Re: ERROR: "vring_del_virtqueue" [drivers/misc/mic/vop/vop.ko] undefined!

On Sat, 2016-04-30 at 09:49 -0700, Randy Dunlap wrote: > On 04/18/16 08:05, kbuild test robot wrote: > > Hi Sudeep, > > > > FYI, the error/warning still remains. > > and still happens in linux-next-20160428... > The patch to fix this build failure was posted @ https://lkml.org/lkml/2016/4/5/7

Re: ERROR: "vring_del_virtqueue" [drivers/misc/mic/vop/vop.ko] undefined!

On Sat, 2016-04-30 at 09:49 -0700, Randy Dunlap wrote: > On 04/18/16 08:05, kbuild test robot wrote: > > Hi Sudeep, > > > > FYI, the error/warning still remains. > > and still happens in linux-next-20160428... > The patch to fix this build failure was posted @ https://lkml.org/lkml/2016/4/5/7

Re: [PATCH] rtc: stmp3xxx: check for failure

On Fri, Apr 15, 2016 at 11:07:15PM +0200, Alexandre Belloni wrote: > Hi, > > On 11/04/2016 at 22:03:55 +0530, Sudip Mukherjee wrote : > > stmp3xxx_wdt_register() can fail as platform_device_alloc() or > > platform_device_add() can fail. Lets check for the return value from > > both

Re: [PATCH] rtc: stmp3xxx: check for failure

On Fri, Apr 15, 2016 at 11:07:15PM +0200, Alexandre Belloni wrote: > Hi, > > On 11/04/2016 at 22:03:55 +0530, Sudip Mukherjee wrote : > > stmp3xxx_wdt_register() can fail as platform_device_alloc() or > > platform_device_add() can fail. Lets check for the return value from > > both

Re: [PATCH] watchdog: dw_wdt: dont build for avr32

On Tue, Apr 12, 2016 at 11:01:28AM -0700, Guenter Roeck wrote: > On Tue, Apr 12, 2016 at 05:58:20PM +0300, Andy Shevchenko wrote: > > On Tue, Apr 12, 2016 at 4:39 PM, Sudip Mukherjee > > wrote: > > > On Tuesday 12 April 2016 06:36 PM, Guenter Roeck wrote: > > >> > > >>

Re: [PATCH] watchdog: dw_wdt: dont build for avr32

On Tue, Apr 12, 2016 at 11:01:28AM -0700, Guenter Roeck wrote: > On Tue, Apr 12, 2016 at 05:58:20PM +0300, Andy Shevchenko wrote: > > On Tue, Apr 12, 2016 at 4:39 PM, Sudip Mukherjee > > wrote: > > > On Tuesday 12 April 2016 06:36 PM, Guenter Roeck wrote: > > >> > > >> On 04/11/2016 10:51 PM,

[PATCH v2] usb: renesas_usbhs: fix signed-unsigned return

The return type of usbhsp_setup_pipecfg() was u16 but it was returning a negative value (-EINVAL). Lets have an additional argument which will have pipecfg and just return the status (success or error) as the return from the function. Signed-off-by: Sudip Mukherjee

[PATCH v2] usb: renesas_usbhs: fix signed-unsigned return

The return type of usbhsp_setup_pipecfg() was u16 but it was returning a negative value (-EINVAL). Lets have an additional argument which will have pipecfg and just return the status (success or error) as the return from the function. Signed-off-by: Sudip Mukherjee --- v2: added pipecfg as an

Re: [PATCH v2 2/2] ARM: dts: enable pinctrl for Broadcom NS2 SoC

Le 30/04/2016 04:13, Linus Walleij a écrit : > On Fri, Apr 29, 2016 at 2:51 PM, Yendapally Reddy Dhananjaya Reddy > wrote: > >> This enables the pinctrl support for Broadcom NS2 SoC >> >> Signed-off-by: Yendapally Reddy Dhananjaya Reddy >>

Re: [PATCH v2 2/2] ARM: dts: enable pinctrl for Broadcom NS2 SoC

Le 30/04/2016 04:13, Linus Walleij a écrit : > On Fri, Apr 29, 2016 at 2:51 PM, Yendapally Reddy Dhananjaya Reddy > wrote: > >> This enables the pinctrl support for Broadcom NS2 SoC >> >> Signed-off-by: Yendapally Reddy Dhananjaya Reddy >> >> Reviewed-by: Ray Jui > > Acked-by: Linus Walleij

Re: [PATCH 26/32] perf/x86/intel/cqm: integrate CQM cgroups with scheduler

In all those cases perf sched_out will call intel_cqm_event_stop that call pqr_cache_update_rmid that sets state->next_rmid to 0. The RMID 0 corresponds to the root monr in the RMID hierarchy. On Fri, Apr 29, 2016 at 4:49 PM Vikas Shivappa wrote: > > > > On Fri,

Re: [PATCH 26/32] perf/x86/intel/cqm: integrate CQM cgroups with scheduler

In all those cases perf sched_out will call intel_cqm_event_stop that call pqr_cache_update_rmid that sets state->next_rmid to 0. The RMID 0 corresponds to the root monr in the RMID hierarchy. On Fri, Apr 29, 2016 at 4:49 PM Vikas Shivappa wrote: > > > > On Fri, 29 Apr 2016, David

Re: [PATCH] Cleanup __pvclock_read_cycles to remove useless variables

On Sat, Apr 30, 2016 at 6:24 AM, Borislav Petkov wrote: > On Mon, Apr 25, 2016 at 02:53:14PM +0800, Minfei Huang wrote: >> The value of cycles and flags can be assigned directly without >> intermediate variables. >> >> Remove the useless variables. >> >> Signed-off-by: Minfei Huang

Re: [PATCH] Cleanup __pvclock_read_cycles to remove useless variables

On Sat, Apr 30, 2016 at 6:24 AM, Borislav Petkov wrote: > On Mon, Apr 25, 2016 at 02:53:14PM +0800, Minfei Huang wrote: >> The value of cycles and flags can be assigned directly without >> intermediate variables. >> >> Remove the useless variables. >> >> Signed-off-by: Minfei Huang >> --- >>

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Sat, 2016-04-30 at 10:12 -0700, Linus Torvalds wrote: > On Sat, Apr 30, 2016 at 9:45 AM, Eric Dumazet wrote: > > > > I use hash_32() in net/sched/sch_fq.c, for all packets sent by Google > > servers. (Note that I did _not_ use hash_ptr()) > > > > That's gazillions of

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Sat, 2016-04-30 at 10:12 -0700, Linus Torvalds wrote: > On Sat, Apr 30, 2016 at 9:45 AM, Eric Dumazet wrote: > > > > I use hash_32() in net/sched/sch_fq.c, for all packets sent by Google > > servers. (Note that I did _not_ use hash_ptr()) > > > > That's gazillions of packets per second, and

BUG: spinlock vs. mutex in SyS_finit_module / usbhs_runtime_resume / omap_tll_enable / clk_prepare_lock

Hi, I have observed this kernel oops on an omap5 board from time to time (approx. 1% of boot processes): [5.830970] ehci-omap: OMAP-EHCI Host Controller driver [5.830974] driver_register 'ehci-omap' [5.895849] driver_register 'wl1271_sdio' [5.896870] BUG: scheduling while atomic:

BUG: spinlock vs. mutex in SyS_finit_module / usbhs_runtime_resume / omap_tll_enable / clk_prepare_lock

Hi, I have observed this kernel oops on an omap5 board from time to time (approx. 1% of boot processes): [5.830970] ehci-omap: OMAP-EHCI Host Controller driver [5.830974] driver_register 'ehci-omap' [5.895849] driver_register 'wl1271_sdio' [5.896870] BUG: scheduling while atomic:

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Sat, Apr 30, 2016 at 9:45 AM, Eric Dumazet wrote: > > I use hash_32() in net/sched/sch_fq.c, for all packets sent by Google > servers. (Note that I did _not_ use hash_ptr()) > > That's gazillions of packets per second, and the current multiply worked > just fine in term

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Sat, Apr 30, 2016 at 9:45 AM, Eric Dumazet wrote: > > I use hash_32() in net/sched/sch_fq.c, for all packets sent by Google > servers. (Note that I did _not_ use hash_ptr()) > > That's gazillions of packets per second, and the current multiply worked > just fine in term of hash spreading. So

Re: [PATCH] tpm: use devm_add_action_or_reset

On Tue, Apr 26, 2016 at 11:30:14AM +0300, Jarkko Sakkinen wrote: > On Mon, Apr 25, 2016 at 09:46:38PM +0100, Sudip Mukherjee wrote: > > If devm_add_action() fails we are explicitly calling the cleanup function > > in the error path. Lets use the helper function devm_add_action_or_reset() > > and

Re: [PATCH] tpm: use devm_add_action_or_reset

On Tue, Apr 26, 2016 at 11:30:14AM +0300, Jarkko Sakkinen wrote: > On Mon, Apr 25, 2016 at 09:46:38PM +0100, Sudip Mukherjee wrote: > > If devm_add_action() fails we are explicitly calling the cleanup function > > in the error path. Lets use the helper function devm_add_action_or_reset() > > and

[PATCH v2] tpm: use devm_add_action_or_reset

From: Sudip Mukherjee If devm_add_action() fails we are explicitly calling the cleanup function in the error path. Lets use the helper function devm_add_action_or_reset() and return directly as we know the cleanup has been done by the helper. Reviewed-by: Jason

[PATCH v2] tpm: use devm_add_action_or_reset

From: Sudip Mukherjee If devm_add_action() fails we are explicitly calling the cleanup function in the error path. Lets use the helper function devm_add_action_or_reset() and return directly as we know the cleanup has been done by the helper. Reviewed-by: Jason Gunthorpe Signed-off-by: Sudip

Re: ERROR: "vring_del_virtqueue" [drivers/misc/mic/vop/vop.ko] undefined!

On 04/18/16 08:05, kbuild test robot wrote: > Hi Sudeep, > > FYI, the error/warning still remains. and still happens in linux-next-20160428... > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: c3b46c73264b03000d1e18b22f5caf63332547c9 > commit:

Re: ERROR: "vring_del_virtqueue" [drivers/misc/mic/vop/vop.ko] undefined!

On 04/18/16 08:05, kbuild test robot wrote: > Hi Sudeep, > > FYI, the error/warning still remains. and still happens in linux-next-20160428... > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: c3b46c73264b03000d1e18b22f5caf63332547c9 > commit:

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Sat, 2016-04-30 at 15:02 +0200, Thomas Gleixner wrote: > Yes. So I tested those two: > > u32 hash_64(u64 key) > { >key = ~key + (key << 18); >key ^= key >> 31; >key += (key << 2)) + (key << 4); >key ^= key >> 11; >key += key << 6; >key ^= key

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Sat, 2016-04-30 at 15:02 +0200, Thomas Gleixner wrote: > Yes. So I tested those two: > > u32 hash_64(u64 key) > { >key = ~key + (key << 18); >key ^= key >> 31; >key += (key << 2)) + (key << 4); >key ^= key >> 11; >key += key << 6; >key ^= key

Re: [PATCH] parport: use subsys_initcall

On Tue, Apr 12, 2016 at 08:56:10PM +0530, Sudip Mukherjee wrote: > The drivers which depends on parport may sometimes try to iniitialize > and register with parport bus even before parport has actually > registered with the device layer. > The simplest solution is to mark the init function as

Re: [PATCH] parport: use subsys_initcall

On Tue, Apr 12, 2016 at 08:56:10PM +0530, Sudip Mukherjee wrote: > The drivers which depends on parport may sometimes try to iniitialize > and register with parport bus even before parport has actually > registered with the device layer. > The simplest solution is to mark the init function as

[PATCH v2] x86:sysfb_efi:efifb_set_system: fix miss valid address range in later BARs

We can't just break out when meet start is equal to zero, this will cause we miss valid address range in later BARs. On the other hand, it isn't enough to test start only for below situation: 0(start) <= lfb_base < end Note: this patch also add a trivial optimization, break out after we

[PATCH v2] x86:sysfb_efi:efifb_set_system: fix miss valid address range in later BARs

We can't just break out when meet start is equal to zero, this will cause we miss valid address range in later BARs. On the other hand, it isn't enough to test start only for below situation: 0(start) <= lfb_base < end Note: this patch also add a trivial optimization, break out after we

Re: [PATCH] Staging: rtl8188eu: fixed coding style issues

On Sat, Apr 30, 2016 at 04:30:12PM +0800, Jacky Boen wrote: > Fixed parentheses, braces, comments, constants on the left side > comparisons, extra newlines and indentations, NULL comparisons, > and a typo. That's a lot of different things all in one patch. Please break it up into "one patch per

Re: [PATCH] Staging: rtl8188eu: fixed coding style issues

On Sat, Apr 30, 2016 at 04:30:12PM +0800, Jacky Boen wrote: > Fixed parentheses, braces, comments, constants on the left side > comparisons, extra newlines and indentations, NULL comparisons, > and a typo. That's a lot of different things all in one patch. Please break it up into "one patch per

Re: [PATCH] char: xillybus: use devm_add_action_or_reset

On Tue, Apr 26, 2016 at 01:23:08PM +0300, Eli Billauer wrote: > Thanks, > > I like the direction, however both xilly_map_single_* functions turn > out ending with > > if (rc) > return rc; > > return 0; > > Which is equivalent to just "return rc". Or maybe return the value > of

Re: [PATCH] char: xillybus: use devm_add_action_or_reset

On Tue, Apr 26, 2016 at 01:23:08PM +0300, Eli Billauer wrote: > Thanks, > > I like the direction, however both xilly_map_single_* functions turn > out ending with > > if (rc) > return rc; > > return 0; > > Which is equivalent to just "return rc". Or maybe return the value > of

[PATCH v2] perf gtk: Print dlerror() and reverse the loading order

This patch applies two changes below: * When dlopen() returns NULL, the string from dlerror() is printed to tell why it has failed. * The loading order was reversed. It used to try to load LIBDIR second, but it's reasonable to look around LIBDIR first and fall back to system directory.

[PATCH v2] perf gtk: Print dlerror() and reverse the loading order

This patch applies two changes below: * When dlopen() returns NULL, the string from dlerror() is printed to tell why it has failed. * The loading order was reversed. It used to try to load LIBDIR second, but it's reasonable to look around LIBDIR first and fall back to system directory.

[PATCH v2] char: xillybus: use devm_add_action_or_reset

If devm_add_action() fails we are explicitly calling dma_unmap_single(), pci_unmap_single() and kfree(). Lets use the helper devm_add_action_or_reset() and return directly in case of error, as we know that the cleanup function has been already called by the helper if there was any error. At that

[PATCH v2] char: xillybus: use devm_add_action_or_reset

If devm_add_action() fails we are explicitly calling dma_unmap_single(), pci_unmap_single() and kfree(). Lets use the helper devm_add_action_or_reset() and return directly in case of error, as we know that the cleanup function has been already called by the helper if there was any error. At that

[PATCH v3 3/3] ACPI/device_sysfs: Clean up checkpatch errors

Cleaning up two existing checkpatch errors (and 2 warnings) in device_sysfs.c since the file is being changed. The change in acpi_device_setup_files() is changing spaces to a tab. Signed-off-by: Betty Dall --- drivers/acpi/device_sysfs.c | 16 +--- 1 file

[PATCH v3 3/3] ACPI/device_sysfs: Clean up checkpatch errors

Cleaning up two existing checkpatch errors (and 2 warnings) in device_sysfs.c since the file is being changed. The change in acpi_device_setup_files() is changing spaces to a tab. Signed-off-by: Betty Dall --- drivers/acpi/device_sysfs.c | 16 +--- 1 file changed, 9 insertions(+),

[PATCH v3 2/3] ACPI/device_sysfs: Change _SUN and _STA show functions error return to EIO

The error return from a sysfs show function is passed up through the call chain and visible as the return from the read system call. The show functions for the _STA and _SUN object currently return -ENODEV. This patch changes the return to -EIO. ENODEV makes less sense since the "device' exists or

[PATCH v3 0/3] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

The ACPI _HRV object on the device is used to supply Linux with the device's hardware revision. This is an optional object. Add sysfs support for the _HRV object if it exists on the device. This change allows users to easily find the hardware version of non-PCI hardware by looking at the sysfs

[PATCH v3 1/3] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

The ACPI _HRV object on the device is used to supply Linux with the device's hardware revision. This is an optional object. Add sysfs support for the _HRV object if it exists on the device. This change allows users to easily find the hardware version of non-PCI hardware by looking at the sysfs

[PATCH v3 2/3] ACPI/device_sysfs: Change _SUN and _STA show functions error return to EIO

The error return from a sysfs show function is passed up through the call chain and visible as the return from the read system call. The show functions for the _STA and _SUN object currently return -ENODEV. This patch changes the return to -EIO. ENODEV makes less sense since the "device' exists or

[PATCH v3 0/3] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

The ACPI _HRV object on the device is used to supply Linux with the device's hardware revision. This is an optional object. Add sysfs support for the _HRV object if it exists on the device. This change allows users to easily find the hardware version of non-PCI hardware by looking at the sysfs

[PATCH v3 1/3] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

The ACPI _HRV object on the device is used to supply Linux with the device's hardware revision. This is an optional object. Add sysfs support for the _HRV object if it exists on the device. This change allows users to easily find the hardware version of non-PCI hardware by looking at the sysfs

Re: [ANNOUNCE] Git v2.8.2

Hi all, On Fri, 29 Apr 2016, Junio C Hamano wrote: > The latest maintenance release Git v2.8.2 is now available at > the usual places. I considered releasing Git for Windows v2.8.2 today, too. However, I decided to delay the release for a couple of days, for a couple of reasons: - I expect an

Re: [ANNOUNCE] Git v2.8.2

Hi all, On Fri, 29 Apr 2016, Junio C Hamano wrote: > The latest maintenance release Git v2.8.2 is now available at > the usual places. I considered releasing Git for Windows v2.8.2 today, too. However, I decided to delay the release for a couple of days, for a couple of reasons: - I expect an

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Fri, 29 Apr 2016, Linus Torvalds wrote: > Picking a new value almost at random (I say "almost", because I just > started with that 32-bit multiplicand value that mostly works and > shifted it up by 32 bits and then randomly added a few more bits to > avoid long ranges of ones and zeroes), I

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Fri, 29 Apr 2016, Linus Torvalds wrote: > Picking a new value almost at random (I say "almost", because I just > started with that 32-bit multiplicand value that mostly works and > shifted it up by 32 bits and then randomly added a few more bits to > avoid long ranges of ones and zeroes), I

[PATCH v3 3/3] USB: serial: cp210x: Cleaned up CRTSCTS flag code.

The CRTSCTS flag code cleared (and inconsistently) bits unrelated to CRTSCTS functionality. It was also harder than necessary to read. Signed-off-by: Konstantin Shkolnyy --- v3: Regenerated the patches correctly against the latest usb-next branch. v2 Improved

[PATCH v3 3/3] USB: serial: cp210x: Cleaned up CRTSCTS flag code.

The CRTSCTS flag code cleared (and inconsistently) bits unrelated to CRTSCTS functionality. It was also harder than necessary to read. Signed-off-by: Konstantin Shkolnyy --- v3: Regenerated the patches correctly against the latest usb-next branch. v2 Improved CRTSCTS fix by feedback. Dropped

[PATCH v3 1/3] USB: serial: cp210x: Fixed RTS mode setting by the CRTSCTS flag.

A bug in the CRTSCTS handling caused RTS to alternate between CRTSCTS=0 => "RTS transmits active signal" and CRTSCTS=1 => "RTS receives flow control" instead of CRTSCTS=0 => "RTS is statically active" and CRTSCTS=1 => "RTS receives flow control" This only happened after first having enabled

[PATCH v3 2/3] USB: serial: cp210x: Got rid of magic numbers in CRTSCTS flag code.

Replaced magic numbers used in the CRTSCTS flag code with symbolic names from the chip specification. Signed-off-by: Konstantin Shkolnyy --- v3: Regenerated the patches correctly against the latest usb-next branch. v2 Improved CRTSCTS fix by feedback. Dropped

[PATCH v3 1/3] USB: serial: cp210x: Fixed RTS mode setting by the CRTSCTS flag.

A bug in the CRTSCTS handling caused RTS to alternate between CRTSCTS=0 => "RTS transmits active signal" and CRTSCTS=1 => "RTS receives flow control" instead of CRTSCTS=0 => "RTS is statically active" and CRTSCTS=1 => "RTS receives flow control" This only happened after first having enabled

[PATCH v3 2/3] USB: serial: cp210x: Got rid of magic numbers in CRTSCTS flag code.

Replaced magic numbers used in the CRTSCTS flag code with symbolic names from the chip specification. Signed-off-by: Konstantin Shkolnyy --- v3: Regenerated the patches correctly against the latest usb-next branch. v2 Improved CRTSCTS fix by feedback. Dropped get_termios error handling fix.

Re: efi_enabled(EFI_PARAVIRT) use

On 2016年04月29日 22:53, Ard Biesheuvel wrote: > On 29 April 2016 at 16:39, Matt Fleming wrote: >> On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote: >>> On Fri, 29 Apr 2016, Ingo Molnar wrote: Also, it would be nice to have all things EFI in a single tree, the

Re: efi_enabled(EFI_PARAVIRT) use

On 2016年04月29日 22:53, Ard Biesheuvel wrote: > On 29 April 2016 at 16:39, Matt Fleming wrote: >> On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote: >>> On Fri, 29 Apr 2016, Ingo Molnar wrote: Also, it would be nice to have all things EFI in a single tree, the conflicts are

Re: efi_enabled(EFI_PARAVIRT) use

On 2016年04月29日 23:37, Stefano Stabellini wrote: > On Fri, 29 Apr 2016, Stefano Stabellini wrote: >> On Fri, 29 Apr 2016, Matt Fleming wrote: >>> On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote: On Fri, 29 Apr 2016, Ingo Molnar wrote: > Also, it would be nice to have all things EFI

Re: efi_enabled(EFI_PARAVIRT) use

On 2016年04月29日 23:37, Stefano Stabellini wrote: > On Fri, 29 Apr 2016, Stefano Stabellini wrote: >> On Fri, 29 Apr 2016, Matt Fleming wrote: >>> On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote: On Fri, 29 Apr 2016, Ingo Molnar wrote: > Also, it would be nice to have all things EFI

Re: Regression of v4.6-rc vs. v4.5: Merge tag 'drm-intel-next-2016-02-29'

On Apr 29 Stefan Richter wrote: > On Apr 26 Stefan Richter wrote: > > v4.6-rc solidly hangs after a short while after boot, login to X11, and > > doing nothing much remarkable on the just brought up X desktop. > > > > Hardware: x86-64, E3-1245 v3 (Haswell), > > mainboard Supermicro

Re: Regression of v4.6-rc vs. v4.5: Merge tag 'drm-intel-next-2016-02-29'

On Apr 29 Stefan Richter wrote: > On Apr 26 Stefan Richter wrote: > > v4.6-rc solidly hangs after a short while after boot, login to X11, and > > doing nothing much remarkable on the just brought up X desktop. > > > > Hardware: x86-64, E3-1245 v3 (Haswell), > > mainboard Supermicro

Re: [PATCH] Cleanup __pvclock_read_cycles to remove useless variables

On Mon, Apr 25, 2016 at 02:53:14PM +0800, Minfei Huang wrote: > The value of cycles and flags can be assigned directly without > intermediate variables. > > Remove the useless variables. > > Signed-off-by: Minfei Huang > --- > arch/x86/include/asm/pvclock.h | 15

Re: [PATCH] Cleanup __pvclock_read_cycles to remove useless variables

On Mon, Apr 25, 2016 at 02:53:14PM +0800, Minfei Huang wrote: > The value of cycles and flags can be assigned directly without > intermediate variables. > > Remove the useless variables. > > Signed-off-by: Minfei Huang > --- > arch/x86/include/asm/pvclock.h | 15 --- > 1 file

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 6:01 PM, Doug Anderson wrote: > Hi, > > On Fri, Apr 29, 2016 at 3:44 PM, Russell King - ARM Linux > wrote: >> My reply would be... why should MMC have special handling that no >> other subsystem has? > > No other subsystem? >

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 6:01 PM, Doug Anderson wrote: > Hi, > > On Fri, Apr 29, 2016 at 3:44 PM, Russell King - ARM Linux > wrote: >> My reply would be... why should MMC have special handling that no >> other subsystem has? > > No other subsystem? > > * i2c allows numbering devices by alias > *

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Thu, 28 Apr 2016, Linus Torvalds wrote: > It's the hashes that _look_ like they might be good hashes, but > there's not a lot of analysis behind it, that I would worry about. The > simple prime modulus _should_ be fine, but at the same time I kind of > suspect we can do better. Especially since

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Thu, 28 Apr 2016, Linus Torvalds wrote: > It's the hashes that _look_ like they might be good hashes, but > there's not a lot of analysis behind it, that I would worry about. The > simple prime modulus _should_ be fine, but at the same time I kind of > suspect we can do better. Especially since

hello linux

Hello linux http://penguinmembers.com/grandfather.php?1xlbpchk4291

hello linux

Hello linux http://penguinmembers.com/grandfather.php?1xlbpchk4291

Re: sched: tweak select_idle_sibling to look for idle threads

On Sat, Apr 09, 2016 at 03:05:54PM -0400, Chris Mason wrote: > select_task_rq_fair() can leave cpu utilization a little lumpy, > especially as the workload ramps up to the maximum capacity of the > machine. The end result can be high p99 response times as apps > wait to get scheduled, even when

Re: sched: tweak select_idle_sibling to look for idle threads

On Sat, Apr 09, 2016 at 03:05:54PM -0400, Chris Mason wrote: > select_task_rq_fair() can leave cpu utilization a little lumpy, > especially as the workload ramps up to the maximum capacity of the > machine. The end result can be high p99 response times as apps > wait to get scheduled, even when

Re: [PATCH] perf/sdt: Directly record cached SDT events

Hi Hemant, On Fri, 29 Apr 2016 19:10:41 +0530 Hemant Kumar wrote: > This patch adds support for directly recording SDT events which are > present in the probe cache. This patch is based on current SDT > enablement patchset (v5) by Masami : >

Re: [PATCH] perf/sdt: Directly record cached SDT events

Hi Hemant, On Fri, 29 Apr 2016 19:10:41 +0530 Hemant Kumar wrote: > This patch adds support for directly recording SDT events which are > present in the probe cache. This patch is based on current SDT > enablement patchset (v5) by Masami : > https://lkml.org/lkml/2016/4/27/828 > and it

[PATCH 3/7] x86/mce: Carve out writes to MCx_STATUS and MCx_CTL

From: Aravind Gopalakrishnan We need to do this after __mcheck_cpu_init_vendor() as for ScalableMCA processors, there are going to be new MSR write handlers if the feature is detected using CPUID bit (which happens in __mcheck_cpu_init_vendor()). No functional

[PATCH 2/7] x86/mce: Grade uncorrected errors for SMCA-enabled systems

From: Aravind Gopalakrishnan For upcoming processors with Scalable MCA feature, we need to check the "succor" CPUID bit and the TCC bit in the MCx_STATUS register in order to grade an MCE's severity. Signed-off-by: Aravind Gopalakrishnan

[PATCH 5/7] x86/mce: Detect and use SMCA-specific msr_ops

From: Yazen Ghannam Replace all calls to MCx_IA32_{CTL,ADDR,MISC,STATUS} with the appropriate msr_ops. Use SMCA-specific msr_ops when on an SMCA-enabled processor. Carved out from a patch by Aravind Gopalakrishnan . Signed-off-by: Yazen

[PATCH 3/7] x86/mce: Carve out writes to MCx_STATUS and MCx_CTL

From: Aravind Gopalakrishnan We need to do this after __mcheck_cpu_init_vendor() as for ScalableMCA processors, there are going to be new MSR write handlers if the feature is detected using CPUID bit (which happens in __mcheck_cpu_init_vendor()). No functional change is introduced here.

[PATCH 2/7] x86/mce: Grade uncorrected errors for SMCA-enabled systems

From: Aravind Gopalakrishnan For upcoming processors with Scalable MCA feature, we need to check the "succor" CPUID bit and the TCC bit in the MCx_STATUS register in order to grade an MCE's severity. Signed-off-by: Aravind Gopalakrishnan Cc: Aravind Gopalakrishnan Cc: Tony Luck Cc:

[PATCH 5/7] x86/mce: Detect and use SMCA-specific msr_ops

From: Yazen Ghannam Replace all calls to MCx_IA32_{CTL,ADDR,MISC,STATUS} with the appropriate msr_ops. Use SMCA-specific msr_ops when on an SMCA-enabled processor. Carved out from a patch by Aravind Gopalakrishnan . Signed-off-by: Yazen Ghannam Cc: Aravind Gopalakrishnan Cc: Tony Luck Cc:

[PATCH 4/7] x86/mce: Define vendor-specific MSR accessors

From: Yazen Ghannam Scalable MCA processors have a whole new range of MSR addresses to obtain bank related info such as CTL, MISC, ADDR, STATUS. Therefore, we need a way to abstract the MSR addresses per vendor. Carved out from a patch by Aravind Gopalakrishnan

[PATCH 6/7] x86/mce: Look in genpool instead of mcelog for pending error records

From: Tony Luck A couple of issues here: 1) MCE_LOG_LEN is only 32 - so we may have more pending records than will fit in the buffer on high core count CPUs. 2) During a panic we may have a lot of duplicate records because multiple logical CPUs may have seen and

[PATCH 7/7] x86/mce: Detect local MCEs properly

From: Yazen Ghannam Check the MCG_STATUS_LMCES bit on Intel to verify that current MCE is local. It is always local on AMD. Signed-off-by: Yazen Ghannam Cc: Tony Luck Cc: linux-edac Cc: x86-ml

[PATCH 4/7] x86/mce: Define vendor-specific MSR accessors

From: Yazen Ghannam Scalable MCA processors have a whole new range of MSR addresses to obtain bank related info such as CTL, MISC, ADDR, STATUS. Therefore, we need a way to abstract the MSR addresses per vendor. Carved out from a patch by Aravind Gopalakrishnan . Signed-off-by: Yazen Ghannam

[PATCH 6/7] x86/mce: Look in genpool instead of mcelog for pending error records

From: Tony Luck A couple of issues here: 1) MCE_LOG_LEN is only 32 - so we may have more pending records than will fit in the buffer on high core count CPUs. 2) During a panic we may have a lot of duplicate records because multiple logical CPUs may have seen and logged the same error

[PATCH 7/7] x86/mce: Detect local MCEs properly

From: Yazen Ghannam Check the MCG_STATUS_LMCES bit on Intel to verify that current MCE is local. It is always local on AMD. Signed-off-by: Yazen Ghannam Cc: Tony Luck Cc: linux-edac Cc: x86-ml Link: http://lkml.kernel.org/r/1461962923-32197-1-git-send-email-yazen.ghan...@amd.com [ Massage

[PATCH 1/7] x86/mce: Log MCEs after a warm rest on AMD, fam 0x17 and later

From: Aravind Gopalakrishnan For Fam17h, we want to report errors that persist across reboots. Error persistence is dependent on HW and no BIOS currently fiddles with values here. So allow reporting of errors upon boot until something goes wrong. Logging is

[PATCH 0/7] tip/ras/core: Second pile

From: Borislav Petkov Hi, this is the second pile of RAS stuff for 4.7. It is mostly AMD F17h enablement and some more work from Tony to divert flow from mcelog and into our new genpool facility. Please queue on tip/ras/core. Thanks. Aravind Gopalakrishnan (3): x86/mce: Log

[PATCH 1/7] x86/mce: Log MCEs after a warm rest on AMD, fam 0x17 and later

From: Aravind Gopalakrishnan For Fam17h, we want to report errors that persist across reboots. Error persistence is dependent on HW and no BIOS currently fiddles with values here. So allow reporting of errors upon boot until something goes wrong. Logging is disabled on older families because

[PATCH 0/7] tip/ras/core: Second pile

From: Borislav Petkov Hi, this is the second pile of RAS stuff for 4.7. It is mostly AMD F17h enablement and some more work from Tony to divert flow from mcelog and into our new genpool facility. Please queue on tip/ras/core. Thanks. Aravind Gopalakrishnan (3): x86/mce: Log MCEs after a

[for-next][PATCH 6/8] tracing: Have trace_buffer_unlock_commit() call the _regs version with NULL

From: "Steven Rostedt (Red Hat)" There's no real difference between trace_buffer_unlock_commit() and trace_buffer_unlock_commit_regs() except that the former passes NULL to ftrace_stack_trace() instead of regs. Have the former be a static inline of the latter which passes

[for-next][PATCH 5/8] tracing: Remove unused function trace_current_buffer_discard_commit()

From: "Steven Rostedt (Red Hat)" The function trace_current_buffer_discard_commit() has no callers, remove it. Signed-off-by: Steven Rostedt --- include/linux/trace_events.h | 2 -- kernel/trace/trace.c | 8 2 files changed, 10

[for-next][PATCH 1/8] tracing: Move event_trigger_unlock_commit{_regs}() to local header

From: "Steven Rostedt (Red Hat)" The functions event_trigger_unlock_commit() and event_trigger_unlock_commit_regs() are no longer used outside the tracing system. Move them out of the generic headers and into the local one. Along with __event_trigger_test_discard() that is

[for-next][PATCH 6/8] tracing: Have trace_buffer_unlock_commit() call the _regs version with NULL

From: "Steven Rostedt (Red Hat)" There's no real difference between trace_buffer_unlock_commit() and trace_buffer_unlock_commit_regs() except that the former passes NULL to ftrace_stack_trace() instead of regs. Have the former be a static inline of the latter which passes NULL for regs.

[for-next][PATCH 5/8] tracing: Remove unused function trace_current_buffer_discard_commit()

From: "Steven Rostedt (Red Hat)" The function trace_current_buffer_discard_commit() has no callers, remove it. Signed-off-by: Steven Rostedt --- include/linux/trace_events.h | 2 -- kernel/trace/trace.c | 8 2 files changed, 10 deletions(-) diff --git

[for-next][PATCH 1/8] tracing: Move event_trigger_unlock_commit{_regs}() to local header

From: "Steven Rostedt (Red Hat)" The functions event_trigger_unlock_commit() and event_trigger_unlock_commit_regs() are no longer used outside the tracing system. Move them out of the generic headers and into the local one. Along with __event_trigger_test_discard() that is only used by them.

[for-next][PATCH 7/8] tracing: Remove one use of trace_current_buffer_lock_reserve()

From: "Steven Rostedt (Red Hat)" The only user of trace_current_buffer_lock_reserve() is in the boot up self tests. Restructure the code a little to have that code use what everything else uses: trace_event_buffer_lock_reserve(). Signed-off-by: Steven Rostedt

[for-next][PATCH 3/8] tracing: Fold filter_check_discard() into its only user

From: "Steven Rostedt (Red Hat)" The function filter_check_discard() is small and only called by one user, its code can be folded into that one caller and make the code a bit less comlplex. Signed-off-by: Steven Rostedt --- kernel/trace/trace.c | 13

<    1   2   3   4   >