[RFC PATCH 0/4] Add SPI flash support for Exynos Chromebooks

[RFC PATCH 0/4] Add SPI flash support for Exynos Chromebooks

[Javier Martinez Canillas]

Hello Mark,

This is an RFC patch series to add SPI flash support for the Exynos
Chromebooks. These machines store in the flash, firmware and system
parameters such as the Google Binary Block flags that controls many
aspects of the system.

There isn't a driver for this flash memory device so the downstream
tree uses spidev to access the device from userspace (i.e: flashrom).

For example, the Google Binary Block (GBB) flags can be updated with:

# flashrom -p linux_spi:dev=/dev/spidev1.0 -r gbb.bin
# gbb_utility -s --flags=0x39 gbb.bin
# flashrom -p linux_spi:dev=/dev/spidev1.0 -w gbb.bin

I took the downstream patches and posted a while ago [0] but you said
that using compatible = "spidev" is wrong since is an implementation
detail of Linux and does not describe the hardware [1].

By looking at a recent discussion [2] and commit [3], it seems that
you agree to use spidev as long as a relevant device ID is added to
the spidev OF device table.

This is a RFC series though since I may missunderstood your comments.

The series is composed of the following patches:

Doug Anderson (1):
  ARM: dts: Add spidev registration to exynos5250-snow

Javier Martinez Canillas (2):
  spi: spidev: Add Google SPI flash compatible string
  ARM: exynos_defconfig: Enable user mode SPI device support

Simon Glass (1):
  ARM: dts: Add SPI flash node for Peach boards

 arch/arm/boot/dts/exynos5250-snow.dts      | 20 ++++++++++++++++++++
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 26 ++++++++++++++++++++++++++
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 26 ++++++++++++++++++++++++++
 arch/arm/configs/exynos_defconfig          |  1 +
 drivers/spi/spidev.c                       |  1 +
 5 files changed, 74 insertions(+)

Patch #1 adds a "google,spi-flash" entry to the spidev OF ID device table.

Patch #2 and #3 add as device node for the SPI flash to the Snow and Peach
Chromebooks DTS.

Patch #4 enables support for spidev to the exynos_defconfig.

The patches have been tested on an Exynos5250 Snow and Exynos5420 Peach Pit
and #1 should go through the spi tree while #2-4 through linux-samsung tree.

Best regards,
Javier

[0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/303348.html
[1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/304256.html
[2]: https://lkml.org/lkml/2015/4/26/28
[3]: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=956b200a846e324322f6211034c734c65a38e550

[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 <javier.martinez@collabora.co.uk>
---
 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

[RFC PATCH 2/4] ARM: dts: Add SPI flash node for Peach boards

[Javier Martinez Canillas]

From: Simon Glass <sjg@chromium.org>

Peach Pit and Pi machines have a SPI flash memory that is used to
store firmware and different system parameters and data.

Add information about the SPI flash chip so that user-space tools
can access it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 26 ++++++++++++++++++++++++++
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 26 ++++++++++++++++++++++++++
 2 files changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 146e71118a72..8e88088d6815 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -892,6 +892,13 @@
 		samsung,pin-drv = <2>;
 	};
 
+	spi_flash_cs: spi-flash-cs {
+		samsung,pins = "gpa2-5";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <3>;
+	};
+
 	usb300_vbus_en: usb300-vbus-en {
 		samsung,pins = "gph0-0";
 		samsung,pin-function = <1>;
@@ -921,6 +928,25 @@
 	clock-names = "rtc", "rtc_src";
 };
 
+&spi_1 {
+	status = "okay";
+	samsung,spi-src-clk = <0>;
+	num-cs = <1>;
+	cs-gpios = <&gpa2 5 0>;
+
+	spidev@0 {
+		compatible = "google,spi-flash";
+		reg = <0>;
+		spi-max-frequency = <50000000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi_flash_cs>;
+
+		controller-data {
+			samsung,spi-feedback-delay = <2>;
+		};
+	};
+};
+
 &spi_2 {
 	status = "okay";
 	num-cs = <1>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 02eb8b15374f..f2b89991b224 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -855,6 +855,13 @@
 		samsung,pin-drv = <2>;
 	};
 
+	spi_flash_cs: spi-flash-cs {
+		samsung,pins = "gpa2-5";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <3>;
+	};
+
 	usb300_vbus_en: usb300-vbus-en {
 		samsung,pins = "gph0-0";
 		samsung,pin-function = <1>;
@@ -884,6 +891,25 @@
 	clock-names = "rtc", "rtc_src";
 };
 
+&spi_1 {
+	status = "okay";
+	samsung,spi-src-clk = <0>;
+	num-cs = <1>;
+	cs-gpios = <&gpa2 5 0>;
+
+	spidev@0 {
+		compatible = "google,spi-flash";
+		reg = <0>;
+		spi-max-frequency = <50000000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi_flash_cs>;
+
+		controller-data {
+			samsung,spi-feedback-delay = <2>;
+		};
+	};
+};
+
 &spi_2 {
 	status = "okay";
 	num-cs = <1>;
-- 
2.1.4

[RFC PATCH 3/4] ARM: dts: Add SPI flash node to exynos5250-snow

[Javier Martinez Canillas]

From: Doug Anderson <dianders@chromium.org>

Exynos5250 Snow machine has a SPI flash memory that is used to
store firmware and different system parameters and data.

Add information about the SPI flash chip so that user-space tools
can access it.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/boot/dts/exynos5250-snow.dts | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 1eca97ee4bd6..e9a2dbe2e0b9 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -615,6 +615,13 @@
 		samsung,pin-drv = <0>;
 	};
 
+	spi_cs: spi-cs {
+		samsung,pins = "gpa2-5";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <3>;
+	};
+
 	tps65090_irq: tps65090-irq {
 		samsung,pins = "gpx2-6";
 		samsung,pin-function = <0>;
@@ -690,6 +697,19 @@
 	status = "okay";
 	samsung,spi-src-clk = <0>;
 	num-cs = <1>;
+	cs-gpios = <&gpa2 5 0>;
+
+	spidev@0 {
+		compatible = "google,spi-flash";
+		reg = <0>;
+		spi-max-frequency = <10000000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi_cs>;
+
+		controller-data {
+			samsung,spi-feedback-delay = <2>;
+		};
+	};
 };
 
 &usbdrd_dwc3 {
-- 
2.1.4

[RFC PATCH 4/4] ARM: exynos_defconfig: Enable user mode SPI device support

[Javier Martinez Canillas]

Some Exynos boards have SPI devices such as flash memories
that need to be accessed from user-space.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/configs/exynos_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index d034c96c039b..434d36ba87cb 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -91,6 +91,7 @@ CONFIG_I2C_CROS_EC_TUNNEL=y
 CONFIG_SPI=y
 CONFIG_SPI_S3C64XX=y
 CONFIG_I2C_S3C2410=y
+CONFIG_SPI_SPIDEV=y
 CONFIG_DEBUG_GPIO=y
 CONFIG_POWER_SUPPLY=y
 CONFIG_BATTERY_SBS=y
-- 
2.1.4

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

[Baruch Siach]

Hi Javier,

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).
> 
> 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.

The compatible string and dt binding should be documented somewhere under 
Documentation/devicetree/bindings/. Also, please keep the dt list on Cc for dt 
related patches.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Re: [RFC PATCH 2/4] ARM: dts: Add SPI flash node for Peach boards

[Krzysztof Kozlowski]

On 19.05.2015 22:34, Javier Martinez Canillas wrote:
> From: Simon Glass <sjg@chromium.org>
> 
> Peach Pit and Pi machines have a SPI flash memory that is used to
> store firmware and different system parameters and data.
> 
> Add information about the SPI flash chip so that user-space tools
> can access it.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Doug Anderson <dianders@chromium.org>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

I assume this can go through samsung-soc tree (after documenting new
compatible)?

The exynos5800-peach-pi.dts and exynos5420-peach-pit.dts have a lot of
common nodes. I wonder if there is a common part which could have its
own dtsi? Like exynos4412-odroid-common.dtsi?

Best regards,
Krzysztof

Re: [RFC PATCH 3/4] ARM: dts: Add SPI flash node to exynos5250-snow

[Krzysztof Kozlowski]

On 19.05.2015 22:34, Javier Martinez Canillas wrote:
> From: Doug Anderson <dianders@chromium.org>
> 
> Exynos5250 Snow machine has a SPI flash memory that is used to
> store firmware and different system parameters and data.
> 
> Add information about the SPI flash chip so that user-space tools
> can access it.
> 
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> Reviewed-by: Olof Johansson <olofj@chromium.org>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  arch/arm/boot/dts/exynos5250-snow.dts | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)

Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

Best regards,
Krzysztof

Re: [RFC PATCH 4/4] ARM: exynos_defconfig: Enable user mode SPI device support

[Krzysztof Kozlowski]

On 19.05.2015 22:34, Javier Martinez Canillas wrote:
> Some Exynos boards have SPI devices such as flash memories
> that need to be accessed from user-space.
> 
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  arch/arm/configs/exynos_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>

Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

Best regards,
Krzysztof

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

[Javier Martinez Canillas]

Hello Baruch,

On 05/19/2015 09:53 PM, Baruch Siach wrote:
> Hi Javier,
> 
> 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).
>> 
>> 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.
> 
> The compatible string and dt binding should be documented somewhere under 
> Documentation/devicetree/bindings/. Also, please keep the dt list on Cc for dt 
> related patches.
>

Yes, I didn't add a binding doc because this is mostly a RFC to see if
Mark finds the approach feasible but yes I should had included anyways,
sorry about that.

I'll add when posting as a proper patch if he agrees with the solution.
 
> baruch
> 

Best regards,
Javier

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [RFC PATCH 2/4] ARM: dts: Add SPI flash node for Peach boards

[Javier Martinez Canillas]

Hello Krzysztof,

On 05/20/2015 05:37 AM, Krzysztof Kozlowski wrote:
> On 19.05.2015 22:34, Javier Martinez Canillas wrote:
>> From: Simon Glass <sjg@chromium.org>
>> 
>> Peach Pit and Pi machines have a SPI flash memory that is used to
>> store firmware and different system parameters and data.
>> 
>> Add information about the SPI flash chip so that user-space tools
>> can access it.
>> 
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> Reviewed-by: Doug Anderson <dianders@chromium.org>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> 
> Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> 
> I assume this can go through samsung-soc tree (after documenting new
> compatible)?
>

Yes, I mentioned in the cover letter that patch #1 should go through
the spi tree and #2-4 through the linux-samsung tree. I can split in
two series once I post as proper patches to make it more clear.
 
> The exynos5800-peach-pi.dts and exynos5420-peach-pit.dts have a lot of
> common nodes. I wonder if there is a common part which could have its
> own dtsi? Like exynos4412-odroid-common.dtsi?
>

We discussed in the past about having a common .dtsi [0]. I'm not a
huge fan of a common .dtsi and I prefer to instead split common dts
fragments in a .dtsi that can be included in different dts.

That also better reflects what happens at the hw level IMHO since a
board may reuse a IP block. Doug Anderson seems to agree with me [1].
 
> Best regards,
> Krzysztof
>

Best regards,
Javier

[0]: https://lkml.org/lkml/2014/6/26/271
[1]: https://lkml.org/lkml/2014/6/26/555

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

[Javier Martinez Canillas]

Hello Mark,

On 05/20/2015 12:13 PM, Mark Brown wrote:
> 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.
> 

Yes, I missed... sorry about that. Do you agree with the approach
though so I can re-spin the patches adding the missing DT binding?

Best regards,
Javier

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

On Wed, May 20, 2015 at 12:18:13PM +0200, Javier Martinez Canillas wrote:
> On 05/20/2015 12:13 PM, Mark Brown wrote:

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

> Yes, I missed... sorry about that. Do you agree with the approach
> though so I can re-spin the patches adding the missing DT binding?

It's probably OK but I didn't really drill through since the binding was
missing.  If these parts are commodity as described it seems surprising
that they aren't compatible with any existing kernel driver.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Javier Martinez Canillas]

Hello Mark,

On 05/20/2015 12:37 PM, Mark Brown wrote:
> On Wed, May 20, 2015 at 12:18:13PM +0200, Javier Martinez Canillas wrote:
>> On 05/20/2015 12:13 PM, Mark Brown wrote:
> 
>> > This is adding a binding with no documentation, documentation is
>> > mandatory for all bindings.
> 
>> Yes, I missed... sorry about that. Do you agree with the approach
>> though so I can re-spin the patches adding the missing DT binding?
> 
> It's probably OK but I didn't really drill through since the binding was
> missing.  If these parts are commodity as described it seems surprising
> that they aren't compatible with any existing kernel driver.
> 

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.

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.

Best regards,
Javier

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

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 :)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [RFC PATCH 2/4] ARM: dts: Add SPI flash node for Peach boards

[Krzysztof Kozlowski]

On 20.05.2015 19:17, Javier Martinez Canillas wrote:
> Hello Krzysztof,
> 
> On 05/20/2015 05:37 AM, Krzysztof Kozlowski wrote:
>> On 19.05.2015 22:34, Javier Martinez Canillas wrote:
>>> From: Simon Glass <sjg@chromium.org>
>>>
>>> Peach Pit and Pi machines have a SPI flash memory that is used to
>>> store firmware and different system parameters and data.
>>>
>>> Add information about the SPI flash chip so that user-space tools
>>> can access it.
>>>
>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>> Reviewed-by: Doug Anderson <dianders@chromium.org>
>>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>
>> Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>>
>> I assume this can go through samsung-soc tree (after documenting new
>> compatible)?
>>
> 
> Yes, I mentioned in the cover letter that patch #1 should go through
> the spi tree and #2-4 through the linux-samsung tree. I can split in
> two series once I post as proper patches to make it more clear.

It is fine, don't split it. It is good to see the usage of binding in
the same patchset.

>  
>> The exynos5800-peach-pi.dts and exynos5420-peach-pit.dts have a lot of
>> common nodes. I wonder if there is a common part which could have its
>> own dtsi? Like exynos4412-odroid-common.dtsi?
>>
> 
> We discussed in the past about having a common .dtsi [0]. I'm not a
> huge fan of a common .dtsi and I prefer to instead split common dts
> fragments in a .dtsi that can be included in different dts.
> 
> That also better reflects what happens at the hw level IMHO since a
> board may reuse a IP block. Doug Anderson seems to agree with me [1].

Seems reasonable.

Best regards,
Krzysztof