lkml.org 
[lkml]   [2013]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [rtc-linux] Re: [PATCH 3/9 v2] rtc: rtc-hid-sensor-time: delay registering as rtc into a work
On Wed, Jun 26, 2013 at 11:34:35PM +0200, Alexander Holler wrote:
> >> + /*
> >> + * The HID device has to be registered to read the clock.
> >> + * Because rtc_device_register() might read the time, we have to delay
> >> + * rtc_device_register() to a work in order to finish the probe before.
> >> + */
> >> + time_state->workts = kmalloc(sizeof(struct hid_time_workts),
> >> + GFP_KERNEL);
> >> + if (time_state->workts == NULL) {
> >> + sensor_hub_remove_callback(hsdev, HID_USAGE_SENSOR_TIME);
> >> + return -ENOMEM;
> >> }
> >> + time_state->workts->time_state = time_state;
> >> + INIT_WORK(&time_state->workts->work,
> >> + hid_time_register_rtc_work);
> >> + schedule_work(&time_state->workts->work);
> >
> > This seems unreliable. The scheduled work can run one nanosecond
> > later, on this or a different CPU. What guarantees that the HID device
> > will then be fully registered?
>
> Nothing, but schedule_delayed_work() is as unreliable as without delay
> and I don't know of any callback after registration has happened. I have
> to dig through the hid-(sensor-)code, maybe I will find a callback I can
> (mis)use to register the rtc driver after the hid driver was registered.

Why not use the deferred_probe code, which is there just for this type
of thing (i.e. your other drivers/devices aren't present/initialized
yet.)? Just return -EPROBE_DEFER from your probe function if you don't
find everything already set up properly, the driver core will call you
again later after it has initialized everything it has found.

Hope this helps,

greg k-h


\
 
 \ /
  Last update: 2013-06-27 00:41    [W:0.303 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site