Re: PROBLEM: Kernel BUG in mfgpt_tick (cs5535-clockevt.c) on ALIX 2c3 - null call

On Mon, 9 Oct 2017, Daniel Lezcano wrote: On 07/10/2017 23:26, David Kozub wrote: Hi all, booting up kernel 4.14-rc3 with CS5535_CLOCK_EVENT_SRC on an ALIX 2c3 (http://pcengines.ch/alix2c3.htm) dies with: [    2.313086] cs5535-smb cs5535-smb: SCx200 device 'CS5535 ACB0' registered [   

Re: PROBLEM: Kernel BUG in mfgpt_tick (cs5535-clockevt.c) on ALIX 2c3 - null call

On Mon, 9 Oct 2017, Daniel Lezcano wrote: On 07/10/2017 23:26, David Kozub wrote: Hi all, booting up kernel 4.14-rc3 with CS5535_CLOCK_EVENT_SRC on an ALIX 2c3 (http://pcengines.ch/alix2c3.htm) dies with: [    2.313086] cs5535-smb cs5535-smb: SCx200 device 'CS5535 ACB0' registered [   

[PATCH] ftrace/docs: Add documentation on how to use ftrace from within the kernel

With the coming removal of jprobes, using ftrace callbacks is one of the utilities that replace the jprobes functionality. Having a document that explains how to use ftrace as such will help in the transition from jprobes to ftrace. This document is for kernel developers that require attaching a

[PATCH] ftrace/docs: Add documentation on how to use ftrace from within the kernel

With the coming removal of jprobes, using ftrace callbacks is one of the utilities that replace the jprobes functionality. Having a document that explains how to use ftrace as such will help in the transition from jprobes to ftrace. This document is for kernel developers that require attaching a

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()

On Mon, Oct 9, 2017 at 4:59 AM, Daniel Vetter wrote: > On Sun, Oct 08, 2017 at 03:43:35PM +0100, Chris Wilson wrote: >> Quoting Harsha Sharma (2017-10-08 15:04:07) >> > @@ -624,7 +624,7 @@ static bool intel_fbdev_init_bios(struct drm_device >> > *dev, >> >

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()

On Mon, Oct 9, 2017 at 4:59 AM, Daniel Vetter wrote: > On Sun, Oct 08, 2017 at 03:43:35PM +0100, Chris Wilson wrote: >> Quoting Harsha Sharma (2017-10-08 15:04:07) >> > @@ -624,7 +624,7 @@ static bool intel_fbdev_init_bios(struct drm_device >> > *dev, >> > ifbdev->preferred_bpp =

[PATCH v3] ftrace: Clear hashes of stale ips of init memory

Filters should be cleared of init functions during freeing of init memory when the ftrace dyn records are released. However in current code, the filters are left as is. This patch clears the hashes of the saved init functions when the init memory is freed. This fixes the following issue

[PATCH v3] ftrace: Clear hashes of stale ips of init memory

Filters should be cleared of init functions during freeing of init memory when the ftrace dyn records are released. However in current code, the filters are left as is. This patch clears the hashes of the saved init functions when the init memory is freed. This fixes the following issue

Re: [PATCH v2] ftrace: Clear hashes of stale ips of init memory

On Mon, Oct 9, 2017 at 12:11 PM, Joel Fernandes wrote: > On Mon, Oct 9, 2017 at 11:53 AM, Joel Fernandes wrote: > [..] >> + >> void ftrace_free_mem(struct module *mod, void *start_ptr, void *end_ptr) >> { >> unsigned long start = (unsigned

Re: [PATCH v2] ftrace: Clear hashes of stale ips of init memory

On Mon, Oct 9, 2017 at 12:11 PM, Joel Fernandes wrote: > On Mon, Oct 9, 2017 at 11:53 AM, Joel Fernandes wrote: > [..] >> + >> void ftrace_free_mem(struct module *mod, void *start_ptr, void *end_ptr) >> { >> unsigned long start = (unsigned long)(start_ptr); >> @@ -6076,8 +6135,12 @@

Build regressions/improvements in v4.14-rc4

Below is the list of build error/warning regressions/improvements in v4.14-rc4[1] compared to v4.13[2]. Summarized: - build errors: +7/-0 - build warnings: +1502/-6250 JFYI, when comparing v4.14-rc4[1] to v4.14-rc3[3], the summaries are: - build errors: +1/-2 - build warnings: +817/-384

Build regressions/improvements in v4.14-rc4

Below is the list of build error/warning regressions/improvements in v4.14-rc4[1] compared to v4.13[2]. Summarized: - build errors: +7/-0 - build warnings: +1502/-6250 JFYI, when comparing v4.14-rc4[1] to v4.14-rc3[3], the summaries are: - build errors: +1/-2 - build warnings: +817/-384

Re: [tho...@m3y3r.de: Re: [PATCH] um: Fix kcov crash before kernel is started.]

On Mon, Oct 09, 2017 at 08:10:45PM +0200, Dmitry Vyukov wrote: > On Mon, Oct 9, 2017 at 6:47 PM, Thomas Meyer wrote: > > - Forwarded message from Thomas Meyer - > > > > Hi, > > > > are you able to shed light on this topic? > > Any help is greatly

Re: [tho...@m3y3r.de: Re: [PATCH] um: Fix kcov crash before kernel is started.]

On Mon, Oct 09, 2017 at 08:10:45PM +0200, Dmitry Vyukov wrote: > On Mon, Oct 9, 2017 at 6:47 PM, Thomas Meyer wrote: > > - Forwarded message from Thomas Meyer - > > > > Hi, > > > > are you able to shed light on this topic? > > Any help is greatly appreciated! > > > > With kind regards >

Re: [PATCH] [media] ov5645: I2C address change

Hi Todor, On Monday, 9 October 2017 19:18:17 EEST Todor Tomov wrote: > On 9.10.2017 15:52, Laurent Pinchart wrote: > > On Monday, 9 October 2017 12:34:26 EEST Sakari Ailus wrote: > >> On Mon, Oct 09, 2017 at 11:36:01AM +0300, Todor Tomov wrote: > >>> On 4.10.2017 13:47, Laurent Pinchart wrote:

Re: [PATCH] [media] ov5645: I2C address change

Hi Todor, On Monday, 9 October 2017 19:18:17 EEST Todor Tomov wrote: > On 9.10.2017 15:52, Laurent Pinchart wrote: > > On Monday, 9 October 2017 12:34:26 EEST Sakari Ailus wrote: > >> On Mon, Oct 09, 2017 at 11:36:01AM +0300, Todor Tomov wrote: > >>> On 4.10.2017 13:47, Laurent Pinchart wrote:

Re: [PATCH] w1: keep balance of mutex locks and refcnts

Hi Alexey 07.10.2017, 20:59, "Alexey Khoroshilov" : > Is it possible to switch to a nested variant: > mutex_lock-atomic_inc-atomic_dec-mutex_unlock > or > atomic_inc-mutex_lock-mutex_unlock-atomic_dec > ? Yeah, you are right, it is a bit messy - we drop the lock while

Re: [PATCH] w1: keep balance of mutex locks and refcnts

Hi Alexey 07.10.2017, 20:59, "Alexey Khoroshilov" : > Is it possible to switch to a nested variant: > mutex_lock-atomic_inc-atomic_dec-mutex_unlock > or > atomic_inc-mutex_lock-mutex_unlock-atomic_dec > ? Yeah, you are right, it is a bit messy - we drop the lock while sleeping waiting for the

Re: linux-next: manual merge of the staging tree with the media tree

On Mon, Oct 09, 2017 at 09:05:32PM +0200, Greg KH wrote: > What fix? :( It's a null diff, the change isn't needed any more. signature.asc Description: PGP signature

Re: linux-next: manual merge of the staging tree with the media tree

On Mon, Oct 09, 2017 at 09:05:32PM +0200, Greg KH wrote: > What fix? :( It's a null diff, the change isn't needed any more. signature.asc Description: PGP signature

Re: [PATCH v2] ftrace: Clear hashes of stale ips of init memory

On Mon, Oct 9, 2017 at 11:53 AM, Joel Fernandes wrote: [..] > + > void ftrace_free_mem(struct module *mod, void *start_ptr, void *end_ptr) > { > unsigned long start = (unsigned long)(start_ptr); > @@ -6076,8 +6135,12 @@ void ftrace_free_mem(struct module *mod, void >

Re: [PATCH v2] ftrace: Clear hashes of stale ips of init memory

On Mon, Oct 9, 2017 at 11:53 AM, Joel Fernandes wrote: [..] > + > void ftrace_free_mem(struct module *mod, void *start_ptr, void *end_ptr) > { > unsigned long start = (unsigned long)(start_ptr); > @@ -6076,8 +6135,12 @@ void ftrace_free_mem(struct module *mod, void > *start_ptr, void

[PATCH] Documentation: leds: Update 00-INDEX file

Add missing entries for the following documentation files: - leds-class-flash.txt - leds-lm3556.txt - leds-mlxcpld.txt - ledtrig-usbport.txt - uleds.txt Signed-off-by: Jacek Anaszewski --- Documentation/leds/00-INDEX | 10 ++ 1 file changed, 10 insertions(+)

[PATCH] Documentation: leds: Update 00-INDEX file

Add missing entries for the following documentation files: - leds-class-flash.txt - leds-lm3556.txt - leds-mlxcpld.txt - ledtrig-usbport.txt - uleds.txt Signed-off-by: Jacek Anaszewski --- Documentation/leds/00-INDEX | 10 ++ 1 file changed, 10 insertions(+) diff --git

Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation

Hi Rik, Thanks for the blazingly fast response :-) On 9 October 2017 at 21:08, Rik van Riel wrote: > On Mon, 2017-10-09 at 21:06 +0200, Michael Kerrisk (man-pages) wrote: >> Hi Rik, >> >> I have a follow-up question re wipe-on-fork. What are the semantics >> for this setting

Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation

Hi Rik, Thanks for the blazingly fast response :-) On 9 October 2017 at 21:08, Rik van Riel wrote: > On Mon, 2017-10-09 at 21:06 +0200, Michael Kerrisk (man-pages) wrote: >> Hi Rik, >> >> I have a follow-up question re wipe-on-fork. What are the semantics >> for this setting with respect to

Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation

On Mon, 2017-10-09 at 21:06 +0200, Michael Kerrisk (man-pages) wrote: > Hi Rik, > > I have a follow-up question re wipe-on-fork. What are the semantics > for this setting with respect to fork() and exec()? That is, in the > child of a fork(), does the flag remain set for the specified address >

Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation

On Mon, 2017-10-09 at 21:06 +0200, Michael Kerrisk (man-pages) wrote: > Hi Rik, > > I have a follow-up question re wipe-on-fork. What are the semantics > for this setting with respect to fork() and exec()? That is, in the > child of a fork(), does the flag remain set for the specified address >

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

> > Ok, but I'm still missing why you think that is needed. What would be the > second page table walker that needs implementing? > > I guess we could implement that on arm64 using our current vmemmap_populate > logic and an explicit memset. > Hi Will, What do you mean by explicit memset()? We

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

> > Ok, but I'm still missing why you think that is needed. What would be the > second page table walker that needs implementing? > > I guess we could implement that on arm64 using our current vmemmap_populate > logic and an explicit memset. > Hi Will, What do you mean by explicit memset()? We

Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation

Hi Rik, I have a follow-up question re wipe-on-fork. What are the semantics for this setting with respect to fork() and exec()? That is, in the child of a fork(), does the flag remain set for the specified address range? (My quick read of the source suggests yes, but I have not tested.) And, when

Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation

Hi Rik, I have a follow-up question re wipe-on-fork. What are the semantics for this setting with respect to fork() and exec()? That is, in the child of a fork(), does the flag remain set for the specified address range? (My quick read of the source suggests yes, but I have not tested.) And, when

[PATCH] watchdog: hpwdt: change maintainer.

Signed-off-by: Jerry Hoemann --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 2d3d750..e7dc993 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6114,7 +6114,7 @@ S:Odd Fixes F:

[PATCH] watchdog: hpwdt: change maintainer.

Signed-off-by: Jerry Hoemann --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 2d3d750..e7dc993 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6114,7 +6114,7 @@ S:Odd Fixes F: drivers/media/usb/hdpvr/ HEWLETT

Re: linux-next: manual merge of the staging tree with the media tree

On Mon, Oct 09, 2017 at 07:26:54PM +0100, Mark Brown wrote: > Hi Greg, > > Today's linux-next merge of the staging tree got a conflict in: > > drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c > > between commit: > >866af46e6ebbc ("media: Staging: atomisp: fix

Re: linux-next: manual merge of the staging tree with the media tree

On Mon, Oct 09, 2017 at 07:26:54PM +0100, Mark Brown wrote: > Hi Greg, > > Today's linux-next merge of the staging tree got a conflict in: > > drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c > > between commit: > >866af46e6ebbc ("media: Staging: atomisp: fix

Re: [PATCH 08/13] net/ipv4/tcp_input.c: kill off ACCESS_ONCE()

On Mon, Oct 09, 2017 at 07:28:45PM +0100, Mark Rutland wrote: > - ACCESS_ONCE(sk->sk_pacing_rate) = min_t(u64, rate, > - sk->sk_max_pacing_rate); > + WRITE_ONCE(sk->sk_pacing_rate) = min_t(u64, rate, > +

Re: [PATCH 08/13] net/ipv4/tcp_input.c: kill off ACCESS_ONCE()

On Mon, Oct 09, 2017 at 07:28:45PM +0100, Mark Rutland wrote: > - ACCESS_ONCE(sk->sk_pacing_rate) = min_t(u64, rate, > - sk->sk_max_pacing_rate); > + WRITE_ONCE(sk->sk_pacing_rate) = min_t(u64, rate, > +

Re: [PATCH] perf tools: unbreak perf record for arm/arm64

On Mon, Oct 09, 2017 at 04:00:00PM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Oct 09, 2017 at 11:22:00AM +0100, Will Deacon escreveu: > > On Fri, Oct 06, 2017 at 07:38:22PM +0100, Mark Rutland wrote: > > > Currently, perf record is broken on arm/arm64 systems when the PMU is > > > specified

Re: [PATCH] perf tools: unbreak perf record for arm/arm64

On Mon, Oct 09, 2017 at 04:00:00PM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Oct 09, 2017 at 11:22:00AM +0100, Will Deacon escreveu: > > On Fri, Oct 06, 2017 at 07:38:22PM +0100, Mark Rutland wrote: > > > Currently, perf record is broken on arm/arm64 systems when the PMU is > > > specified

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

Hi Pavel, On Mon, Oct 09, 2017 at 02:59:09PM -0400, Pavel Tatashin wrote: > > We have two table walks even with your patch series applied afaict: one in > > our definition of vmemmap_populate (arch/arm64/mm/mmu.c) and this one > > in the core code. > > I meant to say implementing two new page

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

Hi Pavel, On Mon, Oct 09, 2017 at 02:59:09PM -0400, Pavel Tatashin wrote: > > We have two table walks even with your patch series applied afaict: one in > > our definition of vmemmap_populate (arch/arm64/mm/mmu.c) and this one > > in the core code. > > I meant to say implementing two new page

Re: [Outreachy kernel] Re: [PATCH v2] drm/tegra: Replace dev_* with DRM_DEV_*

On Mon, Sep 25, 2017 at 3:38 AM, Thierry Reding wrote: > On Sun, Sep 24, 2017 at 10:13:57PM +0530, Harsha Sharma wrote: >> Replace all occurences of dev_info/err/dbg with DRM_DEV_INFO/ >> ERROR/DEBUG as we have DRM_DEV_* variants of drm print macros >> Done using

Re: [Outreachy kernel] Re: [PATCH v2] drm/tegra: Replace dev_* with DRM_DEV_*

On Mon, Sep 25, 2017 at 3:38 AM, Thierry Reding wrote: > On Sun, Sep 24, 2017 at 10:13:57PM +0530, Harsha Sharma wrote: >> Replace all occurences of dev_info/err/dbg with DRM_DEV_INFO/ >> ERROR/DEBUG as we have DRM_DEV_* variants of drm print macros >> Done using following coccinelle semantic

Re: [PATCH 2/2] of/fdt: skip unflattening of disabled nodes

On Sun, Oct 8, 2017 at 5:57 PM, Frank Rowand wrote: > On 10/03/17 09:18, Rob Herring wrote: >> For static DT usecases, we don't need the disabled nodes and can skip >> unflattening. This saves a significant amount of RAM in memory constrained >> cases. In one example on

Re: [PATCH 2/2] of/fdt: skip unflattening of disabled nodes

On Sun, Oct 8, 2017 at 5:57 PM, Frank Rowand wrote: > On 10/03/17 09:18, Rob Herring wrote: >> For static DT usecases, we don't need the disabled nodes and can skip >> unflattening. This saves a significant amount of RAM in memory constrained >> cases. In one example on STM32F469, the RAM usage

Re: [PATCH] perf tools: unbreak perf record for arm/arm64

Em Mon, Oct 09, 2017 at 11:22:00AM +0100, Will Deacon escreveu: > On Fri, Oct 06, 2017 at 07:38:22PM +0100, Mark Rutland wrote: > > Currently, perf record is broken on arm/arm64 systems when the PMU is > > specified explicitly as part of the event, e.g. > > > > $ ./perf record -e

Re: [PATCH] perf tools: unbreak perf record for arm/arm64

Em Mon, Oct 09, 2017 at 11:22:00AM +0100, Will Deacon escreveu: > On Fri, Oct 06, 2017 at 07:38:22PM +0100, Mark Rutland wrote: > > Currently, perf record is broken on arm/arm64 systems when the PMU is > > specified explicitly as part of the event, e.g. > > > > $ ./perf record -e

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

Hi Will, > We have two table walks even with your patch series applied afaict: one in > our definition of vmemmap_populate (arch/arm64/mm/mmu.c) and this one > in the core code. I meant to say implementing two new page table walkers, not at runtime. > My worry is that these are actually highly

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

Hi Will, > We have two table walks even with your patch series applied afaict: one in > our definition of vmemmap_populate (arch/arm64/mm/mmu.c) and this one > in the core code. I meant to say implementing two new page table walkers, not at runtime. > My worry is that these are actually highly

[PATCH v2] ftrace: Clear hashes of stale ips of init memory

Filters should be cleared of init functions during freeing of init memory when the ftrace dyn records are released. However in current code, the filters are left as is. This patch clears the hashes of the saved init functions when the init memory is freed. This fixes the following issue

[PATCH v2] ftrace: Clear hashes of stale ips of init memory

Filters should be cleared of init functions during freeing of init memory when the ftrace dyn records are released. However in current code, the filters are left as is. This patch clears the hashes of the saved init functions when the init memory is freed. This fixes the following issue

Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory

On 10/8/17 11:36 PM, Michal Hocko wrote: On Mon 09-10-17 08:33:16, Michal Hocko wrote: On Sat 07-10-17 00:37:55, Yang Shi wrote: On 10/6/17 2:37 AM, Michal Hocko wrote: On Thu 05-10-17 05:29:10, Yang Shi wrote: [...] + list_for_each_entry_safe(s, s2, _caches, list) { +

Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory

On 10/8/17 11:36 PM, Michal Hocko wrote: On Mon 09-10-17 08:33:16, Michal Hocko wrote: On Sat 07-10-17 00:37:55, Yang Shi wrote: On 10/6/17 2:37 AM, Michal Hocko wrote: On Thu 05-10-17 05:29:10, Yang Shi wrote: [...] + list_for_each_entry_safe(s, s2, _caches, list) { +

Re: [PATCH v5] crypto: s5p-sss: Add HASH support for Exynos

On Mon, Oct 09, 2017 at 01:12:30PM +0200, Kamil Konieczny wrote: > Add support for MD5, SHA1, SHA256 hash algorithms for Exynos HW. > It uses the crypto framework asynchronous hash api. > It is based on omap-sham.c driver. > S5P has some HW differencies and is not implemented. > > Modifications

Re: [PATCH v5] crypto: s5p-sss: Add HASH support for Exynos

On Mon, Oct 09, 2017 at 01:12:30PM +0200, Kamil Konieczny wrote: > Add support for MD5, SHA1, SHA256 hash algorithms for Exynos HW. > It uses the crypto framework asynchronous hash api. > It is based on omap-sham.c driver. > S5P has some HW differencies and is not implemented. > > Modifications

Re: [PATCH v4 1/2] PCI: pci-host-generic: add support for Synopsys DesignWare RC in ECAM mode

On 9 October 2017 at 17:46, Will Deacon wrote: > On Fri, Oct 06, 2017 at 06:21:59PM -0500, Bjorn Helgaas wrote: >> On Fri, Oct 06, 2017 at 05:39:18PM +0100, Ard Biesheuvel wrote: >> > diff --git a/drivers/pci/host/pci-host-generic.c >> > b/drivers/pci/host/pci-host-generic.c

Re: [PATCH v4 1/2] PCI: pci-host-generic: add support for Synopsys DesignWare RC in ECAM mode

On 9 October 2017 at 17:46, Will Deacon wrote: > On Fri, Oct 06, 2017 at 06:21:59PM -0500, Bjorn Helgaas wrote: >> On Fri, Oct 06, 2017 at 05:39:18PM +0100, Ard Biesheuvel wrote: >> > diff --git a/drivers/pci/host/pci-host-generic.c >> > b/drivers/pci/host/pci-host-generic.c >> > index

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

On Mon, Oct 09, 2017 at 08:14:33PM +0200, Michal Hocko wrote: > On Mon 09-10-17 13:51:47, Pavel Tatashin wrote: > > I can go back to that approach, if Michal OK with it. But, that would > > mean that I would need to touch every single architecture that > > implements vmemmap_populate(), and also

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

On Mon, Oct 09, 2017 at 08:14:33PM +0200, Michal Hocko wrote: > On Mon 09-10-17 13:51:47, Pavel Tatashin wrote: > > I can go back to that approach, if Michal OK with it. But, that would > > mean that I would need to touch every single architecture that > > implements vmemmap_populate(), and also

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

On Mon, Oct 09, 2017 at 02:42:32PM -0400, Pavel Tatashin wrote: > Hi Will, > > In addition to what Michal wrote: > > > As an interim step, why not introduce something like > > vmemmap_alloc_block_flags and make the page-table walking opt-out for > > architectures that don't want it? Then we can

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

On Mon, Oct 09, 2017 at 02:42:32PM -0400, Pavel Tatashin wrote: > Hi Will, > > In addition to what Michal wrote: > > > As an interim step, why not introduce something like > > vmemmap_alloc_block_flags and make the page-table walking opt-out for > > architectures that don't want it? Then we can

Re: [PATCH v2 10/16] iommu: introduce device fault report API

On Fri, 6 Oct 2017 10:36:02 +0100 Jean-Philippe Brucker wrote: > Hi Jacob, > > On 06/10/17 00:03, Jacob Pan wrote: > > Traditionally, device specific faults are detected and handled > > within their own device drivers. When IOMMU is enabled, faults such > > as DMA

Re: [PATCH v2 10/16] iommu: introduce device fault report API

On Fri, 6 Oct 2017 10:36:02 +0100 Jean-Philippe Brucker wrote: > Hi Jacob, > > On 06/10/17 00:03, Jacob Pan wrote: > > Traditionally, device specific faults are detected and handled > > within their own device drivers. When IOMMU is enabled, faults such > > as DMA related transactions are

Re: [PATCH v2 1/3] kcov: support comparison operands collection

On Mon, Oct 9, 2017 at 8:37 PM, Mark Rutland wrote: > On Mon, Oct 09, 2017 at 08:15:10PM +0200, 'Dmitry Vyukov' via syzkaller wrote: >> On Mon, Oct 9, 2017 at 5:46 PM, Mark Rutland wrote: >> > On Mon, Oct 09, 2017 at 05:05:19PM +0200, Alexander

Re: [PATCH v2 1/3] kcov: support comparison operands collection

On Mon, Oct 9, 2017 at 8:37 PM, Mark Rutland wrote: > On Mon, Oct 09, 2017 at 08:15:10PM +0200, 'Dmitry Vyukov' via syzkaller wrote: >> On Mon, Oct 9, 2017 at 5:46 PM, Mark Rutland wrote: >> > On Mon, Oct 09, 2017 at 05:05:19PM +0200, Alexander Potapenko wrote: > >> > ... I note that a few

[PATCH] ARM: dts: imx7d: Invert legacy PCI irq mapping

According to i.MX7D reference manual (Rev. 0.1, table 7-1, page 1221) legacy PCI interrupt mapping is as follows: - PCIE INT A is IRQ 122 - PCIE INT B is IRQ 123 - PCIE INT C is IRQ 124 - PCIE INT D is IRQ 125 Invert the mapping information in corresponding DT node to reflect that. Cc:

Re: [PATCH] leds: tca6507: Remove unnecessary reg check

Hi Christos, Thanks for the patch. On 10/08/2017 08:55 PM, Christos Gkekas wrote: > Variable reg is unsigned so checking whether it is less than zero is not > necessary. > > Signed-off-by: Christos Gkekas > --- > drivers/leds/leds-tca6507.c | 2 +- > 1 file changed, 1

[PATCH] ARM: dts: imx7d: Invert legacy PCI irq mapping

According to i.MX7D reference manual (Rev. 0.1, table 7-1, page 1221) legacy PCI interrupt mapping is as follows: - PCIE INT A is IRQ 122 - PCIE INT B is IRQ 123 - PCIE INT C is IRQ 124 - PCIE INT D is IRQ 125 Invert the mapping information in corresponding DT node to reflect that. Cc:

Re: [PATCH] leds: tca6507: Remove unnecessary reg check

Hi Christos, Thanks for the patch. On 10/08/2017 08:55 PM, Christos Gkekas wrote: > Variable reg is unsigned so checking whether it is less than zero is not > necessary. > > Signed-off-by: Christos Gkekas > --- > drivers/leds/leds-tca6507.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

Hi Will, In addition to what Michal wrote: > As an interim step, why not introduce something like > vmemmap_alloc_block_flags and make the page-table walking opt-out for > architectures that don't want it? Then we can just pass __GFP_ZERO from > our vmemmap_populate where necessary and other

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

Hi Will, In addition to what Michal wrote: > As an interim step, why not introduce something like > vmemmap_alloc_block_flags and make the page-table walking opt-out for > architectures that don't want it? Then we can just pass __GFP_ZERO from > our vmemmap_populate where necessary and other

[PATCH] arm64: dts: rockchip: enable touchpad button for rk3399-gru-kevin

Adding the linux,gpio-keymap entry also has the side-effect of making the driver register the touchpad as a touchpad rather than another touchscreen. The index for BTN_LEFT was found by trial and error. Signed-off-by: Emil Renner Berthing ---

[PATCH] arm64: dts: rockchip: enable touchpad button for rk3399-gru-kevin

Adding the linux,gpio-keymap entry also has the side-effect of making the driver register the touchpad as a touchpad rather than another touchscreen. The index for BTN_LEFT was found by trial and error. Signed-off-by: Emil Renner Berthing --- arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts |

RE: [PATCH v1 RFC 1/7] Replace license with GPL

> From: tristram...@microchip.com > > Sent: 06 October 2017 21:33 > > Replace license with GPL. > > Don't you need permission from all the people who have updated > the files in order to make this change? > > David I am a little confused by your comment. The 4 original KSZ9477 DSA driver

RE: [PATCH v1 RFC 1/7] Replace license with GPL

> From: tristram...@microchip.com > > Sent: 06 October 2017 21:33 > > Replace license with GPL. > > Don't you need permission from all the people who have updated > the files in order to make this change? > > David I am a little confused by your comment. The 4 original KSZ9477 DSA driver

Re: [PATCH v2 1/3] kcov: support comparison operands collection

On Mon, Oct 09, 2017 at 08:15:10PM +0200, 'Dmitry Vyukov' via syzkaller wrote: > On Mon, Oct 9, 2017 at 5:46 PM, Mark Rutland wrote: > > On Mon, Oct 09, 2017 at 05:05:19PM +0200, Alexander Potapenko wrote: > > ... I note that a few places in the kernel use a 128-bit type.

Re: [PATCH v2 1/3] kcov: support comparison operands collection

On Mon, Oct 09, 2017 at 08:15:10PM +0200, 'Dmitry Vyukov' via syzkaller wrote: > On Mon, Oct 9, 2017 at 5:46 PM, Mark Rutland wrote: > > On Mon, Oct 09, 2017 at 05:05:19PM +0200, Alexander Potapenko wrote: > > ... I note that a few places in the kernel use a 128-bit type. Are > > 128-bit

linux-next: manual merge of the cgroup tree with the net-next tree

Hi Tejun, Today's linux-next merge of the cgroup tree got a conflict in: kernel/cgroup/cgroup.c between commit: 324bda9e6c5ad ("bpf: multi program support for cgroup+bpf") from the net-next tree and commit: 041cd640b2f3c ("cgroup: Implement cgroup2 basic CPU usage accounting") from

linux-next: manual merge of the cgroup tree with the net-next tree

Hi Tejun, Today's linux-next merge of the cgroup tree got a conflict in: kernel/cgroup/cgroup.c between commit: 324bda9e6c5ad ("bpf: multi program support for cgroup+bpf") from the net-next tree and commit: 041cd640b2f3c ("cgroup: Implement cgroup2 basic CPU usage accounting") from

Re: [PATCH] block: remove unnecessary NULL checks in bioset_integrity_free()

On Oct 6, 2017, at 6:26 PM, Tim Hansen wrote: > On Fri, Oct 06, 2017 at 01:04:25PM -0600, Jens Axboe wrote: >> On 10/05/2017 12:09 PM, Tim Hansen wrote: >>> mempool_destroy() already checks for a NULL value being passed in, this >>> eliminates duplicate checks. >>> >>>

Re: [PATCH] block: remove unnecessary NULL checks in bioset_integrity_free()

On Oct 6, 2017, at 6:26 PM, Tim Hansen wrote: > On Fri, Oct 06, 2017 at 01:04:25PM -0600, Jens Axboe wrote: >> On 10/05/2017 12:09 PM, Tim Hansen wrote: >>> mempool_destroy() already checks for a NULL value being passed in, this >>> eliminates duplicate checks. >>> >>> This was caught by

[PATCH 02/13] EDAC, altera: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 02/13] EDAC, altera: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 06/13] media: dvb_ringbuffer: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 06/13] media: dvb_ringbuffer: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 09/13] net: average: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 09/13] net: average: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

Re: net/sunrpc: v4.14-rc4 lockdep warning

On Mon, 2017-10-09 at 19:17 +0100, Lorenzo Pieralisi wrote: > Hi, > > I have run into the lockdep warning below while running v4.14-rc3/rc4 > on an ARM64 defconfig Juno dev board - reporting it to check whether > it is a known/genuine issue. > > Please let me know if you need further debug data

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

On Mon, Oct 9, 2017 at 11:08 AM, Borislav Petkov wrote: > On Mon, Oct 09, 2017 at 10:50:34AM -0700, Andy Lutomirski wrote: >> The choices are somewhat lazy and not lazy at all. > > Yeah, you probably should explain those choices somewhere and what > exactly they mean. > >> The

Re: net/sunrpc: v4.14-rc4 lockdep warning

On Mon, 2017-10-09 at 19:17 +0100, Lorenzo Pieralisi wrote: > Hi, > > I have run into the lockdep warning below while running v4.14-rc3/rc4 > on an ARM64 defconfig Juno dev board - reporting it to check whether > it is a known/genuine issue. > > Please let me know if you need further debug data

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

On Mon, Oct 9, 2017 at 11:08 AM, Borislav Petkov wrote: > On Mon, Oct 09, 2017 at 10:50:34AM -0700, Andy Lutomirski wrote: >> The choices are somewhat lazy and not lazy at all. > > Yeah, you probably should explain those choices somewhere and what > exactly they mean. > >> The degree of

[PATCH 07/13] net: netlink/netfilter: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 07/13] net: netlink/netfilter: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 08/13] net/ipv4/tcp_input.c: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 08/13] net/ipv4/tcp_input.c: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 10/13] samples: mic/mpssd/mpssd.c: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 10/13] samples: mic/mpssd/mpssd.c: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 11/13] selftests/powerpc: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 13/13] rcutorture: formal: prepare for ACCESS_ONCE() removal

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

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