From: Samuel Ortiz <sameo@linux.intel.com>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: Lauro Ramos Venancio <lauro.venancio@openbossa.org>,
Aloisio Almeida Jr <aloisio.almeida@openbossa.org>,
Ilan Elias <ilane@ti.com>,
linux-wireless@vger.kernel.org,
Eric Lapuyade <eric.lapuyade@intel.com>,
Samuel Ortiz <sameo@linux.intel.com>
Subject: [PATCH 06/20] NFC: Update Documentation/nfc-hci.txt
Date: Mon, 7 May 2012 12:31:17 +0200 [thread overview]
Message-ID: <1336386691-24840-7-git-send-email-sameo@linux.intel.com> (raw)
In-Reply-To: <1336386691-24840-1-git-send-email-sameo@linux.intel.com>
From: Eric Lapuyade <eric.lapuyade@intel.com>
Document the new HCI ops and fix a few typos and spelling mistakes.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
---
Documentation/nfc/nfc-hci.txt | 45 +++++++++++++++++++++++++++++++---------
1 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/Documentation/nfc/nfc-hci.txt b/Documentation/nfc/nfc-hci.txt
index 216b725..320f933 100644
--- a/Documentation/nfc/nfc-hci.txt
+++ b/Documentation/nfc/nfc-hci.txt
@@ -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.
--
1.7.9.1
next prev parent reply other threads:[~2012-05-07 10:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-07 10:31 [PATCH 00/20] NFC updates for 3.5 Samuel Ortiz
2012-05-07 10:31 ` [PATCH 01/20] NFC: Fix up for NLA_PUT_ api changes Samuel Ortiz
2012-05-07 13:01 ` Stephen Rothwell
2012-05-07 10:31 ` [PATCH 02/20] NFC: Cache the core NFC active target pointer instead of its index Samuel Ortiz
2012-05-07 10:31 ` [PATCH 03/20] NFC: Remove useless HCI private nfc target table Samuel Ortiz
2012-05-07 10:31 ` [PATCH 04/20] NFC: Specify usage for targets found and target lost events Samuel Ortiz
2012-05-07 10:31 ` [PATCH 05/20] NFC: Add HCI/SHDLC support to let driver check for tag presence Samuel Ortiz
2012-05-07 10:31 ` Samuel Ortiz [this message]
2012-05-07 10:31 ` [PATCH 07/20] NFC: Remove unneeded pn533 dev NULL check Samuel Ortiz
2012-05-07 10:31 ` [PATCH 08/20] NFC: LLCP connect must wait for a CC frame Samuel Ortiz
2012-05-07 10:31 ` [PATCH 09/20] NFC: Update the LLCP poll mask Samuel Ortiz
2012-05-07 10:31 ` [PATCH 10/20] NFC: Return the amount of LLCP bytes queued to sock_sendmsg Samuel Ortiz
2012-05-07 10:31 ` [PATCH 11/20] NFC: Send device index instead of its name when target is lost Samuel Ortiz
2012-05-07 10:31 ` [PATCH 12/20] NFC: Fix LLCP compilation warning Samuel Ortiz
2012-05-07 10:31 ` [PATCH 13/20] NFC: Quiet nci/data.c sparse noise about plain integer as NULL pointer Samuel Ortiz
2012-05-07 10:31 ` [PATCH 14/20] NFC: Include nci_core.h to nci/lib.c Samuel Ortiz
2012-05-07 10:31 ` [PATCH 15/20] NFC: Quiet nci/ntf.c sparse noise about plain integer as NULL pointer Samuel Ortiz
2012-05-07 10:31 ` [PATCH 16/20] NFC: HCI ops should not be exposed globally Samuel Ortiz
2012-05-07 10:31 ` [PATCH 17/20] NFC: The NFC genl family structure " Samuel Ortiz
2012-05-07 10:31 ` [PATCH 18/20] NFC: HCI based pn544 driver Samuel Ortiz
2012-05-07 10:31 ` [PATCH 19/20] feature-removal: Remove pn544 raw driver Samuel Ortiz
2012-05-07 10:31 ` [PATCH 20/20] NFC: HCI drivers don't have to keep track of polling state Samuel Ortiz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1336386691-24840-7-git-send-email-sameo@linux.intel.com \
--to=sameo@linux.intel.com \
--cc=aloisio.almeida@openbossa.org \
--cc=eric.lapuyade@intel.com \
--cc=ilane@ti.com \
--cc=lauro.venancio@openbossa.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).