Re: [PATCH 0/8] device-dax: sub-division support

On Mon, Dec 12, 2016 at 9:15 AM, Jeff Moyer wrote: > Hi, Dan, > > Dan Williams writes: > >>>From [PATCH 6/8] dax: sub-division support: >> >> Device-DAX is a mechanism to establish mappings of performance / feature >> differentiated memory with strict

Re: [PATCH 0/8] device-dax: sub-division support

On Mon, Dec 12, 2016 at 9:15 AM, Jeff Moyer wrote: > Hi, Dan, > > Dan Williams writes: > >>>From [PATCH 6/8] dax: sub-division support: >> >> Device-DAX is a mechanism to establish mappings of performance / feature >> differentiated memory with strict fault behavior guarantees. With >>

Re: [PATCH] driver core: flush async calls before testing driver removal

Hello, On Mon, Dec 12, 2016 at 12:33:36PM -0600, Rob Herring wrote: > Maybe I'm confused, but don't you need this for all drivers? You need > sync the async SCSI scanning to the driver remove regardless of async > probe. The driver core synchronization is only for synchronizing the > remove with

Re: [PATCH] driver core: flush async calls before testing driver removal

Hello, On Mon, Dec 12, 2016 at 12:33:36PM -0600, Rob Herring wrote: > Maybe I'm confused, but don't you need this for all drivers? You need > sync the async SCSI scanning to the driver remove regardless of async > probe. The driver core synchronization is only for synchronizing the > remove with

Re: [PATCH 0/2] ARM: v7-A !MMU fixes for fun ()

Hi, On Sun, Dec 11, 2016 at 06:40:28PM +0530, Afzal Mohammed wrote: > Kernel reached the stage of invoking user space init & panicked, though > it could not reach till prompt for want of user space executables > > So far i have not come across a toolchain (or a way to create toolchain) > to

Re: [PATCH 0/2] ARM: v7-A !MMU fixes for fun ()

Hi, On Sun, Dec 11, 2016 at 06:40:28PM +0530, Afzal Mohammed wrote: > Kernel reached the stage of invoking user space init & panicked, though > it could not reach till prompt for want of user space executables > > So far i have not come across a toolchain (or a way to create toolchain) > to

Re: [PATCH v2 04/11] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible

On Fri, Dec 09, 2016 at 12:04:12PM +0100, Quentin Schulz wrote: > This adds the "x-powers,axp223-usb-power-supply" to the list of > compatibles for AXP20X VBUS power supply driver. > > Signed-off-by: Quentin Schulz > --- > > v2: > - adding small explanation

Re: [PATCH v2 04/11] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible

On Fri, Dec 09, 2016 at 12:04:12PM +0100, Quentin Schulz wrote: > This adds the "x-powers,axp223-usb-power-supply" to the list of > compatibles for AXP20X VBUS power supply driver. > > Signed-off-by: Quentin Schulz > --- > > v2: > - adding small explanation on AXP223 variation compared to the

Re: [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding

On Fri, Dec 09, 2016 at 01:52:20PM +0100, Geert Uytterhoeven wrote: > Hi Simon, > > On Fri, Dec 9, 2016 at 11:50 AM, Simon Horman > wrote: > > In the case of Renesas R-Car hardware we know that there are generations of > > SoCs, e.g. Gen 1, Gen 2 and Gen 3. But beyond

Re: [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding

On Fri, Dec 09, 2016 at 01:52:20PM +0100, Geert Uytterhoeven wrote: > Hi Simon, > > On Fri, Dec 9, 2016 at 11:50 AM, Simon Horman > wrote: > > In the case of Renesas R-Car hardware we know that there are generations of > > SoCs, e.g. Gen 1, Gen 2 and Gen 3. But beyond that its not clear what the

[GIT PULL] workqueue changes for v4.10-rc1

Hello, Mostly patches to initialize workqueue subsystem earlier and get rid of keventd_up(). The patches were headed for the last merge cycle but got delayed due to a bug found late minute, which is fixed now. Also, to help debugging, destroy_workqueue() is more chatty now on a sanity check

[GIT PULL] workqueue changes for v4.10-rc1

Hello, Mostly patches to initialize workqueue subsystem earlier and get rid of keventd_up(). The patches were headed for the last merge cycle but got delayed due to a bug found late minute, which is fixed now. Also, to help debugging, destroy_workqueue() is more chatty now on a sanity check

[PATCH V7 3/8] iommu/io-pgtable-arm-v7s: Add support for the IOMMU_PRIV flag

From: Robin Murphy The short-descriptor format also allows privileged-only mappings, so let's wire it up. Signed-off-by: Robin Murphy Tested-by: Sricharan R --- drivers/iommu/io-pgtable-arm-v7s.c | 6 +- 1 file

[PATCH V7 3/8] iommu/io-pgtable-arm-v7s: Add support for the IOMMU_PRIV flag

From: Robin Murphy The short-descriptor format also allows privileged-only mappings, so let's wire it up. Signed-off-by: Robin Murphy Tested-by: Sricharan R --- drivers/iommu/io-pgtable-arm-v7s.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[PATCH V7 8/8] iommu/arm-smmu: Revert "iommu/arm-smmu: Set PRIVCFG in stage 1 STEs"

From: Robin Murphy Now that proper privileged mappings can be requested via IOMMU_PRIV, unconditionally overriding the incoming PRIVCFG becomes the wrong thing to do, so stop it. This reverts commit df5e1a0f2a2d779ad467a691203bcbc74d75690e. Signed-off-by: Robin Murphy

Re: [PATCH] Documentation: ti-syscon-reset: fix header path

On Fri, Dec 09, 2016 at 11:11:27AM +0100, yegorsli...@googlemail.com wrote: > From: Yegor Yefremov > > 'include' was missing from path. > > Signed-off-by: Yegor Yefremov > --- > Documentation/devicetree/bindings/reset/ti-syscon-reset.txt

[PATCH V7 7/8] iommu/arm-smmu: Set privileged attribute to 'default' instead of 'unprivileged'

Currently the driver sets all the device transactions privileges to UNPRIVILEGED, but there are cases where the iommu masters wants to isolate privileged supervisor and unprivileged user. So don't override the privileged setting to unprivileged, instead set it to default as incoming and let it be

[PATCH V7 8/8] iommu/arm-smmu: Revert "iommu/arm-smmu: Set PRIVCFG in stage 1 STEs"

From: Robin Murphy Now that proper privileged mappings can be requested via IOMMU_PRIV, unconditionally overriding the incoming PRIVCFG becomes the wrong thing to do, so stop it. This reverts commit df5e1a0f2a2d779ad467a691203bcbc74d75690e. Signed-off-by: Robin Murphy ---

Re: [PATCH] Documentation: ti-syscon-reset: fix header path

On Fri, Dec 09, 2016 at 11:11:27AM +0100, yegorsli...@googlemail.com wrote: > From: Yegor Yefremov > > 'include' was missing from path. > > Signed-off-by: Yegor Yefremov > --- > Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH V7 7/8] iommu/arm-smmu: Set privileged attribute to 'default' instead of 'unprivileged'

Currently the driver sets all the device transactions privileges to UNPRIVILEGED, but there are cases where the iommu masters wants to isolate privileged supervisor and unprivileged user. So don't override the privileged setting to unprivileged, instead set it to default as incoming and let it be

[PATCH V7 6/8] dmaengine: pl330: Make sure microcode is privileged

From: Mitchel Humpherys The PL330 is hard-wired such that instruction fetches on both the manager and channel threads go out onto the bus with the "privileged" bit set. This can become troublesome once there is an IOMMU or other form of memory protection downstream,

[PATCH V7 6/8] dmaengine: pl330: Make sure microcode is privileged

From: Mitchel Humpherys The PL330 is hard-wired such that instruction fetches on both the manager and channel threads go out onto the bus with the "privileged" bit set. This can become troublesome once there is an IOMMU or other form of memory protection downstream, since those will typically be

[PATCH V7 5/8] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED

From: Mitchel Humpherys The newly added DMA_ATTR_PRIVILEGED is useful for creating mappings that are only accessible to privileged DMA engines. Implement it in dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it. Reviewed-by: Robin Murphy

[PATCH V7 4/8] common: DMA-mapping: add DMA_ATTR_PRIVILEGED attribute

From: Mitchel Humpherys This patch adds the DMA_ATTR_PRIVILEGED attribute to the DMA-mapping subsystem. Some advanced peripherals such as remote processors and GPUs perform accesses to DMA buffers in both privileged "supervisor" and unprivileged "user" modes. This

Re: [PATCH] ACPI: small formatting fixes

On Mon, 2016-12-12 at 09:56 -0800, Nick Desaulniers wrote: > A quick cleanup that passes scripts/checkpatch.pl -f . You might use the --strict option for acpi files. > diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c [] > @@ -103,9 +103,8 @@ static long

[PATCH V7 2/8] iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag

From: Jeremy Gebben Allow the creation of privileged mode mappings, for stage 1 only. Reviewed-by: Robin Murphy Tested-by: Robin Murphy Acked-by: Will Deacon Signed-off-by: Jeremy Gebben

[PATCH V7 5/8] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED

From: Mitchel Humpherys The newly added DMA_ATTR_PRIVILEGED is useful for creating mappings that are only accessible to privileged DMA engines. Implement it in dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it. Reviewed-by: Robin Murphy Tested-by: Robin Murphy Acked-by: Will

[PATCH V7 4/8] common: DMA-mapping: add DMA_ATTR_PRIVILEGED attribute

From: Mitchel Humpherys This patch adds the DMA_ATTR_PRIVILEGED attribute to the DMA-mapping subsystem. Some advanced peripherals such as remote processors and GPUs perform accesses to DMA buffers in both privileged "supervisor" and unprivileged "user" modes. This attribute is used to indicate

Re: [PATCH] ACPI: small formatting fixes

On Mon, 2016-12-12 at 09:56 -0800, Nick Desaulniers wrote: > A quick cleanup that passes scripts/checkpatch.pl -f . You might use the --strict option for acpi files. > diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c [] > @@ -103,9 +103,8 @@ static long

[PATCH V7 2/8] iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag

From: Jeremy Gebben Allow the creation of privileged mode mappings, for stage 1 only. Reviewed-by: Robin Murphy Tested-by: Robin Murphy Acked-by: Will Deacon Signed-off-by: Jeremy Gebben --- drivers/iommu/io-pgtable-arm.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff

[PATCH] of/platform: depopulate devices in the reverse order of creation

If the DT has inter-dependencies, then the devices need to be removed in the right order to avoid removal problems. Assuming the DT is constructed so that EPROBE_DEFER doesn't happen during creating then a good way to avoid removal problems is reversing the order during depopulation.

[PATCH] of/platform: depopulate devices in the reverse order of creation

If the DT has inter-dependencies, then the devices need to be removed in the right order to avoid removal problems. Assuming the DT is constructed so that EPROBE_DEFER doesn't happen during creating then a good way to avoid removal problems is reversing the order during depopulation.

[PATCH V7 0/8] Add support for privileged mappings

This series is a resend of the V5 that Mitch sent sometime back [2] All the patches are the same and i have just rebased. Redid patch [3], as it does not apply in this code base. Added a couple of more patches [4], [5] from Robin for adding the privileged attributes to armv7s format and arm-smmuv3

[PATCH V7 1/8] iommu: add IOMMU_PRIV attribute

From: Mitchel Humpherys Add the IOMMU_PRIV attribute, which is used to indicate privileged mappings. Reviewed-by: Robin Murphy Tested-by: Robin Murphy Signed-off-by: Mitchel Humpherys Acked-by: Will

[PATCH V7 0/8] Add support for privileged mappings

This series is a resend of the V5 that Mitch sent sometime back [2] All the patches are the same and i have just rebased. Redid patch [3], as it does not apply in this code base. Added a couple of more patches [4], [5] from Robin for adding the privileged attributes to armv7s format and arm-smmuv3

[PATCH V7 1/8] iommu: add IOMMU_PRIV attribute

From: Mitchel Humpherys Add the IOMMU_PRIV attribute, which is used to indicate privileged mappings. Reviewed-by: Robin Murphy Tested-by: Robin Murphy Signed-off-by: Mitchel Humpherys Acked-by: Will Deacon --- include/linux/iommu.h | 1 + 1 file changed, 1 insertion(+) diff --git

[GIT PULL] percpu changes for v4.10-rc1

Hello, This includes one patch to reject non-power-of-2 alignments and trigger warning. Interestingly, this actually caught a bug in XEN ARM64. Thanks. The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux 4.9-rc1 (2016-10-15 12:17:50 -0700) are available in

[GIT PULL] percpu changes for v4.10-rc1

Hello, This includes one patch to reject non-power-of-2 alignments and trigger warning. Interestingly, this actually caught a bug in XEN ARM64. Thanks. The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux 4.9-rc1 (2016-10-15 12:17:50 -0700) are available in

RE: [PATCH v4 3/5] i2c: designware: Add slave definitions

Hi all, The slave address could be set by the I2C slave backend so I can't use it to setup the controller. A boolean property was my initial approach then Andy and Wolfram Sang suggested the use of compatible strings and later It was suggested to use a property to select mode but I can do it

RE: [PATCH v4 3/5] i2c: designware: Add slave definitions

Hi all, The slave address could be set by the I2C slave backend so I can't use it to setup the controller. A boolean property was my initial approach then Andy and Wolfram Sang suggested the use of compatible strings and later It was suggested to use a property to select mode but I can do it

Re: [PATCH 1/1] Fixed to codestyle

On 12/12/16 12:14 PM, Joe Perches wrote: > On Mon, 2016-12-12 at 07:49 -0600, Eric Sandeen wrote: >> On 12/12/16 4:53 AM, Ozgur Karatas wrote: >>> >>> Hello, >>> >>> I have error to use uuid and I think the functions should be used when -i'm >>> eye-catching- "(* uuid)". >>> I tested it. >>>

Re: [PATCH 1/1] Fixed to codestyle

On 12/12/16 12:14 PM, Joe Perches wrote: > On Mon, 2016-12-12 at 07:49 -0600, Eric Sandeen wrote: >> On 12/12/16 4:53 AM, Ozgur Karatas wrote: >>> >>> Hello, >>> >>> I have error to use uuid and I think the functions should be used when -i'm >>> eye-catching- "(* uuid)". >>> I tested it. >>>

Re: [PATCH v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support

Hi all, On Mon, Dec 12, 2016 at 08:47:06AM -0600, Rob Herring wrote: [Snip Benjamin's proposal; I agree we don't really want a multi-level DT layout purely for making the driver look a little nicer (I'm not sure this would really be nicer anyway). And I think, as Rob notes here, our disagreement

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers wrote: > In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by > default on x86_64. This has been exposing a number of problems in which > on-stack buffers are being passed into the crypto API, which to

Re: [PATCH v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support

Hi all, On Mon, Dec 12, 2016 at 08:47:06AM -0600, Rob Herring wrote: [Snip Benjamin's proposal; I agree we don't really want a multi-level DT layout purely for making the driver look a little nicer (I'm not sure this would really be nicer anyway). And I think, as Rob notes here, our disagreement

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers wrote: > In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by > default on x86_64. This has been exposing a number of problems in which > on-stack buffers are being passed into the crypto API, which to support crypto >

Re: [PATCH] driver core: flush async calls before testing driver removal

On Mon, Dec 12, 2016 at 11:50 AM, Tejun Heo wrote: > Hello, > > On Sun, Dec 11, 2016 at 03:44:36AM +0200, Vladimir Zapolskiy wrote: >> On 12/10/2016 03:04 PM, Greg Kroah-Hartman wrote: >> > Hm, how does this not also get hit if you unbind/bind/unbind/bind/etc. >> > from userspace

Re: [PATCH] driver core: flush async calls before testing driver removal

On Mon, Dec 12, 2016 at 11:50 AM, Tejun Heo wrote: > Hello, > > On Sun, Dec 11, 2016 at 03:44:36AM +0200, Vladimir Zapolskiy wrote: >> On 12/10/2016 03:04 PM, Greg Kroah-Hartman wrote: >> > Hm, how does this not also get hit if you unbind/bind/unbind/bind/etc. >> > from userspace as well? I

[GIT PULL] libata changes for v4.10-rc1

Hello, Linus. * Adam added opt-in ATA command priority support. * There are machines which hide multiple nvme devices behind an ahci BAR. Dan Williams proposed a solution to force-switch the mode but deemed too hackishd. People are gonna discuss the proper way to handle the situation in

[GIT PULL] libata changes for v4.10-rc1

Hello, Linus. * Adam added opt-in ATA command priority support. * There are machines which hide multiple nvme devices behind an ahci BAR. Dan Williams proposed a solution to force-switch the mode but deemed too hackishd. People are gonna discuss the proper way to handle the situation in

[PATCH] PCI: mvebu: Handle changes to the bridge windows while enabled

The PCI core will write to the bridge window config multiple times while they are enabled. This can lead to mbus failures like: mvebu_mbus: cannot add window '4:e8', conflicts with another window mvebu-pcie mbus:pex@e000: Could not create MBus window at [mem 0xe000-0xe00f]: -22

Re: [PATCH v3 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

Hari Bathini writes: > With the advert of container technologies like docker, that depend > on namespaces for isolation, there is a need for tracing support for > namespaces. This patch introduces new PERF_RECORD_NAMESPACES event > for tracing based on namespaces

[PATCH] PCI: mvebu: Handle changes to the bridge windows while enabled

The PCI core will write to the bridge window config multiple times while they are enabled. This can lead to mbus failures like: mvebu_mbus: cannot add window '4:e8', conflicts with another window mvebu-pcie mbus:pex@e000: Could not create MBus window at [mem 0xe000-0xe00f]: -22

Re: [PATCH v3 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

Hari Bathini writes: > With the advert of container technologies like docker, that depend > on namespaces for isolation, there is a need for tracing support for > namespaces. This patch introduces new PERF_RECORD_NAMESPACES event > for tracing based on namespaces related info. > diff --git

Re: [PATCH v2 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

Hi Peter, On Friday 09 December 2016 07:39 PM, Peter Zijlstra wrote: On Fri, Dec 09, 2016 at 12:10:20AM +0530, Hari Bathini wrote: Hi Peter, Sorry for taking so long to respond... On Thursday 24 November 2016 08:40 PM, Peter Zijlstra wrote: On Thu, Nov 24, 2016 at 08:14:29PM +0530, Hari

[LSF/MM TOPIC][LSF/MM ATTEND] Enabling Peer-to-Peer DMAs between PCIe devices

Hi I'd like to discuss the topic of how best to enable DMAs between PCIe devices in the Linux kernel. There have been many attempts to add to the kernel the ability to DMA between two PCIe devices. However, to date, none of these have been accepted. However as PCIe devices like NICs, NVMe SSDs

Re: [PATCH v2 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

Hi Peter, On Friday 09 December 2016 07:39 PM, Peter Zijlstra wrote: On Fri, Dec 09, 2016 at 12:10:20AM +0530, Hari Bathini wrote: Hi Peter, Sorry for taking so long to respond... On Thursday 24 November 2016 08:40 PM, Peter Zijlstra wrote: On Thu, Nov 24, 2016 at 08:14:29PM +0530, Hari

[LSF/MM TOPIC][LSF/MM ATTEND] Enabling Peer-to-Peer DMAs between PCIe devices

Hi I'd like to discuss the topic of how best to enable DMAs between PCIe devices in the Linux kernel. There have been many attempts to add to the kernel the ability to DMA between two PCIe devices. However, to date, none of these have been accepted. However as PCIe devices like NICs, NVMe SSDs

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

ox-a95x.dts | 2 +- > .../arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +- > arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +- > 11 files changed, 31 insertions(+), 10 deletions(-) > I added your patch to next-20161212. My kernel conf

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

.../arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +- > arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +- > 11 files changed, 31 insertions(+), 10 deletions(-) > I added your patch to next-20161212. My kernel config is available as https://github.com/xypron/kernel-od

Re: Documenting the ioctl interfaces to discover relationships between namespaces

"Michael Kerrisk (man-pages)" writes: > On 12/11/2016 11:30 PM, Eric W. Biederman wrote: >> "Michael Kerrisk (man-pages)" writes: >> >>> [was: [PATCH 0/4 v3] Add an interface to discover relationships >>> between namespaces] >> >> One small

Re: [PATCH v2 3/5] staging: lustre: headers: sort headers affected by obdo move

On 12/12/16, 11:34 AM, "Greg Kroah-Hartman" wrote: >What is this mythical guidelines, and why does it differ from the kernel >source ones? > >And again, why is this patch required? > >thanks, > >greg k-h > Here are the general guidelines for your reading pleasure:

Re: Documenting the ioctl interfaces to discover relationships between namespaces

"Michael Kerrisk (man-pages)" writes: > On 12/11/2016 11:30 PM, Eric W. Biederman wrote: >> "Michael Kerrisk (man-pages)" writes: >> >>> [was: [PATCH 0/4 v3] Add an interface to discover relationships >>> between namespaces] >> >> One small comment below. >> >>> >>>Introspecting

Re: [PATCH v2 3/5] staging: lustre: headers: sort headers affected by obdo move

On 12/12/16, 11:34 AM, "Greg Kroah-Hartman" wrote: >What is this mythical guidelines, and why does it differ from the kernel >source ones? > >And again, why is this patch required? > >thanks, > >greg k-h > Here are the general guidelines for your reading pleasure:

[PATCH v3 3/3] perf tool: add cgroup identifier entry in perf report

This patch introduces a cgroup identifier entry field in perf report to identify or distinguish data of different cgroups. It uses the unique inode number of cgroup namespace, included in perf data with the new PERF_RECORD_NAMESPACES event, as cgroup identifier. With the assumption that each

[PATCH v3 2/3] perf tool: add PERF_RECORD_NAMESPACES to include namespaces related info

This patch updates perf tool to examine PERF_RECORD_NAMESPACES events emitted by the kernel when fork, clone, setns or unshare are invoked. Also, it synthesizes PERF_RECORD_NAMESPACES events for processes that were running prior to invocation of perf record, the data for which is taken from

[PATCH v3 3/3] perf tool: add cgroup identifier entry in perf report

This patch introduces a cgroup identifier entry field in perf report to identify or distinguish data of different cgroups. It uses the unique inode number of cgroup namespace, included in perf data with the new PERF_RECORD_NAMESPACES event, as cgroup identifier. With the assumption that each

[PATCH v3 2/3] perf tool: add PERF_RECORD_NAMESPACES to include namespaces related info

This patch updates perf tool to examine PERF_RECORD_NAMESPACES events emitted by the kernel when fork, clone, setns or unshare are invoked. Also, it synthesizes PERF_RECORD_NAMESPACES events for processes that were running prior to invocation of perf record, the data for which is taken from

[PATCH v3 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

With the advert of container technologies like docker, that depend on namespaces for isolation, there is a need for tracing support for namespaces. This patch introduces new PERF_RECORD_NAMESPACES event for tracing based on namespaces related info. Signed-off-by: Hari Bathini

[PATCH v3 0/3] perf: add support for analyzing events for containers

Currently, there is no trivial mechanism to analyze events based on containers. perf -G can be used, but it will not filter events for the containers created after perf is invoked, making it difficult to assess/ analyze performance issues of multiple containers at once. This patch-set overcomes

Re: [V1] mtd: devices: docg3:- Handle return value of devm_ioremap.

On Sun, Dec 11, 2016 at 5:15 PM, Marek Vasut wrote: >> ret = -ENOMEM; >> + base = devm_ioremap(dev, ress->start, DOC_IOSPACE_SIZE); >> + if (!base) >> + return ret; > > I think return -ENOMEM right away won't hurt here. Also, dev_err() >

Re: [V1] mtd: devices: docg3:- Handle return value of devm_ioremap.

On Sun, Dec 11, 2016 at 5:15 PM, Marek Vasut wrote: >> ret = -ENOMEM; >> + base = devm_ioremap(dev, ress->start, DOC_IOSPACE_SIZE); >> + if (!base) >> + return ret; > > I think return -ENOMEM right away won't hurt here. Also, dev_err() > explaining the failure would be

[PATCH v3 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

With the advert of container technologies like docker, that depend on namespaces for isolation, there is a need for tracing support for namespaces. This patch introduces new PERF_RECORD_NAMESPACES event for tracing based on namespaces related info. Signed-off-by: Hari Bathini --- Changes from

[PATCH v3 0/3] perf: add support for analyzing events for containers

Currently, there is no trivial mechanism to analyze events based on containers. perf -G can be used, but it will not filter events for the containers created after perf is invoked, making it difficult to assess/ analyze performance issues of multiple containers at once. This patch-set overcomes

Re: [PATCH v2 3/5] staging: lustre: headers: sort headers affected by obdo move

On Mon, 2016-12-12 at 17:34 +0100, Greg Kroah-Hartman wrote: > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > A: No. > Q: Should I include quotations after my reply? > > http://daringfireball.net/2007/07/on_top > > On Mon, Dec 12, 2016 at 02:42:29PM +, Ben Evans wrote:

Re: [PATCH v2 3/5] staging: lustre: headers: sort headers affected by obdo move

On Mon, 2016-12-12 at 17:34 +0100, Greg Kroah-Hartman wrote: > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > A: No. > Q: Should I include quotations after my reply? > > http://daringfireball.net/2007/07/on_top > > On Mon, Dec 12, 2016 at 02:42:29PM +, Ben Evans wrote:

Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def

On Mon, Dec 12, 2016 at 03:04:28PM +0200, Ozgur Karatas wrote: > Dear Romanovsky; Please avoid top-posting in your replies. Thanks > > I'm trying to learn english and I apologize for my mistake words and phrases. > So, I think the code when call to "sg_set_buf" and next time set memory and >

Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def

On Mon, Dec 12, 2016 at 03:04:28PM +0200, Ozgur Karatas wrote: > Dear Romanovsky; Please avoid top-posting in your replies. Thanks > > I'm trying to learn english and I apologize for my mistake words and phrases. > So, I think the code when call to "sg_set_buf" and next time set memory and >

Re: [PATCH v5 2/2] thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode

On Fri, Nov 11, 2016 at 03:15:03PM -0500, Lyude wrote: > For whatever reason, the X1 Yoga doesn't support the normal method of > querying for tablet mode. Instead of providing the MHKG method under the > hotkey handle, we're instead given the CMMD method under the EC handle. > Values on this

Re: [PATCH v5 2/2] thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode

On Fri, Nov 11, 2016 at 03:15:03PM -0500, Lyude wrote: > For whatever reason, the X1 Yoga doesn't support the normal method of > querying for tablet mode. Instead of providing the MHKG method under the > hotkey handle, we're instead given the CMMD method under the EC handle. > Values on this

Re: [V2] mtd: devices: docg3:- Handle return value of devm_ioremap.

Hi Boris, Yes, It's possible that two driver can use same iomem region. For example you can check commit id - : 33cf75656923ff11d67a937a4f8e9344f58cea77 Here, It's not required. Thanks -Arvind On Monday 12 December 2016 10:34 PM, Boris Brezillon wrote: Hi Arvind, On Mon, 12 Dec 2016

Re: [V2] mtd: devices: docg3:- Handle return value of devm_ioremap.

Hi Boris, Yes, It's possible that two driver can use same iomem region. For example you can check commit id - : 33cf75656923ff11d67a937a4f8e9344f58cea77 Here, It's not required. Thanks -Arvind On Monday 12 December 2016 10:34 PM, Boris Brezillon wrote: Hi Arvind, On Mon, 12 Dec 2016

Re: [PATCH 1/1] Fixed to codestyle

On Mon, 2016-12-12 at 07:49 -0600, Eric Sandeen wrote: > On 12/12/16 4:53 AM, Ozgur Karatas wrote: > > > > Hello, > > > > I have error to use uuid and I think the functions should be used when -i'm > > eye-catching- "(* uuid)". > > I tested it. > > > > Regards, > > > > Signed-off-by: Ozgur

Re: [PATCH 1/1] Fixed to codestyle

On Mon, 2016-12-12 at 07:49 -0600, Eric Sandeen wrote: > On 12/12/16 4:53 AM, Ozgur Karatas wrote: > > > > Hello, > > > > I have error to use uuid and I think the functions should be used when -i'm > > eye-catching- "(* uuid)". > > I tested it. > > > > Regards, > > > > Signed-off-by: Ozgur

[GIT PULL] regulator updates for v4.10

The following changes since commit 69973b830859bc6529a7a0468ba0d80ee5117826: Linux 4.9 (2016-12-11 11:17:54 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/regulator-v4.10 for you to fetch changes up to

Re: [for-next][PATCH 7/8] fgraph: Handle a case where a tracer ignores set_graph_notrace

On Tue, 13 Dec 2016 02:09:04 +0900 Namhyung Kim wrote: > > I wanted the simplest fix for stable. > > I think a simpler fix is just to return when it sees a negative record.. You're right, but I guess I was trying to get it someone closer to the final change too. --

[GIT PULL] regulator updates for v4.10

The following changes since commit 69973b830859bc6529a7a0468ba0d80ee5117826: Linux 4.9 (2016-12-11 11:17:54 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/regulator-v4.10 for you to fetch changes up to

Re: [for-next][PATCH 7/8] fgraph: Handle a case where a tracer ignores set_graph_notrace

On Tue, 13 Dec 2016 02:09:04 +0900 Namhyung Kim wrote: > > I wanted the simplest fix for stable. > > I think a simpler fix is just to return when it sees a negative record.. You're right, but I guess I was trying to get it someone closer to the final change too. -- Steve > > > diff

Re: WARNING: kernel stack frame pointer at ffffffff82e03f40 in swapper:0 has bad value (null)

On Mon, Dec 12, 2016 at 06:50:23PM +0100, Borislav Petkov wrote: > [0.00] bce03f40: ... > [0.00] bce03f48: bc0001b5 (start_cpu+0x5/0x14) > [0.00] bce03f50: bc0001b5 (start_cpu+0x5/0x14) > [0.00]

Re: WARNING: kernel stack frame pointer at ffffffff82e03f40 in swapper:0 has bad value (null)

On Mon, Dec 12, 2016 at 06:50:23PM +0100, Borislav Petkov wrote: > [0.00] bce03f40: ... > [0.00] bce03f48: bc0001b5 (start_cpu+0x5/0x14) > [0.00] bce03f50: bc0001b5 (start_cpu+0x5/0x14) > [0.00]

Re: [RFC 00/10] implement alternative and much simpler id allocator

Hello, Matthew. On Mon, Dec 12, 2016 at 05:35:17PM +, Matthew Wilcox wrote: > I know the preload followed by preload_end looks wrong. I don't > think it's broken though. If we get preempted, then the worst > situation is that we'll end up with the memory we preallocated being > allocated to

Re: [RFC 00/10] implement alternative and much simpler id allocator

Hello, Matthew. On Mon, Dec 12, 2016 at 05:35:17PM +, Matthew Wilcox wrote: > I know the preload followed by preload_end looks wrong. I don't > think it's broken though. If we get preempted, then the worst > situation is that we'll end up with the memory we preallocated being > allocated to

[PATCH] media: platform: exynos4-is: constify v4l2_subdev_* structures

v4l2_subdev_{core/pad/video}_ops structures are stored in the fields of the v4l2_subdev_ops structure which are of type const. Also, v4l2_subdev_ops structure is passed to a function having its argument of type const. As these structures are never modified, so declare them as const. Done using

[PATCH] media: platform: exynos4-is: constify v4l2_subdev_* structures

v4l2_subdev_{core/pad/video}_ops structures are stored in the fields of the v4l2_subdev_ops structure which are of type const. Also, v4l2_subdev_ops structure is passed to a function having its argument of type const. As these structures are never modified, so declare them as const. Done using

Re: Clarification for acceptance statistics?

> Have you proposed a similar patch that was accepted? Yes. - It happened a few times. > I don't find record of it, but I may be wrong. It is really needed to clarify the corresponding software development history any further? Regards, Markus

Re: Clarification for acceptance statistics?

> Have you proposed a similar patch that was accepted? Yes. - It happened a few times. > I don't find record of it, but I may be wrong. It is really needed to clarify the corresponding software development history any further? Regards, Markus

Re: [PATCH 0/2] Add maintainers to the admin guide

On Fri, 2 Dec 2016 10:15:13 -0200 Mauro Carvalho Chehab wrote: > On the past approaches, was planning to keep the documentation > about what's at the MAINTAINERS file inside it, but that would > require running an external script or use some Sphinx extension. > > This

Re: [PATCH 0/2] Add maintainers to the admin guide

On Fri, 2 Dec 2016 10:15:13 -0200 Mauro Carvalho Chehab wrote: > On the past approaches, was planning to keep the documentation > about what's at the MAINTAINERS file inside it, but that would > require running an external script or use some Sphinx extension. > > This time, I took a much

Re: [rtc-linux] Re: [PATCH] rtc: max77683: avoid regmap bulk write for max77620

On Mon, Dec 12, 2016 at 02:28:11PM +0100, Bartlomiej Zolnierkiewicz wrote: > > @@ -259,6 +262,32 @@ static const struct max77686_rtc_driver_data > > max77802_drv_data = { > > .rtc_irq_chip = _rtc_irq_chip, > > }; > > > > +static inline int _regmap_bulk_write(struct max77686_rtc_info *info,

Re: [tpmdd-devel] [PATCH v3 1/3] tpm_crb: map locality registers

On Mon, Dec 12, 2016 at 07:53:06PM +0200, Jarkko Sakkinen wrote: > On Mon, Dec 12, 2016 at 03:57:54PM +, Winkler, Tomas wrote: > > > > On Mon, Dec 12, 2016 at 02:25:32PM +, Winkler, Tomas wrote: > > > > > > > > > > > > In order to provide access to locality registers, this commits > > > >

<    3   4   5   6   7   8   9   10   11   12   >