As previously mentioned in this list, a NFC (Near Field Communication)
subsystem is required to standardize the NFC device drivers
development and create an unified userspace interface. This email
describes our NFC subsystem proposal.
The NFC protocols implementation is divided in some parts:
* The NFC subsystem in the kernel side is responsible for:
- NFC adapters management;
- Polling for targets;
- Low level data exchange;
* All the commands to access the tags data (e.g. MIFARE commands:
READ, WRITE, SECTOR_SELECT) are implemented in the userspace using the
low level data exchange provided by kernel.
* The peer-to-peer NFC protocol (LLCP) will be implemented on kernel
side in order to provide a socket interface (DGRAM and STREAM) with
userspace. The LLCP will be implemented on top of the low level data
exchange provided by NFC subsystem.
+----------------------------------------------------+
| USER SPACE |
+----------------------------------------------------+
^ ^
| netlink |
v |
+---------------+ |
| nlnfc | | AF_NFC socket
+---------------+ |
^ |
| |
v v
+---------------+ +-----------------------------+
| nfccore | <--> | high-level-protocols (LLCP) |
+---------------+ +-----------------------------+
^
|
v
+---------------+
| Device driver |
+---------------+
In order to validate this idea, we developed a NFC subsystem prototype.
For testing purpose, we also implemented a device driver (PN533) and
an userspace test application.
The prototype implementation can be found at:
git://186.215.206.130/linux-nfc.git
The userspace test application (list targets and read/write MIFARE
tags) can be found at:
git://186.215.206.130/nfc-example.git
Prototype Scope:
- Tag Reader/Writer
- Protocols: MIFARE, ISO14443, FELICA, JEWEL
Subsystem Operations:
- start poll - start polling for targets using the protocols given as parameter
- stop poll - stop polling
- activate target - activate a target for communication using a
specific protocol
- deactivate target - deactivate a target
- reset device - put the adapter in idle mode
- data exchange - low level data exchange (send and receive data)
Subsystem Event:
- targets found - report all targets found by the polling
Device Driver Interface:
The device driver interface is a direct correspondence from the NFC
subsystem interface.
User space interface:
When we were designing this subsystem, we were in doubt between
netlink (as in nl80211) and sockets (as in bluez) for userspace
communication. For this prototype, we decided to use generic netlink.
However, the netlink choice has not proven to be the best solution for
the data exchange operation. So we plan to have a new prototype
version using another solution. The options are:
- sockets for all operations as in bluez implementation;
- sockets for data exchange and keep netlink for the other operations.
Further work:
- Define subsystem operations for adapters in "target mode"
- Implement LLCP
- Add support to the "secure elements"
Regards,
Lauro Ramos Venancio
INdT - Instituto Nokia de Tecnologia
Hi Lauro,
On Wed, Apr 06, 2011 at 07:17:19PM -0300, Lauro Ramos Venancio wrote:
> As previously mentioned in this list, a NFC (Near Field Communication)
> subsystem is required to standardize the NFC device drivers
> development and create an unified userspace interface. This email
> describes our NFC subsystem proposal.
given that I've done quite some work on RFID (mifare, iso14443) and NFC
software + hardware some years ago, here is some feedback from my side:
0) why not create a general RFID subsystem instead of locking it down to
NFC? NFC is sort-of a superset of ISO 14443, so it would make more
sense to have a generic framework that can support not only Mifare + NFC
but all types of ISO 14443 (A / B) as well as ISO 15693. This would mean
other applications like electronic ID cards and ICAO-compliant passports
would fit into the picture - even though not being NFC
1) do you really think a kernel subsystem is the best idea for this?
normally, the RFID/NFC ASIC is attached either to USB or serial lines,
and there are no timing constraints against userspace drivers using libusb,
like the existing libnfc or librfid.
Yes, there may be multiple applications using RFID/NFC services, but
if you look at e.g. the smart card frameworks like OpenCT and/or pcsc-lite,
they can do that very well in userspace, without any kernel support.
If you're worried about SPI-attached RFID/NFC ASICs, then I think the
propper approach is to have a generic support for exporting SPI devices to
userspace (similar to what we have with usb + libusb).
I simply do not see the advantage of having this in the kenrel. There are
no latency/timing constraints, and the amount of data you are moving is so
small, that performance considerations also don't really play any role.
2) even if you go for an in-kernel subsystem, what is your strategy for the
many existing CL-RC5xx / CL-RC6xx ASIC based RFID/NFC readers? For them,
you typically need your own software implementation of the anti-collision
procedures of 14443-3 (a+b) and the T=CL (14443-4) code. All of this has
been implemented in userspace e.g. librfid - but do you want to port or
re-implement it all in kernel-land, and then 'glue' it below your current
NFC subsystem approach?
Regards,
Harald
--
- Harald Welte <[email protected]> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
> If you're worried about SPI-attached RFID/NFC ASICs, then I think the
> propper approach is to have a generic support for exporting SPI devices to
> userspace (similar to what we have with usb + libusb).
That bit in my experience doesn't work. Most i²c devices for example end
up needing an actual kernel driver because you have to manage the
transaction flow to stop users breaking things horribly.
> I simply do not see the advantage of having this in the kenrel. There are
> no latency/timing constraints, and the amount of data you are moving is so
> small, that performance considerations also don't really play any role.
The big one is security management - once you've got readers that are
needing to report different stuff to different people you need at least
the muxing in kernel. It also separates protocol stacks from apps which
is rather important in more complex systems.
> 2) even if you go for an in-kernel subsystem, what is your strategy for the
> many existing CL-RC5xx / CL-RC6xx ASIC based RFID/NFC readers? For them,
> you typically need your own software implementation of the anti-collision
> procedures of 14443-3 (a+b) and the T=CL (14443-4) code. All of this has
> been implemented in userspace e.g. librfid - but do you want to port or
> re-implement it all in kernel-land, and then 'glue' it below your current
> NFC subsystem approach?
The obvious thing would be to plug it into the kernel at a higher level
than the raw asic interface. We manage that sort of stuff with all sorts
of network devices just fine, and in fact we'll need chunks of that
anyway for virtualisation of rfid/nfc.
Hi Harald,
2011/4/9 Harald Welte <[email protected]>:
> Hi Lauro,
>
> On Wed, Apr 06, 2011 at 07:17:19PM -0300, Lauro Ramos Venancio wrote:
>> As previously mentioned in this list, a NFC (Near Field Communication)
>> subsystem is required to standardize the NFC device drivers
>> development and create an unified userspace interface. This email
>> describes our NFC subsystem proposal.
>
> given that I've done quite some work on RFID (mifare, iso14443) and NFC
> software + hardware some years ago, here is some feedback from my side:
>
> 0) why not create a general RFID subsystem instead of locking it down to
> NFC? NFC is sort-of a superset of ISO 14443, so it would make more
> sense to have a generic framework that can support not only Mifare + NFC
> but all types of ISO 14443 (A / B) as well as ISO 15693. This would mean
> other applications like electronic ID cards and ICAO-compliant passports
> would fit into the picture - even though not being NFC
The prototype supports ISO 14443 (A/B), MIFARE, Felica and Jewel. It's
straightforward to add ISO 15693 support. So I think it is possible to
support these applications using the NFC subsystem.
>
> 1) do you really think a kernel subsystem is the best idea for this?
> normally, the RFID/NFC ASIC is attached either to USB or serial lines,
> and there are no timing constraints against userspace drivers using libusb,
> like the existing libnfc or librfid.
>
> Yes, there may be multiple applications using RFID/NFC services, but
> if you look at e.g. the smart card frameworks like OpenCT and/or pcsc-lite,
> they can do that very well in userspace, without any kernel support.
>
> If you're worried about SPI-attached RFID/NFC ASICs, then I think the
> propper approach is to have a generic support for exporting SPI devices to
> userspace (similar to what we have with usb + libusb).
>
> I simply do not see the advantage of having this in the kenrel. There are
> no latency/timing constraints, and the amount of data you are moving is so
> small, that performance considerations also don't really play any role.
The advantages appear when you consider the NFC peer-to-peer use case
(LLCP). A socket interface for LLCP would fit better for implementing
some features, such as OBEX over LLCP and IP over LLCP.
The prototype implements in the kernel the minimal set of operations
that will be required by a future LLCP implementation. The same set of
operations are used by userspace applications to implements tag
read/write.
Regards,
Lauro Ramos Venancio
INdT - Instituto Nokia de Tecnologia
Alan,
On Sat, Apr 09, 2011 at 06:45:59PM +0100, Alan Cox wrote:
> > If you're worried about SPI-attached RFID/NFC ASICs, then I think the
> > propper approach is to have a generic support for exporting SPI devices to
> > userspace (similar to what we have with usb + libusb).
>
> That bit in my experience doesn't work. Most i?c devices for example end
> up needing an actual kernel driver because you have to manage the
> transaction flow to stop users breaking things horribly.
luckily the NFC controller landscape is extremely monolithic, i.e. there are
not many vendors (+ chips) that need support, so it _may_ still be an option
to have that small 'actual kernel driver'. But I agree, it is ugly.
> > I simply do not see the advantage of having this in the kenrel. There are
> > no latency/timing constraints, and the amount of data you are moving is so
> > small, that performance considerations also don't really play any role.
>
> The big one is security management - once you've got readers that are
> needing to report different stuff to different people you need at least
> the muxing in kernel.
I doubt that NFC is envisioned as a 'multiple simultaneous users in a device'
application - so I'm not sure how valid that argument really ise. In any case,
you would also have to have some kind of access control lists or similar in the
kernel to decide which user can talk to which card UID, or mifare application ID,
or similar identifier on the respective higher-level protocol.
> It also separates protocol stacks from apps which is rather important in more
> complex systems.
The separation can also be had in userspace, i.e. have a shared ISO 14443 stack
inside the multiplex daemon, and have applications talk at a much higher level
API.
> > 2) even if you go for an in-kernel subsystem, what is your strategy for the
> > many existing CL-RC5xx / CL-RC6xx ASIC based RFID/NFC readers? For them,
> > you typically need your own software implementation of the anti-collision
> > procedures of 14443-3 (a+b) and the T=CL (14443-4) code. All of this has
> > been implemented in userspace e.g. librfid - but do you want to port or
> > re-implement it all in kernel-land, and then 'glue' it below your current
> > NFC subsystem approach?
>
> The obvious thing would be to plug it into the kernel at a higher level
> than the raw asic interface. We manage that sort of stuff with all sorts
> of network devices just fine, and in fact we'll need chunks of that
> anyway for virtualisation of rfid/nfc.
Actually, I'm not sure if we understand each other correctly.
The case that Lauro seems to be implementing right now, is with a RFID
controller that includes the analog+digital transceiver, as well as runs the
RFID protocol stack (ISO 14443) inside a 8051 based microcontroller. This is
what is on Linux so far mostly used in combination with libnfc in userspace.
The case I was talking about is the opposite: You have a pure SPI/I2C (or often
through a protocol converter USB) attached RFID transceiver and have to
implement the protocol stack on the main CPU. This is what you you would so
far drive from something like librfid in userspace.
If there is concensus that this all should live in kernel space, I could
try to find some time to work on an initial librfid-to-kernel port.
What is definitely needed then is some kind of PC/SC integration on the
userspace side, i.e. an ifdhandler that can plug into pcscd, as most of
the (non-NFC) ISO 14443 applications today (electronic passports, VISA, ID
card, ...) simply assume a smart card interface.
Regards,
Harald
--
- Harald Welte <[email protected]> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi Lauro,
On Mon, Apr 11, 2011 at 08:31:11PM -0300, Lauro Ramos Venancio wrote:
> 2011/4/9 Harald Welte <[email protected]>:
>
> > 0) why not create a general RFID subsystem instead of locking it down to
> > ? NFC? ?NFC is sort-of a superset of ISO 14443, so it would make more
> > ? sense to have a generic framework that can support not only Mifare + NFC
> > ? but all types of ISO 14443 (A / B) as well as ISO 15693. ?This would mean
> > ? other applications like electronic ID cards and ICAO-compliant passports
> > ? would fit into the picture - even though not being NFC
>
> The prototype supports ISO 14443 (A/B), MIFARE, Felica and Jewel. It's
> straightforward to add ISO 15693 support. So I think it is possible to
> support these applications using the NFC subsystem.
Then I suggest renaming the system. I think it is a bit confusing to call
something NFC if in fact it is a way more generic RFID system for most common
13.56MHz based systems.
In other words: NFC depends on ISO 14443, but ISO 14443 does not depend on NFC,
so it would be a bit unconventional or unintuitive to use a NFC subsystem to
talk with non-NFC ISO 14443 cards/transponders.
Also, I'm not quite clear what's the situation with regard to the NFC trademark,
i.e. if it wise to use the trademark. There has been one previous case with
the 'firewire' situation, where firewire is the trademark and IEEE 1394 the name
of the technical specification - and the the Linux subsystem is alled
'ieee1394'...
> > 1) do you really think a kernel subsystem is the best idea for this?
> > ? normally, the RFID/NFC ASIC is attached either to USB or serial lines,
> > ? and there are no timing constraints against userspace drivers using libusb,
> > ? like the existing libnfc or librfid.
>
> The advantages appear when you consider the NFC peer-to-peer use case
> (LLCP). A socket interface for LLCP would fit better for implementing
> some features, such as OBEX over LLCP and IP over LLCP.
Ok, I fully agree for the case of OBEX and IP. This did not occur to me when I
made my earlier comment.
Regards,
Harald
--
- Harald Welte <[email protected]> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Harald Welte wrote:
> Also, I'm not quite clear what's the situation with regard to the NFC trademark,
As far as I can tell, "NFC" itself isn't trademarked; it's used in the
ISO standard, and the Wikipedia page mentions several organizations like
NFC World, NFC Times, NFC Lab, and http://www.libnfc.org. (What _is_
trademarked is the "N-Mark": <http://www.nfc-forum.org/resources/N-Mark>.)
> i.e. if it wise to use the trademark. There has been one previous case with
> the 'firewire' situation, where firewire is the trademark and IEEE 1394 the name
> of the technical specification - and the the Linux subsystem is alled
> 'ieee1394'...
In recent kernels, the "ieee1394" subsystem has been replaced by the new
subsystem named "firewire" (and called "Juju").
Regards,
Clemens
Hi Lauro,
Lauro Ramos Venancio <lauro.venancio <at> openbossa.org> writes:
> The prototype implementation can be found at:
> git://186.215.206.130/linux-nfc.git
>
> The userspace test application (list targets and read/write MIFARE
> tags) can be found at:
> git://186.215.206.130/nfc-example.git
Really nice. What about putting those in e.g. gitorious ?
> Prototype Scope:
> - Tag Reader/Writer
> - Protocols: MIFARE, ISO14443, FELICA, JEWEL
>
> Subsystem Operations:
> - start poll - start polling for targets using the protocols given as
> parameter
> - stop poll - stop polling
> - activate target - activate a target for communication using a
> specific protocol
> - deactivate target - deactivate a target
> - reset device - put the adapter in idle mode
> - data exchange - low level data exchange (send and receive data)
I suppose the data_exchange hook is sitting at the NFCIP level ? As I agree
with your further comment that this one should not be part of the netlink
API but should be done through sockets instead, I think this one should be
defined as the netdev start_xmit hook.
So this matches quite well the pn533 API, but I'm wondering how you're
planning to support the HCI based devices (pn544, microread). We clearly
have 2 kind of devices here, and it reminds me of the soft MAC vs full MAC
problem in the 802.11 subsystem.
I think we should have a kernel NFC HCI layer that would implement those
hooks by following the HCP protocol. Then devices that only take HCI
commands (kind of soft MAC NFC devices) would register against the NFC HCI
layer and use those hooks. Other devices (e.g. pn533) would register at a
higher level (The NFC core layer) and provide their own hooks. This would be
similar to what 802.11 drivers do by registering against mac80211 (soft MACs)
or directly against cfg80211 (full MACs).
> Subsystem Event:
> - targets found - report all targets found by the polling
I would like to see a target lost event here as well, but as far as I know,
none of the various NFC specs specify such event. So I guess we get to know
that e.g. a tag is not there anymore when failing to read from it.
> However, the netlink choice has not proven to be the best solution for
> the data exchange operation. So we plan to have a new prototype
> version using another solution. The options are:
> - sockets for all operations as in bluez implementation;
> - sockets for data exchange and keep netlink for the other operations.
I would personally prefer to have a netlink layer for basically anything
except data I/O, and go with a socket for the rest.
>
> Further work:
> - Define subsystem operations for adapters in "target mode"
I am not sure we need any specific additional hook for the target mode. In
this mode, we mostly would be sending events (RF field ON, card activated
or deactivated). After that, afaiu, the card would be expecting data
reception, and then sending responses to it.
We probably need to add a mode setting hook in the ops structure. And also,
according to NFCIP-2, NFC devices should by default be in target mode.
> - Implement LLCP
> - Add support to the "secure elements"
I'm also wondering how we're going to support the various CCID USB NFC
readers currently available ? At the moment this is all done through libusb
and pcsc-lite in userspace, but it would be nice to see that integrated
with this subsystem.
Cheers,
Samuel.
Hi Harald,
2011/4/12 Harald Welte <[email protected]>:
> Hi Lauro,
>
> On Mon, Apr 11, 2011 at 08:31:11PM -0300, Lauro Ramos Venancio wrote:
>
>> 2011/4/9 Harald Welte <[email protected]>:
>>
>> > 0) why not create a general RFID subsystem instead of locking it down to
>> > NFC? NFC is sort-of a superset of ISO 14443, so it would make more
>> > sense to have a generic framework that can support not only Mifare + NFC
>> > but all types of ISO 14443 (A / B) as well as ISO 15693. This would mean
>> > other applications like electronic ID cards and ICAO-compliant passports
>> > would fit into the picture - even though not being NFC
>>
>> The prototype supports ISO 14443 (A/B), MIFARE, Felica and Jewel. It's
>> straightforward to add ISO 15693 support. So I think it is possible to
>> support these applications using the NFC subsystem.
>
> Then I suggest renaming the system. I think it is a bit confusing to call
> something NFC if in fact it is a way more generic RFID system for most common
> 13.56MHz based systems.
>
> In other words: NFC depends on ISO 14443, but ISO 14443 does not depend on NFC,
> so it would be a bit unconventional or unintuitive to use a NFC subsystem to
> talk with non-NFC ISO 14443 cards/transponders.
>
The boundary between NFC and RFID is not fully clear. This prototype
was developed based on NFC Forum documents. NFC Forum tags use all
these protocols (Jewel - Tag 1, Mifare - Tag 2, Felica - Tag 3,
ISO14443 - Tag 4).
My concern on renaming the subsystem is to ensure that its interface
is suitable also for the non-NFC Forum tags.
Regards,
Lauro Ramos Venancio
INdT - Instituto Nokia de Tecnologia
Hi Samuel,
2011/4/14 Samuel Ortiz <[email protected]>:
>> Subsystem Operations:
>> - start poll - start polling for targets using the protocols given as
>> parameter
>> - stop poll - stop polling
>> - activate target - activate a target for communication using a
>> specific protocol
>> - deactivate target - deactivate a target
>> - reset device - put the adapter in idle mode
>> - data exchange - low level data exchange (send and receive data)
> I suppose the data_exchange hook is sitting at the NFCIP level ? As I agree
> with your further comment that this one should not be part of the netlink
> API but should be done through sockets instead, I think this one should be
> defined as the netdev start_xmit hook.
> So this matches quite well the pn533 API, but I'm wondering how you're
> planning to support the HCI based devices (pn544, microread). We clearly
> have 2 kind of devices here, and it reminds me of the soft MAC vs full MAC
> problem in the 802.11 subsystem.
> I think we should have a kernel NFC HCI layer that would implement those
> hooks by following the HCP protocol. Then devices that only take HCI
> commands (kind of soft MAC NFC devices) would register against the NFC HCI
> layer and use those hooks. Other devices (e.g. pn533) would register at a
> higher level (The NFC core layer) and provide their own hooks. This would be
> similar to what 802.11 drivers do by registering against mac80211 (soft MACs)
> or directly against cfg80211 (full MACs).
I fully agree. The prototype was designed with pn533 and pn544 in
mind. When the pn544 device driver is implemented, we will need
another layer for the HCI implementation.
>> Further work:
>> - Define subsystem operations for adapters in "target mode"
> I am not sure we need any specific additional hook for the target mode. In
> this mode, we mostly would be sending events (RF field ON, card activated
> or deactivated). After that, afaiu, the card would be expecting data
> reception, and then sending responses to it.
I think the main part is the handling of timing constraints between
the data reception and the response using a socket interface.
> We probably need to add a mode setting hook in the ops structure. And also,
> according to NFCIP-2, NFC devices should by default be in target mode.
The selection between proximity and vicinity is partially covered by
the protocols selection in start_poll operation.
Probably, the polling loop needs to have an initiator mode phase and a
target mode phase in a cycle (as the PN544 Polling management).
Regards,
Lauro Ramos Venancio
INdT - Instituto Nokia de Tecnologia
Hi Lauro,
On Thu, Apr 14, 2011 at 07:57:57PM -0300, Lauro Ramos Venancio wrote:
> 2011/4/14 Samuel Ortiz <[email protected]>:
>
> >> Subsystem Operations:
> >> ? ? ? - start poll - start polling for targets using the protocols given as
> >> parameter
> >> ? ? ? - stop poll - stop polling
> >> ? ? ? - activate target - activate a target for communication using a
> >> specific protocol
> >> ? ? ? - deactivate target - deactivate a target
> >> ? ? ? - reset device - put the adapter in idle mode
> >> ? ? ? - data exchange - low level data exchange (send and receive data)
> > I suppose the data_exchange hook is sitting at the NFCIP level ? As I agree
> > with your further comment that this one should not be part of the netlink
> > API but should be done through sockets instead, I think this one should be
> > defined as the netdev start_xmit hook.
> > So this matches quite well the pn533 API, but I'm wondering how you're
> > planning to support the HCI based devices (pn544, microread). We clearly
> > have 2 kind of devices here, and it reminds me of the soft MAC vs full MAC
> > problem in the 802.11 subsystem.
> > I think we should have a kernel NFC HCI layer that would implement those
> > hooks by following the HCP protocol. Then devices that only take HCI
> > commands (kind of soft MAC NFC devices) would register against the NFC HCI
> > layer and use those hooks. Other devices (e.g. pn533) would register at a
> > higher level (The NFC core layer) and provide their own hooks. This would be
> > similar to what 802.11 drivers do by registering against mac80211 (soft MACs)
> > or directly against cfg80211 (full MACs).
>
> I fully agree. The prototype was designed with pn533 and pn544 in
> mind. When the pn544 device driver is implemented, we will need
> another layer for the HCI implementation.
Are you guys planning to start working on the pn544 driver ? In theory the HCI
layer should be implemented first but I suppose those 2 can be done in
parallel, and I can start looking at the HCI parts. At least all the
registration one and the netdev interaction as well.
>
> >> Further work:
> >> ? ? ? - Define subsystem operations for adapters in "target mode"
> > I am not sure we need any specific additional hook for the target mode. In
> > this mode, we mostly would be sending events (RF field ON, card activated
> > or deactivated). After that, afaiu, the card would be expecting data
> > reception, and then sending responses to it.
>
> I think the main part is the handling of timing constraints between
> the data reception and the response using a socket interface.
What are those constraints ?
> > We probably need to add a mode setting hook in the ops structure. And also,
> > according to NFCIP-2, NFC devices should by default be in target mode.
>
> The selection between proximity and vicinity is partially covered by
> the protocols selection in start_poll operation.
>
> Probably, the polling loop needs to have an initiator mode phase and a
> target mode phase in a cycle (as the PN544 Polling management).
That is something that is still not clear to me, to be honest with you. When
in initiator mode, are we suppose to run regular polling cycles ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
2011/4/14 Samuel Ortiz <[email protected]>:
> Hi Lauro,
>
> On Thu, Apr 14, 2011 at 07:57:57PM -0300, Lauro Ramos Venancio wrote:
>> 2011/4/14 Samuel Ortiz <[email protected]>:
>>
>> >> Subsystem Operations:
>> >> - start poll - start polling for targets using the protocols given as
>> >> parameter
>> >> - stop poll - stop polling
>> >> - activate target - activate a target for communication using a
>> >> specific protocol
>> >> - deactivate target - deactivate a target
>> >> - reset device - put the adapter in idle mode
>> >> - data exchange - low level data exchange (send and receive data)
>> > I suppose the data_exchange hook is sitting at the NFCIP level ? As I agree
>> > with your further comment that this one should not be part of the netlink
>> > API but should be done through sockets instead, I think this one should be
>> > defined as the netdev start_xmit hook.
>> > So this matches quite well the pn533 API, but I'm wondering how you're
>> > planning to support the HCI based devices (pn544, microread). We clearly
>> > have 2 kind of devices here, and it reminds me of the soft MAC vs full MAC
>> > problem in the 802.11 subsystem.
>> > I think we should have a kernel NFC HCI layer that would implement those
>> > hooks by following the HCP protocol. Then devices that only take HCI
>> > commands (kind of soft MAC NFC devices) would register against the NFC HCI
>> > layer and use those hooks. Other devices (e.g. pn533) would register at a
>> > higher level (The NFC core layer) and provide their own hooks. This would be
>> > similar to what 802.11 drivers do by registering against mac80211 (soft MACs)
>> > or directly against cfg80211 (full MACs).
>>
>> I fully agree. The prototype was designed with pn533 and pn544 in
>> mind. When the pn544 device driver is implemented, we will need
>> another layer for the HCI implementation.
> Are you guys planning to start working on the pn544 driver ? In theory the HCI
> layer should be implemented first but I suppose those 2 can be done in
> parallel, and I can start looking at the HCI parts. At least all the
> registration one and the netdev interaction as well.
We are not implementing the pn544 device driver. So, it would be very
nice if you can implement the HCI part.
Our short term plans are:
- Decide the best name for the subsystem (nfc or rfid).
- Improve the data exchange operation using sockets (2nd prototype)
- Send the patches
>> >> Further work:
>> >> - Define subsystem operations for adapters in "target mode"
>> > I am not sure we need any specific additional hook for the target mode. In
>> > this mode, we mostly would be sending events (RF field ON, card activated
>> > or deactivated). After that, afaiu, the card would be expecting data
>> > reception, and then sending responses to it.
>>
>> I think the main part is the handling of timing constraints between
>> the data reception and the response using a socket interface.
> What are those constraints ?
The response must be sent before the timeout (about 5ms).
>> > We probably need to add a mode setting hook in the ops structure. And also,
>> > according to NFCIP-2, NFC devices should by default be in target mode.
>>
>> The selection between proximity and vicinity is partially covered by
>> the protocols selection in start_poll operation.
>>
>> Probably, the polling loop needs to have an initiator mode phase and a
>> target mode phase in a cycle (as the PN544 Polling management).
> That is something that is still not clear to me, to be honest with you. When
> in initiator mode, are we suppose to run regular polling cycles ?
It's not mandatory. The pn533 looks for targets only once using only
one protocol. The pn544 implements a polling cycle looking for targets
using many protocols.
In the subsystem, we decided to use a polling cycle (start poll/stop
poll) that receive as parameter the protocols to be used. For the
pn533, we implemented the polling cycle in the device driver as the
device does not support it.
When implementing the target mode in the subsystem, we may add a
target mode phase in the polling cycle.
Regards,
Lauro Ramos Venancio
INdT - Instituto Nokia de Tecnologia