| Age | Commit message (Collapse) | Author |
|---|
|
Clang warns:
drivers/staging/media/atomisp/pci/isp/kernels/xnr/xnr_3.0/ia_css_xnr3.host.c:129:35:
warning: implicit conversion from 'unsigned long' to 'int32_t' (aka
'int') changes value from 18446744073709543424 to -8192
[-Wconstant-conversion]
return MAX(MIN(isp_strength, 0), -XNR_BLENDING_SCALE_FACTOR);
~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
XNR_BLENDING_SCALE_FACTOR is BIT(13), or 8192, which will easily fit
into a signed 32-bit integer. However, it is an unsigned long, which
means that negating it is the same as subtracting that value from
ULONG_MAX + 1, which causes it to be larger than a signed 32-bit
integer so it gets implicitly converted.
We can avoid this by using the variable isp_scale, which holds the value
of XNR_BLENDING_SCALE_FACTOR already, where the implicit conversion from
unsigned long to s32 already happened. If that were to ever overflow,
clang would warn: https://godbolt.org/z/EeSxLG
Link: https://github.com/ClangBuiltLinux/linux/issues/1036
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Clang warns:
drivers/staging/media/atomisp/pci/atomisp_cmd.c:4278:17: warning:
address of 'config->info' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (!&config->info) {
~ ~~~~~~~~^~~~
config cannot be NULL because it comes from an ioctl, which ensures that
the user is not giving us an invalid pointer through copy_from_user. If
config is not NULL, info cannot be NULL. Remove this check.
Link: https://github.com/ClangBuiltLinux/linux/issues/1036
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Clang warns:
../drivers/staging/media/atomisp/pci/sh_css.c:8537:14: warning: address
of 'pipe->output_stage' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (&pipe->output_stage)
~~ ~~~~~~^~~~~~~~~~~~
../drivers/staging/media/atomisp/pci/sh_css.c:8545:14: warning: address
of 'pipe->vf_stage' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (&pipe->vf_stage)
~~ ~~~~~~^~~~~~~~
output_stage and vf_stage are pointers in the middle of a struct, their
addresses cannot be NULL if pipe is not NULL and pipe is already checked
for NULL in this function. Simplify this if block.
Link: https://github.com/ClangBuiltLinux/linux/issues/1036
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Clang warns:
../drivers/staging/media/atomisp/pci/atomisp_v4l2.c:1097:3: warning:
variable 'count' is incremented both in the loop header and in the loop
body [-Wfor-loop-analysis]
count++;
^
This was probably unintentional, remove it.
Link: https://github.com/ClangBuiltLinux/linux/issues/1036
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Clang warns:
../drivers/staging/media/atomisp/pci/sh_css_sp.c:1039:23: warning:
address of 'binary->in_frame_info' will always evaluate to 'true'
[-Wpointer-bool-conversion]
} else if (&binary->in_frame_info) {
~~ ~~~~~~~~^~~~~~~~~~~~~
in_frame_info is not a pointer so if binary is not NULL, in_frame_info's
address cannot be NULL. Change this to an else since it will always be
evaluated as one.
While we are here, clean up this if block. The contents of both if
blocks are the same but a check against "stage == 0" is added when
ISP2401 is defined. USE_INPUT_SYSTEM_VERSION_2401 is only defined when
isp2401_system_global.h is included, which only happens when ISP2401. In
other words, USE_INPUT_SYSTEM_VERSION_2401 always requires ISP2401 to be
defined so the '#ifndef ISP2401' makes no sense. Remove that part of the
block to simplify everything.
Link: https://github.com/ClangBuiltLinux/linux/issues/1036
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
stage->args->delay_frames array could point to NULL frames.
What's weird is that we didn't notice this behavior with the
Intel Aero Yocto code.
Handle it, while adding a notice at the code, as this could
be due to some broken pipeline setup.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The sh_css layer adds an abstraction for kvmalloc/kvcalloc.
Get rid of them. Most of the work here was done by this
small coccinelle script:
<cocci>
@@
expression size;
@@
- sh_css_malloc(size)
+ kvmalloc(size, GFP_KERNEL)
@@
expression n;
expression size;
@@
- sh_css_calloc(n, size)
+ kvcalloc(n, size, GFP_KERNEL)
</cocci>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The frame allocation logic happens differently for userptr
or normal mmap. On a quick look, this sounded to be unbalanced,
but the logic should actually work for both cases.
Add an extra comment to reflect it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
For debugging purposes, it helps to know what event
was actually received.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
If something gets wrong when enabling or disabling an IRQ,
we should know better about what happened.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The hmm code is still complex and has bugs. Add a debug print
when memory gets allocated, in order to help identifying what's
happening out there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Instead of using a hacked version of an old copy of
get_user_pages(), use pin_user_pages().
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
This device driver is not MC-centric. So, remove the wrong
caps from it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Yocto Aero driver has a different default for hmm pools.
Use the definitions there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The hmm code is partially based on a fork from 3.10 code,
and has bugs.
Add debug there to help tracking what happens there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The kernel ABI was extended to allow pass tagged user pointers.
Untag the pointers in this function.
Fixes: d93445225cd3 ("uaccess: add noop untagged_addr definition")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Now that we have everything in place, we can get rid of the
memory_access abstraction layer.
Now, everything related to heterogeneous memory management
(hmm) is under hmm.c & related pools.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The mmgr alloc code returns a different type than hmm, due to
some abstraction layer.
Change the driver to use just one type to represent the
hmm memory.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The code for it is commented out, probably because it is
broken or uneeded for the driver to work. So, let's get
rid of it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Those functions are just wrappers for hmm_load/hmm_store.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Move the attrs handling into hmm, simplifying even further
what the ia_css_memory_access.c file does.
Yet, the returned type for ia_css_memory_access.c is an
integer, instead of a pointer.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Yet another memory abstraction layer. Getting rid of this
may be a little trickier, but let's reduce it to a minimal.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Simplify the code by removing this extra memory management
abstraction layer.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The code there is a wrapper for hmm/ wrapper. Simplify it,
and get rid of ION-specific code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
There are several spelling mistakes in various messages and literal
strings. Fix these.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Right now, the variables that define the max number of
delay frames is defined as:
#define VIDEO_FRAME_DELAY 2
#define MAX_NUM_VIDEO_DELAY_FRAMES (VIDEO_FRAME_DELAY + 1)
#define NUM_PREVIEW_DVS_FRAMES (2)
#define MAX_NUM_DELAY_FRAMES MAX(MAX_NUM_VIDEO_DELAY_FRAMES, NUM_PREVIEW_DVS_FRAMES)
In other words, we have:
MAX_NUM_VIDEO_DELAY_FRAMES = 3
MAX_NUM_DELAY_FRAMES = 2
The MAX_NUM_DELAY_FRAMES macro is used only only when allocating
memory. On all other parts, including looping over such array,
MAX_NUM_VIDEO_DELAY_FRAMES is used instead, like:
void sh_css_binary_args_reset(struct sh_css_binary_args *args)
{
unsigned int i;
...
for (i = 0; i < MAX_NUM_VIDEO_DELAY_FRAMES; i++)
args->delay_frames[i] = NULL;
Which will cause buffer overflows, with may override the next array
(tnr_frames[]).
In practice, this may not be causing real issues, as the code
checks for num_delay_frames on some parts (but not everywhere).
So, get rid of the smallest value.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Some arguments for tnf and ref settings are meant to be const, but
they're defined without such annotation. Due to that, there's an
ugly cast at sh_css_sp.c.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The very same macros are defined as CSS_foo and IA_CSS_foo.
Remove this abstraction, as it just make things confusing,
for no good reason.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
This driver has 3 different types of debug messages:
- dev_dbg()
- dbg_level
- ia_css_debug_trace_level
Which is crazy. Ideally, it shold just use dev_dbg()
everywhere, but for now let's unify the last two machanisms.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
It sounds that someone once changed the debug level at compile
time for some testing, but forgot to remove the legacy code after
finishing debuging it.
Get rid of the dead code.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Let's reflect the current status at the TODO list, as other
developers can help addressing issues over there.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Using DQBUF on non-blocking mode will return -EAGAIN
if nothing arrives. Printing it has no value, even for debug
purposes. So, only display real return codes.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
There are several error conditions that don't print anything,
making harder to identify bugs at the code there.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
There's no reason to copy isp_sink_fmt, as the driver
uses it for read-only purposes.
Linux stack is a precious resource. Let's avoid wasting it.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Currently, when an EOF IRQ is received, it generates two messages:
[ 59.191893] atomisp-isp2 0000:00:03.0: irq:0x200000
[ 59.191913] atomisp-isp2 0000:00:03.0: atomisp_isr EOF exp_id 142, asd 0
Flooding the dmesg with lots of messages per second. The same
pattern happens for all other IRQs.
Change the logic for printing just one message per IRQ and
rate-limit those, as, for debugging purposes, it is usually
interesting to know that IRQs are being received, but not
displaying every single one.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
This is not used anywhere. So, let's trash it.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The code under load_primary_binaries() is complex and
were hard to understand, because it used to have lots
of ifdefs and broken identation.
The patch which cleaned it and removed the version-specific
ifdefs added a regression.
Solve it.
Fixes: 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The media bus formats to be used on serial busses are documented but there
was no reference from CSI-2 documentation. Add that now.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The IMX219 camera driver is not a clock provider, but merely a clock
consumer, and thus does not need to include <linux/clk-provider.h> and
<linux/clkdev.h>.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
OminiVision ov2740 is a 2 megapixels RAW RGB image sensor which can
deliver 1920x1080@60fps frames. This driver add the support of
vertical blanking, exposure, test pattern, digital and analog gain
control for sensor.
Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Shawn Tu <shawnx.tu@intel.com>
Signed-off-by: Qiu, Tianshu <tian.shu.qiu@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Query the sensor for its module revision, and compare it
to known revisions.
Currently 2A and 1B revision indentification is supported.
[Sakari Ailus: Wrap a line over 80, alignment, use %u for printing u32]
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Add match table, enable ov8856_probe() to support
both ACPI and DT modes.
ACPI and DT modes are primarily distinguished from
by checking for ACPI mode and by having resource like
be NULL.
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
This patch adds documentation of device tree in YAML schema for the
OV8856 CMOS image sensor.
Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Terratec Cinergy S2 PCIe Dual is a PCIe device with two tuners that
actually contains two USB devices. The devices are visible in the
lsusb printout.
Bus 004 Device 002: ID 153b:1182 TerraTec Electronic GmbH Cinergy S2 PCIe Dual Port 2
Bus 003 Device 002: ID 153b:1181 TerraTec Electronic GmbH Cinergy S2 PCIe Dual Port 1
The devices use the Montage M88DS3000/M88TS2022 demod/tuner.
Signed-off-by: Dirk Nehring <dnehring@gmx.net>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Fixes bug exposed by:
[a3fbc2e6bb0: media: mc-entity.c: use WARN_ON, validate link pads]
The dvbdev incorrectly requests a tuner sink pad to connect to a demux
sink pad. The media controller failure percolates back and the dvb device
creation fails. Fix this by requesting a tuner source pad. Instead of
forcing that pad to be index zero, check if a negative integer error
is returned. A note is added that first source pad found is chosen.
Affected bridges cx231xx and em28xx printed the below warning[s]
when a variety of media controller dvb enabled devices were connected.
The warning returns an error causing all affected devices to fail DVB
device creation.
[ 253.138332] ------------[ cut here ]------------
[ 253.138339] WARNING: CPU: 0 PID: 1550 at drivers/media/mc/mc-entity.c:669 media_create_pad_link+0x1e0/0x200 [mc]
[ 253.138339] Modules linked in: si2168 em28xx_dvb(+) em28xx si2157 lgdt3306a cx231xx_dvb dvb_core cx231xx_alsa cx25840 cx231xx tveeprom cx2341x i2c_mux videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc ir_rc5_decoder rc_hauppauge mceusb rc_core eda
c_mce_amd kvm nls_iso8859_1 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper efi_pstore wmi_bmof k10temp asix usbnet mii nouveau snd_hda_codec_realtek snd_hda_codec_generic input_leds ledtrig_audio snd_hda_codec_hdmi mxm_wmi snd_hda_in
tel video snd_intel_dspcfg ttm snd_hda_codec drm_kms_helper snd_hda_core drm snd_hwdep snd_seq_midi snd_seq_midi_event i2c_algo_bit snd_pcm snd_rawmidi fb_sys_fops snd_seq syscopyarea sysfillrect snd_seq_device sysimgblt snd_timer snd soundcore ccp mac_hid sch_fq_codel parport_p
c ppdev lp parport ip_tables x_tables autofs4 vfio_pci irqbypass vfio_virqfd vfio_iommu_type1 vfio hid_generic usbhid hid i2c_piix4 ahci libahci wmi gpio_amdpt
[ 253.138370] gpio_generic
[ 253.138372] CPU: 0 PID: 1550 Comm: modprobe Tainted: G W 5.7.0-rc2+ #181
[ 253.138373] Hardware name: MSI MS-7A39/B350M GAMING PRO (MS-7A39), BIOS 2.G0 04/27/2018
[ 253.138376] RIP: 0010:media_create_pad_link+0x1e0/0x200 [mc]
[ 253.138378] Code: 26 fd ff ff 44 8b 4d d0 eb d9 0f 0b 41 b9 ea ff ff ff 44 89 c8 c3 0f 0b 41 b9 ea ff ff ff eb f2 0f 0b 41 b9 ea ff ff ff eb e8 <0f> 0b 41 b9 ea ff ff ff eb af 0f 0b 41 b9 ea ff ff ff eb a5 66 90
[ 253.138379] RSP: 0018:ffffb9ecc0ee7a78 EFLAGS: 00010246
[ 253.138380] RAX: ffff943f706c99d8 RBX: 0000000000000000 RCX: 0000000000000000
[ 253.138381] RDX: ffff943f613e0180 RSI: 0000000000000000 RDI: ffff943f706c9958
[ 253.138381] RBP: ffffb9ecc0ee7ab0 R08: 0000000000000001 R09: ffff943f613e0180
[ 253.138382] R10: ffff943f613e0180 R11: ffff943f706c9400 R12: 0000000000000000
[ 253.138383] R13: 0000000000000001 R14: ffff943f706c9958 R15: 0000000000000001
[ 253.138384] FS: 00007f3cd29ba540(0000) GS:ffff943f8ec00000(0000) knlGS:0000000000000000
[ 253.138385] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 253.138385] CR2: 000055f7de0ca830 CR3: 00000003dd208000 CR4: 00000000003406f0
[ 253.138386] Call Trace:
[ 253.138392] media_create_pad_links+0x104/0x1b0 [mc]
[ 253.138397] dvb_create_media_graph+0x350/0x5f0 [dvb_core]
[ 253.138402] em28xx_dvb_init+0x5ea/0x2600 [em28xx_dvb]
[ 253.138408] em28xx_register_extension+0x63/0xc0 [em28xx]
[ 253.138410] ? 0xffffffffc039c000
[ 253.138412] em28xx_dvb_register+0x15/0x1000 [em28xx_dvb]
[ 253.138416] do_one_initcall+0x71/0x250
[ 253.138418] ? do_init_module+0x27/0x22e
[ 253.138421] ? _cond_resched+0x1a/0x50
[ 253.138423] ? kmem_cache_alloc_trace+0x1ec/0x270
[ 253.138425] ? __vunmap+0x1e3/0x240
[ 253.138427] do_init_module+0x5f/0x22e
[ 253.138430] load_module+0x2525/0x2d40
[ 253.138436] __do_sys_finit_module+0xe5/0x120
[ 253.138438] ? __do_sys_finit_module+0xe5/0x120
[ 253.138442] __x64_sys_finit_module+0x1a/0x20
[ 253.138443] do_syscall_64+0x57/0x1b0
[ 253.138445] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 253.138446] RIP: 0033:0x7f3cd24dc839
[ 253.138448] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
[ 253.138449] RSP: 002b:00007ffe4fc514d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 253.138450] RAX: ffffffffffffffda RBX: 000055a9237f63f0 RCX: 00007f3cd24dc839
[ 253.138451] RDX: 0000000000000000 RSI: 000055a922c3ad2e RDI: 0000000000000000
[ 253.138451] RBP: 000055a922c3ad2e R08: 0000000000000000 R09: 0000000000000000
[ 253.138452] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 253.138453] R13: 000055a9237f5550 R14: 0000000000040000 R15: 000055a9237f63f0
[ 253.138456] ---[ end trace a60f19c54aa96ec4 ]---
[ 234.915628] ------------[ cut here ]------------
[ 234.915640] WARNING: CPU: 0 PID: 1502 at drivers/media/mc/mc-entity.c:669 media_create_pad_link+0x1e0/0x200 [mc]
[ 234.915641] Modules linked in: si2157 lgdt3306a cx231xx_dvb(+) dvb_core cx231xx_alsa cx25840 cx231xx tveeprom cx2341x i2c_mux videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc ir_rc5_decoder rc_hauppauge mceusb rc_core edac_mce_amd kvm nls_iso8859
_1 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper efi_pstore wmi_bmof k10temp asix usbnet mii nouveau snd_hda_codec_realtek snd_hda_codec_generic input_leds ledtrig_audio snd_hda_codec_hdmi mxm_wmi snd_hda_intel video snd_intel_dspcf
g ttm snd_hda_codec drm_kms_helper snd_hda_core drm snd_hwdep snd_seq_midi snd_seq_midi_event i2c_algo_bit snd_pcm snd_rawmidi fb_sys_fops snd_seq syscopyarea sysfillrect snd_seq_device sysimgblt snd_timer snd soundcore ccp mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tab
les x_tables autofs4 vfio_pci irqbypass vfio_virqfd vfio_iommu_type1 vfio hid_generic usbhid hid i2c_piix4 ahci libahci wmi gpio_amdpt gpio_generic
[ 234.915700] CPU: 0 PID: 1502 Comm: modprobe Not tainted 5.7.0-rc2+ #181
[ 234.915702] Hardware name: MSI MS-7A39/B350M GAMING PRO (MS-7A39), BIOS 2.G0 04/27/2018
[ 234.915709] RIP: 0010:media_create_pad_link+0x1e0/0x200 [mc]
[ 234.915712] Code: 26 fd ff ff 44 8b 4d d0 eb d9 0f 0b 41 b9 ea ff ff ff 44 89 c8 c3 0f 0b 41 b9 ea ff ff ff eb f2 0f 0b 41 b9 ea ff ff ff eb e8 <0f> 0b 41 b9 ea ff ff ff eb af 0f 0b 41 b9 ea ff ff ff eb a5 66 90
[ 234.915714] RSP: 0018:ffffb9ecc1b6fa50 EFLAGS: 00010246
[ 234.915717] RAX: ffff943f8c94a9d8 RBX: 0000000000000000 RCX: 0000000000000000
[ 234.915719] RDX: ffff943f613e0900 RSI: 0000000000000000 RDI: ffff943f8c94a958
[ 234.915721] RBP: ffffb9ecc1b6fa88 R08: 0000000000000001 R09: ffff943f613e0900
[ 234.915723] R10: ffff943f613e0900 R11: ffff943f6b590c00 R12: 0000000000000000
[ 234.915724] R13: 0000000000000001 R14: ffff943f8c94a958 R15: 0000000000000001
[ 234.915727] FS: 00007f4ca3646540(0000) GS:ffff943f8ec00000(0000) knlGS:0000000000000000
[ 234.915729] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 234.915731] CR2: 00007fff7a53ba18 CR3: 00000003da614000 CR4: 00000000003406f0
[ 234.915733] Call Trace:
[ 234.915745] media_create_pad_links+0x104/0x1b0 [mc]
[ 234.915756] dvb_create_media_graph+0x350/0x5f0 [dvb_core]
[ 234.915766] dvb_init.part.4+0x691/0x1360 [cx231xx_dvb]
[ 234.915780] dvb_init+0x1a/0x20 [cx231xx_dvb]
[ 234.915787] cx231xx_register_extension+0x71/0xa0 [cx231xx]
[ 234.915791] ? 0xffffffffc042f000
[ 234.915796] cx231xx_dvb_register+0x15/0x1000 [cx231xx_dvb]
[ 234.915802] do_one_initcall+0x71/0x250
[ 234.915807] ? do_init_module+0x27/0x22e
[ 234.915811] ? _cond_resched+0x1a/0x50
[ 234.915816] ? kmem_cache_alloc_trace+0x1ec/0x270
[ 234.915820] ? __vunmap+0x1e3/0x240
[ 234.915826] do_init_module+0x5f/0x22e
[ 234.915831] load_module+0x2525/0x2d40
[ 234.915848] __do_sys_finit_module+0xe5/0x120
[ 234.915850] ? __do_sys_finit_module+0xe5/0x120
[ 234.915862] __x64_sys_finit_module+0x1a/0x20
[ 234.915865] do_syscall_64+0x57/0x1b0
[ 234.915870] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 234.915872] RIP: 0033:0x7f4ca3168839
[ 234.915876] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
[ 234.915878] RSP: 002b:00007ffcea3db3b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 234.915881] RAX: ffffffffffffffda RBX: 000055af22c29340 RCX: 00007f4ca3168839
[ 234.915882] RDX: 0000000000000000 RSI: 000055af22c38390 RDI: 0000000000000001
[ 234.915884] RBP: 000055af22c38390 R08: 0000000000000000 R09: 0000000000000000
[ 234.915885] R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000
[ 234.915887] R13: 000055af22c29060 R14: 0000000000040000 R15: 0000000000000000
[ 234.915896] ---[ end trace a60f19c54aa96ec3 ]---
Signed-off-by: Brad Love <brad@nextdimension.cc>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
bindings out of staging
Move phy-rockchip-dphy-rx0 bindings to Documentation/devicetree/bindings/phy
Verified with:
make ARCH=arm64 dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/phy/rockchip-mipi-dphy-rx0.yaml
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
reg property is not used in Rockchip MIPI DPHY RX0 bindings, thus remove
it.
Suggested-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Based on Yocto Aero's repository, the file name for the isp2401
is the same for the B0 release.
So, unify it at the driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The TODO list doesn't reflect the current status of the driver.
Update it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
