[OpenWrt-Devel] [PATCH RFC] brcm47xx: image: use standard KERNEL_IMAGE to avoid warnings
KERNEL_IMAGE is used as target rule so reusing the same name causes: Makefile:326: warning: overriding recipe for target `bin/brcm47xx/vmlinux.lzma' Makefile:326: warning: ignoring old recipe for target `bin/brcm47xx/vmlinux.lzma' Makefile:326: warning: overriding recipe for target `build_dir/target-mipsel_74kc+dsp2_uClibc-0.9.33.2/linux-brcm47xx_mips74k/vmlinux.lzma' Makefile:326: warning: ignoring old recipe for target `build_dir/target-mipsel_74kc+dsp2_uClibc-0.9.33.2/linux-brcm47xx_mips74k/vmlinux.lzma' Unfortunately this will cause copying vmlinux.lzma over and over like: cp vmlinux.lzma FOO-kernel.bin which is redundant on brcm47xx where we never modify kernel image. Signed-off-by: Rafał Miłecki zaj...@gmail.com --- With this fix using new image building system adds another overhead because 99% of devices should share both: kernel (vmlinux.lzma) and TRX. I'm wondering if using new image building system in its current form makes any sense for this simple MIPS target. The gain from building images in parellel may be lost due to re-generating simple files. --- target/linux/brcm47xx/image/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/brcm47xx/image/Makefile b/target/linux/brcm47xx/image/Makefile index 5410ed3..b46ab7b 100644 --- a/target/linux/brcm47xx/image/Makefile +++ b/target/linux/brcm47xx/image/Makefile @@ -138,8 +138,9 @@ DEVICE_VARS += DEVICE_ID VERSION DEVICE_VARS += BOARD_ID REGION define Device/Default + KERNEL := kernel-bin IMAGE_NAME = $$(IMAGE_PREFIX)-$$(1).$$(2) - KERNEL_IMAGE = vmlinux.lzma + KERNEL_NAME = vmlinux.lzma FILESYSTEMS := $(FS_64K) IMAGES := trx IMAGE/trx := trx-with-loader -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] LED Toggling for SATA
Dear All, I would be thankful if you could provide me hint on to how to implement a driver for LED for a AHCI Controller. At present the LED is driven by GPIO. The requirement is that the LED should GLOW SOLID once the SATA link is UP, TOGGLE during SATA traffic and GLOW HOLLOW once the link is down. The driver should expose the LEDS to SYSFS for control from the user. A driver for LEDS for USB is present in drivers/leds/ledtrig-usbdev.c. This uses a function call usb_register_notify to get notified from the USB Core about the USB link. Do we have something similar for SATA ? Regards, Deepanjan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
After thinking it through a bit more, I changed the default behavior to the following: The preferred lifetime is now as given by the ISP, however the DHCPv6 server will only hand out the address with the highest preferred lifetime (= the ULA unless disabled). Thus flash renumbering should still work (since only the ULA-address cannot be changed immediately). Is that okay with you or do you see any other issues? Cheers, Steven On 26.03.2015 20:38, Arjen de Korte wrote: Citeren Steven Barth cy...@openwrt.org: This breaks clients that need fixed IPs (in my case, mostly webmail clients). I wonder why they are so sensitive to source-address changes since their old address is still valid and not deprecated so there is no need to switch. Webmail clients usually don't keep a connection open to the server, hence every connection is a new one. The webmail server only sees the source IP, so even if the DHCPv6 address is still valid for the client, a re-login is needed because the source IP changes. I would gladly send the DHCPv6 address with 0 preferred lifetime but Apple's DHCPv6 client has issues and discard addresses therefore the 1. I could create a patch for this, but for now I consider this a regression, rather than a feature that needs to be configurable. I fail to understand the reasons why this change, which deliberately breaks the outgoing addresses (even if only momentarily) was introduced. The reason for this change is that no host seems to support DHCPv6 reconfiguration so we cannot update clients whenever we see fit (e.g. ISP goes down / is switched / designates a different PD). Which means that in absence of that in worst case client connectivity is lost for T1 seconds. I don't see how this fixes things then. When ra_management is '2' you'd still run into the exact same problem (just without the fallback to SLAAC). In contrast, if the ip6prefix is configured statically (as in my case), there is no chance this will ever happen, since changes will never happen unexpectedly. I think this would be much better fixed by making the client renew its lease more frequently (by lowering the valid and preferred lifetimes). The present fix will also not work for anthing else than a /64. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] synchronous network reload/restart
On 03/26/2015 06:54 PM, Jo-Philipp Wich wrote: Hi. Is there any way to synchronously (blocking) reload or restart the network configuration? ubus call network reload (or restart) returns immediately, and the re-configuration happens asynchronously in the background. I'd like the command to block or otherwise wait until the reconfiguration is complete. Any way to achieve this? No. ~ Jow Potential 'workarounds' 1) if you need to wait for your AP use e.g. 'ubus -t 30 wait_for hostapd.wlan0' to wait for it up to 30 secs to show up 2) to synchronize PROCD startup-scripts add a service_started() method in your scripts that does busy-polling for procd/netifd to bring up services. This blocks subsequent init-scripts from being executed before your current script is done. Some kind of dependency tracking within procd would help for sure (e.g. 'start this service only after services x+y are running'), but given how services are handled as independent instances now, this would add lots of complexity to modules that must not fail. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LED Toggling for SATA
Hi Deepanjan, have a look at ledtrig-ata on how to register a LED trigger for each port [1]. Currently this provides only an activity indicator, however, extending it to the features you described should not be too difficult. Let me know if you need more hints/help with that. Cheers Daniel 1: https://dev.openwrt.org/browser/trunk/target/linux/generic/patches-3.18/834-ledtrig-libata.patch On Mon, Mar 30, 2015 at 09:38:15AM +, Deepanjan Kar wrote: Dear All, I would be thankful if you could provide me hint on to how to implement a driver for LED for a AHCI Controller. At present the LED is driven by GPIO. The requirement is that the LED should GLOW SOLID once the SATA link is UP, TOGGLE during SATA traffic and GLOW HOLLOW once the link is down. The driver should expose the LEDS to SYSFS for control from the user. A driver for LEDS for USB is present in drivers/leds/ledtrig-usbdev.c. This uses a function call usb_register_notify to get notified from the USB Core about the USB link. Do we have something similar for SATA ? Regards, Deepanjan ___ 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] uci -P no longer working correctly
In the latest OpenWrt trunk, I found that config_get has stopped loading uncommitted uci changes from /tmp/.uci. I rely on this behavior, which had worked well for years. I found a change[1] in uci that’s responsible. The uci change makes uci_add_delta_path() reject any attempt to add ctx-savedir to the delta search path. However, in light of cli.c’s usage[2], there’s a problem: when processing a -P argument, it calls uci_add_delta_path() to add the original value of ctx-savedir to the delta search path before changing ctx-savedir. After this change, the uci command-line tool’s -P argument no longer acts as documented. Instead of adding a path to the delta search path, it just sets the default save directory. This behavior change appears to be unintentional, and as I mentioned, it’s broken a long-standing behavior that I rely on. This change became a part of OpenWrt at r45040[3] and is exposed to scripts that use /lib/functions.sh: that script sets LOAD_STATE=1, and its config_load calls /lib/config/uci.sh’s uci_load, which adds a -P argument to its “uci export” command when LOAD_STATE is nonempty. I’m happy to contribute a patch, but I’m not sure what [1] intended, so I’m e-mailing to raise awareness first. Mark [1] http://nbd.name/gitweb.cgi?p=uci.git;a=commitdiff;h=32815cf4959c [2] http://nbd.name/gitweb.cgi?p=uci.git;a=blob;f=cli.c;h=557472ecf421;hb=HEAD [3] https://dev.openwrt.org/changeset/45040/trunk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] uci -P no longer working correctly
Hi, On Mar 30, 2015 10:28 PM, Mark Mentovai m...@moxienet.com wrote: In the latest OpenWrt trunk, I found that config_get has stopped loading uncommitted uci changes from /tmp/.uci. I rely on this behavior, which had worked well for years. I found a change[1] in uci that’s responsible. Sorry for the inconvenience caused. The uci change makes uci_add_delta_path() reject any attempt to add ctx-savedir to the delta search path. However, in light of cli.c’s usage[2], there’s a problem: when processing a -P argument, it calls uci_add_delta_path() to add the original value of ctx-savedir to the delta search path before changing ctx-savedir. After this change, the uci command-line tool’s -P argument no longer acts as documented. Instead of adding a path to the delta search path, it just sets the default save directory. This behavior change appears to be unintentional, and as I mentioned, it’s broken a long-standing behavior that I rely on. This change became a part of OpenWrt at r45040[3] and is exposed to scripts that use /lib/functions.sh: that script sets LOAD_STATE=1, and its config_load calls /lib/config/uci.sh’s uci_load, which adds a -P argument to its “uci export” command when LOAD_STATE is nonempty. Not yet with my keyboard at hand, will look into these scripts tomorrow. The intention behind that check is that if a duplicate delta path was added, it would cause the same delta file to be loaded multiple times. IIRC, this behaviour was found while adding test cases about list type option handling. The relevant code is in function uci_load_delta(). Cheers. yousong I’m happy to contribute a patch, but I’m not sure what [1] intended, so I’m e-mailing to raise awareness first. Mark [1] http://nbd.name/gitweb.cgi?p=uci.git;a=commitdiff;h=32815cf4959c [2] http://nbd.name/gitweb.cgi?p=uci.git;a=blob;f=cli.c;h=557472ecf421;hb=HEAD [3] https://dev.openwrt.org/changeset/45040/trunk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
Since I avoid ULA like the plague, this probably won't be a problem for me and global IPv6 addresses will be served. But I'm not convinced that favoring a ULA prefix (if available) over an ip6prefix is best at all times. Nothing is favored, DHCPv6 just hands out ULAs only (if one is there). Client can still decide what it uses to connect to anywhere, besides it can't use an ULA to connect to the internet anyway. Thus flash renumbering should still work (since only the ULA-address cannot be changed immediately). Is that okay with you or do you see any other issues? Well, one thing that still worries me, is that the behavior of the DHCPv6 server is different depending on the state of the O flag. From a DHCPv6 client perspective, it shouldn't. When both M- and O-flag are set, it is up to the client to decide if it wants to use DHCPv6 or SLAAC. You've made it clear that there may be reasons not to use an adress provided by DHCPv6 and use SLAAC instead. But this should not be the only (or default) way of operation. There may be reasons other than broken IPv6 uplinks why network administrators choose to set both M- and O-flags. I think the other reasons are far more common (the lack of DHCPv6 support in Android is just one of them). Even with the changes pushed out today, odhcpd makes the assumption that the ip6prefix can't be relied upon if a ULA prefix is provided and I think that is just incorrect. First of all the O-Flag is ignored whenever the M-Flag is set. Plus there cannot be clients that only do DHCPv6 but not RAs, since DHCPv6 does not transmit any kind of routes thus a client cannot ignore RAs. There are no assumption of unreliability of a prefix, ULAs aren't used for internet communication since they are not routed. Sorry, I don't see your point. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
Citeren Steven Barth cy...@openwrt.org: After thinking it through a bit more, I changed the default behavior to the following: The preferred lifetime is now as given by the ISP, however the DHCPv6 server will only hand out the address with the highest preferred lifetime (= the ULA unless disabled). Since I avoid ULA like the plague, this probably won't be a problem for me and global IPv6 addresses will be served. But I'm not convinced that favoring a ULA prefix (if available) over an ip6prefix is best at all times. Thus flash renumbering should still work (since only the ULA-address cannot be changed immediately). Is that okay with you or do you see any other issues? Well, one thing that still worries me, is that the behavior of the DHCPv6 server is different depending on the state of the O flag. From a DHCPv6 client perspective, it shouldn't. When both M- and O-flag are set, it is up to the client to decide if it wants to use DHCPv6 or SLAAC. You've made it clear that there may be reasons not to use an adress provided by DHCPv6 and use SLAAC instead. But this should not be the only (or default) way of operation. There may be reasons other than broken IPv6 uplinks why network administrators choose to set both M- and O-flags. I think the other reasons are far more common (the lack of DHCPv6 support in Android is just one of them). Even with the changes pushed out today, odhcpd makes the assumption that the ip6prefix can't be relied upon if a ULA prefix is provided and I think that is just incorrect. Arjen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] e2fsprogs broken on ARM...
On Mon, Mar 30, 2015 at 3:21 PM, John Crispin blo...@openwrt.org wrote: [snip] fix in the making, will be pushed tomorrow ... Thanks John! -John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] e2fsprogs broken on ARM...
On 30/03/2015 21:02, John Szakmeister wrote: Commit 988e3615e52b2cd9b9e07f4bbbd76494f7e0cb24 broke building e2fsprogs on an ARM platform. It looks like that in version 1.42.10 the decision was made to drop locally defined versions of both sync_file_range() and fallocate() because they were broken on 32-bit platforms, and there was some issue on the MIPS32 platform too (see 58229aaf85d435469e901c974f31ead6d9124166 is the e2fsprogs git repo). They decided to let the C library handle it, but unfortunately, uClibc really isn't up to it at the moment. It might be possible to backport the work done to make sync_file_range() on the mainline uClibc, but it might beyond my capability at the moment (I don't have a way to test other platforms right now)--though I can try, if you'd like me to. Or, should we just patch out the building of e4defrag for the time being? We don't currently package it. Thanks! -John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel fix in the making, will be pushed tomorrow ... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] e2fsprogs broken on ARM...
Commit 988e3615e52b2cd9b9e07f4bbbd76494f7e0cb24 broke building e2fsprogs on an ARM platform. It looks like that in version 1.42.10 the decision was made to drop locally defined versions of both sync_file_range() and fallocate() because they were broken on 32-bit platforms, and there was some issue on the MIPS32 platform too (see 58229aaf85d435469e901c974f31ead6d9124166 is the e2fsprogs git repo). They decided to let the C library handle it, but unfortunately, uClibc really isn't up to it at the moment. It might be possible to backport the work done to make sync_file_range() on the mainline uClibc, but it might beyond my capability at the moment (I don't have a way to test other platforms right now)--though I can try, if you'd like me to. Or, should we just patch out the building of e4defrag for the time being? We don't currently package it. Thanks! -John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] b53: fix overriding port 8 state (if it is connected to CPU)
On Wed, Mar 18, 2015 at 12:09 PM, Rafał Miłecki zaj...@gmail.com wrote:
On 18 March 2015 at 11:28, Jonas Gorski j...@openwrt.org wrote:
On Wed, Mar 18, 2015 at 10:02 AM, Rafał Miłecki zaj...@gmail.com wrote:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
.../generic/files/drivers/net/phy/b53/b53_common.c | 23
+-
.../generic/files/drivers/net/phy/b53/b53_regs.h | 1 +
2 files changed, 23 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 e44d194..4597742 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
@@ -525,7 +525,7 @@ static int b53_switch_reset(struct b53_device *dev)
return -EINVAL;
}
}
- } else if ((is531x5(dev) || is5301x(dev)) dev-sw_dev.cpu_port
== B53_CPU_PORT) {
+ } else if (is531x5(dev) dev-sw_dev.cpu_port == B53_CPU_PORT) {
u8 mii_port_override;
b53_read8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
@@ -533,6 +533,27 @@ static int b53_switch_reset(struct b53_device *dev)
b53_write8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
mii_port_override | PORT_OVERRIDE_EN |
PORT_OVERRIDE_LINK);
+ } else if (is5301x(dev)) {
+ /*
+* CPU interface attached to port 8 requires specific
handling.
+* It uses different overriding register and extra ports 5
and 7
+* need to be configured as well.
+*/
+ if (dev-sw_dev.cpu_port == 8) {
+ u8 mii_port_override;
+
+ b53_read8(dev, B53_CTRL_PAGE,
B53_PORT_OVERRIDE_CTRL,
+ mii_port_override);
+ mii_port_override |= PORT_OVERRIDE_LINK |
+PORT_OVERRIDE_RX_FLOW |
+PORT_OVERRIDE_TX_FLOW |
+PORT_OVERRIDE_SPEED_2000M |
+PORT_OVERRIDE_EN;
+ b53_write8(dev, B53_CTRL_PAGE,
B53_PORT_OVERRIDE_CTRL,
+ mii_port_override);
+ } else {
+ pr_warn(overriding CPU port other than 8 is not
supported yet\n);
+ }
}
b53_enable_mib(dev);
How about
@@ -530,9 +530,16 @@ static int b53_switch_reset(struct b53_device *dev)
b53_read8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
mii_port_override);
+
+ mii_port_override |= PORT_OVERRIDE_LINK | PORT_OVERRIDE_EN;
+
+ if (is5301x(dev))
+ mii_port_override |= PORT_OVERRIDE_RX_FLOW |
+PORT_OVERRIDE_TX_FLOW |
+PORT_OVERRIDE_SPEED_2000M;
+
b53_write8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
- mii_port_override | PORT_OVERRIDE_EN |
- PORT_OVERRIDE_LINK);
+ mii_port_override);
}
b53_enable_mib(dev);
instead of creating a full new branch?
As the comment says, this code for BCM5301X will be extended. This is
because of this 2000M speed, which requires configuring 3 ports. It
seems communication between switch and CPU interface with such speed
couldn't be handled with only a single port. Broadcom decided to use 3
ports in total for that.
I don't have that code ready and I also don't like patch bombs, so I
started with this simple change. However because of further
development plans I vote for a separated branch.
Sorry for taking so long to respond, the kernel-size issue on bcm63xx
took longer and had more side effects than expected.
Then let's keep it simple for now and move it into a separate branch
if you actually have the code ready. At least for me, my future code
never stays that way how I imagined it will be and it tends to look a
lot different when done.
Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] swconfig: set pvid to the same value as vid for untagged ports?
On 31 March 2015 at 00:10, Roman Yeryomin leroi.li...@gmail.com wrote: I was little bit surprised it's not so currently. Although I understand that, potentially, there are use cases when you want port pvid to be different from it's untagged vlan id, but usually one wants port ingress traffic to fall into the same vlan as it's untagged egress traffic. Even more, current luci interface ignores 'switch_port' section of /etc/config/network making it impossible to change pvid from web ui. Also if one creates a new vlan most likely he will need a new interface (e.g. eth0.10 for vlan 10). This is not obvious for a regular user. I think it would be much better if netifd (or whoever does it) would at least set pvid to vid value for untagged ports in same vlan group. I can try doing it myself if somebody can give me the pointers to where the changes should go. Did I overlook something? Are there other/better options? Forgot to mention that I test it on mt7620 Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] synchronous network reload/restart
On 03/30/2015 11:26 AM, Zefir Kurtisi wrote:
On 03/26/2015 06:54 PM, Jo-Philipp Wich wrote:
Hi.
Is there any way to synchronously (blocking) reload or restart the
network configuration?
ubus call network reload (or restart) returns immediately, and the
re-configuration happens asynchronously in the background. I'd like the
command to block or otherwise wait until the reconfiguration is
complete. Any way to achieve this?
No.
~ Jow
Potential 'workarounds'
1) if you need to wait for your AP
use e.g. 'ubus -t 30 wait_for hostapd.wlan0'
to wait for it up to 30 secs to show up
2) to synchronize PROCD startup-scripts
add a service_started() method in your scripts that does busy-polling for
procd/netifd to bring up services. This blocks subsequent init-scripts from
being
executed before your current script is done.
Some kind of dependency tracking within procd would help for sure (e.g. 'start
this service only after services x+y are running'), but given how services are
handled as independent instances now, this would add lots of complexity to
modules
that must not fail.
Thanks for these workarounds, they do not help me, but may be useful for
someone else in the future.
I am dealing with the problem of re-configuration of multiple dependent
virtual interfaces: an ad-hoc interface, a monitor interface, an AP and
a BATMAN-ADV bat0 interface all on one wireless device. Also I have a
service which depends on the monitor interface, and needs to be
restarted when that devices gets re-created.
So far got some results by making the necessary ubus calls equivalent of
ubus call network reload via the C interface, and waiting for the ubus
events also thru the C API, but sometimes it seems I get a ifup ({
network.interface: {action:ifup,interface:moni} }) event
before the device is really available, because directly after that,
getting the MAC address by SIOCGIFHWADDR ioctl fails...
Any ideas?
bruno
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V3] b53: define registers available and needed on BCM5301X
On Wed, Mar 18, 2015 at 8:48 PM, Rafał Miłecki zaj...@gmail.com wrote: They are also present on some BCM63xx switches. Signed-off-by: Rafał Miłecki zaj...@gmail.com --- .../generic/files/drivers/net/phy/b53/b53_regs.h | 32 ++ 1 file changed, 32 insertions(+) diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h index 4899cc4..a4db1f1 100644 --- a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h @@ -50,6 +50,9 @@ /* Jumbo Frame Registers */ #define B53_JUMBO_PAGE 0x40 +/* CFP Configuration Registers Page */ +#define B53_CFP_PAGE 0xa1 How big is this page? What are its valid fields? + /* * Control Page registers */ @@ -99,6 +102,24 @@ #define B53_MC_FLOOD_MASK 0x34 #define B53_IPMC_FLOOD_MASK0x36 +/* + * Overriding ports 0-7 on devices with xMII interfaces (8 bit) I suggest adding a blank line here in the comment to separate name and detailed explanation. Also let's call it Override Port State Register or so. Overriding ports sounds like you could change the port numbering or so. + * For port 8 still use B53_PORT_OVERRIDE_CTRL + * Please note that not all ports are available on every hardware, e.g. BCM5301X + * don't include overriding port 6, BCM63xx also have some limitations. + */ +#define B53_GMII_PORT_OVERRIDE_CTRL(i) (0x58 + i) +#define GMII_PORT_OVERRIDE_LINK BIT(0) +#define GMII_PORT_OVERRIDE_FULL_DUPLEX BIT(1) /* 0 = Half Duplex */ +#define GMII_PORT_OVERRIDE_SPEED_S 2 +#define GMII_PORT_OVERRIDE_SPEED_10M (0 PORT_OVERRIDE_SPEED_S) +#define GMII_PORT_OVERRIDE_SPEED_100M(1 PORT_OVERRIDE_SPEED_S) +#define GMII_PORT_OVERRIDE_SPEED_1000M (2 PORT_OVERRIDE_SPEED_S) +#define GMII_PORT_OVERRIDE_RX_FLOW BIT(4) +#define GMII_PORT_OVERRIDE_TX_FLOW BIT(5) +#define GMII_PORT_OVERRIDE_ENBIT(6) /* Use the register contents */ +#define GMII_PORT_OVERRIDE_SPEED_2000M BIT(7) /* BCM5301X only, requires setting 1000M */ Can we shorten these names a bit? Broadcom calls them GMII_PO_*, which I think is an acceptable abbreviation. + /* Software reset register (8 bit) */ #define B53_SOFTRESET 0x79 @@ -156,6 +177,10 @@ #define GC_FRM_MGMT_PORT_04 0x00 #define GC_FRM_MGMT_PORT_MII 0x80 +/* Enable BCM_HDR Tag on IMP port (8 bit) */ Broadcom Header control register? The comment belongs to BRCM_HDR_EN. +#define B53_BRCM_HDR 0x03 +#define BRCM_HDR_EN BIT(0) + /* Device ID register (8 or 32 bit) */ #define B53_DEVICE_ID 0x30 @@ -310,4 +335,11 @@ #define JMS_MIN_SIZE 1518 #define JMS_MAX_SIZE 9724 +/* + * CFP Configuration Page Registers + */ + +/* CFP Control Register with ports map (8 bit) */ +#define B53_CFP_CTRL 0x00 + #endif /* !__B53_REGS_H */ -- 1.8.4.5 Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [dnsmasq] add --tftp-no-fail to ignore missing tftp root
This patch introduces the option --tftp-no-fail to dnsmasq and prevents the
service from aborting if the specified TFTP root directory is not available;
this might be the case if TFTP files are located on external media that might
occasionally not be present at startup.
Signed-off-by: Stefan Tomanek stefan.tomanek+open...@wertarbyte.de
---
.../network/services/dnsmasq/files/dnsmasq.init|1 +
...-tftp-no-fail-to-ignore-missing-tftp-root.patch | 103
2 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644
package/network/services/dnsmasq/patches/120-add-tftp-no-fail-to-ignore-missing-tftp-root.patch
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index 2e7fb7b..9795d1a 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -128,6 +128,7 @@ dnsmasq() {
append_bool $cfg boguspriv --bogus-priv
append_bool $cfg expandhosts --expand-hosts
append_bool $cfg enable_tftp --enable-tftp
+ append_bool $cfg tftp_no_fail --tftp-no-fail
append_bool $cfg nonwildcard --bind-interfaces
append_bool $cfg fqdn --dhcp-fqdn
append_bool $cfg proxydnssec --proxy-dnssec
diff --git
a/package/network/services/dnsmasq/patches/120-add-tftp-no-fail-to-ignore-missing-tftp-root.patch
b/package/network/services/dnsmasq/patches/120-add-tftp-no-fail-to-ignore-missing-tftp-root.patch
new file mode 100644
index 000..9a2a94a
--- /dev/null
+++
b/package/network/services/dnsmasq/patches/120-add-tftp-no-fail-to-ignore-missing-tftp-root.patch
@@ -0,0 +1,103 @@
+From 859e01b56ca9aa1e3a871bfd4db1e372f1a7302d Mon Sep 17 00:00:00 2001
+From: Stefan Tomanek stefan.toma...@wertarbyte.de
+Date: Mon, 30 Mar 2015 22:58:10 +0200
+Subject: [PATCH] add --tftp-no-fail to ignore missing tftp root
+
+This change makes dnsmasq ignore any missing TFTP root directories
+if --tftp-no-fail is specified; this is useful for router devices
+that store TFTP data on an external storage that might not always
+be present.
+---
+ src/dnsmasq.c | 24 ++--
+ src/dnsmasq.h | 3 ++-
+ src/option.c | 3 +++
+ 3 files changed, 23 insertions(+), 7 deletions(-)
+
+diff --git a/src/dnsmasq.c b/src/dnsmasq.c
+index 5c7750d..71e101d 100644
+--- a/src/dnsmasq.c
b/src/dnsmasq.c
+@@ -632,20 +632,32 @@ int main (int argc, char **argv)
+ {
+ if (!((dir = opendir(daemon-tftp_prefix
+ {
+-send_event(err_pipe[1], EVENT_TFTP_ERR, errno,
daemon-tftp_prefix);
+-_exit(0);
++if (! option_bool(OPT_TFTP_NO_FAIL))
++ {
++send_event(err_pipe[1], EVENT_TFTP_ERR, errno,
daemon-tftp_prefix);
++_exit(0);
++ }
++else
++ my_syslog(LOG_WARNING, _(warning: TFTP directory '%s'
inaccessible), daemon-tftp_prefix);
+ }
+-closedir(dir);
++else
++ closedir(dir);
+ }
+
+ for (p = daemon-if_prefix; p; p = p-next)
+ {
+ if (!((dir = opendir(p-prefix
+ {
+- send_event(err_pipe[1], EVENT_TFTP_ERR, errno, p-prefix);
+- _exit(0);
++if (! option_bool(OPT_TFTP_NO_FAIL))
++ {
++send_event(err_pipe[1], EVENT_TFTP_ERR, errno, p-prefix);
++_exit(0);
++ }
++else
++ my_syslog(LOG_WARNING, _(warning: TFTP directory '%s'
inaccessible), p-prefix);
+ }
+-closedir(dir);
++else
++ closedir(dir);
+ }
+ }
+ #endif
+diff --git a/src/dnsmasq.h b/src/dnsmasq.h
+index 1dd61c5..8e0d352 100644
+--- a/src/dnsmasq.h
b/src/dnsmasq.h
+@@ -238,7 +238,8 @@ struct event_desc {
+ #define OPT_DNSSEC_NO_SIGN 48
+ #define OPT_LOCAL_SERVICE 49
+ #define OPT_LOOP_DETECT50
+-#define OPT_LAST 51
++#define OPT_TFTP_NO_FAIL 51
++#define OPT_LAST 52
+
+ /* extra flags for my_syslog, we use a couple of facilities since they are
known
+not to occupy the same bits as priorities, no matter how syslog.h is set
up. */
+diff --git a/src/option.c b/src/option.c
+index 209fa69..fa5e4d3 100644
+--- a/src/option.c
b/src/option.c
+@@ -147,6 +147,7 @@ struct myoption {
+ #define LOPT_LOCAL_SERVICE 335
+ #define LOPT_DNSSEC_TIME 336
+ #define LOPT_LOOP_DETECT 337
++#define LOPT_TFTP_NO_FAIL 338
+
+ #ifdef HAVE_GETOPT_LONG
+ static const struct option opts[] =
+@@ -227,6 +228,7 @@ static const struct myoption opts[] =
+ { dhcp-ignore-names, 2, 0, LOPT_NO_NAMES },
+ { enable-tftp, 2, 0, LOPT_TFTP },
+ { tftp-secure, 0, 0, LOPT_SECURE },
++{ tftp-no-fail, 0, 0, LOPT_TFTP_NO_FAIL },
+ { tftp-unique-root, 0, 0, LOPT_APREF },
+ { tftp-root, 1, 0, LOPT_PREFIX },
+ { tftp-max, 1, 0, LOPT_TFTP_MAX },
+@@ -402,6 +404,7 @@ static struct {
+ {
Re: [OpenWrt-Devel] I'd like to donate a Linksys WRT300N V1
2015-03-30 16:24 GMT-06:00 Josh Berkus j...@postgresql.org: On 03/30/2015 02:43 PM, Rafał Miłecki wrote: On 17 March 2015 at 22:05, Alex Henrie alexhenri...@gmail.com wrote: I just mailed the router. When it arrives, please send confirmation to me and to treasu...@spi-inc.org. I just got it today, thanks! OK. Is another Thank You letter required? If so, I will write one. Yes, I would like a thank you letter. -Alex ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] swconfig: set pvid to the same value as vid for untagged ports?
I was little bit surprised it's not so currently. Although I understand that, potentially, there are use cases when you want port pvid to be different from it's untagged vlan id, but usually one wants port ingress traffic to fall into the same vlan as it's untagged egress traffic. Even more, current luci interface ignores 'switch_port' section of /etc/config/network making it impossible to change pvid from web ui. Also if one creates a new vlan most likely he will need a new interface (e.g. eth0.10 for vlan 10). This is not obvious for a regular user. I think it would be much better if netifd (or whoever does it) would at least set pvid to vid value for untagged ports in same vlan group. I can try doing it myself if somebody can give me the pointers to where the changes should go. Did I overlook something? Are there other/better options? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] e2fsprogs broken on ARM...
On 30 March 2015 at 22:21, John Crispin blo...@openwrt.org wrote: On 30/03/2015 21:02, John Szakmeister wrote: Commit 988e3615e52b2cd9b9e07f4bbbd76494f7e0cb24 broke building e2fsprogs on an ARM platform. It looks like that in version 1.42.10 the decision was made to drop locally defined versions of both sync_file_range() and fallocate() because they were broken on 32-bit platforms, and there was some issue on the MIPS32 platform too (see 58229aaf85d435469e901c974f31ead6d9124166 is the e2fsprogs git repo). They decided to let the C library handle it, but unfortunately, uClibc really isn't up to it at the moment. It might be possible to backport the work done to make sync_file_range() on the mainline uClibc, but it might beyond my capability at the moment (I don't have a way to test other platforms right now)--though I can try, if you'd like me to. Or, should we just patch out the building of e4defrag for the time being? We don't currently package it. Thanks! -John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel fix in the making, will be pushed tomorrow ... I suppose the subj, this ticket https://dev.openwrt.org/ticket/19336 and this error are also related Making all in libtransmission make[5]: Entering directory '/tmp/roman/build_dir.mt7620/target-mipsel_24kec+dsp_uClibc-0.9.33.2/transmission-2.84/libtransmission' CC fdlimit.o In file included from fdlimit.c:39:0: /home/roman/dev/openwrt/build/mt7620/staging_dir/toolchain-mipsel_24kec+dsp_gcc-4.8-linaro_uClibc-0.9.33.2/include/fcntl.h:256:12: error: conflicting types for 'fallocate64' extern int fallocate64 (int __fd, int __mode, __off64_t __offset, __off64_t __len); ^ fdlimit.c:28:14: note: previous declaration of 'fallocate64' was here extern int fallocate64 (int fd, int mode, uint64_t offset, uint64_t len); ^ Makefile:1121: recipe for target 'fdlimit.o' failed make[5]: *** [fdlimit.o] Error 1 make[5]: Leaving directory '/tmp/roman/build_dir.mt7620/target-mipsel_24kec+dsp_uClibc-0.9.33.2/transmission-2.84/libtransmission' Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
Citeren Steven Barth cy...@openwrt.org: Is that okay with you or do you see any other issues? I'm seeing negative preferred and valid lifetimes: Mar 30 19:24:46 host.example.com NetworkManager[750]: infovalid_lft -173 Mar 30 19:24:46 host.example.com NetworkManager[750]: info preferred_lft -173 Mar 30 19:54:47 host.example.com NetworkManager[750]: info valid_lft -1973 Mar 30 19:54:47 host.example.com NetworkManager[750]: info preferred_lft -1973 Mar 30 20:24:46 host.example.com NetworkManager[750]: info valid_lft -3772 Mar 30 20:24:46 host.example.com NetworkManager[750]: info preferred_lft -3772 Mar 30 20:54:46 host.example.com NetworkManager[750]: info valid_lft -5573 Mar 30 20:54:46 host.example.com NetworkManager[750]: info preferred_lft -5573 Mar 30 21:24:47 host.example.com NetworkManager[750]: info valid_lft -7373 Mar 30 21:24:47 host.example.com NetworkManager[750]: info preferred_lft -7373 Mar 30 21:54:46 host.example.com NetworkManager[750]: info valid_lft -9172 Mar 30 21:54:46 host.example.com NetworkManager[750]: info preferred_lft -9172 Mar 30 22:24:46 host.example.com NetworkManager[750]: info valid_lft -10972 Mar 30 22:24:46 host.example.com NetworkManager[750]: info preferred_lft -10972 Mar 30 22:54:46 host.example.com NetworkManager[750]: info valid_lft -12773 Mar 30 22:54:46 host.example.com NetworkManager[750]: info preferred_lft -12773 From the above it looks like the T1 (and T2) timers are not affected, it's just that the preferred and valid lifetimes are off. Not sure if this is not a problem in NetworkManager, but I have no time to check this out now (I'll be away from my mail a couple of days). Arjen ___ 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 Linksys WRT300N V1
On 17 March 2015 at 22:05, Alex Henrie alexhenri...@gmail.com wrote: I just mailed the router. When it arrives, please send confirmation to me and to treasu...@spi-inc.org. I just got it today, thanks! I disassembled it, it's really a PCMCIA wireless card, nice :) Quite an unique device! I had some problems installing OpenWrt, not sure what they were caused by. Ppl trying to install original firmware seemed to had these issues too, so they may be not related to OpenWrt firmware only. I got it as well for the original firmware, however after a reboot is suddenly succeeded. So I decided to install some older OpenWrt as I suspected it may be related to flash size. 12.09 was rejected, so I tried 10.03.1. It got accepted but I think it doesn't boot and I've soft bricked this router. I'll have to install serial console (requires soldering a header) and doing more tests, so it may take me a bit more of time. Anyway, I'm happy to have this device for experiments, thanks! -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/5] ipq806x: add support for 4.0 kernel
Signed-off-by: Mathieu Olivari math...@codeaurora.org --- target/linux/ipq806x/config-4.0| 389 +++ .../001-spi-qup-Add-DMA-capabilities.patch | 522 + ...-v3-spi-qup-Fix-incorrect-block-transfers.patch | 376 +++ .../003-spi-qup-Ensure-done-detection.patch| 56 +++ ...atchdog-qcom-use-timer-devicetree-binding.patch | 72 +++ ...m-add-description-of-KPSS-WDT-for-IPQ8064.patch | 53 +++ ...-watchdog-entries-to-DT-timer-binding-doc.patch | 50 ++ .../patches-4.0/020-add-ap148-bootargs.patch | 46 ++ .../patches-4.0/021-add-ap148-partitions.patch | 35 ++ .../patches-4.0/700-add-gmac-dts-suport.patch | 172 +++ 10 files changed, 1771 insertions(+) create mode 100644 target/linux/ipq806x/config-4.0 create mode 100644 target/linux/ipq806x/patches-4.0/001-spi-qup-Add-DMA-capabilities.patch create mode 100644 target/linux/ipq806x/patches-4.0/002-v3-spi-qup-Fix-incorrect-block-transfers.patch create mode 100644 target/linux/ipq806x/patches-4.0/003-spi-qup-Ensure-done-detection.patch create mode 100644 target/linux/ipq806x/patches-4.0/011-watchdog-qcom-use-timer-devicetree-binding.patch create mode 100644 target/linux/ipq806x/patches-4.0/012-ARM-qcom-add-description-of-KPSS-WDT-for-IPQ8064.patch create mode 100644 target/linux/ipq806x/patches-4.0/013-ARM-msm-add-watchdog-entries-to-DT-timer-binding-doc.patch create mode 100644 target/linux/ipq806x/patches-4.0/020-add-ap148-bootargs.patch create mode 100644 target/linux/ipq806x/patches-4.0/021-add-ap148-partitions.patch create mode 100644 target/linux/ipq806x/patches-4.0/700-add-gmac-dts-suport.patch diff --git a/target/linux/ipq806x/config-4.0 b/target/linux/ipq806x/config-4.0 new file mode 100644 index 000..5ce4644 --- /dev/null +++ b/target/linux/ipq806x/config-4.0 @@ -0,0 +1,389 @@ +CONFIG_ALIGNMENT_TRAP=y +# CONFIG_AMBA_PL08X is not set +# CONFIG_APM_EMULATION is not set +CONFIG_APQ_GCC_8084=y +CONFIG_APQ_MMCC_8084=y +CONFIG_AR8216_PHY=y +CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y +CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y +CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y +CONFIG_ARCH_HAS_SG_CHAIN=y +CONFIG_ARCH_HAS_TICK_BROADCAST=y +CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y +CONFIG_ARCH_MSM8960=y +CONFIG_ARCH_MSM8974=y +CONFIG_ARCH_MSM8X60=y +CONFIG_ARCH_MULTIPLATFORM=y +# CONFIG_ARCH_MULTI_CPU_AUTO is not set +CONFIG_ARCH_MULTI_V6_V7=y +CONFIG_ARCH_MULTI_V7=y +CONFIG_ARCH_NR_GPIO=0 +CONFIG_ARCH_QCOM=y +# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set +# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set +CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y +CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y +CONFIG_ARCH_SUPPORTS_UPROBES=y +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ARCH_USE_BUILTIN_BSWAP=y +CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y +CONFIG_ARCH_WANT_GENERAL_HUGETLB=y +CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y +CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y +CONFIG_ARM=y +CONFIG_ARM_AMBA=y +CONFIG_ARM_ARCH_TIMER=y +CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y +CONFIG_ARM_CPU_SUSPEND=y +CONFIG_ARM_GIC=y +CONFIG_ARM_HAS_SG_CHAIN=y +CONFIG_ARM_L1_CACHE_SHIFT=6 +CONFIG_ARM_L1_CACHE_SHIFT_6=y +# CONFIG_ARM_LPAE is not set +CONFIG_ARM_PATCH_PHYS_VIRT=y +# CONFIG_ARM_SMMU is not set +# CONFIG_ARM_SP805_WATCHDOG is not set +CONFIG_ARM_THUMB=y +# CONFIG_ARM_THUMBEE is not set +CONFIG_ARM_UNWIND=y +CONFIG_ARM_VIRT_EXT=y +CONFIG_AUTO_ZRELADDR=y +# CONFIG_BATTERY_GAUGE_LTC2941 is not set +CONFIG_BCMA_DRIVER_PCI=y +# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set +CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 +CONFIG_BOUNCE=y +CONFIG_BUILD_BIN2C=y +# CONFIG_CACHE_L2X0 is not set +CONFIG_CLEANCACHE=y +CONFIG_CLKDEV_LOOKUP=y +CONFIG_CLKSRC_OF=y +CONFIG_CLKSRC_QCOM=y +CONFIG_CLONE_BACKWARDS=y +CONFIG_COMMON_CLK=y +CONFIG_COMMON_CLK_QCOM=y +CONFIG_COMPACTION=y +CONFIG_COREDUMP=y +CONFIG_CPU_32v6K=y +CONFIG_CPU_32v7=y +CONFIG_CPU_ABRT_EV7=y +# CONFIG_CPU_BIG_ENDIAN is not set +# CONFIG_CPU_BPREDICT_DISABLE is not set +CONFIG_CPU_CACHE_V7=y +CONFIG_CPU_CACHE_VIPT=y +CONFIG_CPU_COPY_V6=y +CONFIG_CPU_CP15=y +CONFIG_CPU_CP15_MMU=y +CONFIG_CPU_HAS_ASID=y +# CONFIG_CPU_ICACHE_DISABLE is not set +CONFIG_CPU_PABRT_V7=y +CONFIG_CPU_PM=y +CONFIG_CPU_RMAP=y +CONFIG_CPU_TLB_V7=y +CONFIG_CPU_V7=y +CONFIG_CRC16=y +# CONFIG_CRC32_SARWATE is not set +CONFIG_CRC32_SLICEBY8=y +CONFIG_CROSS_MEMORY_ATTACH=y +# CONFIG_CRYPTO_SHA1_ARM_NEON is not set +# CONFIG_CRYPTO_SHA512_ARM_NEON is not set +CONFIG_CRYPTO_XZ=y +CONFIG_DCACHE_WORD_ACCESS=y +CONFIG_DEBUG_BUGVERBOSE=y +CONFIG_DEBUG_GPIO=y +CONFIG_DEBUG_LL_INCLUDE=mach/debug-macro.S +CONFIG_DEBUG_PREEMPT=y +# CONFIG_DEBUG_UART_8250 is not set +# CONFIG_DEBUG_USER is not set +CONFIG_DECOMPRESS_GZIP=y +CONFIG_DEVMEM=y +CONFIG_DMADEVICES=y +CONFIG_DMA_ENGINE=y +CONFIG_DMA_OF=y +CONFIG_DMA_VIRTUAL_CHANNELS=y +CONFIG_DTC=y +# CONFIG_DW_DMAC_CORE is not set +# CONFIG_DW_DMAC_PCI is not set +CONFIG_DYNAMIC_DEBUG=y +CONFIG_ETHERNET_PACKET_MANGLE=y
[OpenWrt-Devel] [PATCH 1/5] ipq806x: move 020-add-ap148-bootargs.patch in patches-3.18
Signed-off-by: Mathieu Olivari math...@codeaurora.org
---
.../patches-3.18/020-add-ap148-bootargs.patch | 46 ++
.../ipq806x/patches/020-add-ap148-bootargs.patch | 46 --
2 files changed, 46 insertions(+), 46 deletions(-)
create mode 100644
target/linux/ipq806x/patches-3.18/020-add-ap148-bootargs.patch
delete mode 100644 target/linux/ipq806x/patches/020-add-ap148-bootargs.patch
diff --git a/target/linux/ipq806x/patches-3.18/020-add-ap148-bootargs.patch
b/target/linux/ipq806x/patches-3.18/020-add-ap148-bootargs.patch
new file mode 100644
index 000..a61481e
--- /dev/null
+++ b/target/linux/ipq806x/patches-3.18/020-add-ap148-bootargs.patch
@@ -0,0 +1,46 @@
+--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+@@ -14,6 +14,14 @@
+ };
+ };
+
++ alias {
++ serial0 = uart4;
++ };
++
++ chosen {
++ linux,stdout-path = serial0:115200n8;
++ };
++
+ soc {
+ pinmux@80 {
+ i2c4_pins: i2c4_pinmux {
+--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
+@@ -140,7 +140,7 @@
+ ranges;
+ status = disabled;
+
+- serial@1249 {
++ uart2: serial@1249 {
+ compatible = qcom,msm-uartdm-v1.3,
qcom,msm-uartdm;
+ reg = 0x1249 0x1000,
+ 0x1248 0x1000;
+@@ -175,7 +175,7 @@
+ ranges;
+ status = disabled;
+
+- serial@1634 {
++ uart4: serial@1634 {
+ compatible = qcom,msm-uartdm-v1.3,
qcom,msm-uartdm;
+ reg = 0x1634 0x1000,
+ 0x1630 0x1000;
+@@ -209,7 +209,7 @@
+ ranges;
+ status = disabled;
+
+- serial@1a24 {
++ uart5: serial@1a24 {
+ compatible = qcom,msm-uartdm-v1.3,
qcom,msm-uartdm;
+ reg = 0x1a24 0x1000,
+ 0x1a20 0x1000;
diff --git a/target/linux/ipq806x/patches/020-add-ap148-bootargs.patch
b/target/linux/ipq806x/patches/020-add-ap148-bootargs.patch
deleted file mode 100644
index a61481e..000
--- a/target/linux/ipq806x/patches/020-add-ap148-bootargs.patch
+++ /dev/null
@@ -1,46 +0,0 @@
a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
-+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
-@@ -14,6 +14,14 @@
- };
- };
-
-+ alias {
-+ serial0 = uart4;
-+ };
-+
-+ chosen {
-+ linux,stdout-path = serial0:115200n8;
-+ };
-+
- soc {
- pinmux@80 {
- i2c4_pins: i2c4_pinmux {
a/arch/arm/boot/dts/qcom-ipq8064.dtsi
-+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
-@@ -140,7 +140,7 @@
- ranges;
- status = disabled;
-
-- serial@1249 {
-+ uart2: serial@1249 {
- compatible = qcom,msm-uartdm-v1.3,
qcom,msm-uartdm;
- reg = 0x1249 0x1000,
- 0x1248 0x1000;
-@@ -175,7 +175,7 @@
- ranges;
- status = disabled;
-
-- serial@1634 {
-+ uart4: serial@1634 {
- compatible = qcom,msm-uartdm-v1.3,
qcom,msm-uartdm;
- reg = 0x1634 0x1000,
- 0x1630 0x1000;
-@@ -209,7 +209,7 @@
- ranges;
- status = disabled;
-
-- serial@1a24 {
-+ uart5: serial@1a24 {
- compatible = qcom,msm-uartdm-v1.3,
qcom,msm-uartdm;
- reg = 0x1a24 0x1000,
- 0x1a20 0x1000;
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/5] config: add an option to enable KPROBE
Signed-off-by: Mathieu Olivari math...@codeaurora.org --- config/Config-kernel.in | 17 + include/kernel-defaults.mk | 1 - target/linux/generic/config-3.10 | 4 target/linux/generic/config-3.14 | 4 target/linux/generic/config-3.18 | 4 target/linux/generic/config-4.0 | 4 6 files changed, 33 insertions(+), 1 deletion(-) diff --git a/config/Config-kernel.in b/config/Config-kernel.in index 8471129..cc8df5a 100644 --- a/config/Config-kernel.in +++ b/config/Config-kernel.in @@ -127,6 +127,23 @@ config KERNEL_EARLY_PRINTK debugging purposes to send messages over the serial console in early boot. Enable this to debug early boot problems. +config KERNEL_KPROBES + bool Compile the kernel with kprobes support + default n + select KERNEL_FTRACE + select KERNEL_PERF_EVENTS + help + Compiles the kernel with KPROBES support, which allows you to trap + at almost any kernel address and execute a callback function. + register_kprobe() establishes a probepoint and specifies the + callback. Kprobes is useful for kernel debugging, non-intrusive + instrumentation and testing. + If in doubt, say N. + +config KERNEL_KPROBE_EVENT + bool + default y if KERNEL_KPROBES + config KERNEL_AIO bool Compile the kernel with asynchronous IO support default n diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk index 3a32209..24d2630 100644 --- a/include/kernel-defaults.mk +++ b/include/kernel-defaults.mk @@ -107,7 +107,6 @@ define Kernel/Configure/Default echo # CONFIG_KALLSYMS_EXTRA_PASS is not set $(LINUX_DIR)/.config.target echo # CONFIG_KALLSYMS_ALL is not set $(LINUX_DIR)/.config.target echo # CONFIG_KALLSYMS_UNCOMPRESSED is not set $(LINUX_DIR)/.config.target - echo # CONFIG_KPROBES is not set $(LINUX_DIR)/.config.target $(SCRIPT_DIR)/metadata.pl kconfig $(TMP_DIR)/.packageinfo $(TOPDIR)/.config $(KERNEL_PATCHVER) $(LINUX_DIR)/.config.override $(SCRIPT_DIR)/kconfig.pl 'm+' '+' $(LINUX_DIR)/.config.target /dev/null $(LINUX_DIR)/.config.override $(LINUX_DIR)/.config $(call Kernel/SetNoInitramfs) diff --git a/target/linux/generic/config-3.10 b/target/linux/generic/config-3.10 index 4ccc969..c16d04b 100644 --- a/target/linux/generic/config-3.10 +++ b/target/linux/generic/config-3.10 @@ -204,6 +204,7 @@ CONFIG_ARM_DMA_MEM_BUFFERABLE=y # CONFIG_ARM_ERRATA_764369 is not set # CONFIG_ARM_ERRATA_775420 is not set # CONFIG_ARM_ERRATA_798181 is not set +# CONFIG_ARM_KPROBES_TEST is not set # CONFIG_ARM_PATCH_PHYS_VIRT is not set # CONFIG_ARM_PSCI is not set # CONFIG_ARM_UNWIND is not set @@ -1551,6 +1552,7 @@ CONFIG_KERNEL_XZ=y # CONFIG_KGDB is not set # CONFIG_KMEMCHECK is not set # CONFIG_KPROBES is not set +# CONFIG_KPROBES_SANITY_TEST is not set # CONFIG_KS8842 is not set # CONFIG_KS8851 is not set # CONFIG_KS8851_MLL is not set @@ -2172,6 +2174,7 @@ CONFIG_NET_SCH_FQ_CODEL=y # CONFIG_NET_SCH_SFQ is not set # CONFIG_NET_SCH_TBF is not set # CONFIG_NET_SCH_TEQL is not set +# CONFIG_NET_TCPPROBE is not set # CONFIG_NET_TEAM is not set # CONFIG_NET_TULIP is not set CONFIG_NET_VENDOR_3COM=y @@ -2569,6 +2572,7 @@ CONFIG_PPP_MULTILINK=y # CONFIG_PPTP is not set # CONFIG_PREEMPT is not set CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_TRACER is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_PRINTK=y diff --git a/target/linux/generic/config-3.14 b/target/linux/generic/config-3.14 index 150c6e3..846ea1e 100644 --- a/target/linux/generic/config-3.14 +++ b/target/linux/generic/config-3.14 @@ -229,6 +229,7 @@ CONFIG_ARM_DMA_MEM_BUFFERABLE=y # CONFIG_ARM_ERRATA_773022 is not set # CONFIG_ARM_ERRATA_775420 is not set # CONFIG_ARM_ERRATA_798181 is not set +# CONFIG_ARM_KPROBES_TEST is not set # CONFIG_ARM_PATCH_PHYS_VIRT is not set # CONFIG_ARM_PSCI is not set # CONFIG_ARM_PTDUMP is not set @@ -1687,6 +1688,7 @@ CONFIG_KERNEL_XZ=y # CONFIG_KGDB is not set # CONFIG_KMEMCHECK is not set # CONFIG_KPROBES is not set +# CONFIG_KPROBES_SANITY_TEST is not set # CONFIG_KS8842 is not set # CONFIG_KS8851 is not set # CONFIG_KS8851_MLL is not set @@ -2347,6 +2349,7 @@ CONFIG_NET_SCH_FQ_CODEL=y # CONFIG_NET_SCH_SFQ is not set # CONFIG_NET_SCH_TBF is not set # CONFIG_NET_SCH_TEQL is not set +# CONFIG_NET_TCPPROBE is not set # CONFIG_NET_TEAM is not set # CONFIG_NET_TULIP is not set CONFIG_NET_VENDOR_3COM=y @@ -2762,6 +2765,7 @@ CONFIG_PPP_MULTILINK=y # CONFIG_PPTP is not set # CONFIG_PREEMPT is not set CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_TRACER is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_PRINTK=y diff --git a/target/linux/generic/config-3.18 b/target/linux/generic/config-3.18 index 15fea1d..de12bc7 100644 --- a/target/linux/generic/config-3.18 +++
[OpenWrt-Devel] [PATCH 5/5] kernel: upgrade 4.0 to rc6
Signed-off-by: Mathieu Olivari math...@codeaurora.org --- include/kernel-version.mk | 4 +-- .../patches-4.0/668-fix-ipv6-throw-routes.patch| 31 -- 2 files changed, 2 insertions(+), 33 deletions(-) delete mode 100644 target/linux/generic/patches-4.0/668-fix-ipv6-throw-routes.patch diff --git a/include/kernel-version.mk b/include/kernel-version.mk index 16f76e7..977c8a0 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -7,14 +7,14 @@ LINUX_VERSION-3.10 = .58 LINUX_VERSION-3.13 = .7 LINUX_VERSION-3.14 = .35 LINUX_VERSION-3.18 = .9 -LINUX_VERSION-4.0 = -rc5 +LINUX_VERSION-4.0 = -rc6 LINUX_KERNEL_MD5SUM-3.8.13 = 2af19d06cd47ec459519159cdd10542d LINUX_KERNEL_MD5SUM-3.10.58 = 3ff3478b6351143cef22d4b81cf48b01 LINUX_KERNEL_MD5SUM-3.13.7 = 370adced5e5c1cb1d0d621c2dae2723f LINUX_KERNEL_MD5SUM-3.14.35 = e5e92c40d14bc8ae9a8701db4e1cbb27 LINUX_KERNEL_MD5SUM-3.18.9 = 44cd16ada5eb03589f696f083cd2323b -LINUX_KERNEL_MD5SUM-4.0-rc5 = b26150c980099ef554b26d07f470e647 +LINUX_KERNEL_MD5SUM-4.0-rc6 = bec0aeeacab2852d9a17ccbfa7e280f8 ifdef KERNEL_PATCHVER LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER))) diff --git a/target/linux/generic/patches-4.0/668-fix-ipv6-throw-routes.patch b/target/linux/generic/patches-4.0/668-fix-ipv6-throw-routes.patch deleted file mode 100644 index 283ffce..000 --- a/target/linux/generic/patches-4.0/668-fix-ipv6-throw-routes.patch +++ /dev/null @@ -1,31 +0,0 @@ -From 9cd600244515bd4540898411ab781a97f0cc387f Mon Sep 17 00:00:00 2001 -From: Steven Barth ste...@midlink.org -Date: Thu, 19 Mar 2015 11:54:50 +0100 -Subject: [PATCH] ipv6: fix backtracking for throw routes - -for throw routes to trigger evaluation of other policy rules -EAGAIN needs to be propagated up to fib_rules_lookup -similar to how its done for IPv4 - -A simple testcase for verification is: - -ip -6 rule add lookup 3 priority 3 -ip -6 route add throw 2001:db8::1 -ip -6 route add 2001:db8::1 via fe80::1 dev wlan0 table 3 -ip route get 2001:db8::1 - -Signed-off-by: Steven Barth cy...@openwrt.org - net/ipv6/fib6_rules.c | 1 + - 1 file changed, 1 insertion(+) - a/net/ipv6/fib6_rules.c -+++ b/net/ipv6/fib6_rules.c -@@ -104,6 +104,7 @@ static int fib6_rule_action(struct fib_r - goto again; - flp6-saddr = saddr; - } -+ err = rt-dst.error; - goto out; - } - again: -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/5] ipq806x: clean up kernel conf
Signed-off-by: Mathieu Olivari math...@codeaurora.org --- target/linux/ipq806x/config-3.18 | 5 - 1 file changed, 5 deletions(-) diff --git a/target/linux/ipq806x/config-3.18 b/target/linux/ipq806x/config-3.18 index 97687ac..b2f5571 100644 --- a/target/linux/ipq806x/config-3.18 +++ b/target/linux/ipq806x/config-3.18 @@ -82,7 +82,6 @@ CONFIG_CRC16=y # CONFIG_CRC32_SARWATE is not set CONFIG_CRC32_SLICEBY8=y CONFIG_CROSS_MEMORY_ATTACH=y -# CONFIG_CRYPTO_DEV_QCE is not set # CONFIG_CRYPTO_SHA1_ARM_NEON is not set # CONFIG_CRYPTO_SHA512_ARM_NEON is not set CONFIG_CRYPTO_XZ=y @@ -103,10 +102,8 @@ CONFIG_DTC=y # CONFIG_DW_DMAC_CORE is not set # CONFIG_DW_DMAC_PCI is not set CONFIG_DYNAMIC_DEBUG=y -# CONFIG_EMAC_ROCKCHIP is not set CONFIG_ETHERNET_PACKET_MANGLE=y CONFIG_FREEZER=y -CONFIG_FW_LOADER_USER_HELPER=y CONFIG_GENERIC_ALLOCATOR=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_CLOCKEVENTS=y @@ -215,7 +212,6 @@ CONFIG_MDIO_GPIO=y CONFIG_MIGHT_HAVE_CACHE_L2X0=y CONFIG_MIGHT_HAVE_PCI=y CONFIG_MIGRATION=y -# CONFIG_MMC_SDHCI_MSM is not set CONFIG_MODULES_USE_ELF_REL=y CONFIG_MSM_GCC_8660=y CONFIG_MSM_GCC_8960=y @@ -228,7 +224,6 @@ CONFIG_MTD_M25P80=y CONFIG_MTD_SPI_NOR=y CONFIG_MTD_SPLIT_FIRMWARE=y CONFIG_MTD_SPLIT_FIT_FW=y -CONFIG_MTD_SPLIT_SUPPORT=y CONFIG_MULTI_IRQ_HANDLER=y CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_NEED_DMA_MAP_STATE=y -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
