cron job: media_tree daily build: ERRORS

2018-07-28 Thread Hans Verkuil
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Sun Jul 29 05:00:09 CEST 2018
media-tree git hash:4faeaf9c0f4581667ce5826f9c90c4fd463ef086
media_build git hash:   124c3e4ad8d4408c53cbda100d2bf91bb56ffdf0
v4l-utils git hash: 5e8d31abc6f531ef0bc0fc563d5311602a395685
edid-decode git hash:   ab18befbcacd6cd4dff63faa82e32700369d6f25
gcc version:i686-linux-gcc (GCC) 8.1.0
sparse version: 0.5.2
smatch version: 0.5.1
host hardware:  x86_64
host os:4.16.0-1-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-i686: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
Check COMPILE_TEST: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.101-i686: ERRORS
linux-3.0.101-x86_64: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.102-i686: ERRORS
linux-3.2.102-x86_64: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.113-i686: ERRORS
linux-3.4.113-x86_64: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.10-i686: ERRORS
linux-3.7.10-x86_64: ERRORS
linux-3.8.13-i686: ERRORS
linux-3.8.13-x86_64: ERRORS
linux-3.9.11-i686: ERRORS
linux-3.9.11-x86_64: ERRORS
linux-3.10.108-i686: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.57-i686: OK
linux-3.16.57-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.115-i686: OK
linux-3.18.115-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.52-i686: OK
linux-4.1.52-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.140-i686: OK
linux-4.4.140-x86_64: OK
linux-4.5.7-i686: OK
linux-4.5.7-x86_64: OK
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: OK
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: OK
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: OK
linux-4.9.112-i686: OK
linux-4.9.112-x86_64: OK
linux-4.10.17-i686: OK
linux-4.10.17-x86_64: OK
linux-4.11.12-i686: OK
linux-4.11.12-x86_64: OK
linux-4.12.14-i686: OK
linux-4.12.14-x86_64: OK
linux-4.13.16-i686: OK
linux-4.13.16-x86_64: OK
linux-4.14.55-i686: OK
linux-4.14.55-x86_64: OK
linux-4.15.18-i686: OK
linux-4.15.18-x86_64: OK
linux-4.16.18-i686: OK
linux-4.16.18-x86_64: OK
linux-4.17.6-i686: OK
linux-4.17.6-x86_64: OK
linux-4.18-rc4-i686: OK
linux-4.18-rc4-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


[RFC PATCH] media: rc: repeat_period() can be static

2018-07-28 Thread kbuild test robot


Fixes: f52e85dbaa91 ("media: rc: read out of bounds if bpf reports high 
protocol number")
Signed-off-by: kbuild test robot 
---
 rc-main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index a24850b..ca68e1d 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -679,7 +679,7 @@ static void ir_timer_repeat(struct timer_list *t)
spin_unlock_irqrestore(>keylock, flags);
 }
 
-unsigned int repeat_period(int protocol)
+static unsigned int repeat_period(int protocol)
 {
if (protocol >= ARRAY_SIZE(protocols))
return 100;


Re: [PATCH] media: rc: read out of bounds if bpf reports high protocol number

2018-07-28 Thread kbuild test robot
Hi Sean,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.18-rc6 next-20180727]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sean-Young/media-rc-read-out-of-bounds-if-bpf-reports-high-protocol-number/20180729-035942
base:   git://linuxtv.org/media_tree.git master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/media/rc/rc-main.c:682:14: sparse: symbol 'repeat_period' was not 
>> declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


[PATCH] media: i2c: fix warning in Aptina MT9V111

2018-07-28 Thread Jasmin J.
From: Jasmin Jessich 

This fixes the "'idx' may be used uninitialized in this function"
warning.

Cc:  Jacopo Mondi 
Signed-off-by: Jasmin Jessich 
---
 drivers/media/i2c/mt9v111.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/mt9v111.c b/drivers/media/i2c/mt9v111.c
index da8f6ab..58d5f22 100644
--- a/drivers/media/i2c/mt9v111.c
+++ b/drivers/media/i2c/mt9v111.c
@@ -884,7 +884,7 @@ static int mt9v111_set_format(struct v4l2_subdev *subdev,
struct v4l2_mbus_framefmt new_fmt;
struct v4l2_mbus_framefmt *__fmt;
unsigned int best_fit = ~0L;
-   unsigned int idx;
+   unsigned int idx = 0;
unsigned int i;
 
mutex_lock(>stream_mutex);
-- 
2.7.4



[no subject]

2018-07-28 Thread Andrew Martinez



Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere 
Informationen

Do you need a loan of any kind? If Yes email us now for more info

[no subject]

2018-07-28 Thread Andrew Martinez



Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere 
Informationen

Do you need a loan of any kind? If Yes email us now for more info

Re: [PATCH v3 0/5] Add BPF decoders to ir-keytable

2018-07-28 Thread Sean Young
Hi Hias,

On Sat, Jul 21, 2018 at 08:13:27PM +0200, Matthias Reichl wrote:
> Hi Sean,
> 
> thanks a lot, this is a really nice new feature!

Thank you for testing it and finding all those issues, it has become much
better from your testing.

> On Fri, Jul 13, 2018 at 03:30:06PM +0100, Sean Young wrote:
> > Once kernel v4.18 is released with IR BPF decoding, this can be merged
> > to v4l-utils.
> > 
> > The idea is that IR decoders can be written in C, compiled to BPF 
> > relocatable
> > object file. Any global variables can overriden, so we can supports lots
> > of variants of similiar protocols (just like in the lircd.conf file).
> > 
> > The existing rc_keymap file format can't be used for variables, so I've
> > converted the format to toml. An alternative would be to use the existing
> > lircd.conf file format, but it's a very awkward file to parse in C and it
> > contains many features which are irrelevant to us.
> > 
> > We use libelf to load the bpf relocatable object file.
> > 
> > After loading our example grundig keymap with bpf decoder, the output of
> > ir-keytable is:
> > 
> > Found /sys/class/rc/rc0/ (/dev/input/event8) with:
> > Name: Winbond CIR
> > Driver: winbond-cir, table: rc-rc6-mce
> > LIRC device: /dev/lirc0
> > Attached BPF protocols: grundig
> > Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo 
> > mce_kbd rc-6 sharp xmp imon
> > Enabled protocols: lirc
> > bus: 25, vendor/product: 10ad:00f1, version: 0x0004
> > Repeat delay = 500 ms, repeat period = 125 ms
> > 
> > Alternatively, you simply specify the path to the object file on the command
> > line:
> > 
> > $ ir-keytable -e header_pulse=9000,header_space=4500 -p ./pulse_distance.o
> > 
> > Derek, please note that you can now convert the dish lircd.conf to toml
> > and load the keymap; it should just work. It would be great to have your
> > feedback, thank you.
> 
> I did a few tests with one of my RC-5 remotes, this lircd.conf file
> https://github.com/PiSupply/JustBoom/blob/master/LIRC/lircd.conf
> and kernel 4.18-rc5 on RPi2, with the 32bit ARM kernel and
> gpio-ir-recv, and on LePotato / aarch64 with meson-ir.
> 
> lircd2toml.py did a really good job on converting it, the only
> thing missing was the toggle_bit.

Right, there was a bug in lirc2html.py. I've added a fix to my bpf branch:

https://git.linuxtv.org/syoung/v4l-utils.git/log/?h=bpf

> When testing the converted toml (with "toggle_bit = 11" added
> and the obvious volume keycode fixes) I noticed a couple of issues:
> 
> Buttons seem to be "stuck". The scancode is decoded, key_down
> event is generated, but after release the key_down events repeat
> indefinitely - with the built-in rc-5 decoder this works fine.
> 
> root@upstream:/home/hias/ir-test# ir-keytable -c -w justboom.toml -t
> Old keytable cleared
> Wrote 12 keycode(s) to driver
> Protocols changed to
> Loaded BPF protocol manchester
> Testing events. Please, press CTRL-C to abort.
> 29.065820: lirc protocol(66): scancode = 0x141b
> 29.065890: event type EV_MSC(0x04): scancode = 0x141b
> 29.065890: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
> 29.065890: event type EV_SYN(0x00).
> 29.570059: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
> 29.570059: event type EV_SYN(0x00).
> 29.710062: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
> 29.710062: event type EV_SYN(0x00).
> 29.850057: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
> 29.850057: event type EV_SYN(0x00).
> 29.990057: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
> 29.990057: event type EV_SYN(0x00).
> 30.130055: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
> 30.130055: event type EV_SYN(0x00).
> ...

Thanks, I had not seen this yet either. There is a fix here:

https://www.mail-archive.com/linux-media@vger.kernel.org/msg133813.html

> Even scancodes, eg KEY_UP / scancode 0x141a, aren't decoded at
> all, only odd scancodes work. My guess is the manchester decoder
> could have a problem when the last bit is zero and the message
> doesn't end with a pulse, but a (rather long) timeout.

Yep, yet another bug! I'v added a fix here:

https://git.linuxtv.org/syoung/v4l-utils.git/log/?h=bpf

> (Re-)loading a bpf decoder only works 8 times. The 9th attempt
> gives an error message.
> 
> # for i in `seq 1 9` ; do ir-keytable -p manchester ; done
> Protocols changed to
> Loaded BPF protocol manchester
> Protocols changed to
> Loaded BPF protocol manchester
> Protocols changed to
> Loaded BPF protocol manchester
> Protocols changed to
> Loaded BPF protocol manchester
> Protocols changed to
> Loaded BPF protocol manchester
> Protocols changed to
> Loaded BPF protocol manchester
> Protocols changed to
> Loaded BPF protocol manchester
> Protocols changed to
> Loaded BPF protocol manchester
> Protocols changed to
> failed to create a map: 1 Operation not permitted
> Loaded BPF protocol manchester

There was a bug where bpf programs were leaked on 

Do you Need A Helping Hand?

2018-07-28 Thread irivera
 

-- 

I am Mavis Wanczyk i know you may not know me but am the latest largest
US Powerball lottery winner of $758.7m just of recent, am currently
helping out people in need of financial assistance, i know it's hard to
believe anything on the internet, so if you don't need my help please
don't reply to this message. 

Regards 
Mavis Wanczyk 

[PATCH] media: rc: read out of bounds if bpf reports high protocol number

2018-07-28 Thread Sean Young
The repeat period is read from a static array. If a keydown event is
reported from bpf with a high protocol number, we read out of bounds. This
is unlikely to end up with a reasonable repeat period at the best of times,
in which case no timely key up event is generated.

Signed-off-by: Sean Young 
---
 drivers/media/rc/rc-main.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 2e222d9ee01f..a24850be1f4f 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -679,6 +679,14 @@ static void ir_timer_repeat(struct timer_list *t)
spin_unlock_irqrestore(>keylock, flags);
 }
 
+unsigned int repeat_period(int protocol)
+{
+   if (protocol >= ARRAY_SIZE(protocols))
+   return 100;
+
+   return protocols[protocol].repeat_period;
+}
+
 /**
  * rc_repeat() - signals that a key is still pressed
  * @dev:   the struct rc_dev descriptor of the device
@@ -691,7 +699,7 @@ void rc_repeat(struct rc_dev *dev)
 {
unsigned long flags;
unsigned int timeout = nsecs_to_jiffies(dev->timeout) +
-   msecs_to_jiffies(protocols[dev->last_protocol].repeat_period);
+   msecs_to_jiffies(repeat_period(dev->last_protocol));
struct lirc_scancode sc = {
.scancode = dev->last_scancode, .rc_proto = dev->last_protocol,
.keycode = dev->keypressed ? dev->last_keycode : KEY_RESERVED,
@@ -803,7 +811,7 @@ void rc_keydown(struct rc_dev *dev, enum rc_proto protocol, 
u32 scancode,
 
if (dev->keypressed) {
dev->keyup_jiffies = jiffies + nsecs_to_jiffies(dev->timeout) +
-   msecs_to_jiffies(protocols[protocol].repeat_period);
+   msecs_to_jiffies(repeat_period(protocol));
mod_timer(>timer_keyup, dev->keyup_jiffies);
}
spin_unlock_irqrestore(>keylock, flags);
-- 
2.17.1