**** BEGIN LOGGING AT Fri Jun 04 02:59:57 2010 Jun 04 03:37:56 nico * r21669 /packages/net/ptpd/Makefile: [packages] ptpd: fix initscript file name, fix description, add copyright header, bump release number Jun 04 07:02:19 obsy * r21670 /packages/net/transmission/ (Makefile patches/): [packages] transmission: update to 2.00b2, prevent linking host libevent Jun 04 08:11:35 hello Jun 04 09:13:23 ping rtz2 Jun 04 09:15:36 jow_laptop: pong Jun 04 09:17:46 rtz2: nbd told me you digged out an upstream commit to cure the mmap weirdness on ar71xx. Can you provide me with a link? Jun 04 09:19:40 jow_laptop: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2d4dc890b5c8fabd818a8586607e6843c4375e62 Jun 04 09:19:52 jow_laptop: it's needed on .32 and .33 Jun 04 09:20:02 jow_laptop: for all platforms, not only ar71xx Jun 04 09:20:20 jow_laptop: also, the patch applies cleanly, no need to modify it Jun 04 09:21:50 rtz2: any plans on integrating it yet? Jun 04 09:21:53 thx btw. Jun 04 09:22:41 jow_laptop: I have a patch to add it somewhere, but it's probably not worth the effort Jun 04 09:23:10 jow_laptop: simply copy ti to generic-2.6/patches*/ and give it a nice name Jun 04 09:23:57 jow_laptop: I can send you the svn patch, if you want Jun 04 09:24:42 jow_laptop: actually, it's needed on anything lower then .34 Jun 04 09:32:20 allright Jun 04 09:38:10 jow_laptop: allright I should send it, or allright you don't need it? Jun 04 09:38:25 I can manage from here Jun 04 09:39:19 jow_laptop: ok, thanks Jun 04 10:36:51 cshore: are you here? Jun 04 13:55:22 cshore wake up! Jun 04 17:23:02 mb__1: ping Jun 04 17:23:48 rtz2: pong Jun 04 17:24:15 mb__1: could I interest you in reviewing and commiting a small brcm47xx patch? Jun 04 17:24:28 mb__1: it's not even in patch-patch from ;) Jun 04 17:25:18 as long as it's a plain diff, yeah :) Jun 04 17:25:26 Just send me some mail Jun 04 17:25:36 mb__1: it's on openwrt-devel Jun 04 17:25:38 one moment Jun 04 17:25:50 Ok, I just deleted the history :) Jun 04 17:26:29 mb__1: Provide SPROM for WRT54G3GV2 Jun 04 17:26:32 hmm Jun 04 17:26:41 I migrated to a new mailserver and I just deleted all crap to start over with a clean mailbox Jun 04 17:27:14 mb__1: https://lists.openwrt.org/pipermail/openwrt-devel/2010-May/007222.html Jun 04 17:27:29 mb__1: I can also mail it again Jun 04 17:28:37 rtz2: Why do you need a fallback sprom for a PCI device? Jun 04 17:29:13 mb__1: this thing has a mini-pci wireless crard Jun 04 17:29:16 card Jun 04 17:29:30 without a sprom Jun 04 17:29:58 mb__1: the mac address and config settings are stored in normal nvram with the pci/1/1 preifx Jun 04 17:30:02 I doubt that Jun 04 17:30:34 This would be the first PCI card without an SPROM. Jun 04 17:31:34 mb__1: well, what's the purpose of the ssb_arch_set_fallback_sprom function then? Jun 04 17:31:58 bcm63 Jun 04 17:32:25 It really is an awful hack for a braindead hardware. Jun 04 17:33:26 I can't really say much about that patch anyway. I don't have those devices, so I can't even test it. Jun 04 17:33:52 So if you think it is needed, commit it. I don't know. Jun 04 17:36:44 mb__1: well, I know it's needed Jun 04 17:37:04 mb__1: I had somebody here with this hardware, I wrote this patch for him Jun 04 17:37:20 mb__1: the driver complained about a missing sparom Jun 04 17:37:22 sprom Jun 04 17:37:29 We had some PCI devices in the past where we thought there was no SPROM. But in fact it turned out there was one, just in a different location. Jun 04 17:37:33 mb__1: I don't have svn write access to trunk Jun 04 17:44:58 mb__1: well, all wireless config variables including mac address seem to be in nvram Jun 04 17:46:21 Ok, well. I don't commit this patch, however, as I don't know the device and have no way to verify its correctness. Jun 04 17:47:24 mb__1: the card is connected via pci but not in a mini-pci slot Jun 04 17:47:32 mb__1: so, what should i do now? Jun 04 17:48:14 mb__1: none of the developers seems to have such a device Jun 04 17:48:45 I don't know. Maybe somebody else will commit it. Jun 04 17:49:21 mb__1: the wireless is in the upper right corner of the pcb: http://wiki.openwrt.org/toh/linksys/wrt54g3gv2-vf Jun 04 17:49:29 mb__1: nice :/ Jun 04 17:50:29 What's the card slot for? Jun 04 17:51:30 mb__1: pcmcia Jun 04 17:51:37 Yeah what's connected? Jun 04 17:51:45 mb__1: an umts modem Jun 04 17:52:01 mb__1: hence ...3g ;) Jun 04 17:52:16 ah, k Jun 04 17:56:28 nbd: ping Jun 04 17:57:32 pong Jun 04 17:58:46 nbd: could you take a look at this patch? Jun 04 17:58:54 https://lists.openwrt.org/pipermail/openwrt-devel/2010-May/007222.html Jun 04 18:02:30 i don't like the hardcoded prefix number Jun 04 18:02:51 how about this: Jun 04 18:03:41 as an early fixup for all pci devices on an ssb pci controller, check if nvram contains sprom data and set the parsed sprom as platform_data for the pci device Jun 04 18:03:50 that way you don't have to hardcode stuff Jun 04 18:12:09 nbd: Much better. I'd also prefer a solution that gets rid of the fallback function. The platform data stuff can also be used on bcm63 Jun 04 18:14:32 this doesn't map very well with the way the sprom is accessed at the moment Jun 04 18:16:01 or pretty much not at all Jun 04 18:17:06 why? Jun 04 18:17:26 If the platform data is present, just use it instead of fetching from MMIO Jun 04 18:18:16 hmm, right Jun 04 18:18:25 if I add it to the pci device Jun 04 18:18:26 hmmm Jun 04 18:18:32 I have to think about this Jun 04 18:19:10 You can possibly use the existing ssb_invariants structure for that. Jun 04 18:19:39 Just put that into platform data. Jun 04 18:21:29 I would actually commit a patch that removes the fallback interface. That's a thing I would agree with. Jun 04 18:23:25 The platform data could possibly registered via PCI fixup callback. That's probably cleaner than putting the 43xx knowledge into the SSB pcicore driver Jun 04 18:26:14 mb__1: I would simply change the ssb_pci_sprom_get function to get the sprom from platfrom_data instead of ssb_get_fallback_sprom() in case the the crc check fails Jun 04 18:26:27 mb__1: and add them via a pci fixup Jun 04 18:27:13 yeah Jun 04 18:27:40 I think that should work Jun 04 18:29:52 mb__1: ok, I will take a look at it Jun 04 18:29:54 hmmm Jun 04 18:30:39 but I think I will have to keep the hardcode pci/1/1/ prefix, because I have no clue, what exactly this means Jun 04 18:31:59 I think it's the bus/dev ID Jun 04 18:32:42 If that's the case, you should use it in the fixup to decide whether nvram data exists for the device Jun 04 18:34:54 mb__1: hmm, I'm not completly sure Jun 04 18:37:38 hey, there is even a bug for this Jun 04 18:37:40 https://dev.openwrt.org/ticket/7272 Jun 04 19:09:41 juhosg * r21671 /trunk/target/linux/adm5120/files/arch/mips/adm5120/common/platform.c: adm5120: fix build error on 2.6.34 Jun 04 19:09:45 juhosg * r21672 /trunk/target/linux/adm5120/ (6 files in 4 dirs): adm5120: don't use linux/autoconf.h Jun 04 19:09:49 juhosg * r21673 /trunk/target/linux/ (5 files in 5 dirs): generic: merge mips multi machine update to generic patches for 2.6.32 Jun 04 19:09:51 juhosg * r21674 /trunk/target/linux/ (4 files in 4 dirs): generic: merge mips multi machine update to generic patches for 2.6.33 Jun 04 19:09:54 juhosg * r21675 /trunk/target/linux/ (5 files in 4 dirs): generic: merge mips multi machine update to generic patches for 2.6.34 Jun 04 19:33:38 zioproto * r21676 /packages/net/olsrd/files/olsrd.init: Removing default values enforced but init script, this way OLSR will use its default values that are suggested by the developers. This change was committed within the Wireless Battle Mesh V3 meeting Jun 04 19:34:43 zioproto * r21677 /packages/net/olsrd/files/olsrd.config: Version 0.6.0 of OLSR allows the 0.0.0.0 setting for the plugin so any host can gather information Jun 04 19:39:00 zioproto * r21678 /packages/net/olsrd/Makefile: [packages] olsrd: Added maintainer to the Makefile **** ENDING LOGGING AT Sat Jun 05 02:59:57 2010