[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110318151219.7aedc765@lxorguk.ukuu.org.uk>
Date: Fri, 18 Mar 2011 15:12:19 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: <Waldemar.Rymarkiewicz@...to.com>
Cc: <linux-i2c@...r.kernel.org>, <arnd@...db.de>,
<sameo@...ux.intel.com>, <linux-kernel@...r.kernel.org>,
<hthebaud@...idefr.com>, <matti.j.aaltonen@...ia.com>
Subject: Re: [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip
> >Would it not be lighter to use atomic bit ops ?
>
> Do you mean in order to remove rx_mutex?
>
> mutex_lock(&info->rx_mutex);
> atomic_set(info->irq_state ,1);
> mutex_unlock(&info->rx_mutex);
>
> looks a bit strange. I still need the rx_mutex to protect irq_state while reading i2c.
>
> mutex_lock(&info->rx_mutex);
> ret = i2c_master_recv(client, info->buf, info->buflen);
> info->irq_state = 0;
> mutex_unlock(&info->rx_mutex);
>
I was thinking clear_bit/test_and_set_bit rather than atomic_t operations.
ie in the IRQ
clear_bit(0, &info->irq_state);
in the main path
if (test_and_set_bit(0, &info->state))
i2c_master_recv(...)
but if the mutex is needed anyway it doesn't help make the code saner.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists