Re: [OpenWrt-Devel] [PATCH 00/32] atheros: various cleanups
Hi Sergey, did a quick review of the series and it looks good. i will merge it as is so that we don't loose too much time. we can do the rest of the review cleanup on the linux-mips. i have pushed the patches just now, please check if i merged them correctly/ John On 12/09/2014 04:00, Sergey Ryazanov wrote: Final cleanup series before pushing code upstream. Cleanup all sparce errors and almost all checkpatch warnings (have a few warnings agains config symbol help). And many more cleanups. Flash and ethernet drivers still need some work, especially ethernet driver. Whole series tested with following boards: DWL-2100AP (AR2313 based) FON2202 (AR2315 based) LiteStation2 (AR2316 based) DIR-300 (AR2317 based) Sergey Ryazanov (32): atheros: avoid extern prototypes atheros: add missing include atheros: use NULL instead of plain integer atheros: use static keywork for local code atheros: add blank line after declarations atheros: remove FSF mailing address atheros: remove useless return atheros: ar2315-spiflash: use devm_* API to simplify the code atheros: ar2315-spiflash: update initialization atheros: ar2315-spiflash: use mutex inplace of spinlock atheros: ar231x-eth: remove useless IOCTL handlers atheros: remove useless includes atheros: update ether addresses handling atheros: rework and cleanup board initialization atheros: various space related changes atheros: remove odd ATHEROS_AR2315 config symbol dependencies atheros: ar2315-pci: remove odd locking in PCI config space access function atheros: ar2315-pci: cosmetic changes atheros: ar2315-pci: rework host controller initialization atheros: ar2315-pci: rework interrupt handling atheros: ar2315-pci: rework the configuration access code atheros: ar2315-pci: update host bridge resources atheros: ar2315-pci: update DMA offset macroses atheros: ar2315-pci: rename configuration symbol atheros: ar2315-pci: convert to platform driver atheros: add AR2316 and AR2318 SoCs detection atheros: rename SoCs config symbols atheros: convert gpio.h to stub atheros: rework chained interrupts handling atheros: convert AR5312 GPIO code to platform driver atheros: convert AR2315 GPIO code to platform driver atheros: refresh config target/linux/atheros/config-3.14 | 12 +- target/linux/atheros/patches-3.14/100-board.patch | 700 +++-- .../patches-3.14/101-early-printk-support.patch| 4 +- .../atheros/patches-3.14/102-ar5312_gpio.patch | 194 ++ .../atheros/patches-3.14/103-ar2315_gpio.patch | 315 ++ .../atheros/patches-3.14/105-ar2315_pci.patch | 440 - .../atheros/patches-3.14/110-ar2313_ethernet.patch | 89 +-- .../linux/atheros/patches-3.14/120-spiflash.patch | 161 ++--- .../linux/atheros/patches-3.14/130-watchdog.patch | 6 +- .../patches-3.14/220-enet_micrel_workaround.patch | 17 +- 10 files changed, 1074 insertions(+), 864 deletions(-) create mode 100644 target/linux/atheros/patches-3.14/102-ar5312_gpio.patch create mode 100644 target/linux/atheros/patches-3.14/103-ar2315_gpio.patch ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch
Am 12.09.2014 um 03:48 schrieb Linus Lüssing: Another idea would maybe be to translate MLDv1 / IGMPv2 reports into appropriate MLDv2/IGMPv3 equivalents before sharing them on the bridge to prevent the suppression. Hm, IGMPv2/MLDv1 to IGMPv3/MLDv2 should be relatively easy. But I'm currently not sure whether a router/querier will make and take some wrong assumptions and actions by thinking there is no IGMPv2/MLDv1 listener. What if there is one MLDv2 listener which included source specific state messages in its state change report? The querier would respond with a Multicast Address and Source Specific Query to learn whether there are listeners left for this multicast and source addresses. Would the MLDv1 listener interpret this query and process this message as a Multicast Address Specific Query or would it ignore it? It doesn't really matter since sending / receiving address-and-source-specific queries doesn't reduce the filter timer of the group but only the source timers of the sources included in the query. What about the many MLDv1 queriers we have right now through the bridge code? What if someone sneaks in an MLDv1 listener somewhere in your bridged network over an ethernet cable? (You'd need report translation both on the AP and on bridges and maybe query translation, too) Ah so the bridge code is actually a dumb v1-querier. Hmm that is problematic then I suppose. But doesn't that effectively downgrade the whole link to MLDv1 even if you potentially have a v2 querier at hand? Sounds very fishy to me. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/32] atheros: various cleanups
2014-09-12 10:51 GMT+04:00, John Crispin blo...@openwrt.org: Hi Sergey, did a quick review of the series and it looks good. i will merge it as is so that we don't loose too much time. we can do the rest of the review cleanup on the linux-mips. i have pushed the patches just now, please check if i merged them correctly/ All patches are merged correctly. Thank you. On 12/09/2014 04:00, Sergey Ryazanov wrote: Final cleanup series before pushing code upstream. Cleanup all sparce errors and almost all checkpatch warnings (have a few warnings agains config symbol help). And many more cleanups. Flash and ethernet drivers still need some work, especially ethernet driver. Whole series tested with following boards: DWL-2100AP (AR2313 based) FON2202 (AR2315 based) LiteStation2 (AR2316 based) DIR-300 (AR2317 based) Sergey Ryazanov (32): atheros: avoid extern prototypes atheros: add missing include atheros: use NULL instead of plain integer atheros: use static keywork for local code atheros: add blank line after declarations atheros: remove FSF mailing address atheros: remove useless return atheros: ar2315-spiflash: use devm_* API to simplify the code atheros: ar2315-spiflash: update initialization atheros: ar2315-spiflash: use mutex inplace of spinlock atheros: ar231x-eth: remove useless IOCTL handlers atheros: remove useless includes atheros: update ether addresses handling atheros: rework and cleanup board initialization atheros: various space related changes atheros: remove odd ATHEROS_AR2315 config symbol dependencies atheros: ar2315-pci: remove odd locking in PCI config space access function atheros: ar2315-pci: cosmetic changes atheros: ar2315-pci: rework host controller initialization atheros: ar2315-pci: rework interrupt handling atheros: ar2315-pci: rework the configuration access code atheros: ar2315-pci: update host bridge resources atheros: ar2315-pci: update DMA offset macroses atheros: ar2315-pci: rename configuration symbol atheros: ar2315-pci: convert to platform driver atheros: add AR2316 and AR2318 SoCs detection atheros: rename SoCs config symbols atheros: convert gpio.h to stub atheros: rework chained interrupts handling atheros: convert AR5312 GPIO code to platform driver atheros: convert AR2315 GPIO code to platform driver atheros: refresh config target/linux/atheros/config-3.14 | 12 +- target/linux/atheros/patches-3.14/100-board.patch | 700 +++-- .../patches-3.14/101-early-printk-support.patch| 4 +- .../atheros/patches-3.14/102-ar5312_gpio.patch | 194 ++ .../atheros/patches-3.14/103-ar2315_gpio.patch | 315 ++ .../atheros/patches-3.14/105-ar2315_pci.patch | 440 - .../atheros/patches-3.14/110-ar2313_ethernet.patch | 89 +-- .../linux/atheros/patches-3.14/120-spiflash.patch | 161 ++--- .../linux/atheros/patches-3.14/130-watchdog.patch | 6 +- .../patches-3.14/220-enet_micrel_workaround.patch | 17 +- 10 files changed, 1074 insertions(+), 864 deletions(-) create mode 100644 target/linux/atheros/patches-3.14/102-ar5312_gpio.patch create mode 100644 target/linux/atheros/patches-3.14/103-ar2315_gpio.patch -- BR, Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] libatomic patch
Hello, We're using OpenVSwitch on OpenWRT, and we've been looking into an upgrade from 2.0 to 2.3. Seems that OVS, is dependent on libatomic, which is not exported from the toolchain, though it is built. We've found this patch in patchwork. http://patchwork.openwrt.org/patch/5019/ [ Sorry for not using the Message ID for the In-Reply-To field. I'm using GMail in the browser. ] This patch is exactly what we needed to get libatomic in and have OVS 2.3 working. I will add that the subject of the patch is not too helpful/correct. However the patch is clean. We would like to ask that it is reviewed and [if no objections exist] be included in the main OpenWRT trunk. Thanks Alex ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] libatomic patch
There you go. It would be nice if anyone could maintain a package for openvswitch in the packages or routing-feed then. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] libatomic patch
Awesome. Thanks for updating it. If nobody else wants to step forward for maintaining the OVS feed, I'll fully commit to maintaining it. [ Well, that is, if I'm allowed ] Thanks Alex On Fri, Sep 12, 2014 at 3:30 PM, Steven Barth cy...@openwrt.org wrote: There you go. It would be nice if anyone could maintain a package for openvswitch in the packages or routing-feed then. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ubus: Explicitly add _GNU_SOURCE in CMakeList definitions
Commit b79e808 added O_CLOEXEC marking of ubus socket which requires _GNU_SOURCE define to be set on some systems to avoid compilation issue. Signed-off-by: Hans Dedecker dedec...@gmail.com --- CMakeLists.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index cb2f420..90e0c93 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -1,7 +1,7 @@ cmake_minimum_required(VERSION 2.6) PROJECT(ubus C) -ADD_DEFINITIONS(-Os -Wall -Werror --std=gnu99 -g3 -Wmissing-declarations) +ADD_DEFINITIONS(-Os -D_GNU_SOURCE -Wall -Werror --std=gnu99 -g3 -Wmissing-declarations) OPTION(BUILD_LUA build Lua plugin ON) OPTION(BUILD_EXAMPLES build examples ON) -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] netifd: Override interface macaddr/mtu not working when new style vlan devices are used
As described in the OpenWRT network wiki (http://wiki.openwrt.org/doc/uci/network#options.valid.for.all.protocol.types) common interface uci parameters can be defined like mtu/macaddr/... which override the default interface values. This is working fine when old style vlan configuration is used to override these parameters as can be seen below config interface 'wan' option proto 'dhcp' option mtu '1450' option macaddr 'aa:bb:cc:dd:ee:ff' option ifname 'ptm0.20' ip link show ... 22: ptm0.20@ptm0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1450 qdisc noqueue state UP mode DEFAULT group default link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff .. Using the new device style configuration to define vlans overriding parameters like mtu/macaddr is not working config interface 'wan' option proto 'dhcp' option mtu '1450' option macaddr 'aa:bb:cc:dd:ee:ff' option ifname 'vlan20' config device 'vlan20' option type '8021q' option ifname 'ptm0' option name 'vlan20' option vid '20' ip link show 21: vlan20@ptm0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether a4:b1:e9:47:54:54 brd ff:ff:ff:ff:ff:ff However you can workaround the issue by defining mtu/macaddr in the device section config interface 'wan' option proto 'dhcp' option mtu '1450' option macaddr 'aa:bb:cc:dd:ee:ff' option ifname 'vlan20' config device 'vlan20' option type '8021q' option ifname 'ptm0' option name 'vlan20' option vid '20' option mtu '1450' option macaddr 'aa:bb:cc:dd:ee:ff' ip link show ... 21: vlan20@ptm0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1450 qdisc noqueue state UP mode DEFAULT group default link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff ... Now I'm a bit puzzled if the oberved behavior (need to define mtu/macaddr in the device section to make override work) is expected behavior by design choice or does it need to be considered as bug ? Looking into the netifd code devices are passed the interface config data only when the default_config flag is set which is not the case for the vlan devices and thus common interface parameters cannot be overridden Thx, Hans ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] netifd: Override interface macaddr/mtu not working when new style vlan devices are used
On Friday 12 September 2014 15:13:11 Hans Dedecker wrote: Now I'm a bit puzzled if the oberved behavior (need to define mtu/macaddr in the device section to make override work) is expected behavior by design choice or does it need to be considered as bug ? I believe macaddress and mtu are device specific stuff so in it good that you have to put them in the device section and not in the interface section ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] libatomic patch
Hi Alexandru, sure go ahead. I think there are already some package-definitions on github https://github.com/pichuang/openvwrt/ which you can base the package on. I think the easiest way would be to read our guidelines at: https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md and then make a pull request for that repository with the new package. Cheers, Steven Am 12.09.2014 um 14:51 schrieb Alexandru Ardelean: Awesome. Thanks for updating it. If nobody else wants to step forward for maintaining the OVS feed, I'll fully commit to maintaining it. [ Well, that is, if I'm allowed ] Thanks Alex On Fri, Sep 12, 2014 at 3:30 PM, Steven Barth cy...@openwrt.org mailto:cy...@openwrt.org wrote: There you go. It would be nice if anyone could maintain a package for openvswitch in the packages or routing-feed then. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org mailto: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] [RFC] netifd: Override interface macaddr/mtu not working when new style vlan devices are used
On Fri, Sep 12, 2014 at 3:50 PM, Gioacchino Mazzurco g...@eigenlab.org wrote: On Friday 12 September 2014 15:13:11 Hans Dedecker wrote: Now I'm a bit puzzled if the oberved behavior (need to define mtu/macaddr in the device section to make override work) is expected behavior by design choice or does it need to be considered as bug ? I believe macaddress and mtu are device specific stuff so in it good that you have to put them in the device section and not in the interface section Fair point and no objection from my side to put these parameters under the device section. Just it needs to be made clear this is the vision for the future as currently there's confusion as the wiki documentation does not align the actual implementation ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] libatomic patch
Hey Steven, At the moment we use this one as base: https://github.com/hschaa/openvswitch-feed I did also take a look also at pichuang's repo. I'll take a look at multiple versions and try to pull in all the cleanest elements from each. Then do some tests and come back with a pull request on Github. Thanks Alex On Fri, Sep 12, 2014 at 5:11 PM, Steven Barth cy...@openwrt.org wrote: Hi Alexandru, sure go ahead. I think there are already some package-definitions on github https://github.com/pichuang/openvwrt/ which you can base the package on. I think the easiest way would be to read our guidelines at: https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md and then make a pull request for that repository with the new package. Cheers, Steven Am 12.09.2014 um 14:51 schrieb Alexandru Ardelean: Awesome. Thanks for updating it. If nobody else wants to step forward for maintaining the OVS feed, I'll fully commit to maintaining it. [ Well, that is, if I'm allowed ] Thanks Alex On Fri, Sep 12, 2014 at 3:30 PM, Steven Barth cy...@openwrt.org wrote: There you go. It would be nice if anyone could maintain a package for openvswitch in the packages or routing-feed then. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] libatomic patch
Oh fine with me as well. Use whatever version or patches you think works best. I was just suggesting a starting point in case you needed one. Feel free to ignore it though. Cheers, Steven On 12. September 2014 16:26:16 MESZ, Alexandru Ardelean ardeleana...@gmail.com wrote: Hey Steven, At the moment we use this one as base: https://github.com/hschaa/openvswitch-feed I did also take a look also at pichuang's repo. I'll take a look at multiple versions and try to pull in all the cleanest elements from each. Then do some tests and come back with a pull request on Github. Thanks Alex On Fri, Sep 12, 2014 at 5:11 PM, Steven Barth cy...@openwrt.org wrote: Hi Alexandru, sure go ahead. I think there are already some package-definitions on github https://github.com/pichuang/openvwrt/ which you can base the package on. I think the easiest way would be to read our guidelines at: https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md and then make a pull request for that repository with the new package. Cheers, Steven Am 12.09.2014 um 14:51 schrieb Alexandru Ardelean: Awesome. Thanks for updating it. If nobody else wants to step forward for maintaining the OVS feed, I'll fully commit to maintaining it. [ Well, that is, if I'm allowed ] Thanks Alex On Fri, Sep 12, 2014 at 3:30 PM, Steven Barth cy...@openwrt.org wrote: There you go. It would be nice if anyone could maintain a package for openvswitch in the packages or routing-feed then. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] netifd: Override interface macaddr/mtu not working when new style vlan devices are used
On Friday 12 September 2014 16:21:53 Hans Dedecker wrote: Just it needs to be made clear this is the vision for the future as currently there's confusion as the wiki documentation does not align the actual implementation Yeah the wiki need to be updated ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
