From: Arjan van de Ven <arjan@infradead.org>
To: "Adrian McMenamin" <lkmladrian@gmail.com>
Cc: "Paul Mundt" <lethal@linux-sh.org>,
linuxsh-dev@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] Maple bus support for the Sega Dreamcast
Date: Sun, 9 Sep 2007 19:28:07 +0100 [thread overview]
Message-ID: <20070909192807.3bc2410d@laptopd505.fenrus.org> (raw)
In-Reply-To: <8b67d60709090946y31508ffhf752414872368d8c@mail.gmail.com>
On Sun, 9 Sep 2007 17:46:54 +0100
"Adrian McMenamin" <lkmladrian@gmail.com> wrote:
> This patch adds support for Sega's proprietary Maple bus - which is
> required to support the Dreamcast's peripherals.
Hi,
in general the code looks clean; great job on that.
A few suggestions and comments to hopefully help this driver to become
even better:
First of all, I'm a little concerned about the lack of locking that
this driver seems to have; what guarantees the integrity of the lists
used in the driver?
Second, you have a lot of use of likely() and unlikely(); so much that I think it's waaaay overkill. The code it's in generally isn't hotpath, and gcc also does a pretty decent job without giving these hints in general.
> +
> +void maple_add_packet(struct mapleq *mq)
> +{
> + list_add((struct list_head *) mq, &maple_waitq);
> +}
for example this list.. what makes sure that no 2 pieces of code muck with it at the same time?
> +static struct maple_device *maple_alloc_dev(int port, int unit)
> +{
> + struct maple_device *dev;
> +
> + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> + if (unlikely(!dev))
> + return NULL;
> +
> + dev->port = port;
> + dev->unit = unit;
> + dev->mq = maple_allocq(dev);
> +
> + if (unlikely(!dev->mq)) {
this unlikely isn't needed; gcc basically assumes that NULL pointer checks are unlikely anyway...
> +
> +static int setup_maple_commands(struct device *device, void *ignored)
> +{
> + struct maple_device *maple_dev = to_maple_dev(device);
> +
> + if (likely(maple_dev->interval > 0)) {
> + if (likely(jiffies > maple_dev->when)) {
this is I think a small bug; it is for sure unsafe against jiffies wrapping... please consider using the time_before() and time_after() helpers which will make this comparison safe wrt jiffies wrapping. The same is true for all other jiffies use in the driver...
> +static irqreturn_t maplebus_dma_interrupt(int irq, void *dev_id)
> +{
> + /* Load everything into the bottom half */
> + schedule_work(&maple_dma_process);
> + return IRQ_HANDLED;
> +}
I wonder if you want to at least check if the work was really for you before returning IRQ_HANDLED....
next prev parent reply other threads:[~2007-09-09 18:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-09 16:46 Adrian McMenamin
2007-09-09 18:28 ` Arjan van de Ven [this message]
2007-09-09 18:36 ` Adrian McMenamin
2007-09-09 18:44 ` Arjan van de Ven
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=20070909192807.3bc2410d@laptopd505.fenrus.org \
--to=arjan@infradead.org \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxsh-dev@lists.sourceforge.net \
--cc=lkmladrian@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
all inboxes | Powered by JetHome®