Re: [RFC] NFC subsystem prototype

[Lauro Ramos Venancio]

Hi Samuel,

2011/4/14 Samuel Ortiz <sameo@xxxxxxxxxxxxxxx>:

>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/