Check the return code of i2c_master_recv() for actual errors and
propagate it to the caller.
Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver")
Signed-off-by: Michael Walle <[email protected]>
---
drivers/nfc/nxp-nci/i2c.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 7e451c10985d..9c80d5a6d56b 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -163,7 +163,10 @@ static int nxp_nci_i2c_nci_read(struct nxp_nci_i2c_phy *phy,
skb_put_data(*skb, (void *)&header, NCI_CTRL_HDR_SIZE);
r = i2c_master_recv(client, skb_put(*skb, header.plen), header.plen);
- if (r != header.plen) {
+ if (r < 0) {
+ nfc_err(&client->dev, "I2C receive error %pe\n", ERR_PTR(r));
+ goto nci_read_exit_free_skb;
+ } else if (r != header.plen) {
nfc_err(&client->dev,
"Invalid frame payload length: %u (expected %u)\n",
r, header.plen);
--
2.30.2
On 26/06/2022 21:42, Michael Walle wrote:
> Check the return code of i2c_master_recv() for actual errors and
> propagate it to the caller.
>
> Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver")
The check was there, so I don't see here bug. The only thing missing was
a bit more detailed error message (without cast to %u) and propagating
error code instead of EBADMSG, but these are not bugs. The commit msg
should sound different and Fixes tag is not appropriate.
> Signed-off-by: Michael Walle <[email protected]>
> ---
> drivers/nfc/nxp-nci/i2c.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
> index 7e451c10985d..9c80d5a6d56b 100644
> --- a/drivers/nfc/nxp-nci/i2c.c
> +++ b/drivers/nfc/nxp-nci/i2c.c
> @@ -163,7 +163,10 @@ static int nxp_nci_i2c_nci_read(struct nxp_nci_i2c_phy *phy,
> skb_put_data(*skb, (void *)&header, NCI_CTRL_HDR_SIZE);
>
> r = i2c_master_recv(client, skb_put(*skb, header.plen), header.plen);
> - if (r != header.plen) {
> + if (r < 0) {
> + nfc_err(&client->dev, "I2C receive error %pe\n", ERR_PTR(r));
Print just 'r'.
> + goto nci_read_exit_free_skb;
> + } else if (r != header.plen) {
> nfc_err(&client->dev,
> "Invalid frame payload length: %u (expected %u)\n",
> r, header.plen);
Best regards,
Krzysztof
There are packets which doesn't have a payload. In that case, the second
i2c_master_read() will have a zero length. But because the NFC
controller doesn't have any data left, it will NACK the I2C read and
-ENXIO will be returned. In case there is no payload, just skip the
second i2c master read.
Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver")
Signed-off-by: Michael Walle <[email protected]>
---
drivers/nfc/nxp-nci/i2c.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 9c80d5a6d56b..c9361b5249b7 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -162,6 +162,9 @@ static int nxp_nci_i2c_nci_read(struct nxp_nci_i2c_phy *phy,
skb_put_data(*skb, (void *)&header, NCI_CTRL_HDR_SIZE);
+ if (!header.plen)
+ return 0;
+
r = i2c_master_recv(client, skb_put(*skb, header.plen), header.plen);
if (r < 0) {
nfc_err(&client->dev, "I2C receive error %pe\n", ERR_PTR(r));
--
2.30.2
Am 2022-06-26 21:51, schrieb Krzysztof Kozlowski:
> On 26/06/2022 21:42, Michael Walle wrote:
>> There are packets which doesn't have a payload. In that case, the
>> second
>> i2c_master_read() will have a zero length. But because the NFC
>> controller doesn't have any data left, it will NACK the I2C read and
>> -ENXIO will be returned. In case there is no payload, just skip the
>> second i2c master read.
>>
>> Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI
>> driver")
>> Signed-off-by: Michael Walle <[email protected]>
>
> Reviewed-by: Krzysztof Kozlowski <[email protected]>
Thanks, I'll reorder the patches in the next version otherwise
there will likely be a conflict. That should work with any patch
tools (i.e. b4), shouldn't it?
-michael
On 26/06/2022 21:42, Michael Walle wrote:
> There are packets which doesn't have a payload. In that case, the second
> i2c_master_read() will have a zero length. But because the NFC
> controller doesn't have any data left, it will NACK the I2C read and
> -ENXIO will be returned. In case there is no payload, just skip the
> second i2c master read.
>
> Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver")
> Signed-off-by: Michael Walle <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Best regards,
Krzysztof
On 26/06/2022 21:56, Michael Walle wrote:
> Am 2022-06-26 21:51, schrieb Krzysztof Kozlowski:
>> On 26/06/2022 21:42, Michael Walle wrote:
>>> There are packets which doesn't have a payload. In that case, the
>>> second
>>> i2c_master_read() will have a zero length. But because the NFC
>>> controller doesn't have any data left, it will NACK the I2C read and
>>> -ENXIO will be returned. In case there is no payload, just skip the
>>> second i2c master read.
>>>
>>> Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI
>>> driver")
>>> Signed-off-by: Michael Walle <[email protected]>
>>
>> Reviewed-by: Krzysztof Kozlowski <[email protected]>
>
> Thanks, I'll reorder the patches in the next version otherwise
> there will likely be a conflict.
Yes.
> That should work with any patch
> tools (i.e. b4), shouldn't it?
You mean - re-ordering should work? Yes, no problem with that.
Best regards,
Krzysztof
Am 2022-06-26 21:49, schrieb Krzysztof Kozlowski:
> On 26/06/2022 21:42, Michael Walle wrote:
>> Check the return code of i2c_master_recv() for actual errors and
>> propagate it to the caller.
>>
>> Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI
>> driver")
>
> The check was there, so I don't see here bug. The only thing missing
> was
> a bit more detailed error message (without cast to %u) and propagating
> error code instead of EBADMSG, but these are not bugs. The commit msg
> should sound different and Fixes tag is not appropriate.
Well one could argue the nfc_err() is very misleading as it prints
an unreasonable large number. Will remove the Fixes tag and reword
the commit message.
>> Signed-off-by: Michael Walle <[email protected]>
>> ---
>> drivers/nfc/nxp-nci/i2c.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
>> index 7e451c10985d..9c80d5a6d56b 100644
>> --- a/drivers/nfc/nxp-nci/i2c.c
>> +++ b/drivers/nfc/nxp-nci/i2c.c
>> @@ -163,7 +163,10 @@ static int nxp_nci_i2c_nci_read(struct
>> nxp_nci_i2c_phy *phy,
>> skb_put_data(*skb, (void *)&header, NCI_CTRL_HDR_SIZE);
>>
>> r = i2c_master_recv(client, skb_put(*skb, header.plen),
>> header.plen);
>> - if (r != header.plen) {
>> + if (r < 0) {
>> + nfc_err(&client->dev, "I2C receive error %pe\n", ERR_PTR(r));
>
> Print just 'r'.
Personally, I prefer seeing the actual error string and this idiom is
also used in other drivers. But I wont insist, will change it.
>
>> + goto nci_read_exit_free_skb;
>> + } else if (r != header.plen) {
>> nfc_err(&client->dev,
>> "Invalid frame payload length: %u (expected %u)\n",
>> r, header.plen);
>
>
> Best regards,
> Krzysztof
-michael
On Sun, 26 Jun 2022 21:42:43 +0200 Michael Walle wrote:
> There are packets which doesn't have a payload. In that case, the second
> i2c_master_read() will have a zero length. But because the NFC
> controller doesn't have any data left, it will NACK the I2C read and
> -ENXIO will be returned. In case there is no payload, just skip the
> second i2c master read.
Whoa, are you using this code or just found the problem thru code
inspection? NFC is notorious for having no known users.
Am 2022-06-28 07:03, schrieb Jakub Kicinski:
> On Sun, 26 Jun 2022 21:42:43 +0200 Michael Walle wrote:
>> There are packets which doesn't have a payload. In that case, the
>> second
>> i2c_master_read() will have a zero length. But because the NFC
>> controller doesn't have any data left, it will NACK the I2C read and
>> -ENXIO will be returned. In case there is no payload, just skip the
>> second i2c master read.
>
> Whoa, are you using this code or just found the problem thru code
> inspection? NFC is notorious for having no known users.
Ha! Well, I *try* to use it with a PN7160. No luck so far, we'll see.
At least the communication with the chip works now. I was also kinda
tricked by the Supported status ;)
-michael