[PATCH] PM / sleep: Put pm_test under CONFIG_PM_SLEEP_DEBUG

From: Rafael J. Wysocki The pm_test sysfs attribute is under CONFIG_PM_DEBUG, but it doesn't make sense to provide it if CONFIG_PM_SLEEP is unset, so put it under CONFIG_PM_SLEEP_DEBUG instead. Signed-off-by: Rafael J. Wysocki ---

[PATCH] PM / sleep: Put pm_test under CONFIG_PM_SLEEP_DEBUG

From: Rafael J. Wysocki The pm_test sysfs attribute is under CONFIG_PM_DEBUG, but it doesn't make sense to provide it if CONFIG_PM_SLEEP is unset, so put it under CONFIG_PM_SLEEP_DEBUG instead. Signed-off-by: Rafael J. Wysocki --- kernel/power/main.c |8 +++- kernel/power/power.h |

[PATCH 1/3] PCI / PM: Skip bridges in pci_enable_wake()

From: Rafael J. Wysocki PCI bridges only have a reason to generate wakeup signals on behalf of devices below them, so avoid preparing bridges for wakeup directly in pci_enable_wake(). Also drop the pci_has_subordinate() check from pci_pm_default_resume() as this will

[PATCH 1/3] PCI / PM: Skip bridges in pci_enable_wake()

From: Rafael J. Wysocki PCI bridges only have a reason to generate wakeup signals on behalf of devices below them, so avoid preparing bridges for wakeup directly in pci_enable_wake(). Also drop the pci_has_subordinate() check from pci_pm_default_resume() as this will be done by

[PATCH 3/3] ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()

From: Rafael J. Wysocki The acpi_pci_propagate_wakeup() routine is there to handle cases in which PCI bridges (or PCIe ports) are expected to signal wakeup for devices below them, but currently it doesn't do that correctly. The problem is that

[PATCH 0/3] PCI / ACPI / PM: Fix propagation of wakeup settings to bridges

Hi, The device wakeup code in pci-acpi.c currently has a (theoretical) problem that it can disable wakeup for a bridge prematurely in some obscure conditions. This is described in some more detail in the changelog of patch [3/3] and it has been there for quite a while, so it's nothing new, but

[PATCH 3/3] ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()

From: Rafael J. Wysocki The acpi_pci_propagate_wakeup() routine is there to handle cases in which PCI bridges (or PCIe ports) are expected to signal wakeup for devices below them, but currently it doesn't do that correctly. The problem is that acpi_pci_propagate_wakeup() uses

[PATCH 0/3] PCI / ACPI / PM: Fix propagation of wakeup settings to bridges

Hi, The device wakeup code in pci-acpi.c currently has a (theoretical) problem that it can disable wakeup for a bridge prematurely in some obscure conditions. This is described in some more detail in the changelog of patch [3/3] and it has been there for quite a while, so it's nothing new, but

[PATCH 2/3] ACPI / PM: Split acpi_device_wakeup()

From: Rafael J. Wysocki To prepare for a subsequent change and make the code somewhat easier to follow, do the following in the ACPI device wakeup handling code: * Replace wakeup.flags.enabled under struct acpi_device with wakeup.enable_count as that will be

[PATCH 2/3] ACPI / PM: Split acpi_device_wakeup()

From: Rafael J. Wysocki To prepare for a subsequent change and make the code somewhat easier to follow, do the following in the ACPI device wakeup handling code: * Replace wakeup.flags.enabled under struct acpi_device with wakeup.enable_count as that will be necessary going forward. For

[RFC PATCH v2] ARM: dts: stm32: change pinctrl bindings definition

Initially each pin was declared in "include/dt-bindings/stm32f429-pinfunc.h" and each definition contained SOC names (ex: STM32F429_PA9_FUNC_USART1_TX). Since this approach was approved, the number of supported MCU has increased (STM32F429/STM32F469/STM32f746/STM32H743). To avoid to add a new file

[RFC PATCH v2] ARM: dts: stm32: change pinctrl bindings definition

Initially each pin was declared in "include/dt-bindings/stm32f429-pinfunc.h" and each definition contained SOC names (ex: STM32F429_PA9_FUNC_USART1_TX). Since this approach was approved, the number of supported MCU has increased (STM32F429/STM32F469/STM32f746/STM32H743). To avoid to add a new file

[RFC PATCH v2] ARM: dts: stm32: change pinctrl bindings definition

Initially each pin was declared in "include/dt-bindings/stm32f429-pinfunc.h" and each definition contained SOC names (ex: STM32F429_PA9_FUNC_USART1_TX). Since this approach was approved, the number of supported MCU has increased (STM32F429/STM32F469/STM32f746/STM32H743). To avoid to add a new file

Re: [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On 07/21/17 at 12:33pm, Ingo Molnar wrote: > > * Baoquan He wrote: > > > Kernel text may be located in non-mirror regions (movable zone) when both > > address range mirroring feature and KASLR are enabled. > > > > The address range mirroring feature arranges such mirror region

Re: [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On 07/21/17 at 12:33pm, Ingo Molnar wrote: > > * Baoquan He wrote: > > > Kernel text may be located in non-mirror regions (movable zone) when both > > address range mirroring feature and KASLR are enabled. > > > > The address range mirroring feature arranges such mirror region into > > normal

[RFC PATCH v2] ARM: dts: stm32: change pinctrl bindings definition

Initially each pin was declared in "include/dt-bindings/stm32f429-pinfunc.h" and each definition contained SOC names (ex: STM32F429_PA9_FUNC_USART1_TX). Since this approach was approved, the number of supported MCU has increased (STM32F429/STM32F469/STM32f746/STM32H743). To avoid to add a new file

RE: [PATCH] scsi: megaraid_sas: fix memleak in megasas_alloc_cmdlist_fusion

>-Original Message- >From: shuw...@redhat.com [mailto:shuw...@redhat.com] >Sent: Friday, July 21, 2017 4:24 PM >To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com; >shivasharan.srikanteshw...@broadcom.com; j...@linux.vnet.ibm.com; >martin.peter...@oracle.com >Cc:

RE: [PATCH] scsi: megaraid_sas: fix memleak in megasas_alloc_cmdlist_fusion

>-Original Message- >From: shuw...@redhat.com [mailto:shuw...@redhat.com] >Sent: Friday, July 21, 2017 4:24 PM >To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com; >shivasharan.srikanteshw...@broadcom.com; j...@linux.vnet.ibm.com; >martin.peter...@oracle.com >Cc:

Re: [PATCH 01/12] ARM: ixp4xx: fix ioport_unmap definition

Arnd Bergmann writes: > An empty macro definition can cause unexpected behavior, in > case of the ixp4xx ioport_unmap, we get two warnings: > > drivers/net/wireless/marvell/libertas/if_cs.c: In function 'if_cs_release': > drivers/net/wireless/marvell/libertas/if_cs.c:826:3: error:

Re: [PATCH 01/12] ARM: ixp4xx: fix ioport_unmap definition

Arnd Bergmann writes: > An empty macro definition can cause unexpected behavior, in > case of the ixp4xx ioport_unmap, we get two warnings: > > drivers/net/wireless/marvell/libertas/if_cs.c: In function 'if_cs_release': > drivers/net/wireless/marvell/libertas/if_cs.c:826:3: error: suggest braces

Re: [PATCH] x86/kernel/cpu/amd.c: don't apply the lahf_lm workaround in a hypervisor

On Fri, Jul 21, 2017 at 07:34:59AM -0400, Mikulas Patocka wrote: > (and I can't use kernels newer that 4.4 on the host machine because of > broken hibernation) And what do we do with upstream patches which we need in older kernels? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails

Re: [PATCH] x86/kernel/cpu/amd.c: don't apply the lahf_lm workaround in a hypervisor

On Fri, Jul 21, 2017 at 07:34:59AM -0400, Mikulas Patocka wrote: > (and I can't use kernels newer that 4.4 on the host machine because of > broken hibernation) And what do we do with upstream patches which we need in older kernels? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails

Re: nbd drops connection on most writes

On Fri, Jul 21, 2017 at 12:22:51PM +, Josef Bacik wrote: > Oh shit the default timeout is 0 if you don't set it in the client. Use > the timeout option with nbd client and it should fix it for you. I'll > send something up to make this a sane default. Confirmed, adding a timeout=XXX

Re: nbd drops connection on most writes

On Fri, Jul 21, 2017 at 12:22:51PM +, Josef Bacik wrote: > Oh shit the default timeout is 0 if you don't set it in the client. Use > the timeout option with nbd client and it should fix it for you. I'll > send something up to make this a sane default. Confirmed, adding a timeout=XXX

RE: [PATCH v4 1/3] mfd: Add new mfd device TPS68470

Hi Lee, > > > + * This program is free software; you can redistribute it and/or > > > + * modify it under the terms of the GNU General Public License as > > > + * published by the Free Software Foundation version 2. > > > + * > > > + * This program is distributed "as is" WITHOUT ANY WARRANTY of

RE: [PATCH v4 1/3] mfd: Add new mfd device TPS68470

Hi Lee, > > > + * This program is free software; you can redistribute it and/or > > > + * modify it under the terms of the GNU General Public License as > > > + * published by the Free Software Foundation version 2. > > > + * > > > + * This program is distributed "as is" WITHOUT ANY WARRANTY of

Re: nbd drops connection on most writes

Oh shit the default timeout is 0 if you don't set it in the client. Use the timeout option with nbd client and it should fix it for you. I'll send something up to make this a sane default. Thanks, Josef Sent from my iPhone > On Jul 21, 2017, at 8:15 AM, Adam Borowski

Re: nbd drops connection on most writes

Oh shit the default timeout is 0 if you don't set it in the client. Use the timeout option with nbd client and it should fix it for you. I'll send something up to make this a sane default. Thanks, Josef Sent from my iPhone > On Jul 21, 2017, at 8:15 AM, Adam Borowski wrote: > > Hi! > I'm

[PATCH] errseq: rename __errseq_set to errseq_set

From: Jeff Layton Nothing calls this wrapper anymore, so just remove it and rename the old function to get rid of the double underscore prefix. Signed-off-by: Jeff Layton --- include/linux/errseq.h | 9 + lib/errseq.c | 6 +++---

[PATCH] errseq: rename __errseq_set to errseq_set

From: Jeff Layton Nothing calls this wrapper anymore, so just remove it and rename the old function to get rid of the double underscore prefix. Signed-off-by: Jeff Layton --- include/linux/errseq.h | 9 + lib/errseq.c | 6 +++--- mm/filemap.c | 2 +- 3 files

nbd drops connection on most writes

Hi! I'm afraid that 4.13-rc1 nbd aborts connection on writes for me: [ 251.938384] block nbd0: Send data failed (result -11) [ 251.943484] block nbd0: Request send failed trying another connection [ 251.950034] block nbd0: Receive control failed (result -32) [ 251.955676] block nbd0:

Re: [PATCH] lib/int_sqrt.c: Optimize square root function

On Fri, 2017-07-21 at 13:40 +0200, Peter Zijlstra wrote: > @@ -21,7 +22,11 @@ unsigned long int_sqrt(unsigned long x) > if (x <= 1) > return x; > > - m = 1UL << (BITS_PER_LONG - 2); > + m = 1UL << (__fls(x) & ~1U); > + > + while (m > x) > + m >>= 2;

nbd drops connection on most writes

Hi! I'm afraid that 4.13-rc1 nbd aborts connection on writes for me: [ 251.938384] block nbd0: Send data failed (result -11) [ 251.943484] block nbd0: Request send failed trying another connection [ 251.950034] block nbd0: Receive control failed (result -32) [ 251.955676] block nbd0:

Re: [PATCH] lib/int_sqrt.c: Optimize square root function

On Fri, 2017-07-21 at 13:40 +0200, Peter Zijlstra wrote: > @@ -21,7 +22,11 @@ unsigned long int_sqrt(unsigned long x) > if (x <= 1) > return x; > > - m = 1UL << (BITS_PER_LONG - 2); > + m = 1UL << (__fls(x) & ~1U); > + > + while (m > x) > + m >>= 2;

[PATCH 2/4] perf tools: Add perf_evsel__read_size function

Currently we use the size of struct perf_counts_values to read the event, which prevents us to put any new member to the struct. Adding perf_evsel__read_size to return size of the buffer needed for event read. Link: http://lkml.kernel.org/n/tip-cfc3dmil3tlzezzxtyi9f...@git.kernel.org

[PATCH 2/4] perf tools: Add perf_evsel__read_size function

Currently we use the size of struct perf_counts_values to read the event, which prevents us to put any new member to the struct. Adding perf_evsel__read_size to return size of the buffer needed for event read. Link: http://lkml.kernel.org/n/tip-cfc3dmil3tlzezzxtyi9f...@git.kernel.org

[PATCH 1/4] perf tools: Add verbose output for sys_perf_event_open fallback

Adding info about what is being switched off in the sys_perf_event_open fallback. New output (notice the 'switching off' lines): $ perf stat -e '{cycles,instructions}' -vvv ls Using CPUID GenuineIntel-6-3D intel_pt default config: tsc

[PATCH 1/4] perf tools: Add verbose output for sys_perf_event_open fallback

Adding info about what is being switched off in the sys_perf_event_open fallback. New output (notice the 'switching off' lines): $ perf stat -e '{cycles,instructions}' -vvv ls Using CPUID GenuineIntel-6-3D intel_pt default config: tsc

[PATCH 0/4] perf stat: Enable group read of counters

hi, sending changes to enable group read of perf counters for perf stat command. It allows us to read whole group of counters within single read syscall. Also available in here: git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git perf/stat_group Not sure why we haven't supported

[PATCH 4/4] perf stat: Use group read for event groups

Make perf stat use group read if there are groups defined. The group read will get the values for all member of groups within a single syscall instead of calling read syscall for every event. We can see considerable less amount of kernel cycles spent on single group read, than reading each

[PATCH 0/4] perf stat: Enable group read of counters

hi, sending changes to enable group read of perf counters for perf stat command. It allows us to read whole group of counters within single read syscall. Also available in here: git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git perf/stat_group Not sure why we haven't supported

[PATCH 4/4] perf stat: Use group read for event groups

Make perf stat use group read if there are groups defined. The group read will get the values for all member of groups within a single syscall instead of calling read syscall for every event. We can see considerable less amount of kernel cycles spent on single group read, than reading each

[PATCH 3/4] perf tools: Add perf_evsel__read_counter function

Adding perf_evsel__read_counter function to read single or group counter. After calling this function the counter's evsel::counts struct is filled with values for the counter and member of its group if there are any. Link: http://lkml.kernel.org/n/tip-itsuxdyt7rp4mvij1t6k7...@git.kernel.org

[PATCH 3/4] perf tools: Add perf_evsel__read_counter function

Adding perf_evsel__read_counter function to read single or group counter. After calling this function the counter's evsel::counts struct is filled with values for the counter and member of its group if there are any. Link: http://lkml.kernel.org/n/tip-itsuxdyt7rp4mvij1t6k7...@git.kernel.org

Re: [PATCH v2 5/8] KVM: arm/arm64: vgic: Handle mapped level sensitive SPIs

On Thu, Jun 15, 2017 at 02:52:37PM +0200, Eric Auger wrote: > Currently, the line level of unmapped level sensitive SPIs is > toggled down by the maintenance IRQ handler/resamplefd mechanism. > > As mapped SPI completion is not trapped, we cannot rely on this > mechanism and the line level needs

Re: [PATCH v2 5/8] KVM: arm/arm64: vgic: Handle mapped level sensitive SPIs

On Thu, Jun 15, 2017 at 02:52:37PM +0200, Eric Auger wrote: > Currently, the line level of unmapped level sensitive SPIs is > toggled down by the maintenance IRQ handler/resamplefd mechanism. > > As mapped SPI completion is not trapped, we cannot rely on this > mechanism and the line level needs

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Fri, Jul 21, 2017 at 10:10 AM, Bob Liu wrote: > On 2017/7/21 9:41, Jerome Glisse wrote: >> On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote: >>> On 2017/7/20 23:03, Jerome Glisse wrote: On Wed, Jul 19, 2017 at 05:09:04PM +0800, Bob Liu wrote: > On 2017/7/19

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Fri, Jul 21, 2017 at 10:10 AM, Bob Liu wrote: > On 2017/7/21 9:41, Jerome Glisse wrote: >> On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote: >>> On 2017/7/20 23:03, Jerome Glisse wrote: On Wed, Jul 19, 2017 at 05:09:04PM +0800, Bob Liu wrote: > On 2017/7/19 10:25, Jerome Glisse

Re: [PATCH v4 2/2] arm64: dts: Add Mediatek SoC MT2712 and evaluation board dts and Makefile

On 07/21/2017 08:32 AM, YT Shen wrote: On Wed, 2017-07-19 at 11:26 +0200, Matthias Brugger wrote: On 07/19/2017 08:48 AM, YT Shen wrote: On Tue, 2017-07-18 at 18:29 +0200, Matthias Brugger wrote: On 06/22/2017 11:32 AM, YT Shen wrote: This adds basic chip support for Mediatek 2712

Re: [PATCH v4 2/2] arm64: dts: Add Mediatek SoC MT2712 and evaluation board dts and Makefile

On 07/21/2017 08:32 AM, YT Shen wrote: On Wed, 2017-07-19 at 11:26 +0200, Matthias Brugger wrote: On 07/19/2017 08:48 AM, YT Shen wrote: On Tue, 2017-07-18 at 18:29 +0200, Matthias Brugger wrote: On 06/22/2017 11:32 AM, YT Shen wrote: This adds basic chip support for Mediatek 2712

Re: [PATCH] Documentation: mtk-quadspi: update DT bindings

On 07/21/2017 05:26 AM, Guochun Mao wrote: Add "mediatek,mt2712-nor" and "mediatek,mt7622-nor" for nor flash node's compatible. Signed-off-by: Guochun Mao Reviewed-by: Matthias Brugger --- .../devicetree/bindings/mtd/mtk-quadspi.txt

Re: [PATCH] Documentation: mtk-quadspi: update DT bindings

On 07/21/2017 05:26 AM, Guochun Mao wrote: Add "mediatek,mt2712-nor" and "mediatek,mt7622-nor" for nor flash node's compatible. Signed-off-by: Guochun Mao Reviewed-by: Matthias Brugger --- .../devicetree/bindings/mtd/mtk-quadspi.txt|2 ++ 1 file changed, 2 insertions(+)

Re: [PATCH v2 4/8] KVM: arm/arm64: vgic: restructure kvm_vgic_(un)map_phys_irq

On Thu, Jun 15, 2017 at 02:52:36PM +0200, Eric Auger wrote: > We want to reuse the core of the map/unmap functions for IRQ > forwarding. Let's move the computation of the hwirq in > kvm_vgic_map_phys_irq and pass the linux IRQ as parameter. > the host_irq is added to struct vgic_irq. > > We

Re: [PATCH v2 4/8] KVM: arm/arm64: vgic: restructure kvm_vgic_(un)map_phys_irq

On Thu, Jun 15, 2017 at 02:52:36PM +0200, Eric Auger wrote: > We want to reuse the core of the map/unmap functions for IRQ > forwarding. Let's move the computation of the hwirq in > kvm_vgic_map_phys_irq and pass the linux IRQ as parameter. > the host_irq is added to struct vgic_irq. > > We

[PATCH v2 3/4] iommu/iova: Extend rbtree node caching

The cached node mechanism provides a significant performance benefit for allocations using a 32-bit DMA mask, but in the case of non-PCI devices or where the 32-bit space is full, the loss of this benefit can be significant - on large systems there can be many thousands of entries in the tree,

[PATCH v2 3/4] iommu/iova: Extend rbtree node caching

The cached node mechanism provides a significant performance benefit for allocations using a 32-bit DMA mask, but in the case of non-PCI devices or where the 32-bit space is full, the loss of this benefit can be significant - on large systems there can be many thousands of entries in the tree,

Re: [PATCH] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

Hi Hanjun, On Fri, Jul 21, 2017 at 4:50 PM, Marc Zyngier wrote: > On 21/07/17 11:06, Hanjun Guo wrote: >> On 2017/7/21 17:51, Hanjun Guo wrote: >>> From: Hanjun Guo >>> >>> When running 4.13-rc1 on top of D05, I got the boot log: >>> >>> [

[PATCH v2 2/4] iommu/iova: Optimise the padding calculation

From: Zhen Lei The mask for calculating the padding size doesn't change, so there's no need to recalculate it every loop iteration. Furthermore, Once we've done that, it becomes clear that we don't actually need to calculate a padding size at all - by flipping the

Re: [PATCH] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

Hi Hanjun, On Fri, Jul 21, 2017 at 4:50 PM, Marc Zyngier wrote: > On 21/07/17 11:06, Hanjun Guo wrote: >> On 2017/7/21 17:51, Hanjun Guo wrote: >>> From: Hanjun Guo >>> >>> When running 4.13-rc1 on top of D05, I got the boot log: >>> >>> [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 >>> [

[PATCH v2 2/4] iommu/iova: Optimise the padding calculation

From: Zhen Lei The mask for calculating the padding size doesn't change, so there's no need to recalculate it every loop iteration. Furthermore, Once we've done that, it becomes clear that we don't actually need to calculate a padding size at all - by flipping the arithmetic around, we can just

[PATCH v2 4/4] iommu/iova: Make dma_32bit_pfn implicit

From: Zhen Lei Now that the cached node optimisation can apply to all allocations, the couple of users which were playing tricks with dma_32bit_pfn in order to benefit from it can stop doing so. Conversely, there is also no need for all the other users to explicitly

[PATCH v2 4/4] iommu/iova: Make dma_32bit_pfn implicit

From: Zhen Lei Now that the cached node optimisation can apply to all allocations, the couple of users which were playing tricks with dma_32bit_pfn in order to benefit from it can stop doing so. Conversely, there is also no need for all the other users to explicitly calculate a 'real' 32-bit

[PATCH v2 1/4] iommu/iova: Optimise rbtree searching

From: Zhen Lei Checking the IOVA bounds separately before deciding which direction to continue the search (if necessary) results in redundantly comparing both pfns twice each. GCC can already determine that the final comparison op is redundant and optimise it down to

[PATCH v2 1/4] iommu/iova: Optimise rbtree searching

From: Zhen Lei Checking the IOVA bounds separately before deciding which direction to continue the search (if necessary) results in redundantly comparing both pfns twice each. GCC can already determine that the final comparison op is redundant and optimise it down to 3 in total, but we can go

[PATCH v2 0/4] Optimise 64-bit IOVA allocations

Hi all, In the wake of the ARM SMMU optimisation efforts, it seems that certain workloads (e.g. storage I/O with large scatterlists) probably remain quite heavily influenced by IOVA allocation performance. Separately, Ard also reported massive performance drops for a graphical desktop on AMD

[PATCH v2 0/4] Optimise 64-bit IOVA allocations

Hi all, In the wake of the ARM SMMU optimisation efforts, it seems that certain workloads (e.g. storage I/O with large scatterlists) probably remain quite heavily influenced by IOVA allocation performance. Separately, Ard also reported massive performance drops for a graphical desktop on AMD

Re: [PATCH] lib/int_sqrt.c: Optimize square root function

On Thu, Jul 20, 2017 at 04:24:32PM -0700, Linus Torvalds wrote: > So mayube something like the attached? > > NOTE NOTE NOTE! This may be pure garbage. It's untested. But the code > generation looks ok even if gcc is being way too clever and turns that > first loop into a counted loop instead.

Re: [PATCH] lib/int_sqrt.c: Optimize square root function

On Thu, Jul 20, 2017 at 04:24:32PM -0700, Linus Torvalds wrote: > So mayube something like the attached? > > NOTE NOTE NOTE! This may be pure garbage. It's untested. But the code > generation looks ok even if gcc is being way too clever and turns that > first loop into a counted loop instead.

Re: [PATCH v1] mm/vmalloc: add a node corresponding to cached_hole_size

On Fri, Jul 21, 2017 at 06:01:41PM +0800, Zhaoyang Huang wrote: > we just record the cached_hole_size now, which will be used when > the criteria meet both of 'free_vmap_cache == NULL' and 'size < > cached_hole_size'. However, under above scenario, the search will > start from the rb_root and then

Re: [PATCH v1] mm/vmalloc: add a node corresponding to cached_hole_size

On Fri, Jul 21, 2017 at 06:01:41PM +0800, Zhaoyang Huang wrote: > we just record the cached_hole_size now, which will be used when > the criteria meet both of 'free_vmap_cache == NULL' and 'size < > cached_hole_size'. However, under above scenario, the search will > start from the rb_root and then

Problematic culture around Signed-off-by

Hi folks, I've been away from kernel development for a bit, but I've returned and I'm troubled by what seems to be an entrenched and widespread (IMO) misuse of the "Signed-off-by:" in commits. I've now either been asked to sign off RFC quality patches "because its quicker" on more than one

Problematic culture around Signed-off-by

Hi folks, I've been away from kernel development for a bit, but I've returned and I'm troubled by what seems to be an entrenched and widespread (IMO) misuse of the "Signed-off-by:" in commits. I've now either been asked to sign off RFC quality patches "because its quicker" on more than one

Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: a64: enable AXP803 for Banana Pi M64

在 2017-07-21 15:49，Chen-Yu Tsai 写道： On Fri, Jul 21, 2017 at 3:44 PM, Icenowy Zheng wrote: 于 2017年7月21日 GMT+08:00 下午3:42:07, Chen-Yu Tsai 写到: On Fri, Jul 21, 2017 at 7:07 AM, Icenowy Zheng wrote: Banana Pi M64 board uses an AXP803 PMIC.

Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: a64: enable AXP803 for Banana Pi M64

在 2017-07-21 15:49，Chen-Yu Tsai 写道： On Fri, Jul 21, 2017 at 3:44 PM, Icenowy Zheng wrote: 于 2017年7月21日 GMT+08:00 下午3:42:07, Chen-Yu Tsai 写到: On Fri, Jul 21, 2017 at 7:07 AM, Icenowy Zheng wrote: Banana Pi M64 board uses an AXP803 PMIC. Enable the PMIC and its regulators. As we have now

[PATCH v4 1/7] dt-bindings: phy: qmp: Add output-clock-names

The phy outputs a clock that will act as the parent for the phy's pipe clock. Add the name of this clock to the lane's DT node. Acked-by: Rob Herring Signed-off-by: Varadarajan Narayanan --- Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 3 +++

[PATCH v4 1/7] dt-bindings: phy: qmp: Add output-clock-names

The phy outputs a clock that will act as the parent for the phy's pipe clock. Add the name of this clock to the lane's DT node. Acked-by: Rob Herring Signed-off-by: Varadarajan Narayanan --- Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 3 +++ 1 file changed, 3 insertions(+) diff

Re: [PATCH] pci: add missing __iomem cast

Hi Christoph, Looking deep into to this, i think there is no need to use phy_to_virts since pdev->rom is already a physical address. That's what pci_platform_rom should return, right?! I'll probably send a new patch removing the usage of phys_to_virt. Regards, C.Palminha On 20-07-2017 09:07,

Re: [PATCH] pci: add missing __iomem cast

Hi Christoph, Looking deep into to this, i think there is no need to use phy_to_virts since pdev->rom is already a physical address. That's what pci_platform_rom should return, right?! I'll probably send a new patch removing the usage of phys_to_virt. Regards, C.Palminha On 20-07-2017 09:07,

[PATCH v4 5/7] PCI: dwc: qcom: Use block IP version for operations

Presently, when support for a new SoC is added, the driver ops structures and functions are versioned with plain 1, 2, 3 etc. Instead use the block IP version number. Signed-off-by: Varadarajan Narayanan --- drivers/pci/dwc/pcie-qcom.c | 124

[PATCH v4 5/7] PCI: dwc: qcom: Use block IP version for operations

Presently, when support for a new SoC is added, the driver ops structures and functions are versioned with plain 1, 2, 3 etc. Instead use the block IP version number. Signed-off-by: Varadarajan Narayanan --- drivers/pci/dwc/pcie-qcom.c | 124 ++-- 1 file

[PATCH v4 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe controller

Add support for the IPQ8074 PCIe controller. IPQ8074 supports Gen 1/2, one lane, two PCIe root complex with support for MSI and legacy interrupts, and it conforms to PCI Express Base 2.1 specification. The core init is the similar to the existing SoC, however the clocks and reset lines differ.

[PATCH v4 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe controller

Add support for the IPQ8074 PCIe controller. IPQ8074 supports Gen 1/2, one lane, two PCIe root complex with support for MSI and legacy interrupts, and it conforms to PCI Express Base 2.1 specification. The core init is the similar to the existing SoC, however the clocks and reset lines differ.

[PATCH v4 3/7] phy: qcom-qmp: Fix phy pipe clock name

Presently, the phy pipe clock's name is assumed to be either usb3_phy_pipe_clk_src or pcie_XX_pipe_clk_src (where XX is the phy lane's number). However, this will not work if an SoC has more than one instance of the phy. Hence, instead of assuming the name of the clock, fetch it from the DT.

[PATCH v4 6/7] dt-bindings: pci: qcom: Add support for IPQ8074

Add support for the IPQ8074 PCIe controller. IPQ8074 supports Gen 1/2, one lane, two PCIe root complex with support for MSI and legacy interrupts, and it conforms to PCI Express Base 2.1 specification. Signed-off-by: Varadarajan Narayanan ---

[PATCH v4 3/7] phy: qcom-qmp: Fix phy pipe clock name

Presently, the phy pipe clock's name is assumed to be either usb3_phy_pipe_clk_src or pcie_XX_pipe_clk_src (where XX is the phy lane's number). However, this will not work if an SoC has more than one instance of the phy. Hence, instead of assuming the name of the clock, fetch it from the DT.

[PATCH v4 6/7] dt-bindings: pci: qcom: Add support for IPQ8074

Add support for the IPQ8074 PCIe controller. IPQ8074 supports Gen 1/2, one lane, two PCIe root complex with support for MSI and legacy interrupts, and it conforms to PCI Express Base 2.1 specification. Signed-off-by: Varadarajan Narayanan --- .../devicetree/bindings/pci/qcom,pcie.txt

[PATCH v4 4/7] phy: qcom-qmp: Add support for IPQ8074

Add definitions required to enable QMP phy support for IPQ8074. Signed-off-by: smuthayy Signed-off-by: Varadarajan Narayanan --- drivers/phy/qualcomm/phy-qcom-qmp.c | 124 1 file changed, 124 insertions(+)

[PATCH v4 2/7] dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074

IPQ8074 uses QMP phy controller that provides support to PCIe and USB. Adding dt binding information for the same. Signed-off-by: Varadarajan Narayanan --- Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 8 1 file changed, 8 insertions(+) diff --git

[PATCH v4 4/7] phy: qcom-qmp: Add support for IPQ8074

Add definitions required to enable QMP phy support for IPQ8074. Signed-off-by: smuthayy Signed-off-by: Varadarajan Narayanan --- drivers/phy/qualcomm/phy-qcom-qmp.c | 124 1 file changed, 124 insertions(+) diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c

[PATCH v4 2/7] dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074

IPQ8074 uses QMP phy controller that provides support to PCIe and USB. Adding dt binding information for the same. Signed-off-by: Varadarajan Narayanan --- Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 8 1 file changed, 8 insertions(+) diff --git

[PATCH v4 0/7] Add support for IPQ8074 PCIe phy and controller

v4: phy: qcom-qmp: Fix phy pipe clock name Based on Vivek's comments, return failure only for PCI/USB type of phys. Removed Ack. phy: qcom-qmp: Handle unavailable registers Removed this patch. Incorrectly used a block of code that is not applicable

[PATCH v4 0/7] Add support for IPQ8074 PCIe phy and controller

v4: phy: qcom-qmp: Fix phy pipe clock name Based on Vivek's comments, return failure only for PCI/USB type of phys. Removed Ack. phy: qcom-qmp: Handle unavailable registers Removed this patch. Incorrectly used a block of code that is not applicable

Re: [PATCH] x86/kernel/cpu/amd.c: don't apply the lahf_lm workaround in a hypervisor

On Thu, 13 Jul 2017, Borislav Petkov wrote: > On Wed, Jul 12, 2017 at 10:27:44PM -0400, Mikulas Patocka wrote: > > It is not strictly needed, but it is annoying. I work in the console and > > it is annoying to see these "unhandled rdmsr" messages printed over the > > screen every time I

Re: [PATCH] x86/kernel/cpu/amd.c: don't apply the lahf_lm workaround in a hypervisor

On Thu, 13 Jul 2017, Borislav Petkov wrote: > On Wed, Jul 12, 2017 at 10:27:44PM -0400, Mikulas Patocka wrote: > > It is not strictly needed, but it is annoying. I work in the console and > > it is annoying to see these "unhandled rdmsr" messages printed over the > > screen every time I

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Hi Ted, Snipping one comment: > Practically no one uses /dev/random. It's essentially a deprecated > interface; the primary interfaces that have been recommended for well > over a decade is /dev/urandom, and now, getrandom(2). We only need > 384 bits of randomness every 5 minutes to reseed the

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Hi Ted, Snipping one comment: > Practically no one uses /dev/random. It's essentially a deprecated > interface; the primary interfaces that have been recommended for well > over a decade is /dev/urandom, and now, getrandom(2). We only need > 384 bits of randomness every 5 minutes to reseed the

Re: bluetooth in v4.13-rc1: lock init missing somewhere?

Hi Pavel, >>> Is bluetooth expected to work on n900? >>> >>> It looks like lock init is missing somewhere: >>> >>> [ 402.901031] of_get_named_gpiod_flags: parsed >>> 'bluetooth-wakeup-gpios' property of node >>> '/ocp@6800/serial@4806c000/bluetooth[0]' - status (0) >>> [ 403.042022] BUG:

Re: bluetooth in v4.13-rc1: lock init missing somewhere?

Hi Pavel, >>> Is bluetooth expected to work on n900? >>> >>> It looks like lock init is missing somewhere: >>> >>> [ 402.901031] of_get_named_gpiod_flags: parsed >>> 'bluetooth-wakeup-gpios' property of node >>> '/ocp@6800/serial@4806c000/bluetooth[0]' - status (0) >>> [ 403.042022] BUG:

Re: [PATCH v3 3/9] perf annotate: Fix wrong --show-total-period option showing number of samples

Em Fri, Jul 21, 2017 at 06:41:29PM +0900, Taeung Song escreveu: > On 07/21/2017 04:19 AM, Arnaldo Carvalho de Melo wrote: > > Em Thu, Jul 20, 2017 at 06:36:55AM +0900, Taeung Song escreveu: > > > Currently the --show-total-period option of perf-annotate > > > is different from perf-report's. > >

Re: [PATCH v3 3/9] perf annotate: Fix wrong --show-total-period option showing number of samples

Em Fri, Jul 21, 2017 at 06:41:29PM +0900, Taeung Song escreveu: > On 07/21/2017 04:19 AM, Arnaldo Carvalho de Melo wrote: > > Em Thu, Jul 20, 2017 at 06:36:55AM +0900, Taeung Song escreveu: > > > Currently the --show-total-period option of perf-annotate > > > is different from perf-report's. > >

<    5   6   7   8   9   10   11   12   13   14   >