Re: [PATCH 2/2] rtc: add hym8563 rtc-driver
Am Montag, 25. November 2013, 13:01:25 schrieb Mark Rutland:
> [...]
>
> > +static int hym8563_probe(struct i2c_client *client,
> > +const struct i2c_device_id *id)
> > +{
> > + struct hym8563 *hym8563;
> > + int ret, gpio_int;
> > +
> > + hym8563 = devm_kzalloc(>dev, sizeof(hym8563),
> > GFP_KERNEL); + if (!hym8563)
> > + return -ENOMEM;
> > +
> > + hym8563->client = client;
> > + i2c_set_clientdata(client, hym8563);
> > +
> > + device_set_wakeup_capable(>dev, true);
> > +
> > + gpio_int = of_get_gpio(client->dev.of_node, 0);
> > + if (!gpio_is_valid(gpio_int)) {
> > + dev_err(>dev, "failed to get interrupt gpio\n");
> > + return -EINVAL;
> > + }
> > +
> > + ret = devm_gpio_request_one(>dev, gpio_int,
> > + GPIOF_DIR_IN, "hym8563_int");
> > + if (ret) {
> > + dev_err(>dev, "request of gpio %d failed, %d\n",
> > + gpio_int, ret);
> > + return ret;
> > + }
>
> From here on the gpio is never used or even stashed away anywhere.
> What's the point in requesting it and then leaking it?
As I understand it, requesting gpio also is useful as a mechanism to mark them
as used and therefore prevent a gpio from wrongly being used multiple times.
So, I guess it would be better to either ignore client->irq and just use
gpio_to_irq or use client->irq alone, without the gpio-functions at all.
But what would be preferrable?
--
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] rtc: add hym8563 rtc-driver
[...]
> +static int hym8563_probe(struct i2c_client *client,
> +const struct i2c_device_id *id)
> +{
> + struct hym8563 *hym8563;
> + int ret, gpio_int;
> +
> + hym8563 = devm_kzalloc(>dev, sizeof(hym8563), GFP_KERNEL);
> + if (!hym8563)
> + return -ENOMEM;
> +
> + hym8563->client = client;
> + i2c_set_clientdata(client, hym8563);
> +
> + device_set_wakeup_capable(>dev, true);
> +
> + gpio_int = of_get_gpio(client->dev.of_node, 0);
> + if (!gpio_is_valid(gpio_int)) {
> + dev_err(>dev, "failed to get interrupt gpio\n");
> + return -EINVAL;
> + }
> +
> + ret = devm_gpio_request_one(>dev, gpio_int,
> + GPIOF_DIR_IN, "hym8563_int");
> + if (ret) {
> + dev_err(>dev, "request of gpio %d failed, %d\n",
> + gpio_int, ret);
> + return ret;
> + }
>From here on the gpio is never used or even stashed away anywhere.
What's the point in requesting it and then leaking it?
Thanks,
Mark.
--
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] rtc: add hym8563 rtc-driver
[...]
+static int hym8563_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ struct hym8563 *hym8563;
+ int ret, gpio_int;
+
+ hym8563 = devm_kzalloc(client-dev, sizeof(hym8563), GFP_KERNEL);
+ if (!hym8563)
+ return -ENOMEM;
+
+ hym8563-client = client;
+ i2c_set_clientdata(client, hym8563);
+
+ device_set_wakeup_capable(client-dev, true);
+
+ gpio_int = of_get_gpio(client-dev.of_node, 0);
+ if (!gpio_is_valid(gpio_int)) {
+ dev_err(client-dev, failed to get interrupt gpio\n);
+ return -EINVAL;
+ }
+
+ ret = devm_gpio_request_one(client-dev, gpio_int,
+ GPIOF_DIR_IN, hym8563_int);
+ if (ret) {
+ dev_err(client-dev, request of gpio %d failed, %d\n,
+ gpio_int, ret);
+ return ret;
+ }
From here on the gpio is never used or even stashed away anywhere.
What's the point in requesting it and then leaking it?
Thanks,
Mark.
--
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] rtc: add hym8563 rtc-driver
Am Montag, 25. November 2013, 13:01:25 schrieb Mark Rutland:
[...]
+static int hym8563_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ struct hym8563 *hym8563;
+ int ret, gpio_int;
+
+ hym8563 = devm_kzalloc(client-dev, sizeof(hym8563),
GFP_KERNEL); + if (!hym8563)
+ return -ENOMEM;
+
+ hym8563-client = client;
+ i2c_set_clientdata(client, hym8563);
+
+ device_set_wakeup_capable(client-dev, true);
+
+ gpio_int = of_get_gpio(client-dev.of_node, 0);
+ if (!gpio_is_valid(gpio_int)) {
+ dev_err(client-dev, failed to get interrupt gpio\n);
+ return -EINVAL;
+ }
+
+ ret = devm_gpio_request_one(client-dev, gpio_int,
+ GPIOF_DIR_IN, hym8563_int);
+ if (ret) {
+ dev_err(client-dev, request of gpio %d failed, %d\n,
+ gpio_int, ret);
+ return ret;
+ }
From here on the gpio is never used or even stashed away anywhere.
What's the point in requesting it and then leaking it?
As I understand it, requesting gpio also is useful as a mechanism to mark them
as used and therefore prevent a gpio from wrongly being used multiple times.
So, I guess it would be better to either ignore client-irq and just use
gpio_to_irq or use client-irq alone, without the gpio-functions at all.
But what would be preferrable?
--
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/
