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: Thu Oct 6 05:00:36 CEST 2016 media-tree git hash:e3ea5e94489bc8c711d422dfa311cfa310553a1b media_build

Re: kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)

On Wed, 5 Oct 2016, Jani Nikula wrote: > On Wed, 05 Oct 2016, Daniel Vetter wrote: > > Jani Nikula has a patch with a scrip to make the one kernel-doc parser > > into a lint/checker pass over the entire kernel. I think that'd would > > be more robust instead of trying to

Fw: [PATCH v2] cinergyT2-core: don't do DMA on stack

Sorry, forgot to C/C people that are at the "Re: Problem with VMAP_STACK=y" thread. Forwarded message: Date: Wed, 5 Oct 2016 15:54:18 -0300 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab

Re: Problem with VMAP_STACK=y

Hi Johannes, Em Wed, 5 Oct 2016 20:29:45 +0200 Johannes Stezenbach escreveu: > On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote: > > static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap) > > { > > - char query[] = {

Re: Problem with VMAP_STACK=y

On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote: > static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap) > { > - char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION }; > - char state[3]; > + struct dvb_usb_device *d = adap->dev; > + struct

Re: kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)

Am 05.10.2016 um 16:04 schrieb Jani Nikula : > On Wed, 05 Oct 2016, Daniel Vetter wrote: >> Jani Nikula has a patch with a scrip to make the one kernel-doc parser >> into a lint/checker pass over the entire kernel. I think that'd would >> be more

Re: Problem with VMAP_STACK=y

On Wed, Oct 5, 2016 at 9:45 AM, Jörg Otte wrote: > 2016-10-05 17:53 GMT+02:00 Andy Lutomirski : >> On Wed, Oct 5, 2016 at 8:21 AM, Jörg Otte wrote: >>> 2016-10-05 11:04 GMT+02:00 Mauro Carvalho Chehab :

Re: Problem with VMAP_STACK=y

2016-10-05 17:53 GMT+02:00 Andy Lutomirski : > On Wed, Oct 5, 2016 at 8:21 AM, Jörg Otte wrote: >> 2016-10-05 11:04 GMT+02:00 Mauro Carvalho Chehab : >>> Em Wed, 5 Oct 2016 09:50:42 +0200 (CEST) >>> Jiri Kosina

Re: Problem with VMAP_STACK=y

On Wed, Oct 5, 2016 at 8:21 AM, Jörg Otte wrote: > 2016-10-05 11:04 GMT+02:00 Mauro Carvalho Chehab : >> Em Wed, 5 Oct 2016 09:50:42 +0200 (CEST) >> Jiri Kosina escreveu: >> >>> On Wed, 5 Oct 2016, Patrick Boettcher wrote: >>> >>> >

Re: Problem with VMAP_STACK=y

2016-10-05 11:04 GMT+02:00 Mauro Carvalho Chehab : > Em Wed, 5 Oct 2016 09:50:42 +0200 (CEST) > Jiri Kosina escreveu: > >> On Wed, 5 Oct 2016, Patrick Boettcher wrote: >> >> > > > Thanks for the quick response. >> > > > Drivers are: >> > > > dvb_core,

Re: [PATCH 00/15] improve function-level documentation

On Wed, 5 Oct 2016, Daniel Vetter wrote: > Jani Nikula has a patch with a scrip to make the one kernel-doc parser > into a lint/checker pass over the entire kernel. I think that'd would > be more robust instead of trying to approximate the real kerneldoc > parser. Otoh that parser is a horror

Re: [GIT PULL] HSV formats

Hi Mauro, I don't see the patches below in your tree. Is there a specific reason why this pull request hasn't been processed, or did it just fall through the cracks ? On Wednesday 07 Sep 2016 10:44:09 Ricardo Ribalda Delgado wrote: > Hi Mauro, > > > These patches add support for HSV. > >

kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)

On Wed, 05 Oct 2016, Daniel Vetter wrote: > Jani Nikula has a patch with a scrip to make the one kernel-doc parser > into a lint/checker pass over the entire kernel. I think that'd would > be more robust instead of trying to approximate the real kerneldoc > parser. Otoh that

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

On Wed, Oct 05, 2016 at 03:40:14PM +0200, Benjamin Gaignard wrote: > because with ion it is up to userland to decide which heap to use > and until now userland doesn't have any way to get device constraints... > > I will prefer let a central allocator (in kernel) decide from the > attached

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

because with ion it is up to userland to decide which heap to use and until now userland doesn't have any way to get device constraints... I will prefer let a central allocator (in kernel) decide from the attached devices which allocator is the best. It is what I have implemented in smaf.

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

On Tue, Oct 04, 2016 at 01:47:21PM +0200, Benjamin Gaignard wrote: > version 10 changes: > - rebased on kernel 4.8 tag > - minor typo fix > > version 9 changes: > - rebased on 4.8-rc5 > - struct dma_attrs doesn't exist anymore so update CMA allocator >to compile with new dma_*_attr

Re: [PATCH 00/15] improve function-level documentation

Jani Nikula has a patch with a scrip to make the one kernel-doc parser into a lint/checker pass over the entire kernel. I think that'd would be more robust instead of trying to approximate the real kerneldoc parser. Otoh that parser is a horror show of a perl/regex driven state machine ;-) Jani,

[PATCH 1/1] v4l: compat: Prevent allocating excessive amounts of memory

get_v4l2_ext_controls32() is used to convert the 32-bit compat struct into native 64-bit representation. The function multiplies the array length by the entry length before validating size. Perform the size validation first. Also use unsigned values for size computation. Make similar changes to

Re: Problem with VMAP_STACK=y

Em Wed, 5 Oct 2016 06:04:50 -0300 Mauro Carvalho Chehab escreveu: > Em Wed, 5 Oct 2016 09:50:42 +0200 (CEST) > Jiri Kosina escreveu: > > > On Wed, 5 Oct 2016, Patrick Boettcher wrote: > > > > > > > Thanks for the quick response. > > > > > Drivers

Re: Problem with VMAP_STACK=y

Em Wed, 5 Oct 2016 09:50:42 +0200 (CEST) Jiri Kosina escreveu: > On Wed, 5 Oct 2016, Patrick Boettcher wrote: > > > > > Thanks for the quick response. > > > > Drivers are: > > > > dvb_core, dvb_usb, dbv_usb_cynergyT2 > > > > > > This dbv_usb_cynergyT2 is not from Linus'

[RFC 6/6] v4l2: async: Provide interoperability between OF and fwnode matching

Of and fwnode support are separated in V4L2 and individual drivers may implement one of them. Sub-devices do not match with a notifier expecting sub-devices with fwnodes, nor the other way around. Fix this by checking for sub-device's of_node field in fwnode match and fwnode field in OF match.

Re: Problem with VMAP_STACK=y

On Wed, 5 Oct 2016, Patrick Boettcher wrote: > > > Thanks for the quick response. > > > Drivers are: > > > dvb_core, dvb_usb, dbv_usb_cynergyT2 > > > > This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem > > to be able to find it, and the only google hit I am getting is your >

dvb-usb stack-memory used for URB-buffers (was: Re: Problem with VMAP_STACK=y)

Hi, On Tue, 4 Oct 2016 15:26:28 +0200 (CEST) Jiri Kosina wrote: > On Tue, 4 Oct 2016, Jörg Otte wrote: > > > With kernel 4.8.0-01558-g21f54dd I get thousands of > > "dvb-usb: bulk message failed: -11 (1/0)" > > messages in the logs and the DVB adapter is not working. > > > >

Re: Problem with VMAP_STACK=y

On Wed, 5 Oct 2016 09:26:29 +0200 (CEST) Jiri Kosina wrote: > On Tue, 4 Oct 2016, Jörg Otte wrote: > > > Thanks for the quick response. > > Drivers are: > > dvb_core, dvb_usb, dbv_usb_cynergyT2 > > This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem > to be

Re: Problem with VMAP_STACK=y

On Tue, 4 Oct 2016, Jörg Otte wrote: > Thanks for the quick response. > Drivers are: > dvb_core, dvb_usb, dbv_usb_cynergyT2 This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem to be able to find it, and the only google hit I am getting is your very mail to LKML :) -- Jiri

[RFC 3/5] omap3isp: Switch to fwnode API

Signed-off-by: Sakari Ailus --- drivers/media/platform/omap3isp/isp.c | 75 ++- 1 file changed, 38 insertions(+), 37 deletions(-) diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c index

[RFC 0/5] V4L2 fwnode support

Hi folks, This patchset adds support for fwnode to V4L2. Besides OF, also ACPI based systems can be supported this way. By using V4L2 fwnode, the individual drivers do not need to be aware of the underlying firmware implementation. The patchset depends on another patchset here:

[RFC 4/5] smiapp: Support ACPI power control

On ACPI systems the ACPI will control at least regulators to the sensor. On such systems the sensor driver does not explicitly need to control them, thus make them optional. Signed-off-by: Sakari Ailus --- drivers/media/i2c/smiapp/smiapp-core.c | 2 +- 1 file

[RFC 2/5] v4l: async: Match fwnode instead of of_node

Match more generic fwnode instead of OF specific of_node. This will allows ACPI support. Signed-off-by: Sakari Ailus --- drivers/media/v4l2-core/v4l2-async.c | 12 include/media/v4l2-async.h | 5 + include/media/v4l2-subdev.h |

[RFC 1/5] v4l: fwnode: Support generic fwnode instead of just OF

The fwnode_handle is a more generic way than OF device_node to describe firmware nodes. This prepares for ACPI support in V4L2. Signed-off-by: Sakari Ailus --- drivers/media/v4l2-core/Makefile | 1 + drivers/media/v4l2-core/v4l2-fwnode.c | 338

[RFC 5/5] smiapp: Switch to fwnode API

Signed-off-by: Sakari Ailus --- drivers/media/i2c/smiapp/smiapp-core.c | 29 +++-- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c index

[PATCH 1/1] v4l: flash led class: Fix of_node release in probe() error path

The sub-device's OF node was used (of_node_get()) if it was set, but device's OF node was always put. Fix this. Signed-off-by: Sakari Ailus --- drivers/media/v4l2-core/v4l2-flash-led-class.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-)

[GIT PULL v2 FOR v4.10] smiapp cleanups, fixes and runtime PM support

Hi Mauro, Here are a number of cleanups and some fixes plus runtime PM support for the smiapp driver. Since the previous pull request, the runtime PM support patches have been rewritten. Please pull. The following changes since commit e3ea5e94489bc8c711d422dfa311cfa310553a1b: [media]