Two orthogonal changesets caused a breakage at a printk
inside davinci. Commit a2d17962c9
("[media] davinci: Switch from V4L2 OF to V4L2 fwnode")
made davinci to use struct fwnode_handle instead of
struct device_node. Commit 68d9c47b16
("media: Convert to using %pOF instead of full_name")
changed the printk to not use ->full_name, but, instead,
to rely on %pOF.
With both patches applied, the Kernel will do the wrong
thing, as warned by smatch:
drivers/media/platform/davinci/vpif_capture.c:1399 vpif_async_bound() error: '%pOF' expects argument of type 'struct device_node*', argument 5 has type 'void*'
So, change the logic to actually print the device name
that was obtained before the print logic.
Fixes: 68d9c47b16 ("media: Convert to using %pOF instead of full_name")
Fixes: a2d17962c9 ("[media] davinci: Switch from V4L2 OF to V4L2 fwnode")
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
pr_debug() and netdev_dbg() can be enabled/disabled dynamically
via sysfs. So, stop hidding them under ULE_DEBUG config macro.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This debug option is there for a long time, but it is only
enabled by editing the source code. Due to that, a breakage
inside its code was only noticed years after a change at
the ULE handling logic.
Make it a Kconfig parameter, as it makes easier for
advanced users to enable, and allow test if the compilation
won't be broken in the future.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
commit efb9ab6725 ("[media] dvb_net: prepare to split a very
complex function") changed the ULE handling logic, simplifying it.
However, it forgot to keep the initialization for .priv and to
zero .ule_hist fields.
The lack of .priv cause crashes if dvb_net_ule() is called, as
the function assuems that .priv field to be initialized.
With regards to .ule_hist, the current logic is broken and don't
even compile if ULE_DEBUG. Fix it by making the debug vars static
again, and be sure to pass iov parameter to dvb_net_ule_check_crc().
Fixes: efb9ab6725 ("[media] dvb_net: prepare to split a very complex function")
Suggested-by: Ron Economos <w6rz@comcast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Replace the original license statement with the SPDX identifier.
Update also the copyright owner adding myself as co-owner of the
copyright.
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
There is no reason to hold the lock while we wait for the IR to transmit.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This is code existed for when drivers would send less than the whole
buffer; no driver does this any more, so this is redundant. Drivers
should return -EINVAL if they cannot send the entire buffer.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
If memdup_user() fails, txbuf will be an error pointer and passed
to kfree.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The TX loop is more complex than it should. Simplify it.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The semantics for lirc IR transmit with raw IR is that the write call
should block until the IR is transmitted. Some drivers have no idea
when this actually is (e.g. mceusb), so there is a wait.
This is useful for userspace, as it might want to send a IR button press,
a gap of a predefined number of milliseconds, and then send a repeat
message.
It turns out that for transmitting scancodes this feature is even more
useful, as user space has no idea how long the IR is. So, maintain
the existing semantics for IR scancode transmit.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Since commit 9c7fd60e951d ("media: rc: Replace timeval with ktime_t in
imon.c"), the function tv2int() is no longer used. Remove it.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Another device with the 0xffdc device id, this one with 0x26 in the
config byte. Its an iMON Inside + iMON IR. It does respond to rc-6,
but seems to produce random garbage rather than a scancode.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The agreed format is to use /* */ comments inside header
files. Unfortunately, I ended by using // on a few ones.
Reported-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
s5p_jpeg_runtime_resume() does not call clk_disable_unprepare()
for jpeg->clocks[0] when one of the clk_prepare_enable() fails.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Acked-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
If the subdev is not yet present (probably because the subdev
module has not yet been loaded), the pipe will be NULL. Make sure
that this is not the case before attempting to call the op.
Signed-off-by: Simon Shields <simon@lineageos.org>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Support for Exynos4212 SoCs has been removed by commit bca9085e0a
("ARM: dts: exynos: remove Exynos4212 support (dead code)"), so there
is no need to keep remaining dead code related to this SoC version.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Driver calls request_firmware() whenever the device is opened for the
first time. As the device gets opened and closed, dev->num_inst == 1
is true several times. This is not necessary since the firmware is saved
in the fw_buf. s5p_mfc_load_firmware() copies the buffer returned by
the request_firmware() to dev->fw_buf.
fw_buf sticks around until it gets released from s5p_mfc_remove(), hence
there is no need to keep requesting firmware and copying it to fw_buf.
This might have been overlooked when changes are made to free fw_buf from
the device release interface s5p_mfc_release().
Fix s5p_mfc_load_firmware() to call request_firmware() once and keep state.
Change _probe() to load firmware once fw_buf has been allocated.
s5p_mfc_open() and it continues to call s5p_mfc_load_firmware() and init
hardware which is the step where firmware is written to the device.
This addresses the mfc_mutex contention due to repeated request_firmware()
calls from open() in the following circular locking warning:
[ 552.194115] qtdemux0:sink/2710 is trying to acquire lock:
[ 552.199488] (&dev->mfc_mutex){+.+.}, at: [<bf145544>] s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[ 552.207459]
but task is already holding lock:
[ 552.213264] (&mm->mmap_sem){++++}, at: [<c01df2e4>] vm_mmap_pgoff+0x44/0xb8
[ 552.220284]
which lock already depends on the new lock.
[ 552.228429]
the existing dependency chain (in reverse order) is:
[ 552.235881]
-> #2 (&mm->mmap_sem){++++}:
[ 552.241259] __might_fault+0x80/0xb0
[ 552.245331] filldir64+0xc0/0x2f8
[ 552.249144] call_filldir+0xb0/0x14c
[ 552.253214] ext4_readdir+0x768/0x90c
[ 552.257374] iterate_dir+0x74/0x168
[ 552.261360] SyS_getdents64+0x7c/0x1a0
[ 552.265608] ret_fast_syscall+0x0/0x28
[ 552.269850]
-> #1 (&type->i_mutex_dir_key#2){++++}:
[ 552.276180] down_read+0x48/0x90
[ 552.279904] lookup_slow+0x74/0x178
[ 552.283889] walk_component+0x1a4/0x2e4
[ 552.288222] link_path_walk+0x174/0x4a0
[ 552.292555] path_openat+0x68/0x944
[ 552.296541] do_filp_open+0x60/0xc4
[ 552.300528] file_open_name+0xe4/0x114
[ 552.304772] filp_open+0x28/0x48
[ 552.308499] kernel_read_file_from_path+0x30/0x78
[ 552.313700] _request_firmware+0x3ec/0x78c
[ 552.318291] request_firmware+0x3c/0x54
[ 552.322642] s5p_mfc_load_firmware+0x54/0x150 [s5p_mfc]
[ 552.328358] s5p_mfc_open+0x4e4/0x550 [s5p_mfc]
[ 552.333394] v4l2_open+0xa0/0x104 [videodev]
[ 552.338137] chrdev_open+0xa4/0x18c
[ 552.342121] do_dentry_open+0x208/0x310
[ 552.346454] path_openat+0x28c/0x944
[ 552.350526] do_filp_open+0x60/0xc4
[ 552.354512] do_sys_open+0x118/0x1c8
[ 552.358586] ret_fast_syscall+0x0/0x28
[ 552.362830]
-> #0 (&dev->mfc_mutex){+.+.}:
-> #0 (&dev->mfc_mutex){+.+.}:
[ 552.368379] lock_acquire+0x6c/0x88
[ 552.372364] __mutex_lock+0x68/0xa34
[ 552.376437] mutex_lock_interruptible_nested+0x1c/0x24
[ 552.382086] s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[ 552.386939] v4l2_mmap+0x54/0x88 [videodev]
[ 552.391601] mmap_region+0x3a8/0x638
[ 552.395673] do_mmap+0x330/0x3a4
[ 552.399400] vm_mmap_pgoff+0x90/0xb8
[ 552.403472] SyS_mmap_pgoff+0x90/0xc0
[ 552.407632] ret_fast_syscall+0x0/0x28
[ 552.411876]
other info that might help us debug this:
[ 552.419848] Chain exists of:
&dev->mfc_mutex --> &type->i_mutex_dir_key#2 --> &mm->mmap_sem
[ 552.431200] Possible unsafe locking scenario:
[ 552.437092] CPU0 CPU1
[ 552.441598] ---- ----
[ 552.446104] lock(&mm->mmap_sem);
[ 552.449484] lock(&type->i_mutex_dir_key#2);
[ 552.456329] lock(&mm->mmap_sem);
[ 552.462222] lock(&dev->mfc_mutex);
[ 552.465775]
*** DEADLOCK ***
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
s5p_mfc_load_firmware() will not get called if fw_buf.virt allocation
fails. The allocation happens very early on in the probe routine and
probe fails if allocation fails.
There is no need to check if it is null in s5p_mfc_load_firmware().
Remove the check.
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Setting both V4L2_CAP_VIDEO_CAPTURE_MPLANE and V4L2_CAP_VIDEO_OUTPUT_MPLANE
for mem2mem video nodes is obsolete since commit f0476a83d6 ("[media]
V4L: Add capability flags for memory-to-memory devices"). It was enough
time to adapt all users to the new flags, so drop the legacy caps for now
to match other mem2mem drivers.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Setting both V4L2_CAP_VIDEO_CAPTURE_MPLANE and V4L2_CAP_VIDEO_OUTPUT_MPLANE
for mem2mem video nodes is obsolete since commit f0476a83d6 ("[media]
V4L: Add capability flags for memory-to-memory devices"). It was enough
time to adapt all users to the new flags, so drop the legacy caps for now
to match other mem2mem drivers.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
We copy the subdev frame format from a partially initialized
structure, which is not entirely well-defined. Older compilers
like gcc-4.4 can copy uninitialized stack data here and warn
about it:
drivers/media/platform/exynos4-is/fimc-isp.c: In function 'fimc_isp_subdev_open':
drivers/media/platform/exynos4-is/fimc-isp.c:379: error: 'fmt.reserved[10u]' may be used uninitialized in this function
drivers/media/platform/exynos4-is/fimc-isp.c:379: error: 'fmt.reserved[9u]' may be used uninitialized in this function
...
drivers/media/platform/exynos4-is/fimc-isp.c:379: error: 'fmt.reserved[0u]' may be used uninitialized in this function
drivers/media/platform/exynos4-is/fimc-isp.c:379: error: 'fmt.xfer_func' may be used uninitialized in this function
On newer compilers, only the initialized fields get copied, but
we should not rely on that, so this changes the code to zero-out
the remaining fields first.
Fixes: 9a761e4368 ("[media] exynos4-is: Add Exynos4x12 FIMC-IS driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This patch fixes the menu_skip_mask field initialization and
addresses a following issue found by the SVACE static analysis:
* NO_EFFECT.SELF: assignment to self in expression 'cfg.menu_skip_mask = cfg.menu_skip_mask'
No effect at drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:2083
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The driver may sleep under a spinlock.
The function call path is:
bdisp_device_run (acquire the spinlock)
bdisp_hw_update
bdisp_hw_save_request
devm_kzalloc(GFP_KERNEL) --> may sleep
To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool(DSAC) and checked by my code review.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Currently videobuf2-dma-sg checks for dma direction for
every single page and videobuf2-dc lacks any dma direction
checks and calls set_page_dirty_lock unconditionally.
Thus unify and align the invocations of set_page_dirty_lock
for videobuf2-dc, videobuf2-sg memory allocators with
videobuf2-vmalloc, i.e. the pattern used in vmalloc has been
copied to dc and dma-sg.
Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The pvrusb2 code appears to have a some old workaround code for xawtv that causes a
WARN() due to an unrecognized pixelformat 0 in v4l2_ioctl.c.
Since all other MPEG drivers fill this in correctly, it is a safe assumption that
this particular problem no longer exists.
While I'm at it, clean up the code a bit.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
V4L2_BUF_FLAG_LAST is a signal from the driver to userspace for buffers
on the capture queue. When userspace queues back a capture buffer with
the flag set, we should clear it.
Otherwise, if userspace restarts streaming after EOS, without
reallocating the buffers, mem2mem devices will erroneously signal EOS
prematurely, as soon as the already flagged buffer is dequeued.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The mvcol buffer needs to be placed behind the chroma plane(s) when
decoding MPEG-4, same as for the h.264 decoder. Use the real offset
with the required rounding.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The MPEG-4 decoder mvcol buffer was registered, but its size not added
to a frame buffer allocation. This could cause the decoder to write past
the end of the allocated buffer for large frame sizes.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
We need internal frames to be rounded up to full macroblocks for MPEG-4
decoding as well.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Since bytesperline always fulfills VDOA width requirements, detile the
whole buffer instead of limiting to visible width. This stops TRY_FMT
from returning -EINVAL for YUYV capture buffers that are not a multiple
of 16 wide.
An alternative would be to always round up width to stride, as we report
the valid image rectange via G_SELECTION (V4L2_SEL_TGT_COMPOSE_DEFAULT),
but that would require all applications to handle the compose default
rectangle properly.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The current driver implementation expects at least one buffer on
all queues to start streaming. Properly signal this to the vb2
core, to avoid confusion when streamon is racing with qbuf.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
pxa_camera_probe() was not calling pxa_camera_deactivate(),
responsible to call clk_disable_unprepare(), on the failure path. This
was leading to unbalancing source clock.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
videobuf2 core reports an error when not all buffers have been returned
to the framework:
drivers/media/v4l2-core/videobuf2-core.c:1651
WARN_ON(atomic_read(&q->owned_by_drv_count))
Fix this returning all buffers currently in capture queue.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
When we split VB2 into an independent streaming module and
a V4L2 one, some vb2-core functions started to have a wrong
description: they're meant to be used only by the API-specific
parts of VB2, like vb2-v4l2, as the functions that V4L2 drivers
should use are all under videobuf2-v4l2.h.
Correct their descriptions.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
As kernel-doc doesn't support documenting #define values,
and using enum makes easier to identify where the values
are used, convert V4L2_MBUS_FRAME_DESC_FL_* to enum, and
use BIT() macro.
While here, fix the description at v4l2_mbus_frame_desc_entry,
in order to match what's described for
V4L2_MBUS_FRAME_DESC_FL_LEN_MAX.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Despite the struct says "color16", it was actually using 32 bits
for each color. Fix it.
Suggested-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The color structs right now are just "color" and "color16".
That may lead into conflicts, and don't define precisely what
they meant. As those are used by two drivers (vivid and vimc),
this is even on a somewhat public header!
So rename them to:
color -> tpg_rbg_color8
color16 -> tpg_rbg_color16
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The v4l2-tpg*.h headers are meant to be used only internally by
vivid and vimc. There's no sense keeping them together with the
V4L2 kAPI headers. Also, one header includes the other as they're
meant to be used together. So, merge them.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Add cross-references where needed and add periods at the end of
each kernel-doc paragraph, in order to make it coherent with other
VB2 descriptions.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
There are several issues on the current markups:
- lack of cross-references;
- wrong cross-references;
- lack of a period of the end of several phrases;
- Some descriptions can be enhanced.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Use the existing macros to identify vb2_io_modes bits.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The description there is completely broken and it mentions
an ioctl that doesn't exist.
Fix it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
When generating Sphinx output, create cross-references for the
callbacks for each ioctl.
While here, fix a few wrong names for ioctls.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The V4L_DIR_* direction flags document the direction for a
V4L2 device node. Convert them to enum and document.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
In the past, the same I2C address were used on multiple places.
After I2C rebinding changes, this is no longer needed. So, we
can just get rid of this header, placing the I2C address where
they belong, e. g. either at bttv driver or at tvtuner.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
