Simplify the code a bit as mention by Axel Lin in a previous patch for
st21nfca.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Fixing scripts/checkpatch.pl error "code indent should use tabs where possible" in:
- i2c.c in st21nfcb_nci_irq_thread_fn function.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Fixing "sparse: cast to restricted __be32" message when building with
make C=1 CF=-D__CHECK_ENDIAN__
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The .owner member of struct device_driver is assigned THIS_MODULE twice.
Introduced by:
commit c44cb2edd0
("NFC: dts: st21nfca: Add device-tree (Open Firmware) support to st21nfca")
Acked-by: Christophe RICARD <christophe-h.ricard@st.com>
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
In the previous makefile 2 modules were generated for CONFIG_NFC_ST21NFCA
(st21nfca.ko and st21nfca_dep.ko). Merge both of them into st21nfca_hci.ko
and fix a potential depmod dependency cycle, similar to the one we saw
on st21nfcb:
depmod: WARNING: found 6 modules in dependency cycles!
depmod: WARNING:
/lib/modules/3.17.0-rc3-00002-g7505cea/kernel/drivers/nfc/st21nfcb/st21nfcb.ko
in dependency cycle!
depmod: WARNING:
/lib/modules/3.17.0-rc3-00002-g7505cea/kernel/drivers/nfc/st21nfcb/ndlc.ko
in dependency cycle!
depmod: WARNING:
/lib/modules/3.17.0-rc3-00002-g7505cea/kernel/net/rfkill/rfkill.ko in
dependency cycle!
depmod: WARNING:
/lib/modules/3.17.0-rc3-00002-g7505cea/kernel/net/nfc/nfc.ko in
dependency cycle!
depmod: WARNING:
/lib/modules/3.17.0-rc3-00002-g7505cea/kernel/net/nfc/nci/nci.ko in
dependency cycle!
depmod: WARNING:
/lib/modules/3.17.0-rc3-00002-g7505cea/kernel/lib/crc-ccitt.ko in
dependency cycle!
./scripts/depmod.sh: line 57: 23387 Segmentation fault (core
dumped) "$DEPMOD" "$@" "$KERNELRELEASE" $SYMBOL_PREFIX
make: *** [_modinst_post] Error 139
Reported-by: Daniel Wagner <wagi@monom.org>
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Add the ability to detect the mode (i.e., RF technology)
used by the initiator. The RF technology that was
detected can be retrieved by calling the 'tg_get_rf_tech'
driver hook.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Add target mode support to the trf7970a
NFC driver. This effectively enables full
Peer-to-Peer support.
To handle changing framing between sending
a response frame and receiving the subsequent
request frame, most of the framing changes
take effect in the interrupt handler and not
in trf7970a_tg_config_framing().
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The digital layer can try to send a command with a
timeout value of zero (e.g., digital_tg_send_psl_res().
The zero value is used as a flag to indicate that
the driver should not expect a response. To handle
this, the driver sets an internal timer because it
should still get an interrupt with the TX bit set
in the IRQ Status Register. When it gets that
interrupt, it returns a return value of '0'.
If it doesn't get the interrupt before timing out,
it returns ETIMEDOUT as usual.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Some paths leave a timer still running when
trf7970a_send_err_upstream() is called. This
can cause a timeout to occur in a subsequent
transaction making it fail. Fix this by ensuring
there is no timer running before sending an error
upstream.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Currently, the trf7970a driver blindly turns on its
RF field when configuring its framing. This isn't
a good idea if there is already a device generating
an RF field. Instead, check if there is already an
RF field present before turning on this device's RF
field and, if there is, return EBUSY.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When trf7970a_init() initializes the trf7970a it
implicitly turns off the RF transmitter. Track
this by clearing the TRF7970A_CHIP_STATUS_RF_ON
bit in the cached trf->chip_status_ctrl.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Rename trf7970a_config_rf_tech() and trf7970a_config_framing()
to trf7970a_in_config_rf_tech() and trf7970a_in_config_framing(),
respectively to avoid confusion when target support is added.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The trf7970a should be given at least 1 ms to
completely initialize after the 'Software Init'
and 'Idle' commands have been issued.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Add system suspend/resume support by gracefully
shutting things down when suspending and bringing
the device back to full power when resuming.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Encapsulate the code to start up and gracefully
shutdown the driver and trf7970a device. Doing
this makes adding system suspend/resume support
easier and the resulting code cleaner.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The current code assumes that CONFIG_PM_RUNTIME
is always defined so it won't power up the trf7970a
when it isn't enabled. Fix this by moving the power
up/down code from the pm_runtime_resume/suspend
routines into their own routines and calling the
power up function from the probe routine. This
ensures the device is powered up even when
CONFIG_PM_RUNTIME is not defined.
In order to not power on/off a device that is
already powered on/off, create a new state to
indicate that the power is off (TRF7970A_ST_PWR_OFF).
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Rename the 'TRF7970A_ST_OFF' state to 'TRF7970A_ST_RF_OFF'
to make it clear that this state means that the RF is
off and not the entire device.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
trf7970a_switch_rf_on() is currently a void function
but turning on the RF could fail so it should return
a return code. That return code should also be
propagated back to the entity that initiated the
action.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Depending on the interrupt status value given by the
trf7970a, the driver may not know when a receive operation
is complete. To handle this, the driver waits for a period
of time in case the trf7970a interrupts it again indicating
there are more RX data in the FIFO. It is possible that the
timeout will occur when there are RX data in the FIFO but
before the trf7970a has generated an interrupt to tell the
driver about it. Handle this by calling trf7970a_drain_fifo()
(instead of trf7970a_send_upstream() which just passes up the
data gathered to far) to check if there are more data in the
FIFO. If so, gather that data into the receive buffer. If
not, pass the data collected so far upstream as before.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Receiving an interrupt whose Interrupt Status Register
value has only the SRX bit set is supposed to mean that
all of the data from the tag has been received. That
turns out to not be true so we need to reread the FIFO
Status Register to tell if there are any new bytes in
the FIFO. If there are, continue receiving them; if
there aren't, assume that the receive is complete and
pass the data up.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>