* Re: [PATCH v2] dt-bindings: mediatek: cec: Correct the compatibles for mt7623-mt8167
From: Krzysztof Kozlowski @ 2026-06-25 7:32 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, CK Hu, Jitao shi,
dri-devel, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260624173627.19785-1-l.scorcia@gmail.com>
On Wed, Jun 24, 2026 at 07:36:15PM +0200, Luca Leonardo Scorcia wrote:
> The HDMI CEC driver for both mt7623 and mt8167 is actually the same as
> mt8173-cec and the mt7623n.dtsi board include file already uses mt8173-cec
> compatible as a fallback, but the documentation lists them as separate
> entries. Correct the binding by adding the correct fallback.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: mmc: Convert TI OMAP2420 MMC to DT schema
From: Krzysztof Kozlowski @ 2026-06-25 7:31 UTC (permalink / raw)
To: Eduard Bostina
Cc: daniel.baluta, simona.toaca, goledhruva, m-chawdhry, Ulf Hansson,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-mmc,
devicetree, linux-kernel
In-Reply-To: <20260624163112.535237-1-egbostina@gmail.com>
On Wed, Jun 24, 2026 at 04:31:11PM +0000, Eduard Bostina wrote:
> Convert the Texas Instruments MMC host controller bindings
> to DT schema.
>
> Note that the OMAP2420 driver will not work with OMAP2430 or later omaps.
> Please see the OMAP HSMMC driver for current OMAPs.
>
> Signed-off-by: Eduard Bostina <egbostina@gmail.com>
> ---
> Changes in v2:
> - Changed ti,hwmods type reference from string-array to string
> - Updated ti,hwmods regex pattern to "^msdi([1-9]|[1-9][0-9]+)$"
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v16 04/14] lib: kstrtox: add initial value to _parse_integer_limit()
From: Rodrigo Alencar @ 2026-06-25 7:30 UTC (permalink / raw)
To: Jonathan Cameron, Rodrigo Alencar
Cc: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc,
linux, David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Petr Mladek, Steven Rostedt,
Andy Shevchenko, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260624155414.61755e9a@jic23-huawei>
On 24/06/26 15:54, Jonathan Cameron wrote:
> On Sun, 14 Jun 2026 21:00:44 +0100
> Jonathan Cameron <jic23@kernel.org> wrote:
>
> > On Thu, 4 Jun 2026 11:09:33 +0100
> > Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> >
> > > On 26/06/04 10:58AM, Rodrigo Alencar via B4 Relay wrote:
> > > > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > > >
> > > > Add init parameter to _parse_integer_limit() that defines an initial
> > > > value for the accumulated result when parsing an 64-bit integer. The
> > > > new function prototype is adjusted so that the _parse_integer() macros
> > > > stay consistent allowing for one more argument, which defaults to 0.
> > >
> > > ...
> > >
> > > > noinline
> > > > unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *p,
> > > > - size_t max_chars)
> > > > + size_t max_chars, unsigned long long init)
> > > > {
> > > > unsigned long long res;
> > > > unsigned int rv;
> > > >
> > > > - res = 0;
> > > > + res = init;
> > >
> > > This might generate conflict, as the code around have changed in linux-next.
> > > It is an easy fix though.
> > >
> > Thanks for the heads up. Hopefully that will all fall out when I rebase testing
> > on rc1 once that is out.
> I've done a mid merge cycle rebase as the char-misc branches have merged.
> So this should be resolve on my testing branch now.
https://lore.kernel.org/oe-kbuild-all/202606250230.etPGuolf-lkp@intel.com/
Apparently, the documentation header now includes parameter descriptions.
The new one is missing.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v5 07/14] mfd: lm3533: Use dev_groups in struct device_driver
From: Andy Shevchenko @ 2026-06-25 7:26 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <ajzXidQCd8pe-L5b@ashevche-desk.local>
On Thu, Jun 25, 2026 at 10:24:00AM +0300, Andy Shevchenko wrote:
> On Wed, Jun 17, 2026 at 11:00:24AM +0300, Svyatoslav Ryhel wrote:
...
> > .attrs = lm3533_attributes
> > };
> >
> > +static const struct attribute_group *lm3533_attribute_groups[] = {
> > + &lm3533_attribute_group,
> > + NULL,
> > +};
>
> We have ATTRIBUTE_GROUPS() macro.
Okay, it uses is_visible, so __ATTRIBUTE_GROUPS() that we can still use.
...
> > +++ b/drivers/video/backlight/lm3533_bl.c
>
> Same as per above.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* RE: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Sherry Sun @ 2026-06-25 7:25 UTC (permalink / raw)
To: Frank Li (OSS)
Cc: Sherry Sun (OSS), robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Frank Li, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, Amitkumar Karwar,
Neeraj Sanjay Kale, marcel@holtmann.org, luiz.dentz@gmail.com,
Hongxing Zhu, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com,
brgl@kernel.org, imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-pm@vger.kernel.org
In-Reply-To: <ajwOvZUlOEQzmjsu@SMW015318>
> Subject: Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
>
> On Wed, Jun 24, 2026 at 07:09:26AM +0000, Sherry Sun wrote:
> > > Subject: Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag
> > > support
> > >
> > > On Tue, Jun 23, 2026 at 11:07:28AM +0800, Sherry Sun (OSS) wrote:
> > > > From: Sherry Sun <sherry.sun@nxp.com>
> > > >
> > > > Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices
> > > > during suspend to preserve wakeup capability of the devices and
> > > > also not to power on the devices in the init path.
> > > > This allows controller power-off to be skipped when some devices(e.g.
> > > > M.2 cards key E without auxiliary power) required to support PCIe
> > > > L2 link state and wake-up mechanisms.
> > > >
> > > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > > ---
> > > > drivers/pci/controller/dwc/pci-imx6.c | 36
> > > > +++++++++++++++++----------
> > > > 1 file changed, 23 insertions(+), 13 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > > index 0fa716d1ed75..ff5a9565dbbf 100644
> > > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > > @@ -1382,16 +1382,20 @@ static int imx_pcie_host_init(struct
> > > > dw_pcie_rp
> > > *pp)
> > > > }
> > > > }
> > > >
> > > > - ret = pci_pwrctrl_create_devices(dev);
> > > > - if (ret) {
> > > > - dev_err(dev, "failed to create pwrctrl devices\n");
> > > > - goto err_reg_disable;
> > > > + if (!pci->suspended) {
> > > > + ret = pci_pwrctrl_create_devices(dev);
> > >
> > > Is possible move pci_pwrctrl_create_devices() of
> > > pci_pwrctrl_create_devices
> > >
> > > and call it direct at probe() function, like other regulator_get function.
> > >
> >
> > Hi Frank,
> > That makes sense. However, if we move pci_pwrctrl_create_devices () to
> > probe(), we may need to add the following goto err_pwrctrl_destroy
> > path in imx_pcie_probe() to properly handle errors from
> > pci_pwrctrl_power_on_devices(), is that acceptable?
>
> Can you add a API devm_pci_pwrctrl_create_devices() ?
>
Hi Frank, we cannot unconditionally destroy the pwrctrl devices
when probing fails by using devm API.
Since we need to check the return value of
pci_pwrctrl_power_on_devices() for example EPROBE_DEFER to decide
whether to destroy the pwrctrl devices to avoid the deferred probe loop.
You can find more related discussion here.
https://lore.kernel.org/all/tutxwjciedqoje5wxvtin4h637auni5zzpvb7rtfg4uticxoux@yfl6xg7oht7t/
Best Regards
Sherry
>
> >
> > @@ -1960,11 +1949,15 @@ static int imx_pcie_probe(struct
> platform_device *pdev)
> > if (ret)
> > return ret;
> >
> > + ret = pci_pwrctrl_create_devices(dev);
> > + if (ret)
> > + return dev_err_probe(dev, ret, "failed to create
> > + pwrctrl devices\n");
> > +
> > pci->use_parent_dt_ranges = true;
> > if (imx_pcie->drvdata->mode == DW_PCIE_EP_TYPE) {
> > ret = imx_add_pcie_ep(imx_pcie, pdev);
> > if (ret < 0)
> > - return ret;
> > + goto err_pwrctrl_destroy;
> >
> > /*
> > * FIXME: Only single Device (EPF) is supported due to
> > the @@ -1979,7 +1972,7 @@ static int imx_pcie_probe(struct
> platform_device *pdev)
> > pci->pp.use_atu_msg = true;
> > ret = dw_pcie_host_init(&pci->pp);
> > if (ret < 0)
> > - return ret;
> > + goto err_pwrctrl_destroy;
> >
> > if (pci_msi_enabled()) {
> > u8 offset = dw_pcie_find_capability(pci,
> > PCI_CAP_ID_MSI); @@ -1991,6 +1984,11 @@ static int
> imx_pcie_probe(struct platform_device *pdev)
> > }
> >
> > return 0;
> > +
> > +err_pwrctrl_destroy:
> > + if (ret != -EPROBE_DEFER)
> > + pci_pwrctrl_destroy_devices(dev);
> > + return ret;
> > }
> >
> > Best Regards
> > Sherry
> >
> > >
> > > > + if (ret) {
> > > > + dev_err(dev, "failed to create pwrctrl devices\n");
> > > > + goto err_reg_disable;
> > > > + }
> > > > }
> > > >
> > > > - ret = pci_pwrctrl_power_on_devices(dev);
> > > > - if (ret) {
> > > > - dev_err(dev, "failed to power on pwrctrl devices\n");
> > > > - goto err_pwrctrl_destroy;
> > > > + if (!pp->skip_pwrctrl_off) {
> > > > + ret = pci_pwrctrl_power_on_devices(dev);
> > > > + if (ret) {
> > > > + dev_err(dev, "failed to power on pwrctrl devices\n");
> > > > + goto err_pwrctrl_destroy;
> > > > + }
> > > > }
> > > >
> > > > ret = imx_pcie_clk_enable(imx_pcie); @@ -1460,9 +1464,10 @@
> > > static
> > > > int imx_pcie_host_init(struct dw_pcie_rp *pp)
> > > > err_clk_disable:
> > > > imx_pcie_clk_disable(imx_pcie);
> > > > err_pwrctrl_power_off:
> > > > - pci_pwrctrl_power_off_devices(dev);
> > > > + if (!pp->skip_pwrctrl_off)
> > > > + pci_pwrctrl_power_off_devices(dev);
> > > > err_pwrctrl_destroy:
> > > > - if (ret != -EPROBE_DEFER)
> > > > + if (ret != -EPROBE_DEFER && !pci->suspended)
> > > > pci_pwrctrl_destroy_devices(dev);
> > > > err_reg_disable:
> > > > if (imx_pcie->vpcie)
> > > > @@ -1482,7 +1487,8 @@ static void imx_pcie_host_exit(struct
> > > > dw_pcie_rp
> > > *pp)
> > > > }
> > > > imx_pcie_clk_disable(imx_pcie);
> > > >
> > > > - pci_pwrctrl_power_off_devices(pci->dev);
> > > > + if (!pci->pp.skip_pwrctrl_off)
> > > > + pci_pwrctrl_power_off_devices(pci->dev);
> > > > if (imx_pcie->vpcie)
> > > > regulator_disable(imx_pcie->vpcie);
> > > > }
> > > > @@ -1990,12 +1996,16 @@ static int imx_pcie_probe(struct
> > > > platform_device *pdev) static void imx_pcie_shutdown(struct
> > > > platform_device *pdev) {
> > > > struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> > > > + struct dw_pcie *pci = imx_pcie->pci;
> > > > + struct dw_pcie_rp *pp = &pci->pp;
> > > >
> > > > /* bring down link, so bootloader gets clean state in case of reboot */
> > > > imx_pcie_assert_core_reset(imx_pcie);
> > > > imx_pcie_assert_perst(imx_pcie, true);
> > > > - pci_pwrctrl_power_off_devices(&pdev->dev);
> > > > - pci_pwrctrl_destroy_devices(&pdev->dev);
> > > > + if (!pp->skip_pwrctrl_off)
> > > > + pci_pwrctrl_power_off_devices(&pdev->dev);
> > > > + if (!pci->suspended)
> > > > + pci_pwrctrl_destroy_devices(&pdev->dev);
> > > > }
> > > >
> > > > static const struct imx_pcie_drvdata drvdata[] = {
> > > > --
> > > > 2.50.1
> > > >
> > > >
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom,coresight-tnoc: allow arm,primecell-periphid
From: Krzysztof Kozlowski @ 2026-06-25 7:24 UTC (permalink / raw)
To: Jie Gan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Konrad Dybcio, linux-arm-msm, devicetree,
linux-kernel, coresight, linux-arm-kernel
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v2-1-786520f62f21@oss.qualcomm.com>
On Wed, Jun 24, 2026 at 05:49:25PM +0800, Jie Gan wrote:
> The TNOC device is an AMBA primecell and may carry the standard
> arm,primecell-periphid property, which is used to supply the
> peripheral ID when it cannot be read from the device registers.
>
> Reference primecell.yaml and set additionalProperties to true so the
> binding accepts arm,primecell-periphid along with the other common
> primecell properties.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
> index ef648a15b806..9624fc0adfdc 100644
> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
> @@ -32,6 +32,9 @@ select:
> required:
> - compatible
>
> +allOf:
> + - $ref: /schemas/arm/primecell.yaml#
> +
> properties:
> $nodename:
> pattern: "^tn(@[0-9a-f]+)$"
> @@ -78,7 +81,7 @@ required:
> - in-ports
> - out-ports
>
> -additionalProperties: false
> +additionalProperties: true
Nope, it is not allowed. Explicitly mentioned in writing bindings and
all DT introductory talks by me.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 07/14] mfd: lm3533: Use dev_groups in struct device_driver
From: Andy Shevchenko @ 2026-06-25 7:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-8-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:24AM +0300, Svyatoslav Ryhel wrote:
> Instead of creating and removing the device sysfs attributes directly
> during probe and remove of the driver, respectively, use dev_groups in
> struct device_driver to point to the attribute definitions and let the
> core take care of creating and removing them.
>
> No intentional functional impact.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
And thanks for doing that!
...
> .attrs = lm3533_attributes
> };
>
> +static const struct attribute_group *lm3533_attribute_groups[] = {
> + &lm3533_attribute_group,
> + NULL,
> +};
We have ATTRIBUTE_GROUPS() macro.
...
> +++ b/drivers/video/backlight/lm3533_bl.c
Same as per above.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/4] input: misc: Add an initial driver for haptics inside Qcom PMIH010x PMIC
From: Krzysztof Kozlowski @ 2026-06-25 7:22 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <9175804c-956d-41eb-9995-05a7b3bf3fcc@oss.qualcomm.com>
On 25/06/2026 09:09, Fenglin Wu wrote:
>>
>> That is not what I meant and you did not follow maintainer process. And
>> why did you ignore second binding? Identify how many separate
>> maintainers are here and act like them. I looked again at your patchset
>> and I am sure about that - patchset is unmergeable by Lee.
>
> I see. So I should mention below sentence at the beginning of the cover
> letter, is that right?
>
> Dependencies:
>
> - [patch 2/4] depends on [patch 1/4] and they should be applied together.
>
Yes.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: adm1275: ROHM BD12780 hot-swap controller
From: Krzysztof Kozlowski @ 2026-06-25 7:21 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Matti Vaittinen, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Wensheng Wang, Ashish Yadav, Kim Seer Paller, Cedric Encarnacion,
Chris Packham, Yuxi Wang, Charles Hsu, ChiShih Tsai, linux-hwmon,
devicetree, linux-kernel, linux-doc
In-Reply-To: <bd9419aa-1a21-4ca2-990b-ad1bebf5c9c8@gmail.com>
On 25/06/2026 09:05, Matti Vaittinen wrote:
>>> + - adi,adm1075
>>> + - adi,adm1272
>>> + - adi,adm1273
>>> + - adi,adm1275
>>> + - adi,adm1276
>>> + - adi,adm1278
>>> + - adi,adm1281
>>> + - adi,adm1293
>>> + - adi,adm1294
>>> + - rohm,bd12780
>>> + - silergy,mc09c
>>> +
>>> +# Require BD12780 as a fall-back for BD12780A.
>>
>> No need for the comment, schema is quite explicit.
>
> Eh... I know it is explicit for one who fluently reads yaml. Not all of
> us do that :| (See my reply to the previous comment...) I am not sure
> the comment hurts - while I am sure it helps occasional binding reader
> like me. Can you please reconsider keeping the comment?
This one does not, but if people take the existing code as a starting
point or even as an example in arguments ("he did like that, so I am
allowed as well"), it gets multiplied and we have more bindings with
redundant data.
That's said, if you insist then fine with me, keep it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/4] input: misc: Add an initial driver for haptics inside Qcom PMIH010x PMIC
From: Fenglin Wu @ 2026-06-25 7:09 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <91cc96b0-d25f-436d-a0c7-fec39bf72393@kernel.org>
On 6/25/2026 2:19 PM, Krzysztof Kozlowski wrote:
> On 25/06/2026 03:41, Fenglin Wu wrote:
>> On 6/24/2026 6:05 PM, Krzysztof Kozlowski wrote:
>>> No. Act as maintainer. Clone Linus tree, apply the patch and see if
>>> everything works. My claim is that nothing works and maintainer tree is
>>> broken.
>>>
>>> Best regards,
>>> Krzysztof
>> Thanks for the explanation. I just did that and I didn't see conflict
>> when applying the binding and driver changes, but I did see a conflict
>> when applying the DTS change. I will drop the DTS change 1st and resend
>> them after the driver and binding changes get accepted.
>
> That is not what I meant and you did not follow maintainer process. And
> why did you ignore second binding? Identify how many separate
> maintainers are here and act like them. I looked again at your patchset
> and I am sure about that - patchset is unmergeable by Lee.
I see. So I should mention below sentence at the beginning of the cover
letter, is that right?
Dependencies:
- [patch 2/4] depends on [patch 1/4] and they should be applied together.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: adm1275: ROHM BD12780 hot-swap controller
From: Matti Vaittinen @ 2026-06-25 7:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Matti Vaittinen, Matti Vaittinen, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Wensheng Wang, Ashish Yadav, Kim Seer Paller, Cedric Encarnacion,
Chris Packham, Yuxi Wang, Charles Hsu, ChiShih Tsai, linux-hwmon,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260617-uptight-sexy-hippo-f4bc62@quoll>
I think I (almost) missed this review... Sorry for the belated reply.
On 17/06/2026 13:28, Krzysztof Kozlowski wrote:
> On Tue, Jun 16, 2026 at 09:35:35AM +0300, Matti Vaittinen wrote:
> +
>> + Datasheets:
>> + https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/power_switch/bd12780muv-lb-e.pdf
>> + https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/power_switch/bd12780amuv-lb-e.pdf
>> +
>> properties:
>> compatible:
>> - enum:
>> - - adi,adm1075
>> - - adi,adm1272
>> - - adi,adm1273
>> - - adi,adm1275
>> - - adi,adm1276
>> - - adi,adm1278
>> - - adi,adm1281
>> - - adi,adm1293
>> - - adi,adm1294
>> - - silergy,mc09c
>> + oneOf:
>> + - items:
>> + enum:
>
>
> s/items/enum/, so:
>
> oneOf:
> - enum:
> ....
Thanks Krzysztof. I am always so lost with these bindings. Giving the
concrete suggestion(s) helps a lot!
>
>> + - adi,adm1075
>> + - adi,adm1272
>> + - adi,adm1273
>> + - adi,adm1275
>> + - adi,adm1276
>> + - adi,adm1278
>> + - adi,adm1281
>> + - adi,adm1293
>> + - adi,adm1294
>> + - rohm,bd12780
>> + - silergy,mc09c
>> +
>> +# Require BD12780 as a fall-back for BD12780A.
>
> No need for the comment, schema is quite explicit.
Eh... I know it is explicit for one who fluently reads yaml. Not all of
us do that :| (See my reply to the previous comment...) I am not sure
the comment hurts - while I am sure it helps occasional binding reader
like me. Can you please reconsider keeping the comment?
Although, I am not sure if Guenter suggested me to drop the compatible
for the bd12780a and only use the bd12780 - or if his comment only
applied to the i2c IDs.
https://lore.kernel.org/all/751cd5eb-104f-4445-a6d2-8119ad5d5660@roeck-us.net/
Well, I will keep the bd12780a compatible and drop the I2C ID unless
something else is suggested. Again, the BD12780 and BD12780A do have
different hardware properties (at least in I2C slave address selection
pins), and while it doesn't really matter for the Linux drivers, the DT
bindings should ideally be generic and not Linux specific.
Yours,
-- Matti.
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: dts: socfpga: agilex72: Add initial device tree
From: sashiko-bot @ 2026-06-25 7:04 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260625065329.20274-3-muhammad.nazim.amirul.nazle.asmade@altera.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Missing CPU topology and relative capacity metrics (`capacity-dmips-mhz`) for the heterogeneous Cortex-A520/A720 cluster.
- [Medium] Malformed reserved-memory nodes for firmware regions mixing static and dynamic properties, and improperly exposing secure memory as a DMA pool.
--
commit 24c23f8ecc00caa97660929277c73ae2d495bf92
Author: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
arm64: dts: socfpga: agilex72: Add initial device tree
This commit adds initial device tree support for the Intel SoCFPGA Agilex72
platform. The Agilex72 SoC features a heterogeneous CPU cluster with
Cortex-A520 and Cortex-A720 cores, and includes an SMMU v3 for memory
management.
> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
> new file mode 100644
> index 0000000000000..c29c2afcaab70
> --- /dev/null
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
> @@ -0,0 +1,156 @@
[ ... ]
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + atf_reserved: atf@80000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x0 0x80000000 0x0 0x100000>;
> + alignment = <0x1000>;
> + no-map;
> + };
[Severity: Medium]
Does this node improperly mix static and dynamic allocation properties?
The reg property implies static allocation, while alignment is for
dynamic allocation, and according to the bindings, these are mutually
exclusive.
Also, should ATF memory be exposed as a shared-dma-pool? Secure firmware
memory generally shouldn't be exposed as a pool for the kernel's DMA
subsystem to manage, as it could lead to exceptions if the non-secure kernel
attempts to map or allocate from it.
> +
> + service_reserved: svcbuffer@80100000 {
> + compatible = "shared-dma-pool";
> + reg = <0x0 0x80100000 0x0 0xf00000>;
> + alignment = <0x1000>;
> + no-map;
> + };
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a520";
> + device_type = "cpu";
> + enable-method = "psci";
> + reg = <0x0>;
> + };
[Severity: Medium]
Will the scheduler treat these heterogeneous cores as having equal compute
capacity?
Without a cpu-map topology and capacity-dmips-mhz properties, the Linux
scheduler may default to treating the Cortex-A520 and Cortex-A720 cores
as having equal capacity.
This could lead to suboptimal task placement for the big.LITTLE
architecture.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625065329.20274-1-muhammad.nazim.amirul.nazle.asmade@altera.com?part=2
^ permalink raw reply
* [PATCH v3 0/2] arm64: dts: socfpga: agilex72: Add initial device tree
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-25 6:53 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
This series introduces basic device tree support for the Intel/Altera
Agilex72 SoCFPGA platform, which is a new SoC featuring a heterogeneous
CPU cluster (Cortex-A520 and Cortex-A720 cores).
Patch 1 adds the new compatible strings for Agilex72 to the arm/altera
DT bindings documentation.
Patch 2 introduces the initial DTSI and board-level DTS for the Agilex72
SoCDK. The DTSI covers the core SoC nodes: CPUs, GIC-v3 interrupt
controller with ITS, ARM architectural timer, PSCI, SMMU-v3, OCRAM, and
two UART serial controllers backed by a fixed-clock placeholder. The clock
manager driver for this platform is not yet upstream, so a fixed-clock
at 125 MHz is used as an interim solution for the UART clock, matching
the hardware-confirmed LSP_SP_CLK frequency.
Changes in v3:
- Add UART serial console (uart0, uart1) with fixed-clock placeholder at 125 MHz
- Add aliases and chosen nodes in board DTS for serial console
Changes in v2:
- Applied relevant feedback from Shahsiko's review
- Re-add arm,armv8-timer node which is mandatory for kernel boot
- Rename platform from agilex7-gen2 to agilex72
Nazim Amirul (2):
dt-bindings: arm: altera: Add Agilex72 SoCFPGA compatible strings
arm64: dts: socfpga: agilex72: Add initial device tree
.../devicetree/bindings/arm/altera.yaml | 6 +
arch/arm64/boot/dts/intel/Makefile | 1 +
.../boot/dts/intel/socfpga_agilex72.dtsi | 156 ++++++++++++++++++
.../boot/dts/intel/socfpga_agilex72_socdk.dts | 27 +++
4 files changed, 190 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
--
2.43.7
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: arm: altera: Add Agilex72 SoCFPGA compatible strings
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-25 6:53 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260625065329.20274-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Add the SoC and board compatible strings for the Intel SoCFPGA
Agilex72 platform.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes in v3:
- no changes
---
Documentation/devicetree/bindings/arm/altera.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
index 4b096e52243e..cc03fb437a9a 100644
--- a/Documentation/devicetree/bindings/arm/altera.yaml
+++ b/Documentation/devicetree/bindings/arm/altera.yaml
@@ -115,6 +115,12 @@ properties:
- intel,socfpga-agilex5-socdk-nand
- const: intel,socfpga-agilex5
+ - description: Agilex72 boards
+ items:
+ - enum:
+ - intel,socfpga-agilex72-socdk
+ - const: intel,socfpga-agilex72
+
- description: Agilex7m boards
items:
- enum:
--
2.43.7
^ permalink raw reply related
* [PATCH v3 2/2] arm64: dts: socfpga: agilex72: Add initial device tree
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-25 6:53 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260625065329.20274-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Add initial device tree support for the Intel SoCFPGA Agilex72
platform. This introduces the SoC DTSI and the SoCDK board DTS as
the first upstream submission for this platform.
The Agilex72 SoC features a heterogeneous CPU cluster with
Cortex-A520 and Cortex-A720 cores, and includes an SMMU v3 for
memory management.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
Changes in v3:
- Add UART serial console (uart0, uart1) with fixed-clock placeholder at 125 MHz
- Add aliases and chosen nodes in board DTS for serial console
Changes in v2:
- Re-add arm,armv8-timer node which is mandatory for kernel boot
- Rename platform from agilex7-gen2 to agilex72
---
arch/arm64/boot/dts/intel/Makefile | 1 +
.../boot/dts/intel/socfpga_agilex72.dtsi | 156 ++++++++++++++++++
.../boot/dts/intel/socfpga_agilex72_socdk.dts | 27 +++
3 files changed, 184 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
index 088a03b89c99..270c70fdf084 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -8,6 +8,7 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
socfpga_agilex5_socdk_013b.dtb \
socfpga_agilex5_socdk_modular.dtb \
socfpga_agilex5_socdk_nand.dtb \
+ socfpga_agilex72_socdk.dtb \
socfpga_agilex7m_socdk.dtb \
socfpga_n5x_socdk.dtb
dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
new file mode 100644
index 000000000000..c29c2afcaab7
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, Altera Corporation
+ */
+/dts-v1/;
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ compatible = "intel,socfpga-agilex72";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ atf_reserved: atf@80000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x80000000 0x0 0x100000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+
+ service_reserved: svcbuffer@80100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x80100000 0x0 0xf00000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a520";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x0>;
+ };
+
+ cpu1: cpu@100 {
+ compatible = "arm,cortex-a520";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x100>;
+ };
+
+ cpu2: cpu@200 {
+ compatible = "arm,cortex-a720";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x200>;
+ };
+
+ cpu3: cpu@300 {
+ compatible = "arm,cortex-a720";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x300>;
+ };
+ };
+
+ clocks {
+ uart_clk: uart-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ intc: interrupt-controller@7000000 {
+ compatible = "arm,gic-v3";
+ reg = <0x0 0x7000000 0x0 0x10000>,
+ <0x0 0x7080000 0x0 0x100000>;
+ ranges;
+ #interrupt-cells = <3>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-controller;
+ #redistributor-regions = <1>;
+ redistributor-stride = <0x0 0x40000>;
+
+ its: msi-controller@7040000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x0 0x7040000 0x0 0x20000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ soc: soc@0 {
+ compatible = "simple-bus";
+ ranges = <0 0 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ interrupt-parent = <&intc>;
+
+ smmu: iommu@c100000 {
+ compatible = "arm,smmu-v3";
+ reg = <0x0c100000 0x30000>;
+ interrupts = <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "eventq", "gerror", "priq";
+ dma-coherent;
+ #iommu-cells = <1>;
+ };
+
+ ocram: sram@0 {
+ compatible = "mmio-sram";
+ reg = <0x00000000 0x80000>;
+ ranges = <0 0 0x80000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
+ uart0: serial@9038000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x9038000 0x100>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&uart_clk>;
+ status = "disabled";
+ };
+
+ uart1: serial@9039000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x9039000 0x100>;
+ interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&uart_clk>;
+ status = "disabled";
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts b/arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
new file mode 100644
index 000000000000..998f19f492b3
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, Altera Corporation
+ */
+#include "socfpga_agilex72.dtsi"
+
+/ {
+ model = "Altera SoCFPGA Agilex72 SoCDK";
+ compatible = "intel,socfpga-agilex72-socdk", "intel,socfpga-agilex72";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0x0 0x80000000>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
--
2.43.7
^ permalink raw reply related
* Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties
From: Krzysztof Kozlowski @ 2026-06-25 6:48 UTC (permalink / raw)
To: Daniel Lezcano, Gaurav Kohli
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi,
Dmitry Baryshkov
In-Reply-To: <ae0ec05e-607b-4022-a006-2eb1a283144d@oss.qualcomm.com>
On 24/06/2026 17:56, Daniel Lezcano wrote:
> On 6/24/26 12:42, Krzysztof Kozlowski wrote:
>
> [ ... ]
>
>> Therefore I still do not see the need of tmd-names. You know the name of
>> cooling device, because you have strict one-to-one mapping.
>
>
> There is one remote proc with one or multiple cooling devices attached.
>
> We describe those in the remoteproc node with the tmd-names.
>
> Anyway, we should be able to list the tmd names in the driver itself if
> we ensure a consistency with the index by defining them in a shared
> header eg. include/dt-bindings/firmware/qcom,cdsp.h
>
> #define HAMOA_TMD_CDSP_SW 0
> #define HAMOA_TMD_CDSP_HW 1
> #define HAMOA_TMD_CP0UV_RESTRICTION_COLD 2
>
> In the driver:
>
> struct tmd_name {
> const char *name;
> int id;
> bool disabled;
> };
>
> static struct tmd_name tmd_names[] = {
> { .name = "cdsp_sw", HAMOA_TMD_CDSP_SW },
> { .name = "cdsp_hw", HAMOA_TMD_CDSP_HW, .disabled = true },
> { .name = "cpuv_restriction_cold", HAMOA_TMD_CP0UV_RESTRICTION_COLD,
> .disabled = true },
> };
>
> ...
> for (int i = 0; i < ARRAY_SIZE(tmd_names); i++) {
>
> if (tmd_names[i].disabled)
> continue;
> devm_cooling_of_device_register(rprocdev,
> tmd_names[i].name, tmd_names[i].id, ...);
> }
>
>
> In the device tree:
>
> cooling-maps = <&rproc HAMOA_TMD_CDSP_SW min max>;
>
> I think that is somehow what Konrad and Dmitry were suggesting
>
> Does it sound better ?
Yes and I am surprised that it came now. So you had TMD index available
thus the ID was defined. If device has unique and fixed ID, you should
not have any more properties defining it, because that ID is enough. Any
names could be only for users, e.g. label, but that is not the case here.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: power: limits: Describe Qualcomm SPEL hardware
From: Krzysztof Kozlowski @ 2026-06-25 6:45 UTC (permalink / raw)
To: Daniel Lezcano, Manaf Meethalavalappu Pallikunhi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Bjorn Andersson, Konrad Dybcio, Gaurav Kohli, linux-arm-msm,
devicetree, linux-kernel, linux-pm
In-Reply-To: <63d42dd6-862f-4a9c-a950-5bc90ffab391@oss.qualcomm.com>
On 24/06/2026 22:41, Daniel Lezcano wrote:
> It allows power capping and read the average power consumption for a
> specific device (or/and an energy counter)
>
> Basically you can set a power constraint (power limit) to a device and
> this one won't consume more than that power (the power limitation
> strategy is managed under the hood by the firmware depending on the
> device - lower OPP, idle injection, modem weaker signal, etc ...).
>
> The RAPL or the SPEL have a hierarchical power limitation. For example:
>
> SoC
> |
> ------------------------
> | |
> Cluster0 Cluster1
> | |
> ----------------- -----------------
> | | | | | | | |
> CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
>
>
> If you specify a power limit to 'SoC', then the power consumption of
> Cluster0 + Cluster1 <= SoC
>
> If Cluster0 power consumption decreases, then Cluster1 is allowed to use
> more power until Cluster0 + Cluster1 <= SoC
>
> For me it sounds reasonable to put the device description under power/limits
Yes, can go there. Some pieces of above explanation could be captured in
commit msg.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Krzysztof Kozlowski @ 2026-06-25 6:43 UTC (permalink / raw)
To: Gerald Loacker
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-2-323356c2cc2e@wolfvision.net>
On Fri, Jun 19, 2026 at 11:13:40AM +0200, Gerald Loacker wrote:
> Add support for the optional rockchip,clk-lane-phase device tree property
> to allow board-specific tuning of the clock lane sampling phase for
> improved signal integrity across supported data rates.
>
> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
> ---
> .../devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
> index 03950b3cad08c..010950a8a8856 100644
> --- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
> +++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
> @@ -56,6 +56,15 @@ properties:
> description:
> Some additional phy settings are access through GRF regs.
>
> + rockchip,clk-lane-phase:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 7
Missing default here. If default is unknown, explain that in commit msg.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: edac: Add bindings for Xilinx Versal XilSEM
From: Krzysztof Kozlowski @ 2026-06-25 6:39 UTC (permalink / raw)
To: Rama devi Veggalam
Cc: bp, tony.luck, michal.simek, robh, krzk+dt, conor+dt,
linux-kernel, linux-edac, devicetree, james.morse, mchehab, rric,
git
In-Reply-To: <20260624212545.2850787-2-rama.devi.veggalam@amd.com>
On Thu, Jun 25, 2026 at 02:55:42AM +0530, Rama devi Veggalam wrote:
> Update versal edac device tree bindings for
> Versal Soft Error Mitigation (XilSEM).
>
> Signed-off-by: Rama devi Veggalam <rama.devi.veggalam@amd.com>
> ---
> Changes in v3:
> - Merged XilSEM edac with Versal Edac
One more thing: There is no xilsem here... or commit msg is just missing
the main point. This is very confusing or heavily incorrect patch. No
clue which one.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: edac: Add bindings for Xilinx Versal XilSEM
From: Krzysztof Kozlowski @ 2026-06-25 6:37 UTC (permalink / raw)
To: Rama devi Veggalam
Cc: bp, tony.luck, michal.simek, robh, krzk+dt, conor+dt,
linux-kernel, linux-edac, devicetree, james.morse, mchehab, rric,
git
In-Reply-To: <20260624212545.2850787-2-rama.devi.veggalam@amd.com>
On Thu, Jun 25, 2026 at 02:55:42AM +0530, Rama devi Veggalam wrote:
> Update versal edac device tree bindings for
Everything is update. Pretty useless commit msg.
> Versal Soft Error Mitigation (XilSEM).
A nit, subject: drop second/last, redundant "bindings for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
>
> Signed-off-by: Rama devi Veggalam <rama.devi.veggalam@amd.com>
> ---
> Changes in v3:
> - Merged XilSEM edac with Versal Edac
>
> Changes in v2:
> - Changed "xlnx,versal-xilsem-edac" to constant
> - Removed "compatible: in required section
> - Removed "|" in description
> - Removed "items" in compatible
> - Fixed indentation in examples
> - Updated title and description
> ---
> .../xlnx,versal-ddrmc-edac.yaml | 22 ++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-ddrmc-edac.yaml b/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-ddrmc-edac.yaml
> index 12f8e9f350bc..568d2af7de81 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-ddrmc-edac.yaml
> +++ b/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-ddrmc-edac.yaml
> @@ -4,17 +4,31 @@
> $id: http://devicetree.org/schemas/memory-controllers/xlnx,versal-ddrmc-edac.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: Xilinx Versal DDRMC (Integrated DDR Memory Controller)
> +title: Xilinx Versal DDRMC (Integrated DDR Memory Controller) and Soft Error Mitigation (XilSEM)
>
> maintainers:
> - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
> - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
> + - Rama Devi Veggalam <rama.devi.veggalam@amd.com>
>
> description:
> The integrated DDR Memory Controllers (DDRMCs) support both DDR4 and LPDDR4/
> 4X memory interfaces. Versal DDR memory controller has an optional ECC support
> which correct single bit ECC errors and detect double bit ECC errors.
>
> + Xilinx Versal Soft Error Mitigation (XilSEM) is part of the
> + Platform Loader and Manager (PLM) which runs on the
> + Platform Management Controller (PMC). XilSEM is responsible for reporting
> + and optionally correcting soft errors in Configuration Memory of Versal.
> + The Configuration Memory includes Configuration RAM and
> + Network on Chip (NoC) peripheral interconnect (NPI) Registers.
> +
> + The memory is scanned by a hardware controller in the Versal Programmable
> + Logic (PL). During the scan, if the controller detects any error, be it
> + correctable or uncorrectable, it reports the error to PLM.
> + The XilSEM on PLM performs the error validation and notifies the errors to user application.
> +
> +
> properties:
> compatible:
> const: xlnx,versal-ddrmc
> @@ -23,11 +37,13 @@ properties:
> items:
> - description: DDR Memory Controller registers
> - description: NOC registers corresponding to DDR Memory Controller
> + - description: SEM RTCA Controller registers
>
> reg-names:
> items:
> - const: base
> - const: noc
> + - const: semrtca
You break ABI without any explanation.
NAK, I think I made this point many times already... Please read
writing-bindings doc.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: serial: 8250: aspeed: add aspeed,vuart-over-pci bool prop
From: Krzysztof Kozlowski @ 2026-06-25 6:36 UTC (permalink / raw)
To: Grégoire Layet
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <CAFi2wKbKr8FMcJeGWA5e1UZUTh2=LwYNkLEj6exd2as7=AcvVQ@mail.gmail.com>
On 24/06/2026 14:48, Grégoire Layet wrote:
> Hi Krzysztof,
>
>> What does that mean? How UART can be accessible over PCI bus?
>
> It's a Virtual UART. Internally, it's two FIFOs accessible via
> 8250-compatible register sets on both ends.
I do not know what is Virtual UART...
> There is 4 Virtuals UARTs on the LPC bus of the AST2600 and 2 of them
> are bridged over the PCI bus.
> So, from the host, you can access the 8250 register set on the PCI bus.
You mean these appear (or are) as PCI devices?
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: iio: health: add adi,max86150
From: Krzysztof Kozlowski @ 2026-06-25 6:33 UTC (permalink / raw)
To: Md Shofiqul Islam
Cc: linux-iio, jic23, lars, conor, conor+dt, robh, krzk+dt,
devicetree, linux-kernel
In-Reply-To: <20260623201124.18271-2-shofiqtest@gmail.com>
On Tue, Jun 23, 2026 at 11:11:21PM +0300, Md Shofiqul Islam wrote:
Do not attach (thread) your patchsets to some other threads (unrelated
or older versions). This buries them deep in the mailbox and might
interfere with applying entire sets. See also:
https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> + description: |
Do not need '|' unless you need to preserve formatting.
> + Active-low interrupt line. Asserted when the FIFO almost-full
> + threshold is reached or when a new PPG sample is ready.
> +
> + vdd-supply:
vdddig? Which supply is this?
> + description: Digital core power supply (1.8 V).
> +
> + avdd-supply:
I cannot find it in datasheet.
> + description: Analog core power supply (1.8 V).
> +
> + vref-supply:
> + description: ECG reference voltage supply.
> +
> + leds-supply:
Datasheet calls this VLED. Don't invent names.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8] arm64: dts: qcom: kodiak: Add EL2 overlay
From: Mukesh Ojha @ 2026-06-25 6:33 UTC (permalink / raw)
To: Miaoqing Pan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel, Sumit Garg
In-Reply-To: <8fbfa82f-aae7-48d6-9406-d04e719f028d@oss.qualcomm.com>
On Thu, Jun 25, 2026 at 09:14:41AM +0800, Miaoqing Pan wrote:
>
>
> On 6/24/2026 2:39 PM, Mukesh Ojha wrote:
> > All the existing variants Kodiak boards are using Gunyah hypervisor
> > which means that, so far, Linux-based OS could only boot in EL1 on those
> > devices. However, it is possible for us to boot Linux at EL2 on these
> > devices [1].
> >
> > When running under Gunyah, the remote processor firmware IOMMU
> > streams are controlled by Gunyah. However, without Gunyah, the IOMMU is
> > managed by the consumer of this DeviceTree. Therefore, describe the
> > firmware streams for each remote processor.
> >
> > Add a EL2-specific DT overlay and apply it to Kodiak IOT variant
> > devices to create -el2.dtb for each of them alongside "normal" dtb.
> >
> > Note that modem and media subsystems haven't been supported yet due
> > to missing dependencies. For GPU to work, zap shader is disabled and
> > in EL2 mode the kernel owns hardware watchdog which is enabled here.
> > And for wifi to work wpss copy engine memory need to be mapped for
> > WPSS firmware to work which is aligning with sc7280 chrome.
> >
> > [1]
> > https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi
> >
> > Co-developed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > ---
> > Changes in v8: https://lore.kernel.org/lkml/20260522115936.201208-2-sumit.garg@kernel.org/
> > - Added a wpss copy engine memory similar to chrome for Wifi to work.
> > - WPSS does not have firmware Stream, so that was removed.
> > - Added wifi streams similar to chrome for wifi to work.
> > - Removed this patch from Generic Pas patch series, can be followed
> > separately.
> > - Moved Sumit as co-author as part of modification done to the patch
> > in the past.
> > - Added some more kodiak's board variants in the makefile.
> >
> > Changes in v1-v7:
> > - mpss was disabled and will be enabled once the dependencies patches
> > get merged.
> >
> > arch/arm64/boot/dts/qcom/Makefile | 12 ++++++
> > arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 52 ++++++++++++++++++++++++
> > arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 +-
> > 3 files changed, 65 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> >
> > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > index 6f33c4e2f09c..d2cee1190954 100644
> > --- a/arch/arm64/boot/dts/qcom/Makefile
> > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > @@ -164,7 +164,11 @@ purwa-iot-evk-el2-dtbs := purwa-iot-evk.dtb x1-el2.dtbo
> > dtb-$(CONFIG_ARCH_QCOM) += purwa-iot-evk-el2.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcm6490-fairphone-fp5.dtb
> > +
> > dtb-$(CONFIG_ARCH_QCOM) += qcm6490-idp.dtb
> > +qcm6490-idp-el2-dtbs := qcm6490-idp.dtb kodiak-el2.dtbo
> > +dtb-$(CONFIG_ARCH_QCOM) += qcm6490-idp-el2.dtb
> > +
> > dtb-$(CONFIG_ARCH_QCOM) += qcm6490-particle-tachyon.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcm6490-shift-otter.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-1000.dtb
> > @@ -176,12 +180,20 @@ qcs615-ride-el2-dtbs := qcs615-ride.dtb talos-el2.dtbo
> > dtb-$(CONFIG_ARCH_QCOM) += qcs615-ride-el2.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-radxa-dragon-q6a.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> > +qcs6490-rb3gen2-el2-dtbs := qcs6490-rb3gen2.dtb kodiak-el2.dtbo
> > +dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-el2.dtb
> > qcs6490-rb3gen2-vision-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-vision-mezzanine.dtbo
> > qcs6490-rb3gen2-industrial-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-industrial-mezzanine.dtbo
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine.dtb
> > +qcs6490-rb3gen2-industrial-mezzanine-el2-dtbs := qcs6490-rb3gen2-industrial-mezzanine.dtb kodiak-el2.dtbo
> > +dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine-el2.dtb
> > +
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-vision-mezzanine.dtb
> > +qcs6490-rb3gen2-vision-mezzanine-el2-dtbs := qcs6490-rb3gen2-vision-mezzanine.dtb kodiak-el2.dtbo
> > +dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-vision-mezzanine-el2.dtb
> > +
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-thundercomm-minipc-g1iot.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-thundercomm-rubikpi3.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> > diff --git a/arch/arm64/boot/dts/qcom/kodiak-el2.dtso b/arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> > new file mode 100644
> > index 000000000000..91e4cda45b49
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> > @@ -0,0 +1,52 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> > + *
> > + * Kodiak specific modifications required to boot in EL2.
> > + */
> > +
> > +/dts-v1/;
> > +/plugin/;
> > +
> > +&gpu_zap_shader {
> > + status = "disabled";
> > +};
> > +
> > +&remoteproc_adsp {
> > + iommus = <&apps_smmu 0x1800 0x0>;
> > +};
> > +
> > +&remoteproc_cdsp {
> > + iommus = <&apps_smmu 0x11a0 0x0400>;
> > +};
> > +
> > +&remoteproc_mpss {
> > + status = "disabled";
> > +};
> > +
> > +&reserved_memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + wlan_ce_mem: wlan-ce@4cd000 {
> > + no-map;
> > + reg = <0x0 0x004cd000 0x0 0x1000>;
> > + };
> > +};
> > +
> Is it necessary to redefine |wlan_ce_mem|? Can we consider updating
> |qcs6490-rb3gen2.dts|?
> I have verified that with the following changes, *NON-KVM works fine*, and
> |wlan_ce_mem| is only used by the WCN6750 firmware.
Thanks for the review.
I was unsure about it, hence kept it as how Chrome kept it; I am
fine to keep as suggested as it seems to me these regions were
only needed for wifi-firmware mentioned, and we should not have deleted
it for qcs6490-rb3gen2.dts and idp too, will do the change that
will make this much cleaner.
>
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -26,7 +26,6 @@
> /delete-node/ &adsp_mem;
> /delete-node/ &cdsp_mem;
> /delete-node/ &video_mem;
> -/delete-node/ &wlan_ce_mem;
> /delete-node/ &wpss_mem;
> /delete-node/ &xbl_mem;
>
> @@ -1686,7 +1685,6 @@ &venus {
> };
>
> &wifi {
> - memory-region = <&wlan_fw_mem>;
> qcom,calibration-variant = "Qualcomm_rb3gen2";
>
>
> > +&venus {
> > + status = "disabled";
> > +};
> > +
> > +&watchdog {
> > + status = "okay";
> > +};
> > +
> > +&wifi {
> > + memory-region = <&wlan_fw_mem>, <&wlan_ce_mem>;
> > + status = "okay";
> > +
> > + wifi-firmware {
> > + iommus = <&apps_smmu 0x1c02 0x1>;
> > + };
> > +};
> > diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > index fa540d8c2615..2486d15fa2ba 100644
> > --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > @@ -91,7 +91,7 @@ sleep_clk: sleep-clk {
> > };
> > };
> > - reserved-memory {
> > + reserved_memory: reserved-memory {
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec device
From: Krzysztof Kozlowski @ 2026-06-25 6:28 UTC (permalink / raw)
To: Nas Chung
Cc: Conor Dooley, mchehab@kernel.org, hverkuil@xs4all.nl,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
linux-arm-kernel@lists.infradead.org, jackson.lee, lafley.kim,
marek.vasut@mailbox.org
In-Reply-To: <SL2P216MB2441BB9DC91CCBE494F2B45BFBEC2@SL2P216MB2441.KORP216.PROD.OUTLOOK.COM>
On Thu, Jun 25, 2026 at 01:43:33AM +0000, Nas Chung wrote:
> >> + sram:
> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >> + description:
> >> + phandle to the SRAM node used to store reference data, reducing DMA
> >> + memory bandwidth.
> >> +
> >> + iommus:
> >> + maxItems: 1
> >> +
> >> + "#cooling-cells":
> >> + const: 2
> >> +
> >> + "#address-cells":
> >> + const: 2
> >> +
> >> + "#size-cells":
> >> + const: 2
> >> +
> >> + ranges: true
> >> +
> >> +patternProperties:
> >> + "^interface@[0-9a-f]+$":
> >
> >I have to wonder if this interface business is required at all.
> >Why can this not go into the parent, with each region fetchable via
> >reg-names, interrupt-names and iommu-names?
>
> Thanks for your feedback.
>
> I did try the flat model, but the blocker is the IOMMU.
>
> The control region and four interface regions are independent DMA requesters
> with distinct stream IDs, and each interface can be assigned to a different VM,
> driving the video core with its own isolated memory.
>
> If all stream IDs are listed under the parent's iommus, they bind to a
> single device and share one domain, so the isolation is lost.
> This is the main reason I added the interface nodes.
Feels similar to issue Qualcomm has. I rejected such subnodes and
Qualcomm came with a solution in DMA IOMMU code, but that solution was
rejected by DMA folks:
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
I don't have proper arguments to convince DMA folks, thus I agree for
Qualcomm for the subnodes. It should be fine here as well, in such case.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: input: Add Qualcomm SPMI PMIC haptics
From: Krzysztof Kozlowski @ 2026-06-25 6:23 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260624-qcom-spmi-haptics-v2-1-b9118e60f3e3@oss.qualcomm.com>
On 25/06/2026 04:00, Fenglin Wu wrote:
> Add binding document for the haptics module inside Qualcomm PMIC
> PMIH0108.
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> .../bindings/input/qcom,spmi-haptics.yaml | 132 +++++++++++++++++++++
> 1 file changed, 132 insertions(+)
You did not test this before sending, therefore this fits in to AI slop
category. I do not accept AI slop to be sent to mailing list.
Best regards,
Krzysztof
^ 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