lkml.org 
[lkml]   [2012]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
On 12/11/2012 10:31 AM, Jonathan Cameron wrote:
> On 10/12/12 22:50, Alexander Holler wrote:
>> Am 10.12.2012 22:42, schrieb Jonathan Cameron:
>>> On 12/10/2012 09:39 PM, Lars-Peter Clausen wrote:
>>>> On 12/10/2012 10:26 PM, Alexander Holler wrote:
>>>>> Am 10.12.2012 21:22, schrieb Lars-Peter Clausen:
>>>>>> On 12/10/2012 08:45 PM, Alexander Holler wrote:
>>>>>>> Am 10.12.2012 18:05, schrieb Lars-Peter Clausen:
>>>>>>>
>>>>>>>> Looks pretty good now. But there are still some IIO remnants
>>>>>>>> which should be
>>>>>>>> removed as well. Also the driver should move to drivers/rtc/
>>>>>>>> since, well,
>>>>>>>> it's a rtc driver not a IIO driver.
>>>>>>>
>>>>>>> I think it still should be stick to iio, because that is where all
>>>>>>> HID
>>>>>>> sensors currently are found and where the user would expect to
>>>>>>> find such
>>>>>>> a driver.
>>>>>>
>>>>>> That's because all the current IIO sensor drivers fall in the IIO
>>>>>> domain. This
>>>>>> one clearly is a RTC driver, so it belongs in drivers/rtc/
>>>>>
>>>>> Where nobody will find it if he searches for drivers for his HID
>>>>> sensor.
>>>>> I still see it as HID sensor driver and not a rtc-driver.
>>>>> But ...
>>>>
>>>> I can understand your position, but drivers are usually grouped by
>>>> function not
>>>> by topology. If there is a proper Kconfig help text people should
>>>> hopefully be
>>>> find it.
>>> Seconded on this. If it is a pure rtc driver then it definitely
>>> belongs in
>>> drivers/rtc. Now there might have been ways of doing this as a
>>> consumer / provider
>>> with the provider being in IIO and the consumer in rtc, but that
>>> sounds like
>>> it is over compicating things, at least for now.
>>
>> Personally I just want to use it to have HID-USB_RTCs. ;)
>>
>> But in case of HID sensor hubs, the main usage of that driver will be to
>> set the time of such hubs (something I still have to make patches for),
>> and not to read it. So if you think as an HID sensor user, it should
>> belong to iio or wherever those sensor will finally end up (I think they
>> should end up in HID and should be usable by bluetooth devices too), but
>> if you creatively misuse the standard to get a driver for USB-RTCs, as I
>> want, then rtc is the correct place. ;)
> I did wonder what you were up to ;)
>>
>> Because I don't want to do a v4:
>>
>> the driver has an
>>
>> #include "../common/hid-sensors/hid-sensor-attributes.h"
>>
>> so moving it to drivers/rtc/ will make that even more ugly.
>>
>
>> Suggestions? I don't really care and as I'm currently at the order
>> receiving end ;) I would change it to whatever the maintainers are
>> wanting. Maybe moving that header to include/linux or even integrating
>> it into include/linux/hid-sensor-hubs.h makes sense.
> Yes, move the header or merge into existing one as makes sense.
> I'm not pulling this driver into the IIO tree (unless for some
> reason Alessandro wants me to and I can't think why he would...).
>

Alessandro has been pretty quiet for quite some time now. Luckily Andrew
Morton usually picks up the stuff for orphaned subsystems. So put him on Cc
for v4.

- Lars


\
 
 \ /
  Last update: 2012-12-11 11:21    [W:0.125 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site