Linus,
please pull sound updates for v4.18-rc1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-4.18-rc1
The topmost commit is d4d5a1cd298e67cb68cca8dc7dd1ea3942cce3ff
sound updates for 4.18
Linus,
please pull sound updates for v4.18-rc1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-4.18-rc1
The topmost commit is d4d5a1cd298e67cb68cca8dc7dd1ea3942cce3ff
sound updates for 4.18
On Tue, Jun 05, 2018 at 03:21:48PM -0500, Alan Tull wrote:
> On Tue, May 1, 2018 at 9:50 PM, Wu Hao wrote:
>
> Hi Hao,
>
> > For feature devices drivers, both the FPGA Management Engine (FME) and
> > Accelerated Function Unit (AFU) driver need to expose user interfaces via
> > the device file,
On Tue, Jun 05, 2018 at 03:21:48PM -0500, Alan Tull wrote:
> On Tue, May 1, 2018 at 9:50 PM, Wu Hao wrote:
>
> Hi Hao,
>
> > For feature devices drivers, both the FPGA Management Engine (FME) and
> > Accelerated Function Unit (AFU) driver need to expose user interfaces via
> > the device file,
On Wed, Jun 6, 2018 at 2:27 PM, Jakub Racek wrote:
> Hi,
>
> There is a huge performance regression on the 2 and 4 NUMA node systems on
> stream benchmark with 4.17 kernel compared to 4.16 kernel. Stream, Linpack
> and NAS parallel benchmarks show upto 50% performance drop.
>
> When running for
On Wed, Jun 6, 2018 at 2:27 PM, Jakub Racek wrote:
> Hi,
>
> There is a huge performance regression on the 2 and 4 NUMA node systems on
> stream benchmark with 4.17 kernel compared to 4.16 kernel. Stream, Linpack
> and NAS parallel benchmarks show upto 50% performance drop.
>
> When running for
On Tue, Jun 05, 2018 at 03:21:31PM -0500, Alan Tull wrote:
> On Tue, May 1, 2018 at 9:50 PM, Wu Hao wrote:
>
> Hi Hao,
>
> I understand that you are implementing support for something that
> already has been defined and already exists. With that, I have some
> minor suggestions below. I have
On Tue, Jun 05, 2018 at 03:21:31PM -0500, Alan Tull wrote:
> On Tue, May 1, 2018 at 9:50 PM, Wu Hao wrote:
>
> Hi Hao,
>
> I understand that you are implementing support for something that
> already has been defined and already exists. With that, I have some
> minor suggestions below. I have
On Wed, 06 Jun 2018 14:14:23 +0200
Stefan Agner wrote:
> On 06.06.2018 13:07, Thierry Reding wrote:
> > On Wed, Jun 06, 2018 at 12:45:40PM +0200, Boris Brezillon wrote:
> >> Hi Thierry,
> >>
> >> On Wed, 6 Jun 2018 12:39:03 +0200
> >> Thierry Reding wrote:
> >>
> >> > On Tue, Jun 05, 2018
On Wed, 06 Jun 2018 14:14:23 +0200
Stefan Agner wrote:
> On 06.06.2018 13:07, Thierry Reding wrote:
> > On Wed, Jun 06, 2018 at 12:45:40PM +0200, Boris Brezillon wrote:
> >> Hi Thierry,
> >>
> >> On Wed, 6 Jun 2018 12:39:03 +0200
> >> Thierry Reding wrote:
> >>
> >> > On Tue, Jun 05, 2018
On Wed, Jun 06, 2018 at 02:05:39PM +0200, Andrea Parri wrote:
> Hi Daniel, Viresh,
>
> On Wed, Jun 06, 2018 at 04:15:28PM +0530, Viresh Kumar wrote:
> > On 06-06-18, 12:22, Daniel Lezcano wrote:
> > > (mb() are done in the atomic operations AFAICT).
>
> To do my bit, not all atomic ops do/imply
On Wed, Jun 06, 2018 at 02:05:39PM +0200, Andrea Parri wrote:
> Hi Daniel, Viresh,
>
> On Wed, Jun 06, 2018 at 04:15:28PM +0530, Viresh Kumar wrote:
> > On 06-06-18, 12:22, Daniel Lezcano wrote:
> > > (mb() are done in the atomic operations AFAICT).
>
> To do my bit, not all atomic ops do/imply
Hi,
There is a huge performance regression on the 2 and 4 NUMA node systems on stream
benchmark with 4.17 kernel compared to 4.16 kernel.
Stream, Linpack and NAS parallel benchmarks show upto 50% performance drop.
When running for example 20 stream processes in parallel, we see the following
Hi,
There is a huge performance regression on the 2 and 4 NUMA node systems on stream
benchmark with 4.17 kernel compared to 4.16 kernel.
Stream, Linpack and NAS parallel benchmarks show upto 50% performance drop.
When running for example 20 stream processes in parallel, we see the following
On Tue, Jun 05, 2018 at 11:16:40AM +0200, Daniel Lezcano wrote:
> + atomic_t idle_duration_ms;
> + atomic_t run_duration_ms;
> + idle_duration_ms = atomic_read(_dev->idle_duration_ms);
> + run_duration_ms = atomic_read(_dev->run_duration_ms);
> +
On Tue, Jun 05, 2018 at 11:16:40AM +0200, Daniel Lezcano wrote:
> + atomic_t idle_duration_ms;
> + atomic_t run_duration_ms;
> + idle_duration_ms = atomic_read(_dev->idle_duration_ms);
> + run_duration_ms = atomic_read(_dev->run_duration_ms);
> +
Am 06.06.2018 um 14:08 schrieb Gabriel C:
2018-06-06 13:33 GMT+02:00 Christian König :
Am 06.06.2018 um 13:28 schrieb Gabriel C:
2018-04-11 7:02 GMT+02:00 Gabriel C :
2018-04-11 6:00 GMT+02:00 Gabriel C :
2018-04-09 11:42 GMT+02:00 Christian König
:
Am 07.04.2018 um 00:00 schrieb Jean-Marc
Am 06.06.2018 um 14:08 schrieb Gabriel C:
2018-06-06 13:33 GMT+02:00 Christian König :
Am 06.06.2018 um 13:28 schrieb Gabriel C:
2018-04-11 7:02 GMT+02:00 Gabriel C :
2018-04-11 6:00 GMT+02:00 Gabriel C :
2018-04-09 11:42 GMT+02:00 Christian König
:
Am 07.04.2018 um 00:00 schrieb Jean-Marc
> On 06 June 2018 at 12:39 John Whitmore wrote:
> Again these are just some simple coding style changes to the file, so nothing
> of importance.
If it keeps grumpy maintainers happy, then it's of great importance! :-)
Justin
On 06/06/18 13:18, Colin King wrote:
> From: Colin Ian King
>
> The current use of result is or'ing in values and checking for
> a non-zero result, however, result is not initialized to zero
> so it potentially contains garbage to start with. Fix this by
> initializing it to the first return
> On 06 June 2018 at 12:39 John Whitmore wrote:
> Again these are just some simple coding style changes to the file, so nothing
> of importance.
If it keeps grumpy maintainers happy, then it's of great importance! :-)
Justin
On 06/06/18 13:18, Colin King wrote:
> From: Colin Ian King
>
> The current use of result is or'ing in values and checking for
> a non-zero result, however, result is not initialized to zero
> so it potentially contains garbage to start with. Fix this by
> initializing it to the first return
Commit-ID: 108fab4b5c8f12064ef86e02cb0459992affb30f
Gitweb: https://git.kernel.org/tip/108fab4b5c8f12064ef86e02cb0459992affb30f
Author: Konrad Rzeszutek Wilk
AuthorDate: Fri, 1 Jun 2018 10:59:21 -0400
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 14:13:17 +0200
x86/bugs:
Commit-ID: 108fab4b5c8f12064ef86e02cb0459992affb30f
Gitweb: https://git.kernel.org/tip/108fab4b5c8f12064ef86e02cb0459992affb30f
Author: Konrad Rzeszutek Wilk
AuthorDate: Fri, 1 Jun 2018 10:59:21 -0400
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 14:13:17 +0200
x86/bugs:
Commit-ID: 6ac2f49edb1ef5446089c7c660017732886d62d6
Gitweb: https://git.kernel.org/tip/6ac2f49edb1ef5446089c7c660017732886d62d6
Author: Konrad Rzeszutek Wilk
AuthorDate: Fri, 1 Jun 2018 10:59:20 -0400
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 14:13:16 +0200
x86/bugs: Add
Commit-ID: 6ac2f49edb1ef5446089c7c660017732886d62d6
Gitweb: https://git.kernel.org/tip/6ac2f49edb1ef5446089c7c660017732886d62d6
Author: Konrad Rzeszutek Wilk
AuthorDate: Fri, 1 Jun 2018 10:59:20 -0400
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 14:13:16 +0200
x86/bugs: Add
Commit-ID: 24809860012e0130fbafe536709e08a22b3e959e
Gitweb: https://git.kernel.org/tip/24809860012e0130fbafe536709e08a22b3e959e
Author: Konrad Rzeszutek Wilk
AuthorDate: Fri, 1 Jun 2018 10:59:19 -0400
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 14:13:16 +0200
x86/bugs: Add
Commit-ID: 24809860012e0130fbafe536709e08a22b3e959e
Gitweb: https://git.kernel.org/tip/24809860012e0130fbafe536709e08a22b3e959e
Author: Konrad Rzeszutek Wilk
AuthorDate: Fri, 1 Jun 2018 10:59:19 -0400
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 14:13:16 +0200
x86/bugs: Add
On Wed, Jun 06, 2018 at 04:48:21PM +0530, Naresh Kamboju wrote:
> On 5 June 2018 at 22:31, Greg Kroah-Hartman
> wrote:
> > This is the start of the stable review cycle for the 4.4.136 release.
> > There are 37 patches in this series, all will be posted as a response
> > to this one. If anyone
On Wed, Jun 06, 2018 at 04:48:21PM +0530, Naresh Kamboju wrote:
> On 5 June 2018 at 22:31, Greg Kroah-Hartman
> wrote:
> > This is the start of the stable review cycle for the 4.4.136 release.
> > There are 37 patches in this series, all will be posted as a response
> > to this one. If anyone
Il 06/06/2018 13:56, Andy Shevchenko ha scritto:
On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
em485 gets lost during serial8250_register_8250_port().
Copy em485 to final uart port.
Is it needed at all?
The individual driver decides either to use software emulation (and
calls
Il 06/06/2018 13:56, Andy Shevchenko ha scritto:
On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
em485 gets lost during serial8250_register_8250_port().
Copy em485 to final uart port.
Is it needed at all?
The individual driver decides either to use software emulation (and
calls
On 06.06.2018 13:07, Thierry Reding wrote:
> On Wed, Jun 06, 2018 at 12:45:40PM +0200, Boris Brezillon wrote:
>> Hi Thierry,
>>
>> On Wed, 6 Jun 2018 12:39:03 +0200
>> Thierry Reding wrote:
>>
>> > On Tue, Jun 05, 2018 at 11:19:14PM +0300, Dmitry Osipenko wrote:
>> > > On 01.06.2018 10:30, Boris
On 06.06.2018 13:07, Thierry Reding wrote:
> On Wed, Jun 06, 2018 at 12:45:40PM +0200, Boris Brezillon wrote:
>> Hi Thierry,
>>
>> On Wed, 6 Jun 2018 12:39:03 +0200
>> Thierry Reding wrote:
>>
>> > On Tue, Jun 05, 2018 at 11:19:14PM +0300, Dmitry Osipenko wrote:
>> > > On 01.06.2018 10:30, Boris
On Wed, 6 Jun 2018, Masatake YAMATO wrote:
> On Wed, 6 Jun 2018 12:37:34 +0200 (CEST), Thomas Gleixner
> wrote:
> > On Wed, 6 Jun 2018, Masatake YAMATO wrote:
> >
> > Can you please explain why 0 is the wrong value.
>
> I don't know such constants, 0 and 1.
>
> What I change is just the name
On Wed, 6 Jun 2018, Masatake YAMATO wrote:
> On Wed, 6 Jun 2018 12:37:34 +0200 (CEST), Thomas Gleixner
> wrote:
> > On Wed, 6 Jun 2018, Masatake YAMATO wrote:
> >
> > Can you please explain why 0 is the wrong value.
>
> I don't know such constants, 0 and 1.
>
> What I change is just the name
On Wed, 6 Jun 2018, Pingfan Liu wrote:
> On Wed, Jun 6, 2018 at 5:34 PM, Thomas Gleixner wrote:
> > On Wed, 6 Jun 2018, Pingfan Liu wrote:
> >
> >> On Wed, Jun 6, 2018 at 5:15 PM, Thomas Gleixner wrote:
> >> > On Wed, 6 Jun 2018, Pingfan Liu wrote:
> >> >
> >> >> For x86, there is around 200
On Wed, 6 Jun 2018, Pingfan Liu wrote:
> On Wed, Jun 6, 2018 at 5:34 PM, Thomas Gleixner wrote:
> > On Wed, 6 Jun 2018, Pingfan Liu wrote:
> >
> >> On Wed, Jun 6, 2018 at 5:15 PM, Thomas Gleixner wrote:
> >> > On Wed, 6 Jun 2018, Pingfan Liu wrote:
> >> >
> >> >> For x86, there is around 200
Il 06/06/2018 14:03, Andy Shevchenko ha scritto:
On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
If rs485 is enabled and RTS_AFTER_SEND is set on startup need to keep
TIOCM_RTS asserted to keep rs485 transceiver in RX when idle.
Check if rs485 is on and RTS_AFTER_SEND is set and mask
Hi all,
Note: please do *not* add any v4.19 material to your linux-next included
branches until after v4.18-rc1 has been released.
Changes since 20180605:
The net-next tree lost its build failure but gained a conflict against
Linus' tree.
The staging tree gained conflicts against Linus' tree.
Il 06/06/2018 14:03, Andy Shevchenko ha scritto:
On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
If rs485 is enabled and RTS_AFTER_SEND is set on startup need to keep
TIOCM_RTS asserted to keep rs485 transceiver in RX when idle.
Check if rs485 is on and RTS_AFTER_SEND is set and mask
Hi all,
Note: please do *not* add any v4.19 material to your linux-next included
branches until after v4.18-rc1 has been released.
Changes since 20180605:
The net-next tree lost its build failure but gained a conflict against
Linus' tree.
The staging tree gained conflicts against Linus' tree.
Hi Daniel, Viresh,
On Wed, Jun 06, 2018 at 04:15:28PM +0530, Viresh Kumar wrote:
> On 06-06-18, 12:22, Daniel Lezcano wrote:
> > (mb() are done in the atomic operations AFAICT).
To do my bit, not all atomic ops do/imply memory barriers; e.g.,
[from Documentation/atomic_t.txt]
- non-RMW
Hi Daniel, Viresh,
On Wed, Jun 06, 2018 at 04:15:28PM +0530, Viresh Kumar wrote:
> On 06-06-18, 12:22, Daniel Lezcano wrote:
> > (mb() are done in the atomic operations AFAICT).
To do my bit, not all atomic ops do/imply memory barriers; e.g.,
[from Documentation/atomic_t.txt]
- non-RMW
On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
> If rs485 is enabled and RTS_AFTER_SEND is set on startup need to keep
> TIOCM_RTS asserted to keep rs485 transceiver in RX when idle.
>
> Check if rs485 is on and RTS_AFTER_SEND is set and mask port->mctrl
> with
> TIOCM_RTS too and not
On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
> If rs485 is enabled and RTS_AFTER_SEND is set on startup need to keep
> TIOCM_RTS asserted to keep rs485 transceiver in RX when idle.
>
> Check if rs485 is on and RTS_AFTER_SEND is set and mask port->mctrl
> with
> TIOCM_RTS too and not
On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
> When rs485 enabled and RTS_AFTER_SEND set on startup, need to preserve
> mctrl status, because later functions will call set_mctrl passing
> port->mctrl=0 overriding rts status, resulting in rts pin in
> transmission when idle.
>
> Make
On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
> When rs485 enabled and RTS_AFTER_SEND set on startup, need to preserve
> mctrl status, because later functions will call set_mctrl passing
> port->mctrl=0 overriding rts status, resulting in rts pin in
> transmission when idle.
>
> Make
On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
> RS485 can modify mctrl on startup, especially when RTS_AFTER_SEND is
> on
> TIOCM_RTS is set, then need to keep it set when registering port.
>
> Copy mctrl to new port too.
>
Not sure if it would be useful.
Seems the only em485 user,
On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
> RS485 can modify mctrl on startup, especially when RTS_AFTER_SEND is
> on
> TIOCM_RTS is set, then need to keep it set when registering port.
>
> Copy mctrl to new port too.
>
Not sure if it would be useful.
Seems the only em485 user,
On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
> em485 gets lost during serial8250_register_8250_port().
>
> Copy em485 to final uart port.
>
Is it needed at all?
The individual driver decides either to use software emulation (and
calls explicitly serial8250_em485_init() for that) or
On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
> em485 gets lost during serial8250_register_8250_port().
>
> Copy em485 to final uart port.
>
Is it needed at all?
The individual driver decides either to use software emulation (and
calls explicitly serial8250_em485_init() for that) or
Commit-ID: 838d76d63ec4eaeaa12bedfa50f261480f615200
Gitweb: https://git.kernel.org/tip/838d76d63ec4eaeaa12bedfa50f261480f615200
Author: Dou Liyang
AuthorDate: Fri, 1 Jun 2018 14:50:31 +0800
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 13:38:02 +0200
x86/vector: Fix the args
Commit-ID: 838d76d63ec4eaeaa12bedfa50f261480f615200
Gitweb: https://git.kernel.org/tip/838d76d63ec4eaeaa12bedfa50f261480f615200
Author: Dou Liyang
AuthorDate: Fri, 1 Jun 2018 14:50:31 +0800
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 13:38:02 +0200
x86/vector: Fix the args
On Wed, Jun 6, 2018 at 5:34 PM, Thomas Gleixner wrote:
> On Wed, 6 Jun 2018, Pingfan Liu wrote:
>
>> On Wed, Jun 6, 2018 at 5:15 PM, Thomas Gleixner wrote:
>> > On Wed, 6 Jun 2018, Pingfan Liu wrote:
>> >
>> >> For x86, there is around 200 vectors left for external device on a
>> >> single logic
Commit-ID: 336628128826a9acb045571a960e32e4414ccb61
Gitweb: https://git.kernel.org/tip/336628128826a9acb045571a960e32e4414ccb61
Author: Dou Liyang
AuthorDate: Wed, 23 May 2018 10:35:55 +0800
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 13:38:01 +0200
x86/idt: Simplify the
On Wed, Jun 6, 2018 at 5:34 PM, Thomas Gleixner wrote:
> On Wed, 6 Jun 2018, Pingfan Liu wrote:
>
>> On Wed, Jun 6, 2018 at 5:15 PM, Thomas Gleixner wrote:
>> > On Wed, 6 Jun 2018, Pingfan Liu wrote:
>> >
>> >> For x86, there is around 200 vectors left for external device on a
>> >> single logic
Commit-ID: 336628128826a9acb045571a960e32e4414ccb61
Gitweb: https://git.kernel.org/tip/336628128826a9acb045571a960e32e4414ccb61
Author: Dou Liyang
AuthorDate: Wed, 23 May 2018 10:35:55 +0800
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 13:38:01 +0200
x86/idt: Simplify the
Commit-ID: cce2946b9b30a9b31a18de737d5010c08076e77f
Gitweb: https://git.kernel.org/tip/cce2946b9b30a9b31a18de737d5010c08076e77f
Author: Varsha Rao
AuthorDate: Sun, 20 May 2018 13:30:12 +0530
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 13:38:01 +0200
x86/platform/uv: Remove
Commit-ID: cce2946b9b30a9b31a18de737d5010c08076e77f
Gitweb: https://git.kernel.org/tip/cce2946b9b30a9b31a18de737d5010c08076e77f
Author: Varsha Rao
AuthorDate: Sun, 20 May 2018 13:30:12 +0530
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 13:38:01 +0200
x86/platform/uv: Remove
Commit-ID: 94d49eb30e854c84d1319095b5dd0405a7da9362
Gitweb: https://git.kernel.org/tip/94d49eb30e854c84d1319095b5dd0405a7da9362
Author: Kirill A. Shutemov
AuthorDate: Fri, 18 May 2018 14:30:28 +0300
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 13:38:01 +0200
x86/mm: Decouple
Commit-ID: 94d49eb30e854c84d1319095b5dd0405a7da9362
Gitweb: https://git.kernel.org/tip/94d49eb30e854c84d1319095b5dd0405a7da9362
Author: Kirill A. Shutemov
AuthorDate: Fri, 18 May 2018 14:30:28 +0300
Committer: Thomas Gleixner
CommitDate: Wed, 6 Jun 2018 13:38:01 +0200
x86/mm: Decouple
To turn on the gpu_gx_gdsc, there is a hardware requirement to
turn on the root clock (GFX3D RCG) first which would be the turn
on signal for the gdsc along with the SW_COLLAPSE. As per the
current implementation of clk_rcg2_shared_ops, it clears the
root_enable bit in the enable() and set_rate()
To turn on the gpu_gx_gdsc, there is a hardware requirement to
turn on the root clock (GFX3D RCG) first which would be the turn
on signal for the gdsc along with the SW_COLLAPSE. As per the
current implementation of clk_rcg2_shared_ops, it clears the
root_enable bit in the enable() and set_rate()
For some of the GDSCs, there is a requirement to enable/disable the
few clocks before turning on/off the gdsc power domain. Add support
for the same by specifying a list of clk_hw pointers per gdsc and
enable/disable them along with power domain on/off callbacks.
Signed-off-by: Amit Nischal
---
For some of the GDSCs, there is a requirement to enable/disable the
few clocks before turning on/off the gdsc power domain. Add support
for the same by specifying a list of clk_hw pointers per gdsc and
enable/disable them along with power domain on/off callbacks.
Signed-off-by: Amit Nischal
---
This patch series adds support for graphics clock controller for SDM845.
Below is the brief description for each change:
1. For some of the GDSCs, there is requirement to enable/disable the
few clocks before turning on/off the gdsc power domain. This patch
will add support to enable/disable
Add support for the graphics clock controller found on SDM845
based devices. This would allow graphics drivers to probe and
control their clocks.
Signed-off-by: Amit Nischal
---
drivers/clk/qcom/Kconfig| 9 +
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/gpucc-sdm845.c |
This patch series adds support for graphics clock controller for SDM845.
Below is the brief description for each change:
1. For some of the GDSCs, there is requirement to enable/disable the
few clocks before turning on/off the gdsc power domain. This patch
will add support to enable/disable
Add support for the graphics clock controller found on SDM845
based devices. This would allow graphics drivers to probe and
control their clocks.
Signed-off-by: Amit Nischal
---
drivers/clk/qcom/Kconfig| 9 +
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/gpucc-sdm845.c |
Add device tree bindings for graphics clock controller for
Qualcomm Technology Inc's SoCs.
Signed-off-by: Amit Nischal
---
.../devicetree/bindings/clock/qcom,gpucc.txt | 18 ++
include/dt-bindings/clock/qcom,gpucc-sdm845.h | 38 ++
2 files changed, 56
Add device tree bindings for graphics clock controller for
Qualcomm Technology Inc's SoCs.
Signed-off-by: Amit Nischal
---
.../devicetree/bindings/clock/qcom,gpucc.txt | 18 ++
include/dt-bindings/clock/qcom,gpucc-sdm845.h | 38 ++
2 files changed, 56
Added spaces around various operators, as preferred by coding style.
Signed-off-by: John Whitmore
---
.../rtl8192u/ieee80211/rtl819x_HTProc.c | 22 +--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Added spaces around various operators, as preferred by coding style.
Signed-off-by: John Whitmore
---
.../rtl8192u/ieee80211/rtl819x_HTProc.c | 22 +--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Return statments from void functions are not required by the coding standard.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Function HTIOTActIsDisableMCS14 contained spurious space at start of line.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Return statments from void functions are not required by the coding standard.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Function HTIOTActIsDisableMCS14 contained spurious space at start of line.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Change comparison to NULL to better adhere to coding standard.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Function HTIOTPeerDetermine used incorrect indentation in if statements.
Signed-off-by: John Whitmore
---
.../staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Function HTIOTPeerDetermine used incorrect indentation in if statements.
Signed-off-by: John Whitmore
---
.../staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Change comparison to NULL to better adhere to coding standard.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Remove unneccessary parentheses - Coding Style change
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Remove unneccessary parentheses - Coding Style change
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Declaration of function was spread over three lines.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Declaration of function was spread over three lines.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Simple addition & removal of blank lines as required
Signed-off-by: John Whitmore
---
.../rtl8192u/ieee80211/rtl819x_HTProc.c | 64 +--
1 file changed, 16 insertions(+), 48 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
Version 6 : Sorry to send this out again but version 5 contained a little less
verbosity then required.
Again these are just some simple coding style changes to the file, so nothing
of importance.
Version 6 : Sorry to send this out again but version 5 contained a little less
verbosity then required.
Again these are just some simple coding style changes to the file, so nothing
of importance.
Simple addition & removal of blank lines as required
Signed-off-by: John Whitmore
---
.../rtl8192u/ieee80211/rtl819x_HTProc.c | 64 +--
1 file changed, 16 insertions(+), 48 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
On Wed, 6 Jun 2018 15:01:54 +0530
"Naveen N. Rao" wrote:
> Add powerpc support for the recently added kprobe args tests.
Thank you for adding powerpc support!
Reviewed-by: Masami Hiramatsu
>
> Signed-off-by: Naveen N. Rao
> ---
> .../selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
On Wed, 6 Jun 2018 15:01:54 +0530
"Naveen N. Rao" wrote:
> Add powerpc support for the recently added kprobe args tests.
Thank you for adding powerpc support!
Reviewed-by: Masami Hiramatsu
>
> Signed-off-by: Naveen N. Rao
> ---
> .../selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
On 5 June 2018 at 22:31, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.107 release.
> There are 61 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 5 June 2018 at 22:31, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.107 release.
> There are 61 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 5 June 2018 at 22:31, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.136 release.
> There are 37 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 5 June 2018 at 22:31, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.136 release.
> There are 37 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On Wed 2018-06-06 14:10:29, Sergey Senozhatsky wrote:
> On (06/05/18 14:47), Petr Mladek wrote:
> [..]
> > Grr, the ABBA deadlock is still there. NMIs are not sent to the other
> > CPUs atomically. Even if we detect that logbuf_lock is available
> > in printk_nmi_enter() on some CPUs, it might
On Wed 2018-06-06 14:10:29, Sergey Senozhatsky wrote:
> On (06/05/18 14:47), Petr Mladek wrote:
> [..]
> > Grr, the ABBA deadlock is still there. NMIs are not sent to the other
> > CPUs atomically. Even if we detect that logbuf_lock is available
> > in printk_nmi_enter() on some CPUs, it might
On Wed, 6 Jun 2018 12:37:34 +0200 (CEST), Thomas Gleixner
wrote:
> On Wed, 6 Jun 2018, Masatake YAMATO wrote:
>
> Can you please explain why 0 is the wrong value.
I don't know such constants, 0 and 1.
What I change is just the name of macro parameter as
s/detect/_detect/
I don't
On Wed, 6 Jun 2018 12:37:34 +0200 (CEST), Thomas Gleixner
wrote:
> On Wed, 6 Jun 2018, Masatake YAMATO wrote:
>
> Can you please explain why 0 is the wrong value.
I don't know such constants, 0 and 1.
What I change is just the name of macro parameter as
s/detect/_detect/
I don't
701 - 800 of 1128 matches
Mail list logo
