Re: [[linux-nfc] PATCH v5 2/3] driver: nfc: Add ST95HF NFC Transceiver support

Samuel Ortiz
2015-12-21T22:45:46Z

Hi Shikha,

On Mon, Dec 21, 2015 at 07:57:23PM +0800, Shikha SINGH wrote:
> Hello Samuel,
> Please see my answer below.
>
> >This looks a lot better than the initial version.
> >I only have one question:
> >
> >On Fri, Nov 20, 2015 at 06:40:20AM -0500, Shikha Singh wrote:
> >> +/*
> >> + * st95hf_send_recv_cmd() is for sending commands to ST95HF
> >> + * that are described in the cmd_array[]. It can optionally
> >> + * receive the response if the cmd request is of type
> >> + * SYNC. For that to happen caller must pass true to recv_res.
> >> + * For ASYNC request, recv_res is ignored and the
> >> + * function will never try to receive the response on behalf
> >> + * of the caller.
> >> + */
> >> +static int st95hf_send_recv_cmd(struct st95hf_context *st95context,
> >> + enum st95hf_cmd_list cmd,
> >> + int no_modif,
> >> + struct param_list *list_array,
> >> + bool recv_res)
> >> +{
> >> + unsigned char spi_cmd_buffer[MAX_CMD_LEN];
> >> + int i, ret;
> >> + struct device *dev = &st95context->spicontext.spidev->dev;
> >How do you know this driver is still valid at that point ?
> >It seems to be a potential corner case against the driver's remove function, but
> >it seems to be a race nevertheless.
>
> st95hf_send_recv_cmd() is a static function that can be called only when a NFC digital request is submitted to our driver.
> So in summary, it can be called either from an implemented NFC digital ops (such as st95hf_switch_rf()) or from the driver's threaded ISR.
> Now if we see the remove function of the driver i.e. st95hf_remove(), it waits for all the outstanding NFC digital request to finish via nfc_digital_unregister_device(stcontext->ddev).
>
Yes, that was my main concern but I forgot
nfc_digital_unregister_device() waits for its command workqueue to be
emptied before returning. So we're safe.

All 3 patches applied to nfc-next, thanks.

Cheers,
Samuel.