From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752372AbbF3MVx (ORCPT ); Tue, 30 Jun 2015 08:21:53 -0400 Received: from vegas.theobroma-systems.com ([144.76.126.164]:50422 "EHLO mail.theobroma-systems.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753159AbbF3MVp (ORCPT ); Tue, 30 Jun 2015 08:21:45 -0400 Message-ID: <559289D5.5020503@theobroma-systems.com> Date: Tue, 30 Jun 2015 14:21:41 +0200 From: Martin Kepplinger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Peter Meerwald , Martin Kepplinger CC: jic23@kernel.org, christoph.muellner@theobroma-systems.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org Subject: Re: [PATCH 0/2] iio: mma8452: add support for 3 more devices References: <1435663602-29868-1-git-send-email-martink@posteo.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015-06-30 13:39, Peter Meerwald wrote: > Hello Martin, > >> The first patch doesn't change anything for existing users of mma8452. Please >> test this if you can! > > nice to see the driver improved! > the first patch does quite I bit more than it claims; it's not only > adding more device, I'd prefer the patch split up for review well, yes. It adds an interrupt source for those that don't support the existing one, but I could come up with even more seperate changes, that's true. > >> The second patch corrects how interrupts are described as IIO events. It exists >> seperately because it changes the driver's behaviour for existing users of >> mma8452. > > what is the difference? Since the threshold is no signed value, it changes the event type from IIO_EV_TYPE_THRESH to IIO_EV_TYPE_MAG, see the patch or sysfs-bus-iio Documentation: What: /sys/.../iio:deviceX/events/in_accel_x_mag_en Similar to in_accel_x_thresh[_rising|_falling]_en, but here the magnitude of the channel is compared to the threshold, not its signed value. > > thanks, p. >