public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Hans-Jürgen Koch" <hjk@linutronix.de>
To: Paul Mundt <lethal@linux-sh.org>
Cc: Ben Nizette <bn@niasdigital.com>, gregkh <gregkh@suse.de>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] UIO: Implement a UIO interface for the SMX Cryptengine
Date: Thu, 13 Mar 2008 11:24:32 +0100	[thread overview]
Message-ID: <20080313112432.578076a5@dilbert.local> (raw)
In-Reply-To: <20080313100655.GA6705@linux-sh.org>

Am Thu, 13 Mar 2008 19:06:55 +0900
schrieb Paul Mundt <lethal@linux-sh.org>:

> > +
> > +	info->name = "smx-ce";
> > +	info->version = "0.03";
> 
> You may as well use DRV_NAME and DRV_VERSION, then you can toss that over
> to MODULE_VERSION() if you're so inclined. It's generally nice to keep
> modinfo happy.

UIO name and version are intentionally independent of module name and
version. It's meant to be an information for the userspace part of the driver
and should be set to values that are meaningful for it.

> 
> > +	info->irq = platform_get_irq(dev, 0);
> > +	info->irq_flags = IRQF_SHARED;
> > +	info->handler = smx_handler;
> > +
> platform_get_irq() can fail, which you don't presently handle (though I
> guess uio_register_device() will error out if you hand off -ENXIO as your
> IRQ anyways, so it's not technically an issue). That's a pretty minor
> issue, though, but might be something you wish to fix up if you are
> planning on using this as an example driver for others.

uio_register_device() will silently not register an interrupt if the number
is negative. This allows us to register a driver without interrupts. Hmm.
Maybe we should explicitly check for UIO_IRQ_NONE there and fail if a
different negative irq is passed in. Thanks for pointing this out.

But I agree, Ben should check if platform_get_irq() failed.

> 
> > +	platform_set_drvdata(dev, info);
> > +
> > +	if (uio_register_device(&dev->dev, info))
> > +		goto out_unmap;
> > +
> > +	return 0;
> > +out_unmap:
> > +	iounmap(info->mem[0].internal_addr);
> > +out_free:
> > +	kfree(info);
> > +
> > +	return -ENODEV;
> > +}
> > +
> Your error paths are also pretty quiet. A dev_err() or so in the few
> failure cases you do have might not be a terrible idea.

I agree.

> 
> uio_register_device() also has quite a few different error cases, so it's
> at least worth preserving the error value and returning that back,
> rather than always returning -ENODEV.

Right. Maybe we should make uio_register_device a bit more verbose, too.

Thanks for your detailed review!

Hans

  reply	other threads:[~2008-03-13 10:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-13  9:35 [PATCH v3] UIO: Implement a UIO interface for the SMX Cryptengine Ben Nizette
2008-03-13 10:06 ` Paul Mundt
2008-03-13 10:24   ` Hans-Jürgen Koch [this message]
2008-03-13 10:09 ` Hans-Jürgen Koch

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=20080313112432.578076a5@dilbert.local \
    --to=hjk@linutronix.de \
    --cc=bn@niasdigital.com \
    --cc=gregkh@suse.de \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    /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