aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* brcmfmac: fix brcmf_sdcard_recv_chain() for host without sg supportArend van Spriel2013-10-18
| | | | | | | | | | | | If the SDIO host controller does not support scatter-gather the glom superframe must be transfered from the device and the data for each packet in the queue must be extracted from it. Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: fix brcmf_sdio_txpkt_prep() for host without sg supportArend van Spriel2013-10-18
| | | | | | | | | | | | When running on a host controller that does not support scatter-gather transfers the function brcmf_sdio_txpkt_prep() should not add tail padding buffers. Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: fix brcmf_sdcard_send_pkt() for host without sg supportArend van Spriel2013-10-18
| | | | | | | | | | | If the host does not support scatter-gather transmit the packets in the pktq individually using brcmf_sdio_buffrw(). Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: remove stale code from brcmf_sdcard_recv_chain()Arend van Spriel2013-10-18
| | | | | | | | | | | | The function brcmf_sdcard_recv_chain() has been reworked with commit "brcmfmac: add sdio sg list support", but the incr_fix variable is only assigned but not used so removing it now. Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: verify result of brcmf_sdio_addrprep() callsArend van Spriel2013-10-18
| | | | | | | | | | | Not all calls to the function brcmf_sdio_addrprep() check the return value, but it may fail so better verify it. Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: rework single packet transfersArend van Spriel2013-10-18
| | | | | | | | | | | | The function brcmf_sdio_sglist_rw() does a different code path when packet queue length is 1. Move this to a separate function reducing overhead in the calling context. Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: rename brcmf_sdio_buffrw()Arend van Spriel2013-10-18
| | | | | | | | | | | | The function brcmf_sdio_buffrw() is intended to be used for transfering list of packets using scatter-gather functionality. Rename function to brcmf_sdio_sglist_rw() to clarify this. Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: rework scatter-gather code in brcmf_sdio_buffrw()Arend van Spriel2013-10-18
| | | | | | | | | | | Moving a number of assignments outside of the loop as they are the same for each request. Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: determine host controller related variables during probeArend van Spriel2013-10-18
| | | | | | | | | | | | Instead of determining the limits for scatter-gather MMC transfer request upon each transmit it is now determined during the probe of the SDIO function. Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: rename variable max_seg_sz to max_seg_cnt for clarityArend van Spriel2013-10-18
| | | | | | | | | | | | The variable max_seg_sz in brcmf_sdio_buffrw() respresents the maximum number of buffers that can be sent in one MMC transfer request. Rename it to max_seg_cnt to avoid confusion. Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: add tracepoint for capturing the SDPCM headerArend van Spriel2013-10-18
| | | | | | | | | | | Having the SDPCM header information in the traces is a valuable piece of information. Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: store address in trace_brcmf_hexdump()Arend van Spriel2013-10-18
| | | | | | | | | | The trace function trace_brcmf_hexdump() stores the length, but having the address of the buffer being dumped helps putting it in context. Reviewed-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: add TX99 supportLuis R. Rodriguez2013-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TX99 support enables Specific Absorption Rate (SAR) testing. SAR is the unit of measurement for the amount of radio frequency(RF) absorbed by the body when using a wireless device. The RF exposure limits used are expressed in the terms of SAR, which is a measure of the electric and magnetic field strength and power density for transmitters operating at frequencies from 300 kHz to 100 GHz. Regulatory bodies around the world require that wireless device be evaluated to meet the RF exposure limits set forth in the governmental SAR regulations. In the examples below, for more bit rate options see the iw TX bitrate setting documentation: http://wireless.kernel.org/en/users/Documentation/iw#Modifying_transmit_bitrates Example usage: iw phy phy0 interface add moni0 type monitor ip link set dev moni0 up iw dev moni0 set channel 36 HT40+ iw set bitrates mcs-5 4 echo 10 > /sys/kernel/debug/ieee80211/phy0/ath9k/tx99_power echo 1 > /sys/kernel/debug/ieee80211/phy0/ath9k/tx99 Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: check for NULL rate when using ieee80211_get_rts_cts_rate()Luis R. Rodriguez2013-10-18
| | | | | | | | | ieee80211_get_rts_cts_rate() can return NULL, so don't rely on its members when it does return NULL. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath: add support for proper dynamic regulatory hintsLuis R. Rodriguez2013-10-18
| | | | | | | | | | | This enables support for dynamic user regulatory hints. This is enabled only when CFG80211_CERTIFICATION_ONUS is selected. For US and JP this is explicitly disabled unless the systems are being used for strict controlled testing. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath: split user and driver reguluatory hint parsingLuis R. Rodriguez2013-10-18
| | | | | | | | | On the regulatory notifier split up the parsing of the hints coming from drivers or user. We'll treat these separately. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath: move common dynamic regulatory domain setting to a helperLuis R. Rodriguez2013-10-18
| | | | | | | | This moves the dynamic regulatory domain selection code into a helper. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* cfg80211: export reg_initiator_name()Luis R. Rodriguez2013-10-18
| | | | | | | | Drivers can now use this to parse the regulatory request and be more verbose when needed. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2x00: rt2800lib: autodetect 5GHz band supportGabor Juhos2013-10-18
| | | | | | | | | | | | | | If the RF chip supports more than 14 channels that indirectly means that it supports the 5GHz band. Use this fact to enable 5GHz band support instead of setting SUPPORT_BAND_5GHZ separately for each RF chip. Also move the setup code of the 2GHz band to the same place. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2x00: rt2800lib: use switch statement for RF specific setupGabor Juhos2013-10-18
| | | | | | | | It is much more readable than multiple if-else-if statements. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2x00: rt2800lib: use {tx,rx}_chain_num to avoid superfluous EEPROM accessGabor Juhos2013-10-18
| | | | | | | | | | The {rx,tx}_chain_num fields of rt2x00dev->default_ant contains the number of RX and TX chains already when the rt2800_probe_hw_mode() function runs. Use those values instead of parsing the EEPROM configuration values again. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k/ath: move dfs pattern detector to athJanusz Dziedzic2013-10-18
| | | | | | | | | | Move the DFS pattern detector code to the ath module so the other Atheros drivers can make us of it. This makes no functional changes. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: dfs use CFG80211_CERTIFICATION_ONUS flagJanusz Dziedzic2013-10-18
| | | | | | | | | | | Use CFG80211_CERTIFICATION_ONUS flag in the DFS detector code. This is required as a preparation for moving DFS detector code from ath9k to ath module. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: dfs move ath_dfs_pool_statsJanusz Dziedzic2013-10-18
| | | | | | | | | Move ath_dfs_pool_stats to dfs_pattern_detector code to be not specyfic only for ath9k. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: dfs kill ath9k specyfic codeJanusz Dziedzic2013-10-18
| | | | | | | | | Kill of using ath9k_hw_common() function in dfs detector code. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* libertas: move firmware lifetime handling to firmware.cDan Williams2013-10-18
| | | | | | | | | | | | | Previously, each bus type was responsible for freeing the firmware structure, but some did that badly. Move responsibility for freeing firmware into firmware.c so that it's done once and correctly, instead of happening in multiple places in bus-specific code. This fixes a use-after-free bug found by Dr. H. Nikolaus Schaller where the SDIO code forgot to NULL priv->helper_fw after freeing it. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: add HT40 spectral scan capabilityLorenzo Bianconi2013-10-18
| | | | | | | | | | Add spectral scan feature on HT40 channels for ath9k. This patch extends previous capability added by Simon Wunderlich Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Reviewed-by: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de> Tested-by: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: add noise floor parameter to ath9k_hw_getchan_noiseLorenzo Bianconi2013-10-18
| | | | | | | | | | Add nf parameter to ath9k_hw_getchan_noise() in order to compute NF for EXT chains with the same scale of noise floor calculated on CTL chains. ath9k_hw_getchan_noise() will be used in ath_process_fft() for spectral scan on HT40 channels Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Merge tag 'nfc-next-3.13-1' of ↵John W. Linville2013-10-18
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next Samuel Ortiz <sameo@linux.intel.com> says: "This is the first NFC pull request for the 3.13 kernel. It's a fairly big one, with the following highlights: - NFC digital layer implementation: Most NFC chipsets implement the NFC digital layer in firmware, but others have more basic functionalities and expect the host to implement the digital layer. This layer sits below the NFC core. - Sony's port100 support: This is "soft" NFC USB dongle that expects the digital layer to be implemented on the host. This is the first user of our NFC digital stack implementation. - Secure element API: We now provide a netlink API for enabling, disabling and discovering NFC attached (embedded or UICC ones) secure elements. With some userspace help, this allows us to support NFC payments. Only the pn544 driver currently supports that API. - NCI SPI fixes and improvements: In order to support NCI devices over SPI, we fixed and improved our NCI/SPI implementation. The currently most deployed NFC NCI chipset, Broadcom's bcm2079x, supports that mode and we're planning to use our NCI/SPI framework to implement a driver for it. - pn533 fragmentation support in target mode: This was the only missing feature from our pn533 impementation. We now support fragmentation in both Tx and Rx modes, in target mode." Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * NFC: Fix SE API related sparse warningSamuel Ortiz2013-10-07
| | | | | | | | | | | | | | | | | | | | se_io_cb can be declared static. This fixes the following sparse warning: net/nfc/netlink.c:1287:6: warning: symbol 'se_io_cb' was not declared. Should it be static? Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: port100: Add target mode supportThierry Escande2013-10-07
| | | | | | | | | | | | | | | | | | | | | | | | | | This implements the target NFC digital operations tg_configure_hw(), tg_listen(), tg_listen_mdaa(), and tg_send_cmd(). The target mode supports NFC-A technology at 106kbits/s and NFC-F technologies at 212 and 424kbits/s. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Cc: Stephen Tiedemann <stephen.tiedemann@gmail.com> Tested-by: Cho, Yu-Chen <acho@suse.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: port100: Add initiator mode supportThierry Escande2013-10-07
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the initiator NFC operations in_configure_hw() and in_send_cmd(). It also implements the switch_rf() operation. The initiator mode supports NFC-A technology at 106kbits/s and NFC-F technologies at 212 and 424kbits/s. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Cc: Stephen Tiedemann <stephen.tiedemann@gmail.com> Tested-by: Cho, Yu-Chen <acho@suse.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: port100: Commands mechanism implementationThierry Escande2013-10-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the command handling mechanism. The digital stack serializes all commands sent to the driver. This means that the digital stack waits for the reply of the current command before sending a new one. So there is no command queue managed at driver level. All Port-100 commands are asynchronous. If the command has been sent successfully to the device, it replies with an ACK frame. Then the command response is received (or actually no-response in case of timeout or error) and a command complete work on the system workqueue is responsible for sending the response (or the error) back to the digital stack. The digital stack requires some commands to be synchronous, mainly hardware configuration ones. These commands use the asynchronous command path but are made synchronous by using a completion object. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Cc: Stephen Tiedemann <stephen.tiedemann@gmail.com> Tested-by: Cho, Yu-Chen <acho@suse.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Sony Port-100 Series driverThierry Escande2013-10-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for the Sony NFC USB dongle RC-S380, based on the Port-100 chip. This dongle is an analog frontend and does not implement the digital layer. This driver uses the nfc_digital module which is an implementation of the NFC Digital Protocol stack. This patch is a skeleton. It only registers the dongle against the NFC digital protocol stack. All NFC digital operation functions are stubbed out. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Cc: Stephen Tiedemann <stephen.tiedemann@gmail.com> Tested-by: Cho, Yu-Chen <acho@suse.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: pn533: Target mode Tx fragmentation supportOlivier Guiter2013-09-25
| | | | | | | | | | | | | | | | | | | | | | In target mode, when we want to send frames larger than the max length (PN533_CMD_DATAEXCH_DATA_MAXLEN), we have to split the frame in smaller chunks and send them, using a specific working queue, with the TgSetMetaData command. TgSetMetaData sets his own MI bit in the PFB. The last chunk is sent using the TgSetData command. Signed-off-by: Olivier Guiter <olivier.guiter@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: pn533: Add support for incoming fragmented frame in target modeOlivier Guiter2013-09-25
| | | | | | | | | | | | | | | | | | | | This code processes, for Target Mode, incoming fragmented frames. If the MI bit is present, we start a working queue to grab and aggregate all the parts (using TmGetData between each parts). On the last one, as there's no more MI bit, we jump on the usual behavior. Signed-off-by: Olivier Guiter <olivier.guiter@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: pn533: Add MI/TG bits only when in Initiator modeOlivier Guiter2013-09-25
| | | | | | | | | | | | | | | | | | | | The fragmentation routine (used to split big frames) could be used in target or initiator mode (TgSetMetaData vs InDataExchange), but the MI/TG bytes are not needed in target mode (TgSetMetaData), so we add a check on the mode Signed-off-by: Olivier Guiter <olivier.guiter@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: Modify NCI SPI to implement CS/INT handshake per the specEric Lapuyade2013-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * NFC: NCI: nci_spi_recv_frame() now returns (not forward) the read frameEric Lapuyade2013-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: zero struct spi_transfer variables before usageEric Lapuyade2013-09-25
| | | | | | | | | | | | | | | | | | | | 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: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: netlink: SE API implementationSamuel Ortiz2013-09-24
| | | | | | | | | | | | | | | | Implementation of the NFC_CMD_SE_IO command for sending ISO7816 APDUs to NFC embedded secure elements. The reply is forwarded to user space through NFC_CMD_SE_IO as well. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Define secure element IO API and commandsSamuel Ortiz2013-09-24
| | | | | | | | | | | | | | | | | | | | | | In order to send and receive ISO7816 APDUs to and from NFC embedded secure elements, we define a specific netlink command. On a typical SE use case, host applications will send very few APDUs (Less than 10) per transaction. This is why we decided to go for a simple netlink API. Defining another NFC socket protocol for such low traffic would have been overengineered. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Document NFC targets sens_res fieldSamuel Ortiz2013-09-24
| | | | | | | | | | | | | | | | SENS_RES has no specific endiannes attached to it, the kernel ABI is the following one: Byte 2 (As described by the NFC Forum Digital spec) is the u16 most significant byte. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Fix sens_res endiannes handlingThierry Escande2013-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was triggered by the following sparse warning: net/nfc/digital_technology.c:272:20: sparse: cast to restricted __be16 The SENS_RES response must be treated as __le16 with the first byte received as LSB and the second one as MSB. This is the way neard handles it in the sens_res field of the nfc_target structure which is treated as u16 in cpu endianness. So le16_to_cpu() is used on the received SENS_RES instead of memcpy'ing it. SENS_RES test macros have also been fixed accordingly. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: rawsock: Fix a memory leakThierry Escande2013-09-24
| | | | | | | | | | | | | | | | In the rawsock data exchange callback, the sk_buff is not freed on error. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: pn533: Staticize local symbolsSachin Kamat2013-09-24
| | | | | | | | | | | | | | Local symbols used only in this file are made static. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: nfcwilink: Remove redundant dev_set_drvdataSachin Kamat2013-09-24
| | | | | | | | | | | | | | | | Driver core sets driver data to NULL upon failure or remove. Cc: Ilan Elias <ilane@ti.com> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: digital_tg_send_sensf_res() can be staticFengguang Wu2013-09-24
| | | | | | | | | | | | | | | | | | | | | | Fixes sparse hint: net/nfc/digital_technology.c:640:5: sparse: symbol 'digital_tg_send_sensf_res' was not declared. Should it be static? Cc: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Add newline to pr_* callsSamuel Ortiz2013-09-24
| | | | | | | | | | | | | | | | We do not add the newline to the pr_fmt macro, in order to give more flexibility to the caller and to keep the logging style consistent with the rest of the NFC and kernel code. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Remove PR_ERR and PR_DBG macrosSamuel Ortiz2013-09-24
| | | | | | | | | | | | | | They can be replaced by the standard pr_err and pr_debug one after defining the right pr_fmt macro. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-14 01:00:43 -0400