Re: [OpenWrt-Devel] [PATCH] Add package for Command Line Interface SHell

2012-03-02 Thread Viktar Palstsiuk
On Fri, Mar 2, 2012 at 12:37 AM, Outback Dingo outbackdi...@gmail.com wrote:
 On Tue, Feb 28, 2012 at 10:17 AM, Viktar Palstsiuk
 viktar.palsts...@promwad.com wrote:
 Signed-off-by: Viktar Palstsiuk viktar.palsts...@promwad.com
 ---
  utils/clish/Makefile |   44 
  1 files changed, 44 insertions(+), 0 deletions(-)
  create mode 100644 utils/clish/Makefile

 diff --git a/utils/clish/Makefile b/utils/clish/Makefile
 new file mode 100644
 index 000..78f6ae2
 --- /dev/null
 +++ b/utils/clish/Makefile
 @@ -0,0 +1,44 @@
 +#
 +# Copyright (C) 2012 OpenWrt.org
 +#
 +# This is free software, licensed under the GNU General Public License v2.
 +# See /LICENSE for more information.
 +#
 +
 +include $(TOPDIR)/rules.mk
 +
 +PKG_NAME:=clish
 +PKG_VERSION:=0.7.3
 +PKG_RELEASE:=1
 +
 +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 +PKG_SOURCE_URL:=@SF/$(PKG_NAME)
 +PKG_MD5SUM:=81e20f7a888bcd8e2280e37804d342e4
 +
 +PKG_INSTALL:=1
 +
 +include $(INCLUDE_DIR)/package.mk
 +
 +define Package/clish
 +  SECTION:=utils
 +  CATEGORY:=Utilities
 +  DEPENDS:=+libstdcpp
 +  TITLE:=Command Line Interface SHell
 +  URL:=http://clish.sourceforge.net/
 +endef
 +
 +define Package/clish/description
 + A modular framework for implementing a CISCO-like CLI on a *NIX system.
 + Arbitary command menus and actions can be defined using XML files.
 + This software handles the user interaction,
 + and forks the appropriate system commands to perform any actions.
 +endef
 +
 +define Package/clish/install
 +       $(INSTALL_DIR) $(1)/usr/bin
 +       $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/* $(1)/usr/bin/
 +       $(INSTALL_DIR) $(1)/usr/lib
 +       $(CP) $(PKG_INSTALL_DIR)/usr/lib/*.so* $(1)/usr/lib/
 +endef
 +
 +$(eval $(call BuildPackage,clish))
 --
 1.7.9


 Im willing to commit this, but it would help if you added some basic
 configuration files for users, even if minimal to the package built
 as to give users a start on creating their custom configurations


 ___
 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

clish tar ball already has some configuration file examples which can
be installed to the /etc/clish/

diff --git a/utils/clish/Makefile b/utils/clish/Makefile
index 78f6ae2..1a7d3e0 100644
--- a/utils/clish/Makefile
+++ b/utils/clish/Makefile
@@ -39,6 +39,8 @@ define Package/clish/install
$(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/* $(1)/usr/bin/
$(INSTALL_DIR) $(1)/usr/lib
$(CP) $(PKG_INSTALL_DIR)/usr/lib/*.so* $(1)/usr/lib/
+   $(INSTALL_DIR) $(1)/etc/clish
+   $(CP) $(PKG_BUILD_DIR)/xml-examples/*.xml $(1)/etc/clish/
 endef

 $(eval $(call BuildPackage,clish))

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


Re: [OpenWrt-Devel] [PATCH] BCMA - Find names of non BCM cores

2012-03-02 Thread Rafał Miłecki
2012/3/2 Nathan Hintz nlhi...@hotmail.com:
 Support recognition of MIPS 74K CPU, etc.

 [    0.00] bcma: Core 3 found: MIPS 74K (manuf 0x4A7, id 0x82C, rev 0x01, 
 class 0x0)

 Signed-off-by: Nathan Hintz nlhi...@hotmail.com

 --- /dev/null   2012-02-21 01:00:44.969496803 -0800
 +++ target/linux/brcm47xx/patches-3.2/0050-bcma-find-name-for-non-brcm.patch  
   2011-07-02 16:50:16.0 -0700
 @@ -0,0 +1,17 @@
 +--- a/drivers/bcma/scan.c
  b/drivers/bcma/scan.c
 +@@ -83,11 +83,9 @@
 + {
 +       int i;
 +
 +-      if (id-manuf == BCMA_MANUF_BCM) {
 +-              for (i = 0; i  ARRAY_SIZE(bcma_device_names); i++) {
 +-                      if (bcma_device_names[i].id == id-id)
 +-                              return bcma_device_names[i].name;
 +-              }
 ++      for (i = 0; i  ARRAY_SIZE(bcma_device_names); i++) {
 ++              if (bcma_device_names[i].id == id-id)
 ++                      return bcma_device_names[i].name;

Maybe you should just make use of:
/* Core manufacturers */
#define BCMA_MANUF_ARM  0x43B
#define BCMA_MANUF_MIPS 0x4A7
#define BCMA_MANUF_BCM  0x4BF
rather than dropping the check.

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


Re: [OpenWrt-Devel] MSS clamping in POSTROUTING instead of FORWARD?

2012-03-02 Thread Ashok Rao
I don't see why moving the clamping to POSTROUTING causes the hiding of
issues inside openwrt. The example presented by Etienne is perfectly valid
and the suggestion to mpve the clamping to the POSTROUTING chain seems the
right way to go when you have multiple interfaces that could be used for a
packet.

I think this could be submitted as a ticket and we could let the developers
decide.  The other option of course is to add this to only the multiwan
package.

Ashok
On Wed, Feb 22, 2012 at 2:24 PM, Oliver
oli...@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa wrote:

 On Wednesday 22 Feb 2012 10:09:09 Philip Prindeville wrote:
  I actually don't think that.
 
  I'm just pointing out that in corner cases, being overly conservative
  will increase your chances of success.

 Correct, but it does so by essentially alleviating the symptom of an
 underlying problem; since this change would be a great way of hiding any
 underlying TCP issues inside OpenWRT itself, I'm firmly against this idea -
 we should fix the root cause of a problem, not its symptoms.
  ___
 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] Alix 2D13 on latest trunk, traces in dmesg on bootup?

2012-03-02 Thread Adam Gensler
Went up to kernel version 3.2.5, problem still occurs. Above 3.2.5 
requires refreshing the kernel patches.



On 2/29/12 11:18 PM, Adam Gensler wrote:

For what its worth I spent some time this evening putting together a
Fedora Core 16 virtual machine to test with. I pulled a fresh copy of
trunk and built the alix2 target and got the same traces on boot up.

At this point I'm sure the issue isn't with my build environment but is
an issue in trunk. Unfortunately my kernel-debugging-foo isn't strong
enough to move closer to resolution.


On 2/28/12 7:09 PM, Adam Gensler wrote:

Nothing I'm finding online seems to indicate a simple procedure for
this. Perhaps I'm not searching for the correct terminology. If you have
a sample / example I'd certainly take a look at doing it.


On 2/28/12 5:12 PM, Philip Prindeville wrote:

As it turns out you only need 2-3 commands... you can almost script it
with macros.


On 2/28/12 2:17 PM, Adam Gensler wrote:

Unfortunately I have zero experience with gdb. It would probably take
longer to learn how to use that than to refresh to the kernel
patches on
3.2 to support 3.2.7 so I could try that version to see if its already
fixed.

___
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

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


Re: [OpenWrt-Devel] [PATCH] Add package for Command Line Interface SHell

2012-03-02 Thread Outback Dingo
On Fri, Mar 2, 2012 at 3:33 AM, Viktar Palstsiuk
viktar.palsts...@promwad.com wrote:
 On Fri, Mar 2, 2012 at 12:37 AM, Outback Dingo outbackdi...@gmail.com wrote:
 On Tue, Feb 28, 2012 at 10:17 AM, Viktar Palstsiuk
 viktar.palsts...@promwad.com wrote:
 Signed-off-by: Viktar Palstsiuk viktar.palsts...@promwad.com
 ---
  utils/clish/Makefile |   44 
  1 files changed, 44 insertions(+), 0 deletions(-)
  create mode 100644 utils/clish/Makefile

 diff --git a/utils/clish/Makefile b/utils/clish/Makefile
 new file mode 100644
 index 000..78f6ae2
 --- /dev/null
 +++ b/utils/clish/Makefile
 @@ -0,0 +1,44 @@
 +#
 +# Copyright (C) 2012 OpenWrt.org
 +#
 +# This is free software, licensed under the GNU General Public License v2.
 +# See /LICENSE for more information.
 +#
 +
 +include $(TOPDIR)/rules.mk
 +
 +PKG_NAME:=clish
 +PKG_VERSION:=0.7.3
 +PKG_RELEASE:=1
 +
 +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 +PKG_SOURCE_URL:=@SF/$(PKG_NAME)
 +PKG_MD5SUM:=81e20f7a888bcd8e2280e37804d342e4
 +
 +PKG_INSTALL:=1
 +
 +include $(INCLUDE_DIR)/package.mk
 +
 +define Package/clish
 +  SECTION:=utils
 +  CATEGORY:=Utilities
 +  DEPENDS:=+libstdcpp
 +  TITLE:=Command Line Interface SHell
 +  URL:=http://clish.sourceforge.net/
 +endef
 +
 +define Package/clish/description
 + A modular framework for implementing a CISCO-like CLI on a *NIX system.
 + Arbitary command menus and actions can be defined using XML files.
 + This software handles the user interaction,
 + and forks the appropriate system commands to perform any actions.
 +endef
 +
 +define Package/clish/install
 +       $(INSTALL_DIR) $(1)/usr/bin
 +       $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/* $(1)/usr/bin/
 +       $(INSTALL_DIR) $(1)/usr/lib
 +       $(CP) $(PKG_INSTALL_DIR)/usr/lib/*.so* $(1)/usr/lib/
 +endef
 +
 +$(eval $(call BuildPackage,clish))
 --
 1.7.9


 Im willing to commit this, but it would help if you added some basic
 configuration files for users, even if minimal to the package built
 as to give users a start on creating their custom configurations


 ___
 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

 clish tar ball already has some configuration file examples which can
 be installed to the /etc/clish/

 diff --git a/utils/clish/Makefile b/utils/clish/Makefile
 index 78f6ae2..1a7d3e0 100644
 --- a/utils/clish/Makefile
 +++ b/utils/clish/Makefile
 @@ -39,6 +39,8 @@ define Package/clish/install
        $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/* $(1)/usr/bin/
        $(INSTALL_DIR) $(1)/usr/lib
        $(CP) $(PKG_INSTALL_DIR)/usr/lib/*.so* $(1)/usr/lib/
 +       $(INSTALL_DIR) $(1)/etc/clish
 +       $(CP) $(PKG_BUILD_DIR)/xml-examples/*.xml $(1)/etc/clish/
  endef

  $(eval $(call BuildPackage,clish))

 --
 Best regards,
 Viktar Palstsiuk

Committed revision 30788.


 ___
 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] Makefile for asterisk-1.8 channel driver chan-sccp-b

2012-03-02 Thread Diederik de Groot
This package provides a replacement channel driver for asterisk's 
chan_skinny.


With extended functionality and feature support (shared lines, realtime 
config, custom device state and more). You can find more information 
about chan-sccp-b on http://chan-sccp-b.sourceforge.net and 
http://sourceforge.net/projects/chan-sccp-b.


Provided Makefile, Patches and Config files have been tested. Currently 
uses a direct download from svn repository (trunk), but could be changed 
to use a specific revision posted in tags, if required. I wasn't a 100% 
sure if i should create a new package in packages or in 
package/feeds/packages.


Signed-off-by: Diederik de Grootddegr...@users.sourceforge.net

---
Index: package/asterisk18-chan-sccp-b/files/sccp.openwrt.conf
===
--- package/asterisk18-chan-sccp-b/files/sccp.openwrt.conf(revision 0)
+++ package/asterisk18-chan-sccp-b/files/sccp.openwrt.conf(revision 0)
@@ -0,0 +1,89 @@
+[general]
+servername = Openwrt
+keepalive = 60
+debug = core
+context = default
+dateformat = D/M/Y
+bindaddr = 192.168.1.1
+port = 2000
+disallow=all
+allow=ulaw
+allow=alaw
+allow=gsm
+firstdigittimeout = 16
+digittimeout = 6
+autoanswer_ring_time = 1
+musicclass=default
+language=en
+deny=0.0.0.0/0.0.0.0
+permit=192.168.1.0/255.255.255.0
+protocolversion=17
+
+hotline_enabled=yes
+hotline_context=default
+hotline_extension=111
+
+[SEP001122334455]
+type = device
+description = Phone Number One
+devicetype = 7940
+button = line, 111
+button = line, 113@01:shared
+button = speeddial,Phone 2 Line 1, 112, 112@hint
+
+[SEP00a1a2a3a4a5]
+type = device
+description = Phone Number Two
+devicetype = 7960
+button = line, 112
+button = line, 113@01:shared
+button = speeddial,Phone 1 Line 1, 111, 111@hint
+
+[111]
+id = 1000
+type = line
+pin = 1234
+label = Phone 1 Line 1
+description = Line 111
+mailbox = 10111
+cid_name = Phone 1 CID
+cid_num = 111
+accountcode=79111
+callgroup=1
+pickupgroup=1
+context = default
+incominglimit = 2
+vmnum = 600
+trnsfvm = 1000
+
+[112]
+id = 1001
+type = line
+pin = 1234
+label = Phone 2 Line 1
+description = Line 112
+mailbox = 10112
+cid_name = Phone 2 CID
+cid_num = 112
+accountcode=79112
+callgroup=1
+pickupgroup=1
+context = default
+incominglimit = 2
+vmnum = 600
+trnsfvm = 1000
+
+[113]
+id = 1002
+type = line
+pin = 1234
+label = SharedLine 1
+description = Line 113
+mailbox = 10113
+cid_name = Shared
+cid_num = 113
+accountcode=79113
+incominglimit = 2
+vmnum = 600
+trnsfvm = 1000
+
Index:
package/asterisk18-chan-sccp-b/patches/200-register-file-version.patch
===
---
package/asterisk18-chan-sccp-b/patches/200-register-file-version.patch
(revision
0)
+++
package/asterisk18-chan-sccp-b/patches/200-register-file-version.patch
(revision
0)
@@ -0,0 +1,19 @@
+--- a/src/chan_sccp.h
 b/src/chan_sccp.h
+@@ -172,15 +172,7 @@
+ #define CHECK_LEAKS()
+ #endif
+
+-#define SCCP_FILE_VERSION(file, version) \
+-static void __attribute__((constructor))
__register_file_version(void) \
+-{ \
+-pbx_register_file_version(file, version); \
+-} \
+-static void __attribute__((destructor))
__unregister_file_version(void) \
+-{ \
+-pbx_unregister_file_version(file); \
+-}
++#define SCCP_FILE_VERSION(file, version)
+
+ #define DEV_ID_LOG(x) x ? x-id : SCCP
+
Index: package/asterisk18-chan-sccp-b/Makefile
===
--- package/asterisk18-chan-sccp-b/Makefile(revision 0)
+++ package/asterisk18-chan-sccp-b/Makefile(revision 0)
@@ -0,0 +1,70 @@
+#
+# Copyright (C) 2006 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=asterisk18-chan-sccp-b
+# associated with asterisk version
+PKG_VERSION:=1.8.8.0
+# chan-sccp-b version
+PKG_RELEASE:=V4.0.0
+
+# SVN
+PKG_REV=2797
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
+PKG_SOURCE_URL:=https://chan-sccp-b.svn.sourceforge.net/svnroot/chan-sccp-b/trunk

+PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
+PKG_SOURCE_VERSION:=$(PKG_REV)
+PKG_SOURCE_PROTO:=svn
+
+PKG_FIXUP:=libtool
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/asterisk18-chan-sccp-b
+  SUBMENU:=Telephony
+  SECTION:=net
+  CATEGORY:=Network
+  TITLE:=SCCP channel provider for asterisk
+  URL:=http://chan-sccp-b.net.sourceforge.net/
+  MAINTAINER:=Diederik de Grootddegr...@users.sourceforge.net
+  DEPENDS:=+asterisk18 @!TARGET_avr32
+  PROVIDES:=chan-sccp-b
+  MENU:=1
+endef
+
+define Package/asterisk18-chan-sccp-b/Default/description
+ SCCP channel provider for asterisk. It delivers extended functionality
for SCCP phones over chan_skinny delivered
+ by asterisk by default.
+endef
+
+define Build/Configure
+(cd $(PKG_BUILD_DIR); \
+$(TARGET_CONFIGURE_OPTS) \
+

Re: [OpenWrt-Devel] [PATCH] BCMA - Find names of non BCM cores

2012-03-02 Thread Nathan Hintz
On Fri, 2012-03-02 at 10:20 +0100, Rafał Miłecki wrote:
 2012/3/2 Nathan Hintz nlhi...@hotmail.com:
  Support recognition of MIPS 74K CPU, etc.
 
  [0.00] bcma: Core 3 found: MIPS 74K (manuf 0x4A7, id 0x82C, rev 
  0x01, class 0x0)
 
  Signed-off-by: Nathan Hintz nlhi...@hotmail.com
 
  --- /dev/null   2012-02-21 01:00:44.969496803 -0800
  +++ 
  target/linux/brcm47xx/patches-3.2/0050-bcma-find-name-for-non-brcm.patch
  2011-07-02 16:50:16.0 -0700
  @@ -0,0 +1,17 @@
  +--- a/drivers/bcma/scan.c
   b/drivers/bcma/scan.c
  +@@ -83,11 +83,9 @@
  + {
  +   int i;
  +
  +-  if (id-manuf == BCMA_MANUF_BCM) {
  +-  for (i = 0; i  ARRAY_SIZE(bcma_device_names); i++) {
  +-  if (bcma_device_names[i].id == id-id)
  +-  return bcma_device_names[i].name;
  +-  }
  ++  for (i = 0; i  ARRAY_SIZE(bcma_device_names); i++) {
  ++  if (bcma_device_names[i].id == id-id)
  ++  return bcma_device_names[i].name;
 
 Maybe you should just make use of:
 /* Core manufacturers */
 #define BCMA_MANUF_ARM0x43B
 #define BCMA_MANUF_MIPS   0x4A7
 #define BCMA_MANUF_BCM0x4BF
 rather than dropping the check.
 
Aren't we pretty much assured it is one of those three already?  It is
already known that at least some ID's are unique to a manufacturer,
maybe the manufacturer should be embedded in the bcma_device_names
table, along with a BCMA_MANUF_ANY for ones that are common.

Nathan

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


[OpenWrt-Devel] [PATCH] Add Patch in package/mac80211 for AP and Mesh to operate simultaneously in Single Radio

2012-03-02 Thread Yeoh Chun-Yeow
This patch allows the possibility of having the mesh point and AP to be
operated
simultaneously in one single radio. Previously, mesh point fails to
generate the
mesh beacon if virtual AP is created for the same radio.

Signed-off-by: Chun-Yeow Yeoh yeohchuny...@gmail.com
---
Index: package/mac80211/patches/900-ath5k_allow_mesh_and_ap.patch
===
--- package/mac80211/patches/900-ath5k_allow_mesh_and_ap.patch  (revision 0)
+++ package/mac80211/patches/900-ath5k_allow_mesh_and_ap.patch  (revision 0)
@@ -0,0 +1,52 @@
+--- a/drivers/net/wireless/ath/ath5k/ath5k.h
 b/drivers/net/wireless/ath/ath5k/ath5k.h
+@@ -1320,6 +1320,7 @@ struct ath5k_hw {
+   struct ieee80211_vif*bslot[ATH_BCBUF];
+   u16 num_ap_vifs;
+   u16 num_adhoc_vifs;
++  u16 num_mesh_vifs;
+   unsigned intbhalq,  /* SW q for outgoing
beacons */
+   bmisscount, /* missed beacon transmits
*/
+   bintval,/* beacon interval in TU */
+--- a/drivers/net/wireless/ath/ath5k/base.c
 b/drivers/net/wireless/ath/ath5k/base.c
+@@ -1867,7 +1867,8 @@ ath5k_beacon_send(struct ath5k_hw *ah)
+   ah-bmisscount = 0;
+   }
+
+-  if ((ah-opmode == NL80211_IFTYPE_AP  ah-num_ap_vifs +
ah-num_adhoc_vifs  1) ||
++  if ((ah-opmode == NL80211_IFTYPE_AP  ah-num_ap_vifs
++  + ah-num_adhoc_vifs + ah-num_mesh_vifs  1) ||
+   ah-opmode == NL80211_IFTYPE_MESH_POINT) {
+   u64 tsf = ath5k_hw_get_tsf64(ah);
+   u32 tsftu = TSF_TO_TU(tsf);
+@@ -1952,7 +1953,8 @@ ath5k_beacon_update_timers(struct ath5k_
+   u64 hw_tsf;
+
+   intval = ah-bintval  AR5K_BEACON_PERIOD;
+-  if (ah-opmode == NL80211_IFTYPE_AP  ah-num_ap_vifs +
ah-num_adhoc_vifs  1) {
++  if (ah-opmode == NL80211_IFTYPE_AP  ah-num_ap_vifs
++  + ah-num_mesh_vifs + ah-num_adhoc_vifs  1) {
+   intval /= ATH_BCBUF;/* staggered multi-bss beacons */
+   if (intval  15)
+   ATH5K_WARN(ah, intval %u is too low, min 15\n,
+--- a/drivers/net/wireless/ath/ath5k/mac80211-ops.c
 b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
+@@ -129,6 +129,8 @@ ath5k_add_interface(struct ieee80211_hw
+   ah-num_ap_vifs++;
+   else if (avf-opmode == NL80211_IFTYPE_ADHOC)
+   ah-num_adhoc_vifs++;
++  else if (avf-opmode == NL80211_IFTYPE_MESH_POINT)
++  ah-num_mesh_vifs++;
+   }
+
+   /* Any MAC address is fine, all others are included through the
+@@ -170,6 +172,8 @@ ath5k_remove_interface(struct ieee80211_
+   ah-num_ap_vifs--;
+   else if (avf-opmode == NL80211_IFTYPE_ADHOC)
+   ah-num_adhoc_vifs--;
++  else if (avf-opmode == NL80211_IFTYPE_MESH_POINT)
++  ah-num_mesh_vifs--;
+
+   ath5k_update_bssid_mask_and_opmode(ah, NULL);
+   mutex_unlock(ah-lock);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] Add Patch in package/mac80211 for AP and Mesh to operate simultaneously in Single Radio

2012-03-02 Thread Yeoh Chun-Yeow
Hi, all

This is mainly for ath5k.

Regards,
Chun-Yeow

On Sat, Mar 3, 2012 at 12:50 AM, Yeoh Chun-Yeow yeohchuny...@gmail.comwrote:

 This patch allows the possibility of having the mesh point and AP to be
 operated
 simultaneously in one single radio. Previously, mesh point fails to
 generate the
 mesh beacon if virtual AP is created for the same radio.

 Signed-off-by: Chun-Yeow Yeoh yeohchuny...@gmail.com
 ---
 Index: package/mac80211/patches/900-ath5k_allow_mesh_and_ap.patch
 ===
 --- package/mac80211/patches/900-ath5k_allow_mesh_and_ap.patch  (revision
 0)
 +++ package/mac80211/patches/900-ath5k_allow_mesh_and_ap.patch  (revision
 0)
 @@ -0,0 +1,52 @@
 +--- a/drivers/net/wireless/ath/ath5k/ath5k.h
  b/drivers/net/wireless/ath/ath5k/ath5k.h
 +@@ -1320,6 +1320,7 @@ struct ath5k_hw {
 +   struct ieee80211_vif*bslot[ATH_BCBUF];
 +   u16 num_ap_vifs;
 +   u16 num_adhoc_vifs;
 ++  u16 num_mesh_vifs;
 +   unsigned intbhalq,  /* SW q for outgoing
 beacons */
 +   bmisscount, /* missed beacon transmits
 */
 +   bintval,/* beacon interval in TU */
 +--- a/drivers/net/wireless/ath/ath5k/base.c
  b/drivers/net/wireless/ath/ath5k/base.c
 +@@ -1867,7 +1867,8 @@ ath5k_beacon_send(struct ath5k_hw *ah)
 +   ah-bmisscount = 0;
 +   }
 +
 +-  if ((ah-opmode == NL80211_IFTYPE_AP  ah-num_ap_vifs +
 ah-num_adhoc_vifs  1) ||
 ++  if ((ah-opmode == NL80211_IFTYPE_AP  ah-num_ap_vifs
 ++  + ah-num_adhoc_vifs + ah-num_mesh_vifs  1) ||
 +   ah-opmode == NL80211_IFTYPE_MESH_POINT) {
 +   u64 tsf = ath5k_hw_get_tsf64(ah);
 +   u32 tsftu = TSF_TO_TU(tsf);
 +@@ -1952,7 +1953,8 @@ ath5k_beacon_update_timers(struct ath5k_
 +   u64 hw_tsf;
 +
 +   intval = ah-bintval  AR5K_BEACON_PERIOD;
 +-  if (ah-opmode == NL80211_IFTYPE_AP  ah-num_ap_vifs +
 ah-num_adhoc_vifs  1) {
 ++  if (ah-opmode == NL80211_IFTYPE_AP  ah-num_ap_vifs
 ++  + ah-num_mesh_vifs + ah-num_adhoc_vifs  1) {
 +   intval /= ATH_BCBUF;/* staggered multi-bss beacons */
 +   if (intval  15)
 +   ATH5K_WARN(ah, intval %u is too low, min 15\n,
 +--- a/drivers/net/wireless/ath/ath5k/mac80211-ops.c
  b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
 +@@ -129,6 +129,8 @@ ath5k_add_interface(struct ieee80211_hw
 +   ah-num_ap_vifs++;
 +   else if (avf-opmode == NL80211_IFTYPE_ADHOC)
 +   ah-num_adhoc_vifs++;
 ++  else if (avf-opmode == NL80211_IFTYPE_MESH_POINT)
 ++  ah-num_mesh_vifs++;
 +   }
 +
 +   /* Any MAC address is fine, all others are included through the
 +@@ -170,6 +172,8 @@ ath5k_remove_interface(struct ieee80211_
 +   ah-num_ap_vifs--;
 +   else if (avf-opmode == NL80211_IFTYPE_ADHOC)
 +   ah-num_adhoc_vifs--;
 ++  else if (avf-opmode == NL80211_IFTYPE_MESH_POINT)
 ++  ah-num_mesh_vifs--;
 +
 +   ath5k_update_bssid_mask_and_opmode(ah, NULL);
 +   mutex_unlock(ah-lock);


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


Re: [OpenWrt-Devel] [PATCH] Add Patch in package/mac80211 for AP and Mesh to operate simultaneously in Single Radio

2012-03-02 Thread Jonathan Bither

Have you tried submitting this to linux-wireless?

On 03/02/2012 11:52 AM, Yeoh Chun-Yeow wrote:

Hi, all

This is mainly for ath5k.

Regards,
Chun-Yeow

On Sat, Mar 3, 2012 at 12:50 AM, Yeoh Chun-Yeow yeohchuny...@gmail.com
mailto:yeohchuny...@gmail.com wrote:

This patch allows the possibility of having the mesh point and AP to
be operated
simultaneously in one single radio. Previously, mesh point fails to
generate the
mesh beacon if virtual AP is created for the same radio.

Signed-off-by: Chun-Yeow Yeoh yeohchuny...@gmail.com
mailto:yeohchuny...@gmail.com
---
Index: package/mac80211/patches/900-ath5k_allow_mesh_and_ap.patch
===
--- package/mac80211/patches/900-ath5k_allow_mesh_and_ap.patch
(revision 0)
+++ package/mac80211/patches/900-ath5k_allow_mesh_and_ap.patch
(revision 0)
@@ -0,0 +1,52 @@
+--- a/drivers/net/wireless/ath/ath5k/ath5k.h
 b/drivers/net/wireless/ath/ath5k/ath5k.h
+@@ -1320,6 +1320,7 @@ struct ath5k_hw {
+   struct ieee80211_vif*bslot[ATH_BCBUF];
+   u16 num_ap_vifs;
+   u16 num_adhoc_vifs;
++  u16 num_mesh_vifs;
+   unsigned intbhalq,  /* SW q for outgoing
beacons */
+   bmisscount, /* missed beacon
transmits */
+   bintval,/* beacon interval
in TU */
+--- a/drivers/net/wireless/ath/ath5k/base.c
 b/drivers/net/wireless/ath/ath5k/base.c
+@@ -1867,7 +1867,8 @@ ath5k_beacon_send(struct ath5k_hw *ah)
+   ah-bmisscount = 0;
+   }
+
+-  if ((ah-opmode == NL80211_IFTYPE_AP  ah-num_ap_vifs +
ah-num_adhoc_vifs  1) ||
++  if ((ah-opmode == NL80211_IFTYPE_AP  ah-num_ap_vifs
++  + ah-num_adhoc_vifs + ah-num_mesh_vifs  1) ||
+   ah-opmode == NL80211_IFTYPE_MESH_POINT) {
+   u64 tsf = ath5k_hw_get_tsf64(ah);
+   u32 tsftu = TSF_TO_TU(tsf);
+@@ -1952,7 +1953,8 @@ ath5k_beacon_update_timers(struct ath5k_
+   u64 hw_tsf;
+
+   intval = ah-bintval  AR5K_BEACON_PERIOD;
+-  if (ah-opmode == NL80211_IFTYPE_AP  ah-num_ap_vifs +
ah-num_adhoc_vifs  1) {
++  if (ah-opmode == NL80211_IFTYPE_AP  ah-num_ap_vifs
++  + ah-num_mesh_vifs + ah-num_adhoc_vifs  1) {
+   intval /= ATH_BCBUF;/* staggered multi-bss
beacons */
+   if (intval  15)
+   ATH5K_WARN(ah, intval %u is too low, min 15\n,
+--- a/drivers/net/wireless/ath/ath5k/mac80211-ops.c
 b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
+@@ -129,6 +129,8 @@ ath5k_add_interface(struct ieee80211_hw
+   ah-num_ap_vifs++;
+   else if (avf-opmode == NL80211_IFTYPE_ADHOC)
+   ah-num_adhoc_vifs++;
++  else if (avf-opmode == NL80211_IFTYPE_MESH_POINT)
++  ah-num_mesh_vifs++;
+   }
+
+   /* Any MAC address is fine, all others are included through the
+@@ -170,6 +172,8 @@ ath5k_remove_interface(struct ieee80211_
+   ah-num_ap_vifs--;
+   else if (avf-opmode == NL80211_IFTYPE_ADHOC)
+   ah-num_adhoc_vifs--;
++  else if (avf-opmode == NL80211_IFTYPE_MESH_POINT)
++  ah-num_mesh_vifs--;
+
+   ath5k_update_bssid_mask_and_opmode(ah, NULL);
+   mutex_unlock(ah-lock);




___
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] [PATCH] Add Patch in package/mac80211 for AP and Mesh to operate simultaneously in Single Radio

2012-03-02 Thread Yeoh Chun-Yeow
Hi, Jonathan,

Yes.

Regards,
Chun-Yeow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?

2012-03-02 Thread Philip Prindeville
This should be on a Wiki page if it's not already...  Haven't had time to look.

On your build host, you would start gdb on your image.

On my machine, I do this as:

% gdb
(gdb) build_dir/linux-x86_alix2/linux-3.2.2

and I open the kernel:

(gdb) file vmlinux

then I look at the contents of /proc/modules on my target (# cat 
/proc/modules), example:

...
cs5535_mfgpt 2054 2 geodewdt,cs5535_clockevt,[permanent], Live 0xd0df7000
cs5535_mfd 1548 0 - Live 0xd0ded000
mfd_core 1616 1 cs5535_mfd, Live 0xd0de3000
...

unfortunately, we don't have modinfo on the target, or you could just do:

# modinfo mfd_core | awk '/^filename:/ { print $2; }'

to get the paths to the modules...  But it's not that hard to divine them. 
Remembering that _ in a module name is usually - in a filename, I get:

drivers/mfd/mfd-core.ko

as the path of the 3rd module.  I then do:

(gdb) add-symbol-file drivers/mfd/mfd-core.o 0xd0de3000
add symbol table from file drivers/mfd/mfd-core.o at
.text_addr = 0xd0de3000
(y or n) y
Reading symbols from 
/home/philipp/openwrt-alix/build_dir/linux-x86_alix2/linux-3.2.2/drivers/mfd/mfd-core.o...(no
 debugging symbols found)...done.
(gdb) directory drivers/mfd

to add the module's symbols (note the use of the .o file and not the .ko!), and 
to put the directory containing the sources into the search path.

And if I had a crash at 0xd0de32b2, I can do:

(gdb) list *(0xd0de32b2)
0xd0de32b2 is in mfd_remove_devices (drivers/mfd/mfd-core.c:202).
197 
198 void mfd_remove_devices(struct device *parent)
199 {
200 atomic_t *cnts = NULL;
201 
202 device_for_each_child(parent, cnts, mfd_remove_devices_fn);
203 kfree(cnts);
204 }
205 EXPORT_SYMBOL(mfd_remove_devices);
206 


and I get the line the crash was at.  Hopefully this helps.

It would be neat to have a script that one could paste /proc/modules into and a 
stack trace that did this for us...


On 3/2/12 7:25 AM, Adam Gensler wrote:
 Went up to kernel version 3.2.5, problem still occurs. Above 3.2.5 
 requires refreshing the kernel patches.
 
 
 On 2/29/12 11:18 PM, Adam Gensler wrote:
 For what its worth I spent some time this evening putting together a
 Fedora Core 16 virtual machine to test with. I pulled a fresh copy of
 trunk and built the alix2 target and got the same traces on boot up.

 At this point I'm sure the issue isn't with my build environment but is
 an issue in trunk. Unfortunately my kernel-debugging-foo isn't strong
 enough to move closer to resolution.


 On 2/28/12 7:09 PM, Adam Gensler wrote:
 Nothing I'm finding online seems to indicate a simple procedure for
 this. Perhaps I'm not searching for the correct terminology. If you have
 a sample / example I'd certainly take a look at doing it.


 On 2/28/12 5:12 PM, Philip Prindeville wrote:
 As it turns out you only need 2-3 commands... you can almost script it
 with macros.


 On 2/28/12 2:17 PM, Adam Gensler wrote:
 Unfortunately I have zero experience with gdb. It would probably take
 longer to learn how to use that than to refresh to the kernel
 patches on
 3.2 to support 3.2.7 so I could try that version to see if its already
 fixed.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?

2012-03-02 Thread Philip Prindeville
Sorry, cut and paste error.  The first gdb command should have read:

(gdb) cd build_dir/linux-x86_alix2/linux-3.2.2


On 3/2/12 12:26 PM, Philip Prindeville wrote:
 This should be on a Wiki page if it's not already...  Haven't had time to 
 look.
 
 On your build host, you would start gdb on your image.
 
 On my machine, I do this as:
 
 % gdb
 (gdb) build_dir/linux-x86_alix2/linux-3.2.2
 
 and I open the kernel:
 
 (gdb) file vmlinux
 
 then I look at the contents of /proc/modules on my target (# cat 
 /proc/modules), example:
 
 ...
 cs5535_mfgpt 2054 2 geodewdt,cs5535_clockevt,[permanent], Live 0xd0df7000
 cs5535_mfd 1548 0 - Live 0xd0ded000
 mfd_core 1616 1 cs5535_mfd, Live 0xd0de3000
 ...
 
 unfortunately, we don't have modinfo on the target, or you could just do:
 
 # modinfo mfd_core | awk '/^filename:/ { print $2; }'
 
 to get the paths to the modules...  But it's not that hard to divine them. 
 Remembering that _ in a module name is usually - in a filename, I get:
 
 drivers/mfd/mfd-core.ko
 
 as the path of the 3rd module.  I then do:
 
 (gdb) add-symbol-file drivers/mfd/mfd-core.o 0xd0de3000
 add symbol table from file drivers/mfd/mfd-core.o at
   .text_addr = 0xd0de3000
 (y or n) y
 Reading symbols from 
 /home/philipp/openwrt-alix/build_dir/linux-x86_alix2/linux-3.2.2/drivers/mfd/mfd-core.o...(no
  debugging symbols found)...done.
 (gdb) directory drivers/mfd
 
 to add the module's symbols (note the use of the .o file and not the .ko!), 
 and to put the directory containing the sources into the search path.
 
 And if I had a crash at 0xd0de32b2, I can do:
 
 (gdb) list *(0xd0de32b2)
 0xd0de32b2 is in mfd_remove_devices (drivers/mfd/mfd-core.c:202).
 197   
 198   void mfd_remove_devices(struct device *parent)
 199   {
 200   atomic_t *cnts = NULL;
 201   
 202   device_for_each_child(parent, cnts, mfd_remove_devices_fn);
 203   kfree(cnts);
 204   }
 205   EXPORT_SYMBOL(mfd_remove_devices);
 206   
 
 
 and I get the line the crash was at.  Hopefully this helps.
 
 It would be neat to have a script that one could paste /proc/modules into and 
 a stack trace that did this for us...
 
 
 On 3/2/12 7:25 AM, Adam Gensler wrote:
 Went up to kernel version 3.2.5, problem still occurs. Above 3.2.5 
 requires refreshing the kernel patches.


 On 2/29/12 11:18 PM, Adam Gensler wrote:
 For what its worth I spent some time this evening putting together a
 Fedora Core 16 virtual machine to test with. I pulled a fresh copy of
 trunk and built the alix2 target and got the same traces on boot up.

 At this point I'm sure the issue isn't with my build environment but is
 an issue in trunk. Unfortunately my kernel-debugging-foo isn't strong
 enough to move closer to resolution.


 On 2/28/12 7:09 PM, Adam Gensler wrote:
 Nothing I'm finding online seems to indicate a simple procedure for
 this. Perhaps I'm not searching for the correct terminology. If you have
 a sample / example I'd certainly take a look at doing it.


 On 2/28/12 5:12 PM, Philip Prindeville wrote:
 As it turns out you only need 2-3 commands... you can almost script it
 with macros.


 On 2/28/12 2:17 PM, Adam Gensler wrote:
 Unfortunately I have zero experience with gdb. It would probably take
 longer to learn how to use that than to refresh to the kernel
 patches on
 3.2 to support 3.2.7 so I could try that version to see if its already
 fixed.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] BCMA - Reorder SPROM fill

2012-03-02 Thread Hauke Mehrtens
On 03/02/2012 06:01 AM, Nathan Hintz wrote:
 The SPROM is initialized in bcm47xx_fill_sprom, so move the call to 
 bcm47xx_fill_sprom_ethernet after it.
 
 Signed-off-by: Nathan Hintz nlhi...@hotmail.com
 
 Index: 
 target/linux/brcm47xx/patches-3.2/199-MIPS-BCM47XX-provide-sprom-to-bcma-bus.patch
 ===
 --- 
 target/linux/brcm47xx/patches-3.2/199-MIPS-BCM47XX-provide-sprom-to-bcma-bus.patch
 (revision 30770)
 +++ 
 target/linux/brcm47xx/patches-3.2/199-MIPS-BCM47XX-provide-sprom-to-bcma-bus.patch
 (working copy)
 @@ -66,13 +66,13 @@
  +bcm47xx_fill_sprom(out, prefix);
  +return 0;
  +} else if (bus-hosttype == BCMA_HOSTTYPE_SOC) {
 -+bcm47xx_fill_sprom_ethernet(out, NULL);
  +core = bcma_find_core(bus, BCMA_CORE_80211);
  +if (core) {
  +snprintf(prefix, sizeof(prefix), sb/%u/,
  + core-core_index);
  +bcm47xx_fill_sprom(out, prefix);
  +}
 ++bcm47xx_fill_sprom_ethernet(out, NULL);
  +return 0;
  +} else {
  +printk(KERN_WARNING bcm47xx: unable to fill SPROM for given 
 bustype.\n);

Why do you want to move this call? If there is a mac address stored with
the prefix (sb/1/) for this core we should take it in favor of the
general mac address without a prefix. In my device both addresses are
the same so it would not make a difference, but I haven't looked into
all nvrams.

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


Re: [OpenWrt-Devel] [PATCH] BCMA - Enable use of IRQ6

2012-03-02 Thread Hauke Mehrtens
On 03/02/2012 06:36 AM, Nathan Hintz wrote:
 
 Signed-off-by: Nathan Hintz nlhi...@hotmail.com
 
 --- /dev/null 2012-02-21 01:00:44.969496803 -0800
 +++ target/linux/brcm47xx/patches-3.2/0051-bcma-enable-irq6.patch 
 2011-07-25 11:20:35.030008484 -0700
 @@ -0,0 +1,29 @@
 +--- a/drivers/bcma/driver_mips.c
  b/drivers/bcma/driver_mips.c
 +@@ -74,7 +74,7 @@
 + return dev-core_index;
 + flag = bcma_aread32(dev, BCMA_MIPS_OOBSELOUTA30);
 + 
 +-return flag  0x1F;
 ++return (flag ? (flag  0x1F) : 0x3F);
 + }
 + 
 + /* Get the MIPS IRQ assignment for a specified device.
 +@@ -87,6 +87,8 @@
 + unsigned int irq;
 + 
 + irqflag = bcma_core_mips_irqflag(dev);
 ++if (irqflag == 0x3F)
 ++return 6;
 + 
 + for (irq = 1; irq = 4; irq++)
 + if (bcma_read32(mdev, BCMA_MIPS_MIPS74K_INTMASK(irq)) 
 +@@ -232,7 +234,7 @@
 + core-irq = 0;
 + else
 + core-irq = mips_irq + 2;
 +-if (core-irq  5)
 ++if (core-irq  6)
 + continue;
 + switch (core-id.id) {
 + case BCMA_CORE_PCI:
 

Why do you need the IRQ 6? The current code will not assign it to any
core on the devices I know of. On what device did you test your code? As
the Broadcom SDK doe not use this IRQ I am a little bit scared if it
will work on every device.

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


Re: [OpenWrt-Devel] [PATCH] BCMA - Account for variable PCI memory base/size

2012-03-02 Thread Hauke Mehrtens
On 03/02/2012 06:07 AM, Nathan Hintz wrote:
 Signed-off-by: Nathan Hintz nlhi...@hotmail.com
 
 Index: 
 target/linux/brcm47xx/patches-3.2/0040-bcma-add-PCIe-host-controller.patch
 ===
 --- 
 target/linux/brcm47xx/patches-3.2/0040-bcma-add-PCIe-host-controller.patch
 (revision 30770)
 +++ 
 target/linux/brcm47xx/patches-3.2/0040-bcma-add-PCIe-host-controller.patch
 (working copy)
 @@ -169,7 +169,7 @@
   int bcma_core_pci_irq_ctl(struct bcma_drv_pci *pc, struct bcma_device *core,
  --- a/drivers/bcma/driver_pci_host.c
  +++ b/drivers/bcma/driver_pci_host.c
 -@@ -2,13 +2,587 @@
 +@@ -2,13 +2,588 @@
* Broadcom specific AMBA
* PCI Core in hostmode
*
 @@ -662,8 +662,9 @@
  +/* Ok, ready to run, register it to the system.
  + * The following needs change, if we want to port hostmode
  + * to non-MIPS platform. */
 -+io_map_base = (unsigned long)ioremap_nocache(BCMA_SOC_PCI_MEM,
 -+ 0x0400);
 ++io_map_base = (unsigned 
 long)ioremap_nocache(pc_host-mem_resource.start,
 ++ pc_host-mem_resource.end -
 ++   
 pc_host-mem_resource.start + 1);
  +pc_host-pci_controller.io_map_base = io_map_base;
  +set_io_port_base(pc_host-pci_controller.io_map_base);
  +/* Give some time to the PCI controller to configure itself with the new
 
This patch looks good to me. I will test it soon.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel