| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| syoung | mchehab: my pull request is marked as accepted, but not in media_tree yet. Did you forget to push? | [15:50] |
| mchehab | maybe
or maybe I applied on a wrong local branch... that seems to be the case, actually hmm.. no... I'll check later what happened 877f1a7cee3f media: rc: mceusb: allow the timeout to be configurable 91352b572786 media: rc: mceusb: IR of length 0 means IR timeout, not reset 53a62800efb2 media: rc: mce_kbd decoder: fix race condition cb5bd0575c41 media: rc: mce_kbd decoder: remove superfluous call to input_sync 63039c29f7a4 media: rc: mce_kbd decoder: fix stuck keys 539327608dbe media: rc: mce_kbd protocol encodes two scancodes c421c62a4a08 media: rc: mce_kbd decoder: low timeout values cause double keydowns 284922562b81 media: rc: per-protocol repeat period and minimum keyup timer 95d1544eb643 media: rc: add ioctl to get the current timeout a86d6df84ae6 media: rc: set timeout to smallest value required by enabled protocols ed8c34d7ec35 media: rc: report receiver and transmitter type on device register thare are those patches from you on my local copy | [15:59] |
| syoung | yep, looks good. Thanks | [16:09] |
| mchehab | it is not upstream yet... weird
I'll check later why | [16:10] |
| syoung | thanks | [16:13] |
| ................... (idle for 1h33mn) | ||
| mchehab | syoung: should be there
there was a conflict on a temp tree I use here (locally) In order to make it more secure, I have one local bare tree... where I push everything and from there I push upstream I didn't notice a conflict on an experimental branch when I pushed to the bare tree ! [rejected] devel/compile_test_v7 -> devel/compile_test_v7 (non-fast-forward) what I do here is: $ git push && git --git-dir my_bare_tree.git/ push due to the conflict, it didn't push from the bare tree syoung: anyway, patches should be there please check | [17:46] |
| syoung | mchehab: I've checked it, looks good. Thanks! | [18:03] |
| ..... (idle for 22mn) | ||
| mchehab | great, thanks!
oh, no! something that I was afraid started to happen... people are starting to send patches to "fix" Spectre variant 1 bugs except that they have no idea about what it means nor how this could be exploited they're doing it just because a new logic at smatch started to popup warnings As described at the commit that introduced the smatch spectre analyser: Logically, you would have expected those numbers to be closer together so it probably indicates this test is very flawed. Anyway, this is a first draft.. https://git.linuxtv.org/mchehab/smatch.git/commit/?id=69e9094e11c16853fd40e3b00ca25aa041ca8733 hverkuil, pinchartl, sailus, syoung: please be grumpy when people start sending "spectre" fix patches I don't discard that some things would be vulnerable to it, but the one sending us a patch should provide us some explanation to convince us about the need... as spectre mitigation made by some script kid usually means: "let's slow down the Kernel... just in case" | [18:25] |
| *** | ChanServ sets mode: +v mchehab` | [18:44] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |