All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaud Mouiche <arnaud.mouiche@gmail.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>,
	Peter Pan <peterpandong@micron.com>
Cc: richard@nod.at, computersforpeace@gmail.com,
	thomas.petazzoni@free-electrons.com,
	linux-mtd@lists.infradead.org, peterpansjtu@gmail.com,
	linshunquan1@hisilicon.com
Subject: Re: [PATCH v3 7/8] nand: spi: Add generic SPI controller support
Date: Fri, 17 Mar 2017 18:32:28 +0100	[thread overview]
Message-ID: <3efc4b1f-7391-03f9-497d-8ea5f89f5d59@gmail.com> (raw)
In-Reply-To: <20170317152048.1eca677e@bbrezillon>



On 17/03/2017 15:20, Boris Brezillon wrote:
> [...]
> Should be done before calling spinand_detect(), just in case some DT
> props need to be parsed before the detection step.
>
> This being said, I'm not sure we should let the spinand controller
> driver do the registration step. I'm currently trying to rework the
> parallel NAND framework to act like all other busses, and I think SPI
> NAND controllers should also follow this road:
>
> 1/ spinand controller driver register a controller to the spinand core
>    (spinand_controller_register())
> 2/ the core parses the DT (or board info if DT is not available) and
>     creates N spinand devices (the N value depends on the number of SPI
>     nands connected to the controller)
> 3/ for each spinand device the detection/initialization takes place
>     directly in the core (the spinand_controller_ops should contain
>     anything required to do the detection)
> 4/ for each spinand dev the spinand_controller_ops->add() is called, to
>     let the controller driver attach private data to the device (if
>     required), and/or let it use it's own ECC engine (optional as well).
> 5/ underlying MTD device registered by spinand core code and spinand
>     dev added to the list of devices controlled by this controller (done
>     in the core)
>
> When removing a device, you just have the reverse steps:
>
> 1/ remove from list and unregister the MTD dev
> 2/ call spinand_controller_ops->remove()
> 3/ core/manufacturer cleanup
>
> Not sure how feasible this is, especially for the generic SPI NAND
> controller case where the SPI NAND controller does not have a node in
> the DT, but that would avoid all this boiler-plate duplication we have
> in the // NAND framework.

Since the probe for generic spi devices is generally triggered by the 
SPI layer, it will not match easily in the way you would like the 
registration done.
Can we let this registration question not be a showstopper for Peter's 
effort ?

Regards,
Arnaud
>> +
>> +	ret = mtd_device_register(mtd, NULL, 0);
>> +	if (!ret)
>> +		return 0;
>> +
>> +err5:
>> +	spinand_cleanup(chip);
>> +err4:
>> +	kfree(ecc_engine);
>> +err3:
>> +	kfree(controller);
>> +err2:
>> +	kfree(chip);
>> +err1:
>> +	return ret;
>> +}
>> +
>> +static int generic_spinand_remove(struct spi_device *spi)
>> +{
>> +	struct spinand_device *chip = spi_get_drvdata(spi);
>> +	struct mtd_info *mtd = spinand_to_mtd(chip);
>> +
>> +	mtd_device_unregister(mtd);
>> +	spinand_cleanup(chip);
>> +	kfree(chip->ecc.engine);
>> +	kfree(chip->controller);
>> +	kfree(chip);
>> +
>> +	return 0;
>> +}
>> +
>> +static struct spi_driver generic_spinand_driver = {
>> +	.driver = {
>> +		.name	= "generic_spinand",
>> +		.owner	= THIS_MODULE,
>> +	},
>> +	.probe	= generic_spinand_probe,
>> +	.remove	= generic_spinand_remove,
>> +};
>> +module_spi_driver(generic_spinand_driver);
>> +
>> +MODULE_DESCRIPTION("Generic SPI controller to support SPI NAND");
>> +MODULE_AUTHOR("Peter Pan<peterpandong@micron.com>");
>> +MODULE_LICENSE("GPL v2");

  reply	other threads:[~2017-03-17 17:32 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-16  6:47 [PATCH v3 0/8] Introduction to SPI NAND framework Peter Pan
2017-03-16  6:47 ` [PATCH v3 1/8] mtd: nand: add more helpers in nand.h Peter Pan
2017-03-17 13:07   ` Boris Brezillon
2017-03-20  4:51     ` Peter Pan
2017-03-16  6:47 ` [PATCH v3 2/8] mtd: nand: add oob iterator in nand_for_each_page Peter Pan
2017-03-17 13:11   ` Boris Brezillon
2017-03-20  4:52     ` Peter Pan
2017-03-16  6:47 ` [PATCH v3 3/8] nand: spi: add basic blocks for infrastructure Peter Pan
2017-03-16  9:55   ` Boris Brezillon
2017-03-17  5:45     ` Peter Pan
2017-03-17 10:20   ` Arnaud Mouiche
2017-03-17 10:22     ` Peter Pan
2017-03-17 13:38   ` Boris Brezillon
2017-03-20  4:55     ` Peter Pan
2017-03-16  6:47 ` [PATCH v3 4/8] nand: spi: add basic operations support Peter Pan
2017-03-17 10:33   ` Arnaud Mouiche
2017-03-17 10:49     ` Peter Pan
2017-03-17 11:02       ` Boris Brezillon
2017-03-17 11:09         ` Peter Pan
2017-03-17 11:12           ` Boris Brezillon
2017-03-17 11:18             ` Peter Pan
2017-03-16  6:47 ` [PATCH v3 5/8] nand: spi: Add bad block support Peter Pan
2017-03-17 12:22   ` Arnaud Mouiche
2017-03-17 12:31     ` Boris Brezillon
2017-03-20  4:49       ` Peter Pan
2017-03-16  6:47 ` [PATCH v3 6/8] nand: spi: add Micron spi nand support Peter Pan
2017-03-16  6:47 ` [PATCH v3 7/8] nand: spi: Add generic SPI controller support Peter Pan
2017-03-17 14:20   ` Boris Brezillon
2017-03-17 17:32     ` Arnaud Mouiche [this message]
2017-03-17 17:48       ` Boris Brezillon
2017-03-20  4:58         ` Peter Pan
2017-03-20  5:56           ` Boris Brezillon
2017-03-20  7:15             ` Peter Pan
2017-03-16  6:47 ` [PATCH v3 8/8] MAINTAINERS: Add SPI NAND entry Peter Pan
2017-03-17 10:02 ` [PATCH v3 0/8] Introduction to SPI NAND framework Arnaud Mouiche
2017-03-17 10:34   ` Peter Pan

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=3efc4b1f-7391-03f9-497d-8ea5f89f5d59@gmail.com \
    --to=arnaud.mouiche@gmail.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=linshunquan1@hisilicon.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=peterpandong@micron.com \
    --cc=peterpansjtu@gmail.com \
    --cc=richard@nod.at \
    --cc=thomas.petazzoni@free-electrons.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 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.