| Message ID | 20170819221823.13850-4-hauke@hauke-m.de (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On Sun, Aug 20, 2017 at 12:18:10AM +0200, Hauke Mehrtens wrote: > Do not check which flash type the SoC was booted from before > using this driver. Assume that the device tree is correct and use this > driver when it was added to device tree. This also removes a build > dependency to the SoC code. > > All device trees I am aware of only have one correct flash device entry > in it. The device tree is anyway bundled with the kernel in all systems > using device tree I know of. > > The boot mode can be specified with some pin straps and will select the > flash type the rom code will boot from. One SPI, NOR or NAND flash chip > can be connect to the EBU and used to load the first stage boot loader > from. I think other than this patch we finally have all the acks necessary so I merged the series except this patch which shouldn't be strictly necessary. Ralf -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/28/2017 01:23 PM, Ralf Baechle wrote: > On Sun, Aug 20, 2017 at 12:18:10AM +0200, Hauke Mehrtens wrote: > >> Do not check which flash type the SoC was booted from before >> using this driver. Assume that the device tree is correct and use this >> driver when it was added to device tree. This also removes a build >> dependency to the SoC code. >> >> All device trees I am aware of only have one correct flash device entry >> in it. The device tree is anyway bundled with the kernel in all systems >> using device tree I know of. >> >> The boot mode can be specified with some pin straps and will select the >> flash type the rom code will boot from. One SPI, NOR or NAND flash chip >> can be connect to the EBU and used to load the first stage boot loader >> from. > > I think other than this patch we finally have all the acks necessary so > I merged the series except this patch which shouldn't be strictly necessary. > > Ralf > Hi Ralf and Mark, this driver will not build any more without this patch, because ltq_boot_select() gets removed in "[PATCH v10 09/16] MIPS: lantiq: remove ltq_reset_cause() and ltq_boot_select()" Mark could you please have a look at the commit message if it is better now. Hauke -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 28, 2017 at 01:29:33PM +0200, Hauke Mehrtens wrote:
> Mark could you please have a look at the commit message if it is better now.
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings just adds to the mail volume (if they are
seen at all) and if something has gone wrong you'll have to resend the
patches anyway.
diff --git a/drivers/spi/spi-falcon.c b/drivers/spi/spi-falcon.c index 286b2c81fc6b..f8638e82e5db 100644 --- a/drivers/spi/spi-falcon.c +++ b/drivers/spi/spi-falcon.c @@ -395,11 +395,6 @@ static int falcon_sflash_probe(struct platform_device *pdev) struct spi_master *master; int ret; - if (ltq_boot_select() != BS_SPI) { - dev_err(&pdev->dev, "invalid bootstrap options\n"); - return -ENODEV; - } - master = spi_alloc_master(&pdev->dev, sizeof(*priv)); if (!master) return -ENOMEM;
Do not check which flash type the SoC was booted from before using this driver. Assume that the device tree is correct and use this driver when it was added to device tree. This also removes a build dependency to the SoC code. All device trees I am aware of only have one correct flash device entry in it. The device tree is anyway bundled with the kernel in all systems using device tree I know of. The boot mode can be specified with some pin straps and will select the flash type the rom code will boot from. One SPI, NOR or NAND flash chip can be connect to the EBU and used to load the first stage boot loader from. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Cc: Mark Brown <broonie@kernel.org> Cc: linux-spi@vger.kernel.org --- drivers/spi/spi-falcon.c | 5 ----- 1 file changed, 5 deletions(-)