Re: [PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold

On Tue, 3 May 2016 15:56:44 -0400 Luiz Capitulino wrote: > On Tue, 3 May 2016 12:59:53 -0500 > Clark Williams wrote: > > > John, > > > > This patch is against the devel/v0.98 branch. It turns off tracing in the > > tracemark() so that we don't

Re: [PATCH mmotm] radix-tree: rewrite radix_tree_locate_item fix

On Sun, May 01, 2016 at 09:13:18PM -0700, Hugh Dickins wrote: > radix_tree_locate_item() is often returning the wrong index, causing > swapoff of shmem to hang because it cannot find the swap entry there. > __locate()'s use of base is bogus, it adds an offset twice into index. > > Signed-off-by:

[PATCH net] bridge: fix igmp / mld query parsing

With the newly introduced helper functions the skb pulling is hidden in the checksumming function - and undone before returning to the caller. The IGMP and MLD query parsing functions in the bridge still assumed that the skb is pointing to the beginning of the IGMP/MLD message while it is now

Re: [PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold

On Tue, 3 May 2016 15:56:44 -0400 Luiz Capitulino wrote: > On Tue, 3 May 2016 12:59:53 -0500 > Clark Williams wrote: > > > John, > > > > This patch is against the devel/v0.98 branch. It turns off tracing in the > > tracemark() so that we don't lose information about what was going on when >

Re: [PATCH mmotm] radix-tree: rewrite radix_tree_locate_item fix

On Sun, May 01, 2016 at 09:13:18PM -0700, Hugh Dickins wrote: > radix_tree_locate_item() is often returning the wrong index, causing > swapoff of shmem to hang because it cannot find the swap entry there. > __locate()'s use of base is bogus, it adds an offset twice into index. > > Signed-off-by:

[PATCH net] bridge: fix igmp / mld query parsing

With the newly introduced helper functions the skb pulling is hidden in the checksumming function - and undone before returning to the caller. The IGMP and MLD query parsing functions in the bridge still assumed that the skb is pointing to the beginning of the IGMP/MLD message while it is now

[PATCH] radix-tree: add test for radix_tree_locate_item()

Add a unit test that provides coverage for the bug fixed in the commit entitled "radix-tree: rewrite radix_tree_locate_item fix" from Hugh Dickins. I've verified that this test fails before his patch due to miscalculated 'index' values in __locate() in lib/radix-tree.c, and passes with his fix.

[PATCH] radix-tree: add test for radix_tree_locate_item()

Add a unit test that provides coverage for the bug fixed in the commit entitled "radix-tree: rewrite radix_tree_locate_item fix" from Hugh Dickins. I've verified that this test fails before his patch due to miscalculated 'index' values in __locate() in lib/radix-tree.c, and passes with his fix.

Re: [PATCH net] bridge: fix igmp / mld query parsing

On Tue, 3 May 2016 22:18:54 +0200 Linus Lüssing wrote: > diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c > index 03661d9..7105cdf 100644 > --- a/net/bridge/br_multicast.c > +++ b/net/bridge/br_multicast.c > @@ -1271,6 +1271,7 @@ static int

Re: [PATCH net] bridge: fix igmp / mld query parsing

On Tue, 3 May 2016 22:18:54 +0200 Linus Lüssing wrote: > diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c > index 03661d9..7105cdf 100644 > --- a/net/bridge/br_multicast.c > +++ b/net/bridge/br_multicast.c > @@ -1271,6 +1271,7 @@ static int br_ip4_multicast_query(struct

Re: [PATCH 3/6] statx: Ext4: Return enhanced file attributes

Andreas Dilger wrote: > > (3) FS_xxx_FL flags are returned as for ioctl(FS_IOC_GETFLAGS), setting > > STATX_IOC_FLAGS. > > I don't see where this is implemented in this patch, and it should be > removed from the commit message to avoid confusion. Oops - I forgot to

Re: [PATCH 3/6] statx: Ext4: Return enhanced file attributes

Andreas Dilger wrote: > > (3) FS_xxx_FL flags are returned as for ioctl(FS_IOC_GETFLAGS), setting > > STATX_IOC_FLAGS. > > I don't see where this is implemented in this patch, and it should be > removed from the commit message to avoid confusion. Oops - I forgot to remove it from the other

Re: [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use

Andreas Dilger wrote: > > __u32 st_win_attrs; > > It seems some of these flags are duplicated with the st_information field, > and some are duplicate with FS_IOC_GETFLAGS values, and returning the same > information in multiple ways is confusing. > > If these flags are

Re: [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use

Andreas Dilger wrote: > > __u32 st_win_attrs; > > It seems some of these flags are duplicated with the st_information field, > and some are duplicate with FS_IOC_GETFLAGS values, and returning the same > information in multiple ways is confusing. > > If these flags are part of the CIFS

Re: mainline build: 896 warnings 1 failures (mainline/v4.6-rc5-224-gda9373d)

On Monday 02 May 2016 19:12:31 Olof Johansson wrote: > On Mon, May 2, 2016 at 12:24 AM, Arnd Bergmann wrote: > > On Sunday 01 May 2016 16:19:53 Olof Johansson wrote: > >> On Sun, May 1, 2016 at 2:26 PM, Olof's autobuilder wrote: > >> > Here are the build results

Re: mainline build: 896 warnings 1 failures (mainline/v4.6-rc5-224-gda9373d)

On Monday 02 May 2016 19:12:31 Olof Johansson wrote: > On Mon, May 2, 2016 at 12:24 AM, Arnd Bergmann wrote: > > On Sunday 01 May 2016 16:19:53 Olof Johansson wrote: > >> On Sun, May 1, 2016 at 2:26 PM, Olof's autobuilder wrote: > >> > Here are the build results from automated periodic testing.

Re: [PATCH v2] x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

On Tue, May 03, 2016 at 01:47:04PM -0400, Josh Boyer wrote: > The promise of pretty boot splashes from firmware via BGRT was at > best only that; a promise. The kernel diligently checks to make > sure the BGRT data firmware gives it is valid, and dutifully warns > the user when it isn't.

Re: [PATCH v2] x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

On Tue, May 03, 2016 at 01:47:04PM -0400, Josh Boyer wrote: > The promise of pretty boot splashes from firmware via BGRT was at > best only that; a promise. The kernel diligently checks to make > sure the BGRT data firmware gives it is valid, and dutifully warns > the user when it isn't.

Re: [PATCH] phy: tegra-xusb: add pinctrl dependency

On Tuesday 03 May 2016 18:07:08 Thierry Reding wrote: > Wouldn't that be more of a case for a select dependency? I'm thinking > something like the below (untested, yet). > I usually prefer 'depends on' in a case like this, but it doesn't make a huge difference. If we end up using 'select' here,

Re: [PATCH] phy: tegra-xusb: add pinctrl dependency

On Tuesday 03 May 2016 18:07:08 Thierry Reding wrote: > Wouldn't that be more of a case for a select dependency? I'm thinking > something like the below (untested, yet). > I usually prefer 'depends on' in a case like this, but it doesn't make a huge difference. If we end up using 'select' here,

Re: [v8, 6/7] MAINTAINERS: add entry for Freescale SoC specific driver

On Mon, Apr 25, 2016 at 10:12 PM, Yangbo Lu wrote: > Hi Scott and Leo, > > >> -Original Message- >> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- >> ow...@vger.kernel.org] On Behalf Of Scott Wood >> Sent: Saturday, April 23, 2016 7:23 AM >> To: Yangbo Lu;

Re: [v8, 6/7] MAINTAINERS: add entry for Freescale SoC specific driver

On Mon, Apr 25, 2016 at 10:12 PM, Yangbo Lu wrote: > Hi Scott and Leo, > > >> -Original Message- >> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- >> ow...@vger.kernel.org] On Behalf Of Scott Wood >> Sent: Saturday, April 23, 2016 7:23 AM >> To: Yangbo Lu;

[GIT PULL] overlayfs fixes for 4.6-rc7

Hi Al, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-next This fixes two issues with overlayfs. Thanks, Miklos --- Miklos Szeredi (3): vfs: rename: check backing inode being equal vfs: export lookup_hash() to modules ovl: ignore

[GIT PULL] overlayfs fixes for 4.6-rc7

Hi Al, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-next This fixes two issues with overlayfs. Thanks, Miklos --- Miklos Szeredi (3): vfs: rename: check backing inode being equal vfs: export lookup_hash() to modules ovl: ignore

Re: linux-next: manual merge of the block tree with Linus' tree

On 05/02/2016 10:25 PM, Stephen Rothwell wrote: Hi Jens, Today's linux-next merge of the block tree got a conflict in: drivers/nvme/host/pci.c between commit: 9bf2b972afea ("NVMe: Fix reset/remove race") from Linus' tree and commit: bb8d261e0888 ("nvme: introduce a controller

Re: linux-next: manual merge of the block tree with Linus' tree

On 05/02/2016 10:25 PM, Stephen Rothwell wrote: Hi Jens, Today's linux-next merge of the block tree got a conflict in: drivers/nvme/host/pci.c between commit: 9bf2b972afea ("NVMe: Fix reset/remove race") from Linus' tree and commit: bb8d261e0888 ("nvme: introduce a controller

Re: VFIO MSIX Query

Hi, On Tue, 3 May 2016 23:56:38 +0530 Nitin Saxena wrote: > Hi, > > I am a newbie to VFIO framework and trying to use it for MSIX interrupt > handling in my userspace application. My userspace application is like > intel's dpdk. > > My query is why vfio kernel code does

Re: VFIO MSIX Query

Hi, On Tue, 3 May 2016 23:56:38 +0530 Nitin Saxena wrote: > Hi, > > I am a newbie to VFIO framework and trying to use it for MSIX interrupt > handling in my userspace application. My userspace application is like > intel's dpdk. > > My query is why vfio kernel code does not support msix

Re: [PATCH] mmc: omap: Use dma_request_chan() for requesting DMA channel

On 05/03/16 11:46, Ulf Hansson wrote: > On 29 April 2016 at 15:06, Peter Ujfalusi wrote: >> With the new dma_request_chan() the client driver does not need to look for >> the DMA resource and it does not need to pass filter_fn anymore. >> By switching to the new API the

Re: [PATCH] mmc: omap: Use dma_request_chan() for requesting DMA channel

On 05/03/16 11:46, Ulf Hansson wrote: > On 29 April 2016 at 15:06, Peter Ujfalusi wrote: >> With the new dma_request_chan() the client driver does not need to look for >> the DMA resource and it does not need to pass filter_fn anymore. >> By switching to the new API the driver can now support

Re: [PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold

On Tue, 3 May 2016 12:59:53 -0500 Clark Williams wrote: > John, > > This patch is against the devel/v0.98 branch. It turns off tracing in the > tracemark() so that we don't lose information about what was going on when we > hit the latency: > > > The current logic of

Re: [PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold

On Tue, 3 May 2016 12:59:53 -0500 Clark Williams wrote: > John, > > This patch is against the devel/v0.98 branch. It turns off tracing in the > tracemark() so that we don't lose information about what was going on when we > hit the latency: > > > The current logic of using --tracemark and

[PATCH] sched/fair: Update rq clock before updating nohz cpu load

If we're accessing rq_clock() (e.g. in sched_avg_update()) we should update the rq clock before calling cpu_load_update(), otherwise any time calculations will be stale. All other paths currently call update_rq_clock(). Cc: Peter Zijlstra Cc: Ingo Molnar

[PATCH] sched/fair: Update rq clock before updating nohz cpu load

If we're accessing rq_clock() (e.g. in sched_avg_update()) we should update the rq clock before calling cpu_load_update(), otherwise any time calculations will be stale. All other paths currently call update_rq_clock(). Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mike Galbraith Cc: Mel Gorman Cc:

[GIT PULL] fuse fixes for 4.6-rc7

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-linus to fix a regression and update the MAINTAINERS entry for fuse. Thanks, Miklos --- Ashish Samant (1): fuse: Fix return value from fuse_get_user_pages() Miklos Szeredi (1): fuse:

[GIT PULL] fuse fixes for 4.6-rc7

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-linus to fix a regression and update the MAINTAINERS entry for fuse. Thanks, Miklos --- Ashish Samant (1): fuse: Fix return value from fuse_get_user_pages() Miklos Szeredi (1): fuse:

Re: [RFC PATCH 2/7] ALSA: ac97: add an ac97 bus

Mark Brown writes: > On Sat, Apr 30, 2016 at 11:15:34PM +0200, Robert Jarzmik wrote: >> AC97 is a bus for sound usage. It enables for a AC97 AC-Link to link one >> controller to 0 to 4 AC97 codecs. > >> The goal of this new implementation is to implement a device/driver >>

Re: [RFC PATCH 2/7] ALSA: ac97: add an ac97 bus

Mark Brown writes: > On Sat, Apr 30, 2016 at 11:15:34PM +0200, Robert Jarzmik wrote: >> AC97 is a bus for sound usage. It enables for a AC97 AC-Link to link one >> controller to 0 to 4 AC97 codecs. > >> The goal of this new implementation is to implement a device/driver >> model for AC97, with

[PATCH v3 4/4] x86, boot: Memory hotplug support for KASLR memory randomization

Add a new option (CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING) to define the padding used for the physical memory mapping section when KASLR memory is enabled. It ensures there is enough virtual address space when CONFIG_MEMORY_HOTPLUG is used. The default value is 10 terabytes. If

[PATCH v3 1/4] x86, boot: Refactor KASLR entropy functions

Move the KASLR entropy functions in x86/libray to be used in early kernel boot for KASLR memory randomization. Signed-off-by: Thomas Garnier --- Based on next-20160502 --- arch/x86/boot/compressed/kaslr.c | 76 +++---

[PATCH v3 4/4] x86, boot: Memory hotplug support for KASLR memory randomization

Add a new option (CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING) to define the padding used for the physical memory mapping section when KASLR memory is enabled. It ensures there is enough virtual address space when CONFIG_MEMORY_HOTPLUG is used. The default value is 10 terabytes. If

[PATCH v3 1/4] x86, boot: Refactor KASLR entropy functions

Move the KASLR entropy functions in x86/libray to be used in early kernel boot for KASLR memory randomization. Signed-off-by: Thomas Garnier --- Based on next-20160502 --- arch/x86/boot/compressed/kaslr.c | 76 +++--- arch/x86/include/asm/kaslr.h | 6 +++

[PATCH v3 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Randomizes the virtual address space of kernel memory sections (physical memory mapping, vmalloc & vmemmap) for x86_64. This security feature mitigates exploits relying on predictable kernel addresses. These addresses can be used to disclose the kernel modules base addresses or corrupt specific

[PATCH v3 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Randomizes the virtual address space of kernel memory sections (physical memory mapping, vmalloc & vmemmap) for x86_64. This security feature mitigates exploits relying on predictable kernel addresses. These addresses can be used to disclose the kernel modules base addresses or corrupt specific

[PATCH v3 0/4] x86, boot: KASLR memory randomization

This is PATCH v3 for KASLR memory implementation for x86_64. Recent changes: Add performance information on commit. Add details on PUD alignment. Add information on testing against the KASLR bypass exploit. Rebase on next-20160502. ***Background: The current implementation of

[PATCH v3 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

Minor change that allows early boot physical mapping of PUD level virtual addresses. The current implementation expect the virtual address to be PUD aligned. For KASLR memory randomization, we need to be able to randomize the offset used on the PUD table. It has no impact on current usage.

[PATCH v3 0/4] x86, boot: KASLR memory randomization

This is PATCH v3 for KASLR memory implementation for x86_64. Recent changes: Add performance information on commit. Add details on PUD alignment. Add information on testing against the KASLR bypass exploit. Rebase on next-20160502. ***Background: The current implementation of

[PATCH v3 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

Minor change that allows early boot physical mapping of PUD level virtual addresses. The current implementation expect the virtual address to be PUD aligned. For KASLR memory randomization, we need to be able to randomize the offset used on the PUD table. It has no impact on current usage.

[PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

From: Wang YanQing We can't just break out when meet start is equal to zero, this will cause us to miss valid address ranges in later BARs. On the other hand, it isn't enough to test start only for below situation: 0(start) <= lfb_base < end Due to the BUG this patch

[GIT PULL 0/3] EFI urgent fixes

Folks, here are a few small fixes. One from Josh to stop the ACPI BGRT driver wrecking the splash screen even though the "quiet" kernel parameter is passed, another to fix sysfb_efi on a ThinkPad E550, and one to MAINTAINERS so that get_maintainer.pl finds the EFI entry for all subdirectores of

[PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

From: Wang YanQing We can't just break out when meet start is equal to zero, this will cause us to miss valid address ranges in later BARs. On the other hand, it isn't enough to test start only for below situation: 0(start) <= lfb_base < end Due to the BUG this patch fix, I can't use

[GIT PULL 0/3] EFI urgent fixes

Folks, here are a few small fixes. One from Josh to stop the ACPI BGRT driver wrecking the splash screen even though the "quiet" kernel parameter is passed, another to fix sysfb_efi on a ThinkPad E550, and one to MAINTAINERS so that get_maintainer.pl finds the EFI entry for all subdirectores of

[PATCH 3/3] x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

From: Josh Boyer The promise of pretty boot splashes from firmware via BGRT was at best only that; a promise. The kernel diligently checks to make sure the BGRT data firmware gives it is valid, and dutifully warns the user when it isn't. However, it does so via the

[PATCH 3/3] x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

From: Josh Boyer The promise of pretty boot splashes from firmware via BGRT was at best only that; a promise. The kernel diligently checks to make sure the BGRT data firmware gives it is valid, and dutifully warns the user when it isn't. However, it does so via the pr_err log level which seems

[PATCH 1/3] MAINTAINERS: Remove asterisk from EFI directory names

Mark reported that having asterisks on the end of directory names confuses get_maintainer.pl when it encounters subdirectories, and that my name does not appear when run on drivers/firmware/efi/libstub. Reported-by: Mark Rutland Cc: Ard Biesheuvel

[PATCH 1/3] MAINTAINERS: Remove asterisk from EFI directory names

Mark reported that having asterisks on the end of directory names confuses get_maintainer.pl when it encounters subdirectories, and that my name does not appear when run on drivers/firmware/efi/libstub. Reported-by: Mark Rutland Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Signed-off-by: Matt

Re: [RFC PATCH 1/7] ALSA: ac97: split out the generic ac97 registers

Mark Brown writes: > On Sat, Apr 30, 2016 at 11:15:33PM +0200, Robert Jarzmik wrote: >> Split out from the ac97_codec.h the ac97 generic registers, which can be >> used by a codec, typically a generic ac97 codec, and by the ac97 bus, to >> scan an ac97 AC-Link. > > I don't

Re: [RFC PATCH 1/7] ALSA: ac97: split out the generic ac97 registers

Mark Brown writes: > On Sat, Apr 30, 2016 at 11:15:33PM +0200, Robert Jarzmik wrote: >> Split out from the ac97_codec.h the ac97 generic registers, which can be >> used by a codec, typically a generic ac97 codec, and by the ac97 bus, to >> scan an ac97 AC-Link. > > I don't entirely see the value

Re: [PATCH v2] net: mvneta: Remove superfluous SMP function call

From: Anna-Maria Gleixner Date: Mon, 2 May 2016 11:02:51 +0200 > Since commit 3b9d6da67e11 ("cpu/hotplug: Fix rollback during error-out > in __cpu_disable()") it is ensured that callbacks of CPU_ONLINE and > CPU_DOWN_PREPARE are processed on the hotplugged CPU. Due to

Re: [PATCH v2] net: mvneta: Remove superfluous SMP function call

From: Anna-Maria Gleixner Date: Mon, 2 May 2016 11:02:51 +0200 > Since commit 3b9d6da67e11 ("cpu/hotplug: Fix rollback during error-out > in __cpu_disable()") it is ensured that callbacks of CPU_ONLINE and > CPU_DOWN_PREPARE are processed on the hotplugged CPU. Due to this SMP > function calls

Re: [PATCH V5 2/6] of/slimbus: OF helper for SLIMbus

On Tuesday 03 May 2016 11:11:56 Rob Herring wrote: > > + > > +Child nodes: > > +Every SLIMbus controller node can contain zero or more child nodes > > +representing slave devices on the bus. Every SLIMbus slave device is > > +uniquely determined by the enumeration address containing 4 fields: > >

Re: [PATCH V5 2/6] of/slimbus: OF helper for SLIMbus

On Tuesday 03 May 2016 11:11:56 Rob Herring wrote: > > + > > +Child nodes: > > +Every SLIMbus controller node can contain zero or more child nodes > > +representing slave devices on the bus. Every SLIMbus slave device is > > +uniquely determined by the enumeration address containing 4 fields: > >

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

On Sat, 2016-04-30 at 11:48 +0100, Russell King - ARM Linux wrote: > On Fri, Apr 29, 2016 at 06:42:35PM -0400, Javier Martinez Canillas wrote: > > Maybe a third opinion could make this conversation constructive again. And maybe a forth. > > I think Doug's point is that using a UUID or labels for

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

On Sat, 2016-04-30 at 11:48 +0100, Russell King - ARM Linux wrote: > On Fri, Apr 29, 2016 at 06:42:35PM -0400, Javier Martinez Canillas wrote: > > Maybe a third opinion could make this conversation constructive again. And maybe a forth. > > I think Doug's point is that using a UUID or labels for

Re: [PATCH v2] drm/vc4: Return -EBUSY if there's already a pending flip event.

robert.f...@collabora.com writes: > From: Robert Foss > > As per the documentation in drm_crtc.h, atomic_commit should return > -EBUSY if an asycnhronous update is requested and there is an earlier > update pending. > > Note: docs cited here are drm_crtc.h, and the

Re: [PATCH v2] drm/vc4: Return -EBUSY if there's already a pending flip event.

robert.f...@collabora.com writes: > From: Robert Foss > > As per the documentation in drm_crtc.h, atomic_commit should return > -EBUSY if an asycnhronous update is requested and there is an earlier > update pending. > > Note: docs cited here are drm_crtc.h, and the whole quote is: > > * -

Re: [PATCH v2 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

I don't see much difference. I will update the commits on next iteration with the following: Kernbench shows almost no difference (-+ less than 1%): Before: Average Optimal load -j 12 Run (std deviation): Elapsed Time 102.63 (1.2695) User Time 1034.89 (1.18115) System Time 87.056 (0.456416)

Re: [PATCH] usb: host: ehci-tegra: Avoid getting the same reset twice

On Tue, 3 May 2016, Thierry Reding wrote: > From: Thierry Reding > > Starting with commit 0b52297f2288 ("reset: Add support for shared reset > controls") there is a reference count for reset control assertions. The > goal is to allow resets to be shared by multiple devices

Re: [PATCH v2 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

I don't see much difference. I will update the commits on next iteration with the following: Kernbench shows almost no difference (-+ less than 1%): Before: Average Optimal load -j 12 Run (std deviation): Elapsed Time 102.63 (1.2695) User Time 1034.89 (1.18115) System Time 87.056 (0.456416)

Re: [PATCH] usb: host: ehci-tegra: Avoid getting the same reset twice

On Tue, 3 May 2016, Thierry Reding wrote: > From: Thierry Reding > > Starting with commit 0b52297f2288 ("reset: Add support for shared reset > controls") there is a reference count for reset control assertions. The > goal is to allow resets to be shared by multiple devices and an assert > will

VFIO MSIX Query

Hi, I am a newbie to VFIO framework and trying to use it for MSIX interrupt handling in my userspace application. My userspace application is like intel's dpdk. My query is why vfio kernel code does not support msix masking/ unmasking i.e VFIO_SET_ACTION_TRIGGER is not implemented in kernel

VFIO MSIX Query

Hi, I am a newbie to VFIO framework and trying to use it for MSIX interrupt handling in my userspace application. My userspace application is like intel's dpdk. My query is why vfio kernel code does not support msix masking/ unmasking i.e VFIO_SET_ACTION_TRIGGER is not implemented in kernel

Re: [PATCH v7 2/2] memory: atmel-ebi: add DT bindings documentation

On Tue, May 3, 2016 at 11:51 AM, Boris Brezillon wrote: > Hi Rob, > > On Tue, 3 May 2016 11:40:19 -0500 > Rob Herring wrote: > >> On Thu, Apr 28, 2016 at 02:03:27PM +0200, Boris Brezillon wrote: >> > The EBI (External Bus Interface) is used to

Re: [PATCH v7 2/2] memory: atmel-ebi: add DT bindings documentation

On Tue, May 3, 2016 at 11:51 AM, Boris Brezillon wrote: > Hi Rob, > > On Tue, 3 May 2016 11:40:19 -0500 > Rob Herring wrote: > >> On Thu, Apr 28, 2016 at 02:03:27PM +0200, Boris Brezillon wrote: >> > The EBI (External Bus Interface) is used to access external peripherals >> > (NOR, SRAM, NAND,

Re: [PATCH 7/8] wbt: add general throttling mechanism

On 05/03/2016 12:14 PM, Jens Axboe wrote: On 05/03/2016 10:59 AM, Jens Axboe wrote: On 05/03/2016 09:48 AM, Jan Kara wrote: On Tue 03-05-16 17:40:32, Jan Kara wrote: On Tue 03-05-16 11:34:10, Jan Kara wrote: Yeah, once I'll hunt down that regression with old disk, I can have a look into how

Re: [PATCH 7/8] wbt: add general throttling mechanism

On 05/03/2016 12:14 PM, Jens Axboe wrote: On 05/03/2016 10:59 AM, Jens Axboe wrote: On 05/03/2016 09:48 AM, Jan Kara wrote: On Tue 03-05-16 17:40:32, Jan Kara wrote: On Tue 03-05-16 11:34:10, Jan Kara wrote: Yeah, once I'll hunt down that regression with old disk, I can have a look into how

Re: [PATCH] procfs: fixes pthread cross-thread naming if !PR_DUMPABLE

On Tue, May 3, 2016 at 11:16 AM, Janis Danisevskis wrote: > > > On 03/05/16 18:42, Kees Cook wrote: >> >> On Tue, May 3, 2016 at 10:25 AM, Janis Danisevskis >> wrote: >>> >>> >>> >>> On 26/04/16 21:14, Kees Cook wrote: On Tue, Apr 26, 2016 at

Re: [PATCH] procfs: fixes pthread cross-thread naming if !PR_DUMPABLE

On Tue, May 3, 2016 at 11:16 AM, Janis Danisevskis wrote: > > > On 03/05/16 18:42, Kees Cook wrote: >> >> On Tue, May 3, 2016 at 10:25 AM, Janis Danisevskis >> wrote: >>> >>> >>> >>> On 26/04/16 21:14, Kees Cook wrote: On Tue, Apr 26, 2016 at 10:20 AM, Janis Danisevskis

Re: [PATCH v2] x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

On Tue, 03 May, at 01:47:04PM, Josh Boyer wrote: > The promise of pretty boot splashes from firmware via BGRT was at > best only that; a promise. The kernel diligently checks to make > sure the BGRT data firmware gives it is valid, and dutifully warns > the user when it isn't. However, it does

Re: [PATCH v2] x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

On Tue, 03 May, at 01:47:04PM, Josh Boyer wrote: > The promise of pretty boot splashes from firmware via BGRT was at > best only that; a promise. The kernel diligently checks to make > sure the BGRT data firmware gives it is valid, and dutifully warns > the user when it isn't. However, it does

[PATCH] spi: Fix simple typo s/impelment/implement

This fixes a simple typo in one of the comments. Signed-off-by: Moritz Fischer --- drivers/spi/spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 0239b45..af7c48d 100644 --- a/drivers/spi/spi.c +++

[PATCH] spi: Fix simple typo s/impelment/implement

This fixes a simple typo in one of the comments. Signed-off-by: Moritz Fischer --- drivers/spi/spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 0239b45..af7c48d 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -933,7

[PATCH] crypto: algif_skcipher: replace sg++ with sg_next()

Never use sg++, always use sg = sg_next(sg). Scatterlist entries can be combined if the memory is contiguous but sg++ won't know about that. It sure would run on the slower side. But regardless, sg++ should never be used, only sg_next is safe. Signed-off-by: Muhammad Falak R Wani

[PATCH] crypto: algif_skcipher: replace sg++ with sg_next()

Never use sg++, always use sg = sg_next(sg). Scatterlist entries can be combined if the memory is contiguous but sg++ won't know about that. It sure would run on the slower side. But regardless, sg++ should never be used, only sg_next is safe. Signed-off-by: Muhammad Falak R Wani ---

Re: Regression in inv_mpu6050: 4.6.0-rc5

On 05/01/2016 10:58 PM, Jonathan Cameron wrote: > On 27/04/16 16:56, One Thousand Gnomes wrote: >> On Tue, 26 Apr 2016 18:07:55 -0500 >> Michael Welling wrote: >> >>> On Tue, Apr 26, 2016 at 11:26:51PM +0100, One Thousand Gnomes wrote: This now causes us to crash and

Re: Regression in inv_mpu6050: 4.6.0-rc5

On 05/01/2016 10:58 PM, Jonathan Cameron wrote: > On 27/04/16 16:56, One Thousand Gnomes wrote: >> On Tue, 26 Apr 2016 18:07:55 -0500 >> Michael Welling wrote: >> >>> On Tue, Apr 26, 2016 at 11:26:51PM +0100, One Thousand Gnomes wrote: This now causes us to crash and burn on the ASUS

[PATCH 1/1] i2c-dev: switch from register_chrdev to cdev API

i2c-dev had never moved away from the older register_chrdev interface to implement its char device registration. The register_chrdev API has the limitation of enabling only up to 256 i2c-dev busses to exist. Large platforms with lots of i2c devices (i.e. pluggable transceivers) with dedicated

[PATCH 1/1] i2c-dev: switch from register_chrdev to cdev API

i2c-dev had never moved away from the older register_chrdev interface to implement its char device registration. The register_chrdev API has the limitation of enabling only up to 256 i2c-dev busses to exist. Large platforms with lots of i2c devices (i.e. pluggable transceivers) with dedicated

Re: [PATCH v6 00/21] Add HiSilicon RoCE driver

On Thu, Apr 28, 2016 at 08:09:35PM +0800, Lijun Ou wrote: > The HiSilicon Network Substem is a long term evolution IP which is > supposed to be used in HiSilicon ICT SoCs. HNS (HiSilicon Network > Sybsystem) also has a hardware support of performing RDMA with > RoCEE. > The driver for HiSilicon

Re: [PATCH v6 00/21] Add HiSilicon RoCE driver

On Thu, Apr 28, 2016 at 08:09:35PM +0800, Lijun Ou wrote: > The HiSilicon Network Substem is a long term evolution IP which is > supposed to be used in HiSilicon ICT SoCs. HNS (HiSilicon Network > Sybsystem) also has a hardware support of performing RDMA with > RoCEE. > The driver for HiSilicon

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Tue, May 03, 2016 at 11:48:20AM +0200, Borislav Petkov wrote: > On Mon, May 02, 2016 at 07:10:36PM -0500, Alex Thorlton wrote: > > +#define uv_call_virt(f, args...) \ > > +({ \ > > + efi_status_t __s;

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Tue, May 03, 2016 at 11:48:20AM +0200, Borislav Petkov wrote: > On Mon, May 02, 2016 at 07:10:36PM -0500, Alex Thorlton wrote: > > +#define uv_call_virt(f, args...) \ > > +({ \ > > + efi_status_t __s;

Re: [PATCH v2] x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

On Tue, May 03, 2016 at 01:47:04PM -0400, Josh Boyer wrote: > The promise of pretty boot splashes from firmware via BGRT was at > best only that; a promise. The kernel diligently checks to make > sure the BGRT data firmware gives it is valid, and dutifully warns > the user when it isn't.

Re: [PATCH v2] x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

On Tue, May 03, 2016 at 01:47:04PM -0400, Josh Boyer wrote: > The promise of pretty boot splashes from firmware via BGRT was at > best only that; a promise. The kernel diligently checks to make > sure the BGRT data firmware gives it is valid, and dutifully warns > the user when it isn't.

[PATCH] Staging: dgnc: fix coding style in dgnc_tty.c

Fix checkpatch.pl warning about 'line over 80 characters'. I just split line with function. Signed-off-by: Patryk Mezydlo --- drivers/staging/dgnc/dgnc_tty.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/dgnc/dgnc_tty.c

[PATCH] Staging: dgnc: fix coding style in dgnc_tty.c

Fix checkpatch.pl warning about 'line over 80 characters'. I just split line with function. Signed-off-by: Patryk Mezydlo --- drivers/staging/dgnc/dgnc_tty.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c

[RFC PATCH] firmware: qemu_fw_cfg.c: default to listing user-facing items only

Per the QEMU fw_cfg documentation, items targeted at guest-side userspace should have names beginning with the string "opt/". This patch limits the default sysfs fw_cfg listing to items named "opt/*". The "opt/" prefix on a fw_cfg item name may be interpreted as being analogous to bit 2 in ACPI's

Re: [PATCH] keyrings: Allow searching the user session keyring

Any feedback on this? It is mandatory if we want to mount a ecryptfs directory while the session keyring is used. Thanks, Gwendal. On Thu, Mar 17, 2016 at 10:04 AM, Gwendal Grignou wrote: > Resent to a larger audience. > > On Thu, Mar 10, 2016 at 2:20 PM, Gwendal Grignou

[RFC PATCH] firmware: qemu_fw_cfg.c: default to listing user-facing items only

Per the QEMU fw_cfg documentation, items targeted at guest-side userspace should have names beginning with the string "opt/". This patch limits the default sysfs fw_cfg listing to items named "opt/*". The "opt/" prefix on a fw_cfg item name may be interpreted as being analogous to bit 2 in ACPI's

Re: [PATCH] keyrings: Allow searching the user session keyring

Any feedback on this? It is mandatory if we want to mount a ecryptfs directory while the session keyring is used. Thanks, Gwendal. On Thu, Mar 17, 2016 at 10:04 AM, Gwendal Grignou wrote: > Resent to a larger audience. > > On Thu, Mar 10, 2016 at 2:20 PM, Gwendal Grignou wrote: >> Currently,

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