2019-05-30 07:57:49 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2013-05-29 21:35:02 +08:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2013 Intel Corporation. All rights reserved.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#define pr_fmt(fmt) "nci_spi: %s: " fmt, __func__
|
|
|
|
|
|
2015-10-26 17:27:42 +08:00
|
|
|
#include <linux/module.h>
|
|
|
|
|
|
2013-05-29 21:35:02 +08:00
|
|
|
#include <linux/export.h>
|
|
|
|
|
#include <linux/spi/spi.h>
|
2013-05-29 21:35:03 +08:00
|
|
|
#include <linux/crc-ccitt.h>
|
2013-05-29 21:35:02 +08:00
|
|
|
#include <net/nfc/nci_core.h>
|
|
|
|
|
|
2013-05-29 21:35:04 +08:00
|
|
|
#define NCI_SPI_ACK_SHIFT 6
|
|
|
|
|
#define NCI_SPI_MSB_PAYLOAD_MASK 0x3F
|
2013-05-29 21:35:02 +08:00
|
|
|
|
2013-05-29 21:35:03 +08:00
|
|
|
#define NCI_SPI_SEND_TIMEOUT (NCI_CMD_TIMEOUT > NCI_DATA_TIMEOUT ? \
|
|
|
|
|
NCI_CMD_TIMEOUT : NCI_DATA_TIMEOUT)
|
|
|
|
|
|
|
|
|
|
#define NCI_SPI_DIRECT_WRITE 0x01
|
|
|
|
|
#define NCI_SPI_DIRECT_READ 0x02
|
|
|
|
|
|
|
|
|
|
#define ACKNOWLEDGE_NONE 0
|
|
|
|
|
#define ACKNOWLEDGE_ACK 1
|
|
|
|
|
#define ACKNOWLEDGE_NACK 2
|
|
|
|
|
|
|
|
|
|
#define CRC_INIT 0xFFFF
|
|
|
|
|
|
NFC: NCI: Modify NCI SPI to implement CS/INT handshake per the spec
The NFC Forum NCI specification defines both a hardware and software
protocol when using a SPI physical transport to connect an NFC NCI
Chipset. The hardware requirement is that, after having raised the chip
select line, the SPI driver must wait for an INT line from the NFC
chipset to raise before it sends the data. The chip select must be
raised first though, because this is the signal that the NFC chipset
will detect to wake up and then raise its INT line. If the INT line
doesn't raise in a timely fashion, the SPI driver should abort
operation.
When data is transferred from Device host (DH) to NFC Controller (NFCC),
the signaling sequence is the following:
Data Transfer from DH to NFCC
• 1-Master asserts SPI_CSN
• 2-Slave asserts SPI_INT
• 3-Master sends NCI-over-SPI protocol header and payload data
• 4-Slave deasserts SPI_INT
• 5-Master deasserts SPI_CSN
When data must be transferred from NFCC to DH, things are a little bit
different.
Data Transfer from NFCC to DH
• 1-Slave asserts SPI_INT -> NFC chipset irq handler called -> process
reading from SPI
• 2-Master asserts SPI_CSN
• 3-Master send 2-octet NCI-over-SPI protocol header
• 4-Slave sends 2-octet NCI-over-SPI protocol payload length
• 5-Slave sends NCI-over-SPI protocol payload
• 6-Master deasserts SPI_CSN
In this case, SPI driver should function normally as it does today. Note
that the INT line can and will be lowered anytime between beginning of
step 3 and end of step 5. A low INT is therefore valid after chip select
has been raised.
This would be easily implemented in a single driver. Unfortunately, we
don't write the SPI driver and I had to imagine some workaround trick to
get the SPI and NFC drivers to work in a synchronized fashion. The trick
is the following:
- send an empty spi message: this will raise the chip select line, and
send nothing. We expect the /CS line will stay arisen because we asked
for it in the spi_transfer cs_change field
- wait for a completion, that will be completed by the NFC driver IRQ
handler when it knows we are in the process of sending data (NFC spec
says that we use SPI in a half duplex mode, so we are either sending or
receiving).
- when completed, proceed with the normal data send.
This has been tested and verified to work very consistently on a Nexus
10 (spi-s3c64xx driver). It may not work the same with other spi
drivers.
The previously defined nci_spi_ops{} whose intended purpose were to
address this problem are not used anymore and therefore totally removed.
The nci_spi_send() takes a new optional write_handshake_completion
completion pointer. If non NULL, the nci spi layer will run the above
trick when sending data to the NFC Chip. If NULL, the data is sent
normally all at once and it is then the NFC driver responsibility to
know what it's doing.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-23 23:56:43 +08:00
|
|
|
static int __nci_spi_send(struct nci_spi *nspi, struct sk_buff *skb,
|
|
|
|
|
int cs_change)
|
2013-05-29 21:35:03 +08:00
|
|
|
{
|
|
|
|
|
struct spi_message m;
|
|
|
|
|
struct spi_transfer t;
|
|
|
|
|
|
2013-09-24 00:02:43 +08:00
|
|
|
memset(&t, 0, sizeof(struct spi_transfer));
|
NFC: NCI: Modify NCI SPI to implement CS/INT handshake per the spec
The NFC Forum NCI specification defines both a hardware and software
protocol when using a SPI physical transport to connect an NFC NCI
Chipset. The hardware requirement is that, after having raised the chip
select line, the SPI driver must wait for an INT line from the NFC
chipset to raise before it sends the data. The chip select must be
raised first though, because this is the signal that the NFC chipset
will detect to wake up and then raise its INT line. If the INT line
doesn't raise in a timely fashion, the SPI driver should abort
operation.
When data is transferred from Device host (DH) to NFC Controller (NFCC),
the signaling sequence is the following:
Data Transfer from DH to NFCC
• 1-Master asserts SPI_CSN
• 2-Slave asserts SPI_INT
• 3-Master sends NCI-over-SPI protocol header and payload data
• 4-Slave deasserts SPI_INT
• 5-Master deasserts SPI_CSN
When data must be transferred from NFCC to DH, things are a little bit
different.
Data Transfer from NFCC to DH
• 1-Slave asserts SPI_INT -> NFC chipset irq handler called -> process
reading from SPI
• 2-Master asserts SPI_CSN
• 3-Master send 2-octet NCI-over-SPI protocol header
• 4-Slave sends 2-octet NCI-over-SPI protocol payload length
• 5-Slave sends NCI-over-SPI protocol payload
• 6-Master deasserts SPI_CSN
In this case, SPI driver should function normally as it does today. Note
that the INT line can and will be lowered anytime between beginning of
step 3 and end of step 5. A low INT is therefore valid after chip select
has been raised.
This would be easily implemented in a single driver. Unfortunately, we
don't write the SPI driver and I had to imagine some workaround trick to
get the SPI and NFC drivers to work in a synchronized fashion. The trick
is the following:
- send an empty spi message: this will raise the chip select line, and
send nothing. We expect the /CS line will stay arisen because we asked
for it in the spi_transfer cs_change field
- wait for a completion, that will be completed by the NFC driver IRQ
handler when it knows we are in the process of sending data (NFC spec
says that we use SPI in a half duplex mode, so we are either sending or
receiving).
- when completed, proceed with the normal data send.
This has been tested and verified to work very consistently on a Nexus
10 (spi-s3c64xx driver). It may not work the same with other spi
drivers.
The previously defined nci_spi_ops{} whose intended purpose were to
address this problem are not used anymore and therefore totally removed.
The nci_spi_send() takes a new optional write_handshake_completion
completion pointer. If non NULL, the nci spi layer will run the above
trick when sending data to the NFC Chip. If NULL, the data is sent
normally all at once and it is then the NFC driver responsibility to
know what it's doing.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-23 23:56:43 +08:00
|
|
|
/* a NULL skb means we just want the SPI chip select line to raise */
|
|
|
|
|
if (skb) {
|
|
|
|
|
t.tx_buf = skb->data;
|
|
|
|
|
t.len = skb->len;
|
|
|
|
|
} else {
|
|
|
|
|
/* still set tx_buf non NULL to make the driver happy */
|
|
|
|
|
t.tx_buf = &t;
|
|
|
|
|
t.len = 0;
|
|
|
|
|
}
|
|
|
|
|
t.cs_change = cs_change;
|
2019-12-04 15:58:09 +08:00
|
|
|
t.delay.value = nspi->xfer_udelay;
|
|
|
|
|
t.delay.unit = SPI_DELAY_UNIT_USECS;
|
2015-10-26 17:27:43 +08:00
|
|
|
t.speed_hz = nspi->xfer_speed_hz;
|
2013-05-29 21:35:03 +08:00
|
|
|
|
|
|
|
|
spi_message_init(&m);
|
|
|
|
|
spi_message_add_tail(&t, &m);
|
|
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
return spi_sync(nspi->spi, &m);
|
2013-05-29 21:35:03 +08:00
|
|
|
}
|
|
|
|
|
|
NFC: NCI: Modify NCI SPI to implement CS/INT handshake per the spec
The NFC Forum NCI specification defines both a hardware and software
protocol when using a SPI physical transport to connect an NFC NCI
Chipset. The hardware requirement is that, after having raised the chip
select line, the SPI driver must wait for an INT line from the NFC
chipset to raise before it sends the data. The chip select must be
raised first though, because this is the signal that the NFC chipset
will detect to wake up and then raise its INT line. If the INT line
doesn't raise in a timely fashion, the SPI driver should abort
operation.
When data is transferred from Device host (DH) to NFC Controller (NFCC),
the signaling sequence is the following:
Data Transfer from DH to NFCC
• 1-Master asserts SPI_CSN
• 2-Slave asserts SPI_INT
• 3-Master sends NCI-over-SPI protocol header and payload data
• 4-Slave deasserts SPI_INT
• 5-Master deasserts SPI_CSN
When data must be transferred from NFCC to DH, things are a little bit
different.
Data Transfer from NFCC to DH
• 1-Slave asserts SPI_INT -> NFC chipset irq handler called -> process
reading from SPI
• 2-Master asserts SPI_CSN
• 3-Master send 2-octet NCI-over-SPI protocol header
• 4-Slave sends 2-octet NCI-over-SPI protocol payload length
• 5-Slave sends NCI-over-SPI protocol payload
• 6-Master deasserts SPI_CSN
In this case, SPI driver should function normally as it does today. Note
that the INT line can and will be lowered anytime between beginning of
step 3 and end of step 5. A low INT is therefore valid after chip select
has been raised.
This would be easily implemented in a single driver. Unfortunately, we
don't write the SPI driver and I had to imagine some workaround trick to
get the SPI and NFC drivers to work in a synchronized fashion. The trick
is the following:
- send an empty spi message: this will raise the chip select line, and
send nothing. We expect the /CS line will stay arisen because we asked
for it in the spi_transfer cs_change field
- wait for a completion, that will be completed by the NFC driver IRQ
handler when it knows we are in the process of sending data (NFC spec
says that we use SPI in a half duplex mode, so we are either sending or
receiving).
- when completed, proceed with the normal data send.
This has been tested and verified to work very consistently on a Nexus
10 (spi-s3c64xx driver). It may not work the same with other spi
drivers.
The previously defined nci_spi_ops{} whose intended purpose were to
address this problem are not used anymore and therefore totally removed.
The nci_spi_send() takes a new optional write_handshake_completion
completion pointer. If non NULL, the nci spi layer will run the above
trick when sending data to the NFC Chip. If NULL, the data is sent
normally all at once and it is then the NFC driver responsibility to
know what it's doing.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-23 23:56:43 +08:00
|
|
|
int nci_spi_send(struct nci_spi *nspi,
|
|
|
|
|
struct completion *write_handshake_completion,
|
|
|
|
|
struct sk_buff *skb)
|
2013-05-29 21:35:02 +08:00
|
|
|
{
|
2013-05-29 21:35:03 +08:00
|
|
|
unsigned int payload_len = skb->len;
|
|
|
|
|
unsigned char *hdr;
|
|
|
|
|
int ret;
|
|
|
|
|
long completion_rc;
|
|
|
|
|
|
|
|
|
|
/* add the NCI SPI header to the start of the buffer */
|
|
|
|
|
hdr = skb_push(skb, NCI_SPI_HDR_LEN);
|
|
|
|
|
hdr[0] = NCI_SPI_DIRECT_WRITE;
|
2013-09-05 17:02:21 +08:00
|
|
|
hdr[1] = nspi->acknowledge_mode;
|
2013-05-29 21:35:03 +08:00
|
|
|
hdr[2] = payload_len >> 8;
|
|
|
|
|
hdr[3] = payload_len & 0xFF;
|
|
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
if (nspi->acknowledge_mode == NCI_SPI_CRC_ENABLED) {
|
2013-05-29 21:35:03 +08:00
|
|
|
u16 crc;
|
|
|
|
|
|
|
|
|
|
crc = crc_ccitt(CRC_INIT, skb->data, skb->len);
|
networking: add and use skb_put_u8()
Joe and Bjørn suggested that it'd be nicer to not have the
cast in the fairly common case of doing
*(u8 *)skb_put(skb, 1) = c;
Add skb_put_u8() for this case, and use it across the code,
using the following spatch:
@@
expression SKB, C, S;
typedef u8;
identifier fn = {skb_put};
fresh identifier fn2 = fn ## "_u8";
@@
- *(u8 *)fn(SKB, S) = C;
+ fn2(SKB, C);
Note that due to the "S", the spatch isn't perfect, it should
have checked that S is 1, but there's also places that use a
sizeof expression like sizeof(var) or sizeof(u8) etc. Turns
out that nobody ever did something like
*(u8 *)skb_put(skb, 2) = c;
which would be wrong anyway since the second byte wouldn't be
initialized.
Suggested-by: Joe Perches <joe@perches.com>
Suggested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 20:29:24 +08:00
|
|
|
skb_put_u8(skb, crc >> 8);
|
|
|
|
|
skb_put_u8(skb, crc & 0xFF);
|
2013-05-29 21:35:03 +08:00
|
|
|
}
|
|
|
|
|
|
NFC: NCI: Modify NCI SPI to implement CS/INT handshake per the spec
The NFC Forum NCI specification defines both a hardware and software
protocol when using a SPI physical transport to connect an NFC NCI
Chipset. The hardware requirement is that, after having raised the chip
select line, the SPI driver must wait for an INT line from the NFC
chipset to raise before it sends the data. The chip select must be
raised first though, because this is the signal that the NFC chipset
will detect to wake up and then raise its INT line. If the INT line
doesn't raise in a timely fashion, the SPI driver should abort
operation.
When data is transferred from Device host (DH) to NFC Controller (NFCC),
the signaling sequence is the following:
Data Transfer from DH to NFCC
• 1-Master asserts SPI_CSN
• 2-Slave asserts SPI_INT
• 3-Master sends NCI-over-SPI protocol header and payload data
• 4-Slave deasserts SPI_INT
• 5-Master deasserts SPI_CSN
When data must be transferred from NFCC to DH, things are a little bit
different.
Data Transfer from NFCC to DH
• 1-Slave asserts SPI_INT -> NFC chipset irq handler called -> process
reading from SPI
• 2-Master asserts SPI_CSN
• 3-Master send 2-octet NCI-over-SPI protocol header
• 4-Slave sends 2-octet NCI-over-SPI protocol payload length
• 5-Slave sends NCI-over-SPI protocol payload
• 6-Master deasserts SPI_CSN
In this case, SPI driver should function normally as it does today. Note
that the INT line can and will be lowered anytime between beginning of
step 3 and end of step 5. A low INT is therefore valid after chip select
has been raised.
This would be easily implemented in a single driver. Unfortunately, we
don't write the SPI driver and I had to imagine some workaround trick to
get the SPI and NFC drivers to work in a synchronized fashion. The trick
is the following:
- send an empty spi message: this will raise the chip select line, and
send nothing. We expect the /CS line will stay arisen because we asked
for it in the spi_transfer cs_change field
- wait for a completion, that will be completed by the NFC driver IRQ
handler when it knows we are in the process of sending data (NFC spec
says that we use SPI in a half duplex mode, so we are either sending or
receiving).
- when completed, proceed with the normal data send.
This has been tested and verified to work very consistently on a Nexus
10 (spi-s3c64xx driver). It may not work the same with other spi
drivers.
The previously defined nci_spi_ops{} whose intended purpose were to
address this problem are not used anymore and therefore totally removed.
The nci_spi_send() takes a new optional write_handshake_completion
completion pointer. If non NULL, the nci spi layer will run the above
trick when sending data to the NFC Chip. If NULL, the data is sent
normally all at once and it is then the NFC driver responsibility to
know what it's doing.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-23 23:56:43 +08:00
|
|
|
if (write_handshake_completion) {
|
|
|
|
|
/* Trick SPI driver to raise chip select */
|
|
|
|
|
ret = __nci_spi_send(nspi, NULL, 1);
|
|
|
|
|
if (ret)
|
|
|
|
|
goto done;
|
2013-05-29 21:35:03 +08:00
|
|
|
|
NFC: NCI: Modify NCI SPI to implement CS/INT handshake per the spec
The NFC Forum NCI specification defines both a hardware and software
protocol when using a SPI physical transport to connect an NFC NCI
Chipset. The hardware requirement is that, after having raised the chip
select line, the SPI driver must wait for an INT line from the NFC
chipset to raise before it sends the data. The chip select must be
raised first though, because this is the signal that the NFC chipset
will detect to wake up and then raise its INT line. If the INT line
doesn't raise in a timely fashion, the SPI driver should abort
operation.
When data is transferred from Device host (DH) to NFC Controller (NFCC),
the signaling sequence is the following:
Data Transfer from DH to NFCC
• 1-Master asserts SPI_CSN
• 2-Slave asserts SPI_INT
• 3-Master sends NCI-over-SPI protocol header and payload data
• 4-Slave deasserts SPI_INT
• 5-Master deasserts SPI_CSN
When data must be transferred from NFCC to DH, things are a little bit
different.
Data Transfer from NFCC to DH
• 1-Slave asserts SPI_INT -> NFC chipset irq handler called -> process
reading from SPI
• 2-Master asserts SPI_CSN
• 3-Master send 2-octet NCI-over-SPI protocol header
• 4-Slave sends 2-octet NCI-over-SPI protocol payload length
• 5-Slave sends NCI-over-SPI protocol payload
• 6-Master deasserts SPI_CSN
In this case, SPI driver should function normally as it does today. Note
that the INT line can and will be lowered anytime between beginning of
step 3 and end of step 5. A low INT is therefore valid after chip select
has been raised.
This would be easily implemented in a single driver. Unfortunately, we
don't write the SPI driver and I had to imagine some workaround trick to
get the SPI and NFC drivers to work in a synchronized fashion. The trick
is the following:
- send an empty spi message: this will raise the chip select line, and
send nothing. We expect the /CS line will stay arisen because we asked
for it in the spi_transfer cs_change field
- wait for a completion, that will be completed by the NFC driver IRQ
handler when it knows we are in the process of sending data (NFC spec
says that we use SPI in a half duplex mode, so we are either sending or
receiving).
- when completed, proceed with the normal data send.
This has been tested and verified to work very consistently on a Nexus
10 (spi-s3c64xx driver). It may not work the same with other spi
drivers.
The previously defined nci_spi_ops{} whose intended purpose were to
address this problem are not used anymore and therefore totally removed.
The nci_spi_send() takes a new optional write_handshake_completion
completion pointer. If non NULL, the nci spi layer will run the above
trick when sending data to the NFC Chip. If NULL, the data is sent
normally all at once and it is then the NFC driver responsibility to
know what it's doing.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-23 23:56:43 +08:00
|
|
|
/* wait for NFC chip hardware handshake to complete */
|
|
|
|
|
if (wait_for_completion_timeout(write_handshake_completion,
|
|
|
|
|
msecs_to_jiffies(1000)) == 0) {
|
|
|
|
|
ret = -ETIME;
|
|
|
|
|
goto done;
|
|
|
|
|
}
|
|
|
|
|
}
|
2013-05-29 21:35:03 +08:00
|
|
|
|
NFC: NCI: Modify NCI SPI to implement CS/INT handshake per the spec
The NFC Forum NCI specification defines both a hardware and software
protocol when using a SPI physical transport to connect an NFC NCI
Chipset. The hardware requirement is that, after having raised the chip
select line, the SPI driver must wait for an INT line from the NFC
chipset to raise before it sends the data. The chip select must be
raised first though, because this is the signal that the NFC chipset
will detect to wake up and then raise its INT line. If the INT line
doesn't raise in a timely fashion, the SPI driver should abort
operation.
When data is transferred from Device host (DH) to NFC Controller (NFCC),
the signaling sequence is the following:
Data Transfer from DH to NFCC
• 1-Master asserts SPI_CSN
• 2-Slave asserts SPI_INT
• 3-Master sends NCI-over-SPI protocol header and payload data
• 4-Slave deasserts SPI_INT
• 5-Master deasserts SPI_CSN
When data must be transferred from NFCC to DH, things are a little bit
different.
Data Transfer from NFCC to DH
• 1-Slave asserts SPI_INT -> NFC chipset irq handler called -> process
reading from SPI
• 2-Master asserts SPI_CSN
• 3-Master send 2-octet NCI-over-SPI protocol header
• 4-Slave sends 2-octet NCI-over-SPI protocol payload length
• 5-Slave sends NCI-over-SPI protocol payload
• 6-Master deasserts SPI_CSN
In this case, SPI driver should function normally as it does today. Note
that the INT line can and will be lowered anytime between beginning of
step 3 and end of step 5. A low INT is therefore valid after chip select
has been raised.
This would be easily implemented in a single driver. Unfortunately, we
don't write the SPI driver and I had to imagine some workaround trick to
get the SPI and NFC drivers to work in a synchronized fashion. The trick
is the following:
- send an empty spi message: this will raise the chip select line, and
send nothing. We expect the /CS line will stay arisen because we asked
for it in the spi_transfer cs_change field
- wait for a completion, that will be completed by the NFC driver IRQ
handler when it knows we are in the process of sending data (NFC spec
says that we use SPI in a half duplex mode, so we are either sending or
receiving).
- when completed, proceed with the normal data send.
This has been tested and verified to work very consistently on a Nexus
10 (spi-s3c64xx driver). It may not work the same with other spi
drivers.
The previously defined nci_spi_ops{} whose intended purpose were to
address this problem are not used anymore and therefore totally removed.
The nci_spi_send() takes a new optional write_handshake_completion
completion pointer. If non NULL, the nci spi layer will run the above
trick when sending data to the NFC Chip. If NULL, the data is sent
normally all at once and it is then the NFC driver responsibility to
know what it's doing.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-23 23:56:43 +08:00
|
|
|
ret = __nci_spi_send(nspi, skb, 0);
|
2013-09-05 17:02:21 +08:00
|
|
|
if (ret != 0 || nspi->acknowledge_mode == NCI_SPI_CRC_DISABLED)
|
2013-05-29 21:35:03 +08:00
|
|
|
goto done;
|
|
|
|
|
|
2014-02-13 13:25:48 +08:00
|
|
|
reinit_completion(&nspi->req_completion);
|
2013-09-02 18:35:39 +08:00
|
|
|
completion_rc = wait_for_completion_interruptible_timeout(
|
2013-09-05 17:02:21 +08:00
|
|
|
&nspi->req_completion,
|
2013-09-02 18:35:39 +08:00
|
|
|
NCI_SPI_SEND_TIMEOUT);
|
2013-05-29 21:35:03 +08:00
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
if (completion_rc <= 0 || nspi->req_result == ACKNOWLEDGE_NACK)
|
2013-05-29 21:35:03 +08:00
|
|
|
ret = -EIO;
|
|
|
|
|
|
|
|
|
|
done:
|
NFC: NCI: Modify NCI SPI to implement CS/INT handshake per the spec
The NFC Forum NCI specification defines both a hardware and software
protocol when using a SPI physical transport to connect an NFC NCI
Chipset. The hardware requirement is that, after having raised the chip
select line, the SPI driver must wait for an INT line from the NFC
chipset to raise before it sends the data. The chip select must be
raised first though, because this is the signal that the NFC chipset
will detect to wake up and then raise its INT line. If the INT line
doesn't raise in a timely fashion, the SPI driver should abort
operation.
When data is transferred from Device host (DH) to NFC Controller (NFCC),
the signaling sequence is the following:
Data Transfer from DH to NFCC
• 1-Master asserts SPI_CSN
• 2-Slave asserts SPI_INT
• 3-Master sends NCI-over-SPI protocol header and payload data
• 4-Slave deasserts SPI_INT
• 5-Master deasserts SPI_CSN
When data must be transferred from NFCC to DH, things are a little bit
different.
Data Transfer from NFCC to DH
• 1-Slave asserts SPI_INT -> NFC chipset irq handler called -> process
reading from SPI
• 2-Master asserts SPI_CSN
• 3-Master send 2-octet NCI-over-SPI protocol header
• 4-Slave sends 2-octet NCI-over-SPI protocol payload length
• 5-Slave sends NCI-over-SPI protocol payload
• 6-Master deasserts SPI_CSN
In this case, SPI driver should function normally as it does today. Note
that the INT line can and will be lowered anytime between beginning of
step 3 and end of step 5. A low INT is therefore valid after chip select
has been raised.
This would be easily implemented in a single driver. Unfortunately, we
don't write the SPI driver and I had to imagine some workaround trick to
get the SPI and NFC drivers to work in a synchronized fashion. The trick
is the following:
- send an empty spi message: this will raise the chip select line, and
send nothing. We expect the /CS line will stay arisen because we asked
for it in the spi_transfer cs_change field
- wait for a completion, that will be completed by the NFC driver IRQ
handler when it knows we are in the process of sending data (NFC spec
says that we use SPI in a half duplex mode, so we are either sending or
receiving).
- when completed, proceed with the normal data send.
This has been tested and verified to work very consistently on a Nexus
10 (spi-s3c64xx driver). It may not work the same with other spi
drivers.
The previously defined nci_spi_ops{} whose intended purpose were to
address this problem are not used anymore and therefore totally removed.
The nci_spi_send() takes a new optional write_handshake_completion
completion pointer. If non NULL, the nci spi layer will run the above
trick when sending data to the NFC Chip. If NULL, the data is sent
normally all at once and it is then the NFC driver responsibility to
know what it's doing.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-23 23:56:43 +08:00
|
|
|
kfree_skb(skb);
|
|
|
|
|
|
2013-05-29 21:35:03 +08:00
|
|
|
return ret;
|
2013-05-29 21:35:02 +08:00
|
|
|
}
|
2013-09-05 17:02:21 +08:00
|
|
|
EXPORT_SYMBOL_GPL(nci_spi_send);
|
2013-05-29 21:35:02 +08:00
|
|
|
|
|
|
|
|
/* ---- Interface to NCI SPI drivers ---- */
|
|
|
|
|
|
|
|
|
|
/**
|
2013-09-05 17:02:21 +08:00
|
|
|
* nci_spi_allocate_spi - allocate a new nci spi
|
2013-05-29 21:35:02 +08:00
|
|
|
*
|
|
|
|
|
* @spi: SPI device
|
2013-09-05 17:02:21 +08:00
|
|
|
* @acknowledge_mode: Acknowledge mode used by the NFC device
|
2013-05-29 21:35:02 +08:00
|
|
|
* @delay: delay between transactions in us
|
2013-09-05 17:02:21 +08:00
|
|
|
* @ndev: nci dev to send incoming nci frames to
|
2013-05-29 21:35:02 +08:00
|
|
|
*/
|
2013-09-05 17:02:21 +08:00
|
|
|
struct nci_spi *nci_spi_allocate_spi(struct spi_device *spi,
|
|
|
|
|
u8 acknowledge_mode, unsigned int delay,
|
|
|
|
|
struct nci_dev *ndev)
|
2013-05-29 21:35:02 +08:00
|
|
|
{
|
2013-09-05 17:02:21 +08:00
|
|
|
struct nci_spi *nspi;
|
2013-05-29 21:35:02 +08:00
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
nspi = devm_kzalloc(&spi->dev, sizeof(struct nci_spi), GFP_KERNEL);
|
|
|
|
|
if (!nspi)
|
2013-05-29 21:35:02 +08:00
|
|
|
return NULL;
|
|
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
nspi->acknowledge_mode = acknowledge_mode;
|
|
|
|
|
nspi->xfer_udelay = delay;
|
2015-10-26 17:27:43 +08:00
|
|
|
/* Use controller max SPI speed by default */
|
|
|
|
|
nspi->xfer_speed_hz = 0;
|
2013-09-19 22:52:06 +08:00
|
|
|
nspi->spi = spi;
|
2013-09-05 17:02:21 +08:00
|
|
|
nspi->ndev = ndev;
|
2014-02-13 13:25:48 +08:00
|
|
|
init_completion(&nspi->req_completion);
|
2013-05-29 21:35:02 +08:00
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
return nspi;
|
2013-05-29 21:35:02 +08:00
|
|
|
}
|
2013-09-05 17:02:21 +08:00
|
|
|
EXPORT_SYMBOL_GPL(nci_spi_allocate_spi);
|
2013-05-29 21:35:04 +08:00
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
static int send_acknowledge(struct nci_spi *nspi, u8 acknowledge)
|
2013-05-29 21:35:04 +08:00
|
|
|
{
|
|
|
|
|
struct sk_buff *skb;
|
|
|
|
|
unsigned char *hdr;
|
|
|
|
|
u16 crc;
|
|
|
|
|
int ret;
|
|
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
skb = nci_skb_alloc(nspi->ndev, 0, GFP_KERNEL);
|
2013-05-29 21:35:04 +08:00
|
|
|
|
|
|
|
|
/* add the NCI SPI header to the start of the buffer */
|
|
|
|
|
hdr = skb_push(skb, NCI_SPI_HDR_LEN);
|
|
|
|
|
hdr[0] = NCI_SPI_DIRECT_WRITE;
|
|
|
|
|
hdr[1] = NCI_SPI_CRC_ENABLED;
|
|
|
|
|
hdr[2] = acknowledge << NCI_SPI_ACK_SHIFT;
|
|
|
|
|
hdr[3] = 0;
|
|
|
|
|
|
|
|
|
|
crc = crc_ccitt(CRC_INIT, skb->data, skb->len);
|
networking: add and use skb_put_u8()
Joe and Bjørn suggested that it'd be nicer to not have the
cast in the fairly common case of doing
*(u8 *)skb_put(skb, 1) = c;
Add skb_put_u8() for this case, and use it across the code,
using the following spatch:
@@
expression SKB, C, S;
typedef u8;
identifier fn = {skb_put};
fresh identifier fn2 = fn ## "_u8";
@@
- *(u8 *)fn(SKB, S) = C;
+ fn2(SKB, C);
Note that due to the "S", the spatch isn't perfect, it should
have checked that S is 1, but there's also places that use a
sizeof expression like sizeof(var) or sizeof(u8) etc. Turns
out that nobody ever did something like
*(u8 *)skb_put(skb, 2) = c;
which would be wrong anyway since the second byte wouldn't be
initialized.
Suggested-by: Joe Perches <joe@perches.com>
Suggested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 20:29:24 +08:00
|
|
|
skb_put_u8(skb, crc >> 8);
|
|
|
|
|
skb_put_u8(skb, crc & 0xFF);
|
2013-05-29 21:35:04 +08:00
|
|
|
|
NFC: NCI: Modify NCI SPI to implement CS/INT handshake per the spec
The NFC Forum NCI specification defines both a hardware and software
protocol when using a SPI physical transport to connect an NFC NCI
Chipset. The hardware requirement is that, after having raised the chip
select line, the SPI driver must wait for an INT line from the NFC
chipset to raise before it sends the data. The chip select must be
raised first though, because this is the signal that the NFC chipset
will detect to wake up and then raise its INT line. If the INT line
doesn't raise in a timely fashion, the SPI driver should abort
operation.
When data is transferred from Device host (DH) to NFC Controller (NFCC),
the signaling sequence is the following:
Data Transfer from DH to NFCC
• 1-Master asserts SPI_CSN
• 2-Slave asserts SPI_INT
• 3-Master sends NCI-over-SPI protocol header and payload data
• 4-Slave deasserts SPI_INT
• 5-Master deasserts SPI_CSN
When data must be transferred from NFCC to DH, things are a little bit
different.
Data Transfer from NFCC to DH
• 1-Slave asserts SPI_INT -> NFC chipset irq handler called -> process
reading from SPI
• 2-Master asserts SPI_CSN
• 3-Master send 2-octet NCI-over-SPI protocol header
• 4-Slave sends 2-octet NCI-over-SPI protocol payload length
• 5-Slave sends NCI-over-SPI protocol payload
• 6-Master deasserts SPI_CSN
In this case, SPI driver should function normally as it does today. Note
that the INT line can and will be lowered anytime between beginning of
step 3 and end of step 5. A low INT is therefore valid after chip select
has been raised.
This would be easily implemented in a single driver. Unfortunately, we
don't write the SPI driver and I had to imagine some workaround trick to
get the SPI and NFC drivers to work in a synchronized fashion. The trick
is the following:
- send an empty spi message: this will raise the chip select line, and
send nothing. We expect the /CS line will stay arisen because we asked
for it in the spi_transfer cs_change field
- wait for a completion, that will be completed by the NFC driver IRQ
handler when it knows we are in the process of sending data (NFC spec
says that we use SPI in a half duplex mode, so we are either sending or
receiving).
- when completed, proceed with the normal data send.
This has been tested and verified to work very consistently on a Nexus
10 (spi-s3c64xx driver). It may not work the same with other spi
drivers.
The previously defined nci_spi_ops{} whose intended purpose were to
address this problem are not used anymore and therefore totally removed.
The nci_spi_send() takes a new optional write_handshake_completion
completion pointer. If non NULL, the nci spi layer will run the above
trick when sending data to the NFC Chip. If NULL, the data is sent
normally all at once and it is then the NFC driver responsibility to
know what it's doing.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-23 23:56:43 +08:00
|
|
|
ret = __nci_spi_send(nspi, skb, 0);
|
2013-05-29 21:35:04 +08:00
|
|
|
|
|
|
|
|
kfree_skb(skb);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-23 23:56:31 +08:00
|
|
|
static struct sk_buff *__nci_spi_read(struct nci_spi *nspi)
|
2013-05-29 21:35:04 +08:00
|
|
|
{
|
|
|
|
|
struct sk_buff *skb;
|
|
|
|
|
struct spi_message m;
|
|
|
|
|
unsigned char req[2], resp_hdr[2];
|
|
|
|
|
struct spi_transfer tx, rx;
|
|
|
|
|
unsigned short rx_len = 0;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
spi_message_init(&m);
|
2013-09-24 00:02:43 +08:00
|
|
|
|
|
|
|
|
memset(&tx, 0, sizeof(struct spi_transfer));
|
2013-05-29 21:35:04 +08:00
|
|
|
req[0] = NCI_SPI_DIRECT_READ;
|
2013-09-05 17:02:21 +08:00
|
|
|
req[1] = nspi->acknowledge_mode;
|
2013-05-29 21:35:04 +08:00
|
|
|
tx.tx_buf = req;
|
|
|
|
|
tx.len = 2;
|
|
|
|
|
tx.cs_change = 0;
|
2015-10-26 17:27:43 +08:00
|
|
|
tx.speed_hz = nspi->xfer_speed_hz;
|
2013-05-29 21:35:04 +08:00
|
|
|
spi_message_add_tail(&tx, &m);
|
2013-09-24 00:02:43 +08:00
|
|
|
|
|
|
|
|
memset(&rx, 0, sizeof(struct spi_transfer));
|
2013-05-29 21:35:04 +08:00
|
|
|
rx.rx_buf = resp_hdr;
|
|
|
|
|
rx.len = 2;
|
|
|
|
|
rx.cs_change = 1;
|
2015-10-26 17:27:43 +08:00
|
|
|
rx.speed_hz = nspi->xfer_speed_hz;
|
2013-05-29 21:35:04 +08:00
|
|
|
spi_message_add_tail(&rx, &m);
|
2013-09-24 00:02:43 +08:00
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
ret = spi_sync(nspi->spi, &m);
|
2013-05-29 21:35:04 +08:00
|
|
|
if (ret)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
if (nspi->acknowledge_mode == NCI_SPI_CRC_ENABLED)
|
2013-05-29 21:35:04 +08:00
|
|
|
rx_len = ((resp_hdr[0] & NCI_SPI_MSB_PAYLOAD_MASK) << 8) +
|
|
|
|
|
resp_hdr[1] + NCI_SPI_CRC_LEN;
|
|
|
|
|
else
|
|
|
|
|
rx_len = (resp_hdr[0] << 8) | resp_hdr[1];
|
|
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
skb = nci_skb_alloc(nspi->ndev, rx_len, GFP_KERNEL);
|
2013-05-29 21:35:04 +08:00
|
|
|
if (!skb)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
spi_message_init(&m);
|
2013-09-24 00:02:43 +08:00
|
|
|
|
|
|
|
|
memset(&rx, 0, sizeof(struct spi_transfer));
|
2013-05-29 21:35:04 +08:00
|
|
|
rx.rx_buf = skb_put(skb, rx_len);
|
|
|
|
|
rx.len = rx_len;
|
|
|
|
|
rx.cs_change = 0;
|
2019-12-04 15:58:09 +08:00
|
|
|
rx.delay.value = nspi->xfer_udelay;
|
|
|
|
|
rx.delay.unit = SPI_DELAY_UNIT_USECS;
|
2015-10-26 17:27:43 +08:00
|
|
|
rx.speed_hz = nspi->xfer_speed_hz;
|
2013-05-29 21:35:04 +08:00
|
|
|
spi_message_add_tail(&rx, &m);
|
2013-09-24 00:02:43 +08:00
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
ret = spi_sync(nspi->spi, &m);
|
2013-05-29 21:35:04 +08:00
|
|
|
if (ret)
|
|
|
|
|
goto receive_error;
|
|
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
if (nspi->acknowledge_mode == NCI_SPI_CRC_ENABLED) {
|
networking: make skb_push & __skb_push return void pointers
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.
Make these functions return void * and remove all the casts across
the tree, adding a (u8 *) cast only where the unsigned char pointer
was used directly, all done with the following spatch:
@@
expression SKB, LEN;
typedef u8;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- *(fn(SKB, LEN))
+ *(u8 *)fn(SKB, LEN)
@@
expression E, SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
type T;
@@
- E = ((T *)(fn(SKB, LEN)))
+ E = fn(SKB, LEN)
@@
expression SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- fn(SKB, LEN)[0]
+ *(u8 *)fn(SKB, LEN)
Note that the last part there converts from push(...)[0] to the
more idiomatic *(u8 *)push(...).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 20:29:23 +08:00
|
|
|
*(u8 *)skb_push(skb, 1) = resp_hdr[1];
|
|
|
|
|
*(u8 *)skb_push(skb, 1) = resp_hdr[0];
|
2013-05-29 21:35:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return skb;
|
|
|
|
|
|
|
|
|
|
receive_error:
|
|
|
|
|
kfree_skb(skb);
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int nci_spi_check_crc(struct sk_buff *skb)
|
|
|
|
|
{
|
|
|
|
|
u16 crc_data = (skb->data[skb->len - 2] << 8) |
|
|
|
|
|
skb->data[skb->len - 1];
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
ret = (crc_ccitt(CRC_INIT, skb->data, skb->len - NCI_SPI_CRC_LEN)
|
|
|
|
|
== crc_data);
|
|
|
|
|
|
|
|
|
|
skb_trim(skb, skb->len - NCI_SPI_CRC_LEN);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static u8 nci_spi_get_ack(struct sk_buff *skb)
|
|
|
|
|
{
|
|
|
|
|
u8 ret;
|
|
|
|
|
|
|
|
|
|
ret = skb->data[0] >> NCI_SPI_ACK_SHIFT;
|
|
|
|
|
|
|
|
|
|
/* Remove NFCC part of the header: ACK, NACK and MSB payload len */
|
|
|
|
|
skb_pull(skb, 2);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2013-09-23 23:56:31 +08:00
|
|
|
* nci_spi_read - read frame from NCI SPI drivers
|
2013-05-29 21:35:04 +08:00
|
|
|
*
|
2013-09-05 17:02:21 +08:00
|
|
|
* @nspi: The nci spi
|
2013-05-29 21:35:04 +08:00
|
|
|
* Context: can sleep
|
|
|
|
|
*
|
|
|
|
|
* This call may only be used from a context that may sleep. The sleep
|
|
|
|
|
* is non-interruptible, and has no timeout.
|
|
|
|
|
*
|
2013-09-23 23:56:31 +08:00
|
|
|
* It returns an allocated skb containing the frame on success, or NULL.
|
2013-05-29 21:35:04 +08:00
|
|
|
*/
|
2013-09-23 23:56:31 +08:00
|
|
|
struct sk_buff *nci_spi_read(struct nci_spi *nspi)
|
2013-05-29 21:35:04 +08:00
|
|
|
{
|
|
|
|
|
struct sk_buff *skb;
|
|
|
|
|
|
|
|
|
|
/* Retrieve frame from SPI */
|
2013-09-23 23:56:31 +08:00
|
|
|
skb = __nci_spi_read(nspi);
|
|
|
|
|
if (!skb)
|
2013-05-29 21:35:04 +08:00
|
|
|
goto done;
|
|
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
if (nspi->acknowledge_mode == NCI_SPI_CRC_ENABLED) {
|
2013-05-29 21:35:04 +08:00
|
|
|
if (!nci_spi_check_crc(skb)) {
|
2013-09-05 17:02:21 +08:00
|
|
|
send_acknowledge(nspi, ACKNOWLEDGE_NACK);
|
2013-05-29 21:35:04 +08:00
|
|
|
goto done;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* In case of acknowledged mode: if ACK or NACK received,
|
|
|
|
|
* unblock completion of latest frame sent.
|
|
|
|
|
*/
|
2013-09-05 17:02:21 +08:00
|
|
|
nspi->req_result = nci_spi_get_ack(skb);
|
|
|
|
|
if (nspi->req_result)
|
|
|
|
|
complete(&nspi->req_completion);
|
2013-05-29 21:35:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If there is no payload (ACK/NACK only frame),
|
|
|
|
|
* free the socket buffer
|
|
|
|
|
*/
|
2013-09-23 23:56:31 +08:00
|
|
|
if (!skb->len) {
|
2013-05-29 21:35:04 +08:00
|
|
|
kfree_skb(skb);
|
2013-09-23 23:56:31 +08:00
|
|
|
skb = NULL;
|
2013-05-29 21:35:04 +08:00
|
|
|
goto done;
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-05 17:02:21 +08:00
|
|
|
if (nspi->acknowledge_mode == NCI_SPI_CRC_ENABLED)
|
|
|
|
|
send_acknowledge(nspi, ACKNOWLEDGE_ACK);
|
2013-05-29 21:35:04 +08:00
|
|
|
|
|
|
|
|
done:
|
|
|
|
|
|
2013-09-23 23:56:31 +08:00
|
|
|
return skb;
|
2013-05-29 21:35:04 +08:00
|
|
|
}
|
2013-09-23 23:56:31 +08:00
|
|
|
EXPORT_SYMBOL_GPL(nci_spi_read);
|
2015-10-26 17:27:42 +08:00
|
|
|
|
|
|
|
|
MODULE_LICENSE("GPL");
|