Re: [PATCH V4 2/3] mfd: Intel Platform Monitoring Technology support

at 12:58 AM, Lee Jones wrote: If you do: do { int pos; pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC); if (!pos) break; Then you can invoke pci_find_next_ext_capability() once, no? Part

Re: Linux 4.4.174

On Feb 9, 2019, at 12:13 AM, Greg KH wrote: On Fri, Feb 08, 2019 at 08:44:32PM -0800, Mark D Rustad wrote: On Feb 8, 2019, at 2:54 AM, Greg KH wrote: diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 2ea4c45cf1c8..7c229f59016f 100644

Re: Linux 4.4.174

On Feb 8, 2019, at 2:54 AM, Greg KH wrote: diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 2ea4c45cf1c8..7c229f59016f 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -112,14 +112,11 @@

Re: [virtio-dev] [RFC PATCH V2] virtio_pci: Add SR-IOV support

> On Feb 25, 2018, at 7:20 AM, Yan Vugenfirer wrote: > > Small mistake in the commit message. Red Hat (Qumranet) vendor ID is 1af4, > virtio-net device ID is 1041. > Should be: > PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe > VF: vendor: 1af4 device: 1041

Re: [virtio-dev] [RFC PATCH V2] virtio_pci: Add SR-IOV support

> On Feb 25, 2018, at 7:20 AM, Yan Vugenfirer wrote: > > Small mistake in the commit message. Red Hat (Qumranet) vendor ID is 1af4, > virtio-net device ID is 1041. > Should be: > PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe > VF: vendor: 1af4 device: 1041 subvendor: 8086

Re: [PATCH 00/31 v2] PTI support for x86_32

> On Feb 11, 2018, at 2:59 AM, Adam Borowski wrote: > >> Does Debian make it easy to upgrade to a 64-bit kernel if you have a >> 32-bit install? > > Quite easy, yeah. Crossgrading userspace is not for the faint of the heart, > but changing just the kernel is fine. ISTR

Re: [PATCH 00/31 v2] PTI support for x86_32

> On Feb 11, 2018, at 2:59 AM, Adam Borowski wrote: > >> Does Debian make it easy to upgrade to a 64-bit kernel if you have a >> 32-bit install? > > Quite easy, yeah. Crossgrading userspace is not for the faint of the heart, > but changing just the kernel is fine. ISTR that iscsi doesn't work

Re: [PATCH 06/11] irqchip: mips-cpu: Drop unnecessary static

> On Jul 15, 2017, at 1:59 PM, Julia Lawall <julia.law...@lip6.fr> wrote: > > On Sat, 15 Jul 2017, Mark D Rustad wrote: > >> >>> On Jul 15, 2017, at 1:07 PM, Julia Lawall <julia.law...@lip6.fr> wrote: >>> >>> Drop static on a local

Re: [PATCH 06/11] irqchip: mips-cpu: Drop unnecessary static

> On Jul 15, 2017, at 1:59 PM, Julia Lawall wrote: > > On Sat, 15 Jul 2017, Mark D Rustad wrote: > >> >>> On Jul 15, 2017, at 1:07 PM, Julia Lawall wrote: >>> >>> Drop static on a local variable, when the variable is initialized before >>&

Re: [PATCH 06/11] irqchip: mips-cpu: Drop unnecessary static

> On Jul 15, 2017, at 1:07 PM, Julia Lawall wrote: > > Drop static on a local variable, when the variable is initialized before > any possible use. Thus, the static has no benefit. I think this is in error like the other one. I believe that the irq_chip structure needs

Re: [PATCH 06/11] irqchip: mips-cpu: Drop unnecessary static

> On Jul 15, 2017, at 1:07 PM, Julia Lawall wrote: > > Drop static on a local variable, when the variable is initialized before > any possible use. Thus, the static has no benefit. I think this is in error like the other one. I believe that the irq_chip structure needs a persistent lifetime.

Re: [PATCH 07/11] mfd: Drop unnecessary static

> On Jul 15, 2017, at 1:07 PM, Julia Lawall wrote: > > Drop static on a local variable, when the variable is initialized before > any possible use. Thus, the static has no benefit. I think in this case the use relies on the structure continuing to exist, so a stack

Re: [PATCH 07/11] mfd: Drop unnecessary static

> On Jul 15, 2017, at 1:07 PM, Julia Lawall wrote: > > Drop static on a local variable, when the variable is initialized before > any possible use. Thus, the static has no benefit. I think in this case the use relies on the structure continuing to exist, so a stack object is not an acceptable

Re: MBR partitions slow?

Ulrich Windl wrote: So without partition the throughput is about twice as high! Why? My first thought is that by starting at block 0 the accesses were aligned with the flash block size of the device. By starting at a partition, the accesses probably

Re: MBR partitions slow?

Ulrich Windl wrote: So without partition the throughput is about twice as high! Why? My first thought is that by starting at block 0 the accesses were aligned with the flash block size of the device. By starting at a partition, the accesses probably were not so aligned. -- Mark Rustad,

Re: [PATCH] CodingStyle: Clarify and complete chapter 7

Jonathan Corbet wrote: On Mon, 25 Jul 2016 14:29:06 +0200 Jean Delvare wrote: Chapter 7 (Centralized exiting of functions) of the coding style documentation is unclear at times, and lacks some information (such as the possibility to indent labels with a

Re: [PATCH] CodingStyle: Clarify and complete chapter 7

Jonathan Corbet wrote: On Mon, 25 Jul 2016 14:29:06 +0200 Jean Delvare wrote: Chapter 7 (Centralized exiting of functions) of the coding style documentation is unclear at times, and lacks some information (such as the possibility to indent labels with a single space.) Clarify and complete

Re: [Intel-wired-lan] [PATCH] e1000e: prevent division by zero if TIMINCA is zero

Jarod Wilson wrote: On Fri, May 06, 2016 at 11:43:17PM +, Rustad, Mark D wrote: Denys Vlasenko wrote: Users report that under VMWare, er32(TIMINCA) returns zero. This causes division by zero at init time as follows: ==>incvalue =

Re: [Intel-wired-lan] [PATCH] e1000e: prevent division by zero if TIMINCA is zero

Jarod Wilson wrote: On Fri, May 06, 2016 at 11:43:17PM +, Rustad, Mark D wrote: Denys Vlasenko wrote: Users report that under VMWare, er32(TIMINCA) returns zero. This causes division by zero at init time as follows: ==>incvalue = er32(TIMINCA) &

Re: Determination for the number of named function parameters (with SmPL)

On Dec 1, 2014, at 3:12 AM, SF Markus Elfring wrote: > Hello, > > Would you like to know how many named function parameters are used in the > source files? > > How do you think about to try the following semantic query approach out a bit > more? > > @initialize:python@ > @@ > import sys >

Re: Determination for the number of named function parameters (with SmPL)

On Dec 1, 2014, at 3:12 AM, SF Markus Elfring elfr...@users.sourceforge.net wrote: Hello, Would you like to know how many named function parameters are used in the source files? How do you think about to try the following semantic query approach out a bit more? @initialize:python@

Re: [PATCH] char: hw_random: core.c: Changed from using strncpy to strlcpy

On Oct 11, 2014, at 3:36 PM, Rickard Strandqvist wrote: > Changed from using strncpy to strlcpy to simplify the code Actually you changed from using strncat to strlcat. > Signed-off-by: Rickard Strandqvist > --- > drivers/char/hw_random/core.c | 12 > 1 file changed, 4

Re: [PATCH] char: hw_random: core.c: Changed from using strncpy to strlcpy

On Oct 11, 2014, at 3:36 PM, Rickard Strandqvist rickard_strandqv...@spectrumdigital.se wrote: Changed from using strncpy to strlcpy to simplify the code Actually you changed from using strncat to strlcat. Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se ---

[PATCH] sched: Remove nested extern

Avoid W=2 nested-externs warning by moving the nested extern to a normal extern. This eliminates that warning which is generated for every inclusion of sched.h in a kernel build when W=2 is used. This also removes a point of maintenance if the definition of delayacct_on were ever to change.

[PATCH] sched: Remove nested extern

Avoid W=2 nested-externs warning by moving the nested extern to a normal extern. This eliminates that warning which is generated for every inclusion of sched.h in a kernel build when W=2 is used. This also removes a point of maintenance if the definition of delayacct_on were ever to change.

Re: Overriding -Werror

On Aug 15, 2014, at 9:34 PM, Brian Norris wrote: > Hi Mark, > > (BTW, your mailer is creating some pretty long, unwrapped lines. I've > rewrapped them when quoting below.) Sorry about that. I'll try to remember to deal with it on my end. > On Fri, Aug 15, 2014 at 08:36:07P

Re: Overriding -Werror

:07PM -0700, Mark D Rustad wrote: On Aug 15, 2014, at 12:33 PM, Brian Norris computersforpe...@gmail.com wrote: On Fri, Aug 15, 2014 at 02:30:49AM -0700, Jeff Kirsher wrote: Funny that you bring this up because I have ~60 patches in my queue to resolve several thousand of these warnings. Half

Re: Overriding -Werror

Brian, On Aug 15, 2014, at 12:33 PM, Brian Norris wrote: > Hi, > > On Fri, Aug 15, 2014 at 02:30:49AM -0700, Jeff Kirsher wrote: >> Funny that you bring this up because I have ~60 patches in my queue to >> resolve several thousand of these warnings. Half of the patches >> actually resolve

Re: Overriding -Werror

Brian, On Aug 15, 2014, at 12:33 PM, Brian Norris computersforpe...@gmail.com wrote: Hi, On Fri, Aug 15, 2014 at 02:30:49AM -0700, Jeff Kirsher wrote: Funny that you bring this up because I have ~60 patches in my queue to resolve several thousand of these warnings. Half of the patches

Re: [PATCH] misc: ti-st: st_kim.c: Cleaning up missing null-terminate after strncpy call

On Aug 9, 2014, at 4:45 PM, Rickard Strandqvist wrote: > Added a guaranteed null-terminate after call to strncpy. > > Signed-off-by: Rickard Strandqvist > --- > drivers/misc/ti-st/st_kim.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/misc/ti-st/st_kim.c

Re: [PATCH] net: ethernet: myricom: myri10ge: myri10ge.c: Cleaning up missing null-terminate after strncpy call

On Aug 9, 2014, at 4:40 PM, Rickard Strandqvist wrote: > Added a guaranteed null-terminate after call to strncpy. > > Signed-off-by: Rickard Strandqvist > --- > drivers/net/ethernet/myricom/myri10ge/myri10ge.c |1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [PATCH] net: ethernet: myricom: myri10ge: myri10ge.c: Cleaning up missing null-terminate after strncpy call

On Aug 9, 2014, at 4:40 PM, Rickard Strandqvist rickard_strandqv...@spectrumdigital.se wrote: Added a guaranteed null-terminate after call to strncpy. Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se --- drivers/net/ethernet/myricom/myri10ge/myri10ge.c |1 + 1

Re: [PATCH] misc: ti-st: st_kim.c: Cleaning up missing null-terminate after strncpy call

On Aug 9, 2014, at 4:45 PM, Rickard Strandqvist rickard_strandqv...@spectrumdigital.se wrote: Added a guaranteed null-terminate after call to strncpy. Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se --- drivers/misc/ti-st/st_kim.c |1 + 1 file changed, 1

Re: [PATCH] arch: x86: ia32: ia32_aout.c: Cleaning up missing null-terminate in conjunction with strncpy

Rickard, On Jul 26, 2014, at 2:50 PM, Rickard Strandqvist wrote: > Replacing strncpy with strlcpy to avoid strings that lacks null terminate. > And use the sizeof on the to string rather than the from string. > > Signed-off-by: Rickard Strandqvist > --- > arch/x86/ia32/ia32_aout.c |2 +-

Re: [PATCH] arch: x86: ia32: ia32_aout.c: Cleaning up missing null-terminate in conjunction with strncpy

Rickard, On Jul 26, 2014, at 2:50 PM, Rickard Strandqvist rickard_strandqv...@spectrumdigital.se wrote: Replacing strncpy with strlcpy to avoid strings that lacks null terminate. And use the sizeof on the to string rather than the from string. Signed-off-by: Rickard Strandqvist

Re: [PATCH] crypto: ablkcipher.c: Cleaning up missing null-terminate in conjunction with strncpy

Rickard, On Jul 26, 2014, at 7:09 AM, Rickard Strandqvist wrote: > Replacing strncpy with strlcpy to avoid strings that lacks null terminate. > > Signed-off-by: Rickard Strandqvist > --- > crypto/ablkcipher.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git

Re: [PATCH] crypto: crypto_user.c: Cleaning up missing null-terminate in conjunction with strncpy

Rickard, On Jul 26, 2014, at 7:15 AM, Rickard Strandqvist wrote: > Replacing strncpy with strlcpy to avoid strings that lacks null terminate. > > Signed-off-by: Rickard Strandqvist > --- > crypto/crypto_user.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff

Re: [PATCH] crypto: rng.c: Cleaning up missing null-terminate in conjunction with strncpy

Rickard, On Jul 26, 2014, at 7:18 AM, Rickard Strandqvist wrote: > Replacing strncpy with strlcpy to avoid strings that lacks null terminate. > > Signed-off-by: Rickard Strandqvist > --- > crypto/rng.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/crypto/rng.c

Re: [PATCH] crypto: rng.c: Cleaning up missing null-terminate in conjunction with strncpy

Rickard, On Jul 26, 2014, at 7:18 AM, Rickard Strandqvist rickard_strandqv...@spectrumdigital.se wrote: Replacing strncpy with strlcpy to avoid strings that lacks null terminate. Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se --- crypto/rng.c |2 +- 1 file

Re: [PATCH] crypto: crypto_user.c: Cleaning up missing null-terminate in conjunction with strncpy

Rickard, On Jul 26, 2014, at 7:15 AM, Rickard Strandqvist rickard_strandqv...@spectrumdigital.se wrote: Replacing strncpy with strlcpy to avoid strings that lacks null terminate. Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se --- crypto/crypto_user.c | 12

Re: [PATCH] crypto: ablkcipher.c: Cleaning up missing null-terminate in conjunction with strncpy

Rickard, On Jul 26, 2014, at 7:09 AM, Rickard Strandqvist rickard_strandqv...@spectrumdigital.se wrote: Replacing strncpy with strlcpy to avoid strings that lacks null terminate. Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se --- crypto/ablkcipher.c |8

Re: [PATCH V2] x86/PCI: MMCONFIG: cleanup and add address warning to pci_mmconfig_insert

Another nit below: On Jul 27, 2013, at 12:32 PM, ethan.ker...@gmail.com wrote: > Cleanup the -EINVAL return value handling and add warning message for invalid > start,end,addr parameters. > > V2: Corrected code style and tested for Linux v 3.11-rc2 > > Signed-off-by: ethan.zhao > --- >

Re: [PATCH V2] x86/PCI: MMCONFIG: cleanup and add address warning to pci_mmconfig_insert

Another nit below: On Jul 27, 2013, at 12:32 PM, ethan.ker...@gmail.com wrote: Cleanup the -EINVAL return value handling and add warning message for invalid start,end,addr parameters. V2: Corrected code style and tested for Linux v 3.11-rc2 Signed-off-by: ethan.zhao ethan.z...@oracle.com