* Re: [PATCH v2 4/4] arm64: dts: qcom: x1e80100-dell-xps13-9345: introduce EC
From: Bryan O'Donoghue @ 2026-04-05 0:21 UTC (permalink / raw)
To: Aleksandrs Vinarskis, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans de Goede,
Ilpo Järvinen
Cc: linux-arm-msm, devicetree, linux-kernel, platform-driver-x86,
laurentiu.tudor1, Abel Vesa, Tobias Heider, Val Packett
In-Reply-To: <20260404-dell-xps-9345-ec-v2-4-c977c3caa81f@vinarskis.com>
On 04/04/2026 13:55, Aleksandrs Vinarskis wrote:
> + io-channel-names = "sys_therm0",
> + "sys_therm1",
> + "sys_therm2",
> + "sys_therm3",
> + "sys_therm4",
> + "sys_therm5",
> + "sys_therm6";
io-channels-names = "lpddr5x-therm", "charger-left-therm",
"charger-right-therm", "ssd-therm", "keyboard-therm"
> + };
> };
>
> &i2c7 {
> @@ -1025,6 +1050,64 @@ rtmr0_1p8_reg_en: rtmr0-1p8-reg-en-state {
> };
> };
>
> +&pmk8550_vadc {
> + /* Around DRAM */
> + channel@14c {
> + reg = <PM8350_ADC7_GPIO3_100K_PU(1)>;
> + qcom,hw-settle-time = <200>;
> + qcom,ratiometric;
> + label = "sys_therm0";
You might as well use the same name for the label "lpddr5-therm"
> + };
On thena the list is:
- "OPT temp"
- "CPU VR"
- "GPU VR"
- "Charging-1"
- "Charging-2"
- "WLAN"
- "WLAN (EE)"
So I think both the source and the sink should describe and be allowed
to describe what it is io-channel-names = "fixed list" is too restrictive.
Much more useful to userspace to see a string "lpddr5-therm" than
"sys_therm0".
---
bod
^ permalink raw reply
* Re: [PATCH v2 2/4] platform: arm64: dell-xps-ec: new driver
From: Bryan O'Donoghue @ 2026-04-05 0:29 UTC (permalink / raw)
To: Aleksandrs Vinarskis, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans de Goede,
Ilpo Järvinen
Cc: linux-arm-msm, devicetree, linux-kernel, platform-driver-x86,
laurentiu.tudor1, Abel Vesa, Tobias Heider, Val Packett
In-Reply-To: <20260404-dell-xps-9345-ec-v2-2-c977c3caa81f@vinarskis.com>
On 04/04/2026 13:55, Aleksandrs Vinarskis wrote:
> Introduce EC driver for Dell XPS 13 9345 (codename 'tributo') which may
> partially of fully compatible with Snapdragon-based Dell Latitude,
> Inspiron ('thena'). Primary function of this driver is unblock EC's
> thermal management, specifically to provide it with necessary
> information to control device fans, peripherals power.
>
> The driver was developed primarily by analyzing ACPI DSDT's _DSM and
> i2c dumps of communication between SoC and EC. Changes to Windows
> driver's behavior include increasing temperature feed loop from ~50ms
> to 100ms here.
>
> While Xps's EC is rather complex and controls practically all device
> peripherals including touch row's brightness and special keys such as
> mic mute, these do not go over this particular i2c interface.
>
> Not yet implemented features:
> - On lid-close IRQ event is registered. Windows performs what to
> appears to be thermistor constants readout, though its not obvious
> what it used for.
> - According to ACPI's _DSM there is a method to readout fans' RPM.
> - Initial thermistor constants were sniffed from Windows, these can be
> likely fine tuned for better cooling performance.
> - There is additional temperature reading that Windows sents to EC but
> more rare than others, likely SoC T_j / TZ98 or TZ4. This is the only
> thermal zone who's reading can exceed 115C without triggering thermal
> shutdown.
> - Given similarities between 'tributo' and 'thena' platforms, including
> EC i2c address, driver can be potentially extended to support both.
>
> Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> ---
> MAINTAINERS | 1 +
> drivers/platform/arm64/Kconfig | 12 ++
> drivers/platform/arm64/Makefile | 1 +
> drivers/platform/arm64/dell-xps-ec.c | 267 +++++++++++++++++++++++++++++++++++
> 4 files changed, 281 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a5d175559f4468dfe363b319a1b08d3425f4d712..c150f57b60706224e5b24b0dfb3d8a9b81f36398 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7240,6 +7240,7 @@ DELL XPS EMBEDDED CONTROLLER DRIVER
> M: Aleksandrs Vinarskis <alex@vinarskis.com>
> S: Maintained
> F: Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
> +F: drivers/platform/arm64/dell-xps-ec.c
>
> DELTA AHE-50DC FAN CONTROL MODULE DRIVER
> M: Zev Weiss <zev@bewilderbeest.net>
> diff --git a/drivers/platform/arm64/Kconfig b/drivers/platform/arm64/Kconfig
> index 10f905d7d6bfa5fad30a0689d3a20481268c781e..0bc8f016032bb05cb3a7cc50bdf1092da04153bc 100644
> --- a/drivers/platform/arm64/Kconfig
> +++ b/drivers/platform/arm64/Kconfig
> @@ -33,6 +33,18 @@ config EC_ACER_ASPIRE1
> laptop where this information is not properly exposed via the
> standard ACPI devices.
>
> +config EC_DELL_XPS
> + tristate "Dell XPS 9345 Embedded Controller driver"
> + depends on ARCH_QCOM || COMPILE_TEST
> + depends on I2C
> + depends on IIO
> + help
> + Driver for the Embedded Controller in the Qualcomm Snapdragon-based
> + Dell XPS 13 9345, which handles thermal management and fan speed
> + control.
> +
> + Say M or Y here to include this support.
> +
> config EC_HUAWEI_GAOKUN
> tristate "Huawei Matebook E Go Embedded Controller driver"
> depends on ARCH_QCOM || COMPILE_TEST
> diff --git a/drivers/platform/arm64/Makefile b/drivers/platform/arm64/Makefile
> index 60c131cff6a15bb51a49c9edab95badf513ee0f6..6768dc6c2310837374e67381cfc729bed1fdaaef 100644
> --- a/drivers/platform/arm64/Makefile
> +++ b/drivers/platform/arm64/Makefile
> @@ -6,6 +6,7 @@
> #
>
> obj-$(CONFIG_EC_ACER_ASPIRE1) += acer-aspire1-ec.o
> +obj-$(CONFIG_EC_DELL_XPS) += dell-xps-ec.o
> obj-$(CONFIG_EC_HUAWEI_GAOKUN) += huawei-gaokun-ec.o
> obj-$(CONFIG_EC_LENOVO_YOGA_C630) += lenovo-yoga-c630.o
> obj-$(CONFIG_EC_LENOVO_THINKPAD_T14S) += lenovo-thinkpad-t14s.o
> diff --git a/drivers/platform/arm64/dell-xps-ec.c b/drivers/platform/arm64/dell-xps-ec.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..bf1495fbe473ccdb82b95a66b56e8525f782cc8e
> --- /dev/null
> +++ b/drivers/platform/arm64/dell-xps-ec.c
> @@ -0,0 +1,267 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2026, Aleksandrs Vinarskis <alex@vinarskis.com>
> + */
> +
> +#include <linux/array_size.h>
> +#include <linux/dev_printk.h>
> +#include <linux/device.h>
> +#include <linux/devm-helpers.h>
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/iio/consumer.h>
> +#include <linux/interrupt.h>
> +#include <linux/jiffies.h>
> +#include <linux/module.h>
> +#include <linux/pm.h>
> +#include <linux/unaligned.h>
> +#include <linux/workqueue.h>
> +
> +#define DELL_XPS_EC_SUSPEND_CMD 0xb9
> +#define DELL_XPS_EC_SUSPEND_MSG_LEN 64
> +
> +#define DELL_XPS_EC_TEMP_CMD0 0xfb
> +#define DELL_XPS_EC_TEMP_CMD1 0x20
> +#define DELL_XPS_EC_TEMP_CMD3 0x02
> +#define DELL_XPS_EC_TEMP_MSG_LEN 6
> +#define DELL_XPS_EC_TEMP_POLL_JIFFIES msecs_to_jiffies(100)
> +
> +/*
> + * Format:
> + * - header/unknown (2 bytes)
> + * - per-thermistor entries (3 bytes): thermistor_id, param1, param2
> + */
> +static const u8 dell_xps_ec_thermistor_profile[] = {
> + 0xff, 0x54,
> + 0x01, 0x00, 0x2b, /* sys_therm0 */
> + 0x02, 0x44, 0x2a, /* sys_therm1 */
> + 0x03, 0x44, 0x2b, /* sys_therm2 */
> + 0x04, 0x44, 0x28, /* sys_therm3 */
> + 0x05, 0x55, 0x2a, /* sys_therm4 */
> + 0x06, 0x44, 0x26, /* sys_therm5 */
> + 0x07, 0x44, 0x2b, /* sys_therm6 */
> +};
> +
> +/*
> + * Mapping from IIO channel name to EC command byte
> + */
> +static const struct {
> + const char *name;
> + u8 cmd;
> +} dell_xps_ec_therms[] = {
> + /* TODO: 0x01 is sent only occasionally, likely TZ98 or TZ4 */
> + { "sys_therm0", 0x02 },
> + { "sys_therm1", 0x03 },
> + { "sys_therm2", 0x04 },
> + { "sys_therm3", 0x05 },
> + { "sys_therm4", 0x06 },
> + { "sys_therm5", 0x07 },
> + { "sys_therm6", 0x08 },
> +};
You could probably retrieve these strings from the dt if you really need
them.
I don't think you need static consts in your driver though you could
just as easily do `sprintf("sys_therm%d\n", i) where you use
ec_therms[i].name - the name is only used to print errors and you have
the index of the channel when you do.
It would be nicer to get the strings from DT - certainly make the string
names mandatory but, then let the DT specify those names.
Either that or just do the sprintf("sys_therm%d\n", i); for the index,
whichever you wish yourself.
> +
> +struct dell_xps_ec {
> + struct device *dev;
> + struct i2c_client *client;
> + struct iio_channel *therm_channels[ARRAY_SIZE(dell_xps_ec_therms)];
> + struct delayed_work temp_work;
> +};
> +
> +static int dell_xps_ec_suspend_cmd(struct dell_xps_ec *ec, bool suspend)
> +{
> + u8 buf[DELL_XPS_EC_SUSPEND_MSG_LEN] = {};
> + int ret;
> +
> + buf[0] = DELL_XPS_EC_SUSPEND_CMD;
> + buf[1] = suspend ? 0x01 : 0x00;
> + /* bytes 2..63 remain zero */
> +
> + ret = i2c_master_send(ec->client, buf, sizeof(buf));
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int dell_xps_ec_send_temp(struct dell_xps_ec *ec, u8 cmd_byte,
> + int milli_celsius)
> +{
> + u8 buf[DELL_XPS_EC_TEMP_MSG_LEN];
> + u16 deci_celsius;
> + int ret;
> +
> + /* Convert milli-Celsius to deci-Celsius (Celsius * 10) */
> + deci_celsius = milli_celsius / 100;
> +
> + buf[0] = DELL_XPS_EC_TEMP_CMD0;
> + buf[1] = DELL_XPS_EC_TEMP_CMD1;
> + buf[2] = cmd_byte;
> + buf[3] = DELL_XPS_EC_TEMP_CMD3;
> + put_unaligned_le16(deci_celsius, &buf[4]);
> +
> + ret = i2c_master_send(ec->client, buf, sizeof(buf));
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static void dell_xps_ec_temp_work_fn(struct work_struct *work)
> +{
> + struct dell_xps_ec *ec = container_of(work, struct dell_xps_ec,
> + temp_work.work);
> + int val, ret, i;
> +
> + for (i = 0; i < ARRAY_SIZE(dell_xps_ec_therms); i++) {
> + if (!ec->therm_channels[i])
> + continue;
> +
> + ret = iio_read_channel_processed(ec->therm_channels[i], &val);
> + if (ret < 0) {
> + dev_err_ratelimited(ec->dev,
> + "Failed to read thermistor %s: %d\n",
> + dell_xps_ec_therms[i].name, ret);
> + continue;
> + }
> +
> + ret = dell_xps_ec_send_temp(ec, dell_xps_ec_therms[i].cmd, val);
> + if (ret < 0) {
> + dev_err_ratelimited(ec->dev,
> + "Failed to send temp for %s: %d\n",
> + dell_xps_ec_therms[i].name, ret);
> + }
> + }
> +
> + schedule_delayed_work(&ec->temp_work, DELL_XPS_EC_TEMP_POLL_JIFFIES);
> +}
> +
> +static irqreturn_t dell_xps_ec_irq_handler(int irq, void *data)
> +{
> + struct dell_xps_ec *ec = data;
> +
> + /*
> + * TODO: IRQ is fired on lid-close. Follow Windows example to read out
> + * the thermistor thresholds and potentially fan speeds.
> + */
> + dev_info_ratelimited(ec->dev, "IRQ triggered! (irq=%d)\n", irq);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int dell_xps_ec_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + struct dell_xps_ec *ec;
> + int ret, i;
> +
> + ec = devm_kzalloc(dev, sizeof(*ec), GFP_KERNEL);
> + if (!ec)
> + return -ENOMEM;
> +
> + ec->dev = dev;
> + ec->client = client;
> + i2c_set_clientdata(client, ec);
> +
> + /* Set default thermistor profile */
> + ret = i2c_master_send(client, dell_xps_ec_thermistor_profile,
> + sizeof(dell_xps_ec_thermistor_profile));
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "Failed to set thermistor profile\n");
> +
> + /* Get IIO channels for thermistors */
> + for (i = 0; i < ARRAY_SIZE(dell_xps_ec_therms); i++) {
> + ec->therm_channels[i] =
> + devm_iio_channel_get(dev, dell_xps_ec_therms[i].name);
> + if (IS_ERR(ec->therm_channels[i])) {
> + ret = PTR_ERR(ec->therm_channels[i]);
> + ec->therm_channels[i] = NULL;
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + dev_warn(dev, "Thermistor %s not available: %d\n",
> + dell_xps_ec_therms[i].name, ret);
> + }
> + }
> +
> + /* Start periodic temperature reporting */
> + ret = devm_delayed_work_autocancel(dev, &ec->temp_work,
> + dell_xps_ec_temp_work_fn);
> + if (ret)
> + return ret;
\n
> + schedule_delayed_work(&ec->temp_work, DELL_XPS_EC_TEMP_POLL_JIFFIES);
> + dev_dbg(dev, "Started periodic temperature reporting to EC every %d ms\n",
> + jiffies_to_msecs(DELL_XPS_EC_TEMP_POLL_JIFFIES));
> +
> + /* Request IRQ for EC events */
> + ret = devm_request_threaded_irq(dev, client->irq, NULL,
> + dell_xps_ec_irq_handler,
> + IRQF_ONESHOT, dev_name(dev), ec);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "Failed to request IRQ\n");
> +
> + return 0;
> +}
> +
> +/*
> + * Notify EC of suspend
> + *
> + * This will:
> + * - Cut power to display/trackpad/keyboard/touchrow, wake-up source still works
> + */
> +static int dell_xps_ec_suspend(struct device *dev)
> +{
> + struct dell_xps_ec *ec = dev_get_drvdata(dev);
> +
> + cancel_delayed_work_sync(&ec->temp_work);
> +
> + return dell_xps_ec_suspend_cmd(ec, true);
> +}
> +
> +/*
> + * Notify EC of resume
> + *
> + * This will undo the suspend actions
> + * Without the resume signal, device would wake up but be forced back into
> + * suspend by EC within seconds
> + */
> +static int dell_xps_ec_resume(struct device *dev)
> +{
> + struct dell_xps_ec *ec = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = dell_xps_ec_suspend_cmd(ec, false);
> + if (ret)
> + return ret;
> +
> + schedule_delayed_work(&ec->temp_work, DELL_XPS_EC_TEMP_POLL_JIFFIES);
> + return 0;
> +}
> +
> +static const struct of_device_id dell_xps_ec_of_match[] = {
> + { .compatible = "dell,xps13-9345-ec" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, dell_xps_ec_of_match);
> +
> +static const struct i2c_device_id dell_xps_ec_i2c_id[] = {
> + { "dell-xps-ec" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, dell_xps_ec_i2c_id);
> +
> +static const struct dev_pm_ops dell_xps_ec_pm_ops = {
> + SYSTEM_SLEEP_PM_OPS(dell_xps_ec_suspend, dell_xps_ec_resume)
> +};
> +
> +static struct i2c_driver dell_xps_ec_driver = {
> + .driver = {
> + .name = "dell-xps-ec",
> + .of_match_table = dell_xps_ec_of_match,
> + .pm = &dell_xps_ec_pm_ops,
> + },
> + .probe = dell_xps_ec_probe,
> + .id_table = dell_xps_ec_i2c_id,
> +};
> +module_i2c_driver(dell_xps_ec_driver);
> +
> +MODULE_AUTHOR("Aleksandrs Vinarskis <alex@vinarskis.com>");
> +MODULE_DESCRIPTION("Dell XPS 13 9345 Embedded Controller");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [PATCH 6/7] arm64: dts: qcom: sm8750: Correct and complete DP address spaces
From: Dmitry Baryshkov @ 2026-04-05 2:08 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kuogee Hsieh, Neil Armstrong,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260402-dts-qcom-display-regs-v1-6-daa54ab448a3@oss.qualcomm.com>
On Thu, Apr 02, 2026 at 01:45:17PM +0200, Krzysztof Kozlowski wrote:
> DisplayPort block on Qualcomm SM8750 has few too short address space
> ranges and misses four more spaces. Complete the hardware description,
> which in the future might be important for full feature support.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> dtbs_check success depends on the binding change (first commit).
> ---
> arch/arm64/boot/dts/qcom/sm8750.dtsi | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: Devicetree spec: Specifying /cpus/cpu@* unit address format?
From: David Gibson @ 2026-04-05 4:43 UTC (permalink / raw)
To: Vivian Wang
Cc: devicetree-spec, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Alexandre Ghiti, Chen Wang,
Inochi Amaoto, devicetree, linux-riscv, sophgo
In-Reply-To: <00ddad5a-02f5-474e-af9c-11ce7716ddfc@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Fri, Apr 03, 2026 at 06:06:17PM +0800, Vivian Wang wrote:
> (Also posted at: https://github.com/devicetree-org/devicetree-specification/issues/86 )
>
> Hi all,
>
> Presently, there seems to be some confusion in the community about the
> format of unit addresses for "/cpus/cpu@*" nodes for a CPU with ID > 9, e.g.
>
> cpu@??? {
> reg = <10>;
> /* reg = <0xa>; */ /* This should be equivalent */
> }
>
>
> Should this be a decimal "cpu@10", or hexadecimal "cpu@a"? I can't find
> any explicit specification.
It should be hex. That's a general convention for unit addresses.
Before flattened trees, OF essentially never used decimal
representations of things.
--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/9] driver core: Fix some race conditions
From: Greg Kroah-Hartman @ 2026-04-05 5:27 UTC (permalink / raw)
To: Douglas Anderson
Cc: Rafael J . Wysocki, Danilo Krummrich, Alan Stern, Saravana Kannan,
Christoph Hellwig, Eric Dumazet, Johan Hovold, Leon Romanovsky,
Alexander Lobakin, Alexey Kardashevskiy, Robin Murphy,
Andrew Morton, Frank.Li, Jason Gunthorpe, alex, alexander.stein,
andre.przywara, andrew, andrew, andriy.shevchenko, aou, ardb,
bhelgaas, brgl, broonie, catalin.marinas, chleroy, davem, david,
devicetree, dmaengine, driver-core, gbatra, gregory.clement,
hkallweit1, iommu, jirislaby, joel, joro, kees, kevin.brodsky,
kuba, lenb, lgirdwood, linux-acpi, linux-arm-kernel, linux-aspeed,
linux-cxl, linux-kernel, linux-mips, linux-mm, linux-pci,
linux-riscv, linux-serial, linux-snps-arc, linux-usb, linux,
linuxppc-dev, m.szyprowski, maddy, mani, maz, miko.lenczewski,
mpe, netdev, npiggin, osalvador, oupton, pabeni, palmer,
peter.ujfalusi, peterz, pjw, robh, sebastian.hesselbarth, tglx,
tsbogend, vgupta, vkoul, will, willy, yangyicong, yeoreum.yun
In-Reply-To: <20260404000644.522677-1-dianders@chromium.org>
On Fri, Apr 03, 2026 at 05:04:54PM -0700, Douglas Anderson wrote:
> NOTE: one potentially "controversial" choice I made in some patches
> was to always reserve a flag ID even if a flag is only used under
> certain CONFIG_ settings. This is a change from how things were
> before. Keeping the numbering consistent and allowing easy
> compile-testing of both CONFIG settings seemed worth it, especially
> since it won't take up any extra space until we've added a lot more
> flags.
Nah, this is fine, I don't see any problems with this as the original
code kind of was doing the same thing with the "hole" in the structure
if those options were not enabled.
> I only marked the first patch as a "Fix" since it is the only one
> fixing observed problems. Other patches could be considered fixes too
> if folks want.
>
> I tested the first patch in the series backported to kernel 6.6 on the
> Pixel phone that was experiencing the race. I added extra printouts to
> make sure that the problem was hitting / addressed. The rest of the
> patches are tested with allmodconfig with arm32, arm64, ppc, and
> x86. I boot tested on an arm64 Chromebook running mainline.
I'm guessing your tests passed? :)
Anyway, this looks great, unless there are any objections, other than
the "needs to be undefined", which a follow-on patch can handle, I'll
queue them up next week for 7.1-rc1.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/7] dt-bindings: display/msm: dp-controller: Allow DAI on SM8650
From: Krzysztof Kozlowski @ 2026-04-05 6:54 UTC (permalink / raw)
To: Dmitry Baryshkov, Krzysztof Kozlowski
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kuogee Hsieh, Neil Armstrong,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel
In-Reply-To: <ozofiq5dwk7luisfa6a4e4wbqw4vuvcs2h463hqxt7uee4aod3@j7aslgp4hkn3>
On 05/04/2026 00:04, Dmitry Baryshkov wrote:
> On Thu, Apr 02, 2026 at 01:45:13PM +0200, Krzysztof Kozlowski wrote:
>> DisplayPort on Qualcomm SM8650 (and compatible SM8750) supports audio
>> and there is DTS already having cells and sound-name-prefix. Add SM8650
>> to the list of SoCs referencing the dai-common.yaml schema to solve
>> dtbs_check warnings like:
>>
>> sm8650-hdk-display-card-rear-camera-card.dtb:
>> displayport-controller@af54000 (qcom,sm8650-dp): Unevaluated properties are not allowed ('sound-name-prefix' was unexpected)
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> ---
>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>> index e4f17d29343b..f8daaee8d065 100644
>> --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>> +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>> @@ -210,6 +210,7 @@ allOf:
>> enum:
>> - qcom,glymur-dp
>> - qcom,sa8775p-dp
>> + - qcom,sm8650-dp
>> - qcom,x1e80100-dp
>> then:
>> $ref: /schemas/sound/dai-common.yaml#
>
> This clause is for the platforms which can work either with the eDP
> (aux-bus) or DP (sound-dai-cells) setup. Instead please extend the else
> clause to $ref dai-common.yaml.
OK, this binding is not getting readable...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: PCI: mediatek: Add support for EcoNet EN7528
From: Krzysztof Kozlowski @ 2026-04-05 7:03 UTC (permalink / raw)
To: Caleb James DeLisle
Cc: linux-pci, linux-mips, naseefkm, ryder.lee, helgaas, lpieralisi,
kwilczynski, mani, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, ansuelsmth, linux-mediatek, devicetree,
linux-kernel
In-Reply-To: <20260404182854.2183651-2-cjd@cjdns.fr>
On Sat, Apr 04, 2026 at 06:28:53PM +0000, Caleb James DeLisle wrote:
> Introduce EcoNet EN7528 SoC compatible in MediaTek PCIe controller
> binding.
>
> EcoNet PCIe controller has the same configuration model as
> Mediatek v2 but is initialized more similarly to an MT7621
> PCIe.
>
<form letter>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here. However, there's no
need to repost patches *only* to add the tags. The upstream maintainer
will do that for tags received on the version they apply.
Please read:
https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state in the patch changelog
or cover letter why and what changed.
</form letter>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 01/13] dt-bindings: soc: starfive: Add StarFive JHB100 syscon modules
From: Krzysztof Kozlowski @ 2026-04-05 7:17 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, linux-kernel, devicetree, linux-riscv, Ley Foon Tan
In-Reply-To: <20260403054945.467700-2-changhuang.liang@starfivetech.com>
On Thu, Apr 02, 2026 at 10:49:33PM -0700, Changhuang Liang wrote:
> Add documentation to describe StarFive JHB100 SoC System Controller
> Registers.
>
> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> ---
> .../soc/starfive/starfive,jhb100-syscon.yaml | 140 ++++++++++++++++++
> MAINTAINERS | 5 +
> 2 files changed, 145 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-syscon.yaml
>
> diff --git a/Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-syscon.yaml b/Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-syscon.yaml
> new file mode 100644
> index 000000000000..c0e1f6f68fa2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-syscon.yaml
> @@ -0,0 +1,140 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/starfive/starfive,jhb100-syscon.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: StarFive JHB100 SoC system controller
> +
> +maintainers:
> + - Kevin Xie <kevin.xie@starfivetech.com>
> + - Changhuang Liang <changhuang.liang@starfivetech.com>
> +
> +description:
> + The StarFive JHB100 SoC system controller provides register information such
> + as offset, mask and shift to configure related modules such as PLL and PCIe.
How a MMIO based device can provide a MMIO information? What exactly
does it provide? Register where the value is the offset of other
register?
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - starfive,jhb100-pcierp-syscon
> + - starfive,jhb100-per0-syscon
> + - starfive,jhb100-per1-syscon
> + - starfive,jhb100-sys0-syscon
> + - const: syscon
> + - const: simple-mfd
> + - items:
> + - enum:
> + - starfive,jhb100-b2h-syscon
> + - starfive,jhb100-gpu-syscon
> + - starfive,jhb100-h2b-syscon
> + - starfive,jhb100-host-syscon
> + - starfive,jhb100-husb-syscon
> + - starfive,jhb100-husbcmn-syscon
> + - starfive,jhb100-husbd-syscon
> + - starfive,jhb100-npu-syscon
> + - starfive,jhb100-pcieep-ecsr-syscon
> + - starfive,jhb100-pcierp-ecsr-syscon
> + - starfive,jhb100-per2-syscon
> + - starfive,jhb100-per3-syscon
Hm? per2 as starfive,jhb100-per2crg is a separate device, so how can it
be also a syscon?
> + - starfive,jhb100-strap-syscon
> + - starfive,jhb100-sys1-syscon
> + - starfive,jhb100-sys2-syscon
> + - starfive,jhb100-usb-syscon
> + - starfive,jhb100-vout-syscon
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> + clock-controller:
> + $ref: /schemas/clock/starfive,jhb100-pll.yaml#
> + type: object
Why are you mixing MMIO and non-MMIO devices here/
> +
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 2
> +
> + ranges: true
> +
> +required:
> + - compatible
> + - reg
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - starfive,jhb100-per0-syscon
> + - starfive,jhb100-per1-syscon
> + - starfive,jhb100-sys0-syscon
> + then:
> + required:
> + - clock-controller
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: starfive,jhb100-sys0-syscon
> + then:
> + required:
> + - "#address-cells"
> + - "#size-cells"
> + - ranges
> + patternProperties:
> + "^chipid@[0-9a-f]+$":
> + $ref: /schemas/hwinfo/starfive,jhb100-socinfo.yaml#
> + type: object
> +
> +
Just one blank line
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: starfive,jhb100-pcierp-syscon
> + then:
> + required:
> + - "#address-cells"
> + - "#size-cells"
> + - ranges
> + patternProperties:
> + "^reset-controller@[0-9a-f]+$":
> + $ref: /schemas/reset/starfive,jhb100-reset-pcierp.yaml#
There is no such file so nothing here is testable or even possible to
apply.
Following my first question, I don't understand why this is even a
child.
Anyway, properties must be defined in top-level.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 02/13] dt-bindings: clock: Add system-0 domain PLL clock
From: Krzysztof Kozlowski @ 2026-04-05 7:18 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, linux-kernel, devicetree, linux-riscv, Ley Foon Tan
In-Reply-To: <20260403054945.467700-3-changhuang.liang@starfivetech.com>
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?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 00/13] Add StarFive JHB100 syscon modules
From: Krzysztof Kozlowski @ 2026-04-05 7:18 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, linux-kernel, devicetree, linux-riscv, Ley Foon Tan
In-Reply-To: <20260403054945.467700-1-changhuang.liang@starfivetech.com>
On Thu, Apr 02, 2026 at 10:49:32PM -0700, Changhuang Liang wrote:
> StarFive JHB100 has many syscon modules, as listed below:
> - pcieep0_ecsr_syscon (PCIe endpoint 0 externel syscon)
> - pcieep1_ecsr_syscon
> - host0_syscon (Host0 syscon)
> - host1_syscon
> - husb0_syscon (Host USB 0 syscon)
> - husb1_syscon
> - husbd0_syscon (Host USB device 0 syscon)
> - husbd1_syscon
> - husbcmn_syscon (Host USB common)
> - gpu0_syscon (GPU0 syscon)
> - gpu1_syscon
> - b2h0_syscon (BMC to Host0 syscon)
> - b2h1_syscon (BMC to Host1 syscon)
> - h02b_syscon (Host0 to BMC syscon)
> - h12b_syscon (Host1 to BMC syscon)
> - vout_syscon (Video output syscon)
> - pcierp_ecsr_syscon (PCIe root port externel syscon)
> - pcierp_syscon (PCIe root port syscon)
> - usb_syscon
> - npu_syscon
> - per0_syscon (Peripheral 0 syscon)
> - per1_syscon
> - per2_syscon
> - per3_syscon
> - sys0_syscon (System 0 syscon)
> - sys1_syscon
> - sys2_syscon
> - strap_syscon
>
> Some syscon modules contain PLL, reset, and socinfo nodes
> This series will add these syscon modules, as well as the
> nodes under them.
>
> -PATCH 1: syscon binging
> -PATCH 2-7: syscon PLL driver
> -PATCH 8-10: syscon reset driver
> -PATCH 11-12: syscon socinfo driver
> -PATCH 13: syscon device tree
>
> This series depends on the series:
> https://lore.kernel.org/all/20260402105523.447523-1-changhuang.liang@starfivetech.com/
So nothing is testable here and I am sure there are obvious build issues
(already spotted one).
I won't be reviewing it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 11/13] dt-bindings: hwinfo: Add starfive,jhb100-socinfo
From: Krzysztof Kozlowski @ 2026-04-05 7:19 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, linux-kernel, devicetree, linux-riscv, Ley Foon Tan
In-Reply-To: <20260403054945.467700-12-changhuang.liang@starfivetech.com>
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.yaml b/Documentation/devicetree/bindings/hwinfo/starfive,jhb100-socinfo.yaml
> 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.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: clock: Add ESWIN eic7700 HSP clock and reset generator
From: Krzysztof Kozlowski @ 2026-04-05 7:24 UTC (permalink / raw)
To: dongxuyang
Cc: mturquette, sboyd, robh, krzk+dt, conor+dt, linux-clk, devicetree,
linux-kernel, p.zabel, huangyifeng, ningyu, linmin,
pinkesh.vaghela
In-Reply-To: <20260403093548.670-1-dongxuyang@eswincomputing.com>
On Fri, Apr 03, 2026 at 05:35:48PM +0800, dongxuyang@eswincomputing.com wrote:
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: HSP configuration top clock
> + - description: MMC top clock
> + - description: SATA top clock
> +
> + clock-names:
> + items:
> + - const: hsp_cfg
> + - const: hsp_mmc
> + - const: hsp_sata
Drop hsp_ everywhere
> +
> + '#clock-cells':
> + const: 1
> + description:
> + See <dt-bindings/clock/eswin,eic7700-hspcrg.h> for valid indices.
> +
> + '#reset-cells':
> + const: 1
> + description:
> + See <dt-bindings/reset/eswin,eic7700-hspcrg.h> for valid indices.
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - '#clock-cells'
> + - '#reset-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + clock-controller@50440000 {
> + compatible = "eswin,eic7700-hspcrg";
> + reg = <0x50440000 0x2000>;
> + clocks = <&clock 171>, <&clock 254>, <&clock 187>;
> + clock-names = "hsp_cfg", "hsp_mmc", "hsp_sata";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 76e91d47d2f4..bcbb9578c043 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9506,8 +9506,11 @@ M: Yifeng Huang <huangyifeng@eswincomputing.com>
> M: Xuyang Dong <dongxuyang@eswincomputing.com>
> S: Maintained
> F: Documentation/devicetree/bindings/clock/eswin,eic7700-clock.yaml
> +F: Documentation/devicetree/bindings/clock/eswin,eic7700-hspcrg.yaml
> F: drivers/clk/eswin/
> F: include/dt-bindings/clock/eswin,eic7700-clock.h
> +F: include/dt-bindings/clock/eswin,eic7700-hspcrg.h
Why this cannot be eswin,eic7700* pattern in each directory?
> +F: include/dt-bindings/reset/eswin,eic7700-hspcrg.h
>
> ET131X NETWORK DRIVER
> M: Mark Einon <mark.einon@gmail.com>
> diff --git a/include/dt-bindings/clock/eswin,eic7700-hspcrg.h b/include/dt-bindings/clock/eswin,eic7700-hspcrg.h
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: opp-v2: Fix example 3 CPU reg value
From: Krzysztof Kozlowski @ 2026-04-05 7:27 UTC (permalink / raw)
To: Vivian Wang
Cc: Viresh Kumar, Nishanth Menon, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Viresh Kumar, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20260403-dt-bindings-opp-v2-hex-cpu-reg-v1-1-38a4968ab515@iscas.ac.cn>
On Fri, Apr 03, 2026 at 06:34:29PM +0800, Vivian Wang wrote:
> Example 3 is a dual-cluster example, meaning that the CPU nodes should
> have reg values 0x0, 0x1, 0x100, 0x101. The example incorrectly uses
> decimal 0, 1, 100, 101 instead, which seems unintended. Use the correct
> hexadecimal values.
>
> Even though the value doesn't change for the first two CPUs, 0 and 1 in
> example 3 are changed to 0x0 and 0x1 respectively for consistency. Other
> examples all have reg less than 10, so they have not been changed.
>
> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: sound: renesas,fsi: Add support for multiple clocks
From: Krzysztof Kozlowski @ 2026-04-05 7:32 UTC (permalink / raw)
To: phucduc.bui
Cc: kuninori.morimoto.gx, broonie, lgirdwood, robh, krzk+dt, conor+dt,
geert+renesas, magnus.damm, perex, tiwai, linux-sound,
linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20260403112655.167593-2-phucduc.bui@gmail.com>
On Fri, Apr 03, 2026 at 06:26:53PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> The FSI on r8a7740 requires the SPU clock to be enabled
> before accessing its registers.
> Without this clock, register access may lead to a system
> hang.
> Add support for the "spu" clock so it can be managed by
> the driver.
> The binding is also extended to allow additional clocks,
> as FSIB may require more clock inputs, while FSIA
> typically uses fewer.
Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
And not after every sentece, BTW.
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
> .../devicetree/bindings/sound/renesas,fsi.yaml | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
> index df91991699a7..225cd8d369bb 100644
> --- a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
> +++ b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
> @@ -38,7 +38,11 @@ properties:
> maxItems: 1
>
> clocks:
> - maxItems: 1
> + minItems: 1
> + maxItems: 8
Needs valid descriptions.
> +
> + clock-names:
> + description: List of necessary clock names.
Instead constrain it. See also writing-bindings, writing-schema or
example-schema documents.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: pinctrl: describe the TLMM controller on Qualcomm Nord platforms
From: Krzysztof Kozlowski @ 2026-04-05 7:38 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Bartosz Golaszewski, Shawn Guo,
Arnd Bergmann, linux-arm-msm, linux-gpio, devicetree,
linux-kernel
In-Reply-To: <20260403-nord-tlmm-v1-1-4864f400c700@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 03:27:55PM +0200, Bartosz Golaszewski wrote:
> Add a DT binding document describing the TLMM pin controller available
> on the Nord platforms from Qualcomm.
That's the first time name Nord appears on the lists (except OnePlus
Nord!) and I do not see soc-info with explanation. I know what the Nord
is, but others might not, and if I complain to other patchsets that way
I should complain also here.
The easiest is to send soc-info patch with explanations before this one.
>
> Co-developed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> .../bindings/pinctrl/qcom,nord-tlmm.yaml | 206 +++++++++++++++++++++
> 1 file changed, 206 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,nord-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,nord-tlmm.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..b1fdaa24a045469e3dec512ce0200f240daa1959
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,nord-tlmm.yaml
> @@ -0,0 +1,206 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pinctrl/qcom,nord-tlmm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Technologies, Inc. Nord TLMM block
> +
> +maintainers:
> + - Bartosz Golaszewski <brgl@kernel.org>
> +
> +description: |
Drop |
> + Top Level Mode Multiplexer pin controller in Qualcomm Nord SoC.
> +
> +allOf:
> + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
> +
> +properties:
> + compatible:
> + const: qcom,nord-tlmm
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + gpio-reserved-ranges:
> + minItems: 1
> + maxItems: 74
I guess rather 90 (half of gpios could be reserved in theory...)
> +
> + gpio-line-names:
> + maxItems: 180
pattern in "pins" says 181 gpios.
> +
> +patternProperties:
> + "-state$":
> + oneOf:
> + - $ref: "#/$defs/qcom-nord-tlmm-state"
> + - patternProperties:
> + "-pins$":
> + $ref: "#/$defs/qcom-nord-tlmm-state"
> + additionalProperties: false
> +
> +$defs:
> + qcom-nord-tlmm-state:
> + type: object
> + description:
> + Pinctrl node's client devices use subnodes for desired pin configuration.
> + Client device subnodes use below standard properties.
> + $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
> + unevaluatedProperties: false
> +
> + properties:
> + pins:
> + description:
> + List of gpio pins affected by the properties specified in this
> + subnode.
> + items:
> + oneOf:
> + - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-7][0-9]|180])$"
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/3] arm64: defconfig: enable the Qualcomm Nord TLMM driver
From: Krzysztof Kozlowski @ 2026-04-05 7:39 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Bartosz Golaszewski, Shawn Guo,
Arnd Bergmann, linux-arm-msm, linux-gpio, devicetree,
linux-kernel
In-Reply-To: <20260403-nord-tlmm-v1-3-4864f400c700@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 03:27:57PM +0200, Bartosz Golaszewski wrote:
> This is required to boot linux on the Nord platforms from Qualcomm.
Which upstream board uses it? Can be board which you are currently
upstreaming (posted DTS).
Otherwise I do not see point why upstream would care about defconfig for
non-upstream DTS.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] pinctrl: qcom: add the TLMM driver for the Nord platforms
From: Krzysztof Kozlowski @ 2026-04-05 7:41 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Bartosz Golaszewski, Shawn Guo,
Arnd Bergmann, linux-arm-msm, linux-gpio, devicetree,
linux-kernel
In-Reply-To: <20260403-nord-tlmm-v1-2-4864f400c700@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 03:27:56PM +0200, Bartosz Golaszewski wrote:
> Add support for the TLMM controller on the Qualcomm Nord platform.
>
> Co-developed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> drivers/pinctrl/qcom/Kconfig.msm | 7 +
> drivers/pinctrl/qcom/Makefile | 1 +
> drivers/pinctrl/qcom/pinctrl-nord.c | 3297 +++++++++++++++++++++++++++++++++++
> 3 files changed, 3305 insertions(+)
>
> diff --git a/drivers/pinctrl/qcom/Kconfig.msm b/drivers/pinctrl/qcom/Kconfig.msm
> index 6df6159fa5f89f9f0470e700b4698dc8849ed515..6698e2a50b2f67b1aadb4a840339e769c92f95f8 100644
> --- a/drivers/pinctrl/qcom/Kconfig.msm
> +++ b/drivers/pinctrl/qcom/Kconfig.msm
> @@ -261,6 +261,13 @@ config PINCTRL_SA8775P
> This is the pinctrl, pinmux and pinconf driver for the Qualcomm
> TLMM block found on the Qualcomm SA8775P platforms.
>
> +config PINCTRL_NORD
N goes after M, so probably after PINCTRL_MSM8998
Don't take Milos as an example...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: clock: qcom: Document the Nord SoC TCSR Clock Controller
From: Krzysztof Kozlowski @ 2026-04-05 7:44 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Taniya Das,
Richard Cochran, Shawn Guo, Deepti Jaggi, linux-arm-msm,
linux-clk, devicetree, linux-kernel, netdev
In-Reply-To: <20260403-nord-clks-v1-1-018af14979fd@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 04:10:49PM +0200, Bartosz Golaszewski wrote:
> From: Taniya Das <taniya.das@oss.qualcomm.com>
>
> The Nord SoC TCSR block provides CLKREF clocks for DP, PCIe, UFS, SGMII
> and USB.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> [Shawn: Use compatible qcom,nord-tcsrcc rather than qcom,nord-tcsr]
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> .../bindings/clock/qcom,sm8550-tcsr.yaml | 2 ++
> include/dt-bindings/clock/qcom,nord-tcsrcc.h | 26 ++++++++++++++++++++++
> 2 files changed, 28 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/7] dt-bindings: clock: qcom-rpmhcc: Add support for Nord SoCs
From: Krzysztof Kozlowski @ 2026-04-05 7:45 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Taniya Das,
Richard Cochran, Shawn Guo, Deepti Jaggi, linux-arm-msm,
linux-clk, devicetree, linux-kernel, netdev
In-Reply-To: <20260403-nord-clks-v1-2-018af14979fd@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 04:10:50PM +0200, Bartosz Golaszewski wrote:
> From: Taniya Das <taniya.das@oss.qualcomm.com>
>
> Add bindings and update documentation compatible for RPMh clock
> controller on Nord SoC.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: clock: qcom: Add Nord Global Clock Controller
From: Krzysztof Kozlowski @ 2026-04-05 7:46 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Taniya Das,
Richard Cochran, Shawn Guo, Deepti Jaggi, linux-arm-msm,
linux-clk, devicetree, linux-kernel, netdev
In-Reply-To: <20260403-nord-clks-v1-3-018af14979fd@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 04:10:51PM +0200, Bartosz Golaszewski wrote:
> From: Taniya Das <taniya.das@oss.qualcomm.com>
>
> Add device tree bindings for the global clock controller on Qualcomm
> Nord platform. The global clock controller on Nord SoC is divided into
> multiple clock controllers (GCC,SE_GCC,NE_GCC and NW_GCC). Add each of
> the bindings to define the clock controllers.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> .../devicetree/bindings/clock/qcom,nord-gcc.yaml | 58 ++++++++
> .../devicetree/bindings/clock/qcom,nord-negcc.yaml | 60 +++++++++
> .../devicetree/bindings/clock/qcom,nord-nwgcc.yaml | 55 ++++++++
> include/dt-bindings/clock/qcom,nord-gcc.h | 147 +++++++++++++++++++++
> include/dt-bindings/clock/qcom,nord-negcc.h | 124 +++++++++++++++++
> include/dt-bindings/clock/qcom,nord-nwgcc.h | 69 ++++++++++
> include/dt-bindings/clock/qcom,nord-segcc.h | 98 ++++++++++++++
> 7 files changed, 611 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
From: Krzysztof Kozlowski @ 2026-04-05 7:52 UTC (permalink / raw)
To: Andrea della Porta
Cc: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov
In-Reply-To: <11b5eee3c22cfd034bb4b425d28a5a3ff2a71828.1775223441.git.andrea.porta@suse.com>
On Fri, Apr 03, 2026 at 04:31:54PM +0200, Andrea della Porta wrote:
> +required:
> + - compatible
> + - reg
> + - clocks
> +
Missing ref to pwm.yaml.
> +additionalProperties: false
and this should be unevaluatedProperties. See other files.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: broadcom: rp1: Add PWM node
From: Krzysztof Kozlowski @ 2026-04-05 7:53 UTC (permalink / raw)
To: Andrea della Porta
Cc: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov
In-Reply-To: <ef79e974c6680202294a4cfde7cc791753bf1b3e.1775223441.git.andrea.porta@suse.com>
On Fri, Apr 03, 2026 at 04:31:56PM +0200, Andrea della Porta wrote:
> +
> &rp1_usb0 {
> pinctrl-0 = <&usb_vbus_default_state>;
> pinctrl-names = "default";
> diff --git a/arch/arm64/boot/dts/broadcom/rp1-common.dtsi b/arch/arm64/boot/dts/broadcom/rp1-common.dtsi
> index 5a815c3797945..7e78501e62b0c 100644
> --- a/arch/arm64/boot/dts/broadcom/rp1-common.dtsi
> +++ b/arch/arm64/boot/dts/broadcom/rp1-common.dtsi
> @@ -56,6 +56,16 @@ rp1_eth: ethernet@40100000 {
> #size-cells = <0>;
> };
>
> + rp1_pwm: pwm@4009c000 {
Don't break the order. Instead please read and follow DTS coding style.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: sram: qcom,imem: Add the Milos compatible
From: Krzysztof Kozlowski @ 2026-04-05 7:54 UTC (permalink / raw)
To: Luca Weiss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, ~postmarketos/upstreaming, phone-devel,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260403-milos-imem-v1-1-4244ebb47017@fairphone.com>
On Fri, Apr 03, 2026 at 05:00:23PM +0200, Luca Weiss wrote:
> Add compatible for Milos SoC IMEM.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> index c63026904061..38488e28a6b4 100644
> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> @@ -19,6 +19,7 @@ properties:
> - enum:
> - qcom,apq8064-imem
> - qcom,ipq5424-imem
> + - qcom,milos-imem
Wasn't this imem binding supposed to stop growing and switch to a
different style?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: qcom: Add Xiaomi Poco F1 Tianma variant bindings
From: Krzysztof Kozlowski @ 2026-04-05 7:55 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, Petr Hodina, linux-arm-msm, devicetree, linux-kernel,
phone-devel
In-Reply-To: <20260403-beryllium-compat-string-v1-1-0a6b9cb55a20@ixit.cz>
On Fri, Apr 03, 2026 at 06:55:33PM +0200, David Heidelberg wrote:
> Add documentation for Tianma display and touchscreen variant.
>
> While at it, correct binding documentation expectation.
What expectation? What exactly did you corrected that you claim this is
a fix?
>
> Fixes: 341fdef8ea49 ("dt-bindings: arm: qcom: Add Xiaomi Poco F1 EBBG variant bindings")
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: qcom: Add Xiaomi Poco F1 Tianma variant bindings
From: David Heidelberg @ 2026-04-05 8:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Marijn Suijten, Casey Connolly, Joel Selvaraj,
Jens Reidel, Petr Hodina, linux-arm-msm, devicetree, linux-kernel,
phone-devel
In-Reply-To: <20260405-truthful-fat-angelfish-ec3e45@quoll>
On 05/04/2026 09:55, Krzysztof Kozlowski wrote:
> On Fri, Apr 03, 2026 at 06:55:33PM +0200, David Heidelberg wrote:
>> Add documentation for Tianma display and touchscreen variant.
>>
>> While at it, correct binding documentation expectation.
>
> What expectation? What exactly did you corrected that you claim this is
> a fix?
I would say the missing Tianma variant, which been with us for some time. The
follow up commit fixes the missing compatible and order, thus it would make
sense to me have also the dt-bindings part backported and fixed.
I agree I don't have strong case here. Should I drop the tag, keep it or replace
it with Cc: stable@vger.kernel.org?
David
>
>>
>> Fixes: 341fdef8ea49 ("dt-bindings: arm: qcom: Add Xiaomi Poco F1 EBBG variant bindings")
>
>
> Best regards,
> Krzysztof
>
--
David Heidelberg
^ 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