public inbox for kernel-janitors@vger.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: kernel-janitors@vger.kernel.org
Subject: Re: mfd: Support 88pm80x in 80x driver
Date: Mon, 18 May 2015 09:23:04 +0000	[thread overview]
Message-ID: <20150518092304.GO22418@x1> (raw)
In-Reply-To: <20150514103124.GA21248@mwanda>

On Fri, 15 May 2015, Qiao Zhou wrote:

> On 05/14/2015 08:50 PM, Lee Jones wrote:
> >On Thu, 14 May 2015, Qiao Zhou wrote:
> >
> >>On 05/14/2015 06:31 PM, Dan Carpenter wrote:
> >>>Hello Qiao Zhou,
> >>>
> >>>The patch 70c6cce04066: "mfd: Support 88pm80x in 80x driver" from Jul
> >>>9, 2012, leads to the following static checker warning:
> >>>
> >>>	include/linux/mfd/88pm80x.h:352 pm80x_dev_suspend()
> >>>	warn: test_bit() takes a bit number
> >>>
> >>>include/linux/mfd/88pm80x.h
> >>>    344  #ifdef CONFIG_PM
> >>>    345  static inline int pm80x_dev_suspend(struct device *dev)
> >>>    346  {
> >>>    347          struct platform_device *pdev = to_platform_device(dev);
> >>>    348          struct pm80x_chip *chip = dev_get_drvdata(pdev->dev.parent);
> >>>    349          int irq = platform_get_irq(pdev, 0);
> >>>    350
> >>>    351          if (device_may_wakeup(dev))
> >>>    352                  set_bit((1 << irq), &chip->wu_flag);
> >>>                                 ^^^^^^^^^
> >>>Smatch is complaining because it's doing a double left shift.  If irq is
> >>>larger than 5 then we are corrupting memory.  Also we don't use
> >>Will fix this issue.
> >>>->wu_flag as a bitfield, we use it as a boolean so the name is
> >>>confusing.
> >>>
> >>>    353
> >>>    354          return 0;
> >>>    355  }
> >>>    356
> >>>    357  static inline int pm80x_dev_resume(struct device *dev)
> >>>    358  {
> >>>    359          struct platform_device *pdev = to_platform_device(dev);
> >>>    360          struct pm80x_chip *chip = dev_get_drvdata(pdev->dev.parent);
> >>>    361          int irq = platform_get_irq(pdev, 0);
> >>>    362
> >>>    363          if (device_may_wakeup(dev))
> >>>    364                  clear_bit((1 << irq), &chip->wu_flag);
> >>>                                   ^^^^^^^^^^
> >>>Same issue.
> >>>
> >>>    365
> >>>    366          return 0;
> >>>    367  }
> >>>    368  #endif
> >>>
> >>>drivers/mfd/88pm80x.c
> >>>    133  #ifdef CONFIG_PM_SLEEP
> >>>    134  static int pm80x_suspend(struct device *dev)
> >>>    135  {
> >>>    136          struct i2c_client *client = container_of(dev, struct i2c_client, dev);
> >>>    137          struct pm80x_chip *chip = i2c_get_clientdata(client);
> >>>    138
> >>>    139          if (chip && chip->wu_flag)
> >>>                             ^^^^^^^^^^^^^
> >>>Here it is used as a bool.
> >>It's designed in this way that sub device driver may use this flag.
> >>Also the bit value can tell which sub device sets the flag. However
> >>here we just check whether any bit is set.
> >>>
> >>>    140                  if (device_may_wakeup(chip->dev))
> >>>    141                          enable_irq_wake(chip->irq);
> >>>    142
> >>>    143          return 0;
> >>>    144  }
> >>>    145
> >>>    146  static int pm80x_resume(struct device *dev)
> >>>    147  {
> >>>    148          struct i2c_client *client = container_of(dev, struct i2c_client, dev);
> >>>    149          struct pm80x_chip *chip = i2c_get_clientdata(client);
> >>>    150
> >>>    151          if (chip && chip->wu_flag)
> >>>                             ^^^^^^^^^^^^^
> >>>This is the only other user.
> >>>
> >>>    152                  if (device_may_wakeup(chip->dev))
> >>>    153                          disable_irq_wake(chip->irq);
> >>>    154
> >>>    155          return 0;
> >>>    156  }
> >>>    157  #endif
> >>>
> >>>
> >>>regards,
> >>>dan carpenter
> >>>
> >>Dan,
> >>
> >>Below is the patch to fix this issue. Please have a check and I'll
> >>submit an official patch to community after you reviewed. Thanks for
> >>finding this issue.
> >>
> >> From 96486fda25414e3b926c275b951ac1408fae7830 Mon Sep 17 00:00:00 2001
> >>From: Qiao Zhou <zhouqiao@marvell.com>
> >>Date: Thu, 14 May 2015 19:00:39 +0800
> >>Subject: [PATCH] mfd: 88pm80x: refine irq bit operation
> >>
> >>Set_bit/clear_bit for wu_flag may be corrupted if irq > 5(or 6 for
> >>aarch64). The maximum irq number from 88pm80x chip series is 24.
> >>Here we refine the code to protect the potential memory corruption.
> >>
> >>Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> >>Signed-off-by: Qiao Zhou <zhouqiao@marvell.com>
> >>---
> >>  include/linux/mfd/88pm80x.h |   16 ++++++++++++++--
> >>  1 file changed, 14 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
> >>index 97cb283..a8c0318 100644
> >>--- a/include/linux/mfd/88pm80x.h
> >>+++ b/include/linux/mfd/88pm80x.h

[...]

> >>  	if (device_may_wakeup(dev))
> >>-		set_bit((1 << irq), &chip->wu_flag);
> >>+		set_bit(irq, &chip->wu_flag);
> >
> >Can you come up with a better name?
> It's short for wakeup flag. I may change it to wakeup_flag. Do you
> have any suggestion if it's not okay?

bool wakeup; will be fine.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2015-05-18  9:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-14 10:31 mfd: Support 88pm80x in 80x driver Dan Carpenter
2015-05-14 11:35 ` Qiao Zhou
2015-05-14 12:50 ` Lee Jones
2015-05-15  1:06 ` Qiao Zhou
2015-05-15  8:23 ` Dan Carpenter
2015-05-18  9:23 ` Lee Jones [this message]
2015-05-18  9:27 ` Lee Jones
2015-06-05  2:17 ` zhouqiao
2015-06-05  7:27 ` Lee Jones
2015-06-05  7:49 ` zhouqiao

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20150518092304.GO22418@x1 \
    --to=lee.jones@linaro.org \
    --cc=kernel-janitors@vger.kernel.org \
    /path/to/YOUR_REPLY

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

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