Re: [PATCH] scsi: ibmvfc: constify dev_pm_ops structures.

On 06/29/2017 12:54 AM, Arvind Yadav wrote: > dev_pm_ops are not supposed to change at runtime. All functions > working with dev_pm_ops provided by work with const > dev_pm_ops. So mark the non-const structs as const. > > File size before: >text data bss dec hex filename

Re: [PATCH] scsi: ibmvfc: constify dev_pm_ops structures.

On 06/29/2017 12:54 AM, Arvind Yadav wrote: > dev_pm_ops are not supposed to change at runtime. All functions > working with dev_pm_ops provided by work with const > dev_pm_ops. So mark the non-const structs as const. > > File size before: >text data bss dec hex filename

Re: [PATCH] scsi: ibmvscsi: constify dev_pm_ops structures.

On 06/29/2017 12:43 AM, Arvind Yadav wrote: > dev_pm_ops are not supposed to change at runtime. All functions > working with dev_pm_ops provided by work with const > dev_pm_ops. So mark the non-const structs as const. > > File size before: >text data bss dec hex filename

Re: [PATCH] scsi: ibmvscsi: constify dev_pm_ops structures.

On 06/29/2017 12:43 AM, Arvind Yadav wrote: > dev_pm_ops are not supposed to change at runtime. All functions > working with dev_pm_ops provided by work with const > dev_pm_ops. So mark the non-const structs as const. > > File size before: >text data bss dec hex filename

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 06:28 PM, Dan Williams wrote: > On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers > wrote: > [..] >>> The /dev/pmem >>> device name just tells you that your block device is hosted by a >>> driver that knows how to handle persistent memory constraints, but any

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 06:28 PM, Dan Williams wrote: > On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers > wrote: > [..] >>> The /dev/pmem >>> device name just tells you that your block device is hosted by a >>> driver that knows how to handle persistent memory constraints, but any >>> other details about

Re: [PATCH v2] iommu/arm-smmu-v3: Implement shutdown method

I should have removed the '-v3' since this revision of the patch adds shutdown to arm-smmu.c as well. I'll fix that in a subsequent version after waiting to see if there are additional changes that need to be made. On 6/29/2017 6:18 PM, Nate Watterson wrote: The shutdown method disables the

Re: [PATCH v2] iommu/arm-smmu-v3: Implement shutdown method

I should have removed the '-v3' since this revision of the patch adds shutdown to arm-smmu.c as well. I'll fix that in a subsequent version after waiting to see if there are additional changes that need to be made. On 6/29/2017 6:18 PM, Nate Watterson wrote: The shutdown method disables the

Re: [PATCH] sysctl: don't read uninit memory in deprecated_sysctl_warning()

On Wed, 28 Jun 2017 17:00:37 +0200 Alexander Potapenko wrote: > Don't attempt to read the first two elements of name[] unless they > were actually copied from the userspace. > > This bug has been detected by KMSAN. Thanks. I already have the identical

Re: [PATCH] sysctl: don't read uninit memory in deprecated_sysctl_warning()

On Wed, 28 Jun 2017 17:00:37 +0200 Alexander Potapenko wrote: > Don't attempt to read the first two elements of name[] unless they > were actually copied from the userspace. > > This bug has been detected by KMSAN. Thanks. I already have the identical

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers wrote: [..] >> The /dev/pmem >> device name just tells you that your block device is hosted by a >> driver that knows how to handle persistent memory constraints, but any >> other details about the nature of the address range

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers wrote: [..] >> The /dev/pmem >> device name just tells you that your block device is hosted by a >> driver that knows how to handle persistent memory constraints, but any >> other details about the nature of the address range need to come from >>

Re: [PATCH fixes v3] pinctrl: Really force states during suspend/resume

On Thu, Jun 29, 2017 at 9:38 PM, Florian Fainelli wrote: > On 06/29/2017 02:17 AM, Linus Walleij wrote: >> So if it is not desireable to have every driver know which exact >> state it came from like S3 this or S2 that and on this laptop >> we have S2' which is slightly

Re: [PATCH fixes v3] pinctrl: Really force states during suspend/resume

On Thu, Jun 29, 2017 at 9:38 PM, Florian Fainelli wrote: > On 06/29/2017 02:17 AM, Linus Walleij wrote: >> So if it is not desireable to have every driver know which exact >> state it came from like S3 this or S2 that and on this laptop >> we have S2' which is slightly different and such mess

[PATCH v2] iommu/arm-smmu-v3: Implement shutdown method

The shutdown method disables the SMMU to avoid corrupting a new kernel started with kexec. Signed-off-by: Nate Watterson --- drivers/iommu/arm-smmu-v3.c | 7 +++ drivers/iommu/arm-smmu.c| 6 ++ 2 files changed, 13 insertions(+) diff --git

[PATCH v2] iommu/arm-smmu-v3: Implement shutdown method

The shutdown method disables the SMMU to avoid corrupting a new kernel started with kexec. Signed-off-by: Nate Watterson --- drivers/iommu/arm-smmu-v3.c | 7 +++ drivers/iommu/arm-smmu.c| 6 ++ 2 files changed, 13 insertions(+) diff --git a/drivers/iommu/arm-smmu-v3.c

Re: [PATCH v5] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

Hi Maxime, On 30 June 2017 at 01:56, Maxime Ripard wrote: > On Wed, Jun 28, 2017 at 08:39:33PM +1000, Jonathan Liu wrote: >> >> + u32 int_status; >> >> + u32 fifo_status; >> >> + /* Read needs empty flag unset, write needs full flag unset */ >> >> +

Re: [PATCH v5] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

Hi Maxime, On 30 June 2017 at 01:56, Maxime Ripard wrote: > On Wed, Jun 28, 2017 at 08:39:33PM +1000, Jonathan Liu wrote: >> >> + u32 int_status; >> >> + u32 fifo_status; >> >> + /* Read needs empty flag unset, write needs full flag unset */ >> >> + u32 flag = read ?

Re: [PATCH] iommu/arm-smmu-v3: Implement shutdown method

On 6/29/2017 2:34 PM, Will Deacon wrote: On Thu, Jun 29, 2017 at 01:40:15PM -0400, Nate Watterson wrote: The shutdown method disables the SMMU and its interrupts to avoid potentially corrupting a new kernel started with kexec. Signed-off-by: Nate Watterson ---

Re: [PATCH] iommu/arm-smmu-v3: Implement shutdown method

On 6/29/2017 2:34 PM, Will Deacon wrote: On Thu, Jun 29, 2017 at 01:40:15PM -0400, Nate Watterson wrote: The shutdown method disables the SMMU and its interrupts to avoid potentially corrupting a new kernel started with kexec. Signed-off-by: Nate Watterson --- drivers/iommu/arm-smmu-v3.c |

Re: [PATCH v3 7/7] acpi, nfit: override mask

On Thu, Jun 29, 2017 at 02:16:17PM -0700, Dan Williams wrote: > On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: > > Have module parameter override_dsm_mask override the dsm_mask for > > root calls like it does for non-root dsm calls. > > > > Signed-off-by: Jerry

Re: [PATCH v3 7/7] acpi, nfit: override mask

On Thu, Jun 29, 2017 at 02:16:17PM -0700, Dan Williams wrote: > On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: > > Have module parameter override_dsm_mask override the dsm_mask for > > root calls like it does for non-root dsm calls. > > > > Signed-off-by: Jerry Hoemann > > --- > >

Re: [RFC] gpio: about the need to manage irq mapping dynamically.

On Thu, Jun 29, 2017 at 4:57 PM, Jerome Brunet wrote: > On Thu, 2017-06-29 at 16:14 +0200, Linus Walleij wrote: >> So I changed my mind, it is fine for this type of driver to call >> irq_create_mapping() in gpio_to_irq(). Preferably with some comment >> around the call. > >

Re: [RFC] gpio: about the need to manage irq mapping dynamically.

On Thu, Jun 29, 2017 at 4:57 PM, Jerome Brunet wrote: > On Thu, 2017-06-29 at 16:14 +0200, Linus Walleij wrote: >> So I changed my mind, it is fine for this type of driver to call >> irq_create_mapping() in gpio_to_irq(). Preferably with some comment >> around the call. > > What about disposing

Re: [PATCH 06/16] ntb: add check and comment for link up to mw_count and mw_get_align

On 29/06/17 03:35 PM, Allen Hubbe wrote: >> It is not a workaround for alignment restrictions of the mws. It is a >> restriction to avoid the use of >> doorbells and scratchpads. Memory windows are used exclusively. >> >> Read msi-x local and send that to the peer: > >

Re: [PATCH 06/16] ntb: add check and comment for link up to mw_count and mw_get_align

On 29/06/17 03:35 PM, Allen Hubbe wrote: >> It is not a workaround for alignment restrictions of the mws. It is a >> restriction to avoid the use of >> doorbells and scratchpads. Memory windows are used exclusively. >> >> Read msi-x local and send that to the peer: > >

Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

On Thu, Jun 29, 2017 at 4:49 PM, Greg Kroah-Hartman wrote: > On Thu, Jun 29, 2017 at 11:51:08AM +0200, Linus Walleij wrote: >> On Fri, Jun 23, 2017 at 10:09 PM, Jan Kiszka wrote: >> > On 2017-06-21 08:29, Jan Kiszka wrote: >> >> On 2017-06-20

Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

On Thu, Jun 29, 2017 at 4:49 PM, Greg Kroah-Hartman wrote: > On Thu, Jun 29, 2017 at 11:51:08AM +0200, Linus Walleij wrote: >> On Fri, Jun 23, 2017 at 10:09 PM, Jan Kiszka wrote: >> > On 2017-06-21 08:29, Jan Kiszka wrote: >> >> On 2017-06-20 13:38, Linus Walleij wrote: >> >>> On Tue, Jun 20,

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 6/29/2017 5:50 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 2:16 PM, Linda Knippers wrote: On 06/29/2017 04:42 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers wrote: On 06/29/2017 01:54 PM, Dan Williams wrote:

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 6/29/2017 5:50 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 2:16 PM, Linda Knippers wrote: On 06/29/2017 04:42 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers wrote: On 06/29/2017 01:54 PM, Dan Williams wrote: Allow volatile nfit ranges to participate in

Re: [PATCH 9/9] RISC-V: Build Infastructure

On Wed, 28 Jun 2017 15:54:42 PDT (-0700), james.ho...@imgtec.com wrote: > On Wed, Jun 28, 2017 at 11:55:38AM -0700, Palmer Dabbelt wrote: >> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile >> new file mode 100644 >> index ..7f58cd251ab8 >> --- /dev/null >> +++

Re: [PATCH 9/9] RISC-V: Build Infastructure

On Wed, 28 Jun 2017 15:54:42 PDT (-0700), james.ho...@imgtec.com wrote: > On Wed, Jun 28, 2017 at 11:55:38AM -0700, Palmer Dabbelt wrote: >> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile >> new file mode 100644 >> index ..7f58cd251ab8 >> --- /dev/null >> +++

git send-email (w/o Cc: stable)

On Thu, Jun 22, 2017 at 11:39:05AM +0200, Borislav Petkov wrote: > On Wed, Jun 21, 2017 at 10:47:40AM -0700, Luck, Tony wrote: > > I would if I could work out how to use it. From reading the manual > > page there seem to be a few options to this, but none of them appear > > to just drop a specific

Re: [PATCH 7/9] RISC-V: Paging and MMU

On Wed, 28 Jun 2017 16:09:59 PDT (-0700), james.ho...@imgtec.com wrote: > On Wed, Jun 28, 2017 at 11:55:36AM -0700, Palmer Dabbelt wrote: >> diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h >> new file mode 100644 >> index ..e1491c20d6fd >> --- /dev/null >>

git send-email (w/o Cc: stable)

On Thu, Jun 22, 2017 at 11:39:05AM +0200, Borislav Petkov wrote: > On Wed, Jun 21, 2017 at 10:47:40AM -0700, Luck, Tony wrote: > > I would if I could work out how to use it. From reading the manual > > page there seem to be a few options to this, but none of them appear > > to just drop a specific

Re: [PATCH 7/9] RISC-V: Paging and MMU

On Wed, 28 Jun 2017 16:09:59 PDT (-0700), james.ho...@imgtec.com wrote: > On Wed, Jun 28, 2017 at 11:55:36AM -0700, Palmer Dabbelt wrote: >> diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h >> new file mode 100644 >> index ..e1491c20d6fd >> --- /dev/null >>

Re: [PATCH 2/6] clk: at91: add audio pll clock driver

Hi, On 29/06/2017 at 16:47:58 -0500, Rob Herring wrote: > On Fri, Jun 23, 2017 at 11:00:55AM +0200, Quentin Schulz wrote: > > From: Nicolas Ferre > > > > This new clock driver set allows to have a fractional divided clock that > > would generate a precise clock

Re: [PATCH 2/6] clk: at91: add audio pll clock driver

Hi, On 29/06/2017 at 16:47:58 -0500, Rob Herring wrote: > On Fri, Jun 23, 2017 at 11:00:55AM +0200, Quentin Schulz wrote: > > From: Nicolas Ferre > > > > This new clock driver set allows to have a fractional divided clock that > > would generate a precise clock particularly suitable for audio >

Re: [PATCH v2 04/20] gcc-plugins: Add the randstruct plugin

On Fri, May 26, 2017 at 10:17 PM, Kees Cook wrote: > This feature is ported from grsecurity. The implementation is almost > entirely identical to the original code written by the PaX Team and > Brad Spengler. Hi Kees, I noticed new build errors that bisected back to this

Re: [PATCH v2 04/20] gcc-plugins: Add the randstruct plugin

On Fri, May 26, 2017 at 10:17 PM, Kees Cook wrote: > This feature is ported from grsecurity. The implementation is almost > entirely identical to the original code written by the PaX Team and > Brad Spengler. Hi Kees, I noticed new build errors that bisected back to this patch, which has now

Re: [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection

On Wed, Jun 28, 2017 at 9:13 PM, Li Kun wrote: > 在 2017/5/31 5:39, Kees Cook 写道: >> +bool ex_handler_refcount(const struct exception_table_entry *fixup, >> +struct pt_regs *regs, int trapnr) >> +{ >> + int reset; >> + >> + /* >> +*

Re: [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection

On Wed, Jun 28, 2017 at 9:13 PM, Li Kun wrote: > 在 2017/5/31 5:39, Kees Cook 写道: >> +bool ex_handler_refcount(const struct exception_table_entry *fixup, >> +struct pt_regs *regs, int trapnr) >> +{ >> + int reset; >> + >> + /* >> +* If we crossed from

Re: [RFC PATCH] pinctrl: rockchip: add irq_shutdown

On Fri, Jun 23, 2017 at 09:03:39PM +0800, Jeffy Chen wrote: > Currently the rockchip pinctrl driver would try to enable/disable the > gpio bank clk when enable/disable an irq. > > So when the irq core trying to shutdown an already disabled irq, it > would result in unbalanced clk disable request:

Re: [RFC PATCH] pinctrl: rockchip: add irq_shutdown

On Fri, Jun 23, 2017 at 09:03:39PM +0800, Jeffy Chen wrote: > Currently the rockchip pinctrl driver would try to enable/disable the > gpio bank clk when enable/disable an irq. > > So when the irq core trying to shutdown an already disabled irq, it > would result in unbalanced clk disable request:

Re: [PATCH v3 4/7] acpi, nfit: Use bus_dsm_mask for passthru

On Thu, Jun 29, 2017 at 2:47 PM, Jerry Hoemann wrote: > On Thu, Jun 29, 2017 at 02:35:14PM -0700, Dan Williams wrote: >> On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: >> > Populate bus_dsm_mask and use it to filter dsm calls that user can >>

Re: [PATCH v3 4/7] acpi, nfit: Use bus_dsm_mask for passthru

On Thu, Jun 29, 2017 at 2:47 PM, Jerry Hoemann wrote: > On Thu, Jun 29, 2017 at 02:35:14PM -0700, Dan Williams wrote: >> On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: >> > Populate bus_dsm_mask and use it to filter dsm calls that user can >> > make through the pass thru interface. >> >

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jun 29, 2017 at 2:16 PM, Linda Knippers wrote: > On 06/29/2017 04:42 PM, Dan Williams wrote: >> On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers >> wrote: >>> On 06/29/2017 01:54 PM, Dan Williams wrote: Allow volatile nfit ranges to

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jun 29, 2017 at 2:16 PM, Linda Knippers wrote: > On 06/29/2017 04:42 PM, Dan Williams wrote: >> On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers >> wrote: >>> On 06/29/2017 01:54 PM, Dan Williams wrote: Allow volatile nfit ranges to participate in all the same infrastructure

Re: [PATCH 2/6] clk: at91: add audio pll clock driver

On Fri, Jun 23, 2017 at 11:00:55AM +0200, Quentin Schulz wrote: > From: Nicolas Ferre > > This new clock driver set allows to have a fractional divided clock that > would generate a precise clock particularly suitable for audio > applications. > > The main audio pll

Re: [PATCH 2/6] clk: at91: add audio pll clock driver

On Fri, Jun 23, 2017 at 11:00:55AM +0200, Quentin Schulz wrote: > From: Nicolas Ferre > > This new clock driver set allows to have a fractional divided clock that > would generate a precise clock particularly suitable for audio > applications. > > The main audio pll clock has two children

Re: [PATCH v3 4/7] acpi, nfit: Use bus_dsm_mask for passthru

On Thu, Jun 29, 2017 at 02:35:14PM -0700, Dan Williams wrote: > On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: > > Populate bus_dsm_mask and use it to filter dsm calls that user can > > make through the pass thru interface. > > > > Signed-off-by: Jerry Hoemann

Re: [PATCH v3 4/7] acpi, nfit: Use bus_dsm_mask for passthru

On Thu, Jun 29, 2017 at 02:35:14PM -0700, Dan Williams wrote: > On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: > > Populate bus_dsm_mask and use it to filter dsm calls that user can > > make through the pass thru interface. > > > > Signed-off-by: Jerry Hoemann > > --- > >

Re: [RFC PATCH] userfaultfd: Add feature to request for a signal delivery

On 06/29/2017 03:46 AM, Mike Rapoport wrote: On Wed, Jun 28, 2017 at 11:23:32AM -0700, Prakash Sangappa wrote: [...] Will this result in a signal delivery? In the use case described, the database application does not need any event for hole punching. Basically, just a signal for any

[RESEND PATCH] spmi: Include OF based modalias in device uevent

Include the OF-based modalias in the uevent sent when registering SPMI devices, so that user space has a chance to autoload the kernel module for the device. Tested-by: Rob Clark Reported-by: Rob Clark Reviewed-by: Stephen Boyd

Re: [RFC PATCH] userfaultfd: Add feature to request for a signal delivery

On 06/29/2017 03:46 AM, Mike Rapoport wrote: On Wed, Jun 28, 2017 at 11:23:32AM -0700, Prakash Sangappa wrote: [...] Will this result in a signal delivery? In the use case described, the database application does not need any event for hole punching. Basically, just a signal for any

[RESEND PATCH] spmi: Include OF based modalias in device uevent

Include the OF-based modalias in the uevent sent when registering SPMI devices, so that user space has a chance to autoload the kernel module for the device. Tested-by: Rob Clark Reported-by: Rob Clark Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson --- Resend to collect Rob's T-b

[patch 0/5] genirq: Distangle irq_request/release_resources() from irq_desc->lock

The irq_request/release_resources() callbacks are a problem on RT as they are called under irq_desc->lock with interrupts disabled. Aside of that calling them under irq_desc->lock is conceptually wrong and has a (hard to trigger and probably theoretical) issue in free_irq(). See patch 4/5 for a

[patch 0/5] genirq: Distangle irq_request/release_resources() from irq_desc->lock

The irq_request/release_resources() callbacks are a problem on RT as they are called under irq_desc->lock with interrupts disabled. Aside of that calling them under irq_desc->lock is conceptually wrong and has a (hard to trigger and probably theoretical) issue in free_irq(). See patch 4/5 for a

[patch 1/5] pinctrl: samsung: Remove bogus irq_[un]mask from resource management

The irq chip callbacks irq_request/release_resources() have absolutely no business with masking and unmasking the irq. The core code unmasks the interrupt after complete setup and masks it before invoking irq_release_resources(). The unmask is actually harmful as it happens before the interrupt

[patch 1/5] pinctrl: samsung: Remove bogus irq_[un]mask from resource management

The irq chip callbacks irq_request/release_resources() have absolutely no business with masking and unmasking the irq. The core code unmasks the interrupt after complete setup and masks it before invoking irq_release_resources(). The unmask is actually harmful as it happens before the interrupt

[patch 3/5] genirq: Add mutex to irq desc to serialize request/free_irq()

The irq_request/release_resources() callbacks ar currently invoked under desc->lock with interrupts disabled. This is a source of problems on RT and conceptually not required. Add a seperate mutex to struct irq_desc which allows to serialize request/free_irq(), which can be used to move the

[patch 5/5] genirq/timings: Move free timings out of spinlocked region

No point to do memory management from a interrupt disabled spin locked region. Signed-off-by: Thomas Gleixner Cc: Daniel Lezcano --- kernel/irq/manage.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/kernel/irq/manage.c +++

[patch 3/5] genirq: Add mutex to irq desc to serialize request/free_irq()

The irq_request/release_resources() callbacks ar currently invoked under desc->lock with interrupts disabled. This is a source of problems on RT and conceptually not required. Add a seperate mutex to struct irq_desc which allows to serialize request/free_irq(), which can be used to move the

[patch 5/5] genirq/timings: Move free timings out of spinlocked region

No point to do memory management from a interrupt disabled spin locked region. Signed-off-by: Thomas Gleixner Cc: Daniel Lezcano --- kernel/irq/manage.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -1489,7 +1489,6 @@

[patch 2/5] genirq: Move bus locking into __setup_irq()

There is no point in having the irq_bus_lock() protection around all callers to __setup_irq(). Move it into __setup_irq(). This is also a preparatory patch for addressing the issues with the irq resource callbacks. Signed-off-by: Thomas Gleixner --- kernel/irq/manage.c |

[patch 2/5] genirq: Move bus locking into __setup_irq()

There is no point in having the irq_bus_lock() protection around all callers to __setup_irq(). Move it into __setup_irq(). This is also a preparatory patch for addressing the issues with the irq resource callbacks. Signed-off-by: Thomas Gleixner --- kernel/irq/manage.c | 13 + 1

[patch 4/5] genirq: Move irq resource handling out of spinlocked region

Aside of being conceptually wrong, there is also an actual (hard to trigger and mostly theoretical) problem. CPU0CPU1 free_irq(X) interrupt X spin_lock(desc->lock) wake irq thread()

[patch 4/5] genirq: Move irq resource handling out of spinlocked region

Aside of being conceptually wrong, there is also an actual (hard to trigger and mostly theoretical) problem. CPU0CPU1 free_irq(X) interrupt X spin_lock(desc->lock) wake irq thread()

Re: [PATCH 8/9] RISC-V: User-facing API

On Wed, 28 Jun 2017 15:42:37 PDT (-0700), james.ho...@imgtec.com wrote: > Hi Palmer, > > On Wed, Jun 28, 2017 at 11:55:37AM -0700, Palmer Dabbelt wrote: >> diff --git a/arch/riscv/include/asm/syscalls.h >> b/arch/riscv/include/asm/syscalls.h >> new file mode 100644 >> index

Re: [PATCH 8/9] RISC-V: User-facing API

On Wed, 28 Jun 2017 15:42:37 PDT (-0700), james.ho...@imgtec.com wrote: > Hi Palmer, > > On Wed, Jun 28, 2017 at 11:55:37AM -0700, Palmer Dabbelt wrote: >> diff --git a/arch/riscv/include/asm/syscalls.h >> b/arch/riscv/include/asm/syscalls.h >> new file mode 100644 >> index

Re: [PATCH v2 6/8] x86/entry: add unwind hint annotations

On Thu, Jun 29, 2017 at 02:09:54PM -0700, Andy Lutomirski wrote: > On Thu, Jun 29, 2017 at 12:05 PM, Josh Poimboeuf wrote: > > On Thu, Jun 29, 2017 at 11:50:18AM -0700, Andy Lutomirski wrote: > >> On Thu, Jun 29, 2017 at 10:53 AM, Josh Poimboeuf > >>

Re: [PATCH v2 6/8] x86/entry: add unwind hint annotations

On Thu, Jun 29, 2017 at 02:09:54PM -0700, Andy Lutomirski wrote: > On Thu, Jun 29, 2017 at 12:05 PM, Josh Poimboeuf wrote: > > On Thu, Jun 29, 2017 at 11:50:18AM -0700, Andy Lutomirski wrote: > >> On Thu, Jun 29, 2017 at 10:53 AM, Josh Poimboeuf > >> wrote: > >> > There's a bug here that will

Re: [PATCH] x86/uaccess: optimize copy_user_enhanced_fast_string for short string

Looks ok to me, so Ack, fwiw. I've have long hoped that Intel would actually fix their microcode overhead issue so that we could get rid of all this and just inline "rep movsb", but that hasn't been happening, so this patch looks fine. Side niote: I suspect the copy_user_generic_string() might

Re: [PATCH] x86/uaccess: optimize copy_user_enhanced_fast_string for short string

Looks ok to me, so Ack, fwiw. I've have long hoped that Intel would actually fix their microcode overhead issue so that we could get rid of all this and just inline "rep movsb", but that hasn't been happening, so this patch looks fine. Side niote: I suspect the copy_user_generic_string() might

Re: [RFC PATCH] userfaultfd: Add feature to request for a signal delivery

On 06/29/2017 01:09 AM, Michal Hocko wrote: On Wed 28-06-17 11:23:32, Prakash Sangappa wrote: On 6/28/17 6:18 AM, Mike Rapoport wrote: [...] I've just been thinking that maybe it would be possible to use UFFD_EVENT_REMOVE for this case. We anyway need to implement the generation of

Re: [RFC PATCH] userfaultfd: Add feature to request for a signal delivery

On 06/29/2017 01:09 AM, Michal Hocko wrote: On Wed 28-06-17 11:23:32, Prakash Sangappa wrote: On 6/28/17 6:18 AM, Mike Rapoport wrote: [...] I've just been thinking that maybe it would be possible to use UFFD_EVENT_REMOVE for this case. We anyway need to implement the generation of

Re: [PATCH] spmi: Include OF based modalias in device uevent

On Thu 29 Jun 14:04 PDT 2017, Stephen Boyd wrote: > On 06/28, Bjorn Andersson wrote: > > Include the OF-based modalias in the uevent sent when registering SPMI > > devices, so that user space has a chance to autoload the kernel module > > for the device. > > > > Reported-by: Rob Clark

Re: [PATCH] spmi: Include OF based modalias in device uevent

On Thu 29 Jun 14:04 PDT 2017, Stephen Boyd wrote: > On 06/28, Bjorn Andersson wrote: > > Include the OF-based modalias in the uevent sent when registering SPMI > > devices, so that user space has a chance to autoload the kernel module > > for the device. > > > > Reported-by: Rob Clark > >

RE: [PATCH 06/16] ntb: add check and comment for link up to mw_count and mw_get_align

Let me try that again... From: Hubbe, Allen > From: Logan Gunthorpe > > On 6/29/2017 2:13 PM, Allen Hubbe wrote: > > > Unfortunately, it is to work around hardware errata. That is not so > > > trivial to fix. > > > > Can you describe more what the work around is doing? Can you share the > >

RE: [PATCH 06/16] ntb: add check and comment for link up to mw_count and mw_get_align

Let me try that again... From: Hubbe, Allen > From: Logan Gunthorpe > > On 6/29/2017 2:13 PM, Allen Hubbe wrote: > > > Unfortunately, it is to work around hardware errata. That is not so > > > trivial to fix. > > > > Can you describe more what the work around is doing? Can you share the > >

Re: [PATCH v3 4/7] acpi, nfit: Use bus_dsm_mask for passthru

On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: > Populate bus_dsm_mask and use it to filter dsm calls that user can > make through the pass thru interface. > > Signed-off-by: Jerry Hoemann > --- > drivers/acpi/nfit/core.c | 5 + > 1 file

Re: [PATCH v3 4/7] acpi, nfit: Use bus_dsm_mask for passthru

On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: > Populate bus_dsm_mask and use it to filter dsm calls that user can > make through the pass thru interface. > > Signed-off-by: Jerry Hoemann > --- > drivers/acpi/nfit/core.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git

Re: [PATCH v1 3/3] dt-bindings: Interconnect device-tree bindings draft

On Tue, Jun 27, 2017 at 08:49:03PM +0300, Georgi Djakov wrote: > The interconnect API is not yet using DT bindings for expressing > the relations between the API consumers and providers. This is > posted a separate patch as it needs further discussions on how > to represent this with DT. I would

Re: [PATCH v1 3/3] dt-bindings: Interconnect device-tree bindings draft

On Tue, Jun 27, 2017 at 08:49:03PM +0300, Georgi Djakov wrote: > The interconnect API is not yet using DT bindings for expressing > the relations between the API consumers and providers. This is > posted a separate patch as it needs further discussions on how > to represent this with DT. I would

RE: [PATCH 06/16] ntb: add check and comment for link up to mw_count and mw_get_align

From: Logan Gunthorpe > On 6/29/2017 2:13 PM, Allen Hubbe wrote: > > Unfortunately, it is to work around hardware errata. That is not so > > trivial to fix. > > Can you describe more what the work around is doing? Can you share the > code? It seems odd that a workaround is based on the

RE: [PATCH 06/16] ntb: add check and comment for link up to mw_count and mw_get_align

From: Logan Gunthorpe > On 6/29/2017 2:13 PM, Allen Hubbe wrote: > > Unfortunately, it is to work around hardware errata. That is not so > > trivial to fix. > > Can you describe more what the work around is doing? Can you share the > code? It seems odd that a workaround is based on the

Re: [PATCH V2 3/4] intel_pstate: Ignore scheduler cpufreq callbacks on remote CPUs

On Thu, 2017-06-29 at 10:56 +0530, Viresh Kumar wrote: > From: Steve Muckle > > In preparation for the scheduler cpufreq callback happening on remote > CPUs, check for this case in intel_pstate which currently requires > the > callback run on the local CPU. Such

Re: [PATCH] atmel_mxt_ts: Add support for reset line

On Tue, Jun 27, 2017 at 06:24:38PM +0200, Sebastian Reichel wrote: > From: Martyn Welch > > At least some of the Atmel Maxtouch touchscreen controllers have a reset > pin. If this is not driven correctly the device will be held in reset > and will not respond. > >

Re: [PATCH V2 3/4] intel_pstate: Ignore scheduler cpufreq callbacks on remote CPUs

On Thu, 2017-06-29 at 10:56 +0530, Viresh Kumar wrote: > From: Steve Muckle > > In preparation for the scheduler cpufreq callback happening on remote > CPUs, check for this case in intel_pstate which currently requires > the > callback run on the local CPU. Such callbacks are ignored for now. Is

Re: [PATCH] atmel_mxt_ts: Add support for reset line

On Tue, Jun 27, 2017 at 06:24:38PM +0200, Sebastian Reichel wrote: > From: Martyn Welch > > At least some of the Atmel Maxtouch touchscreen controllers have a reset > pin. If this is not driven correctly the device will be held in reset > and will not respond. > > Add support for driving the

Re: [PATCH v3 3/7] libnvdimm: Add bus level dsm mask.

On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: > Add a bus level dsm_mask to nvdimm_bus_descriptor to allow the passthru > calling mechanism to specify a different mask from the cmd_mask. > > Signed-off-by: Jerry Hoemann > --- >

Re: [PATCH v3 3/7] libnvdimm: Add bus level dsm mask.

On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: > Add a bus level dsm_mask to nvdimm_bus_descriptor to allow the passthru > calling mechanism to specify a different mask from the cmd_mask. > > Signed-off-by: Jerry Hoemann > --- > include/linux/libnvdimm.h | 1 + > 1 file changed, 1

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-06-28 15:03, Paul Moore wrote: > On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote: > > On 2017-05-30 17:21, Paul Moore wrote: > >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > > ... > > >> > diff --git a/kernel/audit.c

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-06-28 15:03, Paul Moore wrote: > On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote: > > On 2017-05-30 17:21, Paul Moore wrote: > >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > > ... > > >> > diff --git a/kernel/audit.c b/kernel/audit.c > >> > index

Re: [PATCH v2 1/1] gpio: gpio-wcove: Fix GPIO control register offset calculation

On Thursday, June 29, 2017 08:28:57 PM Alan Cox wrote: > > So where can I get a handle on the people inside Intel who are obviously > > using ACPI GPIO class for shoehorning what we in the linux kernel call > > syscon or register bit misc access into the GPIO ACPI container just > > because they

Re: [PATCH v2 1/1] gpio: gpio-wcove: Fix GPIO control register offset calculation

On Thursday, June 29, 2017 08:28:57 PM Alan Cox wrote: > > So where can I get a handle on the people inside Intel who are obviously > > using ACPI GPIO class for shoehorning what we in the linux kernel call > > syscon or register bit misc access into the GPIO ACPI container just > > because they

Re: [PATCH RFC 2/2] dt-bindings: add binding documentation for Allwinner CSI

On Tue, Jun 27, 2017 at 07:07:34PM +0800, Yong Deng wrote: > Add binding documentation for Allwinner CSI. For the subject: dt-bindings: media: Add Allwinner Camera Sensor Interface (CSI) "binding documentation" is redundant. > > Signed-off-by: Yong Deng > --- >

Re: [PATCH RFC 2/2] dt-bindings: add binding documentation for Allwinner CSI

On Tue, Jun 27, 2017 at 07:07:34PM +0800, Yong Deng wrote: > Add binding documentation for Allwinner CSI. For the subject: dt-bindings: media: Add Allwinner Camera Sensor Interface (CSI) "binding documentation" is redundant. > > Signed-off-by: Yong Deng > --- >

Re: [PATCH 1/2] cpufreq: intel_pstate: Clean up after performance governor changes

On Thu, 2017-06-29 at 01:47 +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > After commit 82b4e03e01bc (intel_pstate: skip scheduler hook when in > "performance" mode) get_target_pstate_use_performance() and > get_target_pstate_use_cpu_load() are never

Re: [PATCH 1/2] cpufreq: intel_pstate: Clean up after performance governor changes

On Thu, 2017-06-29 at 01:47 +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > After commit 82b4e03e01bc (intel_pstate: skip scheduler hook when in > "performance" mode) get_target_pstate_use_performance() and > get_target_pstate_use_cpu_load() are never called if scaling_governor >

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