[OpenWrt-Devel] [PATCH] netifd: Don't append 6rd dhcp option when iface6rd is empty
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
package/network/config/netifd/files/lib/netifd/proto/dhcp.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
b/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
index d4c483d..b042267 100755
--- a/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
+++ b/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
@@ -40,7 +40,7 @@ proto_dhcp_setup() {
[ $broadcast = 1 ] broadcast=-B || broadcast=
[ -n $clientid ] clientid=-x 0x3d:${clientid//:/} ||
clientid=-C
[ -n $iface6rd ] proto_export IFACE6RD=$iface6rd
- [ $iface6rd != 0 -a -f /lib/netifd/proto/6rd.sh ] append dhcpopts
-O 212
+ [ ${iface6rd:-0} != 0 -a -f /lib/netifd/proto/6rd.sh ] append
dhcpopts -O 212
[ -n $zone6rd ] proto_export ZONE6RD=$zone6rd
[ -n $zone ] proto_export ZONE=$zone
[ -n $mtu6rd ] proto_export MTU6RD=$mtu6rd
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] protobuf broken in BB
Hi all Sorry obconseil and John for the delay, my work priorities got shifted to other things... @John: good idea to ping me personally! ;) Am 06.11.2014 10:23, schrieb obconseil: Le 05/11/2014 22:43, Guillaume Déflache a écrit : Fine, but that's not the problem as I said before (see the very 1st quoted text in this message): *installing protoc at the right location* (that is .../build_dir/host/bin/protoc IIRC) is the problem. I checked that with our pre-BB snapshot it was installed where expected and that with the BB release it is not. You can try executing `make install` from the host build directory to convince yourself that that does what is required from the OpenWrt Makefile but currently missing in BB's. That's what I did and then the problem was gone. So you have to try using protoc to generate some source code files in order to really stumble on the problem. Apart from that everything works fine indeed. Oh. I admit I overlooked this in your previous message. Thanks. What about the attached patch ? I had no time to test it unfortunately but I made one myself (see below) in parallel to get something working for us internally. By the way, maybe somebody else could enlighten me on this but in BB, it seems that the host tools directory is .../staging_dir/host/bin rather than .../build_dir/host/bin . I have no .../build_dir/host/bin directory on my build tree. You are right, .../staging_dir/host/bin is correct: AFAICU only staging_dir/ sports global filesystem hierarchies for all packages with bin/, include/, lib/, ... (one for the host, two per compiled target for the toolchain and the device itself). The patch do install protoc in .../staging_dir/host/bin , along with all other programs like bison,... I think this is the correct thing to do, and that's also what I do in my patch. Since the snapshot we used previously PKG_USE_MIPS16:=0 also got added, does that mean we should also use that on all packages that compile Protocol Buffer generated code and/or link with the PB library? After a second though I think this line was to avoid an assembler error on some plateform. I still need to test the current compiler/assembler on a MIPS16 platform, but for now you can safely leave this line out for your platform. [...] I would have no objections to 2.6.1 if it also works for us too (I can test that at the same time). Yes, please test report : I would much better push upstream a patch with the newest version of protobuf. For us 2.6.0 and 2.5.0 definitely do not work (I think I also tested with 2.6.1, not sure anymore). When I made the patch I stumbled upon https://www.mail-archive.com/protobuf@googlegroups.com/msg10536.html (Re: [protobuf] Re: Issue 670 in protobuf: Not Able to compile protobuf for mips platform) which looks exactly like the problem I had. Alas I did not notify either of OpenWrt or protobuf of the others' problem then. I guess there was some kind of regression from 2.4.1, probably someone should point the upstream protobuf developers to this thread. What works for us is the patch below: - as I said only 2.4.1 worked - removing the src/google/protobuf/stubs/platform_macros.h patch chunk also did help *IIRC* - PKG_USE_MIPS16:=0 or 1 made no difference *IIRC* ##\brief protobuf 2.4.1 without MIPS16 ## ## For the full rationale see https://lists.openwrt.org/pipermail/openwrt-devel/2014-November/029107.html. ## ## This is a Git patch against GitHub OpenWrt's 'packages' feed v14.07. # diff --git a/libs/protobuf/Makefile b/libs/protobuf/Makefile index 1553a7e..1411a82 100644 --- a/libs/protobuf/Makefile +++ b/libs/protobuf/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=protobuf -PKG_VERSION:=2.5.0 +PKG_VERSION:=2.4.1 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=http://protobuf.googlecode.com/files -PKG_MD5SUM:=a72001a9067a4c2c4e0e836d0f92ece4 +PKG_MD5SUM:=ed436802019c9e1f40cc750eaf78f318 PKG_BUILD_DEPENDS:=protobuf/host PKG_USE_MIPS16:=0 @@ -38,14 +38,7 @@ define Package/protobuf/description of its internal RPC protocols and file formats. endef -define Host/Compile - $(MAKE) -C $(HOST_BUILD_DIR) -endef - -define Host/Install -endef - -CONFIGURE_ARGS += --with-protoc=$(HOST_BUILD_DIR)/src/protoc +CONFIGURE_ARGS += --with-protoc=$(STAGING_DIR_HOST)/bin/protoc define Build/InstallDev $(INSTALL_DIR) \ diff --git a/libs/protobuf/patches/001-mipseb-compile.patch b/libs/protobuf/patches/001-mipseb-compile.patch deleted file mode 100644 index 6eb0590..000 --- a/libs/protobuf/patches/001-mipseb-compile.patch +++ /dev/null @@ -1,11 +0,0 @@ a/src/google/protobuf/stubs/platform_macros.h -+++ b/src/google/protobuf/stubs/platform_macros.h -@@ -49,7 +49,7 @@ - #elif defined(__ARMEL__) - #define GOOGLE_PROTOBUF_ARCH_ARM 1 - #define GOOGLE_PROTOBUF_ARCH_32_BIT 1 --#elif defined(__MIPSEL__) -+#elif defined(__MIPSEL__) || defined(__MIPSEB__)
Re: [OpenWrt-Devel] [PATCH] netifd: Don't append 6rd dhcp option when iface6rd is empty
That change was actually intentional so 6rd is setup if its available unless you disable it with iface6rd=0. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] uboot-envtools: add carambola2 support
Signed-off-by: Alexander Couzens lyn...@fe80.eu --- package/boot/uboot-envtools/files/ar71xx | 1 + 1 file changed, 1 insertion(+) diff --git a/package/boot/uboot-envtools/files/ar71xx b/package/boot/uboot-envtools/files/ar71xx index 8084e01..5824af6 100644 --- a/package/boot/uboot-envtools/files/ar71xx +++ b/package/boot/uboot-envtools/files/ar71xx @@ -24,6 +24,7 @@ mr600v2 | \ om5p | \ tube2h | \ wndr3700 | \ +carambola2 | \ nbg6716) ubootenv_add_uci_config /dev/mtd1 0x0 0x1 0x1 ;; -- 2.1.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Autoneg problems with ar8216 on kernel 3.14 (related to ticket 17800)
On Oct 30, 2014 5:08 PM, Heiner Kallweit hkallwe...@gmail.com wrote:
Am 30.10.2014 um 07:22 schrieb Heiner Kallweit:
Am 30.10.2014 um 03:36 schrieb Florian Fainelli:
Le 28/10/2014 11:46, Heiner Kallweit a écrit :
After a little more thinking about it and looking at the code I
basically have two questions:
1.
Is it actually needed to exclude certain phy's in
ar8xxx_phy_config_aneg?
(At least for AR8327 it doesn't get called with an addr != 0 anyway)
Else we could remove ar8xxx_phy_config_aneg and directly register
genphy_config_aneg as
callback for autoneg configuration.
Address 0 is special, since this is a MDIO broadcast address that will
usually be handled by switches as write to all front-panel ports.
2.
Call sequence with regard to ar8216 is:
ar8216: ar8xxx_phy_probe
phy: phy_attach_direct
phy: phy_init_hw
ar8216: ar8xxx_phy_config_init
ar8216: ar8xxx_phy_config_aneg
ar8216 driver handles AR8327/AR8337 different from the other
supported switch types.
ar8xxx_start incl. more detailed configuration is called from
ar8xxx_phy_probe already.
For the other switch types it's called from ar8xxx_phy_config_init.
I wonder whether doing detailed configuration in the probe stage
might be too early.
phy_init_hw resets the switch anyway later.
Doing the detailed setup in ar8xxx_phy_config_init seems to be more
suited however
there might be good reason why it's handled the way it is.
I suppose that you could re-advertise auto-negotiation by calling
genphy_config_advert() in the config_init routine.
The actual problem is caused by BMCR_ANENABLE being cleared by the
reset in phy_init_hw.
As far as I can see genphy_config_advert doesn't bring back this flag.
What does genphy_config_aneg mainly do?
- call genphy_config_advert
- check if BMCR_ANENABLE is set
- if it's not, call genphy_restart_aneg
Therefore, to bring back BMCR_ANENABLE, we have to call
genphy_config_aneg or genphy_restart_aneg.
genphy_restart_aneg most likely is sufficient, however I don't see that
genphy_config_aneg
can do any harm if being called with addr == 0.
At least for me it works perfectly fine to call genphy_config_aneg for
all addr's.
Rgds, Heiner
Rgds,
Heiner
Am 27.10.2014 um 22:00 schrieb Heiner Kallweit:
With two different TPLINK routers (both with a AR8327N switch) I
faced the issue that with
kernel 3.14 certain switch ports used 10MBit/half only.
Under kernel 3.10 everything was fine and the same ports used
1000MBit/full.
As the ar8216 driver is the same I had a look at the common phy code
in drivers/net/phy.
In function phy_init_hw in phy_device.c kernel 3.14 resets the phy
whilst 3.10 does not.
The issue turned out to be that when resetting only flag BMCR_RESET
is set, not BMCR_ANENABLE.
(In ar8216.c always both flags are set when the switch is reset)
Therefore autoneg was not enabled. Also later in the boot process it
doesn't get enabled.
Adding BMCR_ANENABLE solved the problem and now also under 3.14 all
ports use 1000MBit/full.
However I'm not sure whether it's a poper fix to add BMCR_ANENABLE
in this generic phy function.
It might not be appropriate for other phy's.
After resetting the switch later in the boot process
ar8xxx_phy_config_aneg is called with
phydev-addr being 0.
In this case the function returns immediately. Otherwise it would
call genphy_config_aneg.
Calling genphy_config_aneg would also solve the problem as it checks
for BMCR_ANENABLE
being set and sets it if needed.
I don't know the reason why genphy_config_aneg isn't called in case
of addr 0.
Or is this a typo and the check actually should be addr != 0 ?
Rgds, Heiner
The following rudimentary patch works fine for me with kernel 3.14.18 on
TP-LINK TL-WDR4900 (mpc85xx with AR8327Nv4)
TP-LINK TL-WDR4300 ( ar71xx with AR8327Nv2)
Apart from using genphy_config_aneg also for addr==0 I replaced
msleep(1000)
with a polling function inspired by phy_poll_reset in phy_device.c
On AR8327 the reset actually takes less than 20ms. Sleeping for 1000ms
seems to be a waste of time.
Little more work would be needed to make it a proper patch:
- move ar8xxx_phy_poll_reset more to the beginning so that it is defined
before being used in any _hw_init function
- replace msleep(1000) also in the other _hw_init functions
- remove pr_info debug message or make it at least pr_dbg
- insert some comments
- use git format-patch output
Rgds, Heiner
--- ar8216.c.orig 2014-10-30 21:50:19.999723156 +0100
+++ ar8216.c2014-10-30 21:42:11.996481099 +0100
@@ -1591,6 +1591,29 @@
#endif
static int
+ar8xxx_phy_poll_reset(struct mii_bus *bus, int num_phys)
+{
+ unsigned int sleep_msecs = 20;
+ int ret, elapsed, i;
+
+ for(elapsed = sleep_msecs; elapsed = 600; elapsed +=
sleep_msecs) {
+ msleep(sleep_msecs);
+ for (i = 0; i num_phys; i++) {
+
Re: [OpenWrt-Devel] Autoneg problems with ar8216 on kernel 3.14 (related to ticket 17800)
On 19/11/2014 14:44, Weedy wrote:
On Oct 30, 2014 5:08 PM, Heiner Kallweit hkallwe...@gmail.com
mailto:hkallwe...@gmail.com wrote:
Am 30.10.2014 um 07:22 schrieb Heiner Kallweit:
Am 30.10.2014 um 03:36 schrieb Florian Fainelli:
Le 28/10/2014 11:46, Heiner Kallweit a écrit :
After a little more thinking about it and looking at the code I
basically have two questions:
1.
Is it actually needed to exclude certain phy's in
ar8xxx_phy_config_aneg?
(At least for AR8327 it doesn't get called with an addr != 0 anyway)
Else we could remove ar8xxx_phy_config_aneg and directly register
genphy_config_aneg as
callback for autoneg configuration.
Address 0 is special, since this is a MDIO broadcast address that
will usually be handled by switches as write to all front-panel ports.
2.
Call sequence with regard to ar8216 is:
ar8216: ar8xxx_phy_probe
phy: phy_attach_direct
phy: phy_init_hw
ar8216: ar8xxx_phy_config_init
ar8216: ar8xxx_phy_config_aneg
ar8216 driver handles AR8327/AR8337 different from the other
supported switch types.
ar8xxx_start incl. more detailed configuration is called from
ar8xxx_phy_probe already.
For the other switch types it's called from ar8xxx_phy_config_init.
I wonder whether doing detailed configuration in the probe stage
might be too early.
phy_init_hw resets the switch anyway later.
Doing the detailed setup in ar8xxx_phy_config_init seems to be
more suited however
there might be good reason why it's handled the way it is.
I suppose that you could re-advertise auto-negotiation by calling
genphy_config_advert() in the config_init routine.
The actual problem is caused by BMCR_ANENABLE being cleared by the
reset in phy_init_hw.
As far as I can see genphy_config_advert doesn't bring back this flag.
What does genphy_config_aneg mainly do?
- call genphy_config_advert
- check if BMCR_ANENABLE is set
- if it's not, call genphy_restart_aneg
Therefore, to bring back BMCR_ANENABLE, we have to call
genphy_config_aneg or genphy_restart_aneg.
genphy_restart_aneg most likely is sufficient, however I don't see
that genphy_config_aneg
can do any harm if being called with addr == 0.
At least for me it works perfectly fine to call genphy_config_aneg
for all addr's.
Rgds, Heiner
Rgds,
Heiner
Am 27.10.2014 um 22:00 schrieb Heiner Kallweit:
With two different TPLINK routers (both with a AR8327N switch) I
faced the issue that with
kernel 3.14 certain switch ports used 10MBit/half only.
Under kernel 3.10 everything was fine and the same ports used
1000MBit/full.
As the ar8216 driver is the same I had a look at the common phy
code in drivers/net/phy.
In function phy_init_hw in phy_device.c kernel 3.14 resets the
phy whilst 3.10 does not.
The issue turned out to be that when resetting only flag
BMCR_RESET is set, not BMCR_ANENABLE.
(In ar8216.c always both flags are set when the switch is reset)
Therefore autoneg was not enabled. Also later in the boot process
it doesn't get enabled.
Adding BMCR_ANENABLE solved the problem and now also under 3.14
all ports use 1000MBit/full.
However I'm not sure whether it's a poper fix to add
BMCR_ANENABLE in this generic phy function.
It might not be appropriate for other phy's.
After resetting the switch later in the boot process
ar8xxx_phy_config_aneg is called with
phydev-addr being 0.
In this case the function returns immediately. Otherwise it would
call genphy_config_aneg.
Calling genphy_config_aneg would also solve the problem as it
checks for BMCR_ANENABLE
being set and sets it if needed.
I don't know the reason why genphy_config_aneg isn't called in
case of addr 0.
Or is this a typo and the check actually should be addr != 0 ?
Rgds, Heiner
The following rudimentary patch works fine for me with kernel 3.14.18 on
TP-LINK TL-WDR4900 (mpc85xx with AR8327Nv4)
TP-LINK TL-WDR4300 ( ar71xx with AR8327Nv2)
Apart from using genphy_config_aneg also for addr==0 I replaced
msleep(1000)
with a polling function inspired by phy_poll_reset in phy_device.c
On AR8327 the reset actually takes less than 20ms. Sleeping for 1000ms
seems to be a waste of time.
Little more work would be needed to make it a proper patch:
- move ar8xxx_phy_poll_reset more to the beginning so that it is defined
before being used in any _hw_init function
- replace msleep(1000) also in the other _hw_init functions
- remove pr_info debug message or make it at least pr_dbg
- insert some comments
- use git format-patch output
Rgds, Heiner
--- ar8216.c.orig 2014-10-30 21:50:19.999723156 +0100
+++ ar8216.c2014-10-30 21:42:11.996481099 +0100
@@ -1591,6 +1591,29 @@
#endif
static int
+ar8xxx_phy_poll_reset(struct mii_bus *bus, int num_phys)
+{
+ unsigned int sleep_msecs = 20;
+ int ret, elapsed, i;
+
+ for(elapsed = sleep_msecs; elapsed = 600; elapsed +=
sleep_msecs)
[OpenWrt-Devel] Any ETA on fixing luci-app-openvpn's dependency issue?
I just tripped over this: https://dev.openwrt.org/ticket/18220 Is there a known workaround for this? And how exactly does one handle this type of generic Provides functionality in .ipk packages? Surely this sort of thing has been done before, no? rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] compile openwrt with external toolchain
Hi, i cant figure out what the actual bug is from the patch. is PREFIX not fully populated, requiring this to be moved back ? also your patch is whitespace broken. could you resend a fixed version with a better description please ? John On 14/11/2014 04:52, sam wrote: Hi, all, i try to compile openwrt with external toolchain, and it fails when compile ther kernel. i check the TARGET_CROSS in rules.mk and make a little modification. and compile success. i don't know if someone has fixed this issue. the patch below works well on my environment. diff --git a/rules.mk b/rules.mk index 0822979..70f3afc 100644 --- a/rules.mk +++ b/rules.mk @@ -144,9 +144,9 @@ ifndef DUMP TARGET_PATH:=$(TOOLCHAIN_DIR)/bin:$(TARGET_PATH) else ifeq ($(CONFIG_NATIVE_TOOLCHAIN),) - TARGET_CROSS:=$(call qstrip,$(CONFIG_TOOLCHAIN_PREFIX)) TOOLCHAIN_ROOT_DIR:=$(call qstrip,$(CONFIG_TOOLCHAIN_ROOT)) TOOLCHAIN_BIN_DIRS:=$(patsubst ./%,$(TOOLCHAIN_ROOT_DIR)/%,$(call qstrip,$(CONFIG_TOOLCHAIN_BIN_PATH))) + TARGET_CROSS:=$(call qstrip,$(TOOLCHAIN_ROOT_DIR)/bin/$(CONFIG_TOOLCHAIN_PREFIX)) TOOLCHAIN_INC_DIRS:=$(patsubst ./%,$(TOOLCHAIN_ROOT_DIR)/%,$(call qstrip,$(CONFIG_TOOLCHAIN_INC_PATH))) TOOLCHAIN_LIB_DIRS:=$(patsubst ./%,$(TOOLCHAIN_ROOT_DIR)/%,$(call qstrip,$(CONFIG_TOOLCHAIN_LIB_PATH))) ifneq ($(TOOLCHAIN_BIN_DIRS),) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any ETA on fixing luci-app-openvpn's dependency issue?
Quoting Robert P. J. Day rpj...@crashcourse.ca: I just tripped over this: https://dev.openwrt.org/ticket/18220 Is there a known workaround for this? And how exactly does one handle this type of generic Provides functionality in .ipk packages? Surely this sort of thing has been done before, no? Never mind, I just saw the PROVIDES directive in a couple Makefiles, I'm assuming the proper fix is that all openvpn variants should PROVIDE the functionality of openvpn, yes? rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] netifd: Don't append 6rd dhcp option when iface6rd is empty
Ok I see your point. Was a bit confused as I had suddenly different dhcp behavior regarding 6rd with the same config. Hans On Wed, Nov 19, 2014 at 1:49 PM, Steven Barth cy...@openwrt.org wrote: That change was actually intentional so 6rd is setup if its available unless you disable it with iface6rd=0. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Where is best to ask about this Mikrotik RB2011UiAS-2HnD-IN problem (Gigabit ports not working)?
I'm having trouble finding the right place to ask about the problems I having with OpenWrt on my rb-2011uias-2hnd. I have asked about it here (where Soren Harward has tried to help) and on the forums where no one seemed to be able to help. I *think* it's a 'developer' problem in a way as I think it must be some sort of initial configuration problem. As far as I can gather (from Soren Harward) the Gigabit ports work on his (slightly different) RB2011 with on of the Barrier Breaker release candidates. I get the same symptoms with both the default Mikrotik BARRIER BREAKER (14.07, r42625) build and with a build I configured myself from the current trunk. The two problems I have are:- The five Gigabit ports (ETH1 to ETH5) just don't work. The five 10/100 ports (ETH6 to ETH10) work perfectly. The USB doesn't seem to work at all, nothing appears in dmesg when anything is plugged into the USB. Is this the right place to ask about this or should I be asking elsewhere? As I said I don't seem to be getting any response on the Forums, I guess that's not surprising because they are user forums and this isn't reall a usage problem. I'm happy to try custom builds, patches, diagnostics, etc. I am a retired C/C++ (on Solaris) programmer. I do need a bit of help on what to look for though. -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RFC] mtd: bcm47xxpart: lower minimal blocksize to 4Ki (from 64Ki)
On 12 November 2014 09:11, Rafał Miłecki zaj...@gmail.com wrote: Some devices like Netgear WNR1000v3 or WGR614v10 have partitions aligned to 0x1000. Using bigger blocksize stopped us from detecting some parts. Pushed in https://dev.openwrt.org/changeset/43322/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] I'd like to donate a Netgear N150 WNR1000 v3
On 12 November 2014 21:59, Alex Henrie alexhenri...@gmail.com wrote: 2014-11-11 23:51 GMT-07:00 Rafał Miłecki zaj...@gmail.com: On 11 November 2014 23:26, Alex Henrie alexhenri...@gmail.com wrote: Is no one interested? Come on, I'm offering free hardware to play with ;-) I already have about 10-20 Broadcom based boars in my drawer ;) Not that excited with another one. However I'd be happy to help adding support for WNR1000 v3. Could you attach serial console to it and test some patched OpenWrt builds? It sounds like a fun project, but SGT. Garcia darwinsker...@gmail.com volunteered to work on it, and I have already mailed the device to him. I'm sure SGT. Garcia will contact you for help once he receives the device. Thanks for your work on OpenWrt! Hi Garcia, Could you provide us NVRAM dump once you get this device? You have access to nvram show command in both: CFE and original firmware I believe. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Still no progress on gigabit ports on Mikrotek 2011UiAS-2HnD
On Tue, Nov 18, 2014 at 6:50 AM, Chris Green c...@isbd.net wrote: I still have non-working gigabit ports on my Mikrotik 2011UiAS-2HnD. Soren Harward kindly had a look at various diagnostics but hasn't seen anything obvious wrong yet. ... Looking at statistics for the Gigabit switch there's loads of data sent but nothing at all received. Not true on both counts: machines connected to the network are getting IPv6 addresses from your router through SLAAC and DHCPv6, but IPv4 isn't working. I haven't had time to dig through the information you've sent me, and probably won't until next week. In the meantime, start looking for problems above the hardware layer. Also, the USB port on the RB2011 is weirdly not hot-pluggable. You have to connect the device first, then load the appropriate USB kernel modules. -- Soren Harward ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Still no progress on gigabit ports on Mikrotek 2011UiAS-2HnD
On Wed, Nov 19, 2014 at 01:50:39PM -0500, Soren Harward wrote: On Tue, Nov 18, 2014 at 6:50 AM, Chris Green c...@isbd.net wrote: I still have non-working gigabit ports on my Mikrotik 2011UiAS-2HnD. Soren Harward kindly had a look at various diagnostics but hasn't seen anything obvious wrong yet. ... Looking at statistics for the Gigabit switch there's loads of data sent but nothing at all received. Not true on both counts: machines connected to the network are getting IPv6 addresses from your router through SLAAC and DHCPv6, but IPv4 isn't working. I haven't had time to dig through the information you've sent me, and probably won't until next week. In the meantime, start looking for problems above the hardware layer. OK, sorry for the noise I've been making meanwhile, I'll be more patient. :-) Also, the USB port on the RB2011 is weirdly not hot-pluggable. You have to connect the device first, then load the appropriate USB kernel modules. OK, I'll try that and see if I get anywhere. Thanks! :-) -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] ar8216: use genphy_config_aneg also for PHY 0
On 2014-10-31 21:38, Heiner Kallweit wrote: Kernel 3.14 introduced a switch reset in phy_init_hw in drivers/net/phy causing BMCR_ANENABLE to get cleared. Due to the fact that ar8xxx_phy_config_aneg does nothing for PHY 0 autonegatiation support remains disabled. This can cause ports to operate at 10MBit/half-duplex only. Fix this by calling genphy_config_aneg for PHY 0 too as genphy_config_aneg sets BMCR_ANENABLE if it's not yet set. Fixes: ticket 17800 Signed-off-by: Heiner Kallweit hkallwe...@gmail.com Applied the series with a few minor modifications. Thanks! - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] musl libc and timezone
On 2014-11-19 12:58, Gianluca Anzolin wrote: On Wed, Nov 19, 2014 at 08:24:49AM +0100, John Crispin wrote: On 18/11/2014 10:54, Gianluca Anzolin wrote: So in my opinion the better fix would be to populate the TZ environment variable. so if a process is spawned and thent he TZ changes the process is stuck on the old TZ ? that seems totally broken John hehe, I knew I was overlooking something :) So would a patch to musl that reads /etc/TZ everytime be acceptable? I'd like to leave that decision to musl upstream. Please submit it to the musl list first before you send a patch for OpenWrt. Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] musl libc and timezone
On 2014-11-19 21:33, Gianluca Anzolin wrote: On Wed, Nov 19, 2014 at 09:24:27PM +0100, Felix Fietkau wrote: On 2014-11-19 12:58, Gianluca Anzolin wrote: On Wed, Nov 19, 2014 at 08:24:49AM +0100, John Crispin wrote: On 18/11/2014 10:54, Gianluca Anzolin wrote: So in my opinion the better fix would be to populate the TZ environment variable. so if a process is spawned and thent he TZ changes the process is stuck on the old TZ ? that seems totally broken John hehe, I knew I was overlooking something :) So would a patch to musl that reads /etc/TZ everytime be acceptable? I'd like to leave that decision to musl upstream. Please submit it to the musl list first before you send a patch for OpenWrt. Hi, please disregard the patch I already sent... I don't know if I have a chance to get something like that merged, given their pragmatic view of what a libc should do. This is the reason I tried to avoid changes to musl in the first place and use the TZ environment variable instead. Isn't a pragmatic view a good thing here? ;) Even if the patch isn't accepted, it's still worth a try. We can of course carry a non-upstream patch in OpenWrt if things don't work out, but I'd like to avoid that if possible. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] musl: add getopt support for non-option arguments
On 2014-11-17 20:38, Gianluca Anzolin wrote: musl libc doesn't support the GNU getopt extension to parse non-option arguments when the optstring starts with '-'. This extension is used by some utilities, notably iptables, that currently return with errors even with perfectly valid invocations. The patch adds the code needed by getopt.c and getopt_long.c to implement that extension. Signed-off-by: Gianluca Anzolin gianl...@sottospazio.it Please propose this patch on the musl list as well. Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] ar8216: use genphy_config_aneg also for PHY 0
Am 19.11.2014 um 21:19 schrieb Felix Fietkau: On 2014-10-31 21:38, Heiner Kallweit wrote: Kernel 3.14 introduced a switch reset in phy_init_hw in drivers/net/phy causing BMCR_ANENABLE to get cleared. Due to the fact that ar8xxx_phy_config_aneg does nothing for PHY 0 autonegatiation support remains disabled. This can cause ports to operate at 10MBit/half-duplex only. Fix this by calling genphy_config_aneg for PHY 0 too as genphy_config_aneg sets BMCR_ANENABLE if it's not yet set. Fixes: ticket 17800 Signed-off-by: Heiner Kallweit hkallwe...@gmail.com Applied the series with a few minor modifications. Thanks! - Felix Great! Not sure whether you've seen the follow-up on some patches of the series. Patch 4: Nov 1st I submitted a version 2 which simplifies ar8xxx_phy_init by using ar8xxx_has_gige to determine chip GBit capability instead of passing this information as a parameter to the function. Patch 3/5: I use my routers w/o VLAN functionality and the patches work fine. However on Nov 8th Dirk Neukirchen reported a problem that with this patch series his WAN port stopped working. I have no idea how this patch series can impact VLAN functionality. However I provided him with updated patches which fixed the issue. (included in a mail sent Nov 9th). Eventually I moved the ANEG fixup code from ar8xxx_phy_config_aneg to ar8xxx_phy_config_init what seems to be cleaner to me. That's what we discussed about on Nov 13th/14th. Having said that I'm totally fine with patches 1 and 2 being applied. For patches 3 and 4 I'll provide the final (IMHO) versions to be applied. Regarding patch 5 I'd be interested in other's opinion whether this ANEG fixup code better fits into config_init or config_aneg to eventually decide with which version of the patch to go. Heiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 3/5] ar8216: introduce fixup_phys callback in ar8xxx_chip
Move phy fixup code from the chip-specific hw_init functions into a
fixup_phys callback.
Signed-off-by: Heiner Kallweit hkallwe...@gmail.com
---
target/linux/generic/files/drivers/net/phy/ar8216.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c
b/target/linux/generic/files/drivers/net/phy/ar8216.c
index ffc5dcf..a0bf10a 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.c
@@ -80,6 +80,7 @@ struct ar8xxx_chip {
int (*atu_flush)(struct ar8xxx_priv *priv);
void (*vtu_flush)(struct ar8xxx_priv *priv);
void (*vtu_load_vlan)(struct ar8xxx_priv *priv, u32 vid, u32 port_mask);
+ void (*phy_fixup)(struct ar8xxx_priv *priv, int phy);
const struct ar8xxx_mib_desc *mib_decs;
unsigned num_mibs;
@@ -1636,7 +1637,7 @@ ar8327_hw_init(struct ar8xxx_priv *priv)
bus = priv-mii_bus;
for (i = 0; i AR8XXX_NUM_PHYS; i++) {
- ar8327_phy_fixup(priv, i);
+ priv-chip-phy_fixup(priv, i);
/* start aneg on the PHY */
mdiobus_write(bus, i, MII_ADVERTISE, ADVERTISE_ALL |
@@ -1825,6 +1826,7 @@ static const struct ar8xxx_chip ar8327_chip = {
.atu_flush = ar8327_atu_flush,
.vtu_flush = ar8327_vtu_flush,
.vtu_load_vlan = ar8327_vtu_load_vlan,
+ .phy_fixup = ar8327_phy_fixup,
.num_mibs = ARRAY_SIZE(ar8236_mibs),
.mib_decs = ar8236_mibs,
--
2.1.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 4/5] ar8216: factor out PHY init code into a generic function
PHY init code in the switch-specific hw_init functions is mainly
identical. Factor it out into a generic ar8xxx_phy_init function.
Signed-off-by: Heiner Kallweit hkallwe...@gmail.com
---
.../linux/generic/files/drivers/net/phy/ar8216.c | 66 --
1 file changed, 25 insertions(+), 41 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c
b/target/linux/generic/files/drivers/net/phy/ar8216.c
index a0bf10a..02abfe8 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.c
@@ -340,6 +340,28 @@ ar8xxx_phy_poll_reset(struct mii_bus *bus)
return -ETIMEDOUT;
}
+static void
+ar8xxx_phy_init(struct ar8xxx_priv *priv)
+{
+ int i;
+ struct mii_bus *bus;
+
+ bus = priv-mii_bus;
+ for (i = 0; i AR8XXX_NUM_PHYS; i++) {
+ if (priv-chip-phy_fixup)
+ priv-chip-phy_fixup(priv, i);
+
+ /* initialize the port itself */
+ mdiobus_write(bus, i, MII_ADVERTISE,
+ ADVERTISE_ALL | ADVERTISE_PAUSE_CAP |
ADVERTISE_PAUSE_ASYM);
+ if (ar8xxx_has_gige(priv))
+ mdiobus_write(bus, i, MII_CTRL1000, ADVERTISE_1000FULL);
+ mdiobus_write(bus, i, MII_BMCR, BMCR_RESET | BMCR_ANENABLE);
+ }
+
+ ar8xxx_phy_poll_reset(bus);
+}
+
static u32
ar8xxx_mii_read(struct ar8xxx_priv *priv, int reg)
{
@@ -886,22 +908,10 @@ ar8236_setup_port(struct ar8xxx_priv *priv, int port, u32
members)
static int
ar8236_hw_init(struct ar8xxx_priv *priv)
{
- int i;
- struct mii_bus *bus;
-
if (priv-initialized)
return 0;
- /* Initialize the PHYs */
- bus = priv-mii_bus;
- for (i = 0; i AR8XXX_NUM_PHYS; i++) {
- mdiobus_write(bus, i, MII_ADVERTISE,
- ADVERTISE_ALL | ADVERTISE_PAUSE_CAP |
- ADVERTISE_PAUSE_ASYM);
- mdiobus_write(bus, i, MII_BMCR, BMCR_RESET | BMCR_ANENABLE);
- }
-
- ar8xxx_phy_poll_reset(bus);
+ ar8xxx_phy_init(priv);
priv-initialized = true;
return 0;
@@ -938,9 +948,7 @@ static const struct ar8xxx_chip ar8236_chip = {
static int
ar8316_hw_init(struct ar8xxx_priv *priv)
{
- int i;
u32 val, newval;
- struct mii_bus *bus;
val = priv-read(priv, AR8316_REG_POSTRIP);
@@ -979,17 +987,7 @@ ar8316_hw_init(struct ar8xxx_priv *priv)
msleep(1000);
}
- /* Initialize the ports */
- bus = priv-mii_bus;
- for (i = 0; i AR8XXX_NUM_PHYS; i++) {
- /* initialize the port itself */
- mdiobus_write(bus, i, MII_ADVERTISE,
- ADVERTISE_ALL | ADVERTISE_PAUSE_CAP |
ADVERTISE_PAUSE_ASYM);
- mdiobus_write(bus, i, MII_CTRL1000, ADVERTISE_1000FULL);
- mdiobus_write(bus, i, MII_BMCR, BMCR_RESET | BMCR_ANENABLE);
- }
-
- ar8xxx_phy_poll_reset(bus);
+ ar8xxx_phy_init(priv);
out:
priv-initialized = true;
@@ -1620,9 +1618,7 @@ ar8327_hw_config_of(struct ar8xxx_priv *priv, struct
device_node *np)
static int
ar8327_hw_init(struct ar8xxx_priv *priv)
{
- struct mii_bus *bus;
int ret;
- int i;
if (priv-phy-dev.of_node)
ret = ar8327_hw_config_of(priv, priv-phy-dev.of_node);
@@ -1635,19 +1631,7 @@ ar8327_hw_init(struct ar8xxx_priv *priv)
ar8327_leds_init(priv);
- bus = priv-mii_bus;
- for (i = 0; i AR8XXX_NUM_PHYS; i++) {
- priv-chip-phy_fixup(priv, i);
-
- /* start aneg on the PHY */
- mdiobus_write(bus, i, MII_ADVERTISE, ADVERTISE_ALL |
-ADVERTISE_PAUSE_CAP |
-ADVERTISE_PAUSE_ASYM);
- mdiobus_write(bus, i, MII_CTRL1000, ADVERTISE_1000FULL);
- mdiobus_write(bus, i, MII_BMCR, BMCR_RESET | BMCR_ANENABLE);
- }
-
- ar8xxx_phy_poll_reset(bus);
+ ar8xxx_phy_init(priv);
return 0;
}
--
2.1.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] ar8216: use genphy_config_aneg also for PHY 0
On 2014-11-19 22:17, Heiner Kallweit wrote: Am 19.11.2014 um 21:19 schrieb Felix Fietkau: On 2014-10-31 21:38, Heiner Kallweit wrote: Kernel 3.14 introduced a switch reset in phy_init_hw in drivers/net/phy causing BMCR_ANENABLE to get cleared. Due to the fact that ar8xxx_phy_config_aneg does nothing for PHY 0 autonegatiation support remains disabled. This can cause ports to operate at 10MBit/half-duplex only. Fix this by calling genphy_config_aneg for PHY 0 too as genphy_config_aneg sets BMCR_ANENABLE if it's not yet set. Fixes: ticket 17800 Signed-off-by: Heiner Kallweit hkallwe...@gmail.com Applied the series with a few minor modifications. Thanks! - Felix Great! Not sure whether you've seen the follow-up on some patches of the series. Patch 4: Nov 1st I submitted a version 2 which simplifies ar8xxx_phy_init by using ar8xxx_has_gige to determine chip GBit capability instead of passing this information as a parameter to the function. Patch 3/5: I use my routers w/o VLAN functionality and the patches work fine. However on Nov 8th Dirk Neukirchen reported a problem that with this patch series his WAN port stopped working. I have no idea how this patch series can impact VLAN functionality. However I provided him with updated patches which fixed the issue. (included in a mail sent Nov 9th). Eventually I moved the ANEG fixup code from ar8xxx_phy_config_aneg to ar8xxx_phy_config_init what seems to be cleaner to me. That's what we discussed about on Nov 13th/14th. Having said that I'm totally fine with patches 1 and 2 being applied. For patches 3 and 4 I'll provide the final (IMHO) versions to be applied. Regarding patch 5 I'd be interested in other's opinion whether this ANEG fixup code better fits into config_init or config_aneg to eventually decide with which version of the patch to go. Somehow the follow-up versions didn't reach my inbox (except for the two that you just sent me today). Please provide incremental fixes on top of current trunk. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 3/4] ar8216: factor out PHY init and fixup code into a generic function
PHY init code in the switch-specific hw_init functions is mainly
identical. Factor it out into a generic ar8xxx_phy_init function.
Rebase on current trunk.
Signed-off-by: Heiner Kallweit hkallwe...@gmail.com
---
.../linux/generic/files/drivers/net/phy/ar8216.c | 29 --
1 file changed, 10 insertions(+), 19 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c
b/target/linux/generic/files/drivers/net/phy/ar8216.c
index 147d21b..d871cf3 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.c
@@ -80,7 +80,7 @@ struct ar8xxx_chip {
int (*atu_flush)(struct ar8xxx_priv *priv);
void (*vtu_flush)(struct ar8xxx_priv *priv);
void (*vtu_load_vlan)(struct ar8xxx_priv *priv, u32 vid, u32 port_mask);
- void (*fixup_phys)(struct ar8xxx_priv *priv);
+ void (*phy_fixup)(struct ar8xxx_priv *priv, int phy);
const struct ar8xxx_mib_desc *mib_decs;
unsigned num_mibs;
@@ -343,20 +343,20 @@ ar8xxx_phy_poll_reset(struct mii_bus *bus)
}
static void
-ar8xxx_phy_init(struct ar8xxx_priv *priv, bool support_1000)
+ar8xxx_phy_init(struct ar8xxx_priv *priv)
{
int i;
struct mii_bus *bus;
- if (priv-chip-fixup_phys)
- priv-chip-fixup_phys(priv);
-
bus = priv-mii_bus;
for (i = 0; i AR8XXX_NUM_PHYS; i++) {
+ if (priv-chip-phy_fixup)
+ priv-chip-phy_fixup(priv, i);
+
/* initialize the port itself */
mdiobus_write(bus, i, MII_ADVERTISE,
ADVERTISE_ALL | ADVERTISE_PAUSE_CAP |
ADVERTISE_PAUSE_ASYM);
- if (support_1000)
+ if (ar8xxx_has_gige(priv))
mdiobus_write(bus, i, MII_CTRL1000, ADVERTISE_1000FULL);
mdiobus_write(bus, i, MII_BMCR, BMCR_RESET | BMCR_ANENABLE);
}
@@ -913,7 +913,7 @@ ar8236_hw_init(struct ar8xxx_priv *priv)
if (priv-initialized)
return 0;
- ar8xxx_phy_init(priv, false);
+ ar8xxx_phy_init(priv);
priv-initialized = true;
return 0;
@@ -989,7 +989,7 @@ ar8316_hw_init(struct ar8xxx_priv *priv)
msleep(1000);
}
- ar8xxx_phy_init(priv, true);
+ ar8xxx_phy_init(priv);
out:
priv-initialized = true;
@@ -1633,7 +1633,7 @@ ar8327_hw_init(struct ar8xxx_priv *priv)
ar8327_leds_init(priv);
- ar8xxx_phy_init(priv, true);
+ ar8xxx_phy_init(priv);
return 0;
}
@@ -1801,15 +1801,6 @@ ar8327_setup_port(struct ar8xxx_priv *priv, int port,
u32 members)
priv-write(priv, AR8327_REG_PORT_LOOKUP(port), t);
}
-static void
-ar8327_fixup_phys(struct ar8xxx_priv *priv)
-{
- int i;
-
- for (i = 0; i AR8XXX_NUM_PHYS; i++)
- ar8327_phy_fixup(priv, i);
-}
-
static const struct ar8xxx_chip ar8327_chip = {
.caps = AR8XXX_CAP_GIGE | AR8XXX_CAP_MIB_COUNTERS,
.hw_init = ar8327_hw_init,
@@ -1821,7 +1812,7 @@ static const struct ar8xxx_chip ar8327_chip = {
.atu_flush = ar8327_atu_flush,
.vtu_flush = ar8327_vtu_flush,
.vtu_load_vlan = ar8327_vtu_load_vlan,
- .fixup_phys = ar8327_fixup_phys,
+ .phy_fixup = ar8327_phy_fixup,
.num_mibs = ARRAY_SIZE(ar8236_mibs),
.mib_decs = ar8236_mibs,
--
2.1.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] ar8216: use genphy_config_aneg also for PHY 0
Am 19.11.2014 um 22:39 schrieb Felix Fietkau: On 2014-11-19 22:17, Heiner Kallweit wrote: Am 19.11.2014 um 21:19 schrieb Felix Fietkau: On 2014-10-31 21:38, Heiner Kallweit wrote: Kernel 3.14 introduced a switch reset in phy_init_hw in drivers/net/phy causing BMCR_ANENABLE to get cleared. Due to the fact that ar8xxx_phy_config_aneg does nothing for PHY 0 autonegatiation support remains disabled. This can cause ports to operate at 10MBit/half-duplex only. Fix this by calling genphy_config_aneg for PHY 0 too as genphy_config_aneg sets BMCR_ANENABLE if it's not yet set. Fixes: ticket 17800 Signed-off-by: Heiner Kallweit hkallwe...@gmail.com Applied the series with a few minor modifications. Thanks! - Felix Great! Not sure whether you've seen the follow-up on some patches of the series. Patch 4: Nov 1st I submitted a version 2 which simplifies ar8xxx_phy_init by using ar8xxx_has_gige to determine chip GBit capability instead of passing this information as a parameter to the function. Patch 3/5: I use my routers w/o VLAN functionality and the patches work fine. However on Nov 8th Dirk Neukirchen reported a problem that with this patch series his WAN port stopped working. I have no idea how this patch series can impact VLAN functionality. However I provided him with updated patches which fixed the issue. (included in a mail sent Nov 9th). Eventually I moved the ANEG fixup code from ar8xxx_phy_config_aneg to ar8xxx_phy_config_init what seems to be cleaner to me. That's what we discussed about on Nov 13th/14th. Having said that I'm totally fine with patches 1 and 2 being applied. For patches 3 and 4 I'll provide the final (IMHO) versions to be applied. Regarding patch 5 I'd be interested in other's opinion whether this ANEG fixup code better fits into config_init or config_aneg to eventually decide with which version of the patch to go. Somehow the follow-up versions didn't reach my inbox (except for the two that you just sent me today). Please provide incremental fixes on top of current trunk. - Felix The increments to patches 3 and 4 I put into one patch (v3 3/4). Heiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] I'd like to donate a Netgear N150 WNR1000 v3
On Nov 19 18:43 +0100, Rafał Miłecki wrote: Hi Garcia, Could you provide us NVRAM dump once you get this device? You have access to nvram show command in both: CFE and original firmware I believe. -- Rafał will do. SGT. Garcia ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RFC] mtd: bcm47xxpart: lower minimal blocksize to 4Ki (from 64Ki)
On Nov 12 09:11 +0100, Rafał Miłecki wrote: Some devices like Netgear WNR1000v3 or WGR614v10 have partitions aligned to 0x1000. Using bigger blocksize stopped us from detecting some parts. Signed-off-by: Rafał Miłecki zaj...@gmail.com is this related: 6 bcm47xxpart partitions found on MTD device bcm47xxsflash Creating 6 MTD partitions on bcm47xxsflash: 0x-0x0004 : boot 0x0004-0x003f : firmware 0x0004001c-0x0004090c : loader 0x0004090c-0x0014e400 : linux mtd: partition linux must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only 0x0014e400-0x003f : rootfs mtd: partition rootfs must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only mtd: device 4 (rootfs) set to be root filesystem 1 squashfs-split partitions found on MTD device rootfs 0x002b-0x003f : rootfs_data 0x003f-0x0040 : nvram full dmesg: http://codepad.org/2hiTlY4B i started getting this ever since i updated using sysupgrade. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] mysterious wl_exe.o
hi, openwrt, dd-wrt, tomato, potato they all ship wl_exe.o (mips) with their broadcom-wl package which is compiled into wl command. on gentoo (amd64) this is missing, in fact i don't think any desktop linux has it (maybe fedora). so i was wondering where one finds it? it's not included in the hybrid broadcom-sta distribution from broadcom, so where is it? SGT. Garcia ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mysterious wl_exe.o
On 20 November 2014 00:48, SGT. Garcia darwinsker...@gmail.com wrote: openwrt, dd-wrt, tomato, potato they all ship wl_exe.o (mips) with their broadcom-wl package which is compiled into wl command. on gentoo (amd64) this is missing, in fact i don't think any desktop linux has it (maybe fedora). so i was wondering where one finds it? it's not included in the hybrid broadcom-sta distribution from broadcom, so where is it? I guess it's simply closed source. You can use wlc as a replacement. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RFC] mtd: bcm47xxpart: lower minimal blocksize to 4Ki (from 64Ki)
On 20 November 2014 00:32, SGT. Garcia darwinsker...@gmail.com wrote: On Nov 12 09:11 +0100, Rafał Miłecki wrote: Some devices like Netgear WNR1000v3 or WGR614v10 have partitions aligned to 0x1000. Using bigger blocksize stopped us from detecting some parts. Signed-off-by: Rafał Miłecki zaj...@gmail.com is this related: 6 bcm47xxpart partitions found on MTD device bcm47xxsflash Creating 6 MTD partitions on bcm47xxsflash: 0x-0x0004 : boot 0x0004-0x003f : firmware 0x0004001c-0x0004090c : loader 0x0004090c-0x0014e400 : linux mtd: partition linux must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only 0x0014e400-0x003f : rootfs mtd: partition rootfs must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only mtd: device 4 (rootfs) set to be root filesystem 1 squashfs-split partitions found on MTD device rootfs 0x002b-0x003f : rootfs_data 0x003f-0x0040 : nvram Yes. Partitions are created by bcm47xxpart driver. full dmesg: http://codepad.org/2hiTlY4B i started getting this ever since i updated using sysupgrade. Some time ago (AA times) we were using different partitioner. So your pattition-related messages could look different. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar8216: Use generic hw_init from ar8236 for ar8216 too
We should make sure that also for ar8216 hw gets initialized.
For ar8216 hw_init is a dummy currently. The hw_init used for ar8236
should be generic enough to be usable with ar8216 too.
Signed-off-by: Heiner Kallweit hkallwe...@gmail.com
---
target/linux/generic/files/drivers/net/phy/ar8216.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c
b/target/linux/generic/files/drivers/net/phy/ar8216.c
index d871cf3..1d58f3a 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.c
@@ -814,6 +814,12 @@ ar8216_setup_port(struct ar8xxx_priv *priv, int port, u32
members)
static int
ar8216_hw_init(struct ar8xxx_priv *priv)
{
+ if (priv-initialized)
+ return 0;
+
+ ar8xxx_phy_init(priv);
+
+ priv-initialized = true;
return 0;
}
@@ -907,18 +913,6 @@ ar8236_setup_port(struct ar8xxx_priv *priv, int port, u32
members)
(members AR8236_PORT_VLAN2_MEMBER_S));
}
-static int
-ar8236_hw_init(struct ar8xxx_priv *priv)
-{
- if (priv-initialized)
- return 0;
-
- ar8xxx_phy_init(priv);
-
- priv-initialized = true;
- return 0;
-}
-
static void
ar8236_init_globals(struct ar8xxx_priv *priv)
{
@@ -934,7 +928,7 @@ ar8236_init_globals(struct ar8xxx_priv *priv)
static const struct ar8xxx_chip ar8236_chip = {
.caps = AR8XXX_CAP_MIB_COUNTERS,
- .hw_init = ar8236_hw_init,
+ .hw_init = ar8216_hw_init,
.init_globals = ar8236_init_globals,
.init_port = ar8216_init_port,
.setup_port = ar8236_setup_port,
--
2.1.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
