Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
I missed that one on the mailing list. It is the same fix,
or part of it anyway.
Ben
On Wed, 2014-01-22 at 01:01 +0100, Luka Perkov wrote:
> On Tue, Jan 21, 2014 at 08:50:03PM +0100, Ben Mulvihill wrote:
> > Any enlightenment you can provide will be gratefully received.
>
> I have not tested this patch yet but it could be related to your
> problem...
>
> Luka
>
>
> From ad77bb90cbebcd107e81722e1fbdcff91fe55614 Mon Sep 17 00:00:00 2001
> From: Antonios Vamporakis
> Date: Sun, 29 Dec 2013 23:40:15 +0100
> Subject: [PATCH 03/14] lantiq: resolve EBU conflict between NAND and PCI
>
> Stop PCI IRQs from taking over the EBU wile NAND is accessed.
>
> Signed-off-by: Antonios Vamporakis
> ---
> .../0203-xway-fix-nand-pci-conflict.patch | 19
> +++
> 1 file changed, 19 insertions(+)
> create mode 100644
> target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
>
> diff --git
> a/target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
> b/target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
> new file mode 100644
> index 000..f4b5793
> --- /dev/null
> +++ b/target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
> @@ -0,0 +1,19 @@
> +--- a/drivers/mtd/nand/xway_nand.c
> b/drivers/mtd/nand/xway_nand.c
> +@@ -80,13 +80,16 @@ static void xway_reset_chip(struct nand_
> +
> + static void xway_select_chip(struct mtd_info *mtd, int chip)
> + {
> ++static unsigned long csflags;
> +
> + switch (chip) {
> + case -1:
> + ltq_ebu_w32_mask(NAND_CON_CE, 0, EBU_NAND_CON);
> + ltq_ebu_w32_mask(NAND_CON_NANDM, 0, EBU_NAND_CON);
> ++spin_unlock_irqrestore(&ebu_lock, csflags);
> + break;
> + case 0:
> ++spin_lock_irqsave(&ebu_lock, csflags);
> + ltq_ebu_w32_mask(0, NAND_CON_NANDM, EBU_NAND_CON);
> + ltq_ebu_w32_mask(0, NAND_CON_CE, EBU_NAND_CON);
> + break;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] mpc85xx: Fix building ramdisk images
Signed-off-by: Helmut Schaa --- target/linux/mpc85xx/image/Makefile | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/target/linux/mpc85xx/image/Makefile b/target/linux/mpc85xx/image/Makefile index 4c80bb7..5ecd100 100644 --- a/target/linux/mpc85xx/image/Makefile +++ b/target/linux/mpc85xx/image/Makefile @@ -19,11 +19,7 @@ define factoryname $(call imgname,$(1),$(2))-factory.bin endef -ifeq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),y) - IMAGE_SUFFIX=-initramfs -endif - -zImage:=$(BIN_DIR)/$(IMG_PREFIX)-zImage$(IMAGE_SUFFIX) +zImage:=$(BIN_DIR)/$(IMG_PREFIX)-zImage DTS_TARGETS = mpc8548cds_32b p1010rdb tl-wdr4900-v1 p1020rdb BOOT_IMAGES:=zImage cuImage.tl-wdr4900-v1 @@ -35,7 +31,7 @@ define Image/Prepare endef define Image/BuildKernel - cp $(KDIR)/zImage$(IMAGE_SUFFIX) $(zImage) + cp $(KDIR)/zImage $(zImage) $(foreach dts,$(DTS_TARGETS), $(LINUX_DIR)/scripts/dtc/dtc -I dts -O dtb $(LINUX_DIR)/arch/powerpc/boot/dts/$(dts).dts > $(BIN_DIR)/$(IMG_PREFIX)-$(dts).fdt ) -- 1.8.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] mpc85xx: Remove inittab workaround
The default inittab uses "askconsole" which is implemented by procd
and uses the console provided by the kernel command line.
Hence, this platform specific workaround is not necessary anymore.
Signed-off-by: Helmut Schaa
---
target/linux/mpc85xx/base-files/etc/inittab| 2 --
.../etc/uci-defaults/00_inittab-console-fixup | 27 --
2 files changed, 29 deletions(-)
delete mode 100644 target/linux/mpc85xx/base-files/etc/inittab
delete mode 100755
target/linux/mpc85xx/base-files/etc/uci-defaults/00_inittab-console-fixup
diff --git a/target/linux/mpc85xx/base-files/etc/inittab
b/target/linux/mpc85xx/base-files/etc/inittab
deleted file mode 100644
index 17f829f..000
--- a/target/linux/mpc85xx/base-files/etc/inittab
+++ /dev/null
@@ -1,2 +0,0 @@
-::sysinit:/etc/init.d/rcS S boot
-::shutdown:/etc/init.d/rcS K shutdown
diff --git
a/target/linux/mpc85xx/base-files/etc/uci-defaults/00_inittab-console-fixup
b/target/linux/mpc85xx/base-files/etc/uci-defaults/00_inittab-console-fixup
deleted file mode 100755
index 9d7b2ae..000
--- a/target/linux/mpc85xx/base-files/etc/uci-defaults/00_inittab-console-fixup
+++ /dev/null
@@ -1,27 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2011 OpenWrt.org
-#
-
-enable_console_login() {
- local cons=$1
- local initline="$cons::askfirst:/bin/ash --login"
-
- grep -qs "^$initline" /etc/inittab || {
- echo "$initline" >> /etc/inittab
- sync
- kill -HUP 1
- }
-}
-
-inittab_console_fixup() {
- for cons in ttyS0 ttyS1; do
- grep -qs "console=$cons" /proc/cmdline && {
- enable_console_login $cons
- }
- done
-}
-
-inittab_console_fixup
-
-exit 0
--
1.8.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
I have a feeling that the patch posted by luka will fix the fritz3370
problem.
i have a vague recollection that it worked once upon a time. I also
remember that in my last test it did not work, but i had wifi enabled so
that would fit in with the missing locking.
I'll let you know if that is the case and then we can look at the
nor/nand/pci combo afterwards
John
On 22/01/2014 09:46, Ben Mulvihill wrote:
> I missed that one on the mailing list. It is the same fix,
> or part of it anyway.
>
> Ben
>
> On Wed, 2014-01-22 at 01:01 +0100, Luka Perkov wrote:
>> On Tue, Jan 21, 2014 at 08:50:03PM +0100, Ben Mulvihill wrote:
>>> Any enlightenment you can provide will be gratefully received.
>> I have not tested this patch yet but it could be related to your
>> problem...
>>
>> Luka
>>
>>
>> From ad77bb90cbebcd107e81722e1fbdcff91fe55614 Mon Sep 17 00:00:00 2001
>> From: Antonios Vamporakis
>> Date: Sun, 29 Dec 2013 23:40:15 +0100
>> Subject: [PATCH 03/14] lantiq: resolve EBU conflict between NAND and PCI
>>
>> Stop PCI IRQs from taking over the EBU wile NAND is accessed.
>>
>> Signed-off-by: Antonios Vamporakis
>> ---
>> .../0203-xway-fix-nand-pci-conflict.patch | 19
>> +++
>> 1 file changed, 19 insertions(+)
>> create mode 100644
>> target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
>>
>> diff --git
>> a/target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
>> b/target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
>> new file mode 100644
>> index 000..f4b5793
>> --- /dev/null
>> +++ b/target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
>> @@ -0,0 +1,19 @@
>> +--- a/drivers/mtd/nand/xway_nand.c
>> b/drivers/mtd/nand/xway_nand.c
>> +@@ -80,13 +80,16 @@ static void xway_reset_chip(struct nand_
>> +
>> + static void xway_select_chip(struct mtd_info *mtd, int chip)
>> + {
>> ++ static unsigned long csflags;
>> +
>> +switch (chip) {
>> +case -1:
>> +ltq_ebu_w32_mask(NAND_CON_CE, 0, EBU_NAND_CON);
>> +ltq_ebu_w32_mask(NAND_CON_NANDM, 0, EBU_NAND_CON);
>> ++ spin_unlock_irqrestore(&ebu_lock, csflags);
>> +break;
>> +case 0:
>> ++ spin_lock_irqsave(&ebu_lock, csflags);
>> +ltq_ebu_w32_mask(0, NAND_CON_NANDM, EBU_NAND_CON);
>> +ltq_ebu_w32_mask(0, NAND_CON_CE, EBU_NAND_CON);
>> +break;
> ___
> 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] BT Home Hub 2B support - nand driver patch (for comment only)
That makes sense. Thanks again.
Ben
On Wed, 2014-01-22 at 10:30 +0100, John Crispin wrote:
> I have a feeling that the patch posted by luka will fix the fritz3370
> problem.
>
> i have a vague recollection that it worked once upon a time. I also
> remember that in my last test it did not work, but i had wifi enabled so
> that would fit in with the missing locking.
>
> I'll let you know if that is the case and then we can look at the
> nor/nand/pci combo afterwards
>
> John
>
>
> On 22/01/2014 09:46, Ben Mulvihill wrote:
> > I missed that one on the mailing list. It is the same fix,
> > or part of it anyway.
> >
> > Ben
> >
> > On Wed, 2014-01-22 at 01:01 +0100, Luka Perkov wrote:
> >> On Tue, Jan 21, 2014 at 08:50:03PM +0100, Ben Mulvihill wrote:
> >>> Any enlightenment you can provide will be gratefully received.
> >> I have not tested this patch yet but it could be related to your
> >> problem...
> >>
> >> Luka
> >>
> >>
> >> From ad77bb90cbebcd107e81722e1fbdcff91fe55614 Mon Sep 17 00:00:00 2001
> >> From: Antonios Vamporakis
> >> Date: Sun, 29 Dec 2013 23:40:15 +0100
> >> Subject: [PATCH 03/14] lantiq: resolve EBU conflict between NAND and PCI
> >>
> >> Stop PCI IRQs from taking over the EBU wile NAND is accessed.
> >>
> >> Signed-off-by: Antonios Vamporakis
> >> ---
> >> .../0203-xway-fix-nand-pci-conflict.patch | 19
> >> +++
> >> 1 file changed, 19 insertions(+)
> >> create mode 100644
> >> target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
> >>
> >> diff --git
> >> a/target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
> >> b/target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
> >> new file mode 100644
> >> index 000..f4b5793
> >> --- /dev/null
> >> +++
> >> b/target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
> >> @@ -0,0 +1,19 @@
> >> +--- a/drivers/mtd/nand/xway_nand.c
> >> b/drivers/mtd/nand/xway_nand.c
> >> +@@ -80,13 +80,16 @@ static void xway_reset_chip(struct nand_
> >> +
> >> + static void xway_select_chip(struct mtd_info *mtd, int chip)
> >> + {
> >> ++ static unsigned long csflags;
> >> +
> >> + switch (chip) {
> >> + case -1:
> >> + ltq_ebu_w32_mask(NAND_CON_CE, 0, EBU_NAND_CON);
> >> + ltq_ebu_w32_mask(NAND_CON_NANDM, 0, EBU_NAND_CON);
> >> ++ spin_unlock_irqrestore(&ebu_lock, csflags);
> >> + break;
> >> + case 0:
> >> ++ spin_lock_irqsave(&ebu_lock, csflags);
> >> + ltq_ebu_w32_mask(0, NAND_CON_NANDM, EBU_NAND_CON);
> >> + ltq_ebu_w32_mask(0, NAND_CON_CE, EBU_NAND_CON);
> >> + break;
> > ___
> > 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 mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
On Wed, 2014-01-22 at 00:42 +0100, John Crispin wrote: > On 21/01/2014 21:55, David Lang wrote: > > On Tue, 21 Jan 2014, Ben Mulvihill wrote: > > > >> The nand driver currently in trunk works fine, provided ... > > > > what is the current status of nand flash support? I asked about this > > within the last couple of weeks and was told that supporing devices > > with nand flash would require major surgery to the squashfs code to > > allow it to deal with badblocks. > > > > has this been done? was I misinformed on what the problem is? or is > > this still a problem and devices with nand flash can work, but only if > > they avoid squashfs? > > > > > Hi David, > > Daniel is working on splitting the mount_root, block, extroot and all > the other mtd/block related tools to a new repo called fstools. While > doing so we are doing some cleanup of the code. i expect this to hit > trunk within the next week. Once this is done we will add nand specific > features to the repo. Once that is done, openwrt should have proper > support for ubi including functional sysupgrade support (using > ubi-format) ... > > John > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel How critical is the bad blocks problem in practice? The above will solve the lack of bad block handling in squashfs, but unless I've missed the point, on a typical board won't the kernel itself still be loaded directly from flash? Or do you assume that the bootloader will be able to handle ubi as well? Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
On Wed, Jan 22, 2014 at 1:02 PM, Ben Mulvihill wrote: > On Wed, 2014-01-22 at 00:42 +0100, John Crispin wrote: >> On 21/01/2014 21:55, David Lang wrote: >> > On Tue, 21 Jan 2014, Ben Mulvihill wrote: >> > >> >> The nand driver currently in trunk works fine, provided ... >> > >> > what is the current status of nand flash support? I asked about this >> > within the last couple of weeks and was told that supporing devices >> > with nand flash would require major surgery to the squashfs code to >> > allow it to deal with badblocks. >> > >> > has this been done? was I misinformed on what the problem is? or is >> > this still a problem and devices with nand flash can work, but only if >> > they avoid squashfs? >> > >> >> >> Hi David, >> >> Daniel is working on splitting the mount_root, block, extroot and all >> the other mtd/block related tools to a new repo called fstools. While >> doing so we are doing some cleanup of the code. i expect this to hit >> trunk within the next week. Once this is done we will add nand specific >> features to the repo. Once that is done, openwrt should have proper >> support for ubi including functional sysupgrade support (using >> ubi-format) ... >> >> John >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > How critical is the bad blocks problem in practice? The above will > solve the lack of bad block handling in squashfs, but unless I've > missed the point, on a typical board won't the kernel itself still > be loaded directly from flash? Or do you assume that the bootloader > will be able to handle ubi as well? SLC NAND usually is rather stable, but bad blocks exist, and bit flips do happen from time to time, so you need to relocate blocks then. MLC NAND is much worse, there bitflips are rather common, and you need to actually use a threshold of how many correctable bitflips you accept before you move the block somewhere else. To make matters worse, MLC NANDs support a lot less erase cycles than SLC NANDs (1000+ vs. 100k+), so using ubi-format more than once for initial format is a bad idea there (as it will cause all blocks to get erased once). A NAND capable Filesystem needs to be capable of three things: a) Be aware that blocks might be bad and skip them (and not just fail if it encounters them) b) Be aware that blocks might get bit flips just from reading, and be prepared to move the contents to a "fresh" block c) Not rely on the order of the blocks on the flash And squashfs fails for all three. There's of course the possibility of using a flash translation layer like UBI, that will take over all three things and hide all the NAND quirks from filesystems using it. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
> The Home Hub 2B has both nand and nor flash connected to the ebu, plus > an ath9k pci wireless card, and the main difficulty is getting all three > working at the same time without interfering with each other. The nand > driver currently in trunk works fine, provided that open-drain is > enabled on the ebu cs1 pin, and provided that wireless is off. However, > the only way to get the nor chip to work reliably seems to be disable > open-drain on ebu cs1, at which point the nand driver generates jffs2 > errors. Regardless whether open-drain is enabled or not, switching on > wireless also causes jffs2 errors. Based on my experience with the boards with NOR only, the EBU_CS1 pin should always be driven (i.e., not open-drain) for the flash not to get corrupted by PCI. If it is not driven, it takes some time for the pin to be pulled up (depending on the pull-up resistors), and the flash chip may still be enabled when the PCI transfers start. As far as I can see, the problem here is that for two flash chips you need two chip select signals. IIRC, the EBU always uses GPIO23 (EBU_CS1), no matter whether you use NAND or NOR. So you likely need another GPIO to select between NAND and NOR, which you have to toggle manually. Does the original firmware have access to both NAND and NOR simultaneously? Or does the original bootloader disable NOR before booting the firmware? Matti Laakso ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
> Based on my experience with the boards with NOR only, the EBU_CS1 pin > should always be driven (i.e., not open-drain) for the flash not to get > corrupted by PCI. If it is not driven, it takes some time for the pin to > be pulled up (depending on the pull-up resistors), and the flash chip > may still be enabled when the PCI transfers start. And to be clear, driven means OD register set to 1, which means lantiq,open-drain not set in the dts. Matti Laakso ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][feeds] openvpn-devel: make openvpn compatible with polarssl 1.2.3 or newer [AA]
Only relevant for Attitude Adjustment, see trac #12982 [1].
Commit r35529 [2] upgrades polarssl from v 1.1(.3) to 1.2(.5), but introduces
compile errors for openvpn-devel (2.2.2) package present in feeds, as detailed
in [1].
The following small patch [3] fixes these compatibility issues.
[1]. https://dev.openwrt.org/ticket/12983
[2]. https://dev.openwrt.org/changeset/35529
[3]. http://community.openvpn.net/openvpn/attachment/ticket/250/220-allow-
polarssl-1.2.3.patch
Signed-off-by: Tijs Van Buggenhout
--
Index: net/openvpn-devel/Makefile
===
diff --git a/branches/packages_12.09/net/openvpn-devel/Makefile
b/branches/packages_12.09/net/openvpn-devel/Makefile
--- a/branches/packages_12.09/net/openvpn-devel/Makefile(revision 39304)
+++ b/branches/packages_12.09/net/openvpn-devel/Makefile(working copy)
@@ -11,7 +11,7 @@
PKG_REV:=5d4f5435a421299ed047485d8d99bdf9a0d22fd1
PKG_VERSION:=r$(PKG_REV)
-PKG_RELEASE=1
+PKG_RELEASE=2
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git
Index: net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
===
diff --git
a/branches/packages_12.09/net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
b/branches/packages_12.09/net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
new file mode 10644
--- /dev/null (revision 0)
+++
b/branches/packages_12.09/net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
(working copy)
@@ -0,0 +1,82 @@
+--- a/src/openvpn/crypto_polarssl.h
b/src/openvpn/crypto_polarssl.h
+@@ -60,7 +60,11 @@
+ #define OPENVPN_MODE_OFB POLARSSL_MODE_OFB
+
+ /** Cipher is in CFB mode */
++#if POLARSSL_VERSION_NUMBER < 0x0102
+ #define OPENVPN_MODE_CFB POLARSSL_MODE_CFB128
++#else
++#define OPENVPN_MODE_CFB POLARSSL_MODE_CFB
++#endif
+
+ /** Cipher should encrypt */
+ #define OPENVPN_OP_ENCRYPTPOLARSSL_ENCRYPT
+--- a/src/openvpn/ssl_polarssl.c
b/src/openvpn/ssl_polarssl.c
+@@ -67,6 +67,20 @@
+
+ static int default_ciphersuites[] =
+ {
++#if POLARSSL_VERSION_NUMBER >= 0x0102
++TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
++TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA,
++TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
++TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA,
++TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
++TLS_RSA_WITH_AES_256_CBC_SHA,
++TLS_RSA_WITH_CAMELLIA_256_CBC_SHA,
++TLS_RSA_WITH_AES_128_CBC_SHA,
++TLS_RSA_WITH_CAMELLIA_128_CBC_SHA,
++TLS_RSA_WITH_3DES_EDE_CBC_SHA,
++TLS_RSA_WITH_RC4_128_SHA,
++TLS_RSA_WITH_RC4_128_MD5,
++#else
+ SSL_EDH_RSA_AES_256_SHA,
+ SSL_EDH_RSA_CAMELLIA_256_SHA,
+ SSL_EDH_RSA_AES_128_SHA,
+@@ -79,6 +93,7 @@
+ SSL_RSA_DES_168_SHA,
+ SSL_RSA_RC4_128_SHA,
+ SSL_RSA_RC4_128_MD5,
++#endif
+ 0
+ };
+
+@@ -515,7 +530,9 @@
+ ssl_set_rng (ks_ssl->ctx, ctr_drbg_random, rand_ctx_get());
+
+ ALLOC_OBJ_CLEAR (ks_ssl->ssn, ssl_session);
++#if POLARSSL_VERSION_NUMBER < 0x0102
+ ssl_set_session (ks_ssl->ctx, 0, 0, ks_ssl->ssn );
++#endif
+ if (ssl_ctx->allowed_ciphers)
+ ssl_set_ciphersuites (ks_ssl->ctx, ssl_ctx->allowed_ciphers);
+ else
+@@ -828,7 +845,11 @@
+ ssl_get_version (ks_ssl->ctx),
+ ssl_get_ciphersuite(ks_ssl->ctx));
+
++#if POLARSSL_VERSION_NUMBER >= 0x0102
++ cert = ks_ssl->ssn->peer_cert;
++#else
+ cert = ks_ssl->ctx->peer_cert;
++#endif
+ if (cert != NULL)
+ {
+ openvpn_snprintf (s2, sizeof (s2), ", " counter_format " bit RSA",
(counter_type) cert->rsa.len * 8);
+--- a/src/openvpn/options.c
b/src/openvpn/options.c
+@@ -827,7 +827,12 @@
+ o->server_poll_timeout = 0;
+ #endif
+ #ifdef ENABLE_CRYPTO
++#ifdef ENABLE_CRYPTO_POLARSSL
++ o->ciphername = "BLOWFISH-CBC";
++ o->keysize = 16;
++#else
+ o->ciphername = "BF-CBC";
++#endif
+ o->ciphername_defined = true;
+ o->authname = "SHA1";
+ o->authname_defined = true;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][feeds] openvpn-devel: make openvpn compatible with polarssl 1.2.3 or newer [AA]
On Wednesday 22 January 2014 15:34:56 Tijs Van Buggenhout wrote:
> Only relevant for Attitude Adjustment, see trac #12982 [1].
>
> Commit r35529 [2] upgrades polarssl from v 1.1(.3) to 1.2(.5), but
> introduces compile errors for openvpn-devel (2.2.2) package present in
version of openvpn is 2.3_alpha3, sorry for that
> feeds, as detailed in [1].
>
> The following small patch [3] fixes these compatibility issues.
>
> [1]. https://dev.openwrt.org/ticket/12983
> [2]. https://dev.openwrt.org/changeset/35529
> [3]. http://community.openvpn.net/openvpn/attachment/ticket/250/220-allow-
> polarssl-1.2.3.patch
>
> Signed-off-by: Tijs Van Buggenhout
> --
The same ticket holds a more complete patch [4].
[4].
http://community.openvpn.net/openvpn/attachment/ticket/250/freetz.org-openvpn-2.3.0-polarssl-1.2.x-support.patch
Signed-off-by: Tijs Van Buggenhout
--
Index: net/openvpn-devel/Makefile
===
diff --git a/branches/packages_12.09/net/openvpn-devel/Makefile
b/branches/packages_12.09/net/openvpn-devel/Makefile
--- a/branches/packages_12.09/net/openvpn-devel/Makefile(revision 39304)
+++ b/branches/packages_12.09/net/openvpn-devel/Makefile(working copy)
@@ -11,7 +11,7 @@
PKG_REV:=5d4f5435a421299ed047485d8d99bdf9a0d22fd1
PKG_VERSION:=r$(PKG_REV)
-PKG_RELEASE=1
+PKG_RELEASE=2
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git
Index: net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
===
diff --git
a/branches/packages_12.09/net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
b/branches/packages_12.09/net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
new file mode 10644
--- /dev/null (revision 0)
+++
b/branches/packages_12.09/net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
(working copy)
@@ -0,0 +1,185 @@
+--- a/src/openvpn/crypto_polarssl.h
b/src/openvpn/crypto_polarssl.h
+@@ -60,7 +60,11 @@
+ #define OPENVPN_MODE_OFB POLARSSL_MODE_OFB
+
+ /** Cipher is in CFB mode */
++#if POLARSSL_VERSION_NUMBER < 0x0102
+ #define OPENVPN_MODE_CFB POLARSSL_MODE_CFB128
++#else
++#define OPENVPN_MODE_CFB POLARSSL_MODE_CFB
++#endif
+
+ /** Cipher should encrypt */
+ #define OPENVPN_OP_ENCRYPTPOLARSSL_ENCRYPT
+--- a/src/openvpn/options.c
b/src/openvpn/options.c
+@@ -827,7 +827,12 @@
+ o->server_poll_timeout = 0;
+ #endif
+ #ifdef ENABLE_CRYPTO
++#ifdef ENABLE_CRYPTO_POLARSSL
++ o->ciphername = "BLOWFISH-CBC";
++ o->keysize = 16;
++#else
+ o->ciphername = "BF-CBC";
++#endif
+ o->ciphername_defined = true;
+ o->authname = "SHA1";
+ o->authname_defined = true;
+--- a/src/openvpn/ssl_polarssl.h
b/src/openvpn/ssl_polarssl.h
+@@ -30,6 +30,7 @@
+ #ifndef SSL_POLARSSL_H_
+ #define SSL_POLARSSL_H_
+
++#include
+ #include
+
+ #if defined(ENABLE_PKCS11)
+@@ -73,7 +74,9 @@
+
+ struct key_state_ssl {
+ ssl_context *ctx;
++#if POLARSSL_VERSION_NUMBER < 0x0102
+ ssl_session *ssn;
++#endif
+ endless_buffer *ct_in;
+ endless_buffer *ct_out;
+ };
+--- a/src/openvpn/ssl_polarssl.c
b/src/openvpn/ssl_polarssl.c
+@@ -65,6 +65,7 @@
+ {
+ }
+
++#if POLARSSL_VERSION_NUMBER < 0x0102000
+ static int default_ciphersuites[] =
+ {
+ SSL_EDH_RSA_AES_256_SHA,
+@@ -81,6 +82,7 @@
+ SSL_RSA_RC4_128_MD5,
+ 0
+ };
++#endif
+
+ void
+ tls_ctx_server_new(struct tls_root_ctx *ctx)
+@@ -514,12 +516,18 @@
+
+ ssl_set_rng (ks_ssl->ctx, ctr_drbg_random, rand_ctx_get());
+
++#if POLARSSL_VERSION_NUMBER < 0x0102
+ ALLOC_OBJ_CLEAR (ks_ssl->ssn, ssl_session);
+ ssl_set_session (ks_ssl->ctx, 0, 0, ks_ssl->ssn );
++#endif
+ if (ssl_ctx->allowed_ciphers)
+ ssl_set_ciphersuites (ks_ssl->ctx, ssl_ctx->allowed_ciphers);
+ else
++#if POLARSSL_VERSION_NUMBER < 0x0102
+ ssl_set_ciphersuites (ks_ssl->ctx, default_ciphersuites);
++#else
++ ssl_set_ciphersuites (ks_ssl->ctx, ssl_default_ciphersuites);
++#endif
+
+ /* Initialise authentication information */
+ if (is_server)
+@@ -556,8 +564,10 @@
+ ssl_free(ks_ssl->ctx);
+ free(ks_ssl->ctx);
+ }
++#if POLARSSL_VERSION_NUMBER < 0x0102
+ if (ks_ssl->ssn)
+ free(ks_ssl->ssn);
++#endif
+ if (ks_ssl->ct_in) {
+ buf_free_entries(ks_ssl->ct_in);
+ free(ks_ssl->ct_in);
+@@ -818,7 +828,7 @@
+ void
+ print_details (struct key_state_ssl * ks_ssl, const char *prefix)
+ {
+- x509_cert *cert;
++ const x509_cert *cert;
+ char s1[256];
+ char s2[256];
+
+@@ -828,7 +838,11 @@
+ ssl_get_version (ks_ssl->ctx),
+ ssl_get_ciphersuite(ks_ssl->ctx));
+
++#if POLARSSL_VERSION_NUMBER < 0x0102
+ cert = ks_ssl->ctx->peer_cert;
++#else
++ cert = ssl_get_peer_cert(ks_ssl->ctx);
++#endif
+ if (cert != NULL)
+ {
+ openvpn_snprintf (s2, sizeof
Re: [OpenWrt-Devel] [PATCH][feeds] openvpn-devel: make openvpn compatible with polarssl 1.2.3 or newer [AA]
Hi, On Wed, Jan 22, 2014 at 03:34:56PM +0100, Tijs Van Buggenhout wrote: > Only relevant for Attitude Adjustment, see trac #12982 [1]. > > Commit r35529 [2] upgrades polarssl from v 1.1(.3) to 1.2(.5), but introduces > compile errors for openvpn-devel (2.2.2) package present in feeds, as > detailed > in [1]. Given that PolarSSL up to 1.2.9 has security relevant bugs, I'd suggest to upgrade PolarSSL up to 1.2.10, and openvpn-devel to 2.3.2 (which has the necessary changes to compile with polarssl 1.2.x). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpfRH7MEuErv.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] b53: Add BCM53128 switch support
The BCM53128 seems to be very similar to the BCM53125 but has some more ports.
Signed-off-by: Helmut Schaa
---
.../generic/files/drivers/net/phy/b53/b53_common.c | 14 +
.../generic/files/drivers/net/phy/b53/b53_mdio.c | 24 ++
.../generic/files/drivers/net/phy/b53/b53_priv.h | 4 +++-
3 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
index f6a5418..72b08e1 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
@@ -1130,6 +1130,19 @@ static const struct b53_chip_data b53_switch_chips[] = {
.sw_ops = &b53_switch_ops,
},
{
+ .chip_id = BCM53128_DEVICE_ID,
+ .dev_name = "BCM53128",
+ .alias = "bcm53128",
+ .vlans = 4096,
+ .enabled_ports = 0x1ff,
+ .cpu_port = B53_CPU_PORT,
+ .vta_regs = B53_VTA_REGS,
+ .duplex_reg = B53_DUPLEX_STAT_GE,
+ .jumbo_pm_reg = B53_JUMBO_PORT_MASK,
+ .jumbo_size_reg = B53_JUMBO_MAX_SIZE,
+ .sw_ops = &b53_switch_ops,
+ },
+ {
.chip_id = BCM63XX_DEVICE_ID,
.dev_name = "BCM63xx",
.alias = "bcm63xx",
@@ -1363,6 +1376,7 @@ int b53_switch_detect(struct b53_device *dev)
switch (id32) {
case BCM53115_DEVICE_ID:
case BCM53125_DEVICE_ID:
+ case BCM53128_DEVICE_ID:
case BCM53010_DEVICE_ID:
case BCM53011_DEVICE_ID:
case BCM53012_DEVICE_ID:
diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
b/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
index cacf32b..b7e6b59 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
@@ -389,6 +389,23 @@ static struct phy_driver b53_phy_driver_id3 = {
},
};
+/* BCM53128 */
+static struct phy_driver b53_phy_driver_id4 = {
+ .phy_id = 0x03625e14,
+ .name = "Broadcom B53 (4)",
+ .phy_id_mask= 0x1c00,
+ .features = 0,
+ .probe = b53_phy_probe,
+ .remove = b53_phy_remove,
+ .config_aneg= b53_phy_config_aneg,
+ .config_init= b53_phy_config_init,
+ .read_status= b53_phy_read_status,
+ .driver = {
+ .owner = THIS_MODULE,
+ },
+};
+
+
int __init b53_phy_driver_register(void)
{
int ret;
@@ -402,9 +419,15 @@ int __init b53_phy_driver_register(void)
goto err1;
ret = phy_driver_register(&b53_phy_driver_id3);
+ if (ret)
+ goto err2;
+
+ ret = phy_driver_register(&b53_phy_driver_id4);
if (!ret)
return 0;
+ phy_driver_unregister(&b53_phy_driver_id3);
+err2:
phy_driver_unregister(&b53_phy_driver_id2);
err1:
phy_driver_unregister(&b53_phy_driver_id1);
@@ -413,6 +436,7 @@ err1:
void __exit b53_phy_driver_unregister(void)
{
+ phy_driver_unregister(&b53_phy_driver_id4);
phy_driver_unregister(&b53_phy_driver_id3);
phy_driver_unregister(&b53_phy_driver_id2);
phy_driver_unregister(&b53_phy_driver_id1);
diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_priv.h
b/target/linux/generic/files/drivers/net/phy/b53/b53_priv.h
index d9881a1..ce5b530 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_priv.h
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_priv.h
@@ -46,6 +46,7 @@ enum {
BCM5398_DEVICE_ID = 0x98,
BCM53115_DEVICE_ID = 0x53115,
BCM53125_DEVICE_ID = 0x53125,
+ BCM53128_DEVICE_ID = 0x53128,
BCM63XX_DEVICE_ID = 0x6300,
BCM53010_DEVICE_ID = 0x53010,
BCM53011_DEVICE_ID = 0x53011,
@@ -137,7 +138,8 @@ static inline int is539x(struct b53_device *dev)
static inline int is531x5(struct b53_device *dev)
{
return dev->chip_id == BCM53115_DEVICE_ID ||
- dev->chip_id == BCM53125_DEVICE_ID;
+ dev->chip_id == BCM53125_DEVICE_ID ||
+ dev->chip_id == BCM53128_DEVICE_ID;
}
static inline int is63xx(struct b53_device *dev)
--
1.8.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] b53: Use phy_drivers_register
Using phy_drivers_register multiple phy drivers can be registered at once
which makes the code easier to read.
Signed-off-by: Helmut Schaa
---
.../generic/files/drivers/net/phy/b53/b53_mdio.c | 56 +-
1 file changed, 13 insertions(+), 43 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
b/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
index b7e6b59..3257acd 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
@@ -341,8 +341,9 @@ static int b53_phy_read_status(struct phy_device *phydev)
return 0;
}
-/* BCM5325, BCM539x */
-static struct phy_driver b53_phy_driver_id1 = {
+static struct phy_driver b53_phy_drivers[] = {
+{
+ /* BCM5325, BCM539x */
.phy_id = 0x0143bc00,
.name = "Broadcom B53 (1)",
.phy_id_mask= 0x1c00,
@@ -355,10 +356,8 @@ static struct phy_driver b53_phy_driver_id1 = {
.driver = {
.owner = THIS_MODULE,
},
-};
-
-/* BCM53125 */
-static struct phy_driver b53_phy_driver_id2 = {
+}, {
+ /* BCM53125 */
.phy_id = 0x03625c00,
.name = "Broadcom B53 (2)",
.phy_id_mask= 0x1c00,
@@ -371,10 +370,8 @@ static struct phy_driver b53_phy_driver_id2 = {
.driver = {
.owner = THIS_MODULE,
},
-};
-
-/* BCM5365 */
-static struct phy_driver b53_phy_driver_id3 = {
+}, {
+ /* BCM5365 */
.phy_id = 0x00406000,
.name = "Broadcom B53 (3)",
.phy_id_mask= 0x1c00,
@@ -387,10 +384,8 @@ static struct phy_driver b53_phy_driver_id3 = {
.driver = {
.owner = THIS_MODULE,
},
-};
-
-/* BCM53128 */
-static struct phy_driver b53_phy_driver_id4 = {
+}, {
+ /* BCM53128 */
.phy_id = 0x03625e14,
.name = "Broadcom B53 (4)",
.phy_id_mask= 0x1c00,
@@ -403,43 +398,18 @@ static struct phy_driver b53_phy_driver_id4 = {
.driver = {
.owner = THIS_MODULE,
},
-};
+} };
int __init b53_phy_driver_register(void)
{
- int ret;
-
- ret = phy_driver_register(&b53_phy_driver_id1);
- if (ret)
- return ret;
-
- ret = phy_driver_register(&b53_phy_driver_id2);
- if (ret)
- goto err1;
-
- ret = phy_driver_register(&b53_phy_driver_id3);
- if (ret)
- goto err2;
-
- ret = phy_driver_register(&b53_phy_driver_id4);
- if (!ret)
- return 0;
-
- phy_driver_unregister(&b53_phy_driver_id3);
-err2:
- phy_driver_unregister(&b53_phy_driver_id2);
-err1:
- phy_driver_unregister(&b53_phy_driver_id1);
- return ret;
+ return phy_drivers_register(b53_phy_drivers,
+ ARRAY_SIZE(b53_phy_drivers));
}
void __exit b53_phy_driver_unregister(void)
{
- phy_driver_unregister(&b53_phy_driver_id4);
- phy_driver_unregister(&b53_phy_driver_id3);
- phy_driver_unregister(&b53_phy_driver_id2);
- phy_driver_unregister(&b53_phy_driver_id1);
+ phy_drivers_unregister(b53_phy_drivers, ARRAY_SIZE(b53_phy_drivers));
}
module_init(b53_phy_driver_register);
--
1.8.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
On Wed, 2014-01-22 at 13:39 +0100, Matti Laakso wrote: > > The Home Hub 2B has both nand and nor flash connected to the ebu, plus > > an ath9k pci wireless card, and the main difficulty is getting all three > > working at the same time without interfering with each other. The nand > > driver currently in trunk works fine, provided that open-drain is > > enabled on the ebu cs1 pin, and provided that wireless is off. However, > > the only way to get the nor chip to work reliably seems to be disable > > open-drain on ebu cs1, at which point the nand driver generates jffs2 > > errors. Regardless whether open-drain is enabled or not, switching on > > wireless also causes jffs2 errors. > > Based on my experience with the boards with NOR only, the EBU_CS1 pin > should always be driven (i.e., not open-drain) for the flash not to get > corrupted by PCI. If it is not driven, it takes some time for the pin to > be pulled up (depending on the pull-up resistors), and the flash chip > may still be enabled when the PCI transfers start. > > As far as I can see, the problem here is that for two flash chips you > need two chip select signals. IIRC, the EBU always uses GPIO23 > (EBU_CS1), no matter whether you use NAND or NOR. So you likely need > another GPIO to select between NAND and NOR, which you have to toggle > manually. Does the original firmware have access to both NAND and NOR > simultaneously? Or does the original bootloader disable NOR before > booting the firmware? > > Matti Laakso > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Interesting! I had assumed either that there was a cs0 pin, but that it did not appear anywhere in the sources because it was not reconfigurable in the way cs1 is, or else (but I don't know enough about electronics to know whether this is feasible in practice) that both nand and nor on the HH2B were connected to cs1, one of them directly and the other through an inverter, so that whenever one was selected the other was deselected. On the HH2B nor contains the uboot and the uboot environment, nand contains everything else. I don't think the original bootloader disables the nor, because uboot can be reflashed from within the factory firmware. But I am slightly puzzled that there is no trace of the nor driver loading in the bootlog on the wiki. I no longer have the original firmware binary to check again for myself. I'll have to have a closer look at the sources (which are not complete) and see if I can work out what is going on. Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
> Interesting! I had assumed either that there was a cs0 pin, but that > it did not appear anywhere in the sources because it was not > reconfigurable in the way cs1 is, or else (but I don't know enough > about electronics to know whether this is feasible in practice) > that both nand and nor on the HH2B were connected to cs1, one of > them directly and the other through an inverter, so that whenever > one was selected the other was deselected. Actually there is a CS0. Silly me. CS0 and CS1 then correspond to EBU banks 0 and 1. It's just that sometimes only bank 1 is used, but here obviously both are used. Sorry for the confusion. Matti ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] b53: Add BCM53128 switch support
Hi,
On Wed, Jan 22, 2014 at 4:58 PM, Helmut Schaa
wrote:
> The BCM53128 seems to be very similar to the BCM53125 but has some more ports.
>
> Signed-off-by: Helmut Schaa
> ---
> .../generic/files/drivers/net/phy/b53/b53_common.c | 14 +
> .../generic/files/drivers/net/phy/b53/b53_mdio.c | 24
> ++
> .../generic/files/drivers/net/phy/b53/b53_priv.h | 4 +++-
> 3 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> index f6a5418..72b08e1 100644
> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> @@ -1130,6 +1130,19 @@ static const struct b53_chip_data b53_switch_chips[] =
> {
> .sw_ops = &b53_switch_ops,
> },
> {
> + .chip_id = BCM53128_DEVICE_ID,
> + .dev_name = "BCM53128",
> + .alias = "bcm53128",
> + .vlans = 4096,
> + .enabled_ports = 0x1ff,
> + .cpu_port = B53_CPU_PORT,
> + .vta_regs = B53_VTA_REGS,
> + .duplex_reg = B53_DUPLEX_STAT_GE,
> + .jumbo_pm_reg = B53_JUMBO_PORT_MASK,
> + .jumbo_size_reg = B53_JUMBO_MAX_SIZE,
> + .sw_ops = &b53_switch_ops,
> + },
> + {
> .chip_id = BCM63XX_DEVICE_ID,
> .dev_name = "BCM63xx",
> .alias = "bcm63xx",
> @@ -1363,6 +1376,7 @@ int b53_switch_detect(struct b53_device *dev)
> switch (id32) {
> case BCM53115_DEVICE_ID:
> case BCM53125_DEVICE_ID:
> + case BCM53128_DEVICE_ID:
> case BCM53010_DEVICE_ID:
> case BCM53011_DEVICE_ID:
> case BCM53012_DEVICE_ID:
> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
> b/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
> index cacf32b..b7e6b59 100644
> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
> @@ -389,6 +389,23 @@ static struct phy_driver b53_phy_driver_id3 = {
> },
> };
>
> +/* BCM53128 */
> +static struct phy_driver b53_phy_driver_id4 = {
> + .phy_id = 0x03625e14,
> + .name = "Broadcom B53 (4)",
> + .phy_id_mask= 0x1c00,
> + .features = 0,
> + .probe = b53_phy_probe,
> + .remove = b53_phy_remove,
> + .config_aneg= b53_phy_config_aneg,
> + .config_init= b53_phy_config_init,
> + .read_status= b53_phy_read_status,
> + .driver = {
> + .owner = THIS_MODULE,
> + },
> +};
This one should be completely unnecessary:
0x03625e14 & 0x1c00 == 0x3625c00, which is the phy_id of
driver_id2, so I don't see how it could ever match (or how id2 then
could match, depending on in which order linux probes).
Apart from that I don't see any issues (adding support for BCM53118 is
probably analogue).
Regards
Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] busybox: backport dd conv=swab from 1.22
Some boards have the WLAN EEPROM stored in flash in big-endian format,
whereas the driver requires the EEPROM in little-endian format. The
conv=swab option in dd is particularly useful in this case. This patch
backports this feature from busybox-1.22 based on the following commits:
commitb941316ae5313be523b64f0a9151ee4decb2b35b dd: support conv=swab
commit8395bd3f52f8ed46fa3ffc316b2d113afa748bae dd: fix example in a
comment. No code changes.
commit5b9910f0a4a1b7976c46e6f849aaa263180e5521 dd: fail if swab is
attempted on odd-sized block
commit0ff0b320a2dbb5e0b5fa245ffd9b2648d7026843 dd: code shrink
v2: include the commit messages from upstream
Signed-off-by: Matti Laakso
---
Index: trunk/package/utils/busybox/patches/008-backport-dd-conv-swab.patch
===
--- trunk/package/utils/busybox/patches/008-backport-dd-conv-swab.patch
(revision 0)
+++ trunk/package/utils/busybox/patches/008-backport-dd-conv-swab.patch
(working copy)
@@ -0,0 +1,97 @@
+--- a/coreutils/dd.c
b/coreutils/dd.c
+@@ -10,7 +10,7 @@
+
+ //usage:#define dd_trivial_usage
+ //usage: "[if=FILE] [of=FILE] " IF_FEATURE_DD_IBS_OBS("[ibs=N] [obs=N]
") "[bs=N] [count=N] [skip=N]\n"
+-//usage: " [seek=N]" IF_FEATURE_DD_IBS_OBS("
[conv=notrunc|noerror|sync|fsync]")
++//usage: " [seek=N]" IF_FEATURE_DD_IBS_OBS("
[conv=notrunc|noerror|sync|fsync|swab]")
+ //usage:#define dd_full_usage "\n\n"
+ //usage: "Copy a file with converting and formatting\n"
+ //usage: "\n if=FILE Read from FILE instead of stdin"
+@@ -30,6 +30,7 @@
+ //usage: "\n conv=noerrorContinue after read errors"
+ //usage: "\n conv=sync Pad blocks with zeros"
+ //usage: "\n conv=fsync Physically write data out before
finishing"
++//usage: "\n conv=swab Swap every pair of bytes"
+ //usage: )
+ //usage: "\n"
+ //usage: "\nNumbers may be suffixed by c (x1), w (x2), b (x512), kD
(x1000), k (x1024),"
+@@ -155,9 +156,10 @@ int dd_main(int argc UNUSED_PARAM, char
+ FLAG_SYNC= 1 << 1,
+ FLAG_NOERROR = 1 << 2,
+ FLAG_FSYNC = 1 << 3,
++ FLAG_SWAB= 1 << 4,
+ /* end of conv flags */
+- FLAG_TWOBUFS = 1 << 4,
+- FLAG_COUNT = 1 << 5,
++ FLAG_TWOBUFS = 1 << 5,
++ FLAG_COUNT = 1 << 6,
+ };
+ static const char keywords[] ALIGN1 =
+ "bs\0""count\0""seek\0""skip\0""if\0""of\0"
+@@ -167,7 +169,7 @@ int dd_main(int argc UNUSED_PARAM, char
+ ;
+ #if ENABLE_FEATURE_DD_IBS_OBS
+ static const char conv_words[] ALIGN1 =
+- "notrunc\0""sync\0""noerror\0""fsync\0";
++ "notrunc\0""sync\0""noerror\0""fsync\0""swab\0";
+ #endif
+ enum {
+ OP_bs = 0,
+@@ -185,11 +187,11 @@ int dd_main(int argc UNUSED_PARAM, char
+ OP_conv_sync,
+ OP_conv_noerror,
+ OP_conv_fsync,
++ OP_conv_swab,
+ /* Unimplemented conv=XXX: */
+ //nocreat do not create the output file
+ //excl fail if the output file already exists
+ //fdatasync physically write output file data before finishing
+- //swab swap every pair of input bytes
+ //lcase change upper case to lower case
+ //ucase change lower case to upper case
+ //block pad newline-terminated records with spaces to cbs-size
+@@ -207,12 +209,14 @@ int dd_main(int argc UNUSED_PARAM, char
+ struct {
+ int flags;
+ size_t oc;
++ ssize_t prev_read_size; /* for detecting swab failure */
+ off_t count;
+ off_t seek, skip;
+ const char *infile, *outfile;
+ } Z;
+ #define flags (Z.flags )
+ #define oc (Z.oc )
++#define prev_read_size (Z.prev_read_size)
+ #define count (Z.count )
+ #define seek(Z.seek )
+ #define skip(Z.skip )
+@@ -375,6 +379,27 @@ int dd_main(int argc UNUSED_PARAM, char
+* conv=noerror just ignores input bad blocks */
+ n = 0;
+ }
++ if (flags & FLAG_SWAB) {
++ uint16_t *p16;
++ ssize_t n2;
++
++ /* Our code allows only last read to be odd-sized */
++ if (prev_read_size & 1)
++ bb_error_msg_and_die("can't swab %lu byte
buffer",
++ (unsigned long)prev_read_size);
++ prev_read_size = n;
++
++ /* If n is odd, last byte is not swapped:
++ * echo -n "qwe" | dd conv=swab
++ * prints "wqe".
++ */
++ p16 = (void*) ibuf;
++
[OpenWrt-Devel] [PATCH v2] lantiq: do an endianness swap to the RT2860 eeprom for ARV752DPW(22)
ARV7510PW22, ARV752DPW and ARV752DPW22 have the RT2860 eeprom stored in flash as big-endian, but the driver needs it in little-endian format. We have to swab it before handing it over. This requires my earlier patch for busybox. Funnily enough, ARV752DPW works also with the incorrect eeprom, but undoubtedly unoptimally. I have a hunch that also the final remaining Lantiq board would require this swabbing, but I'm not sure, so I just swab it in the three boards that I know about. v2: * Swab also on ARV7510PW22 based on feedback from Alvaro Rojas * Fix the offset with bs=2 Signed-off-by: Matti Laakso --- Index: trunk/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom === --- trunk/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom (revision 39356) +++ trunk/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom (working copy) @@ -10,6 +10,7 @@ local part=$1 local offset=$2 local count=$3 + local swab=$4 local mtd . /lib/functions.sh @@ -17,9 +18,13 @@ mtd=$(find_mtd_part $part) [ -n "$mtd" ] || \ rt2x00_eeprom_die "no mtd device found for partition $part" - - dd if=$mtd of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count || \ - rt2x00_eeprom_die "failed to extract from $mtd" + if [ $swab -gt 0 ]; then + dd if=$mtd of=/lib/firmware/$FIRMWARE bs=2 skip=$offset count=$count conv=swab || \ + rt2x00_eeprom_die "failed to extract from $mtd" + else + dd if=$mtd of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count || \ + rt2x00_eeprom_die "failed to extract from $mtd" + fi } [ -e /lib/firmware/$FIRMWARE ] && exit 0 @@ -29,9 +34,12 @@ "RT2860.eeprom" ) local board=$(lantiq_board_id) case $board in - ARV7510PW22|ARV7525PW|ARV752DPW|ARV752DPW22) - rt2x00_eeprom_extract "board_config" 1040 512 + ARV7510PW22|ARV752DPW|ARV752DPW22) + rt2x00_eeprom_extract "board_config" 520 256 1 ;; + ARV7525PW) + rt2x00_eeprom_extract "board_config" 1040 512 0 + ;; *) rt2x00_eeprom_die "board $board is not supported yet" ;; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
On Wed, 2014-01-22 at 13:38 +0100, Jonas Gorski wrote: > On Wed, Jan 22, 2014 at 1:02 PM, Ben Mulvihill > wrote: > > On Wed, 2014-01-22 at 00:42 +0100, John Crispin wrote: > >> On 21/01/2014 21:55, David Lang wrote: > >> > On Tue, 21 Jan 2014, Ben Mulvihill wrote: > >> > > >> >> The nand driver currently in trunk works fine, provided ... > >> > > >> > what is the current status of nand flash support? I asked about this > >> > within the last couple of weeks and was told that supporing devices > >> > with nand flash would require major surgery to the squashfs code to > >> > allow it to deal with badblocks. > >> > > >> > has this been done? was I misinformed on what the problem is? or is > >> > this still a problem and devices with nand flash can work, but only if > >> > they avoid squashfs? > >> > > >> > >> > >> Hi David, > >> > >> Daniel is working on splitting the mount_root, block, extroot and all > >> the other mtd/block related tools to a new repo called fstools. While > >> doing so we are doing some cleanup of the code. i expect this to hit > >> trunk within the next week. Once this is done we will add nand specific > >> features to the repo. Once that is done, openwrt should have proper > >> support for ubi including functional sysupgrade support (using > >> ubi-format) ... > >> > >> John > >> ___ > >> openwrt-devel mailing list > >> openwrt-devel@lists.openwrt.org > >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > How critical is the bad blocks problem in practice? The above will > > solve the lack of bad block handling in squashfs, but unless I've > > missed the point, on a typical board won't the kernel itself still > > be loaded directly from flash? Or do you assume that the bootloader > > will be able to handle ubi as well? > > SLC NAND usually is rather stable, but bad blocks exist, and bit flips > do happen from time to time, so you need to relocate blocks then. MLC > NAND is much worse, there bitflips are rather common, and you need to > actually use a threshold of how many correctable bitflips you accept > before you move the block somewhere else. To make matters worse, MLC > NANDs support a lot less erase cycles than SLC NANDs (1000+ vs. > 100k+), so using ubi-format more than once for initial format is a bad > idea there (as it will cause all blocks to get erased once). > > A NAND capable Filesystem needs to be capable of three things: > a) Be aware that blocks might be bad and skip them (and not just fail > if it encounters them) > b) Be aware that blocks might get bit flips just from reading, and be > prepared to move the contents to a "fresh" block > c) Not rely on the order of the blocks on the flash > > And squashfs fails for all three. > > There's of course the possibility of using a flash translation layer > like UBI, that will take over all three things and hide all the NAND > quirks from filesystems using it. > > > > Jonas > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Thanks for the detailed explanation. So squashfs on nand is definitely a bad thing. For the same reasons surely loading the firmware straight from raw nand flash is a bad thing too. But the only alternative is to have a layer (ubi or a nand-aware filesystem) between the nand and the firmware image as well, which then means that the bootloader has be able to handle that layer. Have I understood correctly? Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
On Wed, 2014-01-22 at 18:28 +0100, Matti Laakso wrote: > > Interesting! I had assumed either that there was a cs0 pin, but that > > it did not appear anywhere in the sources because it was not > > reconfigurable in the way cs1 is, or else (but I don't know enough > > about electronics to know whether this is feasible in practice) > > that both nand and nor on the HH2B were connected to cs1, one of > > them directly and the other through an inverter, so that whenever > > one was selected the other was deselected. > > Actually there is a CS0. Silly me. CS0 and CS1 then correspond to EBU > banks 0 and 1. It's just that sometimes only bank 1 is used, but here > obviously both are used. Sorry for the confusion. > > Matti > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel The fact that we found we needed extra waits ties in with what you said about how turning open drain on and off affects timing, except that the observed behaviour seems to be the wrong way round. Also, if there are separate cs0 and cs1 pins, why should the open drain setting on CS1 affects both nand and nor. It is all very odd! Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Clean up NFSv4 dependencies
On 01/15/2014 02:49 PM, Daniel Colascione wrote: This patch removes the NFSv4 package and makes NFSv4 support a configuration option for existing packages. Did I not add the right maintainers to my original message? I don't recall finding a specific owner when I looked. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Zabbix: update to 2.2.1
It's running on one of my servers for about a day, update went smooth.
Acked-by: Stefan Hellermann
2014/1/22 Etienne CHAMPETIER
>
> With this new version of zabbix we do not need
> uname and hostname anymore, see
> https://svn.zabbix.com/browse/ZBX-5616
> Only compile tested for now
>
> Signed-off-by: Etienne CHAMPETIER
> ---
> admin/zabbix/Makefile | 10 ++
> admin/zabbix/patches/001-cross_compile.patch | 6 +++---
> admin/zabbix/patches/002-fix-res_send-on-uclibc.patch | 14 +++---
> admin/zabbix/patches/002-uclibc_loadavg.patch | 8
> admin/zabbix/patches/010-change-agentd-config.patch | 8
> 5 files changed, 20 insertions(+), 26 deletions(-)
>
> diff --git a/admin/zabbix/Makefile b/admin/zabbix/Makefile
> index 5ee8425..9088447 100644
> --- a/admin/zabbix/Makefile
> +++ b/admin/zabbix/Makefile
> @@ -8,12 +8,12 @@
> include $(TOPDIR)/rules.mk
>
> PKG_NAME:=zabbix
> -PKG_VERSION:=2.0.8
> +PKG_VERSION:=2.2.1
> PKG_RELEASE:=1
>
> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> PKG_SOURCE_URL:=@SF/zabbix
> -PKG_MD5SUM:=8fef9e6f499295211dd9b2a9db96464b
> +PKG_MD5SUM:=558497839b13a548f533eb2fc951a4e3
>
> PKG_INSTALL:=1
>
> @@ -99,12 +99,6 @@ As it uses libiwinfo, it works with all wifi devices
> supported by openwrt.
> See http://wiki.openwrt.org/doc/howto/zabbix for ready to use zabbix
> templates.
> endef
>
> -
> -define Package/zabbix-agentd/config
> - select BUSYBOX_CONFIG_HOSTNAME if !PACKAGE_net-tools-hostname
> - select BUSYBOX_CONFIG_UNAME if !PACKAGE_coreutils-uname
> -endef
> -
> CONFIGURE_ARGS+= \
> --enable-agent \
> --enable-server \
> diff --git a/admin/zabbix/patches/001-cross_compile.patch
> b/admin/zabbix/patches/001-cross_compile.patch
> index 8716e84..cf8b6d8 100644
> --- a/admin/zabbix/patches/001-cross_compile.patch
> +++ b/admin/zabbix/patches/001-cross_compile.patch
> @@ -1,6 +1,6 @@
> a/configure.in 2012-06-21 21:32:23.707912790 +
> -+++ b/configure.in 2012-06-21 21:33:36.213554564 +
> -@@ -802,25 +802,8 @@
> +--- a/configure.in
> b/configure.in
> +@@ -804,25 +804,8 @@ dnl
>
> dnl Check for %qu format (FreeBSD 4.x)
> dnl FreeBSD 4.x does not support %llu
> diff --git a/admin/zabbix/patches/002-fix-res_send-on-uclibc.patch
> b/admin/zabbix/patches/002-fix-res_send-on-uclibc.patch
> index 3190659..7072f03 100644
> --- a/admin/zabbix/patches/002-fix-res_send-on-uclibc.patch
> +++ b/admin/zabbix/patches/002-fix-res_send-on-uclibc.patch
> @@ -1,6 +1,6 @@
> a/configure.in 2013-02-14 18:29:28.145419003 +0100
> -+++ b/configure.in 2013-02-14 18:28:42.873418092 +0100
> -@@ -149,6 +149,10 @@
> +--- a/configure.in
> b/configure.in
> +@@ -151,6 +151,10 @@ if test "x$found_resolv" != "xyes"; then
> AC_MSG_ERROR([Unable to do DNS lookups (libresolv check failed)])
> fi
> LIBS="${LIBS} ${RESOLV_LIBS}"
> @@ -11,9 +11,9 @@
>
> dnl *
> dnl * *
> a/src/libs/zbxsysinfo/common/net.c 2012-06-21 19:49:46.610567432 +
> -+++ b/src/libs/zbxsysinfo/common/net.c 2012-06-21 19:50:35.816628541 +
> -@@ -418,6 +418,7 @@
> +--- a/src/libs/zbxsysinfo/common/net.c
> b/src/libs/zbxsysinfo/common/net.c
> +@@ -421,6 +421,7 @@ static int dns_query(AGENT_REQUEST *requ
> #else /* not _WINDOWS */
> res_init(); /* initialize always, settings might have changed */
>
> @@ -21,7 +21,7 @@
> if (-1 == (res = res_mkquery(QUERY, zone, C_IN, type, NULL, 0, NULL,
> buf, sizeof(buf
> return SYSINFO_RET_FAIL;
>
> -@@ -436,6 +437,11 @@
> +@@ -439,6 +440,11 @@ static intdns_query(AGENT_REQUEST *requ
> _res.retry = retry;
>
> res = res_send(buf, res, answer.buffer, sizeof(answer.buffer));
> diff --git a/admin/zabbix/patches/002-uclibc_loadavg.patch
> b/admin/zabbix/patches/002-uclibc_loadavg.patch
> index 6effabb..4bf3f77 100644
> --- a/admin/zabbix/patches/002-uclibc_loadavg.patch
> +++ b/admin/zabbix/patches/002-uclibc_loadavg.patch
> @@ -1,5 +1,5 @@
> a/src/libs/zbxsysinfo/linux/cpu.c 2013-02-12 12:27:22.0 +0100
> -+++ b/src/libs/zbxsysinfo/linux/cpu.c 2013-02-14 18:38:02.517429349 +0100
> +--- a/src/libs/zbxsysinfo/linux/cpu.c
> b/src/libs/zbxsysinfo/linux/cpu.c
> @@ -21,6 +21,45 @@
> #include "sysinfo.h"
> #include "stats.h"
> @@ -43,6 +43,6 @@
> +}
> +#endif
> +
> - int SYSTEM_CPU_NUM(const char *cmd, const char *param, unsigned flags,
> AGENT_RESULT *result)
> + int SYSTEM_CPU_NUM(AGENT_REQUEST *request, AGENT_RESULT *result)
> {
> - chartmp[16];
> + char*type;
> diff --git a/admin/zabbix/patches/010-change-agentd-config.patch
> b/admin/zabbix/patches/010-change-agentd-config.patch
> index 58424e9..cf5083e 100644
> --- a/admin/zabbix/patches/010-chan
Re: [OpenWrt-Devel] [PATCH 1/2] b53: Add BCM53128 switch support
On Wed, Jan 22, 2014 at 9:40 PM, Jonas Gorski wrote:
> Hi,
>
> On Wed, Jan 22, 2014 at 4:58 PM, Helmut Schaa
> wrote:
>> The BCM53128 seems to be very similar to the BCM53125 but has some more
>> ports.
>>
>> Signed-off-by: Helmut Schaa
>> ---
>> .../generic/files/drivers/net/phy/b53/b53_common.c | 14 +
>> .../generic/files/drivers/net/phy/b53/b53_mdio.c | 24
>> ++
>> .../generic/files/drivers/net/phy/b53/b53_priv.h | 4 +++-
>> 3 files changed, 41 insertions(+), 1 deletion(-)
>>
>> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>> b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>> index f6a5418..72b08e1 100644
>> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>> @@ -1130,6 +1130,19 @@ static const struct b53_chip_data b53_switch_chips[]
>> = {
>> .sw_ops = &b53_switch_ops,
>> },
>> {
>> + .chip_id = BCM53128_DEVICE_ID,
>> + .dev_name = "BCM53128",
>> + .alias = "bcm53128",
>> + .vlans = 4096,
>> + .enabled_ports = 0x1ff,
>> + .cpu_port = B53_CPU_PORT,
>> + .vta_regs = B53_VTA_REGS,
>> + .duplex_reg = B53_DUPLEX_STAT_GE,
>> + .jumbo_pm_reg = B53_JUMBO_PORT_MASK,
>> + .jumbo_size_reg = B53_JUMBO_MAX_SIZE,
>> + .sw_ops = &b53_switch_ops,
>> + },
>> + {
>> .chip_id = BCM63XX_DEVICE_ID,
>> .dev_name = "BCM63xx",
>> .alias = "bcm63xx",
>> @@ -1363,6 +1376,7 @@ int b53_switch_detect(struct b53_device *dev)
>> switch (id32) {
>> case BCM53115_DEVICE_ID:
>> case BCM53125_DEVICE_ID:
>> + case BCM53128_DEVICE_ID:
>> case BCM53010_DEVICE_ID:
>> case BCM53011_DEVICE_ID:
>> case BCM53012_DEVICE_ID:
>> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
>> b/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
>> index cacf32b..b7e6b59 100644
>> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
>> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
>> @@ -389,6 +389,23 @@ static struct phy_driver b53_phy_driver_id3 = {
>> },
>> };
>>
>> +/* BCM53128 */
>> +static struct phy_driver b53_phy_driver_id4 = {
>> + .phy_id = 0x03625e14,
>> + .name = "Broadcom B53 (4)",
>> + .phy_id_mask= 0x1c00,
>> + .features = 0,
>> + .probe = b53_phy_probe,
>> + .remove = b53_phy_remove,
>> + .config_aneg= b53_phy_config_aneg,
>> + .config_init= b53_phy_config_init,
>> + .read_status= b53_phy_read_status,
>> + .driver = {
>> + .owner = THIS_MODULE,
>> + },
>> +};
>
> This one should be completely unnecessary:
>
> 0x03625e14 & 0x1c00 == 0x3625c00, which is the phy_id of
> driver_id2, so I don't see how it could ever match (or how id2 then
> could match, depending on in which order linux probes).
Indeed, you're right. Let me fix this up ...
> Apart from that I don't see any issues (adding support for BCM53118 is
> probably analogue).
I'd guess so as well but I only have access to a BCM53128.
Helmut
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
