[PATCH v2 0/8] firmware: add new sysdata API

my linux-next tree as well [4]. Please do note that all these series are based on linux-next tag next-20160616, and I noticed that Andrew Morton had picked up a patch by Stephen Boyd and Vikram Mulukutla to add yet-another new old firmware API. This then applies on top of that as its merged on linux

[PATCH v2 1/8] firmware: add new extensible firmware API - sysdata_file_request*()

The firmware API has evolved over the years slowly, as it grows we extend it by adding new routines or at times we extend existing routines with more or less arguments. This doesn't scale well, when new arguments are added to existing routines it means we need to traverse the kernel with a slew of

[PATCH v2 4/8] selftests: firmware: send expected errors to /dev/null

Error that we expect should not be spilled to stdout. Without this we get: ./fw_filesystem.sh: line 58: printf: write error: Invalid argument ./fw_filesystem.sh: line 63: printf: write error: No such device ./fw_filesystem.sh: line 69: echo: write error: No such file or directory

[PATCH v2 0/8] firmware: add new sysdata API

my linux-next tree as well [4]. Please do note that all these series are based on linux-next tag next-20160616, and I noticed that Andrew Morton had picked up a patch by Stephen Boyd and Vikram Mulukutla to add yet-another new old firmware API. This then applies on top of that as its merged on linux

[PATCH v2 1/8] firmware: add new extensible firmware API - sysdata_file_request*()

The firmware API has evolved over the years slowly, as it grows we extend it by adding new routines or at times we extend existing routines with more or less arguments. This doesn't scale well, when new arguments are added to existing routines it means we need to traverse the kernel with a slew of

[PATCH v2 4/8] selftests: firmware: send expected errors to /dev/null

Error that we expect should not be spilled to stdout. Without this we get: ./fw_filesystem.sh: line 58: printf: write error: Invalid argument ./fw_filesystem.sh: line 63: printf: write error: No such device ./fw_filesystem.sh: line 69: echo: write error: No such file or directory

Re: [PATCH v2.1 07/11] mmc: sdhci-of-arasan: Add ability to export card clock

Am Mittwoch, 15. Juni 2016, 09:37:51 schrieb Douglas Anderson: > Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work > with arasan,sdhci-5.1) need to know the card clock in order to function > properly. Let's add the ability to expose this clock. Any PHY that > needs to know the

Re: [PATCH v2.1 07/11] mmc: sdhci-of-arasan: Add ability to export card clock

Am Mittwoch, 15. Juni 2016, 09:37:51 schrieb Douglas Anderson: > Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work > with arasan,sdhci-5.1) need to know the card clock in order to function > properly. Let's add the ability to expose this clock. Any PHY that > needs to know the

Re: [PATCH perf/core v11 07/20] perf probe: Add --cache option to cache the probe definitions

On Thu, 16 Jun 2016 11:29:06 -0300 Arnaldo Carvalho de Melo wrote: > Em Thu, Jun 16, 2016 at 06:38:30AM +0900, Masami Hiramatsu escreveu: > > On Wed, 15 Jun 2016 14:38:59 -0300 > > Arnaldo Carvalho de Melo wrote: > > > > > Em Wed, Jun 15, 2016 at 12:28:40PM

Re: [PATCH perf/core v11 07/20] perf probe: Add --cache option to cache the probe definitions

On Thu, 16 Jun 2016 11:29:06 -0300 Arnaldo Carvalho de Melo wrote: > Em Thu, Jun 16, 2016 at 06:38:30AM +0900, Masami Hiramatsu escreveu: > > On Wed, 15 Jun 2016 14:38:59 -0300 > > Arnaldo Carvalho de Melo wrote: > > > > > Em Wed, Jun 15, 2016 at 12:28:40PM +0900, Masami Hiramatsu escreveu: >

[PATCH 1/2] Documentation: dt: clock: Add fractional scale binding

Add fractional scale clock DTS binding. Signed-off-by: Hoan Tran Signed-off-by: Loc Ho --- .../bindings/clock/fractional-scale-clock.txt | 31 ++ 1 file changed, 31 insertions(+) create mode 100644

[PATCH 1/2] Documentation: dt: clock: Add fractional scale binding

Add fractional scale clock DTS binding. Signed-off-by: Hoan Tran Signed-off-by: Loc Ho --- .../bindings/clock/fractional-scale-clock.txt | 31 ++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/fractional-scale-clock.txt

[PATCH 2/2] clk: Add fractional scale clock support

This patch adds fractional scale clock support. Fractional scale clock is implemented for a single register field. Output rate = parent_rate * scale / denominator For example, for 1 / 8 fractional scale, denominator will be 8 and scale will be computed and programmed accordingly. Signed-off-by:

[PATCH 2/2] clk: Add fractional scale clock support

This patch adds fractional scale clock support. Fractional scale clock is implemented for a single register field. Output rate = parent_rate * scale / denominator For example, for 1 / 8 fractional scale, denominator will be 8 and scale will be computed and programmed accordingly. Signed-off-by:

[PATCH 0/2] clk: Add fractional scale clock support

This patch adds fractional scale clock support. Fractional scale clock is implemented for a single register field. Output rate = parent_rate * scale / denominator For example, for 1 / 8 fractional scale, denominator will be 8 and scale will be computed and programmed accordingly. Hoan Tran (2):

[PATCH 0/2] clk: Add fractional scale clock support

This patch adds fractional scale clock support. Fractional scale clock is implemented for a single register field. Output rate = parent_rate * scale / denominator For example, for 1 / 8 fractional scale, denominator will be 8 and scale will be computed and programmed accordingly. Hoan Tran (2):

Re: [PATCH v2 0/11] Changes to support 150 MHz eMMC on rk3399

Am Montag, 13. Juni 2016, 16:04:24 schrieb Douglas Anderson: > The theme of this series of patches is to try to allow running the eMMC > at 150 MHz on the rk3399 SoC, though the changes should still be correct > and have merit on their own. The motivation for running at 150 MHz is > that doing so

Re: [PATCH v2 0/11] Changes to support 150 MHz eMMC on rk3399

Am Montag, 13. Juni 2016, 16:04:24 schrieb Douglas Anderson: > The theme of this series of patches is to try to allow running the eMMC > at 150 MHz on the rk3399 SoC, though the changes should still be correct > and have merit on their own. The motivation for running at 150 MHz is > that doing so

Re: [PATCH 4/4] phy: rockchip-emmc: reindent the register definitions

Am Donnerstag, 12. Mai 2016, 15:43:06 schrieb Brian Norris: > Some of the spacing was wrong (spaces instead of tabs), and due to > longer entries added later, the columns weren't aligned. Let's get > everything consistent. > > Signed-off-by: Brian Norris Readability is

Re: [PATCH 4/4] phy: rockchip-emmc: reindent the register definitions

Am Donnerstag, 12. Mai 2016, 15:43:06 schrieb Brian Norris: > Some of the spacing was wrong (spaces instead of tabs), and due to > longer entries added later, the columns weren't aligned. Let's get > everything consistent. > > Signed-off-by: Brian Norris Readability is always nice :-)

Re: [PATCH 3/4] phy: rockchip-emmc: configure default output tap delay

Am Donnerstag, 12. Mai 2016, 15:43:05 schrieb Brian Norris: > The output tap delay controls helps maintain the hold requirements for > eMMC. The exact value is dependent on the SoC and other factors, though > it isn't really an exact science. But the default of 0 is not very good, > as it doesn't

Re: [PATCH 3/4] phy: rockchip-emmc: configure default output tap delay

Am Donnerstag, 12. Mai 2016, 15:43:05 schrieb Brian Norris: > The output tap delay controls helps maintain the hold requirements for > eMMC. The exact value is dependent on the SoC and other factors, though > it isn't really an exact science. But the default of 0 is not very good, > as it doesn't

Re: [PATCH v2 2/4] phy: rockchip-emmc: configure frequency range and drive impedance

Am Freitag, 13. Mai 2016, 14:09:43 schrieb Brian Norris: > From: Shawn Lin > > Signal integrity analysis has suggested we set these values. Do this in > power_on(), so that they get reconfigured after suspend/resume. > > Signed-off-by: Shawn Lin

Re: [PATCH v2 2/4] phy: rockchip-emmc: configure frequency range and drive impedance

Am Freitag, 13. Mai 2016, 14:09:43 schrieb Brian Norris: > From: Shawn Lin > > Signal integrity analysis has suggested we set these values. Do this in > power_on(), so that they get reconfigured after suspend/resume. > > Signed-off-by: Shawn Lin > Signed-off-by: Brian Norris on my rk3399-evb

Re: [PATCH 1/4] phy: rockchip-emmc: give DLL some extra time to be ready

Am Donnerstag, 12. Mai 2016, 15:43:03 schrieb Brian Norris: > From: Shawn Lin > > According to the databook, 10.2us is the max time for dll to be ready to > work. However in testing, some chips need 20us for dll to be ready. This > patch adds some extra margin for

Re: [PATCH 1/4] phy: rockchip-emmc: give DLL some extra time to be ready

Am Donnerstag, 12. Mai 2016, 15:43:03 schrieb Brian Norris: > From: Shawn Lin > > According to the databook, 10.2us is the max time for dll to be ready to > work. However in testing, some chips need 20us for dll to be ready. This > patch adds some extra margin for dllrdy to be ready, fixing our

Re: [PATCH v4 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

Hi William, Am Donnerstag, 2. Juni 2016, 20:34:56 schrieb William Wu: > This patch adds the devicetree documentation required for Rockchip > USB3.0 core wrapper consisting of USB3.0 IP from Synopsys. > > It supports DRD mode, and could operate in device mode (SS, HS, FS) > and host mode (SS, HS,

Re: [PATCH v4 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

Hi William, Am Donnerstag, 2. Juni 2016, 20:34:56 schrieb William Wu: > This patch adds the devicetree documentation required for Rockchip > USB3.0 core wrapper consisting of USB3.0 IP from Synopsys. > > It supports DRD mode, and could operate in device mode (SS, HS, FS) > and host mode (SS, HS,

Re: [PATCH 1/3] mm: Don't blindly assign fallback_migrate_page()

On Thu, 16 Jun 2016 23:26:13 +0200 Richard Weinberger wrote: > While block oriented filesystems use buffer_migrate_page() > as page migration function other filesystems which don't > implement ->migratepage() will automatically get fallback_migrate_page() > assigned.

Re: [PATCH 1/3] mm: Don't blindly assign fallback_migrate_page()

On Thu, 16 Jun 2016 23:26:13 +0200 Richard Weinberger wrote: > While block oriented filesystems use buffer_migrate_page() > as page migration function other filesystems which don't > implement ->migratepage() will automatically get fallback_migrate_page() > assigned. fallback_migrate_page() is

x86/tsc: Set X86_FEATURE_TSC_RELIABLE to skip refined calibration

Unlike PIT based calibration which counts TSC cycles against another timer, MSR or CPUID method has no calibration - it simply multiplies the known frequency of a timer by a ratio. So TSC frequency computed by MSR or CPUID is the final frequency and doesn't need the refined calibration process. We

x86/tsc: Set X86_FEATURE_TSC_RELIABLE to skip refined calibration

Unlike PIT based calibration which counts TSC cycles against another timer, MSR or CPUID method has no calibration - it simply multiplies the known frequency of a timer by a ratio. So TSC frequency computed by MSR or CPUID is the final frequency and doesn't need the refined calibration process. We

Re: Kernel 4.7rc3 - Performance drop 30-40% for SPECjbb2005 and SPECjvm2008 benchmarks against 4.6 kernel

> > we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008 > Blergh, of course I don't have those.. :/ SPECjvm2008 is publicly available. https://www.spec.org/download.html We will prepare a reproducer and attach it to the BZ. > What kind of config and userspace setup? Do you run this

Re: Kernel 4.7rc3 - Performance drop 30-40% for SPECjbb2005 and SPECjvm2008 benchmarks against 4.6 kernel

> > we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008 > Blergh, of course I don't have those.. :/ SPECjvm2008 is publicly available. https://www.spec.org/download.html We will prepare a reproducer and attach it to the BZ. > What kind of config and userspace setup? Do you run this

Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

On 16/06/2016 09:33, Pali Rohár wrote: > On Wednesday 15 June 2016 20:19:58 Darren Hart wrote: >> On Wed, Jun 15, 2016 at 09:49:09PM +0200, Pali Rohár wrote: >>> First patch describe problem about 0xe045 code. Second and third are just >>> cosmetic and last rework code which processing WMI events.

Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

On 16/06/2016 09:33, Pali Rohár wrote: > On Wednesday 15 June 2016 20:19:58 Darren Hart wrote: >> On Wed, Jun 15, 2016 at 09:49:09PM +0200, Pali Rohár wrote: >>> First patch describe problem about 0xe045 code. Second and third are just >>> cosmetic and last rework code which processing WMI events.

[PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

-next.git/log/?h=20160616-sysdata-v2 Luis R. Rodriguez (5): MAINTAINERS: extend firmware_class maintainer list firmware: annotate thou shalt not request fw on init or probe firmware: update usermode helper docs and add SmPL report firmware: add usermode helper DECLARE_FW_LOADER_USER

[PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

-next.git/log/?h=20160616-sysdata-v2 Luis R. Rodriguez (5): MAINTAINERS: extend firmware_class maintainer list firmware: annotate thou shalt not request fw on init or probe firmware: update usermode helper docs and add SmPL report firmware: add usermode helper DECLARE_FW_LOADER_USER

[PATCH v2 5/5] firmware: fix fw cache to avoid usermode helper on suspend

The firmware cache purposely kills all non-udev (usermode helper) pending requests prior to suspend with kill_requests_without_uevent() right before it calls out to request for firmware for the fw cache. It is pointless to again run into the possible issue of queing up further usermode helpers

[PATCH v2 5/5] firmware: fix fw cache to avoid usermode helper on suspend

The firmware cache purposely kills all non-udev (usermode helper) pending requests prior to suspend with kill_requests_without_uevent() right before it calls out to request for firmware for the fw cache. It is pointless to again run into the possible issue of queing up further usermode helpers

[PATCH v2 3/5] firmware: update usermode helper docs and add SmPL report

We've determined that very sadly we cannot nuke the usermode helper. The firmware code is a bit hard to follow, and so is the history, document the reasons for why we cannot remove the usermode helper and the only thing we can do is compartamentalize it. While it, add a Coccinelle SmPL patch to

[PATCH v2 3/5] firmware: update usermode helper docs and add SmPL report

We've determined that very sadly we cannot nuke the usermode helper. The firmware code is a bit hard to follow, and so is the history, document the reasons for why we cannot remove the usermode helper and the only thing we can do is compartamentalize it. While it, add a Coccinelle SmPL patch to

[PATCH v2 4/5] firmware: add usermode helper DECLARE_FW_LOADER_USER() annotation

We need to ensure no one else adds *anything* that requests the usermode helper without really meaning it, to police it we now have an SmPL script but no formal annotation is present to help us ensure the call has been validated. Add a dummy DECLARE_FW_LOADER_USER() which we can use to annotate

[PATCH v2 1/5] MAINTAINERS: extend firmware_class maintainer list

I've been reviewing changes proactively, and plan on doing more of this work. I'm doing this early as I should be getting e-mailed about proposed changes. Signed-off-by: Luis R. Rodriguez --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS

[PATCH v2 1/5] MAINTAINERS: extend firmware_class maintainer list

I've been reviewing changes proactively, and plan on doing more of this work. I'm doing this early as I should be getting e-mailed about proposed changes. Signed-off-by: Luis R. Rodriguez --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index

[PATCH v2 4/5] firmware: add usermode helper DECLARE_FW_LOADER_USER() annotation

We need to ensure no one else adds *anything* that requests the usermode helper without really meaning it, to police it we now have an SmPL script but no formal annotation is present to help us ensure the call has been validated. Add a dummy DECLARE_FW_LOADER_USER() which we can use to annotate

[PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

Thou shalt not make firmware calls early on init or probe. systemd already ripped support out for the usermode helper a while ago, there are still users that require the usermode helper, however systemd's use of the usermode helper exacerbated a long lasting issue of the fact that we have many

[PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

Thou shalt not make firmware calls early on init or probe. systemd already ripped support out for the usermode helper a while ago, there are still users that require the usermode helper, however systemd's use of the usermode helper exacerbated a long lasting issue of the fact that we have many

Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

On Wed, Jun 15, 2016 at 01:39:21PM +0200, Joerg Roedel wrote: >On Tue, May 24, 2016 at 11:06:55PM +, Wei Yang wrote: >> Hi, Joerg >> >> Not sure whether you think this calculation is correct. >> >> If I missed something for this " + 1" in your formula, I am glad to hear your >> explanation.

Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

On Wed, Jun 15, 2016 at 01:39:21PM +0200, Joerg Roedel wrote: >On Tue, May 24, 2016 at 11:06:55PM +, Wei Yang wrote: >> Hi, Joerg >> >> Not sure whether you think this calculation is correct. >> >> If I missed something for this " + 1" in your formula, I am glad to hear your >> explanation.

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote: > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote: > > I guess we'll need the bisect on this one to make progress. > > Sigh, I was afraid that might be the next step. OK, I have a curious data point. I assumed the problem would be

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote: > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote: > > I guess we'll need the bisect on this one to make progress. > > Sigh, I was afraid that might be the next step. OK, I have a curious data point. I assumed the problem would be

[PATCH v2 3/8] coccicheck: add indexing enhancement options

Coccinelle has support to make use of its own enhanced "grep" mechanisms instead of using regular grep for searching code, it calls this 'coccigrep'. In lack of any indexing optimization information it uses --use-coccigrep by default. This patch enable indexing optimizations heuristics so that

[PATCH v2 6/8] coccicheck: add support for requring a coccinelle version

Enable Coccinelle SmPL patches to require a specific version of Coccinelle. In the event that the version does not match we just inform the user, if the user asked to go through all SmPL patches we just inform them of the need for a new version of coccinelle for the SmPL patch and continue on with

[PATCH v2 3/8] coccicheck: add indexing enhancement options

Coccinelle has support to make use of its own enhanced "grep" mechanisms instead of using regular grep for searching code, it calls this 'coccigrep'. In lack of any indexing optimization information it uses --use-coccigrep by default. This patch enable indexing optimizations heuristics so that

[PATCH v2 6/8] coccicheck: add support for requring a coccinelle version

Enable Coccinelle SmPL patches to require a specific version of Coccinelle. In the event that the version does not match we just inform the user, if the user asked to go through all SmPL patches we just inform them of the need for a new version of coccinelle for the SmPL patch and continue on with

[PATCH v2 1/8] coccicheck: move spatch binary check up

This has no functional changes. This is being done to enable us to later use spatch binary for some flag checking for certain features early on. Signed-off-by: Luis R. Rodriguez --- scripts/coccicheck | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff

[PATCH v2 0/8] coccicheck: modernize

series, all of which you can find here: https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160616-sysdata-v2 Since further development is done on top of this we may need to coordinate with another maintainer for how these go in. The coccicheck changes will be important

[PATCH v2 1/8] coccicheck: move spatch binary check up

This has no functional changes. This is being done to enable us to later use spatch binary for some flag checking for certain features early on. Signed-off-by: Luis R. Rodriguez --- scripts/coccicheck | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH v2 0/8] coccicheck: modernize

series, all of which you can find here: https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160616-sysdata-v2 Since further development is done on top of this we may need to coordinate with another maintainer for how these go in. The coccicheck changes will be important

[PATCH v2 2/8] coccicheck: enable parmap support

Coccinelle has had parmap support since 1.0.2, this means it supports --jobs, enabling built-in multithreaded functionality, instead of needing one to script it out. Just look for --jobs in the help output to determine if this is supported. Also enable the load balancing to be dynamic, so that if

[PATCH v2 5/8] coccicheck: replace --very-quiet with --quit when debugging

When debugging (using --profile or --show-trying) you want to avoid supressing output, use --quiet instead. While at it, extend documentation for SPFLAGS use. For instance one can use: $ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci $ make coccicheck DEBUG_FILE="poo.err" MODE=report

[PATCH v2 7/8] coccicheck: refer to coccicheck bottest wiki for documentation

Sprinkling *tons* of documentation on the script is not a good idea, instead refer to a wiki for further coccicheck documentation: https://bottest.wiki.kernel.org/coccicheck This page shall always refer to the linux-next iteration of scripts/coccicheck. Signed-off-by: Luis R. Rodriguez

[PATCH v2 2/8] coccicheck: enable parmap support

Coccinelle has had parmap support since 1.0.2, this means it supports --jobs, enabling built-in multithreaded functionality, instead of needing one to script it out. Just look for --jobs in the help output to determine if this is supported. Also enable the load balancing to be dynamic, so that if

[PATCH v2 5/8] coccicheck: replace --very-quiet with --quit when debugging

When debugging (using --profile or --show-trying) you want to avoid supressing output, use --quiet instead. While at it, extend documentation for SPFLAGS use. For instance one can use: $ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci $ make coccicheck DEBUG_FILE="poo.err" MODE=report

[PATCH v2 7/8] coccicheck: refer to coccicheck bottest wiki for documentation

Sprinkling *tons* of documentation on the script is not a good idea, instead refer to a wiki for further coccicheck documentation: https://bottest.wiki.kernel.org/coccicheck This page shall always refer to the linux-next iteration of scripts/coccicheck. Signed-off-by: Luis R. Rodriguez ---

[PATCH v2 8/8] scripts/coccinelle: require coccinelle >= 1.0.4 on device_node_continue.cocci

Make use of the new Requires: tag to be able to specify coccinelle binary version requirements. The cocci file device_node_continue.cocci requires at least coccinelle 1.0.4. Signed-off-by: Luis R. Rodriguez --- scripts/coccinelle/iterators/device_node_continue.cocci | 3 +++

[PATCH v2 4/8] scripts: add glimpse.sh for indexing the kernel

Glimpse is a tool you can use to index the kernel. The tool was open sourced on 2014-09-26 [0] under the ISC license however the original release still [1] does not compile. A fix for this and a release that does compile is provided in a temporary tree [2]. v2 changesl: o simplify DIR in one line

[PATCH v2 8/8] scripts/coccinelle: require coccinelle >= 1.0.4 on device_node_continue.cocci

Make use of the new Requires: tag to be able to specify coccinelle binary version requirements. The cocci file device_node_continue.cocci requires at least coccinelle 1.0.4. Signed-off-by: Luis R. Rodriguez --- scripts/coccinelle/iterators/device_node_continue.cocci | 3 +++ 1 file changed, 3

[PATCH v2 4/8] scripts: add glimpse.sh for indexing the kernel

Glimpse is a tool you can use to index the kernel. The tool was open sourced on 2014-09-26 [0] under the ISC license however the original release still [1] does not compile. A fix for this and a release that does compile is provided in a temporary tree [2]. v2 changesl: o simplify DIR in one line

Re: [PATCH 2 2/2] arm64: dts: apm: Remove leading '0x' from unit addresses

On Tue, Jun 14, 2016 at 08:00:30AM -0500, Bjorn Helgaas wrote: > Unit addresses should not have a leading '0x'. Remove them. > > Signed-off-by: Bjorn Helgaas > --- > arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 32 > ++-- > 1 file changed, 16

Re: [PATCH 2 2/2] arm64: dts: apm: Remove leading '0x' from unit addresses

On Tue, Jun 14, 2016 at 08:00:30AM -0500, Bjorn Helgaas wrote: > Unit addresses should not have a leading '0x'. Remove them. > > Signed-off-by: Bjorn Helgaas > --- > arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 32 > ++-- > 1 file changed, 16 insertions(+), 16

Re: [PATCH 2 1/2] arm64: dts: apm: Use lowercase consistently for hex constants

On Tue, Jun 14, 2016 at 08:00:20AM -0500, Bjorn Helgaas wrote: > The convention in these files is to use lowercase for "0x" prefixes and for > the hex constants themselves, but a few changes didn't follow that > convention, which makes the file annoying to read. > > Use lowercase consistently for

Re: [PATCH 2 1/2] arm64: dts: apm: Use lowercase consistently for hex constants

On Tue, Jun 14, 2016 at 08:00:20AM -0500, Bjorn Helgaas wrote: > The convention in these files is to use lowercase for "0x" prefixes and for > the hex constants themselves, but a few changes didn't follow that > convention, which makes the file annoying to read. > > Use lowercase consistently for

Re: [kernel-hardening] [PATCH 2/2] security,perf: Allow further restriction of perf_event_open

Hi guys, This patch wasn't originally CCed to you (I'm fixing that now). Would you consider taking this into the perf tree? It's been in active use in both Debian and Android for a while now. (If need be, I can resend it.) Thanks! -Kees On Sat, Jun 4, 2016 at 1:49 PM, Jeffrey Vander Stoep

Re: [kernel-hardening] [PATCH 2/2] security,perf: Allow further restriction of perf_event_open

Hi guys, This patch wasn't originally CCed to you (I'm fixing that now). Would you consider taking this into the perf tree? It's been in active use in both Debian and Android for a while now. (If need be, I can resend it.) Thanks! -Kees On Sat, Jun 4, 2016 at 1:49 PM, Jeffrey Vander Stoep

Re: [PATCH v3 14/14] regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range

On Tue, Jun 14, 2016 at 11:13:22AM +0200, Boris Brezillon wrote: > Document the pwm-dutycycle-unit and pwm-dutycycle-range properties. > > Signed-off-by: Boris Brezillon > Acked-by: Brian Norris > --- >

Re: [PATCH v3 14/14] regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range

On Tue, Jun 14, 2016 at 11:13:22AM +0200, Boris Brezillon wrote: > Document the pwm-dutycycle-unit and pwm-dutycycle-range properties. > > Signed-off-by: Boris Brezillon > Acked-by: Brian Norris > --- > .../devicetree/bindings/regulator/pwm-regulator.txt | 19 > +++ > 1 file

Re: cmpxchg and x86 flags output

On 06/15/16 01:50, Peter Zijlstra wrote: >> >> It seems to me that the sanest way to handle this is to add a new >> interface with a fourth parameter, so: >> >> changed = cmpxchgx(ptr, old, new, out); > > See also: > > >

Re: cmpxchg and x86 flags output

On 06/15/16 01:50, Peter Zijlstra wrote: >> >> It seems to me that the sanest way to handle this is to add a new >> interface with a fourth parameter, so: >> >> changed = cmpxchgx(ptr, old, new, out); > > See also: > > >

Re: [PATCH v3 1/2] nxp/dts: add pcie aer interrupt-name property in the dts

On Tue, Jun 14, 2016 at 04:24:04PM +0800, Po Liu wrote: > NXP some platforms aer interrupt was not MSI/MSI-X/INTx > but using interrupt line independently. This patch add a "aer" > interrupt-names for aer interrupt. Please put your explanation why this is okay to change in the commit message. >

Re: [PATCH v3 1/2] nxp/dts: add pcie aer interrupt-name property in the dts

On Tue, Jun 14, 2016 at 04:24:04PM +0800, Po Liu wrote: > NXP some platforms aer interrupt was not MSI/MSI-X/INTx > but using interrupt line independently. This patch add a "aer" > interrupt-names for aer interrupt. Please put your explanation why this is okay to change in the commit message. >

Re: [PATCH v2] cgroup: disable irqs while holding css_set_lock

On Thu, Jun 16, 2016 at 06:03:15PM -0400, Tejun Heo wrote: > On Thu, Jun 16, 2016 at 06:48:56PM -0300, Daniel Bristot de Oliveira wrote: > > On 06/07/2016 05:05 PM, Daniel Bristot de Oliveira wrote: > > > On 06/07/2016 04:30 PM, Tejun Heo wrote: > > >> Is this something in mainline? This forces

Re: [PATCH v2] cgroup: disable irqs while holding css_set_lock

On Thu, Jun 16, 2016 at 06:03:15PM -0400, Tejun Heo wrote: > On Thu, Jun 16, 2016 at 06:48:56PM -0300, Daniel Bristot de Oliveira wrote: > > On 06/07/2016 05:05 PM, Daniel Bristot de Oliveira wrote: > > > On 06/07/2016 04:30 PM, Tejun Heo wrote: > > >> Is this something in mainline? This forces

Re: [PATCH v2] cgroup: disable irqs while holding css_set_lock

On Thu, Jun 16, 2016 at 06:48:56PM -0300, Daniel Bristot de Oliveira wrote: > On 06/07/2016 05:05 PM, Daniel Bristot de Oliveira wrote: > > On 06/07/2016 04:30 PM, Tejun Heo wrote: > >> Is this something in mainline? This forces all task free path to be > >> irq-safe, which *could* be fine but

Re: [PATCH v2] cgroup: disable irqs while holding css_set_lock

On Thu, Jun 16, 2016 at 06:48:56PM -0300, Daniel Bristot de Oliveira wrote: > On 06/07/2016 05:05 PM, Daniel Bristot de Oliveira wrote: > > On 06/07/2016 04:30 PM, Tejun Heo wrote: > >> Is this something in mainline? This forces all task free path to be > >> irq-safe, which *could* be fine but

Re: [RFC PATCH 2/2] KVM: x86: use __kvm_guest_exit

... > static bool vmx_has_high_real_mode_segbase(void) > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 7e3041ef050f..cc741b68139c 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -6706,21 +6706,13 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) > >

Re: [RFC PATCH 2/2] KVM: x86: use __kvm_guest_exit

... > static bool vmx_has_high_real_mode_segbase(void) > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 7e3041ef050f..cc741b68139c 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -6706,21 +6706,13 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) > >

Re: [PATCH 1/2] clocksource: Kconfig: fix tabs vs space

On 16/06/2016 at 16:38:46 +0200, Daniel Lezcano wrote : > On 06/10/2016 05:54 PM, Alexandre Belloni wrote: > > Some options are indented with spaces, properly use tabs instead > > > > Signed-off-by: Alexandre Belloni > > --- > > I will postpone this patch

Re: [PATCH 1/2] clocksource: Kconfig: fix tabs vs space

On 16/06/2016 at 16:38:46 +0200, Daniel Lezcano wrote : > On 06/10/2016 05:54 PM, Alexandre Belloni wrote: > > Some options are indented with spaces, properly use tabs instead > > > > Signed-off-by: Alexandre Belloni > > --- > > I will postpone this patch because it is creating a big issue with

[PATCH v2] mfd: intel_soc_pmic_bxtwc: Add Intel BXT WhiskeyCove PMIC ADC thermal channel-zone mapping

This patch adds the mapping of PMIC ADC channel to thermal zone. This mapping is used in the pmic thermal driver to notify the thermal zone with the pmic adc channel alert interrupts. This patch also adds three new data structures to include/linux/mfd/intel_soc_pmic.h: struct trip_config_map{},

[PATCH v2] mfd: intel_soc_pmic_bxtwc: Add Intel BXT WhiskeyCove PMIC ADC thermal channel-zone mapping

This patch adds the mapping of PMIC ADC channel to thermal zone. This mapping is used in the pmic thermal driver to notify the thermal zone with the pmic adc channel alert interrupts. This patch also adds three new data structures to include/linux/mfd/intel_soc_pmic.h: struct trip_config_map{},

Re: [PATCH] mm: compaction: fix dummy declarations

On Thu, 16 Jun 2016 08:30:28 +0900 Minchan Kim wrote: > Hi Andrew, > > On Wed, Jun 15, 2016 at 02:48:25PM -0700, Andrew Morton wrote: > > On Wed, 15 Jun 2016 23:39:12 +0200 Arnd Bergmann wrote: > > > > > We get a build error in several test builds after a

Re: [PATCH] mm: compaction: fix dummy declarations

On Thu, 16 Jun 2016 08:30:28 +0900 Minchan Kim wrote: > Hi Andrew, > > On Wed, Jun 15, 2016 at 02:48:25PM -0700, Andrew Morton wrote: > > On Wed, 15 Jun 2016 23:39:12 +0200 Arnd Bergmann wrote: > > > > > We get a build error in several test builds after a recent code rework: > > > > > > In

Re: [RFC PATCH 1/2] KVM: x86: always use "acknowledge interrupt on exit"

Paolo Bonzini writes: > This is necessary to simplify handle_external_intr in the next patch. > It means that nested KVM will require 3.16 on the host (or 3.17 if you > have APICv enabled). > > Signed-off-by: Paolo Bonzini > --- > arch/x86/kvm/vmx.c |

Re: [RFC PATCH 1/2] KVM: x86: always use "acknowledge interrupt on exit"

Paolo Bonzini writes: > This is necessary to simplify handle_external_intr in the next patch. > It means that nested KVM will require 3.16 on the host (or 3.17 if you > have APICv enabled). > > Signed-off-by: Paolo Bonzini > --- > arch/x86/kvm/vmx.c | 7 +++ > 1 file changed, 3

4.6.2 frequent crashes under memory + IO pressure

Hi, a man's got to have a hobby, thus I'm running Android AOSP builds on my home PC which has 4GB of RAM, 4GB swap. Apparently it is not really adequate for the job but used to work with a 4.4.10 kernel. Now I upgraded to 4.6.2 and it crashes usually within 30mins during compilation. The crash

4.6.2 frequent crashes under memory + IO pressure

Hi, a man's got to have a hobby, thus I'm running Android AOSP builds on my home PC which has 4GB of RAM, 4GB swap. Apparently it is not really adequate for the job but used to work with a 4.4.10 kernel. Now I upgraded to 4.6.2 and it crashes usually within 30mins during compilation. The crash

Re: [PATCH v2] cgroup: disable irqs while holding css_set_lock

On 06/07/2016 05:05 PM, Daniel Bristot de Oliveira wrote: > On 06/07/2016 04:30 PM, Tejun Heo wrote: >> Is this something in mainline? This forces all task free path to be >> irq-safe, which *could* be fine but it's weird to make cgroup free >> path irq-safe for something which isn't in mainline.

Re: [PATCH v2] cgroup: disable irqs while holding css_set_lock

On 06/07/2016 05:05 PM, Daniel Bristot de Oliveira wrote: > On 06/07/2016 04:30 PM, Tejun Heo wrote: >> Is this something in mainline? This forces all task free path to be >> irq-safe, which *could* be fine but it's weird to make cgroup free >> path irq-safe for something which isn't in mainline.

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