Currently, digital_target_found() has a race between
the events started by calling nfc_targets_found()
(which ultimately expect ddev->poll_tech_count to be
zero) and setting ddev->poll_tech_count to zero after
the call to nfc_targets_found().  When the race is
"lost" (i.e., ddev->poll_tech_count is found to not
be zero by the events started by nfc_targets_found()),
an error message is printed and the target is not found.
A similar race exists when digital_tg_recv_atr_req()
calls nfc_tm_activated().

Fix this by first saving the current value of
ddev->poll_tech_count and then clearing it before
calling nfc_targets_found()/nfc_tm_activated().
Clearing ddev->poll_tech_count before calling
nfc_targets_found()/nfc_tm_activated() eliminates
the race.  Saving the value is required so it can be
restored when nfc_targets_found()/nfc_tm_activated()
fails and polling needs to continue.
Acked-by: NThierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>