lkml.org 
[lkml]   [2013]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] rtc: rtc-hid-sensor-time: fix possible bug on driver_remove
    Hello,

    sorry to bother again. I've now had the time to play with the new
    hctosys I proposed patches for and rtc-hid-sensor-time.

    If the new hctosys mechanism will end up in the kernel, the following
    patches I've recently send and which already got merged to -mm won't
    work anymore and should disappear:

    [PATCH 3/4] rtc: rtc-hid-sensor-time: add option hctosys to set time at boot
    [PATCH 4/4] rtc: rtc-hid-sensor-time: add support for milliseconds
    [PATCH] rtc: rtc-hid-sensor-time: fix possible bug on driver_remove


    The other two patches


    [PATCH 1/4] rtc: rtc-hid-sensor-time: allow full years (16bit) in HID
    reports
    [PATCH 2/4] rtc: rtc-hid-sensor-time: allow 16 and 32 bit values for all
    attributes.

    which got merged too are still fine.


    I don't know if I should send reverts for those 3 patches, or ...

    I've already have a patch which would be needed if the new hctosys would
    be used, but I will delay sending them until we figured out if and how
    that new hctosys will become real. But you might already revert or
    delete the above 3 patches in your tree.


    That silly looking driver rtc-hid-sensor-time is really an endless story. :/

    Besides writing the driver and an example firmware implementation I had
    to make patches for iio, hid-sensor-hub and hid, and now for timekeeping
    and rtc. All for nothing but the fun having to convince maintainers of
    all sorts and bothering them. ;)


    And the todo-list still contains some stuff:

    - rtc-hid-sensor-time still does not get loaded automatically if a
    matching hid-sensor-hub appears to the system. That needs changes to hid
    and/or hid-sensor-hub. Problem is that I don't have a real hid sensor
    hub and I don't know why the people which do produce such products and
    have written hid-sensor-hub didn't have implemented a way to do such. Or
    I've just missed something.

    - Have to redo millisecond support.

    - ntp functionality (e.g. module parameter adjtime) to make it possible
    to use a hardware clock with support for milliseconds to turn the system
    clock to a stratum 1 clock.

    - and last but not least I hope the standard for those HID sensors will
    become a standardized way to set the time. I still wouldn't like it if I
    had to "invent" something myself (easy, but it would be linux-specific
    and "invented" by some fool like me who just wrote it's own firmware
    without having any knowledge about some real hid-sensor products ;) ),
    but ...

    Regards,

    Alexander Holler


    \
     
     \ /
      Last update: 2013-06-08 11:21    [W:3.402 / U:0.944 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site