Re: [OpenWrt-Devel] [PATCH v2] mac80211: enable support for RaLink Rt53xx USB devices in rt2800usb

[Gabor Juhos]

2011.12.25. 17:16 keltezéssel, Daniel Golle írta:
> Hi!
> 
> On Mon, Nov 14, 2011 at 03:01:34PM +0100, Daniel Golle wrote:
>> The driver works quite nice and stable for me using a RaLink Rt5370 USB
>> device.
>> 
>> Signed-off-by: Daniel Golle 
>> 
>> Index: package/mac80211/Makefile 
>> === ---
>> package/mac80211/Makefile(revision 29114) +++ package/mac80211/Makefile
>> (working copy) @@ -1147,6 +1147,7 @@ CONFIG_RT2800_LIB=$(if
>> $(CONFIG_PACKAGE_kmod-rt2800-lib),m) \ CONFIG_RT2800PCI=$(if
>> $(CONFIG_PACKAGE_kmod-rt2800-pci),m) \ CONFIG_RT2800USB=$(if
>> $(CONFIG_PACKAGE_kmod-rt2800-usb),m) \ + CONFIG_RT2800USB_RT53XX=$(if
>> $(CONFIG_PACKAGE_kmod-rt2800-usb),y) \ CONFIG_RTL8180=$(if
>> $(CONFIG_PACKAGE_kmod-rtl8180),m) \ CONFIG_RTL8187=$(if
>> $(CONFIG_PACKAGE_kmod-rtl8187),m) \ CONFIG_RTL8192CE= \
> 
> Aparently this was wrong, CONFIG_RT2800USB_RT53XX is supposed to live in 
> BUILDARGS rather than MAKE_OPTS to actually get support for the Rt5370. 
> Thanks to actmnophn for the hint!
> 
> This reverts changeset 29116 and adds it to the right section in the
> Makefile.
> 
> Signed-off-by: Daniel Golle 

Applied.

Thanks,
Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] ar71xx: TL-MR3020: fix board detection, fix missing mandatory package and modify LED behaviour

[Gabor Juhos]

2012.01.24. 19:41 keltezéssel, Christian Cier-Zniewski írta:
> This patch fixes the board detection of the TL-MR3020.
> The string *TL-MR3020 was searched which is wrong.
> Now the correct string *"TL-MR3020 v1" is searched for.
> The board name has also been modified from tl-mr3020 to tl-mr3020-v1 to 
> reflect
> the correction revision.
> All strings have been updated in the other files which rely on the board name.
> 
> The LED behaviour has also been modified:
> * The WPS LED is the diag LED now.
> * A netdev trigger for the LAN LED has been added.
> 
> The profile of the TL-MR3020 has been updated because the needed package
> "kmod-ledtrig-usbdev" was missing which resulted in a non-working usbdev 
> trigger
> for the 3G/USB LED.
> 
> Signed-off-by: Christian Cier-Zniewski 

Aplied with some chages.

Thanks,
Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: TL-MR3020: fix GPIO polarity for button and switch

[Gabor Juhos]

2012.01.24. 19:31 keltezéssel, Christian Cier-Zniewski írta:
> This patch fixes the GPIO polarity for the button and the sliding switch. The
> buttons are not active low. "Pressed" and "Released" events are wrong without
> the patch.
> 
> Signed-off-by: Christian Cier-Zniewski 

Applied.

Thanks,
Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Compiling WNDR3700 with 3.2 kernel?

[Gabor Juhos]

2012.01.25. 8:19 keltezéssel, Andrew Silverman írta:
> I'm sure this is obvious to most, but not to me- I'd like to try out the new
> trunk builds with the 3.2 kernel, but it's not clear to me how to configure
> the build to start using that version even though I've grabbed the recent svn
> updates- it continues to build the 2.6.39.4 kernel.

3.2 is not enabled by default.

> Any quick instructions where this can be configured would be appreciated.

 Change the LINUX_VERSION variable from '2.6.39.4' to '3.2.1' in
'target/linux/ar71xx/Makefile'.

-Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Compiling WNDR3700 with 3.2 kernel?

[Andrew Silverman]

I'm sure this is obvious to most, but not to me- I'd like to try out the new 
trunk builds with the 3.2 kernel, but it's not clear to me how to configure the 
build to start using that version even though I've grabbed the recent svn 
updates- it continues to build the 2.6.39.4 kernel.

Any quick instructions where this can be configured would be appreciated.

Thanks-

Andy
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] collectd-mod-iwinfo

[Hanno Schupp]

Hi jow,

Thanks for following up.

Here the outputs:

root@Router00177962:/tmp#  iwinfo wl0 info
wl0   ESSID: "Chillifire Hotspot"
  Access Point: 00:1D:7E:E7:96:D4
  Type: wl  HW Mode(s): 802.11bg
  Mode: Master  Channel: 3 (2.422 GHz)
  Tx-Power: 24 dBm  Link Quality: 5/5
  Signal: 1 dBm  Noise: -92 dBm
  Bit Rate: 54.0 MBit/s
  Encryption: none
  Supports VAPs: yes

root@Router00177962:/tmp#  cat /etc/collectd.conf
# Please read collectd.conf(5) for a list of options.
# http://collectd.org/
#

BaseDir "/var/lib/collectd"
PIDFile "/var/run/collectd.pid"
Interval60
ReadThreads 1

LoadPlugin cpu
LoadPlugin load
LoadPlugin network
LoadPlugin memory
LoadPlugin ping
LoadPlugin processes
LoadPlugin iwinfo


  Server "120.138.19.134" "265"



Host "login02.chillifire.net"



  Process "chilli"


No errors on manual  start as you had requested. When starting daemon
normally with /etc/init.d/collectd start collectd does run fine:

root@Router00177962:/tmp#  ps
  PID USER   VSZ STAT COMMAND
1 root  1432 Sinit
2 root 0 SW   [keventd]
3 root 0 RWN  [ksoftirqd_CPU0]
4 root 0 SW   [kswapd]
5 root 0 SW   [bdflush]
6 root 0 SW   [kupdated]
8 root 0 SW   [mtdblockd]
   94 root 0 SWN  [jffs2_gcd_mtd4]
  120 root  1432 Sinit
  147 root  1440 Ssyslogd -C16
  149 root  1420 Sklogd
  856 root   888 S/usr/sbin/nas -P /var/run/nas.wl0.1.pid -H 34954
-l b
  930 root  1436 Sudhcpc -t 0 -i eth0.1 -b -p
/var/run/dhcp-eth0.1.pid
 1239 root   948 Sedge -d tun9 -f -r 0 -a 0.0.0.0 -s 255.255.255.255
-m
 1270 root  1436 Sudhcpc -i tun9 -b -p /var/run/tun9.pid -R -t 3
 1284 root  1440 Scrond -c /etc/crontabs -l 5
 1299 root  1112 S/usr/sbin/dropbear -P /var/run/dropbear.1.pid -p
22
 1402 root   940 S/usr/sbin/uhttpd -f -h /www -r Router00177962 -x
/cgi
 1425 nobody 868 S/usr/sbin/dnsmasq -K -D -y -Z -b -E -s lan -S
/lan/ -
 1511 root  2256 S/usr/sbin/chilli --conf=/etc/chilli.conf --pidfile
/v
 1547 root  1048 S/usr/sbin/ffwatchd
 1649 root  1432 S/usr/sbin/ntpd -n -p 0.openwrt.pool.ntp.org -p
1.open
 2022 root  1188 S/usr/sbin/dropbear -P /var/run/dropbear.1.pid -p
22
 2024 root  1436 S-ash
 2235 root  2476 S/usr/sbin/collectd -f
 2237 root  2476 S/usr/sbin/collectd -f
 2238 root  2476 S/usr/sbin/collectd -f
 2239 root  2476 S/usr/sbin/collectd -f
 2245 root  1428 Rps


No /tmp data file is created:

root@Router00177962:/tmp# ls -l
-rw-r--r--1 root root4 Jan 25 06:05 TZ
-rw-r--r--1 root root   79 Jan 25 05:59 dhcp.leases
-rw-r--r--1 root root  400 Sep  8 15:55 hs.conf
drwxr-xr-x3 root root   60 Sep  8 15:56 lib
drwxr-xr-x2 root root   40 Jan 25 06:04 lock
drwxr-xr-x2 root root   80 Sep  8 15:55 log
-rw-r--r--1 root root  773 Sep  8 15:55 main.conf
drwxr-xr-x2 root root   60 Jan 25 06:04 opkg-lists
drwxr-xr-x2 root root   40 Jan  1  2000 overlay
-rw-r--r--1 root root   32 Sep  8 15:55 resolv.conf
-rw-r--r--1 root root   77 Sep  8 15:55 resolv.conf.auto
drwxr-xr-x2 root root  380 Jan 25 06:05 run
-rw-r--r--1 root root   14 Sep  8 15:55 settings
drwxr-xr-x3 root root   60 Sep  8 15:55 spool
drwxr-xr-x2 root root  100 Sep  8 15:55 state
drwxr-xr-x3 root root   60 Jan 25 06:04 usr






-Original Message-
From: openwrt-devel-boun...@lists.openwrt.org
[mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Jo-Philipp
Wich
Sent: Wednesday, 25 January 2012 1:43 p.m.
To: OpenWrt Development List
Subject: Re: [OpenWrt-Devel] collectd-mod-iwinfo

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

So if you install the iwinfo cli frontend and run "iwinfo wl0 info", does it
output anything useful, does it identify the hw as "type wl" ?

Is "LoadPlugin iwinfo" in the enerated collectd.conf ?
Is "killall -9 collectd; collectd -f" reporting any errors ?
Are there iwinfo *.rrd files generated in /tmp/$hostname/ ?

~ Jow
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8fUBwACgkQdputYINPTPPt1QCfb8VxBljgoJ8As00b87RUPlz3
UgQAniLL1LV4M3QUPxUHc7AH0ztzRcMe
=XTkI
-END PGP SIGNATURE-
___
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] Let's fix the OpenWrt patch acceptance problem!

[Philip Prindeville]

On 1/24/12 6:06 AM, Jonathan McCrohan wrote:
> I also see svn as part of the problem. I think a move towards the
> linux-kernel development model would be a great benefit.
> 
> Using git would allow users to make many small fixes in their own tree
> and send single a pull request for fixes to x,y and z to a member of the
> patch review team for ACK or NAK who can then commit to master.
> Hopefully this will result in fewer stray patches.
> 
> The original user will then show up in git blame and will make tracing
> errors far easier. Currently, unless you have commit rights, everything
> comes from one of the few core developers and you have to manually look
> up the changeset to figure out who is responsible for it.

For those of us that submit fixes that then languish for months before being 
committed, wouldn't that mean having to constantly rebase them?

-Philip

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Qdisc

[scolfield]

Hi,

I'm not family with queue disciplines in the Linux kernel. My doubt is,
if the switch/router with Linux has exactly two ports to use for input and
output, so consider the following ASCII picture:
   ___
 /   \
Network 1 -- | eth0 |  SWITCH   | eth1 | ---
Network 2
 \ ___ /


Now, consider that a one flow crossing this switch:

Network 1 ---> eth0 ---> eth1 ---> Network 2

There are qdisc associated into the ingress and egress port?
How the qdisc (e.g., HTB) "communicate" with queues?

My doubt is, if I wanna instantiate 8 queue, each queue will be
a class on the HTB?

The following picture are possible?:

queue1 |---\
queue2 |---  \
queue3 |---   \ Network driver
queue4 |--- Scheduler -> | egress queue |---> out
queue5 |---   /eth1
queue6 |---  /
queue7 |--- /
queue8 |---/

The HTB act in 8 queues?

Thanks regards,
--
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] collectd-mod-iwinfo

[Jo-Philipp Wich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

So if you install the iwinfo cli frontend and run "iwinfo wl0 info",
does it output anything useful, does it identify the hw as "type wl" ?

Is "LoadPlugin iwinfo" in the enerated collectd.conf ?
Is "killall -9 collectd; collectd -f" reporting any errors ?
Are there iwinfo *.rrd files generated in /tmp/$hostname/ ?

~ Jow
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8fUBwACgkQdputYINPTPPt1QCfb8VxBljgoJ8As00b87RUPlz3
UgQAniLL1LV4M3QUPxUHc7AH0ztzRcMe
=XTkI
-END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] collectd-mod-iwinfo

[Hanno Schupp]

Thanks Jow,

I had a look at /trunk/package/iwinfo/Makefile and the IWINFO_BACKENDS
section seems to define wl driver as required target if a Broadcom kernel
module is loaded.

I do not understand Makefile at all, so I do not understand what else needs
to be done to 'wl must be enabled at build time of libiwinfo to get enabled
as backend'

Sorry to be a pest, but some help would bs greatly appreciated.

Thanks

Hanno
On Wednesday, 25 January 2012, Jo-Philipp Wich  wrote:
> Hey.
>
>> I cannot get collectd-mod-iwinfo to work for the proprietary wl0
>> drivers. They work fine on ath5k and ath9k.
>
> Make sure iwinfo was compiled with wl support (wl must be enabled at
> build time of libiwinfo to get enabled as backend)
>
>> Before I try further, does collectd-mod-iwinfo support wl0
> Yes.
>
> ~ Jow
> ___
> 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] [PATCH] Add support for Sitecom WL-341v3 and other Sercomm IP1006RRv2 boards -- third attempt

[Marco Antonio Mauro]

This patch adds support for the Sitecom WL-341 v3 and other Sercomm
IP1006RRv2 based boards for sysupgrade support and for the initial
flash through pushbutton initiated recovery mode with the special
partition table and fixes for the quirks and things required by the
modified bootloader.

There is a known bug, Wi-Fi is not working on my board probably
because of the lack of RAM (the board only has 16MiB ram -- half of
the normal amount for non rebadged versions, but there is an empty
slot for another ram chip,) but I don't know for sure. The driver
loads but hostapd fails to load so I think it's not related to the
specific device except for the lack of RAM.

Moreover, only 7 of the 11 onboard leds are confirmed working, it
seems that one of the others is always on and the remaining ones are
connected to the wireless card leds already recognized by OpenWrt

The patch is attached and not inline to avoid mangling by my mail client.

This obsoletes and replaces my previous patch, which has a copypaste error.

Signed-off-by: Marco Antonio Mauro 


-- 
Marcus905
GPG pubkey:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1FC0ECC932FE5FAC
Index: target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig
===
--- target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig	(revision 29890)
+++ target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig	(working copy)
@@ -41,6 +41,11 @@
 	select RALINK_DEV_GPIO_BUTTONS
 	select RALINK_DEV_GPIO_LEDS
 
+config RT305X_MACH_WL341V3
+	bool "Sitecom WL-341 v3 board support"
+	select RALINK_DEV_GPIO_BUTTONS
+	select RALINK_DEV_GPIO_LEDS
+
 config RT305X_MACH_ESR_9753
 	bool "EnGenius ESR-9753 support"
 	select RALINK_DEV_GPIO_BUTTONS
Index: target/linux/ramips/files/arch/mips/ralink/rt305x/mach-wl341v3.c
===
--- target/linux/ramips/files/arch/mips/ralink/rt305x/mach-wl341v3.c	(revision 0)
+++ target/linux/ramips/files/arch/mips/ralink/rt305x/mach-wl341v3.c	(revision 0)
@@ -0,0 +1,154 @@
+/*
+ *  Sitecom WL341v3 board support
+ *
+ *  Copyright (C) 2012 Marco Antonio Mauro 
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License version 2 as published
+ *  by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "devices.h"
+
+#define WL341V3_GPIO_LED_FIRST_AMBER	9
+#define WL341V3_GPIO_LED_FIRST_BLUE	13
+#define WL341V3_GPIO_LED_THIRD_AMBER	11
+#define WL341V3_GPIO_LED_THIRD_BLUE	14
+#define WL341V3_GPIO_LED_FOURTH_BLUE	10
+#define WL341V3_GPIO_LED_FIFTH_AMBER	12
+#define WL341V3_GPIO_LED_FIFTH_BLUE	8
+
+#define WL341V3_GPIO_BUTTON_WPS		5	/* active low */
+#define WL341V3_GPIO_BUTTON_RESET	7	/* active low */
+
+#define WL341V3_BUTTONS_POLL_INTERVAL	20
+
+#ifdef CONFIG_MTD_PARTITIONS
+static struct mtd_partition wl341v3_partitions[] = {
+	{
+		.name	= "u-boot",
+		.offset	= 0,
+		.size	= 0x02,
+		.mask_flags = MTD_WRITEABLE,
+	}, {
+		.name	= "board-nvram",
+		.offset	= 0x02,
+		.size	= 0x01,
+		.mask_flags = MTD_WRITEABLE,
+	}, {
+		.name	= "u-boot-env",
+		.offset	= 0x03,
+		.size	= 0x01,
+		.mask_flags = MTD_WRITEABLE,
+	}, {
+		.name	= "kernel",
+		.offset	= 0x04,
+		.size	= 0x0d,
+	}, {
+		.name	= "rootfs",
+		.offset	= 0x11,
+		.size	= 0x2e,
+	}, {
+		.name	= "signature-eRcOmM",
+		.offset	= 0x3f,
+		.size	= 0x01,
+	}, {
+		.name	= "firmware",
+		.offset	= 0x04,
+		.size	= 0x3b,
+	}, {
+		.name	= "fullflash",
+		.offset	= 0x00,
+		.size	= 0x40,
+	}
+};
+#endif /* CONFIG_MTD_PARTITIONS */
+
+static struct physmap_flash_data wl341v3_flash_data = {
+#ifdef CONFIG_MTD_PARTITIONS
+	.nr_parts	= ARRAY_SIZE(wl341v3_partitions),
+	.parts		= wl341v3_partitions,
+#endif
+};
+
+static struct gpio_led wl341v3_leds_gpio[] __initdata = {
+	{
+		.name		= "wl341v3:amber:first",
+		.gpio		= WL341V3_GPIO_LED_FIRST_AMBER,
+		.active_low	= 1,
+	}, {
+		.name		= "wl341v3:blue:first",
+		.gpio		= WL341V3_GPIO_LED_FIRST_BLUE,
+		.active_low	= 1,
+	}, {
+		.name		= "wl341v3:amber:third",
+		.gpio		= WL341V3_GPIO_LED_THIRD_AMBER,
+		.active_low	= 1,
+	}, {
+		.name		= "wl341v3:blue:third",
+		.gpio		= WL341V3_GPIO_LED_THIRD_BLUE,
+		.active_low	= 1,
+	}, {
+		.name		= "wl341v3:blue:fourth",
+		.gpio		= WL341V3_GPIO_LED_FOURTH_BLUE,
+		.active_low	= 1,
+	}, {
+		.name		= "wl341v3:amber:fifth",
+		.gpio		= WL341V3_GPIO_LED_FIFTH_AMBER,
+		.active_low	= 1,
+	}, {
+		.name		= "wl341v3:blue:fifth",
+		.gpio		= WL341V3_GPIO_LED_FIFTH_BLUE,
+		.active_low	= 1,
+	}
+};
+
+static struct gpio_button wl341v3_gpio_buttons[] __initdata = {
+	{
+		.desc		= "reset",
+		.type		= EV_KEY,
+		.code		= KEY_RESTART,
+		.threshold	= 3,
+		.gpio		= WL341V3_GPIO_BUTTON_RESET,
+		.active_low	= 1,
+	}, {
+		.desc		= "wps",
+		.type		= EV_KEY,
+		.code	

[OpenWrt-Devel] [PATCH] Add support for Sitecom WL-341v3 and other Sercomm IP1006RRv2 boards

[Marco Antonio Mauro]

This patch adds support for the Sitecom WL-341 v3 and other Sercomm
IP1006RRv2 based boards for sysupgrade support and for the initial
flash through pushbutton initiated recovery mode with the special
partition table and fixes for the quirks and things required by the
modified bootloader.

There is a known bug, Wi-Fi is not working on my board probably
because of the lack of RAM (the board only has 16MiB ram -- half of
the normal amount for non rebadged versions, but there is an empty
slot for another ram chip,) but I don't know for sure. The driver
loads but hostapd fails to load so I think it's not related to the
specific device except for the lack of RAM.

Moreover, only 7 of the 11 onboard leds are confirmed working, it
seems that one of the others is always on and the remaining ones are
connected to the wireless card leds already recognized by OpenWrt

The patch is attached and not inline to avoid mangling by my mail client.

This obsoletes and replaces my previous patch.

Signed-off-by: Marco Antonio Mauro 

-- 
Marcus905
GPG pubkey:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1FC0ECC932FE5FAC
Index: target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig
===
--- target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig	(revision 29890)
+++ target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig	(working copy)
@@ -41,6 +41,11 @@
 	select RALINK_DEV_GPIO_BUTTONS
 	select RALINK_DEV_GPIO_LEDS
 
+config RT305X_MACH_WL341V3
+	bool "Sitecom WL-341 v3 board support"
+	select RALINK_DEV_GPIO_BUTTONS
+	select RALINK_DEV_GPIO_LEDS
+
 config RT305X_MACH_ESR_9753
 	bool "EnGenius ESR-9753 support"
 	select RALINK_DEV_GPIO_BUTTONS
Index: target/linux/ramips/files/arch/mips/ralink/rt305x/mach-wl341v3.c
===
--- target/linux/ramips/files/arch/mips/ralink/rt305x/mach-wl341v3.c	(revision 0)
+++ target/linux/ramips/files/arch/mips/ralink/rt305x/mach-wl341v3.c	(revision 0)
@@ -0,0 +1,154 @@
+/*
+ *  Sitecom WL341v3 board support
+ *
+ *  Copyright (C) 2012 Marco Antonio Mauro 
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License version 2 as published
+ *  by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "devices.h"
+
+#define WL341V3_GPIO_LED_FIRST_AMBER	9
+#define WL341V3_GPIO_LED_FIRST_BLUE	13
+#define WL341V3_GPIO_LED_THIRD_AMBER	11
+#define WL341V3_GPIO_LED_THIRD_BLUE	14
+#define WL341V3_GPIO_LED_FOURTH_BLUE	10
+#define WL341V3_GPIO_LED_FIFTH_AMBER	12
+#define WL341V3_GPIO_LED_FIFTH_BLUE	8
+
+#define WL341V3_GPIO_BUTTON_WPS		5	/* active low */
+#define WL341V3_GPIO_BUTTON_RESET	7	/* active low */
+
+#define WL341V3_BUTTONS_POLL_INTERVAL	20
+
+#ifdef CONFIG_MTD_PARTITIONS
+static struct mtd_partition wl341v3_partitions[] = {
+	{
+		.name	= "u-boot",
+		.offset	= 0,
+		.size	= 0x02,
+		.mask_flags = MTD_WRITEABLE,
+	}, {
+		.name	= "board-nvram",
+		.offset	= 0x02,
+		.size	= 0x01,
+		.mask_flags = MTD_WRITEABLE,
+	}, {
+		.name	= "u-boot-env",
+		.offset	= 0x03,
+		.size	= 0x01,
+		.mask_flags = MTD_WRITEABLE,
+	}, {
+		.name	= "kernel",
+		.offset	= 0x04,
+		.size	= 0x0d,
+	}, {
+		.name	= "rootfs",
+		.offset	= 0x11,
+		.size	= 0x2e,
+	}, {
+		.name	= "signature-eRcOmM",
+		.offset	= 0x3f,
+		.size	= 0x01,
+	}, {
+		.name	= "firmware",
+		.offset	= 0x04,
+		.size	= 0x3b,
+	}, {
+		.name	= "fullflash",
+		.offset	= 0x00,
+		.size	= 0x40,
+	}
+};
+#endif /* CONFIG_MTD_PARTITIONS */
+
+static struct physmap_flash_data wl341v3_flash_data = {
+#ifdef CONFIG_MTD_PARTITIONS
+	.nr_parts	= ARRAY_SIZE(wl341v3_partitions),
+	.parts		= wl341v3_partitions,
+#endif
+};
+
+static struct gpio_led wl341v3_leds_gpio[] __initdata = {
+	{
+		.name		= "wl341v3:amber:first",
+		.gpio		= WL341V3_GPIO_LED_FIRST_AMBER,
+		.active_low	= 1,
+	}, {
+		.name		= "wl341v3:blue:first",
+		.gpio		= WL341V3_GPIO_LED_FIRST_BLUE,
+		.active_low	= 1,
+	}, {
+		.name		= "wl341v3:amber:third",
+		.gpio		= WL341V3_GPIO_LED_STATUS_BLUE,
+		.active_low	= 1,
+	}, {
+		.name		= "wl341v3:blue:third",
+		.gpio		= WL341V3_GPIO_LED_STATUS_BLUE,
+		.active_low	= 1,
+	}, {
+		.name		= "wl341v3:blue:fourth",
+		.gpio		= WL341V3_GPIO_LED_STATUS_BLUE,
+		.active_low	= 1,
+	}, {
+		.name		= "wl341v3:amber:fifth",
+		.gpio		= WL341V3_GPIO_LED_STATUS_BLUE,
+		.active_low	= 1,
+	}, {
+		.name		= "wl341v3:blue:fifth",
+		.gpio		= WL341V3_GPIO_LED_STATUS_BLUE,
+		.active_low	= 1,
+	}
+};
+
+static struct gpio_button wl341v3_gpio_buttons[] __initdata = {
+	{
+		.desc		= "reset",
+		.type		= EV_KEY,
+		.code		= KEY_RESTART,
+		.threshold	= 3,
+		.gpio		= WL341V3_GPIO_BUTTON_RESET,
+		.active_low	= 1,
+	}, {
+		.desc		= "wps",
+		.type		= EV_KEY,
+		.code		= KEY_WPS_BUTTON,
+		.thres

Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!

[Florian Fainelli]

On Tuesday 24 January 2012 15:59:18 Emmanuel Deloget wrote:
> Le 01/24/2012 02:06 PM, Jonathan McCrohan a écrit :
> > On 24/01/12 08:22, Dave Taht wrote:
> >> My principal critique of this workflow is that I tend to view svn as
> >> part of the problem to a large extent. If I do a patch in my own (git)
> >> tree to test with, I invariably have to rebase that tree when it comes
> >> down from svn.
> >> 
> >> as I am frequently offline, not being able to do a 'svn log' is the
> >> second deal-killer for me, for svn usage.
> > 
> > I also see svn as part of the problem. I think a move towards the
> > linux-kernel development model would be a great benefit.
> > 
> > Using git would allow users to make many small fixes in their own tree
> > and send single a pull request for fixes to x,y and z to a member of the
> > patch review team for ACK or NAK who can then commit to master.
> > Hopefully this will result in fewer stray patches.
> > 
> > The original user will then show up in git blame and will make tracing
> > errors far easier. Currently, unless you have commit rights, everything
> > comes from one of the few core developers and you have to manually look
> > up the changeset to figure out who is responsible for it.
> 
> I would also give my vote to git, as this solution proved to be far
> more scalable than svn. Since importing an svn tree to git is quite easy,
> and since trac proposed a git connector, such a move should be nearly
> painless (unless you have the full openwrt svn as an svn:external in
> your own tree).

Let's just keep focused on the proposal here and not the use of a different 
tool for the main repository. SVN is scalable as well, what is not is giving 
access to the main repository right now.
-- 
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!

[Florian Fainelli]

Hello,

On Tuesday 24 January 2012 21:14:23 Michael Heimpold wrote:
> Hi,
> 
> > In my opinion, the main issue is not that we don't give out SVN access
> > fast enough,
> 
> from my personal experience I can say that I got SVN access very quickly
> after I offered taking over maintainership for php5 package.
> 
> After some months I suggested to split php into multiple packages
> (for pecl modules) but I did not yet get svn acccess for this. Not even
> a response to my requests.
> 
> > it's that people consider SVN access necessary for
> > contributing in the first place.
> 
> I don't think so. I'm fine with submitting patches to the list. To speed up
> my personal workflow I placed 'packages' on github so that I can send pull
> requests to the list (git://github.com/mhei/openwrt-packages.git) in the
> near future (but I'm still novice with git - learning by doing :-)

Sending pull-requests along with the patches contained in the pull request 
sounds good to me. FYI, buildroot proceeds like this.

> 
> And yes, please stay hard giving commit access away to keep the
> quality on the current high level.
> And yes, tell me/flame me when I commit rubbish or send patches
> which doesn't apply/are broken...
> 
> So to summarize: for me the main trouble is not how the workflow
> is - I'll try to adapt myself - but I need feedback on the list as I've
> only little time on IRC...
> 
> > willing to organize and take care of maintaining the tree and compile
> > testing and reviewing the incoming changes?
> 
> Is there already work done/docs about setting up buildbot slaves/
> cronjobs for nightly builds... ? I feel that my CPU could do something
> useful when I'm sleeping/at work :-)

You might want to contact Jo and Travis about this since they both administer 
such a buildbot.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!

[Michael Heimpold]

Hi,

> In my opinion, the main issue is not that we don't give out SVN access
> fast enough,

from my personal experience I can say that I got SVN access very quickly
after I offered taking over maintainership for php5 package.

After some months I suggested to split php into multiple packages
(for pecl modules) but I did not yet get svn acccess for this. Not even
a response to my requests.

> it's that people consider SVN access necessary for
> contributing in the first place.

I don't think so. I'm fine with submitting patches to the list. To speed up my
personal workflow I placed 'packages' on github so that I can send pull requests
to the list (git://github.com/mhei/openwrt-packages.git) in the near future
(but I'm still novice with git - learning by doing :-)

And yes, please stay hard giving commit access away to keep the
quality on the current high level.
And yes, tell me/flame me when I commit rubbish or send patches
which doesn't apply/are broken...

So to summarize: for me the main trouble is not how the workflow
is - I'll try to adapt myself - but I need feedback on the list as I've
only little time on IRC...

> willing to organize and take care of maintaining the tree and compile
> testing and reviewing the incoming changes?

Is there already work done/docs about setting up buildbot slaves/
cronjobs for nightly builds... ? I feel that my CPU could do something
useful when I'm sleeping/at work :-)

My 2 cents, mhei

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] ar71xx: TL-MR3020: fix board detection, fix missing mandatory package and modify LED behaviour

[Christian Cier-Zniewski]

This patch fixes the board detection of the TL-MR3020.
The string *TL-MR3020 was searched which is wrong.
Now the correct string *"TL-MR3020 v1" is searched for.
The board name has also been modified from tl-mr3020 to tl-mr3020-v1 to 
reflect the correction revision.
All strings have been updated in the other files which rely on the board 
name.


The LED behaviour has also been modified:
* The WPS LED is the diag LED now.
* A netdev trigger for the LAN LED has been added.

The profile of the TL-MR3020 has been updated because the needed package 
"kmod-ledtrig-usbdev" was missing which resulted in a non-working usbdev 
trigger for the 3G/USB LED.


Signed-off-by: Christian Cier-Zniewski 



Index: target/linux/ar71xx/base-files/lib/ar71xx.sh
===
--- target/linux/ar71xx/base-files/lib/ar71xx.sh(Revision 29875)
+++ target/linux/ar71xx/base-files/lib/ar71xx.sh(Arbeitskopie)
@@ -256,8 +256,8 @@
*"DIR-615 rev. C1")
name="dir-615-c1"
;;
-   *TL-MR3020)
-   name="tl-mr3020"
+   *"TL-MR3020 v1")
+   name="tl-mr3020-v1"
;;
*TL-MR3220)
name="tl-mr3220"
Index: target/linux/ar71xx/base-files/lib/upgrade/platform.sh
===
--- target/linux/ar71xx/base-files/lib/upgrade/platform.sh  (Revision 29875)
+++ target/linux/ar71xx/base-files/lib/upgrade/platform.sh  (Arbeitskopie)
@@ -121,7 +121,7 @@
}
return 0
;;
-   tl-mr3020 | \
+   tl-mr3020-v1 | \
tl-mr3220 | \
tl-mr3420 | \
tl-wa901nd | \
Index: target/linux/ar71xx/base-files/etc/uci-defaults/leds
===
--- target/linux/ar71xx/base-files/etc/uci-defaults/leds(Revision 29875)
+++ target/linux/ar71xx/base-files/etc/uci-defaults/leds(Arbeitskopie)
@@ -139,9 +139,10 @@
set_led_netdev "port2" "port2" "om2p:blue:lan" "eth1"
;;
 
-tl-mr3020)
+tl-mr3020-v1)
set_led_usbdev "usb" "USB" "tp-link:green:3g" "1-1"
set_led_wlan "wlan" "WLAN" "tp-link:green:wlan" "phy0tpt"
+   set_led_netdev "lan" "LAN" "tp-link:green:lan"  "eth0"
;;
 
 tl-mr3220 | \
Index: target/linux/ar71xx/base-files/etc/uci-defaults/network
===
--- target/linux/ar71xx/base-files/etc/uci-defaults/network (Revision 29875)
+++ target/linux/ar71xx/base-files/etc/uci-defaults/network (Arbeitskopie)
@@ -110,7 +110,7 @@
 bullet-m |\
 eap7660d |\
 rb-411 |\
-tl-mr3020 |\
+tl-mr3020-v1 |\
 tl-wa901nd |\
 tl-wa901nd-v2 |\
 tl-wr703n |\
Index: target/linux/ar71xx/base-files/etc/diag.sh
===
--- target/linux/ar71xx/base-files/etc/diag.sh  (Revision 29875)
+++ target/linux/ar71xx/base-files/etc/diag.sh  (Arbeitskopie)
@@ -97,7 +97,9 @@
tew-632brp)
status_led="tew-632brp:green:status"
;;
-   tl-mr3020 | \
+   tl-mr3020-v1)
+   status_led="tp-link:green:wps"
+   ;;
tl-mr3220 | \
tl-mr3420 | \
tl-wa901nd | \
Index: target/linux/ar71xx/generic/profiles/tp-link.mk
===
--- target/linux/ar71xx/generic/profiles/tp-link.mk (Revision 29875)
+++ target/linux/ar71xx/generic/profiles/tp-link.mk (Arbeitskopie)
@@ -7,7 +7,7 @@
 
 define Profile/TLMR3020
NAME:=TP-LINK TL-MR3020
-   PACKAGES:=kmod-usb-core kmod-usb2
+   PACKAGES:=kmod-usb-core kmod-usb2 kmod-ledtrig-usbdev
 endef
 
 define Profile/TLMR3020/Description
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] ar71xx: TL-MR3020: fix GPIO polarity for button and switch

[Christian Cier-Zniewski]

This patch fixes the GPIO polarity for the button and the sliding 
switch. The buttons are not active low. "Pressed" and "Released" events 
are wrong without the patch.


Signed-off-by: Christian Cier-Zniewski 


Index: target/linux/ar71xx/files-2.6.39/arch/mips/ar71xx/mach-tl-mr3020.c
===
--- target/linux/ar71xx/files-2.6.39/arch/mips/ar71xx/mach-tl-mr3020.c  
(Revision 29875)
+++ target/linux/ar71xx/files-2.6.39/arch/mips/ar71xx/mach-tl-mr3020.c  
(Arbeitskopie)
@@ -74,7 +74,7 @@
.code   = KEY_WPS_BUTTON,
.debounce_interval = TL_MR3020_KEYS_DEBOUNCE_INTERVAL,
.gpio   = TL_MR3020_GPIO_BTN_WPS,
-   .active_low = 1,
+   .active_low = 0,
},
{
.desc   = "sw1",
@@ -82,7 +82,7 @@
.code   = BTN_0,
.debounce_interval = TL_MR3020_KEYS_DEBOUNCE_INTERVAL,
.gpio   = TL_MR3020_GPIO_BTN_SW1,
-   .active_low = 1,
+   .active_low = 0,
},
{
.desc   = "sw2",
@@ -90,7 +90,7 @@
.code   = BTN_1,
.debounce_interval = TL_MR3020_KEYS_DEBOUNCE_INTERVAL,
.gpio   = TL_MR3020_GPIO_BTN_SW2,
-   .active_low = 1,
+   .active_low = 0,
}
 };
 
Index: target/linux/ar71xx/files-3.2/arch/mips/ath79/mach-tl-mr3020.c
===
--- target/linux/ar71xx/files-3.2/arch/mips/ath79/mach-tl-mr3020.c  
(Revision 29875)
+++ target/linux/ar71xx/files-3.2/arch/mips/ath79/mach-tl-mr3020.c  
(Arbeitskopie)
@@ -74,7 +74,7 @@
.code   = KEY_WPS_BUTTON,
.debounce_interval = TL_MR3020_KEYS_DEBOUNCE_INTERVAL,
.gpio   = TL_MR3020_GPIO_BTN_WPS,
-   .active_low = 1,
+   .active_low = 0,
},
{
.desc   = "sw1",
@@ -82,7 +82,7 @@
.code   = BTN_0,
.debounce_interval = TL_MR3020_KEYS_DEBOUNCE_INTERVAL,
.gpio   = TL_MR3020_GPIO_BTN_SW1,
-   .active_low = 1,
+   .active_low = 0,
},
{
.desc   = "sw2",
@@ -90,7 +90,7 @@
.code   = BTN_1,
.debounce_interval = TL_MR3020_KEYS_DEBOUNCE_INTERVAL,
.gpio   = TL_MR3020_GPIO_BTN_SW2,
-   .active_low = 1,
+   .active_low = 0,
}
 };
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Synopsys DWC OTG USB, round 4

[Nikolai Zhubr]

Hello Alan,
24.01.2012 19:45, Alan Stern:
[trim]

Does this mean that the hardware has only one FIFO?  Or only one for
each direction?  That's a pretty limited design.


Well EPs do have separate FIFOs, at least that's how the driver see it, 
but it looks like they are somehow not fully independent actually.


[trim]

It's even possible that the host will want to receive one packet from
one endpoint (presumably the FIFO can hold more than one packet's
worth?) followed by one packet from another endpoint.  Judging by your
description, it is impossible for the device to fulfill such requests.

You will simply have to live with mismatches.  There's nothing wrong
them, so long as the device responds to a mismatch with NAK.


Ok, so you mean that it would be correct to just allow mismatches happen 
as much as they will and consider handling them (that is, resubmitting 
data) as a normal workflow?


Thank you.
Nikolai



Alan Stern





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designware USB OTG driver upstream questions

[Nikolai Zhubr]

Hi,
24.01.2012 19:12, Loh Tien Hock:

Hi Nikolai.

I tried the patch with g_serial. it needed some fix I have in my company's
repository for slave mode. Dma mode works correctly.


Wow, this puzzles me somewhat. I'll definitely try to test it and report 
back.


Thank you.
Nikolai

[trim]



These patches are not in mergable state, for the very least, they have

no information as to what they do, who wrote them, and all the other
meta-data we need to be able to read them.



Hi Greg,

Sorry for the late reply. The patch was obtained from these link:
http://patchwork.ozlabs.org/**patch/119923/
http://patchwork.ozlabs.org/**patch/119924/
http://patchwork.ozlabs.org/**patch/119925/
http://patchwork.ozlabs.org/**patch/119925/
http://patchwork.ozlabs.org/**patch/119926/
http://patchwork.ozlabs.org/**patch/119927/
http://patchwork.ozlabs.org/**patch/119928/
http://patchwork.ozlabs.org/**patch/119929/
http://patchwork.ozlabs.org/**patch/119930/
http://patchwork.ozlabs.org/**patch/119931/
http://patchwork.ozlabs.org/**patch/119932/

Are the meta-data in place? I'm still new to kernel patch, so please let
me know
if there's anymore things you need. Please advice on the work needed (as
to
rewrite, or to refactor).



Before even proceeding to any formal requirements: have you checked how
well it works with g_serial and g_ether?


Thank you.
Nikolai





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!

[Felix Fietkau]

On 2012-01-24 4:29 PM, Geert Uytterhoeven wrote:
> On Tue, Jan 24, 2012 at 16:16, Felix Fietkau  wrote:
>> Probably not going to happen for the main repo. Some developers like to
>> stay with SVN. Right now I don't see a point in pushing for a complete
>> switch to git, since the svn<->git integration is working just fine.
> 
> While git-svn is bidirectional, there are limitations when working with other
> people using git:
>   - After pulling from another git repository, you cannot just dcommit the
> result to the svn repository. You must rebase or cherry-pick it on top of
> your branch you use to sync with svn.
>   - You loose the original authorship, as dcommit will commit it to svn as
> your own.
> 
> Disclaimer: it's been a few months I used git-svn, so things may have changed
> in the mean time. Welcome to the road to heaven^H^H^H^H^H^Hgit ;-)
Yeah, I'm aware of the above limitations. I've been using git-svn for
all of my OpenWrt checkouts for a few years now. The rebase/cherry-pick
can be easily automated with a script, and the authorship can be
annotated in the commit messages. I don't think either of those
limitations is problematic at all.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!

[Geert Uytterhoeven]

On Tue, Jan 24, 2012 at 16:16, Felix Fietkau  wrote:
> Probably not going to happen for the main repo. Some developers like to
> stay with SVN. Right now I don't see a point in pushing for a complete
> switch to git, since the svn<->git integration is working just fine.

While git-svn is bidirectional, there are limitations when working with other
people using git:
  - After pulling from another git repository, you cannot just dcommit the
result to the svn repository. You must rebase or cherry-pick it on top of
your branch you use to sync with svn.
  - You loose the original authorship, as dcommit will commit it to svn as
your own.

Disclaimer: it's been a few months I used git-svn, so things may have changed
in the mean time. Welcome to the road to heaven^H^H^H^H^H^Hgit ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!

[Felix Fietkau]

On 2012-01-24 3:57 PM, Brian J. Murrell wrote:
> On 12-01-24 08:06 AM, Jonathan McCrohan wrote:
>> 
>> I also see svn as part of the problem. I think a move towards the
>> linux-kernel development model would be a great benefit.
> 
> I hate sending simple "me too" posts, but to help demonstrate that there
> is demand for this, I too would welcome a move to git from SVN.
Probably not going to happen for the main repo. Some developers like to
stay with SVN. Right now I don't see a point in pushing for a complete
switch to git, since the svn<->git integration is working just fine.

So guys, let's keep this discussion on topic. The proposed-changes repo
is of course going to be a git repo, but the main repo stays with svn.

Let's focus the discussion on how the proposed-changes repo should be
maintained, who should do it, and how the patch team will organize.

If you feel like you absolutely must send your 'me too' mails on the
switch-to-git topic, please pick a different thread for that. :)

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Synopsys DWC OTG USB, round 4

[Nikolai Zhubr]

Hello people,

I'd like to hear some advice before I waste yet more time on this. 
Because my knowledge of USB concepts is close to nonexistent, I'll just 
present the situation as I see it currently with just all details I have.


As I understand it, the problem with this thing in device mode is that 
it is unable to automatically reorder IN data for different EPs 
submitted to it by the driver to match the sequence of EPs in IN tokens 
coming from host side. (A mismatch will be detected, however, and 
reported to the driver through an irq) So as long as the hardware can 
not provide necessary ordering by itself, this obviously has to be done 
in software (in the driver). Otherwise, the device might ocasionally 
still work in cases of very few IN EPs used and some very predictable IN 
patterns (for which g_file_storage is apparently an example) but will 
fail sooner or later.


Ok. The unpatched original dwc driver just does not care at all. The 
workaround code (supposedly created by Amlogic) does care but the 
reordering it applies is not based on any actual IN tokens. (To be 
short, its does some hard-coded preventive reordering, probably based on 
some experiments) So essentially, it just masqerades the problem a 
little bit rather than removes it (Well, at least now I know why 
android's adb via usb is so unstable on this device) So I suppose such 
workaround isn't really worth applying.


In order to guarantee proper ordering in software (in case there are 2 
or more IN EPs), the driver will need to:


1. not start submitting new IN data to Tx FIFO until a respective IN 
token is received;
2. either be notified of every new IN token separately, or have an 
opportunity to examine EP numbers of actual IN tokens received in a batch.


From my recent attempts I know that 1 is possible and simple, though 
delaying start of transfer would probably result in less-than-optimal 
overall speed in simple scenarios, but that it ok.


Now 2 is harder. While there are individual intktxfemp bits ("IN Token 
while Tx Fifo Empty") for all EPs, under heavy CPU load (or just 
occasionally) they might collide in a single irq and therefore will not 
be sufficient to build the required sequence unambiguously. Fetching 
informations on actual IN tokens from the controller is mentioned in 
header files and implemented in some function in the driver but it does 
not work on my device (all zeroes all the time, maybe the feature was 
dropped to simplify the silicon or header file is imprecise, no idea) So 
basically in this case of collided intktxfemp bits the only possibility 
is do a random guess (e.g. try the first one), then if "EP mismatch" 
interrupt occures, blacklist this EP temporarily and try another. Repeat 
as necessary. Very ugly.


So question is, does it even make sense? Is it worth trying or am I too 
wrong somethere?


Thank you.
Nikolai


22.01.2012 15:12, I wrote:

Hello,
22.01.2012 1:40, I wrote:
[...]

if matters). Without that, controller starts raising "IN Token Received
with EP mismatch" instead of normal "Transfer complete" bit. If I
understand it correctly, this means that Tx FIFO happened to be filled
in some particular order that controller disliked (and refused). I've
also found a fragment of code with possibly relevant comment (quoted
below). Indeed, apparently this "EP mismatch" event is not handled
anywhere in the driver (other than providing a line for dmesg). If it
should, then I'd guess it means the driver is just plain unfininshed and
I have no idea if it can even be fixed with a reasonable effort. Not


Nevermind. I've meanwhile found some code crafted by Amlogic (or whoever
it was) addressing exactly this problem. It does not work well because
it is buggy, however the idea is simple enough: do not push data to Tx
FIFO if it still holds some previous unsent data for another EP. I think
I can fix this workaround to actually do what it tries to.
(This somewhat reduces the whole usefullness of EPs probably, but at
least the damned thing stops throwing "EP mismatch", I've checked)


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!

[Emmanuel Deloget]

Le 01/24/2012 02:06 PM, Jonathan McCrohan a écrit :

On 24/01/12 08:22, Dave Taht wrote:

My principal critique of this workflow is that I tend to view svn as part
of the problem to a large extent. If I do a patch in my own (git) tree
to test with, I invariably have to rebase that tree when it comes down
from svn.

as I am frequently offline, not being able to do a 'svn log' is the
second deal-killer for me, for svn usage.


I also see svn as part of the problem. I think a move towards the
linux-kernel development model would be a great benefit.

Using git would allow users to make many small fixes in their own tree
and send single a pull request for fixes to x,y and z to a member of the
patch review team for ACK or NAK who can then commit to master.
Hopefully this will result in fewer stray patches.

The original user will then show up in git blame and will make tracing
errors far easier. Currently, unless you have commit rights, everything
comes from one of the few core developers and you have to manually look
up the changeset to figure out who is responsible for it.


I would also give my vote to git, as this solution proved to be far
more scalable than svn. Since importing an svn tree to git is quite easy,
and since trac proposed a git connector, such a move should be nearly
painless (unless you have the full openwrt svn as an svn:external in
your own tree).


Jon

___
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] Let's fix the OpenWrt patch acceptance problem!

[Brian J. Murrell]

On 12-01-24 08:06 AM, Jonathan McCrohan wrote:
> 
> I also see svn as part of the problem. I think a move towards the
> linux-kernel development model would be a great benefit.

I hate sending simple "me too" posts, but to help demonstrate that there
is demand for this, I too would welcome a move to git from SVN.

Cheers,
b.



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Buffalo WZR-HP-G450H support question

[Jo-Philipp Wich]

Hi,

> Specifically, I'm lacking the ability to change channels (the 
> important part)

option channel ?

> and have no ability to control antenna chains or adjust power.

option txpower, option rxantenna and option txantenna?

> What can I do to help improve this support, or who can I help?

You could start elaborating on the actual problems.

~ Jow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] iwinfo hardware_name

[Jo-Philipp Wich]

The current code is supposed to infer the model from the PCI IDs of the
radio, apparently this is not possible and as I have no access to such a
model I cannot fix it either - I assumed ath5k exposes it the same way
madwifi does but apparently not.

~ Jow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] collectd-mod-iwinfo

[Jo-Philipp Wich]

Hey.

> I cannot get collectd-mod-iwinfo to work for the proprietary wl0
> drivers. They work fine on ath5k and ath9k.

Make sure iwinfo was compiled with wl support (wl must be enabled at
build time of libiwinfo to get enabled as backend).

> Before I try further, does collectd-mod-iwinfo support wl0
Yes.

~ Jow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!

[Jonathan McCrohan]

On 24/01/12 08:22, Dave Taht wrote:
> My principal critique of this workflow is that I tend to view svn as part
> of the problem to a large extent. If I do a patch in my own (git) tree
> to test with, I invariably have to rebase that tree when it comes down
> from svn.
> 
> as I am frequently offline, not being able to do a 'svn log' is the
> second deal-killer for me, for svn usage.

I also see svn as part of the problem. I think a move towards the
linux-kernel development model would be a great benefit.

Using git would allow users to make many small fixes in their own tree
and send single a pull request for fixes to x,y and z to a member of the
patch review team for ACK or NAK who can then commit to master.
Hopefully this will result in fewer stray patches.

The original user will then show up in git blame and will make tracing
errors far easier. Currently, unless you have commit rights, everything
comes from one of the few core developers and you have to manually look
up the changeset to figure out who is responsible for it.

Jon

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/4] ALL0256N: user-space support

[Gabor Juhos]

2012.01.23. 21:03 keltezéssel, Daniel Golle írta:
> This adds uci-defaults and sysupgrade support for the ALL0256N.
> 
> Signed-off-by: Daniel Golle 

Applied.

Thanks,
Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 4/4] ALL0256N: image/Makefile

[Gabor Juhos]

2012.01.23. 21:05 keltezéssel, Daniel Golle írta:
> Generate sysupgrade image for the ALL0256N.
> 
> Signed-off-by: Daniel Golle 

Applied.

Thanks,
Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/4] ALL0256N: board setup code

[Gabor Juhos]

2012.01.23. 21:02 keltezéssel, Daniel Golle írta:
> Add mach-all0256n.c doing the board-setup.
> 
> Signed-off-by: Daniel Golle 

Folded into the 1/4 patch to avoid a build error.

Thanks,
Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/4] ALL0256N: add entry to machtype.h, Kconfig, Makefile and config-2.6.39

[Gabor Juhos]

2012.01.23. 21:00 keltezéssel, Daniel Golle írta:
> ALL0256N: add entires in machtype.h, Makefile, Kconfig and enable board in
> config-2.3.39
> 
> Signed-off-by: Daniel Golle 

Applied.

Thanks,
Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips scripts updates

[Gabor Juhos]

2012.01.23. 1:29 keltezéssel, Roman Yeryomin írta:
> In this patch:
> 
> * rename Argus leds to avoid underscores
> * rename Belkin F5D8235 v1 leds from f5d8234 to f5d8235
> * remove Belkin F5D8235 v1 status led defined as storage led (it was
> defined as usb led earlier, just in wrong place) - it should have
> router led as in v2
> * add Argus, Sparklan and Belkin F5D8235 v2 status leds
> * add Belkin F5D8235 v1 and v2 usb leds
> * fix Belkin F5D8235 v2 network config generation and mac address axtraction
> * fix Sparklan board identification
> * add Sparklan usb led (this board doesn't have usb connector by
> default and the led is hidden also but if you are going to solder the
> connector then you'll see the led too)
> * add Sparklan network config generation and mac address extraction
> * fix empty string test in network script and...
> * ...sort case entries by the first board in the list
> 
> Adding an attachment too in case inline version is mangled.
> 
> Signed-off-by: Roman Yeryomin 

Applied.

Thanks,
Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] sysupgrade for ESR-9753

[Gabor Juhos]

2012.01.15. 12:00 keltezéssel, Artur Wronowski írta:
> This patch add sysupgrade for Engenius ESR-9753
> 
> Signed-off-by: Artur Wronowski 

Applied.

Thanks,
Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] Initial DSL framework for Lantiq

[John Crispin]

applied in r29881

thanks
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ltq_dsl_app support for taking pppoa link up and down

[John Crispin]

this patch is folded into the other dsl framework patch.

thnaks for testing,
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] New package dstat

[Roberto Riggio]

No, it is the same version. The version from the 20th wasn't in my 
outgoing mail box, so i thought that it was not sent. Sorry for the 
confusion.


R.

On 23/01/2012 19:13, Jo-Philipp Wich wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

is there any difference to the version from 20th?
As far as I can see it is identical just that this one got mangled by
your mailer.

~ Jow
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8do0wACgkQdputYINPTPPcfgCfYztDILCGjltCqar0SUz/cL9s
UbkAn3anNkgk8z3GsPo5A6afafGW6Pxo
=I2Jf
-END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



--

Roberto Riggio, Ph.D.
CREATE-NET
Network & Security Solutions for Pervasive Computing Systems (iNSPIRE)
Senior Researcher
Via alla Cascata 56/D - 38123 Povo Trento (Italy)
e-mail: roberto.rig...@create-net.org
Tel: (+39) 0461 408400 - interno/extension 708
Fax: (+39) 0461 421157
www.create-net.org/~rriggio


The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited according to
the Italian Law 196/2003 of the Legislature. If you received this in
error, please contact the sender and delete the material from any
computer.

Le informazioni contenute in questo messaggio di posta elettronica e nei
file allegati sono da considerarsi strettamente riservate. Il loro
utilizzo e' consentito esclusivamente al destinatario del messaggio, per
le finalita' indicate nel messaggio stesso. Qualora riceveste questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla cancellazione del
messaggio stesso dal Vostro sistema. Trattenere il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo,
od utilizzarlo per finalita' diverse, costituisce comportamento
contrario ai principi dettati dal D. Lgs. 196/2003.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!

[Dave Taht]

On Mon, Jan 23, 2012 at 8:33 PM, Felix Fietkau  wrote:
> As you've probably noticed, we've had issues keeping up with the
> workload of incoming patches.
> There is quite a bit of work involved in taking care of incoming
> patches, not just review. Patches need to be compile tested, ideally
> also runtime tested, and checked for dependency issues. Most of the
> time, this work is left up to the limited number of people that have SVN
> access. People often complain that it's hard to get involved, because it
> takes a long time to get SVN access, and the rules for that may not
> always be clear.
>
> In my opinion, the main issue is not that we don't give out SVN access
> fast enough, it's that people consider SVN access necessary for
> contributing in the first place. If we change the way patches are
> accepted to no longer depend on that, it becomes much easier for people
> to start.
>
> To be able to do that properly, it is important that patches still get
> reviewed and tested, but we can decentralize this work to split it up
> among a bigger group.
>
> One way to do this would be to have a group of people - with or without
> SVN access - maintaining a git tree with proposed changes to /trunk or
> /packages. This tree should be frequently rebased to latest SVN.
> This allows any developer with SVN access to spend a few minutes a day
> looking over the tree, giving it a quick sanity check, and then flushing
> all changes into SVN.
> With proper care by the tree maintainers, author attribution and review
> annotations can be easily put into the commit messages to ensure that
> they are preserved during the commit to SVN.
>
> With such a tree, the typical lifetime of a patch could look somewhat
> like this:
>
> - User proposes a patch on the list.
> - Core developer does a superficial review on patchwork, assigns it to
> the patch team, possibly with comments on what to test or look out for
> - Somebody from the patch team picks up the patch, tests it, ACKs it.
> - Patch gets added to the proposed-changes tree.
> - A developer with SVN access flushes the proposed-changes tree into SVN.
>
> One nice thing about this workflow is that aside from a few scripts to
> simplify dealing with constantly rebased git trees, we have all the
> tools we need to implement this.
>
> Does this proposal make sense? Do we have any volunteers that are
> willing to organize and take care of maintaining the tree and compile
> testing and reviewing the incoming changes?

If there is a process like that in place I'll gladly participate on the arches
I am working on, notably the ag71xx, and perhaps one day guruplug and
x86 and kvm. I do try to test things thoroughly - sometimes too thoroughly,
I have something of a backlog.

My principal critique of this workflow is that I tend to view svn as part
of the problem to a large extent. If I do a patch in my own (git) tree
to test with, I invariably have to rebase that tree when it comes down
from svn.

as I am frequently offline, not being able to do a 'svn log' is the
second deal-killer for me, for svn usage.

I can see what you propose as being an incremental improvement
on what currently exists, and can live with it, however.

A second, large problem (in my mind), is that I would like to find a
process for getting stuff upstream into the mainline kernel. The
latest patch set for the 71xx is something like 84 files and 120+
patches, and most of that is stuff that is unchanged for the past year.

Most of what I worked on last quarter got developed in the net-next
git tree,  and backported and then tested on cerowrt.

>
> - Felix
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel