**** BEGIN LOGGING AT Fri Jul 12 02:59:58 2013 Jul 12 07:32:31 build #317 of atheros is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/atheros/builds/317 Jul 12 07:48:26 build #319 of orion is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/319 Jul 12 08:01:38 nbd r37263 trunk/package/kernel/mac80211/patches/003-remove_bogus_modparams.patch * mac80211: remove bogus module params from compat.ko Jul 12 08:01:42 nbd r37264 trunk/package/ kernel/mac80211/patches/403-ath_regd_optional.patch kernel/mac80211/patches/300-pending_work.patch kernel/mac80211/patches/603-rt2x00-introduce-rt2x00eeprom.patch * mac80211: merge a fix for PS-Poll handling, refresh patches Jul 12 08:05:41 (For a non-OpenWRT project) I need to communicate with a switch. OpenWRT has a framework that I want to look into and maybe adapt for my needs. Just before starting, is there anything that would be good to know? I guess you didn't try to mainline it? Is there something in it your are not happy with? Jul 12 08:07:02 <[florian]> ukleinek: well, I really would like to mainline it, because I also plan on using swconfig for some of my company's product too Jul 12 08:08:13 [florian]: my company is very keen on mainline. I cannot promise anything but we might be willing to spend some of our time to help. Jul 12 08:08:37 <[florian]> ukleinek: you might want to see with nbd as last I talked about this with him he said he wanted to rework some stuff Jul 12 08:08:52 <[florian]> ukleinek: but besides that, I would like to see that framework being mainline Jul 12 08:09:04 <[florian]> ukleinek: as I do not think things like DSA are good enough for embedded for instance Jul 12 08:10:30 I didn't look into DSA (distributed Switch Architecture?) yet, but that is another candidate to look on. Jul 12 08:10:55 A colleague told it's more targetting at machines that have >1 switch and need to handle interconnections. Jul 12 08:11:12 <[florian]> well DSA is really Marvell centric and uses a mix of MDIO controls + in-band with ethernet management frames Jul 12 08:11:26 <[florian]> and yes, it is suitable when you need to cascade switches for instance Jul 12 08:11:28 ah right, that was another argument against it. Jul 12 08:11:37 <[florian]> also DSA will create virtual interfaces per-port, yikes Jul 12 08:12:03 nbd r37265 trunk/package/kernel/mac80211/Makefile Jul 12 08:12:03 mac80211: reconfigure in Build/Compile instead of Build/Configure to catch kernel config changes Jul 12 08:12:53 DSA is for devices where you want to treat switches as port multiplexers instead of fully functional switches Jul 12 08:13:24 <[florian]> nbd: last we talked about mainlining swconfig you said there were a bunch of things you wanted to update/change Jul 12 08:13:28 <[florian]> what was it? Jul 12 08:13:41 i don't have any list right now Jul 12 08:13:46 it's just a general round of cleanups Jul 12 08:14:02 + of bindings for switch port mappings Jul 12 08:14:02 <[florian]> do you think we could be good enough with its current state to propose it as RFC? Jul 12 08:14:04 + reporting to userspace Jul 12 08:14:26 RFC is okay Jul 12 08:14:33 to get some feedback Jul 12 08:14:54 <[florian]> I suspect people will ask us why we do not extend DSA or something similar Jul 12 08:15:31 because DSA uses a completely different structure that simply can't handle some things well Jul 12 08:15:40 especially when it comes to handling vlans Jul 12 08:15:50 <[florian]> that was a rhetorical question :) Jul 12 08:15:58 You have to argue why DSA is bad for your scenario and optimally present an approach that handles both. Jul 12 08:16:02 right, just giving you some answers in case people ask exactly that ;) Jul 12 08:16:42 <[florian]> one thing against DSA is that it simply is not suitable to manage low-end switches such as all the ADM6996 stuff and so on Jul 12 08:17:16 <[florian]> and not everyone wants to afford mangling the frames just for the sake of adding a in-frame trailer/header to do its business too Jul 12 08:18:19 * ukleinek gets interrupted and is AFK for a while. Jul 12 08:20:48 nbd r37266 branches/attitude_adjustment/ (107 files in 4 dirs) * mac80211: backport latest version from trunk (as of r37265) Jul 12 08:26:48 [florian], nbd: can you point me to an example driver using the switch stuff? Jul 12 08:27:57 <[florian]> ukleinek: a simple one that comes to mind is: Jul 12 08:27:59 <[florian]> target/linux/generic/files/drivers/net/phy/ip17xx.c Jul 12 08:28:23 <[florian]> drivers for the realtek switches or b53 are a bit more complex Jul 12 08:29:38 * ukleinek notes that. Thanks Jul 12 08:30:08 <[florian]> ip17xx uses one patch which is not upstream to hook into update_link and aneg_done Jul 12 08:30:53 * ukleinek 's current target would be drivers/net/ethernet/freescale/fec* Jul 12 08:31:32 <[florian]> switch drivers are nothing more than "augmented" phy lib drivers Jul 12 08:31:43 <[florian]> which is also the reason why they are "nice" Jul 12 08:32:45 <[florian]> if your driver already uses phylib, you should be able to bind directly to your corresponding switch driver Jul 12 08:33:16 The switch is a different problem as I don't have a datasheet and probably I can only get it under NDA. Jul 12 08:41:36 the .config_init, .config_aneg, .aneg_done, .update_link and .read_status callbacks all do the same for switches, right? Jul 12 08:42:02 <[florian]> each switch driver may hook into it Jul 12 08:43:21 what for? Jul 12 08:43:46 <[florian]> to perform some basica initialization or present an always up link state from the Ethernet MAC point of view Jul 12 08:43:58 I thought they all are a phy with link always available. Jul 12 08:44:33 <[florian]> yes that's true Jul 12 08:44:48 <[florian]> but since they are PHY drivers they need to present something consistent anyway Jul 12 08:44:57 <[florian]> for instance config_init is used to register a switch driver Jul 12 08:45:14 <[florian]> but yes all other callbacks usually behave the same with all switch drivers Jul 12 08:45:22 yeah, that's what I see in the ip17xx driver. I would expect other drivers not to need more. Jul 12 08:46:44 <[florian]> the lantiq PSB6970 driver seems to do a bit more, no idea why really Jul 12 08:48:09 ukleinek: another argument against DSA is that it currently forces the CPU to do forwarding between ports (unless you apply never accepted patches from marvell that add "bridge accelarators", i.e. propagate the bridge settings to (port) vlan settings) Jul 12 08:48:37 <[florian]> KanjiMonster: I think that is what nbd refered to earlier as "port multiplexer" Jul 12 08:49:50 in drivers/net/phy/ip17xx.c, don't you need to call ip17xx_reset before register_switch in ip17xx_config_init() Jul 12 08:49:53 ? Jul 12 08:52:36 <[florian]> since it takes a switch_dev argument, it would have to be modified if that was the case Jul 12 08:52:56 <[florian]> ah well, no I afair it can't because you need to probe the number of ports first Jul 12 08:53:57 note I don't have much glue about switches yet, it just looks wrong in general. Usually you first make your device ready, and only then register it to the framework. Jul 12 08:54:25 <[florian]> yes I agree with you, the way it is done though would mean refactoring this a bit Jul 12 08:55:41 ukleinek: the only parts that do anything with the exported device are userspace utilities, so it's currently a non issue as the switch often gets registered before userspace is even up due to in-kernel drivers Jul 12 08:58:15 KanjiMonster: so it only matters for modular drivers. Still I think this needs to be addressed for mainline submission. Jul 12 09:00:50 <_rmk_> or if the device is unbound and rebound via sysfs Jul 12 09:01:41 _rmk_: right Jul 12 09:02:04 <_rmk_> and publishing some device to the kernel before its initialized *is* a bug Jul 12 09:02:29 <_rmk_> to the kernel for userspace use Jul 12 09:03:34 <_rmk_> its a topic which got discussed at several kernel summits over the years Jul 12 09:03:52 <[florian]> that's a fair point Jul 12 13:12:26 hauke r37267 branches/attitude_adjustment/package/acx-mac80211/ (5 files in 2 dirs) * AA: acx-mac80211: make it compile with recent mac80211 again Jul 12 13:48:11 hauke r37268 trunk/target/ (19 files in 5 dirs) * bcm53xx: add initial support for ARM based BCM47XX and BCM53XX SoCs Jul 12 13:51:21 [Florian]: Do you remember that asked you about RTL8672 porting? I haven't the skills to make it work in openwrt :( At least found that the SoC is based in the RLX5181. Jul 12 13:54:59 I've learned a lot thanks to Kanjimonster, blogic, nbd, you and the rest of the openwrt team but is not enought. Jul 12 13:55:45 At least tried it :/ Jul 12 14:02:49 The_Lizard: maybe there is an alternative way to load openwrt boards that use BRN-BOOT as bootloader with a program called sp700ex: http://www.kessler-design.com/speedport-w700v/sp700ex.html Jul 12 14:04:39 more info here: https://forum.openwrt.org/viewtopic.php?pid=134522#p134522 Jul 12 14:08:33 KanjiMonster: i have a bcm6368 based router; if you need a some kind of betatester for something tell me it. Jul 12 14:12:05 build #308 of lantiq is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/308 Jul 12 15:27:51 build #60 of mpc85xx is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/60 Jul 12 15:30:48 build #287 of rb532 is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/287 Jul 12 15:33:57 build #287 of ppc44x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/287 Jul 12 16:04:27 Pteridium, looks promising, I have normal firmware in my device now, so I could test it... Jul 12 16:05:00 but it is possible that KPN (dutch ISP) has changed things so that the images are hashed... Jul 12 16:05:13 * have to be hashed/encrypted... Jul 12 16:05:23 build #268 of au1000 is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/268 Jul 12 16:06:55 Luckily I do understand a bit of german ;) Jul 12 16:12:48 The_Lizard: one moment, problems with internet Jul 12 16:22:29 The_Lizard: with sp700ex you can create an image that can be loaded from BRN-BOOT. You need an u-boot as second stage bootloader and locate the firmware signature. Jul 12 16:23:02 In the case of the arv4518pw the signature is BRNDANUBE Jul 12 16:26:38 The signature is located at the bottom of the firmware image or somewhere in the flash Jul 12 18:42:45 Pteridium, fyi: I have checked out the brndumper, it can't be used as long as the bootloaders password is a secret Jul 12 18:43:12 And the brn-boot loader can't be used yet.. Jul 12 18:44:15 It would be cool if we can create an image that can be loaded with the original firmware, so that we create an u-boot stage... Jul 12 22:00:39 build #272 of sibyte is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/272 Jul 12 22:28:30 build #301 of uml is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/301 Jul 12 22:30:51 build #274 of xburst is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/274 Jul 12 22:31:10 build #332 of at91 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/332 Jul 12 22:54:22 blogic: https://dev.openwrt.org/ticket/13861 Jul 13 00:05:25 build #289 of ar7 is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/289 Jul 13 01:56:04 build #245 of iop32x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/245 **** ENDING LOGGING AT Sat Jul 13 02:59:58 2013