From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Cc: <linux-i2c@vger.kernel.org>, <arnd@arndb.de>,
<sameo@linux.intel.com>, <linux-kernel@vger.kernel.org>,
<hthebaud@insidefr.com>, <matti.j.aaltonen@nokia.com>
Subject: Re: [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip
Date: Fri, 18 Mar 2011 11:03:48 +0000 [thread overview]
Message-ID: <20110318110348.728f6036@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <1300444824-13713-2-git-send-email-waldemar.rymarkiewicz@tieto.com>
On Fri, 18 Mar 2011 11:40:24 +0100
Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> wrote:
> Add new driver for MicroRead NFC chip connected to i2c bus.
Ok we now have two devices and they have differing APIs and own device
names and both from the same company. This has to stop right now and the
existing one wants sorting out accordingly (while you are it fix the fact
any user can blow the kernel log away in that one by issuing bogus ioctls
at it, thats not a good thing)
NAK to this in its current form.
If we are going to have multiple nfc devices (and we are) then we need
a /dev/nfc%d device range to dump them in and we need some API
commonality.
Your API seems fairly sane (except your nfc-microread.txt needs to
document or point properly to the HCI messages in question
> +The application can use ioctl(MICROREAD_IOC_RESET)to reset the hardware.
And a reset is a generic sort of interface so we should probably have
NFC_IOC_RESET to go with /dev/nfc%d naming.
> +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);
So a process spinning trying to open it can spew all over the log - looks
bogus to me (similar problems in the existing driver)
> + if (count > info->buflen) {
> + dev_err(&client->dev, "%s: no enough space in read buffer.",
> + __func__);
> + ret = -ENOMEM;
> + goto done;
More bogus log spewing and an odd error code for good measure
> + lrc = calc_lrc(info->buf, len + 1);
> + if (lrc != info->buf[len + 1]) {
> + dev_err(&client->dev, "%s: incorrect i2c frame.", __func__);
> + ret = -EFAULT;
> + goto done;
So I can also spew all over the log by putting a deliberately busted
sender next to it.
> + }
> +
> + ret = len + 2;
> +
> + if (copy_to_user(buf, info->buf, len + 2)) {
> + dev_err(&client->dev, "%s: error copying to user.", __func__);
> + ret = -EFAULT;
And another one.
> +static ssize_t microread_write(struct file *file, const char __user *buf,
> + size_t count, loff_t *f_pos)
> +{
> + struct microread_info *info = container_of(file->private_data,
> + struct microread_info, mdev);
> + struct i2c_client *client = info->i2c_dev;
> + int ret;
> + u16 len;
> +
> + dev_dbg(&client->dev, "%s: info: %p, size %d (bytes).", __func__,
> + info, count);
> +
> + if (count > info->buflen) {
> + dev_err(&client->dev, "%s: no enought space in TX buffer.",
> + __func__);
> + return -EINVAL;
> + }
And another
> +
> + len = min_t(u16, count, info->buflen);
> +
> + mutex_lock(&info->mutex);
> + if (copy_from_user(info->buf, buf, len)) {
> + dev_err(&client->dev, "%s: error copying from user.",
> + __func__);
Etc - these all want cleaning up
> +static unsigned int microread_poll(struct file *file, poll_table *wait)
> +{
> + struct microread_info *info = container_of(file->private_data,
> + struct microread_info, mdev);
> + struct i2c_client *client = info->i2c_dev;
> + int ret = (POLLOUT | POLLWRNORM);
> +
> + dev_vdbg(&client->dev, "%s: info: %p client %p", __func__, info,
> + client);
> +
> + mutex_lock(&info->mutex);
> + poll_wait(file, &info->rx_waitq, wait);
> +
> + mutex_lock(&info->rx_mutex);
> + if (info->irq_state)
> + ret |= (POLLIN | POLLRDNORM);
> + mutex_unlock(&info->rx_mutex);
> + mutex_unlock(&info->mutex);
What is the intended behaviour on a reset while I am polling ?
> +static long microread_ioctl(struct file *file, unsigned int cmd,
> + unsigned long arg)
> +{
> + struct microread_info *info = container_of(file->private_data,
> + struct microread_info, mdev);
> + struct i2c_client *client = info->i2c_dev;
> + struct microread_nfc_platform_data *pdata =
> + dev_get_platdata(&client->dev);
> + int ret = 0;
> +
> + dev_dbg(&client->dev, "%s: info: %p cmd %d", __func__, info, cmd);
> +
> + mutex_lock(&info->mutex);
> +
> + switch (cmd) {
> + case MICROREAD_IOC_CONFIGURE:
> + case MICROREAD_IOC_CONNECT:
> + goto done;
Ermm nope.. why do we have do nothing ioctls ?
> + case MICROREAD_IOC_RESET:
> + microread_reset_hw(pdata);
> + default:
> + dev_err(&client->dev, "%s; not supported ioctl 0x%x", __func__,
> + cmd);
And more spewage
> +static irqreturn_t microread_irq(int irq, void *dev)
> +{
> + struct microread_info *info = dev;
> + struct i2c_client *client = info->i2c_dev;
> +
> + dev_dbg(&client->dev, "irq: info %p client %p ", info, client);
> +
> + if (irq != client->irq)
> + return IRQ_NONE;
How can this occur - why is this test needed ????
> +
> + mutex_lock(&info->rx_mutex);
> + info->irq_state = 1;
> + mutex_unlock(&info->rx_mutex);
Would it not be lighter to use atomic bit ops ?
> + info->mdev.minor = MISC_DYNAMIC_MINOR;
> + info->mdev.name = MICROREAD_DEV_NAME;
> + info->mdev.fops = µread_fops;
> + info->mdev.parent = &client->dev;
> +
> + ret = misc_register(&info->mdev);
> + if (ret < 0) {
> + dev_err(&client->dev, "%s: register chr dev failed (ret %d)",
> + __func__, ret);
> + goto free_irq;
> + }
And at this point you want a thing to hand out nfc%d names not to use
misc device with random per device API. The same app ought to be able to
work with many nfc readers.
> +static int microread_suspend(struct i2c_client *client, pm_message_t mesg)
> +{
> + return -ENOSYS;
> +}
> +
> +static int microread_resume(struct i2c_client *client)
> +{
> + return -ENOSYS;
> +}
So why provide them ??
Alan
next prev parent reply other threads:[~2011-03-18 11:03 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-18 10:40 Waldemar Rymarkiewicz
2011-03-18 10:40 ` Waldemar Rymarkiewicz
2011-03-18 11:03 ` Alan Cox [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2011-03-10 14:20 Waldemar Rymarkiewicz
2011-03-10 13:52 ` Arnd Bergmann
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
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=20110318110348.728f6036@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=arnd@arndb.de \
--cc=hthebaud@insidefr.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matti.j.aaltonen@nokia.com \
--cc=sameo@linux.intel.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
all inboxes | Powered by JetHome®