- 14 Jun, 2013 24 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-nextJohn W. Linville authored
Samuel Ortiz <sameo@linux.intel.com> says: "These are the pending NFC patches for the 3.11 merge window. It contains the pending fixes that were on nfc-fixes (nfc-fixes-3.10-2), along with a few more for the pn544 and pn533 drivers, the LLCP disconnection path and an LLCP memory leak. Highlights for this one are: - An initial secure element API. NFC chipsets can carry an embedded secure element or get access to the SIM one. In both cases they control the secure elements and this API provides a way to discover, enable and disable the available SEs. It also exports that to userspace in order for SE focused middleware to actually do something with them (e.g. payments). - NCI over SPI support. SPI is the most complex NCI specified transport layer and we now have support for it in the kernel. The next step will be to implement drivers for NCI chipsets using this transport like e.g. bcm2079x. - NFC p2p hardware simulation driver. We now have an nfcsim driver that is mostly a loopback device between 2 NFC interfaces. It also implements the rest of the NFC core API like polling and target detection. This driver, with neard running on top of it, allows us to completely test the LLCP, SNEP and Handover implementation without physical hardware. - A Firmware update netlink API. Most (All ?) HCI chipsets have a special firmware update mode where applications can push a new firmware that will be flashed. We now have a netlink API for providing that mode to e.g. nfctool." Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Valentin Ilie authored
Fix checkpatch warnings. Replace __attribute__((__packed__)) with __packed. Replace spaces with tabs. Signed-off-by: Valentin Ilie <valentin.ilie@gmail.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
The WKS (Well Known Services) bitmask should be transmitted in big endian order. Picky implementations will refuse to establish an LLCP link when the WKS bit 0 is not set to 1. The vast majority of implementations out there are not that picky though... Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
In order to advertise our LLCP support properly and to follow the LLCP specs requirements, we need to initialize the WKS (Well-Known Services) bitfield to 1 as SAP 0 is the only mandatory supported service. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
When we receive a RNR, the remote is busy processing the last received frame. We set a local flag for that, and we should send a SYMM when it is set instead of sending any pending frame. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
Without the new LLCP_CONNECTING state, non blocking sockets will be woken up with a POLLHUP right after calling connect() because their state is stuck at LLCP_CLOSED. That prevents userspace from implementing any proper non blocking socket based NFC p2p client. Cc: stable@vger.kernel.org Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Thierry Escande authored
This driver declares two virtual NFC devices supporting NFC-DEP protocol. An LLCP connection can be established between them and all packets sent from one device is sent back to the other, acting as loopback devices. Once established, the LLCP link can be disconnected by disabling the target device (with rfkill, nfctool, or neard disable-adapter test script). Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Thierry Escande authored
In nfc_llcp_tx_work() the sk_buff is not freed when the llcp_sock is null and the PDU is an I one. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Thierry Escande authored
This patch keeps the socket alive and therefore does not remove it from the sockets list in the local until the DISC PDU has been actually sent. Otherwise we would reply with DM PDUs before sending the DISC one. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Thierry Escande authored
nfc_llcp_send_disconnect() already exists but is not used. nfc_llcp_disconnect() naming is not consistent with other PDU sending functions. This patch removes nfc_llcp_send_disconnect() and renames nfc_llcp_disconnect() Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Olivier Guiter authored
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: Olivier Guiter <olivier.guiter@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
Enabling or disabling an NFC accessible secure element through netlink requires giving both an NFC controller and a secure element indexes. Once enabled the secure element will handle card emulation once polling starts. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
Called via netlink, this API will enable or disable a specific secure element. When a secure element is enabled, it will handle card emulation and more generically ISO-DEP target mode, i.e. all target mode cases except for p2p target mode. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
When an NFC driver or host controller stack discovers a secure element, it will call nfc_add_se(). In order for userspace applications to use these secure elements, a netlink event will then be sent with the SE index and its type. With that information userspace applications can decide wether or not to enable SEs, through their indexes. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
This API will allow NFC drivers to add and remove the secure elements they know about or detect. Typically this should be called (asynchronously or not) from the driver or the host interface stack detect_se hook. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
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: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
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: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
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: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
LLCP validation requires TSN to be 0x03 for type F. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Frederic Danis authored
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: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Frederic Danis authored
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: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Frederic Danis authored
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: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
- 13 Jun, 2013 16 commits
-
-
Samuel Ortiz authored
Exiting on the error case is more typical to the kernel coding style. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Eric Lapuyade authored
This is a simple forward to the HCI driver. When driver is done with the operation, it shall directly notify NFC Core by calling nfc_fw_upload_done(). Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Eric Lapuyade authored
As several NFC chipsets can have their firmwares upgraded and reflashed, this patchset adds a new netlink command to trigger that the driver loads or flashes a new firmware. This will allows userspace triggered firmware upgrade through netlink. The firmware name or hint is passed as a parameter, and the driver will eventually fetch the firmware binary through the request_firmware API. The cmd can only be executed when the nfc dev is not in use. Actual firmware loading/flashing is an asynchronous operation. Result of the operation shall send a new event up to user space through the nfc dev multicast socket. During operation, the nfc dev is not openable and thus not usable. Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Frederic Danis authored
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: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Wei Yongjun authored
Fix to return -ENOMEM in the nfc device alloc error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Arron Wang authored
There is no builtin command for driver to check the presence of Felica and Jewel device, it is more reasonable for the userspace daemon neard to build seperate commands to check the presence of the card. Signed-off-by: Arron Wang <arron.wang@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Arron Wang authored
NFCID2 is defined as the first 2 manufacturer ID (IDm) bytes. NFC DEP (NFC peer to peer) devices Type-F NFCID2 must start with 0x01fe according to the NFC Digital Specification. By checking those first 2 bytes we send the right command either to the reader gate when NFCID2 != 0x1fe (The NFC tag case) or to the NFCIP1 gate when seeing an NFC DEP device (The NFC peer to peer case). Without this fix, Felica (Type F) tags are not properly detected with this driver. Signed-off-by: Arron Wang <arron.wang@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
-
-
Sujith Manoharan authored
Since raising/lowering the limits based on INI has been changed, the error limit for OFDM has to be 1000, not 3500. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
With the new rate control API, the driver can now apply the tx rate to outgoing frames just before they are uploaded to the device. This is important because the rate control can now react to fading or improving links a bit sooner. Also, the driver no longer needs to sort the outgoing frames for sample attempts (which affected the size of A-MPDUs and the throughput of the link). For aggregated data frames, the driver (and rate control) needs only to calculate and apply a single set of tx rates to every subframe of the whole aggregate. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wei Yongjun authored
Fix to return -ENOMEM in the skb alloc error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Cho, Yu-Chen authored
This patch adds support for Mediatek Bluetooth device T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.01 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0e8d ProdID=763f Rev= 1.00 S: Manufacturer=MediaTek S: Product=BT S: SerialNumber=1.0 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=450mA A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=ff Prot=ff I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Cho, Yu-Chen <acho@suse.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Emmanuel Grumbach authored
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
The fw is unreliable in all the cases in which the packet wasn't sent. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The older devices (pre-7000/3000 series) all only work with the DVM opmode due to firmware availability, while newer ones will only work with the MVM opmode for the same reason. When building a driver that only has one of MVM or DVM, there's no reason to build the device support and have the PCIe IDs for all devices since they can't be used anyway, so avoid that. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-