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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.