HI Ilan, On Thu, Aug 18, 2011 at 3:43 AM, Elias, Ilan <ilane@xxxxxx> wrote: >> What happens if the driver is polling for targets or even with a >> remote target activated? The nfc_dev structure has some control to >> track the driver state (e.g. dev->polling) that must have their values >> updated. Otherwise, the next start_poll() call would fail with EBUSY. > You're correct, of course. > When dev_down is called and we have some active operation (e.g. polling, > active target), there are 2 approaches: > 1) stop internally any active operations and update internal states > (e.g. dev->polling). Please note that if we have an active data exchange, > the callback might not be called at all. > 2) simply return EBUSY and let the upper layers handle it. We don't use to interrupt a running command when a new one arrives. However, if dev_down/dev_up commands are intending to be used also as a reset procedure, the first approach is more suitable. Until now we didn't face any situation that required a reset procedure. So i would go with the second approach. > With both approaches, we'll have to keep track of active target state > (in addition to dev->polling). Which option do you prefer? Yes, that's true. Something like dev->remote_activated will be needed. Regards, Aloisio -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
