From: "Jörn Engel" <joern@logfs.org>
To: Adrian McMenamin <adrian@newgolddream.dyndns.info>
Cc: MTD <linux-mtd@lists.infradead.org>
Subject: Re: [Fwd: Re: [PATCH] 2/2 mtd: Add support for the Dreamcast VMU flash]
Date: Thu, 20 Mar 2008 11:03:53 +0100 [thread overview]
Message-ID: <20080320100353.GA409@logfs.org> (raw)
In-Reply-To: <1205961641.6276.6.camel@localhost.localdomain>
Some details I noticed on first glance.
On Wed, 19 March 2008 21:20:41 +0000, Adrian McMenamin wrote:
>
> +/* Interface with maple bus to read bytes */
> +static int maple_vmu_read_block(unsigned int num, unsigned char *buf,
> + struct mtd_info *mtd)
> +{
> + struct memcard *card;
> + struct mdev_part *mpart;
> + struct maple_device *mdev;
> + int partition, error, locking;
> + void *sendbuf;
> +
> + mpart = mtd->priv;
> + mdev = mpart->mdev;
> + partition = mpart->partition;
> + card = mdev->private_data;
> +
> + /* wait for the mutex to be available */
> + locking = down_interruptible(&(mdev->mq->sem));
> + if (locking) {
> + printk(KERN_INFO "Maple: VMU at (%d, %d) is locked -"
> + " aborting read\n", mdev->unit, mdev->port);
> + goto fail_nosendbuf;
> + }
> + mdev->mq->command = MAPLE_COMMAND_BREAD;
> + mdev->mq->length = 2;
> +
> + sendbuf = kzalloc(mdev->mq->length * 4, GFP_KERNEL);
> + if (!sendbuf) {
> + error = -ENOMEM;
> + goto fail_nosendbuf;
> + }
> +
> + ((unsigned long *)sendbuf)[0] = cpu_to_be32(MAPLE_FUNC_MEMCARD);
> + ((unsigned long *)sendbuf)[1] = cpu_to_be32(partition << 24 | num);
unsigned long is larger than 32bit on many architectures. Better
variant:
__be32 *sendbuf;
...
sendbuf[0] = cpu_to_be32(MAPLE_FUNC_MEMCARD);
sendbuf[1] = cpu_to_be32(partition << 24 | num);
Sparse would have noticed this problem as well. Might be a good idea to
$ make C=1 drivers/mtd/maps/vmu_flash.o
and take a look what other problems show up.
> + mdev->mq->sendbuf = sendbuf;
Possibly the big-endian annotations need to trickly though the layers
here as well.
> +/* mtd function to simulate reading byte by byte */
> +static unsigned char vmu_flash_read_char(unsigned long ofs, int *retval,
> + struct mtd_info *mtd)
> +{
> + struct vmu_block *vblock;
> + struct memcard *card;
> + struct mdev_part *mpart;
> + struct maple_device *mdev;
> + unsigned char *buf, ret;
> + int partition, error;
> +
> + mpart = mtd->priv;
> + mdev = mpart->mdev;
> + partition = mpart->partition;
> + card = mdev->private_data;
> + *retval = 0;
> + buf = kmalloc(card->blocklen, GFP_KERNEL);
> + if (!buf) {
> + *retval = 1;
> + error = ENOMEM;
> + goto fail_buffer;
> + }
> +
> + vblock = ofs_to_block(ofs, mtd, partition);
> + if (!vblock) {
> + *retval = 3;
> + error = ENOMEM;
> + goto invalid_block;
> + }
> +
> + error = maple_vmu_read_block(vblock->num, buf, mtd);
> + if (error) {
> + *retval = 2;
> + goto failed_block;
> + }
> + ret = buf[vblock->ofs];
> + kfree(buf);
> + kfree(vblock);
> + return ret;
> +
> +failed_block:
> + kfree(vblock);
> +invalid_block:
> + kfree(buf);
> +fail_buffer:
> + return -error;
Yikes. Errnos greater 127 do exist. Better return a signed int and
interpret at error if <0.
You could also combine the two sets of kfree() into one, btw.
> + do {
> + if (pcache->valid &&
> + time_before(jiffies, pcache->jiffies_atc + HZ)) {
> + vblock = ofs_to_block(from + index, mtd, partition);
> + if (!vblock)
> + return -ENOMEM;
> + if (pcache->block == vblock->num) {
> + /*we have cached it, so do necessary copying */
> + leftover = card->blocklen - vblock->ofs;
> + if (leftover > len - index) {
> + /* only a bit of this block to copy */
> + memcpy(buf + index,
> + pcache->buffer + vblock->ofs,
> + len - index);
Five levels of indentation are a strong indication that this code is
buggy. I don't understand how it behaves in all corner cases and I bet
neither do you.
> + do {
> +
> + /* Read in the block we are to write to */
> + if (maple_vmu_read_block(vblock->num, buffer, mtd)) {
> + error = -EIO;
> + goto fail_io;
> + }
> +
> + do {
> + buffer[vblock->ofs] = buf[index];
> + vblock->ofs++;
> + index++;
> + if (index >= len)
> + break;
> + } while (vblock->ofs < card->blocklen);
> + /* write out new buffer */
> + retval = maple_vmu_write_block(vblock->num, buffer, mtd);
> + /* invalidare the cache */
> + pcache = (card->parts[partition]).pcache;
> + pcache->valid = 0;
> +
> + if (retval != card->blocklen) {
> + error = -EIO;
> + goto fail_io;
> + }
> +
> + vblock->num++;
> + vblock->ofs = 0;
> + } while (len > index);
And here is an example of essentially the same loop in a fashion mere
mortals can understand. Much better. ;)
> +MODULE_AUTHOR("Adrian McMenamin, Paul Mundt");
I believe the main use of MODULE_AUTHOR is to figure out who to send bug
reports/patches to, not to contain every possible copyright holder. So
possibly just your name here would be more appropriate.
Jörn
--
A victorious army first wins and then seeks battle.
-- Sun Tzu
next prev parent reply other threads:[~2008-03-20 11:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-19 21:20 [Fwd: Re: [PATCH] 2/2 mtd: Add support for the Dreamcast VMU flash] Adrian McMenamin
2008-03-20 10:03 ` Jörn Engel [this message]
2008-03-20 11:56 ` Adrian McMenamin
2008-03-20 11:20 ` Jörn Engel
2008-03-20 12:56 ` Adrian McMenamin
2008-03-20 12:31 ` Jörn Engel
2008-03-20 20:11 ` Adrian McMenamin
2008-03-20 21:58 ` Jörn Engel
2008-03-20 22:27 ` Adrian McMenamin
2008-03-21 9:49 ` Jörn Engel
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=20080320100353.GA409@logfs.org \
--to=joern@logfs.org \
--cc=adrian@newgolddream.dyndns.info \
--cc=linux-mtd@lists.infradead.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 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.