aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2012-05-22 16:07:23 -0400
committerDavid S. Miller <davem@davemloft.net>2012-05-22 16:07:23 -0400
commitc3719a1ef52eb1aadf77b7557cc9ca08124d8818 (patch)
tree9fc3737751948a71cde8f8ff64d1ca4cb0f44932 /Documentation
parent35c579070a349cfe54f9e09a47df2c5b68d58469 (diff)
parenta0d0d1685f9763ab26a394df3ab84026b39a06a7 (diff)
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 <davem@davemloft.net>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/feature-removal-schedule.txt12
-rw-r--r--Documentation/nfc/nfc-hci.txt45
2 files changed, 47 insertions, 10 deletions
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index e4b57756b9f5..04d81d26d5fe 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -534,6 +534,18 @@ Who: Kees Cook <keescook@chromium.org>
534 534
535---------------------------- 535----------------------------
536 536
537What: Removing the pn544 raw driver.
538When: 3.6
539Why: With the introduction of the NFC HCI and SHDL kernel layers, pn544.c
540 is being replaced by pn544_hci.c which is accessible through the netlink
541 and socket NFC APIs. Moreover, pn544.c is outdated and does not seem to
542 work properly with the latest Android stacks.
543 Having 2 drivers for the same hardware is confusing and as such we
544 should only keep the one following the kernel NFC APIs.
545Who: Samuel Ortiz <sameo@linux.intel.com>
546
547----------------------------
548
537What: setitimer accepts user NULL pointer (value) 549What: setitimer accepts user NULL pointer (value)
538When: 3.6 550When: 3.6
539Why: setitimer is not returning -EFAULT if user pointer is NULL. This 551Why: setitimer is not returning -EFAULT if user pointer is NULL. This
diff --git a/Documentation/nfc/nfc-hci.txt b/Documentation/nfc/nfc-hci.txt
index 216b7254fcc3..320f9336c781 100644
--- a/Documentation/nfc/nfc-hci.txt
+++ b/Documentation/nfc/nfc-hci.txt
@@ -22,9 +22,9 @@ response to arrive.
22HCI events can also be received from the host controller. They will be handled 22HCI events can also be received from the host controller. They will be handled
23and a translation will be forwarded to NFC Core as needed. 23and a translation will be forwarded to NFC Core as needed.
24HCI uses 2 execution contexts: 24HCI uses 2 execution contexts:
25- one if for executing commands : nfc_hci_msg_tx_work(). Only one command 25- one for executing commands : nfc_hci_msg_tx_work(). Only one command
26can be executing at any given moment. 26can be executing at any given moment.
27- one if for dispatching received events and responses : nfc_hci_msg_rx_work() 27- one for dispatching received events and commands : nfc_hci_msg_rx_work().
28 28
29HCI Session initialization: 29HCI Session initialization:
30--------------------------- 30---------------------------
@@ -52,18 +52,42 @@ entry points:
52struct nfc_hci_ops { 52struct nfc_hci_ops {
53 int (*open)(struct nfc_hci_dev *hdev); 53 int (*open)(struct nfc_hci_dev *hdev);
54 void (*close)(struct nfc_hci_dev *hdev); 54 void (*close)(struct nfc_hci_dev *hdev);
55 int (*hci_ready) (struct nfc_hci_dev *hdev);
55 int (*xmit)(struct nfc_hci_dev *hdev, struct sk_buff *skb); 56 int (*xmit)(struct nfc_hci_dev *hdev, struct sk_buff *skb);
56 int (*start_poll)(struct nfc_hci_dev *hdev, u32 protocols); 57 int (*start_poll)(struct nfc_hci_dev *hdev, u32 protocols);
57 int (*target_from_gate)(struct nfc_hci_dev *hdev, u8 gate, 58 int (*target_from_gate)(struct nfc_hci_dev *hdev, u8 gate,
58 struct nfc_target *target); 59 struct nfc_target *target);
60 int (*complete_target_discovered) (struct nfc_hci_dev *hdev, u8 gate,
61 struct nfc_target *target);
62 int (*data_exchange) (struct nfc_hci_dev *hdev,
63 struct nfc_target *target,
64 struct sk_buff *skb, struct sk_buff **res_skb);
65 int (*check_presence)(struct nfc_hci_dev *hdev,
66 struct nfc_target *target);
59}; 67};
60 68
61open() and close() shall turn the hardware on and off. xmit() shall simply 69- open() and close() shall turn the hardware on and off.
62write a frame to the chip. start_poll() is an optional entrypoint that shall 70- hci_ready() is an optional entry point that is called right after the hci
63set the hardware in polling mode. This must be implemented only if the hardware 71session has been set up. The driver can use it to do additional initialization
64uses proprietary gates or a mechanism slightly different from the HCI standard. 72that must be performed using HCI commands.
65target_from_gate() is another optional entrypoint to return the protocols 73- xmit() shall simply write a frame to the chip.
74- start_poll() is an optional entrypoint that shall set the hardware in polling
75mode. This must be implemented only if the hardware uses proprietary gates or a
76mechanism slightly different from the HCI standard.
77- target_from_gate() is an optional entrypoint to return the nfc protocols
66corresponding to a proprietary gate. 78corresponding to a proprietary gate.
79- complete_target_discovered() is an optional entry point to let the driver
80perform additional proprietary processing necessary to auto activate the
81discovered target.
82- data_exchange() must be implemented by the driver if proprietary HCI commands
83are required to send data to the tag. Some tag types will require custom
84commands, others can be written to using the standard HCI commands. The driver
85can check the tag type and either do proprietary processing, or return 1 to ask
86for standard processing.
87- check_presence() is an optional entry point that will be called regularly
88by the core to check that an activated tag is still in the field. If this is
89not implemented, the core will not be able to push tag_lost events to the user
90space
67 91
68On the rx path, the driver is responsible to push incoming HCP frames to HCI 92On the rx path, the driver is responsible to push incoming HCP frames to HCI
69using nfc_hci_recv_frame(). HCI will take care of re-aggregation and handling 93using 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
99handles shdlc rx & tx queues. Dispatches HCI cmd responses. 123handles shdlc rx & tx queues. Dispatches HCI cmd responses.
100 124
101- HCI Tx Cmd worker (MSGTXWQ) 125- HCI Tx Cmd worker (MSGTXWQ)
102Serialize execution of HCI commands. Complete execution in case of resp timeout. 126Serializes execution of HCI commands. Completes execution in case of response
127timeout.
103 128
104- HCI Rx worker (MSGRXWQ) 129- HCI Rx worker (MSGRXWQ)
105Dispatches incoming HCI commands or events. 130Dispatches incoming HCI commands or events.
@@ -133,11 +158,11 @@ able to complete the command with a timeout error if no response arrive.
133SMW context gets scheduled and invokes nfc_shdlc_sm_work(). This function 158SMW context gets scheduled and invokes nfc_shdlc_sm_work(). This function
134handles shdlc framing in and out. It uses the driver xmit to send frames and 159handles shdlc framing in and out. It uses the driver xmit to send frames and
135receives incoming frames in an skb queue filled from the driver IRQ handler. 160receives incoming frames in an skb queue filled from the driver IRQ handler.
136SHDLC I(nformation) frames payload are HCP fragments. They are agregated to 161SHDLC I(nformation) frames payload are HCP fragments. They are aggregated to
137form complete HCI frames, which can be a response, command, or event. 162form complete HCI frames, which can be a response, command, or event.
138 163
139HCI Responses are dispatched immediately from this context to unblock 164HCI Responses are dispatched immediately from this context to unblock
140waiting command execution. Reponse processing involves invoking the completion 165waiting command execution. Response processing involves invoking the completion
141callback that was provided by nfc_hci_msg_tx_work() when it sent the command. 166callback that was provided by nfc_hci_msg_tx_work() when it sent the command.
142The completion callback will then wake the syscall context. 167The completion callback will then wake the syscall context.
143 168