**** BEGIN LOGGING AT Tue Apr 16 02:59:57 2019 Apr 16 03:22:59 <{Nico}> 5~5~ Apr 16 05:22:35 Slimey: `needs reviewer` tag means, that this PR needs reviewer, in other words it means, that I've (or someone else) already looked at that PR, but I'm not going to merge it or consider to review it for some reason, usually I don't have enough knowledge in that area of the tree to decide if it should go in or not Apr 16 05:22:59 Slimey: in that particular case it's because it's ar71xx, longer explanation here http://lists.infradead.org/pipermail/openwrt-devel/2019-April/016679.html Apr 16 05:46:06 nyt: is this one of the openwrt patches causing this? If so we should simply drop it Apr 16 08:17:21 _lore_, nbd: I'm wondering if you could've an idea how to handle the cases where `mediatek,mtd-eeprom` couldn't be used on devices which have MAC addresses stored in eeprom as ascii text like for example this router https://github.com/openwrt/openwrt/pull/1448#issuecomment-442476695 Apr 16 08:21:26 or do you think, that it would be better to bring this topic on the linux-wireless mailing list? Apr 16 09:02:30 blogic: what is the status of this target/linux/generic/pending-4.19/681-NET-add-of_get_mac_address_mtd.patch patch in upstream? I can't find any discussion about it Apr 16 09:08:08 ynezz: mind doing a review on a commit in my staging tree that adds support for a new ath79 device ? Apr 16 09:08:18 sure Apr 16 09:08:43 https://git.openwrt.org/25ef61db Apr 16 09:09:05 wow, didn't know about this nice URL option Apr 16 09:09:10 now you do ;) Apr 16 09:09:40 oh, common, why this license? :) Apr 16 09:10:45 honestly I based it on target/linux/ath79/dts/ar9342_ubnt_nanobeam-ac.dts Apr 16 09:11:35 ah, should be exactly "GPL-2.0-or-later OR MIT" ? Apr 16 09:12:21 https://openwrt.org/submitting-patches#dts_checklist Apr 16 09:12:28 yeah, I was just looking at that Apr 16 09:13:07 about the LEDs, I couldn't find any GPIO line that changed any LED status Apr 16 09:13:17 but could be GPL-2.0 OR MIT I think as well Apr 16 09:14:09 does it mean target/linux/ath79/dts/ar9342_ubnt_nanobeam-ac.dts should be changed as well (contact the author about it?) Apr 16 09:15:10 no, he refused to change it, I've already tried that https://github.com/openwrt/openwrt/pull/1733#discussion_r246310625 Apr 16 09:16:01 for the LEDs your best bet is poking in vendor system Apr 16 09:17:06 or take a look at PCB traces, where the LEDs might be possibly connected Apr 16 09:17:57 and as you don't have the hardware description in the commit message yet, I don't know about which LEDs are you talking about Apr 16 09:18:47 BTW how did you get that pll-data value? Apr 16 09:21:00 it's the same as ar9342_ubnt_nanobeam-ac.dts Apr 16 09:22:09 there's a forum thread about this device that mentions packet loss on the ethernet interface. started from the same values as the nanobeam ac and did not notice any packet loss so I figured it'd be good Apr 16 09:22:55 still worth at the value of the registers with io/devmem in vendor system Apr 16 09:25:00 I'll power up my other unit when I find some time and do some poking Apr 16 09:25:04 thanks for the feedback Apr 16 09:33:33 jow, yes, but it short circuits some code that prob improveshroughput on lower power devices Apr 16 09:38:00 which won't be useable with kernel 4.19 anyway Apr 16 09:38:34 people want 4.19, so they shall receive it in all its bloaty glory Apr 16 09:44:20 stintel: that's devmem which should probably work under some versions of AirOS http://ynezz.true.cz/temp/devmem2-airos Apr 16 10:31:35 ynezz: its not upstream Apr 16 10:31:49 so from the holy book of how to waste time Apr 16 10:31:50 ... Apr 16 10:31:51 if (!nla_get_flag(tb_iftypes[NL80211_IFTYPE_AP])); Apr 16 10:31:52 return NL_OK; Apr 16 10:31:59 ... :-) Apr 16 10:32:04 took me 10 minutes Apr 16 10:34:40 blogic: ah, so that's probably missunderstanding on my side, as I've thought, that patches in pending dir have been sent upstream Apr 16 10:35:32 hack -> pending -> upstream -> backport Apr 16 11:09:25 blogic: anyway, from your point of view, how to handle properly the cases where `mediatek,mtd-eeprom` couldn't be used on devices which have MAC addresses stored in eeprom as ascii text like for example this router https://github.com/openwrt/openwrt/pull/1448#issuecomment-442476695 ? Apr 16 11:24:40 blogic: to me it seems like the solution could be `mtd-mac-address` extended to support the MAC stored in ascii text form, probably `mtd-mac-address-ascii` (or similar acceptable DT solution) Apr 16 12:03:30 ynezz: yes Apr 16 12:03:41 ynezz: pending means should go upstream but might need cleanup Apr 16 13:38:38 How does it look for OpenWrt 18.06.03 which was wanted to be released soon? Apr 16 13:40:28 and still it sits there https://lore.kernel.org/netdev/20190409113315.64132-1-ldir@darbyshire-bryant.me.uk/ sigh Apr 16 13:41:04 ynezz i see Apr 16 13:42:25 and the savedscp bit - deep sigh https://lore.kernel.org/netfilter-devel/20190409142333.68403-1-ldir@darbyshire-bryant.me.uk/ Apr 16 14:51:52 blogic: any objections https://github.com/ynezz/linux/commit/5fd24d765547e8337c30757fbccb3728fd0068ee ? (I'll split the Documentation to the separate commit) Apr 16 14:52:37 the diff http://paste.ubuntu.com/p/JqSMTnFf6j/ Apr 16 16:16:26 whhy should the docs go in a separate commit? Apr 16 16:17:00 checkpatch told me so :) Apr 16 16:17:32 WARNING: DT binding docs and includes should be a separate patch. See: Documentation/devicetree/bindings/submitting-patches.txt Apr 16 16:26:18 fair enough. rules are rules then I guess. Apr 16 18:01:23 jow: *shrug* still works fine with patch 613 modified as per the small patch i pasted Apr 16 19:32:11 jow: several patches were submitted after 4.19 that slim down MIPS without floating point a little bit. Apr 16 19:32:53 should probably be backported Apr 16 19:39:32 ynezz: thanks for picking it up Apr 16 19:43:43 guys is there anything to be said for just cherry-picking the master hostapd patches into 18.06? Apr 16 19:44:02 or is that just plain silly given they're running different git snapshots (the 18.06 one being from 2018-05) Apr 16 19:56:45 just asking because just backporting and fixing up the hostapd package Makefile seems to work (maybe a bit too easy) Apr 16 20:01:37 karlp: well, probably the tools are too noisy, there is already a lot of commits which change code and documentation in one commit **** ENDING LOGGING AT Wed Apr 17 02:59:57 2019