On Fri, Mar 20, 2015 at 7:26 AM, Martin Kepplinger <martin.kepplinger@xxxxxxxxxxxxxxxxxxxxx> wrote: > Am 2015-03-19 um 11:22 schrieb Bastien Nocera: >> On Wed, 2015-03-18 at 19:28 +0100, Martin Kepplinger wrote: >>> Am 2015-03-18 um 19:05 schrieb Bastien Nocera: >>>> On Wed, 2015-03-18 at 19:02 +0100, Martin Kepplinger wrote: >>>>> Am 2015-03-18 um 17:59 schrieb Bastien Nocera: >>>>>> On Wed, 2015-03-18 at 17:42 +0100, Martin Kepplinger wrote: >>>>>>> >>>>>> <snip> >>>>>>> It could have gone to drivers/iio/accel if it would use an >>>>>>> iio interface, which would make more sense, you are right, >>>>>>> but I >>>>>>> simply don't have the time to merge it in to iio. >>>>>>> >>>>>>> It doesn't use an input interface either but I don't see a >>>>>>> good place for an accelerometer that uses sysfs only. >>>>>>> >>>>>>> It works well, is a relatively recent chip and a clean >>>>>>> dirver. But this is all I can provide. >>>>>> >>>>>> As a person who works on the user-space interaction of those >>>>>> with desktops [1]: Urgh. >>>>>> >>>>>> I already have 3 (probably 4) types of accelerometers to >>>>>> contend with, I'm not fond of adding yet another type. >>>>>> >>>>>> Is there any way to get this hardware working outside the SoCs >>>>>> it's designed for (say, a device with I2C like a Raspberry >>>>>> Pi), so that a kind soul could handle getting this using the >>>>>> right interfaces? >>>>>> >>>>> >>>>> It works on basically any SoC and is in no way limited in this >>>>> regard. Sure, userspace has to expicitely support it and I hear >>>>> you. Using the iio interface would make more sense. I can only >>>>> say I'd love to have the time to move this driver over. I'm >>>>> very sorry. >>>> >>>> How can we get the hardware for somebody to use on their own >>>> laptops/embedded boards to implement this driver? >>>> >>> >>> It's connected over I2C. If the included documentation is not clear >>> please tell me what exacly. Thanks! >> >> >> I'll ask the question a different way: can you please give the address >> of a shop where that hardware is available? >> > > there is > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=RDMMA865x&lang_cd= > and http://linux-sunxi.org/Inet_K970 for example. I think I saw Android > devices with it too, and I would guess it would be used more often if it > were in linux. I am going to say again (in a different way) what Bastien said. In its current form, even in drivers/misc, this is a NACK for me (v1, v2, v3 & v4). Putting a driver in Linux means we have to support it forever, and definitively, nobody will use an accelerometer in Android if it is in drivers/misc. Android requires drivers to follow the IIO protocol. Period. So having your own will not help android, it will just be a burden. The sysfs you are proposing seems simple enough, but we can not afford having a 3rd custom way of relying the accelerometer information in the Linux tree (they were first handled in input, then IIO, then a custom sysfs). If you really want to have the driver in the tree, I won't be opposed if you put in under staging. This way, you can break it whenever you want and people won't rely on it. And then, we can use your driver as a base to port it to IIO. Sorry for being rude, but I am starting to get tired of people saying that they don't have the time to follow what the reviewers said. You obviously spent some time polishing this driver, why not making it right from its first inclusion in the tree? Cheers, Benjamin > > Please refer to v4 of the patch for different questions. thanks! > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
