* Re: [PATCH v1 11/13] dt-bindings: hwinfo: Add starfive,jhb100-socinfo
From: Changhuang Liang @ 2026-04-07 6:49 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Philipp Zabel, Emil Renner Berthing, Chen Wang,
Inochi Amaoto, Alexey Charkov, Thomas Bogendoerfer, Keguang Zhang,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
Leyfoon Tan
In-Reply-To: <20260405-strong-watchful-marmot-fdfad6@quoll>
Hi, Krzysztof
Thanks for the review.
> On Thu, Apr 02, 2026 at 10:49:43PM -0700, Changhuang Liang wrote:
> > Add starfive,jhb100-socinfo for StarFive JHB100 SoC.
> >
> > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> > ---
> > .../hwinfo/starfive,jhb100-socinfo.yaml | 36
> +++++++++++++++++++
> > 1 file changed, 36 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/hwinfo/starfive,jhb100-socinfo.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/hwinfo/starfive,jhb100-socinfo.yam
> > l
> > b/Documentation/devicetree/bindings/hwinfo/starfive,jhb100-socinfo.yam
> > l
> > new file mode 100644
> > index 000000000000..cc6b7d5a4c91
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwinfo/starfive,jhb100-socinfo
> > +++ .yaml
> > @@ -0,0 +1,36 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +http://devicetree.org/schemas/hwinfo/starfive,jhb100-socinfo.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: StarFive JHB100 SoC platform chipid module
> > +
> > +maintainers:
> > + - Changhuang Liang <changhuang.liang@starfivetech.com>
> > +
> > +description:
> > + StarFive JHB100 SoC platform chipid module is represented by
> > +JHB100_PRODUCT_ID
> > + register which contains information about revision. This register
> > +is located
> > + under the syscon.
> > +
> > +properties:
> > + compatible:
> > + items:
> > + - const: starfive,jhb100-socinfo
>
> No, not a separate device.
>
> > +
> > + reg:
> > + maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + chipid@38 {
> > + compatible = "starfive,jhb100-socinfo";
> > + reg = <0x38 0x4>;
>
> One register is not a device. NAK.
I noticed that other platforms have similar practices:
https://elixir.bootlin.com/linux/v7.0-rc7/source/arch/arm/boot/dts/aspeed/aspeed-g4.dtsi#L205
or could you provide me with alternative suggestions? Thank you very much.
Best Regards,
Changhuang
^ permalink raw reply
* Re: [PATCH 4/6] arm64: dts: qcom: kaanapali-mtp: Enable bluetooth and Wifi
From: Zijun Hu @ 2026-04-07 6:49 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Jingyi Wang, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, aiqun.yu, tingwei.zhang,
trilok.soni, yijie.yang, linux-arm-msm, devicetree, linux-kernel,
20260224-knp-dts-misc-v6-0-79d20dab8a60
In-Reply-To: <crlrsxrpzqad2oj7u7sjdtpdxnbdjjfw7kogughydgnlatw7m7@qpytwjgmrzke>
On 4/1/2026 10:07 PM, Dmitry Baryshkov wrote:
>>>> 2) its driver does not parse and use the property 'swctrl-gpios', moreover, the
>>>> property have no user within upstream DT tree.
>>> There is no "driver" in the "DT bindings"
>>>
>> 'its driver' i mean here is the driver which drives the device which is generated
>> by this DT node 'qcom,wcn7850-pmu'.
>> source code of the driver is drivers/power/sequencing/pwrseq-qcom-wcn.c
> DT describes the hardware. The driver behaviour is not that relevant
> here.
agree with your opinion which is right (^^)
>
>>>> 3) the property is not mandatory based on binding spec.
>>> Which is expected, because on some platforms it might be not wired up
>>> and on the other platforms the pin to which it is wired to might be
>>> unknown (think about all the phones for which the community doesn't have
>>> schematics).
>>>
>> got your points and will explain mine at below 2) together.
>>
>>>> 4) upstream DT tree have had many such usages as mine which just set default pin
>>>> configuration and not specify 'swctrl-gpios' explicitly.
>>> I don't understand this part.
>>>
>> For DT node 'qcom,wcn7850-pmu' of products identified by the following dts file at least:
>>
>> wcn7850-pmu {
>> compatible = "qcom,wcn7850-pmu";
>>
>> pinctrl-names = "default"; // config SW_CTRL pin default settings, but
>> pinctrl-0 = ....; // this DT node does not specify property 'swctrl-gpios'.
>> ....
>> }
>>
>>
>> grep -l -r "qcom,wcn7850-pmu" arch/arm64/boot/dts/qcom/ | xargs grep -l -r "sw[_-]ctrl"
>> arch/arm64/boot/dts/qcom/sm8550-hdk.dts
>> arch/arm64/boot/dts/qcom/sm8650-qrd.dts
>> arch/arm64/boot/dts/qcom/sm8750-mtp.dts
>> arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
>> arch/arm64/boot/dts/qcom/sm8550-qrd.dts
>> arch/arm64/boot/dts/qcom/sm8650-hdk.dts
> So, let's fix them too.
>
perhaps. also fix for kaanapali-mtp whose DT have gone into linux-next.
BTW, there may be other 'qcom,wcnxxxx-pmu' which have the same problem to fix besides
'qcom,wcn7850-pmu'.
>>>> 5) kaanapali-mtp is originally preinstalled with android OS which supports some
>>>> qualcomm specific feature which have not been supported by up-stream kernel.
>>>> so kaanapali-mtp H/W has some wired pins which is not used by up-stream
>>>> kernel sometimes
>>> Again, what does that have to do with the hardware description?
>> kaanapali-mtp hardware supports the feature pin SW_CTRL involved, but we can decide
>> not to enable the feature based on requirements.
>>
>> any advise about how to correct DTS to not enable the feature SW_CTRL involved ?
> You can enable or disable something in the driver. It doesn't change the
> way the chip is wired (that's what DT describes).
got it. thank you. (^^)
^ permalink raw reply
* Re: [PATCH v5 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Linus Walleij @ 2026-04-07 6:48 UTC (permalink / raw)
To: Frank Li, Peter Rosin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-kernel, linux-gpio, devicetree, imx,
linux-arm-kernel, Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <CAD++jLmoHiJWV3J8f3TtpmQWLpUFD24icQEv2cbO3+x7775zxw@mail.gmail.com>
On Tue, Apr 7, 2026 at 8:42 AM Linus Walleij <linusw@kernel.org> wrote:
> > mux: add devm_mux_control_get_from_np() to get mux from child node
>
> Didn't get an ACK from the mux maintainer for this but this has been going
> on for long now so I applied it.
>
> Peter: protest if you don't like this and I will back it out.
I created an immutable branch for Peter to pull in if he want it:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=ib-mux-pinctrl
(You can also pull in just the bottom commit which is just the mux change)
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH V10 04/13] PCI: imx6: Assert PERST# before enabling regulators
From: Manivannan Sadhasivam @ 2026-04-07 6:46 UTC (permalink / raw)
To: Sherry Sun
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB12114917D17B5B8FB67E68DB9925AA@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Tue, Apr 07, 2026 at 06:38:50AM +0000, Sherry Sun wrote:
>
> > On Thu, Apr 02, 2026 at 05:50:58PM +0800, Sherry Sun wrote:
> > > According to the PCIe initialization requirements, PERST# signal
> > > should be asserted before applying power to the PCIe device, and
> > > deasserted after power and reference clock are stable.
> > >
> >
> > Spec wording is not quite like this. Spec mandates asserting PERST# *before*
> > stopping refclk and powering down the device and deasserting it *after*
> > applying power and refclk stable.
> >
> > I believe you want to assert PERST# before enabling regulator to prevent the
> > endpoint from functioning? If so, is it due to refclk not available yet or some
> > other reason?
>
> You are right. My commit message wording was not that precise.
> The PCIe endpoint may start responding or driving signals as
> soon as its supply is enabled, even before the reference clock is stable.
> Asserting PERST# before enabling the regulator ensures that the endpoint
> remains in reset throughout the entire power-up sequence, until both
> power and refclk are known to be stable and link initialization can safely
> begin. This is mainly to avoid undefined behavior during early power-up.
>
> I will update the commit message to better reflect this.
>
> >
> > > Currently, the driver enables the vpcie3v3aux regulator in
> > > imx_pcie_probe() before PERST# is asserted in imx_pcie_host_init(),
> > > which violates the PCIe power sequencing requirements. However, there
> > > is no issue so far because PERST# is requested as GPIOD_OUT_HIGH in
> > > imx_pcie_probe(), which guarantees that PERST# is asserted before
> > > enabling the vpcie3v3aux regulator.
> > >
> > > This is prepare for the upcoming changes that will parse the reset
> > > property using the new Root Port binding, which will use GPIOD_ASIS
> > > when requesting the reset GPIO. With GPIOD_ASIS, the GPIO state is not
> > > guaranteed, so explicit sequencing is required.
> > >
> > > Fix the power sequencing by:
> > > 1. Moving vpcie3v3aux regulator enable from probe to
> > > imx_pcie_host_init(), where it can be properly sequenced with PERST#.
> > > 2. Moving imx_pcie_assert_perst() before regulator and clock enable to
> > > ensure correct ordering.
> > >
> > > The vpcie3v3aux regulator is kept enabled for the entire PCIe
> > > controller lifecycle and automatically disabled on device removal via devm
> > cleanup.
> > >
> >
> > vpcie3v3aux handling should be in a separate patch.
>
> Actually the handling of vpcie3v3aux itself remains unchanged, I just adjust the
> sequence of regulator/clock enable and perst#.
> Previously, the imx driver enabled the vpcie3v3aux regulator in imx_pcie_probe()
> before PERST# is asserted in imx_pcie_host_init(), which violates the PCIe power
> sequencing requirements.
> This patch moves vpcie3v3aux regulator enable from probe to imx_pcie_host_init(),
> where it can be properly sequenced with PERST#.
> Perhaps I should just remove this description to avoid confusion.
>
Yeah.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 0/3] i2c: ma35d1: Add support for MA35D1 I2C controller
From: zychen @ 2026-04-07 6:45 UTC (permalink / raw)
To: andi.shyti, ychuang3
Cc: robh, krzk+dt, conor+dt, linux-i2c, devicetree, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260316063726.41048-1-zychennvt@gmail.com>
Hi Andi and Krzysztof,
I'm following up on this series. As detailed in the change log, v2 addresses the feedback from v1 regarding the modernization of legacy code.
I am preparing v3 to address minor formatting issues in Patch 3 (DTS). Before sending it out, I would highly appreciate any technical feedback on the driver logic in Patch 2 to ensure it aligns with your expectations.
Best regards,
Zi-Yu
Zi-Yu Chen 於 2026/3/16 下午 02:37 寫道:
> This series adds support for the I2C controller found in the Nuvoton
> MA35D1 SoC. The driver supports controller and optional target mode
> and runtime power management.
>
> The implementation has been tested on the Nuvoton MA35D1 SOM board.
>
> Changes in v2:
> - Overall:
> - Rebase on linux-i2c/i2c-next
> - Switched terminology from "master/slave" to "controller/target".
>
> - Patch 1 (dt-bindings):
> - Simplified description and fixed 'reg' size in example.
>
> - Patch 2 (driver):
> - Modernized using devm_*, generic device properties, and FIELD_PREP/GENMASK.
> - Optimized power management by moving clock control to runtime PM.
> - Simplified code by removing redundant .remove(), .owner, and inlines.
> - Added dev_err_probe() and default bus frequency handling.
>
> - Patch 3 (dts):
> - Moved i2c aliases to board dts and reordered nodes alphabetically.
>
> -Link to v1: https://lore.kernel.org/r/20260302020822.13936-1-zychennvt@gmail.com
>
> Zi-Yu Chen (3):
> dt-bindings: i2c: nuvoton,ma35d1-i2c: Add MA35D1 I2C controller
> i2c: ma35d1: Add Nuvoton MA35D1 I2C driver support
> arm64: dts: nuvoton: Add I2C nodes for MA35D1 SoC
>
> .../bindings/i2c/nuvoton,ma35d1-i2c.yaml | 63 ++
> .../boot/dts/nuvoton/ma35d1-som-256m.dts | 18 +-
> arch/arm64/boot/dts/nuvoton/ma35d1.dtsi | 60 ++
> drivers/i2c/busses/Kconfig | 13 +
> drivers/i2c/busses/Makefile | 1 +
> drivers/i2c/busses/i2c-ma35d1.c | 792 ++++++++++++++++++
> 6 files changed, 946 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/i2c/nuvoton,ma35d1-i2c.yaml
> create mode 100644 drivers/i2c/busses/i2c-ma35d1.c
>
^ permalink raw reply
* [PATCH v5 3/3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Enable ath10k host-cap skip quirk
From: David Heidelberg via B4 Relay @ 2026-04-07 6:43 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio, Paul Sajna
Cc: Baochen Qiang, Vasanthakumar Thiagarajan, Dmitry Baryshkov,
Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel, David Heidelberg
In-Reply-To: <20260407-skip-host-cam-qmi-req-v5-0-dfa8a05c6538@ixit.cz>
From: Amit Pundir <amit.pundir@linaro.org>
The Wi-Fi firmware used on Xiaomi Poco F1 (beryllium) phone doesn't
support the host-capability QMI request, so add a quirk to skip it on
this device.
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-common.dtsi
index 1298485c42142..950bbcc3bf91f 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-common.dtsi
@@ -661,5 +661,6 @@ &wifi {
vdd-3.3-ch1-supply = <&vreg_l23a_3p3>;
qcom,calibration-variant = "xiaomi_beryllium";
+ qcom,snoc-host-cap-skip-quirk;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v5 0/3] ath10k: Introduce a devicetree quirk to skip host cap QMI requests
From: David Heidelberg via B4 Relay @ 2026-04-07 6:43 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio, Paul Sajna
Cc: Baochen Qiang, Vasanthakumar Thiagarajan, Dmitry Baryshkov,
Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel, David Heidelberg
This quirk is used so far used on:
- LG G7 ThinQ
- Xiaomi Poco F1
I'm resending it after ~ 4 years since initial send due to Snapdragon
845 being one of best supported platform for mobile phones running
Linux, so it would be shame to not have shiny support.
Original thread:
https://lore.kernel.org/all/b796bfee-b753-479a-a8d6-ba1fe3ee6222@ixit.cz/
I tried the embedding the information inside the firmware, but the
information is required *before* loading the firmware itself.
Firmware quirk thread:
https://lore.kernel.org/linux-wireless/20251111-xiaomi-beryllium-firmware-v1-0-836b9c51ad86@ixit.cz/
Until merged, available also at:
https://codeberg.org/sdm845/linux/commits/branch/b4/skip-host-cam-qmi-req
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Changes in v5:
- Implement device-tree mutual-exclusion between
snoc-host-cap-8bit-quirk and snoc-host-cap-skip-quirk. (Krzysztof)
- Link to v4: https://lore.kernel.org/r/20260325-skip-host-cam-qmi-req-v4-0-bc08538487aa@ixit.cz
Changes in v4:
- Added my own missing SoB. (Dmitry)
- Improve the commit message. (Dmitry)
- Link to v3: https://lore.kernel.org/r/20260325-skip-host-cam-qmi-req-v3-0-b163cf7b3c81@ixit.cz
Changes in v3:
- Rebased on recent linux-next (next-20260325).
- Improved motivation and description. (Dmitry)
- Link to v2: https://lore.kernel.org/r/20251110-skip-host-cam-qmi-req-v2-0-0daf485a987a@ixit.cz
---
Amit Pundir (3):
dt-bindings: wireless: ath10k: Add quirk to skip host cap QMI requests
ath10k: Add device-tree quirk to skip host cap QMI requests
arm64: dts: qcom: sdm845-xiaomi-beryllium: Enable ath10k host-cap skip quirk
.../devicetree/bindings/net/wireless/qcom,ath10k.yaml | 11 +++++++++++
.../arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-common.dtsi | 1 +
drivers/net/wireless/ath/ath10k/qmi.c | 13 ++++++++++---
drivers/net/wireless/ath/ath10k/snoc.c | 3 +++
drivers/net/wireless/ath/ath10k/snoc.h | 1 +
5 files changed, 26 insertions(+), 3 deletions(-)
---
base-commit: 816f193dd0d95246f208590924dd962b192def78
change-id: 20251110-skip-host-cam-qmi-req-e155628ebc39
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* [PATCH v5 2/3] ath10k: Add device-tree quirk to skip host cap QMI requests
From: David Heidelberg via B4 Relay @ 2026-04-07 6:43 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio, Paul Sajna
Cc: Baochen Qiang, Vasanthakumar Thiagarajan, Dmitry Baryshkov,
Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel, David Heidelberg
In-Reply-To: <20260407-skip-host-cam-qmi-req-v5-0-dfa8a05c6538@ixit.cz>
From: Amit Pundir <amit.pundir@linaro.org>
Some firmware versions do not support the host capability QMI request.
Since this request occurs before firmware-N.bin and board-M.bin are
loaded, the quirk cannot be expressed in the firmware itself.
The root cause is unclear, but there appears to be a generation of
firmware that lacks host capability support.
Without this quirk, ath10k_qmi_host_cap_send_sync() returns
QMI_ERR_MALFORMED_MSG_V01 before loading the firmware. This error is not
fatal - Wi-Fi services still come up successfully if the request is simply
skipped.
Add a device-tree quirk to skip the host capability QMI request on devices
whose firmware does not support it.
For example, firmware build
"QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1"
on Xiaomi Poco F1 phone requires this quirk.
Suggested-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Tested-by: Paul Sajna <sajattack@postmarketos.org>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
drivers/net/wireless/ath/ath10k/qmi.c | 13 ++++++++++---
drivers/net/wireless/ath/ath10k/snoc.c | 3 +++
drivers/net/wireless/ath/ath10k/snoc.h | 1 +
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index eebd78e7ff6bc..e7f90fd9e9b83 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -808,6 +808,7 @@ ath10k_qmi_ind_register_send_sync_msg(struct ath10k_qmi *qmi)
static void ath10k_qmi_event_server_arrive(struct ath10k_qmi *qmi)
{
struct ath10k *ar = qmi->ar;
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
int ret;
ret = ath10k_qmi_ind_register_send_sync_msg(qmi);
@@ -819,9 +820,15 @@ static void ath10k_qmi_event_server_arrive(struct ath10k_qmi *qmi)
return;
}
- ret = ath10k_qmi_host_cap_send_sync(qmi);
- if (ret)
- return;
+ /*
+ * Skip the host capability request for the firmware versions which
+ * do not support this feature.
+ */
+ if (!test_bit(ATH10K_SNOC_FLAG_SKIP_HOST_CAP_QUIRK, &ar_snoc->flags)) {
+ ret = ath10k_qmi_host_cap_send_sync(qmi);
+ if (ret)
+ return;
+ }
ret = ath10k_qmi_msa_mem_info_send_sync_msg(qmi);
if (ret)
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index f72f236fb9eb3..3106502275781 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -1362,6 +1362,9 @@ static void ath10k_snoc_quirks_init(struct ath10k *ar)
if (of_property_read_bool(dev->of_node, "qcom,snoc-host-cap-8bit-quirk"))
set_bit(ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK, &ar_snoc->flags);
+
+ if (of_property_read_bool(dev->of_node, "qcom,snoc-host-cap-skip-quirk"))
+ set_bit(ATH10K_SNOC_FLAG_SKIP_HOST_CAP_QUIRK, &ar_snoc->flags);
}
int ath10k_snoc_fw_indication(struct ath10k *ar, u64 type)
diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
index 1ecae34687c21..46574fd8f84ee 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.h
+++ b/drivers/net/wireless/ath/ath10k/snoc.h
@@ -51,6 +51,7 @@ enum ath10k_snoc_flags {
ATH10K_SNOC_FLAG_MODEM_STOPPED,
ATH10K_SNOC_FLAG_RECOVERY,
ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK,
+ ATH10K_SNOC_FLAG_SKIP_HOST_CAP_QUIRK,
};
struct clk_bulk_data;
--
2.53.0
^ permalink raw reply related
* [PATCH v5 1/3] dt-bindings: wireless: ath10k: Add quirk to skip host cap QMI requests
From: David Heidelberg via B4 Relay @ 2026-04-07 6:43 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio, Paul Sajna
Cc: Baochen Qiang, Vasanthakumar Thiagarajan, Dmitry Baryshkov,
Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel, David Heidelberg
In-Reply-To: <20260407-skip-host-cam-qmi-req-v5-0-dfa8a05c6538@ixit.cz>
From: Amit Pundir <amit.pundir@linaro.org>
Some firmware versions do not support the host-capability QMI request.
Since this request occurs before firmware and board files are loaded,
the quirk cannot be expressed in the firmware itself and must be described
in the device tree.
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Co-developed-by: David Heidelberg <david@ixit.cz>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
.../devicetree/bindings/net/wireless/qcom,ath10k.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
index f2440d39b7ebc..c21d66c7cd558 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
@@ -171,6 +171,12 @@ properties:
Quirk specifying that the firmware expects the 8bit version
of the host capability QMI request
+ qcom,snoc-host-cap-skip-quirk:
+ type: boolean
+ description:
+ Quirk specifying that the firmware wants to skip the host
+ capability QMI request
+
qcom,xo-cal-data:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@@ -292,6 +298,11 @@ allOf:
required:
- interrupts
+ - not:
+ required:
+ - qcom,snoc-host-cap-8bit-quirk
+ - qcom,snoc-host-cap-skip-quirk
+
examples:
# SNoC
- |
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Linus Walleij @ 2026-04-07 6:42 UTC (permalink / raw)
To: Frank Li, Peter Rosin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-kernel, linux-gpio, devicetree, imx,
linux-arm-kernel, Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <20260327-pinctrl-mux-v5-0-d4aec9d62c62@nxp.com>
Hi Frank,
OK let's apply it!
On Fri, Mar 27, 2026 at 10:34 PM Frank Li <Frank.Li@nxp.com> wrote:
> mux: add devm_mux_control_get_from_np() to get mux from child node
Didn't get an ACK from the mux maintainer for this but this has been going
on for long now so I applied it.
Peter: protest if you don't like this and I will back it out.
> dt-bindings: pinctrl: Add generic pinctrl for board-level mux chips
> pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
> pinctrl: add optional .release_mux() callback
> pinctrl: add generic board-level pinctrl driver using mux framework
Those applied.
> arm64: dts: imx8mp-evk: add board-level mux for CAN2 and MICFIL
> arm64: dts: imx8mp-evk: add flexcan2 overlay file
Please funnel these through the SoC tree!
Yours,
Linus Walleij
^ permalink raw reply
* RE: [PATCH V10 04/13] PCI: imx6: Assert PERST# before enabling regulators
From: Sherry Sun @ 2026-04-07 6:38 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <jwazawvhuoafkhfwpjfgccc3hz6kej7i6iwkh5be2qena2b4di@yzv6e75zezfu>
> On Thu, Apr 02, 2026 at 05:50:58PM +0800, Sherry Sun wrote:
> > According to the PCIe initialization requirements, PERST# signal
> > should be asserted before applying power to the PCIe device, and
> > deasserted after power and reference clock are stable.
> >
>
> Spec wording is not quite like this. Spec mandates asserting PERST# *before*
> stopping refclk and powering down the device and deasserting it *after*
> applying power and refclk stable.
>
> I believe you want to assert PERST# before enabling regulator to prevent the
> endpoint from functioning? If so, is it due to refclk not available yet or some
> other reason?
You are right. My commit message wording was not that precise.
The PCIe endpoint may start responding or driving signals as
soon as its supply is enabled, even before the reference clock is stable.
Asserting PERST# before enabling the regulator ensures that the endpoint
remains in reset throughout the entire power-up sequence, until both
power and refclk are known to be stable and link initialization can safely
begin. This is mainly to avoid undefined behavior during early power-up.
I will update the commit message to better reflect this.
>
> > Currently, the driver enables the vpcie3v3aux regulator in
> > imx_pcie_probe() before PERST# is asserted in imx_pcie_host_init(),
> > which violates the PCIe power sequencing requirements. However, there
> > is no issue so far because PERST# is requested as GPIOD_OUT_HIGH in
> > imx_pcie_probe(), which guarantees that PERST# is asserted before
> > enabling the vpcie3v3aux regulator.
> >
> > This is prepare for the upcoming changes that will parse the reset
> > property using the new Root Port binding, which will use GPIOD_ASIS
> > when requesting the reset GPIO. With GPIOD_ASIS, the GPIO state is not
> > guaranteed, so explicit sequencing is required.
> >
> > Fix the power sequencing by:
> > 1. Moving vpcie3v3aux regulator enable from probe to
> > imx_pcie_host_init(), where it can be properly sequenced with PERST#.
> > 2. Moving imx_pcie_assert_perst() before regulator and clock enable to
> > ensure correct ordering.
> >
> > The vpcie3v3aux regulator is kept enabled for the entire PCIe
> > controller lifecycle and automatically disabled on device removal via devm
> cleanup.
> >
>
> vpcie3v3aux handling should be in a separate patch.
Actually the handling of vpcie3v3aux itself remains unchanged, I just adjust the
sequence of regulator/clock enable and perst#.
Previously, the imx driver enabled the vpcie3v3aux regulator in imx_pcie_probe()
before PERST# is asserted in imx_pcie_host_init(), which violates the PCIe power
sequencing requirements.
This patch moves vpcie3v3aux regulator enable from probe to imx_pcie_host_init(),
where it can be properly sequenced with PERST#.
Perhaps I should just remove this description to avoid confusion.
Best Regards
Sherry
>
> - Mani
>
> > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > ---
> > drivers/pci/controller/dwc/pci-imx6.c | 49
> > +++++++++++++++++++++------
> > 1 file changed, 39 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 45d70ae7e04f..948ffb75d122 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -166,6 +166,8 @@ struct imx_pcie {
> > u32 tx_swing_full;
> > u32 tx_swing_low;
> > struct regulator *vpcie;
> > + struct regulator *vpcie_aux;
> > + bool vpcie_aux_enabled;
> > struct regulator *vph;
> > void __iomem *phy_base;
> >
> > @@ -1220,6 +1222,13 @@ static void imx_pcie_disable_device(struct
> pci_host_bridge *bridge,
> > imx_pcie_remove_lut(imx_pcie, pci_dev_id(pdev)); }
> >
> > +static void imx_pcie_vpcie_aux_disable(void *data) {
> > + struct regulator *vpcie_aux = data;
> > +
> > + regulator_disable(vpcie_aux);
> > +}
> > +
> > static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool
> > assert) {
> > if (assert) {
> > @@ -1240,6 +1249,24 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> *pp)
> > struct imx_pcie *imx_pcie = to_imx_pcie(pci);
> > int ret;
> >
> > + imx_pcie_assert_perst(imx_pcie, true);
> > +
> > + /* Keep 3.3Vaux supply enabled for the entire PCIe controller lifecycle
> */
> > + if (imx_pcie->vpcie_aux && !imx_pcie->vpcie_aux_enabled) {
> > + ret = regulator_enable(imx_pcie->vpcie_aux);
> > + if (ret) {
> > + dev_err(dev, "failed to enable vpcie_aux
> regulator: %d\n",
> > + ret);
> > + return ret;
> > + }
> > + imx_pcie->vpcie_aux_enabled = true;
> > +
> > + ret = devm_add_action_or_reset(dev,
> imx_pcie_vpcie_aux_disable,
> > + imx_pcie->vpcie_aux);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > if (imx_pcie->vpcie) {
> > ret = regulator_enable(imx_pcie->vpcie);
> > if (ret) {
> > @@ -1249,25 +1276,24 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> *pp)
> > }
> > }
> >
> > + ret = imx_pcie_clk_enable(imx_pcie);
> > + if (ret) {
> > + dev_err(dev, "unable to enable pcie clocks: %d\n", ret);
> > + goto err_reg_disable;
> > + }
> > +
> > if (pp->bridge && imx_check_flag(imx_pcie,
> IMX_PCIE_FLAG_HAS_LUT)) {
> > pp->bridge->enable_device = imx_pcie_enable_device;
> > pp->bridge->disable_device = imx_pcie_disable_device;
> > }
> >
> > imx_pcie_assert_core_reset(imx_pcie);
> > - imx_pcie_assert_perst(imx_pcie, true);
> >
> > if (imx_pcie->drvdata->init_phy)
> > imx_pcie->drvdata->init_phy(imx_pcie);
> >
> > imx_pcie_configure_type(imx_pcie);
> >
> > - ret = imx_pcie_clk_enable(imx_pcie);
> > - if (ret) {
> > - dev_err(dev, "unable to enable pcie clocks: %d\n", ret);
> > - goto err_reg_disable;
> > - }
> > -
> > if (imx_pcie->phy) {
> > ret = phy_init(imx_pcie->phy);
> > if (ret) {
> > @@ -1780,9 +1806,12 @@ static int imx_pcie_probe(struct platform_device
> *pdev)
> > of_property_read_u32(node, "fsl,max-link-speed", &pci-
> >max_link_speed);
> > imx_pcie->supports_clkreq = of_property_read_bool(node,
> > "supports-clkreq");
> >
> > - ret = devm_regulator_get_enable_optional(&pdev->dev,
> "vpcie3v3aux");
> > - if (ret < 0 && ret != -ENODEV)
> > - return dev_err_probe(dev, ret, "failed to enable Vaux
> supply\n");
> > + imx_pcie->vpcie_aux = devm_regulator_get_optional(&pdev->dev,
> "vpcie3v3aux");
> > + if (IS_ERR(imx_pcie->vpcie_aux)) {
> > + if (PTR_ERR(imx_pcie->vpcie_aux) != -ENODEV)
> > + return PTR_ERR(imx_pcie->vpcie_aux);
> > + imx_pcie->vpcie_aux = NULL;
> > + }
> >
> > imx_pcie->vpcie = devm_regulator_get_optional(&pdev->dev,
> "vpcie");
> > if (IS_ERR(imx_pcie->vpcie)) {
> > --
> > 2.37.1
> >
>
> --
> மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v6 3/3] fpga-mgr: Add Efinix SPI programming driver
From: Xu Yilun @ 2026-04-07 6:12 UTC (permalink / raw)
To: iansdannapel
Cc: linux-fpga, devicetree, linux-kernel, mdf, yilun.xu, trix, robh,
krzk+dt, conor+dt, neil.armstrong, heiko, marex,
prabhakar.mahadev-lad.rj, dev
In-Reply-To: <20260327114842.1300284-4-iansdannapel@gmail.com>
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index aeb89bb13517..21eb0ef1fc2e 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_FPGA_MGR_VERSAL_FPGA) += versal-fpga.o
> obj-$(CONFIG_FPGA_MGR_MICROCHIP_SPI) += microchip-spi.o
> obj-$(CONFIG_FPGA_MGR_LATTICE_SYSCONFIG) += lattice-sysconfig.o
> obj-$(CONFIG_FPGA_MGR_LATTICE_SYSCONFIG_SPI) += lattice-sysconfig-spi.o
> +obj-$(CONFIG_FPGA_MGR_EFINIX_SPI) += efinix-spi.o
> obj-$(CONFIG_ALTERA_PR_IP_CORE) += altera-pr-ip-core.o
> obj-$(CONFIG_ALTERA_PR_IP_CORE_PLAT) += altera-pr-ip-core-plat.o
This is the tail of "FPGA Manager Drivers", move it here.
...
> +static int efinix_spi_write_init(struct fpga_manager *mgr,
> + struct fpga_image_info *info,
> + const char *buf, size_t count)
> +{
> + struct device *dev = &mgr->dev;
Why do you make this change? This is just one-time usage, and in some
other functions you don't make the same change. Please delete it.
> + struct efinix_spi_conf *conf = mgr->priv;
> + struct spi_transfer assert_cs = {
> + .cs_change = 1,
> + };
> + struct spi_message message;
> + int ret;
> +
> + if (info->flags & FPGA_MGR_PARTIAL_RECONFIG) {
> + dev_err(dev, "Partial reconfiguration not supported\n");
> + return -EOPNOTSUPP;
> + }
> +
> + /*
> + * Efinix passive SPI configuration requires chip select to stay
> + * asserted from reset until the bitstream is fully clocked in.
> + * Lock the SPI bus so no other device can toggle CS between the
> + * reset pulse and the write/complete transfers.
> + */
> + spi_bus_lock(conf->spi->controller);
> + spi_message_init_with_transfers(&message, &assert_cs, 1);
> + ret = spi_sync_locked(conf->spi, &message);
> + if (ret) {
> + spi_bus_unlock(conf->spi->controller);
> + return ret;
> + }
> +
> + /* Reset with CS asserted */
> + efinix_spi_reset(conf);
> +
> + return 0;
> +}
> +
> +static int efinix_spi_write(struct fpga_manager *mgr, const char *buf,
> + size_t count)
> +{
> + struct device *dev = &mgr->dev;
ditto.
> + struct spi_transfer write_xfer = {
> + .tx_buf = buf,
> + .len = count,
> + .cs_change = 1, /* Keep CS asserted */
Move this comment to its first appearance.
...
> +static const struct of_device_id efinix_spi_of_match[] = {
> + { .compatible = "efinix,trion-config", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, efinix_spi_of_match);
> +
> +static const struct spi_device_id efinix_ids[] = {
> + { "trion-config", 0 },
> + { "titanium-config", 0 },
> + { "topaz-config", 0 },
Since you've trimmed of_match_table, any reason to keep 3
spi_device_ids? IIUC you could keep them in sync.
^ permalink raw reply
* Re: [PATCH v4 1/4] dt-bindings: arm: hpe,gxp: Add HPE GSC platform compatible
From: Krzysztof Kozlowski @ 2026-04-07 6:31 UTC (permalink / raw)
To: nick.hawkins
Cc: catalin.marinas, will, robh, krzk+dt, conor+dt, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260406143821.1843621-2-nick.hawkins@hpe.com>
On Mon, Apr 06, 2026 at 02:38:18PM +0000, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> From: Nick Hawkins <nick.hawkins@hpe.com>
Duplicated From parts.
With this fixed:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 3/3] riscv: dts: spacemit: Enable USB3.0/PCIe on OrangePi RV2
From: Chukun Pan @ 2026-04-07 6:30 UTC (permalink / raw)
To: dlan
Cc: alex, amadeus, aou, conor+dt, devicetree, gaohan, krzk+dt,
linux-kernel, linux-riscv, palmer, pjw, rabenda.cn, robh,
spacemit
In-Reply-To: <20260403141637-GKA1042809@kernel.org>
Hi,
> I think Krzysztof will have objection on this, which isn't used by any
> device, so not really useful, see similar comment for "reg_dc_in" here
Currently, at least it's used for USB hub vdd-supply. Since there's
only this one, indicating a power source, I think it's acceptable.
> I'm not sure if there is any enforced rules on this? I can understand
> you are trying to sort them in alphabet order.. but I would personally
> prefer old way - in slightly logical order.. but I do have no strong
> preference..
There are no strict rules, but I think it would be better to keep
the same order as the regulators below within the same DT.
Thanks,
Chukun
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: iio: dac: Add ADI AD5706R
From: Krzysztof Kozlowski @ 2026-04-07 6:29 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260407-dev_ad5706r-v5-1-a4c7737b6ae9@analog.com>
On Tue, Apr 07, 2026 at 11:39:44AM +0800, Alexis Czezar Torreno wrote:
> Add device tree binding documentation for the Analog Devices
> AD5706R 4-channel 16-bit current output digital-to-analog converter.
>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
>
> ---
> Changes in v5:
> - Changed out-en-gpios to enable-gpios.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v1] dt-bindings: usb: Fix EIC7700 USB reset's issue
From: caohang @ 2026-04-07 6:17 UTC (permalink / raw)
To: gregkh, robh, krzk+dt, conor+dt, Thinh.Nguyen, p.zabel,
linux-kernel, linux-usb, devicetree
Cc: ningyu, linmin, pinkesh.vaghela, Hang Cao
From: Hang Cao <caohang@eswincomputing.com>
The EIC7700 USB controller requires a USB PHY RESET operation.PHY RESET
operation was missed in the verification version, as it was performed in
ESWIN's U-Boot.
If a non-ESWIN provided loader is used, this issue will occur, resulting
in USB not work.This patch does not introduce any backward incompatibility
since the dts is not upstream yet.
Fixes: c640a4239db5 ("dt-bindings: usb: Add ESWIN EIC7700 USB controller")
Signed-off-by: Hang Cao <caohang@eswincomputing.com>
---
.../devicetree/bindings/usb/eswin,eic7700-usb.yaml | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml b/Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml
index 41c3b1b98991..658260619423 100644
--- a/Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml
+++ b/Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml
@@ -41,12 +41,13 @@ properties:
- const: usb_en
resets:
- maxItems: 2
+ maxItems: 3
reset-names:
items:
- const: vaux
- const: usb_rst
+ - const: usb_phy
eswin,hsp-sp-csr:
description:
@@ -85,8 +86,8 @@ examples:
interrupt-parent = <&plic>;
interrupts = <85>;
interrupt-names = "peripheral";
- resets = <&reset 84>, <&hspcrg 2>;
- reset-names = "vaux", "usb_rst";
+ resets = <&reset 84>, <&hspcrg 2>, <&hspcrg 4>;
+ reset-names = "vaux", "usb_rst", "usb_phy";
dr_mode = "peripheral";
maximum-speed = "high-speed";
phy_type = "utmi";
--
2.34.1
^ permalink raw reply related
* Re: [Upstream] Re: [PATCH] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlay
From: Primoz Fiser @ 2026-04-07 6:14 UTC (permalink / raw)
To: Frank Li, Florijan Plohl
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel, upstream
In-Reply-To: <adMg762HH4gcuWyq@lizhi-Precision-Tower-5810>
Hi Frank, Florijan,
On 4/6/26 04:56, Frank Li wrote:
> On Fri, Apr 03, 2026 at 10:29:00AM +0200, Florijan Plohl wrote:
>> Hello,
>>
>> On 4/2/26 15:50, Frank Li wrote:
>>> On Thu, Apr 02, 2026 at 09:08:26AM +0200, Florijan Plohl wrote:
>>>> Add overlay for the PEB-AV-18 adapter on phyBOARD-Segin-i.MX91/93.
>>> what's means PEB-AV-18? Is it random board name?
>> The PEB-AV-18 is PHYTEC designation for Audio/Video adapter modules that can
>> be used to connect displays on their boards.
>>
>> I will improve commit message to add more such information in v2.
>>
>>>
>>>
>>>> The supported LCD is Powertip PH800480T032-ZHC19 panel (AC220).
>>>>
>>>> Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
>>>> ---
>>>> arch/arm64/boot/dts/freescale/Makefile | 4 +
>>>> .../imx91-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
>>>> .../imx93-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
>>> Any difference between 91 and 93, can use one overlay file?
>>>
>>> Frank
>>
>> Can you suggest how to do so?
>>
>> There are imx93-pinfunc.h and imx91-pinfunc.h which are not unified
>> between imx91 and imx93.
>
> I suggest move pinmux setting to mainboard's dts files, which provide
> plug adaptor header, signal should be descripted in mainboard's dts file,
> which provide an unified label to overlay file.
Yeah, that would be one way of doing it.
However, the phycore dtsi and phyboard dts are kept simple by design
choice. This way, all optional pinctrls and peripherals are kept
separate from the board device-tree to maintain clutter low.
For v2 I would prefer to keep as is (current downstream implementation)
or at least use this approach:
imx91-93-phyboard-segin-peb-av-18.dtsi
|
-> imx91-phyboard-segin-peb-av-18.dtso
|
-> imx93-phyboard-segin-peb-av-18.dtso
BR,
Primoz
>
> Frank
>
>>
>> So we can only create common dtsi like so:
>>
>> imx91-93-phyboard-segin-peb-av-18.dtsi
>>
>> and still use separate dtsos:
>>
>> imx91-phyboard-segin-peb-av-18.dtso
>> imx93-phyboard-segin-peb-av-18.dtso
>>
>> Is that your idea?
>>
>> BR,
>>
>> Florijan Plohl
>>
>>>> --
>>>> 2.43.0
>>>>
> _______________________________________________
> upstream mailing list -- upstream@lists.phytec.de
> To unsubscribe send an email to upstream-leave@lists.phytec.de
--
Primoz Fiser
phone: +386-41-390-545
email: primoz.fiser@norik.com
--
Norik systems d.o.o.
Your embedded software partner
Slovenia, EU
phone: +386-41-540-545
email: info@norik.com
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: imx8mp-ab2: Correct interrupt flags
From: Daniel Baluta @ 2026-04-07 6:13 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Marek Vasut, Peng Fan, Fedor Ross, Shawn Guo,
Shengjiu Wang, Viorel Suman, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260406063810.25531-6-krzysztof.kozlowski@oss.qualcomm.com>
On 4/6/26 09:38, Krzysztof Kozlowski wrote:
> GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
> These are simple defines so they could be used in DTS but they will not
> have the same meaning:
> 1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
> 2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
>
> Correct the interrupt flags, assuming the author of the code wanted the
> same logical behavior behind the name "ACTIVE_xxx", this is:
> ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW
>
> Fixes: bf68c18150ef ("arm64: dts: imx8mp-ab2: add support for NXP i.MX8MP audio board (version 2)")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
^ permalink raw reply
* Re: [PATCH v16 6/7] coresight: ctcu: enable byte-cntr for TMC ETR devices
From: Jie Gan @ 2026-04-07 5:59 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Bjorn Andersson, Konrad Dybcio
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
devicetree
In-Reply-To: <20260323-enable-byte-cntr-for-ctcu-v16-6-7a413d211b8d@oss.qualcomm.com>
On 3/23/2026 5:49 PM, Jie Gan wrote:
> The byte-cntr function provided by the CTCU device is used to transfer data
> from the ETR buffer to the userspace. An interrupt is triggered if the data
> size exceeds the threshold set in the BYTECNTRVAL register. The interrupt
> handler counts the number of triggered interruptions and the read function
> will read the data from the synced ETR buffer.
>
> Switching the sysfs_buf when current buffer is full or the timeout is
> triggered and resets rrp and rwp registers after switched the buffer.
> The synced buffer will become available for reading after the switch.
>
> Byte-cntr workflow:
> start -> ctcu_enable(ctcu_byte_cntr_start) -> tmc_enable_etr_sink ->
> tmc_read_prepare_etr(jump to tmc_read_prepare_byte_cntr) ->
> tmc_etr_get_sysfs_trace(jump to tmc_byte_cntr_get_data) ->
> tmc_disable_etr_sink -> ctcu_disable(ctcu_byte_cntr_stop) ->
> tmc_read_unprepare_etr(jump to tmc_read_unprepare_byte_cntr) -> finish
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
> .../ABI/testing/sysfs-bus-coresight-devices-ctcu | 9 +
> drivers/hwtracing/coresight/Makefile | 2 +-
> .../hwtracing/coresight/coresight-ctcu-byte-cntr.c | 286 +++++++++++++++++++++
> drivers/hwtracing/coresight/coresight-ctcu-core.c | 104 +++++++-
> drivers/hwtracing/coresight/coresight-ctcu.h | 79 +++++-
> drivers/hwtracing/coresight/coresight-tmc-core.c | 3 +-
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 104 +++++++-
> drivers/hwtracing/coresight/coresight-tmc.h | 9 +
> 8 files changed, 571 insertions(+), 25 deletions(-)
>
[...]
> +
> +static int tmc_read_prepare_byte_cntr(struct tmc_drvdata *etr_drvdata)
> +{
> + struct coresight_device *ctcu = tmc_etr_get_ctcu_device(etr_drvdata);
> + struct ctcu_byte_cntr *byte_cntr_data;
> + int ret = 0;
> +
> + /* byte-cntr is operating with SYSFS mode being enabled only */
> + if (coresight_get_mode(etr_drvdata->csdev) != CS_MODE_SYSFS)
> + return -EINVAL;
> +
> + byte_cntr_data = ctcu_get_byte_cntr(ctcu, etr_drvdata->csdev);
> + if (!byte_cntr_data || !byte_cntr_data->irq_enabled)
> + return -EINVAL;
> +
> + if (byte_cntr_data->reading)
> + return -EBUSY;
> +
Found a potential race condition here.
I should set the byte_cntr_data->reading as earlier as possible, reset
it if we suffered an issue for creating buffer list to prevent to create
the etr_buf_list twice.
After the correction:
unsigned long flags;
raw_spin_lock_irqsave(&byte_cntr_data->spin_lock, flags);
if (byte_cntr_data->reading)
return -EBUSY;
byte_cntr_data->reading = true;
raw_spin_unlock_irqrestore(&byte_cntr_data->spin_lock, flags);
/* Setup an available etr_buf_list for byte-cntr */
ret = tmc_create_etr_buf_list(etr_drvdata, 2);
if (ret) {
byte_cntr_data->reading = false;
return ret;
}
guard(raw_spinlock_irqsave)(&byte_cntr_data->spin_lock);
...
Thanks,
Jie
> + /* Setup an available etr_buf_list for byte-cntr */
> + ret = tmc_create_etr_buf_list(etr_drvdata, 2);
> + if (ret)
> + return ret;
> +
> + guard(raw_spinlock_irqsave)(&byte_cntr_data->spin_lock);
> + atomic_set(&byte_cntr_data->irq_cnt, 0);
> + /*
> + * Configure the byte-cntr register to enable IRQ. The configured
> + * size is 5% of the buffer_size.
> + */
> + ctcu_cfg_byte_cntr_reg(byte_cntr_data->ctcu_drvdata,
> + etr_drvdata->size / MAX_IRQ_CNT,
> + byte_cntr_data->irq_ctrl_offset);
> + enable_irq_wake(byte_cntr_data->irq);
> + byte_cntr_data->buf_node = NULL;
> + byte_cntr_data->reading = true;
> +
> + return 0;
> +}
> +
> +static int tmc_read_unprepare_byte_cntr(struct tmc_drvdata *etr_drvdata)
> +{
> + struct coresight_device *ctcu = tmc_etr_get_ctcu_device(etr_drvdata);
> + struct ctcu_byte_cntr *byte_cntr_data;
> +
> + byte_cntr_data = ctcu_get_byte_cntr(ctcu, etr_drvdata->csdev);
> + if (!byte_cntr_data || !byte_cntr_data->irq_enabled)
> + return -EINVAL;
> +
> + tmc_clean_etr_buf_list(etr_drvdata);
> + guard(raw_spinlock_irqsave)(&byte_cntr_data->spin_lock);
> + /* Configure the byte-cntr register to disable IRQ */
> + ctcu_cfg_byte_cntr_reg(byte_cntr_data->ctcu_drvdata, 0,
> + byte_cntr_data->irq_ctrl_offset);
> + disable_irq_wake(byte_cntr_data->irq);
> + byte_cntr_data->buf_node = NULL;
> + byte_cntr_data->reading = false;
> +
> + return 0;
> +}
> +
> +const struct tmc_sysfs_ops byte_cntr_sysfs_ops = {
> + .read_prepare = tmc_read_prepare_byte_cntr,
> + .read_unprepare = tmc_read_unprepare_byte_cntr,
> + .get_trace_data = tmc_byte_cntr_get_data,
> +};
> +
> +/* Start the byte-cntr function when the path is enabled. */
> +void ctcu_byte_cntr_start(struct coresight_device *csdev, struct coresight_path *path)
> +{
> + struct coresight_device *sink = coresight_get_sink(path);
> + struct ctcu_byte_cntr *byte_cntr_data;
> +
> + byte_cntr_data = ctcu_get_byte_cntr(csdev, sink);
> + if (!byte_cntr_data)
> + return;
> +
> + /* Don't start byte-cntr function when irq_enabled is not set. */
> + if (!byte_cntr_data->irq_enabled || byte_cntr_data->enable)
> + return;
> +
> + guard(raw_spinlock_irqsave)(&byte_cntr_data->spin_lock);
> + byte_cntr_data->enable = true;
> +}
> +
> +/* Stop the byte-cntr function when the path is disabled. */
> +void ctcu_byte_cntr_stop(struct coresight_device *csdev, struct coresight_path *path)
> +{
> + struct coresight_device *sink = coresight_get_sink(path);
> + struct ctcu_byte_cntr *byte_cntr_data;
> +
> + if (coresight_get_mode(sink) == CS_MODE_SYSFS)
> + return;
> +
> + byte_cntr_data = ctcu_get_byte_cntr(csdev, sink);
> + if (!byte_cntr_data)
> + return;
> +
> + guard(raw_spinlock_irqsave)(&byte_cntr_data->spin_lock);
> + byte_cntr_data->enable = false;
> +}
> +
> +void ctcu_byte_cntr_init(struct device *dev, struct ctcu_drvdata *drvdata, int etr_num)
> +{
> + struct ctcu_byte_cntr *byte_cntr_data;
> + struct device_node *nd = dev->of_node;
> + int irq_num, ret, i;
> +
> + tmc_etr_set_byte_cntr_sysfs_ops(&byte_cntr_sysfs_ops);
> + for (i = 0; i < etr_num; i++) {
> + byte_cntr_data = &drvdata->byte_cntr_data[i];
> + irq_num = of_irq_get(nd, i);
> + if (irq_num < 0) {
> + dev_err(dev, "Failed to get IRQ from DT for port%d\n", i);
> + continue;
> + }
> +
> + ret = devm_request_irq(dev, irq_num, byte_cntr_handler,
> + IRQF_TRIGGER_RISING | IRQF_SHARED,
> + dev_name(dev), byte_cntr_data);
> + if (ret) {
> + dev_err(dev, "Failed to register IRQ for port%d\n", i);
> + continue;
> + }
> +
> + byte_cntr_data->irq = irq_num;
> + byte_cntr_data->ctcu_drvdata = drvdata;
> + init_waitqueue_head(&byte_cntr_data->wq);
> + raw_spin_lock_init(&byte_cntr_data->spin_lock);
> + }
> +}
> diff --git a/drivers/hwtracing/coresight/coresight-ctcu-core.c b/drivers/hwtracing/coresight/coresight-ctcu-core.c
> index e8720026c9e3..56590f22ad79 100644
> --- a/drivers/hwtracing/coresight/coresight-ctcu-core.c
> +++ b/drivers/hwtracing/coresight/coresight-ctcu-core.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> - * Copyright (c) 2024-2025 Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) 2024-2026 Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> */
>
> #include <linux/clk.h>
> @@ -18,6 +19,7 @@
>
> #include "coresight-ctcu.h"
> #include "coresight-priv.h"
> +#include "coresight-tmc.h"
>
> #define ctcu_writel(drvdata, val, offset) __raw_writel((val), drvdata->base + offset)
> #define ctcu_readl(drvdata, offset) __raw_readl(drvdata->base + offset)
> @@ -43,17 +45,21 @@
>
> #define CTCU_ATID_REG_BIT(traceid) (traceid % 32)
> #define CTCU_ATID_REG_SIZE 0x10
> +#define CTCU_ETR0_IRQCTRL 0x6c
> +#define CTCU_ETR1_IRQCTRL 0x70
> #define CTCU_ETR0_ATID0 0xf8
> #define CTCU_ETR1_ATID0 0x108
>
> static const struct ctcu_etr_config sa8775p_etr_cfgs[] = {
> {
> - .atid_offset = CTCU_ETR0_ATID0,
> - .port_num = 0,
> + .atid_offset = CTCU_ETR0_ATID0,
> + .irq_ctrl_offset = CTCU_ETR0_IRQCTRL,
> + .port_num = 0,
> },
> {
> - .atid_offset = CTCU_ETR1_ATID0,
> - .port_num = 1,
> + .atid_offset = CTCU_ETR1_ATID0,
> + .irq_ctrl_offset = CTCU_ETR1_IRQCTRL,
> + .port_num = 1,
> },
> };
>
> @@ -62,6 +68,85 @@ static const struct ctcu_config sa8775p_cfgs = {
> .num_etr_config = ARRAY_SIZE(sa8775p_etr_cfgs),
> };
>
> +void ctcu_program_register(struct ctcu_drvdata *drvdata, u32 val, u32 offset)
> +{
> + CS_UNLOCK(drvdata->base);
> + ctcu_writel(drvdata, val, offset);
> + CS_LOCK(drvdata->base);
> +}
> +
> +static ssize_t irq_enabled_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct ctcu_byte_cntr_irq_attribute *irq_attr =
> + container_of(attr, struct ctcu_byte_cntr_irq_attribute, attr);
> + struct ctcu_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + u8 port = irq_attr->port;
> +
> + if (!drvdata->byte_cntr_data[port].irq_ctrl_offset)
> + return -EINVAL;
> +
> + return sysfs_emit(buf, "%u\n",
> + (unsigned int)drvdata->byte_cntr_data[port].irq_enabled);
> +}
> +
> +static ssize_t irq_enabled_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t size)
> +{
> + struct ctcu_byte_cntr_irq_attribute *irq_attr =
> + container_of(attr, struct ctcu_byte_cntr_irq_attribute, attr);
> + struct ctcu_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + u8 port = irq_attr->port;
> + unsigned long val;
> +
> + if (kstrtoul(buf, 0, &val))
> + return -EINVAL;
> +
> + guard(raw_spinlock_irqsave)(&drvdata->spin_lock);
> + if (drvdata->byte_cntr_data[port].reading)
> + return -EBUSY;
> + else if (drvdata->byte_cntr_data[port].irq_ctrl_offset)
> + drvdata->byte_cntr_data[port].irq_enabled = !!val;
> +
> + return size;
> +}
> +
> +static umode_t irq_enabled_is_visible(struct kobject *kobj,
> + struct attribute *attr, int n)
> +{
> + struct device_attribute *dev_attr =
> + container_of(attr, struct device_attribute, attr);
> + struct ctcu_byte_cntr_irq_attribute *irq_attr =
> + container_of(dev_attr, struct ctcu_byte_cntr_irq_attribute, attr);
> + struct device *dev = kobj_to_dev(kobj);
> + struct ctcu_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + u8 port = irq_attr->port;
> +
> + if (drvdata && drvdata->byte_cntr_data[port].irq_ctrl_offset)
> + return attr->mode;
> +
> + return 0;
> +}
> +
> +static struct attribute *ctcu_attrs[] = {
> + ctcu_byte_cntr_irq_rw(0),
> + ctcu_byte_cntr_irq_rw(1),
> + NULL,
> +};
> +
> +static struct attribute_group ctcu_attr_grp = {
> + .attrs = ctcu_attrs,
> + .is_visible = irq_enabled_is_visible,
> +};
> +
> +static const struct attribute_group *ctcu_attr_grps[] = {
> + &ctcu_attr_grp,
> + NULL,
> +};
> +
> static void ctcu_program_atid_register(struct ctcu_drvdata *drvdata, u32 reg_offset,
> u8 bit, bool enable)
> {
> @@ -140,11 +225,15 @@ static int ctcu_set_etr_traceid(struct coresight_device *csdev, struct coresight
> static int ctcu_enable(struct coresight_device *csdev, enum cs_mode mode,
> struct coresight_path *path)
> {
> + ctcu_byte_cntr_start(csdev, path);
> +
> return ctcu_set_etr_traceid(csdev, path, true);
> }
>
> static int ctcu_disable(struct coresight_device *csdev, struct coresight_path *path)
> {
> + ctcu_byte_cntr_stop(csdev, path);
> +
> return ctcu_set_etr_traceid(csdev, path, false);
> }
>
> @@ -195,7 +284,10 @@ static int ctcu_probe(struct platform_device *pdev)
> for (i = 0; i < cfgs->num_etr_config; i++) {
> etr_cfg = &cfgs->etr_cfgs[i];
> drvdata->atid_offset[i] = etr_cfg->atid_offset;
> + drvdata->byte_cntr_data[i].irq_ctrl_offset =
> + etr_cfg->irq_ctrl_offset;
> }
> + ctcu_byte_cntr_init(dev, drvdata, cfgs->num_etr_config);
> }
> }
>
> @@ -209,6 +301,7 @@ static int ctcu_probe(struct platform_device *pdev)
> desc.dev = dev;
> desc.ops = &ctcu_ops;
> desc.access = CSDEV_ACCESS_IOMEM(base);
> + desc.groups = ctcu_attr_grps;
> raw_spin_lock_init(&drvdata->spin_lock);
>
> drvdata->csdev = coresight_register(&desc);
> @@ -248,6 +341,7 @@ static void ctcu_platform_remove(struct platform_device *pdev)
> if (WARN_ON(!drvdata))
> return;
>
> + tmc_etr_reset_byte_cntr_sysfs_ops();
> ctcu_remove(pdev);
> pm_runtime_disable(&pdev->dev);
> }
> diff --git a/drivers/hwtracing/coresight/coresight-ctcu.h b/drivers/hwtracing/coresight/coresight-ctcu.h
> index e9594c38dd91..a2ae0a0d91d0 100644
> --- a/drivers/hwtracing/coresight/coresight-ctcu.h
> +++ b/drivers/hwtracing/coresight/coresight-ctcu.h
> @@ -1,23 +1,31 @@
> /* SPDX-License-Identifier: GPL-2.0-only */
> /*
> - * Copyright (c) 2024-2025 Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) 2024-2026 Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> */
>
> #ifndef _CORESIGHT_CTCU_H
> #define _CORESIGHT_CTCU_H
> +
> +#include <linux/time.h>
> #include "coresight-trace-id.h"
>
> /* Maximum number of supported ETR devices for a single CTCU. */
> #define ETR_MAX_NUM 2
>
> +#define BYTE_CNTR_TIMEOUT (3 * HZ)
> +#define MAX_IRQ_CNT 20
> +
> /**
> * struct ctcu_etr_config
> * @atid_offset: offset to the ATID0 Register.
> - * @port_num: in-port number of CTCU device that connected to ETR.
> + * @port_num: in-port number of the CTCU device that connected to ETR.
> + * @irq_ctrl_offset: offset to the BYTECNTRVAL register.
> */
> struct ctcu_etr_config {
> const u32 atid_offset;
> const u32 port_num;
> + const u32 irq_ctrl_offset;
> };
>
> struct ctcu_config {
> @@ -25,15 +33,68 @@ struct ctcu_config {
> int num_etr_config;
> };
>
> -struct ctcu_drvdata {
> - void __iomem *base;
> - struct clk *apb_clk;
> - struct device *dev;
> - struct coresight_device *csdev;
> +/**
> + * struct ctcu_byte_cntr
> + * @enable: indicates that byte_cntr function is enabled or not.
> + * @irq_enabled: indicates that the interruption is enabled.
> + * @reading: indicates that byte_cntr is reading.
> + * @irq: allocated number of the IRQ.
> + * @irq_cnt: IRQ count number of the triggered interruptions.
> + * @wq: waitqueue for reading data from ETR buffer.
> + * @spin_lock: spinlock of the byte_cntr_data.
> + * @irq_ctrl_offset: offset to the BYTECNTVAL Register.
> + * @ctcu_drvdata: drvdata of the CTCU device.
> + * @buf_node: etr_buf_node for reading.
> + */
> +struct ctcu_byte_cntr {
> + bool enable;
> + bool irq_enabled;
> + bool reading;
> + int irq;
> + atomic_t irq_cnt;
> + wait_queue_head_t wq;
> raw_spinlock_t spin_lock;
> - u32 atid_offset[ETR_MAX_NUM];
> + u32 irq_ctrl_offset;
> + struct ctcu_drvdata *ctcu_drvdata;
> + struct etr_buf_node *buf_node;
> +};
> +
> +struct ctcu_drvdata {
> + void __iomem *base;
> + struct clk *apb_clk;
> + struct device *dev;
> + struct coresight_device *csdev;
> + struct ctcu_byte_cntr byte_cntr_data[ETR_MAX_NUM];
> + raw_spinlock_t spin_lock;
> + u32 atid_offset[ETR_MAX_NUM];
> /* refcnt for each traceid of each sink */
> - u8 traceid_refcnt[ETR_MAX_NUM][CORESIGHT_TRACE_ID_RES_TOP];
> + u8 traceid_refcnt[ETR_MAX_NUM][CORESIGHT_TRACE_ID_RES_TOP];
> };
>
> +/**
> + * struct ctcu_byte_cntr_irq_attribute
> + * @attr: The device attribute.
> + * @port: port number.
> + */
> +struct ctcu_byte_cntr_irq_attribute {
> + struct device_attribute attr;
> + u8 port;
> +};
> +
> +#define ctcu_byte_cntr_irq_rw(port) \
> + (&((struct ctcu_byte_cntr_irq_attribute[]) { \
> + { \
> + __ATTR(irq_enabled##port, 0644, irq_enabled_show, \
> + irq_enabled_store), \
> + port, \
> + } \
> + })[0].attr.attr)
> +
> +void ctcu_program_register(struct ctcu_drvdata *drvdata, u32 val, u32 offset);
> +
> +/* Byte-cntr functions */
> +void ctcu_byte_cntr_start(struct coresight_device *csdev, struct coresight_path *path);
> +void ctcu_byte_cntr_stop(struct coresight_device *csdev, struct coresight_path *path);
> +void ctcu_byte_cntr_init(struct device *dev, struct ctcu_drvdata *drvdata, int port_num);
> +
> #endif
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
> index 110eedde077f..9f4fd86e8c32 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-core.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
> @@ -293,7 +293,8 @@ static ssize_t tmc_read(struct file *file, char __user *data, size_t len,
> return -EFAULT;
> }
>
> - *ppos += actual;
> + if (!tmc_etr_update_buf_node_pos(drvdata, actual))
> + *ppos += actual;
> dev_dbg(&drvdata->csdev->dev, "%zu bytes copied\n", actual);
>
> return actual;
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index d4a99c77dd90..3253964d1ce7 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -1168,6 +1168,8 @@ static int tmc_etr_enable_hw(struct tmc_drvdata *drvdata,
> return rc;
> }
>
> +static const struct tmc_sysfs_ops *byte_cntr_sysfs_ops;
> +
> /*
> * Return the available trace data in the buffer (starts at etr_buf->offset,
> * limited by etr_buf->len) from @pos, with a maximum limit of @len,
> @@ -1178,23 +1180,39 @@ static int tmc_etr_enable_hw(struct tmc_drvdata *drvdata,
> * We are protected here by drvdata->reading != 0, which ensures the
> * sysfs_buf stays alive.
> */
> -ssize_t tmc_etr_get_sysfs_trace(struct tmc_drvdata *drvdata,
> - loff_t pos, size_t len, char **bufpp)
> +ssize_t tmc_etr_read_sysfs_buf(struct etr_buf *sysfs_buf, loff_t pos,
> + size_t len, char **bufpp)
> {
> s64 offset;
> ssize_t actual = len;
> - struct etr_buf *etr_buf = drvdata->sysfs_buf;
>
> - if (pos + actual > etr_buf->len)
> - actual = etr_buf->len - pos;
> + if (pos + actual > sysfs_buf->len)
> + actual = sysfs_buf->len - pos;
> if (actual <= 0)
> return actual;
>
> /* Compute the offset from which we read the data */
> - offset = etr_buf->offset + pos;
> - if (offset >= etr_buf->size)
> - offset -= etr_buf->size;
> - return tmc_etr_buf_get_data(etr_buf, offset, actual, bufpp);
> + offset = sysfs_buf->offset + pos;
> + if (offset >= sysfs_buf->size)
> + offset -= sysfs_buf->size;
> + return tmc_etr_buf_get_data(sysfs_buf, offset, actual, bufpp);
> +}
> +EXPORT_SYMBOL_GPL(tmc_etr_read_sysfs_buf);
> +
> +ssize_t tmc_etr_get_sysfs_trace(struct tmc_drvdata *drvdata,
> + loff_t pos, size_t len, char **bufpp)
> +{
> + ssize_t ret;
> +
> + if (byte_cntr_sysfs_ops) {
> + ret = byte_cntr_sysfs_ops->get_trace_data(drvdata, pos,
> + len, bufpp);
> + /* Return the filled buffer */
> + if (ret > 0 || ret == -ENOMEM)
> + return ret;
> + }
> +
> + return tmc_etr_read_sysfs_buf(drvdata->sysfs_buf, pos, len, bufpp);
> }
>
> static struct etr_buf *
> @@ -1248,6 +1266,33 @@ static void __tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
>
> }
>
> +static void tmc_etr_reset_sysfs_buf(struct tmc_drvdata *drvdata)
> +{
> + u32 sts;
> +
> + CS_UNLOCK(drvdata->base);
> + tmc_write_rrp(drvdata, drvdata->sysfs_buf->hwaddr);
> + tmc_write_rwp(drvdata, drvdata->sysfs_buf->hwaddr);
> + sts = readl_relaxed(drvdata->base + TMC_STS) & ~TMC_STS_FULL;
> + writel_relaxed(sts, drvdata->base + TMC_STS);
> + CS_LOCK(drvdata->base);
> +}
> +
> +/**
> + * tmc_etr_enable_disable_hw - enable/disable the ETR hw.
> + * @drvdata: drvdata of the TMC device.
> + * @enable: indicates enable/disable.
> + */
> +void tmc_etr_enable_disable_hw(struct tmc_drvdata *drvdata, bool enable)
> +{
> + if (enable) {
> + tmc_etr_reset_sysfs_buf(drvdata);
> + __tmc_etr_enable_hw(drvdata);
> + } else
> + __tmc_etr_disable_hw(drvdata);
> +}
> +EXPORT_SYMBOL_GPL(tmc_etr_enable_disable_hw);
> +
> void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
> {
> __tmc_etr_disable_hw(drvdata);
> @@ -2040,6 +2085,35 @@ int tmc_create_etr_buf_list(struct tmc_drvdata *drvdata, int num_nodes)
> }
> EXPORT_SYMBOL_GPL(tmc_create_etr_buf_list);
>
> +void tmc_etr_set_byte_cntr_sysfs_ops(const struct tmc_sysfs_ops *sysfs_ops)
> +{
> + byte_cntr_sysfs_ops = sysfs_ops;
> +}
> +EXPORT_SYMBOL_GPL(tmc_etr_set_byte_cntr_sysfs_ops);
> +
> +void tmc_etr_reset_byte_cntr_sysfs_ops(void)
> +{
> + byte_cntr_sysfs_ops = NULL;
> +}
> +EXPORT_SYMBOL_GPL(tmc_etr_reset_byte_cntr_sysfs_ops);
> +
> +bool tmc_etr_update_buf_node_pos(struct tmc_drvdata *drvdata, ssize_t size)
> +{
> + struct etr_buf_node *nd, *next;
> +
> + if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
> + return false;
> +
> + list_for_each_entry_safe(nd, next, &drvdata->etr_buf_list, link) {
> + if (nd && nd->reading) {
> + nd->pos += size;
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
> {
> int ret = 0;
> @@ -2049,6 +2123,14 @@ int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
> if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETR))
> return -EINVAL;
>
> + if (byte_cntr_sysfs_ops) {
> + ret = byte_cntr_sysfs_ops->read_prepare(drvdata);
> + if (!ret || ret == -EBUSY)
> + return ret;
> +
> + ret = 0;
> + }
> +
> raw_spin_lock_irqsave(&drvdata->spinlock, flags);
> if (drvdata->reading) {
> ret = -EBUSY;
> @@ -2085,6 +2167,10 @@ int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata)
> if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETR))
> return -EINVAL;
>
> + if (byte_cntr_sysfs_ops)
> + if (!byte_cntr_sysfs_ops->read_unprepare(drvdata))
> + return 0;
> +
> raw_spin_lock_irqsave(&drvdata->spinlock, flags);
>
> /* RE-enable the TMC if need be */
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
> index fbb015079872..a15e2f93f16a 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.h
> +++ b/drivers/hwtracing/coresight/coresight-tmc.h
> @@ -211,12 +211,15 @@ struct tmc_resrv_buf {
> /**
> * @sysfs_buf: Allocated sysfs_buf.
> * @is_free: Indicates whether the buffer is free to choose.
> + * @reading: Indicates byte_cntr is reading the buffer attached to
> + * the node.
> * @pos: Offset to the start of the buffer.
> * @link: list_head of the node.
> */
> struct etr_buf_node {
> struct etr_buf *sysfs_buf;
> bool is_free;
> + bool reading;
> loff_t pos;
> struct list_head link;
> };
> @@ -480,5 +483,11 @@ struct etr_buf *tmc_etr_get_buffer(struct coresight_device *csdev,
> extern const struct attribute_group coresight_etr_group;
> void tmc_clean_etr_buf_list(struct tmc_drvdata *drvdata);
> int tmc_create_etr_buf_list(struct tmc_drvdata *drvdata, int num_nodes);
> +void tmc_etr_set_byte_cntr_sysfs_ops(const struct tmc_sysfs_ops *sysfs_ops);
> +void tmc_etr_reset_byte_cntr_sysfs_ops(void);
> +void tmc_etr_enable_disable_hw(struct tmc_drvdata *drvdata, bool enable);
> +bool tmc_etr_update_buf_node_pos(struct tmc_drvdata *drvdata, ssize_t size);
> +ssize_t tmc_etr_read_sysfs_buf(struct etr_buf *sysfs_buf, loff_t pos,
> + size_t len, char **bufpp);
>
> #endif
>
^ permalink raw reply
* Re: [PATCH v20 2/6] pwm: driver for qualcomm ipq6018 pwm block
From: George Moussalem @ 2026-04-07 5:58 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Baruch Siach,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, linux-pwm,
devicetree, linux-kernel, Devi Priya, Baruch Siach
In-Reply-To: <adF9VdZYEGQfRqyl@monoceros>
On 4/4/2026 11:09 PM, Uwe Kleine-König wrote:
> Hello George,
>
> On Fri, Apr 03, 2026 at 12:40:32PM +0200, George Moussalem wrote:
>> On 4/2/2026 5:35 PM, Uwe Kleine-König wrote:
>>> diff --git a/drivers/pwm/pwm-ipq.c b/drivers/pwm/pwm-ipq.c
>>> index b944ecb456d5..4818d0170d53 100644
>>> --- a/drivers/pwm/pwm-ipq.c
>>> +++ b/drivers/pwm/pwm-ipq.c
>>> @@ -97,9 +97,10 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>>> if (state->polarity != PWM_POLARITY_NORMAL)
>>> return -EINVAL;
>>>
>>> - if (!ipq_chip->clk_rate)
>>> - return -EINVAL;
>>> -
>>> + /*
>>> + * XXX Why? A comment please. (Is this already covered by the checks
>>> + * below?)
>>> + */
>>
>> This check can be safely removed as it is indeed covered by the check
>> where the period_ns is limited to IPQ_PWM_MAX_PERIOD_NS which equals to
>> NSEC_PER_SEC as per macro definition above.
>>
>>> if (state->period < DIV64_U64_ROUND_UP(NSEC_PER_SEC,
>>> ipq_chip->clk_rate))
>>> return -ERANGE;
>>> @@ -107,18 +108,29 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>>> period_ns = min(state->period, IPQ_PWM_MAX_PERIOD_NS);
>>> duty_ns = min(state->duty_cycle, period_ns);
>>>
>>> + /*
>>> + * Pick the maximal value for PWM_DIV that still allows a
>>> + * 100% relative duty cycle. This allows a fine grained
>>> + * selection of duty cycles.
>>> + */
>>> pwm_div = IPQ_PWM_MAX_DIV - 1;
>>> +
>>> + /*
>>> + * XXX mul_u64_u64_div_u64 returns an u64, this might overflow the
>>> + * unsigned int pre_div.
>>> + */
>>
>> Theoretically, yes, but in practice it won't due to above constraints.
>> Take the max period of 10^9 (NSEC_PER_SEC) * max clock rate of 10^9 (1
>> GHz), then the numerator becomes 10^18. Divide that by 10^9
>> (NSEC_PER_SEC) * 65,535 (IPQ_PWM_MAX_DIV) and that fits well into a
>> 32-bit integer.
>
> OK, please put that in a comment.
>
>> Do you want me to send a v21 or can you apply the diff in your tree with
>> above deletion and comment?
>
> Yes, please send a v21.
Just to circle back, I've sent v21. Can you please review and get it
merged if there are no further comments?
>
> Best regards
> Uwe
Thanks,
George
^ permalink raw reply
* [PATCH v3 2/2] riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
From: Sandie Cao @ 2026-04-07 5:57 UTC (permalink / raw)
To: Yixun Lan, Troy Mitchell
Cc: Conor Dooley, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Heinrich Schuchardt, Michael Opdenacker, Guodong Xu,
Hendrik Hamerlinck, Yangyu Chen, spacemit, linux-riscv,
devicetree, linux-kernel, Sandie Cao
In-Reply-To: <20260407055557.1202713-1-sandie.cao@deepcomputing.io>
The FML13V05 board from DeepComputing incorporates a SpacemiT K3 RISC-V
SoC.It is a mainboard designed for the Framework Laptop 13 Chassis,
which has (Framework) SKU FRANHQ0001.
The FML13V05 board features:
- SpacemiT K3 RISC-V SoC
- LPDDR5 16GB or 32GB
- eMMC 32GB ~128GB (Optional)
- UFS 3.1 256G (Optional)
- QSPI Flash
- MicroSD Slot
- PCIe-based Wi-Fi
- 4 USB-C Ports
- Port 1: PD 3.0 (65W Max), USB 3.2 Gen 1
- Port 2: PD 3.0 (65W Max), USB 3.2 Gen 1, DP 1.4 (4K@60Hz)
- Port 3 & 4: USB 3.2 Gen 1
This minimal device tree enables booting into a serial console with UART
output.
Signed-off-by: Sandie Cao <sandie.cao@deepcomputing.io>
---
arch/riscv/boot/dts/spacemit/Makefile | 1 +
.../spacemit/k3-deepcomputing-fml13v05.dts | 31 +++++++++++++++++++
2 files changed, 32 insertions(+)
create mode 100644 arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
index 7e2b87702571..acb993c452ba 100644
--- a/arch/riscv/boot/dts/spacemit/Makefile
+++ b/arch/riscv/boot/dts/spacemit/Makefile
@@ -4,4 +4,5 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
+dtb-$(CONFIG_ARCH_SPACEMIT) += k3-deepcomputing-fml13v05.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
diff --git a/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts b/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
new file mode 100644
index 000000000000..783066fc7ad7
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2024 DeepComputing (HK) Limited
+ */
+
+#include "k3.dtsi"
+#include "k3-pinctrl.dtsi"
+
+/ {
+ model = "DeepComputing FML13V05";
+ compatible = "deepcomputing,fml13v05", "spacemit,k3";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0";
+ };
+
+ memory@100000000 {
+ device_type = "memory";
+ reg = <0x1 0x00000000 0x4 0x00000000>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_0_cfg>;
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
From: Sandie Cao @ 2026-04-07 5:57 UTC (permalink / raw)
To: Yixun Lan, Troy Mitchell
Cc: Conor Dooley, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Heinrich Schuchardt, Michael Opdenacker, Guodong Xu,
Hendrik Hamerlinck, Yangyu Chen, spacemit, linux-riscv,
devicetree, linux-kernel, Sandie Cao
In-Reply-To: <20260407055557.1202713-1-sandie.cao@deepcomputing.io>
Document the compatible string for the Deepcomputing fml13v05.
It's based on the SpacemiT K3 RISC-V SoC and is designed for the Framework
Laptop 13 Chassis, which has (Framework) SKU FRANHQ0001.
Signed-off-by: Sandie Cao <sandie.cao@deepcomputing.io>
---
Documentation/devicetree/bindings/riscv/spacemit.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/riscv/spacemit.yaml b/Documentation/devicetree/bindings/riscv/spacemit.yaml
index b958b94a924d..af8030242bdc 100644
--- a/Documentation/devicetree/bindings/riscv/spacemit.yaml
+++ b/Documentation/devicetree/bindings/riscv/spacemit.yaml
@@ -29,6 +29,7 @@ properties:
- const: spacemit,k1
- items:
- enum:
+ - deepcomputing,fml13v05
- spacemit,k3-pico-itx
- const: spacemit,k3
--
2.43.0
^ permalink raw reply related
* [PATCH v3 0/2] Add DeepComputing FML13V05 board dts
From: Sandie Cao @ 2026-04-07 5:55 UTC (permalink / raw)
To: Yixun Lan, Troy Mitchell
Cc: Conor Dooley, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Heinrich Schuchardt, Michael Opdenacker, Guodong Xu,
Hendrik Hamerlinck, Yangyu Chen, spacemit, linux-riscv,
devicetree, linux-kernel, Sandie Cao
This series updates Device Tree related files to introduce the
FML13V05 board from DeepComputing, which incorporates a Spacemit
K3 SoC. This board is designed for use on the Framework Laptop 13
Chassis, which has (Framework) SKU FRANHQ0001.
The series is rebased on k1/dt-for-next.
v3:
rebased on k1/dt-for-next.
- Patch 1:
Use formal format user name.
Remove Reviewed-by Heinrich Schuchardt from internal sysstem.
- Patch 2:
Use formal format user name.
Remove Reviewed-by Heinrich Schuchardt from internal sysstem.
Add uart0 pinctrl.
v2 (deprecated):
Link to v2: https://lore.kernel.org/all/20260331071110.68321-1-sandie.cao@deepcomputing.io/
v1:
Link to v1: https://lore.kernel.org/all/20260331034423.67142-1-sandie.cao@deepcomputing.io/
Sandie Cao (2):
dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
.../devicetree/bindings/riscv/spacemit.yaml | 1 +
arch/riscv/boot/dts/spacemit/Makefile | 1 +
.../spacemit/k3-deepcomputing-fml13v05.dts | 31 +++++++++++++++++++
3 files changed, 33 insertions(+)
create mode 100644 arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
base-commit: af62a095eb0c3359d477b55ef72d2afd94c83c8f
--
2.43.0
^ permalink raw reply
* Re: [PATCH v3 1/2] ti,j721e-system-controller.yaml: Allow audio-refclk as clock-controller child
From: Krzysztof Kozlowski @ 2026-04-07 5:53 UTC (permalink / raw)
To: Moteen Shah
Cc: krzk+dt, robh, conor+dt, nm, vigneshr, kristo, devicetree,
linux-arm-kernel, linux-kernel, u-kumar1, gehariprasath,
y-abhilashchandra
In-Reply-To: <62dd6a7f-7a5b-4939-a18d-8b763f6e8f9b@ti.com>
On 07/04/2026 07:46, Moteen Shah wrote:
> Hey Krzysztof,
>
> On 31/03/26 12:39, Krzysztof Kozlowski wrote:
>> On Mon, Mar 30, 2026 at 03:14:58PM +0530, Moteen Shah wrote:
>>> The ti,j721e-system-controller binding currently only allows
>>> clock-controller@ child nodes to reference the ti,am654-ehrpwm-tbclk
>>> schema. However, the system controller on J721S2 also contains audio
>> J721S2 or AM62?
>>
>>> reference clock controllers (ti,am62-audio-refclk) that use the same
>>> clock-controller@XXXX naming pattern.
>>>
>>> Hence, extend the clock-controller pattern to accept either ehrpwm-tbclk
>>> or audio-refclk schemas using a oneOf constraint.
>>>
>>> Signed-off-by: Moteen Shah <m-shah@ti.com>
>>> ---
>>> .../bindings/soc/ti/ti,j721e-system-controller.yaml | 6 ++++--
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
>>> index f3bd0be3b279..d5d84a8f1257 100644
>>> --- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
>>> +++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
>>> @@ -53,9 +53,11 @@ patternProperties:
>>>
>>> "^clock-controller@[0-9a-f]+$":
>>> type: object
>>> - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
>>> + oneOf:
>>> + - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
>>> + - $ref: /schemas/clock/ti,am62-audio-refclk.yaml#
>> Alphanumerical order.
>>
>> There is no ti,am62 in the top level compatibles, so why am62 is here?
>> Top level has j721s2 but this ti,am62-audio-refclk.yaml only am62.
>>
>> Best regards,
>> Krzysztof
>
> The "ti,am62-audio-refclk" compatible refers to a shared audio reference
> clock IP block that was first introduced/named on AM62 but is present on
> other TI K3 SoCs as well, including J721S2. The compatible string
> identifies the IP block, not the SoC family.
>
> This is already an established pattern —
> k3-j784s4-j742s2-main-common.dtsi uses the same compatible for the
> J784S4/J742S2 audio refclk node.
Please read carefully writing-bindings doc.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] ti,j721e-system-controller.yaml: Allow audio-refclk as clock-controller child
From: Moteen Shah @ 2026-04-07 5:46 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: krzk+dt, robh, conor+dt, nm, vigneshr, kristo, devicetree,
linux-arm-kernel, linux-kernel, u-kumar1, gehariprasath,
y-abhilashchandra
In-Reply-To: <20260331-flashy-hilarious-whale-6e606c@quoll>
Hey Krzysztof,
On 31/03/26 12:39, Krzysztof Kozlowski wrote:
> On Mon, Mar 30, 2026 at 03:14:58PM +0530, Moteen Shah wrote:
>> The ti,j721e-system-controller binding currently only allows
>> clock-controller@ child nodes to reference the ti,am654-ehrpwm-tbclk
>> schema. However, the system controller on J721S2 also contains audio
> J721S2 or AM62?
>
>> reference clock controllers (ti,am62-audio-refclk) that use the same
>> clock-controller@XXXX naming pattern.
>>
>> Hence, extend the clock-controller pattern to accept either ehrpwm-tbclk
>> or audio-refclk schemas using a oneOf constraint.
>>
>> Signed-off-by: Moteen Shah <m-shah@ti.com>
>> ---
>> .../bindings/soc/ti/ti,j721e-system-controller.yaml | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
>> index f3bd0be3b279..d5d84a8f1257 100644
>> --- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
>> +++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
>> @@ -53,9 +53,11 @@ patternProperties:
>>
>> "^clock-controller@[0-9a-f]+$":
>> type: object
>> - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
>> + oneOf:
>> + - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
>> + - $ref: /schemas/clock/ti,am62-audio-refclk.yaml#
> Alphanumerical order.
>
> There is no ti,am62 in the top level compatibles, so why am62 is here?
> Top level has j721s2 but this ti,am62-audio-refclk.yaml only am62.
>
> Best regards,
> Krzysztof
The "ti,am62-audio-refclk" compatible refers to a shared audio reference
clock IP block that was first introduced/named on AM62 but is present on
other TI K3 SoCs as well, including J721S2. The compatible string
identifies the IP block, not the SoC family.
This is already an established pattern —
k3-j784s4-j742s2-main-common.dtsi uses the same compatible for the
J784S4/J742S2 audio refclk node.
The ti,j721e-system-controller.yaml binding (which covers
ti,j721s2-system-controller) already lists ti,am62-audio-refclk as an
allowed clock-controller child, which was updated in patch 1/2 of this
series to make room for this node.
Best regards,
Moteen Shah
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox