| Message ID | 1389048557-16364-1-git-send-email-andrew@lunn.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, 2014-01-06 at 23:49 +0100, Andrew Lunn wrote: > Re-implement the Marvell Kirkwood ts41x-setup.c in DT. > > As with the QNAP 119, there are two variants, depending on which SoC > has been used. They differ on Ethernet PHY addresses and number of > PCIe busses. > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> On the assumption that this is basically the same as the think you asked me to test last week: Tested-by: Ian Campbell <ijc@hellion.org.uk> (specifically kirkwood-ts419-6281.dtb) What is the plan for the board files for the ts* platforms? Are they going to go away? This seems to have happened for the Sheevaplug case, which is causing some transition pain for distros (e.g. http://bugs.debian.org/731345). The big issue for the ts devices is that each board file seems to be splitting into two DTB files so in order to handle upgrades we need to be able to detect which of the two variants we need, both when running the previous board-file kernel and when running the DT version. Any advice? You previously pointed me to a string in the dmesg but this might not be reliable if the early boot messages have gone from the circular buffer and in any case I'm not sure how wise it is to rely on parsing those. It looks like the board files determine things based on kirkwood_pcie_id() -- is the result of that available in userspace anywhere? I suppose counting the number of PCI buses would work, not a brilliant solution but given the need to work with board file kernels too maybe that's the best option. The other issue I spotted is that /dev/input/by-path/platform-gpio-keys-event has become /dev/input/by-path/platform-gpio_keys.3-event. Is it considered valid for a by-path name to change? In particular the 3 here is apparently the node depth in the DTB, which doesn't make much logical sense as a "path" in this context I don't think (I expect it to be some sort of path through the hardware buses, perhaps my expectation is wrong?). I may make the userspace tools (e.g. qcontrol) switch to listening on all input devices anyway (which realistically is mostly going to only be that one). Or is there some other stable input device naming scheme which should be implemented (perhaps on the udev side)? Thanks, Ian. > --- > arch/arm/boot/dts/Makefile | 4 +- > arch/arm/boot/dts/kirkwood-ts419-6281.dts | 20 ++++++++ > arch/arm/boot/dts/kirkwood-ts419-6282.dts | 32 ++++++++++++ > arch/arm/boot/dts/kirkwood-ts419.dtsi | 75 +++++++++++++++++++++++++++++ > 4 files changed, 130 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6281.dts > create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6282.dts > create mode 100644 arch/arm/boot/dts/kirkwood-ts419.dtsi > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 0447d726a6bc..938a62f75255 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -104,7 +104,9 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-b3.dtb \ > kirkwood-sheevaplug-esata.dtb \ > kirkwood-topkick.dtb \ > kirkwood-ts219-6281.dtb \ > - kirkwood-ts219-6282.dtb > + kirkwood-ts219-6282.dtb \ > + kirkwood-ts419-6281.dtb \ > + kirkwood-ts419-6282.dtb > dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb > dtb-$(CONFIG_ARCH_MSM) += qcom-msm8660-surf.dtb \ > qcom-msm8960-cdp.dtb > diff --git a/arch/arm/boot/dts/kirkwood-ts419-6281.dts b/arch/arm/boot/dts/kirkwood-ts419-6281.dts > new file mode 100644 > index 000000000000..aa22aa862857 > --- /dev/null > +++ b/arch/arm/boot/dts/kirkwood-ts419-6281.dts > @@ -0,0 +1,20 @@ > +/* > + * Device Tree file for QNAP TS41X with 6281 SoC > + * > + * Copyright (C) 2013, Andrew Lunn <andrew@lunn.ch> > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version > + * 2 of the License, or (at your option) any later version. > + */ > + > +/dts-v1/; > + > +#include "kirkwood.dtsi" > +#include "kirkwood-6281.dtsi" > +#include "kirkwood-ts219.dtsi" > +#include "kirkwood-ts419.dtsi" > + > +ðphy0 { reg = <8>; }; > +ðphy1 { reg = <0>; }; > diff --git a/arch/arm/boot/dts/kirkwood-ts419-6282.dts b/arch/arm/boot/dts/kirkwood-ts419-6282.dts > new file mode 100644 > index 000000000000..d7512d4cdced > --- /dev/null > +++ b/arch/arm/boot/dts/kirkwood-ts419-6282.dts > @@ -0,0 +1,32 @@ > +/* > + * Device Tree file for QNAP TS41X with 6282 SoC > + * > + * Copyright (C) 2013, Andrew Lunn <andrew@lunn.ch> > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version > + * 2 of the License, or (at your option) any later version. > + */ > + > +/dts-v1/; > + > +#include "kirkwood.dtsi" > +#include "kirkwood-6282.dtsi" > +#include "kirkwood-ts219.dtsi" > +#include "kirkwood-ts419.dtsi" > + > +/ { > + mbus { > + pcie-controller { > + status = "okay"; > + > + pcie@2,0 { > + status = "okay"; > + }; > + }; > + }; > +}; > + > +ðphy0 { reg = <0>; }; > +ðphy1 { reg = <1>; }; > diff --git a/arch/arm/boot/dts/kirkwood-ts419.dtsi b/arch/arm/boot/dts/kirkwood-ts419.dtsi > new file mode 100644 > index 000000000000..1a9c624c7a92 > --- /dev/null > +++ b/arch/arm/boot/dts/kirkwood-ts419.dtsi > @@ -0,0 +1,75 @@ > +/* > + * Device Tree include file for QNAP TS41X > + * > + * Copyright (C) 2013, Andrew Lunn <andrew@lunn.ch> > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version > + * 2 of the License, or (at your option) any later version. > + */ > + > +/ { > + model = "QNAP TS419 family"; > + compatible = "qnap,ts419", "marvell,kirkwood"; > + > + ocp@f1000000 { > + pinctrl: pinctrl@10000 { > + pinctrl-names = "default"; > + > + pmx_USB_copy_button: pmx-USB-copy-button { > + marvell,pins = "mpp43"; > + marvell,function = "gpio"; > + }; > + pmx_reset_button: pmx-reset-button { > + marvell,pins = "mpp37"; > + marvell,function = "gpio"; > + }; > + /* > + * JP1 indicates if an LCD module is installed > + * on the serial port (0), or if the port is used > + * as a console (1). > + */ > + pmx_jumper_jp1: pmx-jumper_jp1 { > + marvell,pins = "mpp45"; > + marvell,function = "gpio"; > + }; > + > + }; > + }; > + > + gpio_keys { > + compatible = "gpio-keys"; > + #address-cells = <1>; > + #size-cells = <0>; > + pinctrl-0 = <&pmx_reset_button &pmx_USB_copy_button>; > + pinctrl-names = "default"; > + > + button@1 { > + label = "USB Copy"; > + linux,code = <KEY_COPY>; > + gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; > + }; > + button@2 { > + label = "Reset"; > + linux,code = <KEY_RESTART>; > + gpios = <&gpio1 5 GPIO_ACTIVE_LOW>; > + }; > + }; > +}; > + > +&mdio { > + status = "okay"; > + > + ethphy1: ethernet-phy@1 { > + device_type = "ethernet-phy"; > + /* overwrite reg property in board file */ > + }; > +}; > + > +ð1 { > + status = "okay"; > + ethernet1-port@0 { > + phy-handle = <ðphy1>; > + }; > +};
On Wed, Jan 08, 2014 at 09:48:37AM +0000, Ian Campbell wrote: > On Mon, 2014-01-06 at 23:49 +0100, Andrew Lunn wrote: > > Re-implement the Marvell Kirkwood ts41x-setup.c in DT. > > > > As with the QNAP 119, there are two variants, depending on which SoC > > has been used. They differ on Ethernet PHY addresses and number of > > PCIe busses. > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > On the assumption that this is basically the same as the think you asked > me to test last week: > Tested-by: Ian Campbell <ijc@hellion.org.uk> (specifically kirkwood-ts419-6281.dtb) It is the same. Thanks for testing. > What is the plan for the board files for the ts* platforms? Are they > going to go away? This seems to have happened for the Sheevaplug case, > which is causing some transition pain for distros (e.g. > http://bugs.debian.org/731345). We plan to make them go away. We are not quite there yet, there are still a couple of boards which don't have DT files. But we are working on those. > The big issue for the ts devices is that each board file seems to be > splitting into two DTB files so in order to handle upgrades we need to > be able to detect which of the two variants we need, both when running > the previous board-file kernel and when running the DT version. Any > advice? You previously pointed me to a string in the dmesg but this > might not be reliable if the early boot messages have gone from the > circular buffer and in any case I'm not sure how wise it is to rely on > parsing those. > > It looks like the board files determine things based on > kirkwood_pcie_id() -- is the result of that available in userspace > anywhere? I suppose counting the number of PCI buses would work, not a > brilliant solution but given the need to work with board file kernels > too maybe that's the best option. This is an issue, which has been discussed a bit recently while fixing an i2c issues on Marvell XP SoCs. As far as i know, there is no reliable export of the version field. It might be available from lspci, but so far i've not seen it. I will look into this in the next few days. > The other issue I spotted is > that /dev/input/by-path/platform-gpio-keys-event has > become /dev/input/by-path/platform-gpio_keys.3-event. Is it considered > valid for a by-path name to change? In particular the 3 here is > apparently the node depth in the DTB, which doesn't make much logical > sense as a "path" in this context I don't think (I expect it to be some > sort of path through the hardware buses, perhaps my expectation is > wrong?). To be honest, i've no idea about this. I hope somebody else will answer. If not, we might need to ask on the input mailing list. Andrew
On Wed, Jan 08, 2014 at 09:48:37AM +0000, Ian Campbell wrote: > On Mon, 2014-01-06 at 23:49 +0100, Andrew Lunn wrote: Hi Ian I added in the devicetree list and the input list and added my thoughts below. > The other issue I spotted is > that /dev/input/by-path/platform-gpio-keys-event has > become /dev/input/by-path/platform-gpio_keys.3-event. Is it considered > valid for a by-path name to change? In particular the 3 here is > apparently the node depth in the DTB, which doesn't make much logical > sense as a "path" in this context I don't think (I expect it to be some > sort of path through the hardware buses, perhaps my expectation is > wrong?). The ts41x-setup.c board file creates the gpio keys platform device using the following structure: static struct platform_device qnap_ts41x_button_device = { .name = "gpio-keys", .id = -1, .num_resources = 0, .dev = { .platform_data = &qnap_ts41x_button_data, } }; The id of -1 causes platform_device_add() to set the device name to plain "gpio-keys". When using DT, the device name is created by the function of_device_make_bus_id(). It has the following comment: * This routine will first try using either the dcr-reg or the reg property * value to derive a unique name. As a last resort it will use the node * name followed by a unique number. Since the gpio_keys node does not have a reg properties, it gets a unique number appended to it. We end up with the device name "gpio_keys.3" So as it stands, it does not appear i can make the DT system use the same device name as a board system. But i'm also a little bit concerned by the "unique number" and this ending up in /dev/input/by-path/platform-gpio_keys.3-event. Is this path supposed to be stable? This unique number is not stable. An unwitting change to the DT could cause its value to change. Do we need to make it stable? Andrew
Ian, On Wed, Jan 08, 2014 at 09:48:37AM +0000, Ian Campbell wrote: > What is the plan for the board files for the ts* platforms? Are they > going to go away? This seems to have happened for the Sheevaplug case, > which is causing some transition pain for distros (e.g. > http://bugs.debian.org/731345). Sorry, I'm rather swamped at the moment. From my cursory reading of the thread, is it correct to say that this problem can be solved by enabling the CONFIG_MACH_SHEEVAPLUG_DT config option? thx, Jason.
On Mon, Jan 06, 2014 at 11:49:17PM +0100, Andrew Lunn wrote: > Re-implement the Marvell Kirkwood ts41x-setup.c in DT. > > As with the QNAP 119, there are two variants, depending on which SoC > has been used. They differ on Ethernet PHY addresses and number of > PCIe busses. > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > --- > arch/arm/boot/dts/Makefile | 4 +- > arch/arm/boot/dts/kirkwood-ts419-6281.dts | 20 ++++++++ > arch/arm/boot/dts/kirkwood-ts419-6282.dts | 32 ++++++++++++ > arch/arm/boot/dts/kirkwood-ts419.dtsi | 75 +++++++++++++++++++++++++++++ > 4 files changed, 130 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6281.dts > create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6282.dts > create mode 100644 arch/arm/boot/dts/kirkwood-ts419.dtsi Applied to mvebu/dt with Ian's Tested-by thx, Jason.
On Mon, 2014-01-13 at 19:39 -0500, Jason Cooper wrote: > Ian, > > On Wed, Jan 08, 2014 at 09:48:37AM +0000, Ian Campbell wrote: > > What is the plan for the board files for the ts* platforms? Are they > > going to go away? This seems to have happened for the Sheevaplug case, > > which is causing some transition pain for distros (e.g. > > http://bugs.debian.org/731345). > > Sorry, I'm rather swamped at the moment. From my cursory reading of the > thread, is it correct to say that this problem can be solved by enabling > the CONFIG_MACH_SHEEVAPLUG_DT config option? That would have allows 3.11 to boot with DT, but for 3.11 we are OK with the board file support from a Debian PoV The real issue is the transition of the userspace components which configure the bootloader (called "flash-kernel" in Debian) which needs to know whether or not a DTB should be appended. I think we've now mostly solved that by teaching flash-kernel what the minimum kernel version which requires a DTB is (see [0] and [1]), I've set this to 3.12 for Sheevaplug and Guruplug, I'll set it to whatever is appropriate on the ts* platforms when the time comes. Ian. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731345http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731345 [1] http://anonscm.debian.org/gitweb/?p=d-i/flash-kernel.git;a=commit;h=f656a00daa4d1ada46203e6e1831ae574eb005f8
On Mon, Jan 13, 2014 at 07:48:33PM -0500, Jason Cooper wrote: > On Mon, Jan 06, 2014 at 11:49:17PM +0100, Andrew Lunn wrote: > > Re-implement the Marvell Kirkwood ts41x-setup.c in DT. > > > > As with the QNAP 119, there are two variants, depending on which SoC > > has been used. They differ on Ethernet PHY addresses and number of > > PCIe busses. > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > --- > > arch/arm/boot/dts/Makefile | 4 +- > > arch/arm/boot/dts/kirkwood-ts419-6281.dts | 20 ++++++++ > > arch/arm/boot/dts/kirkwood-ts419-6282.dts | 32 ++++++++++++ > > arch/arm/boot/dts/kirkwood-ts419.dtsi | 75 +++++++++++++++++++++++++++++ > > 4 files changed, 130 insertions(+), 1 deletion(-) > > create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6281.dts > > create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6282.dts > > create mode 100644 arch/arm/boot/dts/kirkwood-ts419.dtsi > > Applied to mvebu/dt with Ian's Tested-by Hi Jason Thanks, but please could you hold onto it for a while. I would like to see how the discussion about unstable /dev/input/by-path discussion plays out. That is if anybody actually replies to my question... Thanks Andrew
On Tue, Jan 14, 2014 at 10:15:43AM +0100, Andrew Lunn wrote: > On Mon, Jan 13, 2014 at 07:48:33PM -0500, Jason Cooper wrote: > > On Mon, Jan 06, 2014 at 11:49:17PM +0100, Andrew Lunn wrote: > > > Re-implement the Marvell Kirkwood ts41x-setup.c in DT. > > > > > > As with the QNAP 119, there are two variants, depending on which SoC > > > has been used. They differ on Ethernet PHY addresses and number of > > > PCIe busses. > > > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > > --- > > > arch/arm/boot/dts/Makefile | 4 +- > > > arch/arm/boot/dts/kirkwood-ts419-6281.dts | 20 ++++++++ > > > arch/arm/boot/dts/kirkwood-ts419-6282.dts | 32 ++++++++++++ > > > arch/arm/boot/dts/kirkwood-ts419.dtsi | 75 +++++++++++++++++++++++++++++ > > > 4 files changed, 130 insertions(+), 1 deletion(-) > > > create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6281.dts > > > create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6282.dts > > > create mode 100644 arch/arm/boot/dts/kirkwood-ts419.dtsi > > > > Applied to mvebu/dt with Ian's Tested-by > > Hi Jason > > Thanks, but please could you hold onto it for a while. I would like to > see how the discussion about unstable /dev/input/by-path discussion > plays out. That is if anybody actually replies to my question... Ok, this and the Bubba board are probably for next cycle at this point anyhow. I'll send pulls for the fixes sometime today. thx, Jason.
On Saturday 11 January 2014, Andrew Lunn wrote: > The id of -1 causes platform_device_add() to set the device name to > plain "gpio-keys". > > When using DT, the device name is created by the function > of_device_make_bus_id(). It has the following comment: > > * This routine will first try using either the dcr-reg or the reg property > * value to derive a unique name. As a last resort it will use the node > * name followed by a unique number. > > Since the gpio_keys node does not have a reg properties, it gets a > unique number appended to it. We end up with the device name > "gpio_keys.3" > > So as it stands, it does not appear i can make the DT system use the > same device name as a board system. > > But i'm also a little bit concerned by the "unique number" and this > ending up in /dev/input/by-path/platform-gpio_keys.3-event. Is this > path supposed to be stable? This unique number is not stable. An > unwitting change to the DT could cause its value to change. Do we need > to make it stable? > One possibility would be to create an artificial bus in DT for all gpio-keys devices, use #address-cells=<1> and #size-cells=<0> for it, and give each device a unique reg property. Not sure if that would be considered an elegant solution though. Arnd
> > But i'm also a little bit concerned by the "unique number" and this > > ending up in /dev/input/by-path/platform-gpio_keys.3-event. Is this > > path supposed to be stable? This unique number is not stable. An > > unwitting change to the DT could cause its value to change. Do we need > > to make it stable? > > > > One possibility would be to create an artificial bus in DT for all > gpio-keys devices, use #address-cells=<1> and #size-cells=<0> > for it, and give each device a unique reg property. Not sure if that > would be considered an elegant solution though. Hi Arnd Can i imply from your answer that you think /dev/input/by-path/platform-gpio_keys.3-event should be stable? A quick look at udev rules seems to suggestion this is an issue for input/gpio-keys and maybe audio and video if there is a top level DT property collecting the different sub devices together for ASOC and V4L. Thanks Andrew
On Wednesday 15 January 2014 18:45:19 Andrew Lunn wrote: > > > But i'm also a little bit concerned by the "unique number" and this > > > ending up in /dev/input/by-path/platform-gpio_keys.3-event. Is this > > > path supposed to be stable? This unique number is not stable. An > > > unwitting change to the DT could cause its value to change. Do we need > > > to make it stable? > > > > > > > One possibility would be to create an artificial bus in DT for all > > gpio-keys devices, use #address-cells=<1> and #size-cells=<0> > > for it, and give each device a unique reg property. Not sure if that > > would be considered an elegant solution though. > > Hi Arnd > > Can i imply from your answer that you think > > /dev/input/by-path/platform-gpio_keys.3-event > > should be stable? No, I have no idea whether it should be or not. I was just trying to come up with a way to make it stable if that's desired. > A quick look at udev rules seems to suggestion this is an issue for > input/gpio-keys and maybe audio and video if there is a top level DT > property collecting the different sub devices together for ASOC and > V4L. For some other subsystems, we have entries in /aliases/ to sort them. Maybe that would work here to get a stable path independent of the location in DT. Arnd
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 0447d726a6bc..938a62f75255 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -104,7 +104,9 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-b3.dtb \ kirkwood-sheevaplug-esata.dtb \ kirkwood-topkick.dtb \ kirkwood-ts219-6281.dtb \ - kirkwood-ts219-6282.dtb + kirkwood-ts219-6282.dtb \ + kirkwood-ts419-6281.dtb \ + kirkwood-ts419-6282.dtb dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb dtb-$(CONFIG_ARCH_MSM) += qcom-msm8660-surf.dtb \ qcom-msm8960-cdp.dtb diff --git a/arch/arm/boot/dts/kirkwood-ts419-6281.dts b/arch/arm/boot/dts/kirkwood-ts419-6281.dts new file mode 100644 index 000000000000..aa22aa862857 --- /dev/null +++ b/arch/arm/boot/dts/kirkwood-ts419-6281.dts @@ -0,0 +1,20 @@ +/* + * Device Tree file for QNAP TS41X with 6281 SoC + * + * Copyright (C) 2013, Andrew Lunn <andrew@lunn.ch> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +/dts-v1/; + +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" +#include "kirkwood-ts219.dtsi" +#include "kirkwood-ts419.dtsi" + +ðphy0 { reg = <8>; }; +ðphy1 { reg = <0>; }; diff --git a/arch/arm/boot/dts/kirkwood-ts419-6282.dts b/arch/arm/boot/dts/kirkwood-ts419-6282.dts new file mode 100644 index 000000000000..d7512d4cdced --- /dev/null +++ b/arch/arm/boot/dts/kirkwood-ts419-6282.dts @@ -0,0 +1,32 @@ +/* + * Device Tree file for QNAP TS41X with 6282 SoC + * + * Copyright (C) 2013, Andrew Lunn <andrew@lunn.ch> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +/dts-v1/; + +#include "kirkwood.dtsi" +#include "kirkwood-6282.dtsi" +#include "kirkwood-ts219.dtsi" +#include "kirkwood-ts419.dtsi" + +/ { + mbus { + pcie-controller { + status = "okay"; + + pcie@2,0 { + status = "okay"; + }; + }; + }; +}; + +ðphy0 { reg = <0>; }; +ðphy1 { reg = <1>; }; diff --git a/arch/arm/boot/dts/kirkwood-ts419.dtsi b/arch/arm/boot/dts/kirkwood-ts419.dtsi new file mode 100644 index 000000000000..1a9c624c7a92 --- /dev/null +++ b/arch/arm/boot/dts/kirkwood-ts419.dtsi @@ -0,0 +1,75 @@ +/* + * Device Tree include file for QNAP TS41X + * + * Copyright (C) 2013, Andrew Lunn <andrew@lunn.ch> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +/ { + model = "QNAP TS419 family"; + compatible = "qnap,ts419", "marvell,kirkwood"; + + ocp@f1000000 { + pinctrl: pinctrl@10000 { + pinctrl-names = "default"; + + pmx_USB_copy_button: pmx-USB-copy-button { + marvell,pins = "mpp43"; + marvell,function = "gpio"; + }; + pmx_reset_button: pmx-reset-button { + marvell,pins = "mpp37"; + marvell,function = "gpio"; + }; + /* + * JP1 indicates if an LCD module is installed + * on the serial port (0), or if the port is used + * as a console (1). + */ + pmx_jumper_jp1: pmx-jumper_jp1 { + marvell,pins = "mpp45"; + marvell,function = "gpio"; + }; + + }; + }; + + gpio_keys { + compatible = "gpio-keys"; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-0 = <&pmx_reset_button &pmx_USB_copy_button>; + pinctrl-names = "default"; + + button@1 { + label = "USB Copy"; + linux,code = <KEY_COPY>; + gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; + }; + button@2 { + label = "Reset"; + linux,code = <KEY_RESTART>; + gpios = <&gpio1 5 GPIO_ACTIVE_LOW>; + }; + }; +}; + +&mdio { + status = "okay"; + + ethphy1: ethernet-phy@1 { + device_type = "ethernet-phy"; + /* overwrite reg property in board file */ + }; +}; + +ð1 { + status = "okay"; + ethernet1-port@0 { + phy-handle = <ðphy1>; + }; +};
Re-implement the Marvell Kirkwood ts41x-setup.c in DT. As with the QNAP 119, there are two variants, depending on which SoC has been used. They differ on Ethernet PHY addresses and number of PCIe busses. Signed-off-by: Andrew Lunn <andrew@lunn.ch> --- arch/arm/boot/dts/Makefile | 4 +- arch/arm/boot/dts/kirkwood-ts419-6281.dts | 20 ++++++++ arch/arm/boot/dts/kirkwood-ts419-6282.dts | 32 ++++++++++++ arch/arm/boot/dts/kirkwood-ts419.dtsi | 75 +++++++++++++++++++++++++++++ 4 files changed, 130 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6281.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6282.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts419.dtsi