BMC/Intel-BMC/linux.git/drivers/media/cec, branch dev-4.18

media: cec: forgot to cancel delayed work

2018-11-13T19:12:50+00:00

commit 490d84f6d73c12f4204241cff8651eed60aae914 upstream. If the wait for completion was interrupted, then make sure to cancel any delayed work. This can only happen if a transmit is waiting for a reply, and you press Ctrl-C or reboot/poweroff or something like that which interrupts the thread waiting for the reply and then proceeds to delete the CEC message. Since the delayed work wasn't canceled, once it would trigger it referred to stale data and resulted in a kernel oops. Fixes: 7ec2b3b941a6 ("cec: add new tx/rx status bits to detect aborts/timeouts") Signed-off-by: Hans Verkuil Cc: # for v4.18 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: cec: fix the Signal Free Time calculation

2018-11-13T19:12:50+00:00

commit 7d867a1b765e2b70815fec4964d7822a976ed349 upstream. The calculation of the Signal Free Time in the framework was not correct. If a message was received, then the next transmit should be considered a New Initiator and use a shorter SFT value. This was not done with the result that if both sides where continually sending messages, they both could use the same SFT value and one side could deny the other side access to the bus. Note that this fix does not take the corner case into account where a receive is in progress when you call adap_transmit. Signed-off-by: Hans Verkuil Cc: # for v4.18 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: cec: add new tx/rx status bits to detect aborts/timeouts

2018-11-13T19:12:49+00:00

commit 7ec2b3b941a666a942859684281b5f6460a0c234 upstream. If the HDMI cable is disconnected or the CEC adapter is manually unconfigured, then all pending transmits and wait-for-replies are aborted. Signal this with new status bits (CEC_RX/TX_STATUS_ABORTED). If due to (usually) a driver bug a transmit never ends (i.e. the transmit_done was never called by the driver), then when this times out the message is marked with CEC_TX_STATUS_TIMEOUT. This should not happen and is an indication of a driver bug. Without a separate status bit for this it was impossible to detect this from userspace. The 'transmit timed out' kernel message is now a warning, so this should be more prominent in the kernel log as well. Signed-off-by: Hans Verkuil Cc: # for v4.18 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: cec: integrate cec_validate_phys_addr() in cec-api.c

2018-11-13T19:12:49+00:00

commit e81bff39489a06384822bb38ce7a59f9e365bbe9 upstream. The cec_phys_addr_validate() function will be moved to V4L2, so use a simplified variant of that function in cec-api.c. cec now no longer calls cec_phys_addr_validate() and it can be safely moved to V4L2. Signed-off-by: Hans Verkuil Cc: # for v4.17 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: cec: make cec_get_edid_spa_location() an inline function

2018-11-13T19:12:49+00:00

commit b915bf575d5b7774d0f22d57d6c143e07dcaade2 upstream. This function is needed by both V4L2 and CEC, so move this to cec.h as a static inline since there are no obvious shared modules between the two subsystems. This patch, together with the following ones, fixes a dependency bug: if CEC_CORE is disabled, then building adv7604 (and other HDMI receivers) will fail because an essential function is now stubbed out. Signed-off-by: Hans Verkuil Cc: # for v4.17 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: cec: fix wrong tx/rx_status values when canceling a msg

2018-05-28T20:25:25+00:00

When a message was canceled it could return tx_status with both OK and MAX_RETRIES set, which is illegal. If a canceled message was waiting for a reply, then rx_status wasn't updated, so set that as well. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: cec-pin-error-inj: avoid a false-positive Spectre detection

2018-05-28T20:11:17+00:00

The current logic makes Smatch to false-detect a Spectre variant 1 vulnerability. The problem is that it initializes an u32 indirectly from user space input. After trying to write a fixup, after a while I realized that, in practice, this shouldn't be a problem, as an u32 is initialized from u8, but it took some time to discover it. So, do some code cleanup to make it clearer for both humans and machines about the valid range for "op". Fix this warning: drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() warn: potential spectre issue 'pin->error_inj_args' Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: rc: per-protocol repeat period and minimum keyup timer

2018-04-20T13:16:55+00:00

Each IR protocol has its own repeat period. We can minimise the keyup timer to be the protocol period + IR timeout. This makes keys less "sticky" and makes IR more reactive and nicer to use. This feature was previously attempted in commit d57ea877af38 ("media: rc: per-protocol repeat period"), but that did not take the IR timeout into account, and had to be reverted. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab

media: cec: set ev rather than v with CEC_PIN_EVENT_FL_DROPPED bit

2018-04-20T12:37:35+00:00

Setting v with the CEC_PIN_EVENT_FL_DROPPED is incorrect, instead ev should be set with this bit. Fix this. Detected by CoverityScan, CID#1467974 ("Extra high-order bits") Fixes: 6ec1cbf6b125 ("media: cec: improve CEC pin event handling") Signed-off-by: Colin Ian King Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: cec: fix smatch error

2018-04-17T09:49:59+00:00

drivers/media/cec/cec-pin-error-inj.c:231 cec_pin_error_inj_parse_line() error: uninitialized symbol 'pos'. The tx-add-bytes command didn't check for the presence of an argument, and also didn't check that it was > 0. This should fix this error. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab