Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
Jurting has quit [Remote host closed the connection]
aisa has joined #qi-hardware
urandom__ has quit [Quit: Konversation terminated!]
heberth has quit [Quit: leaving]
xiangfu has joined #qi-hardware
freakazoid0223 has joined #qi-hardware
nikescar has quit [Read error: Connection reset by peer]
nikescar has joined #qi-hardware
akiwiguy has joined #qi-hardware
akiwiguy has left #qi-hardware [#qi-hardware]
aisa has quit [Quit: leaving]
scientes has joined #qi-hardware
DocScrutinizer05 has joined #qi-hardware
DocScrutinizer06 has quit [Ping timeout: 252 seconds]
<larsc>
good question, any idea why it didn't make it?
<mth>
no idea, I just noticed that when cherry-picking all 3.5 commits into 3.6 this one didn't end up empty
<larsc>
the line is in the commit though, just at a different position
<mth>
ah, git failed to detect that then
<larsc>
I guess Ralf reordered it
<mth>
anyway, thanks for looking at it
jluis has quit [Ping timeout: 245 seconds]
jluis has joined #qi-hardware
<mth>
larsc, kyak, xiangfu: I pushed the jz-3.6 branch to qi-kernel
<mth>
as always, tested on A320, builds for Nanonote but not tested there
<mth>
the board-qi_lb60.c might need an update for the pwm beeper
<mth>
see ad8f4827 for the update on board-a320.c for an example
<mth>
the pwm device is already added for the NN, but the new-style mapping is not
<viric>
the board has a pwm beeper?
cladamw has joined #qi-hardware
<mth>
"static struct platform_device qi_lb60_pwm_beeper" says it does :)
<viric>
nice :)
<whitequark>
DocScrutinizer05: what do you think about Jolla?
<larsc>
mth: thanks
<larsc>
viric: yes. try to enter beep on the console
<viric>
but is that separate from the speaker?
<viric>
(I don't have the NN at hand)
<xiangfu>
mth, thanks. I will test it on nanonote.
<larsc>
viric: yes
<larsc>
there is a piezo
<viric>
ahh
<viric>
interesting :)
xiangfu has quit [Ping timeout: 246 seconds]
Hoolxi has joined #qi-hardware
xiangfu has joined #qi-hardware
aisa has joined #qi-hardware
<pabs3>
whitequark: yawn
freemor has joined #qi-hardware
kristoffer has joined #qi-hardware
xiangfu has quit [Quit: Leaving]
<whitequark>
pabs3: huh?
Hoolxi has quit [Remote host closed the connection]
paul_boddie has joined #qi-hardware
<paul_boddie>
Does anyone want to answer a stupid Linux kernel programming question?
urandom__ has joined #qi-hardware
<kyak>
mth: thanks!
<paul_boddie>
OK, well, I'll ask it anyway and see if anyone has any opinion. It's actually about that USB/IP kernel module I mentioned before. That module appears to obtain a socket from a process using its file descriptor table, and I've been trying to obtain a usable "struct file" instead using fget, in order to use it with a tty character device file.
lekernel_ has joined #qi-hardware
lekernel has quit [Ping timeout: 246 seconds]
<paul_boddie>
So, is it possible to obtain a usable "struct file" and use it to write to a character device within the kernel using, say, vfs_write? I do the set_fs magic but still get EFAULT.
lekernel_ is now known as lekernel
cladamw has quit [Quit: Ex-Chat]
lekernel_ has joined #qi-hardware
lekernel has quit [Ping timeout: 256 seconds]
<larsc>
paul_boddie: yes ;)
<kyak>
mth: jz-3.6 boots with Nanonote :)
<mth>
does the beeper still work?
<paul_boddie>
It's weird because I do fget, which should give me the file object that I need to actually write something, and I do the set_fs(KERNEL_DS) stuff to stop the address validation, but I start to wonder whether there are memory allocation issues that I haven't thought about, even though the socket-based stuff appears to use stack-allocated memory and synchronous I/O.
<kyak>
the beeper doesn't work, but i didn't modify the board.c
<larsc>
kyak: it should work without modifing it
<kyak>
something must be wrong with config options.. proc is not mounted
<larsc>
kyak: your init is probably not /etc/preinit
<paul_boddie>
And it's quite hard to find a discussion about this on the Internet because everyone is wailing "Don't open files in the kernel!" (I'm not) and pointing to a 2005 article about doing bad things in the kernel.
<viric>
I never understood the openwrt game on the 'init' path
<larsc>
paul_boddie: what exactly are you trying to do?
<kyak>
larsc: should i patch the kernel to use /etc/preinit or modify the cmdline in uboot?
<larsc>
kyak: both is possible
<larsc>
and should work
<larsc>
if you have serial access to uboot it should be faster
<viric>
why are the openwrt people not using the usual init paths?
<larsc>
good question
<viric>
I find it annoying :)
lekernel_ is now known as lekernel
<paul_boddie>
Doesn't the stock NanoNote bootloader specify /etc/preinit?
<kyak>
larsc: fixed the problem with init, still it doesn't beep
<kyak>
paul_boddie: interestingly, not. I guess it relies on the kernel patch
<paul_boddie>
kyak: I couldn't remember where the setting got applied, but I found that the Debian userland obviously wouldn't work without some preinit "glue".
<kyak>
larsc: after fixing init stuff, i don't need CONFIG_DEVTMPFS :)
emeb has joined #qi-hardware
<larsc>
kyak: what's the output of /sys/bus/platform/{devices,drivers}?
<larsc>
Is CONFIG_PWM_BEEPER enabled in your config?
<paul_boddie>
larsc: I'm trying to get the usbip driver to talk over a serial device instead of a socket.
<larsc>
so you want to do usb over serial?
<paul_boddie>
Well, if it works over TCP/IP, why not over something behaving like a serial line?
<mth>
larsc: we don't have "IS_ENABLED(CONFIG_PWM)" in include/linux/pwm.h, so perhaps another patch is missing too?
<paul_boddie>
I actually thought the modifications would be relatively trivial, but I think I must have underestimated the Linux kernel's capacity to infuriate again.
<larsc>
paul_boddie: I'd expect it to work to. where do you get the fd from, do you pass it in from userspace?
<paul_boddie>
So, the usbip driver does a scanf on some integers written to a sysfs file. It then does an fget to get a "struct file" and then tests for a socket before calling SOCKET_I on the inode of the file.
<paul_boddie>
On being written. The socket is opened in user space and the sysfs file/attribute is used to tell the kernel/module to take over.
<larsc>
ok, i guess that could work, but still. and you kept the same behaviour and just skipped the socket part
<paul_boddie>
Yes, I use fget but don't do any "conversion" to a socket. I suspect that there's something in the socket handling that allows this module to use kernel-allocated memory because there's no set_fs stuff in that module at all.
<paul_boddie>
I'm open to better suggestions about how this could be done, but I understand how it probably came about.
<larsc>
I don't think you need set_fs if you are already in kernel space
<larsc>
-EFAULT would suggest that you don't have premission to read the memory area you want to write to the console
<paul_boddie>
There's precious little (coherent) documentation about this, at least on the Internet.
<larsc>
can you paste your diff somewhere?
<paul_boddie>
Yes, in fact before getting EFAULT, I found that I was actually causing an "oops" or backtrace, but I think that was because I was using __user pointers directly with kernel addresses.
<paul_boddie>
I'll try and paste a diff later on. Currently, I'm not where my diff actually is. :-)
<larsc>
__user is just a hint for the compiler
<paul_boddie>
I'm either missing something super-obvious or there's a more serious issue.
kyak has quit []
<paul_boddie>
What I found was that the vfs functions all seem to need __user pointers at some level, but in this case all work is being done in the kernel and there's no user space client.
pcercuei has joined #qi-hardware
<paul_boddie>
Maybe we should port the HURD to the NanoNote. :-)
kyak has joined #qi-hardware
kyak has quit [Changing host]
kyak has joined #qi-hardware
<DocScrutinizer05>
whitequark: (jolla) they don't get the catch to hire me - what can I say ;-P
<DocScrutinizer05>
prolly they'll buy some cheap chinese phone and rebrand it ;-)
<paul_boddie>
Don't reveal Nokia's eventual business model to us! ;-)
<paul_boddie>
There must be something really stupidly obvious I'm doing wrong, but I don't see it!
Hoolxi has joined #qi-hardware
<paul_boddie>
Maybe I should open a normal file and pass a descriptor for that. I did try opening the device file in the kernel itself, but that didn't change anything.
LunaVorax_ has joined #qi-hardware
heberth has quit [Quit: leaving]
LunaVorax has quit [Ping timeout: 256 seconds]
<paul_boddie>
Just tried with a normal file, and that didn't fault, so maybe something is happening in the driver behind the serial device.
pcercuei has quit [Quit: go!]
<paul_boddie>
Actually, I think a normal file doesn't seem to exercise the writing code, but it does attempt a read, gets zero bytes, and then the driver pronounces it a "disconnect".