From: Jiri Slaby <jirislaby@gmail.com>
To: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Cc: Grant Likely <grant.likely@secretlab.ca>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Xilinx: hwicap driver comments
Date: Thu, 07 Feb 2008 23:39:43 +0100 [thread overview]
Message-ID: <47AB88AF.7090403@gmail.com> (raw)
In-Reply-To: <20080207223148.D0757DD807E@mail15-dub.bigfish.com>
On 02/07/2008 11:31 PM, Stephen Neuendorffer wrote:
>> Few comments I have:
>> - release f_op retval is silently ignored, I guess you will get your
> device into
>> undefined state when the first function fails (esp. when you interrupt
> the sem)
>
> Hmm.. hadn't realized that. I'm open to suggestions on how to do this
> better. The real reason why the synchronization is there is to make
> sure that only one client is using the device at a time, using the
> is_open flag.
just mutex_lock(); that need not be interrupted.
>> - semaphores are deprecated
>> - class_device_create is deprecated
>
> What is preferred?
device_create(); and pass the struct device as a parent when you are at it.
Otherwise it will be in /sys/*/virtual/* I suppose.
>> - don't understand this:
>> memcpy(kbuf, drvdata->read_buffer, bytes_remaining);
>> drvdata->read_buffer_in_use = bytes_remaining;
>> free_page((unsigned long)kbuf);
>
> The physical device only generates/accepts complete words, the intention
> is to account for the possibility that a read does not read complete
> words, and to fulfill the read whenever possible.
> It's arguable that read() and write() should not accept or return
> partial words, I suppose
OK, but why are you copying anything to buffer which you free 2 lines below?
next prev parent reply other threads:[~2008-02-07 22:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-07 20:08 Xilinx: hwicap driver comments Jiri Slaby
2008-02-07 20:34 ` Grant Likely
2008-02-07 21:10 ` Stephen Neuendorffer
2008-02-07 20:42 ` Andrew Morton
2008-02-07 20:54 ` Grant Likely
2008-02-07 21:21 ` Andrew Morton
2008-02-07 21:31 ` Grant Likely
2008-02-07 21:35 ` Stephen Neuendorffer
2008-02-07 21:53 ` Andrew Morton
2008-02-07 22:00 ` Stephen Neuendorffer
2008-02-07 21:40 ` Linus Torvalds
2008-02-07 21:25 ` Benjamin Herrenschmidt
2008-02-07 21:35 ` Josh Boyer
2008-02-07 22:11 ` Andrew Morton
2008-02-07 22:58 ` Josh Boyer
2008-02-07 21:17 ` Benjamin Herrenschmidt
2008-02-07 21:28 ` Jiri Slaby
2008-02-07 21:33 ` Benjamin Herrenschmidt
2008-02-07 21:35 ` Grant Likely
2008-02-07 22:31 ` Stephen Neuendorffer
2008-02-07 22:39 ` Jiri Slaby [this message]
2008-02-08 2:17 ` [PATCH] [POWERPC] Xilinx: hwicap driver Stephen Neuendorffer
2008-02-08 2:17 ` Stephen Neuendorffer
2008-02-08 9:10 ` Jiri Slaby
2008-02-08 9:10 ` Jiri Slaby
2008-02-08 16:49 ` Randy Dunlap
2008-02-08 16:49 ` Randy Dunlap
2008-02-08 17:08 ` Xilinx: hwicap driver comments Stephen Neuendorffer
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=47AB88AF.7090403@gmail.com \
--to=jirislaby@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=stephen.neuendorffer@xilinx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.