[PATCH v2 0/4] Add support for the Mercury+ AA1 module

[PATCH v2 0/4] Add support for the Mercury+ AA1 module

[Paweł Anikiel]

The following patches add support for the Mercury+ AA1 with an
Arria 10 SoCFPGA.

This version differs from the previous one by removing the spi
flash node, renaming the memory and mdio nodes, adding gpio nodes,
and adding a bus number property to Synopsys DesignWare i2c
controller node.

Paweł Anikiel (4):
  i2c: check bus number property in DesignWare I2C Controller
  dt-bindings: add bus number property
  reset: socfpga: add empty driver allowing consumers to probe
  dts: socfpga: Add Mercury+ AA1 devicetree

 .../bindings/i2c/snps,designware-i2c.yaml     |  5 +
 arch/arm/boot/dts/Makefile                    |  1 +
 .../boot/dts/socfpga_arria10_mercury_aa1.dts  | 99 +++++++++++++++++++
 drivers/i2c/busses/i2c-designware-platdrv.c   |  3 +-
 drivers/reset/reset-socfpga.c                 | 26 +++++
 5 files changed, 133 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/socfpga_arria10_mercury_aa1.dts

-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller

[Paweł Anikiel]

On SoCFPGA systems, it's desireable to have fixed numbering for
i2c busses, while being able to enable/disable them (e.g. have i2c1
be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also
be achieved using devicetree aliases (see i2c_add_adapter). However,
having the driver be self-contained without relying on aliases is more
robust.

Signed-off-by: Paweł Anikiel <pan@semihalf.com>
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 21113665ddea..f27e6bc9ad9d 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -280,7 +280,8 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
 					I2C_CLASS_HWMON : I2C_CLASS_DEPRECATED;
 	ACPI_COMPANION_SET(&adap->dev, ACPI_COMPANION(&pdev->dev));
 	adap->dev.of_node = pdev->dev.of_node;
-	adap->nr = -1;
+	if (of_property_read_u32(pdev->dev.of_node, "busno", &adap->nr))
+		adap->nr = -1;
 
 	if (dev->flags & ACCESS_NO_IRQ_SUSPEND) {
 		dev_pm_set_driver_flags(&pdev->dev,
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller

[Andy Shevchenko]

On Tue, Oct 05, 2021 at 04:37:45PM +0200, Paweł Anikiel wrote:
> On SoCFPGA systems, it's desireable to have fixed numbering for
> i2c busses, while being able to enable/disable them (e.g. have i2c1
> be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also
> be achieved using devicetree aliases (see i2c_add_adapter). However,
> having the driver be self-contained without relying on aliases is more
> robust.

Why? This number means nothing, user space has another means to have
this being robust. Sorry, but I don't see any even close to good enough
justification, NAK.

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 2/4] dt-bindings: add bus number property

[Paweł Anikiel]

On SoCFPGA systems, it's desireable to have fixed numbering for
i2c busses, while being able to enable/disable them (e.g. have i2c1
be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also
be achieved using devicetree aliases (see i2c_add_adapter). However,
having the driver be self-contained without relying on aliases is more
robust.

Signed-off-by: Paweł Anikiel <pan@semihalf.com>
---
 .../devicetree/bindings/i2c/snps,designware-i2c.yaml         | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
index d9293c57f573..1e02ddcbd690 100644
--- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
@@ -93,6 +93,11 @@ properties:
       - const: tx
       - const: rx
 
+  busno:
+    description: |
+      The property should contain the desired bus number (as opposed to
+      being assigned automatically)
+
 unevaluatedProperties: false
 
 required:
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/4] dt-bindings: add bus number property

[Arnd Bergmann]

On Tue, Oct 5, 2021 at 4:37 PM Paweł Anikiel <pan@semihalf.com> wrote:
>
> On SoCFPGA systems, it's desireable to have fixed numbering for
> i2c busses, while being able to enable/disable them (e.g. have i2c1
> be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also
> be achieved using devicetree aliases (see i2c_add_adapter). However,
> having the driver be self-contained without relying on aliases is more
> robust.
>
> Signed-off-by: Paweł Anikiel <pan@semihalf.com>

I don't see how adding a nonstandard property in one of the i2c bus
drivers helps at all. How do you expect this to work when there are
multiple i2c controllers in the system using different drivers? What
should happen if both an alias and the busno property are set?

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/4] dt-bindings: add bus number property

[Arnd Bergmann]

On Tue, Oct 5, 2021 at 4:37 PM Paweł Anikiel <pan@semihalf.com> wrote:
>
> On SoCFPGA systems, it's desireable to have fixed numbering for
> i2c busses, while being able to enable/disable them (e.g. have i2c1
> be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also
> be achieved using devicetree aliases (see i2c_add_adapter). However,
> having the driver be self-contained without relying on aliases is more
> robust.
>
> Signed-off-by: Paweł Anikiel <pan@semihalf.com>

I don't see how adding a nonstandard property in one of the i2c bus
drivers helps at all. How do you expect this to work when there are
multiple i2c controllers in the system using different drivers? What
should happen if both an alias and the busno property are set?

      Arnd

Re: [PATCH v2 2/4] dt-bindings: add bus number property

[Alexandre Belloni]

On 05/10/2021 18:22:12+0200, Arnd Bergmann wrote:
> On Tue, Oct 5, 2021 at 4:37 PM Paweł Anikiel <pan@semihalf.com> wrote:
> >
> > On SoCFPGA systems, it's desireable to have fixed numbering for
> > i2c busses, while being able to enable/disable them (e.g. have i2c1
> > be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also
> > be achieved using devicetree aliases (see i2c_add_adapter). However,
> > having the driver be self-contained without relying on aliases is more
> > robust.
> >
> > Signed-off-by: Paweł Anikiel <pan@semihalf.com>
> 
> I don't see how adding a nonstandard property in one of the i2c bus
> drivers helps at all. How do you expect this to work when there are
> multiple i2c controllers in the system using different drivers? What
> should happen if both an alias and the busno property are set?
> 

What happens when two nodes have the same busno property because e.g.
one is in a dtsi and the other one is in a dts?


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/4] dt-bindings: add bus number property

[Paweł Anikiel]

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

On Tue, Oct 5, 2021 at 6:28 PM Alexandre Belloni <
alexandre.belloni@bootlin.com> wrote:

> On 05/10/2021 18:22:12+0200, Arnd Bergmann wrote:
> > On Tue, Oct 5, 2021 at 4:37 PM Paweł Anikiel <pan@semihalf.com> wrote:
> > >
> > > On SoCFPGA systems, it's desireable to have fixed numbering for
> > > i2c busses, while being able to enable/disable them (e.g. have i2c1
> > > be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also
> > > be achieved using devicetree aliases (see i2c_add_adapter). However,
> > > having the driver be self-contained without relying on aliases is more
> > > robust.
> > >
> > > Signed-off-by: Paweł Anikiel <pan@semihalf.com>
> >
> > I don't see how adding a nonstandard property in one of the i2c bus
> > drivers helps at all. How do you expect this to work when there are
> > multiple i2c controllers in the system using different drivers? What
> > should happen if both an alias and the busno property are set?
> >
>
> What happens when two nodes have the same busno property because e.g.
> one is in a dtsi and the other one is in a dts?
>

If busno is set, the alias is ignored (the code that checks aliases
is never reached). If two nodes have the same busno property, we get
a WARN in drivers/i2c/i2c-core-base.c:1637, and only on of them
gets attached.

What is a better way of doing this then? Is adding aliases to the
devicetree like this okay?

aliases {
...
i2c0 = &i2c0;
i2c1 = &i2c1;
};

[-- Attachment #2: Type: text/html, Size: 2054 bytes --]

Re: [PATCH v2 2/4] dt-bindings: add bus number property

[Arnd Bergmann]

On Wed, Oct 6, 2021 at 11:21 AM Paweł Anikiel <pan@semihalf.com> wrote:
> On Tue, Oct 5, 2021 at 6:28 PM Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
>>
>> What happens when two nodes have the same busno property because e.g.
>> one is in a dtsi and the other one is in a dts?
>
>
> If busno is set, the alias is ignored (the code that checks aliases
> is never reached). If two nodes have the same busno property, we get
> a WARN in drivers/i2c/i2c-core-base.c:1637, and only on of them
> gets attached.
>
> What is a better way of doing this then? Is adding aliases to the
> devicetree like this okay?
>
> aliases {
> ...
> i2c0 = &i2c0;
> i2c1 = &i2c1;
> };

Yes, this is the normal way to do it.

The way I tend to think of it is that the soc.dtsi file contains a description
of hardware that exists inside of the chip and is as much as possible
detached from how an OS uses it or what is connected to it on the
outside. You then have the board.dts file that contains everything specific
to the board.

The /chosen and /aliases nodes in turn are specific to the individual
machine, based on local configuration, installed OS and boot loader,
and how the devices on the board are used.

We tend to have the /aliases node populated with a sensible configuration
of how we expect them to be used for a given board. So if your machine
connects two of the internal i2c buses on the SoC, it makes sense to assign
them the aliases i2c0 and i2c1. On the other hand, if one of them is
not connected anywhere, you may skip that, or if there is an additional
i2c controller in programmable logic or behind some gpio lines, you can
make that your i2c0 alias.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/4] dt-bindings: add bus number property

[Arnd Bergmann]

On Wed, Oct 6, 2021 at 11:21 AM Paweł Anikiel <pan@semihalf.com> wrote:
> On Tue, Oct 5, 2021 at 6:28 PM Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
>>
>> What happens when two nodes have the same busno property because e.g.
>> one is in a dtsi and the other one is in a dts?
>
>
> If busno is set, the alias is ignored (the code that checks aliases
> is never reached). If two nodes have the same busno property, we get
> a WARN in drivers/i2c/i2c-core-base.c:1637, and only on of them
> gets attached.
>
> What is a better way of doing this then? Is adding aliases to the
> devicetree like this okay?
>
> aliases {
> ...
> i2c0 = &i2c0;
> i2c1 = &i2c1;
> };

Yes, this is the normal way to do it.

The way I tend to think of it is that the soc.dtsi file contains a description
of hardware that exists inside of the chip and is as much as possible
detached from how an OS uses it or what is connected to it on the
outside. You then have the board.dts file that contains everything specific
to the board.

The /chosen and /aliases nodes in turn are specific to the individual
machine, based on local configuration, installed OS and boot loader,
and how the devices on the board are used.

We tend to have the /aliases node populated with a sensible configuration
of how we expect them to be used for a given board. So if your machine
connects two of the internal i2c buses on the SoC, it makes sense to assign
them the aliases i2c0 and i2c1. On the other hand, if one of them is
not connected anywhere, you may skip that, or if there is an additional
i2c controller in programmable logic or behind some gpio lines, you can
make that your i2c0 alias.

      Arnd

Re: [PATCH v2 2/4] dt-bindings: add bus number property

[Paweł Anikiel]

On Tue, Oct 5, 2021 at 6:28 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> On 05/10/2021 18:22:12+0200, Arnd Bergmann wrote:
> > On Tue, Oct 5, 2021 at 4:37 PM Paweł Anikiel <pan@semihalf.com> wrote:
> > >
> > > On SoCFPGA systems, it's desireable to have fixed numbering for
> > > i2c busses, while being able to enable/disable them (e.g. have i2c1
> > > be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also
> > > be achieved using devicetree aliases (see i2c_add_adapter). However,
> > > having the driver be self-contained without relying on aliases is more
> > > robust.
> > >
> > > Signed-off-by: Paweł Anikiel <pan@semihalf.com>
> >
> > I don't see how adding a nonstandard property in one of the i2c bus
> > drivers helps at all. How do you expect this to work when there are
> > multiple i2c controllers in the system using different drivers? What
> > should happen if both an alias and the busno property are set?
> >
>
> What happens when two nodes have the same busno property because e.g.
> one is in a dtsi and the other one is in a dts?
>

If busno is set, the alias is ignored (the code that checks aliases
is never reached). If two nodes have the same busno property, we get
a WARN in drivers/i2c/i2c-core-base.c:1637, and only on of them
gets attached.

What is a better way of doing this then? Is adding aliases to the
devicetree like this okay?

aliases {
...
i2c0 = &i2c0;
i2c1 = &i2c1;
};

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/4] dt-bindings: add bus number property

[Paweł Anikiel]

On Tue, Oct 5, 2021 at 6:28 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> On 05/10/2021 18:22:12+0200, Arnd Bergmann wrote:
> > On Tue, Oct 5, 2021 at 4:37 PM Paweł Anikiel <pan@semihalf.com> wrote:
> > >
> > > On SoCFPGA systems, it's desireable to have fixed numbering for
> > > i2c busses, while being able to enable/disable them (e.g. have i2c1
> > > be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also
> > > be achieved using devicetree aliases (see i2c_add_adapter). However,
> > > having the driver be self-contained without relying on aliases is more
> > > robust.
> > >
> > > Signed-off-by: Paweł Anikiel <pan@semihalf.com>
> >
> > I don't see how adding a nonstandard property in one of the i2c bus
> > drivers helps at all. How do you expect this to work when there are
> > multiple i2c controllers in the system using different drivers? What
> > should happen if both an alias and the busno property are set?
> >
>
> What happens when two nodes have the same busno property because e.g.
> one is in a dtsi and the other one is in a dts?
>

If busno is set, the alias is ignored (the code that checks aliases
is never reached). If two nodes have the same busno property, we get
a WARN in drivers/i2c/i2c-core-base.c:1637, and only on of them
gets attached.

What is a better way of doing this then? Is adding aliases to the
devicetree like this okay?

aliases {
...
i2c0 = &i2c0;
i2c1 = &i2c1;
};

Re: [PATCH v2 2/4] dt-bindings: add bus number property

[Rob Herring]

On Tue, Oct 05, 2021 at 04:37:46PM +0200, Paweł Anikiel wrote:
> On SoCFPGA systems, it's desireable to have fixed numbering for
> i2c busses, while being able to enable/disable them (e.g. have i2c1
> be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also
> be achieved using devicetree aliases (see i2c_add_adapter). However,
> having the driver be self-contained without relying on aliases is more
> robust.

Your header is a bit weird as you have 2 Message-IDs:

> Message-ID: <20211005143748.2471647-3-pan@semihalf.com>                                                                                                     
> X-Mailer: git-send-email 2.25.1                                                                                                                             
> Message-ID: <20211005143746.xE5rCkt-P_XlNkn9bJ8ZqYPY4nQQ7doqzSd4FrAlICY@z>                                                                                  

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 3/4] reset: socfpga: add empty driver allowing consumers to probe

[Paweł Anikiel]

The early reset driver doesn't ever probe, which causes consuming
devices to be unable to probe. Add an empty driver to set this device
as available, allowing consumers to probe.

Signed-off-by: Paweł Anikiel <pan@semihalf.com>
---
 drivers/reset/reset-socfpga.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
index 2a72f861f798..8c6492e5693c 100644
--- a/drivers/reset/reset-socfpga.c
+++ b/drivers/reset/reset-socfpga.c
@@ -92,3 +92,29 @@ void __init socfpga_reset_init(void)
 	for_each_matching_node(np, socfpga_early_reset_dt_ids)
 		a10_reset_init(np);
 }
+
+/*
+ * The early driver is problematic, because it doesn't register
+ * itself as a driver. This causes certain device links to prevent
+ * consumer devices from probing. The hacky solution is to register
+ * an empty driver, whose only job is to attach itself to the reset
+ * manager and call probe.
+ */
+static const struct of_device_id socfpga_reset_dt_ids[] = {
+	{ .compatible = "altr,rst-mgr", },
+	{ /* sentinel */ },
+};
+
+static int reset_simple_probe(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static struct platform_driver reset_socfpga_driver = {
+	.probe	= reset_simple_probe,
+	.driver = {
+		.name		= "socfpga-reset",
+		.of_match_table	= socfpga_reset_dt_ids,
+	},
+};
+builtin_platform_driver(reset_socfpga_driver);
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 4/4] dts: socfpga: Add Mercury+ AA1 devicetree

[Paweł Anikiel]

Add support for the Mercury+ AA1 module for Arria 10 SoC FPGA.

Signed-off-by: Paweł Anikiel <pan@semihalf.com>
Signed-off-by: Joanna Brozek <jbrozek@antmicro.com>
Signed-off-by: Mariusz Glebocki <mglebocki@antmicro.com>
Signed-off-by: Tomasz Gorochowik <tgorochowik@antmicro.com>
Signed-off-by: Maciej Mikunda <mmikunda@antmicro.com>
---
 arch/arm/boot/dts/Makefile                    |   1 +
 .../boot/dts/socfpga_arria10_mercury_aa1.dts  | 111 ++++++++++++++++++
 2 files changed, 112 insertions(+)
 create mode 100644 arch/arm/boot/dts/socfpga_arria10_mercury_aa1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e0934180724..0a7809eb3795 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1078,6 +1078,7 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += \
 	socfpga_arria10_socdk_nand.dtb \
 	socfpga_arria10_socdk_qspi.dtb \
 	socfpga_arria10_socdk_sdmmc.dtb \
+	socfpga_arria10_mercury_aa1.dtb \
 	socfpga_cyclone5_chameleon96.dtb \
 	socfpga_cyclone5_mcvevk.dtb \
 	socfpga_cyclone5_socdk.dtb \
diff --git a/arch/arm/boot/dts/socfpga_arria10_mercury_aa1.dts b/arch/arm/boot/dts/socfpga_arria10_mercury_aa1.dts
new file mode 100644
index 000000000000..1e11168b80db
--- /dev/null
+++ b/arch/arm/boot/dts/socfpga_arria10_mercury_aa1.dts
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "socfpga_arria10.dtsi"
+
+/ {
+
+	model = "Enclustra Mercury AA1";
+	compatible = "altr,socfpga-arria10", "altr,socfpga";
+
+	aliases {
+		ethernet0 = &gmac0;
+		serial1 = &uart1;
+	};
+
+	memory@0 {
+		name = "memory";
+		device_type = "memory";
+		reg = <0x0 0x80000000>; /* 2GB */
+	};
+
+	chosen {
+		stdout-path = "serial1:115200n8";
+	};
+};
+
+&eccmgr {
+	sdmmca-ecc@ff8c2c00 {
+		compatible = "altr,socfpga-sdmmc-ecc";
+		reg = <0xff8c2c00 0x400>;
+		altr,ecc-parent = <&mmc>;
+		interrupts = <15 IRQ_TYPE_LEVEL_HIGH>,
+			     <47 IRQ_TYPE_LEVEL_HIGH>,
+			     <16 IRQ_TYPE_LEVEL_HIGH>,
+			     <48 IRQ_TYPE_LEVEL_HIGH>;
+	};
+};
+
+&gmac0 {
+	phy-mode = "rgmii";
+	phy-addr = <0xffffffff>; /* probe for phy addr */
+
+	max-frame-size = <3800>;
+	status = "okay";
+
+	phy-handle = <&phy3>;
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "snps,dwmac-mdio";
+		phy3: ethernet-phy@3 {
+			txd0-skew-ps = <0>; /* -420ps */
+			txd1-skew-ps = <0>; /* -420ps */
+			txd2-skew-ps = <0>; /* -420ps */
+			txd3-skew-ps = <0>; /* -420ps */
+			rxd0-skew-ps = <420>; /* 0ps */
+			rxd1-skew-ps = <420>; /* 0ps */
+			rxd2-skew-ps = <420>; /* 0ps */
+			rxd3-skew-ps = <420>; /* 0ps */
+			txen-skew-ps = <0>; /* -420ps */
+			txc-skew-ps = <1860>; /* 960ps */
+			rxdv-skew-ps = <420>; /* 0ps */
+			rxc-skew-ps = <1680>; /* 780ps */
+			reg = <3>;
+		};
+	};
+};
+
+&gpio0 {
+	status = "okay";
+};
+
+&gpio1 {
+	status = "okay";
+};
+
+&gpio2 {
+	status = "okay";
+};
+
+&i2c1 {
+	status = "okay";
+	busno = <1>;
+	isl12022: isl12022@6f {
+		status = "okay";
+		compatible = "isil,isl12022";
+		reg = <0x6f>;
+	};
+};
+
+/* Following mappings are taken from arria10 socdk dts */
+&mmc {
+	status = "okay";
+	cap-sd-highspeed;
+	broken-cd;
+	bus-width = <4>;
+};
+
+&osc1 {
+	clock-frequency = <33330000>;
+};
+
+&uart1 {
+	status = "okay";
+};
+
+&usb0 {
+	status = "okay";
+	dr_mode = "host";
+};
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel