From: Arnd Bergmann <arnd@arndb.de>
To: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
hthebaud@insidefr.com, Jari Vanhala <ext-jari.vanhala@nokia.com>,
Matti Aaltonen <matti.j.aaltonen@nokia.com>
Subject: Re: [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip
Date: Thu, 10 Mar 2011 14:52:54 +0100 [thread overview]
Message-ID: <201103101452.54862.arnd@arndb.de> (raw)
In-Reply-To: <1299766808-2535-1-git-send-email-waldemar.rymarkiewicz@tieto.com>
On Thursday 10 March 2011, Waldemar Rymarkiewicz wrote:
> Add new driver for MicroRead NFC chip connected to i2c bus.
>
> See Documentation/nfc/nfc-microread.txt.
The imlpementation looks fairly clean, no objections on that.
However, this is the second NFC driver (at least), and that means
it's time to come up with a generic way of talking to NFC devices
from user space. We cannot allow every NFC controller to have
another set of arbitrary ioctl numbers.
What I suggest you do is to work with the maintainers of the existing
pn544 driver (Matti and Jari) to create an NFC core library that
takes care of the character device interface and that can be
shared between the two drivers. Instead of each driver registering a
misc device, make it call a nfc_device_register() function that
is implemented in a common module.
You will need a structure like
struct nfc_device {
struct device *dev; /* points to i2c/platform/... hardware device */
const struct nfc_operations *ops;
struct mutex mutex;
};
struct nfc_operations {
/* pin before calling the functions */
struct module *owner;
/* called from file operations */
int (*open)(struct nfc_device *dev);
void (*close)(struct nfc_device *dev);
/* called from ioctl */
int (*configure)(struct nfc_device *dev);
int (*connect)(struct nfc_device *dev);
int (*reset)(struct nfc_device *);
size_t (*read_avail)(struct nfc_device *); /* for poll, read */
ssize_t (*read)(struct nfc_device *, void __user *buf, size_t len);
size_t (*write_avail)(struct nfc_device *); /* for write */
ssize_t (*write)(struct nfc_device *, void __user *buf, size_t len);
};
extern int nfc_device_register(struct nfc_device *dev);
extern void nfc_device_unregister(struct nfc_device *dev);
extern void nfc_wake_up(struct nfc_device *dev); /* on interrupt */
> +The below platform data should be set when configuring board.
> +
> +struct microread_nfc_platform_data {
> + unsigned int rst_gpio;
> + unsigned int irq_gpio;
> + unsigned int ioh_gpio;
Not your problem directly, but I think we need to find a way to encode
gpio pins in resources like we do for interrupts.
> + int (*request_hardware) (struct i2c_client *client);
> + void (*release_hardware) (void);
Why do you need these in platform data? Can't you just request
the i2c device at the time when you create the platform_device?
> +struct microread_info {
> + struct i2c_client *i2c_dev;
> + struct miscdevice mdev;
> +
> + u8 state;
> + u8 irq_state;
> + int irq;
> + u16 buflen;
> + u8 *buf;
> + wait_queue_head_t rx_waitq;
> + struct mutex rx_mutex;
> + struct mutex mutex;
> +};
mdev, rx_waitq and mutex would go into the common module.
I would expect that you also need a tx_waitq. What happens
when the buffer is full?
> +static inline int microread_is_busy(struct microread_info *info)
> +{
> + return (info->state == MICROREAD_STATE_BUSY);
> +}
> +
> +static int microread_open(struct inode *inode, struct file *file)
> +{
> + struct microread_info *info = container_of(file->private_data,
> + struct microread_info, mdev);
> + struct i2c_client *client = info->i2c_dev;
> + int ret = 0;
> +
> + dev_vdbg(&client->dev, "%s: info: %p", __func__, info);
> +
> + mutex_lock(&info->mutex);
> +
> + if (microread_is_busy(info)) {
> + dev_err(&client->dev, "%s: info %p: device is busy.", __func__,
> + info);
> + ret = -EBUSY;
> + goto done;
> + }
> +
> + info->state = MICROREAD_STATE_BUSY;
> +done:
> + mutex_unlock(&info->mutex);
> + return ret;
> +}
Note that the microread_is_busy() logic does not protect you from having
multiple concurrent readers, because multiple threads may share a single
file descriptor.
> +long microread_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> +{
...
> +const struct file_operations microread_fops = {
> + .owner = THIS_MODULE,
Some of your identifiers are not 'static'. Please make sure that only symbols
that are used across files are in the global namespace.
Arnd
next prev parent reply other threads:[~2011-03-10 13:53 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-10 14:20 [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip Waldemar Rymarkiewicz
2011-03-10 13:52 ` Arnd Bergmann [this message]
2011-03-10 14:45 ` Waldemar.Rymarkiewicz
2011-03-10 16:20 ` Arnd Bergmann
2011-03-14 14:59 ` Waldemar.Rymarkiewicz
2011-03-14 15:34 ` Arnd Bergmann
2011-03-14 15:45 ` Waldemar.Rymarkiewicz
2011-03-14 16:00 ` Arnd Bergmann
2011-03-14 16:15 ` Waldemar.Rymarkiewicz
2011-03-14 17:01 ` Arnd Bergmann
2011-03-15 8:37 ` Waldemar.Rymarkiewicz
2011-03-15 9:06 ` Arnd Bergmann
2011-03-17 12:58 ` Waldemar.Rymarkiewicz
2011-03-17 13:07 ` Arnd Bergmann
2011-03-17 13:38 ` Waldemar.Rymarkiewicz
2011-03-17 13:54 ` Arnd Bergmann
2011-03-17 13:58 ` Waldemar.Rymarkiewicz
-- strict thread matches above, loose matches on Subject: below --
2011-03-18 10:40 Waldemar Rymarkiewicz
2011-03-18 10:40 ` Waldemar Rymarkiewicz
2011-03-18 11:03 ` Alan Cox
2011-03-18 15:00 ` Waldemar.Rymarkiewicz
2011-03-18 15:05 ` Arnd Bergmann
2011-03-18 15:12 ` Alan Cox
2011-03-18 15:15 ` Waldemar.Rymarkiewicz
2011-03-18 11:49 ` Wolfram Sang
2011-03-18 15:08 ` Waldemar.Rymarkiewicz
2011-03-18 15:31 ` Mark Brown
2011-03-18 16:43 ` Waldemar.Rymarkiewicz
2011-03-18 12:19 ` Arnd Bergmann
2011-03-18 12:51 ` Mark Brown
2011-03-18 14:20 ` Arnd Bergmann
2011-03-25 14:26 ` Samuel Ortiz
2011-03-29 8:00 ` Waldemar.Rymarkiewicz
2011-03-29 11:05 ` Arnd Bergmann
2011-03-29 11:59 ` Alan Cox
2011-03-29 12:04 ` Arnd Bergmann
2011-03-29 12:23 ` Alan Cox
2011-03-29 13:22 ` Arnd Bergmann
2011-03-31 14:16 ` Samuel Ortiz
2011-03-31 14:42 ` Waldemar.Rymarkiewicz
2011-03-31 14:49 ` Arnd Bergmann
2011-03-31 15:09 ` Samuel Ortiz
2011-03-31 15:24 ` Waldemar.Rymarkiewicz
2011-03-31 15:30 ` Samuel Ortiz
2011-04-01 18:19 ` Aloisio Almeida
2011-04-01 19:43 ` Arnd Bergmann
2011-06-06 20:22 ` Pavan Savoy
2011-06-06 20:30 ` Pavan Savoy
2011-06-06 20:46 ` Aloisio Almeida
2011-06-06 20:50 ` Samuel Ortiz
2011-03-18 15:50 ` Randy Dunlap
2011-03-18 15:57 ` Waldemar.Rymarkiewicz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201103101452.54862.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=ext-jari.vanhala@nokia.com \
--cc=hthebaud@insidefr.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matti.j.aaltonen@nokia.com \
--cc=waldemar.rymarkiewicz@tieto.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox