Re: [PATCH 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid

On Thu, Jun 2, 2016 at 11:05 PM, Laurent Pinchart wrote: > Hi Boris, > > Thank you for the patch. > > On Thursday 02 Jun 2016 16:31:28 Boris Brezillon wrote: >> Adapt drm_pick_crtcs() and update_connector_routing() to fallback to >>

Re: [PATCH 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid

On Thu, Jun 2, 2016 at 11:05 PM, Laurent Pinchart wrote: > Hi Boris, > > Thank you for the patch. > > On Thursday 02 Jun 2016 16:31:28 Boris Brezillon wrote: >> Adapt drm_pick_crtcs() and update_connector_routing() to fallback to >> drm_atomic_helper_best_encoder() if funcs->best_encoder() is

Re: [PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic

On Thu, Jun 02, 2016 at 04:14:03PM -0500, Alex Thorlton wrote: > On Thu, Jun 02, 2016 at 08:45:47PM +0100, Matt Fleming wrote: > > Unless I've missed it, I didn't see an explanation in the changelog of > > why it's OK to switch from using __va(tab->function) to tab->function > > directly, which

Re: [PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic

On Thu, Jun 02, 2016 at 04:14:03PM -0500, Alex Thorlton wrote: > On Thu, Jun 02, 2016 at 08:45:47PM +0100, Matt Fleming wrote: > > Unless I've missed it, I didn't see an explanation in the changelog of > > why it's OK to switch from using __va(tab->function) to tab->function > > directly, which

Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait()

On Thu, Jun 02, 2016 at 06:57:00PM +0100, Will Deacon wrote: > > +++ b/include/asm-generic/qspinlock.h > > @@ -28,30 +28,13 @@ > > */ > > static __always_inline int queued_spin_is_locked(struct qspinlock *lock) > > { > > + /* > > +* See queued_spin_unlock_wait(). > > * > > +*

Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait()

On Thu, Jun 02, 2016 at 06:57:00PM +0100, Will Deacon wrote: > > +++ b/include/asm-generic/qspinlock.h > > @@ -28,30 +28,13 @@ > > */ > > static __always_inline int queued_spin_is_locked(struct qspinlock *lock) > > { > > + /* > > +* See queued_spin_unlock_wait(). > > * > > +*

Re: [PATCH 01/20] x86, intel: Introduce macros for Intel family numbers

On Wed, Jun 01, 2016 at 05:11:57PM -0700, Dave Hansen wrote: > > From: Dave Hansen > > If you are cc'd on this code, please check _your_ code vs. the > model list in "intel-family.h". Please make sure you have all > the models listed that you intend to. > >

Re: [PATCH 01/20] x86, intel: Introduce macros for Intel family numbers

On Wed, Jun 01, 2016 at 05:11:57PM -0700, Dave Hansen wrote: > > From: Dave Hansen > > If you are cc'd on this code, please check _your_ code vs. the > model list in "intel-family.h". Please make sure you have all > the models listed that you intend to. > > Problem: > > We have a boatload of

Re: [PATCH 01/20] x86, intel: Introduce macros for Intel family numbers

On Thursday, June 02, 2016 08:57:15 AM Borislav Petkov wrote: > On Wed, Jun 01, 2016 at 05:11:57PM -0700, Dave Hansen wrote: > > +#define INTEL_FAM6_MODEL_CORE_YONAH0x0E > > +#define INTEL_FAM6_MODEL_CORE2_MEROM 0x0F > > That "MODEL_" part looks redundant too IMO -

Re: [PATCH 01/20] x86, intel: Introduce macros for Intel family numbers

On Thursday, June 02, 2016 08:57:15 AM Borislav Petkov wrote: > On Wed, Jun 01, 2016 at 05:11:57PM -0700, Dave Hansen wrote: > > +#define INTEL_FAM6_MODEL_CORE_YONAH0x0E > > +#define INTEL_FAM6_MODEL_CORE2_MEROM 0x0F > > That "MODEL_" part looks redundant too IMO -

Re: [PATCH] of: use pr_fmt prefix for all console printing

On 06/02/16 12:56, Rob Herring wrote: > On Thu, Jun 2, 2016 at 12:33 PM, Frank Rowand wrote: >> On 06/02/16 08:14, Rob Herring wrote: >>> Clean-up all the DT printk functions to use common pr_fmt prefix. >>> >>> Some print statements such as kmalloc errors were redundant,

Re: [PATCH] of: use pr_fmt prefix for all console printing

On 06/02/16 12:56, Rob Herring wrote: > On Thu, Jun 2, 2016 at 12:33 PM, Frank Rowand wrote: >> On 06/02/16 08:14, Rob Herring wrote: >>> Clean-up all the DT printk functions to use common pr_fmt prefix. >>> >>> Some print statements such as kmalloc errors were redundant, so just >>> drop those.

Re: [PATCH tty-next] devpts: Make each mount of devpts an independent filesystem.

On Thu, Jun 2, 2016 at 2:23 PM, Eric W. Biederman wrote: > > We certainly don't need the permission check. I agree that we don't need it, but it does simplify the code, and it doesn't actually harm anything, since the thing we check for permissions is the same /dev

Re: [PATCH tty-next] devpts: Make each mount of devpts an independent filesystem.

On Thu, Jun 2, 2016 at 2:23 PM, Eric W. Biederman wrote: > > We certainly don't need the permission check. I agree that we don't need it, but it does simplify the code, and it doesn't actually harm anything, since the thing we check for permissions is the same /dev directory, which we already

[PATCH 1/6] clk: Add missing clk_get_sys() stub

When compiling with the COMPILE_TEST option set, the clps711x does not compile because of the clk_get_sys() noop stub missing. Signed-off-by: Daniel Lezcano --- include/linux/clk.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/clk.h

[PATCH 1/6] clk: Add missing clk_get_sys() stub

When compiling with the COMPILE_TEST option set, the clps711x does not compile because of the clk_get_sys() noop stub missing. Signed-off-by: Daniel Lezcano --- include/linux/clk.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/clk.h b/include/linux/clk.h index

[PATCH 2/6] clocksource/drivers/bcm_kona: Remove useless header

The driver includes the header but it is pointless. Remove it. Signed-off-by: Daniel Lezcano --- drivers/clocksource/bcm_kona_timer.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/clocksource/bcm_kona_timer.c b/drivers/clocksource/bcm_kona_timer.c

[PATCH 4/6] clocksource/drivers/armv7m_systick: Add the COMPILE_TEST option

In order to increase the compilation test coverage, add the COMPILE_TEST so the driver can be compiled even if it does not belong to the platform or the architecture. Signed-off-by: Daniel Lezcano --- drivers/clocksource/Kconfig | 2 +- 1 file changed, 1 insertion(+),

[PATCH 2/6] clocksource/drivers/bcm_kona: Remove useless header

The driver includes the header but it is pointless. Remove it. Signed-off-by: Daniel Lezcano --- drivers/clocksource/bcm_kona_timer.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/clocksource/bcm_kona_timer.c b/drivers/clocksource/bcm_kona_timer.c index e717e87..fd11d59 100644

[PATCH 4/6] clocksource/drivers/armv7m_systick: Add the COMPILE_TEST option

In order to increase the compilation test coverage, add the COMPILE_TEST so the driver can be compiled even if it does not belong to the platform or the architecture. Signed-off-by: Daniel Lezcano --- drivers/clocksource/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 5/6] clocksource/drivers/bcm_kona: Add the COMPILE_TEST option

Change the Kconfig option logic to fullfil with the current approach. A new Kconfig option is added, CONFIG_BCM_KONA_TIMER and is selected by the platform. Then the clocksource's Kconfig is changed to make this option selectable by the user if the COMPILE_TEST option is set. Otherwise, it is up

[PATCH 3/6] clocksource/drivers/bcm2835: Add the COMPILE_TEST option

Change the Kconfig option logic to fullfil with the current approach. A new Kconfig option is added, CONFIG_BCM2835_TIMER and is selected by the platform. Then the clocksource's Kconfig is changed to make this option selectable by the user if the COMPILE_TEST option is set. Otherwise, it is up to

[PATCH 5/6] clocksource/drivers/bcm_kona: Add the COMPILE_TEST option

Change the Kconfig option logic to fullfil with the current approach. A new Kconfig option is added, CONFIG_BCM_KONA_TIMER and is selected by the platform. Then the clocksource's Kconfig is changed to make this option selectable by the user if the COMPILE_TEST option is set. Otherwise, it is up

[PATCH 3/6] clocksource/drivers/bcm2835: Add the COMPILE_TEST option

Change the Kconfig option logic to fullfil with the current approach. A new Kconfig option is added, CONFIG_BCM2835_TIMER and is selected by the platform. Then the clocksource's Kconfig is changed to make this option selectable by the user if the COMPILE_TEST option is set. Otherwise, it is up to

[PATCH 6/6] clocksource/drivers/clps_711x: Add the COMPILE_TEST option

Change the Kconfig option logic to fullfil with the current approach. A new Kconfig option is added, CONFIG_BCM_KONA_TIMER and is selected by the platform. Then the clocksource's Kconfig is changed to make this option selectable by the user if the COMPILE_TEST option is set. Otherwise, it is up

[PATCH 6/6] clocksource/drivers/clps_711x: Add the COMPILE_TEST option

Change the Kconfig option logic to fullfil with the current approach. A new Kconfig option is added, CONFIG_BCM_KONA_TIMER and is selected by the platform. Then the clocksource's Kconfig is changed to make this option selectable by the user if the COMPILE_TEST option is set. Otherwise, it is up

Re: [PATCH 32/32] mmc: bcm2835: Import bcm2835-mmc and switch to it

Stefan Wahren writes: > Hi Eric, > >> Eric Anholt hat am 2. Juni 2016 um 20:18 geschrieben: >> >> >> Stefan Wahren writes: >> >> > Hi Gerd, >> > >> > Am 01.06.2016 um 23:43 schrieb Gerd Hoffmann: >> >> From: Eric Anholt

Re: [PATCH 32/32] mmc: bcm2835: Import bcm2835-mmc and switch to it

Stefan Wahren writes: > Hi Eric, > >> Eric Anholt hat am 2. Juni 2016 um 20:18 geschrieben: >> >> >> Stefan Wahren writes: >> >> > Hi Gerd, >> > >> > Am 01.06.2016 um 23:43 schrieb Gerd Hoffmann: >> >> From: Eric Anholt >> >> >> >> With this we can get wifi (brcmfmac) to probe. Without it

Re: [PATCH tty-next] devpts: Make each mount of devpts an independent filesystem.

"H. Peter Anvin" writes: > On 06/02/16 13:22, Eric W. Biederman wrote: >> >> The problem with lookup_one_len_unlocked is that it still calls >> inode_permission. >> >> As per previous discussions we don't want the path based permission >> checks involved in that lookup. >> > >

Re: [PATCH tty-next] devpts: Make each mount of devpts an independent filesystem.

"H. Peter Anvin" writes: > On 06/02/16 13:22, Eric W. Biederman wrote: >> >> The problem with lookup_one_len_unlocked is that it still calls >> inode_permission. >> >> As per previous discussions we don't want the path based permission >> checks involved in that lookup. >> > > Is it that we

Re: [PATCH] usb: musbhsdma: Add space after that ','.

Hi, On Wed, Jun 01, 2016 at 09:49:35AM -0400, Sandhya Bankar wrote: > Add space after that ','. > > Signed-off-by: Sandhya Bankar Please revise the subject prefix to "usb: musb: musbhsdma: ...". Regards, -Bin.

Re: [PATCH] usb: musbhsdma: Add space after that ','.

Hi, On Wed, Jun 01, 2016 at 09:49:35AM -0400, Sandhya Bankar wrote: > Add space after that ','. > > Signed-off-by: Sandhya Bankar Please revise the subject prefix to "usb: musb: musbhsdma: ...". Regards, -Bin.

Re: [PATCH] usb: musb_host: Use sizeof(*qh)instead of sizeof *qh.

Hi, On Wed, Jun 01, 2016 at 09:40:06AM -0400, Sandhya Bankar wrote: > Use sizeof(*qh)instead of sizeof *qh. > > Signed-off-by: Sandhya Bankar Please revise the subject prefix to "usb: musb: host: ...". Regards, -Bin.

Re: [PATCH] usb: musb_host: Use sizeof(*qh)instead of sizeof *qh.

Hi, On Wed, Jun 01, 2016 at 09:40:06AM -0400, Sandhya Bankar wrote: > Use sizeof(*qh)instead of sizeof *qh. > > Signed-off-by: Sandhya Bankar Please revise the subject prefix to "usb: musb: host: ...". Regards, -Bin.

Re: [PATCH] device tree description for AD5820 camera auto-focus coil

On Thu, Jun 02, 2016 at 09:30:27PM +0200, Pavel Machek wrote: > > Add documentation for ad5820 device tree binding. > > Signed-off-by: Pavel Machek Thanks, Pavel!! Can I pick the two patches (this one + the driver) or would you like to send a pull request? In the latter case

Re: [PATCH] device tree description for AD5820 camera auto-focus coil

On Thu, Jun 02, 2016 at 09:30:27PM +0200, Pavel Machek wrote: > > Add documentation for ad5820 device tree binding. > > Signed-off-by: Pavel Machek Thanks, Pavel!! Can I pick the two patches (this one + the driver) or would you like to send a pull request? In the latter case you can add:

Re: [PATCH 3/3] Update efi_thunk to use efi_call_virt_generic

On Thu, Jun 02, 2016 at 09:19:49PM +0100, Matt Fleming wrote: > On Wed, 18 May, at 02:11:41PM, Alex Thorlton wrote: > > +#define arch_efi_call_virt(p, f, ...) > > \ > > +({ \ > > + u32 func =

Re: [PATCH 3/3] Update efi_thunk to use efi_call_virt_generic

On Thu, Jun 02, 2016 at 09:19:49PM +0100, Matt Fleming wrote: > On Wed, 18 May, at 02:11:41PM, Alex Thorlton wrote: > > +#define arch_efi_call_virt(p, f, ...) > > \ > > +({ \ > > + u32 func =

Re: [PATCH/RFC 0/1] soc: renesas: Add DT fixup code for backwards compatibility

Hi Rob and Geert, On Wednesday 01 Jun 2016 15:27:59 Rob Herring wrote: > On Wed, Jun 1, 2016 at 2:50 PM, Geert Uytterhoeven wrote: > > Hi all, > > > > When moving functionality from C code to DT, we're regularly faced with > > stable DT issues: old DTBs should keep on working. This requires

Re: [PATCH/RFC 0/1] soc: renesas: Add DT fixup code for backwards compatibility

Hi Rob and Geert, On Wednesday 01 Jun 2016 15:27:59 Rob Herring wrote: > On Wed, Jun 1, 2016 at 2:50 PM, Geert Uytterhoeven wrote: > > Hi all, > > > > When moving functionality from C code to DT, we're regularly faced with > > stable DT issues: old DTBs should keep on working. This requires

Re: [PATCHv5] support for AD5820 camera auto-focus coil

On Thu, Jun 02, 2016 at 09:27:37PM +0200, Pavel Machek wrote: > On Thu 2016-06-02 10:45:45, Sakari Ailus wrote: > > On Thu, Jun 02, 2016 at 12:08:40AM +0200, Pavel Machek wrote: > > > On Wed 2016-06-01 18:24:39, Sakari Ailus wrote: > > > > Hi Pavel, > > > > > > > > Well, it does not use any dt

Re: [PATCHv5] support for AD5820 camera auto-focus coil

On Thu, Jun 02, 2016 at 09:27:37PM +0200, Pavel Machek wrote: > On Thu 2016-06-02 10:45:45, Sakari Ailus wrote: > > On Thu, Jun 02, 2016 at 12:08:40AM +0200, Pavel Machek wrote: > > > On Wed 2016-06-01 18:24:39, Sakari Ailus wrote: > > > > Hi Pavel, > > > > > > > > Well, it does not use any dt

Re: [REGRESSION] Headphones no longer working on MacPro6,1 with 4.4

On 05/24/2016 10:54 AM, Takashi Iwai wrote: On Tue, 24 May 2016 18:41:06 +0200, Laura Abbott wrote: Node 0x10 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x42,

Re: [REGRESSION] Headphones no longer working on MacPro6,1 with 4.4

On 05/24/2016 10:54 AM, Takashi Iwai wrote: On Tue, 24 May 2016 18:41:06 +0200, Laura Abbott wrote: Node 0x10 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x42,

Re: [PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic

On Thu, Jun 02, 2016 at 08:45:47PM +0100, Matt Fleming wrote: > Unless I've missed it, I didn't see an explanation in the changelog of > why it's OK to switch from using __va(tab->function) to tab->function > directly, which presumably is a physical address. > > Was that intended? It was

Re: [PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic

On Thu, Jun 02, 2016 at 08:45:47PM +0100, Matt Fleming wrote: > Unless I've missed it, I didn't see an explanation in the changelog of > why it's OK to switch from using __va(tab->function) to tab->function > directly, which presumably is a physical address. > > Was that intended? It was

[PATCH v2 -next] virtio-net: Add initial MTU advice feature

This commit adds the feature bit and associated mtu device entry for the virtio network device. When a virtio device comes up, it checks the feature bit for the VIRTIO_NET_F_MTU feature. If such feature bit is enabled, the driver will read the advised MTU and use it as the initial value.

[PATCH v2 -next] virtio-net: Add initial MTU advice feature

This commit adds the feature bit and associated mtu device entry for the virtio network device. When a virtio device comes up, it checks the feature bit for the VIRTIO_NET_F_MTU feature. If such feature bit is enabled, the driver will read the advised MTU and use it as the initial value.

Re: [PATCH 5/8] x86, pkeys: allocation/free syscalls

On 06/01/2016 01:48 PM, Arnd Bergmann wrote: >> +330common pkey_alloc sys_pkey_alloc >> > +331common pkey_free sys_pkey_free >> > >> > # >> > # x32-specific system call numbers start at 512 to avoid cache impact >> > > Could you also add the system call

Re: [PATCH 5/8] x86, pkeys: allocation/free syscalls

On 06/01/2016 01:48 PM, Arnd Bergmann wrote: >> +330common pkey_alloc sys_pkey_alloc >> > +331common pkey_free sys_pkey_free >> > >> > # >> > # x32-specific system call numbers start at 512 to avoid cache impact >> > > Could you also add the system call

Re: [PATCH v1 1/2] ARM: dts: keystone: remove bogus IO resource entry from PCI binding

On 06/02/2016 02:08 PM, Santosh Shilimkar wrote: > On 6/2/2016 8:17 AM, Murali Karicheri wrote: >> The PCI DT bindings contain a bogus entry for IO space which is not >> supported on Keystone. The current bogus entry has an invalid size >> and throws following error during boot. >> >> [0.420713]

Re: [PATCH v1 1/2] ARM: dts: keystone: remove bogus IO resource entry from PCI binding

On 06/02/2016 02:08 PM, Santosh Shilimkar wrote: > On 6/2/2016 8:17 AM, Murali Karicheri wrote: >> The PCI DT bindings contain a bogus entry for IO space which is not >> supported on Keystone. The current bogus entry has an invalid size >> and throws following error during boot. >> >> [0.420713]

Re: [PATCH 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid

Hi Boris, Thank you for the patch. On Thursday 02 Jun 2016 16:31:28 Boris Brezillon wrote: > Adapt drm_pick_crtcs() and update_connector_routing() to fallback to > drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so > that DRM drivers can leave this hook unassigned if they know

Re: [PATCH 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid

Hi Boris, Thank you for the patch. On Thursday 02 Jun 2016 16:31:28 Boris Brezillon wrote: > Adapt drm_pick_crtcs() and update_connector_routing() to fallback to > drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so > that DRM drivers can leave this hook unassigned if they know

Re: [PATCH v2 5/6] ethernet/intel: Use pci_(request|release)_mem_regions

On Thu, 2016-06-02 at 09:30 +0200, Johannes Thumshirn wrote: > Now that we do have pci_request_mem_regions() and > pci_release_mem_regions() at > hand, use it in the Intel ethernet drivers. > > Suggested-by: Christoph Hellwig > Signed-off-by: Johannes Thumshirn

Re: [PATCH v2 5/6] ethernet/intel: Use pci_(request|release)_mem_regions

On Thu, 2016-06-02 at 09:30 +0200, Johannes Thumshirn wrote: > Now that we do have pci_request_mem_regions() and > pci_release_mem_regions() at > hand, use it in the Intel ethernet drivers. > > Suggested-by: Christoph Hellwig > Signed-off-by: Johannes Thumshirn > Cc: Jeff Kirsher > Cc: David

[RFC PATCH] x86/efi: Auto enable EFI memmap on SGI UV systems

The intent here is to automatically enable the EFI memory map entries on SGI UV systems, which can have more than 128 E820 entries and will cause headaches if the EFI memory map entries are not added. The assumption is made that the community would prefer that this change be a UV specific quirk,

[RFC PATCH] x86/efi: Auto enable EFI memmap on SGI UV systems

The intent here is to automatically enable the EFI memory map entries on SGI UV systems, which can have more than 128 E820 entries and will cause headaches if the EFI memory map entries are not added. The assumption is made that the community would prefer that this change be a UV specific quirk,

Re: [PATCH 16/20] drm: omap: Rely on the default ->best_encoder() behavior

Hi Boris, Thank you for the patch. On Thursday 02 Jun 2016 16:31:43 Boris Brezillon wrote: > We have a 1:1 relationship between connectors and encoders and the > driver is relying on the atomic helpers: we can drop the custom > ->best_encoder() implementation and let the core call >

Re: [PATCH 16/20] drm: omap: Rely on the default ->best_encoder() behavior

Hi Boris, Thank you for the patch. On Thursday 02 Jun 2016 16:31:43 Boris Brezillon wrote: > We have a 1:1 relationship between connectors and encoders and the > driver is relying on the atomic helpers: we can drop the custom > ->best_encoder() implementation and let the core call >

Re: [PATCH 09/20] drm: rcar-du: Rely on the default ->best_encoder() behavior

Hi Boris, Thank you for the patch. On Thursday 02 Jun 2016 16:31:36 Boris Brezillon wrote: > All outputs have a 1:1 relationship between connectors and encoders, > and the driver is relying on the atomic helpers: we can drop the custom > ->best_encoder() implementations and let the core call >

Re: [PATCH 09/20] drm: rcar-du: Rely on the default ->best_encoder() behavior

Hi Boris, Thank you for the patch. On Thursday 02 Jun 2016 16:31:36 Boris Brezillon wrote: > All outputs have a 1:1 relationship between connectors and encoders, > and the driver is relying on the atomic helpers: we can drop the custom > ->best_encoder() implementations and let the core call >

[PATCH] x86/efi: Auto enable EFI memmap on SGI UV systems

Currently, the EFI memory map entries are disabled by default and must be enabled by passing the kernel boot option: add_efi_memmap The EFI memory map entries should be enabled on systems with more than 128 E820 entries, which includes many UV systems. Check if we're on a UV system by chekcing

[PATCH] x86/efi: Auto enable EFI memmap on SGI UV systems

Currently, the EFI memory map entries are disabled by default and must be enabled by passing the kernel boot option: add_efi_memmap The EFI memory map entries should be enabled on systems with more than 128 E820 entries, which includes many UV systems. Check if we're on a UV system by chekcing

Re: [PATCH] MAINTAINERS: Remove Muli Ben-Yahuda from Calgary x86-64 IOMMU entry

Maybe Muli Ben-Yehuda ? On Thu, 02 Jun 2016 17:58:47 +0200 Krzysztof Kozlowski wrote: > Muli Ben-Yahuda's email bounces so remove him from Calgary IOMMU. He is > already present in CREDITS for that. > > Cc: disc...@x86-64.org > Cc: Jon D. Mason

Re: [PATCH] MAINTAINERS: Remove Muli Ben-Yahuda from Calgary x86-64 IOMMU entry

Maybe Muli Ben-Yehuda ? On Thu, 02 Jun 2016 17:58:47 +0200 Krzysztof Kozlowski wrote: > Muli Ben-Yahuda's email bounces so remove him from Calgary IOMMU. He is > already present in CREDITS for that. > > Cc: disc...@x86-64.org > Cc: Jon D. Mason > Signed-off-by: Krzysztof Kozlowski > --- >

Re: [PATCH tty-next] devpts: Make each mount of devpts an independent filesystem.

On 06/02/16 13:22, Eric W. Biederman wrote: > > The problem with lookup_one_len_unlocked is that it still calls > inode_permission. > > As per previous discussions we don't want the path based permission > checks involved in that lookup. > Is it that we don't *want* it, or that we don't *need*

Re: [PATCH tty-next] devpts: Make each mount of devpts an independent filesystem.

On 06/02/16 13:22, Eric W. Biederman wrote: > > The problem with lookup_one_len_unlocked is that it still calls > inode_permission. > > As per previous discussions we don't want the path based permission > checks involved in that lookup. > Is it that we don't *want* it, or that we don't *need*

Re: [PART2 RFC v1 1/9] iommu/amd: Detect and enable guest vAPIC support

On 5/9/2016 6:49 AM, Joerg Roedel wrote: On Fri, Apr 08, 2016 at 07:49:22AM -0500, Suthikulpanit, Suravee wrote: From: Suravee Suthikulpanit This patch introduces a new IOMMU driver parameter, amd_iommu_guest_ir, which can be used to specify different interrupt

Re: [PART2 RFC v1 1/9] iommu/amd: Detect and enable guest vAPIC support

On 5/9/2016 6:49 AM, Joerg Roedel wrote: On Fri, Apr 08, 2016 at 07:49:22AM -0500, Suthikulpanit, Suravee wrote: From: Suravee Suthikulpanit This patch introduces a new IOMMU driver parameter, amd_iommu_guest_ir, which can be used to specify different interrupt remapping mode for passthrough

Re: [PATCH 5/5] intel_idle: Add S0ix validation

On Thu, Jun 2, 2016 at 12:53 PM, One Thousand Gnomes wrote: >> How would this spuriously trigger during boot? This code is only run >> during freeze. If there's some issue with not entering S0ix before a >> module or firmware is loaded, it's better to not use suspend

Re: [PATCH 5/5] intel_idle: Add S0ix validation

On Thu, Jun 2, 2016 at 12:53 PM, One Thousand Gnomes wrote: >> How would this spuriously trigger during boot? This code is only run >> during freeze. If there's some issue with not entering S0ix before a >> module or firmware is loaded, it's better to not use suspend to idle >> until those are in

Re: [PATCH v8 00/14] Add support for remote unwind

On Thu, Jun 02, 2016 at 09:55:12AM +, He Kuang wrote: SNIP > and now we can use LIBUNWIND_DIR to specific custom dirctories > containing libunwind libs. > > v8: > > - Put unwind__register_ops call into unwind__prepare_access from >patch 4 to patch 3. > - Fail thread__insert_map on

Re: [PATCH v8 00/14] Add support for remote unwind

On Thu, Jun 02, 2016 at 09:55:12AM +, He Kuang wrote: SNIP > and now we can use LIBUNWIND_DIR to specific custom dirctories > containing libunwind libs. > > v8: > > - Put unwind__register_ops call into unwind__prepare_access from >patch 4 to patch 3. > - Fail thread__insert_map on

Re: [PATCH v8 03/14] perf tools: Introducing struct unwind_libunwind_ops for local unwind

On Thu, Jun 02, 2016 at 09:55:15AM +, He Kuang wrote: SNIP > @@ -680,3 +680,52 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg, > > return get_entries(, cb, arg, max_stack); > } > + > +static struct unwind_libunwind_ops > +_unwind_libunwind_ops = { > + .prepare_access

Re: [PATCH 00/11] cpufreq: Keep policy->freq_table sorted

On Thu, Jun 2, 2016 at 5:42 PM, Viresh Kumar wrote: > On 2 June 2016 at 20:38, Rafael J. Wysocki wrote: >> On Thu, Jun 2, 2016 at 4:19 PM, Viresh Kumar wrote: >>> Hi Rafael, >>> >>> This series fixes all cpufreq drivers that

Re: [PATCH v8 03/14] perf tools: Introducing struct unwind_libunwind_ops for local unwind

On Thu, Jun 02, 2016 at 09:55:15AM +, He Kuang wrote: SNIP > @@ -680,3 +680,52 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg, > > return get_entries(, cb, arg, max_stack); > } > + > +static struct unwind_libunwind_ops > +_unwind_libunwind_ops = { > + .prepare_access

Re: [PATCH 00/11] cpufreq: Keep policy->freq_table sorted

On Thu, Jun 2, 2016 at 5:42 PM, Viresh Kumar wrote: > On 2 June 2016 at 20:38, Rafael J. Wysocki wrote: >> On Thu, Jun 2, 2016 at 4:19 PM, Viresh Kumar wrote: >>> Hi Rafael, >>> >>> This series fixes all cpufreq drivers that provide a 'target_index' >>> callback or in other words, which provide

Re: [PATCH tty-next] devpts: Make each mount of devpts an independent filesystem.

Linus Torvalds writes: > On Thu, Jun 2, 2016 at 8:29 AM, Eric W. Biederman > wrote: >> >> The /dev/ptmx device node is changed to lookup the directory entry >> "pts" in the same directory as the /dev/ptmx device node was opened >> in. If

Re: [PATCH v8 04/14] perf tools: Move unwind__prepare_access from thread_new into thread__insert_map

On Thu, Jun 02, 2016 at 09:55:16AM +, He Kuang wrote: SNIP > } > > -void thread__insert_map(struct thread *thread, struct map *map) > +int thread__insert_map(struct thread *thread, struct map *map) > { > + int ret; > + > map_groups__fixup_overlappings(thread->mg, map, stderr);

Re: [PATCH v8 08/14] perf tools: Extract common API out of unwind-libunwind-local.c

On Thu, Jun 02, 2016 at 09:55:20AM +, He Kuang wrote: SNIP > +void unwind__finish_access(struct thread *thread) > +{ > + if (thread->unwind_libunwind_ops) > + thread->unwind_libunwind_ops->finish_access(thread); > +} > + > +int unwind__get_entries(unwind_entry_cb_t cb, void

Re: [PATCH v8 08/14] perf tools: Extract common API out of unwind-libunwind-local.c

On Thu, Jun 02, 2016 at 09:55:20AM +, He Kuang wrote: SNIP > +void unwind__finish_access(struct thread *thread) > +{ > + if (thread->unwind_libunwind_ops) > + thread->unwind_libunwind_ops->finish_access(thread); > +} > + > +int unwind__get_entries(unwind_entry_cb_t cb, void

Re: [PATCH tty-next] devpts: Make each mount of devpts an independent filesystem.

Linus Torvalds writes: > On Thu, Jun 2, 2016 at 8:29 AM, Eric W. Biederman > wrote: >> >> The /dev/ptmx device node is changed to lookup the directory entry >> "pts" in the same directory as the /dev/ptmx device node was opened >> in. If there is a "pts" entry and that entry is a devpts

Re: [PATCH v8 04/14] perf tools: Move unwind__prepare_access from thread_new into thread__insert_map

On Thu, Jun 02, 2016 at 09:55:16AM +, He Kuang wrote: SNIP > } > > -void thread__insert_map(struct thread *thread, struct map *map) > +int thread__insert_map(struct thread *thread, struct map *map) > { > + int ret; > + > map_groups__fixup_overlappings(thread->mg, map, stderr);

Re: [PATCH v8 13/14] perf callchain: Support x86 target platform

On Thu, Jun 02, 2016 at 09:55:25AM +, He Kuang wrote: SNIP > @@ -31,9 +33,17 @@ int unwind__prepare_access(struct thread *thread, struct > map *map) > return 0; > > arch = normalize_arch(thread->mg->machine->env->arch); > - pr_debug("unwind: target platform=%s\n",

Re: [PATCH v8 13/14] perf callchain: Support x86 target platform

On Thu, Jun 02, 2016 at 09:55:25AM +, He Kuang wrote: SNIP > @@ -31,9 +33,17 @@ int unwind__prepare_access(struct thread *thread, struct > map *map) > return 0; > > arch = normalize_arch(thread->mg->machine->env->arch); > - pr_debug("unwind: target platform=%s\n",

[PATCH net-next] net: disable fragment reassembly if high_thresh is zero

Before commit 6d7b857d541e ("net: use lib/percpu_counter API for fragmentation mem accounting"), setting the reassembly high threshold to 0 prevented fragment reassembly as first fragment would be always evicted before second could be added to the queue. While inefficient, some users apparently

[PATCH net-next] net: disable fragment reassembly if high_thresh is zero

Before commit 6d7b857d541e ("net: use lib/percpu_counter API for fragmentation mem accounting"), setting the reassembly high threshold to 0 prevented fragment reassembly as first fragment would be always evicted before second could be added to the queue. While inefficient, some users apparently

Re: [RESEND PATCH v4 5/5] thermal: rockchip: add the set_trips function

On Fri, May 27, 2016 at 1:36 AM, Caesar Wang wrote: > Whenever the current temperature is updated, the trip points immediately > below and above the current temperature are found. A sensor driver > callback `set_trips' is then called with the temperatures. > Lastly, The

Re: [RESEND PATCH v4 5/5] thermal: rockchip: add the set_trips function

On Fri, May 27, 2016 at 1:36 AM, Caesar Wang wrote: > Whenever the current temperature is updated, the trip points immediately > below and above the current temperature are found. A sensor driver > callback `set_trips' is then called with the temperatures. > Lastly, The sensor will trigger the

Re: [PATCH 3/3] Update efi_thunk to use efi_call_virt_generic

On Wed, 18 May, at 02:11:41PM, Alex Thorlton wrote: > diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h > index f310f0b..6643f9b 100644 > --- a/arch/x86/include/asm/efi.h > +++ b/arch/x86/include/asm/efi.h > @@ -68,6 +68,52 @@ struct efi_scratch { > u64 phys_stack; >

Re: [PATCH 3/3] Update efi_thunk to use efi_call_virt_generic

On Wed, 18 May, at 02:11:41PM, Alex Thorlton wrote: > diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h > index f310f0b..6643f9b 100644 > --- a/arch/x86/include/asm/efi.h > +++ b/arch/x86/include/asm/efi.h > @@ -68,6 +68,52 @@ struct efi_scratch { > u64 phys_stack; >

Re: Anyone have a clone of wireless-legacy.git?

On Thu, Jun 02, 2016 at 08:48:08PM +0100, One Thousand Gnomes wrote: > On Thu, 2 Jun 2016 14:38:04 -0400 > "John W. Linville" wrote: > > > It has recently come to my attention that the old wireless-legacy.git > > tree is no longer available on kernel.org. I honestly have

Re: Anyone have a clone of wireless-legacy.git?

On Thu, Jun 02, 2016 at 08:48:08PM +0100, One Thousand Gnomes wrote: > On Thu, 2 Jun 2016 14:38:04 -0400 > "John W. Linville" wrote: > > > It has recently come to my attention that the old wireless-legacy.git > > tree is no longer available on kernel.org. I honestly have no idea > > what

Re: [PATCH 4/4] powerpc/mm/radix: Implement tlb mmu gather flush efficiently

On Thu, 2 Jun 2016 15:09:49 +0530 "Aneesh Kumar K.V" wrote: > Now that we track page size in mmu_gather, we can use address based > tlbie format when doing a tlb_flush(). We don't do this if we are > invalidating the full address space. > > ... > > void

Re: [PATCH 4/4] powerpc/mm/radix: Implement tlb mmu gather flush efficiently

On Thu, 2 Jun 2016 15:09:49 +0530 "Aneesh Kumar K.V" wrote: > Now that we track page size in mmu_gather, we can use address based > tlbie format when doing a tlb_flush(). We don't do this if we are > invalidating the full address space. > > ... > > void radix__tlb_flush(struct mmu_gather

Re: [PATCH] of: use pr_fmt prefix for all console printing

On Thu, 2016-06-02 at 14:56 -0500, Rob Herring wrote: > On Thu, Jun 2, 2016 at 12:33 PM, Frank Rowand wrote: [] > > > @@ -355,8 +355,6 @@ int of_overlay_create(struct device_node *tree) > > > > > >   id = idr_alloc(_idr, ov, 0, 0, GFP_KERNEL); > > >   if (id < 0)

Re: [PATCH] of: use pr_fmt prefix for all console printing

On Thu, 2016-06-02 at 14:56 -0500, Rob Herring wrote: > On Thu, Jun 2, 2016 at 12:33 PM, Frank Rowand wrote: [] > > > @@ -355,8 +355,6 @@ int of_overlay_create(struct device_node *tree) > > > > > >   id = idr_alloc(_idr, ov, 0, 0, GFP_KERNEL); > > >   if (id < 0) { > > > - 

[GIT PULL] KVM fixes for v4.7-rc2

Linus, The following changes since commit 1a695a905c18548062509178b98bc91e67510864: Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you to fetch changes up to

[GIT PULL] KVM fixes for v4.7-rc2

Linus, The following changes since commit 1a695a905c18548062509178b98bc91e67510864: Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you to fetch changes up to

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