public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: David Brownell <david-b@pacbell.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	davinci-linux-open-source@linux.davincidsp.com,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [patch/RESEND 2.6.29-rc3-git] NAND: davinci_nand driver
Date: Fri, 27 Feb 2009 14:29:32 -0800	[thread overview]
Message-ID: <87k57ba4z7.fsf@deeprootsystems.com> (raw)
In-Reply-To: <200902261515.22197.david-b@pacbell.net> (David Brownell's message of "Thu\, 26 Feb 2009 15\:15\:21 -0800")

David Brownell <david-b@pacbell.net> writes:

> On Thursday 26 February 2009, Andrew Morton wrote:
>
>> > + * Copyright (C) 2006 Texas Instruments.
>> > + *
>> > + * Ported to 2.6.23 Copyright (C) 2008 by
>> > + *   Sander Huijsen <Shuijsen@optelecom-nkf.com>
>> > + *   Troy Kisky <troy.kisky@boundarydevices.com>
>> > + *   Dirk Behme <Dirk.Behme@gmail.com>
>> 
>> hm.  What's the story with authorship, attributions and signoffs here?
>
> Written by TI (PSP team in India, ISTR) with no individual
> authorship credited, and shipped with a MontaVista 2.6.10
> kernel.  Ported as noted; I could presumably add my own
> copyright given recent updates I've made.  Likewise Felipe
> Balbi.  Kevin Hilman has signed off on various patches as
> part of merging them to the DaVinci tree.
>
> (To the TI team reading this via the DaVinci list:  I think
> Andrew is hinting that a Signed-off-By from a TI person
> would be a Nice Thing.  Same for Dirk, and maybe others.)
>
>
>> > ...
>> >
>> > +#ifdef CONFIG_MTD_PARTITIONS
>> > +static inline int mtd_has_partitions(void) { return 1; }
>> > +#else
>> > +static inline int mtd_has_partitions(void) { return 0; }
>> > +#endif
>> > +
>> > +#ifdef CONFIG_MTD_CMDLINE_PARTS
>> > +static inline int mtd_has_cmdlinepart(void) { return 1; }
>> > +#else
>> > +static inline int mtd_has_cmdlinepart(void) { return 0; }
>> > +#endif
>> 
>> These definitions shouldn't be buried in a .c file.
>
> I will send along a patch to move them to <linux/mtd/...> headers,
> now that there seems to be a bit of recognition that the current
> ifdef-centric approach in the MTD mapping drivers is trouble.  ;)
>
>
>> >
>> > ...
>> >
>> > +static void nand_davinci_hwctl_1bit(struct mtd_info *mtd, int mode)
>> > +{
>> > +	struct davinci_nand_info *info;
>> > +	u32 retval;
>> 
>> The identifier `retval' is usually used to identify the value which
>> this function will return.
>
> True; resolved in the appended fixup patch.
>
>
>> > +static int nand_davinci_calculate_1bit(struct mtd_info *mtd,
>> > +				      const u_char *dat, u_char *ecc_code)
>> > +{
>> > +	unsigned int ecc_val = nand_davinci_readecc_1bit(mtd);
>> > +	unsigned int tmp = (ecc_val & 0x0fff) | ((ecc_val & 0x0fff0000) >> 4);
>> 
>> argh.
>
> It seems the best-dressed pirates have parrots named "argh"!  ;)
>
>
>> > +	/* invert so that erased block ecc is correct */
>> > +	tmp = ~tmp;
>> > +	ecc_code[0] = (u_char)(tmp);
>> > +	ecc_code[1] = (u_char)(tmp >> 8);
>> > +	ecc_code[2] = (u_char)(tmp >> 16);
>> 
>> Is there some library facility which is being open-coded here?
>
> I don't know of such a facility:  24-bit integer into 3-byte buffer.
>
>
>> > +	return 0;
>> > +}
>> > +
>> >
>> > ...
>> >
>> > +static int __init nand_davinci_probe(struct platform_device *pdev)
>> > +{
>> > +		... deletia ...
>> > +
>> > +	info = kzalloc(sizeof(*info), GFP_KERNEL);
>> > +	if (!info) {
>> > +		dev_err(&pdev->dev, "unable to allocate memory\n");
>> > +		ret = -ENOMEM;
>> > +		goto err_nomem;
>> > +	}
>> > +
>> > +	platform_set_drvdata(pdev, info);
>> > +
>> > +	res1 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> > +	res2 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> > +	if (!res1 || !res2) {
>> > +		dev_err(&pdev->dev, "resource missing\n");
>> > +		ret = -EINVAL;
>> > +		goto err_res;
>> 
>> This leaks `info'.
>> 
>> Please check all the error path unwinding here.
>
> OK -- that does look buggish.
>
> (Kevin -- I suggest you merge this to the DaVinci tree to
> make the eventual resync-with-mainline easier.)
>

Done.

It also needs this cleanup bit below which is in DaVinci git now that
we've deprecated the use of the davinci cpu_is_* macros in drivers.

This could be just folded into current patch if desired.

Thanks,

Kevin


commit 1bacc33ccc9bd0f3c109bf8a8550e9b6f99397bd
Author: Kevin Hilman <khilman@deeprootsystems.com>
Date:   Thu Feb 26 17:15:18 2009 -0800

    MTD: NAND: drop usage of cpu_is_* macro
    
    Usage of davinci-specific cpu_is macros is not allowed in drivers.
    These options should be passed in through platform_data.
    
    Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index aa70b4e..a2f78ad 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -33,7 +33,6 @@
 #include <linux/mtd/nand.h>
 #include <linux/mtd/partitions.h>
 
-#include <mach/cpu.h>
 #include <mach/nand.h>
 
 #include <asm/mach-types.h>
@@ -392,8 +391,6 @@ static int __init nand_davinci_probe(struct platform_device *pdev)
 	/* use board-specific ECC config; else, the best available */
 	if (pdata)
 		ecc_mode = pdata->ecc_mode;
-	else if (cpu_is_davinci_dm355())
-		ecc_mode = NAND_ECC_HW_SYNDROME;
 	else
 		ecc_mode = NAND_ECC_HW;
 

  parent reply	other threads:[~2009-02-27 22:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-24 23:09 [patch/RESEND 2.6.29-rc3-git] NAND: davinci_nand driver David Brownell
2009-02-25  1:55 ` Thiago Galesi
2009-02-25  4:12   ` David Brownell
2009-02-25 13:05     ` Thiago Galesi
2009-02-26 20:33 ` Andrew Morton
2009-02-26 23:15   ` David Brownell
2009-02-27 17:52     ` Felipe Balbi
2009-03-02  8:33       ` Rajashekhara, Sudhakar
2009-02-27 22:29     ` Kevin Hilman [this message]
2009-02-26 23:18   ` [patch 2.6.29-rc6-mmotm] MTD: partitioning utility predicates David Brownell

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=87k57ba4z7.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=akpm@linux-foundation.org \
    --cc=david-b@pacbell.net \
    --cc=davinci-linux-open-source@linux.davincidsp.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox