diff mbox series

[OpenWrt-Devel,v2] ath79: add D-Link DIR-615 E4

Message ID 20191109135320.25020-1-fercerpav@gmail.com
State Changes Requested
Headers show
Series [OpenWrt-Devel,v2] ath79: add D-Link DIR-615 E4 | expand

Commit Message

Paul Fertser Nov. 9, 2019, 1:53 p.m. UTC 
Support ported from ar71xx.

Tested on hardware: flashing OpenWrt, then downgrading to vendor
firmware, then using regular vendor web interface to upgrade to OpenWrt
(using -factory.bin image). All MACs in vendor firmware were correct,
the only visible quirk was meaningless "Hardware Version:" field in the
web interface page header (one can append "mac" partition contents to
the vendor firmware dump prior to flashing if that's too worrying).

Signed-off-by: Paul Fertser <fercerpav@gmail.com>
---
Changes for v2:

    - Remove "rev." from board name
    - Use a single DTS file; whoever has hardware to port this to the other
      similar devices can easily unsplit it later
    - Fix label_mac handling (as it's not available in DT)
    - Rename gpio_leds to leds DTS section
    - Use boardname for LEDs and merge the setup code with buffalo,whr-g301n
    - Use 33 MHz for SPI clock (max frequency for READ command acconding to the
      chip datasheet)
    - Make "firmware" partition 0x3b0000 (3776 kiB) long, covering "mac" and "lp"

 .../ath79/dts/ar7240_dlink_dir-615-e4.dts     | 188 ++++++++++++++++++
 target/linux/ath79/image/tiny.mk              |  16 ++
 .../ath79/tiny/base-files/etc/board.d/01_leds |   3 +-
 .../tiny/base-files/etc/board.d/02_network    |   6 +
 .../etc/hotplug.d/firmware/10-ath9k-eeprom    |   4 +
 5 files changed, 216 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts

Comments

Adrian Schmutzler Nov. 11, 2019, 11:12 a.m. UTC | #1 
Hi Paul,

[...]

> +	aliases {
> +		led-boot = &power_amber;

Please include "led_" prefix for the labels, so &led_power_amber in this case.

> +		led-failsafe = &power_amber;
> +		led-running = &power_green;
> +		led-upgrade = &power_amber;
> +	};
> +

[...]

> +	leds {
> +		compatible = "gpio-leds";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&switch_led_pins>;
> +
> +		power_green: power_green {

As stated above, change the _label_ to include a "led_" prefix, so this becomes "led_power_green: power_green {". Same for power_amber below.

> +			label = "dir-615-e4:green:power";

Sorry for causing confusion here. I have had a look into ar71xx mach files and they consistent use "d-link" as vendor for the led labels. Thus, I think it makes more sense to revert that to the previous version "d-link:green:power".

> +			gpios = <&gpio 6 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		power_amber: power_amber {
> +			label = "dir-615-e4:amber:power";
> +			gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		wps {
> +			label = "dir-615-e4:blue:wps";
> +			gpios = <&gpio 0 GPIO_ACTIVE_LOW>;
> +		};
> +
> +		lan1 {
> +			label = "dir-615-e4:green:lan1";
> +			gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
> +		};
> +
> +		lan2 {
> +			label = "dir-615-e4:green:lan2";
> +			gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
> +		};
> +
> +		lan3 {
> +			label = "dir-615-e4:green:lan3";
> +			gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
> +		};
> +
> +		lan4 {
> +			label = "dir-615-e4:green:lan4";
> +			gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
> +		};
> +
> +		wan_amber {
> +			label = "dir-615-e4:amber:wan";
> +			gpios = <&gpio 7 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		wan_green {
> +			label = "dir-615-e4:green:wan";
> +			gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
> +		};
> +
> +		wlan {
> +			label = "dir-615-e4:green:wlan";
> +			gpios = <&ath9k 1 GPIO_ACTIVE_LOW>;
> +			linux,default-trigger = "phy0tpt";
> +		};

At some point, we started to put ath9k leds into a node of their own:

	ath9k-leds {
		wlan {
			label = "dir-615-e4:green:wlan";
			gpios = <&ath9k 1 GPIO_ACTIVE_LOW>;
			linux,default-trigger = "phy0tpt";
		};
	};

> +	};
> +};
> +
> +&spi {
> +	status = "okay";
> +	num-cs = <1>;

Please add empty line after status.

> +
> +	flash@0 {
> +		compatible = "jedec,spi-nor";
> +		reg = <0>;
> +		spi-max-frequency = <33000000>;
> +
> +		partitions {
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			uboot: partition@0 {
> +				reg = <0x0 0x30000>;
> +				label = "u-boot";
> +				read-only;
> +			};
> +
> +			nvram: partition@30000 {
> +				reg = <0x30000 0x10000>;
> +				label = "nvram";
> +				read-only;
> +			};

Remove the node labels for the two partitions above, as they are not used anyway (but not the label properties).

> +
> +			firmware: partition@40000 {
> +				compatible = "denx,uimage";
> +				reg = <0x40000 0x3b0000>;
> +				label = "firmware";
> +			};
> +
> +			/*
> +			These two partitions are defined by CameoAP99 layout
> +			but not needed for vendor firmware: MAC address is
> taken
> +			from "nvram", language pack can be flashed separately.
> +
> +			mac: partition@3b0000 {
> +				reg = <0x3b0000 0x10000>;
> +				label = "mac";
> +				read-only;
> +			};
> +
> +			lp: partition@3c0000 {
> +				reg = <0x3c0000 0x30000>;
> +				label = "lp";
> +				read-only;
> +			};
> +			*/

Well, we still do not know whether they are present in vendor firmware. I'm still skeptical about removing them.
Nevertheless, I won't prevent you from doing that, but please remove this comment from the DTS then and put an extensive description into the commit message instead.

> +
> +			art: partition@3f0000 {
> +				reg = <0x3f0000 0x10000>;
> +				label = "art";
> +				read-only;
> +			};
> +		};
> +	};
> +};
> +
> +&eth0 {
> +	status = "okay";
> +
> +	/* ethernet MAC is stored in nvram */

Remove those comments. You are setting up stuff in 02_network, which are relatively standard, so I think extra comments are not necessary.

> +};
> +
> +&eth1 {
> +	status = "okay";
> +
> +	/* ethernet MAC is stored in nvram */

Remove comment.

> +};
> +
> +&pcie {
> +	status = "okay";
> +
> +	ath9k: wifi@0,0 {
> +		compatible = "pci168c,002b";
> +		reg = <0x0000 0 0 0 0>;
> +		qca,no-eeprom;
> +		/* LAN MAC is supposed to be used for wifi */

Remove comment.

Don't forget to split the 01_leds definitions again ...

Best

Adrian
Adrian Schmutzler Nov. 11, 2019, 12:03 p.m. UTC | #2 
Hi,

> > > +                   label = "dir-615-e4:green:power"; 
> > 
> > Sorry for causing confusion here. I have had a look into ar71xx 
> > mach files and they consistent use "d-link" as vendor for the 
> > led labels. Thus, I think it makes more sense to revert that to 
> > the previous version "d-link:green:power". 
> Yes, and that used to be wrong :) 
> Originally upstream said it was meant to be board name here, 
> "d-link" was always wrong. (this was an interpretation debate on 
> "uniqueness" see 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/leds/common.txt?id=116b8e164116be537f50cdcce84d80be0facd0cf)

Well, just from the commit message and documentation only the "LED class device" has to be uniquely identified. That doesn't state in which set it has to be unique. One could also interpret this in a way that only the LEDs in a certain DTS (and thus for the device at hand) have to be unique, so you cannot label two of them "usb".

> Of course, nowadays, they actually say that label itself is 
> deprecated, so if we're moving forwards, let's just use "color" 
> and "function" attributes instead directly? (though the new 
> attributes are only available since 2019-07-xx timeframes)

I'd like that, and I never understood why the device part was actually introduced there. However, I'm too new as a committer to decide on that.

> (Or 
> just drop them, labels are always only needed if didn't name the 
> node clearly enough, or wanted characters you weren't allowed in 
> the node name) 

Those labels are used for luci AFAIK, and I'm not really familiar with the mechanics of luci, so I cannot comment on this one.

Best

Adrian
Adrian Schmutzler Nov. 11, 2019, 12:09 p.m. UTC | #3 
Hi again,

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org] On
> Behalf Of Paul Fertser
> Sent: Samstag, 9. November 2019 14:53
> To: openwrt-devel@lists.openwrt.org
> Cc: Paul Fertser <fercerpav@gmail.com>; Adrian Schmutzler
> <mail@adrianschmutzler.de>; tmo26@gmx.de
> Subject: [OpenWrt-Devel] [PATCH v2] ath79: add D-Link DIR-615 E4
> 
> Support ported from ar71xx.
> 
> Tested on hardware: flashing OpenWrt, then downgrading to vendor
> firmware, then using regular vendor web interface to upgrade to OpenWrt
> (using -factory.bin image). All MACs in vendor firmware were correct,
> the only visible quirk was meaningless "Hardware Version:" field in the
> web interface page header (one can append "mac" partition contents to
> the vendor firmware dump prior to flashing if that's too worrying).

please include specifications and flashing instructions into the commit message, also for ported devices.
In most cases you can exploit the support commit from ar71xx to start with ...

Best

Adrian
Paul Fertser Nov. 11, 2019, 12:14 p.m. UTC | #4 
Hello Adrian,

Thank you very much for the review.

On Mon, Nov 11, 2019 at 12:12:47PM +0100, Adrian Schmutzler wrote:
> > +		power_green: power_green {
> 
> As stated above, change the _label_ to include a "led_" prefix, so
> this becomes "led_power_green: power_green {". Same for power_amber
> below.

Noted.

> > +			label = "dir-615-e4:green:power";
> 
> Sorry for causing confusion here. I have had a look into ar71xx mach
> files and they consistent use "d-link" as vendor for the led
> labels. Thus, I think it makes more sense to revert that to the
> previous version "d-link:green:power".

Why do you think so? If board name is a good idea and allows sharing
led arrangements (and sharing is desired) then why should we stick to
the old way of doing it?

> > +		wlan {
> > +			label = "dir-615-e4:green:wlan";
> > +			gpios = <&ath9k 1 GPIO_ACTIVE_LOW>;
> > +			linux,default-trigger = "phy0tpt";
> > +		};
> 
> At some point, we started to put ath9k leds into a node of their own:

Noted.

> > +&spi {
> > +	status = "okay";
> > +	num-cs = <1>;
> 
> Please add empty line after status.

Yep.

> > +			nvram: partition@30000 {
> > +				reg = <0x30000 0x10000>;
> > +				label = "nvram";
> > +				read-only;
> > +			};
> 
> Remove the node labels for the two partitions above, as they are not used anyway (but not the label properties).

Noted.

> > +			/*
> > +			These two partitions are defined by CameoAP99 layout
> > +			but not needed for vendor firmware: MAC address is
> > taken
> > +			from "nvram", language pack can be flashed separately.
> > +
> > +			mac: partition@3b0000 {
> > +				reg = <0x3b0000 0x10000>;
> > +				label = "mac";
> > +				read-only;
> > +			};
> > +
> > +			lp: partition@3c0000 {
> > +				reg = <0x3c0000 0x30000>;
> > +				label = "lp";
> > +				read-only;
> > +			};
> > +			*/
> 
> Well, we still do not know whether they are present in vendor
> firmware. I'm still skeptical about removing them.  Nevertheless, I
> won't prevent you from doing that, but please remove this comment
> from the DTS then and put an extensive description into the commit
> message instead.

I've made specific effort to flash vendor firmware and confirmed by
testing on hardware that the vendor firmware doesn't need those
partitions. Isn't that enough? What important aspects did I not check?

Regarding removing comments in DTS, this I am not yet sure is the
right way to go, please consider this rationale: DTS files are not
only OpenWrt-specific, they're supposed to specify hardware
arrangements for the upstream Linux, and for all the other low-level
software that can be booted on hardware too (such as barebox and
u-boot bootloaders). This said, whatever can't be expressed as a set
of properties should still be mentioned in the comments so that
whoever is dealing with this hardware has extensive information.

> > +&eth0 {
> > +	status = "okay";
> > +
> > +	/* ethernet MAC is stored in nvram */
> 
> Remove those comments. You are setting up stuff in 02_network, which
> are relatively standard, so I think extra comments are not
> necessary.

E.g. when (if at all ever) the kernel gains support for parsing nvram
partition, this comment will be changed to a proper DT property. But
it doesn't mean that a person looking at this file before that happens
should need to consult OpenWrt sources to understand how to deal with
this board properly.
Adrian Schmutzler Nov. 11, 2019, 12:53 p.m. UTC | #5 
Hi,

> > > +			label = "dir-615-e4:green:power";
> >
> > Sorry for causing confusion here. I have had a look into ar71xx mach
> > files and they consistent use "d-link" as vendor for the led
> > labels. Thus, I think it makes more sense to revert that to the
> > previous version "d-link:green:power".
> 
> Why do you think so? If board name is a good idea and allows sharing
> led arrangements (and sharing is desired) then why should we stick to
> the old way of doing it?

Because with boardname-specific LED labels you cannot share the LED definitions in device tree, so they cannot be moved into a common DTSI.
Despite, if you had several similar d-link devices, you could also share definitions in 01_leds for those again.
But 01_leds is just a workaround for stuff that cannot be defined in DTS, so IMO the impact on DT is more important than the impact on 01_leds.

> > Well, we still do not know whether they are present in vendor
> > firmware. I'm still skeptical about removing them.  Nevertheless, I
> > won't prevent you from doing that, but please remove this comment
> > from the DTS then and put an extensive description into the commit
> > message instead.
> 
> I've made specific effort to flash vendor firmware and confirmed by
> testing on hardware that the vendor firmware doesn't need those
> partitions. Isn't that enough? What important aspects did I not check?

I haven't been able to extract that precise information from your previous comments (I don't want to blame you for that, maybe I just overlooked it ...).

If stock firmware works without those partitions, removing them is fine for me. Please explicitly state in your commit message (after telling about the removal) that you tested successfully on vendor firmware. :-)

> 
> Regarding removing comments in DTS, this I am not yet sure is the
> right way to go, please consider this rationale: DTS files are not
> only OpenWrt-specific, they're supposed to specify hardware
> arrangements for the upstream Linux, and for all the other low-level
> software that can be booted on hardware too (such as barebox and
> u-boot bootloaders). This said, whatever can't be expressed as a set
> of properties should still be mentioned in the comments so that
> whoever is dealing with this hardware has extensive information.
> 

Well, I do not think we are using DTS files like this so far. Normally, what's in board.d files is not added to DT "again".

> > > +&eth0 {
> > > +	status = "okay";
> > > +
> > > +	/* ethernet MAC is stored in nvram */
> >
> > Remove those comments. You are setting up stuff in 02_network, which
> > are relatively standard, so I think extra comments are not
> > necessary.
> 
> E.g. when (if at all ever) the kernel gains support for parsing nvram
> partition, this comment will be changed to a proper DT property. But
> it doesn't mean that a person looking at this file before that happens
> should need to consult OpenWrt sources to understand how to deal with
> this board properly.

To make it really useful, you would at least have to add the "location" in nvram to the comment, too. With your current solution, you'd still have to look into 02_network to find out about that.

And if you then really followed that strategy, you would also have to add comments for netdev/switch triggers, the caldata, etc.

Anyway, my opposition is not strong enough to reject this right now, maybe someone else can provide an additional opinion on the subject.

Best

Adrian

> 
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercerpav@gmail.com
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Paul Fertser Nov. 11, 2019, 1:08 p.m. UTC | #6 
On Mon, Nov 11, 2019 at 01:53:10PM +0100, Adrian Schmutzler wrote:
> > I've made specific effort to flash vendor firmware and confirmed by
> > testing on hardware that the vendor firmware doesn't need those
> > partitions. Isn't that enough? What important aspects did I not check?
> 
> I haven't been able to extract that precise information from your
> previous comments (I don't want to blame you for that, maybe I just
> overlooked it ...).
> 
> If stock firmware works without those partitions, removing them is
> fine for me. Please explicitly state in your commit message (after
> telling about the removal) that you tested successfully on vendor
> firmware. :-)

Funny thing but it's exactly the commit message for my v2 where I
tried to express it. For the next version I'll try to make it more
clear. The vendor firmware was split out of a full flash dump I found
on the net (I copied the whole original "firmware" partition with "mtd
write").
Paul Fertser Dec. 7, 2019, 2:04 p.m. UTC | #7 
Hello dear maintainer,

You changed the status of the patch to "Changes requested" but you
haven't expressed your opinion on the topics raised during the
discussion. Please do so that I can make the changes to your liking.
Petr Štetiar Dec. 7, 2019, 3:04 p.m. UTC | #8 
Paul Fertser <fercerpav@gmail.com> [2019-12-07 17:04:06]:

Hi,

> You changed the status of the patch to "Changes requested" but you

I've marked it as such, because of that discussion[1], but I admit, that I
didn't read it thoroughly.

1. https://patchwork.ozlabs.org/patch/1192429/

-- ynezz
Paul Fertser Dec. 7, 2019, 8:10 p.m. UTC | #9 
Hi Petr,

On Sat, Dec 07, 2019 at 04:04:13PM +0100, Petr Štetiar wrote:
> > You changed the status of the patch to "Changes requested" but you
> 
> I've marked it as such, because of that discussion[1], but I admit, that I
> didn't read it thoroughly.

One thing I find a bit annoying about Patchwork is that state changes
are anonymous and so a committer might get an odd feeling when
something like that happens.

Regarding this specific patch, I'd really like to hear the opinion of
a maintainer (it seems like ath79 doesn't have an official maintainer
yet) as there're some issues raised in the discussion for which
there's still no clear answer. I'll be happy to change the patch in
any way that will get it accepted.
Petr Štetiar Dec. 7, 2019, 8:58 p.m. UTC | #10 
Paul Fertser <fercerpav@gmail.com> [2019-12-07 23:10:11]:

> Regarding this specific patch, I'd really like to hear the opinion of
> a maintainer (it seems like ath79 doesn't have an official maintainer

To me it seems like its maintained by a community, by developers like you,
with the little help of team members like Adrian having necessary commit
rights.

> I'll be happy to change the patch in any way that will get it accepted.

Then just do the requested changes in v3, solved.

-- ynezz
Paul Fertser Dec. 7, 2019, 9:11 p.m. UTC | #11 
On Sat, Dec 07, 2019 at 09:58:26PM +0100, Petr Štetiar wrote:
> > I'll be happy to change the patch in any way that will get it accepted.
> 
> Then just do the requested changes in v3, solved.

I got an impression Adrian is not sure anymore he's requesting all the
changes we talked about, as I provided some reasonable
counter-arguments and that he is waiting for someone else to chime
in. If you tell me I should just do whatever Adrian says, ok, np. Do I
get it right?
Adrian Schmutzler Dec. 7, 2019, 10:11 p.m. UTC | #12 
Well, address the issues we have agreed on in a v3.

From my scanning of the open discussion points, the following was unresolved in some way:
1. Name prefix for LED labels
In ar71xx, all devices use "d-link". In ath79, so far two devices use "d-link" and four devices use the device name.
Since d-link looks like a vendor where heavy use of DTSI files is possible, I would use "d-link" as prefix for those.

2. Comments for ethX nodes in DTS files: I would remove the comments. It wouldn't be a big problem if you keep them for v3, though.

3. Partitioning: Remove the commented partitions and provide an extensive explanation in the commit message.

Further discussion may be led based on a v3 patch then.

Best

Adrian

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org]
> On Behalf Of Paul Fertser
> Sent: Samstag, 7. Dezember 2019 22:11
> To: Petr Štetiar <ynezz@true.cz>
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH v2] ath79: add D-Link DIR-615 E4
> 
> On Sat, Dec 07, 2019 at 09:58:26PM +0100, Petr Štetiar wrote:
> > > I'll be happy to change the patch in any way that will get it accepted.
> >
> > Then just do the requested changes in v3, solved.
> 
> I got an impression Adrian is not sure anymore he's requesting all the
> changes we talked about, as I provided some reasonable counter-arguments
> and that he is waiting for someone else to chime in. If you tell me I should
> just do whatever Adrian says, ok, np. Do I get it right?
> 
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercerpav@gmail.com
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Paul Fertser Dec. 7, 2019, 10:21 p.m. UTC | #13 
On Sat, Dec 07, 2019 at 11:11:27PM +0100, mail@adrianschmutzler.de wrote:
> Well, address the issues we have agreed on in a v3.

Sure, will do tomorrow, thanks!
diff mbox series

Patch

diff --git a/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts b/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts
new file mode 100644
index 0000000000..64ee2eb938
--- /dev/null
+++ b/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts
@@ -0,0 +1,188 @@ 
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+#include "ar7240.dtsi"
+
+/ {
+	model = "D-Link DIR-615 E4";
+	compatible = "dlink,dir-615-e4", "qca,ar7240";
+
+	aliases {
+		led-boot = &power_amber;
+		led-failsafe = &power_amber;
+		led-running = &power_green;
+		led-upgrade = &power_amber;
+	};
+
+	keys {
+		compatible = "gpio-keys";
+
+		reset {
+			label = "reset";
+			linux,code = <KEY_RESTART>;
+			gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
+			debounce-interval = <60>;
+		};
+
+		wps {
+			label = "wps";
+			linux,code = <KEY_WPS_BUTTON>;
+			gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
+			debounce-interval = <60>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&switch_led_pins>;
+
+		power_green: power_green {
+			label = "dir-615-e4:green:power";
+			gpios = <&gpio 6 GPIO_ACTIVE_HIGH>;
+		};
+
+		power_amber: power_amber {
+			label = "dir-615-e4:amber:power";
+			gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+		};
+
+		wps {
+			label = "dir-615-e4:blue:wps";
+			gpios = <&gpio 0 GPIO_ACTIVE_LOW>;
+		};
+
+		lan1 {
+			label = "dir-615-e4:green:lan1";
+			gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+		};
+
+		lan2 {
+			label = "dir-615-e4:green:lan2";
+			gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
+		};
+
+		lan3 {
+			label = "dir-615-e4:green:lan3";
+			gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
+		};
+
+		lan4 {
+			label = "dir-615-e4:green:lan4";
+			gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
+		};
+
+		wan_amber {
+			label = "dir-615-e4:amber:wan";
+			gpios = <&gpio 7 GPIO_ACTIVE_HIGH>;
+		};
+
+		wan_green {
+			label = "dir-615-e4:green:wan";
+			gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+		};
+
+		wlan {
+			label = "dir-615-e4:green:wlan";
+			gpios = <&ath9k 1 GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "phy0tpt";
+		};
+	};
+};
+
+&spi {
+	status = "okay";
+	num-cs = <1>;
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <33000000>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			uboot: partition@0 {
+				reg = <0x0 0x30000>;
+				label = "u-boot";
+				read-only;
+			};
+
+			nvram: partition@30000 {
+				reg = <0x30000 0x10000>;
+				label = "nvram";
+				read-only;
+			};
+
+			firmware: partition@40000 {
+				compatible = "denx,uimage";
+				reg = <0x40000 0x3b0000>;
+				label = "firmware";
+			};
+
+			/*
+			These two partitions are defined by CameoAP99 layout
+			but not needed for vendor firmware: MAC address is taken
+			from "nvram", language pack can be flashed separately.
+
+			mac: partition@3b0000 {
+				reg = <0x3b0000 0x10000>;
+				label = "mac";
+				read-only;
+			};
+
+			lp: partition@3c0000 {
+				reg = <0x3c0000 0x30000>;
+				label = "lp";
+				read-only;
+			};
+			*/
+
+			art: partition@3f0000 {
+				reg = <0x3f0000 0x10000>;
+				label = "art";
+				read-only;
+			};
+		};
+	};
+};
+
+&eth0 {
+	status = "okay";
+
+	/* ethernet MAC is stored in nvram */
+};
+
+&eth1 {
+	status = "okay";
+
+	/* ethernet MAC is stored in nvram */
+};
+
+&pcie {
+	status = "okay";
+
+	ath9k: wifi@0,0 {
+		compatible = "pci168c,002b";
+		reg = <0x0000 0 0 0 0>;
+		qca,no-eeprom;
+		/* LAN MAC is supposed to be used for wifi */
+		#gpio-cells = <2>;
+		gpio-controller;
+	};
+};
+
+&pinmux {
+	switch_led_pins: pinmux_switch_led_pins {
+		pinctrl-single,bits = <0x0 0x0 0xf8>;
+	};
+};
+
+&uart {
+	status = "okay";
+};
diff --git a/target/linux/ath79/image/tiny.mk b/target/linux/ath79/image/tiny.mk
index 8f867575af..5f6adeac86 100644
--- a/target/linux/ath79/image/tiny.mk
+++ b/target/linux/ath79/image/tiny.mk
@@ -13,6 +13,22 @@  define Device/buffalo_whr-g301n
 endef
 TARGET_DEVICES += buffalo_whr-g301n
 
+define Device/dlink_dir-615-e4
+  ATH_SOC := ar7240
+  DEVICE_VENDOR := D-Link
+  DEVICE_MODEL := DIR-615
+  DEVICE_VARIANT := E4
+  IMAGE_SIZE := 3776k
+  FACTORY_IMAGE_SIZE := 3456k
+  IMAGES += factory.bin
+  IMAGE/default := append-kernel | append-rootfs | pad-rootfs
+  IMAGE/sysupgrade.bin := $$(IMAGE/default) | append-metadata | check-size $$$$(IMAGE_SIZE)
+  IMAGE/factory.bin := $$(IMAGE/default) | check-size $$$$(FACTORY_IMAGE_SIZE) | \
+    pad-to $$$$(FACTORY_IMAGE_SIZE) | append-string "AP99-AR7240-RT-091105-05"
+  SUPPORTED_DEVICES += dir-615-e4
+endef
+TARGET_DEVICES += dlink_dir-615-e4
+
 define Device/pqi_air-pen
   ATH_SOC := ar9330
   DEVICE_VENDOR := PQI
diff --git a/target/linux/ath79/tiny/base-files/etc/board.d/01_leds b/target/linux/ath79/tiny/base-files/etc/board.d/01_leds
index bb1799c645..29ab7a0473 100755
--- a/target/linux/ath79/tiny/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/tiny/base-files/etc/board.d/01_leds
@@ -8,7 +8,8 @@  board=$(board_name)
 boardname="${board##*,}"
 
 case "$board" in
-buffalo,whr-g301n)
+buffalo,whr-g301n|\
+dlink,dir-615-e4)
 	ucidef_set_led_netdev "wan" "WAN" "$boardname:green:wan" "eth0"
 	ucidef_set_led_switch "lan1" "LAN1" "$boardname:green:lan1" "switch0" "0x02"
 	ucidef_set_led_switch "lan2" "LAN2" "$boardname:green:lan2" "switch0" "0x04"
diff --git a/target/linux/ath79/tiny/base-files/etc/board.d/02_network b/target/linux/ath79/tiny/base-files/etc/board.d/02_network
index 49fccc0b2e..5d0657fa43 100755
--- a/target/linux/ath79/tiny/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/tiny/base-files/etc/board.d/02_network
@@ -35,6 +35,7 @@  ath79_setup_interfaces()
 		ucidef_add_switch "switch0" \
 			"0@eth0" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1"
 		;;
+	dlink,dir-615-e4|\
 	netgear,wnr1000-v2|\
 	netgear,wnr2000-v3|\
 	netgear,wnr612-v2|\
@@ -75,6 +76,11 @@  ath79_setup_macs()
 	local board="$1"
 
 	case "$board" in
+	dlink,dir-615-e4)
+		lan_mac=$(mtd_get_mac_ascii "nvram" "lan_mac")
+		wan_mac=$(mtd_get_mac_ascii "nvram" "wan_mac")
+		label_mac=$wan_mac
+		;;
 	tplink,tl-wr941-v2|\
 	tplink,tl-wr941n-v7-cn)
 		base_mac=$(mtd_get_mac_binary u-boot 0x1fc00)
diff --git a/target/linux/ath79/tiny/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom b/target/linux/ath79/tiny/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
index 3da95cc161..5952a40195 100644
--- a/target/linux/ath79/tiny/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
+++ b/target/linux/ath79/tiny/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
@@ -14,6 +14,10 @@  case "$FIRMWARE" in
 	tplink,tl-wr941-v4)
 		caldata_extract "art" 0x1000 0xeb8
 		;;
+	dlink,dir-615-e4)
+		caldata_extract "art" 0x1000 0x1000
+		ath9k_patch_mac_crc $(mtd_get_mac_ascii "nvram" "lan_mac") 0x10c
+		;;
 	netgear,wnr1000-v2|\
 	netgear,wnr2000-v3|\
 	netgear,wnr612-v2|\