Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

On 1 July 2016 at 17:00, Mark Brown wrote: > On Fri, Jul 01, 2016 at 10:58:34AM +0200, Michal Suchanek wrote: >> On 1 July 2016 at 10:25, Mark Brown wrote: > >> > It's been repeatedly suggested to you that the tooling for this stuff >> > could use some

[PATCH 01/31] mm, vmstat: add infrastructure for per-node vmstats

Series: "Move LRU page reclaim from zones to nodes v7" This is the latest version of a series that moves LRUs from the zones to the node that is based upon 4.6-rc3 plus the page allocator optimisation series. Conceptually, this is simple but there are a lot of details. Some of the broad

[PATCH 04/31] mm, vmscan: begin reclaiming pages on a per-node basis

This patch makes reclaim decisions on a per-node basis. A reclaimer knows what zone is required by the allocation request and skips pages from higher zones. In many cases this will be ok because it's a GFP_HIGHMEM request of some description. On 64-bit, ZONE_DMA32 requests will cause some

Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

On 1 July 2016 at 17:00, Mark Brown wrote: > On Fri, Jul 01, 2016 at 10:58:34AM +0200, Michal Suchanek wrote: >> On 1 July 2016 at 10:25, Mark Brown wrote: > >> > It's been repeatedly suggested to you that the tooling for this stuff >> > could use some work. Please go and put some effort into

[PATCH 11/31] mm: vmscan: do not reclaim from kswapd if there is any eligible zone

kswapd scans from highest to lowest for a zone that requires balancing. This was necessary when reclaim was per-zone to fairly age pages on lower zones. Now that we are reclaiming on a per-node basis, any eligible zone can be used and pages will still be aged fairly. This patch avoids reclaiming

[PATCH 06/31] mm, vmscan: make kswapd reclaim in terms of nodes

Patch "mm: vmscan: Begin reclaiming pages on a per-node basis" started thinking of reclaim in terms of nodes but kswapd is still zone-centric. This patch gets rid of many of the node-based versus zone-based decisions. o A node is considered balanced when any eligible lower zone is balanced.

[PATCH 11/31] mm: vmscan: do not reclaim from kswapd if there is any eligible zone

kswapd scans from highest to lowest for a zone that requires balancing. This was necessary when reclaim was per-zone to fairly age pages on lower zones. Now that we are reclaiming on a per-node basis, any eligible zone can be used and pages will still be aged fairly. This patch avoids reclaiming

[PATCH 06/31] mm, vmscan: make kswapd reclaim in terms of nodes

Patch "mm: vmscan: Begin reclaiming pages on a per-node basis" started thinking of reclaim in terms of nodes but kswapd is still zone-centric. This patch gets rid of many of the node-based versus zone-based decisions. o A node is considered balanced when any eligible lower zone is balanced.

[PATCH 12/31] mm, vmscan: make shrink_node decisions more node-centric

Earlier patches focused on having direct reclaim and kswapd use data that is node-centric for reclaiming but shrink_node() itself still uses too much zone information. This patch removes unnecessary zone-based information with the most important decision being whether to continue reclaim or not.

[PATCH 07/31] mm, vmscan: remove balance gap

The balance gap was introduced to apply equal pressure to all zones when reclaiming for a higher zone. With node-based LRU, the need for the balance gap is removed and the code is dead so remove it. [vba...@suse.cz: Also remove KSWAPD_ZONE_BALANCE_GAP_RATIO] Link:

[PATCH 09/31] mm, vmscan: by default have direct reclaim only shrink once per node

Direct reclaim iterates over all zones in the zonelist and shrinking them but this is in conflict with node-based reclaim. In the default case, only shrink once per node. Link: http://lkml.kernel.org/r/1466518566-30034-10-git-send-email-mgor...@techsingularity.net Signed-off-by: Mel Gorman

[PATCH 12/31] mm, vmscan: make shrink_node decisions more node-centric

Earlier patches focused on having direct reclaim and kswapd use data that is node-centric for reclaiming but shrink_node() itself still uses too much zone information. This patch removes unnecessary zone-based information with the most important decision being whether to continue reclaim or not.

[PATCH 07/31] mm, vmscan: remove balance gap

The balance gap was introduced to apply equal pressure to all zones when reclaiming for a higher zone. With node-based LRU, the need for the balance gap is removed and the code is dead so remove it. [vba...@suse.cz: Also remove KSWAPD_ZONE_BALANCE_GAP_RATIO] Link:

[PATCH 09/31] mm, vmscan: by default have direct reclaim only shrink once per node

Direct reclaim iterates over all zones in the zonelist and shrinking them but this is in conflict with node-based reclaim. In the default case, only shrink once per node. Link: http://lkml.kernel.org/r/1466518566-30034-10-git-send-email-mgor...@techsingularity.net Signed-off-by: Mel Gorman

[PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps

kswapd goes through some complex steps trying to figure out if it should stay awake based on the classzone_idx and the requested order. It is unnecessarily complex and passes in an invalid classzone_idx to balance_pgdat(). What matters most of all is whether a larger order has been requsted and

[PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps

kswapd goes through some complex steps trying to figure out if it should stay awake based on the classzone_idx and the requested order. It is unnecessarily complex and passes in an invalid classzone_idx to balance_pgdat(). What matters most of all is whether a larger order has been requsted and

[PATCH 05/31] mm, vmscan: have kswapd only scan based on the highest requested zone

kswapd checks all eligible zones to see if they need balancing even if it was woken for a lower zone. This made sense when we reclaimed on a per-zone basis because we wanted to shrink zones fairly so avoid age-inversion problems. Ideally this is completely unnecessary when reclaiming on a

[PATCH 02/31] mm, vmscan: move lru_lock to the node

Node-based reclaim requires node-based LRUs and locking. This is a preparation patch that just moves the lru_lock to the node so later patches are easier to review. It is a mechanical change but note this patch makes contention worse because the LRU lock is hotter and direct reclaim and kswapd

[PATCH 10/31] mm, vmscan: remove duplicate logic clearing node congestion and dirty state

Reclaim may stall if there is too much dirty or congested data on a node. This was previously based on zone flags and the logic for clearing the flags is in two places. As congestion/dirty tracking is now tracked on a per-node basis, we can remove some duplicate logic. Link:

[PATCH 05/31] mm, vmscan: have kswapd only scan based on the highest requested zone

kswapd checks all eligible zones to see if they need balancing even if it was woken for a lower zone. This made sense when we reclaimed on a per-zone basis because we wanted to shrink zones fairly so avoid age-inversion problems. Ideally this is completely unnecessary when reclaiming on a

[PATCH 02/31] mm, vmscan: move lru_lock to the node

Node-based reclaim requires node-based LRUs and locking. This is a preparation patch that just moves the lru_lock to the node so later patches are easier to review. It is a mechanical change but note this patch makes contention worse because the LRU lock is hotter and direct reclaim and kswapd

[PATCH 10/31] mm, vmscan: remove duplicate logic clearing node congestion and dirty state

Reclaim may stall if there is too much dirty or congested data on a node. This was previously based on zone flags and the logic for clearing the flags is in two places. As congestion/dirty tracking is now tracked on a per-node basis, we can remove some duplicate logic. Link:

[PATCH 00/31] Move LRU page reclaim from zones to nodes v8

Previous releases double accounted LRU stats on the zone and the node because it was required by should_reclaim_retry. The last patch in the series removes the double accounting. It's not integrated with the series as reviewers may not like the solution. If not, it can be safely dropped without a

[git pull] IOMMU Fixes for Linux v4.7-rc5

Hi Linus, The following changes since commit a4c34ff1c029e90e7d5f8dd8d29b0a93b31c3cb2: iommu/vt-d: Enable QI on all IOMMUs before setting root entry (2016-06-17 11:29:48 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git

[PATCH 00/31] Move LRU page reclaim from zones to nodes v8

Previous releases double accounted LRU stats on the zone and the node because it was required by should_reclaim_retry. The last patch in the series removes the double accounting. It's not integrated with the series as reviewers may not like the solution. If not, it can be safely dropped without a

[git pull] IOMMU Fixes for Linux v4.7-rc5

Hi Linus, The following changes since commit a4c34ff1c029e90e7d5f8dd8d29b0a93b31c3cb2: iommu/vt-d: Enable QI on all IOMMUs before setting root entry (2016-06-17 11:29:48 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git

Re: [PATCH v1 03/11] KVM: x86: dynamic kvm_apic_map

2016-07-01 17:06+0200, Paolo Bonzini: > On 01/07/2016 16:38, Radim Krčmář wrote: > On the > other hand, I suspect you need to bump KVM_MAX_VCPU_ID beyond its > current default setting (which is equal to KVM_MAX_VCPUS), up to 511 or

Re: [PATCH] [media] cec: add missing inline stubs

On Friday, July 1, 2016 5:22:32 PM CEST Hans Verkuil wrote: > > diff --git a/drivers/media/platform/vivid/Kconfig > > b/drivers/media/platform/vivid/Kconfig > > index 8e6918c5c87c..8e31146d079a 100644 > > --- a/drivers/media/platform/vivid/Kconfig > > +++ b/drivers/media/platform/vivid/Kconfig >

Re: [PATCH v1 03/11] KVM: x86: dynamic kvm_apic_map

2016-07-01 17:06+0200, Paolo Bonzini: > On 01/07/2016 16:38, Radim Krčmář wrote: > On the > other hand, I suspect you need to bump KVM_MAX_VCPU_ID beyond its > current default setting (which is equal to KVM_MAX_VCPUS), up to 511 or

Re: [PATCH] [media] cec: add missing inline stubs

On Friday, July 1, 2016 5:22:32 PM CEST Hans Verkuil wrote: > > diff --git a/drivers/media/platform/vivid/Kconfig > > b/drivers/media/platform/vivid/Kconfig > > index 8e6918c5c87c..8e31146d079a 100644 > > --- a/drivers/media/platform/vivid/Kconfig > > +++ b/drivers/media/platform/vivid/Kconfig >

Re: [PATCH 6/6] x86: Fix stray A/D bit setting into non-present PTEs

Linus Torvalds writes: > On Thu, Jun 30, 2016 at 9:39 PM, Dave Hansen wrote: >> >> I think what you suggest will work if we don't consider A/D in >> pte_none(). I think there are a bunch of code path where assume that >> !pte_present() &&

Re: [PATCH 6/6] x86: Fix stray A/D bit setting into non-present PTEs

Linus Torvalds writes: > On Thu, Jun 30, 2016 at 9:39 PM, Dave Hansen wrote: >> >> I think what you suggest will work if we don't consider A/D in >> pte_none(). I think there are a bunch of code path where assume that >> !pte_present() && !pte_none() means swap. > > Yeah, we would need to

Re: [PATCH v3 1/4] drm/rockchip: vop: export line flag function

On Fri, Jul 1, 2016 at 5:19 AM, Yakir Yang wrote: > VOP have integrated a hardware counter which indicate the exact display > line that vop is scanning. And if we're interested in a specific line, > we can set the line number to vop line_flag register, and then vop would >

Re: [PATCH v3 1/4] drm/rockchip: vop: export line flag function

On Fri, Jul 1, 2016 at 5:19 AM, Yakir Yang wrote: > VOP have integrated a hardware counter which indicate the exact display > line that vop is scanning. And if we're interested in a specific line, > we can set the line number to vop line_flag register, and then vop would > generate a line_flag

RE: [RFC PATCH 0/2] net: ethernet: Add support for gmii2rgmii converter

Hi Andrew, > On Fri, Jul 01, 2016 at 11:50:10AM +0530, Kedareswara rao Appana wrote: > > This patch series does the following > > ---> Add support for gmii2rgmii converter. > > How generic is this gmii2rgmii IP block? Could it be used with any GMII and > RGMII device? This converter does

RE: [RFC PATCH 0/2] net: ethernet: Add support for gmii2rgmii converter

Hi Andrew, > On Fri, Jul 01, 2016 at 11:50:10AM +0530, Kedareswara rao Appana wrote: > > This patch series does the following > > ---> Add support for gmii2rgmii converter. > > How generic is this gmii2rgmii IP block? Could it be used with any GMII and > RGMII device? This converter does

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote: > On 2016/6/30 21:27, Rafael J. Wysocki wrote: > >On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote: > >>GTDT is part of ACPI spec, drivers/acpi/ is for driver code of > >>ACPI spec, I think it can stay in drivers/acpi/ from this

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote: > On 2016/6/30 21:27, Rafael J. Wysocki wrote: > >On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote: > >>GTDT is part of ACPI spec, drivers/acpi/ is for driver code of > >>ACPI spec, I think it can stay in drivers/acpi/ from this

Re: [PATCH] [media] cec: add missing inline stubs

On 07/01/2016 05:13 PM, Arnd Bergmann wrote: > On Friday, July 1, 2016 4:35:09 PM CEST Hans Verkuil wrote: >> On 07/01/2016 01:19 PM, Arnd Bergmann wrote: >>> The linux/cec.h header file contains empty inline definitions for >>> a subset of the API for the case in which CEC is not enabled, >>>

Re: [PATCH] [media] cec: add missing inline stubs

On 07/01/2016 05:13 PM, Arnd Bergmann wrote: > On Friday, July 1, 2016 4:35:09 PM CEST Hans Verkuil wrote: >> On 07/01/2016 01:19 PM, Arnd Bergmann wrote: >>> The linux/cec.h header file contains empty inline definitions for >>> a subset of the API for the case in which CEC is not enabled, >>>

RE: [RFC PATCH 1/2] net: ethernet: xilinx: Add gmii2rgmii converter support

Hi Florian, Thanks for the review. > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +static void xgmii2rgmii_fix_mac_speed(void *priv, unsigned int speed) > > +{ > > + struct gmii2rgmii

RE: [RFC PATCH 0/2] net: ethernet: Add support for gmii2rgmii converter

Hi Florian, Thanks for the review... > Le 30/06/2016 23:20, Kedareswara rao Appana a écrit : > > This patch series does the following > > ---> Add support for gmii2rgmii converter. > > ---> Add support for gmii2rgmii converter in the macb driver. > > > > Earlier sent one RFC patch

RE: [RFC PATCH 1/2] net: ethernet: xilinx: Add gmii2rgmii converter support

Hi Florian, Thanks for the review. > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +static void xgmii2rgmii_fix_mac_speed(void *priv, unsigned int speed) > > +{ > > + struct gmii2rgmii

RE: [RFC PATCH 0/2] net: ethernet: Add support for gmii2rgmii converter

Hi Florian, Thanks for the review... > Le 30/06/2016 23:20, Kedareswara rao Appana a écrit : > > This patch series does the following > > ---> Add support for gmii2rgmii converter. > > ---> Add support for gmii2rgmii converter in the macb driver. > > > > Earlier sent one RFC patch

Re: [PATCH v4] vmlinux.lds: account for destructor sections

On Fri, Jul 1, 2016 at 5:19 PM, Dmitry Vyukov wrote: > If CONFIG_KASAN is enabled and gcc is configured with > --disable-initfini-array and/or gold linker is used, > gcc emits .ctors/.dtors and .text.startup/.text.exit > sections instead of .init_array/.fini_array. > .dtors

strange Mac OSX RST behavior

I'm wondering if anybody else has run into this... On Mac OSX 10.11.5 (latest version), we have found that when tcp connections are abruptly terminated (via ^C), a FIN is sent followed by an RST packet. The RST is sent with the same sequence number as the FIN, and thus dropped since the stack

Re: [PATCH v4] vmlinux.lds: account for destructor sections

On Fri, Jul 1, 2016 at 5:19 PM, Dmitry Vyukov wrote: > If CONFIG_KASAN is enabled and gcc is configured with > --disable-initfini-array and/or gold linker is used, > gcc emits .ctors/.dtors and .text.startup/.text.exit > sections instead of .init_array/.fini_array. > .dtors section is not

strange Mac OSX RST behavior

I'm wondering if anybody else has run into this... On Mac OSX 10.11.5 (latest version), we have found that when tcp connections are abruptly terminated (via ^C), a FIN is sent followed by an RST packet. The RST is sent with the same sequence number as the FIN, and thus dropped since the stack

Re: [PATCH v3] vmlinux.lds: account for destructor sections

On Fri, Jul 1, 2016 at 4:58 PM, Andrey Ryabinin wrote: > 2016-06-29 20:28 GMT+03:00 Dmitry Vyukov : >> On Fri, Jun 24, 2016 at 6:57 PM, Andrey Ryabinin >> wrote: >>> 2016-06-24 18:39 GMT+03:00 Dmitry Vyukov

[PATCH v4] vmlinux.lds: account for destructor sections

If CONFIG_KASAN is enabled and gcc is configured with --disable-initfini-array and/or gold linker is used, gcc emits .ctors/.dtors and .text.startup/.text.exit sections instead of .init_array/.fini_array. .dtors section is not explicitly accounted in the linker script and messes vvar/percpu

Re: [PATCH v3] vmlinux.lds: account for destructor sections

On Fri, Jul 1, 2016 at 4:58 PM, Andrey Ryabinin wrote: > 2016-06-29 20:28 GMT+03:00 Dmitry Vyukov : >> On Fri, Jun 24, 2016 at 6:57 PM, Andrey Ryabinin >> wrote: >>> 2016-06-24 18:39 GMT+03:00 Dmitry Vyukov : If CONFIG_KASAN is enabled and gcc is configured with

[PATCH v4] vmlinux.lds: account for destructor sections

If CONFIG_KASAN is enabled and gcc is configured with --disable-initfini-array and/or gold linker is used, gcc emits .ctors/.dtors and .text.startup/.text.exit sections instead of .init_array/.fini_array. .dtors section is not explicitly accounted in the linker script and messes vvar/percpu

Re: [PATCH] iio: dac: mcp4725: Remove unneeded conversions to bool

On 07/01/2016 10:03 AM, Peter Meerwald-Stadler wrote: > >> Found with scripts/coccinelle/misc/boolconv.cocci. > > I'd argue that > > pd = (inbuf[0] >> 1) & 0x3; > if (pd) { > data->powerdown = true; > data->powerdown_mode = pd - 1; > }

Re: [PATCH] iio: dac: mcp4725: Remove unneeded conversions to bool

On 07/01/2016 10:03 AM, Peter Meerwald-Stadler wrote: > >> Found with scripts/coccinelle/misc/boolconv.cocci. > > I'd argue that > > pd = (inbuf[0] >> 1) & 0x3; > if (pd) { > data->powerdown = true; > data->powerdown_mode = pd - 1; > }

Re: [PATCH 6/7] dt-bindings: net: bgmac: add bindings documentation for bgmac

On Fri, Jul 1, 2016 at 5:46 AM, Arnd Bergmann wrote: > On Thursday, June 30, 2016 6:59:13 PM CEST Jon Mason wrote: >> + >> +Required properties: >> + - compatible: "brcm,bgmac-nsp" >> + - reg:Address and length of the GMAC registers, >> + Address and

Re: [PATCH 6/7] dt-bindings: net: bgmac: add bindings documentation for bgmac

On Fri, Jul 1, 2016 at 5:46 AM, Arnd Bergmann wrote: > On Thursday, June 30, 2016 6:59:13 PM CEST Jon Mason wrote: >> + >> +Required properties: >> + - compatible: "brcm,bgmac-nsp" >> + - reg:Address and length of the GMAC registers, >> + Address and length of the

Re: [PATCH v1 03/11] KVM: x86: dynamic kvm_apic_map

On 01/07/2016 17:06, Paolo Bonzini wrote: >>> >> > Should it? >> Yes, x2APIC ID cannot be changed in hardware and is initialized to the >> intitial APIC ID. >> Letting LAPIC_SET change x2APIC ID would allow scenarios where userspace >> reuses old VMs instead of building new ones after

Re: [PATCH v1 03/11] KVM: x86: dynamic kvm_apic_map

On 01/07/2016 17:06, Paolo Bonzini wrote: >>> >> > Should it? >> Yes, x2APIC ID cannot be changed in hardware and is initialized to the >> intitial APIC ID. >> Letting LAPIC_SET change x2APIC ID would allow scenarios where userspace >> reuses old VMs instead of building new ones after

Re: [RFC PATCH 0/2] net: ethernet: Add support for gmii2rgmii converter

On Fri, Jul 01, 2016 at 11:50:10AM +0530, Kedareswara rao Appana wrote: > This patch series does the following > ---> Add support for gmii2rgmii converter. How generic is this gmii2rgmii IP block? Could it be used with any GMII and RGMII device? Should it be placed in drivers/net/phy, so making

Re: [RFC PATCH 0/2] net: ethernet: Add support for gmii2rgmii converter

On Fri, Jul 01, 2016 at 11:50:10AM +0530, Kedareswara rao Appana wrote: > This patch series does the following > ---> Add support for gmii2rgmii converter. How generic is this gmii2rgmii IP block? Could it be used with any GMII and RGMII device? Should it be placed in drivers/net/phy, so making

Re: [PATCH] [media] cec: add missing inline stubs

On Friday, July 1, 2016 4:35:09 PM CEST Hans Verkuil wrote: > On 07/01/2016 01:19 PM, Arnd Bergmann wrote: > > The linux/cec.h header file contains empty inline definitions for > > a subset of the API for the case in which CEC is not enabled, > > however we have driver that call other functions as

Re: [PATCH] [media] cec: add missing inline stubs

On Friday, July 1, 2016 4:35:09 PM CEST Hans Verkuil wrote: > On 07/01/2016 01:19 PM, Arnd Bergmann wrote: > > The linux/cec.h header file contains empty inline definitions for > > a subset of the API for the case in which CEC is not enabled, > > however we have driver that call other functions as

Re: [PATCH] arm64: defconfig: Enable QDF2432 config options

Christopher Covington wrote: Due to distribution differences [1][2], I see =y built-in as the default on mobile platforms and =m modular as the default on server platforms. I don't think we should mix "server" defconfing entries with "mobile" defconfig entries. It's a arm64 defconfig,

Re: [PATCH] arm64: defconfig: Enable QDF2432 config options

Christopher Covington wrote: Due to distribution differences [1][2], I see =y built-in as the default on mobile platforms and =m modular as the default on server platforms. I don't think we should mix "server" defconfing entries with "mobile" defconfig entries. It's a arm64 defconfig,

Re: [docs-next PATCH] Documentation/sphinx: skip build if user requested specific DOCBOOKS

Em Fri, 01 Jul 2016 16:31:14 +0300 Jani Nikula escreveu: > On Fri, 01 Jul 2016, Mauro Carvalho Chehab wrote: > > Em Fri, 1 Jul 2016 15:24:44 +0300 > > Jani Nikula escreveu: > > > >> If the user requested specific

Re: [docs-next PATCH] Documentation/sphinx: skip build if user requested specific DOCBOOKS

Em Fri, 01 Jul 2016 16:31:14 +0300 Jani Nikula escreveu: > On Fri, 01 Jul 2016, Mauro Carvalho Chehab wrote: > > Em Fri, 1 Jul 2016 15:24:44 +0300 > > Jani Nikula escreveu: > > > >> If the user requested specific DocBooks to be built using 'make > >> DOCBOOKS=foo.xml htmldocs', assume no

Re: [PATCH v1 06/11] KVM: x86: use hardware-compatible format for APIC ID register

On 01/07/2016 16:54, Radim Krčmář wrote: >> >(Hint: we >> > want kvm-unit-tests for this). > :) Something like this? > > enable_xapic() > id = apic_id() > set_apic_id(id+1) // ? > enable_x2apic() > id == apic_id() & 0xff

Re: [PATCH v1 06/11] KVM: x86: use hardware-compatible format for APIC ID register

On 01/07/2016 16:54, Radim Krčmář wrote: >> >(Hint: we >> > want kvm-unit-tests for this). > :) Something like this? > > enable_xapic() > id = apic_id() > set_apic_id(id+1) // ? > enable_x2apic() > id == apic_id() & 0xff

Re: [PATCH v1 03/11] KVM: x86: dynamic kvm_apic_map

On 01/07/2016 16:38, Radim Krčmář wrote: >> > Should it? > Yes, x2APIC ID cannot be changed in hardware and is initialized to the > intitial APIC ID. > Letting LAPIC_SET change x2APIC ID would allow scenarios where userspace > reuses old VMs instead of building new ones after reconfiguration. >

Re: [PATCH v1 03/11] KVM: x86: dynamic kvm_apic_map

On 01/07/2016 16:38, Radim Krčmář wrote: >> > Should it? > Yes, x2APIC ID cannot be changed in hardware and is initialized to the > intitial APIC ID. > Letting LAPIC_SET change x2APIC ID would allow scenarios where userspace > reuses old VMs instead of building new ones after reconfiguration. >

Re: [PATCH] arm64: defconfig: Enable QDF2432 config options

On 07/01/2016 10:14 AM, Timur Tabi wrote: > Christopher Covington wrote: >> arch/arm64/configs/defconfig | 4 >> scripts/patch-details.sh | 21 ++--- > > I don't think these two files should be combined. Oops, sorry. Fixed in v2. >> CONFIG_PINCTRL_SINGLE=y >>

Re: [PATCH] iio: dac: mcp4725: Remove unneeded conversions to bool

> Found with scripts/coccinelle/misc/boolconv.cocci. I'd argue that pd = (inbuf[0] >> 1) & 0x3; if (pd) { data->powerdown = true; data->powerdown_mode = pd - 1; } else { data->powerdown = false;

Re: [PATCH] arm64: defconfig: Enable QDF2432 config options

On 07/01/2016 10:14 AM, Timur Tabi wrote: > Christopher Covington wrote: >> arch/arm64/configs/defconfig | 4 >> scripts/patch-details.sh | 21 ++--- > > I don't think these two files should be combined. Oops, sorry. Fixed in v2. >> CONFIG_PINCTRL_SINGLE=y >>

Re: [PATCH] iio: dac: mcp4725: Remove unneeded conversions to bool

> Found with scripts/coccinelle/misc/boolconv.cocci. I'd argue that pd = (inbuf[0] >> 1) & 0x3; if (pd) { data->powerdown = true; data->powerdown_mode = pd - 1; } else { data->powerdown = false;

Re: [RFC PATCH 0/2] net: ethernet: Add support for gmii2rgmii converter

Le 30/06/2016 23:20, Kedareswara rao Appana a écrit : > This patch series does the following > ---> Add support for gmii2rgmii converter. > ---> Add support for gmii2rgmii converter in the macb driver. > > Earlier sent one RFC patch https://patchwork.kernel.org/patch/9186615/ > which includes

Re: [RFC PATCH 0/2] net: ethernet: Add support for gmii2rgmii converter

Le 30/06/2016 23:20, Kedareswara rao Appana a écrit : > This patch series does the following > ---> Add support for gmii2rgmii converter. > ---> Add support for gmii2rgmii converter in the macb driver. > > Earlier sent one RFC patch https://patchwork.kernel.org/patch/9186615/ > which includes

Re: [PATCH] doc: flat-table directive

Em Fri, 1 Jul 2016 16:07:47 +0200 Markus Heiser escreveu: > Am 01.07.2016 um 15:09 schrieb Jani Nikula : > > > On Fri, 01 Jul 2016, Markus Heiser wrote: > >> In Sphinx, the code-block directive is a literal block,

Re: [PATCH] doc: flat-table directive

Em Fri, 1 Jul 2016 16:07:47 +0200 Markus Heiser escreveu: > Am 01.07.2016 um 15:09 schrieb Jani Nikula : > > > On Fri, 01 Jul 2016, Markus Heiser wrote: > >> In Sphinx, the code-block directive is a literal block,

Re: [PATCH] doc: flat-table directive

Em Fri, 1 Jul 2016 16:07:47 +0200 Markus Heiser escreveu: > Am 01.07.2016 um 15:09 schrieb Jani Nikula : > > > On Fri, 01 Jul 2016, Markus Heiser wrote: > >> In Sphinx, the code-block directive is a literal block, no refs or markup > >> will be interpreted. This is different to what you know

Re: [PATCH] doc: flat-table directive

Em Fri, 1 Jul 2016 16:07:47 +0200 Markus Heiser escreveu: > Am 01.07.2016 um 15:09 schrieb Jani Nikula : > > > On Fri, 01 Jul 2016, Markus Heiser wrote: > >> In Sphinx, the code-block directive is a literal block, no refs or markup > >> will be interpreted. This is different to what you know

Re: EXT: Re: [PATCH RFC 1/4] dma: imx-sdma - reduce transfer latency for DMA cyclic clients

On 28/06/16 17:34, Vinod Koul wrote: On Thu, Jun 09, 2016 at 03:16:30PM +0300, Nandor Han wrote: Having the SDMA driver use a tasklet for running the clients callback introduce some issues: - probability to have desynchronized data because of the race condition created since the DMA

Re: [PATCH] spi: imx: wait_for_completion_timeout(..) for PIO transfers

On Fri, Jul 01, 2016 at 02:32:58PM +0200, Christian Gmeiner wrote: > In some rare cases I see the following 'task blocked' information. It > looks like the PIO transfer has some problems and never succeeds. Make > use of wait_for_completion_timeout(..) to detect this case and > return -ETIMEDOUT.

Re: [PATCH] drivers/perf: arm-pmu: Handle per-interrupt affinity mask

Hi Marc, On 2016年07月01日 21:21, Marc Zyngier wrote: On a big-little system, PMUs can be wired to CPUs using per CPU interrups (PPI). In this case, it is important to make sure that the enable/disable do happen on the right set of CPUs. So instead of relying on the interrupt-affinity property,

Re: EXT: Re: [PATCH RFC 1/4] dma: imx-sdma - reduce transfer latency for DMA cyclic clients

On 28/06/16 17:34, Vinod Koul wrote: On Thu, Jun 09, 2016 at 03:16:30PM +0300, Nandor Han wrote: Having the SDMA driver use a tasklet for running the clients callback introduce some issues: - probability to have desynchronized data because of the race condition created since the DMA

Re: [PATCH] spi: imx: wait_for_completion_timeout(..) for PIO transfers

On Fri, Jul 01, 2016 at 02:32:58PM +0200, Christian Gmeiner wrote: > In some rare cases I see the following 'task blocked' information. It > looks like the PIO transfer has some problems and never succeeds. Make > use of wait_for_completion_timeout(..) to detect this case and > return -ETIMEDOUT.

Re: [PATCH] drivers/perf: arm-pmu: Handle per-interrupt affinity mask

Hi Marc, On 2016年07月01日 21:21, Marc Zyngier wrote: On a big-little system, PMUs can be wired to CPUs using per CPU interrups (PPI). In this case, it is important to make sure that the enable/disable do happen on the right set of CPUs. So instead of relying on the interrupt-affinity property,

Re: [RFC PATCH 1/2] net: ethernet: xilinx: Add gmii2rgmii converter support

Le 30/06/2016 23:20, Kedareswara rao Appana a écrit : > This patch adds support for gmii2rgmii converter. > > The GMII to RGMII IP core provides the Reduced Gigabit Media > Independent Interface (RGMII) between Ethernet physical media > Devices and the Gigabit Ethernet controller. This core can >

Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

On Fri, Jul 01, 2016 at 10:58:34AM +0200, Michal Suchanek wrote: > On 1 July 2016 at 10:25, Mark Brown wrote: > > It's been repeatedly suggested to you that the tooling for this stuff > > could use some work. Please go and put some effort into that rather > > than continuing

Re: [RFC PATCH 1/2] net: ethernet: xilinx: Add gmii2rgmii converter support

Le 30/06/2016 23:20, Kedareswara rao Appana a écrit : > This patch adds support for gmii2rgmii converter. > > The GMII to RGMII IP core provides the Reduced Gigabit Media > Independent Interface (RGMII) between Ethernet physical media > Devices and the Gigabit Ethernet controller. This core can >

Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

On Fri, Jul 01, 2016 at 10:58:34AM +0200, Michal Suchanek wrote: > On 1 July 2016 at 10:25, Mark Brown wrote: > > It's been repeatedly suggested to you that the tooling for this stuff > > could use some work. Please go and put some effort into that rather > > than continuing this thread which

Re: [PATCH v3] vmlinux.lds: account for destructor sections

2016-06-29 20:28 GMT+03:00 Dmitry Vyukov : > On Fri, Jun 24, 2016 at 6:57 PM, Andrey Ryabinin > wrote: >> 2016-06-24 18:39 GMT+03:00 Dmitry Vyukov : >>> If CONFIG_KASAN is enabled and gcc is configured with >>>

Re: [PATCH 3/4] sched/fair: Add REBALANCE_AFFINITY rebalancing code

On Fri, Jul 01, 2016 at 09:15:55AM -0500, James Hartsock wrote: > On Fri, Jul 1, 2016 at 3:24 AM, Peter Zijlstra wrote: > > > On Fri, Jul 01, 2016 at 09:35:46AM +0200, Jiri Olsa wrote: > > > well this is issue our partner met in the setup, > > > and I'm not sure what was

Re: [PATCH v4 09/29] fork: Add generic vmalloced stack support

On Sun, Jun 26, 2016 at 02:55:31PM -0700, Andy Lutomirski wrote: > If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with > vmalloc_node. > > grsecurity has had a similar feature (called > GRKERNSEC_KSTACKOVERFLOW) for a long time. > > Cc: Oleg Nesterov >

Re: [PATCH v3] vmlinux.lds: account for destructor sections

2016-06-29 20:28 GMT+03:00 Dmitry Vyukov : > On Fri, Jun 24, 2016 at 6:57 PM, Andrey Ryabinin > wrote: >> 2016-06-24 18:39 GMT+03:00 Dmitry Vyukov : >>> If CONFIG_KASAN is enabled and gcc is configured with >>> --disable-initfini-array and/or gold linker is used, >>> gcc emits .ctors/.dtors and

Re: [PATCH 3/4] sched/fair: Add REBALANCE_AFFINITY rebalancing code

On Fri, Jul 01, 2016 at 09:15:55AM -0500, James Hartsock wrote: > On Fri, Jul 1, 2016 at 3:24 AM, Peter Zijlstra wrote: > > > On Fri, Jul 01, 2016 at 09:35:46AM +0200, Jiri Olsa wrote: > > > well this is issue our partner met in the setup, > > > and I'm not sure what was their motivation for

Re: [PATCH v4 09/29] fork: Add generic vmalloced stack support

On Sun, Jun 26, 2016 at 02:55:31PM -0700, Andy Lutomirski wrote: > If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with > vmalloc_node. > > grsecurity has had a similar feature (called > GRKERNSEC_KSTACKOVERFLOW) for a long time. > > Cc: Oleg Nesterov > Signed-off-by: Andy

Re: mfd: dm355evm_msp: Refactoring for add_child()

> FYI, code looks fine. Thanks for your acknowledgement. > ... but please take this opportunity to set-up your submission > environment i.e. using `git format-patch` and `git send-email`. Would you like to see any special settings to be mentioned in a section like "15) Explicit In-Reply-To

Re: mfd: dm355evm_msp: Refactoring for add_child()

> FYI, code looks fine. Thanks for your acknowledgement. > ... but please take this opportunity to set-up your submission > environment i.e. using `git format-patch` and `git send-email`. Would you like to see any special settings to be mentioned in a section like "15) Explicit In-Reply-To

Re: [PATCH v1 06/11] KVM: x86: use hardware-compatible format for APIC ID register

2016-07-01 16:12+0200, Paolo Bonzini: > On 01/07/2016 15:11, Radim Krčmář wrote: >> +static void __kvm_apic_state_fixup(struct kvm_vcpu *vcpu, >> + struct kvm_lapic_state *s, bool set) >> +{ >> + if (apic_x2apic_mode(vcpu->arch.apic)) { >> +

Re: [PATCH v1 06/11] KVM: x86: use hardware-compatible format for APIC ID register

2016-07-01 16:12+0200, Paolo Bonzini: > On 01/07/2016 15:11, Radim Krčmář wrote: >> +static void __kvm_apic_state_fixup(struct kvm_vcpu *vcpu, >> + struct kvm_lapic_state *s, bool set) >> +{ >> + if (apic_x2apic_mode(vcpu->arch.apic)) { >> +

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