* [PATCH 3/5] arm64: defconfig: Enable ILI7807S DSI panel driver
From: Nabige Aala @ 2026-06-27 10:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, arpit.saini, mohit.dsor,
Nabige Aala
In-Reply-To: <20260627-shikra-dt-changes-v1-0-449a402673d0@oss.qualcomm.com>
From: Arpit Saini <arpit.saini@oss.qualcomm.com>
Enable the ILI7807S 1080x1920 video-mode DSI panel driver as a module,
used on the Shikra board.
Signed-off-by: Arpit Saini <arpit.saini@oss.qualcomm.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f2e6ae93e533..0395873ec03f 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1009,6 +1009,7 @@ CONFIG_DRM_MXSFB=m
CONFIG_DRM_IMX_LCDIF=m
CONFIG_DRM_NOUVEAU=m
CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m
+CONFIG_DRM_PANEL_ILITEK_ILI7807S=m
CONFIG_DRM_PANEL_LVDS=m
CONFIG_DRM_PANEL_HIMAX_HX8279=m
CONFIG_DRM_PANEL_HIMAX_HX83112A=m
--
2.34.1
^ permalink raw reply related
* [PATCH 2/5] arm64: dts: qcom: shikra-cqm-evk: Enable display and add ili7807s panel
From: Nabige Aala @ 2026-06-27 10:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, arpit.saini, mohit.dsor,
Nabige Aala
In-Reply-To: <20260627-shikra-dt-changes-v1-0-449a402673d0@oss.qualcomm.com>
From: Arpit Saini <arpit.saini@oss.qualcomm.com>
Enable the Shikra MDSS display subsystem on the Shikra CQM EVK
board and add the DLC0697 MIPI DSI display panel node.
Pin pm4125_l5 to 1.232V with regulator-allow-set-load
for DSI PHY PLL stability.
Signed-off-by: Arpit Saini <arpit.saini@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 104 ++++++++++++++++++++++++++++
1 file changed, 104 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
index 683b5245923b..c9ea093cd8ca 100644
--- a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
+++ b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
@@ -23,6 +23,18 @@ chosen {
stdout-path = "serial0:115200n8";
};
+ lcd_bias: regulator-lcd-bias {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_bias";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&pm4125_l17>;
+ gpio = <&tlmm 151 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-0 = <&lcd_bias_en>;
+ pinctrl-names = "default";
+ };
+
wcn3988-pmu {
compatible = "qcom,wcn3988-pmu";
@@ -60,6 +72,52 @@ vreg_pmu_ch1: ldo4 {
};
};
+&mdss {
+ status = "okay";
+};
+
+&mdss_dsi0 {
+ vdda-supply = <&pm4125_l5>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "dlc,dlc0697", "ilitek,ili7807s";
+ reg = <0>;
+
+ reset-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
+
+ vddi-supply = <&pm4125_l15>;
+ avdd-supply = <&lcd_bias>;
+ avee-supply = <&lcd_bias>;
+
+ pinctrl-0 = <&panel_bl_en &panel_rst_n &panel_te_pin>;
+ pinctrl-1 = <&panel_bl_en_suspend &panel_rst_n_suspend>;
+ pinctrl-names = "default", "sleep";
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+ };
+};
+
+&mdss_dsi0_out {
+ remote-endpoint = <&panel_in>;
+ data-lanes = <0 1 2 3>;
+};
+
+&mdss_dsi0_phy {
+ status = "okay";
+};
+
+&pm4125_l5 {
+ /* DSI VDDA - must be at NOM voltage for PHY PLL lock */
+ regulator-min-microvolt = <1232000>;
+ regulator-max-microvolt = <1232000>;
+ regulator-allow-set-load;
+};
+
&remoteproc_cdsp {
firmware-name = "qcom/shikra/cdsp.mbn";
@@ -116,3 +174,49 @@ &wifi {
status = "okay";
};
+
+&tlmm {
+ lcd_bias_en: lcd-bias-en-state {
+ pins = "gpio151";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ panel_bl_en: panel-bl-en-state {
+ pins = "gpio91";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-high;
+ };
+
+ panel_bl_en_suspend: panel-bl-en-suspend-state {
+ pins = "gpio91";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ output-low;
+ };
+
+ panel_rst_n: panel-rst-n-state {
+ pins = "gpio3";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ panel_rst_n_suspend: panel-rst-n-suspend-state {
+ pins = "gpio3";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ panel_te_pin: panel-te-pin-state {
+ pins = "gpio86";
+ function = "mdp_vsync_p";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: qcom: shikra-cqs-evk: Enable display and add ili7807s panel
From: Nabige Aala @ 2026-06-27 10:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, arpit.saini, mohit.dsor,
Nabige Aala
In-Reply-To: <20260627-shikra-dt-changes-v1-0-449a402673d0@oss.qualcomm.com>
From: Arpit Saini <arpit.saini@oss.qualcomm.com>
Enable the Shikra MDSS display subsystem on the Shikra CQS EVK
board and add the DLC0697 MIPI DSI display panel node.
Signed-off-by: Arpit Saini <arpit.saini@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 104 ++++++++++++++++++++++++++++
1 file changed, 104 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
index 26ff8007a819..4ae47d72d4d4 100644
--- a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
+++ b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
@@ -23,6 +23,18 @@ chosen {
stdout-path = "serial0:115200n8";
};
+ lcd_bias: regulator-lcd-bias {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_bias";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&pm4125_l17>;
+ gpio = <&tlmm 151 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-0 = <&lcd_bias_en>;
+ pinctrl-names = "default";
+ };
+
wcn3988-pmu {
compatible = "qcom,wcn3988-pmu";
@@ -60,6 +72,52 @@ vreg_pmu_ch1: ldo4 {
};
};
+&mdss {
+ status = "okay";
+};
+
+&mdss_dsi0 {
+ vdda-supply = <&pm4125_l5>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "dlc,dlc0697", "ilitek,ili7807s";
+ reg = <0>;
+
+ reset-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
+
+ vddi-supply = <&pm4125_l15>;
+ avdd-supply = <&lcd_bias>;
+ avee-supply = <&lcd_bias>;
+
+ pinctrl-0 = <&panel_bl_en &panel_rst_n &panel_te_pin>;
+ pinctrl-1 = <&panel_bl_en_suspend &panel_rst_n_suspend>;
+ pinctrl-names = "default", "sleep";
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+ };
+};
+
+&mdss_dsi0_out {
+ remote-endpoint = <&panel_in>;
+ data-lanes = <0 1 2 3>;
+};
+
+&mdss_dsi0_phy {
+ status = "okay";
+};
+
+&pm4125_l5 {
+ /* DSI VDDA - must be at NOM voltage for PHY PLL lock */
+ regulator-min-microvolt = <1232000>;
+ regulator-max-microvolt = <1232000>;
+ regulator-allow-set-load;
+};
+
&remoteproc_cdsp {
firmware-name = "qcom/shikra/cdsp.mbn";
@@ -116,3 +174,49 @@ &wifi {
status = "okay";
};
+
+&tlmm {
+ lcd_bias_en: lcd-bias-en-state {
+ pins = "gpio151";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ panel_bl_en: panel-bl-en-state {
+ pins = "gpio91";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-high;
+ };
+
+ panel_bl_en_suspend: panel-bl-en-suspend-state {
+ pins = "gpio91";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ output-low;
+ };
+
+ panel_rst_n: panel-rst-n-state {
+ pins = "gpio3";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ panel_rst_n_suspend: panel-rst-n-suspend-state {
+ pins = "gpio3";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ panel_te_pin: panel-te-pin-state {
+ pins = "gpio86";
+ function = "mdp_vsync_p";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: qcom: Shikra LT9611UXD support
From: Nabige Aala @ 2026-06-27 10:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, arpit.saini, mohit.dsor,
Nabige Aala
In-Reply-To: <20260627-shikra-dt-changes-v1-0-449a402673d0@oss.qualcomm.com>
From: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
Device tree changes to support lt9611uxd hdmi-dsi driver.
Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts | 122 ++++++++++++++++++++++++++++
1 file changed, 122 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
index fd691d53a0fa..9cc4a1c6e4ed 100644
--- a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
+++ b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
@@ -23,6 +23,36 @@ chosen {
stdout-path = "serial0:115200n8";
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <<9611_out>;
+ };
+ };
+ };
+
+ vreg_lt9611_vcc: regulator-lt9611-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "lt9611_vcc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&pm8150_gpios 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_reg_en>;
+ };
+
+ vreg_lt9611_vdd: regulator-lt9611-vdd {
+ compatible = "regulator-fixed";
+ regulator-name = "lt9611_vdd";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
vreg_wcn_3p3: regulator-wcn-3p3 {
compatible = "regulator-fixed";
regulator-name = "wcn_3p3";
@@ -68,6 +98,78 @@ vreg_pmu_ch1: ldo4 {
};
};
+&i2c4 {
+ status = "okay";
+
+ lt9611uxd: lt9611uxd@41 {
+ compatible = "lontium,lt9611uxd";
+ reg = <0x41>;
+ interrupts-extended = <&tlmm 85 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&tlmm 76 GPIO_ACTIVE_HIGH>;
+ vcc-supply = <&vreg_lt9611_vcc>;
+ vdd-supply = <&vreg_lt9611_vdd>;
+ lontium,port-select = <1>; /* PORT_SELECT_B */
+
+ pinctrl-names = "default";
+ pinctrl-0 = <<9611_irq_pin <9611_rst_pin>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lt9611_a: endpoint {
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ lt9611_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
+&mdss {
+ status = "okay";
+};
+
+&mdss_dsi0 {
+ vdda-supply = <&pm8150_l11>;
+ status = "okay";
+
+};
+
+&mdss_dsi0_out {
+ remote-endpoint = <<9611_a>;
+ data-lanes = <0 1 2 3>;
+};
+
+&mdss_dsi0_phy {
+ status = "okay";
+};
+
+&pm8150_gpios {
+ hdmi_reg_en: hdmi-reg-en-state {
+ pins = "gpio4";
+ function = PMIC_GPIO_FUNC_NORMAL;
+ bias-disable;
+ };
+};
+
+&pm8150_l11 {
+ /* DSI VDDA - must be at NOM voltage for PHY PLL lock */
+ regulator-min-microvolt = <1232000>;
+ regulator-max-microvolt = <1232000>;
+ regulator-allow-set-load;
+};
+
&remoteproc_cdsp {
firmware-name = "qcom/shikra/cdsp.mbn";
@@ -103,6 +205,26 @@ &sdhc_1 {
status = "okay";
};
+&tlmm {
+ lt9611_irq_pin: lt9611-irq-state {
+ pins = "gpio85";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ lt9611_rst_pin: lt9611-rst-state {
+ pins = "gpio76";
+ function = "gpio";
+ drive-strength = <8>;
+ output-high;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
&uart8 {
status = "okay";
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 0/2] arm64: dts: rockchip: Add Vicharak Vaaman2 board support
From: Heiko Stübner @ 2026-06-27 10:05 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel,
Hrushiraj Gandhi
Cc: robh, krzk+dt, conor+dt, Hrushiraj Gandhi
In-Reply-To: <20260627094854.81564-1-hrushirajg23@gmail.com>
Hi,
Am Samstag, 27. Juni 2026, 11:48:52 Mitteleuropäische Sommerzeit schrieb Hrushiraj Gandhi:
> This patch series adds device tree support for the Vicharak Vaaman2,
> a single-board computer based on the Rockchip RK3588 SoC.
please use proper versioning when sending new patches
If I'm reading this correctly, this should be
[PATCH v3 0/2] ....
Please also provide a changelog on what changed between versions.
See all the other patchsets on the mailinglist for reference.
Heiko
> The Vaaman2 board features include:
> - RK3588 SoC
> - eMMC storage and microSD support
> - RK806 PMIC and multiple RK8602/RK8603 regulators
> - Real-time clock and status LED
> - UART serial console and SARADC
>
> Note: This series was generated on top of the pending Vicharak Axon
> board support patches (v7) and includes the Axon entry in the context
> of the YAML binding patch.
>
> Patch 1 adds the binding documentation for the Vaaman2 board.
> Patch 2 adds the actual device tree file and Makefile entry.
>
> Hrushiraj Gandhi (2):
> dt-bindings: arm: rockchip: Add Vicharak Vaaman2
> arm64: dts: rockchip: Add Vicharak Vaaman2 board
>
> .../devicetree/bindings/arm/rockchip.yaml | 5 +
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../dts/rockchip/rk3588-vicharak-vaaman2.dts | 547 ++++++++++++++++++
> 3 files changed, 553 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
>
>
^ permalink raw reply
* Re: [PATCH v4 2/2] iio: magnetometer: add support for Melexis MLX90393
From: sashiko-bot @ 2026-06-27 10:06 UTC (permalink / raw)
To: Nikhil Gautam; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260627095519.8377-3-nikhilgtr@gmail.com>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] Data race and state corruption due to function-static `scale_avail` array.
- [High] Stack-allocated buffers are passed to `i2c_transfer`, violating DMA safety rules.
- [Medium] Writing to temperature scale incorrectly modifies magnetometer hardware gain.
- [Medium] Temperature oversampling ratio exposes raw register values instead of actual multipliers.
- [Medium] IIO scale factors are incorrectly calculated, violating the expected IIO ABI units.
- [Low] Use of floating-point literal in delay calculation causes build failures.
--
commit 46a132b5223abb9cadead7640985442ba357e7bc
Author: Nikhil Gautam <nikhilgtr@gmail.com>
iio: magnetometer: add support for Melexis MLX90393
This patch adds Industrial I/O subsystem support for the Melexis MLX90393
3-axis magnetometer and temperature sensor. The driver supports raw magnetic
field and temperature measurements, scale and oversampling selection, and
currently uses the I2C interface.
> diff --git a/drivers/iio/magnetometer/mlx90393_core.c b/drivers/iio/magnetometer/mlx90393_core.c
> new file mode 100644
> index 0000000000000..78fcab8a2b566
> --- /dev/null
> +++ b/drivers/iio/magnetometer/mlx90393_core.c
> @@ -0,0 +1,701 @@
[ ... ]
> +static const int mlx90393_osr2_avail[MLX90393_OSR2_MAX] = {
> + 0, 1, 2, 3,
> +};
[Severity: Medium]
Does this expose raw register values for the temperature oversampling ratio
instead of the actual multipliers?
The IIO ABI requires exposing the actual ratio (1, 2, 4, 8) rather than the
raw hardware indices. Users reading or writing the in_temp_oversampling_ratio
sysfs attribute might be confused by these hardware-specific indices.
[ ... ]
> +static int mlx90393_read_reg(struct mlx90393_data *data, u8 reg, u16 *val)
> +{
> + u8 tx[2];
> + u8 rx[3];
> + int ret;
> +
> + tx[0] = MLX90393_CMD_RR;
> + /* Register address is encoded in bits [7:2] */
> + tx[1] = reg << 2;
> +
> + ret = mlx90393_xfer(data, tx, sizeof(tx), rx, sizeof(rx));
[Severity: High]
Can passing these stack-allocated buffers to the I2C transport cause memory
corruption or DMA mapping errors?
Since CONFIG_VMAP_STACK is enabled by default in modern kernels, stack memory
is not physically contiguous and cannot be safely mapped for DMA. When sysfs
operations trigger communication with the device, the I2C controller might use
DMA to transfer data, which expects DMA-safe memory.
This pattern is also present in mlx90393_write_reg() and
mlx90393_read_measurement().
[ ... ]
> +static int mlx90393_get_scale(struct mlx90393_data *data,
> + const struct iio_chan_spec *chan,
> + int *val, int *val2)
> +{
> + enum mlx90393_axis_type axis;
> + u8 res;
> +
> + if (chan->channel2 == IIO_MOD_Z) {
> + axis = MLX90393_AXIS_TYPE_Z;
> + res = data->res_z;
> + } else {
> + axis = MLX90393_AXIS_TYPE_XY;
> + res = data->res_xy;
> + }
> +
> + *val = 0;
> + *val2 = mlx90393_scale_table[axis][data->gain_sel][res];
> +
> + return IIO_VAL_INT_PLUS_NANO;
> +}
[Severity: Medium]
Does this calculate the scale factor correctly for the IIO ABI?
The magnetometer scale values in mlx90393_scale_table are returned using
IIO_VAL_INT_PLUS_NANO, yielding a value like 0.000000751. However, since the
value is 0.751 uT/LSB, this corresponds to 0.00751 Gauss/LSB. Returning it
as nanounits without adjusting the multiplier makes the reported scale off by
a factor of 10,000.
[ ... ]
> +static int mlx90393_write_raw(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int val, int val2,
> + long mask)
> +{
> + struct mlx90393_data *data = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE: {
> + guard(mutex)(&data->lock);
> + return mlx90393_set_scale(data, chan, val, val2);
> + }
[Severity: Medium]
Does this allow writing to the temperature scale?
Since IIO_CHAN_INFO_SCALE is checked unconditionally without validating
chan->type, writes to the in_temp_scale sysfs attribute fall through to
mlx90393_set_scale(). Because chan->channel2 is 0 for the temperature channel,
this unintentionally modifies the magnetometer's GAIN_SEL configuration instead
of returning -EINVAL.
[ ... ]
> +static int mlx90393_read_raw(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int *val, int *val2, long mask)
> +{
[ ... ]
> + case IIO_CHAN_INFO_SCALE:
> + switch (chan->type) {
> + case IIO_MAGN:
> + return mlx90393_get_scale(data, chan, val, val2);
> +
> + case IIO_TEMP:
> + /*
> + * Datasheet Table 7: Thermal Specification
> + */
> + *val = 0;
> + *val2 = 22124;
> + return IIO_VAL_INT_PLUS_MICRO;
[Severity: Medium]
Does this return the temperature scale in degrees Celsius instead of
milli-Celsius?
The IIO ABI specifies that temperature should be exposed in milli-Celsius, but
returning 0.022124 yields degrees Celsius.
[ ... ]
> +static int mlx90393_read_avail(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + const int **vals,
> + int *type,
> + int *length,
> + long mask)
> +{
> + struct mlx90393_data *data = iio_priv(indio_dev);
> + static int scale_avail[MLX90393_GAIN_MAX][MLX90393_AXIS_MAX];
[Severity: High]
Can concurrent reads of this function corrupt the scale_available sysfs output?
Because scale_avail is declared as a function-static array, it is shared
across all channels and devices. When the IIO core processes the returned
pointer outside of the driver's lock, concurrent reads (e.g., from multiple
axes or probed devices) will overwrite the array and return interleaved or
incorrect values to userspace.
[ ... ]
> +static int mlx90393_init(struct mlx90393_data *data)
> +{
> + int ret;
> + u16 reg;
> +
> + /* Exit mode */
> + ret = mlx90393_write_cmd(data, MLX90393_CMD_EX);
> + if (ret)
> + return ret;
> +
> + /*
> + * Datasheet section 15.4.1.2 (RT command), Figure 16:
> + * Wait 1 ms after EX command before issuing RT.
> + */
> + fsleep(1 * USEC_PER_MSEC);
> +
> + /* Reset device */
> + ret = mlx90393_write_cmd(data, MLX90393_CMD_RT);
> + if (ret)
> + return ret;
> +
> + /*
> + * Datasheet section 15.4.1.2 (RT command), Figure 16:
> + * Wait 1.5 ms for the start-up sequence to complete.
> + */
> + fsleep(1.5 * USEC_PER_MSEC);
[Severity: Low]
Will this floating-point literal cause build failures?
The expression uses 1.5, which is a double-precision floating-point literal.
The Linux kernel does not support floating-point arithmetic, which leads to
compilation errors on most architectures that do not support soft-float or
have strict compiler flags against floating-point usage.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260627095519.8377-1-nikhilgtr@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: rockchip: Add Vicharak Vaaman2 board support
From: Heiko Stübner @ 2026-06-27 10:06 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel,
Hrushiraj Gandhi
Cc: robh, krzk+dt, conor+dt, Hrushiraj Gandhi
In-Reply-To: <1999863.IobQ9Gjlxr@diego>
Am Samstag, 27. Juni 2026, 12:05:35 Mitteleuropäische Sommerzeit schrieb Heiko Stübner:
> Hi,
>
> Am Samstag, 27. Juni 2026, 11:48:52 Mitteleuropäische Sommerzeit schrieb Hrushiraj Gandhi:
> > This patch series adds device tree support for the Vicharak Vaaman2,
> > a single-board computer based on the Rockchip RK3588 SoC.
>
> please use proper versioning when sending new patches
>
> If I'm reading this correctly, this should be
>
> [PATCH v3 0/2] ....
correction .. v2 ;-)
The other was the Axon board.
>
> Please also provide a changelog on what changed between versions.
> See all the other patchsets on the mailinglist for reference.
>
> Heiko
>
> > The Vaaman2 board features include:
> > - RK3588 SoC
> > - eMMC storage and microSD support
> > - RK806 PMIC and multiple RK8602/RK8603 regulators
> > - Real-time clock and status LED
> > - UART serial console and SARADC
> >
> > Note: This series was generated on top of the pending Vicharak Axon
> > board support patches (v7) and includes the Axon entry in the context
> > of the YAML binding patch.
> >
> > Patch 1 adds the binding documentation for the Vaaman2 board.
> > Patch 2 adds the actual device tree file and Makefile entry.
> >
> > Hrushiraj Gandhi (2):
> > dt-bindings: arm: rockchip: Add Vicharak Vaaman2
> > arm64: dts: rockchip: Add Vicharak Vaaman2 board
> >
> > .../devicetree/bindings/arm/rockchip.yaml | 5 +
> > arch/arm64/boot/dts/rockchip/Makefile | 1 +
> > .../dts/rockchip/rk3588-vicharak-vaaman2.dts | 547 ++++++++++++++++++
> > 3 files changed, 553 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
> >
> >
>
>
^ permalink raw reply
* Re: [PATCH v3 7/9] ASoC: dt-bindings: loongson,ls-audio-card: Add ATK-DL2K0300B compatible
From: Binbin Zhou @ 2026-06-27 10:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Binbin Zhou, Huacai Chen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Keguang Zhang, Huacai Chen, Xuerui Wang, loongarch,
devicetree, linux-sound
In-Reply-To: <20260626-devout-vulture-of-reading-4fbfad@quoll>
Hi Krzysztof:
Thanks for your review.
On Fri, Jun 26, 2026 at 6:01 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Fri, Jun 26, 2026 at 10:27:28AM +0800, Binbin Zhou wrote:
> > Add new compatible for the ATK-DL2K0300B development board based on
> > Loongson-2K0300.
> >
> > Unlike others, this board features GPIO-controlled headphone detection,
> > headphone control, and speaker enable.
> >
> > Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> > ---
> > .../sound/loongson,ls-audio-card.yaml | 38 +++++++++++++++++++
> > 1 file changed, 38 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
> > index 8c214e5d04b1..dc7f4afbb777 100644
> > --- a/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
> > +++ b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
> > @@ -23,6 +23,7 @@ properties:
> > enum:
> > - loongson,ls-audio-card # Loongson-2K1000/Loongson-2K2000/LS7A
> > - loongson,ls2k0300-forever-pi-audio-card # CTCISZ Forever Pi
> > + - loongson,ls2k0300-dl2k0300b-audio-card # ATK-DL2K0300B
> >
> > mclk-fs:
> > $ref: simple-card.yaml#/definitions/mclk-fs
> > @@ -47,6 +48,18 @@ properties:
> > required:
> > - sound-dai
> >
> > + spkr-en-gpios:
> > + maxItems: 1
> > + description: The GPIO that enables the speakers
> > +
> > + hp-ctl-gpios:
> > + maxItems: 1
> > + description: The GPIO that control the headphones
> > +
> > + hp-det-gpios:
> > + maxItems: 1
> > + description: The GPIO that detect headphones are plugged in
> > +
>
> Add allOf:if:then: block after "required:" block and disallow these
> ("...: false") for other variants.
OK, I will add if:then block as follow:
@@ -68,6 +68,18 @@ required:
unevaluatedProperties: false
+if:
+ properties:
+ compatible:
+ contains:
+ const: loongson,ls2k0300-dl2k0300b-audio-card
+
+then:
+ required:
+ - spkr-en-gpios
+ - hp-ctl-gpios
+ - hp-det-gpios
+
examples:
- |
sound
>
> If these stay, because I have doubts. spkr-en-gpios sounds like
> enable-gpios of each speaker, so not suitable here but should go to
> individual speaker codec nodes.
Speaker codec? Sorry, I’m not quite sure what you mean. `speaker` and
`headphone` are routing options for the same codec (es8328), and they
are mutually exclusive. Of course, based on the current design, there
aren’t multiple `speakers`.
Also, these three GPIOs are on the CPU side. Is it reasonable to place
them in the `machine` node?
>
> Best regards,
> Krzysztof
>
--
Thanks.
Binbin
^ permalink raw reply
* [PATCH v2 0/2] arm64: dts: rockchip: Add Vicharak Vaaman2 board support
From: Hrushiraj Gandhi @ 2026-06-27 10:26 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel
Cc: heiko, robh, krzk+dt, conor+dt, Hrushiraj Gandhi
This patch series adds device tree support for the Vicharak Vaaman2,
a single-board computer based on the Rockchip RK3588 SoC.
The Vaaman2 board features include:
- RK3588 SoC
- eMMC storage and microSD support
- RK806 PMIC and multiple RK8602/RK8603 regulators
- Real-time clock and status LED
- UART serial console and SARADC
Note: This series was generated on top of the pending Vicharak Axon
board support patches (v7) and includes the Axon entry in the context
of the YAML binding patch.
Changes in v2:
- Fixed rk806 PMIC pinctrl node names to comply with dtbs_check ('-pins' suffix).
- Removed I2S audio nodes which were unneeded for minimal boot.
- Cleaned up indentation throughout the DTS.
Patch 1 adds the binding documentation for the Vaaman2 board.
Patch 2 adds the actual device tree file and Makefile entry.
Hrushiraj Gandhi (2):
dt-bindings: arm: rockchip: Add Vicharak Vaaman2
arm64: dts: rockchip: Add Vicharak Vaaman2 board
.../devicetree/bindings/arm/rockchip.yaml | 5 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588-vicharak-vaaman2.dts | 547 ++++++++++++++++++
3 files changed, 553 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
--
2.47.3
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: arm: rockchip: Add Vicharak Vaaman2
From: Hrushiraj Gandhi @ 2026-06-27 10:26 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel
Cc: heiko, robh, krzk+dt, conor+dt, Hrushiraj Gandhi
In-Reply-To: <20260627102633.86222-1-hrushirajg23@gmail.com>
Add device tree binding documentation for the Vicharak Vaaman2,
a single-board computer based on the Rockchip RK3588 SoC.
Signed-off-by: Hrushiraj Gandhi <hrushirajg23@gmail.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index b023d4cc9842..b5a43fd5e546 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -1311,6 +1311,11 @@ properties:
- const: vicharak,axon
- const: rockchip,rk3588
+ - description: Vicharak Vaaman2
+ items:
+ - const: vicharak,vaaman2
+ - const: rockchip,rk3588
+
- description: WolfVision PF5 mainboard
items:
- const: wolfvision,rk3568-pf5
--
2.47.3
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: rockchip: Add Vicharak Vaaman2 board
From: Hrushiraj Gandhi @ 2026-06-27 10:26 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel
Cc: heiko, robh, krzk+dt, conor+dt, Hrushiraj Gandhi
In-Reply-To: <20260627102633.86222-1-hrushirajg23@gmail.com>
Add device tree for the Vicharak Vaaman2, a single-board computer
based on the Rockchip RK3588 SoC.
The board features:
- RK3588 SoC with 4x Cortex-A76 (big) + 4x Cortex-A55 (little)
- eMMC storage via SDHCI (HS400)
- microSD card via SDMMC
- RK806 PMIC on SPI2 providing all required power domains
- Two RK8602/RK8603 CPU regulators on I2C0 (big clusters)
- RK8602 NPU regulator on I2C1
- HYM8563 RTC on I2C0
- Status LED on GPIO2_C5 (active-low, heartbeat trigger)
- UART2 as serial console at 1500000 baud
- SARADC with 1.8V reference
Signed-off-by: Hrushiraj Gandhi <hrushirajg23@gmail.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588-vicharak-vaaman2.dts | 547 ++++++++++++++++++
2 files changed, 548 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 92114cb757cc..9213280d831b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-tiger-haikou-video-demo.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-toybrick-x0.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-turing-rk1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-vicharak-axon.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-vicharak-vaaman2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-coolpi-4b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-evb1-v10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-gameforce-ace.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts b/arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
new file mode 100644
index 000000000000..9ba9688c1213
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
@@ -0,0 +1,547 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3588.dtsi"
+
+/ {
+ model = "Vicharak Vaaman2";
+ compatible = "vicharak,vaaman2", "rockchip,rk3588";
+
+ aliases {
+ mmc0 = &sdmmc;
+ mmc1 = &sdhci;
+ serial2 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ status_led: status-led {
+ gpios = <&gpio2 RK_PC5 GPIO_ACTIVE_LOW>;
+ function = LED_FUNCTION_STATUS;
+ default-state = "on";
+ retain-state-suspended;
+ linux,default-trigger = "heartbeat";
+ };
+
+ };
+
+ vcc20v_dcin: regulator-vcc20v-dcin {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc20v_dcin";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <20000000>;
+ regulator-max-microvolt = <20000000>;
+ };
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc20v_dcin>;
+ };
+
+ vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v1_nldo_s3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+ cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+ cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+
+&i2c0 {
+ pinctrl-0 = <&i2c0m2_xfer>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ vdd_cpu_big0_s0: regulator@42 {
+ compatible = "rockchip,rk8602";
+ fcs,suspend-voltage-selector = <1>;
+ reg = <0x42>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1050000>;
+ regulator-min-microvolt = <550000>;
+ regulator-name = "vdd_cpu_big0_s0";
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_big1_s0: regulator@43 {
+ compatible = "rockchip,rk8603", "rockchip,rk8602";
+ fcs,suspend-voltage-selector = <1>;
+ reg = <0x43>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1050000>;
+ regulator-min-microvolt = <550000>;
+ regulator-name = "vdd_cpu_big1_s0";
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ hym8563: rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ clock-output-names = "hym8563";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rtc_int>;
+ wakeup-source;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1m2_xfer>;
+ status = "okay";
+
+ vdd_npu_s0: regulator@42 {
+ compatible = "rockchip,rk8602";
+ reg = <0x42>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_npu_s0";
+ regulator-boot-on;
+ regulator-enable-ramp-delay = <500>;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&sdhci {
+ bus-width = <8>;
+ full-pwr-cycle-in-suspend;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ no-sd;
+ no-sdio;
+ non-removable;
+ vmmc-supply = <&vcc_3v3_s3>;
+ vqmmc-supply = <&vcc_1v8_s3>;
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ max-frequency = <200000000>;
+ no-mmc;
+ no-sdio;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc_3v3_s3>;
+ vqmmc-supply = <&vccio_sd_s0>;
+ status = "okay";
+};
+
+&spi2 {
+ assigned-clock-rates = <200000000>;
+ assigned-clocks = <&cru CLK_SPI2>;
+ num-cs = <1>;
+ pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@0 {
+ reg = <0>;
+ compatible = "rockchip,rk806";
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-parent = <&gpio0>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+ <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+ spi-max-frequency = <1000000>;
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc5-supply = <&vcc5v0_sys>;
+ vcc6-supply = <&vcc5v0_sys>;
+ vcc7-supply = <&vcc5v0_sys>;
+ vcc8-supply = <&vcc5v0_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+ vcc10-supply = <&vcc5v0_sys>;
+ vcc11-supply = <&vcc_2v0_pldo_s3>;
+ vcc12-supply = <&vcc5v0_sys>;
+ vcc13-supply = <&vcc_1v1_nldo_s3>;
+ vcc14-supply = <&vcc_1v1_nldo_s3>;
+ vcca-supply = <&vcc5v0_sys>;
+
+ rk806_dvs1_null: dvs1-null-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs2_null: dvs2-null-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs3_null: dvs3-null-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun0";
+ };
+
+ regulators {
+ vdd_gpu_s0: dcdc-reg1 {
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_gpu_s0";
+ regulator-enable-ramp-delay = <400>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_lit_s0: dcdc-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_cpu_lit_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_log_s0: dcdc-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <750000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_log_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdd_vdenc_s0: dcdc-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_vdenc_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_ddr_s0: dcdc-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <900000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_ddr_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <850000>;
+ };
+ };
+
+ vdd2_ddr_s3: dcdc-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vdd2_ddr_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_2v0_pldo_s3: dcdc-reg7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-name = "vdd_2v0_pldo_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <2000000>;
+ };
+ };
+
+ vcc_3v3_s3: dcdc-reg8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_3v3_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vddq_ddr_s0: dcdc-reg9 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vddq_ddr_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8_s3: dcdc-reg10 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_1v8_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ avcc_1v8_s0: pldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "avcc_1v8_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8_s0: pldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_1v8_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ avdd_1v2_s0: pldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "avdd_1v2_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v3_s0: pldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_3v3_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd_s0: pldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ pldo6_s3: pldo-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "pldo6_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd_0v75_s3: nldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdd_0v75_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdd_ddr_pll_s0: nldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdd_ddr_pll_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <850000>;
+ };
+ };
+
+ avdd_0v75_s0: nldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <837500>;
+ regulator-max-microvolt = <837500>;
+ regulator-name = "avdd_0v75_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_0v85_s0: nldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdd_0v85_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_0v75_s0: nldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdd_0v75_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+&pinctrl {
+ hym8563 {
+ rtc_int: rtc-int {
+ rockchip,pins =
+ <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&saradc {
+ vref-supply = <&avcc_1v8_s0>;
+ status = "okay";
+};
+
+&tsadc {
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2m0_xfer>;
+ status = "okay";
+};
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v5 0/7] thermal/drivers: airoha: Add support for AN7583
From: Christian Marangi (Ansuel) @ 2026-06-27 11:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Christian Marangi,
Lorenzo Bianconi, devicetree, linux-kernel, linux-pm
In-Reply-To: <20260520155525.22239-1-ansuelsmth@gmail.com>
Il giorno mer 20 mag 2026 alle ore 17:55 Christian Marangi
<ansuelsmth@gmail.com> ha scritto:
>
> This small series implement all the required changes to
> support Airoha AN7583 Thermal Sensor.
>
> The SoC dropped the Monitor subsystem and only provide
> temperature reading. Some generalization was required
> to at least save the common code with also the help of
> reg field API.
>
> Changes v5:
> - Fix alpabetical order in Documentation patch
> - Address suggested change by AI Bot
> Changes v4:
> - Rebase on top of linux-next
> Changes v3:
> - Property use chip-scu for thermal sensor
> Changes v2:
> - Update DT schema patch to implement dedicated schema
>
> Christian Marangi (7):
> thermal/drivers: airoha: fix copy paste error on clamp_t low temp
> thermal/drivers: airoha: fix copy paste error for sen internal
> thermal/drivers: airoha: Convert to regmap API
> thermal/drivers: airoha: Generalize probe function
> thermal/drivers: airoha: Generalize get_thermal_ADC and set_mux
> function
> dt-bindings: arm: airoha: Add the chip-scu node for AN7583 SoC
> thermal/drivers: airoha: Add support for AN7583 Thermal Sensor
>
> .../bindings/arm/airoha,en7581-chip-scu.yaml | 14 +
> drivers/thermal/airoha_thermal.c | 380 +++++++++++++++---
> 2 files changed, 327 insertions(+), 67 deletions(-)
>
Any news for this series? Can someone check it? Every patch have
a tag.
^ permalink raw reply
* [PATCH v3 0/4] CI: mediatek-gen3: Add 2-lanes mode support + clock
From: Christian Marangi @ 2026-06-27 12:14 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ryder Lee, Michael Turquette, Stephen Boyd,
Brian Masney, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi, Jianjun Wang,
linux-pci, devicetree, linux-kernel, linux-mediatek, linux-clk,
linux-arm-kernel
This small series introduce support for 2-lanes mode for Airoha AN7581
SoC. This is needed for correctly functionality of Eagle WiFi Card
normally attached to this SoC that require a 2-line PCIe card to
correctly work (and give the proper performance)
The first 2 patch address a limitation of the PCIe implementation
where the PERSTOUT reset were indirectly asserted and deasserted
all at the same time (for all the 3 PCIe card) with PCIe
enable and disable.
The 2 patch address this and introduce correct reset to control
reset line for the relevant PCIe line.
The last 2 patch add additional logic and support to assert
and deassert the PERSTOUT and also apply the required configuration
for 2-lanes mode.
2-lanes mode is implemented in DT by adding the required property
and by defining the "num-lanes" to 2.
Changes v3:
- Add Ack from Krzysztof
- Improve commit description of PCIe patch
- Use pcie->num_lanes instead of possible uninit variable num_lanes
Changes v2:
- Address typo regs -> reg in Documentation
- Address typo lan -> lane in Documentation
- Apply a suggested fix from Airoha for PCIe MUX configuration
before PHY init
- Parse secondary reg in probe
- Add missing reset_status handling for inverted bits
- Move SCU to local handling in power_up
- Add check for max num-lanes for EN7581
Christian Marangi (4):
dt-bindings: clock: airoha: Add additional reset for PCIe PERSTOUT
clk: en7523: add support for dedicated PCIe PERSTOUT reset
dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document
2-lanes
PCI: mediatek-gen3: Add 2-lanes mode support for Airoha AN7581
.../bindings/pci/airoha,en7581-pcie.yaml | 251 ++++++++++++++++++
.../bindings/pci/mediatek-pcie-gen3.yaml | 77 +-----
drivers/clk/clk-en7523.c | 39 ++-
drivers/pci/controller/pcie-mediatek-gen3.c | 104 ++++++--
.../dt-bindings/reset/airoha,en7581-reset.h | 4 +
5 files changed, 375 insertions(+), 100 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml
--
2.53.0
^ permalink raw reply
* [PATCH v3 1/4] dt-bindings: clock: airoha: Add additional reset for PCIe PERSTOUT
From: Christian Marangi @ 2026-06-27 12:14 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ryder Lee, Michael Turquette, Stephen Boyd,
Brian Masney, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi, Jianjun Wang,
linux-pci, devicetree, linux-kernel, linux-mediatek, linux-clk,
linux-arm-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260627121450.3529133-1-ansuelsmth@gmail.com>
Add additional reset to control PCIe PERSTOUT reset line for each of the 3
PCIe lines.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
include/dt-bindings/reset/airoha,en7581-reset.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/dt-bindings/reset/airoha,en7581-reset.h b/include/dt-bindings/reset/airoha,en7581-reset.h
index 6544a1790b83..25e75534daa9 100644
--- a/include/dt-bindings/reset/airoha,en7581-reset.h
+++ b/include/dt-bindings/reset/airoha,en7581-reset.h
@@ -62,5 +62,9 @@
#define EN7581_CPU_TIMER_RST 50
#define EN7581_PCIE_HB_RST 51
#define EN7581_XPON_MAC_RST 52
+/* RST_PCIC */
+#define EN7581_PCIC_PERSTOUT0_RST 53
+#define EN7581_PCIC_PERSTOUT1_RST 54
+#define EN7581_PCIC_PERSTOUT2_RST 55
#endif /* __DT_BINDINGS_RESET_CONTROLLER_AIROHA_EN7581_H_ */
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/4] clk: en7523: add support for dedicated PCIe PERSTOUT reset
From: Christian Marangi @ 2026-06-27 12:14 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ryder Lee, Michael Turquette, Stephen Boyd,
Brian Masney, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi, Jianjun Wang,
linux-pci, devicetree, linux-kernel, linux-mediatek, linux-clk,
linux-arm-kernel
In-Reply-To: <20260627121450.3529133-1-ansuelsmth@gmail.com>
Add support for resetting the PCIe lines with the PERSTOUT reset. These
special reset are controlled by the PCIC register and are specific to each
of the 3 PCIe lines.
Notice that reset logic is inverted for these bit where 0 is assert and 1
deassert. This is intenrally handled in the reset function.
PCI enable/disable are updated to drop PERSTOUT bits in favor dedicated
reset handling.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
drivers/clk/clk-en7523.c | 39 ++++++++++++++++++++++++++++-----------
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/clk-en7523.c b/drivers/clk/clk-en7523.c
index 1ab0e2eca5d3..c9b21d9bf2f3 100644
--- a/drivers/clk/clk-en7523.c
+++ b/drivers/clk/clk-en7523.c
@@ -338,6 +338,7 @@ static const struct en_clk_desc en7581_base_clks[] = {
static const u16 en7581_rst_ofs[] = {
REG_RST_CTRL2,
REG_RST_CTRL1,
+ REG_NP_SCU_PCIC,
};
static const u16 en751221_rst_ofs[] = {
@@ -450,6 +451,11 @@ static const u16 en7581_rst_map[] = {
[EN7581_CPU_TIMER_RST] = RST_NR_PER_BANK + 28,
[EN7581_PCIE_HB_RST] = RST_NR_PER_BANK + 29,
[EN7581_XPON_MAC_RST] = RST_NR_PER_BANK + 31,
+
+ /* RST_PCIC */
+ [EN7581_PCIC_PERSTOUT0_RST] = 2 * RST_NR_PER_BANK + 29,
+ [EN7581_PCIC_PERSTOUT1_RST] = 2 * RST_NR_PER_BANK + 26,
+ [EN7581_PCIC_PERSTOUT2_RST] = 2 * RST_NR_PER_BANK + 16,
};
static const u16 en751221_rst_map[] = {
@@ -635,9 +641,7 @@ static int en7581_pci_enable(struct clk_hw *hw)
void __iomem *np_base = cg->base;
u32 val, mask;
- mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1 |
- REG_PCI_CONTROL_PERSTOUT1 | REG_PCI_CONTROL_PERSTOUT2 |
- REG_PCI_CONTROL_PERSTOUT;
+ mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1;
val = readl(np_base + REG_PCI_CONTROL);
writel(val | mask, np_base + REG_PCI_CONTROL);
@@ -650,9 +654,7 @@ static void en7581_pci_disable(struct clk_hw *hw)
void __iomem *np_base = cg->base;
u32 val, mask;
- mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1 |
- REG_PCI_CONTROL_PERSTOUT1 | REG_PCI_CONTROL_PERSTOUT2 |
- REG_PCI_CONTROL_PERSTOUT;
+ mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1;
val = readl(np_base + REG_PCI_CONTROL);
writel(val & ~mask, np_base + REG_PCI_CONTROL);
usleep_range(1000, 2000);
@@ -754,14 +756,21 @@ static int en7523_reset_update(struct reset_controller_dev *rcdev,
unsigned long id, bool assert)
{
struct en_rst_data *rst_data = container_of(rcdev, struct en_rst_data, rcdev);
- void __iomem *addr = rst_data->base + rst_data->bank_ofs[id / RST_NR_PER_BANK];
+ u32 offset = rst_data->bank_ofs[id / RST_NR_PER_BANK];
+ void __iomem *addr = rst_data->base + offset;
+ bool inverted = false;
u32 val;
+ /* For PCIC reset logic is inverted, 0:assert 1:deassert*/
+ if (offset == REG_NP_SCU_PCIC)
+ inverted = true;
+
val = readl(addr);
+ val &= ~BIT(id % RST_NR_PER_BANK);
if (assert)
- val |= BIT(id % RST_NR_PER_BANK);
+ val |= inverted ? 0 : BIT(id % RST_NR_PER_BANK);
else
- val &= ~BIT(id % RST_NR_PER_BANK);
+ val |= inverted ? BIT(id % RST_NR_PER_BANK) : 0;
writel(val, addr);
return 0;
@@ -783,9 +792,17 @@ static int en7523_reset_status(struct reset_controller_dev *rcdev,
unsigned long id)
{
struct en_rst_data *rst_data = container_of(rcdev, struct en_rst_data, rcdev);
- void __iomem *addr = rst_data->base + rst_data->bank_ofs[id / RST_NR_PER_BANK];
+ u32 offset = rst_data->bank_ofs[id / RST_NR_PER_BANK];
+ void __iomem *addr = rst_data->base + offset;
+ bool inverted = false;
+ u32 val;
+
+ /* For PCIC reset logic is inverted, 0:assert 1:deassert*/
+ if (offset == REG_NP_SCU_PCIC)
+ inverted = true;
- return !!(readl(addr) & BIT(id % RST_NR_PER_BANK));
+ val = readl(addr) & BIT(id % RST_NR_PER_BANK);
+ return inverted ? !val : !!val;
}
static int en7523_reset_xlate(struct reset_controller_dev *rcdev,
--
2.53.0
^ permalink raw reply related
* [PATCH v3 3/4] dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document 2-lanes
From: Christian Marangi @ 2026-06-27 12:14 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ryder Lee, Michael Turquette, Stephen Boyd,
Brian Masney, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi, Jianjun Wang,
linux-pci, devicetree, linux-kernel, linux-mediatek, linux-clk,
linux-arm-kernel
In-Reply-To: <20260627121450.3529133-1-ansuelsmth@gmail.com>
To permit proper documentation of required property to support PCIe
configured for 2-lanes mode, split the Airoha schema part from the
mediatek-gen3 schema to a dedicated schema.
A PCIe configured for 2-lanes mode require an additional reg for the
secondary PCIe to be configured and the airoha,scu phandle to correctly
configure the PCIe MUX.
Rework the mediatek-gen3 schema to drop any redundant constraint previsouly
introduced for Airoha PCIe properties.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
.../bindings/pci/airoha,en7581-pcie.yaml | 251 ++++++++++++++++++
.../bindings/pci/mediatek-pcie-gen3.yaml | 77 +-----
2 files changed, 256 insertions(+), 72 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml
diff --git a/Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml b/Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml
new file mode 100644
index 000000000000..c690ba7f207c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml
@@ -0,0 +1,251 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/airoha,en7581-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Gen3 PCIe controller on Airoha SoCs
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description: |+
+ PCIe Gen3 MAC controller for Airoha 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.
+
+properties:
+ compatible:
+ const: airoha,en7581-pcie
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ minItems: 1
+ maxItems: 2
+
+ interrupts:
+ maxItems: 1
+
+ ranges:
+ minItems: 1
+ maxItems: 8
+
+ iommu-map:
+ maxItems: 1
+
+ iommu-map-mask:
+ const: 0
+
+ resets:
+ minItems: 1
+ maxItems: 4
+
+ reset-names:
+ minItems: 1
+ maxItems: 4
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: sys-ck
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ items:
+ - const: pcie-phy
+
+ num-lanes:
+ enum: [1, 2]
+
+ mediatek,pbus-csr:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to pbus-csr syscon
+ - description: offset of pbus-csr base address register
+ - description: offset of pbus-csr base address mask register
+ description:
+ Phandle with two arguments to the syscon node used to detect if
+ a given address is accessible on PCIe controller.
+
+ airoha,scu:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to airoha SCU syscon
+ description:
+ Phandle to SCU syscon to configure PCIe MUX for 2 lines support.
+
+ '#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
+ - clock-names
+ - '#interrupt-cells'
+ - interrupt-controller
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+ - if:
+ properties:
+ num-lanes:
+ const: 2
+ then:
+ properties:
+ reg:
+ minItems: 2
+
+ reg-names:
+ items:
+ - const: pcie-mac
+ - const: sec-pcie-mac
+
+ resets:
+ minItems: 4
+
+ reset-names:
+ items:
+ - const: phy-lane0
+ - const: phy-lane1
+ - const: perstout
+ - const: sec-perstout
+
+ required:
+ - airoha,scu
+
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
+ reg-names:
+ items:
+ - const: pcie-mac
+
+ resets:
+ minItems: 2
+ maxItems: 3
+
+ reset-names:
+ minItems: 2
+ items:
+ - enum: [ phy-lane0, phy-lane1, phy-lane2 ]
+ - enum: [ phy-lane1, perstout ]
+ - const: phy-lane2
+
+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@1fc00000 {
+ compatible = "airoha,en7581-pcie";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ reg = <0x0 0x1fc00000 0x0 0x1670>,
+ <0x0 0x1fc20000 0x0 0x1670>;
+ reg-names = "pcie-mac", "sec-pcie-mac";
+
+ clocks = <&scuclk 7>;
+ clock-names = "sys-ck";
+
+ phys = <&pciephy>;
+ phy-names = "pcie-phy";
+
+ ranges = <0x02000000 0 0x20000000 0x0 0x20000000 0 0x4000000>;
+
+ resets = <&scuclk 48>,
+ <&scuclk 49>,
+ <&scuclk 53>,
+ <&scuclk 54>;
+ reset-names = "phy-lane0", "phy-lane1",
+ "perstout", "sec-perstout";
+
+ num-lanes = <2>;
+
+ mediatek,pbus-csr = <&pbus_csr 0x0 0x4>;
+
+ airoha,scu = <&scuclk>;
+
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ bus-range = <0x00 0xff>;
+ #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;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
index 4db700fc36ba..510f1f2b1c5a 100644
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
@@ -59,7 +59,6 @@ properties:
- const: mediatek,mt8196-pcie
- const: mediatek,mt8192-pcie
- const: mediatek,mt8196-pcie
- - const: airoha,en7581-pcie
reg:
maxItems: 1
@@ -83,20 +82,20 @@ properties:
resets:
minItems: 1
- maxItems: 3
+ maxItems: 2
reset-names:
minItems: 1
- maxItems: 3
+ maxItems: 2
items:
- enum: [ phy, mac, phy-lane0, phy-lane1, phy-lane2 ]
+ enum: [ phy, mac ]
clocks:
- minItems: 1
+ minItems: 4
maxItems: 6
clock-names:
- minItems: 1
+ minItems: 4
maxItems: 6
assigned-clocks:
@@ -115,17 +114,6 @@ properties:
power-domains:
maxItems: 1
- mediatek,pbus-csr:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- items:
- - items:
- - description: phandle to pbus-csr syscon
- - description: offset of pbus-csr base address register
- - description: offset of pbus-csr base address mask register
- description:
- Phandle with two arguments to the syscon node used to detect if
- a given address is accessible on PCIe controller.
-
'#interrupt-cells':
const: 1
@@ -177,16 +165,6 @@ allOf:
- const: peri_26m
- const: top_133m
- resets:
- minItems: 1
- maxItems: 2
-
- reset-names:
- minItems: 1
- maxItems: 2
-
- mediatek,pbus-csr: false
-
- if:
properties:
compatible:
@@ -208,16 +186,6 @@ allOf:
- const: peri_26m
- const: peri_mem
- resets:
- minItems: 1
- maxItems: 2
-
- reset-names:
- minItems: 1
- maxItems: 2
-
- mediatek,pbus-csr: false
-
- if:
properties:
compatible:
@@ -246,8 +214,6 @@ allOf:
- const: phy
- const: mac
- mediatek,pbus-csr: false
-
- if:
properties:
compatible:
@@ -257,7 +223,6 @@ allOf:
then:
properties:
clocks:
- minItems: 4
maxItems: 4
clock-names:
@@ -267,38 +232,6 @@ allOf:
- const: peri_26m
- const: top_133m
- resets:
- minItems: 1
- maxItems: 2
-
- reset-names:
- minItems: 1
- maxItems: 2
-
- mediatek,pbus-csr: false
-
- - if:
- properties:
- compatible:
- const: airoha,en7581-pcie
- then:
- properties:
- clocks:
- maxItems: 1
-
- clock-names:
- items:
- - const: sys-ck
-
- resets:
- minItems: 3
-
- reset-names:
- items:
- - const: phy-lane0
- - const: phy-lane1
- - const: phy-lane2
-
unevaluatedProperties: false
examples:
--
2.53.0
^ permalink raw reply related
* [PATCH v3 4/4] PCI: mediatek-gen3: Add 2-lanes mode support for Airoha AN7581
From: Christian Marangi @ 2026-06-27 12:14 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ryder Lee, Michael Turquette, Stephen Boyd,
Brian Masney, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi, Jianjun Wang,
linux-pci, devicetree, linux-kernel, linux-mediatek, linux-clk,
linux-arm-kernel
In-Reply-To: <20260627121450.3529133-1-ansuelsmth@gmail.com>
The Airoha AN7581 SoC supports configuring the first PCIe0 lane to 2-lanes
mode (2x link) by bonding it with the second PCIe lane (PCIe1). This is
done by configuring the PCIe MUX in the SCU register.
To correctly configure PCIe0 in 2x link, define in DT the following
additional property:
- additional reg, 'sec-pcie-mac' for the secondary PCIe.
- PERSTOUT reset for both main and secondary PCIE0, called 'perstout' and
'sec-perstout'
- airoha,scu property to correctly configure the SCU register for the PCIe
MUX
- 'num-lanes' set to '2' to enable PCIe0 in 2x link
In such configuration the EQ preset are configured to the same values.
To permit correct configuration of the PCIe line, additional logic is added
to assert and deassert the PERSTOUT resets.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
drivers/pci/controller/pcie-mediatek-gen3.c | 104 ++++++++++++++++----
1 file changed, 87 insertions(+), 17 deletions(-)
diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
index b0accd828589..ba28d95e5d44 100644
--- a/drivers/pci/controller/pcie-mediatek-gen3.c
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -32,6 +32,11 @@
#include "../pci.h"
+/* AN7581 SCU register */
+#define SCU_PCIC 0x88
+#define SCU_PCIC_PCIE_CTRL GENMASK(7, 0)
+
+/* PCIe register */
#define PCIE_BASE_CFG_REG 0x14
#define PCIE_BASE_CFG_SPEED GENMASK(15, 8)
@@ -131,6 +136,7 @@
#define PCIE_ATR_TLP_TYPE_IO PCIE_ATR_TLP_TYPE(2)
#define MAX_NUM_PHY_RESETS 3
+#define MAX_NUM_PERSTOUT_RESETS 2
#define PCIE_MTK_RESET_TIME_US 10
@@ -203,9 +209,11 @@ struct mtk_msi_set {
struct mtk_gen3_pcie {
struct device *dev;
void __iomem *base;
+ void __iomem *sec_base;
phys_addr_t reg_base;
struct reset_control *mac_reset;
struct reset_control_bulk_data phy_resets[MAX_NUM_PHY_RESETS];
+ struct reset_control_bulk_data perstout_resets[MAX_NUM_PERSTOUT_RESETS];
struct phy *phy;
struct clk_bulk_data *clks;
int num_clks;
@@ -928,6 +936,14 @@ static int mtk_pcie_parse_port(struct mtk_gen3_pcie *pcie)
if (ret)
return dev_err_probe(dev, ret, "failed to get PHY bulk reset\n");
+ pcie->perstout_resets[0].id = "perstout";
+ pcie->perstout_resets[1].id = "sec-perstout";
+
+ ret = devm_reset_control_bulk_get_optional_exclusive(dev, MAX_NUM_PERSTOUT_RESETS,
+ pcie->perstout_resets);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to get PERSTOUT bulk reset\n");
+
pcie->mac_reset = devm_reset_control_get_optional_exclusive(dev, "mac");
if (IS_ERR(pcie->mac_reset))
return dev_err_probe(dev, PTR_ERR(pcie->mac_reset), "failed to get MAC reset\n");
@@ -949,18 +965,38 @@ static int mtk_pcie_parse_port(struct mtk_gen3_pcie *pcie)
pcie->num_lanes = num_lanes;
}
+ /* Map secondary PCIe for 2-lanes mode for EN7581 */
+ if (pcie->num_lanes == 2 && device_is_compatible(dev, "airoha,en7581-pcie")) {
+ regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sec-pcie-mac");
+ if (!regs)
+ return -EINVAL;
+ pcie->sec_base = devm_ioremap_resource(dev, regs);
+ if (IS_ERR(pcie->sec_base))
+ return dev_err_probe(dev, PTR_ERR(pcie->sec_base), "failed to map secondary register base\n");
+ }
+
return 0;
}
static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
{
struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
+ unsigned int num_lanes = max(1, pcie->num_lanes);
+ struct regmap *pbus_regmap, *scu;
struct device *dev = pcie->dev;
struct resource_entry *entry;
- struct regmap *pbus_regmap;
u32 val, args[2], size;
resource_size_t addr;
- int err;
+ int i, err;
+
+ if (num_lanes > 2)
+ return dev_err_probe(dev, -EINVAL, "unsupported num-lanes, maximum 2 lanes supported\n");
+
+ if (num_lanes == 2) {
+ scu = syscon_regmap_lookup_by_phandle(dev->of_node, "airoha,scu");
+ if (IS_ERR(scu))
+ return dev_err_probe(dev, PTR_ERR(scu), "failed to map SCU regmap\n");
+ }
/*
* The controller may have been left out of reset by the bootloader
@@ -992,6 +1028,19 @@ static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
size = lower_32_bits(resource_size(entry->res));
regmap_write(pbus_regmap, args[1], GENMASK(31, __fls(size)));
+ /* Assert PERSTOUT for all relevant lines */
+ err = reset_control_bulk_assert(MAX_NUM_PERSTOUT_RESETS,
+ pcie->perstout_resets);
+ if (err) {
+ dev_err(dev, "failed to assert PERSTOUTs\n");
+ return err;
+ }
+
+ /* Configure SCU MUX to disable PCIE1 for 2 lines mode */
+ if (num_lanes == 2)
+ regmap_update_bits(scu, SCU_PCIC, SCU_PCIC_PCIE_CTRL,
+ FIELD_PREP(SCU_PCIC_PCIE_CTRL, BIT(1)));
+
/*
* Unlike the other MediaTek Gen3 controllers, the Airoha EN7581
* requires PHY initialization and power-on before PHY reset deassert.
@@ -1024,18 +1073,6 @@ static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
- val = FIELD_PREP(PCIE_VAL_LN0_DOWNSTREAM, 0x47) |
- FIELD_PREP(PCIE_VAL_LN1_DOWNSTREAM, 0x47) |
- FIELD_PREP(PCIE_VAL_LN0_UPSTREAM, 0x41) |
- FIELD_PREP(PCIE_VAL_LN1_UPSTREAM, 0x41);
- writel_relaxed(val, pcie->base + PCIE_EQ_PRESET_01_REG);
-
- val = PCIE_K_PHYPARAM_QUERY | PCIE_K_QUERY_TIMEOUT |
- FIELD_PREP(PCIE_K_PRESET_TO_USE_16G, 0x80) |
- FIELD_PREP(PCIE_K_PRESET_TO_USE, 0x2) |
- FIELD_PREP(PCIE_K_FINETUNE_MAX, 0xf);
- writel_relaxed(val, pcie->base + PCIE_PIPE4_PIE8_REG);
-
err = clk_bulk_prepare_enable(pcie->num_clks, pcie->clks);
if (err) {
dev_err(dev, "failed to prepare clock\n");
@@ -1043,14 +1080,47 @@ static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
}
/*
- * Airoha EN7581 performs PCIe reset via clk callbacks since it has a
- * hw issue with PCIE_PE_RSTB signal. Add wait for the time needed to
- * complete the PCIe reset.
+ * Old Airoha EN7581 clock driver performed PCIe reset via
+ * clk callbacks since it has a hw issue with PCIE_PE_RSTB signal.
+ * This is now handled by dedicated PERSTOUT resets with clk
+ * driver only enabling the refclk.
+ *
+ * Wait is still needed for refclk to stabilize
*/
msleep(PCIE_T_PVPERL_MS);
+ /* Configure all the lines to the same EQ config */
+ for (i = 0; i < num_lanes; i++) {
+ void __iomem *base = pcie->base;
+
+ if (i == 1)
+ base = pcie->sec_base;
+
+ val = FIELD_PREP(PCIE_VAL_LN0_DOWNSTREAM, 0x47) |
+ FIELD_PREP(PCIE_VAL_LN1_DOWNSTREAM, 0x47) |
+ FIELD_PREP(PCIE_VAL_LN0_UPSTREAM, 0x41) |
+ FIELD_PREP(PCIE_VAL_LN1_UPSTREAM, 0x41);
+ writel_relaxed(val, base + PCIE_EQ_PRESET_01_REG);
+
+ val = PCIE_K_PHYPARAM_QUERY | PCIE_K_QUERY_TIMEOUT |
+ FIELD_PREP(PCIE_K_PRESET_TO_USE_16G, 0x80) |
+ FIELD_PREP(PCIE_K_PRESET_TO_USE, 0x2) |
+ FIELD_PREP(PCIE_K_FINETUNE_MAX, 0xf);
+ writel_relaxed(val, base + PCIE_PIPE4_PIE8_REG);
+ }
+
+ /* Deassert PERSTOUT for all relevant lines */
+ err = reset_control_bulk_deassert(MAX_NUM_PERSTOUT_RESETS,
+ pcie->perstout_resets);
+ if (err) {
+ dev_err(dev, "failed to deassert PERSTOUTs\n");
+ goto err_perstout_deassert;
+ }
+
return 0;
+err_perstout_deassert:
+ clk_bulk_disable_unprepare(pcie->num_clks, pcie->clks);
err_clk_prepare_enable:
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 1/4] dt-bindings: clock: airoha: Add additional reset for PCIe PERSTOUT
From: sashiko-bot @ 2026-06-27 12:19 UTC (permalink / raw)
To: Christian Marangi; +Cc: robh, devicetree, conor+dt, linux-pci
In-Reply-To: <20260627121450.3529133-2-ansuelsmth@gmail.com>
> Add additional reset to control PCIe PERSTOUT reset line for each of the 3
> PCIe lines.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260627121450.3529133-1-ansuelsmth@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sc8280xp: Fix DWC3 core register size
From: Xilin Wu @ 2026-06-27 12:19 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Johan Hovold, Krishna Kurapati
Cc: Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel,
stable
In-Reply-To: <f07dce35-f807-48bd-a04d-76d69ae74f37@oss.qualcomm.com>
On 6/26/2026 11:21 PM, Konrad Dybcio wrote:
> On 6/26/26 5:07 PM, Xilin Wu wrote:
>> The SC8280XP DWC3 core register regions are currently described as 0xcd00
>> bytes, but the hardware register block extends further. In particular, the
>> DWC_usb31 LLUCTL registers start at 0xd024 and are accessed by the DWC3
>> driver when a controller is limited to SuperSpeed using
>> maximum-speed = "super-speed".
>>
>> With the shorter resource, probing such a controller can fault when the
>> driver programs LLUCTL.FORCE_GEN1. Use the correct 0xd950-byte register
>> size for all SC8280XP DWC3 core instances.
>>
>> Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform")
>> Fixes: 3170a2c906c6 ("arm64: dts: qcom: sc8280xp: Add USB DWC3 Multiport controller")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Xilin Wu <sophon@radxa.com>
>> ---
>> arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>> index a2bd6b10e475..d06f79b7680c 100644
>> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>> @@ -4034,7 +4034,7 @@ usb_2: usb@a4f8800 {
>>
>> usb_2_dwc3: usb@a400000 {
>> compatible = "snps,dwc3";
>> - reg = <0 0x0a400000 0 0xcd00>;
>> + reg = <0 0x0a400000 0 0xd950>;
>
> Let's do 0xfc100, the QC glue driver already does out-of-bounds
> accesses into the base+0xfxxx space..
>
> Konrad
>
sc8280xp dwc3 doesn't use the flattened binding. Using 0xfc100 would
make it overlap with the parent glue resource.
--
Best regards,
Xilin Wu <sophon@radxa.com>
^ permalink raw reply
* Re: [PATCH v3 3/4] dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document 2-lanes
From: sashiko-bot @ 2026-06-27 12:21 UTC (permalink / raw)
To: Christian Marangi; +Cc: conor+dt, devicetree, linux-pci, robh
In-Reply-To: <20260627121450.3529133-4-ansuelsmth@gmail.com>
> To permit proper documentation of required property to support PCIe
> configured for 2-lanes mode, split the Airoha schema part from the
> mediatek-gen3 schema to a dedicated schema.
>
> A PCIe configured for 2-lanes mode require an additional reg for the
> secondary PCIe to be configured and the airoha,scu phandle to correctly
> configure the PCIe MUX.
>
> Rework the mediatek-gen3 schema to drop any redundant constraint previsouly
> introduced for Airoha PCIe properties.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260627121450.3529133-1-ansuelsmth@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v3 2/4] clk: en7523: add support for dedicated PCIe PERSTOUT reset
From: sashiko-bot @ 2026-06-27 12:26 UTC (permalink / raw)
To: Christian Marangi; +Cc: linux-pci, robh, conor+dt, devicetree
In-Reply-To: <20260627121450.3529133-3-ansuelsmth@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] The newly added `REG_NP_SCU_PCIC` reset bank shares register `0x88` with the clock framework, causing a cross-subsystem data race.
Pre-existing issues:
- [High] Missing spinlock in reset controller update function leads to intra-bank read-modify-write races between concurrent resets.
- [High] In `en7523_pci_prepare`, a stale local variable is reused for multiple delayed register writes, which will silently overwrite any concurrent changes made by the reset framework.
- [High] The clock `.disable` callback (`en7581_pci_disable`) calls `usleep_range()`, which sleeps while holding the clock framework's IRQ-disabled spinlock.
--
commit 1a24107acd835b1f50aa873616efba12fb4d03d2
Author: Christian Marangi <ansuelsmth@gmail.com>
Subject: clk: en7523: add support for dedicated PCIe PERSTOUT reset
This commit adds support for resetting the PCIe lines using the PERSTOUT
reset, controlled by the PCIC register. It implements inverted logic for
these bits within the reset function. The PCI enable and disable functions
are also updated to drop PERSTOUT bits in favor of this dedicated reset
handling.
> diff --git a/drivers/clk/clk-en7523.c b/drivers/clk/clk-en7523.c
> index 1ab0e2eca5d32..c9b21d9bf2f3f 100644
> --- a/drivers/clk/clk-en7523.c
> +++ b/drivers/clk/clk-en7523.c
[ ... ]
> @@ -650,9 +654,7 @@ static void en7581_pci_disable(struct clk_hw *hw)
> void __iomem *np_base = cg->base;
> u32 val, mask;
>
> - mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1 |
> - REG_PCI_CONTROL_PERSTOUT1 | REG_PCI_CONTROL_PERSTOUT2 |
> - REG_PCI_CONTROL_PERSTOUT;
> + mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1;
> val = readl(np_base + REG_PCI_CONTROL);
> writel(val & ~mask, np_base + REG_PCI_CONTROL);
> usleep_range(1000, 2000);
[Severity: High]
This is a pre-existing issue, but does this sleep cause a bug when called from
atomic context?
The clock framework core invokes .disable callbacks with the global enable_lock
raw spinlock held and local interrupts disabled. Inside en7581_pci_disable,
there is a call to usleep_range().
Could this lead to a system panic or deadlock by sleeping inside an atomic
context? Should this either use an atomic delay like udelay() or be moved to
the .unprepare callback?
[ ... ]
> @@ -754,14 +756,21 @@ static int en7523_reset_update(struct reset_controller_dev *rcdev,
> unsigned long id, bool assert)
> {
> struct en_rst_data *rst_data = container_of(rcdev, struct en_rst_data, rcdev);
> - void __iomem *addr = rst_data->base + rst_data->bank_ofs[id / RST_NR_PER_BANK];
> + u32 offset = rst_data->bank_ofs[id / RST_NR_PER_BANK];
> + void __iomem *addr = rst_data->base + offset;
> + bool inverted = false;
> u32 val;
>
> + /* For PCIC reset logic is inverted, 0:assert 1:deassert*/
> + if (offset == REG_NP_SCU_PCIC)
> + inverted = true;
> +
> val = readl(addr);
> + val &= ~BIT(id % RST_NR_PER_BANK);
> if (assert)
> - val |= BIT(id % RST_NR_PER_BANK);
> + val |= inverted ? 0 : BIT(id % RST_NR_PER_BANK);
> else
> - val &= ~BIT(id % RST_NR_PER_BANK);
> + val |= inverted ? BIT(id % RST_NR_PER_BANK) : 0;
> writel(val, addr);
[Severity: High]
This isn't a bug introduced by this patch, but does this read-modify-write
sequence need a spinlock?
The en7523_reset_update function modifies MMIO registers locklessly. If
different drivers concurrently call reset_control_assert or deassert on the
same reset bank, wouldn't they race and overwrite each other's register
changes?
[Severity: High]
Is there a cross-subsystem data race introduced here by sharing register 0x88
between the clock and reset frameworks?
This patch maps REG_NP_SCU_PCIC (0x88) as a reset controller bank. However,
this same register is mapped as REG_PCI_CONTROL and modified by the clock
framework in en7581_pci_enable.
Since en7581_pci_enable runs under the clock core's enable_lock spinlock, and
en7523_reset_update runs locklessly, will concurrent accesses from these two
paths result in one silently overwriting the other's bit modifications?
[Severity: High]
This is a pre-existing issue, but does en7523_pci_prepare overwrite concurrent
register changes made by the reset framework?
In en7523_pci_prepare, a local variable is reused for multiple delayed register
writes:
drivers/clk/clk-en7523.c:en7523_pci_prepare() {
val = readl(np_base + REG_RESET_CONTROL1);
...
writel(val & ~mask, np_base + REG_RESET_CONTROL1);
usleep_range(1000, 2000);
writel(val | mask, np_base + REG_RESET_CONTROL1);
msleep(100);
writel(val & ~mask, np_base + REG_RESET_CONTROL1);
}
If a device requests a reset on bank 1 (REG_RESET_CONTROL1) during the ~115ms
sleep window, won't the final writel() in en7523_pci_prepare silently overwrite
those state changes using the stale val?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260627121450.3529133-1-ansuelsmth@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v3 4/4] PCI: mediatek-gen3: Add 2-lanes mode support for Airoha AN7581
From: sashiko-bot @ 2026-06-27 12:30 UTC (permalink / raw)
To: Christian Marangi; +Cc: devicetree, conor+dt, robh, linux-pci
In-Reply-To: <20260627121450.3529133-5-ansuelsmth@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [Critical] Modifying the `SCU_PCIC` register via syscon regmap replaces unrelated bits (unintentionally asserting device resets) and races with the clock driver's raw memory accesses.
- [High] The dedicated PERSTOUT resets (perstout_resets) are never asserted during device teardown, leaving PCIe endpoints out of reset.
Pre-existing issues:
- [High] The return value of `pm_runtime_get_sync()` is ignored, potentially leading to hardware access on a suspended device.
- [High] Early returns in `mtk_pcie_en7581_power_up()` leak the `phy_resets` deassert count, permanently breaking hardware initialization on probe retry.
--
commit 13851a15e592cd94ee574eb5716be89f2a065bba
Author: Christian Marangi <ansuelsmth@gmail.com>
Subject: PCI: mediatek-gen3: Add 2-lanes mode support for Airoha AN7581
The Airoha AN7581 SoC supports configuring the first PCIe0 lane to 2-lanes
mode by bonding it with the second PCIe lane. This change configures the
PCIe MUX in the SCU register and adds logic to assert and deassert the
PERSTOUT resets.
> diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
> index b0accd8285892..ba28d95e5d44b 100644
> --- a/drivers/pci/controller/pcie-mediatek-gen3.c
> +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
[ ... ]
> @@ -949,18 +965,38 @@ static int mtk_pcie_parse_port(struct mtk_gen3_pcie *pcie)
> pcie->num_lanes = num_lanes;
> }
>
> + /* Map secondary PCIe for 2-lanes mode for EN7581 */
> + if (pcie->num_lanes == 2 && device_is_compatible(dev, "airoha,en7581-pcie")) {
> + regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sec-pcie-mac");
> + if (!regs)
> + return -EINVAL;
> + pcie->sec_base = devm_ioremap_resource(dev, regs);
> + if (IS_ERR(pcie->sec_base))
> + return dev_err_probe(dev, PTR_ERR(pcie->sec_base), "failed to map secondary register base\n");
> + }
> +
> return 0;
> }
>
> static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
> {
> struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> + unsigned int num_lanes = max(1, pcie->num_lanes);
> + struct regmap *pbus_regmap, *scu;
> struct device *dev = pcie->dev;
> struct resource_entry *entry;
> - struct regmap *pbus_regmap;
> u32 val, args[2], size;
> resource_size_t addr;
> - int err;
> + int i, err;
> +
> + if (num_lanes > 2)
> + return dev_err_probe(dev, -EINVAL, "unsupported num-lanes, maximum 2 lanes supported\n");
> +
> + if (num_lanes == 2) {
> + scu = syscon_regmap_lookup_by_phandle(dev->of_node, "airoha,scu");
> + if (IS_ERR(scu))
> + return dev_err_probe(dev, PTR_ERR(scu), "failed to map SCU regmap\n");
> + }
[Severity: High]
This is a pre-existing issue, but do these early returns leak the
phy_resets deassert count?
If syscon_regmap_lookup_by_phandle() returns -EPROBE_DEFER, or if num_lanes
is greater than 2, this function returns directly to mtk_pcie_setup().
mtk_pcie_setup() does an initial deassert before calling power_up:
mtk_pcie_setup() {
reset_control_bulk_deassert(pcie->soc->phy_resets.num_resets, pcie->phy_resets);
...
err = pcie->soc->power_up(pcie);
if (err)
return err;
}
Since the error path in mtk_pcie_setup() returns without asserting the resets
again, does this leaked reset deassert count on shared resets prevent the
reset controller from physically asserting the line on subsequent probe
attempts, permanently breaking hardware initialization on probe retry?
>
> /*
> * The controller may have been left out of reset by the bootloader
> @@ -992,6 +1028,19 @@ static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
> size = lower_32_bits(resource_size(entry->res));
> regmap_write(pbus_regmap, args[1], GENMASK(31, __fls(size)));
>
> + /* Assert PERSTOUT for all relevant lines */
> + err = reset_control_bulk_assert(MAX_NUM_PERSTOUT_RESETS,
> + pcie->perstout_resets);
> + if (err) {
> + dev_err(dev, "failed to assert PERSTOUTs\n");
> + return err;
> + }
> +
> + /* Configure SCU MUX to disable PCIE1 for 2 lines mode */
> + if (num_lanes == 2)
> + regmap_update_bits(scu, SCU_PCIC, SCU_PCIC_PCIE_CTRL,
> + FIELD_PREP(SCU_PCIC_PCIE_CTRL, BIT(1)));
[Severity: Critical]
Does this regmap_update_bits() call on SCU_PCIC clear unrelated bits and
unintentionally assert device resets?
By using SCU_PCIC_PCIE_CTRL (GENMASK(7, 0)) as the mask to write BIT(1),
this forces bits 0 and 2-7 to 0. Since the clock/reset driver for this SoC
uses this same register to control device resets with inverted logic
(0 = assert, 1 = deassert), does this unintentionally assert the reset for
the PCIE0 controller itself and other peripherals?
Also, since the clock driver uses raw readl()/writel() without a shared
lock, does this introduce a data race that could corrupt the register state?
> +
> /*
> * Unlike the other MediaTek Gen3 controllers, the Airoha EN7581
> * requires PHY initialization and power-on before PHY reset deassert.
> @@ -1024,18 +1073,6 @@ static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
> pm_runtime_enable(dev);
> pm_runtime_get_sync(dev);
[Severity: High]
This isn't a bug introduced by this patch, but is it safe to ignore the
return value of pm_runtime_get_sync() here?
If runtime PM fails to resume the device and returns a negative error code,
this unconditionally proceeds to enable clocks and access hardware registers.
Can accessing registers of a suspended device cause synchronous external
aborts or bus faults resulting in a kernel panic?
>
> - val = FIELD_PREP(PCIE_VAL_LN0_DOWNSTREAM, 0x47) |
> - FIELD_PREP(PCIE_VAL_LN1_DOWNSTREAM, 0x47) |
> - FIELD_PREP(PCIE_VAL_LN0_UPSTREAM, 0x41) |
> - FIELD_PREP(PCIE_VAL_LN1_UPSTREAM, 0x41);
> - writel_relaxed(val, pcie->base + PCIE_EQ_PRESET_01_REG);
> -
> - val = PCIE_K_PHYPARAM_QUERY | PCIE_K_QUERY_TIMEOUT |
> - FIELD_PREP(PCIE_K_PRESET_TO_USE_16G, 0x80) |
> - FIELD_PREP(PCIE_K_PRESET_TO_USE, 0x2) |
> - FIELD_PREP(PCIE_K_FINETUNE_MAX, 0xf);
> - writel_relaxed(val, pcie->base + PCIE_PIPE4_PIE8_REG);
> -
> err = clk_bulk_prepare_enable(pcie->num_clks, pcie->clks);
> if (err) {
> dev_err(dev, "failed to prepare clock\n");
> @@ -1043,14 +1080,47 @@ static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
> }
>
> /*
> - * Airoha EN7581 performs PCIe reset via clk callbacks since it has a
> - * hw issue with PCIE_PE_RSTB signal. Add wait for the time needed to
> - * complete the PCIe reset.
> + * Old Airoha EN7581 clock driver performed PCIe reset via
> + * clk callbacks since it has a hw issue with PCIE_PE_RSTB signal.
> + * This is now handled by dedicated PERSTOUT resets with clk
> + * driver only enabling the refclk.
> + *
> + * Wait is still needed for refclk to stabilize
> */
> msleep(PCIE_T_PVPERL_MS);
>
> + /* Configure all the lines to the same EQ config */
> + for (i = 0; i < num_lanes; i++) {
> + void __iomem *base = pcie->base;
> +
> + if (i == 1)
> + base = pcie->sec_base;
> +
> + val = FIELD_PREP(PCIE_VAL_LN0_DOWNSTREAM, 0x47) |
> + FIELD_PREP(PCIE_VAL_LN1_DOWNSTREAM, 0x47) |
> + FIELD_PREP(PCIE_VAL_LN0_UPSTREAM, 0x41) |
> + FIELD_PREP(PCIE_VAL_LN1_UPSTREAM, 0x41);
> + writel_relaxed(val, base + PCIE_EQ_PRESET_01_REG);
> +
> + val = PCIE_K_PHYPARAM_QUERY | PCIE_K_QUERY_TIMEOUT |
> + FIELD_PREP(PCIE_K_PRESET_TO_USE_16G, 0x80) |
> + FIELD_PREP(PCIE_K_PRESET_TO_USE, 0x2) |
> + FIELD_PREP(PCIE_K_FINETUNE_MAX, 0xf);
> + writel_relaxed(val, base + PCIE_PIPE4_PIE8_REG);
> + }
> +
> + /* Deassert PERSTOUT for all relevant lines */
> + err = reset_control_bulk_deassert(MAX_NUM_PERSTOUT_RESETS,
> + pcie->perstout_resets);
[Severity: High]
Are the perstout_resets missing from the teardown path?
Since they are asserted and deasserted during power up, does the endpoint
remain fully powered on and out of reset while the host controller's PHYs
and clocks are disabled during mtk_pcie_power_down()?
mtk_pcie_power_down() {
clk_bulk_disable_unprepare(pcie->num_clks, pcie->clks);
pm_runtime_put_sync(pcie->dev);
...
phy_power_off(pcie->phy);
phy_exit(pcie->phy);
...
}
This might violate the PCIe specification and leave endpoints active, which
could lead to spurious DMA, fatal bus errors, and system lockups when
unbinding the driver or suspending.
> + if (err) {
> + dev_err(dev, "failed to deassert PERSTOUTs\n");
> + goto err_perstout_deassert;
> + }
> +
> return 0;
>
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260627121450.3529133-1-ansuelsmth@gmail.com?part=4
^ permalink raw reply
* Re: [RFC PATCH net-next v8 03/12] net: phylink: add phylink_release_pcs() to externally release a PCS
From: Christian Marangi @ 2026-06-27 12:33 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <a271385e-302d-45c7-a1df-aebd380b427b@bootlin.com>
On Thu, Jun 25, 2026 at 04:13:14PM +0200, Maxime Chevallier wrote:
> Hello Christian,
>
> On 6/18/26 14:57, Christian Marangi wrote:
> > Add phylink_release_pcs() to externally release a PCS from a phylink
> > instance. This can be used to handle case when a single PCS needs to be
> > removed and the phylink instance needs to be refreshed.
> >
> > On calling phylink_release_pcs(), the PCS will be removed from the
> > phylink internal PCS list and the phylink supported_interfaces value is
> > reparsed with the remaining PCS interfaces.
> >
> > Also a phylink resolve is triggered to handle the PCS removal.
> >
> > The flag force_major_config is set to make phylink resolve reconfigure
> > the interface (even if it didn't change).
> > This is needed to handle the special case when the current PCS used
> > by phylink is removed and a major_config is needed to propagae the
> > configuration change. With this option enabled we also force mac_config
> > even if the PHY link is not up for the in-band case.
> >
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
> > drivers/net/phy/phylink.c | 56 +++++++++++++++++++++++++++++++++++++++
> > include/linux/phylink.h | 2 ++
> > 2 files changed, 58 insertions(+)
> >
> > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> > index c38bcd43b8c8..064d6f5a06da 100644
> > --- a/drivers/net/phy/phylink.c
> > +++ b/drivers/net/phy/phylink.c
> > @@ -158,6 +158,8 @@ static const phy_interface_t phylink_sfp_interface_preference[] = {
> > static DECLARE_PHY_INTERFACE_MASK(phylink_sfp_interfaces);
> >
> > static void phylink_run_resolve(struct phylink *pl);
> > +static void phylink_link_down(struct phylink *pl);
> > +static void phylink_pcs_disable(struct phylink_pcs *pcs);
> >
> > /**
> > * phylink_set_port_modes() - set the port type modes in the ethtool mask
> > @@ -918,6 +920,60 @@ static void phylink_resolve_an_pause(struct phylink_link_state *state)
> > }
> > }
> >
> > +/**
> > + * phylink_release_pcs - Removes a PCS from the phylink PCS available list
> > + * @pcs: a pointer to the phylink_pcs struct to be released
> > + *
> > + * This function release a PCS from the phylink PCS available list if
> > + * actually in use. It also refreshes the supported interfaces of the
> > + * phylink instance by copying the supported interfaces from the phylink
> > + * conf and merging the supported interfaces of the remaining available PCS
> > + * in the list and trigger a resolve.
> > + */
> > +void phylink_release_pcs(struct phylink_pcs *pcs)
> > +{
> > + struct phylink *pl;
> > +
> > + ASSERT_RTNL();
> > +
> > + pl = pcs->phylink;
> > + if (!pl)
> > + return;
> > +
> > + mutex_lock(&pl->state_mutex);
> > +
> > + list_del(&pcs->list);
> > + pcs->phylink = NULL;
> > +
> > + /*
> > + * Check if we are removing the PCS currently
> > + * in use by phylink. If this is the case, tear down
> > + * the link, force phylink resolve to reconfigure the
> > + * interface mode, disable the current PCS and set the
> > + * phylink PCS to NULL.
> > + */
> > + if (pl->pcs == pcs) {
> > + phylink_link_down(pl);
> > + phylink_pcs_disable(pl->pcs);
> > +
> > + pl->force_major_config = true;
> > + pl->pcs = NULL;
> > + }
> > +
> > + mutex_unlock(&pl->state_mutex);
> > +
> > + /* Refresh supported interfaces */
> > + phy_interface_copy(pl->supported_interfaces,
> > + pl->config->supported_interfaces);
> > + list_for_each_entry(pcs, &pl->pcs_list, list)
> > + phy_interface_or(pl->supported_interfaces,
> > + pl->supported_interfaces,
> > + pcs->supported_interfaces);
>
> I've given more thought to that 'supported_interfaces' thing. This
> patchset redefines the meaning of
>
> pl->config->supported_interfaces
>
> Currently, it's filled by the MAC driver and means "Every interface
> we can support, including the ones provided by PCSs that we can use
> with this MAC".
>
> It now becomes "Every interface we support without needing a PCS", at
> least the way I understand that.
>
Wait but with the current code using the OR logic, it still follows
"Every interface we can support...". The modes that needs a PCS are
specificed with the pcs_interfaces mask in phylink_config.
The late add and release operates on the phylink supported_interfaces ONLY
when the MAC didn't specify support for it (by removing it as only the PCS
will declare support for it)
The confusion is present because everything is validated later on
major_config so those supported_interfaces are just an HINT that are later
verified with get_caps and with the pcs_validate OPs.
Adding the supported_interfaces to phylink is really to keep an original
reference of the value. This is to address a pattern I have notice where
the MAC driver always OR the interfaces with the one supported by the PCS.
(I remember it was pointed out by Russell)
But I'm more than open to discussion as this is something marginal to the
whole implementation, I'm also questioning if this OR is actually useful to
anything on the nth tought on this.
One thing that I notice is that parsing this early with AND might be
problematic at phylink_create, but I still have to evaluate that.
My take is that would be good to have some review also on the other logic
as I think I reached a point where Sashiko starts to comments on more or
less unreal problem.
> It's not an error in your code, but I think this is worth documenting
> somewhere as this changes one the things that's already fairly
> error-prone in new drivers.
>
> I don't know to what extent people use that, be we have a porting guide
> that explains how to use phylink in a MAC driver, maybe an update in there
> would be nice as well :
>
> https://docs.kernel.org/networking/sfp-phylink.html#rough-guide-to-converting-a-network-driver-to-sfp-phylink
>
> Maxime
>
>
--
Ansuel
^ permalink raw reply
* Re: [PATCH v2 5/8] dt-bindings: iio: adc: add ti,ads122c14
From: Conor Dooley @ 2026-06-27 14:03 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chris Hall, Patrick Edwards,
Kurt Borja, Nguyen Minh Tien, linux-iio, devicetree, linux-kernel
In-Reply-To: <82294468-c4cf-4003-93f1-31a113c79979@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
On Fri, Jun 26, 2026 at 01:35:22PM -0500, David Lechner wrote:
> >> +required:
> >> + - compatible
> >
> > reg?
>
> I thought reg being required by i2c-controller.yaml was already good enough.
>
> https://github.com/devicetree-org/dt-schema/blob/2203c1720f4ebeebd7f8d10e9dc1812993482fab/dtschema/schemas/i2c/i2c-controller.yaml#L219
Nothing mandates that this is a device on a bus at all without requiring
reg, since that's a schema applied by the parent.
It's unlikely that that will actually occur, but I think properties
mandated by schema that are not referenced in a binding should be
required by the binding.
>
> >
> >> + - avdd-supply
> >> + - dvdd-supply
> >> +
> >> +dependencies:
> >> + refn-supply: [ refp-supply ]
> >> +
> >> +oneOf:
> >> + - required: [ refp-supply ]
> >> + - required: [ "ti,refp-refn-resistor-ohms" ]
> >> + - properties:
> >> + refp-supply: false
> >> + refn-supply: false
> >> + ti,refp-refn-resistor-ohms: false
> >
> > I assume you've tested this to make sure it enforces the behaviour that
> > you want?
>
>
> yes
:)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RFC 00/12] RFC: Devicetree-ACPI hybrid mode
From: Sudeep Holla @ 2026-06-27 14:12 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Hans de Goede, Sudeep Holla, Rafael J . Wysocki, Bjorn Andersson,
Konrad Dybcio, Srinivas Kandagatla, Krzysztof Kozlowski,
Dmitry Baryshkov, Bartosz Golaszewski, Abel Vesa, linux-arm-msm,
devicetree, linux-acpi
In-Reply-To: <obvpvyx3kmzcdc5nxmx4inlpiqugjxdgzfzmdxzfqqy4qqwt7l@y2zyrtso6yk4>
On Fri, Jun 26, 2026 at 11:57:47PM +0300, Dmitry Baryshkov wrote:
> On Fri, Jun 26, 2026 at 04:52:41PM +0100, Sudeep Holla wrote:
> > On Tue, Jun 23, 2026 at 04:52:13PM +0200, Hans de Goede wrote:
> > > Hi All,
> > >
> > > Currently as soon as the kernel boots with a populated DT provided then
> > > the arch/arm64 code sets acpi_disabled=1 and the complete ACPI subsystem
> > > gets disabled. On WoA Snapdragon laptops where the factory Windows OS
> > > actually boots using these tables this is not necessarily desirable.
> > >
> >
> > I am bit lost reading the very first statement here.
> >
> > Who is populating DT and why ? It seems that is the source of the problem.
> >
> > If windows can boot with ACPI tables, why is it causing issues for the
> > Linux kernel, any specifics?
>
> Windows uses a separate beast called PEP, which nobody wanted to
> implement for these platforms up to now. You can find a lot of ACPI
> dumps for these devices at [1].
>
Agreed and I assume that is the reason why we want DT.
> > IOW why is DT populated which creates the problem you are trying to address
> > here.
>
> Most of the laptops resemble other Qualcomm platforms, which use DT for
> hardware description. In some cases, it is the same platform being used
> for both mobile, IoT and laptops. It was more or less natural to reuse
> existing support.
>
Sure, just use DT then, why are we even talking about mixed/hybrid mode.
It gives no incentive to OEMs using PEP to get away from it and use
standard ACPI or improve if anything is missing.
So I don't like this idea of mixing at all. Use ACPI or DT, make up you
mind. You can't expect to get the best of both worlds if you are not improving
the missing parts in either of those. This is just a shortcut.
--
Regards,
Sudeep
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox