user/sven/linux.git/drivers/nfc, branch v3.18.67

NFC: st21nfcb: remove st21nfcb_nci_i2c_disable

2015-07-04T03:02:25Z

[ Upstream commit 4ac82e894825126816d7b7f662743335ce2b015e ] ndlc_remove already calls st21nfcb_nci_i2c_disable and phy->powered is already set to 0. Cc: stable@vger.kernel.org Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz Signed-off-by: Sasha Levin

NFC: st21nfcb: Do not remove header once the payload is sent

2015-07-04T03:02:25Z

[ Upstream commit 09f39a950523b1bb830c30a8670b77e0067da092 ] Once the data is sent, we need to preserve the full frame for the ndlc state machine. If the NDLC ACK is not received in time, the ndlc layer will resend the same frame. Having the header byte pulled will corrupt the frame. Cc: stable@vger.kernel.org Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz Signed-off-by: Sasha Levin

NFC: st21nfcb: Remove inappropriate kfree on a devm_kzalloc pointer

2015-07-04T03:02:25Z

[ Upstream commit 38bd83f04c5e9695011dc5c294e0c4e6a9f9052d ] Since ndev->driver_data is allocated by devm_kzalloc(), we do not need the inappropriate kfree to free it in driver's remove function. Freeing will trigger when driver unloads. Cc: stable@vger.kernel.org Acked-by: Christophe Ricard Signed-off-by: Firo Yang Signed-off-by: Samuel Ortiz Signed-off-by: Sasha Levin

NFC: st21nfcb: Retry i2c_master_send if it returns a negative value

2015-05-17T23:12:06Z

[ Upstream commit d4a41d10b2cb5890aeda6b2912973b2a754b05b1 ] i2c_master_send may return many negative values different than -EREMOTEIO. In case an i2c transaction is NACK'ed, on raspberry pi B+ kernel 3.18, -EIO is generated instead. Cc: stable@vger.kernel.org Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz Signed-off-by: Sasha Levin

Merge tag 'master-2014-10-02' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next

2014-10-06T01:34:39Z

John W. Linville says: ==================== pull request: wireless-next 2014-10-03 Please pull tihs batch of updates intended for the 3.18 stream! For the iwlwifi bits, Emmanuel says: "I have here a few things that depend on the latest mac80211's changes: RRM, TPC, Quiet Period etc... Eyal keeps improving our rate control and we have a new device ID. This last patch should probably have gone to wireless.git, but at that stage, I preferred to send it to -next and CC stable." For (most of) the Atheros bits, Kalle says: "The only new feature is testmode support from me. Ben added a new method to crash the firmware with an assert for debug purposes. As usual, we have lots of smaller fixes from Michal. Matteo fixed a Kconfig dependency with debugfs. I fixed some warnings recently added to checkpatch." For the NFC bits, Samuel says: "We've had major updates for TI and ST Microelectronics drivers, and a few NCI related changes. For TI's trf7970a driver: - Target mode support for trf7970a - Suspend/resume support for trf7970a - DT properties additions to handle different quirks - A bunch of fixes for smartphone IOP related issues For ST Microelectronics' ST21NFCA and ST21NFCB drivers: - ISO15693 support for st21nfcb - checkpatch and sparse related warning fixes - Code cleanups and a few minor fixes Finally, Marvell added ISO15693 support to the NCI stack, together with a couple of NCI fixes." For the Bluetooth bits, Johan says: "This 3.18 pull request replaces the one I did on Monday ("bluetooth-next 2014-09-22", which hasn't been pulled yet). The additions since the last request are: - SCO connection fix for devices not supporting eSCO - Cleanups regarding the SCO establishment logic - Remove unnecessary return value from logging functions - Header compression fix for 6lowpan - Cleanups to the ieee802154/mrf24j40 driver Here's a copy from previous request that this one replaces: ' Here are some more patches for 3.18. They include various fixes to the btusb HCI driver, a fix for LE SMP, as well as adding Jukka to the MAINTAINERS file for generic 6LoWPAN (as requested by Alexander Aring). I've held on to this pull request a bit since we were waiting for a SCO related fix to get sorted out first. However, since the merge window is getting closer I decided not to wait for it. If we do get the fix sorted out there'll probably be a second small pull request later this week. '" And, "Unless 3.17 gets delayed this will probably be our last -next pull request for 3.18. We've got: - New Marvell hardware supportr - Multicast support for 6lowpan - Several of 6lowpan fixes & cleanups - Fix for a (false-positive) lockdep warning in L2CAP - Minor btusb cleanup" On top of all that comes the usual sort of updates to ath5k, ath9k, ath10k, brcmfmac, mwifiex, and wil6210. This time around there are also a number of rtlwifi updates to enable some new hardware and to reconcile the in-kernel drivers with some newer releases of the Realtek vendor drivers. Also of note is some device tree work for the bcma bus. Please let me know if there are problems! ==================== Signed-off-by: David S. Miller

NFC: st21nfca: Fix potential double kfree_skb error

2014-09-24T00:02:24Z

skb is already freed in st21nfca_tx_work and was freed also in st21nfca_im_send_psl_req. Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz

NFC: st21nfca: ERR_PTR vs NULL fix

2014-09-24T00:02:24Z

"skb" can be NULL here but it can't be an ERR_PTR: - IS_ERR(NULL) return false and skb migth be NULL. - skb cannot be a ERR_PTR as nfc_hci_send_cmd_async it never using such cast. !skb is more appropriate at those places. Reported-by: Dan Carpenter Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz

NFC: st21nfcb: remove error output

2014-09-24T00:02:24Z

In case we are not able to read out the NDLC/NCI header, we do not consider this as an issue and we will give a later chance. The NDLC layer will handle errors thanks to its internal timers. Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz

NFC: st21nfcb: Add ISO15693 Reader/Writer support

2014-09-24T00:02:24Z

Add support for ISO/IEC 15693 RF technology and Type 5 tags. Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz

NFC: nci: Add support for proprietary RF Protocols

2014-09-24T00:02:24Z

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: Christophe Ricard Signed-off-by: Samuel Ortiz