Re: [PATCH 3/5] toshiba_acpi: Add accelerometer input polled device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 08, 2014 at 05:04:30PM -0700, Darren Hart wrote:
> On Fri, Sep 05, 2014 at 11:04:18PM -0600, Azael Avalos wrote:
> > Hi there,
> > 
> > 2014-09-05 20:42 GMT-06:00 Darren Hart <dvhart@xxxxxxxxxxxxx>:
> > > On Fri, Sep 05, 2014 at 11:14:05AM -0600, Azael Avalos wrote:
> > >> The accelerometer sensor is very sensitive, and having userspace
> > >> poll the sysfs position entry is not very battery friendly.
> > >>
> > >> This patch removes the sysfs entry and instead, it creates an
> > >> input polled device (joystick) for the built-in accelerometer.
> > >
> > > Hrm, while sysfs details can change across kernel versions, usually due to
> > > driver core changes, we try to keep them as consistent as possible so as not to
> > > break userspace.
> > >
> > > That said, if we are going to try and come up with a better model for
> > > representing an accelerometer, wouldn't treating it as an IIO device be the more
> > > logical approach?
> > 
> > Yes of course, but the actual accelerometer device (sensor?) is not
> > really exposed,
> > only certain "functions" it provides, and they are divided across two
> > different ACPI devices,
> > TOS620A exposes the protection, and the TOS1900 (and et. al.) only
> > exposes the axes.
> 
> As I understand it, IIO defines an interface to a device, a standard sysfs set
> of properties. I should think we could provide the appropriate callbacks even
> for a partially implemented (or a pair of) accelerometer.
> 
> Jonathan, what are your thoughts here. Is such a "device" (ACPI accessors to
> axis and threshold) a candidate for IIO, or is this input polled device more
> appropriate?
> 
> > 
> > I see your point in breaking userspace, but given the fact that it was
> > recently introduced,
> > I didn't thought it was already "adopted", that's why I decided to
> > remove the sysfs entry.
> 
> Looks like since 3.15 if I read the log correctly. That is fairly recent and
> this is not one of the "defined interfaces" in the sysfs documentation.
> 
> Greg, can you weigh in here - does this change count as "breaking userspace", or
> is this more inline with the scheduler knobs in /proc/sched_debug which can
> change from version to version.
> 
> > 
> > Then we might as well keep the sysfs entry and have the input polled
> > device as well.
> 
> Let's see what Greg has to say. If he isn't bothered by the change, I won't push
> the issue.

If it should be an IIO device, great, make it an IIO device, and move
away from a custom sysfs interface that matches nothing else.

But I really doubt it should be a joystick device, that just doesn't
make sense at all.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux