Re: [PATCH net-next v2] net: nfc: Propagate ISO14443 type A target ATS to userspace via netlink

[Simon Horman <horms@kernel.org>]

On Sun, Nov 03, 2024 at 01:45:25PM +0100, Juraj Šarinay wrote:
> Add a 20-byte field ats to struct nfc_target and expose it as
> NFC_ATTR_TARGET_ATS via the netlink interface. The payload contains
> 'historical bytes' that help to distinguish cards from one another.
> The information is commonly used to assemble an emulated ATR similar
> to that reported by smart cards with contacts.
> 
> Add a 20-byte field target_ats to struct nci_dev to hold the payload
> obtained in nci_rf_intf_activated_ntf_packet() and copy it to over to
> nfc_target.ats in nci_activate_target(). The approach is similar
> to the handling of 'general bytes' within ATR_RES.

Hi Juraj,

Perhaps I misunderstand things, and perhaps there is precedence in relation
to ATR_RES. But I am slightly concerned that this leans towards exposing
internal details rather then semantics via netlink.

> Replace the hard-coded size of rats_res within struct
> activation_params_nfca_poll_iso_dep by the equal constant NFC_ATS_MAXSIZE
> now defined in nfc.h
> 
> Within NCI, the information corresponds to the 'RATS Response' activation
> parameter that omits the initial length byte TL. This loses no
> information and is consistent with our handling of SENSB_RES that
> also drops the first (constant) byte.
> 
> Tested with nxp_nci_i2c on a few type A targets including an
> ICAO 9303 compliant passport.
> 
> I refrain from the corresponding change to digital_in_recv_ats()
> to have the few drivers based on digital.h fill nfc_target.ats,
> as I have no way to test it. That class of drivers appear not to set
> NFC_ATTR_TARGET_SENSB_RES either. Consider a separate patch to propagate
> (all) the parameters.
> 
> Signed-off-by: Juraj Šarinay <juraj@sarinay.com>

...