* Re: [PATCH v2 4/5] arm64: defconfig: Drop unused Ethernet vendors
From: Geert Uytterhoeven @ 2026-06-19 10:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-kernel, linux-arm-kernel, Catalin Marinas, Will Deacon,
Arnd Bergmann, Alexandre Belloni, Linus Walleij, Drew Fustini,
soc
In-Reply-To: <20260429-defconfig-v2-4-e4ed4186028b@oss.qualcomm.com>
Hi Krzysztof,
On Wed, 29 Apr 2026 at 20:52, Krzysztof Kozlowski
<krzysztof.kozlowski@oss.qualcomm.com> wrote:
> Make going through `make menuconfig` easier by disabling the unused
> Ethernet vendor menu options, where no actual driver for given vendor is
> selected.
>
> Impact checked with comparing old and new autoconf.h:
> diff ... | grep '^-' | grep -v CONFIG_NET_VENDOR
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Thanks for your patch, which is now commit 32379ad4060b6fc0
("arm64: defconfig: Drop unused Ethernet vendors").
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -349,15 +349,33 @@ CONFIG_VIRTIO_NET=y
> CONFIG_MHI_NET=m
> CONFIG_NET_DSA_BCM_SF2=m
> CONFIG_NET_DSA_MSCC_FELIX=m
> +# CONFIG_NET_VENDOR_3COM is not set
> +# CONFIG_NET_VENDOR_ACTIONS is not set
> +# CONFIG_NET_VENDOR_ADAPTEC is not set
> +# CONFIG_NET_VENDOR_AGERE is not set
> +# CONFIG_NET_VENDOR_ALACRITECH is not set
> +# CONFIG_NET_VENDOR_ALLWINNER is not set
[...]
I am not sure this new policy is a good idea: none of this affects
actual kernel size, but it does increase defconfig size, and churn.
E.g. for the m68k defconfig, I dropped all these disablements
several years ago.
I don't use menufconfig, so just my 2€c...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v4 2/2] media: i2c: ov5640: Add reset controller support with GPIO fallback
From: robby.cai @ 2026-06-19 10:05 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam,
sebastian.krzyszkowiak, slongerbeam, sakari.ailus, mchehab,
p.zabel, kieran.bingham
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260619100532.3779934-1-robby.cai@oss.nxp.com>
From: Robby Cai <robby.cai@nxp.com>
Add support for the reset controller framework by acquiring the reset
line using devm_reset_control_get_optional_shared_deasserted(). This
allows the driver to handle reset lines provided by a reset controller,
including shared ones, while avoiding unbalanced deassert counts.
Retain support for legacy reset-gpios as a fallback when no reset
controller is defined. In that case, request the GPIO and keep it in the
deasserted state as the initial configuration.
This enables the driver to support both reset-controller-backed reset
lines and older GPIO-based descriptions while preserving the existing
power-up sequencing behavior.
Signed-off-by: Robby Cai <robby.cai@nxp.com>
---
drivers/media/i2c/ov5640.c | 80 +++++++++++++++++++++++++++++++++-----
1 file changed, 70 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 85ecc23b3587..5e6db8aacb11 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -17,6 +17,7 @@
#include <linux/module.h>
#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
#include <linux/slab.h>
#include <linux/types.h>
#include <media/v4l2-async.h>
@@ -442,6 +443,7 @@ struct ov5640_dev {
u32 xclk_freq;
struct regulator_bulk_data supplies[OV5640_NUM_SUPPLIES];
+ struct reset_control *reset;
struct gpio_desc *reset_gpio;
struct gpio_desc *pwdn_gpio;
bool upside_down;
@@ -2431,6 +2433,48 @@ static int ov5640_restore_mode(struct ov5640_dev *sensor)
return ov5640_set_framefmt(sensor, &sensor->fmt);
}
+static int ov5640_get_reset(struct device *dev, struct ov5640_dev *sensor)
+{
+ /* use deasserted version to avoid unbalanced deassert counts */
+ sensor->reset =
+ devm_reset_control_get_optional_shared_deasserted(dev, NULL);
+ if (IS_ERR(sensor->reset))
+ return dev_err_probe(dev, PTR_ERR(sensor->reset),
+ "Failed to get reset\n");
+ else if (sensor->reset)
+ return 0;
+
+ /*
+ * fallback to legacy reset-gpios
+ * GPIOD_OUT_HIGH ensures deasserted state for ACTIVE_LOW reset
+ */
+ sensor->reset_gpio = devm_gpiod_get_optional(dev, "reset",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(sensor->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(sensor->reset_gpio),
+ "Failed to get reset gpio");
+
+ return 0;
+}
+
+static int ov5640_reset_assert(struct ov5640_dev *sensor)
+{
+ if (sensor->reset)
+ return reset_control_assert(sensor->reset);
+
+ gpiod_set_value_cansleep(sensor->reset_gpio, 1);
+ return 0;
+}
+
+static int ov5640_reset_deassert(struct ov5640_dev *sensor)
+{
+ if (sensor->reset)
+ return reset_control_deassert(sensor->reset);
+
+ gpiod_set_value_cansleep(sensor->reset_gpio, 0);
+ return 0;
+}
+
static void ov5640_power(struct ov5640_dev *sensor, bool enable)
{
gpiod_set_value_cansleep(sensor->pwdn_gpio, enable ? 0 : 1);
@@ -2448,12 +2492,19 @@ static void ov5640_power(struct ov5640_dev *sensor, bool enable)
*
* In such cases, this gpio should be mapped to pwdn_gpio in the driver, and we
* should still toggle the pwdn_gpio below with the appropriate delays, while
- * the calls to reset_gpio will be ignored.
+ * reset handling (via reset controller or GPIO) will be ignored.
*/
-static void ov5640_powerup_sequence(struct ov5640_dev *sensor)
+static int ov5640_powerup_sequence(struct ov5640_dev *sensor)
{
+ int ret;
+
if (sensor->pwdn_gpio) {
- gpiod_set_value_cansleep(sensor->reset_gpio, 1);
+ ret = ov5640_reset_assert(sensor);
+ if (ret) {
+ dev_err(&sensor->i2c_client->dev,
+ "Failed to assert reset: %d\n", ret);
+ return ret;
+ }
/* camera power cycle */
ov5640_power(sensor, false);
@@ -2461,7 +2512,13 @@ static void ov5640_powerup_sequence(struct ov5640_dev *sensor)
ov5640_power(sensor, true);
usleep_range(1000, 2000); /* t3 */
- gpiod_set_value_cansleep(sensor->reset_gpio, 0);
+ ret = ov5640_reset_deassert(sensor);
+ if (ret) {
+ dev_err(&sensor->i2c_client->dev,
+ "Failed to deassert reset: %d\n", ret);
+ ov5640_power(sensor, false);
+ return ret;
+ }
} else {
/* software reset */
ov5640_write_reg(sensor, OV5640_REG_SYS_CTRL0,
@@ -2475,6 +2532,8 @@ static void ov5640_powerup_sequence(struct ov5640_dev *sensor)
*/
ov5640_write_reg(sensor, OV5640_REG_SYS_CTRL0,
OV5640_REG_SYS_CTRL0_SW_PWDN);
+
+ return 0;
}
static int ov5640_set_power_on(struct ov5640_dev *sensor)
@@ -2497,7 +2556,9 @@ static int ov5640_set_power_on(struct ov5640_dev *sensor)
goto xclk_off;
}
- ov5640_powerup_sequence(sensor);
+ ret = ov5640_powerup_sequence(sensor);
+ if (ret)
+ goto regulator_off;
ret = ov5640_init_slave_id(sensor);
if (ret)
@@ -2507,6 +2568,7 @@ static int ov5640_set_power_on(struct ov5640_dev *sensor)
power_off:
ov5640_power(sensor, false);
+regulator_off:
regulator_bulk_disable(OV5640_NUM_SUPPLIES, sensor->supplies);
xclk_off:
clk_disable_unprepare(sensor->xclk);
@@ -3914,11 +3976,9 @@ static int ov5640_probe(struct i2c_client *client)
if (IS_ERR(sensor->pwdn_gpio))
return PTR_ERR(sensor->pwdn_gpio);
- /* request optional reset pin */
- sensor->reset_gpio = devm_gpiod_get_optional(dev, "reset",
- GPIOD_OUT_HIGH);
- if (IS_ERR(sensor->reset_gpio))
- return PTR_ERR(sensor->reset_gpio);
+ ret = ov5640_get_reset(dev, sensor);
+ if (ret)
+ return ret;
v4l2_i2c_subdev_init(&sensor->sd, client, &ov5640_subdev_ops);
sensor->sd.internal_ops = &ov5640_internal_ops;
--
2.50.1
^ permalink raw reply related
* [PATCH v4 1/2] arm64: dts: imx8mq-evk: Add OV5640 camera support via overlays
From: robby.cai @ 2026-06-19 10:05 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam,
sebastian.krzyszkowiak, slongerbeam, sakari.ailus, mchehab,
p.zabel, kieran.bingham
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260619100532.3779934-1-robby.cai@oss.nxp.com>
From: Robby Cai <robby.cai@nxp.com>
Add overlays for single and dual camera setups on CSI1 and CSI2, enabling
the following media pipelines:
- OV5640 (I2C2) -> MIPI CSI1 -> CSI1 bridge
- OV5640 (I2C1) -> MIPI CSI2 -> CSI2 bridge
On the i.MX8MQ EVK, both sensors share a common reset GPIO, while each
sensor has an independent powerdown (PWDN) GPIO.
Both sensors also share the same MCLK source (CLKO2), configured
identically as required by the hardware design.
Signed-off-by: Robby Cai <robby.cai@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 7 ++
.../dts/freescale/imx8mq-evk-ov5640-csi1.dtso | 69 +++++++++++++++++++
.../dts/freescale/imx8mq-evk-ov5640-csi2.dtso | 65 +++++++++++++++++
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 50 ++++++++++++++
4 files changed, 191 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 8ddaab127ab9..8507cbdb5556 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -501,6 +501,13 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
imx8mq-evk-pcie1-ep-dtbs += imx8mq-evk.dtb imx-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk-pcie1-ep.dtb
+imx8mq-evk-ov5640-csi1-dtbs := imx8mq-evk.dtb imx8mq-evk-ov5640-csi1.dtbo
+dtb-${CONFIG_ARCH_MXC} += imx8mq-evk-ov5640-csi1.dtb
+imx8mq-evk-ov5640-csi2-dtbs := imx8mq-evk.dtb imx8mq-evk-ov5640-csi2.dtbo
+dtb-${CONFIG_ARCH_MXC} += imx8mq-evk-ov5640-csi2.dtb
+imx8mq-evk-ov5640-dual-dtbs := imx8mq-evk.dtb imx8mq-evk-ov5640-csi1.dtbo imx8mq-evk-ov5640-csi2.dtbo
+dtb-${CONFIG_ARCH_MXC} += imx8mq-evk-ov5640-dual.dtb
+
dtb-$(CONFIG_ARCH_MXC) += imx8mq-hummingboard-pulse.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-kontron-pitx-imx8m.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk-ov5640-csi1.dtso b/arch/arm64/boot/dts/freescale/imx8mq-evk-ov5640-csi1.dtso
new file mode 100644
index 000000000000..1e9931802cdc
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk-ov5640-csi1.dtso
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/imx8mq-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/media/video-interfaces.h>
+
+&csi1 {
+ status = "okay";
+};
+
+&i2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_camera1_pwdn>;
+ clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ clock-names = "xclk";
+ assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
+ assigned-clock-rates = <20000000>;
+ powerdown-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 6 GPIO_ACTIVE_LOW>;
+ DOVDD-supply = <&sw4_reg>;
+ AVDD-supply = <®_2v8>;
+ DVDD-supply = <®_1v5>;
+
+ port {
+ camera1_ep: endpoint {
+ remote-endpoint = <&mipi_csi1_in_ep>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&mipi_csi1 {
+ assigned-clock-rates = <266000000>, <200000000>, <66000000>;
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mipi_csi1_in_ep: endpoint {
+ remote-endpoint = <&camera1_ep>;
+ data-lanes = <1 2>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ };
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk-ov5640-csi2.dtso b/arch/arm64/boot/dts/freescale/imx8mq-evk-ov5640-csi2.dtso
new file mode 100644
index 000000000000..fd247b3b5982
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk-ov5640-csi2.dtso
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/imx8mq-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/media/video-interfaces.h>
+
+&csi2 {
+ status = "okay";
+};
+
+&i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_camera2_pwdn>;
+ clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ clock-names = "xclk";
+ assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
+ assigned-clock-rates = <20000000>;
+ powerdown-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 6 GPIO_ACTIVE_LOW>;
+ DOVDD-supply = <&sw4_reg>;
+ AVDD-supply = <®_2v8>;
+ DVDD-supply = <®_1v5>;
+
+ port {
+ camera2_ep: endpoint {
+ remote-endpoint = <&mipi_csi2_in_ep>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&mipi_csi2 {
+ assigned-clock-rates = <266000000>, <200000000>, <66000000>;
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mipi_csi2_in_ep: endpoint {
+ remote-endpoint = <&camera2_ep>;
+ data-lanes = <1 2>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ };
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index e7d87ea81b69..d8c139c9128d 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -50,6 +50,20 @@ reg_usdhc2_vmmc: regulator-vsd-3v3 {
enable-active-high;
};
+ reg_1v5: regulator-1v5 {
+ compatible = "regulator-fixed";
+ regulator-name = "DVDD_1V5";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ };
+
+ reg_2v8: regulator-2v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "AVDD_2V8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
buck2_reg: regulator-buck2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_buck2>;
@@ -542,12 +556,34 @@ &wdog1 {
};
&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mclk>, <&pinctrl_camera_reset>;
+
pinctrl_buck2: vddarmgrp {
fsl,pins = <
MX8MQ_IOMUXC_GPIO1_IO13_GPIO1_IO13 0x19
>;
};
+ pinctrl_camera1_pwdn: camera1pwdngrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x19
+ >;
+ };
+
+ pinctrl_camera2_pwdn: camera2pwdngrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x19
+ >;
+ };
+
+ /* Shared reset line for cameras on CSI1 and CSI2. */
+ pinctrl_camera_reset: cameraresetgrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO06_GPIO1_IO6 0x19
+ >;
+ };
+
pinctrl_fec1: fec1grp {
fsl,pins = <
MX8MQ_IOMUXC_ENET_MDC_ENET1_MDC 0x3
@@ -575,12 +611,26 @@ MX8MQ_IOMUXC_I2C1_SDA_I2C1_SDA 0x4000007f
>;
};
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C2_SCL_I2C2_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C2_SDA_I2C2_SDA 0x4000007f
+ >;
+ };
+
pinctrl_ir: irgrp {
fsl,pins = <
MX8MQ_IOMUXC_GPIO1_IO12_GPIO1_IO12 0x4f
>;
};
+ /* Shared MCLK for cameras on CSI1 and CSI2. */
+ pinctrl_mclk: mclkgrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO15_CCMSRCGPCMIX_CLKO2 0x59
+ >;
+ };
+
pinctrl_mipi_dsi: mipidsigrp {
fsl,pins = <
MX8MQ_IOMUXC_ECSPI1_SCLK_GPIO5_IO6 0x16
--
2.50.1
^ permalink raw reply related
* [PATCH v4 0/2] imx8mq-evk and ov5640: Add overlay-based camera support with shared reset handling
From: robby.cai @ 2026-06-19 10:05 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam,
sebastian.krzyszkowiak, slongerbeam, sakari.ailus, mchehab,
p.zabel, kieran.bingham
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel
From: Robby Cai <robby.cai@nxp.com>
This series enables OV5640 camera support on the i.MX8MQ EVK using
device tree overlays, including single- and dual-camera configurations.
The DT overlays describe two OV5640 sensors connected to different
MIPI CSI-2 interfaces:
- OV5640 (I2C2) -> MIPI CSI1 -> CSI1 bridge
- OV5640 (I2C1) -> MIPI CSI2 -> CSI2 bridge
On this platform, both sensors share a common reset GPIO line, while
each has an independent powerdown (PWDN) GPIO. Due to this hardware
constraint, proper handling of the shared reset line is required when
both cameras are present.
To address this, the OV5640 driver is updated to use the reset controller
framework, allowing it to correctly support shared reset lines. Legacy
reset-gpios support is retained as a fallback when no reset controller
is defined, ensuring compatibility with existing device tree
descriptions without requiring changes.
Note:
1) With commit 8f040b5c5e3a ("leds: class: Use firmware nodes for device lookup"),
the OV5640 driver reports the following errors:
[ 11.373844] ov5640 0-003c: error -EINVAL: getting privacy LED
[ 11.376442] ov5640 0-003c: probe with driver ov5640 failed with error -22
[ 11.906977] ov5640 1-003c: error -EINVAL: getting privacy LED
[ 11.909793] ov5640 1-003c: probe with driver ov5640 failed with error -22
This issue has been reported and discussed in [1] and related threads.
As a temporary workaround for testing OV5640, the patch can be reverted.
Link [1]: https://lore.kernel.org/all/aignTNlK5kCLmQ2A@tom-desktop/
2) The patch at:
https://lore.kernel.org/imx/20260619073115.3778313-1-robby.cai@oss.nxp.com/
is also required for OV5640 to function properly on the i.MX8MQ EVK.
Changes in v4:
- Switch EVK camera support to DT overlays for CSI1/CSI2/dual configurations (Kieran Bingham)
- Convert OV5640 driver to use reset controller framework with GPIO fallback (sashiko)
- Ensure correct handling of reset line (sashiko)
Link to v3: https://lore.kernel.org/imx/20260529132334.3333294-1-robby.cai@nxp.com/
Changes in v3:
- Add OV5640 driver changes to use reset control framework for shared reset
- Drop GPIO hog for reset in DTS
Link to v2: https://lore.kernel.org/imx/20260515111143.2980956-1-robby.cai@nxp.com/
Changes in v2:
- Address comments on MIPI clock configuration (Frank, Sebastian):
drop the first patch and consolidate the correct clock configuration
into the second patch
- Address comments from sashiko:
* Use MEDIA_BUS_TYPE_CSI2_DPHY instead of a literal value
* Fix a probe-order dependency related to reset handling. Switch to
software reset, as the shared hardware reset line prevents
independent reset when both cameras are enabled due to a board
design limitation
* Fix incorrect voltage value in the reg_2v8 node
Link to v1: https://lore.kernel.org/imx/20260417110200.753678-1-robby.cai@nxp.com/
Signed-off-by: Robby Cai <robby.cai@nxp.com>
Robby Cai (2):
arm64: dts: imx8mq-evk: Add OV5640 camera support via overlays
media: i2c: ov5640: Add reset controller support with GPIO fallback
arch/arm64/boot/dts/freescale/Makefile | 7 ++
.../dts/freescale/imx8mq-evk-ov5640-csi1.dtso | 69 ++++++++++++++++
.../dts/freescale/imx8mq-evk-ov5640-csi2.dtso | 65 +++++++++++++++
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 50 ++++++++++++
drivers/media/i2c/ov5640.c | 80 ++++++++++++++++---
5 files changed, 261 insertions(+), 10 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-evk-ov5640-csi1.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-evk-ov5640-csi2.dtso
--
2.50.1
^ permalink raw reply
* Re: [PATCH v2 3/6] arm64: dts: qcom: kodiak: Add GEM_NOC interconnect for adreno SMMU
From: Bibek Kumar Patro @ 2026-06-19 9:51 UTC (permalink / raw)
To: Konrad Dybcio, Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <3384ecdf-599f-4862-a3c4-9f54b4ddfe63@oss.qualcomm.com>
On 6/18/2026 2:56 PM, Konrad Dybcio wrote:
> On 6/8/26 4:37 PM, Bibek Kumar Patro wrote:
>>
>>
>> On 6/8/2026 7:27 PM, Dmitry Baryshkov wrote:
>>> On Tue, May 26, 2026 at 08:12:04PM +0530, Bibek Kumar Patro wrote:
>>>> On Kodiak platforms, the Adreno SMMU requires a bandwidth vote on
>>>> the GEM_NOC path (MASTER_GPU_TCU -> SLAVE_EBI1) before its registers
>>>> are accessible. Without this vote, the SMMU may become unreachable,
>>>> leading to intermittent probe failures and runtime issues.
>>>>
>>>> Add the required interconnect to ensure reliable register access.
>>>
>>> Does it only concern the GPU SMMU? What about the APPS SMMU? Should it
>>> be voting on other interconnects too? I guess so, because currently I
>>> see that TBUs vote for various interconnects. BTW: should apps_smmu also
>>> vote on the power domains?
>>>
>>
>> This race mainly occurs in GPU SMMU, where the GDSC can have an
>
> Mainly or exclusively?
>
It is exclusively in GPU SMMU as of now. We haven't seen any instance on
other SMMU, e.g pcie AMMU, APPS SMMU.
Also as per my understanding of the architecture which i mentioned
earlier [1], this issue will only arise in GPU SMMU.
Thanks & regards,
Bibek
> Konrad
>
>> independent vote on the Adreno SMMU. However, the GEM_NOC vote may
>> already have been removed by the GPU (or any consumer of adreno_smmu,
>> e.g gmu), unless it is explicitly voted by the GPU SMMU (which acts as a
>> supplier for the GPU). This mismatch can lead to SHUB timeouts or NoC
>> errors.
>>
>> Mostly this race reported in suspend/resume cycle (when gpu/gmu devices moves to slumber/suspend state before adreno_smmu powers down
>> and the later doesn't have explicit interconnect voting).
>>
>> In the case of APPS SMMU, such a race is not expected for any known
>> use case. APPS SMMU is part of a shared infrastructure block, and its
>> power is typically kept enabled as long as attached master devices are
>> active. Therefore, explicit power-domain voting from APPS SMMU may not
>> be required.
>>
[1]
>> Thanks,
>> Bibek
>>
>>
>>>>
>>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> index fa540d8c2615dc02d941eb16bc7253204c2750bd..eefa4b836a81374ff437ab4bbcbc3fecc1590ab6 100644
>>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> @@ -3386,6 +3386,8 @@ adreno_smmu: iommu@3da0000 {
>>>> power-domains = <&gpucc GPU_CC_CX_GDSC>;
>>>> dma-coherent;
>>>> + interconnects = <&gem_noc MASTER_GPU_TCU QCOM_ICC_TAG_ALWAYS
>>>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
>>>> };
>>>> gfx_0_tbu: tbu@3dd9000 {
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>>
>>
>>
^ permalink raw reply
* [PATCH v2 0/3] phy: rockchip: inno-csidphy: fix 2500 Mbps support and add clock lane phase tuning
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
This series fixes and extends the Rockchip Innosilicon CSI D-PHY driver
to support data rates up to 2500 Mbps and adds optional board-specific
clock lane phase tuning for signal integrity.
Patch 1 fixes an off-by-one error in the rk1808 hsfreq range table:
the final entry was capped at 2499 Mbps, causing a rejection of the
maximum supported rate of 2500 Mbps.
Patches 2 and 3 add an optional rockchip,clk-lane-phase device tree
property that allows tuning the clock lane sampling phase in ~40 ps
steps to compensate for board-level signal integrity variations.
---
Changes in v2:
- dt-bindings: improve rockchip,clk-lane-phase description wording
(Conor Dooley)
- Link to v1: https://patch.msgid.link/20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@wolfvision.net
To: Vinod Koul <vkoul@kernel.org>
To: Neil Armstrong <neil.armstrong@linaro.org>
To: Heiko Stuebner <heiko@sntech.de>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: linux-phy@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Gerald Loacker (3):
phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
.../bindings/phy/rockchip-inno-csi-dphy.yaml | 9 ++++++++
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 27 +++++++++++++++++++++-
2 files changed, 35 insertions(+), 1 deletion(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260617-feature-mipi-csi-dphy-4k60-9879c3d1fe4f
Best regards,
--
Gerald Loacker <gerald.loacker@wolfvision.net>
^ permalink raw reply
* Re: [PATCH RFC 1/3] cpu/hotplug: Introduce CONFIG_PARALLEL_SMT_PRIMARY_FIRST
From: Peter Zijlstra @ 2026-06-19 9:41 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Jinjie Ruan, catalin.marinas, will, tsbogend, pjw, palmer, aou,
alex, mingo, bp, dave.hansen, hpa, kees, nathan, linusw, ojeda,
david.kaplan, lukas.bulwahn, ryan.roberts, maz, timothy.hayes,
lpieralisi, thuth, oupton, yeoreum.yun, miko.lenczewski, broonie,
kevin.brodsky, james.clark, tabba, mrigendra.chaubey, arnd,
anshuman.khandual, x86, linux-kernel, linux-arm-kernel,
linux-mips, linux-riscv
In-Reply-To: <87a4srdgk0.ffs@fw13>
On Thu, Jun 18, 2026 at 05:17:03PM +0200, Thomas Gleixner wrote:
> Something simple like the uncompiled below should just work, no?
>
> ---
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -102,6 +102,10 @@ config HOTPLUG_PARALLEL
> bool
> select HOTPLUG_SPLIT_STARTUP
>
> +config HOTPLUG_PARALLEL_SMT
> + bool
> + select HOTPLUG_PARALLEL
depends on ARCH_SUPPORTS_SCHED_SMT ?
^ permalink raw reply
* [PATCH v2 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net>
Add support for the optional rockchip,clk-lane-phase device tree property
to allow board-specific tuning of the clock lane sampling phase for
improved signal integrity across supported data rates.
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
.../devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
index 03950b3cad08c..010950a8a8856 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
@@ -56,6 +56,15 @@ properties:
description:
Some additional phy settings are access through GRF regs.
+ rockchip,clk-lane-phase:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+ description:
+ Clock lane sampling phase selection (hardware tap index 0–7). Each step
+ corresponds to an approximately 40 ps delay as described in the hardware
+ specification.
+
required:
- compatible
- reg
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net 2/2] net: airoha: fix netif_set_real_num_tx_queues for sparse QoS channels
From: Simon Horman @ 2026-06-19 9:35 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wayen Yan, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260618-airoha-qos-fixes-v1-2-37192652157f@kernel.org>
On Thu, Jun 18, 2026 at 08:00:30AM +0200, Lorenzo Bianconi wrote:
> airoha_tc_htb_alloc_leaf_queue() assigns queue IDs based on the channel
> index (opt->qid = AIROHA_NUM_TX_RING + channel), but updates
> real_num_tx_queues with a simple increment (num_tx_queues + 1). When QoS
> channels are allocated sparsely (e.g., channels 0 and 3 without 1 and
> 2), the returned qid can exceed real_num_tx_queues, causing out-of-bounds
> accesses in the networking stack.
> For example, allocating channel 0 then channel 3 results in
> real_num_tx_queues = 34 but qid = 35, which is out of range [0, 34).
> Fix this by computing real_num_tx_queues based on the highest active
> channel index rather than using a simple counter, in both the allocation
> and deletion paths.
>
> Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
...
> @@ -2806,7 +2806,10 @@ static int airoha_tc_htb_alloc_leaf_queue(struct net_device *netdev,
> if (err)
> goto error;
>
> - err = netif_set_real_num_tx_queues(netdev, num_tx_queues + 1);
> + if (num_tx_queues <= netdev->real_num_tx_queues)
> + goto set_qos_sq_bmap;
> +
> + err = netif_set_real_num_tx_queues(netdev, num_tx_queues);
> if (err) {
> airoha_qdma_set_tx_rate_limit(netdev, channel, 0,
> opt->quantum);
> @@ -2815,6 +2818,7 @@ static int airoha_tc_htb_alloc_leaf_queue(struct net_device *netdev,
> goto error;
> }
>
> +set_qos_sq_bmap:
I would prefer if this could be achieved without a goto.
> set_bit(channel, dev->qos_sq_bmap);
> opt->qid = AIROHA_NUM_TX_RING + channel;
>
...
^ permalink raw reply
* Re: [PATCH net 1/2] net: airoha: Fix off-by-one in airoha_tc_remove_htb_queue()
From: Simon Horman @ 2026-06-19 9:34 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wayen Yan, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260618-airoha-qos-fixes-v1-1-37192652157f@kernel.org>
On Thu, Jun 18, 2026 at 08:00:29AM +0200, Lorenzo Bianconi wrote:
> airoha_tc_htb_alloc_leaf_queue() computes the HTB QoS channel index
> as opt->classid % AIROHA_NUM_QOS_CHANNELS and stores it in qos_sq_bmap.
> However, airoha_tc_remove_htb_queue() clears the HTB configuration
> using queue + 1 as the channel index, causing an off-by-one error.
> Use queue directly as the QoS channel index to match the allocation
> logic.
>
> Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: errata: Handle Apple WFI State Loss
From: Will Deacon @ 2026-06-19 9:24 UTC (permalink / raw)
To: Yureka Lilian
Cc: Catalin Marinas, linux-arm-kernel, linux-kernel, asahi,
Sasha Finkelstein
In-Reply-To: <e105c7b2-a5eb-4b5d-955f-685058143e9d@cyberchaos.dev>
On Wed, Jun 17, 2026 at 09:23:03PM +0200, Yureka Lilian wrote:
> On 6/15/26 17:02, Will Deacon wrote:
> > In fact, would wfe be a better choice than nop for you?
>
> Regarding wfe: Simply replacing the wfi with wfe on these particular
> machines leads to them getting stuck in the boot process (entering wfe on
> the boot core and never waking up again), maybe because some kinds of
> interrupts do not count as as events for the wfe wake-up?
argh, I had forgotten that a pending masked interrupt doesn't wake up
a WFE (it does wake up a WFI).
So we probably shouldn't have wfe in the list of idle instruction choices
(unless we want to rely on the eventstream).
Will
^ permalink raw reply
* [PATCH v2 3/3] phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net>
At high data rates like 4K60 (2500 Mbps), such as when using an
LT6911GXD bridge chip on an RK3588 board, fixed default timing parameters
can cause signal integrity issues and clock-data recovery failures.
The driver currently lacks a mechanism to adjust the clock lane sampling
phase to compensate for board-specific trace variations.
Resolve this by parsing and applying the optional 'rockchip,clk-lane-phase'
device tree property. This enables board-specific tuning of the clock
lane sampling phase in ~40 ps steps (range 0-7) to optimize link
stability. If the property is absent, the driver falls back to the
hardware default.
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 25 ++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
index 5281f8dea0ad3..3a15840e86cad 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
@@ -69,6 +69,10 @@
#define RK1808_CSIDPHY_CLK_CALIB_EN 0x168
#define RK3568_CSIDPHY_CLK_CALIB_EN 0x168
+#define CSIDPHY_LANE_CLK_3_PHASE 0x38
+#define CSIDPHY_CLK_PHASE_MASK GENMASK(6, 4)
+#define CSIDPHY_CLK_PHASE_DEFAULT 3
+
#define RESETS_MAX 2
/*
@@ -151,6 +155,7 @@ struct rockchip_inno_csidphy {
const struct dphy_drv_data *drv_data;
struct phy_configure_opts_mipi_dphy config;
u8 hsfreq;
+ int clk_phase;
};
static inline void write_grf_reg(struct rockchip_inno_csidphy *priv,
@@ -304,6 +309,13 @@ static int rockchip_inno_csidphy_power_on(struct phy *phy)
rockchip_inno_csidphy_ths_settle(priv, priv->hsfreq,
CSIDPHY_LANE_THS_SETTLE(i));
+ if (priv->clk_phase >= 0) {
+ val = readl(priv->phy_base + CSIDPHY_LANE_CLK_3_PHASE);
+ val &= ~CSIDPHY_CLK_PHASE_MASK;
+ val |= FIELD_PREP(CSIDPHY_CLK_PHASE_MASK, priv->clk_phase);
+ writel(val, priv->phy_base + CSIDPHY_LANE_CLK_3_PHASE);
+ }
+
write_grf_reg(priv, GRF_DPHY_CSIPHY_CLKLANE_EN, 0x1);
write_grf_reg(priv, GRF_DPHY_CSIPHY_DATALANE_EN,
GENMASK(priv->config.lanes - 1, 0));
@@ -449,6 +461,7 @@ static int rockchip_inno_csidphy_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct phy_provider *phy_provider;
struct phy *phy;
+ u32 phase;
int ret;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -464,6 +477,18 @@ static int rockchip_inno_csidphy_probe(struct platform_device *pdev)
return -ENODEV;
}
+ priv->clk_phase = -1;
+ if (device_property_read_u32(dev, "rockchip,clk-lane-phase",
+ &phase) == 0) {
+ if (phase >= BIT(3)) {
+ dev_err(dev,
+ "rockchip,clk-lane-phase %u out of range [0,7]\n",
+ phase);
+ return -EINVAL;
+ }
+ priv->clk_phase = phase;
+ }
+
priv->grf = syscon_regmap_lookup_by_phandle(dev->of_node,
"rockchip,grf");
if (IS_ERR(priv->grf)) {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/3] phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net>
The rk1808 hsfreq table capped at 2499 Mbps, preventing a data rate of
exactly 2500 Mbps. Extend the final entry to 2500 Mbps to support this
rate.
This is essential for RK3588 reusing this array and fully supporting
rates up to 2500 Mbps.
Fixes: bd1f775d6027 ("phy/rockchip: add Innosilicon-based CSI dphy")
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
index c79fb53d8ee5c..5281f8dea0ad3 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
@@ -170,7 +170,7 @@ static const struct hsfreq_range rk1808_mipidphy_hsfreq_ranges[] = {
{ 299, 0x06}, { 399, 0x08}, { 499, 0x0b}, { 599, 0x0e},
{ 699, 0x10}, { 799, 0x12}, { 999, 0x16}, {1199, 0x1e},
{1399, 0x23}, {1599, 0x2d}, {1799, 0x32}, {1999, 0x37},
- {2199, 0x3c}, {2399, 0x41}, {2499, 0x46}
+ {2199, 0x3c}, {2399, 0x41}, {2500, 0x46}
};
static const struct hsfreq_range rk3326_mipidphy_hsfreq_ranges[] = {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 15/78] ASoC: codecs: cs42l43: Use guard() for mutex locks
From: David Laight @ 2026-06-19 9:13 UTC (permalink / raw)
To: Bui Duc Phuc
Cc: Charles Keepax, Mark Brown, Liam Girdwood, Jaroslav Kysela,
Takashi Iwai, Cheng-Yi Chiang, Tzung-Bi Shih, Guenter Roeck,
Benson Leung, David Rhodes, Richard Fitzgerald, povik+lin,
Support Opensource, Nick Li, Herve Codina, Srinivas Kandagatla,
Matthias Brugger, AngeloGioacchino Del Regno, Shenghao Ding,
Kevin Lu, Baojun Xu, Sen Wang, Oder Chiou, Lars-Peter Clausen,
nuno.sa, Steven Eckhoff, patches, chrome-platform, asahi,
linux-arm-msm, linux-sound, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <CAABR9nG+6gOj4KnWmTyykgGN93xy6jKQh+-_f8Xxn=Jkv28vBA@mail.gmail.com>
On Fri, 19 Jun 2026 15:20:37 +0700
Bui Duc Phuc <phucduc.bui@gmail.com> wrote:
> Hi Charles, David,
>
> Thanks for the review.
>
> > >
> > > I believe you have to use scoped_guard here, as there is a return
> > > from the function above, if memory serves it attempts to release
> > > the mutex on that path despite it being above the guard.
> >
> > Indeed.
> > I believe clang will complain.
> > That makes these mechanical conversions of existing code dangerous churn.
> >
> > While using guard() (etc) can make it easier to ensure the lock is released
> > when functions have multiple error exits, I'm not convinced it makes the
> > code any easier to read (other people may disagree).
> >
>
> I built the code with both GCC and Clang and didn't see any warnings.
>
> My understanding was that the early return exits the function before
> the guard is instantiated, so it should not affect the guard's cleanup
> handling.
>
> Could you explain what issue you are referring to? I may be missing
> something.
When a variable is defined (and initialised) part way down a block the
compiler moves the definition to the top of the block but doesn't initialise
it at all, the first assignment happens where the code contains the
definition.
However the destructor is always called at the end of the block.
So if you return from a function before the definition the destructor
is called with an uninitialised argument.
This has always been a problem with C++.
It usually happens when you define a variable inside a switch statement.
David
>
> Best regards,
> Phuc
^ permalink raw reply
* Re: Question: pinctrl-backed GPIO set_config and gpio_chip::can_sleep
From: Bartosz Golaszewski @ 2026-06-19 9:01 UTC (permalink / raw)
To: Linus Walleij
Cc: Linus Walleij, Bartosz Golaszewski, Ludovic Desroches,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Antonio Borneo,
Maxime Coquelin, Alexandre Torgue, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, linux-arm-kernel, linux-gpio, linux-stm32,
linux-sunxi, linux-kernel, jianhao.xu, Runyu Xiao
In-Reply-To: <CAD++jLmW3vgTFryRAL24x2TbgbR1tbhjw-nFFH3askoZfSibaQ@mail.gmail.com>
On Thu, 18 Jun 2026 15:15:30 +0200, Linus Walleij <linusw@kernel.org> said:
> Hi Runyu,
>
> thanks for your analysis!
>
> On Thu, Jun 18, 2026 at 7:42 AM Runyu Xiao <runyu.xiao@seu.edu.cn> wrote:
>
>> The path we are concerned about is:
>>
>> gpiod_set_config()
>> -> gpio_do_set_config()
>> -> gpiochip_generic_config()
>> -> pinctrl_gpio_set_config()
>> -> pinctrl_get_device_gpio_range()
>> -> mutex_lock(&pctldev->mutex)
>
> That would be mutex_lock(&pinctrldev_list_mutex); would it not?
>
>> If gpiod_cansleep() returns false, a GPIO forwarder or another consumer
>> can choose an atomic carrier and call gpiod_set_config() while holding a
>> spinlock.
>
> I see the problem.
>
>> The local draft I am considering marks only these controllers as
>> sleeping:
>>
>> pinctrl: at91-pio4: mark the GPIO controller as sleeping
>> pinctrl: stm32: mark the GPIO controller as sleeping
>> pinctrl: sunxi: mark the GPIO controller as sleeping
>>
>> The reason is that all three expose gpiochip_generic_config() and can
>> therefore reach the pinctrl mutex from the GPIO set_config path, while
>> their current gpio_chip registration does not set can_sleep.
>
> But that's not the right solution is it? These controllers can probably
> just write a register and be done with it, they all look like they are
> memory-mapped? That means we introduce sleep where not needed.
>
> Can we simply replace pinctrldev_list_mutex with a spinlock?
Oh I've tried, I've give it a few attempts in the past. It's not a "simply"
case this one! :)
> The list isn't gonna be huge and all in-memory anyway.
> If it takes too much time we need to think about putting the
> ranges in a better data structure such as the maple tree.
>
FWIW radix tree provides some RCU synchronization IIRC.
> mutex_lock(&pinctrldev_list_mutex); could then be turned
> into spinlock_irqsave() or even better
> guard(spinlock_irqsave)(&pinctrldev_list_lock) in
> pinctrl_get_device_gpio_range().
>
I recall running into places where a mutex would be taken in atomic context
in that case.
Bart
> This would mean we just take two different spinlocks in seqence
> and save state in each so it should work just fine.
>
> Yours,
> Linus Walleij
>
^ permalink raw reply
* Re: [RFC PATCH 3/6] arm64: mm: fix restoring linear map permissions on execmem cache clean
From: Ryan Roberts @ 2026-06-19 8:33 UTC (permalink / raw)
To: Adrian Barnaś, linux-arm-kernel
Cc: linux-mm, Catalin Marinas, Will Deacon, David Hildenbrand,
Mike Rapoport (Microsoft), Ard Biesheuvel, Christoph Lameter,
Yang Shi, Brendan Jackman
In-Reply-To: <402e247d-1eb9-4842-ba9a-712a3bb9b438@arm.com>
On 18/06/2026 16:05, Ryan Roberts wrote:
> On 11/06/2026 14:01, Adrian Barnaś wrote:
>> Strip the read-only attribute from the selected memory range when
>> restoring the linear map after an execmem cache clean.
>>
>> An execmem cache clean is performed when a cache block becomes empty
>> after unloading a module. When making the memory valid again, the linear
>> memory alias must also have its read-only attribute cleared.
>>
>> Without this change, the linear memory alias remains read-only even
>> after the execmem cache block itself is freed, which prevents subsequent
>> allocations from writing to that memory.
>>
>> Signed-off-by: Adrian Barnaś <abarnas@google.com>
>> ---
>> arch/arm64/mm/pageattr.c | 17 ++++++++++++++++-
>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
>> index 88720bbba892..eaefdf90b0d5 100644
>> --- a/arch/arm64/mm/pageattr.c
>> +++ b/arch/arm64/mm/pageattr.c
>> @@ -239,6 +239,13 @@ int set_memory_x(unsigned long addr, int numpages)
>> __pgprot(PTE_PXN));
>> }
>>
>> +static int set_memory_default(unsigned long addr, int numpages)
>> +{
>> + return __change_memory_common(addr, PAGE_SIZE * numpages,
>> + __pgprot(PTE_VALID),
>> + __pgprot(PTE_RDONLY));
>
> This is not sufficient to convert an invalid entry to valid. As well as setting
> the PTE_VALID bit, you would also need to clear the PTE_PRESENT_INVALID and set
> PTE_MAYBE_NG.
>
> e.g:
>
> int set_memory_valid(unsigned long addr, int numpages, int enable)
> {
> if (enable)
> return __change_memory_common(addr, PAGE_SIZE * numpages,
> __pgprot(PTE_PRESENT_VALID_KERNEL),
> __pgprot(PTE_PRESENT_INVALID));
>
>
>> +}
>> +
>> int set_memory_valid(unsigned long addr, int numpages, int enable)
>> {
>> if (enable)
>> @@ -362,7 +369,15 @@ int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
>> if (!can_set_direct_map())
>> return 0;
>>
>> - return set_memory_valid(addr, nr, valid);
>> + /*
>> + * Execmem cache uses this function to reset permissions on linear mapping
>> + * when freeing unused cache block. On x86 it makes memory RW which is
>> + * desirable. On ARM64 set_memory_valid() just change valid bit which
>> + * leave direct mapping read-only so use set_memory_default instead.
>> + */
>> +
>> + return valid ? set_memory_default(addr, nr) :
>> + set_memory_valid(addr, nr, false);
>
> Surely execmem should just be using set_direct_map_default_noflush() if that's
> the behaviour it wants?
>
> I think that the current implementation of set_direct_map_default_noflush()
> doesn't undo the effects of set_memory_nx() / set_memory_x(). That might be
> worth checking?
It's also worth mentioning that set_direct_map_valid_noflush() has "noflush" in
the name, implies it doesn't expect/require any TLB flushing to occur. But the
implementation will perform tlb flushing for any case that is not just a
invalid->valid transition (which for the existing impl is the case when
valid=true and for your changes is never the case - see __change_memory_common).
But execmem doesn't do any tlb flushing so it looks to me like it actually
requires that set_direct_map_valid_noflush() handles the tlb flushing? All seems
a bit fishy and probably warrants a cleanup to make things clearer.
>
> Thanks,
> Ryan
>
>
>> }
>>
>> #ifdef CONFIG_DEBUG_PAGEALLOC
>
^ permalink raw reply
* Re: [PATCH 11/78] ASoC: codecs: cros_ec_codec: Use guard() for mutex locks
From: Bui Duc Phuc @ 2026-06-19 8:26 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: Mark Brown, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Cheng-Yi Chiang, Guenter Roeck, Benson Leung, David Rhodes,
Richard Fitzgerald, povik+lin, Charles Keepax, Support Opensource,
Nick Li, Herve Codina, Srinivas Kandagatla, Matthias Brugger,
AngeloGioacchino Del Regno, Shenghao Ding, Kevin Lu, Baojun Xu,
Sen Wang, Oder Chiou, Lars-Peter Clausen, nuno.sa, Steven Eckhoff,
patches, chrome-platform, asahi, linux-arm-msm, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <ajNud7QkwF369lBY@google.com>
Hi Tzung-Bi,
> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Thanks for reviewing the patch.
Best regards,
Phuc
^ permalink raw reply
* Re: [PATCH 15/78] ASoC: codecs: cs42l43: Use guard() for mutex locks
From: Bui Duc Phuc @ 2026-06-19 8:20 UTC (permalink / raw)
To: David Laight
Cc: Charles Keepax, Mark Brown, Liam Girdwood, Jaroslav Kysela,
Takashi Iwai, Cheng-Yi Chiang, Tzung-Bi Shih, Guenter Roeck,
Benson Leung, David Rhodes, Richard Fitzgerald, povik+lin,
Support Opensource, Nick Li, Herve Codina, Srinivas Kandagatla,
Matthias Brugger, AngeloGioacchino Del Regno, Shenghao Ding,
Kevin Lu, Baojun Xu, Sen Wang, Oder Chiou, Lars-Peter Clausen,
nuno.sa, Steven Eckhoff, patches, chrome-platform, asahi,
linux-arm-msm, linux-sound, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260617140209.3f89706c@pumpkin>
Hi Charles, David,
Thanks for the review.
> >
> > I believe you have to use scoped_guard here, as there is a return
> > from the function above, if memory serves it attempts to release
> > the mutex on that path despite it being above the guard.
>
> Indeed.
> I believe clang will complain.
> That makes these mechanical conversions of existing code dangerous churn.
>
> While using guard() (etc) can make it easier to ensure the lock is released
> when functions have multiple error exits, I'm not convinced it makes the
> code any easier to read (other people may disagree).
>
I built the code with both GCC and Clang and didn't see any warnings.
My understanding was that the early return exits the function before
the guard is instantiated, so it should not affect the guard's cleanup
handling.
Could you explain what issue you are referring to? I may be missing
something.
Best regards,
Phuc
^ permalink raw reply
* Re: [PATCH v4 2/2] clk: amlogic: Add A9 AO clock controller driver
From: Jerome Brunet @ 2026-06-19 8:08 UTC (permalink / raw)
To: Julian Braha
Cc: jian.hu, Neil Armstrong, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <5af78bca-7c49-48b1-af8a-cfbe55ae26ba@gmail.com>
On ven. 19 juin 2026 at 08:48, Julian Braha <julianbraha@gmail.com> wrote:
> Hi Jerome,
>
> On 6/19/26 08:29, Jerome Brunet wrote:
>> No, regmap clock are directly used so this is necessary.
>> Relying on other module dependencies is not enough
>
> What do you mean it's "not enough"?
>
> Functionally, any user of COMMON_CLK_MESON_DUALDIV can also use
> COMMON_CLK_MESON_REGMAP.
This driver directly use regmap clocks. This is a direct dependency,
required for the build and stated as such. If the module needs it, it
depends on it, simply.
Relying on indirect dependencies is incorrect and fragile.
If those dependencies ever change, the build breaks for no obvious reason.
>
> Unless you mean for documentation purposes?
>
> - Julian Braha
--
Jerome
^ permalink raw reply
* [PATCH net v2] net: airoha: Fix TX scheduler queue mask loop upper bound
From: Wayen Yan @ 2026-06-19 7:52 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In airoha_qdma_set_chan_tx_sched(), the loop clearing queue mask was
using AIROHA_NUM_TX_RING (32) instead of AIROHA_NUM_QOS_QUEUES (8).
Each channel has 8 queues, and TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i)
computes BIT(i + (channel * 8)). With i ranging 0..31, this causes:
- channel 0: clears bit 0..31 (all 4 channels) instead of 0..7
- channel 1: clears bit 8..31 (channels 1-3) instead of 8..15
- channel 2: clears bit 16..31 (channels 2-3) instead of 16..23
- channel 3: clears bit 24..31 (channel 3 only) - correct by accident
While BIT(32+) on arm64 produces 64-bit values truncated to 0 in u32
mask parameter, the loop still incorrectly clears queues within the
same channel beyond queue 7.
Even though this is functionally harmless (the register resets to 0
and is only ever cleared, never set — so clearing extra bits is a
no-op), the loop bound is semantically wrong and should be fixed for
correctness and clarity.
Fix by using AIROHA_NUM_QOS_QUEUES (8) as the loop upper bound.
Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Wayen Yan <win847@gmail.com>
---
Changes in v2:
- Add Lorenzo's Acked-by tag.
- Clarify in commit message that this is semantically wrong but
functionally harmless (register resets to 0, only cleared), as
Lorenzo pointed out in review.
- Rebase on current net tree.
Link: https://lore.kernel.org/netdev/ajJIWMs4dVbfkHZ5@lore-desk/
Link: https://lore.kernel.org/netdev/CAL_ptrs6J3Ryw_4mVTq5VgzkB4RreF5S0huHyLvd9YwWr1m6jAA@mail.gmail.com/
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index d0c0c0ec8a..ca77747b44 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2212,7 +2212,7 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *dev,
struct airoha_gdm_port *port = netdev_priv(dev);
int i;
- for (i = 0; i < AIROHA_NUM_TX_RING; i++)
+ for (i = 0; i < AIROHA_NUM_QOS_QUEUES; i++)
airoha_qdma_clear(port->qdma, REG_QUEUE_CLOSE_CFG(channel),
TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
--
2.51.0
^ permalink raw reply related
* [PATCH net v4] net: airoha: Fix skb->priority underflow in airoha_dev_select_queue()
From: Wayen Yan @ 2026-06-19 7:50 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In airoha_dev_select_queue(), the expression:
queue = (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES;
implicitly converts to unsigned arithmetic: when skb->priority is 0
(the default for unclassified traffic), (0u - 1u) wraps to UINT_MAX,
and UINT_MAX % 8 = 7, routing default best-effort packets to the
highest-priority QoS queue. This causes QoS inversion where the
majority of traffic on a PON gateway starves actual high-priority
flows (VoIP, gaming, etc.).
The "- 1" offset was a leftover from the ETS offload implementation
that has since been removed. The correct mapping is a direct modulo:
queue = skb->priority % AIROHA_NUM_QOS_QUEUES;
This maps priority 0 → queue 0 (lowest), priority 7 → queue 7
(highest), with higher priorities wrapping around. This is the
standard Linux sk_prio → HW queue mapping used by other drivers.
Fixes: 2b288b81560b ("net: airoha: Introduce ndo_select_queue callback")
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Joe Damato <joe@dama.to>
Signed-off-by: Wayen Yan <win847@gmail.com>
---
Changes in v4:
- Remove the "- 1" offset entirely as suggested by Lorenzo and Jakub.
The offset was an ETS offload leftover; the correct mapping is a
direct modulo of skb->priority to AIROHA_NUM_QOS_QUEUES, matching
the standard Linux sk_prio → HW queue convention. (v3 used a
ternary guard which addressed the underflow but kept the unneeded
offset.)
Link: https://lore.kernel.org/netdev/20260617164448.31e189bc@kernel.org/
Link: https://lore.kernel.org/netdev/ajPCgH7E_ke6Fdur@lore-desk/
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index d0c0c0ec8a..9ec3f22754 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1928,7 +1928,7 @@ static u16 airoha_dev_select_queue(struct net_device *dev, struct sk_buff *skb,
*/
channel = netdev_uses_dsa(dev) ? skb_get_queue_mapping(skb) : port->id;
channel = channel % AIROHA_NUM_QOS_CHANNELS;
- queue = (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES; /* QoS queue */
+ queue = skb->priority % AIROHA_NUM_QOS_QUEUES;
queue = channel * AIROHA_NUM_QOS_QUEUES + queue;
return queue < dev->num_tx_queues ? queue : 0;
--
2.51.0
^ permalink raw reply related
* [PATCH v3 1/1] reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ
From: robby.cai @ 2026-06-19 7:31 UTC (permalink / raw)
To: p.zabel, Frank.Li, s.hauer, festevam
Cc: krzk+dt, andrew.smirnov, kernel, imx, linux-arm-kernel,
linux-kernel, aisheng.dong, guoniu.zhou
From: Robby Cai <robby.cai@nxp.com>
On i.MX8MQ, the MIPI CSI reset lines are active-low and not self-clearing.
Writing '0' asserts reset and it remains asserted until explicitly
deasserted by software.
This driver previously treated the MIPI CSI reset signals as active-high,
which led to incorrect reset assert/deassert sequencing. This issue was
exposed by commit 6d79bb8fd2aa ("media: imx8mq-mipi-csi2: Explicitly
release reset").
Fix this by reflecting the correct reset polarity and ensuring proper
reset handling.
Fixes: c979dbf59987 ("reset: imx7: Add support for i.MX8MQ IP block variant")
Cc: <stable@vger.kernel.org> # 6d79bb8fd2aa: media: imx8mq-mipi-csi2: Explicitly release reset
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Robby Cai <robby.cai@nxp.com>
---
Changes in v3:
- Add Cc tag as suggested by Philipp Zabel
- Add R-b tag from Philipp Zabel
Link to v2: https://lore.kernel.org/imx/20260417080851.489303-1-robby.cai@nxp.com/
Changes in v2:
- Drop the naming change in response to feedback from Krzysztof Kozlowski
- Refine the patch subject and commit message
Link to v1: https://lore.kernel.org/imx/20260331101331.1405588-1-robby.cai@nxp.com/
---
drivers/reset/reset-imx7.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
index dd01fe11c5cb..a3cb8244d76a 100644
--- a/drivers/reset/reset-imx7.c
+++ b/drivers/reset/reset-imx7.c
@@ -236,6 +236,12 @@ static int imx8mq_reset_set(struct reset_controller_dev *rcdev,
case IMX8MQ_RESET_PCIE_CTRL_APPS_EN:
case IMX8MQ_RESET_PCIE2_CTRL_APPS_EN:
+ case IMX8MQ_RESET_MIPI_CSI1_CORE_RESET:
+ case IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET:
+ case IMX8MQ_RESET_MIPI_CSI1_ESC_RESET:
+ case IMX8MQ_RESET_MIPI_CSI2_CORE_RESET:
+ case IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET:
+ case IMX8MQ_RESET_MIPI_CSI2_ESC_RESET:
case IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N:
case IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N:
case IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N:
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v4 2/2] clk: amlogic: Add A9 AO clock controller driver
From: Julian Braha @ 2026-06-19 7:48 UTC (permalink / raw)
To: Jerome Brunet
Cc: jian.hu, Neil Armstrong, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1jbjd7c7ip.fsf@starbuckisacylon.baylibre.com>
Hi Jerome,
On 6/19/26 08:29, Jerome Brunet wrote:
> No, regmap clock are directly used so this is necessary.
> Relying on other module dependencies is not enough
What do you mean it's "not enough"?
Functionally, any user of COMMON_CLK_MESON_DUALDIV can also use
COMMON_CLK_MESON_REGMAP.
Unless you mean for documentation purposes?
- Julian Braha
^ permalink raw reply
* Re: Question: pinctrl-backed GPIO set_config and gpio_chip::can_sleep
From: Linus Walleij @ 2026-06-19 7:43 UTC (permalink / raw)
To: Runyu Xiao
Cc: Linus Walleij, Bartosz Golaszewski, Ludovic Desroches,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Antonio Borneo,
Maxime Coquelin, Alexandre Torgue, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, linux-arm-kernel, linux-gpio, linux-stm32,
linux-sunxi, linux-kernel, jianhao.xu
In-Reply-To: <20260618151052.3984665-1-runyu.xiao@seu.edu.cn>
Hi Runyu,
On Thu, Jun 18, 2026 at 5:11 PM Runyu Xiao <runyu.xiao@seu.edu.cn> wrote:
> I agree that marking these memory-mapped controllers as can_sleep is too
> broad if the only sleepable part is the pinctrl range lookup. That would
> make consumers treat otherwise MMIO-backed get/set paths as sleepable,
> which is not the contract I want to change.
>
> I will hold back the at91-pio4/stm32/sunxi can_sleep series and look at
> the pinctrl core direction instead, specifically whether
> pinctrldev_list_mutex can be replaced by a non-sleeping lock for
> pinctrl_get_device_gpio_range(). That should also line up with the GPIO
> direction callback case discussed in the other thread.
Your replies look like those one would get from an AI agent,
because they are repeating information (context) that I have just
provided, just with other words.
If this is the case you need to instruct your agent to be terse in
mailing list replies: it needs to quote what I just said with >
markers in the margin and just add the word "Agreed" after
it.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 0/2] clk: amlogic: Add A9 AO clock controller
From: Jerome Brunet @ 2026-06-19 7:40 UTC (permalink / raw)
To: Jian Hu via B4 Relay
Cc: Neil Armstrong, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Xianwei Zhao, Kevin Hilman,
Martin Blumenstingl, jian.hu, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel, Conor Dooley
In-Reply-To: <20260618-a9_aoclk-v4-0-569d0425e50c@amlogic.com>
On jeu. 18 juin 2026 at 17:49, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
> This series adds Amlogic A9 AO clock support, including dt-binding and AO clock driver.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
A part from the 2 minor problems found by sashiko, This looks good.
> ---
> Changes in v4:
> - Drop CLK_IS_CRITICAL for ao_xtal_in clock.
> - Drop CLK_HW_INIT* and revert to explicit clock declarations.
> - Link to v3: https://lore.kernel.org/r/20260610-a9_aoclk-v3-0-b7592d6c31e2@amlogic.com
>
> Changes in v3:
> - Move COMPILE_TEST after 'depends on ARM64' reported by sashiko-bot.
> - Rename i2c3 to i3c reported by sashiko-bot.
> - Reword the comment describing ao_xtal_in's flags.
> - Use struct clk_init_data to describe ao_xtal_in's hw.init.
> - Link to v2: https://lore.kernel.org/r/20260603-a9_aoclk-v2-0-f47ea616ee78@amlogic.com
>
> Changes in v2:
> - Split the A9 clock driver and send the AO clock separately.
> - Rename aobus to soc.
> - Use CLK_HW_INIT_FW_NAME to describe clk_init_data.
> - Use CLK_HW_INIT_PARENTS_DATA to describe clk_init_data.
> - Use a9_ao prefix for MESON_COMP_SEL.
> - Correct duandiv name.
> - Fix pwm b reg.
> - Link to v1: https://lore.kernel.org/all/20260511-b4-a9_clk-v1-0-41cb4071b7c9@amlogic.com/
>
> ---
> Jian Hu (2):
> dt-bindings: clock: Add Amlogic A9 AO clock controller
> clk: amlogic: Add A9 AO clock controller driver
>
> .../bindings/clock/amlogic,a9-aoclkc.yaml | 76 ++++
> drivers/clk/meson/Kconfig | 13 +
> drivers/clk/meson/Makefile | 1 +
> drivers/clk/meson/a9-aoclk.c | 488 +++++++++++++++++++++
> include/dt-bindings/clock/amlogic,a9-aoclkc.h | 76 ++++
> 5 files changed, 654 insertions(+)
> ---
> base-commit: ca89c88bcf69daca829044c638a8163d5ce47af0
> change-id: 20260603-a9_aoclk-bbf531badc63
>
> Best regards,
--
Jerome
^ 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