| Message ID | 20240318203923.183943-1-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net-next,v1,1/1] nfc: st95hf: Switch to using gpiod API | expand |
Mon, Mar 18, 2024 at 09:39:23PM CET, andriy.shevchenko@linux.intel.com wrote: >This updates the driver to gpiod API, and removes yet another use of >of_get_named_gpio(). > >Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> net-next is closed, send again next week.
On Tue, Mar 19, 2024 at 11:25:34AM +0100, Jiri Pirko wrote: > Mon, Mar 18, 2024 at 09:39:23PM CET, andriy.shevchenko@linux.intel.com wrote: > >This updates the driver to gpiod API, and removes yet another use of > >of_get_named_gpio(). > > > net-next is closed, send again next week. Same Q: Why to resend? Can't you utilise lore.kernel.org?
On Wed, Mar 20, 2024 at 12:27:37PM +0200, Andy Shevchenko wrote: > On Tue, Mar 19, 2024 at 11:25:34AM +0100, Jiri Pirko wrote: > > Mon, Mar 18, 2024 at 09:39:23PM CET, andriy.shevchenko@linux.intel.com wrote: > > >This updates the driver to gpiod API, and removes yet another use of > > >of_get_named_gpio(). > > > > > net-next is closed, send again next week. > > Same Q: Why to resend? Can't you utilise lore.kernel.org? Because that is how Netdev development currently operates. A system which I believe emerged as a way to handle the enormous volume of patches involved. Maybe it could change, but that is a different conversation. Other subsystems work differently, and that is fine too. https://docs.kernel.org/process/maintainer-netdev.html#git-trees-and-patch-flow
On Wed, Mar 20, 2024 at 11:12:58AM +0000, Simon Horman wrote: > On Wed, Mar 20, 2024 at 12:27:37PM +0200, Andy Shevchenko wrote: > > On Tue, Mar 19, 2024 at 11:25:34AM +0100, Jiri Pirko wrote: > > > Mon, Mar 18, 2024 at 09:39:23PM CET, andriy.shevchenko@linux.intel.com wrote: > > > >This updates the driver to gpiod API, and removes yet another use of > > > >of_get_named_gpio(). > > > > > > > net-next is closed, send again next week. > > > > Same Q: Why to resend? Can't you utilise lore.kernel.org? > > Because that is how Netdev development currently operates. > A system which I believe emerged as a way to handle the > enormous volume of patches involved. Maybe it could change, > but that is a different conversation. > > Other subsystems work differently, and that is fine too. > > https://docs.kernel.org/process/maintainer-netdev.html#git-trees-and-patch-flow I see that this is the limitation of patchwork and/or nobody wants to "reopen" the patch based on Message-ID. Still I believe it's possible to make it smarter. In any case, I'll resend the patch(es) and try to keep in mind, that during merge window net is a black hole (astronomically speaking).
diff --git a/drivers/nfc/st95hf/core.c b/drivers/nfc/st95hf/core.c index ed704bb77226..067e0ec31d2d 100644 --- a/drivers/nfc/st95hf/core.c +++ b/drivers/nfc/st95hf/core.c @@ -7,14 +7,13 @@ */ #include <linux/err.h> -#include <linux/gpio.h> +#include <linux/gpio/consumer.h> #include <linux/init.h> #include <linux/interrupt.h> #include <linux/irq.h> #include <linux/module.h> #include <linux/netdevice.h> #include <linux/nfc.h> -#include <linux/of_gpio.h> #include <linux/of.h> #include <linux/property.h> #include <linux/regulator/consumer.h> @@ -196,7 +195,7 @@ struct st95_digital_cmd_complete_arg { * for spi communication between st95hf and host. * @ddev: nfc digital device object. * @nfcdev: nfc device object. - * @enable_gpio: gpio used to enable st95hf transceiver. + * @enable_gpiod: gpio used to enable st95hf transceiver. * @complete_cb_arg: structure to store various context information * that is passed from nfc requesting thread to the threaded ISR. * @st95hf_supply: regulator "consumer" for NFC device. @@ -219,7 +218,7 @@ struct st95hf_context { struct st95hf_spi_context spicontext; struct nfc_digital_dev *ddev; struct nfc_dev *nfcdev; - unsigned int enable_gpio; + struct gpio_desc *enable_gpiod; struct st95_digital_cmd_complete_arg complete_cb_arg; struct regulator *st95hf_supply; unsigned char sendrcv_trflag; @@ -451,19 +450,19 @@ static int st95hf_select_protocol(struct st95hf_context *stcontext, int type) static void st95hf_send_st95enable_negativepulse(struct st95hf_context *st95con) { /* First make irq_in pin high */ - gpio_set_value(st95con->enable_gpio, HIGH); + gpiod_set_value(st95con->enable_gpiod, HIGH); /* wait for 1 milisecond */ usleep_range(1000, 2000); /* Make irq_in pin low */ - gpio_set_value(st95con->enable_gpio, LOW); + gpiod_set_value(st95con->enable_gpiod, LOW); /* wait for minimum interrupt pulse to make st95 active */ usleep_range(1000, 2000); /* At end make it high */ - gpio_set_value(st95con->enable_gpio, HIGH); + gpiod_set_value(st95con->enable_gpiod, HIGH); } /* @@ -1063,6 +1062,7 @@ MODULE_DEVICE_TABLE(of, st95hf_spi_of_match); static int st95hf_probe(struct spi_device *nfc_spi_dev) { + struct device *dev = &nfc_spi_dev->dev; int ret; struct st95hf_context *st95context; @@ -1108,19 +1108,14 @@ static int st95hf_probe(struct spi_device *nfc_spi_dev) */ dev_set_drvdata(&nfc_spi_dev->dev, spicontext); - st95context->enable_gpio = - of_get_named_gpio(nfc_spi_dev->dev.of_node, - "enable-gpio", - 0); - if (!gpio_is_valid(st95context->enable_gpio)) { + st95context->enable_gpiod = devm_gpiod_get(dev, "enable", GPIOD_OUT_HIGH); + if (IS_ERR(st95context->enable_gpiod)) { + ret = PTR_ERR(st95context->enable_gpiod); dev_err(&nfc_spi_dev->dev, "No valid enable gpio\n"); - ret = st95context->enable_gpio; goto err_disable_regulator; } - ret = devm_gpio_request_one(&nfc_spi_dev->dev, st95context->enable_gpio, - GPIOF_DIR_OUT | GPIOF_INIT_HIGH, - "enable_gpio"); + ret = gpiod_set_consumer_name(st95context->enable_gpiod, "enable_gpio"); if (ret) goto err_disable_regulator;
This updates the driver to gpiod API, and removes yet another use of of_get_named_gpio(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> --- drivers/nfc/st95hf/core.c | 27 +++++++++++---------------- 1 file changed, 11 insertions(+), 16 deletions(-)