* [PATCH v5 1/2] firmware: stratix10-svc: add async HWMON read commands and register socfpga-hwmon device
From: tze.yee.ng @ 2026-07-15 6:28 UTC (permalink / raw)
To: Dinh Nguyen, linux-kernel, Guenter Roeck, Jonathan Corbet,
Shuah Khan, linux-hwmon, linux-doc
In-Reply-To: <cover.1784096224.git.tze.yee.ng@altera.com>
From: Tze Yee Ng <tze.yee.ng@altera.com>
Add asynchronous Stratix 10 service layer support for hardware monitor
temperature and voltage read commands in stratix10_svc_async_send() and
stratix10_svc_async_prepare_response().
Register a socfpga-hwmon platform device from the service layer driver
when hardware monitor support is enabled, similar to the RSU device.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
---
Changes in v5:
- No functional changes from v4
Changes in v3:
- No functional changes from v2
Changes in v2:
- Extend patch scope beyond async SMC support: register socfpga-hwmon
platform device from stratix10-svc when CONFIG_SENSORS_ALTERA_SOCFPGA_HWMON
is enabled
- Follow RSU-style registration; RSU probe error handling is unchanged
- Add err_unregister_clients to unregister hwmon and RSU on populate failure
- Unregister hwmon platform device in stratix10-svc remove()
---
drivers/firmware/stratix10-svc.c | 46 ++++++++++++++++++--
include/linux/firmware/intel/stratix10-smc.h | 38 ++++++++++++++++
2 files changed, 81 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/stratix10-svc.c b/drivers/firmware/stratix10-svc.c
index 5e20057ee344..bb6c02cd1f81 100644
--- a/drivers/firmware/stratix10-svc.c
+++ b/drivers/firmware/stratix10-svc.c
@@ -45,6 +45,7 @@
/* stratix10 service layer clients */
#define STRATIX10_RSU "stratix10-rsu"
+#define SOCFPGA_HWMON "socfpga-hwmon"
/* Maximum number of SDM client IDs. */
#define MAX_SDM_CLIENT_IDS 16
@@ -104,9 +105,11 @@ struct stratix10_svc_chan;
/**
* struct stratix10_svc - svc private data
* @stratix10_svc_rsu: pointer to stratix10 RSU device
+ * @stratix10_svc_hwmon: pointer to stratix10 HWMON device
*/
struct stratix10_svc {
struct platform_device *stratix10_svc_rsu;
+ struct platform_device *stratix10_svc_hwmon;
};
/**
@@ -1329,6 +1332,14 @@ int stratix10_svc_async_send(struct stratix10_svc_chan *chan, void *msg,
args.a0 = INTEL_SIP_SMC_ASYNC_RSU_NOTIFY;
args.a2 = p_msg->arg[0];
break;
+ case COMMAND_HWMON_READTEMP:
+ args.a0 = INTEL_SIP_SMC_ASYNC_HWMON_READTEMP;
+ args.a2 = p_msg->arg[0];
+ break;
+ case COMMAND_HWMON_READVOLT:
+ args.a0 = INTEL_SIP_SMC_ASYNC_HWMON_READVOLT;
+ args.a2 = p_msg->arg[0];
+ break;
default:
dev_err(ctrl->dev, "Invalid command ,%d\n", p_msg->command);
ret = -EINVAL;
@@ -1422,6 +1433,10 @@ static int stratix10_svc_async_prepare_response(struct stratix10_svc_chan *chan,
*/
data->kaddr1 = (void *)&handle->res;
break;
+ case COMMAND_HWMON_READTEMP:
+ case COMMAND_HWMON_READVOLT:
+ data->kaddr1 = (void *)&handle->res.a2;
+ break;
default:
dev_alert(ctrl->dev, "Invalid command\n ,%d", p_msg->command);
@@ -2016,16 +2031,38 @@ static int stratix10_svc_drv_probe(struct platform_device *pdev)
if (ret)
goto err_put_device;
+ if (IS_ENABLED(CONFIG_SENSORS_ALTERA_SOCFPGA_HWMON)) {
+ svc->stratix10_svc_hwmon =
+ platform_device_alloc(SOCFPGA_HWMON, 0);
+ if (!svc->stratix10_svc_hwmon) {
+ dev_err(dev, "failed to allocate %s device\n",
+ SOCFPGA_HWMON);
+ } else {
+ svc->stratix10_svc_hwmon->dev.parent = dev;
+
+ ret = platform_device_add(svc->stratix10_svc_hwmon);
+ if (ret) {
+ dev_err(dev, "failed to add %s device: %d\n",
+ SOCFPGA_HWMON, ret);
+ platform_device_put(svc->stratix10_svc_hwmon);
+ svc->stratix10_svc_hwmon = NULL;
+ }
+ }
+ }
+
ret = of_platform_default_populate(dev_of_node(dev), NULL, dev);
if (ret)
- goto err_unregister_rsu_dev;
+ goto err_unregister_clients;
pr_info("Intel Service Layer Driver Initialized\n");
return 0;
-err_unregister_rsu_dev:
- platform_device_unregister(svc->stratix10_svc_rsu);
+err_unregister_clients:
+ if (svc->stratix10_svc_hwmon)
+ platform_device_unregister(svc->stratix10_svc_hwmon);
+ if (svc->stratix10_svc_rsu)
+ platform_device_unregister(svc->stratix10_svc_rsu);
goto err_free_fifos;
err_put_device:
platform_device_put(svc->stratix10_svc_rsu);
@@ -2049,6 +2086,9 @@ static void stratix10_svc_drv_remove(struct platform_device *pdev)
struct stratix10_svc_controller *ctrl = platform_get_drvdata(pdev);
struct stratix10_svc *svc = ctrl->svc;
+ if (svc->stratix10_svc_hwmon)
+ platform_device_unregister(svc->stratix10_svc_hwmon);
+
platform_device_unregister(svc->stratix10_svc_rsu);
stratix10_svc_async_exit(ctrl);
diff --git a/include/linux/firmware/intel/stratix10-smc.h b/include/linux/firmware/intel/stratix10-smc.h
index 9224974fffc4..706176cc5c6a 100644
--- a/include/linux/firmware/intel/stratix10-smc.h
+++ b/include/linux/firmware/intel/stratix10-smc.h
@@ -701,6 +701,44 @@ INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_COMPLETED_WRITE)
#define INTEL_SIP_SMC_ASYNC_POLL \
INTEL_SIP_SMC_ASYNC_VAL(INTEL_SIP_SMC_ASYNC_FUNC_ID_POLL)
+/**
+ * Request INTEL_SIP_SMC_ASYNC_HWMON_READTEMP
+ * Async call to request temperature
+ *
+ * Call register usage:
+ * a0 INTEL_SIP_SMC_ASYNC_HWMON_READTEMP
+ * a1 transaction job id
+ * a2 Temperature Channel
+ * a3-a17 not used
+ *
+ * Return status
+ * a0 INTEL_SIP_SMC_STATUS_OK, INTEL_SIP_SMC_STATUS_REJECTED
+ * or INTEL_SIP_SMC_STATUS_BUSY
+ * a1-a17 not used
+ */
+#define INTEL_SIP_SMC_ASYNC_FUNC_ID_HWMON_READTEMP 0xE8
+#define INTEL_SIP_SMC_ASYNC_HWMON_READTEMP \
+ INTEL_SIP_SMC_ASYNC_VAL(INTEL_SIP_SMC_ASYNC_FUNC_ID_HWMON_READTEMP)
+
+/**
+ * Request INTEL_SIP_SMC_ASYNC_HWMON_READVOLT
+ * Async call to request voltage
+ *
+ * Call register usage:
+ * a0 INTEL_SIP_SMC_ASYNC_HWMON_READVOLT
+ * a1 transaction job id
+ * a2 Voltage Channel
+ * a3-a17 not used
+ *
+ * Return status
+ * a0 INTEL_SIP_SMC_STATUS_OK, INTEL_SIP_SMC_STATUS_REJECTED
+ * or INTEL_SIP_SMC_STATUS_BUSY
+ * a1-a17 not used
+ */
+#define INTEL_SIP_SMC_ASYNC_FUNC_ID_HWMON_READVOLT 0xE9
+#define INTEL_SIP_SMC_ASYNC_HWMON_READVOLT \
+ INTEL_SIP_SMC_ASYNC_VAL(INTEL_SIP_SMC_ASYNC_FUNC_ID_HWMON_READVOLT)
+
/**
* Request INTEL_SIP_SMC_ASYNC_RSU_GET_SPT
* Async call to get RSU SPT from SDM.
--
2.43.7
^ permalink raw reply related
* [PATCH v5 2/2] hwmon: add Altera SoC FPGA hardware monitoring driver
From: tze.yee.ng @ 2026-07-15 6:28 UTC (permalink / raw)
To: Dinh Nguyen, linux-kernel, Guenter Roeck, Jonathan Corbet,
Shuah Khan, linux-hwmon, linux-doc
In-Reply-To: <cover.1784096224.git.tze.yee.ng@altera.com>
From: Tze Yee Ng <tze.yee.ng@altera.com>
Add a hardware monitor driver for Altera SoC FPGA devices using the
Stratix 10 service layer. Sensor channels are selected based on the
service layer compatible string.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
---
Changes in v5:
- Poll async responses until HWMON_TIMEOUT (2 s) instead of a fixed
3-iteration retry loop (~3 ms), fixing premature timeouts observed
on silicon
- Add MODULE_ALIAS("platform:socfpga-hwmon")
Changes in v4:
- Register devm_add_action_or_reset() before
devm_hwmon_device_register_with_info(); drop manual channel cleanup
on hwmon registration failure
- Remove unreferenced async completion and pre-poll
wait_for_completion_io_timeout(); poll directly after async_send()
with the existing retry loop
Changes in v3:
- Fix 16-bit signed Q8.8 temperature conversion (cast through s16)
- Remove unused async callback; pass NULL to stratix10_svc_async_send()
- Keep wait_for_completion_io_timeout() before polling with comment
explaining the service layer never invokes the callback but firmware
needs time to complete the transaction (RSU pattern)
- Align async poll loop with RSU (retry on failure instead of aborting)
- Use wait_for_completion_timeout() for synchronous reads
- Handle -EINVAL and -EOPNOTSUPP when async client registration fails
- Defer SVC channel/async cleanup via devm_add_action_or_reset();
drop .remove()
Changes in v2:
- Drop altr,stratix10-hwmon OF compatible and DT channel parsing
- Select channels from hardcoded tables using parent SVC compatible
(intel,stratix10-svc or intel,agilex-svc)
- Rename driver from stratix10-hwmon to socfpga-hwmon
- Rename Kconfig symbol to CONFIG_SENSORS_ALTERA_SOCFPGA_HWMON
- Add Agilex voltage and temperature channel tables
- Convert SDM Q8.8 degrees Celsius to hwmon millidegrees
- Convert SDM Q16 volts to hwmon millivolts
- Use socfpga_hwmon as hwmon sysfs device name
- Add last_err for synchronous SVC read error propagation
- Update Documentation/hwmon and MAINTAINERS accordingly
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/socfpga-hwmon.rst | 34 ++
MAINTAINERS | 8 +
drivers/hwmon/Kconfig | 10 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/socfpga-hwmon.c | 579 ++++++++++++++++++++++++++
6 files changed, 633 insertions(+)
create mode 100644 Documentation/hwmon/socfpga-hwmon.rst
create mode 100644 drivers/hwmon/socfpga-hwmon.c
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 29130df44d12..3299417a24b8 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -254,6 +254,7 @@ Hardware Monitoring Kernel Drivers
sparx5-temp
spd5118
stpddc60
+ socfpga-hwmon
surface_fan
sy7636a-hwmon
tc654
diff --git a/Documentation/hwmon/socfpga-hwmon.rst b/Documentation/hwmon/socfpga-hwmon.rst
new file mode 100644
index 000000000000..e5da42556a62
--- /dev/null
+++ b/Documentation/hwmon/socfpga-hwmon.rst
@@ -0,0 +1,34 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver socfpga-hwmon
+=============================
+
+Supported chips:
+
+ * Altera Stratix 10 SoC FPGA
+ * Altera Agilex SoC FPGA
+
+Authors:
+ - Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
+ - Tze Yee Ng <tze.yee.ng@altera.com>
+
+Description
+-----------
+
+This driver supports hardware monitoring for Altera SoC
+FPGA devices through the Secure Device Manager and Stratix 10 service layer.
+
+The following sensor types are supported:
+
+ * temperature
+ * voltage
+
+Usage Notes
+-----------
+
+The stratix10-svc driver registers a socfpga-hwmon platform device when
+hardware monitor support is enabled. Sensor channels are selected in the
+driver based on the service layer compatible string:
+
+ * intel,stratix10-svc
+ * intel,agilex-svc
diff --git a/MAINTAINERS b/MAINTAINERS
index 15011f5752a9..2b0ee6d5c6ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -965,6 +965,14 @@ L: linux-gpio@vger.kernel.org
S: Maintained
F: drivers/gpio/gpio-altera.c
+ALTERA SoC FPGA HWMON DRIVER
+M: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
+M: Tze Yee Ng <tze.yee.ng@altera.com>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/socfpga-hwmon.rst
+F: drivers/hwmon/socfpga-hwmon.c
+
ALTERA TRIPLE SPEED ETHERNET DRIVER
M: Boon Khai Ng <boon.khai.ng@altera.com>
L: netdev@vger.kernel.org
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 5c2d3ff5fce8..54ce630c7de6 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2157,6 +2157,16 @@ config SENSORS_SMSC47M192
This driver can also be built as a module. If so, the module
will be called smsc47m192.
+config SENSORS_ALTERA_SOCFPGA_HWMON
+ tristate "Altera SoC FPGA hardware monitoring features"
+ depends on INTEL_STRATIX10_SERVICE
+ help
+ If you say yes here you get support for the temperature and
+ voltage sensors of Altera SoC FPGA devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called socfpga-hwmon.
+
config SENSORS_SMSC47B397
tristate "SMSC LPC47B397-NC"
depends on HAS_IOPORT
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 63effc0ab8d1..aeedee80e1f0 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -221,6 +221,7 @@ obj-$(CONFIG_SENSORS_SMPRO) += smpro-hwmon.o
obj-$(CONFIG_SENSORS_SMSC47B397)+= smsc47b397.o
obj-$(CONFIG_SENSORS_SMSC47M1) += smsc47m1.o
obj-$(CONFIG_SENSORS_SMSC47M192)+= smsc47m192.o
+obj-$(CONFIG_SENSORS_ALTERA_SOCFPGA_HWMON) += socfpga-hwmon.o
obj-$(CONFIG_SENSORS_SPARX5) += sparx5-temp.o
obj-$(CONFIG_SENSORS_SPD5118) += spd5118.o
obj-$(CONFIG_SENSORS_STTS751) += stts751.o
diff --git a/drivers/hwmon/socfpga-hwmon.c b/drivers/hwmon/socfpga-hwmon.c
new file mode 100644
index 000000000000..72418201b65d
--- /dev/null
+++ b/drivers/hwmon/socfpga-hwmon.c
@@ -0,0 +1,579 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Altera SoC FPGA hardware monitoring driver
+ *
+ * Copyright (c) 2026 Altera Corporation
+ *
+ * Authors:
+ * Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
+ * Tze Yee Ng <tze.yee.ng@altera.com>
+ */
+
+#include <linux/bitops.h>
+#include <linux/cleanup.h>
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/firmware/intel/stratix10-svc-client.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/jiffies.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#define HWMON_TIMEOUT msecs_to_jiffies(SVC_HWMON_REQUEST_TIMEOUT_MS)
+#define HWMON_RETRY_SLEEP_MS 1U
+#define HWMON_ASYNC_MSG_RETRY 3U
+#define SOCFPGA_HWMON_MAXSENSORS 16
+#define SOCFPGA_HWMON_CHANNEL_MASK GENMASK(15, 0)
+#define SOCFPGA_HWMON_PAGE_SHIFT 16
+#define SOCFPGA_HWMON_CHAN(page, channel) \
+ (((page) << SOCFPGA_HWMON_PAGE_SHIFT) | \
+ ((channel) & SOCFPGA_HWMON_CHANNEL_MASK))
+#define SOCFPGA_HWMON_ATTR_VISIBLE 0444
+/* Temperature from SDM is signed Q8.8 degrees Celsius (8 fractional bits). */
+#define SOCFPGA_HWMON_TEMP_FRAC_BITS 8
+#define SOCFPGA_HWMON_TEMP_FRAC_DIV BIT(SOCFPGA_HWMON_TEMP_FRAC_BITS)
+#define SOCFPGA_HWMON_TEMP_MDEG_SCALE 1000
+/* Voltage from SDM is unsigned Q16 volts (16 fractional bits). */
+#define SOCFPGA_HWMON_VOLT_FRAC_BITS 16
+#define SOCFPGA_HWMON_VOLT_FRAC_DIV BIT(SOCFPGA_HWMON_VOLT_FRAC_BITS)
+#define SOCFPGA_HWMON_VOLT_MV_SCALE 1000
+
+#define ETEMP_INACTIVE 0x80000000U
+#define ETEMP_TOO_OLD 0x80000001U
+#define ETEMP_NOT_PRESENT 0x80000002U
+#define ETEMP_TIMEOUT 0x80000003U
+#define ETEMP_CORRUPT 0x80000004U
+#define ETEMP_BUSY 0x80000005U
+#define ETEMP_NOT_INITIALIZED 0x800000FFU
+
+struct socfpga_hwmon_channel {
+ u32 reg;
+ const char *label;
+};
+
+struct socfpga_hwmon_board_data {
+ const struct socfpga_hwmon_channel *temp;
+ unsigned int num_temp;
+ const struct socfpga_hwmon_channel *volt;
+ unsigned int num_volt;
+};
+
+struct socfpga_hwmon_priv {
+ struct stratix10_svc_chan *chan;
+ struct stratix10_svc_client client;
+ struct completion completion;
+ struct mutex lock; /* protect SVC calls */
+ bool async;
+ int last_err; /* sync-mode SVC result; 0 on success */
+ u32 temperature;
+ u32 voltage;
+ int temperature_channels;
+ int voltage_channels;
+ const char *temp_chan_names[SOCFPGA_HWMON_MAXSENSORS];
+ const char *volt_chan_names[SOCFPGA_HWMON_MAXSENSORS];
+ u32 temp_chan[SOCFPGA_HWMON_MAXSENSORS];
+ u32 volt_chan[SOCFPGA_HWMON_MAXSENSORS];
+};
+
+static umode_t socfpga_hwmon_is_visible(const void *dev,
+ enum hwmon_sensor_types type,
+ u32 attr, int chan)
+{
+ const struct socfpga_hwmon_priv *priv = dev;
+
+ switch (type) {
+ case hwmon_temp:
+ if (chan < priv->temperature_channels)
+ return SOCFPGA_HWMON_ATTR_VISIBLE;
+ return 0;
+ case hwmon_in:
+ if (chan < priv->voltage_channels)
+ return SOCFPGA_HWMON_ATTR_VISIBLE;
+ return 0;
+ default:
+ return 0;
+ }
+}
+
+static void socfpga_hwmon_readtemp_cb(struct stratix10_svc_client *client,
+ struct stratix10_svc_cb_data *data)
+{
+ struct socfpga_hwmon_priv *priv = client->priv;
+
+ priv->last_err = -EIO;
+ if (data->status == BIT(SVC_STATUS_OK)) {
+ priv->last_err = 0;
+ priv->temperature = (u32)*(unsigned long *)data->kaddr1;
+ } else if (data->kaddr1) {
+ dev_err(client->dev, "%s failed with status 0x%x, value 0x%lx\n",
+ __func__, data->status,
+ *(unsigned long *)data->kaddr1);
+ } else {
+ dev_err(client->dev, "%s failed with status 0x%x\n",
+ __func__, data->status);
+ }
+
+ complete(&priv->completion);
+}
+
+static void socfpga_hwmon_readvolt_cb(struct stratix10_svc_client *client,
+ struct stratix10_svc_cb_data *data)
+{
+ struct socfpga_hwmon_priv *priv = client->priv;
+
+ priv->last_err = -EIO;
+ if (data->status == BIT(SVC_STATUS_OK)) {
+ priv->last_err = 0;
+ priv->voltage = (u32)*(unsigned long *)data->kaddr1;
+ } else if (data->kaddr1) {
+ dev_err(client->dev, "%s failed with status 0x%x, value 0x%lx\n",
+ __func__, data->status,
+ *(unsigned long *)data->kaddr1);
+ } else {
+ dev_err(client->dev, "%s failed with status 0x%x\n",
+ __func__, data->status);
+ }
+
+ complete(&priv->completion);
+}
+
+static int socfpga_hwmon_parse_temp(long *val, u32 temperature)
+{
+ switch (temperature) {
+ case ETEMP_INACTIVE:
+ case ETEMP_NOT_PRESENT:
+ case ETEMP_CORRUPT:
+ case ETEMP_NOT_INITIALIZED:
+ return -EOPNOTSUPP;
+ case ETEMP_TIMEOUT:
+ case ETEMP_BUSY:
+ case ETEMP_TOO_OLD:
+ return -EAGAIN;
+ default:
+ /* SDM returns a 16-bit signed Q8.8 value in the low 16 bits. */
+ *val = (long)(s16)(temperature & SOCFPGA_HWMON_CHANNEL_MASK) *
+ SOCFPGA_HWMON_TEMP_MDEG_SCALE / SOCFPGA_HWMON_TEMP_FRAC_DIV;
+ return 0;
+ }
+}
+
+static int socfpga_hwmon_encode_temp_arg(u32 reg, u64 *arg)
+{
+ u32 page = (reg >> SOCFPGA_HWMON_PAGE_SHIFT) & SOCFPGA_HWMON_CHANNEL_MASK;
+ u32 channel = reg & SOCFPGA_HWMON_CHANNEL_MASK;
+
+ if (channel >= SOCFPGA_HWMON_MAXSENSORS)
+ return -EINVAL;
+
+ *arg = (1ULL << channel) | ((u64)page << SOCFPGA_HWMON_PAGE_SHIFT);
+ return 0;
+}
+
+static int socfpga_hwmon_encode_volt_arg(u32 reg, u64 *arg)
+{
+ u32 channel = reg & SOCFPGA_HWMON_CHANNEL_MASK;
+
+ if (channel >= SOCFPGA_HWMON_MAXSENSORS)
+ return -EINVAL;
+
+ *arg = 1ULL << channel;
+ return 0;
+}
+
+static int socfpga_hwmon_async_read(struct device *dev,
+ enum hwmon_sensor_types type,
+ struct stratix10_svc_client_msg *msg)
+{
+ struct socfpga_hwmon_priv *priv = dev_get_drvdata(dev);
+ struct stratix10_svc_cb_data data = {};
+ unsigned long deadline = jiffies + HWMON_TIMEOUT;
+ void *handle = NULL;
+ int status, index, ret;
+
+ for (index = 0; index < HWMON_ASYNC_MSG_RETRY; index++) {
+ status = stratix10_svc_async_send(priv->chan, msg, &handle,
+ NULL, NULL);
+ if (status == 0)
+ break;
+ dev_warn(dev, "Failed to send async message: %d\n", status);
+ msleep(HWMON_RETRY_SLEEP_MS);
+ }
+
+ if (status && !handle) {
+ dev_err(dev, "Failed to send async message after %u retries: %d\n",
+ HWMON_ASYNC_MSG_RETRY, status);
+ return status;
+ }
+
+ ret = -ETIMEDOUT;
+ while (!time_after(jiffies, deadline)) {
+ status = stratix10_svc_async_poll(priv->chan, handle, &data);
+ if (status == -EAGAIN) {
+ dev_dbg(dev, "Async message is still in progress\n");
+ } else if (status < 0) {
+ dev_alert(dev, "Failed to poll async message: %d\n", status);
+ ret = -ETIMEDOUT;
+ } else if (status == 0) {
+ ret = 0;
+ break;
+ }
+ msleep(HWMON_RETRY_SLEEP_MS);
+ }
+
+ if (ret) {
+ dev_err(dev, "Failed to get async response\n");
+ goto done;
+ }
+
+ if (data.status) {
+ dev_err(dev, "%s returned 0x%x from SDM\n", __func__,
+ data.status);
+ ret = -EFAULT;
+ goto done;
+ }
+
+ if (type == hwmon_temp)
+ priv->temperature = (u32)*(unsigned long *)data.kaddr1;
+ else
+ priv->voltage = (u32)*(unsigned long *)data.kaddr1;
+
+ ret = 0;
+
+done:
+ stratix10_svc_async_done(priv->chan, handle);
+ return ret;
+}
+
+static int socfpga_hwmon_sync_read(struct device *dev,
+ enum hwmon_sensor_types type,
+ struct stratix10_svc_client_msg *msg)
+{
+ struct socfpga_hwmon_priv *priv = dev_get_drvdata(dev);
+ int ret;
+
+ reinit_completion(&priv->completion);
+
+ if (type == hwmon_temp)
+ priv->client.receive_cb = socfpga_hwmon_readtemp_cb;
+ else
+ priv->client.receive_cb = socfpga_hwmon_readvolt_cb;
+
+ ret = stratix10_svc_send(priv->chan, msg);
+ if (ret < 0)
+ goto status_done;
+
+ ret = wait_for_completion_timeout(&priv->completion, HWMON_TIMEOUT);
+ if (!ret) {
+ dev_err(priv->client.dev, "timeout waiting for SMC call\n");
+ ret = -ETIMEDOUT;
+ goto status_done;
+ }
+
+ ret = priv->last_err;
+
+status_done:
+ stratix10_svc_done(priv->chan);
+ return ret;
+}
+
+static int socfpga_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int chan, long *val)
+{
+ struct socfpga_hwmon_priv *priv = dev_get_drvdata(dev);
+ struct stratix10_svc_client_msg msg = {0};
+ int ret;
+
+ if (chan >= SOCFPGA_HWMON_MAXSENSORS)
+ return -EOPNOTSUPP;
+
+ switch (type) {
+ case hwmon_temp:
+ ret = socfpga_hwmon_encode_temp_arg(priv->temp_chan[chan],
+ &msg.arg[0]);
+ if (ret)
+ return ret;
+ msg.command = COMMAND_HWMON_READTEMP;
+ break;
+ case hwmon_in:
+ ret = socfpga_hwmon_encode_volt_arg(priv->volt_chan[chan],
+ &msg.arg[0]);
+ if (ret)
+ return ret;
+ msg.command = COMMAND_HWMON_READVOLT;
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ guard(mutex)(&priv->lock);
+ if (priv->async)
+ ret = socfpga_hwmon_async_read(dev, type, &msg);
+ else
+ ret = socfpga_hwmon_sync_read(dev, type, &msg);
+ if (ret)
+ return ret;
+
+ if (type == hwmon_temp)
+ ret = socfpga_hwmon_parse_temp(val, priv->temperature);
+ else
+ /* SDM returns Q16 volts; convert to hwmon millivolts. */
+ *val = (long)priv->voltage * SOCFPGA_HWMON_VOLT_MV_SCALE /
+ SOCFPGA_HWMON_VOLT_FRAC_DIV;
+ return ret;
+}
+
+static int socfpga_hwmon_read_string(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int chan, const char **str)
+{
+ struct socfpga_hwmon_priv *priv = dev_get_drvdata(dev);
+
+ switch (type) {
+ case hwmon_in:
+ *str = priv->volt_chan_names[chan];
+ return 0;
+ case hwmon_temp:
+ *str = priv->temp_chan_names[chan];
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct hwmon_ops socfpga_hwmon_ops = {
+ .is_visible = socfpga_hwmon_is_visible,
+ .read = socfpga_hwmon_read,
+ .read_string = socfpga_hwmon_read_string,
+};
+
+static const struct hwmon_channel_info *socfpga_hwmon_info[] = {
+ HWMON_CHANNEL_INFO(temp,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL),
+ HWMON_CHANNEL_INFO(in,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL),
+ NULL
+};
+
+static const struct hwmon_chip_info socfpga_hwmon_chip_info = {
+ .ops = &socfpga_hwmon_ops,
+ .info = socfpga_hwmon_info,
+};
+
+static const struct socfpga_hwmon_channel s10_hwmon_volt_channels[] = {
+ { SOCFPGA_HWMON_CHAN(0, 2), "0.8V VCC" },
+ { SOCFPGA_HWMON_CHAN(0, 3), "1.8V VCCIO_SDM" },
+ { SOCFPGA_HWMON_CHAN(0, 6), "0.9V VCCERAM" },
+};
+
+static const struct socfpga_hwmon_channel s10_hwmon_temp_channels[] = {
+ { SOCFPGA_HWMON_CHAN(0, 0), "Main Die SDM" },
+};
+
+static const struct socfpga_hwmon_board_data s10_hwmon_board = {
+ .temp = s10_hwmon_temp_channels,
+ .num_temp = ARRAY_SIZE(s10_hwmon_temp_channels),
+ .volt = s10_hwmon_volt_channels,
+ .num_volt = ARRAY_SIZE(s10_hwmon_volt_channels),
+};
+
+static const struct socfpga_hwmon_channel agilex_hwmon_volt_channels[] = {
+ { SOCFPGA_HWMON_CHAN(0, 2), "0.8V VCC" },
+ { SOCFPGA_HWMON_CHAN(0, 3), "1.8V VCCIO_SDM" },
+ { SOCFPGA_HWMON_CHAN(0, 4), "1.8V VCCPT" },
+ { SOCFPGA_HWMON_CHAN(0, 5), "1.2V VCCCRCORE" },
+ { SOCFPGA_HWMON_CHAN(0, 6), "0.9V VCCH" },
+ { SOCFPGA_HWMON_CHAN(0, 7), "0.8V VCCL" },
+};
+
+static const struct socfpga_hwmon_channel agilex_hwmon_temp_channels[] = {
+ { SOCFPGA_HWMON_CHAN(0, 0), "Main Die SDM" },
+ { SOCFPGA_HWMON_CHAN(1, 0), "Main Die corner bottom left max" },
+ { SOCFPGA_HWMON_CHAN(2, 0), "Main Die corner top left max" },
+ { SOCFPGA_HWMON_CHAN(3, 0), "Main Die corner bottom right max" },
+ { SOCFPGA_HWMON_CHAN(4, 0), "Main Die corner top right max" },
+};
+
+static const struct socfpga_hwmon_board_data agilex_hwmon_board = {
+ .temp = agilex_hwmon_temp_channels,
+ .num_temp = ARRAY_SIZE(agilex_hwmon_temp_channels),
+ .volt = agilex_hwmon_volt_channels,
+ .num_volt = ARRAY_SIZE(agilex_hwmon_volt_channels),
+};
+
+static const struct socfpga_hwmon_board_data *
+socfpga_hwmon_get_board(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+
+ if (!np)
+ return NULL;
+
+ if (of_device_is_compatible(np, "intel,stratix10-svc"))
+ return &s10_hwmon_board;
+ if (of_device_is_compatible(np, "intel,agilex-svc"))
+ return &agilex_hwmon_board;
+
+ return NULL;
+}
+
+static int socfpga_hwmon_init_channels(struct device *dev,
+ const struct socfpga_hwmon_board_data *board,
+ struct socfpga_hwmon_priv *priv)
+{
+ unsigned int i;
+
+ if (board->num_temp > SOCFPGA_HWMON_MAXSENSORS ||
+ board->num_volt > SOCFPGA_HWMON_MAXSENSORS)
+ return -EINVAL;
+
+ for (i = 0; i < board->num_temp; i++) {
+ priv->temp_chan_names[i] = board->temp[i].label;
+ priv->temp_chan[i] = board->temp[i].reg;
+ }
+ priv->temperature_channels = board->num_temp;
+
+ for (i = 0; i < board->num_volt; i++) {
+ priv->volt_chan_names[i] = board->volt[i].label;
+ priv->volt_chan[i] = board->volt[i].reg;
+ }
+ priv->voltage_channels = board->num_volt;
+
+ return 0;
+}
+
+static void socfpga_hwmon_release_svc(void *data)
+{
+ struct socfpga_hwmon_priv *priv = data;
+
+ if (priv->async)
+ stratix10_svc_remove_async_client(priv->chan);
+ stratix10_svc_free_channel(priv->chan);
+}
+
+static int socfpga_hwmon_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device *parent = dev->parent;
+ const struct socfpga_hwmon_board_data *board;
+ struct socfpga_hwmon_priv *priv;
+ struct device *hwmon_dev;
+ int ret;
+
+ if (!parent || !parent->of_node) {
+ dev_err(dev, "missing parent device node\n");
+ return -ENODEV;
+ }
+
+ board = socfpga_hwmon_get_board(parent);
+ if (!board) {
+ dev_err(dev, "unsupported service layer compatible\n");
+ return -ENODEV;
+ }
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->client.dev = dev;
+ priv->client.priv = priv;
+ init_completion(&priv->completion);
+ mutex_init(&priv->lock);
+
+ ret = socfpga_hwmon_init_channels(dev, board, priv);
+ if (ret)
+ return ret;
+
+ priv->chan = stratix10_svc_request_channel_byname(&priv->client,
+ SVC_CLIENT_HWMON);
+ if (IS_ERR(priv->chan)) {
+ ret = PTR_ERR(priv->chan);
+ if (ret == -EPROBE_DEFER)
+ dev_dbg(dev, "service channel %s not ready, deferring probe\n",
+ SVC_CLIENT_HWMON);
+ else
+ dev_err(dev, "couldn't get service channel %s: %d\n",
+ SVC_CLIENT_HWMON, ret);
+ return ret;
+ }
+
+ ret = stratix10_svc_add_async_client(priv->chan, false);
+ switch (ret) {
+ case 0:
+ priv->async = true;
+ break;
+ case -EINVAL:
+ case -EOPNOTSUPP:
+ /*
+ * stratix10_svc_add_async_client() returns -EINVAL when the
+ * async controller is not initialized; fall back to sync mode.
+ */
+ dev_dbg(dev, "async operations not supported, using sync mode\n");
+ priv->async = false;
+ break;
+ default:
+ dev_err(dev, "failed to add async client: %d\n", ret);
+ stratix10_svc_free_channel(priv->chan);
+ return ret;
+ }
+
+ ret = devm_add_action_or_reset(dev, socfpga_hwmon_release_svc, priv);
+ if (ret)
+ return ret;
+
+ hwmon_dev = devm_hwmon_device_register_with_info(dev, "socfpga_hwmon",
+ priv,
+ &socfpga_hwmon_chip_info,
+ NULL);
+ if (IS_ERR(hwmon_dev))
+ return PTR_ERR(hwmon_dev);
+
+ platform_set_drvdata(pdev, priv);
+ return 0;
+}
+
+static struct platform_driver socfpga_hwmon_driver = {
+ .probe = socfpga_hwmon_probe,
+ .driver = {
+ .name = "socfpga-hwmon",
+ },
+};
+module_platform_driver(socfpga_hwmon_driver);
+
+MODULE_AUTHOR("Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>");
+MODULE_AUTHOR("Tze Yee Ng <tze.yee.ng@altera.com>");
+MODULE_DESCRIPTION("Altera SoC FPGA hardware monitoring driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:socfpga-hwmon");
--
2.43.7
^ permalink raw reply related
* Re: [PATCH 2/8] mm/khugepaged: extract young page check into collapse_is_young() helper
From: Baolin Wang @ 2026-07-15 6:29 UTC (permalink / raw)
To: Nico Pache
Cc: linux-doc, linux-kernel, linux-mm, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Zi Yan, Liam R. Howlett,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jonathan Corbet, Shuah Khan
In-Reply-To: <CAA1CXcD7Mta7y3j20TXjWWfMmmYRSjt5Vq=fbbS=aYWcepppug@mail.gmail.com>
On 7/15/26 2:04 PM, Nico Pache wrote:
> On Fri, Jul 10, 2026 at 1:41 AM Baolin Wang
> <baolin.wang@linux.alibaba.com> wrote:
>>
>>
>>
>> On 7/6/26 11:44 PM, Nico Pache wrote:
>>> The change deduplicates the "is this PTE young enough to count as
>>> referenced" condition that was repeated in both
>>> __collapse_huge_page_isolate() and collapse_scan_pmd(), extracting it into
>>> a single inline helper function.
>>>
>>> Also move the comment and use it as the function header. While we are at
>>> it, updated the comment to clarify that a young pte is a recently accessed
>>> one.
>>>
>>> Signed-off-by: Nico Pache <npache@redhat.com>
>>> ---
>>> mm/khugepaged.c | 35 +++++++++++++++++++----------------
>>> 1 file changed, 19 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>> index b3985b854e77..48b008a3c891 100644
>>> --- a/mm/khugepaged.c
>>> +++ b/mm/khugepaged.c
>>> @@ -675,6 +675,23 @@ static void release_pte_pages(pte_t *pte, pte_t *_pte,
>>> }
>>> }
>>>
>>> +/*
>>> + * collapse_is_young() - Check for enough young pte to justify collapsing
>>> + *
>>> + * If collapse was initiated by khugepaged, check that the page has been
>>> + * recently accessed (young pte) to justify collapsing the page.
>>> + *
>>> + * Return: true if the page has been recently accessed (young pte).
>>> + */
>>> +static inline bool collapse_is_young(struct collapse_control *cc, pte_t pteval,
>>> + struct folio *folio, struct vm_area_struct *vma, unsigned long addr)
>>> +{
>>> + return cc->is_khugepaged &&
>>> + (pte_young(pteval) || folio_test_young(folio) ||
>>> + folio_test_referenced(folio) ||
>>> + mmu_notifier_test_young(vma->vm_mm, addr));
>>> +}
>>
>> collapse_is_young() is somewhat confusing to me. Would using
>> 'referenced' be a more appropriate name? collapse_folio_is_referenced()?
>
> I went with collapse_is_referenced since it also checks the PTE not
> just the folio.
>
>>
>> Also, it feels odd to put 'cc->is_khugepaged' in a helper whose purpose
>> is to check whether a folio has been accessed. I think this helper
>> should be more self-contained and focused solely on checking whether the
>> folio was accessed.
>
> While I don't wholeheartedly disagree, the point is to clean up the
> code and abstract some of this logic away from the parent functions. I
> prefer doing the khugepaged check inside this new helper because the
> code is much cleaner.
Sure. I don't have a strong opinion, let's see what others perfer :)
^ permalink raw reply
* Re: [PATCH v7 07/17] iio: test: add kunit tests for channel prefix naming generation
From: Andy Shevchenko @ 2026-07-15 6:32 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Rodrigo Alencar, Jonathan Cameron, Rodrigo Alencar via B4 Relay,
linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Jonathan Corbet, Shuah Khan, Kees Cook,
Gustavo A. R. Silva
In-Reply-To: <20260714180812.000070c4@oss.qualcomm.com>
On Tue, Jul 14, 2026 at 06:08:12PM -0700, Jonathan Cameron wrote:
> On Mon, 13 Jul 2026 10:52:56 +0100
> Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> > On 12/07/26 02:09, Jonathan Cameron wrote:
> > > On Tue, 07 Jul 2026 15:04:28 +0100
> > > Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
...
> > > > Because __iio_chan_prefix_emit() is static, the test translation unit
> > > > is pulled into industrialio-core.c.
KUnit also has static/non-static automation via a macro (defined in the
kunit/visibility.h) and I see that's used in the below example.
> > > Isn't there some magic route cases like this that makes it non static
> > > only when self tests are enabled?
> > > Claude tells me to look at include/kunit/visibility.h
> >
> > There is, Although I think that using
> >
> > #if IS_ENABLED(CONFIG_IIO_CHANNEL_PREFIX_KUNIT_TEST)
> > #include "test/iio-test-channel-prefix.c"
> > #endif
> >
> > was more straight forward, less invasive and easier to change than..
Maybe, but thanks to this thread, I fixed other modules that use their own
approach to use the standard KUnit infra for this (as below).
> > /* In "drivers/iio/industrialio-core.c" */
> >
> > #include <kunit/visibility.h>
> > ...
> > VISIBLE_IF_KUNIT ssize_t __iio_chan_prefix_emit(...)
> > {
> > ...
> > }
> > EXPORT_SYMBOL_IF_KUNIT(__iio_chan_prefix_emit);
> >
> > /* In "iio_core.h" */
> >
> > #if IS_ENABLED(CONFIG_KUNIT)
> > ssize_t __iio_chan_prefix_emit(...);
> > #endif
> >
> > /* In "drivers/iio/test/iio-test-channel-prefix.c" */
> >
> > #include <kunit/visibility.h>
> > #include <iio_core.h>
> > ...
> > MODULE_IMPORT_NS("EXPORTED_FOR_KUNIT_TESTING");
> > ...
> > // Use __iio_chan_prefix_emit() in tests
>
> I'd rather this wasn't built into the core module. So prefer you jump
> though those hoops.
Hmm... The above (while being verbose) is the standard way of how we export
symbols for KUnit tests. Do you have a better alternative that everyone can
use? (Not only IIO subsystem.)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: (subset) [PATCH v25 0/7] firmware: imx: driver for NXP secure-enclave
From: Frieder Schrempf @ 2026-07-15 7:32 UTC (permalink / raw)
To: Frank Li
Cc: Frank Li, Jonathan Corbet, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Pankaj Gupta, linux-doc, linux-kernel, devicetree,
imx, linux-arm-kernel
In-Reply-To: <alZJzKHs8w0UAw_z@SMW015318>
On 14.07.26 16:38, Frank Li wrote:
> On Tue, Jul 14, 2026 at 09:27:06AM +0200, Frieder Schrempf wrote:
>> On 05.05.26 17:53, Frank Li wrote:
>>>
>>> On Thu, 22 Jan 2026 17:19:12 +0530, Pankaj Gupta wrote:
>>>> The NXP's i.MX EdgeLock Enclave, a HW IP creating an embedded secure
>>>> enclave within the SoC boundary to enable features like
>>>> - HSM
>>>> - SHE
>>>> - V2X
>>>>
>>>> Communicates via message unit with linux kernel. This driver is
>>>> enables communication ensuring well defined message sequence protocol
>>>> between Application Core and enclave's firmware.
>>>>
>>>> [...]
>>>
>>> Applied, thanks!
>>>
>>> [1/7] Documentation/firmware: add imx/se to other_interfaces
>>> commit: 3b4531c6e0f4c8874f0266853a410438eda1fc24
>>> [2/7] dt-bindings: arm: fsl: add imx-se-fw binding doc
>>> commit: 4d7bcf0869686d7d7fbf16244453b987e5ca6d14
>>> [3/7] firmware: imx: add driver for NXP EdgeLock Enclave
>>> commit: 338529a73c2bf2c277013b745cfe6f19b84b70af
>>> [4/7] firmware: imx: device context dedicated to priv
>>> commit: 2d733ed67f608ee85abb854157011f88d7f280a8
>>> [5/7] firmware: drivers: imx: adds miscdev
>>> commit: 4de71839142b5f43846e3593f4eb236e1d733885
>> What happened to these patches?
>>
>> They were part of linux-next for quite some time (up to next-20260630)
>> and then they disappeared (missing in next-20260701).
>>
>> I didn't find any hint where or why they were dropped.
>
> Sashiko and linux-next build found some issues, which need be fixed before
> send pull request.
>
> Pankaj is working on the new version.
>
Ok, thanks for the update. It would be helpful if you could reply to the
thread if already applied patches need to be dropped so others who base
their work on these patches know about it.
@Pankaj: Do you have a rough timeline for this? I would really like to
get my work with the NVMEM driver [1] done.
Thanks!
[1]
https://patchwork.kernel.org/project/linux-arm-kernel/cover/20260713-upstreaming-next-20260609-imx-ocotp-ele-v2-0-b8266d93514b@kontron.de/
^ permalink raw reply
* Re: What's cooking in zh_CN (Jul 2026, #02)
From: Weijie Yuan @ 2026-07-15 8:22 UTC (permalink / raw)
To: Dongliang Mu, Alex Shi, Doehyun Baek
Cc: linux-doc, Alex Shi, Yanteng Si, Ben Guo, Gary Guo, Yan Zhu,
Jiandong Qiu, chengyaqiang, Haoyang Liu
In-Reply-To: <ecae49cd-4861-44e0-b873-6ca98e205855@hust.edu.cn>
On Wed, Jul 15, 2026 at 09:55:35AM +0800, Dongliang Mu wrote:
> On 7/15/26 1:56 AM, Doehyun Baek wrote:
> > > Btw, for example, my patch (Weijie Yuan · docs/zh_CN: add docs-next
> > checkout workaround) is actually directly discarded after we reached
> > a consensus during our communication (with Dongliang). But it's
> > obvious that we didn't say it explicitly. So your website can't
> > recognize it automaticly right now. Perhaps we can think about how
> > to deal with this situation later.
> >
> > Yeah, this is a downside of an automated approach: it can miss details
> > that are only implicit in the discussion. I see roughly three ways to
> > handle such cases:
> >
> > 1. Allow authors to mark a patch explicitly by replying with a
> > recognized phrase, such as `Patch-status: withdrawn`.
>
> This is better.
>
> Or similar to syzbot, we can provide an option in the webpage to directly
> mark patchset as invalid.
Do we need to consider the bidirectional synchronization of the state?
If the marking is only done on the dashboard and not synchronized with
the lore list, it seems likely to cause confusion. Imagine having to
switch between two pages repeatedly to check the status of a series.
On Wed, Jul 15, 2026 at 09:46:26AM +0800, Dongliang Mu wrote:
> On 7/15/26 1:42 AM, Weijie Yuan wrote:
> > On Tue, Jul 14, 2026 at 07:05:28PM +0200, Doehyun Baek wrote:
> > > I "cooked" up a small website this evening that attempts to automate them:
> > >
> > > https://doehyunbaek.github.io/cook-linux-zhcn/
> > >
> > > Every hour, a GitHub Actions workflow scans recent `docs/zh_CN` patches on
> > > the linux-doc mailing list, groups rerolls, and compares their subjects
> > > with Alex´s `docs-next` tree to determine whether they have been applied.
> > > Pending series with no update for more than 30 days are classified as
> > > "Cold."
> > >
> > > This is still an experimental prototype, and its heuristics may have bugs,
> > > particularly when threads or patch subjects change. The source is available
> > > here:
> > >
> > > https://github.com/doehyunbaek/cook-linux-zhcn
> > >
> > > Issues, suggestions, and pull requests are welcome!
> > Btw, for example, my patch (Weijie Yuan · docs/zh_CN: add docs-next
> > checkout workaround) is actually directly discarded after we reached
> > a consensus during our communication (with Dongliang). But it's
> > obvious that we didn't say it explicitly. So your website can't
> > recognize it automaticly right now. Perhaps we can think about how
> > to deal with this situation later.
>
> We can set a terminal instruction like "Applied, thanks" to automate
> the end of patches.
LKML provides a bot [1] that can automatically send a email when a git pull
is done by Linus Torvalds. But it is for mainline only now. :-(
I originally planned to integrate it with our status board and avoid
having Alex manually reply "Applied" each time.
Then I realize b4 provides a feature [2] that can automatically seed
feedback to the original series when a series is merged or so. It may
save maintainer's time and trigger some automation, but I don't see our
maintainers using b4, so there's a learning cost. At the same time,
automation may bring complexity, which is a trade-off.
[1] https://korg.docs.kernel.org/prtracker.html
[2] https://b4.docs.kernel.org/en/latest/maintainer/ty.html
On Wed, Jul 15, 2026 at 09:52:20AM +0800, Alex Shi wrote:
> On 2026/7/15 01:05, Doehyun Baek wrote:
> > Hi Weijie,
> >
> > Thanks for putting together the "What´s cooking" reports!
> > I "cooked" up a small website this evening that attempts to automate them:
> >
> > https://doehyunbaek.github.io/cook-linux-zhcn/
> > <https://doehyunbaek.github.io/cook-linux-zhcn/>
>
> Nice work!
> Maybe add a build testing result for each of patches, like 'make htmldocs
> -s', although build should pass before send out patches, but it often be
> omitted.
Sounds like we are going to build our own CI platform. ;-)
^ permalink raw reply
* [PATCH v2 0/4] hwmon: Add Kandou KB9002 PCIe retimer driver
From: Andy Chung via B4 Relay @ 2026-07-15 9:08 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Chung,
Guenter Roeck, Jonathan Corbet, Shuah Khan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, Andy Chung
The Kandou KB9002 is an 8-lane PCIe 5.0 retimer with an integrated
microcontroller that exposes an SMBus 3.0 target (with mandatory PEC)
on its sideband interface. Its firmware aggregates per-lane die
temperatures and publishes the maximum through a register window.
This series adds a hwmon driver for it. The driver reports the
aggregated maximum die temperature as temp1_input, and exposes the
running firmware version and boot status under debugfs.
The series is organised as:
1/4 add the "kandou" vendor prefix
2/4 device tree binding for the retimer
3/4 the driver, Kconfig/Makefile and MAINTAINERS entry
4/4 hwmon documentation
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
---
Changes in v2:
- Drop the unconditional I2C_FUNC_I2C requirement at probe; require raw
I2C only in the host-interface switch path, so the driver loads on
SMBus-only adapters when the chip is already strapped to SMBus.
- kb9002_read_revid(): return immediately on a hard I2C read error
instead of retrying the FIFO drain, avoiding needless bus traffic when
the device is absent.
- Link to v1: https://lore.kernel.org/all/20260714-kb9002-upstream-v1-0-8fd2f0b135d8@amd.com
---
Andy Chung (4):
dt-bindings: Add vendor prefix for Kandou
dt-bindings: hwmon: Add Kandou KB9002
hwmon: (kb9002) Add driver for Kandou KB9002 retimer
hwmon: (kb9002) Add documentation
.../devicetree/bindings/hwmon/kandou,kb9002.yaml | 45 ++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/kb9002.rst | 65 +++
MAINTAINERS | 8 +
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/kb9002.c | 479 +++++++++++++++++++++
8 files changed, 612 insertions(+)
---
base-commit: ca078d004cf58137bcf8cb24a8b271397431ba58
change-id: 20260713-kb9002-upstream-06c686e37833
Best regards,
--
Andy Chung <Andy.Chung@amd.com>
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: hwmon: Add Kandou KB9002
From: Andy Chung via B4 Relay @ 2026-07-15 9:08 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Chung,
Guenter Roeck, Jonathan Corbet, Shuah Khan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, Andy Chung
In-Reply-To: <20260715-kb9002-upstream-v2-0-2fd390383da5@amd.com>
From: Andy Chung <Andy.Chung@amd.com>
Add device tree bindings for the Kandou KB9002 PCIe 5.0 retimer, an
SMBus target that exposes an aggregated die temperature.
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
---
.../devicetree/bindings/hwmon/kandou,kb9002.yaml | 45 ++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/kandou,kb9002.yaml b/Documentation/devicetree/bindings/hwmon/kandou,kb9002.yaml
new file mode 100644
index 000000000000..67859e9d63c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/kandou,kb9002.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/kandou,kb9002.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Kandou KB9002 PCIe 5.0 retimer
+
+maintainers:
+ - Andy Chung <andy.chung@amd.com>
+
+description: |
+ The Kandou KB9002 is an 8-lane PCIe 5.0 retimer that exposes a
+ firmware-controlled SMBus 3.0 target on its sideband interface.
+ The host can query the aggregated maximum die temperature and the
+ running firmware version through that target.
+
+ The 7-bit SMBus address is selected by three SMB_ADDR straps and
+ ranges from 0x20 to 0x27.
+
+properties:
+ compatible:
+ const: kandou,kb9002
+
+ reg:
+ minimum: 0x20
+ maximum: 0x27
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ retimer@20 {
+ compatible = "kandou,kb9002";
+ reg = <0x20>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/4] dt-bindings: Add vendor prefix for Kandou
From: Andy Chung via B4 Relay @ 2026-07-15 9:08 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Chung,
Guenter Roeck, Jonathan Corbet, Shuah Khan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, Andy Chung
In-Reply-To: <20260715-kb9002-upstream-v2-0-2fd390383da5@amd.com>
From: Andy Chung <Andy.Chung@amd.com>
Kandou Bus, S.A. is the vendor of the KB9002 PCIe retimer.
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 396044f368e7..727871970d97 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -879,6 +879,8 @@ patternProperties:
description: JuTouch Technology Co., Ltd.
"^kam,.*":
description: Kamstrup A/S
+ "^kandou,.*":
+ description: Kandou Bus, S.A.
"^karo,.*":
description: Ka-Ro electronics GmbH
"^keithkoep,.*":
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/4] hwmon: (kb9002) Add driver for Kandou KB9002 retimer
From: Andy Chung via B4 Relay @ 2026-07-15 9:08 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Chung,
Guenter Roeck, Jonathan Corbet, Shuah Khan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, Andy Chung
In-Reply-To: <20260715-kb9002-upstream-v2-0-2fd390383da5@amd.com>
From: Andy Chung <Andy.Chung@amd.com>
The Kandou KB9002 is an 8-lane PCIe 5.0 retimer that exposes an SMBus
target with mandatory PEC. Add a hwmon driver reporting the firmware
aggregated maximum die temperature as temp1_input, with the firmware
version and boot status under debugfs.
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
---
MAINTAINERS | 8 +
drivers/hwmon/Kconfig | 11 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/kb9002.c | 479 +++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 499 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9b4b1575bdbd..1d80ac2660e2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13931,6 +13931,14 @@ S: Maintained
F: Documentation/hwmon/k8temp.rst
F: drivers/hwmon/k8temp.c
+KANDOU KB9002 PCIE RETIMER HWMON DRIVER
+M: Andy Chung <andy.chung@amd.com>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/hwmon/kandou,kb9002.yaml
+F: Documentation/hwmon/kb9002.rst
+F: drivers/hwmon/kb9002.c
+
KASAN
M: Andrey Ryabinin <ryabinin.a.a@gmail.com>
R: Alexander Potapenko <glider@google.com>
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08c29685126a..300329773e87 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -335,6 +335,17 @@ config SENSORS_K10TEMP
This driver can also be built as a module. If so, the module
will be called k10temp.
+config SENSORS_KB9002
+ tristate "Kandou KB9002 PCIe retimer"
+ depends on I2C
+ help
+ If you say yes here you get support for the integrated
+ temperature sensor and firmware version readout on Kandou
+ KB9002 PCIe 5.0 retimers, accessed over SMBus.
+
+ This driver can also be built as a module. If so, the module
+ will be called kb9002.
+
config SENSORS_KBATT
tristate "KEBA battery controller support"
depends on KEBA_CP500
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 63809eeec2f4..0cad7e21634c 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -113,6 +113,7 @@ obj-$(CONFIG_SENSORS_IT87) += it87.o
obj-$(CONFIG_SENSORS_JC42) += jc42.o
obj-$(CONFIG_SENSORS_K8TEMP) += k8temp.o
obj-$(CONFIG_SENSORS_K10TEMP) += k10temp.o
+obj-$(CONFIG_SENSORS_KB9002) += kb9002.o
obj-$(CONFIG_SENSORS_KBATT) += kbatt.o
obj-$(CONFIG_SENSORS_KFAN) += kfan.o
obj-$(CONFIG_SENSORS_LAN966X) += lan966x-hwmon.o
diff --git a/drivers/hwmon/kb9002.c b/drivers/hwmon/kb9002.c
new file mode 100644
index 000000000000..94c7d95b3fff
--- /dev/null
+++ b/drivers/hwmon/kb9002.c
@@ -0,0 +1,479 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Kandou KB9002 PCIe 5.0 retimer hwmon driver.
+ *
+ * The retimer exposes a system management bus (SMBus 3.0 with PEC)
+ * target for firmware-managed status registers. This driver assumes
+ * the chip is strapped to SMBus mode and exports the aggregated
+ * maximum die temperature as hwmon temp1_input (millidegrees Celsius)
+ * plus the firmware version and boot status under debugfs.
+ *
+ * Datasheet: Kandou KB9002 PCIe retimer (KA-015171-PD).
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/debugfs.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/i2c.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/seq_file.h>
+#include <linux/types.h>
+#include <linux/unaligned.h>
+
+#define KB9002_DEV_NAME "kb9002"
+
+/*
+ * SMBus read command codes. Each read is a two-phase PEC-protected
+ * transaction: prime writes the target address, data reads it back with
+ * the register contents. FW reads use a 16-bit address, HW reads 32-bit.
+ */
+#define KB9002_CC_FW_READ_PRIME 0x82
+#define KB9002_CC_FW_READ_DATA 0x81
+#define KB9002_CC_HW_READ_PRIME 0x8a
+#define KB9002_CC_HW_READ_DATA 0x89
+
+/* Firmware register offsets (16-bit). */
+#define KB9002_FW_REG_VID 0x0004
+#define KB9002_FW_REG_FW_VERSION 0x0500
+#define KB9002_FW_REG_TEMP_MAXIMUM 0x0550
+
+#define KB9002_VID_MASK GENMASK(31, 16)
+#define KB9002_VID_KANDOU 0x1e6f
+
+/* Firmware boot status: 0xe8 in the top byte means init completed OK. */
+#define KB9002_HW_REG_FW_BOOT_STATUS 0xe0090008
+#define KB9002_FW_BOOT_STATUS_OK_MSB 0xe8
+
+/*
+ * Hardware registers reached over raw I2C (32-bit addressing). The
+ * host-interface bit selects SMBus (set) vs raw-I2C target; parts
+ * strapped to raw I2C need it set before SMBus access works.
+ */
+#define KB9002_HW_REG_REVID 0x00480004
+#define KB9002_HW_REG_HOST_IF 0x00480008
+#define KB9002_HOST_IF_SMBUS BIT(1)
+
+#define KB9002_REVID_MASK GENMASK(7, 0)
+#define KB9002_REVID_B0 0x10
+#define KB9002_REVID_B1 0x11
+
+/* Retries to drain a stray leading 0xff from the raw-I2C FIFO. */
+#define KB9002_REVID_READ_RETRIES 16
+
+/* Temperature: 32-bit Q16.16 absolute Kelvin. */
+#define KB9002_TEMP_FRAC_BITS 16
+#define KB9002_ABS_ZERO_MILLI_C (-273150)
+
+/* Firmware takes up to ~2s to respond after a host-interface change. */
+#define KB9002_FW_READY_POLL_US (25 * USEC_PER_MSEC)
+#define KB9002_FW_READY_TIMEOUT_US (2 * USEC_PER_SEC)
+
+struct kb9002_data {
+ struct i2c_client *client;
+ struct mutex lock; /* serialises register accesses */
+};
+
+/* Raw-I2C read: write the 32-bit BE address, then read 4 BE data bytes. */
+static int kb9002_i2c_read(struct i2c_client *client, u32 reg, u32 *val)
+{
+ u8 addr[4];
+ u8 rbuf[4];
+ struct i2c_msg msgs[2] = {
+ {
+ .addr = client->addr,
+ .flags = 0,
+ .len = sizeof(addr),
+ .buf = addr,
+ },
+ {
+ .addr = client->addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(rbuf),
+ .buf = rbuf,
+ },
+ };
+ int ret;
+
+ put_unaligned_be32(reg, addr);
+
+ ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
+ if (ret < 0)
+ return ret;
+ if (ret != ARRAY_SIZE(msgs))
+ return -EIO;
+
+ *val = get_unaligned_be32(rbuf);
+ return 0;
+}
+
+/* Raw-I2C write: 4 BE address bytes followed by 4 BE data bytes. */
+static int kb9002_i2c_write(struct i2c_client *client, u32 reg, u32 val)
+{
+ u8 buf[8];
+ struct i2c_msg msg = {
+ .addr = client->addr,
+ .flags = 0,
+ .len = sizeof(buf),
+ .buf = buf,
+ };
+ int ret;
+
+ put_unaligned_be32(reg, &buf[0]);
+ put_unaligned_be32(val, &buf[4]);
+
+ ret = i2c_transfer(client->adapter, &msg, 1);
+ if (ret < 0)
+ return ret;
+ if (ret != 1)
+ return -EIO;
+
+ return 0;
+}
+
+/*
+ * Read the silicon revision ID. A fresh FIFO may start with a stray
+ * 0xff that shifts the result, so drain one byte between retries until
+ * the top byte is no longer 0xff.
+ */
+static int kb9002_read_revid(struct i2c_client *client, u32 *revid)
+{
+ u8 dummy;
+ int ret;
+ int i;
+
+ for (i = 0; i < KB9002_REVID_READ_RETRIES; i++) {
+ ret = kb9002_i2c_read(client, KB9002_HW_REG_REVID, revid);
+ if (ret)
+ return ret;
+ if ((*revid >> 24) != 0xff)
+ return 0;
+ /* Drain one byte from the chip to re-align the I2C FIFO. */
+ i2c_master_recv(client, &dummy, 1);
+ }
+
+ return -EIO;
+}
+
+/*
+ * Read a 32-bit firmware register over SMBus: block-write the 16-bit LE
+ * address, then block-read the echoed address plus 4 LE data bytes.
+ */
+static int kb9002_fw_read(struct kb9002_data *data, u16 reg, u32 *val)
+{
+ struct i2c_client *client = data->client;
+ u8 addr[2];
+ u8 rbuf[I2C_SMBUS_BLOCK_MAX];
+ int ret;
+
+ put_unaligned_le16(reg, addr);
+
+ mutex_lock(&data->lock);
+
+ ret = i2c_smbus_write_block_data(client, KB9002_CC_FW_READ_PRIME,
+ sizeof(addr), addr);
+ if (ret < 0)
+ goto out;
+
+ ret = i2c_smbus_read_block_data(client, KB9002_CC_FW_READ_DATA, rbuf);
+ if (ret < 0)
+ goto out;
+ if (ret < (int)(sizeof(addr) + sizeof(*val))) {
+ ret = -EIO;
+ goto out;
+ }
+
+ *val = get_unaligned_le32(&rbuf[sizeof(addr)]);
+ ret = 0;
+out:
+ mutex_unlock(&data->lock);
+ return ret;
+}
+
+/* Like kb9002_fw_read but for a hardware register (32-bit LE address). */
+static int kb9002_smbus_hw_read(struct kb9002_data *data, u32 reg, u32 *val)
+{
+ struct i2c_client *client = data->client;
+ u8 addr[4];
+ u8 rbuf[I2C_SMBUS_BLOCK_MAX];
+ int ret;
+
+ put_unaligned_le32(reg, addr);
+
+ mutex_lock(&data->lock);
+
+ ret = i2c_smbus_write_block_data(client, KB9002_CC_HW_READ_PRIME,
+ sizeof(addr), addr);
+ if (ret < 0)
+ goto out;
+
+ ret = i2c_smbus_read_block_data(client, KB9002_CC_HW_READ_DATA, rbuf);
+ if (ret < 0)
+ goto out;
+ if (ret < (int)(sizeof(addr) + sizeof(*val))) {
+ ret = -EIO;
+ goto out;
+ }
+
+ *val = get_unaligned_le32(&rbuf[sizeof(addr)]);
+ ret = 0;
+out:
+ mutex_unlock(&data->lock);
+ return ret;
+}
+
+/*
+ * Switch the host interface from raw-I2C to SMBus and wait for firmware
+ * to come back up. Called only when SMBus access failed in probe, i.e.
+ * the chip is strapped to raw-I2C mode. Confirms the revision, sets the
+ * SMBus-mode bit, then polls until firmware responds again.
+ */
+static int kb9002_enable_smbus_target(struct kb9002_data *data)
+{
+ struct i2c_client *client = data->client;
+ u32 revid;
+ u32 val;
+ int op_ret;
+ int ret;
+
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
+ return dev_err_probe(&client->dev, -ENODEV,
+ "raw I2C required to switch to SMBus mode\n");
+
+ ret = kb9002_read_revid(client, &revid);
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "revision ID read failed\n");
+
+ switch (FIELD_GET(KB9002_REVID_MASK, revid)) {
+ case KB9002_REVID_B0:
+ case KB9002_REVID_B1:
+ break;
+ default:
+ return dev_err_probe(&client->dev, -ENODEV,
+ "unsupported revision ID 0x%08x\n", revid);
+ }
+
+ ret = kb9002_i2c_read(client, KB9002_HW_REG_HOST_IF, &val);
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "host interface read failed\n");
+
+ val |= KB9002_HOST_IF_SMBUS;
+
+ ret = kb9002_i2c_write(client, KB9002_HW_REG_HOST_IF, val);
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "host interface write failed\n");
+
+ /* Wait until firmware re-initialisation completes. */
+ ret = read_poll_timeout(kb9002_fw_read, op_ret, op_ret == 0,
+ KB9002_FW_READY_POLL_US,
+ KB9002_FW_READY_TIMEOUT_US, true,
+ data, KB9002_FW_REG_VID, &val);
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "firmware not responding over SMBus\n");
+
+ return 0;
+}
+
+/* Convert Q16.16 absolute Kelvin to millidegrees Celsius. */
+static long kb9002_temp_to_milli_c(u32 raw)
+{
+ s64 milli_k = ((s64)raw * 1000) >> KB9002_TEMP_FRAC_BITS;
+
+ return (long)milli_k + KB9002_ABS_ZERO_MILLI_C;
+}
+
+static int kb9002_read_temp(struct kb9002_data *data, long *val)
+{
+ u32 raw;
+ int ret;
+
+ ret = kb9002_fw_read(data, KB9002_FW_REG_TEMP_MAXIMUM, &raw);
+ if (ret)
+ return ret;
+
+ *val = kb9002_temp_to_milli_c(raw);
+ return 0;
+}
+
+static umode_t kb9002_is_visible(const void *drvdata,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ if (type == hwmon_temp &&
+ (attr == hwmon_temp_input || attr == hwmon_temp_label))
+ return 0444;
+ return 0;
+}
+
+static int kb9002_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *val)
+{
+ struct kb9002_data *data = dev_get_drvdata(dev);
+
+ if (type == hwmon_temp && attr == hwmon_temp_input)
+ return kb9002_read_temp(data, val);
+
+ return -EOPNOTSUPP;
+}
+
+static int kb9002_read_string(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, const char **str)
+{
+ if (type == hwmon_temp && attr == hwmon_temp_label) {
+ *str = KB9002_DEV_NAME;
+ return 0;
+ }
+ return -EOPNOTSUPP;
+}
+
+static const struct hwmon_ops kb9002_hwmon_ops = {
+ .is_visible = kb9002_is_visible,
+ .read = kb9002_read,
+ .read_string = kb9002_read_string,
+};
+
+static const struct hwmon_channel_info * const kb9002_hwmon_info[] = {
+ HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_LABEL),
+ NULL,
+};
+
+static const struct hwmon_chip_info kb9002_chip_info = {
+ .ops = &kb9002_hwmon_ops,
+ .info = kb9002_hwmon_info,
+};
+
+static int kb9002_fw_version_show(struct seq_file *s, void *unused)
+{
+ struct kb9002_data *data = s->private;
+ u32 ver;
+ int ret;
+
+ ret = kb9002_fw_read(data, KB9002_FW_REG_FW_VERSION, &ver);
+ if (ret)
+ return ret;
+
+ seq_printf(s, "%u.%02u.%02u.%u\n",
+ (ver >> 24) & 0xff, (ver >> 16) & 0xff,
+ (ver >> 8) & 0xff, (ver >> 0) & 0xff);
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(kb9002_fw_version);
+
+static int kb9002_fw_load_status_show(struct seq_file *s, void *unused)
+{
+ struct kb9002_data *data = s->private;
+ u32 status;
+ int ret;
+
+ ret = kb9002_smbus_hw_read(data, KB9002_HW_REG_FW_BOOT_STATUS, &status);
+ if (ret)
+ return ret;
+
+ seq_printf(s, "%s\n",
+ (status >> 24) == KB9002_FW_BOOT_STATUS_OK_MSB ?
+ "normal" : "abnormal");
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(kb9002_fw_load_status);
+
+static void kb9002_debugfs_init(struct kb9002_data *data)
+{
+ struct dentry *dir = data->client->debugfs;
+
+ debugfs_create_file("fw_ver", 0444, dir, data,
+ &kb9002_fw_version_fops);
+ debugfs_create_file("fw_load_status", 0444, dir, data,
+ &kb9002_fw_load_status_fops);
+}
+
+static int kb9002_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct kb9002_data *data;
+ struct device *hwmon_dev;
+ u32 vid;
+ int ret;
+
+ if (!i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_BLOCK_DATA |
+ I2C_FUNC_SMBUS_PEC))
+ return -ENODEV;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->client = client;
+ mutex_init(&data->lock);
+
+ /* All firmware register accesses are PEC-protected. */
+ client->flags |= I2C_CLIENT_PEC;
+
+ i2c_set_clientdata(client, data);
+
+ /*
+ * Try SMBus first. If the chip is strapped to raw-I2C mode it
+ * will not respond to SMBus framing, so fall back to switching
+ * the host interface over raw I2C and retry.
+ */
+ ret = kb9002_fw_read(data, KB9002_FW_REG_VID, &vid);
+ if (ret) {
+ dev_dbg(dev, "SMBus probe failed (%d), trying raw-I2C host-interface switch\n",
+ ret);
+ ret = kb9002_enable_smbus_target(data);
+ if (ret)
+ return ret;
+ ret = kb9002_fw_read(data, KB9002_FW_REG_VID, &vid);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "VID read failed after host-interface switch\n");
+ }
+ if (FIELD_GET(KB9002_VID_MASK, vid) != KB9002_VID_KANDOU)
+ return dev_err_probe(dev, -ENODEV,
+ "unexpected VID 0x%08x\n", vid);
+
+ hwmon_dev = devm_hwmon_device_register_with_info(dev, KB9002_DEV_NAME,
+ data,
+ &kb9002_chip_info,
+ NULL);
+ if (IS_ERR(hwmon_dev))
+ return PTR_ERR(hwmon_dev);
+
+ kb9002_debugfs_init(data);
+ return 0;
+}
+
+static const struct i2c_device_id kb9002_id[] = {
+ { KB9002_DEV_NAME },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, kb9002_id);
+
+static const struct of_device_id kb9002_of_match[] = {
+ { .compatible = "kandou,kb9002" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, kb9002_of_match);
+
+static struct i2c_driver kb9002_driver = {
+ .driver = {
+ .name = KB9002_DEV_NAME,
+ .of_match_table = kb9002_of_match,
+ },
+ .probe = kb9002_probe,
+ .id_table = kb9002_id,
+};
+module_i2c_driver(kb9002_driver);
+
+MODULE_AUTHOR("Andy Chung <andy.chung@amd.com>");
+MODULE_DESCRIPTION("Kandou KB9002 PCIe retimer hwmon driver");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/4] hwmon: (kb9002) Add documentation
From: Andy Chung via B4 Relay @ 2026-07-15 9:08 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andy Chung,
Guenter Roeck, Jonathan Corbet, Shuah Khan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, Andy Chung
In-Reply-To: <20260715-kb9002-upstream-v2-0-2fd390383da5@amd.com>
From: Andy Chung <Andy.Chung@amd.com>
Document the sysfs and debugfs interfaces of the Kandou KB9002 hwmon
driver.
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/kb9002.rst | 65 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+)
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 226789376217..9dc796d087dc 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -112,6 +112,7 @@ Hardware Monitoring Kernel Drivers
jc42
k10temp
k8temp
+ kb9002
kbatt
kfan
lan966x
diff --git a/Documentation/hwmon/kb9002.rst b/Documentation/hwmon/kb9002.rst
new file mode 100644
index 000000000000..e6d8d9c78923
--- /dev/null
+++ b/Documentation/hwmon/kb9002.rst
@@ -0,0 +1,65 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver kb9002
+====================
+
+Supported chips:
+
+ * Kandou KB9002
+
+ Prefix: 'kb9002'
+
+ Addresses scanned: -
+
+ Datasheet: KA-015171-PD (available from Kandou under NDA)
+
+Author: Andy Chung <andy.chung@amd.com>
+
+Description
+-----------
+
+The Kandou KB9002 is an 8-lane PCIe 5.0 retimer with an integrated
+microcontroller. It exposes an SMBus 3.0 target (with mandatory PEC)
+on its sideband interface. The internal firmware aggregates per-lane
+die temperatures and publishes the maximum value through a 16-bit
+addressed register window.
+
+This driver reports that aggregated maximum as the only hwmon
+temperature channel. The running firmware version and the firmware
+boot status are exposed under debugfs.
+
+sysfs interface
+---------------
+
+================== ===============================================
+temp1_input Aggregated maximum die temperature across all
+ active lanes (millidegrees Celsius).
+temp1_label Always "kb9002".
+================== ===============================================
+
+debugfs interface
+-----------------
+
+Files live in the per-client debugfs directory created by the I2C
+core: ``/sys/kernel/debug/i2c/i2c-<bus>/<bus>-<addr>/``.
+
+================== ===============================================
+fw_ver Running firmware version in
+ "major.minor.patch.suffix" format. Read-only.
+fw_load_status Firmware boot status: "normal" once firmware has
+ finished initialising, "abnormal" otherwise.
+ Read-only.
+================== ===============================================
+
+Notes
+-----
+
+The driver requires ``I2C_FUNC_SMBUS_BLOCK_DATA``,
+``I2C_FUNC_SMBUS_PEC`` and ``I2C_FUNC_I2C`` from the host adapter. The
+last is needed only during probe for the host-interface mode switch;
+runtime accesses use SMBus block transactions exclusively.
+
+The retimer's SMBus address is configurable on three strap pins and
+ranges from 0x20 to 0x27. The address is selected through device tree
+(or i2c board info) the same way as any other I2C device; the driver
+does not auto-detect.
--
2.34.1
^ permalink raw reply related
* [PATCH v2] scripts/kernel-doc: Suggest possible names for excess descriptions
From: Ryszard Knop @ 2026-07-15 11:17 UTC (permalink / raw)
To: Randy Dunlap, linux-doc
Cc: Shuicheng Lin, Jani Nikula, linux-kernel, intel-xe
In-Reply-To: <20260714111208.323108-1-ryszard.knop@intel.com>
Since check_sections() now warns if a documentation tag member name is
the same as defined in the struct, we can suggest names the checker
knows, so that it's more obvious how to deal with the warning.
v2 (rdunlap):
- Strip whitespace from warnings, nicer when the hint is empty
Signed-off-by: Ryszard Knop <ryszard.knop@intel.com>
---
tools/lib/python/kdoc/kdoc_parser.py | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/tools/lib/python/kdoc/kdoc_parser.py b/tools/lib/python/kdoc/kdoc_parser.py
index 2dedda215c22..a22c3e3182f0 100644
--- a/tools/lib/python/kdoc/kdoc_parser.py
+++ b/tools/lib/python/kdoc/kdoc_parser.py
@@ -558,6 +558,13 @@ class KernelDoc:
self.push_parameter(ln, decl_type, param, dtype,
arg, declaration_name)
+ def get_suggestions_hint(self, decl_name, possible_names):
+ suggestions = set(name for name in possible_names if decl_name in name)
+ if not suggestions:
+ return ""
+
+ return f"(did you mean one of: '{"', '".join(suggestions)}')"
+
def check_sections(self, ln, decl_name, decl_type):
"""
Check for errors inside sections, emitting warnings if not found
@@ -566,12 +573,13 @@ class KernelDoc:
for section in self.entry.sections:
if section not in self.entry.parameterlist and \
not known_sections.search(section):
+ hint = self.get_suggestions_hint(section, self.entry.parameterlist)
if decl_type == 'function':
dname = f"{decl_type} parameter"
else:
dname = f"{decl_type} member"
self.emit_msg(ln,
- f"Excess {dname} '{section}' description in '{decl_name}'")
+ f"Excess {dname} '{section}' description in '{decl_name}' {hint}".strip())
#
# Check that documented parameter names (from doc comments, including
@@ -591,12 +599,13 @@ class KernelDoc:
if param_name in self.entry.parameterlist:
continue
+ hint = self.get_suggestions_hint(param_name, self.entry.parameterlist)
if decl_type == 'function':
dname = f"{decl_type} parameter"
else:
dname = f"{decl_type} member"
self.emit_msg(ln,
- f"Excess {dname} '{param_name}' description in '{decl_name}'")
+ f"Excess {dname} '{param_name}' description in '{decl_name}' {hint}".strip())
def check_return_section(self, ln, declaration_name, return_type):
"""
--
2.55.0
^ permalink raw reply related
* Re: [PATCH] scripts/kernel-doc: Suggest possible names for excess descriptions
From: Knop, Ryszard @ 2026-07-15 11:18 UTC (permalink / raw)
To: linux-doc@vger.kernel.org, rdunlap@infradead.org
Cc: intel-xe@lists.freedesktop.org, Lin, Shuicheng,
linux-kernel@vger.kernel.org, jani.nikula@linux.intel.com
In-Reply-To: <12d74842-c826-46ec-922a-68f5e4042cb6@infradead.org>
On Tue, 2026-07-14 at 14:44 -0700, Randy Dunlap wrote:
> Hi,
>
>
> On 7/14/26 4:12 AM, Ryszard Knop wrote:
> > Since check_sections() now warns if a documentation tag member name is
> > the same as defined in the struct, we can suggest names the checker
> > knows, so that it's more obvious how to deal with the warning.
> >
>
> Seems to work for me.
>
> > Signed-off-by: Ryszard Knop <ryszard.knop@intel.com>
> > ---
> > tools/lib/python/kdoc/kdoc_parser.py | 13 +++++++++++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/lib/python/kdoc/kdoc_parser.py b/tools/lib/python/kdoc/kdoc_parser.py
> > index 2dedda215c22..3f88095eab06 100644
> > --- a/tools/lib/python/kdoc/kdoc_parser.py
> > +++ b/tools/lib/python/kdoc/kdoc_parser.py
> > @@ -558,6 +558,13 @@ class KernelDoc:
> > self.push_parameter(ln, decl_type, param, dtype,
> > arg, declaration_name)
> >
> > + def get_suggestions_hint(self, decl_name, possible_names):
> > + suggestions = set(name for name in possible_names if decl_name in name)
> > + if not suggestions:
> > + return ""
> > +
> > + return f"(did you mean one of: '{"', '".join(suggestions)}')"
> > +
> > def check_sections(self, ln, decl_name, decl_type):
> > """
> > Check for errors inside sections, emitting warnings if not found
> > @@ -566,12 +573,13 @@ class KernelDoc:
> > for section in self.entry.sections:
> > if section not in self.entry.parameterlist and \
> > not known_sections.search(section):
> > + hint = self.get_suggestions_hint(section, self.entry.parameterlist)
> > if decl_type == 'function':
> > dname = f"{decl_type} parameter"
> > else:
> > dname = f"{decl_type} member"
> > self.emit_msg(ln,
> > - f"Excess {dname} '{section}' description in '{decl_name}'")
> > + f"Excess {dname} '{section}' description in '{decl_name}' {hint}")
>
> When 'hint' is empty, this statement and/or the similar one below
> adds a trailing space to each of those lines.
> Can you prevent that? (yeah, it's just a nit)
Sure thing, submitted a v2.
>
> >
> > #
> > # Check that documented parameter names (from doc comments, including
> > @@ -591,12 +599,13 @@ class KernelDoc:
> > if param_name in self.entry.parameterlist:
> > continue
> >
> > + hint = self.get_suggestions_hint(param_name, self.entry.parameterlist)
> > if decl_type == 'function':
> > dname = f"{decl_type} parameter"
> > else:
> > dname = f"{decl_type} member"
> > self.emit_msg(ln,
> > - f"Excess {dname} '{param_name}' description in '{decl_name}'")
> > + f"Excess {dname} '{param_name}' description in '{decl_name}' {hint}")
> >
> > def check_return_section(self, ln, declaration_name, return_type):
> > """
>
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
> Tested-by: Randy Dunlap <rdunlap@infradead.org>
>
> thanks.
A.
Thanks, Ryszard
^ permalink raw reply
* Re: [PATCH 2/2] mm/zswap: Support batch writeback in shrink_memcg()
From: Hao Jia @ 2026-07-15 11:28 UTC (permalink / raw)
To: Yosry Ahmed
Cc: akpm, tj, hannes, shakeel.butt, mhocko, mkoutny, nphamcs,
chengming.zhou, muchun.song, roman.gushchin, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <CAO9r8zNiT63LUHx8X5i_aboX1UWuGkcFf+p9ch-pekURUuDdXg@mail.gmail.com>
On 2026/7/15 00:52, Yosry Ahmed wrote:
> On Tue, Jul 14, 2026 at 1:15 AM Hao Jia <jiahao.kernel@gmail.com> wrote:
>>
>> From: Hao Jia <jiahao1@lixiang.com>
>>
>> Currently, shrink_memcg() writes back at most one entry per-node during
>> its traversal. This makes shrink_worker() inefficient, as it must
>> repeatedly re-enter shrink_memcg() to make any substantial progress.
>
> Please also mention the case about writeback being slow to keep up
> with refaults in some cases, leading to zswap store failures and pages
> skipping zswap and going directly to disk, which is an LRU inversion.
>
Will be done in the next version.
>>
>> To address this, extend shrink_memcg() and rewrite its LRU iteration logic
>> to support batch writeback. Introduce the nr_to_scan parameter to bound how
>> many pages are scanned per call. This enables batch writeback in the
>> shrink_worker() path, while maintaining a low scan budget in the
>> zswap_store() path.
>>
>> Additionally, to prepare for future proactive writeback, update the return
>> value semantics of shrink_memcg(): a positive value now represents the
>> actual number of compressed bytes written back, 0 indicates that candidates
>> existed but no writeback succeeded, and a negative value represents an
>> error code.
>
> This part should be dropped for now, and added with the proactive
> writeback, as it's currently unused AFAICT. Removing
> zswap_shrink_walk_arg will simplify the patch and make it focused on
> the batching part.
Will be done in the next version.
>
>>
>> Test Setup:
>> Total memory: 32 GB.
>> zswap settings: max_pool_percent=1, accept_threshold_percent=50,
>> shrinker_enabled=N.
>> Allocate 512MB of anonymous pages and fill them with random data (to avoid
>> compression), then use cgroup memory.reclaim to force a large amount of
>> anonymous pages into zswap. At an interval of 2ms, allocate a 4K anonymous
>> page where the first 4 bytes are random numbers and the rest are zeros, and
>> then trigger a reclamation of this 4K anonymous page through cgroup
>> memory.reclaim. When the pool threshold is reached, shrink_memcg() will
>> be triggered.
>>
>> The test data after running for 120s is as follows:
>> Baseline Patched
>> shrink_worker wakeups 5363 85
>> shrink_memcg calls 11,345,012 188,264
>> written_back 40214 40275
>>
>> Conclusion:
>> Under the same workload and run duration, the patched kernel shows a
>> significant reduction in both shrink_worker wakeups and shrink_memcg calls.
>
> Please also include data from the case where zswap store failures are
> observed and pages go to disk, and compare before and after this
> patch. I think that part is also really important.
I retested and added some collected information. Perhaps
`pool_limit_hit` and `pswpout` can explain that batch shrinking of zswap
can reduce the number of pages that fail to be stored due to the pool
limit, allowing zswap to skip zswap and go directly to disk.
Baseline Patched
shrink_worker wakeups 5,363 85
shrink_memcg calls 11,373,201 180,928
written_back pages 40,212 40,236
zswap_store calls 161,190 168,741
store succeeded (ret=1) 102,743 127,644
store rejected (ret=0) 58,447 41,097
store reject rate ~36% ~24%
pool_limit_hit delta 55,826 14,062
pswpout 98,659 81,333
pswpin 2 1
Thanks,
Hao
^ permalink raw reply
* [PATCH v2] docs/ja_JP: submitting-patches: Refine wording etc for "splitting changes" and later
From: Akira Yokosawa @ 2026-07-15 11:36 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Shuah Khan, linux-doc, linux-kernel, Akira Yokosawa,
Akiyoshi Kurita
Resolve rough edges in translation text added since commit 61e4155c81d1
("docs/ja_JP: translate more of submitting-patches.rst").
As with commit 999084ee0b11 ("docs/ja_JP: submitting-patches: Amend
"Describe your changes""), do the following tweaks:
- Rewording and rephrasing.
- Suppress extra white spaces rendered before and after strong emphasis
in HTML and PDF by using espcaped spaces.
- Provide translation words for "embargo", "word-wrap", "top-posting",
etc.
- Rather than keep "interleaved replies", use only 「インライン返信」
("inline reply"), which is a popular term in Japanese.
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Cc: Akiyoshi Kurita <weibu@redadmin.org>
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
v2: Use 「件名」 for "subject line".
(Inspired by Kurita-san's submission at:
https://lore.kernel.org/20260712210535.161387-1-weibu@redadmin.org/
, "[PATCH v3] docs/ja_JP: translate submitting-patches.rst (sign-off)")
--
.../ja_JP/process/submitting-patches.rst | 150 +++++++++---------
1 file changed, 75 insertions(+), 75 deletions(-)
diff --git a/Documentation/translations/ja_JP/process/submitting-patches.rst b/Documentation/translations/ja_JP/process/submitting-patches.rst
index d31d469909e4..d8ee82ba790b 100644
--- a/Documentation/translations/ja_JP/process/submitting-patches.rst
+++ b/Documentation/translations/ja_JP/process/submitting-patches.rst
@@ -182,7 +182,7 @@ URL は禁止です。
変更を分割する
--------------
-各 **論理的な変更** は、個別のパッチに分けてください。
+それぞれの\ **論理的な変更**\ は、個別のパッチに分けてください。
たとえば、単一のドライバに対する変更にバグ修正と性能改善の
両方が含まれるなら、それらは 2 つ以上のパッチに分けてください。
@@ -208,7 +208,7 @@ URL は禁止です。
ことがあります。途中でバグを持ち込めば、彼らに感謝されることは
ないでしょう。
-パッチセットをこれ以上小さくできないなら、一度に投稿するのは
+パッチセットをそれ以上小さくできないなら、一度に投稿するのは
15 個程度までにして、レビューと統合を待ってください。
@@ -220,18 +220,17 @@ Documentation/process/coding-style.rst を参照してください。
これを怠ると、単にレビューアの時間を無駄にするだけでなく、
パッチはおそらく読まれもせずに却下されます。
-大きな例外が 1 つあります。コードをあるファイルから別の
-ファイルへ移動する場合です。このときは、コードを移動する
-その同じパッチの中で、移動したコードを一切変更してはいけません。
-そうすることで、コードの移動という行為と、あなたの変更とを
-明確に区別できます。これは実際の差分のレビューを大いに助け、
-ツールがコード自体の履歴をより適切に追跡できるようにします。
+一つの重要な例外は、コードをあるファイルから別のファイルへ移動する場合です。
+その際は、コードを移動するその同じパッチの中で、一切コードを変更しては
+いけません。これにより、コードの移動という行為と、コードの変更とが
+明確に区別されます。これは実際の差分のレビューを大いに助け、また、ツールを
+使ったコード変更の履歴の追跡を容易にします。
提出前に、パッチスタイルチェッカー
(``scripts/checkpatch.pl``) でパッチを確認してください。
-ただし、スタイルチェッカーは指針として見るべきであり、
+ただし、スタイルチェッカーは指針にすぎず、
人間の判断に取って代わるものではないことに注意してください。
-違反があっても、その方がコードの見栄えがよいなら、
+違反が指摘されるままのコードの方が見栄えがよいなら、おそらく
そのままにしておくのが最善でしょう。
チェッカーは 3 つのレベルで報告します:
@@ -240,8 +239,7 @@ Documentation/process/coding-style.rst を参照してください。
- WARNING: 慎重なレビューを要するもの
- CHECK: 検討を要するもの
-パッチに残した違反については、すべて理由を説明できなければ
-なりません。
+パッチに違反を残す場合は、そのすべてを正当化できなければなりません。
パッチの宛先を選択する
@@ -256,8 +254,8 @@ Documentation/process/coding-style.rst を参照してください。
サブシステムのメンテナが見つからない場合は、Andrew Morton
(akpm@linux-foundation.org) が最後の手段となるメンテナです。
-すべてのパッチでは、デフォルトで linux-kernel@vger.kernel.org を
-使うべきですが、このリストの流量が多いため、目を通さなくなった
+すべてのパッチは、デフォルトで linux-kernel@vger.kernel.org にも
+送られるべきですが、このリストは流量が多く、目を通さなくなった
開発者も少なくありません。とはいえ、無関係なメーリングリストや
無関係な人々にスパムを送らないでください。
@@ -268,103 +266,104 @@ Documentation/process/coding-style.rst を参照してください。
Linux カーネルに採用されるすべての変更の最終的な裁定者は
Linus Torvalds です。彼のメールアドレスは
<torvalds@linux-foundation.org> です。Linus は大量のメールを
-受け取っており、現時点では彼に直接届くパッチはごくわずかなので、
-通常は彼にメールを送ることを極力避けてください。
+受け取っており、現時点では直接彼を経由するパッチはごくわずかなので、
+通常は彼にメールを送ることを極力\ **避けて**\ ください。
-悪用可能なセキュリティバグを修正するパッチがあるなら、
-そのパッチを security@kernel.org に送ってください。深刻なバグに
+悪用可能なセキュリティバグを修正するパッチの場合は、
+それを security@kernel.org に送ってください。深刻なバグに
ついては、ディストリビュータがユーザーにパッチを配布できるよう、
-短期間の embargo が検討される場合があります。そのような場合、
-そのパッチを公開メーリングリストに送るべきではありません。
+短期間の秘匿措置 (訳註: embargo) が検討される可能性があります。
+ですので、その種のパッチを公開メーリングリストに送らないでください。
Documentation/process/security-bugs.rst も参照してください。
リリース済みカーネルの深刻なバグを修正するパッチは、次のような行を
-パッチの sign-off 欄に入れることで、stable メンテナへ向けてください::
+パッチの sign-off 欄に入れることで、stable メンテナに知らせてください。
+(メールの宛先ではないことに注意。) ::
Cc: stable@vger.kernel.org
-これはメールの受信者ではないことに注意してください。また、
-この文書に加えて Documentation/process/stable-kernel-rules.rst も
-読んでください。
+また、この文書に加えて Documentation/process/stable-kernel-rules.rst
+も読んでください。
変更がユーザーランドとカーネルのインターフェースに影響する場合は、
MAINTAINERS ファイルに記載されている MAN-PAGES メンテナに
-man-pages パッチ、少なくとも変更の通知を送って、情報が
-マニュアルページに反映されるようにしてください。ユーザー空間 API の
+マニュアルページのパッチ、もしくは少なくとも変更の通知を送って、情報が
+そちらにも反映されるようにしてください。ユーザー空間 API の
変更は、linux-api@vger.kernel.org にも Cc してください。
MIME・リンク・圧縮・添付なし、プレーンテキストのみ
----------------------------------------------------
Linus や他のカーネル開発者は、あなたが投稿する変更を読み、
-コメントできる必要があります。カーネル開発者が標準的な
-メールツールを使ってあなたの変更を「引用」し、コードの特定の
-箇所についてコメントできることが重要です。
+コメントできる必要があります。カーネル開発者にとって、コードの特定の
+箇所について、標準的なメールツールを使ってあなたの変更を「引用」し、
+コメントできることが重要です。
-このため、すべてのパッチはメール本文中に ``inline`` で投稿すべきです。
+このため、すべてのパッチはメール本文中に「インライン」で投稿すべきです。
これを行う最も簡単な方法は ``git send-email`` を使うことであり、
強く推奨されます。``git send-email`` の対話型チュートリアルは
-https://git-send-email.io で利用できます。
+https://git-send-email.io にあります。
-``git send-email`` を使わないことを選ぶ場合:
+``git send-email`` を使わない場合:
.. warning::
- パッチをコピー＆ペーストする場合は、エディタの word-wrap によって
- パッチが壊れないよう注意してください。
+ パッチをコピー＆ペーストする際に、エディタによる自動改行で
+ パッチが壊されないよう注意してください。
圧縮の有無にかかわらず、パッチを MIME 添付ファイルとして添付しては
-いけません。多くの一般的なメールアプリケーションは、MIME 添付
-ファイルを常にプレーンテキストとして送信するとは限らず、あなたの
-コードにコメントできなくなります。MIME 添付ファイルは Linus が
-処理するのにも少し余分な時間がかかるため、MIME 添付された変更が
-受け入れられる可能性を下げます。
+いけません。よく使われるメールアプリケーションの多くは、MIME 添付
+ファイルをプレーンテキストとして送信するとは限らず、あなたのコードに
+対するコメントを妨げます。MIME 添付ファイルは Linus (訳補: をはじめ
+とする開発者）が処理するのに余分な手間がかかるため、MIME 添付すると
+その変更が受け入れられる可能性を下げることになります。
-例外: メーラがパッチを壊してしまう場合は、誰かから MIME を使って
-再送するよう求められることがあります。
+例外: パッチがメーラーによって壊されている場合に、MIME による再送
+を求められることがあります。
-パッチを変更せずに送信するようメールクライアントを設定するための
-ヒントについては、Documentation/process/email-clients.rst を参照してください。
+改変なしにパッチを送信するためのメールクライアント設定のヒントは、
+Documentation/process/email-clients.rst を参照してください。
-レビューコメントに返答する
+レビューコメントに応答する
--------------------------
-あなたのパッチには、ほぼ確実に、パッチを改善する方法について
-レビューアからコメントが付きます。それは、あなたのメールへの返信という
-形で届きます。それらのコメントには必ず返答してください。レビューアを
-無視することは、こちらも無視されるためのよい方法です。コメントに
-答えるには、単にそのメールへ返信すれば構いません。コード変更に
+あなたのパッチには、ほぼ確実に、その改善に向けてレビューアから
+コメントが付きます。それは、あなたのメールへの返信という
+形で届きます。それらのコメントには必ず応答してください。レビューアを
+無視することは、あなたが無視されることにつながります。コメントに
+答えるには、単にそのメールへ返信すればよいです。コード変更に
つながらないレビューコメントや質問であっても、次のレビューアが状況を
-よりよく理解できるように、ほぼ確実にコメントまたは changelog エントリに
-反映すべきです。
-
-どのような変更を行うのかをレビューアに必ず伝え、時間を割いてくれた
-ことに感謝してください。コードレビューは疲れる、時間のかかる作業であり、
-レビューアが不機嫌になることもあります。そのような場合であっても、
-丁寧に返答し、指摘された問題に対応してください。次の版を送るときは、
-cover letter または個々のパッチに ``patch changelog`` を追加し、前回の
+よりよく理解できるよう、多くの場合、コメントまたは changelog エントリ
+として残すべきです。
+
+どのような変更を行うのかを忘れずにレビューアに伝えてください。そして
+時間を割いてくれることへの感謝を忘れないでください。
+コードレビューは疲れる、時間のかかる作業であり、
+ときにはレビューアが機嫌を損ねることもあります。そのような場合でも、
+丁寧に応答し、指摘された問題に対応してください。次の版を送る際には、
+カバーレターまたは個々のパッチに ``patch changelog`` を追加し、前回の
投稿との差分を説明してください。詳細は原文の該当節
("The canonical patch format") を参照してください。
.. TODO: Convert to file-local cross-reference when the destination is
translated.
-あなたのパッチにコメントした人には、パッチの Cc リストに追加して、
-新しい版を知らせてください。
+あなたのパッチにコメントしてくれた人たちは、パッチの Cc リストに追加して
+新しい版について知らせてください。
メールクライアントとメーリングリストでの作法についての推奨事項は、
Documentation/process/email-clients.rst を参照してください。
-メール議論では不要な引用を削った interleaved replies を使う
-------------------------------------------------------------
+要点に絞ったインライン返信での議論
+---------------------------------------
-Linux カーネル開発の議論では、top-posting は強く非推奨とされています。
-Interleaved replies、または ``inline`` replies を使うと、会話の流れを
-ずっと追いやすくなります。詳細は次を参照してください:
+Linux カーネル開発の議論では、全文引用 (訳註: top-posting) は強く非推奨です。
+インライン返信 (訳註: interleaved reples or "inline" replies) を使うと、
+会話の流れをずっと追いやすくなります。詳細は次を参照してください:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
-メーリングリストでは、よく次のように引用されます::
+これについて、メーリングリストでは、次の引用をしばしば目にします::
A: http://en.wikipedia.org/wiki/Top_post
Q: Where do I find info about this thing called top-posting?
@@ -381,24 +380,25 @@ https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
Q: Should I include quotations after my reply?
-落胆しない、そして急がない
---------------------------
+落胆しない - いらいらしない
+---------------------------
変更を投稿した後は、辛抱強く待ってください。レビューアは忙しい人たちであり、
-あなたのパッチをすぐに見られるとは限りません。
+あなたのパッチにすぐに取りかかれるとは限りません。
かつては、パッチが何のコメントもなく虚空へ消えていくこともありましたが、
現在の開発プロセスはそれよりも円滑に機能しています。数週間以内、
通常は 2〜3 週間以内にコメントを受け取るはずです。そうならない場合は、
パッチを正しい場所へ送ったか確認してください。再投稿したりレビューアに
-ping したりする前に、少なくとも 1 週間は待ってください。merge window の
-ような忙しい時期には、さらに長く待つ方がよい場合もあります。
+ping したりする前に、少なくとも 1 週間は待ってください。マージ期間
+(訳註: merge window) のような忙しい時期には、さらに長く待ちましょう。
-数週間後に、subject line に "RESEND" を追加して、パッチまたは
-パッチシリーズを再送しても構いません::
+数週間後に、件名に "RESEND" を追加したパッチまたはパッチシリーズを
+再送することは構いません::
[PATCH Vx RESEND] sub/sys: Condensed patch summary
-パッチまたはパッチシリーズの修正版を投稿する場合は、"RESEND" を
-追加しないでください。"RESEND" は、前回の投稿から一切変更していない
-パッチまたはパッチシリーズを再送する場合にのみ使います。
+ただし、パッチまたはパッチシリーズの修正版を投稿する際には "RESEND"
+を追加しないでください。
+"RESEND" は、前回の投稿から一切変更のないパッチまたはパッチシリーズの
+再送だけに当てはまります。
base-commit: 4108b688d3a456ee1d04c15fa09bcd1cfa9bc425
--
2.43.0
^ permalink raw reply related
* [PATCH v6 1/5] spi: dt-bindings: Add spi-device-addr peripheral property
From: Janani Sunil @ 2026-07-15 11:41 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan, Mark Brown, Marius Cristea, Marcus Folkesson,
Kent Gustavsson
Cc: linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
linux-spi, Kent Gustavsson, Janani Sunil
In-Reply-To: <20260715-ad5529r-driver-v6-0-cfdf8b9f5ee3@analog.com>
Some SPI devices support sharing a single chip select across multiple
physical chips by encoding a device address in the SPI frame itself.
Add the generic spi-device-addr property for describing these hardware
addresses. The property is placed on the SPI peripheral node and may
contain multiple addresses.
Signed-off-by: Janani Sunil <janani.sunil@analog.com>
---
Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
index 880a9f624566..135657582131 100644
--- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
@@ -142,6 +142,11 @@ properties:
minItems: 2
maxItems: 4
+ spi-device-addr:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Device address used when multiple peripherals share a single chip select.
+
st,spi-midi-ns:
deprecated: true
description: |
--
2.43.0
^ permalink raw reply related
* [PATCH v6 0/5] iio: dac: Add support for AD5529R DAC
From: Janani Sunil @ 2026-07-15 11:41 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan, Mark Brown, Marius Cristea, Marcus Folkesson,
Kent Gustavsson
Cc: linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
linux-spi, Kent Gustavsson, Janani Sunil
This patch series adds support for Analog Devices AD5529R, a 16 channel
16 and 12 bit voltage Digital-to-Analog Converter (DAC) with integrated
precision reference. The AD5529R operates from both unipolar and
bipolar supplies. The device communicates via SPI interface.
**Device Overview:**
The AD5529R features 16 independent DAC channels, with 16 or 12 bit
resolution, allowing independently programmable output ranges. The
internal 4.096V precision reference sets the accuracy of the output
voltage.
The device can encode a hardware address in its SPI command frame,
allowing up to 4 devices to share a single chip select. This series
introduces a generic spi-device-addr property for describing this type
of addressing. Existing equivalent properties in the Microchip MCP3564
and MCP3911 bindings are retained but marked as deprecated.
**Features Implemented:**
- Support for AD5529R 12-bit and 16-bit variants via device match data.
- Support for a single DAC device using any hardware address between 0
and 3.
- Reset support via reset controller framework.
- Dual regmap configuration to handle 8 and 16 bit registers.
- Per-channel output range configuration from devicetree.
- Optional external reference and bipolar supply handling.
**Patch Summary:**
1. Add the generic spi-device-addr SPI peripheral property.
2. Add spi-device-addr to the MCP3564 binding and deprecate its legacy
vendor specific property.
3. Add spi-device-addr to the MCP3911 binding and deprecate its legacy
vendor specific property.
4. AD5529R binding documentation with channel configuration.
5. Implement AD5529R IIO DAC Driver with regmap support.
**Testing:**
The driver was compiled and tested on the EVAL-AD5529R-ARDZ using a
coraZ7 with a mainline v7.0 kernel.
**Driver Rationale:**
AD5529R introduces:
1. A unique register layout
2. Mixed 8-bit and 16-bit register accesses
3. Hardware specific features like function generators, multi-die
hotpath registers etc.
The device warrants its own driver due to these fundamental
architectural differences, that would require substantial changes to
existing drivers without providing reusable benefits. The standalone
driver also allows future extensions for related devices in the same
family.
**Not Implemented in this Series:**
The binding includes generic, peripheral level device addressing needed for
multi-device support using a shared CS, but the driver presently
supports only a single device.
Signed-off-by: Janani Sunil <janani.sunil@analog.com>
---
Changes in v6:
- Rename spi,device-addr to spi-device-addr and define it as an array at
peripheral node level.
- Fix the SPI binding patch subject prefix to use "spi: dt-bindings:".
- Add spi-device-addr to the MCP3564 and MCP3911 bindings.
- Deprecate the existing Microchip-specific device-address properties.
- Replace adi,output-range-microvolt with output-range-microvolt.
- Move AD5529R device addressing from channel nodes to the peripheral
node.
- Include linux/types.h
- Honour non-zero hardware address in the AD5529R driver.
- Dynamically expose only the channels described by devicetree and
remove unused scan type definitions.
- Use explicit reset assertion and deassertion as the GPIO reset
controller does not implement reset_control_reset().
- Use the MICRO and MILLI unit constants when matching output ranges.
- Simplify optional reference regulator handling and remove the
external reference comment.
- Simplify error messages and stick to 80 col.
- Link to v5: https://lore.kernel.org/r/20260701-ad5529r-driver-v5-0-ed087900e642@analog.com
Changes in v5:
- Move register bitfield definitions next to their parent register
addresses.
- Remove spurious extra indent.
- Rename ad5529r_output_ranges_mv[] to ad5529r_output_ranges_mV[].
- Remove extra parentheses in regmap_reg_range() for the readback range.
- Use reset_control_reset() instead of reset_control_deassert().
- Use 10 * USEC_PER_MSEC instead of a bare 10000 in fsleep().
- Use fwnode_property_present() to explicitly guard the optional property.
- Rewrite external_vref detection using explicit if/else.
- Follow reverse christmas tree variable declaration order.
- Improve invalid channel error message to include the maximum.
- Add a new spi property to include the SPI device address.
- Update ad5529r devicetree binding to allow more than 16 channels to include multiple DACs.
- Update cover letter to add a mention about the multi device support.
- Update driver commit message to describe the device further.
- Link to v4: https://lore.kernel.org/r/20260609-ad5529r-driver-v4-0-2e4c02234a1a@analog.com
Changes in v4:
- Fix DT child-node regex for hexadecimal channel addresses.
- Wrap long DT binding description lines.
- Simplify optional `vref-supply` and `hvss-supply` handling.
- Update REF_SEL programming for optional external reference use.
- Clean up range parsing and error messages.
- Simplify debugfs register access by calling regmap helpers directly.
- Add clarifying comments for reset settling time and RAW reads from `DAC_INPUT_A`.
- Remove an unused vref regulator pointer and an include.
- Rename the REF_SEL bit define and clean up small driver details.
- Toggle pins defined as PWM pins, instead of GPIOs
- Update cover letter to sync up latest changes.
- Link to v3: https://lore.kernel.org/r/20260519-ad5529r-driver-v3-0-267c0731aa68@analog.com
Changes in v3:
- Split into adi,ad5529r-16 and adi,ad5529r-12 device tree compatibles
- Add DT-based output range configuration via adi,output-range-microvolt
- Expand DT binding: vref-supply, clear/tg GPIOs, interrupts, muxout
- Correct power supply voltage specifications as per datasheet
- Reduce SPI frequency limit to 25MHz as per datasheet specs
- Switch to autoincrement addressing mode, remove +1 register offsets
- Use DT match data instead of device ID detection for fallback support
- Implement dynamic scale/offset calculation per configured channel range
- Added explicit val_format_endian and reg_stride for 16-bit regmap bus
- Code cleanup: alphabetical includes, ARRAY_SIZE(), unused defines
- Minor: .sign→.format field, simplify read/write order, optional hvss-supply
- Remove redundant driver documentation ad5529r.rst
- Link to v2: https://lore.kernel.org/r/20260508-ad5529r-driver-v2-0-e315441685d7@analog.com
Changes in v2:
- Fix IIO scale to use millivolts per ABI requirement
- Fix documentation voltage calculations (2.5V not 2.048V)
- Fix bipolar ranges in documentation (±5V, ±10V, ±15V, ±20V)
- Fix alphabetical ordering in documentation index
- Add missing newline to documentation file
- Fix scale units description (millivolts not microvolts)
- Include a section for driver rationale in the cover letter
- Reword contents in cover letter 12/16 bit generic->variant
- Add dependency array for spi-cpha and spi-cpol properties
- Link to v1: https://lore.kernel.org/r/20260507-ad5529r-driver-v1-0-b4460f3cb44f@analog.com
---
Janani Sunil (5):
spi: dt-bindings: Add spi-device-addr peripheral property
dt-bindings: iio: adc: microchip,mcp3564: Add spi-device-addr
dt-bindings: iio: adc: microchip,mcp3911: Add spi-device-addr
dt-bindings: iio: dac: Add AD5529R
iio: dac: Add AD5529R DAC driver support
.../bindings/iio/adc/microchip,mcp3564.yaml | 9 +-
.../bindings/iio/adc/microchip,mcp3911.yaml | 8 +-
.../devicetree/bindings/iio/dac/adi,ad5529r.yaml | 224 +++++++++
.../bindings/spi/spi-peripheral-props.yaml | 5 +
MAINTAINERS | 8 +
drivers/iio/dac/Kconfig | 17 +
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/ad5529r.c | 502 +++++++++++++++++++++
8 files changed, 771 insertions(+), 3 deletions(-)
---
base-commit: 93df88612859e8e19dec93c69d563b4b73e9bd4b
change-id: 20260507-ad5529r-driver-866bbdd864de
Best regards,
--
Janani Sunil <janani.sunil@analog.com>
^ permalink raw reply
* [PATCH v6 2/5] dt-bindings: iio: adc: microchip,mcp3564: Add spi-device-addr
From: Janani Sunil @ 2026-07-15 11:41 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan, Mark Brown, Marius Cristea, Marcus Folkesson,
Kent Gustavsson
Cc: linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
linux-spi, Kent Gustavsson, Janani Sunil
In-Reply-To: <20260715-ad5529r-driver-v6-0-cfdf8b9f5ee3@analog.com>
Add the generic spi-device-addr property to the binding and deprecate
the existing vendor specific microchip,hw-device-address property.
Signed-off-by: Janani Sunil <janani.sunil@analog.com>
---
Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
index 675319276197..02bb198e9fa7 100644
--- a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
@@ -80,6 +80,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
+ deprecated: true
description:
The address is set on a per-device basis by fuses in the factory,
configured on request. If not requested, the fuses are set for 0x1.
@@ -91,6 +92,11 @@ properties:
clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
which is first one on the wire).
+ spi-device-addr:
+ maxItems: 1
+ items:
+ enum: [0, 1, 2, 3]
+
"#io-channel-cells":
const: 1
@@ -123,7 +129,6 @@ dependencies:
required:
- compatible
- reg
- - microchip,hw-device-address
- spi-max-frequency
allOf:
@@ -159,7 +164,7 @@ examples:
spi-cpha;
spi-cpol;
spi-max-frequency = <10000000>;
- microchip,hw-device-address = <1>;
+ spi-device-addr = <1>;
#address-cells = <1>;
#size-cells = <0>;
--
2.43.0
^ permalink raw reply related
* [PATCH v6 3/5] dt-bindings: iio: adc: microchip,mcp3911: Add spi-device-addr
From: Janani Sunil @ 2026-07-15 11:41 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan, Mark Brown, Marius Cristea, Marcus Folkesson,
Kent Gustavsson
Cc: linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
linux-spi, Kent Gustavsson, Janani Sunil
In-Reply-To: <20260715-ad5529r-driver-v6-0-cfdf8b9f5ee3@analog.com>
Add the generic spi-device-addr property to the binding and deprecate
the existing vendor specific microchip,device-addr property
Signed-off-by: Janani Sunil <janani.sunil@analog.com>
---
Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
index 3a69ec60edb9..4a60df06bd35 100644
--- a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
@@ -57,6 +57,12 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
+ deprecated: true
+
+ spi-device-addr:
+ maxItems: 1
+ items:
+ enum: [0, 1, 2, 3]
vref-supply:
description: |
@@ -86,7 +92,7 @@ examples:
interrupts = <15 2>;
reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
spi-max-frequency = <20000000>;
- microchip,device-addr = <0>;
+ spi-device-addr = <0>;
vref-supply = <&vref_reg>;
clocks = <&xtal>;
};
--
2.43.0
^ permalink raw reply related
* [PATCH v6 4/5] dt-bindings: iio: dac: Add AD5529R
From: Janani Sunil @ 2026-07-15 11:41 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan, Mark Brown, Marius Cristea, Marcus Folkesson,
Kent Gustavsson
Cc: linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
linux-spi, Kent Gustavsson, Janani Sunil
In-Reply-To: <20260715-ad5529r-driver-v6-0-cfdf8b9f5ee3@analog.com>
Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
buffered voltage output digital-to-analog converter (DAC) with an
integrated precision reference.
Signed-off-by: Janani Sunil <janani.sunil@analog.com>
---
.../devicetree/bindings/iio/dac/adi,ad5529r.yaml | 224 +++++++++++++++++++++
MAINTAINERS | 7 +
2 files changed, 231 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml
new file mode 100644
index 000000000000..730206fd6eab
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml
@@ -0,0 +1,224 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,ad5529r.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD5529R 16-Channel 12/16-bit High Voltage DAC
+
+maintainers:
+ - Janani Sunil <janani.sunil@analog.com>
+
+description: |
+ The AD5529R is a 16-channel, 12-bit or 16-bit, high voltage, buffered voltage
+ output digital-to-analog converter (DAC) with an integrated precision reference.
+ The device operates from unipolar and bipolar supplies. It is guaranteed
+ monotonic and has built-in rail-to-rail output buffers that can source or
+ sink up to 25mA.
+
+ Specifications:
+ * 16 independent 12-bit or 16-bit DAC channels
+ * Independently programmable output ranges: 0V to 5V, 0V to 10V, 0V to 20V,
+ 0V to 40V, ±5V, ±10V, ±15V, and ±20V
+ * The device supports SPI communication with Mode 0 and Mode 3.
+ * 4.096V precision reference, 12ppm/°C maximum
+ * Built-in function generation: Toggle, Sinusoidal Dither, and Ramp waveforms
+ * Multiplexer for output voltage, load current sense and die temperature
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ad5529r.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ad5529r-16 # 16-bit variant
+ - adi,ad5529r-12 # 12-bit variant
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 25000000
+ description:
+ Maximum SPI frequency. The device supports SPI Mode 0 and Mode 3.
+ Read operations are limited to 25MHz maximum.
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the RESET pin. Active low. When asserted low,
+ performs a power-on reset and initializes the device to its default state.
+
+ clear-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the CLEAR pin. Active low. When asserted low,
+ clears all DAC data registers without affecting configuration settings.
+
+ interrupts:
+ maxItems: 1
+ description:
+ Interrupt connected to the ALARM pin. Active low interrupt output
+ for overtemperature conditions, SPI CRC errors, and function completion.
+
+ pwms:
+ minItems: 1
+ maxItems: 4
+ description:
+ PWM signals connected to the TG0-TG3 toggle pins. Pulsing these pins
+ based on trigger edge settings allows selected DACs to be updated
+ synchronously for digital function generation.
+
+ pwm-names:
+ minItems: 1
+ maxItems: 4
+ items:
+ enum: [ tg0, tg1, tg2, tg3 ]
+
+ io-channels:
+ maxItems: 1
+ description:
+ ADC channel connected to the MUXOUT pin for monitoring output voltage,
+ load current sense, and die temperature.
+
+ io-channel-names:
+ const: muxout
+
+ vdd-supply:
+ description: Digital power supply (1.08V to 1.98V)
+
+ avdd-supply:
+ description: Analog power supply (4.75V to 5.25V)
+
+ hvdd-supply:
+ description:
+ High voltage positive supply (7V to 45V). Supply voltage should be chosen
+ based on configured output ranges (see datasheet Table 9).
+
+ hvss-supply:
+ description:
+ High voltage negative supply (-22.5V to 0V). Required only when using
+ bipolar output ranges (±5V, ±10V, ±15V, ±20V). Supply voltage should be
+ chosen based on configured output ranges (see datasheet Table 9).
+
+ vref-supply:
+ description:
+ External voltage reference supply (4.056V to 4.136V, typically 4.096V).
+ When specified, the device uses external reference mode and the VREF pin
+ becomes an input. The device uses the internal 4.096V precision reference
+ otherwise.
+
+ spi-device-addr:
+ minItems: 1
+ maxItems: 4
+ items:
+ enum: [0, 1, 2, 3]
+ default: [0]
+ description:
+ Hardware address of each device, selected by the ID0 and ID1 pins.
+ Up to four AD5529R devices can share a single SPI chip select.
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^channel@([0-9a-f]{1,2})$":
+ $ref: dac.yaml
+ type: object
+ description: Child nodes for individual channel configuration
+
+ properties:
+ reg:
+ description:
+ Flattened channel number across all AD5529R devices sharing the chip
+ select. Within each 16-channel block, the physical channel number is reg % 16.
+ minimum: 0
+ maximum: 63
+
+ output-range-microvolt:
+ description:
+ Output voltage range for this channel as [min, max] in
+ microvolts.
+ oneOf:
+ - items:
+ - const: 0
+ default: 0
+ - enum: [5000000, 10000000, 20000000, 40000000]
+ default: 5000000
+ - items:
+ - const: -5000000
+ - const: 5000000
+ - items:
+ - const: -10000000
+ - const: 10000000
+ - items:
+ - const: -15000000
+ - const: 15000000
+ - items:
+ - const: -20000000
+ - const: 20000000
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - avdd-supply
+ - hvdd-supply
+
+dependencies:
+ spi-cpha: [ spi-cpol ]
+ spi-cpol: [ spi-cpha ]
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "adi,ad5529r-16";
+ reg = <0>;
+ spi-max-frequency = <25000000>;
+ spi-device-addr = <0>;
+
+ vdd-supply = <&vdd_regulator>;
+ avdd-supply = <&avdd_regulator>;
+ hvdd-supply = <&hvdd_regulator>;
+ hvss-supply = <&hvss_regulator>;
+
+ reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ output-range-microvolt = <0 5000000>;
+ };
+
+ channel@1 {
+ reg = <1>;
+ output-range-microvolt = <(-10000000) 10000000>;
+ };
+
+ channel@2 {
+ reg = <2>;
+ output-range-microvolt = <0 40000000>;
+ };
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index d6c3c7d22403..320e84765ce6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1507,6 +1507,13 @@ W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/iio/adc/adi,ad4851.yaml
F: drivers/iio/adc/ad4851.c
+ANALOG DEVICES INC AD5529R DRIVER
+M: Janani Sunil <janani.sunil@analog.com>
+L: linux-iio@vger.kernel.org
+S: Supported
+W: https://ez.analog.com/linux-software-drivers
+F: Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml
+
ANALOG DEVICES INC AD5706R DRIVER
M: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
L: linux-iio@vger.kernel.org
--
2.43.0
^ permalink raw reply related
* [PATCH v6 5/5] iio: dac: Add AD5529R DAC driver support
From: Janani Sunil @ 2026-07-15 11:41 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan, Mark Brown, Marius Cristea, Marcus Folkesson,
Kent Gustavsson
Cc: linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
linux-spi, Kent Gustavsson, Janani Sunil
In-Reply-To: <20260715-ad5529r-driver-v6-0-cfdf8b9f5ee3@analog.com>
Add support for AD5529R 16-channel, 12/16 bit Digital to Analog Converter
from Analog Devices.
The device communicates over SPI and supports per-channel output range
configuration. An optional external 4.096V reference can be used in
place of the internal reference.
Signed-off-by: Janani Sunil <janani.sunil@analog.com>
---
MAINTAINERS | 1 +
drivers/iio/dac/Kconfig | 17 ++
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/ad5529r.c | 502 ++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 521 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 320e84765ce6..143714e27d51 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1513,6 +1513,7 @@ L: linux-iio@vger.kernel.org
S: Supported
W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml
+F: drivers/iio/dac/ad5529r.c
ANALOG DEVICES INC AD5706R DRIVER
M: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index 657c68e75542..bb1d59889a2a 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -134,6 +134,23 @@ config AD5449
To compile this driver as a module, choose M here: the
module will be called ad5449.
+config AD5529R
+ tristate "Analog Devices AD5529R High Voltage DAC driver"
+ depends on SPI_MASTER
+ select REGMAP_SPI
+ help
+ Say yes here to build support for Analog Devices AD5529R
+ 16-Channel, 12-Bit/16-Bit, 40V High Voltage Precision Digital to Analog
+ Converter.
+
+ The device features multiple output voltage ranges from -20V to +20V,
+ built-in 4.096V voltage reference, and digital functions including
+ toggle, dither, and ramp modes. Supports both 12-bit and 16-bit
+ resolution variants.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad5529r.
+
config AD5592R_BASE
tristate
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 003431798498..f35e060b3643 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_AD5446) += ad5446.o
obj-$(CONFIG_AD5446_SPI) += ad5446-spi.o
obj-$(CONFIG_AD5446_I2C) += ad5446-i2c.o
obj-$(CONFIG_AD5449) += ad5449.o
+obj-$(CONFIG_AD5529R) += ad5529r.o
obj-$(CONFIG_AD5592R_BASE) += ad5592r-base.o
obj-$(CONFIG_AD5592R) += ad5592r.o
obj-$(CONFIG_AD5593R) += ad5593r.o
diff --git a/drivers/iio/dac/ad5529r.c b/drivers/iio/dac/ad5529r.c
new file mode 100644
index 000000000000..c279dc530d68
--- /dev/null
+++ b/drivers/iio/dac/ad5529r.c
@@ -0,0 +1,502 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * AD5529R Digital-to-Analog Converter Driver
+ * 16-Channel, 12/16-Bit, 40V High Voltage Precision DAC
+ *
+ * Copyright 2026 Analog Devices Inc.
+ * Author: Janani Sunil <janani.sunil@analog.com>
+ */
+
+#include <linux/array_size.h>
+#include <linux/bits.h>
+#include <linux/delay.h>
+#include <linux/dev_printk.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/iio/iio.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
+#include <linux/spi/spi.h>
+#include <linux/types.h>
+#include <linux/units.h>
+
+#define AD5529R_REG_INTERFACE_CONFIG_A 0x00
+#define AD5529R_INTERFACE_CONFIG_A_SW_RESET (BIT(7) | BIT(0))
+#define AD5529R_INTERFACE_CONFIG_A_ADDR_ASCENSION BIT(5)
+#define AD5529R_INTERFACE_CONFIG_A_SDO_ENABLE BIT(4)
+#define AD5529R_REG_DEVICE_CONFIG 0x02
+#define AD5529R_REG_CHIP_GRADE 0x06
+#define AD5529R_REG_SCRATCH_PAD 0x0A
+#define AD5529R_REG_SPI_REVISION 0x0B
+#define AD5529R_REG_VENDOR_H 0x0D
+#define AD5529R_REG_STREAM_MODE 0x0E
+#define AD5529R_REG_INTERFACE_STATUS_A 0x11
+#define AD5529R_REG_MULTI_DAC_CH_SEL 0x14
+#define AD5529R_REG_OUT_RANGE_BASE 0x3C
+#define AD5529R_REG_OUT_RANGE(ch) (AD5529R_REG_OUT_RANGE_BASE + (ch) * 2)
+#define AD5529R_REG_DAC_INPUT_A_BASE 0x148
+#define AD5529R_REG_DAC_INPUT_A(ch) (AD5529R_REG_DAC_INPUT_A_BASE + (ch) * 2)
+#define AD5529R_REG_DAC_DATA_READBACK_BASE 0x16A
+#define AD5529R_REG_TSENS_ALERT_FLAG 0x18C
+#define AD5529R_REG_TSENS_SHTD_FLAG 0x18E
+#define AD5529R_REG_FUNC_BUSY 0x1A0
+#define AD5529R_REG_REF_SEL 0x1A2
+#define AD5529R_REF_SEL_INTERNAL_REF BIT(0)
+#define AD5529R_REG_INIT_CRC_ERR_STAT 0x1A4
+#define AD5529R_REG_MULTI_DAC_HOTPATH_SW_LDAC 0x1A8
+
+#define AD5529R_MAX_REGISTER 0x232
+#define AD5529R_8BIT_REG_MAX 0x13
+#define AD5529R_SPI_READ_FLAG 0x80
+#define AD5529R_ADDR_SHIFT 12
+
+struct ad5529r_model_data {
+ const char *model_name;
+ unsigned int resolution;
+};
+
+#define AD5529R_DAC_CHANNEL(chan) ((struct iio_chan_spec) { \
+ .type = IIO_VOLTAGE, \
+ .indexed = 1, \
+ .output = 1, \
+ .channel = (chan), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE) | \
+ BIT(IIO_CHAN_INFO_OFFSET), \
+})
+
+static const char * const ad5529r_supply_names[] = {
+ "vdd",
+ "avdd",
+ "hvdd",
+};
+
+static const struct ad5529r_model_data ad5529r_16bit_model_data = {
+ .model_name = "ad5529r-16",
+ .resolution = 16,
+};
+
+static const struct ad5529r_model_data ad5529r_12bit_model_data = {
+ .model_name = "ad5529r-12",
+ .resolution = 12,
+};
+
+enum ad5529r_output_range {
+ AD5529R_RANGE_0V_5V,
+ AD5529R_RANGE_0V_10V,
+ AD5529R_RANGE_0V_20V,
+ AD5529R_RANGE_0V_40V,
+ AD5529R_RANGE_NEG5V_5V,
+ AD5529R_RANGE_NEG10V_10V,
+ AD5529R_RANGE_NEG15V_15V,
+ AD5529R_RANGE_NEG20V_20V,
+};
+
+static const s32 ad5529r_output_ranges_mV[8][2] = {
+ [AD5529R_RANGE_0V_5V] = { 0, 5000 },
+ [AD5529R_RANGE_0V_10V] = { 0, 10000 },
+ [AD5529R_RANGE_0V_20V] = { 0, 20000 },
+ [AD5529R_RANGE_0V_40V] = { 0, 40000 },
+ [AD5529R_RANGE_NEG5V_5V] = { -5000, 5000 },
+ [AD5529R_RANGE_NEG10V_10V] = { -10000, 10000 },
+ [AD5529R_RANGE_NEG15V_15V] = { -15000, 15000 },
+ [AD5529R_RANGE_NEG20V_20V] = { -20000, 20000 },
+};
+
+struct ad5529r_state {
+ struct spi_device *spi;
+ const struct ad5529r_model_data *model_data;
+ struct regmap *regmap_8bit;
+ struct regmap *regmap_16bit;
+ struct iio_chan_spec channels[16];
+ unsigned int num_channels;
+ enum ad5529r_output_range output_range_idx[16];
+};
+
+static const struct regmap_range ad5529r_8bit_readable_ranges[] = {
+ regmap_reg_range(AD5529R_REG_INTERFACE_CONFIG_A, AD5529R_REG_CHIP_GRADE),
+ regmap_reg_range(AD5529R_REG_SCRATCH_PAD, AD5529R_REG_VENDOR_H),
+ regmap_reg_range(AD5529R_REG_STREAM_MODE, AD5529R_REG_INTERFACE_STATUS_A),
+};
+
+static const struct regmap_range ad5529r_16bit_readable_ranges[] = {
+ regmap_reg_range(AD5529R_REG_MULTI_DAC_CH_SEL, AD5529R_REG_INIT_CRC_ERR_STAT),
+ regmap_reg_range(AD5529R_REG_MULTI_DAC_HOTPATH_SW_LDAC, AD5529R_MAX_REGISTER),
+};
+
+static const struct regmap_access_table ad5529r_8bit_readable_table = {
+ .yes_ranges = ad5529r_8bit_readable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(ad5529r_8bit_readable_ranges),
+};
+
+static const struct regmap_access_table ad5529r_16bit_readable_table = {
+ .yes_ranges = ad5529r_16bit_readable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(ad5529r_16bit_readable_ranges),
+};
+
+static const struct regmap_range ad5529r_8bit_read_only_ranges[] = {
+ regmap_reg_range(AD5529R_REG_DEVICE_CONFIG, AD5529R_REG_CHIP_GRADE),
+ regmap_reg_range(AD5529R_REG_SPI_REVISION, AD5529R_REG_VENDOR_H),
+};
+
+static const struct regmap_range ad5529r_16bit_read_only_ranges[] = {
+ regmap_reg_range(AD5529R_REG_DAC_DATA_READBACK_BASE,
+ AD5529R_REG_DAC_DATA_READBACK_BASE + 15 * 2),
+ regmap_reg_range(AD5529R_REG_TSENS_ALERT_FLAG, AD5529R_REG_TSENS_SHTD_FLAG),
+ regmap_reg_range(AD5529R_REG_FUNC_BUSY, AD5529R_REG_FUNC_BUSY),
+ regmap_reg_range(AD5529R_REG_INIT_CRC_ERR_STAT, AD5529R_REG_INIT_CRC_ERR_STAT),
+};
+
+static const struct regmap_access_table ad5529r_8bit_writeable_table = {
+ .no_ranges = ad5529r_8bit_read_only_ranges,
+ .n_no_ranges = ARRAY_SIZE(ad5529r_8bit_read_only_ranges),
+};
+
+static const struct regmap_access_table ad5529r_16bit_writeable_table = {
+ .no_ranges = ad5529r_16bit_read_only_ranges,
+ .n_no_ranges = ARRAY_SIZE(ad5529r_16bit_read_only_ranges),
+};
+
+static const struct regmap_config ad5529r_regmap_8bit_config = {
+ .name = "ad5529r-8bit",
+ .reg_bits = 16,
+ .val_bits = 8,
+ .max_register = AD5529R_8BIT_REG_MAX,
+ .read_flag_mask = AD5529R_SPI_READ_FLAG,
+ .rd_table = &ad5529r_8bit_readable_table,
+ .wr_table = &ad5529r_8bit_writeable_table,
+};
+
+static const struct regmap_config ad5529r_regmap_16bit_config = {
+ .name = "ad5529r-16bit",
+ .reg_bits = 16,
+ .val_bits = 16,
+ .max_register = AD5529R_MAX_REGISTER,
+ .read_flag_mask = AD5529R_SPI_READ_FLAG,
+ .val_format_endian = REGMAP_ENDIAN_LITTLE,
+ .rd_table = &ad5529r_16bit_readable_table,
+ .wr_table = &ad5529r_16bit_writeable_table,
+ .reg_stride = 2,
+};
+
+static struct regmap *ad5529r_get_regmap(struct ad5529r_state *st,
+ unsigned int reg)
+{
+ if (reg <= AD5529R_8BIT_REG_MAX)
+ return st->regmap_8bit;
+
+ return st->regmap_16bit;
+}
+
+static int ad5529r_reset(struct ad5529r_state *st)
+{
+ struct reset_control *rst;
+ int ret;
+
+ rst = devm_reset_control_get_optional_exclusive(&st->spi->dev, NULL);
+ if (IS_ERR(rst))
+ return PTR_ERR(rst);
+
+ if (rst) {
+ ret = reset_control_assert(rst);
+ if (ret)
+ return ret;
+
+ ret = reset_control_deassert(rst);
+ if (ret)
+ return ret;
+ } else {
+ ret = regmap_write(st->regmap_8bit, AD5529R_REG_INTERFACE_CONFIG_A,
+ AD5529R_INTERFACE_CONFIG_A_SW_RESET);
+ if (ret)
+ return ret;
+ }
+
+ /*
+ * Wait 10 ms for digital initialization to complete.
+ * Per datasheet, Interface Status A register NOT_READY_ERR bit is
+ * set if SPI transactions are attempted before digital initialization
+ * completes.
+ */
+ fsleep(10 * USEC_PER_MSEC);
+
+ return regmap_write(st->regmap_8bit, AD5529R_REG_INTERFACE_CONFIG_A,
+ AD5529R_INTERFACE_CONFIG_A_SDO_ENABLE |
+ AD5529R_INTERFACE_CONFIG_A_ADDR_ASCENSION);
+}
+
+static int ad5529r_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct ad5529r_state *st = iio_priv(indio_dev);
+ unsigned int reg_addr, reg_val_h;
+ int ret, range_idx, span_mv;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ /*
+ * Read from DAC_INPUT_A register rather than DAC_DATA_READBACK.
+ * The DAC operates in transparent mode and directly reflects
+ * whatever value is written to the INPUT_A register.
+ */
+ reg_addr = AD5529R_REG_DAC_INPUT_A(chan->channel);
+ ret = regmap_read(st->regmap_16bit, reg_addr, ®_val_h);
+ if (ret)
+ return ret;
+
+ *val = reg_val_h;
+
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ range_idx = st->output_range_idx[chan->channel];
+
+ span_mv = ad5529r_output_ranges_mV[range_idx][1] -
+ ad5529r_output_ranges_mV[range_idx][0];
+ *val = span_mv;
+ *val2 = st->model_data->resolution;
+
+ return IIO_VAL_FRACTIONAL_LOG2;
+ case IIO_CHAN_INFO_OFFSET:
+ range_idx = st->output_range_idx[chan->channel];
+
+ if (ad5529r_output_ranges_mV[range_idx][0] < 0)
+ *val = -(1 << (st->model_data->resolution - 1));
+ else
+ *val = 0;
+
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int ad5529r_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int val, int val2, long mask)
+{
+ struct ad5529r_state *st = iio_priv(indio_dev);
+ unsigned int reg_addr;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ if (val < 0 || val > GENMASK(st->model_data->resolution - 1, 0))
+ return -EINVAL;
+
+ reg_addr = AD5529R_REG_DAC_INPUT_A(chan->channel);
+
+ return regmap_write(st->regmap_16bit, reg_addr, val);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int ad5529r_find_output_range(const s32 *vals)
+{
+ for (unsigned int i = 0; i < ARRAY_SIZE(ad5529r_output_ranges_mV); i++) {
+ const s32 *range = ad5529r_output_ranges_mV[i];
+
+ if (vals[0] == range[0] * (MICRO / MILLI) &&
+ vals[1] == range[1] * (MICRO / MILLI))
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+static int ad5529r_parse_channel_ranges(struct device *dev,
+ struct ad5529r_state *st)
+{
+ s32 vals[2];
+ int ret, range_idx;
+ u32 ch;
+
+ device_for_each_child_node_scoped(dev, child) {
+ ret = fwnode_property_read_u32(child, "reg", &ch);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Missing reg property in channel node\n");
+
+ if (ch >= 16)
+ return dev_err_probe(dev, -EINVAL,
+ "Channel %u exceeds maximum 15\n",
+ ch);
+
+ if (fwnode_property_present(child, "output-range-microvolt")) {
+ /*
+ * DT stores cells as raw 32-bit values; signed endpoints are
+ * encoded by dtc in two's-complement and then interpreted
+ * here as s32.
+ */
+ ret = fwnode_property_read_u32_array(child,
+ "output-range-microvolt",
+ (u32 *)vals, ARRAY_SIZE(vals));
+ if (ret < 0)
+ return dev_err_probe(dev, ret,
+ "Failed to read range for ch %u\n",
+ ch);
+
+ range_idx = ad5529r_find_output_range(vals);
+ if (range_idx < 0)
+ return dev_err_probe(dev, range_idx,
+ "Invalid range [%d %d] for ch %u\n",
+ vals[0], vals[1], ch);
+ } else {
+ range_idx = AD5529R_RANGE_0V_5V;
+ }
+
+ st->output_range_idx[ch] = range_idx;
+ ret = regmap_write(st->regmap_16bit,
+ AD5529R_REG_OUT_RANGE(ch), range_idx);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to configure range for ch %u\n",
+ ch);
+
+ st->channels[st->num_channels++] = AD5529R_DAC_CHANNEL(ch);
+ }
+
+ return 0;
+}
+
+static int ad5529r_reg_access(struct iio_dev *indio_dev,
+ unsigned int reg,
+ unsigned int writeval,
+ unsigned int *readval)
+{
+ struct ad5529r_state *st = iio_priv(indio_dev);
+
+ if (readval)
+ return regmap_read(ad5529r_get_regmap(st, reg), reg, readval);
+
+ return regmap_write(ad5529r_get_regmap(st, reg), reg, writeval);
+}
+
+static const struct iio_info ad5529r_info = {
+ .read_raw = ad5529r_read_raw,
+ .write_raw = ad5529r_write_raw,
+ .debugfs_reg_access = ad5529r_reg_access,
+};
+
+static int ad5529r_probe(struct spi_device *spi)
+{
+ struct device *dev = &spi->dev;
+ struct iio_dev *indio_dev;
+ struct ad5529r_state *st;
+ struct regmap_config regmap_8bit_cfg = ad5529r_regmap_8bit_config;
+ struct regmap_config regmap_16bit_cfg = ad5529r_regmap_16bit_config;
+ bool external_vref;
+ u32 dev_addr = 0;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*st));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ st = iio_priv(indio_dev);
+
+ st->spi = spi;
+
+ st->model_data = spi_get_device_match_data(spi);
+ if (!st->model_data)
+ return dev_err_probe(dev, -EINVAL,
+ "Failed to identify device variant\n");
+
+ device_property_read_u32(dev, "spi-device-addr", &dev_addr);
+ if (dev_addr > 3)
+ return dev_err_probe(dev, -EINVAL,
+ "spi-device-addr %u out of range [0, 3]\n",
+ dev_addr);
+ regmap_8bit_cfg.reg_base = dev_addr << AD5529R_ADDR_SHIFT;
+ regmap_16bit_cfg.reg_base = dev_addr << AD5529R_ADDR_SHIFT;
+
+ ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(ad5529r_supply_names),
+ ad5529r_supply_names);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to get and enable regulators\n");
+
+ ret = devm_regulator_get_enable_optional(dev, "hvss");
+ if (ret && ret != -ENODEV)
+ return dev_err_probe(dev, ret,
+ "Failed to get and enable hvss regulator\n");
+
+ ret = devm_regulator_get_enable_optional(dev, "vref");
+ if (ret == -ENODEV)
+ external_vref = false;
+ else if (!ret)
+ external_vref = true;
+ else
+ return dev_err_probe(dev, ret,
+ "Failed to get and enable vref regulator\n");
+
+ st->regmap_8bit = devm_regmap_init_spi(spi, ®map_8bit_cfg);
+ if (IS_ERR(st->regmap_8bit))
+ return dev_err_probe(dev, PTR_ERR(st->regmap_8bit),
+ "Failed to initialize 8-bit regmap\n");
+
+ st->regmap_16bit = devm_regmap_init_spi(spi, ®map_16bit_cfg);
+ if (IS_ERR(st->regmap_16bit))
+ return dev_err_probe(dev, PTR_ERR(st->regmap_16bit),
+ "Failed to initialize 16-bit regmap\n");
+
+ ret = ad5529r_reset(st);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to reset device\n");
+
+ ret = regmap_assign_bits(st->regmap_16bit, AD5529R_REG_REF_SEL,
+ AD5529R_REF_SEL_INTERNAL_REF,
+ external_vref ? 0 : AD5529R_REF_SEL_INTERNAL_REF);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to configure reference\n");
+
+ ret = ad5529r_parse_channel_ranges(dev, st);
+ if (ret)
+ return ret;
+
+ indio_dev->name = st->model_data->model_name;
+ indio_dev->info = &ad5529r_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->channels = st->channels;
+ indio_dev->num_channels = st->num_channels;
+
+ return devm_iio_device_register(dev, indio_dev);
+}
+
+static const struct of_device_id ad5529r_of_match[] = {
+ { .compatible = "adi,ad5529r-16", .data = &ad5529r_16bit_model_data },
+ { .compatible = "adi,ad5529r-12", .data = &ad5529r_12bit_model_data },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ad5529r_of_match);
+
+static const struct spi_device_id ad5529r_id[] = {
+ {
+ .name = "ad5529r-16",
+ .driver_data = (kernel_ulong_t)&ad5529r_16bit_model_data,
+ },
+ {
+ .name = "ad5529r-12",
+ .driver_data = (kernel_ulong_t)&ad5529r_12bit_model_data,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(spi, ad5529r_id);
+
+static struct spi_driver ad5529r_driver = {
+ .driver = {
+ .name = "ad5529r",
+ .of_match_table = ad5529r_of_match,
+ },
+ .probe = ad5529r_probe,
+ .id_table = ad5529r_id,
+};
+module_spi_driver(ad5529r_driver);
+
+MODULE_AUTHOR("Janani Sunil <janani.sunil@analog.com>");
+MODULE_DESCRIPTION("Analog Devices AD5529R 12/16-bit DAC driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] docs/ja_JP: submitting-patches: Refine wording etc for "splitting changes" and later
From: Weijie Yuan @ 2026-07-15 11:43 UTC (permalink / raw)
To: Akira Yokosawa
Cc: Jonathan Corbet, Shuah Khan, linux-doc, linux-kernel,
Akiyoshi Kurita
In-Reply-To: <20260715113616.94305-1-akiyks@gmail.com>
On Wed, Jul 15, 2026 at 08:36:16PM +0900, Akira Yokosawa wrote:
> Resolve rough edges in translation text added since commit 61e4155c81d1
> ("docs/ja_JP: translate more of submitting-patches.rst").
>
> As with commit 999084ee0b11 ("docs/ja_JP: submitting-patches: Amend
> "Describe your changes""), do the following tweaks:
>
> - Rewording and rephrasing.
> - Suppress extra white spaces rendered before and after strong emphasis
> in HTML and PDF by using espcaped spaces.
> - Provide translation words for "embargo", "word-wrap", "top-posting",
> etc.
> - Rather than keep "interleaved replies", use only 「インライン返信」
> ("inline reply"), which is a popular term in Japanese.
>
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> Cc: Akiyoshi Kurita <weibu@redadmin.org>
>
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Duplicated sign-off? ;-)
^ permalink raw reply
* [PATCH v3] docs/ja_JP: submitting-patches: Refine wording etc for "splitting changes" and later
From: Akira Yokosawa @ 2026-07-15 12:05 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Shuah Khan, Weijie Yuan, linux-doc, linux-kernel, Akira Yokosawa,
Akiyoshi Kurita
Resolve rough edges in translation text added since commit 61e4155c81d1
("docs/ja_JP: translate more of submitting-patches.rst").
As with commit 999084ee0b11 ("docs/ja_JP: submitting-patches: Amend
"Describe your changes""), do the following tweaks:
- Rewording and rephrasing.
- Suppress extra white spaces rendered before and after strong emphasis
in HTML and PDF by using espcaped spaces.
- Provide translation words for "embargo", "word-wrap", "top-posting",
etc.
- Rather than keep "interleaved replies", use only 「インライン返信」
("inline reply"), which is a popular term in Japanese.
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Cc: Akiyoshi Kurita <weibu@redadmin.org>
---
v3: Remove duplicated Signed-off-by: ...
v2: Use 「件名」 for "subject line".
(Inspired by Kurita-san's submission at:
https://lore.kernel.org/20260712210535.161387-1-weibu@redadmin.org/
, "[PATCH v3] docs/ja_JP: translate submitting-patches.rst (sign-off)")
---
.../ja_JP/process/submitting-patches.rst | 150 +++++++++---------
1 file changed, 75 insertions(+), 75 deletions(-)
diff --git a/Documentation/translations/ja_JP/process/submitting-patches.rst b/Documentation/translations/ja_JP/process/submitting-patches.rst
index d31d469909e4..d8ee82ba790b 100644
--- a/Documentation/translations/ja_JP/process/submitting-patches.rst
+++ b/Documentation/translations/ja_JP/process/submitting-patches.rst
@@ -182,7 +182,7 @@ URL は禁止です。
変更を分割する
--------------
-各 **論理的な変更** は、個別のパッチに分けてください。
+それぞれの\ **論理的な変更**\ は、個別のパッチに分けてください。
たとえば、単一のドライバに対する変更にバグ修正と性能改善の
両方が含まれるなら、それらは 2 つ以上のパッチに分けてください。
@@ -208,7 +208,7 @@ URL は禁止です。
ことがあります。途中でバグを持ち込めば、彼らに感謝されることは
ないでしょう。
-パッチセットをこれ以上小さくできないなら、一度に投稿するのは
+パッチセットをそれ以上小さくできないなら、一度に投稿するのは
15 個程度までにして、レビューと統合を待ってください。
@@ -220,18 +220,17 @@ Documentation/process/coding-style.rst を参照してください。
これを怠ると、単にレビューアの時間を無駄にするだけでなく、
パッチはおそらく読まれもせずに却下されます。
-大きな例外が 1 つあります。コードをあるファイルから別の
-ファイルへ移動する場合です。このときは、コードを移動する
-その同じパッチの中で、移動したコードを一切変更してはいけません。
-そうすることで、コードの移動という行為と、あなたの変更とを
-明確に区別できます。これは実際の差分のレビューを大いに助け、
-ツールがコード自体の履歴をより適切に追跡できるようにします。
+一つの重要な例外は、コードをあるファイルから別のファイルへ移動する場合です。
+その際は、コードを移動するその同じパッチの中で、一切コードを変更しては
+いけません。これにより、コードの移動という行為と、コードの変更とが
+明確に区別されます。これは実際の差分のレビューを大いに助け、また、ツールを
+使ったコード変更の履歴の追跡を容易にします。
提出前に、パッチスタイルチェッカー
(``scripts/checkpatch.pl``) でパッチを確認してください。
-ただし、スタイルチェッカーは指針として見るべきであり、
+ただし、スタイルチェッカーは指針にすぎず、
人間の判断に取って代わるものではないことに注意してください。
-違反があっても、その方がコードの見栄えがよいなら、
+違反が指摘されるままのコードの方が見栄えがよいなら、おそらく
そのままにしておくのが最善でしょう。
チェッカーは 3 つのレベルで報告します:
@@ -240,8 +239,7 @@ Documentation/process/coding-style.rst を参照してください。
- WARNING: 慎重なレビューを要するもの
- CHECK: 検討を要するもの
-パッチに残した違反については、すべて理由を説明できなければ
-なりません。
+パッチに違反を残す場合は、そのすべてを正当化できなければなりません。
パッチの宛先を選択する
@@ -256,8 +254,8 @@ Documentation/process/coding-style.rst を参照してください。
サブシステムのメンテナが見つからない場合は、Andrew Morton
(akpm@linux-foundation.org) が最後の手段となるメンテナです。
-すべてのパッチでは、デフォルトで linux-kernel@vger.kernel.org を
-使うべきですが、このリストの流量が多いため、目を通さなくなった
+すべてのパッチは、デフォルトで linux-kernel@vger.kernel.org にも
+送られるべきですが、このリストは流量が多く、目を通さなくなった
開発者も少なくありません。とはいえ、無関係なメーリングリストや
無関係な人々にスパムを送らないでください。
@@ -268,103 +266,104 @@ Documentation/process/coding-style.rst を参照してください。
Linux カーネルに採用されるすべての変更の最終的な裁定者は
Linus Torvalds です。彼のメールアドレスは
<torvalds@linux-foundation.org> です。Linus は大量のメールを
-受け取っており、現時点では彼に直接届くパッチはごくわずかなので、
-通常は彼にメールを送ることを極力避けてください。
+受け取っており、現時点では直接彼を経由するパッチはごくわずかなので、
+通常は彼にメールを送ることを極力\ **避けて**\ ください。
-悪用可能なセキュリティバグを修正するパッチがあるなら、
-そのパッチを security@kernel.org に送ってください。深刻なバグに
+悪用可能なセキュリティバグを修正するパッチの場合は、
+それを security@kernel.org に送ってください。深刻なバグに
ついては、ディストリビュータがユーザーにパッチを配布できるよう、
-短期間の embargo が検討される場合があります。そのような場合、
-そのパッチを公開メーリングリストに送るべきではありません。
+短期間の秘匿措置 (訳註: embargo) が検討される可能性があります。
+ですので、その種のパッチを公開メーリングリストに送らないでください。
Documentation/process/security-bugs.rst も参照してください。
リリース済みカーネルの深刻なバグを修正するパッチは、次のような行を
-パッチの sign-off 欄に入れることで、stable メンテナへ向けてください::
+パッチの sign-off 欄に入れることで、stable メンテナに知らせてください。
+(メールの宛先ではないことに注意。) ::
Cc: stable@vger.kernel.org
-これはメールの受信者ではないことに注意してください。また、
-この文書に加えて Documentation/process/stable-kernel-rules.rst も
-読んでください。
+また、この文書に加えて Documentation/process/stable-kernel-rules.rst
+も読んでください。
変更がユーザーランドとカーネルのインターフェースに影響する場合は、
MAINTAINERS ファイルに記載されている MAN-PAGES メンテナに
-man-pages パッチ、少なくとも変更の通知を送って、情報が
-マニュアルページに反映されるようにしてください。ユーザー空間 API の
+マニュアルページのパッチ、もしくは少なくとも変更の通知を送って、情報が
+そちらにも反映されるようにしてください。ユーザー空間 API の
変更は、linux-api@vger.kernel.org にも Cc してください。
MIME・リンク・圧縮・添付なし、プレーンテキストのみ
----------------------------------------------------
Linus や他のカーネル開発者は、あなたが投稿する変更を読み、
-コメントできる必要があります。カーネル開発者が標準的な
-メールツールを使ってあなたの変更を「引用」し、コードの特定の
-箇所についてコメントできることが重要です。
+コメントできる必要があります。カーネル開発者にとって、コードの特定の
+箇所について、標準的なメールツールを使ってあなたの変更を「引用」し、
+コメントできることが重要です。
-このため、すべてのパッチはメール本文中に ``inline`` で投稿すべきです。
+このため、すべてのパッチはメール本文中に「インライン」で投稿すべきです。
これを行う最も簡単な方法は ``git send-email`` を使うことであり、
強く推奨されます。``git send-email`` の対話型チュートリアルは
-https://git-send-email.io で利用できます。
+https://git-send-email.io にあります。
-``git send-email`` を使わないことを選ぶ場合:
+``git send-email`` を使わない場合:
.. warning::
- パッチをコピー＆ペーストする場合は、エディタの word-wrap によって
- パッチが壊れないよう注意してください。
+ パッチをコピー＆ペーストする際に、エディタによる自動改行で
+ パッチが壊されないよう注意してください。
圧縮の有無にかかわらず、パッチを MIME 添付ファイルとして添付しては
-いけません。多くの一般的なメールアプリケーションは、MIME 添付
-ファイルを常にプレーンテキストとして送信するとは限らず、あなたの
-コードにコメントできなくなります。MIME 添付ファイルは Linus が
-処理するのにも少し余分な時間がかかるため、MIME 添付された変更が
-受け入れられる可能性を下げます。
+いけません。よく使われるメールアプリケーションの多くは、MIME 添付
+ファイルをプレーンテキストとして送信するとは限らず、あなたのコードに
+対するコメントを妨げます。MIME 添付ファイルは Linus (訳補: をはじめ
+とする開発者）が処理するのに余分な手間がかかるため、MIME 添付すると
+その変更が受け入れられる可能性を下げることになります。
-例外: メーラがパッチを壊してしまう場合は、誰かから MIME を使って
-再送するよう求められることがあります。
+例外: パッチがメーラーによって壊されている場合に、MIME による再送
+を求められることがあります。
-パッチを変更せずに送信するようメールクライアントを設定するための
-ヒントについては、Documentation/process/email-clients.rst を参照してください。
+改変なしにパッチを送信するためのメールクライアント設定のヒントは、
+Documentation/process/email-clients.rst を参照してください。
-レビューコメントに返答する
+レビューコメントに応答する
--------------------------
-あなたのパッチには、ほぼ確実に、パッチを改善する方法について
-レビューアからコメントが付きます。それは、あなたのメールへの返信という
-形で届きます。それらのコメントには必ず返答してください。レビューアを
-無視することは、こちらも無視されるためのよい方法です。コメントに
-答えるには、単にそのメールへ返信すれば構いません。コード変更に
+あなたのパッチには、ほぼ確実に、その改善に向けてレビューアから
+コメントが付きます。それは、あなたのメールへの返信という
+形で届きます。それらのコメントには必ず応答してください。レビューアを
+無視することは、あなたが無視されることにつながります。コメントに
+答えるには、単にそのメールへ返信すればよいです。コード変更に
つながらないレビューコメントや質問であっても、次のレビューアが状況を
-よりよく理解できるように、ほぼ確実にコメントまたは changelog エントリに
-反映すべきです。
-
-どのような変更を行うのかをレビューアに必ず伝え、時間を割いてくれた
-ことに感謝してください。コードレビューは疲れる、時間のかかる作業であり、
-レビューアが不機嫌になることもあります。そのような場合であっても、
-丁寧に返答し、指摘された問題に対応してください。次の版を送るときは、
-cover letter または個々のパッチに ``patch changelog`` を追加し、前回の
+よりよく理解できるよう、多くの場合、コメントまたは changelog エントリ
+として残すべきです。
+
+どのような変更を行うのかを忘れずにレビューアに伝えてください。そして
+時間を割いてくれることへの感謝を忘れないでください。
+コードレビューは疲れる、時間のかかる作業であり、
+ときにはレビューアが機嫌を損ねることもあります。そのような場合でも、
+丁寧に応答し、指摘された問題に対応してください。次の版を送る際には、
+カバーレターまたは個々のパッチに ``patch changelog`` を追加し、前回の
投稿との差分を説明してください。詳細は原文の該当節
("The canonical patch format") を参照してください。
.. TODO: Convert to file-local cross-reference when the destination is
translated.
-あなたのパッチにコメントした人には、パッチの Cc リストに追加して、
-新しい版を知らせてください。
+あなたのパッチにコメントしてくれた人たちは、パッチの Cc リストに追加して
+新しい版について知らせてください。
メールクライアントとメーリングリストでの作法についての推奨事項は、
Documentation/process/email-clients.rst を参照してください。
-メール議論では不要な引用を削った interleaved replies を使う
-------------------------------------------------------------
+要点に絞ったインライン返信での議論
+---------------------------------------
-Linux カーネル開発の議論では、top-posting は強く非推奨とされています。
-Interleaved replies、または ``inline`` replies を使うと、会話の流れを
-ずっと追いやすくなります。詳細は次を参照してください:
+Linux カーネル開発の議論では、全文引用 (訳註: top-posting) は強く非推奨です。
+インライン返信 (訳註: interleaved reples or "inline" replies) を使うと、
+会話の流れをずっと追いやすくなります。詳細は次を参照してください:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
-メーリングリストでは、よく次のように引用されます::
+これについて、メーリングリストでは、次の引用をしばしば目にします::
A: http://en.wikipedia.org/wiki/Top_post
Q: Where do I find info about this thing called top-posting?
@@ -381,24 +380,25 @@ https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
Q: Should I include quotations after my reply?
-落胆しない、そして急がない
---------------------------
+落胆しない - いらいらしない
+---------------------------
変更を投稿した後は、辛抱強く待ってください。レビューアは忙しい人たちであり、
-あなたのパッチをすぐに見られるとは限りません。
+あなたのパッチにすぐに取りかかれるとは限りません。
かつては、パッチが何のコメントもなく虚空へ消えていくこともありましたが、
現在の開発プロセスはそれよりも円滑に機能しています。数週間以内、
通常は 2〜3 週間以内にコメントを受け取るはずです。そうならない場合は、
パッチを正しい場所へ送ったか確認してください。再投稿したりレビューアに
-ping したりする前に、少なくとも 1 週間は待ってください。merge window の
-ような忙しい時期には、さらに長く待つ方がよい場合もあります。
+ping したりする前に、少なくとも 1 週間は待ってください。マージ期間
+(訳註: merge window) のような忙しい時期には、さらに長く待ちましょう。
-数週間後に、subject line に "RESEND" を追加して、パッチまたは
-パッチシリーズを再送しても構いません::
+数週間後に、件名に "RESEND" を追加したパッチまたはパッチシリーズを
+再送することは構いません::
[PATCH Vx RESEND] sub/sys: Condensed patch summary
-パッチまたはパッチシリーズの修正版を投稿する場合は、"RESEND" を
-追加しないでください。"RESEND" は、前回の投稿から一切変更していない
-パッチまたはパッチシリーズを再送する場合にのみ使います。
+ただし、パッチまたはパッチシリーズの修正版を投稿する際には "RESEND"
+を追加しないでください。
+"RESEND" は、前回の投稿から一切変更のないパッチまたはパッチシリーズの
+再送だけに当てはまります。
base-commit: 4108b688d3a456ee1d04c15fa09bcd1cfa9bc425
--
2.43.0
^ permalink raw reply related
* Re: [PATCH RFC] coding-assistants: simplify attribution - WIPO recommendations also seem kind of worrying
From: Ellie @ 2026-07-15 12:11 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Christian Brauner, Linus Torvalds, Jonathan Corbet, Jens Axboe,
David Hildenbrand, Jeff Layton, Vlastimil Babka, workflows,
linux-doc, linux-kernel, linux-fsdevel
In-Reply-To: <20260703115852.GC3659451@killaraus.ideasonboard.com>
On 7/3/26 1:58 PM, Laurent Pinchart wrote:
> Your messages got completely ignored for a month and a half. Most
> developers (including myself) don't read LKML due to the high traffic,
> but I'm still surprised by the complete lack of reply. Maybe CC'ing the
> workflows@vger.kernel.org mailing list would have helped ?
Given the ongoing discussion I'm kind of wondering if it has been
noticed by now, I apologize if it has and I just missed it.
Sadly, my concerning finds keep piling up, e.g. here's the WIPO, World
Intellectual Property Organization, on what they recommend for AI:
https://www.wipo.int/publications/en/details.jsp?id=4713
Quote: "Consider using generative AI tools that have trained solely on
licensed, public domain, or a user's own training data. [...] Thoroughly
vet datasets when training or fine-tuning generative AI. Verify IP
ownership, license coverage for AI training, [...]"
I'm not a lawyer, so I could be wrong and this isn't legal advice:
But it seems to me like neither do the Linux Foundations guidelines seem
to be aware of this or adhere to this, nor does there seem to be a
single coding LLM available anywhere that fulfills these.
(Since wouldn't that require training data that is both GPL-relicensing
compatible and also doesn't require attribution? The latter I've never
seen with any coding LLM out there.)
I wonder if the Linux Foundation would find it interesting what the WIPO
says here, given how important the kernel is?
The angle of it just being a tool doesn't fully seem aware of such
concerns. At least when actual LLM code is added into the kernel.
(And at the same time, it's probably possible to make such a vetted LLM
if anybody wanted to. But that might require policies that enforce it.)
Regards,
Ellie
^ permalink raw reply
* Re: [PATCH printk 3/3] printk: Support setting console sync mode via console=
From: Petr Mladek @ 2026-07-15 12:23 UTC (permalink / raw)
To: John Ogness
Cc: Sergey Senozhatsky, Steven Rostedt, Andrew Murray, Chris Down,
linux-kernel, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260710144609.194487-4-john.ogness@linutronix.de>
On Fri 2026-07-10 16:51:53, John Ogness wrote:
> Extend the console= kernel command line argument to support specifying
> sync mode at boot time. This is achieved by introducing a new "sync"
> option that can be passed within a console= cmdline argument.
>
> For example, assuming the first serial device should be a console using
> sync mode:
>
> console=ttyS0,115200,sync
>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> Co-authored-by: Chris Down <chris@chrisdown.name>
Just for record, I guess that Chris Down is mentioned as a Co-author
because of the function find_and_remove_console_option() which seems
to be taken from
https://lore.kernel.org/all/d1cae00c839a3681759061e646f21a35b9b66613.1764272407.git.chris@chrisdown.name/
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2567,6 +2567,81 @@ static void set_user_specified(struct console_cmdline *c, bool user_specified)
> console_set_on_cmdline = 1;
> }
>
> +/**
> + * find_and_remove_console_option - Find and remove a named option from console options string
> + * @options: The console options string (will be modified in-place)
> + * @key: The option name to find (e.g., "loglevel")
> + * @val_buf: Buffer to store the option value (if present)
> + * @val_buf_size: Size of @val_buf
> + *
> + * This function searches for a named option in a comma-separated options string
> + * (e.g., "9600n8,loglevel:3,sync"). If found, it extracts the value
> + * (the part after ':') and removes the entire option from the string.
> + *
> + * If an option does not support values, @val_buf should be NULL, in which
> + * case no value part is extracted and any user provided ':' is considered part
> + * of the option key.
> + *
> + * The function modifies @options in-place by:
> + * 1. Temporarily null-terminating option names and values during parsing
> + * 2. Restoring separators if the option isn't found
> + * 3. Removing the found option by shifting the remaining string
> + *
> + * Return: true if the option was found and removed, false otherwise
> + */
> +static bool find_and_remove_console_option(char *options, const char *key,
> + char *val_buf, size_t val_buf_size)
> +{
> + bool found = false, first = true;
> + char *option, *next = options;
> +
> + while ((option = strsep(&next, ","))) {
Sashiko AI pointed out that add_preferred_console() is called also
by of_console_check() where the @options parameter is casted from
"const char *", see
https://sashiko.dev/#/patchset/20260710144609.194487-1-john.ogness%40linutronix.de
I believe that we should be on the safe side. Honestly, I did not
analyze it to the bottom. But the string "of_stdout_options":
+ must be '\0' terminated. So that it can't be part of a full memory dump
of the original device tree file. It must be a dedicated memory
entity which is accessed separately in some node tree, see
of_find_node_opts_by_path().
+ is used only by of_console_check(). So there should not be problem
with parallel access [*]
[*] of_console_check() is actually called from two locations:
serial_core_add_one_port() and sprd_uart_is_console(). So there
is some risk of parallelism.
On the other hand, it makes sense to add the console from
the device tree only once. And we would have bigger problems
when add_preferred_console() is called by mode CPUs in
parallel.
Sigh, I think that we could keep it because it should be good enough.
But I do not have 100% good feeling about it.
Second sigh, proper fix would need to either allocate a copy
or create some static buffer for options in struct console_cmdline
or so.
Or handle this a different way.
> + char *value = NULL;
> +
> + if (val_buf) {
> + value = strchr(option, ':');
> + if (value)
> + *(value++) = '\0';
> + }
> +
> + if (strcmp(option, key) == 0) {
> + found = true;
> + if (value) {
> + if (strlen(value) >= val_buf_size) {
> + pr_warn("Cannot copy console option value for %s:%s: not enough space (%zu)\n",
> + option, value, val_buf_size);
> + found = false;
> + } else {
> + strscpy(val_buf, value, val_buf_size);
> + }
> + } else if (val_buf) {
> + *val_buf = '\0';
> + }
> + }
> +
> + if (found)
> + break;
> +
> + if (next)
> + *(next - 1) = ',';
> + if (value)
> + *(value - 1) = ':';
> +
> + first = false;
> + }
> +
> + if (found) {
> + if (next)
> + memmove(option, next, strlen(next) + 1);
> + else if (first)
> + *option = '\0';
Sashiko AI also pointed out that this would create an empty string.
For example, serial8250_console_setup() checks only whether it is NULL
and tries to read the baudate, ...
Sigh, the handling of the console parameters is yet another historic
mess which would deserve a clean up. I'll add this to my TODO
in the console registration clean up. But I think that it is beyond
the scope of this patch set.
Well, we should stay conservative and set options to NULL in this case.
> + else
> + *--option = '\0';
> + }
> +
> + return found;
> +}
> +
> static int __add_preferred_console(const char *name, const short idx,
> const char *devname, char *options,
> char *brl_options, bool user_specified)
Otherwise, it looks good to me.
Best Regards,
Petr
^ 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