Re: [OpenWrt-Devel] [PATCH 3/3] b53: create slave devices for ports
I'm also very interested in implementing a switchdev driver (seems to be a good direction for this type of work), so I'd like to see any efforts in this direction so far which I can use as a base for my driver. I was waiting for the switch to Linux 3.19 for the initial code be be easily available. Charlie On 26/02/15 19:58, Alexandru Ardelean wrote: Fully agree on converging. I missed Rafal's switchdev effort. Before starting on this work, I first tried to look into net/dsa in the Linux kernel. I did notice your patches there and started on that. I got to a decent point, but then I was stuck at some issues. I later found out that I needed to adjust the MTU and manually pad potential runt packets. I also found out the switchdev API, which seems like it's in an rather infant state. In any case, I think DSA is the better approach, so my vote is for b53 + DSA (or DSA-like) in the kernel. For this swconfig effort, the reasoning is that our current firmware is @ kernel 3.10, and most of our current target setup logic relies on swconfig; I backported DSA, but because of time/effort constraints to also port, test & validate any b53 PHY setup logic in DSA, we decided that it's easier to adapt the current b53 driver, and later re-visit DSA. And because we have time constraints, there's no telling if we'll have the time to port b53 to DSA, so this patchset is at least meant to share our effort/findings regarding the b53 + LAN ports + Broadcom tag. If things get settled/more calm, I might try to do an effort to do b53 + DSA (if nobody does that before me). Regarding this patchset, I have no objections regarding whether it gets accepted/dropped. Either way, we'll keep it in our tree for a while, and re-evaluate any other DSA (or DSA-like) frameworks later. Thanks Alex On Thu, Feb 26, 2015 at 8:24 PM, Florian Fainelli mailto:f.faine...@gmail.com>> wrote: On 25/02/15 07:24, Alexandru Ardelean wrote: > Feature implemented and tested on BCM53128. > > Slave devices logic copied from the Linux kernel from Marvell's DSA > driver ( linux/net/dsa/ ). > Also the logic for the Broadcom tag processing has been copied from there. There are different efforts here going on, and I would like to at least 3 different people (you, Rafal and myself) can converge to an identical solution that fits everybody here. What net-next supports today is: - broadcom tags in net/dsa/tag_brcm.c, 4-bytes format, identical to yours AFAICT - HW bridging support for bcm_sf2 (roboswitch successor) What's missing: - adding VLAN configuration, which is what Rafal has been doing using here: http://thread.gmane.org/gmane.linux.network/351503 There are a number of things that I want to rework in DSA such that we can almost immediately leverage OpenWrt's switch drivers, where the entry point is a phy_driver, and have them register as switches (DSA or something wider) eventually [1], such that DSA handles the slave devices creation, and also handles the transmission/reception of Broadcom tags for us. This is work in progress, but I expect the patches would be ready by the end of this week. [1]: http://www.spinics.net/lists/netdev/msg295942.html > > OpenWRT's eth_mangle_rx/tx() patch/code is being used to tap into > the packets to/from the ethernet chip since it's convenient. > > This code will create lanX (X = 1..B53_N_PORTS) devices. > All traffic from the ethX device will be forwarded the proper lanX device. > So, sw_port0_traffic == lan1_traffic and so on. > > The slave devices logic has been put into it's own file. > Should this logic be desired to be extended to swconfig or other > switch chips, it should be convenient to just move the slave.c/h files. > > Note: if enable_vlan == 1, be sure to configure VLAN per lanX device > in '/etc/config/network' > > Signed-off-by: Alexandru Ardelean mailto:ardeleana...@gmail.com>> > --- > .../generic/files/drivers/net/phy/b53/Makefile| 2 +- > .../generic/files/drivers/net/phy/b53/b53_common.c | 3 + > .../generic/files/drivers/net/phy/b53/b53_hdr.c | 114 +++- > .../generic/files/drivers/net/phy/b53/b53_priv.h | 2 + > .../generic/files/drivers/net/phy/b53/slave.c | 196 + > .../generic/files/drivers/net/phy/b53/slave.h | 38 > 6 files changed, 352 insertions(+), 3 deletions(-) > create mode 100644 target/linux/generic/files/drivers/net/phy/b53/slave.c > create mode 100644 target/linux/generic/files/drivers/net/phy/b53/slave.h > > diff --git a/target/linux/generic/files/drivers/net/phy/b53/Makefile b/target/linux/generic/files/drivers/net/phy/b53/Makefile > index 6c809f9..c74f82b 100644 > --- a/target/linux/generic/files/drivers/net/phy/b53/Makefile >
Re: [OpenWrt-Devel] [PATCH 3/3] b53: create slave devices for ports
Fully agree on converging. I missed Rafal's switchdev effort. Before starting on this work, I first tried to look into net/dsa in the Linux kernel. I did notice your patches there and started on that. I got to a decent point, but then I was stuck at some issues. I later found out that I needed to adjust the MTU and manually pad potential runt packets. I also found out the switchdev API, which seems like it's in an rather infant state. In any case, I think DSA is the better approach, so my vote is for b53 + DSA (or DSA-like) in the kernel. For this swconfig effort, the reasoning is that our current firmware is @ kernel 3.10, and most of our current target setup logic relies on swconfig; I backported DSA, but because of time/effort constraints to also port, test & validate any b53 PHY setup logic in DSA, we decided that it's easier to adapt the current b53 driver, and later re-visit DSA. And because we have time constraints, there's no telling if we'll have the time to port b53 to DSA, so this patchset is at least meant to share our effort/findings regarding the b53 + LAN ports + Broadcom tag. If things get settled/more calm, I might try to do an effort to do b53 + DSA (if nobody does that before me). Regarding this patchset, I have no objections regarding whether it gets accepted/dropped. Either way, we'll keep it in our tree for a while, and re-evaluate any other DSA (or DSA-like) frameworks later. Thanks Alex On Thu, Feb 26, 2015 at 8:24 PM, Florian Fainelli wrote: > On 25/02/15 07:24, Alexandru Ardelean wrote: > > Feature implemented and tested on BCM53128. > > > > Slave devices logic copied from the Linux kernel from Marvell's DSA > > driver ( linux/net/dsa/ ). > > Also the logic for the Broadcom tag processing has been copied from > there. > > There are different efforts here going on, and I would like to at least > 3 different people (you, Rafal and myself) can converge to an identical > solution that fits everybody here. > > What net-next supports today is: > > - broadcom tags in net/dsa/tag_brcm.c, 4-bytes format, identical to > yours AFAICT > - HW bridging support for bcm_sf2 (roboswitch successor) > > What's missing: > - adding VLAN configuration, which is what Rafal has been doing using > here: http://thread.gmane.org/gmane.linux.network/351503 > > There are a number of things that I want to rework in DSA such that we > can almost immediately leverage OpenWrt's switch drivers, where the > entry point is a phy_driver, and have them register as switches (DSA or > something wider) eventually [1], such that DSA handles the slave devices > creation, and also handles the transmission/reception of Broadcom tags > for us. This is work in progress, but I expect the patches would be > ready by the end of this week. > > [1]: http://www.spinics.net/lists/netdev/msg295942.html > > > > > OpenWRT's eth_mangle_rx/tx() patch/code is being used to tap into > > the packets to/from the ethernet chip since it's convenient. > > > > This code will create lanX (X = 1..B53_N_PORTS) devices. > > All traffic from the ethX device will be forwarded the proper lanX > device. > > So, sw_port0_traffic == lan1_traffic and so on. > > > > The slave devices logic has been put into it's own file. > > Should this logic be desired to be extended to swconfig or other > > switch chips, it should be convenient to just move the slave.c/h files. > > > > Note: if enable_vlan == 1, be sure to configure VLAN per lanX device > > in '/etc/config/network' > > > > Signed-off-by: Alexandru Ardelean > > --- > > .../generic/files/drivers/net/phy/b53/Makefile | 2 +- > > .../generic/files/drivers/net/phy/b53/b53_common.c | 3 + > > .../generic/files/drivers/net/phy/b53/b53_hdr.c| 114 +++- > > .../generic/files/drivers/net/phy/b53/b53_priv.h | 2 + > > .../generic/files/drivers/net/phy/b53/slave.c | 196 > + > > .../generic/files/drivers/net/phy/b53/slave.h | 38 > > 6 files changed, 352 insertions(+), 3 deletions(-) > > create mode 100644 > target/linux/generic/files/drivers/net/phy/b53/slave.c > > create mode 100644 > target/linux/generic/files/drivers/net/phy/b53/slave.h > > > > diff --git a/target/linux/generic/files/drivers/net/phy/b53/Makefile > b/target/linux/generic/files/drivers/net/phy/b53/Makefile > > index 6c809f9..c74f82b 100644 > > --- a/target/linux/generic/files/drivers/net/phy/b53/Makefile > > +++ b/target/linux/generic/files/drivers/net/phy/b53/Makefile > > @@ -1,5 +1,5 @@ > > obj-$(CONFIG_B53)+= b53_common.o > > -obj-$(CONFIG_B53_HDR)+= b53_hdr.o > > +obj-$(CONFIG_B53_HDR)+= b53_hdr.o slave.o > > > > obj-$(CONFIG_B53_PHY_FIXUP) += b53_phy_fixup.o > > > > 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 9459b22..3da9efe 100644 > > --- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c > > +++ b/target/
Re: [OpenWrt-Devel] [PATCH 3/3] b53: create slave devices for ports
On 25/02/15 07:24, Alexandru Ardelean wrote:
> Feature implemented and tested on BCM53128.
>
> Slave devices logic copied from the Linux kernel from Marvell's DSA
> driver ( linux/net/dsa/ ).
> Also the logic for the Broadcom tag processing has been copied from there.
There are different efforts here going on, and I would like to at least
3 different people (you, Rafal and myself) can converge to an identical
solution that fits everybody here.
What net-next supports today is:
- broadcom tags in net/dsa/tag_brcm.c, 4-bytes format, identical to
yours AFAICT
- HW bridging support for bcm_sf2 (roboswitch successor)
What's missing:
- adding VLAN configuration, which is what Rafal has been doing using
here: http://thread.gmane.org/gmane.linux.network/351503
There are a number of things that I want to rework in DSA such that we
can almost immediately leverage OpenWrt's switch drivers, where the
entry point is a phy_driver, and have them register as switches (DSA or
something wider) eventually [1], such that DSA handles the slave devices
creation, and also handles the transmission/reception of Broadcom tags
for us. This is work in progress, but I expect the patches would be
ready by the end of this week.
[1]: http://www.spinics.net/lists/netdev/msg295942.html
>
> OpenWRT's eth_mangle_rx/tx() patch/code is being used to tap into
> the packets to/from the ethernet chip since it's convenient.
>
> This code will create lanX (X = 1..B53_N_PORTS) devices.
> All traffic from the ethX device will be forwarded the proper lanX device.
> So, sw_port0_traffic == lan1_traffic and so on.
>
> The slave devices logic has been put into it's own file.
> Should this logic be desired to be extended to swconfig or other
> switch chips, it should be convenient to just move the slave.c/h files.
>
> Note: if enable_vlan == 1, be sure to configure VLAN per lanX device
> in '/etc/config/network'
>
> Signed-off-by: Alexandru Ardelean
> ---
> .../generic/files/drivers/net/phy/b53/Makefile | 2 +-
> .../generic/files/drivers/net/phy/b53/b53_common.c | 3 +
> .../generic/files/drivers/net/phy/b53/b53_hdr.c| 114 +++-
> .../generic/files/drivers/net/phy/b53/b53_priv.h | 2 +
> .../generic/files/drivers/net/phy/b53/slave.c | 196
> +
> .../generic/files/drivers/net/phy/b53/slave.h | 38
> 6 files changed, 352 insertions(+), 3 deletions(-)
> create mode 100644 target/linux/generic/files/drivers/net/phy/b53/slave.c
> create mode 100644 target/linux/generic/files/drivers/net/phy/b53/slave.h
>
> diff --git a/target/linux/generic/files/drivers/net/phy/b53/Makefile
> b/target/linux/generic/files/drivers/net/phy/b53/Makefile
> index 6c809f9..c74f82b 100644
> --- a/target/linux/generic/files/drivers/net/phy/b53/Makefile
> +++ b/target/linux/generic/files/drivers/net/phy/b53/Makefile
> @@ -1,5 +1,5 @@
> obj-$(CONFIG_B53)+= b53_common.o
> -obj-$(CONFIG_B53_HDR)+= b53_hdr.o
> +obj-$(CONFIG_B53_HDR)+= b53_hdr.o slave.o
>
> obj-$(CONFIG_B53_PHY_FIXUP) += b53_phy_fixup.o
>
> 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 9459b22..3da9efe 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
> @@ -1377,6 +1377,9 @@ static int b53_global_reset_switch(struct switch_dev
> *dev)
> priv->enable_management = 0;
> #ifdef CONFIG_B53_HDR
> priv->enable_brcm_hdr = 0;
> + /* Call this function before the memset on the priv->ports,
> + * otherwise we may leak devices */
> + b53_unregister_netdevs(priv);
> #endif
>
> memset(priv->vlans, 0, sizeof(priv->vlans) * dev->vlans);
> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_hdr.c
> b/target/linux/generic/files/drivers/net/phy/b53/b53_hdr.c
> index 2a562a9..8fa7929 100644
> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_hdr.c
> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_hdr.c
> @@ -21,14 +21,32 @@
>
> #include "b53_regs.h"
> #include "b53_priv.h"
> +#include "slave.h"
>
> /* This tag length is 4 bytes, older ones were 6 bytes, we do not
> * handle them
> */
> #define BRCM_HDR_LEN4
> #define MIN_FRAME_LEN 64
> +#define BRCM_IG_DSTMAP2_MASK 1
> +#define BRCM_IG_DSTMAP1_MASK 0xff
> +#define BRCM_EG_PID_MASK 0x1f
>
> -static struct sk_buff *b53_mangle_tx(struct net_device *dev, struct sk_buff
> *skb)
> +/* Ingress and egress opcodes */
> +#define BRCM_OPCODE_SHIFT 5
> +
> +static inline void b53_brcm_tag_set(struct sk_buff *skb, int port_idx)
> +{
> + u8 *brcm_tag = skb->data + 2 * ETH_ALEN;
> +
> + brcm_tag[0] = (1 << BRCM_OPCODE_SHIFT);
> + brcm_tag[1] = 0;
> + brcm_tag[2] = (port_idx == 8) ? BRCM_IG_DSTMAP2_MASK : 0;
> + brcm_tag[3] = (1 << port_idx) & BRCM_IG_DSTMAP1_MASK;
> +}
> +
[OpenWrt-Devel] [PATCH 0/2] procd: fix building with latest json-c
These patches allow procd to be build with the latest json-c William Holland (2): fix building with json-c.0.12 Fix use of functions deprecated in json-c.0.12 CMakeLists.txt |7 +++ plug/hotplug.c |6 +- service/validate.c | 37 ++--- 3 files changed, 38 insertions(+), 12 deletions(-) -- 1.7.10.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] Fix use of functions deprecated in json-c.0.12
---
service/validate.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/service/validate.c b/service/validate.c
index 0e45493..2297b4d 100644
--- a/service/validate.c
+++ b/service/validate.c
@@ -57,16 +57,27 @@ service_validate_dump_all(struct blob_buf *b, char *p, char
*s)
if (s && strcmp(s, v->type))
continue;
- o = json_object_object_get(r, v->package);
- if (!o) {
- o = json_object_new_object();
- json_object_object_add(r, v->package, o);
- }
- t = json_object_object_get(o, v->type);
- if (!t) {
- t = json_object_new_object();
- json_object_object_add(o, v->type, t);
- }
+ #ifdef JSONC
+ if (!json_object_object_get_ex(r, v->package, &o)) {
+ o = json_object_new_object();
+ json_object_object_add(r, v->package, o);
+ }
+ if (!json_object_object_get_ex(o, v->type, &t)) {
+ t = json_object_new_object();
+ json_object_object_add(o, v->type, t);
+ }
+ #else
+ o = json_object_object_get(r, v->package);
+ if (!o) {
+ o = json_object_new_object();
+ json_object_object_add(r, v->package, o);
+ }
+ t = json_object_object_get(o, v->type);
+ if (!t) {
+ t = json_object_new_object();
+ json_object_object_add(o, v->type, t);
+ }
+ #endif
avl_for_each_element(&v->rules, vr, avl)
json_object_object_add(t, vr->option,
json_object_new_string(vr->rule));
}
--
1.7.10.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] fix building with json-c.0.12
---
CMakeLists.txt |7 +++
plug/hotplug.c |6 +-
service/validate.c |6 +-
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 5414677..058d774 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -14,6 +14,13 @@ SET(SOURCES procd.c signal.c watchdog.c state.c
inittab.c rcS.c ubus.c system.c
service/service.c service/instance.c service/validate.c
service/trigger.c service/watch.c
plug/coldplug.c plug/hotplug.c utils/utils.c)
+INCLUDE(FindPkgConfig)
+PKG_CHECK_MODULES(JSONC json-c)
+IF(JSONC_FOUND)
+ ADD_DEFINITIONS(-DJSONC)
+ INCLUDE_DIRECTORIES(${JSONC_INCLUDE_DIRS})
+ENDIF()
+
find_library(json NAMES json-c json)
SET(LIBS ubox ubus ${json} blobmsg_json json_script)
diff --git a/plug/hotplug.c b/plug/hotplug.c
index 061833a..3bf6253 100644
--- a/plug/hotplug.c
+++ b/plug/hotplug.c
@@ -22,7 +22,11 @@
#include
#include
#include
-#include
+#ifdef JSONC
+ #include
+#else
+ #include
+#endif
#include
#include
diff --git a/service/validate.c b/service/validate.c
index a33a48e..0e45493 100644
--- a/service/validate.c
+++ b/service/validate.c
@@ -13,7 +13,11 @@
#include
#include
-#include
+#ifdef JSONC
+ #include
+#else
+ #include
+#endif
#include "../procd.h"
--
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Lantiq 3.10 (BB) was lantiq v3.18
Hi,
I have here multiple TD-W8970 with Annex A and Annex B.
> m25p80@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "s25fl129p0";
> reg = <0 0>;
> linux,modalias = "m25p80", "mx25l3205d";
> spi-max-frequency = <100>;
I increased spi-max-frequency = <5000>.
According to the datasheets I found that is maximum frequency.
With my 3 models (2x A, 1x B) these settings work with BB (kernel 3.10) well.
I have not yet tested 3.18.
I benchmarked boot up times from spi-flash with my build.
I could lower bootup times (from uboot to init-completed) from 2m01s to 1m18s.
I suggest backporting this increase of the spi freq to BB.
best regards
Am 26.02.2015 um 02:57 schrieb Daniel Gimpelevich:
> On Sun, 15 Feb 2015 05:21:34 +, Daniel Gimpelevich wrote:
>> On Sat, 14 Feb 2015 19:55:03 +0100, John Crispin wrote:
>>> ok, i think the spi clock is just really slow
>>>
>>>
>>> try increasing it to 10 or 20 mhz. running the flash at 1 Mhz explains
>>> why it takes a week to boot and do anything useful. even with the bus
>>> being bitbanged it should be possible to go beyond 1mhz
>>
>> 1) I'm not sure what tests to run to see what frequency is safe.
>> 2) That's the flash, though. I don't think it explains why the DSL
>> interface in particular takes forever and a day to acknowledge anything.
>> Does it?
>
> OK, adding an extra zero to spi-max-frequency leaves me with no Internet
> after boot. The nas0 interface is created but not brought up. Also,
> /etc/init.d/dsl_control STILL takes about twenty minutes to execute. Here
> is the output of logread:
>
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 28.50] IFXUSB: ifxusb_hcd:
> version 3.2 B110801
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 29.004000] IFXUSB: USB core #0
> soft-reset
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 29.208000] IFXUSB: USB core #0
> soft-reset
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 29.208000] ifxusb_hcd
> ifxusb_hcd: IFX USB Controller
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 29.212000] ifxusb_hcd
> ifxusb_hcd: new USB bus registered, assigned bus number 1
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 29.22] ifxusb_hcd
> ifxusb_hcd: irq 62, io mem 0xbe101000
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 29.228000] IFXUSB: Init: Power
> Port (0)
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 29.236000] hub 1-0:1.0: USB
> hub found
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 29.236000] hub 1-0:1.0: 1 port
> detected
> Wed Feb 25 16:33:51 2015 kern.notice kernel: [ 30.916000] random: mktemp
> urandom read with 121 bits of entropy available
> Wed Feb 25 16:33:51 2015 kern.notice kernel: [ 32.852000] random:
> nonblocking pool is initialized
> Wed Feb 25 16:33:51 2015 kern.notice kernel: [ 40.812000] jffs2: notice:
> (286) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of
> xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
> Wed Feb 25 16:33:51 2015 user.info kernel: [ 40.832000] block: attempting
> to load /tmp/jffs_cfg/upper/etc/config/fstab
> Wed Feb 25 16:33:51 2015 user.info kernel: [ 40.912000] block: extroot: not
> configured
> Wed Feb 25 16:33:51 2015 kern.notice kernel: [ 42.54] jffs2: notice:
> (283) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of
> xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
> Wed Feb 25 16:33:51 2015 user.info kernel: [ 47.672000] block: attempting
> to load /tmp/jffs_cfg/upper/etc/config/fstab
> Wed Feb 25 16:33:51 2015 user.info kernel: [ 47.72] block: extroot: not
> configured
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 53.648000] NET: Registered
> protocol family 10
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 53.672000] zram: Created 1
> device(s) ...
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 53.68] NET: Registered
> protocol family 8
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 53.684000] NET: Registered
> protocol family 20
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 53.70] tun: Universal
> TUN/TAP device driver, 1.6
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 53.704000] tun: (C) 1999-2004
> Max Krasnyansky
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 53.724000] sit: IPv6 over IPv4
> tunneling driver
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 53.744000] PPP generic driver
> version 2.4.2
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 53.764000] ip6_tables: (C)
> 2000-2006 Netfilter Core Team
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 53.796000] nf_conntrack
> version 0.5.0 (945 buckets, 3780 max)
> Wed Feb 25 16:33:51 2015 kern.info kernel: [ 53.896000] IFX MEI Version
> 5.00.00
> Wed Feb 25 16:33:51 2015 kern.warn kernel: [ 53.924000] Infineon CPE API
> Driver version: DSL CPE
Re: [OpenWrt-Devel] lantiq v3.18
On Thu, 2015-02-26 at 09:06 +0100, John Crispin wrote: > you might want to consider the td8970. it works well for many people > but > also has the slow spi flash problem and takes ages the boot. Considering that the whole target is heading for unsupported status, I don't understand how switching to a td8970 would improve things. I'm not sure what work has been done to support MediaTek DSL interfaces after they released driver source, but AFAIK they don't involve VoIP hardware, and the wifi driver is not nearly as mature as Atheros. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
