From: Guenter Roeck <linux@roeck-us.net>
To: Jamie Lentin <jm@lentin.co.uk>
Cc: Andrew Lunn <andrew@lunn.ch>, Jason Cooper <jason@lakedaemon.net>,
devicetree-discuss@lists.ozlabs.org,
Rob Herring <rob.herring@calxeda.com>,
Grant Likely <grant.likely@secretlab.ca>,
Jean Delvare <khali@linux-fr.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] hwmon: Add devicetree bindings to gpio-fan
Date: Fri, 7 Sep 2012 11:36:04 -0700 [thread overview]
Message-ID: <20120907183604.GA26986@roeck-us.net> (raw)
In-Reply-To: <1347035675-23907-2-git-send-email-jm@lentin.co.uk>
On Fri, Sep 07, 2012 at 05:34:34PM +0100, Jamie Lentin wrote:
> Allow a gpio-fan to be defined in devicetree, see binding documentation
> for details.
>
> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
> ---
> .../devicetree/bindings/gpio/gpio-fan.txt | 25 +++++
> drivers/hwmon/gpio-fan.c | 111 ++++++++++++++++++++
> 2 files changed, 136 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-fan.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-fan.txt b/Documentation/devicetree/bindings/gpio/gpio-fan.txt
> new file mode 100644
> index 0000000..2dd457a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-fan.txt
> @@ -0,0 +1,25 @@
> +Bindings for fan connected to GPIO lines
> +
> +Required properties:
> +- compatible : "gpio-fan"
> +- gpios: Specifies the pins that map to bits in the control value,
> + ordered MSB-->LSB.
> +- gpio-fan,speed-map: A mapping of possible fan RPM speeds and the
> + control value that should be set to achieve them. This array
> + must have the RPM values in ascending order.
> +
> +Optional properties:
> +- alarm-gpios: This pin going active indicates something is wrong with
> + the fan, and a udev event will be fired.
> +
> +Examples:
> +
> + gpio_fan {
> + compatible = "gpio-fan";
> + gpios = <&gpio1 14 1
> + &gpio1 13 1>;
> + gpio-fan,speed-map = <0 0
> + 3000 1
> + 6000 2>;
> + alarm-gpios = <&gpio1 15 1>;
> + };
> diff --git a/drivers/hwmon/gpio-fan.c b/drivers/hwmon/gpio-fan.c
> index 2f4b01b..876ce41 100644
> --- a/drivers/hwmon/gpio-fan.c
> +++ b/drivers/hwmon/gpio-fan.c
> @@ -31,6 +31,8 @@
> #include <linux/hwmon.h>
> #include <linux/gpio.h>
> #include <linux/gpio-fan.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_gpio.h>
>
> struct gpio_fan_data {
> struct platform_device *pdev;
> @@ -400,12 +402,120 @@ static ssize_t show_name(struct device *dev,
>
> static DEVICE_ATTR(name, S_IRUGO, show_name, NULL);
>
> +
> +#ifdef CONFIG_OF
> +/*
> + * Translate OpenFirmware node properties into platform_data
> + */
> +static int gpio_fan_get_of_pdata(struct device *dev,
> + struct gpio_fan_platform_data *pdata)
> +{
> + struct device_node *node;
> + struct gpio_fan_speed *speed;
> + unsigned *ctrl;
> + unsigned i;
> + u32 u;
> + struct property *prop;
> + const __be32 *p;
> +
> + node = dev->of_node;
> +
> + /* Fill GPIO pin array */
> + pdata->num_ctrl = of_gpio_count(node);
> + ctrl = devm_kzalloc(dev, pdata->num_ctrl * sizeof(unsigned),
> + GFP_KERNEL);
> + if (!ctrl)
> + return -ENOMEM;
> + for (i = 0; i < of_gpio_count(node); i++) {
> + int val;
> +
> + val = of_get_gpio(node, i);
> + if (val >= 0)
> + ctrl[i] = val;
> + else
> + return -EINVAL;
I very much prefer not to hide the error code and reverse the logic.
if (val < 0)
return val;
ctrl[i] = val;
> + }
> + pdata->ctrl = ctrl;
> +
> + /* Get speed map array size */
> + i = 0;
> + of_property_for_each_u32(node, "gpio-fan,speed-map", prop, p, u)
> + i++;
Looking through the of code, isn't there a function which returns the
number of elements ?
Something like
int length;
struct property *prop;
prop = of_find_property(node, "gpio-fan,speed-map", &length);
> + if (i & 1) {
> + dev_err(dev, "gpio-fan,speed-map contains odd number of entries");
> + return -ENODEV;
> + }
How about i == 0 ?
> + pdata->num_speed = i >> 1;
> + speed = devm_kzalloc(dev,
> + pdata->num_speed * sizeof(struct gpio_fan_speed),
> + GFP_KERNEL);
> + if (!speed)
> + return -ENOMEM;
> +
> + /* Populate speed map */
> + i = 0;
> + of_property_for_each_u32(node, "gpio-fan,speed-map", prop, p, u) {
> + if (i & 1)
> + speed[i >> 1].ctrl_val = (int)u;
> + else
> + speed[i >> 1].rpm = (int)u;
Are those type casts necessary ?
> + i++;
> + }
> + pdata->speed = speed;
> +
> + /* Alarm GPIO if one exists */
> + if (of_gpio_named_count(node, "alarm-gpios")) {
> + struct gpio_fan_alarm *alarm;
> + int val;
> + enum of_gpio_flags flags;
> +
> + alarm = devm_kzalloc(dev, sizeof(struct gpio_fan_alarm),
> + GFP_KERNEL);
> + if (!alarm)
> + return -ENOMEM;
> +
> + val = of_get_named_gpio_flags(node, "alarm-gpios", 0, &flags);
> + if (val >= 0) {
> + alarm->gpio = val;
> + alarm->active_low = flags & OF_GPIO_ACTIVE_LOW;
> + } else
> + return -EINVAL;
> +
How about
if (val < 0)
return val;
alarm->gpio = val;
alarm->active_low = flags & OF_GPIO_ACTIVE_LOW;
> + pdata->alarm = alarm;
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id of_gpio_fan_match[] = {
> + { .compatible = "gpio-fan", },
> + {},
> +};
> +#endif /* CONFIG_OF_GPIO */
> +
> static int __devinit gpio_fan_probe(struct platform_device *pdev)
> {
> int err;
> struct gpio_fan_data *fan_data;
> struct gpio_fan_platform_data *pdata = pdev->dev.platform_data;
>
> +#ifdef CONFIG_OF
> + if (!pdata) {
> + struct gpio_fan_platform_data *alt_pdata;
> +
Why not just use pdata ? I don't really see a reason for introducing
a second variable. After all, we know here that pdata is NULL, and that it won't
be used.
> + alt_pdata = devm_kzalloc(&pdev->dev,
> + sizeof(struct gpio_fan_platform_data),
> + GFP_KERNEL);
> + if (!alt_pdata)
> + return -ENOMEM;
> +
> + err = gpio_fan_get_of_pdata(&pdev->dev, alt_pdata);
> + if (err)
> + return err;
> + pdata = alt_pdata;
> + }
> +#endif /* CONFIG_OF_GPIO */
> +
> if (!pdata)
> return -EINVAL;
#else case, maybe ?
>
> @@ -511,6 +621,7 @@ static struct platform_driver gpio_fan_driver = {
> .driver = {
> .name = "gpio-fan",
> .pm = GPIO_FAN_PM,
> + .of_match_table = of_match_ptr(of_gpio_fan_match),
> },
> };
>
> --
> 1.7.10.4
>
>
next prev parent reply other threads:[~2012-09-07 18:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-07 16:34 [PATCH 0/2] hwmon: kirkwood: Add DT bindings to gpio-fan for DNS-32[05] Jamie Lentin
2012-09-07 16:34 ` [PATCH 1/2] hwmon: Add devicetree bindings to gpio-fan Jamie Lentin
2012-09-07 18:36 ` Guenter Roeck [this message]
[not found] ` <1347035675-23907-2-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2012-09-08 7:32 ` Andrew Lunn
2012-09-07 16:34 ` [PATCH 2/2] ARM: kirkwood: Use devicetree to define DNS-32[05] fan Jamie Lentin
[not found] ` <1347035675-23907-3-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2012-09-07 21:23 ` Andrew Lunn
[not found] ` <1347035675-23907-1-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2012-09-10 13:51 ` [PATCH V2 0/2] hwmon: kirkwood: Add DT bindings to gpio-fan for DNS-32[05] Jamie Lentin
[not found] ` <1347285112-13542-1-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2012-09-10 13:51 ` [PATCH V2 1/2] hwmon: Add devicetree bindings to gpio-fan Jamie Lentin
[not found] ` <1347285112-13542-2-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2012-09-10 15:28 ` Andrew Lunn
[not found] ` <20120910152814.GA6050-g2DYL2Zd6BY@public.gmane.org>
2012-09-10 16:04 ` Jamie Lentin
[not found] ` <alpine.DEB.2.00.1209101656120.10589-5X291BYdrx55rAo4AelP/Ydd74u8MsAO@public.gmane.org>
2012-09-10 18:15 ` Jason Cooper
2012-09-10 18:49 ` Guenter Roeck
[not found] ` <20120910184919.GA30872-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2012-09-14 16:07 ` [PATCH V3 " Jamie Lentin
2012-09-15 2:28 ` Guenter Roeck
[not found] ` <20120915022833.GA20375-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2012-09-15 3:16 ` Jason Cooper
2012-09-10 13:51 ` [PATCH V2 2/2] ARM: kirkwood: Use devicetree to define DNS-32[05] fan Jamie Lentin
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=20120907183604.GA26986@roeck-us.net \
--to=linux@roeck-us.net \
--cc=andrew@lunn.ch \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=jason@lakedaemon.net \
--cc=jm@lentin.co.uk \
--cc=khali@linux-fr.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=rob.herring@calxeda.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).