**** BEGIN LOGGING AT Wed Mar 11 03:02:27 2020
Mar 11 03:19:21 <mangix> swalker: I doubt they will.
Mar 11 03:19:54 <mangix> also turns out faad2 went to github. and the CVE ID is wrong...
Mar 11 03:48:38 <owrt-1907-builds> build #133 of x86/geode is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Fgeode/builds/133
Mar 11 07:31:11 <owrt-1907-builds> build #128 of ath25/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath25%2Fgeneric/builds/128
Mar 11 07:34:10 <rmilecki> russell--: same problem with gpio-button-hotplug here
Mar 11 07:34:35 <rmilecki> would be great to debug & fix that as we have easy to reproduce case
Mar 11 07:34:49 <rmilecki> but it takes time & buildroot knowledge :|
Mar 11 07:35:29 <rmilecki> blogic: why one would prefer u80211d over iwinfo?
Mar 11 07:36:57 <ynezz> ubus
Mar 11 07:37:31 <rmilecki> but iwinfo is ubus capable, is it not?
Mar 11 07:37:48 <ynezz> dunno, I've thought it's just a cli, not a daemon
Mar 11 07:37:58 <rmilecki> maybe it was rpcd plugin then
Mar 11 07:45:58 <ynezz> must have been fun tracing down that ipv6 memleak  :)
Mar 11 07:46:06 <ynezz> thanks for taking care
Mar 11 08:10:19 <xback> blocktrron: Thanks for checking out that PR :-)
Mar 11 08:19:47 <SimoneNascivera> Hi everyone I have an issue with OpenWrt i2c configuration and since I spent several days on it and I couldn't solve it, I decided to ask here
Mar 11 08:21:04 <SimoneNascivera> I'm using a device based on mt7620a
Mar 11 08:21:42 <SimoneNascivera>  Hi everyone I have an issue with OpenWrt i2c configuration and since I spent several days on it and I couldn't solve it, I decided to ask here
Mar 11 08:21:48 <SimoneNascivera>  I'm using a device based on mt7620a
Mar 11 08:22:29 <SimoneNascivera> I'm currently modifying a pre made profile, when it fully works I'll make a custom one
Mar 11 08:22:51 <SimoneNascivera> I added "&i2c { status = "okay" } to the .dts file
Mar 11 08:23:10 <SimoneNascivera> but when I check dmesg this is the output:
Mar 11 08:24:09 <SimoneNascivera> root@OpenWrt:~# dmesg | grep 'pinctrl\|i2c'
Mar 11 08:24:09 <SimoneNascivera> [    0.162660] pinctrl core: initialized pinctrl subsystem
Mar 11 08:24:10 <SimoneNascivera> [    8.593605] i2c /dev entries driver
Mar 11 08:24:10 <SimoneNascivera> [    8.640812] rt2880-pinmux pinctrl: pin io1 already requested by pinctrl; cannot claim for 10000900.i2c
Mar 11 08:24:10 <SimoneNascivera> [    8.659445] rt2880-pinmux pinctrl: pin-1 (10000900.i2c) status -22
Mar 11 08:24:11 <SimoneNascivera> [    8.671770] rt2880-pinmux pinctrl: could not request pin 1 (io1) from group i2c  on device rt2880-pinmux
Mar 11 08:24:14 <SimoneNascivera> [    8.690675] i2c-ralink 10000900.i2c: Error applying setting, reverse things back
Mar 11 08:24:16 <SimoneNascivera> [    8.705437] i2c-ralink: probe of 10000900.i2c failed with error -22
Mar 11 08:24:18 <SimoneNascivera> [    8.803706] usbcore: registered new interface driver i2c-tiny-usb
Mar 11 08:24:28 <SimoneNascivera> I'm stuck here
Mar 11 08:25:26 <SimoneNascivera> Could you please advice me on how to proceed?
Mar 11 08:26:03 <PaulFertser> SimoneNascivera: first advice, please never paste more than 2-3 lines to a public channel, use some pastebin instead.
Mar 11 08:26:44 <PaulFertser> SimoneNascivera: second, check what other peripheral is multiplexed to the same pins, and disable it.
Mar 11 08:27:06 <SimoneNascivera> Sure I'm sorry. It's my first time here
Mar 11 08:27:36 <SimoneNascivera> Thank you for your suggestion. I'll do it immediately
Mar 11 08:28:32 <SimoneNascivera> With disabling you mean from the dts file?
Mar 11 08:32:24 <PaulFertser> SimoneNascivera: yes
Mar 11 08:40:31 <rmilecki> ynezz: thanks, that was really time confusing
Mar 11 08:40:35 <rmilecki> *consuming
Mar 11 08:41:16 <SimoneNascivera> I removed the entry from the dts file but it still gives me this error: https://pastebin.com/x7sYvAiL
Mar 11 08:41:50 <SimoneNascivera> This is the dts file: https://pastebin.com/n4exgZnD
Mar 11 08:42:21 <PaulFertser> SimoneNascivera: removed which entry?
Mar 11 08:43:05 <SimoneNascivera> gpio0 which had the pin 1 and 2 in common with i2c
Mar 11 08:48:28 <SimoneNascivera> Is there anything else that could prevent the kernel module from starting?
Mar 11 08:48:35 <SimoneNascivera> I'm not used to pinctrl
Mar 11 08:49:09 <PaulFertser> SimoneNascivera: cat /sys/kernel/debug/gpio
Mar 11 08:49:57 <SimoneNascivera> PaulFertser: https://pastebin.com/3jXyZ6Nu
Mar 11 08:50:21 <SimoneNascivera> GPIO0 is used by a code of mine
Mar 11 08:50:32 <SimoneNascivera> GPIO66 is the reset button
Mar 11 08:53:13 <SimoneNascivera> This is the output of cat /sys/kernel/debug/pinctrl/pinctrl/pinmux-pins if it is useful https://pastebin.com/DhfheWxE
Mar 11 09:01:01 <SimoneNascivera> Also setting gpio0 as disabled instead of removing the entry doesn't change anything
Mar 11 09:03:13 <PaulFertser> SimoneNascivera: hm, it's not disabled by default so it should have helped
Mar 11 09:05:52 <SimoneNascivera> PaulFertser: something changed because now I can't export pin0 with command "echo "0" > /sys/class/gpio/export", but I still have the same dmesg message
Mar 11 09:11:06 <PaulFertser> simone_: cat /sys/kernel/debug/pinctrl/*/pinmux-pins
Mar 11 09:12:01 <simone_> PaulFertser: https://pastebin.com/ePAURP9C
Mar 11 09:15:42 <SimoneNascivera> PaulFertser: I'm sorry for changing my nickname but I had to change computer
Mar 11 09:18:18 <PaulFertser> SimoneNascivera: so it's claimed by pinctrl indeed
Mar 11 09:19:29 <SimoneNascivera> PaulFertser: yes, it seems so. It's my first time using pinctrl and I dont know how to set it
Mar 11 09:19:30 <PaulFertser> SimoneNascivera: and pin0 now unclaimed
Mar 11 09:22:24 <SimoneNascivera> PaulFertser: how do I make pinctrl unclaim the pins?
Mar 11 09:29:46 <PaulFertser> SimoneNascivera: not sure yet. Are you able to "export" pin 1 btw?
Mar 11 09:30:06 <mart> Hi. I hope it's ok to ask this here: I tried to build a custom fritzbox4040 image (current openwrt master). Build works, I can flash the typical fb4040 eva image. During boot (I'm having a serial cable attached) I am getting lots of messages like: WDT failed to write: Bad address and lots of other "Bad address" messages. Can anyone point me in the right direction what this messages implies?
Mar 11 09:31:37 <SimoneNascivera> PaulFertser: no, i cannot export both pin 1 and 2
Mar 11 09:42:30 <ldir> aparcar[m]: not until at least Friday - is it kernel 5.4 dependent?  Currently linux won't crosscompile for openwrt under macos, which means docker and sloooow
Mar 11 09:43:08 <ynezz> they broke it, again? :)
Mar 11 09:43:18 <ynezz> thats 5.4?
Mar 11 09:44:40 <SimoneNascivera> PaulFertser: I finally fixed it. It was due to having "i2c" in state_default, which sets it as gpio
Mar 11 09:44:58 <SimoneNascivera> PaulFertser: thank you for your help
Mar 11 09:45:50 <PaulFertser> SimoneNascivera: so is there a bug in dtsi?
Mar 11 09:46:25 <PaulFertser> mart: I guess you should pastebin the full serial log for starters
Mar 11 09:47:29 <PaulFertser> SimoneNascivera: I see, in your device file. Ok, glad to hear you figured it out.
Mar 11 09:48:13 <PaulFertser> I was looking only through the dtsi so haven't spotted it.
Mar 11 09:48:16 <owrt-snap-builds> build #250 of armvirt/64 is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F64/builds/250  blamelist: Leon M. George <leon@georgemail.eu>, David Bauer <mail@david-bauer.net>, Yousong Zhou <yszhou4tech@gmail.com>, Rafa? Mi?ecki <rafal@milecki.pl>, Hans Dedecker <dedeckeh@gmail.com>,
Mar 11 09:48:16 <owrt-snap-builds> Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Mar 11 09:49:56 <ynezz> oh, watchdogs strikes again
Mar 11 09:56:08 <ldir> ynezz: It was never really working.  AIUI all the stuff under scripts/mod expects to find kernel headers natively.  4.19 broke with KERNEL_STACK_VALIDATION and I think the latest stuff is more fallout from missing/poor cross-compilation support under scripts
Mar 11 09:56:47 <ynezz> well, once you fix it, we can probably build under FreeBSD as well :)
Mar 11 09:58:51 <ldir> https://gitlab.com/ldir/openwrt/-/jobs/465672429
Mar 11 09:59:02 <ynezz> 404
Mar 11 09:59:07 <ynezz> you're so secret
Mar 11 10:00:08 * ldir wanders around the settings pages again
Mar 11 10:02:08 <ldir> ynezz: try again
Mar 11 10:03:14 <ldir> anyway, I now have to go for 2 days to do $paidwork as opposed to $unpaidhobby
Mar 11 10:04:48 <jow> booh
Mar 11 10:08:45 <ldir> that's not the opinion of the mortgage people ;-)
Mar 11 10:09:30 <ynezz> ldir: staging_dir/toolchain-x86_64_gcc-8.3.0_musl/include/asm/types.h
Mar 11 10:10:08 <ynezz> so probably some fiddling with the include paths is needed in owrt or upstream?
Mar 11 10:10:33 <ynezz> (if I understand that `./tools/include/linux/types.h:10:10: fatal error: 'asm/types.h' file not found` error correctly)
Mar 11 11:16:32 <cotequeiroz> ping nbd
Mar 11 13:59:44 <adrianschmutzler> jow: I want to remove iwinfo in a downstream firmware. will this have any side effects, as I see that iwinfo is not selected by dependencies, but somehow magically via extra_packages?
Mar 11 14:35:10 <jow> adrianschmutzler: I don't think so
Mar 11 14:36:35 <adrianschmutzler> okay, thanks. we replace wpad by hostapd anyway, so the criterion for adding it via extra_packages should actually go away anyway, but it's still there, so I wanted to make sure ...
Mar 11 14:39:48 <nbd> cotequeiroz: pong
Mar 11 14:41:23 <cotequeiroz> nbd: I'm reworking 'scripts/config' to sync with linux master.  I really like the way the dependencies are shown, making it a lot easier to find out why a symbol is being selected.
Mar 11 14:42:13 <cotequeiroz> Do you have a repository with the changes made from upstream to get to our current state?
Mar 11 14:44:56 <cotequeiroz> I've made one by trial and error here:https://github.com/cotequeiroz/linux.git
Mar 11 14:50:07 <nbd> cotequeiroz: i used to have that, but it's out of date now. i can give you some info that might help getting it rebased:
Mar 11 14:50:24 <nbd> scripts/config from openwrt commit 9bfa6971aeaa663ae5cc845f589ebbd1459a1fc9 was based on upstream commit f429d35588847fa1048f9dbdcc3cc1ee1b530041
Mar 11 14:53:31 <cotequeiroz> I saw that, but I'm thinking about keeping the warning.  It pointed out for example, that RTC_SUPPORT should not be tristate, but a bool.
Mar 11 14:57:25 <cotequeiroz> I have to go now, and will be back in 90 minutes.
Mar 11 14:58:53 <karlp> ldir: what do you use (if anything) for mdns browsing on osx?
Mar 11 18:54:22 <owrt-snap-builds> build #288 of armvirt/32 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F32/builds/288
Mar 11 19:51:49 <aparcar[m]> ynezz: as always, thanks for the response
**** ENDING LOGGING AT Thu Mar 12 02:59:57 2020