**** BEGIN LOGGING AT Thu Jan 28 02:59:56 2010 Jan 28 03:00:13 rtz: oh wait...don't have working gpio-buttons on this platform Jan 28 03:01:16 rtz: let me try anyway...it's about time I looked at that anyway Jan 28 03:04:57 does anyone of you know where the b44 driver comes from? Jan 28 03:05:03 is it included in the kernel? Jan 28 03:07:47 cshore: do you have the neccesary stuff in the platfrom setup code of the kernel? Jan 28 03:08:08 yes...IIRC there's a bug though Jan 28 03:09:26 cshore i found the error Jan 28 03:09:41 ifconfig $ifname 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 up was missing Jan 28 03:09:47 in set_preinit_iface() { Jan 28 03:10:43 not that's not right...not supposed to hardcode 1.1 Jan 28 03:10:54 which variable should i use? Jan 28 03:11:30 the problem is that the device is down so it can be detect be the robo switch Jan 28 03:11:35 be=by Jan 28 03:11:39 so preinit doesnt work Jan 28 03:11:53 i llok at the old preinit/preinit.arch Jan 28 03:11:57 try ifconfig $ifname 0.0.0.0 up Jan 28 03:14:41 if it works ill send a mail to the mailing list Jan 28 03:14:50 with a patch attached Jan 28 03:14:56 but i think thats the eror Jan 28 03:14:58 error Jan 28 03:15:20 I think you might be right Jan 28 03:15:28 i know :) Jan 28 03:16:28 first i also thought it was caused by modded code .. but there was no mod .. so there must be another reason for this Jan 28 03:28:14 cshore: it works Jan 28 03:28:21 i send thje patch to the mailing list Jan 28 03:28:26 thje=the Jan 28 03:28:34 puchu: heh, thank...I'm glad you didn't listen to Jo and I Jan 28 03:29:24 yeah ... im glad im that mulish ;) Jan 28 03:30:14 cshore have a nice evening Jan 28 03:30:17 sleep well Jan 28 03:30:28 i will go to bed now Jan 28 03:30:29 puchu: you as well Jan 28 03:30:34 thanks Jan 28 03:30:36 bye Jan 28 04:29:35 rtz: I am an ooops in gpio-buttons to debug...it was there before but I haven't had a chance to debug or to get Florian to look at it Jan 28 04:33:57 hey, less then 20 missing externals :D Jan 28 04:34:17 cshore: for which platform? Jan 28 04:34:26 brcm63xx Jan 28 04:34:38 sorry, nothing I have here Jan 28 04:34:50 rtz: do you have a backtrace? Jan 28 04:35:16 just the oops Jan 28 04:49:17 is make clean enough to repull from the target/linux/... directory for the build? Jan 28 05:52:20 marek * r19356 /packages/net/batman-advanced/ (Config.in Makefile files/etc/init.d/batman-adv-kernelland): Jan 28 05:52:20 batman-adv: adding support for the development branch Jan 28 05:52:20 * offer choice between maint/dev branch Jan 28 05:52:20 * make batctl optional upon user request Jan 28 05:52:20 * upgrade src version Jan 28 05:52:24 * fix EXTRA_CLFAGS Jan 28 05:52:26 Thanks to Linus Luessing for his help. Jan 28 06:11:22 no oops! Jan 28 06:11:51 ping rtz Jan 28 06:12:14 with evinput, I get /dev/input/event0 Jan 28 06:29:51 is it possible to use profiles to change kernel #ifdefs? Jan 28 07:12:06 anyone know how to debug why a reset button isn't generating a hotplug event? Jan 28 07:14:40 gpioctl is able to get the status Jan 28 08:58:16 ping rtz Jan 28 09:32:43 juhosg * r19357 /trunk/target/linux/ (6 files in 6 dirs): kernel: move mips_machine.h to 'arch/mips/include/asm' Jan 28 11:06:01 what is [ar71xx-spi] that i see in "top" ? Jan 28 11:20:34 Lalloso: a kernel thread i would assume Jan 28 11:20:43 I think it's the "bus" to the flash Jan 28 11:21:03 stintel: indeed Jan 28 11:21:13 spi == serial peripheral interface Jan 28 11:21:15 or 3 wire Jan 28 11:21:19 has many names Jan 28 11:21:35 it is 1 clock line , 1 data in and 1 data out Jan 28 11:21:50 additionally you can attach several devices but need a /CS line Jan 28 11:22:06 so you have 4 signales essentially SCL, SDI, SDO and CS Jan 28 11:22:19 some also use MISO MOSI SCK Jan 28 11:22:28 there are many names depending on the vendor Jan 28 11:29:38 is possible to modify kernel compilation via profiles (in menuconfig)? Jan 28 11:54:22 juhosg * r19358 /trunk/ (26 files in 6 dirs): kernel: update to 2.6.32.6 Jan 28 11:54:25 juhosg * r19359 /trunk/target/linux/ar71xx/ (3 files in 2 dirs): ar71xx: switch to 2.6.32 Jan 28 11:54:48 cool Jan 28 11:55:38 cshore: profiles has an effect on package selection Jan 28 11:55:47 sub targets can ship their own kernel config Jan 28 11:56:22 adm5120/router_be and adm5120/router_le are an example of this Jan 28 11:56:26 anyone have any idea if using devtmpfs would speed up anything during boot? Jan 28 11:56:31 as in target/linux/adm..... Jan 28 11:56:39 stintel: ? Jan 28 11:56:52 it does already imho Jan 28 11:57:04 unless preinit was changed recently Jan 28 11:57:23 blogic: ? Jan 28 11:57:38 devtmpfs is a .32+ feature, and we didn't use it Jan 28 11:57:50 devtmpfs was added in 2.6.32 iirc Jan 28 11:58:16 and I didnt find it in the config-2.6.32 of my target Jan 28 11:58:37 blogic: well it's not so much a different config as I want to do different GPIO assignments, based on router, which is different than board type Jan 28 11:58:44 I'll try to enable it in my next build Jan 28 11:59:44 stintel: you'll need to make sure you're not mounting tmpfs over top of it (that the default preinit behaviour, because the current (but I'm working on an update) preinit is not devtmpfs aware Jan 28 12:00:19 ok, thanks for the pointer Jan 28 12:00:42 blogic: but thinking about about it, it'd be better if that could be modified by a userspace program Jan 28 12:00:57 cshore: ermmm Jan 28 12:01:05 mach types and bootloader arguments Jan 28 12:01:12 or kernel command line Jan 28 12:01:21 Kaloz: true Jan 28 12:05:33 any idea what my my reset button isn't generating hotplug events even though gpioctl is able to read the correct GPIO port correctly? (with hotplug-button, evinput, and gpio-buttons)? Jan 28 12:12:38 hmm I don't find the CONFIG_DEVTMPFS in target/linux/ar71xx/config-2.6.32 but when doing make kernel_menuconfig it's already enabled. I guess I'll see what happens ;-) Jan 28 12:13:54 maybe it is enabled in the generic config ... target/linux/generic-2.6/config-2.6.32 Jan 28 12:14:19 it is merged together with the per-arch config Jan 28 12:18:55 aha Jan 28 12:19:22 jow_laptop: indeed, thanks Jan 28 12:25:15 jow: know anything about gpio-buttons? Jan 28 12:51:08 is tcpdump a feed of openwrt? Jan 28 12:52:31 it is in the packages feed Jan 28 13:11:18 k Jan 28 13:12:59 {Nico}: are you here? Jan 28 13:13:35 jow_laptop: is there a way to have feeds pointing to the right place while the base code points to my own svn? Jan 28 13:13:51 feeds.conf Jan 28 13:16:14 let me see Jan 28 13:16:32 jow_laptop do you work for openwrt? Jan 28 13:17:13 Lalloso: s/for/on/ - yes Jan 28 13:17:39 i'm working "with" openwrt at the moemnt Jan 28 13:17:46 but do you get an earning from openwrt? Jan 28 13:17:55 i mean the official noprofit organization Jan 28 13:18:02 no Jan 28 13:49:35 is a MIPS 24Kc V7.4 better or worse than a MIPS 34K V4.12 ? Jan 28 13:50:14 mips 34k is newer Jan 28 13:50:21 dunno if it is better or worse Jan 28 13:50:36 also i think 34k supports vpe, but dont quote me on that Jan 28 13:55:42 it supports two vpes Jan 28 13:55:49 what are vpe in any case? Jan 28 13:55:56 34K ASEs implemented : mips16 dsp mt Jan 28 13:56:10 lalloso is this a ar9 ? Jan 28 13:56:19 i am trying freeswitch and on the 34k it goes to 100% Jan 28 13:56:26 while on the 24kC it works Jan 28 13:56:37 what is ar9? Jan 28 13:56:42 it's an Amazon-S Jan 28 13:57:44 <{Nico}> Lalloso: 'lo Jan 28 13:58:21 {Nico} my friend i'm playing hard with freeswitch Jan 28 13:58:59 1.0.5 will be out february 8 Jan 28 13:59:06 <{Nico}> ok Jan 28 13:59:33 I still have to play with it in order to provide you the right patches to the makefiles Jan 28 13:59:45 and have it all in just one directory like usr/local/freeswitch Jan 28 14:00:14 do you want me to patch it also in order to have 1.0.5 instead of 1.0.4 ? Jan 28 14:01:20 or maybe is it better to just use http://latest.freeswitch.org/ ? Jan 28 14:02:32 Lalloso: did you get the sdk from infineon ? Jan 28 14:02:38 and it is the owrt version Jan 28 14:02:39 ? Jan 28 14:02:41 woot!!!! Jan 28 14:02:45 nice nice nice Jan 28 14:13:56 :) Jan 28 14:23:50 ping nbd Jan 28 14:25:59 rtz: do u have commit access? Jan 28 14:26:05 there is a bug that should be fixed Jan 28 14:26:14 in init Jan 28 14:45:21 puchu: nope, sorry Jan 28 14:47:28 ping rtz Jan 28 14:50:44 cshore: yes? Jan 28 14:51:17 I'm trying to get my gpio-buttons/button-hotplug working and having no luck Jan 28 14:51:33 cshore: where exactly is the problem? Jan 28 14:51:35 but gpioctl can access the pin fine Jan 28 14:52:07 it gpio-buttons or button-hotplug....I don't know which Jan 28 14:53:25 cshore: can you point me to the code, where the gpio_buttons platfrom device is set up in the kernel? Jan 28 14:55:35 /target/linux/brcm63xx/files/arch/mips/bcm63xx/boards/board_bcm963xx.c Jan 28 14:56:15 let me pastebin....I've modified from tree...there was a bug Jan 28 14:57:39 http://openwrt.pastebin.ca/1769395 Jan 28 14:59:26 cshore: you are missing the most important thing ;) Jan 28 14:59:35 what's that? Jan 28 15:00:27 cshore: the gpio line and the key code Jan 28 15:00:30 cshore: https://dev.openwrt.org/browser/trunk/target/linux/rdc/files-2.6.30/arch/x86/mach-rdc321x/platform.c#L106 Jan 28 15:01:45 or wait Jan 28 15:01:48 }, .reset_buttons = { { .desc = "reset", .gpio = 36, .active_low = 1, .type = EV_KEY, .code = BTN_0, .threshold = Jan 28 15:01:51 bah Jan 28 15:02:15 that paste didn't go so well Jan 28 15:02:39 cshore: what board do you have? Jan 28 15:02:51 96348GW Jan 28 15:03:20 cshore: I will have to take a closer look at it Jan 28 15:03:34 cshore: but I have to eat now, will be back in 15 min Jan 28 15:03:47 ok, thanks Jan 28 15:23:43 is there a way to manually install a feed? Jan 28 15:29:18 or which is the path where they get installed? Jan 28 15:29:19 <{Nico}> Lalloso: copy ./feeds.conf.default to ./feeds.conf and edit it Jan 28 15:29:29 let me try Jan 28 15:29:44 <{Nico}> feeds get fetched in the ./feeds directory Jan 28 15:30:33 <{Nico}> i have the following in mine: Jan 28 15:30:47 <{Nico}> src-link packages ../../packages-ref Jan 28 15:31:26 can i have this src-svn packages https://svn.openwrt.org/openwrt/packages ? Jan 28 15:31:40 isn't that already in there? Jan 28 15:31:47 also it must be svn:// not https:// Jan 28 15:31:52 i can't svn out Jan 28 15:31:55 i need https Jan 28 15:31:57 :-( Jan 28 15:32:13 <{Nico}> nope, do what jow_laptop is suggesting Jan 28 15:32:21 that is the default Jan 28 15:32:28 and it does not work for me Jan 28 15:32:30 :-( Jan 28 15:32:34 <{Nico}> well, the default is wrong then :) Jan 28 15:32:44 no wait Jan 28 15:32:58 the default is: src-svn packages svn://svn.openwrt.org/openwrt/packages Jan 28 15:33:05 <{Nico}> better Jan 28 15:33:10 you can check it out somewhere else, copy the checkout over to your machine and then use src-link Jan 28 15:33:23 okay Jan 28 15:33:30 src-link means actual filesystem right? Jan 28 15:33:34 correct Jan 28 15:33:47 src-link my_local_feed /usr/src/packages/ Jan 28 15:33:52 k Jan 28 15:34:23 then Jan 28 15:34:31 ./scripts/feeds update my_local_feed Jan 28 15:34:39 ./scripts/feeds install -a -p my_local_feed Jan 28 15:35:09 update will scan the directory for packages, install will pull it into the buildroot Jan 28 15:35:22 ... using symlinks Jan 28 15:35:52 cshore: are you leds working? Jan 28 15:38:25 rtz: yes Jan 28 15:43:29 cshore: and if you check gpio 36 manually, you will get the expected result? Jan 28 15:43:39 cshore: 0 on pressed button, 1 otherwise? Jan 28 15:43:47 that's right Jan 28 15:44:22 cshore: is the gpio_buttons driver loaded and the input device created? Jan 28 15:44:29 yes Jan 28 15:44:34 even0 Jan 28 15:44:39 /dev/input/even0 Jan 28 15:44:47 event0 Jan 28 15:45:20 cshore: the buttons_hotplug driver is also laoded? Jan 28 15:45:25 yes Jan 28 15:46:11 i can't find /var/log/messages in openwrt Jan 28 15:46:17 is there another way to read syslog? Jan 28 15:46:21 logread Jan 28 15:46:36 sweet Jan 28 15:46:38 but when I put echo "$(date)" >>/tmp/button.date it's never created Jan 28 15:47:00 in /etc/hotplug.d/button Jan 28 15:47:23 /etc/hotplug.d/button/01-youraction ? Jan 28 15:47:32 and trap "echo here" SIGUSR1 has not effect Jan 28 15:47:57 hmm...I just called it youraction (in /etc/hotplug.d/button) Jan 28 15:48:13 "button" is supposed to be a directory of scripts Jan 28 15:48:13 it shouldn't matter Jan 28 15:48:27 ah k Jan 28 15:48:30 yes shouldn't matter Jan 28 15:48:36 if it's called 01-youraction, or something else .. Jan 28 15:48:37 . Jan 28 15:48:53 as long as it's in /etc/hotplug.d/button/ Jan 28 15:48:57 and does hotplug-call button works? Jan 28 15:49:20 haven't tried it...just a sec Jan 28 15:52:47 what parameters should I call hotplug-call with? Jan 28 15:53:26 just button should be enough for testing Jan 28 15:53:43 usually there are some environment variables passed along like ACTION and DEVICE Jan 28 15:59:00 it's working now...I think I must have called the script button instead on the button directory Jan 28 16:00:57 I'm not getting SIGUSR1 though Jan 28 16:01:19 trap "echo here" SIGUSR1 Jan 28 16:01:22 does nothing Jan 28 16:01:48 but the date above is working (in /etc/hotplug.d/button/10-action Jan 28 16:02:03 mmm i have a program which takes 40% cpu usr and 60% cpu sys Jan 28 16:02:04 can you have both? Jan 28 16:02:07 100% cpu :) Jan 28 16:02:16 where do i get started for tracing the problem? Jan 28 16:04:40 hmmm...is /etc/hotplug2-init.rules actually going to do anything? Jan 28 16:04:59 That's where the USR1 signal is generated Jan 28 16:05:26 and since I'm not getting it, I'm guessing that files is never used Jan 28 16:05:47 cshore: it was originally Jan 28 16:05:55 cshore: not sure, if you messed it up ;) Jan 28 16:06:05 fresh flash Jan 28 16:06:10 cshore: take a look at the start commands for hotplug2 Jan 28 16:06:17 cshore: there should be 2 Jan 28 16:06:55 cshore: one with the init rule and another one with the normal rule Jan 28 16:07:15 Lalloso: top? Jan 28 16:07:24 I see it in preinit Jan 28 16:07:54 with top i see the processes taking up the cpu but how do i know the reason? Jan 28 16:08:20 same software on different mips works fine Jan 28 16:09:54 ahhhh, I see...those hotplug events would only be generating during preinit Jan 28 16:10:19 because boot kills the preinit hotplug daemon Jan 28 16:10:24 Lalloso: which process? Jan 28 16:10:31 freeswitch Jan 28 16:10:37 no, idea, sorry Jan 28 16:10:47 no problem Jan 28 16:11:14 cshore: the second hotplug daemon is started with the normal hotplug script Jan 28 16:11:24 cshore: I have no idea, why it is killed later Jan 28 16:12:06 it's deliberate...probably so hotplug has the new rootfs Jan 28 16:12:41 right, that's probably the reason Jan 28 16:16:57 nico * r19360 /packages/utils/ap51-flash/ (7 files in 3 dirs): [packages] add ap51-flash Jan 28 16:18:13 is this a valid command svn co https://svn.openwrt.org/openwrt/trunk openwrt ? Jan 28 16:18:33 i don't understand if svn.openwrt.org is just svn:// or also https:// Jan 28 16:18:42 not considering http:// :-) Jan 28 16:19:25 ok, the problem isn't the hotplug button thingy, it the kill -USR1 is kill hotplug, not the process that is trying to trap it Jan 28 16:24:29 kill -USR1 isn't work from the hotplug process to the shell Jan 28 16:27:09 ok kill -USR1 pid from one shell to another (telnet to ash) doesn't work Jan 28 16:27:40 or at least it's not trapped by the trap statement Jan 28 16:27:47 may trap only traps subshells Jan 28 16:28:47 that means buttons are broken for the purposes of falisafe on all platforms at the moment Jan 28 16:29:46 if I'm right, that is Jan 28 16:31:22 cshore: why should this fail? Jan 28 16:31:36 did you maybe mess up the pids somehow? Jan 28 16:31:55 nope, right pid Jan 28 16:33:01 <{Nico}> Lalloso: https://dev.openwrt.org/wiki/GetSource Jan 28 16:33:07 ah...nope it works Jan 28 16:33:14 wrong keyword Jan 28 16:34:55 there'll be a bug in preinit then Jan 28 16:37:04 yeah...buttons work! Jan 28 16:37:12 thanks guys Jan 28 16:38:23 5 unresolved externals! Jan 28 16:38:31 rtz: cool Jan 28 16:39:18 well, there are a number of stubs and some stuff still missing, but the main parts are there Jan 28 16:39:28 at least for a very simple implementation Jan 28 16:39:59 do events queue in the kernel or in the program? Jan 28 16:40:23 if in the kernel we check need to check if there are any events, and process them, and then exit Jan 28 16:40:46 not sure Jan 28 16:41:07 then the how long it waits could be controlled by the fs_wait_key function Jan 28 16:41:20 but this somehow place together with the --presist option of hotplug2 and udevtrigger Jan 28 16:42:06 have to go for some time now and kill somebody at MediaMarkt Jan 28 16:42:18 heh, what's going on ? Jan 28 16:42:31 or is that an arcade? Jan 28 16:47:30 cshore: electronic discounter Jan 28 16:47:45 cshore: and they also they mobile phone contracts Jan 28 16:48:18 rtz: and you have problems? Jan 28 16:48:35 cshore: it's a long and complex story, but I make it short, I have a contract I don't want to have because some call center guy lied to me Jan 28 16:48:49 rtz: ah, yes...I understand Jan 28 16:54:01 cshore * r19361 /trunk/target/linux/brcm63xx/files/ (2 files in 2 dirs): brcm63xx: Fix gpio-buttons and add LED and buttons for Tecom IGW6200 and Comtrend CT-5261 Jan 28 17:38:37 florian * r19362 /packages/net/mgen/ (. Makefile patches/ patches/100-ipv6.patch): [package] add mgen, patch from Roberto Riggio Jan 28 17:38:51 ping florian Jan 28 17:38:55 <[florian]> pong cshore Jan 28 17:39:27 [florian]: I have a patch for the rdc gpio Jan 28 17:39:36 <[florian]> rtz: ok, can I see it? Jan 28 17:39:38 [florian]: give me a minute Jan 28 17:40:03 [florian]: have to start my linux vm Jan 28 17:40:24 [florian]: i have also some idea about the problem with the not working switch ports Jan 28 17:40:55 [florian]: basic problem is, that not all phys are correctly initialized Jan 28 17:41:04 <[florian]> rtz: humm, I see Jan 28 17:41:06 [florian]: I think we need a way to deal with the fact that there are multiple routers with the same board id but different GPIO maps Jan 28 17:41:36 [florian]: unfortunatly, the current libphy has very bad support for multiple phys connected to one mac Jan 28 17:41:39 <[florian]> cshore: definitively, I wish we could runtime detect the model Jan 28 17:41:56 in fact, it's pretty much non exsistent and very hard to add Jan 28 17:41:58 <[florian]> rtz: yes, I remember we last talked about this, and multiple phys connected to a single mac is pretty rear Jan 28 17:42:03 <[florian]> s/rear/rare/ Jan 28 17:42:19 [florian]: actually, it's pretty common for embedded devices Jan 28 17:42:31 [florian]: can we specify at build time at least? We could also build specific images instead of every image every time Jan 28 17:42:31 [florian]: every switch has multiple phys Jan 28 17:43:06 <[florian]> cshore: I am not really fond of this, this introduces potential breakages for people choosing a bad image Jan 28 17:43:18 <[florian]> cshore: I would rather create a module which overrides the led settings for instance or something like this Jan 28 17:43:32 [florian]: I wrote a version of libphy with intristic support for this, but it's pretty much a complete rewrite Jan 28 17:43:50 [florian]: yeah that would be better Jan 28 17:44:16 [florian]: I showed it to nbd, but he didn't have the time to look at it yet, but he also had some doubts, if it's possible to get this into mainline Jan 28 17:44:29 [florian]: if you want, I can show it to you Jan 28 17:44:30 <[florian]> rtz: do you mind me looking at it too? Jan 28 17:44:44 <[florian]> cshore: let me think about a clean solution for this Jan 28 17:44:45 [florian]: one moment ;) Jan 28 17:44:59 <[florian]> rtz: still booting the VM ;) Jan 28 17:45:25 [florian]: vm is booted, but now it takes a few minutes until I can do anything there Jan 28 17:45:27 <[florian]> rtz: I recently got a bifferboard, so hopefully I will be able to mainline the gpiochip driver in a couple of days Jan 28 17:45:29 I need more ram :( Jan 28 17:46:33 [florian]: I basically wrote a pci driver for the southbridge, because that's where the watchdog and the gpio sits Jan 28 17:46:46 <[florian]> rtz: makes sense, that was what I was going to rewrite Jan 28 17:46:48 [florian] if we do the modules, would it be possible to use profiles to specifiy the image to build and the (default) led override module to include in the image? Jan 28 17:47:16 <[florian]> cshore: sure, the idea, is to let you have a module which would provide its own LED/buttons mapping Jan 28 17:47:19 [florian]: by the way, I can't get the watchdog to reboot the machine, looks like something isn't connected Jan 28 17:47:31 <[florian]> rtz: does "reboot" works? Jan 28 17:47:42 <[florian]> rtz: because the reboot quirk uses the watchdog with a very small delay to reboot the CPU Jan 28 17:47:58 [florian]: it doesn't Jan 28 17:48:06 [florian]: use the watchdog I mean Jan 28 17:48:14 [florian]: the comments are wrong Jan 28 17:48:24 [florian]: I checked the register usage Jan 28 17:48:41 [florian]: it uses the softreset future of the rdc in reg 0x90 Jan 28 17:48:45 or 92 Jan 28 17:48:47 not sure Jan 28 17:49:01 <[florian]> rtz: oh ok, I thought it used the internal watchdog Jan 28 17:49:08 <[florian]> rtz: then I will fix the comment too :) Jan 28 17:49:17 [florian]: you probably haven't seen you mail yet...I've committed the GPIO for button and LED for the GW6200 and Comtrend CT-5621 Jan 28 17:49:58 [florian]: if you give me a moment, I can tell you, what it does Jan 28 17:50:11 <[florian]> cshore: I actually did, and even replied to you :p Jan 28 17:50:29 <[florian]> rtz: no problem Jan 28 17:52:26 [florian] if you the led/button mapping module(s) does that mean the user could try different modules to see which ones worked for them? Jan 28 17:52:35 <[florian]> cshore: yes Jan 28 17:53:58 [florian]: I think that's what we're going to have to do, because AFAIK there's no special distinguishing features between different routers of the same board id Jan 28 17:54:21 [florian]: especially the older boards Jan 28 17:54:26 <[florian]> cshore: we could probably check for mac addresses ranges, but I do not like this Jan 28 17:56:22 [florian]: http://openwrt.pastebin.com/m237005f1 Jan 28 17:56:34 [florian]: the gpio.c file should be deleted Jan 28 17:56:34 [florian]: I suppose we could, but it could get unwieldy pretty quickly...and we'd be constantly having to update that database Jan 28 17:57:16 <[florian]> cshore: exactly Jan 28 17:57:41 AlexanderS: ping Jan 28 17:57:43 <[florian]> rtz: a couple of comments Jan 28 17:57:48 rtz: pong Jan 28 17:58:06 AlexanderS: the phy driver stuff I gave you, did you try it? Jan 28 17:58:24 [florian]: and the phy stuff: http://www.file-upload.net/download-2204831/phy4.tar.html Jan 28 17:58:27 <[florian]> rtz: I do not think we can mainline your southrbridge module as is, we would have to split it into 3 parts Jan 28 17:58:49 [florian]: it's very incomplete, but one can see, how it's supposed to work Jan 28 17:58:57 <[florian]> rtz: the southrbridge module should match on the southbridge pci device id, then register as platform devices a separate watchdog and gpiolib driver Jan 28 17:59:20 <[florian]> rtz: I do not think the linux kernel allows you to have two modules matching on the same pci id, but if can, even better Jan 28 17:59:55 <[florian]> rtz: about target/linux/rdc/files-2.6.30/arch/x86/mach-rdc321x/platform.c Jan 28 18:00:18 <[florian]> it will break the other platforms, so, we should register the leds and buttons by matching on the RDC CPU identifier (if possible) Jan 28 18:00:45 [florian]: why will it break other platforms? Jan 28 18:01:08 <[florian]> rtz: well, I meant models, for instance ar525w has a different gpio mapping Jan 28 18:01:40 [florian]: it doesn't mess with the gpio mapping Jan 28 18:01:43 rtz: no, i had no time yet... Jan 28 18:02:09 <[florian]> rtz: oh you are right, sorry about that Jan 28 18:02:11 [florian]: it creates only the gpio device itself, and the access registers should be the same for all rdc devices Jan 28 18:02:23 <[florian]> rtz: you misunderstood me I think Jan 28 18:02:30 maybe Jan 28 18:02:33 <[florian]> rtz: I mean that any change to platform.c is model-specific Jan 28 18:02:43 <[florian]> rtz: for sure the gpio driver will work on any rdc321x device, we agree o nthat Jan 28 18:04:17 [florian]: I'm not sure, how to do this in a good way Jan 28 18:04:32 <[florian]> rtz: distinguishing between models? Jan 28 18:04:37 <[florian]> rtz: that's a tricky part Jan 28 18:04:47 splitting of platform.c in different files, would probably be the best idea Jan 28 18:05:12 <[florian]> rtz: that helps, but ideally we would like to detect devices dynamically and provide a single kernel Jan 28 18:05:23 <[florian]> rtz: anyway, that's not the most important part imho Jan 28 18:05:46 [florian]: ok, back to the pci driver Jan 28 18:05:55 [florian]: what exactly is to do there? Jan 28 18:06:14 <[florian]> rtz: the best would be to split the gpio driver and the watchdog driver and make both match on the same pci id Jan 28 18:06:53 <[florian]> rtz: which I need to check when I am back home Jan 28 18:07:13 [florian]: they would still need to access the same pci device Jan 28 18:07:34 [florian]: and there can only be one driver per device Jan 28 18:07:59 <[florian]> oh that's right, I forgot about this Jan 28 18:08:14 [florian]: by the way, the comment in line 151 of the patch is crap, it's about 1.45 seconds delay Jan 28 18:08:18 <[florian]> rtz: wait, they both access the pci config register Jan 28 18:09:00 [florian]: yes, but they have different registers Jan 28 18:09:22 in the pci config area of the south bridge Jan 28 18:09:24 <[florian]> rtz: if they use different bar's that's fine Jan 28 18:09:38 <[florian]> rtz: well but that would only work if they did not use the config space Jan 28 18:09:46 <[florian]> this rdc design sounds fishy Jan 28 18:09:46 [florian]: they don't use bars afaik, the use the pci config space Jan 28 18:10:21 well, I'm no expert on pci devices, but i don't see a problem with that Jan 28 18:10:50 <[florian]> rtz: it's not a problem, it's just some bad design, that's the purpose of bars, not config space to driver gpios for instance Jan 28 18:11:20 <[florian]> I go back home, see you from there with a device to test ;) Jan 28 18:11:40 I will be gone for about an hour or so Jan 28 18:12:39 ping nbd Jan 28 18:12:40 hi Jan 28 18:12:44 hi cshore Jan 28 18:12:54 puchu: hi Jan 28 18:13:07 it seems no one wants to commit the init fix for brcm[2.4,47xx] Jan 28 18:13:18 puchu: probably just busy Jan 28 18:13:51 cshore it sometimes takes wwek until some commits make it into trunk Jan 28 18:13:57 wwek=weeks Jan 28 18:18:36 puchu: ping me in about 6 hours if nobody commits it Jan 28 18:19:07 thepeople in 6 hours ill be in bed .. but i can ping u tommorow if nobody commits it Jan 28 18:19:12 thepeople: thanks Jan 28 18:24:01 puchu: pong Jan 28 18:24:47 nbd could u please commit my openssl fix for ubsec_ssb and i also found a failure in preinit for brcm47xx,brcm2.4 Jan 28 18:25:13 will take care of it in a few minutes Jan 28 18:25:19 okay thanks Jan 28 18:25:25 gotta make some tea first ;) Jan 28 18:25:34 is there somehow a way to get commit access to the tree Jan 28 18:25:44 what or how much fixes do i have to do to get it? Jan 28 18:26:02 @mbd Jan 28 18:26:06 nbd Jan 28 18:28:47 tea? oO Jan 28 18:29:03 * cshore likes this idea Jan 28 18:29:22 jow_laptop: yeah, i'm not that much into coffee Jan 28 18:33:00 puchu: other members of the team think we shouldn't give out full commit access to many people anymore. we're trying to get more people to become maintainers for specific packages instead Jan 28 18:34:43 nbd so i wont get access ever because i do fixes for progs i use Jan 28 18:36:26 puchu: I don't think that is the intent Jan 28 18:38:26 juhosg * r19363 /trunk/target/linux/generic-2.6/config-2.6.32: kernel: add missing config symbols for 2.6.32 Jan 28 18:38:29 juhosg * r19364 /trunk/package/kernel/modules/video.mk: package/modules: add missing gspca video drivers for 2.6.32 (patch from #6595) Jan 28 18:38:33 more of we want people to maintain packages, but not maintain the whole tree Jan 28 18:39:20 becuase it would help free up people that have been maintaining the tree Jan 28 18:39:21 thepeople: i know what u mean and if someone is doing good at this maybe he/she gets access to more Jan 28 18:40:08 thepeople: yeah but it would make no sense for me to test patches for other people that commit tickets ... because i cant even commit them so it makes no sense at all to do this Jan 28 18:40:20 so im just updating/fixing things i use Jan 28 18:40:40 it does help if you test them, becuase we don't always see issues Jan 28 18:41:58 thepeople: i know what u mean .. but its like .. do u do things when no one ever credits you for this? u do it - an other person "earns" the credit for it .. although its your work ... it not ment in a monetary way Jan 28 18:42:03 its more like a motivation thing Jan 28 18:42:26 I understand what you are saying, it is a hard thing to do Jan 28 18:43:37 when someone says .. u are responsible for this ... i will take responsebility for it ... but begging for commiting fixes is not what im searching for .. i dont mean it for bad Jan 28 18:45:30 <[florian]> rtz: I am back Jan 28 18:45:36 yea, having to beg for commits is bad, it is one of the things we are really bad at, a lot of patches sit there with no response Jan 28 18:48:36 maybe we need somebody in charge of keeping track of the mailing list, merging obvious patches and bugging the right people for reviewing the non-obvious ones Jan 28 18:48:46 puchu: that is why I was saying ping me in 6 hours then I would be able to commit your fix :-) (but I have a bad memore just remembering patches at times) Jan 28 18:48:47 thepeople it doesnt matter for me because i fixed it ... but for people just using openwrt ... knowing nothing about c/bash or things like that ... its not that easy to find out why its not working ... so they have to wait/use exploitable versions (ex. openssl) until someone commits allready done patches ... Jan 28 18:49:01 nbd: I agree Jan 28 18:49:35 thepeople: that's how it usually works with subsystem maintainers for specific kernel trees Jan 28 18:49:37 nbd: actually likely 2-3 people would be best Jan 28 18:49:37 e.g. with the wireless tree Jan 28 18:49:42 yes Jan 28 18:50:01 if we have somebody keeping track of that, we probably don't need many more people with commit access Jan 28 18:50:31