linux-toradex.git/net/nfc, branch v4.10

genetlink: mark families as __ro_after_init

2016-10-27T20:16:09+00:00

Now genl_register_family() is the only thing (other than the
users themselves, perhaps, but I didn't find any doing that)
writing to the family struct.

In all families that I found, genl_register_family() is only
called from __init functions (some indirectly, in which case
I've add __init annotations to clarifly things), so all can
actually be marked __ro_after_init.

This protects the data structure from accidental corruption.

Signed-off-by: Johannes Berg 
Signed-off-by: David S. Miller

genetlink: statically initialize families

2016-10-27T20:16:09+00:00

Instead of providing macros/inline functions to initialize
the families, make all users initialize them statically and
get rid of the macros.

This reduces the kernel code size by about 1.6k on x86-64
(with allyesconfig).

Signed-off-by: Johannes Berg 
Signed-off-by: David S. Miller

genetlink: no longer support using static family IDs

2016-10-27T20:16:09+00:00

Static family IDs have never really been used, the only
use case was the workaround I introduced for those users
that assumed their family ID was also their multicast
group ID.

Additionally, because static family IDs would never be
reserved by the generic netlink code, using a relatively
low ID would only work for built-in families that can be
registered immediately after generic netlink is started,
which is basically only the control family (apart from
the workaround code, which I also had to add code for so
it would reserve those IDs)

Thus, anything other than GENL_ID_GENERATE is flawed and
luckily not used except in the cases I mentioned. Move
those workarounds into a few lines of code, and then get
rid of GENL_ID_GENERATE entirely, making it more robust.

Signed-off-by: Johannes Berg 
Signed-off-by: David S. Miller

genetlink: introduce and use genl_family_attrbuf()

2016-10-27T20:16:08+00:00

This helper function allows family implementations to access
their family's attrbuf. This gets rid of the attrbuf usage
in families, and also adds locking validation, since it's not
valid to use the attrbuf with parallel_ops or outside of the
dumpit callback.

Signed-off-by: Johannes Berg 
Signed-off-by: David S. Miller

NFC: digital: Fix RTOX supervisor PDU handling

2016-07-11T00:02:03+00:00

When the target needs more time to process the received PDU, it sends
Response Timeout Extension (RTOX) PDU.

When the initiator receives a RTOX PDU, it must reply with a RTOX PDU
and extends the current rwt value with the formula:
 rwt_int = rwt * rtox

This patch takes care of the rtox value passed by the target in the RTOX
PDU and extends the timeout for the next response accordingly.

Signed-off-by: Thierry Escande 
Signed-off-by: Samuel Ortiz

NFC: digital: Add support for NFC DEP Response Waiting Time

2016-07-11T00:01:14+00:00

When sending an ATR_REQ, the initiator must wait for the ATR_RES at
least 'RWT(nfcdep,activation) + dRWT(nfcdep)' and no more than
'RWT(nfcdep,activation) + dRWT(nfcdep) + dT(nfcdep,initiator)'. This
gives a timeout value between 1237 ms and 1337 ms. This patch defines
DIGITAL_ATR_RES_RWT to 1337 used for the timeout value of ATR_REQ
command.

For other DEP PDUs, the initiator must wait between 'RWT + dRWT(nfcdep)'
and 'RWT + dRWT(nfcdep) + dT(nfcdep,initiator)' where RWT is given by
the following formula: '(256 * 16 / f(c)) * 2^wt' where wt is the value
of the TO field in the ATR_RES response and is in the range between 0
and 14. This patch declares a mapping table for wt values and gives RWT
max values between 100 ms and 5049 ms.

This patch also defines DIGITAL_ATR_RES_TO_WT, the maximum wt value in
target mode, to 8.

Signed-off-by: Thierry Escande 
Signed-off-by: Samuel Ortiz

NFC: digital: Free supervisor PDUs

2016-07-11T00:00:26+00:00

This patch frees the RTOX resp sk_buff in initiator mode. It also makes
use of the free_resp exit point for ATN supervisor PDUs in both
initiator and target mode.

Signed-off-by: Thierry Escande 
Signed-off-by: Samuel Ortiz

NFC: digital: Rework ACK PDU handling in initiator mode

2016-07-10T23:59:37+00:00

With this patch, ACK PDU sk_buffs are now freed and code has been
refactored for better errors handling.

Signed-off-by: Thierry Escande 
Signed-off-by: Samuel Ortiz

NFC: digital: Fix ACK & NACK PDUs handling in target mode

2016-07-10T23:58:46+00:00

When the target receives a NACK PDU, it re-sends the last sent PDU.

ACK PDUs are received by the target as a reply from the initiator to
chained I-PDUs. There are 3 cases to handle:
- If the target has previously received 1 or more ATN PDUs and the PNI
  in the ACK PDU is equal to the target PNI - 1, then it means that the
  initiator did not received the last issued PDU from the target. In
  this case it re-sends this PDU.
- If the target has received 1 or more ATN PDUs but the ACK PNI is not
  the target PNI - 1, then this means that this ACK is the reply of the
  previous chained I-PDU sent by the target. The target did not received
  it on the first attempt and it is being re-sent by the initiator. The
  process continues as usual.
- No ATN PDU received before this ACK PDU. This is the reply of a
  chained I-PDU. The target keeps on processing its chained I-PDU.

The code has been refactored to avoid too many indentation levels.

Also, ACK and NACK PDUs were not freed. This is now fixed.

Signed-off-by: Thierry Escande 
Signed-off-by: Samuel Ortiz

NFC: digital: Fix target DEP_REQ I-PDU handling after ATN PDU

2016-07-10T23:57:50+00:00

When the initiator sends a DEP_REQ I-PDU, the target device may not
reply in a timely manner. In this case the initiator device must send an
attention PDU (ATN) and if the recipient replies with an ATN PDU in
return, then the last I-PDU must be sent again by the initiator.

This patch fixes how the target handles I-PDU received after an ATN PDU
has been received.

There are 2 possible cases:
- The target has received the initial DEP_REQ and sends back the DEP_RES
  but the initiator did not receive it. In this case, after the
  initiator has sent an ATN PDU and the target replied it (with an ATN
  as well), the initiator sends the saved skb of the initial DEP_REQ
  again and the target replies with the saved skb of the initial
  DEP_RES.
- Or the target did not even received the initial DEP_REQ. In this case,
  after the ATN PDUs exchange, the initiator sends the saved skb and the
  target simply passes it up, just as usual.

This behavior is controlled using the atn_count and the PNI field of the
digital device structure.

Signed-off-by: Thierry Escande 
Signed-off-by: Samuel Ortiz