mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-29 11:11:45 -04:00
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
John says: -------------------- I apologize for not having sent this sooner. FWIW, I was in a car somewhere between Illinois and North Carolina for most of the day Sunday and Monday... :-) This is (obviously) the last non-fix pull request for wireless bits intended for 3.5. It includes AP support for mwifiex, a variety of HCI and other updates for NFC, some brcmfmac and brcmsmac refactoring, a large batch of ssb and bcma updates, a batch of ath6kl updates, some cfg80211 and mac80211 updates/refactoring from Johannes Berg, a rather large collection of Bluetooth updates by way of Gustavo, and a variety of other bits here and there. -------------------- Signed-off-by: David S. Miller <[email protected]>
This commit is contained in:
commit
c3719a1ef5
173 changed files with 6618 additions and 5499 deletions
|
|
@ -534,6 +534,18 @@ Who: Kees Cook <[email protected]>
|
|||
|
||||
----------------------------
|
||||
|
||||
What: Removing the pn544 raw driver.
|
||||
When: 3.6
|
||||
Why: With the introduction of the NFC HCI and SHDL kernel layers, pn544.c
|
||||
is being replaced by pn544_hci.c which is accessible through the netlink
|
||||
and socket NFC APIs. Moreover, pn544.c is outdated and does not seem to
|
||||
work properly with the latest Android stacks.
|
||||
Having 2 drivers for the same hardware is confusing and as such we
|
||||
should only keep the one following the kernel NFC APIs.
|
||||
Who: Samuel Ortiz <[email protected]>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: setitimer accepts user NULL pointer (value)
|
||||
When: 3.6
|
||||
Why: setitimer is not returning -EFAULT if user pointer is NULL. This
|
||||
|
|
|
|||
|
|
@ -22,9 +22,9 @@ response to arrive.
|
|||
HCI events can also be received from the host controller. They will be handled
|
||||
and a translation will be forwarded to NFC Core as needed.
|
||||
HCI uses 2 execution contexts:
|
||||
- one if for executing commands : nfc_hci_msg_tx_work(). Only one command
|
||||
- one for executing commands : nfc_hci_msg_tx_work(). Only one command
|
||||
can be executing at any given moment.
|
||||
- one if for dispatching received events and responses : nfc_hci_msg_rx_work()
|
||||
- one for dispatching received events and commands : nfc_hci_msg_rx_work().
|
||||
|
||||
HCI Session initialization:
|
||||
---------------------------
|
||||
|
|
@ -52,18 +52,42 @@ entry points:
|
|||
struct nfc_hci_ops {
|
||||
int (*open)(struct nfc_hci_dev *hdev);
|
||||
void (*close)(struct nfc_hci_dev *hdev);
|
||||
int (*hci_ready) (struct nfc_hci_dev *hdev);
|
||||
int (*xmit)(struct nfc_hci_dev *hdev, struct sk_buff *skb);
|
||||
int (*start_poll)(struct nfc_hci_dev *hdev, u32 protocols);
|
||||
int (*target_from_gate)(struct nfc_hci_dev *hdev, u8 gate,
|
||||
struct nfc_target *target);
|
||||
int (*complete_target_discovered) (struct nfc_hci_dev *hdev, u8 gate,
|
||||
struct nfc_target *target);
|
||||
int (*data_exchange) (struct nfc_hci_dev *hdev,
|
||||
struct nfc_target *target,
|
||||
struct sk_buff *skb, struct sk_buff **res_skb);
|
||||
int (*check_presence)(struct nfc_hci_dev *hdev,
|
||||
struct nfc_target *target);
|
||||
};
|
||||
|
||||
open() and close() shall turn the hardware on and off. xmit() shall simply
|
||||
write a frame to the chip. start_poll() is an optional entrypoint that shall
|
||||
set the hardware in polling mode. This must be implemented only if the hardware
|
||||
uses proprietary gates or a mechanism slightly different from the HCI standard.
|
||||
target_from_gate() is another optional entrypoint to return the protocols
|
||||
- open() and close() shall turn the hardware on and off.
|
||||
- hci_ready() is an optional entry point that is called right after the hci
|
||||
session has been set up. The driver can use it to do additional initialization
|
||||
that must be performed using HCI commands.
|
||||
- xmit() shall simply write a frame to the chip.
|
||||
- start_poll() is an optional entrypoint that shall set the hardware in polling
|
||||
mode. This must be implemented only if the hardware uses proprietary gates or a
|
||||
mechanism slightly different from the HCI standard.
|
||||
- target_from_gate() is an optional entrypoint to return the nfc protocols
|
||||
corresponding to a proprietary gate.
|
||||
- complete_target_discovered() is an optional entry point to let the driver
|
||||
perform additional proprietary processing necessary to auto activate the
|
||||
discovered target.
|
||||
- data_exchange() must be implemented by the driver if proprietary HCI commands
|
||||
are required to send data to the tag. Some tag types will require custom
|
||||
commands, others can be written to using the standard HCI commands. The driver
|
||||
can check the tag type and either do proprietary processing, or return 1 to ask
|
||||
for standard processing.
|
||||
- check_presence() is an optional entry point that will be called regularly
|
||||
by the core to check that an activated tag is still in the field. If this is
|
||||
not implemented, the core will not be able to push tag_lost events to the user
|
||||
space
|
||||
|
||||
On the rx path, the driver is responsible to push incoming HCP frames to HCI
|
||||
using nfc_hci_recv_frame(). HCI will take care of re-aggregation and handling
|
||||
|
|
@ -99,7 +123,8 @@ fast, cannot sleep. stores incoming frames into an shdlc rx queue
|
|||
handles shdlc rx & tx queues. Dispatches HCI cmd responses.
|
||||
|
||||
- HCI Tx Cmd worker (MSGTXWQ)
|
||||
Serialize execution of HCI commands. Complete execution in case of resp timeout.
|
||||
Serializes execution of HCI commands. Completes execution in case of response
|
||||
timeout.
|
||||
|
||||
- HCI Rx worker (MSGRXWQ)
|
||||
Dispatches incoming HCI commands or events.
|
||||
|
|
@ -133,11 +158,11 @@ able to complete the command with a timeout error if no response arrive.
|
|||
SMW context gets scheduled and invokes nfc_shdlc_sm_work(). This function
|
||||
handles shdlc framing in and out. It uses the driver xmit to send frames and
|
||||
receives incoming frames in an skb queue filled from the driver IRQ handler.
|
||||
SHDLC I(nformation) frames payload are HCP fragments. They are agregated to
|
||||
SHDLC I(nformation) frames payload are HCP fragments. They are aggregated to
|
||||
form complete HCI frames, which can be a response, command, or event.
|
||||
|
||||
HCI Responses are dispatched immediately from this context to unblock
|
||||
waiting command execution. Reponse processing involves invoking the completion
|
||||
waiting command execution. Response processing involves invoking the completion
|
||||
callback that was provided by nfc_hci_msg_tx_work() when it sent the command.
|
||||
The completion callback will then wake the syscall context.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue