Re: namei_vfat.c array subscript is above array bounds

Meelis Roos writes: >> > I do not know if this is old or new, just noticed it scrolling by while >> > compiling current 4.12+git on 32-bit x86. >> >> Which version of compiler? > > gcc version 6.4.0 20170704 (Debian 6.4.0-1) > > After "touch fs/fat/namei_vfat.c" it appears

Re: namei_vfat.c array subscript is above array bounds

Meelis Roos writes: >> > I do not know if this is old or new, just noticed it scrolling by while >> > compiling current 4.12+git on 32-bit x86. >> >> Which version of compiler? > > gcc version 6.4.0 20170704 (Debian 6.4.0-1) > > After "touch fs/fat/namei_vfat.c" it appears consitently for me.

Re: [PATCH v16 2/7] power: add power sequence library

On Fri, Jul 07, 2017 at 03:03:06PM +0200, Rafael J. Wysocki wrote: > On Friday, July 07, 2017 04:01:07 PM Peter Chen wrote: > > On Fri, Jul 07, 2017 at 03:13:48AM +0200, Rafael J. Wysocki wrote: > > > > > > > > - Can I write new code for it or I need to depend on something? > > > > > > There is

Re: [PATCH v16 2/7] power: add power sequence library

On Fri, Jul 07, 2017 at 03:03:06PM +0200, Rafael J. Wysocki wrote: > On Friday, July 07, 2017 04:01:07 PM Peter Chen wrote: > > On Fri, Jul 07, 2017 at 03:13:48AM +0200, Rafael J. Wysocki wrote: > > > > > > > > - Can I write new code for it or I need to depend on something? > > > > > > There is

Re: [PATCH] printk: Move printk_delay to separate file

On Sat, 2017-07-08 at 14:24 +0900, Sergey Senozhatsky wrote: > On (07/07/17 11:08), Joe Perches wrote: > > printk.c is a huge file with too many local functions for a > > human to read and easily parse. > > > > Start to separate out bits into smaller files. > > > > Miscellanea: > > > > o Rename

Re: [PATCH] printk: Move printk_delay to separate file

On Sat, 2017-07-08 at 14:24 +0900, Sergey Senozhatsky wrote: > On (07/07/17 11:08), Joe Perches wrote: > > printk.c is a huge file with too many local functions for a > > human to read and easily parse. > > > > Start to separate out bits into smaller files. > > > > Miscellanea: > > > > o Rename

[GIT PULL]: dmaengine updates for 4.13-rc1

Hi Linus, Please pull dmaengine updates for v4.13-rc1 as detailed below. The AVR32 removal in dma and sound has been coordinated with me pulling tiwai/topic/avr32-removal into dmaengine tree, you should get those from Takashi. Also the mv_xor fixes ai/topic/avr32-removal is already merged in

[GIT PULL]: dmaengine updates for 4.13-rc1

Hi Linus, Please pull dmaengine updates for v4.13-rc1 as detailed below. The AVR32 removal in dma and sound has been coordinated with me pulling tiwai/topic/avr32-removal into dmaengine tree, you should get those from Takashi. Also the mv_xor fixes ai/topic/avr32-removal is already merged in

Re: [PATCH 3/9] firmware: arm_scmi: add basic driver infrastructure for SCMI

Hi Roy, Matt, Nishant, Harb Abdulhamid, Loc, I have a gut feeling you guys were part of the SCMI spec committee. If so, could you please chime in? On Fri, Jul 7, 2017 at 11:09 PM, Sudeep Holla wrote: > > > On 07/07/17 17:52, Jassi Brar wrote: >> Hi Arnd, Hi Rob, Hi Mark,

Re: [PATCH 3/9] firmware: arm_scmi: add basic driver infrastructure for SCMI

Hi Roy, Matt, Nishant, Harb Abdulhamid, Loc, I have a gut feeling you guys were part of the SCMI spec committee. If so, could you please chime in? On Fri, Jul 7, 2017 at 11:09 PM, Sudeep Holla wrote: > > > On 07/07/17 17:52, Jassi Brar wrote: >> Hi Arnd, Hi Rob, Hi Mark, >> >> [CC'ing only

Re: [PATCH 2/2] ARM: dts: motorola-cpcap-mapphone: set initial mode for vaudio

* Sebastian Reichel [170707 13:08]: > Set default mode for vaudio, which may be left in standby mode > if the system is booted via kexec from Android. Acked-by: Tony Lindgren

Re: [PATCH 2/2] ARM: dts: motorola-cpcap-mapphone: set initial mode for vaudio

* Sebastian Reichel [170707 13:08]: > Set default mode for vaudio, which may be left in standby mode > if the system is booted via kexec from Android. Acked-by: Tony Lindgren

Re: [PATCH 1/2] regulator: cpcap: Fix standby mode

* Sebastian Reichel [170707 13:08]: > While working on the audio-codec I noticed, that the > low power mode of the regulators are not properly > supported. This fixes the issue for vaudio. Yeah good catch: Acked-by: Tony Lindgren

Re: [PATCH 1/2] regulator: cpcap: Fix standby mode

* Sebastian Reichel [170707 13:08]: > While working on the audio-codec I noticed, that the > low power mode of the regulators are not properly > supported. This fixes the issue for vaudio. Yeah good catch: Acked-by: Tony Lindgren

Re: [PATCH 0/3] Motorola Droid 4 Audio Support

* Sebastian Reichel [170707 09:43]: > Hi, > > I got working sound on Droid 4 with mainline \o/. The codec is > currently missing support for detecting if something has been > plugged into the 3.5mm connector, since that seems to require > some closed source

Re: [git pull] vfs.git pile 13 - killing __copy_in_user()

On Fri, Jul 7, 2017 at 5:29 PM, Al Viro wrote: > There used to be 6 places in the entire tree calling __copy_in_user(), > all of them bogus. Four got killed off in work.drm branch, this takes care of > the remaining ones and kills the definition of that sucker.

Re: [PATCH 0/3] Motorola Droid 4 Audio Support

* Sebastian Reichel [170707 09:43]: > Hi, > > I got working sound on Droid 4 with mainline \o/. The codec is > currently missing support for detecting if something has been > plugged into the 3.5mm connector, since that seems to require > some closed source firmware and needs further

Re: [git pull] vfs.git pile 13 - killing __copy_in_user()

On Fri, Jul 7, 2017 at 5:29 PM, Al Viro wrote: > There used to be 6 places in the entire tree calling __copy_in_user(), > all of them bogus. Four got killed off in work.drm branch, this takes care of > the remaining ones and kills the definition of that sucker. This branch is garbage.

Re: [PATCH] printk: Move printk_delay to separate file

On (07/07/17 11:08), Joe Perches wrote: > printk.c is a huge file with too many local functions for a > human to read and easily parse. > > Start to separate out bits into smaller files. > > Miscellanea: > > o Rename suppress_message_printing to printk_suppress_message > o Add function

Re: [PATCH] printk: Move printk_delay to separate file

On (07/07/17 11:08), Joe Perches wrote: > printk.c is a huge file with too many local functions for a > human to read and easily parse. > > Start to separate out bits into smaller files. > > Miscellanea: > > o Rename suppress_message_printing to printk_suppress_message > o Add function

Re: [PATCH] printk: Modify operators of printed_len

On (07/08/17 10:51), Pierre Kuo wrote: > In 8b1742c9c207, we remove printk-recursion detection code in > vprintk_emit(), where it is the first place that printed_len calculated. > After removing above detection, it seems we can directly assign the > result of log_output to printed_len. > >

Re: [PATCH] printk: Modify operators of printed_len

On (07/08/17 10:51), Pierre Kuo wrote: > In 8b1742c9c207, we remove printk-recursion detection code in > vprintk_emit(), where it is the first place that printed_len calculated. > After removing above detection, it seems we can directly assign the > result of log_output to printed_len. > >

Re: [PATCH 2/2] ext4: fix __ext4_new_inode() journal credits calculation

On Wed, Jul 05, 2017 at 07:38:19PM -0700, Tahsin Erdogan wrote: > ea_inode feature allows creating extended attributes that are up to > 64k in size. Update __ext4_new_inode() to pick increased credit limits. > > To avoid overallocating too many journal credits, update > __ext4_xattr_set_credits()

Re: [PATCH 2/2] ext4: fix __ext4_new_inode() journal credits calculation

On Wed, Jul 05, 2017 at 07:38:19PM -0700, Tahsin Erdogan wrote: > ea_inode feature allows creating extended attributes that are up to > 64k in size. Update __ext4_new_inode() to pick increased credit limits. > > To avoid overallocating too many journal credits, update > __ext4_xattr_set_credits()

[PATCH] cisco: enic: Fic an error handling path in 'vnic_dev_init_devcmd2()'

if 'ioread32()' returns 0xFFF, we have to go through the error handling path as done everywhere else in this function. Move the 'err_free_wq' label to better match its name and its location and add a new label 'err_disable_wq'. Update the code accordingly. Fixes: 373fb0873d43 ("enic: add

[PATCH] cisco: enic: Fic an error handling path in 'vnic_dev_init_devcmd2()'

if 'ioread32()' returns 0xFFF, we have to go through the error handling path as done everywhere else in this function. Move the 'err_free_wq' label to better match its name and its location and add a new label 'err_disable_wq'. Update the code accordingly. Fixes: 373fb0873d43 ("enic: add

Re: [git pull] vfs.git pile 11 - iov_iter/hardening

On Fri, Jul 7, 2017 at 5:29 PM, Al Viro wrote: > > Trivial conflicts with libnvdimm; this stuff will get some > followups, but again, that's for another series. Gaah. Yeah, I guess I could have done the trivial ugly merge that just took the new

Re: [git pull] vfs.git pile 11 - iov_iter/hardening

On Fri, Jul 7, 2017 at 5:29 PM, Al Viro wrote: > > Trivial conflicts with libnvdimm; this stuff will get some > followups, but again, that's for another series. Gaah. Yeah, I guess I could have done the trivial ugly merge that just took the new copy_from_iter_flushcache() as-is, and

[RESEND PATCH v2 6/7] pwm: rockchip: Add rk3328 pwm support

The rk3328 soc supports atomic update, we could lock the configuration of period and duty at first, after unlock is configured, the period and duty are effective at the same time. If the polarity, period and duty need to be configured together, the way for atomic update is "configure lock and old

[RESEND PATCH v2 6/7] pwm: rockchip: Add rk3328 pwm support

The rk3328 soc supports atomic update, we could lock the configuration of period and duty at first, after unlock is configured, the period and duty are effective at the same time. If the polarity, period and duty need to be configured together, the way for atomic update is "configure lock and old

[PATCH v2 7/7] arm64: dts: rockchip: Add pwm nodes for rk3328

There are 4 pwm channels built in rk3328 soc, need to configure the both APB clock and bus clock. Signed-off-by: David Wu --- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 45 1 file changed, 45 insertions(+) diff --git

[PATCH v2 7/7] arm64: dts: rockchip: Add pwm nodes for rk3328

There are 4 pwm channels built in rk3328 soc, need to configure the both APB clock and bus clock. Signed-off-by: David Wu --- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 45 1 file changed, 45 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi

[PATCH v2 6/7] pwm: rockchip: Add rk3328 pwm support

The rk3328 soc supports atomic update, we could lock the configuration of period and duty at first, after unlock is configured, the period and duty are effective at the same time. If the polarity, period and duty need to be configured together, the way for atomic update is "configure lock and old

[PATCH v2 6/7] pwm: rockchip: Add rk3328 pwm support

The rk3328 soc supports atomic update, we could lock the configuration of period and duty at first, after unlock is configured, the period and duty are effective at the same time. If the polarity, period and duty need to be configured together, the way for atomic update is "configure lock and old

[PATCH v2 5/7] pwm: rockchip: Move the configuration of polarity from rockchip_pwm_set_enable() to rockchip_pwm_config()

It is usually possible to configure the polarity, cycle and duty all at once, so that the polarity and cycle and duty should be binding together. Move it into rockchip_pwm_config(), as well as prepared for the next atomic update commit. Signed-off-by: David Wu ---

[PATCH v2 5/7] pwm: rockchip: Move the configuration of polarity from rockchip_pwm_set_enable() to rockchip_pwm_config()

It is usually possible to configure the polarity, cycle and duty all at once, so that the polarity and cycle and duty should be binding together. Move it into rockchip_pwm_config(), as well as prepared for the next atomic update commit. Signed-off-by: David Wu --- drivers/pwm/pwm-rockchip.c |

[PATCH v2 4/7] pwm: rockchip: Use pwm_apply instead of the pwm_enable

Drop the custom hook of pwm_enable and implement pwm_apply_v1 and pwm_apply_v2 instead. Signed-off-by: David Wu --- drivers/pwm/pwm-rockchip.c | 141 + 1 file changed, 77 insertions(+), 64 deletions(-) diff --git

[PATCH v2 0/7] Add rk3328 pwm support

There are two features of rk3328 pwm module. - PWM APB and function clocks are different. - Add pwm atomic hardware update David Wu (7): pwm: rockchip: Add APB and function both clocks support pwm: rockchip: Remove the judge from return value of pwm_config pwm: rockchip: Remove the

[PATCH v2 4/7] pwm: rockchip: Use pwm_apply instead of the pwm_enable

Drop the custom hook of pwm_enable and implement pwm_apply_v1 and pwm_apply_v2 instead. Signed-off-by: David Wu --- drivers/pwm/pwm-rockchip.c | 141 + 1 file changed, 77 insertions(+), 64 deletions(-) diff --git a/drivers/pwm/pwm-rockchip.c

[PATCH v2 0/7] Add rk3328 pwm support

There are two features of rk3328 pwm module. - PWM APB and function clocks are different. - Add pwm atomic hardware update David Wu (7): pwm: rockchip: Add APB and function both clocks support pwm: rockchip: Remove the judge from return value of pwm_config pwm: rockchip: Remove the

[PATCH v2 2/7] pwm: rockchip: Remove the judge from return value of pwm_config

It seems the rockchip_pwm_config always returns the result 0, so remove the judge. Signed-off-by: David Wu Acked-by: Boris Brezillon --- drivers/pwm/pwm-rockchip.c | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-)

[PATCH v2 1/7] pwm: rockchip: Add APB and function both clocks support

New PWM module provides two individual clocks for APB clock and function clock. Signed-off-by: David Wu Acked-by: Rob Herring --- .../devicetree/bindings/pwm/pwm-rockchip.txt | 8 +++- drivers/pwm/pwm-rockchip.c | 53

[PATCH v2 3/7] pwm: rockchip: Remove the dumplicate rockchip_pwm_ops ops

The rockchip_pwm_ops_v1 and rockchip_pwm_ops_v2 ops are the same struct members, remove one of them. Signed-off-by: David Wu --- drivers/pwm/pwm-rockchip.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/pwm/pwm-rockchip.c

[PATCH v2 2/7] pwm: rockchip: Remove the judge from return value of pwm_config

It seems the rockchip_pwm_config always returns the result 0, so remove the judge. Signed-off-by: David Wu Acked-by: Boris Brezillon --- drivers/pwm/pwm-rockchip.c | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/drivers/pwm/pwm-rockchip.c

[PATCH v2 1/7] pwm: rockchip: Add APB and function both clocks support

New PWM module provides two individual clocks for APB clock and function clock. Signed-off-by: David Wu Acked-by: Rob Herring --- .../devicetree/bindings/pwm/pwm-rockchip.txt | 8 +++- drivers/pwm/pwm-rockchip.c | 53 ++ 2 files changed, 51

[PATCH v2 3/7] pwm: rockchip: Remove the dumplicate rockchip_pwm_ops ops

The rockchip_pwm_ops_v1 and rockchip_pwm_ops_v2 ops are the same struct members, remove one of them. Signed-off-by: David Wu --- drivers/pwm/pwm-rockchip.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c

Re: [PATCH 0/2] exec: Use sane stack rlimit for setuid exec

On Fri, Jul 7, 2017 at 1:04 PM, Linus Torvalds wrote: > On Fri, Jul 7, 2017 at 12:56 PM, Kees Cook wrote: >> As discussed with Linus and Andy, we need to reset the stack rlimit >> before we do memory layouts when execing a privilege-gaining

Re: [PATCH 0/2] exec: Use sane stack rlimit for setuid exec

On Fri, Jul 7, 2017 at 1:04 PM, Linus Torvalds wrote: > On Fri, Jul 7, 2017 at 12:56 PM, Kees Cook wrote: >> As discussed with Linus and Andy, we need to reset the stack rlimit >> before we do memory layouts when execing a privilege-gaining (e.g. >> setuid) program. This moves

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

On Fri, Jul 7, 2017 at 7:04 PM, Casey Leedom wrote: > Okay, thanks for the note Alexander. I'll have to look more closely at > the patch on Monday and try it out on one of the targeted systems to verify > the semantics you describe. > > However, that said, there is no way

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

On Fri, Jul 7, 2017 at 7:04 PM, Casey Leedom wrote: > Okay, thanks for the note Alexander. I'll have to look more closely at > the patch on Monday and try it out on one of the targeted systems to verify > the semantics you describe. > > However, that said, there is no way to tell a priori

Re: [PATCH v3] acpi: handle the acpi hotplug schedule error

Hi Rafael, On Fri, Jul 07, 2017 at 03:16:40PM +0200, Rafael J. Wysocki wrote: > On Friday, July 07, 2017 02:22:42 PM Lee, Chun-Yi wrote: > > Kernel should decrements the reference count of acpi device > > when the scheduling of acpi hotplug work failed, and evaluates > > _OST to notify BIOS the

Re: [PATCH v3] acpi: handle the acpi hotplug schedule error

Hi Rafael, On Fri, Jul 07, 2017 at 03:16:40PM +0200, Rafael J. Wysocki wrote: > On Friday, July 07, 2017 02:22:42 PM Lee, Chun-Yi wrote: > > Kernel should decrements the reference count of acpi device > > when the scheduling of acpi hotplug work failed, and evaluates > > _OST to notify BIOS the

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Sat, Jul 08, 2017 at 01:40:18AM +0200, Adam Borowski wrote: > On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote: > > On 7/6/17, 9:32 AM, "Adam Borowski" wrote: > > > Got a reproducible crash on amd64: > > > Thanks for the bug report Adam! I'm looking into the

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Sat, Jul 08, 2017 at 01:40:18AM +0200, Adam Borowski wrote: > On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote: > > On 7/6/17, 9:32 AM, "Adam Borowski" wrote: > > > Got a reproducible crash on amd64: > > > Thanks for the bug report Adam! I'm looking into the failure, and haven't >

[PATCH] printk: Modify operators of printed_len

In 8b1742c9c207, we remove printk-recursion detection code in vprintk_emit(), where it is the first place that printed_len calculated. After removing above detection, it seems we can directly assign the result of log_output to printed_len. Signed-off-by: Pierre Kuo ---

[PATCH] printk: Modify operators of printed_len

In 8b1742c9c207, we remove printk-recursion detection code in vprintk_emit(), where it is the first place that printed_len calculated. After removing above detection, it seems we can directly assign the result of log_output to printed_len. Signed-off-by: Pierre Kuo --- kernel/printk/printk.c |

Re: [PATCH] printk: Modify operators of printed_len

hi Joe >> > [] >> > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c >> > >> > [] >> > > @@ -1754,7 +1754,7 @@ asmlinkage int vprintk_emit(int facility, int >> > > level, >> > > if (dict) >> > > lflags |= LOG_PREFIX|LOG_NEWLINE; >> > > >> > > - printed_len +=

Re: [PATCH] printk: Modify operators of printed_len

hi Joe >> > [] >> > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c >> > >> > [] >> > > @@ -1754,7 +1754,7 @@ asmlinkage int vprintk_emit(int facility, int >> > > level, >> > > if (dict) >> > > lflags |= LOG_PREFIX|LOG_NEWLINE; >> > > >> > > - printed_len +=

Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3

On Fri, Jul 7, 2017 at 3:24 PM, Linus Torvalds wrote: > On Fri, Jul 7, 2017 at 11:57 AM, Kees Cook wrote: >> To avoid pathological stack usage or the need to special-case setuid >> execs, just limit all arg stack usage to at most _STK_LIM / 4

Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3

On Fri, Jul 7, 2017 at 3:24 PM, Linus Torvalds wrote: > On Fri, Jul 7, 2017 at 11:57 AM, Kees Cook wrote: >> To avoid pathological stack usage or the need to special-case setuid >> execs, just limit all arg stack usage to at most _STK_LIM / 4 * 3 (6MB). > > Ok, this I think I should just apply,

Re: [GIT PULL] writeback error handling fixes (pile #2)

On Thu, Jul 6, 2017 at 5:26 AM, Jeff Layton wrote: > > Sorry for the long description, but I think it's important to give good > background here: Thanks, this was what I wanted. Looks good, and pulled - still going through my basic test-builds before getting pushed out.

Re: [GIT PULL] writeback error handling fixes (pile #2)

On Thu, Jul 6, 2017 at 5:26 AM, Jeff Layton wrote: > > Sorry for the long description, but I think it's important to give good > background here: Thanks, this was what I wanted. Looks good, and pulled - still going through my basic test-builds before getting pushed out. Linus

Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells

On 07/07/2017 07:51 PM, Goldwyn Rodrigues wrote: > > > On 07/04/2017 05:16 PM, Jens Axboe wrote: >> >> Please expedite getting this upstream, asap. >> > > Jens, > > I have posted an updated patch [1] and it is acked by David. Would you > pick it up or should it go through the btrfs tree (or

Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells

On 07/07/2017 07:51 PM, Goldwyn Rodrigues wrote: > > > On 07/04/2017 05:16 PM, Jens Axboe wrote: >> >> Please expedite getting this upstream, asap. >> > > Jens, > > I have posted an updated patch [1] and it is acked by David. Would you > pick it up or should it go through the btrfs tree (or

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Okay, thanks for the note Alexander. I'll have to look more closely at the patch on Monday and try it out on one of the targeted systems to verify the semantics you describe. However, that said, there is no way to tell a priori where a device will send TLPs. To simply assume that all TLPs

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Okay, thanks for the note Alexander. I'll have to look more closely at the patch on Monday and try it out on one of the targeted systems to verify the semantics you describe. However, that said, there is no way to tell a priori where a device will send TLPs. To simply assume that all TLPs

Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells

On 07/04/2017 05:16 PM, Jens Axboe wrote: > > Please expedite getting this upstream, asap. > Jens, I have posted an updated patch [1] and it is acked by David. Would you pick it up or should it go through the btrfs tree (or some other tree)? [1] https://patchwork.kernel.org/patch/9825813/

Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells

On 07/04/2017 05:16 PM, Jens Axboe wrote: > > Please expedite getting this upstream, asap. > Jens, I have posted an updated patch [1] and it is acked by David. Would you pick it up or should it go through the btrfs tree (or some other tree)? [1] https://patchwork.kernel.org/patch/9825813/

Re: [PATCH] watchdog: stm32_iwdg: constify watchdog_ops structure

On 07/07/2017 05:28 PM, Gustavo A. R. Silva wrote: Check for watchdog_ops structures that are only stored in the ops field of a watchdog_device structure. This field is declared const, so watchdog_ops structures that have this property can be declared as const also. This issue was detected

Re: [PATCH] watchdog: stm32_iwdg: constify watchdog_ops structure

On 07/07/2017 05:28 PM, Gustavo A. R. Silva wrote: Check for watchdog_ops structures that are only stored in the ops field of a watchdog_device structure. This field is declared const, so watchdog_ops structures that have this property can be declared as const also. This issue was detected

Re: [PATCH] watchdog: coh901327_wdt: constify watchdog_ops structure

On 07/07/2017 05:33 PM, Gustavo A. R. Silva wrote: Check for watchdog_ops structures that are only stored in the ops field of a watchdog_device structure. This field is declared const, so watchdog_ops structures that have this property can be declared as const also. This issue was detected

Re: [PATCH] watchdog: coh901327_wdt: constify watchdog_ops structure

On 07/07/2017 05:33 PM, Gustavo A. R. Silva wrote: Check for watchdog_ops structures that are only stored in the ops field of a watchdog_device structure. This field is declared const, so watchdog_ops structures that have this property can be declared as const also. This issue was detected

Re: [PATCH] watchdog: stm32_iwdg: constify watchdog_ops structure

On 07/07/2017 05:28 PM, Gustavo A. R. Silva wrote: Check for watchdog_ops structures that are only stored in the ops field of a watchdog_device structure. This field is declared const, so watchdog_ops structures that have this property can be declared as const also. This issue was detected

Re: [PATCH] watchdog: stm32_iwdg: constify watchdog_ops structure

On 07/07/2017 05:28 PM, Gustavo A. R. Silva wrote: Check for watchdog_ops structures that are only stored in the ops field of a watchdog_device structure. This field is declared const, so watchdog_ops structures that have this property can be declared as const also. This issue was detected

Re: [PATCH] watchdog: it87_wdt: constify watchdog_ops structure

On 07/07/2017 05:23 PM, Gustavo A. R. Silva wrote: Check for watchdog_ops structures that are only stored in the ops field of a watchdog_device structure. This field is declared const, so watchdog_ops structures that have this property can be declared as const also. This issue was detected

Re: [PATCH] watchdog: it87_wdt: constify watchdog_ops structure

On 07/07/2017 05:23 PM, Gustavo A. R. Silva wrote: Check for watchdog_ops structures that are only stored in the ops field of a watchdog_device structure. This field is declared const, so watchdog_ops structures that have this property can be declared as const also. This issue was detected

Re: [PATCH] watchdog: ts72xx_wdt: constify watchdog_ops structure

On 07/07/2017 05:18 PM, Gustavo A. R. Silva wrote: Check for watchdog_ops structures that are only stored in the ops field of a watchdog_device structure. This field is declared const, so watchdog_ops structures that have this property can be declared as const also. This issue was detected

Re: [PATCH] watchdog: ts72xx_wdt: constify watchdog_ops structure

On 07/07/2017 05:18 PM, Gustavo A. R. Silva wrote: Check for watchdog_ops structures that are only stored in the ops field of a watchdog_device structure. This field is declared const, so watchdog_ops structures that have this property can be declared as const also. This issue was detected

[PATCH V3 0/3] Refine numa_emulation

My previous patch "x86/mm/numa: Remove numa_nodemask_from_meminfo()" hits a problem in numa_emulation. The reason is numa_nodes_parsed is not set correctly after emulation. This patch set tries to fix this and also with two code refine. Detailed discussions are in this thread:

[PATCH V3 0/3] Refine numa_emulation

My previous patch "x86/mm/numa: Remove numa_nodemask_from_meminfo()" hits a problem in numa_emulation. The reason is numa_nodes_parsed is not set correctly after emulation. This patch set tries to fix this and also with two code refine. Detailed discussions are in this thread:

[PATCH V3 1/3] x86/numa_emulation: refine the calculation of max_emu_nid and dfl_phys_nid

max_emu_nid and dfl_phys_nid is calculated from emu_nid_to_phys[], which is calculated in split_nodes_xxx_interleave(). From the logic in these functions, it is assured the emu_nid_to_phys[] has meaningful value if it return successfully and ensures dfl_phys_nid will get a valid value. This patch

[PATCH V3 1/3] x86/numa_emulation: refine the calculation of max_emu_nid and dfl_phys_nid

max_emu_nid and dfl_phys_nid is calculated from emu_nid_to_phys[], which is calculated in split_nodes_xxx_interleave(). From the logic in these functions, it is assured the emu_nid_to_phys[] has meaningful value if it return successfully and ensures dfl_phys_nid will get a valid value. This patch

[PATCH V3 2/3] x86/numa_emulation: assign physnode_mask directly from numa_nodes_parsed

numa_init() has already called init_func(), which is responsible for setting numa_nodes_parsed, so use this nodemask instead of re-finding it when calling numa_emulation(). This patch gets the physnode_mask directly from numa_nodes_parsed. At the same time, it corrects the comment of these two

[PATCH V3 3/3] x86/numa_emulation: restructures numa_nodes_parsed from emulated nodes

By emulating numa, it may contains more or less nodes than physical nodes. In numa_emulation(), numa_meminfo/numa_distance/__apicid_to_node is restructured according to emulated nodes, except numa_nodes_parsed. This patch restructures numa_nodes_parsed from emulated nodes. Signed-off-by: Wei

[PATCH V3 2/3] x86/numa_emulation: assign physnode_mask directly from numa_nodes_parsed

numa_init() has already called init_func(), which is responsible for setting numa_nodes_parsed, so use this nodemask instead of re-finding it when calling numa_emulation(). This patch gets the physnode_mask directly from numa_nodes_parsed. At the same time, it corrects the comment of these two

[PATCH V3 3/3] x86/numa_emulation: restructures numa_nodes_parsed from emulated nodes

By emulating numa, it may contains more or less nodes than physical nodes. In numa_emulation(), numa_meminfo/numa_distance/__apicid_to_node is restructured according to emulated nodes, except numa_nodes_parsed. This patch restructures numa_nodes_parsed from emulated nodes. Signed-off-by: Wei

[PATCH] video: cobalt_lcdfb: constify fb_fix_screeninfo structure

This structure is only used to copy into other structures, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct fb_fix_screeninfo i@p = { ... }; @ok@ identifier r.i;

[PATCH] video: cobalt_lcdfb: constify fb_fix_screeninfo structure

This structure is only used to copy into other structures, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct fb_fix_screeninfo i@p = { ... }; @ok@ identifier r.i;

[PATCH] video: xilinxfb: constify fb_fix_screeninfo and fb_var_screeninfo structures

These structures are only used to copy into other structures, so declare them as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct fb_fix_screeninfo i@p = { ... }; @ok@ identifier r.i;

[PATCH] video: xilinxfb: constify fb_fix_screeninfo and fb_var_screeninfo structures

These structures are only used to copy into other structures, so declare them as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct fb_fix_screeninfo i@p = { ... }; @ok@ identifier r.i;

[PATCH] video/chips: constify fb_fix_screeninfo and fb_var_screeninfo structures

These structures are only used to copy into other structures, so declare them as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct fb_fix_screeninfo i@p = { ... }; @ok@ identifier r.i;

[PATCH] video/chips: constify fb_fix_screeninfo and fb_var_screeninfo structures

These structures are only used to copy into other structures, so declare them as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct fb_fix_screeninfo i@p = { ... }; @ok@ identifier r.i;

Re: [PATCH v5 3/5] mtd: handle partitioning on devices with 0 erasesize

On Tue, Jul 04, 2017 at 03:22:52AM +, Chris Packham wrote: > I had someone mention to me in passing that mtdinfo was failing for them > (crashing with some floating point error). I'm wondering if we've > created a divide-by-zero problem by reporting 0 erase size in /proc/mtd. > I don't have

Re: [PATCH v5 3/5] mtd: handle partitioning on devices with 0 erasesize

On Tue, Jul 04, 2017 at 03:22:52AM +, Chris Packham wrote: > I had someone mention to me in passing that mtdinfo was failing for them > (crashing with some floating point error). I'm wondering if we've > created a divide-by-zero problem by reporting 0 erase size in /proc/mtd. > I don't have

[PATCH] video/mbx: constify fb_fix_screeninfo and fb_var_screeninfo structures

These structures are only used to copy into other structures, so declare them as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct fb_fix_screeninfo i@p = { ... }; @ok@ identifier r.i;

[PATCH] video/mbx: constify fb_fix_screeninfo and fb_var_screeninfo structures

These structures are only used to copy into other structures, so declare them as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct fb_fix_screeninfo i@p = { ... }; @ok@ identifier r.i;

[GIT PULL] MD update for 4.13

Hi, Please pull MD update for 4.13. This update only includes several bug fixes: - Neil Brown fixes a deadlock in MD suspend and a potential bug in bio allocation. - Mikulas Patocka fixes a signal issue - Guoqing Jiang fixes a typo in FailFast test - Other trival fixes Please note, there is a

[GIT PULL] MD update for 4.13

Hi, Please pull MD update for 4.13. This update only includes several bug fixes: - Neil Brown fixes a deadlock in MD suspend and a potential bug in bio allocation. - Mikulas Patocka fixes a signal issue - Guoqing Jiang fixes a typo in FailFast test - Other trival fixes Please note, there is a

[PATCH] auxdisplay: cfag12864bfb: constify fb_fix_screeninfo and fb_var_screeninfo structures

These structures are only used to copy into other structures, so declare them as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct fb_fix_screeninfo i@p = { ... }; @ok@ identifier r.i;

[PATCH] auxdisplay: cfag12864bfb: constify fb_fix_screeninfo and fb_var_screeninfo structures

These structures are only used to copy into other structures, so declare them as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct fb_fix_screeninfo i@p = { ... }; @ok@ identifier r.i;

  1   2   3   4   5   6   7   8   9   10   >