cron job: media_tree daily build: ERRORS

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: Tue Oct 3 05:00:05 CEST 2017 media-tree git hash:cf09e3c904bf424f8b6a8203958e09bf7d9bcbc0 media_build

Re: [PATCH 00/18] use ARRAY_SIZE macro

On Mon, 2 Oct 2017 15:22:24 -0400 bfie...@fieldses.org (J. Bruce Fields) wrote: > Mainly I'd just like to know which you're asking for. Do you want me to > apply this, or to ACK it so someone else can? If it's sent as a series > I tend to assume the latter. > > But in this case I'm assuming

Re: [PATCH RFC] media: staging/imx: fix complete handler

On 10/01/2017 04:36 PM, Russell King - ARM Linux wrote: On Sun, Oct 01, 2017 at 01:16:53PM -0700, Steve Longerbeam wrote: Right, imx_media_add_vdev_to_pa() has followed a link to an entity that imx is not aware of. The only effect of this patch (besides allowing the driver to load with

Re: [PATCH v10 00/24] Unified fwnode endpoint parser, async sub-device notifier support, N9 flash DTS

Hi, On Mon, Sep 11, 2017 at 9:59 AM, Sakari Ailus wrote: > Hi folks, > > We have a large influx of new, unmerged, drivers that are now parsing > fwnode endpoints and each one of them is doing this a little bit > differently. The needs are still exactly the same for

Re: [PATCH 1/1] v4l: async: Fix notifier complete callback error handling

Hi Russell, On Mon, Oct 2, 2017 at 7:12 PM, Russell King - ARM Linux wrote: >> > > Any chance of sending me that patch so I can test this patch? I'd > rather not manually de-html-ise the above patch. You can

Re: [PATCH 1/1] v4l: async: Fix notifier complete callback error handling

On Mon, Oct 02, 2017 at 02:28:46PM +0300, Sakari Ailus wrote: > On Mon, Oct 02, 2017 at 01:59:54PM +0300, Sakari Ailus wrote: > > The notifier complete callback may return an error. This error code was > > simply returned to the caller but never handled properly. > > > > Move calling the complete

[PATCH v7 2/2] media:imx274 V4l2 driver for Sony imx274 CMOS sensor

The imx274 is a Sony CMOS image sensor that has 1/2.5 image size. It supports up to 3840x2160 (4K) 60fps, 1080p 120fps. The interface is 4-lane MIPI CSI-2 running at 1.44Gbps each. This driver has been tested on Xilinx ZCU102 platform with a Leopard LI-IMX274MIPI-FMC camera board. Support for

[PATCH v7 1/2] media:imx274 device tree binding file

The binding file for imx274 CMOS sensor V4l2 driver Signed-off-by: Leon Luo Acked-by: Sören Brinkmann Acked-by: Rob Herring --- v7: - no changes v6: - no changes v5: - add 'port' and 'endpoint' information v4: - no

Raspberry PI 2 & Easy cap Dmseg log

Hi  I Have 2 of these easycap devices both product the same with VLC "traffic cone" Hope the log is of help Any ideas would be welcome Jerry [    0.00] Booting Linux on physical CPU 0x0 [    0.00] Linux version 4.9.41-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG

[PATCH v3] staging: atomisp: add a driver for ov5648 camera sensor

The ov5648 5-megapixel camera sensor from OmniVision supports up to 2592x1944 resolution and MIPI CSI-2 interface. Output format is raw sRGB/Bayer with 10 bits per colour (SGRBG10_1X10). This patch is a port of ov5648 driver after applying following 01org/ProductionKernelQuilts patches: -

Re: [PATCH 00/18] use ARRAY_SIZE macro

On Mon, Oct 02, 2017 at 07:35:54AM +0200, Greg KH wrote: > On Sun, Oct 01, 2017 at 08:52:20PM -0400, Jérémy Lefaure wrote: > > On Mon, 2 Oct 2017 09:01:31 +1100 > > "Tobin C. Harding" wrote: > > > > > > In order to reduce the size of the To: and Cc: lines, each patch of the > > >

Re: [PATCH 00/18] use ARRAY_SIZE macro

Em Sun, 1 Oct 2017 20:52:20 -0400 Jérémy Lefaure escreveu: > Anyway, I can tell to each maintainer that they can apply the patches > they're concerned about and next time I may send individual patches. In the case of media, we'll handle it as if they were individual

Re: [PATCH] string.h: work around for increased stack usage

On 10/02/2017 11:40 AM, Arnd Bergmann wrote: > The hardened strlen() function causes rather large stack usage > in at least one file in the kernel when CONFIG_KASAN is enabled: > > drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init': >

Re: [v4,2/9] brcmsmac: split up wlc_phy_workarounds_nphy

Arnd Bergmann wrote: > The stack consumption in this driver is still relatively high, with one > remaining warning if the warning level is lowered to 1536 bytes: > > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: > the frame size of 1880 bytes is

Re: [v4, 1/9] brcmsmac: make some local variables 'static const' to reduce stack size

Arnd Bergmann wrote: > With KASAN and a couple of other patches applied, this driver is one > of the few remaining ones that actually use more than 2048 bytes of > kernel stack: > > broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_gainctrl': >

Re: [PATCH v3 10/15] [media] vb2: add 'ordered' property to queues

Hi, On Thu, Sep 07, 2017 at 03:42:21PM -0300, Gustavo Padovan wrote: From: Gustavo Padovan For explicit synchronization (and soon for HAL3/Request API) we need the v4l2-driver to guarantee the ordering in which the buffers were queued by userspace. This is

Re: [PATCH v3 04/15] [media] vb2: add in-fence support to QBUF

Hi, On Thu, Sep 07, 2017 at 03:42:15PM -0300, Gustavo Padovan wrote: From: Gustavo Padovan Receive in-fence from userspace and add support for waiting on them before queueing the buffer to the driver. Buffers are only queued to the driver once they are ready. A

Re: [PATCH v3 02/15] [media] vb2: add explicit fence user API

Hi, On Thu, Sep 07, 2017 at 03:42:13PM -0300, Gustavo Padovan wrote: From: Gustavo Padovan Turn the reserved2 field into fence_fd that we will use to send an in-fence to the kernel and return an out-fence from the kernel to userspace. Two new flags were added,

Re: [PATCH v3 00/15] V4L2 Explicit Synchronization support

Hi Gustavo, On Thu, Sep 07, 2017 at 03:42:11PM -0300, Gustavo Padovan wrote: From: Gustavo Padovan Hi, Refer to the documentation on the first patch for the details. The previous iteration is here:

[PATCH] [media] ov5645: I2C address change

As soon as the sensor is powered on, change the I2C address to the one specified in DT. This allows to use multiple physical sensors connected to the same I2C bus. Signed-off-by: Todor Tomov --- drivers/media/i2c/ov5645.c | 42 ++

Re: [PATCH v14 07/28] rcar-vin: Use generic parser for parsing fwnode endpoints

Hejssan, On 10/02/17 15:14, Niklas Söderlund wrote: > Hi Sakari, > > On 2017-10-02 14:58:10 +0300, Sakari Ailus wrote: >> Hi Niklas, >> >> On 09/30/17 16:17, Niklas Söderlund wrote: >>> Hi Sakari, >>> >>> Thanks for your patch, I like it. Unfortunately it causes issues :-( >>> >>> I picked the

Re: [PATCH v14 07/28] rcar-vin: Use generic parser for parsing fwnode endpoints

Hi Sakari, On 2017-10-02 14:58:10 +0300, Sakari Ailus wrote: > Hi Niklas, > > On 09/30/17 16:17, Niklas Söderlund wrote: > > Hi Sakari, > > > > Thanks for your patch, I like it. Unfortunately it causes issues :-( > > > > I picked the first 7 patches of this series on top of media-next and it

Re: [PATCH v14 07/28] rcar-vin: Use generic parser for parsing fwnode endpoints

Hi Niklas, On 09/30/17 16:17, Niklas Söderlund wrote: > Hi Sakari, > > Thanks for your patch, I like it. Unfortunately it causes issues :-( > > I picked the first 7 patches of this series on top of media-next and it > produce problems when tested on Koelsch with CONFIG_OF_DYNAMIC=y. > > 1. It

usb/media/uvc: BUG in uvc_mc_create_links/media_create_pad_link

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 9e66317d3c92ddaab330c125dfe9d06eee268aff (4.14-rc3). uvcvideo: Found UVC 0.00 device a (2833:0201) uvcvideo 1-1:3.92: Entity type for entity Output 2 was not initialized! [ cut here ]

usb/media/v4l2: use-after-free in video_unregister_device/device_del

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 9e66317d3c92ddaab330c125dfe9d06eee268aff (4.14-rc3). usb 1-1: config 48 interface 0 altsetting 0 endpoint 0x4 has invalid maxpacket 1956, setting to 64 usb 1-1: New USB device found, idVendor=0573,

Re: [PATCH 1/1] v4l: async: Fix notifier complete callback error handling

On Mon, Oct 02, 2017 at 01:59:54PM +0300, Sakari Ailus wrote: > The notifier complete callback may return an error. This error code was > simply returned to the caller but never handled properly. > > Move calling the complete callback function to the caller from > v4l2_async_test_notify and undo

[PATCH 1/1] v4l: async: Fix notifier complete callback error handling

The notifier complete callback may return an error. This error code was simply returned to the caller but never handled properly. Move calling the complete callback function to the caller from v4l2_async_test_notify and undo the work that was done either in async sub-device or async notifier

Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver

Hi Rob On 27 September 2017 at 22:51, Rob Herring wrote: > On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote: >> Hi Stefan >> >> On 22 September 2017 at 07:45, Stefan Wahren wrote: >> > Hi Dave, >> > >> >> Dave Stevenson

Re: [PATCH 03/18] media: use ARRAY_SIZE

On Sun, Oct 1, 2017 at 3:30 PM, Jérémy Lefaure wrote: > Using the ARRAY_SIZE macro improves the readability of the code. Also, > it is not always useful to use a variable to store this constant > calculated at compile time. > > Found with Coccinelle with the following

Re: [PATCH RFC] [media] v4l: async: don't bomb out on ->complete failure

Hi Mauro and Russell, On Sat, Sep 30, 2017 at 06:20:49AM -0300, Mauro Carvalho Chehab wrote: > Em Fri, 29 Sep 2017 22:33:36 +0100 > Russell King escreveu: > > > When a subdev is being registered via v4l2_async_register_subdev(), we > > test to see if we have all the

Re: [PATCH] string.h: work around for increased stack usage

On Mon, Oct 2, 2017 at 10:40 AM, Arnd Bergmann wrote: > > void fortify_panic(const char *name) __noreturn __cold; > + > +/* work around GCC PR82365 */ > +#if defined(CONFIG_KASAN) && !defined(__clang__) && GCC_VERSION <= 8 > +#define fortify_panic(x) \ > + do { \ > +

[PATCH] string.h: work around for increased stack usage

The hardened strlen() function causes rather large stack usage in at least one file in the kernel when CONFIG_KASAN is enabled: drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init': drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 bytes is larger than

Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

On Thu, Sep 28, 2017 at 4:30 PM, Arnd Bergmann wrote: > On Thu, Sep 28, 2017 at 6:09 AM, Andrey Ryabinin > wrote: >> On 09/27/2017 04:26 PM, Arnd Bergmann wrote: >>> On Tue, Sep 26, 2017 at 9:49 AM, Andrey Ryabinin >>> wrote: >

[PATCH v2 1/1] staging: atomisp: Update TODO regarding sensors

There was no specific item regarding what should be done to sensor, lens and flash drivers. Add one, to replace the vague item denoting support only to particular sensor, lens and flash devices. Signed-off-by: Sakari Ailus --- since v1: - Mention LED flash API for

Re: [PATCH] imx-csi: fix burst size

Hi Russell, On Fri, 2017-09-29 at 22:41 +0100, Russell King wrote: > Setting a burst size of "8" doesn't work for IMX219 with 8-bit bayer, > but a burst size of "16" does.  Fix this. Do larger bursts work as well, if the width is divisible by the burst length? Since the Bayer format can't pass