[OpenWrt-Devel] [PATCH] [ramips] add profile for Dlink DIR-615 H1
Hello, this adds the profile for Dlink DIR-615 H1 without the usb default packages since this router does not have a usb port and while all the needed definitions for building are already in target/linux/ramips/image/Makefile this also allows users to select the exact target in RT305x based boards menuconfig for this router and compile its firmware. Signed-off-by: Daniel Petre d...@ip6.ro Index: target/linux/ramips/rt305x/profiles/dlink.mk === --- target/linux/ramips/rt305x/profiles/dlink.mk(revision 0) +++ target/linux/ramips/rt305x/profiles/dlink.mk(revision 0) @@ -0,0 +1,20 @@ +# +# Copyright (C) 2013 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/DIR615H1 + NAME:=Dlink DIR-615 H1 +PACKAGES:=\ +-kmod-usb-core -kmod-usb-rt305x-dwc_otg \ +-kmod-ledtrig-usbdev +endef + +define Profile/DIR615H1/Description + Package set for Dlink DIR-615 H1 board +endef + +$(eval $(call Profile,DIR615H1)) + ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how to enable openssl hardware encryption engine ?
Is there anything else that should be done to get padlock working? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ramips] fix Dlink DIR-615 D network detection
Hello, Currently target/linux/ramips/base-files/lib/preinit/06_set_iface_mac doesn't set properly for dir-615 d devices. Some people in the forum previously provided some patches regarding to this problem, but has not applied here somehow: https://forum.openwrt.org/viewtopic.php?pid=189309#p189309 Thanks Signed-off-by: Gavin Ni gis...@gmail.com Index: target/linux/ramips/base-files/lib/preinit/06_set_iface_mac === --- target/linux/ramips/base-files/lib/preinit/06_set_iface_mac (revision 36213) +++ target/linux/ramips/base-files/lib/preinit/06_set_iface_mac (working copy) @@ -35,7 +35,8 @@ ;; dir-300-b1 |\ dir-300-b2 |\ - dir-600-b1) + dir-600-b1 |\ + dir-615-d) mac=$(mtd_get_mac_binary devdata 16388) ifconfig eth0 hw ether $mac 2/dev/null ;; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: Allow talitos crypto hw module selection
2013.03.28. 10:12 keltezéssel, Helmut Schaa írta: Signed-off-by: Helmut Schaa helmut.sc...@googlemail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] E4200 and broadcom 47xx soc
On 04/06/2013 04:36 AM, Chirag Chhatriwala wrote: On Thu, Mar 28, 2013 at 9:00 PM, Hauke Mehrtens ha...@hauke-m.de mailto:ha...@hauke-m.de wrote: On 03/29/2013 01:47 AM, Chirag Chhatriwala wrote: On Thu, Mar 28, 2013 at 7:19 PM, Hauke Mehrtens ha...@hauke-m.de mailto:ha...@hauke-m.de mailto:ha...@hauke-m.de mailto:ha...@hauke-m.de wrote: You need the bgmac Ethernet driver and wifi should be supported by b43, brcmsmac or wl. The 5GHz wifi will not work in 5GHz mode and it could work in 2.4 GHZ mode with b43. Select a profile with all Ethernet or bgmac Ethernet. Hauke Strange, I thought the 5GHz wifi would work with broadcom-wl driver as it is expected. Am I missing something? No, broacom-wl only supports old wifi devices and no new cores released in the last ~4 years. The 5GHz wifi supports 450MBit/s so it is a BCM4331 with a HT-Phy and this is only supported by b43 with ieee80211g rates and in the 2.4 GHz band. This wifi will probably not work at all because it was not designed and programmed to be used in the 2.4GHz band. The 2.4GHz wifi of the BCM4718 should work with b43, brcmsmac or broadcom-wl. Hauke Okay I get that. So basically on the E4200 I will have Ethernet (as a result of bgmac), WiFi only on the SoC (BCM4718A1 integrated WiFi) , 2.4 GHz WiFi on the BCM4331 (through b43 or wl) but not 5 GHz ? So what I understand is full 450 Mbps 5 Ghz WiFi support is still lacking for (newer) broadcom based hardware. That is quite a bummer. The BCM4331 is only supported by b43 not wl. If the BCM4718A1 has the same wifi core as the BCM4718 it will work with b43, brcmsmac or wl. Yes support for newer Broadcom based wifi chips is very poor. That has me questioning is there any OpenWrt roadmap on supporting the broadcom based 5 Ghz chips? I am currently working on getting AP mode in brcmsmac working in 5GHz mode but this is just for devices supported by brcmsmac. The problem is that Broadcom does not support OpenWrt in any way and we are not even allowed to update broadcom-wl to a more recent version, because the contract some has with Broadcom does not allow him to do this Also, the new hardware (based on BCM4706) will support Ethernet (due to bgmac) but the WiFi is still a question mark. Also, the BCM4706 boards are not WiSoCs from what I understand (no integrated wifi). Its BCM4360/BCM4331 (RTN66U) and BCM4360/BCM4331 (EA4500). Any plans of making the drivers more current/up-to-date now that 802.11an+ac hardware is gaining momentum. No one I know of is working on the Broadcom ac-phy, your best changes are that we somehow get a more recent broadcom-wl version or Broadcom adds support for this phy to brcmsmac. If you want a router with good OpenWrt support choose one Atheros based device. PS. My CP2102 USB to UART is blown and I'm waiting to receive another one. Do I just connect the TX, RX and GND? And the TX (on router) connects to RX (on UART module) and vice versa or is it simple TX to TX and RX to RX? We're still talking about the E4200. Thanks. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Question on conffiles define / nodogsplash
On 04/06/2013 02:55 PM, Saverio Proto wrote: Hello, I have a personal version of nodogsplash OpenWRT package and I noticed today I was missing this patch from the main tree: https://github.com/ninuxorg/ninux-openwrt-packages/commit/92f90fae6ef6e29f789c2c7a539c4a3efb31b70d when I added this: define Package/nodogsplash/conffiles /etc/nodogsplash/nodogsplash.conf endef did I made my system smarter so that the file /etc/nodogsplash/nodogsplash.conf is saved automatically when I do sysupgrade ? Yes, your guess is correct; it works like that. that ends up adding a file to the final package /lib/upgrade/keep.d/nodogsplash which makes sysupgrade save /etc/nodogsplash/nodogsplash.conf before reflashing cheers! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] 802.11ac list of hardware devices
Hi, there is a really nice list of 802.11ac hardware: http://wikidevi.com/wiki/List_of_802.11ac_Hardware After searching through openwrt devel mailing list, forums and wiki my conculsion is that none of this hardware is supported in openwrt, right? OpenWrt devel team is not developing wifi drivers, you just intergrate them from upstream kernel team when they become available, right? Please correct me if I'm wrong. I know that broadcom support sucks, but what is happeing with atheros? How far is atheros 802.11ac chips support in upstream kernel? Cheers, Valent. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how to enable openssl hardware encryption engine ?
I meant lack of hardware support for engine padlock. I should read my mail first before I send it. Dne 6.4.2013 17:32, Jiri Slachta napsal(a): Hello Valent, I am sorry for late response. I am unable to locate the problem between engine and openssl engine due to lack of hardware I use. I'd suggest at first try stracing to use gdb to debug and locate, what openssl needs to run with engine libraries. I am not that experienced in debugging with gdb, so I can't give you a hand in this. :-( If you can paste your log to pastebin and provide links to it, I am sure that someone will take a look at it (at least I will). Jiri Dne 6.4.2013 10:13, valent.turko...@gmail.com napsal(a): Is there anything else that should be done to get padlock working? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.11ac list of hardware devices
2013/4/6 valent.turko...@gmail.com valent.turko...@gmail.com: there is a really nice list of 802.11ac hardware: http://wikidevi.com/wiki/List_of_802.11ac_Hardware After searching through openwrt devel mailing list, forums and wiki my conculsion is that none of this hardware is supported in openwrt, right? OpenWrt devel team is not developing wifi drivers, you just intergrate them from upstream kernel team when they become available, right? Please correct me if I'm wrong. I know that broadcom support sucks, but what is happeing with atheros? How far is atheros 802.11ac chips support in upstream kernel? OpenWrt is community of various ppl, some develop drivers, some just work on integrating everything. I'm developer of Broadcom hardware drivers and I mostly focus on mainlining stuff. But I track OpenWrt development as well. I could *start* working on Broadcom 802.11ac devices, but noone so far decided to donate any of them to the OpenWrt (or me), and they are quite expensive so far. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ramips] Update ARC Freestation profile
Update ARC Freestation profile.
These devices are actually built around the 8devices Carambola dev board.
ARC FreeStation, Flex mARC, iFlex, and SplitStation devices are
supported with this image, see ARCFlex Firmware Downloads:
http://www.antennas.com/wiki/index.php?title=ARC-OS_Firmware_Downloads_and_Revision_History
Funnily enough if present the external USB wlan ends up being wlan-0, with the
SoC device being wlan-1.
- Invert port map so special handling of vlan config can be removed.
- Add LED config similar to original ArcOS firmware.
* Freestation5 reportedly only has the PoE toggle, but some of the other
devices may have the three LEDs.
- Get MACs from factory partition.
- Update description to list supported devices.
- Carambola uses RT3050 (not RT3052), though my Carambola CPU
actually reports itself as being an RT3350 while still having
RT3050F markings.
Signed-off-by: Tobias Diedrich ranma+open...@tdiedrich.de
Index:
openwrt-ralink-swconfig/target/linux/ramips/base-files/etc/uci-defaults/02_network
===
---
openwrt-ralink-swconfig.orig/target/linux/ramips/base-files/etc/uci-defaults/02_network
2013-04-06 17:50:58.079146022 +0200
+++
openwrt-ralink-swconfig/target/linux/ramips/base-files/etc/uci-defaults/02_network
2013-04-06 17:50:58.069146008 +0200
@@ -142,7 +142,6 @@
ucidef_add_switch_vlan switch0 2 0t 5
;;
- freestation5 | \
wcr-150gn)
ucidef_set_interfaces_lan_wan eth0.2 eth0.1
;;
@@ -263,6 +262,7 @@
all0239-3g | \
carambola | \
+ freestation5 | \
w502u | \
wnce2001)
lan_mac=$(mtd_get_mac_binary factory 40)
Index:
openwrt-ralink-swconfig/target/linux/ramips/rt305x/profiles/freestation5.mk
===
---
openwrt-ralink-swconfig.orig/target/linux/ramips/rt305x/profiles/freestation5.mk
2013-04-06 17:50:58.079146022 +0200
+++ openwrt-ralink-swconfig/target/linux/ramips/rt305x/profiles/freestation5.mk
2013-04-06 18:40:47.923321965 +0200
@@ -12,7 +12,7 @@
endef
define Profile/FREESTATION5/Description
- Package set for ARC Flex FreeStation5
+ Package set for ARC FreeStation, Flex mARC, iFlex, and SplitStation
endef
$(eval $(call Profile,FREESTATION5))
Index: openwrt-ralink-swconfig/target/linux/ramips/dts/FREESTATION5.dts
===
--- openwrt-ralink-swconfig.orig/target/linux/ramips/dts/FREESTATION5.dts
2013-04-06 17:50:58.079146022 +0200
+++ openwrt-ralink-swconfig/target/linux/ramips/dts/FREESTATION5.dts
2013-04-06 18:31:09.302513800 +0200
@@ -5,7 +5,7 @@
/ {
#address-cells = 1;
#size-cells = 1;
- compatible = FREESTATION5, ralink,rt3052-soc;
+ compatible = FREESTATION5, ralink,rt3050-soc;
model = ARC FreeStation5;
memorydetect {
@@ -16,6 +16,18 @@
bootargs = console=ttyS0,115200
mtdparts=1f00.cfi:192k(u-boot)ro,64k(u-boot-env)ro,64k(factory)ro,7872k@0x5(firmware);
};
+ palmbus@1000 {
+ sysc@0 {
+ ralink,pinmux = i2c, spi, uartlite, jtag,
mdio, sdram, rgmii;
+ ralink,uartmux = gpio;
+ ralink,wdtmux = 1;
+ };
+
+ gpio0: gpio@600 {
+ status = okay;
+ };
+ };
+
cfi@1f00 {
compatible = cfi-flash;
reg = 0x1f00 0x80;
@@ -32,7 +44,7 @@
esw@1011 {
status = okay;
- ralink,portmap = 0x3e;
+ ralink,portmap = 0x01;
};
wmac@1018 {
@@ -42,4 +54,28 @@
otg@101c {
status = okay;
};
+
+ gpio-leds {
+ compatible = gpio-leds;
+ // Used to enable power-over-ethernet passthrough from port0 to
port1.
+ // Disable passthrough by default to prevent accidental
equipment damage.
+ poe {
+ label = freestation:poe:passthrough;
+ gpios = gpio0 11 1;
+ };
+ // The following leds are defined in the ArcOS firmware, but
reportedly
+ // not present in the Freestation5 device.
+ wifi {
+ label = freestation:unknown:wifi;
+ gpios = gpio0 7 1;
+ };
+ powerg {
+ label = freestation:unknown:powerg;
+ gpios = gpio0 9 1;
+ };
+ usb {
+ label = freestation:unknown:usb;
+ gpios = gpio0 14 1;
+ };
+ };
};
--
Tobias PGP: http://8ef7ddba.uguu.de
Re: [OpenWrt-Devel] 802.11ac list of hardware devices
valent.turko...@gmail.com wrote: I know that broadcom support sucks, but what is happeing with atheros? How far is atheros 802.11ac chips support in upstream kernel? A new driver ath10k is being developed and will be submitted for inclusion in the kernel. Hopefully soon. Sujith ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ramips] Update ARC Freestation profile
On 06/04/13 18:47, Tobias Diedrich wrote:
+
+ gpio-leds {
+ compatible = gpio-leds;
+ // Used to enable power-over-ethernet passthrough from port0 to
port1.
+ // Disable passthrough by default to prevent accidental
equipment damage.
+ poe {
+ label = freestation:poe:passthrough;
+ gpios =gpio0 11 1;
+ };
+ // The following leds are defined in the ArcOS firmware, but
reportedly
+ // not present in the Freestation5 device.
Hi,
this should be done with an of_gpio_export node
-
https://dev.openwrt.org/browser/trunk/target/linux/ramips/dts/DIR-645.dts#L134
John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ramips] Update ARC Freestation profile
John Crispin wrote:
On 06/04/13 18:47, Tobias Diedrich wrote:
+
+gpio-leds {
+compatible = gpio-leds;
+// Used to enable power-over-ethernet passthrough from port0 to
port1.
+// Disable passthrough by default to prevent accidental
equipment damage.
+poe {
+label = freestation:poe:passthrough;
+gpios =gpio0 11 1;
+};
+// The following leds are defined in the ArcOS firmware, but
reportedly
+// not present in the Freestation5 device.
Hi,
this should be done with an of_gpio_export node
-
https://dev.openwrt.org/browser/trunk/target/linux/ramips/dts/DIR-645.dts#L134
Hmm, annoyingly that does not seem to allow setting defaults values
other than direction.
But I'd like to set it to active_low and off by default.
--
Tobias PGP: http://8ef7ddba.uguu.de
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ramips] Update ARC Freestation profile
On 07/04/13 00:39, Tobias Diedrich wrote:
John Crispin wrote:
On 06/04/13 18:47, Tobias Diedrich wrote:
+
+ gpio-leds {
+ compatible = gpio-leds;
+ // Used to enable power-over-ethernet passthrough from port0 to
port1.
+ // Disable passthrough by default to prevent accidental
equipment damage.
+ poe {
+ label = freestation:poe:passthrough;
+ gpios =gpio0 11 1;
+ };
+ // The following leds are defined in the ArcOS firmware, but
reportedly
+ // not present in the Freestation5 device.
Hi,
this should be done with an of_gpio_export node
-
https://dev.openwrt.org/browser/trunk/target/linux/ramips/dts/DIR-645.dts#L134
Hmm, annoyingly that does not seem to allow setting defaults values
other than direction.
But I'd like to set it to active_low and off by default.
gpio-export,output = 0;
... the parameter is the default output value
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/5][mips16] Minimal patches for userspace mips16
On Apr 5, 2013, at 8:47 AM, Florian Fainelli wrote:
I would be grateful if you could also test with vanilla GCC 4.6, 4.7 and 4.8
and 4.7-linaro whether we need the GCC patch you provided?
We need something for each, but the file I'm patching doesn't exist in some
other versions. I'm going to try to get a patch that works against all those
flavors. The MIPS SDE config (gcc/config/mips/sde.h) already encountered the
mixed .init problem and patched a different way. I think I'm going to steal it
and put it in config/mips/linux.h.
===
/* Force all .init and .fini entries to be 32-bit, not mips16, so that
in a mixed environment they are all the same mode. The crti.asm and
crtn.asm files will also be compiled as 32-bit due to the
-no-mips16 flag in SUBTARGET_ASM_SPEC above. */
#undef CRT_CALL_STATIC_FUNCTION
#define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC) \
===
And they implemented the nobody does .S files in mips16 mode in the compiler
driver rather than in TARGET_ASFLAGS.
===
[...] Force -no-mips16,
so that MIPS16 assembler code requires an explicit .set mips16.
Very little hand-written MIPS16 assembler exists, and some build
systems expect code to be assembled as non-MIPS16 even if the
prevailing compiler flags select -mips16. */
#undef SUBTARGET_ASM_SPEC
#define SUBTARGET_ASM_SPEC \
%{!mips1:--trap} \
%{mips16:-no-mips16}
===
I am inclined to believe SDE when they talk about what is and is not common on
MIPS. I'll take the mips16 part of that #define. Then we can (but don't have
to) revert the openwrt TARGET_ASFLAGS fix.
By the way the problem a GCC patch is fixing is:
00400e18 _init:
400e18: 3c1c0002lui gp,0x2
400e1c: 279ca648addiu gp,gp,-22968
400e20: 0399e021addugp,gp,t9
400e24: 27bdffe0addiu sp,sp,-32
400e28: afbc0010sw gp,16(sp)
400e2c: afbf001csw ra,28(sp)
400e30: afbc0018sw gp,24(sp)
**400e34: 04171a000x4171a00
**400e38: 1a006500blezs0,41a23c _end+0x6c7c
**400e3c: 65000b440x65000b44
400e40: 8fbf001clw ra,28(sp)
400e44: 03e8jr ra
400e48: 27bd0020addiu sp,sp,32
If you disassemble that in mips16 mode, those three words are:
400e34: 1a00 0417 jal 40105c frame_dummy
400e38: 6500nop
400e3a: 1a00 0b44 jal 402d10 __do_global_ctors_aux
400e3e: 6500nop
Jay
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ramips] Update ARC Freestation profile
John Crispin wrote:
On 06/04/13 18:47, Tobias Diedrich wrote:
+
+gpio-leds {
+compatible = gpio-leds;
+// Used to enable power-over-ethernet passthrough from port0 to
port1.
+// Disable passthrough by default to prevent accidental
equipment damage.
+poe {
+label = freestation:poe:passthrough;
+gpios =gpio0 11 1;
+};
+// The following leds are defined in the ArcOS firmware, but
reportedly
+// not present in the Freestation5 device.
Hi,
this should be done with an of_gpio_export node
-
https://dev.openwrt.org/browser/trunk/target/linux/ramips/dts/DIR-645.dts#L134
There's a bug in the gpio-export code. :)
But I'm rewriting it to use the following syntax:
gpio-export,name = mario;
gpio-export,flags = out_init_high, active_low, changeable;
gpio-export,gpios = gpio0 11 1;
Which will support the following flags (had to add GPIOF_ACTIVE_LOW):
static struct of_gpio_flag of_gpio_flags[] = {
{ in, GPIOF_DIR_IN },
{ out_init_low, GPIOF_OUT_INIT_LOW },
{ out_init_high, GPIOF_OUT_INIT_HIGH },
{ open_drain, GPIOF_OPEN_DRAIN },
{ open_source, GPIOF_OPEN_SOURCE },
{ active_low, GPIOF_ACTIVE_LOW },
{ changeable, GPIOF_EXPORT_CHANGEABLE },
{ /* sentinel */ }
};
--
Tobias PGP: http://8ef7ddba.uguu.de
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ramips] Update ARC Freestation profile
Tobias Diedrich wrote:
John Crispin wrote:
On 06/04/13 18:47, Tobias Diedrich wrote:
+
+ gpio-leds {
+ compatible = gpio-leds;
+ // Used to enable power-over-ethernet passthrough from port0 to
port1.
+ // Disable passthrough by default to prevent accidental
equipment damage.
+ poe {
+ label = freestation:poe:passthrough;
+ gpios =gpio0 11 1;
+ };
+ // The following leds are defined in the ArcOS firmware, but
reportedly
+ // not present in the Freestation5 device.
Hi,
this should be done with an of_gpio_export node
-
https://dev.openwrt.org/browser/trunk/target/linux/ramips/dts/DIR-645.dts#L134
There's a bug in the gpio-export code. :)
But I'm rewriting it to use the following syntax:
gpio-export,name = mario;
gpio-export,flags = out_init_high, active_low, changeable;
gpio-export,gpios = gpio0 11 1;
Which will support the following flags (had to add GPIOF_ACTIVE_LOW):
static struct of_gpio_flag of_gpio_flags[] = {
{ in, GPIOF_DIR_IN },
{ out_init_low, GPIOF_OUT_INIT_LOW },
{ out_init_high, GPIOF_OUT_INIT_HIGH },
{ open_drain, GPIOF_OPEN_DRAIN },
{ open_source, GPIOF_OPEN_SOURCE },
{ active_low, GPIOF_ACTIVE_LOW },
{ changeable, GPIOF_EXPORT_CHANGEABLE },
{ /* sentinel */ }
};
Something like this (WIP).
Also has a few consistency-changes:
- Changed gpio_export - gpio-export for consistency with gpio-leds friends.
- Changed gpio-export,name - label for consistency
---
a/target/linux/ramips/patches-3.8/0209-owrt-GPIO-add-gpio_export_with_name.patch
+++
b/target/linux/ramips/patches-3.8/0209-owrt-GPIO-add-gpio_export_with_name.patch
@@ -91,7 +91,7 @@ Signed-off-by: John Crispin blogic@open
/* Private data structure for of_gpiochip_find_and_xlate */
struct gg_data {
-@@ -289,3 +291,62 @@ void of_gpiochip_remove(struct gpio_chip
+@@ -289,3 +291,103 @@ void of_gpiochip_remove(struct gpio_chip
if (chip-of_node)
of_node_put(chip-of_node);
}
@@ -101,6 +101,32 @@ Signed-off-by: John Crispin blogic@open
+ { /* sentinel */ }
+};
+
++/* Private data structure for of_gpio_flag_value */
++struct of_gpio_flag {
++ const char *name;
++ unsigned value;
++};
++
++static struct of_gpio_flag of_gpio_flags[] = {
++ { in, GPIOF_DIR_IN },
++ { out_init_low, GPIOF_OUT_INIT_LOW },
++ { out_init_high, GPIOF_OUT_INIT_HIGH },
++ { open_drain, GPIOF_OPEN_DRAIN },
++ { open_source, GPIOF_OPEN_SOURCE },
++ { active_low, GPIOF_ACTIVE_LOW },
++ { changeable, GPIOF_EXPORT_CHANGEABLE },
++ { /* sentinel */ }
++};
++
++static unsigned __init of_gpio_flag_value(const char *name, struct
of_gpio_flag *flags)
++{
++ for (; flags-name; flags++)
++ if (!strcmp(flags-name, name))
++ return flags-value;
++
++ return 0;
++}
++
+static int __init of_gpio_export_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
@@ -111,27 +137,42 @@ Signed-off-by: John Crispin blogic@open
+ for_each_child_of_node(np, cnp) {
+ const char *name = NULL;
+ int gpio;
-+ bool dmc;
+ int max_gpio = 1;
+ int i;
+
-+ of_property_read_string(cnp, gpio-export,name, name);
++ of_property_read_string(cnp, label, name);
+
+ if (!name)
+ max_gpio = of_gpio_count(cnp);
+
+ for (i = 0; i max_gpio; i++) {
++ unsigned flags = GPIOF_EXPORT;
++ struct property *prop;
++ const char *flag;
++
+ gpio = of_get_gpio(cnp, i);
-+ if (devm_gpio_request(pdev-dev, gpio, name ? name :
of_node_full_name(np)))
-+ continue;
+
-+ if (!of_property_read_u32(cnp, gpio-export,output,
val))
-+ gpio_direction_output(gpio, val);
-+ else
-+ gpio_direction_input(gpio);
++ /* Only use output/direction_may_change if flags isn't
used. */
++ if (!of_find_property(cnp, gpio-export,flags, NULL)) {
++ if (!of_property_read_u32(cnp,
gpio-export,output, val)) {
++ if (val)
++ flags |= GPIOF_OUT_INIT_HIGH;
++ else
++ flags |= GPIOF_OUT_INIT_LOW;
++ } else {
++ flags |= GPIOF_DIR_IN;
++ }
++
++ if (of_property_read_bool(cnp,
gpio-export,direction_may_change))
++
