From: Ian Abbott <abbotti@mev.co.uk>
To: "Prashant P. Shah" <pshah.mumbai@gmail.com>
Cc: "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
Frank Mori Hess <fmhess@users.sourceforge.net>,
Ian Abbott <ian.abbott@mev.co.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] Staging: comedi: add dyna_pci10xx driver
Date: Thu, 9 Jun 2011 12:04:19 +0100 [thread overview]
Message-ID: <4DF0A8B3.8090900@mev.co.uk> (raw)
In-Reply-To: <20110609092401.GA2777@mail.fossee.in>
On 09/06/11 10:24, Prashant P. Shah wrote:
> For Dynalog PCI DAQ cards:
> PCI-1050
>
> Signed-off-by: Prashant P. Shah <pshah.mumbai@gmail.com>
It looks mostly okay to me as long as you got the PCI device ID
allocated by PLX (which they'll happily do for their customers if you
tell them what product the chip is is part of), and didn't just pull it
out of a hat!
A small criticism is a slight overuse of udelay(10) calls in the driver.
Are they all necessary? (I can understand its use in the code that
waits for AI conversions to complete.) In the more general cases, you
might want to look at configuring wait states in the PLX chip instead of
relying on software delays. It doesn't matter too much though.
I have a few more specific comments on the code (not many!):
> +/* digital output bit interface */
> +static int dyna_pci10xx_do_insn_bits(struct comedi_device *dev,
> + struct comedi_subdevice *s,
> + struct comedi_insn *insn, unsigned int *data)
> +{
> + if (insn->n != 2)
> + return -EINVAL;
> +
> + /* The insn data is a mask in data[0] and the new data
> + * in data[1], each channel cooresponding to a bit.
> + * s->state contains the previous write data
> + */
> +
> + if (data[0]) {
> + down(&devpriv->sem);
> + s->state &= ~data[0];
> + s->state |= (data[0] & data[1]);
> + smp_mb();
> + outw_p(s->state, devpriv->BADR3);
> + udelay(10);
> + up(&devpriv->sem);
> + }
> +
> + /*
> + * On return, data[1] contains the value of the digital
> + * input and output lines. We just return the software copy of the
> + * output values if it was a purely digital output subdevice.
> + */
> + data[1] = s->state;
> +
> + return 2;
> +}
Since you've gone to the bother of using a semaphore here, it may be
better to grab it before the 'if (data[0])' and release it after the
'data[1] = s->state;'. Then data[1] will definitely be the value that
was written to the outputs by this ioctl.
It would be better to use a mutex than a semaphore for the reasons given
in Documentation/mutex-design.txt.
> +static int dyna_pci10xx_detach(struct comedi_device *dev)
> +{
> + if (devpriv->pci_dev)
> + comedi_pci_disable(devpriv->pci_dev);
> +
> + return 0;
> +}
devpriv may be NULL when _detach is called, so you need to replace the
above test with 'if (devpriv && devpriv->pci_dev)' to avoid a possible
kernel oops.
Best regards,
Ian.
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
next prev parent reply other threads:[~2011-06-09 11:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-09 9:24 [PATCH 1/2] Staging: comedi: add dyna_pci10xx driver Prashant P. Shah
2011-06-09 11:04 ` Ian Abbott [this message]
2011-06-09 11:40 ` Prashant Shah
-- strict thread matches above, loose matches on Subject: below --
2011-06-13 7:28 Prashant P. Shah
2011-06-13 9:33 ` Ian Abbott
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=4DF0A8B3.8090900@mev.co.uk \
--to=abbotti@mev.co.uk \
--cc=devel@linuxdriverproject.org \
--cc=fmhess@users.sourceforge.net \
--cc=gregkh@suse.de \
--cc=ian.abbott@mev.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=pshah.mumbai@gmail.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