<nick[m]1234>
should I put your singed-off their, too?
<nick[m]1234>
if it fixes it
<nick[m]1234>
there*
<hurricos>
df
<hurricos>
dmesg
fda has joined #openwrt-devel
fda has quit []
dangole has quit [Remote host closed the connection]
fda has joined #openwrt-devel
<hurricos>
svanheule: no new bus master after confirming spi_gpio is loaded
<hurricos>
however, I added some printks to spi-gpio.c and can say for sure that the driver just hasn't registered against the device
<hurricos>
does a driver care where in a device tree it finds a compatible node?
<hurricos>
I mean, I'm sure the relationship between devices might be twisted by moving a node, but I'm trying to figure out (if) why spi_gpio isn't registering against a spi-gpio-compatible
<blocktrron1>
nick[m]1234: do as you wish
<blocktrron1>
"mx25l6405d_defaukt_init_fixups" <-- i think you have a typo there
Grommish_ has joined #openwrt-devel
<blocktrron1>
hurricos: not entirely in the loop, but all drivers (SPI master, GPIO expander) have to be in-kernel for led-gpio to register the LEDs
<hurricos>
!
<hurricos>
that's very helpful, thank you
<hurricos>
so I wonder, why do we ship kmod-spi-gpio at all?
<hurricos>
well
<hurricos>
wait no.
<hurricos>
sorry, I misread what you said.
<hurricos>
My problem is that spi
<blocktrron1>
hurricos: please provide a link to your current tree to keep it short
<hurricos>
I expect something under /sys/class/spi_master.
<hurricos>
spi_gpio and friends are compiled as modules rather than being in-kernel.
Grommish has quit [Ping timeout: 480 seconds]
<blocktrron1>
your config implies you addd spi-gpio to your kernel
<blocktrron1>
in which case you'll receive a stub package
<hurricos>
When I added the kern symbol SPI_GPIO to arch/powerpc/platforms/85xx/Kconfig in my patch, I did see function signatures from spi-gpio.c in System.map, but assumed it was not compiled in because I did not see any of the printk's I'd added here: https://github.com/Hurricos/openwrt/commit/0c0c5702f5597ed3347e57896e9e103a2aa29d76
<hurricos>
After having make distclean'ed and compiled a kernel without SPI_GPIO, and made myself sure that spi_gpio was loaded, I realize it's possible that the led_spi node was never being seen, rather than spi_gpio not being in the kernel.
goliath has quit [Quit: SIGSEGV]
<blocktrron1>
and the problem with your durrent tree is what exactly?
<nick[m]1234>
blocktrron1: thanks already fixed typo in a new commit ;) I will put your signed-off and send to mailinglist and do some pending pr to openwrt. I tested everything again and it seems to work.
<nick[m]1234>
thanks a lot for your help!!! :)
<hurricos>
So yes, I know why I was getting a stub package. I can't seem to figure out why spi_gpio isn't running spi_gpio_probe
<blocktrron1>
nick[m]1234: can you check whether the nanostation ac still works with 5.10? AFAIR it also has an 8 bit SR, and should also be affected
<blocktrron1>
so the whole 16 bit SR flag for macronix is questionable at best form my POV
<hurricos>
(after having fixed the issue you just observed RE: stub package)
<blocktrron1>
it is built into the kernel, so packaging and modules are not of relevance
<hurricos>
I packaged and modularized because I had no way to tell whether spi_gpio was being loaded at all.
<hurricos>
blocktrron1: Should I take your quote > but all drivers ... have to be in-kernel < to say that I must go back and put these drivers in-kernel to have them register against device tree nodes at all?
<blocktrron1>
you can't have drivers necessary for driving LEDs as modules
<blocktrron1>
As OpenWrt failsafe utilizes LEDs but does not mount the rootfs
<hurricos>
Right. I understood that one from svenheule, I only packaged as packages to be able to verify with lsmod, etc. that spi_gpio was there. If you know a better way to tell interactively whether a module is built into the kernel, I'd appreciate it
<blocktrron1>
check the .config after compiling in the linux build-dir
<hurricos>
for e.g. SPI_GPIO, yes?
<hurricos>
err. CONFIG_SPI_GPIO
<blocktrron1>
correct
<hurricos>
Thanks, I wasn't sure that was reliable.
<hurricos>
(tristate config options confuse me)
<blocktrron1>
Also i would refrain from using the per machine-inclusion of configuration as long as it is only used OpenWrt downstream
<hurricos>
So, would you suggest applying CONFIG_SPI_GPIO to the p1020 subtarget entirely?
<blocktrron1>
it comes down to the same result
<hurricos>
err, sorry. mpc85xx, in this case
<blocktrron1>
but with less confusion
<blocktrron1>
you can also just add it to the relevant subtarget, idc
<hurricos>
great.
<blocktrron1>
is the gpio-reset-bit required?
<hurricos>
No clue. The upstream source drives these LEDss from userspace.
<nick[m]1234>
blocktrron1: Currently, I don't, but I can look if I can fetch me somewhere a device. :)
<blocktrron1>
Does have nothing to do with your issue of the SPI master not probing, but your shift register does not seem to have a output enable input
<hurricos>
not to mention that I can't imagine qca9882 firmware running correctly on a qca9888, but weirder things have happened
GoaTendies_ has joined #openwrt-devel
<GoaTendies_>
Anyone willing to help me compile a build with a modified DTS file to turn up the power tables on a 1900AC ? Can pay a bounty. Thx
<hurricos>
GoaTendies_: Increasing power tables isn't going to get you anywhere
<hurricos>
they're there for a reason -- just reflecting the status quo of what the hardware is capable of.
<hurricos>
Otoh, you do need to have the country code set correctly for OpenWrt to take advantage of what your hardware can do
<hurricos>
don't forget either, more than ~10dB or so difference between an AP and a STA means that your AP will stop seeing block acknowledgements from your client and transmit speeds will drop substantially
<hurricos>
if you're trying to get better wifi you're better off using dumb APs
<GoaTendies_>
Thanks for the reply, hurricos. You lost me on the block acknowledgements and 'dumb APs
<hurricos>
you don't need higher tx power
<hurricos>
you need closer access poins :P
<GoaTendies_>
Well, I can't be closer unfortunately. I've read a bit how it's likely not the benefit most would think, but I'm on the cusp of it being 'good enough' just need a little boost and was hoping that'd be the cure.
rsalvaterra has quit [Quit: rsalvaterra]
<GoaTendies_>
I'm using the US country code in Canada, wasn't aware if there was a special one just for us. Took me long enough to just get a good router configured for OpenVPN and some sensible firewall settings. Just now limited to way too low of throughput and need to try something else.
<hurricos>
when I say closer, what I mean is
rsalvaterra has joined #openwrt-devel
<hurricos>
you can use more than one physical device
<hurricos>
An Archer C7 costs around $20 CAD, for example
<GoaTendies_>
I thought about it, or trying to understand how to use the same router as a repeater and place it closer. Was worried about throughput loss in that case from past experience with a 'bridge'?
<hurricos>
You should wire the additional AP to the existing one.
<hurricos>
At that point, you just make two edits to the default OpenWrt config on the device --
<hurricos>
edit /etc/config/network to be a DHCP client on LAN as opposed to 'static'
<hurricos>
There's no reasonable way to do any sort of meshing or repeating with the 1900AC due to the wireless chipset, unfortunatley
<GoaTendies_>
I have a building closer and could try seeing what kind of signal I can get there first.. I'm quite a ways from a default config as it stands, piecing together what I think is what I'm after. A good connection comes first no doubt.
<hurricos>
You keep your config on the 1900AC. The two changes above would be changes from the OpenWrt defaults on a new device.
<GoaTendies_>
The 3200 comes with a second (or third?) radio if I recall, but I saw that the WiFi chipset no longer loaded a power table (compared to the 1900AC) so that's what I was going to pursue.
<hurricos>
You say building. This is outdoor?
<GoaTendies_>
Residential, house to house a block away. I have a detached garage a bit closer, which is inbetween my line of sight.
<GoaTendies_>
I have an older Asus RT-N66U here I had OpenWRT running ok on. Just didn't support the OpenVPN I think.
<hurricos>
I don't know what your situation is exactly, but in your case I would place two identical devices as close to 'line of sight' of each other, one in each building.
<hurricos>
I'd use a wireless mesh network, and bridge it with the LAN on each device. That does limit you to devices that have ath9k, ath10k or mt76-based wireless chips
<GoaTendies_>
*the N66U didn't have a working driver for 5Ghz, that's why I abandoned it. Yeah I wasn't banking on setting up a second device and thought I could get this one working stronger along.
<GoaTendies_>
Ok, thanks for the advice, I'll look at using another device.
<hurricos>
The WRT1900AC already has very high power. You're not going to get very far with 5GHz (it doesn't penetrate buildings well), and on 2.4GHz I'm sure you're already at the max (30dB)
<hurricos>
You're going to be running into the problem of your 1900AC not "seeing" responses from your clients.
<GoaTendies_>
I just fired it up here, and I get ~-86 to -92dB on 5Ghz, the Rx/Tx rate is constantly dropping down and changing 'bands' - 20 /40 Mhz & VHT-MCS 1 / VHT-NSS 2 / Short GI / MCS 1
<hurricos>
-86 is tenuous
<hurricos>
-92 is pretty much the sensitivity limit for regular clients
<GoaTendies_>
I'm hearing what you're saying, probably coincides with what I just mentioned. Sorry I don't fully understand everything yet.
<neggles>
anything with a CN5xxx is a paperweight imo
<hurricos>
not as bad as CNS3K
<neggles>
octeon II is bad enough, octeon+ can go
<Namidairo>
lol those wires
<Namidairo>
and the RTC battery
<hurricos>
Namidairo: nematodes
<hurricos>
everything about this board was an afterthought
<hurricos>
booting with CONFIG_GPIO_CDEV
<neggles>
the USG-XG-8/ER-Infinity are a CN7360
<hurricos>
VSC8490 if I'm not mistaken?
<hurricos>
or am I thinking of ER X 10?
<neggles>
ER-Infinity has 8xSFP+
<neggles>
direct to CPU
<hurricos>
(the 10GB PHY)
<hurricos>
NOT DIRECT!
<hurricos>
it's XAUI
<hurricos>
or so I thought
<hurricos>
let me look at a board
<neggles>
octeon III
<neggles>
there are two small chips
<neggles>
that are quad-port quasi-phys
<neggles>
I've lost the device tree where'd it go
<hurricos>
wow no
<hurricos>
you're right
<hurricos>
it's straight in
<hurricos>
don't need XAUI for <7cm
<neggles>
it's quite the beast
<neggles>
even if it pulls like 50? 75?w at idle
<neggles>
the LCD module on the front of the USG version is a fully standalone device with a cortex-M7 STM32 connected over USB
<neggles>
it also has a buffer overflow or something internally after it's been playing the loadscreen animation for about 10 hours or so
<hurricos>
if only cavium didnt suck :(
<neggles>
so the progress bar starts having a seizure
<hurricos>
for which the kernel patches are some arcane bunk
<hurricos>
in the oem kernel
<hurricos>
I bet
<neggles>
they're stupid but they're not all that bad
<neggles>
just for some reason they used a dir under /proc instead of /sys for their custom gpio chardev
<hurricos>
I see that all the time
<neggles>
i just rewrote the kernel module
<neggles>
since all the userspace daemon needed was to flip a few pins back and forth
<hurricos>
gpiodetect works now :O
<neggles>
and now i have the USG LCM daemon running under EdgeOS
<neggles>
i figured turning it into an edgerouter was realistically the most useful thing I could do
<hurricos>
gpioinfo gives me this though
<hurricos>
gpioinfo: error creating line iterator: Invalid argument
<neggles>
yeah okay mpc85xx gpio driver doesn't support the new abi :/
<hurricos>
gah
<neggles>
probably fairly trivial to patch
<neggles>
but not now
<hurricos>
nooo
<hurricos>
not now
<hurricos>
I'm going home and to sleep before I ☠️
<neggles>
oh
<neggles>
dammit
<neggles>
Using it on a system with CONFIG_GPIO_CDEV_V1 disabled results in highly obscure errors which do nothing to explain what exactly is wrong. For instance running 'gpioinfo' produces the error "error creating line iterator", and only having meticulously traced the execution flow of this tool in the source code can one find out that this is due the
<neggles>
ioctl(GPIO_GET_LINEINFO_IOCTL) call in gpiod_line_update() (in lib/core.c) failing as unsupported.
<hurricos>
I'm not seeing anything about the bootrom knowing about mmc
<neggles>
MTK_MSDC = OFF
<neggles>
think that's the mtk mmc driver
<neggles>
yes
<neggles>
so you'd need to rebuilt u-boot
<neggles>
with that switch flipped
<hurricos>
among other things mio
<hurricos>
ultimately the bootrom needs to be able to read everything from mmc
<neggles>
the drivers are all there
<hurricos>
can't have drivers if you can't read them
lmore377 has joined #openwrt-devel
<hurricos>
it expects to boot from SPI
<neggles>
oh i mean u-boot has the code for mmc controller etc. and it's got a 16mb SPI flash it runs u-boot off
<neggles>
so if you turn on mmc support in the spi flash you could boot from SD using the spi flash u-boot
<hurricos>
right, I think dwfreed's question was, can I boot u-boot from ....
<hurricos>
oh you know
<hurricos>
that's not what their question was was it
<hurricos>
nvm
<neggles>
yeah, running u-boot out of the microSD is more difficult / maybe not possible
<hurricos>
you can do it on P1020 :D
<dwfreed>
maybe I could get away with just altering the root= kernel command line param
<neggles>
dwfreed: that would just be extroot
<neggles>
which, yes
<hurricos>
P2041RDB actually checks sdhc first to see if the first block starts with its own bootloader magic
<neggles>
hurricos: there's a 64B i2c eeprom that tells it what order to try boot things from in
<neggles>
on the 1020s, at least
<dwfreed>
neggles: extroot doesn't load the /rom from the extroot, only the /overlay
<hurricos>
neggles: hmmmmmmmmm wait is it readable?
<hurricos>
writable?*
<neggles>
yes
<neggles>
found some commented hex files of their contents in... something...
<hurricos>
I could use that and solder on a 16MiB oh
<neggles>
qoriq sdk
<hurricos>
well if I brick it I can't rewrite the i2c :sweating:
<neggles>
you can't reprogram an i2c eeprom?
<neggles>
do you have a SOIC clip and literally any microcontroller? :P
<hurricos>
well
<hurricos>
where is the i2c?
<hurricos>
is it a tiny one?
<neggles>
it's a regular ole SO-8
<hurricos>
or is it the same standard pitch they use foir SOIC8s
<hurricos>
WAHHHHHH
<neggles>
pretty sure anyway
<dwfreed>
neggles: I basically want entirely different images (but I could keep the same kernel among them, so I can just use the spi flash for that) with different packages baked into their /rom
<dwfreed>
(the microsd card will be partitioned)
GoaTendies_ has quit [Remote host closed the connection]
<neggles>
dwfreed: then you'd probably need to rebake u-boot with mmc support
<neggles>
but if kernel is in spi flash
<neggles>
then if you change kernel config to let u-boot pass the cmdline instead of utterly ignoring it like openwrt usually does
<dwfreed>
yeah, that's the idea
<neggles>
that'll work yeah
<dwfreed>
and then I can manipulate the uboot env from within openwrt as needed to pick the boot device
<neggles>
yup
<neggles>
or even just small u-boot script in env vars
<hurricos>
ahh, technology :)
<dwfreed>
(I use the physical switch and the hotplug events for them to do that)
<neggles>
if mmc 0 info fails, boot from nand
<neggles>
er, nor
<dwfreed>
that goes back to requiring uboot with mmc support :P
<neggles>
...right
<neggles>
derp
<neggles>
i mean building u-boot for a gl.inet product isn't hard
<neggles>
but intimidating i guess
<dwfreed>
eh, not too intimidating for me, I run gentoo
<dwfreed>
just lazy
<neggles>
hurricos: hmm i may be wrong i think i misidentified the eeprom
<neggles>
or is this tiny msop the tpm
<neggles>
ah, no, the tpm is the SC3204 next to it, so alas the eeprom is indeed tiny as heck
<neggles>
could tag tiny wires to it if really pressed, but.
<ynezz>
nick[m]1234: you need seccomp support in kernel so you can't add it adhoc via some package, so that dependency doesn't make sense
<nick[m]1234>
ynezz: maybe I misunderstood the syntax, I thought it means if @SECCOMP_SUPPORT is enabled (so kernel seccomp support) I also select procd-seccomp
<nick[m]1234>
+@SECCOMP_SUPPORT:procd-seccomp
<nick[m]1234>
is that incorrect?
<ynezz>
no, that package needs to be already in the image, so that's why it's included in include/target.mk when CONFIG_SECCOMP is enabled
<nick[m]1234>
ynezz: yep you are right. probably fixed by https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=520403cd4978fd2e3cca389e5009ca5c0ac26db9
<nick[m]1234>
thanks!
<nick[m]1234>
probably users are using legacy openwrt version
felix has quit []
<Namidairo>
I don't suppose Nixio.exec parsed line breaks as new commands...
spirry has quit [Ping timeout: 480 seconds]
<Namidairo>
oh wait no they're passing it through /bin/sh -c
fda has joined #openwrt-devel
felix has joined #openwrt-devel
<nick[m]1234>
was there already somewhere a discussion what we do with 32mb ram devices?
danitool has quit [Remote host closed the connection]
danitool has joined #openwrt-devel
drikus_ has quit [Ping timeout: 480 seconds]
Weissnix4711 has joined #openwrt-devel
Weissnix4711 has quit []
minimal has joined #openwrt-devel
<blocktrron1>
rsalvaterra: I'll have a short look but this guy on the forum is a hassle to deal with
onemarcfifty has quit [Remote host closed the connection]
onemarcfifty has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
minimal has quit []
drikus has joined #openwrt-devel
<rsalvaterra>
blocktrron1: Locking is not my forté, but if I'm reading the stack trace correctly and scheduling is occurring after the mutex_lock in the aw9523_gpio_set function, I don't understand how it could happen. :/
drikus has joined #openwrt-devel
drikus has quit [Remote host closed the connection]
zenox has joined #openwrt-devel
Gaspare has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
drikus has joined #openwrt-devel
drikus has quit [Remote host closed the connection]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
dangole_ has joined #openwrt-devel
aiyion has joined #openwrt-devel
aiyion_ has quit [Ping timeout: 480 seconds]
dangole has quit [Ping timeout: 480 seconds]
drikus has joined #openwrt-devel
drikus has quit [Remote host closed the connection]
Gaspare has quit [Quit: Gaspare]
pmelange1 has joined #openwrt-devel
pmelange has joined #openwrt-devel
pmelange1 has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
onemarcfifty has quit [Remote host closed the connection]
onemarcfifty has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
Tapper has joined #openwrt-devel
rmilecki has joined #openwrt-devel
marc__ has joined #openwrt-devel
onemarcfifty has quit [Read error: Connection reset by peer]
nlowe has joined #openwrt-devel
<stintel>
dangole_: pong
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
victhor has joined #openwrt-devel
drikus has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
Gaspare has joined #openwrt-devel
marc__ has quit [Read error: No route to host]
marc__ has joined #openwrt-devel
dangole_ has quit [Remote host closed the connection]
srslypascal is now known as Guest9417
srslypascal has joined #openwrt-devel
Guest9417 has quit [Ping timeout: 480 seconds]
dangole has joined #openwrt-devel
<dangole>
stintel: was wondering if you could test the unifi6lr with 2.5GE uplink. i don't have an injector yet and only 1GE PoE switch to power the device...
<stintel>
dangole: did you make any changes ?
<dangole>
stintel: yes, i pushed to master already. the AQR112C is now recognized
<stintel>
once I figure out firewalld with nftables backend and then adapt my strongswan updown script to insert nftables rules, I'll be able to access my home network properly
<stintel>
I hope the U6LR is connected
<stintel>
but I fear it might not be
* stintel
currently in hospital :(
<dangole>
stintel: probably more work will be needed, but it would be interesting to examine the PHY using mdio-tools (using kmod-mdio-netlink), eg. mdio mdio-bus 8:7 0xc800
<dangole>
stintel: oh, so forcing 2500base-t and examining phy registers definitely something more fun doing locally i suppose... unless you configure the unifi6lr to be a wifi client so you can play with ethernet without cutting yourself off...
marc__ has quit [Read error: No route to host]
onemarcfifty has joined #openwrt-devel
<dangole>
stintel: i hope you'll be fine soon!
<stintel>
dangole: it's opened and has ttl attached and can powercycle it via the switch
<dangole>
stintel: ok, so can be fun :)
<stintel>
just not sure if it's currently plugged in
<stintel>
the good thing is, since I ended up in hospital I'm not 2000km away from the U6LR, rather 2 or so
<dangole>
stintel: i basically got clause 45 mdio access working and then aqr112c gets detected. 1000m link is detected properly and works. 100m link is detected but doesn't work. 2500m isn't even advertised (according to ethtool) and i can't test...
Gaspare has quit [Quit: Gaspare]
<stintel>
but first fighting with firewalld and nftables backend, I can revert to iptables, again, but rather fix it than doing a workaround this time :)
drikus has joined #openwrt-devel
drikus has quit [Remote host closed the connection]
Weissnix4711 has joined #openwrt-devel
Tapper has quit [Quit: Tapper]
onemarcfifty has quit [Remote host closed the connection]
onemarcfifty has joined #openwrt-devel
<zenox>
Hello, I'm tinkering around with a ZTE WF830 I have laying around. It's running OpenWrt 14.07, and I'd like to port (?) some newer version to it, but I don't have a clear idea of what to do, even after reading the docs on adding new device support. From what I've understood from the docs and source code, I think I should start with creating a device tree file, is that correct? Is there any kind of checklist of what to incorporate
<PaulFertser>
zenox: first thing to learn is what hardware it's based on and what similar boards are supported. Figuring out the SoC would be the very first step.
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<PaulFertser>
SpaceX: As a failsafe, we limit the uptime of our devices to 20 days.
<PaulFertser>
what?
philipp64 has quit [Quit: philipp64]
<hauke>
PaulFertser: it is rocket science ;-)
<PaulFertser>
hauke: that's extracted from OpenWrt fork running on their fancy wifi routers.
zenox has quit [Remote host closed the connection]
zenox has joined #openwrt-devel
philipp64 has joined #openwrt-devel
philipp64 has quit []
<zenox>
PaulFertser: I've managed to access the serial port and figure out most things (MT7621 SoC, 128MB NAND flash, 128MB DDR3 RAM), but there's no /sys/class/gpio so I'll try to get the led and button info some other way. Unless I can skip those for now and figure that out on the firmware I'll compile?
<PaulFertser>
zenox: sure you can skip those, I'd try making the bootloader running an initramfs image.
<PaulFertser>
zenox: just pick any board with same soc and type of nand.
<PaulFertser>
And use the right RAM size.
<PaulFertser>
zenox: leds and buttons are easy to figure out by probing once you get basics running.
<PaulFertser>
zenox: please recheck sizes, it's a bit odd to see 128/128 device, there might be some mistake, I suggest you check the datasheets.
nlowe has joined #openwrt-devel
danitool has joined #openwrt-devel
<hauke>
PaulFertser: I probably read the same blog post you read
<zenox>
PaulFerster: I got this line from the boot logs: [ 2.504000] NAND device: Manufacturer ID: 0xc8, Chip ID: 0xd1 (Unknown NAND 128MiB 3,3V 8-bit), 128MiB, page size: 2048, OOB size: 64
<zenox>
and from /proc/meminfo: MemTotal: 124964 kB
drikus has joined #openwrt-devel
drikus has quit [Remote host closed the connection]
<PaulFertser>
zenox: verified then
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
drikus has joined #openwrt-devel
drikus has quit [Remote host closed the connection]
cmonroe has joined #openwrt-devel
drikus has joined #openwrt-devel
valku has quit [Quit: valku]
onemarcfifty has quit [Ping timeout: 480 seconds]
philipp64 has joined #openwrt-devel
drikus has joined #openwrt-devel
drikus has quit [Remote host closed the connection]
<blocktrron1>
rsalvaterra: now i got home, I'll have a look on the GPIO expander
drikus has joined #openwrt-devel
drikus has quit [Remote host closed the connection]
<blocktrron1>
i assume the can_sleep property of the gpio chip has to be set to true in order to use mutexes
zenox has quit [Remote host closed the connection]
drikus has joined #openwrt-devel
drikus has quit [Remote host closed the connection]
dedeckeh has quit [Remote host closed the connection]
jekkos has joined #openwrt-devel
jekkos has quit [Remote host closed the connection]
drikus has joined #openwrt-devel
drikus has quit [Remote host closed the connection]
rmilecki has quit [Ping timeout: 480 seconds]
drikus has joined #openwrt-devel
drikus has quit [Remote host closed the connection]
<rsalvaterra>
blocktrron1: I trust your judgement, it's not something I'm familiar with. :)
drikus has joined #openwrt-devel
drikus has quit [Remote host closed the connection]