* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Daniele Briguglio @ 2026-06-24 12:20 UTC (permalink / raw)
To: Heiko Stuebner, Diederik de Haas, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <2008560.6tgchFWduM@diego>
Hi Heiko,
> Care to send a patch for that change? :-)
Will do. I was only waiting for your call on the approach before sending,
so I'll get it out shortly.
Best regards,
Daniele
^ permalink raw reply
* Re: [PATCH 5/7] soc: aspeed: Add eSPI flash channel support
From: Markus Elfring @ 2026-06-24 12:14 UTC (permalink / raw)
To: YH Chung, linux-aspeed, openbmc, linux-arm-kernel, devicetree,
Andrew Jeffery, Conor Dooley, Joel Stanley, Krzysztof Kozlowski,
Philipp Zabel, Rob Herring, Ryan Chen
Cc: LKML, Maciej Lawniczak
In-Reply-To: <20260313-upstream_espi-v1-5-9504428e1f43@aspeedtech.com>
…
> +++ b/drivers/soc/aspeed/espi/aspeed-espi.c
…
> +static void aspeed_espi_flash_rx_work(struct work_struct *work)
> +{
> + struct aspeed_espi_flash *flash = container_of(work, struct aspeed_espi_flash, rx_work);
> + struct aspeed_espi *espi = container_of(flash, struct aspeed_espi, flash);
> +
> + mutex_lock(&flash->tx_mtx);
> + aspeed_espi_flash_handle_lun(espi);
> + mutex_unlock(&flash->tx_mtx);
> +}
…
Under which circumstances would you become interested to apply a statement
like “guard(mutex)(&flash->tx_mtx);”?
https://elixir.bootlin.com/linux/v7.1.1/source/include/linux/mutex.h#L253
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v4 3/3] arm64: dts: qcom: Add Vicharak Axon Mini
From: Konrad Dybcio @ 2026-06-24 12:12 UTC (permalink / raw)
To: Ajit Singh
Cc: Bjorn Andersson, Bartosz Golaszewski, Dmitry Baryshkov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <ajYcnHPZjkFwGjly@page.local>
On 6/20/26 6:57 AM, Ajit Singh wrote:
> On Fri, Jun 19, 2026 at 05:30:40PM +0530, Konrad Dybcio wrote:
>> On 6/18/26 8:29 AM, Ajit Singh wrote:
>>> On Tue, Jun 16, 2026 at 02:10:44PM +0530, Konrad Dybcio wrote:
>>>> On 6/12/26 6:16 AM, Ajit Singh wrote:
>>>>> On Wed, Jun 10, 2026 at 02:58:19PM +0530, Konrad Dybcio wrote:
>>>>>> On 6/7/26 1:36 PM, Ajit Singh wrote:
>>>>>>> Add DTS for the Vicharak Axon Mini board based on the Qualcomm
>>>>>>> QCS6490 SoC.
>>>>>>>
>>>>>>> This adds debug UART, eMMC, UFS, SDIO WLAN, USB 2.0 host, PCIe
>>>>>>> support along with regulators.
>>>>>>>
>>>>>>> The UFS ICE block is kept disabled because enabling it currently causes
>>>>>>> an SError during qcom_ice_create() on this board. UFS works without ICE.
>>>>>>>
>>>>>>> Signed-off-by: Ajit Singh <blfizzyy@gmail.com>
>>>>>>> ---
[...]
>>
>> most notably though, it seems that the brcmfmac driver doesn't even use
>> the regulator framework, probably because all of the SDIO WLANs that
>> Linux supports were wired in a more "embedded" way, where the V(Q)MMC
>> supplies were enough.. unless it's the case here too?
>
> It might not be possible to drop regulator-always-on for VREG_L12C here. The
> SDHC2 host already has its own vmmc/vqmmc rails:
>
> vqmmc-supply = <&vreg_l2c_1p62>;
> vmmc-supply = <&vreg_l6c_2p96>;
>
> VREG_L12C is a separate module-side VDDIO rail for the AP6272S WLAN/BT module.
> There is no separate GPIO-controlled enable for this rail;
>
> as you said, since brcmfmac does not appear to consume an extra VDDIO regulator
> from the SDIO child node, so unless there is a preferred way to model this
> module-side VDDIO rail, I think VREG_L12C still needs to stay always-on.
OK, let's get this merged then
Konrad
^ permalink raw reply
* Re: [PATCH v2 3/4] arm64: dts: qcom: Add HONOR MagicBook Art 14 device tree
From: Konrad Dybcio @ 2026-06-24 12:10 UTC (permalink / raw)
To: Konstantin Shabanov
Cc: andersson, robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260620173833.17728-1-mail@etehtsea.me>
On 6/20/26 7:38 PM, Konstantin Shabanov wrote:
> On Tue, 16 Jun 2026 14:37:13 +0200 Konrad Dybcio wrote:
>>> +/* MP0 goes to the USB-A port(USB3) and FPC */
>>
>> "MP0" refers to the first USB3+USB2 port on the multiport controller.
>> Is there a hub inbetween? Should we describe it? Do we know if VBUS on
>> the USB-A port is controllable?
>
> Unfortunately, I couldn't find any documentation for this laptop, and
> all I can tell is that the USB-A port seems to work and the FPC is
> recognized:
>
> Bus 005 Device 002: ID 10a5:9924 FPC FPC L:2407 FW:3334147
OK, if it works, it works
Konrad
^ permalink raw reply
* Re: [PATCH v3 3/4] arm64: dts: qcom: Add HONOR MagicBook Art 14 device tree
From: Konrad Dybcio @ 2026-06-24 12:10 UTC (permalink / raw)
To: Konstantin Shabanov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260620175210.19563-4-mail@etehtsea.me>
On 6/20/26 7:51 PM, Konstantin Shabanov wrote:
> Introduce support for the HONOR MagicBook Art 14 laptop.
> This version is based on the initial work by Kirill A. Korinsky [1]
> and Valentin Manea [2].
[...]
> +&iris {
> + firmware-name = "qcom/x1e80100/HONOR/MRO-XXX/qcvss8380.mbn";
Is that a model name, or a placeholder?
[...]
> +&tlmm {
> + gpio-reserved-ranges = <34 2>, /* Unused */
> + <44 4>; /* SPI (TPM) */
> +
> + hall_int_n_default: hall-int-n-state {
> + pins = "gpio92";
> + function = "gpio";
> + bias-disable;
> + };
nit: pins would be best sorted by their pin index
[...]
> + ts0_default: ts0-default-state {
> + int-n-pins {
> + pins = "gpio51";
> + function = "gpio";
> + bias-disable;
> + };
> +
> + reset-n-pins {
> + pins = "gpio48";
> + function = "gpio";
> + output-high;
not a nit: drop output-foo properties from TLMM pins, the
driver that consumes them should take care of setting their state
[...]
> +/* MP0 goes to the USB-A port(USB3) and FPC */
ultra nit: add a space before '(', please
Konrad
^ permalink raw reply
* Re: [PATCH v3 3/4] arm64: dts: qcom: Add HONOR MagicBook Art 14 device tree
From: Konrad Dybcio @ 2026-06-24 12:07 UTC (permalink / raw)
To: Konstantin Shabanov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260620175210.19563-4-mail@etehtsea.me>
On 6/20/26 7:51 PM, Konstantin Shabanov wrote:
> Introduce support for the HONOR MagicBook Art 14 laptop.
> This version is based on the initial work by Kirill A. Korinsky [1]
> and Valentin Manea [2].
[...]
> +/* MP0 goes to the USB-A port(USB3) and FPC */
> +&usb_mp {
> + /* Limit to single port */
> + phys = <&usb_mp_hsphy0>, <&usb_mp_qmpphy0>;
> + phy-names = "usb2-0", "usb3-0";
> +
> + status = "okay";
> +};
It's fine to keep the other one enabled, if only to make sure that
it's powered off sanely
Konrad
^ permalink raw reply
* Re: [PATCH 5/7] soc: aspeed: Add eSPI flash channel support
From: Markus Elfring @ 2026-06-24 12:02 UTC (permalink / raw)
To: YH Chung, linux-aspeed, openbmc, linux-arm-kernel, devicetree,
Andrew Jeffery, Conor Dooley, Joel Stanley, Krzysztof Kozlowski,
Philipp Zabel, Rob Herring, Ryan Chen
Cc: LKML, Maciej Lawniczak
In-Reply-To: <20260313-upstream_espi-v1-5-9504428e1f43@aspeedtech.com>
…
> +++ b/drivers/soc/aspeed/espi/aspeed-espi-comm.h
> @@ -0,0 +1,62 @@
…
> +/*
> + * eSPI cycle type encoding
> + *
> + * Section 5.1 Cycle Types and Packet Format,
> + * Intel eSPI Interface Base Specification, Rev 1.0, Jan. 2016.
> + */
> +#define ESPI_FLASH_READ 0x00
> +#define ESPI_FLASH_WRITE 0x01
> +#define ESPI_FLASH_ERASE 0x02
…
How do you think about to use an enumeration for such data?
https://en.wikipedia.org/wiki/Enumerated_type#C_and_syntactically_similar_languages
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Konrad Dybcio @ 2026-06-24 12:00 UTC (permalink / raw)
To: Xin Xu, andersson, konradybcio; +Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <tencent_A65CB41DCB0CA96634CF8883E1CF89059706@qq.com>
On 6/22/26 8:46 PM, Xin Xu wrote:
> Add the pm8008 PMIC node on i2c15 with seven LDOs,
> using GPIO84 as interrupt and GPIO76 as reset.
>
> Signed-off-by: Xin Xu <xxsemail@qq.com>
> ---
[...]
> + pm8008_default: pm8008-default-state {
> + int-pins {
> + pins = "gpio84";
> + function = "gpio";
> + bias-disable;
> + drive-strength = <2>;
> + input-enable;
> + };
arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-boe.dtb: pinctrl@f100000 (qcom,sm8250-pinctrl): pm8008-default-state: 'oneOf' conditional failed, one must be fixed:
'function' is a required property
'pins' is a required property
Unevaluated properties are not allowed ('int-pins', 'reset-pins' were unexpected)
False schema does not allow True
from schema $id: http://devicetree.org/schemas/pinctrl/qcom,sm8250-pinctrl.yaml
Please drop input-enable, it's not a thing on TLMM pins
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt8395-radxa-nio-12l: Enable I2C3 on 40-pin header
From: sashiko-bot @ 2026-06-24 11:58 UTC (permalink / raw)
To: Ricardo Pardini via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260624-nio-12l-add-i2c-40-pin-v1-1-f6c11ed2184c@pardini.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Contradictory and invalid multiple drive strength properties (`drive-strength` and `drive-strength-microamp`) in the `i2c3_pins` pinctrl node.
--
commit cc885ce9bc43909e2fea294bb5532055037c4cf5
Author: Ricardo Pardini <ricardo@pardini.net>
arm64: dts: mediatek: mt8395-radxa-nio-12l: Enable I2C3 on 40-pin header
This commit enables I2C3 on the 40-pin header for the Radxa NIO 12L board.
It adds the corresponding pin configurations to allow users to connect
external I2C devices.
> diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
> index bf91305e8e4a5..03a2f2e746475 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
[ ... ]
> @@ -789,6 +797,16 @@ pins-bus {
> };
> };
>
> + i2c3_pins: i2c3-pins {
> + pins-bus {
> + pinmux = <PINMUX_GPIO14__FUNC_SDA3>,
> + <PINMUX_GPIO15__FUNC_SCL3>;
> + bias-pull-up = <1000>;
> + drive-strength = <6>;
> + drive-strength-microamp = <1000>;
[Severity: Medium]
Is it expected to specify both drive-strength and drive-strength-microamp
for the same pins here?
The generic pinconf parser will emit a boot error log when it encounters
multiple drive strength properties, as requesting both 6mA and 1mA drive
strengths is contradictory.
Both properties will then propagate to the Mediatek pinctrl driver, which
may program both the standard and advanced driving circuits simultaneously.
Could this leave the I2C3 pins in an undefined electrical state?
> + };
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-nio-12l-add-i2c-40-pin-v1-1-f6c11ed2184c@pardini.net?part=1
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: qcom,ids: Add SoC ID for Snapdragon SDA 850
From: Konrad Dybcio @ 2026-06-24 11:58 UTC (permalink / raw)
To: Krzysztof Kozlowski, David Heidelberg, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <b3799f48-85bf-48d3-b2bd-daba59f6dd0b@kernel.org>
On 6/24/26 1:57 PM, Krzysztof Kozlowski wrote:
> On 24/06/2026 13:53, Konrad Dybcio wrote:
>> On 6/24/26 1:50 PM, Krzysztof Kozlowski wrote:
>>> On 24/06/2026 13:37, David Heidelberg wrote:
>>>> best I do is close-to-mainline tree,
>>>>
>>>> https://github.com/commaai/vamOS/tree/master/kernel/dts
>>>
>>>
>>> That's not upstream, so we do not need this patch upstream... Just keep
>>> it out of tree.
>>
>> As I mentioned, the proposed ID has upstream users e.g.
>> sdm850-lenovo-yoga-c630.dts
>
> There is no use of this in that DTS, so my comment is valid: please post
> it with users.
aaaah, I get it.. David, please add the socinfo entry
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Konrad Dybcio @ 2026-06-24 11:57 UTC (permalink / raw)
To: Xin Xu, andersson, konradybcio; +Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <tencent_A65CB41DCB0CA96634CF8883E1CF89059706@qq.com>
On 6/22/26 8:46 PM, Xin Xu wrote:
> Add the pm8008 PMIC node on i2c15 with seven LDOs,
> using GPIO84 as interrupt and GPIO76 as reset.
>
> Signed-off-by: Xin Xu <xxsemail@qq.com>
> ---
[...]
> + pm8008_default: pm8008-default-state {
> + int-pins {
> + pins = "gpio84";
> + function = "gpio";
> + bias-disable;
> + drive-strength = <2>;
> + input-enable;
> + };
> +
> + reset-pins {
> + pins = "gpio76";
> + function = "gpio";
> + bias-pull-up;
> + drive-strength = <2>;
nit: bias properties after drive-strength (I now noticed that 8250 dtsi
has it ""wrong"", we'll mass-touch it up once we have a tool for that..
sorry for the trouble)
otherwise
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: qcom,ids: Add SoC ID for Snapdragon SDA 850
From: Krzysztof Kozlowski @ 2026-06-24 11:57 UTC (permalink / raw)
To: Konrad Dybcio, David Heidelberg, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <12bc9f3d-bfea-4ff8-8eb6-d2203bb46b89@oss.qualcomm.com>
On 24/06/2026 13:53, Konrad Dybcio wrote:
> On 6/24/26 1:50 PM, Krzysztof Kozlowski wrote:
>> On 24/06/2026 13:37, David Heidelberg wrote:
>>> best I do is close-to-mainline tree,
>>>
>>> https://github.com/commaai/vamOS/tree/master/kernel/dts
>>
>>
>> That's not upstream, so we do not need this patch upstream... Just keep
>> it out of tree.
>
> As I mentioned, the proposed ID has upstream users e.g.
> sdm850-lenovo-yoga-c630.dts
There is no use of this in that DTS, so my comment is valid: please post
it with users.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: sm8250-xiaomi-elish: add ov8856 front camera
From: Konrad Dybcio @ 2026-06-24 11:56 UTC (permalink / raw)
To: Xin Xu, andersson, konradybcio; +Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <tencent_A7DA95458754255A62A4C730EEE484AB2905@qq.com>
On 6/22/26 8:52 PM, Xin Xu wrote:
> Add the ov8856 front camera, connected on CCI1 to CSIPHY4 and
> powered by pm8008 LDOs and other supplies.
>
> Signed-off-by: Xin Xu <xxsemail@qq.com>
> ---
[...]
> &cdsp {
> firmware-name = "qcom/sm8250/xiaomi/elish/cdsp.mbn";
> status = "okay";
> @@ -877,6 +933,20 @@ bt_en_state: bt-default-state {
> bias-pull-up;
> };
>
> + camera_front_active: camera-front-active-state {
> + pins = "gpio109";
> + function = "gpio";
> + bias-disable;
> + drive-strength = <2>;
> + };
> +
> + mclk3_active: mclk3-active-state {
> + pins = "gpio97";
> + function = "cam_mclk";
> + bias-disable;
> + drive-strength = <4>;
> + };
nit: other nodes have drive-strength before bias-disable
Also let's move the mclk pin state definition to sm8250, it's not
specific to this board
Konrad
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: qcom,ids: Add SoC ID for Snapdragon SDA 850
From: Konrad Dybcio @ 2026-06-24 11:53 UTC (permalink / raw)
To: Krzysztof Kozlowski, David Heidelberg, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <80049d2e-ddc9-44e9-b231-876adcd79823@kernel.org>
On 6/24/26 1:50 PM, Krzysztof Kozlowski wrote:
> On 24/06/2026 13:37, David Heidelberg wrote:
>> best I do is close-to-mainline tree,
>>
>> https://github.com/commaai/vamOS/tree/master/kernel/dts
>
>
> That's not upstream, so we do not need this patch upstream... Just keep
> it out of tree.
As I mentioned, the proposed ID has upstream users e.g.
sdm850-lenovo-yoga-c630.dts
Konrad
^ permalink raw reply
* Re: [PATCH v6 9/9] arm64: dts: freescale: imx95: Add video codec node
From: Francesco Dolcini @ 2026-06-24 11:50 UTC (permalink / raw)
To: Nas Chung
Cc: mchehab, hverkuil, robh, krzk+dt, conor+dt, shawnguo, s.hauer,
linux-media, devicetree, linux-kernel, linux-imx,
linux-arm-kernel, jackson.lee, lafley.kim, marek.vasut
In-Reply-To: <20260624072043.238-10-nas.chung@chipsnmedia.com>
On Wed, Jun 24, 2026 at 04:20:43PM +0900, Nas Chung wrote:
> Add the Chips and Media wave633 video codec node on IMX95 SoCs.
>
> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> ---
> .../boot/dts/freescale/imx95-19x19-evk.dts | 11 ++++++
> arch/arm64/boot/dts/freescale/imx95.dtsi | 36 +++++++++++++++++++
> 2 files changed, 47 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
> index 041fd838fabb..7edd1c69966a 100644
> --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
> @@ -76,6 +76,11 @@ linux_cma: linux,cma {
> linux,cma-default;
> reusable;
> };
> +
> + vpu_boot: memory@a0000000 {
> + reg = <0 0xa0000000 0 0x100000>;
> + no-map;
> + };
> };
>
> flexcan1_phy: can-phy0 {
> @@ -1142,3 +1147,9 @@ &tpm6 {
> pinctrl-0 = <&pinctrl_tpm6>;
> status = "okay";
> };
> +
> +&vpu {
> + memory-region = <&vpu_boot>;
> + sram = <&sram1>;
Can the `sram` node moved to imx95.dtsi or not?
Francesco
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: net: rockchip-dwmac: Allow 9 clocks
From: Heiko Stübner @ 2026-06-24 11:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Wu, Maxime Coquelin, Alexandre Torgue, Yanan He
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-3-5aef608a3f64@gmail.com>
Am Mittwoch, 24. Juni 2026, 10:44:40 Mitteleuropäische Sommerzeit schrieb Yanan He:
> RV1126 has a separate GMAC Ethernet output clock used as the external
> PHY reference clock. This clock is described in addition to the existing
> GMAC clocks.
AS stated in the driver patch, this is the input clock for the phy
and ethernet phys are perfectly capable of handling their input
clocks. See reference in the driver patch.
Heiko
> Signed-off-by: Yanan He <grumpycat921013@gmail.com>
> ---
> Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> index 80c252845349..86a7e83675ae 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> @@ -71,7 +71,7 @@ properties:
>
> clocks:
> minItems: 4
> - maxItems: 8
> + maxItems: 9
>
> clock-names:
> contains:
>
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: qcom,ids: Add SoC ID for Snapdragon SDA 850
From: Krzysztof Kozlowski @ 2026-06-24 11:50 UTC (permalink / raw)
To: David Heidelberg, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <16d91c51-9f1b-48ff-90db-7dd7ef056bc2@ixit.cz>
On 24/06/2026 13:37, David Heidelberg wrote:
> best I do is close-to-mainline tree,
>
> https://github.com/commaai/vamOS/tree/master/kernel/dts
That's not upstream, so we do not need this patch upstream... Just keep
it out of tree.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/7] net: stmmac: dwmac-rk: Enable refout clock for RGMII
From: Heiko Stübner @ 2026-06-24 11:49 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Wu, Maxime Coquelin, Alexandre Torgue, Yanan He
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-4-5aef608a3f64@gmail.com>
Hi,
Am Mittwoch, 24. Juni 2026, 10:44:41 Mitteleuropäische Sommerzeit schrieb Yanan He:
> Some Rockchip GMAC integrations use clk_mac_refout as an external PHY
> reference clock even when the MAC is configured for RGMII.
>
> RV1126 boards can route CLK_GMAC_ETHERNET_OUT to the external PHY as a
> 25 MHz reference clock. If the driver does not acquire and enable this
> clock in RGMII mode, the common clock framework may disable it as unused
> and the PHY can lose its reference clock.
>
> Enable the refout clock handling for RGMII in addition to RMII.
the clock your referencing is not limited to your rv1126 but instead
present on most (all?) Rockchip SoCs.
And it is an input clock for the phy itself, so should be handled there.
See for example
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi#n313
as a reference.
Heiko
> Signed-off-by: Yanan He <grumpycat921013@gmail.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> index 8d7042e68926..f6fdc0c5b475 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -1112,7 +1112,8 @@ static int rk_gmac_clk_init(struct plat_stmmacenet_data *plat)
> bsp_priv->clk_enabled = false;
>
> bsp_priv->num_clks = ARRAY_SIZE(rk_clocks);
> - if (phy_iface == PHY_INTERFACE_MODE_RMII)
> + if (phy_iface == PHY_INTERFACE_MODE_RMII ||
> + phy_iface == PHY_INTERFACE_MODE_RGMII)
> bsp_priv->num_clks += ARRAY_SIZE(rk_rmii_clocks);
>
> bsp_priv->clks = devm_kcalloc(dev, bsp_priv->num_clks,
> @@ -1123,7 +1124,8 @@ static int rk_gmac_clk_init(struct plat_stmmacenet_data *plat)
> for (i = 0; i < ARRAY_SIZE(rk_clocks); i++)
> bsp_priv->clks[i].id = rk_clocks[i];
>
> - if (phy_iface == PHY_INTERFACE_MODE_RMII) {
> + if (phy_iface == PHY_INTERFACE_MODE_RMII ||
> + phy_iface == PHY_INTERFACE_MODE_RGMII) {
> for (j = 0; j < ARRAY_SIZE(rk_rmii_clocks); j++)
> bsp_priv->clks[i++].id = rk_rmii_clocks[j];
> }
>
>
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Heiko Stübner @ 2026-06-24 11:45 UTC (permalink / raw)
To: Daniele Briguglio, Diederik de Haas, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Diederik de Haas
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <DJGM4D19H31O.4I5N79CG5Z8C@cknow-tech.com>
Am Dienstag, 23. Juni 2026, 19:42:05 Mitteleuropäische Sommerzeit schrieb Diederik de Haas:
> Hi,
>
> On Tue Jun 23, 2026 at 4:10 PM CEST, Daniele Briguglio wrote:
> >> So IIUC that means I'd be testing both variants.
> >
> > Right, that covers both: the mux path and the consumer path. Looking
> > forward to the results.
>
> Analog audio works on both. Plus with _TO_IO and LTS without in their
> respective DTS's. So I guess CLK_IGNORE_UNUSED works.
> Whether it's a good/right fix, I'll leave up to others.
It is the correct fix, as it returns the original way things worked for
boards not activly handling that clock.
So while boards should do that, this makes the clock-addition
backwards compatible.
Care to send a patch for that change? :-)
Heiko
^ permalink raw reply
* [PATCH] arm64: dts: mediatek: mt8395-radxa-nio-12l: Enable I2C3 on 40-pin header
From: Ricardo Pardini via B4 Relay @ 2026-06-24 11:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Ricardo Pardini
From: Ricardo Pardini <ricardo@pardini.net>
I2C3 (SDA3/SCL3 on GPIO14/GPIO15) is routed to the 40-pin GPIO header,
exposed on the blue-colored pins 27 (SCL3) and 28 (SDA3). Enable the
controller, add the corresponding pin configuration in the pinctrl node
so users can use external I2C devices.
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
The Radxa NIO 12L exposes I2C3 (SDA3/SCL3, GPIO14/GPIO15) on its 40-pin
GPIO header, on the blue-coloured pins 27 (SCL3) and 28 (SDA3).
Enable the I2C3 controller, add the matching pinctrl configuration and run
the bus at 400 kHz, matching the other I2C buses already enabled on this
board.
Tested using a SD1306 I2C OLED display.
---
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
index bf91305e8e4a5..03a2f2e746475 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
@@ -371,6 +371,14 @@ it5205_sbu_mux: endpoint {
};
};
+/* Exposed on 40-pin header (blue-colored pins 27:SCL3 28:SDA3) */
+&i2c3 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&i2c3_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
&i2c4 {
clock-frequency = <400000>;
pinctrl-0 = <&i2c4_pins>;
@@ -789,6 +797,16 @@ pins-bus {
};
};
+ i2c3_pins: i2c3-pins {
+ pins-bus {
+ pinmux = <PINMUX_GPIO14__FUNC_SDA3>,
+ <PINMUX_GPIO15__FUNC_SCL3>;
+ bias-pull-up = <1000>;
+ drive-strength = <6>;
+ drive-strength-microamp = <1000>;
+ };
+ };
+
i2c4_pins: i2c4-pins {
pins-bus {
pinmux = <PINMUX_GPIO16__FUNC_SDA4>,
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260624-nio-12l-add-i2c-40-pin-19e0482fd835
Best regards,
--
Ricardo Pardini <ricardo@pardini.net>
^ permalink raw reply related
* Re: [PATCH v11] PCI: Add support for PCIe WAKE# interrupt
From: sashiko-bot @ 2026-06-24 11:40 UTC (permalink / raw)
To: Krishna Chaitanya Chundru; +Cc: linux-pci, devicetree, robh, conor+dt
In-Reply-To: <20260624-wakeirq_support-v11-1-120fbfaebe59@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] Hot-removing an endpoint sharing a WAKE# GPIO breaks wakeup for all remaining endpoints on that line.
- [High] pci_remove_of_wake_gpio() unconditionally clears the device's wakeup configuration and wake IRQ, even if it never acquired the WAKE# GPIO.
- [High] WAKE# GPIO configuration forces device wakeup to be enabled by default, violating PCI PM policy.
- [Medium] Calling platform_pci_configure_wake() after device_add() creates a race condition that overwrites driver or userspace wakeup configuration.
- [Medium] Hardcoded IRQ_TYPE_LEVEL_LOW ignores Device Tree GPIO polarity for the WAKE# interrupt.
- [Medium] WAKE# GPIO configuration permanently fails if the GPIO provider returns -EPROBE_DEFER.
--
commit 9e1cd6307066585f1f51b9e7de95ae7950936ba0
Author: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
PCI: Add support for PCIe WAKE# interrupt
According to the PCI Express specification (PCIe r7.0, Section 5.3.3.2),
two link wakeup mechanisms are defined: Beacon and WAKE#. This change adds
support for the WAKE# mechanism in the PCI core.
Link: https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/
Link: https://github.com/devicetree-org/dt-schema/pull/170
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 8b18c4ba845cf..0f5effe1d7026 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
[ ... ]
> + ret = dev_pm_set_dedicated_wake_irq(&pdev->dev, wake_irq);
> + if (ret < 0) {
> + pci_err(pdev, "Failed to set WAKE# IRQ: %d\n", ret);
> + return;
> + }
> +
> + ret = irq_set_irq_type(wake_irq, IRQ_TYPE_LEVEL_LOW);
[Severity: Medium]
Does hardcoding IRQ_TYPE_LEVEL_LOW here override the logical polarity
specified in the Device Tree?
If the WAKE# GPIO is specified via the wake-gpios property with flags like
GPIO_ACTIVE_HIGH, this explicit type setting might ignore those flags and
fail to trigger on platforms with an inverted physical signal.
> + if (ret < 0) {
> + dev_pm_clear_wake_irq(&pdev->dev);
> + pci_err(pdev, "Failed to set irq_type: %d\n", ret);
> + return;
> + }
> +
> + device_init_wakeup(&pdev->dev, true);
[Severity: High]
Could this forcefully enable wakeup by default and violate standard PCI PM
policy?
Calling device_init_wakeup() with true marks the device as wakeup capable
and also sets dev->power.should_wakeup = true. The standard PCI core
behavior usually marks devices as wakeup capable but leaves enablement to
userspace opt-in.
> +}
> +
> +void pci_configure_of_wake_gpio(struct pci_dev *dev)
> +{
> + struct device_node *dn = pci_device_to_OF_node(dev);
> + struct gpio_desc *gpio;
> +
> + if (!dn)
> + return;
> + /*
> + * fwnode_gpiod_get() may fail with -EBUSY (e.g. shared WAKE#), but the
> + * actual WAKE# trigger from the device would still work and the host
> + * controller driver will enable power to the topology.
> + *
> + * -EPROBE_DEFER cannot be propagated here since pci_device_add() has no
> + * retry mechanism.
> + */
> + gpio = fwnode_gpiod_get(of_fwnode_handle(dn), "wake", GPIOD_IN, NULL);
> + if (!IS_ERR(gpio)) {
[Severity: Medium]
Since pci_device_add() has no retry mechanism, does swallowing -EPROBE_DEFER
here mean WAKE# functionality will permanently fail if the GPIO controller
providing the WAKE# line hasn't probed yet?
[Severity: High]
If multiple endpoints share a WAKE# GPIO, only the first device acquires
it while the rest fail with -EBUSY. Can this break wakeup capabilities
for all remaining endpoints if the first device is later hot-removed?
When the first device is removed, it frees the shared GPIO via
pci_remove_of_wake_gpio(), leaving the remaining active endpoints without
an associated wake IRQ.
> + dev->wake = gpio;
> + pci_configure_wake_irq(dev, gpio);
> + }
> +}
> +
> +void pci_remove_of_wake_gpio(struct pci_dev *dev)
> +{
> + struct device_node *dn = pci_device_to_OF_node(dev);
> +
> + if (!dn)
> + return;
> +
> + device_init_wakeup(&dev->dev, false);
> + dev_pm_clear_wake_irq(&dev->dev);
> + gpiod_put(dev->wake);
> + dev->wake = NULL;
> +}
[Severity: High]
Should this cleanup block be guarded by a check for dev->wake?
As it stands, if a PCI device with an OF node failed to acquire the GPIO
(e.g., it returned -EBUSY) or didn't have a wake property, this will still
unconditionally clear its PME wakeup capability and detach any dedicated
wake IRQ the driver might have configured itself.
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index b63cd0c310bc0..143b0bd35b3c9 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
[ ... ]
> @@ -2775,6 +2775,8 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
> /* Establish pdev->tsm for newly added (e.g. new SR-IOV VFs) */
> pci_tsm_init(dev);
>
> + platform_pci_configure_wake(dev);
[Severity: Medium]
Does calling platform_pci_configure_wake() after device_add() create a race
condition?
By the time this is called, the device is already visible in sysfs and
uevents have fired. Local userspace tools configuring power/wakeup or
asynchronous driver probes could have their configurations silently
overwritten by the subsequent device_init_wakeup() call.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-wakeirq_support-v11-1-120fbfaebe59@oss.qualcomm.com?part=1
^ permalink raw reply
* [PATCH 4/4] media: dt-bindings: rc: Sync keymap list with latest list
From: Sean Young @ 2026-06-24 11:39 UTC (permalink / raw)
To: linux-media, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Young
Cc: devicetree, linux-kernel
In-Reply-To: <cover.1782300922.git.sean@mess.org>
The list is out of sync, so add missing entries, remove obsolete
entries and sort.
Signed-off-by: Sean Young <sean@mess.org>
---
Documentation/devicetree/bindings/media/rc.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml
index dedc5a4b81ec..43d84296e70d 100644
--- a/Documentation/devicetree/bindings/media/rc.yaml
+++ b/Documentation/devicetree/bindings/media/rc.yaml
@@ -122,10 +122,10 @@ properties:
- rc-proteus-2309
- rc-purpletv
- rc-pv951
- - rc-rc5-tv
- rc-rc6-mce
- rc-real-audio-220-32-keys
- rc-reddo
+ - rc-siemens-gigaset-rc20
- rc-snapstream-firefly
- rc-streamzap
- rc-su3000
@@ -147,11 +147,11 @@ properties:
- rc-tt-1500
- rc-twinhan-dtv-cab-ci
- rc-twinhan1027
+ - rc-vega-s9x
- rc-videomate-k100
- rc-videomate-s350
- rc-videomate-tv-pvr
- rc-videostrong-kii-pro
- - rc-vega-s9x
- rc-wetek-hub
- rc-wetek-play2
- rc-winfast
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] dt-bindings: arm: qcom,ids: Add SoC ID for Snapdragon SDA 850
From: David Heidelberg @ 2026-06-24 11:37 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <6ddd0652-d18e-4e23-a230-5f5c8a9756f8@kernel.org>
best I do is close-to-mainline tree,
https://github.com/commaai/vamOS/tree/master/kernel/dts
David
On 24/06/2026 08:26, Krzysztof Kozlowski wrote:
> On 23/06/2026 20:41, David Heidelberg via B4 Relay wrote:
>> From: David Heidelberg <david@ixit.cz>
>>
>> Add SoC ID for Qualcomm Snapdragon SDA850.
>>
>> Signed-off-by: David Heidelberg <david@ixit.cz>
>> ---
>> Will be used by Comma three.
>
> Can you provide a link?
>
> In general this must be send with the user.
>
>
> Best regards,
> Krzysztof
--
David Heidelberg
^ permalink raw reply
* [PATCH v9 06/12] clk: realtek: Add support for phase locked loops (PLLs)
From: Yu-Chun Lin @ 2026-06-24 11:29 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt, p.zabel, cylee12,
afaerber, jyanchou, bmasney
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-realtek-soc, james.tai, cy.huang, stanley_chang,
eleanor.lin
In-Reply-To: <20260624112940.3475605-1-eleanor.lin@realtek.com>
From: Cheng-Yu Lee <cylee12@realtek.com>
Provide a full set of PLL operations for programmable PLLs and a read-only
variant for fixed or hardware-managed PLLs.
Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v9:
- Add 'ftbl_find_ceil_by_rate()' as a fallback in 'clk_pll_determine_rate()' to
properly handle 'min_rate' and 'max_rate' boundaries when the floor result falls
below 'min_rate'.
---
drivers/clk/realtek/Makefile | 2 +
drivers/clk/realtek/clk-pll.c | 217 +++++++++++++++++++++++++++++++
drivers/clk/realtek/clk-pll.h | 47 +++++++
drivers/clk/realtek/freq_table.c | 57 ++++++++
drivers/clk/realtek/freq_table.h | 18 +++
5 files changed, 341 insertions(+)
create mode 100644 drivers/clk/realtek/clk-pll.c
create mode 100644 drivers/clk/realtek/clk-pll.h
create mode 100644 drivers/clk/realtek/freq_table.c
create mode 100644 drivers/clk/realtek/freq_table.h
diff --git a/drivers/clk/realtek/Makefile b/drivers/clk/realtek/Makefile
index 13000ed4ba11..71edc18121c6 100644
--- a/drivers/clk/realtek/Makefile
+++ b/drivers/clk/realtek/Makefile
@@ -2,3 +2,5 @@
obj-$(CONFIG_RTK_CLK_COMMON) += clk-rtk.o
clk-rtk-y += clk-rtk-common.o
+clk-rtk-y += clk-pll.o
+clk-rtk-y += freq_table.o
diff --git a/drivers/clk/realtek/clk-pll.c b/drivers/clk/realtek/clk-pll.c
new file mode 100644
index 000000000000..54c284070e47
--- /dev/null
+++ b/drivers/clk/realtek/clk-pll.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2024-2026 Realtek Semiconductor Corporation
+ * Author: Cheng-Yu Lee <cylee12@realtek.com>
+ */
+
+#include <linux/export.h>
+#include <linux/regmap.h>
+#include <linux/spinlock.h>
+#include "clk-pll.h"
+
+#define TIMEOUT 500
+
+static inline struct clk_pll *to_clk_pll(struct clk_hw *hw)
+{
+ struct clk_regmap *clkr = to_clk_regmap(hw);
+
+ return container_of(clkr, struct clk_pll, clkr);
+}
+
+static int wait_freq_ready(struct clk_pll *clkp)
+{
+ u32 pollval;
+
+ /* reg == 0 means not configured.
+ * Register offset 0 is never a valid address on Realtek SoCs.
+ */
+ if (!clkp->freq_ready_reg)
+ return 0;
+
+ return regmap_read_poll_timeout_atomic(clkp->clkr.regmap, clkp->freq_ready_reg, pollval,
+ (pollval & clkp->freq_ready_mask) == clkp->freq_ready_val, 1, TIMEOUT);
+}
+
+static bool is_power_on(struct clk_pll *clkp)
+{
+ u32 val;
+
+ /* reg == 0 means not configured (assume always on).
+ * Register offset 0 is never a valid address on Realtek SoCs.
+ */
+ if (!clkp->power_reg)
+ return true;
+
+ if (regmap_read(clkp->clkr.regmap, clkp->power_reg, &val))
+ return false;
+
+ return (val & clkp->power_mask) == clkp->power_val_on;
+}
+
+static void clk_pll_disable(struct clk_hw *hw)
+{
+ struct clk_pll *clkp = to_clk_pll(hw);
+ unsigned long flags;
+
+ if (!clkp->seq_power_off)
+ return;
+
+ spin_lock_irqsave(&clkp->lock, flags);
+
+ regmap_multi_reg_write(clkp->clkr.regmap, clkp->seq_power_off,
+ clkp->num_seq_power_off);
+
+ spin_unlock_irqrestore(&clkp->lock, flags);
+}
+
+static int clk_pll_is_enabled(struct clk_hw *hw)
+{
+ struct clk_pll *clkp = to_clk_pll(hw);
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(&clkp->lock, flags);
+
+ ret = is_power_on(clkp);
+
+ spin_unlock_irqrestore(&clkp->lock, flags);
+
+ return ret;
+}
+
+static int clk_pll_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ struct clk_pll *clkp = to_clk_pll(hw);
+ const struct freq_table *ftblv = NULL;
+
+ ftblv = ftbl_find_by_rate(clkp->freq_tbl, req->rate);
+
+ if (ftblv && ftblv->rate >= req->min_rate) {
+ req->rate = ftblv->rate;
+ return 0;
+ }
+
+ /* floor result is below min_rate; find the smallest rate >= min_rate */
+ ftblv = ftbl_find_ceil_by_rate(clkp->freq_tbl, req->min_rate);
+ if (!ftblv || ftblv->rate > req->max_rate)
+ return -EINVAL;
+
+ req->rate = ftblv->rate;
+
+ return 0;
+}
+
+static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_pll *clkp = to_clk_pll(hw);
+ const struct freq_table *fv;
+ unsigned long flags;
+ u32 freq_val;
+
+ spin_lock_irqsave(&clkp->lock, flags);
+
+ if (regmap_read(clkp->clkr.regmap, clkp->freq_reg, &freq_val)) {
+ spin_unlock_irqrestore(&clkp->lock, flags);
+ return 0;
+ }
+
+ freq_val &= clkp->freq_mask;
+
+ fv = ftbl_find_by_val_with_mask(clkp->freq_tbl, clkp->freq_mask,
+ freq_val);
+
+ spin_unlock_irqrestore(&clkp->lock, flags);
+
+ return fv ? fv->rate : 0;
+}
+
+static int clk_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_pll *clkp = to_clk_pll(hw);
+ const struct freq_table *fv;
+ unsigned long flags;
+ int ret;
+
+ fv = ftbl_find_by_rate(clkp->freq_tbl, rate);
+ if (!fv || fv->rate != rate)
+ return -EINVAL;
+
+ spin_lock_irqsave(&clkp->lock, flags);
+
+ if (clkp->seq_pre_set_freq) {
+ ret = regmap_multi_reg_write(clkp->clkr.regmap, clkp->seq_pre_set_freq,
+ clkp->num_seq_pre_set_freq);
+ if (ret)
+ goto unlock;
+ }
+
+ ret = regmap_update_bits(clkp->clkr.regmap, clkp->freq_reg,
+ clkp->freq_mask, fv->val);
+ if (ret)
+ goto unlock;
+
+ if (clkp->seq_post_set_freq) {
+ ret = regmap_multi_reg_write(clkp->clkr.regmap, clkp->seq_post_set_freq,
+ clkp->num_seq_post_set_freq);
+ if (ret)
+ goto unlock;
+ }
+
+ if (is_power_on(clkp)) {
+ ret = wait_freq_ready(clkp);
+ if (ret)
+ goto unlock;
+ }
+
+unlock:
+ spin_unlock_irqrestore(&clkp->lock, flags);
+
+ return ret;
+}
+
+static int clk_pll_enable(struct clk_hw *hw)
+{
+ struct clk_pll *clkp = to_clk_pll(hw);
+ unsigned long flags;
+ int ret = 0;
+
+ if (!clkp->seq_power_on)
+ return ret;
+
+ spin_lock_irqsave(&clkp->lock, flags);
+
+ if (is_power_on(clkp))
+ goto unlock;
+
+ ret = regmap_multi_reg_write(clkp->clkr.regmap, clkp->seq_power_on,
+ clkp->num_seq_power_on);
+ if (ret)
+ goto unlock;
+
+ ret = wait_freq_ready(clkp);
+ if (ret)
+ goto unlock;
+
+unlock:
+ spin_unlock_irqrestore(&clkp->lock, flags);
+
+ return ret;
+}
+
+const struct clk_ops rtk_clk_pll_ops = {
+ .enable = clk_pll_enable,
+ .disable = clk_pll_disable,
+ .is_enabled = clk_pll_is_enabled,
+ .recalc_rate = clk_pll_recalc_rate,
+ .determine_rate = clk_pll_determine_rate,
+ .set_rate = clk_pll_set_rate,
+};
+EXPORT_SYMBOL_NS_GPL(rtk_clk_pll_ops, "REALTEK_CLK");
+
+const struct clk_ops rtk_clk_pll_ro_ops = {
+ .recalc_rate = clk_pll_recalc_rate,
+};
+EXPORT_SYMBOL_NS_GPL(rtk_clk_pll_ro_ops, "REALTEK_CLK");
diff --git a/drivers/clk/realtek/clk-pll.h b/drivers/clk/realtek/clk-pll.h
new file mode 100644
index 000000000000..b70d6b3ec61e
--- /dev/null
+++ b/drivers/clk/realtek/clk-pll.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2017-2026 Realtek Semiconductor Corporation
+ * Author: Cheng-Yu Lee <cylee12@realtek.com>
+ */
+
+#ifndef __CLK_REALTEK_CLK_PLL_H
+#define __CLK_REALTEK_CLK_PLL_H
+
+#include <linux/spinlock.h>
+#include "clk-rtk-common.h"
+#include "freq_table.h"
+
+struct reg_sequence;
+
+struct clk_pll {
+ struct clk_regmap clkr;
+ const struct reg_sequence *seq_power_on;
+ u32 num_seq_power_on;
+ const struct reg_sequence *seq_power_off;
+ u32 num_seq_power_off;
+ const struct reg_sequence *seq_pre_set_freq;
+ u32 num_seq_pre_set_freq;
+ const struct reg_sequence *seq_post_set_freq;
+ u32 num_seq_post_set_freq;
+ const struct freq_table *freq_tbl;
+ u32 freq_reg;
+ u32 freq_mask;
+ u32 freq_ready_mask;
+ u32 freq_ready_reg;
+ u32 freq_ready_val;
+ u32 power_reg;
+ u32 power_mask;
+ u32 power_val_on;
+
+ /* This lock prevents race conditions when multiple CPUs or contexts
+ * simultaneously access this PLL's registers during multi-step operations
+ */
+ spinlock_t lock;
+};
+
+#define __clk_pll_hw(_ptr) __clk_regmap_hw(&(_ptr)->clkr)
+
+extern const struct clk_ops rtk_clk_pll_ops;
+extern const struct clk_ops rtk_clk_pll_ro_ops;
+
+#endif /* __CLK_REALTEK_CLK_PLL_H */
diff --git a/drivers/clk/realtek/freq_table.c b/drivers/clk/realtek/freq_table.c
new file mode 100644
index 000000000000..6ff8dbf60cc6
--- /dev/null
+++ b/drivers/clk/realtek/freq_table.c
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/bitops.h>
+#include "freq_table.h"
+
+#define IS_FREQ_TABLE_END(_f) ((_f)->rate == 0)
+
+const struct freq_table *ftbl_find_by_rate(const struct freq_table *ftbl,
+ unsigned long rate)
+{
+ const struct freq_table *best = NULL;
+ unsigned long best_rate = 0;
+
+ for (; !IS_FREQ_TABLE_END(ftbl); ftbl++) {
+ if (ftbl->rate == rate)
+ return ftbl;
+
+ if (ftbl->rate > rate)
+ continue;
+
+ if (ftbl->rate > best_rate) {
+ best_rate = ftbl->rate;
+ best = ftbl;
+ }
+ }
+
+ return best;
+}
+
+const struct freq_table *ftbl_find_ceil_by_rate(const struct freq_table *ftbl,
+ unsigned long rate)
+{
+ const struct freq_table *best = NULL;
+ unsigned long best_rate = ULONG_MAX;
+
+ for (; !IS_FREQ_TABLE_END(ftbl); ftbl++) {
+ if (ftbl->rate < rate)
+ continue;
+
+ if (ftbl->rate < best_rate) {
+ best_rate = ftbl->rate;
+ best = ftbl;
+ }
+ }
+
+ return best;
+}
+
+const struct freq_table *
+ftbl_find_by_val_with_mask(const struct freq_table *ftbl, u32 mask, u32 value)
+{
+ for (; !IS_FREQ_TABLE_END(ftbl); ftbl++) {
+ if ((ftbl->val & mask) == (value & mask))
+ return ftbl;
+ }
+ return NULL;
+}
diff --git a/drivers/clk/realtek/freq_table.h b/drivers/clk/realtek/freq_table.h
new file mode 100644
index 000000000000..78215aee3300
--- /dev/null
+++ b/drivers/clk/realtek/freq_table.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+struct freq_table {
+ u32 val;
+ unsigned long rate;
+};
+
+#define FREQ_TABLE_END \
+ { \
+ .rate = 0 \
+ }
+
+const struct freq_table *ftbl_find_by_rate(const struct freq_table *ftbl,
+ unsigned long rate);
+const struct freq_table *ftbl_find_ceil_by_rate(const struct freq_table *ftbl,
+ unsigned long rate);
+const struct freq_table *
+ftbl_find_by_val_with_mask(const struct freq_table *ftbl, u32 mask, u32 value);
--
2.43.0
^ permalink raw reply related
* [PATCH v9 07/12] clk: realtek: Add support for gate clock
From: Yu-Chun Lin @ 2026-06-24 11:29 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt, p.zabel, cylee12,
afaerber, jyanchou, bmasney
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-realtek-soc, james.tai, cy.huang, stanley_chang,
eleanor.lin
In-Reply-To: <20260624112940.3475605-1-eleanor.lin@realtek.com>
From: Cheng-Yu Lee <cylee12@realtek.com>
Introduce clk_regmap_gate_ops supporting enable, disable, is_enabled, and
for standard regmap gate clocks.
Add clk_regmap_gate_ro_ops as a read-only variant exposing only is_enabled.
Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v9:
- None.
---
drivers/clk/realtek/Makefile | 1 +
drivers/clk/realtek/clk-regmap-gate.c | 70 +++++++++++++++++++++++++++
drivers/clk/realtek/clk-regmap-gate.h | 65 +++++++++++++++++++++++++
3 files changed, 136 insertions(+)
create mode 100644 drivers/clk/realtek/clk-regmap-gate.c
create mode 100644 drivers/clk/realtek/clk-regmap-gate.h
diff --git a/drivers/clk/realtek/Makefile b/drivers/clk/realtek/Makefile
index 71edc18121c6..90c0658a83bf 100644
--- a/drivers/clk/realtek/Makefile
+++ b/drivers/clk/realtek/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_RTK_CLK_COMMON) += clk-rtk.o
clk-rtk-y += clk-rtk-common.o
clk-rtk-y += clk-pll.o
clk-rtk-y += freq_table.o
+clk-rtk-y += clk-regmap-gate.o
diff --git a/drivers/clk/realtek/clk-regmap-gate.c b/drivers/clk/realtek/clk-regmap-gate.c
new file mode 100644
index 000000000000..0db0057215e3
--- /dev/null
+++ b/drivers/clk/realtek/clk-regmap-gate.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2017-2026 Realtek Semiconductor Corporation
+ * Author: Cheng-Yu Lee <cylee12@realtek.com>
+ */
+
+#include <linux/bits.h>
+#include <linux/clk-provider.h>
+#include <linux/export.h>
+#include <linux/regmap.h>
+#include "clk-regmap-gate.h"
+
+static int clk_regmap_gate_enable(struct clk_hw *hw)
+{
+ struct clk_regmap_gate *clkg = to_clk_regmap_gate(hw);
+ unsigned int mask;
+ unsigned int val;
+
+ mask = BIT(clkg->bit_idx);
+ val = BIT(clkg->bit_idx);
+
+ if (clkg->write_en) {
+ mask |= BIT(clkg->bit_idx + 1);
+ val |= BIT(clkg->bit_idx + 1);
+ }
+
+ return regmap_update_bits(clkg->clkr.regmap, clkg->gate_ofs, mask, val);
+}
+
+static void clk_regmap_gate_disable(struct clk_hw *hw)
+{
+ struct clk_regmap_gate *clkg = to_clk_regmap_gate(hw);
+ unsigned int mask;
+ unsigned int val;
+
+ mask = BIT(clkg->bit_idx);
+ val = 0;
+
+ if (clkg->write_en) {
+ mask |= BIT(clkg->bit_idx + 1);
+ val |= BIT(clkg->bit_idx + 1);
+ }
+
+ regmap_update_bits(clkg->clkr.regmap, clkg->gate_ofs, mask, val);
+}
+
+static int clk_regmap_gate_is_enabled(struct clk_hw *hw)
+{
+ struct clk_regmap_gate *clkg = to_clk_regmap_gate(hw);
+ int ret;
+ u32 val;
+
+ ret = regmap_read(clkg->clkr.regmap, clkg->gate_ofs, &val);
+ if (ret < 0)
+ return ret;
+
+ return !!(val & BIT(clkg->bit_idx));
+}
+
+const struct clk_ops rtk_clk_regmap_gate_ops = {
+ .enable = clk_regmap_gate_enable,
+ .disable = clk_regmap_gate_disable,
+ .is_enabled = clk_regmap_gate_is_enabled,
+};
+EXPORT_SYMBOL_NS_GPL(rtk_clk_regmap_gate_ops, "REALTEK_CLK");
+
+const struct clk_ops rtk_clk_regmap_gate_ro_ops = {
+ .is_enabled = clk_regmap_gate_is_enabled,
+};
+EXPORT_SYMBOL_NS_GPL(rtk_clk_regmap_gate_ro_ops, "REALTEK_CLK");
diff --git a/drivers/clk/realtek/clk-regmap-gate.h b/drivers/clk/realtek/clk-regmap-gate.h
new file mode 100644
index 000000000000..3f4c7a784eb0
--- /dev/null
+++ b/drivers/clk/realtek/clk-regmap-gate.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2017-2026 Realtek Semiconductor Corporation
+ * Author: Cheng-Yu Lee <cylee12@realtek.com>
+ */
+
+#ifndef __CLK_REALTEK_CLK_REGMAP_GATE_H
+#define __CLK_REALTEK_CLK_REGMAP_GATE_H
+
+#include "clk-rtk-common.h"
+
+struct clk_regmap_gate {
+ struct clk_regmap clkr;
+ int gate_ofs;
+ u8 bit_idx;
+ u32 write_en : 1;
+};
+
+#define __clk_regmap_gate_hw(_p) __clk_regmap_hw(&(_p)->clkr)
+
+#define __CLK_REGMAP_GATE(_name, _parent, _ops, _flags, _ofs, _bit_idx, \
+ _write_en) \
+ struct clk_regmap_gate _name = { \
+ .clkr.hw.init = CLK_HW_INIT(#_name, _parent, _ops, _flags), \
+ .gate_ofs = _ofs, \
+ .bit_idx = _bit_idx, \
+ .write_en = _write_en, \
+ }
+
+#define CLK_REGMAP_GATE(_name, _parent, _flags, _ofs, _bit_idx, _write_en) \
+ __CLK_REGMAP_GATE(_name, _parent, &rtk_clk_regmap_gate_ops, _flags, _ofs, \
+ _bit_idx, _write_en)
+
+#define CLK_REGMAP_GATE_RO(_name, _parent, _flags, _ofs, _bit_idx, _write_en) \
+ __CLK_REGMAP_GATE(_name, _parent, &rtk_clk_regmap_gate_ro_ops, _flags, \
+ _ofs, _bit_idx, _write_en)
+
+#define __CLK_REGMAP_GATE_NO_PARENT(_name, _ops, _flags, _ofs, _bit_idx, \
+ _write_en) \
+ struct clk_regmap_gate _name = { \
+ .clkr.hw.init = CLK_HW_INIT_NO_PARENT(#_name, _ops, _flags), \
+ .gate_ofs = _ofs, \
+ .bit_idx = _bit_idx, \
+ .write_en = _write_en, \
+ }
+
+#define CLK_REGMAP_GATE_NO_PARENT(_name, _flags, _ofs, _bit_idx, _write_en) \
+ __CLK_REGMAP_GATE_NO_PARENT(_name, &rtk_clk_regmap_gate_ops, _flags, _ofs, \
+ _bit_idx, _write_en)
+
+#define CLK_REGMAP_GATE_NO_PARENT_RO(_name, _flags, _ofs, _bit_idx, _write_en) \
+ __CLK_REGMAP_GATE_NO_PARENT(_name, &rtk_clk_regmap_gate_ro_ops, _flags, \
+ _ofs, _bit_idx, _write_en)
+
+static inline struct clk_regmap_gate *to_clk_regmap_gate(struct clk_hw *hw)
+{
+ struct clk_regmap *clkr = to_clk_regmap(hw);
+
+ return container_of(clkr, struct clk_regmap_gate, clkr);
+}
+
+extern const struct clk_ops rtk_clk_regmap_gate_ops;
+extern const struct clk_ops rtk_clk_regmap_gate_ro_ops;
+
+#endif /* __CLK_REALTEK_CLK_REGMAP_GATE_H */
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox