By not always starting the polling loop from the same modulation, we
avoid entering infinite loops where devices exporting 2 targets (on 2
different modulations) get the same target activated over and over.
If this target is not readable (e.g. a wallet emulating a tag), we will
stay in an error loop for ever.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

It seems that some pn533 firmwares go belly up when being asked to send
poll frames too frequently. Adding a 10ms delay between each of them
calm the chip down and prevent it from crashing.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The extended information frame are sent by PN533 to exchange frames
larger than 255 bytes. These extended frame are very close from the
standard ones except for the header size length. On each incoming
frame, we set the correct header length, and we do that only for the
standard pn533 chipsets as the acr122 does not seem to support extended
frames properly.
Signed-off-by: NOlivier Guiter <olivier.guiter@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

On sending large frames (size > 262), we split it in multiple chunks and
send them asynchronously with MI bit.
Signed-off-by: NOlivier Guiter <olivier.guiter@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Extended Information frames are slightly different from standard frames
as they can (theorically) handle datas up tu 64kB. PN533 firmware only
supports packet data up to 265 (incl. TFI byte)
This kind of frame are used when the pn533 wants to exchange more than
255 bytes, and this patch handles the reception of such frames.
Signed-off-by: NOlivier Guiter <olivier.guiter@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The AUTO RFCA bit forbids the pn533 chipset to turn its radio on
whenever an external field is present.
Without this bit set, some devices seems to get over flood by the
pn533 rf field and thus become hardly detectable.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

p2p devices must be able to support 424 kbps, so we should always select
that bitrate in initiator mode.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Some devices are getting confused when not being asked for their system
code with type F.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

By turning the radio off after each failed polling try, we dramatically
improve the pn533 polling loop efficiency.
Without this fix, all Android phones running the broadcom NFC stack are
almost never detected.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

By using the standard setting for the regular pn533 dongles, we no
longer wait for ever for an ATR_RES. Without this, a failing ATR_REQ
will put the hardware into a busy loop, constantly waiting for an
ATR_RES.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Instead of dumping ACR122 frames as errors, we use the print_hex_dump()
dynamic debug APIs.
We also print an accurate IC version, as the ACR122 is pn532 based.
Signed-off-by: NOlivier Guiter <olivier.guiter@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Supported secure elements are typically found during a discovery process
initiated when the NFC controller is up and running. For a given NFC
chipset there can be many configurations (embedded SE or not, with or
without a SIM card wired to the NFC controller SWP interface, etc...) and
thus driver code will never know before hand which SEs are available.
So we remove this field, it will be replaced by a real SE discovery
mechanism.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

When using NFC-F we should copy the NFCID2 buffer that we got from
SENSF_RES through the ATR_REQ NFCID3 buffer. Not doing so violates
NFC Forum digital requirement #189.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

LLCP validation requires TSN to be 0x03 for type F.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Fix to return -ENOMEM in the nfc device alloc error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Correct spelling typo in various part of drivers
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Add missing usb_put_dev on failure path in pn533_probe().

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NMarina Makienko <makienko@ispras.ru>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Major features added in 0.2 version:

* frame ops added to support wider set of devices
* support of ACS ACR122U
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

pn533_abort_cmd() aborts last command sent to the controller
and cancels already requested urb.

As ACR122U does not support any mechanism (as ACK for standard
PN533) which aborts last command this cannot be issued for this
device. Otherwise, acr122u will behave in an unstable way.
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

ACS ACR122U is an USB NFC reader, PC/SC and CCID compilant, based
on NXP PN532 chip.

Internally, it's build of MCU, PN532 and an antenna. MCU makes the
device CCID and PC/SC compilant and provide USB connection.

In this achitecture, a host cannot talk directly to PN532 and must
rely on MCU. Luckily, MCU exposes pseud-APDU through PC/SC Escape
mechanism which let the host to transmit standard PN532 commands
directly to PN532 chip with some limitations.

The frame roughly looks like:

    CCID header    |          APDU header           |    PN532 header
(pc_to_rdr_escape) |  (pseudo apdu Direct Tramsmit) | (len, TFI, cmd, params)

Accordign to limitations, ACR122U does't provide any mechanism to
abort last issued command.
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

As not all devices require ACK confirmation of every request sent to the
controller, differentiate two protocol types.

First one, request-ack-response and the second one request-response type.
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Rename 'wq_in_error' field to more relevant 'status'
and move it to cmd context struct.
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Reorder code to avoid functions declaration.
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

In all cases (send_cmd_async, send_data_async and send_sync)
pn533_send_async_complete() handles all responses internally,
so there is no need to pass this as a callback.

Cmd context is passed to __pn533_send_frame_async in all the
cases as well. It's already kept in struct pn533 which is
available all the time the device is attached. So we can make
use of it instead.

Therefore, cmd_complete and cmd_complete_arg are no needed any more.
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

We must free 'cmd_complete_mi_arg' and not 'cmd_complete_arg'
when getting send error handling fragmented response.
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

'cmd->code' looks better then 'cmd->cmd_code'
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Keep cmd context in pn533 struct instead of only cmd code.
The context already includes cmd_code.
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Use struct pn533_cmd instead of pn533_send_async_complete_arg
to track the context of the issued cmd.

This way pn533_send_async_complete_arg struct is no needed
anymore. Just move issuer complete callback to pn533_cmd struct.
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

In case of error from __pn533_send_frame_async() while sending
next cmd from the queue (cmd_wq), cmd->req, cmd->resp and
cmd->arg pointers won't be freed.
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Define explicitely it is Pasori specific reset command.
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Remove duplicated authors info from the header as well.
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Depends on timing division by zero can happen when user stops
polling.

pn533_stop_poll() resets modulation counter on stop_poll, but
meanwhile we get response for last poll request and try, despite
of stop poll request, to schedule next modulation for polling.

Log message:
[345.922515] pn533 1-1.3:1.0: pn533_stop_poll
[345.928314] pn533 1-1.3:1.0: pn533_send_ack
[345.932769] pn533 1-1.3:1.0: Received a frame.
[345.937438] PN533 RX: 00 00 ff 03 fd d5 4b 00 e0 00
[345.942840] pn533 1-1.3:1.0: pn533_poll_complete
[345.947753] pn533 1-1.3:1.0: pn533_start_poll_complete
[345.953186] Division by zero in kernel.
[345.957244] [<c001b38c>] (unwind_backtrace+0x0/0xf0)
[345.965698] [<c0260e78>] (Ldiv0+0x8/0x10)
[345.974060] [<c0260e60>] (__aeabi_idivmod+0x8/0x18)
[345.983978] [<c02e0064>] (pn533_poll_complete+0x3c0/0x500)
[345.994903] [<c02df690>] (pn533_send_async_complete+0x7c/0xc0)
[346.005828] [<c02e028c>] (pn533_wq_cmd_complete+0x1c/0x34)
[346.016113] [<c005d134>] (process_one_work+0x1ac/0x57c)
[346.025848] [<c005d85c>] (worker_thread+0x168/0x42c)
[346.034576] [<c00620c0>] (kthread+0xa4/0xb0)
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

For better debugging as the codes are defined in hex in the spec.
Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Those can be very verbose and we only want them when debugging pn533.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Remove unneeded bitwise OR operator on uninitialized sk_buff data
Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>