hwmon: add Altera SoC FPGA hardware monitoring support

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The async service layer is torn down before the child platform devices (HWMON and RSU) are unregistered, leading to a Use-After-Free and NULL pointer dereference if a concurrent async call is made. --

commit 2c6317a7aef89428e616ea8354fab157b27ff35f
Author: Tze Yee Ng <[email protected]>

firmware: stratix10-svc: add async HWMON read commands and register socfpga-hwmon device

Add asynchronous Stratix 10 service layer support for hardware monitor temperature and voltage read commands. Register a socfpga-hwmon platform device when hardware monitor support is enabled.

Quoted 4 lines

drivers/firmware/stratix10-svc.c +0 -0

index c24ca5823078f..716b58f5a6170 100644

[ ... ]

drivers/firmware/stratix10-svc.c static void stratix10_svc_drv_remove(struct platform_device *pdev) · line 2092

Quoted 7 lines

drivers/firmware/stratix10-svc.c +3 -0

@@ -2050,6 +2087,9 @@ static void stratix10_svc_drv_remove(struct platform_device *pdev)
 
  	of_platform_depopulate(ctrl->dev);
 
+	if (svc->stratix10_svc_hwmon)
+		platform_device_unregister(svc->stratix10_svc_hwmon);
+

[Severity: High]
This is a pre-existing issue, but does unregistering the child devices here introduce a race condition with module removal?

In stratix10_svc_drv_remove(), we tear down the async service layer before the child devices are unregistered:

	stratix10_svc_async_exit(ctrl);
	of_platform_depopulate(ctrl->dev);
	if (svc->stratix10_svc_hwmon)
		platform_device_unregister(svc->stratix10_svc_hwmon);

If a sysfs read for the hwmon device (e.g., temp1_input) races with module unload, could it proceed to stratix10_svc_async_send() because the device is not yet unregistered?

If so, it looks like stratix10_svc_async_send() will dereference the achan structure that was already freed:

	ret = ida_alloc_max(&achan->job_id_pool, MAX_SDM_JOB_IDS,
			    GFP_KERNEL);

And later attempt a NULL pointer dereference, as actrl->invoke_fn was set to NULL by stratix10_svc_async_exit():

	actrl->invoke_fn(actrl, &args, &res);

Should the child platform devices be unregistered before stratix10_svc_async_exit() is called?

Quoted 3 lines

drivers/firmware/stratix10-svc.c +0 -0

  	platform_device_unregister(svc->stratix10_svc_rsu);
 
  	for (i = 0; i < SVC_NUM_CHANNEL; i++) {

Quoted 52 lines · On 3/7/2026 4:19 pm, [email protected] wrote:

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The async service layer is torn down before the child platform devices (HWMON and RSU) are unregistered, leading to a Use-After-Free and NULL pointer dereference if a concurrent async call is made. --

commit 2c6317a7aef89428e616ea8354fab157b27ff35f
Author: Tze Yee Ng <[email protected]>

firmware: stratix10-svc: add async HWMON read commands and register socfpga-hwmon device

Add asynchronous Stratix 10 service layer support for hardware monitor temperature and voltage read commands. Register a socfpga-hwmon platform device when hardware monitor support is enabled.

Quoted 4 lines

drivers/firmware/stratix10-svc.c +0 -0

index c24ca5823078f..716b58f5a6170 100644

[ ... ]

drivers/firmware/stratix10-svc.c static void stratix10_svc_drv_remove(struct platform_device *pdev) · line 2092

Quoted 7 lines

drivers/firmware/stratix10-svc.c +3 -0

@@ -2050,6 +2087,9 @@ static void stratix10_svc_drv_remove(struct platform_device *pdev)
 
   	of_platform_depopulate(ctrl->dev);
 
+	if (svc->stratix10_svc_hwmon)
+		platform_device_unregister(svc->stratix10_svc_hwmon);
+

[Severity: High]
This is a pre-existing issue, but does unregistering the child devices here introduce a race condition with module removal?

In stratix10_svc_drv_remove(), we tear down the async service layer before the child devices are unregistered:

	stratix10_svc_async_exit(ctrl);
	of_platform_depopulate(ctrl->dev);
	if (svc->stratix10_svc_hwmon)
		platform_device_unregister(svc->stratix10_svc_hwmon);

If a sysfs read for the hwmon device (e.g., temp1_input) races with module unload, could it proceed to stratix10_svc_async_send() because the device is not yet unregistered?

If so, it looks like stratix10_svc_async_send() will dereference the achan structure that was already freed:

	ret = ida_alloc_max(&achan->job_id_pool, MAX_SDM_JOB_IDS,
			    GFP_KERNEL);

Quoted 12 lines

And later attempt a NULL pointer dereference, as actrl->invoke_fn was set to NULL by stratix10_svc_async_exit():

	actrl->invoke_fn(actrl, &args, &res);

Should the child platform devices be unregistered before stratix10_svc_async_exit() is called?

Quoted 3 lines

drivers/firmware/stratix10-svc.c +0 -0

   	platform_device_unregister(svc->stratix10_svc_rsu);
 
   	for (i = 0; i < SVC_NUM_CHANNEL; i++) {

Hi,

Agreed with Sashiko's comment. In stratix10_svc_drv_remove(), stratix10_svc_async_exit() currently runs before the hwmon and RSU platform devices are unregistered. A concurrent sysfs read could still reach stratix10_svc_async_send() and use resources already torn down by stratix10_svc_async_exit().

This ordering predates the hwmon registration in this series; RSU follows the same pattern today. The fix would be to unregister child platform devices (and depopulate) before calling stratix10_svc_async_exit().

We can include that reorder in this series, or send it as a separate stratix10-svc fix.

Quoted 89 lines · TZE YEE

Quoted 74 lines · On 3/7/2026 4:19 pm, [email protected] wrote:

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The async service layer is torn down before the child platform devices (HWMON and RSU) are unregistered, leading to a Use- After-Free and NULL pointer dereference if a concurrent async call is made.

Signature · 9 lines

commit 2c6317a7aef89428e616ea8354fab157b27ff35f
Author: Tze Yee Ng <[email protected]>

firmware: stratix10-svc: add async HWMON read commands and register 
socfpga-hwmon device

Add asynchronous Stratix 10 service layer support for hardware monitor
temperature and voltage read commands. Register a socfpga-hwmon platform
device when hardware monitor support is enabled.

Quoted 5 lines

drivers/firmware/ renamed from drivers/firmware/stratix10-svc.c +0 -0

stratix10-svc.c
index c24ca5823078f..716b58f5a6170 100644

drivers/firmware/stratix10-svc.c +0 -0

[ ... ]

drivers/firmware/stratix10-svc.c static void stratix10_svc_drv_remove(struct · line 2091

Quoted 6 lines

drivers/firmware/stratix10-svc.c +3 -0

@@ -2050,6 +2087,9 @@ static void stratix10_svc_drv_remove(struct 
 platform_device *pdev)
        of_platform_depopulate(ctrl->dev);
+    if (svc->stratix10_svc_hwmon)
+        platform_device_unregister(svc->stratix10_svc_hwmon);
+

[Severity: High]
This is a pre-existing issue, but does unregistering the child devices here
introduce a race condition with module removal?

In stratix10_svc_drv_remove(), we tear down the async service layer before
the child devices are unregistered:

    stratix10_svc_async_exit(ctrl); of_platform_depopulate(ctrl->dev);
    if (svc->stratix10_svc_hwmon) platform_device_unregister(svc->stratix10_svc_hwmon);

If a sysfs read for the hwmon device (e.g., temp1_input) races with module
unload, could it proceed to stratix10_svc_async_send() because the device
is not yet unregistered?

If so, it looks like stratix10_svc_async_send() will dereference the achan
structure that was already freed:

    ret = ida_alloc_max(&achan->job_id_pool, MAX_SDM_JOB_IDS, GFP_KERNEL);

And later attempt a NULL pointer dereference, as actrl->invoke_fn was set
to NULL by stratix10_svc_async_exit():

    actrl->invoke_fn(actrl, &args, &res);

Should the child platform devices be unregistered before stratix10_svc_async_exit() is called?

Quoted 2 lines

drivers/firmware/stratix10-svc.c +0 -0

        platform_device_unregister(svc->stratix10_svc_rsu);
        for (i = 0; i < SVC_NUM_CHANNEL; i++) {

Hi,

Agreed with Sashiko's comment. In stratix10_svc_drv_remove(), stratix10_svc_async_exit() currently runs before the hwmon and RSU platform devices are unregistered. A concurrent sysfs read could still reach stratix10_svc_async_send() and use resources already torn down by stratix10_svc_async_exit().

This ordering predates the hwmon registration in this series; RSU follows the same pattern today. The fix would be to unregister child platform devices (and depopulate) before calling stratix10_svc_async_exit().

Quoted 3 lines

We can include that reorder in this series, or send it as a separate stratix10-svc fix.

Please send that as a separate fix.

Thanks,
Dinh

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incorrect devm registration order causes a Use-After-Free vulnerability during device unbind or probe failure.
- [Medium] Unreferenced completion causes a guaranteed maximum timeout delay on every asynchronous sensor read. --

commit 9e088a070299b309352aa9a88006e3927d0c50bd
Author: Tze Yee Ng <[email protected]>

hwmon: add Altera SoC FPGA hardware monitoring driver

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.

Quoted 4 lines

drivers/hwmon/socfpga-hwmon.c new file +0 -0

new file mode 100644

[ ... ]

Quoted 24 lines

drivers/hwmon/socfpga-hwmon.c new file +24 -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 = {};
+	struct completion completion;
+	unsigned long wait_ret;
+	void *handle = NULL;
+	int status, index, ret;
+
+	init_completion(&completion);
+
+	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", status);
+		msleep(HWMON_RETRY_SLEEP_MS);
+	}
+
+	if (status && !handle) {
+		dev_err(dev, "Failed to send async message after %u retries: %d\n",

drivers/hwmon/socfpga-hwmon.c line 219

Quoted 10 lines

drivers/hwmon/socfpga-hwmon.c new file +10 -0

+			HWMON_ASYNC_MSG_RETRY, status);
+		return status;
+	}
+
+	/*
+	 * The service layer never invokes the async callback, but wait
+	 * before polling anyway: RSU uses the same pattern and the firmware
+	 * needs time to complete the transaction after async_send().
+	 */
+	wait_ret = wait_for_completion_io_timeout(&completion, HWMON_TIMEOUT);

[Severity: Medium]
Will this cause a guaranteed timeout delay on every sensor read?

In socfpga_hwmon_async_read(), a local completion is initialized but is never passed to any asynchronous function or callback (the function stratix10_svc_async_send() receives NULL for the callback).

Because the completion can never be signaled, the execution will unconditionally block in an uninterruptible sleep for the entire HWMON_TIMEOUT duration on every single sensor read. Only after this maximum timeout expires does the function proceed to poll for the response.

Quoted 2 lines

drivers/hwmon/socfpga-hwmon.c new file +2 -0

+	if (wait_ret > 0)
+		dev_dbg(dev, "Received async interrupt\n");

[ ... ]

Quoted 2 lines

drivers/hwmon/socfpga-hwmon.c new file +2 -0

+static int socfpga_hwmon_probe(struct platform_device *pdev)
+{

[ ... ]

drivers/hwmon/socfpga-hwmon.c line 577

Quoted 12 lines

drivers/hwmon/socfpga-hwmon.c new file +12 -0

+	hwmon_dev = devm_hwmon_device_register_with_info(dev, "socfpga_hwmon",
+							 priv,
+							 &socfpga_hwmon_chip_info,
+							 NULL);
+	if (IS_ERR(hwmon_dev)) {
+		if (priv->async)
+			stratix10_svc_remove_async_client(priv->chan);
+		stratix10_svc_free_channel(priv->chan);
+		return PTR_ERR(hwmon_dev);
+	}
+
+	ret = devm_add_action_or_reset(dev, socfpga_hwmon_release_svc, priv);

[Severity: High]
Does this devres registration order create a use-after-free vulnerability during device unbind?

In socfpga_hwmon_probe(), the hwmon device is registered via devm_hwmon_device_register_with_info() before the cleanup action socfpga_hwmon_release_svc is added via devm_add_action_or_reset().

Because devres unwinds actions in reverse order of addition (LIFO), upon device unbind, socfpga_hwmon_release_svc will execute first, freeing the service layer channel (priv->chan).

However, the hwmon device will still be active and its sysfs attributes accessible to user space during this time. A concurrent sysfs read can invoke socfpga_hwmon_read(), which will attempt to use the already-freed priv->chan, resulting in a use-after-free.

drivers/hwmon/socfpga-hwmon.c line 583

Quoted 6 lines

drivers/hwmon/socfpga-hwmon.c new file +6 -0

+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, priv);
+	return 0;
+}

Quoted 102 lines · On 3/7/2026 4:18 pm, [email protected] wrote:

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incorrect devm registration order causes a Use-After-Free vulnerability during device unbind or probe failure.
- [Medium] Unreferenced completion causes a guaranteed maximum timeout delay on every asynchronous sensor read. --

commit 9e088a070299b309352aa9a88006e3927d0c50bd
Author: Tze Yee Ng <[email protected]>

hwmon: add Altera SoC FPGA hardware monitoring driver

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.

Quoted 4 lines

drivers/hwmon/socfpga-hwmon.c new file +0 -0

new file mode 100644

[ ... ]

Quoted 24 lines

drivers/hwmon/socfpga-hwmon.c new file +24 -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 = {};
+	struct completion completion;
+	unsigned long wait_ret;
+	void *handle = NULL;
+	int status, index, ret;
+
+	init_completion(&completion);
+
+	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", status);
+		msleep(HWMON_RETRY_SLEEP_MS);
+	}
+
+	if (status && !handle) {
+		dev_err(dev, "Failed to send async message after %u retries: %d\n",

drivers/hwmon/socfpga-hwmon.c line 219

Quoted 10 lines

drivers/hwmon/socfpga-hwmon.c new file +10 -0

+			HWMON_ASYNC_MSG_RETRY, status);
+		return status;
+	}
+
+	/*
+	 * The service layer never invokes the async callback, but wait
+	 * before polling anyway: RSU uses the same pattern and the firmware
+	 * needs time to complete the transaction after async_send().
+	 */
+	wait_ret = wait_for_completion_io_timeout(&completion, HWMON_TIMEOUT);

[Severity: Medium]
Will this cause a guaranteed timeout delay on every sensor read?

In socfpga_hwmon_async_read(), a local completion is initialized but is never passed to any asynchronous function or callback (the function stratix10_svc_async_send() receives NULL for the callback).

Because the completion can never be signaled, the execution will unconditionally block in an uninterruptible sleep for the entire HWMON_TIMEOUT duration on every single sensor read. Only after this maximum timeout expires does the function proceed to poll for the response.

Quoted 2 lines

drivers/hwmon/socfpga-hwmon.c new file +2 -0

+	if (wait_ret > 0)
+		dev_dbg(dev, "Received async interrupt\n");

[ ... ]

Quoted 2 lines

drivers/hwmon/socfpga-hwmon.c new file +2 -0

+static int socfpga_hwmon_probe(struct platform_device *pdev)
+{

[ ... ]

drivers/hwmon/socfpga-hwmon.c line 577

Quoted 12 lines

drivers/hwmon/socfpga-hwmon.c new file +12 -0

+	hwmon_dev = devm_hwmon_device_register_with_info(dev, "socfpga_hwmon",
+							 priv,
+							 &socfpga_hwmon_chip_info,
+							 NULL);
+	if (IS_ERR(hwmon_dev)) {
+		if (priv->async)
+			stratix10_svc_remove_async_client(priv->chan);
+		stratix10_svc_free_channel(priv->chan);
+		return PTR_ERR(hwmon_dev);
+	}
+
+	ret = devm_add_action_or_reset(dev, socfpga_hwmon_release_svc, priv);

[Severity: High]
Does this devres registration order create a use-after-free vulnerability during device unbind?

In socfpga_hwmon_probe(), the hwmon device is registered via devm_hwmon_device_register_with_info() before the cleanup action socfpga_hwmon_release_svc is added via devm_add_action_or_reset().

Because devres unwinds actions in reverse order of addition (LIFO), upon device unbind, socfpga_hwmon_release_svc will execute first, freeing the service layer channel (priv->chan).

However, the hwmon device will still be active and its sysfs attributes accessible to user space during this time. A concurrent sysfs read can invoke socfpga_hwmon_read(), which will attempt to use the already-freed priv->chan, resulting in a use-after-free.

Quoted 7 lines

drivers/hwmon/socfpga-hwmon.c line 583

Quoted 6 lines

drivers/hwmon/socfpga-hwmon.c new file +6 -0

+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, priv);
+	return 0;
+}

Hi maintainers,

1. [High] Incorrect devm registration order causes a Use-After-Free vulnerability during device unbind or probe failure.

Agreed. v4 will register devm_add_action_or_reset() before devm_hwmon_device_register_with_info(), matching other hwmon drivers (e.g. pwm-fan, qnap-mcu-hwmon). On hwmon registration failure, probe returns and devm runs the release action automatically, so manual channel cleanup on that path is no longer needed.

2. [Medium] Unreferenced completion causes a guaranteed maximum timeout delay on every asynchronous sensor read.

Agreed that the completion is never signaled because the service layer does not invoke the async callback. rsu_send_async_msg() in stratix10-rsu.c uses the same send → wait → poll pattern, so we followed RSU for consistency with the existing Stratix 10 async SVC client.

Quoted 134 lines · TZE YEE

Quoted 121 lines · On 3/7/2026 4:18 pm, [email protected] wrote:

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incorrect devm registration order causes a Use-After-Free vulnerability during device unbind or probe failure.
- [Medium] Unreferenced completion causes a guaranteed maximum timeout delay on every asynchronous sensor read.

Signature · 9 lines

commit 9e088a070299b309352aa9a88006e3927d0c50bd
Author: Tze Yee Ng <[email protected]>

hwmon: add Altera SoC FPGA hardware monitoring driver

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.

Quoted 5 lines

drivers/hwmon/socfpga- renamed from drivers/hwmon/socfpga-hwmon.c +0 -0

hwmon.c
new file mode 100644

drivers/hwmon/socfpga-hwmon.c new file +0 -0

[ ... ]

Quoted 29 lines

drivers/hwmon/socfpga-hwmon.c new file +24 -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 = {};
+    struct completion completion;
+    unsigned long wait_ret;
+    void *handle = NULL;
+    int status, index, ret;
+
+    init_completion(&completion);
+
+    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", 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;
+    }
+

Quoted 8 lines

+    /*
+     * The service layer never invokes the async callback, but wait +     * before polling anyway: RSU uses the same pattern and the firmware
+     * needs time to complete the transaction after async_send(). +     */
+    wait_ret = wait_for_completion_io_timeout(&completion, HWMON_TIMEOUT);

[Severity: Medium]
Will this cause a guaranteed timeout delay on every sensor read?

In socfpga_hwmon_async_read(), a local completion is initialized but is never passed to any asynchronous function or callback (the function stratix10_svc_async_send() receives NULL for the callback).

Because the completion can never be signaled, the execution will unconditionally block in an uninterruptible sleep for the entire HWMON_TIMEOUT duration on every single sensor read. Only after this maximum
timeout expires does the function proceed to poll for the response.

Quoted 2 lines

+    if (wait_ret > 0)
+        dev_dbg(dev, "Received async interrupt\n");

[ ... ]

Quoted 2 lines

drivers/hwmon/socfpga-hwmon.c new file +2 -0

+static int socfpga_hwmon_probe(struct platform_device *pdev)
+{

[ ... ]

Quoted 6 lines

+    hwmon_dev = devm_hwmon_device_register_with_info(dev, "socfpga_hwmon",
+                             priv,
+                             &socfpga_hwmon_chip_info, +                             NULL);
+    if (IS_ERR(hwmon_dev)) {

Quoted 8 lines

+        if (priv->async)
+            stratix10_svc_remove_async_client(priv->chan); +        stratix10_svc_free_channel(priv->chan);
+        return PTR_ERR(hwmon_dev);
+    }
+
+    ret = devm_add_action_or_reset(dev, socfpga_hwmon_release_svc, priv);

[Severity: High]
Does this devres registration order create a use-after-free vulnerability
during device unbind?

In socfpga_hwmon_probe(), the hwmon device is registered via devm_hwmon_device_register_with_info() before the cleanup action socfpga_hwmon_release_svc is added via devm_add_action_or_reset().

Because devres unwinds actions in reverse order of addition (LIFO), upon device unbind, socfpga_hwmon_release_svc will execute first, freeing the service layer channel (priv->chan).

However, the hwmon device will still be active and its sysfs attributes accessible to user space during this time. A concurrent sysfs read can invoke socfpga_hwmon_read(), which will attempt to use the already-freed priv->chan, resulting in a use-after-free.

drivers/hwmon/socfpga-hwmon.c line 583

Quoted 6 lines

+    if (ret)
+        return ret;

drivers/hwmon/socfpga-hwmon.c new file +4 -0

+
+    platform_set_drvdata(pdev, priv);
+    return 0;
+}

Hi maintainers,

1. [High] Incorrect devm registration order causes a Use-After-Free vulnerability during device unbind or probe failure.

Agreed. v4 will register devm_add_action_or_reset() before devm_hwmon_device_register_with_info(), matching other hwmon drivers (e.g. pwm-fan, qnap-mcu-hwmon). On hwmon registration failure, probe returns and devm runs the release action automatically, so manual channel cleanup on that path is no longer needed.

Quoted 8 lines

2. [Medium] Unreferenced completion causes a guaranteed maximum timeout delay on every asynchronous sensor read.

Agreed that the completion is never signaled because the service layer does not invoke the async callback. rsu_send_async_msg() in stratix10-rsu.c uses the same send → wait → poll pattern, so we followed RSU for consistency with the existing Stratix 10 async SVC client.

Sorry, I am not willing to accept the "other code is buggy, therefore it is ok to introduce the same bug here" argument (Is that some new trend ? I hear it so often lately that I am getting tired of it). You'll have to provide a better argument explaining why it would make sense to call wait_for_completion_io_timeout() if it is known to always time out. You might as well just call usleep_range() or similar; while that would still be bad code, at least it would not be misleading. Just add a comment explaining the reason when you do that.

Guenter