**** BEGIN LOGGING AT Sun Jun 02 02:59:58 2019 **** BEGIN LOGGING AT Sun Jun 02 08:28:05 2019 Jun 02 12:01:43 kyli: please report it on bugs.openwrt.org Jun 02 12:04:45 <_abc_> Hi. Why is the lua version in 18.06.2 5.1 ? It is ancient. Are there problems with porting newer luas to openwrt? Size perhaps? Jun 02 12:07:14 i guess it's because updating beyond that breaks a lot of users due to the change in how modules are handled Jun 02 12:07:57 but that doesn't mean openwrt can't have two lua packages Jun 02 12:12:38 for some it's ancient, for some it's stable and battle tested Jun 02 12:13:10 :D Jun 02 12:39:31 lua versions aren't really new/better, they're "here's a new thing altogether" Jun 02 12:40:16 having support for lua 5.3 as well might be nice, but we don't do that at the moment, as we're not using versioned directories Jun 02 12:41:21 _abc_: it's kinda like asking why gcc supports c89 or c99 as default, not c11, they're "ancient" but not problemmatically ancient. it's not openssl Jun 02 12:46:16 <_abc_> I know, I am just trying to stay on top of things, on several platforms. openwrt, linux desktop/debian and also esp8266 all with lua. Jun 02 12:56:00 you can add a newer lua using your own feed Jun 02 12:56:12 the Makefiles aren't that ugly Jun 02 13:17:16 Hauke: any idea how to tackle increased bug reports with kernel crashes which were probably uncovered with 9b1239451d65 ("Kernel: Activate CONFIG_HARDENED_USERCOPY") ? Jun 02 13:19:32 ynezz: can you point me to such an bug report? Jun 02 13:20:25 Hauke: FS#2305 or FS#2297 Jun 02 13:22:05 ynezz: thanks Jun 02 13:22:13 hmm should we revert this? Jun 02 13:22:29 I am not sure because these are probably real bugs we found Jun 02 13:23:26 I am also supprised to see this with mkfs.ext2 Jun 02 13:24:04 I would have expected this more on our out of tree drivers Jun 02 13:24:55 the strange thing is, that mkfs.ext2 exposes problem with dropbear Jun 02 13:25:18 ????? Jun 02 13:25:26 if you look at the crash Jun 02 13:25:31 I can not explain this Jun 02 13:25:55 ok Jun 02 13:26:11 it's caused by dropbear pid/task when mkfs.ext2 is running Jun 02 13:26:37 I'm not in favor for reverting it, I don't like reverts and I think, that it's actually some weird bug somewhere Jun 02 13:26:55 but I'm not able to reproduce it either Jun 02 13:27:34 maybe someone with mt7621 could try it and either confirm or deny it Jun 02 13:28:56 I just wanted to flash my new mt7621 device Jun 02 13:35:05 <_abc_> http://pgl.yoyo.org/web3.0/intro.php excellent Jun 02 14:43:21 mt7621 sucks Jun 02 14:43:25 :D Jun 02 15:34:25 mnemoc:you _can_ but there's no support for building lua modules for "base" lua5.1 and your extra lua, so you'd be in a deep pit pretty quickly. Jun 02 15:35:06 karlp: :D Jun 02 17:06:52 When I connect my UART to my Xiaomi Mi WiFi R3G the system does not boot any more, does someone else has the smae problem, or which UART is working better? Jun 02 17:07:06 I assume that some of the UART pins are also bootstrap pins Jun 02 17:07:17 but I haven't checked the datasheet yet Jun 02 17:07:49 when I disconenct the UART and conenct it only later e.g. when the system is in u-boot it works Jun 02 17:18:03 lynxis ping Jun 02 17:21:47 Hauke: I have the same issue with the wrt1200ac Jun 02 17:21:54 not that this helps you any bit ;) Jun 02 19:07:56 <_abc_> Hi. /etc/rc.button/failsafe should fire when no other script matches the passed %BUTTON% right? I don't have that happening. Jun 02 19:08:38 <_abc_> It contains: [ "${TYPE}" = "switch" ] || echo ${BUTTON} > /tmp/failsafe_button Jun 02 19:09:25 <_abc_> Nothing is ever written into the tmp file. I instrumented the other present scripts in the rc.button dir with logger, only reset gets called. Does this mean the QSS button is not "wired" in this release to any script? Jun 02 19:09:38 <_abc_> Is there some way to make sure this is so (not wired)? Jun 02 19:10:17 <_abc_> Afaik there should be a button mask in the kernel somewhere telling the module which buttons to watch for change/polling. Where is this mask? Only in the source? Jun 02 19:16:49 <_abc_> Great I exported all gpios, ignoring the erroring ones, and ran a script through them to see values, all as "in", to see what the qss button is connected to. No chance, nothing changes. Jun 02 19:17:12 <_abc_> This is 18.06.2 tl-wr741 v4 AR9331. Jun 02 19:17:31 <_abc_> Is the default as shipped openwrt release always "neutering" gpios other than platform ones? Jun 02 19:17:59 <_abc_> Seems to be true on BB as discussed before on the 740 and now on 18.06.2 too Jun 02 19:19:42 <_abc_> Okay, looks like there is no way around installing the sources and looking at them Jun 02 19:24:16 <_abc_> echo 11 12 > /sys/bus/i2c/drivers/pcf857x/bind Jun 02 19:24:22 <_abc_> --> no such device? Jun 02 19:24:44 <_abc_> The driver is built in, I did not add packages to enable it. Jun 02 19:41:10 <_abc_> In https://github.com/openwrt/openwrt/blob/master/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c -- what C idiom is: val = !!gpio_get_value_cansleep(bdata->b->gpio); -- the !! means double negation? Is that not optimized out by the compiler? I assume this is an idiom to force boolean/ 0/1 answer in C but does the compiler not eat the !!? Jun 02 20:01:56 <_abc_> This seems to indicate the pcf857x module is only compiled as a module for ath79 platform. Yet in the running 18.06.2 here it is not a module, the module is not in lsmod, and the sysfs device is present?! https://github.com/openwrt/openwrt/search?p=1&q=pcf857x&unscoped_q=pcf857x Jun 02 20:02:13 <_abc_> Does anyone have an idea how come my running 18.06.2 and the github could be out of sync? Jun 02 20:19:15 _abc_: the driver is compiled into the kernel -> https://github.com/openwrt/openwrt/blob/v18.06.2/target/linux/ar71xx/config-4.9#L328 Jun 02 20:21:43 the kmod package will still be created, but empty. its existence is just to serve as something other kmods can depend on without having to special case when the .ko isn't available because the driver is already in the kernel Jun 02 20:22:20 _abc_: no the compiler does not eat !! and it is used to force a boolean result Jun 02 20:22:26 <_abc_> Okay so that module needs params, they are passed in how? Which gpios is it mapped to? Jun 02 20:22:36 <_abc_> ldir: thanks, interesting it is not optimizing that out. Jun 02 20:23:30 <_abc_> KanjiMonster: so how is it loaded? There are no params, the module compiled in is useless as such, no? Jun 02 20:23:36 compare & contrast https://pastebin.com/wtQeYg2H Jun 02 20:23:39 <_abc_> I can't set / bind gpios to it Jun 02 20:27:08 <_abc_> Would the pcf857x driver take 2 gpios at once per echo? Since it needs sda and scl? echo 11 26 >/sys/bus/i2c/drivers/pcf857x/bind ? Jun 02 20:29:01 <_abc_> ldir: are you sure no compiler flags will make the compiler optimize !! out? Jun 02 20:30:02 <_abc_> KanjiMonster: can you direct link me to the .c file which implements the pcf857x driver? I tried to search by string since it creates "pcf857x/" in sysfs but could only find patches Jun 02 20:32:00 _abc_: is there even a device present where the driver can bind to it? and its https://elixir.bootlin.com/linux/v4.9.180/source/drivers/gpio/gpio-pcf857x.c Jun 02 20:32:18 <_abc_> ~# echo 11 >/sys/bus/i2c/drivers/pcf857x/bind Jun 02 20:32:19 <_abc_> ash: write error: No such device Jun 02 20:32:21 <_abc_> ^^ Jun 02 20:32:59 that's not how "bind" works Jun 02 20:32:59 <_abc_> KanjiMonster: thanks for the link. I wonder if this is specific to the ath79/tiny platform, the crippled device lingering in there. Jun 02 20:33:13 <_abc_> KanjiMonster: I thought it works like export on gpio. No? Jun 02 20:33:25 bind expects a .. I guess i2c device ID the driver should attach to Jun 02 20:33:54 <_abc_> It has to know the gpio pins 1st Jun 02 20:35:16 no it doesn't Jun 02 20:36:36 pcf857x is a provider of gpios, not a consumer (AFAICT) Jun 02 20:36:42 <_abc_> Well somehow somewhere it has to get into the kernel, which gpios are assigned to it. Looking at static int pcf857x_probe( ... it eventually calls if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE)) -- which implies it must already know the gpios Jun 02 20:37:10 <_abc_> KanjiMonster: the pcf is attached to the ath79 using 2 gpios of the ath79. They can be dedicated ones or bit banged. Jun 02 20:37:26 <_abc_> Which subsystem / module provides this low level function? Jun 02 20:37:37 <_abc_> i2c_check_functionality? Jun 02 20:38:33 <_abc_> Near the bottom there's a comment "register after i2c postcore initcall and before subsys initcalls that may rely on these GPIOs" Jun 02 20:38:34 you mean bit banged i2c? Jun 02 20:38:39 <_abc_> Yes Jun 02 20:39:15 that's a completely different driver Jun 02 20:39:43 https://elixir.bootlin.com/linux/v4.9.180/source/drivers/i2c/busses/i2c-gpio.c Jun 02 20:40:04 <_abc_> That should be kmod-i2c-gpio.ko when built? Jun 02 20:40:20 you'll need to provide the gpios either through device tree, or when registering the platform driver. nothing you can do from userspace Jun 02 20:40:27 *platform device Jun 02 20:40:45 <_abc_> I think loading kmod-i2c-gpio.ko will take params? Jun 02 20:42:00 why do you think that? there is nothing in the linked code suggesting it does Jun 02 20:42:18 <_abc_> ret = devm_gpio_request(&pdev->dev, sda_pin, "sda"); ret = devm_gpio_request(&pdev->dev, scl_pin, "scl"); Jun 02 20:42:30 <_abc_> What's devm_gpio_request()? Jun 02 20:43:19 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Jun 02 20:43:30 <_abc_> KanjiMonster: where are these properties read from? Jun 02 20:44:07 <_abc_> of_property_read_u32(np, "i2c-gpio,delay-us", etc? Jun 02 20:44:13 <_abc_> of_ is what? Jun 02 20:44:30 open firmware, AKA devicetree Jun 02 20:44:45 <_abc_> Ah so these come in via the platform defines at compile time only/ Jun 02 20:44:46 <_abc_> ? Jun 02 20:45:30 <_abc_> That makes some sense, sadly. I don't understand why the pcf875x driver is hard compiled into the kernel if the subsystems it needs to work are modules and not compiled in Jun 02 20:46:03 devicetree is what ath79 uses; ar71xx uses platform devices, https://github.com/openwrt/openwrt/blob/v18.06.2/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar750.c#L83 Jun 02 20:46:38 i2c[-gpio] is also compiled in https://github.com/openwrt/openwrt/blob/v18.06.2/target/linux/ar71xx/config-4.9#L372 Jun 02 20:47:16 <_abc_> Okay so if it is in, where the heck is it in the image? Jun 02 20:47:50 if the board code your board is using doesn't register a i2c-gpio platform device, there will be no i2c bus registered Jun 02 20:48:27 <_abc_> Ah. So the pcf857x is considered a platform device, because it is used on other boards? Of this family? Jun 02 20:48:37 <_abc_> That makes sense! Jun 02 20:49:07 no, platform device is just the standard inferface for registering devices that can't be automatically probed, like gpio connected stuff Jun 02 20:55:25 <_abc_> Hm. Jun 02 20:56:52 <_abc_> Okay, so why can't I control gpio's I managed to export (no error) under /sys/class/gpio/gpio* ? I can read from the ones attached to the buttons, after rmmod gpio-button-hotplug; the others I can't read or write to in software, they seem frozen. I interfaced to them in hw, no reading external state, no writing works. Jun 02 20:57:11 <_abc_> The write commands to value and direction succeed, no changes Jun 02 20:57:49 probably pinmuxed to other functions Jun 02 20:57:51 <_abc_> Are non platform gpio's masked out somewhere in the custom build process? Perhaps to avoid "mishaps" in case a pin is hard pulled up or down or such? Jun 02 20:58:16 <_abc_> KanjiMonster: then why can I export them? Export does not check for other functions? Jun 02 20:58:30 no, it doesn't Jun 02 20:58:47 <_abc_> Anyway I selected those which are apparently not connected to anything, still no fun. There are 3 free gpios on this platform I have access to. Jun 02 20:59:03 <_abc_> They are not used on the pcb apparently Jun 02 20:59:22 <_abc_> Could they be masked anyway? **** ENDING LOGGING AT Mon Jun 03 02:59:57 2019