Combine transceive() functionality about libnfc HOT 15 CLOSED

What do you think about:
 - add "_t" suffix to types (defined using typedef), 
 - append "nfc_" prefix, IMHO it should be cleaner.
 - found a self-explained name for struct and typedef

i.e.:
 - init_modulation => nfc_modulation_t
 - dev_info => nfc_device_t
 - etc.

In my opinion the "nfc_device" terminology is ambiguous because it's not clear 
if a
device is the user NFC chip or a third party NFC active device.

Fine Zuck, what do you purpose ?

Could "nfc_adaptor_t" be a good option?

These two sound nice:
 - init_modulation => nfc_modulation_t
 - dev_info => nfc_adaptor_t

I will try to look into the init_modulation_t struct. It should be a straight 
forward
usable syntax.

Remember to change "nfc_device_desc_t" too:

nfc_device_desc_t => nfc_adaptor_desc_t

init_modulation => nfc_modulation_t
is not correct.... since talk about the "initial modulation" (for 
anti-collision)
later you can boost up the speed (change modulation). This is not (yet) 
supported,
but the initial modulation will never change... (for example for a ISO14443-A 
card)

so it sould be then ?:)
init_modulation => nfc_init_modulation_t

Yes, I think you're right.

Roel, if I understand correctly, I'm not agree with you on this point, a typedef
define a type, the nature of described thing. "initial modulation" is a 
modulation,
of course when I read your comment I understand there is a "current modulation" 
and
an "init modulation" but that seems to be variables roles, not types. I think we
should have a nfc_modulation_t type which can be ISO14443A_106, FELICA_212, 
etc. and
two variables nmInitModulation and nmCurrentModulation in the right structure.
Did I misunderstood something ?

The main idea of this issue is now fixed since r452.