| 7c4b4fadb66959c50c170182847886e83393eebf |
|
02-Mar-2013 |
Martijn Coenen <maco@google.com> |
Fix some LLCP threading issues.
On Android we now start connecting SNEP/other LLCP
services as soon as the link comes up. That means
we will have connect requests incoming, accept
responses outgoing, connect requests outgoing and
accept responses incoming.
This lays bare a lot of threading issues in this lib.
Since the receives come in serialized, those typically
do not cause any issue. However, we may be sending
something on a thread coming from the NfcService,
while at the same time we'll receive for example
a connect frame from the remote, to which the receive
thread immediately wants to send a response.
This is a first attempt at making sends thread-safe:
already there was a lot of logic to deal with the fact
that another send was in progress, in the form of the
bSendPending variable. That variable was however
not checked atomically, and some operations did not
even set it correctly.
This change tests and sets that variable atomically,
more or less implementing a semaphore with try-acquires
and fallbacks for the failure case.
The generic structure is:
if (testAndSetSendPending()) {
// Another thread is sending, stash data
// and most importantly do *NOT* change shared data
} else {
// We're now the only one sending, we're free
// to change shared data until the callback is
// called.
}
This is just a band-aid fix, but given the fact that
this stack will be deprecated it is hopefully enough
for our planned usecases.
A decent fix would involve switching to
a TX-queue per socket, and a generic TX-queue
for the whole LLCP link. This allows us to fully
decouple the connection layer from the transport
layer, as it should be.
Change-Id: Ibd8742f7350a58459771f5036a049af3a487f783
/external/libnfc-nxp/src/phFriNfc_Llcp.h
|
| 7b187e70a5f0ffc021cc06a9f1a2bf2c0f8f8767 |
|
16-Jan-2012 |
Sunil Jogi <sunil.jogi@nxp.com> |
LLCP 1.1 implementation.
Previously, in LLCP v1.0, the only way to use the SDP (Service
Discovery Protocol) service was to send a CONNECT frame containing
the Service Name to the SDP service. This was implicitly
preforming a connection request to the requested service.
LLCP v1.1 introduced a way to discover services more efficiently
and without implicit connection. It also enables connectionless
services to have a service name. It is based on a new protocol
based on a new SNL frame containing discovery requests and
responses.
This update comes with new APIs:
- phLibNfc_Llcp_DiscoverServices() function can be used to discover
remote services. It can take multiple service names and resolve
all of them in a single call.
- Register service name at bind time. Cache LLCP service name/sap pairs.
In LLCP 1.1 specification defines at section 5.9 that any service
lookup answer must be valid for the whole LLCP session duration.
To enforce this, we cache the SAP/SN pairs locally and make sure
that the applications don't break the cache.
The stack remains fully retro-compatible with v1.0 devices.
Change-Id: I052edd3838013cee65e7415d0ed01fc3e9cad36d
/external/libnfc-nxp/src/phFriNfc_Llcp.h
|
| 3a9d18ff42ce17d62e1968ed93358d036989b670 |
|
23-May-2011 |
Sylvain Fonteneau <sylvain.fonteneau@trusted-logic.com> |
Check SAP range in LLCP sockets.
LLCP specification mentions that SAP numbers are allocated as follows:
- from 0x00 to 0x0F, used for well-known services
- from 0x10 to 0x1F, used for SDP advertised services
- from 0x20 to 0x3F, used for *non* SDP advertised services
This patch enforce this restriction.
Change-Id: Idd8ab4da4cfa9ad9e2dbf7eddc3c66900bcf9ff8
/external/libnfc-nxp/src/phFriNfc_Llcp.h
|
| 34ff48f6cd6595a899e05fbd56f4c84891840d3f |
|
27-Jun-2011 |
Nick Pelly <npelly@google.com> |
libnfc spring cleaning
o Fix most libnfc warnings, from 360 to 18
o Make DAL_DEBUG much less verbose and more useful
o Clean up Android.mk
Done with minimal textual diff to minimize merge conflicts.
Change-Id: I918645500723ff7bb092ad9959628fcabac45bec
/external/libnfc-nxp/src/phFriNfc_Llcp.h
|
| 651794422f331be5865ed8afcab6a56e3abe7521 |
|
14-Apr-2011 |
Sylvain Fonteneau <sylvain.fonteneau@trusted-logic.com> |
Fixed LLCP SAP value range.
Valid LLCP Service Access Point values are 0x00 to 0x3F, not 0x2F.
Before this patch, a socket with a local SAP between 0x30 and 0x3F
was unable to communicate (operation callbacks were never called).
Change-Id: Ic3f9b9f353a01e2682e28575152f171d7ec421e4
/external/libnfc-nxp/src/phFriNfc_Llcp.h
|
| 8608ad938da280b895e3bb71435d6fe34c589219 |
|
14-Jan-2011 |
Sylvain Fonteneau <sylvain.fonteneau@trusted-logic.com> |
Fixed LLCP receive window checkings.
Before sending a packet, the LLCP stack have to check if the remote
peer is ready to send. To do so, a Receive Window mechanism based on
packet numbering and acknowledgment is used.
Basically, the sender have to make sure that he must have not sent
more than RW-1 unaknowledged frames before sending a new one. This
patch is correcting this test which was failing in some situations.
Change-Id: I525f6b472a909ce48feb938aa02858b9456edc11
/external/libnfc-nxp/src/phFriNfc_Llcp.h
|
| 5d9927ba30ba449badb9f6df0fbeb4d6aedc6e2a |
|
23-Sep-2010 |
Nick Pelly <npelly@google.com> |
Initial libnfc checkin
Source: Trusted_NFC_Device_Host_AA03.01e02_google.zip code drop (23-Sep-2010)
Change-Id: Ie47f18423f949a8d3e0815d13f55c814312add24
Signed-off-by: Nick Pelly <npelly@google.com>
/external/libnfc-nxp/src/phFriNfc_Llcp.h
|