[PATCH] kernfs: Check KERNFS_HAS_RELEASE before calling kernfs_release_file()

Recently started seeing a kernel oops when a module tries removing a memory mapped sysfs bin_attribute. On closer investigation the root cause seems to be kernfs_release_file() trying to call kernfs_op.release() callback that's NULL for such sysfs bin_attributes. The oops occurs when

[PATCH] kernfs: Check KERNFS_HAS_RELEASE before calling kernfs_release_file()

Recently started seeing a kernel oops when a module tries removing a memory mapped sysfs bin_attribute. On closer investigation the root cause seems to be kernfs_release_file() trying to call kernfs_op.release() callback that's NULL for such sysfs bin_attributes. The oops occurs when

Re: [PATCH net-next 02/12] net: phy: bcm7xxx: add support for 28nm EPHY

On Mon, Mar 13, 2017 at 07:06:25PM -0700, Doug Berger wrote: > On 03/13/2017 06:06 PM, Andrew Lunn wrote: > > On Mon, Mar 13, 2017 at 05:41:32PM -0700, Doug Berger wrote: > >> +static int bcm7xxx_28nm_ephy_01_afe_config_init(struct phy_device *phydev) > >> +{ > >> + int ret; > >> + > >> + /* set

Re: [PATCH net-next 02/12] net: phy: bcm7xxx: add support for 28nm EPHY

On Mon, Mar 13, 2017 at 07:06:25PM -0700, Doug Berger wrote: > On 03/13/2017 06:06 PM, Andrew Lunn wrote: > > On Mon, Mar 13, 2017 at 05:41:32PM -0700, Doug Berger wrote: > >> +static int bcm7xxx_28nm_ephy_01_afe_config_init(struct phy_device *phydev) > >> +{ > >> + int ret; > >> + > >> + /* set

Re: [PATCH] drm/radeon: Fix GPU lockups for the R7 M270

On 03/14/2017 01:00 AM, Alex Deucher wrote: > Does your kernel have this patch: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef736d394e85b1bf1fd65ba5e5257b85f6c82325 Yes, my kernel has this patch (this issue first occurred in v4.10). -- Cheers, Umang

Re: [PATCH] drm/radeon: Fix GPU lockups for the R7 M270

On 03/14/2017 01:00 AM, Alex Deucher wrote: > Does your kernel have this patch: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef736d394e85b1bf1fd65ba5e5257b85f6c82325 Yes, my kernel has this patch (this issue first occurred in v4.10). -- Cheers, Umang

Re: [BUG] 4.11.0-rc1 panic on shutdown X61s

On Tue, Mar 14, 2017 at 01:20:27AM +, Brown, Aaron F wrote: > > Borislav Petkov writes: > > > On Sun, Mar 12, 2017 at 03:55:08PM +0200, Andy Shevchenko wrote: > > > > > >> The only change that IMHO matters happened between v4.10 and v4.11- > > rc1 is this: > > >> > > >> @@

Re: [BUG] 4.11.0-rc1 panic on shutdown X61s

On Tue, Mar 14, 2017 at 01:20:27AM +, Brown, Aaron F wrote: > > Borislav Petkov writes: > > > On Sun, Mar 12, 2017 at 03:55:08PM +0200, Andy Shevchenko wrote: > > > > > >> The only change that IMHO matters happened between v4.10 and v4.11- > > rc1 is this: > > >> > > >> @@ -6276,8 +6274,8 @@

Re: [PATCH] scsi: storvsc: Add support for FC rport.

> "Cathy" == Cathy Avery writes: Hi Cathy, Cathy> I haven't received any feedback yet. Cathy> Should I resend? You sent this right at the beginning of the merge window. That almost guarantees that nobody will have time to look at it. Whereas now is a good time to send

Re: [PATCH] scsi: storvsc: Add support for FC rport.

> "Cathy" == Cathy Avery writes: Hi Cathy, Cathy> I haven't received any feedback yet. Cathy> Should I resend? You sent this right at the beginning of the merge window. That almost guarantees that nobody will have time to look at it. Whereas now is a good time to send submissions for

Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces

Hi Vineet, On Mon, 13 Mar 2017, Vineet Gupta wrote: > I've not looked at the patches closely (or read the references paper fully > yet), > but at first glance it seems on ARC architecture, we can can potentially > use/leverage this mechanism to implement the shared TLB entries. Before anyone >

Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces

Hi Vineet, On Mon, 13 Mar 2017, Vineet Gupta wrote: > I've not looked at the patches closely (or read the references paper fully > yet), > but at first glance it seems on ARC architecture, we can can potentially > use/leverage this mechanism to implement the shared TLB entries. Before anyone >

Re: [PATCH] engine: mv_xor: remove redundant null check on cd

On Wed, Mar 01, 2017 at 02:07:21PM +, Colin King wrote: > From: Colin Ian King > > The check to see if cd is null is redundant, pdata->channels is > never null at this point, and hence >channels[i] cannot > be null, so remove the null check. > > Detected by

Re: [PATCH] engine: mv_xor: remove redundant null check on cd

On Wed, Mar 01, 2017 at 02:07:21PM +, Colin King wrote: > From: Colin Ian King > > The check to see if cd is null is redundant, pdata->channels is > never null at this point, and hence >channels[i] cannot > be null, so remove the null check. > > Detected by CoverityScan, CID#1357194

Re: [PATCH] serial: 8250_dw: Fix breakage when HAVE_CLK=n

On Mon, Mar 13, 2017 at 11:14:07AM +, James Hogan wrote: > Hi Greg, > > On Sat, Mar 04, 2017 at 01:09:58PM +, James Hogan wrote: > > Commit 6a171b299379 ("serial: 8250_dw: Allow hardware flow control to be > > used") recently broke the 8250_dw driver on platforms which don't select > >

Re: [PATCH] serial: 8250_dw: Fix breakage when HAVE_CLK=n

On Mon, Mar 13, 2017 at 11:14:07AM +, James Hogan wrote: > Hi Greg, > > On Sat, Mar 04, 2017 at 01:09:58PM +, James Hogan wrote: > > Commit 6a171b299379 ("serial: 8250_dw: Allow hardware flow control to be > > used") recently broke the 8250_dw driver on platforms which don't select > >

Re: [lkp-robot] [f2fs] 4ac912427c: -33.7% aim7.jobs-per-min regression

On 03/14, Chao Yu wrote: >On 2017/3/14 3:22, Jaegeuk Kim wrote: >> On 03/13, Thorsten Leemhuis wrote: >>> @Chao Yu/@Jaegeuk Kim: I'm considering to add this to the regressions >>> report for 4.11; or is there a reason why it shouldn't be considered a >>> regression? Ciao, Thorsten >> >> Hi, >>

Re: [lkp-robot] [f2fs] 4ac912427c: -33.7% aim7.jobs-per-min regression

On 03/14, Chao Yu wrote: >On 2017/3/14 3:22, Jaegeuk Kim wrote: >> On 03/13, Thorsten Leemhuis wrote: >>> @Chao Yu/@Jaegeuk Kim: I'm considering to add this to the regressions >>> report for 4.11; or is there a reason why it shouldn't be considered a >>> regression? Ciao, Thorsten >> >> Hi, >>

Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

Thank you for your very helpful answer. I really do appreciate it. It's possible that this device is using high speed because it offers a feature to transfer its internal clipboard to the host, and it allows that clipboard to contain lots of data. Interestingly, though, hidden within a usage

Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

Thank you for your very helpful answer. I really do appreciate it. It's possible that this device is using high speed because it offers a feature to transfer its internal clipboard to the host, and it allows that clipboard to contain lots of data. Interestingly, though, hidden within a usage

Re: [PATCH] perf report: show sort_order in title

On Mon, Mar 13, 2017 at 11:57:18AM -0300, Arnaldo Carvalho de Melo wrote: > > I'll just rename this to use the tools/perf/ style for such functions, > > making it: > > > > static int hists__scnprintf_sort_fields(hists, buf, size) > > But then, while testing, > > Before: > > $ perf

Re: [PATCH] perf report: show sort_order in title

On Mon, Mar 13, 2017 at 11:57:18AM -0300, Arnaldo Carvalho de Melo wrote: > > I'll just rename this to use the tools/perf/ style for such functions, > > making it: > > > > static int hists__scnprintf_sort_fields(hists, buf, size) > > But then, while testing, > > Before: > > $ perf

Re: [PATCH] usbnet: smsc95xx: Reduce logging noise

On 03/13/2017 03:32 PM, David Miller wrote: From: Guenter Roeck Date: Fri, 10 Mar 2017 17:45:21 -0800 An insert/remove stress test generated the following log message sequence. ... Use netdev_dbg() instead of netdev_warn() for the repeating messages to reduce logging

Re: [PATCH] usbnet: smsc95xx: Reduce logging noise

On 03/13/2017 03:32 PM, David Miller wrote: From: Guenter Roeck Date: Fri, 10 Mar 2017 17:45:21 -0800 An insert/remove stress test generated the following log message sequence. ... Use netdev_dbg() instead of netdev_warn() for the repeating messages to reduce logging noise. Signed-off-by:

[PATCH 2/2 V2] staging: dgnc: remove useless switch-case statements

The dgnc_tty_send_break() has a switch-case condition for msec. It is no use except case -1. Signed-off-by: Daeseok Youn --- V2: The two patches in previous series are merged into one patch. drivers/staging/dgnc/dgnc_tty.c | 10 +- 1 file changed, 1

[PATCH 2/2 V2] staging: dgnc: remove useless switch-case statements

The dgnc_tty_send_break() has a switch-case condition for msec. It is no use except case -1. Signed-off-by: Daeseok Youn --- V2: The two patches in previous series are merged into one patch. drivers/staging/dgnc/dgnc_tty.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff

Re: [lkp-robot] [f2fs] 4ac912427c: -33.7% aim7.jobs-per-min regression

On 2017/3/14 3:22, Jaegeuk Kim wrote: > On 03/13, Thorsten Leemhuis wrote: >> @Chao Yu/@Jaegeuk Kim: I'm considering to add this to the regressions >> report for 4.11; or is there a reason why it shouldn't be considered a >> regression? Ciao, Thorsten > > Hi, > > I'm planning to submit f2fs

Re: [lkp-robot] [f2fs] 4ac912427c: -33.7% aim7.jobs-per-min regression

On 2017/3/14 3:22, Jaegeuk Kim wrote: > On 03/13, Thorsten Leemhuis wrote: >> @Chao Yu/@Jaegeuk Kim: I'm considering to add this to the regressions >> report for 4.11; or is there a reason why it shouldn't be considered a >> regression? Ciao, Thorsten > > Hi, > > I'm planning to submit f2fs

[PATCH 1/2 V2] staging: dgnc: ch->ch_bd is already assigned to bd variable

The bd variables in functions are already assigned from ch->ch_bd but it is not used in those functions except checking NULL. The ch->ch_bd could be replaced with bd variable. Signed-off-by: Daeseok Youn --- V2: Patches in previous series are splited but it could be

[PATCH 1/2 V2] staging: dgnc: ch->ch_bd is already assigned to bd variable

The bd variables in functions are already assigned from ch->ch_bd but it is not used in those functions except checking NULL. The ch->ch_bd could be replaced with bd variable. Signed-off-by: Daeseok Youn --- V2: Patches in previous series are splited but it could be merged into one. There are

RE: [Intel-wired-lan] [PATCH] net: intel: ixgb: use new api ethtool_{get|set}_link_ksettings

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Philippe Reynes > Sent: Sunday, February 5, 2017 3:11 PM > To: Kirsher, Jeffrey T ; da...@davemloft.net > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux- >

RE: [Intel-wired-lan] [PATCH] net: intel: ixgb: use new api ethtool_{get|set}_link_ksettings

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Philippe Reynes > Sent: Sunday, February 5, 2017 3:11 PM > To: Kirsher, Jeffrey T ; da...@davemloft.net > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux- > ker...@vger.kernel.org; Philippe

[x86/kasan] 1771c6e1a5 BUG: KASAN: slab-out-of-bounds in memdup_user at addr ffff8800001f3940

Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 1771c6e1a567ea0ba20a4ffe68a1419fd8ef Author: Andrey Ryabinin AuthorDate: Fri May 20 16:59:31

[x86/kasan] 1771c6e1a5 BUG: KASAN: slab-out-of-bounds in memdup_user at addr ffff8800001f3940

Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 1771c6e1a567ea0ba20a4ffe68a1419fd8ef Author: Andrey Ryabinin AuthorDate: Fri May 20 16:59:31 2016 -0700 Commit:

Re: [PATCH net-next 02/12] net: phy: bcm7xxx: add support for 28nm EPHY

On 03/13/2017 06:06 PM, Andrew Lunn wrote: > On Mon, Mar 13, 2017 at 05:41:32PM -0700, Doug Berger wrote: >> +static int bcm7xxx_28nm_ephy_01_afe_config_init(struct phy_device *phydev) >> +{ >> +int ret; >> + >> +/* set shadow mode 2 */ >> +ret = phy_set_clr_bits(phydev,

Re: [PATCH net-next 02/12] net: phy: bcm7xxx: add support for 28nm EPHY

On 03/13/2017 06:06 PM, Andrew Lunn wrote: > On Mon, Mar 13, 2017 at 05:41:32PM -0700, Doug Berger wrote: >> +static int bcm7xxx_28nm_ephy_01_afe_config_init(struct phy_device *phydev) >> +{ >> +int ret; >> + >> +/* set shadow mode 2 */ >> +ret = phy_set_clr_bits(phydev,

Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On 14 March 2017 at 09:10, Jun Li wrote: > Hi, > >> -Original Message- >> From: Baolin Wang [mailto:baolin.w...@linaro.org] >> Sent: Monday, March 13, 2017 4:44 PM >> To: Jun Li >> Cc: NeilBrown ; Felipe Balbi ; Greg KH >>

Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On 14 March 2017 at 09:10, Jun Li wrote: > Hi, > >> -Original Message- >> From: Baolin Wang [mailto:baolin.w...@linaro.org] >> Sent: Monday, March 13, 2017 4:44 PM >> To: Jun Li >> Cc: NeilBrown ; Felipe Balbi ; Greg KH >> ; Sebastian Reichel ; Dmitry >> Eremin-Solenikov ; David

[PATCH] lockdep: call time_hardirqs_off after clearing hardirqs_enabled

The current order of calls within trace_hardirqs_off_caller() would provoke an "unannotated irqs-off" WARNING. This warning was reported by check_flags() when it found that the hardirqs has been disabled but the irq-flags state, "hardirqs_enabled", has not been cleared. Check_flags() is called

[PATCH] lockdep: call time_hardirqs_off after clearing hardirqs_enabled

The current order of calls within trace_hardirqs_off_caller() would provoke an "unannotated irqs-off" WARNING. This warning was reported by check_flags() when it found that the hardirqs has been disabled but the irq-flags state, "hardirqs_enabled", has not been cleared. Check_flags() is called

Re: [tip:perf/urgent] perf/core: Fix the perf_cpu_time_max_percent check

On 2017/3/14 2:35, Vince Weaver wrote: > On Sat, 25 Feb 2017, Peter Zijlstra wrote: > >> On Sat, Feb 25, 2017 at 04:10:37PM +0800, Tan Xiaojun wrote: >> >>> 2)If it is, where we will fix it more appropriate, perf_fuzzer(not set >>> 0 or 100) or kernel(limit 1 to 99), or maybe it is the bug of >>>

[PATCH] perf sched timehist: Add --next option

The --next option shows the next task for each context switch, providing more context for the sequence of scheduler events. $ perf sched timehist --next | head Samples do not have callchains. timecpu task name wait time sch delay run time

Re: [tip:perf/urgent] perf/core: Fix the perf_cpu_time_max_percent check

On 2017/3/14 2:35, Vince Weaver wrote: > On Sat, 25 Feb 2017, Peter Zijlstra wrote: > >> On Sat, Feb 25, 2017 at 04:10:37PM +0800, Tan Xiaojun wrote: >> >>> 2)If it is, where we will fix it more appropriate, perf_fuzzer(not set >>> 0 or 100) or kernel(limit 1 to 99), or maybe it is the bug of >>>

[PATCH] perf sched timehist: Add --next option

The --next option shows the next task for each context switch, providing more context for the sequence of scheduler events. $ perf sched timehist --next | head Samples do not have callchains. timecpu task name wait time sch delay run time

RE: [Intel-wired-lan] [PATCH] net: intel: igbvf: use new api ethtool_{get|set}_link_ksettings

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Philippe Reynes > Sent: Sunday, February 5, 2017 2:55 PM > To: Kirsher, Jeffrey T ; da...@davemloft.net > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux- >

RE: [Intel-wired-lan] [PATCH] net: intel: igbvf: use new api ethtool_{get|set}_link_ksettings

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Philippe Reynes > Sent: Sunday, February 5, 2017 2:55 PM > To: Kirsher, Jeffrey T ; da...@davemloft.net > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux- > ker...@vger.kernel.org; Philippe

Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

On Mon, 13 Mar 2017, Samuel Thibault wrote: > Alan Stern, on dim. 12 mars 2017 21:40:33 -0400, wrote: > > On Sun, 12 Mar 2017, Dave Mielke wrote: > > > [quoted lines by Alan Stern on 2017/03/12 at 21:31 -0400] > > > > > > >A device's speed is only partially related to its USB version. A > > >

Re: [PATCH 3/3] staging: dngc: ch->ch_bd is already assigned to bd variable

2017-03-14 7:26 GMT+09:00 Greg KH : > On Sun, Mar 12, 2017 at 11:47:28PM +0900, Daeseok Youn wrote: >> The bd variable in dgnc_tty_digiseta() is assigned with >> ch->ch_bd but it is not used in this function except checking NULL. >> The ch->ch_bd could be replaced with

Re: [PATCH 3/3] staging: dngc: ch->ch_bd is already assigned to bd variable

2017-03-14 7:26 GMT+09:00 Greg KH : > On Sun, Mar 12, 2017 at 11:47:28PM +0900, Daeseok Youn wrote: >> The bd variable in dgnc_tty_digiseta() is assigned with >> ch->ch_bd but it is not used in this function except checking NULL. >> The ch->ch_bd could be replaced with bd variable in

Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

On Mon, 13 Mar 2017, Samuel Thibault wrote: > Alan Stern, on dim. 12 mars 2017 21:40:33 -0400, wrote: > > On Sun, 12 Mar 2017, Dave Mielke wrote: > > > [quoted lines by Alan Stern on 2017/03/12 at 21:31 -0400] > > > > > > >A device's speed is only partially related to its USB version. A > > >

RE: [Intel-wired-lan] [PATCH] net: intel: igb: use new api ethtool_{get|set}_link_ksettings

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Philippe Reynes > Sent: Sunday, February 5, 2017 9:56 AM > To: Kirsher, Jeffrey T ; da...@davemloft.net > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux- >

RE: [Intel-wired-lan] [PATCH] net: intel: igb: use new api ethtool_{get|set}_link_ksettings

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Philippe Reynes > Sent: Sunday, February 5, 2017 9:56 AM > To: Kirsher, Jeffrey T ; da...@davemloft.net > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux- > ker...@vger.kernel.org; Philippe

Re: [BUG] 4.11.0-rc1 panic on shutdown X61s

On Tue, Mar 14, 2017 at 01:20:27AM +, Brown, Aaron F wrote: > Believe it or not we actually do test these changes. This one was > tested by me and I did not have the same results you and the other > people reporting this trace did. I made it back in the lab today and > have spent a good part

Re: [BUG] 4.11.0-rc1 panic on shutdown X61s

On Tue, Mar 14, 2017 at 01:20:27AM +, Brown, Aaron F wrote: > Believe it or not we actually do test these changes. This one was > tested by me and I did not have the same results you and the other > people reporting this trace did. I made it back in the lab today and > have spent a good part

Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

On Sun, 12 Mar 2017, Dave Mielke wrote: > [quoted lines by Alan Stern on 2017/03/12 at 21:40 -0400] > > >No, I was wondering why an HID device would run at high speed. Both > >you and Samuel implied that this was because it was a USB-2 device. > >But that is not an adequate answer, because it

Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

On Sun, 12 Mar 2017, Dave Mielke wrote: > [quoted lines by Alan Stern on 2017/03/12 at 21:40 -0400] > > >No, I was wondering why an HID device would run at high speed. Both > >you and Samuel implied that this was because it was a USB-2 device. > >But that is not an adequate answer, because it

Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces

+CC Ingo, tglx Hi Till, On 03/13/2017 03:14 PM, Till Smejkal wrote: > Introduce a different type of address spaces which are first class citizens > in the OS. That means that the kernel now handles two types of AS, those > which are closely coupled with a process and those which aren't. While

Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces

+CC Ingo, tglx Hi Till, On 03/13/2017 03:14 PM, Till Smejkal wrote: > Introduce a different type of address spaces which are first class citizens > in the OS. That means that the kernel now handles two types of AS, those > which are closely coupled with a process and those which aren't. While

Re: Synaptics RMI4 touchpad regression in 4.11-rc1

On 03/13/2017 06:15 AM, Benjamin Tissoires wrote: [Resending, forgot to add Jiri in CC] On Mar 13 2017 or thereabouts, Benjamin Tissoires wrote: On Mar 13 2017 or thereabouts, Thorsten Leemhuis wrote: Lo! On 12.03.2017 02:55, Cameron Gutman wrote: Beginning in 4.11-rc1, it looks like RMI4

Re: Synaptics RMI4 touchpad regression in 4.11-rc1

On 03/13/2017 06:15 AM, Benjamin Tissoires wrote: [Resending, forgot to add Jiri in CC] On Mar 13 2017 or thereabouts, Benjamin Tissoires wrote: On Mar 13 2017 or thereabouts, Thorsten Leemhuis wrote: Lo! On 12.03.2017 02:55, Cameron Gutman wrote: Beginning in 4.11-rc1, it looks like RMI4

Re: [f2fs-dev] [PATCH] f2fs: cover update_free_nid_bitmap with free_list_lock

On 2017/3/14 3:57, Jaegeuk Kim wrote: > On 03/13, Kinglong Mee wrote: >> On 3/13/2017 20:10, Chao Yu wrote: >>> free_nid_bitmap and free_nid_count in update_free_nid_bitmap should be >>> updated atomically, use free_list_lock cover them to avoid race in >> >> nid_list_lock? > > Think so. > I

Re: [f2fs-dev] [PATCH] f2fs: cover update_free_nid_bitmap with free_list_lock

On 2017/3/14 3:57, Jaegeuk Kim wrote: > On 03/13, Kinglong Mee wrote: >> On 3/13/2017 20:10, Chao Yu wrote: >>> free_nid_bitmap and free_nid_count in update_free_nid_bitmap should be >>> updated atomically, use free_list_lock cover them to avoid race in >> >> nid_list_lock? > > Think so. > I

[PATCH 1/2] Fix V8 device information issue

From: Masaki Ota -Fix the issue that V8(E7=73 03 28) devices are not assined correct device information bit from OTP. -Specified correct OTP bit for the V8 device setting of Button pad, DualPoint and Touchpad size. -Deleted extra code from alps_v8_protocol_data decision

[PATCH 2/2] Fix the issue that V8 Button pad Stick button does not work

From: Masaki Ota - V8 Button pad Stick Right and Middle button don't work. - Alps stick devices have physical buttons absolutely, so delete "ALPS_BUTTONPAD" check Flag from Stick button process. Signed-off-by: Masaki Ota Acked-by: Pali Rohar

[PATCH 1/2] Fix V8 device information issue

From: Masaki Ota -Fix the issue that V8(E7=73 03 28) devices are not assined correct device information bit from OTP. -Specified correct OTP bit for the V8 device setting of Button pad, DualPoint and Touchpad size. -Deleted extra code from alps_v8_protocol_data decision process. Signed-off-by:

[PATCH 2/2] Fix the issue that V8 Button pad Stick button does not work

From: Masaki Ota - V8 Button pad Stick Right and Middle button don't work. - Alps stick devices have physical buttons absolutely, so delete "ALPS_BUTTONPAD" check Flag from Stick button process. Signed-off-by: Masaki Ota Acked-by: Pali Rohar --- drivers/input/mouse/alps.c | 6 ++ 1 file

Re: [PATCH] lockdep: call trace_hardirqs_off after clearing hardirqs_enabled

On 2017年03月13日 22:05, Steven Rostedt wrote: On Mon, 13 Mar 2017 18:08:48 +0800 Qi Hou wrote: The current order of calls within trace_hardirqs_off() would provoke an "unannotated irqs-off" WARNING. This warning was reported by check_flags() when it found that the

Re: [PATCH] lockdep: call trace_hardirqs_off after clearing hardirqs_enabled

On 2017年03月13日 22:05, Steven Rostedt wrote: On Mon, 13 Mar 2017 18:08:48 +0800 Qi Hou wrote: The current order of calls within trace_hardirqs_off() would provoke an "unannotated irqs-off" WARNING. This warning was reported by check_flags() when it found that the hardirqs has been disabled

Re: [RESEND] drm/exynos: Remove support for Exynos4415 (SoC not supported anymore)

Merged. Thanks. 2017년 03월 12일 03:04에 Krzysztof Kozlowski 이(가) 쓴 글: > Support for Exynos4415 is going away because there are no internal nor > external users. > > Since commit 46dcf0ff0de3 ("ARM: dts: exynos: Remove exynos4415.dtsi"), > the platform cannot be instantiated so remove also the

Re: [RESEND] drm/exynos: Remove support for Exynos4415 (SoC not supported anymore)

Merged. Thanks. 2017년 03월 12일 03:04에 Krzysztof Kozlowski 이(가) 쓴 글: > Support for Exynos4415 is going away because there are no internal nor > external users. > > Since commit 46dcf0ff0de3 ("ARM: dts: exynos: Remove exynos4415.dtsi"), > the platform cannot be instantiated so remove also the

RE: [BUG] 4.11.0-rc1 panic on shutdown X61s

> From: Bjørn Mork [mailto:bj...@mork.no] > Sent: Monday, March 13, 2017 9:46 AM > To: Borislav Petkov > Cc: Andy Shevchenko ; l...@pengaru.com; > linux-kernel ; vcap...@pengaru.com; linux- > p...@vger.kernel.org;

RE: [BUG] 4.11.0-rc1 panic on shutdown X61s

> From: Bjørn Mork [mailto:bj...@mork.no] > Sent: Monday, March 13, 2017 9:46 AM > To: Borislav Petkov > Cc: Andy Shevchenko ; l...@pengaru.com; > linux-kernel ; vcap...@pengaru.com; linux- > p...@vger.kernel.org; intel-wired-...@lists.osuosl.org; khalidm > ; David Singleton ; Brown, Aaron > F ;

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Samuel Thibault, on mar. 14 mars 2017 01:47:01 +0100, wrote: > Greg KH, on mar. 14 mars 2017 06:14:04 +0800, wrote: > > On Mon, Mar 13, 2017 at 10:05:51PM +, okash.khaw...@gmail.com wrote: > > > This patchset introduces a TTY-based way for the synths to communicate > > > with devices as an

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Samuel Thibault, on mar. 14 mars 2017 01:47:01 +0100, wrote: > Greg KH, on mar. 14 mars 2017 06:14:04 +0800, wrote: > > On Mon, Mar 13, 2017 at 10:05:51PM +, okash.khaw...@gmail.com wrote: > > > This patchset introduces a TTY-based way for the synths to communicate > > > with devices as an

Re: [PATCH v4 0/5] perf report: Show inline stack

Hi, Any comments for this v4 patch series? Thanks Jin Yao On 3/3/2017 6:43 PM, Jin Yao wrote: v4: Remove the options "--inline-line" and "--inline-name". Just use a new option "--inline" to print the inline function information. The policy is if the inline function name can be

Re: [PATCH v4 0/5] perf report: Show inline stack

Hi, Any comments for this v4 patch series? Thanks Jin Yao On 3/3/2017 6:43 PM, Jin Yao wrote: v4: Remove the options "--inline-line" and "--inline-name". Just use a new option "--inline" to print the inline function information. The policy is if the inline function name can be

Re: [PATCH] staging: atomisp: use k{v}zalloc instead of k{v}alloc and memset

2017-03-14 2:54 GMT+09:00 Alan Cox : > > On Mon, 2017-03-13 at 19:54 +0900, Daeseok Youn wrote: > > If the atomisp_kernel_zalloc() has "true" as a second parameter, it > > tries to allocate zeroing memory from kmalloc(vmalloc) and memset. > > But using kzalloc is rather than

Re: [PATCH] staging: atomisp: use k{v}zalloc instead of k{v}alloc and memset

2017-03-14 2:54 GMT+09:00 Alan Cox : > > On Mon, 2017-03-13 at 19:54 +0900, Daeseok Youn wrote: > > If the atomisp_kernel_zalloc() has "true" as a second parameter, it > > tries to allocate zeroing memory from kmalloc(vmalloc) and memset. > > But using kzalloc is rather than kmalloc followed by

[GIT PULL] Please pull powerpc/linux.git powerpc-4.11-4 tag

Hi Linus, Please pull some more powerpc fixes for 4.11. The bulk of the diffstat is the Power9 Machine Check handler. It's bigger than I'd usually send after rc2, but apparently folks are hitting them in the field, and it's from Nick. This also includes the fix for macio devices that was sent

[GIT PULL] Please pull powerpc/linux.git powerpc-4.11-4 tag

Hi Linus, Please pull some more powerpc fixes for 4.11. The bulk of the diffstat is the Power9 Machine Check handler. It's bigger than I'd usually send after rc2, but apparently folks are hitting them in the field, and it's from Nick. This also includes the fix for macio devices that was sent

Re: [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new,free}

Hi Brian > > The crasher was snd_dmaengine_pcm_register's platform ? > > No, actually it wasn't. It was spi2.0, which was a dummy, from > snd_soc_dummy_probe(). But somehow snd_soc_platform_drv_pcm_new() got > called for it... Hmm.. I couldn't reproduce your issue on my system with dummy

Re: [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new,free}

Hi Brian > > The crasher was snd_dmaengine_pcm_register's platform ? > > No, actually it wasn't. It was spi2.0, which was a dummy, from > snd_soc_dummy_probe(). But somehow snd_soc_platform_drv_pcm_new() got > called for it... Hmm.. I couldn't reproduce your issue on my system with dummy

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

Hi, > -Original Message- > From: Baolin Wang [mailto:baolin.w...@linaro.org] > Sent: Monday, March 13, 2017 4:44 PM > To: Jun Li > Cc: NeilBrown ; Felipe Balbi ; Greg KH > ; Sebastian Reichel ;

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

Hi, > -Original Message- > From: Baolin Wang [mailto:baolin.w...@linaro.org] > Sent: Monday, March 13, 2017 4:44 PM > To: Jun Li > Cc: NeilBrown ; Felipe Balbi ; Greg KH > ; Sebastian Reichel ; Dmitry > Eremin-Solenikov ; David Woodhouse > ; r...@kernel.org; Marek Szyprowski > ; Ruslan

Re: [PATCH net-next 02/12] net: phy: bcm7xxx: add support for 28nm EPHY

On Mon, Mar 13, 2017 at 05:41:32PM -0700, Doug Berger wrote: > +static int bcm7xxx_28nm_ephy_01_afe_config_init(struct phy_device *phydev) > +{ > + int ret; > + > + /* set shadow mode 2 */ > + ret = phy_set_clr_bits(phydev, MII_BCM7XXX_TEST, > +

Re: [PATCH net-next 02/12] net: phy: bcm7xxx: add support for 28nm EPHY

On Mon, Mar 13, 2017 at 05:41:32PM -0700, Doug Berger wrote: > +static int bcm7xxx_28nm_ephy_01_afe_config_init(struct phy_device *phydev) > +{ > + int ret; > + > + /* set shadow mode 2 */ > + ret = phy_set_clr_bits(phydev, MII_BCM7XXX_TEST, > +

Re: [PATCH net-next 12/12] net: bcmgenet: add support for the GENETv5 hardware

On 03/13/2017 05:41 PM, Doug Berger wrote: > This commit adds support for the GENETv5 implementation. > > The GENETv5 reports a major version of 6 instead of 5 so compensate > for this when verifying the configuration of the driver. Also the > EPHY revision is now contained in the MDIO registers

Re: [PATCH net-next 12/12] net: bcmgenet: add support for the GENETv5 hardware

On 03/13/2017 05:41 PM, Doug Berger wrote: > This commit adds support for the GENETv5 implementation. > > The GENETv5 reports a major version of 6 instead of 5 so compensate > for this when verifying the configuration of the driver. Also the > EPHY revision is now contained in the MDIO registers

Re: [PATCH net-next 11/12] dt-bindings: net: update bcmgenet binding for GENETv5

On 03/13/2017 05:41 PM, Doug Berger wrote: > The device tree documentation must be updated to reflect the new compatible > strings "brcm,genet-v5" and "brcm,genet-mdio-v5" used by the GENETv5 driver. > > Signed-off-by: Doug Berger Reviewed-by: Florian Fainelli

Re: [PATCH net-next 11/12] dt-bindings: net: update bcmgenet binding for GENETv5

On 03/13/2017 05:41 PM, Doug Berger wrote: > The device tree documentation must be updated to reflect the new compatible > strings "brcm,genet-v5" and "brcm,genet-mdio-v5" used by the GENETv5 driver. > > Signed-off-by: Doug Berger Reviewed-by: Florian Fainelli -- Florian

Re: [PATCH net-next 10/12] dt-bindings: net: document bcmgenet WoL interrupt

On 03/13/2017 05:41 PM, Doug Berger wrote: > A third interrupt cell can be provided to optionally specify > the interrupt used for handling Wake on LAN events. > > Typically the wake up handling uses a separate interrupt > controller, so the interrupts-extended property is used to > accommodate

Re: [PATCH net-next 10/12] dt-bindings: net: document bcmgenet WoL interrupt

On 03/13/2017 05:41 PM, Doug Berger wrote: > A third interrupt cell can be provided to optionally specify > the interrupt used for handling Wake on LAN events. > > Typically the wake up handling uses a separate interrupt > controller, so the interrupts-extended property is used to > accommodate

Re: [PATCH net-next 09/12] net: bcmgenet: return EOPNOTSUPP for unknown ioctl commands

On 03/13/2017 05:41 PM, Doug Berger wrote: > This commit changes the ioctl handling behavior to return the > EOPNOTSUPP error code instead of the EINVAL error code when an > unknown ioctl command value is detected. > > It also removes some redundant parsing of the ioctl command value > and allows

Re: [PATCH net-next 09/12] net: bcmgenet: return EOPNOTSUPP for unknown ioctl commands

On 03/13/2017 05:41 PM, Doug Berger wrote: > This commit changes the ioctl handling behavior to return the > EOPNOTSUPP error code instead of the EINVAL error code when an > unknown ioctl command value is detected. > > It also removes some redundant parsing of the ioctl command value > and allows

Re: [PATCH net-next 08/12] net: bcmgenet: correct return value of __bcmgenet_tx_reclaim

On 03/13/2017 05:41 PM, Doug Berger wrote: > The reclaim function should return the number of buffer descriptors > reclaimed, not just the number corresponding to skb packets. > > Also, remove the unnecessary computation when updating the consumer > index. > > While this is not a functional

Re: [PATCH net-next 08/12] net: bcmgenet: correct return value of __bcmgenet_tx_reclaim

On 03/13/2017 05:41 PM, Doug Berger wrote: > The reclaim function should return the number of buffer descriptors > reclaimed, not just the number corresponding to skb packets. > > Also, remove the unnecessary computation when updating the consumer > index. > > While this is not a functional

Re: [PATCH net-next 07/12] net: bcmgenet: clear status to reduce spurious interrupts

On 03/13/2017 05:41 PM, Doug Berger wrote: > Since the DMA interrupt status is latched and the DMA servicing can be > polled, it is a good idea to clear the latched status of a DMA interrupt > before performing the service that would be invoked by the interrupt. > > This prevents old status from

Re: [PATCH net-next 07/12] net: bcmgenet: clear status to reduce spurious interrupts

On 03/13/2017 05:41 PM, Doug Berger wrote: > Since the DMA interrupt status is latched and the DMA servicing can be > polled, it is a good idea to clear the latched status of a DMA interrupt > before performing the service that would be invoked by the interrupt. > > This prevents old status from

Re: arch/x86/include/asm/pgtable.h:888:2: error: implicit declaration of function 'native_pud_clear'

Hi Dave, On Mon, Mar 13, 2017 at 08:57:54AM -0700, Dave Jiang wrote: Fengguang, I don't believe Andrew has picked up this patch yet: http://marc.info/?l=linux-mm=148883870428812=2 Unless you are seeing issues with that patch. It looks the patch is not in mainline or linux-next yet: % git

Re: [PATCH net-next 06/12] net: bcmgenet: remove handling of wol interrupts from isr0

On 03/13/2017 05:41 PM, Doug Berger wrote: > The bcmgenet_wol_isr() handler performs the necessary processing for > waking from a GENET event. There is no necessary functionality behind > servicing the UMAC_IRQ_MPD_R event in the handling of isr0. Therefore > the code that unmasks and masks this

<    1   2   3   4   5   6   7   8   9   10   >