[GIT PULL] parisc fixes for 4.6-rc2

Hi Linus, please pull some important fixes for the parisc architecture from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.6-3 Since commit 0de7985 (parisc: Use generic extable search and sort routines) module loading is boken on parisc, because the parisc

[GIT PULL] parisc fixes for 4.6-rc2

Hi Linus, please pull some important fixes for the parisc architecture from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.6-3 Since commit 0de7985 (parisc: Use generic extable search and sort routines) module loading is boken on parisc, because the parisc

Re: Kernel crash on startup - bisected to commit 3b24d854cb35

On Fri, Apr 8, 2016 at 10:28 PM, Larry Finger wrote: > Following a recent pull of the wireless-drivers-next repo. my system got a > kernel panic on startup at native_apic_msr_write+0x27. The problem was > bisected to commit 3b24d854cb35 ("tcp/dccp: do not touch listener

Re: Kernel crash on startup - bisected to commit 3b24d854cb35

On Fri, Apr 8, 2016 at 10:28 PM, Larry Finger wrote: > Following a recent pull of the wireless-drivers-next repo. my system got a > kernel panic on startup at native_apic_msr_write+0x27. The problem was > bisected to commit 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt > under

Re: [PATCH v11 00/60] PCI: Resource allocation cleanup for v4.7

On Thu, Apr 7, 2016 at 5:51 PM, Linus Torvalds wrote: > > So please, try to split this up sanely, and let's merge it in sane > pieces. I see that you have that M7101 quirk removal randomly in the > middle of this series, for example, and it doesn't seem to be the

Re: [PATCH v11 00/60] PCI: Resource allocation cleanup for v4.7

On Thu, Apr 7, 2016 at 5:51 PM, Linus Torvalds wrote: > > So please, try to split this up sanely, and let's merge it in sane > pieces. I see that you have that M7101 quirk removal randomly in the > middle of this series, for example, and it doesn't seem to be the only > such random patch. That's

Re: [PATCH 4/4] irqchip: bcm2836: Use a more generic memory barrier call

On 04/08/2016 12:20 PM, Eric Anholt wrote: Stephen Warren writes: On 04/04/2016 09:44 PM, Eric Anholt wrote: dsb() requires an argument on arm64, so we needed to add "sy". Instead, take this opportunity to switch to the same smp_wmb() call that gic uses for its IPIs.

Re: [PATCH 4/4] irqchip: bcm2836: Use a more generic memory barrier call

On 04/08/2016 12:20 PM, Eric Anholt wrote: Stephen Warren writes: On 04/04/2016 09:44 PM, Eric Anholt wrote: dsb() requires an argument on arm64, so we needed to add "sy". Instead, take this opportunity to switch to the same smp_wmb() call that gic uses for its IPIs. This is a less strong

[GIT] Networking

1) Stale SKB data pointer access across pskb_may_pull() calls in L2TP, from Haishuang Yan. 2) Fix multicast frame handling in mac80211 AP code, from Felix Fietkau. 3) mac80211 station hashtable insert errors not handled properly, fix from Johannes Berg. 4) Fix TX descriptor count

[GIT] Networking

1) Stale SKB data pointer access across pskb_may_pull() calls in L2TP, from Haishuang Yan. 2) Fix multicast frame handling in mac80211 AP code, from Felix Fietkau. 3) mac80211 station hashtable insert errors not handled properly, fix from Johannes Berg. 4) Fix TX descriptor count

Re: [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skipregular OOM killer path

Michal Hocko wrote: > On Fri 08-04-16 20:19:28, Tetsuo Handa wrote: > > I looked at next-20160408 but I again came to think that we should remove > > these shortcuts (something like a patch shown bottom). > > feel free to send the patch with the full description. But I would &

Re: [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skipregular OOM killer path

Michal Hocko wrote: > On Fri 08-04-16 20:19:28, Tetsuo Handa wrote: > > I looked at next-20160408 but I again came to think that we should remove > > these shortcuts (something like a patch shown bottom). > > feel free to send the patch with the full description. But I would &

Re: [PATCH] sched/deadline/rtmutex: Fix a PI crash for deadline tasks

On 2016/04/09 at 03:28, Steven Rostedt wrote: > On Fri, 8 Apr 2016 15:15:42 -0400 > Steven Rostedt wrote: > >> From what I understand, the slowfn() modifies the task pi_list (or >> rbtree, as it is today). As this is an unlock, the task being woken >> (the next one to grab

Re: [PATCH] sched/deadline/rtmutex: Fix a PI crash for deadline tasks

On 2016/04/09 at 03:28, Steven Rostedt wrote: > On Fri, 8 Apr 2016 15:15:42 -0400 > Steven Rostedt wrote: > >> From what I understand, the slowfn() modifies the task pi_list (or >> rbtree, as it is today). As this is an unlock, the task being woken >> (the next one to grab the lock) is removed

[9 Apr 2016] Singapore Government Hackers Keep Deleting Teo En Ming's Firefox Bookmarks

Computer Hacking Incident Reporting (9 April 2016 Saturday) === Singapore Government computer hackers keep deleting Teo En Ming's Firefox bookmarks. A few days ago, on 4 April 2016 Monday, I began to systematically add Firefox bookmarks for

Re: [PATCH] sched/deadline/rtmutex: Fix a PI crash for deadline tasks

On 2016/04/09 at 02:59, Peter Zijlstra wrote: > On Fri, Apr 08, 2016 at 02:50:55PM -0400, Steven Rostedt wrote: >> On Fri, 8 Apr 2016 19:38:35 +0200 >> Peter Zijlstra wrote: >> >>> On Fri, Apr 08, 2016 at 12:25:10PM -0400, Steven Rostedt wrote: >>> So the

[9 Apr 2016] Singapore Government Hackers Keep Deleting Teo En Ming's Firefox Bookmarks

Computer Hacking Incident Reporting (9 April 2016 Saturday) === Singapore Government computer hackers keep deleting Teo En Ming's Firefox bookmarks. A few days ago, on 4 April 2016 Monday, I began to systematically add Firefox bookmarks for

Re: [PATCH] sched/deadline/rtmutex: Fix a PI crash for deadline tasks

On 2016/04/09 at 02:59, Peter Zijlstra wrote: > On Fri, Apr 08, 2016 at 02:50:55PM -0400, Steven Rostedt wrote: >> On Fri, 8 Apr 2016 19:38:35 +0200 >> Peter Zijlstra wrote: >> >>> On Fri, Apr 08, 2016 at 12:25:10PM -0400, Steven Rostedt wrote: >>> So the preempt_disable() is to allow us to

[PATCH] nvme/host: Add missing blk_integrity tag_size + flags assignments

From: Nicholas Bellinger While doing recent bring-up of nvme/host with target-core T10-PI, I noticed /sys/block/nvme*/integrity/device_is_integrity_capable was false, and /sys/block/nvme*/integrity/tag_size contained a bogus value. AFAICT outside of blk_integrity_compare()

[PATCH] nvme/host: Add missing blk_integrity tag_size + flags assignments

From: Nicholas Bellinger While doing recent bring-up of nvme/host with target-core T10-PI, I noticed /sys/block/nvme*/integrity/device_is_integrity_capable was false, and /sys/block/nvme*/integrity/tag_size contained a bogus value. AFAICT outside of blk_integrity_compare() for DM + MD these are

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

On Friday 08 April 2016, Andrew Pinski wrote: > On Thu, Apr 7, 2016 at 5:18 AM, Adam Borowski wrote: > > On Wed, 6 Apr 2016, Geert Uytterhoeven wrote: > >> On Wed, Apr 6, 2016 at 12:08 AM, Yury Norov > >> wrote: > >>> v6: > >>> - time_t,

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

On Friday 08 April 2016, Andrew Pinski wrote: > On Thu, Apr 7, 2016 at 5:18 AM, Adam Borowski wrote: > > On Wed, 6 Apr 2016, Geert Uytterhoeven wrote: > >> On Wed, Apr 6, 2016 at 12:08 AM, Yury Norov > >> wrote: > >>> v6: > >>> - time_t, __kenel_off_t and other types turned to be 32-bit > >>>

Re: [PATCH v5 6/9] irqchip/gic-v3: Parse and export virtual GIC information

Hi Julien, On 04/04/2016 06:37 AM, Julien Grall wrote: > Fill up the recently introduced gic_kvm_info with the hardware > information used for virtualization. > > Signed-off-by: Julien Grall > Cc: Thomas Gleixner > Cc: Jason Cooper

Re: [PATCH v5 6/9] irqchip/gic-v3: Parse and export virtual GIC information

Hi Julien, On 04/04/2016 06:37 AM, Julien Grall wrote: > Fill up the recently introduced gic_kvm_info with the hardware > information used for virtualization. > > Signed-off-by: Julien Grall > Cc: Thomas Gleixner > Cc: Jason Cooper > Cc: Marc Zyngier > > --- > Changes in v5: > -

Re: [PATCH] arm64: CONFIG_DEVPORT should not be used when PCI is being used

On Thursday 07 April 2016, Al Stone wrote: > >>> config DEVPORT > >>> bool > >>> - depends on !M68K > >>> + depends on !M68K && !ARM64 > >> > >> Why not fix the real bug here, it's odd that only these two arches need > >> this disabled, don't you agree? > > Agreed. It does seem

Re: [PATCH] arm64: CONFIG_DEVPORT should not be used when PCI is being used

On Thursday 07 April 2016, Al Stone wrote: > >>> config DEVPORT > >>> bool > >>> - depends on !M68K > >>> + depends on !M68K && !ARM64 > >> > >> Why not fix the real bug here, it's odd that only these two arches need > >> this disabled, don't you agree? > > Agreed. It does seem

Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

On Thu, Mar 17, 2016 at 03:56:47PM -0600, Toshi Kani wrote: > On Wed, 2016-03-16 at 00:29 +0100, Luis R. Rodriguez wrote: > > On x86 Linux code we now have ioremap_uc() that can't use MTRR behind the > > scenes, why would something like this on the BIOS not be possible? That > > ultimately uses

Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

On Thu, Mar 17, 2016 at 03:56:47PM -0600, Toshi Kani wrote: > On Wed, 2016-03-16 at 00:29 +0100, Luis R. Rodriguez wrote: > > On x86 Linux code we now have ioremap_uc() that can't use MTRR behind the > > scenes, why would something like this on the BIOS not be possible? That > > ultimately uses

Re: [PATCH 1/4] acpi,pci,irq: reduce resource requirements

Hi Bjorn, On 4/5/2016 7:21 PM, Bjorn Helgaas wrote: >> I know you want to validate that all PCI interrupts are level, it looks like >> the code >> > is allowing other combinations. > It's not that we need to validate that all PCI interrupts are level. What > we need is to make sure all users

Re: [PATCH 1/4] acpi,pci,irq: reduce resource requirements

Hi Bjorn, On 4/5/2016 7:21 PM, Bjorn Helgaas wrote: >> I know you want to validate that all PCI interrupts are level, it looks like >> the code >> > is allowing other combinations. > It's not that we need to validate that all PCI interrupts are level. What > we need is to make sure all users

[PATCH V2 1/3] acpi,pci,irq: reduce resource requirements

Code has been redesigned to calculate penalty requirements on the fly. This significantly simplifies the implementation and removes some of the init calls from x86 architecture. Command line penalty assignment has been limited to ISA interrupts only. Signed-off-by: Sinan Kaya

[PATCH V2 1/3] acpi,pci,irq: reduce resource requirements

Code has been redesigned to calculate penalty requirements on the fly. This significantly simplifies the implementation and removes some of the init calls from x86 architecture. Command line penalty assignment has been limited to ISA interrupts only. Signed-off-by: Sinan Kaya ---

[PATCH V2 2/3] acpi,pci,irq: remove redundant code in acpi_irq_penalty_init

acpi_irq_get_penalty is now calculating the penalty on the fly now. No need to maintain global list of penalties or calculate them at the init time. Removing duplicate code in acpi_irq_penalty_init. Signed-off-by: Sinan Kaya --- arch/x86/pci/acpi.c | 1 -

[PATCH V2 3/3] acpi,pci,irq: remove SCI penalize function

Removing the SCI penalize function as the penalty is now calculated on the fly. Signed-off-by: Sinan Kaya --- arch/x86/kernel/acpi/boot.c | 1 - drivers/acpi/pci_link.c | 9 - include/linux/acpi.h| 1 - 3 files changed, 11 deletions(-) diff --git

[PATCH V2 3/3] acpi,pci,irq: remove SCI penalize function

Removing the SCI penalize function as the penalty is now calculated on the fly. Signed-off-by: Sinan Kaya --- arch/x86/kernel/acpi/boot.c | 1 - drivers/acpi/pci_link.c | 9 - include/linux/acpi.h| 1 - 3 files changed, 11 deletions(-) diff --git

[PATCH V2 2/3] acpi,pci,irq: remove redundant code in acpi_irq_penalty_init

acpi_irq_get_penalty is now calculating the penalty on the fly now. No need to maintain global list of penalties or calculate them at the init time. Removing duplicate code in acpi_irq_penalty_init. Signed-off-by: Sinan Kaya --- arch/x86/pci/acpi.c | 1 - drivers/acpi/pci_link.c |

RE: [PATCH -v2] drivers: net: ethernet: intel: e1000e: fix ethtool autoneg off for non-copper

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Daniel Walker > Sent: Tuesday, April 5, 2016 11:30 AM > To: Ruinskiy, Dima ; Kirsher, Jeffrey T > ; Brandeburg, Jesse > ;

RE: [PATCH -v2] drivers: net: ethernet: intel: e1000e: fix ethtool autoneg off for non-copper

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Daniel Walker > Sent: Tuesday, April 5, 2016 11:30 AM > To: Ruinskiy, Dima ; Kirsher, Jeffrey T > ; Brandeburg, Jesse > ; Nelson, Shannon > ; Wyborny, Carolyn > ; Skidmore, Donald C > ; Allan, Bruce W ; >

Re: [RFC][PATCH] MAINTAINERS: Add Android Ion as a separate entry

On Fri, Apr 08, 2016 at 04:35:25PM -0700, Laura Abbott wrote: > The android drivers have a few other people reviewing patches. > Add a separate entry to ensure patches go to the right people. > > Signed-off-by: Laura Abbott > --- > Sumit and I have been doing review anyway so

Re: [RFC][PATCH] MAINTAINERS: Add Android Ion as a separate entry

On Fri, Apr 08, 2016 at 04:35:25PM -0700, Laura Abbott wrote: > The android drivers have a few other people reviewing patches. > Add a separate entry to ensure patches go to the right people. > > Signed-off-by: Laura Abbott > --- > Sumit and I have been doing review anyway so I think it makes

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

On Tue, Mar 29, 2016 at 10:41 AM, Luis R. Rodriguez wrote: > We need to ensure amd iommu v2 initializes before > driver uses such as drivers/gpu/drm/amd/amdkfd/kfd_module.c, > to do this make its init routine a subsys_initcall() which > ensures its load init is called first

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

On Tue, Mar 29, 2016 at 10:41 AM, Luis R. Rodriguez wrote: > We need to ensure amd iommu v2 initializes before > driver uses such as drivers/gpu/drm/amd/amdkfd/kfd_module.c, > to do this make its init routine a subsys_initcall() which > ensures its load init is called first than modules when >

[PATCH v1 0/2] x86/init: extend quirk use

...@kernel.org [2] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160408-pv-disabled-v5 Luis R. Rodriguez (2): x86/init: disable pnpbios for X86_SUBARCH_INTEL_MID x86/init: disable pnpbios for X86_SUBARCH_CE4100 arch/x86/kernel/platform-quirks.c | 5 +++-- 1 file

[PATCH v1 0/2] x86/init: extend quirk use

...@kernel.org [2] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160408-pv-disabled-v5 Luis R. Rodriguez (2): x86/init: disable pnpbios for X86_SUBARCH_INTEL_MID x86/init: disable pnpbios for X86_SUBARCH_CE4100 arch/x86/kernel/platform-quirks.c | 5 +++-- 1 file

[PATCH v1 1/2] x86/init: disable pnpbios for X86_SUBARCH_INTEL_MID

As per hpa Intel MID platforms can also disable pnpbios [0]. [0] http://lkml.kernel.org/r/5702b5c2.7070...@zytor.com Suggested-by: H. Peter Anvin Signed-off-by: Luis R. Rodriguez --- arch/x86/kernel/platform-quirks.c | 4 +--- 1 file changed, 1 insertion(+),

[PATCH v1 2/2] x86/init: disable pnpbios for X86_SUBARCH_CE4100

As per hpa CE4100 platforms can also disable pnpbios [0]. [0] http://lkml.kernel.org/r/5702b5c2.7070...@zytor.com Suggested-by: H. Peter Anvin Signed-off-by: Luis R. Rodriguez --- arch/x86/kernel/platform-quirks.c | 3 +++ 1 file changed, 3 insertions(+)

[PATCH v1 1/2] x86/init: disable pnpbios for X86_SUBARCH_INTEL_MID

As per hpa Intel MID platforms can also disable pnpbios [0]. [0] http://lkml.kernel.org/r/5702b5c2.7070...@zytor.com Suggested-by: H. Peter Anvin Signed-off-by: Luis R. Rodriguez --- arch/x86/kernel/platform-quirks.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[PATCH v1 2/2] x86/init: disable pnpbios for X86_SUBARCH_CE4100

As per hpa CE4100 platforms can also disable pnpbios [0]. [0] http://lkml.kernel.org/r/5702b5c2.7070...@zytor.com Suggested-by: H. Peter Anvin Signed-off-by: Luis R. Rodriguez --- arch/x86/kernel/platform-quirks.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [PATCH v5 00/14] x86: remove paravirt_enabled()

BTW also here's a tree if someone needs it: https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160408-pv-disabled-v5 Luis

Re: [PATCH v5 00/14] x86: remove paravirt_enabled()

BTW also here's a tree if someone needs it: https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160408-pv-disabled-v5 Luis

[PATCH v5 10/14] x86/cpu/intel: remove not needed paravirt_enabled() for f00f work around

The X86_BUG_F00F work around is responsible for fixing up the error generated on attempted F00F exploitation from an OOPS to a SIGILL. There is no reason why this code should not be allowed to run on PV guest on a F00F-affected CPU -- it would simply never trigger. The pv_enabled() check was there

[PATCH v5 14/14] x86/paravirt: remove paravirt_enabled()

That that paravirt_enabled() is replaced with proper x86 semantics we can remove it. Signed-off-by: Luis R. Rodriguez --- arch/x86/include/asm/paravirt.h | 5 - arch/x86/include/asm/paravirt_types.h | 1 - arch/x86/include/asm/processor.h | 1 -

[PATCH v5 09/14] x86/tboot: remove paravirt_enabled()

There is already a check for boot_params.tboot_addr prior to paravirt_enabled(). Both Xen and lguest, which are also the only ones that set paravirt_enabled to true, never set the boot_params.tboot_addr. The Xen folks are sure a force disable to 0 is not needed, we recently forced disabled this on

[PATCH v5 10/14] x86/cpu/intel: remove not needed paravirt_enabled() for f00f work around

The X86_BUG_F00F work around is responsible for fixing up the error generated on attempted F00F exploitation from an OOPS to a SIGILL. There is no reason why this code should not be allowed to run on PV guest on a F00F-affected CPU -- it would simply never trigger. The pv_enabled() check was there

[PATCH v5 14/14] x86/paravirt: remove paravirt_enabled()

That that paravirt_enabled() is replaced with proper x86 semantics we can remove it. Signed-off-by: Luis R. Rodriguez --- arch/x86/include/asm/paravirt.h | 5 - arch/x86/include/asm/paravirt_types.h | 1 - arch/x86/include/asm/processor.h | 1 - arch/x86/kernel/kvm.c

[PATCH v5 09/14] x86/tboot: remove paravirt_enabled()

There is already a check for boot_params.tboot_addr prior to paravirt_enabled(). Both Xen and lguest, which are also the only ones that set paravirt_enabled to true, never set the boot_params.tboot_addr. The Xen folks are sure a force disable to 0 is not needed, we recently forced disabled this on

[PATCH v5 07/14] tools/lguest: force disable tboot and apm

The paravirt_enabled() check is going away, the area tossed to the kernel on lguest is not zerored out, so ensure lguest force disables tboot and apm just in case the kernel file being read might have this set for whatever reason. Signed-off-by: Luis R. Rodriguez ---

[PATCH v5 05/14] x86, ACPI: move ACPI_FADT_NO_CMOS_RTC check to ACPI boot code

This moves the ACPI specific check into the ACPI boot code, it also takes advantage of the x86_platform.legacy.rtc which is checked for already on the RTC initialization code. This lets us remove the nasty #ifdefery and consolidate the checks to use only one toggle to disable the RTC init code.

[PATCH v5 07/14] tools/lguest: force disable tboot and apm

The paravirt_enabled() check is going away, the area tossed to the kernel on lguest is not zerored out, so ensure lguest force disables tboot and apm just in case the kernel file being read might have this set for whatever reason. Signed-off-by: Luis R. Rodriguez --- tools/lguest/lguest.c | 6

[PATCH v5 05/14] x86, ACPI: move ACPI_FADT_NO_CMOS_RTC check to ACPI boot code

This moves the ACPI specific check into the ACPI boot code, it also takes advantage of the x86_platform.legacy.rtc which is checked for already on the RTC initialization code. This lets us remove the nasty #ifdefery and consolidate the checks to use only one toggle to disable the RTC init code.

[PATCH v5 02/14] x86/xen: use X86_SUBARCH_XEN for PV guest boots

The use of subarch should have no current effect on Xen PV guests, as such this should have no current functional effects. Reviewed-by: David Vrabel Signed-off-by: Luis R. Rodriguez --- arch/x86/xen/enlighten.c | 1 + 1 file changed, 1 insertion(+)

[PATCH v5 02/14] x86/xen: use X86_SUBARCH_XEN for PV guest boots

The use of subarch should have no current effect on Xen PV guests, as such this should have no current functional effects. Reviewed-by: David Vrabel Signed-off-by: Luis R. Rodriguez --- arch/x86/xen/enlighten.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/xen/enlighten.c

[PATCH v5 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

We have 4 types of x86 platforms that disable RTC: * Intel MID * Lguest - uses paravirt * Xen dom-U - uses paravirt * x86 on legacy systems annotated with an ACPI legacy flag We can consolidate all of these into a platform specific legacy quirk set early in boot through

[PATCH v5 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

We have 4 types of x86 platforms that disable RTC: * Intel MID * Lguest - uses paravirt * Xen dom-U - uses paravirt * x86 on legacy systems annotated with an ACPI legacy flag We can consolidate all of these into a platform specific legacy quirk set early in boot through

Re: [PATCH v2] x86: Calculate MHz using APERF/MPERF for cpuinfo and scaling_cur_freq

> I have a minor ABI concern with this patch. It seems that there is much more > variance in the output of "cpu MHz" with this patch, and I think that > needs to be noted in the changelog. > > ISTR having a conversation a while ago (with you Len? with Srinivas?) > where I mentioned that "cpu

Re: [PATCH v2] x86: Calculate MHz using APERF/MPERF for cpuinfo and scaling_cur_freq

> I have a minor ABI concern with this patch. It seems that there is much more > variance in the output of "cpu MHz" with this patch, and I think that > needs to be noted in the changelog. > > ISTR having a conversation a while ago (with you Len? with Srinivas?) > where I mentioned that "cpu

Re: [PATCH v1 06/10] device property: switch to use UUID API

On Fri, Apr 8, 2016 at 6:00 PM, Andy Shevchenko wrote: > On Fri, 2016-04-08 at 09:27 +0800, Huang, Ying wrote: >> Andy Shevchenko writes: >> >> > >> > On Fri, 2016-02-26 at 16:11 +0200, Andy Shevchenko wrote: >> > > >> > > On

Re: [PATCH v1 06/10] device property: switch to use UUID API

On Fri, Apr 8, 2016 at 6:00 PM, Andy Shevchenko wrote: > On Fri, 2016-04-08 at 09:27 +0800, Huang, Ying wrote: >> Andy Shevchenko writes: >> >> > >> > On Fri, 2016-02-26 at 16:11 +0200, Andy Shevchenko wrote: >> > > >> > > On Thu, 2016-02-18 at 01:03 +0100, Rafael J. Wysocki wrote: >> > > > >> >

[PATCH v5 00/14] x86: remove paravirt_enabled()

This v5 updates the subarch documentation to annotate that X86_SUBARCH_XEN can be use for both Xen dom0 and domU, and adds an optional x86_platform.set_legacy_features() in order to deal with further platform legacy fine tunings when the platform requires further semantics than what is currently

[PATCH v5 11/14] pnpbios: replace paravirt_enabled() check with legacy device check

Since we are removing paravirt_enabled() replace it with a logical equivalent. Even though PNPBIOS is x86 specific we add an arch-specific type call, which can be implemented by any architecture to show how other legacy attribute devices can later be also checked for with other ACPI legacy

[PATCH v5 09/14] x86/tboot: remove paravirt_enabled()

There is already a check for boot_params.tboot_addr prior to paravirt_enabled(). Both Xen and lguest, which are also the only ones that set paravirt_enabled to true, never set the boot_params.tboot_addr. The Xen folks are sure a force disable to 0 is not needed, we recently forced disabled this on

[PATCH v5 05/14] x86, ACPI: move ACPI_FADT_NO_CMOS_RTC check to ACPI boot code

This moves the ACPI specific check into the ACPI boot code, it also takes advantage of the x86_platform.legacy.rtc which is checked for already on the RTC initialization code. This lets us remove the nasty #ifdefery and consolidate the checks to use only one toggle to disable the RTC init code.

[PATCH v5 03/14] tools/lguest: make lguest launcher use X86_SUBARCH_LGUEST explicitly

Be explicit and make use of X86_SUBARCH_LGUEST directly. Signed-off-by: Luis R. Rodriguez --- tools/lguest/lguest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c index 80159e6811c2..ff0aa580c6e1 100644

[PATCH v5 06/14] x86/init: use a platform legacy quirk for ebda

This replaces the paravirt_enabled() check with a proper x86 legacy platform quirk. As per 0-day, this bumps the vmlinux size using i386-tinyconfig as follows: TOTAL TEXT init.text x86_early_init_platform_quirks() +39 +35+35 +25 That's a 4 byte total overhead, the rest is

[PATCH v5 10/14] x86/cpu/intel: remove not needed paravirt_enabled() for f00f work around

The X86_BUG_F00F work around is responsible for fixing up the error generated on attempted F00F exploitation from an OOPS to a SIGILL. There is no reason why this code should not be allowed to run on PV guest on a F00F-affected CPU -- it would simply never trigger. The pv_enabled() check was there

[PATCH v5 07/14] tools/lguest: force disable tboot and apm

The paravirt_enabled() check is going away, the area tossed to the kernel on lguest is not zerored out, so ensure lguest force disables tboot and apm just in case the kernel file being read might have this set for whatever reason. Signed-off-by: Luis R. Rodriguez ---

[PATCH v5 00/14] x86: remove paravirt_enabled()

This v5 updates the subarch documentation to annotate that X86_SUBARCH_XEN can be use for both Xen dom0 and domU, and adds an optional x86_platform.set_legacy_features() in order to deal with further platform legacy fine tunings when the platform requires further semantics than what is currently

[PATCH v5 11/14] pnpbios: replace paravirt_enabled() check with legacy device check

Since we are removing paravirt_enabled() replace it with a logical equivalent. Even though PNPBIOS is x86 specific we add an arch-specific type call, which can be implemented by any architecture to show how other legacy attribute devices can later be also checked for with other ACPI legacy

[PATCH v5 09/14] x86/tboot: remove paravirt_enabled()

There is already a check for boot_params.tboot_addr prior to paravirt_enabled(). Both Xen and lguest, which are also the only ones that set paravirt_enabled to true, never set the boot_params.tboot_addr. The Xen folks are sure a force disable to 0 is not needed, we recently forced disabled this on

[PATCH v5 05/14] x86, ACPI: move ACPI_FADT_NO_CMOS_RTC check to ACPI boot code

This moves the ACPI specific check into the ACPI boot code, it also takes advantage of the x86_platform.legacy.rtc which is checked for already on the RTC initialization code. This lets us remove the nasty #ifdefery and consolidate the checks to use only one toggle to disable the RTC init code.

[PATCH v5 03/14] tools/lguest: make lguest launcher use X86_SUBARCH_LGUEST explicitly

Be explicit and make use of X86_SUBARCH_LGUEST directly. Signed-off-by: Luis R. Rodriguez --- tools/lguest/lguest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c index 80159e6811c2..ff0aa580c6e1 100644 ---

[PATCH v5 06/14] x86/init: use a platform legacy quirk for ebda

This replaces the paravirt_enabled() check with a proper x86 legacy platform quirk. As per 0-day, this bumps the vmlinux size using i386-tinyconfig as follows: TOTAL TEXT init.text x86_early_init_platform_quirks() +39 +35+35 +25 That's a 4 byte total overhead, the rest is

[PATCH v5 10/14] x86/cpu/intel: remove not needed paravirt_enabled() for f00f work around

The X86_BUG_F00F work around is responsible for fixing up the error generated on attempted F00F exploitation from an OOPS to a SIGILL. There is no reason why this code should not be allowed to run on PV guest on a F00F-affected CPU -- it would simply never trigger. The pv_enabled() check was there

[PATCH v5 07/14] tools/lguest: force disable tboot and apm

The paravirt_enabled() check is going away, the area tossed to the kernel on lguest is not zerored out, so ensure lguest force disables tboot and apm just in case the kernel file being read might have this set for whatever reason. Signed-off-by: Luis R. Rodriguez --- tools/lguest/lguest.c | 6

Re: [PATCH] mtd: nand: nuc900: allow compiling with COMPILE_TEST

Hi Rafał, [auto build test WARNING on mtd/master] [also build test WARNING on v4.6-rc2 next-20160408] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/mtd-nand-nuc900-allow

[PATCH v5 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch

Although hardware_subarch has been in place since the x86 boot protocol 2.07 it hasn't been used much. Enumerate current possible values to avoid misuses and help with semantics later at boot time should this be used further. These enums should only ever be used by architecture x86 code, and all

[PATCH v5 08/14] apm32: remove paravirt_enabled() use

There is already a check for apm_info.bios == 0, the apm_info.bios is set from the boot_params.apm_bios_info. Both Xen and lguest, which are also the only ones that set paravirt_enabled to true, never set the apm_bios.info. The Xen folks are sure force disable to 0 is not needed because apm_info

[PATCH v5 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch

Although hardware_subarch has been in place since the x86 boot protocol 2.07 it hasn't been used much. Enumerate current possible values to avoid misuses and help with semantics later at boot time should this be used further. These enums should only ever be used by architecture x86 code, and all

[PATCH v5 08/14] apm32: remove paravirt_enabled() use

There is already a check for apm_info.bios == 0, the apm_info.bios is set from the boot_params.apm_bios_info. Both Xen and lguest, which are also the only ones that set paravirt_enabled to true, never set the apm_bios.info. The Xen folks are sure force disable to 0 is not needed because apm_info

Re: [PATCH] mtd: nand: nuc900: allow compiling with COMPILE_TEST

Hi Rafał, [auto build test WARNING on mtd/master] [also build test WARNING on v4.6-rc2 next-20160408] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/mtd-nand-nuc900-allow

[PATCH v5 13/14] x86/init: rename ebda code file

This makes it clearer what this is. Signed-off-by: Luis R. Rodriguez --- arch/x86/Makefile | 2 +- arch/x86/kernel/Makefile | 2 +- arch/x86/kernel/{head.c => ebda.c} | 0 3 files changed, 2 insertions(+), 2 deletions(-) rename

[PATCH v5 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

We have 4 types of x86 platforms that disable RTC: * Intel MID * Lguest - uses paravirt * Xen dom-U - uses paravirt * x86 on legacy systems annotated with an ACPI legacy flag We can consolidate all of these into a platform specific legacy quirk set early in boot through

[PATCH v5 02/14] x86/xen: use X86_SUBARCH_XEN for PV guest boots

The use of subarch should have no current effect on Xen PV guests, as such this should have no current functional effects. Reviewed-by: David Vrabel Signed-off-by: Luis R. Rodriguez --- arch/x86/xen/enlighten.c | 1 + 1 file changed, 1 insertion(+)

[PATCH v5 12/14] x86, ACPI: parse ACPI_FADT_LEGACY_DEVICES

ACPI 5.2.9.3 IA-PC Boot Architecture flag ACPI_FADT_LEGACY_DEVICES can be used to determine if a system has legacy devices LPC or ISA devices. The x86 platform already has a struct which lists known associated legacy devices, we start off careful only by disabling root devices we should not

[PATCH v5 13/14] x86/init: rename ebda code file

This makes it clearer what this is. Signed-off-by: Luis R. Rodriguez --- arch/x86/Makefile | 2 +- arch/x86/kernel/Makefile | 2 +- arch/x86/kernel/{head.c => ebda.c} | 0 3 files changed, 2 insertions(+), 2 deletions(-) rename arch/x86/kernel/{head.c => ebda.c}

[PATCH v5 02/14] x86/xen: use X86_SUBARCH_XEN for PV guest boots

The use of subarch should have no current effect on Xen PV guests, as such this should have no current functional effects. Reviewed-by: David Vrabel Signed-off-by: Luis R. Rodriguez --- arch/x86/xen/enlighten.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/xen/enlighten.c

[PATCH v5 12/14] x86, ACPI: parse ACPI_FADT_LEGACY_DEVICES

ACPI 5.2.9.3 IA-PC Boot Architecture flag ACPI_FADT_LEGACY_DEVICES can be used to determine if a system has legacy devices LPC or ISA devices. The x86 platform already has a struct which lists known associated legacy devices, we start off careful only by disabling root devices we should not

[PATCH v5 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

We have 4 types of x86 platforms that disable RTC: * Intel MID * Lguest - uses paravirt * Xen dom-U - uses paravirt * x86 on legacy systems annotated with an ACPI legacy flag We can consolidate all of these into a platform specific legacy quirk set early in boot through

[PATCH v5 14/14] x86/paravirt: remove paravirt_enabled()

That that paravirt_enabled() is replaced with proper x86 semantics we can remove it. Signed-off-by: Luis R. Rodriguez --- arch/x86/include/asm/paravirt.h | 5 - arch/x86/include/asm/paravirt_types.h | 1 - arch/x86/include/asm/processor.h | 1 -

[PATCH v5 14/14] x86/paravirt: remove paravirt_enabled()

That that paravirt_enabled() is replaced with proper x86 semantics we can remove it. Signed-off-by: Luis R. Rodriguez --- arch/x86/include/asm/paravirt.h | 5 - arch/x86/include/asm/paravirt_types.h | 1 - arch/x86/include/asm/processor.h | 1 - arch/x86/kernel/kvm.c

  1   2   3   4   5   6   7   8   9   10   >