- 02 12月, 2014 4 次提交
-
-
由 Christophe Ricard 提交于
Some NFC controller using NCI protocols may need a proprietary commands flow to disable a secure element Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
Some NFC controller using NCI protocols may need a proprietary commands flow to enable a secure element Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
NFC: nci: Update nci_discover_se to run proprietary commands to discover all available secure element Some NFC controller using NCI protocols may need a proprietary commands flow to discover all available secure element Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
Fix sparse warning introduced by commit: 9e87f9a9 It was generating the following warning: net/nfc/nci/ntf.c:170:7: sparse: symbol 'nci_get_prop_rf_protocol' was not declared. Should it be static? Procedure to reproduce it: # apt-get install sparse git checkout 9e87f9a9 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ Signed-off-by: NFengguang Wu <fengguang.wu@intel.com> Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 28 11月, 2014 8 次提交
-
-
由 Julien Lefrique 提交于
Before signaling the deactivation, send a deactivation request if in RFST_DISCOVERY state because neard assumes polling is stopped and will try to restart it. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
When the deactivation type reported by RF_DEACTIVATE_NTF is Discovery, go in RFST_DISCOVERY state. The NFCC stays in Poll mode and/or Listen mode. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
As specified in NCI 1.0 and NCI 1.1, when using the NFC-DEP RF Interface, the DH and the NFCC shall only use the Static RF Connection for data communication with a Remote NFC Endpoint. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
The Target responds to the ATR_REQ with the ATR_RES. Configure the General Bytes in ATR_RES with the first three octets equal to the NFC Forum LLCP magic number, followed by some LLC Parameters TLVs described in section 4.5 of [LLCP]. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
Changes: * Extract the Listen mode activation parameters from RF_INTF_ACTIVATED_NTF. * Store the General Bytes of ATR_REQ. * Signal that Target mode is activated in case of an activation in NFC-DEP. * Update the NCI state accordingly. * Use the various constants defined in nfc.h. * Fix the ATR_REQ and ATR_RES maximum size. As per NCI 1.0 and NCI 1.1, the Activation Parameters for both Poll and Listen mode contain all the bytes of ATR_REQ/ATR_RES starting and including Byte 3 as defined in [DIGITAL]. In [DIGITAL], the maximum size of ATR_REQ/ATR_RES is 64 bytes and they are numbered starting from Byte 1. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
Send LA_SEL_INFO and LF_PROTOCOL_TYPE with NFC-DEP protocol enabled. Configure 212 Kbit/s and 412 Kbit/s bit rates for Listen F. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
The Target mode protocols are given to the nci_start_poll() function but were previously ignored. To enable P2P Target, when NFC-DEP is requested as a Target mode protocol, add NFC-A and NFC-F Passive Listen modes in RF_DISCOVER_CMD command. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 24 9月, 2014 1 次提交
-
-
由 Christophe Ricard 提交于
In NFC Forum NCI specification, some RF Protocol values are reserved for proprietary use (from 0x80 to 0xfe). Some CLF vendor may need to use one value within this range for specific technology. Furthermore, some CLF may not becompliant with NFC Froum NCI specification 2.0 and therefore will not support RF Protocol value 0x06 for PROTOCOL_T5T as mention in a draft specification and in a recent push. Adding get_rf_protocol handle to the nci_ops structure will help to set the correct technology to target. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 01 9月, 2014 3 次提交
-
-
由 Vincent Cuissard 提交于
NCI RF FRAME interface is used for all kind of tags except ISODEP ones. So for all other kind of tags the status byte has to be removed. Signed-off-by: NVincent Cuissard <cuissard@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Vincent Cuissard 提交于
All contexts have to be initiliazed before calling nfc_register_device otherwise it is possible to call nci_dev_up before ending the nci_register_device function. In such case kernel will crash on non initialized variables. Signed-off-by: NVincent Cuissard <cuissard@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Vincent Cuissard 提交于
Update nci.h to respect latest NCI specification proposal (stop using proprietary opcodes). Handle ISO15693 parameters in NCI_RF_ACTIVATED_NTF handler. Signed-off-by: NVincent Cuissard <cuissard@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 23 7月, 2014 1 次提交
-
-
由 Christophe Ricard 提交于
Add T1T matching with Jewel during notification. It was causing "the target found does not have the desired protocol" to show up. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 20 5月, 2014 2 次提交
-
-
由 Hiren Tandel 提交于
So that anyone listening on SOCKPROTO_RAW for raw frames will get all NCI frames, in both directions. This actually implements userspace NFC NCI sniffing. It's now up to userspace to decode those frames. Signed-off-by: NHiren Tandel <hirent@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Hiren Tandel 提交于
ATR_RES response received within Activation Parameters is already in correct order. Reversing it fails LLCP magic number check and so P2P functionality fails. Signed-off-by: NHiren Tandel <hirent@marvell.com> Signed-off-by: NRahul Tank <rahult@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 24 2月, 2014 2 次提交
-
-
由 Axel Lin 提交于
Calling init_completion() once is enough. Then use reinit_completion() instead in __nci_request() and nci_spi_send(). Signed-off-by: NAxel Lin <axel.lin@ingics.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Amitkumar Karwar 提交于
The check should be for setup function pointer. This patch fixes NULL pointer dereference issue for NCI based NFC driver which doesn't define setup handler. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 07 1月, 2014 3 次提交
-
-
由 Amitkumar Karwar 提交于
This API can be used by drivers to send their custom configuration using SET_CONFIG NCI command to the device. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Amitkumar Karwar 提交于
Some drivers require special configuration while initializing. This patch adds setup handler for this custom configuration. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Amitkumar Karwar 提交于
Local general bytes returned by nfc_get_local_general_bytes() are already in correct order. We don't need to reverse them. Remove local_gb[] local array as it's not needed any more. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 06 1月, 2014 1 次提交
-
-
由 Amitkumar Karwar 提交于
nci_close_device() sends nci reset command to the device. If there is no response for this command, nci request timeout occurs first and then cmd timeout happens. Because command timer has started after sending the command. We are immediately flushing command workqueue after nci timeout. Later we will try to schedule cmd_work in command timer which leads to a crash. Cancel cmd_timer before flushing the workqueue to fix the problem. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 11 12月, 2013 1 次提交
-
-
由 Jeff Kirsher 提交于
Several files refer to an old address for the Free Software Foundation in the file header comment. Resolve by replacing the address with the URL <http://www.gnu.org/licenses/> so that we do not have to keep updating the header comments anytime the address changes. CC: linux-wireless@vger.kernel.org CC: Lauro Ramos Venancio <lauro.venancio@openbossa.org> CC: Aloisio Almeida Jr <aloisio.almeida@openbossa.org> CC: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 25 9月, 2013 7 次提交
-
-
由 Eric Lapuyade 提交于
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: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Eric Lapuyade 提交于
Previously, nci_spi_recv_frame() would directly transmit incoming frames to the NCI Core. However, it turns out that some NFC NCI Chips will add additional proprietary headers that must be handled/removed before NCI Core gets a chance to handle the frame. With this modification, the chip phy or driver are now responsible to transmit incoming frames to NCI Core after proper treatment, and NCI SPI becomes a driver helper instead of sitting between the NFC driver and NCI Core. As a general rule in NFC, *_recv_frame() APIs are used to deliver an incoming frame to an upper layer. To better suit the actual purpose of nci_spi_recv_frame(), and go along with its nci_spi_send() counterpart, the function is renamed to nci_spi_read() The skb is returned as the function result Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Eric Lapuyade 提交于
Using ARM compiler, and without zero-ing spi_transfer, spi-s3c64xx driver would issue abnormal errors due to bpw field value being set to unexpected value. This structure MUST be set to all zeros except for those field specifically used. Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Eric Lapuyade 提交于
Storing the spi device was forgotten in the original implementation, which would pretty obviously cause some kind of serious crash when actually trying to send something through that device. Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Eric Lapuyade 提交于
NCI SPI layer should not manage the nci dev, this is the job of the nci chipset driver. This layer should be limited to frame/deframe nci packets, and optionnaly check integrity (crc) and manage the ack/nak protocol. The NCI SPI must not be mixed up with an NCI dev. spi_[dev|device] are therefore renamed to a simple spi for more clarity. The header and crc sizes are moved to nci.h so that drivers can use them to reserve space in outgoing skbs. nci_spi_send() is exported to be accessible by drivers. Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Eric Lapuyade 提交于
An hci dev is an hdev. An nci dev is an ndev. Calling an nci spi dev an ndev is misleading since it's not the same thing. The nci dev contained in the nci spi dev is also named inconsistently. Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Eric Lapuyade 提交于
Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 19 7月, 2013 1 次提交
-
-
由 Frederic Danis 提交于
kbuild test robot found following error: net/built-in.o: In function `nci_spi_send': >> spi.c:(.text+0x19a76f): undefined reference to `crc_ccitt' Add CRC_CCITT module to Kconfig to fix it Reported-by: kbuild test robot. Signed-off-by: NFrederic Danis <frederic.danis@linux.intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 14 6月, 2013 6 次提交
-
-
由 Samuel Ortiz 提交于
Secure elements need to be discovered after enabling the NFC controller. This is typically done by the NCI core and the HCI drivers (HCI does not specify how to discover SEs, it is left to the specific drivers). Also, the SE enable/disable API explicitely takes a SE index as its argument. Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Samuel Ortiz 提交于
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>
-
由 Frederic Danis 提交于
Before any operation, driver interruption is de-asserted to prevent race condition between TX and RX. Transaction starts by emitting "Direct read" and acknowledged mode bytes. Then packet length is read allowing to allocate correct NCI socket buffer. After that payload is retrieved. A delay after the transaction can be added. This delay is determined by the driver during nci_spi_allocate_device() call and can be 0. If acknowledged mode is set: - CRC of header and payload is checked - if frame reception fails (CRC error): NACK is sent - if received frame has ACK or NACK flag: unblock nci_spi_send() Payload is passed to NCI module. At the end, driver interruption is re asserted. Signed-off-by: NFrederic Danis <frederic.danis@linux.intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Frederic Danis 提交于
Before any operation, driver interruption is de-asserted to prevent race condition between TX and RX. The NCI over SPI header is added in front of NCI packet. If acknowledged mode is set, CRC-16-CCITT is added to the packet. Then the packet is forwarded to SPI module to be sent. A delay after the transaction is added. This delay is determined by the driver during nci_spi_allocate_device() call and can be 0. After data has been sent, driver interruption is re-asserted. If acknowledged mode is set, nci_spi_send will block until acknowledgment is received. Signed-off-by: NFrederic Danis <frederic.danis@linux.intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Frederic Danis 提交于
The NFC Forum defines a transport interface based on Serial Peripheral Interface (SPI) for the NFC Controller Interface (NCI). This module implements the SPI transport of NCI, calling SPI module directly to read/write data to NFC controller (NFCC). NFCC driver should provide functions performing device open and close. It should also provide functions asserting/de-asserting interruption to prevent TX/RX race conditions. NFCC driver can also fix a delay between transactions if needed by the hardware. Signed-off-by: NFrederic Danis <frederic.danis@linux.intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Frederic Danis 提交于
skb->dev is used for carrying a net_device pointer and not an nci_dev pointer. Remove usage of skb-dev to carry nci_dev and replace it by parameter in nci_recv_frame(), nci_send_frame() and driver send() functions. NfcWilink driver is also updated to use those functions. Signed-off-by: NFrederic Danis <frederic.danis@linux.intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-