linux.git/drivers/media/cec/core, branch v6.7

Merge drm/drm-next into drm-intel-next

2023-09-15T08:23:38+00:00

Sync to v6.6-rc1.

Signed-off-by: Jani Nikula

media: cec: core: add note about *_from_edid() function usage in drm

2023-09-01T08:59:37+00:00

In the drm subsystem, the source physical address is, in most cases,
available without having to parse the EDID again. Add notes about
preferring to use the pre-parsed address instead.

Cc: Hans Verkuil 
Cc: linux-media@vger.kernel.org
Signed-off-by: Jani Nikula 
Reviewed-by: Hans Verkuil 
Acked-by: Hans Verkuil 
Link: https://patchwork.freedesktop.org/patch/msgid/20230831105144.25923-1-jani.nikula@intel.com

media: cec-pin: only enable interrupts when monitoring the CEC pin

2023-08-10T05:58:32+00:00

The CEC interrupt is only needed if userspace wants to monitor
the CEC pin for an unconfigured CEC device. That gives it the
most precise CEC pin debugging results.

This avoids a corner case where the interrupt is enabled for
a short period when the adapter is about to be configured.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: cec-pin: improve interrupt handling

2023-08-10T05:58:32+00:00

The CEC pin framework needs a bit more control over the interrupt
handling: make sure that the disable_irq op is called even if the
device node is unregistered, log the state of the interrupt in
debugfs, and disable the interrupt when the kernel thread is stopped.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: cec: core: add adap_unconfigured() callback

2023-08-10T05:58:32+00:00

The adap_configured() callback was called with the adap->lock mutex
held if the 'configured' argument was false, and without the adap->lock
mutex held if that argument was true.

That was very confusing, and so split this up in a adap_unconfigured()
callback and a high-level configured() callback.

This also makes it easier to understand when the mutex is held: all
low-level adap_* callbacks are called with the mutex held. All other
callbacks are called without that mutex held.

Signed-off-by: Hans Verkuil 
Fixes: f1b57164305d ("media: cec: add optional adap_configured callback")
Signed-off-by: Mauro Carvalho Chehab

media: cec: core: add adap_nb_transmit_canceled() callback

2023-08-10T05:58:32+00:00

A potential deadlock was found by Zheng Zhang with a local syzkaller
instance.

The problem is that when a non-blocking CEC transmit is canceled by calling
cec_data_cancel, that in turn can call the high-level received() driver
callback, which can call cec_transmit_msg() to transmit a new message.

The cec_data_cancel() function is called with the adap->lock mutex held,
and cec_transmit_msg() tries to take that same lock.

The root cause is that the received() callback can either be used to pass
on a received message (and then adap->lock is not held), or to report a
canceled transmit (and then adap->lock is held).

This is confusing, so create a new low-level adap_nb_transmit_canceled
callback that reports back that a non-blocking transmit was canceled.

And the received() callback is only called when a message is received,
as was the case before commit f9d0ecbf56f4 ("media: cec: correctly pass
on reply results") complicated matters.

Reported-by: Zheng Zhang 
Signed-off-by: Hans Verkuil 
Fixes: f9d0ecbf56f4 ("media: cec: correctly pass on reply results")
Signed-off-by: Mauro Carvalho Chehab

media: Explicitly include correct DT includes

2023-07-19T10:57:51+00:00

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring 
Signed-off-by: Hans Verkuil

media: cec: core: don't set last_initiator if tx in progress

2023-05-26T09:52:22+00:00

When a message was received the last_initiator is set to 0xff.
This will force the signal free time for the next transmit
to that for a new initiator. However, if a new transmit is
already in progress, then don't set last_initiator, since
that's the initiator of the current transmit. Overwriting
this would cause the signal free time of a following transmit
to be that of the new initiator instead of a next transmit.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: cec: core: disable adapter in cec_devnode_unregister

2023-05-26T09:52:05+00:00

Explicitly disable the CEC adapter in cec_devnode_unregister()

Usually this does not really do anything important, but for drivers
that use the CEC pin framework this is needed to properly stop the
hrtimer. Without this a crash would happen when such a driver is
unloaded with rmmod.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: cec: core: not all messages were passed on when monitoring

2023-04-15T06:48:39+00:00

The valid_la boolean is used to check if the destination logical
address is either 15 (broadcast) or our logical address. If it is
for another logical address, then only adapters that have the
CEC_CAP_MONITOR_ALL capability can pass it on.

However, it is also used to do more detailed validity checks,
such as whether the message was broadcast when it should have been
directed, or vice versa, in which case the message must be ignored
according to the spec. But that should not apply to monitoring.

Add a new bool that just checks the LA and nothing else.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab