* [PATCH] arm64: dts: aspeed: Fix duplicate pinctrl labels and address scheme
From: Ryan Chen @ 2026-06-11 6:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Arnd Bergmann
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Ryan Chen
Fix duplicate pinctrl_tach{0-15} and pinctrl_n{cts,dcd,dsr,ri}5 labels
in aspeed-g7-soc1-pinctrl.dtsi.
Drop the cpu-index from secondary/tertiary container nodes: reduce the
"#address-cells" from 2 to 1 and update ssp_nvic/tsp_nvic unit-address
and reg accordingly. Also remove URL comments from the DTS.
Suggested-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Fixes: e77bb5dc5759 ("arm64: dts: aspeed: Add initial AST27xx SoC device tree")
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
This series contains follow-up fixes for the AST27xx DTS support that
was merged into linux-next (e77bb5dc5759).
Two issues were identified after merge by Andrew Jeffery during review
of the pending v11 series:
1. Duplicate pinctrl state labels in aspeed-g7-soc1-pinctrl.dtsi caused
dtc to abort with fatal label-redefinition errors.
2. The synthetic container nodes (secondary, tertiary) for sub-processor
interrupt controllers used a 2-cell address scheme to encode a
<cpu-index reg-base> tuple. Since the cpu-index adds no value for
nodes that are purely phandle anchors, Andrew requested we drop it
and use the bare register address instead.
---
arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi | 14 ++-
.../boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi | 102 ---------------------
2 files changed, 6 insertions(+), 110 deletions(-)
diff --git a/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
index ef283d95649a..58193c3c3696 100644
--- a/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
+++ b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
@@ -84,32 +84,30 @@ l2: l2-cache0 {
};
secondary {
- #address-cells = <2>;
- /* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/of/address.c?h=v6.16#n491 */
+ #address-cells = <1>;
#size-cells = <0>;
- /* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/of/address.c?h=v6.16#n430 */
- ssp_nvic: interrupt-controller@1,e000e100 {
+ ssp_nvic: interrupt-controller@e000e100 {
compatible = "arm,v7m-nvic";
#interrupt-cells = <2>;
#address-cells = <0>;
interrupt-controller;
- reg = <1 0xe000e100>;
+ reg = <0xe000e100>;
arm,num-irq-priority-bits = <3>;
status = "disabled";
};
};
tertiary {
- #address-cells = <2>;
+ #address-cells = <1>;
#size-cells = <0>;
- tsp_nvic: interrupt-controller@2,e000e100 {
+ tsp_nvic: interrupt-controller@e000e100 {
compatible = "arm,v7m-nvic";
#interrupt-cells = <2>;
#address-cells = <0>;
interrupt-controller;
- reg = <2 0xe000e100>;
+ reg = <0xe000e100>;
arm,num-irq-priority-bits = <3>;
status = "disabled";
};
diff --git a/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi b/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
index 72d93323593d..6edf14617b09 100644
--- a/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
@@ -496,87 +496,6 @@ pinctrl_hvi3c15_default: hvi3c15-default-state {
function = "I3C15";
groups = "HVI3C15";
};
-
- pinctrl_tach0_default: tach0-default-state {
- function = "TACH0";
- groups = "TACH0";
- };
-
- pinctrl_tach1_default: tach1-default-state {
- function = "TACH1";
- groups = "TACH1";
- };
-
- pinctrl_tach2_default: tach2-default-state {
- function = "TACH2";
- groups = "TACH2";
- };
-
- pinctrl_tach3_default: tach3-default-state {
- function = "TACH3";
- groups = "TACH3";
- };
-
- pinctrl_tach4_default: tach4-default-state {
- function = "TACH4";
- groups = "TACH4";
- };
-
- pinctrl_tach5_default: tach5-default-state {
- function = "TACH5";
- groups = "TACH5";
- };
-
- pinctrl_tach6_default: tach6-default-state {
- function = "TACH6";
- groups = "TACH6";
- };
-
- pinctrl_tach7_default: tach7-default-state {
- function = "TACH7";
- groups = "TACH7";
- };
-
- pinctrl_tach8_default: tach8-default-state {
- function = "TACH8";
- groups = "TACH8";
- };
-
- pinctrl_tach9_default: tach9-default-state {
- function = "TACH9";
- groups = "TACH9";
- };
-
- pinctrl_tach10_default: tach10-default-state {
- function = "TACH10";
- groups = "TACH10";
- };
-
- pinctrl_tach11_default: tach11-default-state {
- function = "TACH11";
- groups = "TACH11";
- };
-
- pinctrl_tach12_default: tach12-default-state {
- function = "TACH12";
- groups = "TACH12";
- };
-
- pinctrl_tach13_default: tach13-default-state {
- function = "TACH13";
- groups = "TACH13";
- };
-
- pinctrl_tach14_default: tach14-default-state {
- function = "TACH14";
- groups = "TACH14";
- };
-
- pinctrl_tach15_default: tach15-default-state {
- function = "TACH15";
- groups = "TACH15";
- };
-
pinctrl_thru0_default: thru0-default-state {
function = "THRU0";
groups = "THRU0";
@@ -940,27 +859,6 @@ pinctrl_uart3_default: uart3-default-state {
function = "UART3";
groups = "UART3";
};
-
- pinctrl_ncts5_default: ncts5-default-state {
- function = "NCTS5";
- groups = "NCTS5";
- };
-
- pinctrl_ndcd5_default: ndcd5-default-state {
- function = "NDCD5";
- groups = "NDCD5";
- };
-
- pinctrl_ndsr5_default: ndsr5-default-state {
- function = "NDSR5";
- groups = "NDSR5";
- };
-
- pinctrl_nri5_default: nri5-default-state {
- function = "NRI5";
- groups = "NRI5";
- };
-
pinctrl_ndtr5_default: ndtr5-default-state {
function = "NDTR5";
groups = "NDTR5";
---
base-commit: abe651837cb394f76d738a7a747322fca3bf17ba
change-id: 20260611-dtsi_fix-099b11a321b5
Best regards,
--
Ryan Chen <ryan_chen@aspeedtech.com>
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: iio: sensirion,sps30: Add myself as maintainer
From: Krzysztof Kozlowski @ 2026-06-11 6:48 UTC (permalink / raw)
To: Maxwell Doose
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duzsynski
In-Reply-To: <CAKqfh0GNcOAtW2wEBPhKi2GwdVAJNGcgjdJVidQYvOF7oJ2HVA@mail.gmail.com>
On 11/06/2026 00:27, Maxwell Doose wrote:
> On Wed, Jun 10, 2026 at 4:10 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On Tue, Jun 09, 2026 at 11:17:00AM -0500, Maxwell Doose wrote:
>>> Tomasz's entry is no longer valid, as he is not active anymore. Add
>>> myself as maintainer for the SPS30 to replace his entry.
>>>
>>> Link: https://lore.kernel.org/linux-iio/20260609140712.2e5d1640@jic23-huawei/
>>> Cc: Tomasz Duzsynski <tduszyns@gmail.com>
>>> Signed-off-by: Maxwell Doose <m32285159@gmail.com>
>>> ---
>>> .../devicetree/bindings/iio/chemical/sensirion,sps30.yaml | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> How many separate patches are you going to send?
>>
>
> Sorry. I guess the reason these are separate patches is because these
> are basically across two different subsystems (iio and dt-bindings). I
> ought to quit doing this.
You sent four patches, not two.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: pinctrl: qcom,pmic-gpio: Add Qualcomm PMK7750
From: Krzysztof Kozlowski @ 2026-06-11 6:45 UTC (permalink / raw)
To: sashiko-reviews; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260610125349.55A6D1F00893@smtp.kernel.org>
On 10/06/2026 14:53, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] The new `qcom,pmk7750-gpio` compatible string is missing from the C driver's OF match table, and the binding schema prevents using a functional fallback, making the hardware impossible to probe.
I will simply add fallback.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Add myself as maintainer for PMS7003
From: Krzysztof Kozlowski @ 2026-06-11 6:37 UTC (permalink / raw)
To: Maxwell Doose
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duszynski
In-Reply-To: <CAKqfh0Hi8EkShh3s4dUqAJRDExQLR0NVOvd4An+bY5hat4-Lhw@mail.gmail.com>
On 11/06/2026 00:24, Maxwell Doose wrote:
> On Wed, Jun 10, 2026 at 4:09 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On Tue, Jun 09, 2026 at 11:03:26AM -0500, Maxwell Doose wrote:
>>> Tomasz's entry is no longer valid, as he is not active anymore. Add
>>
>> Why is not longer valid? I see activity in Feb...
>>
>
> Strange. According to git log --author="Tomasz Duszynski" last commit
> I have from him is 2023. We also did have an RFC open for a month on
> linux-iio with Tomasz Cced with no response.
So you did not check enough... and no one needs to read RFC :/
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 00/13] Enable I2C on SA8255p Qualcomm platforms
From: Praveen Talari @ 2026-06-11 6:26 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Mukesh Kumar Savaliya, Viken Dadhaniya, Konrad Dybcio,
linux-arm-msm, linux-i2c, devicetree, linux-kernel,
bjorn.andersson, dmitry.baryshkov, konrad.dybcio, prasad.sodagudi,
aniket.randive, chandana.chiluveru, jyothi.seerapu,
chiluka.harish
In-Reply-To: <ahEObi9ubGaTEcwK@baldur>
Hi Andi.
On 23-05-2026 07:49, Bjorn Andersson wrote:
> On Fri, Feb 27, 2026 at 11:45:31AM +0530, Praveen Talari wrote:
>> The Qualcomm automotive SA8255p SoC relies on firmware to configure
>> platform resources, including clocks, interconnects and TLMM.
>> The driver requests resources operations over SCMI using power
>> and performance protocols.
>>
>> The SCMI power protocol enables or disables resources like clocks,
>> interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
>> such as resume/suspend, to control power states(on/off).
>>
>> The SCMI performance protocol manages I2C frequency, with each
>> frequency rate represented by a performance level. The driver uses
>> geni_se_set_perf_opp() API to request the desired frequency rate..
>>
>> As part of geni_se_set_perf_opp(), the OPP for the requested frequency
>> is obtained using dev_pm_opp_find_freq_floor() and the performance
>> level is set using dev_pm_opp_set_opp().
>>
> @Andi, I've merged the soc-patches through an immutable branch into the
> qcom-tree for 7.2, please find this at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git 20260227061544.1785978-1-praveen.talari@oss.qualcomm.com
>
> Regards,
> Bjorn
@Andi
I hope these I2C patches can be picked up now.
Feedback is welcome if anything further is needed.
Thanks,
Praveen Talari
>
>> Praveen Talari (13):
>> soc: qcom: geni-se: Refactor geni_icc_get() and make qup-memory ICC
>> path optional
>> soc: qcom: geni-se: Add geni_icc_set_bw_ab() function
>> soc: qcom: geni-se: Introduce helper API for resource initialization
>> soc: qcom: geni-se: Handle core clk in geni_se_clks_off() and
>> geni_se_clks_on()
>> soc: qcom: geni-se: Add resources activation/deactivation helpers
>> soc: qcom: geni-se: Introduce helper API for attaching power domains
>> soc: qcom: geni-se: Introduce helper APIs for performance control
>> dt-bindings: i2c: Describe SA8255p
>> i2c: qcom-geni: Isolate serial engine setup
>> i2c: qcom-geni: Move resource initialization to separate function
>> i2c: qcom-geni: Use resources helper APIs in runtime PM functions
>> i2c: qcom-geni: Store of_device_id data in driver private struct
>> i2c: qcom-geni: Enable I2C on SA8255p Qualcomm platforms
>> ---
>> v3->v4
>> - Added a new patch(4/13) to handle core clk as part of
>> geni_se_clks_off/on().
>>
>> .../bindings/i2c/qcom,sa8255p-geni-i2c.yaml | 64 ++++
>> drivers/i2c/busses/i2c-qcom-geni.c | 324 +++++++++---------
>> drivers/soc/qcom/qcom-geni-se.c | 270 ++++++++++++++-
>> include/linux/soc/qcom/geni-se.h | 19 +
>> 4 files changed, 491 insertions(+), 186 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/i2c/qcom,sa8255p-geni-i2c.yaml
>>
>>
>> base-commit: 7d6661873f6b54c75195780a40d66bad3d482d8f
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: display: panel: himax,hx83121a: add optional bl supply
From: Icenowy Zheng @ 2026-06-11 6:15 UTC (permalink / raw)
To: Pengyu Luo
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown,
dri-devel, devicetree, linux-kernel
In-Reply-To: <CAH2e8h7oDLO4isyPOY3syEQLMrcCGiGmkKsAYvtEz+qoT9-N_w@mail.gmail.com>
在 2026-06-11四的 13:45 +0800，Pengyu Luo写道：
> On Thu, Jun 11, 2026 at 1:36 PM Icenowy Zheng
> <zhengxingda@iscas.ac.cn> wrote:
> >
> > 在 2026-06-11四的 13:26 +0800，Pengyu Luo写道：
> > > On Tue, 09 Jun 2026 00:26:20 +0800, Icenowy Zheng
> > > <zhengxingda@iscas.ac.cn> wrote:
> > > > When the backlight is managed by the panel controller IC, an
> > > > external
> > > > power rail might be powering the backlight.
> > > >
> > > > Add an optional `bl-supply` property to describe such power
> > > > rail,
> > > > thus
> > > > allow disabling the backlight.
> > > >
> > >
> > > Please add it as a hwen pin, this will simplify your code later.
> >
> > I am not sure whether this should be a pin or a regulator -- the DT
> > binding should reflect the HW fact, and LCD panel backlights
> > usually
> > require a high voltage (or even a current source) that is driven by
> > a
> > dedicated regulator.
> >
>
> Most backlight ICs use a hwen pin to enable the supply, afaik, like
> ktz8866, ktz8868, aw99706, etc. We don't touch the VIN. (My
> disclaimer:
> I am just an amateur, know less about the circuit)
I found some specificiation of a LCD panel using DCS brightness to
control backlight at [1] (this panel is supported by panel-himax-
hx83102 driver), and it has no HWEN pins -- the pins related to
backlight seem to be LED_{C2,C1,A} and PWM, which means a backlight
regulator must be present.
Although the situation is a little odd -- the regulator isn't a fixed
one, but a adjustable one adjusted by the panel.
Thanks,
Icenowy
[1]
https://www.scribd.com/presentation/759684395/Titan20-TP-LCM-SPEC-XT2073-Motorola-one-fusion
>
> Best wishes,
> Pengyu
>
> > Thanks,
> > Icenowy
> >
> > >
> > > >
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/display/panel/himax,hx83121
> > > > a.ya
> > > > ml
> > > > b/Documentation/devicetree/bindings/display/panel/himax,hx83121
> > > > a.ya
> > > > ml
> > > > index e067a2f6d0b2..aeca3c9a599c 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/display/panel/himax,hx83121
> > > > a.ya
> > > > ml
> > > > +++
> > > > b/Documentation/devicetree/bindings/display/panel/himax,hx83121
> > > > a.ya
> > > > ml
> > > > @@ -40,6 +40,9 @@ properties:
> > > > vddi-supply:
> > > > description: power supply for IC
> > > >
> > > > + bl-supply:
> > > > + description: power supply for backlight, in case it's
> > > > managed
> > > > via DSC
> > > > +
> > >
> > > s/DSC/DCS/
> > >
> > > Best wishes,
> > > Pengyu
> >
^ permalink raw reply
* Re: [PATCH v2 6/7] arm64: dts: qcom: sm8350: modernize PCIe entries
From: Manivannan Sadhasivam @ 2026-06-11 6:13 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Lorenzo Pieralisi, Krzysztof Wilczyński, Rob Herring,
Bjorn Helgaas, Konrad Dybcio, Qiang Yu, Jeff Johnson,
Liam Girdwood, Mark Brown, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-pci, linux-kernel,
linux-wireless, ath11k, devicetree, Bartosz Golaszewski,
linux-bluetooth, Bartosz Golaszewski
In-Reply-To: <20260608-sm8350-wifi-v2-6-efb68f1ff04c@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 09:59:24AM +0300, Dmitry Baryshkov wrote:
> The recent suggestion is to have PERST# / WAKE pins and PHYs in the PCIe
> port rather than RC device. The kernel recently started warning about
> the older style of DT. Modernize DT for SM8350 platform by moving the
> entries under the root port device node.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 18 +++++++++++-------
> arch/arm64/boot/dts/qcom/sm8350.dtsi | 12 ++++--------
> 2 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
> index 5f975d009465..4973a3eb11b5 100644
> --- a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
> @@ -493,12 +493,14 @@ &pcie0 {
> pinctrl-names = "default";
> pinctrl-0 = <&pcie0_default_state>;
>
> - perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> -
> status = "okay";
> };
>
> +&pcie0_port0 {
> + reset-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> +};
> +
> &pcie0_phy {
> vdda-phy-supply = <&vreg_l5b_0p88>;
> vdda-pll-supply = <&vreg_l6b_1p2>;
> @@ -507,15 +509,17 @@ &pcie0_phy {
> };
>
> &pcie1 {
> - perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
> -
> - pinctrl-names = "default";
> pinctrl-0 = <&pcie1_default_state>;
> + pinctrl-names = "default";
>
> status = "okay";
> };
>
> +&pcie1_port0 {
> + reset-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
> +};
> +
> &pcie1_phy {
> status = "okay";
> vdda-phy-supply = <&vreg_l5b_0p88>;
> diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> index eb2a795d8edb..136daa444865 100644
> --- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> @@ -1583,12 +1583,9 @@ pcie0: pcie@1c00000 {
>
> power-domains = <&gcc PCIE_0_GDSC>;
>
> - phys = <&pcie0_phy>;
> - phy-names = "pciephy";
> -
> status = "disabled";
>
> - pcie@0 {
> + pcie0_port0: pcie@0 {
> device_type = "pci";
> reg = <0x0 0x0 0x0 0x0 0x0>;
> bus-range = <0x01 0xff>;
> @@ -1596,6 +1593,7 @@ pcie@0 {
> #address-cells = <3>;
> #size-cells = <2>;
> ranges;
> + phys = <&pcie0_phy>;
> };
> };
>
> @@ -1692,12 +1690,9 @@ pcie1: pcie@1c08000 {
>
> power-domains = <&gcc PCIE_1_GDSC>;
>
> - phys = <&pcie1_phy>;
> - phy-names = "pciephy";
> -
> status = "disabled";
>
> - pcie@0 {
> + pcie1_port0: pcie@0 {
> device_type = "pci";
> reg = <0x0 0x0 0x0 0x0 0x0>;
> bus-range = <0x01 0xff>;
> @@ -1705,6 +1700,7 @@ pcie@0 {
> #address-cells = <3>;
> #size-cells = <2>;
> ranges;
> + phys = <&pcie1_phy>;
> };
> };
>
>
> --
> 2.47.3
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 1/7] PCI: qcom: fix parsing of PERST# in the legacy case
From: Manivannan Sadhasivam @ 2026-06-11 6:12 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Lorenzo Pieralisi, Krzysztof Wilczyński, Rob Herring,
Bjorn Helgaas, Konrad Dybcio, Qiang Yu, Jeff Johnson,
Liam Girdwood, Mark Brown, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-pci, linux-kernel,
linux-wireless, ath11k, devicetree, Bartosz Golaszewski,
linux-bluetooth
In-Reply-To: <20260608-sm8350-wifi-v2-1-efb68f1ff04c@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 09:59:19AM +0300, Dmitry Baryshkov wrote:
> Commit deed8aec62dc ("PCI: qcom: Handle mixed PERST#/PHY DT
> configuration") fixed support for the "mixed" platforms which declare
> PERST# pin the RC node and the PHY in the RP node, however it also broke
> support for a majority of existing platforms, which declare both PERST#
> and PHY in the RC node, because now PERST# is first acquired in
> qcom_pcie_parse_ports(), which then returns -ENODEV (as there are no
> PHYs in the RP nodes). Later qcom_pcie_parse_legacy_binding() tries to
> acquire the PERST# GPIO again and fails with -EBUSY (as the GPIO has
> already been requested).
>
> Move parsing of RC's perst-gpios to qcom_pcie_probe(), making it obvious
> that it's shared for both cases and skip parsing it in both functions.
>
> Fixes: deed8aec62dc ("PCI: qcom: Handle mixed PERST#/PHY DT configuration")
> Closes: https://lore.kernel.org/r/gieaybsg2ckxpctvqj77nlwu7utama2yeyvebkonmexsxrra3v@v3fobqasxnmy/
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
This issue is fixed now. You can drop this patch in next revision.
- Mani
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 25 ++++++++++---------------
> 1 file changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index 11fc60489892..7664c7c28c0e 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -1907,15 +1907,6 @@ static int qcom_pcie_parse_ports(struct qcom_pcie *pcie)
> struct device *dev = pcie->pci->dev;
> int ret = -ENODEV;
>
> - if (of_find_property(dev->of_node, "perst-gpios", NULL)) {
> - pcie->reset = devm_gpiod_get_optional(dev, "perst",
> - GPIOD_OUT_HIGH);
> - if (IS_ERR(pcie->reset))
> - return PTR_ERR(pcie->reset);
> -
> - dev_warn(dev, "Reusing PERST# from Root Complex node. DT needs to be fixed!\n");
> - }
> -
> for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> if (!of_node_is_type(of_port, "pci"))
> continue;
> @@ -1942,7 +1933,6 @@ static int qcom_pcie_parse_legacy_binding(struct qcom_pcie *pcie)
> struct device *dev = pcie->pci->dev;
> struct qcom_pcie_perst *perst;
> struct qcom_pcie_port *port;
> - struct gpio_desc *reset;
> struct phy *phy;
> int ret;
>
> @@ -1950,10 +1940,6 @@ static int qcom_pcie_parse_legacy_binding(struct qcom_pcie *pcie)
> if (IS_ERR(phy))
> return PTR_ERR(phy);
>
> - reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_HIGH);
> - if (IS_ERR(reset))
> - return PTR_ERR(reset);
> -
> ret = phy_init(phy);
> if (ret)
> return ret;
> @@ -1970,7 +1956,7 @@ static int qcom_pcie_parse_legacy_binding(struct qcom_pcie *pcie)
> INIT_LIST_HEAD(&port->list);
> list_add_tail(&port->list, &pcie->ports);
>
> - perst->desc = reset;
> + perst->desc = pcie->reset;
> INIT_LIST_HEAD(&port->perst);
> INIT_LIST_HEAD(&perst->list);
> list_add_tail(&perst->list, &port->perst);
> @@ -2107,6 +2093,15 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>
> pp->ops = &qcom_pcie_dw_ops;
>
> + if (of_find_property(dev->of_node, "perst-gpios", NULL)) {
> + pcie->reset = devm_gpiod_get_optional(dev, "perst",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(pcie->reset))
> + return PTR_ERR(pcie->reset);
> +
> + dev_warn(dev, "Reusing PERST# from Root Complex node. DT needs to be updated!\n");
> + }
> +
> ret = qcom_pcie_parse_ports(pcie);
> if (ret) {
> if (ret != -ENODEV) {
>
> --
> 2.47.3
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: connector: pcie-m2-e: Add 3.3Vaux supply support
From: Manivannan Sadhasivam @ 2026-06-11 6:10 UTC (permalink / raw)
To: Sherry Sun
Cc: Krzysztof Kozlowski, sashiko-reviews@lists.linux.dev,
manivannan.sadhasivam@oss.qualcomm.com, linux-pci@vger.kernel.org,
robh@kernel.org, Frank.Li@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev
In-Reply-To: <VI0PR04MB12114DA25D08329D3DC2C3ADA921B2@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Thu, Jun 11, 2026 at 03:59:28AM +0000, Sherry Sun wrote:
> > On Wed, Jun 10, 2026 at 10:13:00AM +0000, Sherry Sun wrote:
> > > > On Wed, Jun 10, 2026 at 08:40:54AM +0000, Sherry Sun wrote:
> > > > > > On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org
> > wrote:
> > > > > > > Thank you for your contribution! Sashiko AI review found 1
> > > > > > > potential
> > > > > > issue(s) to consider:
> > > > > > > - [Medium] The `vpcie3v3aux-supply` property describes a
> > > > > > > non-existent
> > > > > > hardware feature on the M.2 Key E connector to work around a
> > > > > > software policy.
> > > > > >
> > > > > > Feels valid. Describe which pin on M2 connector are you representing.
> > > > > >
> > > > >
> > > > > Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power Sources
> > > > > and Grounds.
> > > > >
> > > > > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The
> > > > > voltage source, 3.3 V, is expected to be available during the
> > > > > system’s stand-by/suspend state to support wake event processing
> > > > > on the communications card.
> > > > >
> > > > > But the current vpcie3v3-supply may be gated off during system
> > suspend.
> > > > > So I tried to add vpcie3v3aux-supply to let this 3.3 V power
> > > > > source always on for PCIe M.2 Key E connector. That means
> > > > > vpcie3v3aux-supply and vpcie3v3-supply actually refer to the same 3.3 V
> > power source.
> > > > >
> > > > > @Mani, do you think this is reasonable? Or do you have any other
> > > > > better solutions? Thanks!
> > > > >
> > > >
> > > > There is no Vaux defined in the M.2 spec. So you cannot define that
> > > > supply in the binding. You can define the custom Vaux supply as a
> > > > fixed regulator in DT and mark it always on so that it is keeps supplying
> > 3.3v to the card.
> > > >
> > >
> > > Hi Mani, thanks for the suggestion, but adding an always on regulator
> > > may cause board power waste, current solution ensures the 3.3v
> > > regulator is only enabled when M.2 connector needs to work .
> > >
> >
> > What do you mean by 'need to work'? For getting the M.2 card to work, you
> > already have 3.3v supply. If you want the board to be always ON, then you
> > need to supply 3.3Vaux, which should be always ON too.
> >
> > But who is turning off vpcie3v3-supply? M.2 connector driver or the
> > platform?
> >
>
> Hi Mani,
> I'm not sure if I understand your question correctly, actually it's the platform
> driver that calls the M.2 connector driver to turn off vpcie3v3-supply.
> Take i.MX pci device as an example,
> pm_suspend() -> imx_pcie_suspend_noirq() -> imx_pcie_host_exit() ->
> pci_pwrctrl_power_off_devices() -> pwrseq_power_off() ->
> pwrseq_unit_disable() -> pwrseq_pcie_m2_vregs_disable()
>
> Taking back to M.2 Specification:
> PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The
> voltage source, 3.3 V, is expected to be available during the
> system’s stand-by/suspend state to support wake event processing
> on the communications card.
>
> Per my understanding of the above, the M.2 Spec actually suggest the
> 3.3 V power source should not be turned off.
> Should we simply enable the 3.3 V power source in pwrseq_pcie_m2_probe()
> and remove the pwrseq_pcie_m2_vregs_unit_data?
>
Just don't call pci_pwrctrl_power_off_devices() from the suspend path.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 0/6] arm64: dts: qcom: sc8280xp: set GPI DMA channels according to DSDT
From: Pengyu Luo @ 2026-06-11 5:55 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <bd5ad1b53eb009377d0ee492b0e007e45d36f6a1.camel@iscas.ac.cn>
On Sun, Jun 7, 2026 at 4:49 PM Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
>
> 在 2026-06-06六的 21:51 +0800，Pengyu Luo写道：
> > On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng
> > <zhengxingda@iscas.ac.cn> wrote:
> > >
> > > 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
> > > > On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
> > > > > 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
> > > > >
> > > > > > On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
> > > > > >
> > > > > > The magnetic keyboard (USB HID) can't be connected somehow,
> > > > > > others
> > > > > > are
> > > > > > fine, such as the spi touchscreen (not upstream yet), which
> > > > > > utilizes
> > > > > > DMA definitely. My config is here
> > > > > > https://pastebin.com/SdjuyJYk
> > > > >
> > > > > Is this a defconfig?
> > > > >
> > > >
> > > > Yes.
> > > >
> > > > > BTW it seems that CONFIG_ASYNC_TX_DMA needs to be selected too
> > > > > for
> > > > > exhibiting the problem (because there should be "public" GPI
> > > > > DMA
> > > > > consumers to trigger the stuck/reset).
> > > > >
> > > >
> > > > Is this still necessary? I checked the fedora discussion and your
> > > > GPI
> > > > DMA fix. And GPI DMA is only for the QUP-supported peripherals as
> > > > the
> > > > binding mentioned, devicetree/bindings/dma/qcom,gpi.yaml
> > >
> > > The devicetree without this fix seems to be still incorrect,
> > > because
> > > with the device tree fix even if the GPI DMA driver misbehaves the
> > > system won't be stuck (although it will iterate all GPI channels
> > > and
> > > then fail to function at all).
> > >
> >
> > Back to the start. You said some GPI interfaces aren't available to
> > HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did a quick test,
> > and spi6 consumed it, no stuck or reset. Could you give me a
> > unavailable channel?
>
> I think channel 0b10000 of gpi_dma2 could be an example?
>
> It seems that 4 channels are tried on gpi_dma2 before hang on my
> gaokun3, but as gaokun3 has no known serial access, it's possible that
> 0b100000 or 0b1000 is problematic.
>
I see. I may test it on the weekend. Thanks!
Best wishes,
Pengyu
> (The reason gpi_dma2 is checked first is because it's the GPI DMA
> controller with the smallest address)
>
> BTW I just took the values from Windows DSDT, which is quite
> conservative.
>
> Thanks,
> Icenowy
>
> >
> > Best wishes,
> > Pengyu
>
^ permalink raw reply
* Re: [PATCH 3/3] drm/panel: himax-hx83121a: add backlight regulator support
From: Pengyu Luo @ 2026-06-11 5:51 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown,
dri-devel, devicetree, linux-kernel
In-Reply-To: <69a18fd1a1b9f375bbccfbe0d9e88ab31a01a188.camel@iscas.ac.cn>
On Thu, Jun 11, 2026 at 1:43 PM Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
>
> 在 2026-06-11四的 13:26 +0800，Pengyu Luo写道：
> > On Tue, 09 Jun 2026 00:26:22 +0800, Icenowy Zheng
> > <zhengxingda@iscas.ac.cn> wrote:
> > > diff --git a/drivers/gpu/drm/panel/panel-himax-hx83121a.c
> > > b/drivers/gpu/drm/panel/panel-himax-hx83121a.c
> > > index 1a7e0125bced..e31e2fba0a78 100644
> > > --- a/drivers/gpu/drm/panel/panel-himax-hx83121a.c
> > > +++ b/drivers/gpu/drm/panel/panel-himax-hx83121a.c
> > > @@ -195,7 +197,27 @@ static int himax_bl_update_status(struct
> > > backlight_device *bl)
> > > [ ... skip 18 lines ... ]
> > > + ret = regulator_enable(ctx->bl_supply);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ctx->backlight_enabled = true;
> > > +
> >
> > If you use a pin, (it is indeed a hwen pin as we know) you can
> > simplify it like this,
> >
> > bool bl_enable_now = !!brightness;
> >
> > if (ctx->bl_enable != bl_enable_now) {
> > gpiod_set_value(ctx->hwen_gpio, bl_enable_now);
> > ctx->bl_enable = bl_enable_now;
> > }
> >
> > BTW, iirc, panel bias can be turned off too, although I don't think
> > this will save too much power.
>
> BTW during my test, it seems that DCS backlight 0 isn't turning off
> backlight.
>
Yes, there is a hwen pin to turn off BL. In the downstream, I added
it, no time to upstream it, I forgot to add display DT too. I meant
you can turn off panel bias too, if you turn off BL. In general, I
turn off it in drm_panel_unprepare()
Best wishes,
Pengyu
^ permalink raw reply
* Re: [net-next 3/3] arm64: dts: renesas: r8a779g0: Add gPTP node
From: Niklas Söderlund @ 2026-06-11 5:52 UTC (permalink / raw)
To: sashiko-reviews; +Cc: robh, devicetree, conor+dt, wsa+renesas
In-Reply-To: <20260610215741.431DE1F00893@smtp.kernel.org>
Hello,
On 2026-06-10 21:57:40 +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Device Tree Resource Conflict due to overlapping memory, clock, and reset regions between `tsn0` and `gptp`.
> --
>
> commit 225abba0fdcd1f7e4ebd535f168ba1447d871a7e
> Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>
> arm64: dts: renesas: r8a779g0: Add gPTP node
>
> The gPTP module is shared between the RAVB and RTSN Ethernet devices on
> the SoC.
>
> > diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> > index 82a7278836e57..758c4ca0ae5f2 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> > @@ -603,6 +603,15 @@ tsn0: ethernet@e6460000 {
> > status = "disabled";
> > };
> >
> > + gptp: gptp@e6449000 {
> > + compatible = "renesas,r8a779g0-gptp", "renesas,rcar-gen4-gptp";
> > + reg = <0 0xe6449000 0 0x500>;
> > + clocks = <&cpg CPG_MOD 2723>;
> > + power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> > + resets = <&cpg 2723>;
>
> [Severity: High]
> Will this introduce a regression by duplicating resources already claimed by
> the existing tsn0 node?
Yes.
That is the idea of this work. To break free the ptp memory region from
the RTSN (on V4H) and RSWITCH (on S4) so it can be shared with RAVB.
This is discussed in the cover letter of the series.
>
> Looking at the tsn0 node earlier in this file:
>
> tsn0: ethernet@e6460000 {
> compatible = "renesas,r8a779g0-ethertsn", "renesas,rcar-gen4-ethertsn";
> reg = <0 0xe6460000 0 0x7000>,
> <0 0xe6449000 0 0x500>;
> reg-names = "tsnes", "gptp";
> interrupts = <GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "tx", "rx";
> clocks = <&cpg CPG_MOD 2723>;
> power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> resets = <&cpg 2723>;
> status = "disabled";
> };
>
> It appears tsn0 already claims the 0xe6449000 memory region, CPG_MOD 2723 clock,
> and reset 2723.
>
> If both drivers are enabled, will the second driver to probe fail when
> requesting these overlapping resources, such as receiving -EBUSY from
> devm_ioremap_resource() or request_mem_region()?
>
> Should the overlapping resources be removed from the tsn0 node now that the
> gPTP module is represented as a standalone shared node?
>
> > + status = "disabled";
> > + };
> > +
> > i2c0: i2c@e6500000 {
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260609215711.2960150-4-niklas.soderlund+renesas@ragnatech.se?part=1
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
* Re: (subset) [PATCH v6 0/2] riscv: sophgo: allow DMA multiplexer set channel number for DMA controller
From: Vinod Koul @ 2026-06-11 5:51 UTC (permalink / raw)
To: Eugeniy Paltsev, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen Wang, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Alexander Sverdlin, Longbin Li, Yixun Lan,
Anton D. Stavinskii, Inochi Amaoto
Cc: dmaengine, devicetree, linux-kernel, sophgo, linux-riscv,
Yixun Lan
In-Reply-To: <20260511063818.463877-1-inochiama@gmail.com>
On Mon, 11 May 2026 14:38:15 +0800, Inochi Amaoto wrote:
> As the DMA controller on Sophgo CV1800 series SoC only has 8 channels,
> the SoC provides a dma multiplexer to reuse the DMA channel. However,
> the dma multiplexer also controlls the DMA interrupt multiplexer, which
> means that the dma multiplexer needs to know the channel number.
>
> Change the DMA phandle args parsing logic so it can use handshake
> number as channel number if necessary.
>
> [...]
Applied, thanks!
[1/2] dt-bindings: dma: snps,dw-axi-dmac: Add fallback compatible for CV1800B
commit: 7524fe142b5a772f8421aeee2132cf7e21a00103
Best regards,
--
~Vinod
^ permalink raw reply
* Re: (subset) [PATCH v4 00/10] arm64: dts: qcom: Extend Shikra device tree with peripheral and subsystem support
From: Vinod Koul @ 2026-06-11 5:51 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio, Komal Bajaj
Cc: linux-arm-msm, dmaengine, devicetree, linux-kernel, linux-pm,
Xueyao An, Krzysztof Kozlowski, Sayantan Chakraborty,
Dmitry Baryshkov, Konrad Dybcio, Aastha Pandey, Imran Shaik,
Raviteja Laggyshetty, Vishnu Santhosh, Bibek Kumar Patro,
Gaurav Kohli, Yepuri Siddu, Miaoqing Pan
In-Reply-To: <20260608-shikra-dt-m1-v4-0-2114300594a6@oss.qualcomm.com>
On Mon, 08 Jun 2026 18:40:20 +0530, Komal Bajaj wrote:
> Extend Shikra DT with peripheral and subsystem support across all SoM
> variants (CQ2390M, CQ2390S, IQ2390S) and their EVK boards.
>
> The series adds:
>
> - QUPv3 serial engine configuration
> - cpufreq-hw node for hardware-assisted CPU frequency scaling
> - DDR bandwidth monitor (BWMONv5) nodes with OPP tables for dynamic
> DDR frequency scaling
> - EPSS L3 interconnect provider node for L3 cache frequency scaling
> - CPU OPP tables to drive DDR and L3 scaling per frequency domain
> - SMP2P nodes for CDSP, modem and LMCU inter-processor signalling
> - Remoteproc PAS nodes for CDSP, LPAICP and MPSS subsystems
> - TSENS instance with 14 thermal sensors and thermal zone definitions
> - Bluetooth (WCN3988) node with board-specific regulator supplies on
> all three EVK variants
> - WiFi node in the SoC DTSI with board-specific power supply and
> calibration variant selection on all three EVK variants
>
> [...]
Applied, thanks!
[01/10] dt-bindings: dma: qcom,gpi: Document GPI DMA engine for Shikra SoC
commit: 0fbf772fabe93b52f1ecd9ea193dbc90a6042c4d
Best regards,
--
~Vinod
^ permalink raw reply
* Re: (subset) [PATCH v4 0/3] Reserve eDMA channels 0-1 for V2X
From: Vinod Koul @ 2026-06-11 5:51 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Frank Li,
Peng Fan, Ye Li, Joy Zou
Cc: devicetree, imx, linux-arm-kernel, linux-kernel,
Laurentiu Mihalcea
In-Reply-To: <20260211-b4-imx95-v2x-v4-0-10852754b267@nxp.com>
On Wed, 11 Feb 2026 17:28:23 +0800, Joy Zou wrote:
>
>
Applied, thanks!
[1/3] dt-bindings: dma: fsl-edma: add dma-channel-mask property description
commit: 75b28d74f90c79e788e0e86caf0173fc0b2e92aa
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v13 2/4] crypto: spacc - Add SPAcc ahash support
From: Herbert Xu @ 2026-06-11 5:50 UTC (permalink / raw)
To: Pavitrakumar Managutte
Cc: linux-crypto, linux-kernel, devicetree, robh, conor+dt,
Ruud.Derwig, rbannerm, manjunath.hadli, adityak, navami.telsang,
bhoomikak
In-Reply-To: <20260604165210.1141842-3-pavitrakumarm@vayavyalabs.com>
On Thu, Jun 04, 2026 at 10:22:08PM +0530, Pavitrakumar Managutte wrote:
> Add ahash support to SPAcc driver.
> Below are the hash algos supported:
> - cmac(aes)
> - xcbc(aes)
> - cmac(sm4)
> - xcbc(sm4)
> - hmac(md5)
> - md5
> - hmac(sha1)
> - sha1
> - sha224
> - sha256
> - sha384
> - sha512
> - hmac(sha224)
> - hmac(sha256)
> - hmac(sha384)
> - hmac(sha512)
> - sha3-224
> - sha3-256
> - sha3-384
> - sha3-512
> - michael_mic
>
> Co-developed-by: Bhoomika Kadabi <bhoomikak@vayavyalabs.com>
> Signed-off-by: Bhoomika Kadabi <bhoomikak@vayavyalabs.com>
> Acked-by: Ross Bannerman <rbannerm@synopsys.com>
> Signed-off-by: Pavitrakumar Managutte <pavitrakumarm@vayavyalabs.com>
> Signed-off-by: Manjunath Hadli <manjunath.hadli@vayavyalabs.com>
> ---
> drivers/crypto/dwc-spacc/spacc_ahash.c | 897 ++++++++++++++
> drivers/crypto/dwc-spacc/spacc_core.c | 1311 ++++++++++++++++++++
> drivers/crypto/dwc-spacc/spacc_core.h | 838 +++++++++++++
> drivers/crypto/dwc-spacc/spacc_device.c | 275 ++++
> drivers/crypto/dwc-spacc/spacc_device.h | 237 ++++
> drivers/crypto/dwc-spacc/spacc_hal.c | 374 ++++++
> drivers/crypto/dwc-spacc/spacc_hal.h | 114 ++
> drivers/crypto/dwc-spacc/spacc_interrupt.c | 329 +++++
> drivers/crypto/dwc-spacc/spacc_manager.c | 611 +++++++++
> 9 files changed, 4986 insertions(+)
> create mode 100644 drivers/crypto/dwc-spacc/spacc_ahash.c
> create mode 100644 drivers/crypto/dwc-spacc/spacc_core.c
> create mode 100644 drivers/crypto/dwc-spacc/spacc_core.h
> create mode 100644 drivers/crypto/dwc-spacc/spacc_device.c
> create mode 100644 drivers/crypto/dwc-spacc/spacc_device.h
> create mode 100644 drivers/crypto/dwc-spacc/spacc_hal.c
> create mode 100644 drivers/crypto/dwc-spacc/spacc_hal.h
> create mode 100644 drivers/crypto/dwc-spacc/spacc_interrupt.c
> create mode 100644 drivers/crypto/dwc-spacc/spacc_manager.c
Please also check the Sashiko comments, some of those look alarming:
https://sashiko.dev/#/patchset/20260604165210.1141842-1-pavitrakumarm%40vayavyalabs.com
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v13 2/4] crypto: spacc - Add SPAcc ahash support
From: Herbert Xu @ 2026-06-11 5:49 UTC (permalink / raw)
To: Pavitrakumar Managutte
Cc: linux-crypto, linux-kernel, devicetree, robh, conor+dt,
Ruud.Derwig, rbannerm, manjunath.hadli, adityak, navami.telsang,
bhoomikak
In-Reply-To: <20260604165210.1141842-3-pavitrakumarm@vayavyalabs.com>
On Thu, Jun 04, 2026 at 10:22:08PM +0530, Pavitrakumar Managutte wrote:
>
> +static int spacc_hash_do_one_request(struct crypto_engine *engine, void *areq)
> +{
> + struct ahash_request *req = ahash_request_cast(areq);
> + struct crypto_ahash *reqtfm = crypto_ahash_reqtfm(req);
> + struct spacc_crypto_ctx *tctx = crypto_ahash_ctx(reqtfm);
> + struct spacc_crypto_reqctx *ctx = ahash_request_ctx(req);
> + struct spacc_priv *priv = dev_get_drvdata(tctx->dev);
> + const struct spacc_alg *salg = spacc_tfm_ahash(&reqtfm->base);
> + int rc = 0;
> +
> + ctx->single_shot = 1;
> + ctx->total_nents = sg_nents(req->src);
> +
> + tctx->tmp_sgl = kmalloc_array(2, sizeof(*tctx->tmp_sgl), GFP_KERNEL);
> +
> + if (!tctx->tmp_sgl)
> + goto fallback;
> +
> + sg_init_table(tctx->tmp_sgl, 2);
> + tctx->tmp_sgl[0].length = 0;
> +
> + if (tctx->handle < 0 || !tctx->ctx_valid) {
> + priv = dev_get_drvdata(salg->dev);
> + tctx->dev = get_device(salg->dev);
> +
> + rc = spacc_is_mode_keysize_supported(&priv->spacc,
> + salg->mode->id, tctx->keylen, 1);
This check could've been done before going through the crypto
engine. If we're just going to use the fallback, there is no
point going all the way through the engine just to drop out right
at the end.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: display: panel: himax,hx83121a: add optional bl supply
From: Pengyu Luo @ 2026-06-11 5:45 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown,
dri-devel, devicetree, linux-kernel
In-Reply-To: <2877375c4efee4b4e816b418c965da7bd7d60992.camel@iscas.ac.cn>
On Thu, Jun 11, 2026 at 1:36 PM Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
>
> 在 2026-06-11四的 13:26 +0800，Pengyu Luo写道：
> > On Tue, 09 Jun 2026 00:26:20 +0800, Icenowy Zheng
> > <zhengxingda@iscas.ac.cn> wrote:
> > > When the backlight is managed by the panel controller IC, an
> > > external
> > > power rail might be powering the backlight.
> > >
> > > Add an optional `bl-supply` property to describe such power rail,
> > > thus
> > > allow disabling the backlight.
> > >
> >
> > Please add it as a hwen pin, this will simplify your code later.
>
> I am not sure whether this should be a pin or a regulator -- the DT
> binding should reflect the HW fact, and LCD panel backlights usually
> require a high voltage (or even a current source) that is driven by a
> dedicated regulator.
>
Most backlight ICs use a hwen pin to enable the supply, afaik, like
ktz8866, ktz8868, aw99706, etc. We don't touch the VIN. (My disclaimer:
I am just an amateur, know less about the circuit)
Best wishes,
Pengyu
> Thanks,
> Icenowy
>
> >
> > >
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/panel/himax,hx83121a.ya
> > > ml
> > > b/Documentation/devicetree/bindings/display/panel/himax,hx83121a.ya
> > > ml
> > > index e067a2f6d0b2..aeca3c9a599c 100644
> > > ---
> > > a/Documentation/devicetree/bindings/display/panel/himax,hx83121a.ya
> > > ml
> > > +++
> > > b/Documentation/devicetree/bindings/display/panel/himax,hx83121a.ya
> > > ml
> > > @@ -40,6 +40,9 @@ properties:
> > > vddi-supply:
> > > description: power supply for IC
> > >
> > > + bl-supply:
> > > + description: power supply for backlight, in case it's managed
> > > via DSC
> > > +
> >
> > s/DSC/DCS/
> >
> > Best wishes,
> > Pengyu
>
^ permalink raw reply
* Re: [PATCH v32 5/5] i2c: ast2600: Add target mode support
From: sashiko-bot @ 2026-06-11 5:46 UTC (permalink / raw)
To: Ryan Chen; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260611-upstream_i2c-v32-5-b66eba921d01@aspeedtech.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Incorrect chronological ordering of I2C slave events and spurious event signaling in the target interrupt handler breaks backend state machines.
- [High] Controller mode can be permanently locked out because `target_active` is not reliably cleared upon target transaction STOP.
- [High] Race condition in the target mode master-abort fast path leaves stale controller interrupts pending, leading to use-after-free and data corruption of subsequent I2C transfers.
- [High] Failure to W1C-clear target ISR error bits causes a permanent deadlock where all subsequent controller transfers fail with -EBUSY.
--
commit e5417daca64552c41b25f31b14fb3eb562d3e134
Author: Ryan Chen <ryan_chen@aspeedtech.com>
i2c: ast2600: Add target mode support
Add target mode support to the AST2600 I2C driver, enabling dual-role
capability. This includes adding target interrupt handling and address match
response logic.
> diff --git a/drivers/i2c/busses/i2c-ast2600.c b/drivers/i2c/busses/i2c-ast2600.c
> index 70f37dc77468a..aace0c7eeb721 100644
> --- a/drivers/i2c/busses/i2c-ast2600.c
> +++ b/drivers/i2c/busses/i2c-ast2600.c
> @@ -348,6 +353,253 @@ static int ast2600_i2c_recover_bus(struct ast2600_i2c_bus *i2c_bus)
[ ... ]
> +#if IS_ENABLED(CONFIG_I2C_SLAVE)
> +static void ast2600_i2c_target_packet_buff_irq(struct ast2600_i2c_bus *i2c_bus, u32 sts)
> +{
> + u8 value = 0;
> + int target_rx_len = 0;
> + u32 cmd = 0;
> + int i;
> +
> + /* due to controller target is common buffer, need force the master stop not issue */
> + if (readl(i2c_bus->reg_base + AST2600_I2CM_CMD_STS) & GENMASK(15, 0)) {
> + writel(0, i2c_bus->reg_base + AST2600_I2CM_CMD_STS);
> + writel(0, i2c_bus->reg_base + AST2600_I2CM_IER);
> + writel(readl(i2c_bus->reg_base + AST2600_I2CM_ISR),
> + i2c_bus->reg_base + AST2600_I2CM_ISR);
> + i2c_bus->cmd_err = -EBUSY;
> + WRITE_ONCE(i2c_bus->msgs, NULL);
> + writel(AST2600_I2CM_PKT_DONE | AST2600_I2CM_BUS_RECOVER,
> + i2c_bus->reg_base + AST2600_I2CM_IER);
> + complete(&i2c_bus->cmd_complete);
> + }
[Severity: High]
Could this fast path abort leave stale controller interrupts pending?
If the hardware asynchronously asserts PKT_DONE or PKT_ERROR shortly after the
W1C ISR read here, the complete() call wakes the waiting thread, which might
immediately start a new controller transfer.
Would the stale interrupt then fire and incorrectly apply to the new transfer,
potentially leading to a use-after-free on the new msgs buffer?
> +
> + /* Handle i2c target timeout condition */
> + if (sts & AST2600_I2CS_INACTIVE_TO) {
> + /* Reset timeout counter */
> + u32 ac_timing = readl(i2c_bus->reg_base + AST2600_I2CC_AC_TIMING) &
> + AST2600_I2CC_AC_TIMING_MASK;
> +
> + writel(ac_timing, i2c_bus->reg_base + AST2600_I2CC_AC_TIMING);
> + ac_timing |= AST2600_I2CC_TTIMEOUT(i2c_bus->timeout);
> + writel(ac_timing, i2c_bus->reg_base + AST2600_I2CC_AC_TIMING);
> + writel(TARGET_TRIGGER_CMD, i2c_bus->reg_base + AST2600_I2CS_CMD_STS);
> + writel(AST2600_I2CS_PKT_DONE, i2c_bus->reg_base + AST2600_I2CS_ISR);
> + i2c_slave_event(i2c_bus->target, I2C_SLAVE_STOP, &value);
> + WRITE_ONCE(i2c_bus->target_active, false);
> + return;
> + }
[Severity: High]
Does this early return fail to clear the AST2600_I2CS_INACTIVE_TO bit from
the hardware register?
Since it is never W1C-cleared, the ISR register might remain non-zero
permanently.
> +
> + sts &= ~(AST2600_I2CS_PKT_DONE | AST2600_I2CS_PKT_ERROR);
> +
> + if (sts & AST2600_I2CS_SLAVE_MATCH)
> + WRITE_ONCE(i2c_bus->target_active, true);
> +
> + switch (sts) {
> + case AST2600_I2CS_SLAVE_PENDING | AST2600_I2CS_WAIT_RX_DMA |
> + AST2600_I2CS_SLAVE_MATCH | AST2600_I2CS_RX_DONE | AST2600_I2CS_STOP:
> + case AST2600_I2CS_SLAVE_PENDING |
> + AST2600_I2CS_SLAVE_MATCH | AST2600_I2CS_RX_DONE | AST2600_I2CS_STOP:
> + case AST2600_I2CS_SLAVE_PENDING |
> + AST2600_I2CS_SLAVE_MATCH | AST2600_I2CS_STOP:
> + i2c_slave_event(i2c_bus->target, I2C_SLAVE_STOP, &value);
> + fallthrough;
[Severity: High]
Is the event ordering inverted here?
This unconditionally emits I2C_SLAVE_STOP first, and then falls through to
emit I2C_SLAVE_WRITE_REQUESTED and I2C_SLAVE_WRITE_RECEIVED.
Emitting the STOP condition prior to receiving the write data leaves backend
state machines (like i2c-slave-eeprom) without a terminating event for the
data, which typically causes writes to be dropped.
[ ... ]
> + case AST2600_I2CS_SLAVE_MATCH | AST2600_I2CS_WAIT_TX_DMA | AST2600_I2CS_RX_DONE:
> + case AST2600_I2CS_WAIT_TX_DMA | AST2600_I2CS_RX_DONE:
> + case AST2600_I2CS_WAIT_TX_DMA:
> + if (sts & AST2600_I2CS_SLAVE_MATCH)
> + i2c_slave_event(i2c_bus->target, I2C_SLAVE_WRITE_REQUESTED, &value);
[Severity: High]
Can this spuriously emit I2C_SLAVE_WRITE_REQUESTED during a repeated start
transitioning to a Master Read (WAIT_TX_DMA)?
If so, it would reset the backend's internal write pointers, corrupting
previously received write data before I2C_SLAVE_READ_REQUESTED is processed.
[ ... ]
> + if (cmd)
> + writel(cmd, i2c_bus->reg_base + AST2600_I2CS_CMD_STS);
> +
> + writel(AST2600_I2CS_PKT_DONE, i2c_bus->reg_base + AST2600_I2CS_ISR);
> + readl(i2c_bus->reg_base + AST2600_I2CS_ISR);
> +
> + if ((sts & AST2600_I2CS_STOP) && !(sts & AST2600_I2CS_SLAVE_PENDING))
> + WRITE_ONCE(i2c_bus->target_active, false);
> +}
[Severity: High]
Is this condition too strict?
For standard target write transactions, the hardware explicitly combines
AST2600_I2CS_STOP and AST2600_I2CS_SLAVE_PENDING in the same interrupt event.
If this evaluates to false in those normal cases, target_active would
remain permanently true, locking out all subsequent controller mode
transfers with -EBUSY.
> @@ -682,6 +954,21 @@ static int ast2600_i2c_controller_xfer(struct i2c_adapter *adap, struct i2c_msg
> return ret;
> }
>
> +#if IS_ENABLED(CONFIG_I2C_SLAVE)
> + if (READ_ONCE(i2c_bus->target_active))
> + return -EBUSY;
> + /*
> + * Controller and target share the same buffer register. A target
> + * transaction can update buffer state asynchronously via IRQ, so block
> + * controller transfers while target is active to avoid buffer corruption.
> + */
> + writel(0, i2c_bus->reg_base + AST2600_I2CS_IER);
> + if (readl(i2c_bus->reg_base + AST2600_I2CS_ISR) || READ_ONCE(i2c_bus->target_active)) {
> + writel(AST2600_I2CS_PKT_DONE, i2c_bus->reg_base + AST2600_I2CS_IER);
> + return -EBUSY;
> + }
> +#endif
[Severity: High]
If AST2600_I2CS_INACTIVE_TO is left uncleared in the target interrupt handler,
will this check permanently return -EBUSY for all subsequent controller
transfers?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-upstream_i2c-v32-0-b66eba921d01@aspeedtech.com?part=5
^ permalink raw reply
* Re: [PATCH v32 4/5] i2c: ast2600: Add controller driver for AST2600 new register set
From: sashiko-bot @ 2026-06-11 5:46 UTC (permalink / raw)
To: Ryan Chen; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260611-upstream_i2c-v32-4-b66eba921d01@aspeedtech.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The driver fails to send a NAK on the last byte of an intermediate read message, causing the slave to hold SDA low and block the subsequent Repeated Start.
- [High] The interrupt handler does not clear error status bits in the Write-1-to-Clear (W1C) ISR register, permanently wedging the controller after a single error.
- [Medium] Bus recovery failure and other error interrupts are not enabled in the Interrupt Enable Register (IER), leading to needless blocking timeouts.
--
commit 01c0588191421a92b3d96b7bc246be1fe0958d9f
Author: Ryan Chen <ryan_chen@aspeedtech.com>
i2c: ast2600: Add controller driver for AST2600 new register set
The AST2600 introduces a new I2C controller register layout, selectable
at runtime via global control registers. Compared to the legacy layout
used on AST2400/AST2500, the new layout separates controller (master)
and target (slave) registers and adds support for packet-based transfers
> diff --git a/drivers/i2c/busses/i2c-ast2600.c b/drivers/i2c/busses/i2c-ast2600.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-ast2600.c
[ ... ]
> +static int ast2600_i2c_setup_buff_rx(u32 cmd, struct ast2600_i2c_bus *i2c_bus)
> +{
> + struct i2c_msg *msg = &i2c_bus->msgs[i2c_bus->msgs_index];
> + int xfer_len = msg->len - i2c_bus->controller_xfer_cnt;
> +
> + cmd |= AST2600_I2CM_PKT_EN | AST2600_I2CM_RX_BUFF_EN | AST2600_I2CM_RX_CMD;
> +
> + if (cmd & AST2600_I2CM_START_CMD)
> + cmd |= AST2600_I2CM_PKT_ADDR(msg->addr);
> +
> + if (msg->flags & I2C_M_RECV_LEN) {
> + dev_dbg(i2c_bus->dev, "smbus read\n");
> + xfer_len = 1;
> + } else if (xfer_len > i2c_bus->buf_size) {
> + xfer_len = i2c_bus->buf_size;
> + } else if (i2c_bus->msgs_index + 1 == i2c_bus->msgs_count) {
> + cmd |= CONTROLLER_TRIGGER_LAST_STOP;
> + }
[Severity: High]
Does this logic omit the NAK for intermediate read messages?
The CONTROLLER_TRIGGER_LAST_STOP flag (which applies the hardware NAK via
AST2600_I2CM_RX_CMD_LAST) is strictly tied to the absolute final message in
the array. If the transfer contains an intermediate read message, such as a
read before a Repeated Start, the last byte will be ACKed.
This will cause the slave to expect another byte and hold SDA low, leading to
an arbitration loss or bus hang when attempting the Repeated Start.
[ ... ]
> +static int ast2600_i2c_controller_irq(struct ast2600_i2c_bus *i2c_bus)
> +{
> + u32 sts = readl(i2c_bus->reg_base + AST2600_I2CM_ISR);
> + u32 ctrl;
> +
> + sts &= ~AST2600_I2CM_SMBUS_ALERT;
> +
> + if (sts & AST2600_I2CM_BUS_RECOVER_FAIL) {
> + writel(AST2600_I2CM_BUS_RECOVER_FAIL, i2c_bus->reg_base + AST2600_I2CM_ISR);
> + ctrl = readl(i2c_bus->reg_base + AST2600_I2CC_FUN_CTRL);
> + writel(0, i2c_bus->reg_base + AST2600_I2CC_FUN_CTRL);
> + writel(ctrl, i2c_bus->reg_base + AST2600_I2CC_FUN_CTRL);
> + WRITE_ONCE(i2c_bus->msgs, NULL);
> + i2c_bus->cmd_err = -EPROTO;
> + complete(&i2c_bus->cmd_complete);
> + return 1;
> + }
> +
> + if (sts & AST2600_I2CM_BUS_RECOVER) {
> + writel(AST2600_I2CM_BUS_RECOVER, i2c_bus->reg_base + AST2600_I2CM_ISR);
> + WRITE_ONCE(i2c_bus->msgs, NULL);
> + i2c_bus->cmd_err = 0;
> + complete(&i2c_bus->cmd_complete);
> + return 1;
> + }
> +
> + i2c_bus->cmd_err = ast2600_i2c_irq_err_to_errno(sts);
> + if (i2c_bus->cmd_err) {
> + WRITE_ONCE(i2c_bus->msgs, NULL);
> + writel(AST2600_I2CM_PKT_DONE, i2c_bus->reg_base + AST2600_I2CM_ISR);
> + complete(&i2c_bus->cmd_complete);
> + return 1;
> + }
[Severity: High]
Will this permanently wedge the controller after a single error?
When an error occurs, the error path explicitly writes only
AST2600_I2CM_PKT_DONE to the ISR. W1C error bits like AST2600_I2CM_ARBIT_LOSS
or AST2600_I2CM_TX_NAK are never written back and will remain set.
Because the error path calls complete() successfully, the timeout fallback
path that could reset the controller is bypassed. On the very next I2C
transaction, a new PKT_DONE interrupt will cause the handler to read the
stale error bits, instantly fail the transaction, and loop in this state.
The same issue appears to exist in ast2600_i2c_controller_packet_irq() for
bits like AST2600_I2CM_PKT_ERROR.
[ ... ]
> +static int ast2600_i2c_probe(struct platform_device *pdev)
> +{
[ ... ]
> + ret = devm_request_irq(dev, i2c_bus->irq, ast2600_i2c_bus_irq, 0,
> + dev_name(dev), i2c_bus);
> + if (ret < 0) {
> + ret = dev_err_probe(dev, ret, "Unable to request irq %d\n",
> + i2c_bus->irq);
> + goto err;
> + }
> +
> + writel(AST2600_I2CM_PKT_DONE | AST2600_I2CM_BUS_RECOVER,
> + i2c_bus->reg_base + AST2600_I2CM_IER);
> +
> + ret = i2c_add_adapter(&i2c_bus->adap);
[Severity: Medium]
Are bus recovery failure interrupts intentionally left disabled?
The interrupt enable register is configured here without including the
AST2600_I2CM_BUS_RECOVER_FAIL bit. If a bus recovery attempt fails, the
hardware will assert the bit in the ISR, but the interrupt handler will
never be triggered.
This will cause the driver to needlessly block for the entire duration of
wait_for_completion_timeout() instead of handling the failure immediately.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-upstream_i2c-v32-0-b66eba921d01@aspeedtech.com?part=4
^ permalink raw reply
* Re: [PATCH 3/3] drm/panel: himax-hx83121a: add backlight regulator support
From: Icenowy Zheng @ 2026-06-11 5:43 UTC (permalink / raw)
To: Pengyu Luo
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown,
dri-devel, devicetree, linux-kernel
In-Reply-To: <178115560757.199930.5802398831559617564.b4-review@b4>
在 2026-06-11四的 13:26 +0800，Pengyu Luo写道：
> On Tue, 09 Jun 2026 00:26:22 +0800, Icenowy Zheng
> <zhengxingda@iscas.ac.cn> wrote:
> > diff --git a/drivers/gpu/drm/panel/panel-himax-hx83121a.c
> > b/drivers/gpu/drm/panel/panel-himax-hx83121a.c
> > index 1a7e0125bced..e31e2fba0a78 100644
> > --- a/drivers/gpu/drm/panel/panel-himax-hx83121a.c
> > +++ b/drivers/gpu/drm/panel/panel-himax-hx83121a.c
> > @@ -195,7 +197,27 @@ static int himax_bl_update_status(struct
> > backlight_device *bl)
> > [ ... skip 18 lines ... ]
> > + ret = regulator_enable(ctx->bl_supply);
> > + if (ret)
> > + return ret;
> > +
> > + ctx->backlight_enabled = true;
> > +
>
> If you use a pin, (it is indeed a hwen pin as we know) you can
> simplify it like this,
>
> bool bl_enable_now = !!brightness;
>
> if (ctx->bl_enable != bl_enable_now) {
> gpiod_set_value(ctx->hwen_gpio, bl_enable_now);
> ctx->bl_enable = bl_enable_now;
> }
>
> BTW, iirc, panel bias can be turned off too, although I don't think
> this will save too much power.
BTW during my test, it seems that DCS backlight 0 isn't turning off
backlight.
Thanks,
Icenowy
>
> Best wishes,
> Pengyu
^ permalink raw reply
* Re: [PATCH v32 2/5] i2c: aspeed: Read clock-frequency via i2c_parse_fw_timings()
From: sashiko-bot @ 2026-06-11 5:40 UTC (permalink / raw)
To: Ryan Chen; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260611-upstream_i2c-v32-2-b66eba921d01@aspeedtech.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] I2C adapter is removed after asserting hardware reset, preventing I2C transfers during device unbind.
- [High] Zero value in `bus-frequency` DT property leads to a divide-by-zero exception.
--
commit 92481335123f99873954906861adc75752062695
Author: Ryan Chen <ryan_chen@aspeedtech.com>
i2c: aspeed: Read clock-frequency via i2c_parse_fw_timings()
Use i2c_parse_fw_timings() to read the standard "clock-frequency"
property, and fall back to "bus-frequency" only when the standard
property is absent.
> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
> index a26b74c712061..f00bd779146e7 100644
> --- a/drivers/i2c/busses/i2c-aspeed.c
> +++ b/drivers/i2c/busses/i2c-aspeed.c
[ ... ]
> @@ -1025,12 +1026,18 @@ static int aspeed_i2c_probe_bus(struct platform_device *pdev)
> }
> reset_control_deassert(bus->rst);
>
> - ret = of_property_read_u32(pdev->dev.of_node,
> - "bus-frequency", &bus->bus_frequency);
> - if (ret < 0) {
> - dev_err(&pdev->dev,
> - "Could not read bus-frequency property\n");
> - bus->bus_frequency = I2C_MAX_STANDARD_MODE_FREQ;
> + i2c_parse_fw_timings(&pdev->dev, &timings, false);
> + if (timings.bus_freq_hz) {
> + bus->bus_frequency = timings.bus_freq_hz;
> + } else {
> + ret = of_property_read_u32(pdev->dev.of_node,
> + "bus-frequency",
> + &bus->bus_frequency);
> + if (ret < 0) {
> + dev_err(&pdev->dev,
> + "Could not read clock-frequency or bus-frequency property\n");
> + bus->bus_frequency = I2C_MAX_STANDARD_MODE_FREQ;
> + }
> }
[Severity: High]
This is a pre-existing issue, but can this code cause a divide-by-zero
exception if the device tree sets "bus-frequency" to 0?
If the property is present and set to 0, of_property_read_u32() succeeds
and leaves bus->bus_frequency as 0. Later, in aspeed_i2c_init_clk(), it
is used as a divisor:
drivers/i2c/busses/i2c-aspeed.c:aspeed_i2c_init_clk() {
...
divisor = DIV_ROUND_UP(bus->parent_clk_frequency, bus->bus_frequency);
...
}
Does the driver need to validate that the read frequency is strictly
positive to prevent a kernel panic here?
[Severity: High]
This is a pre-existing issue, but does aspeed_i2c_remove_bus() prevent
I2C transfers during device unbind by asserting hardware reset too early?
In drivers/i2c/busses/i2c-aspeed.c:aspeed_i2c_remove_bus(), the code does:
/* Disable everything. */
writel(0, bus->base + ASPEED_I2C_FUN_CTRL_REG);
writel(0, bus->base + ASPEED_I2C_INTR_CTRL_REG);
spin_unlock_irqrestore(&bus->lock, flags);
reset_control_assert(bus->rst);
i2c_del_adapter(&bus->adap);
When i2c_del_adapter() unregisters child I2C devices, their remove
callbacks may attempt I2C transfers to cleanly shut down the peripherals.
Because the hardware controller is already disabled and in reset, will these
transfers silently fail, timeout, or cause external aborts when the CPU
tries to access the registers?
Should i2c_del_adapter() be called before disabling the hardware and
asserting reset?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-upstream_i2c-v32-0-b66eba921d01@aspeedtech.com?part=2
^ permalink raw reply
* Re: [PATCH v5 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
From: Kyle Hsieh @ 2026-06-11 5:41 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <3d56889c004fc2d11b76ace6033c7ccfb8a37d03.camel@codeconstruct.com.au>
On Wed, Jun 10, 2026 at 7:15 PM Andrew Jeffery
<andrew@codeconstruct.com.au> wrote:
>
> Hi Kyle,
>
> On Mon, 2026-06-08 at 10:42 +0800, Kyle Hsieh wrote:
> > Add linux device tree entry related to the Meta(Facebook) rmc-node.
>
> This is redundant as it is evident from the patch itself. Can you
> please remove it?
>
> > The system use an AT2600 BMC.
> > This node is named "ventura2".
>
> Can you provide some more detail about the platform in the commit
> message? What's it's purpose? Can you describe some interesting
> features or details about its design?
>
Hi Andrew,
To briefly answer your question: Ventura2 is Rack Management
Controller. It is a modular device primarily designed to manage liquid
cooling systems and monitor rack-level hardware states. Its key
hardware features include an extensive I2C/GPIO topology for
tray-level and rack-level liquid leakage detection, as well as MCTP
over I2C support for asynchronous device communications.
I will remove the redundant sentence and include this detailed
description of the platform's purpose and architecture in the commit
message for v7.
> >
> > Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
> > ---
> > arch/arm/boot/dts/aspeed/Makefile | 1 +
> > .../dts/aspeed/aspeed-bmc-facebook-ventura2.dts | 2888 ++++++++++++++++++++
> > 2 files changed, 2889 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
> > index 9adf9278dc94..6b96997629d4 100644
> > --- a/arch/arm/boot/dts/aspeed/Makefile
> > +++ b/arch/arm/boot/dts/aspeed/Makefile
> > @@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
> > aspeed-bmc-facebook-minipack.dtb \
> > aspeed-bmc-facebook-santabarbara.dtb \
> > aspeed-bmc-facebook-tiogapass.dtb \
> > + aspeed-bmc-facebook-ventura2.dtb \
> > aspeed-bmc-facebook-wedge40.dtb \
> > aspeed-bmc-facebook-wedge100.dtb \
> > aspeed-bmc-facebook-wedge400-data64.dtb \
> > diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts
> > new file mode 100644
> > index 000000000000..9bf7d6e52e40
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts
> > @@ -0,0 +1,2888 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (c) 2023 Facebook Inc.
> > +/dts-v1/;
> > +
> > +#include "aspeed-g6.dtsi"
> > +#include <dt-bindings/i2c/i2c.h>
> > +#include <dt-bindings/gpio/aspeed-gpio.h>
> > +
> > +/ {
> > + model = "Facebook Ventura2 RMC";
> > + compatible = "facebook,ventura2-rmc", "aspeed,ast2600";
> >
>
> ...
>
> > +};
> > +
>
> ...
>
> > +&gpio1 {
> > + gpio-line-names =
> > + /*18A0-18A7*/ "","","","","","","","",
> > + /*18B0-18B7*/ "","","","",
> > + "FM_BOARD_BMC_REV_ID0","FM_BOARD_BMC_REV_ID1",
> > + "FM_BOARD_BMC_REV_ID2","",
> > + /*18C0-18C7*/ "SPI_BMC_BIOS_ROM_IRQ0_R_N","","","","","","","",
> > + /*18D0-18D7*/ "","","","","","","","",
> > + /*18E0-18E3*/ "FM_BMC_PROT_LS_EN","AC_PWR_BMC_BTN_R_N","","";
> > +};
> > +
> > +&i2c0 {
> > + status = "okay";
> > +
> > + i2c-mux@77 {
> > + compatible = "nxp,pca9548";
> > + reg = <0x77>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + i2c-mux-idle-disconnect;
> > +
> > + i2c0mux0ch0: i2c@0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > + };
> > +
> > + i2c0mux0ch1: i2c@1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <1>;
> > + };
> > +
> > + i2c0mux0ch2: i2c@2 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <2>;
> > + };
> > +
> > + i2c0mux0ch3: i2c@3 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <3>;
> > + status = "okay";
> > + };
> > +
> > + i2c0mux0ch4: i2c@4 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <4>;
> > + status = "okay";
> > + };
> > +
> > + i2c0mux0ch5: i2c@5 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <5>;
> > + status = "okay";
> > +
> > + eeprom@56 {
> > + compatible = "atmel,24c128";
> > + reg = <0x56>;
> > + };
> > + };
> > +
> > + i2c0mux0ch6: i2c@6 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <6>;
> > +
> > + eeprom@56 {
> > + compatible = "atmel,24c128";
> > + reg = <0x56>;
> > + };
> > +
> > + fan_io_expander0: gpio@20 {
> > + compatible = "nxp,pca9555";
> > + reg = <0x20>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + };
> > +
> > + fan_io_expander1: gpio@21 {
> > + compatible = "nxp,pca9555";
> > + reg = <0x21>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + };
> > +
> > + adc@1d {
> > + compatible = "ti,adc128d818";
> > + reg = <0x1d>;
> > + ti,mode = /bits/ 8 <1>;
> > + };
> > +
> > + adc@35 {
> > + compatible = "maxim,max11617";
> > + reg = <0x35>;
> > + };
> > + };
> > +
> > + i2c0mux0ch7: i2c@7 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <7>;
> > +
> > + fanctl0: fan-controller@20 {
> > + compatible = "maxim,max31790";
> > + reg = <0x20>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + channel@2 {
>
> Can you make sure that you consistently use a blank line to separate
> child nodes from each other and from properties in their parent?
>
> Please fix throughout.
I will recheck the whole file to satisfy the rule in the next patch v7, thanks.
>
> > + reg = <2>;
> > + sensor-type = "TACH";
> > + };
> > + channel@5 {
> > + reg = <5>;
> > + sensor-type = "TACH";
> > + };
> > + };
> > +
> > + fanctl1: fan-controller@23 {
> > + compatible = "nuvoton,nct7363";
> > + reg = <0x23>;
> > + #pwm-cells = <2>;
> > +
> > + fan-9 {
> > + pwms = <&fanctl1 0 20000>;
> > + tach-ch = /bits/ 8 <0x09>;
> > + };
> > +
> > + fan-11 {
> > + pwms = <&fanctl1 0 20000>;
> > + tach-ch = /bits/ 8 <0x0B>;
> > + };
> > +
> > + fan-10 {
> > + pwms = <&fanctl1 4 20000>;
> > + tach-ch = /bits/ 8 <0x0A>;
> > + };
> > +
> > + fan-13 {
> > + pwms = <&fanctl1 4 20000>;
> > + tach-ch = /bits/ 8 <0x0D>;
> > + };
> > +
> > + fan-15 {
> > + pwms = <&fanctl1 6 20000>;
> > + tach-ch = /bits/ 8 <0x0F>;
> > + };
> > +
> > + fan-1 {
>
> Can you please sort the fan nodes in ascending order?
I will reorder the fan node in next patch v7.
>
> > + pwms = <&fanctl1 6 20000>;
> > + tach-ch = /bits/ 8 <0x01>;
> > + };
> > +
> > + fan-0 {
> > + pwms = <&fanctl1 10 20000>;
> > + tach-ch = /bits/ 8 <0x00>;
> > + };
> > +
> > + fan-3 {
> > + pwms = <&fanctl1 10 20000>;
> > + tach-ch = /bits/ 8 <0x03>;
> > + };
> > + };
> > + };
> > + };
> > +};
> >
>
> ...
>
> > +
> > + // Marvell 88E6393X EEPROM
>
> Please try to be consistent with the comment style (prefer /* */).
I will fix this in the next patch v7, thanks for your suggestion.
>
> > + eeprom@50 {
> > + compatible = "atmel,24c64";
> > + reg = <0x50>;
> > + };
> > +
> > + rtc@51 {
> > + compatible = "nxp,pcf8563";
> > + reg = <0x51>;
> > + };
> > +};
> > +
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: display: panel: himax,hx83121a: add optional bl supply
From: Icenowy Zheng @ 2026-06-11 5:36 UTC (permalink / raw)
To: Pengyu Luo
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown,
dri-devel, devicetree, linux-kernel
In-Reply-To: <178115560756.199930.11183711627429440356.b4-review@b4>
在 2026-06-11四的 13:26 +0800，Pengyu Luo写道：
> On Tue, 09 Jun 2026 00:26:20 +0800, Icenowy Zheng
> <zhengxingda@iscas.ac.cn> wrote:
> > When the backlight is managed by the panel controller IC, an
> > external
> > power rail might be powering the backlight.
> >
> > Add an optional `bl-supply` property to describe such power rail,
> > thus
> > allow disabling the backlight.
> >
>
> Please add it as a hwen pin, this will simplify your code later.
I am not sure whether this should be a pin or a regulator -- the DT
binding should reflect the HW fact, and LCD panel backlights usually
require a high voltage (or even a current source) that is driven by a
dedicated regulator.
Thanks,
Icenowy
>
> >
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/himax,hx83121a.ya
> > ml
> > b/Documentation/devicetree/bindings/display/panel/himax,hx83121a.ya
> > ml
> > index e067a2f6d0b2..aeca3c9a599c 100644
> > ---
> > a/Documentation/devicetree/bindings/display/panel/himax,hx83121a.ya
> > ml
> > +++
> > b/Documentation/devicetree/bindings/display/panel/himax,hx83121a.ya
> > ml
> > @@ -40,6 +40,9 @@ properties:
> > vddi-supply:
> > description: power supply for IC
> >
> > + bl-supply:
> > + description: power supply for backlight, in case it's managed
> > via DSC
> > +
>
> s/DSC/DCS/
>
> Best wishes,
> Pengyu
^ permalink raw reply
* [PATCH v32 5/5] i2c: ast2600: Add target mode support
From: Ryan Chen @ 2026-06-11 5:31 UTC (permalink / raw)
To: jk, andriy.shevchenko, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Rayn Chen, Philipp Zabel
Cc: linux-i2c, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, openbmc, Ryan Chen
In-Reply-To: <20260611-upstream_i2c-v32-0-b66eba921d01@aspeedtech.com>
Add target mode support to the AST2600 I2C driver.
Target mode features implemented include:
- Add target interrupt handling
- Address match and response logic
This complements the existing controller-mode support, enabling
dual-role capability.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
Changes in v32:
- Fix target RX data loss in the master-abort fast path: remove the
BUFF_CTRL zeroing that preceded the controller IER clear. The shared
BUFF_CTRL register holds the pending target RX length in bits [29:24];
zeroing it before the switch statement causes target_rx_len to read
back as 0, silently discarding all bytes already received by the
target.
- Fix use-after-free in master-abort fast path: null msgs and re-enable
the controller IER before calling complete(), not after. Calling
complete() first allows process context to immediately start a new
i2c_transfer() and install a new msgs pointer; a stale controller IRQ
firing during the subsequent IER restore would then dereference the
new transfer's msgs buffer.
- Fix shared-buffer corruption on coalesced STOP+SLAVE_MATCH IRQ:
restore the SLAVE_PENDING guard on the target_active = false
transition. SLAVE_PENDING (bit 29) is set precisely when a new
address-match is already queued while the previous DMA receive has
not yet been processed. Clearing target_active unconditionally on
STOP in that case lets the controller side overwrite the shared Tx/Rx
buffer before the new target transaction has been re-armed.
- Use READ_ONCE() for all process-context reads of target_active.
The IRQ path writes target_active with WRITE_ONCE(); plain loads in
process context allow the compiler to cache the value across the
IER-disable window, potentially seeing a stale false and starting a
controller transfer that races with an active target transaction.
Changes in v31:
- Address Sashiko AI code review feedback on the target patch:
- Clear target_active on any STOP. The previous condition
`(sts & STOP) && !(sts & SLAVE_PENDING)` failed under coalesced
STOP+SLAVE_PENDING IRQs and left target_active stuck true,
deadlocking controller_xfer() with -EBUSY forever.
- Enable the target IER inside reg_target() instead of
unconditionally in probe(). unreg_target() disables it; without
matching re-enable in reg_target() a subsequent re-registration
would never receive IRQs. Also avoids spurious IRQ activity when
no slave is registered.
- Add the missing CMD_STS write in the
SLAVE_PENDING|RX_DONE|WAIT_TX_DMA|STOP target ISR case so the
HW state machine is re-armed (TRIGGER | TX_BUFF_EN); otherwise
the controller stretches SCL until INACTIVE_TO recovers.
- Default target ISR case now writes TARGET_TRIGGER_CMD to re-arm
the HW state machine instead of silently breaking, which
previously left the bus hung on unhandled sts combinations.
- W1C-clear the ADDR1/2/3_NAK bits in HW (not just locally) in
ast2600_i2c_target_irq(); stale ADDR_NAK bits made
controller_xfer() see I2CS_ISR != 0 and bounce every transfer
with -EBUSY.
- unreg_target(): replace masked ADDR_CTRL write with writel(0, ...);
AST2600_I2CS_ADDR1_MASK covers only bits[6:0] (the 7-bit address),
leaving ADDR1_ENABLE (BIT(7)) set after unregister. Although SLAVE_EN
is cleared first, writing 0 is the correct and complete teardown.
Changes in v30:
- Address Sashiko AI code review feedback:
- Force-stop path (target IRQ aborting an in-flight controller
transfer): disable the controller IER and W1C-clear pending ISR
before calling complete(), then restore the IER after the wake-up.
Without the disable/clear sequence the controller IRQ handler can
race with the target abort path and double-complete or touch
freed msgs.
- unreg_target() teardown ordering: disable the target IER first,
then disable SLAVE_EN / clear ADDR_CTRL, synchronize_irq(), W1C
pending ISR, and only then NULL i2c_bus->target and clear
target_active. The old order left IER enabled while target was
being cleared, allowing an in-flight handler to dereference a
target pointer the caller had already freed.
- reg_target() bring-up ordering: assign i2c_bus->target before
enabling SLAVE_EN. Otherwise an IRQ that fires after SLAVE_EN is
set but before the pointer is stored finds target == NULL, exits
without clearing the ISR, and the unmasked event re-fires as an
IRQ storm.
- Use writel() instead of writeb() when staging a TX byte into the
target buffer. The AST2600 buffer SRAM only supports 32-bit
accesses; byte writes are silently dropped (or, on some
revisions, raise a bus fault), so a SLAVE_READ_REQUESTED reply
never reaches the master.
- reg_target() rejects 10-bit client addresses with -EAFNOSUPPORT.
AST2600_I2CS_ADDR1 is only a 7-bit field; without the check, the
high bits of a 10-bit address overflow into the adjacent ADDR2
field and silently corrupt a second target slot.
- Initialise the local `u8 value` to 0 in the target packet IRQ
handler. Its address is passed to i2c_slave_event() for events
such as I2C_SLAVE_STOP / I2C_SLAVE_READ_REQUESTED; a slave
backend that reads the byte before writing would otherwise leak
uninitialised kernel stack.
Changes in v29:
- fix race between unreg_target and IRQ handler.
- move i2cs ier enable from ast2600_i2c_init to probe after master ier enable.
- remove dma/byte transfer, use buffer mode only.
Changes in v28:
- fix typo condication -> condition
- fix compile error, when disable CONFIG_I2C_SLAVE
Changes in v26:
- change int to bool target_operate
- rename target_operate to target_active
- use i2c_bus->target replace require IO
- use WRITE_ONCE replace target_operate write.
---
drivers/i2c/busses/i2c-ast2600.c | 359 +++++++++++++++++++++++++++++++++++++++
1 file changed, 359 insertions(+)
diff --git a/drivers/i2c/busses/i2c-ast2600.c b/drivers/i2c/busses/i2c-ast2600.c
index 70f37dc77468..aace0c7eeb72 100644
--- a/drivers/i2c/busses/i2c-ast2600.c
+++ b/drivers/i2c/busses/i2c-ast2600.c
@@ -255,6 +255,11 @@ struct ast2600_i2c_bus {
bool multi_master;
bool stop_pending;
void __iomem *buf_base;
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ /* target structure */
+ bool target_active;
+ struct i2c_client *target;
+#endif
};
static void ast2600_i2c_ac_timing_config(struct ast2600_i2c_bus *i2c_bus)
@@ -348,6 +353,253 @@ static int ast2600_i2c_recover_bus(struct ast2600_i2c_bus *i2c_bus)
return ret;
}
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+static void ast2600_i2c_target_packet_buff_irq(struct ast2600_i2c_bus *i2c_bus, u32 sts)
+{
+ u8 value = 0;
+ int target_rx_len = 0;
+ u32 cmd = 0;
+ int i;
+
+ /* due to controller target is common buffer, need force the master stop not issue */
+ if (readl(i2c_bus->reg_base + AST2600_I2CM_CMD_STS) & GENMASK(15, 0)) {
+ writel(0, i2c_bus->reg_base + AST2600_I2CM_CMD_STS);
+ writel(0, i2c_bus->reg_base + AST2600_I2CM_IER);
+ writel(readl(i2c_bus->reg_base + AST2600_I2CM_ISR),
+ i2c_bus->reg_base + AST2600_I2CM_ISR);
+ i2c_bus->cmd_err = -EBUSY;
+ WRITE_ONCE(i2c_bus->msgs, NULL);
+ writel(AST2600_I2CM_PKT_DONE | AST2600_I2CM_BUS_RECOVER,
+ i2c_bus->reg_base + AST2600_I2CM_IER);
+ complete(&i2c_bus->cmd_complete);
+ }
+
+ /* Handle i2c target timeout condition */
+ if (sts & AST2600_I2CS_INACTIVE_TO) {
+ /* Reset timeout counter */
+ u32 ac_timing = readl(i2c_bus->reg_base + AST2600_I2CC_AC_TIMING) &
+ AST2600_I2CC_AC_TIMING_MASK;
+
+ writel(ac_timing, i2c_bus->reg_base + AST2600_I2CC_AC_TIMING);
+ ac_timing |= AST2600_I2CC_TTIMEOUT(i2c_bus->timeout);
+ writel(ac_timing, i2c_bus->reg_base + AST2600_I2CC_AC_TIMING);
+ writel(TARGET_TRIGGER_CMD, i2c_bus->reg_base + AST2600_I2CS_CMD_STS);
+ writel(AST2600_I2CS_PKT_DONE, i2c_bus->reg_base + AST2600_I2CS_ISR);
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_STOP, &value);
+ WRITE_ONCE(i2c_bus->target_active, false);
+ return;
+ }
+
+ sts &= ~(AST2600_I2CS_PKT_DONE | AST2600_I2CS_PKT_ERROR);
+
+ if (sts & AST2600_I2CS_SLAVE_MATCH)
+ WRITE_ONCE(i2c_bus->target_active, true);
+
+ switch (sts) {
+ case AST2600_I2CS_SLAVE_PENDING | AST2600_I2CS_WAIT_RX_DMA |
+ AST2600_I2CS_SLAVE_MATCH | AST2600_I2CS_RX_DONE | AST2600_I2CS_STOP:
+ case AST2600_I2CS_SLAVE_PENDING |
+ AST2600_I2CS_SLAVE_MATCH | AST2600_I2CS_RX_DONE | AST2600_I2CS_STOP:
+ case AST2600_I2CS_SLAVE_PENDING |
+ AST2600_I2CS_SLAVE_MATCH | AST2600_I2CS_STOP:
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_STOP, &value);
+ fallthrough;
+ case AST2600_I2CS_SLAVE_PENDING |
+ AST2600_I2CS_WAIT_RX_DMA | AST2600_I2CS_SLAVE_MATCH | AST2600_I2CS_RX_DONE:
+ case AST2600_I2CS_WAIT_RX_DMA | AST2600_I2CS_SLAVE_MATCH | AST2600_I2CS_RX_DONE:
+ case AST2600_I2CS_WAIT_RX_DMA | AST2600_I2CS_SLAVE_MATCH:
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_WRITE_REQUESTED, &value);
+ cmd = TARGET_TRIGGER_CMD;
+ if (sts & AST2600_I2CS_RX_DONE) {
+ target_rx_len = AST2600_I2CC_GET_RX_BUF_LEN(readl(i2c_bus->reg_base +
+ AST2600_I2CC_BUFF_CTRL));
+ for (i = 0; i < target_rx_len; i++) {
+ value = readb(i2c_bus->buf_base + i2c_bus->buf_size + i);
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_WRITE_RECEIVED, &value);
+ }
+ }
+ if (readl(i2c_bus->reg_base + AST2600_I2CS_CMD_STS) & AST2600_I2CS_RX_BUFF_EN)
+ cmd = 0;
+ else
+ cmd = TARGET_TRIGGER_CMD | AST2600_I2CS_RX_BUFF_EN;
+
+ writel(AST2600_I2CC_SET_RX_BUF_LEN(i2c_bus->buf_size),
+ i2c_bus->reg_base + AST2600_I2CC_BUFF_CTRL);
+ break;
+ case AST2600_I2CS_WAIT_RX_DMA | AST2600_I2CS_RX_DONE:
+ cmd = TARGET_TRIGGER_CMD;
+ target_rx_len = AST2600_I2CC_GET_RX_BUF_LEN(readl(i2c_bus->reg_base +
+ AST2600_I2CC_BUFF_CTRL));
+ for (i = 0; i < target_rx_len; i++) {
+ value = readb(i2c_bus->buf_base + i2c_bus->buf_size + i);
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_WRITE_RECEIVED, &value);
+ }
+ cmd |= AST2600_I2CS_RX_BUFF_EN;
+ writel(AST2600_I2CC_SET_RX_BUF_LEN(i2c_bus->buf_size),
+ i2c_bus->reg_base + AST2600_I2CC_BUFF_CTRL);
+ break;
+ case AST2600_I2CS_SLAVE_PENDING | AST2600_I2CS_WAIT_RX_DMA |
+ AST2600_I2CS_RX_DONE | AST2600_I2CS_STOP:
+ cmd = TARGET_TRIGGER_CMD;
+ target_rx_len = AST2600_I2CC_GET_RX_BUF_LEN(readl(i2c_bus->reg_base +
+ AST2600_I2CC_BUFF_CTRL));
+ for (i = 0; i < target_rx_len; i++) {
+ value = readb(i2c_bus->buf_base + i2c_bus->buf_size + i);
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_WRITE_RECEIVED, &value);
+ }
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_STOP, &value);
+ cmd |= AST2600_I2CS_RX_BUFF_EN;
+ writel(AST2600_I2CC_SET_RX_BUF_LEN(i2c_bus->buf_size),
+ i2c_bus->reg_base + AST2600_I2CC_BUFF_CTRL);
+ break;
+ case AST2600_I2CS_SLAVE_PENDING | AST2600_I2CS_RX_DONE | AST2600_I2CS_STOP:
+ cmd = TARGET_TRIGGER_CMD;
+ target_rx_len = AST2600_I2CC_GET_RX_BUF_LEN(readl(i2c_bus->reg_base +
+ AST2600_I2CC_BUFF_CTRL));
+ for (i = 0; i < target_rx_len; i++) {
+ value = readb(i2c_bus->buf_base + i2c_bus->buf_size + i);
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_WRITE_RECEIVED, &value);
+ }
+ /* workaround for avoid next start with len != 0 */
+ writel(BIT(0), i2c_bus->reg_base + AST2600_I2CC_BUFF_CTRL);
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_STOP, &value);
+ break;
+ case AST2600_I2CS_RX_DONE | AST2600_I2CS_STOP:
+ cmd = TARGET_TRIGGER_CMD;
+ target_rx_len = AST2600_I2CC_GET_RX_BUF_LEN(readl(i2c_bus->reg_base +
+ AST2600_I2CC_BUFF_CTRL));
+ for (i = 0; i < target_rx_len; i++) {
+ value = readb(i2c_bus->buf_base + i2c_bus->buf_size + i);
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_WRITE_RECEIVED, &value);
+ }
+ /* workaround for avoid next start with len != 0 */
+ writel(BIT(0), i2c_bus->reg_base + AST2600_I2CC_BUFF_CTRL);
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_STOP, &value);
+ break;
+ case AST2600_I2CS_SLAVE_PENDING | AST2600_I2CS_RX_DONE |
+ AST2600_I2CS_WAIT_TX_DMA | AST2600_I2CS_STOP:
+ target_rx_len = AST2600_I2CC_GET_RX_BUF_LEN(readl(i2c_bus->reg_base +
+ AST2600_I2CC_BUFF_CTRL));
+ for (i = 0; i < target_rx_len; i++) {
+ value = readb(i2c_bus->buf_base + i2c_bus->buf_size + i);
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_WRITE_RECEIVED, &value);
+ }
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_STOP, &value);
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_READ_REQUESTED, &value);
+ writel(value, i2c_bus->buf_base);
+ writel(AST2600_I2CC_SET_TX_BUF_LEN(1),
+ i2c_bus->reg_base + AST2600_I2CC_BUFF_CTRL);
+ cmd = TARGET_TRIGGER_CMD | AST2600_I2CS_TX_BUFF_EN;
+ break;
+ case AST2600_I2CS_WAIT_TX_DMA | AST2600_I2CS_SLAVE_MATCH:
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_READ_REQUESTED, &value);
+ writel(value, i2c_bus->buf_base);
+ writel(AST2600_I2CC_SET_TX_BUF_LEN(1),
+ i2c_bus->reg_base + AST2600_I2CC_BUFF_CTRL);
+ cmd = TARGET_TRIGGER_CMD | AST2600_I2CS_TX_BUFF_EN;
+ break;
+ case AST2600_I2CS_SLAVE_PENDING | AST2600_I2CS_STOP |
+ AST2600_I2CS_TX_NAK | AST2600_I2CS_SLAVE_MATCH | AST2600_I2CS_RX_DONE:
+ case AST2600_I2CS_SLAVE_PENDING | AST2600_I2CS_WAIT_RX_DMA | AST2600_I2CS_STOP |
+ AST2600_I2CS_TX_NAK | AST2600_I2CS_SLAVE_MATCH | AST2600_I2CS_RX_DONE:
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_STOP, &value);
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_WRITE_REQUESTED, &value);
+ target_rx_len = AST2600_I2CC_GET_RX_BUF_LEN(readl(i2c_bus->reg_base +
+ AST2600_I2CC_BUFF_CTRL));
+ for (i = 0; i < target_rx_len; i++) {
+ value = readb(i2c_bus->buf_base + i2c_bus->buf_size + i);
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_WRITE_RECEIVED, &value);
+ }
+ writel(AST2600_I2CC_SET_RX_BUF_LEN(i2c_bus->buf_size),
+ i2c_bus->reg_base + AST2600_I2CC_BUFF_CTRL);
+ cmd = TARGET_TRIGGER_CMD | AST2600_I2CS_RX_BUFF_EN;
+ break;
+ case AST2600_I2CS_SLAVE_MATCH | AST2600_I2CS_WAIT_TX_DMA | AST2600_I2CS_RX_DONE:
+ case AST2600_I2CS_WAIT_TX_DMA | AST2600_I2CS_RX_DONE:
+ case AST2600_I2CS_WAIT_TX_DMA:
+ if (sts & AST2600_I2CS_SLAVE_MATCH)
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_WRITE_REQUESTED, &value);
+
+ if (sts & AST2600_I2CS_RX_DONE) {
+ target_rx_len = AST2600_I2CC_GET_RX_BUF_LEN(readl(i2c_bus->reg_base +
+ AST2600_I2CC_BUFF_CTRL));
+ for (i = 0; i < target_rx_len; i++) {
+ value = readb(i2c_bus->buf_base + i2c_bus->buf_size + i);
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_WRITE_RECEIVED, &value);
+ }
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_READ_REQUESTED, &value);
+ } else {
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_READ_PROCESSED, &value);
+ }
+ writel(value, i2c_bus->buf_base);
+ writel(AST2600_I2CC_SET_TX_BUF_LEN(1),
+ i2c_bus->reg_base + AST2600_I2CC_BUFF_CTRL);
+ cmd = TARGET_TRIGGER_CMD | AST2600_I2CS_TX_BUFF_EN;
+ break;
+ /* workaround : trigger the cmd twice to fix next state keep 1000000 */
+ case AST2600_I2CS_SLAVE_MATCH | AST2600_I2CS_RX_DONE:
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_WRITE_REQUESTED, &value);
+ cmd = TARGET_TRIGGER_CMD | AST2600_I2CS_RX_BUFF_EN;
+ writel(cmd, i2c_bus->reg_base + AST2600_I2CS_CMD_STS);
+ break;
+ case AST2600_I2CS_TX_NAK | AST2600_I2CS_STOP:
+ case AST2600_I2CS_STOP:
+ cmd = TARGET_TRIGGER_CMD;
+ i2c_slave_event(i2c_bus->target, I2C_SLAVE_STOP, &value);
+ break;
+ default:
+ dev_dbg(i2c_bus->dev, "unhandled target isr case %x, sts %x\n", sts,
+ readl(i2c_bus->reg_base + AST2600_I2CC_STS_AND_BUFF));
+ cmd = TARGET_TRIGGER_CMD;
+ break;
+ }
+
+ if (cmd)
+ writel(cmd, i2c_bus->reg_base + AST2600_I2CS_CMD_STS);
+
+ writel(AST2600_I2CS_PKT_DONE, i2c_bus->reg_base + AST2600_I2CS_ISR);
+ readl(i2c_bus->reg_base + AST2600_I2CS_ISR);
+
+ if ((sts & AST2600_I2CS_STOP) && !(sts & AST2600_I2CS_SLAVE_PENDING))
+ WRITE_ONCE(i2c_bus->target_active, false);
+}
+
+static int ast2600_i2c_target_irq(struct ast2600_i2c_bus *i2c_bus)
+{
+ u32 ier = readl(i2c_bus->reg_base + AST2600_I2CS_IER);
+ u32 isr = readl(i2c_bus->reg_base + AST2600_I2CS_ISR);
+
+ if (!(isr & ier))
+ return 0;
+
+ /*
+ * Target interrupt coming after controller packet done
+ * So need handle controller first.
+ */
+ if (readl(i2c_bus->reg_base + AST2600_I2CM_ISR) & AST2600_I2CM_PKT_DONE)
+ return 0;
+
+ isr &= ~(AST2600_I2CS_ADDR_INDICATE_MASK);
+
+ if (isr & (AST2600_I2CS_ADDR1_NAK | AST2600_I2CS_ADDR2_NAK |
+ AST2600_I2CS_ADDR3_NAK)) {
+ writel(isr & (AST2600_I2CS_ADDR1_NAK | AST2600_I2CS_ADDR2_NAK |
+ AST2600_I2CS_ADDR3_NAK),
+ i2c_bus->reg_base + AST2600_I2CS_ISR);
+ isr &= ~(AST2600_I2CS_ADDR1_NAK | AST2600_I2CS_ADDR2_NAK |
+ AST2600_I2CS_ADDR3_NAK);
+ }
+
+ if (AST2600_I2CS_ADDR_MASK & isr)
+ isr &= ~AST2600_I2CS_ADDR_MASK;
+
+ if (AST2600_I2CS_PKT_DONE & isr)
+ ast2600_i2c_target_packet_buff_irq(i2c_bus, isr);
+
+ return 1;
+}
+#endif
+
static int ast2600_i2c_setup_buff_tx(u32 cmd, struct ast2600_i2c_bus *i2c_bus)
{
struct i2c_msg *msg = &i2c_bus->msgs[i2c_bus->msgs_index];
@@ -559,6 +811,20 @@ static void ast2600_i2c_controller_packet_irq(struct ast2600_i2c_bus *i2c_bus, u
}
break;
case AST2600_I2CM_RX_DONE:
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ /*
+ * Workaround for controller/target packet mode enable rx done stuck issue
+ * When controller go for first read (RX_DONE), target mode will also effect
+ * Then controller will send nack, not operate anymore.
+ */
+ if (readl(i2c_bus->reg_base + AST2600_I2CS_CMD_STS) & AST2600_I2CS_PKT_MODE_EN) {
+ u32 target_cmd = readl(i2c_bus->reg_base + AST2600_I2CS_CMD_STS);
+
+ writel(0, i2c_bus->reg_base + AST2600_I2CS_CMD_STS);
+ writel(target_cmd, i2c_bus->reg_base + AST2600_I2CS_CMD_STS);
+ }
+ fallthrough;
+#endif
case AST2600_I2CM_RX_DONE | AST2600_I2CM_NORMAL_STOP:
xfer_len = AST2600_I2CC_GET_RX_BUF_LEN(readl(i2c_bus->reg_base +
AST2600_I2CC_BUFF_CTRL));
@@ -666,6 +932,12 @@ static irqreturn_t ast2600_i2c_bus_irq(int irq, void *dev_id)
{
struct ast2600_i2c_bus *i2c_bus = dev_id;
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ if (i2c_bus->target) {
+ if (ast2600_i2c_target_irq(i2c_bus))
+ return IRQ_HANDLED;
+ }
+#endif
return IRQ_RETVAL(ast2600_i2c_controller_irq(i2c_bus));
}
@@ -682,6 +954,21 @@ static int ast2600_i2c_controller_xfer(struct i2c_adapter *adap, struct i2c_msg
return ret;
}
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ if (READ_ONCE(i2c_bus->target_active))
+ return -EBUSY;
+ /*
+ * Controller and target share the same buffer register. A target
+ * transaction can update buffer state asynchronously via IRQ, so block
+ * controller transfers while target is active to avoid buffer corruption.
+ */
+ writel(0, i2c_bus->reg_base + AST2600_I2CS_IER);
+ if (readl(i2c_bus->reg_base + AST2600_I2CS_ISR) || READ_ONCE(i2c_bus->target_active)) {
+ writel(AST2600_I2CS_PKT_DONE, i2c_bus->reg_base + AST2600_I2CS_IER);
+ return -EBUSY;
+ }
+#endif
+
i2c_bus->cmd_err = 0;
i2c_bus->msgs = msgs;
i2c_bus->msgs_index = 0;
@@ -689,6 +976,10 @@ static int ast2600_i2c_controller_xfer(struct i2c_adapter *adap, struct i2c_msg
WRITE_ONCE(i2c_bus->stop_pending, false);
reinit_completion(&i2c_bus->cmd_complete);
ret = ast2600_i2c_do_start(i2c_bus);
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ /* avoid race condition target is wait and controller wait 1st target operate */
+ writel(AST2600_I2CS_PKT_DONE, i2c_bus->reg_base + AST2600_I2CS_IER);
+#endif
if (ret)
goto controller_out;
timeout = wait_for_completion_timeout(&i2c_bus->cmd_complete, i2c_bus->adap.timeout);
@@ -717,6 +1008,9 @@ static int ast2600_i2c_controller_xfer(struct i2c_adapter *adap, struct i2c_msg
* if the bus is still busy.
*/
if (i2c_bus->multi_master &&
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ !READ_ONCE(i2c_bus->target_active) &&
+#endif
(readl(i2c_bus->reg_base + AST2600_I2CC_STS_AND_BUFF) &
AST2600_I2CC_BUS_BUSY_STS))
ast2600_i2c_recover_bus(i2c_bus);
@@ -765,8 +1059,66 @@ static int ast2600_i2c_init(struct ast2600_i2c_bus *i2c_bus)
/* Clear Interrupt */
writel(GENMASK(27, 0), i2c_bus->reg_base + AST2600_I2CM_ISR);
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ writel(GENMASK(27, 0), i2c_bus->reg_base + AST2600_I2CS_ISR);
+#endif
+
+ return 0;
+}
+
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+static int ast2600_i2c_reg_target(struct i2c_client *client)
+{
+ struct ast2600_i2c_bus *i2c_bus = i2c_get_adapdata(client->adapter);
+ u32 cmd = TARGET_TRIGGER_CMD;
+
+ if (i2c_bus->target)
+ return -EINVAL;
+
+ if (client->flags & I2C_CLIENT_TEN)
+ return -EAFNOSUPPORT;
+
+ dev_dbg(i2c_bus->dev, "target addr %x\n", client->addr);
+
+ writel(0, i2c_bus->reg_base + AST2600_I2CS_ADDR_CTRL);
+
+ i2c_bus->target = client;
+
+ writel(AST2600_I2CC_SLAVE_EN | readl(i2c_bus->reg_base + AST2600_I2CC_FUN_CTRL),
+ i2c_bus->reg_base + AST2600_I2CC_FUN_CTRL);
+
+ writel(cmd, i2c_bus->reg_base + AST2600_I2CS_CMD_STS);
+ /* Set target addr. */
+ writel(client->addr | AST2600_I2CS_ADDR1_ENABLE,
+ i2c_bus->reg_base + AST2600_I2CS_ADDR_CTRL);
+
+ writel(AST2600_I2CS_PKT_DONE, i2c_bus->reg_base + AST2600_I2CS_IER);
+
+ return 0;
+}
+
+static int ast2600_i2c_unreg_target(struct i2c_client *client)
+{
+ struct ast2600_i2c_bus *i2c_bus = i2c_get_adapdata(client->adapter);
+ u32 val;
+
+ writel(0, i2c_bus->reg_base + AST2600_I2CS_IER);
+
+ val = readl(i2c_bus->reg_base + AST2600_I2CC_FUN_CTRL);
+ writel(val & ~AST2600_I2CC_SLAVE_EN, i2c_bus->reg_base + AST2600_I2CC_FUN_CTRL);
+ writel(0, i2c_bus->reg_base + AST2600_I2CS_ADDR_CTRL);
+
+ synchronize_irq(i2c_bus->irq);
+
+ writel(readl(i2c_bus->reg_base + AST2600_I2CS_ISR),
+ i2c_bus->reg_base + AST2600_I2CS_ISR);
+
+ i2c_bus->target = NULL;
+ WRITE_ONCE(i2c_bus->target_active, false);
+
return 0;
}
+#endif
static u32 ast2600_i2c_functionality(struct i2c_adapter *adap)
{
@@ -776,6 +1128,10 @@ static u32 ast2600_i2c_functionality(struct i2c_adapter *adap)
static const struct i2c_algorithm i2c_ast2600_algorithm = {
.xfer = ast2600_i2c_controller_xfer,
.functionality = ast2600_i2c_functionality,
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ .reg_target = ast2600_i2c_reg_target,
+ .unreg_target = ast2600_i2c_unreg_target,
+#endif
};
static const struct i2c_adapter_quirks ast2600_i2c_quirks = {
@@ -819,6 +1175,9 @@ static int ast2600_i2c_probe(struct platform_device *pdev)
regmap_write(i2c_bus->global_regs, AST2600_I2CG_CLK_DIV_CTRL, I2CCG_DIV_CTRL);
}
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ WRITE_ONCE(i2c_bus->target_active, false);
+#endif
i2c_bus->dev = dev;
i2c_bus->multi_master = device_property_read_bool(dev, "multi-master");
--
2.34.1
^ 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