[PATCH net-next] nfc: st95hf: switch to using sleeping variants of gpiod API

Dmitry Torokhov posted 1 patch 1 year, 5 months ago
drivers/nfc/st95hf/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
[PATCH net-next] nfc: st95hf: switch to using sleeping variants of gpiod API
Posted by Dmitry Torokhov 1 year, 5 months ago
The driver does not not use gpiod API calls in an atomic context. Switch
to gpiod_set_value_cansleep() calls to allow using the driver with GPIO
controllers that might need process context to operate.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/nfc/st95hf/core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/nfc/st95hf/core.c b/drivers/nfc/st95hf/core.c
index ffe5b4eab457..5b3451fc4491 100644
--- a/drivers/nfc/st95hf/core.c
+++ b/drivers/nfc/st95hf/core.c
@@ -450,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 */
-	gpiod_set_value(st95con->enable_gpiod, HIGH);
+	gpiod_set_value_cansleep(st95con->enable_gpiod, HIGH);
 
 	/* wait for 1 milisecond */
 	usleep_range(1000, 2000);
 
 	/* Make irq_in pin low */
-	gpiod_set_value(st95con->enable_gpiod, LOW);
+	gpiod_set_value_cansleep(st95con->enable_gpiod, LOW);
 
 	/* wait for minimum interrupt pulse to make st95 active */
 	usleep_range(1000, 2000);
 
 	/* At end make it high */
-	gpiod_set_value(st95con->enable_gpiod, HIGH);
+	gpiod_set_value_cansleep(st95con->enable_gpiod, HIGH);
 }
 
 /*
-- 
2.46.0.184.g6999bdac58-goog


-- 
Dmitry
Re: [PATCH net-next] nfc: st95hf: switch to using sleeping variants of gpiod API
Posted by Jakub Kicinski 1 year, 5 months ago
On Mon, 19 Aug 2024 18:10:32 -0700 Dmitry Torokhov wrote:
> The driver does not not use gpiod API calls in an atomic context. Switch
> to gpiod_set_value_cansleep() calls to allow using the driver with GPIO
> controllers that might need process context to operate.

Could you explain why? Are you using this device? Is it part of some
larger effort to remove an API?
Re: [PATCH net-next] nfc: st95hf: switch to using sleeping variants of gpiod API
Posted by Dmitry Torokhov 1 year, 5 months ago
On Tue, Aug 20, 2024 at 08:26:14AM -0700, Jakub Kicinski wrote:
> On Mon, 19 Aug 2024 18:10:32 -0700 Dmitry Torokhov wrote:
> > The driver does not not use gpiod API calls in an atomic context. Switch
> > to gpiod_set_value_cansleep() calls to allow using the driver with GPIO
> > controllers that might need process context to operate.
> 
> Could you explain why? Are you using this device? Is it part of some
> larger effort to remove an API?

Because it is better to use sleeping variants of gpiod API unless the
call is in atomic context, so it is basic code hygiene. We do not want
other drivers to copy the behavior.

I was going through my WIP patches and decided to sent it out. Originally
it was part of overall transition of the driver to gpiod API, but Andy
Shevchenko beat me to it, so movement to gpiod_set_value_cansleep()
is all that is left.

Thanks.

-- 
Dmitry
Re: [PATCH net-next] nfc: st95hf: switch to using sleeping variants of gpiod API
Posted by Przemek Kitszel 1 year, 5 months ago
On 8/20/24 03:10, Dmitry Torokhov wrote:
> The driver does not not use gpiod API calls in an atomic context. Switch

please remove one "not"

> to gpiod_set_value_cansleep() calls to allow using the driver with GPIO
> controllers that might need process context to operate.
> 
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Code is fine, but why not as a fix?

> ---
>   drivers/nfc/st95hf/core.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/nfc/st95hf/core.c b/drivers/nfc/st95hf/core.c
> index ffe5b4eab457..5b3451fc4491 100644
> --- a/drivers/nfc/st95hf/core.c
> +++ b/drivers/nfc/st95hf/core.c
> @@ -450,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 */
> -	gpiod_set_value(st95con->enable_gpiod, HIGH);
> +	gpiod_set_value_cansleep(st95con->enable_gpiod, HIGH);
>   
>   	/* wait for 1 milisecond */
>   	usleep_range(1000, 2000);
>   
>   	/* Make irq_in pin low */
> -	gpiod_set_value(st95con->enable_gpiod, LOW);
> +	gpiod_set_value_cansleep(st95con->enable_gpiod, LOW);
>   
>   	/* wait for minimum interrupt pulse to make st95 active */
>   	usleep_range(1000, 2000);
>   
>   	/* At end make it high */
> -	gpiod_set_value(st95con->enable_gpiod, HIGH);
> +	gpiod_set_value_cansleep(st95con->enable_gpiod, HIGH);
>   }
>   
>   /*
Re: [PATCH net-next] nfc: st95hf: switch to using sleeping variants of gpiod API
Posted by Andrew Lunn 1 year, 5 months ago
On Tue, Aug 20, 2024 at 10:10:37AM +0200, Przemek Kitszel wrote:
> On 8/20/24 03:10, Dmitry Torokhov wrote:
> > The driver does not not use gpiod API calls in an atomic context. Switch
> 
> please remove one "not"
> 
> > to gpiod_set_value_cansleep() calls to allow using the driver with GPIO
> > controllers that might need process context to operate.
> > 
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> Code is fine, but why not as a fix?

Why would this be a fix? What is broken?

    Andrew
Re: [PATCH net-next] nfc: st95hf: switch to using sleeping variants of gpiod API
Posted by Dmitry Torokhov 1 year, 5 months ago
On Tue, Aug 20, 2024 at 03:53:21PM +0200, Andrew Lunn wrote:
> On Tue, Aug 20, 2024 at 10:10:37AM +0200, Przemek Kitszel wrote:
> > On 8/20/24 03:10, Dmitry Torokhov wrote:
> > > The driver does not not use gpiod API calls in an atomic context. Switch
> > 
> > please remove one "not"
> > 
> > > to gpiod_set_value_cansleep() calls to allow using the driver with GPIO
> > > controllers that might need process context to operate.
> > > 
> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > 
> > Code is fine, but why not as a fix?
> 
> Why would this be a fix? What is broken?

No, this is not a fix but a tiny enhancement. As far as I know no
existing devices actually require it.

Thanks.

-- 
Dmitry