Re: [PATCH v4.4 1/1] v4l: event: Add subscription to list before calling "add" operation

[Greg Kroah-Hartman]

On Thu, Nov 08, 2018 at 01:46:32PM +0200, Sakari Ailus wrote:
> [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ]
> 
> Patch ad608fbcf166 changed how events were subscribed to address an issue
> elsewhere. As a side effect of that change, the "add" callback was called
> before the event subscription was added to the list of subscribed events,
> causing the first event queued by the add callback (and possibly other
> events arriving soon afterwards) to be lost.
> 
> Fix this by adding the subscription to the list before calling the "add"
> callback, and clean up afterwards if that fails.
> 
> Fixes: ad608fbcf166 ("media: v4l: event: Prevent freeing event subscriptions 
> while accessed")
> 
> Reported-by: Dave Stevenson 
> Signed-off-by: Sakari Ailus 
> Tested-by: Dave Stevenson 
> Reviewed-by: Hans Verkuil 
> Tested-by: Hans Verkuil 
> Cc: sta...@vger.kernel.org (for 4.14 and up)
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/v4l2-core/v4l2-event.c | 43 
> 
>  1 file changed, 24 insertions(+), 19 deletions(-)

Now applied, thanks.

greg k-h

Re: [PATCH v2 for v4.9 1/1] v4l: event: Add subscription to list before calling "add" operation

[Greg Kroah-Hartman]

On Wed, Nov 14, 2018 at 11:37:53AM +0200, Sakari Ailus wrote:
> [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ]
> 
> Patch ad608fbcf166 changed how events were subscribed to address an issue
> elsewhere. As a side effect of that change, the "add" callback was called
> before the event subscription was added to the list of subscribed events,
> causing the first event queued by the add callback (and possibly other
> events arriving soon afterwards) to be lost.
> 
> Fix this by adding the subscription to the list before calling the "add"
> callback, and clean up afterwards if that fails.
> 
> Fixes: ad608fbcf166 ("media: v4l: event: Prevent freeing event subscriptions 
> while accessed")
> 
> Reported-by: Dave Stevenson 
> Signed-off-by: Sakari Ailus 
> Tested-by: Dave Stevenson 
> Reviewed-by: Hans Verkuil 
> Tested-by: Hans Verkuil 
> Signed-off-by: Mauro Carvalho Chehab 
> [Sakari Ailus: Backported to v4.9 stable]
> Signed-off-by: Sakari Ailus 
> ---
> since v1 (as requested by Sasha):
> 
> - Add my final SoB
> - Indicate specifically this is a backport
> - Remove the extra cc stable

Now queued up, thanks.

greg k-h

Re: [PATCH v2 for v4.4 1/1] v4l: event: Add subscription to list before calling "add" operation

[Greg Kroah-Hartman]

On Mon, Nov 26, 2018 at 08:27:59AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Nov 22, 2018 at 01:33:33PM +0200, Sakari Ailus wrote:
> > On Tue, Nov 20, 2018 at 09:21:50AM -0200, Mauro Carvalho Chehab wrote:
> > > Em Tue, 20 Nov 2018 12:49:46 +0200
> > > Sakari Ailus  escreveu:
> > > 
> > > > Hi Greg,
> > > > 
> > > > On Mon, Nov 19, 2018 at 06:46:21PM +0100, Greg Kroah-Hartman wrote:
> > > > > On Mon, Nov 19, 2018 at 07:03:54PM +0200, Sakari Ailus wrote:  
> > > > > > Hi Greg,
> > > > > > 
> > > > > > On Mon, Nov 19, 2018 at 04:14:00PM +0100, Greg Kroah-Hartman wrote: 
> > > > > >  
> > > > > > > On Wed, Nov 14, 2018 at 11:37:46AM +0200, Sakari Ailus wrote:  
> > > > > > > > [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ]  
> > > > > > > 
> > > > > > > There is no such git commit id in Linus's tree :(  
> > > > > > 
> > > > > > Right. At the moment it's in the media tree only. I expect it'll 
> > > > > > end up to
> > > > > > Linus's tree once Mauro will send the next pull request from the 
> > > > > > media tree
> > > > > > to Linus.  
> > > > > 
> > > > > Ok, please do not send requests for stable tree inclusion until 
> > > > > _AFTER_
> > > > > the patch is in Linus's tree, otherwise it just wastes the stable tree
> > > > > maintainer's time :(  
> > > > 
> > > > Apologies for the noise. I'll send you a note once the patches are in
> > > > Linus's tree.
> > > 
> > > Btw, just sent a pull request with this patch. 
> > > 
> > > I wanted to send this two weeks ago, but I had to do two trips 
> > > (the final one to be at KS/LPC). This ended by delaying the pull request.
> > 
> > The patch is in Linus's tree now.
> 
> And what is the git commit id?

Nevermind, I see it...

Re: [PATCH v2 for v4.4 1/1] v4l: event: Add subscription to list before calling "add" operation

[Greg Kroah-Hartman]

On Thu, Nov 22, 2018 at 01:33:33PM +0200, Sakari Ailus wrote:
> On Tue, Nov 20, 2018 at 09:21:50AM -0200, Mauro Carvalho Chehab wrote:
> > Em Tue, 20 Nov 2018 12:49:46 +0200
> > Sakari Ailus  escreveu:
> > 
> > > Hi Greg,
> > > 
> > > On Mon, Nov 19, 2018 at 06:46:21PM +0100, Greg Kroah-Hartman wrote:
> > > > On Mon, Nov 19, 2018 at 07:03:54PM +0200, Sakari Ailus wrote:  
> > > > > Hi Greg,
> > > > > 
> > > > > On Mon, Nov 19, 2018 at 04:14:00PM +0100, Greg Kroah-Hartman wrote:  
> > > > > > On Wed, Nov 14, 2018 at 11:37:46AM +0200, Sakari Ailus wrote:  
> > > > > > > [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ]  
> > > > > > 
> > > > > > There is no such git commit id in Linus's tree :(  
> > > > > 
> > > > > Right. At the moment it's in the media tree only. I expect it'll end 
> > > > > up to
> > > > > Linus's tree once Mauro will send the next pull request from the 
> > > > > media tree
> > > > > to Linus.  
> > > > 
> > > > Ok, please do not send requests for stable tree inclusion until _AFTER_
> > > > the patch is in Linus's tree, otherwise it just wastes the stable tree
> > > > maintainer's time :(  
> > > 
> > > Apologies for the noise. I'll send you a note once the patches are in
> > > Linus's tree.
> > 
> > Btw, just sent a pull request with this patch. 
> > 
> > I wanted to send this two weeks ago, but I had to do two trips 
> > (the final one to be at KS/LPC). This ended by delaying the pull request.
> 
> The patch is in Linus's tree now.

And what is the git commit id?

thanks,

gre k-h

Re: [PATCH v2 for v4.4 1/1] v4l: event: Add subscription to list before calling "add" operation

[Greg Kroah-Hartman]

On Mon, Nov 19, 2018 at 07:03:54PM +0200, Sakari Ailus wrote:
> Hi Greg,
> 
> On Mon, Nov 19, 2018 at 04:14:00PM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Nov 14, 2018 at 11:37:46AM +0200, Sakari Ailus wrote:
> > > [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ]
> > 
> > There is no such git commit id in Linus's tree :(
> 
> Right. At the moment it's in the media tree only. I expect it'll end up to
> Linus's tree once Mauro will send the next pull request from the media tree
> to Linus.

Ok, please do not send requests for stable tree inclusion until _AFTER_
the patch is in Linus's tree, otherwise it just wastes the stable tree
maintainer's time :(

greg k-h

Re: [PATCH v2 for v4.4 1/1] v4l: event: Add subscription to list before calling "add" operation

[Greg Kroah-Hartman]

On Wed, Nov 14, 2018 at 11:37:46AM +0200, Sakari Ailus wrote:
> [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ]

There is no such git commit id in Linus's tree :(

Re: [PATCH 09/15] net: irda: pxaficp_ir: remove the dmaengine compat need

[Greg Kroah-Hartman]

On Mon, Apr 02, 2018 at 04:26:50PM +0200, Robert Jarzmik wrote:
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.
> 
> This patch simplifies the dma resource acquisition, using the more
> generic function dma_request_slave_channel().
> 
> Signed-off-by: Robert Jarzmik 
> ---
>  drivers/staging/irda/drivers/pxaficp_ir.c | 14 ++
>  1 file changed, 2 insertions(+), 12 deletions(-)

This file is no longer in Linus's tree :)

thanks,

greg k-h

Re: [PATCH] media: staging/imx: fill vb2_v4l2_buffer sequence entry

[Greg Kroah-Hartman]

On Tue, Mar 13, 2018 at 09:00:54PM +0100, Peter Seiderer wrote:
> Signed-off-by: Peter Seiderer 
> ---
>  drivers/staging/media/imx/imx-media-csi.c | 5 +
>  1 file changed, 5 insertions(+)

I know I don't take patches with an empty changelog description, but
other maintainers might be much more forgiving... :)

Re: [PATCH] staging: media: remove unused VIDEO_ATOMISP_OV8858 kconfig

[Greg Kroah-Hartman]

On Tue, Jan 23, 2018 at 07:31:27PM +0200, Andy Shevchenko wrote:
> On Tue, Jan 23, 2018 at 4:37 PM, Corentin Labbe  wrote:
> > Nothing in kernel use VIDEO_ATOMISP_OV8858 since commit 3a81c7660f80 
> > ("media: staging: atomisp: Remove IMX sensor support")
> > Lets remove this kconfig option.
> 
> First of all, I hardly understand how that change is related.
> Second, did you check Makefile?

I don't see it being used in any Makefile, what file do you see it:
$ git grep VIDEO_ATOMISP_OV8858
drivers/staging/media/atomisp/i2c/Kconfig:config VIDEO_ATOMISP_OV8858

So it should be removed.

thanks,

greg k-h

Re: [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

[Greg Kroah-Hartman]

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 with operations
> > performed by userspace through ioctls or other file operations on video
> > device nodes.
> > 
> > This leads to potential access to freed memory or to other resources
> > during device access if unplug occurs during device access. To solve
> > this, we need to wait until all device access completes when unplugging
> > the device, and block all further access when the device is being
> > unplugged.
> > 
> > Three new functions are introduced. The video_device_enter() and
> > video_device_exit() functions must be used to mark entry and exit from
> > all code sections where the device can be accessed. The
> > video_device_unplug() function is then used in the unplug handler to
> > mark the device as being unplugged and wait for all access to complete.
> > 
> > As an example mark the ioctl handler as a device access section. Other
> > file operations need to be protected too, and blocking ioctls (such as
> > VIDIOC_DQBUF) need to be handled as well.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >  drivers/media/v4l2-core/v4l2-dev.c | 57 
> > ++
> >  include/media/v4l2-dev.h   | 47 +++
> >  2 files changed, 104 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
> > b/drivers/media/v4l2-core/v4l2-dev.c
> > index c647ba648805..c73c6d49e7cf 100644
> > --- a/drivers/media/v4l2-core/v4l2-dev.c
> > +++ b/drivers/media/v4l2-core/v4l2-dev.c
> > @@ -156,6 +156,52 @@ void video_device_release_empty(struct video_device 
> > *vdev)
> >  }
> >  EXPORT_SYMBOL(video_device_release_empty);
> >  
> > +int video_device_enter(struct video_device *vdev)
> > +{
> > +   bool unplugged;
> > +
> > +   spin_lock(>unplug_lock);
> > +   unplugged = vdev->unplugged;
> > +   if (!unplugged)
> > +   vdev->access_refcount++;
> > +   spin_unlock(>unplug_lock);
> > +
> > +   return unplugged ? -ENODEV : 0;
> > +}
> > +EXPORT_SYMBOL_GPL(video_device_enter);
> > +
> > +void video_device_exit(struct video_device *vdev)
> > +{
> > +   bool wake_up;
> > +
> > +   spin_lock(>unplug_lock);
> > +   WARN_ON(--vdev->access_refcount < 0);
> > +   wake_up = vdev->access_refcount == 0;
> > +   spin_unlock(>unplug_lock);
> > +
> > +   if (wake_up)
> > +   wake_up(>unplug_wait);
> > +}
> > +EXPORT_SYMBOL_GPL(video_device_exit);
> > +
> > +void video_device_unplug(struct video_device *vdev)
> > +{
> > +   bool unplug_blocked;
> > +
> > +   spin_lock(>unplug_lock);
> > +   unplug_blocked = vdev->access_refcount > 0;
> > +   vdev->unplugged = true;
> > +   spin_unlock(>unplug_lock);
> > +
> > +   if (!unplug_blocked)
> > +   return;
> > +
> > +   if (!wait_event_timeout(vdev->unplug_wait, !vdev->access_refcount,
> > +   msecs_to_jiffies(15)))
> > +   WARN(1, "Timeout waiting for device access to complete\n");
> > +}
> > +EXPORT_SYMBOL_GPL(video_device_unplug);
> > +
> >  static inline void video_get(struct video_device *vdev)
> >  {
> > get_device(>dev);
> > @@ -351,6 +397,10 @@ static long v4l2_ioctl(struct file *filp, unsigned int 
> > cmd, unsigned long arg)
> > struct video_device *vdev = video_devdata(filp);
> > int ret = -ENODEV;
> >  
> > +   ret = video_device_enter(vdev);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > if (vdev->fops->unlocked_ioctl) {
> > struct mutex *lock = v4l2_ioctl_get_lock(vdev, cmd);
> >  
> > @@ -358,11 +408,14 @@ static long v4l2_ioctl(struct file *filp, unsigned 
> > int cmd, unsigned long arg)
> > return -ERESTARTSYS;
> > if (video_is_registered(vdev))
> > ret = vdev->fops->unlocked_ioctl(filp, cmd, arg);
> > +   else
> > +   ret = -ENODEV;
> > if (lock)
> > mutex_unlock(lock);
> > } else
> > ret = -ENOTTY;
> >  
> > +   video_device_exit(vdev);
> > return ret;
> >  }
> >  
> > @@ -841,6 +894,10 @@ int __video_register_device(struct video_device *vdev, 
> > int type, int nr,
> > if (WARN_ON(!vdev->v4l2_dev))
> > return -EINVAL;
> >  
> > +   /* unplug support */
> > +   spin_lock_init(>unplug_lock);
> > +   init_waitqueue_head(>unplug_wait);
> > +
> 
> I'm c/c Greg here, as I don't think, that, the way it is, it
> belongs at V4L2 core.
> 
> I mean: if this is a problem that affects all drivers, it would should, 
> instead, be sitting at the driver's core.

What "problem" is trying to be solved here?  One where your specific
device type races with your specific user api?  Doesn't sound very
driver-core specific to me :)

As an example, what other bus/device type needs 

Re: [PATCH] media: usbvision: remove unneeded DRIVER_LICENSE #define

[Greg Kroah-Hartman]

On Fri, Nov 17, 2017 at 06:26:30PM +0100, Philippe Ombredanne wrote:
> On Fri, Nov 17, 2017 at 6:01 PM, Mauro Carvalho Chehab
> <mche...@s-opensource.com> wrote:
> > Em Fri, 17 Nov 2017 16:01:41 +0100
> > Philippe Ombredanne <pombreda...@nexb.com> escreveu:
> >
> >> On Fri, Nov 17, 2017 at 3:58 PM, Mauro Carvalho Chehab
> >> <mche...@s-opensource.com> wrote:
> >> > Em Fri, 17 Nov 2017 15:18:26 +0100
> >> > Greg Kroah-Hartman <gre...@linuxfoundation.org> escreveu:
> >> >
> >> > Its license is actually GPL 2.0+
> >> >
> >> > So, I would actually change it to:
> >> >
> >> > MODULE_LICENSE("GPL v2");
> >>
> >> Mauro:
> >>
> >> actually even if it sounds weird the module.h doc [1] is clear on this 
> >> topic:
> >>
> >>  * "GPL" [GNU Public License v2 or later]
> >>  * "GPL v2" [GNU Public License v2]
> >>
> >> So it should be "GPL" IMHO.
> >>
> >>
> >> [1] 
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h?id=refs/tags/v4.10#n175
> >>
> >
> > Oh! Yeah, you're right. I would add that on the Kernel documentation
> > somewhere, perhaps with the new document that Thomas is writing
> > about SPFX.
> > The Documentation/kernel-hacking/hacking.rst doc mentions
> > MODULE_LICENSE, but doesn't define the expected values for it.
> 
> 
> Good point!
> 
> Thomas:
> Is this something that should be taken care of?
> If yes, I may be able take a crack at it sometimes next week.
> 
> unless...
> 
> Mauro:
> if you have a docwriter soul and want to make a good deed for the
> holidays, may you feel like starting a doc patch? :P
> 
> e.g. something along the lines:
> 
> "Here are the valid values for MODULE_LICENSE as found in module.h ...
> And here are the rules to set a MODULE_LICENSE and how this relates to
> the top level SPDX-License-Identifier..."
> 
> BTW, I wished we could align the MODULE_LICENSE values with the SPDX
> ids for clarity and as this would inject normalized SPDX license tags
> in the Elf binaries.
> 
> But that 's likely impossible as it would break a truck load of
> out-of-tree module macros and out-of-tree module loading command line
> tools everywhere (such as busybox and many other) so the (computing)
> world would crawl to a halt. *sigh*

That's a much longer-term project, let's get the obvious things done
first before worrying about this type of thing :)

thanks,

greg k-h

Re: [PATCH] media: usbvision: remove unneeded DRIVER_LICENSE #define

[Greg Kroah-Hartman]

On Fri, Nov 17, 2017 at 03:01:02PM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 17 Nov 2017 16:01:41 +0100
> Philippe Ombredanne <pombreda...@nexb.com> escreveu:
> 
> > On Fri, Nov 17, 2017 at 3:58 PM, Mauro Carvalho Chehab
> > <mche...@s-opensource.com> wrote:
> > > Em Fri, 17 Nov 2017 15:18:26 +0100
> > > Greg Kroah-Hartman <gre...@linuxfoundation.org> escreveu:
> > >  
> > >> There is no need to #define the license of the driver, just put it in
> > >> the MODULE_LICENSE() line directly as a text string.
> > >>
> > >> This allows tools that check that the module license matches the source
> > >> code license to work properly, as there is no need to unwind the
> > >> unneeded dereference.
> > >>
> > >> Cc: Hans Verkuil <hverk...@xs4all.nl>
> > >> Cc: Mauro Carvalho Chehab <mche...@kernel.org>
> > >> Cc: Johan Hovold <jo...@kernel.org>
> > >> Cc: Davidlohr Bueso <d...@stgolabs.net>
> > >> Cc: Sakari Ailus <sakari.ai...@linux.intel.com>
> > >> Reported-by: Philippe Ombredanne <pombreda...@nexb.com>
> > >> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> 
> Acked-by: Mauro Carvalho Chehab <mche...@kernel.org>
> 
> > >> ---
> > >>  drivers/media/usb/usbvision/usbvision-video.c | 3 +--
> > >>  1 file changed, 1 insertion(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/media/usb/usbvision/usbvision-video.c 
> > >> b/drivers/media/usb/usbvision/usbvision-video.c
> > >> index 960272d3c924..0f5954a1fea2 100644
> > >> --- a/drivers/media/usb/usbvision/usbvision-video.c
> > >> +++ b/drivers/media/usb/usbvision/usbvision-video.c
> > >> @@ -72,7 +72,6 @@
> > >>  #define DRIVER_NAME "usbvision"
> > >>  #define DRIVER_ALIAS "USBVision"
> > >>  #define DRIVER_DESC "USBVision USB Video Device Driver for Linux"
> > >> -#define DRIVER_LICENSE "GPL"
> > >>  #define USBVISION_VERSION_STRING "0.9.11"
> > >>
> > >>  #define  ENABLE_HEXDUMP  0   /* Enable if you need it */
> > >> @@ -141,7 +140,7 @@ MODULE_PARM_DESC(radio_nr, "Set radio device number 
> > >> (/dev/radioX).  Default: -1
> > >>  /* Misc stuff */
> > >>  MODULE_AUTHOR(DRIVER_AUTHOR);
> > >>  MODULE_DESCRIPTION(DRIVER_DESC);
> > >> -MODULE_LICENSE(DRIVER_LICENSE);
> > >> +MODULE_LICENSE("GPL");  
> > >
> > > Makes sense to me, but, if we look at the header of this file:
> > >
> > >  * This program is free software; you can redistribute it and/or modify
> > >  * it under the terms of the GNU General Public License as published by
> > >  * the Free Software Foundation; either version 2 of the License, or
> > >  * (at your option) any later version.
> > >
> > > Its license is actually GPL 2.0+
> > >
> > > So, I would actually change it to:
> > >
> > > MODULE_LICENSE("GPL v2");  
> > 
> > Mauro:
> > 
> > actually even if it sounds weird the module.h doc [1] is clear on this 
> > topic:
> > 
> >  * "GPL" [GNU Public License v2 or later]
> >  * "GPL v2" [GNU Public License v2]
> > 
> > So it should be "GPL" IMHO.
> > 
> > 
> > [1] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h?id=refs/tags/v4.10#n175
> > 
> 
> Oh! Yeah, you're right. I would add that on the Kernel documentation
> somewhere, perhaps with the new document that Thomas is writing
> about SPFX. 
> 
> The Documentation/kernel-hacking/hacking.rst doc mentions 
> MODULE_LICENSE, but doesn't define the expected values for it.

It's buried in the code comments in include/linux/module.h.  One of
these days I want to just make a #define for the licenses that makes it
a bit more obvious what each should be, but for now, we have lots of
other things to clean up before dealing with this :)

thanks,

greg k-h

Re: [PATCH] media: usbvision: remove unneeded DRIVER_LICENSE #define

[Greg Kroah-Hartman]

On Fri, Nov 17, 2017 at 12:58:47PM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 17 Nov 2017 15:18:26 +0100
> Greg Kroah-Hartman <gre...@linuxfoundation.org> escreveu:
> 
> > There is no need to #define the license of the driver, just put it in
> > the MODULE_LICENSE() line directly as a text string.
> > 
> > This allows tools that check that the module license matches the source
> > code license to work properly, as there is no need to unwind the
> > unneeded dereference.
> > 
> > Cc: Hans Verkuil <hverk...@xs4all.nl>
> > Cc: Mauro Carvalho Chehab <mche...@kernel.org>
> > Cc: Johan Hovold <jo...@kernel.org>
> > Cc: Davidlohr Bueso <d...@stgolabs.net>
> > Cc: Sakari Ailus <sakari.ai...@linux.intel.com>
> > Reported-by: Philippe Ombredanne <pombreda...@nexb.com>
> > Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> > ---
> >  drivers/media/usb/usbvision/usbvision-video.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/media/usb/usbvision/usbvision-video.c 
> > b/drivers/media/usb/usbvision/usbvision-video.c
> > index 960272d3c924..0f5954a1fea2 100644
> > --- a/drivers/media/usb/usbvision/usbvision-video.c
> > +++ b/drivers/media/usb/usbvision/usbvision-video.c
> > @@ -72,7 +72,6 @@
> >  #define DRIVER_NAME "usbvision"
> >  #define DRIVER_ALIAS "USBVision"
> >  #define DRIVER_DESC "USBVision USB Video Device Driver for Linux"
> > -#define DRIVER_LICENSE "GPL"
> >  #define USBVISION_VERSION_STRING "0.9.11"
> >  
> >  #defineENABLE_HEXDUMP  0   /* Enable if you need it */
> > @@ -141,7 +140,7 @@ MODULE_PARM_DESC(radio_nr, "Set radio device number 
> > (/dev/radioX).  Default: -1
> >  /* Misc stuff */
> >  MODULE_AUTHOR(DRIVER_AUTHOR);
> >  MODULE_DESCRIPTION(DRIVER_DESC);
> > -MODULE_LICENSE(DRIVER_LICENSE);
> > +MODULE_LICENSE("GPL");
> 
> Makes sense to me, but, if we look at the header of this file:
> 
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License as published by
>  * the Free Software Foundation; either version 2 of the License, or
>  * (at your option) any later version.
> 
> Its license is actually GPL 2.0+
> 
> So, I would actually change it to:
> 
> MODULE_LICENSE("GPL v2");

As Philippe points out, the original marking is correct.

Once we get SPDX tags on all of the kernel files, mis-matches, if they
are present, will be obvious to check for and fix up.  Which is why I
have submitted this patch :)

thanks,

greg k-h

[PATCH] media: usbvision: remove unneeded DRIVER_LICENSE #define

[Greg Kroah-Hartman]

There is no need to #define the license of the driver, just put it in
the MODULE_LICENSE() line directly as a text string.

This allows tools that check that the module license matches the source
code license to work properly, as there is no need to unwind the
unneeded dereference.

Cc: Hans Verkuil <hverk...@xs4all.nl>
Cc: Mauro Carvalho Chehab <mche...@kernel.org>
Cc: Johan Hovold <jo...@kernel.org>
Cc: Davidlohr Bueso <d...@stgolabs.net>
Cc: Sakari Ailus <sakari.ai...@linux.intel.com>
Reported-by: Philippe Ombredanne <pombreda...@nexb.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/media/usb/usbvision/usbvision-video.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/usb/usbvision/usbvision-video.c 
b/drivers/media/usb/usbvision/usbvision-video.c
index 960272d3c924..0f5954a1fea2 100644
--- a/drivers/media/usb/usbvision/usbvision-video.c
+++ b/drivers/media/usb/usbvision/usbvision-video.c
@@ -72,7 +72,6 @@
 #define DRIVER_NAME "usbvision"
 #define DRIVER_ALIAS "USBVision"
 #define DRIVER_DESC "USBVision USB Video Device Driver for Linux"
-#define DRIVER_LICENSE "GPL"
 #define USBVISION_VERSION_STRING "0.9.11"
 
 #defineENABLE_HEXDUMP  0   /* Enable if you need it */
@@ -141,7 +140,7 @@ MODULE_PARM_DESC(radio_nr, "Set radio device number 
(/dev/radioX).  Default: -1
 /* Misc stuff */
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
-MODULE_LICENSE(DRIVER_LICENSE);
+MODULE_LICENSE("GPL");
 MODULE_VERSION(USBVISION_VERSION_STRING);
 MODULE_ALIAS(DRIVER_ALIAS);
 
-- 
2.15.0

Re: [PATCH v3 1/3] staging: greybus: light: fix memory leak in v4l2 register

[Greg Kroah-Hartman]

On Thu, Aug 10, 2017 at 06:49:45PM +0300, Sakari Ailus wrote:
> From: Rui Miguel Silva 
> 
> We are allocating memory for the v4l2 flash configuration structure and
> leak it in the normal path. Just use the stack for this as we do not
> use it outside of this function.
> 
> Also use IS_ERR() instead of IS_ERR_OR_NULL() to check return value from
> v4l2_flash_init() for it never returns NULL.
> 
> Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
> Reported-by: Sakari Ailus 
> Signed-off-by: Rui Miguel Silva 
> Reviewed-by: Viresh Kumar 
> Signed-off-by: Sakari Ailus 
> Acked-by: Hans Verkuil 
> ---
>  drivers/staging/greybus/light.c | 29 +
>  1 file changed, 9 insertions(+), 20 deletions(-)

Does not apply to my tree :(

Re: [PATCH v3.2 2/3] v4l2-flash-led-class: Create separate sub-devices for indicators

[Greg Kroah-Hartman]

On Tue, Aug 15, 2017 at 02:28:11PM +0300, Sakari Ailus wrote:
> The V4L2 flash interface allows controlling multiple LEDs through a single
> sub-devices if, and only if, these LEDs are of different types. This
> approach scales badly for flash controllers that drive multiple flash LEDs
> or for LED specific associations. Essentially, the original assumption of a
> LED driver chip that drives a single flash LED and an indicator LED is no
> longer valid.
> 
> Address the matter by registering one sub-device per LED.
> 
> Signed-off-by: Sakari Ailus 
> Reviewed-by: Jacek Anaszewski 
> Acked-by: Pavel Machek 
> Reviewed-by: Rui Miguel Silva  (for greybus/light)
> Acked-by: Hans Verkuil 
> ---
> since v3.2:

"3.2"?

Isn't that just "v5"?  Please don't be cute with version numbering, we
have a hard time telling what is going on, make it obvious...

thanks,

greg k-h

Re: [PATCH 00/14] gcc-7 warnings

[Greg Kroah-Hartman]

On Fri, Jul 14, 2017 at 11:25:12AM +0200, Arnd Bergmann wrote:
> This series should shut up all warnings introduced by gcc-6 or gcc-7 on
> today's linux-next, as observed in "allmodconfig" builds on x86,
> arm and arm64.
> 
> I have sent some of these before, but some others are new, as I had
> at some point disabled the -Wint-in-bool-context warning in my
> randconfig testing and did not notice the other warnings.
> 
> I have another series to address all -Wformat-overflow warnings,
> and one more patch to turn off the -Wformat-truncation warnings
> unless we build with "make W=1". I'll send that separately.
> 
> Most of these are consist of trivial refactoring of the code to
> shut up false-positive warnings, the one exception being
> "staging:iio:resolver:ad2s1210 fix negative IIO_ANGL_VEL read",
> which fixes a regression against linux-3.1 that has gone
> unnoticed since then. Still, review from subsystem maintainers
> would be appreciated.
> 
> I would suggest that Andrew Morton can pick these up into linux-mm
> so we can make sure they all make it into the release. Alternatively
> Linus might feel like picking them all up himself.
> 
> While I did not mark the harmless ones for stable backports,
> Greg may also want to pick them up once they go upstream, to
> help build-test the stable kernels with gcc-7.

Thanks for these, I'll keep an eye out for them to get into the stable
trees, so I can eventually update my test-build box to gcc-7.

thanks,

greg k-h

Re: Lots of new warnings with gcc-7.1.1

[Greg Kroah-Hartman]

On Tue, Jul 11, 2017 at 03:35:15PM -0700, Linus Torvalds wrote:
> [ Very random list of maintainers and mailing lists, at least
> partially by number of warnings generated by gcc-7.1.1 that is then
> correlated with the get_maintainers script ]
> 
> So I upgraded one of my boxes to F26, which upgraded the compiler to gcc-7.1.1
> 
> Which in turn means that my nice clean allmodconfig compile is not an
> unholy mess of annoying new warnings.

I asked Arnd about this the other day on IRC as I've hit this as well on
the stable releases, and it's really annoying.  He mentioned that he had
lots of these warnings fixed, but didn't push most of the changes out
yet.  Arnd, any repo with them in it that we could look at?

> Normally I hate the stupid new warnings, but this time around they are
> actually exactly the kinds of warnings you'd want to see and that are
> hard for humans to pick out errors: lots of format errors wrt limited
> buffer sizes.
> 
> At the same time, many of them *are* annoying. We have various limited
> buffers that are limited for a good reason, and some of the format
> truncation warnings are about numbers in the range {0-MAX_INT], where
> we definitely know that we don't need to worry about the really big
> ones.
> 
> After all, we're using "snprintf()" for a reason - we *want* to
> truncate if the buffer is too small.

Yeah, that's the warnings in the USB core code, we "know" this will not
happen, and we are using snprintf() for that reason as well, I don't
know how to fool gcc into the fact that it's all ok here.

> Anyway, it would be lovely if some of the more affected developers
> would take a look at gcc-7.1.1 warnings. Right now I get about three
> *thousand* lines of warnings from a "make allmodconfig" build, which
> makes them a bit overwhelming.

I only have 310 when building the 4.12.0 release with 7.1.1, I wonder if
Fedora turned more warnings on in their compiler release, I'm running
Arch here:
$ gcc --version
gcc (GCC) 7.1.1 20170621

thanks,

greg k-h

Re: [PATCH] staging: fbtft: make const array gamma_par_mask static

[Greg Kroah-Hartman]

On Tue, Jul 11, 2017 at 06:39:59PM +0100, Colin Ian King wrote:
> On 11/07/17 18:30, Greg Kroah-Hartman wrote:
> > On Tue, Jul 11, 2017 at 06:20:02PM +0100, Colin King wrote:
> >> From: Colin Ian King <colin.k...@canonical.com>
> >>
> >> Don't populate array gamma_par_mask on the stack but instead make it
> >> static.  Makes the object code smaller by 148 bytes:
> >>
> >> Before:
> >>text   data bss dec hex filename
> >>2993   1104   040971001 
> >> drivers/staging/fbtft/fb_st7789v.o
> >>
> >> After:
> >>text   data bss dec hex filename
> >>2757   1192   03949 f6d 
> >> drivers/staging/fbtft/fb_st7789v.o
> >>
> >> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> >> ---
> >>  drivers/media/usb/gspca/xirlink_cit.c | 2 +-
> >>  drivers/staging/fbtft/fb_st7789v.c| 2 +-
> >>  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > Your subject doesn't match the patch :(
> 
> Got distracted by the Trump Jnr tweet. Will resend.

Dude, the best thing is to just read:
https://whatthefuckjusthappenedtoday.com/
once a day, otherwise you will not get any work done ever again...

Re: [PATCH] staging: fbtft: make const array gamma_par_mask static

[Greg Kroah-Hartman]

On Tue, Jul 11, 2017 at 06:20:02PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Don't populate array gamma_par_mask on the stack but instead make it
> static.  Makes the object code smaller by 148 bytes:
> 
> Before:
>text  data bss dec hex filename
>2993  1104   040971001 
> drivers/staging/fbtft/fb_st7789v.o
> 
> After:
>text  data bss dec hex filename
>2757  1192   03949 f6d 
> drivers/staging/fbtft/fb_st7789v.o
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/media/usb/gspca/xirlink_cit.c | 2 +-
>  drivers/staging/fbtft/fb_st7789v.c| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Your subject doesn't match the patch :(

Re: [PATCH v2 24/27] usb: gadget: u_uac1: Kill set_fs() usage

[Greg Kroah-Hartman]

On Thu, Jun 01, 2017 at 10:58:47PM +0200, Takashi Iwai wrote:
> With the new API to perform the in-kernel buffer copy, we can get rid
> of set_fs() usage in this driver, finally.
> 
> Signed-off-by: Takashi Iwai <ti...@suse.de>
> ---

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

[PATCH 08/13] staging: media: atomisp: Make undeclared symbols static

[Greg Kroah-Hartman]

From: Guru Das Srinagesh <gurooo...@gmail.com>

Fix sparse warnings: "symbol not declared; should it be static?"

Signed-off-by: Guru Das Srinagesh <gurooo...@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c
index 7ce8803cf6f9..c151c848cf8f 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c
@@ -130,9 +130,9 @@ static int atomisp_q_one_metadata_buffer(struct 
atomisp_sub_device *asd,
return 0;
 }
 
-int atomisp_q_one_s3a_buffer(struct atomisp_sub_device *asd,
-   enum atomisp_input_stream_id stream_id,
-   enum atomisp_css_pipe_id css_pipe_id)
+static int atomisp_q_one_s3a_buffer(struct atomisp_sub_device *asd,
+   enum atomisp_input_stream_id stream_id,
+   enum atomisp_css_pipe_id css_pipe_id)
 {
struct atomisp_s3a_buf *s3a_buf;
struct list_head *s3a_list;
@@ -172,9 +172,9 @@ int atomisp_q_one_s3a_buffer(struct atomisp_sub_device *asd,
return 0;
 }
 
-int atomisp_q_one_dis_buffer(struct atomisp_sub_device *asd,
-   enum atomisp_input_stream_id stream_id,
-   enum atomisp_css_pipe_id css_pipe_id)
+static int atomisp_q_one_dis_buffer(struct atomisp_sub_device *asd,
+   enum atomisp_input_stream_id stream_id,
+   enum atomisp_css_pipe_id css_pipe_id)
 {
struct atomisp_dis_buf *dis_buf;
unsigned long irqflags;
@@ -744,7 +744,7 @@ static void atomisp_subdev_init_struct(struct 
atomisp_sub_device *asd)
 /*
  * file operation functions
  */
-unsigned int atomisp_subdev_users(struct atomisp_sub_device *asd)
+static unsigned int atomisp_subdev_users(struct atomisp_sub_device *asd)
 {
return asd->video_out_preview.users +
   asd->video_out_vf.users +
-- 
2.13.0

[PATCH 10/13] staging: media: atomisp: one char read beyond end of string

[Greg Kroah-Hartman]

From: Dan Carpenter <dan.carpen...@oracle.com>

We should verify that "ix < max_len" before we test whether we have
reached the NUL terminator.

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Reported-by: David Binderman <dcb...@hotmail.com>
Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 .../pci/atomisp2/css2400/hive_isp_css_include/string_support.h   | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/string_support.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/string_support.h
index 568631698a3d..74b5a1c7ac9a 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/string_support.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/string_support.h
@@ -72,9 +72,8 @@ static size_t strnlen_s(
return 0;
}
 
-   for (ix=0;
-   ((src_str[ix] != '\0') && (ix< max_len));
-   ++ix) /*Nothing else to do*/;
+   for (ix = 0; ix < max_len && src_str[ix] != '\0'; ix++)
+   ;
 
/* On Error, it will return src_size == max_len*/
return ix;
-- 
2.13.0

[PATCH 13/13] staging: media: atomisp: don't treat warnings as errors

[Greg Kroah-Hartman]

From: Mauro Carvalho Chehab <mche...@s-opensource.com>

Several atomisp files use:
 ccflags-y += -Werror

As, on media, our usual procedure is to use W=1, and atomisp
has *a lot* of warnings with such flag enabled,like:

./drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/system_local.h:62:26:
 warning: 'DDR_BASE' defined but not used [-Wunused-const-variable=]

At the end, it causes our build to fail, impacting our workflow.

So, remove this crap. If one wants to force -Werror, he
can still build with it enabled by passing a parameter to
make.

Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/staging/media/atomisp/i2c/Makefile  | 2 --
 drivers/staging/media/atomisp/i2c/imx/Makefile  | 2 --
 drivers/staging/media/atomisp/i2c/ov5693/Makefile   | 2 --
 drivers/staging/media/atomisp/pci/atomisp2/Makefile | 2 +-
 4 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/Makefile 
b/drivers/staging/media/atomisp/i2c/Makefile
index 8ea01904c0ea..466517c7c8e6 100644
--- a/drivers/staging/media/atomisp/i2c/Makefile
+++ b/drivers/staging/media/atomisp/i2c/Makefile
@@ -19,5 +19,3 @@ obj-$(CONFIG_VIDEO_AP1302) += ap1302.o
 
 obj-$(CONFIG_VIDEO_LM3554) += lm3554.o
 
-ccflags-y += -Werror
-
diff --git a/drivers/staging/media/atomisp/i2c/imx/Makefile 
b/drivers/staging/media/atomisp/i2c/imx/Makefile
index 1d7f7ab94cac..6b13a3a66e49 100644
--- a/drivers/staging/media/atomisp/i2c/imx/Makefile
+++ b/drivers/staging/media/atomisp/i2c/imx/Makefile
@@ -4,5 +4,3 @@ imx1x5-objs := imx.o drv201.o ad5816g.o dw9714.o dw9719.o 
dw9718.o vcm.o otp.o o
 
 ov8858_driver-objs := ../ov8858.o dw9718.o vcm.o
 obj-$(CONFIG_VIDEO_OV8858) += ov8858_driver.o
-
-ccflags-y += -Werror
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/Makefile 
b/drivers/staging/media/atomisp/i2c/ov5693/Makefile
index fceb9e9b881b..c9c0e1245858 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/Makefile
+++ b/drivers/staging/media/atomisp/i2c/ov5693/Makefile
@@ -1,3 +1 @@
 obj-$(CONFIG_VIDEO_OV5693) += ov5693.o
-
-ccflags-y += -Werror
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/Makefile 
b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
index 3fa7c1c1479f..f126a89a08e9 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/Makefile
+++ b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
@@ -351,5 +351,5 @@ DEFINES := -DHRT_HW -DHRT_ISP_CSS_CUSTOM_HOST 
-DHRT_USE_VIR_ADDRS -D__HOST__
 DEFINES += -DATOMISP_POSTFIX=\"css2400b0_v21\" -DISP2400B0
 DEFINES += -DSYSTEM_hive_isp_css_2400_system -DISP2400
 
-ccflags-y += $(INCLUDES) $(DEFINES) -fno-common -Werror
+ccflags-y += $(INCLUDES) $(DEFINES) -fno-common
 
-- 
2.13.0

[PATCH 11/13] staging: media: atomisp: putting NULs in the wrong place

[Greg Kroah-Hartman]

From: Dan Carpenter <dan.carpen...@oracle.com>

We're putting the NUL terminators one space beyond where they belong.
This doesn't show up in testing because all but the callers put a NUL in
the correct place themselves.  LOL.  It causes a static checker warning
about buffer overflows.

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 .../pci/atomisp2/css2400/hive_isp_css_include/string_support.h| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/string_support.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/string_support.h
index 74b5a1c7ac9a..c53241a7a281 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/string_support.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/string_support.h
@@ -117,7 +117,7 @@ STORAGE_CLASS_INLINE int strncpy_s(
 
/* dest_str is big enough for the len */
strncpy(dest_str, src_str, len);
-   dest_str[len+1] = '\0';
+   dest_str[len] = '\0';
return 0;
 }
 
@@ -157,7 +157,7 @@ STORAGE_CLASS_INLINE int strcpy_s(
 
/* dest_str is big enough for the len */
strncpy(dest_str, src_str, len);
-   dest_str[len+1] = '\0';
+   dest_str[len] = '\0';
return 0;
 }
 
-- 
2.13.0

[PATCH 12/13] staging: media: atomisp: fix missing blank line coding style issue in atomisp_tpg.c

[Greg Kroah-Hartman]

From: Manny Vindiola <man...@gmail.com>

This is a patch to the atomisp_tpg.c file that fixes up a missing
blank line warning found by the checkpatch.pl tool

Signed-off-by: Manny Vindiola <man...@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c
index 996d1bdebad4..48b96048cab4 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c
@@ -56,6 +56,7 @@ static int tpg_set_fmt(struct v4l2_subdev *sd,
   struct v4l2_subdev_format *format)
 {
struct v4l2_mbus_framefmt *fmt = >format;
+
if (format->pad)
return -EINVAL;
/* only raw8 grbg is supported by TPG */
-- 
2.13.0

[PATCH 09/13] staging: media: atomisp: Fix -Werror=int-in-bool-context compile errors

[Greg Kroah-Hartman]

From: Hans de Goede <hdego...@redhat.com>

With gcc-7.1.1 I was getting the following compile error:

error: ‘*’ in boolean context, suggest ‘&&’ instead

The problem is the definition of CEIL_DIV:
 #define CEIL_DIV(a, b)   ((b) ? ((a) + (b) - 1) / (b) : 0)

Which when called as: CEIL_DIV(x, y * z) triggers this error, note
we cannot do as the error suggests since b is evaluated multiple times.

This commit fixes these compile errors.

Signed-off-by: Hans de Goede <hdego...@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c   | 1 -
 .../pci/atomisp2/css2400/hive_isp_css_include/math_support.h| 6 +++---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
index b830b241e2e6..ad2c610d2ce3 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
@@ -2506,7 +2506,6 @@ static void __configure_capture_pp_input(struct 
atomisp_sub_device *asd,
struct ia_css_pipe_extra_config *pipe_extra_configs =
_env->pipe_extra_configs[pipe_id];
unsigned int hor_ds_factor = 0, ver_ds_factor = 0;
-#define CEIL_DIV(a, b)   ((b) ? ((a) + (b) - 1) / (b) : 0)
 
if (width == 0 && height == 0)
return;
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/math_support.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/math_support.h
index 48d84bc0ad9e..f74b405b0f39 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/math_support.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/math_support.h
@@ -62,15 +62,15 @@
 #define MAX(a, b)(((a) > (b)) ? (a) : (b))
 #define MIN(a, b)(((a) < (b)) ? (a) : (b))
 #ifdef ISP2401
-#define ROUND_DIV(a, b)  ((b) ? ((a) + ((b) >> 1)) / (b) : 0)
+#define ROUND_DIV(a, b)  (((b) != 0) ? ((a) + ((b) >> 1)) / (b) : 0)
 #endif
-#define CEIL_DIV(a, b)   ((b) ? ((a) + (b) - 1) / (b) : 0)
+#define CEIL_DIV(a, b)   (((b) != 0) ? ((a) + (b) - 1) / (b) : 0)
 #define CEIL_MUL(a, b)   (CEIL_DIV(a, b) * (b))
 #define CEIL_MUL2(a, b)  (((a) + (b) - 1) & ~((b) - 1))
 #define CEIL_SHIFT(a, b) (((a) + (1 << (b)) - 1)>>(b))
 #define CEIL_SHIFT_MUL(a, b) (CEIL_SHIFT(a, b) << (b))
 #ifdef ISP2401
-#define ROUND_HALF_DOWN_DIV(a, b)  ((b) ? ((a) + (b / 2) - 1) / (b) : 0)
+#define ROUND_HALF_DOWN_DIV(a, b)  (((b) != 0) ? ((a) + (b / 2) - 1) / (b) 
: 0)
 #define ROUND_HALF_DOWN_MUL(a, b)  (ROUND_HALF_DOWN_DIV(a, b) * (b))
 #endif
 
-- 
2.13.0

[PATCH 02/13] staging: media: atomisp: use logical AND, not bitwise

[Greg Kroah-Hartman]

From: Guru Das Srinagesh <gurooo...@gmail.com>

Fixes sparse warning "dubious: x & !y" in logical expression.

Signed-off-by: Guru Das Srinagesh <gurooo...@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 .../media/atomisp/pci/atomisp2/css2400/runtime/binary/src/binary.c  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/binary/src/binary.c
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/binary/src/binary.c
index a8b93a756e41..ae0b229c9fb8 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/binary/src/binary.c
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/binary/src/binary.c
@@ -1658,7 +1658,7 @@ ia_css_binary_find(struct ia_css_binary_descr *descr,
candidate->internal.max_height);
continue;
}
-   if (!candidate->enable.ds && need_ds & 
!(xcandidate->num_output_pins > 1)) {
+   if (!candidate->enable.ds && need_ds && 
!(xcandidate->num_output_pins > 1)) {
ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE,
"ia_css_binary_find() [%d] continue: !%d && 
%d\n",
__LINE__, candidate->enable.ds, (int)need_ds);
-- 
2.13.0

[PATCH 06/13] staging: media: atomisp: fixed coding style errors

[Greg Kroah-Hartman]

From: Avraham Shukron <avraham.shuk...@gmail.com>

Fix for error (not warnings) reported by checkpatch.pl
Specifically:
 - missing whitespace around "=" and after ","
 - indentation with spaces instead of tabs
 - lines starting with a whitespace

This patch does not affect the compiled code in any way.

Signed-off-by: Avraham Shukron <avraham.shuk...@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 .../platform/intel-mid/atomisp_gmin_platform.c | 156 ++---
 .../platform/intel-mid/intel_mid_pcihelpers.c  |   2 +-
 2 files changed, 79 insertions(+), 79 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 15409e96449d..2a819ac6f9e2 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -51,7 +51,7 @@ struct gmin_subdev {
 
 static struct gmin_subdev gmin_subdevs[MAX_SUBDEVS];
 
-static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI ,
+static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI,
PMIC_CRYSTALCOVE } pmic_id;
 
 /* The atomisp uses type==0 for the end-of-list marker, so leave space. */
@@ -152,13 +152,13 @@ const struct camera_af_platform_data 
*camera_get_af_platform_data(void)
 EXPORT_SYMBOL_GPL(camera_get_af_platform_data);
 
 int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
-struct camera_sensor_platform_data *plat_data,
-enum intel_v4l2_subdev_type type)
+   struct camera_sensor_platform_data *plat_data,
+   enum intel_v4l2_subdev_type type)
 {
int i;
struct i2c_board_info *bi;
struct gmin_subdev *gs;
-struct i2c_client *client = v4l2_get_subdevdata(subdev);
+   struct i2c_client *client = v4l2_get_subdevdata(subdev);
struct acpi_device *adev;
 
dev_info(>dev, "register atomisp i2c module type %d\n", type);
@@ -172,7 +172,7 @@ int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
if (adev)
adev->power.flags.power_resources = 0;
 
-   for (i=0; i < MAX_SUBDEVS; i++)
+   for (i = 0; i < MAX_SUBDEVS; i++)
if (!pdata.subdevs[i].type)
break;
 
@@ -206,7 +206,7 @@ struct v4l2_subdev *atomisp_gmin_find_subdev(struct 
i2c_adapter *adapter,
 struct i2c_board_info *board_info)
 {
int i;
-   for (i=0; i < MAX_SUBDEVS && pdata.subdevs[i].type; i++) {
+   for (i = 0; i < MAX_SUBDEVS && pdata.subdevs[i].type; i++) {
struct intel_v4l2_subdev_table *sd = [i];
if (sd->v4l2_subdev.i2c_adapter_id == adapter->nr &&
sd->v4l2_subdev.board_info.addr == board_info->addr)
@@ -270,45 +270,45 @@ static const struct gmin_cfg_var t100_vars[] = {
 };
 
 static const struct gmin_cfg_var mrd7_vars[] = {
-{"INT33F8:00_CamType", "1"},
-{"INT33F8:00_CsiPort", "1"},
-{"INT33F8:00_CsiLanes","2"},
-{"INT33F8:00_CsiFmt","13"},
-{"INT33F8:00_CsiBayer", "0"},
-{"INT33F8:00_CamClk", "0"},
-{"INT33F9:00_CamType", "1"},
-{"INT33F9:00_CsiPort", "0"},
-{"INT33F9:00_CsiLanes","1"},
-{"INT33F9:00_CsiFmt","13"},
-{"INT33F9:00_CsiBayer", "0"},
-{"INT33F9:00_CamClk", "1"},
-{},
+   {"INT33F8:00_CamType", "1"},
+   {"INT33F8:00_CsiPort", "1"},
+   {"INT33F8:00_CsiLanes", "2"},
+   {"INT33F8:00_CsiFmt", "13"},
+   {"INT33F8:00_CsiBayer", "0"},
+   {"INT33F8:00_CamClk", "0"},
+   {"INT33F9:00_CamType", "1"},
+   {"INT33F9:00_CsiPort", "0"},
+   {"INT33F9:00_CsiLanes", "1"},
+   {"INT33F9:00_CsiFmt", "13"},
+   {"INT33F9:00_CsiBayer", "0"},
+   {"INT33F9:00_CamClk", "1"},
+   {},
 };
 
 static const struct gmin_cfg_var ecs7_vars[] = {
-{"INT33BE:00_CsiPort", "1"},
-{"INT33BE:00_CsiLanes","2"},
-{"INT33BE:00_CsiFmt","13"},
-{"INT33BE:00_CsiBayer", "2"},
-{"INT33BE:00_CamClk", "0"},
-{"INT33F0:

[PATCH 07/13] staging: media: atomisp: fix coding style warnings

[Greg Kroah-Hartman]

From: Avraham Shukron <avraham.shuk...@gmail.com>

Fix for warnings reported by checkpatch.pl:
 - Multiline comment style
 - Bare "unsigned"
 - Missing blank line after declarations
 - Un-needed braces around single-statement branch

Signed-off-by: Avraham Shukron <avraham.shuk...@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 .../platform/intel-mid/atomisp_gmin_platform.c | 45 ++
 .../platform/intel-mid/intel_mid_pcihelpers.c  |  9 +++--
 2 files changed, 35 insertions(+), 19 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 2a819ac6f9e2..d68e9cf33aa7 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -119,7 +119,7 @@ static int af_power_ctrl(struct v4l2_subdev *subdev, int 
flag)
/*
 * The power here is used for dw9817,
 * regulator is from rear sensor
-   */
+*/
if (gs->v2p8_vcm_reg) {
if (flag)
return regulator_enable(gs->v2p8_vcm_reg);
@@ -167,7 +167,8 @@ int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
 * uses ACPI runtime power management for camera devices, but
 * we don't.  Disable it, or else the rails will be needlessly
 * tickled during suspend/resume.  This has caused power and
-* performance issues on multiple devices. */
+* performance issues on multiple devices.
+*/
adev = ACPI_COMPANION(>dev);
if (adev)
adev->power.flags.power_resources = 0;
@@ -182,7 +183,8 @@ int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
/* Note subtlety of initialization order: at the point where
 * this registration API gets called, the platform data
 * callbacks have probably already been invoked, so the
-* gmin_subdev struct is already initialized for us. */
+* gmin_subdev struct is already initialized for us.
+*/
gs = find_gmin_subdev(subdev);
 
pdata.subdevs[i].type = type;
@@ -206,8 +208,10 @@ struct v4l2_subdev *atomisp_gmin_find_subdev(struct 
i2c_adapter *adapter,
 struct i2c_board_info *board_info)
 {
int i;
+
for (i = 0; i < MAX_SUBDEVS && pdata.subdevs[i].type; i++) {
struct intel_v4l2_subdev_table *sd = [i];
+
if (sd->v4l2_subdev.i2c_adapter_id == adapter->nr &&
sd->v4l2_subdev.board_info.addr == board_info->addr)
return sd->subdev;
@@ -261,7 +265,8 @@ static const struct gmin_cfg_var ffrd8_vars[] = {
 };
 
 /* Cribbed from MCG defaults in the mt9m114 driver, not actually verified
- * vs. T100 hardware */
+ * vs. T100 hardware
+ */
 static const struct gmin_cfg_var t100_vars[] = {
{ "INT33F0:00_CsiPort",  "0" },
{ "INT33F0:00_CsiLanes", "1" },
@@ -345,10 +350,8 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
struct device *dev;
struct i2c_client *client = v4l2_get_subdevdata(subdev);
 
-   if (!pmic_id) {
-
-   pmic_id = PMIC_REGULATOR;
-   }
+   if (!pmic_id)
+   pmic_id = PMIC_REGULATOR;
 
if (!client)
return NULL;
@@ -401,7 +404,8 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
 * API is broken with the current drivers, returning
 * "1" for a regulator that will then emit a
 * "unbalanced disable" WARNing if we try to disable
-* it. */
+* it.
+*/
}
 
return _subdevs[i];
@@ -410,6 +414,7 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
 static struct gmin_subdev *find_gmin_subdev(struct v4l2_subdev *subdev)
 {
int i;
+
for (i = 0; i < MAX_SUBDEVS; i++)
if (gmin_subdevs[i].subdev == subdev)
return _subdevs[i];
@@ -419,6 +424,7 @@ static struct gmin_subdev *find_gmin_subdev(struct 
v4l2_subdev *subdev)
 static int gmin_gpio0_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
+
if (gs && gs->gpio0) {
gpiod_set_value(gs->gpio0, on);
return 0;
@@ -429,6 +435,7 @@ static int gmin_gpio0_ctrl(struct v4l2_subdev *subdev, int 
on)
 static int gmin_gpio1_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
+
if (gs && gs->gpio1) {
gpiod_set_value(gs->gpio1, on);
 

[PATCH 01/13] staging: media: atomisp: Add __printf validation and fix fallout

[Greg Kroah-Hartman]

From: Joe Perches <j...@perches.com>

__printf validation adds format and argument validation.

Fix the various broken format/argument mismatches.

Signed-off-by: Joe Perches <j...@perches.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 .../isp/kernels/sdis/sdis_1.0/ia_css_sdis.host.c  |  6 +++---
 .../isp/kernels/sdis/sdis_2/ia_css_sdis2.host.c   |  2 +-
 .../css2400/isp/kernels/tnr/tnr_1.0/ia_css_tnr.host.c |  2 +-
 .../css2400/runtime/debug/interface/ia_css_debug.h|  1 +
 .../atomisp2/css2400/runtime/debug/src/ia_css_debug.c |  6 +++---
 .../media/atomisp/pci/atomisp2/css2400/sh_css.c   | 19 ++-
 .../media/atomisp/pci/atomisp2/css2400/sh_css_mipi.c  |  2 +-
 .../atomisp/pci/atomisp2/css2400/sh_css_params.c  | 10 +-
 8 files changed, 25 insertions(+), 23 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/sdis/sdis_1.0/ia_css_sdis.host.c
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/sdis/sdis_1.0/ia_css_sdis.host.c
index 0daab1176865..9478c12abe89 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/sdis/sdis_1.0/ia_css_sdis.host.c
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/sdis/sdis_1.0/ia_css_sdis.host.c
@@ -265,9 +265,9 @@ ia_css_translate_dvs_statistics(
assert(isp_stats->hor_proj != NULL);
assert(isp_stats->ver_proj != NULL);
 
-   IA_CSS_ENTER("hproj=%p, vproj=%p, haddr=%x, vaddr=%x",
-   host_stats->hor_proj, host_stats->ver_proj,
-   isp_stats->hor_proj, isp_stats->ver_proj);
+   IA_CSS_ENTER("hproj=%p, vproj=%p, haddr=%p, vaddr=%p",
+host_stats->hor_proj, host_stats->ver_proj,
+isp_stats->hor_proj, isp_stats->ver_proj);
 
hor_num_isp = host_stats->grid.aligned_height;
ver_num_isp = host_stats->grid.aligned_width;
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/sdis/sdis_2/ia_css_sdis2.host.c
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/sdis/sdis_2/ia_css_sdis2.host.c
index 5a0c103e9eb7..9bccb6473154 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/sdis/sdis_2/ia_css_sdis2.host.c
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/sdis/sdis_2/ia_css_sdis2.host.c
@@ -213,7 +213,7 @@ ia_css_translate_dvs2_statistics(
 "hor_coefs.even_real=%p, hor_coefs.even_imag=%p, "
 "ver_coefs.odd_real=%p, ver_coefs.odd_imag=%p, "
 "ver_coefs.even_real=%p, ver_coefs.even_imag=%p, "
-"haddr=%x, vaddr=%x",
+"haddr=%p, vaddr=%p",
host_stats->hor_prod.odd_real, host_stats->hor_prod.odd_imag,
host_stats->hor_prod.even_real, host_stats->hor_prod.even_imag,
host_stats->ver_prod.odd_real, host_stats->ver_prod.odd_imag,
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/tnr/tnr_1.0/ia_css_tnr.host.c
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/tnr/tnr_1.0/ia_css_tnr.host.c
index 804c19ab4485..222a7bd7f176 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/tnr/tnr_1.0/ia_css_tnr.host.c
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/tnr/tnr_1.0/ia_css_tnr.host.c
@@ -55,7 +55,7 @@ ia_css_tnr_dump(
"tnr_coef", tnr->coef);
ia_css_debug_dtrace(level, "\t%-32s = %d\n",
"tnr_threshold_Y", tnr->threshold_Y);
-   ia_css_debug_dtrace(level, "\t%-32s = %d\n"
+   ia_css_debug_dtrace(level, "\t%-32s = %d\n",
"tnr_threshold_C", tnr->threshold_C);
 }
 
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/interface/ia_css_debug.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/interface/ia_css_debug.h
index be7df3a30c21..91c105cc6204 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/interface/ia_css_debug.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/interface/ia_css_debug.h
@@ -137,6 +137,7 @@ ia_css_debug_vdtrace(unsigned int level, const char *fmt, 
va_list args)
sh_css_vprint(fmt, args);
 }
 
+__printf(2, 3)
 extern void ia_css_debug_dtrace(unsigned int level, const char *fmt, ...);
 
 /*! @brief Dump sp thread's stack contents
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c
index 030810bd0878..bcc0d464084f 100644
--- 
a/drivers/staging

[PATCH 00/13] staging: media: atomisp queued up patches

[Greg Kroah-Hartman]

Hi Mauro,

Here's the set of accumulated atomisp staging patches that I had in my
to-review mailbox.  After this, my queue is empty, the driver is all
yours!  Good Luck! :)

thanks,

greg k-h

Avraham Shukron (3):
  staging: media: atomisp: fixed sparse warnings
  staging: media: atomisp: fixed coding style errors
  staging: media: atomisp: fix coding style warnings

Dan Carpenter (2):
  staging: media: atomisp: one char read beyond end of string
  staging: media: atomisp: putting NULs in the wrong place

Fabrizio Perria (1):
  staging: media: atomisp: Fix unnecessary initialization of static

Guru Das Srinagesh (2):
  staging: media: atomisp: use logical AND, not bitwise
  staging: media: atomisp: Make undeclared symbols static

Hans de Goede (1):
  staging: media: atomisp: Fix -Werror=int-in-bool-context compile
errors

Joe Perches (1):
  staging: media: atomisp: Add __printf validation and fix fallout

Manny Vindiola (1):
  staging: media: atomisp: fix missing blank line coding style issue in
atomisp_tpg.c

Mauro Carvalho Chehab (1):
  staging: media: atomisp: don't treat warnings as errors

Valentin Vidic (1):
  staging: media: atomisp: drop unused qos variable

 drivers/staging/media/atomisp/i2c/Makefile |   2 -
 drivers/staging/media/atomisp/i2c/imx/Makefile |   2 -
 drivers/staging/media/atomisp/i2c/ov5693/Makefile  |   2 -
 .../staging/media/atomisp/pci/atomisp2/Makefile|   2 +-
 .../atomisp/pci/atomisp2/atomisp_compat_css20.c|   1 -
 .../media/atomisp/pci/atomisp2/atomisp_fops.c  |  14 +-
 .../media/atomisp/pci/atomisp2/atomisp_tpg.c   |   1 +
 .../media/atomisp/pci/atomisp2/atomisp_v4l2.c  |   2 +-
 .../css2400/hive_isp_css_include/math_support.h|   6 +-
 .../css2400/hive_isp_css_include/string_support.h  |   9 +-
 .../isp/kernels/sdis/sdis_1.0/ia_css_sdis.host.c   |   6 +-
 .../isp/kernels/sdis/sdis_2/ia_css_sdis2.host.c|   2 +-
 .../isp/kernels/tnr/tnr_1.0/ia_css_tnr.host.c  |   2 +-
 .../atomisp2/css2400/runtime/binary/src/binary.c   |   2 +-
 .../css2400/runtime/debug/interface/ia_css_debug.h |   1 +
 .../css2400/runtime/debug/src/ia_css_debug.c   |   6 +-
 .../media/atomisp/pci/atomisp2/css2400/sh_css.c|  19 +-
 .../atomisp/pci/atomisp2/css2400/sh_css_mipi.c |   2 +-
 .../atomisp/pci/atomisp2/css2400/sh_css_params.c   |  10 +-
 .../platform/intel-mid/atomisp_gmin_platform.c | 210 +++--
 .../platform/intel-mid/intel_mid_pcihelpers.c  |  12 +-
 21 files changed, 162 insertions(+), 151 deletions(-)

-- 
2.13.0

[PATCH 04/13] staging: media: atomisp: fixed sparse warnings

[Greg Kroah-Hartman]

From: Avraham Shukron <avraham.shuk...@gmail.com>

Added "static" storage class to 4 not-declared functions

Signed-off-by: Avraham Shukron <avraham.shuk...@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 .../media/atomisp/platform/intel-mid/atomisp_gmin_platform.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 5b4506a71126..15409e96449d 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -436,7 +436,7 @@ static int gmin_gpio1_ctrl(struct v4l2_subdev *subdev, int 
on)
return -EINVAL;
 }
 
-int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
 
@@ -455,7 +455,8 @@ int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
 
return -EINVAL;
 }
-int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
+
+static int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
int ret;
@@ -491,7 +492,7 @@ int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
return -EINVAL;
 }
 
-int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
int ret;
@@ -527,7 +528,7 @@ int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
return -EINVAL;
 }
 
-int gmin_flisclk_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_flisclk_ctrl(struct v4l2_subdev *subdev, int on)
 {
int ret = 0;
struct gmin_subdev *gs = find_gmin_subdev(subdev);
-- 
2.13.0

[PATCH 05/13] staging: media: atomisp: drop unused qos variable

[Greg Kroah-Hartman]

From: Valentin Vidic <valentin.vi...@carnet.hr>

Fixes a sparse warning:

drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c:35:5: 
warning: symbol 'qos' was not declared. Should it be static?

Signed-off-by: Valentin Vidic <valentin.vi...@carnet.hr>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c 
b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
index a6c0f5f8c3f8..b01463361943 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
@@ -32,7 +32,6 @@ static DEFINE_SPINLOCK(msgbus_lock);
 
 static struct pci_dev *pci_root;
 static struct pm_qos_request pm_qos;
-int qos;
 
 #define DW_I2C_NEED_QOS(platform_is(INTEL_ATOM_BYT))
 
-- 
2.13.0

[PATCH 03/13] staging: media: atomisp: Fix unnecessary initialization of static

[Greg Kroah-Hartman]

From: Fabrizio Perria <fabrizio.per...@gmail.com>

Fix checkpatch warning: removed unnecessary initialization of
static variable "skip_fwload" to 0 in source atomisp_v4l2.c

Signed-off-by: Fabrizio Perria <fabrizio.per...@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index e3fdbdba0b34..a0478077a012 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -51,7 +51,7 @@
 /* G-Min addition: pull this in from intel_mid_pm.h */
 #define CSTATE_EXIT_LATENCY_C1  1
 
-static uint skip_fwload = 0;
+static uint skip_fwload;
 module_param(skip_fwload, uint, 0644);
 MODULE_PARM_DESC(skip_fwload, "Skip atomisp firmware load");
 
-- 
2.13.0

Re: [PATCH] media: fix one code style problem

[Greg Kroah-Hartman]

On Fri, May 05, 2017 at 01:18:24PM -0700, Remco wrote:
> From: Remco Verhoef 
> 
> this patch will fix one code style problem (ctx:WxE), space
> prohibited before that

Your subject needs work :)

And why just one issue, is that the only place this type of problem is
needed in this file?

thanks,

greg k-h

Re: [PATCHv3 13/22] staging: android: ion: Use CMA APIs directly

[Greg Kroah-Hartman]

On Mon, Apr 03, 2017 at 11:57:55AM -0700, Laura Abbott wrote:
> When CMA was first introduced, its primary use was for DMA allocation
> and the only way to get CMA memory was to call dma_alloc_coherent. This
> put Ion in an awkward position since there was no device structure
> readily available and setting one up messed up the coherency model.
> These days, CMA can be allocated directly from the APIs. Switch to using
> this model to avoid needing a dummy device. This also mitigates some of
> the caching problems (e.g. dma_alloc_coherent only returning uncached
> memory).
> 
> Signed-off-by: Laura Abbott 
> ---
>  drivers/staging/android/ion/Kconfig|  7 +++
>  drivers/staging/android/ion/Makefile   |  3 +-
>  drivers/staging/android/ion/ion_cma_heap.c | 97 
> --
>  3 files changed, 35 insertions(+), 72 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/Kconfig 
> b/drivers/staging/android/ion/Kconfig
> index 206c4de..15108c4 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -10,3 +10,10 @@ menuconfig ION
> If you're not using Android its probably safe to
> say N here.
>  
> +config ION_CMA_HEAP
> + bool "Ion CMA heap support"
> + depends on ION && CMA
> + help
> +   Choose this option to enable CMA heaps with Ion. This heap is backed
> +   by the Contiguous Memory Allocator (CMA). If your system has these
> +   regions, you should say Y here.
> diff --git a/drivers/staging/android/ion/Makefile 
> b/drivers/staging/android/ion/Makefile
> index 26672a0..66d0c4a 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -1,6 +1,7 @@
>  obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o \
>   ion_page_pool.o ion_system_heap.o \
> - ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
> + ion_carveout_heap.o ion_chunk_heap.o
> +obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
>  ifdef CONFIG_COMPAT
>  obj-$(CONFIG_ION) += compat_ion.o
>  endif
> diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
> b/drivers/staging/android/ion/ion_cma_heap.c
> index d562fd7..f3e0f59 100644
> --- a/drivers/staging/android/ion/ion_cma_heap.c
> +++ b/drivers/staging/android/ion/ion_cma_heap.c
> @@ -19,24 +19,19 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
> +#include 
>  
>  #include "ion.h"
>  #include "ion_priv.h"
>  
>  struct ion_cma_heap {
>   struct ion_heap heap;
> - struct device *dev;
> + struct cma *cma;
>  };
>  
>  #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
>  
> -struct ion_cma_buffer_info {
> - void *cpu_addr;
> - dma_addr_t handle;
> - struct sg_table *table;
> -};
> -
>  
>  /* ION CMA heap operations functions */
>  static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
> @@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
> ion_buffer *buffer,
>   unsigned long flags)
>  {
>   struct ion_cma_heap *cma_heap = to_cma_heap(heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info;
> -
> - dev_dbg(dev, "Request buffer allocation len %ld\n", len);
> -
> - if (buffer->flags & ION_FLAG_CACHED)
> - return -EINVAL;
> + struct sg_table *table;
> + struct page *pages;
> + int ret;
>  
> - info = kzalloc(sizeof(*info), GFP_KERNEL);
> - if (!info)
> + pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL);
> + if (!pages)
>   return -ENOMEM;
>  
> - info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
> - GFP_HIGHUSER | __GFP_ZERO);
> -
> - if (!info->cpu_addr) {
> - dev_err(dev, "Fail to allocate buffer\n");
> + table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
> + if (!table)
>   goto err;
> - }
>  
> - info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
> - if (!info->table)
> + ret = sg_alloc_table(table, 1, GFP_KERNEL);
> + if (ret)
>   goto free_mem;
>  
> - if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
> - len))
> - goto free_table;
> - /* keep this for memory release */
> - buffer->priv_virt = info;
> - buffer->sg_table = info->table;
> - dev_dbg(dev, "Allocate buffer %p\n", buffer);
> + sg_set_page(table->sgl, pages, len, 0);
> +
> + buffer->priv_virt = pages;
> + buffer->sg_table = table;
>   return 0;
>  
> -free_table:
> - kfree(info->table);
>  free_mem:
> - dma_free_coherent(dev, len, info->cpu_addr, info->handle);
> + kfree(table);
>  err:
> - kfree(info);
> + cma_release(cma_heap->cma, pages, buffer->size);
>   return -ENOMEM;
>  }
>  
>  static void ion_cma_free(struct 

Re: [PATCH] staging/media: make atomisp vlv2_plat_clock explicitly non-modular

[Greg Kroah-Hartman]

On Wed, Apr 12, 2017 at 09:57:55PM -0400, Paul Gortmaker wrote:
> The Makefile / Kconfig currently controlling compilation of this code is:
> 
> clock/Makefile:obj-$(CONFIG_INTEL_ATOMISP) += vlv2_plat_clock.o
> 
> atomisp/Kconfig:menuconfig INTEL_ATOMISP
> atomisp/Kconfig:bool "Enable support to Intel MIPI camera drivers"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
> 
> Since module_init was already not in use by this driver, the init
> ordering remains unchanged with this commit.
> 
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
> 
> Cc: Mauro Carvalho Chehab <mche...@kernel.org>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Cc: Alan Cox <a...@linux.intel.com>
> Cc: linux-media@vger.kernel.org
> Cc: de...@driverdev.osuosl.org
> Signed-off-by: Paul Gortmaker <paul.gortma...@windriver.com>

I'm pretty sure we want this code to be built as a module, so maybe a
Kconfig change would resolve the issue instead?

Alan, any thoughts?

thanks,

greg k-h

Re: [PATCH v2 00/21] Convert USB documentation to ReST format

[Greg Kroah-Hartman]

On Tue, Apr 11, 2017 at 03:36:39PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 11 Apr 2017 16:58:40 +0200
> Greg Kroah-Hartman <gre...@linuxfoundation.org> escreveu:
> 
> > On Sat, Apr 08, 2017 at 10:04:33PM +0200, Greg Kroah-Hartman wrote:
> > > On Sat, Apr 08, 2017 at 11:23:28AM -0600, Jonathan Corbet wrote:  
> > > > On Wed,  5 Apr 2017 10:22:54 -0300
> > > > Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:
> > > >   
> > > > > Currently, there are several USB core documents that are at either
> > > > > written in plain text or in DocBook format. Convert them to ReST
> > > > > and add to the driver-api book.  
> > > > 
> > > > Greg, do you see any reason not to apply these for 4.12?  A few of them
> > > > touch comments outside of Documentation/; I'm happy to carry those or
> > > > leave them to you, as you prefer.  
> > > 
> > > I'll queue them up in the next few days, thanks!  
> > 
> > Nope, they don't apply to my tree, it was probably based on yours.  And
> > the first two are ones I shouldn't be taking.
> 
> Yeah, I based it at the docs-next tree. If you prefer, I can rebase
> on your tree, but I guess that the docbook conversion patches
> would likely conflict with some patches at docs-next, because of
> the Makefile changes.

Doesn't bother me, it can go through the Documentation tree as-is.

thanks,

greg k-h

Re: [PATCH v2 00/21] Convert USB documentation to ReST format

[Greg Kroah-Hartman]

On Sat, Apr 08, 2017 at 10:04:33PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Apr 08, 2017 at 11:23:28AM -0600, Jonathan Corbet wrote:
> > On Wed,  5 Apr 2017 10:22:54 -0300
> > Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:
> > 
> > > Currently, there are several USB core documents that are at either
> > > written in plain text or in DocBook format. Convert them to ReST
> > > and add to the driver-api book.
> > 
> > Greg, do you see any reason not to apply these for 4.12?  A few of them
> > touch comments outside of Documentation/; I'm happy to carry those or
> > leave them to you, as you prefer.
> 
> I'll queue them up in the next few days, thanks!

Nope, they don't apply to my tree, it was probably based on yours.  And
the first two are ones I shouldn't be taking.

So, feel free to take all of these with a:
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
for the USB-related patches (2-21).

thanks,

greg k-h

Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 09:20:27AM -0700, Laura Abbott wrote:
> On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote:
> > On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
> >> Hi,
> >>
> >> This is v3 of the series to do some serious Ion cleanup in preparation for
> >> moving out of staging. I didn't hear much on v2 so I'm going to assume
> >> people are okay with the series as is. I know there were still some open
> >> questions about moving away from /dev/ion but in the interest of small
> >> steps I'd like to go ahead and merge this series assuming there are no more
> >> major objections. More work can happen on top of this.
> > 
> > I've applied patches 3-11 as those were independant of the CMA changes.
> > I'd like to take the rest, including the CMA changes, but I need an ack
> > from someone dealing with the -mm tree before I can do that.
> > 
> > Or, if they just keep ignoring it, I guess I can take them :)
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Thanks. I'll send out some nag e-mails asking for Acks. If I don't get
> any, I'll resend the rest of the series after the 4.12 merge window.

Why so long?  This series has been sent a bunch, if no one responds in a
week, I'll be glad to take them all in my tree :)

thanks,

greg k-h

Re: [PATCH v2 00/21] Convert USB documentation to ReST format

[Greg Kroah-Hartman]

On Sat, Apr 08, 2017 at 11:23:28AM -0600, Jonathan Corbet wrote:
> On Wed,  5 Apr 2017 10:22:54 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > Currently, there are several USB core documents that are at either
> > written in plain text or in DocBook format. Convert them to ReST
> > and add to the driver-api book.
> 
> Greg, do you see any reason not to apply these for 4.12?  A few of them
> touch comments outside of Documentation/; I'm happy to carry those or
> leave them to you, as you prefer.

I'll queue them up in the next few days, thanks!

greg k-h

Re: [PATCH] staging: media/platform/bcm2835: remove gstreamer workaround

[Greg Kroah-Hartman]

On Sun, Apr 02, 2017 at 12:48:15AM -0400, Kevin Wern wrote:
> Gstreamer's v4l2src reacted poorly to certain outputs from the bcm2835
> video driver's ioctl ops function vidioc_enum_framesizes, so a
> workaround was created that could be activated by user input. This
> workaround would replace the driver's ioctl ops struct with another,
> similar struct--only with no function pointed to by
> vidioc_enum_framesizes. With no response, gstreamer would attempt to
> continue with some default settings that happened to work better.
> 
> However, this bug has been fixed in gstreamer since 2014, so we
> shouldn't include this workaround in the stable version of the driver.
> 
> Signed-off-by: Kevin Wern 
> ---
>  drivers/staging/media/platform/bcm2835/TODO|  5 --
>  .../media/platform/bcm2835/bcm2835-camera.c| 59 
> --
>  2 files changed, 64 deletions(-)

Doesn't apply against my tree at all :(

thanks,

greg k-h

Re: [PATCH] add blank line after declarations

[Greg Kroah-Hartman]

On Fri, Apr 07, 2017 at 08:41:11AM -0400, Manny Vindiola wrote:
> Add blank line after variable declarations as part of checkpatch.pl style 
> fixup.
> 
> Signed-off-by: Manny Vindiola 
> ---
>  drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c | 1 +
>  1 file changed, 1 insertion(+)

Your subject line needs a lot of work, please read the reference
material I sent you for your last patch...

thanks,

greg k-h

Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging

[Greg Kroah-Hartman]

On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
> Hi,
> 
> This is v3 of the series to do some serious Ion cleanup in preparation for
> moving out of staging. I didn't hear much on v2 so I'm going to assume
> people are okay with the series as is. I know there were still some open
> questions about moving away from /dev/ion but in the interest of small
> steps I'd like to go ahead and merge this series assuming there are no more
> major objections. More work can happen on top of this.

I've applied patches 3-11 as those were independant of the CMA changes.
I'd like to take the rest, including the CMA changes, but I need an ack
from someone dealing with the -mm tree before I can do that.

Or, if they just keep ignoring it, I guess I can take them :)

thanks,

greg k-h

Re: [PATCH v3] Revert "staging: radio-bcm2048: fixed bare use of unsigned int"

[Greg Kroah-Hartman]

On Mon, Mar 27, 2017 at 05:20:29PM +1100, Eddie Youseph wrote:
> This reverts previous changes to checkpatch warning:
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> ---
> Changes in v2:
>   - Added changelog
> 
> Changes in v3:
>   - Revert changes to using bare unsigned

I don't understand, this patch fails to apply.  What are you making it
aginst?

confused,

greg k-h

Re: [PATCH] staging: media: atomisp: remove ifdef around HMM_BO_ION

[Greg Kroah-Hartman]

On Fri, Mar 24, 2017 at 02:20:24PM +0100, Arnd Bergmann wrote:
> The revert reintroduced a build failure without CONFIG_ION:
> 
> media/atomisp/pci/atomisp2/hmm/hmm.c:52:2: error: excess elements in array 
> initializer [-Werror]
> media/atomisp/pci/atomisp2/hmm/hmm.c:52:2: note: (near initialization for 
> 'hmm_bo_type_strings')
> 
> We should really be able to build in any configuration, so this tries a
> different fix to make sure the symbol is defined.
> 
> Fixes: 9ca98bd07748 ("Revert "staging: media: atomisp: fill properly 
> hmm_bo_type_strings when ION is disabled"")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/staging/media/atomisp/pci/atomisp2/include/hmm/hmm_bo.h | 2 --
>  1 file changed, 2 deletions(-)

Ugh, Alan, what's going on here, I thought you fixed this?

totally confused,

greg k-h

Re: [PATCH] staging: media: atomisp: use kvmalloc and kvfree

[Greg Kroah-Hartman]

On Thu, Mar 23, 2017 at 09:12:39PM +0800, Geliang Tang wrote:
> Use kvmalloc() and kvfree() instead of open-coding.

These functions are not in Linus's tree, so I can't apply this patch
without breaking things :(

thanks,

greg k-h

Re: [PATCH v2] staging: radio-bcm2048: fixed bare use of unsigned int

[Greg Kroah-Hartman]

On Wed, Mar 22, 2017 at 01:33:39PM +1100, Eddie Youseph wrote:
> Fixed checkpatch WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> 
> Signed-off-by: Eddie Youseph 
> ---
> Changes in v2:
>   - Added changelog

Did you actually build this change?

Please do so...

thanks,

greg k-h

Re: [PATCH] bcm2048: Fix checkpatch checks

[Greg Kroah-Hartman]

On Sat, Feb 18, 2017 at 11:52:37AM +0800, Man Choy wrote:
> Fix following checks:
> 
> CHECK: Avoid crashing the kernel - try using WARN_ON & recovery code rather 
> than BUG() or BUG_ON()
> +   BUG_ON((index+2) >= BCM2048_MAX_RDS_RT);
> 
> CHECK: spaces preferred around that '+' (ctx:VxV)
> +   BUG_ON((index+2) >= BCM2048_MAX_RDS_RT);
>  ^
> 
> CHECK: Avoid crashing the kernel - try using WARN_ON & recovery code rather 
> than BUG() or BUG_ON()
> +   BUG_ON((index+4) >= BCM2048_MAX_RDS_RT);
> 
> CHECK: spaces preferred around that '+' (ctx:VxV)
> +   BUG_ON((index+4) >= BCM2048_MAX_RDS_RT);
>  ^
> ---
>  drivers/staging/media/bcm2048/radio-bcm2048.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
> b/drivers/staging/media/bcm2048/radio-bcm2048.c
> index 37bd439..d5ee279 100644
> --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> @@ -1534,7 +1534,7 @@ static int bcm2048_parse_rt_match_c(struct 
> bcm2048_device *bdev, int i,
>   if (crc == BCM2048_RDS_CRC_UNRECOVARABLE)
>   return 0;
>  
> - BUG_ON((index+2) >= BCM2048_MAX_RDS_RT);
> + WARN_ON((index + 2) >= BCM2048_MAX_RDS_RT);

Ick, no to all of these!  What happens if this is true, the code will
crash, right?  You have to properly recover from this, don't just throw
the message out to userspace and then keep on going.

You can't just do a search/replace for this, otherwise it would have
been done already :)

thanks,

greg k-h

Re: [PATCH] Staging: media: bcm2048: Fixed an error

[Greg Kroah-Hartman]

On Sun, Feb 12, 2017 at 11:12:42PM +0200, Ran Algawi wrote:
> Hello Greg,
> First, I appreciate you taking the time to educate me. I used the checkpatch
> script on the file I fixed and he reported the line as an error. Do you
> consider all checkpatch warnings/error/checks as coding style fixes?

The ones that refer to coding style issues, yes, that is what they are.
Sometimes the script points out other things that should be changed,
like octal values which is not an error in this case, but rather a
clarification.

And please turn html off in your email client, it gets rejected by the
mailing lists :)

thanks,

greg k-h

Re: [PATCH] staging: davinci_vpfe: fix multiline comment style

[Greg Kroah-Hartman]

On Wed, Feb 08, 2017 at 01:52:05PM +0200, Avraham Shukron wrote:
> Signed-off-by: Avraham Shukron 

I can't take patches without a changelog text, and neither should any
other maintainer...

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/6] staging: Import the BCM2835 MMAL-based V4L2 camera driver.

[Greg Kroah-Hartman]

On Sun, Feb 05, 2017 at 10:15:21PM +, Dave Stevenson wrote:
> Newbie question: if this has already been merged to staging, where am I
> looking for the relevant tree to add patches on top of?
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git branch
> staging-next?

Yes, that is the correct place.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] staging: bcm2835: mark all symbols as 'static'

[Greg Kroah-Hartman]

On Thu, Feb 02, 2017 at 01:11:36PM +0100, Arnd Bergmann wrote:
> On Thu, Feb 2, 2017 at 1:04 PM, Arnd Bergmann  wrote:
> > On Thu, Feb 2, 2017 at 12:34 PM, Arnd Bergmann  wrote:
> >> I got a link error in allyesconfig:
> >> Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera 
> >> driver.")
> >> Signed-off-by: Arnd Bergmann 
> >
> > Please disregard this patch version, it's broken.
> 
> Too late, I see it's already applied, I'll send a follow-up to revert
> the first hunk.

Ah, I could have just dropped your patch (it's a testing branch that I
can rebase), but I took your newer patch that fixed it up, so all is
good.

That's what I get for applying patches too quickly :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Staging: media: radio-bcm2048: Fix alignment issues

[Greg Kroah-Hartman]

On Wed, Oct 19, 2016 at 08:10:25PM +0200, Jean-Baptiste Abbadie wrote:
> On 19/10/16 19:51, Greg Kroah-Hartman wrote:
> > I can't take a patch with no changelog text, sorry.
> Hello,
> 
> Should I add the changelog in the same thread or start a new thread ?

Whole new patch please.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Staging: media: radio-bcm2048: Fix alignment issues

[Greg Kroah-Hartman]

On Wed, Oct 19, 2016 at 07:17:12PM +0200, Jean-Baptiste Abbadie wrote:
> Signed-off-by: Jean-Baptiste Abbadie 

I can't take a patch with no changelog text, sorry.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH -next] staging: media: stih-cec: remove unused including

[Greg Kroah-Hartman]

On Wed, Sep 28, 2016 at 03:13:13PM +, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Remove including  that don't need it.
> 
> Signed-off-by: Wei Yongjun 
> Acked-by: Benjamin Gaignard 
> ---
>  drivers/staging/media/st-cec/stih-cec.c | 1 -

This file isn't in my tree, maybe it needs to go through Mauro's...
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma-buf/sw_sync: mark sync_timeline_create() static

[Greg Kroah-Hartman]

On Tue, Sep 20, 2016 at 06:23:33PM +0530, Sumit Semwal wrote:
> Hi Baoyou,
> 
> On 20 September 2016 at 16:43, Gustavo Padovan  wrote:
> > 2016-09-18 Baoyou Xie :
> >
> >> We get 1 warning when building kernel with W=1:
> >> drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for 
> >> 'sync_timeline_create' [-Wmissing-prototypes]
> >>
> >> In fact, this function is only used in the file in which it is
> >> declared and don't need a declaration, but can be made static.
> >> So this patch marks it 'static'.
> >>
> >> Signed-off-by: Baoyou Xie 
> >> ---
> >>  drivers/dma-buf/sw_sync.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Thanks for finding this.
> 
> Thanks for the patch; this doesn't apply to mainline yet, since the
> de-staging of sw_sync code is queued for 4.9 via Greg-KH's tree.
> CC'ing him.
> 
> Greg, would it be possible to please take this via your tree?

If someone resends it to me with the needed acks and reviewed-by, I
will.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for 4.6] davinci_vpfe: Revert "staging: media: davinci_vpfe: remove,unnecessary ret variable"

[Greg Kroah-Hartman]

On Fri, Apr 15, 2016 at 01:58:10PM +0200, Hans Verkuil wrote:
> This reverts commit afa5d19a2b5fbf0bbcce34f3613bce2bc9479bb7.
> 
> This patch is completely bogus and messed up the code big time.
> 
> I'm not sure what was intended, but this isn't it.
> 
> Cc: Thaissa Falbo <thaissa.fa...@gmail.com>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> ---
> 
> Greg, this patch was never seen by us. Can you redirect patches for 
> staging/media
> to the linux-media mailinglist? We'd like to stay on top of what is happening 
> there.

Ugh, you are right, sorry about this.  I'll try to forward this stuff
onward, my fault.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add tw5864 driver

[Greg Kroah-Hartman]

On Mon, Mar 14, 2016 at 03:55:14AM +0200, Andrey Utkin wrote:
> From: Andrey Utkin 
> 
> Support for boards based on Techwell TW5864 chip which provides
> multichannel video & audio grabbing and encoding (H.264, MJPEG,
> ADPCM G.726).
> 
> Signed-off-by: Andrey Utkin 
> Tested-by: Andrey Utkin 

Meta-conmment, why add this to drivers/staging/media?  Why can't it just
go into drivers/media/ ?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add tw5864 driver

[Greg Kroah-Hartman]

On Mon, Mar 14, 2016 at 03:55:14AM +0200, Andrey Utkin wrote:
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2333,6 +2333,7 @@
>  #define PCI_VENDOR_ID_CAVIUM 0x177d
>  
>  #define PCI_VENDOR_ID_TECHWELL   0x1797
> +#define PCI_DEVICE_ID_TECHWELL_5864  0x5864
>  #define PCI_DEVICE_ID_TECHWELL_6800  0x6800
>  #define PCI_DEVICE_ID_TECHWELL_6801  0x6801
>  #define PCI_DEVICE_ID_TECHWELL_6804  0x6804

Please read the comments at the top of this file for why you don't need
to put any new ids into it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Failed to build on 4.2.6

[Greg Kroah-Hartman]

On Mon, Dec 07, 2015 at 10:25:19AM -0500, Steven Rostedt wrote:
> Hi,
> 
> The attached config doesn't build on 4.2.6, but changing it to the
> following:
> 
>  VIDEO_V4L2_SUBDEV_API n -> y
> +V4L2_FLASH_LED_CLASS n
> 
> does build.

Did this work on older kernels (4.2.5?  .4?  older?)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: media: omap4iss: Reformat overly long lines

[Greg Kroah-Hartman]

On Tue, May 26, 2015 at 10:54:18AM +0200, Piotr S. Staszewski wrote:
 This reformats lines that were previously above 80 characters long,
 improving readability and making checkpatch.pl happy.
 
 Signed-off-by: Piotr S. Staszewski p.staszew...@gmail.com
 ---
  drivers/staging/media/omap4iss/iss_csi2.c| 21 ---
  drivers/staging/media/omap4iss/iss_ipipe.c   | 30 
 ++--
  drivers/staging/media/omap4iss/iss_ipipeif.c | 10 ++
  drivers/staging/media/omap4iss/iss_resizer.c |  8 +---
  4 files changed, 44 insertions(+), 25 deletions(-)
 
 diff --git a/drivers/staging/media/omap4iss/iss_csi2.c 
 b/drivers/staging/media/omap4iss/iss_csi2.c
 index d7ff769..a8714bb 100644
 --- a/drivers/staging/media/omap4iss/iss_csi2.c
 +++ b/drivers/staging/media/omap4iss/iss_csi2.c
 @@ -224,7 +224,8 @@ static u16 csi2_ctx_map_format(struct iss_csi2_device 
 *csi2)
   fmtidx = 3;
   break;
   default:
 - WARN(1, KERN_ERR CSI2: pixel format %08x unsupported!\n,
 + WARN(1,
 +  KERN_ERR CSI2: pixel format %08x unsupported!\n,

That line wasn't over 80 characters long, why change it?

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/13] serial: 8250_dma: Support for deferred probing when requesting DMA channels

[Greg Kroah-Hartman]

On Tue, May 26, 2015 at 04:25:58PM +0300, Peter Ujfalusi wrote:
 Switch to use ma_request_slave_channel_compat_reason() to request the DMA
 channels. In case of error, return the error code we received including
 -EPROBE_DEFER

I think you typed the function name wrong here :(

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] radio-bcm2048: Fix region selection

[Greg Kroah-Hartman]

On Fri, May 15, 2015 at 11:32:51PM +0200, Pali Rohár wrote:
 From: maxx m...@spaceboyz.net

I need a real name here, sorry.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] radio-bcm2048: Enable access to automute and ctrl registers

[Greg Kroah-Hartman]

On Fri, May 15, 2015 at 11:31:51PM +0200, Pali Rohár wrote:
 From: maxx m...@spaceboyz.net

Same here, real name please.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: hcd: get/put device and hcd for hcd_buffers()

['Greg Kroah-Hartman']

On Mon, Dec 08, 2014 at 09:44:05AM +, David Laight wrote:
 From: Greg Kroah-Hartman
  On Fri, Dec 05, 2014 at 09:03:57PM +0100, Sebastian Andrzej Siewior wrote:
   Consider the following scenario:
   - plugin a webcam
   - play the stream via gst-launch-0.10 v4l2src device=/dev/video0
   - remove the USB-HCD during playback via rmmod $HCD
  
   and now wait for the crash
  
  Which you deserve, why did you ever remove a kernel module?  That's racy
  and _never_ recommended, which is why it never happens automatically and
  only root can do it.
 
 Really drivers and subsystems should have the required locking (etc) to
 ensure that kernel modules can either be unloaded, or that the unload
 request itself fails if the device is busy.
 
 It shouldn't be considered a 'shoot self in foot' operation.
 OTOH there are likely to be bugs.

This is not always the case, sorry, removing a kernel module is a known
racy condition, and sometimes adding all of the locking required to try
to make it safe just isn't worth it overall, as this is something that
_only_ a developer does.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: hcd: get/put device and hcd for hcd_buffers()

['Greg Kroah-Hartman']

On Tue, Dec 09, 2014 at 05:01:35PM +0100, Sebastian Andrzej Siewior wrote:
 On 12/09/2014 04:24 PM, 'Greg Kroah-Hartman' wrote:
  On Mon, Dec 08, 2014 at 09:44:05AM +, David Laight wrote:
  From: Greg Kroah-Hartman
  On Fri, Dec 05, 2014 at 09:03:57PM +0100, Sebastian Andrzej Siewior wrote:
  Consider the following scenario:
  - plugin a webcam
  - play the stream via gst-launch-0.10 v4l2src device=/dev/video0
  - remove the USB-HCD during playback via rmmod $HCD
 
  and now wait for the crash
 
  Which you deserve, why did you ever remove a kernel module?  That's racy
  and _never_ recommended, which is why it never happens automatically and
  only root can do it.
 
  Really drivers and subsystems should have the required locking (etc) to
  ensure that kernel modules can either be unloaded, or that the unload
  request itself fails if the device is busy.
 
  It shouldn't be considered a 'shoot self in foot' operation.
  OTOH there are likely to be bugs.
  
  This is not always the case, sorry, removing a kernel module is a known
  racy condition, and sometimes adding all of the locking required to try
  to make it safe just isn't worth it overall, as this is something that
  _only_ a developer does.
 
 I wasn't are of that. rmmod does not mention this. Kconfig does not
 mention this and suggest y as default (for MODULE_UNLOAD) . rmmod -f
 likely causes problems but this is not the case here. If you want to
 avoid rmmod why not mark a driver that it is not safe to remove it? And
 why not make it work?

Because sometimes fixes to make rmmod work properly entail slowing
down the whole normal path.  There is inherit problems with the core
of the module unload code for all modules that are known, and are not
going to be fixed because this isn't something that really matters.

 You can unbind the HCD driver from the PCI-device via sysfs and this is
 not something not only a developer does. This unbind calls the remove
 function of the driver and the only difference between unbind and rmmod
 is that the module remains inserted (but this is no news for you).

If unbind causes a problem, it's the same problem that could happen if
the hardware is hot-unplugged (like on a PCI card.)  Stuff like that
_does_ need to be fixed, and if your test shows this is a problem, I am
all for fixing that.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: hcd: get/put device and hcd for hcd_buffers()

[Greg Kroah-Hartman]

On Fri, Dec 05, 2014 at 09:03:57PM +0100, Sebastian Andrzej Siewior wrote:
 Consider the following scenario:
 - plugin a webcam
 - play the stream via gst-launch-0.10 v4l2src device=/dev/video0…
 - remove the USB-HCD during playback via rmmod $HCD
 
 and now wait for the crash

Which you deserve, why did you ever remove a kernel module?  That's racy
and _never_ recommended, which is why it never happens automatically and
only root can do it.

 |musb-hdrc musb-hdrc.2.auto: remove, state 1
 |usb usb2: USB disconnect, device number 1
 |usb 2-1: USB disconnect, device number 3
 |uvcvideo: Failed to resubmit video URB (-19).
 |musb-hdrc musb-hdrc.2.auto: USB bus 2 deregistered
 |musb-hdrc musb-hdrc.1.auto: remove, state 4
 |usb usb1: USB disconnect, device number 1
 |musb-hdrc musb-hdrc.1.auto: USB bus 1 deregistered
 |Unable to handle kernel paging request at virtual address 6b6b6b6f
 |pgd = c0004000
 |[6b6b6b6f] *pgd=
 |Internal error: Oops: 5 [#1] ARM
 |Modules linked in: uvcvideo]
 |CPU: 0 PID: 2613 Comm: gst-launch-0.10 Tainted: GW3.14.25+ #40
 |task: ec2b8100 ti: ec38e000 task.ti: ec38e000
 |PC is at hcd_buffer_free+0x64/0xc0
 |LR is at uvc_free_urb_buffers+0x34/0x50 [uvcvideo]
 |Process gst-launch-0.10 (pid: 2613, stack limit = 0xec38e240)
 |[c03a07e8] (hcd_buffer_free)
 |[bf2f0c78] (uvc_free_urb_buffers [uvcvideo])
 |[bf2f33dc] (uvc_video_enable [uvcvideo])
 |[bf2ef150] (uvc_v4l2_release [uvcvideo])
 |[bf2ac318] (v4l2_release [videodev])
 |[c0103334] (__fput)
 |[c005b618] (task_work_run)
 |[c00417a0] (do_exit)
 |[c0041ebc] (do_group_exit)
 
 as part of the device-removal the HCD removes its dma-buffers, the HCD
 structure itself and even the struct device is gone. That means if UVC
 removes its URBs after its last user (/dev/videoX) is gone and not from
 the -disconnect() callback then it is too late because the HCD might
 gone.
 
 First, I fixed by in the UVC driver by ignoring the UVC_SC_VIDEOSTREAMING
 in its -disconnect callback and calling uvc_video_enable(, 0) in
 uvc_unregister_video(). But then I though that it might not be clever to
 release that memory if there is userspace using it.
 
 So instead, I hold the device struct in the HCD and the HCD struct on
 every USB-buf-alloc. That means after a disconnect we still have a
 refcount on usb_hcd and device and it will be cleaned later once the
 last USB-buffer is released.
 
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
 With this applied, I only see this three times (which is not new)
 
 | [ cut here ]
 | WARNING: CPU: 0 PID: 1755 at fs/sysfs/group.c:219 
 sysfs_remove_group+0x88/0x98()
 | sysfs group c08a70d4 not found for kobject 'event4'
 | Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops 
 videobuf2_core v4l2_common videodev ipv6 musb_hdrc udc_core us]
 | CPU: 0 PID: 1755 Comm: gst-launch-0.10 Not tainted 
 3.18.0-rc7-00065-gabcefb342fbf-dirty #1813
 | [c00152a8] (unwind_backtrace) from [c0011a48] (show_stack+0x10/0x14)
 | [c0011a48] (show_stack) from [c056450c] (dump_stack+0x80/0x9c)
 | [c056450c] (dump_stack) from [c00401a0] (warn_slowpath_common+0x68/0x8c)
 | [c00401a0] (warn_slowpath_common) from [c0040258] 
 (warn_slowpath_fmt+0x30/0x40)
 | [c0040258] (warn_slowpath_fmt) from [c01af2a4] 
 (sysfs_remove_group+0x88/0x98)
 | [c01af2a4] (sysfs_remove_group) from [c039420c] (device_del+0x34/0x198)
 | [c039420c] (device_del) from [c0428208] (evdev_disconnect+0x18/0x44)
 | [c0428208] (evdev_disconnect) from [c04258c8] 
 (__input_unregister_device+0xa4/0x148)
 | [c04258c8] (__input_unregister_device) from [c04259ac] 
 (input_unregister_device+0x40/0x74)
 | [c04259ac] (input_unregister_device) from [bf0c6294] 
 (uvc_delete+0x20/0x10c [uvcvideo])
 | [bf0c6294] (uvc_delete [uvcvideo]) from [bf08a68c] 
 (v4l2_device_release+0x9c/0xc4 [videodev])
 | [bf08a68c] (v4l2_device_release [videodev]) from [c03934f0] 
 (device_release+0x2c/0x90)
 | [c03934f0] (device_release) from [c030f7bc] (kobject_release+0x48/0x7c)
 | [c030f7bc] (kobject_release) from [bf089330] (v4l2_release+0x50/0x78 
 [videodev])
 | [bf089330] (v4l2_release [videodev]) from [c0147e34] (__fput+0x80/0x1c4)
 | [c0147e34] (__fput) from [c0058a18] (task_work_run+0xb4/0xe4)
 | [c0058a18] (task_work_run) from [c00425ec] (do_exit+0x2dc/0x92c)
 | [c00425ec] (do_exit) from [c0042ca4] (do_group_exit+0x3c/0xb0)
 | [c0042ca4] (do_group_exit) from [c0042d28] (__wake_up_parent+0x0/0x18)
 | ---[ end trace b54a8f3c8129180e ]---
 anyone an idea?
 
  drivers/usb/core/buffer.c | 30 +-
  drivers/usb/core/hcd.c|  2 ++
  2 files changed, 27 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
 index 506b969ea7fd..01e080a61519 100644
 --- a/drivers/usb/core/buffer.c
 +++ b/drivers/usb/core/buffer.c
 @@ -107,7 +107,7 @@ void hcd_buffer_destroy(struct usb_hcd *hcd)
   * better sharing and to leverage mm/slab.c intelligence.
   */
  
 -void 

Re: [PATCH] usb: hcd: get/put device and hcd for hcd_buffers()

[Greg Kroah-Hartman]

On Sat, Dec 06, 2014 at 12:13:13AM +0100, Sebastian Andrzej Siewior wrote:
 * Greg Kroah-Hartman | 2014-12-05 13:19:32 [-0800]:
 
 On Fri, Dec 05, 2014 at 09:03:57PM +0100, Sebastian Andrzej Siewior wrote:
  Consider the following scenario:
  - plugin a webcam
  - play the stream via gst-launch-0.10 v4l2src device=/dev/video0…
  - remove the USB-HCD during playback via rmmod $HCD
  
  and now wait for the crash
 
 Which you deserve, why did you ever remove a kernel module?  That's racy
 its been found by the testing team and looks legitimate.
 
 and _never_ recommended, which is why it never happens automatically and
 only root can do it.
 I beg your pardon. So it is okay to remove the UVC-driver / plug the
 cable and expect that things continue to work but removing the HCD is a
 no no?

If you hot unplug the HCD and this is an issue, yes, that's something to
fix.  If you can only trigger this by unloading a kernel module, no,
it's not a big issue at all.  It's pretty trivial to cause kernel oopses
by unloading kernel modules if you know what you are doing.

  diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
  index 506b969ea7fd..01e080a61519 100644
  --- a/drivers/usb/core/buffer.c
  +++ b/drivers/usb/core/buffer.c
  @@ -107,7 +107,7 @@ void hcd_buffer_destroy(struct usb_hcd *hcd)
* better sharing and to leverage mm/slab.c intelligence.
*/
   
  -void *hcd_buffer_alloc(
  +static void *_hcd_buffer_alloc(
 
 Looks like this isn't really needed here, right?
 
 either this or I would have the tree callers if the allocation succeded
 or not in order not to take a reference if the allocation failed.

My point is this isn't needed for this patch.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: media: lirc: modify print calls

[Greg Kroah-Hartman]

On Wed, Nov 05, 2014 at 03:43:44PM +0200, Aya Mahfouz wrote:
 On Wed, Nov 05, 2014 at 08:17:11AM -0200, Mauro Carvalho Chehab wrote:
  Em Tue, 4 Nov 2014 23:43:07 +0200
  Aya Mahfouz mahfouz.saif.elya...@gmail.com escreveu:
  
   This patches replaces one pr_debug call by dev_dbg and
   changes the device used by one of the dev_err calls.
  
  Also doesn't apply. Probably made to apply on Greg's tree.
  
  Regards,
  Mauro
  
 
 Yes, I submit patches to Greg's tree. Should I clone your
 tree?

I'll take this one as it builds on a change in my tree.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/4] cenalloc: Constraint-Enabled Allocation helpers for dma-buf

[Greg Kroah-Hartman]

On Sat, Oct 11, 2014 at 01:37:56AM +0530, Sumit Semwal wrote:
 Devices sharing buffers using dma-buf could benefit from sharing their
 constraints via struct device, and dma-buf framework would manage the
 common constraints for all attached devices per buffer.
 
 With that information, we could have a 'generic' allocator helper in
 the form of a central dma-buf exporter, which can create dma-bufs, and
 allocate backing storage at the time of first call to
 dma_buf_map_attachment.
 
 This allocation would utilise the constraint-mask by matching it to
 the right allocator from a pool of allocators, and then allocating
 buffer backing storage from this allocator.
 
 The pool of allocators could be platform-dependent, allowing for
 platforms to hide the specifics of these allocators from the devices
 that access the dma-buf buffers.
 
 A sample sequence could be:
 - get handle to cenalloc_device,
 - create a dmabuf using cenalloc_buffer_create;
 - use this dmabuf to attach each device, which has its constraints
set in the constraints mask (dev-dma_params-access_constraints_mask)
   - at each dma_buf_attach() call, dma-buf will check to see if the constraint
 mask for the device requesting attachment is compatible with the 
 constraints
 of devices already attached to the dma-buf; returns an error if it isn't.
 - after all devices have attached, the first call to dma_buf_map_attachment()
   will allocate the backing storage for the buffer.
 - follow the dma-buf api for map / unmap etc usage.
 - detach all attachments,
 - call cenalloc_buffer_free to free the buffer if refcount reaches zero;
 
 ** IMPORTANT**
 This mechanism of delayed allocation based on constraint-enablement will work
 *ONLY IF* the first map_attachment() call is made AFTER all attach() calls are
 done.
 
 Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
 Cc: linux-ker...@vger.kernel.org
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 Cc: linux-media@vger.kernel.org
 Cc: dri-de...@lists.freedesktop.org
 Cc: linaro-mm-...@lists.linaro.org
 ---
  MAINTAINERS  |   1 +
  drivers/cenalloc/cenalloc.c  | 597 
 +++
  drivers/cenalloc/cenalloc.h  |  99 +++
  drivers/cenalloc/cenalloc_priv.h | 188 
  4 files changed, 885 insertions(+)
  create mode 100644 drivers/cenalloc/cenalloc.c
  create mode 100644 drivers/cenalloc/cenalloc.h
  create mode 100644 drivers/cenalloc/cenalloc_priv.h
 
 diff --git a/MAINTAINERS b/MAINTAINERS
 index 40d4796..e88ac81 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -3039,6 +3039,7 @@ L:  linux-media@vger.kernel.org
  L:   dri-de...@lists.freedesktop.org
  L:   linaro-mm-...@lists.linaro.org
  F:   drivers/dma-buf/
 +F:   drivers/cenalloc/
  F:   include/linux/dma-buf*
  F:   include/linux/reservation.h
  F:   include/linux/*fence.h
 diff --git a/drivers/cenalloc/cenalloc.c b/drivers/cenalloc/cenalloc.c
 new file mode 100644
 index 000..f278056
 --- /dev/null
 +++ b/drivers/cenalloc/cenalloc.c
 @@ -0,0 +1,597 @@
 +/*
 + * Allocator helper framework for constraints-aware dma-buf backing storage
 + * allocation.
 + * This allows constraint-sharing devices to deferred-allocate buffers shared
 + * via dma-buf.
 + *
 + * Copyright(C) 2014 Linaro Limited. All rights reserved.
 + * Author: Sumit Semwal sumit.sem...@linaro.org
 + *
 + * Structure for management of clients, buffers etc heavily derived from
 + * Android's ION framework.

Does that mean we can drop ION after this gets merged?

/me dreams

Anyway, why a new directory?  Why not just put it in drivers/dma-buf ?
Or a subdir below there?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/8] [media] soc_camera: Do not decrement endpoint node refcount in the loop

[Greg Kroah-Hartman]

On Mon, Sep 29, 2014 at 11:45:23AM +0200, Philipp Zabel wrote:
 Am Montag, den 29.09.2014, 12:13 +0300 schrieb Dan Carpenter:
  On Mon, Sep 29, 2014 at 10:15:44AM +0200, Philipp Zabel wrote:
   In preparation for a following patch, stop decrementing the endpoint node
   refcount in the loop. This temporarily leaks a reference to the endpoint 
   node,
   which will be fixed by having of_graph_get_next_endpoint decrement the 
   refcount
   of its prev argument instead.
  
  Don't do this...
  
  My understanding (and I haven't invested much time into trying to
  understand this beyond glancing at the change) is that patch 1 and 2,
  introduce small bugs that are fixed in patch 3?
 
  Just fold all three patches into one patch.  We need an Ack from Mauro
  and Greg and then send the patch through Grant's tree.
 
 Yes. Patches 1 and 2 leak a reference on of_nodes touched by the loop.
 As far as I am aware, all users of this code don't use the reference
 counting (CONFIG_OF_DYNAMIC is disabled), so this bug should be
 theoretical.
 
 I'd be happy do as you suggest if Mauro and Greg agree.

Let's see the correct patch, don't break things and then later on fix
them...

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/6] of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint

[Greg Kroah-Hartman]

On Mon, Sep 29, 2014 at 08:03:34PM +0200, Philipp Zabel wrote:
 Decrementing the reference count of the previous endpoint node allows to
 use the of_graph_get_next_endpoint function in a for_each_... style macro.
 All current users of this function that pass a non-NULL prev parameter
 (that is, soc_camera and imx-drm) are changed to not decrement the passed
 prev argument's refcount themselves.
 
 Signed-off-by: Philipp Zabel p.za...@pengutronix.de
 ---
 Changes since v4:
  - Folded patches 1-3 into this one
 ---
  drivers/media/platform/soc_camera/soc_camera.c |  3 ++-
  drivers/of/base.c  |  9 +
  drivers/staging/imx-drm/imx-drm-core.c | 12 ++--
  3 files changed, 5 insertions(+), 19 deletions(-)

No objection from me for this, but Grant is in charge of
drivers/of/base.c, so I'll leave it for him to apply.

Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] drivers/base/dma-buf.c: replace dma_buf_uninit_debugfs by debugfs_remove_recursive

[Greg Kroah-Hartman]

On Fri, Jun 27, 2014 at 10:32:10PM +0200, Fabian Frederick wrote:
 null test before debugfs_remove_recursive is not needed so one line function
 dma_buf_uninit_debugfs can be removed.
 
 This patch calls debugfs_remove_recursive under CONFIG_DEBUG_FS
 
 Cc: Sumit Semwal sumit.sem...@linaro.org
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 Cc: linux-media@vger.kernel.org
 Signed-off-by: Fabian Frederick f...@skynet.be
 ---
 
 This is untested.
 
  drivers/base/dma-buf.c | 13 +++--
  1 file changed, 3 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
 index 840c7fa..184c0cb 100644
 --- a/drivers/base/dma-buf.c
 +++ b/drivers/base/dma-buf.c
 @@ -701,12 +701,6 @@ static int dma_buf_init_debugfs(void)
   return err;
  }
  
 -static void dma_buf_uninit_debugfs(void)
 -{
 - if (dma_buf_debugfs_dir)
 - debugfs_remove_recursive(dma_buf_debugfs_dir);
 -}
 -
  int dma_buf_debugfs_create_file(const char *name,
   int (*write)(struct seq_file *))
  {
 @@ -722,9 +716,6 @@ static inline int dma_buf_init_debugfs(void)
  {
   return 0;
  }
 -static inline void dma_buf_uninit_debugfs(void)
 -{
 -}
  #endif
  
  static int __init dma_buf_init(void)
 @@ -738,6 +729,8 @@ subsys_initcall(dma_buf_init);
  
  static void __exit dma_buf_deinit(void)
  {
 - dma_buf_uninit_debugfs();
 +#ifdef CONFIG_DEBUG_FS
 + debugfs_remove_recursive(dma_buf_debugfs_dir);
 +#endif

That ifdef should not be needed at all, right?  No ifdefs should be
needed for debugfs code, if it is written correctly :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

[Greg Kroah-Hartman]

On Wed, Apr 30, 2014 at 04:02:50PM +0200, Andrzej Hajda wrote:
 Generic framework for tracking internal interfaces
 ==
 
 Summary
 ---
 
 interface_tracker is a generic framework which allows to track appearance
 and disappearance of different interfaces provided by kernel/driver code 
 inside
 the kernel. Examples of such interfaces: clocks, phys, regulators, 
 drm_panel...
 Interface is specified by a pair of object pointer and interface type. Object
 type depends on interface type, for example interface type drm_panel 
 determines
 that object is a device_node. Object pointer is used to distinguish different
 interfaces of the same type and should identify object the interface is bound 
 to.
 For example it could be DT node, struct device,...
 
 The framework provides two functions for interface providers which should be
 called just after interface becomes available or just before interface
 removal. Interface consumers can register callback which will be called
 when requested interface changes its state, if during callback registration
 the interface is already up, notification will be sent also.
 
 The framework allows nesting calls, for example it is possible to signal one
 interface in tracker callback of another interface. It is done by putting
 every request into the queue. If the queue is empty before adding
 the request, the queue will be processed after, if there is already another
 request in the queue it means the queue is already processed by different
 thread so no additional action is required. With this pattern only spinlock
 is necessary to protect the queue. However in case of removal of either
 callback or interface caller should be sure that his request has been
 processed so framework waits until the queue becomes empty, it is done using
 completion mechanism.
 
 The framework functions should not be called in atomic context. Callbacks
 should be aware that they can be called in any time between registration and
 de-registration, so they should use synchronization mechanisms carefully.
 Callbacks should also avoid to perform time consuming tasks, the framework
 serializes them, so it could stall other callbacks.
 
 Use cases
 -
 
 The interface is very generic, there are many situations it can be useful:
 
 1. Replacement for subsystem specific methods of publishing/unpublishing
 interfaces. Currently many frameworks allows only querying for presence of 
 given
 interface. In such cases client can defer probing or implement interface
 polling, which is usually subobtimal. Additionally subsystems often do not
 provide methods to signal to the consumers that they are about to be 
 destroyed.
 
 2. Monitoring for different interfaces provided by the same object. An example
 should explain it better. Lets assume in device tree drm crtc device node have
 video link to another node, so it knows only that there is something connected
 to its RGB output. It can be a RGB panel (drm_panel framework), it can be an
 image enhancer (SoC specific framework) or it can be some signal converter
 (drm_encoder, drm_bridge, drm_encoder_slave...). Driver have only phandle to
 another node. Currently it is difficult to handle such situations in a generic
 way. interface_tracker should make it simple: crtc should monitor all 
 supported
 interface types that appears at the device_node pointed by the phandle.
 
 Potential use cases
 ---
 
 Points mentioned above were the reasons for writing this framework. During
 development I have realized that this framework can be also useful for other
 tasks.
 
 3. Replacement for deferred probing - if for some reason driver do not wants 
 to
 defer but it requires given resources it can use interface_tracker. It should 
 be
 possible to create an helper which will wait for appearance of all interfaces
 from a given list, and 'continue' probe only when all resources becomes
 available.
 
 4. Replacement or helper for subsystem specific solutions:
 - V4L2 subdev async registration,
 - component framework.
 Both frameworks solves a problem of tracking sub-components (un-)registration
 by master device, it should be possible to do the same with interface_tracker
 framework. Some additional helpers can be convienent to make the 
 implementation
 easier.
 
 5. Cure the situation with sysfs 'unbind' property. Currently many drivers are
 providers of different resources/interfaces: regulators, clocks, phys,
 V4L2 subdevs, ... They are usually protected from module unloading by getting
 module reference, but there is no protection from driver unbinding using sysfs
 method: echo 'device' /sys/bus/.../drivers/.../unbind. After unbind consumer
 stays with the pointer to non-existing object, next time it tries to use it
 system usually crashes. interface_tracker do not add any protection, but it 
 adds
 a way to signal to the consumer that given resource will disappear. It allows
 to handle such 

Re: [PATCH] [media] Prefer gspca_sonixb over sn9c102 for all devices

[Greg Kroah-Hartman]

On Fri, Apr 11, 2014 at 09:15:32AM +0200, Jean Delvare wrote:
 The sn9c102 driver is deprecated. It was moved to staging in
 anticipation of its removal in a future kernel version. However, USB
 devices 0C45:6024 and 0C45:6025 are still handled by sn9c102 when
 both sn9c102 and gspca_sonixb are enabled.
 
 We must migrate all the users of these devices to the gspca_sonixb
 driver now, so that it gets sufficient testing before the sn9c102
 driver is finally phased out.
 
 Signed-off-by: Jean Delvare jdelv...@suse.de
 Cc: Hans de Goede hdego...@redhat.com
 Cc: Mauro Carvalho Chehab m.che...@samsung.com
 Cc: Luca Risolia luca.riso...@studio.unibo.it
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 ---
 I consider this a bug fix, I believe it should go upstream ASAP.
 

Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: media: omap24xx: fix up some checkpatch.pl issues

[Greg Kroah-Hartman]

On Wed, Apr 09, 2014 at 11:25:18PM +1000, Vitaly Osipov wrote:
 Fixes the following issues:
 
 tcm825x.c:
 
 ERROR: Macros with complex values should be enclosed in parenthesis
 WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then 
 dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
 
 tcm825x.h:
 
 ERROR: Macros with complex values should be enclosed in parenthesis


Please only do one type of thing per patch.  So this should be a series
of 2 patches, one for the macro error, and one for the printk fixes.

Can you please redo these and resend them?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: rtl2832_sdr: fixup checkpatch/style issues

[Greg Kroah-Hartman]

On Wed, Apr 09, 2014 at 08:07:28PM -0400, Anthony DeStefano wrote:
 rtl2832_sdr.c: fixup checkpatch issues about long lines
 
 Signed-off-by: Anthony DeStefano a...@fastmail.fm
 ---
  drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c | 23 ---
  1 file changed, 16 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c 
 b/drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c
 index 104ee8a..0e6c6fa 100644
 --- a/drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c
 +++ b/drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c
 @@ -935,7 +935,9 @@ static int rtl2832_sdr_set_tuner_freq(struct 
 rtl2832_sdr_state *s)
   /*
* bandwidth (Hz)
*/
 - bandwidth_auto = v4l2_ctrl_find(s-hdl, 
 V4L2_CID_RF_TUNER_BANDWIDTH_AUTO);
 + bandwidth_auto = v4l2_ctrl_find(s-hdl,
 + V4L2_CID_RF_TUNER_BANDWIDTH_AUTO);

Please line stuff up under the (, so for this line it would be:

bandwidth_auto = v4l2_ctrl_find(s-hdl,
V4L2_CID_RF_TUNER_BANDWIDTH_AUTO);

Please fix the rest of these all up.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] [media] v4l: omap4iss: Add DEBUG compiler flag

[Greg Kroah-Hartman]

On Thu, Mar 06, 2014 at 01:48:29AM +0100, Laurent Pinchart wrote:
 Hi Joe,
 
 On Wednesday 05 March 2014 16:28:03 Joe Perches wrote:
  On Thu, 2014-03-06 at 00:50 +0100, Laurent Pinchart wrote:
   Please note that -DDEBUG is equivalent to '#define DEBUG', not to '#define
   CONFIG_DEBUG'. 'DEBUG' needs to be defined for dev_dbg() to have any
   effect.
 
  Not quite.  If CONFIG_DYNAMIC_DEBUG is set, these
  dev_dbg statements are compiled in but not by default
  set to emit output.  Output can be enabled by using
  dynamic_debug controls like:
  
  # echo -n 'file omap4iss/* +p'  debugfs/dynamic_debug/control
  
  See Documentation/dynamic-debug-howto.txt for more details.
 
 Thank you for the additional information.
 
 Would you recommend to drop driver-specific Kconfig options related to 
 debugging and use CONFIG_DYNAMIC_DEBUG instead ?

Yes, please do that, no one wants to rebuild drivers and subsystems with
different options just for debugging.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma-buf: avoid using IS_ERR_OR_NULL

[Greg Kroah-Hartman]

On Sat, Dec 21, 2013 at 07:42:17AM -0500, Rob Clark wrote:
 On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross ccr...@android.com wrote:
  dma_buf_map_attachment and dma_buf_vmap can return NULL or
  ERR_PTR on a error.  This encourages a common buggy pattern in
  callers:
  sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
  if (IS_ERR_OR_NULL(sgt))
  return PTR_ERR(sgt);
 
  This causes the caller to return 0 on an error.  IS_ERR_OR_NULL
  is almost always a sign of poorly-defined error handling.
 
  This patch converts dma_buf_map_attachment to always return
  ERR_PTR, and fixes the callers that incorrectly handled NULL.
  There are a few more callers that were not checking for NULL
  at all, which would have dereferenced a NULL pointer later.
  There are also a few more callers that correctly handled NULL
  and ERR_PTR differently, I left those alone but they could also
  be modified to delete the NULL check.
 
  This patch also converts dma_buf_vmap to always return NULL.
  All the callers to dma_buf_vmap only check for NULL, and would
  have dereferenced an ERR_PTR and panic'd if one was ever
  returned. This is not consistent with the rest of the dma buf
  APIs, but matches the expectations of all of the callers.
 
  Signed-off-by: Colin Cross ccr...@android.com
  ---
   drivers/base/dma-buf.c | 18 +++---
   drivers/gpu/drm/drm_prime.c|  2 +-
   drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |  2 +-
   drivers/media/v4l2-core/videobuf2-dma-contig.c |  2 +-
   4 files changed, 14 insertions(+), 10 deletions(-)
 
  diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
  index 1e16cbd61da2..cfe1d8bc7bb8 100644
  --- a/drivers/base/dma-buf.c
  +++ b/drivers/base/dma-buf.c
  @@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* @dmabuf:[in]buffer to attach device to.
* @dev:   [in]device to be attached.
*
  - * Returns struct dma_buf_attachment * for this attachment; may return 
  negative
  - * error codes.
  - *
  + * Returns struct dma_buf_attachment * for this attachment; returns 
  ERR_PTR on
  + * error.
*/
   struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev)
  @@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
* @attach:[in]attachment whose scatterlist is to be returned
* @direction: [in]direction of DMA transfer
*
  - * Returns sg_table containing the scatterlist to be returned; may return 
  NULL
  - * or ERR_PTR.
  - *
  + * Returns sg_table containing the scatterlist to be returned; returns 
  ERR_PTR
  + * on error.
*/
   struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
  enum dma_data_direction direction)
  @@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct 
  dma_buf_attachment *attach,
  return ERR_PTR(-EINVAL);
 
  sg_table = attach-dmabuf-ops-map_dma_buf(attach, direction);
  +   if (!sg_table)
  +   sg_table = ERR_PTR(-ENOMEM);
 
  return sg_table;
   }
  @@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
* These calls are optional in drivers. The intended use for them
* is for mapping objects linear in kernel space for high use objects.
* Please attempt to use kmap/kunmap before thinking about these 
  interfaces.
  + *
  + * Returns NULL on error.
*/
   void *dma_buf_vmap(struct dma_buf *dmabuf)
   {
  @@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
  BUG_ON(dmabuf-vmap_ptr);
 
  ptr = dmabuf-ops-vmap(dmabuf);
  -   if (IS_ERR_OR_NULL(ptr))
  +   if (WARN_ON_ONCE(IS_ERR(ptr)))
 
 since vmap is optional, the WARN_ON might be a bit strong..  although
 it would be a bit strange for an exporter to supply a vmap fxn which
 always returned NULL, not sure about that.  Just thought I'd mention
 it in case anyone else had an opinion about that.

Yeah, I don't like this, it could cause unnecessary reports of problems.

Care to fix it up?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/2] *** SUBJECT HERE ***

[Greg Kroah-Hartman]

On Fri, Feb 07, 2014 at 06:09:46PM +0100, Jean-Francois Moine wrote:
 *** BLURB HERE ***

Subject and BLURB forgotten?

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma-buf: avoid using IS_ERR_OR_NULL

[Greg Kroah-Hartman]

On Fri, Feb 07, 2014 at 09:22:37AM -0800, Colin Cross wrote:
 On Fri, Feb 7, 2014 at 8:43 AM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:
  On Sat, Dec 21, 2013 at 07:42:17AM -0500, Rob Clark wrote:
  On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross ccr...@android.com wrote:
   dma_buf_map_attachment and dma_buf_vmap can return NULL or
   ERR_PTR on a error.  This encourages a common buggy pattern in
   callers:
   sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
   if (IS_ERR_OR_NULL(sgt))
   return PTR_ERR(sgt);
  
   This causes the caller to return 0 on an error.  IS_ERR_OR_NULL
   is almost always a sign of poorly-defined error handling.
  
   This patch converts dma_buf_map_attachment to always return
   ERR_PTR, and fixes the callers that incorrectly handled NULL.
   There are a few more callers that were not checking for NULL
   at all, which would have dereferenced a NULL pointer later.
   There are also a few more callers that correctly handled NULL
   and ERR_PTR differently, I left those alone but they could also
   be modified to delete the NULL check.
  
   This patch also converts dma_buf_vmap to always return NULL.
   All the callers to dma_buf_vmap only check for NULL, and would
   have dereferenced an ERR_PTR and panic'd if one was ever
   returned. This is not consistent with the rest of the dma buf
   APIs, but matches the expectations of all of the callers.
  
   Signed-off-by: Colin Cross ccr...@android.com
   ---
drivers/base/dma-buf.c | 18 +++---
drivers/gpu/drm/drm_prime.c|  2 +-
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |  2 +-
drivers/media/v4l2-core/videobuf2-dma-contig.c |  2 +-
4 files changed, 14 insertions(+), 10 deletions(-)
  
   diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
   index 1e16cbd61da2..cfe1d8bc7bb8 100644
   --- a/drivers/base/dma-buf.c
   +++ b/drivers/base/dma-buf.c
   @@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
 * @dmabuf:[in]buffer to attach device to.
 * @dev:   [in]device to be attached.
 *
   - * Returns struct dma_buf_attachment * for this attachment; may return 
   negative
   - * error codes.
   - *
   + * Returns struct dma_buf_attachment * for this attachment; returns 
   ERR_PTR on
   + * error.
 */
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
 struct device *dev)
   @@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
 * @attach:[in]attachment whose scatterlist is to be returned
 * @direction: [in]direction of DMA transfer
 *
   - * Returns sg_table containing the scatterlist to be returned; may 
   return NULL
   - * or ERR_PTR.
   - *
   + * Returns sg_table containing the scatterlist to be returned; returns 
   ERR_PTR
   + * on error.
 */
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment 
   *attach,
   enum dma_data_direction 
   direction)
   @@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct 
   dma_buf_attachment *attach,
   return ERR_PTR(-EINVAL);
  
   sg_table = attach-dmabuf-ops-map_dma_buf(attach, direction);
   +   if (!sg_table)
   +   sg_table = ERR_PTR(-ENOMEM);
  
   return sg_table;
}
   @@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
 * These calls are optional in drivers. The intended use for them
 * is for mapping objects linear in kernel space for high use objects.
 * Please attempt to use kmap/kunmap before thinking about these 
   interfaces.
   + *
   + * Returns NULL on error.
 */
void *dma_buf_vmap(struct dma_buf *dmabuf)
{
   @@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
   BUG_ON(dmabuf-vmap_ptr);
  
   ptr = dmabuf-ops-vmap(dmabuf);
   -   if (IS_ERR_OR_NULL(ptr))
   +   if (WARN_ON_ONCE(IS_ERR(ptr)))
 
  since vmap is optional, the WARN_ON might be a bit strong..  although
  it would be a bit strange for an exporter to supply a vmap fxn which
  always returned NULL, not sure about that.  Just thought I'd mention
  it in case anyone else had an opinion about that.
 
  Yeah, I don't like this, it could cause unnecessary reports of problems.
 
 The WARN_ON_ONCE is only if the vmap op returns ERR_PTR, not if it
 returns NULL.  This is designed to catch vmap ops that don't follow
 the spec, so I would call them necessary reports, but I can take it
 out if you still disagree.

Ah, ok, that makes more sense.  I'll queue this up.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fw: [PATCH 34/52] devices.txt: add video4linux device for Software Defined Radio

[Greg Kroah-Hartman]

On Tue, Feb 04, 2014 at 11:19:03AM -0200, Mauro Carvalho Chehab wrote:
 Alan/Greg/Andrew/Rob,
 
 Not sure who is currently maintaining Documentation/devices.txt.
 
 We're needing to add support of a new type of V4L2 devices there.
 
 Could you please ack with the following patch? If this one is ok, I intend
 to send via my tree together with the patch series that implements support
 for it, if you agree.
 
 Thank you!
 Mauro
 
 Forwarded message:
 
 Date: Sat, 25 Jan 2014 19:10:28 +0200
 From: Antti Palosaari cr...@iki.fi
 To: linux-media@vger.kernel.org
 Cc: Antti Palosaari cr...@iki.fi, Hans Verkuil hverk...@xs4all.nl
 Subject: [PATCH 34/52] devices.txt: add video4linux device for Software 
 Defined Radio
 
 
 Add new video4linux device named /dev/swradio for Software Defined
 Radio use. V4L device minor numbers are allocated dynamically
 nowadays, but there is still configuration option for old fixed style.
 Add note to mention that configuration option too.
 
 Cc: Hans Verkuil hverk...@xs4all.nl
 Signed-off-by: Antti Palosaari cr...@iki.fi
 Acked-by: Hans Verkuil hans.verk...@cisco.com

Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] staging: go7007: fix use of uninitialised pointer

[Greg Kroah-Hartman]

On Mon, Nov 11, 2013 at 12:46:24PM +0100, Michal Nazarewicz wrote:
 go variable is initialised only after the switch case so it cannot be
 dereferenced prior to that happening.
 
 Signed-off-by: Michal Nazarewicz min...@mina86.com
 ---
  drivers/staging/media/go7007/go7007-usb.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 
 On Sun, Nov 10 2013, Dan Carpenter wrote:
  There are 3 other uses before go gets initialized.
 
 Argh...  Other occurrences of the letters “GO” deceived my eyes.  Sorry
 about that and thanks.

This is no longer needed, as I revertd the patch that caused the
original problems, sorry.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: staging: media: Use dev_err() instead of pr_err()

[Greg Kroah-Hartman]

On Sun, Nov 17, 2013 at 10:03:21AM -0200, Mauro Carvalho Chehab wrote:
 Em Fri, 15 Nov 2013 15:29:39 +0900
 Greg Kroah-Hartman gre...@linuxfoundation.org escreveu:
 
  On Thu, Nov 14, 2013 at 11:08:14AM -0200, Mauro Carvalho Chehab wrote:
   Hi,
   
   I'm not sure how this patch got applied upstream:
   
 commit b6ea5ef80aa7fd6f4b18ff2e4174930e8772e812
 Author: Dulshani Gunawardhana dulshani.gunawardhan...@gmail.com
 Date:   Sun Oct 20 22:58:28 2013 +0530
 
 staging:media: Use dev_dbg() instead of pr_debug()
 
 Use dev_dbg() instead of pr_debug() in go7007-usb.c.
   
 Signed-off-by: Dulshani Gunawardhana 
   dulshani.gunawardhan...@gmail.com
 Reviewed-by: Josh Triplett j...@joshtriplett.org
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
   
   But, from the custody chain, it seems it was not C/C to linux-media ML,
   doesn't have the driver maintainer's ack[1] and didn't went via my tree.
  
  It came in through my tree as part of the OPW intern application
  process.
 
 Ah, OK.
 
 I don't mind if you apply those directly, but what makes me a little
 worried is that at least the final version of the patchset should be
 c/c to driver/subsystem maintainers for their review and for them to 
 know that the patch will be merged via some other tree, as it might
 be causing conflicts with their trees.
 
  And yes, sorry, it's broken, I have some follow-on patches to fix this,
  but you are right, it should just be reverted for now, very sorry about
  that.
 
 No problem.
 
  Do you want to do that, or should I?
 
 I prefer if you could do it, as I'm still waiting the merge from my tree,
 and I don't want to cascade another pull request before the original
 pull requests get handled. In any case, they won't conflict with this,
 as I don't have any patch for this driver on my tree for 3.13.

Ok, I'll do this after 3.13-rc1 is out, sorry for the problems.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fw: staging: media: Use dev_err() instead of pr_err()

[Greg Kroah-Hartman]

On Thu, Nov 14, 2013 at 11:08:14AM -0200, Mauro Carvalho Chehab wrote:
 Hi,
 
 I'm not sure how this patch got applied upstream:
 
   commit b6ea5ef80aa7fd6f4b18ff2e4174930e8772e812
   Author: Dulshani Gunawardhana dulshani.gunawardhan...@gmail.com
   Date:   Sun Oct 20 22:58:28 2013 +0530
   
   staging:media: Use dev_dbg() instead of pr_debug()
   
   Use dev_dbg() instead of pr_debug() in go7007-usb.c.
 
   Signed-off-by: Dulshani Gunawardhana 
 dulshani.gunawardhan...@gmail.com
   Reviewed-by: Josh Triplett j...@joshtriplett.org
   Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
 
 But, from the custody chain, it seems it was not C/C to linux-media ML,
 doesn't have the driver maintainer's ack[1] and didn't went via my tree.

It came in through my tree as part of the OPW intern application
process.

And yes, sorry, it's broken, I have some follow-on patches to fix this,
but you are right, it should just be reverted for now, very sorry about
that.

Do you want to do that, or should I?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: go7007: fix use of uninitialised pointer

[Greg Kroah-Hartman]

On Sun, Nov 10, 2013 at 07:37:57PM +0100, Michal Nazarewicz wrote:
 From: Michal Nazarewicz min...@mina86.com
 
 The go variable is declade without initialisation and invocation of
 dev_dbg immediatelly tries to dereference it.
 ---
  drivers/staging/media/go7007/go7007-usb.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/staging/media/go7007/go7007-usb.c 
 b/drivers/staging/media/go7007/go7007-usb.c
 index 58684da..457ab63 100644
 --- a/drivers/staging/media/go7007/go7007-usb.c
 +++ b/drivers/staging/media/go7007/go7007-usb.c
 @@ -1057,7 +1057,7 @@ static int go7007_usb_probe(struct usb_interface *intf,
   char *name;
   int video_pipe, i, v_urb_len;
  
 - dev_dbg(go-dev, probing new GO7007 USB board\n);
 + pr_debug(probing new GO7007 USB board\n);

Please either delete this entirely, or use the struct device in the
usb_interface pointer.

A driver should never have a raw pr_* call.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL FOR v3.13] OMAP4 ISS driver

[Greg Kroah-Hartman]

On Tue, Oct 15, 2013 at 06:13:04PM +0200, Laurent Pinchart wrote:
 Hello,
 
 Here's a pull request for v3.13 that adds a driver for the OMAP4 ISS (camera 
 interface).

I don't take pull requests for staging drivers.

But even if I did, Mauro takes drivers/staging/media/ code, so it's up
to him to take this, not me.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 8/8] drivers: misc: use module_platform_driver_probe()

[Greg Kroah-Hartman]

On Thu, Mar 14, 2013 at 06:09:38PM +0100, Fabio Porcedda wrote:
 This patch converts the drivers to use the
 module_platform_driver_probe() macro which makes the code smaller and
 a bit simpler.

Someone else beat you to this fix for these files, sorry.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/9] Media Controller capture driver for DM365

[Greg Kroah-Hartman]

On Wed, Nov 28, 2012 at 10:18:02AM -0200, Mauro Carvalho Chehab wrote:
 Em Wed, 28 Nov 2012 12:56:10 +0100
 Hans Verkuil hansv...@cisco.com escreveu:
 
  On Wed 28 November 2012 12:45:37 Dan Carpenter wrote:
   I wish people wouldn't submit big patches right before the merge
   window opens...  :/ It's better to let it sit in linux-next for a
   couple weeks so people can mess with it a bit.
  
  It's been under review for quite some time now, and the main change since
  the last posted version is that this is now moved to staging/media.
  
  So it is not yet ready for prime time, but we do want it in to simplify
  the last remaining improvements needed to move it to drivers/media.
 
 last remaining improvements? I didn't review the patchset, but
 the TODO list seems to have several pending stuff there:
 
 +- User space interface refinement
 +- Controls should be used when possible rather than private ioctl
 +- No enums should be used
 +- Use of MC and V4L2 subdev APIs when applicable
 +- Single interface header might suffice
 +- Current interface forces to configure everything at once
 +- Get rid of the dm365_ipipe_hw.[ch] layer
 +- Active external sub-devices defined by link configuration; no strcmp
 +  needed
 +- More generic platform data (i2c adapters)
 +- The driver should have no knowledge of possible external subdevs; see
 +  struct vpfe_subdev_id
 +- Some of the hardware control should be refactorede
 +- Check proper serialisation (through mutexes and spinlocks)
 +- Names that are visible in kernel global namespace should have a common
 +  prefix (or a few)
 
 From the above comments, both Kernelspace and Userspace APIs require 
 lots of work.
 
 Also, it is not clear at all if this is a fork of the existing davinci
 driver, or if it is a completely new driver for an already-supported
 hardware, making very hard (if not impossible) to review it, and, if it
 is yet-another-driver for the same hardware, moving it out of staging
 will be a big issue, as it won't be trivial to check for regressions
 introduced by a different driver.
 
  
  I'm happy with this going in given the circumstances.
 
 Well, I'm not.

Me either, it is way too late in the cycle to take huge stuff for 3.8,
sorry.

But as I don't manage drivers/staging/media/ there's not even anything I
can do here, it's Mauro's, so I'll leave it up to him :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/9] Media Controller capture driver for DM365

[Greg Kroah-Hartman]

On Wed, Nov 28, 2012 at 08:18:20PM +0100, Hans Verkuil wrote:
 On Wed November 28 2012 18:22:48 Greg Kroah-Hartman wrote:
  On Wed, Nov 28, 2012 at 10:18:02AM -0200, Mauro Carvalho Chehab wrote:
   Em Wed, 28 Nov 2012 12:56:10 +0100
   Hans Verkuil hansv...@cisco.com escreveu:
   
On Wed 28 November 2012 12:45:37 Dan Carpenter wrote:
 I wish people wouldn't submit big patches right before the merge
 window opens...  :/ It's better to let it sit in linux-next for a
 couple weeks so people can mess with it a bit.

It's been under review for quite some time now, and the main change 
since
the last posted version is that this is now moved to staging/media.

So it is not yet ready for prime time, but we do want it in to simplify
the last remaining improvements needed to move it to drivers/media.
   
   last remaining improvements? I didn't review the patchset, but
   the TODO list seems to have several pending stuff there:
   
   +- User space interface refinement
   +- Controls should be used when possible rather than private ioctl
   +- No enums should be used
   +- Use of MC and V4L2 subdev APIs when applicable
   +- Single interface header might suffice
   +- Current interface forces to configure everything at once
   +- Get rid of the dm365_ipipe_hw.[ch] layer
   +- Active external sub-devices defined by link configuration; no strcmp
   +  needed
   +- More generic platform data (i2c adapters)
   +- The driver should have no knowledge of possible external subdevs; see
   +  struct vpfe_subdev_id
   +- Some of the hardware control should be refactorede
   +- Check proper serialisation (through mutexes and spinlocks)
   +- Names that are visible in kernel global namespace should have a common
   +  prefix (or a few)
   
   From the above comments, both Kernelspace and Userspace APIs require 
   lots of work.
 
 And that's why it is in staging. Should a long TODO list now suddenly
 prevent staging from being used? In Barcelona we discussed this and the
 only requirement we came up was was that it should compile.

Yes, that's all I care about in staging, but as I stated, I don't
maintain drivers/staging/media/ that area is under Mauro's control
(MAINTAINERS even says this), and I'm a bit leery of going against the
wishes of an existing subsystem maintainer for adding staging drivers
that tie into their subsystem.

So if you get Mauro's approval, I'll be glad to queue it up.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/9] Media Controller capture driver for DM365

[Greg Kroah-Hartman]

On Wed, Nov 28, 2012 at 08:30:04PM +0100, Sylwester Nawrocki wrote:
 On 11/28/2012 01:22 PM, Dan Carpenter wrote:
  In the end this is just a driver, and I don't especially care.  But
  it's like not just this one which makes me frustrated.  I really
  believe in linux-next and I think everything should spend a couple
  weeks there before being merged.
 
 Couple of weeks in linux-next plus a couple of weeks of final patch
 series version awaiting to being reviewed and picked up by a maintainer
 makes almost entire kernel development cycle.

If I were to take this today, it would only live in linux-next for less
than a week before it would be sent to Linus due to where we are in the
development cycle, so Dan's objections are quite valid.

 These are huge additional delays, especially in the embedded world.

Embedded is special just like everyone else.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fw: [PATCH] dma-mapping: fix dma_common_get_sgtable() conditional compilation

[Greg Kroah-Hartman]

On Mon, Nov 26, 2012 at 06:18:37PM -0200, Mauro Carvalho Chehab wrote:
 Hi Greg,
 
 Are you maintaining drivers/base/dma-mapping.c? The enclosed path is needed to
 enable DMABUF handling on V4L2 on some architectures, like x86_64, as we need
 dma_common_get_sgtable() on drivers/media/v4l2-core/videobuf2-dma-contig.c.
 
 Would you mind acking it, in order to let this patch flow via my tree? This 
 way,
 I can revert a workaround I had to apply there, in order to avoid linux-next
 compilation breakage.
 
 Thanks!
 Mauro
 
 -
 
 From: Marek Szyprowski m.szyprow...@samsung.com
 Date: Mon, 26 Nov 2012 14:41:48 +0100
 
 dma_common_get_sgtable() function doesn't depend on
 ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY, so it must not be compiled
 conditionally.
 
 Reported-by: Stephen Rothwell s...@canb.auug.org.au
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com

Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging/media: Use dev_ printks in go7007/s2250-loader.c

[Greg Kroah-Hartman]

On Mon, Nov 05, 2012 at 08:34:42PM +0900, YAMANE Toshiaki wrote:
 fixed below checkpatch warnings.
 - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then 
 pr_err(...  to printk(KERN_ERR ...
 - WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then 
 pr_info(...  to printk(KERN_INFO ...
 
 Signed-off-by: YAMANE Toshiaki yamaneto...@gmail.com
 ---
  drivers/staging/media/go7007/s2250-loader.c |   35 
 ++-
  1 file changed, 18 insertions(+), 17 deletions(-)

Please note that I don't touch the drivers/staging/media/* files, so
copying me on these patches doesn't do anything :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging/media: Use dev_ printks in go7007/s2250-loader.c

[Greg Kroah-Hartman]

On Mon, Nov 05, 2012 at 07:11:11AM -0800, Joe Perches wrote:
 On Mon, 2012-11-05 at 14:11 +0100, Greg Kroah-Hartman wrote:
  On Mon, Nov 05, 2012 at 08:34:42PM +0900, YAMANE Toshiaki wrote:
   fixed below checkpatch warnings.
   - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then 
   pr_err(...  to printk(KERN_ERR ...
   - WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then 
   pr_info(...  to printk(KERN_INFO ...
   
   Signed-off-by: YAMANE Toshiaki yamaneto...@gmail.com
   ---
drivers/staging/media/go7007/s2250-loader.c |   35 
   ++-
1 file changed, 18 insertions(+), 17 deletions(-)
  
  Please note that I don't touch the drivers/staging/media/* files, so
  copying me on these patches doesn't do anything :)
 
 Maybe:
 
  MAINTAINERS |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/MAINTAINERS b/MAINTAINERS
 index b062349..542a541 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -6906,6 +6906,7 @@ T:  git 
 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
  L:   de...@driverdev.osuosl.org
  S:   Supported
  F:   drivers/staging/
 +X:   drivers/staging/media/

Sure, that would be good, care to resend it with a signed-off-by: so I
can apply it?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Q] reprobe deferred-probing drivers

[Greg Kroah-Hartman]

On Wed, Oct 17, 2012 at 10:27:36AM +0200, Guennadi Liakhovetski wrote:
 Hi
 
 I've got a situation, for which I currently don't have a (good) solution.
 
 Let's say device A depends on device B and as long as B hasn't probed, A 
 requests deferred probing. Now B probes, which causes A to also succeed 
 its probing. Next we want to remove B, say, by unloading its driver. A has 
 to go back into deferred-probing state. How do we do it? This can be 
 achieved by unloading B's driver and loading again. Essentially, we have 
 to use the sysfs unbind and then the bind attributes. But how do we do 
 this from the kernel? Shall we export driver_bind() and driver_unbind()?

No, no driver should ever have to mess with that at all, it is up to the
bus to do this.  Do you have a pointer to the code you are concerned
about?

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/16] mm/drivers: use vm_flags_t for vma flags

[Greg Kroah-Hartman]

On Wed, Mar 21, 2012 at 10:56:33AM +0400, Konstantin Khlebnikov wrote:
 Signed-off-by: Konstantin Khlebnikov khlebni...@openvz.org
 Cc: linux-media@vger.kernel.org
 Cc: de...@driverdev.osuosl.org
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Cc: Mauro Carvalho Chehab mche...@infradead.org
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 Cc: John Stultz john.stu...@linaro.org
 Cc: Arve Hjønnevåg a...@android.com

Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3.0.y 0/4] Re: lirc_serial spuriously claims assigned port and irq to be in use

[Greg Kroah-Hartman]

On Wed, Mar 07, 2012 at 02:17:09PM -0600, Jonathan Nieder wrote:
 Greg Kroah-Hartman wrote:
  On Fri, Mar 02, 2012 at 02:39:13PM -0600, Jonathan Nieder wrote:
  Ben Hutchings wrote:
  On Thu, 2012-03-01 at 21:45 -0600, Jonathan Nieder wrote:
 
  Would some of these patches (e.g., at least patches 1, 2, and 5) be
  appropriate for inclusion in the 3.0.y and 3.2.y stable kernels from
  kernel.org?
 
  Assuming they haven't caused any regressions, I think everything except
  9b98d6067971 (4/5) would be appropriate.
 
  Great.  Here are the aforementioned patches rebased against 3.0.y,
 [...]
  So they should also go to 3.2-stable, right?
 
 Yes.

Thanks, all now queued up.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3.0.y 0/4] Re: lirc_serial spuriously claims assigned port and irq to be in use

[Greg Kroah-Hartman]

On Fri, Mar 02, 2012 at 02:39:13PM -0600, Jonathan Nieder wrote:
 Ben Hutchings wrote:
  On Thu, 2012-03-01 at 21:45 -0600, Jonathan Nieder wrote:
 
  Would some of these patches (e.g., at least patches 1, 2, and 5) be
  appropriate for inclusion in the 3.0.y and 3.2.y stable kernels from
  kernel.org?
 
  Assuming they haven't caused any regressions, I think everything except
  9b98d6067971 (4/5) would be appropriate.
 
 Great.  Here are the aforementioned patches rebased against 3.0.y, in
 the hope that some interested person can confirm they still work.  The
 only backporting needed was to adjust to the lack of
 drivers/staging/lirc - drivers/staging/media/lirc renaming.

So they should also go to 3.2-stable, right?

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html