Hi Andy,
The patch looks good to me.
The device got enumerated via ACPI on development platforms for
integration tests purposes.
Best Regards
Christophe
On 17/03/2017 08:49, Andy Shevchenko wrote:
On Tue, 2017-03-07 at 12:25 +0200, Andy Shevchenko wrote:
We return -ENODEV if ACPI provides a GPIO resource. Looks really
wrong.
If it has even been tested?
Any comments on this clean up?
Next patch which is dependent to this is related to ACPI enumeration.
After GPIO ACPI library gets stricter the driver wouldn't work without
ACPI related changes.
By the way, is this device have ever been enumerated via ACPI?
Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
---
drivers/nfc/st21nfca/i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nfc/st21nfca/i2c.c b/drivers/nfc/st21nfca/i2c.c
index 5a82f553906c..737384d287aa 100644
--- a/drivers/nfc/st21nfca/i2c.c
+++ b/drivers/nfc/st21nfca/i2c.c
@@ -514,9 +514,9 @@ static int
st21nfca_hci_i2c_acpi_request_resources(struct i2c_client *client)
/* Get EN GPIO from ACPI */
gpiod_ena = devm_gpiod_get_index(dev, ST21NFCA_GPIO_NAME_EN,
1,
GPIOD_OUT_LOW);
- if (!IS_ERR(gpiod_ena)) {
+ if (IS_ERR(gpiod_ena)) {
nfc_err(dev, "Unable to get ENABLE GPIO\n");
- return -ENODEV;
+ return PTR_ERR(gpiod_ena);
}
phy->gpio_ena = desc_to_gpio(gpiod_ena);
