linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@infradead.org>
To: Azael Avalos <coproscefalo@gmail.com>
Cc: platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v2 3/5] toshiba_acpi: Fix accelerometer direction reporting
Date: Mon, 15 Sep 2014 12:29:27 -0700	[thread overview]
Message-ID: <20140915192923.GA61529@vmdeb7> (raw)
In-Reply-To: <1410569437-3066-2-git-send-email-coproscefalo@gmail.com>

On Fri, Sep 12, 2014 at 06:50:37PM -0600, Azael Avalos wrote:
> The position file on sysfs was reporting absolute values
> for its axes.
> 
> This patch fixes the direction reporting (either negative
> or positive), as well as added a mutex lock to it.
> 

Hi All,

I've added Greg KH, Rafael, and H. Peter Anvin to get some clarity on a topic
which is coming up repeatedly in the platform-drivers-x86 subsystem.
Specifically, whether or not the driver-specific sysfs attributes should be
considered a "stable userspace interface".

The sysfs documentation [1] specfifically calls out the following types of
device properties:

o devpath
o kernel name
o subsystem
o driver
o attributes (the topic of this email)

In the case of this patch, Azael proposes changing the x,y,z attributes from the
absolute values read from the device to relative signed values.

In my opinion, this changes a userspace interface that exists prior to this
development cycle. As such, the attributes must remain as they are and new
attributes should be added if a new interface is wanted/needed. New x_rel,
y_rel, z_rel attributes could be added for this purpose.

I have also suggested this device (2 actually) would be better supported as an
IIO accelerometer device, but even that would change the sysfs interface by
removing these altogether and using the IIO standardized path and accelerometer
interface.

Do we have a policy for this kind of change already in place?

1. Documentation/sysfs-rules.txt 

Thanks,

Darren


> Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
> ---
> This was: Add accelerometer input polled device
> 
> Changes since v1:
> Dropped polldev and kept the position entry, and simply
> fix the axes direction reporting, the IIO device will
> be added in a future patch instead of the polled device.
> 
>  drivers/platform/x86/toshiba_acpi.c | 21 ++++++++++++++++-----
>  1 file changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c
> index edd8f3d..a94e5ed 100644
> --- a/drivers/platform/x86/toshiba_acpi.c
> +++ b/drivers/platform/x86/toshiba_acpi.c
> @@ -124,6 +124,7 @@ MODULE_LICENSE("GPL");
>  #define SCI_TOUCHPAD			0x050e
>  
>  /* field definitions */
> +#define HCI_ACCEL_DIRECTION_MASK	0x8000
>  #define HCI_ACCEL_MASK			0x7fff
>  #define HCI_HOTKEY_DISABLE		0x0b
>  #define HCI_HOTKEY_ENABLE		0x09
> @@ -1527,19 +1528,29 @@ static ssize_t toshiba_position_show(struct device *dev,
>  				     struct device_attribute *attr, char *buf)
>  {
>  	struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
> -	u32 xyval, zval, tmp;
> -	u16 x, y, z;
> +	u32 xyval, zval;
> +	int x, y, z;
>  	int ret;
>  
> +	mutex_lock(&dev->mutex);
> +
>  	xyval = zval = 0;
>  	ret = toshiba_accelerometer_get(toshiba, &xyval, &zval);
> -	if (ret < 0)
> +	if (ret) {
> +		mutex_unlock(&dev->mutex);
>  		return ret;
> +	}
>  
> +	/* Accelerometer values */
>  	x = xyval & HCI_ACCEL_MASK;
> -	tmp = xyval >> HCI_MISC_SHIFT;
> -	y = tmp & HCI_ACCEL_MASK;
> +	y = (xyval >> HCI_MISC_SHIFT) & HCI_ACCEL_MASK;
>  	z = zval & HCI_ACCEL_MASK;
> +	/* Movement direction */
> +	x *= xyval & HCI_ACCEL_DIRECTION_MASK ? -1 : 1;
> +	y *= (xyval >> HCI_MISC_SHIFT) & HCI_ACCEL_DIRECTION_MASK ? -1 : 1;
> +	z *= zval & HCI_ACCEL_DIRECTION_MASK ? -1 : 1;
> +
> +	mutex_unlock(&dev->mutex);
>  
>  	return sprintf(buf, "%d %d %d\n", x, y, z);
>  }
> -- 
> 2.0.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Darren Hart
Intel Open Source Technology Center

  reply	other threads:[~2014-09-15 19:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-13  0:50 [PATCH v4 4/5] toshiba_acpi: Support new keyboard backlight type Azael Avalos
2014-09-13  0:50 ` [PATCH v2 3/5] toshiba_acpi: Fix accelerometer direction reporting Azael Avalos
2014-09-15 19:29   ` Darren Hart [this message]
2014-09-15 19:56     ` Greg Kroah-Hartman
2014-09-15 21:01       ` H. Peter Anvin
2014-09-15 21:13         ` Darren Hart
2014-09-15 17:47 ` [PATCH v4 4/5] toshiba_acpi: Support new keyboard backlight type Darren Hart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140915192923.GA61529@vmdeb7 \
    --to=dvhart@infradead.org \
    --cc=coproscefalo@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).