linux-kernel - Re: [RFC PATCH 3/3] iio: derive the mounting matrix from ACPI

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]

Message-ID: <1430753037.5506.18.camel@spandruv-DESK3.jf.intel.com>
Date:	Mon, 04 May 2015 08:23:57 -0700
From:	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
To:	Octavian Purdila <octavian.purdila@...el.com>
Cc:	sathyanarayanan.kuppuswamy@...ux.intel.com,
	Jonathan Cameron <jic23@...nel.org>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Peter Meerwald <pmeerw@...erw.net>,
	Robert Moore <robert.moore@...el.com>,
	Rafael J Wysocki <rafael.j.wysocki@...el.com>,
	Len Brown <lenb@...nel.org>, linux-api@...r.kernel.org,
	lkml <linux-kernel@...r.kernel.org>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [RFC PATCH 3/3] iio: derive the mounting matrix from ACPI _PLD
 objects

On Mon, 2015-05-04 at 11:21 +0300, Octavian Purdila wrote:
> On Mon, May 4, 2015 at 4:11 AM, Sathyanarayanan Kuppuswamy
> <sathyanarayanan.kuppuswamy@...ux.intel.com> wrote:
> > Hi Octavian,
> >
> > On 04/27/2015 07:23 PM, Octavian Purdila wrote:
> >>
> >> On Tue, Apr 28, 2015 at 12:57 AM, sathyanarayanan kuppuswamy
> >> <sathyanarayanan.kuppuswamy@...ux.intel.com> wrote:
> >>>
> >>> Hi
> >>>
> >>> On 04/27/2015 08:54 AM, Octavian Purdila wrote:
> >>>>
> >>>> On Mon, Apr 27, 2015 at 6:42 PM, Kuppuswamy Sathyanarayanan
> >>>> <sathyanarayanan.kuppuswamy@...ux.intel.com> wrote:
> >>>>>
> >>>>> Since Acpi framework already exports this info to user space, Why not
> >>>>> do
> >>>>> this derivation in user space code ? Why do we need new ABI, if the
> >>>>> same
> >>>>> can be derived from existing one.
> >>>>>
> >>>> The ABI was added in the previous patch so that we can present the
> >>>> sensor orientation information to userspace even in the case of device
> >>>> tree.
> >>>
> >>> If the main reason for implementing a new ABI is to support DT platforms,
> >>> Why not implement a version of _PLD for device tree ? Don't you think it
> >>> would be much better than adding a new ABI to export redundant
> >>> information ?
> >>>
> >> IMO the mounting matrix is more consistent with the IIO ABIs. Although
> >> I have no issue with repicating _PLD for device tree if people agree
> >> that it is better.
> >
> > Since your main issue is, device tree lacking ABI to specify location
> > information, you should consider fixing it there. Let's wait for others
> > comment on this.
> >
> > If you think mounting matrix provides more information than what is
> > supported
> > by _PLD,  then we should consider implementing another ABI. AFAIK, that is
> > not
> > the case here.
> >
> > Adding adding a new ABI to represent the information that can be derived
> > from existing ABI does not seem to be useful.
> 
> AFAICS the ACPI _PLD information is not (yet) exported to userspace. This patch:
> 
> http://marc.info/?t=140795040700003&r=1&w=2
> 
> does not seem to be merged upstream. So there is no existing ABI to
> derive from :)
I don't think there is any major objection to this patch. The author
should just try and see if he can replace to device_* calls.

Thanks,
Srinivas

> 
> >>
> >>
> >>> Also the location information of the device is not just specific to iio
> >>> drivers. You should consider that we would have similar requirements for
> >>> devices implemented as input or platform drivers.
> >>
> >> The upstream standard for those sensors where the orientation matters
> >> (accelerometer, gyro, compass) is IIO.
> >>
> >> Granted, there are other device types for which the orientation
> >> information may be useful (e.g. camera). However the actual
> >> interpretation and action to be taken is different for each subsystem
> >> (e.g. in the camera case do the correction via V4L2_CID_HFLIP /
> >> V4L2_CID_VFLIP) so I think it is better to expose it at the subsystem
> >> level in a way consistent with the subsystem's ABIs.
> >
> > I agree that location information is used differently at different
> > sub systems. But my question is why we need  a new ABI ?
> >
> > Why not handle it in user space ?
> >
> > -


--
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/