lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 11 Dec 2012 10:40:01 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Jonathan Cameron <jic23@...23.retrosnub.co.uk>
CC:	Alexander Holler <holler@...oftware.de>,
	Jonathan Cameron <jic23@...nel.org>,
	linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
	Jonathan Cameron <jic23@....ac.uk>, rtc-linux@...glegroups.com,
	Alessandro Zummo <a.zummo@...ertech.it>,
	srinivas pandruvada <srinivas.pandruvada@...el.com>
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ