This updates the driver to gpiod API, and removes yet another use of
of_get_named_gpio().
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/nfc/st95hf/core.c | 27 +++++++++++----------------
1 file changed, 11 insertions(+), 16 deletions(-)
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;
--
2.43.0.rc1.1.gbec44491f096
Mon, Mar 18, 2024 at 09:39:23PM CET, [email protected] wrote:
>This updates the driver to gpiod API, and removes yet another use of
>of_get_named_gpio().
>
>Signed-off-by: Andy Shevchenko <[email protected]>
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, [email protected] 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?
--
With Best Regards,
Andy Shevchenko
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, [email protected] 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, [email protected] 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).
--
With Best Regards,
Andy Shevchenko