[PATCH V3 2/4] blkcg: delete unused APIs

2017-09-14 Thread Shaohua Li
From: Shaohua Li Nobody uses the APIs right now. Acked-by: Tejun Heo Signed-off-by: Shaohua Li --- block/bio.c| 31 --- include/linux/bio.h| 2 -- include/linux/blk-cgroup.h | 12 3

[PATCH V3 2/4] blkcg: delete unused APIs

2017-09-14 Thread Shaohua Li
From: Shaohua Li Nobody uses the APIs right now. Acked-by: Tejun Heo Signed-off-by: Shaohua Li --- block/bio.c| 31 --- include/linux/bio.h| 2 -- include/linux/blk-cgroup.h | 12 3 files changed, 45 deletions(-) diff --git

[PATCH V3 4/4] block/loop: make loop cgroup aware

2017-09-14 Thread Shaohua Li
From: Shaohua Li loop block device handles IO in a separate thread. The actual IO dispatched isn't cloned from the IO loop device received, so the dispatched IO loses the cgroup context. I'm ignoring buffer IO case now, which is quite complicated. Making the loop thread aware

[PATCH V3 4/4] block/loop: make loop cgroup aware

2017-09-14 Thread Shaohua Li
From: Shaohua Li loop block device handles IO in a separate thread. The actual IO dispatched isn't cloned from the IO loop device received, so the dispatched IO loses the cgroup context. I'm ignoring buffer IO case now, which is quite complicated. Making the loop thread aware cgroup context

[PATCH V3 3/4] block: make blkcg aware of kthread stored original cgroup info

2017-09-14 Thread Shaohua Li
From: Shaohua Li bio_blkcg is the only API to get cgroup info for a bio right now. If bio_blkcg finds current task is a kthread and has original blkcg associated, it will use the css instead of associating the bio to current task. This makes it possible that kthread dispatches bios

[PATCH V3 3/4] block: make blkcg aware of kthread stored original cgroup info

2017-09-14 Thread Shaohua Li
From: Shaohua Li bio_blkcg is the only API to get cgroup info for a bio right now. If bio_blkcg finds current task is a kthread and has original blkcg associated, it will use the css instead of associating the bio to current task. This makes it possible that kthread dispatches bios on behalf of

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

2017-09-14 Thread Andrew Lunn
> Can you clarify what type of registers it is you are wanting to read? > We already have ethtool which is meant to allow reading the device > registers for a given netdev. As long as the port has a netdev > associated it then there is no need to be getting into debugfs since > we should probably

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

2017-09-14 Thread Andrew Lunn
> Can you clarify what type of registers it is you are wanting to read? > We already have ethtool which is meant to allow reading the device > registers for a given netdev. As long as the port has a netdev > associated it then there is no need to be getting into debugfs since > we should probably

Re: [PATCH 2/2] integrity: replace call to integrity_read_file with kernel version

2017-09-14 Thread James Morris
On Thu, 14 Sep 2017, Christoph Hellwig wrote: > On Fri, Sep 15, 2017 at 06:21:28AM +1000, James Morris wrote: > > So, to be clear, this patch solves the XFS deadlock using a different > > approach (to the now reverted integrity_read approach), which Christoph > > also says is more correct

Re: [PATCH 2/2] integrity: replace call to integrity_read_file with kernel version

2017-09-14 Thread James Morris
On Thu, 14 Sep 2017, Christoph Hellwig wrote: > On Fri, Sep 15, 2017 at 06:21:28AM +1000, James Morris wrote: > > So, to be clear, this patch solves the XFS deadlock using a different > > approach (to the now reverted integrity_read approach), which Christoph > > also says is more correct

Re: [PATCH 2/2] mfd: fsl-imx25: clean up irq settings during removal

2017-09-14 Thread Martin Kaiser
Thus wrote Lee Jones (lee.jo...@linaro.org): > On Tue, 12 Sep 2017, Martin Kaiser wrote: > > When fsl-imx25-tsadc is compiled as a module, unloading and reloading > > the module will lead to a crash. > > Add a removal function which clears the irq handler and removes the irq > > domain. With

Re: [PATCH 2/2] mfd: fsl-imx25: clean up irq settings during removal

2017-09-14 Thread Martin Kaiser
Thus wrote Lee Jones (lee.jo...@linaro.org): > On Tue, 12 Sep 2017, Martin Kaiser wrote: > > When fsl-imx25-tsadc is compiled as a module, unloading and reloading > > the module will lead to a crash. > > Add a removal function which clears the irq handler and removes the irq > > domain. With

Re: "objtool orc" creates invalid file arch/x86/kernel/time.o

2017-09-14 Thread Josh Poimboeuf
On Sun, Sep 10, 2017 at 10:38:58PM +0200, Arnd Bergmann wrote: > Hi Josh, > > I have a randconfig build that produces a link error: > > built-in.o: member arch/x86/kernel/time.o in archive is not an object > > I've traced it down to the "objtool orc generate" command that appears > to corrupt

Re: "objtool orc" creates invalid file arch/x86/kernel/time.o

2017-09-14 Thread Josh Poimboeuf
On Sun, Sep 10, 2017 at 10:38:58PM +0200, Arnd Bergmann wrote: > Hi Josh, > > I have a randconfig build that produces a link error: > > built-in.o: member arch/x86/kernel/time.o in archive is not an object > > I've traced it down to the "objtool orc generate" command that appears > to corrupt

Re: dma-coherent: fix dma_declare_coherent_memory() logic error

2017-09-14 Thread Roy Pledge
On 9/5/2017 4:10 AM, Arnd Bergmann wrote: > A recent change interprets the return code of dma_init_coherent_memory > as an error value, but it is instead a boolean, where 'true' indicates > success. This leads causes the caller to always do the wrong thing, > and also triggers a compile-time

Re: dma-coherent: fix dma_declare_coherent_memory() logic error

2017-09-14 Thread Roy Pledge
On 9/5/2017 4:10 AM, Arnd Bergmann wrote: > A recent change interprets the return code of dma_init_coherent_memory > as an error value, but it is instead a boolean, where 'true' indicates > success. This leads causes the caller to always do the wrong thing, > and also triggers a compile-time

Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

2017-09-14 Thread Pavel Machek
On Thu 2017-09-14 21:31:31, Jacek Anaszewski wrote: > Hi David and Pavel, > > On 09/13/2017 10:20 PM, Pavel Machek wrote: > > Hi! > > > >> These patch series add the LED_BRIGHTNESS_FAST flag support for > >> ledtrig-transient to use hrtimer so that platforms with high-resolution > >> timer > >>

Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

2017-09-14 Thread Pavel Machek
On Thu 2017-09-14 21:31:31, Jacek Anaszewski wrote: > Hi David and Pavel, > > On 09/13/2017 10:20 PM, Pavel Machek wrote: > > Hi! > > > >> These patch series add the LED_BRIGHTNESS_FAST flag support for > >> ledtrig-transient to use hrtimer so that platforms with high-resolution > >> timer > >>

[PATCH] perf, tools: Fix adding multiple event groups

2017-09-14 Thread Andi Kleen
From: Andi Kleen The -M metric group parser threw away the events of earlier groups when multiple groups were specified. Fix this here by not overwriting the string incorrectly. Now this works correctly: % perf stat -M Summary,SMT --metric-only -a sleep 1 Performance

[PATCH] perf, tools: Fix adding multiple event groups

2017-09-14 Thread Andi Kleen
From: Andi Kleen The -M metric group parser threw away the events of earlier groups when multiple groups were specified. Fix this here by not overwriting the string incorrectly. Now this works correctly: % perf stat -M Summary,SMT --metric-only -a sleep 1 Performance counter stats for

Re: [PATCH v4 15/18] fpga: region: move device tree support to of-fpga-region.c

2017-09-14 Thread Alan Tull
On Thu, Sep 14, 2017 at 10:50 AM, wrote: Hi Matthew, Thanks for the review! > > Hi Alan, > > Just a couple of minor nits. > > Matthew Gerlach > > On Wed, 13 Sep 2017, Alan Tull wrote: > >> Create of-fpga-region.c and ove the following functions without > > >

Re: [PATCH v4 15/18] fpga: region: move device tree support to of-fpga-region.c

2017-09-14 Thread Alan Tull
On Thu, Sep 14, 2017 at 10:50 AM, wrote: Hi Matthew, Thanks for the review! > > Hi Alan, > > Just a couple of minor nits. > > Matthew Gerlach > > On Wed, 13 Sep 2017, Alan Tull wrote: > >> Create of-fpga-region.c and ove the following functions without > > > s/ove/move/ OK >> >>

Re: [RFC] [DVB][FRONTEND] Added a new ioctl for optimizing frontend property set operation

2017-09-14 Thread Mauro Carvalho Chehab
Hi Satendra, Em Thu, 14 Sep 2017 05:59:27 -0400 Satendra Singh Thakur escreveu: > -For setting one frontend property , one FE_SET_PROPERTY ioctl is called > -Since, size of struct dtv_property is 72 bytes, this ioctl requires > ---allocating 72 bytes of memory in user

Re: [RFC] [DVB][FRONTEND] Added a new ioctl for optimizing frontend property set operation

2017-09-14 Thread Mauro Carvalho Chehab
Hi Satendra, Em Thu, 14 Sep 2017 05:59:27 -0400 Satendra Singh Thakur escreveu: > -For setting one frontend property , one FE_SET_PROPERTY ioctl is called > -Since, size of struct dtv_property is 72 bytes, this ioctl requires > ---allocating 72 bytes of memory in user space > ---allocating 72

Re: [PATCH 2/2] integrity: replace call to integrity_read_file with kernel version

2017-09-14 Thread Christoph Hellwig
On Fri, Sep 15, 2017 at 06:21:28AM +1000, James Morris wrote: > So, to be clear, this patch solves the XFS deadlock using a different > approach (to the now reverted integrity_read approach), which Christoph > also says is more correct generally. Correct? No. It is in addition to the previous

Re: [PATCH 2/2] integrity: replace call to integrity_read_file with kernel version

2017-09-14 Thread Christoph Hellwig
On Fri, Sep 15, 2017 at 06:21:28AM +1000, James Morris wrote: > So, to be clear, this patch solves the XFS deadlock using a different > approach (to the now reverted integrity_read approach), which Christoph > also says is more correct generally. Correct? No. It is in addition to the previous

[PATCH 2/2] ASoC: topology: Fix a potential memory leak in 'soc_tplg_dapm_widget_denum_create()'

2017-09-14 Thread Christophe JAILLET
If this sanity check fails, we must free the memory that has already been allocated. So we must go to 'err' as in the other error handling parth of this function. Fixes: 1a7dd6e2f192 ("ASoC: topology: Allow a widget to have multiple enum controls") Signed-off-by: Christophe JAILLET

[PATCH 2/2] ASoC: topology: Fix a potential memory leak in 'soc_tplg_dapm_widget_denum_create()'

2017-09-14 Thread Christophe JAILLET
If this sanity check fails, we must free the memory that has already been allocated. So we must go to 'err' as in the other error handling parth of this function. Fixes: 1a7dd6e2f192 ("ASoC: topology: Allow a widget to have multiple enum controls") Signed-off-by: Christophe JAILLET ---

[PATCH 1/2] ASoC: topology: Fix a potential NULL pointer dereference in 'soc_tplg_dapm_widget_denum_create()'

2017-09-14 Thread Christophe JAILLET
if 'se = kzalloc()' fails in the 'for' loop, we will branch to 'err'. But in this case, 'kc[i].private_value' will still be NULL. A NULL pointer dereference will then occur is the error handling path. In such a case, it is safe to just 'continue' in order to skip this entry and free the other

[PATCH 1/2] ASoC: topology: Fix a potential NULL pointer dereference in 'soc_tplg_dapm_widget_denum_create()'

2017-09-14 Thread Christophe JAILLET
if 'se = kzalloc()' fails in the 'for' loop, we will branch to 'err'. But in this case, 'kc[i].private_value' will still be NULL. A NULL pointer dereference will then occur is the error handling path. In such a case, it is safe to just 'continue' in order to skip this entry and free the other

[PATCH] cgroup: Properly init nr_tasks in cgroup_taskset

2017-09-14 Thread Waiman Long
Commit 610467270fb3 ("cgroup: don't call migration methods if there are no tasks to migrate") introduces a new field nr_tasks to the cgroup_taskset structure for keeping track of the number of tasks contained in the structure. The initial value of this field, however, is not guaranteed to be 0 as

[PATCH] cgroup: Properly init nr_tasks in cgroup_taskset

2017-09-14 Thread Waiman Long
Commit 610467270fb3 ("cgroup: don't call migration methods if there are no tasks to migrate") introduces a new field nr_tasks to the cgroup_taskset structure for keeping track of the number of tasks contained in the structure. The initial value of this field, however, is not guaranteed to be 0 as

Re: [PATCH v4 17/18] fpga: clean up fpga Kconfig

2017-09-14 Thread Alan Tull
On Thu, Sep 14, 2017 at 10:56 AM, wrote: Hi Matthew, > > Hi Alan, > > s/mixxed/mixed/ > OK, I'll fix that. Alan > On Wed, 13 Sep 2017, Alan Tull wrote: > >> The fpga menuconfig has gotten messy. The bridges and managers are >> mixxed together. >> >> *

Re: [PATCH v4 17/18] fpga: clean up fpga Kconfig

2017-09-14 Thread Alan Tull
On Thu, Sep 14, 2017 at 10:56 AM, wrote: Hi Matthew, > > Hi Alan, > > s/mixxed/mixed/ > OK, I'll fix that. Alan > On Wed, 13 Sep 2017, Alan Tull wrote: > >> The fpga menuconfig has gotten messy. The bridges and managers are >> mixxed together. >> >> * Separate the bridges and things

[PATCH 1/3 v2] perf/x86/intel/uncore: Cache logical pkg id in uncore driver

2017-09-14 Thread Prarit Bhargava
From: Andi Kleen The SNB-EP uncore driver is the only user of topology_phys_to_logical_pkg in a performance critical path. Change it query the logical pkg ID only once at initialization time and then cache it in box structure. Signed-off-by: Andi Kleen

[PATCH 1/3 v2] perf/x86/intel/uncore: Cache logical pkg id in uncore driver

2017-09-14 Thread Prarit Bhargava
From: Andi Kleen The SNB-EP uncore driver is the only user of topology_phys_to_logical_pkg in a performance critical path. Change it query the logical pkg ID only once at initialization time and then cache it in box structure. Signed-off-by: Andi Kleen --- arch/x86/events/intel/uncore.c

[PATCH 3/3 v2] x86/smpboot: Fix __max_logical_packages estimate

2017-09-14 Thread Prarit Bhargava
A system booted with a small number of cores enabled per package panics because the estimate of __max_logical_packages is too low. This occurs when the total number of active cores across all packages is less than the maximum core count for a single package. ie) On a 4 package system with 20

[PATCH 2/3 v2] x86/topology: Avoid wasting 128k for package id array

2017-09-14 Thread Prarit Bhargava
From: Andi Kleen I was looking at large early boot allocations and noticed that since (1f12e32f x86/topology: Create logical package id) every 64bit system allocates a 128k array to convert logical package ids. This happens because the array is sized for MAX_LOCAL_APIC and

[PATCH 3/3 v2] x86/smpboot: Fix __max_logical_packages estimate

2017-09-14 Thread Prarit Bhargava
A system booted with a small number of cores enabled per package panics because the estimate of __max_logical_packages is too low. This occurs when the total number of active cores across all packages is less than the maximum core count for a single package. ie) On a 4 package system with 20

[PATCH 2/3 v2] x86/topology: Avoid wasting 128k for package id array

2017-09-14 Thread Prarit Bhargava
From: Andi Kleen I was looking at large early boot allocations and noticed that since (1f12e32f x86/topology: Create logical package id) every 64bit system allocates a 128k array to convert logical package ids. This happens because the array is sized for MAX_LOCAL_APIC and that is always 32k on

[PATCH 0/3 v2] x86/smpboot: Cleanup logical package ID

2017-09-14 Thread Prarit Bhargava
Cleanup the logical package ID code by storing the logical package ID in the cpuinfo_x86 struct and calculating the maximum logical package ID after all the CPUs have been enumerated. [v2]: Decrease logical_packages when the last thread in a socket is removed. Signed-off-by: Prarit Bhargava

[PATCH 0/3 v2] x86/smpboot: Cleanup logical package ID

2017-09-14 Thread Prarit Bhargava
Cleanup the logical package ID code by storing the logical package ID in the cpuinfo_x86 struct and calculating the maximum logical package ID after all the CPUs have been enumerated. [v2]: Decrease logical_packages when the last thread in a socket is removed. Signed-off-by: Prarit Bhargava

[PATCH] iio: dac: ds4422/ds4424 dac driver

2017-09-14 Thread Ismail Kose
From: "Ismail H. Kose" This patch provides an iio device driver for DS4422/DS4424 chips that support two/four channel 7-bit Sink/Source Current DAC. The driver supports device tree and platform files for the configurations. Datasheet publicly available at:

[PATCH] iio: dac: ds4422/ds4424 dac driver

2017-09-14 Thread Ismail Kose
From: "Ismail H. Kose" This patch provides an iio device driver for DS4422/DS4424 chips that support two/four channel 7-bit Sink/Source Current DAC. The driver supports device tree and platform files for the configurations. Datasheet publicly available at:

Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y

2017-09-14 Thread Dmitry V. Levin
On Thu, Sep 14, 2017 at 07:40:43PM +, Eugene Syromyatnikov wrote: > On Wed, Sep 13, 2017 at 4:49 PM, Oleg Nesterov wrote: > > IOW, why do we want to silently ignore the upper bits in $rax ? > > By the way, they are ignored elsewhere, in audit[1] or seccomp[2], for >

Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y

2017-09-14 Thread Dmitry V. Levin
On Thu, Sep 14, 2017 at 07:40:43PM +, Eugene Syromyatnikov wrote: > On Wed, Sep 13, 2017 at 4:49 PM, Oleg Nesterov wrote: > > IOW, why do we want to silently ignore the upper bits in $rax ? > > By the way, they are ignored elsewhere, in audit[1] or seccomp[2], for > example. > > [1]

Re: [GIT PULL] overlayfs update for 4.14

2017-09-14 Thread Linus Torvalds
On Thu, Sep 14, 2017 at 1:12 PM, Miklos Szeredi wrote: > > I was saying that it's a bad idea to mix external and internal flags. > That was the reason the two were separated on that API. I'm open to > arguments about that. The thing is, I don't think "upper layer" is any more

Re: [GIT PULL] overlayfs update for 4.14

2017-09-14 Thread Linus Torvalds
On Thu, Sep 14, 2017 at 1:12 PM, Miklos Szeredi wrote: > > I was saying that it's a bad idea to mix external and internal flags. > That was the reason the two were separated on that API. I'm open to > arguments about that. The thing is, I don't think "upper layer" is any more internal than

Re: [PATCH RFC 0/3] A few round_pipe_size() and pipe-max-size fixups

2017-09-14 Thread Randy Dunlap
On 09/14/17 12:19, Joe Lawrence wrote: > On 09/14/2017 12:57 PM, Randy Dunlap wrote: >> On 09/14/17 06:26, Michael Kerrisk (man-pages) wrote: >>> Hello Joe, >>> >>> On 5 September 2017 at 16:44, Joe Lawrence wrote: While backporting Michael's "pipe: fix limit

Re: [PATCH RFC 0/3] A few round_pipe_size() and pipe-max-size fixups

2017-09-14 Thread Randy Dunlap
On 09/14/17 12:19, Joe Lawrence wrote: > On 09/14/2017 12:57 PM, Randy Dunlap wrote: >> On 09/14/17 06:26, Michael Kerrisk (man-pages) wrote: >>> Hello Joe, >>> >>> On 5 September 2017 at 16:44, Joe Lawrence wrote: While backporting Michael's "pipe: fix limit handling" [1] patchset to a

Re: [PATCH 2/2] integrity: replace call to integrity_read_file with kernel version

2017-09-14 Thread James Morris
On Tue, 12 Sep 2017, Mimi Zohar wrote: > From: Christoph Hellwig > > The CONFIG_IMA_LOAD_X509 and CONFIG_EVM_LOAD_X509 options permit > loading x509 signed certificates onto the trusted keyrings without > verifying the x509 certificate file's signature. > > This patch replaces the

Re: [PATCH 2/2] integrity: replace call to integrity_read_file with kernel version

2017-09-14 Thread James Morris
On Tue, 12 Sep 2017, Mimi Zohar wrote: > From: Christoph Hellwig > > The CONFIG_IMA_LOAD_X509 and CONFIG_EVM_LOAD_X509 options permit > loading x509 signed certificates onto the trusted keyrings without > verifying the x509 certificate file's signature. > > This patch replaces the call to the

Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y

2017-09-14 Thread Dmitry V. Levin
On Wed, Sep 13, 2017 at 06:49:21PM +0200, Oleg Nesterov wrote: > On 09/13, Dmitry V. Levin wrote: > > > > Before this change, CONFIG_X86_X32=y fastpath behaviour was different > > from slowpath: > > and even with this change they differ if CONFIG_X86_X32=n? No, I don't think so. >

Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y

2017-09-14 Thread Dmitry V. Levin
On Wed, Sep 13, 2017 at 06:49:21PM +0200, Oleg Nesterov wrote: > On 09/13, Dmitry V. Levin wrote: > > > > Before this change, CONFIG_X86_X32=y fastpath behaviour was different > > from slowpath: > > and even with this change they differ if CONFIG_X86_X32=n? No, I don't think so. >

Re: [PATCH v2] android: binder: Drop lru lock in isolate callback

2017-09-14 Thread Andrew Morton
On Thu, 14 Sep 2017 14:22:25 -0400 Sherry Yang wrote: > Drop the global lru lock in isolate callback > before calling zap_page_range which calls > cond_resched, and re-acquire the global lru > lock before returning. Also change return > code to LRU_REMOVED_RETRY. > > Use

Re: [PATCH v2] android: binder: Drop lru lock in isolate callback

2017-09-14 Thread Andrew Morton
On Thu, 14 Sep 2017 14:22:25 -0400 Sherry Yang wrote: > Drop the global lru lock in isolate callback > before calling zap_page_range which calls > cond_resched, and re-acquire the global lru > lock before returning. Also change return > code to LRU_REMOVED_RETRY. > > Use mmput_async when fail

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

2017-09-14 Thread Alexander Duyck
On Thu, Sep 14, 2017 at 12:59 PM, Maxim Uvarov wrote: > debugfs here is very very useful to read registers directly and > compare what use space tools see. Cool feature to get regs by port and > use standard tools to diff and print them. Even might be better to > allow drivers

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

2017-09-14 Thread Alexander Duyck
On Thu, Sep 14, 2017 at 12:59 PM, Maxim Uvarov wrote: > debugfs here is very very useful to read registers directly and > compare what use space tools see. Cool feature to get regs by port and > use standard tools to diff and print them. Even might be better to > allow drivers to decode register

Re: [GIT PULL] overlayfs update for 4.14

2017-09-14 Thread Miklos Szeredi
On Thu, Sep 14, 2017 at 10:00 PM, Linus Torvalds wrote: > If you can't bother to try to make it act as a proper VFS thing, then > I don't want to see patches from you to the VFS code. I was saying that it's a bad idea to mix external and internal flags. That was

Re: [GIT PULL] overlayfs update for 4.14

2017-09-14 Thread Miklos Szeredi
On Thu, Sep 14, 2017 at 10:00 PM, Linus Torvalds wrote: > If you can't bother to try to make it act as a proper VFS thing, then > I don't want to see patches from you to the VFS code. I was saying that it's a bad idea to mix external and internal flags. That was the reason the two were separated

Please pull Intel vendor json metrics updates

2017-09-14 Thread Andi Kleen
Hi Arnaldo, I found some more missing brackets with metrics. Now I fixed it all with a script. This replaces the earlier patch to only fix up ILP, and fixes other metrics too. Please pull the metrics updates. It's on top of current acme perf/core The following changes since commit

Please pull Intel vendor json metrics updates

2017-09-14 Thread Andi Kleen
Hi Arnaldo, I found some more missing brackets with metrics. Now I fixed it all with a script. This replaces the earlier patch to only fix up ILP, and fixes other metrics too. Please pull the metrics updates. It's on top of current acme perf/core The following changes since commit

Re: [v8 0/4] cgroup-aware OOM killer

2017-09-14 Thread David Rientjes
On Thu, 14 Sep 2017, Michal Hocko wrote: > > It is certainly possible to add oom priorities on top before it is merged, > > but I don't see why it isn't part of the patchset. > > Because the semantic of the priority for non-leaf memcgs is not fully > clear and I would rather have the core of

Re: [v8 0/4] cgroup-aware OOM killer

2017-09-14 Thread David Rientjes
On Thu, 14 Sep 2017, Michal Hocko wrote: > > It is certainly possible to add oom priorities on top before it is merged, > > but I don't see why it isn't part of the patchset. > > Because the semantic of the priority for non-leaf memcgs is not fully > clear and I would rather have the core of

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

2017-09-14 Thread Jacek Anaszewski
On 09/14/2017 09:38 PM, David Lin wrote: > On Thu, Sep 14, 2017 at 12:31 PM, Jacek Anaszewski > wrote: >> I would change one more thing in this patch, though. The hr_timer engine >> should be made optional and not used by default for fast LEDs. >> It could be made

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

2017-09-14 Thread Jacek Anaszewski
On 09/14/2017 09:38 PM, David Lin wrote: > On Thu, Sep 14, 2017 at 12:31 PM, Jacek Anaszewski > wrote: >> I would change one more thing in this patch, though. The hr_timer engine >> should be made optional and not used by default for fast LEDs. >> It could be made configurable by exposing

Re: [PATCH v4 13/18] fpga: region: add register/unregister functions

2017-09-14 Thread Alan Tull
On Thu, Sep 14, 2017 at 4:56 AM, Wu Hao wrote: > On Thu, Sep 14, 2017 at 04:48:36AM +0800, Alan Tull wrote: >> Another step in separating common code from device tree specific >> code for FPGA regions. >> >> * add FPGA region register/unregister functions. >> * add the

Re: [PATCH v4 13/18] fpga: region: add register/unregister functions

2017-09-14 Thread Alan Tull
On Thu, Sep 14, 2017 at 4:56 AM, Wu Hao wrote: > On Thu, Sep 14, 2017 at 04:48:36AM +0800, Alan Tull wrote: >> Another step in separating common code from device tree specific >> code for FPGA regions. >> >> * add FPGA region register/unregister functions. >> * add the register/unregister

Re: [GIT PULL] overlayfs update for 4.14

2017-09-14 Thread Linus Torvalds
On Wed, Sep 13, 2017 at 11:46 PM, Miklos Szeredi wrote: > > d_real() is currently is *the* overlayfs-op: I know. And it's ugly as #%^! hell. We don't want to make it uglier. And honestly, if you think that "it's only for overlayfs, so I can do anything I damn well want to

Re: [GIT PULL] overlayfs update for 4.14

2017-09-14 Thread Linus Torvalds
On Wed, Sep 13, 2017 at 11:46 PM, Miklos Szeredi wrote: > > d_real() is currently is *the* overlayfs-op: I know. And it's ugly as #%^! hell. We don't want to make it uglier. And honestly, if you think that "it's only for overlayfs, so I can do anything I damn well want to this p[iece of shit"

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

2017-09-14 Thread Maxim Uvarov
debugfs here is very very useful to read registers directly and compare what use space tools see. Cool feature to get regs by port and use standard tools to diff and print them. Even might be better to allow drivers to decode register names and bits values. Once that is done driver mainaince will

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

2017-09-14 Thread Maxim Uvarov
debugfs here is very very useful to read registers directly and compare what use space tools see. Cool feature to get regs by port and use standard tools to diff and print them. Even might be better to allow drivers to decode register names and bits values. Once that is done driver mainaince will

Re: [PATCH] config: ls1012aqds: Add USB EHCI support for ls1012aqds

2017-09-14 Thread York Sun
On 09/14/2017 12:54 PM, York Sun wrote: > On 07/27/2017 03:05 AM, yinbo@nxp.com wrote: >> From: Rajesh Bhagat >> >> +#elif defined(CONFIG_LS102XA) || defined(CONFIG_ARCH_LS1012A) > > Please use CONFIG_ARCH_LS1021A, not CONFIG_LS102XA. > Never mind. This is merged.

Re: [PATCH] config: ls1012aqds: Add USB EHCI support for ls1012aqds

2017-09-14 Thread York Sun
On 09/14/2017 12:54 PM, York Sun wrote: > On 07/27/2017 03:05 AM, yinbo@nxp.com wrote: >> From: Rajesh Bhagat >> >> +#elif defined(CONFIG_LS102XA) || defined(CONFIG_ARCH_LS1012A) > > Please use CONFIG_ARCH_LS1021A, not CONFIG_LS102XA. > Never mind. This is merged. I will send a patch to

Re: [PATCH] config: ls1012aqds: Add USB EHCI support for ls1012aqds

2017-09-14 Thread York Sun
On 07/27/2017 03:05 AM, yinbo@nxp.com wrote: > From: Rajesh Bhagat > > Add USB EHCI support for ls1012aqds platform > > Signed-off-by: Rajat Srivastava > Signed-off-by: Rajesh Bhagat > Signed-off-by: yinbo.zhu

Re: [PATCH] config: ls1012aqds: Add USB EHCI support for ls1012aqds

2017-09-14 Thread York Sun
On 07/27/2017 03:05 AM, yinbo@nxp.com wrote: > From: Rajesh Bhagat > > Add USB EHCI support for ls1012aqds platform > > Signed-off-by: Rajat Srivastava > Signed-off-by: Rajesh Bhagat > Signed-off-by: yinbo.zhu > --- > arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h | 1 + >

[RFC] iommu: arm-smmu: stall support

2017-09-14 Thread Rob Clark
Adds a new domain property for iommu clients to opt-in to stalling with asynchronous resume, and for the client to determine if the iommu supports this. Current motivation is that: a) On 8x96/a530, if we don't enable CFCFG (or HUPCF) then non- faulting translations which are happening

[RFC] iommu: arm-smmu: stall support

2017-09-14 Thread Rob Clark
Adds a new domain property for iommu clients to opt-in to stalling with asynchronous resume, and for the client to determine if the iommu supports this. Current motivation is that: a) On 8x96/a530, if we don't enable CFCFG (or HUPCF) then non- faulting translations which are happening

[GIT PULL] MAP_SHARED_VALIDATE for 4.14

2017-09-14 Thread Williams, Dan J
Hi Linus, please consider pulling: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/map-shared-validate-for-4.14 ...for 4.14 as a pre-requisite for the proposed mmap flags (MAP_SYNC and MAP_DIRECT) being developed for 4.15 consideration. As I highlighted in the last posting

[GIT PULL] MAP_SHARED_VALIDATE for 4.14

2017-09-14 Thread Williams, Dan J
Hi Linus, please consider pulling: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/map-shared-validate-for-4.14 ...for 4.14 as a pre-requisite for the proposed mmap flags (MAP_SYNC and MAP_DIRECT) being developed for 4.15 consideration. As I highlighted in the last posting

Re: [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros

2017-09-14 Thread Jacek Anaszewski
Hi David, Thanks for the patch. On 09/13/2017 07:53 PM, David Lin wrote: > This is for readability as well as to avoid checkpatch warnings when > adding new bit flag information in the future. > > Signed-off-by: David Lin > --- > include/linux/leds.h | 18 +-

Re: [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros

2017-09-14 Thread Jacek Anaszewski
Hi David, Thanks for the patch. On 09/13/2017 07:53 PM, David Lin wrote: > This is for readability as well as to avoid checkpatch warnings when > adding new bit flag information in the future. > > Signed-off-by: David Lin > --- > include/linux/leds.h | 18 +- > 1 file changed,

Re: [PATCH v2] dmaengine: imx-sdma: Correct src_addr_widths and directions

2017-09-14 Thread Fabio Estevam
Hi Nicolin, On Thu, Sep 14, 2017 at 3:46 PM, Nicolin Chen wrote: > The driver already supports DMA_DEV_TO_DEV in sdma_config(), > DMA_SLAVE_BUSWIDTH_2_BYTES and DMA_SLAVE_BUSWIDTH_1_BYTE in > sdma_prep_slave_sg(). So this patch adds them to the lists. > > Signed-off-by:

Re: [PATCH v2] dmaengine: imx-sdma: Correct src_addr_widths and directions

2017-09-14 Thread Fabio Estevam
Hi Nicolin, On Thu, Sep 14, 2017 at 3:46 PM, Nicolin Chen wrote: > The driver already supports DMA_DEV_TO_DEV in sdma_config(), > DMA_SLAVE_BUSWIDTH_2_BYTES and DMA_SLAVE_BUSWIDTH_1_BYTE in > sdma_prep_slave_sg(). So this patch adds them to the lists. > > Signed-off-by: Nicolin Chen Patch

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

2017-09-14 Thread Pavel Machek
Hi! > > > > NAK. > > > > > > > > LEDs do not need extra overhead, and vibrator control should not go > > > > through LED subsystem. > > > > > > > > Input subsystem includes support for vibrations and force > > > > feedback. Please use that instead. > > > > > > I thought we are already over this

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

2017-09-14 Thread Pavel Machek
Hi! > > > > NAK. > > > > > > > > LEDs do not need extra overhead, and vibrator control should not go > > > > through LED subsystem. > > > > > > > > Input subsystem includes support for vibrations and force > > > > feedback. Please use that instead. > > > > > > I thought we are already over this

Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y

2017-09-14 Thread Eugene Syromyatnikov
On Wed, Sep 13, 2017 at 4:49 PM, Oleg Nesterov wrote: > IOW, why do we want to silently ignore the upper bits in $rax ? By the way, they are ignored elsewhere, in audit[1] or seccomp[2], for example. [1] include/linux/audit.h [2] include/uapi/linux/seccomp.h, definition of

Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y

2017-09-14 Thread Eugene Syromyatnikov
On Wed, Sep 13, 2017 at 4:49 PM, Oleg Nesterov wrote: > IOW, why do we want to silently ignore the upper bits in $rax ? By the way, they are ignored elsewhere, in audit[1] or seccomp[2], for example. [1] include/linux/audit.h [2] include/uapi/linux/seccomp.h, definition of struct seccomp_data

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

2017-09-14 Thread David Lin
On Thu, Sep 14, 2017 at 12:31 PM, Jacek Anaszewski wrote: > I would change one more thing in this patch, though. The hr_timer engine > should be made optional and not used by default for fast LEDs. > It could be made configurable by exposing additional sysfs file from

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

2017-09-14 Thread David Lin
On Thu, Sep 14, 2017 at 12:31 PM, Jacek Anaszewski wrote: > I would change one more thing in this patch, though. The hr_timer engine > should be made optional and not used by default for fast LEDs. > It could be made configurable by exposing additional sysfs file from > ledtrig-transient.c, e.g.

Re: [PATCH v4 11/18] fpga: region: add fpga-region.h header

2017-09-14 Thread Alan Tull
On Thu, Sep 14, 2017 at 4:50 AM, Wu Hao wrote: Hi Hao, > On Thu, Sep 14, 2017 at 04:48:34AM +0800, Alan Tull wrote: >> * Create fpga-region.h. >> * Export fpga_region_program_fpga. >> * Move struct fpga_region and other things to the header. >> >> This is a step in separating

Re: [PATCH v4 11/18] fpga: region: add fpga-region.h header

2017-09-14 Thread Alan Tull
On Thu, Sep 14, 2017 at 4:50 AM, Wu Hao wrote: Hi Hao, > On Thu, Sep 14, 2017 at 04:48:34AM +0800, Alan Tull wrote: >> * Create fpga-region.h. >> * Export fpga_region_program_fpga. >> * Move struct fpga_region and other things to the header. >> >> This is a step in separating FPGA region common

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

2017-09-14 Thread Jacek Anaszewski
Hi David and Pavel, On 09/13/2017 10:20 PM, Pavel Machek wrote: > Hi! > >> These patch series add the LED_BRIGHTNESS_FAST flag support for >> ledtrig-transient to use hrtimer so that platforms with high-resolution timer >> support can have better accuracy in the trigger duration timing. The need

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

2017-09-14 Thread Jacek Anaszewski
Hi David and Pavel, On 09/13/2017 10:20 PM, Pavel Machek wrote: > Hi! > >> These patch series add the LED_BRIGHTNESS_FAST flag support for >> ledtrig-transient to use hrtimer so that platforms with high-resolution timer >> support can have better accuracy in the trigger duration timing. The need

[PATCH] perf: qcom_l2_pmu: add event names

2017-09-14 Thread Neil Leeder
Add event names so that common events can be specified symbolically, for example: l2cache_0/total-reads/,l2cache_0/cycles/ Event names are displayed in 'perf list'. Signed-off-by: Neil Leeder --- drivers/perf/qcom_l2_pmu.c | 54

[PATCH] perf: qcom_l2_pmu: add event names

2017-09-14 Thread Neil Leeder
Add event names so that common events can be specified symbolically, for example: l2cache_0/total-reads/,l2cache_0/cycles/ Event names are displayed in 'perf list'. Signed-off-by: Neil Leeder --- drivers/perf/qcom_l2_pmu.c | 54 ++ 1 file changed,

[PATCH] ARM: dts: am43xx-epos-evm: Remove extra CPSW EMAC entry

2017-09-14 Thread Andrew F. Davis
From: Yogesh Siraswar On am438x EPOS boards there is only one ethernet port, remove extra port definition. This boot log warnings during PHY detection. Signed-off-by: Yogesh Siraswar Signed-off-by: Andrew F. Davis ---

[PATCH] ARM: dts: am43xx-epos-evm: Remove extra CPSW EMAC entry

2017-09-14 Thread Andrew F. Davis
From: Yogesh Siraswar On am438x EPOS boards there is only one ethernet port, remove extra port definition. This boot log warnings during PHY detection. Signed-off-by: Yogesh Siraswar Signed-off-by: Andrew F. Davis --- arch/arm/boot/dts/am43x-epos-evm.dts | 6 +- 1 file changed, 1

Re: [PATCH] drm/i915: remove redundant variable hw_check

2017-09-14 Thread Chris Wilson
Quoting Colin King (2017-09-14 17:21:54) > From: Colin Ian King > > hw_check is being assigned and updated but is no longer being read, > hence it is redundant and can be removed. > > Detected by clang scan-build: > "warning: Value stored to 'hw_check' during its

Re: [PATCH] drm/i915: remove redundant variable hw_check

2017-09-14 Thread Chris Wilson
Quoting Colin King (2017-09-14 17:21:54) > From: Colin Ian King > > hw_check is being assigned and updated but is no longer being read, > hence it is redundant and can be removed. > > Detected by clang scan-build: > "warning: Value stored to 'hw_check' during its initialization > is never read"

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