10 Dec, 2014
1 commit
-
…inville/wireless-next
John W. Linville says:
====================
pull request: wireless-next 2014-12-08Please pull this last batch of pending wireless updates for the 3.19 tree...
For the wireless bits, Johannes says:
"This time I have Felix's no-status rate control work, which will allow
drivers to work better with rate control even if they don't have perfect
status reporting. In addition to this, a small hwsim fix from Patrik,
one of the regulatory patches from Arik, and a number of cleanups and
fixes I did myself.Of note is a patch where I disable CFG80211_WEXT so that compatibility
is no longer selectable - this is intended as a wake-up call for anyone
who's still using it, and is still easily worked around (it's a one-line
patch) before we fully remove the code as well in the future."For the Bluetooth bits, Johan says:
"Here's one more bluetooth-next pull request for 3.19:
- Minor cleanups for ieee802154 & mac802154
- Fix for the kernel warning with !TASK_RUNNING reported by Kirill A.
Shutemov
- Support for another ath3k device
- Fix for tracking link key based security level
- Device tree bindings for btmrvl + a state update fix
- Fix for wrong ACL flags on LE links"And...
"In addition to the previous one this contains two more cleanups to
mac802154 as well as support for some new HCI features from the
Bluetooth 4.2 specification.From the original request:
'Here's what should be the last bluetooth-next pull request for 3.19.
It's rather large but the majority of it is the Low Energy Secure
Connections feature that's part of the Bluetooth 4.2 specification. The
specification went public only this week so we couldn't publish the
corresponding code before that. The code itself can nevertheless be
considered fairly mature as it's been in development for over 6 months
and gone through several interoperability test events.Besides LE SC the pull request contains an important fix for command
complete events for mgmt sockets which also fixes some leaks of hci_conn
objects when powering off or unplugging Bluetooth adapters.A smaller feature that's part of the pull request is service discovery
support. This is like normal device discovery except that devices not
matching specific UUIDs or strong enough RSSI are filtered out.Other changes that the pull request contains are firmware dump support
to the btmrvl driver, firmware download support for Broadcom BCM20702A0
variants, as well as some coding style cleanups in 6lowpan &
ieee802154/mac802154 code.'"For the NFC bits, Samuel says:
"With this one we get:
- NFC digital improvements for DEP support: Chaining, NACK and ATN
support added.- NCI improvements: Support for p2p target, SE IO operand addition,
SE operands extensions to support proprietary implementations, and
a few fixes.- NFC HCI improvements: OPEN_PIPE and NOTIFY_ALL_CLEARED support,
and SE IO operand addition.- A bunch of minor improvements and fixes for STMicro st21nfcb and
st21nfca"For the iwlwifi bits, Emmanuel says:
"Major works are CSA and TDLS. On top of that I have a new
firmware API for scan and a few rate control improvements.
Johannes find a few tricks to improve our CPU utilization
and adds support for a new spin of 7265 called 7265D.
Along with this a few random things that don't stand out."And...
"I deprecate here -8.ucode since -9 has been published long ago.
Along with that I have a new activity, we have now better
a infrastructure for firmware debugging. This will allow to
have configurable probes insides the firmware.
Luca continues his work on NetDetect, this feature is now
complete. All the rest is minor fixes here and there."For the Atheros bits, Kalle says:
"Only ath10k changes this time and no major changes. Most visible are:
o new debugfs interface for runtime firmware debugging (Yanbo)
o fix shared WEP (Sujith)
o don't rebuild whenever kernel version changes (Johannes)
o lots of refactoring to make it easier to add new hw support (Michal)
There's also smaller fixes and improvements with no point of listing
here."In addition, there are a few last minute updates to ath5k,
ath9k, brcmfmac, brcmsmac, mwifiex, rt2x00, rtlwifi, and wil6210.
Also included is a pull of the wireless tree to pick-up the fixes
originally included in "pull request: wireless 2014-12-03"...Please let me know if there are problems!
====================Signed-off-by: David S. Miller <davem@davemloft.net>
03 Dec, 2014
9 commits
-
The maximum size of ATR_REQ and ATR_RES is 64 bytes.
The maximum number of General Bytes is calculated by
the maximum number of data bytes in the ATR_REQ/ATR_RES,
substracted by the number of mandatory data bytes.ATR_REQ: 16 mandatory data bytes, giving a maximum of
48 General Bytes.
ATR_RES: 17 mandatory data bytes, giving a maximum of
47 General Bytes.Regression introduced in commit a99903ec.
Signed-off-by: Julien Lefrique
Signed-off-by: Samuel Ortiz -
Fixing: net/nfc/nci/ntf.c:106:31: warning: cast to restricted __le16
message when building with make C=1 CF=-D__CHECK_ENDIAN__Signed-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz -
Fix warnings:
net/nfc/llcp_commands.c:421:14: warning: incorrect type in assignment (different base types)
net/nfc/llcp_commands.c:421:14: expected unsigned short [unsigned] [usertype] miux
net/nfc/llcp_commands.c:421:14: got restricted __be16
net/nfc/llcp_commands.c:477:14: warning: incorrect type in assignment (different base types)
net/nfc/llcp_commands.c:477:14: expected unsigned short [unsigned] [usertype] miux
net/nfc/llcp_commands.c:477:14: got restricted __be16Procedure to reproduce:
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__Signed-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz -
Some pipe are only created by other host (different than the
Terminal Host).
The pipe values will for example be notified by
NFC_HCI_ADM_NOTIFY_PIPE_CREATED.Signed-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz -
se_io allows to send apdu over the CLF to the embedded
Secure Element.Signed-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz -
Some tag might get deactivated after some read or write tentative.
This may happen for example with Mifare Ultralight C tag when trying
to read the last 4 blocks (starting block 0x2c) configured as write
only.
NFC_CMD_ACTIVATE_TARGET will try to reselect the tag in order to
detect if it got remove from the field or if it is still present.Signed-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz -
nci_rf_deactivate_req only support NCI_DEACTIVATE_TYPE_IDLE_MODE.
In some situation, it might be necessary to be able to support other
NCI_DEACTIVATE_TYPE such as NCI_DEACTIVATE_TYPE_SLEEP_MODE in order for
example to reactivate the selected target.Signed-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz -
A notification for rf deaction can be IDLE_MODE, SLEEP_MODE,
SLEEP_AF_MODE and DISCOVERY. According to each type and the NCI
state machine is different (see figure 10 RF Communication State
Machine in NCI specification)Signed-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz -
The nci status byte was ignored. In case of tag reading for example,
if the tag is removed from the antenna there is no way for the upper
layers (aka: stack) to get inform about such event.Signed-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz
02 Dec, 2014
8 commits
-
When switching from UICC to another, the CLF may signals to the Terminal
Host that some existing pipe are cleared for future update.This notification needs to be "acked" by the Terminal Host with a ANY_OK
message.Signed-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz -
If our terminal connect with other host like UICC, it may create
a pipe with us, the host controller will notify us new pipe
created, after that UICC will open that pipe, if we don't handle
that request, UICC may failed to continue initialize which may
lead to card emulation feature failed to workSigned-off-by: Arron Wang
Signed-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz -
se_io allows to send apdu over the CLF to the embedded Secure Element.
Signed-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz -
Some NFC controller using NCI protocols may need a proprietary commands
flow to disable a secure elementSigned-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz -
Some NFC controller using NCI protocols may need a proprietary commands
flow to enable a secure elementSigned-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz -
…ilable secure element
Some NFC controller using NCI protocols may need a proprietary commands
flow to discover all available secure elementSigned-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> -
Fix sparse warning introduced by commit: 9e87f9a9c4c4754508b2c2638fbde9e10c7a103b
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 9e87f9a9c4c4754508b2c2638fbde9e10c7a103b
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__Signed-off-by: Fengguang Wu
Signed-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz -
se_io allows to send apdu over the CLF to the embedded Secure Element.
Signed-off-by: Christophe Ricard
Signed-off-by: Samuel Ortiz
28 Nov, 2014
22 commits
-
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: Julien Lefrique
Signed-off-by: Samuel Ortiz -
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: Julien Lefrique
Signed-off-by: Samuel Ortiz -
Signed-off-by: Julien Lefrique
Signed-off-by: Samuel Ortiz -
Signed-off-by: Julien Lefrique
Signed-off-by: Samuel Ortiz -
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: Julien Lefrique
Signed-off-by: Samuel Ortiz -
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: Julien Lefrique
Signed-off-by: Samuel Ortiz -
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: Julien Lefrique
Signed-off-by: Samuel Ortiz -
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: Julien Lefrique
Signed-off-by: Samuel Ortiz -
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: Julien Lefrique
Signed-off-by: Samuel Ortiz -
list_for_each_entry_safe() is necessary if list objects are deleted from
the list while traversing it. Not the case here, so we can use the base
list_for_each_entry variant.Signed-off-by: Axel Lin
Signed-off-by: Samuel Ortiz -
When an NFC-DEP target receives an ATN PDU, its
supposed to respond with a similar ATN PDU.
When the Target receives an I PDU with the PNI
one less than the current PNI and the last PDU
sent was an ATN PDU, the Target is to resend the
last non-ATN PDU that it has sent. This is
described in section 14.12.3.4 of the NFC Digital
Protocol Spec.The digital layer's NFC-DEP code doesn't implement
this so add that support.Reviewed-by: Thierry Escande
Tested-by: Thierry Escande
Signed-off-by: Mark A. Greer
Signed-off-by: Samuel Ortiz -
When an NFC-DEP Initiator times out when waiting for
a DEP_RES from the Target, its supposed to send an
ATN to the Target. The Target should respond to the
ATN with a similar ATN PDU and the Initiator can then
resend the last non-ATN PDU that it sent. No more
than 'N(retry,atn)' are to be send where
2
Tested-by: Thierry Escande
Signed-off-by: Mark A. Greer
Signed-off-by: Samuel Ortiz -
When an NFC-DEP Target receives a NACK PDU with
a PNI equal to 1 less than the current PNI, it
is supposed to re-send the last PDU. This is
implied in section 14.12.5.4 of the NFC Digital
Protocol Spec.The digital layer's NFC-DEP code doesn't implement
Target-side NACK handing so add it. The last PDU
that was sent is saved in the 'nfc_digital_dev'
structure's 'saved_skb' member. The skb will have
an additional reference taken to ensure that the skb
isn't freed when the driver performs a kfree_skb()
on the skb. The length of the skb/PDU is also saved
so the length can be restored when re-sending the PDU
in the skb (the driver will perform an skb_pull() so
an skb_push() needs to be done to restore the skb's
data pointer/length).Reviewed-by: Thierry Escande
Tested-by: Thierry Escande
Signed-off-by: Mark A. Greer
Signed-off-by: Samuel Ortiz -
When an NFC-DEP Initiator receives a frame with
an incorrect CRC or with a parity error, and the
frame is at least 4 bytes long, its supposed to
send a NACK to the Target. The Initiator can
send up to 'N(retry,nack)' consecutive NACKs
where 2
Tested-by: Thierry Escande
Signed-off-by: Mark A. Greer
Signed-off-by: Samuel Ortiz -
When the peer in an NFC-DEP exchange has a
packet to send that is larger than the local
maximum payload, it sets the 'MI' bit in the
'I' PDU. This indicates that NFC-DEP chaining
is to occur.When such a PDU is received, the local side
responds with an 'ACK' PDU and this continues
until the peer sends an 'I' PDU with the 'MI'
bit cleared. This indicates that the chaining
sequence is complete and the entire packet has
been transferred.Receiving chained PDUs is currently not supported
by the digital layer so add that support. When a
chaining sequence is initiated by the peer, the
digital layer will allocate an skb large enough
to hold 8 maximum sized frame payloads. The maximum
payload can range from 64 to 254 bytes so 8 * 254 =
2032 seems like a reasonable compromise between
potentially wasting memory and constantly reallocating
new, larger skbs.Reviewed-by: Thierry Escande
Tested-by: Thierry Escande
Signed-off-by: Mark A. Greer
Signed-off-by: Samuel Ortiz -
When the NFC-DEP code is given a packet to send
that is larger than the peer's maximum payload,
its supposed to set the 'MI' bit in the 'I' PDU's
Protocol Frame Byte (PFB). Setting this bit
indicates that NFC-DEP chaining is to occur.When NFC-DEP chaining is progress, sender 'I' PDUs
are acknowledged with 'ACK' PDUs until the last 'I'
PDU in the chain (which has the 'MI' bit cleared)
is responded to with a normal 'I' PDU. This can
occur while in Initiator mode or in Target mode.Sender NFC-DEP chaining is currently not implemented
in the digital layer so add that support. Unfortunately,
since sending a frame may require writing the CRC to the
end of the data, the relevant data part of the original
skb must be copied for each intermediate frame.Reviewed-by: Thierry Escande
Tested-by: Thierry Escande
Signed-off-by: Mark A. Greer
Signed-off-by: Samuel Ortiz -
The maximum payload for NFC-DEP exchanges (i.e., the
number of bytes between SoD and EoD) is negotiated
using the ATR_REQ, ATR_RES, and PSL_REQ commands.
The valid maximum lengths are 64, 128, 192, and 254
bytes.Currently, NFC-DEP code assumes that both sides are
always using 254 byte maximums and ignores attempts
by the peer to change it. Instead, implement the
negotiation code, enforce the local maximum when
receiving data from the peer, and don't send payloads
that exceed the remote's maximum. The default local
maximum is 254 bytes.Reviewed-by: Thierry Escande
Tested-by: Thierry Escande
Signed-off-by: Mark A. Greer
Signed-off-by: Samuel Ortiz -
NFC-DEP DEP_REQ and DEP_RES exchanges using 'I'
and 'ACK/NACK' PDUs have a sequence number called
the Packet Number Information (PNI). The PNI
is incremented (modulo 4) after every DEP_REQ/
DEP_RES pair and should be verified by the digital
layer code. That verification isn't always done,
though, so add code to make sure that it is done.Reviewed-by: Thierry Escande
Tested-by: Thierry Escande
Signed-off-by: Mark A. Greer
Signed-off-by: Samuel Ortiz -
According to chapter 14 of the NFC-DEP Digital
Protocol Spec., the NAD byte should never be
present in DEP_REQ or DEP_RES frames. However,
this is not enforced so add that enforcement code.Reviewed-by: Thierry Escande
Tested-by: Thierry Escande
Signed-off-by: Mark A. Greer
Signed-off-by: Samuel Ortiz -
When in Target mode, the Initiator specifies whether
subsequent DEP_REQ and DEP_RES frames will include
a DID byte by the value passed in the ATR_REQ. If
the DID value in the ATR_REQ is '0' then no DID
byte will be included. If the DID value is between
'1' and '14' then a DID byte containing the same
value must be included in subsequent DEP_REQ and
DEP_RES frames. Any other DID value is invalid.
This is specified in sections 14.8.1.2 and 14.8.2.2
of the NFC Digital Protocol Spec.Checking the DID value (if it should be there at all),
is not currently supported by the digital layer's
NFC-DEP code. Add this support by remembering the
DID value in the ATR_REQ, checking the DID value of
received DEP_REQ frames (if it should be there at all),
and including the remembered DID value in DEP_RES
frames when appropriate.Reviewed-by: Thierry Escande
Tested-by: Thierry Escande
Signed-off-by: Mark A. Greer
Signed-off-by: Samuel Ortiz -
When in Initiator mode, the digital layer's
NFC-DEP code always sets the Device ID (DID)
value in the ATR_REQ to '0'. This means that
subsequent DEP_REQ and DEP_RES frames must
never include a DID byte. This is specified
in sections 14.8.1.1 and 14.8.2.1 of the NFC
Digital Protocol Spec.Currently, the digital layer's NFC-DEP code
doesn't enforce this rule so add code to ensure
that there is no DID byte in DEP_RES frames.Reviewed-by: Thierry Escande
Tested-by: Thierry Escande
Signed-off-by: Mark A. Greer
Signed-off-by: Samuel Ortiz -
Rearrange some of the code in digital_in_recv_dep_res()
and digital_tg_recv_dep_req() so the initial code looks
similar. The real reason is prepare the code for some
upcoming patches that require these changes.Reviewed-by: Thierry Escande
Tested-by: Thierry Escande
Signed-off-by: Mark A. Greer
Signed-off-by: Samuel Ortiz
