Re: [PATCH v4 1/6] ARM: at91: add TCB registers definitions

On 2018-04-18 12:51:38 [+0200], Alexandre Belloni wrote: > diff --git a/include/soc/at91/atmel_tcb.h b/include/soc/at91/atmel_tcb.h > new file mode 100644 > index ..d263ea677225 > --- /dev/null > +++ b/include/soc/at91/atmel_tcb.h … > +static inline struct clk *tcb_clk_get(struct

Re: [PATCH v4 1/6] ARM: at91: add TCB registers definitions

On 2018-04-18 12:51:38 [+0200], Alexandre Belloni wrote: > diff --git a/include/soc/at91/atmel_tcb.h b/include/soc/at91/atmel_tcb.h > new file mode 100644 > index ..d263ea677225 > --- /dev/null > +++ b/include/soc/at91/atmel_tcb.h … > +static inline struct clk *tcb_clk_get(struct

Re: [PATCH v4 1/5] efi: Export boot-services code and data as debugfs-blobs

On 26 April 2018 at 14:06, Hans de Goede wrote: > Sometimes it is useful to be able to dump the efi boot-services code and > data. This commit adds these as debugfs-blobs to /sys/kernel/debug/efi, > but only if efi=debug is passed on the kernel-commandline as this requires >

Re: [PATCH v4 1/5] efi: Export boot-services code and data as debugfs-blobs

On 26 April 2018 at 14:06, Hans de Goede wrote: > Sometimes it is useful to be able to dump the efi boot-services code and > data. This commit adds these as debugfs-blobs to /sys/kernel/debug/efi, > but only if efi=debug is passed on the kernel-commandline as this requires > not freeing those

Re: [PATCH net-next 1/2 v2] netns: restrict uevents

Christian Brauner writes: > On Tue, Apr 24, 2018 at 06:00:35PM -0500, Eric W. Biederman wrote: >> Christian Brauner writes: >> >> > On Wed, Apr 25, 2018, 00:41 Eric W. Biederman >> > wrote: >> > >> >

Re: [PATCH net-next 1/2 v2] netns: restrict uevents

Christian Brauner writes: > On Tue, Apr 24, 2018 at 06:00:35PM -0500, Eric W. Biederman wrote: >> Christian Brauner writes: >> >> > On Wed, Apr 25, 2018, 00:41 Eric W. Biederman >> > wrote: >> > >> > Bah. This code is obviously correct and probably wrong. >> > >> > How do we deliver

Re: [V3 PATCH] perf parse-events: Specially handle uncore event alias in small groups

On 4/26/2018 12:14 PM, Jiri Olsa wrote: On Wed, Apr 25, 2018 at 10:58:43AM -0700, kan.li...@linux.intel.com wrote: SNIP -void parse_events__set_leader(char *name, struct list_head *list) +/* + * Check if the two uncore PMUs are from the same uncore block + * The format of the uncore PMU

Re: [V3 PATCH] perf parse-events: Specially handle uncore event alias in small groups

On 4/26/2018 12:14 PM, Jiri Olsa wrote: On Wed, Apr 25, 2018 at 10:58:43AM -0700, kan.li...@linux.intel.com wrote: SNIP -void parse_events__set_leader(char *name, struct list_head *list) +/* + * Check if the two uncore PMUs are from the same uncore block + * The format of the uncore PMU

Re: [linux-sunxi] [PATCH 3/3] arm64: allwinner: h6: enable MMC0/2 on Pine H64

Hi, On 26/04/18 15:07, Icenowy Zheng wrote: > The Pine H64 board have a MicroSD slot connected to MMC0 controller of > the H6 SoC and a eMMC slot connected to MMC2. > > Enable them in the device tree. > > Signed-off-by: Icenowy Zheng > --- >

Re: [linux-sunxi] [PATCH 3/3] arm64: allwinner: h6: enable MMC0/2 on Pine H64

Hi, On 26/04/18 15:07, Icenowy Zheng wrote: > The Pine H64 board have a MicroSD slot connected to MMC0 controller of > the H6 SoC and a eMMC slot connected to MMC2. > > Enable them in the device tree. > > Signed-off-by: Icenowy Zheng > --- > .../boot/dts/allwinner/sun50i-h6-pine-h64.dts

Re: [PATCH v4 0/6] clocksource: rework Atmel TCB timer driver

On 2018-04-18 12:51:37 [+0200], Alexandre Belloni wrote: > Hi, Hi, please keep on Cc if you intend to repost this. > This series gets back on the TCB drivers rework. It introduces a new driver to > handle the clocksource and clockevent devices. So you don't want the old thing we have in -RT. I

Re: [PATCH v4 0/6] clocksource: rework Atmel TCB timer driver

On 2018-04-18 12:51:37 [+0200], Alexandre Belloni wrote: > Hi, Hi, please keep on Cc if you intend to repost this. > This series gets back on the TCB drivers rework. It introduces a new driver to > handle the clocksource and clockevent devices. So you don't want the old thing we have in -RT. I

Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: h6: add device tree nodes for MMC controllers

Hi, On 26/04/18 15:07, Icenowy Zheng wrote: > The Allwinner H6 SoC have 3 MMC controllers. > > Add device tree nodes for them. > > Signed-off-by: Icenowy Zheng > --- > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 56 > > 1 file changed, 56

Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: h6: add device tree nodes for MMC controllers

Hi, On 26/04/18 15:07, Icenowy Zheng wrote: > The Allwinner H6 SoC have 3 MMC controllers. > > Add device tree nodes for them. > > Signed-off-by: Icenowy Zheng > --- > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 56 > > 1 file changed, 56 insertions(+) > >

Re: [linux-sunxi] [PATCH 1/3] mmc: sunxi: add support for the MMC controller on H6

Hi, On 26/04/18 15:07, Icenowy Zheng wrote: > The new Allwinner H6 SoC have 3 MMC controllers. The first and second > ones are similar to the ones on A64, but the third one adds EMCE > (Embedded Crypto Engine) support which does hardware transparent crypto > on the eMMC. > > As we still do not

Re: [linux-sunxi] [PATCH 1/3] mmc: sunxi: add support for the MMC controller on H6

Hi, On 26/04/18 15:07, Icenowy Zheng wrote: > The new Allwinner H6 SoC have 3 MMC controllers. The first and second > ones are similar to the ones on A64, but the third one adds EMCE > (Embedded Crypto Engine) support which does hardware transparent crypto > on the eMMC. > > As we still do not

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

On Wed, Apr 25, 2018 at 9:54 PM Stephen Rothwell wrote: > Hi Evan, > On Thu, 26 Apr 2018 03:39:25 + Evan Green wrote: > > > > Guenter and I had a fix for compile test here, which had failures that > > looked similar: > > > >

Re: [Qemu-devel] [RFC v2] qemu: Add virtio pmem device

> > +static void virtio_pmem_flush(VirtIODevice *vdev, VirtQueue *vq) > > +{ > > +VirtQueueElement *elem; > > +VirtIOPMEM *pmem = VIRTIO_PMEM(vdev); > > +HostMemoryBackend *backend = MEMORY_BACKEND(pmem->memdev); > > +int fd = memory_region_get_fd(>mr); > > + > > +elem =

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

On Wed, Apr 25, 2018 at 9:54 PM Stephen Rothwell wrote: > Hi Evan, > On Thu, 26 Apr 2018 03:39:25 + Evan Green wrote: > > > > Guenter and I had a fix for compile test here, which had failures that > > looked similar: > > > > https://lkml.org/lkml/2018/4/18/752 > That looks like it could

Re: [Qemu-devel] [RFC v2] qemu: Add virtio pmem device

> > +static void virtio_pmem_flush(VirtIODevice *vdev, VirtQueue *vq) > > +{ > > +VirtQueueElement *elem; > > +VirtIOPMEM *pmem = VIRTIO_PMEM(vdev); > > +HostMemoryBackend *backend = MEMORY_BACKEND(pmem->memdev); > > +int fd = memory_region_get_fd(>mr); > > + > > +elem =

Re: [PATCH v2] gpiolib: add hogs support for machine code

2018-04-26 14:07 GMT+02:00 Linus Walleij : > On Tue, Apr 10, 2018 at 10:30 PM, Bartosz Golaszewski wrote: > >> Board files constitute a significant part of the users of the legacy >> GPIO framework. In many cases they only export a line and set its >>

Re: [PATCH v2] gpiolib: add hogs support for machine code

2018-04-26 14:07 GMT+02:00 Linus Walleij : > On Tue, Apr 10, 2018 at 10:30 PM, Bartosz Golaszewski wrote: > >> Board files constitute a significant part of the users of the legacy >> GPIO framework. In many cases they only export a line and set its >> desired value. We could use GPIO hogs for

Re: [PATCH 1/2] dmaengine: axi-dmac: Use devm_request_irq()

Hi Lars, On Thu, Apr 26, 2018 at 9:26 AM, Lars-Peter Clausen wrote: > On 04/26/2018 06:12 PM, Moritz Fischer wrote: >> Use devm_request_irq() instead of request_irq() to request the IRQ. >> >> Signed-off-by: Moritz Fischer >> --- >> >> Hi Lars, >> >> was there

Re: [PATCH 1/2] dmaengine: axi-dmac: Use devm_request_irq()

Hi Lars, On Thu, Apr 26, 2018 at 9:26 AM, Lars-Peter Clausen wrote: > On 04/26/2018 06:12 PM, Moritz Fischer wrote: >> Use devm_request_irq() instead of request_irq() to request the IRQ. >> >> Signed-off-by: Moritz Fischer >> --- >> >> Hi Lars, >> >> was there a specific reason not to use

Re: [PATCH v2] input/touchscreen: atmel_mxt_ts: Add correct touchpad button mapping for the Caroline Chromebook.

On Thu, Apr 26, 2018 at 06:45:32AM -0700, Guenter Roeck wrote: > On Wed, Apr 25, 2018 at 10:37 PM, Vittorio Gambaletta (VittGam) < > linuxb...@vittgam.net> wrote: > > > Hello, > > > > On 26/04/2018 00:57:34 CEST, Dmitry Torokhov wrote: > > > On Wed, Apr 25, 2018 at 03:26:50PM -0700, Dmitry

Re: [PATCH v2] input/touchscreen: atmel_mxt_ts: Add correct touchpad button mapping for the Caroline Chromebook.

On Thu, Apr 26, 2018 at 06:45:32AM -0700, Guenter Roeck wrote: > On Wed, Apr 25, 2018 at 10:37 PM, Vittorio Gambaletta (VittGam) < > linuxb...@vittgam.net> wrote: > > > Hello, > > > > On 26/04/2018 00:57:34 CEST, Dmitry Torokhov wrote: > > > On Wed, Apr 25, 2018 at 03:26:50PM -0700, Dmitry

Re: [RFC v2 2/2] pmem: device flush over VIRTIO

> > On Wed, Apr 25, 2018 at 04:54:14PM +0530, Pankaj Gupta wrote: > > This patch adds functionality to perform > > flush from guest to hosy over VIRTIO > > when 'ND_REGION_VIRTIO'flag is set on > > nd_negion. Flag is set by 'virtio-pmem' > > driver. > > > > Signed-off-by: Pankaj Gupta

Re: [RFC v2 2/2] pmem: device flush over VIRTIO

> > On Wed, Apr 25, 2018 at 04:54:14PM +0530, Pankaj Gupta wrote: > > This patch adds functionality to perform > > flush from guest to hosy over VIRTIO > > when 'ND_REGION_VIRTIO'flag is set on > > nd_negion. Flag is set by 'virtio-pmem' > > driver. > > > > Signed-off-by: Pankaj Gupta > > ---

Re: [PATCH] f2fs: fix to wait IO writeback in __revoke_inmem_pages()

On 04/26, Chao Yu wrote: > On 2018/4/26 23:48, Jaegeuk Kim wrote: > > On 04/26, Chao Yu wrote: > >> Thread A Thread B > >> - f2fs_ioc_commit_atomic_write > >> - commit_inmem_pages > >> - f2fs_submit_merged_write_cond > >> : write data > >>

Re: [PATCH] f2fs: fix to wait IO writeback in __revoke_inmem_pages()

On 04/26, Chao Yu wrote: > On 2018/4/26 23:48, Jaegeuk Kim wrote: > > On 04/26, Chao Yu wrote: > >> Thread A Thread B > >> - f2fs_ioc_commit_atomic_write > >> - commit_inmem_pages > >> - f2fs_submit_merged_write_cond > >> : write data > >>

Re: [PATCH v5] gpio: dwapb: Add support for 1 interrupt per port A GPIO

Hi, On Thu, Apr 26, 2018 at 9:19 AM, Phil Edworthy wrote: > The DesignWare GPIO IP can be configured for either 1 interrupt or 1 > per GPIO in port A, but the driver currently only supports 1 interrupt. > See the DesignWare DW_apb_gpio Databook description of the >

Re: [PATCH v5] gpio: dwapb: Add support for 1 interrupt per port A GPIO

Hi, On Thu, Apr 26, 2018 at 9:19 AM, Phil Edworthy wrote: > The DesignWare GPIO IP can be configured for either 1 interrupt or 1 > per GPIO in port A, but the driver currently only supports 1 interrupt. > See the DesignWare DW_apb_gpio Databook description of the > 'GPIO_INTR_IO' parameter. > >

Re: [PATCH] Revert "x86/mm: implement free pmd/pte page interfaces"

On Thu, 2018-04-26 at 17:14 +0200, Joerg Roedel wrote: > From: Joerg Roedel > > This reverts commit 28ee90fe6048fa7b7ceaeb8831c0e4e454a4cf89. > > This commit is broken for x86, as it unmaps the PTE and PMD > pages and immediatly frees them without doing a TLB flush. > >

Re: [PATCH] Revert "x86/mm: implement free pmd/pte page interfaces"

On Thu, 2018-04-26 at 17:14 +0200, Joerg Roedel wrote: > From: Joerg Roedel > > This reverts commit 28ee90fe6048fa7b7ceaeb8831c0e4e454a4cf89. > > This commit is broken for x86, as it unmaps the PTE and PMD > pages and immediatly frees them without doing a TLB flush. > > Further this lacks

Re: [PATCH] USB: serial: option: adding support for ublox R410M

On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote: > On 4/26/2018 23:12, Johan Hovold wrote: > > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote: > >> On 4/26/2018 18:39, Lars Melin wrote: > >>> On 4/26/2018 18:19, Bjørn Mork wrote: > Anyway, Qualcomm based designs are

Re: [PATCH] USB: serial: option: adding support for ublox R410M

On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote: > On 4/26/2018 23:12, Johan Hovold wrote: > > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote: > >> On 4/26/2018 18:39, Lars Melin wrote: > >>> On 4/26/2018 18:19, Bjørn Mork wrote: > Anyway, Qualcomm based designs are

random: GFP_KERNEL from irq context

Hi Ted, Just triggered this on my test box: [ 16.992068] BUG: sleeping function called from invalid context at mm/slab.h:421 [ 17.001136] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/30 [ 17.009116] CPU: 30 PID: 0 Comm: swapper/30 Not tainted 4.17.0-rc2+ #665 [ 17.017092]

random: GFP_KERNEL from irq context

Hi Ted, Just triggered this on my test box: [ 16.992068] BUG: sleeping function called from invalid context at mm/slab.h:421 [ 17.001136] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/30 [ 17.009116] CPU: 30 PID: 0 Comm: swapper/30 Not tainted 4.17.0-rc2+ #665 [ 17.017092]

Re: [PATCH 2/2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

On 04/26/2018 06:12 PM, Moritz Fischer wrote: > Request IRQ with IRQF_SHARED flag. This works since the interrupt > handler already checks if there is an actual IRQ pending and returns > IRQ_NONE otherwise. > > Signed-off-by: Moritz Fischer Acked-by: Lars-Peter Clausen

Re: [PATCH 2/2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

On 04/26/2018 06:12 PM, Moritz Fischer wrote: > Request IRQ with IRQF_SHARED flag. This works since the interrupt > handler already checks if there is an actual IRQ pending and returns > IRQ_NONE otherwise. > > Signed-off-by: Moritz Fischer Acked-by: Lars-Peter Clausen Thanks. > --- >

Re: [PATCH 1/2] dmaengine: axi-dmac: Use devm_request_irq()

On 04/26/2018 06:12 PM, Moritz Fischer wrote: > Use devm_request_irq() instead of request_irq() to request the IRQ. > > Signed-off-by: Moritz Fischer > --- > > Hi Lars, > > was there a specific reason not to use devm_request_irq() ? Yes, it is wrong :) This reorders the

Re: [PATCH 1/2] dmaengine: axi-dmac: Use devm_request_irq()

On 04/26/2018 06:12 PM, Moritz Fischer wrote: > Use devm_request_irq() instead of request_irq() to request the IRQ. > > Signed-off-by: Moritz Fischer > --- > > Hi Lars, > > was there a specific reason not to use devm_request_irq() ? Yes, it is wrong :) This reorders the sequence in the

Re: [PATCH v5 2/2] selftests: sparc64: char: Selftest for privileged ADI driver

On 04/23/2018 03:01 PM, Shuah Khan wrote: On 04/23/2018 11:33 AM, Tom Hromatka wrote: Add a selftest for the sparc64 privileged ADI driver. These tests verify the read(), pread(), write(), pwrite(), and seek() functionality of the driver. The tests also report simple performance statistics:

Re: [PATCH v5 2/2] selftests: sparc64: char: Selftest for privileged ADI driver

On 04/23/2018 03:01 PM, Shuah Khan wrote: On 04/23/2018 11:33 AM, Tom Hromatka wrote: Add a selftest for the sparc64 privileged ADI driver. These tests verify the read(), pread(), write(), pwrite(), and seek() functionality of the driver. The tests also report simple performance statistics:

Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable

Michal Hocko writes: > I've had a patch to remove owner few years back. It needed some work > to finish but maybe that would be a better than try to make > non-scalable thing suck less. I have a question. Would it be reasonable to just have a mm->memcg? That would appear to

Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable

Michal Hocko writes: > I've had a patch to remove owner few years back. It needed some work > to finish but maybe that would be a better than try to make > non-scalable thing suck less. I have a question. Would it be reasonable to just have a mm->memcg? That would appear to be the simplest

Re: [PATCH] USB: serial: option: adding support for ublox R410M

On 4/26/2018 23:12, Johan Hovold wrote: On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote: On 4/26/2018 18:39, Lars Melin wrote: On 4/26/2018 18:19, Bjørn Mork wrote: Anyway, Qualcomm based designs are definitely handled by both drivers. Using qcserial only makes sense if the

Re: [PATCH] USB: serial: option: adding support for ublox R410M

On 4/26/2018 23:12, Johan Hovold wrote: On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote: On 4/26/2018 18:39, Lars Melin wrote: On 4/26/2018 18:19, Bjørn Mork wrote: Anyway, Qualcomm based designs are definitely handled by both drivers. Using qcserial only makes sense if the

[PATCH 04/11] irqchip: stm32: add suspend support

From: Ludovic Barre This patch adds suspend feature. -Use default irq_set_wake function to store wakeup request. -Suspend function set wake_active into imr of each bank and save rising/falling trigger registers. -Resume function restore the mask_cache interrupt into imr

[PATCH 05/11] irqchip: stm32: add host and driver data structures

From: Ludovic Barre This patch adds host and driver data structures to support different stm32 exti controllers with variants. Signed-off-by: Ludovic Barre --- drivers/irqchip/irq-stm32-exti.c | 152 ++- 1 file

[PATCH 04/11] irqchip: stm32: add suspend support

From: Ludovic Barre This patch adds suspend feature. -Use default irq_set_wake function to store wakeup request. -Suspend function set wake_active into imr of each bank and save rising/falling trigger registers. -Resume function restore the mask_cache interrupt into imr of each bank and

[PATCH 05/11] irqchip: stm32: add host and driver data structures

From: Ludovic Barre This patch adds host and driver data structures to support different stm32 exti controllers with variants. Signed-off-by: Ludovic Barre --- drivers/irqchip/irq-stm32-exti.c | 152 ++- 1 file changed, 104 insertions(+), 48 deletions(-)

Re: [PATCH v2 2/2] x86/mm: implement free pmd/pte page interfaces

On Thu, 2018-04-26 at 16:19 +0200, Joerg Roedel wrote: > Hi Toshi, Andrew, > > this patch(-set) is broken in several ways, please see below. > > On Wed, Mar 14, 2018 at 12:01:55PM -0600, Toshi Kani wrote: > > Implement pud_free_pmd_page() and pmd_free_pte_page() on x86, which > > clear a given

Re: [PATCH v2 2/2] x86/mm: implement free pmd/pte page interfaces

On Thu, 2018-04-26 at 16:19 +0200, Joerg Roedel wrote: > Hi Toshi, Andrew, > > this patch(-set) is broken in several ways, please see below. > > On Wed, Mar 14, 2018 at 12:01:55PM -0600, Toshi Kani wrote: > > Implement pud_free_pmd_page() and pmd_free_pte_page() on x86, which > > clear a given

[PATCH 03/11] irqchip: stm32: add falling pending register support

From: Ludovic Barre This patch adds support of rising/falling pending registers. Falling pending register (fpr) is needed for next revision. Signed-off-by: Ludovic Barre --- drivers/irqchip/irq-stm32-exti.c | 47

[PATCH 03/11] irqchip: stm32: add falling pending register support

From: Ludovic Barre This patch adds support of rising/falling pending registers. Falling pending register (fpr) is needed for next revision. Signed-off-by: Ludovic Barre --- drivers/irqchip/irq-stm32-exti.c | 47 ++-- 1 file changed, 36 insertions(+), 11

[PATCH 10/11] ARM: dts: stm32: add exti support for stm32mp157c

From: Ludovic Barre This patch adds external interrupt (exti) support on stm32mp157c SoC. Signed-off-by: Ludovic Barre --- arch/arm/boot/dts/stm32mp157c.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH 10/11] ARM: dts: stm32: add exti support for stm32mp157c

From: Ludovic Barre This patch adds external interrupt (exti) support on stm32mp157c SoC. Signed-off-by: Ludovic Barre --- arch/arm/boot/dts/stm32mp157c.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi

[PATCH 06/11] irqchip: stm32: prepare common functions

From: Ludovic Barre This patch prepares functions which could be reused by next variant of stm32 exti controller. Signed-off-by: Ludovic Barre --- drivers/irqchip/irq-stm32-exti.c | 91 +--- 1 file changed, 58

[PATCH 06/11] irqchip: stm32: prepare common functions

From: Ludovic Barre This patch prepares functions which could be reused by next variant of stm32 exti controller. Signed-off-by: Ludovic Barre --- drivers/irqchip/irq-stm32-exti.c | 91 +--- 1 file changed, 58 insertions(+), 33 deletions(-) diff --git

[PATCH 01/11] irqchip: stm32: Optimizes and cleans up stm32-exti irq_domain

From: radek - In stm32_exti_alloc function, discards irq_domain_set_info with handle_simple_irq. This overwrite the setting defined while init of generic chips. Exti controller manages edge irq type. - Removes acking in chained irq handler as this is done by

[PATCH 01/11] irqchip: stm32: Optimizes and cleans up stm32-exti irq_domain

From: radek - In stm32_exti_alloc function, discards irq_domain_set_info with handle_simple_irq. This overwrite the setting defined while init of generic chips. Exti controller manages edge irq type. - Removes acking in chained irq handler as this is done by irq_chip itself inside

[PATCH 00/11] irqchip: stm32: add exti support for stm32mp157c

From: Ludovic Barre Exti controller has been differently integrated on stm32mp1 SoC. A parent irq has only one external interrupt Vs stm32f4: one parent irq can have some external interrupts. On stm32mp1 hierachy domain could be used. Handlers are call by parent, each

[PATCH 00/11] irqchip: stm32: add exti support for stm32mp157c

From: Ludovic Barre Exti controller has been differently integrated on stm32mp1 SoC. A parent irq has only one external interrupt Vs stm32f4: one parent irq can have some external interrupts. On stm32mp1 hierachy domain could be used. Handlers are call by parent, each parent interrupt could be

[PATCH 08/11] irqchip: stm32: add suspend/resume support for hierarchy domain

From: Ludovic Barre This patch adds suspend/resume feature for exti hierarchy domain. -suspend function sets wake_active into imr of each banks -resume function restores the mask_cache interrupt into imr of each banks Signed-off-by: Ludovic Barre

[PATCH 08/11] irqchip: stm32: add suspend/resume support for hierarchy domain

From: Ludovic Barre This patch adds suspend/resume feature for exti hierarchy domain. -suspend function sets wake_active into imr of each banks -resume function restores the mask_cache interrupt into imr of each banks Signed-off-by: Ludovic Barre --- drivers/irqchip/irq-stm32-exti.c | 49

[PATCH 09/11] pinctrl: stm32: add irq_eoi for stm32gpio irqchip

From: Ludovic Barre -Parent domain of stm32gpio evolves to hierarchy domain and could have a handle_fasteoi_irq. So an irq_eoi parent callback is needed for children. -Replace space by tabulation. Signed-off-by: Ludovic Barre ---

[PATCH 09/11] pinctrl: stm32: add irq_eoi for stm32gpio irqchip

From: Ludovic Barre -Parent domain of stm32gpio evolves to hierarchy domain and could have a handle_fasteoi_irq. So an irq_eoi parent callback is needed for children. -Replace space by tabulation. Signed-off-by: Ludovic Barre --- drivers/pinctrl/stm32/pinctrl-stm32.c | 13 +++-- 1

[PATCH v5] gpio: dwapb: Add support for 1 interrupt per port A GPIO

The DesignWare GPIO IP can be configured for either 1 interrupt or 1 per GPIO in port A, but the driver currently only supports 1 interrupt. See the DesignWare DW_apb_gpio Databook description of the 'GPIO_INTR_IO' parameter. This change allows the driver to work with up to 32 interrupts, it will

[PATCH v5] gpio: dwapb: Add support for 1 interrupt per port A GPIO

The DesignWare GPIO IP can be configured for either 1 interrupt or 1 per GPIO in port A, but the driver currently only supports 1 interrupt. See the DesignWare DW_apb_gpio Databook description of the 'GPIO_INTR_IO' parameter. This change allows the driver to work with up to 32 interrupts, it will

[PATCH 02/11] irqchip: stm32: checkpatch fix

From: Ludovic Barre -WARNING: struct irq_domain_ops should normally be const -CHECK: Alignment should match open parenthesis Signed-off-by: Ludovic Barre --- drivers/irqchip/irq-stm32-exti.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH 11/11] ARM: dts: stm32: add exti support to stm32mp157 pinctrl

From: Ludovic Barre This patch adds support of external interrupt for gpio[a..k], gpioz Signed-off-by: Ludovic Barre --- arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 4 1 file changed, 4 insertions(+) diff --git

[PATCH 02/11] irqchip: stm32: checkpatch fix

From: Ludovic Barre -WARNING: struct irq_domain_ops should normally be const -CHECK: Alignment should match open parenthesis Signed-off-by: Ludovic Barre --- drivers/irqchip/irq-stm32-exti.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 11/11] ARM: dts: stm32: add exti support to stm32mp157 pinctrl

From: Ludovic Barre This patch adds support of external interrupt for gpio[a..k], gpioz Signed-off-by: Ludovic Barre --- arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi

[PATCH 07/11] irqchip: stm32: add stm32mp1 support with hierarchy domain

From: Ludovic Barre Exti controller has been differently integrated on stm32mp1 SoC. A parent irq has only one external interrupt. A hierachy domain could be used. Handlers are call by parent, each parent interrupt could be masked and unmasked according to the needs.

[PATCH 07/11] irqchip: stm32: add stm32mp1 support with hierarchy domain

From: Ludovic Barre Exti controller has been differently integrated on stm32mp1 SoC. A parent irq has only one external interrupt. A hierachy domain could be used. Handlers are call by parent, each parent interrupt could be masked and unmasked according to the needs. Signed-off-by: Ludovic

[PATCH 2/2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

Request IRQ with IRQF_SHARED flag. This works since the interrupt handler already checks if there is an actual IRQ pending and returns IRQ_NONE otherwise. Signed-off-by: Moritz Fischer --- drivers/dma/dma-axi-dmac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 1/2] dmaengine: axi-dmac: Use devm_request_irq()

Use devm_request_irq() instead of request_irq() to request the IRQ. Signed-off-by: Moritz Fischer --- Hi Lars, was there a specific reason not to use devm_request_irq() ? Cheers, Moritz --- drivers/dma/dma-axi-dmac.c | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH 2/2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

Request IRQ with IRQF_SHARED flag. This works since the interrupt handler already checks if there is an actual IRQ pending and returns IRQ_NONE otherwise. Signed-off-by: Moritz Fischer --- drivers/dma/dma-axi-dmac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 1/2] dmaengine: axi-dmac: Use devm_request_irq()

Use devm_request_irq() instead of request_irq() to request the IRQ. Signed-off-by: Moritz Fischer --- Hi Lars, was there a specific reason not to use devm_request_irq() ? Cheers, Moritz --- drivers/dma/dma-axi-dmac.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

Re: [PATCH v1] kthread/smpboot: Serialize kthread parking against wakeup

On 04/26, Peter Zijlstra wrote: > > For the others, I think we want to do something like the below. I still > need to look at TASK_TRACED, which I suspect is also special, Yes, and TASK_STOPPED. ptrace_freeze_traced() and ptrace_unfreeze_traced() should be fine, but ptrace_stop() wants

Re: [PATCH v1] kthread/smpboot: Serialize kthread parking against wakeup

On 04/26, Peter Zijlstra wrote: > > For the others, I think we want to do something like the below. I still > need to look at TASK_TRACED, which I suspect is also special, Yes, and TASK_STOPPED. ptrace_freeze_traced() and ptrace_unfreeze_traced() should be fine, but ptrace_stop() wants

Re: [V3 PATCH] perf parse-events: Specially handle uncore event alias in small groups

On Wed, Apr 25, 2018 at 10:58:43AM -0700, kan.li...@linux.intel.com wrote: SNIP > -void parse_events__set_leader(char *name, struct list_head *list) > +/* > + * Check if the two uncore PMUs are from the same uncore block > + * The format of the uncore PMU name is uncore_#blockname_#pmuidx > + */

Re: [V3 PATCH] perf parse-events: Specially handle uncore event alias in small groups

On Wed, Apr 25, 2018 at 10:58:43AM -0700, kan.li...@linux.intel.com wrote: SNIP > -void parse_events__set_leader(char *name, struct list_head *list) > +/* > + * Check if the two uncore PMUs are from the same uncore block > + * The format of the uncore PMU name is uncore_#blockname_#pmuidx > + */

Re: [PATCH net-next 1/2 v2] netns: restrict uevents

On Tue, Apr 24, 2018 at 06:00:35PM -0500, Eric W. Biederman wrote: > Christian Brauner writes: > > > On Wed, Apr 25, 2018, 00:41 Eric W. Biederman wrote: > > > > Bah. This code is obviously correct and probably wrong. > > > > How do we

Re: [PATCH net-next 1/2 v2] netns: restrict uevents

On Tue, Apr 24, 2018 at 06:00:35PM -0500, Eric W. Biederman wrote: > Christian Brauner writes: > > > On Wed, Apr 25, 2018, 00:41 Eric W. Biederman wrote: > > > > Bah. This code is obviously correct and probably wrong. > > > > How do we deliver uevents for network devices that are outside of

Re: [PATCH] USB: serial: option: adding support for ublox R410M

On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote: > On 4/26/2018 18:39, Lars Melin wrote: > > On 4/26/2018 18:19, Bjørn Mork wrote: > >> Anyway, Qualcomm based designs are definitely handled by both drivers. > >> Using qcserial only makes sense if the interface layout matches one of > >>

Re: [PATCH] USB: serial: option: adding support for ublox R410M

On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote: > On 4/26/2018 18:39, Lars Melin wrote: > > On 4/26/2018 18:19, Bjørn Mork wrote: > >> Anyway, Qualcomm based designs are definitely handled by both drivers. > >> Using qcserial only makes sense if the interface layout matches one of > >>

Re: [PATCH 4/4] exit: Lockless iteration over task list in mm_update_next_owner()

On 26.04.2018 18:29, Andrea Parri wrote: > On Thu, Apr 26, 2018 at 04:52:39PM +0300, Kirill Tkhai wrote: >> On 26.04.2018 15:35, Andrea Parri wrote: > > [...] > >>> >>> Mmh, it's possible that I am misunderstanding this statement but it does >>> not seem quite correct to me; a counter-example

Re: [PATCH 4/4] exit: Lockless iteration over task list in mm_update_next_owner()

On 26.04.2018 18:29, Andrea Parri wrote: > On Thu, Apr 26, 2018 at 04:52:39PM +0300, Kirill Tkhai wrote: >> On 26.04.2018 15:35, Andrea Parri wrote: > > [...] > >>> >>> Mmh, it's possible that I am misunderstanding this statement but it does >>> not seem quite correct to me; a counter-example

Re: linux-next: unable to fetch the kbuild-current tree

2018-04-26 6:57 GMT+09:00 Stephen Rothwell : > Hi Masahiro, > > Fetching the kbuild-current tree produces this error: > > fatal: Couldn't find remote ref refs/heads/fixes > Sorry, I fixed it now. -- Best Regards Masahiro Yamada

Re: linux-next: unable to fetch the kbuild-current tree

2018-04-26 6:57 GMT+09:00 Stephen Rothwell : > Hi Masahiro, > > Fetching the kbuild-current tree produces this error: > > fatal: Couldn't find remote ref refs/heads/fixes > Sorry, I fixed it now. -- Best Regards Masahiro Yamada

Re: [PATCH 2/6] powerpc/64s: Add support for ori barrier_nospec patching

Hello, On Tue, 24 Apr 2018 14:15:55 +1000 Michael Ellerman wrote: > From: Michal Suchanek > > Based on the RFI patching. This is required to be able to disable the > speculation barrier. why do you not patch the nospec barrier which is included as part

Re: [PATCH 2/6] powerpc/64s: Add support for ori barrier_nospec patching

Hello, On Tue, 24 Apr 2018 14:15:55 +1000 Michael Ellerman wrote: > From: Michal Suchanek > > Based on the RFI patching. This is required to be able to disable the > speculation barrier. why do you not patch the nospec barrier which is included as part of the RFI flush code? I think when

Re: [PATCH 3/3] f2fs: maintain discard interface separately

On 04/25, Chao Yu wrote: > This patch adds a new file discard.c to maintain discard related > function separately. I don't think we need this at all. Thanks, > > BTW, fix below checkpatch errors: > > ERROR: space required before the open brace '{' > + } else if (issued == -1){ > >

Re: [PATCH 3/3] f2fs: maintain discard interface separately

On 04/25, Chao Yu wrote: > This patch adds a new file discard.c to maintain discard related > function separately. I don't think we need this at all. Thanks, > > BTW, fix below checkpatch errors: > > ERROR: space required before the open brace '{' > + } else if (issued == -1){ > >

Re: [PATCH 2/3] f2fs: introduce {create,destroy}_discard_caches for cleanup

On 04/25, Chao Yu wrote: > Split discard slab cache related initial/release codes into separated > function {create,destroy}_discard_caches, later we can maintain those > independent functions in separated discard.c No need this as well. > > Signed-off-by: Chao Yu > --- >

Re: [PATCH 2/3] f2fs: introduce {create,destroy}_discard_caches for cleanup

On 04/25, Chao Yu wrote: > Split discard slab cache related initial/release codes into separated > function {create,destroy}_discard_caches, later we can maintain those > independent functions in separated discard.c No need this as well. > > Signed-off-by: Chao Yu > --- > fs/f2fs/f2fs.h|

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

- On Apr 26, 2018, at 11:03 AM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Apr 25, 2018, at 6:51 PM, rostedt rost...@goodmis.org wrote: > >> On Wed, 25 Apr 2018 17:40:56 -0400 (EDT) >> Mathieu Desnoyers wrote: >> >>> One problem with

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

- On Apr 26, 2018, at 11:03 AM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Apr 25, 2018, at 6:51 PM, rostedt rost...@goodmis.org wrote: > >> On Wed, 25 Apr 2018 17:40:56 -0400 (EDT) >> Mathieu Desnoyers wrote: >> >>> One problem with your approach is that you can

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