Re: [greybus-dev] [PATCH] staging: greybus: light: fix memory leak in v4l2 register

On 02-08-17, 17:52, Rui Miguel Silva wrote: > 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. > > Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") >

[PATCH] staging: rtl8192e: Change fixed function names with "%s: ", __func__

Replace hard-coded function names in strings with "%s", __func__ in the dot11d.c file. Issue found by checkpatch.pl. Signed-off-by: vergilzhang --- drivers/staging/rtl8192e/dot11d.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH net-next v3 0/3] netvsc: transparent VF support

From: Stephen Hemminger Date: Tue, 1 Aug 2017 19:58:52 -0700 > This patch set changes how SR-IOV Virtual Function devices are managed > in the Hyper-V network driver. This version is rebased onto current net-next. ... Series applied, thanks Stephen.

[PATCH] staging: rtl8192e: Change fixed function names with "%s: ", __func__

staging: rtl8192e: Fix coding style issue caught by checkpatch.pl related to function name in debug print Signed-off-by: vergilzhang --- drivers/staging/rtl8192e/dot11d.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH] staging: rtl8192e: Change fixed function names with "%s: ", __func__

On Thu, Aug 03, 2017 at 01:59:56AM +0800, vergilzhang wrote: > staging: rtl8192e: Fix coding style issue caught by checkpatch.pl related to > function name in debug print > > Signed-off-by: vergilzhang > --- > drivers/staging/rtl8192e/dot11d.c | 4 ++-- > 1 file

Re: [PATCH V2] hyperv: netvsc: Neaten netvsc_send_pkt by using a temporary

From: Joe Perches Date: Mon, 31 Jul 2017 10:30:54 -0700 > Repeated dereference of nvmsg.msg.v1_msg.send_rndis_pkt can be > shortened by using a temporary. Do so. > > No change in object code. > > Miscellanea: > > o Use * const for rpkt and nvchan > > Signed-off-by: Joe

[PATCH] staging: greybus: light: fix memory leak in v4l2 register

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. Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Reported-by: Sakari Ailus

[PATCH v10 9/9] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others(). Tracing is done the same way we do xen_mmu_flush_tlb_others(). Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko Reviewed-by: Stephen Hemminger

[PATCH v10 8/9] x86/hyper-v: support extended CPU ranges for TLB flush hypercalls

Hyper-V hosts may support more than 64 vCPUs, we need to use HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX/LIST_EX hypercalls in this case. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko Reviewed-by: Stephen Hemminger

[PATCH v10 7/9] x86/hyper-v: use hypercall for remote TLB flush

Hyper-V host can suggest us to use hypercall for doing remote TLB flush, this is supposed to work faster than IPIs. Implementation details: to do HvFlushVirtualAddress{Space,List} hypercalls we need to put the input somewhere in memory and we don't really want to have memory allocation on each

[PATCH v10 3/9] x86/hyper-v: fast hypercall implementation

Hyper-V supports 'fast' hypercalls when all parameters are passed through registers. Implement an inline version of a simpliest of these calls: hypercall with one 8-byte input and no output. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko

[PATCH v10 4/9] hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT

We need to pass only 8 bytes of input for HvSignalEvent which makes it a perfect fit for fast hypercall. hv_input_signal_event_buffer is not needed any more and hv_input_signal_event is converted to union for convenience. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy

[PATCH v10 6/9] hyper-v: globalize vp_index

To support implementing remote TLB flushing on Hyper-V with a hypercall we need to make vp_index available outside of vmbus module. Rename and globalize. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko Reviewed-by: Stephen Hemminger

[PATCH v10 5/9] x86/hyper-v: implement rep hypercalls

Rep hypercalls are normal hypercalls which perform multiple actions at once. Hyper-V guarantees to return exectution to the caller in not more than 50us and the caller needs to use hypercall continuation. Touch NMI watchdog between hypercall invocations. This is going to be used for

[PATCH v10 2/9] x86/hyper-v: make hv_do_hypercall() inline

We have only three call sites for hv_do_hypercall() and we're going to change HVCALL_SIGNAL_EVENT to doing fast hypercall so we can inline this function for optimization. Hyper-V top level functional specification states that r9-r11 registers and flags may be clobbered by the hypervisor during

[PATCH v10 1/9] x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set

Code is arch/x86/hyperv/ is only needed when CONFIG_HYPERV is set, the 'basic' support and detection lives in arch/x86/kernel/cpu/mshyperv.c which is included when CONFIG_HYPERVISOR_GUEST is set. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko

[PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

Changes since v9: - Rebase to 4.13-rc3. - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no functional dependencies on this patch so the series can go through a different tree (and it actually belongs to x86 if I got Ingo's comment right). - Add in missing void return

Re: [PATCH] staging: vboxvideo: use drm_gem_object_put instead of drm_gem_object_unreference

On Wed, Aug 2, 2017 at 3:47 PM, Cihangir Akturk wrote: > On Wed, Aug 02, 2017 at 02:38:50PM +0200, Daniel Vetter wrote: >> On Wed, Aug 2, 2017 at 1:46 AM, Cihangir Akturk wrote: >> > drm_gem_object_unreference is a compatibility alias for drm_gem_object_put

Re: [PATCH] staging: vboxvideo: use drm_gem_object_put instead of drm_gem_object_unreference

On Wed, Aug 02, 2017 at 02:38:50PM +0200, Daniel Vetter wrote: > On Wed, Aug 2, 2017 at 1:46 AM, Cihangir Akturk wrote: > > drm_gem_object_unreference is a compatibility alias for drm_gem_object_put > > so should > > not be used by new code. > > > > This patch fixes the

[PATCH] Remove explicit return type cast

Remove explicit typecasting of return value in the interrupt handlers. Signed-off-by: Hari Prasath --- drivers/staging/pi433/pi433_if.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/pi433/pi433_if.c

Re: [PATCH] staging: vboxvideo: use drm_gem_object_put instead of drm_gem_object_unreference

On Wed, Aug 2, 2017 at 1:46 AM, Cihangir Akturk wrote: > drm_gem_object_unreference is a compatibility alias for drm_gem_object_put so > should > not be used by new code. > > This patch fixes the following warning reported by coccinelle: > >

[PATCH] staging:wlan-ng Fix multiple line dereference

This patch fixes multiple line dereference Warning reported by checkpatch script. This is done to simplify the code and make it more readable. Signed-off-by: Janani Sankara Babu --- drivers/staging/wlan-ng/hfa384x_usb.c | 12 1 file changed, 4 insertions(+), 8

Re: [PATCH] staging: pi433: remove some macros, introduce some inline functions

On Wed, Aug 02, 2017 at 02:07:37PM +0200, Marcus Wolf wrote: > Hi Dan, > > I get your point and I understand, that there need to be rules to > simplify the life for the maintainers... > > But I honestly must confess, that at the moment, I don't have the > time for doing that. I am into two

Re: [PATCH] staging: pi433: remove some macros, introduce some inline functions

Hi Dan, I get your point and I understand, that there need to be rules to simplify the life for the maintainers... But I honestly must confess, that at the moment, I don't have the time for doing that. I am into two customer projects, that keep me very busy these weeks. The only thing, I can

Re: [PATCH] staging: pi433: remove some macros, introduce some inline functions

On Wed, Aug 02, 2017 at 02:53:30PM +0300, Dan Carpenter wrote: > > +{ > > + u8 tempVal; > Btw, just call this "u8 tmp;". The word "temp" is short for temperature and "val" doesn't add any information because it's clearly a value. regards, dan carpenter

Re: [PATCH] staging: pi433: remove some macros, introduce some inline functions

I'm afraid this patch is going to need to be divided into several patches that do one thing per patch. And I totally get that redoing patches sucks... Sorry. On Wed, Aug 02, 2017 at 01:10:14PM +0200, Wolf Entwicklungen wrote: > According to the proposal of Walter Harms, I removed some macros >

[PATCH] staging: pi433: remove some macros, introduce some inline functions

From: Marcus Wolf According to the proposal of Walter Harms, I removed some macros and added some inline functions. Since I used a bit more intelligent interface, this enhances readability and reduces problems with checkpatch.pl at the same time. In addition

Re: [PATCH] staging: pi433: remove some macros, introduce some inline functions

Hi Dan, as discussed last week, here you can find my patch, touching nearly every function in rf69.c I tried my best to have a correct style of the patch. As far, as I figured out, the patch does not fully apply on staging-next, since there are two bugfixes missing, that were reported before

[PATCH] staging: pi433: remove some macros, introduce some inline functions

According to the proposal of Walter Harms, I removed some macros and added some inline functions. Since I used a bit more intelligent interface, this enhances readability and reduces problems with checkpatch.pl at the same time. In addition obsolete debug ifdefs were removed. Signed-off-by:

Re: [PATCH 1/5] staging/pi433:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

On Wed, Aug 02, 2017 at 03:45:12PM +0530, rishabh hardas wrote: > Hi, > > Sorry for the mistakes, just started out with Linux kernel. No worries. We all started as newbies. > I will redo all the things again and split them logically and send > them back. > > Should I send it on this thread or

Re: [PATCH 1/5] staging/pi433:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

On Wed, Aug 02, 2017 at 11:15:16AM +0200, Wolf Entwicklungen wrote: > Hi Dan, > > I offered Greg to have an eye on the patches, that were submitted. He asked > me to reply to those patches, I had a look for, with the Reviewed-by tag. > > Now I am a bit unsure, what I should do. > > Since I am

Re: [PATCH 1/5] staging/pi433:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

Hi Dan, I offered Greg to have an eye on the patches, that were submitted. He asked me to reply to those patches, I had a look for, with the Reviewed-by tag. Now I am a bit unsure, what I should do. Since I am interested in, I for sure will read every patch. It's just a little thing, to reply

Re: [PATCH 1/5] staging/pi433:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

I seldom Ack patches or add Reviewed-by tags. Greg is going to compile test them all so that buys you a little slack but if you were committing patches yourself and you broke the build everyone would get annoyed with you. Just put a comment if you can't build test things. regards, dan carpenter

Re: [PATCH] staging: lustre: grab the cld->cld_lock mutex unconditionally

I guess that does look a bit simpler. Reviewed-by: Dan Carpenter regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/5] staging/pi433:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

Hi! Ok. Didn't know that I have to check for such stuff. So far i was just checking the code changes, not the style of the patch itself. Will try to be more strict... Is it mandatory, that I compile the code, or is it ok, if I do the review "just" by reading? Reason for the question: If

Re: [PATCH 1/5] staging/pi433:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

On Wed, Aug 02, 2017 at 10:08:04AM +0200, Wolf Entwicklungen wrote: > Reviewed-by: Marcus Wolf > > Just reviewed, not tested. > As far as I can see, there is no technical issue with this patch. You need to be a bit more strict in your reviews... There were a few

Re: [PATCH 2/5] staging/pi433/pi433_if.c:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

The subject is too vague. The patch prefix isn't right. Do `git log --oneline drivers/staging/pi433/` to see what other people are doing: 99859541a92d staging: pi433: use div_u64 for 64-bit division 056eeda2f9e6 staging: pi433: Style fix - align block comments 775f6ab013d3 staging: pi433: Make

Re: [PATCH 1/5] staging/pi433:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

This patch is going to break the build. Every patch has to be able to be compiled so we can use git bisect. You'll need to redo the whole series. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org

Re: [PATCH] staging: pi433: reduce stack size in tx thread

Reviewed-by: Marcus Wolf Maybe tx_buffer is a bit more clearly then buffer. Thanks, Marcus Am Mo, 31.07.2017, 10:57 schrieb Arnd Bergmann: > Putting a 900 byte array on the stack is a clearly too much in the > kernel, and sometimes results in warnings like: > >

Re: [PATCH 1/5] staging/pi433:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

The subject is too long. On Wed, Aug 02, 2017 at 01:01:55AM +0530, Rishabh Hardas wrote: > This is a 5 patch series which solves coding style issues > as marked by checkpatch.pl in the file pi433_if.h and > contains changes that have to be made in other files as a > consequence of the changes

[PATCH] staging: fsl-mc: fix resource_size.cocci warnings

Use resource_size() function on resource objects instead of explicit computation. This patch fixes the following coccinelle warning: drivers/staging/fsl-mc/bus/dprc-driver.c:620:35-38: ERROR: Missing resource_size with mc_dev -> regions Signed-off-by: Cihangir Akturk ---

Re: [PATCH] media: staging: atomisp: sh_css_calloc shall return a pointer to the allocated space

On Wed, 2017-08-02 at 18:00 +1000, Sergei A. Trusov wrote: > The calloc function returns either a null pointer or a pointer to the > allocated space. Add the second case that is missed. gads. Bug added by commit da22013f7df4 ("atomisp: remove indirection from sh_css_malloc") These wrappers

Re: [PATCH] staging/pi433: Solved some coding style issues in pi433_if.c

Reviewed-by: Marcus Wolf Thank you :-) Am Di, 1.08.2017, 07:09 schrieb Rishabh Hardas: > From: Rishabh Hardas > > Solved a few coding style issues, used BIT macro to set MINORBITS. > > Signed-off-by: Rishabh Hardas

Re: [PATCH 5/5] staging/pi433/rf69_enum.h:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

Reviewed-by: Marcus Wolf Am Di, 1.08.2017, 21:31 schrieb Rishabh Hardas: > Signed-off-by: Rishabh Hardas > --- > drivers/staging/pi433/rf69_enum.h | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git

Re: [PATCH 4/5] staging/pi433/rf69.c:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

Reviewed-by: Marcus Wolf Maybe lnaGain should move to lna_gain instead of lnagain (also applies to the headers...) Marcus Am Di, 1.08.2017, 21:31 schrieb Rishabh Hardas: > Signed-off-by: Rishabh Hardas > --- >

Re: [PATCH 3/5] staging/pi433/rf69.h:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

Reviewed-by: Marcus Wolf Am Di, 1.08.2017, 21:31 schrieb Rishabh Hardas: > Signed-off-by: Rishabh Hardas > --- > drivers/staging/pi433/rf69.h | 26 +- > 1 file changed, 13 insertions(+), 13 deletions(-) > > diff

Re: [PATCH 2/5] staging/pi433/pi433_if.c:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

Reviewed-by: Marcus Wolf Am Di, 1.08.2017, 21:31 schrieb Rishabh Hardas: > Signed-off-by: Rishabh Hardas > --- > drivers/staging/pi433/pi433_if.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

[PATCH] media: staging: atomisp: sh_css_calloc shall return a pointer to the allocated space

The calloc function returns either a null pointer or a pointer to the allocated space. Add the second case that is missed. Signed-off-by: Sergei A. Trusov --- drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH 1/5] staging/pi433:Removed Coding style issues from pi433_if.h and other dependencies arising from it.

Reviewed-by: Marcus Wolf Just reviewed, not tested. As far as I can see, there is no technical issue with this patch. I prefer the names of the enumerations in camel case, because then they are a bit shorter. If camel case is unwanted, for sure we need that change.