[PATCH v4] staging: rtl8192e: Aligning the * on each line in block comments

This patch fixes the issue by aligning the * on each line in block comments. [Patch v1] is rejected as the changes done is not following the linux coding style and [Patch v2] is rejected because forgot to mention the cause of rejection of [Patch v1].The cause of rejection of [Patch v3] is that the

[PATCH v4] staging: rtl8192e: Aligning the * on each line in block comments

This patch fixes the issue by aligning the * on each line in block comments. [Patch v1] is rejected as the changes done is not following the linux coding style and [Patch v2] is rejected because forgot to mention the cause of rejection of [Patch v1].The cause of rejection of [Patch v3] is that the

RE: [PATCH 9/9] staging: fsl-mc: dprc: drop unused APIs

> --- a/drivers/staging/fsl-mc/include/dprc.h > +++ b/drivers/staging/fsl-mc/include/dprc.h > @@ -42,20 +42,6 @@ > > struct fsl_mc_io; > > -/** > - * Set this value as the icid value in dprc_cfg structure when creating a > - * container, in case the ICID is not selected by the user and should

Re: [PATCH] staging: lustre: remove CLASSERT macro

On Feb 2, 2017, at 04:26, Arnd Bergmann wrote: > > lustre uses a fake switch() statement as a compile-time assert, but > unfortunately > each use of that causes a warning when building with clang: > > drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2907:2: warning: no case

Re: [PATCH] staging: fbtft: change 'gamma' array to u32

On Thu, 2017-02-02 at 15:43 +0100, Arnd Bergmann wrote: > Having a local variable of 1024 bytes on 64-bit architectures is a bit > too much, and I ran into this warning while trying to see what functions > use the largest stack: > > drivers/staging/fbtft/fbtft-sysfs.c: In function

RE: [PATCH 4/9] staging: fsl-mc: don't use devres api for refcounted objects

> -Original Message- > From: laurentiu.tu...@nxp.com [mailto:laurentiu.tu...@nxp.com] > Sent: Wednesday, February 01, 2017 5:43 AM > To: gre...@linuxfoundation.org > Cc: de...@driverdev.osuosl.org; linux-ker...@vger.kernel.org; ag...@suse.de; > a...@arndb.de; Ioana > Ciornei

RE: [PATCH 3/9] staging: fsl-mc: add device release callback

> -Original Message- > From: upstream-release-boun...@linux.freescale.net [mailto:upstream-release- > boun...@linux.freescale.net] On Behalf Of laurentiu.tu...@nxp.com > Sent: Wednesday, February 01, 2017 5:43 AM > To: gre...@linuxfoundation.org > Cc: de...@driverdev.osuosl.org;

Re: [PATCH v2] staging: rtl8188eu: remove not necessary braces {} (checkpatch fix)

On Thu, 2017-02-02 at 08:06 +0200, Martin Karamihov wrote: > On 02/01/2017 08:11 PM, Joe Perches wrote: > > ...and clarifying the code for a > > human reader is much more important than making a > > file not have any checkpatch warnings. > > I agree. I respect the developers' own coding style and

Re: [PATCH] staging: rtl8188eu: checkpatch fixes: removed not necessary braces {}

On Sun, 2017-01-29 at 17:43 +0100, Bjørn Mork wrote: > Greg KH writes: > > > Please take some time, and go read Documentation/SubmittingPatches. > > That's quickly done nowadays: > > bjorn@miraculix:/usr/local/src/git/linux$ cat Documentation/SubmittingPatches >

Re: [PATCH v3 16/24] media: Add i.MX media core driver

On Fri, Jan 06, 2017 at 06:11:34PM -0800, Steve Longerbeam wrote: > +/* register an internal subdev as a platform device */ > +static struct imx_media_subdev * > +add_internal_subdev(struct imx_media_dev *imxmd, > + const struct internal_subdev *isd, > + int ipu_id)

Re: [PATCH v3 16/24] media: Add i.MX media core driver

On Fri, Jan 06, 2017 at 06:11:34PM -0800, Steve Longerbeam wrote: > +struct imx_media_dev { > + struct media_device md; > + struct v4l2_device v4l2_dev; This is similarly buggy. struct v4l2_device { struct device *dev; #if defined(CONFIG_MEDIA_CONTROLLER) struct

Re: [PATCH v3 20/24] media: imx: Add Camera Interface subdev driver

On Fri, Jan 06, 2017 at 06:11:38PM -0800, Steve Longerbeam wrote: > +struct camif_priv { > + struct device *dev; > + struct video_devicevfd; You can't do this. > +static struct video_device camif_videodev = { > + .fops = _fops, > + .ioctl_ops =

Re: [PATCH v3 00/24] i.MX Media Driver

On Thu, Feb 02, 2017 at 11:12:41AM -0800, Steve Longerbeam wrote: > Here is the current .queue_setup() op in imx-media-capture.c: > > static int capture_queue_setup(struct vb2_queue *vq, >unsigned int *nbuffers, >unsigned int

Re: [PATCH v3 00/24] i.MX Media Driver

On 02/02/2017 10:58 AM, Russell King - ARM Linux wrote: On Thu, Feb 02, 2017 at 10:26:55AM -0800, Steve Longerbeam wrote: On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote: and for whatever reason we end up falling out through free_ring. This is VERY bad news, because it means that the

Re: [PATCH v3 00/24] i.MX Media Driver

On Thu, Feb 02, 2017 at 10:26:55AM -0800, Steve Longerbeam wrote: > On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote: > >and for whatever reason we end up falling out through free_ring. This > >is VERY bad news, because it means that the ring which SMFC took a copy > >of is now freed

Re: [PATCH v3 00/24] i.MX Media Driver

On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote: On Thu, Feb 02, 2017 at 05:22:46PM +, Russell King - ARM Linux wrote: I thought, maybe, it's the IPU overwriting past the end of the buffer, but I've added checks and that doesn't seem to have fired. I also wondered if it was some

Re: [PATCH v3] staging: rtl8192e: Aligning the * on each line in block comments

On Thu, 2017-02-02 at 23:28 +0530, Arushi wrote: > This patch fixes the issue by aligning the * on each line in block comments. > [Patch v1] is rejected as the changes done is not following the linux > coding style and [Patch v2] is rejected because forgot to mention the > cause of rejection of

[PATCH v3] staging: rtl8192e: Aligning the * on each line in block comments

This patch fixes the issue by aligning the * on each line in block comments. [Patch v1] is rejected as the changes done is not following the linux coding style and [Patch v2] is rejected because forgot to mention the cause of rejection of [Patch v1]. Signed-off-by: Arushi

Re: [PATCH v3 00/24] i.MX Media Driver

On Thu, Feb 02, 2017 at 05:22:46PM +, Russell King - ARM Linux wrote: > I thought, maybe, it's the IPU overwriting past the end of the buffer, > but I've added checks and that doesn't seem to have fired. I also > wondered if it was some kind of use-after-free of the ring, so I made >

Re: [PATCH v3 00/24] i.MX Media Driver

Hi Russell, I don't recommend spending too much time debugging this OOPS. The dma buffer ring has been removed completely in version 4 (which I'm trying to get ready to post hopefully by end of this week). Steve On 02/02/2017 09:22 AM, Russell King - ARM Linux wrote: I seem to be getting

Re: [PATCH v2] staging: rtl8192e: Aligning the * on each line in block comments

On Thu, Feb 02, 2017 at 10:26:02PM +0530, Arushi wrote: > This patch fixes the issue by aligning the * on each line in block comments. > > Signed-off-by: Arushi > --- > drivers/staging/speakup/fakekey.c| 10 +- > drivers/staging/speakup/i18n.c

Re: [PATCH v3 00/24] i.MX Media Driver

I seem to be getting some sort of memory corruption with this driver. I've had two instances now of uninitialised spinlocks in imx_media_dma_buf_get_active() which show that the spinlock being taken in this function is all-zeros. That very quickly leads to an oops, where I've seen buf->ring is

[PATCH v2] staging: rtl8192e: Aligning the * on each line in block comments

This patch fixes the issue by aligning the * on each line in block comments. Signed-off-by: Arushi --- drivers/staging/speakup/fakekey.c| 10 +- drivers/staging/speakup/i18n.c | 14 +++--- drivers/staging/speakup/main.c

[PATCH] staging: lustre: fix coding style issue in vvp_page.c

This is a patch to fix "WARNING: line over 80 characters" found by checkpatch.pl in vvp_page.c. Signed-off-by: Zhengyi Shen --- drivers/staging/lustre/lustre/llite/vvp_page.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH] staging: fbtft: change 'gamma' array to u32

Having a local variable of 1024 bytes on 64-bit architectures is a bit too much, and I ran into this warning while trying to see what functions use the largest stack: drivers/staging/fbtft/fbtft-sysfs.c: In function 'store_gamma_curve': drivers/staging/fbtft/fbtft-sysfs.c:132:1: warning: the

[PATCH] staging: rtl8192u: move stats_IndicateArray off stack

Putting 128 pointers on the stack is rather wasteful, in particular on 64-bit architectures: drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c: In function 'RxPktPendingTimeout': drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:92:1: warning: the frame size of 1072 bytes is larger than

[PATCH] staging/emxx_udc: Fix styling issues

Fix line over 80 characters. Statements longer than 80 columns were broken into sensible chunks. Descendants in four different palces were in the same uniform style. Signed-off-by: Zhengyi Shen --- drivers/staging/emxx_udc/emxx_udc.c | 13 - 1 file changed, 8

RE: [PATCH 05/10] staging: unisys: visorbus: Clarify reason for pointer check in bus_destroy()

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Thursday, February 02, 2017 7:14 AM > To: Kershner, David A > Cc: driverdev-devel@linuxdriverproject.org; *S-Par-Maintainer > ; jes.soren...@gmail.com;

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

On Thu, Feb 2, 2017 at 1:22 PM, Greg Kroah-Hartman wrote: > 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:

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

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

[PATCH] staging: bcm2835: don't mark 'bcm2835_v4l2_debug' as static

This one unfortunately slipped through my own build testing, my patch caused a new build error: bcm2835-camera.c:53:12: error: static declaration of 'bcm2835_v4l2_debug' follows non-static declaration We want the symbol to be global as it is indeed used in more than one file and declared

Re: [PATCH 00/10] staging: unisys: additional error handling and channel cleanups.

On Wed, Feb 01, 2017 at 05:38:52PM -0500, David Kershner wrote: > This series fixes a problem where we were using a Linux specific data > structure in our s-Par channel. These channels are shared across multiple > OS types and should not use OS specific structures unless absolutely > needed. It

[PATCH 1/2] staging: rts5208: remove redundant retval status check

From: Colin Ian King The retval status checks in the proceeding do loop return out of function ms_read_attritbute_info if there is an error condition, thus we never reach the end of the loop with retval failed status. Therefore, the retval status check at end of the

Re: [PATCH 10/10] staging: unisys: visorbus: Clarify reason for device pointer checks

On Wed, Feb 01, 2017 at 05:39:02PM -0500, David Kershner wrote: > From: David Binder > > Clarifies why the pointers returned from visorbus_get_device_by_id() in > visorbus are validated. The check is performed in order to be extra > careful, for the sake of added

Re: [PATCH 09/10] staging: unisys: visorbus: Clarify reason for bus pointer checks

On Wed, Feb 01, 2017 at 05:39:01PM -0500, David Kershner wrote: > From: David Binder > > Clarifies why the pointers returned from visorbus_get_device_by_id() in > visorbus are validated. The check is performed in order to be extra > careful, for the sake of added

Re: [PATCH 05/10] staging: unisys: visorbus: Clarify reason for pointer check in bus_destroy()

On Wed, Feb 01, 2017 at 05:38:57PM -0500, David Kershner wrote: > From: David Binder > > Clarifies why the pointer returned from visorbus_get_device_by_id() in > bus_destroy() is validated. The check is performed in order to be extra > careful, for the sake of added

[PATCH 2/2] staging: rts5208: remove unncessary result set and check, just return SUCCESS

From: Colin Ian King Minor clean up, there is no need to assign result to zero, then check if it is less than zero. Just return SUCCESS. Signed-off-by: Colin Ian King --- drivers/staging/rts5208/rtsx.c | 6 ++ 1 file changed, 2

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

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

Re: [PATCH 01/10] staging: unisys: include: fix improper use of dma_data_direction

On Wed, Feb 01, 2017 at 05:38:53PM -0500, David Kershner wrote: > From: Steven Matthews > > Replace use of standard Linux dma_data_direction with a Unisys- > specific uis_dma_data_direction and provide a function to convert > from the latter to the former. This is

Re: [PATCH] staging: rtl8192u: Adding a blank line after declarations

On Thu, Feb 02, 2017 at 01:21:13AM +0530, simran singhal wrote: > This patch fixes the checkpatch warning by adding a blank line after > declarations. > WARNING: Missing a blank line after declarations > > Signed-off-by: simran singhal > --- >

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

On Thu, Feb 2, 2017 at 12:34 PM, Arnd Bergmann wrote: > I got a link error in allyesconfig: > > drivers/staging/media/platform/bcm2835/bcm2835-camera.o: In function > `vidioc_enum_framesizes': > bcm2835-camera.c:(.text.vidioc_enum_framesizes+0x0): multiple definition of >

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

On Fri, 2017-01-06 at 18:11 -0800, Steve Longerbeam wrote: > Adds MIPI CSI-2 Receiver subdev driver. This subdev is required > for sensors with a MIPI CSI2 interface. > > Signed-off-by: Steve Longerbeam > --- > drivers/staging/media/imx/Makefile| 1 + >

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

I got a link error in allyesconfig: drivers/staging/media/platform/bcm2835/bcm2835-camera.o: In function `vidioc_enum_framesizes': bcm2835-camera.c:(.text.vidioc_enum_framesizes+0x0): multiple definition of `vidioc_enum_framesizes'

[PATCH] staging: lustre: remove CLASSERT macro

lustre uses a fake switch() statement as a compile-time assert, but unfortunately each use of that causes a warning when building with clang: drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2907:2: warning: no case matching constant switch condition '42'

Re: [PATCH] staging: lustre: shut up clang warnings on CLASSERT()

On Feb 2, 2017 11:43 AM, "Greg Kroah-Hartman" wrote: > On Thu, Feb 02, 2017 at 11:40:32AM +0100, Arnd Bergmann wrote: > > I've done a semi-automated patch to replace CLASSERT() with the respective > > BUILD_BUG_ON() now, but that patch is quite large. > > Should be

Re: [PATCH v3 22/24] media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver

Hi Steve, Thank you for the patch. Many of the comments below apply to the ov5642 driver too, please take them into account when reworking patch 23/24. On Friday 06 Jan 2017 18:11:40 Steve Longerbeam wrote: > This driver is based on ov5640_mipi.c from Freescale imx_3.10.17_1.0.0_beta > branch,

Re: [PATCH] staging: lustre: shut up clang warnings on CLASSERT()

On Thu, Feb 02, 2017 at 11:40:32AM +0100, Arnd Bergmann wrote: > On Thu, Feb 2, 2017 at 10:54 AM, Greg Kroah-Hartman > wrote: > b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h > >> > index aab15d8112a4..2d5435029185 100644 > >> > ---

Re: [PATCH] staging: lustre: shut up clang warnings on CLASSERT()

On Thu, Feb 2, 2017 at 10:54 AM, Greg Kroah-Hartman wrote: b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h >> > index aab15d8112a4..2d5435029185 100644 >> > --- a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h >> > +++

Re: [PATCH] staging: lustre: shut up clang warnings on CLASSERT()

On Thu, Feb 02, 2017 at 07:50:24AM +, Dilger, Andreas wrote: > On Feb 1, 2017, at 09:52, Arnd Bergmann wrote: > > > > lustre uses a fake switch() statement as a compile-time assert, but > > unfortunately > > each use of that causes a warning when building with clang: > > > >

..Reply

Dear Comrade, I hope that I not offend you. Anyway,i found your email through your country email data base because of how important is it to me, reaching out to some one like for something serious, let me introduce myself. My name is Fatima Rukaya Muhammad, I'm from Tartous Syria and living