Re: [RFC PATCH 1/4] spi: spidev: Add Google SPI flash compatible string

[Mark Brown]

On Wed, May 20, 2015 at 01:21:53PM +0200, Javier Martinez Canillas wrote:

> The ChromeOS user-space just uses flashrom to send a raw stream of bytes
> via spidev to the SPI NOR flash chip. There is drivers/mtd/spi-nor/spi-nor.c
> but AFAIU there are some limitations when interfacing the flash through
> the MTD layer, for example there isn't a way to set the SPI flash write
> protection through MTD. But I'll do some investigation before re-spinning
> the patches.

OK, that's a bit concerning - perhaps what's needed here is to extend
MTD and so on (if only to find some way for it to coexist with spidev
for the time being)?

> BTW, the other "rohm,dh2228fv" compatible string in spidev added by commit
> 8fad805bdc52 ("spi: spidev: Add Rohm DH2228FV DAC compatible string"), also
> does not have a documented DT binding so that should be fixed as well.

wv :)


signature.asc
Description: Digital signature

Re: [RFC PATCH 1/4] spi: spidev: Add Google SPI flash compatible string

[Mark Brown]

On Tue, May 19, 2015 at 03:34:11PM +0200, Javier Martinez Canillas wrote:
> Google Chromebooks have a SPI flash that is used to store firmware and
> different system parameters and data (i.e: Google Binary Block flags).

> ---
>  drivers/spi/spidev.c | 1 +
>  1 file changed, 1 insertion(+)

This is adding a binding with no documentation, documentation is
mandatory for all bindings.


signature.asc
Description: Digital signature

[RFC PATCH 1/4] spi: spidev: Add Google SPI flash compatible string

[Javier Martinez Canillas]

Google Chromebooks have a SPI flash that is used to store firmware and
different system parameters and data (i.e: Google Binary Block flags).

Since there isn't a driver for it yet, the spidev interface is used to
access the flash from user-space (i.e: using the flashrom tool).

Add a "google,spi-flash" compatible string so the Device Tree sources
use it instead of the "spidev" compatible which does not describe the
real HW and is just a Linux implementation detail.

A generic "google,spi-flash" OF device ID is used instead of the actual
vendor/model because these chips are commodity parts that are sourced
from multiple vendors. So specifying the exact vendor and model in the
DTS will add a maintenance burden with no real gain (the parts are 100%
compatible anyways) and will likely result in it simply being wrong for
a sizeable fraction of the machines.

Also, it would require to duplicate a DTS since the machine is the same
besides using a different SPI flash part.

Signed-off-by: Javier Martinez Canillas 
---
 drivers/spi/spidev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index dd616ff0ffc5..b18cf7bdc385 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -693,6 +693,7 @@ static struct class *spidev_class;
 #ifdef CONFIG_OF
 static const struct of_device_id spidev_dt_ids[] = {
{ .compatible = "rohm,dh2228fv" },
+   { .compatible = "google,spi-flash" },
{},
 };
 MODULE_DEVICE_TABLE(of, spidev_dt_ids);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html