| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | ChanServ sets mode: +o mchehab | [01:04] |
| ................................................................................................................ (idle for 9h17mn) | ||
| mchehab | marc|gonzalez: Linux stack is very small... around 4k | [10:21] |
| .... (idle for 15mn) | ||
| marc|gonzalez | mchehab: When do you consider a struct too big for the stack? | [10:36] |
| mchehab | we usually shift from stack-allocated structs when warned during build time...
but the thing is: we should avoid using stack for structs, as they tend to grow with time | [10:38] |
| marc|gonzalez | Interesting, I never really thought about this. Why is the kernel stack so small? | [10:44] |
| mchehab | design decision | [10:45] |
| marc|gonzalez | For security?
Only one page | [10:45] |
| mchehab | it is actually configurable
could be even less than 4k | [10:45] |
| .... (idle for 17mn) | ||
| marc|gonzalez | mchehab: what's the kconfig knob for stack size?
I think kernel stack size is 8KB option for 4KB was removed a long time ago | [11:02] |
| mchehab | maybe. this changes from time to time | [11:06] |
| *** | ChanServ sets mode: +o mchehab | [11:10] |
| marc|gonzalez | mchehab: what is your size threshold for allocating on the heap vs stack? | [11:13] |
| ........................ (idle for 1h55mn) | ||
| ukleinek | marc|gonzalez: stack size also varies by architecture IIRC | [13:08] |
| marc|gonzalez | ukleinek: indeed: git grep '#define THREAD_SIZE' | [13:10] |
| ........................................ (idle for 3h19mn) | ||
| mchehab: Is "[PATCH v3] media: si2168: Refactor command setup code" OK? Is it waiting for after the merge window is closed to be reviewed? | [16:29] | |
| mchehab | didn't review yet | [16:32] |
| also, usually, syoung does the review for dvb patches nowadays | [16:40] | |
| .............. (idle for 1h8mn) | ||
| ukleinek | marc|gonzalez: link to your patch? Maybe it affects what I plan to do? | [17:48] |
| ....... (idle for 34mn) | ||
| b-rad | different ukleinek, i got busy but i'll look up your issue now real quick | [18:22] |
| .......... (idle for 47mn) | ||
| ukleinek, are you saying that merely copying the \x02 chip id command into 2157 probe fixes all your issues? | [19:09] | |
| ukleinek | b-rad: moving, not copying. Then yes | [19:19] |
| b-rad | it copied, so it's left in _init then you still get the same failure? | [19:20] |
| ukleinek | b-rad: I didn't reproduce completely, but assuming https://lkml.org/lkml/2017/10/27/503 is right, making the chip boot (command 01-01) somehow destroys the possibility to read the i2c bus
b-rad: which patch do you look at? | [19:20] |
| b-rad | not the patch, your rfc | [19:22] |
| ukleinek | https://lkml.org/lkml/2017/3/15/778 is the change I need to make the stick work
I didn't send an rfc patch | [19:22] |
| b-rad | wow, thats a hardware patch lol
[RFC] dvb: af9035.c: Logilink vg0022a to device id table that is what i've been reading | [19:23] |
| ukleinek | that I need on top to make the driver try to probe of course
That's https://lkml.org/lkml/2017/3/15/776 from Andreas Kemnade's thread. | [19:24] |
| b-rad | so the reference i have is structured similarly to the upstream driver and has no special cases for 214x | [19:26] |
| ...... (idle for 26mn) | ||
| ukleinek | b-rad: I just verified https://lkml.org/lkml/2017/10/27/503 using this patch: http://paste.debian.net/1091310/
results in: [ 81.592831] si2157 10-0063: si2168_init:547: read chip version Si2147-413330 [ 81.619394] si2157 10-0063: si2168_init:556: read chip version Si21255-ffffff | [19:52] |
| .................. (idle for 1h27mn) | ||
| b-rad: is there a command or property in the si2168 that configures an internal pullup on the SDA_MASTER line? | [21:19] | |
| b-rad | not in my reference | [21:32] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |