Re: [PATCH] USB: serial: ftdi_sio: add IDs for Xsens Mti USB converter

Hi Patrick, On Wed, Aug 5, 2020 at 9:57 PM Patrick Riphagen wrote: > > The device added has an FTDI chip inside. > The device is used to connect Xsens USB Motion Trackers. > > Signed-off-by: Patrick Riphagen Now you've dropped the backport to stable. Just put Cc: sta...@vger.kernel.org just

Re: [PATCH v2] [media] lirc_zilog: Clean up lirc zilog error codes

Almost there on the subject. Stuff between brackets is removed by git, so you should rather use something like [PATCH v2] staging: lirc: Clean up zilog error codes On Wed, Jul 12, 2017 at 9:17 PM, Yves Lemée wrote: > According the coding style guidelines, the ENOSYS

Re: [PATCH v2] [media] lirc_zilog: Clean up lirc zilog error codes

Almost there on the subject. Stuff between brackets is removed by git, so you should rather use something like [PATCH v2] staging: lirc: Clean up zilog error codes On Wed, Jul 12, 2017 at 9:17 PM, Yves Lemée wrote: > According the coding style guidelines, the ENOSYS error code must be returned

Re: [PATCH] staging: ks7010: fix styling WARNINGs

On Fri, Jun 30, 2017 at 8:39 PM, Mark Rogers wrote: > Thank you for your feedback. I guess when making this patch I had the > preferred coding style in mind, but didn't ask myself if making the code > conform to it would truly improve readability. > > I agree with all of

Re: [PATCH] staging: ks7010: fix styling WARNINGs

On Fri, Jun 30, 2017 at 8:39 PM, Mark Rogers wrote: > Thank you for your feedback. I guess when making this patch I had the > preferred coding style in mind, but didn't ask myself if making the code > conform to it would truly improve readability. > > I agree with all of your comments. Do you

Re: [PATCH] Clean up lirc zilog error codes

On Tue, Jul 11, 2017 at 7:57 PM, Yves Lemée wrote: > According the coding style guidelines, the ENOSYS error code must be returned > in case of a non existent system call. This code has been replaced with > the ENOTTY error code indicating, a missing functionality. >

Re: [PATCH] Clean up lirc zilog error codes

On Tue, Jul 11, 2017 at 7:57 PM, Yves Lemée wrote: > According the coding style guidelines, the ENOSYS error code must be returned > in case of a non existent system call. This code has been replaced with > the ENOTTY error code indicating, a missing functionality. > > Signed-off-by: Yves Lemée

Re: [PATCH v2 2/2] Staging: android/ion: fix sparse warning

Hi, Again, your subject is too generic. On Wed, Jul 12, 2017 at 6:51 AM, Joseph Wright wrote: > Declare private function static to fix sparse warning: > > ion_cma_heap.c:109:5: warning: symbol '__ion_add_cma_heaps' \ > was not declared. Should it be static? > >

Re: [PATCH v2 2/2] Staging: android/ion: fix sparse warning

Hi, Again, your subject is too generic. On Wed, Jul 12, 2017 at 6:51 AM, Joseph Wright wrote: > Declare private function static to fix sparse warning: > > ion_cma_heap.c:109:5: warning: symbol '__ion_add_cma_heaps' \ > was not declared. Should it be static? > > Signed-off-by: Joseph

Re: [PATCH v2 1/2] Staging: android/ion: fix sparse warnings

Hi, please consider changing your subject to something like staging: android/ion: declare two functions Perhaps you can make it more on-topic. It's more useful than "fix sparse warning" On Wed, Jul 12, 2017 at 6:51 AM, Joseph Wright wrote: > Declare functions to fix

Re: [PATCH v2 1/2] Staging: android/ion: fix sparse warnings

Hi, please consider changing your subject to something like staging: android/ion: declare two functions Perhaps you can make it more on-topic. It's more useful than "fix sparse warning" On Wed, Jul 12, 2017 at 6:51 AM, Joseph Wright wrote: > Declare functions to fix sparse warnings: > >

Re: [PATCH] Staging:ks7010:ks_wlan_net.c: unneeded type casting removed

On Mon, Jul 10, 2017 at 9:09 AM, AndyS wrote: > Subject: [PATCH] Staging:ks7010:ks_wlan_net.c: unneeded type casting removed [PATCH] staging: ks7010: remove unneeded type casting > removed undesired type casting. Warning was raised by checkpatch.pl > This patch is for eudyptula

Re: [PATCH] Staging:ks7010:ks_wlan_net.c: unneeded type casting removed

On Mon, Jul 10, 2017 at 9:09 AM, AndyS wrote: > Subject: [PATCH] Staging:ks7010:ks_wlan_net.c: unneeded type casting removed [PATCH] staging: ks7010: remove unneeded type casting > removed undesired type casting. Warning was raised by checkpatch.pl > This patch is for eudyptula challenge > >

Re: [greybus-dev] [PATCH v2] staging: greybus: arche: wrap over-length lines

On Mon, Jul 10, 2017 at 6:46 AM, Viresh Kumar wrote: > Hi Mitchell, > > On 09-07-17, 20:25, Mitchell Tasman wrote: >> Adjust formatting of various statements to keep line length within >> the 80 column limit preferred by the Linux kernel coding style. > > We try to follow

Re: [greybus-dev] [PATCH v2] staging: greybus: arche: wrap over-length lines

On Mon, Jul 10, 2017 at 6:46 AM, Viresh Kumar wrote: > Hi Mitchell, > > On 09-07-17, 20:25, Mitchell Tasman wrote: >> Adjust formatting of various statements to keep line length within >> the 80 column limit preferred by the Linux kernel coding style. > > We try to follow that most of the time,

Re: [PATCH 2/2] Staging: dgnc: I have fixed the changes in dgnc_neo.c This is a patch to the dgnc_neo.c warning udealy to usleep range Signed-off-by: Yash Omer <yashomer0...@gmail.com>

Hi, On Thu, Jul 6, 2017 at 3:49 AM, yash007 wrote: > From: Yash Omer Instead of resending the same thing every time, could you instead fix your commit message and send a v2? Also, where's patch 1 of 2? > > --- > drivers/staging/dgnc/dgnc_neo.c | 10

Re: [PATCH 2/2] Staging: dgnc: I have fixed the changes in dgnc_neo.c This is a patch to the dgnc_neo.c warning udealy to usleep range Signed-off-by: Yash Omer

Hi, On Thu, Jul 6, 2017 at 3:49 AM, yash007 wrote: > From: Yash Omer Instead of resending the same thing every time, could you instead fix your commit message and send a v2? Also, where's patch 1 of 2? > > --- > drivers/staging/dgnc/dgnc_neo.c | 10 +- > 1 file changed, 5

Re: [PATCH 8/8] Staging: lustre :lustre: include :lustre_compat.h: Prefer using the BIT macro

On Thu, Jul 6, 2017 at 9:13 AM, Jaya Durga wrote: > Subject: Staging: lustre :lustre: include :lustre_compat.h: Prefer using the > BIT macro Don't overdo it ;-). Subject: staging: lustre: lustre_compat.h: Prefer using the BIT macro > Replace all instances of (1 << 27) with

Re: [PATCH 8/8] Staging: lustre :lustre: include :lustre_compat.h: Prefer using the BIT macro

On Thu, Jul 6, 2017 at 9:13 AM, Jaya Durga wrote: > Subject: Staging: lustre :lustre: include :lustre_compat.h: Prefer using the > BIT macro Don't overdo it ;-). Subject: staging: lustre: lustre_compat.h: Prefer using the BIT macro > Replace all instances of (1 << 27) with BIT(27) to fix >

Re: [PATCH 2/2] Staging: dgnc: I have fixed the changes in dgnc_neo.c This is a patch to the dgnc_neo.c warning udealy to usleep range Signed-off-by: Yash Omer <yashomer0...@gmail.com>

On Thu, Jul 6, 2017 at 3:22 AM, yash007 wrote: > From: Yash Omer Your commit message is completely broken. Please fix it. See Documentation/process/submitting-patches.rst chapter 14. > > --- > drivers/staging/dgnc/dgnc_neo.c | 10 +- > 1 file

Re: [PATCH 2/2] Staging: dgnc: I have fixed the changes in dgnc_neo.c This is a patch to the dgnc_neo.c warning udealy to usleep range Signed-off-by: Yash Omer

On Thu, Jul 6, 2017 at 3:22 AM, yash007 wrote: > From: Yash Omer Your commit message is completely broken. Please fix it. See Documentation/process/submitting-patches.rst chapter 14. > > --- > drivers/staging/dgnc/dgnc_neo.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) >

Re: [tip:sched/core] sched/cputime: Refactor the cputime_adjust() code

On Fri, Jun 30, 2017 at 4:00 PM, Rik van Riel wrote: > On Fri, 2017-06-30 at 06:10 -0700, tip-bot for Gustavo A. R. Silva > wrote: > >> +++ b/kernel/sched/cputime.c >> @@ -615,19 +615,13 @@ static void cputime_adjust(struct task_cputime >> *curr, >>* userspace. Once a

Re: [tip:sched/core] sched/cputime: Refactor the cputime_adjust() code

On Fri, Jun 30, 2017 at 4:00 PM, Rik van Riel wrote: > On Fri, 2017-06-30 at 06:10 -0700, tip-bot for Gustavo A. R. Silva > wrote: > >> +++ b/kernel/sched/cputime.c >> @@ -615,19 +615,13 @@ static void cputime_adjust(struct task_cputime >> *curr, >>* userspace. Once a task gets some

Re: [PATCH] staging: ks7010: fix styling WARNINGs

On Fri, Jun 30, 2017 at 6:52 AM, Mark Rogers wrote: > Trivial style changes. There are still 3 "line over 80 characters" > checkpatch.pl warnings, but I think they are best left alone as > breaking the first two warning lines could hurt readability. The third > warning is a

Re: [PATCH] staging: ks7010: fix styling WARNINGs

On Fri, Jun 30, 2017 at 6:52 AM, Mark Rogers wrote: > Trivial style changes. There are still 3 "line over 80 characters" > checkpatch.pl warnings, but I think they are best left alone as > breaking the first two warning lines could hurt readability. The third > warning is a message that should

Re: [PATCH] clocksource: em_sti: fix error return codes in em_sti_probe()

On Fri, Jun 30, 2017 at 6:42 AM, Gustavo A. R. Silva wrote: > Propagate the return values of platform_get_irq and > devm_request_irq on failure. > > Signed-off-by: Gustavo A. R. Silva > --- > drivers/clocksource/em_sti.c | 9 + > 1 file

Re: [PATCH] clocksource: em_sti: fix error return codes in em_sti_probe()

On Fri, Jun 30, 2017 at 6:42 AM, Gustavo A. R. Silva wrote: > Propagate the return values of platform_get_irq and > devm_request_irq on failure. > > Signed-off-by: Gustavo A. R. Silva > --- > drivers/clocksource/em_sti.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff

Re: [PATCH 3/6] staging: iio: tsl2x7x: remove tsl2x7x_i2c_read()

On Thu, Jun 29, 2017 at 7:03 PM, Brian Masney wrote: > tsl2x7x_i2c_read() would call i2c_smbus_write_byte() and > i2c_smbus_read_byte(). These two i2c functions can be replaced with a > single call to i2c_smbus_read_byte_data(). This patch removes the > tsl2x7x_i2c_read()

Re: [PATCH 3/6] staging: iio: tsl2x7x: remove tsl2x7x_i2c_read()

On Thu, Jun 29, 2017 at 7:03 PM, Brian Masney wrote: > tsl2x7x_i2c_read() would call i2c_smbus_write_byte() and > i2c_smbus_read_byte(). These two i2c functions can be replaced with a > single call to i2c_smbus_read_byte_data(). This patch removes the > tsl2x7x_i2c_read() function and replaces

Re: [PATCH 14/14] staging: ccree: fix block comment style

On Tue, Jun 27, 2017 at 9:27 AM, Gilad Ben-Yossef wrote: > Align block comments according to coding style. > > Signed-off-by: Gilad Ben-Yossef > --- > drivers/staging/ccree/cc_hw_queue_defs.h | 8 > 1 file changed, 4 insertions(+), 4

Re: [PATCH 14/14] staging: ccree: fix block comment style

On Tue, Jun 27, 2017 at 9:27 AM, Gilad Ben-Yossef wrote: > Align block comments according to coding style. > > Signed-off-by: Gilad Ben-Yossef > --- > drivers/staging/ccree/cc_hw_queue_defs.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git

Re: [PATCH 6/6] Staging: wlan-ng: hfa384x.h:Fix use of volatile is usually wrong

On Thu, Jun 29, 2017 at 12:25 PM, Jaya Durga wrote: > Fix checkpatch.pl issue > WARNING: Use of volatile is usually wrong: > see Documentation/process/volatile-considered-harmful.rst Now I've only had a very quick look at the code using this. Could you elaborate on why just

Re: [PATCH 6/6] Staging: wlan-ng: hfa384x.h:Fix use of volatile is usually wrong

On Thu, Jun 29, 2017 at 12:25 PM, Jaya Durga wrote: > Fix checkpatch.pl issue > WARNING: Use of volatile is usually wrong: > see Documentation/process/volatile-considered-harmful.rst Now I've only had a very quick look at the code using this. Could you elaborate on why just removing the volatile

Re: [PATCH] hwmon: Add LTC2471/LTC2473 driver

On Thu, Jun 29, 2017 at 1:30 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote: > On 29-06-17 13:18, Frans Klaver wrote: >> >> On Thu, Jun 29, 2017 at 12:45 PM, Mike Looijmans >> <mike.looijm...@topic.nl> wrote: >>> >>> The LTC2741 and LTC24

Re: [PATCH] hwmon: Add LTC2471/LTC2473 driver

On Thu, Jun 29, 2017 at 1:30 PM, Mike Looijmans wrote: > On 29-06-17 13:18, Frans Klaver wrote: >> >> On Thu, Jun 29, 2017 at 12:45 PM, Mike Looijmans >> wrote: >>> >>> The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473 >>>

Re: [PATCH] hwmon: Add LTC2471/LTC2473 driver

On Thu, Jun 29, 2017 at 12:45 PM, Mike Looijmans wrote: > The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473 > is similar to the LTC2471 but outputs a signed differential value. > > Datasheet: > http://cds.linear.com/docs/en/datasheet/24713fb.pdf >

Re: [PATCH] hwmon: Add LTC2471/LTC2473 driver

On Thu, Jun 29, 2017 at 12:45 PM, Mike Looijmans wrote: > The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473 > is similar to the LTC2471 but outputs a signed differential value. > > Datasheet: > http://cds.linear.com/docs/en/datasheet/24713fb.pdf > > Signed-off-by: Mike

Re: [kernel-sched-cputime] question about probable bug in cputime_adjust()

On 29 June 2017 01:57:19 CEST, "Gustavo A. R. Silva" wrote: --- a/kernel/sched/cputime.c +++ b/kernel/sched/cputime.c @@ -637,9 +637,10 @@ static void cputime_adjust(struct task_cputime >*curr, *= (rtime_i+1 - rtime_i) + utime_i

Re: [kernel-sched-cputime] question about probable bug in cputime_adjust()

On 29 June 2017 01:57:19 CEST, "Gustavo A. R. Silva" wrote: --- a/kernel/sched/cputime.c +++ b/kernel/sched/cputime.c @@ -637,9 +637,10 @@ static void cputime_adjust(struct task_cputime >*curr, *= (rtime_i+1 - rtime_i) + utime_i *

Re: [PATCH] scsi: hisi_sas: optimise DMA slot memory

On Wed, Jun 28, 2017 at 5:25 PM, John Garry wrote: > From: Xiaofei Tan > > Currently we allocate 3 sets of DMA memories from separate > pools for each slot. This is inefficient in terms of memory usage > (buffers are less than 1 page in size, so we

Re: [PATCH] scsi: hisi_sas: optimise DMA slot memory

On Wed, Jun 28, 2017 at 5:25 PM, John Garry wrote: > From: Xiaofei Tan > > Currently we allocate 3 sets of DMA memories from separate > pools for each slot. This is inefficient in terms of memory usage > (buffers are less than 1 page in size, so we lose due to alignment), > and also time spend

Re: [PATCH] staging: rts5208 : Fixing coding style warnings

Hi, On Wed, Jun 28, 2017 at 2:50 PM, Simo Koskinen wrote: > Fixed following warnings found by checkpatch.pl script: > > WARNING: Prefer using '"%s...", __func__' to using '', > this function's name, in a string > > Signed-off-by: Simo Koskinen > ---

Re: [PATCH] staging: rts5208 : Fixing coding style warnings

Hi, On Wed, Jun 28, 2017 at 2:50 PM, Simo Koskinen wrote: > Fixed following warnings found by checkpatch.pl script: > > WARNING: Prefer using '"%s...", __func__' to using '', > this function's name, in a string > > Signed-off-by: Simo Koskinen > --- > drivers/staging/rts5208/rtsx.c |

Re: [PATCH] Staging: unisys: visorbus: Fix coding style warning from checkpatch.pl.

Hi, On Wed, Jun 28, 2017 at 4:49 AM, Quytelda Kahja wrote: > Replace the literal function name "visorbus_create_instance" with the format > specifier "%s" so it can be dynamically filled by the __func__ macro. On a general note, I think the actual change or effect is more

Re: [PATCH] Staging: unisys: visorbus: Fix coding style warning from checkpatch.pl.

Hi, On Wed, Jun 28, 2017 at 4:49 AM, Quytelda Kahja wrote: > Replace the literal function name "visorbus_create_instance" with the format > specifier "%s" so it can be dynamically filled by the __func__ macro. On a general note, I think the actual change or effect is more import to mention in

Re: [kernel-sched-cputime] question about probable bug in cputime_adjust()

On Wed, Jun 28, 2017 at 7:35 AM, Frans Klaver <franskla...@gmail.com> wrote: > On Wed, Jun 28, 2017 at 1:03 AM, Gustavo A. R. Silva > <garsi...@embeddedor.com> wrote: >> >> Hello everybody, >> >> While looking into Coverity ID 1371643 I ran into the

Re: [kernel-sched-cputime] question about probable bug in cputime_adjust()

On Wed, Jun 28, 2017 at 7:35 AM, Frans Klaver wrote: > On Wed, Jun 28, 2017 at 1:03 AM, Gustavo A. R. Silva > wrote: >> >> Hello everybody, >> >> While looking into Coverity ID 1371643 I ran into the following piece of >> code at kernel/sched/cputime.c:568: &g

Re: [kernel-sched-cputime] question about probable bug in cputime_adjust()

On Wed, Jun 28, 2017 at 1:03 AM, Gustavo A. R. Silva wrote: > > Hello everybody, > > While looking into Coverity ID 1371643 I ran into the following piece of > code at kernel/sched/cputime.c:568: > > 568/* > 569 * Adjust tick based cputime random precision against

Re: [kernel-sched-cputime] question about probable bug in cputime_adjust()

On Wed, Jun 28, 2017 at 1:03 AM, Gustavo A. R. Silva wrote: > > Hello everybody, > > While looking into Coverity ID 1371643 I ran into the following piece of > code at kernel/sched/cputime.c:568: > > 568/* > 569 * Adjust tick based cputime random precision against scheduler runtime > 570 *

Re: [PATCH V3] lightnvm: if LUNs are already allocated fix return

> Fixes: ade69e243 ("lightnvm: merge gennvm with core") > Signed-off-by: Rakesh Pandit <rak...@tuxera.com> Reviewed-by: Frans Klaver <franskla...@gmail.com> > --- > > V3: Propagate return value from nvm_reserve_luns instead of hard-coding > (Frans) >

Re: [PATCH V3] lightnvm: if LUNs are already allocated fix return

quot;lightnvm: merge gennvm with core") > Signed-off-by: Rakesh Pandit Reviewed-by: Frans Klaver > --- > > V3: Propagate return value from nvm_reserve_luns instead of hard-coding > (Frans) > V2: return error code directly instead of using ret variable (Frans) > > dr

Re: [PATCH V2] lightnvm: if LUNs are already allocated fix return

On Tue, Jun 27, 2017 at 1:23 PM, Rakesh Pandit <rak...@tuxera.com> wrote: > On Tue, Jun 27, 2017 at 01:01:22PM +0200, Frans Klaver wrote: >> On Tue, Jun 27, 2017 at 12:43 PM, Rakesh Pandit <rak...@tuxera.com> wrote: >> > While creating new device with NVM_

Re: [PATCH V2] lightnvm: if LUNs are already allocated fix return

On Tue, Jun 27, 2017 at 1:23 PM, Rakesh Pandit wrote: > On Tue, Jun 27, 2017 at 01:01:22PM +0200, Frans Klaver wrote: >> On Tue, Jun 27, 2017 at 12:43 PM, Rakesh Pandit wrote: >> > While creating new device with NVM_DEV_CREATE if LUNs are already >> > allocated ioctl

Re: [PATCH V2] lightnvm: if LUNs are already allocated fix return

On Tue, Jun 27, 2017 at 12:43 PM, Rakesh Pandit wrote: > While creating new device with NVM_DEV_CREATE if LUNs are already > allocated ioctl would return -ENOMEM which is wrong. This patch > propagates -EBUSY from nvm_reserve_luns which is correct response. > > Fixes:

Re: [PATCH V2] lightnvm: if LUNs are already allocated fix return

On Tue, Jun 27, 2017 at 12:43 PM, Rakesh Pandit wrote: > While creating new device with NVM_DEV_CREATE if LUNs are already > allocated ioctl would return -ENOMEM which is wrong. This patch > propagates -EBUSY from nvm_reserve_luns which is correct response. > > Fixes: ade69e243 ("lightnvm: merge

Re: [PATCH 4/4] Staging: rtl8712 : osdep_intf.h: fix macro coding style issue

On Tue, Jun 27, 2017 at 9:48 AM, Jaya Durga wrote: > Fix checkpatch.pl warning of the form "CHECK" Macro argument 'x' > may be better as '(x)' to avoid precedence issues. > > Signed-off-by: Jaya Durga > --- > drivers/staging/rtl8712/osdep_intf.h | 5 - > 1

Re: [PATCH 4/4] Staging: rtl8712 : osdep_intf.h: fix macro coding style issue

On Tue, Jun 27, 2017 at 9:48 AM, Jaya Durga wrote: > Fix checkpatch.pl warning of the form "CHECK" Macro argument 'x' > may be better as '(x)' to avoid precedence issues. > > Signed-off-by: Jaya Durga > --- > drivers/staging/rtl8712/osdep_intf.h | 5 - > 1 file changed, 4 insertions(+), 1

Re: [PATCH] ligtnvm: if LUNs are already allocated fix return

On Tue, Jun 27, 2017 at 10:39 AM, Matias Bjørling wrote: > From: Rakesh Pandit > > While creating new device with NVM_DEV_CREATE if LUNs are already > allocated ioctl would return -ENOMEM which is wrong. This patch > propagates -EBUSY from nvm_reserve_luns

Re: [PATCH] ligtnvm: if LUNs are already allocated fix return

On Tue, Jun 27, 2017 at 10:39 AM, Matias Bjørling wrote: > From: Rakesh Pandit > > While creating new device with NVM_DEV_CREATE if LUNs are already > allocated ioctl would return -ENOMEM which is wrong. This patch > propagates -EBUSY from nvm_reserve_luns which is correct response. > > Fixes:

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

On Fri, Jun 23, 2017 at 07:37:28PM -0400, Julia Lawall wrote: > > > On Sat, 24 Jun 2017, Frans Klaver wrote: > > > Hm. For some reason the great mail filtering scheme decided to push > > this past my inbox :-/ > > > > On Sat, Jun 17, 2017 at 12:44 AM,

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

On Fri, Jun 23, 2017 at 07:37:28PM -0400, Julia Lawall wrote: > > > On Sat, 24 Jun 2017, Frans Klaver wrote: > > > Hm. For some reason the great mail filtering scheme decided to push > > this past my inbox :-/ > > > > On Sat, Jun 17, 2017 at 12:44 AM, Joe P

Re: [PATCH v4] crypto: sun4i-ss: support the Security System PRNG

Hi, On Mon, Jun 26, 2017 at 2:20 PM, Corentin Labbe wrote: > The Security System have a PRNG, this patch add support for it via > crypto_rng. s,have,has, s,add,adds, > > Signed-off-by: Corentin Labbe > --- > > Changes since v3 (note: the

Re: [PATCH v4] crypto: sun4i-ss: support the Security System PRNG

Hi, On Mon, Jun 26, 2017 at 2:20 PM, Corentin Labbe wrote: > The Security System have a PRNG, this patch add support for it via > crypto_rng. s,have,has, s,add,adds, > > Signed-off-by: Corentin Labbe > --- > > Changes since v3 (note: the v3 miss changes and version tag sorry) > - Replaced all

Re: [PATCH] Staging : rts5208 : checkpatch.pl fixes

On Mon, Jun 26, 2017 at 11:12 AM, Simo Koskinen wrote: > On Fri, Jun 23, 2017 at 5:59 PM, Joe Perches wrote: >> On Fri, 2017-06-23 at 15:55 +0200, Simo Koskinen wrote: >>> Fixed some issues reported by checkpatch.pl script. >> [] >>> diff --git

Re: [PATCH] Staging : rts5208 : checkpatch.pl fixes

On Mon, Jun 26, 2017 at 11:12 AM, Simo Koskinen wrote: > On Fri, Jun 23, 2017 at 5:59 PM, Joe Perches wrote: >> On Fri, 2017-06-23 at 15:55 +0200, Simo Koskinen wrote: >>> Fixed some issues reported by checkpatch.pl script. >> [] >>> diff --git a/drivers/staging/rts5208/rtsx.c

Re: [PATCH] staging: sm750fb: always take the lock

On Mon, Jun 26, 2017 at 11:11 AM, Geert Uytterhoeven wrote: > On Mon, Jun 26, 2017 at 7:45 AM, AbdAllah-MEZITI > wrote: >> This patch >> - will always take the lock > > Why? > > "The current code only takes the lock if multiple instances are

Re: [PATCH] staging: sm750fb: always take the lock

On Mon, Jun 26, 2017 at 11:11 AM, Geert Uytterhoeven wrote: > On Mon, Jun 26, 2017 at 7:45 AM, AbdAllah-MEZITI > wrote: >> This patch >> - will always take the lock > > Why? > > "The current code only takes the lock if multiple instances are in use. > This is error-prone, and confuses static

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

On Sat, Jun 24, 2017 at 1:37 AM, Julia Lawall <julia.law...@lip6.fr> wrote: > > > On Sat, 24 Jun 2017, Frans Klaver wrote: > >> Hm. For some reason the great mail filtering scheme decided to push >> this past my inbox :-/ >> >> On Sat, Jun 17, 2017 at 12:4

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

On Sat, Jun 24, 2017 at 1:37 AM, Julia Lawall wrote: > > > On Sat, 24 Jun 2017, Frans Klaver wrote: > >> Hm. For some reason the great mail filtering scheme decided to push >> this past my inbox :-/ >> >> On Sat, Jun 17, 2017 at 12:44 AM, Joe Perches wrote: &g

Re: [PATCH] staging: sm750fb: always take the lock

There's no version number. Which one is the correct one? On Mon, Jun 26, 2017 at 7:45 AM, AbdAllah-MEZITI wrote: > This patch > - will always take the lock > - fix the sparse warning: > drivers/staging/sm750fb/sm750.c:159:13: warning: context imbalance in >

Re: [PATCH] staging: sm750fb: always take the lock

There's no version number. Which one is the correct one? On Mon, Jun 26, 2017 at 7:45 AM, AbdAllah-MEZITI wrote: > This patch > - will always take the lock > - fix the sparse warning: > drivers/staging/sm750fb/sm750.c:159:13: warning: context imbalance in > 'lynxfb_ops_fillrect' - different

Re: [PATCH] staging: sm750fb: always take the lock

On Sun, Jun 25, 2017 at 11:39 PM, AbdAllah-MEZITI wrote: > Subject: [PATCH] staging: sm750fb: always take the lock When sending a new version of your patch, include a version number: Subject: [PATCH V2] staging: ... Frans

Re: [PATCH] staging: sm750fb: always take the lock

On Sun, Jun 25, 2017 at 11:39 PM, AbdAllah-MEZITI wrote: > Subject: [PATCH] staging: sm750fb: always take the lock When sending a new version of your patch, include a version number: Subject: [PATCH V2] staging: ... Frans

Re: [PATCH] staging: sm750fb: fix sparce warning.

On 25 June 2017 21:10:36 CEST, AbdAllah-MEZITI wrote: >This patch fixes the following sparce warnings: different lock contexts >for basic block. > >drivers/staging/sm750fb//sm750.c:159:13: warning: context imbalance in >'lynxfb_ops_fillrect' - different lock

Re: [PATCH] staging: sm750fb: fix sparce warning.

On 25 June 2017 21:10:36 CEST, AbdAllah-MEZITI wrote: >This patch fixes the following sparce warnings: different lock contexts >for basic block. > >drivers/staging/sm750fb//sm750.c:159:13: warning: context imbalance in >'lynxfb_ops_fillrect' - different lock contexts for basic block

Re: [PATCH] Staging: wlan-ng: hfa384x_usb: Fixed sparse warning cast to restricted __le16

On Fri, Jun 16, 2017 at 12:05 PM, Jaya Durga wrote: > when building with make C=1 CF=-D__CHECK_ENDIAN__ > > drivers/staging/wlan-ng/hfa384x_usb.c:3383:36: warning: cast to restricted > __le16 > > fixed by using the le16_to_cpus function. > > Signed-off-by: Jaya Durga

Re: [PATCH] Staging: wlan-ng: hfa384x_usb: Fixed sparse warning cast to restricted __le16

On Fri, Jun 16, 2017 at 12:05 PM, Jaya Durga wrote: > when building with make C=1 CF=-D__CHECK_ENDIAN__ > > drivers/staging/wlan-ng/hfa384x_usb.c:3383:36: warning: cast to restricted > __le16 > > fixed by using the le16_to_cpus function. > > Signed-off-by: Jaya Durga > --- >

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

Hm. For some reason the great mail filtering scheme decided to push this past my inbox :-/ On Sat, Jun 17, 2017 at 12:44 AM, Joe Perches <j...@perches.com> wrote: > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote: >> The header field in struct pd_message is declared as

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

Hm. For some reason the great mail filtering scheme decided to push this past my inbox :-/ On Sat, Jun 17, 2017 at 12:44 AM, Joe Perches wrote: > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote: >> The header field in struct pd_message is declared as an __le16 type. Th

[PATCH] staging: fusb302: don't bitshift __le16 type

don't get fishy results on big endian systems anymore. Signed-off-by: Frans Klaver <franskla...@gmail.com> --- drivers/staging/typec/fusb302/fusb302.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/f

[PATCH] staging: fusb302: don't bitshift __le16 type

don't get fishy results on big endian systems anymore. Signed-off-by: Frans Klaver --- drivers/staging/typec/fusb302/fusb302.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/fusb302/fusb302.c index

Re: [PATCH v2] staging: wlan-ng: Amend type mismatch warnings

ahesh <suni...@techveda.org> > --- > Changes for v2: > - Reworked on the patch and modified commit message as per the > recommendations from Frans Klaver and Greg K-H. > > - Patch was tested and built on next-20170609 and staging-testing. > --- > drivers/staging/wla

Re: [PATCH v2] staging: wlan-ng: Amend type mismatch warnings

on the patch and modified commit message as per the > recommendations from Frans Klaver and Greg K-H. > > - Patch was tested and built on next-20170609 and staging-testing. > --- > drivers/staging/wlan-ng/hfa384x.h| 18 +- > drivers/staging/wlan-ng/prism

Re: [PATCH] staging: wlan-ng: Amend type mismatch warnings

On Mon, Jun 12, 2017 at 7:15 PM, wrote: > From: Suniel Mahesh > > The following type mismatch warnings reported by sparse > have been amended: > warning: cast to restricted __le16 > warning: incorrect type in assignment (different base types) Why not

Re: [PATCH] staging: wlan-ng: Amend type mismatch warnings

On Mon, Jun 12, 2017 at 7:15 PM, wrote: > From: Suniel Mahesh > > The following type mismatch warnings reported by sparse > have been amended: > warning: cast to restricted __le16 > warning: incorrect type in assignment (different base types) Why not change the type of the struct fields to

Re: [PATCH v2] staging: goldfish: Fix style issues in macros

hink it adds value to the patch, as it's just for a personal goal. It is also custom to reply _below_ the (part of the) message you're responding to by the way ;-). Cheers, Frans > On 27/03/17 15:05, Frans Klaver wrote: >> On Mon, Mar 27, 2017 at 1:52 PM, aviyae <aviya...@gmail.com> wrote

Re: [PATCH v2] staging: goldfish: Fix style issues in macros

as it's just for a personal goal. It is also custom to reply _below_ the (part of the) message you're responding to by the way ;-). Cheers, Frans > On 27/03/17 15:05, Frans Klaver wrote: >> On Mon, Mar 27, 2017 at 1:52 PM, aviyae wrote: >>> From: Aviya Erenfeld >>>

Re: [PATCH v2] staging: goldfish: Fix style issues in macros

On Mon, Mar 27, 2017 at 1:52 PM, aviyae wrote: > From: Aviya Erenfeld > > staging: goldfish: Fix style issues in macros > > Fix coding style issues in macros: > 1. Add parenthesis around macros argument > 2. Avoid arguments reuse in macros > > (For the

Re: [PATCH v2] staging: goldfish: Fix style issues in macros

On Mon, Mar 27, 2017 at 1:52 PM, aviyae wrote: > From: Aviya Erenfeld > > staging: goldfish: Fix style issues in macros > > Fix coding style issues in macros: > 1. Add parenthesis around macros argument > 2. Avoid arguments reuse in macros > > (For the eudyptula challenge) How is that relevant?

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote: > From: Colin Ian King > > info is being checked to see if it is a null pointer, however, vpgu is > dereferencing info before this check, leading to a potential null > pointer dereference. If

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote: > From: Colin Ian King > > info is being checked to see if it is a null pointer, however, vpgu is > dereferencing info before this check, leading to a potential null > pointer dereference. If info is null, then the error message being > printed

[PATCH] staging: wlan_ng: fix logical continuation alignment

It appears that our coding style prefers that logical continuations have the operator at the end of the line. Fix that. While at it, stick the 'if' after 'else' where it belongs. Signed-off-by: Frans Klaver <franskla...@gmail.com> --- drivers/staging/wlan-ng/prism2mgmt.c | 11 +---

[PATCH] staging: wlan_ng: fix logical continuation alignment

It appears that our coding style prefers that logical continuations have the operator at the end of the line. Fix that. While at it, stick the 'if' after 'else' where it belongs. Signed-off-by: Frans Klaver --- drivers/staging/wlan-ng/prism2mgmt.c | 11 +-- 1 file changed, 5 insertions

Re: [PATCH v05 27/72] linux/if.h linux/hdlc/ioctl.h: move IFNAMSIZ definition to hdlc/ioctl.h

On Tue, Aug 23, 2016 at 10:03 AM, Frans Klaver <franskla...@gmail.com> wrote: > On Tue, Aug 23, 2016 at 9:05 AM, David Miller <da...@davemloft.net> wrote: >> From: Frans Klaver <franskla...@gmail.com> >> Date: Tue, 23 Aug 2016 09:03:20 +0200 >> >>> O

Re: [PATCH v05 27/72] linux/if.h linux/hdlc/ioctl.h: move IFNAMSIZ definition to hdlc/ioctl.h

On Tue, Aug 23, 2016 at 10:03 AM, Frans Klaver wrote: > On Tue, Aug 23, 2016 at 9:05 AM, David Miller wrote: >> From: Frans Klaver >> Date: Tue, 23 Aug 2016 09:03:20 +0200 >> >>> On Tue, Aug 23, 2016 at 1:30 AM, David Miller wrote: >>>> From: Mikko Ra

Re: [PATCH v05 27/72] linux/if.h linux/hdlc/ioctl.h: move IFNAMSIZ definition to hdlc/ioctl.h

On Tue, Aug 23, 2016 at 9:05 AM, David Miller <da...@davemloft.net> wrote: > From: Frans Klaver <franskla...@gmail.com> > Date: Tue, 23 Aug 2016 09:03:20 +0200 > >> On Tue, Aug 23, 2016 at 1:30 AM, David Miller <da...@davemloft.net> wrote: >>> From: Mikko

Re: [PATCH v05 27/72] linux/if.h linux/hdlc/ioctl.h: move IFNAMSIZ definition to hdlc/ioctl.h

On Tue, Aug 23, 2016 at 9:05 AM, David Miller wrote: > From: Frans Klaver > Date: Tue, 23 Aug 2016 09:03:20 +0200 > >> On Tue, Aug 23, 2016 at 1:30 AM, David Miller wrote: >>> From: Mikko Rapeli >>> Date: Mon, 22 Aug 2016 20:32:44 +0200 >>> >>&g

Re: [PATCH v05 27/72] linux/if.h linux/hdlc/ioctl.h: move IFNAMSIZ definition to hdlc/ioctl.h

On Tue, Aug 23, 2016 at 1:30 AM, David Miller <da...@davemloft.net> wrote: > From: Mikko Rapeli <mikko.rap...@iki.fi> > Date: Mon, 22 Aug 2016 20:32:44 +0200 > >> Fixes userspace compiler error: >> >> error: ‘IFNAMSIZ’ undeclared here (not in a function) &g

Re: [PATCH v05 27/72] linux/if.h linux/hdlc/ioctl.h: move IFNAMSIZ definition to hdlc/ioctl.h

On Tue, Aug 23, 2016 at 1:30 AM, David Miller wrote: > From: Mikko Rapeli > Date: Mon, 22 Aug 2016 20:32:44 +0200 > >> Fixes userspace compiler error: >> >> error: ‘IFNAMSIZ’ undeclared here (not in a function) >> >> Suggested by Frans Klaver

Re: [PATCH v5 1/2] usb: USB Type-C connector class

On Wed, Aug 17, 2016 at 3:53 PM, Heikki Krogerus <heikki.kroge...@linux.intel.com> wrote: > Hi, > > On Wed, Aug 17, 2016 at 03:14:03PM +0200, Frans Klaver wrote: >> On Wed, Aug 17, 2016 at 12:34 PM, Heikki Krogerus >> > +static const ch

  1   2   3   4   5   6   7   8   9   10   >