Reported as a Kaffeine bug:
	https://bugs.kde.org/show_bug.cgi?id=375811

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

On Kernel 4.9, the default is to not accept DMA on stack anymore
on x86 architecture. On other architectures, this has been a
requirement since Kernel 2.2. So, after this patch, this driver
should likely work fine on all archs.

Tested with USB ID 2040:5510: Hauppauge Windham

Cc: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Poll messages that are used to allocate a logical address should
use the same initiator as the destination. Instead, it expected that
the initiator was 0xf which is not according to the standard.

This also had consequences for the message checks in cec_transmit_msg_fh
that incorrectly rejected poll messages with the same initiator and
destination.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Due to an incorrect condition the last_la used for the initial attempt at
claiming a logical address could be wrong.

The last_la wasn't converted to a mask when ANDing with type2mask, so that
test was broken.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

A rare randconfig build failure shows up in this driver when
the CRC32 helper is not there:

drivers/media/built-in.o: In function `s5k4ecgx_s_power':
s5k4ecgx.c:(.text+0x9eb4): undefined reference to `crc32_le'

This adds the 'select' that all other users of this function have.

Fixes: 8b99312b ("[media] Add v4l2 subdev driver for S5K4ECGX sensor")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

With gcc-5 or higher on x86, we can get a bogus warning in the
dvb-net code:

drivers/media/dvb-core/dvb_net.c: In function 'dvb_net_ule':
arch/x86/include/asm/string_32.h:78:22: error: '*((void *)&dest_addr+4)' may be used uninitialized in this function [-Werror=maybe-uninitialized]

The problem here is that gcc doesn't track all of the conditions
to prove it can't end up copying uninitialized data.
This changes the logic around so we zero out the destination
address earlier when we determine that it is not set here.
This allows the compiler to figure it out.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The s_stream() handler incorrectly writes the whole MISC_CTL register to
enable or disable the outputs, overriding the output pinmuxing
configuration. Fix it to only touch the output enable bits.

The CONF_SHARED_PIN register is also written by the same function,
resulting in muxing the INTREQ signal instead of the VBLK/GPCL signal on
the INTREQ/GPCL/VBLK pin. As the driver doesn't support interrupts this
is obviously incorrect, and breaks operation on other devices. Fix it by
removing the write.

Cc: stable@vger.kernel.org # For Kernel	4.5 and	upper
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The FID/GLCO/VLK/HVLK and INTREQ/GPCL/VBLK pins are muxed differently
depending on whether the input is an S-Video or composite signal. The
comment that explains the logic doesn't reflect the code. It appears
that the comment is incorrect, as disabling the output data bus in
composite mode makes no sense. Update the comment to match the code.

While at it define macros for the MISC_CTL register bits, the code is
too confusing with numerical values.

Cc: stable@vger.kernel.org # For Kernel	4.5 and	upper
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The tvp5150 doesn't support format setting through the subdev pad API
and thus implements the set format handler as a get format operation.
The single handler, tvp5150_fill_fmt(), resets the device by calling
tvp5150_reset(). This causes malfunction as the device can be reset at
will, possibly from userspace when the subdev userspace API is enabled.

The reset call was added in commit ec2c4f3f ("[media] media:
tvp5150: Add mbus_fmt callbacks"), probably as an attempt to set the
device to a known state before detecting the current TV standard.
However, the get format handler doesn't access the hardware to get the
TV standard since commit 963ddc63 ("[media] media: tvp5150: Add
cropping support"). There is thus no need to reset the device when
getting the format.

However, removing the tvp5150_reset() from the get/set format handlers
results in the function not being called at all if the bridge driver
doesn't use the .reset() operation. The operation is nowadays abused and
shouldn't be used, so shouldn't expect bridge drivers to call it. To
make sure the device is properly initialize, move the reset call from
the format handlers to the probe function.

Cc: stable@vger.kernel.org # For Kernel 4.5 and upper
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

commit 73d5c5c8 ("[media] pctv452e: don't do DMA on stack") caused
a NULL pointer dereference which occurs when dvb_usb_init()
calls dvb_usb_device_power_ctrl() for the first time, before the
frontend has been attached. It also caused a recursive deadlock because
tt3650_ci_msg_locked() has already locked the mutex.

So, partially revert it, but move the buffer to the heap
(DMA capable), not to the stack (may not be DMA capable).
Instead of sharing one buffer which needs mutex protection,
do a new heap allocation for each call.

Fixes: commit 73d5c5c8 ("[media] pctv452e: don't do DMA on stack")

Cc: stable@vger.kernel.org # For Kernel 4.9
Signed-off-by: NMax Kellermann <max.kellermann@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Simply the interrupt setup by using the new PCI layer helpers.

Despite using pci_enable_msi_range, this driver was only requesting a
single MSI vector anyway.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

This race was discovered by running cec-compliance -A with the cec module debug
parameter set to 2: suddenly the test would fail.

It turns out that this happens when the test configures the adapter in
non-blocking mode, then it waits for the CEC_EVENT_STATE_CHANGE event and once
the event is received it unconfigures the adapter.

What happened was that the unconfigure was executed while the configure was
still transmitting the Report Features and Report Physical Address messages.
This messed up the internal state of the cec_adapter.

The fix is to transmit those messages with the adap->lock mutex held (this will
just queue them up in the internal transmit queue, and not actually transmit
anything yet). Only unlock the mutex once everything is done. The main thread
will dequeue the messages from the internal transmit queue and transmit them
one by one, unless an unconfigure was done, and in that case any messages are
just dropped.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

It's only a small function and this makes it easier to switch to
transmitting the message with adap->lock held in the next patch.
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The fill function just fills in the cec_msg struct, it doesn't transmit
the message. This is now done explicitly.

This makes it possible to switch to transmitting this message with adap->lock
held.
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The loop that sets the unused logical addresses to INVALID should be
done before 'configured' is set to true. This ensures that cec_log_addrs
is consistent before it will be used.
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

This is a 2.0 only message, so it should return Feature Abort if the
adapter is configured for CEC version 1.4.

Right now it does nothing, which means that the sender will time out.
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

When a pending message was canceled (e.g. due to a timeout), then the
old tx_status info was overwritten instead of ORed. The same happened
with the tx_error_cnt field. So just modify them instead of overwriting
them.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

In the (very) small print of the REPORT_CURRENT_LATENCY message there is a
line that says that the last byte of the message (audio out delay) is only
present if the 'audio out compensated' value is 3.

I missed this, and so if this message was sent with a total length of 6 (i.e.
without the audio out delay byte), then it was rejected by the framework
since a minimum length of 7 was expected.

Fix this minimum length check and update the wrappers in cec-funcs.h to do
the right thing based on the message length.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The smiapp_suspend() and smiapp_resume() functions will end up being unused
if CONFIG_PM is enabled but CONFIG_PM_SLEEP is disabled, causing a
compiler warning from both of the function definitions. Fix this by
marking the functions with __maybe_unused.
Suggested-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Power on the sensor when the module is loaded and power it off when it is
removed.
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

A break is missing resulting in the hue control enabling or disabling
the decode completely. Fix it.

Fixes: c43875f6 ("[media] tvp5150: replace MEDIA_ENT_F_CONN_TEST by a control")

Cc: stable@vger.kernel.org
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The function is large and called in several places, don't inline it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The function is only referenced as a handler in the tvp5150_sd_media_ops
structure, which is only used when CONFIG_MEDIA_CONTROLLER is set. Don't
define the function and the structure when the configuration option is
unset to avoid an unused function warning.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Now that we're storing usb_interface at em28xx struct,
there's no good reason to keep storing usb_device, as we can
get it from usb_interface. So, get rid of it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The usb_device->dev is not the right device for dev_foo() calls.
Instead, it should use usb_interface->dev.
Tested-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Changing the device name, causes it to be unable to remove the
sysfs file, causing troubles if a device is removed and then
re-inserted.

[ 1010.310320] WARNING: CPU: 3 PID: 119 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x7b/0x90
[ 1010.310323] sysfs: cannot create duplicate filename '/bus/usb/devices/1-3.3'
[ 1010.310325] Modules linked in: lgdt330x em28xx_dvb dvb_core em28xx_alsa tuner_xc2028 tuner tvp5150 em28xx_v4l videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core em28xx tveeprom v4l2_common videodev media xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables cmac bnep cpufreq_powersave cpufreq_conservative cpufreq_userspace binfmt_misc parport_pc ppdev lp parport snd_hda_codec_hdmi iTCO_wdt snd_hda_codec_realtek iTCO_vendor_support snd_hda_codec_generic arc4 intel_rapl x86_pkg_temp_thermal iwlmvm intel_powerclamp coretemp kvm_intel mac80211 kvm i915
[ 1010.310383]  irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel iwlwifi pl2303 aesni_intel btusb aes_x86_64 usbserial lrw btrtl gf128mul glue_helper btbcm ablk_helper cryptd btintel bluetooth drm_kms_helper cfg80211 drm psmouse pcspkr i2c_i801 e1000e serio_raw snd_hda_intel snd_soc_rt5640 snd_hda_codec snd_soc_rl6231 snd_soc_ssm4567 mei_me i2c_smbus rfkill snd_hda_core ptp mei snd_soc_core ehci_pci sg lpc_ich shpchp mfd_core ehci_hcd pps_core snd_hwdep i2c_algo_bit snd_compress snd_pcm sdhci_acpi snd_timer battery snd sdhci elan_i2c snd_soc_sst_acpi mmc_core fjes dw_dmac i2c_hid soundcore snd_soc_sst_match i2c_designware_platform video i2c_designware_core acpi_pad acpi_als kfifo_buf tpm_tis button industrialio tpm_tis_core tpm ext4 crc16 jbd2 fscrypto mbcache dm_mod joydev evdev hid_logitech_hidpp
[ 1010.310449]  sd_mod hid_logitech_dj usbhid hid ahci libahci crc32c_intel libata xhci_pci xhci_hcd scsi_mod usbcore fan thermal
[ 1010.310464] CPU: 3 PID: 119 Comm: kworker/3:2 Not tainted 4.9.0-rc8+ #14
[ 1010.310466] Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
[ 1010.310487] Workqueue: usb_hub_wq hub_event [usbcore]
[ 1010.310490]  0000000000000000 ffffffff848f56c5 ffff8803b1f7f858 0000000000000000
[ 1010.310496]  ffffffff8414f8f8 ffff88030000001f ffffed00763eff07 ffff8803b1f7f8f0
[ 1010.310501]  ffff8803b3ea1e60 0000000000000001 ffffffffffffffef ffff8803b45c6840
[ 1010.310505] Call Trace:
[ 1010.310517]  [<ffffffff848f56c5>] ? dump_stack+0x5c/0x77
[ 1010.310522]  [<ffffffff8414f8f8>] ? __warn+0x168/0x1a0
[ 1010.310526]  [<ffffffff8414f9e4>] ? warn_slowpath_fmt+0xb4/0xf0
[ 1010.310529]  [<ffffffff8414f930>] ? __warn+0x1a0/0x1a0
[ 1010.310534]  [<ffffffff845436c6>] ? kasan_kmalloc+0xa6/0xd0
[ 1010.310539]  [<ffffffff846ec2fa>] ? kernfs_path_from_node+0x4a/0x60
[ 1010.310543]  [<ffffffff846f66eb>] ? sysfs_warn_dup+0x7b/0x90
[ 1010.310547]  [<ffffffff846f6f26>] ? sysfs_do_create_link_sd.isra.2+0xb6/0xd0
[ 1010.310553]  [<ffffffff84cd5a08>] ? bus_add_device+0x318/0x6b0
[ 1010.310557]  [<ffffffff846f8693>] ? sysfs_create_groups+0x83/0x110
[ 1010.310562]  [<ffffffff84ccff87>] ? device_add+0x777/0x1350
[ 1010.310567]  [<ffffffff84ccf810>] ? device_private_init+0x180/0x180
[ 1010.310583]  [<ffffffffc00c0f77>] ? usb_new_device+0x707/0x1030 [usbcore]
[ 1010.310598]  [<ffffffffc00c58c5>] ? hub_event+0x1d65/0x3280 [usbcore]
[ 1010.310604]  [<ffffffff841eb4ab>] ? account_entity_dequeue+0x30b/0x4a0
[ 1010.310618]  [<ffffffffc00c3b60>] ? hub_port_debounce+0x280/0x280 [usbcore]
[ 1010.310624]  [<ffffffff8407ccd0>] ? compat_start_thread+0x80/0x80
[ 1010.310629]  [<ffffffff851f5cb4>] ? __schedule+0x704/0x1770
[ 1010.310633]  [<ffffffff851f55b0>] ? io_schedule_timeout+0x390/0x390
[ 1010.310638]  [<ffffffff84541783>] ? cache_reap+0x173/0x200
[ 1010.310642]  [<ffffffff84197bed>] ? process_one_work+0x4ed/0xe60
[ 1010.310646]  [<ffffffff84198642>] ? worker_thread+0xe2/0xfd0
[ 1010.310650]  [<ffffffff8421f76c>] ? __wake_up_common+0xbc/0x160
[ 1010.310654]  [<ffffffff84198560>] ? process_one_work+0xe60/0xe60
[ 1010.310658]  [<ffffffff841a837c>] ? kthread+0x1cc/0x220
[ 1010.310663]  [<ffffffff841a81b0>] ? kthread_park+0x80/0x80
[ 1010.310667]  [<ffffffff841a81b0>] ? kthread_park+0x80/0x80
[ 1010.310671]  [<ffffffff841a81b0>] ? kthread_park+0x80/0x80
[ 1010.310675]  [<ffffffff852016f5>] ? ret_from_fork+0x25/0x30
Tested-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

A register used to identify chip during probe was overwritten during
firmware download and due to that later probe's for warm chip were
failing. Detect chip from the another register, which is located on
different register bank 2.

Fixes: 94d0eaa4 ("[media] mn88472: move out of staging to media")

Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

A register used to identify chip during probe was overwritten during
firmware download and due to that later probe's for warm chip were
failing. Detect chip from the another register, which is located on
different register bank 2.

Fixes: 7908fad9 ("[media] mn88473: finalize driver")

Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

"c77d17c0 [media] lirc: use-after free" introduces two problems:
cdev_del() can be called with a NULL argument, and the kobject_put()
path will cause a double free.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Exynos5433 SoC has MFC v8 hardware module, but it has more
complex clock hierarchy, so a new compatible is added.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

This patch changes the code for handling clocks. Now clocks are defined
per each device variant, what is a preparation for adding support for
Exynos 5433 MFC V8, which has more clocks than all previous versions.
Also use devm_clk_get() to simplify cleanup path.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

This patch moves preparation of clocks from s5p_mfc_init_pm()
(driver probe) to s5p_mfc_power_on() (start of device operation).
This change will allow to use runtime power usage optimization
on newer Samsung Exynos platforms (for example Exynos 5433).
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

After commit "s5p-mfc: Fix clock management in s5p_mfc_release function"
all clocks related functions are called only when MFC device is really
available, so there is no additional check needed for NULL
gate clocks. This patch simplifies the code and kills IS_ERR_OR_NULL
macro usage.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

CONFIG_PM is always enabled on Exynos platforms, so remove dead code
related to early development of MFC driver on platform without PM support.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Move clock disabling before turning power off.  This will enable later
to add calls to clk_prepare/unprepare in the s5p_mfc_power_off() function
to avoid keeping clocks prepared all the time when driver is bound.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The maximum rate of special clock depends on SoC variant and should
be set in device tree via assigned-clock-rates property, so remove
the code which forces special clock to 200MHz.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Some applications don't check error codes from QBUF/DQBUF ioctls,
so don't spam kernel log with errors if they fall into endless loop
trying to queue next buffer after a failure.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

We do video allocation all the time and we need it to be fast.  Plus TLB
efficiency isn't terribly important for video.

That means we want to set DMA_ATTR_ALLOC_SINGLE_PAGES.

See also the previous change (commit 14d3ae2e "ARM: dma-mapping: Use
DMA_ATTR_ALLOC_SINGLE_PAGES hint to optimize allocation").

[m.szyprowski: rebased patch onto v4.9-rc1 and adapted changes
 to latest videbuf2 changes, this simplifies code changes to
 only set proper dma attribute flag and comment the reason
 for it, added commit id of arch/arm/mm patch]
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

HSV formats were missing the color encoding, which leads to an invalid
ycbcr_enc value during get_fmt and try_fmt.
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Zero is not a valid value for hsv_enc. Set the field to a valid
initial value.

This is not a problem for vivid, because it sets the field to 180 via
tpg_s_hsv_enc() on the control initialization, but it might be a source
of errors for other drivers that use this code.
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The cec_allocate_adapter function doesn't need the parent device, only the
cec_register_adapter function needs it.

Drop the cec_devnode parent field, since devnode.dev.parent can be used
instead.

This change makes the framework consistent with other frameworks where the
parent device is not used until the device is registered.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>