ath79: update DTS for TP-Link WDR3600/WDR4300 v1

[adschm]

This updates gpio-export to gpio-hogs and switches to interrupt-driven gpio-keys.

Solved usb power with gpio-hogs.
It looks like this is the first case where two reg_usb_vbus with different gpios are required for two ports.
I need some help with the setup for those. (Just check what's there already)

[kofec]

I will have a question fot this topic. After all latest changes regarding GPIO. Is it possible to mange power on this device - WDR3600/WDR4300 v1
on older releases it was done by:

    # echo 0 > /sys/class/gpio/gpio21/value
    # echo 0 > /sys/class/gpio/gpio22/value

[adschm]

@kofec I can try on my device one the correct setup is sorted out.

[adschm]

Tried different variants, but I only get USB2 working, USB1 is dead. With gpio-export everything works as expected. Any ideas?

[jneuhauser]

I´ve added the following nodes only to get the default trigger for the leds working...

port@1 {
	...
	hub_port1: port@1 {
		...
	};

	hub_port2: port@2 {
		...
	};
};

The driver does not handle this nodes as the usb ports are working also without the nodes above.
I think you have to add your both vbus-supply definitions as properties to the usb node.

EDIT: I personally prefer the solution with gpio-export

[adschm]

@jneuhauser

I've already tried with

&usb {
	[...]
	vbus-supply = <&reg_usb_vbus1 &reg_usb_vbus2>;
	[...]
};

Same situation.

But this sounds like I should try to get rid of the nested nodes?

[981213]

vbus-supply only works for SoCs using chipidea driver. ar934x uses generic ehci platform driver if I remember correctly.
I used fixed regulator for Qihoo C301 but I only setup an always-on fixed regulator without binding it to USB node.

[jeffsf]

gpio-hog is also functional for this, as well as “clean” in the DTS.

I keep hoping to find a way to “bounce” the power, but I haven’t seen any way to control a fixed-regulator through sysfs or the like.

[adschm]

Okay, so I will give it a try with gpio-hog as in:

openwrt/target/linux/ramips/dts/mt7620a_edimax_ew-7478apc.dts

Line 65 in 447deed

enable_usb_power {

[adschm]

Thanks for your pointers.
I updated the commit and tested successfully on WDR4300.

[adschm]

Coming back to the question raised by @kofec:

Can I manage USB power set via gpio-hogs on the running device?

[adschm]

This PR might be obsoleted by:
https://patchwork.ozlabs.org/patch/1141057/
https://patchwork.ozlabs.org/patch/1141233/

[adschm]

Update:

• Improved node names
• Use GPIO_ACTIVE_HIGH consistently

[adschm]

@blocktrron
Maybe have a look at this? It is simple and tested, and I would like it merged, since #2298 depends on it.

[Leo-PL]

For me, LGTM, except that I'd split the gpio-keys part and gpio-hogs part as separate commits, they are logically separate changes.

[blocktrron]

Thanks! Merged to my staging tree: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=summary

@adrianschmutzler If you want to reach out specifically to me, E-Mail is the best way, as GitHub gives me notifications about everything in the Organization, independent whether I'm mentioned or not.

[Leo-PL]

@adrianschmutzler coming back to the topic of controlling devices via userspace, have you managed to perform this?

If it's no longer possible with GPIO hogs, then it's a regression, which affects my devices, as I use USB power switch to restart LTE modem.

[adschm]

There has been a discussion on the same subject on the devel list:
https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg49204.html

Since there have been two requests, I would be willing to "revert" usb power to gpio-export for this device if one of you provides a proper patch.

[Leo-PL]

I'll provide a patch in coming days.
Also, regarding "for this device": I think this is a regression for all USB-capable devices which had a GPIO export previously, including but not limited to TL-WR1043ND, TL-WR703N and others, to name a few that I do own. I believe that until a better solution can be found, the change to GPIO hogs for USB power shall be reverted for all capable devices.

[adschm]

@Leo-PL Well, have a look at the discussion. You may try your luck with reverting everything.
If you do that, please send to patch to the list instead of opening a PR here.