Hans Verkuil [Fri, 22 Apr 2016 13:03:38 +0000 (10:03 -0300)]
[media] sta2x11_vip: fix s_std
The s_std ioctl was broken in this driver, partially due to the
changes to the adv7180 driver (this affected the handling of
V4L2_STD_ALL) and partially because the new standard was never
stored in vip->std.
The handling of V4L2_STD_ALL has been rewritten to just call querystd
and the new standard is now stored correctly.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Federico Vaga <federico.vaga@gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Hans Verkuil [Fri, 22 Apr 2016 13:03:37 +0000 (10:03 -0300)]
[media] adv7180: fix broken standards handling
The adv7180 attempts to autodetect the standard. Unfortunately this
is seriously broken.
This patch removes the autodetect completely. Only the querystd op
will detect the standard. Since the design of the adv7180 requires
that you switch to a special autodetect mode you cannot call querystd
when you are streaming.
So the s_stream op has been added so we know whether we are streaming
or not, and if we are, then querystd returns EBUSY.
After testing this with a signal generator is became obvious that
a sleep is needed between changing the standard to autodetect and
reading the status. So the autodetect can never have worked well.
The s_std call now just sets the new standard without any querying.
If the driver supports the interrupt, then when it detects a standard
change it will signal that by sending the V4L2_EVENT_SOURCE_CHANGE
event.
With these changes this driver now behaves like all other video
receivers.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Federico Vaga <federico.vaga@gmail.com> Tested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Hans Verkuil [Fri, 22 Apr 2016 09:06:59 +0000 (06:06 -0300)]
[media] DocBook media: drop 'experimental' annotations
Drop the 'experimental' annotations. The only remaining part of the API
that is still marked 'experimental' are the debug ioctls/structs, and
that is intentional. Only the v4l2-dbg application should use those.
All others have been around for years, so it is time to drop the
'experimental' designation.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Most of what is marked as 'experimental' has been around for years. Time
to drop that annotation.
The only remaining 'experimental' bits of the API are the debug ioctls
and structs: these should remain experimental since the only application
that should use this is v4l2-dbg.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The v4l2_device_call_* defines filter subdevs based on the grp_id value.
But some drivers use a bitmask, so instead of filtering by grp_id == value,
you want to filter by grp_id & value.
Make variants of these defines to do this.
The 'has_op' define has been extended to have a grp_id argument as well, and
a mask variant has been added.
This extra argument required a change to go7007.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Hans Verkuil [Tue, 22 Mar 2016 10:30:29 +0000 (07:30 -0300)]
[media] vidioc-dv-timings-cap.xml: explicitly state that pad and reserved should be zeroed
The DV_TIMINGS_CAP documentation didn't state clearly that the pad and
reserved fields should be zeroed by the application. For subdev pad can
be other values as well.
It also mistakenly said that only drivers would have to zero the reserved
field, that's not correct.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Hans Verkuil [Tue, 22 Mar 2016 10:30:28 +0000 (07:30 -0300)]
[media] vidioc-enum-dv-timings.xml: explicitly state that pad and reserved should be zeroed
The ENUM_DV_TIMINGS documentation did not clearly state that the pad and reserved
fields should be zeroed (pad only when used with a video device node).
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Hans Verkuil [Fri, 15 Apr 2016 15:35:32 +0000 (12:35 -0300)]
[media] pvrusb2: fix smatch errors
These are false positives, but still easy to fix.
pvrusb2-hdw.c:3676 pvr2_send_request_ex() error: we previously assumed 'write_data' could be null (see line 3648)
pvrusb2-hdw.c:3829 pvr2_send_request_ex() error: we previously assumed 'read_data' could be null (see line 3649)
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Set vb2_queue.gfp_flags to GFP_DMA32. Otherwise it will start to
create bounce buffers which is something you want to avoid since
those are in limited supply.
Without this patch, DMA scatter-gather may not work because
machines can ran out of buffers easily.
Hans Verkuil [Mon, 21 Mar 2016 11:07:44 +0000 (08:07 -0300)]
[media] tw686x-kh: specify that the DMA is 32 bits
Set vb2_queue.gfp_flags to GFP_DMA32. Otherwise it will start to
create bounce buffers which is something you want to avoid since
those are in limited supply.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
the dma_requests field is cached, but cache is not used:
drivers/staging/media/tw686x-kh/tw686x-kh-video.c: In function 'tw686x_video_irq':
drivers/staging/media/tw686x-kh/tw686x-kh-video.c:622:6: warning: variable 'requests' set but not used [-Wunused-but-set-variable]
u32 requests;
^
Use the cache instead, as it seems reading it needs to be done
with spin lock taken.
Ezequiel Garcia [Wed, 2 Mar 2016 14:30:16 +0000 (11:30 -0300)]
[media] media: Support Intersil/Techwell TW686x-based video capture cards
This commit introduces the support for the Techwell TW686x video
capture IC. This hardware supports a few DMA modes, including
scatter-gather and frame (contiguous).
This commit makes little use of the DMA engine and instead has
a memcpy based implementation. DMA frame and scatter-gather modes
support may be added in the future.
Currently supported chips:
- TW6864 (4 video channels),
- TW6865 (4 video channels, not tested, second generation chip),
- TW6868 (8 video channels but only 4 first channels using
built-in video decoder are supported, not tested),
- TW6869 (8 video channels, second generation chip).
[mchehab@osg.samsung.com: make checkpatch happy by using "unsigned int"
instead of just "unsigned"] Cc: Krzysztof Halasa <khalasa@piap.pl> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Krzysztof Hałasa [Fri, 11 Mar 2016 12:23:16 +0000 (09:23 -0300)]
[media] TW686x frame grabber driver
A driver for Intersil/Techwell TW686x-based PCIe frame grabbers.
[hans.verkuil@cisco.com: renamed staging tw686x to tw686x-kh to prevent naming conflicts]
[hans.verkuil@cisco.com: don't build tw686x-kh if tw686x is already selected to prevent conflicts]
[mchehab@osg.samsung.com: use "unsigned int" instead of just "unsigned" and add some whitespaces to make checkpatch happier] Signed-off-by: Krzysztof Halasa <khalasa@piap.pl> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Right now, the lock schema for media_device struct is messy,
since sometimes, it is protected via a spin lock, while, for
media graph traversal, it is protected by a mutex.
Solve this conflict by always using a mutex.
As a side effect, this prevents a bug when the media notifiers
is called at atomic context, while running the notifier callback:
Simon Horman [Fri, 25 Mar 2016 01:46:45 +0000 (22:46 -0300)]
[media] media: platform: rcar_jpu, vsp1: Use ARCH_RENESAS
Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
Laurent Pinchart [Fri, 25 Mar 2016 09:51:06 +0000 (06:51 -0300)]
[media] v4l: vsp1: Update WPF and LIF maximum sizes for Gen3
The maximum image size supported by the WPF is 2048x2048 on Gen2 and
8190x8190 on Gen3. Update the code accordingly, and fix the maximum LIF
size for both Gen2 and Gen3.
Laurent Pinchart [Thu, 24 Mar 2016 08:15:59 +0000 (05:15 -0300)]
[media] v4l: vsp1: Add global alpha support for DRM pipeline
Make the global alpha multiplier of DRM planes configurable. All the
necessary infrastructure is there, we just need to store the alpha value
passed through the DRM API.
Laurent Pinchart [Tue, 22 Mar 2016 14:10:27 +0000 (11:10 -0300)]
[media] v4l: vsp1: Add support for the RPF alpha multiplier on Gen3
The Gen3 RPF includes an alpha multiplier that can both multiply the
alpha channel by a fixed global alpha value, and multiply the pixel
components to convert the input to premultiplied alpha.
As alpha premultiplication is available in the BRU for both Gen2 and
Gen3 we handle it there and use the Gen3 alpha multiplier for global
alpha multiplication only. This prevents conversion to premultiplied
alpha if no BRU is present in the pipeline, that use case will be
implemented later if needed.
[media] v4l: vsp1: dl: Add support for multi-body display lists
Display lists support up to 8 bodies but we currently use a single one.
To support preparing display lists for large look-up tables, add support
for multi-body display lists.
The vsp1_dl_list_put() function expects to be called with the display
list manager lock held. This assumption is correct for calls from within
the vsp1_dl.c file, but not for the external calls. Fix it by taking the
lock inside the function and providing an unlocked version for the
internal callers.
Laurent Pinchart [Wed, 24 Feb 2016 23:25:42 +0000 (20:25 -0300)]
[media] v4l: vsp1: Factorize media bus codes enumeration code
Most of the entities can't perform format conversion and implement the
same media bus enumeration function. Factorize the code into a single
implementation.
Laurent Pinchart [Wed, 24 Feb 2016 21:40:12 +0000 (18:40 -0300)]
[media] v4l: vsp1: RPF entities can't be target nodes
The RPF entities are located at the very beginning of pipelines, they
can't be target nodes in the Data Path Router matrix. Remove their input
ID from the routing table.
Laurent Pinchart [Sun, 17 Jan 2016 21:53:56 +0000 (19:53 -0200)]
[media] v4l: vsp1: Allocate pipelines on demand
Instead of embedding pipelines in the vsp1_video objects allocate them
on demand when they are needed. This fixes the streamon race condition
where pipelines objects from different video nodes could be used for the
same pipeline.
Laurent Pinchart [Thu, 14 Jan 2016 16:17:32 +0000 (14:17 -0200)]
[media] v4l: vsp1: Pass pipe pointer to entity configure functions
Pass the pipe explicitly instead of retrieving it through media
entities. This decouples device state stored in the pipeline from the
active state stored in entities, preparing for dynamic pipeline
creation.
Laurent Pinchart [Sun, 22 Nov 2015 22:29:25 +0000 (20:29 -0200)]
[media] v4l: vsp1: Pass display list explicitly to configure functions
Modules write register values to the active display list pointed to by
the pipeline. In order to support preparing display lists ahead of time,
pass them explicitly to all configuration functions.
Laurent Pinchart [Tue, 17 Nov 2015 15:10:26 +0000 (13:10 -0200)]
[media] v4l: vsp1: Create a new configure operation to setup modules
The subdev s_stream operation is abused as a generic way to setup
modules at every frame. Move the code out to a new VSP1 entity configure
operation.
Most modules now have an empty s_stream operation that can be removed.
The only exception is the WPF module that needs to perform hardware
configuration when stopping the stream. The code can be simplified
accordingly as we know that that operation never fails.
Laurent Pinchart [Sun, 15 Nov 2015 21:14:22 +0000 (19:14 -0200)]
[media] v4l: vsp1: Store active selection rectangles in a pad config structure
Use the pad config structure part of the vsp1_entity to store all active
pad selection rectangles. This generalizes the code to operate on pad
config structures.
Laurent Pinchart [Sun, 15 Nov 2015 21:14:22 +0000 (19:14 -0200)]
[media] v4l: vsp1: Store active formats in a pad config structure
Add a pad config structure field to the vsp1_entity structure and use it
to store all active pad formats. This generalizes the code to operate on
pad config structures.
Laurent Pinchart [Sun, 15 Nov 2015 22:09:08 +0000 (20:09 -0200)]
[media] v4l: vsp1: Implement and use the subdev pad::init_cfg configuration
Turn the custom formats initialization function into a standard
pad::init_cfg handler and use it in subdevs instead of initializing
formats in the subdev open handler.
This makes the subdev open handler empty, so remove it.
Laurent Pinchart [Tue, 17 Nov 2015 14:23:23 +0000 (12:23 -0200)]
[media] v4l: vsp1: Consolidate entity ops in a struct vsp1_entity_operations
Entities have two operations, a destroy operation stored directly in
vsp1_entity and a set_memory operation stored in a vsp1_rwpf_operations
structure. Move the two to a more generic vsp1_entity_operations
structure that will serve to implement additional operations.
Laurent Pinchart [Sun, 15 Nov 2015 00:48:27 +0000 (22:48 -0200)]
[media] v4l: vsp1: Add header display list support
Display lists can operate in header or headerless mode. The headerless
mode is only available on WPF0, to be used with the display engine. All
other WPF instances can only use display lists in header mode.
Implement support for header mode to prepare for display list usage on
WPFs other than 0.
[media] v4l: vsp1: Document calling context of vsp1_pipeline_propagate_alpha()
The function can only be called from a s_stream handler as it requires a
valid display list context (due to calling vsp1_uds_set_alpha() which
writes to module registers). Document the requirement.
The RPF source memory pointers need to be offset to take the crop
rectangle into account. Offsets are computed in the RPF stream start,
which can happen (when using the DRM pipeline) after calling the RPF
.set_memory() operation that programs the buffer addresses.
The .set_memory() operation tries to guard against the problem by
skipping programming of the registers when the module isn't streaming.
This will however only protect the first use of an RPF in a DRM
pipeline, as in all subsequent uses the module streaming flag will be
set and the .set_memory() operation will use potentially incorrect
offsets.
Fix this by allowing the caller to decide whether to program the
hardware immediately or just cache the addresses. While at it refactor
the memory set code and create a new vsp1_rwpf_set_memory() that cache
addresses and calls the .set_memory() operation to apply them to the
hardware.
As a side effect the driver now writes all three DMA address registers
regardless of the number of planes, and initializes unused addresses to
zero.
[media] v4l: vsp1: Enable display list support for the HS[IT], LUT, SRU and UDS
Those modules were left out of display list integration as they're not
used by the DRM pipeline. To prepare for display list support in non-DRM
pipelines use the module write API to set registers.
[media] v4l: vsp1: sru: Don't program intensity in control set handler
The datasheet clearly states that all but a few registers can't be
modified when the device is running. Programming the intensity
parameters in the control set handler is thus prohibited. Program it
when starting the module instead.
This requires storing the intensity value internally as the module can
be started from the frame completion interrupt handler, and accessing
control values requires taking a mutex.
[media] v4l: vsp1: rwpf: Don't program alpha value in control set handler
The datasheet clearly states that all but a few registers can't be
modified when the device is running. Programming the alpha value in
the control set handler is thus prohibited. Program it when starting the
module instead.
This requires storing the alpha value internally as the module can be
started from the frame completion interrupt handler, and accessing
control values requires taking a mutex.
As reported by smatch:
drivers/media/platform/vsp1/vsp1_drm.c:39:6: warning: no previous prototype for 'vsp1_drm_frame_end' [-Wmissing-prototypes]
void vsp1_drm_frame_end(struct vsp1_pipeline *pipe)
Fixes: ef9621bcd664 ("[media] v4l: vsp1: Store the display list manager in the WPF") Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] v4l: vsp1: bru: Don't program background color in control set handler
The datasheet clearly states that all but a few registers can't be
modified when the device is running. Programming the background color
in the control set handler is thus prohibited. Program it when starting
the module instead.
This requires storing the background color value internally as the
module can be started from the frame completion interrupt handler, and
accessing control values requires taking a mutex.
Laurent Pinchart [Sun, 15 Nov 2015 00:27:52 +0000 (22:27 -0200)]
[media] v4l: vsp1: Store the display list manager in the WPF
Each WPF can process display lists independently, move the manager to
the WPF to reflect that and prepare for display list support for non-DRM
pipelines.
Laurent Pinchart [Sat, 14 Nov 2015 18:33:40 +0000 (16:33 -0200)]
[media] v4l: vsp1: Simplify frame end processing
The DRM pipeline, as it runs in automatic restart mode, never sees the
pipeline state set to VSP1_PIPELINE_STOPPING or VSP1_PIPELINE_STOPPED
when running the frame end interrupt handler. We can thus skip the
checks various checks in the handler and return immediately.
Similarly the DRM frame end handler calls vsp1_pipeline_run()
unnecessarily, as the state there is never VSP1_PIPELINE_STOPPED. Remove
the function call and the frame end handler is it's now empty.
Make sure display list usage is correctly disabled by always setting up
the corresponding registers, including when the display list feature
isn't used.
Laurent Pinchart [Mon, 29 Feb 2016 02:28:38 +0000 (23:28 -0300)]
[media] v4l: vsp1: video: Fix coding style
Commit 54b5a749b4f3 ("[media] v4l: vsp1: Use media entity enumeration
interface") wasn't aligned with the driver coding style. Fix it by
renaming the rval variable to ret.
Furthermore shorten lines by accessing the media_device instance in a
more straightforward fashion.
Laurent Pinchart [Sat, 20 Feb 2016 01:13:45 +0000 (23:13 -0200)]
[media] v4l: vsp1: drm: Include correct header file
The VSP1 DRM API is declared in <media/vsp1.h>, not <linux/vsp1.h>. Fix
it. This also reverts commit 18922936dc28 ("[media] vsp1_drm.h: add
missing prototypes") that added the same declarations in a different
header file.
[media] v4l: subdev: Add pad config allocator and init
Add a new subdev operation to initialize a subdev pad config array, and
a helper function to allocate and initialize the array. This can be used
by bridge drivers to implement try format based on subdev pad
operations.
Laurent Pinchart [Mon, 29 Feb 2016 11:45:45 +0000 (08:45 -0300)]
[media] media: Rename is_media_entity_v4l2_io to is_media_entity_v4l2_video_device
All users of is_media_entity_v4l2_io() (the exynos4-is, omap3isp,
davince_vpfe and omap4iss drivers and the v4l2-mc power management code)
use the function to check whether entities are video_device instances,
either to ensure they can cast the entity to a struct video_device, or
to count the number of video nodes users.
The purpose of the function is thus to identify whether the media entity
instance is an instance of the video_device object, not to check whether
it can perform I/O. Rename it accordingly, we will introduce a more
specific is_media_entity_v4l2_io() check when needed.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Laurent Pinchart [Mon, 29 Feb 2016 11:45:44 +0000 (08:45 -0300)]
[media] media: Add obj_type field to struct media_entity
Code that processes media entities can require knowledge of the
structure type that embeds a particular media entity instance in order
to cast the entity to the proper object type. This needs is shown by the
presence of the is_media_entity_v4l2_io and is_media_entity_v4l2_subdev
functions.
The implementation of those two functions relies on the entity function
field, which is both a wrong and an inefficient design, without even
mentioning the maintenance issue involved in updating the functions
every time a new entity function is added. Fix this by adding add an
obj_type field to the media entity structure to carry the information.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Simon Horman [Tue, 15 Mar 2016 00:40:27 +0000 (21:40 -0300)]
[media] soc_camera: rcar_vin: add device tree support for r8a7792
Simply document new compatibility string.
As a previous patch adds a generic R-Car Gen2 compatibility string
there appears to be no need for a driver updates.
By documenting this compat string it may be used in DTSs shipped, for
example as part of ROMs. It must be used in conjunction with the Gen2
fallback compat string. At this time there are no known differences between
the r8a7792 IP block and that implemented by the driver for the Gen2
fallback compat string. Thus there is no need to update the driver as the
use of the Gen2 fallback compat string will activate the correct code in
the current driver while leaving the option for r8a7792-specific driver
code to be activated in an updated driver should the need arise.
Yoshihiro Kaneko [Tue, 15 Mar 2016 00:40:26 +0000 (21:40 -0300)]
[media] soc_camera: rcar_vin: add R-Car Gen 2 and 3 fallback compatibility strings
Add fallback compatibility string for R-Car Gen 1 and 2.
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and 3. But beyond that it's unclear what the relationship
between IP blocks might be. For example, I believe that r8a7790 is older
than r8a7791 but that doesn't imply that the latter is a descendant of the
former or vice versa.
We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.
For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme being adopted for
drivers for Renesas SoCs.
Simon Horman [Tue, 8 Mar 2016 01:03:58 +0000 (22:03 -0300)]
[media] sh_mobile_ceu_camera: Remove dependency on SUPERH
A dependency on ARCH_SHMOBILE seems to be the best option for
sh_mobile_ceu_camera:
* For Super H based SoCs: sh_mobile_ceu is used on SH_AP325RXA, SH_ECOVEC,
SH_KFR2R09, SH_MIGOR, and SH_7724_SOLUTION_ENGINE which depend on
CPU_SUBTYPE_SH7722, CPU_SUBTYPE_SH7723, or CPU_SUBTYPE_SH7724 which all
select ARCH_SHMOBILE.
* For ARM Based SoCs: Since the removal of legacy (non-multiplatform)
support this driver has not been used by any Renesas ARM based SoCs.
The Renesas ARM based SoCs currently select ARCH_SHMOBILE, however,
it is planned that this will no longer be the case.
This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
Thanks to Geert Uytterhoeven for analysis and portions of the
change log text.
Simon Horman [Tue, 8 Mar 2016 01:03:55 +0000 (22:03 -0300)]
[media] rcar_vin: Use ARCH_RENESAS
Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
Dan Carpenter [Tue, 15 Mar 2016 07:07:10 +0000 (04:07 -0300)]
[media] m5mols: potential uninitialized variable
Smatch complains that there are some paths where "status" isn't
initialized. The code does assume that m5mols_read_u8() can fail so it
seems as if Smatch is correct.
Let's initialize it to REG_ISO_AUTO which is zero.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Dan Carpenter [Tue, 15 Mar 2016 07:05:20 +0000 (04:05 -0300)]
[media] cx23885: uninitialized variable in cx23885_av_work_handler()
The "handled" variable could be uninitialized if the
interrupt_service_routine() call back hasn't been implimented or if it
has been implemented but doesn't initialize "handled" to zero at the
start. For example, adv76xx_isr() only sets "handled" to true.
Fixes: 44b153ca639f ('[media] m5mols: Add ISO sensitivity controls') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
projects / karo-tx-linux.git / log