tree/branch: git://git.ragnatech.se/linux media-tree
branch HEAD: 72c27a68a2a3f650f0dc7891ee98f02283fc11af media: pvrusb2: properly
check endpoint types
TIMEOUT after 1192m
Sorry we cannot finish the testset for your branch within a reasonable time.
It's our fault -- either some build server
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Wed Dec 13 05:00:18 CET 2017
media-tree git hash:330dada5957e3ca0c8811b14c45e3ac42c694651
media_build git
Hey Andrey,
Quoting Andrey Konovalov :
On Thu, Nov 23, 2017 at 2:31 AM, Gustavo A. R. Silva
wrote:
Hi Andrey,
I have successfully installed and tested syzkaller with QEMU. Can you please
tell me how to reproduce this bug or share with me the full crash report?
Also, can you point me out to
From: Daniel Scheller
Fix up all remaining cosmetic issues as reported by checkpatch.pl.
Signed-off-by: Daniel Scheller
Signed-off-by: Jasmin Jessich
---
drivers/staging/media/cxd2099/cxd2099.c | 19 +--
drivers/staging/media/cxd2099/cxd2099.h | 14 +++---
2 files chan
From: Daniel Scheller
Debug messages should go to KERN_DEBUG, thus change the slot_shutdown()
notice from dev_info() to dev_dbg().
Signed-off-by: Daniel Scheller
Signed-off-by: Jasmin Jessich
---
drivers/staging/media/cxd2099/cxd2099.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
From: Daniel Scheller
These three small patches make the driver checkpatch-strict clean and
improves a few strings. No functional changes.
Essentially drivers/staging/media/cxd2099/ is now clean, esp.:
$ scripts/checkpatch.pl --strict --file drivers/staging/media/cxd2099/cxd2099.c
total: 0 er
From: Daniel Scheller
Prefix dev_*() I2C address prints with 0x, change CXD2099 to CXD2099AR,
change the MODULE_DESCRIPTION to a proper one and have a better (and
shorter) description for the buffermode modparam.
Signed-off-by: Daniel Scheller
Signed-off-by: Jasmin Jessich
---
drivers/staging
From: Jasmin Jessich
Required after the ddbridge 0.9.32 bump in media_tree.
Signed-off-by: Jasmin Jessich
Signed-off-by: Daniel Scheller
---
Fixes at least the patch issue with kernel <=3.13. Jasmin originally
prepared the updated patch when the ddbridge-0.9.32 bump was done, so
sending it in
On Tue, 2017-12-12 at 15:21 +0100, Arnd Bergmann wrote:
> On Tue, Dec 12, 2017 at 1:45 PM, Mauro Carvalho Chehab
> wrote:
> > Em Tue, 12 Dec 2017 03:42:32 -0800
> > Joe Perches escreveu:
> >
> > > > I actually thought about marking them 'const' here before sending
> > > > (without noticing the c
Hi Hans,
On 12-12-2017 15:47, Hans Verkuil wrote:
> Hi Jose,
>
> Some more comments:
Thanks for the review!
>
> On 11/12/17 18:41, Jose Abreu wrote:
>> This is an initial submission for the Synopsys DesignWare HDMI RX
>> Controller Driver. This driver interacts with a phy driver so that
>> a com
On Tue, 12 Dec 2017 09:03:50 -0200
Mauro Carvalho Chehab wrote:
> Em Mon, 06 Nov 2017 23:36:36 +
> Alan escreveu:
>
> > This isn't the ideal final solution but it stops the main problem for now
> > where an open (often from udev) races the device initialization and we try
> > and load the f
Hi Jose,
Some more comments:
On 11/12/17 18:41, Jose Abreu wrote:
> This is an initial submission for the Synopsys DesignWare HDMI RX
> Controller Driver. This driver interacts with a phy driver so that
> a communication between them is created and a video pipeline is
> configured.
>
> The contr
Hi Mauro,
On Tuesday, 12 December 2017 14:39:32 EET Mauro Carvalho Chehab wrote:
> Em Thu, 23 Nov 2017 15:21:01 +0100 Greg Kroah-Hartman escreveu:
> > On Thu, Nov 23, 2017 at 11:07:51AM -0200, Mauro Carvalho Chehab wrote:
> >> Em Thu, 16 Nov 2017 02:33:48 +0200 Laurent Pinchart escreveu:
> >>> Dev
This adds a new NVIDIA Tegra video decoder driver. It is depending on the
request API work since it is a stateless codec, so for now park this in staging.
The dts patches should go through nvidia's tree.
Regards,
Hans
The following changes since commit 330dada5957e3ca0c8811b14c45e3ac42c
Hi Greg and Mauro,
On Thursday, 23 November 2017 16:21:01 EET Greg Kroah-Hartman wrote:
> On Thu, Nov 23, 2017 at 11:07:51AM -0200, Mauro Carvalho Chehab wrote:
> > Em Thu, 16 Nov 2017 02:33:48 +0200 Laurent Pinchart escreveu:
> >> Device unplug being asynchronous, it naturally races with operatio
Hi Mauro,
On Thursday, 23 November 2017 15:07:51 EET Mauro Carvalho Chehab wrote:
> Em Thu, 16 Nov 2017 02:33:48 +0200 Laurent Pinchart escreveu:
> > Device unplug being asynchronous, it naturally races with operations
> > performed by userspace through ioctls or other file operations on video
> >
Hi Hans,
On Friday, 17 November 2017 13:09:20 EET Hans Verkuil wrote:
> On 16/11/17 01:33, Laurent Pinchart wrote:
> > Device unplug being asynchronous, it naturally races with operations
> > performed by userspace through ioctls or other file operations on video
> > device nodes.
> >
> > This le
Hi Kieran,
On Thursday, 16 November 2017 16:47:11 EET Kieran Bingham wrote:
> On 16/11/17 12:32, Sakari Ailus wrote:
> > Hi Laurent,
> >
> > Thank you for the initiative to bring up and address the matter!
>
> I concur - this looks like a good start towards managing the issue.
>
> One potential
Hi Sakari,
On Thursday, 16 November 2017 14:32:37 EET Sakari Ailus wrote:
> On Thu, Nov 16, 2017 at 02:33:48AM +0200, Laurent Pinchart wrote:
> > Device unplug being asynchronous, it naturally races with operations
> > performed by userspace through ioctls or other file operations on video
> > dev
On Tue, Dec 12, 2017 at 1:45 PM, Mauro Carvalho Chehab
wrote:
> Em Tue, 12 Dec 2017 03:42:32 -0800
> Joe Perches escreveu:
>
>> > I actually thought about marking them 'const' here before sending
>> > (without noticing the changelog text) and then ran into what must
>> > have led me to drop the '
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)
The driver may sleep under a spinlock.
The function call path is:
bdisp_device_run (acquire the spinlock)
bdisp_hw_reset
msleep --> may sleep
To fix it, msleep is replaced with mdelay.
This bug is found by my static analysis tool(DSAC) and checked by my code
review.
Signed-off-by: Jia-Ju
The correct error code when a function is not defined is
-ENOTSUPP. It was typoed wrong as -EOPNOTSUPP, with,
unfortunately, exists, but it is not used by the DVB core.
Thanks-to: Geert Uytterhoeven
Thanks-to: Arnd Bergmann
To make me revisit this code.
Fixes: a9cb97c3e628 ("media: dvb_fronten
On 10/12/17 19:56, Dmitry Osipenko wrote:
> On 05.12.2017 16:03, Hans Verkuil wrote:
>> On 12/05/17 13:17, Dmitry Osipenko wrote:
>>> Hi Hans,
>>>
>>> On 04.12.2017 17:04, Hans Verkuil wrote:
Hi Dmitry,
As you already mention in the TODO, this should become a v4l2 codec driver.
Em Tue, 12 Dec 2017 03:42:32 -0800
Joe Perches escreveu:
> > I actually thought about marking them 'const' here before sending
> > (without noticing the changelog text) and then ran into what must
> > have led me to drop the 'const' originally: tuner_i2c_xfer_send()
> > takes a non-const pointer.
Em Thu, 23 Nov 2017 15:21:01 +0100
Greg Kroah-Hartman escreveu:
> On Thu, Nov 23, 2017 at 11:07:51AM -0200, Mauro Carvalho Chehab wrote:
> > Hi Laurent,
> >
> > Em Thu, 16 Nov 2017 02:33:48 +0200
> > Laurent Pinchart escreveu:
> >
> > > Device unplug being asynchronous, it naturally races wi
Hi Tim,
Sorry for the delay, I needed to find some time to think about this.
On 11/16/17 05:30, Rob Herring wrote:
> On Wed, Nov 15, 2017 at 10:31:14AM -0800, Tim Harvey wrote:
>> On Wed, Nov 15, 2017 at 7:52 AM, Rob Herring wrote:
>>> On Thu, Nov 09, 2017 at 10:45:34AM -0800, Tim Harvey wrote:
On Tue, 2017-12-12 at 11:24 +0100, Arnd Bergmann wrote:
> On Mon, Dec 11, 2017 at 10:17 PM, Michael Ira Krufky
> wrote:
> > On Mon, Dec 11, 2017 at 2:34 PM, Joe Perches wrote:
> > > On Mon, 2017-12-11 at 13:06 +0100, Arnd Bergmann wrote:
> > > > With CONFIG_KASAN enabled, we get a relatively larg
Hi Kieran,
On Fri, Nov 17, 2017 at 4:47 PM, Kieran Bingham
wrote:
> Each display list currently allocates an area of DMA memory to store register
> settings for the VSP1 to process. Each of these allocations adds pressure to
> the IPMMU TLB entries.
>
> We can reduce the pressure by pre-allocatin
Em Mon, 06 Nov 2017 23:36:36 +
Alan escreveu:
> This isn't the ideal final solution but it stops the main problem for now
> where an open (often from udev) races the device initialization and we try
> and load the firmware twice at the same time. This needless to say doesn't
> usually end wel
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
Hi Leo,
Am Dienstag, 12. Dezember 2017, 14:28:15 CET schrieb Leo Wen:
> +Optional properties:
> +
> +- spi-max-frequency : Maximum SPI clocking speed of the device;
> + (for RK1608)
> +- spi-min-frequency : Minimum SPI clocking speed of the device;
> +
On Mon, Dec 11, 2017 at 10:17 PM, Michael Ira Krufky
wrote:
> On Mon, Dec 11, 2017 at 2:34 PM, Joe Perches wrote:
>> On Mon, 2017-12-11 at 13:06 +0100, Arnd Bergmann wrote:
>>> With CONFIG_KASAN enabled, we get a relatively large stack frame in one
>>> function
>>>
>>> drivers/media/tuners/tda82
Hi Jacopo,
Thank you for the patch.
On Wednesday, 15 November 2017 12:55:58 EET Jacopo Mondi wrote:
> Migo-R platform uses sh_mobile_ceu camera driver, which is now being
> replaced by a proper V4L2 camera driver named 'renesas-ceu'.
>
> Move Migo-R platform to use the v4l2 renesas-ceu camera dr
On 12/12/2017 03:34 AM, Smitha T Murthy wrote:
>> s/Lay/Layer here and below
>>
> Ok I will change it.
While it's fine to make such change for controls up to
V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_QP...
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_QP:return "HEVC
>>> Hierarchic
Yes, acked-by: Ralph Metzler
Jasmin J. writes:
> Hi!
>
> > I don't know if you are also waiting for a comment from me.
> All positive ones are welcome ;)
>
> > I am fine with those changes. They are even desperately needed
> > to get some "problem CAMs" working.
> THX, so we can interpr
Hi Laurent,
On Mon, 11 Dec 2017, Laurent Pinchart wrote:
> Hi Guennadi,
>
> On Monday, 11 December 2017 23:44:09 EET Guennadi Liakhovetski wrote:
> > On Mon, 11 Dec 2017, Laurent Pinchart wrote:
> > > On Monday, 11 December 2017 22:16:23 EET Laurent Pinchart wrote:
> > >> On Wednesday, 6 Decembe
37 matches
Mail list logo
