Re: [PATCH v7 7/8] uapi: export all headers under uapi directories

Le 24/02/2017 à 17:49, Nicolas Dichtel a écrit : > Regularly, when a new header is created in include/uapi/, the developer > forgets to add it in the corresponding Kbuild file. This error is usually > detected after the release is out. > > In fact, all headers under uapi directories should be

Re: [PATCH v7 7/8] uapi: export all headers under uapi directories

Le 24/02/2017 à 17:49, Nicolas Dichtel a écrit : > Regularly, when a new header is created in include/uapi/, the developer > forgets to add it in the corresponding Kbuild file. This error is usually > detected after the release is out. > > In fact, all headers under uapi directories should be

Re: [RFC PATCH 0/2] mtd: spi-nor: Handle vmalloc'd buffers

On 27/02/2017 13:08, Vignesh R wrote: > This series implements bounce buffer support to handle vmalloc'd buffers > in case of drivers use DMA, similar to what is done in MTD NAND > framework. > > I have tested this on two platform: > DRA74 SoC (cortex a15 @1GHz) with s25fl256s1 QSPI (SPI bus

Re: [RFC PATCH 0/2] mtd: spi-nor: Handle vmalloc'd buffers

On 27/02/2017 13:08, Vignesh R wrote: > This series implements bounce buffer support to handle vmalloc'd buffers > in case of drivers use DMA, similar to what is done in MTD NAND > framework. > > I have tested this on two platform: > DRA74 SoC (cortex a15 @1GHz) with s25fl256s1 QSPI (SPI bus

Re: [RFT 0/4] mfd: regulator: max14577: Remove support for platform data

On Monday, February 27, 2017 05:32:37 PM Krzysztof Kozlowski wrote: > On Mon, Feb 27, 2017 at 2:55 PM, Bartlomiej Zolnierkiewicz > wrote: > > > > Hi, > > > > On Friday, February 17, 2017 10:01:56 PM Krzysztof Kozlowski wrote: > >> Hi, > >> > >> Minor cleanup of max14577

Re: [RFT 0/4] mfd: regulator: max14577: Remove support for platform data

On Monday, February 27, 2017 05:32:37 PM Krzysztof Kozlowski wrote: > On Mon, Feb 27, 2017 at 2:55 PM, Bartlomiej Zolnierkiewicz > wrote: > > > > Hi, > > > > On Friday, February 17, 2017 10:01:56 PM Krzysztof Kozlowski wrote: > >> Hi, > >> > >> Minor cleanup of max14577 family of drivers. The

Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API

On Mon, 2017-02-27 at 13:52 +0100, Romain Perier wrote: > > I also wonder if you've in fact converted all of the > > pci_pool struct and function uses why a new checkpatch > > test is needed at all. > > That's just to avoid futures mistakes/uses. When all instances and macro definitions are

Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API

On Mon, 2017-02-27 at 13:52 +0100, Romain Perier wrote: > > I also wonder if you've in fact converted all of the > > pci_pool struct and function uses why a new checkpatch > > test is needed at all. > > That's just to avoid futures mistakes/uses. When all instances and macro definitions are

Re: [PATCH] asm-generic: Force cast get_user() setting x to 0

On Sat, Feb 25, 2017 at 2:24 AM, Stephen Boyd wrote: > Quoting Stephen Boyd (2017-02-17 08:52:29) >> If we call get_user() with an __le* or __be* type sparse will >> complain when we assign the result to 0 on the faulting path. >> Let's force cast here so that sparse

Re: [PATCH] asm-generic: Force cast get_user() setting x to 0

On Sat, Feb 25, 2017 at 2:24 AM, Stephen Boyd wrote: > Quoting Stephen Boyd (2017-02-17 08:52:29) >> If we call get_user() with an __le* or __be* type sparse will >> complain when we assign the result to 0 on the faulting path. >> Let's force cast here so that sparse doesn't complain. This >>

Hallo

Sehr geehrter, Mit Respekt und Menschlichkeit war ich gezwungen, Ihnen unter einem humanitären Grund zu schreiben. Mein Name ist Frau Joanna Diane Christopher, und ich bin mit Herrn Bakayoko Christopher Direktor J.C Industries in der Elfenbeinküste verheiratet. Wir waren seit 16 Jahren ohne

Hallo

Sehr geehrter, Mit Respekt und Menschlichkeit war ich gezwungen, Ihnen unter einem humanitären Grund zu schreiben. Mein Name ist Frau Joanna Diane Christopher, und ich bin mit Herrn Bakayoko Christopher Direktor J.C Industries in der Elfenbeinküste verheiratet. Wir waren seit 16 Jahren ohne

Re: [PATCHv4] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

Hi Abel, On Fri, Feb 24 2017, Abel Vesa wrote: > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index fda6a46..877df5b 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -55,6 +55,7 @@ config ARM > select HAVE_DMA_API_DEBUG > select HAVE_DMA_CONTIGUOUS if MMU >

Re: [PATCHv4] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

Hi Abel, On Fri, Feb 24 2017, Abel Vesa wrote: > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index fda6a46..877df5b 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -55,6 +55,7 @@ config ARM > select HAVE_DMA_API_DEBUG > select HAVE_DMA_CONTIGUOUS if MMU >

Re: [bpf] 9d876e79df: BUG: unable to handle kernel paging request at 653a8346

On 02/27/2017 03:14 AM, kernel test robot wrote: Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master I'll take a look, thanks for the report!

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 12:25:10, Heiko Carstens wrote: > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: > > A couple of other thoughts: > > 1) Having all newly added memory online ASAP is probably what people > > want for all virtual machines. > > This is not true for s390. On s390 we

Re: [bpf] 9d876e79df: BUG: unable to handle kernel paging request at 653a8346

On 02/27/2017 03:14 AM, kernel test robot wrote: Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master I'll take a look, thanks for the report!

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 12:25:10, Heiko Carstens wrote: > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: > > A couple of other thoughts: > > 1) Having all newly added memory online ASAP is probably what people > > want for all virtual machines. > > This is not true for s390. On s390 we

Re: next-20170217 boot on POWER8 LPAR : WARNING @kernel/jump_label.c:287

On Tue, 21 Feb 2017 11:37:21 -0500 Jason Baron wrote: > Thanks for testing. We probably need something like the following to > make sure we don't hit this on other arches. Steve - I will send 4 > separate patches for this to get arch maintainers' acks for this? > I just

Re: [PATCH 5/9] Staging: rtl8712: rtl871x_mp_ioctl.h - style fix

On Sun, Feb 26, 2017 at 03:32:08PM +1300, Derek Robson wrote: > Fixed style of block comments > Found using checkpatch > > Signed-off-by: Derek Robson > --- > drivers/staging/rtl8712/rtl871x_mp_ioctl.h | 32 > +++--- > 1 file changed, 16

Re: next-20170217 boot on POWER8 LPAR : WARNING @kernel/jump_label.c:287

On Tue, 21 Feb 2017 11:37:21 -0500 Jason Baron wrote: > Thanks for testing. We probably need something like the following to > make sure we don't hit this on other arches. Steve - I will send 4 > separate patches for this to get arch maintainers' acks for this? > I just got back from ELC,

Re: [PATCH 5/9] Staging: rtl8712: rtl871x_mp_ioctl.h - style fix

On Sun, Feb 26, 2017 at 03:32:08PM +1300, Derek Robson wrote: > Fixed style of block comments > Found using checkpatch > > Signed-off-by: Derek Robson > --- > drivers/staging/rtl8712/rtl871x_mp_ioctl.h | 32 > +++--- > 1 file changed, 16 insertions(+), 16 deletions(-) >

Re: [RFT 0/4] mfd: regulator: max14577: Remove support for platform data

On Mon, Feb 27, 2017 at 2:55 PM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Friday, February 17, 2017 10:01:56 PM Krzysztof Kozlowski wrote: >> Hi, >> >> Minor cleanup of max14577 family of drivers. The dependency inside: >> 1. Patch #3 and #4 depends for safeness

Re: [RFT 0/4] mfd: regulator: max14577: Remove support for platform data

On Mon, Feb 27, 2017 at 2:55 PM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Friday, February 17, 2017 10:01:56 PM Krzysztof Kozlowski wrote: >> Hi, >> >> Minor cleanup of max14577 family of drivers. The dependency inside: >> 1. Patch #3 and #4 depends for safeness on #1 so no one would try

[GIT PULL] tracing: One more small update for 4.11

Linus, Commit 79c6f448c8b79c ("tracing: Fix hwlat kthread migration") fixed a bug that was caused by a race condition in initializing the hwlat thread. When fixing this code, I realized that it should have been done differently. Instead of doing the rewrite and sending that to stable, I just

[GIT PULL] tracing: One more small update for 4.11

Linus, Commit 79c6f448c8b79c ("tracing: Fix hwlat kthread migration") fixed a bug that was caused by a race condition in initializing the hwlat thread. When fixing this code, I realized that it should have been done differently. Instead of doing the rewrite and sending that to stable, I just

Re: linux-next: build failure after merge of the scsi-mkp tree

On Mon, 2017-02-27 at 12:54 +1100, Stephen Rothwell wrote: > Hi James, > > On Thu, 23 Feb 2017 08:06:39 +1100 Stephen Rothwell < > s...@canb.auug.org.au> wrote: > > > > On Wed, 22 Feb 2017 13:41:19 +1100 Stephen Rothwell < > > s...@canb.auug.org.au> wrote: > > > > > > After merging the scsi-mkp

Re: linux-next: build failure after merge of the scsi-mkp tree

On Mon, 2017-02-27 at 12:54 +1100, Stephen Rothwell wrote: > Hi James, > > On Thu, 23 Feb 2017 08:06:39 +1100 Stephen Rothwell < > s...@canb.auug.org.au> wrote: > > > > On Wed, 22 Feb 2017 13:41:19 +1100 Stephen Rothwell < > > s...@canb.auug.org.au> wrote: > > > > > > After merging the scsi-mkp

Re: [WARNING: A/V UNSCANNABLE][Merge tag 'media/v4.11-1' of git] ff58d005cd: BUG: unable to handle kernel NULL pointer dereference at 0000039c

* Thomas Gleixner wrote: > The pending interrupt issue happens, at least on my test boxen, mostly on > the 'legacy' interrupts (0 - 15). But even the IOAPIC interrupts >=16 > happen occasionally. > > > - Spurious interrupts on IRQ7, which are triggered by IRQ 0 (PIT/HPET).

Re: [PATCH v2 01/17] dt-bindings: Add vendor prefix for Actions Semi

Am 24.02.2017 um 04:40 schrieb Andreas Färber: > Actions Semiconductor was listed on NASDAQ as ACTS until Dec 16, 2016. > > Cc: mp...@actions-semi.com > Signed-off-by: Andreas Färber > --- > v1 -> v2: > * Reverted from "acts" to "actions" (cf. IAP140 "mrvl" vs. "marvell") >

Re: [WARNING: A/V UNSCANNABLE][Merge tag 'media/v4.11-1' of git] ff58d005cd: BUG: unable to handle kernel NULL pointer dereference at 0000039c

* Thomas Gleixner wrote: > The pending interrupt issue happens, at least on my test boxen, mostly on > the 'legacy' interrupts (0 - 15). But even the IOAPIC interrupts >=16 > happen occasionally. > > > - Spurious interrupts on IRQ7, which are triggered by IRQ 0 (PIT/HPET). On >one of the

Re: [PATCH v2 01/17] dt-bindings: Add vendor prefix for Actions Semi

Am 24.02.2017 um 04:40 schrieb Andreas Färber: > Actions Semiconductor was listed on NASDAQ as ACTS until Dec 16, 2016. > > Cc: mp...@actions-semi.com > Signed-off-by: Andreas Färber > --- > v1 -> v2: > * Reverted from "acts" to "actions" (cf. IAP140 "mrvl" vs. "marvell") > >

Re: net/bridge: warning in br_fdb_find

On Mon, Feb 27, 2017 at 4:33 PM, Andrey Konovalov wrote: > Hi, > > I'm getting a huge number of warning reports while fuzzing the kernel > with syzkaller. > Unfortunately they are not reproducible. > > On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26). > > My

Re: net/bridge: warning in br_fdb_find

On Mon, Feb 27, 2017 at 4:33 PM, Andrey Konovalov wrote: > Hi, > > I'm getting a huge number of warning reports while fuzzing the kernel > with syzkaller. > Unfortunately they are not reproducible. > > On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26). > > My .config is attached. > >

[PATCH] lockdep: Fix compilation error for !CONFIG_MODULES and !CONFIG_SMP

From: Dan Murphy When CONFIG_MODULES is not set then it fails to compile in lockdep: |kernel/locking/lockdep.c: In function 'look_up_lock_class': |kernel/locking/lockdep.c:684:12: error: implicit declaration of function | '__is_module_percpu_address'

[PATCH] lockdep: Fix compilation error for !CONFIG_MODULES and !CONFIG_SMP

From: Dan Murphy When CONFIG_MODULES is not set then it fails to compile in lockdep: |kernel/locking/lockdep.c: In function 'look_up_lock_class': |kernel/locking/lockdep.c:684:12: error: implicit declaration of function | '__is_module_percpu_address' [-Werror=implicit-function-declaration] If

Re: [PATCH v1 1/2] coresight: bindings for debug module

Hi Mike, On Mon, Feb 27, 2017 at 12:37:45PM +, Mike Leach wrote: > Hi Leo > > On 23 February 2017 at 01:57, Leo Yan wrote: > > According to ARMv8 architecture reference manual (ARM DDI 0487A.k) > > Chapter 'Part H: External debug', the CPU can integrate debug module > >

Re: tip.today - scheduler bam boom crash (cpu hotplug)

On 27/02/2017 14:04, Peter Zijlstra wrote: This results in sched clock always unstable for kvm guest since there is no invariant tsc cpuid bit exposed for kvm guest currently. >>> What the heck is KVM_FEATURE_CLOCKSOURCE_STABLE_BIT / >>> PVCLOCK_TSC_STABLE_BIT about then? >> It checks

Re: [PATCH v1 1/2] coresight: bindings for debug module

Hi Mike, On Mon, Feb 27, 2017 at 12:37:45PM +, Mike Leach wrote: > Hi Leo > > On 23 February 2017 at 01:57, Leo Yan wrote: > > According to ARMv8 architecture reference manual (ARM DDI 0487A.k) > > Chapter 'Part H: External debug', the CPU can integrate debug module > > and it can support

Re: tip.today - scheduler bam boom crash (cpu hotplug)

On 27/02/2017 14:04, Peter Zijlstra wrote: This results in sched clock always unstable for kvm guest since there is no invariant tsc cpuid bit exposed for kvm guest currently. >>> What the heck is KVM_FEATURE_CLOCKSOURCE_STABLE_BIT / >>> PVCLOCK_TSC_STABLE_BIT about then? >> It checks

[PATCH v2] lockdep: Handle statically initialized PER_CPU locks proper

From: Thomas Gleixner If a PER_CPU struct which contains a spin_lock is statically initialized via: DEFINE_PER_CPU(struct foo, bla) = { .lock = __SPIN_LOCK_UNLOCKED(bla.lock) }; then lockdep assigns a seperate key to each lock because the logic for assigning a key

[PATCH v2] lockdep: Handle statically initialized PER_CPU locks proper

From: Thomas Gleixner If a PER_CPU struct which contains a spin_lock is statically initialized via: DEFINE_PER_CPU(struct foo, bla) = { .lock = __SPIN_LOCK_UNLOCKED(bla.lock) }; then lockdep assigns a seperate key to each lock because the logic for assigning a key to statically

Re: [PATCH v2 3/3] percpu: improve allocation success rate for non-GFP_KERNEL callers

On Mon 27-02-17 05:00:31, Tahsin Erdogan wrote: > On Mon, Feb 27, 2017 at 1:52 AM, Michal Hocko wrote: > > On Sat 25-02-17 20:38:29, Tahsin Erdogan wrote: > >> When pcpu_alloc() is called with gfp != GFP_KERNEL, the likelihood of > >> a failure is higher than GFP_KERNEL case.

Re: [PATCH v2 3/3] percpu: improve allocation success rate for non-GFP_KERNEL callers

On Mon 27-02-17 05:00:31, Tahsin Erdogan wrote: > On Mon, Feb 27, 2017 at 1:52 AM, Michal Hocko wrote: > > On Sat 25-02-17 20:38:29, Tahsin Erdogan wrote: > >> When pcpu_alloc() is called with gfp != GFP_KERNEL, the likelihood of > >> a failure is higher than GFP_KERNEL case. This is mainly

Re: [PATCH v2 1/2] dt-bindings: arm: hisilicon: add bindings for hi3798cv200 SoC and Poplar board

Hi, Am 27.02.2017 um 03:48 schrieb Alex Elder: > On 02/26/2017 07:24 PM, Jiancheng Xue wrote: >> On 2017/2/26 9:32, Andreas Färber wrote: >>> Am 22.02.2017 um 09:38 schrieb Jiancheng Xue: Add bindings for HiSilicon hi3798cv200 SoC and Poplar Board. Signed-off-by: Jiancheng Xue

Re: [PATCH v2 1/2] dt-bindings: arm: hisilicon: add bindings for hi3798cv200 SoC and Poplar board

Hi, Am 27.02.2017 um 03:48 schrieb Alex Elder: > On 02/26/2017 07:24 PM, Jiancheng Xue wrote: >> On 2017/2/26 9:32, Andreas Färber wrote: >>> Am 22.02.2017 um 09:38 schrieb Jiancheng Xue: Add bindings for HiSilicon hi3798cv200 SoC and Poplar Board. Signed-off-by: Jiancheng Xue

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 11:49:43, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Mon 27-02-17 11:02:09, Vitaly Kuznetsov wrote: > > [...] > >> I don't have anything new to add to the discussion happened last week > >> but I'd like to summarize my arguments against this

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 11:49:43, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Mon 27-02-17 11:02:09, Vitaly Kuznetsov wrote: > > [...] > >> I don't have anything new to add to the discussion happened last week > >> but I'd like to summarize my arguments against this change: > >> > >> 1)

[PATCH] sd: close hole in > 2T device rejection when !CONFIG_LBDAF

When the kernel is compiled _without_ support for large (>= 2TiB) block devices, code in the sd driver's read_capacity() routines rejects devices whose count of native-sized blocks does not fit in the 32 bit sector_t type. A device reporting 4294967296 512-byte blocks will be rejected, but a

[PATCH] sd: close hole in > 2T device rejection when !CONFIG_LBDAF

When the kernel is compiled _without_ support for large (>= 2TiB) block devices, code in the sd driver's read_capacity() routines rejects devices whose count of native-sized blocks does not fit in the 32 bit sector_t type. A device reporting 4294967296 512-byte blocks will be rejected, but a

Re: [PATCH V5 4/6] mm: reclaim MADV_FREE pages

On Fri 24-02-17 13:31:47, Shaohua Li wrote: > When memory pressure is high, we free MADV_FREE pages. If the pages are > not dirty in pte, the pages could be freed immediately. Otherwise we > can't reclaim them. We put the pages back to anonumous LRU list (by > setting SwapBacked flag) and the

Re: [PATCH V5 4/6] mm: reclaim MADV_FREE pages

On Fri 24-02-17 13:31:47, Shaohua Li wrote: > When memory pressure is high, we free MADV_FREE pages. If the pages are > not dirty in pte, the pages could be freed immediately. Otherwise we > can't reclaim them. We put the pages back to anonumous LRU list (by > setting SwapBacked flag) and the

Re: [PATCH 1/2] drivers: pwm: pwm-atmel: add support for pwm on sama5d2

Hi, Please ignore this patch also. I will resend it after switching to atomic PWM. Thank you, Claudiu Beznea On 23.02.2017 11:16, Alexandre Belloni wrote: > On 23/02/2017 at 10:38:39 +0200, Claudiu Beznea wrote: >> Enable PWM on sama5d2 by adding atmel_pwm_config_v3(). >> This, simply, sets the

Re: [PATCH 1/2] drivers: pwm: pwm-atmel: add support for pwm on sama5d2

Hi, Please ignore this patch also. I will resend it after switching to atomic PWM. Thank you, Claudiu Beznea On 23.02.2017 11:16, Alexandre Belloni wrote: > On 23/02/2017 at 10:38:39 +0200, Claudiu Beznea wrote: >> Enable PWM on sama5d2 by adding atmel_pwm_config_v3(). >> This, simply, sets the

Re: [PATCH 1/2] dt-bindings: iio: stm32-adc: add option to set resolution

On Fri, Feb 24, 2017 at 05:04:45PM +0100, Fabrice Gasnier wrote: > On 02/19/2017 01:09 PM, Jonathan Cameron wrote: > > On 15/02/17 16:55, Fabrice Gasnier wrote: > > > Add documentation for 'st,adc-res' dt optional property. > > > > > > Signed-off-by: Fabrice Gasnier > >

Re: [PATCH 1/2] dt-bindings: iio: stm32-adc: add option to set resolution

On Fri, Feb 24, 2017 at 05:04:45PM +0100, Fabrice Gasnier wrote: > On 02/19/2017 01:09 PM, Jonathan Cameron wrote: > > On 15/02/17 16:55, Fabrice Gasnier wrote: > > > Add documentation for 'st,adc-res' dt optional property. > > > > > > Signed-off-by: Fabrice Gasnier > > I'm happy with this, but

[GIT PULL] tracing: Updates for 4.11

Linus, This release has no new tracing features, just clean ups, minor fixes and small optimizations. Please pull the latest trace-v4.11 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-v4.11 Tag SHA1:

[GIT PULL] tracing: Updates for 4.11

Linus, This release has no new tracing features, just clean ups, minor fixes and small optimizations. Please pull the latest trace-v4.11 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-v4.11 Tag SHA1:

Re: [PATCH V5 5/6] mm: enable MADV_FREE for swapless system

On Fri 24-02-17 13:31:48, Shaohua Li wrote: > Now MADV_FREE pages can be easily reclaimed even for swapless system. We > can safely enable MADV_FREE for all systems. > > Cc: Michal Hocko > Cc: Minchan Kim > Cc: Hugh Dickins > Cc: Rik van

Re: [PATCH V5 5/6] mm: enable MADV_FREE for swapless system

On Fri 24-02-17 13:31:48, Shaohua Li wrote: > Now MADV_FREE pages can be easily reclaimed even for swapless system. We > can safely enable MADV_FREE for all systems. > > Cc: Michal Hocko > Cc: Minchan Kim > Cc: Hugh Dickins > Cc: Rik van Riel > Cc: Mel Gorman > Cc: Andrew Morton > Acked-by:

[PATCH 07/20] PCI: implement Devres interface to map PCI config space

The introduction of the pci_remap_cfgspace() interface allows PCI host controller drivers to map PCI config space through a dedicated kernel interface. Current PCI host controller drivers use the devm_ioremap_* Devres interfaces to map PCI configuration space regions so in order to update them to

[PATCH 07/20] PCI: implement Devres interface to map PCI config space

The introduction of the pci_remap_cfgspace() interface allows PCI host controller drivers to map PCI config space through a dedicated kernel interface. Current PCI host controller drivers use the devm_ioremap_* Devres interfaces to map PCI configuration space regions so in order to update them to

[PATCH 09/20] PCI: xilinx-nwl: update PCI config space remap function

PCI configuration space should be mapped with a memory region type that generates on the CPU host bus non-posted write transations. Update the driver to use the devm_pci_remap_cfg* interface to make sure the correct memory mappings for PCI configuration space are used. Signed-off-by: Lorenzo

[PATCH 09/20] PCI: xilinx-nwl: update PCI config space remap function

PCI configuration space should be mapped with a memory region type that generates on the CPU host bus non-posted write transations. Update the driver to use the devm_pci_remap_cfg* interface to make sure the correct memory mappings for PCI configuration space are used. Signed-off-by: Lorenzo

[PATCH 05/20] ARM: implement pci_remap_cfgspace() interface

The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering and Posting") define rules for PCI configuration space transactions ordering and posting, that state that configuration writes have to be non-posted transactions. Current ioremap interface on ARM provides mapping functions that

[PATCH 06/20] PCI: ECAM: use pci_remap_cfgspace() to map config region

Current ECAM kernel implementation uses ioremap() to map the ECAM configuration space memory region; this is not safe in that on some architectures the ioremap interface provides mappings that allow posted write transactions. This, as highlighted in the PCIe specifications (4.0 - Rev0.3, "Ordering

[PATCH 05/20] ARM: implement pci_remap_cfgspace() interface

The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering and Posting") define rules for PCI configuration space transactions ordering and posting, that state that configuration writes have to be non-posted transactions. Current ioremap interface on ARM provides mapping functions that

[PATCH 06/20] PCI: ECAM: use pci_remap_cfgspace() to map config region

Current ECAM kernel implementation uses ioremap() to map the ECAM configuration space memory region; this is not safe in that on some architectures the ioremap interface provides mappings that allow posted write transactions. This, as highlighted in the PCIe specifications (4.0 - Rev0.3, "Ordering

[PATCH 08/20] PCI: xilinx: update PCI config space remap function

PCI configuration space should be mapped with a memory region type that generates on the CPU host bus non-posted write transations. Update the driver to use the devm_pci_remap_cfg* interface to make sure the correct memory mappings for PCI configuration space are used. Signed-off-by: Lorenzo

[PATCH 08/20] PCI: xilinx: update PCI config space remap function

PCI configuration space should be mapped with a memory region type that generates on the CPU host bus non-posted write transations. Update the driver to use the devm_pci_remap_cfg* interface to make sure the correct memory mappings for PCI configuration space are used. Signed-off-by: Lorenzo

[PATCH 10/20] PCI: spear13xx: update PCI config space remap function

PCI configuration space should be mapped with a memory region type that generate on the CPU host bus non-posted write transations. Update the driver to use the devm_pci_remap_cfg* interface to make sure the correct memory mappings for PCI configuration space are used. Signed-off-by: Lorenzo

[PATCH 10/20] PCI: spear13xx: update PCI config space remap function

PCI configuration space should be mapped with a memory region type that generate on the CPU host bus non-posted write transations. Update the driver to use the devm_pci_remap_cfg* interface to make sure the correct memory mappings for PCI configuration space are used. Signed-off-by: Lorenzo

[PATCH 1/4] fpga: fix sparse warnings in fpga-mgr and fpga-bridge

From: Dinh Nguyen Fix up these sparse warnings: drivers/fpga/fpga-mgr.c:189:21: warning: symbol '__fpga_mgr_get' was not declared. Should it be static? drivers/fpga/fpga-bridge.c:30:12: warning: symbol 'bridge_list_lock' was not declared. Should it be static?

[PATCH 02/20] PCI: fix pci_remap_iospace() remap attribute

According to the PCI local bus specifications (Revision 3.0, 3.2.5), I/O Address space transactions are non-posted. On architectures where I/O space is implemented through a chunk of memory mapped space mapped to PCI address space (ie IA64/ARM/ARM64) the memory mapping for the region backing I/O

[PATCH 1/4] fpga: fix sparse warnings in fpga-mgr and fpga-bridge

From: Dinh Nguyen Fix up these sparse warnings: drivers/fpga/fpga-mgr.c:189:21: warning: symbol '__fpga_mgr_get' was not declared. Should it be static? drivers/fpga/fpga-bridge.c:30:12: warning: symbol 'bridge_list_lock' was not declared. Should it be static? Signed-off-by: Dinh Nguyen

[PATCH 02/20] PCI: fix pci_remap_iospace() remap attribute

According to the PCI local bus specifications (Revision 3.0, 3.2.5), I/O Address space transactions are non-posted. On architectures where I/O space is implemented through a chunk of memory mapped space mapped to PCI address space (ie IA64/ARM/ARM64) the memory mapping for the region backing I/O

[PATCH 01/20] PCI: remove __weak tag from pci_remap_iospace()

pci_remap_iospace() is marked as a weak symbol even though no architecture is currently overriding it; given that its implementation internals have already code paths that are arch specific (ie PCI_IOBASE and ioremap_page_range() attributes) there is no need to leave the weak symbol in the kernel

[PATCH 01/20] PCI: remove __weak tag from pci_remap_iospace()

pci_remap_iospace() is marked as a weak symbol even though no architecture is currently overriding it; given that its implementation internals have already code paths that are arch specific (ie PCI_IOBASE and ioremap_page_range() attributes) there is no need to leave the weak symbol in the kernel

[PATCH 0/4] fpga: zynq: encrypted bitstreams plus one

Hi Greg, Please take these patches that have been reviewed on the lkml and linux-fpga lists. Dihn's patch fixes minor sparse warnings. Moritz's patch adds some functionality for Zynq. Thanks, Alan Dinh Nguyen (1): fpga: fix sparse warnings in fpga-mgr and fpga-bridge Moritz Fischer (3):

[PATCH 3/4] fpga: zynq: Add support for encrypted bitstreams

From: Moritz Fischer Add support for encrypted bitstreams. For this to work the system must be booted in secure mode. In order for on-the-fly decryption to work, the PCAP clock rate needs to be lowered via the PCAP_RATE_EN bit. Signed-off-by: Moritz Fischer

[PATCH 2/4] fpga: Add flag to indicate bitstream needs decrypting

From: Moritz Fischer Add a flag that is passed to the write_init() callback, indicating that the bitstream is encrypted. The low-level driver will deal with the flag, or return an error, if encrypted bitstreams are not supported. Signed-off-by: Moritz Fischer

[PATCH 0/4] fpga: zynq: encrypted bitstreams plus one

Hi Greg, Please take these patches that have been reviewed on the lkml and linux-fpga lists. Dihn's patch fixes minor sparse warnings. Moritz's patch adds some functionality for Zynq. Thanks, Alan Dinh Nguyen (1): fpga: fix sparse warnings in fpga-mgr and fpga-bridge Moritz Fischer (3):

[PATCH 3/4] fpga: zynq: Add support for encrypted bitstreams

From: Moritz Fischer Add support for encrypted bitstreams. For this to work the system must be booted in secure mode. In order for on-the-fly decryption to work, the PCAP clock rate needs to be lowered via the PCAP_RATE_EN bit. Signed-off-by: Moritz Fischer Acked-by: Michal Simek

[PATCH 2/4] fpga: Add flag to indicate bitstream needs decrypting

From: Moritz Fischer Add a flag that is passed to the write_init() callback, indicating that the bitstream is encrypted. The low-level driver will deal with the flag, or return an error, if encrypted bitstreams are not supported. Signed-off-by: Moritz Fischer Acked-by: Michal Simek

[PATCH 4/4] fpga: region: Add fpga-region property 'encrypted-fpga-config'

From: Moritz Fischer Add fpga-region property to allow passing the fact that the bitstream is encrypted to the fpga-region and ultimately to the low-level driver. Signed-off-by: Moritz Fischer Acked-by: Michal Simek Signed-off-by:

[PATCH 4/4] fpga: region: Add fpga-region property 'encrypted-fpga-config'

From: Moritz Fischer Add fpga-region property to allow passing the fact that the bitstream is encrypted to the fpga-region and ultimately to the low-level driver. Signed-off-by: Moritz Fischer Acked-by: Michal Simek Signed-off-by: Alan Tull ---

[PATCH 11/20] PCI: rockchip: update PCI config space remap function

PCI configuration space should be mapped with a memory region type that generates on the CPU host bus non-posted write transations. Update the driver to use the devm_pci_remap_cfg* interface to make sure the correct memory mappings for PCI configuration space are used. Signed-off-by: Lorenzo

Re: [PATCH V11 10/10] arm/arm64: KVM: add guest SEA support

Hi Wang Xiongfeng, On 25/02/17 07:15, Xiongfeng Wang wrote: > On 2017/2/22 5:22, Tyler Baicar wrote: >> Currently external aborts are unsupported by the guest abort >> handling. Add handling for SEAs so that the host kernel reports >> SEAs which occur in the guest kernel. >> diff --git

Re: [PATCH V11 10/10] arm/arm64: KVM: add guest SEA support

Hi Wang Xiongfeng, On 25/02/17 07:15, Xiongfeng Wang wrote: > On 2017/2/22 5:22, Tyler Baicar wrote: >> Currently external aborts are unsupported by the guest abort >> handling. Add handling for SEAs so that the host kernel reports >> SEAs which occur in the guest kernel. >> diff --git

[PATCH 11/20] PCI: rockchip: update PCI config space remap function

PCI configuration space should be mapped with a memory region type that generates on the CPU host bus non-posted write transations. Update the driver to use the devm_pci_remap_cfg* interface to make sure the correct memory mappings for PCI configuration space are used. Signed-off-by: Lorenzo

[PATCH 03/20] asm-generic/io.h: add PCI config space remap interface

The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and Posting") mandate non-posted configuration transactions. As further highlighted in the PCIe specifications (4.0 - Rev0.3, "Ordering Considerations for the Enhanced Configuration Access Mechanism"), through ECAM and ECAM-derivative

[PATCH 03/20] asm-generic/io.h: add PCI config space remap interface

The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and Posting") mandate non-posted configuration transactions. As further highlighted in the PCIe specifications (4.0 - Rev0.3, "Ordering Considerations for the Enhanced Configuration Access Mechanism"), through ECAM and ECAM-derivative

[PATCH 04/20] ARM64: implement pci_remap_cfgspace() interface

The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering and Posting") defines rules for PCI configuration space transactions ordering and posting, that state that configuration writes are non-posted transactions. This rule is reinforced by the ARM v8 architecture reference manual (issue

[PATCH 12/20] PCI: qcom: update PCI config space remap function

PCI configuration space should be mapped with a memory region type that generates on the CPU host bus non-posted write transations. Update the driver to use the devm_pci_remap_cfg* interface to make sure the correct memory mappings for PCI configuration space are used. Signed-off-by: Lorenzo

[PATCH 04/20] ARM64: implement pci_remap_cfgspace() interface

The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering and Posting") defines rules for PCI configuration space transactions ordering and posting, that state that configuration writes are non-posted transactions. This rule is reinforced by the ARM v8 architecture reference manual (issue

[PATCH 12/20] PCI: qcom: update PCI config space remap function

PCI configuration space should be mapped with a memory region type that generates on the CPU host bus non-posted write transations. Update the driver to use the devm_pci_remap_cfg* interface to make sure the correct memory mappings for PCI configuration space are used. Signed-off-by: Lorenzo

[PATCH 13/20] PCI: iproc-platform: update PCI config space remap function

PCI configuration space should be mapped with a memory region type that generates on the CPU host bus non-posted write transations. Update the driver to use the devm_pci_remap_cfg* interface to make sure the correct memory mappings for PCI configuration space are used. Signed-off-by: Lorenzo

[PATCH 1/2] powerpc/mm: Handle protnone ptes on fork

We need mark pages of parent process read only on fork. Numa fault pte needs a protnone ptes variant with saved write flag set. On fork we need to make sure we remove the saved write bit. Instead of adding the protnone check in the caller update ptep_set_wrprotect variants to clear savedwrite bit.

[PATCH 13/20] PCI: iproc-platform: update PCI config space remap function

PCI configuration space should be mapped with a memory region type that generates on the CPU host bus non-posted write transations. Update the driver to use the devm_pci_remap_cfg* interface to make sure the correct memory mappings for PCI configuration space are used. Signed-off-by: Lorenzo

[PATCH 1/2] powerpc/mm: Handle protnone ptes on fork

We need mark pages of parent process read only on fork. Numa fault pte needs a protnone ptes variant with saved write flag set. On fork we need to make sure we remove the saved write bit. Instead of adding the protnone check in the caller update ptep_set_wrprotect variants to clear savedwrite bit.

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