When using `pn53x` chip with target not compatible with `InListPassiveTarget` (like `NMT_ISO14443BICLASS`, `NMT_ISO14443B2CT` & `NMT_ISO14443B2SR` by eg.), the logic behind `nfc_initiator_select_passive_target` to return target count seems to be buggy
`nfc_initiator_select_passive_target`:
> Returns:
> Returns selected passive target count on success, otherwise returns libnfc's error code (negative value)
In `pn53x_initiator_select_passive_target_ext`, the return value in success is always `abtTargetsData[0]`. This is correct when using `InListPassiveTarget` as the first byte is `NbTg`, but it can be problematic for other cases.
- Example with a Mifare:
```
gentilkiwi@pi5:~/libnfc-dev $ ./utils/nfc-list -t 1
NFC device: Elechouse NFC Module V3 (SPI) opened
## End of function 'pn53x_initiator_select_passive_target_ext'...
## abtTargetsData content is : 01 01 00 04 08 04 1a da 74 44
## return will be: 0x01 (?)
1 ISO14443A passive target(s) found:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): 1a da 74 44
SAK (SEL_RES): 08
```
- Example with 2x ST25TB:
```
gentilkiwi@pi5:~/libnfc-dev $ ./utils/nfc-list -t 32
NFC device: Elechouse NFC Module V3 (SPI) opened
## End of function 'pn53x_initiator_select_passive_target_ext'...
## abtTargetsData content is : 35 a5 f2 a4 68 1f 02 d0
## return will be: 0x35 (?)
1 ISO14443B-2 ST SRx passive target(s) found:
ISO/IEC 14443-2B ST SRx (106 kbps) target:
UID: 35 a5 f2 a4 68 1f 02 d0
```
```
gentilkiwi@pi5:~/libnfc-dev $ ./utils/nfc-list -t 32
NFC device: Elechouse NFC Module V3 (SPI) opened
## End of function 'pn53x_initiator_select_passive_target_ext'...
## abtTargetsData content is : 00 92 f0 a4 68 1f 02 d0
## return will be: 0x00 (?)
0 ISO14443B-2 ST SRx passive target(s) found.
```
The proposed PR will fix the target count to 1 when not using `InListPassiveTarget`, since current versions of target initialisation do not support for more.
- Results:
```
gentilkiwi@pi5:~/libnfc-dev $ ./utils/nfc-list -t 32
NFC device: Elechouse NFC Module V3 (SPI) opened
1 ISO14443B-2 ST SRx passive target(s) found:
ISO/IEC 14443-2B ST SRx (106 kbps) target:
UID: 00 92 f0 a4 68 1f 02 d0
gentilkiwi@pi5:~/libnfc-dev $ ./examples/nfc-st25tb
|mode : info
Reader : Elechouse NFC Module V3 (SPI) - via pn532_spi:/dev/spidev0.0:500000
...wait for card...
Target : ISO/IEC 14443-2B ST SRx (106 kbps)
UID : 00 92 f0 a4 68 1f 02 d0
Manuf : 0x02 - STMicroelectronics
ChipId : 0x1f - ST25TB04K
Serial : 0x68a4f09200
|blk sz : 32 bits
|nb blks: 128
|sys idx: 255
```
(also checked for non-regression with `InListPassiveTarget`, including multiples `A` targets)
CMake Warning (dev) at utils/CMakeLists.txt:50 (ADD_EXECUTABLE):
Policy CMP0115 is not set: Source file extensions must be explicit. Run
"cmake --help-policy CMP0115" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
File:
/home/rousseau/Documents/github/libnfc/utils/jewel.c
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Warning (dev) at libnfc/CMakeLists.txt:77 (ADD_LIBRARY):
Policy CMP0115 is not set: Source file extensions must be explicit. Run
"cmake --help-policy CMP0115" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
File:
/home/rousseau/Documents/github/libnfc/libnfc/nfc.c
This warning is for project developers. Use -Wno-dev to suppress it.
Modification to set PN53X_REG_CIU_TxAuto, PN53X_REG_CIU_CWGsP & PN53X_REG_CIU_ModGsP registers values before init.
Avoids a dummy scan in B mode before
Without this patch the cmake config assume that every UNIX system that
is not APPLE is automatically a linux system. This however causes
problems on FreeBSD and properly on other BSD systems.
We now explicitly check if the CMAKE_SYSTEM_NAME is set to Linux.
There is a small typo in contrib/win32/libnfc/buses/uart.c, libnfc/drivers/acr122_usb.c, libnfc/drivers/acr122s.c, libnfc/drivers/arygon.c, libnfc/drivers/pn532_uart.c, libnfc/drivers/pn53x_usb.c.
Should read `mechanism` rather than `mecanism`.
Fix 4k - [@gelotus]
(we can re-introduce support for other card types later as long as we adhere to the principal that we don't write unless requested to)
