This patch resolves coding style space ERRORs reported by checkpatch
ERROR: spaces required around that '>' (ctx:VxV)
ERROR: space required after that ',' (ctx:VxO)
ERROR: space required before that '&' (ctx:OxV)
ERROR: spaces required around that '!=' (ctx:VxV)
ERROR: spaces required around that
On Fri, Mar 15, 2019 at 10:49:46AM +0530, Vaibhav Agarwal wrote:
> On Thu, Mar 14, 2019 at 12:15 PM Kangjie Lu wrote:
> >
> > ida_simple_get could fail. The fix inserts a check for its
> > return value.
> >
> > Signed-off-by: Kangjie Lu
> > ---
> > drivers/staging/greybus/audio_manager.c | 3
On 4/30/19 7:10 AM, Christian König wrote:
> diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
> index 2c4f324f8626..cacca830b482 100644
> --- a/drivers/xen/gntdev-dmabuf.c
> +++ b/drivers/xen/gntdev-dmabuf.c
> @@ -608,6 +608,7 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv
On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote:
> Add a structure for the parameters of dma_buf_attach, this makes it much
> easier
> to add new parameters later on.
I don't understand this reasoning. What are the "new parameters" that
are being proposed, and why do we need to
Hi "Christian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.1-rc7 next-20190430]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0d
Thanks Rui for catching the bisect problem, I will fix for v3.
Steve
On 4/30/19 2:56 PM, Rui Miguel Silva wrote:
Hi Steve,
On Sun 28 Apr 2019 at 20:09, Steve Longerbeam wrote:
Because the IPU sub-devices VDIC and IC are not present in the
device-tree, platform devices were created for them
Setting the media entity pads after the async register subdev can be
racy with probe complete callback. So, make sure that the media pads
are initialized before the probe complete is called.
For that move the media entity pads initialization to the registered
subdev internal operation.
Re-organize modules, and which objects are linked into those modules, so
that:
- imx6-media (renamed from imx-media) is the media driver module for
imx5/6 only, and has no symbol exports.
- imx6-media-csi (renamed from imx-media-csi) is the subdev driver
module for imx5/6 CSI. It is now
Move imx_media_add_video_device() into imx_media_capture_device_register().
Also the former has no error conditions to convert to void.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-ic-prpencvf.c | 5 -
drivers/staging/media/imx/imx-media-capture.c | 3 +++
Rvert this commit, as imx_media_capture_device_set_format() will be
removed. The arguments to mx_media_mbus_fmt_to_pix_fmt() and
imx_media_capture_device_set_format() in imx7_csi_set_fmt() are also
reverted.
This reverts commit 5964cbd8692252615370b77eb96764dd70c2f837.
Signed-off-by: Steve
Don't propagate the source pad format to the connected capture device.
It's now the responsibility of userspace to call VIDIOC_S_FMT on the
capture device to ensure the capture format and compose rectangle
are compatible with the connected source. To check this, validate
the capture format with
Export find_pipeline_pad(), renaming to imx_media_pipeline_pad(), and
extend its functionality to allow searching for video devices in the
enabled pipeline in addition to sub-devices.
As part of this:
- Rename imx_media_find_mipi_csi2_channel() to
imx_media_pipeline_csi2_channel().
- Remove
Allocate and free a DMA coherent buffer in imx_media_alloc/free_dma_buf()
from the given device. This allows DMA alloc and free using a device
that is backed by real hardware, which for the imx5/6/7 CSI is the CSI
unit, and for the internal IPU sub-devices, is the parent IPU.
Signed-off-by: Steve
Because the IPU sub-devices VDIC and IC are not present in the
device-tree, platform devices were created for them instead. This
allowed these sub-devices to be added to the media device's async
notifier and registered asynchronously along with the other
sub-devices that do have a device-tree
The media device is already available via multiple methods, there is no
need to set driver data for v4l2_dev to the media device.
In imx_media_link_notify(), get media device from link->graph_obj.mdev.
In imx_media_capture_device_register(), get media device from
v4l2_dev->mdev.
Signed-off-by:
Yes, because the reverted commit was merged before the imx7 support, I
will fix this for v3.
Steve
On 4/30/19 3:00 PM, Rui Miguel Silva wrote:
Hi Steve,
On Sun 28 Apr 2019 at 20:09, Steve Longerbeam wrote:
Rvert this commit, as imx_media_capture_device_set_format() will be
removed.
This
Hi Steve,
On Sun 28 Apr 2019 at 20:09, Steve Longerbeam wrote:
> Rvert this commit, as imx_media_capture_device_set_format() will be
> removed.
>
> This reverts commit 5964cbd8692252615370b77eb96764dd70c2f837.
>
> Signed-off-by: Steve Longerbeam
> ---
>
Hi Steve,
On Sun 28 Apr 2019 at 20:09, Steve Longerbeam wrote:
> Because the IPU sub-devices VDIC and IC are not present in the
> device-tree, platform devices were created for them instead. This
> allowed these sub-devices to be added to the media device's async
> notifier and registered
Return value directly without saving it in a variable and remove that
variable.
Issue suggested by Coccinelle.
Signed-off-by: Vatsala Narang
---
Changes in v2:
-Change subject line and log message
-Remove respective unused variable
drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
linux/commits/Christian-K-nig/dma-buf-add-struct-dma_buf_attach_info-v2/20190430-221017
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
i.MX7 and i.MX6UL/L have the same CSI controller. So add i.MX6UL/L support
to imx7-media-csi driver.
Signed-off-by: Sébastien Szymanski
---
This patch needs the following patch from Rui Miguel Silva:
https://patchwork.linuxtv.org/patch/55657/
I have tested this patch with a OV5640 sensor
On Sat, Apr 27, 2019 at 04:38:45AM +0200, Nicholas Mc Guire wrote:
> weit_for_completion_interruptible returns in (0 on completion and
> -ERESTARTSYS on interruption) - so use an int not long for API conformance
> and simplify the logic here a bit: need not check explicitly for == 0 as
> this is
Add a structure for the parameters of dma_buf_attach, this makes it much easier
to add new parameters later on.
v2: rebase cleanup and fix all new implementations as well
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 13 +++--
This patch fixes the usage of the wrong struct device when calling
function snd_card_new.
Reported-by: Eugeniu Rosca
Signed-off-by: Christian Gromm
---
drivers/staging/most/sound/sound.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/most/sound/sound.c
On Wed, Apr 24, 2019 at 11:57:43AM -0700, Nathan Chancellor wrote:
> diff --git a/drivers/staging/kpc2000/kpc2000/cell_probe.c
> b/drivers/staging/kpc2000/kpc2000/cell_probe.c
> index ad2cc0a3bfa1..13f544f3c0b9 100644
> --- a/drivers/staging/kpc2000/kpc2000/cell_probe.c
> +++
On Tue, Apr 30, 2019 at 11:00:22AM +0200, Christian Gromm wrote:
> This patch fixes the usage of the wrong struct device when calling
> function snd_card_new.
>
> Reported-by: Eugeniu Rosca
> Signed-off-by: Christian Gromm
> ---
> drivers/staging/most/sound/sound.c | 2 +-
> 1 file changed, 1
On Sat, Apr 27, 2019 at 05:27:25AM +0200, Nicholas Mc Guire wrote:
> wait_for_completion_timeout() returns unsigned long (0 on timeout or
> remaining jiffies) not int.
>
Yeah, but it's fine though because 1 / 256 fits into int without a
problem.
I'm not sure this sort of patch is worth it
On Sat, Apr 27, 2019 at 11:14:34AM +0200, Nicholas Mc Guire wrote:
> weit_for_completion_interruptible returns in (0 on completion and
^
wait_for_completion_interruptible
> -ERESTARTSYS on interruption) - so use an int not long for API conformance
> and simplify the logic here a bit: need
The code is calculating the resource size wrong because it should be
inclusive of the "res->end" address. In other words, "end - start + 1".
We can just use the resource_size() function to do it correctly.
Fixes: 7dc7967fc39a ("staging: kpc2000: add initial set of Daktronics drivers")
The kp2000_regs struct has a 4 byte hole between ->hw_rev and ->ssid so
this could leak stack information to the user. This patch just memsets
the whole struct to zero.
Fixes: 7dc7967fc39a ("staging: kpc2000: add initial set of Daktronics drivers")
Signed-off-by: Dan Carpenter
---
This patch fixes the usage of the wrong struct device when calling
function snd_card_new.
Reported-by: Eugeniu Rosca
Signed-off-by: Christian Gromm
Fixes: commit 69c90cf1b2faf5fa08fe5e18e4b47b044474506e
---
v2: add Fixes tag to s-o-b area
drivers/staging/most/sound/sound.c | 2 +-
1 file
On Tue, Apr 30, 2019 at 11:53:01AM +, christian.gr...@microchip.com wrote:
> On Di, 2019-04-30 at 11:20 +0200, Greg KH wrote:
> > External E-Mail
> >
> >
> > On Tue, Apr 30, 2019 at 11:00:22AM +0200, Christian Gromm wrote:
> > >
> > > This patch fixes the usage of the wrong struct device
On Di, 2019-04-30 at 11:20 +0200, Greg KH wrote:
> External E-Mail
>
>
> On Tue, Apr 30, 2019 at 11:00:22AM +0200, Christian Gromm wrote:
> >
> > This patch fixes the usage of the wrong struct device when calling
> > function snd_card_new.
> >
> > Reported-by: Eugeniu Rosca
> > Signed-off-by:
On Tue, Apr 30, 2019 at 12:58:21PM +0300, Dan Carpenter wrote:
> On Sat, Apr 27, 2019 at 05:27:25AM +0200, Nicholas Mc Guire wrote:
> > wait_for_completion_timeout() returns unsigned long (0 on timeout or
> > remaining jiffies) not int.
> >
>
> Yeah, but it's fine though because 1 / 256
On Mon, Apr 29, 2019 at 01:06:58PM +0530, Vatsala Narang wrote:
> Modify return statement and remove the respective assignment.
>
> Issue found by coccinelle.
>
> Signed-off-by: Vatsala Narang
> ---
> drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c | 3 +--
> 1 file changed, 1
On Tue, Apr 30, 2019 at 02:07:48PM +0200, Christian Gromm wrote:
> This patch fixes the usage of the wrong struct device when calling
> function snd_card_new.
>
> Reported-by: Eugeniu Rosca
> Signed-off-by: Christian Gromm
> Fixes:commit 69c90cf1b2faf5fa08fe5e18e4b47b044474506e
Nit,
On Tue, Apr 30, 2019 at 09:32:20AM -0400, Sven Van Asbroeck wrote:
> On Tue, Apr 30, 2019 at 12:19 AM Al Viro wrote:
> >
> > ... not that there's much sense keeping ->fieldbus_type in host-endian,
> > while we are at it.
>
> Interesting! Suppose we make device->fieldbus_type bus-endian.
Keep it
On Tue, Apr 30, 2019 at 10:03 AM Greg Kroah-Hartman
wrote:
>
> Keep it bus-endian, as that's the "normal" way bus structures work (like
> PCI and USB for example), and that should be in a documented, and
> consistent, form, right?
>
> Then do the conversion when you access the field from within
On Tue, Apr 30, 2019 at 10:22 AM Sven Van Asbroeck wrote:
>
> Ah ok, it's like a standard way of implementing a bus. Sounds good, I'll
> spin a patch to conform to it. And while I'm at it, I'll rename fieldbus_type
> because it can be confused with another fieldbus_type within the
> fieldbus_dev
On Tue, Apr 30, 2019 at 09:32:20AM -0400, Sven Van Asbroeck wrote:
> On Tue, Apr 30, 2019 at 12:19 AM Al Viro wrote:
> >
> > ... not that there's much sense keeping ->fieldbus_type in host-endian,
> > while we are at it.
>
> Interesting! Suppose we make device->fieldbus_type bus-endian.
> Then
On Tue, Apr 30, 2019 at 12:19 AM Al Viro wrote:
>
> ... not that there's much sense keeping ->fieldbus_type in host-endian,
> while we are at it.
Interesting! Suppose we make device->fieldbus_type bus-endian.
Then the endinan-ness conversion either needs to happen in
bus_match() (and we'd have
41 matches
Mail list logo
