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
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
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
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
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
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
> 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
> 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
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
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
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
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
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
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
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
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
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
> >>
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
> >>
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
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
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
>
>
>
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
>>
>>
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
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
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
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
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
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
---
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
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
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
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
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.
>>
>> *
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
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
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
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
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
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
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
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
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
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:
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:
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
>
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]
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
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
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
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
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
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
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.
>
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.
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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"
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
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
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.
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
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
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 +
>
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
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
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
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
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 +-
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,
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:
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
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
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
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
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
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
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.
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
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
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
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
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
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,
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
---
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
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
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"
301 - 400 of 1388 matches
Mail list logo