| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| | |
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
Conflicts:
drivers/net/wireless/brcm80211/brcmfmac/sdio_host.h
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | | |
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
Conflicts:
drivers/net/wireless/iwlwifi/pcie/drv.c
|
| | | |\
| | | |
| | | |
| | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Some APs (notably a Sitecom WL-153 v1 with firmware 1.45) are sending
invalid WMM parameters setting AIFSN, ECWmin and ECWmax to zero. The
spec mandates that the value of AIFSN is at least 2, and some cards
(e.g. Intel with the iwldvm driver) can't transmit when the invalid
QoS parameters are actually uploaded to the firmware.
Since there's little chance of being able to guess the values that
the AP actually meant, disable WMM if such an invalid case is found.
Since ECWmin/ECWmax are allowed to be zero, only verify AIFSN >= 2
and ECWmin <= ECWmax.
Reviewed-by: Eliad Peller <eliad@wizery.com>
Reported-by: Antonio Quartulli <antonio@meshcoding.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Bitrate mask were not respected in transmissions, causing (for
example) P2P GO/client to use CCK rates for auth and assoc frames.
Fix it by considering the rate mask in __rate_control_send_low().
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Transmissions with the IEEE80211_TX_CTL_NO_CCK_RATE flag set
(which can come from userspace) were no longer guaranteed to
be transmitted with allowed rates since commit 2103dec14792b
("mac80211: select and adjust bitrates according to channel
mode") due to a missing rate_flags check in that commit. The
commit also introduced the need to check the 5/10 MHz flags
but accidentally didn't. Fix it by adding the missing check.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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>
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This adds support for NFC-DEP target mode for NFC-A and NFC-F
technologies.
If the driver provides it, the stack uses an automatic mode for
technology detection and automatic anti-collision. Otherwise the stack
tries to use non-automatic synchronization and listens for SENS_REQ and
SENSF_REQ commands.
The detection, activation, and data exchange procedures work exactly
the same way as in initiator mode, as described in the previous
commits, except that the digital stack waits for commands and sends
responses back to the peer device.
Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This adds support for NFC-DEP protocol in initiator mode for NFC-A and
NFC-F technologies.
When a target is detected, the process flow is as follow:
For NFC-A technology:
1 - The digital stack receives a SEL_RES as the reply of the SEL_REQ
command.
2 - If b7 of SEL_RES is set, the peer device is configure for NFC-DEP
protocol. NFC core is notified through nfc_targets_found().
Execution continues at step 4.
3 - Otherwise, it's a tag and the NFC core is notified. Detection
ends.
4 - The digital stacks sends an ATR_REQ command containing a randomly
generated NFCID3 and the general bytes obtained from the LLCP layer
of NFC core.
For NFC-F technology:
1 - The digital stack receives a SENSF_RES as the reply of the
SENSF_REQ command.
2 - If B1 and B2 of NFCID2 are 0x01 and 0xFE respectively, the peer
device is configured for NFC-DEP protocol. NFC core is notified
through nfc_targets_found(). Execution continues at step 4.
3 - Otherwise it's a type 3 tag. NFC core is notified. Detection
ends.
4 - The digital stacks sends an ATR_REQ command containing the NFC-F
NFCID2 as NFCID3 and the general bytes obtained from the LLCP layer
of NFC core.
For both technologies:
5 - The digital stacks receives the ATR_RES response containing the
NFCID3 and the general bytes of the peer device.
6 - The digital stack notifies NFC core that the DEP link is up through
nfc_dep_link_up().
7 - The NFC core performs data exchange through tm_transceive().
8 - The digital stack sends a DEP_REQ command containing an I PDU with
the data from NFC core.
9 - The digital stack receives a DEP_RES command
10 - If the DEP_RES response contains a supervisor PDU with timeout
extension request (RTOX) the digital stack sends a DEP_REQ
command containing a supervisor PDU acknowledging the RTOX
request. The execution continues at step 9.
11 - If the DEP_RES response contains an I PDU, the response data is
passed back to NFC core through the response callback. The
execution continues at step 8.
Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This adds polling support for NFC-F technology at 212 kbits/s and 424
kbits/s. A user space application like neard can send type 3 tag
commands through the NFC core.
Process flow for NFC-F detection is as follow:
1 - The digital stack sends the SENSF_REQ command to the NFC device.
2 - A peer device replies with a SENSF_RES response.
3 - The digital stack notifies the NFC core of the presence of a
target in the operation field and passes the target NFCID2.
This also adds support for CRC calculation of type CRC-F. The CRC
calculation is handled by the digital stack if the NFC device doesn't
support it.
Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This adds support for NFC-A technology at 106 kbits/s. The stack can
detect tags of type 1 and 2. There is no support for collision
detection. Tags can be read and written by using a user space
application or a daemon like neard.
The flow of polling operations for NFC-A detection is as follow:
1 - The digital stack sends the SENS_REQ command to the NFC device.
2 - The NFC device receives a SENS_RES response from a peer device and
passes it to the digital stack.
3 - If the SENS_RES response identifies a type 1 tag, detection ends.
NFC core is notified through nfc_targets_found().
4 - Otherwise, the digital stack sets the cascade level of NFCID1 to
CL1 and sends the SDD_REQ command.
5 - The digital stack selects SEL_CMD and SEL_PAR according to the
cascade level and sends the SDD_REQ command.
4 - The digital stack receives a SDD_RES response for the cascade level
passed in the SDD_REQ command.
5 - The digital stack analyses (part of) NFCID1 and verify BCC.
6 - The digital stack sends the SEL_REQ command with the NFCID1
received in the SDD_RES.
6 - The peer device replies with a SEL_RES response
7 - Detection ends if NFCID1 is complete. NFC core notified of new
target by nfc_targets_found().
8 - If NFCID1 is not complete, the cascade level is incremented (up
to and including CL3) and the execution continues at step 5 to
get the remaining bytes of NFCID1.
Once target detection is done, type 1 and 2 tag commands must be
handled by a user space application (i.e neard) through the NFC core.
Responses for type 1 tag are returned directly to user space via NFC
core.
Responses of type 2 commands are handled differently. The digital stack
doesn't analyse the type of commands sent through im_transceive() and
must differentiate valid responses from error ones.
The response process flow is as follow:
1 - If the response length is 16 bytes, it is a valid response of a
READ command. the packet is returned to the NFC core through the
callback passed to im_transceive(). Processing stops.
2 - If the response is 1 byte long and is a ACK byte (0x0A), it is a
valid response of a WRITE command for example. First packet byte
is set to 0 for no-error and passed back to the NFC core.
Processing stops.
3 - Any other response is treated as an error and -EIO error code is
returned to the NFC core through the response callback.
Moreover, since the driver can't differentiate success response from a
NACK response, the digital stack has to handle CRC calculation.
Thus, this patch also adds support for CRC calculation. If the driver
doesn't handle it, the digital stack will calculate CRC and will add it
to sent frames. CRC will also be checked and removed from received
frames. Pointers to the correct CRC calculation functions are stored in
the digital stack device structure when a target is detected. This
avoids the need to check the current target type for every call to
im_transceive() and for every response received from a peer device.
Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This implements the mechanism used to send commands to the driver in
initiator mode through in_send_cmd().
Commands are serialized and sent to the driver by using a work item
on the system workqueue. Responses are handled asynchronously by
another work item. Once the digital stack receives the response through
the command_complete callback, the next command is sent to the driver.
This also implements the polling mechanism. It's handled by a work item
cycling on all supported protocols. The start poll command for a given
protocol is sent to the driver using the mechanism described above.
The process continues until a peer is discovered or stop_poll is
called. This patch implements the poll function for NFC-A that sends a
SENS_REQ command and waits for the SENS_RES response.
Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is the initial commit of the NFC Digital Protocol stack
implementation.
It offers an interface for devices that don't have an embedded NFC
Digital protocol stack. The driver instantiates the digital stack by
calling nfc_digital_allocate_device(). Within the nfc_digital_ops
structure, the driver specifies a set of function pointers for driver
operations. These functions must be implemented by the driver and are:
in_configure_hw:
Hardware configuration for RF technology and communication framing in
initiator mode. This is a synchronous function.
in_send_cmd:
Initiator mode data exchange using RF technology and framing previously
set with in_configure_hw. The peer response is returned through
callback cb. If an io error occurs or the peer didn't reply within the
specified timeout (ms), the error code is passed back through the resp
pointer. This is an asynchronous function.
tg_configure_hw:
Hardware configuration for RF technology and communication framing in
target mode. This is a synchronous function.
tg_send_cmd:
Target mode data exchange using RF technology and framing previously
set with tg_configure_hw. The peer next command is returned through
callback cb. If an io error occurs or the peer didn't reply within the
specified timeout (ms), the error code is passed back through the resp
pointer. This is an asynchronous function.
tg_listen:
Put the device in listen mode waiting for data from the peer device.
This is an asynchronous function.
tg_listen_mdaa:
If supported, put the device in automatic listen mode with mode
detection and automatic anti-collision. In this mode, the device
automatically detects the RF technology and executes the
anti-collision detection using the command responses specified in
mdaa_params. The mdaa_params structure contains SENS_RES, NFCID1, and
SEL_RES for 106A RF tech. NFCID2 and system code (sc) for 212F and
424F. The driver returns the NFC-DEP ATR_REQ command through cb. The
digital stack deducts the RF tech by analyzing the SoD of the frame
containing the ATR_REQ command. This is an asynchronous function.
switch_rf:
Turns device radio on or off. The stack does not call explicitly
switch_rf to turn the radio on. A call to in|tg_configure_hw must turn
the device radio on.
abort_cmd:
Discard the last sent command.
Then the driver registers itself against the digital stack by using
nfc_digital_register_device() which in turn registers the digital stack
against the NFC core layer. The digital stack implements common NFC
operations like dev_up(), dev_down(), start_poll(), stop_poll(), etc.
This patch is only a skeleton and NFC operations are just stubs.
Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As we can potentially get DEP up events without having sent a netlink
command, we need to set the active target properly from dep_link_is_up.
Spontaneous DEP up events can come from devices that detected an active
p2p target. In that case there is no need to call the netlink DEP up
command as the link is already up and running.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This will be needed by all NFC driver implementing the SE ops.
Signed-off-by: Arron Wang <arron.wang@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Read the current IAC LAP values when initializing the controller. The
values are not used, but it is good to have them in the trace files
for debugging purposes.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When initializing a controller make sure to read out the number of
supported IAC and store its result. This value is needed to determine
if limited discoverable for BR/EDR can be configured or not.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The scan window parameter for connection establishment and passive
scanning needs to be smaller or equal than the scan interval.
Instead of waiting for a controller to reject these values later on,
just reject them right away.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
If a socket was bound to an address type other than BR/EDR (such as LE)
we should reject trying to connect it to a BR/EDR address. The same
applies for binding to BR/EDR and trying to connect to non-BR/EDR.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We need to verify that the bdaddr type passed to connect() and bind() is
within the set of valid values. If it is not we need to cleanly fail
with EINVAL.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This patch converts Set Discoverable to use an asynchronous request
along with its own completion callback. This is necessary for splitting
raw HCI socket use cases from mgmt, as well as for enabling the hooking
up of Advertising parameters together with the HCI_DISCOVERABLE flag
(coming in later patches).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Now that the connectable setting is also applicable for the LE side it's
possible that the HCI_CONNECTABLE flag is already set when changing the
BR/EDR setting from false to true while the controller is powered. In
this situation we need to update the BR/EDR scan mode to reflect the
setting. Additionally, since HCI_CONNECTABLE also applies to LE we must
not clear the HCI_CONNECTABLE flag when disabling bredr.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The set_bredr_scan() function will soon be needed by the set_bredr()
function, so move it to a new location to avoid having to add a forward
declaration.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This patch updates the Set Connectable Management command to also update
the LE advertising type to either connectable or non-connectable
advertising. An extra helper function is needed for getting the right
advertising type since we can not only rely on the HCI_CONNECTABLE flag
but must also check for a pending Set Connectable command (in which case
the flag does not yet have its final value).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We need to ensure that the advertising data is up-to-date whenever
advertising is enabled, but when disabling advertising we do not need to
worry about it (since it will eventually get fixed as soon as
advertising is enabled again). This patch fixes this in the command
complete callback for set_adv_enable.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
These functions will soon be used by set_connectable() so move them to a
location in mgmt.c that doesn't require forward declarations.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
If the HCI commands related to the Set Connectable command fail we will
get a non-zero status in the request completion callback. In such a case
we must respond with the appropriate command status message to user space.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This patch moves the responsibility of setting/clearing the
HCI_CONNECTABLE flag to the request completion callback of the Set
Connectable command. This will allow us to cleanly add support for LE
Advertising hooks in later patches.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This patch moves all the decisions of which HCI commands to send (or not
to send) to the code between hci_req_init() and hci_req_run() this
allows us to further extend the request with further commands but still
keep the same logic of handling whether to return a direct mgmt response
in the case that no HCI commands were sent.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Clearing the BT_SK_SUSPEND socket flag from the L2CAP core is causing
a dependency on the socket. So intead of doing that, use a channel
callback into the socket handling to resume.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The L2CAP core should not look into the socket flags to figure out the
setting of defer setup. So introduce a L2CAP channel flag that mirrors
the socket flag.
Since the defer setup option is only set in one place this becomes a
really easy thing to do.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The exposed socket information do not contain source or destination
addresses. So adjust the header accordingly.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
There have been a lot of changes in the core Bluetooth handling
lately. So it is a good idea to increase the module version.
The module version is not used anywhere, but it makes debugging
a little bit simpler if versions can be distinguished.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The L2CAP connectionless channels use SOCK_DGRAM and recvmsg() and need
to receive the remote BD_ADDR and PSM information via msg_name from
the recvmsg() system call.
So in case the L2CAP socket is for connectionless channels, provide
a msg_name callback that can update the data. Also store the remote
BD_ADDR and PSM in the skb so it can be extracted later on.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
