[PATCH] mtd: add setup/teardown callbacks to plat_nand

Alexander Clouter alex at digriz.org.uk
Thu Mar 5 03:54:49 EST 2009


* hartleys <hartleys at visionengravers.com> [Wed, 4 Mar 2009 19:19:24 -0500]:
>
> Any other comments on this patch?  If it looks ok how do I get it
> applied?
>
You can add a Tested-By from me if you want, I used it, then stopped as 
the dma engine loaded after my platform driver which made it half as 
useful (the remove was still helpful) :-/

I'm just waiting for (write|read)_buf and others that were even touted 
back in October 2007[1] :(

Cheers

[1] http://www.infradead.org/pipermail/linux-mtd/2007-October/019659.html

> -----Original Message-----
> From: linux-mtd-bounces at lists.infradead.org
> [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf Of hartleys
> Sent: Monday, February 09, 2009 3:55 PM
> To: Mike Frysinger
> Cc: linux-mtd at lists.infradead.org
> Subject: RE: [PATCH] mtd: add setup/teardown callbacks to plat_nand
>
> On Monday, February 09, 2009 3:28 PM, Mike Frysinger wrote:
>> On Mon, Feb 9, 2009 at 16:37, hartleys wrote:
>>> Add optional setup and teardown callbacks to the plat_nand driver.
>>>
>>> Some platforms may require additional setup, such as configuring
>>> the memory controller, before the nand device can be accessed. 
>>> This patch provides an optional callback to handle this setup as
>>> well as a callback to teardown the setup.
>>
>> on our platforms, we've been putting the setup into the board init
>> code.  but it would certainly be much saner to have explicit steps
>> for it in the plat_nand code as you suggest.
>>
>> i think having the naming convention follow existing practices
>> would be better.  then we dont have to keep our index of synonyms
>> around. i.e. change "setup" to "probe" and "teardown" to "remove"
>> -mike
>
> I've seen both naming conventions used in various drivers.  I'm not sure
> which is the best option.
>
> The "setup", or "probe", callback doesn't/shouldn't to any actual
> probing for the nand device, that's handled by the driver.  It's only
> purpose should be to correctly configure the hardware to allow the probe
> to work.
>
> But, here is the patch again with the changes as suggested.
>
> I also noticed that a header was missing in linux/mtd/nand.h due to the
> callbacks.  I wasn't sure what various platforms might need so I just
> coded this to pass the struct platform_device.  I guess they could both
> just be a void parameter.  Any suggestions...
>
> Thanks,
> Hartley
>
> Signed-off-by: H Hartley Sweeten <hsweeten at visionengravers.com>
>
> ---
>
> diff --git a/drivers/mtd/nand/plat_nand.c b/drivers/mtd/nand/plat_nand.c
> index 75f9f48..600fbe9 100644
> --- a/drivers/mtd/nand/plat_nand.c
> +++ b/drivers/mtd/nand/plat_nand.c
> @@ -70,6 +70,13 @@ static int __init plat_nand_probe(struct
> platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, data);
>  
> +	/* Handle any platform specific setup */
> +	if (pdata->ctrl.probe) {
> +		res = pdata->ctrl.probe(pdev);
> +		if (res)
> +			goto out;
> +	}
> +
>  	/* Scan to find existance of the device */
>  	if (nand_scan(&data->mtd, 1)) {
>  		res = -ENXIO;
> @@ -99,6 +106,8 @@ static int __init plat_nand_probe(struct
> platform_device *pdev)
>  
>  	nand_release(&data->mtd);
>  out:
> +	if (pdata->ctrl.remove)
> +		pdata->ctrl.remove(pdev);
>  	platform_set_drvdata(pdev, NULL);
>  	iounmap(data->io_base);
>  	kfree(data);
> @@ -111,15 +120,15 @@ out:
>  static int __devexit plat_nand_remove(struct platform_device *pdev)
>  {
>  	struct plat_nand_data *data = platform_get_drvdata(pdev);
> -#ifdef CONFIG_MTD_PARTITIONS
>  	struct platform_nand_data *pdata = pdev->dev.platform_data;
> -#endif
>  
>  	nand_release(&data->mtd);
>  #ifdef CONFIG_MTD_PARTITIONS
>  	if (data->parts && data->parts != pdata->chip.partitions)
>  		kfree(data->parts);
>  #endif
> +	if (pdata->ctrl.remove)
> +		pdata->ctrl.remove(pdev);
>  	iounmap(data->io_base);
>  	kfree(data);
>  
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index db5b63d..8534924 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -18,6 +18,7 @@
>  #ifndef __LINUX_MTD_NAND_H
>  #define __LINUX_MTD_NAND_H
>  
> +#include <linux/platform_device.h>
>  #include <linux/wait.h>
>  #include <linux/spinlock.h>
>  #include <linux/mtd/mtd.h>
> @@ -579,6 +580,8 @@ struct platform_nand_chip {
>  
>  /**
>   * struct platform_nand_ctrl - controller level device structure
> + * @probe:		platform specific function to probe/setup
> hardware
> + * @remove:		platform specific function to remove/teardown
> hardware
>   * @hwcontrol:		platform specific hardware control structure
>   * @dev_ready:		platform specific function to read ready/busy
> pin
>   * @select_chip:	platform specific chip select function
> @@ -589,6 +592,8 @@ struct platform_nand_chip {
>   * All fields are optional and depend on the hardware driver
> requirements
>   */
>  struct platform_nand_ctrl {
> +	int		(*probe)(struct platform_device *pdev);
> +	void		(*remove)(struct platform_device *pdev);
>  	void		(*hwcontrol)(struct mtd_info *mtd, int cmd);
>  	int		(*dev_ready)(struct mtd_info *mtd);
>  	void		(*select_chip)(struct mtd_info *mtd, int chip); 
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>


Cheers

-- 
Alexander Clouter
.sigmonster says: What this country needs is a good five cent nickel.




More information about the linux-mtd mailing list