* 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 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 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 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 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
* [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
* [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 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 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
* 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
* 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 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 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 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 V10 03/13] PCI: dwc: Parse Root Port nodes in dw_pcie_host_init()
From: Manivannan Sadhasivam @ 2026-04-07 6:52 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: <VI0PR04MB121147E4D3F9FDC95391C1153925AA@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Tue, Apr 07, 2026 at 03:21:30AM +0000, Sherry Sun wrote:
> > On Thu, Apr 02, 2026 at 05:50:57PM +0800, Sherry Sun wrote:
> > > Add support for parsing Root Port child nodes in dw_pcie_host_init()
> > > using pci_host_common_parse_ports(). This allows DWC-based drivers to
> > > specify Root Port properties (like reset GPIOs) in individual Root
> > > Port nodes rather than in the host bridge node.
> > >
> > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++++++
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > index da152c31bb2e..f6fca984fb34 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > @@ -20,6 +20,7 @@
> > > #include <linux/platform_device.h>
> > >
> > > #include "../../pci.h"
> > > +#include "../pci-host-common.h"
> > > #include "pcie-designware.h"
> > >
> > > static struct pci_ops dw_pcie_ops;
> > > @@ -581,6 +582,13 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
> > >
> > > pp->bridge = bridge;
> > >
> > > + /* Parse Root Port nodes if present */
> > > + ret = pci_host_common_parse_ports(dev, bridge);
> > > + if (ret && ret != -ENOENT) {
> > > + dev_err(dev, "Failed to parse Root Port nodes: %d\n", ret);
> > > + return ret;
> >
> > Won't this change break drivers that parse Root Ports on their own? Either
> > you need to modify them also in this change or call this API from imx6 driver
> > and let other drivers switch to it in a phased manner.
> >
> > I perfer the latter.
>
> Hi Mani, sorry I didn't fully get your point here, there are no changes to this part
> V10, for drivers that parse Root Ports on their own, here pci_host_common_parse_ports()
> will return -ENOENT, so nothing break as we discussed this in V8
> https://lore.kernel.org/all/dcl3bdljrdzgeaybrg3dc5uaxkebkjns7pajix6mxxftao5g4m@vm3ywyyp4ujh/.
>
So if this API gets called first, it will acquire PERST# from the Root Port node
and if the controller drivers try to do the same in their own parsing code,
PERST# request will return -EBUSY and the probe will fail.
On the other hand, if the controller drivers parse PERST# first, this API will
return -EBUSY and will result in probe failure.
Only way to fix this issue would be to call this API from imx6 driver for now
and start migrating other drivers later.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v1 02/13] dt-bindings: clock: Add system-0 domain PLL clock
From: Changhuang Liang @ 2026-04-07 6:56 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-godlike-pistachio-mackerel-7ab494@quoll>
Hi, Krzysztof
Thanks for the review.
> On Thu, Apr 02, 2026 at 10:49:34PM -0700, Changhuang Liang wrote:
> > Add system-0 domain PLL clock for StarFive JHB100 SoC.
> >
> > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> > ---
> > .../bindings/clock/starfive,jhb100-pll.yaml | 44 +++++++++++++++++++
> > .../dt-bindings/clock/starfive,jhb100-crg.h | 6 +++
>
> You did not test your code. Apply patch #1 and test it. Do you see build-level
> errors?
I'm very sorry about this. I will reorganize my patch to avoid the related errors.
Best Regards,
Changhuang
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: leds: Document LTC3208 Multidisplay LED Driver
From: Krzysztof Kozlowski @ 2026-04-07 6:58 UTC (permalink / raw)
To: Jan Carlo Roleda
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-kernel, linux-leds, devicetree
In-Reply-To: <20260406-upstream-ltc3208-v3-2-7f0b1d20ee7a@analog.com>
On Mon, Apr 06, 2026 at 03:17:06PM +0800, Jan Carlo Roleda wrote:
> Add Documentation for LTC3208 Multidisplay LED Driver.
>
> Signed-off-by: Jan Carlo Roleda <jancarlo.roleda@analog.com>
> ---
Still incorrect order.
...
> +
> + led-controller@1b {
> + compatible = "adi,ltc3208";
> + reg = <0x1b>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + adi,disable-camhl-pin;
> + adi,cfg-enrgbs-pin;
> + adi,disable-rgb-aux4-dropout;
> +
> + led@0 {
> + reg = <0>;
I still expect this to be complete, so at least function and color.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: hwmon/pmbus: Add Infineon XDP720
From: Krzysztof Kozlowski @ 2026-04-07 7:00 UTC (permalink / raw)
To: ASHISH YADAV
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <20260406101647.109667-2-Ashish.Yadav@infineon.com>
On Mon, Apr 06, 2026 at 03:46:46PM +0530, ASHISH YADAV wrote:
> From: Ashish Yadav <ashish.yadav@infineon.com>
>
> Add documentation for the device tree binding of the XDP720 eFuse.
> This patch introduces a YAML schema describing the required and optional
Redundant parts was supposed to go to /dev/null.
You already said this in the first sentence.
Also, there is no such thing as YAML schema.
> properties for the XDP720 eFuse device node. It includes details on the
> compatible string, register mapping,supply and rimon-micro-ohms(RIMON).
So nothing here is useful - nothing explains the hardware, so drop all
this and keep only first sentence. Or say something useful about
hardware.
>
> Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
> ---
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 3/3] riscv: dts: spacemit: Enable USB3.0/PCIe on OrangePi RV2
From: Chukun Pan @ 2026-04-07 7:00 UTC (permalink / raw)
To: gaohan
Cc: alex, amadeus, aou, conor+dt, devicetree, dlan, krzk+dt, legoll,
linux-kernel, linux-riscv, palmer, pjw, rabenda.cn, robh,
spacemit
In-Reply-To: <dba1428ac649dbc6d3fe4c58f0c6d24bb7432b9f.1775417019.git.gaohan@iscas.ac.cn>
Hi,
> + pcie_vcc3v3: regulator-pcie-vcc3v3 {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio K1_GPIO(116) GPIO_ACTIVE_HIGH>;
> + regulator-name = "pcie_vcc3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
Please add: `vin-supply = <&vcc_5v0>;`
> + vcc5v0_usb30: regulator-vcc5v0-usb30 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_usb30";
> + enable-active-high;
> + gpios = <&gpio K1_GPIO(123) GPIO_ACTIVE_HIGH>;
Could you place `regulator-name` under `gpios`?
vcc5v0_usb30: regulator-vcc5v0-usb30 {
compatible = "regulator-fixed";
enable-active-high;
gpios = <&gpio K1_GPIO(123) GPIO_ACTIVE_HIGH>;
regulator-name = "vcc5v0_usb30";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
vin-supply = <&vcc_5v0>;
};
> +&pcie1 {
> + vpcie3v3-supply = <&pcie_vcc3v3>;
Redundant vpcie3v3-supply.
> + status = "okay";
> };
Thanks,
Chukun
^ permalink raw reply
* Re: [PATCH v1 02/13] dt-bindings: clock: Add system-0 domain PLL clock
From: Krzysztof Kozlowski @ 2026-04-07 7:02 UTC (permalink / raw)
To: Changhuang Liang
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: <ZQ4PR01MB120275BC5277C4FF18A738E6F25A2@ZQ4PR01MB1202.CHNPR01.prod.partner.outlook.cn>
On 07/04/2026 08:56, Changhuang Liang wrote:
> Hi, Krzysztof
>
> Thanks for the review.
>
>> On Thu, Apr 02, 2026 at 10:49:34PM -0700, Changhuang Liang wrote:
>>> Add system-0 domain PLL clock for StarFive JHB100 SoC.
>>>
>>> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
>>> ---
>>> .../bindings/clock/starfive,jhb100-pll.yaml | 44 +++++++++++++++++++
>>> .../dt-bindings/clock/starfive,jhb100-crg.h | 6 +++
>>
>> You did not test your code. Apply patch #1 and test it. Do you see build-level
>> errors?
>
> I'm very sorry about this. I will reorganize my patch to avoid the related errors.
>
Anyway this one should be folded into the parent. You have one generic,
system-wide clock as input, so as well this can be the resource of the
parent. And no address spaces.
Other examples have one-register address spaces, so these are not really
separate devices.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 0/4] SDM670 LPASS LPI pin controller support
From: Linus Walleij @ 2026-04-07 7:02 UTC (permalink / raw)
To: Richard Acayan
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm, linux-gpio,
devicetree
In-Reply-To: <20260331200658.1306-1-mailingradian@gmail.com>
On Tue, Mar 31, 2026 at 10:06 PM Richard Acayan <mailingradian@gmail.com> wrote:
> Richard Acayan (4):
> dt-bindings: qcom: lpass-lpi-common: add reserved GPIOs property
> dt-bindings: pinctrl: qcom: Add SDM670 LPASS LPI pinctrl
> pinctrl: qcom: add sdm670 lpi tlmm
These three patches applied to the pinctrl tree for v7.1
> arm64: dts: qcom: sdm670: add lpi pinctrl
Please funnel this patch through the SoC tree!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 4/4] arm64: dts: qcom: sdm670: add lpi pinctrl
From: Linus Walleij @ 2026-04-07 7:03 UTC (permalink / raw)
To: Richard Acayan
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm, linux-gpio,
devicetree
In-Reply-To: <20260331200658.1306-5-mailingradian@gmail.com>
On Tue, Mar 31, 2026 at 10:06 PM Richard Acayan <mailingradian@gmail.com> wrote:
> The Snapdragon 670 has a separate TLMM for audio pins. Add the device
> node for it.
>
> Also add reserved GPIOs for the Pixel 3a, which blocks access to the
> sensor GPIOs.
>
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Acked-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: Document Xiaomi Poco F1 Tianma variant
From: Krzysztof Kozlowski @ 2026-04-07 7:04 UTC (permalink / raw)
To: David Heidelberg
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Marijn Suijten, Casey Connolly, Joel Selvaraj,
Jens Reidel, Arnaud Ferraris, Marco Mattiolo, Petr Hodina,
linux-arm-msm, devicetree, linux-kernel, phone-devel
In-Reply-To: <20260405-beryllium-compat-string-v2-1-91149be07835@ixit.cz>
On Sun, Apr 05, 2026 at 12:54:55PM +0200, David Heidelberg wrote:
> Document the panel-specific compatible string for the Tianma variant
> of the Xiaomi Poco F1:
>
> - "xiaomi,beryllium-tianma"
>
> and require the generic fallback compatible:
>
> - "xiaomi,beryllium"
>
> Update the binding to clarify that all panel variants must list the
> variant-specific compatible first, followed by the generic device
> compatible, in accordance with DT matching rules.
>
> The previous binding documentation did not describe the Tianma variant
> and did not clearly specify the required fallback compatible, which
> resulted in inconsistent DTS implementations.
>
> No functional differences are currently exposed between Tianma and EBBG
> variants at the binding level; both rely on the same generic device
> compatibility for software support.
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 11/13] dt-bindings: hwinfo: Add starfive,jhb100-socinfo
From: Krzysztof Kozlowski @ 2026-04-07 7:06 UTC (permalink / raw)
To: Changhuang Liang
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: <ZQ4PR01MB12021DE82F5D893BBA15A659F25A2@ZQ4PR01MB1202.CHNPR01.prod.partner.outlook.cn>
On 07/04/2026 08:49, Changhuang Liang wrote:
> 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
Sure, how is that DTS and platform?
Why did you chosen exactly this one, known of poor quality and multiple
warnings, but did not choose something which is reviewed in detail and
passes all expectations?
> or could you provide me with alternative suggestions? Thank you very much.
Fold into the parent. See also writing bindings or DTS101 talk.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/3] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Linus Walleij @ 2026-04-07 7:27 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: brgl, robh, krzk+dt, conor+dt, afaerber, tychang, linux-gpio,
devicetree, linux-kernel, linux-arm-kernel, linux-realtek-soc,
cy.huang, stanley_chang, james.tai
In-Reply-To: <20260331113835.3510341-4-eleanor.lin@realtek.com>
On Tue, Mar 31, 2026 at 1:38 PM Yu-Chun Lin <eleanor.lin@realtek.com> wrote:
> From: Tzuyi Chang <tychang@realtek.com>
>
> Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
>
> Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
> which manages pins via shared bank registers, the RTD1625 introduces
> a per-pin register architecture. Each GPIO line now has its own
> dedicated 32-bit control register to manage configuration independently,
> including direction, output value, input value, interrupt enable, and
> debounce. Therefore, this distinct hardware design requires a separate
> driver.
>
> Signed-off-by: Tzuyi Chang <tychang@realtek.com>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
With Bartosz comment addressed:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ 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