#
e2ed5024 |
|
17-Mar-2022 |
Hans Verkuil <hverkuil-cisco@xs4all.nl> |
media: cec: use call_op and check for !unregistered Use call_(void_)op consistently in the CEC core framework. Ditto for the cec pin ops. And check if !adap->devnode.unregistered before calling each op. This avoids calls to ops when the device has been unregistered and the underlying hardware may be gone. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
#
3813c932 |
|
03-Mar-2022 |
Hans Verkuil <hverkuil-cisco@xs4all.nl> |
media: cec: call enable_adap on s_log_addrs Don't enable/disable the adapter if the first fh is opened or the last fh is closed, instead do this when the adapter is configured or unconfigured, and also when we enter Monitor All or Monitor Pin mode for the first time or we exit the Monitor All/Pin mode for the last time. However, if needs_hpd is true, then do this when the physical address is set or cleared: in that case the adapter typically is powered by the HPD, so it really is disabled when the HPD is low. This case (needs_hpd is true) was already handled in this way, so this wasn't changed. The problem with the old behavior was that if the HPD goes low when no fh is open, and a transmit was in progress, then the adapter would be disabled, typically stopping the transmit immediately which leaves a partial message on the bus, which isn't nice and can confuse some adapters. It makes much more sense to disable it only when the adapter is unconfigured and we're not monitoring the bus, since then you really won't be using it anymore. To keep track of this store a CEC activation count and call adap_enable only when it goes from 0 to 1 or back to 0. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
#
a9e61076 |
|
01-Dec-2021 |
Hans Verkuil <hverkuil-cisco@xs4all.nl> |
media: cec: fix a deadlock situation The cec_devnode struct has a lock meant to serialize access to the fields of this struct. This lock is taken during device node (un)registration and when opening or releasing a filehandle to the device node. When the last open filehandle is closed the cec adapter might be disabled by calling the adap_enable driver callback with the devnode.lock held. However, if during that callback a message or event arrives then the driver will call one of the cec_queue_event() variants in cec-adap.c, and those will take the same devnode.lock to walk the open filehandle list. This obviously causes a deadlock. This is quite easy to reproduce with the cec-gpio driver since that uses the cec-pin framework which generated lots of events and uses a kernel thread for the processing, so when adap_enable is called the thread is still running and can generate events. But I suspect that it might also happen with other drivers if an interrupt arrives signaling e.g. a received message before adap_enable had a chance to disable the interrupts. This patch adds a new mutex to serialize access to the fhs list. When adap_enable() is called the devnode.lock mutex is held, but not devnode.lock_fhs. The event functions in cec-adap.c will now use devnode.lock_fhs instead of devnode.lock, ensuring that it is safe to call those functions from the adap_enable callback. This specific issue only happens if the last open filehandle is closed and the physical address is invalid. This is not something that happens during normal operation, but it does happen when monitoring CEC traffic (e.g. cec-ctl --monitor) with an unconfigured CEC adapter. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v5.13 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
2ddd0330 |
|
24-Nov-2021 |
Hans Verkuil <hverkuil-cisco@xs4all.nl> |
media: cec: safely unhook lists in cec_data smatch warns about data->list not being removed from list: drivers/media/cec/core/cec-adap.c:926 cec_transmit_msg_fh() warn: '&data->list' not removed from list It is a false warning, but it doesn't hurt to make the code more robust and safely unhook data->list and data->xfer_list together with a WARN_ON if this is actually ever needed (this really shouldn't happen). Note that fixing the data->list warning just replaced it with a new similar warning for data->xfer_list, so both needed to be addressed. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
4f20b7be |
|
01-Dec-2020 |
Hans Verkuil <hverkuil-cisco@xs4all.nl> |
media: cec: add EPOLLPRI in poll() when dev is unregistered If the CEC device was unregistered, then add EPOLLPRI to the poll() mask. Otherwise a select() that only waits for exceptions will not wake up. A select() that waits for read and/or write events *will* wake up on an EPOLLERR, but not (for some reason) if it just waits for exceptions. Strangly the epoll functionality will wakeup on EPOLLERR if you just wait for an exception, so in this respect select() and epoll differ. In the end it doesn't really matter, what matters is that polling file handles are woken up on device unregistration. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
6c42227c |
|
25-Jun-2020 |
Hans Verkuil <hverkuil-cisco@xs4all.nl> |
cec-api: prevent leaking memory through hole in structure Fix this smatch warning: drivers/media/cec/core/cec-api.c:156 cec_adap_g_log_addrs() warn: check that 'log_addrs' doesn't leak information (struct has a hole after 'features') Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
de73b88c |
|
15-Apr-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
media: cec: move the core to a separate directory In preparation for moving CEC drivers to the CEC directory, move the core to a separate place. Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|