Stop processing hid input when registering the RTC fails and handle
a NULL returned from devm_rtc_device_register() as a failure too.
Signed-off-by: Alexander Holler <[email protected]>
---
drivers/rtc/rtc-hid-sensor-time.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-hid-sensor-time.c b/drivers/rtc/rtc-hid-sensor-time.c
index 7273b01..1ab3d13 100644
--- a/drivers/rtc/rtc-hid-sensor-time.c
+++ b/drivers/rtc/rtc-hid-sensor-time.c
@@ -283,9 +283,11 @@ static int hid_time_probe(struct platform_device *pdev)
"hid-sensor-time", &hid_time_rtc_ops,
THIS_MODULE);
- if (IS_ERR(time_state->rtc)) {
+ if (IS_ERR_OR_NULL(time_state->rtc)) {
+ ret = time_state->rtc ? PTR_ERR(time_state->rtc) : -ENODEV;
+ time_state->rtc = NULL;
+ sensor_hub_remove_callback(hsdev, HID_USAGE_SENSOR_TIME);
dev_err(&pdev->dev, "rtc device register failed!\n");
- return PTR_ERR(time_state->rtc);
}
return ret;
--
1.8.1.4
Enable the processing of HID input records before the RTC will be registered,
in order to allow the RTC register function to read clock. Without doing
that the clock can only be read after the probe function has finished.
Signed-off-by: Alexander Holler <[email protected]>
---
drivers/rtc/rtc-hid-sensor-time.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/rtc/rtc-hid-sensor-time.c b/drivers/rtc/rtc-hid-sensor-time.c
index 1ab3d13..1006a62 100644
--- a/drivers/rtc/rtc-hid-sensor-time.c
+++ b/drivers/rtc/rtc-hid-sensor-time.c
@@ -279,11 +279,18 @@ static int hid_time_probe(struct platform_device *pdev)
return ret;
}
+ /*
+ * Enable HID input processing early in order to be able to read the
+ * clock already in devm_rtc_device_register().
+ */
+ hid_device_io_start(hsdev->hdev);
+
time_state->rtc = devm_rtc_device_register(&pdev->dev,
"hid-sensor-time", &hid_time_rtc_ops,
THIS_MODULE);
if (IS_ERR_OR_NULL(time_state->rtc)) {
+ hid_device_io_stop(hsdev->hdev);
ret = time_state->rtc ? PTR_ERR(time_state->rtc) : -ENODEV;
time_state->rtc = NULL;
sensor_hub_remove_callback(hsdev, HID_USAGE_SENSOR_TIME);
--
1.8.1.4
On Thu, 1 Aug 2013 20:39:02 +0200 Alexander Holler <[email protected]> wrote:
> Enable the processing of HID input records before the RTC will be registered,
> in order to allow the RTC register function to read clock. Without doing
> that the clock can only be read after the probe function has finished.
>
> Signed-off-by: Alexander Holler <[email protected]>
> ---
> drivers/rtc/rtc-hid-sensor-time.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/rtc/rtc-hid-sensor-time.c b/drivers/rtc/rtc-hid-sensor-time.c
> index 1ab3d13..1006a62 100644
> --- a/drivers/rtc/rtc-hid-sensor-time.c
> +++ b/drivers/rtc/rtc-hid-sensor-time.c
> @@ -279,11 +279,18 @@ static int hid_time_probe(struct platform_device *pdev)
> return ret;
> }
>
> + /*
> + * Enable HID input processing early in order to be able to read the
> + * clock already in devm_rtc_device_register().
> + */
> + hid_device_io_start(hsdev->hdev);
> +
> time_state->rtc = devm_rtc_device_register(&pdev->dev,
> "hid-sensor-time", &hid_time_rtc_ops,
> THIS_MODULE);
>
> if (IS_ERR_OR_NULL(time_state->rtc)) {
> + hid_device_io_stop(hsdev->hdev);
> ret = time_state->rtc ? PTR_ERR(time_state->rtc) : -ENODEV;
> time_state->rtc = NULL;
> sensor_hub_remove_callback(hsdev, HID_USAGE_SENSOR_TIME);
Shouldn't now there be a hid_device_io_stop() in hid_time_remove()?
Also, hid_device_io_start() does a weird up() on a
downed-by-someone-else semaphore. Where was that down() performed in
this case?
Also, your changelog implies that the kernel is already doing this
hid_device_io_start(), only it does it too late. If that is the case
then will the existing-before-this-patch call to hid_device_io_start()
generate the "io already started" warning?
Am 09.08.2013 00:11, schrieb Andrew Morton:
> On Thu, 1 Aug 2013 20:39:02 +0200 Alexander Holler <[email protected]> wrote:
>
>> Enable the processing of HID input records before the RTC will be registered,
>> in order to allow the RTC register function to read clock. Without doing
>> that the clock can only be read after the probe function has finished.
>>
>> Signed-off-by: Alexander Holler <[email protected]>
>> ---
>> drivers/rtc/rtc-hid-sensor-time.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/rtc/rtc-hid-sensor-time.c b/drivers/rtc/rtc-hid-sensor-time.c
>> index 1ab3d13..1006a62 100644
>> --- a/drivers/rtc/rtc-hid-sensor-time.c
>> +++ b/drivers/rtc/rtc-hid-sensor-time.c
>> @@ -279,11 +279,18 @@ static int hid_time_probe(struct platform_device *pdev)
>> return ret;
>> }
>>
>> + /*
>> + * Enable HID input processing early in order to be able to read the
>> + * clock already in devm_rtc_device_register().
>> + */
>> + hid_device_io_start(hsdev->hdev);
>> +
>> time_state->rtc = devm_rtc_device_register(&pdev->dev,
>> "hid-sensor-time", &hid_time_rtc_ops,
>> THIS_MODULE);
>>
>> if (IS_ERR_OR_NULL(time_state->rtc)) {
>> + hid_device_io_stop(hsdev->hdev);
>> ret = time_state->rtc ? PTR_ERR(time_state->rtc) : -ENODEV;
>> time_state->rtc = NULL;
>> sensor_hub_remove_callback(hsdev, HID_USAGE_SENSOR_TIME);
>
> Shouldn't now there be a hid_device_io_stop() in hid_time_remove()?
That isn't how I understood the commit message to commit
c849a6143bec520aff2a6646518b0d041402428b which introduced that
functionality in 3.10. But maybe I'm wrong. I haven't looked at the
underlying code and haven't tested that (very unlikely) error path with
the new change I made.
> Also, hid_device_io_start() does a weird up() on a
> downed-by-someone-else semaphore. Where was that down() performed in
> this case?
Uh, don't know, as already said, I haven't looked at the underlying
code. But I will now do and will enable all mutex/semaphore debug
options I find. I have to admit, I didn't have tested the change with
debug options enabled, so if the kernel doesn't cry on wierd uo()'s
without debug options enabled, I would have missed that.
> Also, your changelog implies that the kernel is already doing this
> hid_device_io_start(), only it does it too late. If that is the case
> then will the existing-before-this-patch call to hid_device_io_start()
> generate the "io already started" warning?
No, hid_device_io_start() was introduced especially for such cases. I
need it because devm_rtc_device_register() might want to read the clock,
but without hid_device_io_start() that only is possible after probe
finished (therefor not during devm_rtc_device_register()).
Some time later ...
With several debug options enabled I've got (once) the below backtrace
with the error path enabled (time_state->rtc = NULL instead of
time_state->rtc = rtc_device_register()).
[ 8.007975] rtc_hid_sensor_time HID-SENSOR-2000a0.0: milliseconds
supported
[ 8.015499] rtc_hid_sensor_time HID-SENSOR-2000a0.0: rtc device
register failed!
(...)
[ 65.551939] =================================
[ 65.556343] [ INFO: inconsistent lock state ]
To add some more explanations for the trace (below in full without
times): The device I use does send the time around once every minute as
an hid input report and this just might have happened here, causing the
lock warning. What makes me wonder here is that hid-sensor-hub seems to
receive the input report even after hid_device_io_stop() was called and
the probe function for the hid device in question (rtc-hid-sensor-time)
failed with a rc of -ENODEV.
I've added the HID maintainer and the author of the above mentioned
commit to cc.
I will need some time (hopefully this weekend) to have a deeper look at
what goes wrong there. Unfortunatley rtc-hid-sensor-time currently seems
to be the only user of hid_device_io_stop(), so I might have hit a bug
or did use it wrong.
But nevertheless, the non-error-path does work as expected, at least I
haven't seen a problem until now.
Regards,
Alexander Holler
----------
=================================
[ INFO: inconsistent lock state ]
3.10.5-dockstar-00038-g03242d1-dirty #408 Not tainted
---------------------------------
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&(&sd->dyn_callback_lock)->rlock){?.+...}, at: [<c02af9f8>]
sensor_hub_raw_event+0x10c/0x204
{HARDIRQ-ON-W} state was registered at:
[<c004dba0>] __lock_acquire+0x630/0x18f0
[<c004f31c>] lock_acquire+0x64/0x78
[<c039c960>] _raw_spin_lock+0x40/0x50
[<c02af854>] sensor_hub_register_callback+0x2c/0xc4
[<c029ce1c>] hid_time_probe+0x2f8/0x36c
[<c0234c98>] platform_drv_probe+0x14/0x18
[<c0233d48>] driver_probe_device+0xb4/0x210
[<c023243c>] bus_for_each_drv+0x48/0x8c
[<c0233c50>] device_attach+0x68/0x8c
[<c02332a8>] bus_probe_device+0x28/0xa0
[<c0231a84>] device_add+0x3d8/0x594
[<c0235064>] platform_device_add+0x130/0x1c0
[<c023ca50>] mfd_add_device+0x1d0/0x23c
[<c023cc38>] mfd_add_devices+0x7c/0xac
[<c02afeec>] sensor_hub_probe+0x2a0/0x364
[<c02aa614>] hid_device_probe+0x90/0x128
[<c0233d48>] driver_probe_device+0xb4/0x210
[<c023243c>] bus_for_each_drv+0x48/0x8c
[<c0233c50>] device_attach+0x68/0x8c
[<c02332a8>] bus_probe_device+0x28/0xa0
[<c0231a84>] device_add+0x3d8/0x594
[<c02aa28c>] hid_add_device+0x244/0x29c
[<c02b1f10>] usbhid_probe+0x368/0x448
[<c027bc14>] usb_probe_interface+0x13c/0x1e0
[<c0233d48>] driver_probe_device+0xb4/0x210
[<c023243c>] bus_for_each_drv+0x48/0x8c
[<c0233c50>] device_attach+0x68/0x8c
[<c02332a8>] bus_probe_device+0x28/0xa0
[<c0231a84>] device_add+0x3d8/0x594
[<c027a45c>] usb_set_configuration+0x610/0x6bc
[<c02821d4>] generic_probe+0x3c/0x74
[<c027bcdc>] usb_probe_device+0x24/0x3c
[<c0233d48>] driver_probe_device+0xb4/0x210
[<c023243c>] bus_for_each_drv+0x48/0x8c
[<c0233c50>] device_attach+0x68/0x8c
[<c02332a8>] bus_probe_device+0x28/0xa0
[<c0231a84>] device_add+0x3d8/0x594
[<c0272c04>] usb_new_device+0x1dc/0x304
[<c0274050>] hub_thread+0x9c4/0xf70
[<c0034600>] kthread+0xa0/0xb0
[<c00090a0>] ret_from_fork+0x14/0x34
irq event stamp: 139814
hardirqs last enabled at (139811): [<c02a24e8>]
cpuidle_enter_state+0x50/0x100
hardirqs last disabled at (139812): [<c0008b74>] __irq_svc+0x34/0xa0
softirqs last enabled at (139814): [<c001d9c8>] irq_enter+0x44/0x64
softirqs last disabled at (139813): [<c001d9bc>] irq_enter+0x38/0x64
might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&sd->dyn_callback_lock)->rlock);
<Interrupt>
lock(&(&sd->dyn_callback_lock)->rlock);
**
1 lock held by swapper/0:
#0: (&(&sd->lock)->rlock){-.....}, at: [<c02af92c>]
sensor_hub_raw_event+0x40/0x204
:
CPU: 0 PID: 0 Comm: swapper Not tainted
3.10.5-dockstar-00038-g03242d1-dirty #408
[<c000d670>] (unwind_backtrace+0x0/0xe0) from [<c000b2bc>]
(show_stack+0x10/0x14)
[<c000b2bc>] (show_stack+0x10/0x14) from [<c0396884>]
(print_usage_bug.part.25+0x21c/0x284)
[<c0396884>] (print_usage_bug.part.25+0x21c/0x284) from [<c004d34c>]
(mark_lock+0x438/0x65c)
[<c004d34c>] (mark_lock+0x438/0x65c) from [<c004db24>]
(__lock_acquire+0x5b4/0x18f0)
[<c004db24>] (__lock_acquire+0x5b4/0x18f0) from [<c004f31c>]
(lock_acquire+0x64/0x78)
[<c004f31c>] (lock_acquire+0x64/0x78) from [<c039c960>]
(_raw_spin_lock+0x40/0x50)
[<c039c960>] (_raw_spin_lock+0x40/0x50) from [<c02af9f8>]
(sensor_hub_raw_event+0x10c/0x204)
[<c02af9f8>] (sensor_hub_raw_event+0x10c/0x204) from [<c02a9a80>]
(hid_input_report+0x148/0x170)
[<c02a9a80>] (hid_input_report+0x148/0x170) from [<c02b1a18>]
(hid_irq_in+0x98/0x228)
[<c02b1a18>] (hid_irq_in+0x98/0x228) from [<c0275fa0>]
(usb_hcd_giveback_urb+0x94/0xf0)
[<c0275fa0>] (usb_hcd_giveback_urb+0x94/0xf0) from [<c0284c7c>]
(ehci_urb_done+0x6c/0x78)
[<c0284c7c>] (ehci_urb_done+0x6c/0x78) from [<c0287254>]
(qh_completions+0x310/0x394)
[<c0287254>] (qh_completions+0x310/0x394) from [<c0289550>]
(ehci_work+0x14c/0x780)
[<c0289550>] (ehci_work+0x14c/0x780) from [<c028a4cc>]
(ehci_irq+0x21c/0x248)
[<c028a4cc>] (ehci_irq+0x21c/0x248) from [<c0275958>]
(usb_hcd_irq+0x38/0x6c)
[<c0275958>] (usb_hcd_irq+0x38/0x6c) from [<c00621bc>]
(handle_irq_event_percpu+0x2c/0x1a4)
[<c00621bc>] (handle_irq_event_percpu+0x2c/0x1a4) from [<c0062370>]
(handle_irq_event+0x3c/0x5c)
[<c0062370>] (handle_irq_event+0x3c/0x5c) from [<c0064864>]
(handle_level_irq+0xd0/0xe8)
[<c0064864>] (handle_level_irq+0xd0/0xe8) from [<c0061c40>]
(generic_handle_irq+0x20/0x30)
[<c0061c40>] (generic_handle_irq+0x20/0x30) from [<c00098e8>]
(handle_IRQ+0x60/0x84)
[<c00098e8>] (handle_IRQ+0x60/0x84) from [<c0008b78>] (__irq_svc+0x38/0xa0)
[<c0008b78>] (__irq_svc+0x38/0xa0) from [<c02a24f8>]
(cpuidle_enter_state+0x60/0x100)
[<c02a24f8>] (cpuidle_enter_state+0x60/0x100) from [<c02a2674>]
(cpuidle_idle_call+0xdc/0x144)
[<c02a2674>] (cpuidle_idle_call+0xdc/0x144) from [<c0009a2c>]
(arch_cpu_idle+0x8/0x44)
[<c0009a2c>] (arch_cpu_idle+0x8/0x44) from [<c0042ebc>]
(cpu_startup_entry+0x80/0xec)
[<c0042ebc>] (cpu_startup_entry+0x80/0xec) from [<c050a750>]
(start_kernel+0x29c/0x2e4)
----------
On Fri, 9 Aug 2013, Alexander Holler wrote:
> =================================
> [ INFO: inconsistent lock state ]
> 3.10.5-dockstar-00038-g03242d1-dirty #408 Not tainted
> ---------------------------------
> inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
> (&(&sd->dyn_callback_lock)->rlock){?.+...}, at: [<c02af9f8>]
> sensor_hub_raw_event+0x10c/0x204
> {HARDIRQ-ON-W} state was registered at:
I think you need the patch below. Please let me know if it fixes it.
From: Jiri Kosina <[email protected]>
Subject: [PATCH] HID: sensor-hub: make dyn_callback_lock IRQ-safe
dyn_callback_lock is being taken from IRQ context through hid_irq_in() ->
hid_input_report() -> sensor_hub_raw_event() -> sensor_hub_get_callback(),
therefore anyone else acquiring it needs to disable IRQs to disable deadlocks.
Reported-by: Alexander Holler <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
---
drivers/hid/hid-sensor-hub.c | 24 ++++++++++++++----------
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index ca749810..b334e50 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -147,23 +147,24 @@ int sensor_hub_register_callback(struct hid_sensor_hub_device *hsdev,
{
struct hid_sensor_hub_callbacks_list *callback;
struct sensor_hub_data *pdata = hid_get_drvdata(hsdev->hdev);
+ unsigned long flags;
- spin_lock(&pdata->dyn_callback_lock);
+ spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
list_for_each_entry(callback, &pdata->dyn_callback_list, list)
if (callback->usage_id == usage_id) {
- spin_unlock(&pdata->dyn_callback_lock);
+ spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
return -EINVAL;
}
callback = kzalloc(sizeof(*callback), GFP_ATOMIC);
if (!callback) {
- spin_unlock(&pdata->dyn_callback_lock);
+ spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
return -ENOMEM;
}
callback->usage_callback = usage_callback;
callback->usage_id = usage_id;
callback->priv = NULL;
list_add_tail(&callback->list, &pdata->dyn_callback_list);
- spin_unlock(&pdata->dyn_callback_lock);
+ spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
return 0;
}
@@ -174,15 +175,16 @@ int sensor_hub_remove_callback(struct hid_sensor_hub_device *hsdev,
{
struct hid_sensor_hub_callbacks_list *callback;
struct sensor_hub_data *pdata = hid_get_drvdata(hsdev->hdev);
+ unsigned long flags;
- spin_lock(&pdata->dyn_callback_lock);
+ spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
list_for_each_entry(callback, &pdata->dyn_callback_list, list)
if (callback->usage_id == usage_id) {
list_del(&callback->list);
kfree(callback);
break;
}
- spin_unlock(&pdata->dyn_callback_lock);
+ spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
return 0;
}
@@ -359,15 +361,16 @@ static int sensor_hub_suspend(struct hid_device *hdev, pm_message_t message)
{
struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
struct hid_sensor_hub_callbacks_list *callback;
+ unsigned long flags;
hid_dbg(hdev, " sensor_hub_suspend\n");
- spin_lock(&pdata->dyn_callback_lock);
+ spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
list_for_each_entry(callback, &pdata->dyn_callback_list, list) {
if (callback->usage_callback->suspend)
callback->usage_callback->suspend(
pdata->hsdev, callback->priv);
}
- spin_unlock(&pdata->dyn_callback_lock);
+ spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
return 0;
}
@@ -376,15 +379,16 @@ static int sensor_hub_resume(struct hid_device *hdev)
{
struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
struct hid_sensor_hub_callbacks_list *callback;
+ unsigned long flags;
hid_dbg(hdev, " sensor_hub_resume\n");
- spin_lock(&pdata->dyn_callback_lock);
+ spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
list_for_each_entry(callback, &pdata->dyn_callback_list, list) {
if (callback->usage_callback->resume)
callback->usage_callback->resume(
pdata->hsdev, callback->priv);
}
- spin_unlock(&pdata->dyn_callback_lock);
+ spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
return 0;
}
--
Jiri Kosina
SUSE Labs
Am 09.08.2013 13:12, schrieb Jiri Kosina:
> On Fri, 9 Aug 2013, Alexander Holler wrote:
>
>
>> =================================
>> [ INFO: inconsistent lock state ]
>> 3.10.5-dockstar-00038-g03242d1-dirty #408 Not tainted
>> ---------------------------------
>> inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
>> swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
>> (&(&sd->dyn_callback_lock)->rlock){?.+...}, at: [<c02af9f8>]
>> sensor_hub_raw_event+0x10c/0x204
>> {HARDIRQ-ON-W} state was registered at:
>
> I think you need the patch below. Please let me know if it fixes it.
Thanks a lot. That actually fixed the bug I never have seen before and
the patch might be a candidate for the stable series (even if almost no
one would see the problem because there don't seem to be many
hid-sensor-hub users and the bug seems only to be visible with some
debug options enabled).
Btw, I've lied and that bug happened with the enforced error path as
well as during normal operation. It seems I have enabled some debug
option in the kernel, I never had enabled before.
Unfortunaly that doesn't answer Andrew Mortons questions.
I've now also verified if hid-sensor-hub receives an event with
sensor_hub_raw_event() in the error-path (hid_device_io_stop() called
and probe() failed), and this still *does* happen. That event (input
report) doesn't come through hid-sensor-hub to my driver, but I think
this is because of my call to sensor_hub_remove_callback() which is in
the error path too.
So I actually wonder why the input report still is reported from the
hid-subsystem to hid-sensor-hub, even after I've called
hid_device_io_stop() and probe() failed.
Maybe everything is still ok and I just got confused with the somehow
complicate interactions between the usb- and hid-subsystem,
hid-sensor-hub (which uses MFD) and rtc-hid-sensor-time.
I will also have a look if I find the seem to be missing down(), maybe
that will offer some explanations to what goes on. Unfortunately I still
don't know the complete path of events, I've stopped reading the source
after you've told me about the patch from Andrew de los Reyes, beeing
happy to have found a nice and proper solution (instead of the delayed
rtc-device registering I did before). ;)
Regards,
Alexander Holler
Am 09.08.2013 18:21, schrieb Alexander Holler:
> I've now also verified if hid-sensor-hub receives an event with
> sensor_hub_raw_event() in the error-path (hid_device_io_stop() called
> and probe() failed), and this still *does* happen. That event (input
> report) doesn't come through hid-sensor-hub to my driver, but I think
> this is because of my call to sensor_hub_remove_callback() which is in
> the error path too.
> So I actually wonder why the input report still is reported from the
> hid-subsystem to hid-sensor-hub, even after I've called
> hid_device_io_stop() and probe() failed.
> Maybe everything is still ok and I just got confused with the somehow
> complicate interactions between the usb- and hid-subsystem,
> hid-sensor-hub (which uses MFD) and rtc-hid-sensor-time.
Adding some more stuff to the confusion: Currently I think it is correct
that hid-sensor-hub still receives the event, even after
rtc-hid-sensor-time called hid_device_io_stop() and probe() failed. The
reason the same reason, why hid-sensor-hub uses mfd, the actual hardware
device might be shared by different drivers (therfor -hub).
Regards,
Alexander Holler
Hi Alexander
On Fri, Aug 9, 2013 at 6:33 PM, Alexander Holler <[email protected]> wrote:
> Am 09.08.2013 18:21, schrieb Alexander Holler:
>
>> I've now also verified if hid-sensor-hub receives an event with
>> sensor_hub_raw_event() in the error-path (hid_device_io_stop() called
>> and probe() failed), and this still *does* happen. That event (input
>> report) doesn't come through hid-sensor-hub to my driver, but I think
>> this is because of my call to sensor_hub_remove_callback() which is in
>> the error path too.
>> So I actually wonder why the input report still is reported from the
>> hid-subsystem to hid-sensor-hub, even after I've called
>> hid_device_io_stop() and probe() failed.
>> Maybe everything is still ok and I just got confused with the somehow
>> complicate interactions between the usb- and hid-subsystem,
>> hid-sensor-hub (which uses MFD) and rtc-hid-sensor-time.
>
>
> Adding some more stuff to the confusion: Currently I think it is correct
> that hid-sensor-hub still receives the event, even after rtc-hid-sensor-time
> called hid_device_io_stop() and probe() failed. The reason the same reason,
> why hid-sensor-hub uses mfd, the actual hardware device might be shared by
> different drivers (therfor -hub).
I don't have time right know to debug this, but I thought I'd just
clarify how the HID I/O lock works:
HID core uses a semaphore to protect driver probe and removal. That
is, the semaphore is locked during the ->probe() and ->remove()
callbacks. The input event handler (in atomic context!) tries to lock
this, too. If it fails due to ->probe or ->remove currently running,
it simply drops the input events (which is fine for reasons that don't
matter here). If it can lock it, it simply calls the ->raw_event() or
whatever callbacks of the driver (probably via hid-input).
If no driver is currently bound to a device, all input events are
always dropped.
If a driver now needs to perform I/O during ->probe or ->remove, they
must explicitly notify HID core about this. We cannot allow it
automatically as drivers must have a chance to setup some context
before the first events are passed in.
We start I/O via hid_device_io_start(). This simply releases the
->probe() semaphore and makes sure HID core knows about this. Once you
call it, your drivers input callbacks will be used by HID core so you
can perform I/O. Once you call hid_device_io_stop() the semaphore is
locked again and no more I/O is possible.
Same applies to the ->remove() callback, although it's not used by any
driver, yet. The reason is that ->remove() is almost always called if
the transport layer is already closed so any I/O will return -EIO.
We make sure we don't do any double down() or up() by tracking it via
a boolean. The memory barriers there aren't really obvious but it
should be correct.
I hope that explains how all this works. I can look over your patch on
Sunday if still necessary.
Cheers
David
Am 09.08.2013 19:02, schrieb David Herrmann:
> I hope that explains how all this works. I can look over your patch on
> Sunday if still necessary.
Thanks a lot for the explanation. Actually I don't have a problem but
Andrew Morton asked me some questions I can't answer without looking in
someone else source. ;)
Fortunately that forced me to enable some debug options which have shown
a bug Jiri fixed right after I've reported it.
So if your explanation answered Andrew Morton questions, I'm fine,
because my driver still works as I think it should. ;)
Thanks again,
Alexander Holler