Re: [PATCH 2/4] input: tablet: pegasus_notetaker: Fix usb_autopm calls to be balanced

2016-07-21 Thread Martin Kepplinger
Am 2016-07-20 um 23:29 schrieb Dmitry Torokhov:
> On Mon, Jul 18, 2016 at 04:29:07PM +0200, Martin Kepplinger wrote:
>> Signed-off-by: Martin Kepplinger 
>> ---
>>  drivers/input/tablet/pegasus_notetaker.c | 19 +++
>>  1 file changed, 11 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/input/tablet/pegasus_notetaker.c 
>> b/drivers/input/tablet/pegasus_notetaker.c
>> index 27cb352..fdbc5e8 100644
>> --- a/drivers/input/tablet/pegasus_notetaker.c
>> +++ b/drivers/input/tablet/pegasus_notetaker.c
>> @@ -208,27 +208,30 @@ static int pegasus_open(struct input_dev *dev)
>>  return retval;
>>  
>>  pegasus->irq->dev = pegasus->usbdev;
>> -if (usb_submit_urb(pegasus->irq, GFP_KERNEL))
>> +if (usb_submit_urb(pegasus->irq, GFP_KERNEL)) {
>>  retval = -EIO;
>> +goto out;
>> +}
>>  
>>  retval = pegasus_set_mode(pegasus, PEN_MODE_XY, NOTETAKER_LED_MOUSE);
> 
> If this fails I we should kill URB and cancel work. I adjusted and
> applied.

You're right. Thanks for this!

> 
>>  
>> -usb_autopm_put_interface(pegasus->intf);
>> +out:
>>  
>> -return retval;
>> +if (retval < 0) {
>> +usb_autopm_put_interface(pegasus->intf);
>> +return retval;
>> +} else {
>> +return 0;
>> +}
>>  }
>>  
>>  static void pegasus_close(struct input_dev *dev)
>>  {
>>  struct pegasus *pegasus = input_get_drvdata(dev);
>> -int autopm_error;
>>  
>> -autopm_error = usb_autopm_get_interface(pegasus->intf);
>>  usb_kill_urb(pegasus->irq);
>>  cancel_work_sync(&pegasus->init);
>> -
>> -if (!autopm_error)
>> -usb_autopm_put_interface(pegasus->intf);
>> +usb_autopm_put_interface(pegasus->intf);
>>  }
>>  
>>  static int pegasus_probe(struct usb_interface *intf,
>> -- 
>> 2.1.4
>>
> 



Re: [PATCH 1/4] input: tablet: pegasus_notetaker: Track usb control msg errors

2016-07-21 Thread Martin Kepplinger
Am 2016-07-20 um 23:06 schrieb Dmitry Torokhov:
> Hi Martin,
> 
> On Mon, Jul 18, 2016 at 04:29:06PM +0200, Martin Kepplinger wrote:
>> Signed-off-by: Martin Kepplinger 
>> ---
>>  drivers/input/tablet/pegasus_notetaker.c | 26 ++
>>  1 file changed, 18 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/input/tablet/pegasus_notetaker.c 
>> b/drivers/input/tablet/pegasus_notetaker.c
>> index 83aa583..27cb352 100644
>> --- a/drivers/input/tablet/pegasus_notetaker.c
>> +++ b/drivers/input/tablet/pegasus_notetaker.c
>> @@ -79,7 +79,7 @@ struct pegasus {
>>  struct work_struct init;
>>  };
>>  
>> -static void pegasus_control_msg(struct pegasus *pegasus, u8 *data, int len)
>> +static int pegasus_control_msg(struct pegasus *pegasus, u8 *data, int len)
>>  {
>>  const int sizeof_buf = len + 2;
>>  int result;
>> @@ -87,7 +87,7 @@ static void pegasus_control_msg(struct pegasus *pegasus, 
>> u8 *data, int len)
>>  
>>  cmd_buf = kmalloc(sizeof_buf, GFP_KERNEL);
>>  if (!cmd_buf)
>> -return;
>> +return -ENOMEM;
>>  
>>  cmd_buf[0] = NOTETAKER_REPORT_ID;
>>  cmd_buf[1] = len;
>> @@ -100,17 +100,23 @@ static void pegasus_control_msg(struct pegasus 
>> *pegasus, u8 *data, int len)
>>   0, 0, cmd_buf, sizeof_buf,
>>   USB_CTRL_SET_TIMEOUT);
>>  
>> -if (result != sizeof_buf)
>> -dev_err(&pegasus->usbdev->dev, "control msg error\n");
>> +if (result != sizeof_buf) {
>> +if (result >= 0)
>> +result = -EIO;
>> +dev_err(&pegasus->usbdev->dev, "control msg error: %d\n",
>> +result);
>> +}
>>  
>>  kfree(cmd_buf);
>> +
>> +return result;
> 
> Your 4th patch relies on pegasus_control_msg() returning 0 on success,
> otherwise you will not restart the URB when doing reset resume. I
> rearranged the code here so we free cmd_buf right after calling
> usb_control_msg() and the explicitly returnig 0 in success branch.
> 

Yes, I saw it. Thanks for your explaining and fixing!

>>  }
>>  
>> -static void pegasus_set_mode(struct pegasus *pegasus, u8 mode, u8 led)
>> +static int pegasus_set_mode(struct pegasus *pegasus, u8 mode, u8 led)
>>  {
>>  u8 cmd[] = {NOTETAKER_SET_CMD, NOTETAKER_SET_MODE, led, mode};
>>  
>> -pegasus_control_msg(pegasus, cmd, sizeof(cmd));
>> +return pegasus_control_msg(pegasus, cmd, sizeof(cmd));
>>  }
>>  
>>  static void pegasus_parse_packet(struct pegasus *pegasus)
>> @@ -184,8 +190,12 @@ static void pegasus_irq(struct urb *urb)
>>  static void pegasus_init(struct work_struct *work)
>>  {
>>  struct pegasus *pegasus = container_of(work, struct pegasus, init);
>> +int retval;
>>  
>> -pegasus_set_mode(pegasus, PEN_MODE_XY, NOTETAKER_LED_MOUSE);
>> +retval = pegasus_set_mode(pegasus, PEN_MODE_XY, NOTETAKER_LED_MOUSE);
>> +if (retval < 0)
>> +dev_err(&pegasus->usbdev->dev, "pegasus_set_mode error: %d\n",
>> +retval);
>>  }
>>  
>>  static int pegasus_open(struct input_dev *dev)
>> @@ -201,7 +211,7 @@ static int pegasus_open(struct input_dev *dev)
>>  if (usb_submit_urb(pegasus->irq, GFP_KERNEL))
>>  retval = -EIO;
>>  
>> -pegasus_set_mode(pegasus, PEN_MODE_XY, NOTETAKER_LED_MOUSE);
>> +retval = pegasus_set_mode(pegasus, PEN_MODE_XY, NOTETAKER_LED_MOUSE);
>>  
>>  usb_autopm_put_interface(pegasus->intf);
>>  
> 
> Thanks.
> 



[PATCH] input: pegasus_notetaker - directly include workqueue header

2016-08-24 Thread Martin Kepplinger
According to the kernel's guidelines, let's directly include the
workqueue functions we use.

Signed-off-by: Martin Kepplinger 
---
I don't know if it's worth it, but I should have included this according to
the guidelines :)


 drivers/input/tablet/pegasus_notetaker.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/tablet/pegasus_notetaker.c 
b/drivers/input/tablet/pegasus_notetaker.c
index 949dacc..47de5a8 100644
--- a/drivers/input/tablet/pegasus_notetaker.c
+++ b/drivers/input/tablet/pegasus_notetaker.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* USB HID defines */
 #define USB_REQ_GET_REPORT 0x01
-- 
2.1.4



Re: [PATCH] iio: accel: mma8452: Bugfix to enbale and allow different events to work parallely.

2017-08-17 Thread Martin Kepplinger
p specific data
>>>* @chip_id:  WHO_AM_I register's value
>>> @@ -116,40 +139,12 @@ struct mma8452_data {
>>>* @mma_scales:   scale factors for converting register 
>>> values
>>>*to m/s^2; 3 modes: 2g, 4g, 8g; 2 
>>> integers
>>>*per mode: m/s^2 and micro m/s^2
>>> - * @ev_cfg:event config register address
>>> - * @ev_cfg_ele:latch bit in event config register
>>> - * @ev_cfg_chan_shift: number of the bit to enable events in X
>>> - * direction; in event config register
>>> - * @ev_src:event source register address
>>> - * @ev_src_xe: bit in event source register that 
>>> indicates
>>> - * an event in X direction
>>> - * @ev_src_ye: bit in event source register that 
>>> indicates
>>> - * an event in Y direction
>>> - * @ev_src_ze: bit in event source register that 
>>> indicates
>>> - * an event in Z direction
>>> - * @ev_ths:event threshold register address
>>> - * @ev_ths_mask:   mask for the threshold value
>>> - * @ev_count:  event count (period) register address
>>> - *
>>> - * Since not all chips supported by the driver support comparing
>high pass
>>> - * filtered data for events (interrupts), different interrupt
>sources are
>>> - * used for different chips and the relevant registers are included
>here.
>>>*/
>>>   struct mma_chip_info {
>>> u8 chip_id;
>>> const struct iio_chan_spec *channels;
>>> int num_channels;
>>> const int mma_scales[3][2];
>>> -   u8 ev_cfg;
>>> -   u8 ev_cfg_ele;
>>> -   u8 ev_cfg_chan_shift;
>>> -   u8 ev_src;
>>> -   u8 ev_src_xe;
>>> -   u8 ev_src_ye;
>>> -   u8 ev_src_ze;
>>> -   u8 ev_ths;
>>> -   u8 ev_ths_mask;
>>> -   u8 ev_count;
>>>   };
>>>   
>>>   enum {
>>> @@ -602,9 +597,8 @@ static int mma8452_set_power_mode(struct
>mma8452_data *data, u8 mode)
>>>   static int mma8452_freefall_mode_enabled(struct mma8452_data
>*data)
>>>   {
>>> int val;
>>> -   const struct mma_chip_info *chip = data->chip_info;
>>>   
>>> -   val = i2c_smbus_read_byte_data(data->client, chip->ev_cfg);
>>> +   val = i2c_smbus_read_byte_data(data->client, MMA8452_FF_MT_CFG);
>>> if (val < 0)
>>> return val;
>>>   
>>> @@ -614,29 +608,28 @@ static int
>mma8452_freefall_mode_enabled(struct mma8452_data *data)
>>>   static int mma8452_set_freefall_mode(struct mma8452_data *data,
>bool state)
>>>   {
>>> int val;
>>> -   const struct mma_chip_info *chip = data->chip_info;
>>>   
>>> if ((state && mma8452_freefall_mode_enabled(data)) ||
>>> (!state && !(mma8452_freefall_mode_enabled(data
>>> return 0;
>>>   
>>> -   val = i2c_smbus_read_byte_data(data->client, chip->ev_cfg);
>>> +   val = i2c_smbus_read_byte_data(data->client, MMA8452_FF_MT_CFG);
>>> if (val < 0)
>>> return val;
>>>   
>>> if (state) {
>>> -   val |= BIT(idx_x + chip->ev_cfg_chan_shift);
>>> -   val |= BIT(idx_y + chip->ev_cfg_chan_shift);
>>> -   val |= BIT(idx_z + chip->ev_cfg_chan_shift);
>>> +   val |= BIT(idx_x + MMA8452_FF_MT_CHAN_SHIFT);
>>> +   val |= BIT(idx_y + MMA8452_FF_MT_CHAN_SHIFT);
>>> +   val |= BIT(idx_z + MMA8452_FF_MT_CHAN_SHIFT);
>>> val &= ~MMA8452_FF_MT_CFG_OAE;
>>> } else {
>>> -   val &= ~BIT(idx_x + chip->ev_cfg_chan_shift);
>>> -   val &= ~BIT(idx_y + chip->ev_cfg_chan_shift);
>>> -   val &= ~BIT(idx_z + chip->ev_cfg_chan_shift);
>>> +   val &= ~BIT(idx_x + MMA8452_FF_MT_CHAN_SHIFT);
>>> +   val &= ~BIT(idx_y + MMA8452_FF_MT_CHAN_SHIFT);
>>> +   val &= ~BIT(idx_z + MMA8452_FF_MT_CHAN_SHIFT);
>>> val |= MMA8452_FF_MT_CFG_OAE;
>>> }
>>>   
>>> -   return mma8452_change_config(data, chip->ev_cfg, val);
>>> +   return mma8452_change_config(data, MMA8452_FF_MT_CFG, val);
>>>   }
>>>   
>>>   static int mma8452_set_hp_filter_frequency(struct mma8452_data
>*data,
>>> @@ -740,6 +733,39 @@ static int mma8452_write_raw(struct iio_dev
>*indio_dev,
>>> return ret;
>>>   }
>>>   
>>> +static int mma8452_get_event_regs(const struct iio_chan_spec *chan,
>>> +  enum iio_event_direction dir,
>>> +  struct mma8452_event_regs *ev_regs
>>> +  )
>>> +{
>>> +   if (!chan)
>>> +   return -EINVAL;
>>> +   switch (chan->type) {
>>> +   case IIO_ACCEL:
>>> +   switch (dir) {
>>> +   case IIO_EV_DIR_FALLING:
>>> +   ev_regs->ev_cfg = MMA8452_FF_MT_CFG;
>>> +   ev_regs->ev_src = MMA8452_FF_MT_SRC;
>>> +   ev_regs->ev_ths = MMA8452_FF_MT_THS;
>>> +   ev_regs->ev_ths_mask = MMA8452_FF_MT_THS_MASK;
>>> +   ev_regs->ev_count = MMA8452_FF_MT_COUNT;
>>> +   break;
>>> +   case IIO_EV_DIR_RISING:
>>> +   ev_regs->ev_cfg = MMA8452_TRANSIENT_CFG;
>>> +   ev_regs->ev_src = MMA8452_TRANSIENT_SRC;
>>> +   ev_regs->ev_ths = MMA8452_TRANSIENT_THS;
>>
>> ev_ths_mask is not set here
>>
>>> +   ev_regs->ev_count = MMA8452_TRANSIENT_COUNT;
>>> +   break;
>>> +   default:
>>> +   return -EINVAL;
>>> +   }
>>> +   break;
>>> +   default:
>>> +   return -EINVAL;
>>> +   }
>>> +   return 0;
>> could replace 'breaks' with return 0 to save some lines and simplify
>> control flow
>>
>>> +}
>>> +
>>>   static int mma8452_read_thresh(struct iio_dev *indio_dev,
>>>const struct iio_chan_spec *chan,
>>>enum iio_event_type type,
>>> @@ -749,21 +775,23 @@ static int mma8452_read_thresh(struct iio_dev
>*indio_dev,
>>>   {
>>> struct mma8452_data *data = iio_priv(indio_dev);
>>> int ret, us, power_mode;
>>> +   struct mma8452_event_regs ev_regs;
>>>   
>>> +   ret = mma8452_get_event_regs(chan, dir, &ev_regs);
>>> +   if (ret)
>>> +   return ret;
>>> switch (info) {
>>> case IIO_EV_INFO_VALUE:
>>> -   ret = i2c_smbus_read_byte_data(data->client,
>>> -  data->chip_info->ev_ths);
>>> +   ret = i2c_smbus_read_byte_data(data->client, ev_regs.ev_ths);
>>> if (ret < 0)
>>> return ret;
>>>   
>>> -   *val = ret & data->chip_info->ev_ths_mask;
>>> +   *val = ret & ev_regs.ev_ths_mask;
>>>   
>>> return IIO_VAL_INT;
>>>   
>>> case IIO_EV_INFO_PERIOD:
>>> -   ret = i2c_smbus_read_byte_data(data->client,
>>> -  data->chip_info->ev_count);
>>> +   ret = i2c_smbus_read_byte_data(data->client, ev_regs.ev_count);
>>> if (ret < 0)
>>> return ret;
>>>   
>>> @@ -809,14 +837,18 @@ static int mma8452_write_thresh(struct iio_dev
>*indio_dev,
>>>   {
>>> struct mma8452_data *data = iio_priv(indio_dev);
>>> int ret, reg, steps;
>>> +   struct mma8452_event_regs ev_regs;
>>> +
>>> +   ret = mma8452_get_event_regs(chan, dir, &ev_regs);
>>> +   if (ret)
>>> +   return ret;
>>>   
>>> switch (info) {
>>> case IIO_EV_INFO_VALUE:
>>> -   if (val < 0 || val > MMA8452_TRANSIENT_THS_MASK)
>>> +   if (val < 0 || val > ev_regs.ev_ths_mask)
>>> return -EINVAL;
>>>   
>>> -   return mma8452_change_config(data, data->chip_info->ev_ths,
>>> -val);
>>> +   return mma8452_change_config(data, ev_regs.ev_ths, val);
>>>   
>>> case IIO_EV_INFO_PERIOD:
>>> ret = mma8452_get_power_mode(data);
>>> @@ -830,8 +862,7 @@ static int mma8452_write_thresh(struct iio_dev
>*indio_dev,
>>> if (steps < 0 || steps > 0xff)
>>> return -EINVAL;
>>>   
>>> -   return mma8452_change_config(data, data->chip_info->ev_count,
>>> -steps);
>>> +   return mma8452_change_config(data, ev_regs.ev_count, steps);
>>>   
>>> case IIO_EV_INFO_HIGH_PASS_FILTER_3DB:
>>> reg = i2c_smbus_read_byte_data(data->client,
>>> @@ -861,23 +892,23 @@ static int mma8452_read_event_config(struct
>iio_dev *indio_dev,
>>>  enum iio_event_direction dir)
>>>   {
>>> struct mma8452_data *data = iio_priv(indio_dev);
>>> -   const struct mma_chip_info *chip = data->chip_info;
>>> int ret;
>>>   
>>> -   switch (dir) {
>>> -   case IIO_EV_DIR_FALLING:
>>> -   return mma8452_freefall_mode_enabled(data);
>>> -   case IIO_EV_DIR_RISING:
>>> -   if (mma8452_freefall_mode_enabled(data))
>>> -   return 0;
>>> +   switch (chan->type) {
>>> +   case IIO_ACCEL:
>> this adds a check for chan-type == IIO_ACCESS, so strictly this would
>be
>> an unrelated change...
>>
>>> +   switch (dir) {
>>> +   case IIO_EV_DIR_FALLING:
>>> +   return mma8452_freefall_mode_enabled(data);
>>> +   case IIO_EV_DIR_RISING:
>>> +   ret = i2c_smbus_read_byte_data(data->client,
>MMA8452_TRANSIENT_CFG);
>>> +   if (ret < 0)
>>> +   return ret;
>>>   
>>> -   ret = i2c_smbus_read_byte_data(data->client,
>>> -  data->chip_info->ev_cfg);
>>> -   if (ret < 0)
>>> -   return ret;
>>> +   return !!(ret & 
>>> MMA8452_TRANSIENT_CFG_CHAN(chan->scan_index));
>>>   
>>> -   return !!(ret & BIT(chan->scan_index +
>>> -   chip->ev_cfg_chan_shift));
>>> +   default:
>>> +   return -EINVAL;
>>> +   }
>>> default:
>>> return -EINVAL;
>>> }
>>> @@ -890,39 +921,33 @@ static int mma8452_write_event_config(struct
>iio_dev *indio_dev,
>>>   int state)
>>>   {
>>> struct mma8452_data *data = iio_priv(indio_dev);
>>> -   const struct mma_chip_info *chip = data->chip_info;
>>> int val, ret;
>>>   
>>> ret = mma8452_set_runtime_pm_state(data->client, state);
>>> if (ret)
>>> retu

-- 
Martin Kepplinger
http://martinkepplinger.com
sent from mobile


[PATCH] Input: ar1021_i2c - set INPUT_PROP_DIRECT

2017-11-02 Thread Martin Kepplinger
If INPUT_PROP_DIRECT is set, userspace doesn't have to fall back to old
ways of identifying touchscreen devices. Let's add it.

Signed-off-by: Martin Kepplinger 
---
 drivers/input/touchscreen/ar1021_i2c.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/touchscreen/ar1021_i2c.c 
b/drivers/input/touchscreen/ar1021_i2c.c
index f9dcbd63e598..b35b640fdadf 100644
--- a/drivers/input/touchscreen/ar1021_i2c.c
+++ b/drivers/input/touchscreen/ar1021_i2c.c
@@ -117,6 +117,7 @@ static int ar1021_i2c_probe(struct i2c_client *client,
input->open = ar1021_i2c_open;
input->close = ar1021_i2c_close;
 
+   __set_bit(INPUT_PROP_DIRECT, input->propbit);
input_set_capability(input, EV_KEY, BTN_TOUCH);
input_set_abs_params(input, ABS_X, 0, AR1021_MAX_X, 0, 0);
input_set_abs_params(input, ABS_Y, 0, AR1021_MAX_Y, 0, 0);
-- 
2.11.0



Re: [PATCH] iio: mma8452: add power_mode sysfs configuration

2017-11-12 Thread Martin Kepplinger
On 2017-11-11 01:33, Jonathan Cameron wrote:
> On Mon, 6 Nov 2017 08:19:58 +0100
> Martin Kepplinger  wrote:
> 
>> This adds the power_mode sysfs interface to the device as documented in
>> sysfs-bus-iio.
>>
>> ---
>>
>> Note that I explicitely don't sign off on this.
>>
>> This is a starting point for anybody who can test it and check for correct
>> API usage, and ABI correctness, as documented in 
>> Documentation/ABI/testing/sys-bus-iio
>> (grep it for "power_mode"). The ABI doc probably would need an addition
>> too, if the 4 power modes here seem generally useful (there are only
>>  2 listed there)!
>>
>> So, if you can test this, feel free to set up a proper patch or
>> two, and I'm happy to review.
>>
>> Please note that this patch is quite old. It really should be that simple
>> as far as my understanding back then. We always list the available 
>> frequencies
>> of the given power mode we are in, for example, already, and everything
>> basically is in place except for the user interface.
> 
> Hmm. A lot of devices support something along these lines.  The issue
> has always been - how is userspace to figure out what to do with it?
> It's all very vague...
> 
> Funnily enough - this used to be really common, but is becoming less so
> now - presumably because no one was using it much (or maybe I am reading
> too much into that ;)
> 
> Now the question is whether it can be tied to better defined things?
> 
> Here low noise restricts the range to 4g.  Issue is that we don't actually
> have writeable _available attributes (which correspond to range in this case).
> 

Does it? Isn't it merely less oversampling.

> Low power mode... This one is apparently oversampling.  If possible support
> it as that as we have well defined interfaces for that.
> 
> Jonathan.

Ah, I remember; the oversampling settings was actually a reason why I
hadn't submitted the patch :) The oversampling API would definitely be
more accurate.

I would like "oversampling" more than this "power_mode" too. For this
driver it would be far more complicated to implement though. I doubt
that it'll be done. power_mode is basically already there implicitely,
and given that there *is* the ABI, we could offer it for free.

But given your concerns, I would strip down this patch to only offer the
already documented "low_noise" and "low_power" modes. It wouldn't be
worth it to extend the ABI just because of this!

Users would have a simple switch if they don't really *want* to know the
details. I think it can be useful to just say "I don't care about power
consuption. Be as accurate as possible" or "I just want this think to
work. Use a little power as possible." Sure it's vage, but would it be
useless?


Re: [PATCH] iio: accel: mma8452: Add single pulse/tap event detection

2017-11-13 Thread Martin Kepplinger

Am 14.11.2017 05:36 schrieb harinath Nampally:

> This patch adds following related changes:
> - defines pulse event related registers
> - enables and handles single pulse interrupt for fxls8471
> - handles IIO_EV_DIR_EITHER in read/write callbacks (because
>   event direction for pulse is either rising or falling)
> - configures read/write event value for pulse latency register
>   using IIO_EV_INFO_HYSTERESIS
> - adds multiple events like pulse and tranient event spec
>   as elements of event_spec array named 'mma8452_accel_events'
>
> Except mma8653 chip all other chips like mma845x and
> fxls8471 have single tap detection feature.
> Tested thoroughly using iio_event_monitor application on
> imx6ul-evk board which has fxls8471.
>
> Signed-off-by: Harinath Nampally 
> ---
What tree is this written against? It doesn't apply to the current 
-next

anyways.

Thanks for the review.
It is actually against 'testing' branch, I think two of my earlier
patches are not yet applied to
any branch, that might be reason this patch is not good against
current -next or 'togreg'.


I think the defintions would deserve to be in a separate patch, but
that's debatable.

Yes, I would argue that definitions are not a logical change.



I would argue definitions don't break the build and maybe slightly 
better

support features like bisect or revert :)


>   .type = IIO_EV_TYPE_MAG,
>   .dir = IIO_EV_DIR_RISING,
>   .mask_separate = BIT(IIO_EV_INFO_ENABLE),
> @@ -1139,6 +1274,15 @@ static const struct iio_event_spec 
mma8452_transient_event[] = {
>   BIT(IIO_EV_INFO_PERIOD) |
>   BIT(IIO_EV_INFO_HIGH_PASS_FILTER_3DB)
>   },
> + {
> + //pulse event
> + .type = IIO_EV_TYPE_MAG,
> + .dir = IIO_EV_DIR_EITHER,
> + .mask_separate = BIT(IIO_EV_INFO_ENABLE),
> + .mask_shared_by_type = BIT(IIO_EV_INFO_VALUE) |
> + BIT(IIO_EV_INFO_PERIOD) |
> + BIT(IIO_EV_INFO_HYSTERESIS)
> + },
>  };
>
>  static const struct iio_event_spec mma8452_motion_event[] = {
> @@ -1202,8 +1346,8 @@ static struct attribute_group 
mma8452_event_attribute_group = {
>   .shift = 16 - (bits), \
>   .endianness = IIO_BE, \
>   }, \
> - .event_spec = mma8452_transient_event, \
> - .num_event_specs = ARRAY_SIZE(mma8452_transient_event), \
> + .event_spec = mma8452_accel_events, \
> + .num_event_specs = ARRAY_SIZE(mma8452_accel_events), \
that would go in the mentioned separate renaming-patch

OK so I will make a patch set; patch 1/2 to just rename
'mma8452_transient_event[]'
to 'mma8452_accel_events[]'(without adding pulse event).
and everything else would go in 2/2. Does that makes sense?



It does to me.


Re: [PATCH] iio: mma8452: add power_mode sysfs configuration

2017-11-13 Thread Martin Kepplinger

Am 14.11.2017 05:56 schrieb harinath Nampally:

Hi Martin,

But given your concerns, I would strip down this patch to only offer 
the

already documented "low_noise" and "low_power" modes. It wouldn't be
worth it to extend the ABI just because of this!

OK then we can map 'low_noise' to high resolution mode. But I am afraid
I can't test the functionality because I don't have proper instruments 
to

measure the current draw(in microAmps) accurately.


I would like "oversampling" more than this "power_mode" too. For this
driver it would be far more complicated to implement though. I doubt
that it'll be done. power_mode is basically already there implicitely,
and given that there *is* the ABI, we could offer it for free.

I think 'oversampling' is already implemented, as I see
'case IIO_CHAN_INFO_OVERSAMPLING_RATIO:'
being handled which is basically setting the all 4 different power 
modes.

If we also add 'power_mode', I think it would be like having two
different user interfaces for
same functionality. So I don't see much of value adding 'power_mode' as 
well.

Please correct me if I am wrong.

Thanks,
Harinath



You're right. I should've looked more closely. oversampling is there and 
seems to
work. No need to blow up this driver or let alone extend an ABI now. 
Let's drop

this patch.

thanks
 martin


On Sun, Nov 12, 2017 at 7:28 AM, Martin Kepplinger  
wrote:

On 2017-11-11 01:33, Jonathan Cameron wrote:

On Mon, 6 Nov 2017 08:19:58 +0100
Martin Kepplinger  wrote:

This adds the power_mode sysfs interface to the device as documented 
in

sysfs-bus-iio.

---

Note that I explicitely don't sign off on this.

This is a starting point for anybody who can test it and check for 
correct
API usage, and ABI correctness, as documented in 
Documentation/ABI/testing/sys-bus-iio
(grep it for "power_mode"). The ABI doc probably would need an 
addition

too, if the 4 power modes here seem generally useful (there are only
 2 listed there)!

So, if you can test this, feel free to set up a proper patch or
two, and I'm happy to review.

Please note that this patch is quite old. It really should be that 
simple
as far as my understanding back then. We always list the available 
frequencies
of the given power mode we are in, for example, already, and 
everything

basically is in place except for the user interface.


Hmm. A lot of devices support something along these lines.  The issue
has always been - how is userspace to figure out what to do with it?
It's all very vague...

Funnily enough - this used to be really common, but is becoming less 
so
now - presumably because no one was using it much (or maybe I am 
reading

too much into that ;)

Now the question is whether it can be tied to better defined things?

Here low noise restricts the range to 4g.  Issue is that we don't 
actually
have writeable _available attributes (which correspond to range in 
this case).




Does it? Isn't it merely less oversampling.

Low power mode... This one is apparently oversampling.  If possible 
support

it as that as we have well defined interfaces for that.

Jonathan.


Ah, I remember; the oversampling settings was actually a reason why I
hadn't submitted the patch :) The oversampling API would definitely be
more accurate.

I would like "oversampling" more than this "power_mode" too. For this
driver it would be far more complicated to implement though. I doubt
that it'll be done. power_mode is basically already there implicitely,
and given that there *is* the ABI, we could offer it for free.

But given your concerns, I would strip down this patch to only offer 
the

already documented "low_noise" and "low_power" modes. It wouldn't be
worth it to extend the ABI just because of this!

Users would have a simple switch if they don't really *want* to know 
the
details. I think it can be useful to just say "I don't care about 
power

consuption. Be as accurate as possible" or "I just want this think to
work. Use a little power as possible." Sure it's vage, but would it be
useless?




[PATCH] kernel: replace FSF address with web source in license notices

2017-11-14 Thread Martin Kepplinger
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "<http://www.gnu.org/licenses/>".

Signed-off-by: Martin Kepplinger 
---

This is an attempt to sneak this in in one go for the kernel directory.
I think it's important to take the license statement serious and to not
confuse users.

If this should go in as seperate patches, each to their lists, please
say so.

thanks

 martin



 kernel/audit.c  | 3 +--
 kernel/audit.h  | 3 +--
 kernel/audit_watch.c| 3 +--
 kernel/auditfilter.c| 3 +--
 kernel/auditsc.c| 3 +--
 kernel/events/hw_breakpoint.c   | 3 +--
 kernel/events/uprobes.c | 3 +--
 kernel/extable.c| 3 +--
 kernel/futex.c  | 3 +--
 kernel/kprobes.c| 3 +--
 kernel/module.c | 3 +--
 kernel/params.c | 3 +--
 kernel/time/timeconv.c  | 3 +--
 kernel/trace/trace_events_filter.c  | 3 +--
 kernel/trace/trace_events_trigger.c | 3 +--
 kernel/trace/trace_kprobe.c | 3 +--
 kernel/trace/trace_probe.c  | 3 +--
 kernel/trace/trace_probe.h  | 3 +--
 kernel/trace/trace_uprobe.c | 3 +--
 kernel/tracepoint.c | 3 +--
 20 files changed, 20 insertions(+), 40 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 227db99b0f19..1aa743f21c0d 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -16,8 +16,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
  *
  * Written by Rickard E. (Rik) Faith 
  *
diff --git a/kernel/audit.h b/kernel/audit.h
index af5bc59487ed..27f01e30a0db 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -15,8 +15,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
  */
 
 #include 
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 9eb8b3511636..93cb46c5dbe1 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -15,8 +15,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
  */
 
 #include 
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 4a1758adb222..5e61702b06cd 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -15,8 +15,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index e80459f7e132..7ef2078334b6 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -17,8 +17,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
  *
  * Written by Rickard E. (Rik) Faith 
  *
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index 3f8cb1e14588..4aaf161870a1 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -10,8 +10,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
  *
  * Copyright (C) 2007 Alan Stern
  * Copyright (C) IBM Corporation, 2009
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 267f6ef91d97..5d9835116f08 100644
--- a/ke

[PATCH] crypto: replace FSF address with web source in license notices

2017-11-14 Thread Martin Kepplinger
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "<http://www.gnu.org/licenses/>".

Signed-off-by: Martin Kepplinger 
---
 crypto/ablk_helper.c  | 4 +---
 crypto/camellia_generic.c | 3 +--
 crypto/cast5_generic.c| 3 +--
 crypto/cast6_generic.c| 3 +--
 crypto/simd.c | 4 +---
 crypto/twofish_common.c   | 5 ++---
 crypto/twofish_generic.c  | 5 ++---
 crypto/xcbc.c | 3 +--
 8 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/crypto/ablk_helper.c b/crypto/ablk_helper.c
index 1441f07d0a19..6e5d2f149b89 100644
--- a/crypto/ablk_helper.c
+++ b/crypto/ablk_helper.c
@@ -18,9 +18,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- * USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  *
  */
 
diff --git a/crypto/camellia_generic.c b/crypto/camellia_generic.c
index a02286bf319e..32ddd4836ff5 100644
--- a/crypto/camellia_generic.c
+++ b/crypto/camellia_generic.c
@@ -13,8 +13,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
 /*
diff --git a/crypto/cast5_generic.c b/crypto/cast5_generic.c
index df5c72629383..66169c178314 100644
--- a/crypto/cast5_generic.c
+++ b/crypto/cast5_generic.c
@@ -16,8 +16,7 @@
 * any later version.
 *
 * You should have received a copy of the GNU General Public License
-* along with this program; if not, write to the Free Software
-* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+* along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */
 
 
diff --git a/crypto/cast6_generic.c b/crypto/cast6_generic.c
index 058c8d755d03..c8e5ec69790e 100644
--- a/crypto/cast6_generic.c
+++ b/crypto/cast6_generic.c
@@ -13,8 +13,7 @@
  * any later version.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
 
diff --git a/crypto/simd.c b/crypto/simd.c
index 88203370a62f..208226d7f908 100644
--- a/crypto/simd.c
+++ b/crypto/simd.c
@@ -19,9 +19,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- * USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  *
  */
 
diff --git a/crypto/twofish_common.c b/crypto/twofish_common.c
index 5f62c4f9f6e0..f3a0dd25f871 100644
--- a/crypto/twofish_common.c
+++ b/crypto/twofish_common.c
@@ -24,9 +24,8 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- * USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
  *
  * This code is a "clean room" implementation, written from the paper
  * _Twofish: A 128-Bit Block Cipher_ by Bruce Schneier, John Kelsey,
diff --git a/crypto/twofish_generic.c b/crypto/twofish_generic.c
index ebf7a3efb572..07e62433fbfb 100644
--- a/crypto/twofish_generic.c
+++ b/crypto/twofish_generic.c
@@ -23,9 +23,8 @@
  * GNU General Public License for more details.
  * 
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- * USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
  *
  * This code is a "clean room" implementation, written from the paper
  * _Twofish: A 128-Bit Block Cipher_ by Bruce Schneier, John Kelsey,
diff --git a/crypto/xcbc.c b/crypto/xcbc.c
index df90b332554c..25c75af50d3f 100644
--- a/crypto/xcbc.c
+++ b/crypto/xcbc.c
@@ -12,8 +12,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write 

[PATCH] init: replace FSF address with web source in license notices

2017-11-14 Thread Martin Kepplinger
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "<http://www.gnu.org/licenses/>".

Signed-off-by: Martin Kepplinger 
---
 init/noinitramfs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/init/noinitramfs.c b/init/noinitramfs.c
index 267739d85179..3ee9e3dbfbc4 100644
--- a/init/noinitramfs.c
+++ b/init/noinitramfs.c
@@ -14,8 +14,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 #include 
 #include 
-- 
2.11.0



[PATCH] lib: replace FSF address with web source in license notices

2017-11-14 Thread Martin Kepplinger
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "<http://www.gnu.org/licenses/>" in the lib directory.

Signed-off-by: Martin Kepplinger 
---

This is an attempt to sneak this in for the lib subdirectory in one go.
If you would rather have the changes individually go to the relevant
people, please just say so.

thanks
   martin


 lib/decompress_unlzo.c| 3 +--
 lib/dma-debug.c   | 3 +--
 lib/flex_array.c  | 3 +--
 lib/llist.c   | 3 +--
 lib/mpi/generic_mpih-add1.c   | 3 +--
 lib/mpi/generic_mpih-lshift.c | 3 +--
 lib/mpi/generic_mpih-mul1.c   | 3 +--
 lib/mpi/generic_mpih-mul2.c   | 3 +--
 lib/mpi/generic_mpih-mul3.c   | 3 +--
 lib/mpi/generic_mpih-rshift.c | 3 +--
 lib/mpi/generic_mpih-sub1.c   | 3 +--
 lib/mpi/longlong.h| 5 ++---
 lib/mpi/mpi-bit.c | 3 +--
 lib/mpi/mpi-cmp.c | 3 +--
 lib/mpi/mpi-inline.h  | 3 +--
 lib/mpi/mpi-internal.h| 3 +--
 lib/mpi/mpi-pow.c | 3 +--
 lib/mpi/mpicoder.c| 3 +--
 lib/mpi/mpih-cmp.c| 3 +--
 lib/mpi/mpih-div.c| 3 +--
 lib/mpi/mpih-mul.c| 3 +--
 lib/mpi/mpiutil.c | 3 +--
 lib/rbtree.c  | 3 +--
 lib/timerqueue.c  | 3 +--
 24 files changed, 25 insertions(+), 49 deletions(-)

diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
index f4c158e3a022..fa71c4dc0542 100644
--- a/lib/decompress_unlzo.c
+++ b/lib/decompress_unlzo.c
@@ -22,8 +22,7 @@
  *
  * You should have received a copy of the GNU General Public License
  * along with this program; see the file COPYING.
- * If not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ * If not, see <http://www.gnu.org/licenses/>.
  *
  * Markus F.X.J. Oberhumer
  * 
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index e5b4237da650..d76e5c1a495c 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -13,8 +13,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
 #include 
diff --git a/lib/flex_array.c b/lib/flex_array.c
index 2eed22fa507c..234895ab27d9 100644
--- a/lib/flex_array.c
+++ b/lib/flex_array.c
@@ -12,8 +12,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  *
  * Copyright IBM Corporation, 2009
  *
diff --git a/lib/llist.c b/lib/llist.c
index 7062e931a7bb..a56ba9f0350e 100644
--- a/lib/llist.c
+++ b/lib/llist.c
@@ -19,8 +19,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 #include 
 #include 
diff --git a/lib/mpi/generic_mpih-add1.c b/lib/mpi/generic_mpih-add1.c
index c94c7dd344b3..3c3e94556adb 100644
--- a/lib/mpi/generic_mpih-add1.c
+++ b/lib/mpi/generic_mpih-add1.c
@@ -15,8 +15,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  *
  * Note: This code is heavily based on the GNU MP Library.
  *  Actually it's the same code with only minor changes in the
diff --git a/lib/mpi/generic_mpih-lshift.c b/lib/mpi/generic_mpih-lshift.c
index 86318927231a..84d0d800996c 100644
--- a/lib/mpi/generic_mpih-lshift.c
+++ b/lib/mpi/generic_mpih-lshift.c
@@ -14,8 +14,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  *
  * Note: This code is heavily based on the GNU MP Library.
  *  Act

[PATCH] mm: replace FSF address with web source in license notices

2017-11-14 Thread Martin Kepplinger
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "<http://www.gnu.org/licenses/>" in the mm directory.

Signed-off-by: Martin Kepplinger 
---
 mm/kmemleak-test.c | 3 +--
 mm/kmemleak.c  | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/mm/kmemleak-test.c b/mm/kmemleak-test.c
index dd3c23a801b1..9a13ad2c0cca 100644
--- a/mm/kmemleak-test.c
+++ b/mm/kmemleak-test.c
@@ -14,8 +14,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
 #define pr_fmt(fmt) "kmemleak: " fmt
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index e4738d5e9b8c..e6d6d3c9f543 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -14,8 +14,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  *
  *
  * For more information on the algorithm and kmemleak usage, please see
-- 
2.11.0



[PATCH] samples: replace FSF address with web source in license notices

2017-11-14 Thread Martin Kepplinger
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "<http://www.gnu.org/licenses/>" in the samples
directory.

Signed-off-by: Martin Kepplinger 
---
 samples/auxdisplay/cfag12864b-example.c | 3 +--
 samples/configfs/configfs_sample.c  | 6 ++
 samples/connector/cn_test.c | 3 +--
 samples/connector/ucon.c| 3 +--
 samples/hw_breakpoint/data_breakpoint.c | 3 +--
 5 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/samples/auxdisplay/cfag12864b-example.c 
b/samples/auxdisplay/cfag12864b-example.c
index e7823ffb1ca0..fc8b4c6c655f 100644
--- a/samples/auxdisplay/cfag12864b-example.c
+++ b/samples/auxdisplay/cfag12864b-example.c
@@ -17,8 +17,7 @@
  *  GNU General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *  along with this program.  If not, see <http://www.gnu.org/licenses/>.
  *
  */
 
diff --git a/samples/configfs/configfs_sample.c 
b/samples/configfs/configfs_sample.c
index 004a4e201476..43810e6c745d 100644
--- a/samples/configfs/configfs_sample.c
+++ b/samples/configfs/configfs_sample.c
@@ -15,10 +15,8 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  * General Public License for more details.
  *
- * You should have received a copy of the GNU General Public
- * License along with this program; if not, write to the
- * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
- * Boston, MA 021110-1307, USA.
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  *
  * Based on sysfs:
  * sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel
diff --git a/samples/connector/cn_test.c b/samples/connector/cn_test.c
index 95cd06f4ec1e..48dfe47e65a5 100644
--- a/samples/connector/cn_test.c
+++ b/samples/connector/cn_test.c
@@ -15,8 +15,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
 #define pr_fmt(fmt) "cn_test: " fmt
diff --git a/samples/connector/ucon.c b/samples/connector/ucon.c
index 8a4da64e02a8..1943aba7e903 100644
--- a/samples/connector/ucon.c
+++ b/samples/connector/ucon.c
@@ -15,8 +15,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
 #include 
diff --git a/samples/hw_breakpoint/data_breakpoint.c 
b/samples/hw_breakpoint/data_breakpoint.c
index ef7f32291852..7ff5db0ccfe9 100644
--- a/samples/hw_breakpoint/data_breakpoint.c
+++ b/samples/hw_breakpoint/data_breakpoint.c
@@ -12,8 +12,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  *
  * usage: insmod data_breakpoint.ko ksym=
  *
-- 
2.11.0



Re: [PATCH] mm: replace FSF address with web source in license notices

2017-11-14 Thread Martin Kepplinger

Am 14.11.2017 10:49 schrieb Michal Hocko:

On Tue 14-11-17 10:44:38, Martin Kepplinger wrote:
A few years ago the FSF moved and "59 Temple Place" is wrong. Having 
this

still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace 
the
postal address with "<http://www.gnu.org/licenses/>" in the mm 
directory.


Why to change this now? Isn't there a general plan to move to SPDX?


Shouldn't a move to SPDX only be additions to what we currently have? 
That's
at least what the "reuse" project suggests, see 
https://reuse.software/practices/

with "Don’t remove existing headers, but only add to them."

thanks

   martin



[PATCH] scripts: replace FSF address with web source in license notices

2017-11-14 Thread Martin Kepplinger
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "<http://www.gnu.org/licenses/>" in the scripts
directory.

Signed-off-by: Martin Kepplinger 
---
 scripts/dtc/checks.c| 4 +---
 scripts/dtc/data.c  | 4 +---
 scripts/dtc/dtc-lexer.l | 4 +---
 scripts/dtc/dtc-lexer.lex.c_shipped | 4 +---
 scripts/dtc/dtc-parser.y| 4 +---
 scripts/dtc/dtc.c   | 4 +---
 scripts/dtc/fdtget.c| 4 +---
 scripts/dtc/fdtput.c| 4 +---
 scripts/dtc/flattree.c  | 4 +---
 scripts/dtc/fstree.c| 4 +---
 scripts/dtc/livetree.c  | 4 +---
 scripts/dtc/srcpos.c| 4 +---
 scripts/dtc/srcpos.h| 4 +---
 scripts/dtc/treesource.c| 4 +---
 scripts/dtc/util.c  | 4 +---
 scripts/dtc/util.h  | 4 +---
 scripts/genksyms/genksyms.c | 4 ++--
 scripts/genksyms/genksyms.h | 4 ++--
 scripts/genksyms/lex.l  | 4 ++--
 scripts/genksyms/lex.lex.c_shipped  | 4 ++--
 scripts/genksyms/parse.y| 4 ++--
 scripts/selinux/mdp/mdp.c   | 3 +--
 22 files changed, 27 insertions(+), 60 deletions(-)

diff --git a/scripts/dtc/checks.c b/scripts/dtc/checks.c
index e66138449886..27dd1e0de47a 100644
--- a/scripts/dtc/checks.c
+++ b/scripts/dtc/checks.c
@@ -13,9 +13,7 @@
  *  General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- *   USA
+ *  along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
 #include "dtc.h"
diff --git a/scripts/dtc/data.c b/scripts/dtc/data.c
index aa37a16c8891..ed6ab5817603 100644
--- a/scripts/dtc/data.c
+++ b/scripts/dtc/data.c
@@ -13,9 +13,7 @@
  *  General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- *   USA
+ *  along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
 #include "dtc.h"
diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
index fd825ebba69c..164798e6e9ce 100644
--- a/scripts/dtc/dtc-lexer.l
+++ b/scripts/dtc/dtc-lexer.l
@@ -13,9 +13,7 @@
  *  General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- *   USA
+ *  along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
 %option noyywrap nounput noinput never-interactive
diff --git a/scripts/dtc/dtc-lexer.lex.c_shipped 
b/scripts/dtc/dtc-lexer.lex.c_shipped
index 011bb9632ff2..fd5b12a283be 100644
--- a/scripts/dtc/dtc-lexer.lex.c_shipped
+++ b/scripts/dtc/dtc-lexer.lex.c_shipped
@@ -618,9 +618,7 @@ char *yytext;
  *  General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- *   USA
+ *  along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 #define YY_NO_INPUT 1
 
diff --git a/scripts/dtc/dtc-parser.y b/scripts/dtc/dtc-parser.y
index affc81a8f9ab..e3a3b155ace8 100644
--- a/scripts/dtc/dtc-parser.y
+++ b/scripts/dtc/dtc-parser.y
@@ -13,9 +13,7 @@
  *  General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- *   USA
+ *  along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 %{
 #include 
diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index 5ed873c72ad1..da967e7a8050 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -13,9 +13,7 @@
  *  General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, wri

[PATCH] security: replace FSF address with web source in license notices

2017-11-14 Thread Martin Kepplinger
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "<http://www.gnu.org/licenses/>" in the security
directory.

Signed-off-by: Martin Kepplinger 
---
 security/selinux/include/netlabel.h | 3 +--
 security/selinux/netlabel.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/security/selinux/include/netlabel.h 
b/security/selinux/include/netlabel.h
index 75686d53df07..e77a5e307955 100644
--- a/security/selinux/include/netlabel.h
+++ b/security/selinux/include/netlabel.h
@@ -19,8 +19,7 @@
  * the GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program;  if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  *
  */
 
diff --git a/security/selinux/netlabel.c b/security/selinux/netlabel.c
index aaba6677ee2e..2c297b995b16 100644
--- a/security/selinux/netlabel.c
+++ b/security/selinux/netlabel.c
@@ -22,8 +22,7 @@
  * the GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program;  if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  *
  */
 
-- 
2.11.0



Re: [PATCH] mm: replace FSF address with web source in license notices

2017-11-14 Thread Martin Kepplinger

Am 14.11.2017 11:02 schrieb Michal Hocko:

On Tue 14-11-17 10:55:35, Martin Kepplinger wrote:

Am 14.11.2017 10:49 schrieb Michal Hocko:
> On Tue 14-11-17 10:44:38, Martin Kepplinger wrote:
> > A few years ago the FSF moved and "59 Temple Place" is wrong. Having
> > this
> > still in our source files feels old and unmaintained.
> >
> > Let's take the license statement serious and not confuse users.
> >
> > As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace
> > the
> > postal address with "<http://www.gnu.org/licenses/>" in the mm
> > directory.
>
> Why to change this now? Isn't there a general plan to move to SPDX?

Shouldn't a move to SPDX only be additions to what we currently have? 
That's

at least what the "reuse" project suggests, see
https://reuse.software/practices/
with "Don’t remove existing headers, but only add to them."


I thought the primary motivation was to unify _all_ headers and get rid
of all the duplication. (aside from files which do not have any license
which is under discussion elsewhere).


I doubt that this can be fully accieved in the long run :) It'd be nice 
of course in

some way.

But I also doubt that it'd be so easy to remove the permission 
statements.

The FSF who's license we use suggest to have them, but others do too.
And as mentioned, "using SPDX" doesn't imply "not having permission
statements".

But I think that's off-topic actually. Moving to SPDX could still be 
done in
any way whatsoever after this. This change fixes a *mistake* and can 
reduce

confusion or even support license compliance, who knows :)

thanks
martin



Re: [PATCH v4 2/2] iio: accel: mma8452: Rename config structs for readability

2017-11-05 Thread Martin Kepplinger
On 2017-11-05 19:00, Harinath Nampally wrote:
> Rename structs holding event configuration registers
> to more appropriate names. This naming is consistent
> with the event config register names given in the
> mma845x and fxls8471 datasheets.
> 
> Signed-off-by: Harinath Nampally 

Makes sense to me.

Acked-by: Martin Kepplinger 


Hey Harinath,

I think it'd be great to have the "power_mode" iio ABI interface
for mma8452 too, and I just found an old patch pf mine for this.

If you say you could test it and check for correct API usage and
ABI provisioning in sysfs, I'd be happy to publish it for you to
make any necessary corrections and submit it after testing.

Do we have a deal?

thanks

 martin


Re: [PATCH v4 1/2] iio: accel: mma8452: Rename a struct for code readibility

2017-11-05 Thread Martin Kepplinger
On 2017-11-05 19:00, Harinath Nampally wrote:
> Rename time step look up struct to generic name
> as the values in the look table are same for all
> the other events like pulse, transient etc.
> 
> Signed-off-by: Harinath Nampally 

Acked-by: Martin Kepplinger 



[PATCH] iio: mma8452: add power_mode sysfs configuration

2017-11-05 Thread Martin Kepplinger
This adds the power_mode sysfs interface to the device as documented in
sysfs-bus-iio.

---

Note that I explicitely don't sign off on this.

This is a starting point for anybody who can test it and check for correct
API usage, and ABI correctness, as documented in 
Documentation/ABI/testing/sys-bus-iio
(grep it for "power_mode"). The ABI doc probably would need an addition
too, if the 4 power modes here seem generally useful (there are only
 2 listed there)!

So, if you can test this, feel free to set up a proper patch or
two, and I'm happy to review.

Please note that this patch is quite old. It really should be that simple
as far as my understanding back then. We always list the available frequencies
of the given power mode we are in, for example, already, and everything
basically is in place except for the user interface.

thanks
martin



 drivers/iio/accel/mma8452.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index bfd4bc806fc2..640bbd9872ab 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -1166,6 +1166,41 @@ static struct attribute_group 
mma8452_event_attribute_group = {
.attrs = mma8452_event_attributes,
 };
 
+static const char * const mma8452_power_modes[] = {"normal",
+  "low_noise_low_power",
+  "low_noise",
+  "low_power"};
+
+static int mma8452_get_power_mode_iio_enum(struct iio_dev *indio_dev,
+  const struct iio_chan_spec *chan)
+{
+   struct mma8452_data *data = iio_priv(indio_dev);
+
+   return mma8452_get_power_mode(data);
+}
+
+static int mma8452_set_power_mode_iio_enum(struct iio_dev *indio_dev,
+  const struct iio_chan_spec *chan,
+  unsigned int mode)
+{
+   struct mma8452_data *data = iio_priv(indio_dev);
+
+   return mma8452_set_power_mode(data, mode);
+}
+
+static const struct iio_enum mma8452_power_mode_enum = {
+   .items = mma8452_power_modes,
+   .num_items = ARRAY_SIZE(mma8452_power_modes),
+   .get = mma8452_get_power_mode_iio_enum,
+   .set = mma8452_set_power_mode_iio_enum,
+};
+
+static const struct iio_chan_spec_ext_info mma8452_ext_info[] = {
+   IIO_ENUM("power_mode", true, &mma8452_power_mode_enum),
+   IIO_ENUM_AVAILABLE("power_mode", &mma8452_power_mode_enum),
+   { },
+};
+
 #define MMA8452_FREEFALL_CHANNEL(modifier) { \
.type = IIO_ACCEL, \
.modified = 1, \
@@ -1204,6 +1239,7 @@ static struct attribute_group 
mma8452_event_attribute_group = {
}, \
.event_spec = mma8452_transient_event, \
.num_event_specs = ARRAY_SIZE(mma8452_transient_event), \
+   .ext_info = mma8452_ext_info, \
 }
 
 #define MMA8652_CHANNEL(axis, idx, bits) { \
@@ -1225,6 +1261,7 @@ static struct attribute_group 
mma8452_event_attribute_group = {
}, \
.event_spec = mma8452_motion_event, \
.num_event_specs = ARRAY_SIZE(mma8452_motion_event), \
+   .ext_info = mma8452_ext_info, \
 }
 
 static const struct iio_chan_spec mma8451_channels[] = {
-- 
2.11.0



Re: [PATCH] platform: acer-wmi: update notice about deprecated user interface

2015-10-05 Thread Martin Kepplinger
Am 2015-10-05 um 12:30 schrieb joeyli:
> Hi Darren, 
> 
> On Sat, Oct 03, 2015 at 10:20:52AM -0700, Darren Hart wrote:
>> On Tue, Sep 29, 2015 at 05:50:32PM +0800, joeyli wrote:
>>> Hi Martin, 
>>>
>>> On Tue, Sep 29, 2015 at 08:46:38AM +0200, Martin Kepplinger wrote:
>>>> Signed-off-by: Martin Kepplinger 
>>>> ---
>>>> This just looks odd in the logs. Feel free to ignore it or act on it
>>>> differently ;)
>>>>
>>>>
>>>
>>> Thanks for your patch and it reminds me to remove those interfaces in 
>>> acer-wmi.
>>> Please let me check and I am thinking direct remove those interfaces.
>>
>> Joey, I will wait to hear from you on this patch (or a replacement).
>>
>> Thanks,
>>
> 
> Thanks for your reminding. I just sent patch to remove sysfs interface of 
> acer-wmi.
> 
> Joey Lee
> 

I have to leave the estimation whether this old interface won't have
users to you and others, but if it's ok, it's nice to see dead code
removed! thanks,

  martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 4/6] iio: mma8452: add support for MMA8652FC and MMA8653FC

2015-09-01 Thread Martin Kepplinger
MMA8652FC and MMA8653FC don't provide the transient interrupt source, so
the motion interrupt source is used by providing a new iio_chan_spec
definition, so that other supported devices are not affected by this.

Datasheets for the newly supported devices are available at Freescale's
website:

http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8652FC.pdf
http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8653FC.pdf

Signed-off-by: Martin Kepplinger 
Signed-off-by: Christoph Muellner 
---
 .../devicetree/bindings/iio/accel/mma8452.txt  |  4 +-
 drivers/iio/accel/Kconfig  |  2 +-
 drivers/iio/accel/mma8452.c| 98 --
 3 files changed, 95 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index c3bc272..e3c3746 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -1,10 +1,12 @@
-Freescale MMA8452Q or MMA8453Q triaxial accelerometer
+Freescale MMA8452Q, MMA8453Q, MMA8652FC or MMA8653FC triaxial accelerometer
 
 Required properties:
 
   - compatible: should contain one of
 * "fsl,mma8452"
 * "fsl,mma8453"
+* "fsl,mma8652"
+* "fsl,mma8653"
   - reg: the I2C address of the chip
 
 Optional properties:
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index e4075a0..a37155d 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -106,7 +106,7 @@ config MMA8452
select IIO_TRIGGERED_BUFFER
help
  Say yes here to build support for the following Freescale 3-axis
- accelerometers: MMA8452Q, MMA8453Q.
+ accelerometers: MMA8452Q, MMA8453Q, MMA8652FC, MMA8653FC.
 
  To compile this driver as a module, choose M here: the module
  will be called mma8452.
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 6b1a862..59b4455 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -3,6 +3,8 @@
  *
  * MMA8452Q (12 bit)
  * MMA8453Q (10 bit)
+ * MMA8652FC (12 bit)
+ * MMA8653FC (10 bit)
  *
  * Copyright 2014 Peter Meerwald 
  *
@@ -84,6 +86,8 @@
 
 #define  MMA8452_DEVICE_ID 0x2a
 #define  MMA8453_DEVICE_ID 0x3a
+#define MMA8652_DEVICE_ID  0x4a
+#define MMA8653_DEVICE_ID  0x5a
 
 struct mma8452_data {
struct i2c_client *client;
@@ -791,6 +795,26 @@ static struct attribute_group 
mma8452_event_attribute_group = {
.num_event_specs = ARRAY_SIZE(mma8452_transient_event), \
 }
 
+#define MMA8652_CHANNEL(axis, idx, bits) { \
+   .type = IIO_ACCEL, \
+   .modified = 1, \
+   .channel2 = IIO_MOD_##axis, \
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+   BIT(IIO_CHAN_INFO_CALIBBIAS), \
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
+   BIT(IIO_CHAN_INFO_SCALE), \
+   .scan_index = idx, \
+   .scan_type = { \
+   .sign = 's', \
+   .realbits = (bits), \
+   .storagebits = 16, \
+   .shift = 16 - (bits), \
+   .endianness = IIO_BE, \
+   }, \
+   .event_spec = mma8452_motion_event, \
+   .num_event_specs = ARRAY_SIZE(mma8452_motion_event), \
+}
+
 static const struct iio_chan_spec mma8452_channels[] = {
MMA8452_CHANNEL(X, 0, 12),
MMA8452_CHANNEL(Y, 1, 12),
@@ -805,9 +829,25 @@ static const struct iio_chan_spec mma8453_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(3),
 };
 
+static const struct iio_chan_spec mma8652_channels[] = {
+   MMA8652_CHANNEL(X, 0, 12),
+   MMA8652_CHANNEL(Y, 1, 12),
+   MMA8652_CHANNEL(Z, 2, 12),
+   IIO_CHAN_SOFT_TIMESTAMP(3),
+};
+
+static const struct iio_chan_spec mma8653_channels[] = {
+   MMA8652_CHANNEL(X, 0, 10),
+   MMA8652_CHANNEL(Y, 1, 10),
+   MMA8652_CHANNEL(Z, 2, 10),
+   IIO_CHAN_SOFT_TIMESTAMP(3),
+};
+
 enum {
mma8452,
mma8453,
+   mma8652,
+   mma8653,
 };
 
 static const struct mma_chip_info mma_chip_info_table[] = {
@@ -850,6 +890,38 @@ static const struct mma_chip_info mma_chip_info_table[] = {
.ev_ths_mask = MMA8452_TRANSIENT_THS_MASK,
.ev_count = MMA8452_TRANSIENT_COUNT,
},
+   [mma8652] = {
+   .chip_id = MMA8652_DEVICE_ID,
+   .channels = mma8652_channels,
+   .num_channels = ARRAY_SIZE(mma8652_channels),
+   .mma_scales = { {0, 9577}, {0, 19154}, {0, 38307} },
+   .ev_cfg = MMA8452_FF_MT_CFG,
+   .ev_cfg_ele = MMA8452_FF_MT_CFG_ELE,
+   .ev_cfg_chan_shift = 3,
+   .ev_src = MMA8452_FF_MT_SRC,
+   .ev_src_xe = MMA8452_FF_MT

[PATCHv6 0/6] iio: mma8452: improve driver and support more chips

2015-09-01 Thread Martin Kepplinger
Version 6 of the mma8452 driver improvements. This is rebased on the current
-next tree because of cleanup changes in the meantime. Also, the patches are
slightly more cleaned up (adding the DT bindings document in the right patch).
Here we go:


These changes add support for motion interrupts and 3 more accelerometer
chips, two of which use them because they don't support the until now
included transient interrupt sources:

MMA8453Q, MMA8652FC and MMA8653FC; datasheets are in the commit messages.
The driver and module name remains the same, seperating it from the device
names it now supports.

Please review and test if you can. For MMA8452Q, nothing should have
changed.

revision history

v6   rebase! remove one patch (adding a new DT property). minor patch cleanup.
v5   DRIVER_NAME define removed; more flexible DT property
v4   cleanup; one bugfix patch removed from series; DT people added
v3   adds one patch to allow all possible pin wirings; adds more email
recipients
v2   splits the work into a series of smaller pieces
v1   initial post

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2/6] iio: mma8452: add support for MMA8453Q accelerometer chip

2015-09-01 Thread Martin Kepplinger
This adds support for the 10 bit version if Freescale's accelerometers
of this series. The datasheet is available at Freescale's website:

http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8453Q.pdf

It creates a devicetree bindings file to document the new functionality
and removes the driver from the trivial-devices list.

Signed-off-by: Martin Kepplinger 
Signed-off-by: Christoph Muellner 
---
 .../devicetree/bindings/i2c/trivial-devices.txt|  1 -
 .../devicetree/bindings/iio/accel/mma8452.txt  | 22 +
 drivers/iio/accel/Kconfig  |  6 ++--
 drivers/iio/accel/mma8452.c| 37 --
 4 files changed, 59 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/accel/mma8452.txt

diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index d77d412..a50e56d 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -54,7 +54,6 @@ epson,rx8581  I2C-BUS INTERFACE REAL TIME CLOCK MODULE
 fsl,mag3110MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
 fsl,mc13892MC13892: Power Management Integrated Circuit (PMIC) for 
i.MX35/51
 fsl,mma8450MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic 
Accelerometer
-fsl,mma8452MMA8452Q: 3-axis 12-bit / 8-bit Digital Accelerometer
 fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
 fsl,sgtl5000   SGTL5000: Ultra Low-Power Audio Codec
 gmt,g751   G751: Digital Temperature Sensor and Thermal Watchdog 
with Two-Wire Interface
diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
new file mode 100644
index 000..c3bc272
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -0,0 +1,22 @@
+Freescale MMA8452Q or MMA8453Q triaxial accelerometer
+
+Required properties:
+
+  - compatible: should contain one of
+* "fsl,mma8452"
+* "fsl,mma8453"
+  - reg: the I2C address of the chip
+
+Optional properties:
+
+  - interrupt-parent: should be the phandle for the interrupt controller
+  - interrupts: interrupt mapping for GPIO IRQ
+
+Example:
+
+   mma8453fc@1d {
+   compatible = "fsl,mma8453";
+   reg = <0x1d>;
+   interrupt-parent = <&gpio1>;
+   interrupts = <5 0>;
+   };
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index a59047d..e4075a0 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -100,13 +100,13 @@ config KXCJK1013
  be called kxcjk-1013.
 
 config MMA8452
-   tristate "Freescale MMA8452Q Accelerometer Driver"
+   tristate "Freescale MMA8452Q and similar Accelerometers Driver"
depends on I2C
select IIO_BUFFER
select IIO_TRIGGERED_BUFFER
help
- Say yes here to build support for the Freescale MMA8452Q 3-axis
- accelerometer.
+ Say yes here to build support for the following Freescale 3-axis
+ accelerometers: MMA8452Q, MMA8453Q.
 
  To compile this driver as a module, choose M here: the module
  will be called mma8452.
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index f28428fa..7b2ab17 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -1,5 +1,8 @@
 /*
- * mma8452.c - Support for Freescale MMA8452Q 3-axis 12-bit accelerometer
+ * mma8452.c - Support for following Freescale 3-axis accelerometers:
+ *
+ * MMA8452Q (12 bit)
+ * MMA8453Q (10 bit)
  *
  * Copyright 2014 Peter Meerwald 
  *
@@ -26,7 +29,7 @@
 
 #define MMA8452_STATUS 0x00
 #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) | BIT(0))
-#define MMA8452_OUT_X  0x01 /* MSB first, 12-bit  */
+#define MMA8452_OUT_X  0x01 /* MSB first */
 #define MMA8452_OUT_Y  0x03
 #define MMA8452_OUT_Z  0x05
 #define MMA8452_INT_SRC0x0c
@@ -69,6 +72,7 @@
 #define  MMA8452_INT_TRANS BIT(5)
 
 #define  MMA8452_DEVICE_ID 0x2a
+#define  MMA8453_DEVICE_ID 0x3a
 
 struct mma8452_data {
struct i2c_client *client;
@@ -768,8 +772,16 @@ static const struct iio_chan_spec mma8452_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(3),
 };
 
+static const struct iio_chan_spec mma8453_channels[] = {
+   MMA8452_CHANNEL(X, 0, 10),
+   MMA8452_CHANNEL(Y, 1, 10),
+   MMA8452_CHANNEL(Z, 2, 10),
+   IIO_CHAN_SOFT_TIMESTAMP(3),
+};
+
 enum {
mma8452,
+   mma8453,
 };
 
 static const struct mma_chip_inf

[PATCH 1/6] iio: mma8452: refactor for seperating chip specific data

2015-09-01 Thread Martin Kepplinger
This adds a struct mma_chip_info to hold data that will remain specific to
the chip in use. It is provided during probe() and linked in
struct of_device_id.

Also this suggests that the driver is called "mma8452" and now handles the
MMA8452Q device, but is not limited to it.

Signed-off-by: Martin Kepplinger 
Signed-off-by: Christoph Muellner 
---
 drivers/iio/accel/mma8452.c | 183 
 1 file changed, 134 insertions(+), 49 deletions(-)

diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index b921d84..f28428fa 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MMA8452_STATUS 0x00
 #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) | BIT(0))
@@ -74,6 +75,52 @@ struct mma8452_data {
struct mutex lock;
u8 ctrl_reg1;
u8 data_cfg;
+   const struct mma_chip_info *chip_info;
+};
+
+/**
+ * struct mma_chip_info - chip specific data for Freescale's accelerometers
+ * @chip_id:   WHO_AM_I register's value
+ * @channels:  struct iio_chan_spec matching the device's
+ * capabilities
+ * @num_channels:  number of channels
+ * @mma_scales:scale factors for converting register 
values
+ * to m/s^2; 3 modes: 2g, 4g, 8g; 2 integers
+ * per mode: m/s^2 and micro m/s^2
+ * @ev_cfg:event config register address
+ * @ev_cfg_ele:latch bit in event config register
+ * @ev_cfg_chan_shift: number of the bit to enable events in X
+ * direction; in event config register
+ * @ev_src:event source register address
+ * @ev_src_xe: bit in event source register that indicates
+ * an event in X direction
+ * @ev_src_ye: bit in event source register that indicates
+ * an event in Y direction
+ * @ev_src_ze: bit in event source register that indicates
+ * an event in Z direction
+ * @ev_ths:event threshold register address
+ * @ev_ths_mask:   mask for the threshold value
+ * @ev_count:  event count (period) register address
+ *
+ * Since not all chips supported by the driver support comparing high pass
+ * filtered data for events (interrupts), different interrupt sources are
+ * used for different chips and the relevant registers are included here.
+ */
+struct mma_chip_info {
+   u8 chip_id;
+   const struct iio_chan_spec *channels;
+   int num_channels;
+   const int mma_scales[3][2];
+   u8 ev_cfg;
+   u8 ev_cfg_ele;
+   u8 ev_cfg_chan_shift;
+   u8 ev_src;
+   u8 ev_src_xe;
+   u8 ev_src_ye;
+   u8 ev_src_ze;
+   u8 ev_ths;
+   u8 ev_ths_mask;
+   u8 ev_count;
 };
 
 static int mma8452_drdy(struct mma8452_data *data)
@@ -143,16 +190,6 @@ static const int mma8452_samp_freq[8][2] = {
{6, 25}, {1, 56}
 };
 
-/*
- * Hardware has fullscale of -2G, -4G, -8G corresponding to raw value -2048
- * The userspace interface uses m/s^2 and we declare micro units
- * So scale factor is given by:
- * g * N * 100 / 2048 for N = 2, 4, 8 and g = 9.80665
- */
-static const int mma8452_scales[3][2] = {
-   {0, 9577}, {0, 19154}, {0, 38307}
-};
-
 /* Datasheet table 35  (step time vs sample frequency) */
 static const int mma8452_transient_time_step_us[8] = {
1250,
@@ -189,8 +226,11 @@ static ssize_t mma8452_show_scale_avail(struct device *dev,
struct device_attribute *attr,
char *buf)
 {
-   return mma8452_show_int_plus_micros(buf, mma8452_scales,
-   ARRAY_SIZE(mma8452_scales));
+   struct mma8452_data *data = iio_priv(i2c_get_clientdata(
+to_i2c_client(dev)));
+
+   return mma8452_show_int_plus_micros(buf, data->chip_info->mma_scales,
+   ARRAY_SIZE(data->chip_info->mma_scales));
 }
 
 static ssize_t mma8452_show_hp_cutoff_avail(struct device *dev,
@@ -221,9 +261,8 @@ static int mma8452_get_samp_freq_index(struct mma8452_data 
*data,
 
 static int mma8452_get_scale_index(struct mma8452_data *data, int val, int 
val2)
 {
-   return mma8452_get_int_plus_micros_index(mma8452_scales,
-ARRAY_SIZE(mma8452_scales),
-val, val2);
+   return mma8452_get_int_plus_micros_index(data->chip_info->mma_scales,
+   ARRAY_SIZE(data->chip_info->mma_scales), val, val2);
 }
 
 static in

[PATCH 5/6] iio: mma8452: add copyright notice comment

2015-09-01 Thread Martin Kepplinger
Signed-off-by: Martin Kepplinger 
Signed-off-by: Christoph Muellner 
---
 drivers/iio/accel/mma8452.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 59b4455..15d50c9 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -6,6 +6,7 @@
  * MMA8652FC (12 bit)
  * MMA8653FC (10 bit)
  *
+ * Copyright 2015 Martin Kepplinger 
  * Copyright 2014 Peter Meerwald 
  *
  * This file is subject to the terms and conditions of version 2 of
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 6/6] iio: mma8452: leave sysfs namings to the iio core

2015-09-01 Thread Martin Kepplinger
This doesn't actually change anything since the core names the sysfs folder
for the iio event attributes "events" anyways. It only leaves the job to the
core.

Signed-off-by: Martin Kepplinger 
Signed-off-by: Christoph Muellner 
---
 drivers/iio/accel/mma8452.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 15d50c9..1eccc2d 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -772,7 +772,6 @@ static struct attribute *mma8452_event_attributes[] = {
 
 static struct attribute_group mma8452_event_attribute_group = {
.attrs = mma8452_event_attributes,
-   .name = "events",
 };
 
 #define MMA8452_CHANNEL(axis, idx, bits) { \
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3/6] iio: mma8452: add freefall / motion interrupt source

2015-09-01 Thread Martin Kepplinger
This adds the freefall / motion interrupt source definitions to the driver.
It is used in this series' next patch, for chips that don't support the
transient interrupt source.

Signed-off-by: Martin Kepplinger 
Signed-off-by: Christoph Muellner 
---
 drivers/iio/accel/mma8452.c | 44 
 1 file changed, 36 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 7b2ab17..6b1a862 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -42,6 +42,16 @@
 #define  MMA8452_DATA_CFG_HPF_MASK BIT(4)
 #define MMA8452_HP_FILTER_CUTOFF   0x0f
 #define  MMA8452_HP_FILTER_CUTOFF_SEL_MASK GENMASK(1, 0)
+#define MMA8452_FF_MT_CFG  0x15
+#define  MMA8452_FF_MT_CFG_OAE BIT(6)
+#define  MMA8452_FF_MT_CFG_ELE BIT(7)
+#define MMA8452_FF_MT_SRC  0x16
+#define  MMA8452_FF_MT_SRC_XHE BIT(1)
+#define  MMA8452_FF_MT_SRC_YHE BIT(3)
+#define  MMA8452_FF_MT_SRC_ZHE BIT(5)
+#define MMA8452_FF_MT_THS  0x17
+#define  MMA8452_FF_MT_THS_MASK0x7f
+#define MMA8452_FF_MT_COUNT0x18
 #define MMA8452_TRANSIENT_CFG  0x1d
 #define  MMA8452_TRANSIENT_CFG_HPF_BYP BIT(0)
 #define  MMA8452_TRANSIENT_CFG_CHAN(chan)  BIT(chan + 1)
@@ -69,6 +79,7 @@
 #define MMA8452_MAX_REG0x31
 
 #define  MMA8452_INT_DRDY  BIT(0)
+#define  MMA8452_INT_FF_MT BIT(2)
 #define  MMA8452_INT_TRANS BIT(5)
 
 #define  MMA8452_DEVICE_ID 0x2a
@@ -613,7 +624,8 @@ static int mma8452_write_event_config(struct iio_dev 
*indio_dev,
else
val &= ~BIT(chan->scan_index + chip->ev_cfg_chan_shift);
 
-   val |= MMA8452_TRANSIENT_CFG_ELE;
+   val |= chip->ev_cfg_ele;
+   val |= MMA8452_FF_MT_CFG_OAE;
 
return mma8452_change_config(data, chip->ev_cfg, val);
 }
@@ -654,6 +666,7 @@ static irqreturn_t mma8452_interrupt(int irq, void *p)
 {
struct iio_dev *indio_dev = p;
struct mma8452_data *data = iio_priv(indio_dev);
+   const struct mma_chip_info *chip = data->chip_info;
int ret = IRQ_NONE;
int src;
 
@@ -666,7 +679,10 @@ static irqreturn_t mma8452_interrupt(int irq, void *p)
ret = IRQ_HANDLED;
}
 
-   if (src & MMA8452_INT_TRANS) {
+   if ((src & MMA8452_INT_TRANS &&
+chip->ev_src == MMA8452_TRANSIENT_SRC) ||
+   (src & MMA8452_INT_FF_MT &&
+chip->ev_src == MMA8452_FF_MT_SRC)) {
mma8452_transient_interrupt(indio_dev);
ret = IRQ_HANDLED;
}
@@ -728,6 +744,16 @@ static const struct iio_event_spec 
mma8452_transient_event[] = {
},
 };
 
+static const struct iio_event_spec mma8452_motion_event[] = {
+   {
+   .type = IIO_EV_TYPE_MAG,
+   .dir = IIO_EV_DIR_RISING,
+   .mask_separate = BIT(IIO_EV_INFO_ENABLE),
+   .mask_shared_by_type = BIT(IIO_EV_INFO_VALUE) |
+   BIT(IIO_EV_INFO_PERIOD)
+   },
+};
+
 /*
  * Threshold is configured in fixed 8G/127 steps regardless of
  * currently selected scale for measurement.
@@ -1013,13 +1039,15 @@ static int mma8452_probe(struct i2c_client *client,
 
if (client->irq) {
/*
-* Although we enable the transient interrupt source once and
-* for all here the transient event detection itself is not
-* enabled until userspace asks for it by
-* mma8452_write_event_config()
+* Although we enable the interrupt sources once and for
+* all here the event detection itself is not enabled until
+* userspace asks for it by mma8452_write_event_config()
 */
-   int supported_interrupts = MMA8452_INT_DRDY | MMA8452_INT_TRANS;
-   int enabled_interrupts = MMA8452_INT_TRANS;
+   int supported_interrupts = MMA8452_INT_DRDY |
+  MMA8452_INT_TRANS |
+  MMA8452_INT_FF_MT;
+   int enabled_interrupts = MMA8452_INT_TRANS |
+MMA8452_INT_FF_MT;
 
/* Assume wired to INT1 pin */
ret = i2c_smbus_write_byte_data(client,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] iio: mma8452: support either of the available interrupt pins

2015-10-13 Thread Martin Kepplinger
This change is important in order for everyone to be easily able to use the
driver for one of the supported accelerometer chips!

Until now, the driver blindly assumed that the INT1 interrupt line is wired
on a user's board. But these devices have 2 interrupt lines and can route
their different interrupt sources to one of them. Since only their motion
detection interrupt source is implemented as IIO events, users just use
either one of the pins.

client->irq is not changed because only one interrupt line is supported.
The user is warned if she describes both interrupt pins in the dts.

If possibly in the future more interrupt sources might be available,
additional DT properties will be added.

Of course, this also falls back to assuming INT1, so for existing users
nothing will break. The new functionality is described in the bindings doc.

Signed-off-by: Martin Kepplinger 
---
this applies to the current -next. thanks in advance for your review!


 .../devicetree/bindings/iio/accel/mma8452.txt  |  6 +
 drivers/iio/accel/mma8452.c| 26 +-
 2 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index e3c3746..6e42c23 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -7,13 +7,18 @@ Required properties:
 * "fsl,mma8453"
 * "fsl,mma8652"
 * "fsl,mma8653"
+
   - reg: the I2C address of the chip
 
 Optional properties:
 
   - interrupt-parent: should be the phandle for the interrupt controller
+
   - interrupts: interrupt mapping for GPIO IRQ
 
+  - interrupt-names: should contain "INT1" or "INT2", the accelerometer's
+interrupt line in use.
+
 Example:
 
mma8453fc@1d {
@@ -21,4 +26,5 @@ Example:
reg = <0x1d>;
interrupt-parent = <&gpio1>;
interrupts = <5 0>;
+   interrupt-names = "INT2";
};
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 1eccc2d..dbfd0b4 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MMA8452_STATUS 0x00
 #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) | BIT(0))
@@ -1130,13 +1131,26 @@ static int mma8452_probe(struct i2c_client *client,
   MMA8452_INT_FF_MT;
int enabled_interrupts = MMA8452_INT_TRANS |
 MMA8452_INT_FF_MT;
+   int irq1, irq2;
 
-   /* Assume wired to INT1 pin */
-   ret = i2c_smbus_write_byte_data(client,
-   MMA8452_CTRL_REG5,
-   supported_interrupts);
-   if (ret < 0)
-   return ret;
+   irq1 = of_irq_get_byname(client->dev.of_node, "INT1");
+   irq2 = of_irq_get_byname(client->dev.of_node, "INT2");
+
+   if (irq1 > 0 && irq2 > 0)
+   dev_warn(&client->dev,
+"only one interrupt line supported\n");
+
+   /* if INT2 is found, use it. Otherwise INT1 */
+   if (!(irq2 > 0 && irq1 < 0)) {
+   ret = i2c_smbus_write_byte_data(client,
+   MMA8452_CTRL_REG5,
+   supported_interrupts);
+   if (ret < 0)
+   return ret;
+   dev_info(&client->dev, "using interrupt line INT1\n");
+   } else {
+   dev_info(&client->dev, "using interrupt line INT2\n");
+   }
 
ret = i2c_smbus_write_byte_data(client,
MMA8452_CTRL_REG4,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2] iio: mma8452: support either of the available interrupt pins

2015-10-14 Thread Martin Kepplinger
This change is important in order for everyone to be easily able to use the
driver for one of the supported accelerometer chips!

Until now, the driver blindly assumed that the INT1 interrupt line is wired
on a user's board. But these devices have 2 interrupt lines and can route
their different interrupt sources to one of them. Since only their motion
detection interrupt source is implemented as IIO events, users just use
either one of the pins.

Of course, this also falls back to assuming INT1, so for existing users
nothing will break. The new functionality is described in the bindings doc.

Signed-off-by: Martin Kepplinger 
---
changelog:
v2: don't warn but normally handle if both pins are described in dts
thanks Mark Rutland
v1: initial post


 .../devicetree/bindings/iio/accel/mma8452.txt  |  7 +++
 drivers/iio/accel/mma8452.c| 22 --
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index e3c3746..f06ed87 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -7,13 +7,19 @@ Required properties:
 * "fsl,mma8453"
 * "fsl,mma8652"
 * "fsl,mma8653"
+
   - reg: the I2C address of the chip
 
 Optional properties:
 
   - interrupt-parent: should be the phandle for the interrupt controller
+
   - interrupts: interrupt mapping for GPIO IRQ
 
+  - interrupt-names: should contain "INT1" and/or "INT2", the accelerometer's
+interrupt line in use. If only "INT2" is present, INT2 is
+used; otherwise INT1.
+
 Example:
 
mma8453fc@1d {
@@ -21,4 +27,5 @@ Example:
reg = <0x1d>;
interrupt-parent = <&gpio1>;
interrupts = <5 0>;
+   interrupt-names = "INT2";
};
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 1eccc2d..4d69c3d 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MMA8452_STATUS 0x00
 #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) | BIT(0))
@@ -1130,13 +1131,22 @@ static int mma8452_probe(struct i2c_client *client,
   MMA8452_INT_FF_MT;
int enabled_interrupts = MMA8452_INT_TRANS |
 MMA8452_INT_FF_MT;
+   int irq1, irq2;
 
-   /* Assume wired to INT1 pin */
-   ret = i2c_smbus_write_byte_data(client,
-   MMA8452_CTRL_REG5,
-   supported_interrupts);
-   if (ret < 0)
-   return ret;
+   irq1 = of_irq_get_byname(client->dev.of_node, "INT1");
+   irq2 = of_irq_get_byname(client->dev.of_node, "INT2");
+
+   /* if INT2 is found, use it. Otherwise INT1 */
+   if (!(irq2 > 0 && irq1 < 0)) {
+   ret = i2c_smbus_write_byte_data(client,
+   MMA8452_CTRL_REG5,
+   supported_interrupts);
+   if (ret < 0)
+   return ret;
+   dev_info(&client->dev, "using interrupt line INT1\n");
+   } else {
+   dev_info(&client->dev, "using interrupt line INT2\n");
+   }
 
ret = i2c_smbus_write_byte_data(client,
MMA8452_CTRL_REG4,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3] iio: mma8452: support either of the available interrupt pins

2015-10-14 Thread Martin Kepplinger
This change is important in order for everyone to be easily able to use the
driver for one of the supported accelerometer chips!

Until now, the driver blindly assumed that the INT1 interrupt line is wired
on a user's board. But these devices have 2 interrupt lines and can route
their different interrupt sources to one of them. Since only their motion
detection interrupt source is implemented as IIO events, users just use
either one of the pins.

Of course, this also falls back to assuming INT1, so for existing users
nothing will break. The new functionality is described in the bindings doc.

Signed-off-by: Martin Kepplinger 
---
changelog:
v3: correctly assign irq if both pins are described in DT. thanks again
v2: don't warn but normally handle if both pins are described in dts
thanks Mark Rutland
v1: initial post

 .../devicetree/bindings/iio/accel/mma8452.txt  |  6 +
 drivers/iio/accel/mma8452.c| 26 +-
 2 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index e3c3746..3c10e85 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -7,13 +7,18 @@ Required properties:
 * "fsl,mma8453"
 * "fsl,mma8652"
 * "fsl,mma8653"
+
   - reg: the I2C address of the chip
 
 Optional properties:
 
   - interrupt-parent: should be the phandle for the interrupt controller
+
   - interrupts: interrupt mapping for GPIO IRQ
 
+  - interrupt-names: should contain "INT1" and/or "INT2", the accelerometer's
+interrupt line in use.
+
 Example:
 
mma8453fc@1d {
@@ -21,4 +26,5 @@ Example:
reg = <0x1d>;
interrupt-parent = <&gpio1>;
interrupts = <5 0>;
+   interrupt-names = "INT2";
};
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 1eccc2d..6b9b360 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MMA8452_STATUS 0x00
 #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) | BIT(0))
@@ -1130,13 +1131,26 @@ static int mma8452_probe(struct i2c_client *client,
   MMA8452_INT_FF_MT;
int enabled_interrupts = MMA8452_INT_TRANS |
 MMA8452_INT_FF_MT;
+   int irq1, irq2;
 
-   /* Assume wired to INT1 pin */
-   ret = i2c_smbus_write_byte_data(client,
-   MMA8452_CTRL_REG5,
-   supported_interrupts);
-   if (ret < 0)
-   return ret;
+   irq1 = of_irq_get_byname(client->dev.of_node, "INT1");
+   irq2 = of_irq_get_byname(client->dev.of_node, "INT2");
+
+   /* if INT2 is found, use it. Otherwise INT1 */
+   if (!(irq2 > 0 && irq1 < 0)) {
+   ret = i2c_smbus_write_byte_data(client,
+   MMA8452_CTRL_REG5,
+   supported_interrupts);
+   if (ret < 0)
+   return ret;
+
+   if (irq1 > 0)
+   client->irq = irq1;
+   dev_info(&client->dev, "using interrupt line INT1\n");
+   } else {
+   client->irq = irq2;
+   dev_info(&client->dev, "using interrupt line INT2\n");
+   }
 
ret = i2c_smbus_write_byte_data(client,
MMA8452_CTRL_REG4,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3] iio: mma8452: support either of the available interrupt pins

2015-10-15 Thread Martin Kepplinger
Am 2015-10-14 um 17:12 schrieb Lars-Peter Clausen:
> On 10/14/2015 03:15 PM, Martin Kepplinger wrote:
> [...]
>> +if (irq1 > 0)
>> +client->irq = irq1;
> 
> You must not overwrite client->irq, that field is manged by the I2C core and
> is supposed to be read only for device drivers.
>

I thought about it again and before I implement it, let me show you:

since interrupt-names would be "invented" anyways ("INT1", "INT2"),
here's an idea for the bindings doc that would be a more long-term
solution to implement:

  - interrupts: interrupt mapping for GPIO IRQ

These devices have two interrupt pins called INT1 and INT2 they
can route their different interrupt sources to:

IRQ NameInterrupt SourceWired Pin
-
DATA_READY_1data ready  INT1
DATA_READY_2INT2
MOTION_1motion events   INT1
MOTION_2INT2
INT1all INT1
INT2INT2

  - interrupt-names: should contain IRQ Names in the order in which they
 were supplied in the interrupts property.

 Depending on how your chip is wired and what
 interrupt sources should be handled by the driver,
 choose one IRQ Name per Interrupt source, or
 INT1/INT2 for all sources to one pin here.

Example 1:

mma8453fc@1d {
compatible = "fsl,mma8453";
reg = <0x1d>;
interrupt-parent = <&gpio1>;
interrupts = <5 0>;
interrupt-names = "INT2"; // interrupt pin wired to INT2
};

Example 2:

mma8453fc@1d {
compatible = "fsl,mma8453";
reg = <0x1d>;
interrupt-parent = <&gpio1>;
interrupts = <4 0>, <5 0>;
/* data ready comes from INT2, motion events from INT1 */
interrupt-names = "DATA_READY_2", "MOTION_1";
};

What do you think?

thanks
   martin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v4] iio: mma8452: support either of the available interrupt pins

2015-10-15 Thread Martin Kepplinger
This change is important in order for everyone to be easily able to use the
driver for one of the supported accelerometer chips!

Until now, the driver blindly assumed that the INT1 interrupt line is wired
on a user's board. But these devices have 2 interrupt lines and can route
their interrupt sources to one of them. Now, if "INT2" is found and matches
i2c_client->irq, INT2 will be used.

The chip's default actually is INT2, which is why probably many boards will
have it wired and can make use of this.

Of course, this also falls back to assuming INT1, so for existing users
nothing will break. The new functionality is described in the bindings doc.

Signed-off-by: Martin Kepplinger 
---
changelog:
v4: use irq that matches client->irq, backwards compatible
v3: correctly assign irq if both pins are described in DT
v2: don't warn but normally handle if both pins are described in dts
thanks Mark Rutland
v1: initial post

 .../devicetree/bindings/iio/accel/mma8452.txt   |  6 ++
 drivers/iio/accel/mma8452.c | 21 +++--
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index e3c3746..3c10e85 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -7,13 +7,18 @@ Required properties:
 * "fsl,mma8453"
 * "fsl,mma8652"
 * "fsl,mma8653"
+
   - reg: the I2C address of the chip
 
 Optional properties:
 
   - interrupt-parent: should be the phandle for the interrupt controller
+
   - interrupts: interrupt mapping for GPIO IRQ
 
+  - interrupt-names: should contain "INT1" and/or "INT2", the accelerometer's
+interrupt line in use.
+
 Example:
 
mma8453fc@1d {
@@ -21,4 +26,5 @@ Example:
reg = <0x1d>;
interrupt-parent = <&gpio1>;
interrupts = <5 0>;
+   interrupt-names = "INT2";
};
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 1eccc2d..116a6e4 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MMA8452_STATUS 0x00
 #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) | BIT(0))
@@ -1130,13 +1131,21 @@ static int mma8452_probe(struct i2c_client *client,
   MMA8452_INT_FF_MT;
int enabled_interrupts = MMA8452_INT_TRANS |
 MMA8452_INT_FF_MT;
+   int irq2;
 
-   /* Assume wired to INT1 pin */
-   ret = i2c_smbus_write_byte_data(client,
-   MMA8452_CTRL_REG5,
-   supported_interrupts);
-   if (ret < 0)
-   return ret;
+   irq2 = of_irq_get_byname(client->dev.of_node, "INT2");
+
+   if (irq2 == client->irq) {
+   dev_dbg(&client->dev, "using interrupt line INT2\n");
+   } else {
+   ret = i2c_smbus_write_byte_data(client,
+   MMA8452_CTRL_REG5,
+   supported_interrupts);
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(&client->dev, "using interrupt line INT1\n");
+   }
 
ret = i2c_smbus_write_byte_data(client,
MMA8452_CTRL_REG4,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 1/2] bitops.h: Improve sign_extend32()'s documentation

2015-10-15 Thread Martin Kepplinger
It is often overlooked that sign_extend32(), despite it's name, is safe
to use for 16 and 8 bit types aswell. This should help that sign extension
isn't done manually some other way.

Signed-off-by: Martin Kepplinger 
---
 include/linux/bitops.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index e635533..2177c01 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -164,6 +164,8 @@ static inline __u8 ror8(__u8 word, unsigned int shift)
  * sign_extend32 - sign extend a 32-bit value using specified bit as sign-bit
  * @value: value to sign extend
  * @index: 0 based bit index (0<=index<32) to sign bit
+ *
+ * This is safe to use for 16- and 8-bit types aswell.
  */
 static inline __s32 sign_extend32(__u32 value, int index)
 {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2/2] bitops.h: add sign_extend64()

2015-10-15 Thread Martin Kepplinger
Months back, this was discussed, see https://lkml.org/lkml/2015/1/18/289
The result was the 64-bit version being "likely fine", "valuable" and
"correct". The discussion only fell asleep but since there are possible
users, let's add it.

Signed-off-by: Martin Kepplinger 
---
 include/linux/bitops.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 2177c01..1672b74 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -173,6 +173,17 @@ static inline __s32 sign_extend32(__u32 value, int index)
return (__s32)(value << shift) >> shift;
 }
 
+/**
+ * sign_extend64 - sign extend a 64-bit value using specified bit as sign-bit
+ * @value: value to sign extend
+ * @index: 0 based bit index (0<=index<64) to sign bit
+ */
+static inline __s64 sign_extend64(__u64 value, int index)
+{
+   __u8 shift = 63 - index;
+   return (__s64)(value << shift) >> shift;
+}
+
 static inline unsigned fls_long(unsigned long l)
 {
if (sizeof(l) == 4)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


bitops.h: improve sign extending API

2015-10-15 Thread Martin Kepplinger
PATCH 1/2 improves the doc of sign_extend32()

This should help to avoid different manual approaches to sign extension


PATCH 2/2 adds sign_extend64()

An informal example of what could follow in
arch/sh/kernel/traps_64.c after PATCH 2/2:

@@ -101,7 +102,7 @@ static int generate_and_check_address(struct pt_regs *regs,
__s64 displacement;
displacement = (opcode >> 10) & 0x3ff;
-   displacement = ((displacement << 54) >> 54); /* sign extend */
+   displacement = sign_extend64(displacement, 9);
addr = (__u64)((__s64)base_address + (displacement << 
width_shift));
} else {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 0/5] improve sign extension API

2015-10-16 Thread Martin Kepplinger
PATCH 1 improves the doc of sign_extend32()
It should help to avoid different manual approaches to sign extension

PATCH 2 adds sign_extend64()

PTACH 3-5 are (untested) example users of sign_extend64()

changelog
-
v2: fix a typo and add examples for sign_extend64()

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 5/5] arch: x86: use sign_extend64() for sign extension

2015-10-16 Thread Martin Kepplinger
Signed-off-by: Martin Kepplinger 
---
 arch/x86/kernel/cpu/perf_event_msr.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_msr.c 
b/arch/x86/kernel/cpu/perf_event_msr.c
index f32ac13..ec863b9 100644
--- a/arch/x86/kernel/cpu/perf_event_msr.c
+++ b/arch/x86/kernel/cpu/perf_event_msr.c
@@ -163,10 +163,9 @@ again:
goto again;
 
delta = now - prev;
-   if (unlikely(event->hw.event_base == MSR_SMI_COUNT)) {
-   delta <<= 32;
-   delta >>= 32; /* sign extend */
-   }
+   if (unlikely(event->hw.event_base == MSR_SMI_COUNT))
+   delta = sign_extend64(delta, 31);
+
local64_add(now - prev, &event->count);
 }
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 1/5] bitops.h: Improve sign_extend32()'s documentation

2015-10-16 Thread Martin Kepplinger
It is often overlooked that sign_extend32(), despite it's name, is safe
to use for 16 and 8 bit types aswell. This should help that sign extension
isn't done manually some other way.

Signed-off-by: Martin Kepplinger 
---
 include/linux/bitops.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index e635533..5629923 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -164,6 +164,8 @@ static inline __u8 ror8(__u8 word, unsigned int shift)
  * sign_extend32 - sign extend a 32-bit value using specified bit as sign-bit
  * @value: value to sign extend
  * @index: 0 based bit index (0<=index<32) to sign bit
+ *
+ * This is safe to use for 16- and 8-bit types as well.
  */
 static inline __s32 sign_extend32(__u32 value, int index)
 {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 4/5] arch: sh: use sign_extend64() for sign extension

2015-10-16 Thread Martin Kepplinger
Signed-off-by: Martin Kepplinger 
---
 arch/sh/kernel/cpu/sh5/unwind.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/kernel/cpu/sh5/unwind.c b/arch/sh/kernel/cpu/sh5/unwind.c
index 10aed41..3a4fed4 100644
--- a/arch/sh/kernel/cpu/sh5/unwind.c
+++ b/arch/sh/kernel/cpu/sh5/unwind.c
@@ -159,7 +159,7 @@ static int lookup_prev_stack_frame(unsigned long fp, 
unsigned long pc,
 
/* Sign extend */
regcache[dest] =
-   s64)(u64)op >> 10) & 0x) << 54) >> 54;
+   sign_extend64u64)op >> 10) & 0x), 9);
break;
case (0xd0 >> 2): /* addi */
case (0xd4 >> 2): /* addi.l */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3/5] arch: sh: use sign_extend64() for sign extension

2015-10-16 Thread Martin Kepplinger
Signed-off-by: Martin Kepplinger 
---
 arch/sh/kernel/traps_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/kernel/traps_64.c b/arch/sh/kernel/traps_64.c
index 112ea11..d208c27 100644
--- a/arch/sh/kernel/traps_64.c
+++ b/arch/sh/kernel/traps_64.c
@@ -101,7 +101,7 @@ static int generate_and_check_address(struct pt_regs *regs,
if (displacement_not_indexed) {
__s64 displacement;
displacement = (opcode >> 10) & 0x3ff;
-   displacement = ((displacement << 54) >> 54); /* sign extend */
+   displacement = sign_extend64(displacement, 9);
addr = (__u64)((__s64)base_address + (displacement << 
width_shift));
} else {
__u64 offset;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2/5] bitops.h: add sign_extend64()

2015-10-16 Thread Martin Kepplinger
Months back, this was discussed, see https://lkml.org/lkml/2015/1/18/289
The result was the 64-bit version being "likely fine", "valuable" and
"correct". The discussion only fell asleep but since there are possible
users, let's add it.

Signed-off-by: Martin Kepplinger 
---
 include/linux/bitops.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 5629923..2b8ed12 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -173,6 +173,17 @@ static inline __s32 sign_extend32(__u32 value, int index)
return (__s32)(value << shift) >> shift;
 }
 
+/**
+ * sign_extend64 - sign extend a 64-bit value using specified bit as sign-bit
+ * @value: value to sign extend
+ * @index: 0 based bit index (0<=index<64) to sign bit
+ */
+static inline __s64 sign_extend64(__u64 value, int index)
+{
+   __u8 shift = 63 - index;
+   return (__s64)(value << shift) >> shift;
+}
+
 static inline unsigned fls_long(unsigned long l)
 {
if (sizeof(l) == 4)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v4] iio: mma8452: support either of the available interrupt pins

2015-10-22 Thread Martin Kepplinger
Am 2015-10-20 um 13:03 schrieb Martin Kepplinger:
> Am 2015-10-15 um 15:10 schrieb Martin Kepplinger:
>> This change is important in order for everyone to be easily able to use the
>> driver for one of the supported accelerometer chips!
>>
>> Until now, the driver blindly assumed that the INT1 interrupt line is wired
>> on a user's board. But these devices have 2 interrupt lines and can route
>> their interrupt sources to one of them. Now, if "INT2" is found and matches
>> i2c_client->irq, INT2 will be used.
>>
>> The chip's default actually is INT2, which is why probably many boards will
>> have it wired and can make use of this.
>>
>> Of course, this also falls back to assuming INT1, so for existing users
>> nothing will break. The new functionality is described in the bindings doc.
>>
>> Signed-off-by: Martin Kepplinger 
>> ---
>> changelog:
>> v4: use irq that matches client->irq, backwards compatible
>> v3: correctly assign irq if both pins are described in DT
>> v2: don't warn but normally handle if both pins are described in dts
>> thanks Mark Rutland
>> v1: initial post
>>
>>  .../devicetree/bindings/iio/accel/mma8452.txt   |  6 ++
>>  drivers/iio/accel/mma8452.c | 21 
>> +++--
>>  2 files changed, 21 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
>> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>> index e3c3746..3c10e85 100644
>> --- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>> @@ -7,13 +7,18 @@ Required properties:
>>  * "fsl,mma8453"
>>  * "fsl,mma8652"
>>  * "fsl,mma8653"
>> +
>>- reg: the I2C address of the chip
>>  
>>  Optional properties:
>>  
>>- interrupt-parent: should be the phandle for the interrupt controller
>> +
>>- interrupts: interrupt mapping for GPIO IRQ
>>  
>> +  - interrupt-names: should contain "INT1" and/or "INT2", the 
>> accelerometer's
>> + interrupt line in use.
>> +
>>  Example:
>>  
>>  mma8453fc@1d {
>> @@ -21,4 +26,5 @@ Example:
>>  reg = <0x1d>;
>>  interrupt-parent = <&gpio1>;
>>  interrupts = <5 0>;
>> +interrupt-names = "INT2";
>>  };
>> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
>> index 1eccc2d..116a6e4 100644
>> --- a/drivers/iio/accel/mma8452.c
>> +++ b/drivers/iio/accel/mma8452.c
>> @@ -29,6 +29,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #define MMA8452_STATUS  0x00
>>  #define  MMA8452_STATUS_DRDY(BIT(2) | BIT(1) | 
>> BIT(0))
>> @@ -1130,13 +1131,21 @@ static int mma8452_probe(struct i2c_client *client,
>> MMA8452_INT_FF_MT;
>>  int enabled_interrupts = MMA8452_INT_TRANS |
>>   MMA8452_INT_FF_MT;
>> +int irq2;
>>  
>> -/* Assume wired to INT1 pin */
>> -ret = i2c_smbus_write_byte_data(client,
>> -MMA8452_CTRL_REG5,
>> -supported_interrupts);
>> -if (ret < 0)
>> -return ret;
>> +irq2 = of_irq_get_byname(client->dev.of_node, "INT2");
>> +
>> +if (irq2 == client->irq) {
>> +dev_dbg(&client->dev, "using interrupt line INT2\n");
>> +} else {
>> +ret = i2c_smbus_write_byte_data(client,
>> +MMA8452_CTRL_REG5,
>> +supported_interrupts);
>> +if (ret < 0)
>> +return ret;
>> +
>> +dev_dbg(&client->dev, "using interrupt line INT1\n");
>> +}
>>  
>>  ret = i2c_smbus_write_byte_data(client,
>>  MMA8452_CTRL_REG4,
>>
> 
> This works fine and would be convenient to have. Any objections?
> 
> thanks
>  martin

yes, no, maybe?

thanks
   martin


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v4] iio: mma8452: support either of the available interrupt pins

2015-10-20 Thread Martin Kepplinger
Am 2015-10-15 um 15:10 schrieb Martin Kepplinger:
> This change is important in order for everyone to be easily able to use the
> driver for one of the supported accelerometer chips!
> 
> Until now, the driver blindly assumed that the INT1 interrupt line is wired
> on a user's board. But these devices have 2 interrupt lines and can route
> their interrupt sources to one of them. Now, if "INT2" is found and matches
> i2c_client->irq, INT2 will be used.
> 
> The chip's default actually is INT2, which is why probably many boards will
> have it wired and can make use of this.
> 
> Of course, this also falls back to assuming INT1, so for existing users
> nothing will break. The new functionality is described in the bindings doc.
> 
> Signed-off-by: Martin Kepplinger 
> ---
> changelog:
> v4: use irq that matches client->irq, backwards compatible
> v3: correctly assign irq if both pins are described in DT
> v2: don't warn but normally handle if both pins are described in dts
> thanks Mark Rutland
> v1: initial post
> 
>  .../devicetree/bindings/iio/accel/mma8452.txt   |  6 ++
>  drivers/iio/accel/mma8452.c | 21 
> +++--
>  2 files changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> index e3c3746..3c10e85 100644
> --- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> @@ -7,13 +7,18 @@ Required properties:
>  * "fsl,mma8453"
>  * "fsl,mma8652"
>  * "fsl,mma8653"
> +
>- reg: the I2C address of the chip
>  
>  Optional properties:
>  
>- interrupt-parent: should be the phandle for the interrupt controller
> +
>- interrupts: interrupt mapping for GPIO IRQ
>  
> +  - interrupt-names: should contain "INT1" and/or "INT2", the accelerometer's
> +  interrupt line in use.
> +
>  Example:
>  
>   mma8453fc@1d {
> @@ -21,4 +26,5 @@ Example:
>   reg = <0x1d>;
>   interrupt-parent = <&gpio1>;
>   interrupts = <5 0>;
> + interrupt-names = "INT2";
>   };
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 1eccc2d..116a6e4 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define MMA8452_STATUS   0x00
>  #define  MMA8452_STATUS_DRDY (BIT(2) | BIT(1) | BIT(0))
> @@ -1130,13 +1131,21 @@ static int mma8452_probe(struct i2c_client *client,
>  MMA8452_INT_FF_MT;
>   int enabled_interrupts = MMA8452_INT_TRANS |
>MMA8452_INT_FF_MT;
> + int irq2;
>  
> - /* Assume wired to INT1 pin */
> - ret = i2c_smbus_write_byte_data(client,
> - MMA8452_CTRL_REG5,
> - supported_interrupts);
> - if (ret < 0)
> - return ret;
> + irq2 = of_irq_get_byname(client->dev.of_node, "INT2");
> +
> + if (irq2 == client->irq) {
> + dev_dbg(&client->dev, "using interrupt line INT2\n");
> + } else {
> + ret = i2c_smbus_write_byte_data(client,
> + MMA8452_CTRL_REG5,
> + supported_interrupts);
> + if (ret < 0)
> + return ret;
> +
> + dev_dbg(&client->dev, "using interrupt line INT1\n");
> + }
>  
>   ret = i2c_smbus_write_byte_data(client,
>   MMA8452_CTRL_REG4,
> 

This works fine and would be convenient to have. Any objections?

thanks
 martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v4] iio: mma8452: support either of the available interrupt pins

2015-10-25 Thread Martin Kepplinger


Am 25. Oktober 2015 12:05:05 MEZ, schrieb Jonathan Cameron :
>On 22/10/15 19:22, Rob Herring wrote:
>> On Thu, Oct 15, 2015 at 8:10 AM, Martin Kepplinger
> wrote:
>>> This change is important in order for everyone to be easily able to
>use the
>>> driver for one of the supported accelerometer chips!
>>>
>>> Until now, the driver blindly assumed that the INT1 interrupt line
>is wired
>>> on a user's board. But these devices have 2 interrupt lines and can
>route
>>> their interrupt sources to one of them. Now, if "INT2" is found and
>matches
>>> i2c_client->irq, INT2 will be used.
>>>
>>> The chip's default actually is INT2, which is why probably many
>boards will
>>> have it wired and can make use of this.
>>>
>>> Of course, this also falls back to assuming INT1, so for existing
>users
>>> nothing will break. The new functionality is described in the
>bindings doc.
>>>
>>> Signed-off-by: Martin Kepplinger
>
>>> ---
>>> changelog:
>>> v4: use irq that matches client->irq, backwards compatible
>>> v3: correctly assign irq if both pins are described in DT
>>> v2: don't warn but normally handle if both pins are described in dts
>>> thanks Mark Rutland
>>> v1: initial post
>>>
>>>  .../devicetree/bindings/iio/accel/mma8452.txt   |  6 ++
>> 
>> For the binding:
>> 
>> Rob Herring 
>I've guessed that was an Acked-by :)
>
>Anyhow, applied to the togreg branch of iio.git.
>
>I'm afraid after my hiatus for a couple of weeks (day job work crisis
>now
>over) this has missed going in for the current cycle.
>
>IIO merge closes more than a week before the merge window opens and
>Linus
>just announced probably release a week today.
>
>Sorry about that, will be queued up for an early entry into linux next
>after the merge window closes.
>
>Jonathan

That's fine. Thanks

>> 
>>>  drivers/iio/accel/mma8452.c | 21
>+++--
>>>  2 files changed, 21 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>>> index e3c3746..3c10e85 100644
>>> --- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>>> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>>> @@ -7,13 +7,18 @@ Required properties:
>>>  * "fsl,mma8453"
>>>  * "fsl,mma8652"
>>>  * "fsl,mma8653"
>>> +
>>>- reg: the I2C address of the chip
>>>
>>>  Optional properties:
>>>
>>>- interrupt-parent: should be the phandle for the interrupt
>controller
>>> +
>>>- interrupts: interrupt mapping for GPIO IRQ
>>>
>>> +  - interrupt-names: should contain "INT1" and/or "INT2", the
>accelerometer's
>>> +interrupt line in use.
>>> +
>>>  Example:
>>>
>>> mma8453fc@1d {
>>> @@ -21,4 +26,5 @@ Example:
>>> reg = <0x1d>;
>>> interrupt-parent = <&gpio1>;
>>> interrupts = <5 0>;
>>> +   interrupt-names = "INT2";
>>> };
>>> diff --git a/drivers/iio/accel/mma8452.c
>b/drivers/iio/accel/mma8452.c
>>> index 1eccc2d..116a6e4 100644
>>> --- a/drivers/iio/accel/mma8452.c
>>> +++ b/drivers/iio/accel/mma8452.c
>>> @@ -29,6 +29,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>>  #define MMA8452_STATUS 0x00
>>>  #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) |
>BIT(0))
>>> @@ -1130,13 +1131,21 @@ static int mma8452_probe(struct i2c_client
>*client,
>>>MMA8452_INT_FF_MT;
>>> int enabled_interrupts = MMA8452_INT_TRANS |
>>>  MMA8452_INT_FF_MT;
>>> +   int irq2;
>>>
>>> -   /* Assume wired to INT1 pin */
>>> -   ret = i2c_smbus_write_byte_data(client,
>>> -   MMA8452_CTRL_REG5,
>>> -  
>supported_interrupts);
>>> -   if (ret < 0)
>>> - 

Re: [PATCH 11/11] touchscreen: tsc200x: Use octal permissions

2018-07-22 Thread Martin Kepplinger
On 2018-07-21 21:09, dev-harsh1998 wrote:
> WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using 
> octal permissions '0444'.
> +static DEVICE_ATTR(selftest, S_IRUGO, tsc200x_selftest_show, NULL);
> 
> Signed-off-by: dev-harsh1998 

Acked-by: Martin Kepplinger 



Re: [PATCH] input: edt-ft5x06: increase allowed data range for threshold parameter

2017-05-11 Thread Martin Kepplinger
On 2017-05-08 18:11, Rob Herring wrote:
> On Tue, May 02, 2017 at 05:00:59PM +0200, Martin Kepplinger wrote:
>> The datasheet and application note does not mention an allowed range for
>> the M09_REGISTER_THRESHOLD parameter. One of our customers needs to set
>> lower values than 20 and they seem to work just fine on EDT EP0xx0M09 with
>> T5x06 touch.
>>
>> So, lacking a known lower limit, we increase the range for thresholds,
>> and set the lower limit to 0. The documentation is updated accordingly.
>>
>> Signed-off-by: Schoefegger Stefan 
>> Signed-off-by: Manfred Schlaegl 
>> Signed-off-by: Martin Kepplinger 
>> ---
>>  Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt | 2 +-
>>  Documentation/input/devices/edt-ft5x06.rst | 2 +-
>>  drivers/input/touchscreen/edt-ft5x06.c | 2 +-
>>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> Acked-by: Rob Herring 
> 

Dmitry, any objections or thoughts?

thanks
   martin


Re: [PATCH 1/2] Input: sur40: Delete an error message for a failed memory allocation in sur40_probe()

2018-01-21 Thread Martin Kepplinger
On 2018-01-20 22:28, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 20 Jan 2018 22:11:24 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Martin Kepplinger 

> ---
>  drivers/input/touchscreen/sur40.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/sur40.c 
> b/drivers/input/touchscreen/sur40.c
> index f16f8358c70a..c7a0a92b2044 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
> @@ -591,7 +591,6 @@ static int sur40_probe(struct usb_interface *interface,
>   sur40->bulk_in_epaddr = endpoint->bEndpointAddress;
>   sur40->bulk_in_buffer = kmalloc(sur40->bulk_in_size, GFP_KERNEL);
>   if (!sur40->bulk_in_buffer) {
> - dev_err(&interface->dev, "Unable to allocate input buffer.");
>   error = -ENOMEM;
>   goto err_free_polldev;
>   }
> 



Re: [PATCH] Input: edt-ft5x06: Delete an error message for a failed memory allocation in edt_ft5x06_ts_probe()

2018-01-21 Thread Martin Kepplinger
On 2018-01-21 20:19, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sun, 21 Jan 2018 20:10:03 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Martin Kepplinger 

> ---
>  drivers/input/touchscreen/edt-ft5x06.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
> b/drivers/input/touchscreen/edt-ft5x06.c
> index c53a3d7239e7..9d2799c90150 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -978,10 +978,8 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
>   dev_dbg(&client->dev, "probing for EDT FT5x06 I2C\n");
>  
>   tsdata = devm_kzalloc(&client->dev, sizeof(*tsdata), GFP_KERNEL);
> - if (!tsdata) {
> - dev_err(&client->dev, "failed to allocate driver data.\n");
> + if (!tsdata)
>   return -ENOMEM;
> - }
>  
>   chip_data = of_device_get_match_data(&client->dev);
>   if (!chip_data)
> 



Re: [PATCH 2/2] Input: sur40: Improve a size determination in sur40_probe()

2018-01-21 Thread Martin Kepplinger
On 2018-01-20 22:30, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 20 Jan 2018 22:16:14 +0100
> 
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Martin Kepplinger 

> ---
>  drivers/input/touchscreen/sur40.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/sur40.c 
> b/drivers/input/touchscreen/sur40.c
> index c7a0a92b2044..946e1a0328b4 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
> @@ -550,7 +550,7 @@ static int sur40_probe(struct usb_interface *interface,
>   return -ENODEV;
>  
>   /* Allocate memory for our device state and initialize it. */
> - sur40 = kzalloc(sizeof(struct sur40_state), GFP_KERNEL);
> + sur40 = kzalloc(sizeof(*sur40), GFP_KERNEL);
>   if (!sur40)
>   return -ENOMEM;
>  
> 



[PATCH] Documentation/process: update FUSE project website

2018-03-27 Thread Martin Kepplinger
According to the old project site, https://sourceforge.net/projects/fuse/
the project has moved to https://github.com/libfuse/ so we update the
link to point to the latest libfuse release.

Signed-off-by: Martin Kepplinger 
---
 Documentation/process/changes.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/process/changes.rst 
b/Documentation/process/changes.rst
index 4f19a9725f76..ddc029734b25 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -430,7 +430,7 @@ udev
 FUSE
 
 
-- <http://sourceforge.net/projects/fuse>
+- <https://github.com/libfuse/libfuse/releases>
 
 mcelog
 --
-- 
2.14.2



[PATCH] Documentation: admin-guide: add kvmconfig, xenconfig and tinyconfig commands

2018-03-22 Thread Martin Kepplinger
Add kvmconfig, xenconfig and tinyconfig to the list of alternative
configuration commands. Descriptions are directly taken from the Makefile.

Signed-off-by: Martin Kepplinger 
---
 Documentation/admin-guide/README.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/admin-guide/README.rst 
b/Documentation/admin-guide/README.rst
index 155372b3b57f..02caa7efd5ef 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -218,6 +218,13 @@ Configuring the kernel
  "make localyesconfig" Similar to localmodconfig, except it will convert
all module options to built in (=y) options.
 
+ "make kvmconfig"   Enable additional options for kvm guest kernel support.
+
+ "make xenconfig"   Enable additional options for xen dom0 guest kernel
+support.
+
+ "make tinyconfig"  Configure the tiniest possible kernel.
+
You can find more information on using the Linux kernel config tools
in Documentation/kbuild/kconfig.txt.
 
-- 
2.14.2



[PATCH] Documentation: magic-numbers: Fix typo

2018-03-23 Thread Martin Kepplinger
This fixes a little then / them confusion.

Signed-off-by: Martin Kepplinger 
---
 Documentation/process/magic-number.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/process/magic-number.rst 
b/Documentation/process/magic-number.rst
index c74199f60c6c..00cecf1fcba9 100644
--- a/Documentation/process/magic-number.rst
+++ b/Documentation/process/magic-number.rst
@@ -14,7 +14,7 @@ passing pointers to structures via a void * pointer.  The tty 
code,
 for example, does this frequently to pass driver-specific and line
 discipline-specific structures back and forth.
 
-The way to use magic numbers is to declare then at the beginning of
+The way to use magic numbers is to declare them at the beginning of
 the structure, like so::
 
struct tty_ldisc {
-- 
2.14.2



[PATCH] ubi: fastmap: Check each mapping only once

2018-11-26 Thread Martin Kepplinger
From: Richard Weinberger 

[ Upstream commit 34653fd8c46e771585fce5975e4243f8fd401914 ]

This commit got merged along with commit 781932375ffc
("ubi: fastmap: Correctly handle interrupted erasures in EBA") upstream but
only the latter has been applied to stable v4.14.54 as commit a23cf10d9abb.
This resulted in a performance regression. Startup on i.MX platforms is
delayed for up to a few seconds depending on the platform.
This fixes ubi fastmap to be of the same performance as it has been before
said fastmap changes.

Fixes: a23cf10d9abb ("ubi: fastmap: Correctly handle interrupted erasures in 
EBA")
Signed-off-by: Richard Weinberger 
Signed-off-by: Martin Kepplinger 
---

Richard, although this fixes a major slowdown regression in -stable, do you
consider this "stable" too?

This applies and is tested only for the 4.14 stable tree. It seems to be
equally relevant for 4.9 and 4.4 though.

thanks
   martin


 drivers/mtd/ubi/build.c   |  1 +
 drivers/mtd/ubi/eba.c |  4 
 drivers/mtd/ubi/fastmap.c | 20 
 drivers/mtd/ubi/ubi.h | 11 +++
 drivers/mtd/ubi/vmt.c |  1 +
 drivers/mtd/ubi/vtbl.c| 16 +++-
 6 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 18a72da759a0..6445c693d935 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -526,6 +526,7 @@ void ubi_free_internal_volumes(struct ubi_device *ubi)
for (i = ubi->vtbl_slots;
 i < ubi->vtbl_slots + UBI_INT_VOL_COUNT; i++) {
ubi_eba_replace_table(ubi->volumes[i], NULL);
+   ubi_fastmap_destroy_checkmap(ubi->volumes[i]);
kfree(ubi->volumes[i]);
}
 }
diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c
index d0884bd9d955..c4d4b8f07630 100644
--- a/drivers/mtd/ubi/eba.c
+++ b/drivers/mtd/ubi/eba.c
@@ -517,6 +517,9 @@ static int check_mapping(struct ubi_device *ubi, struct 
ubi_volume *vol, int lnu
if (!ubi->fast_attach)
return 0;
 
+   if (!vol->checkmap || test_bit(lnum, vol->checkmap))
+   return 0;
+
vidb = ubi_alloc_vid_buf(ubi, GFP_NOFS);
if (!vidb)
return -ENOMEM;
@@ -551,6 +554,7 @@ static int check_mapping(struct ubi_device *ubi, struct 
ubi_volume *vol, int lnu
goto out_free;
}
 
+   set_bit(lnum, vol->checkmap);
err = 0;
 
 out_free:
diff --git a/drivers/mtd/ubi/fastmap.c b/drivers/mtd/ubi/fastmap.c
index 5a832bc79b1b..63e8527f7b65 100644
--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -1101,6 +1101,26 @@ int ubi_scan_fastmap(struct ubi_device *ubi, struct 
ubi_attach_info *ai,
goto out;
 }
 
+int ubi_fastmap_init_checkmap(struct ubi_volume *vol, int leb_count)
+{
+   struct ubi_device *ubi = vol->ubi;
+
+   if (!ubi->fast_attach)
+   return 0;
+
+   vol->checkmap = kcalloc(BITS_TO_LONGS(leb_count), sizeof(unsigned long),
+   GFP_KERNEL);
+   if (!vol->checkmap)
+   return -ENOMEM;
+
+   return 0;
+}
+
+void ubi_fastmap_destroy_checkmap(struct ubi_volume *vol)
+{
+   kfree(vol->checkmap);
+}
+
 /**
  * ubi_write_fastmap - writes a fastmap.
  * @ubi: UBI device object
diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h
index 5fe62653995e..f5ba97c46160 100644
--- a/drivers/mtd/ubi/ubi.h
+++ b/drivers/mtd/ubi/ubi.h
@@ -334,6 +334,9 @@ struct ubi_eba_leb_desc {
  * @changing_leb: %1 if the atomic LEB change ioctl command is in progress
  * @direct_writes: %1 if direct writes are enabled for this volume
  *
+ * @checkmap: bitmap to remember which PEB->LEB mappings got checked,
+ *protected by UBI LEB lock tree.
+ *
  * The @corrupted field indicates that the volume's contents is corrupted.
  * Since UBI protects only static volumes, this field is not relevant to
  * dynamic volumes - it is user's responsibility to assure their data
@@ -377,6 +380,10 @@ struct ubi_volume {
unsigned int updating:1;
unsigned int changing_leb:1;
unsigned int direct_writes:1;
+
+#ifdef CONFIG_MTD_UBI_FASTMAP
+   unsigned long *checkmap;
+#endif
 };
 
 /**
@@ -965,8 +972,12 @@ size_t ubi_calc_fm_size(struct ubi_device *ubi);
 int ubi_update_fastmap(struct ubi_device *ubi);
 int ubi_scan_fastmap(struct ubi_device *ubi, struct ubi_attach_info *ai,
 struct ubi_attach_info *scan_ai);
+int ubi_fastmap_init_checkmap(struct ubi_volume *vol, int leb_count);
+void ubi_fastmap_destroy_checkmap(struct ubi_volume *vol);
 #else
 static inline int ubi_update_fastmap(struct ubi_device *ubi) { return 0; }
+int static inline ubi_fastmap_init_checkmap(struct ubi_volume *vol, int 
leb_count) { return 0; }
+static inline void ubi_fastmap_destroy_checkmap(struct ubi_volume *vol) {}
 #endif
 
 /* 

Re: [PATCH] Input: restore EV_ABS ABS_RESERVED

2018-12-06 Thread Martin Kepplinger

On 06.12.18 00:03, Peter Hutterer wrote:

ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of
ffe0e7cf290f5c9 when the high-resolution scrolling code was removed.

Signed-off-by: Peter Hutterer 


Reviewed-by: Martin Kepplinger 


smime.p7s
Description: S/MIME cryptographic signature


Re: [PATCH] ubi: fastmap: Check each mapping only once

2018-12-03 Thread Martin Kepplinger

On 02.12.18 16:02, Richard Weinberger wrote:

Sasha,

Am Sonntag, 2. Dezember 2018, 15:35:43 CET schrieb Sasha Levin:

On Sun, Dec 02, 2018 at 11:50:33AM +, Sudip Mukherjee wrote:

Now queued up for 4.14.y, thanks.


can you *please* slow a little down?


True. It will really help if you can have some sort of fixed schedule
for stable release, like maybe stablerc is ready on Thursday or Friday
and release the stable on Monday. Having a weekend in stablerc will be
helpful for people like me who only get the time in weekends for
upstream or stable kernel.


Any sort of schedule will never work for everyone (for example, if it's
part of your paid job - you don't necessarily want to review stuff over
the weekend).


a schedule is not needed, but please give maintainers at least a chance
to react on stable inclusion request.
In this case Martin asked for inclusion on Monday and the patch was applied
two days later.


True, especially when the maintainer is asked a question as part of the 
patch.


I've already had the feeling that we'd need the other patch too, but in 
this case at least I should have searched for Fixes tags.


Greg, how about reminding people of Fixes tags in 
Documentation/process/stable-kernel-rules.rst ?


  martin


smime.p7s
Description: S/MIME cryptographic signature


Re: [PATCH] iio: mma8452: Fix ignoring MMA8452_INT_DRDY

2018-06-20 Thread Martin Kepplinger
On 2018-06-07 20:52, Leonard Crestez wrote:
> Interrupts are ignored if no event bit is set in the status status
> register and this breaks the buffer interface. No data is shown when
> running "iio_generic_buffer -n mma8451 -a" and interrupt counts go
> crazy.
> 
> Fix by not returning IRQ_NONE if DRDY is set.
> 
> Fixes: 605f72de137a ("iio: accel: mma8452: improvements to handle
> multiple events")
> 
> Signed-off-by: Leonard Crestez 

At least this does no harm to events. So if this solves your problem:

Acked-by: Martin Kepplinger 

thanks,

martin

> 
> ---
>  drivers/iio/accel/mma8452.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Perhaps this whole early-exit check could be dropped? It is not clear
> how it helps.
> 
> If for some models we want to ignore unsupported events then maybe this
> should be checked for each individual bit. Instead of
> 
> if (src & MMA8452_INT_FF_MT) {
> 
> Check for:
> 
> if ((src & MMA8452_INT_FF_MT) && (data->chip_info->enabled_events & 
> MMA8452_INT_FF_MT))
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 7a2da7f9d4dc..5485b35fe553 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -1032,11 +1032,11 @@ static irqreturn_t mma8452_interrupt(int irq, void *p)
>  
>   src = i2c_smbus_read_byte_data(data->client, MMA8452_INT_SRC);
>   if (src < 0)
>   return IRQ_NONE;
>  
> - if (!(src & data->chip_info->enabled_events))
> + if (!(src & (data->chip_info->enabled_events | MMA8452_INT_DRDY)))
>   return IRQ_NONE;
>  
>   if (src & MMA8452_INT_DRDY) {
>   iio_trigger_poll_chained(indio_dev->trig);
>   ret = IRQ_HANDLED;
> 



pEpkey.asc
Description: application/pgp-keys


[PATCH] iio: accel: mma9551_core: prevent using uninitialized variable

2018-12-10 Thread Martin Kepplinger
mma9551_gpio_config()'s switch statement sets the uninitialized pol_mask
variable but doesn't have default settings. Said function can therefore
be called in a way to use the uninitialized variable (at least in case
enum mma9551_gpio_pin is extended with unhandled values).

While things should be fine now, this initializes pol_mask just to prevent
failure.

Signed-off-by: Martin Kepplinger 
---
 drivers/iio/accel/mma9551_core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/accel/mma9551_core.c b/drivers/iio/accel/mma9551_core.c
index c34c5ce8123b..2fc79b14888b 100644
--- a/drivers/iio/accel/mma9551_core.c
+++ b/drivers/iio/accel/mma9551_core.c
@@ -539,7 +539,8 @@ EXPORT_SYMBOL(mma9551_update_config_bits);
 int mma9551_gpio_config(struct i2c_client *client, enum mma9551_gpio_pin pin,
u8 app_id, u8 bitnum, int polarity)
 {
-   u8 reg, pol_mask, pol_val;
+   u8 reg, pol_val;
+   u8 pol_mask = 0;
int ret;
 
if (pin > mma9551_gpio_max) {
-- 
2.11.0



Re: [PATCH V2 2/2] iio: accell: mma8452: add optional vdd/vddio regulator operation support

2018-12-10 Thread Martin Kepplinger
On 10.12.18 08:25, Anson Huang wrote:
> The accelerometer's power supply could be controlled by regulator
> on some platforms, such as i.MX6Q-SABRESD board, the mma8451's
> power supply is controlled by a GPIO fixed regulator, need to make
> sure the regulator is enabled before any communication with mma8451,
> this patch adds optional vdd/vddio regulator operation support.
> 
> Signed-off-by: Anson Huang 

Acked-by: Martin Kepplinger 



Re: [PATCH V6 2/2] iio: accell: mma8452: add vdd/vddio regulator operation support

2019-01-07 Thread Martin Kepplinger
On 05.01.19 18:29, Jonathan Cameron wrote:
> On Sun, 23 Dec 2018 09:02:32 +
> Anson Huang  wrote:
> 
>> The accelerometer's power supply could be controllable on some
>> platforms, such as i.MX6Q-SABRESD board, the mma8451's power supplies
>> are controlled by a GPIO fixed regulator, need to make sure the
>> regulators are enabled before any communication with mma8451, this
>> patch adds vdd/vddio regulator operation support.
>>
>> Signed-off-by: Anson Huang 
>> Acked-by: Martin Kepplinger 
> 
> I'm fine with the general approach now, though I would like separate
> error handling for the two different regulators.
> 
> Also, this has obviously changed a fair bit since Martin originally gave
> that Ack.  Martin, could you confirm you are still happy with the code?

I'd like to have the change you mention below too. I'll build, review
and confirm after that. thanks!

> 
> Thanks,
> 
> Jonathan
> 
> 
>> ---
>> ChangeLog since V5:
>> - ONLY enable vdd/vddio regulators after both of them are aquired;
>> - Since the suspend/resume operations are same as runtime 
>> suspend/resume, so just use the
>>   pm_runtime_force_suspend/resume for suspend/resuem callback to simply 
>> the code.
>> ---
>>  drivers/iio/accel/mma8452.c | 99 
>> +++--
>>  1 file changed, 77 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
>> index 421a0a8..7519ed5 100644
>> --- a/drivers/iio/accel/mma8452.c
>> +++ b/drivers/iio/accel/mma8452.c
>> @@ -31,6 +31,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #define MMA8452_STATUS  0x00
>>  #define  MMA8452_STATUS_DRDY(BIT(2) | BIT(1) | 
>> BIT(0))
>> @@ -107,6 +108,8 @@ struct mma8452_data {
>>  u8 data_cfg;
>>  const struct mma_chip_info *chip_info;
>>  int sleep_val;
>> +struct regulator *vdd_reg;
>> +struct regulator *vddio_reg;
>>  };
>>  
>>   /**
>> @@ -1534,9 +1537,33 @@ static int mma8452_probe(struct i2c_client *client,
>>  mutex_init(&data->lock);
>>  data->chip_info = match->data;
>>  
>> +data->vdd_reg = devm_regulator_get(&client->dev, "vdd");
>> +data->vddio_reg = devm_regulator_get(&client->dev, "vddio");
>> +if (IS_ERR(data->vdd_reg) || IS_ERR(data->vddio_reg)) {
>> +if (PTR_ERR(data->vdd_reg) == -EPROBE_DEFER ||
>> +PTR_ERR(data->vddio_reg) == -EPROBE_DEFER)
>> +return -EPROBE_DEFER;
>> +
>> +dev_err(&client->dev, "failed to get VDD/VDDIO regulator!\n");
>> +return IS_ERR(data->vdd_reg) ?
>> +   PTR_ERR(data->vdd_reg) : PTR_ERR(data->vddio_reg);
> 
> This is overly complex.  It'll be more lines of code, but I'd prefer
> you handle the two separately as the result will be more readable / less
> fragile.
> 
>> +}
>> +
>> +ret = regulator_enable(data->vdd_reg);
>> +if (ret) {
>> +dev_err(&client->dev, "failed to enable VDD regulator!\n");
>> +return ret;
>> +}
>> +
>> +ret = regulator_enable(data->vddio_reg);
>> +if (ret) {
>> +dev_err(&client->dev, "failed to enable VDDIO regulator!\n");
>> +goto disable_regulator_vdd;
>> +}
>> +
>>  ret = i2c_smbus_read_byte_data(client, MMA8452_WHO_AM_I);
>>  if (ret < 0)
>> -return ret;
>> +goto disable_regulators;
>>  
>>  switch (ret) {
>>  case MMA8451_DEVICE_ID:
>> @@ -1549,7 +1576,8 @@ static int mma8452_probe(struct i2c_client *client,
>>  break;
>>  /* else: fall through */
>>  default:
>> -return -ENODEV;
>> +ret = -ENODEV;
>> +goto disable_regulators;
>>  }
>>  
>>  dev_info(&client->dev, "registering %s accelerometer; ID 0x%x\n",
>> @@ -1566,13 +1594,13 @@ static int mma8452_probe(struct i2c_client *client,
>>  
>>  ret = mma8452_reset(client);
>>  if (ret < 0)
>> -return ret;
>> +goto disable_regulators;
>>  
>>  data->data_cfg = MMA8452_DA

Re: [PATCH V7 2/2] iio: accell: mma8452: add vdd/vddio regulator operation support

2019-01-08 Thread Martin Kepplinger
On 08.01.19 10:14, Anson Huang wrote:
> The accelerometer's power supply could be controllable on some
> platforms, such as i.MX6Q-SABRESD board, the mma8451's power supplies
> are controlled by a GPIO fixed regulator, need to make sure the
> regulators are enabled before any communication with mma8451, this
> patch adds vdd/vddio regulator operation support.
> 
> Signed-off-by: Anson Huang 
> Acked-by: Martin Kepplinger 
> ---
> ChangeLog Since V6:
>   - separate the error handling of regulators get to make code easy to read.
> ---
>  drivers/iio/accel/mma8452.c | 105 
> ++--
>  1 file changed, 83 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 421a0a8..3027811 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define MMA8452_STATUS   0x00
>  #define  MMA8452_STATUS_DRDY (BIT(2) | BIT(1) | BIT(0))
> @@ -107,6 +108,8 @@ struct mma8452_data {
>   u8 data_cfg;
>   const struct mma_chip_info *chip_info;
>   int sleep_val;
> + struct regulator *vdd_reg;
> + struct regulator *vddio_reg;
>  };
>  
>   /**
> @@ -1534,9 +1537,39 @@ static int mma8452_probe(struct i2c_client *client,
>   mutex_init(&data->lock);
>   data->chip_info = match->data;
>  
> + data->vdd_reg = devm_regulator_get(&client->dev, "vdd");
> + if (IS_ERR(data->vdd_reg)) {
> + if (PTR_ERR(data->vdd_reg) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> + dev_err(&client->dev, "failed to get VDD regulator!\n");
> + return PTR_ERR(data->vdd_reg);
> + }
> +
> + data->vddio_reg = devm_regulator_get(&client->dev, "vddio");
> + if (IS_ERR(data->vddio_reg)) {
> + if (PTR_ERR(data->vddio_reg) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> + dev_err(&client->dev, "failed to get VDDIO regulator!\n");
> + return PTR_ERR(data->vddio_reg);
> + }
> +
> + ret = regulator_enable(data->vdd_reg);
> + if (ret) {
> + dev_err(&client->dev, "failed to enable VDD regulator!\n");
> + return ret;
> + }
> +
> + ret = regulator_enable(data->vddio_reg);
> + if (ret) {
> + dev_err(&client->dev, "failed to enable VDDIO regulator!\n");
> + goto disable_regulator_vdd;
> + }
> +
>   ret = i2c_smbus_read_byte_data(client, MMA8452_WHO_AM_I);
>   if (ret < 0)
> - return ret;
> + goto disable_regulators;
>  
>   switch (ret) {
>   case MMA8451_DEVICE_ID:
> @@ -1549,7 +1582,8 @@ static int mma8452_probe(struct i2c_client *client,
>   break;
>   /* else: fall through */
>   default:
> - return -ENODEV;
> + ret = -ENODEV;
> + goto disable_regulators;
>   }
>  
>   dev_info(&client->dev, "registering %s accelerometer; ID 0x%x\n",
> @@ -1566,13 +1600,13 @@ static int mma8452_probe(struct i2c_client *client,
>  
>   ret = mma8452_reset(client);
>   if (ret < 0)
> - return ret;
> + goto disable_regulators;
>  
>   data->data_cfg = MMA8452_DATA_CFG_FS_2G;
>   ret = i2c_smbus_write_byte_data(client, MMA8452_DATA_CFG,
>   data->data_cfg);
>   if (ret < 0)
> - return ret;
> + goto disable_regulators;
>  
>   /*
>* By default set transient threshold to max to avoid events if
> @@ -1581,7 +1615,7 @@ static int mma8452_probe(struct i2c_client *client,
>   ret = i2c_smbus_write_byte_data(client, MMA8452_TRANSIENT_THS,
>   MMA8452_TRANSIENT_THS_MASK);
>   if (ret < 0)
> - return ret;
> + goto disable_regulators;
>  
>   if (client->irq) {
>   int irq2;
> @@ -1595,7 +1629,7 @@ static int mma8452_probe(struct i2c_client *client,
>   MMA8452_CTRL_REG5,
>   data->chip_info->all_events);
>   if (ret < 0)
> - return ret;
> + goto disable_regulators;
>  
>   dev_

[PATCH] can: ucan: fix some typos in comments

2018-10-12 Thread Martin Kepplinger
This fixes some double-word and trivial typos in the ucan driver comments.

Signed-off-by: Martin Kepplinger 
---
hi guys,

The Seal looks very nice. Since I'm doing CAN work right now, I could totally
use one of these instead of old gear from PEAK.

I hope you're doing fine. Best regards,

martin


 drivers/net/can/usb/ucan.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/can/usb/ucan.c b/drivers/net/can/usb/ucan.c
index 0678a38b1af4..8c680fb9fdc8 100644
--- a/drivers/net/can/usb/ucan.c
+++ b/drivers/net/can/usb/ucan.c
@@ -64,7 +64,7 @@
  *the following way:
  *
  * m[n].len <=> the length if message n(including the header in bytes)
- * m[n] is is aligned to a 4 byte boundary, hence
+ * m[n] is aligned to a 4 byte boundary, hence
  *   offset(m[0])   := 0;
  *   offset(m[n+1]) := offset(m[n]) + (m[n].len + 3) & 3
  *
@@ -288,7 +288,7 @@ struct ucan_priv {
 */
spinlock_t echo_skb_lock;
 
-   /* usb device information information */
+   /* usb device information */
u8 intf_index;
u8 in_ep_addr;
u8 out_ep_addr;
@@ -1449,7 +1449,7 @@ static int ucan_probe(struct usb_interface *intf,
 
/* request the device information and store it in ctl_msg_buffer
 *
-* note: ucan_ctrl_command_* wrappers connot be used yet
+* note: ucan_ctrl_command_* wrappers cannot be used yet
 * because `up` is initialised in Stage 3
 */
ret = usb_control_msg(udev,
@@ -1498,7 +1498,7 @@ static int ucan_probe(struct usb_interface *intf,
 
up = netdev_priv(netdev);
 
-   /* initialze data */
+   /* initialize data */
up->udev = udev;
up->intf = intf;
up->netdev = netdev;
-- 
2.19.0



[PATCH] input: st1232: set INPUT_PROP_DIRECT property

2018-10-05 Thread Martin Kepplinger
This is how userspace checks for touchscreen devices most reliably.

Signed-off-by: Martin Kepplinger 
---
 drivers/input/touchscreen/st1232.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/touchscreen/st1232.c 
b/drivers/input/touchscreen/st1232.c
index d5dfa4053bbf..b71673911aac 100644
--- a/drivers/input/touchscreen/st1232.c
+++ b/drivers/input/touchscreen/st1232.c
@@ -195,6 +195,7 @@ static int st1232_ts_probe(struct i2c_client *client,
input_dev->id.bustype = BUS_I2C;
input_dev->dev.parent = &client->dev;
 
+   __set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
__set_bit(EV_SYN, input_dev->evbit);
__set_bit(EV_KEY, input_dev->evbit);
__set_bit(EV_ABS, input_dev->evbit);
-- 
2.19.0



Re: [PATCH] Input: uinput - allow for max == min during input_absinfo validation

2018-09-18 Thread Martin Kepplinger

On 9/18/18 7:22 AM, Peter Hutterer wrote:

These values are inclusive, so a range of 1 requires min == max.

Signed-off-by: Peter Hutterer 


true, nice catch.

Reviewed-by: Martin Kepplinger 


smime.p7s
Description: S/MIME cryptographic signature


Re: [PATCH] dts: imx8mq-librem5: Don't wake up on volume key press

2024-06-10 Thread Martin Kepplinger
Am Montag, dem 20.05.2024 um 12:57 +0200 schrieb Guido Günther:
> The only key that should wake up the phone is power button press.
> This
> prevents accidental wakeup due to e.g. pressing the buttons in the
> pocket or backpack and is in line what userspace uses to unblank the
> device.
> 
> Signed-off-by: Guido Günther 

Reviewed-by: Martin Kepplinger 

thank you,

  martin

> ---
>  arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> index ffb5fe61630d..1b39514d5c12 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> @@ -45,7 +45,6 @@ key-vol-down {
> gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
> linux,code = ;
> debounce-interval = <50>;
> -   wakeup-source;
> };
>  
> key-vol-up {
> @@ -53,7 +52,6 @@ key-vol-up {
> gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
> linux,code = ;
> debounce-interval = <50>;
> -   wakeup-source;
> };
> };
>  



[PATCH] input: (gtco) use sign_extend32() for sign extension

2015-01-23 Thread Martin Kepplinger
Signed-off-by: Martin Kepplinger 
---
Despite it's name, sign_extend32() is safe to use for 8 and 16 bit types too.


 drivers/input/tablet/gtco.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
index 8580456..272a838 100644
--- a/drivers/input/tablet/gtco.c
+++ b/drivers/input/tablet/gtco.c
@@ -59,7 +59,7 @@ Scott Hill sh...@gtcocalcomp.com
 #include 
 #include 
 #include 
-
+#include 
 
 #include 
 
@@ -666,13 +666,8 @@ static void gtco_urb_callback(struct urb *urbinfo)
case 4:
/* Tilt */
 
-   /* Sign extend these 7 bit numbers.  */
-   if (device->buffer[6] & 0x40)
-   device->buffer[6] |= 0x80;
-
-   if (device->buffer[7] & 0x40)
-   device->buffer[7] |= 0x80;
-
+   device->buffer[6] = sign_extend32(device->buffer[6], 6);
+   device->buffer[7] = sign_extend32(device->buffer[7], 6);
 
valsigned = (device->buffer[6]);
input_report_abs(inputdev, ABS_TILT_X, (s32)valsigned);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] rtc: (x1205) use sign_extend32() for sign extension

2015-01-24 Thread Martin Kepplinger
Signed-off-by: Martin Kepplinger 
---
Despite it's name, sign_extend32() is safe to use for 8 bit types
too. (see https://lkml.org/lkml/2015/1/18/289 if interested)

 drivers/rtc/rtc-x1205.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-x1205.c b/drivers/rtc/rtc-x1205.c
index b1de58e..5638b7b 100644
--- a/drivers/rtc/rtc-x1205.c
+++ b/drivers/rtc/rtc-x1205.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DRV_VERSION "1.0.8"
 
@@ -366,8 +367,7 @@ static int x1205_get_atrim(struct i2c_client *client, int 
*trim)
 * perform sign extension. The formula is
 * Catr = (atr * 0.25pF) + 11.00pF.
 */
-   if (atr & 0x20)
-   atr |= 0xC0;
+   atr = sign_extend32(atr, 5);
 
dev_dbg(&client->dev, "%s: raw atr=%x (%d)\n", __func__, atr, atr);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] media: (stb0899) use sign_extend32() for sign extension

2015-01-25 Thread Martin Kepplinger
Signed-off-by: Martin Kepplinger 
---
 drivers/media/dvb-frontends/stb0899_algo.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/stb0899_algo.c 
b/drivers/media/dvb-frontends/stb0899_algo.c
index 93596e0..7bbcfde 100644
--- a/drivers/media/dvb-frontends/stb0899_algo.c
+++ b/drivers/media/dvb-frontends/stb0899_algo.c
@@ -19,6 +19,7 @@
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 */
 
+#include 
 #include "stb0899_drv.h"
 #include "stb0899_priv.h"
 #include "stb0899_reg.h"
@@ -1490,9 +1491,7 @@ enum stb0899_status stb0899_dvbs2_algo(struct 
stb0899_state *state)
/* Store signal parameters  */
offsetfreq = STB0899_READ_S2REG(STB0899_S2DEMOD, CRL_FREQ);
 
-   /* sign extend 30 bit value before using it in calculations */
-   if (offsetfreq & (1 << 29))
-   offsetfreq |= -1 << 30;
+   offsetfreq = sign_extend32(offset_freq, 29);
 
offsetfreq = offsetfreq / ((1 << 30) / 1000);
offsetfreq *= (internal->master_clk / 100);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2] media: (stb0899) use sign_extend32() for sign extension

2015-01-25 Thread Martin Kepplinger
Signed-off-by: Martin Kepplinger 
---
Sorry. I should have at least built my change. This is the correct version.


 drivers/media/dvb-frontends/stb0899_algo.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/stb0899_algo.c 
b/drivers/media/dvb-frontends/stb0899_algo.c
index 93596e0..3012f19 100644
--- a/drivers/media/dvb-frontends/stb0899_algo.c
+++ b/drivers/media/dvb-frontends/stb0899_algo.c
@@ -19,6 +19,7 @@
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 */
 
+#include 
 #include "stb0899_drv.h"
 #include "stb0899_priv.h"
 #include "stb0899_reg.h"
@@ -1490,9 +1491,7 @@ enum stb0899_status stb0899_dvbs2_algo(struct 
stb0899_state *state)
/* Store signal parameters  */
offsetfreq = STB0899_READ_S2REG(STB0899_S2DEMOD, CRL_FREQ);
 
-   /* sign extend 30 bit value before using it in calculations */
-   if (offsetfreq & (1 << 29))
-   offsetfreq |= -1 << 30;
+   offsetfreq = sign_extend32(offsetfreq, 29);
 
offsetfreq = offsetfreq / ((1 << 30) / 1000);
offsetfreq *= (internal->master_clk / 100);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[RFC PATCH 0/4] Example changes using proposed sign_extend functions

2015-01-14 Thread Martin Kepplinger

These are 4 of probably many examples of what could be changed if the proposed
sign_extend8, 16 and 64 are added to bitops.h, now as real patches.

Again, keep in mind, only take them if "PATCH v2 add sign_exted8, 16 and 64"
is included first.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2/4] rtc: use sign_extend8 instead of manual conversion

2015-01-14 Thread Martin Kepplinger
Signed-off-by: Martin Kepplinger 
---
 drivers/rtc/rtc-x1205.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-x1205.c b/drivers/rtc/rtc-x1205.c
index b1de58e..3ec0b95 100644
--- a/drivers/rtc/rtc-x1205.c
+++ b/drivers/rtc/rtc-x1205.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DRV_VERSION "1.0.8"
 
@@ -366,8 +367,7 @@ static int x1205_get_atrim(struct i2c_client *client, int 
*trim)
 * perform sign extension. The formula is
 * Catr = (atr * 0.25pF) + 11.00pF.
 */
-   if (atr & 0x20)
-   atr |= 0xC0;
+   atr = sign_extend8(atr, 5);
 
dev_dbg(&client->dev, "%s: raw atr=%x (%d)\n", __func__, atr, atr);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 1/4] input: gtco: use bitops' sign_extend8

2015-01-14 Thread Martin Kepplinger
Signed-off-by: Martin Kepplinger 
---
 drivers/input/tablet/gtco.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
index 8580456..25b3834 100644
--- a/drivers/input/tablet/gtco.c
+++ b/drivers/input/tablet/gtco.c
@@ -59,7 +59,7 @@ Scott Hill sh...@gtcocalcomp.com
 #include 
 #include 
 #include 
-
+#include 
 
 #include 
 
@@ -666,13 +666,8 @@ static void gtco_urb_callback(struct urb *urbinfo)
case 4:
/* Tilt */
 
-   /* Sign extend these 7 bit numbers.  */
-   if (device->buffer[6] & 0x40)
-   device->buffer[6] |= 0x80;
-
-   if (device->buffer[7] & 0x40)
-   device->buffer[7] |= 0x80;
-
+   device->buffer[6] = sign_extend8(device->buffer[6], 6);
+   device->buffer[7] = sign_extend8(device->buffer[6], 6);
 
valsigned = (device->buffer[6]);
input_report_abs(inputdev, ABS_TILT_X, (s32)valsigned);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 4/4] hwmon: jc42: use bitops' sign_extend16

2015-01-14 Thread Martin Kepplinger
Signed-off-by: Martin Kepplinger 
Reviewed-by: Guenter Roeck 
---
 drivers/hwmon/jc42.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/jc42.c b/drivers/hwmon/jc42.c
index 388f8bc..d0582a3 100644
--- a/drivers/hwmon/jc42.c
+++ b/drivers/hwmon/jc42.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Addresses to scan */
 static const unsigned short normal_i2c[] = {
@@ -213,11 +214,7 @@ static u16 jc42_temp_to_reg(int temp, bool extended)
 
 static int jc42_temp_from_reg(s16 reg)
 {
-   reg &= 0x1fff;
-
-   /* sign extend register */
-   if (reg & 0x1000)
-   reg |= 0xf000;
+   reg = sign_extend16(reg, 12);
 
/* convert from 0.0625 to 0.001 resolution */
return reg * 125 / 2;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3/4] media: stb0899: use sign_extend8 instead of manual work

2015-01-14 Thread Martin Kepplinger
Signed-off-by: Martin Kepplinger 
---
 drivers/media/dvb-frontends/stb0899_algo.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/stb0899_algo.c 
b/drivers/media/dvb-frontends/stb0899_algo.c
index 93596e0..7bbcfde 100644
--- a/drivers/media/dvb-frontends/stb0899_algo.c
+++ b/drivers/media/dvb-frontends/stb0899_algo.c
@@ -19,6 +19,7 @@
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 */
 
+#include 
 #include "stb0899_drv.h"
 #include "stb0899_priv.h"
 #include "stb0899_reg.h"
@@ -1490,9 +1491,7 @@ enum stb0899_status stb0899_dvbs2_algo(struct 
stb0899_state *state)
/* Store signal parameters  */
offsetfreq = STB0899_READ_S2REG(STB0899_S2DEMOD, CRL_FREQ);
 
-   /* sign extend 30 bit value before using it in calculations */
-   if (offsetfreq & (1 << 29))
-   offsetfreq |= -1 << 30;
+   offsetfreq = sign_extend32(offset_freq, 29);
 
offsetfreq = offsetfreq / ((1 << 30) / 1000);
offsetfreq *= (internal->master_clk / 100);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 3/6] hwmon: jc42: use bitops' sign_extend16

2015-01-11 Thread Martin Kepplinger
Am 2014-12-16 um 08:17 schrieb Martin Kepplinger:
> Am 2014-12-15 um 22:29 schrieb Guenter Roeck:
>> On Mon, Dec 15, 2014 at 05:18:34PM +0100, Martin Kepplinger wrote:
>>> ---
>>
>> Some description would be nice. Also, please consider adding
>> relevant subsystem mailing lists and maintainers to your patches.
>>
> 
> I shouldn't have added the Signed-off-by line to some of them. Sorry.
> 
> The driver-patches are meant to be examples of what can be changed if
> the sign_extend functions are added. I don't know if they are taken and
> planned to post the driver patches (probably more) thereafter, and of
> course to the relevant people.

Is this sign_extendXX() set of functions considered to be added to
bitops.h ?

Just checking if I can prepare some driver-patches (the ones I posted
are just examples, meant to be re-sent to relevant maintainers when it's
time), or not.

thanks

> 
>>>  drivers/hwmon/jc42.c | 5 ++---
>>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/hwmon/jc42.c b/drivers/hwmon/jc42.c
>>> index 388f8bc..335a2de 100644
>>> --- a/drivers/hwmon/jc42.c
>>> +++ b/drivers/hwmon/jc42.c
>>> @@ -31,6 +31,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  
>>>  /* Addresses to scan */
>>>  static const unsigned short normal_i2c[] = {
>>> @@ -215,9 +216,7 @@ static int jc42_temp_from_reg(s16 reg)
>>>  {
>>> reg &= 0x1fff;
>>>  
>> If I understand the code in sign_extend16 correctly, the above mask
>> should no longer be necessary.
> 
> exactly. The mask would then be shifting. Thanks!
> 
>>
>> Thanks,
>> Guenter
>>
>>> -   /* sign extend register */
>>> -   if (reg & 0x1000)
>>> -   reg |= 0xf000;
>>> +   reg = sign_extend16(reg, 12);
>>>  
>>> /* convert from 0.0625 to 0.001 resolution */
>>> return reg * 125 / 2;
>>> -- 
>>> 2.1.3
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>
>>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2] bitops.h: add sign_extend8(), 16 and 64 functions

2015-01-12 Thread Martin Kepplinger
This adds helper functions for sign-extending signed values of any lower
(hardware-)given size to s8, s16 or s64 respectively, just like sign_extend32()
for s32.

Signed-off-by: Martin Kepplinger 
Suggested-by: Christoph Muellner 
---
 include/linux/bitops.h | 33 +
 1 file changed, 33 insertions(+)

diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 5d858e0..9c31680 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -161,6 +161,28 @@ static inline __u8 ror8(__u8 word, unsigned int shift)
 }
 
 /**
+ * sign_extend8 - sign extend a 8-bit value using specified bit as sign-bit
+ * @value: value to sign extend
+ * @index: 0 based bit index (0<=index<8) to sign bit
+ */
+static inline __s8 sign_extend8(__u8 value, int index)
+{
+   __u8 shift = 7 - index;
+   return (__s8)(value << shift) >> shift;
+}
+
+/**
+ * sign_extend16 - sign extend a 16-bit value using specified bit as sign-bit
+ * @value: value to sign extend
+ * @index: 0 based bit index (0<=index<16) to sign bit
+ */
+static inline __s16 sign_extend16(__u16 value, int index)
+{
+   __u8 shift = 15 - index;
+   return (__s16)(value << shift) >> shift;
+}
+
+/**
  * sign_extend32 - sign extend a 32-bit value using specified bit as sign-bit
  * @value: value to sign extend
  * @index: 0 based bit index (0<=index<32) to sign bit
@@ -171,6 +193,17 @@ static inline __s32 sign_extend32(__u32 value, int index)
return (__s32)(value << shift) >> shift;
 }
 
+/**
+ * sign_extend64 - sign extend a 64-bit value using specified bit as sign-bit
+ * @value: value to sign extend
+ * @index: 0 based bit index (0<=index<64) to sign bit
+ */
+static inline __s64 sign_extend64(__u64 value, int index)
+{
+   __u8 shift = 63 - index;
+   return (__s64)(value << shift) >> shift;
+}
+
 static inline unsigned fls_long(unsigned long l)
 {
if (sizeof(l) == 4)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[RFC] hwmon: jc42: use bitops' sign_extend16

2015-01-12 Thread Martin Kepplinger
Example change, using new sign_extend functions.
---
 drivers/hwmon/jc42.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/jc42.c b/drivers/hwmon/jc42.c
index 388f8bc..d0582a3 100644
--- a/drivers/hwmon/jc42.c
+++ b/drivers/hwmon/jc42.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Addresses to scan */
 static const unsigned short normal_i2c[] = {
@@ -213,11 +214,7 @@ static u16 jc42_temp_to_reg(int temp, bool extended)
 
 static int jc42_temp_from_reg(s16 reg)
 {
-   reg &= 0x1fff;
-
-   /* sign extend register */
-   if (reg & 0x1000)
-   reg |= 0xf000;
+   reg = sign_extend16(reg, 12);
 
/* convert from 0.0625 to 0.001 resolution */
return reg * 125 / 2;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[RFC] rtc: use sign_extend8 instead of manual conversion

2015-01-12 Thread Martin Kepplinger
Example change, using new sign_extend functions.
---
 drivers/rtc/rtc-x1205.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-x1205.c b/drivers/rtc/rtc-x1205.c
index b1de58e..3ec0b95 100644
--- a/drivers/rtc/rtc-x1205.c
+++ b/drivers/rtc/rtc-x1205.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DRV_VERSION "1.0.8"
 
@@ -366,8 +367,7 @@ static int x1205_get_atrim(struct i2c_client *client, int 
*trim)
 * perform sign extension. The formula is
 * Catr = (atr * 0.25pF) + 11.00pF.
 */
-   if (atr & 0x20)
-   atr |= 0xC0;
+   atr = sign_extend8(atr, 5);
 
dev_dbg(&client->dev, "%s: raw atr=%x (%d)\n", __func__, atr, atr);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[RFC] input: gtco: use bitops' sign_extend8

2015-01-12 Thread Martin Kepplinger
Example change, using new sign_extend functions.
---
 drivers/input/tablet/gtco.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
index 8580456..25b3834 100644
--- a/drivers/input/tablet/gtco.c
+++ b/drivers/input/tablet/gtco.c
@@ -59,7 +59,7 @@ Scott Hill sh...@gtcocalcomp.com
 #include 
 #include 
 #include 
-
+#include 
 
 #include 
 
@@ -666,13 +666,8 @@ static void gtco_urb_callback(struct urb *urbinfo)
case 4:
/* Tilt */
 
-   /* Sign extend these 7 bit numbers.  */
-   if (device->buffer[6] & 0x40)
-   device->buffer[6] |= 0x80;
-
-   if (device->buffer[7] & 0x40)
-   device->buffer[7] |= 0x80;
-
+   device->buffer[6] = sign_extend8(device->buffer[6], 6);
+   device->buffer[7] = sign_extend8(device->buffer[6], 6);
 
valsigned = (device->buffer[6]);
input_report_abs(inputdev, ABS_TILT_X, (s32)valsigned);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[RFC] media: stb0899: use sign_extend8 instead of manual work

2015-01-12 Thread Martin Kepplinger
Example change, using new sign_extend functions.
---
 drivers/media/dvb-frontends/stb0899_algo.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/stb0899_algo.c 
b/drivers/media/dvb-frontends/stb0899_algo.c
index 93596e0..7bbcfde 100644
--- a/drivers/media/dvb-frontends/stb0899_algo.c
+++ b/drivers/media/dvb-frontends/stb0899_algo.c
@@ -19,6 +19,7 @@
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 */
 
+#include 
 #include "stb0899_drv.h"
 #include "stb0899_priv.h"
 #include "stb0899_reg.h"
@@ -1490,9 +1491,7 @@ enum stb0899_status stb0899_dvbs2_algo(struct 
stb0899_state *state)
/* Store signal parameters  */
offsetfreq = STB0899_READ_S2REG(STB0899_S2DEMOD, CRL_FREQ);
 
-   /* sign extend 30 bit value before using it in calculations */
-   if (offsetfreq & (1 << 29))
-   offsetfreq |= -1 << 30;
+   offsetfreq = sign_extend32(offset_freq, 29);
 
offsetfreq = offsetfreq / ((1 << 30) / 1000);
offsetfreq *= (internal->master_clk / 100);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 3/6] hwmon: jc42: use bitops' sign_extend16

2015-01-12 Thread Martin Kepplinger
Am 2015-01-11 um 17:52 schrieb Guenter Roeck:
> On 01/11/2015 02:34 AM, Martin Kepplinger wrote:
>> Am 2014-12-16 um 08:17 schrieb Martin Kepplinger:
>>> Am 2014-12-15 um 22:29 schrieb Guenter Roeck:
>>>> On Mon, Dec 15, 2014 at 05:18:34PM +0100, Martin Kepplinger wrote:
>>>>> ---
>>>>
>>>> Some description would be nice. Also, please consider adding
>>>> relevant subsystem mailing lists and maintainers to your patches.
>>>>
>>>
>>> I shouldn't have added the Signed-off-by line to some of them. Sorry.
>>>
>>> The driver-patches are meant to be examples of what can be changed if
>>> the sign_extend functions are added. I don't know if they are taken and
>>> planned to post the driver patches (probably more) thereafter, and of
>>> course to the relevant people.
>>
>> Is this sign_extendXX() set of functions considered to be added to
>> bitops.h ?
>>
>> Just checking if I can prepare some driver-patches (the ones I posted
>> are just examples, meant to be re-sent to relevant maintainers when it's
>> time), or not.
>>
> 
> You should probably ask the question as response to patch 1/6.
> 
> In general, it might be useful to send example patches like this one as
> RFC.
> Sending it as real patch and then saying "it is just an example" may result
> in the entire series being ignored. This is not a matter of Signed-off
> or not
> (originally I didn't even understand what you wanted to say with your
> reply),
> but a matter of a non-misleading headline.
> 
> Thanks,
> Guenter
> 

Thanks for the advice. I resent, https://lkml.org/lkml/2015/1/12/590
because the thing is easier than it might now seem, and hope that
doesn't add confusion.

thanks again,
 martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v4] add support for Freescale's MMA8653FC 10 bit accelerometer

2015-03-20 Thread Martin Kepplinger
From: Martin Kepplinger 

The MMA8653FC is a low-power, three-axis, capacitive micromachined
accelerometer with 10 bits of resolution with flexible user-programmable
options.

Embedded interrupt functions enable overall power savings, by relieving the
host processor from continuously polling data, for example using the poll()
system call.

The device can be configured to generate wake-up interrupt signals from any
combination of the configurable embedded functions, enabling the MMA8653FC
to monitor events while remaining in a low-power mode during periods of
inactivity.

This driver provides devicetree properties to program the device's behaviour
and a simple, tested and documented sysfs interface. The data sheet and more
information is available on Freescale's website.

Signed-off-by: Martin Kepplinger 
Signed-off-by: Christoph Muellner 
---

patch revision history
..
v4 changes DT propery names, adds a missing interrupt source and removes
   the DT option to set interrupt line active high due to unsuccesful testing
v3 moves the driver from drivers/input/misc to drivers/misc
v2 corrects licensing and commit messages and adds appropriate recipients


 .../testing/sysfs-bus-i2c-devices-fsl-mma8653fc|  39 +
 .../devicetree/bindings/misc/fsl,mma8653fc.txt | 102 +++
 MAINTAINERS|   5 +
 drivers/misc/Kconfig   |  11 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/mma8653fc.c   | 897 +
 6 files changed, 1055 insertions(+)
 create mode 100644 
Documentation/ABI/testing/sysfs-bus-i2c-devices-fsl-mma8653fc
 create mode 100644 Documentation/devicetree/bindings/misc/fsl,mma8653fc.txt
 create mode 100644 drivers/misc/mma8653fc.c

diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsl-mma8653fc 
b/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsl-mma8653fc
new file mode 100644
index 000..8172c27
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsl-mma8653fc
@@ -0,0 +1,39 @@
+What:  /sys/bus/i2c/drivers/mma8653fc/*/standby
+Date:  March 2015
+Contact:       Martin Kepplinger 
+Description:
+   Write 0 to this in order to turn on the device, and 1 to turn
+   it off. Read to see if it is turned on or off.
+
+
+What:  /sys/bus/i2c/drivers/mma8653fc/*/currentmode
+Date:  March 2015
+Contact:       Martin Kepplinger 
+Description:
+   Reading this provides the current state of the device, read
+   directly from a register. This can be "standby", "wake" or
+   "sleep".
+
+
+What:  /sys/bus/i2c/drivers/mma8653fc/*/position
+Date:      March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Read only. Without interrupts enabled gets current position
+   values by reading. Poll "position" with interrupt conditions
+   set, to get notified; see Documentation/.../fsl,mma8653fc.txt
+
+   position file format:
+   "x y z [landscape/portrait status] [front/back status]"
+
+   x y z values:
+   in mg
+   landscape/portrait status char:
+   r   landscape right
+   d   portrait down
+   u   portrait up
+   l   landscape left
+   front/back status char:
+   f   front facing
+   b   back facing
+
diff --git a/Documentation/devicetree/bindings/misc/fsl,mma8653fc.txt 
b/Documentation/devicetree/bindings/misc/fsl,mma8653fc.txt
new file mode 100644
index 000..5015813
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/fsl,mma8653fc.txt
@@ -0,0 +1,102 @@
+Freescale MMA8653FC 3-axis Accelerometer
+
+Required properties:
+- compatible
+   "fsl,mma8653fc"
+- reg
+   I2C address
+
+Optional properties:
+
+- interrupt-parent
+   a phandle for the interrupt controller (see
+   Documentation/devicetree/bindings/interrupt-controller/interrupts.txt)
+- interrupts
+   interrupt line to which the chip is connected (active low)
+- int1
+   set to use interrupt line 1, default is line 2
+   the interrupt sources can be routed to one of the two lines
+- ir-freefall-motion-x
+   activate freefall/motion interrupts on x axis
+- ir-freefall-motion-y
+   activate freefall/motion interrupts on y axis
+- ir-freefall-motion-z
+   activate freefall/motion interrupts on z axis
+- irq-threshold
+   0 < value < 8000: threshold for motion interrupts in mg
+- ir-landscape-portrait
+   activate landscape/portrait interrupts
+- ir-auto-wake
+   activate wake/sleep change interrupts
+- ir-data-ready:
+   activate data-ready interrupts
+   Interrupt events can b

Re: [PATCH v3] add support for Freescale's MMA8653FC 10 bit accelerometer

2015-03-20 Thread Martin Kepplinger
Am 2015-03-19 um 17:03 schrieb Mark Rutland:
>> diff --git a/Documentation/devicetree/bindings/misc/fsl,mma8653fc.txt 
>> b/Documentation/devicetree/bindings/misc/fsl,mma8653fc.txt
>> new file mode 100644
>> index 000..3921acb
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/fsl,mma8653fc.txt
>> @@ -0,0 +1,96 @@
>> +Freescale MMA8653FC 3-axis Accelerometer
>> +
>> +Required properties:
>> +- compatible
>> +   "fsl,mma8653fc"
>> +- reg
>> +   I2C address
>> +
>> +Optional properties:
>> +
>> +- interrupt-parent
>> +   a phandle for the interrupt controller (see
>> +   
>> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt)
>> +- interrupts
>> +   interrupt line to which the chip is connected
>> +- int1
>> +   set to use interrupt line 1 instead of 2
> 
> If you have two interrupt output lines, you should have two entries in
> interrupts.
> 
> You can use interrupt-names to determine which line(s) are wired up.
> 

You can't use both interrupt lines. You have to decide on one and all
your selected interrupt sources will be on this one line.

> I don't believe that you need this property.
> 
>> +- int_active_high
>> +   set interrupt line active high
> 
> s/_/-/ in property names please. 
> 
> What happens if this isn't set? Is it active-low, or edge-triggered?
> 
> It feels like we should be able to query when we need to set this from
> the IRQ(s).

It's active low per default. I investigated and couldn't successfully
use active high. In v4 of the patch, this option is gone and documented.

> 
>> +- ir_freefall_motion_x
>> +   activate freefall/motion interrupts on x axis
>> +- ir_freefall_motion_y
>> +   activate freefall/motion interrupts on y axis
>> +- ir_freefall_motion_z
>> +   activate freefall/motion interrupts on z axis
>> +- irq_threshold
>> +   0 < value < 8000: threshold for motion interrupts in mg
>> +- ir_landscape_portrait
>> +   activate landscape/portrait interrupts
>> +- ir_data_ready:
>> +   activate data-ready interrupts
>> +   Interrupt events can be activated in any combination.
> 
> These all sounds like they would be better as runtime options. I don't
> see why these should necessarily be in the DT.

First, I don't really want to expand the sysfs ABI much. Second, there
are use cases that don't need these at runtime and it would seem to make
it even harder for systems to use this driver.

> 
>> +- range
>> +   2, 4, or 8: range in g, default: 2
> 
> Likewise.
> 
> It would be nice to have a better qualified name than "range".

I use "dynamic-range" in v4 of the patch.

> 
>> +- auto_wake_sleep
>> +   auto sleep mode (lower frequency)
>> +- motion_mode
>> +   use motion mode instead of freefall mode (trigger if >threshold).
>> +   per default an interrupt occurs if motion values fall below the
>> +   value set in "threshold" and therefore can detect free fall on the
>> +   vertical axis (depending on the position of the device).
>> +   Setting this values inverts the behaviour and an interrupt occurs
>> +   above the threshold value, so usually activate horizontal axis in
>> +   this case.
> 
> These both sound like they would be better as runtime options.
> 
>> +
>> +- x-offset
>> +   0 < value < 500: calibration offset in mg
>> +   this value has an offset of 250 itself:
>> +   0 is -250mg, 250 is 0 mg, 500 is 250mg
>> +- y-offset
>> +   see x-offset
>> +- z-offset
>> +   see x-offset
> 
> I'm unsure about these; it really depends on what the calibration is
> for.

this is better documented in v4 of the patch.

> 
> Mark.
> 

thanks for reviewing!

  martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2] add support for Freescale's MMA8653FC 10 bit accelerometer

2015-03-20 Thread Martin Kepplinger
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:
>>>>>>
>>>>> 
>>>>>> 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.

Please refer to v4 of the patch for different questions. thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v4] add support for Freescale's MMA8653FC 10 bit accelerometer

2015-03-20 Thread Martin Kepplinger
Am 2015-03-20 um 12:31 schrieb Varka Bhadram:
> On 03/20/2015 04:50 PM, Martin Kepplinger wrote:
>> From: Martin Kepplinger 
>>
( ...)
>> +return 0;
>> +
>> + err_free_irq:
>> +if (mma->irq)
>> +free_irq(mma->irq, mma);
>> + err_free_mem:
>> +kfree(mma);
> 
> If we use devm_* API's above steps are not required
> 
>> + err_out:
>> +return err;
>> +}
>> +
>> +static int mma8653fc_remove(struct i2c_client *client)
>> +{
>> +struct mma8653fc *mma = i2c_get_clientdata(client);
>> +
>> +free_irq(mma->irq, mma);
>> +dev_dbg(&client->dev, "unregistered accelerometer\n");
>> +kfree(mma);
> 
> same as above..
> 

thanks!


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2] add support for Freescale's MMA8653FC 10 bit accelerometer

2015-03-20 Thread Martin Kepplinger
Am 2015-03-20 um 13:27 schrieb Benjamin Tissoires:
> On Fri, Mar 20, 2015 at 7:26 AM, Martin Kepplinger
>  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:
>>>>>>>>
>>>>>>> 
>>>>>>>> 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.

That seems reasonable. I have prepared a (little more cleaned up) v5 of
the patch and moved it to staging, with a TODO file containing also the
current documentation. I hope to be able to do the iio integration
sometime "soon", but this could speed things up.

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

That's totally fine. Of course iio is the way to go. I had the driver
before I really knew iio and this was lazyness (when I found
Documentation/ABI/testing), plus the desire to publish it before the
chip itself is deprecated.

> 
> 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 majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v5] add support for Freescale's MMA8653FC 10 bit accelerometer

2015-03-20 Thread Martin Kepplinger
From: Martin Kepplinger 

The MMA8653FC is a low-power, three-axis, capacitive micromachined
accelerometer with 10 bits of resolution with flexible user-programmable
options.

Embedded interrupt functions enable overall power savings, by relieving the
host processor from continuously polling data, for example using the poll()
system call.

The device can be configured to generate wake-up interrupt signals from any
combination of the configurable embedded functions, enabling the MMA8653FC
to monitor events while remaining in a low-power mode during periods of
inactivity.

This driver provides devicetree properties to program the device's behaviour
and a simple, tested and documented sysfs interface. The data sheet and more
information is available on Freescale's website.

Signed-off-by: Martin Kepplinger 
Signed-off-by: Christoph Muellner 
---

patch revision history
..
v5 clean up (suggested by Varka Bhadram) and move the driver to staging
v4 changes DT propery names, adds a missing interrupt source and removes
   the DT option to set interrupt line active high due to unsuccesful testing
v3 moves the driver from drivers/input/misc to drivers/misc
v2 corrects licensing and commit messages and adds appropriate recipients


 drivers/staging/Kconfig   |   2 +
 drivers/staging/mma8653fc/Kconfig |  10 +
 drivers/staging/mma8653fc/Makefile|   1 +
 drivers/staging/mma8653fc/TODO| 146 ++
 drivers/staging/mma8653fc/mma8653fc.c | 864 ++
 5 files changed, 1023 insertions(+)
 create mode 100644 drivers/staging/mma8653fc/Kconfig
 create mode 100644 drivers/staging/mma8653fc/Makefile
 create mode 100644 drivers/staging/mma8653fc/TODO
 create mode 100644 drivers/staging/mma8653fc/mma8653fc.c

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 45baa83..661e5f5 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -108,4 +108,6 @@ source "drivers/staging/fbtft/Kconfig"
 
 source "drivers/staging/i2o/Kconfig"
 
+source "drivers/staging/mma8653fc/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/mma8653fc/Kconfig 
b/drivers/staging/mma8653fc/Kconfig
new file mode 100644
index 000..988451b
--- /dev/null
+++ b/drivers/staging/mma8653fc/Kconfig
@@ -0,0 +1,10 @@
+config MMA8653FC
+tristate "MMA8653FC - Freescale's 3-Axis, 10-bit Digital Accelerometer"
+depends on I2C
+default n
+help
+  Say Y here if you want to support Freescale's MMA8653FC Accelerometer
+  through I2C interface.
+
+  To compile this driver as a module, choose M here: the
+  module will be called mma8653fc.
diff --git a/drivers/staging/mma8653fc/Makefile 
b/drivers/staging/mma8653fc/Makefile
new file mode 100644
index 000..9a245a3
--- /dev/null
+++ b/drivers/staging/mma8653fc/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MMA8653FC) += mma8653fc.o
diff --git a/drivers/staging/mma8653fc/TODO b/drivers/staging/mma8653fc/TODO
new file mode 100644
index 000..0a31225
--- /dev/null
+++ b/drivers/staging/mma8653fc/TODO
@@ -0,0 +1,146 @@
+- move to IIO device API. The current DT/sysfs interface is documented below
+
+Documentation/ABI/testing/...
+-
+What:  /sys/bus/i2c/drivers/mma8653fc/*/standby
+Date:  March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Write 0 to this in order to turn on the device, and 1 to turn
+   it off. Read to see if it is turned on or off.
+
+
+What:  /sys/bus/i2c/drivers/mma8653fc/*/currentmode
+Date:  March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Reading this provides the current state of the device, read
+   directly from a register. This can be "standby", "wake" or
+   "sleep".
+
+
+What:  /sys/bus/i2c/drivers/mma8653fc/*/position
+Date:  March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Read only. Without interrupts enabled gets current position
+   values by reading. Poll "position" with interrupt conditions
+   set, to get notified; see Documentation/.../fsl,mma8653fc.txt
+
+   position file format:
+   "x y z [landscape/portrait status] [front/back status]"
+
+   x y z values:
+   in mg
+   landscape/portrait status char:
+   r   landscape right
+   d   portrait down
+   u   portrait up
+   l   landscape left
+   front/back status char:
+   f   front facing
+   b   back facing
+
+
+Documentation/devicetree/bindings/...
+-
+Required properties:
+- compatible
+   

[PATCH v5] add support for Freescale's MMA8653FC 10 bit accelerometer

2015-03-20 Thread Martin Kepplinger
From: Martin Kepplinger 

The MMA8653FC is a low-power, three-axis, capacitive micromachined
accelerometer with 10 bits of resolution with flexible user-programmable
options.

Embedded interrupt functions enable overall power savings, by relieving the
host processor from continuously polling data, for example using the poll()
system call.

The device can be configured to generate wake-up interrupt signals from any
combination of the configurable embedded functions, enabling the MMA8653FC
to monitor events while remaining in a low-power mode during periods of
inactivity.

This driver provides devicetree properties to program the device's behaviour
and a simple, tested and documented sysfs interface. The data sheet and more
information is available on Freescale's website.

Signed-off-by: Martin Kepplinger 
Signed-off-by: Christoph Muellner 
---

This would be v5 aswell, but appies to the current -next tree.

 drivers/staging/mma8653fc/Kconfig |  10 +
 drivers/staging/mma8653fc/Makefile|   1 +
 drivers/staging/mma8653fc/TODO| 146 ++
 drivers/staging/mma8653fc/mma8653fc.c | 864 ++
 4 files changed, 1021 insertions(+)
 create mode 100644 drivers/staging/mma8653fc/Kconfig
 create mode 100644 drivers/staging/mma8653fc/Makefile
 create mode 100644 drivers/staging/mma8653fc/TODO
 create mode 100644 drivers/staging/mma8653fc/mma8653fc.c

diff --git a/drivers/staging/mma8653fc/Kconfig 
b/drivers/staging/mma8653fc/Kconfig
new file mode 100644
index 000..988451b
--- /dev/null
+++ b/drivers/staging/mma8653fc/Kconfig
@@ -0,0 +1,10 @@
+config MMA8653FC
+tristate "MMA8653FC - Freescale's 3-Axis, 10-bit Digital Accelerometer"
+depends on I2C
+default n
+help
+  Say Y here if you want to support Freescale's MMA8653FC Accelerometer
+  through I2C interface.
+
+  To compile this driver as a module, choose M here: the
+  module will be called mma8653fc.
diff --git a/drivers/staging/mma8653fc/Makefile 
b/drivers/staging/mma8653fc/Makefile
new file mode 100644
index 000..9a245a3
--- /dev/null
+++ b/drivers/staging/mma8653fc/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MMA8653FC) += mma8653fc.o
diff --git a/drivers/staging/mma8653fc/TODO b/drivers/staging/mma8653fc/TODO
new file mode 100644
index 000..0a31225
--- /dev/null
+++ b/drivers/staging/mma8653fc/TODO
@@ -0,0 +1,146 @@
+- move to IIO device API. The current DT/sysfs interface is documented below
+
+Documentation/ABI/testing/...
+-
+What:  /sys/bus/i2c/drivers/mma8653fc/*/standby
+Date:      March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Write 0 to this in order to turn on the device, and 1 to turn
+   it off. Read to see if it is turned on or off.
+
+
+What:  /sys/bus/i2c/drivers/mma8653fc/*/currentmode
+Date:      March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Reading this provides the current state of the device, read
+   directly from a register. This can be "standby", "wake" or
+   "sleep".
+
+
+What:  /sys/bus/i2c/drivers/mma8653fc/*/position
+Date:  March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Read only. Without interrupts enabled gets current position
+   values by reading. Poll "position" with interrupt conditions
+   set, to get notified; see Documentation/.../fsl,mma8653fc.txt
+
+   position file format:
+   "x y z [landscape/portrait status] [front/back status]"
+
+   x y z values:
+   in mg
+   landscape/portrait status char:
+   r   landscape right
+   d   portrait down
+   u   portrait up
+   l   landscape left
+   front/back status char:
+   f   front facing
+   b   back facing
+
+
+Documentation/devicetree/bindings/...
+-
+Required properties:
+- compatible
+   "fsl,mma8653fc"
+- reg
+   I2C address
+
+Optional properties:
+
+- interrupt-parent
+   a phandle for the interrupt controller (see
+   Documentation/devicetree/bindings/interrupt-controller/interrupts.txt)
+- interrupts
+   interrupt line to which the chip is connected (active low)
+- int1
+   set to use interrupt line 1, default is line 2
+   the interrupt sources can be routed to one of the two lines
+- ir-freefall-motion-x
+   activate freefall/motion interrupts on x axis
+- ir-freefall-motion-y
+   activate freefall/motion interrupts on y axis
+- ir-freefall-motion-z
+   activate freefall/motion interrupts on z axis
+- irq-threshold
+   0 < value < 8000: th

[PATCH v5] add support for Freescale's MMA8653FC 10 bit accelerometer

2015-03-21 Thread Martin Kepplinger
From: Martin Kepplinger 

The MMA8653FC is a low-power, three-axis, capacitive micromachined
accelerometer with 10 bits of resolution with flexible user-programmable
options.

Embedded interrupt functions enable overall power savings, by relieving the
host processor from continuously polling data, for example using the poll()
system call.

The device can be configured to generate wake-up interrupt signals from any
combination of the configurable embedded functions, enabling the MMA8653FC
to monitor events while remaining in a low-power mode during periods of
inactivity.

This driver provides devicetree properties to program the device's behaviour
and a simple, tested and documented sysfs interface. The data sheet and more
information is available on Freescale's website.

Signed-off-by: Martin Kepplinger 
Signed-off-by: Christoph Muellner 
---

Sorry, I forgot the Kconfig integration into drivers/staging.
This applies and builds.

 drivers/staging/Kconfig   |   2 +
 drivers/staging/mma8653fc/Kconfig |  10 +
 drivers/staging/mma8653fc/Makefile|   1 +
 drivers/staging/mma8653fc/TODO| 146 ++
 drivers/staging/mma8653fc/mma8653fc.c | 864 ++
 5 files changed, 1023 insertions(+)
 create mode 100644 drivers/staging/mma8653fc/Kconfig
 create mode 100644 drivers/staging/mma8653fc/Makefile
 create mode 100644 drivers/staging/mma8653fc/TODO
 create mode 100644 drivers/staging/mma8653fc/mma8653fc.c

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index bfacf69..834d949 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -112,4 +112,6 @@ source "drivers/staging/i2o/Kconfig"
 
 source "drivers/staging/fsl-mc/Kconfig"
 
+source "drivers/staging/mma8653fc/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/mma8653fc/Kconfig 
b/drivers/staging/mma8653fc/Kconfig
new file mode 100644
index 000..988451b
--- /dev/null
+++ b/drivers/staging/mma8653fc/Kconfig
@@ -0,0 +1,10 @@
+config MMA8653FC
+tristate "MMA8653FC - Freescale's 3-Axis, 10-bit Digital Accelerometer"
+depends on I2C
+default n
+help
+  Say Y here if you want to support Freescale's MMA8653FC Accelerometer
+  through I2C interface.
+
+  To compile this driver as a module, choose M here: the
+  module will be called mma8653fc.
diff --git a/drivers/staging/mma8653fc/Makefile 
b/drivers/staging/mma8653fc/Makefile
new file mode 100644
index 000..9a245a3
--- /dev/null
+++ b/drivers/staging/mma8653fc/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MMA8653FC) += mma8653fc.o
diff --git a/drivers/staging/mma8653fc/TODO b/drivers/staging/mma8653fc/TODO
new file mode 100644
index 000..0a31225
--- /dev/null
+++ b/drivers/staging/mma8653fc/TODO
@@ -0,0 +1,146 @@
+- move to IIO device API. The current DT/sysfs interface is documented below
+
+Documentation/ABI/testing/...
+-
+What:  /sys/bus/i2c/drivers/mma8653fc/*/standby
+Date:  March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Write 0 to this in order to turn on the device, and 1 to turn
+   it off. Read to see if it is turned on or off.
+
+
+What:  /sys/bus/i2c/drivers/mma8653fc/*/currentmode
+Date:  March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Reading this provides the current state of the device, read
+   directly from a register. This can be "standby", "wake" or
+   "sleep".
+
+
+What:  /sys/bus/i2c/drivers/mma8653fc/*/position
+Date:  March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Read only. Without interrupts enabled gets current position
+   values by reading. Poll "position" with interrupt conditions
+   set, to get notified; see Documentation/.../fsl,mma8653fc.txt
+
+   position file format:
+   "x y z [landscape/portrait status] [front/back status]"
+
+   x y z values:
+   in mg
+   landscape/portrait status char:
+   r   landscape right
+   d   portrait down
+   u   portrait up
+   l   landscape left
+   front/back status char:
+   f   front facing
+   b   back facing
+
+
+Documentation/devicetree/bindings/...
+-
+Required properties:
+- compatible
+   "fsl,mma8653fc"
+- reg
+   I2C address
+
+Optional properties:
+
+- interrupt-parent
+   a phandle for the interrupt controller (see
+   Documentation/devicetree/bindings/interrupt-controller/interrupts.txt)
+- interrupts
+   interrupt line to which the chip is connected (active low)

[PATCH v5] add support for Freescale's MMA8653FC 10 bit accelerometer

2015-03-21 Thread Martin Kepplinger
From: Martin Kepplinger 

The MMA8653FC is a low-power, three-axis, capacitive micromachined
accelerometer with 10 bits of resolution with flexible user-programmable
options.

Embedded interrupt functions enable overall power savings, by relieving the
host processor from continuously polling data, for example using the poll()
system call.

The device can be configured to generate wake-up interrupt signals from any
combination of the configurable embedded functions, enabling the MMA8653FC
to monitor events while remaining in a low-power mode during periods of
inactivity.

This driver provides devicetree properties to program the device's behaviour
and a simple, tested and documented sysfs interface. The data sheet and more
information is available on Freescale's website.

Signed-off-by: Martin Kepplinger 
Signed-off-by: Christoph Muellner 
---

Still, I was missing the drivers/staging Makefile addition. This applies and
builds automatically.

 drivers/staging/Kconfig   |   2 +
 drivers/staging/Makefile  |   1 +
 drivers/staging/mma8653fc/Kconfig |  10 +
 drivers/staging/mma8653fc/Makefile|   1 +
 drivers/staging/mma8653fc/TODO| 146 ++
 drivers/staging/mma8653fc/mma8653fc.c | 864 ++
 6 files changed, 1024 insertions(+)
 create mode 100644 drivers/staging/mma8653fc/Kconfig
 create mode 100644 drivers/staging/mma8653fc/Makefile
 create mode 100644 drivers/staging/mma8653fc/TODO
 create mode 100644 drivers/staging/mma8653fc/mma8653fc.c

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index bfacf69..834d949 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -112,4 +112,6 @@ source "drivers/staging/i2o/Kconfig"
 
 source "drivers/staging/fsl-mc/Kconfig"
 
+source "drivers/staging/mma8653fc/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 2bbd1bf..cfea86a 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -48,3 +48,4 @@ obj-$(CONFIG_COMMON_CLK_XLNX_CLKWZRD) += clocking-wizard/
 obj-$(CONFIG_FB_TFT)   += fbtft/
 obj-$(CONFIG_I2O)  += i2o/
 obj-$(CONFIG_FSL_MC_BUS)   += fsl-mc/
+obj-$(CONFIG_MMA8653FC)+= mma8653fc/
diff --git a/drivers/staging/mma8653fc/Kconfig 
b/drivers/staging/mma8653fc/Kconfig
new file mode 100644
index 000..988451b
--- /dev/null
+++ b/drivers/staging/mma8653fc/Kconfig
@@ -0,0 +1,10 @@
+config MMA8653FC
+tristate "MMA8653FC - Freescale's 3-Axis, 10-bit Digital Accelerometer"
+depends on I2C
+default n
+help
+  Say Y here if you want to support Freescale's MMA8653FC Accelerometer
+  through I2C interface.
+
+  To compile this driver as a module, choose M here: the
+  module will be called mma8653fc.
diff --git a/drivers/staging/mma8653fc/Makefile 
b/drivers/staging/mma8653fc/Makefile
new file mode 100644
index 000..9a245a3
--- /dev/null
+++ b/drivers/staging/mma8653fc/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MMA8653FC) += mma8653fc.o
diff --git a/drivers/staging/mma8653fc/TODO b/drivers/staging/mma8653fc/TODO
new file mode 100644
index 000..0a31225
--- /dev/null
+++ b/drivers/staging/mma8653fc/TODO
@@ -0,0 +1,146 @@
+- move to IIO device API. The current DT/sysfs interface is documented below
+
+Documentation/ABI/testing/...
+-
+What:  /sys/bus/i2c/drivers/mma8653fc/*/standby
+Date:  March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Write 0 to this in order to turn on the device, and 1 to turn
+   it off. Read to see if it is turned on or off.
+
+
+What:  /sys/bus/i2c/drivers/mma8653fc/*/currentmode
+Date:  March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Reading this provides the current state of the device, read
+   directly from a register. This can be "standby", "wake" or
+   "sleep".
+
+
+What:  /sys/bus/i2c/drivers/mma8653fc/*/position
+Date:  March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Read only. Without interrupts enabled gets current position
+   values by reading. Poll "position" with interrupt conditions
+   set, to get notified; see Documentation/.../fsl,mma8653fc.txt
+
+   position file format:
+   "x y z [landscape/portrait status] [front/back status]"
+
+   x y z values:
+   in mg
+   landscape/portrait status char:
+   r   landscape right
+   d   portrait down
+   u   portrait up
+   l   landscape left
+   front/back status char:
+

Re: [PATCH v2] btrfs: explicitly set control file's private_data

2015-03-31 Thread Martin Kepplinger

Am 31.03.2015 14:31 schrieb Tom Van Braeckel:

Err, upon further inspection, I think that this was a false positive.

Btrfs relies on the initial value of the private_data member of a file
being NULL in the regular ioctl operation handler for
BTRFS_IOC_TRANS_START but it does not use the miscdevice framework for
those files.

It *does* use the miscdevice framework in the ioctl operation handler
of the /dev/btrfs-control file but there it does not use the file's
private_data member. So IMHO, the proposed patch is not necessary...


This is offtopic, assuming you are right and didn't find more affected 
places:


Then I would say you could re-post the real change (to misc_open() ) to 
the
relevant people for 4.2 (not 4.1), so either wait for 4.0 to be released 
or try
something like "for 4.2" in the topic (or as a comment after the --- 
dashes in

the patch email)

I would want to have it in -next for one cycle at least.

Further, I would remove the code-comment you had here
https://lkml.org/lkml/2015/1/9/718 because GregKH already pulled this in
(a little too early ;) :
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=03190c67ff72b5c56b24266762ab8abe68970f45
which is extractable kernel documenation. You could somehow link to it
in the commit message.

  martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] iio: doc: fix typo

2015-04-30 Thread Martin Kepplinger
Since we have deviceX, we don't need accelX. This has no users as of now, so
correcting this is no problem.

Signed-off-by: Martin Kepplinger 
---

That's really just a question now. If I'm wrong, sorry for the noise.

 Documentation/ABI/testing/sysfs-bus-iio | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 3befcb1..efd1334 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1119,7 +1119,7 @@ Description:
This attribute is used to read the amount of quadrature error
present in the device at a given time.
 
-What:  /sys/.../iio:deviceX/in_accelX_power_mode
+What:  /sys/.../iio:deviceX/in_accel_power_mode
 KernelVersion: 3.11
 Contact:   linux-...@vger.kernel.org
 Description:
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: iio: what does in_accel_x_thresh_rising_en ?

2015-06-11 Thread Martin Kepplinger
Am 2015-06-10 um 22:49 schrieb Jonathan Cameron:
> On 09/06/15 17:03, Martin Kepplinger wrote:
>> hi
>>
>> Is the in_accel_thresh_rising_value (or falling) threshold value signed
>> or unsigned?
>>
>> In other words: Is a RISING event fired on an absolute growing value in
>> the positive range, and a FALLING event on an absolute growing value in
>> the negative acceleration range (< 0g)?
>>
>> Or is a RISING event fired on a signed rising value, no matter if the
>> threshold is positive or negative, and a FALLING event on a decreasing
>> signed value, also when the threshold is positive?
>>
>> thanks
>>
>> martin
>>
> Hi Martin,
> 
> The two relevant abi elements are:
> in_accel_thresh_rising_value and
> in_accel_mag_rising_value
> Once you know the second one exists then you can probably work out the
> meaning of thresh ;)
> 
> Thresh is the value, mag(nitude) is the absolute value, so if you get one
> that is thresh, then if the channel can go negative, negative values are
> definitely possible.  On an accelerometer, you can get either implemented.
> mag_rising is typically to allow motion detection, thresh_rising might
> be used to detect a change of orientation (put bounds around each axis
> at a particular point in time.
> 
> There are also roc (rate of change) type event detectors on some 
> accelerometers.
> 
> Hope that clear the mud up ;)
> 
> Jonathan
> 

Hi Jonathan,

Oh I overlooked, this is clear now. So
events/in_accel_x&y&z_mag_falling_en for example is
a classic freefall detection. Would an implementation here just use
in_accel_mag_falling_value ? I'm not yet sure how an iio_event_spec
would look like in that case. Freefall is what I could do in my driver.

But this was very helpful, thanks for your time!

   martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] acer-wmi: update removal notice for sysfs interface

2015-06-16 Thread Martin Kepplinger
Signed-off-by: Martin Kepplinger 
---
These just look odd when out of date. The proper fix would probably be
to create a Documentation/ABI/testing/sysfs-platform-acer-wmi file and
remove the deprecated ones.


 drivers/platform/x86/acer-wmi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 3ac29a1..83c4850 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -1670,7 +1670,7 @@ static ssize_t show_bool_threeg(struct device *dev,
u32 result; \
acpi_status status;
 
-   pr_info("This threeg sysfs will be removed in 2014 - used by: %s\n",
+   pr_info("This threeg sysfs will be removed in 2015 - used by: %s\n",
current->comm);
status = get_u32(&result, ACER_CAP_THREEG);
if (ACPI_SUCCESS(status))
@@ -1683,7 +1683,7 @@ static ssize_t set_bool_threeg(struct device *dev,
 {
u32 tmp = simple_strtoul(buf, NULL, 10);
acpi_status status = set_u32(tmp, ACER_CAP_THREEG);
-   pr_info("This threeg sysfs will be removed in 2014 - used by: %s\n",
+   pr_info("This threeg sysfs will be removed in 2015 - used by: %s\n",
current->comm);
if (ACPI_FAILURE(status))
return -EINVAL;
@@ -1695,7 +1695,7 @@ static DEVICE_ATTR(threeg, S_IRUGO | S_IWUSR, 
show_bool_threeg,
 static ssize_t show_interface(struct device *dev, struct device_attribute 
*attr,
char *buf)
 {
-   pr_info("This interface sysfs will be removed in 2014 - used by: %s\n",
+   pr_info("This interface sysfs will be removed in 2015 - used by: %s\n",
current->comm);
switch (interface->type) {
case ACER_AMW0:
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


iio: what does in_accel_x_thresh_rising_en ?

2015-06-09 Thread Martin Kepplinger
hi

Is the in_accel_thresh_rising_value (or falling) threshold value signed
or unsigned?

In other words: Is a RISING event fired on an absolute growing value in
the positive range, and a FALLING event on an absolute growing value in
the negative acceleration range (< 0g)?

Or is a RISING event fired on a signed rising value, no matter if the
threshold is positive or negative, and a FALLING event on a decreasing
signed value, also when the threshold is positive?

thanks

martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/2] Input: st1232 - switch to gpiod API

2019-02-05 Thread Martin Kepplinger



Martin Kepplinger | Entwicklung Software 

GINZINGER ELECTRONIC SYSTEMS GMBH

Tel.: +43 7723 5422 157
Mail: martin.kepplin...@ginzinger.com
Web: www.ginzinger.com




On 29.01.19 11:23, Martin Kepplinger wrote:

From: Martin Kepplinger 

Use devm_gpiod_get_optional() and gpiod_set_value_cansleep() instead
of the old API. The st1232_ts_power() now passes on the inverted "poweron"
value to reflect the correct logical value.

Signed-off-by: Martin Kepplinger 
---

Tested and works. thanks for your help Dmitry,



is this what you had in mind? any problems or questions?

thanks
 martin






  drivers/input/touchscreen/st1232.c | 22 ++
  1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/input/touchscreen/st1232.c 
b/drivers/input/touchscreen/st1232.c
index 777df903605d..04d75b08be44 100644
--- a/drivers/input/touchscreen/st1232.c
+++ b/drivers/input/touchscreen/st1232.c
@@ -45,7 +45,7 @@ struct st1232_ts_data {
struct i2c_client *client;
struct input_dev *input_dev;
struct dev_pm_qos_request low_latency_req;
-   int reset_gpio;
+   struct gpio_desc *reset_gpio;
const struct st_chip_info *chip_info;
int read_buf_len;
u8 *read_buf;
@@ -142,8 +142,8 @@ static irqreturn_t st1232_ts_irq_handler(int irq, void 
*dev_id)
  
  static void st1232_ts_power(struct st1232_ts_data *ts, bool poweron)

  {
-   if (gpio_is_valid(ts->reset_gpio))
-   gpio_direction_output(ts->reset_gpio, poweron);
+   if (ts->reset_gpio)
+   gpiod_set_value_cansleep(ts->reset_gpio, !poweron);
  }
  
  static const struct st_chip_info st1232_chip_info = {

@@ -215,15 +215,13 @@ static int st1232_ts_probe(struct i2c_client *client,
ts->client = client;
ts->input_dev = input_dev;
  
-	ts->reset_gpio = of_get_gpio(client->dev.of_node, 0);

-   if (gpio_is_valid(ts->reset_gpio)) {
-   error = devm_gpio_request(&client->dev, ts->reset_gpio, NULL);
-   if (error) {
-   dev_err(&client->dev,
-   "Unable to request GPIO pin %d.\n",
-   ts->reset_gpio);
-   return error;
-   }
+   ts->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
+GPIOD_OUT_HIGH);
+   if (IS_ERR(ts->reset_gpio)) {
+   error = PTR_ERR(ts->reset_gpio);
+   dev_err(&client->dev, "Unable to request GPIO pin: %d.\n",
+   error);
+   return error;
}
  
  	st1232_ts_power(ts, true);









Ginzinger electronic systems GmbH
Gewerbegebiet Pirath 16
4952 Weng im Innkreis
www.ginzinger.com

Firmenbuchnummer: FN 364958d
Firmenbuchgericht: Ried im Innkreis
UID-Nr.: ATU66521089


Diese Nachricht ist vertraulich und darf nicht an andere Personen weitergegeben 
oder von diesen verwendet werden. Verständigen Sie uns, wenn Sie irrtümlich 
eine Mitteilung empfangen haben.

This message is confidential. It may not be disclosed to, or used by, anyone 
other than the addressee. If you receive this message by mistake, please advise 
the sender.


smime.p7s
Description: S/MIME cryptographic signature


Re: [PATCH] mtd: rawnand: gpmi: fix MX28 bus master lockup problem

2019-02-05 Thread Martin Kepplinger

On 05.02.19 16:22, Fabio Estevam wrote:

On Tue, Feb 5, 2019 at 11:00 AM Miquel Raynal  wrote:


Hi Martin,

Martin Kepplinger  wrote on Tue, 29 Jan 2019
16:37:00 +0100:


From: Martin Kepplinger 

Disable BCH soft reset according to MX23 erratum #2847 ("BCH soft
reset may cause bus master lock up") for MX28 too. It has the same
problem.

Observed problem: once per 100,000+ MX28 reboots NAND read failed on
DMA timeout errors:
[1.770823] UBI: attaching mtd3 to ubi0
[2.768088] gpmi_nand: DMA timeout, last DMA :1
[3.958087] gpmi_nand: BCH timeout, last DMA :1
[4.156033] gpmi_nand: Error in ECC-based read: -110
[4.161136] UBI warning: ubi_io_read: error -110 while reading 64
bytes from PEB 0:0, read only 0 bytes, retry
[4.171283] step 1 error
[4.173846] gpmi_nand: Chip: 0, Error -1

Without BCH soft reset we successfully executed 1,000,000 MX28 reboots.

I have a quote from NXP regarding this problem, from July 18th 2016:

"As the i.MX23 and i.MX28 are of the same generation, they share many
characteristics. Unfortunately, also the erratas may be shared.
In case of the documented erratas and the workarounds, you can also
apply the workaround solution of one device on the other one. This have
been reported, but I’m afraid that there are not an estimated date for
updating the Errata documents.
Please accept our apologies for any inconveniences this may cause."

Signed-off-by: Manfred Schlaegl 
Signed-off-by: Martin Kepplinger 


Does this also need a Fixes tag so that it can be backported to stable?



Actually I rebased this from our 4.14 stable tree, so yes, I just forgot 
about that and I guess it would be


Fixes: 6f2a6a52560a ("mtd: nand: gpmi: reset BCH earlier, too, to avoid 
NAND startup problems")


Do you want me to add this and CC stable?

thanks
  martin


smime.p7s
Description: S/MIME cryptographic signature


[PATCH v2] mtd: rawnand: gpmi: fix MX28 bus master lockup problem

2019-02-05 Thread Martin Kepplinger
Disable BCH soft reset according to MX23 erratum #2847 ("BCH soft
reset may cause bus master lock up") for MX28 too. It has the same
problem.

Observed problem: once per 100,000+ MX28 reboots NAND read failed on
DMA timeout errors:
[1.770823] UBI: attaching mtd3 to ubi0
[2.768088] gpmi_nand: DMA timeout, last DMA :1
[3.958087] gpmi_nand: BCH timeout, last DMA :1
[4.156033] gpmi_nand: Error in ECC-based read: -110
[4.161136] UBI warning: ubi_io_read: error -110 while reading 64
bytes from PEB 0:0, read only 0 bytes, retry
[4.171283] step 1 error
[4.173846] gpmi_nand: Chip: 0, Error -1

Without BCH soft reset we successfully executed 1,000,000 MX28 reboots.

I have a quote from NXP regarding this problem, from July 18th 2016:

"As the i.MX23 and i.MX28 are of the same generation, they share many
characteristics. Unfortunately, also the erratas may be shared.
In case of the documented erratas and the workarounds, you can also
apply the workaround solution of one device on the other one. This have
been reported, but I’m afraid that there are not an estimated date for
updating the Errata documents.
Please accept our apologies for any inconveniences this may cause."

Fixes: 6f2a6a52560a ("mtd: nand: gpmi: reset BCH earlier, too, to avoid
NAND startup problems")
Cc: sta...@vger.kernel.org
Signed-off-by: Manfred Schlaegl 
Signed-off-by: Martin Kepplinger 
Reviewed-by: Miquel Raynal 
Reviewed-by: Fabio Estevam 
---


revision history

v2: add Fixes tag, Cc stable and add recent Reviewed-by tags


 drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c 
b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
index bd4cfac6b5aa..a4768df5083f 100644
--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
@@ -155,9 +155,10 @@ int gpmi_init(struct gpmi_nand_data *this)
 
/*
 * Reset BCH here, too. We got failures otherwise :(
-* See later BCH reset for explanation of MX23 handling
+* See later BCH reset for explanation of MX23 and MX28 handling
 */
-   ret = gpmi_reset_block(r->bch_regs, GPMI_IS_MX23(this));
+   ret = gpmi_reset_block(r->bch_regs,
+  GPMI_IS_MX23(this) || GPMI_IS_MX28(this));
if (ret)
goto err_out;
 
@@ -263,12 +264,10 @@ int bch_set_geometry(struct gpmi_nand_data *this)
/*
* Due to erratum #2847 of the MX23, the BCH cannot be soft reset on this
* chip, otherwise it will lock up. So we skip resetting BCH on the MX23.
-   * On the other hand, the MX28 needs the reset, because one case has been
-   * seen where the BCH produced ECC errors constantly after 1
-   * consecutive reboots. The latter case has not been seen on the MX23
-   * yet, still we don't know if it could happen there as well.
+   * and MX28.
*/
-   ret = gpmi_reset_block(r->bch_regs, GPMI_IS_MX23(this));
+   ret = gpmi_reset_block(r->bch_regs,
+  GPMI_IS_MX23(this) || GPMI_IS_MX28(this));
if (ret)
goto err_out;
 
-- 
2.20.1



smime.p7s
Description: S/MIME cryptographic signature


[PATCH] fbdev: mxsfb: implement FB_PRE_INIT_FB option

2019-02-06 Thread Martin Kepplinger
From: Melchior Franz 

The FB_PRE_INIT_FB option keeps the kernel from reinitializing the display
and prevents flickering during the transition from a bootloader splash
screen to the kernel logo screen.

Make this option available for the mxsfb driver.

Signed-off-by: Melchior Franz 
Signed-off-by: Martin Kepplinger 
Signed-off-by: Manfred Schlaegl 
---
 drivers/video/fbdev/Kconfig |  2 +-
 drivers/video/fbdev/mxsfb.c | 12 
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 58a9590c9db6..0e7ab29c9c70 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2183,7 +2183,7 @@ config FB_EP93XX
 
 config FB_PRE_INIT_FB
bool "Don't reinitialize, use bootloader's GDC/Display configuration"
-   depends on FB && FB_MB862XX_LIME
+   depends on FB && (FB_MB862XX_LIME || FB_MXS)
---help---
  Select this option if display contents should be inherited as set by
  the bootloader.
diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
index 12c8bd1d24d5..a017200a16b3 100644
--- a/drivers/video/fbdev/mxsfb.c
+++ b/drivers/video/fbdev/mxsfb.c
@@ -181,6 +181,7 @@ struct mxsfb_info {
const struct mxsfb_devdata *devdata;
u32 sync;
struct regulator *reg_lcd;
+   int pre_init;
 };
 
 #define mxsfb_is_v3(host) (host->devdata->ipversion == 3)
@@ -419,6 +420,12 @@ static int mxsfb_set_par(struct fb_info *fb_info)
 
fb_info->fix.line_length = line_size;
 
+   if (host->pre_init) {
+   mxsfb_enable_controller(fb_info);
+   host->pre_init = 0;
+   return 0;
+   }
+
/*
 * It seems, you can't re-program the controller if it is still running.
 * This may lead into shifted pictures (FIFO issue?).
@@ -931,6 +938,10 @@ static int mxsfb_probe(struct platform_device *pdev)
if (IS_ERR(host->reg_lcd))
host->reg_lcd = NULL;
 
+#if defined(CONFIG_FB_PRE_INIT_FB)
+   host->pre_init = 1;
+#endif
+
fb_info->pseudo_palette = devm_kcalloc(&pdev->dev, 16, sizeof(u32),
   GFP_KERNEL);
if (!fb_info->pseudo_palette) {
@@ -963,6 +974,7 @@ static int mxsfb_probe(struct platform_device *pdev)
mxsfb_enable_controller(fb_info);
}
 
+   host->pre_init = 0;
dev_info(&pdev->dev, "initialized\n");
 
return 0;
-- 
2.20.1



smime.p7s
Description: S/MIME cryptographic signature


  1   2   3   4   5   6   7   8   >