* Re: [PATCH v5 3/4] iio: adc: ad4691: add triggered buffer support
From: kernel test robot @ 2026-03-30 23:50 UTC (permalink / raw)
To: Radu Sabau via B4 Relay, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: oe-kbuild-all, linux-iio, devicetree, linux-kernel, linux-pwm,
linux-gpio, linux-doc, Radu Sabau
In-Reply-To: <20260327-ad4692-multichannel-sar-adc-driver-v5-3-11f789de47b8@analog.com>
Hi Radu,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 11439c4635edd669ae435eec308f4ab8a0804808]
url: https://github.com/intel-lab-lkp/linux/commits/Radu-Sabau-via-B4-Relay/dt-bindings-iio-adc-add-AD4691-family/20260330-200546
base: 11439c4635edd669ae435eec308f4ab8a0804808
patch link: https://lore.kernel.org/r/20260327-ad4692-multichannel-sar-adc-driver-v5-3-11f789de47b8%40analog.com
patch subject: [PATCH v5 3/4] iio: adc: ad4691: add triggered buffer support
config: i386-randconfig-r131-20260331 (https://download.01.org/0day-ci/archive/20260331/202603310753.zLWq0JDB-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
sparse: v0.6.5-rc1
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260331/202603310753.zLWq0JDB-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603310753.zLWq0JDB-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/iio/adc/ad4691.c:675:47: sparse: sparse: dereference of noderef expression
>> drivers/iio/adc/ad4691.c:675:47: sparse: sparse: dereference of noderef expression
drivers/iio/adc/ad4691.c:757:47: sparse: sparse: dereference of noderef expression
drivers/iio/adc/ad4691.c:757:47: sparse: sparse: dereference of noderef expression
drivers/iio/adc/ad4691.c:809:46: sparse: sparse: dereference of noderef expression
drivers/iio/adc/ad4691.c:809:46: sparse: sparse: dereference of noderef expression
drivers/iio/adc/ad4691.c:815:40: sparse: sparse: dereference of noderef expression
drivers/iio/adc/ad4691.c:815:40: sparse: sparse: dereference of noderef expression
drivers/iio/adc/ad4691.c: note: in included file:
include/linux/bitmap.h:797:55: sparse: sparse: shift too big (32) for type unsigned long
include/linux/bitmap.h:797:55: sparse: sparse: shift too big (32) for type unsigned long
vim +675 drivers/iio/adc/ad4691.c
668
669 static int ad4691_manual_buffer_preenable(struct iio_dev *indio_dev)
670 {
671 struct ad4691_state *st = iio_priv(indio_dev);
672 struct device *dev = regmap_get_device(st->regmap);
673 struct spi_device *spi = to_spi_device(dev);
674 unsigned int n_active = bitmap_weight(indio_dev->active_scan_mask,
> 675 indio_dev->masklength);
676 unsigned int n_xfers = n_active + 1;
677 unsigned int k, i;
678 int ret;
679
680 st->scan_xfers = kcalloc(n_xfers, sizeof(*st->scan_xfers), GFP_KERNEL);
681 if (!st->scan_xfers)
682 return -ENOMEM;
683
684 st->scan_tx = kcalloc(n_xfers, sizeof(*st->scan_tx), GFP_KERNEL);
685 if (!st->scan_tx) {
686 kfree(st->scan_xfers);
687 return -ENOMEM;
688 }
689
690 st->scan_rx = kcalloc(n_xfers, sizeof(*st->scan_rx), GFP_KERNEL);
691 if (!st->scan_rx) {
692 kfree(st->scan_tx);
693 kfree(st->scan_xfers);
694 return -ENOMEM;
695 }
696
697 spi_message_init(&st->scan_msg);
698
699 k = 0;
700 iio_for_each_active_channel(indio_dev, i) {
701 st->scan_tx[k] = cpu_to_be16(AD4691_ADC_CHAN(i));
702 st->scan_xfers[k].tx_buf = &st->scan_tx[k];
703 st->scan_xfers[k].rx_buf = &st->scan_rx[k];
704 st->scan_xfers[k].len = sizeof(__be16);
705 st->scan_xfers[k].cs_change = 1;
706 spi_message_add_tail(&st->scan_xfers[k], &st->scan_msg);
707 k++;
708 }
709
710 /* Final NOOP transfer to retrieve last channel's result. */
711 st->scan_tx[k] = cpu_to_be16(AD4691_NOOP);
712 st->scan_xfers[k].tx_buf = &st->scan_tx[k];
713 st->scan_xfers[k].rx_buf = &st->scan_rx[k];
714 st->scan_xfers[k].len = sizeof(__be16);
715 spi_message_add_tail(&st->scan_xfers[k], &st->scan_msg);
716
717 st->scan_msg.spi = spi;
718
719 ret = spi_optimize_message(spi, &st->scan_msg);
720 if (ret) {
721 ad4691_free_scan_bufs(st);
722 return ret;
723 }
724
725 ret = ad4691_enter_conversion_mode(st);
726 if (ret) {
727 spi_unoptimize_message(&st->scan_msg);
728 ad4691_free_scan_bufs(st);
729 return ret;
730 }
731
732 return 0;
733 }
734
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH net-next 13/15] ice: add support for unmanaged DPLL on E830 NIC
From: Tony Nguyen @ 2026-03-30 23:02 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev
Cc: Arkadiusz Kubalewski, anthony.l.nguyen, richardcochran, corbet,
linux-doc, horms, aleksandr.loktionov, przemyslaw.kitszel,
vgrinber, Paul Menzel, Grzegorz Nitka, Sunitha Mekala
In-Reply-To: <20260330230248.646900-1-anthony.l.nguyen@intel.com>
From: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
Hardware variants of E830 may support an unmanaged DPLL where the
configuration is hardcoded within the hardware and firmware, meaning
users cannot modify settings. However, users are able to check the DPLL
lock status and obtain configuration information through the Linux DPLL
and devlink health subsystem.
Availability of 'loss of lock' health status code determines if such
support is available, if true, register single DPLL device with 1 input
and 1 output and provide hardcoded/read only properties of a pin and
DPLL device. User is only allowed to check DPLL device status and receive
notifications on DPLL lock status change.
When present, the DPLL device locks to an external signal provided
through the PCIe/OCP pin. The expected input signal is 1PPS
(1 Pulse Per Second) embedded on a 10MHz reference clock.
The DPLL produces output:
- for MAC (Media Access Control) & PHY (Physical Layer) clocks,
- 1PPS for synchronization of onboard PHC (Precision Hardware Clock) timer.
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
.../device_drivers/ethernet/intel/ice.rst | 83 +++++
.../net/ethernet/intel/ice/devlink/health.c | 4 +
.../net/ethernet/intel/ice/ice_adminq_cmd.h | 12 +
drivers/net/ethernet/intel/ice/ice_common.c | 136 ++++++++
drivers/net/ethernet/intel/ice/ice_common.h | 8 +
drivers/net/ethernet/intel/ice/ice_dpll.c | 302 ++++++++++++++++--
drivers/net/ethernet/intel/ice/ice_dpll.h | 10 +
drivers/net/ethernet/intel/ice/ice_main.c | 11 +-
drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 46 +++
drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 1 +
10 files changed, 592 insertions(+), 21 deletions(-)
diff --git a/Documentation/networking/device_drivers/ethernet/intel/ice.rst b/Documentation/networking/device_drivers/ethernet/intel/ice.rst
index 0bca293cf9cb..09877066b031 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/ice.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/ice.rst
@@ -941,6 +941,89 @@ To see input signal on those PTP pins, you need to configure DPLL properly.
Output signal is only visible on DPLL and to send it to the board SMA/U.FL pins,
DPLL output pins have to be manually configured.
+Unmanaged DPLL Support
+----------------------
+Hardware variants of E830 may support an unmanaged DPLL:
+
+- Intel(R) Ethernet Network Adapter E830-XXVDA8F for OCP 3.0,
+
+- Intel(R) Ethernet Network Adapter E830-XXVDA4F.
+
+In the case of the unmanaged DPLL, the configuration is hardcoded within the
+hardware and firmware, meaning users cannot modify settings. However,
+users can check the DPLL lock status and obtain configuration information
+through the Linux DPLL subsystem.
+
+When present, the DPLL device locks to an external signal provided through the
+PCIe/OCP pin. The expected input signal is 1PPS (1 Pulse Per Second) embedded
+on a 10MHz reference clock.
+The DPLL produces output:
+
+- for MAC (Media Access Control) & PHY (Physical Layer) clocks,
+
+- 1PPS for synchronization of onboard PHC (Precision Hardware Clock) timer.
+
+Requirements: The Linux kernel must have support for both the DPLL Subsystem
+and the Embedded Sync patch series.
+
+Example output of querying the Linux DPLL subsystem can be found below.
+
+.. code-block:: console
+ :caption: Dumping the DPLL pins
+
+ $ <ynl> --spec Documentation/netlink/specs/dpll.yaml --dump pin-get
+ [{'board-label': '1588-TIME_SYNC',
+ 'capabilities': set(),
+ 'clock-id': 282574471561216,
+ 'esync-frequency': 1,
+ 'esync-frequency-supported': [{'frequency-max': 1, 'frequency-min': 1}],
+ 'esync-pulse': 25,
+ 'frequency': 10000000,
+ 'id': 13,
+ 'module-name': 'ice',
+ 'parent-device': [{'direction': 'input',
+ 'parent-id': 6,
+ 'state': 'connected'}],
+ 'phase-adjust-max': 0,
+ 'phase-adjust-min': 0,
+ 'type': 'ext'},
+ {'board-label': 'MAC-PHY-CLK',
+ 'capabilities': set(),
+ 'clock-id': 282574471561216,
+ 'frequency': 156250000,
+ 'id': 14,
+ 'module-name': 'ice',
+ 'parent-device': [{'direction': 'output',
+ 'parent-id': 6,
+ 'state': 'connected'}],
+ 'phase-adjust-max': 0,
+ 'phase-adjust-min': 0,
+ 'type': 'synce-eth-port'},
+ {'board-label': '1588-TIME_REF',
+ 'capabilities': set(),
+ 'clock-id': 282574471561216,
+ 'frequency': 1,
+ 'id': 15,
+ 'module-name': 'ice',
+ 'parent-device': [{'direction': 'output',
+ 'parent-id': 6,
+ 'state': 'connected'}],
+ 'phase-adjust-max': 0,
+ 'phase-adjust-min': 0,
+ 'type': 'int-oscillator'}]
+
+.. code-block:: console
+ :caption: Dumping the DPLL devices
+
+ $ <ynl> --spec Documentation/netlink/specs/dpll.yaml --dump device-get
+ [{'clock-id': 282574471561216,
+ 'id': 6,
+ 'lock-status': 'locked',
+ 'mode': 'manual',
+ 'mode-supported': ['manual'],
+ 'module-name': 'ice',
+ 'type': 'pps'}]
+
GNSS module
-----------
Requires kernel compiled with CONFIG_GNSS=y or CONFIG_GNSS=m.
diff --git a/drivers/net/ethernet/intel/ice/devlink/health.c b/drivers/net/ethernet/intel/ice/devlink/health.c
index 8e9a8a8178d4..31e6c5107c97 100644
--- a/drivers/net/ethernet/intel/ice/devlink/health.c
+++ b/drivers/net/ethernet/intel/ice/devlink/health.c
@@ -101,6 +101,8 @@ static const struct ice_health_status ice_health_status_lookup[] = {
"Supplied MIB file is invalid. DCB reverted to default configuration.",
"Disable FW-LLDP and check DCBx system configuration.",
{ice_port_number_label, "MIB ID"}},
+ {ICE_AQC_HEALTH_STATUS_INFO_LOSS_OF_LOCK, "Local DPLL lock status",
+ NULL,},
};
static int ice_health_status_lookup_compare(const void *a, const void *b)
@@ -242,6 +244,8 @@ void ice_process_health_status_event(struct ice_pf *pf, struct ice_rq_event_info
pf->health_reporters.fw_status = *health_info;
devlink_health_report(pf->health_reporters.fw,
"FW syndrome reported", NULL);
+ if (status_code == ICE_AQC_HEALTH_STATUS_INFO_LOSS_OF_LOCK)
+ ice_dpll_lock_state_set_unmanaged(pf, health_info, true);
break;
case ICE_AQC_HEALTH_STATUS_PF:
case ICE_AQC_HEALTH_STATUS_PORT:
diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
index 859e9c66f3e7..3f8c1b8befc3 100644
--- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
@@ -1498,6 +1498,7 @@ struct ice_aqc_get_link_topo {
#define ICE_AQC_GET_LINK_TOPO_NODE_NR_PCA9575 0x21
#define ICE_AQC_GET_LINK_TOPO_NODE_NR_ZL30632_80032 0x24
#define ICE_AQC_GET_LINK_TOPO_NODE_NR_SI5383_5384 0x25
+#define ICE_AQC_GET_LINK_TOPO_NODE_NR_ZL80640 0x27
#define ICE_AQC_GET_LINK_TOPO_NODE_NR_E822_PHY 0x30
#define ICE_AQC_GET_LINK_TOPO_NODE_NR_C827 0x31
#define ICE_AQC_GET_LINK_TOPO_NODE_NR_GEN_CLK_MUX 0x47
@@ -2481,11 +2482,14 @@ enum ice_aqc_health_status {
ICE_AQC_HEALTH_STATUS_ERR_BMC_RESET = 0x50B,
ICE_AQC_HEALTH_STATUS_ERR_LAST_MNG_FAIL = 0x50C,
ICE_AQC_HEALTH_STATUS_ERR_RESOURCE_ALLOC_FAIL = 0x50D,
+ ICE_AQC_HEALTH_STATUS_INFO_LOSS_OF_LOCK = 0x601,
ICE_AQC_HEALTH_STATUS_ERR_FW_LOOP = 0x1000,
ICE_AQC_HEALTH_STATUS_ERR_FW_PFR_FAIL = 0x1001,
ICE_AQC_HEALTH_STATUS_ERR_LAST_FAIL_AQ = 0x1002,
};
+#define ICE_AQC_HEALTH_STATUS_CODE_NUM 64
+
/* Get Health Status (indirect 0xFF22) */
struct ice_aqc_get_health_status {
__le16 health_status_count;
@@ -2512,6 +2516,13 @@ struct ice_aqc_health_status_elem {
__le32 internal_data2;
};
+/* Get Health Status response buffer entry, (0xFF21)
+ * repeated per reported health status
+ */
+struct ice_aqc_health_status_supp_elem {
+ __le16 health_status_code;
+};
+
/* Admin Queue command opcodes */
enum ice_adminq_opc {
/* AQ commands */
@@ -2675,6 +2686,7 @@ enum ice_adminq_opc {
/* System Diagnostic commands */
ice_aqc_opc_set_health_status_cfg = 0xFF20,
+ ice_aqc_opc_get_supported_health_status_codes = 0xFF21,
ice_aqc_opc_get_health_status = 0xFF22,
/* FW Logging Commands */
diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
index ce11fea122d0..0e246d193712 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.c
+++ b/drivers/net/ethernet/intel/ice/ice_common.c
@@ -3050,6 +3050,29 @@ bool ice_is_cgu_in_netlist(struct ice_hw *hw)
return false;
}
+/**
+ * ice_is_unmanaged_cgu_in_netlist - check for unmanaged CGU presence
+ * @hw: pointer to the hw struct
+ *
+ * Check if the unmanaged Clock Generation Unit (CGU) device is present in the netlist.
+ * Save the CGU part number in the hw structure for later use.
+ * Return:
+ * * true - unmanaged cgu is present
+ * * false - unmanaged cgu is not present
+ */
+bool ice_is_unmanaged_cgu_in_netlist(struct ice_hw *hw)
+{
+ if (!ice_find_netlist_node(hw, ICE_AQC_LINK_TOPO_NODE_TYPE_CLK_CTRL,
+ ICE_AQC_LINK_TOPO_NODE_CTX_GLOBAL,
+ ICE_AQC_GET_LINK_TOPO_NODE_NR_ZL80640,
+ NULL)) {
+ hw->cgu_part_number = ICE_AQC_GET_LINK_TOPO_NODE_NR_ZL80640;
+ return true;
+ }
+
+ return false;
+}
+
/**
* ice_is_gps_in_netlist
* @hw: pointer to the hw struct
@@ -6312,6 +6335,119 @@ bool ice_is_fw_health_report_supported(struct ice_hw *hw)
ICE_FW_API_HEALTH_REPORT_PATCH);
}
+/**
+ * ice_aq_get_health_status_supported - get supported health status codes
+ * @hw: pointer to the HW struct
+ * @buff: pointer to buffer where health status elements will be stored
+ * @num: number of health status elements buffer can hold
+ *
+ * Return:
+ * * 0 - success,
+ * * negative - AQ error code.
+ */
+static int
+ice_aq_get_health_status_supported(struct ice_hw *hw,
+ struct ice_aqc_health_status_supp_elem *buff,
+ int num)
+{
+ u16 code = ice_aqc_opc_get_supported_health_status_codes;
+ struct libie_aq_desc desc;
+
+ ice_fill_dflt_direct_cmd_desc(&desc, code);
+
+ return ice_aq_send_cmd(hw, &desc, buff, num * sizeof(*buff), NULL);
+}
+
+/**
+ * ice_aq_get_health_status - get current health status array from the firmware
+ * @hw: pointer to the HW struct
+ * @buff: pointer to buffer where health status elements will be stored
+ * @num: number of health status elements buffer can hold
+ *
+ * Return:
+ * * 0 - success,
+ * * negative - AQ error code.
+ */
+int ice_aq_get_health_status(struct ice_hw *hw,
+ struct ice_aqc_health_status_elem *buff, int num)
+{
+ struct libie_aq_desc desc;
+
+ ice_fill_dflt_direct_cmd_desc(&desc,
+ ice_aqc_opc_get_health_status);
+
+ return ice_aq_send_cmd(hw, &desc, buff, num * sizeof(*buff), NULL);
+}
+
+/**
+ * ice_is_health_status_code_supported - check if health status code is supported
+ * @hw: pointer to the hardware structure
+ * @code: health status code to check
+ * @supported: pointer to boolean result
+ *
+ * Return: 0 on success, negative error code otherwise
+ */
+int ice_is_health_status_code_supported(struct ice_hw *hw, u16 code,
+ bool *supported)
+{
+ const int BUFF_SIZE = ICE_AQC_HEALTH_STATUS_CODE_NUM;
+ struct ice_aqc_health_status_supp_elem *buff;
+ int ret;
+
+ *supported = false;
+ buff = kzalloc_objs(*buff, BUFF_SIZE);
+ if (!buff)
+ return -ENOMEM;
+ ret = ice_aq_get_health_status_supported(hw, buff, BUFF_SIZE);
+ if (ret)
+ goto free_buff;
+ for (int i = 0; i < BUFF_SIZE && buff[i].health_status_code; i++)
+ if (le16_to_cpu(buff[i].health_status_code) == code) {
+ *supported = true;
+ break;
+ }
+
+free_buff:
+ kfree(buff);
+ return ret;
+}
+
+/**
+ * ice_get_last_health_status_code - get last health status for given code
+ * @hw: pointer to the hardware structure
+ * @out: pointer to the health status struct to be filled
+ * @code: health status code to check
+ *
+ * Return: 0 on success, negative error code otherwise
+ */
+int ice_get_last_health_status_code(struct ice_hw *hw,
+ struct ice_aqc_health_status_elem *out,
+ u16 code)
+{
+ const int BUFF_SIZE = ICE_AQC_HEALTH_STATUS_CODE_NUM;
+ struct ice_aqc_health_status_elem *buff;
+ int ret, last_status = -1;
+
+ buff = kzalloc_objs(*buff, BUFF_SIZE);
+ if (!buff)
+ return -ENOMEM;
+ ret = ice_aq_get_health_status(hw, buff, BUFF_SIZE);
+ if (ret)
+ goto free_buff;
+ for (int i = 0; i < BUFF_SIZE && buff[i].health_status_code; i++)
+ if (le16_to_cpu(buff[i].health_status_code) == code)
+ last_status = i;
+
+ if (last_status >= 0)
+ memcpy(out, &buff[last_status], sizeof(*out));
+ else
+ memset(out, 0, sizeof(*out));
+
+free_buff:
+ kfree(buff);
+ return ret;
+}
+
/**
* ice_aq_set_health_status_cfg - Configure FW health events
* @hw: pointer to the HW struct
diff --git a/drivers/net/ethernet/intel/ice/ice_common.h b/drivers/net/ethernet/intel/ice/ice_common.h
index e700ac0dc347..cbecee66e2a7 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.h
+++ b/drivers/net/ethernet/intel/ice/ice_common.h
@@ -162,6 +162,7 @@ ice_aq_get_phy_caps(struct ice_port_info *pi, bool qual_mods, u8 report_mode,
bool ice_is_phy_rclk_in_netlist(struct ice_hw *hw);
bool ice_is_clock_mux_in_netlist(struct ice_hw *hw);
bool ice_is_cgu_in_netlist(struct ice_hw *hw);
+bool ice_is_unmanaged_cgu_in_netlist(struct ice_hw *hw);
bool ice_is_gps_in_netlist(struct ice_hw *hw);
int
ice_aq_get_netlist_node(struct ice_hw *hw, struct ice_aqc_get_link_topo *cmd,
@@ -188,6 +189,13 @@ ice_get_link_default_override(struct ice_link_default_override_tlv *ldo,
struct ice_port_info *pi);
bool ice_is_phy_caps_an_enabled(struct ice_aqc_get_phy_caps_data *caps);
bool ice_is_fw_health_report_supported(struct ice_hw *hw);
+int ice_aq_get_health_status(struct ice_hw *hw,
+ struct ice_aqc_health_status_elem *buff, int num);
+int ice_is_health_status_code_supported(struct ice_hw *hw, u16 code,
+ bool *supported);
+int ice_get_last_health_status_code(struct ice_hw *hw,
+ struct ice_aqc_health_status_elem *out,
+ u16 code);
int ice_aq_set_health_status_cfg(struct ice_hw *hw, u8 event_source);
int ice_aq_get_phy_equalization(struct ice_hw *hw, u16 data_in, u16 op_code,
u8 serdes_num, int *output);
diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/ethernet/intel/ice/ice_dpll.c
index 62f75701d652..2a9eb233dbf4 100644
--- a/drivers/net/ethernet/intel/ice/ice_dpll.c
+++ b/drivers/net/ethernet/intel/ice/ice_dpll.c
@@ -18,6 +18,8 @@
#define ICE_DPLL_SW_PIN_INPUT_BASE_SFP 4
#define ICE_DPLL_SW_PIN_INPUT_BASE_QSFP 6
#define ICE_DPLL_SW_PIN_OUTPUT_BASE 0
+#define ICE_DPLL_HEALTH_STATUS_LOCKED 1
+#define ICE_DPLL_HEALTH_STATUS_UNLOCKED 0
#define ICE_DPLL_PIN_SW_INPUT_ABS(in_idx) \
(ICE_DPLL_SW_PIN_INPUT_BASE_SFP + (in_idx))
@@ -80,6 +82,10 @@ static const struct dpll_pin_frequency ice_esync_range[] = {
DPLL_PIN_FREQUENCY_RANGE(0, DPLL_PIN_FREQUENCY_1_HZ),
};
+static const struct dpll_pin_frequency ice_esync_range_unmanaged[] = {
+ DPLL_PIN_FREQUENCY_1PPS,
+};
+
/**
* ice_dpll_is_sw_pin - check if given pin shall be controlled by SW
* @pf: private board structure
@@ -1089,9 +1095,11 @@ ice_dpll_pin_state_get(const struct dpll_pin *pin, void *pin_priv,
return -EBUSY;
mutex_lock(&pf->dplls.lock);
- ret = ice_dpll_pin_state_update(pf, p, pin_type, extack);
- if (ret)
- goto unlock;
+ if (!pf->dplls.unmanaged) {
+ ret = ice_dpll_pin_state_update(pf, p, pin_type, extack);
+ if (ret)
+ goto unlock;
+ }
if (pin_type == ICE_DPLL_PIN_TYPE_INPUT ||
pin_type == ICE_DPLL_PIN_TYPE_OUTPUT)
*state = p->state[d->dpll_idx];
@@ -2151,9 +2159,14 @@ ice_dpll_input_esync_get(const struct dpll_pin *pin, void *pin_priv,
mutex_unlock(&pf->dplls.lock);
return -EOPNOTSUPP;
}
- esync->range = ice_esync_range;
- esync->range_num = ARRAY_SIZE(ice_esync_range);
- if (p->flags[0] & ICE_AQC_GET_CGU_IN_CFG_FLG2_ESYNC_EN) {
+ if (pf->dplls.unmanaged) {
+ esync->range = ice_esync_range_unmanaged;
+ esync->range_num = ARRAY_SIZE(ice_esync_range_unmanaged);
+ } else {
+ esync->range = ice_esync_range;
+ esync->range_num = ARRAY_SIZE(ice_esync_range);
+ }
+ if (p->flags[0] & ICE_DPLL_IN_ESYNC_ENABLED) {
esync->freq = DPLL_PIN_FREQUENCY_1_HZ;
esync->pulse = ICE_DPLL_PIN_ESYNC_PULSE_HIGH_PERCENT;
} else {
@@ -2583,6 +2596,21 @@ static const struct dpll_pin_ops ice_dpll_output_ops = {
.esync_get = ice_dpll_output_esync_get,
};
+static const struct dpll_pin_ops ice_dpll_input_unmanaged_ops = {
+ .frequency_get = ice_dpll_input_frequency_get,
+ .direction_get = ice_dpll_input_direction,
+ .state_on_dpll_get = ice_dpll_input_state_get,
+#if defined(HAVE_DPLL_ESYNC)
+ .esync_get = ice_dpll_input_esync_get,
+#endif /* HAVE_DPLL_ESYNC */
+};
+
+static const struct dpll_pin_ops ice_dpll_output_unmanaged_ops = {
+ .frequency_get = ice_dpll_output_frequency_get,
+ .direction_get = ice_dpll_output_direction,
+ .state_on_dpll_get = ice_dpll_output_state_get,
+};
+
static const struct dpll_device_ops ice_dpll_ops = {
.lock_status_get = ice_dpll_lock_status_get,
.mode_get = ice_dpll_mode_get,
@@ -3148,12 +3176,15 @@ ice_dpll_init_direct_pins(struct ice_pf *pf, bool cgu,
int ret;
ret = ice_dpll_get_pins(pf, pins, start_idx, count, pf->dplls.clock_id);
- if (ret)
+ if (!cgu || ret)
return ret;
- if (cgu) {
+
+ if (first) {
ret = ice_dpll_register_pins(first, pins, ops, count);
if (ret)
goto release_pins;
+ }
+ if (second) {
ret = ice_dpll_register_pins(second, pins, ops, count);
if (ret)
goto unregister_first;
@@ -3162,7 +3193,8 @@ ice_dpll_init_direct_pins(struct ice_pf *pf, bool cgu,
return 0;
unregister_first:
- ice_dpll_unregister_pins(first, pins, ops, count);
+ if (first)
+ ice_dpll_unregister_pins(first, pins, ops, count);
release_pins:
ice_dpll_release_pins(pins, count);
return ret;
@@ -3419,6 +3451,18 @@ static void ice_dpll_deinit_pins(struct ice_pf *pf, bool cgu)
struct ice_dpll *de = &d->eec;
struct ice_dpll *dp = &d->pps;
+ if (d->unmanaged) {
+ ice_dpll_unregister_pins(dp->dpll, inputs,
+ &ice_dpll_input_unmanaged_ops,
+ num_inputs);
+ ice_dpll_unregister_pins(dp->dpll, outputs,
+ &ice_dpll_output_unmanaged_ops,
+ num_outputs);
+ ice_dpll_release_pins(inputs, num_inputs);
+ ice_dpll_release_pins(outputs, num_outputs);
+ return;
+ }
+
ice_dpll_deinit_rclk_pin(pf);
if (pf->hw.mac_type == ICE_MAC_GENERIC_3K_E825)
ice_dpll_deinit_fwnode_pins(pf, pf->dplls.inputs, 0);
@@ -3603,23 +3647,29 @@ static int ice_dpll_init_pins(struct ice_pf *pf, bool cgu)
const struct dpll_pin_ops *input_ops;
int ret, count;
- input_ops = &ice_dpll_input_ops;
- output_ops = &ice_dpll_output_ops;
+ if (!pf->dplls.unmanaged) {
+ input_ops = &ice_dpll_input_ops;
+ output_ops = &ice_dpll_output_ops;
+ } else {
+ input_ops = &ice_dpll_input_unmanaged_ops;
+ output_ops = &ice_dpll_output_unmanaged_ops;
+ }
ret = ice_dpll_init_direct_pins(pf, cgu, pf->dplls.inputs, 0,
pf->dplls.num_inputs, input_ops,
- pf->dplls.eec.dpll,
- pf->dplls.pps.dpll);
+ pf->dplls.eec.dpll, pf->dplls.pps.dpll);
if (ret)
return ret;
count = pf->dplls.num_inputs;
- if (cgu) {
+ if (cgu || pf->dplls.unmanaged) {
ret = ice_dpll_init_direct_pins(pf, cgu, pf->dplls.outputs,
count, pf->dplls.num_outputs,
output_ops, pf->dplls.eec.dpll,
pf->dplls.pps.dpll);
if (ret)
goto deinit_inputs;
+ if (pf->dplls.unmanaged)
+ return 0;
count += pf->dplls.num_outputs;
if (!pf->dplls.generic) {
ret = ice_dpll_init_direct_pins(pf, cgu, pf->dplls.sma,
@@ -3732,7 +3782,8 @@ ice_dpll_init_dpll(struct ice_pf *pf, struct ice_dpll *d, bool cgu,
if (type == DPLL_TYPE_PPS && ice_dpll_is_pps_phase_monitor(pf))
ops = &ice_dpll_pom_ops;
- ice_dpll_update_state(pf, d, true);
+ if (!pf->dplls.unmanaged)
+ ice_dpll_update_state(pf, d, true);
ret = dpll_device_register(d->dpll, type, ops, d);
if (ret) {
dpll_device_put(d->dpll, &d->tracker);
@@ -3759,6 +3810,33 @@ static void ice_dpll_deinit_worker(struct ice_pf *pf)
kthread_destroy_worker(d->kworker);
}
+/**
+ * ice_dpll_pin_freq_info - find pin frequency from supported ones
+ * @hw: pointer to the hardware structure
+ * @pin_idx: pin index
+ * @input: if input pin
+ *
+ * This function searches through the array of supported frequencies for a
+ * DPLL pin and returns single frequency pin is capable, if pin support only
+ * one frequency. Shall be used only for dpll with driver hardcoded frequency.
+ *
+ * Return:
+ * * 0 - failure, pin uses multiple frequencies,
+ * * frequency - success.
+ */
+static u64 ice_dpll_pin_freq_info(struct ice_hw *hw, u8 pin_idx, bool input)
+{
+ struct dpll_pin_frequency *freqs;
+ u8 freq_num;
+
+ /* Get supported frequencies for this pin */
+ freqs = ice_cgu_get_pin_freq_supp(hw, pin_idx, input, &freq_num);
+ if (!freqs || freq_num != 1 || freqs[0].min != freqs[0].max)
+ return 0;
+
+ return freqs[0].min;
+}
+
/**
* ice_dpll_init_worker - Initialize DPLLs periodic worker
* @pf: board private structure
@@ -3918,6 +3996,15 @@ ice_dpll_init_info_direct_pins(struct ice_pf *pf,
pins[i].prop.board_label = ice_cgu_get_pin_name(hw, i, input);
pins[i].prop.type = ice_cgu_get_pin_type(hw, i, input);
if (input) {
+ if (pf->dplls.unmanaged) {
+ pins[i].freq = ice_dpll_pin_freq_info(hw, i,
+ input);
+ pins[i].state[0] = DPLL_PIN_STATE_CONNECTED;
+ pins[i].status =
+ ICE_AQC_GET_CGU_IN_CFG_STATUS_ESYNC_CAP;
+ pins[i].flags[0] = ICE_DPLL_IN_ESYNC_ENABLED;
+ continue;
+ }
ret = ice_aq_get_cgu_ref_prio(hw, de->dpll_idx, i,
&de->input_prio[i]);
if (ret)
@@ -3931,6 +4018,12 @@ ice_dpll_init_info_direct_pins(struct ice_pf *pf,
if (ice_dpll_is_sw_pin(pf, i, true))
pins[i].hidden = true;
} else {
+ if (pf->dplls.unmanaged) {
+ pins[i].freq = ice_dpll_pin_freq_info(hw, i,
+ input);
+ pins[i].state[0] = DPLL_PIN_STATE_CONNECTED;
+ continue;
+ }
ret = ice_cgu_get_output_pin_state_caps(hw, i, &caps);
if (ret)
return ret;
@@ -3948,10 +4041,13 @@ ice_dpll_init_info_direct_pins(struct ice_pf *pf,
pins[i].prop.freq_supported_num = freq_supp_num;
pins[i].pf = pf;
}
- if (input)
+ if (input && !pf->dplls.unmanaged) {
ret = ice_dpll_init_ref_sync_inputs(pf);
+ if (ret)
+ return ret;
+ }
- return ret;
+ return 0;
}
/**
@@ -4144,7 +4240,6 @@ static int ice_dpll_init_info_e825c(struct ice_pf *pf)
d->clock_id = ice_generate_clock_id(pf);
d->num_inputs = ICE_SYNCE_CLK_NUM;
-
d->inputs = kzalloc_objs(*d->inputs, d->num_inputs);
if (!d->inputs)
return -ENOMEM;
@@ -4169,6 +4264,82 @@ static int ice_dpll_init_info_e825c(struct ice_pf *pf)
return ret;
}
+/**
+ * ice_dpll_lock_state_init_unmanaged - initialize lock state for unmanaged dpll
+ * @pf: board private structure
+ *
+ * Initialize the lock state for unmanaged DPLL by checking health status.
+ * For unmanaged DPLL, we rely on hardware autonomous operation.
+ *
+ * Return:
+ * * 0 - success
+ * * negative - init failure reason
+ */
+static int ice_dpll_lock_state_init_unmanaged(struct ice_pf *pf)
+{
+ u16 code = ICE_AQC_HEALTH_STATUS_INFO_LOSS_OF_LOCK;
+ struct ice_aqc_health_status_elem buff;
+ int ret;
+
+ ret = ice_get_last_health_status_code(&pf->hw, &buff, code);
+ if (ret)
+ return ret;
+ ice_dpll_lock_state_set_unmanaged(pf, &buff, false);
+
+ return ret;
+}
+
+/**
+ * ice_dpll_init_info_unmanaged - init dpll information for unmanaged dpll
+ * @pf: board private structure
+ *
+ * Acquire (from HW) and set basic dpll information (on pf->dplls struct).
+ * For unmanaged dpll mode.
+ *
+ * Return:
+ * * 0 - success
+ * * negative - init failure reason
+ */
+static int ice_dpll_init_info_unmanaged(struct ice_pf *pf)
+{
+ struct ice_dplls *d = &pf->dplls;
+ int ret;
+
+ d->clock_id = ice_generate_clock_id(pf);
+ d->num_inputs = ice_cgu_get_pin_num(&pf->hw, true);
+ d->num_outputs = ice_cgu_get_pin_num(&pf->hw, false);
+ ret = ice_dpll_lock_state_init_unmanaged(pf);
+ if (ret)
+ return ret;
+ d->inputs = kzalloc_objs(*d->inputs, d->num_inputs);
+ if (!d->inputs)
+ return -ENOMEM;
+
+ ret = ice_dpll_init_pins_info(pf, ICE_DPLL_PIN_TYPE_INPUT);
+ if (ret)
+ goto deinit_info;
+
+ d->outputs = kzalloc_objs(*d->outputs, d->num_outputs);
+ if (!d->outputs) {
+ ret = -ENOMEM;
+ goto deinit_info;
+ }
+
+ ret = ice_dpll_init_pins_info(pf, ICE_DPLL_PIN_TYPE_OUTPUT);
+ if (ret)
+ goto deinit_info;
+
+ d->pps.mode = DPLL_MODE_MANUAL;
+ dev_dbg(ice_pf_to_dev(pf), "%s - success, inputs:%u, outputs:%u\n",
+ __func__, d->num_inputs, d->num_outputs);
+ return 0;
+deinit_info:
+ dev_err(ice_pf_to_dev(pf), "%s - fail: d->inputs:%p, d->outputs:%p\n",
+ __func__, d->inputs, d->outputs);
+ ice_dpll_deinit_info(pf);
+ return ret;
+}
+
/**
* ice_dpll_init_info - prepare pf's dpll information structure
* @pf: board private structure
@@ -4268,6 +4439,42 @@ static int ice_dpll_init_info(struct ice_pf *pf, bool cgu)
return ret;
}
+/**
+ * ice_dpll_lock_state_set_unmanaged - determine lock state from health status
+ * @pf: board private structure
+ * @buff: health status buffer
+ * @notify: if true, notify dpll device
+ *
+ * Set unmanaged dpll lock state based on health status code and internal data.
+ * Context: Acquires and releases pf->dplls.lock (must release before notify
+ * if called).
+ */
+void ice_dpll_lock_state_set_unmanaged(struct ice_pf *pf,
+ const struct ice_aqc_health_status_elem *buff,
+ bool notify)
+{
+ u32 internal_data = le32_to_cpu(buff->internal_data1);
+ struct ice_dpll *d = &pf->dplls.pps;
+
+ if (!ice_pf_src_tmr_owned(pf))
+ return;
+
+ mutex_lock(&pf->dplls.lock);
+ if (buff->health_status_code == 0 ||
+ internal_data == ICE_DPLL_HEALTH_STATUS_LOCKED)
+ d->dpll_state = DPLL_LOCK_STATUS_LOCKED;
+ else
+ d->dpll_state = DPLL_LOCK_STATUS_UNLOCKED;
+
+ if (d->prev_dpll_state == d->dpll_state)
+ notify = false;
+ else
+ d->prev_dpll_state = d->dpll_state;
+ mutex_unlock(&pf->dplls.lock);
+ if (notify && d->dpll)
+ dpll_device_change_ntf(d->dpll);
+}
+
/**
* ice_dpll_deinit - Disable the driver/HW support for dpll subsystem
* the dpll device.
@@ -4287,15 +4494,55 @@ void ice_dpll_deinit(struct ice_pf *pf)
if (cgu)
ice_dpll_deinit_worker(pf);
- ice_dpll_deinit_pins(pf, cgu);
+ ice_dpll_deinit_pins(pf, cgu || pf->dplls.unmanaged);
if (!IS_ERR_OR_NULL(pf->dplls.pps.dpll))
- ice_dpll_deinit_dpll(pf, &pf->dplls.pps, cgu);
+ ice_dpll_deinit_dpll(pf, &pf->dplls.pps,
+ cgu || pf->dplls.unmanaged);
if (!IS_ERR_OR_NULL(pf->dplls.eec.dpll))
ice_dpll_deinit_dpll(pf, &pf->dplls.eec, cgu);
ice_dpll_deinit_info(pf);
mutex_destroy(&pf->dplls.lock);
}
+/**
+ * ice_dpll_init_unmanaged - initialize support for unmanaged dpll subsystem
+ * @pf: board private structure
+ *
+ * Set up the device dplls for unmanaged mode, register them and pins connected
+ * within Linux dpll subsystem. Allow userspace to obtain state of DPLL.
+ *
+ * Context: Initializes pf->dplls.lock mutex.
+ */
+static void ice_dpll_init_unmanaged(struct ice_pf *pf)
+{
+ struct ice_dplls *d = &pf->dplls;
+ int err;
+
+ if (!ice_pf_src_tmr_owned(pf))
+ return;
+ mutex_init(&d->lock);
+ err = ice_dpll_init_info_unmanaged(pf);
+ if (err)
+ goto err_exit;
+ err = ice_dpll_init_dpll(pf, &pf->dplls.pps, true, DPLL_TYPE_PPS);
+ if (err)
+ goto deinit_info;
+ err = ice_dpll_init_pins(pf, true);
+ if (err)
+ goto deinit_pps;
+ set_bit(ICE_FLAG_DPLL, pf->flags);
+
+ return;
+
+deinit_pps:
+ ice_dpll_deinit_dpll(pf, &pf->dplls.pps, true);
+deinit_info:
+ ice_dpll_deinit_info(pf);
+err_exit:
+ mutex_destroy(&d->lock);
+ dev_warn(ice_pf_to_dev(pf), "DPLLs init failure err:%d\n", err);
+}
+
/**
* ice_dpll_init_e825 - initialize support for dpll subsystem
* @pf: board private structure
@@ -4383,8 +4630,23 @@ static void ice_dpll_init_e810(struct ice_pf *pf)
dev_warn(ice_pf_to_dev(pf), "DPLLs init failure err:%d\n", err);
}
+/**
+ * ice_dpll_init - initialize support for dpll subsystem
+ * @pf: board private structure
+ *
+ * Set up the device dplls, register them and pins connected within Linux dpll
+ * subsystem. Allow userspace to obtain state of DPLL and handling of DPLL
+ * configuration requests.
+ *
+ * Context: Initializes pf->dplls.lock mutex.
+ */
void ice_dpll_init(struct ice_pf *pf)
{
+ if (pf->dplls.unmanaged) {
+ ice_dpll_init_unmanaged(pf);
+ return;
+ }
+
switch (pf->hw.mac_type) {
case ICE_MAC_GENERIC_3K_E825:
ice_dpll_init_e825(pf);
diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.h b/drivers/net/ethernet/intel/ice/ice_dpll.h
index ae42cdea0ee1..2c98b6c6deb0 100644
--- a/drivers/net/ethernet/intel/ice/ice_dpll.h
+++ b/drivers/net/ethernet/intel/ice/ice_dpll.h
@@ -146,14 +146,22 @@ struct ice_dplls {
s32 output_phase_adj_max;
u32 periodic_counter;
bool generic;
+ bool unmanaged;
};
#if IS_ENABLED(CONFIG_PTP_1588_CLOCK)
void ice_dpll_init(struct ice_pf *pf);
void ice_dpll_deinit(struct ice_pf *pf);
+void ice_dpll_lock_state_set_unmanaged(struct ice_pf *pf,
+ const struct ice_aqc_health_status_elem *buff,
+ bool notify);
#else
static inline void ice_dpll_init(struct ice_pf *pf) { }
static inline void ice_dpll_deinit(struct ice_pf *pf) { }
+static inline void
+ice_dpll_lock_state_set_unmanaged(struct ice_pf *pf,
+ const struct ice_aqc_health_status_elem *buff,
+ bool notify) { }
#endif
#endif
@@ -173,3 +181,5 @@ static inline void ice_dpll_deinit(struct ice_pf *pf) { }
#define ICE_CGU_R11_SYNCE_S_BYP_CLK GENMASK(6, 1)
#define ICE_CGU_BYPASS_MUX_OFFSET_E825C 3
+#define ICE_DPLL_UNMANAGED_PIN_NUM 4
+#define ICE_DPLL_IN_ESYNC_ENABLED ICE_AQC_GET_CGU_IN_CFG_FLG2_ESYNC_EN
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 3c36e3641b9e..325c7f850ff8 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -4787,7 +4787,9 @@ void ice_deinit_dev(struct ice_pf *pf)
static void ice_init_features(struct ice_pf *pf)
{
+ u16 code = ICE_AQC_HEALTH_STATUS_INFO_LOSS_OF_LOCK;
struct device *dev = ice_pf_to_dev(pf);
+ int err;
if (ice_is_safe_mode(pf))
return;
@@ -4799,8 +4801,15 @@ static void ice_init_features(struct ice_pf *pf)
if (ice_is_feature_supported(pf, ICE_F_GNSS))
ice_gnss_init(pf);
+ /* Initialize unmanaged DPLL detection */
+ err = ice_is_health_status_code_supported(&pf->hw, code,
+ &pf->dplls.unmanaged);
+ if (err || !ice_is_unmanaged_cgu_in_netlist(&pf->hw))
+ pf->dplls.unmanaged = false;
+
if (ice_is_feature_supported(pf, ICE_F_CGU) ||
- ice_is_feature_supported(pf, ICE_F_PHY_RCLK))
+ ice_is_feature_supported(pf, ICE_F_PHY_RCLK) ||
+ pf->dplls.unmanaged)
ice_dpll_init(pf);
/* Note: Flow director init failure is non-fatal to load */
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
index 61c0a0d93ea8..54555d232bd1 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
@@ -20,6 +20,10 @@ static struct dpll_pin_frequency ice_cgu_pin_freq_10_mhz[] = {
DPLL_PIN_FREQUENCY_10MHZ,
};
+static struct dpll_pin_frequency ice_cgu_pin_freq_156_25mhz[] = {
+ DPLL_PIN_FREQUENCY_RANGE(156250000, 156250000),
+};
+
static const struct ice_cgu_pin_desc ice_e810t_sfp_cgu_inputs[] = {
{ "CVL-SDP22", ZL_REF0P, DPLL_PIN_TYPE_INT_OSCILLATOR,
ARRAY_SIZE(ice_cgu_pin_freq_common), ice_cgu_pin_freq_common },
@@ -131,6 +135,18 @@ static const struct ice_cgu_pin_desc ice_e823_zl_cgu_outputs[] = {
{ "NONE", ZL_OUT5, 0, 0 },
};
+static const struct ice_cgu_pin_desc ice_e830_unmanaged_inputs[] = {
+ { "1588-TIME_SYNC", 0, DPLL_PIN_TYPE_EXT,
+ ARRAY_SIZE(ice_cgu_pin_freq_10_mhz), ice_cgu_pin_freq_10_mhz },
+};
+
+static const struct ice_cgu_pin_desc ice_e830_unmanaged_outputs[] = {
+ { "MAC-PHY-CLK", 0, DPLL_PIN_TYPE_SYNCE_ETH_PORT,
+ ARRAY_SIZE(ice_cgu_pin_freq_156_25mhz), ice_cgu_pin_freq_156_25mhz },
+ { "1588-TIME_REF", 1, DPLL_PIN_TYPE_INT_OSCILLATOR,
+ ARRAY_SIZE(ice_cgu_pin_freq_1_hz), ice_cgu_pin_freq_1_hz},
+};
+
/* Low level functions for interacting with and managing the device clock used
* for the Precision Time Protocol.
*
@@ -5684,6 +5700,24 @@ ice_cgu_get_pin_desc(struct ice_hw *hw, bool input, int *size)
case ICE_DEV_ID_E823C_SGMII:
t = ice_cgu_get_pin_desc_e823(hw, input, size);
break;
+ case ICE_DEV_ID_E830CC_BACKPLANE:
+ case ICE_DEV_ID_E830CC_QSFP56:
+ case ICE_DEV_ID_E830CC_SFP:
+ case ICE_DEV_ID_E830CC_SFP_DD:
+ case ICE_DEV_ID_E830C_BACKPLANE:
+ case ICE_DEV_ID_E830C_QSFP:
+ case ICE_DEV_ID_E830C_SFP:
+ case ICE_DEV_ID_E830_XXV_BACKPLANE:
+ case ICE_DEV_ID_E830_XXV_QSFP:
+ case ICE_DEV_ID_E830_XXV_SFP:
+ if (input) {
+ t = ice_e830_unmanaged_inputs;
+ *size = ARRAY_SIZE(ice_e830_unmanaged_inputs);
+ } else {
+ t = ice_e830_unmanaged_outputs;
+ *size = ARRAY_SIZE(ice_e830_unmanaged_outputs);
+ }
+ break;
default:
break;
}
@@ -5710,6 +5744,18 @@ int ice_cgu_get_num_pins(struct ice_hw *hw, bool input)
return 0;
}
+/**
+ * ice_cgu_get_pin_num - get pin description array size
+ * @hw: pointer to the hw struct
+ * @input: if request is done against input or output pins
+ *
+ * Return: size of pin description array for given hw.
+ */
+int ice_cgu_get_pin_num(struct ice_hw *hw, bool input)
+{
+ return ice_cgu_get_num_pins(hw, input);
+}
+
/**
* ice_cgu_get_pin_type - get pin's type
* @hw: pointer to the hw struct
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
index 9bfd3e79c580..87aa4cfc5a46 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
@@ -356,6 +356,7 @@ int ice_read_sma_ctrl(struct ice_hw *hw, u8 *data);
int ice_write_sma_ctrl(struct ice_hw *hw, u8 data);
int ice_ptp_read_sdp_ac(struct ice_hw *hw, __le16 *entries, uint *num_entries);
int ice_cgu_get_num_pins(struct ice_hw *hw, bool input);
+int ice_cgu_get_pin_num(struct ice_hw *hw, bool input);
enum dpll_pin_type ice_cgu_get_pin_type(struct ice_hw *hw, u8 pin, bool input);
struct dpll_pin_frequency *
ice_cgu_get_pin_freq_supp(struct ice_hw *hw, u8 pin, bool input, u8 *num);
--
2.47.1
^ permalink raw reply related
* Re: [PATCH v3 02/24] PCI: Add API to track PCI devices preserved across Live Update
From: Bjorn Helgaas @ 2026-03-30 22:54 UTC (permalink / raw)
To: David Matlack
Cc: Alex Williamson, Bjorn Helgaas, Adithya Jayachandran,
Alexander Graf, Alex Mastro, Andrew Morton, Ankit Agrawal,
Arnd Bergmann, Askar Safin, Borislav Petkov (AMD), Chris Li,
Dapeng Mi, David Rientjes, Feng Tang, Jacob Pan, Jason Gunthorpe,
Jason Gunthorpe, Jonathan Corbet, Josh Hilke, Kees Cook,
Kevin Tian, kexec, kvm, Leon Romanovsky, Leon Romanovsky,
linux-doc, linux-kernel, linux-kselftest, linux-mm, linux-pci,
Li RongQing, Lukas Wunner, Marco Elver, Michał Winiarski,
Mike Rapoport, Parav Pandit, Pasha Tatashin, Paul E. McKenney,
Pawan Gupta, Peter Zijlstra (Intel), Pranjal Shrivastava,
Pratyush Yadav, Raghavendra Rao Ananta, Randy Dunlap,
Rodrigo Vivi, Saeed Mahameed, Samiullah Khawaja, Shuah Khan,
Vipin Sharma, Vivek Kasireddy, William Tu, Yi Liu, Zhu Yanjun
In-Reply-To: <acWne_ZCcF4YQN25@google.com>
On Thu, Mar 26, 2026 at 09:39:07PM +0000, David Matlack wrote:
> On 2026-03-25 06:12 PM, Bjorn Helgaas wrote:
> > On Mon, Mar 23, 2026 at 11:57:54PM +0000, David Matlack wrote:
> > > Add an API to enable the PCI subsystem to participate in a Live Update
> > > and track all devices that are being preserved by drivers. Since this
> > > support is still under development, hide it behind a new Kconfig
> > > PCI_LIVEUPDATE that is marked experimental.
> ...
> > This sets "dev->liveupdate_incoming = false", and the only place we
> > check that is in pci_liveupdate_retrieve(). In particular, there's
> > nothing in the driver bind/unbind paths that seems related. I guess
> > pci_liveupdate_finish() just means the driver can't call
> > pci_liveupdate_retrieve() any more?
>
> liveupdate_incoming is used by VFIO in patch 10:
>
> https://lore.kernel.org/kvm/20260323235817.1960573-11-dmatlack@google.com/
>
> Fundamentally, I think drivers will need to know that the device they
> are dealing with was preserved across the Live Update so they can react
> accordingly and this is how they know. This feels like an appropriate
> responsibility to delegate to the PCI core since it can be common across
> all PCI devices, rather than requiring drivers to store their own state
> about which devices were preserved. I suspect PCI core will also use
> liveupdate_incoming in the future (e.g. to avoid assigning new BARs) as
> we implement more of the device preservation.
Yes. It's easier to review if this is added at the point where it is
used.
> And in case you are also wondering about liveupdate_outgoing, I forsee
> that being used for things like skipping disabling bus mastering in
> pci_device_shutdown().
>
> I think it would be a good idea to try to split this patch up, so there
> is more breathing room to explain this context in the commit messages.
Sounds good.
> > > + * Don't both accounting for VFs that could be created after this
> > > + * since preserving VFs is not supported yet. Also don't account
> > > + * for devices that could be hot-plugged after this since preserving
> > > + * hot-plugged devices across Live Update is not yet an expected
> > > + * use-case.
> >
> > s/Don't both accounting/Don't bother accounting/ ? not sure of intent
>
> "Don't bother" was the intent.
>
> > I suspect the important thing here is that this allocates space for
> > preserving X devices, and each subsequent pci_liveupdate_preserve()
> > call from a driver uses up one of those slots.
> >
> > My guess is this is just an allocation issue and from that point of
> > view there's no actual problem with enabling VFs or hot-adding devices
> > after this point; it's just that pci_liveupdate_preserve() will fail
> > after X calls.
>
> Yes that is correct.
Mentioning VFs in the comment is a slight misdirection when the actual
concern is just about the number of devices.
> I see that a lot of your comments are about these WARN_ONs so do you
> have any general guidance on how I should be handling them?
If it's practical to arrange it so we dereference a NULL pointer or
similar, that's my preference because it doesn't take extra code and
it's impossible to ignore. Sometimes people add "if (!ptr) return
-EINVAL;" to internal functions where "ptr" should never be NULL. IMO
cases like that should just use assume "ptr" is valid and use it.
Likely not a practical strategy in your case.
> > > + if (pci_WARN_ONCE(dev, !dev_ser, "Cannot find preserved device!"))
> >
> > Seems like an every-time sort of message if this indicates a driver bug?
> >
> > It's enough of a hassle to convince myself that pci_WARN_ONCE()
> > returns the value that caused the warning that I would prefer:
> >
> > if (!dev_ser) {
> > pci_warn(...) or pci_WARN_ONCE(...)
> > return;
> > }
>
> For "this should really never happen" warnings, which is the case here,
> my preference is to use WARN_ON_ONCE() since you only need to see it
> happen once to know there is a bug somewhere, and logging every time can
> lead to overwhelmingly interleaved logs if it happens too many times.
I'm objecting more to using the return value of pci_WARN_ONCE() than
the warning itself. It's not really obvious what WARN_ONCE() should
return and kind of a hassle to figure it out, so I think it's clearer
in this case to test dev_ser directly.
> > > + for (i = ser->nr_devices; i > 0; i--) {
> > > + struct pci_dev_ser *prev = &ser->devices[i - 1];
> > > + int cmp = pci_dev_ser_cmp(&new, prev);
> > > +
> > > + /*
> > > + * This should never happen unless there is a kernel bug or
> > > + * corruption that causes the state in struct pci_ser to get out
> > > + * of sync with struct pci_dev.
> >
> > Huh. Same comment as above. I don't think this is telling me
> > anything useful. I guess what happened is we're trying to preserve X
> > and X is already in "ser", but we should have returned -EBUSY above
> > for that case. If we're just saying memory corruption could cause
> > bugs, I think that's pointless.
> >
> > Actually I'm not even sure we should check for this.
> >
> > > + */
> > > + if (WARN_ON_ONCE(!cmp))
> > > + return -EBUSY;
>
> This is another "this should really never happen" check. I could just
> return without warning but this is a sign that something is very wrong
> somewhere in the kernel and it is trivial to just add WARN_ON_ONCE() so
> that it gets flagged in dmesg. In my experience that can be very helpful
> to track down logic bugs during developemt and rare race conditions at
> scale in production environments.
OK. Maybe just remove the comment. It's self-evident that
WARN_ON_ONCE() is a "shouldn't happen" situation, and I don't think
the comment contains useful information.
> > > +u32 pci_liveupdate_incoming_nr_devices(void)
> > > +{
> > > + struct pci_ser *ser;
> > > +
> > > + if (pci_liveupdate_flb_get_incoming(&ser))
> > > + return 0;
> >
> > Seems slightly overcomplicated to return various error codes from
> > pci_liveupdate_flb_get_incoming(), only to throw them away here and
> > special-case the "return 0". I think you *could* set
> > "ser->nr_devices" to zero at entry to
> > pci_liveupdate_flb_get_incoming() and make this just:
> >
> > pci_liveupdate_flb_get_incoming(&ser);
> > return ser->nr_devices;
>
> pci_liveupdate_flb_get_incoming() fetches the preserved pci_ser struct
> from LUO (the struct that the previous kernel allocated and populated).
> If pci_liveupdate_flb_get_incoming() returns an error, it means there
> was no struct pci_ser preserved by the previous kernel (or at least not
> that the current kernel is compatible with), so we return 0 here to
> indicate that 0 devices were preserved.
Right. Here's what I was thinking:
pci_liveupdate_flb_get_incoming(...)
{
struct pci_ser *ser = *serp;
ser->nr_devices = 0;
ret = liveupdate_flb_get_incoming(...);
...
if (ret == -ENOENT) {
pr_info_once("PCI: No incoming FLB data detected during Live Update");
return;
}
WARN_ONCE(ret, "PCI: Failed to retrieve incoming ...");
}
u32 pci_liveupdate_incoming_nr_devices(void)
{
pci_liveupdate_flb_get_incoming(&ser);
return ser->nr_devices;
}
> > > +++ b/include/linux/kho/abi/pci.h
> >
> > It seems like most of include/linux/ is ABI, so does kho/abi/ need to
> > be separated out in its own directory?
>
> include/linux/kho/abi/ contains all of the structs, enums, etc. that are
> handed off between kernels during a Live Update. If almost anything
> changes in this directory, it breaks our ability to upgrade/downgrade
> via Live Update. That's why it's split off into its own directory.
>
> include/linux/ is not part of the Live Update ABI. Changes to those
> headers to not affect our ability to upgrade/downgrade via Live Update.
>
> > It's kind of unusual for the hierarchy to be this deep, especially
> > since abi/ is the only thing in include/linux/kho/.
>
> Yes I agree, but that is outside the scope of this patchset I think.
> This directory already exists.
Agreed.
Bjorn
^ permalink raw reply
* [PATCH] docs: add an Assisted-by mention to submitting-patches.rst
From: Jonathan Corbet @ 2026-03-30 22:25 UTC (permalink / raw)
To: linux-doc; +Cc: linux-kernel, Sasha Levin
We now require disclosure of the use of coding assistants, but our core
submitting-patches document does not mention that. Add a brief mention
with a pointer to Documentation/process/coding-assistants.rst
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
This is just a minimal change in the hope that a few more contributors
will see it. I realize that this document needs a rather more serious
thrash, but that's for later.
Documentation/process/submitting-patches.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index c88e75bf0534..d7290e208e72 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -634,6 +634,16 @@ bugzilla.kernel.org is a public place in this sense, but email addresses
used there are private; so do not expose them in tags, unless the person
used them in earlier contributions.
+Using Assisted-by:
+------------------
+
+If you used any sort of advanced coding tool in the creation of your patch,
+you need to acknowledge that use by adding an Assisted-by tag. Failure to
+do so may impede the acceptance of your work. Please see
+Documentation/process/coding-assistants.rst for details regarding the
+acknowledgment of coding assistants.
+
+
.. _the_canonical_patch_format:
The canonical patch format
--
2.53.0
^ permalink raw reply related
* [PATCH -next] hwmon: (yogafan) fix markup warning
From: Randy Dunlap @ 2026-03-30 21:46 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Sergio Melas, Guenter Roeck, linux-hwmon, linux-doc
Add a blank line between the License and heading lines to prevent a
documentation build warning:
Documentation/hwmon/yogafan.rst:2: WARNING: Explicit markup ends without
a blank line; unexpected unindent. [docutils]
Fixes: b773f2e6b472 ("hwmon: (yogafan) Add support for Lenovo Yoga/Legion fan monitoring")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Sergio Melas <sergiomelas@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Documentation/hwmon/yogafan.rst | 1 +
1 file changed, 1 insertion(+)
--- linux-next.orig/Documentation/hwmon/yogafan.rst
+++ linux-next/Documentation/hwmon/yogafan.rst
@@ -1,4 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0-only
+
===============================================================================================
Kernel driver yogafan
===============================================================================================
^ permalink raw reply
* Re: [PATCH V10 0/8] dax: prepare for famfs
From: Alison Schofield @ 2026-03-30 21:21 UTC (permalink / raw)
To: John Groves
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
John Groves, Jonathan Corbet, Shuah Khan, Vishal Verma,
Dave Jiang, Matthew Wilcox, Jan Kara, Alexander Viro,
David Hildenbrand, Christian Brauner, Darrick J . Wong,
Randy Dunlap, Jeff Layton, Amir Goldstein, Jonathan Cameron,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <0100019d311bed04-dbb67b48-c55d-4e6a-962a-a0f8b714f2e7-000000@email.amazonses.com>
On Fri, Mar 27, 2026 at 09:03:26PM +0000, John Groves wrote:
> From: John Groves <john@groves.net>
>
> This patch series along with the bundled patches to fuse are available
> as a git tag at [0].
>
> Dropped the "bundle" thread. If this submission goes smoothly, I'll update
> the fuse patches to v10 (very little change there as yet).
>
> Changes v9 -> v10
> - Minor modernizations per comments from (mostly) Jonathan
> - Minor Kconfig simplification
> - bus.c:dax_match_type(): don't make fsdev_dax eligible for automatic binding
> where devdax would otherwise bind
> - dax-private.h: add missing kerneldoc comment for field cached_size in
> struct dev_dax_range (thanks Dave)
> - fsdev_write_dax(): s/pmem_addr/addr/ (thanks Dave)
> - include/linux/dax.h: remove a spuriously-added declaration of inode_dax()
> (thanks Jonathan)
>
> Description:
>
> This patch series introduces the required dax support for famfs.
> Previous versions of the famfs series included both dax and fuse patches.
> This series separates them into separate patch series' (and the fuse
> series dependends on this dax series).
>
> The famfs user space code can be found at [1]
>
> Dax Overview:
>
> This series introduces a new "famfs mode" of devdax, whose driver is
> drivers/dax/fsdev.c. This driver supports dax_iomap_rw() and
> dax_iomap_fault() calls against a character dax instance. A dax device
> now can be converted among three modes: 'system-ram', 'devdax' and
> 'famfs' via daxctl or sysfs (e.g. unbind devdax and bind famfs instead).
>
> In famfs mode, a dax device initializes its pages consistent with the
> fsdaxmode of pmem. Raw read/write/mmap are not supported in this mode,
> but famfs is happy in this mode - using dax_iomap_rw() for read/write and
> dax_iomap_fault() for mmap faults.
>
Here's what I found:
famfs-v10 on 7.0-rc5 + ndctl v84:
dax suite all pass 13/13, so no regression appears
famfs-v10 on 7.0-rc5 +
(ndctl v84 w https://github.com/jagalactic/ndctl/tree/famfs
top 3 patches + edit daxctl-famfs.sh to use cxl-test:
existing dax suite keeps passing
daxctl-famfs.sh oops w the new test at # Restore original mode"
seems easy to repoduce, maybe cannot go back to system-ram???
Let me know if you need more info.
-- Alison
^ permalink raw reply
* Re: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
From: Andrew Morton @ 2026-03-30 21:22 UTC (permalink / raw)
To: SeongJae Park
Cc: Greg KH, Liam R. Howlett, # 5 . 19 . x, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm, Roman Gushchin
In-Reply-To: <20260329193226.59025-1-sj@kernel.org>
On Sun, 29 Mar 2026 12:32:26 -0700 SeongJae Park <sj@kernel.org> wrote:
> On Sun, 29 Mar 2026 20:05:53 +0200 Greg KH <gregkh@linuxfoundation.org> wrote:
>
> > On Sun, Mar 29, 2026 at 08:49:16AM -0700, SeongJae Park wrote:
> > > Forwarding sashiko.dev review status for this thread.
> > >
> > > # review url: https://sashiko.dev/#/patchset/20260329153052.46657-1-sj@kernel.org
> >
> > Why are you doing this? If we want to see the review, can't we just go
> > and look at the tool itself?
>
> We can. But it is bit cumbersome to opening web browser and moving my focus to
> there. Reading everything on the mailing tool is easier for some people like
> me. Like some test bots send reports are replying to patches, or we sometimes
> forwarding bugzilla reports to mailing lists in a form of a plain text mail.
>
> Secondly, I have to share my opinions about the reviews, as many times AI
> reviews need human's opinions. There is no good way to do that on the web ui
> of the tool (sashiko) for now, and I think this mail based flow is the best.
I do agree with Greg that it's all a bit excessive. Thanks for your
your diligence, but perhaps dial it back a bit? It's OK - we're all
trying to figure out how best to utilize this tool.
I view Sashiko as primarily an author tool. Sometimes I call it
checkpatch++. In a better world, author would be able to sort out
Sashiko issues before ever sending out the patchset. But in this
world, a public send is needed to obtain that review.
So what we're presently seeing is author development activity which is
unfortunately and inappropriately being conducted on a public list.
Personally, I pay only a little attention to author's Sashiko activity.
Just enough to see whether I should pay more attention. If author
says "oops, let me redo" then fine, I'll await the next spin. If
author says "that was all nonsense" then fine, time to take a closer
look.
^ permalink raw reply
* Re: [PATCH net-next v3 0/3] net: bridge: add stp_mode attribute for STP mode selection
From: Andy Roulin @ 2026-03-30 19:48 UTC (permalink / raw)
To: netdev
Cc: bridge, Nikolay Aleksandrov, Ido Schimmel, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Petr Machata,
Donald Hunter, Jonas Gorski, linux-doc, linux-kselftest,
linux-kernel
In-Reply-To: <20260330022107.670566-1-aroulin@nvidia.com>
On 3/29/26 19:21, Andy Roulin wrote:
>
> Patch 1 adds the kernel support. The mode can only be changed while
> STP is disabled and is processed before IFLA_BR_STP_STATE in
> br_changelink() so both can be set atomically in a single netlink
> message.
https://sashiko.dev/#/patchset/20260330022107.670566-1-aroulin%40nvidia.com
will fix the reported issue in v4.
^ permalink raw reply
* [PATCH] Documentation: amd-pstate: fix dead links in the reference section
From: Ninad Naik @ 2026-03-30 19:08 UTC (permalink / raw)
To: ray.huang, gautham.shenoy, mario.limonciello, perry.yuan, corbet,
skhan
Cc: linux-pm, linux-doc, linux-kernel, me, Ninad Naik
The links for AMD64 Architecture Programmer's Manual and PPR for AMD
Family 19h Model 51h, Revision A1 Processors redirect to a generic page.
Update the links to the working ones.
Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
---
Documentation/admin-guide/pm/amd-pstate.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst
index e1771f2225d5..13d6580894bc 100644
--- a/Documentation/admin-guide/pm/amd-pstate.rst
+++ b/Documentation/admin-guide/pm/amd-pstate.rst
@@ -790,13 +790,13 @@ Reference
===========
.. [1] AMD64 Architecture Programmer's Manual Volume 2: System Programming,
- https://www.amd.com/system/files/TechDocs/24593.pdf
+ https://docs.amd.com/v/u/en-US/24593_3.44_APM_Vol2
.. [2] Advanced Configuration and Power Interface Specification,
https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf
.. [3] Processor Programming Reference (PPR) for AMD Family 19h Model 51h, Revision A1 Processors
- https://www.amd.com/system/files/TechDocs/56569-A1-PUB.zip
+ https://docs.amd.com/v/u/en-US/56569-A1-PUB_3.03
.. [4] Linux Kernel Selftests,
https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Babu Moger @ 2026-03-30 18:46 UTC (permalink / raw)
To: Reinette Chatre, corbet, tony.luck, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: skhan, x86, hpa, peterz, juri.lelli, vincent.guittot,
dietmar.eggemann, rostedt, bsegall, mgorman, vschneid, kas,
rick.p.edgecombe, akpm, pmladek, rdunlap, dapeng1.mi, kees, elver,
paulmck, lirongqing, safinaskar, fvdl, seanjc, pawan.kumar.gupta,
xin, tiala, Neeraj.Upadhyay, chang.seok.bae, thomas.lendacky,
elena.reshetova, linux-doc, linux-kernel, linux-coco, kvm,
eranian, peternewman
In-Reply-To: <88eebfac-5286-4788-b244-911c659c0439@intel.com>
Hi Reinette,
On 3/27/26 17:11, Reinette Chatre wrote:
> Hi Babu,
>
> On 3/26/26 10:12 AM, Babu Moger wrote:
>> Hi Reinette,
>>
>> Thanks for the review comments. Will address one by one.
>>
>> On 3/24/26 17:51, Reinette Chatre wrote:
>>> Hi Babu,
>>>
>>> On 3/12/26 1:36 PM, Babu Moger wrote:
>>>> This series adds support for Privilege-Level Zero Association (PLZA) to the
>>>> resctrl subsystem. PLZA is an AMD feature that allows specifying a CLOSID
>>>> and/or RMID for execution in kernel mode (privilege level zero), so that
>>>> kernel work is not subject to the same resource constrains as the current
>>>> user-space task. This avoids kernel operations being aggressively throttled
>>>> when a task's memory bandwidth is heavily limited.
>>>>
>>>> The feature documentation is not yet publicly available, but it is expected
>>>> to be released in the next few weeks. In the meantime, a brief description
>>>> of the features is provided below.
>>>>
>>>> Privilege Level Zero Association (PLZA)
>>>>
>>>> Privilege Level Zero Association (PLZA) allows the hardware to
>>>> automatically associate execution in Privilege Level Zero (CPL=0) with a
>>>> specific COS (Class of Service) and/or RMID (Resource Monitoring
>>>> Identifier). The QoS feature set already has a mechanism to associate
>>>> execution on each logical processor with an RMID or COS. PLZA allows the
>>>> system to override this per-thread association for a thread that is
>>>> executing with CPL=0.
>>>> ------------------------------------------------------------------------
>>>>
>>>> The series introduces the feature in a way that supports the interface in
>>>> a generic manner to accomodate MPAM or other vendor specific implimentation.
>>>>
>>>> Below is the detailed requirements provided by Reinette:
>>>> https://lore.kernel.org/lkml/2ab556af-095b-422b-9396-f845c6fd0342@intel.com/
>>> Our discussion considered how resctrl could support PLZA in a generic way while
>>> also preparing to support MPAM's variants and how PLZA may evolve to have similar
>>> capabilities when considering the capabilities of its registers.
>>>
>>> This does not mean that your work needs to implement everything that was discussed.
>>> Instead, this work is expected to just support what PLZA is capable of today but
>>> do so in a way that the future enhancements could be added to.
>>>
>>> This series is quite difficult to follow since it appears to implement a full
>>> featured generic interface while PLZA cannot take advantage of it.
>>>
>>> Could you please simplify this work to focus on just enabling PLZA and only
>>> add interfaces needed to do so?
>> Sure. Will try. Lets continue the discussion.
>>>> Summary:
>>>> 1. Kernel-mode/PLZA controls and status should be exposed under the resctrl
>>>> info directory:/sys/fs/resctrl/info/, not as a separate or arch-specific path.
>>>>
>>>> 2. Add two info files
>>>>
>>>> a. kernel_mode
>>>> Purpose: Control how resource allocation and monitoring apply in kernel mode
>>>> (e.g. inherit from task vs global assign).
>>>>
>>>> Read: List supported modes and show current one (e.g. with [brackets]).
>>>> Write: Set current mode by name (e.g. inherit_ctrl_and_mon, global_assign_ctrl_assign_mon).
>>>>
>>>> b. kernel_mode_assignment
>>>>
>>>> Purpose: When a “global assign” kernel mode is active, specify which resctrl group
>>>> (CLOSID/RMID) is used for kernel work.
>>>>
>>>> Read: Show the assigned group in a path-like form (e.g. //, ctrl1//, ctrl1/mon1/).
>>>> Write: Assign or clear the group used for kernel mode (and optionally clear with an empty write).
>>>>
>>>> The patches are based on top of commit (v7.0.0-rc3)
>>>> 839e91ce3f41b (tip/master) Merge branch into tip/master: 'x86/tdx'
>>>> ------------------------------------------------------------------------
>>>>
>>>> Examples: kernel_mode and kernel_mode_assignment
>>>>
>>>> All paths below are under /sys/fs/resctrl/ (e.g. info/kernel_mode means
>>>> /sys/fs/resctrl/info/kernel_mode). Resctrl must be mounted and the platform
>>>> must support the relevant modes (e.g. AMD with PLZA).
>>>>
>>>> 1) kernel_mode — show and set the current kernel mode
>>>>
>>>> Read supported modes and which one is active (current in brackets):
>>>>
>>>> $ cat info/kernel_mode
>>>> [inherit_ctrl_and_mon]
>>>> global_assign_ctrl_inherit_mon
>>>> global_assign_ctrl_assign_mon
>>>>
>>>> Set the active mode (e.g. use one CLOSID+RMID for all kernel work):
>>>>
>>>> $ echo "global_assign_ctrl_assign_mon" > info/kernel_mode
>>>> $ cat info/kernel_mode
>>>> inherit_ctrl_and_mon
>>>> global_assign_ctrl_inherit_mon
>>>> [global_assign_ctrl_assign_mon]
>>>>
>>>> Mode meanings:
>>>> - inherit_ctrl_and_mon: kernel uses same CLOSID/RMID as the current task (default).
>>>> - global_assign_ctrl_inherit_mon: one CLOSID for all kernel work; RMID inherited from user.
>>>> - global_assign_ctrl_assign_mon: one resource group (CLOSID+RMID) for all kernel work.
>>>>
>>>> 2) kernel_mode_assignment — show and set which group is used for kernel work
>>>>
>>>> Only relevant when kernel_mode is not "inherit_ctrl_and_mon". Read the
>>> To help with future usages please connect visibility of this file with the mode in
>>> info/kernel_mode. This helps us to support future modes with other resctrl files, possible
>>> within each resource group.
>>> Specifically, kernel_mode_assignment is not visible to user space if mode is "inherit_ctrl_and_mon",
>>> while it is visible when mode is global_assign_ctrl_inherit_mon or global_assign_ctrl_assign_mon.
>> Sure. Will do.
>>
>>>> currently assigned group (path format is "CTRL_MON/MON/"):
>>> The format depends on the mode, right? If the mode is "global_assign_ctrl_inherit_mon"
>>> then it should only contain a control group, alternatively, if the mode is
>>> "global_assign_ctrl_assign_mon" then it contains control and mon group. This gives
>>> resctrl future flexibility to change format for future modes.
>> This can be done both ways. Whole purpose of these groups is to get CLOSID and RMID to enable PLZA. User can echo CTRL_MON or MON group to kernel_mode_assignment in any of the modes. We can decide what needs to be updated in MSR (PQR_PLZA_ASSOC) based on what kernel mode is selected.
> The "both ways" are specific to one of the two active modes though.
> PLZA only needs the RMID when the mode is "global_assign_ctrl_assign_mon".
>
> Displaying and parsing monitor group when the mode is
> "global_assign_ctrl_inherit_mon" creates an inconsistent interface since the mode
> only uses a control group. The interface to user space should match the mode otherwise
> it becomes confusing.
Ok. That is fine. We can do that.
> ...
>
>
>>>> Tony suggested using global variables to store the kernel mode
>>>> CLOSID and RMID. However, the kernel mode CLOSID and RMID are
>>>> coming from rdtgroup structure with the new interface. Accessing
>>>> them requires holding the associated lock, which would make the
>>>> context switch path unnecessarily expensive. So, dropped the idea.
>>>> https://lore.kernel.org/lkml/aXuxVSbk1GR2ttzF@agluck-desk3/
>>>> Let me know if there are other ways to optimize this.
>>> I do not see why the context switch path needs to be touched at all with this
>>> implementation. Since PLZA only supports global assignment does it not mean that resctrl
>>> only needs to update PQR_PLZA_ASSOC when user writes to info/kernel_mode and
>>> info/kernel_mode_assignment?
>> Each thread has an MSR to configure whether to associate privilege level zero execution with a separate COS and/or RMID, and the value of the COS and/or RMID. PLZA may be enabled or disabled on a per-thread basis. However, the COS and RMID association and configuration must be the same for all threads in the QOS Domain.
> Based on previous comment in https://lore.kernel.org/lkml/abb049fa-3a3d-4601-9ae3-61eeb7fd8fcf@amd.com/
> and this implementation all fields of PQR_PLZA_ASSOC except PQR_PLZA_ASSOC.plza_en must be the
> same for all CPUs on the system, not just per QoS domain. Could you please confirm?
Sorry for the confusion. It is "per QoS domain".
All the fields of PQR_PLZA_ASSOC except PQR_PLZA_ASSOC.plza_enmust be set to the same value for all HW threads in the QOS domain for
consistent operation (Per-QosDomain).
>
>> So, PQR_PLZA_ASSOC is a per thread MSR just like PQR_ASSOC.
>>
>> Privilege-Level Zero Association (PLZA) allows the user to specify a COS and/or RMID associated with execution in Privilege-Level Zero. When enabled on a HW thread, when that thread enters Privilige-Level Zero, transactions associated with that thread will be associated with the PLZA COS and/or RMID. Otherwise, the HW thread will be associated with the COS and RMID identified by PQR_ASSOC.
>>
>> More below.
>>
>>> Consider some of the scenarios:
>>>
>>> resctrl mount with default state:
>>>
>>> # cat info/kernel_mode
>>> [inherit_ctrl_and_mon]
>>> global_assign_ctrl_inherit_mon
>>> global_assign_ctrl_assign_mon
>>> # ls info/kernel_mode_assignment
>>> ls: cannot access 'info/kernel_mode_assignment': No such file or directory
>>>
>>> enable global_assign_ctrl_assign_mon mode:
>>> # echo "global_assign_ctrl_assign_mon" > info/kernel_mode
>>>
>>> Expectation here is that when user space sets this mode as above then resctrl would
>>> in turn program MSR_IA32_PQR_PLZA_ASSOC on all CPUs to be:
>>> MSR_IA32_PQR_PLZA_ASSOC.rmid=0
>>> MSR_IA32_PQR_PLZA_ASSOC.rmid_en=1
>>> MSR_IA32_PQR_PLZA_ASSOC.closid=0
>>> MSR_IA32_PQR_PLZA_ASSOC.closid_en=1
>>> MSR_IA32_PQR_PLZA_ASSOC.plza_en=1
>>>
>>> I do not see why it is necessary to maintain any per-CPU or per-task state or needing
>>> to touch the context switch code. Since PLZA only supports global could it not
>>> just set MSR_IA32_PQR_PLZA_ASSOC on all online CPUs and be done with it?
>>> Only caveat is that if a CPU is offline then this setting needs to be stashed
>>> so that MSR_IA32_PQR_PLZA_ASSOC can be set when new CPU comes online.
>>>
>>> The way that rdtgroup_config_kmode() introduced in patch #11 assumes it is dealing
>>> with RDT_RESOURCE_L3 and traverses the resource domain list and resource group
>>> CPU mask seems unnecessary to me as well as error prone since the system may only
>>> have, for example, RDT_RESOURCE_MBA enabled or even just monitoring. Why not just set
>>> MSR_IA32_PQR_PLZA_ASSOC on all CPUs and be done?
>>>
>>> To continue the scenarios ...
>>>
>>> After user's setting above related files read:
>>> # cat info/kernel_mode
>>> inherit_ctrl_and_mon
>>> global_assign_ctrl_inherit_mon
>>> [global_assign_ctrl_assign_mon]
>>> # cat info/kernel_mode_assignment
>>> //
>>>
>>> Modify group used by global_assign_ctrl_assign_mon mode:
>>> # echo 'ctrl1/mon1/' > info/kernel_mode_assignment
>>>
>>> Expectation here is that when user space sets this then resctrl would
>>> program MSR_IA32_PQR_PLZA_ASSOC on all CPUs to be:
>>> MSR_IA32_PQR_PLZA_ASSOC.rmid=<rmid of mon1>
>>> MSR_IA32_PQR_PLZA_ASSOC.rmid_en=1
>>> MSR_IA32_PQR_PLZA_ASSOC.closid=<closid of ctrl1>
>>> MSR_IA32_PQR_PLZA_ASSOC.closid_en=1
>>> MSR_IA32_PQR_PLZA_ASSOC.plza_en=1
>>
>> This works correctly when PLZA associations are defined by per CPU. For example, lets assume that *ctrl1* is assigned *CLOSID 1*.
>>
>> In this scenario, every task in the system running on a any CPU will use the limits associated with *CLOSID 1* whenever it enters Privilege-Level Zero, because the CPU's *PQR_PLZA_ASSOC* register has PLZA enabled and CLOSID is 1.
>>
>> Now consider task-based association:
>>
>> We have two resctrl groups:
>>
>> * *ctrl1 -> CLOSID 1 -> task1.plza = 1 : *User wants PLZA be enabled
>> for this task.
>> * *ctrl2 -> CLOSID 2 -> task2.plza = 0 : *User wants PLZA
>> disabled for this task.
>>
>> Suppose *task1* is first scheduled on *CPU 0*. This behaves as expected: since CPU 0 's *PQR_PLZA_ASSOC* contains *CLOSID 1, plza_en =1*, task1 will use the limits from CLOSID 1 when it enters Privilege-Level Zero.
>>
>> However, if *task2* later runs on *CPU 0*, we expect it to use *CLOSID 2* in both user mode and kernel mode, because user has PLZA disabled for this task. But CPU 0 still has *CLOSID 1, **plza_en =1* in its PQR_PLZA_ASSOC register.
>>
>> As a result, task2 will incorrectly run with *CLOSID 1* when entering Privilege-Level Zero something we explicitly want to avoid.
>>
>> At that point, PLZA must be disabled on CPU 0 to prevent the unintended association. Hope this explanation makes the issue clear.
>>
> A couple of points:
> - Looks like we still need to come to agreement what is meant by "global" when it
> comes to kernel mode.
>
> In your description there is a "global" configuration, but the assignment is "per-task".
> To me this sounds like a new and distinct kernel_mode from the "global" modes
> considered so far. This seems to move to the "per_task" mode mentioned in but
> the implementation does not take into account any of the earlier discussions
> surrounding it:
> https://lore.kernel.org/lkml/2ab556af-095b-422b-9396-f845c6fd0342@intel.com/
>
> We only learned about one use case in https://lore.kernel.org/lkml/CABPqkBSq=cgn-am4qorA_VN0vsbpbfDePSi7gubicpROB1=djw@mail.gmail.com/
> As I understand this use case requires PLZA globally enabled for all tasks. Thus
> I consider task assignment to be "global" when in the "global_*" kernel modes.
> If this is indeed a common use case then supporting only global configuration
> but then requiring user space to manually assign all tasks afterwards sounds
> cumbersome for user space and also detrimental to system performance with all
> the churn to modify all the task_structs involved. The accompanying documentation
> does not mention all this additional user space interactions required by user
> space to use this implementation.
>
> I find this implementation difficult and inefficient to use in the one use case
> we know of. I would suggest that resctrl optimizes for the one known use case.
>
> - This implementation ignores discussion on how existing resctrl files should
> not be repurposed.
>
> This implementation allows user space to set a resource group in
> kernel_mode_assignment with the consequence that this resource group's
> "tasks" file changes behavior. I consider this a break of resctrl interface.
> We did briefly consider per-task configuration/assignment in previous discussion
> and the proposal was for it to use a new file (only when and if needed!).
>
> - Now a user is required to write the task id of every task that participates
> in PLZA. Apart from the churn already mentioned this also breaks existing
> usage since it is no longer possible for new tasks to be added to this
> resource group. This creates an awkward interface where all tasks belonging
> to a resource group inherits the allocations/monitoring for their user space
> work and will get PLZA enabled whether user requested it or not while
> tasks from other resource groups need to be explicitly enabled. This creates
> an inconsistency when it comes to task assignment. The only way to "remove"
> PLZA from such a task would be to assign it to another resource group which
> may not have the user space allocations ... and once this is done the task
> cannot be moved back.
> There is no requirement that CLOSID/RMID should be dedicated to kernel work
> but this implementation does so in an inconsistent way.
>
> - Apart from the same issues as with repurposing of tasks file, why should same
> CPU allocation be used for kernel and user space?
>
Yes, I agree with your concerns. The goal here is to make the interface
less disruptive while still addressing the different use cases.
Background: Customers have identified an issue with the QoS
Bandwidth Control feature: when a CLOS is aggressively throttled
and execution transitions into kernel mode, kernel operations are
also subject to the same aggressive throttling.
Privilege-Level Zero Association (PLZA) allows a user to specify a COS
and/or RMID to be used during execution at Privilege Level Zero. When
PLZA is enabled on a hardware thread, any execution that enters
Privilege Level Zero will have its transactions associated with the PLZA
COS and/or RMID. Otherwise, the thread continues to use the COS and RMID
specified by |PQR_ASSOC|. In other words, the hardware provides a
dedicated COS and/or RMID specifically for kernel-mode execution.
There are multiple ways this feature can be applied. For simplicity, the
discussion below focuses only on CLOSID.
1. Global PLZA enablement
PLZA can be configured as a global feature by setting
|PQR_PLZA_ASSOC.closid = CLOSID| and |PQR_PLZA_ASSOC.plza_en = 1| on all
threads in the system. A dedicated CLOSID is reserved for this purpose,
and all CPU threads use its allocations whenever they enter Privilege
Level Zero. This CLOSID does not need to be associated with any resctrl
group. The user can explicitly enable or disable this feature. There is
no context switch overhead but there is no flexibility with this approach.
2. Group based PLZA allocation : PLZA is managed via dedicated
restctrl group. A separate resctrl group can be created
specifically for PLZA, with a dedicated CLOSID used exclusively
for kernel mode execution. This approach can be further divided
into two association models:
i) CPU based association
CPUs are assigned to the PLZA group, and PLZA is enabled only on those
CPUs. This effectively creates a dedicated PLZA group. MSRs
(|PQR_PLZA_ASSOC)| are programmed only when the user changes CPU
assignments. This approach requires no changes to the context switch
code and introduces no additional context switch overhead.
ii) Task based association
Tasks are explicitly assigned by the user to the PLZA group. Tasks need
to be updated when user adds a new task. Also, this requires updates
during task scheduling so that the MSRs (|PQR_PLZA_ASSOC)| are
programmed on each context switch, which introduces additional context
switch overhead.
I tried to fit these requirements into the interface files in
/sys/fs/resctrl/info/. I may have missed few things while trying to
achieve it. As usual, I am open for the discussion and recommendations.
Thanks,
Babu
^ permalink raw reply
* [PATCH v2] docs: pt_BR: translate process/2.Process.rst
From: Daniel Castro @ 2026-03-30 18:02 UTC (permalink / raw)
To: danielmaraboo; +Cc: corbet, linux-doc, Daniel Castro
Add Brazilian Portuguese translation of the development process
document (Documentation/process/2.Process.rst), covering the
development cycle overview, patch lifecycle, subsystem trees,
staging trees, tools, mailing lists, and getting started with
kernel development.
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Daniel Castro <arantescastro@gmail.com>
---
v2: Fix stray line breaks throughout the file.
Documentation/translations/pt_BR/index.rst | 1 +
.../translations/pt_BR/process/2.Process.rst | 502 ++++++++++++++++++
2 files changed, 503 insertions(+)
create mode 100644 Documentation/translations/pt_BR/process/2.Process.rst
diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
index 4f7fcc3c66fb..edf19ddf8916 100644
--- a/Documentation/translations/pt_BR/index.rst
+++ b/Documentation/translations/pt_BR/index.rst
@@ -69,4 +69,5 @@ kernel e sobre como ver seu trabalho integrado.
Introdução <process/1.Intro>
Como começar <process/howto>
Requisitos mínimos <process/changes>
+ Como o processo de desenvolvimento funciona <process/2.Process>
Manuais dos mantenedores <process/maintainer-handbooks>
diff --git a/Documentation/translations/pt_BR/process/2.Process.rst b/Documentation/translations/pt_BR/process/2.Process.rst
new file mode 100644
index 000000000000..a3ab18c0f8d6
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/2.Process.rst
@@ -0,0 +1,502 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Como o processo de desenvolvimento funciona
+===========================================
+
+O desenvolvimento do kernel Linux no início da década de 1990 era bastante
+informal, com um número relativamente pequeno de usuários e desenvolvedores
+envolvidos. Com uma base de usuários na casa dos milhões e cerca de 2.000
+desenvolvedores envolvidos ao longo de um ano, o kernel teve que desenvolver uma
+série de processos para manter o desenvolvimento fluindo sem problemas. Um
+sólido conhecimento de como o processo funciona é necessário para participar
+efetivamente dele.
+
+Visão geral
+-----------
+
+O kernel Linux utiliza um modelo de desenvolvimento contínuo ("rolling release")
+baseado em prazos flexíveis. Uma nova versão principal do kernel (que
+chamaremos, por exemplo, de 9.x) [1]_ ocorre a cada dois ou três meses, trazendo
+novos recursos, alterações internas na API e muito mais. Uma versão típica pode
+conter cerca de 13.000 conjuntos de alterações, com mudanças em várias centenas
+de milhares de linhas de código. Versões recentes, juntamente com suas datas,
+podem ser encontradas na `Wikipedia
+<https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_.
+
+.. [1] Rigorosamente falando, o kernel Linux não utiliza o esquema de
+ versionamento semântico. Em vez disso, o par 9.x identifica a
+ versão principal como um número inteiro. Para cada versão, x é
+ incrementado, mas 9 é incrementado apenas se x for considerado
+ grande o suficiente (por exemplo, o Linux 5.0 é lançado após o
+ Linux 4.20).
+
+Segue-se um procedimento relativamente simples quanto à integração de patches
+para cada lançamento. No início de cada ciclo de desenvolvimento, a janela de
+fusão ("merge window") é considerada aberta. Nesse momento, o código que é
+considerado suficientemente estável (e que é aceito pela comunidade de
+desenvolvimento) é integrado ao kernel principal. A maior parte das alterações
+para um novo ciclo de desenvolvimento (e todas as principais alterações) será
+integrada durante esse período, a uma taxa próxima de 1.000 alterações
+("patches" ou "conjuntos de alterações") por dia.
+
+(Vale observar que as alterações integradas durante a janela de merge não surgem
+do nada; elas foram coletadas, testadas e preparadas com antecedência. O
+funcionamento desse processo será descrito em detalhes mais adiante).
+
+A janela de merge dura aproximadamente duas semanas. Ao final desse período,
+Linus Torvalds declarará que a janela está fechada e lançará o primeiro dos
+kernels "rc". Para o kernel que está destinado a ser o 9.x, por exemplo, o
+lançamento que ocorre ao final da janela de merge será chamado de 9.x-rc1. O
+lançamento -rc1 é o sinal de que o tempo para incorporar novos recursos passou e
+que o tempo para estabilizar o próximo kernel começou.
+
+Nas próximas seis a dez semanas, somente patches que corrijam problemas devem
+ser enviados para a versão principal ("mainline"). Ocasionalmente, uma mudança
+mais significativa será permitida, mas tais ocasiões são raras; desenvolvedores
+que tentam integrar novos recursos fora da janela de merge tendem a receber uma
+recepção pouco calorosa. Como regra geral, se você perder a janela de merge
+para um determinado recurso, o melhor a fazer é esperar pelo próximo ciclo de
+desenvolvimento. (Uma exceção ocasional é feita para drivers para hardware
+anteriormente não suportado; se eles não alterarem nenhum código já presente na
+árvore ("in-tree"), não podem causar regressões e podem ser adicionados com
+segurança a qualquer momento).
+
+À medida que as correções são incorporadas à mainline, o ritmo de envio de
+patches diminui gradualmente. Linus lança novos kernels -rc aproximadamente uma
+vez por semana; uma série normal costuma chegar entre o -rc6 e o -rc9 antes que
+o kernel seja considerado suficientemente estável para o lançamento da versão
+final. Nesse ponto, todo o processo se reinicia.
+
+Como exemplo, veja como foi o ciclo de desenvolvimento da versão 5.4 (todas as
+datas em 2019):
+
+ ============== ===================================================
+ 15 de setembro Lançamento da versão estável 5.3
+ 30 de setembro 5.4-rc1, janela de merge fechada
+ 6 de outubro 5.4-rc2
+ 13 de outubro 5.4-rc3
+ 20 de outubro 5.4-rc4
+ 27 de outubro 5.4-rc5
+ 3 de novembro 5.4-rc6
+ 10 de novembro 5.4-rc7
+ 17 de novembro 5.4-rc8
+ 24 de novembro 5.4 lançamento da versão estável ("stable release")
+ ============== ===================================================
+
+Como os desenvolvedores decidem quando encerrar o ciclo de desenvolvimento e
+criar a versão estável? A métrica mais importante utilizada é a lista de
+regressões em relação às versões anteriores. Nenhum bug é bem-vindo, mas aqueles
+que quebram sistemas que funcionavam no passado são considerados especialmente
+graves. Por esse motivo, patches que causam regressões são vistos com maus olhos
+e têm grande probabilidade de serem revertidas durante o período de
+estabilização.
+
+O objetivo dos desenvolvedores é corrigir todas as regressões conhecidas antes
+do lançamento da versão estável. Na prática, esse nível de perfeição é difícil
+de alcançar; há muitas variáveis em um projeto desse porte. Chega um ponto em
+que adiar o lançamento final só piora o problema; a pilha de alterações
+aguardando a próxima janela de merge aumentará, criando ainda mais regressões na
+próxima vez. Portanto, a maioria dos kernels é lançada com algumas regressões
+conhecidas, embora, idealmente, nenhuma delas seja grave.
+
+Assim que uma versão estável é lançada, sua manutenção contínua é transferida
+para a equipe estável ("stable team"), atualmente composta por Greg
+Kroah-Hartman e Sasha Levin. A equipe estável lançará atualizações ocasionais
+para a versão estável usando o esquema de numeração 9.x.y.
+
+Para ser considerado para uma versão de atualização ("update release"), um patch
+deve (1) corrigir um bug significativo e (2) já ter sido incorporado à mainline
+do próximo kernel de desenvolvimento. Os kernels normalmente recebem
+atualizações estáveis por um pouco mais de um ciclo de desenvolvimento após o
+lançamento inicial. Assim, por exemplo, o histórico do kernel 5.2 era o seguinte
+(todas as datas em 2019):
+
+ ============== ===============================
+ 7 de julho 5.2 versão estável
+ 14 de julho 5.2.1
+ 21 de julho 5.2.2
+ 26 de julho 5.2.3
+ 28 de julho 5.2.4
+ 31 de julho 5.2.5
+ ... ...
+ 11 de outubro 5.2.21
+ ============== ===============================
+
+A versão 5.2.21 foi a última atualização estável da série 5.2.
+
+Alguns kernels são designados como kernels de "longo prazo"; eles receberão
+suporte por um período mais longo. Consulte o seguinte link para obter a lista
+de versões de kernel de longo prazo ativas e seus respectivos mantenedores:
+
+ https://www.kernel.org/category/releases.html
+
+A seleção de um kernel para suporte a longo prazo ("long-term support") é
+puramente uma questão de um mantenedor ter a necessidade e o tempo para manter
+essa versão. Não há planos conhecidos para suporte a longo prazo para qualquer
+versão futura específica.
+
+O ciclo de vida de um patch
+---------------------------
+
+Os patches não vão diretamente do teclado do desenvolvedor para o kernel
+principal ("mainline"). Em vez disso, existe um processo razoavelmente complexo
+(embora relativamente informal) projetado para garantir que cada patch seja
+revisado quanto à qualidade e que cada patch implemente uma alteração desejável
+no kernel mainline.
+
+Esse processo pode ser rápido para correções menores ou, no caso de mudanças
+grandes e controversas, levar anos. Grande parte da frustração dos
+desenvolvedores vem da falta de compreensão desse processo ou de tentativas de
+contorná-lo.
+
+Na esperança de reduzir essa frustração, este documento descreverá como um patch
+é inserido no kernel. O que se segue é uma introdução que descreve o processo de
+forma um tanto idealizada. Uma abordagem muito mais detalhada será apresentada
+em seções posteriores.
+
+As etapas pelas quais um patch passa são, geralmente:
+
+ - Projeto ("Design"). É aqui que os requisitos reais para o patch - e a
+ maneira como esses requisitos serão atendidos - são definidos. O trabalho
+ de projeto geralmente é feito sem envolver a comunidade, mas é melhor
+ fazer esse trabalho de forma aberta, se possível; isso pode economizar
+ muito tempo com reformulações posteriores.
+
+ - Revisão inicial ("Early review"). Os patches são enviados para a lista
+ de discussão relevante, e os desenvolvedores dessa lista respondem com
+ quaisquer comentários que possam ter. Esse processo deve revelar quaisquer
+ problemas importantes com um patch, se tudo correr bem.
+
+ - Revisão mais ampla ("Wider review"). Quando o patch estiver quase pronto
+ para inclusão na mainline, ele deve ser aceito por um mantenedor de
+ subsistema relevante - embora essa aceitação não seja uma garantia de que
+ o patch chegará à mainline. O patch aparecerá na árvore do subsistema do
+ mantenedor e nas árvores -next (descritas abaixo). Quando o processo
+ funciona, esta etapa leva a uma revisão mais extensa do patch e à
+ descoberta de quaisquer problemas resultantes da integração deste patch
+ com o trabalho que está sendo feito por outros.
+
+- Observe que a maioria dos mantenedores também tem empregos regulares,
+ portanto, o merge do seu patch pode não ser a prioridade máxima deles.
+ Se o seu patch estiver recebendo feedback sobre mudanças necessárias,
+ você deve implementá-las ou justificar por que não devem ser feitas.
+ Se o seu patch não tiver reclamações de revisão, mas não estiver sendo
+ integrado pelo mantenedor do subsistema ou driver apropriado, você deve
+ persistir na atualização do patch para o kernel atual para que ele se
+ aplique corretamente e continuar enviando-o para revisão e merge.
+
+ - Integração na mainline. Por fim, um patch bem-sucedido será incorporado
+ ao repositório mainline gerenciado por Linus Torvalds. Novos comentários
+ ou problemas podem surgir nesta etapa; é fundamental que o desenvolvedor
+ responda prontamente a eles e solucione quaisquer falhas que surjam.
+
+ - Versão estável. A base de usuários afetada pelo patch agora é ampla;
+ consequentemente, novas falhas podem ser detectadas.
+
+ - Manutenção a longo prazo ("long-term maintenance"). Embora seja plenamente
+ possível que um desenvolvedor se esqueça de seu código após a integração,
+ tal comportamento tende a causar uma má impressão na comunidade. A
+ incorporação do código alivia parte do fardo da manutenção, uma vez que
+ outros desenvolvedores corrigirão possíveis falhas decorrentes de mudanças
+ na API. Contudo, o autor original deve manter a responsabilidade sobre o
+ código, caso deseje que ele permaneça útil a longo prazo.
+
+Um dos maiores erros cometidos pelos desenvolvedores do kernel (ou seus
+empregadores) é tentar reduzir o processo a uma única etapa de "integração à
+mainline". Essa abordagem invariavelmente leva à frustração de todos os
+envolvidos.
+
+Como os patches chegam ao Kernel
+--------------------------------
+
+Existe apenas uma pessoa que pode incorporar patches ao repositório mainline do
+kernel: Linus Torvalds. No entanto, dos mais de 9.500 patches integrados ao
+kernel 2.6.38, por exemplo, apenas 112 (cerca de 1,3%) foram selecionados
+diretamente por ele. O projeto do kernel há muito superou a escala em que um
+único desenvolvedor seria capaz de inspecionar e filtrar todas as contribuições
+sem auxílio. A solução adotada pela comunidade para gerenciar esse crescimento
+foi a implementação de uma hierarquia de mantenedores fundamentada em uma cadeia
+de confiança.
+
+A base de código do kernel é subdividida logicamente em subsistemas: rede,
+suporte a arquiteturas específicas, gerenciamento de memória, dispositivos de
+vídeo, entre outros. A maioria possui um mantenedor designado — um desenvolvedor
+com responsabilidade integral pelo código daquela área. Esses mantenedores
+atuam, em linhas gerais, como os guardiões de seus respectivos domínios, sendo
+os responsáveis por validar e aceitar patches para inclusão no kernel mainline.
+
+Cada mantenedor de subsistema gerencia sua própria versão da árvore de códigos
+do kernel, geralmente (mas nem sempre) utilizando a ferramenta de controle de
+versão git. Ferramentas como o git (e correlatas, como quilt ou mercurial)
+permitem que os mantenedores rastreiem uma lista de patches, incluindo
+informações de autoria e outros metadados. A qualquer momento, o mantenedor
+consegue identificar quais patches em seu repositório não constam na mainline.
+
+Quando a janela de merge é aberta, os mantenedores de alto nível solicitam que
+Linus realize o "pull" dos patches selecionados em seus respectivos repositórios
+para integração. Caso Linus concorde, o fluxo de patches sobe para o seu
+repositório, tornando-se parte do kernel mainline. O nível de atenção que Linus
+dedica a patches específicos recebidos em uma operação de pull varia; é evidente
+que, por vezes, ele os analisa minuciosamente. No entanto, como regra geral,
+Linus confia que os mantenedores de subsistemas não enviarão patches
+problemáticos para o topo da cadeia ("upstream").
+
+Os mantenedores de subsistemas, por sua vez, podem realizar o pull de patches de
+outros mantenedores. Por exemplo, a árvore de rede é construída a partir de
+patches que se acumularam primeiramente em árvores dedicadas a drivers de
+dispositivos de rede, redes sem fio, entre outras. Essa sequência de
+repositórios pode ser arbitrariamente longa, embora raramente exceda dois ou
+três elos. Cada mantenedor na cadeia confia naqueles que gerenciam as árvores de
+nível inferior; esse processo é conhecido como "cadeia de confiança".
+
+Claramente, em um sistema como este, a inclusão de patches no kernel depende de
+encontrar o mantenedor correto. Enviar patches diretamente para Linus não
+costuma ser o procedimento adequado.
+
+Árvores next ("Next trees")
+---------------------------
+
+A cadeia de árvores de subsistemas orienta o fluxo de patches para o kernel, mas
+também levanta uma questão interessante: e se alguém quiser analisar todos os
+patches que estão sendo preparados para a próxima janela de merge?
+Desenvolvedores estarão interessados em quais outras mudanças estão pendentes
+para verificar se há conflitos preocupantes; um patch que altere o protótipo de
+uma função essencial do kernel, por exemplo, entrará em conflito com quaisquer
+outros patches que utilizem a forma antiga dessa função. Revisores e testadores
+desejam acessar as mudanças em sua forma integrada antes que todas elas cheguem
+ao kernel mainline. Seria possível realizar o pull de alterações de todas as
+árvores de subsistemas relevantes, mas isso seria uma tarefa onerosa e propensa
+a erros.
+
+A resposta vem na forma das árvores -next, onde as árvores de subsistemas são
+reunidas para testes e revisão. A mais antiga dessas árvores, mantida por Andrew
+Morton, é chamada de "-mm" (sigla para "memory management", ou gerenciamento de
+memória, que deu origem ao nome). A árvore -mm integra patches de uma extensa
+lista de árvores de subsistemas e também contém alguns patches voltados para
+auxiliar na depuração ("debugging").
+
+Além disso, a -mm contém uma coleção significativa de patches selecionados
+diretamente por Andrew. Esses patches podem ter sido publicados em uma lista de
+discussão ("mailing list") ou podem se aplicar a uma parte do kernel para a qual
+não exista uma árvore de subsistema designada. Como resultado, a -mm opera como
+uma espécie de árvore de subsistema de última instância; se não houver outro
+caminho óbvio para um patch chegar à mainline, é provável que ele termine na
+-mm. Patches diversos que se acumulam na -mm serão, eventualmente, encaminhados
+para uma árvore de subsistema apropriada ou enviados diretamente para Linus. Em
+um ciclo de desenvolvimento típico, aproximadamente 5% a 10% dos patches que
+entram na mainline chegam lá via -mm.
+
+O patch -mm atual está disponível no diretório "mmotm" (-mm of the moment) em:
+
+ https://www.ozlabs.org/~akpm/mmotm/
+
+O uso da árvore MMOTM, entretanto, tende a ser uma experiência frustrante; há
+uma chance real de que o código sequer compile.
+
+A árvore principal para a integração de patches do próximo ciclo é a linux-next,
+mantida por Mark Brown. A linux-next é, por concepção, uma captura ("snapshot")
+do que se espera que a mainline venha a ser após o fechamento da próxima janela
+de merge. As árvores linux-next são anunciadas nas listas de discussão
+linux-kernel e linux-next assim que são consolidadas; elas podem ser baixadas
+em:
+
+ https://www.kernel.org/pub/linux/kernel/next/
+
+A linux-next tornou-se parte integrante do processo de desenvolvimento do
+kernel; idealmente, todos os patches incorporados durante uma determinada janela
+de merge devem ter sido integrados à linux-next algum tempo antes da abertura
+dessa janela.
+
+Árvores de Staging ("Staging trees")
+------------------------------------
+
+A árvore de código-fonte do kernel contém o diretório drivers/staging/, que
+abriga diversos subdiretórios de drivers ou sistemas de arquivos em processo de
+inclusão na árvore do kernel. Eles permanecem em drivers/staging/ enquanto
+demandam aprimoramentos; uma vez concluídos, podem ser movidos para o kernel
+propriamente dito. Esta é uma forma de rastrear drivers que ainda não atingiram
+os padrões de codificação ou qualidade do kernel Linux, mas que a comunidade
+pode desejar utilizar e acompanhar o desenvolvimento.
+
+Atualmente, Greg Kroah-Hartman mantém a árvore de staging. Drivers que ainda
+necessitam de ajustes são enviados a ele, cada um ocupando seu próprio
+subdiretório em drivers/staging/. Juntamente com os arquivos-fonte do driver,
+deve constar um arquivo TODO no diretório. O arquivo TODO lista as tarefas
+pendentes para a aceitação no kernel propriamente dito, além de uma lista de
+pessoas que devem ser copiadas ("Cc'd") em quaisquer patches relacionados ao
+driver. As regras atuais exigem que os drivers submetidos ao staging devam, no
+mínimo, compilar corretamente.
+
+O staging pode ser um caminho relativamente simples para inserir novos drivers
+na mainline onde, com sorte, atrairão a atenção de outros desenvolvedores e
+evoluirão rapidamente. Entretanto, a entrada no staging não encerra o processo;
+códigos que não apresentem progresso regular acabarão removidos. Além disso, os
+distribuidores tendem a ser relutantes em habilitar drivers de staging.
+Portanto, o staging é, na melhor das hipóteses, uma etapa temporária no percurso
+para se tornar um driver adequado para a mainline.
+
+Ferramentas
+-----------
+
+Conforme observado no texto anterior, o processo de desenvolvimento do kernel
+depende fortemente da capacidade de orquestrar coleções de patches em diversas
+direções. O sistema como um todo não funcionaria com a eficiência atual sem o
+auxílio de ferramentas adequadamente robustas. Tutoriais sobre o uso dessas
+ferramentas estão além do escopo deste documento, mas cabe aqui apresentar
+algumas orientações básicas.
+
+O sistema de gerenciamento de código-fonte predominante na comunidade do kernel
+é, de longe, o git. O git é um dos diversos sistemas de controle de versão
+distribuídos desenvolvidos pela comunidade de software livre. Ele é altamente
+otimizado para o desenvolvimento do kernel, apresentando excelente desempenho ao
+lidar com grandes repositórios e volumes massivos de patches. Também possui a
+reputação de ser complexo para aprender e operar, embora tenha evoluído
+significativamente com o tempo. Algum nível de domínio da ferramenta é
+praticamente um requisito para desenvolvedores de kernel; mesmo que não a
+utilizem em seu próprio fluxo de trabalho, precisarão do git para acompanhar as
+atividades de outros desenvolvedores (e da mainline).
+
+O git já está disponível nos repositórios de quase todas as distribuições Linux.
+A página oficial do projeto encontra-se em:
+
+ https://git-scm.com/
+
+Essa página contém links para documentações e tutoriais.
+
+Entre os desenvolvedores de kernel que não utilizam o git, a escolha mais
+popular é, quase certamente, o Mercurial:
+
+ https://www.selenic.com/mercurial/
+
+O Mercurial compartilha muitos recursos com o git, mas oferece uma interface que
+muitos consideram mais fácil de usar.
+
+A outra ferramenta que vale a pena conhecer é o Quilt:
+
+ https://savannah.nongnu.org/projects/quilt/
+
+O quilt é um sistema de gerenciamento de patches, em vez de um sistema de
+gerenciamento de código-fonte. Ele não rastreia o histórico ao longo do tempo;
+em vez disso, é orientado ao rastreamento de um conjunto específico de
+alterações em relação a uma base de código em evolução. Alguns mantenedores de
+subsistemas importantes usam o quilt para gerenciar patches destinados ao
+upstream. Para o gerenciamento de certos tipos de árvores (como a -mm, por
+exemplo), o quilt é a melhor ferramenta para o trabalho.
+
+Listas de discussão ("Mailing lists")
+-------------------------------------
+
+Grande parte do trabalho de desenvolvimento do kernel Linux é realizada por meio
+de listas de discussão ("mailing lists"). É difícil participar plenamente da
+comunidade sem ingressar em, pelo menos, uma lista em algum lugar. No entanto,
+as listas de discussão do Linux também representam um risco potencial para os
+desenvolvedores, que podem acabar soterrados por uma carga de mensagens
+eletrônicas, infringir as convenções utilizadas nas listas do Linux, ou ambos.
+
+A maioria das listas de discussão do kernel está hospedada em kernel.org; a
+lista principal pode ser encontrada em:
+
+ https://subspace.kernel.org
+
+Existem listas hospedadas em outros locais; por favor, verifique o arquivo
+MAINTAINERS para encontrar a lista relevante de qualquer subsistema específico.
+
+A principal lista de discussão para o desenvolvimento do kernel é, naturalmente,
+a linux-kernel. Esta lista é um lugar intimidador; o volume pode chegar a 500
+mensagens por dia, o nível de ruído é alto, as conversas podem ser extremamente
+técnicas e os participantes nem sempre estão preocupados em demonstrar um alto
+grau de polidez. No entanto, não há outro lugar onde a comunidade de
+desenvolvimento do kernel se reúna como um todo; desenvolvedores que evitam esta
+lista perderão informações importantes.
+
+Existem algumas dicas que podem ajudar na sobrevivência à linux-kernel:
+
+ - Direcione as mensagens da lista para uma pasta separada, em vez de
+ sua caixa de entrada principal. É preciso ser capaz de ignorar o fluxo
+ de mensagens por períodos prolongados.
+
+ - Não tente acompanhar todas as conversas — ninguém consegue. É importante
+ filtrar tanto pelo tópico de interesse (embora conversas longas possam se
+ desviar do assunto original sem alterar o campo de assunto do e-mail)
+ quanto pelas pessoas que estão participando.
+
+ - Não alimente os trolls. Se alguém estiver tentando provocar uma reação
+ irritada, ignore-o.
+
+ - Ao responder a um e-mail da linux-kernel (ou de outras listas), preserve
+ o cabeçalho Cc: para todos os envolvidos. Na ausência de um motivo forte
+ (como uma solicitação explícita), você nunca deve remover destinatários.
+ Certifique-se sempre de que a pessoa a quem você está respondendo esteja
+ na lista de Cc:. Essa convenção também torna desnecessário pedir
+ explicitamente para ser copiado nas respostas às suas postagens.
+
+ - Pesquise nos arquivos da lista (e na rede como um todo) antes de fazer
+ perguntas. Alguns desenvolvedores podem ficar impacientes com pessoas
+ que claramente não fizeram o "dever de casa".
+
+ - Use respostas intercaladas ("inline"), o que torna sua resposta mais
+ fácil de ler. (Ou seja, evite o "top-posting" — a prática de colocar
+ sua resposta acima do texto citado ao qual você está respondendo).
+ Para mais detalhes, veja:
+ :ref:`Documentation/process/submitting-patches.rst <interleaved_replies>`.
+
+ - Pergunte na lista de discussão correta. A linux-kernel pode ser o ponto
+ de encontro geral, mas não é o melhor lugar para encontrar desenvolvedores
+ de todos os subsistemas.
+
+O último ponto — encontrar a lista de discussão correta — é onde desenvolvedores
+iniciantes costumam errar. Alguém que faça uma pergunta relacionada a redes na
+linux-kernel quase certamente receberá uma sugestão educada para perguntar na
+lista netdev, pois essa é a lista frequentada pela maioria dos desenvolvedores
+de rede. Existem outras listas para os subsistemas SCSI, video4linux, IDE,
+sistemas de arquivos ("filesystems"), etc. O melhor lugar para procurar por
+listas de discussão é no arquivo MAINTAINERS que acompanha o código-fonte do
+kernel.
+
+Iniciando no desenvolvimento do Kernel
+--------------------------------------
+
+Dúvidas sobre como iniciar no processo de desenvolvimento do kernel são comuns —
+tanto por parte de indivíduos quanto de empresas. Igualmente comuns são os
+tropeços que tornam o início desse relacionamento mais difícil do que precisa
+ser.
+
+As empresas costumam buscar a contratação de desenvolvedores conhecidos para dar
+o pontapé inicial em um grupo de desenvolvimento. Esta pode ser, de fato, uma
+técnica eficaz. No entanto, ela também tende a ser cara e não contribui muito
+para expandir o grupo de desenvolvedores experientes de kernel. É possível
+capacitar desenvolvedores internos no desenvolvimento do kernel Linux, desde que
+se invista um pouco de tempo. Dedicar esse tempo pode dotar um empregador de um
+grupo de desenvolvedores que compreendem tanto o kernel quanto a empresa, e que
+também podem ajudar a treinar outros. A médio prazo, esta é frequentemente a
+abordagem mais proveitosa.
+
+Desenvolvedores individuais muitas vezes sentem-se, compreensivelmente, perdidos
+sobre por onde começar. Iniciar com um projeto grande pode ser intimidador;
+geralmente deseja-se "testar o terreno" com algo menor primeiro. Este é o ponto
+onde alguns desenvolvedores se lançam na criação de patches que corrigem erros
+ortográficos ou problemas menores de estilo de codificação (coding style).
+Infelizmente, tais patches criam um nível de ruído que distrai a comunidade de
+desenvolvimento como um todo; por isso, cada vez mais, eles são vistos com
+desdém. Novos desenvolvedores que desejam se apresentar à comunidade não
+receberão o tipo de recepção que esperam por meio desses métodos.
+
+Andrew Morton oferece este conselho para aspirantes a desenvolvedores de kernel
+
+::
+
+ O projeto nº 1 para todos os iniciantes no kernel certamente deve
+ ser "certificar-se de que o kernel funcione perfeitamente o tempo
+ todo em todas as máquinas em que você puder colocar as mãos".
+ Geralmente, a maneira de fazer isso é trabalhar com outros para
+ que as coisas sejam corrigidas (isso pode exigir persistência!),
+ mas tudo bem — isso faz parte do desenvolvimento do kernel.
+
+(https://lwn.net/Articles/283982/).
+
+Na ausência de problemas óbvios para corrigir, os desenvolvedores são
+aconselhados a olhar para as listas atuais de regressões e bugs abertos em
+geral. Nunca há escassez de problemas que precisem de correção; ao abordar essas
+questões, os desenvolvedores ganharão experiência com o processo enquanto, ao
+mesmo tempo, constroem respeito junto ao restante da comunidade de
+desenvolvimento.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] iommu/amd: add amd_iommu=relax_unity option for VFIO passthrough
From: Alex Williamson @ 2026-03-30 17:26 UTC (permalink / raw)
To: Christos Longros
Cc: Joerg Roedel, Suravee Suthikulpanit, Will Deacon, Robin Murphy,
Jonathan Corbet, Shuah Khan, iommu, linux-doc, linux-kernel, alex
In-Reply-To: <20260328213228.12084-1-chris.longros@gmail.com>
On Sat, 28 Mar 2026 22:32:28 +0100
Christos Longros <chris.longros@gmail.com> wrote:
> On some AMD motherboards (Gigabyte B650 Gaming X AX V2, X870E and
> others), VFIO passthrough of any PCI device fails with:
>
> "Firmware has requested this device have a 1:1 IOMMU mapping,
> rejecting configuring the device without a 1:1 mapping."
>
> These boards' IVRS tables include IVMD type 0x22 (range) entries
> spanning wide device ranges (e.g. devid 0x0000 to 0x0FFF, covering
> PCI buses 0-15). The entries exist for platform devices like IOAPIC
> and HPET, but they get applied to nearly every IOMMU group on the
> system. Since commit a48ce36e2786 ("iommu: Prevent RESV_DIRECT
> devices from blocking domains"), any device with IOMMU_RESV_DIRECT
> regions has require_direct=1 set, which prevents VFIO from claiming
> DMA ownership.
>
> No PCI device can be passed through on affected boards -- not just
> the platform devices that need the identity mappings, but also
> endpoint devices like network adapters and GPUs.
>
> Intel handles a similar firmware over-specification with
> device_rmrr_is_relaxable(), which marks certain RMRR entries as
> IOMMU_RESV_DIRECT_RELAXABLE so VFIO can claim them. AMD has no
> equivalent.
The difference is that we have known devices on the Intel platform
which have these RMRRs for largely historical reasons and we've
collectively decided it's safe to "relax" the direct mapping
requirement. We don't believe there's ongoing post-boot, side-channel
DMA happening in the background for these devices.
That's very different from providing a blind opt-in to ignore the
platform directive to provide direct mapping for any arbitrary device.
This is unsafe and difficult to debug.
I think the preferred route here is to contact your motherboard vendor
to both make them aware of the issue and determine whether they're
willing to address it. Thanks,
Alex
> Add an opt-in amd_iommu=relax_unity boot parameter. When set, IVRS
> unity map entries are reported as IOMMU_RESV_DIRECT_RELAXABLE instead
> of IOMMU_RESV_DIRECT. The IOMMU still creates the identity mappings,
> preserving DMA for platform devices, but VFIO can take ownership of
> individual devices for passthrough.
>
> Tested by passing through an RTL8852CE WiFi adapter to a FreeBSD
> QEMU/KVM guest via vfio-pci. Without the option, vfio_iommu_type1
> fails to set up the container. With amd_iommu=relax_unity,
> passthrough works.
>
> Signed-off-by: Christos Longros <chris.longros@gmail.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 6 ++++++
> drivers/iommu/amd/amd_iommu_types.h | 1 +
> drivers/iommu/amd/init.c | 6 ++++++
> drivers/iommu/amd/iommu.c | 7 ++++++-
> 4 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 03a550630..974506ad9 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -441,6 +441,12 @@ Kernel parameters
> force_enable - Force enable the IOMMU on platforms known
> to be buggy with IOMMU enabled. Use this
> option with care.
> + relax_unity - Mark IVRS unity map entries as relaxable,
> + allowing VFIO to claim devices that have
> + firmware-declared identity mappings. Required
> + on some AMD motherboards where global unity
> + maps prevent any device passthrough. Use this
> + option with care.
> pgtbl_v1 - Use v1 page table for DMA-API (Default).
> pgtbl_v2 - Use v2 page table for DMA-API.
> irtcachedis - Disable Interrupt Remapping Table (IRT) caching.
> diff --git a/drivers/iommu/amd/amd_iommu_types.h b/drivers/iommu/amd/amd_iommu_types.h
> index c685d3771..bc35d5016 100644
> --- a/drivers/iommu/amd/amd_iommu_types.h
> +++ b/drivers/iommu/amd/amd_iommu_types.h
> @@ -907,6 +907,7 @@ struct unity_map_entry {
> */
>
> extern bool amd_iommu_force_isolation;
> +extern bool amd_iommu_unity_relaxed;
>
> /* Max levels of glxval supported */
> extern int amd_iommu_max_glx_val;
> diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
> index f3fd7f39e..a89120700 100644
> --- a/drivers/iommu/amd/init.c
> +++ b/drivers/iommu/amd/init.c
> @@ -173,6 +173,9 @@ u64 amd_iommu_efr2;
> /* Host (v1) page table is not supported*/
> bool amd_iommu_hatdis;
>
> +/* Relax unity map entries for VFIO passthrough */
> +bool amd_iommu_unity_relaxed __read_mostly;
> +
> /* SNP is enabled on the system? */
> bool amd_iommu_snp_en;
> EXPORT_SYMBOL(amd_iommu_snp_en);
> @@ -3676,6 +3679,9 @@ static int __init parse_amd_iommu_options(char *str)
> amd_iommu_pgtable = PD_MODE_V2;
> } else if (strncmp(str, "irtcachedis", 11) == 0) {
> amd_iommu_irtcachedis = true;
> + } else if (strncmp(str, "relax_unity", 11) == 0) {
> + amd_iommu_unity_relaxed = true;
> + pr_warn("AMD IOMMU: unity map relaxation enabled\n");
> } else if (strncmp(str, "nohugepages", 11) == 0) {
> pr_info("Restricting V1 page-sizes to 4KiB");
> amd_iommu_pgsize_bitmap = AMD_IOMMU_PGSIZES_4K;
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 760d5f462..4606fa6a4 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -3070,7 +3070,12 @@ static void amd_iommu_get_resv_regions(struct device *dev,
> if (devid < entry->devid_start || devid > entry->devid_end)
> continue;
>
> - type = IOMMU_RESV_DIRECT;
> + /*
> + * When relax_unity is set, mark unity map entries as
> + * relaxable so VFIO can claim devices for passthrough.
> + */
> + type = amd_iommu_unity_relaxed ?
> + IOMMU_RESV_DIRECT_RELAXABLE : IOMMU_RESV_DIRECT;
> length = entry->address_end - entry->address_start;
> if (entry->prot & IOMMU_PROT_IR)
> prot |= IOMMU_READ;
^ permalink raw reply
* Re: [PATCH v5 2/4] iio: adc: ad4691: add initial driver for AD4691 family
From: Andy Shevchenko @ 2026-03-30 17:24 UTC (permalink / raw)
To: Sabau, Radu bogdan
Cc: Andy Shevchenko, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, David Lechner, Sa, Nuno, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB84143540CE505514E1CD84B4F752A@LV9PR03MB8414.namprd03.prod.outlook.com>
On Mon, Mar 30, 2026 at 5:20 PM Sabau, Radu bogdan
<Radu.Sabau@analog.com> wrote:
> > -----Original Message-----
> > From: Andy Shevchenko <andriy.shevchenko@intel.com>
> > Sent: Friday, March 27, 2026 1:36 PM
> > To: Sabau, Radu bogdan <Radu.Sabau@analog.com>
...
> > > +#include <linux/bitfield.h>
> > > +#include <linux/bitops.h>
> > > +#include <linux/cleanup.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/device.h>
> >
> > Hmm... Is it used? Or perhaps you need only
> > dev_printk.h
> > device/devres.h
> > ?
> I have checked this out and it seems device.h doesn't actually need
> to be included anyway since spi.h directly includes device.h, and since
> this is a SPI driver that's never going away, it's covered. Will drop it!
No, this is the wrong justification. IWYU principle is about exact
match between what is used and included in a file (module). spi.h is
not dev_*() provider and may not be considered for that.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] docs: generate a static 404 page
From: Rito Rhymes @ 2026-03-30 17:20 UTC (permalink / raw)
To: Jonathan Corbet, Rito Rhymes, skhan, mchehab; +Cc: linux-doc, linux-kernel
In-Reply-To: <87zf3pnwj7.fsf@trenco.lwn.net>
> Who are your users, what is your use case? Who do you think will do all
> of the setup work to create a server with a custom 404 page, but can't
> supply the page itself?
I see I framed this far too generically. My intent was narrower.
I mentioned nginx because I had looked at the live
docs.kernel.org deployment and saw that it uses nginx. The patch
is intended primarily for the canonical live documentation site.
My reasoning is that, on a public site of this size, users will
still sometimes arrive at missing URLs through stale indexed
links, old bookmarks, mistyped paths, truncated URLs, or references
from external sites. In that case, a documentation-native 404
gives them a way back into search, site navigation, and the
documentation root instead of leaving them on a generic orphaned
server error page.
The translated 404 handling also follows a live-site purpose.
When a user lands on a missing page under translated documentation,
it is more useful to keep the recovery path within that same language
section than to send them back to the English root.
Rito
^ permalink raw reply
* Re: [PATCH] docs: proc: remove description of prof_cpu_mask
From: Jonathan Corbet @ 2026-03-30 17:03 UTC (permalink / raw)
To: Zenghui Yu, linux-doc, linux-fsdevel, linux-kernel
Cc: skhan, Zenghui Yu (Huawei)
In-Reply-To: <20260311070940.94838-1-zenghui.yu@linux.dev>
Zenghui Yu <zenghui.yu@linux.dev> writes:
> From: "Zenghui Yu (Huawei)" <zenghui.yu@linux.dev>
>
> Commit 2e5449f4f21a ("profiling: Remove create_prof_cpu_mask().") said that
> no one would create /proc/irq/prof_cpu_mask since commit 1f44a225777e
> ("s390: convert interrupt handling to use generic hardirq", 2013). Remove
> the outdated description.
>
> While at it, fix another minor typo (s/DMS/DMA/).
>
> Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev>
> ---
> Documentation/filesystems/proc.rst | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: 答复: [外部邮件] Re: [PATCH] docs: kernel-parameters: fix architecture alignment for pt, nopt, and nobypass
From: Jonathan Corbet @ 2026-03-30 16:59 UTC (permalink / raw)
To: Li,Rongqing(ACG CCN), Randy Dunlap, Shuah Khan, Andrew Morton,
Borislav Petkov, Peter Zijlstra, Feng Tang, Pawan Gupta,
Dapeng Mi, Kees Cook, Marco Elver, Paul E . McKenney, Askar Safin,
Bjorn Helgaas, Sohil Mehta, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <16386e7715284b22b5f72e7106ed5619@baidu.com>
"Li,Rongqing(ACG CCN)" <lirongqing@baidu.com> writes:
> You are right , [X86] isn't needed , How about to remove the [X86], like below
>
> Documentation/kernel-parameters: fix architecture alignment for pt, nopt, and nobypass
>
> Commit ab0e7f20768a ("Documentation: Merge x86-specific boot options doc
> into kernel-parameters.txt") introduced a formatting regression where
> architecture tags were placed on separate lines with broken indentation.
> This caused the 'nopt' [X86] parameter to appear as if it belonged to
> the [PPC/POWERNV] section.
Please submit this as properly formatted standalone patch, so it can be
applied.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] docs/ja_JP: submitting-patches: Amend "Describe your changes"
From: Jonathan Corbet @ 2026-03-30 16:58 UTC (permalink / raw)
To: Akira Yokosawa, Akiyoshi Kurita
Cc: Shuah Khan, linux-doc, linux-kernel, Akira Yokosawa
In-Reply-To: <20260326114637.144601-1-akiyks@gmail.com>
Akira Yokosawa <akiyks@gmail.com> writes:
> To make the translation of "Describe your changes" (into
> "変更内容を記述する") easier to follow, do some rewording and
> rephrasing, as well as fixing a couple of mistranslations.
>
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> ---
> .../ja_JP/process/submitting-patches.rst | 107 +++++++++---------
> 1 file changed, 53 insertions(+), 54 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v2 0/2] Add a script to check for kernel-doc regressions
From: Jonathan Corbet @ 2026-03-30 16:54 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Mauro Carvalho Chehab
Cc: Mauro Carvalho Chehab, linux-doc, linux-kernel, Shuah Khan
In-Reply-To: <cover.1774551940.git.mchehab+huawei@kernel.org>
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> Hi Jon,
>
> I've using this script internally to check for regressions and
> changes with kernel-doc, specially those related to the new
> CTokenizer code:
>
> $ tools/docs/kdoc_diff --help
> usage: kdoc_diff [-h] [--full] [--regression] [--work-dir WORK_DIR] [--clean] commits [files ...]
>
I've applied these. Haven't had a chance to play with it much, but it
looks to be useful.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] Doc: process: Added two important books for Linux Kernel programming and development
From: Jonathan Corbet @ 2026-03-30 16:53 UTC (permalink / raw)
To: Bhaskar Chowdhury, skhan, workflows, linux-doc, linux-kernel
Cc: Bhaskar Chowdhury
In-Reply-To: <20260328074745.2309736-1-unixbhaskar@gmail.com>
Bhaskar Chowdhury <unixbhaskar@gmail.com> writes:
> These books are very well written and enhance the understanding of the process.
>
> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
> ---
> Documentation/process/howto.rst | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
> index 9438e03d6f50..c5164a27fc1a 100644
> --- a/Documentation/process/howto.rst
> +++ b/Documentation/process/howto.rst
> @@ -34,7 +34,8 @@ experience, the following books are good for, if anything, reference:
> - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
> - "Practical C Programming" by Steve Oualline [O'Reilly]
> - "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
> -
> + - "Linux System Programming" by Robert Love [O'Reilly]
> + - "Linux Kernel Development" By Robert Love [Pearson]
> The kernel is written using GNU C and the GNU toolchain. While it
Adding mention of those books might well be a good thing to do, but
you're adding them in the middle of a section that is talking about C
programming specifically. It doesn't make much sense to put them there.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v5 2/2] workflows, scripts: sort ver_linux and changes.rst
From: Jonathan Corbet @ 2026-03-30 16:38 UTC (permalink / raw)
To: Manuel Ebner, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Manuel Ebner
In-Reply-To: <20260325194811.78509-2-manuelebner@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> sort output of scripts/ver_linux alphabetically
> sort list in changes.rst alphabetically
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> Documentation/process/changes.rst | 52 ++++++++++++-------------
> scripts/ver_linux | 64 +++++++++++++++----------------
> 2 files changed, 58 insertions(+), 58 deletions(-)
Changelog is now:
docs: changes.rst and ver_linux: sort the lists
Sort the lists of tools in both scripts/ver_linux and
Documentation/process/changes.rst into alphabetical order, facilitating
comparison between the two.
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
[jc: rewrote changelog]
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
As an additional note...what would be Really Nice would be to have a
single list of tool dependencies that could be automatically used by
both files. An additional bonus would be a mode in script/ver_linux to
only report on tools that are missing or below the required version. A
guy can dream...:)
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v5 1/2] workflows, scripts: harmonize and cleanup
From: Jonathan Corbet @ 2026-03-30 16:36 UTC (permalink / raw)
To: Manuel Ebner, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Manuel Ebner
In-Reply-To: <20260325194616.78093-2-manuelebner@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> cleanup and harmonize output of scripts/ver_linux and table in changes.rst
>
> ver_linux:
> fix path to changes.rst
> Add missing tools in ver_linux
> bash, bc, bindgen, btrfs-progs, Clang, gdb, GNU awk, GNU tar,
> GRUB, GRUB2, gtags, iptables, kmod, mcelog, mkimage, openssl,
> pahole, Python, Rust, Sphinx, squashfs-tools
>
> changes.rst:
> add reference to ./scripts/ver_linux
> needn't -> do not need to
> add gdb version 7.2 as mentioned in:
> Documentation/process/debugging/gdb-kernel-debugging.rst
> scripts/gdb/vmlinux-gdb.py
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
Applied, but the changelog now reads:
docs: changes/ver_linux: fix entries and add several tools
Some of the entries in both Documentation/process/changes.rst and
script/ver_linux were obsolete; update them to reflect the current way of
getting version information.
Many were missing altogether; add the relevant information for:
bash, bc, bindgen, btrfs-progs, Clang, gdb, GNU awk, GNU tar,
GRUB, GRUB2, gtags, iptables, kmod, mcelog, mkimage, openssl,
pahole, Python, Rust, Sphinx, squashfs-tools
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
[jc: rewrote changelog]
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
jon
^ permalink raw reply
* Re: [PATCH v5 0/2] workflow, scripts: sort changes.rst and ver_linux
From: Jonathan Corbet @ 2026-03-30 16:32 UTC (permalink / raw)
To: Manuel Ebner, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Manuel Ebner
In-Reply-To: <20260325194326.77923-2-manuelebner@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> restructured the patch series into logical changes.
> fixed changelogs, but i'm not super content.
>
> [v4] -> [v5]:
> undo "remove (optional)" from [v4]
> merged patches with same concepts
> [PATCH v4 1/4], [PATCH v4 2/4] -> [PATCH v5 1/2]
> [PATCH v4 3/4], [PATCH v4 4/4] -> [PATCH v5 2/2]
> fix changelogs for the individual patches
OK, I have applied this series. For any future changes, though, I
really need you to work on your changelogs.
The 0/N cover letter should describe what the series as a whole does,
you didn't do that here.
For the individual patches, I have rewritten the changelogs; I'll reply
to each with what I've done.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] doc tools: better handle KBUILD_VERBOSE
From: Jacob Keller @ 2026-03-30 16:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Jonathan Corbet, Linux Doc Mailing List, linux-kernel,
Mauro Carvalho Chehab, Randy Dunlap, Shuah Khan
In-Reply-To: <20260328010955.19a90582@foz.lan>
On 3/27/2026 5:09 PM, Mauro Carvalho Chehab wrote:
> On Fri, 27 Mar 2026 11:35:39 -0700
> Jacob Keller <jacob.e.keller@intel.com> wrote:
>
>> On 3/26/2026 10:57 PM, Mauro Carvalho Chehab wrote:
>>> As reported by Jacob, there are troubles when KBUILD_VERBOSE is
>>> set at the environment.
>>>
>>> Fix it on both kernel-doc and sphinx-build-wrapper.
>>>
>>> Reported-by: Jacob Keller <jacob.e.keller@intel.com>
>>> Closes: https://lore.kernel.org/linux-doc/9367d899-53af-4d9c-9320-22fc4dbadca5@intel.com/
>>> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>>> ---
>>
>> I loaded this on my system and tested the build works as expected both
>> with V=0 and when I export KBUILD_VERBOSE manually.
>>
>> Thanks for fixing this quickly!
>>
>> Tested-by: Jacob Keller <jacob.e.keller@intel.com>
>>
>>> tools/docs/sphinx-build-wrapper | 7 ++++++-
>>> tools/lib/python/kdoc/kdoc_files.py | 7 ++++++-
>>> 2 files changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tools/docs/sphinx-build-wrapper b/tools/docs/sphinx-build-wrapper
>>> index 2c63d28f639d..1bb962202784 100755
>>> --- a/tools/docs/sphinx-build-wrapper
>>> +++ b/tools/docs/sphinx-build-wrapper
>>> @@ -238,7 +238,12 @@ class SphinxBuilder:
>>> self.latexopts = os.environ.get("LATEXOPTS", "")
>>>
>>> if not verbose:
>>> - verbose = bool(os.environ.get("KBUILD_VERBOSE", "") != "")
>>> + try:
>>> + verbose = bool(int(os.environ.get("KBUILD_VERBOSE", 0)))
>>> + except ValueError:
>>> + # Handles an eventual case where verbosity is not a number
>>> + # like KBUILD_VERBOSE=""
>>
>> Strictly speaking I think os.environ.get() will handle the case of an
>> empty KBUILD_VERBOSE by converting to the default value (in this case 0).
>
> It won't. See:
>
> $ FOO="" python3
> Python 3.14.3 (main, Feb 4 2026, 00:00:00) [GCC 15.2.1 20260123 (Red Hat 15.2.1-7)] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import os
> >>> os.environ.get("FOO", 0)
> ''
>
> $ FOO="0" python3
> Python 3.14.3 (main, Feb 4 2026, 00:00:00) [GCC 15.2.1 20260123 (Red Hat 15.2.1-7)] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import os
> >>> os.environ.get("FOO", 0)
> ...
> '0'
>
> $ unset FOO; python3
> Python 3.14.3 (main, Feb 4 2026, 00:00:00) [GCC 15.2.1 20260123 (Red Hat 15.2.1-7)] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import os
> >>> os.environ.get("FOO", 0)
> ...
> 0
>
> it will only get an integer 0 if the env var (at the above example, FOO)
> is not on env.
We always export KBUILD_VERBOSE regardless of its content, so we always
have os.environ.get("KBUILD_VERBOSE", 0) returning an empty string..
but the old bool() conversion would return false as expected. I.e. prior
to the change '' was handled as false as expected. but with int() then
we *do* get a ValueError now instead.
Ok.
>
>> The intent of the comment and code is pretty clear though, so I don't
>> know that deserves a re-roll.
>
> I opted to add a comment there because having two conversions,
> first to int then to bool is not that obvious ;-)
>
Yes. I was misunderstanding the intent of the comment, because I was
thinking that KBUILD_VERBOSE was unset, i.e. if you assign
KBUILD_VERBOSE= it would result in an unset value, but set and empty is
distinct from unset.
Prior to the int() conversion the bool() conversion did implicitly
handle the '' to false conversion, but now we'll get an exception first.
Thanks, and apologies for my confusion :D
> Thanks,
> Mauro
^ permalink raw reply
* Re: [PATCH] Documentation: Provide hints on how to debug Python GDB scripts
From: Jonathan Corbet @ 2026-03-30 16:15 UTC (permalink / raw)
To: Florian Fainelli, linux-kernel, akpm
Cc: tglx, radu, Florian Fainelli, Shuah Khan, Illia Ostapyshyn,
open list:DOCUMENTATION PROCESS, open list:DOCUMENTATION
In-Reply-To: <20260326233226.2248817-1-florian.fainelli@broadcom.com>
Florian Fainelli <florian.fainelli@broadcom.com> writes:
> By default GDB does not print a full stack of its integrated Python
> interpreter, thus making the debugging of GDB scripts more painful than
> it has to be.
>
> Suggested-by: Radu Rendec <radu@rendec.net>
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
> ---
> Documentation/process/debugging/gdb-kernel-debugging.rst | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/process/debugging/gdb-kernel-debugging.rst b/Documentation/process/debugging/gdb-kernel-debugging.rst
> index 9475c759c722..53e225760a4d 100644
> --- a/Documentation/process/debugging/gdb-kernel-debugging.rst
> +++ b/Documentation/process/debugging/gdb-kernel-debugging.rst
> @@ -173,3 +173,12 @@ this is just a snapshot of the initial version::
>
> Detailed help can be obtained via "help <command-name>" for commands and "help
> function <function-name>" for convenience functions.
> +
> +Debugging GDB scripts
> +---------------------
> +
> +GDB does not enable a full Python backtrace which can make debugging GDB
> +scripts more difficult than necessary. The following will allow for printing a
> +full backtrace of the python environment::
> +
> + (gdb) set python print-stack full
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v8 00/10] VMSCAPE optimization for BHI variant
From: Pawan Gupta @ 2026-03-30 16:11 UTC (permalink / raw)
To: Jon Kohler
Cc: x86@kernel.org, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, Asit Mallick, Tao Zhang, bpf@vger.kernel.org,
netdev@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <3B7BF368-4A3A-4853-A7CD-6F17E7982546@nutanix.com>
On Mon, Mar 30, 2026 at 03:16:32AM +0000, Jon Kohler wrote:
> Tested the v7 of this series with 6.18.y and one of our performance
> suites, where we had previously bisected a significant regression to
> the enablement of the VMSCAPE mitigation. This particular suite looks
> at synthetic performance using KVM virtualized Windows guests.
>
> Long story short, this suite tries to derive what end user experience
> would be in these virtual machines while performing a standardized set
> of synthetic tasks on real apps.
>
> VMSCAPE hits especially hard when enabling Windows HVCI, which drives
> a much higher VMExit count, all else equals.
>
> Tested on an Intel Xeon 6444Y (SPR)
>
> TLDR, we're really happy with the results. The following was with
> Intel MBEC *enabled*, so even with that speedup (and drastic reduction
> in VMExits), this optimization makes a significant difference.
>
> - CPU‑ready time drops ~70 % across all steady‑state and log‑on metrics
> with this series, indicating more efficient context switching even
> though overall hypervisor CPU rises ~14 % (steady) to ~12 % (max).
> Basically, we're getting more actual work done.
> - Read/write IOPS increase by ~18–37 % and 14–20 % respectively, while
> average IO latency remains largely unchanged or slightly lower in
> steady metrics.
> - Power consumption falls 5–11 % in every category
> - Login times improve by 4–6 % on average.
> - Application start‑up times are generally better (Word, Excel,
> PowerPoint, Outlook), especially Outlook max time drops 67 %, a clear
> win for end‑user experience.
These results are promising.
> Tested-By: Jon Kohler <jon@nutanix.com>
Thanks for testing, Jon.
^ 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