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-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
