Re: [PATCH] klp: remove superfluous errors in asm/livepatch.h

On Fri, Mar 04, 2016 at 10:53:39AM +0100, Miroslav Benes wrote: > There is an #error in asm/livepatch.h for both x86 and s390 in > !CONFIG_LIVEPATCH cases. It does not make much sense as pointed out by > Michael Ellerman. One can happily include asm/livepatch.h with > CONFIG_LIVEPATCH. Remove it

Re: [PATCH] klp: remove superfluous errors in asm/livepatch.h

On Fri, Mar 04, 2016 at 10:53:39AM +0100, Miroslav Benes wrote: > There is an #error in asm/livepatch.h for both x86 and s390 in > !CONFIG_LIVEPATCH cases. It does not make much sense as pointed out by > Michael Ellerman. One can happily include asm/livepatch.h with > CONFIG_LIVEPATCH. Remove it

headsup: random memory corruption on 4.5-rc5

So I've gotten two random memory corruptions on my haswell laptop over the past week, one caused my e1000 driver to crap out, and one in ext4 I've lost the e1000 trace it never made it to disk, I've been running a lot of VMs on this with the standard virtio hw, as well as usual desktop stuff

headsup: random memory corruption on 4.5-rc5

So I've gotten two random memory corruptions on my haswell laptop over the past week, one caused my e1000 driver to crap out, and one in ext4 I've lost the e1000 trace it never made it to disk, I've been running a lot of VMs on this with the standard virtio hw, as well as usual desktop stuff

Re: [PATCH 00/12] KVM: MMU: cleanup around kvm_sync_page, and a few micro-optimizations

On 24/02/2016 14:17, Paolo Bonzini wrote: > This series started from looking at mmu_unsync_walk for the ubsan thread. > Patches 1 and 2 are the result of the discussions in that thread. > > Patches 3 to 9 do more cleanups in __kvm_sync_page and its callers. > Among other changes, it removes

Re: [PATCH 00/12] KVM: MMU: cleanup around kvm_sync_page, and a few micro-optimizations

On 24/02/2016 14:17, Paolo Bonzini wrote: > This series started from looking at mmu_unsync_walk for the ubsan thread. > Patches 1 and 2 are the result of the discussions in that thread. > > Patches 3 to 9 do more cleanups in __kvm_sync_page and its callers. > Among other changes, it removes

Re: [PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

On Fri, Mar 4, 2016 at 8:19 AM, Thierry Reding wrote: > From: Thierry Reding > > Extend the binding to cover the set of feature found in Tegra210. > > Signed-off-by: Thierry Reding > +PCIe pad: > +- > + > +Required

Re: [PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

On Fri, Mar 4, 2016 at 8:19 AM, Thierry Reding wrote: > From: Thierry Reding > > Extend the binding to cover the set of feature found in Tegra210. > > Signed-off-by: Thierry Reding > +PCIe pad: > +- > + > +Required properties: > +- clocks: Must contain an entry for each entry in

Re: [PATCH 3/4] leds: Add driver for the ISSI IS31FL32xx family of LED controllers

On 03/04/2016 08:02 PM, David Rivshin (Allworx) wrote: On Fri, 04 Mar 2016 17:01:52 +0100 Jacek Anaszewski wrote: On 03/04/2016 04:05 PM, David Rivshin (Allworx) wrote: On Fri, 04 Mar 2016 08:54:02 +0100 Jacek Anaszewski wrote: On

Re: [PATCH 3/4] leds: Add driver for the ISSI IS31FL32xx family of LED controllers

On 03/04/2016 08:02 PM, David Rivshin (Allworx) wrote: On Fri, 04 Mar 2016 17:01:52 +0100 Jacek Anaszewski wrote: On 03/04/2016 04:05 PM, David Rivshin (Allworx) wrote: On Fri, 04 Mar 2016 08:54:02 +0100 Jacek Anaszewski wrote: On 03/04/2016 01:45 AM, David Rivshin (Allworx) wrote: On

Re: [PATCH] mm/hugetlb: use EOPNOTSUPP in hugetlb sysctl handlers

On Thu, 3 Mar 2016 11:02:51 +0100 Jan Stancek wrote: > Replace ENOTSUPP with EOPNOTSUPP. If hugepages are not supported, > this value is propagated to userspace. EOPNOTSUPP is part of uapi > and is widely supported by libc libraries. hm, what is the actual user-visible

Re: [PATCH] mm/hugetlb: use EOPNOTSUPP in hugetlb sysctl handlers

On Thu, 3 Mar 2016 11:02:51 +0100 Jan Stancek wrote: > Replace ENOTSUPP with EOPNOTSUPP. If hugepages are not supported, > this value is propagated to userspace. EOPNOTSUPP is part of uapi > and is widely supported by libc libraries. hm, what is the actual user-visible effect of this change?

Re: [PATCH v3 9/10] cpufreq: sched: Re-introduce cpufreq_update_util()

On Fri, Mar 4, 2016 at 10:27 PM, Rafael J. Wysocki wrote: > On Fri, Mar 4, 2016 at 10:21 PM, Steve Muckle wrote: >> On 03/04/2016 05:30 AM, Rafael J. Wysocki wrote: >>> +void cpufreq_update_util(u64 time, unsigned long util, unsigned long max) >>> +{

Re: [PATCH v3 9/10] cpufreq: sched: Re-introduce cpufreq_update_util()

On Fri, Mar 4, 2016 at 10:27 PM, Rafael J. Wysocki wrote: > On Fri, Mar 4, 2016 at 10:21 PM, Steve Muckle wrote: >> On 03/04/2016 05:30 AM, Rafael J. Wysocki wrote: >>> +void cpufreq_update_util(u64 time, unsigned long util, unsigned long max) >>> +{ >>> + struct freq_update_hook *hook; >>>

Re: [PATCH net-next v3 3/4] drm/vmwgfx: remove userland definition of DIV_ROUND_UP

Hi Nicolas, On 4 March 2016 at 10:52, Nicolas Dichtel wrote: > Let's use __KERNEL_DIV_ROUND_UP, which is defined in uapi/linux/kernel.h. > > Signed-off-by: Nicolas Dichtel > --- > .../drm/vmwgfx/device_include/svga3d_surfacedefs.h | 20 >

Re: [PATCH net-next v3 3/4] drm/vmwgfx: remove userland definition of DIV_ROUND_UP

Hi Nicolas, On 4 March 2016 at 10:52, Nicolas Dichtel wrote: > Let's use __KERNEL_DIV_ROUND_UP, which is defined in uapi/linux/kernel.h. > > Signed-off-by: Nicolas Dichtel > --- > .../drm/vmwgfx/device_include/svga3d_surfacedefs.h | 20 > +++- > 1 file changed, 11

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

Hi Thierry, On Fri, Mar 4, 2016 at 8:19 AM, Thierry Reding wrote: > From: Thierry Reding > > The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a > set of lanes that are used for PCIe, SATA and USB. > > Signed-off-by: Thierry

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

Hi Thierry, On Fri, Mar 4, 2016 at 8:19 AM, Thierry Reding wrote: > From: Thierry Reding > > The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a > set of lanes that are used for PCIe, SATA and USB. > > Signed-off-by: Thierry Reding Thanks, this binding looks much better,

[PATCH] [media] em28xx: fix Terratec Grabby AC97 codec detection

EMP202 chip inside Terratec Grabby (hw rev 2) seems to require some time before accessing reliably its registers. Otherwise it returns some values previously put on the I2C bus. To account for that period, we delay card setup until we have a proof that accessing AC97 registers is reliable. We get

[PATCH] Fix Terratec Grabby AC97 codec detection

Thanks Mauro for commenting on my work. With respect to first version, I've: * added a timeout mecanism as requested * added an extra check to avoid cases when the same value is constantly returned no matter which register is accessed. --- To test this: * modprobe em28xx-alsa * connect Grabby *

[PATCH] [media] em28xx: fix Terratec Grabby AC97 codec detection

EMP202 chip inside Terratec Grabby (hw rev 2) seems to require some time before accessing reliably its registers. Otherwise it returns some values previously put on the I2C bus. To account for that period, we delay card setup until we have a proof that accessing AC97 registers is reliable. We get

[PATCH] Fix Terratec Grabby AC97 codec detection

Thanks Mauro for commenting on my work. With respect to first version, I've: * added a timeout mecanism as requested * added an extra check to avoid cases when the same value is constantly returned no matter which register is accessed. --- To test this: * modprobe em28xx-alsa * connect Grabby *

Re: [PATCH] stmmac: fix noderef.cocci warnings

From: Alexandre Torgue Date: Fri, 4 Mar 2016 13:45:40 +0100 > Hi, > > On 03/03/2016 02:55 AM, kbuild test robot wrote: >> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:115:15-21: >> ERROR: application of sizeof to pointer >> >> sizeof when applied to a pointer

Re: [PATCH] stmmac: fix noderef.cocci warnings

From: Alexandre Torgue Date: Fri, 4 Mar 2016 13:45:40 +0100 > Hi, > > On 03/03/2016 02:55 AM, kbuild test robot wrote: >> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:115:15-21: >> ERROR: application of sizeof to pointer >> >> sizeof when applied to a pointer typed expression gives

[PATCH net-next] hv_netvsc: Move subchannel waiting to rndis_filter_device_remove()

During hot add, vmbus_device_register() is called from vmbus_onoffer(), on the same workqueue as the subchannel offer message work-queue, so subchannel offer won't be processed until the vmbus_device_register()/... /netvsc_probe() is done. Also, vmbus_device_register() is called with

[PATCH net-next] hv_netvsc: Move subchannel waiting to rndis_filter_device_remove()

During hot add, vmbus_device_register() is called from vmbus_onoffer(), on the same workqueue as the subchannel offer message work-queue, so subchannel offer won't be processed until the vmbus_device_register()/... /netvsc_probe() is done. Also, vmbus_device_register() is called with

Re: [PATCH v3 9/10] cpufreq: sched: Re-introduce cpufreq_update_util()

On Fri, Mar 4, 2016 at 10:21 PM, Steve Muckle wrote: > On 03/04/2016 05:30 AM, Rafael J. Wysocki wrote: >> +void cpufreq_update_util(u64 time, unsigned long util, unsigned long max) >> +{ >> + struct freq_update_hook *hook; >> + >> +#ifdef CONFIG_LOCKDEP >> +

Re: [PATCH v3 9/10] cpufreq: sched: Re-introduce cpufreq_update_util()

On Fri, Mar 4, 2016 at 10:21 PM, Steve Muckle wrote: > On 03/04/2016 05:30 AM, Rafael J. Wysocki wrote: >> +void cpufreq_update_util(u64 time, unsigned long util, unsigned long max) >> +{ >> + struct freq_update_hook *hook; >> + >> +#ifdef CONFIG_LOCKDEP >> + WARN_ON(debug_locks &&

Re: Backport patch from 4.2 to 3.18

On 03/04/2016 03:40 PM, Andrei Sharaev wrote: > Hi Sasha, > > Can you backport this patch for "inet-frag-fixes" to linux kernel 3.18 LTS? > http://kernel.suse.com/cgit/kernel/commit/?h=v4.2-rc5=64b892ad2326348a5b8314167590d240e3bcc69e > > I get 1-5 kernel panics in month for linux kernels

Re: Backport patch from 4.2 to 3.18

On 03/04/2016 03:40 PM, Andrei Sharaev wrote: > Hi Sasha, > > Can you backport this patch for "inet-frag-fixes" to linux kernel 3.18 LTS? > http://kernel.suse.com/cgit/kernel/commit/?h=v4.2-rc5=64b892ad2326348a5b8314167590d240e3bcc69e > > I get 1-5 kernel panics in month for linux kernels

[PATCH v7 1/5] leds: core: add generic support for RGB LED's

Add generic support for RGB LED's. Basic idea is to use enum led_brightness also for the hue and saturation color components.This allows to implement the color extension w/o changes to struct led_classdev. Select LEDS_RGB to enable building drivers using the RGB extension. Flag LED_SET_HUE_SAT

Re: [PATCH v5 4/4] leds: core: add support for RGB LED's

Am 04.03.2016 um 10:05 schrieb Jacek Anaszewski: > On 03/01/2016 10:36 PM, Heiner Kallweit wrote: >> Export a function to convert HSV color values to RGB. >> It's intended to be called by drivers for RGB LEDs. >> >> Signed-off-by: Heiner Kallweit >> --- >> v2: >> - move hsv

[PATCH v7 1/5] leds: core: add generic support for RGB LED's

Add generic support for RGB LED's. Basic idea is to use enum led_brightness also for the hue and saturation color components.This allows to implement the color extension w/o changes to struct led_classdev. Select LEDS_RGB to enable building drivers using the RGB extension. Flag LED_SET_HUE_SAT

Re: [PATCH v5 4/4] leds: core: add support for RGB LED's

Am 04.03.2016 um 10:05 schrieb Jacek Anaszewski: > On 03/01/2016 10:36 PM, Heiner Kallweit wrote: >> Export a function to convert HSV color values to RGB. >> It's intended to be called by drivers for RGB LEDs. >> >> Signed-off-by: Heiner Kallweit >> --- >> v2: >> - move hsv -> rgb conversion to

[PATCH v7 4/5] leds: core: document ABI change for RGB extension

Document the ABI change in Documentation/ABI/testing/sysfs-class-led. Signed-off-by: Heiner Kallweit --- v7: - separated from patch 3 --- Documentation/ABI/testing/sysfs-class-led | 11 +++ 1 file changed, 11 insertions(+) diff --git

[PATCH v7 4/5] leds: core: document ABI change for RGB extension

Document the ABI change in Documentation/ABI/testing/sysfs-class-led. Signed-off-by: Heiner Kallweit --- v7: - separated from patch 3 --- Documentation/ABI/testing/sysfs-class-led | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-class-led

[PATCH v7 2/5] leds: core: add color LED sysfs extension

Extend brightness sysfs property handling to deal with monochrome and color mode as well. Signed-off-by: Heiner Kallweit --- v2: - split from patch 1 v3: - moved one change (led_is_off) to patch 1 v4: - changed printf format string to %#.6x v5: - no changes v6: - no changes

Re: [PATCH] kernel/...: Convert pr_warning to pr_warn

On Fri, Mar 4, 2016 at 7:15 PM, Joe Perches wrote: > Use the more common logging method with the eventual goal > of removing pr_warning altogether. > > Miscellanea: > > o Realign arguments > o Coalesce formats > o Add missing space between a few coalesced formats > >

[PATCH v7 2/5] leds: core: add color LED sysfs extension

Extend brightness sysfs property handling to deal with monochrome and color mode as well. Signed-off-by: Heiner Kallweit --- v2: - split from patch 1 v3: - moved one change (led_is_off) to patch 1 v4: - changed printf format string to %#.6x v5: - no changes v6: - no changes v7: - no changes ---

Re: [PATCH] kernel/...: Convert pr_warning to pr_warn

On Fri, Mar 4, 2016 at 7:15 PM, Joe Perches wrote: > Use the more common logging method with the eventual goal > of removing pr_warning altogether. > > Miscellanea: > > o Realign arguments > o Coalesce formats > o Add missing space between a few coalesced formats > > Signed-off-by: Joe Perches >

Re: [PATCH] PM / Domains: Propagate start and restore errors during runtime resume

On Fri, Mar 4, 2016 at 9:38 PM, Laurent Pinchart wrote: > Hi Ulf, > > Thank you for the review. > > On Friday 04 March 2016 11:22:49 Ulf Hansson wrote: >> On 2 March 2016 at 00:20, Laurent Pinchart wrote: >> > During runtime resume the return values of the start

Re: [PATCH] PM / Domains: Propagate start and restore errors during runtime resume

On Fri, Mar 4, 2016 at 9:38 PM, Laurent Pinchart wrote: > Hi Ulf, > > Thank you for the review. > > On Friday 04 March 2016 11:22:49 Ulf Hansson wrote: >> On 2 March 2016 at 00:20, Laurent Pinchart wrote: >> > During runtime resume the return values of the start and restore steps >> > are

[PATCH v7 3/5] leds: core: add documentation for RGB extension

Document the RGB extension in Documentation/leds/leds-class.txt Signed-off-by: Heiner Kallweit --- v2: - introduced to patch series v3: - document extension in more detail v4: - Better explain why flag LED_SET_HUE_SAT is needed v5: - no changes v6: - no changes v7: - move

[PATCH v7 5/5] leds: core: add support for RGB LED's

Export a function to convert HSV color values to RGB. It's intended to be called by drivers for RGB LEDs. Signed-off-by: Heiner Kallweit --- v2: - move hsv -> rgb conversion to separate file - remove flag LED_DEV_CAP_RGB v3: - call led_hsv_to_rgb only if LED_DEV_CAP_HSV is

[PATCH v7 3/5] leds: core: add documentation for RGB extension

Document the RGB extension in Documentation/leds/leds-class.txt Signed-off-by: Heiner Kallweit --- v2: - introduced to patch series v3: - document extension in more detail v4: - Better explain why flag LED_SET_HUE_SAT is needed v5: - no changes v6: - no changes v7: - move Documentation/ABI

[PATCH v7 5/5] leds: core: add support for RGB LED's

Export a function to convert HSV color values to RGB. It's intended to be called by drivers for RGB LEDs. Signed-off-by: Heiner Kallweit --- v2: - move hsv -> rgb conversion to separate file - remove flag LED_DEV_CAP_RGB v3: - call led_hsv_to_rgb only if LED_DEV_CAP_HSV is set This is needed

Re: [PATCH v2] mtd: avoid stack overflow in MTD CFI code

On Mon, Feb 29, 2016 at 01:20:28PM +0100, Arnd Bergmann wrote: > When map_word gets too large, we use a lot of kernel stack, and for > MTD_MAP_BANK_WIDTH_32, this means we use more than the recommended > 1024 bytes in a number of functions: > > drivers/mtd/chips/cfi_cmdset_0020.c: In function

Re: [PATCH v3 9/10] cpufreq: sched: Re-introduce cpufreq_update_util()

On 03/04/2016 05:30 AM, Rafael J. Wysocki wrote: > +void cpufreq_update_util(u64 time, unsigned long util, unsigned long max) > +{ > + struct freq_update_hook *hook; > + > +#ifdef CONFIG_LOCKDEP > + WARN_ON(debug_locks && !rcu_read_lock_sched_held()); > +#endif > + > + hook =

Re: [PATCH v10 1/6] fixed typo in ufshcd-pltfrm

On Friday 04 March 2016 17:22:14 Joao Pinto wrote: > Fixed typo in ufshcd-pltfrm. > > Signed-off-by: Joao Pinto Acked-by: Arnd Bergmann

Re: [PATCH v3 9/10] cpufreq: sched: Re-introduce cpufreq_update_util()

On 03/04/2016 05:30 AM, Rafael J. Wysocki wrote: > +void cpufreq_update_util(u64 time, unsigned long util, unsigned long max) > +{ > + struct freq_update_hook *hook; > + > +#ifdef CONFIG_LOCKDEP > + WARN_ON(debug_locks && !rcu_read_lock_sched_held()); > +#endif > + > + hook =

Re: [PATCH v10 1/6] fixed typo in ufshcd-pltfrm

On Friday 04 March 2016 17:22:14 Joao Pinto wrote: > Fixed typo in ufshcd-pltfrm. > > Signed-off-by: Joao Pinto Acked-by: Arnd Bergmann

Re: [PATCH v2] mtd: avoid stack overflow in MTD CFI code

On Mon, Feb 29, 2016 at 01:20:28PM +0100, Arnd Bergmann wrote: > When map_word gets too large, we use a lot of kernel stack, and for > MTD_MAP_BANK_WIDTH_32, this means we use more than the recommended > 1024 bytes in a number of functions: > > drivers/mtd/chips/cfi_cmdset_0020.c: In function

Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"

On Fri, 2016-03-04 at 13:37 -0500, Paul Gortmaker wrote: > [Re: runtime regression with "x86/mm/pat: Emulate PAT when it is > disabled"] On 03/03/2016 (Thu 22:02) Toshi Kani wrote: > > > On Thu, 2016-03-03 at 15:59 -0500, Paul Gortmaker wrote:  : > > > > > > The stand alone reproducer is here;

Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"

On Fri, 2016-03-04 at 13:37 -0500, Paul Gortmaker wrote: > [Re: runtime regression with "x86/mm/pat: Emulate PAT when it is > disabled"] On 03/03/2016 (Thu 22:02) Toshi Kani wrote: > > > On Thu, 2016-03-03 at 15:59 -0500, Paul Gortmaker wrote:  : > > > > > > The stand alone reproducer is here;

Re: [PATCH v10 6/6] add TC G210 pci driver

On Friday 04 March 2016 17:22:19 Joao Pinto wrote: > This patch adds a glue pci driver for the Synopsys G210 Test Chip. > > Signed-off-by: Joao Pinto Mostly ok, just a few suggestions: > + > +/* Test Chip type expected values */ > +#define TC_G210_20BIT 20 > +#define

Re: [PATCH v10 6/6] add TC G210 pci driver

On Friday 04 March 2016 17:22:19 Joao Pinto wrote: > This patch adds a glue pci driver for the Synopsys G210 Test Chip. > > Signed-off-by: Joao Pinto Mostly ok, just a few suggestions: > + > +/* Test Chip type expected values */ > +#define TC_G210_20BIT 20 > +#define TC_G210_40BIT 40 >

Re: [PATCH 4/4] leds: Replace dedicated SN3218 driver with IS31FL32XX driver

Hi David, > "David Rivshin (Allworx)" hat am 3. März 2016 um > 04:01 geschrieben: > > > From: David Rivshin > > Si-En Technology was acquired by ISSI in 2011, and it appears that > the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216

Re: [PATCH 4/4] leds: Replace dedicated SN3218 driver with IS31FL32XX driver

Hi David, > "David Rivshin (Allworx)" hat am 3. März 2016 um > 04:01 geschrieben: > > > From: David Rivshin > > Si-En Technology was acquired by ISSI in 2011, and it appears that > the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216 devices. > As the IS31FL32XX driver already handles the

[PATCH v2] media: add prefixes to interface types

Add missing prefixes for DVB, V4L, and ALSA interface types. Signed-off-by: Shuah Khan --- Changes since v1: Addresses Hans's comments on v1 drivers/media/media-entity.c | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff

[PATCH v2] media: add prefixes to interface types

Add missing prefixes for DVB, V4L, and ALSA interface types. Signed-off-by: Shuah Khan --- Changes since v1: Addresses Hans's comments on v1 drivers/media/media-entity.c | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git

Re: [PATCH v10 5/6] add TC G210 platform driver

On Friday 04 March 2016 17:22:18 Joao Pinto wrote: > This patch adds a glue platform driver for the Synopsys G210 Test Chip. > > Signed-off-by: Joao Pinto Looks basically ok, but I think it can be simplified a little: > +/** > + * struct ufs_hba_dwc_vops - UFS DWC specific

Re: [PATCH v10 5/6] add TC G210 platform driver

On Friday 04 March 2016 17:22:18 Joao Pinto wrote: > This patch adds a glue platform driver for the Synopsys G210 Test Chip. > > Signed-off-by: Joao Pinto Looks basically ok, but I think it can be simplified a little: > +/** > + * struct ufs_hba_dwc_vops - UFS DWC specific variant operations >

Re: [PATCH net-next v3 0/4] uapi: consolidate DIV_ROUND_UP definition

From: Nicolas Dichtel Date: Fri, 4 Mar 2016 11:52:15 +0100 > The inital goal was to consolidate ethtool.h uapi header. But I took the > opportunity to remove all duplicate definitions of DIV_ROUND_UP. > > v3: add patch #2 and #3 > > v2: split the patch > define

Re: [PATCH net-next v3 0/4] uapi: consolidate DIV_ROUND_UP definition

From: Nicolas Dichtel Date: Fri, 4 Mar 2016 11:52:15 +0100 > The inital goal was to consolidate ethtool.h uapi header. But I took the > opportunity to remove all duplicate definitions of DIV_ROUND_UP. > > v3: add patch #2 and #3 > > v2: split the patch > define DIV_ROUND_UP in uapi

Re: [PATCH v10 3/6] added support for DesignWare Controller

On Friday 04 March 2016 17:22:16 Joao Pinto wrote: > This patch has the goal to add support for DesignWare UFS Controller > specific operations. > > Signed-off-by: Joao Pinto > Acked-by: Arnd Bergmann

Re: [PATCH v10 4/6] added support for Synopsys G210 Test Chip

On Friday 04 March 2016 17:22:17 Joao Pinto wrote: > This patch adds support for Synopsys G210 Test Chip. > > Signed-off-by: Joao Pinto > Acked-by: Arnd Bergmann

Re: [PATCH v10 3/6] added support for DesignWare Controller

On Friday 04 March 2016 17:22:16 Joao Pinto wrote: > This patch has the goal to add support for DesignWare UFS Controller > specific operations. > > Signed-off-by: Joao Pinto > Acked-by: Arnd Bergmann

Re: [PATCH v10 4/6] added support for Synopsys G210 Test Chip

On Friday 04 March 2016 17:22:17 Joao Pinto wrote: > This patch adds support for Synopsys G210 Test Chip. > > Signed-off-by: Joao Pinto > Acked-by: Arnd Bergmann

Re: [PATCH] x86: PAT: Documentation: update overlapping ioremap hack recommendation

On Fri, Mar 04, 2016 at 08:23:26PM +0100, Luis R. Rodriguez wrote: > On Thu, Mar 03, 2016 at 01:42:33PM -0800, Paul E. McKenney wrote: > > On Thu, Mar 03, 2016 at 01:21:48PM -0800, Luis R. Rodriguez wrote: > > > The current documentation refers to using set_memor_wc() as a > > > possible hole

Re: [PATCH] x86: PAT: Documentation: update overlapping ioremap hack recommendation

On Fri, Mar 04, 2016 at 08:23:26PM +0100, Luis R. Rodriguez wrote: > On Thu, Mar 03, 2016 at 01:42:33PM -0800, Paul E. McKenney wrote: > > On Thu, Mar 03, 2016 at 01:21:48PM -0800, Luis R. Rodriguez wrote: > > > The current documentation refers to using set_memor_wc() as a > > > possible hole

Re: [PATCH v10 2/6] added UFS 2.0 capabilities

On Friday 04 March 2016 17:22:15 Joao Pinto wrote: > Adding UFS 2.0 support to the UFS core driver. > > Signed-off-by: Joao Pinto > Acked-by: Arnd Bergmann

Re: [PATCH v10 2/6] added UFS 2.0 capabilities

On Friday 04 March 2016 17:22:15 Joao Pinto wrote: > Adding UFS 2.0 support to the UFS core driver. > > Signed-off-by: Joao Pinto > Acked-by: Arnd Bergmann

Re: [PATCH] ARM: LLVMLinux: Change "extern inline" to "static inline" in mpi-inline.h and mpi-internal.h

On Friday 04 March 2016 20:48:56 Gianfranco Costamagna wrote: > >Close, but not quite right. > > >It's currently in the crypto tree after Herbert Xu picked it up. > >It is scheduled to be merged into 4.6 at the moment. > > > wonderful, sure, in the next merge window is good. > But there is a

Re: [PATCH] ARM: LLVMLinux: Change "extern inline" to "static inline" in mpi-inline.h and mpi-internal.h

On Friday 04 March 2016 20:48:56 Gianfranco Costamagna wrote: > >Close, but not quite right. > > >It's currently in the crypto tree after Herbert Xu picked it up. > >It is scheduled to be merged into 4.6 at the moment. > > > wonderful, sure, in the next merge window is good. > But there is a

Re: [PATCH] futex: replace bare barrier() with more lightweight READ_ONCE()

On Fri, Mar 04, 2016 at 09:12:31AM +0800, Jianyu Zhan wrote: > On Fri, Mar 4, 2016 at 1:05 AM, Darren Hart wrote: > > I thought I provided a corrected comment block maybe I didn't. We have > > been > > working on improving the futex documentation, so we're paying close

Re: [PATCH] futex: replace bare barrier() with more lightweight READ_ONCE()

On Fri, Mar 04, 2016 at 09:12:31AM +0800, Jianyu Zhan wrote: > On Fri, Mar 4, 2016 at 1:05 AM, Darren Hart wrote: > > I thought I provided a corrected comment block maybe I didn't. We have > > been > > working on improving the futex documentation, so we're paying close > > attention to > >

Re: [PATCH] PM / Runtime: Only force-resume device if it has been force-suspended

Hi Ulf and Alan, Thank you for the review. On Friday 04 March 2016 10:24:10 Alan Stern wrote: > On Fri, 4 Mar 2016, Ulf Hansson wrote: > > On 3 March 2016 at 21:16, Laurent Pinchart wrote: > >> The pm_runtime_force_suspend() and pm_runtime_force_resume() helpers are > >> designed to help driver

Re: [PATCH] PM / Runtime: Only force-resume device if it has been force-suspended

Hi Ulf and Alan, Thank you for the review. On Friday 04 March 2016 10:24:10 Alan Stern wrote: > On Fri, 4 Mar 2016, Ulf Hansson wrote: > > On 3 March 2016 at 21:16, Laurent Pinchart wrote: > >> The pm_runtime_force_suspend() and pm_runtime_force_resume() helpers are > >> designed to help driver

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

On Friday 04 March 2016 19:18:49 i...@linux-pingi.de wrote: > Am 04.03.2016 um 16:24 schrieb Arnd Bergmann: > > On Thursday 03 March 2016 09:30:38 i...@linux-pingi.de wrote: > >> Hi Arnd, > >> I fully agree and ack. > >> Thanks for the work. > >> > > > > I actually did more patches that I ended

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

On Friday 04 March 2016 19:18:49 i...@linux-pingi.de wrote: > Am 04.03.2016 um 16:24 schrieb Arnd Bergmann: > > On Thursday 03 March 2016 09:30:38 i...@linux-pingi.de wrote: > >> Hi Arnd, > >> I fully agree and ack. > >> Thanks for the work. > >> > > > > I actually did more patches that I ended

Re: [PATCH] leds: Add Chrome OS keyboard backlight LEDs driver

On Fri, Mar 04, 2016 at 09:55:24PM +0100, Jacek Anaszewski wrote: > On 03/04/2016 08:13 PM, Dmitry Torokhov wrote: > >On Fri, Mar 04, 2016 at 10:38:40AM +0100, Jacek Anaszewski wrote: > >>Hi Evan, > >> > >>On 03/04/2016 09:38 AM, Evan McClain wrote: > >>>On Thu, 2016-03-03 at 15:46 -0800, Dmitry

Re: [PATCH] leds: Add Chrome OS keyboard backlight LEDs driver

On Fri, Mar 04, 2016 at 09:55:24PM +0100, Jacek Anaszewski wrote: > On 03/04/2016 08:13 PM, Dmitry Torokhov wrote: > >On Fri, Mar 04, 2016 at 10:38:40AM +0100, Jacek Anaszewski wrote: > >>Hi Evan, > >> > >>On 03/04/2016 09:38 AM, Evan McClain wrote: > >>>On Thu, 2016-03-03 at 15:46 -0800, Dmitry

Re: [PATCH] leds: Add Chrome OS keyboard backlight LEDs driver

On Fri, Mar 04, 2016 at 03:41:36PM -0500, Evan McClain wrote: > On Fri, 2016-03-04 at 11:13 -0800, Dmitry Torokhov wrote: > > On Fri, Mar 04, 2016 at 10:38:40AM +0100, Jacek Anaszewski wrote: > > > > > > Hi Evan, > > > > > > On 03/04/2016 09:38 AM, Evan McClain wrote: > > > > > > > > On Thu,

Re: [PATCH] leds: Add Chrome OS keyboard backlight LEDs driver

On Fri, Mar 04, 2016 at 03:41:36PM -0500, Evan McClain wrote: > On Fri, 2016-03-04 at 11:13 -0800, Dmitry Torokhov wrote: > > On Fri, Mar 04, 2016 at 10:38:40AM +0100, Jacek Anaszewski wrote: > > > > > > Hi Evan, > > > > > > On 03/04/2016 09:38 AM, Evan McClain wrote: > > > > > > > > On Thu,

Re: [PATCH] ARM: LLVMLinux: Change "extern inline" to "static inline" in mpi-inline.h and mpi-internal.h

Hi >Close, but not quite right. >It's currently in the crypto tree after Herbert Xu picked it up. >It is scheduled to be merged into 4.6 at the moment. wonderful, sure, in the next merge window is good. But there is a little difference between your patch and mine. In your case they were

Re: [PATCH] ARM: LLVMLinux: Change "extern inline" to "static inline" in mpi-inline.h and mpi-internal.h

Hi >Close, but not quite right. >It's currently in the crypto tree after Herbert Xu picked it up. >It is scheduled to be merged into 4.6 at the moment. wonderful, sure, in the next merge window is good. But there is a little difference between your patch and mine. In your case they were

Re: [PATCH] leds: Add Chrome OS keyboard backlight LEDs driver

On 03/04/2016 08:13 PM, Dmitry Torokhov wrote: On Fri, Mar 04, 2016 at 10:38:40AM +0100, Jacek Anaszewski wrote: Hi Evan, On 03/04/2016 09:38 AM, Evan McClain wrote: On Thu, 2016-03-03 at 15:46 -0800, Dmitry Torokhov wrote: From: Simon Que This is a driver for ACPI-based

Re: [PATCH] leds: Add Chrome OS keyboard backlight LEDs driver

On 03/04/2016 08:13 PM, Dmitry Torokhov wrote: On Fri, Mar 04, 2016 at 10:38:40AM +0100, Jacek Anaszewski wrote: Hi Evan, On 03/04/2016 09:38 AM, Evan McClain wrote: On Thu, 2016-03-03 at 15:46 -0800, Dmitry Torokhov wrote: From: Simon Que This is a driver for ACPI-based keyboard backlight

Re: [PATCH 12/41] clk: qcom: Remove CLK_IS_ROOT

On 03/01, Stephen Boyd wrote: > This flag is a no-op now. Remove usage of the flag. > > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH 12/41] clk: qcom: Remove CLK_IS_ROOT

On 03/01, Stephen Boyd wrote: > This flag is a no-op now. Remove usage of the flag. > > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

[PART1 RFC v2 04/10] svm: clean up V_TPR, V_IRQ, V_INTR_PRIO, and V_INTR_MASKING

From: Suravee Suthikulpanit Now that we have defined the bit field, use them to replace existing macros. This patch should not have functional change. Signed-off-by: Suravee Suthikulpanit --- arch/x86/include/asm/svm.h | 9

[PART1 RFC v2 03/10] svm: Introduce new AVIC VMCB registers

From: Suravee Suthikulpanit Introduce new AVIC VMCB registers. Also breakdown int_ctl register into bit-field for ease of use. Signed-off-by: Suravee Suthikulpanit --- arch/x86/include/asm/svm.h | 29 -

[PART1 RFC v2 04/10] svm: clean up V_TPR, V_IRQ, V_INTR_PRIO, and V_INTR_MASKING

From: Suravee Suthikulpanit Now that we have defined the bit field, use them to replace existing macros. This patch should not have functional change. Signed-off-by: Suravee Suthikulpanit --- arch/x86/include/asm/svm.h | 9 - arch/x86/kvm/svm.c | 24

[PART1 RFC v2 03/10] svm: Introduce new AVIC VMCB registers

From: Suravee Suthikulpanit Introduce new AVIC VMCB registers. Also breakdown int_ctl register into bit-field for ease of use. Signed-off-by: Suravee Suthikulpanit --- arch/x86/include/asm/svm.h | 29 - 1 file changed, 24 insertions(+), 5 deletions(-) diff --git

[PART1 RFC v2 07/10] svm: Add VMEXIT handlers for AVIC

From: Suravee Suthikulpanit Introduce VMEXIT handlers, avic_incp_ipi_interception() and avic_noaccel_interception(). Signed-off-by: Suravee Suthikulpanit --- arch/x86/include/uapi/asm/svm.h | 9 +- arch/x86/kvm/svm.c

[PART1 RFC v2 07/10] svm: Add VMEXIT handlers for AVIC

From: Suravee Suthikulpanit Introduce VMEXIT handlers, avic_incp_ipi_interception() and avic_noaccel_interception(). Signed-off-by: Suravee Suthikulpanit --- arch/x86/include/uapi/asm/svm.h | 9 +- arch/x86/kvm/svm.c | 260 2 files

[PART1 RFC v2 06/10] svm: Add interrupt injection via AVIC

This patch introduces a new mechanism to inject interrupt using AVIC. Since VINTR is not supported when enable AVIC, we need to inject interrupt via APIC backing page instead. This patch also adds support for AVIC doorbell, which is used by KVM to signal a running vcpu to check IRR for injected

[PART1 RFC v2 06/10] svm: Add interrupt injection via AVIC

This patch introduces a new mechanism to inject interrupt using AVIC. Since VINTR is not supported when enable AVIC, we need to inject interrupt via APIC backing page instead. This patch also adds support for AVIC doorbell, which is used by KVM to signal a running vcpu to check IRR for injected

[PART1 RFC v2 08/10] svm: Do not expose x2APIC when enable AVIC

From: Suravee Suthikulpanit Since AVIC only virtualizes xAPIC hardware for the guest, we need to: * Intercept APIC BAR msr accesses to disable x2APIC * Intercept CPUID access to not advertise x2APIC support * Hide x2APIC support when checking via KVM

[PART1 RFC v2 10/10] svm: Manage vcpu load/unload when enable AVIC

From: Suravee Suthikulpanit When a vcpu is loaded/unloaded to a physical core, we need to update information in the Physical APIC-ID table accordingly. Signed-off-by: Suravee Suthikulpanit --- arch/x86/kvm/svm.c | 146

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