**** BEGIN LOGGING AT Fri Dec 14 03:00:01 2018 Dec 14 03:53:43 is there any documentation on "Compile with support for patented functionality"? Dec 14 04:10:24 biangbiangmian: try: git grep BUILD_PATENTED Dec 14 04:10:31 particularly in feeds Dec 14 04:16:59 thanks Dec 14 06:19:13 greearb__: do you happen to know the mtu limit of ath10k? Dec 14 06:19:34 I mean is there any firmware / driver imposed limit or is it just mac80211? Dec 14 06:38:12 found what I was looking for. linux/ieee80211.h: #define IEEE80211_MAX_DATA_LEN 2304 Dec 14 06:48:43 oh, EHCI has stopped working on bcm53xx Dec 14 06:48:46 [ 6.045431] bcm_ns_usb2 1800c000.usb2-phy: can't request region for resource [mem 0x1800c000-0x1800cfff] Dec 14 06:48:48 [ 6.054917] bcm_ns_usb2 1800c000.usb2-phy: Failed to map DMU regs Dec 14 08:26:54 phew... currently rebasing master on top of openwrt-18.06 locally here to simplify backporting stuff Dec 14 08:27:08 its interesting to see how fast and thorough tings have diverged :) Dec 14 08:31:26 seems like a lot of fun Dec 14 09:21:34 Hi if any one has 5 mins could some one pleas bump the mwlwifi driver to 10.3.8.0-20181210. https://github.com/kaloz/mwlwifi/commit/c1345bb1d84950da2651c9921c17b1dfe0f1fa30 Dec 14 09:22:05 stintel: ping Dec 14 09:22:30 I cant do it at the mo as I messed up my remote and don't know how to fix it. Dec 14 09:23:15 stintel: could you test the 4.9 kernel bump in my tree on bcm2708? ar71xx has diverged to much to keep backporting it for testing the bumps here :) Dec 14 09:30:36 *yawn* Dec 14 09:30:41 xback: on it Dec 14 09:32:01 i run into some weird problem with rebuilding modules Dec 14 09:32:38 xback: Expose irq internals in debugfs (GENERIC_IRQ_DEBUGFS) [N/y/?] (NEW) Dec 14 09:33:00 xback: apparently getting more questions for new symbols. looks weird Dec 14 09:33:26 PRINTK_SAFE_LOG_BUF_SHIFT POSIX_TIMERS PC104 SLAB_MERGE_DEFAULT SLAB_FREELIST_HARDENED ... Dec 14 09:33:37 wait a minute Dec 14 09:33:41 vim build_dir/target-*/linux-*/linux-*/drivers/phy/broadcom/phy-bcm-ns-usb2.c Dec 14 09:33:43 make V=s Dec 14 09:33:44 strings build_dir/target-*/linux-*/packages/.pkgdir/kmod-phy-bcm-ns-usb2/lib/modules/4.14.87/phy-bcm-ns-usb2.ko Dec 14 09:33:50 that .ko does not get updated Dec 14 09:34:27 but that shows updated module: Dec 14 09:34:29 strings build_dir/target-*/linux-*/linux-*/drivers/phy/broadcom/phy-bcm-ns-usb2.ko Dec 14 09:34:40 xback: disregard. maybe I need to get some coffee first :) Dec 14 09:34:41 jow: yeah :) I feel master is a _lot_ further from 18.06 than 1806 is from 17.01 Dec 14 09:40:02 blogic: Hi, please could you take a look at the following patch https://github.com/openwrt/openwrt/pull/1632/commits/9d8f7d52072352dd3ecb4a3c5067307903c48346 ? I'm wondering if you might have an idea what might cause differrent register settings after the boot on ar71xx Vs ath79, same hardware setup, same u-boot etc. Dec 14 09:44:22 got master rebased on top of openwrt-18.06 with some gentle force (skip all kernel bumps, skip anything ath79 related, skipt dropped targets Dec 14 09:45:12 will now refine it a bit, annotate the commits (backported from sha1) and then use it as source to pick stuff into 18.06 Dec 14 09:45:16 blogic: on ath79 the content of MAC cfg1, cfg2, mfl regs after the reset/boot looks like the ag71xx_hw_setup was run two times (but it actualy wasn't) and I'm wondering what might cause this, I'm thinking about it for a few days already, but couldn't simply find the explanation for this different kernel behaviour Dec 14 09:45:36 result can be seen at https://git.openwrt.org/?p=openwrt/staging/jow.git;a=shortlog;h=refs/heads/backport-18.06 Dec 14 09:45:57 ynezz: hmmm Dec 14 09:46:05 different reset order of the drivers ? Dec 14 09:46:17 blogic: maybe it helps, here's full dmesg from ath79 http://paste.ubuntu.com/p/2YyYDPWmtX/ and from ar71xx http://paste.ubuntu.com/p/gvY7SnK8dG/ Dec 14 09:46:30 well, see we changed the gmac config in ath79 Dec 14 09:46:34 so it is its own driver Dec 14 09:46:41 and maybe the probe/reset order has changed Dec 14 09:47:08 so the gmac will setup the register and then later a reset happens in a different driver that implicitly resets the registers Dec 14 09:49:02 yes I was thinking about that also, so I've added pr_info and dump_stack before the reset/probe parts, and it seems to be called in the similar order, I couldn't find the difference between ar71xx/ath79 Dec 14 09:52:46 ynezz: i think i found something Dec 14 09:52:52 SoC: Atheros AR9342 rev 2 Dec 14 09:53:04 ar71xx will set pdata->is_ar724x = 1; Dec 14 09:53:18 and ag71xx in ar71xx inside hw_init does some extra reset logic Dec 14 09:53:26 which the ath79 driver does not do Dec 14 09:53:28 this part doesn't have impact on this, I've commented it out Dec 14 09:53:35 :-) Dec 14 09:53:36 ok Dec 14 09:54:16 I was suspecting that one also, but no luck either :) Dec 14 09:55:25 the only other difference is ee is that ar71xx will do the reset_bit mask inside dev-eth.c Dec 14 09:55:34 and flip them all at the same time Dec 14 09:55:48 and with at79 we flip the singular in possible a different order Dec 14 09:56:02 dev-eth.c will for example flip all of them once after platform_register Dec 14 09:56:15 and ath79/ag71xx will only flip the mac bit during boot Dec 14 09:57:04 thanks, I'll look into that Dec 14 09:57:36 try to flip all the bits taht dev-eth.c would flip for the board early inside the probe of ag71xx Dec 14 09:57:43 or simply not flip them inside ar71xx Dec 14 11:07:28 ok, that modules building issue seems to be a regression between 17.01 and 18.06 Dec 14 11:09:02 blogic: yep, that's it :) Dec 14 11:10:42 but it's needed to reset both bits (GMAC0 and MDIO) together otherwise the reset doesn't work, I've removed the MDIO from the reset_bits in ar71xx and the regs werent reset Dec 14 11:11:52 jow: how much of master you planning on backporting to 18.06? it sound slike "all of it" ? Dec 14 11:14:06 karlp: I did the rebase to figure that out Dec 14 11:14:17 the huge deviations make git cherry & friends mostly useless Dec 14 11:14:29 xback: Linux OpenWrt 4.9.145 #0 Fri Dec 14 09:37:13 2018 armv6l GNU/Linux Dec 14 11:14:48 I do not plain to backport everything, I'll probably focus on core package updates and obvious fixes Dec 14 11:14:59 for mac80211, ath10k, mt76 etc. bumps I'll need input from the others Dec 14 11:15:16 goodo, given how many changes there were, I didn't really feel like, "backport all the things" was going to be a great idea. Dec 14 11:24:11 which is going to be the next release kernel? Dec 14 11:24:14 4.19? Dec 14 11:26:30 <_lore_> hi, if I compile with 'Compile the kernel with debug information', is a kernel pkg stripped? Dec 14 11:27:27 thagabe: 4.14 Dec 14 11:27:41 Ops i mean after 4.14 Dec 14 11:28:09 whever is current by then, probably 4.19 Dec 14 11:28:31 but I guess by then people are already waiting for 4.24 because it has the latest fancy features Dec 14 11:29:06 jokes aside, probably 4.19 Dec 14 11:51:14 ynezz: which means my commit https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=83d2dbc59924c90dd865de113a55d60826ac0c04 is wrong :( Dec 14 11:57:06 stintel: thanks a lot :). that's bcm2708? Dec 14 11:58:00 xback: ack Dec 14 11:58:46 xback: I can do bcm2710 too if you want (aarch64) Dec 14 11:59:33 stintel: it's not required afaict as no symbol changes were done or any otter critical changes. it was a fairly light bump Dec 14 11:59:59 xback: ok Dec 14 12:00:38 stintel: mind if I add your tested-by in the patch? Dec 14 12:00:45 xback: please do :) Dec 14 12:02:30 pushed to master Dec 14 12:08:30 gch981213: No, it's good, it just need to be adjusted little bit Dec 14 12:12:04 * russell-- wonders if it would be easier to try to track upstream most-recent-kernel (as a build option, not default) to spread pain out over time, than to wait and try to do big leaps all at once Dec 14 12:21:38 ynezz: My commit made mdio register before eth. If we need to move the reset from mdio to eth, we have to delay mdio init after the eth otherwise the initialized mdio register values will be resetted. Dec 14 12:22:58 we could apply this "hack" to all chips (and it won't look so hacky if we do so :) ) https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=f43e8f90049fbbf7961854660c09e88fb7555ef2 But we then need to find a way to delay eth1 initialization after eth0. Dec 14 12:23:41 and we need to swap eth1/eth0 for all routers using builtin switch. Dec 14 12:24:30 gch981213: Aha, you're alive Dec 14 12:25:35 gch981213: Thanks for finding the one datasheet with a clue on MT7628 Dec 14 12:27:32 It's actually pointed out by russell-- :-D Dec 14 12:27:42 Well then, thanks russell-- too Dec 14 12:27:43 * russell-- waves Dec 14 12:28:13 yay random datasheets Dec 14 12:28:30 russell--: It's the datasheet lottery with these people Dec 14 12:28:36 Speaking of which Dec 14 12:28:45 blogic: Did you enter my numbers into the MT7628N lottery? :) Dec 14 12:30:37 btw, i've been asked to ask if, by some miracle, there might be a mode where uart1 on mt76x8 shows up on different pads, not described in the datasheet(s) Dec 14 12:31:03 because, if so, that would be handy in our particular application Dec 14 12:31:24 I'm guessing not Dec 14 12:32:08 me too, but this mapping SD pins elsewhere gives a certain, distant hope Dec 14 12:33:15 It could be interesting to see if setting that bit changes any secret registers elsewhere Dec 14 12:34:19 I'm about 3800 miles from my boards though Dec 14 12:43:18 gch981213: the main problem in Nanostation M XW case was, that the GMAC registers were not reset in ag71xx_probe before setting up the GMAC Dec 14 12:44:22 it seems so far to me, that we need to reset both bits (GMAC0 and MDIO0) at once together to get the GMAC0 regs into reset state Dec 14 12:44:35 as it's being done in ar71xx now Dec 14 12:45:47 in `ar71xx` in `ath79_register_eth()` we use `pdata->reset_bit = AR934X_RESET_GE0_MAC | AR934X_RESET_GE0_MDIO;` Dec 14 12:46:07 in ath79 we just use AR934X_RESET_GE0_MAC bit separately Dec 14 12:46:40 if I change `pdata->reset_bit = AR934X_RESET_GE0_MAC` in ar71xx, the regs aren't reset to default state either Dec 14 12:48:00 so we probably just need to do the same in ath79 as well, drop the mdio_reset and move that into mac_reset (array of two reset bits) Dec 14 12:49:17 my work in progress patch http://paste.ubuntu.com/p/BWYHkDqxjm/ Dec 14 12:51:03 ynezz: That's what I said: we'll ended up reset mdio after mdio is initialized Dec 14 12:52:07 no Dec 14 12:52:46 at least not in the probe, as the reset seems to happen before of_platform_device_create(mdio_node, NULL, NULL); Dec 14 12:53:32 ynezz: That happens only if eth0/eth1 isn't a "simple-mfd" Dec 14 12:53:49 ah Dec 14 12:54:05 I set them to "simple-mfd" for ar7241/later chips so that I can probe mdio before eth Dec 14 12:54:41 because on routers with only one FE ports we need mdio1/eth0 only. Dec 14 12:55:00 jow, I've seen reports of being unable to receive larger MTU frames in ath10k, but never dug into it in detail Dec 14 12:56:04 we need mdio1 for getting phy status from builtin switch but we don't need mdio0/eth1. Dec 14 12:57:03 ok, so what about moving the reset of gmac to mdio instead? Dec 14 12:58:25 well, it seems like you've much better understanding of that code then I do, so I'm wondering if you could fix it :) I'm more then happy to help testing it Dec 14 13:06:54 ynezz: I think moving them to mdio works (If we only apply them for ar7241 and later chips.) but I'd prefer having them in eth driver and change the probing order somehow. I'm a little bit busy these days and I could do it when I have some free time, probably two or three weeks later :) Dec 14 13:07:30 no problem, I don't need that fix, I don't have that device anyway :) Dec 14 13:08:26 I'm just not happy with my current fix I've proposed in the PR as it seems more like a hack, then a proper solution Dec 14 13:14:00 rmilecki: i just nudged derRichard about the ubifs bug patch getting merged upstream, said he's going to send it to linus this weekend Dec 14 13:14:35 russell--: oh my, I thought it's already there! Dec 14 13:14:39 thanks for pinging him! Dec 14 13:15:02 it's in his -next tree Dec 14 13:26:37 gch981213: hm, even with the both GMAC0 and MDIO0 reset bits set, the GMAC0 still doesn't have the regs set to their reset values in ag71xx_probe Dec 14 13:30:35 nbd: ping Dec 14 13:30:42 nbd: regarding https://bugs.openwrt.org/index.php?do=details&task_id=1946&string=qmi&search_name=&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= Dec 14 13:31:16 nbd: I check the souce code and indeed this does nothing. Can it be omitted? I would remove it from qmi.sh to start Dec 14 13:33:22 heh, I wonder if google translate got this right: Killing chicken with a knife? The knives are out, and when they seek the "knife" to go slant. It is the accumulation of time and the whimsy of the heart. Dec 14 13:38:52 xback: i think there's simply a bug there and it should return QMI_CMD_REQUEST Dec 14 13:39:27 not sure which qmi devices need wda-set-data-format and which ones handle it through ctl Dec 14 13:41:09 and the mode needs to be passed too Dec 14 14:04:59 nbd: please check my mail. It should be fixed within minutes then. Thanks Dec 14 14:05:26 dedeckeh: ping Dec 14 14:20:33 if anyone dnsmasq aware, could they take a look at https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=bc3cb6ecd9a0c171ceac62af711084e1e825f91f Dec 14 14:24:07 That's about 3 bugs in 3 days courtesy openwrt testing on a dnsmasq tree that's been the same for over a month - we have a wide range of use cases out there :-) Dec 14 14:25:32 Hi jow you can back port the driver for mwlwifi to Dec 14 14:29:41 ynezz: How did you reset them? I've just done some quick test on my ar9344 router. both reset needs to be asserted before deasserting them. e.g. we can: assert gmac -> assert mdio -> deassert gmac -> deassert mdio. But this won't work: assert gmac-> deassert gmac -> assert mdio -> deassert mdio. Dec 14 14:29:52 the mwlwifi driver that is in master has bin working grate for a wile now. Dec 14 14:45:39 gch981213: I've added both bits to the mac_reset `resets = <&rst 9>, <&rst 22>;` Dec 14 14:46:28 this made me chuckle https://www.theregister.co.uk/2018/12/14/microsoft_windows_95_christmas_jumper/ especially the idea of the Apple jumper. Dec 14 14:48:33 BTW, how do you verify that it works? Do you've reset value of MAC_CFG2 register set to 0x7000, as in `mac_cfg2=00007000` before calling ag71xx_hw_setup ? Dec 14 14:59:02 ldir:pong Dec 14 15:01:22 ynezz: I mean how did you wrote the reset in driver code? Just adding them in dts isn't enough. Dec 14 15:01:34 ynezz: Here's how I did it: https://paste.ubuntu.com/p/WvzGD83xR4/ Dec 14 15:02:08 I directly wrote registers in U-boot command line. Dec 14 15:06:09 in ag71xx_hw_init() there is `reset_control_assert(ag->mac_reset); msleep(100); reset_control_assert(ag->mac_reset); msleep(200);` Dec 14 15:06:13 dedeckeh: ^^^ the dnsmasq fix above Dec 14 15:06:53 err, in ag71xx_hw_init() there is `reset_control_assert(ag->mac_reset); msleep(100); reset_control_deassert(ag->mac_reset); msleep(200);` Dec 14 15:07:26 and it supports arrays of bits, so this `resets = <&rst 9>, <&rst 22>;` should work as well right? Dec 14 15:07:58 ldir:will have a look; but it won't be today anymore Dec 14 15:08:24 np :-) Dec 14 15:09:17 AR934X_RESET_GE0_MAC=BIT(9), AR934X_RESET_GE0_MDIO=BIT(22) Dec 14 15:09:46 ynezz: Did you notice this? :) ag->mac_reset = devm_reset_control_get(&pdev->dev, "mac"); Dec 14 15:10:26 yes Dec 14 15:10:38 what's wrong with that? Dec 14 15:10:52 You need to define a mdio_reset in struct ag71xx and add ag->mdio_reset = devm_reset_control_get(&pdev->dev, "mdio"); Dec 14 15:11:00 no Dec 14 15:11:10 and assert both resets separatedly Dec 14 15:11:22 I can just change the DTS as well Dec 14 15:12:53 arrays of bits are supported, currently there's `resets = <&rst 9>;` defined for eth0, so I've changed it to `resets = <&rst 9>, <&rst 22>;` Dec 14 15:13:05 and removed that reset from mdio Dec 14 15:13:30 here is the reset for array of bits https://elixir.bootlin.com/linux/v4.14.88/source/drivers/reset/core.c#L169 Dec 14 15:17:07 so by having `resets = <&rst 9>, <&rst 22>;` defined in eth0 node in DTS, it should be almost the same as we've now in the ar71xx code `pdata->reset_bit = AR934X_RESET_GE0_MDIO | AR933X_RESET_GE0_MDIO;` Dec 14 15:18:56 Ah. I didn't know there is such an API available Dec 14 15:19:34 me neither, I did it with separate resets first, then found it out Dec 14 16:41:19 ynezz: I'm wondering whether you've replaced devm_reset_control_get with devm_reset_control_array_get :) Dec 14 16:44:29 This is really an annoying problem. We have ag71xx_fast_reset asserting mac reset only. If it works why the register values aren't reset? If it doesn't work without asserting mdio reset together why is there such a piece of code? I'll try to figure out what's done in atheros SDK (The linux SDK, not the openwrt one.) when I'm free. Dec 14 16:44:55 yes, I've found about that one too :) Dec 14 16:45:46 I need help with some kernel stuff Dec 14 16:46:17 gch981213: it works with devm_reset_control_array_get: eth%d: mac_cfg1=80000000, mac_cfg2=00007000, ipg=40605060, hdx=00a1f037, mfl=00000600 Dec 14 16:46:43 scripts/kconfig/conf --silentoldconfig Kconfig net/sched/Kconfig:44: warning: menuconfig statement without prompt * * Restart config... * * * MultiProtocol Label Switching * MultiProtocol Label Switching (MPLS) [Y/?] y MPLS: GSO support (NET_MPLS_GSO) [M/y/?] m MPLS: routing support (MPLS_ROUTING) [N/m/y/?] (NEW) aborted! Console input/output is redirected. Run 'make oldconfig' to update configuration. scripts/kconfig/Make Dec 14 16:47:01 gch981213: `ag->mac_reset = devm_reset_control_array_get_exclusive(&pdev->dev);` actually Dec 14 20:44:13 Howdy folks. Whats the earliest version of openwrt that supported a 2.7 version of Python? Dec 14 20:44:37 I've got a vendor supplied SDK for a device that's based on Backfire and only has 2.6 Dec 14 20:44:48 Was hoping I could massage an early 2.7 package to work in that older SDK. Dec 14 20:54:12 It's like 8 years old already! Dec 14 22:15:46 hey :) Dec 14 22:16:30 is it posible to get the builder to update the program faster than the git ? like a program that scanns for update for it ? Dec 14 22:17:52 (yes i know the patches will probably fail, and the build will probably be not as godt as orginal becuse of the missing patches .. but it kind of sux having super old shit in a firmware to) Dec 14 22:32:43 Zorgx: no, the buildsystem isn't built for that Dec 14 22:35:07 to bad .. it sux trying to update it my self.. xD and i can just forget the patches xD Dec 14 23:06:39 me need help Dec 14 23:06:46 checking for getrandom... no checking for getentropy... no checking for NETTLE... no configure: error: *** *** Libnettle 3.4 was not found. Dec 15 01:47:01 sigh Dec 15 01:47:23 it would be really nice if ncm support worked more than once ouf of 5 **** ENDING LOGGING AT Sat Dec 15 02:59:58 2018