* Re: [PATCH v3 2/2] hwmon: add AMD Promontory 21 xHCI temperature sensor support
From: Guenter Roeck @ 2026-05-08 13:12 UTC (permalink / raw)
To: Jihong Min, Jihong Min
Cc: Greg Kroah-Hartman, Mathias Nyman, Jonathan Corbet, Shuah Khan,
Mario Limonciello, Basavaraj Natikar, linux-usb, linux-hwmon,
linux-doc, linux-pci, linux-kernel
In-Reply-To: <16c4f7e5-e33d-4271-a7af-5d6c7fca0570@icloud.com>
On 5/7/26 22:42, Jihong Min wrote:
> I believe I have addressed the other review comments for v4, including the
> remaining discussion from v2 2/2, your comments, and Mathias's suggestion to
> move the PROM21-specific xHCI PCI handling into a separate glue driver.
>
> I agree that "prom21_hwmon" is not a good name.
>
> I think just "prom21" may also be too broad, because Promontory 21 is a
> chipset/IP block with multiple I/O functions. This driver monitors the
> temperature value exposed through the PROM21 xHCI PCI function's MMIO BAR, so
> the xHCI part should probably be visible in the hwmon naming.
>
> I am considering:
>
> - drivers/hwmon/prom21-xhci.c
> - CONFIG_SENSORS_PROM21_XHCI
> - hwmon name: prom21_xhci
>
> while keeping the USB glue as xhci-pci-prom21.c.
>
> Does that sound reasonable?
>
Yes.
Please note that you keep top-posting. I don't mind that much, but
top-posting is (sometimes strongly) discouraged for linux kernel discussions.
Thanks,
Guenter
> Sincerely,
> Jihong Min
>
> On 5/8/26 00:53, Guenter Roeck wrote:
>> On Thu, May 07, 2026 at 12:31:59PM +0900, Jihong Min wrote:
>>> PROM21 xHCI controllers expose an 8-bit temperature value through a
>>> vendor-specific index/data register pair in the xHCI PCI MMIO BAR
>>> region. Add an auxiliary hwmon driver for PROM21 controllers with PCI
>>> ID 1022:43fd.
>>>
>>> PROM21 is an AMD chipset IP used in single-chip or daisy-chained
>>> configurations to build AMD 6xx/8xx series chipsets.
>>>
>>> The vendor index register is at byte offset 0x3000 from the xHCI MMIO
>>> BAR base and the vendor data register is at byte offset 0x3008. The
>>> driver writes register selector 0x0001e520 to the index register, reads
>>> the raw temperature value from the low 8 bits of the data register, and
>>> restores the previous index before returning. Expose temp1_input and an
>>> xHCI label through hwmon.
>>>
>>> Register the hwmon device under the parent PCI function so userspace
>>> reports it as a PCI adapter, while the auxiliary driver still owns the
>>> hwmon lifetime and unregisters it from the auxiliary remove path.
>>>
>>> No public AMD reference is available for this value. The conversion
>>> formula is derived from observed temperature readings:
>>>
>>> temp[C] = raw * 0.9066 - 78.624
>>>
>>> Testing showed that the temperature register does not return a valid
>>> value while the xHCI PCI function is runtime suspended. By default, the
>>> driver does not wake the parent PCI device from hwmon reads and returns
>>> -EPERM while the device is suspended.
>> Seriously ? Why would this be a permission issue ? Make it -ENODATA.
>>
>>> Document the supported device, register access, conversion formula,
>>> module parameter, sysfs attributes, and sysfs lookup method.
>>>
>>> Assisted-by: Codex:gpt-5.5
>>> Signed-off-by: Jihong Min <hurryman2212@gmail.com>
>>> ---
>>> Documentation/hwmon/index.rst | 1 +
>>> Documentation/hwmon/prom21-hwmon.rst | 86 ++++++++
>>> drivers/hwmon/Kconfig | 11 +
>>> drivers/hwmon/Makefile | 1 +
>>> drivers/hwmon/prom21-hwmon.c | 293 +++++++++++++++++++++++++++
>>> 5 files changed, 392 insertions(+)
>>> create mode 100644 Documentation/hwmon/prom21-hwmon.rst
>>> create mode 100644 drivers/hwmon/prom21-hwmon.c
>>>
>>> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
>>> index 8b655e5d6b68..41072977f0ef 100644
>>> --- a/Documentation/hwmon/index.rst
>>> +++ b/Documentation/hwmon/index.rst
>>> @@ -216,6 +216,7 @@ Hardware Monitoring Kernel Drivers
>>> pmbus
>>> powerz
>>> powr1220
>>> + prom21-hwmon
>>> pt5161l
>>> pxe1610
>>> pwm-fan
>>> diff --git a/Documentation/hwmon/prom21-hwmon.rst b/Documentation/hwmon/prom21-hwmon.rst
>>> new file mode 100644
>>> index 000000000000..0ba763e68ae9
>>> --- /dev/null
>>> +++ b/Documentation/hwmon/prom21-hwmon.rst
>>> @@ -0,0 +1,86 @@
>>> +.. SPDX-License-Identifier: GPL-2.0
>>> +
>>> +Kernel driver prom21-hwmon
>>> +==========================
>>> +
>>> +Supported chips:
>>> +
>>> + * AMD Promontory 21 (PROM21) xHCI
>>> +
>>> + Prefix: 'prom21_hwmon'
>> The "hwmon" in this name is redundant. Yes, I know, others like it too,
>> but it is still redundant. I won't comment on it further, though.
>>
>>> +
>>> + PCI ID: 1022:43fd
>>> +
>>> +Author:
>>> +
>>> + - Jihong Min <hurryman2212@gmail.com>
>>> +
>>> +Description
>>> +-----------
>>> +
>>> +This driver exposes the temperature sensor in AMD PROM21 xHCI controllers.
>>> +
>>> +The driver binds to an auxiliary device created by the xHCI PCI driver for
>>> +supported controllers. The sensor value is accessed through a vendor-specific
>>> +index/data register pair in the controller's PCI MMIO BAR.
>>> +
>>> +PROM21 is an AMD chipset IP used in single-chip or daisy-chained configurations
>>> +to build AMD 6xx/8xx series chipsets. Since the xHCI controllers are
>>> +integrated in PROM21, this temperature can also be used as a monitor for a
>>> +temperature close to the AMD chipset temperature.
>>> +
>>> +Register access
>>> +---------------
>>> +
>>> +The temperature value is read through a vendor-specific index/data register
>>> +pair in the xHCI PCI MMIO BAR. The driver uses the following byte offsets from
>>> +the MMIO BAR base:
>>> +
>>> +======================= =====================================================
>>> +0x3000 Vendor index register
>>> +0x3008 Vendor data register
>>> +======================= =====================================================
>>> +
>>> +The driver saves the current vendor index register value, writes the
>>> +temperature selector ``0x0001e520`` to the vendor index register, reads the
>>> +vendor data register, and restores the previous vendor index value before
>>> +returning. The raw temperature value is the low 8 bits of the vendor data
>>> +register value.
>>> +
>>> +No public AMD reference is available for the raw value. The temperature
>>> +conversion formula is derived from observed PROM21 xHCI temperature readings:
>>> +
>>> + temp[C] = raw * 0.9066 - 78.624
>>> +
>>> +Module parameters
>>> +-----------------
>>> +
>>> +pm: bool
>>> + Allow runtime PM state changes for device memory access. This is disabled
>>> + by default. If disabled, the driver does not wake the xHCI PCI device from
>>> + a temperature read. It reads the temperature only when the device is active.
>>> + A read from a suspended device returns ``-EPERM``.
>>> +
>>> +Sysfs entries
>>> +-------------
>>> +
>>> +======================= =====================================================
>>> +temp1_input Temperature in millidegrees Celsius
>>> +temp1_label "xHCI"
>> This is pointless and not the idea behind having a "label" attribute.
>> The driver name itself already associates the sensor with xhci.
>> Please drop.
>>
>>> +======================= =====================================================
>>> +
>>> +The hwmon device name is ``prom21_hwmon``. The sysfs path depends on the hwmon
>>> +device number assigned by the kernel. Userspace can locate the device by
>>> +matching the ``name`` attribute:
>>> +
>>> +.. code-block:: sh
>>> +
>>> + for hwmon in /sys/class/hwmon/hwmon*; do
>>> + [ "$(cat "$hwmon/name")" = "prom21_hwmon" ] || continue
>>> + cat "$hwmon/temp1_label"
>>> + cat "$hwmon/temp1_input"
>>> + done
>>> +
>>> +``temp1_input`` reports millidegrees Celsius, so a value of ``50113`` means
>>> +50.113 degrees Celsius. If the raw register value is invalid, ``temp1_input``
>>> +returns ``-ENODATA``.
>>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>>> index 14e4cea48acc..06d81cc29fec 100644
>>> --- a/drivers/hwmon/Kconfig
>>> +++ b/drivers/hwmon/Kconfig
>>> @@ -940,6 +940,17 @@ config SENSORS_POWERZ
>>> This driver can also be built as a module. If so, the module
>>> will be called powerz.
>>> +config SENSORS_PROM21
>>> + tristate "AMD Promontory 21 xHCI temperature sensor"
>>> + depends on USB_XHCI_PCI
>>> + select USB_XHCI_PCI_AUXDEV
>>> + help
>>> + If you say yes here you get support for the AMD Promontory 21
>>> + (PROM21) xHCI temperature sensor.
>>> +
>>> + This driver can also be built as a module. If so, the module
>>> + will be called prom21-hwmon.
>>> +
>>> config SENSORS_POWR1220
>>> tristate "Lattice POWR1220 Power Monitoring"
>>> depends on I2C
>>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
>>> index 4788996aa137..7693ed3b3f72 100644
>>> --- a/drivers/hwmon/Makefile
>>> +++ b/drivers/hwmon/Makefile
>>> @@ -196,6 +196,7 @@ obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
>>> obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
>>> obj-$(CONFIG_SENSORS_POWERZ) += powerz.o
>>> obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
>>> +obj-$(CONFIG_SENSORS_PROM21) += prom21-hwmon.o
>>> obj-$(CONFIG_SENSORS_PT5161L) += pt5161l.o
>>> obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
>>> obj-$(CONFIG_SENSORS_QNAP_MCU_HWMON) += qnap-mcu-hwmon.o
>>> diff --git a/drivers/hwmon/prom21-hwmon.c b/drivers/hwmon/prom21-hwmon.c
>>> new file mode 100644
>>> index 000000000000..1c137304d65d
>>> --- /dev/null
>>> +++ b/drivers/hwmon/prom21-hwmon.c
>>> @@ -0,0 +1,293 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * AMD PROM21 xHCI Hwmon Implementation
>>> + * (only temperature monitoring is supported)
>>> + *
>>> + * This can be effectively used as the alternative chipset temperature monitor.
>>> + *
>>> + * Copyright (C) 2026 Jihong Min <hurryman2212@gmail.com>
>>> + */
>>> +
>>> +#include <linux/auxiliary_bus.h>
>>> +#include <linux/device.h>
>>> +#include <linux/err.h>
>>> +#include <linux/errno.h>
>>> +#include <linux/hwmon.h>
>>> +#include <linux/io.h>
>>> +#include <linux/math.h>
>>> +#include <linux/module.h>
>>> +#include <linux/mutex.h>
>>> +#include <linux/pci.h>
>>> +#include <linux/pm_runtime.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/usb.h>
>>> +#include <linux/usb/hcd.h>
>>> +
>>> +#define PROM21_INDEX 0x3000
>>> +#define PROM21_DATA 0x3008
>>> +#define PROM21_TEMP_REG 0x0001e520
>>> +
>>> +#define PROM21_HWMON_NAME "prom21_hwmon"
>>> +#define PROM21_TEMP_LABEL "xHCI"
>>> +
>>> +struct prom21_hwmon {
>>> + struct pci_dev *pdev;
>>> + struct device *hwmon_dev;
>>> + void __iomem *regs;
>>> + bool removing;
>>> + struct mutex lock; /* protects removing and the index/data registers */
>> It is difficult to believe that auxiliary device management is so unstable
>> that it needs all that complexity. This will require confirmation from
>> someone who knows how this is supposed to work, and a detailed explanation
>> in the driver explaining why it is necessary.
>>
>>> +};
>>> +
>>> +static bool pm;
>>> +module_param(pm, bool, 0444);
>>> +MODULE_PARM_DESC(pm, "Allow runtime PM state changes for device memory access");
>> No. Either enable it or don't, but please don't add such module parameters.
>> The pm complexity in the driver, as written, makes it all but impossible
>> to determine what is going on.
>>
>>> +
>>> +static void prom21_hwmon_invalidate(struct prom21_hwmon *hwmon)
>>> +{
>>> + mutex_lock(&hwmon->lock);
>>> + hwmon->removing = true;
>>> + mutex_unlock(&hwmon->lock);
>>> +}
>>> +
>>> +static int prom21_hwmon_pm_get(struct prom21_hwmon *hwmon, bool *pm_ref)
>>> +{
>>> + struct device *dev = &hwmon->pdev->dev;
>>> + int ret;
>>> +
>>> + *pm_ref = false;
>>> +
>>> + /*
>>> + * PROM21 temperature register access does not return a valid value while
>>> + * the parent xHCI PCI function is suspended. By default, only read when
>>> + * runtime PM reports the device as active, or when runtime PM is disabled
>>> + * and the device is not marked as suspended. If pm=Y, allow runtime PM
>>> + * state changes while accessing the temperature register.
>>> + */
>>> + if (pm) {
>>> + ret = pm_runtime_resume_and_get(dev);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + *pm_ref = true;
>>> + return 0;
>>> + }
>>> +
>>> + ret = pm_runtime_get_if_active(dev);
>>> + if (ret > 0) {
>>> + *pm_ref = true;
>>> + return 0;
>>> + }
>>> +
>>> + if (ret == -EINVAL && !pm_runtime_status_suspended(dev))
>>> + return 0;
>>> +
>>> + if (!ret || pm_runtime_status_suspended(dev))
>>> + return -EPERM;
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +/*
>>> + * This is not a pure MMIO read. The PROM21 vendor data register is selected
>>> + * by temporarily writing PROM21_TEMP_REG to the vendor index register. Keep
>>> + * the sequence short and restore the previous index before returning.
>>> + */
>>> +static int prom21_hwmon_read_temp_raw_restore_index(struct prom21_hwmon *hwmon,
>>> + u8 *raw)
>>> +{
>>> + struct device *dev = &hwmon->pdev->dev;
>>> + bool pm_ref;
>>> + u32 index;
>>> + u32 data;
>>> + int ret;
>>> +
>>> + /*
>>> + * The xHCI PCI remove path destroys the auxiliary device before HCD
>>> + * teardown. Keep runtime PM and MMIO inside the critical section so a
>>> + * sysfs read cannot use the vendor register pair after remove starts.
>>> + */
>>> + mutex_lock(&hwmon->lock);
>>> + if (hwmon->removing) {
>>> + mutex_unlock(&hwmon->lock);
>>> + return -ENODEV;
>>> + }
>>> +
>>> + ret = prom21_hwmon_pm_get(hwmon, &pm_ref);
>>> + if (ret) {
>>> + mutex_unlock(&hwmon->lock);
>>> + return ret;
>>> + }
>>> +
>>> + index = readl(hwmon->regs + PROM21_INDEX);
>>> + /* Select the PROM21 temperature register through the vendor index. */
>>> + writel(PROM21_TEMP_REG, hwmon->regs + PROM21_INDEX);
>>> + data = readl(hwmon->regs + PROM21_DATA);
>>> + /* Restore the previous vendor index register value. */
>>> + writel(index, hwmon->regs + PROM21_INDEX);
>>> + readl(hwmon->regs + PROM21_INDEX);
>>> +
>>> + if (pm_ref) {
>>> + /*
>>> + * Use autosuspend so repeated sysfs reads do not suspend the
>>> + * controller immediately after each successful register access.
>>> + */
>>> + pm_runtime_mark_last_busy(dev);
>>> + pm_runtime_put_autosuspend(dev);
>>> + }
>>> + mutex_unlock(&hwmon->lock);
>>> +
>>> + *raw = data & 0xff;
>>> + if (!*raw || *raw == 0xff)
>>> + return -ENODATA;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static long prom21_hwmon_raw_to_millicelsius(u8 raw)
>>> +{
>>> + /*
>>> + * No public AMD reference is available for this value.
>>> + * The scale was derived from observed PROM21 xHCI temperature readings:
>>> + * temp[C] = raw * 0.9066 - 78.624
>>> + */
>>> + return DIV_ROUND_CLOSEST(raw * 9066, 10) - 78624;
>>> +}
>>> +
>>> +static umode_t prom21_hwmon_is_visible(const void *drvdata,
>>> + enum hwmon_sensor_types type, u32 attr,
>>> + int channel)
>>> +{
>>> + if (type != hwmon_temp || channel)
>>> + return 0;
>>> +
>>> + switch (attr) {
>>> + case hwmon_temp_input:
>>> + case hwmon_temp_label:
>>> + return 0444;
>>> + default:
>>> + return 0;
>>> + }
>>> +}
>>> +
>>> +static int prom21_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
>>> + u32 attr, int channel, long *val)
>>> +{
>>> + struct prom21_hwmon *hwmon = dev_get_drvdata(dev);
>>> + u8 raw;
>>> + int ret;
>>> +
>>> + if (type != hwmon_temp || attr != hwmon_temp_input || channel)
>>> + return -EOPNOTSUPP;
>>> +
>>> + ret = prom21_hwmon_read_temp_raw_restore_index(hwmon, &raw);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + *val = prom21_hwmon_raw_to_millicelsius(raw);
>>> + return 0;
>>> +}
>>> +
>>> +static int prom21_hwmon_read_string(struct device *dev,
>>> + enum hwmon_sensor_types type, u32 attr,
>>> + int channel, const char **str)
>>> +{
>>> + if (type != hwmon_temp || attr != hwmon_temp_label || channel)
>>> + return -EOPNOTSUPP;
>>> +
>>> + *str = PROM21_TEMP_LABEL;
>>> + return 0;
>>> +}
>>> +
>>> +static const struct hwmon_ops prom21_hwmon_ops = {
>>> + .is_visible = prom21_hwmon_is_visible,
>>> + .read = prom21_hwmon_read,
>>> + .read_string = prom21_hwmon_read_string,
>>> +};
>>> +
>>> +static const struct hwmon_channel_info *const prom21_hwmon_info[] = {
>>> + HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_LABEL),
>>> + NULL,
>>> +};
>>> +
>>> +static const struct hwmon_chip_info prom21_hwmon_chip_info = {
>>> + .ops = &prom21_hwmon_ops,
>>> + .info = prom21_hwmon_info,
>>> +};
>>> +
>>> +static int prom21_hwmon_probe(struct auxiliary_device *auxdev,
>>> + const struct auxiliary_device_id *id)
>>> +{
>>> + struct device *dev = &auxdev->dev;
>>> + struct device *parent = dev->parent;
>>> + struct prom21_hwmon *hwmon;
>>> + struct pci_dev *pdev;
>>> + struct usb_hcd *hcd;
>>> + int ret;
>>> +
>>> + if (!parent || !dev_is_pci(parent))
>>> + return -ENODEV;
>>> +
>>> + pdev = to_pci_dev(parent);
>>> + hcd = pci_get_drvdata(pdev);
>>> + if (!hcd)
>>> + return dev_err_probe(dev, -ENODEV,
>>> + "xHCI HCD data unavailable\n");
>>> +
>>> + if (!hcd->regs || hcd->rsrc_len < PROM21_DATA + sizeof(u32))
>>> + return dev_err_probe(dev, -ENODEV, "invalid MMIO resource\n");
>>> +
>>> + hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
>>> + if (!hwmon)
>>> + return -ENOMEM;
>>> +
>>> + ret = devm_mutex_init(dev, &hwmon->lock);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + hwmon->pdev = pdev;
>>> + hwmon->regs = hcd->regs;
>>> + auxiliary_set_drvdata(auxdev, hwmon);
>>> +
>>> + /*
>>> + * Use the PCI function as the hwmon parent so user space reports it as
>>> + * a PCI adapter. Lifetime is still owned by this auxiliary driver;
>>> + * remove() unregisters the hwmon device before xhci-pci tears down the
>>> + * HCD.
>>> + */
>>> + hwmon->hwmon_dev =
>>> + hwmon_device_register_with_info(&pdev->dev, PROM21_HWMON_NAME,
>>> + hwmon, &prom21_hwmon_chip_info,
>>> + NULL);
>>> + if (IS_ERR(hwmon->hwmon_dev))
>>> + return PTR_ERR(hwmon->hwmon_dev);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static void prom21_hwmon_remove(struct auxiliary_device *auxdev)
>>> +{
>>> + struct prom21_hwmon *hwmon = auxiliary_get_drvdata(auxdev);
>>> +
>>> + if (hwmon) {
>>> + prom21_hwmon_invalidate(hwmon);
>>> + hwmon_device_unregister(hwmon->hwmon_dev);
>>> + }
>>> +}
>>> +
>>> +static const struct auxiliary_device_id prom21_hwmon_id_table[] = {
>>> + { .name = "xhci_pci." PROM21_HWMON_NAME },
>>> + {}
>>> +};
>>> +MODULE_DEVICE_TABLE(auxiliary, prom21_hwmon_id_table);
>>> +
>>> +static struct auxiliary_driver prom21_hwmon_driver = {
>>> + .name = "prom21-hwmon",
>>> + .probe = prom21_hwmon_probe,
>>> + .remove = prom21_hwmon_remove,
>>> + .id_table = prom21_hwmon_id_table,
>>> +};
>>> +module_auxiliary_driver(prom21_hwmon_driver);
>>> +
>>> +MODULE_AUTHOR("Jihong Min <hurryman2212@gmail.com>");
>>> +MODULE_DESCRIPTION("AMD PROM21 xHCI hwmon driver");
>>> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH 1/3] Documentation/gpu: add dedicated documentation for Intel display
From: Rodrigo Vivi @ 2026-05-08 13:15 UTC (permalink / raw)
To: Jani Nikula
Cc: intel-gfx, intel-xe, dri-devel, linux-doc, Matthew Brost,
Thomas Hellström, joonas.lahtinen, tursulin
In-Reply-To: <21bfa7777eb0926eadd309d4c6f5c9cf48405cf0.1778235406.git.jani.nikula@intel.com>
On Fri, May 08, 2026 at 01:20:47PM +0300, Jani Nikula wrote:
> Nowadays, the display support for drm/i915 and drm/xe is shared between
> the drivers, even though the code is located under drm/i915/display.
>
> The drm/i915 documentation has everything, including display topics, in
> one huge page, while the drm/xe documentation is well-organized but
> hardly mentions display. It's not great, to put it mildly.
>
> Split out the Intel display documentation to a dedicated directory,
> Documentation/gpu/intel-display. Also directly split the
> functionality/feature documentation to dedicated pages to keep the main
> index page high level and readable. We'll want to organize this further,
> but just sort them alphabetically for starters.
>
> Drop the boilerplate documentation sections that don't actually document
> anything.
>
> Cross-reference drm/i915, drm/xe, and intel-display.
>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>
> ---
>
> Tip: 'git show --color-moved' conveniently highlights what gets moved
> and what gets deleted.
> ---
> Documentation/gpu/drivers.rst | 1 +
> Documentation/gpu/drm-kms.rst | 3 +
> Documentation/gpu/i915.rst | 202 +-----------------
> .../gpu/intel-display/async-flip.rst | 8 +
> Documentation/gpu/intel-display/audio.rst | 23 ++
> Documentation/gpu/intel-display/cdclk.rst | 11 +
> Documentation/gpu/intel-display/dmc.rst | 26 +++
> Documentation/gpu/intel-display/dpio.rst | 8 +
> Documentation/gpu/intel-display/dpll.rst | 14 ++
> Documentation/gpu/intel-display/drrs.rst | 11 +
> Documentation/gpu/intel-display/dsb.rst | 11 +
> Documentation/gpu/intel-display/fbc.rst | 11 +
> .../gpu/intel-display/fifo-underrun.rst | 11 +
> .../gpu/intel-display/frontbuffer.rst | 14 ++
> Documentation/gpu/intel-display/hotplug.rst | 11 +
> Documentation/gpu/intel-display/index.rst | 40 ++++
> Documentation/gpu/intel-display/plane.rst | 11 +
> Documentation/gpu/intel-display/psr.rst | 11 +
> Documentation/gpu/intel-display/vbt.rst | 14 ++
> Documentation/gpu/xe/index.rst | 5 +
> 20 files changed, 251 insertions(+), 195 deletions(-)
> create mode 100644 Documentation/gpu/intel-display/async-flip.rst
> create mode 100644 Documentation/gpu/intel-display/audio.rst
> create mode 100644 Documentation/gpu/intel-display/cdclk.rst
> create mode 100644 Documentation/gpu/intel-display/dmc.rst
> create mode 100644 Documentation/gpu/intel-display/dpio.rst
> create mode 100644 Documentation/gpu/intel-display/dpll.rst
> create mode 100644 Documentation/gpu/intel-display/drrs.rst
> create mode 100644 Documentation/gpu/intel-display/dsb.rst
> create mode 100644 Documentation/gpu/intel-display/fbc.rst
> create mode 100644 Documentation/gpu/intel-display/fifo-underrun.rst
> create mode 100644 Documentation/gpu/intel-display/frontbuffer.rst
> create mode 100644 Documentation/gpu/intel-display/hotplug.rst
> create mode 100644 Documentation/gpu/intel-display/index.rst
> create mode 100644 Documentation/gpu/intel-display/plane.rst
> create mode 100644 Documentation/gpu/intel-display/psr.rst
> create mode 100644 Documentation/gpu/intel-display/vbt.rst
>
> diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst
> index 2e13e0ad7e88..20d2c454aa1d 100644
> --- a/Documentation/gpu/drivers.rst
> +++ b/Documentation/gpu/drivers.rst
> @@ -8,6 +8,7 @@ GPU Driver Documentation
> amdgpu/index
> i915
> imagination/index
> + intel-display/index
> mcde
> meson
> nouveau
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index fbe0583eb84c..a125052f46bc 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -1,3 +1,6 @@
> +
> +.. _drm-kms:
> +
> =========================
> Kernel Mode Setting (KMS)
> =========================
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index eba09c3ddce4..0c9d68758533 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -1,3 +1,6 @@
> +
> +.. _drm/i915:
> +
> ===========================
> drm/i915 Intel GFX Driver
> ===========================
> @@ -7,6 +10,9 @@ models) integrated GFX chipsets with both Intel display and rendering
> blocks. This excludes a set of SoC platforms with an SGX rendering unit,
> those have basic support through the gma500 drm driver.
>
> +The display, or :ref:`drm-kms`, support for drm/i915 is provided by
> +:ref:`drm/intel-display`, and shared with :ref:`drm/xe <drm/xe>`.
> +
> Core Driver Infrastructure
> ==========================
>
> @@ -64,200 +70,6 @@ Workarounds
> .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c
> :doc: Hardware workarounds
>
> -Display Hardware Handling
> -=========================
> -
> -This section covers everything related to the display hardware including
> -the mode setting infrastructure, plane, sprite and cursor handling and
> -display, output probing and related topics.
> -
> -Mode Setting Infrastructure
> ----------------------------
> -
> -The i915 driver is thus far the only DRM driver which doesn't use the
> -common DRM helper code to implement mode setting sequences. Thus it has
> -its own tailor-made infrastructure for executing a display configuration
> -change.
> -
> -Frontbuffer Tracking
> ---------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c
> - :doc: frontbuffer tracking
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.h
> - :internal:
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c
> - :internal:
> -
> -Display FIFO Underrun Reporting
> --------------------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c
> - :doc: fifo underrun handling
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c
> - :internal:
> -
> -Plane Configuration
> --------------------
> -
> -This section covers plane configuration and composition with the primary
> -plane, sprites, cursors and overlays. This includes the infrastructure
> -to do atomic vsync'ed updates of all this state and also tightly coupled
> -topics like watermark setup and computation, framebuffer compression and
> -panel self refresh.
> -
> -Atomic Plane Helpers
> ---------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c
> - :doc: atomic plane helpers
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c
> - :internal:
> -
> -Asynchronous Page Flip
> -----------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display.c
> - :doc: asynchronous flip implementation
> -
> -Output Probing
> ---------------
> -
> -This section covers output probing and related infrastructure like the
> -hotplug interrupt storm detection and mitigation code. Note that the
> -i915 driver still uses most of the common DRM helper code for output
> -probing, so those sections fully apply.
> -
> -Hotplug
> --------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c
> - :doc: Hotplug
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c
> - :internal:
> -
> -High Definition Audio
> ----------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c
> - :doc: High Definition Audio over HDMI and Display Port
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c
> - :internal:
> -
> -.. kernel-doc:: include/drm/intel/i915_component.h
> - :internal:
> -
> -Intel HDMI LPE Audio Support
> -----------------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c
> - :doc: LPE Audio integration for HDMI or DP playback
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c
> - :internal:
> -
> -Panel Self Refresh PSR (PSR/SRD)
> ---------------------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c
> - :doc: Panel Self Refresh (PSR/SRD)
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c
> - :internal:
> -
> -Frame Buffer Compression (FBC)
> -------------------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c
> - :doc: Frame Buffer Compression (FBC)
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c
> - :internal:
> -
> -Display Refresh Rate Switching (DRRS)
> --------------------------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c
> - :doc: Display Refresh Rate Switching (DRRS)
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c
> - :internal:
> -
> -DPIO
> -----
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpio_phy.c
> - :doc: DPIO
> -
> -DMC Firmware Support
> ---------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c
> - :doc: DMC Firmware Support
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c
> - :internal:
> -
> -DMC Flip Queue
> ---------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_flipq.c
> - :doc: DMC Flip Queue
> -
> -DMC wakelock support
> ---------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c
> - :doc: DMC wakelock support
> -
> -Video BIOS Table (VBT)
> -----------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_bios.c
> - :doc: Video BIOS Table (VBT)
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_bios.c
> - :internal:
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_vbt_defs.h
> - :internal:
> -
> -Display clocks
> ---------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cdclk.c
> - :doc: CDCLK / RAWCLK
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cdclk.c
> - :internal:
> -
> -Display PLLs
> -------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> - :doc: Display PLLs
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> - :internal:
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> - :internal:
> -
> -Display State Buffer
> ---------------------
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
> - :doc: DSB
> -
> -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
> - :internal:
> -
> GT Programming
> ==============
>
> @@ -568,7 +380,7 @@ The HuC FW layout is the same as the GuC one, see `GuC Firmware Layout`_
>
> DMC
> ---
> -See `DMC Firmware Support`_
> +See :ref:`drm/intel-display/dmc`.
>
> Tracing
> =======
> diff --git a/Documentation/gpu/intel-display/async-flip.rst b/Documentation/gpu/intel-display/async-flip.rst
> new file mode 100644
> index 000000000000..e4ae4012efc5
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/async-flip.rst
> @@ -0,0 +1,8 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Asynchronous Page Flip
> +----------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display.c
> + :doc: asynchronous flip implementation
> diff --git a/Documentation/gpu/intel-display/audio.rst b/Documentation/gpu/intel-display/audio.rst
> new file mode 100644
> index 000000000000..7d3c1b514b0e
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/audio.rst
> @@ -0,0 +1,23 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +High Definition Audio
> +---------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c
> + :doc: High Definition Audio over HDMI and Display Port
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c
> + :internal:
> +
> +.. kernel-doc:: include/drm/intel/i915_component.h
> + :internal:
> +
> +Intel HDMI LPE Audio Support
> +----------------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c
> + :doc: LPE Audio integration for HDMI or DP playback
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c
> + :internal:
> diff --git a/Documentation/gpu/intel-display/cdclk.rst b/Documentation/gpu/intel-display/cdclk.rst
> new file mode 100644
> index 000000000000..231b22a733e7
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/cdclk.rst
> @@ -0,0 +1,11 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Display clocks
> +--------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cdclk.c
> + :doc: CDCLK / RAWCLK
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cdclk.c
> + :internal:
> diff --git a/Documentation/gpu/intel-display/dmc.rst b/Documentation/gpu/intel-display/dmc.rst
> new file mode 100644
> index 000000000000..2fcdbd457d79
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/dmc.rst
> @@ -0,0 +1,26 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +.. _drm/intel-display/dmc:
> +
> +DMC Firmware Support
> +--------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c
> + :doc: DMC Firmware Support
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c
> + :internal:
> +
> +
> +DMC Flip Queue
> +--------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_flipq.c
> + :doc: DMC Flip Queue
> +
> +DMC wakelock support
> +--------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c
> + :doc: DMC wakelock support
> diff --git a/Documentation/gpu/intel-display/dpio.rst b/Documentation/gpu/intel-display/dpio.rst
> new file mode 100644
> index 000000000000..32e6f299f256
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/dpio.rst
> @@ -0,0 +1,8 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +DPIO
> +----
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpio_phy.c
> + :doc: DPIO
> diff --git a/Documentation/gpu/intel-display/dpll.rst b/Documentation/gpu/intel-display/dpll.rst
> new file mode 100644
> index 000000000000..35e8168ccfb9
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/dpll.rst
> @@ -0,0 +1,14 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Display PLLs
> +------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> + :doc: Display PLLs
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> + :internal:
> diff --git a/Documentation/gpu/intel-display/drrs.rst b/Documentation/gpu/intel-display/drrs.rst
> new file mode 100644
> index 000000000000..adb413f300f1
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/drrs.rst
> @@ -0,0 +1,11 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Display Refresh Rate Switching (DRRS)
> +-------------------------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c
> + :doc: Display Refresh Rate Switching (DRRS)
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c
> + :internal:
> diff --git a/Documentation/gpu/intel-display/dsb.rst b/Documentation/gpu/intel-display/dsb.rst
> new file mode 100644
> index 000000000000..cbd40b0a4e7b
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/dsb.rst
> @@ -0,0 +1,11 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Display State Buffer
> +--------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
> + :doc: DSB
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
> + :internal:
> diff --git a/Documentation/gpu/intel-display/fbc.rst b/Documentation/gpu/intel-display/fbc.rst
> new file mode 100644
> index 000000000000..40f9d16bdebd
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/fbc.rst
> @@ -0,0 +1,11 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Frame Buffer Compression (FBC)
> +------------------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c
> + :doc: Frame Buffer Compression (FBC)
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c
> + :internal:
> diff --git a/Documentation/gpu/intel-display/fifo-underrun.rst b/Documentation/gpu/intel-display/fifo-underrun.rst
> new file mode 100644
> index 000000000000..50731f3a1f03
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/fifo-underrun.rst
> @@ -0,0 +1,11 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Display FIFO Underrun Reporting
> +-------------------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c
> + :doc: fifo underrun handling
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c
> + :internal:
> diff --git a/Documentation/gpu/intel-display/frontbuffer.rst b/Documentation/gpu/intel-display/frontbuffer.rst
> new file mode 100644
> index 000000000000..2a1bc63ba6b4
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/frontbuffer.rst
> @@ -0,0 +1,14 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Frontbuffer Tracking
> +--------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c
> + :doc: frontbuffer tracking
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c
> + :internal:
> diff --git a/Documentation/gpu/intel-display/hotplug.rst b/Documentation/gpu/intel-display/hotplug.rst
> new file mode 100644
> index 000000000000..4cd9dd5ac8fc
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/hotplug.rst
> @@ -0,0 +1,11 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Hotplug
> +-------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c
> + :doc: Hotplug
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c
> + :internal:
> diff --git a/Documentation/gpu/intel-display/index.rst b/Documentation/gpu/intel-display/index.rst
> new file mode 100644
> index 000000000000..8d40363b8f90
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/index.rst
> @@ -0,0 +1,40 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +.. _drm/intel-display:
> +
> +====================
> +Intel Display Driver
> +====================
> +
> +The Intel display driver provides the display, or :ref:`drm-kms`, support for
> +both the :ref:`drm/xe <drm/xe>` and :ref:`drm/i915 <drm/i915>` Intel GPU
> +drivers.
> +
> +The source code currently resides under ``drivers/gpu/drm/i915/display`` due to
> +historical reasons, and it's compiled separately into both drm/xe and drm/i915
> +kernel modules.
> +
> +The drm/xe and drm/i915 drivers are the "core" or "parent" drivers for display,
> +as they initialize and own the drm device, and pass that on to the display
> +driver. The display driver isn't an independent driver in that sense.
> +
> +.. toctree::
> + :maxdepth: 1
> + :caption: Detailed display topics
> +
> + async-flip
> + audio
> + cdclk
> + dmc
> + dpio
> + dpll
> + drrs
> + dsb
> + fbc
> + fifo-underrun
> + frontbuffer
> + hotplug
> + plane
> + psr
> + vbt
> diff --git a/Documentation/gpu/intel-display/plane.rst b/Documentation/gpu/intel-display/plane.rst
> new file mode 100644
> index 000000000000..41cf6571aab0
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/plane.rst
> @@ -0,0 +1,11 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Atomic Plane Helpers
> +--------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c
> + :doc: atomic plane helpers
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c
> + :internal:
> diff --git a/Documentation/gpu/intel-display/psr.rst b/Documentation/gpu/intel-display/psr.rst
> new file mode 100644
> index 000000000000..134c905f500e
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/psr.rst
> @@ -0,0 +1,11 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Panel Self Refresh PSR (PSR/SRD)
> +--------------------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c
> + :doc: Panel Self Refresh (PSR/SRD)
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c
> + :internal:
> diff --git a/Documentation/gpu/intel-display/vbt.rst b/Documentation/gpu/intel-display/vbt.rst
> new file mode 100644
> index 000000000000..bbc7ee183f1b
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/vbt.rst
> @@ -0,0 +1,14 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Video BIOS Table (VBT)
> +----------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_bios.c
> + :doc: Video BIOS Table (VBT)
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_bios.c
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_vbt_defs.h
> + :internal:
> diff --git a/Documentation/gpu/xe/index.rst b/Documentation/gpu/xe/index.rst
> index 874ffcb6da3a..665c0e93601c 100644
> --- a/Documentation/gpu/xe/index.rst
> +++ b/Documentation/gpu/xe/index.rst
> @@ -1,5 +1,7 @@
> .. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>
> +.. _drm/xe:
> +
> =======================
> drm/xe Intel GFX Driver
> =======================
> @@ -8,6 +10,9 @@ The drm/xe driver supports some future GFX cards with rendering, display,
> compute and media. Support for currently available platforms like TGL, ADL,
> DG2, etc is provided to prototype the driver.
>
> +The display, or :ref:`drm-kms`, support for drm/xe is provided by
> +:ref:`drm/intel-display`, and shared with :ref:`drm/i915 <drm/i915>`.
Great idea!
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> +
> .. toctree::
> :titlesonly:
>
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH 2/3] Documentation/gpu: use === for Intel display section heading underlines
From: Rodrigo Vivi @ 2026-05-08 13:15 UTC (permalink / raw)
To: Jani Nikula
Cc: intel-gfx, intel-xe, dri-devel, linux-doc, Matthew Brost,
Thomas Hellström, joonas.lahtinen, tursulin
In-Reply-To: <f49968792220ca3ff24efde813550850340d092e.1778235406.git.jani.nikula@intel.com>
On Fri, May 08, 2026 at 01:20:48PM +0300, Jani Nikula wrote:
> Prefer to use === instead of --- for top level section heading
> underlines to allow using the latter for sub-headings later.
>
> While at it, fix the underline lenghts where needed.
>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
> Documentation/gpu/intel-display/async-flip.rst | 2 +-
> Documentation/gpu/intel-display/audio.rst | 4 ++--
> Documentation/gpu/intel-display/cdclk.rst | 2 +-
> Documentation/gpu/intel-display/dmc.rst | 6 +++---
> Documentation/gpu/intel-display/dpio.rst | 2 +-
> Documentation/gpu/intel-display/dpll.rst | 2 +-
> Documentation/gpu/intel-display/drrs.rst | 2 +-
> Documentation/gpu/intel-display/dsb.rst | 2 +-
> Documentation/gpu/intel-display/fbc.rst | 2 +-
> Documentation/gpu/intel-display/fifo-underrun.rst | 2 +-
> Documentation/gpu/intel-display/frontbuffer.rst | 2 +-
> Documentation/gpu/intel-display/hotplug.rst | 2 +-
> Documentation/gpu/intel-display/plane.rst | 2 +-
> Documentation/gpu/intel-display/psr.rst | 2 +-
> Documentation/gpu/intel-display/vbt.rst | 2 +-
> 15 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/gpu/intel-display/async-flip.rst b/Documentation/gpu/intel-display/async-flip.rst
> index e4ae4012efc5..40f93e885bb7 100644
> --- a/Documentation/gpu/intel-display/async-flip.rst
> +++ b/Documentation/gpu/intel-display/async-flip.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> Asynchronous Page Flip
> -----------------------
> +======================
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_display.c
> :doc: asynchronous flip implementation
> diff --git a/Documentation/gpu/intel-display/audio.rst b/Documentation/gpu/intel-display/audio.rst
> index 7d3c1b514b0e..eef95df75f8d 100644
> --- a/Documentation/gpu/intel-display/audio.rst
> +++ b/Documentation/gpu/intel-display/audio.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> High Definition Audio
> ----------------------
> +=====================
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c
> :doc: High Definition Audio over HDMI and Display Port
> @@ -14,7 +14,7 @@ High Definition Audio
> :internal:
>
> Intel HDMI LPE Audio Support
> -----------------------------
> +============================
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c
> :doc: LPE Audio integration for HDMI or DP playback
> diff --git a/Documentation/gpu/intel-display/cdclk.rst b/Documentation/gpu/intel-display/cdclk.rst
> index 231b22a733e7..a66d623b0ec9 100644
> --- a/Documentation/gpu/intel-display/cdclk.rst
> +++ b/Documentation/gpu/intel-display/cdclk.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> Display clocks
> ---------------
> +==============
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_cdclk.c
> :doc: CDCLK / RAWCLK
> diff --git a/Documentation/gpu/intel-display/dmc.rst b/Documentation/gpu/intel-display/dmc.rst
> index 2fcdbd457d79..4368da4c7048 100644
> --- a/Documentation/gpu/intel-display/dmc.rst
> +++ b/Documentation/gpu/intel-display/dmc.rst
> @@ -4,7 +4,7 @@
> .. _drm/intel-display/dmc:
>
> DMC Firmware Support
> ---------------------
> +====================
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c
> :doc: DMC Firmware Support
> @@ -14,13 +14,13 @@ DMC Firmware Support
>
>
> DMC Flip Queue
> ---------------------
> +==============
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_flipq.c
> :doc: DMC Flip Queue
>
> DMC wakelock support
> ---------------------
> +====================
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c
> :doc: DMC wakelock support
> diff --git a/Documentation/gpu/intel-display/dpio.rst b/Documentation/gpu/intel-display/dpio.rst
> index 32e6f299f256..84d92ac162f8 100644
> --- a/Documentation/gpu/intel-display/dpio.rst
> +++ b/Documentation/gpu/intel-display/dpio.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> DPIO
> -----
> +====
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpio_phy.c
> :doc: DPIO
> diff --git a/Documentation/gpu/intel-display/dpll.rst b/Documentation/gpu/intel-display/dpll.rst
> index 35e8168ccfb9..c750352e0ae5 100644
> --- a/Documentation/gpu/intel-display/dpll.rst
> +++ b/Documentation/gpu/intel-display/dpll.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> Display PLLs
> -------------
> +============
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> :doc: Display PLLs
> diff --git a/Documentation/gpu/intel-display/drrs.rst b/Documentation/gpu/intel-display/drrs.rst
> index adb413f300f1..a5aaba63d6b9 100644
> --- a/Documentation/gpu/intel-display/drrs.rst
> +++ b/Documentation/gpu/intel-display/drrs.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> Display Refresh Rate Switching (DRRS)
> --------------------------------------
> +=====================================
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c
> :doc: Display Refresh Rate Switching (DRRS)
> diff --git a/Documentation/gpu/intel-display/dsb.rst b/Documentation/gpu/intel-display/dsb.rst
> index cbd40b0a4e7b..857aca59995a 100644
> --- a/Documentation/gpu/intel-display/dsb.rst
> +++ b/Documentation/gpu/intel-display/dsb.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> Display State Buffer
> ---------------------
> +====================
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
> :doc: DSB
> diff --git a/Documentation/gpu/intel-display/fbc.rst b/Documentation/gpu/intel-display/fbc.rst
> index 40f9d16bdebd..de9e19021f50 100644
> --- a/Documentation/gpu/intel-display/fbc.rst
> +++ b/Documentation/gpu/intel-display/fbc.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> Frame Buffer Compression (FBC)
> -------------------------------
> +==============================
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c
> :doc: Frame Buffer Compression (FBC)
> diff --git a/Documentation/gpu/intel-display/fifo-underrun.rst b/Documentation/gpu/intel-display/fifo-underrun.rst
> index 50731f3a1f03..5d8f01921506 100644
> --- a/Documentation/gpu/intel-display/fifo-underrun.rst
> +++ b/Documentation/gpu/intel-display/fifo-underrun.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> Display FIFO Underrun Reporting
> --------------------------------
> +===============================
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c
> :doc: fifo underrun handling
> diff --git a/Documentation/gpu/intel-display/frontbuffer.rst b/Documentation/gpu/intel-display/frontbuffer.rst
> index 2a1bc63ba6b4..7ae38e0827bf 100644
> --- a/Documentation/gpu/intel-display/frontbuffer.rst
> +++ b/Documentation/gpu/intel-display/frontbuffer.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> Frontbuffer Tracking
> ---------------------
> +====================
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c
> :doc: frontbuffer tracking
> diff --git a/Documentation/gpu/intel-display/hotplug.rst b/Documentation/gpu/intel-display/hotplug.rst
> index 4cd9dd5ac8fc..f33bc0087c27 100644
> --- a/Documentation/gpu/intel-display/hotplug.rst
> +++ b/Documentation/gpu/intel-display/hotplug.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> Hotplug
> --------
> +=======
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c
> :doc: Hotplug
> diff --git a/Documentation/gpu/intel-display/plane.rst b/Documentation/gpu/intel-display/plane.rst
> index 41cf6571aab0..59932a82051b 100644
> --- a/Documentation/gpu/intel-display/plane.rst
> +++ b/Documentation/gpu/intel-display/plane.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> Atomic Plane Helpers
> ---------------------
> +====================
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c
> :doc: atomic plane helpers
> diff --git a/Documentation/gpu/intel-display/psr.rst b/Documentation/gpu/intel-display/psr.rst
> index 134c905f500e..63e56abcdd56 100644
> --- a/Documentation/gpu/intel-display/psr.rst
> +++ b/Documentation/gpu/intel-display/psr.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> Panel Self Refresh PSR (PSR/SRD)
> ---------------------------------
> +================================
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c
> :doc: Panel Self Refresh (PSR/SRD)
> diff --git a/Documentation/gpu/intel-display/vbt.rst b/Documentation/gpu/intel-display/vbt.rst
> index bbc7ee183f1b..be69f7fd7b39 100644
> --- a/Documentation/gpu/intel-display/vbt.rst
> +++ b/Documentation/gpu/intel-display/vbt.rst
> @@ -2,7 +2,7 @@
> .. Copyright © 2026 Intel Corporation
>
> Video BIOS Table (VBT)
> -----------------------
> +======================
>
> .. kernel-doc:: drivers/gpu/drm/i915/display/intel_bios.c
> :doc: Video BIOS Table (VBT)
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v3 1/2] usb: xhci-pci: add generic auxiliary device interface
From: Guenter Roeck @ 2026-05-08 13:17 UTC (permalink / raw)
To: Jihong Min, Mathias Nyman, Jihong Min, Greg Kroah-Hartman,
Mathias Nyman
Cc: Jonathan Corbet, Shuah Khan, Mario Limonciello, Basavaraj Natikar,
linux-usb, linux-hwmon, linux-doc, linux-pci, linux-kernel
In-Reply-To: <f47d9cc1-e39b-4199-b031-e91b8e02ab1d@icloud.com>
On 5/8/26 00:04, Jihong Min wrote:
> Hi Mathias,
>
> I tried the xhci-pci-prom21.c approach you suggested, with a PROM21-specific
> PCI glue driver calling xhci_pci_common_probe() and creating the auxiliary
> hwmon child device from that driver.
>
> While doing that I noticed a possible boot-time regression with the module
> case.
>
> If CONFIG_USB_XHCI_PCI=y and CONFIG_USB_XHCI_PCI_PROM21=m, then generic
> xhci-pci sees CONFIG_USB_XHCI_PCI_PROM21 as enabled and refuses the PROM21
> PCI ID:
>
> if (IS_ENABLED(CONFIG_USB_XHCI_PCI_PROM21) &&
> pci_match_id(pci_ids_prom21, dev))
> return -ENODEV;
>
> That means the PROM21 xHCI controller is handled only by
> xhci-pci-prom21.ko. If that module is not present in the initramfs or is not
> loaded early enough, the PROM21 xHCI controller remains unbound during early
> boot. Devices behind that controller, such as a USB keyboard used for early
> boot or disk unlock, would not work even though the generic xhci-pci driver is
> built in and could otherwise operate the controller.
>
> This seems different from the Renesas case, where the separate PCI driver is
> needed for controller-specific firmware handling. For PROM21, the USB/xHCI
> operation itself is still generic; the only extra function is publishing an
> optional hwmon child device.
>
> So I am not sure what the preferred direction should be:
>
> 1. Keep the separate xhci-pci-prom21.c PCI glue driver and make
> USB_XHCI_PCI_PROM21 built-in only, or otherwise constrain the Kconfig so
> the generic xhci-pci handoff cannot break early boot.
>
> 2. Keep PROM21 handled by generic xhci-pci and add only a small
> PROM21-specific auxiliary-device creation hook in xhci-pci after the
> common probe succeeds. In that model, failure to create the optional hwmon
> auxiliary device would not affect USB operation.
>
> 3. Some other split that keeps PROM21-specific sensor code outside
> xhci-pci, but does not prevent generic xhci-pci from binding the
> controller when the optional PROM21 glue is not available early.
>
> Do you still prefer the separate xhci-pci-prom21.c PCI driver for this case,
> or would the minimal xhci-pci auxiliary-device hook be more appropriate given
> the built-in xhci-pci / modular PROM21 glue case?
>
Maybe I am missing something, but it seems to me that CONFIG_USB_XHCI_PCI_PROM21
should be just as built-in as CONFIG_USB_XHCI_PCI.
Thanks,
Guenter
> Sincerely,
> Jihong Min
>
> On 5/7/26 18:31, Mathias Nyman wrote:
>> On 5/7/26 06:31, Jihong Min wrote:
>>> Some xHCI PCI controllers expose controller-specific functionality that is
>>> not part of generic xHCI operation and is better handled by optional child
>>> drivers in other subsystems. Add a small auxiliary device registration path
>>> for selected xHCI PCI controllers.
>>>
>>> The initial PCI ID match table lists AMD Promontory 21 (PROM21) 1022:43fd
>>> controllers. For matching controllers, xhci-pci creates an auxiliary
>>> device and stores it in devres so the remove path destroys it before HCD
>>> teardown.
>>>
>>> Subsystem-specific child drivers can then bind to those devices through
>>> the auxiliary bus and keep their hardware-specific logic outside xhci-pci.
>>>
>>> Assisted-by: Codex:gpt-5.5
>>> Signed-off-by: Jihong Min <hurryman2212@gmail.com>
>>> ---
>>> drivers/usb/host/Kconfig | 10 +++++
>>> drivers/usb/host/xhci-pci.c | 83 +++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 93 insertions(+)
>>>
>>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>>> index 0a277a07cf70..e0c2c7ac5c97 100644
>>> --- a/drivers/usb/host/Kconfig
>>> +++ b/drivers/usb/host/Kconfig
>>> @@ -42,6 +42,16 @@ config USB_XHCI_PCI
>>> depends on USB_PCI
>>> default y
>>> +config USB_XHCI_PCI_AUXDEV
>>> + bool "xHCI PCI auxiliary device support"
>>> + depends on USB_XHCI_PCI
>>> + select AUXILIARY_BUS
>>> + help
>>> + This enables xHCI PCI support for registering auxiliary devices
>>> + for selected controllers. It is used by optional child drivers
>>> + that bind to xHCI PCI controller-specific functionality through
>>> + the auxiliary bus.
>>> +
>>> config USB_XHCI_PCI_RENESAS
>>> tristate "Support for additional Renesas xHCI controller with firmware"
>>> depends on USB_XHCI_PCI
>>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>>> index 585b2f3117b0..618d6840e108 100644
>>> --- a/drivers/usb/host/xhci-pci.c
>>> +++ b/drivers/usb/host/xhci-pci.c
>>> @@ -8,6 +8,8 @@
>>> * Some code borrowed from the Linux EHCI driver.
>>> */
>>> +#include <linux/auxiliary_bus.h>
>>> +#include <linux/device/devres.h>
>>> #include <linux/pci.h>
>>> #include <linux/slab.h>
>>> #include <linux/module.h>
>>> @@ -80,6 +82,7 @@
>>> #define PCI_DEVICE_ID_AMD_RAVEN_15E1_XHCI 0x15e1
>>> #define PCI_DEVICE_ID_AMD_RAVEN2_XHCI 0x15e5
>>> #define PCI_DEVICE_ID_AMD_RENOIR_XHCI 0x1639
>>> +#define PCI_DEVICE_ID_AMD_PROM21_XHCI 0x43fd
>>> #define PCI_DEVICE_ID_AMD_PROMONTORYA_4 0x43b9
>>> #define PCI_DEVICE_ID_AMD_PROMONTORYA_3 0x43ba
>>> #define PCI_DEVICE_ID_AMD_PROMONTORYA_2 0x43bb
>>> @@ -103,6 +106,80 @@ static int xhci_pci_run(struct usb_hcd *hcd);
>>> static int xhci_pci_update_hub_device(struct usb_hcd *hcd, struct usb_device *hdev,
>>> struct usb_tt *tt, gfp_t mem_flags);
>>> +static const struct pci_device_id pci_ids_have_aux[] = {
>>> + { PCI_DEVICE_DATA(AMD, PROM21_XHCI, "prom21_hwmon") },
>>> + { /* end: all zeroes */ }
>>> +};
>>> +
>>> +struct xhci_pci_aux_devres {
>>> + struct auxiliary_device *auxdev;
>>> +};
>>> +
>>> +static const char *xhci_pci_aux_dev_name(struct pci_dev *pdev)
>>> +{
>>> + const struct pci_device_id *id;
>>> +
>>> + id = pci_match_id(pci_ids_have_aux, pdev);
>>> + if (!id)
>>> + return NULL;
>>> +
>>> + return (const char *)id->driver_data;
>>> +}
>>> +
>>> +static void xhci_pci_aux_devres_release(struct device *dev, void *res)
>>> +{
>>> + struct xhci_pci_aux_devres *devres = res;
>>> +
>>> + if (devres->auxdev)
>>> + auxiliary_device_destroy(devres->auxdev);
>>> +}
>>> +
>>> +static void xhci_pci_try_add_aux_device(struct pci_dev *pdev)
>>> +{
>>> + struct xhci_pci_aux_devres *devres;
>>> + struct auxiliary_device *auxdev;
>>> + const char *aux_dev_name;
>>> +
>>> + aux_dev_name = xhci_pci_aux_dev_name(pdev);
>>> + if (!aux_dev_name)
>>> + return;
>>> +
>>> + devres = devres_alloc(xhci_pci_aux_devres_release, sizeof(*devres),
>>> + GFP_KERNEL);
>>> + if (!devres) {
>>> + dev_warn(&pdev->dev,
>>> + "failed to allocate auxiliary device state\n");
>>> + return;
>>> + }
>>> +
>>> + auxdev = auxiliary_device_create(&pdev->dev, KBUILD_MODNAME,
>>> + aux_dev_name, NULL,
>>> + (pci_domain_nr(pdev->bus) << 16) |
>>> + pci_dev_id(pdev));
>>> + if (!auxdev) {
>>> + devres_free(devres);
>>> + dev_warn(&pdev->dev, "failed to add %s auxiliary device\n",
>>> + aux_dev_name);
>>> + return;
>>> + }
>>> +
>>> + devres->auxdev = auxdev;
>>> + devres_add(&pdev->dev, devres);
>>> +}
>>> +
>>> +static void xhci_pci_try_remove_aux_device(struct pci_dev *pdev)
>>> +{
>>> + struct xhci_pci_aux_devres *devres;
>>> +
>>> + devres = devres_find(&pdev->dev, xhci_pci_aux_devres_release, NULL,
>>> + NULL);
>>> + if (!devres || !devres->auxdev)
>>> + return;
>>> +
>>> + auxiliary_device_destroy(devres->auxdev);
>>> + devres->auxdev = NULL;
>>> +}
>>> +
>>> static const struct xhci_driver_overrides xhci_pci_overrides __initconst = {
>>> .reset = xhci_pci_setup,
>>> .start = xhci_pci_run,
>>> @@ -677,6 +754,9 @@ int xhci_pci_common_probe(struct pci_dev *dev, const struct pci_device_id *id)
>>> if (device_property_read_bool(&dev->dev, "ti,pwron-active-high"))
>>> pci_clear_and_set_config_dword(dev, 0xE0, 0, 1 << 22);
>>> + if (IS_ENABLED(CONFIG_USB_XHCI_PCI_AUXDEV))
>>> + xhci_pci_try_add_aux_device(dev);
>>> +
>>> return 0;
>>
>> I think this should be turned around so that the vendor specific code calls the common code.
>> xhci-pci-renesas.c does this nicely.
>>
>> In your case it would be adding something like a xhci-pci-prom21.c pci driver:
>>
>> xhci_pci_prom21_probe(struct pci_dev *dev, const struct pci_device_id *id)
>> {
>> crate_auxiliary_device(dev);
>> return xhci_pci_common_probe(dev, id);
>> }
>>
>> xhci_pci_prom21_remove(struct pci_dev *dev)
>> {
>> destroy_auxiliary_device(dev);
>> xhci_pci_remove(dev);
>> }
>>
>> static const struct pci_device_id pci_ids[] = {
>> { PCI_DEVICE(YOUR_AMD_PCI_VENDOR_ID, YOUR_PROM21_DEVICE_ID) },
>> { /* end: all zeroes */ }
>> };
>> MODULE_DEVICE_TABLE(pci, pci_ids);
>>
>> static struct pci_driver xhci_prom21_pci_driver = {
>> .name = "xhci-pci-prom21",
>> .id_table = pci_ids,
>>
>> .probe = xhci_pci_prom21_probe,
>> .remove = xhci_pci_prom21_remove,
>>
>> .shutdown = usb_hcd_pci_shutdown,
>> .driver = {
>> .pm = pm_ptr(&usb_hcd_pci_pm_ops),
>> },
>> };
>> module_pci_driver(xhci_prom21_pci_driver);
>>
>> MODULE_DESCRIPTION("AMD Promontory 21 xHCI PCI Host Controller Driver");
>> MODULE_IMPORT_NS("xhci");
>> MODULE_LICENSE("GPL v2");
>>
>> -Mathias
>
^ permalink raw reply
* Re: [PATCH 3/3] Documentation/gpu: add remaining DOC: comments to Intel display documentation
From: Rodrigo Vivi @ 2026-05-08 13:19 UTC (permalink / raw)
To: Jani Nikula
Cc: intel-gfx, intel-xe, dri-devel, linux-doc, Matthew Brost,
Thomas Hellström, joonas.lahtinen, tursulin
In-Reply-To: <589c46cf9a46763f4fbb7e1756656e6d71ba1431.1778235406.git.jani.nikula@intel.com>
On Fri, May 08, 2026 at 01:20:49PM +0300, Jani Nikula wrote:
> Not all of the overview DOC: comments in the display driver are
> incorporated into the documentation. Add the missing ones, including
> some function documentation.
>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
> Documentation/gpu/intel-display/atomic.rst | 11 +++++++++++
> Documentation/gpu/intel-display/casf.rst | 8 ++++++++
> Documentation/gpu/intel-display/cmtg.rst | 8 ++++++++
> Documentation/gpu/intel-display/index.rst | 4 ++++
> Documentation/gpu/intel-display/snps-phy.rst | 8 ++++++++
> 5 files changed, 39 insertions(+)
> create mode 100644 Documentation/gpu/intel-display/atomic.rst
> create mode 100644 Documentation/gpu/intel-display/casf.rst
> create mode 100644 Documentation/gpu/intel-display/cmtg.rst
> create mode 100644 Documentation/gpu/intel-display/snps-phy.rst
>
> diff --git a/Documentation/gpu/intel-display/atomic.rst b/Documentation/gpu/intel-display/atomic.rst
> new file mode 100644
> index 000000000000..43a473181e7a
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/atomic.rst
> @@ -0,0 +1,11 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Atomic Modeset Support
> +======================
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic.c
> + :doc: atomic modeset support
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic.c
> + :internal:
I believe they key functions on the other files below also deserves this
kind of doc. But I know, future work not related to this patch. ;)
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> diff --git a/Documentation/gpu/intel-display/casf.rst b/Documentation/gpu/intel-display/casf.rst
> new file mode 100644
> index 000000000000..406778ccd94c
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/casf.rst
> @@ -0,0 +1,8 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Content Adaptive Sharpness Filter (CASF)
> +========================================
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_casf.c
> + :doc: Content Adaptive Sharpness Filter (CASF)
> diff --git a/Documentation/gpu/intel-display/cmtg.rst b/Documentation/gpu/intel-display/cmtg.rst
> new file mode 100644
> index 000000000000..04edd0bd165d
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/cmtg.rst
> @@ -0,0 +1,8 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Common Primary Timing Generator (CMTG)
> +======================================
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cmtg.c
> + :doc: Common Primary Timing Generator (CMTG)
> diff --git a/Documentation/gpu/intel-display/index.rst b/Documentation/gpu/intel-display/index.rst
> index 8d40363b8f90..01c3d1e576b7 100644
> --- a/Documentation/gpu/intel-display/index.rst
> +++ b/Documentation/gpu/intel-display/index.rst
> @@ -24,8 +24,11 @@ driver. The display driver isn't an independent driver in that sense.
> :caption: Detailed display topics
>
> async-flip
> + atomic
> audio
> + casf
> cdclk
> + cmtg
> dmc
> dpio
> dpll
> @@ -37,4 +40,5 @@ driver. The display driver isn't an independent driver in that sense.
> hotplug
> plane
> psr
> + snps-phy
> vbt
> diff --git a/Documentation/gpu/intel-display/snps-phy.rst b/Documentation/gpu/intel-display/snps-phy.rst
> new file mode 100644
> index 000000000000..c9e333fa7f62
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/snps-phy.rst
> @@ -0,0 +1,8 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +Synopsis PHY support
> +====================
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_snps_phy.c
> + :doc: Synopsis PHY support
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: dac: Add AD5529R DAC driver support
From: Jonathan Cameron @ 2026-05-08 13:30 UTC (permalink / raw)
To: Janani Sunil
Cc: Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil
In-Reply-To: <20260508-ad5529r-driver-v2-2-e315441685d7@analog.com>
On Fri, 8 May 2026 13:55:48 +0200
Janani Sunil <janani.sunil@analog.com> wrote:
> Add support for AD5529R 16-channel, 12/16 bit Digital to Analog Converter
>
> Signed-off-by: Janani Sunil <janani.sunil@analog.com>
Hi Janani,
Various comments inline
Thanks,
Jonathan
> diff --git a/drivers/iio/dac/ad5529r.c b/drivers/iio/dac/ad5529r.c
> new file mode 100644
> index 000000000000..3676956f6eff
> --- /dev/null
> +++ b/drivers/iio/dac/ad5529r.c
> @@ -0,0 +1,564 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * AD5529R Digital-to-Analog Converter Driver
> + * 16-Channel, 12/16-Bit, 40V High Voltage Precision DAC
> + *
> + * Copyright 2026 Analog Devices Inc.
> + * Author: Janani Sunil <janani.sunil@analog.com>
> + */
> +
> +#include <linux/array_size.h>
> +#include <linux/bits.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/spi/spi.h>
> +#include <linux/errno.h>
> +#include <linux/iio/iio.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <linux/delay.h>
> +#include <linux/regulator/consumer.h>
Alphabetical order.
> +
> +/* Register Map */
> +#define AD5529R_REG_INTERFACE_CONFIG_A 0x00
> +#define AD5529R_REG_INTERFACE_CONFIG_B 0x01
> +#define AD5529R_REG_DEVICE_CONFIG 0x02
> +#define AD5529R_REG_CHIP_TYPE 0x03
> +#define AD5529R_REG_PRODUCT_ID_L 0x04
> +#define AD5529R_REG_PRODUCT_ID_H 0x05
> +#define AD5529R_REG_CHIP_GRADE 0x06
> +#define AD5529R_REG_SCRATCH_PAD 0x0A
> +#define AD5529R_REG_SPI_REVISION 0x0B
> +#define AD5529R_REG_VENDOR_L 0x0C
> +#define AD5529R_REG_VENDOR_H 0x0D
> +#define AD5529R_REG_STREAM_MODE 0x0E
> +#define AD5529R_REG_TRANSFER_CONFIG 0x0F
> +#define AD5529R_REG_INTERFACE_CONFIG_C 0x10
> +#define AD5529R_REG_INTERFACE_STATUS_A 0x11
> +
> +/* Configuration registers */
> +#define AD5529R_REG_MULTI_DAC_CH_SEL (0x14 + 1)
Feels like this would all be simpler if you used autoincrement rather than
default value of autdecrement. What breaks if you do that?
Superficially feels like all the +1 would go away - though with need
for a byte swap? Might be worth that pain for the simpler code.
Should just be a regmap_config parameter.
> +#define AD5529R_REG_LDAC_SYNC_ASYNC (0x16 + 1)
> +#define AD5529R_REG_LDAC_HW_SW (0x18 + 1)
> +
> +/* Hardware LDAC source and edge select registers (per channel, 16-bit) */
> +#define AD5529R_REG_LDAC_HW_SRC_EDGE_SEL_BASE (0x1A + 1)
> +#define AD5529R_REG_LDAC_HW_SRC_EDGE_SEL(ch) \
> + (AD5529R_REG_LDAC_HW_SRC_EDGE_SEL_BASE + (ch) * 2)
> +
> +/* Output configuration */
> +#define AD5529R_REG_OUT_OPERATING_MODE (0x3A + 1)
> +#define AD5529R_REG_OUT_RANGE_BASE (0x3C + 1)
> +#define AD5529R_REG_OUT_RANGE(ch) (AD5529R_REG_OUT_RANGE_BASE + (ch) * 2)
> +
> +/* Calibration registers */
> +#define AD5529R_REG_CAL_GAIN_BASE (0x5C + 1)
> +#define AD5529R_REG_CAL_GAIN(ch) (AD5529R_REG_CAL_GAIN_BASE + (ch) * 2)
> +
> +#define AD5529R_REG_CAL_OFFSET_BASE (0x7C + 1)
> +#define AD5529R_REG_CAL_OFFSET(ch) (AD5529R_REG_CAL_OFFSET_BASE + (ch) * 2)
> +
> +/* Function generator registers */
> +#define AD5529R_REG_FUNC_EN (0x9C + 1)
> +#define AD5529R_REG_FUNC_MODE_SEL_BASE (0x9E + 1)
> +#define AD5529R_REG_FUNC_MODE_SEL(ch) \
> + (AD5529R_REG_FUNC_MODE_SEL_BASE + (ch) * 2)
> +
> +#define AD5529R_REG_FUNC_DAC_INPUT_B_BASE (0xBE + 1)
> +#define AD5529R_REG_FUNC_DAC_INPUT_B(ch) \
> + (AD5529R_REG_FUNC_DAC_INPUT_B_BASE + (ch) * 2)
> +
> +#define AD5529R_REG_FUNC_DITHER_PERIOD_BASE (0xDE + 1)
> +#define AD5529R_REG_FUNC_DITHER_PERIOD(ch) \
> + (AD5529R_REG_FUNC_DITHER_PERIOD_BASE + (ch) * 2)
> +
> +#define AD5529R_REG_FUNC_DITHER_PHASE_BASE (0xFE + 1)
> +#define AD5529R_REG_FUNC_DITHER_PHASE(ch) \
> + (AD5529R_REG_FUNC_DITHER_PHASE_BASE + (ch) * 2)
> +
> +#define AD5529R_REG_FUNC_RAMP_STEP_BASE (0x11E + 1)
> +#define AD5529R_REG_FUNC_RAMP_STEP(ch) \
> + (AD5529R_REG_FUNC_RAMP_STEP_BASE + (ch) * 2)
> +
> +#define AD5529R_REG_FUNC_INT_EN (0x13E + 1)
> +
> +/* Multiplexer and main DAC registers */
> +#define AD5529R_REG_MUX_OUT_SEL (0x140 + 1)
> +#define AD5529R_REG_MULTI_DAC_SW_LDAC (0x142 + 1)
> +#define AD5529R_REG_MULTI_DAC_INPUT_A (0x144 + 1)
> +#define AD5529R_REG_DAC_SW_LDAC (0x146 + 1)
> +
> +#define AD5529R_REG_DAC_INPUT_A_BASE (0x148 + 1)
> +#define AD5529R_REG_DAC_INPUT_A(ch) (AD5529R_REG_DAC_INPUT_A_BASE + (ch) * 2)
> +
> +/* Status and readback registers */
> +#define AD5529R_REG_FUNC_INT_STAT (0x168 + 1)
> +#define AD5529R_REG_DAC_DATA_READBACK_BASE (0x16A + 1)
> +#define AD5529R_REG_DAC_DATA_READBACK(ch) \
> + (AD5529R_REG_DAC_DATA_READBACK_BASE + (ch) * 2)
> +
> +/* Temperature sensor registers */
> +#define AD5529R_REG_TSENS_EN (0x18A + 1)
> +#define AD5529R_REG_TSENS_ALERT_FLAG (0x18C + 1)
> +#define AD5529R_REG_TSENS_SHTD_FLAG (0x18E + 1)
> +#define AD5529R_REG_TSENS_ALERT_STAT (0x190 + 1)
> +#define AD5529R_REG_TSENS_SHTD_STAT (0x192 + 1)
> +#define AD5529R_REG_ALARMB_TSENS_EN (0x194 + 1)
> +#define AD5529R_REG_ALARMB_TSENS_SEL (0x196 + 1)
> +#define AD5529R_REG_TSENS_SHTD_EN_CH (0x198 + 1)
> +#define AD5529R_REG_DAC_DIS_DEGLITCH_CH (0x19A + 1)
> +#define AD5529R_REG_DAC_INT_EN (0x19C + 1)
> +#define AD5529R_REG_ALL_FUNC_INT_STAT (0x19E + 1)
> +#define AD5529R_REG_FUNC_BUSY (0x1A0 + 1)
> +#define AD5529R_REG_REF_SRC_SEL (0x1A2 + 1)
> +#define AD5529R_REG_INIT_CRC_ERR_STAT (0x1A4 + 1)
> +
> +/* Hotpath registers for multi-device support */
> +#define AD5529R_REG_MULTI_DAC_HOTPATH_SW_LDAC (0x1A8 + 1)
> +#define AD5529R_REG_MULTI_DAC_HOTPATH_INPUT_A_DIE_0 (0x1AA + 1)
> +#define AD5529R_REG_MULTI_DAC_HOTPATH_INPUT_A_DIE_1 (0x1AC + 1)
> +#define AD5529R_REG_MULTI_DAC_HOTPATH_INPUT_A_DIE_2 (0x1AE + 1)
> +#define AD5529R_REG_MULTI_DAC_HOTPATH_INPUT_A_DIE_3 (0x1B0 + 1)
> +#define AD5529R_REG_DAC_HOTPATH_SW_LDAC (0x1B2 + 1)
> +
> +/* Hotpath per-channel DAC input registers for each die */
> +#define AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_0_BASE (0x1B4 + 1)
> +#define AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_0(ch) \
> + (AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_0_BASE + (ch) * 2)
> +
> +#define AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_1_BASE (0x1D4 + 1)
> +#define AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_1(ch) \
> + (AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_1_BASE + (ch) * 2)
> +
> +#define AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_2_BASE (0x1F4 + 1)
> +#define AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_2(ch) \
> + (AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_2_BASE + (ch) * 2)
> +
> +#define AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_3_BASE (0x214 + 1)
> +#define AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_3(ch) \
> + (AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_3_BASE + (ch) * 2)
> +
> +#define AD5529R_INTERFACE_CONFIG_A_SW_RESET (BIT(7) | BIT(0))
> +#define AD5529R_INTERFACE_CONFIG_A_ADDR_ASCENSION BIT(5)
> +#define AD5529R_INTERFACE_CONFIG_A_SDO_ENABLE BIT(4)
> +#define AD5529R_INTERFACE_CONFIG_A_DEFAULT 0x10
I'd put the values it represents inline and get rid of this define.
_DEFAULT defines are rarely a good design pattern
> +#define AD5529R_NUM_CHANNELS 16
I'd store this along side the channels pointer then you can use ARRAY_SIZE() on the
the chan_spec array and drop this constant.
> +#define AD5529R_MAX_CHANNEL_INDEX (AD5529R_NUM_CHANNELS - 1)
With the above gone, just make this a hard coded 15.
> +#define AD5529R_MAX_REGISTER (0x232 + 1)
> +#define AD5529R_8BIT_REG_MAX 0x13
> +#define AD5529R_ADDR(reg_addr) ((reg_addr) & 0xFFF)
Not used, so drop it.
> +#define AD5529R_RESET_PULSE_US 1000
> +#define AD5529R_RESET_DELAY_US 10000
As mentioned below - just put these numbers inline. Defines just make
the code harder to read when they are used only once and represent exactly
what the value is.
> +#define AD5529R_SPI_BUF_SIZE 4
No idea what this is for - not used.
> +#define AD5529R_NUM_SUPPLIES 4
No need for a constant for this - use [] to define the names array and ARRAY_SIZE()
on that to get the size where needed.
> +#define AD5529R_SPI_READ_FLAG 0x80
> +
> +static const struct regmap_range ad5529r_8bit_readable_ranges[] = {
> + regmap_reg_range(AD5529R_REG_INTERFACE_CONFIG_A, AD5529R_REG_CHIP_GRADE),
> + regmap_reg_range(AD5529R_REG_SCRATCH_PAD, AD5529R_REG_VENDOR_H),
> + regmap_reg_range(AD5529R_REG_STREAM_MODE, AD5529R_REG_INTERFACE_STATUS_A),
> +};
> +
> +static const struct regmap_range ad5529r_16bit_readable_ranges[] = {
Tricky bit here is you are saying it's a 16 bit regmap but then providing
address ranges including the ones we shouldn't use. We need to hide those
intermediate addresses. Various things might work depending on the addresses.
Can we hide the bottom bit of each address then write it to appropriate value
under the hood. That is divide addresses by 2?
> + regmap_reg_range(AD5529R_REG_MULTI_DAC_CH_SEL, AD5529R_REG_LDAC_HW_SW),
> + regmap_reg_range(AD5529R_REG_LDAC_HW_SRC_EDGE_SEL_BASE,
> + AD5529R_REG_LDAC_HW_SRC_EDGE_SEL_BASE + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_OUT_OPERATING_MODE, AD5529R_REG_OUT_OPERATING_MODE),
> + regmap_reg_range(AD5529R_REG_OUT_RANGE_BASE,
> + AD5529R_REG_OUT_RANGE_BASE + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_CAL_GAIN_BASE,
> + AD5529R_REG_CAL_GAIN_BASE + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_CAL_OFFSET_BASE,
> + AD5529R_REG_CAL_OFFSET_BASE + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_FUNC_EN, AD5529R_REG_FUNC_EN),
> + regmap_reg_range(AD5529R_REG_FUNC_MODE_SEL_BASE,
> + AD5529R_REG_FUNC_MODE_SEL_BASE + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_FUNC_DAC_INPUT_B_BASE,
> + AD5529R_REG_FUNC_DAC_INPUT_B_BASE + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_FUNC_DITHER_PERIOD_BASE,
> + AD5529R_REG_FUNC_DITHER_PERIOD_BASE + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_FUNC_DITHER_PHASE_BASE,
> + AD5529R_REG_FUNC_DITHER_PHASE_BASE + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_FUNC_RAMP_STEP_BASE,
> + AD5529R_REG_FUNC_RAMP_STEP_BASE + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_FUNC_INT_EN, AD5529R_REG_DAC_SW_LDAC),
> + regmap_reg_range(AD5529R_REG_DAC_INPUT_A_BASE,
> + AD5529R_REG_DAC_INPUT_A_BASE + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_FUNC_INT_STAT, AD5529R_REG_FUNC_INT_STAT),
> + regmap_reg_range(AD5529R_REG_DAC_DATA_READBACK_BASE,
> + AD5529R_REG_DAC_DATA_READBACK_BASE + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_TSENS_EN, AD5529R_REG_INIT_CRC_ERR_STAT),
> + regmap_reg_range(AD5529R_REG_MULTI_DAC_HOTPATH_SW_LDAC, AD5529R_REG_DAC_HOTPATH_SW_LDAC),
> + regmap_reg_range(AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_0_BASE,
> + AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_0_BASE +
> + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_1_BASE,
> + AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_1_BASE +
> + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_2_BASE,
> + AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_2_BASE +
> + AD5529R_MAX_CHANNEL_INDEX * 2),
> + regmap_reg_range(AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_3_BASE,
> + AD5529R_REG_DAC_HOTPATH_INPUT_A_DIE_3_BASE +
> + AD5529R_MAX_CHANNEL_INDEX * 2),
Yikes. This thing has an ugly register map.
> +};
> +
> +static int ad5529r_detect_device(struct ad5529r_state *st)
> +{
> + unsigned int product_id;
> + int ret;
> +
> + ret = regmap_read(st->regmap_8bit, AD5529R_REG_PRODUCT_ID_L, &product_id);
> + if (ret)
> + return ret;
> +
> + switch (product_id) {
> + case AD5529R_PRODUCT_ID_16BIT:
> + st->model_data = &ad5529r_16bit_model_data;
> + break;
> + case AD5529R_PRODUCT_ID_12BIT:
> + st->model_data = &ad5529r_12bit_model_data;
> + break;
> + default:
> + dev_err(&st->spi->dev, "Unknown product ID: 0x%02X\n", product_id);
> + return -ENODEV;
See below on why this doesn't extend to fallback compatibles from DT and
what to do instead.
> + }
> +
> + dev_dbg(&st->spi->dev, "Detected %s variant (Product ID: 0x%02X)\n",
> + st->model_data->model_name, product_id);
> +
> + return 0;
> +}
> +
> +static int ad5529r_reset(struct ad5529r_state *st)
> +{
> + struct reset_control *rst;
> + int ret;
> +
> + rst = devm_reset_control_get_optional_exclusive(&st->spi->dev, NULL);
> + if (IS_ERR(rst))
> + return PTR_ERR(rst);
> +
> + if (rst) {
> + ret = reset_control_deassert(rst);
> + if (ret)
> + return ret;
> + } else {
> + ret = regmap_write(st->regmap_8bit, AD5529R_REG_INTERFACE_CONFIG_A,
> + AD5529R_INTERFACE_CONFIG_A_SW_RESET);
> + if (ret)
> + return ret;
> + }
> +
> + fsleep(AD5529R_RESET_DELAY_US);
This define is only used in one place. I'd rather see the value here and
a comment on where it comes from - typically a spec reference.
> +
> + return regmap_write(st->regmap_8bit, AD5529R_REG_INTERFACE_CONFIG_A,
> + AD5529R_INTERFACE_CONFIG_A_DEFAULT);
> +}
> +
> +static int ad5529r_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct ad5529r_state *st = iio_priv(indio_dev);
> + unsigned int reg_addr;
> + unsigned int reg_val_h;
Could combine those two on oneline (not that important)
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + reg_addr = AD5529R_REG_DAC_INPUT_A(chan->channel);
> + ret = regmap_read(st->regmap_16bit, reg_addr, ®_val_h);
> + if (ret)
> + return ret;
> +
> + *val = reg_val_h;
> +
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + /*
> + * Using default 0-5V range: VOUTn = A × D/2^N + B
> + * where A = 5V, B = 0V, D = digital code, N = resolution
> + * Scale = 5000mV / 2^resolution
See the comment on the dt-binding. I think we need support for
dt described output ranges from the start. This is a rare multi range
device where we could set a safe default but to me it makes little sense
and the driver will be doing something unexpected if a newer DT is
provided with a different range.
> + */
> + *val = 5000;
> + *val2 = st->model_data->resolution;
> +
> + return IIO_VAL_FRACTIONAL_LOG2;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int ad5529r_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val, int val2, long mask)
> +{
> + struct ad5529r_state *st = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (val < 0 || val > GENMASK(st->model_data->resolution - 1, 0))
> + return -EINVAL;
> +
> + return regmap_write(st->regmap_16bit, AD5529R_REG_DAC_INPUT_A(chan->channel), val);
That's a very long line. Break it up as:
return regmap_write(st->regmap_16bit,
AD5529R_REG_DAC_INPUT_A(chan->channel), val);
I don't mind going past 80 for readability but here I don't see it as greatly hurt
by breaking the line and it was way past 80. Or use a local reg_addr variable
like you have in read_raw()
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int ad5529r_probe(struct spi_device *spi)
> +{
> + struct device *dev = &spi->dev;
> + struct iio_dev *indio_dev;
> + struct ad5529r_state *st;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*st));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + st = iio_priv(indio_dev);
> +
> + st->spi = spi;
> +
> + ret = devm_regulator_bulk_get_enable(dev, AD5529R_NUM_SUPPLIES,
> + ad5529r_supply_names);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to get and enable regulators\n");
> +
> + st->regmap_8bit = devm_regmap_init_spi(spi, &ad5529r_regmap_8bit_config);
> + if (IS_ERR(st->regmap_8bit))
> + return dev_err_probe(dev, PTR_ERR(st->regmap_8bit),
> + "Failed to initialize 8-bit regmap\n");
> +
> + st->regmap_16bit = devm_regmap_init_spi(spi, &ad5529r_regmap_16bit_config);
> + if (IS_ERR(st->regmap_16bit))
> + return dev_err_probe(dev, PTR_ERR(st->regmap_16bit),
> + "Failed to initialize 16-bit regmap\n");
> +
> + ret = ad5529r_reset(st);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to reset device\n");
> +
> + ret = ad5529r_detect_device(st);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to detect device variant\n");
No to this. It breaks the use of fallback device tree compatibles. As such we
never fail on an ID missmatch. Instead we just believe firmware when it says
whatever is there is compatible with this device. See below on why I think
we need to break this into separate compatibles.
> +
> + indio_dev->name = st->model_data->model_name;
> + indio_dev->info = &ad5529r_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->channels = st->model_data->channels;
> + indio_dev->num_channels = AD5529R_NUM_CHANNELS;
> +
> + return devm_iio_device_register(dev, indio_dev);
> +}
> +
> +static const struct of_device_id ad5529r_of_match[] = {
> + { .compatible = "adi,ad5529r" },
Hmm. I'm in two minds on this. Is it better to do as you have
an detect between the ad5529r-12 and ad5529r-16 based on ID or should
we just have them as separate compatibles? If they had different part
numbers (which is most common way this is done by ADI and others) then
we'd not consider sharing a compatible. As such I think we should split
them. That also makes fallback compatibles work. Otherwise how
would we know whether a new device ID should be 12 or 16 bit?
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, ad5529r_of_match);
> +
> +static const struct spi_device_id ad5529r_id[] = {
> + { "ad5529r" },
Same would apply here for including the postfix in the naming.
> + { }
> +};
> +MODULE_DEVICE_TABLE(spi, ad5529r_id);
> +
> +static struct spi_driver ad5529r_driver = {
> + .driver = {
> + .name = "ad5529r",
> + .of_match_table = ad5529r_of_match,
> + },
> + .probe = ad5529r_probe,
> + .id_table = ad5529r_id,
> +};
> +module_spi_driver(ad5529r_driver);
> +
> +MODULE_AUTHOR("Janani Sunil <janani.sunil@analog.com>");
> +MODULE_DESCRIPTION("Analog Devices AD5529R 12/16-bit DAC driver");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: 回复：[PATCH v13 net-next 03/11] net/nebula-matrix: add chip related definitions
From: Andrew Lunn @ 2026-05-08 13:40 UTC (permalink / raw)
To: Illusion Wang
Cc: Paolo Abeni, Dimon, Alvin, Sam, netdev, andrew+netdev, corbet,
kuba, linux-doc, lorenzo, horms, vadim.fedorenko, lukas.bulwahn,
edumazet, enelsonmoore, skhan, hkallweit1, open list
In-Reply-To: <b240b971-81b8-4325-80b6-5352e1515f07.Illusion.Wang@nebula-matrix.com>
> But I printed out the results:
> ARRAY_SIZE(nbl_sec009_data) equals NBL_SEC009_SIZE,
> ARRAY_SIZE(nbl_sec025_data) equals NBL_SEC025_SIZE,
> and ARRAY_SIZE(nbl_sec022_data) equals NBL_SEC022_SIZE.
>
> Is the AI making a mistake here?
Just a guess, i've not looked at this patch at all.
Are you doing this on a 32 bit build? Maybe the AI is?
Andrew
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Sasha Levin @ 2026-05-08 13:44 UTC (permalink / raw)
To: Jonathan Corbet
Cc: akpm, skhan, linux-doc, linux-kernel, linux-kselftest, gregkh
In-Reply-To: <87v7cz8cus.fsf@trenco.lwn.net>
On Thu, May 07, 2026 at 09:21:15AM -0600, Jonathan Corbet wrote:
>Sasha Levin <sashal@kernel.org> writes:
>
>> When a (security) issue goes public, fleets stay exposed until a patched kernel
>> is built, distributed, and rebooted into.
>>
>> For many such issues the simplest mitigation is to stop calling the buggy
>> function. Killswitch provides that. An admin writes:
>>
>> echo "engage af_alg_sendmsg -1" \
>> > /sys/kernel/security/killswitch/control
>>
>> After this, af_alg_sendmsg() returns -EPERM on every call without
>> running its body. The mitigation takes effect immediately, and is dropped on
>> the next reboot.
>
>A quick look suggests that you're not checking lockdown status. I don't
>doubt for a second that this thing could be used to bypass lockdown - by
>shorting out security_locked_down() if nothing else. I'm guessing that
>might not prove entirely popular.
Hmm... Good point. I'll respin a v2 adressing this and Greg's comments.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: iio: dac: Add AD5529R
From: Rodrigo Alencar @ 2026-05-08 13:50 UTC (permalink / raw)
To: Jonathan Cameron, Janani Sunil
Cc: Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
rodrigo.alencar
In-Reply-To: <20260508134843.7646c4f5@jic23-huawei>
On 26/05/08 01:48PM, Jonathan Cameron wrote:
> On Fri, 8 May 2026 13:55:47 +0200
> Janani Sunil <janani.sunil@analog.com> wrote:
...
> > + Specifications:
> > + * 16 independent 12-bit or 16-bit DAC channels
> > + * Independently programmable output ranges: 0V to 5V, 0V to 10V, 0V to 20V,
> > + 0V to 40V, ±5V, ±10V, ±15V, and ±20V
> > + * The device supports SPI communication with Mode 0 and Mode 3.
> > + * 4.096V precision reference, 12ppm/°C maximum
> > + * Built-in function generation: Toggle, Sinusoidal Dither, and Ramp waveforms
>
> Interesting - so this is a DDS, be it a simple one. +CC Rodrigo who has been
> wrestling with one of those recently. Rodrigo, can you take a look at this
> driver and see if it fits in the ABI etc you've been hammering out? Thanks!
I am not sure how this is a DDS as it does really generate frequencies, so it does
not seem to act as an oscillator. I'd say the minimum for a DDS is an NCO + DAC.
The function generation seem to act only on the voltage levels. There is the step
size and ramp limits configuration that are similar to a DDS with a digital ramp
generator. I suppose that users have some use cases that are often integrated into
the products so they can do less (and the overall system becomes more efficient).
However, those products end up solving too many problems at once and they get too
complex!
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v1 2/4] spi: Support suppress_override_attrs flag
From: Mark Brown @ 2026-05-08 13:53 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Danilo Krummrich, driver-core, linux-doc, linux-kernel, linux-iio,
linux-spi, Greg Kroah-Hartman, Rafael J. Wysocki, Jonathan Corbet,
Shuah Khan, Jean-Baptiste Maneyrol, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
In-Reply-To: <20260508095224.1275645-3-andriy.shevchenko@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]
On Fri, May 08, 2026 at 11:42:40AM +0200, Andy Shevchenko wrote:
> Some device driver may want to suppress the driver_override sysfs attribute
> by specifying a certain flag in their struct device_driver. Since SPI uses
> explicit attribute instantiation, add that support here.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: iio: dac: Add AD5529R
From: Nuno Sá @ 2026-05-08 13:57 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Janani Sunil, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-kernel, linux-doc,
Janani Sunil, rodrigo.alencar
In-Reply-To: <20260508134843.7646c4f5@jic23-huawei>
On Fri, May 08, 2026 at 01:48:43PM +0100, Jonathan Cameron wrote:
> On Fri, 8 May 2026 13:55:47 +0200
> Janani Sunil <janani.sunil@analog.com> wrote:
>
> > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > buffered voltage output digital-to-analog converter (DAC) with an
> > integrated precision reference.
> >
> > Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> > ---
> > .../devicetree/bindings/iio/dac/adi,ad5529r.yaml | 96 ++++++++++++++++++++++
> > MAINTAINERS | 7 ++
> > 2 files changed, 103 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml
> > new file mode 100644
> > index 000000000000..f531b4865b01
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml
> > @@ -0,0 +1,96 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/dac/adi,ad5529r.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Analog Devices AD5529R 16-Channel 12/16-bit High Voltage DAC
>
> How is one device bother 12 and 16-bit? That sometimes happens for
> ADCs where it is really reflecting oversampling or for device with hardware
> FIFOs where storage space is saved by using lower bit rate. I'm not sure either
> applies here.
>
> > +
> > +maintainers:
> > + - Janani Sunil <janani.sunil@analog.com>
> > +
> > +description: |
> > + The AD5529R is a 16-channel, 12-bit or 16-bit, high voltage, buffered voltage output
> > + digital-to-analog converter (DAC) with an integrated precision reference.
> > + The device operates from unipolar and bipolar supplies. It is guaranteed
> > + monotonic and has built-in rail-to-rail output buffers that can source or
> > + sink up to 25mA.
> > +
> > + Specifications:
> > + * 16 independent 12-bit or 16-bit DAC channels
> > + * Independently programmable output ranges: 0V to 5V, 0V to 10V, 0V to 20V,
> > + 0V to 40V, ±5V, ±10V, ±15V, and ±20V
> > + * The device supports SPI communication with Mode 0 and Mode 3.
> > + * 4.096V precision reference, 12ppm/°C maximum
> > + * Built-in function generation: Toggle, Sinusoidal Dither, and Ramp waveforms
>
> Interesting - so this is a DDS, be it a simple one. +CC Rodrigo who has been
> wrestling with one of those recently. Rodrigo, can you take a look at this
> driver and see if it fits in the ABI etc you've been hammering out? Thanks!
Yes, this also crossed my mind. I only briefly looked into the datasheet
but this device seems to be similar to the ltc2688 for the toggle and
dither modes. Naturally ramp is something new.
Not really sure this one is a DDS as that typically means things like
NCOs. This device looks like a "plain" DAC.
So, devices like the one Rodrigo is working one combine DDS + DAC to do
things like synthesizing waveforms (in a very fast way).
We would need to do some auditing but I guess we tend to put above
devices in dac/ (because they do have a DAC internally) or even maybe in
frequency/ but maybe worth thinking about a new directory for those.
Having said the above the ABI might still matter for both devices.
- Nuno Sá
>
>
> > + * Multiplexer for output voltage, load current sense and die temperature
> > +
> > + Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ad5529r.pdf
> > +
> > +properties:
> > + compatible:
> > + const: adi,ad5529r
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + spi-max-frequency:
> > + maximum: 50000000
> > +
> > + reset-gpios:
> > + maxItems: 1
> > + description:
> > + GPIO connected to the RESET pin. Active low. When asserted low,
> > + performs a power-on reset and initializes the device to its default state.
> > +
> > + vdd-supply:
> > + description: Digital power supply (typically 3.3V)
> > +
> > + avdd-supply:
> > + description: Analog power supply (typically 5V)
> > +
> > + hvdd-supply:
> > + description: High voltage positive supply (up to 40V for output range)
> > +
> > + hvss-supply:
> > + description: High voltage negative supply (ground or negative voltage)
>
> I don't mind doing it this way but in some similar cases where 0 is something that
> can be considered the 'default' we've made the supply optional. What was
> your reasoning for requiring it in this case?
>
> dt-bindings should be as complete as we can make them - with that in mind...
>
> There are some more interesting corners on this device the binding doesn't
> currently cover such as mux_out pin. We'd normally do that by making the
> driver potentially a client of an ADC
>
> Easier though is !alarm which smells like an interrupt.
> !clear probably a gpio. TG0-3 also GPIOs.
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - vdd-supply
> > + - avdd-supply
> > + - hvdd-supply
> > + - hvss-supply
>
^ permalink raw reply
* Re: [PATCH v17 02/11] cxl/ras: Unify Endpoint and Port AER trace events
From: Jonathan Cameron @ 2026-05-08 14:05 UTC (permalink / raw)
To: Bowman, Terry
Cc: dave, dave.jiang, alison.schofield, djbw, bhelgaas, shiju.jose,
ming.li, Smita.KoralahalliChannabasappa, rrichter, dan.carpenter,
PradeepVineshReddy.Kodamati, lukas, Benjamin.Cheatham,
sathyanarayanan.kuppuswamy, vishal.l.verma, alucerop, ira.weiny,
corbet, rafael, xueshuai, linux-cxl, linux-kernel, linux-pci,
linux-acpi, linux-doc, Mauro Carvalho Chehab
In-Reply-To: <8913c666-a343-4717-8ab2-0b8546d1bdfb@amd.com>
On Thu, 7 May 2026 13:33:45 -0500
"Bowman, Terry" <terry.bowman@amd.com> wrote:
> On 5/7/2026 1:08 PM, Jonathan Cameron wrote:
> > [Some people who received this message don't often get email from jic23@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On Tue, 5 May 2026 12:30:20 -0500
> > Terry Bowman <terry.bowman@amd.com> wrote:
> >
> >> From: Dan Williams <djbw@kernel.org>
> >
> > +CC Mauro - rasdaemon related - see below.
> >
> >>
> >> CXL protocol error logging uses two parallel sets of trace events. The
> >> cxl_port_aer_correctable_error() and cxl_port_aer_uncorrectable_error()
> >> events are used by CPER for CXL Port devices. The cxl_aer_correctable_error()
> >> and cxl_aer_uncorrectable_error() events are used for CXL Endpoints. Update
> >> the trace routines to use the latter for all CXL devices on both the CPER
> >> and native AER paths.
> >>
> >> Generalize cxl_aer_correctable_error()/cxl_aer_uncorrectable_error to
> >> take a struct device * and a u64 serial argument supplied by the caller.
> >> cxl_handle_ras() and cxl_handle_cor_ras() gain the new u64 serial parameter,
> >> sourced from pci_get_dsn().
> >>
> >> The CPER path keeps its existing Port-vs-Endpoint dispatch and passes the
> >> new arguments to the unified trace events. The CPER path will be folded
> >> together in a following patch.
> >>
> >> Remove the now-unused cxl_port_aer_correctable_error() and
> >> cxl_port_aer_uncorrectable_error().
> >>
> >> **WARNING: ABI BREAK**
> >> Rename the trace event field "memdev" to "device" so all CXL device types
> >> (Ports and Endpoints) can be reported under a common field name. Note this
> >> is an ABI break for userspace tools that key off the old "memdev" field.
> >> Specifically, rasdaemon's ras-cxl-handler.c looks up "memdev" and bails on
> >> NULL, so an unmodified rasdaemon will drop every CXL CE/UCE event once this
> >> kernel ships. A rasdaemon update is needed in a separate series.
> >>
> >> The need for the field rename was discussed in v16 review [1].
> >
> > This concerns me (sorry I wasn't paying attention to the v16 thread).
> > It is a userspace regression against code that is out in the wild and typically
> > not updated in sync with the kernel.
> >
> > If you are suggesting breaking ras-daemon at the very least +CC the maintainer.
> >
> > To get to a unified tracepoint add a new one that does what you want, but
> > maintain the existing ones as well. Userspace can then migrate and maybe
> > in 5+ years time we can delete the non unified ones.
> >
> > No actually comments on the code, just left it all here for Mauro,
> >
> > Thanks,
> >
> > Jonathan
> >
>
> Dan was clear about using a single set of CE and UE handlers for all CXL RAS
> protocol errors. While I understand there may be concerns, please direct any
> objections to Dan and clarify what changes are required to avoid this
> repeatedly going back and forth.
>
> [1] https://lore.kernel.org/linux-cxl/69cb2d5ba3111_178904100b7@dwillia2-mobl4.notmuch/
Sure - Dan's on this thread so I'm sure he'll see it sooner or later.
Perhaps I'm missing something that makes this less critical than it appears.
You can have a single set of handlers, but at the point of spitting the actual
tracepoints out we need to keep spitting the old ones (+ possibly a new unified
one if you want to one day get rid of the separation.) Bit fiddly but seems
unlikely to be that bad. e.g. put a wrapper where you currently have
trace_cxl_aer_uncorrectable_error() and have that omit the new and old (based
on device type) tracepoints. Then when we eventually drop this after enough
years that we can be sure the new one is in use, the code cleanup is all in
one place.
Note this issue isn't a "maybe" thing - we are talking userspace ABI breakage
in an interface known to be in use in commonly used software that is not
typically updated in time with the kernel cadence. There have been arguments
that some trace points are not 'stable' but that definitely isn't the case for
the RAS ones which are the main interface from kernel to userspace tooling.
In theory you could make such a change and maybe get away with it (on basis
a regression only exists if anyone notices) but you'd need ALL the distros
on board that ship rasdaemon + if you really don't want to end up reverting
you'd have to work closely with the hyperscalers who might decide to throw a
'regression + revert' request at the list which either means a scramble to
put in place what I describe above, or this series being reverted. Note there
are downstream forks of rasdaemon to content with as well.
That pain just isn't worth it.
Mauro, any idea if any distros scan for RAS tracepoints for compatibility breakage?
They probably should like they do of ioctls and similar but no idea if anyone
actually does yet. If they do we'd get the revert request pretty quickly...
If not we get to wait for some one to hit it in a functional test
- thankfully RAS paths are definitely in those test sets but they tend to
run later and hence when a revert / fix is more painful.
Jonathan
^ permalink raw reply
* Re: [PATCH v3 1/3] drm/fdinfo: Add "evicted" memory accounting
From: Nicolas Frattaroli @ 2026-05-08 14:21 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Boris Brezillon, Steven Price, Liviu Dudau,
Jonathan Corbet, Shuah Khan, Tvrtko Ursulin
Cc: dri-devel, linux-kernel, kernel, linux-doc
In-Reply-To: <85d22f7e-af44-4a6e-911f-54830c91e339@ursulin.net>
On Friday, 24 April 2026 18:01:10 Central European Summer Time Tvrtko Ursulin wrote:
>
> On 23/04/2026 13:33, Nicolas Frattaroli wrote:
> > Currently, there's no way to know for certain how much GPU memory was
> > swapped out. The difference between total and resident memory would
> > include newly allocated pages, which are not resident, but also aren't
> > swapped out.
> >
> > Add a new drm_gem_object_status so drivers can signal when an object has
> > been evicted to swap, and add a new "evicted" counter to
> > drm_memory_stats.
> >
> > Due to how the supported_flags bitmask is determined, the "evicted"
> > count won't be printed to fdinfo if there's no swapped out pages.
> >
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> > Documentation/gpu/drm-usage-stats.rst | 6 ++++++
> > drivers/gpu/drm/drm_file.c | 8 ++++++++
> > include/drm/drm_file.h | 2 ++
> > include/drm/drm_gem.h | 2 ++
> > 4 files changed, 18 insertions(+)
> >
> > diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst
> > index 24d3012ca7a6..11570976095e 100644
> > --- a/Documentation/gpu/drm-usage-stats.rst
> > +++ b/Documentation/gpu/drm-usage-stats.rst
> > @@ -200,6 +200,12 @@ One practical example of this could be the presence of unsignaled fences in a
> > GEM buffer reservation object. Therefore, the active category is a subset of the
> > resident category.
> >
> > +- drm-evicted-<region>: <uint> [KiB|MiB]
> > +
> > +The total size of buffers that have been evicted and are currently in swap
> > +space. Only present if there are buffers that are currently swapped out, and the
> > +driver implements reporting of this type of memory.
>
> Please hold off merging this for a few days, I just noticed it and would
> like to set aside some time next week to think about the semantics, how
> it applies to discrete GPUs where evicted != swapped and some other
> questions.
>
> Regards,
>
> Tvrtko
>
It's been more than a few days (2 weeks, in fact), with no follow-up.
I'm getting a little grumpy because people expressing vague concerns,
and then disappearing over the hills for weeks, is an ongoing problem
in the DRM subsystem. If you want me to reword the documentation to
decouple eviction from swapping, then I can do that, but please say
so and then review the follow-up revision so that we're actually
working towards a solution and not just rolling the dice of who saw
the e-mail thread and felt like responding this time around.
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: [PATCH v3 2/2] hwmon: add AMD Promontory 21 xHCI temperature sensor support
From: Jihong Min @ 2026-05-08 14:21 UTC (permalink / raw)
To: Guenter Roeck, Jihong Min
Cc: Greg Kroah-Hartman, Mathias Nyman, Jonathan Corbet, Shuah Khan,
Mario Limonciello, Basavaraj Natikar, linux-usb, linux-hwmon,
linux-doc, linux-pci, linux-kernel
In-Reply-To: <6745fd21-2001-4e06-af41-96ae63154c02@roeck-us.net>
> Yes.
>
> Please note that you keep top-posting. I don't mind that much, but
> top-posting is (sometimes strongly) discouraged for linux kernel
> discussions.
Sorry, this is my first kernel contribution and I was not familiar with the
mailing list convention around top-posting. I will avoid top-posting and use
inline replies from now on.
I have addressed the review comments in v4, including runtime PM behavior,
temp1_label removal, -ENODATA return, the PROM21-specific xHCI PCI glue
split,
and making the PROM21 PCI glue built-in only when enabled. I also
adopted the
naming scheme discussed above:
- drivers/hwmon/prom21-xhci.c
- CONFIG_SENSORS_PROM21_XHCI
- hwmon name: prom21_xhci
I will send v4 now.
Sincerely,
Jihong Min
^ permalink raw reply
* Re: [PATCH v3 1/2] usb: xhci-pci: add generic auxiliary device interface
From: Jihong Min @ 2026-05-08 14:22 UTC (permalink / raw)
To: Guenter Roeck, Mathias Nyman, Jihong Min, Greg Kroah-Hartman,
Mathias Nyman
Cc: Jonathan Corbet, Shuah Khan, Mario Limonciello, Basavaraj Natikar,
linux-usb, linux-hwmon, linux-doc, linux-pci, linux-kernel
In-Reply-To: <e9808463-021b-41cf-8080-0f4e45ae2ebb@roeck-us.net>
> Maybe I am missing something, but it seems to me that
> CONFIG_USB_XHCI_PCI_PROM21
> should be just as built-in as CONFIG_USB_XHCI_PCI.
Agreed. I changed USB_XHCI_PCI_PROM21 to a bool depending on
USB_XHCI_PCI=y, so the PROM21 PCI glue is built in whenever it owns the
PROM21 xHCI PCI binding. The hwmon sensor driver remains optional and can
still be built as a module.
I will include this in v4.
Sincerely,
Jihong Min
^ permalink raw reply
* Re: [PATCH v9 00/22] Enable FRED with KVM VMX
From: Maciej Wieczor-Retman @ 2026-05-08 14:25 UTC (permalink / raw)
To: David Woodhouse
Cc: Andrew Cooper, Xin Li, linux-kernel, kvm, linux-doc,
Saenz Julienne, Nicolas, pbonzini, seanjc, corbet, tglx, mingo,
bp, dave.hansen, x86, hpa, luto, peterz, chao.gao, hch,
sohil.mehta
In-Reply-To: <e2c20e1773b9579ea4cea3b26d7eec02671757f8.camel@infradead.org>
On 2026-05-08 at 00:00:21 +0100, David Woodhouse wrote:
>On Thu, 2026-05-07 at 15:53 +0200, Maciej Wieczor-Retman wrote:
>>
>> My theory is that after 'int3' call the FRED event is handled elsewhere and %rdi
>> is not preserved. So the original version of the assembly looks okay but I was
>> thinking that int3 has side effects.
>
>Please could you try the version at
>https://git.infradead.org/?p=users/dwmw2/linux.git;a=commitdiff;h=fred
>or this incremental patch:
...
>
Just tested it and now it works fine :)
(aside from the ICEBP thing of course but that's on the kernel side)
--
Kind regards
Maciej Wieczór-Retman
^ permalink raw reply
* [PATCH v4 0/2] AMD Promontory 21 xHCI temperature sensor support
From: Jihong Min @ 2026-05-08 14:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Mathias Nyman
Cc: Guenter Roeck, Jonathan Corbet, Shuah Khan, Mario Limonciello,
Basavaraj Natikar, linux-usb, linux-hwmon, linux-doc, linux-pci,
linux-kernel, Jihong Min
This series adds temperature monitoring for AMD Promontory 21 (PROM21)
xHCI PCI functions.
Patch 1 adds a small PROM21-specific xHCI PCI glue driver. USB host
operation is delegated to common xhci-pci code; the PROM21 glue only owns
the PCI binding and publishes an auxiliary "hwmon" child device for
optional sensor support. The glue is built-in only when enabled, matching
built-in xhci-pci, so PROM21 controllers are not left unbound during early
boot if an optional module is absent.
Patch 2 adds the auxiliary hwmon driver. It exposes temp1_input as
prom21_xhci, does not wake the parent PCI device for sensor reads, and
documents the register access and empirical observation method used to
identify the register pair and conversion formula.
Changes in v4:
- Move PROM21 PCI handling into a PROM21-specific xHCI PCI glue driver.
- Make USB_XHCI_PCI_PROM21 built-in only when enabled.
- Rename the hwmon driver/config/name to prom21-xhci,
SENSORS_PROM21_XHCI, and prom21_xhci.
- Return -ENODATA for suspended parent devices and invalid raw values.
- Remove temp1_label and the runtime PM module parameter.
- Simplify hwmon remove/read lifetime handling.
- Expand hwmon documentation with register access, runtime PM behavior,
sysfs lookup, and observation details.
Jihong Min (2):
usb: xhci-pci: add AMD Promontory 21 PCI glue
hwmon: add AMD Promontory 21 xHCI temperature sensor support
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/prom21-xhci.rst | 99 +++++++++++
drivers/hwmon/Kconfig | 10 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/prom21-xhci.c | 250 ++++++++++++++++++++++++++++
drivers/usb/host/Kconfig | 18 ++
drivers/usb/host/Makefile | 1 +
drivers/usb/host/xhci-pci-prom21.c | 111 ++++++++++++
drivers/usb/host/xhci-pci.c | 11 ++
9 files changed, 502 insertions(+)
create mode 100644 Documentation/hwmon/prom21-xhci.rst
create mode 100644 drivers/hwmon/prom21-xhci.c
create mode 100644 drivers/usb/host/xhci-pci-prom21.c
--
2.53.0
^ permalink raw reply
* [PATCH v4 1/2] usb: xhci-pci: add AMD Promontory 21 PCI glue
From: Jihong Min @ 2026-05-08 14:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Mathias Nyman
Cc: Guenter Roeck, Jonathan Corbet, Shuah Khan, Mario Limonciello,
Basavaraj Natikar, linux-usb, linux-hwmon, linux-doc, linux-pci,
linux-kernel, Jihong Min
In-Reply-To: <20260508143910.14673-1-hurryman2212@gmail.com>
AMD Promontory 21 (PROM21) xHCI controllers use generic xHCI
operation, but the PCI function also exposes optional
controller-specific sensor functionality. Add a small PROM21 PCI glue
driver for AMD 1022:43fd controllers.
The driver delegates USB host operation to the common xhci-pci core and
creates a "hwmon" auxiliary device for optional child drivers. Failure
to create the auxiliary device is logged but does not fail the xHCI
probe, since the auxiliary device is only needed for sensor support.
Keep the PROM21 PCI glue built-in only when enabled because it owns the
PCI binding for PROM21 xHCI controllers and must be available whenever
the common built-in xhci-pci driver hands those controllers off. This
avoids an early boot case where generic xhci-pci rejects a PROM21
controller but a modular xhci-pci-prom21 driver is not available in the
initramfs, leaving USB devices behind that controller unavailable.
Assisted-by: Codex:gpt-5.5
Signed-off-by: Jihong Min <hurryman2212@gmail.com>
---
drivers/usb/host/Kconfig | 18 +++++
drivers/usb/host/Makefile | 1 +
drivers/usb/host/xhci-pci-prom21.c | 111 +++++++++++++++++++++++++++++
drivers/usb/host/xhci-pci.c | 11 +++
4 files changed, 141 insertions(+)
create mode 100644 drivers/usb/host/xhci-pci-prom21.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 0a277a07cf70..74eedef1440d 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -42,6 +42,24 @@ config USB_XHCI_PCI
depends on USB_PCI
default y
+config USB_XHCI_PCI_PROM21
+ bool "AMD Promontory 21 xHCI PCI support"
+ depends on USB_XHCI_PCI=y
+ select AUXILIARY_BUS
+ help
+ Say 'Y' to enable support for the AMD Promontory 21 xHCI PCI
+ controller with optional sensor support. This driver does not add
+ PROM21-specific USB or xHCI operation. It binds PROM21 xHCI PCI
+ functions, delegates USB host operation to the common xHCI PCI core,
+ and creates auxiliary devices for optional sensor drivers.
+
+ This driver is built-in only because it owns the PCI binding for
+ PROM21 xHCI controllers when enabled and must be available whenever
+ the common xHCI PCI driver is available. The optional sensor driver
+ can still be built as a module.
+
+ If unsure, say 'N'.
+
config USB_XHCI_PCI_RENESAS
tristate "Support for additional Renesas xHCI controller with firmware"
depends on USB_XHCI_PCI
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index a07e7ba9cd53..174580c1281a 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
obj-$(CONFIG_USB_XHCI_HCD) += xhci-hcd.o
obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
+obj-$(CONFIG_USB_XHCI_PCI_PROM21) += xhci-pci-prom21.o
obj-$(CONFIG_USB_XHCI_PCI_RENESAS) += xhci-pci-renesas.o
obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
obj-$(CONFIG_USB_XHCI_HISTB) += xhci-histb.o
diff --git a/drivers/usb/host/xhci-pci-prom21.c b/drivers/usb/host/xhci-pci-prom21.c
new file mode 100644
index 000000000000..7354a898732e
--- /dev/null
+++ b/drivers/usb/host/xhci-pci-prom21.c
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AMD Promontory 21 xHCI host controller PCI Bus Glue.
+ *
+ * This does not add any PROM21-specific USB or xHCI operation. It exists only
+ * to publish an auxiliary device for integrated temperature sensor support.
+ *
+ * Copyright (C) 2026 Jihong Min <hurryman2212@gmail.com>
+ */
+
+#include <linux/auxiliary_bus.h>
+#include <linux/device/devres.h>
+#include <linux/errno.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/slab.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "xhci-pci.h"
+
+struct prom21_xhci_auxdev {
+ struct auxiliary_device *auxdev;
+};
+
+static void prom21_xhci_auxdev_release(struct device *dev, void *res)
+{
+ struct prom21_xhci_auxdev *prom21_auxdev = res;
+
+ auxiliary_device_destroy(prom21_auxdev->auxdev);
+}
+
+static int prom21_xhci_create_auxdev(struct pci_dev *pdev)
+{
+ struct prom21_xhci_auxdev *prom21_auxdev;
+
+ prom21_auxdev = devres_alloc(prom21_xhci_auxdev_release,
+ sizeof(*prom21_auxdev), GFP_KERNEL);
+ if (!prom21_auxdev)
+ return -ENOMEM;
+
+ prom21_auxdev->auxdev =
+ auxiliary_device_create(&pdev->dev, KBUILD_MODNAME, "hwmon",
+ NULL, (pci_domain_nr(pdev->bus) << 16) |
+ pci_dev_id(pdev));
+ if (!prom21_auxdev->auxdev) {
+ devres_free(prom21_auxdev);
+ return -ENOMEM;
+ }
+
+ devres_add(&pdev->dev, prom21_auxdev);
+ return 0;
+}
+
+static void prom21_xhci_destroy_auxdev(struct pci_dev *pdev)
+{
+ devres_release(&pdev->dev, prom21_xhci_auxdev_release, NULL, NULL);
+}
+
+static int prom21_xhci_probe(struct pci_dev *dev,
+ const struct pci_device_id *id)
+{
+ int retval;
+
+ retval = xhci_pci_common_probe(dev, id);
+ if (retval)
+ return retval;
+
+ retval = prom21_xhci_create_auxdev(dev);
+ if (retval) {
+ /*
+ * The auxiliary device only provides optional temperature sensor
+ * support. Keep the xHCI controller usable if it fails.
+ */
+ dev_err(&dev->dev,
+ "failed to create PROM21 hwmon auxiliary device: %d\n",
+ retval);
+ }
+
+ return 0;
+}
+
+static void prom21_xhci_remove(struct pci_dev *dev)
+{
+ prom21_xhci_destroy_auxdev(dev);
+ xhci_pci_remove(dev);
+}
+
+static const struct pci_device_id pci_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_AMD, 0x43fd) }, /* PROM21 xHCI */
+ { /* end: all zeroes */ }
+};
+MODULE_DEVICE_TABLE(pci, pci_ids);
+
+static struct pci_driver prom21_xhci_driver = {
+ .name = "xhci-pci-prom21",
+ .id_table = pci_ids,
+
+ .probe = prom21_xhci_probe,
+ .remove = prom21_xhci_remove,
+
+ .shutdown = usb_hcd_pci_shutdown,
+ .driver = {
+ .pm = pm_ptr(&usb_hcd_pci_pm_ops),
+ },
+};
+module_pci_driver(prom21_xhci_driver);
+
+MODULE_DESCRIPTION("AMD Promontory 21 xHCI PCI Host Controller Driver");
+MODULE_IMPORT_NS("xhci");
+MODULE_LICENSE("GPL");
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 585b2f3117b0..5db427ad0422 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -84,6 +84,7 @@
#define PCI_DEVICE_ID_AMD_PROMONTORYA_3 0x43ba
#define PCI_DEVICE_ID_AMD_PROMONTORYA_2 0x43bb
#define PCI_DEVICE_ID_AMD_PROMONTORYA_1 0x43bc
+#define PCI_DEVICE_ID_AMD_PROM21_XHCI 0x43fd
#define PCI_DEVICE_ID_ATI_NAVI10_7316_XHCI 0x7316
@@ -696,12 +697,22 @@ static const struct pci_device_id pci_ids_renesas[] = {
{ /* end: all zeroes */ }
};
+/* handled by xhci-pci-prom21 if enabled */
+static const struct pci_device_id pci_ids_prom21[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_PROM21_XHCI) },
+ { /* end: all zeroes */ }
+};
+
static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
if (IS_ENABLED(CONFIG_USB_XHCI_PCI_RENESAS) &&
pci_match_id(pci_ids_renesas, dev))
return -ENODEV;
+ if (IS_ENABLED(CONFIG_USB_XHCI_PCI_PROM21) &&
+ pci_match_id(pci_ids_prom21, dev))
+ return -ENODEV;
+
return xhci_pci_common_probe(dev, id);
}
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/2] hwmon: add AMD Promontory 21 xHCI temperature sensor support
From: Jihong Min @ 2026-05-08 14:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Mathias Nyman
Cc: Guenter Roeck, Jonathan Corbet, Shuah Khan, Mario Limonciello,
Basavaraj Natikar, linux-usb, linux-hwmon, linux-doc, linux-pci,
linux-kernel, Jihong Min
In-Reply-To: <20260508143910.14673-1-hurryman2212@gmail.com>
Add an auxiliary-bus hwmon driver for the temperature sensor exposed by
AMD Promontory 21 (PROM21) xHCI PCI functions. The driver binds to the
"hwmon" auxiliary device published by the PROM21 xHCI PCI glue and
exposes the sensor as temp1_input under the prom21_xhci hwmon device.
The sensor is accessed through a PROM21 vendor index/data register pair
in the xHCI PCI MMIO BAR. The read path restores the previous vendor
index value after sampling and does not runtime-resume the parent PCI
device; reads from a suspended parent return -ENODATA.
Document the supported device, register access, runtime PM behavior, and
sysfs lookup method. The documentation also records the observation
method used to identify the register pair and derive the conversion
formula.
Assisted-by: Codex:gpt-5.5
Signed-off-by: Jihong Min <hurryman2212@gmail.com>
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/prom21-xhci.rst | 99 +++++++++++
drivers/hwmon/Kconfig | 10 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/prom21-xhci.c | 250 ++++++++++++++++++++++++++++
5 files changed, 361 insertions(+)
create mode 100644 Documentation/hwmon/prom21-xhci.rst
create mode 100644 drivers/hwmon/prom21-xhci.c
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 8b655e5d6b68..324208f1faa2 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -216,6 +216,7 @@ Hardware Monitoring Kernel Drivers
pmbus
powerz
powr1220
+ prom21-xhci
pt5161l
pxe1610
pwm-fan
diff --git a/Documentation/hwmon/prom21-xhci.rst b/Documentation/hwmon/prom21-xhci.rst
new file mode 100644
index 000000000000..10d03c4476c3
--- /dev/null
+++ b/Documentation/hwmon/prom21-xhci.rst
@@ -0,0 +1,99 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver prom21-xhci
+=========================
+
+Supported chips:
+
+ * AMD Promontory 21 (PROM21) xHCI
+
+ Prefix: 'prom21_xhci'
+
+ PCI ID: 1022:43fd
+
+Author:
+
+ - Jihong Min <hurryman2212@gmail.com>
+
+Description
+-----------
+
+This driver exposes the temperature sensor in AMD PROM21 xHCI controllers.
+
+The driver binds to an auxiliary device created by the xHCI PCI driver for
+supported controllers. The sensor value is accessed through a vendor-specific
+index/data register pair in the controller's PCI MMIO BAR.
+The auxiliary device is created by the ``xhci-pci-prom21`` PCI glue driver.
+USB host operation is otherwise delegated to the common ``xhci-pci`` code.
+
+PROM21 is an AMD chipset IP used in single-chip or daisy-chained configurations
+to build AMD 6xx/8xx series chipsets. Since the xHCI controllers are
+integrated in PROM21, this temperature can also be used as a monitor for a
+temperature close to the AMD chipset temperature.
+
+Register access
+---------------
+
+The temperature value is read through a vendor-specific index/data register
+pair in the xHCI PCI MMIO BAR. The driver uses the following byte offsets from
+the MMIO BAR base:
+
+======================= =====================================================
+0x3000 Vendor index register
+0x3008 Vendor data register
+======================= =====================================================
+
+The driver saves the current vendor index register value, writes the
+temperature selector ``0x0001e520`` to the vendor index register, reads the
+vendor data register, and restores the previous vendor index value before
+returning. The raw temperature value is the low 8 bits of the vendor data
+register value.
+
+No public AMD reference is available for the register pair or the raw value.
+The register pair was identified on an X870E system with two PROM21 xHCI
+controllers. One controller was passed through to a Windows VM, and the same
+controller's PCI MMIO BAR was observed from the Linux host while HWiNFO64 was
+reporting the PROM21 xHCI temperature. In the test environment, the reported
+temperature was very stable at idle and the displayed sensor resolution was
+low, which made it possible to look for a consistently repeating MMIO response
+for the same reported temperature. During observation, offset 0x3000 repeatedly
+contained selector ``0x0001e520``. Writing the same selector to offset 0x3000
+from Linux and then reading offset 0x3008 reproduced the same raw value, so the
+offsets are treated as a vendor index/data register pair.
+
+The conversion formula was empirically inferred by matching observed raw
+8-bit values against HWiNFO64's reported PROM21 xHCI temperature for the same
+controller. The observed mapping is:
+
+ temp[C] = raw * 0.9066 - 78.624
+
+Runtime PM
+----------
+
+The driver does not wake the xHCI PCI device for hwmon reads. It reads the
+temperature only when the parent device is already active. A read from a
+suspended device returns ``-ENODATA``. Sensor reads do not mark the xHCI PCI
+device as busy or schedule autosuspend, so polling the sensor does not delay
+runtime suspend.
+
+Sysfs entries
+-------------
+
+======================= =====================================================
+temp1_input Temperature in millidegrees Celsius
+======================= =====================================================
+
+The hwmon device name is ``prom21_xhci``. The sysfs path depends on the hwmon
+device number assigned by the kernel. Userspace can locate the device by
+matching the ``name`` attribute:
+
+.. code-block:: sh
+
+ for hwmon in /sys/class/hwmon/hwmon*; do
+ [ "$(cat "$hwmon/name")" = "prom21_xhci" ] || continue
+ cat "$hwmon/temp1_input"
+ done
+
+``temp1_input`` reports millidegrees Celsius, so a value of ``50113`` means
+50.113 degrees Celsius. If the raw register value is invalid, ``temp1_input``
+returns ``-ENODATA``.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 14e4cea48acc..fe0f14e247b5 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -951,6 +951,16 @@ config SENSORS_POWR1220
This driver can also be built as a module. If so, the module
will be called powr1220.
+config SENSORS_PROM21_XHCI
+ tristate "AMD Promontory 21 xHCI temperature sensor"
+ depends on USB_XHCI_PCI_PROM21
+ help
+ If you say yes here you get support for the AMD Promontory 21
+ (PROM21) xHCI temperature sensor.
+
+ This driver can also be built as a module. If so, the module
+ will be called prom21-xhci.
+
config SENSORS_LAN966X
tristate "Microchip LAN966x Hardware Monitoring"
depends on SOC_LAN966 || COMPILE_TEST
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 4788996aa137..0bda542e8e2b 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -196,6 +196,7 @@ obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
obj-$(CONFIG_SENSORS_POWERZ) += powerz.o
obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
+obj-$(CONFIG_SENSORS_PROM21_XHCI) += prom21-xhci.o
obj-$(CONFIG_SENSORS_PT5161L) += pt5161l.o
obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
obj-$(CONFIG_SENSORS_QNAP_MCU_HWMON) += qnap-mcu-hwmon.o
diff --git a/drivers/hwmon/prom21-xhci.c b/drivers/hwmon/prom21-xhci.c
new file mode 100644
index 000000000000..f91303ce3428
--- /dev/null
+++ b/drivers/hwmon/prom21-xhci.c
@@ -0,0 +1,250 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AMD Promontory 21 xHCI Hwmon Implementation
+ * (only temperature monitoring is supported)
+ *
+ * This can be effectively used as the alternative chipset temperature monitor.
+ *
+ * Copyright (C) 2026 Jihong Min <hurryman2212@gmail.com>
+ */
+
+#include <linux/auxiliary_bus.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/hwmon.h>
+#include <linux/io.h>
+#include <linux/math.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/pci.h>
+#include <linux/pm_runtime.h>
+#include <linux/slab.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#define PROM21_INDEX 0x3000
+#define PROM21_DATA 0x3008
+#define PROM21_TEMP_REG 0x0001e520
+
+struct prom21_xhci {
+ struct pci_dev *pdev;
+ struct device *hwmon_dev;
+ void __iomem *regs;
+ struct mutex lock; /* serializes index/data register access */
+};
+
+static int prom21_xhci_pm_get(struct prom21_xhci *hwmon, bool *pm_ref)
+{
+ struct device *dev = &hwmon->pdev->dev;
+ int ret;
+
+ *pm_ref = false;
+
+ /*
+ * PROM21 temperature register access does not return a valid value while
+ * the parent xHCI PCI function is suspended. Do not wake the device from
+ * a hwmon read; only read when runtime PM reports the device as active,
+ * or when runtime PM is disabled and the device is not marked as
+ * suspended.
+ */
+ ret = pm_runtime_get_if_active(dev);
+ if (ret > 0) {
+ *pm_ref = true;
+ return 0;
+ }
+
+ if (ret == -EINVAL && !pm_runtime_status_suspended(dev))
+ return 0;
+
+ if (!ret || pm_runtime_status_suspended(dev))
+ return -ENODATA;
+
+ return ret;
+}
+
+/*
+ * This is not a pure MMIO read. The PROM21 vendor data register is selected
+ * by temporarily writing PROM21_TEMP_REG to the vendor index register.
+ * Serialize the sequence, keep it short, and restore the previous index before
+ * returning so this driver does not leave the vendor index/data register pair
+ * in a different state for other possible users.
+ */
+static int prom21_xhci_read_temp_raw_restore_index(struct prom21_xhci *hwmon,
+ u8 *raw)
+{
+ struct device *dev = &hwmon->pdev->dev;
+ bool pm_ref;
+ u32 index;
+ u32 data;
+ int ret;
+
+ ret = prom21_xhci_pm_get(hwmon, &pm_ref);
+ if (ret)
+ return ret;
+
+ mutex_lock(&hwmon->lock);
+ index = readl(hwmon->regs + PROM21_INDEX);
+ /* Select the PROM21 temperature register through the vendor index. */
+ writel(PROM21_TEMP_REG, hwmon->regs + PROM21_INDEX);
+ data = readl(hwmon->regs + PROM21_DATA);
+ /* Restore the previous vendor index register value. */
+ writel(index, hwmon->regs + PROM21_INDEX);
+ readl(hwmon->regs + PROM21_INDEX);
+ mutex_unlock(&hwmon->lock);
+
+ if (pm_ref) {
+ /*
+ * Drop only the reference taken by pm_runtime_get_if_active().
+ * Do not mark the device busy or schedule autosuspend from the
+ * hwmon path; sensor polling must not keep the xHCI PCI device
+ * active.
+ */
+ pm_runtime_put_noidle(dev);
+ }
+
+ *raw = data & 0xff;
+ if (!*raw || *raw == 0xff)
+ return -ENODATA;
+
+ return 0;
+}
+
+static long prom21_xhci_raw_to_millicelsius(u8 raw)
+{
+ /*
+ * No public AMD reference is available for this value.
+ * The scale was derived from observed PROM21 xHCI temperature readings:
+ * temp[C] = raw * 0.9066 - 78.624
+ */
+ return DIV_ROUND_CLOSEST(raw * 9066, 10) - 78624;
+}
+
+static umode_t prom21_xhci_is_visible(const void *drvdata,
+ enum hwmon_sensor_types type, u32 attr,
+ int channel)
+{
+ if (type != hwmon_temp || channel)
+ return 0;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static int prom21_xhci_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *val)
+{
+ struct prom21_xhci *hwmon = dev_get_drvdata(dev);
+ u8 raw;
+ int ret;
+
+ if (type != hwmon_temp || attr != hwmon_temp_input || channel)
+ return -EOPNOTSUPP;
+
+ ret = prom21_xhci_read_temp_raw_restore_index(hwmon, &raw);
+ if (ret)
+ return ret;
+
+ *val = prom21_xhci_raw_to_millicelsius(raw);
+ return 0;
+}
+
+static const struct hwmon_ops prom21_xhci_ops = {
+ .is_visible = prom21_xhci_is_visible,
+ .read = prom21_xhci_read,
+};
+
+static const struct hwmon_channel_info *const prom21_xhci_info[] = {
+ HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
+ NULL,
+};
+
+static const struct hwmon_chip_info prom21_xhci_chip_info = {
+ .ops = &prom21_xhci_ops,
+ .info = prom21_xhci_info,
+};
+
+static int prom21_xhci_probe(struct auxiliary_device *auxdev,
+ const struct auxiliary_device_id *id)
+{
+ struct device *dev = &auxdev->dev;
+ struct device *parent = dev->parent;
+ struct prom21_xhci *hwmon;
+ struct pci_dev *pdev;
+ struct usb_hcd *hcd;
+ int ret;
+
+ if (!parent || !dev_is_pci(parent))
+ return -ENODEV;
+
+ pdev = to_pci_dev(parent);
+ hcd = pci_get_drvdata(pdev);
+ if (!hcd)
+ return dev_err_probe(dev, -ENODEV,
+ "xHCI HCD data unavailable\n");
+
+ if (!hcd->regs || hcd->rsrc_len < PROM21_DATA + sizeof(u32))
+ return dev_err_probe(dev, -ENODEV, "invalid MMIO resource\n");
+
+ hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
+ if (!hwmon)
+ return -ENOMEM;
+
+ ret = devm_mutex_init(dev, &hwmon->lock);
+ if (ret)
+ return ret;
+
+ hwmon->pdev = pdev;
+ hwmon->regs = hcd->regs;
+ auxiliary_set_drvdata(auxdev, hwmon);
+
+ /*
+ * Use the PCI function as the hwmon parent so user space reports it as
+ * a PCI adapter. Lifetime is still owned by this auxiliary driver;
+ * remove() unregisters the hwmon device before xhci-pci tears down the
+ * HCD.
+ */
+ hwmon->hwmon_dev =
+ hwmon_device_register_with_info(&pdev->dev, "prom21_xhci",
+ hwmon, &prom21_xhci_chip_info,
+ NULL);
+ if (IS_ERR(hwmon->hwmon_dev))
+ return PTR_ERR(hwmon->hwmon_dev);
+
+ return 0;
+}
+
+static void prom21_xhci_remove(struct auxiliary_device *auxdev)
+{
+ struct prom21_xhci *hwmon = auxiliary_get_drvdata(auxdev);
+
+ /*
+ * The PROM21 PCI glue destroys the auxiliary device before HCD teardown.
+ * Unregister the hwmon device here so sysfs removes the attributes,
+ * stops new reads, and drains active hwmon callbacks before the xHCI
+ * MMIO mapping is released.
+ */
+ hwmon_device_unregister(hwmon->hwmon_dev);
+}
+
+static const struct auxiliary_device_id prom21_xhci_id_table[] = {
+ { .name = "xhci_pci_prom21.hwmon" },
+ {}
+};
+MODULE_DEVICE_TABLE(auxiliary, prom21_xhci_id_table);
+
+static struct auxiliary_driver prom21_xhci_driver = {
+ .name = "prom21-xhci",
+ .probe = prom21_xhci_probe,
+ .remove = prom21_xhci_remove,
+ .id_table = prom21_xhci_id_table,
+};
+module_auxiliary_driver(prom21_xhci_driver);
+
+MODULE_AUTHOR("Jihong Min <hurryman2212@gmail.com>");
+MODULE_DESCRIPTION("AMD Promontory 21 xHCI temperature sensor driver");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v9 00/22] Enable FRED with KVM VMX
From: David Woodhouse @ 2026-05-08 14:46 UTC (permalink / raw)
To: Maciej Wieczor-Retman
Cc: Andrew Cooper, Xin Li, linux-kernel, kvm, linux-doc,
Saenz Julienne, Nicolas, pbonzini, seanjc, corbet, tglx, mingo,
bp, dave.hansen, x86, hpa, luto, peterz, chao.gao, hch,
sohil.mehta
In-Reply-To: <af3x4nukic9smHdX@wieczorr-mobl1.localdomain>
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
On Fri, 2026-05-08 at 16:25 +0200, Maciej Wieczor-Retman wrote:
>
> Just tested it and now it works fine :)
Great, thanks. Including the __attribute__((used)) part?
> (aside from the ICEBP thing of course but that's on the kernel side)
Well yes, that was kind of the point in generating the selftest.
I don't have access to hardware right now, but I can do test driven
development by proxy... :)
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 1/8] net: convert netmem_tx flag to enum
From: Stanislav Fomichev @ 2026-05-08 14:56 UTC (permalink / raw)
To: Bobby Eshleman
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan, Alex Shi,
Yanteng Si, Dongliang Mu, Michael Chan, Pavan Chebbi,
Joshua Washington, Harshitha Ramamurthy, Saeed Mahameed,
Tariq Toukan, Mark Bloch, Leon Romanovsky, Alexander Duyck,
kernel-team, Daniel Borkmann, Nikolay Aleksandrov, Shuah Khan, dw,
mohsin.bashr, willemb, jiang.kun2, xu.xin16, wang.yaxin, netdev,
linux-doc, linux-kernel, linux-rdma, bpf, linux-kselftest,
Stanislav Fomichev, Mina Almasry, Bobby Eshleman
In-Reply-To: <20260507-tcp-dm-netkit-v3-1-52821445867c@meta.com>
On 05/07, Bobby Eshleman wrote:
> From: Bobby Eshleman <bobbyeshleman@meta.com>
>
> Devices that support netmem TX previously set dev->netmem_tx = true.
> This was checked in validate_xmit_unreadable_skb() to drop unreadable
> skbs (skbs with dmabuf-backed frags) before they reach drivers that
> would mishandle them or devices that would not have the iommu mappings
> for them.
>
> A subsequent patch will introduce a third state for virtual devices
> that forward unreadable skbs without ever performing DMA on them. To
> prepare for that, convert the boolean dev->netmem_tx into an enum:
>
> NETMEM_TX_NONE - no netmem TX support (drop unreadable skbs)
> NETMEM_TX_DMA - full support, device does DMA
>
> Update the existing NIC drivers (bnxt, gve, mlx5, fbnic) and the
> validators in net/core to use the new enum. No functional change.
>
> Acked-by: Harshitha Ramamurthy <hramamurthy@google.com>
> Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
> ---
> Changes in v3:
> - Split NO_DMA changes into subsequent commit (Jakub)
> - Move !netdev->netmem_tx -> netdev->netmem_tx ==
> NETMEM_TX_NONE conversions to this patch (Jakub)
>
> Changes in v2:
> - Squash driver conversion patches (2-5) into patch 1 (Jakub)
> ---
> Documentation/networking/netmem.rst | 5 ++++-
> Documentation/translations/zh_CN/networking/netmem.rst | 4 +++-
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
> drivers/net/ethernet/google/gve/gve_main.c | 2 +-
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +-
> drivers/net/ethernet/meta/fbnic/fbnic_netdev.c | 2 +-
> include/linux/netdevice.h | 8 +++++++-
> net/core/dev.c | 2 +-
> net/core/netdev-genl.c | 2 +-
> 9 files changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/networking/netmem.rst b/Documentation/networking/netmem.rst
> index b63aded46337..5ccadba4f373 100644
> --- a/Documentation/networking/netmem.rst
> +++ b/Documentation/networking/netmem.rst
> @@ -95,4 +95,7 @@ Driver TX Requirements
> netdev@, or reach out to the maintainers and/or almasrymina@google.com for
> help adding the netmem API.
>
> -2. Driver should declare support by setting `netdev->netmem_tx = true`
> +2. Driver should declare support by setting `netdev->netmem_tx` to the
> + appropriate mode:
> +
> + - `NETMEM_TX_DMA`: for physical devices that perform DMA.
> diff --git a/Documentation/translations/zh_CN/networking/netmem.rst b/Documentation/translations/zh_CN/networking/netmem.rst
> index fe351a240f02..9c84423b7528 100644
> --- a/Documentation/translations/zh_CN/networking/netmem.rst
> +++ b/Documentation/translations/zh_CN/networking/netmem.rst
> @@ -89,4 +89,6 @@ dma-mapping API 去处理。
> 使用某个还不存在的 netmem API，你可以自行添加并提交到 netdev@，也可以联系维护
> 人员或者发送邮件至 almasrymina@google.com 寻求帮助。
>
> -2. 驱动程序应通过设置 netdev->netmem_tx = true 来表明自身支持 netmem 功能。
> +2. 驱动程序应将 `netdev->netmem_tx` 设置为适当的模式：
> +
> + - `NETMEM_TX_DMA`：适用于执行 DMA 的物理设备。
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> index 8c55874f44ca..ed9c22dc4a5a 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> @@ -17120,7 +17120,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> dev->queue_mgmt_ops = &bnxt_queue_mgmt_ops_unsupp;
> if (BNXT_SUPPORTS_QUEUE_API(bp))
> dev->queue_mgmt_ops = &bnxt_queue_mgmt_ops;
> - dev->netmem_tx = true;
> + dev->netmem_tx = NETMEM_TX_DMA;
>
> rc = register_netdev(dev);
> if (rc)
> diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
> index 424d973c97f2..dd2b8f087163 100644
> --- a/drivers/net/ethernet/google/gve/gve_main.c
> +++ b/drivers/net/ethernet/google/gve/gve_main.c
> @@ -2894,7 +2894,7 @@ static int gve_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> goto abort_with_wq;
>
> if (!gve_is_gqi(priv) && !gve_is_qpl(priv))
> - dev->netmem_tx = true;
> + dev->netmem_tx = NETMEM_TX_DMA;
>
> err = register_netdev(dev);
> if (err)
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 5a46870c4b74..fc49aae38807 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -5924,7 +5924,7 @@ static void mlx5e_build_nic_netdev(struct net_device *netdev)
>
> netdev->priv_flags |= IFF_UNICAST_FLT;
>
> - netdev->netmem_tx = true;
> + netdev->netmem_tx = NETMEM_TX_DMA;
>
> netif_set_tso_max_size(netdev, GSO_MAX_SIZE);
> mlx5e_set_xdp_feature(priv);
> diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
> index c406a3b56b37..138e522ef9b9 100644
> --- a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
> +++ b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
> @@ -752,7 +752,7 @@ struct net_device *fbnic_netdev_alloc(struct fbnic_dev *fbd)
> netdev->netdev_ops = &fbnic_netdev_ops;
> netdev->stat_ops = &fbnic_stat_ops;
> netdev->queue_mgmt_ops = &fbnic_queue_mgmt_ops;
> - netdev->netmem_tx = true;
> + netdev->netmem_tx = NETMEM_TX_DMA;
>
> fbnic_set_ethtool_ops(netdev);
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 0e1e581efc5a..580bccb118a0 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1788,6 +1788,11 @@ enum netdev_stat_type {
> NETDEV_PCPU_STAT_DSTATS, /* struct pcpu_dstats */
> };
>
> +enum netmem_tx_mode {
> + NETMEM_TX_NONE, /* no netmem TX support */
> + NETMEM_TX_DMA, /* DMA-capable netmem TX (real HW) */
> +};
> +
> enum netdev_reg_state {
> NETREG_UNINITIALIZED = 0,
> NETREG_REGISTERED, /* completed register_netdevice */
> @@ -1809,7 +1814,8 @@ enum netdev_reg_state {
> * @lltx: device supports lockless Tx. Deprecated for real HW
> * drivers. Mainly used by logical interfaces, such as
> * bonding and tunnels
> - * @netmem_tx: device support netmem_tx.
> + * @netmem_tx: device netmem TX mode (NETMEM_TX_NONE or
> + * NETMEM_TX_DMA).
nit: if you happen to repost, listing enum values here seems too much?
"device netmem TX mode" should be enough
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
^ permalink raw reply
* Re: [PATCH net-next v3 2/8] net: netkit: declare NETMEM_TX_NO_DMA mode
From: Stanislav Fomichev @ 2026-05-08 14:57 UTC (permalink / raw)
To: Bobby Eshleman
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan, Alex Shi,
Yanteng Si, Dongliang Mu, Michael Chan, Pavan Chebbi,
Joshua Washington, Harshitha Ramamurthy, Saeed Mahameed,
Tariq Toukan, Mark Bloch, Leon Romanovsky, Alexander Duyck,
kernel-team, Daniel Borkmann, Nikolay Aleksandrov, Shuah Khan, dw,
mohsin.bashr, willemb, jiang.kun2, xu.xin16, wang.yaxin, netdev,
linux-doc, linux-kernel, linux-rdma, bpf, linux-kselftest,
Stanislav Fomichev, Mina Almasry, Bobby Eshleman
In-Reply-To: <20260507-tcp-dm-netkit-v3-2-52821445867c@meta.com>
On 05/07, Bobby Eshleman wrote:
> From: Bobby Eshleman <bobbyeshleman@meta.com>
>
> Some virtual devices like netkit (or ifb) never DMA and never touch frag
> contents, they just forward the skb to another device. They are unable
> to forward unreadable skbs, however, because they fail to pass TX
> validation checks on dev->netmem_tx. The existing two-state
> NETMEM_TX_NONE / NETMEM_TX_DMA doesn't give the TX validator enough
> information to differentiate devices that will attempt DMA on the
> unreadable skb from those that will simply route it untouched.
>
> Add a third mode to the enum so drivers can indicate 1) if they have
> netmem TX support, and 2) if they do, whether they are DMA-capable:
>
> NETMEM_TX_NO_DMA - pass-through, device never DMAs
>
> Widen dev->netmem_tx from a 1-bit field to 2 bits to fit the new value,
> and declare netkit as NETMEM_TX_NO_DMA. Devmem TX support over these
> devices comes in a follow-up patch.
>
> Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
^ permalink raw reply
* Re: [PATCH net-next v3 3/8] net: devmem: support TX over NETMEM_TX_NO_DMA devices
From: Stanislav Fomichev @ 2026-05-08 15:01 UTC (permalink / raw)
To: Bobby Eshleman
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan, Alex Shi,
Yanteng Si, Dongliang Mu, Michael Chan, Pavan Chebbi,
Joshua Washington, Harshitha Ramamurthy, Saeed Mahameed,
Tariq Toukan, Mark Bloch, Leon Romanovsky, Alexander Duyck,
kernel-team, Daniel Borkmann, Nikolay Aleksandrov, Shuah Khan, dw,
mohsin.bashr, willemb, jiang.kun2, xu.xin16, wang.yaxin, netdev,
linux-doc, linux-kernel, linux-rdma, bpf, linux-kselftest,
Stanislav Fomichev, Mina Almasry, Bobby Eshleman
In-Reply-To: <20260507-tcp-dm-netkit-v3-3-52821445867c@meta.com>
On 05/07, Bobby Eshleman wrote:
> From: Bobby Eshleman <bobbyeshleman@meta.com>
>
> When a netkit virtual device leases queues from a physical NIC, devmem
> TX bindings created on the netkit device must still result in the dmabuf
> being mapped for dma by the physical device. This patch accomplishes
> this by teaching the bind handler to search for the underlying
> DMA-capable device by looking it up via leased rx queues. The function
> netdev_find_netmem_tx_dev(), used for finding the underlying DMA-capable
> device, can be extended to support other non-netkit NETMEM_TX_NO_DMA
> devices in the future if needed.
>
> Additionally, this patch extends validate_xmit_unreadable_skb() to
> support the netkit case, where the skb is validated twice: once on the
> netkit guest device and again on the physical NIC after BPF redirect or
> ip forwarding.
>
> Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
> ---
> Changes in v3:
> - Fix validate_xmit_unreadable_skb() bug for non-devmem
> unreadable niovs (should not be dropped)
> - Major simplification of validate_xmit_unreadable_skb()
> - Fix prematurely released lock in bind-tx handler (Jakub)
>
> Changes in v2:
> - In validate_xmit_unreadable_skb() to check netmem_tx mode before
> inspecting frags (Jakub)
> - Lock bind_dev around netdev_queue_get_dma_dev() when bind_dev !=
> netdev to fix lockdep (Sashiko)
> ---
> net/core/dev.c | 3 +++
> net/core/devmem.c | 6 +++--
> net/core/devmem.h | 9 ++++++--
> net/core/netdev-genl.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++----
> 4 files changed, 72 insertions(+), 9 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index fbe4c328a367..268417c9ef22 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3999,6 +3999,9 @@ static struct sk_buff *validate_xmit_unreadable_skb(struct sk_buff *skb,
> if (dev->netmem_tx == NETMEM_TX_NONE)
> goto out_free;
>
> + if (dev->netmem_tx == NETMEM_TX_NO_DMA)
> + goto out;
> +
Since this is a good case, maybe fold it into skb_frags_readable check above?
if (likely(skb_frags_readable() || netmem_tx == NETMEM_TX_NO_DMA))
Otherwise it's a bit confusing to have:
if (xxx)
goto out;
if (yyy)
goto out_free;
if (zzz)
goto out;
(or, reorder to be out/out/out_free)
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
^ permalink raw reply
* Re: [PATCH net-next v3 4/8] selftests: drv-net: ncdevmem: add -n flag to skip NIC configuration
From: Stanislav Fomichev @ 2026-05-08 15:01 UTC (permalink / raw)
To: Bobby Eshleman
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan, Alex Shi,
Yanteng Si, Dongliang Mu, Michael Chan, Pavan Chebbi,
Joshua Washington, Harshitha Ramamurthy, Saeed Mahameed,
Tariq Toukan, Mark Bloch, Leon Romanovsky, Alexander Duyck,
kernel-team, Daniel Borkmann, Nikolay Aleksandrov, Shuah Khan, dw,
mohsin.bashr, willemb, jiang.kun2, xu.xin16, wang.yaxin, netdev,
linux-doc, linux-kernel, linux-rdma, bpf, linux-kselftest,
Stanislav Fomichev, Mina Almasry, Bobby Eshleman
In-Reply-To: <20260507-tcp-dm-netkit-v3-4-52821445867c@meta.com>
On 05/07, Bobby Eshleman wrote:
> From: Bobby Eshleman <bobbyeshleman@meta.com>
>
> Add a -n (skip_config) flag that causes ncdevmem to skip NIC
> configuration when operating as an RX server. When -n is passed,
> ncdevmem skips configuring header split, RSS, and flow steering, as well
> as their teardown on exit.
>
> This allows ksft tests to pre-configure the NIC in the host namespace
> before launching ncdevmem in the guest namespace. This is needed for
> netkit devmem tests where the test harness namespace has direct access
> to the NIC and the ncdevmem namespace does not.
>
> Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: trivial-devices: Add Delta E50SN12051
From: Conor Dooley @ 2026-05-08 15:01 UTC (permalink / raw)
To: u8813345
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Chang, Jonathan Corbet, Shuah Khan, linux-hwmon, devicetree,
linux-kernel, linux-doc, Colin Huang
In-Reply-To: <20260508-add-e50sn12051-v5-1-abebdcc29665@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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