devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "christophe.ricard" <christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
Cc: linux-nfc-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
	christophe-h.ricard-qxv4g6HH51o@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC v2 00/14] Secure Element support for NCI based NFC controller, st21nfcb integration and EVT_TRANSACTION
Date: Wed, 28 Jan 2015 22:11:35 +0100	[thread overview]
Message-ID: <54C95087.9090702@gmail.com> (raw)
In-Reply-To: <1422476251-25972-1-git-send-email-christophe-h.ricard-qxv4g6HH51o@public.gmane.org>

Hi Samuel,

Please ignore this serie. It does not build.

Sorry for that.
Best Regards
Christophe
On 28/01/2015 21:17, Christophe Ricard wrote:
> Hi Samuel,
>
> This is a pre-send with an update including your comments on patch #20.
> Patch #27 is not yet modified. I hope to send something for review tonight.
>
> "
> I have to introduce dynnamic conn_id management has described in the NCI
> specification. Only RF static conn_id was supported so far. I have tried to
> do a minimun changeset in order to bring all the necessary NCI functions in
> order to operate with a secure element with ST21NFCB NFC controller. Besides the
> standard NCI commands, the HCI commands are sent following a proprietary
> implementation.
>
> Miscellaneous
> -------------
> I am also routing the HCI event TRANSACTION up to user space. It may help to understand
> the necessity to reference every pipe with a tuple {gate, host}. This for example allows
> to keep the host information generating this particular event.
>
> Open Questions:
> ---------------
> Both integration may have little gap in their card emulation behavior.
> For example:
> - ST21NFCA will have card emulation active as soon as we activate a secure element.
> - ST21NFCB will have card emulation active according to the selected polling mode.
> When do you expect to have card emulation to be active ?
>
> When an application is running, it might be necessary to signals to the under layers
> that it has finished to operate with a particular secure element. The goal here is to release
> a secure element without deactivating it. For example to allow automatic sleep mode.
> With my current implementation,
> - With ST21NFCB, enable_se/disable_se may fit this request as both secure element are kept activated.
> - With ST21NFCA, enable_se/disable_se does not fit this requirement as i am completely deactivating
> the secure element.
> I am not sure if the SE activation should not be done in the discovery_se without any deactivation
> until the device remove function(?).
> "
>
> Any feedback are welcome.
>
> Best Regards
> Christophe
>
> Christophe Ricard (14):
>    NFC: nci: Add dynamic conn_id NCI concept.
>    NFC: nci: Make nci_request available for nfc driver
>    NFC: nci: Add NCI NFCEE constant
>    NFC: nci: Add nci_nfcee_discover handler command/response/notification
>    NFC: nci: Add nci_nfcee_mode_set handler command/response
>    NFC: nci: Add nci_core_conn_create handler command/response
>    NFC: nci: Add nci_core_conn_close handler command/response
>    NFC: st21nfcb: Add HCI protocol over NCI protocol support
>    NFC: st21nfcb: Adding support for secure element
>    NFC: Forward NFC_EVT_TRANSACTION up to user space
>    NFC: nci: Add support RF_NFCEE_ACTION_NTF
>    NFC: nci: Change NCI state machine to LISTEN_ACTIVE and ignore
>      parameters in rf_intf_activated_ntf
>    NFC: st21nfcb: Add support for HCI event transaction
>    NFC: st21nfca: Add support for HCI event transaction
>
>   drivers/nfc/st21nfca/st21nfca_se.c       |  21 +
>   drivers/nfc/st21nfcb/Makefile            |   2 +-
>   drivers/nfc/st21nfcb/st21nfcb.c          |   8 +-
>   drivers/nfc/st21nfcb/st21nfcb.h          |   2 +
>   drivers/nfc/st21nfcb/st21nfcb_hci_core.c | 823 +++++++++++++++++++++++++++++++
>   drivers/nfc/st21nfcb/st21nfcb_hci_core.h | 134 +++++
>   drivers/nfc/st21nfcb/st21nfcb_se.c       | 631 ++++++++++++++++++++++++
>   drivers/nfc/st21nfcb/st21nfcb_se.h       |  59 +++
>   include/net/nfc/nci.h                    |  95 ++++
>   include/net/nfc/nci_core.h               |  41 +-
>   include/net/nfc/nfc.h                    |  27 +
>   include/uapi/linux/nfc.h                 |   1 +
>   net/nfc/core.c                           |  21 +
>   net/nfc/nci/core.c                       | 121 ++++-
>   net/nfc/nci/data.c                       |  72 ++-
>   net/nfc/nci/ntf.c                        |  93 +++-
>   net/nfc/nci/rsp.c                        | 100 +++-
>   net/nfc/netlink.c                        |  47 ++
>   net/nfc/nfc.h                            |   2 +
>   19 files changed, 2255 insertions(+), 45 deletions(-)
>   create mode 100644 drivers/nfc/st21nfcb/st21nfcb_hci_core.c
>   create mode 100644 drivers/nfc/st21nfcb/st21nfcb_hci_core.h
>   create mode 100644 drivers/nfc/st21nfcb/st21nfcb_se.c
>   create mode 100644 drivers/nfc/st21nfcb/st21nfcb_se.h
>

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      parent reply	other threads:[~2015-01-28 21:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 20:17 [RFC v2 00/14] Secure Element support for NCI based NFC controller, st21nfcb integration and EVT_TRANSACTION Christophe Ricard
     [not found] ` <1422476251-25972-1-git-send-email-christophe-h.ricard-qxv4g6HH51o@public.gmane.org>
2015-01-28 20:17   ` [RFC v2 01/14] NFC: nci: Add dynamic conn_id NCI concept Christophe Ricard
2015-01-28 20:17   ` [RFC v2 02/14] NFC: nci: Make nci_request available for nfc driver Christophe Ricard
2015-01-28 20:17   ` [RFC v2 03/14] NFC: nci: Add NCI NFCEE constant Christophe Ricard
2015-01-28 20:17   ` [RFC v2 04/14] NFC: nci: Add nci_nfcee_discover handler command/response/notification Christophe Ricard
2015-01-28 20:17   ` [RFC v2 05/14] NFC: nci: Add nci_nfcee_mode_set handler command/response Christophe Ricard
2015-01-28 20:17   ` [RFC v2 06/14] NFC: nci: Add nci_core_conn_create " Christophe Ricard
2015-01-28 20:17   ` [RFC v2 07/14] NFC: nci: Add nci_core_conn_close " Christophe Ricard
2015-01-28 20:17   ` [RFC v2 08/14] NFC: st21nfcb: Add HCI protocol over NCI protocol support Christophe Ricard
2015-01-28 20:17   ` [RFC v2 09/14] NFC: st21nfcb: Adding support for secure element Christophe Ricard
2015-01-28 20:17   ` [RFC v2 10/14] NFC: Forward NFC_EVT_TRANSACTION up to user space Christophe Ricard
2015-01-28 20:17   ` [RFC v2 11/14] NFC: nci: Add support RF_NFCEE_ACTION_NTF Christophe Ricard
2015-01-28 20:17   ` [RFC v2 12/14] NFC: nci: Change NCI state machine to LISTEN_ACTIVE and ignore parameters in rf_intf_activated_ntf Christophe Ricard
2015-01-28 20:17   ` [RFC v2 13/14] NFC: st21nfcb: Add support for HCI event transaction Christophe Ricard
2015-01-28 20:17   ` [RFC v2 14/14] NFC: st21nfca: " Christophe Ricard
2015-01-28 21:11   ` christophe.ricard [this message]

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=54C95087.9090702@gmail.com \
    --to=christophe.ricard-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=christophe-h.ricard-qxv4g6HH51o@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-nfc-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org \
    --cc=sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    /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).