On Tue, Nov 20, 2018 at 12:44:31PM +0530, Harsh Shandilya wrote:
> On 19 November 2018 9:55:07 PM IST, Greg Kroah-Hartman
> wrote:
> >This is the start of the stable review cycle for the 4.19.3 release.
> >There are 205 patches in this series, all will be posted as a response
> >to this one. If
On Tue, Nov 20, 2018 at 12:44:31PM +0530, Harsh Shandilya wrote:
> On 19 November 2018 9:55:07 PM IST, Greg Kroah-Hartman
> wrote:
> >This is the start of the stable review cycle for the 4.19.3 release.
> >There are 205 patches in this series, all will be posted as a response
> >to this one. If
On Mon, Nov 19, 2018 at 05:09:38PM -0700, shuah wrote:
> On 11/19/18 9:28 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.126 release.
> > There are 90 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues
On Mon, Nov 19, 2018 at 05:09:38PM -0700, shuah wrote:
> On 11/19/18 9:28 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.126 release.
> > There are 90 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues
On Mon 19-11-18 14:05:34, David Rientjes wrote:
> On Thu, 15 Nov 2018, Michal Hocko wrote:
>
> > > The userspace had a single way to determine if thp had been disabled for
> > > a
> > > specific vma and that was broken with your commit. We have since fixed
> > > it. Modifying our software
On Mon 19-11-18 14:05:34, David Rientjes wrote:
> On Thu, 15 Nov 2018, Michal Hocko wrote:
>
> > > The userspace had a single way to determine if thp had been disabled for
> > > a
> > > specific vma and that was broken with your commit. We have since fixed
> > > it. Modifying our software
On Mon 19-11-18 14:16:24, David Rientjes wrote:
> On Mon, 19 Nov 2018, Greg Kroah-Hartman wrote:
>
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
>
> As I noted when this patch was originally proposed and when I nacked it[*]
> because it causes a 13.9%
On Mon 19-11-18 14:16:24, David Rientjes wrote:
> On Mon, 19 Nov 2018, Greg Kroah-Hartman wrote:
>
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
>
> As I noted when this patch was originally proposed and when I nacked it[*]
> because it causes a 13.9%
* Andy Lutomirski wrote:
> The fault handling code tries to validate that a page fault from
> user mode that would extend the stack is within a certain range of
> the user SP. regs->sp is only equal to the user SP if
> user_mode(regs). In the extremely unlikely event that that
>
* Andy Lutomirski wrote:
> The fault handling code tries to validate that a page fault from
> user mode that would extend the stack is within a certain range of
> the user SP. regs->sp is only equal to the user SP if
> user_mode(regs). In the extremely unlikely event that that
>
On Mon, Nov 19, 2018 at 5:50 PM Robin Murphy wrote:
>
> On 19/11/2018 14:18, Ramon Fried wrote:
> > On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
> > wrote:
> >>
> >> On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
> -* Because 32-bit DMA masks are so common we
On Mon, Nov 19, 2018 at 5:50 PM Robin Murphy wrote:
>
> On 19/11/2018 14:18, Ramon Fried wrote:
> > On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
> > wrote:
> >>
> >> On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
> -* Because 32-bit DMA masks are so common we
On 19/11/2018 18.19, Tony Lindgren wrote:
> * Peter Ujfalusi [181119 10:16]:
>> On 2018-11-13 20:06, Tony Lindgren wrote:
>>> Looks like the IRQ_TYPE_NONE issue still is there for omap5 and
>>> should be fixed with IRQ_TYPE_HIGH.
>>>
>>> No idea about why palmas interrupts would stop working
On 19/11/2018 18.19, Tony Lindgren wrote:
> * Peter Ujfalusi [181119 10:16]:
>> On 2018-11-13 20:06, Tony Lindgren wrote:
>>> Looks like the IRQ_TYPE_NONE issue still is there for omap5 and
>>> should be fixed with IRQ_TYPE_HIGH.
>>>
>>> No idea about why palmas interrupts would stop working
* Andy Lutomirski wrote:
> Hi all-
>
> We currently have some giant turds in the way that syscalls are
> numbered. We have the x86_32 table, which is totally sane other than
> some legacy multiplexers. Then we have the x86_64 table, which is,
> um, demented:
>
> - The numbers don't match
* Andy Lutomirski wrote:
> Hi all-
>
> We currently have some giant turds in the way that syscalls are
> numbered. We have the x86_32 table, which is totally sane other than
> some legacy multiplexers. Then we have the x86_64 table, which is,
> um, demented:
>
> - The numbers don't match
Aaro,
On 19/11/2018 20.46, Aaro Koskinen wrote:
> Hi,
>
> On Mon, Nov 19, 2018 at 12:40:40PM +0200, Peter Ujfalusi wrote:
>> When the channel is configured for slave operation the LCH_TYPE needs to be
>> set to LCh-P. For memcpy channels the LCH_TYPE must be set to LCh-2D.
>>
>> Signed-off-by:
On Fri, 16 Nov 2018, Joe Perches wrote:
> On Fri, 2018-11-16 at 14:44 +0200, Jani Nikula wrote:
>> I quickly cooked up this script to produce the top-5 commit prefixes for
>> the given files over the arbitrary last 200 commits. It'll give you a
>> pretty good idea if you're even close.
>>
>> ---
Aaro,
On 19/11/2018 20.46, Aaro Koskinen wrote:
> Hi,
>
> On Mon, Nov 19, 2018 at 12:40:40PM +0200, Peter Ujfalusi wrote:
>> When the channel is configured for slave operation the LCH_TYPE needs to be
>> set to LCh-P. For memcpy channels the LCH_TYPE must be set to LCh-2D.
>>
>> Signed-off-by:
On Fri, 16 Nov 2018, Joe Perches wrote:
> On Fri, 2018-11-16 at 14:44 +0200, Jani Nikula wrote:
>> I quickly cooked up this script to produce the top-5 commit prefixes for
>> the given files over the arbitrary last 200 commits. It'll give you a
>> pretty good idea if you're even close.
>>
>> ---
In case the RSDP address in struct boot_params is specified don't try
to find the table by searching, but take the address directly as set
by the boot loader.
Signed-off-by: Juergen Gross
---
arch/x86/include/uapi/asm/bootparam.h | 3 ++-
arch/x86/kernel/acpi/boot.c | 2 +-
2 files
In case the RSDP address in struct boot_params is specified don't try
to find the table by searching, but take the address directly as set
by the boot loader.
Signed-off-by: Juergen Gross
---
arch/x86/include/uapi/asm/bootparam.h | 3 ++-
arch/x86/kernel/acpi/boot.c | 2 +-
2 files
Hi Uffe
On 19/11/18 6:48 PM, Ulf Hansson wrote:
> On 19 November 2018 at 12:16, Faiz Abbas wrote:
>> Commit 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802")
>> disabled DCRC interrupts during tuning. This write to the interrupt
>> enable register gets overwritten in
Hi Uffe
On 19/11/18 6:48 PM, Ulf Hansson wrote:
> On 19 November 2018 at 12:16, Faiz Abbas wrote:
>> Commit 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802")
>> disabled DCRC interrupts during tuning. This write to the interrupt
>> enable register gets overwritten in
Hello Linus
Signed-off-by: Florian Eckert
This is looking better and better! Thanks to everyone helping out
and thanks for your perseverance Florian!
I have to thanks for reviewing my driver.
This is the way opensource works.
Thanks for the feedback i will update the driver with your
On 19 November 2018 9:55:07 PM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 4.19.3 release.
>There are 205 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.
>
Hello Linus
Signed-off-by: Florian Eckert
This is looking better and better! Thanks to everyone helping out
and thanks for your perseverance Florian!
I have to thanks for reviewing my driver.
This is the way opensource works.
Thanks for the feedback i will update the driver with your
On 19 November 2018 9:55:07 PM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 4.19.3 release.
>There are 205 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.
>
On Tue, 20 Nov 2018 00:57:13 +0100,
Pavel Machek wrote:
>
> > +#if IS_ENABLED(CONFIG_HUAWEI_LAPTOP)
> > +#include
> > +
> > +static int (*huawei_wmi_micmute_led_set_func)(bool);
> > +
>
> So we should not be doing this.
>
> Thinkpad ACPI module exports its LEDs there, for example.
Both
On Tue, 20 Nov 2018 00:57:13 +0100,
Pavel Machek wrote:
>
> > +#if IS_ENABLED(CONFIG_HUAWEI_LAPTOP)
> > +#include
> > +
> > +static int (*huawei_wmi_micmute_led_set_func)(bool);
> > +
>
> So we should not be doing this.
>
> Thinkpad ACPI module exports its LEDs there, for example.
Both
Hi all,
Do you have any comments on this serial?
Thanks.
Wei.
On 13/11/2018 6:06 PM, Wei Ni wrote:
> This series fixed some issues for Tegra soctherm
>
> Main changes from v1:
> 1. Acked by Thierry Reding for the patch
> "thermal: tegra: fix memory allocation".
> 2. Print out the sensor name
Hi all,
Do you have any comments on this serial?
Thanks.
Wei.
On 13/11/2018 6:06 PM, Wei Ni wrote:
> This series fixed some issues for Tegra soctherm
>
> Main changes from v1:
> 1. Acked by Thierry Reding for the patch
> "thermal: tegra: fix memory allocation".
> 2. Print out the sensor name
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, November 19, 2018 1:33 PM
> To: Naga Sureshkumar Relli
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com;
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, November 19, 2018 1:33 PM
> To: Naga Sureshkumar Relli
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com;
Gentle Ping...
Best Regards!
Anson Huang
> -Original Message-
> From: Anson Huang
> Sent: 2018年10月24日 14:40
> To: rui.zh...@intel.com; edubez...@gmail.com; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Cc: dl-linux-imx
> Subject: [PATCH] thermal: imx: fix for dependency on
Gentle Ping...
Best Regards!
Anson Huang
> -Original Message-
> From: Anson Huang
> Sent: 2018年10月24日 14:40
> To: rui.zh...@intel.com; edubez...@gmail.com; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Cc: dl-linux-imx
> Subject: [PATCH] thermal: imx: fix for dependency on
Hello,
My client is seeking a US$100 Million private investment diversification in a
viable business in your region with an Individual like you. This offer will
require your technical and managerial partnership.
Should you be inclined to pursue this offer, Contact me for detailed
information.
Hello,
My client is seeking a US$100 Million private investment diversification in a
viable business in your region with an Individual like you. This offer will
require your technical and managerial partnership.
Should you be inclined to pursue this offer, Contact me for detailed
information.
On Sat, Nov 17, 2018 at 3:03 PM, Bruce Fields wrote:
> On Sat, Nov 17, 2018 at 08:33:27AM -0500, Jeff Layton wrote:
>> Thanks for the explanation, Dmitry. I've added the tag to the patch in
>> my tree. It should show up in linux-next soon.
>>
>> I still find it a little misleading to say that
On Sat, Nov 17, 2018 at 3:03 PM, Bruce Fields wrote:
> On Sat, Nov 17, 2018 at 08:33:27AM -0500, Jeff Layton wrote:
>> Thanks for the explanation, Dmitry. I've added the tag to the patch in
>> my tree. It should show up in linux-next soon.
>>
>> I still find it a little misleading to say that
Hi Rob,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f2ce1065e767fc7da106a5f5381d1e8f842dc6f4
commit: 37c8a5fafa3bb7dcdd51774be353be6cb2912b86 kbuild: consolidate Devicetree
dtb build rules
date: 7 weeks ago
Hi Rob,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f2ce1065e767fc7da106a5f5381d1e8f842dc6f4
commit: 37c8a5fafa3bb7dcdd51774be353be6cb2912b86 kbuild: consolidate Devicetree
dtb build rules
date: 7 weeks ago
We appreciate your comments.
We refine source code according to your comments.
>> This is an interesting idea, and an evolution since the initial
>> approach which was submitted based upon xattr attributes. I still
>> find the idea of using attributes simpler to manage though, since
>> they're
We appreciate your comments.
We refine source code according to your comments.
>> This is an interesting idea, and an evolution since the initial
>> approach which was submitted based upon xattr attributes. I still
>> find the idea of using attributes simpler to manage though, since
>> they're
The current value of the early boot static pool size is not big enough
for systems with large number of CPUs with timer or/and workqueue
objects selected. As the results, systems have 60+ CPUs with both timer
and workqueue objects enabled could trigger "ODEBUG: Out of memory.
ODEBUG disabled".
The current value of the early boot static pool size is not big enough
for systems with large number of CPUs with timer or/and workqueue
objects selected. As the results, systems have 60+ CPUs with both timer
and workqueue objects enabled could trigger "ODEBUG: Out of memory.
ODEBUG disabled".
On 11/20/2018 2:22 AM, Sekhar Nori wrote:
On 13/11/18 7:20 PM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
IRQ numbering") the davinci GPIO driver fails to probe if we boot
in legacy mode from any of the board
On 11/20/2018 2:22 AM, Sekhar Nori wrote:
On 13/11/18 7:20 PM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
IRQ numbering") the davinci GPIO driver fails to probe if we boot
in legacy mode from any of the board
On Tue, 2018-11-13 at 08:00 -0800, Nicolas Boichat wrote:
> On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu wrote:
> >
> > From: Owen Chen
> >
> > On both MT8183 & MT6765, there add "set/clr" register for
> > each clkmux setting, and one update register to trigger value change.
> > It is designed to
On Tue, 2018-11-13 at 08:00 -0800, Nicolas Boichat wrote:
> On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu wrote:
> >
> > From: Owen Chen
> >
> > On both MT8183 & MT6765, there add "set/clr" register for
> > each clkmux setting, and one update register to trigger value change.
> > It is designed to
On 19-11-18, 14:18, Quentin Perret wrote:
> static int cpufreq_init(struct cpufreq_policy *policy)
> {
> + struct em_data_callback em_cb = EM_DATA_CB(of_est_power);
> struct cpufreq_frequency_table *freq_table;
> struct opp_table *opp_table = NULL;
> struct private_data
On 19-11-18, 14:18, Quentin Perret wrote:
> static int cpufreq_init(struct cpufreq_policy *policy)
> {
> + struct em_data_callback em_cb = EM_DATA_CB(of_est_power);
> struct cpufreq_frequency_table *freq_table;
> struct opp_table *opp_table = NULL;
> struct private_data
There are a few system calls (pselect, ppoll, etc) which replace a task
sigmask while they are running in a kernel-space
When a task calls one of these syscalls, the kernel saves a current
sigmask in task->saved_sigmask and sets a syscall sigmask.
On syscall-exit-stop, ptrace traps a task before
There are a few system calls (pselect, ppoll, etc) which replace a task
sigmask while they are running in a kernel-space
When a task calls one of these syscalls, the kernel saves a current
sigmask in task->saved_sigmask and sets a syscall sigmask.
On syscall-exit-stop, ptrace traps a task before
On Tue, 20 Nov 2018, Baoquan He wrote:
> On 11/19/18 at 09:59pm, Michal Hocko wrote:
> > On Mon 19-11-18 12:34:09, Hugh Dickins wrote:
> > > I'm glad that I delayed, what I had then (migration_waitqueue instead
> > > of using page_waitqueue) was not wrong, but what I've been using the
> > > last
On Tue, 20 Nov 2018, Baoquan He wrote:
> On 11/19/18 at 09:59pm, Michal Hocko wrote:
> > On Mon 19-11-18 12:34:09, Hugh Dickins wrote:
> > > I'm glad that I delayed, what I had then (migration_waitqueue instead
> > > of using page_waitqueue) was not wrong, but what I've been using the
> > > last
Hi Rob,
On 17/11/18 1:50 AM, Rob Herring wrote:
On Thu, Oct 18, 2018 at 8:31 AM Rob Herring wrote:
DT bindings normally go in via subsystem maintainers, so add PHY
bindings under generic PHY framework.
Reported-by: Gustavo A. R. Silva
Cc: Kishon Vijay Abraham I
Signed-off-by: Rob Herring
Hi Rob,
On 17/11/18 1:50 AM, Rob Herring wrote:
On Thu, Oct 18, 2018 at 8:31 AM Rob Herring wrote:
DT bindings normally go in via subsystem maintainers, so add PHY
bindings under generic PHY framework.
Reported-by: Gustavo A. R. Silva
Cc: Kishon Vijay Abraham I
Signed-off-by: Rob Herring
More details of the seal can be found in the LKML patch:
https://lore.kernel.org/lkml/20181120052137.74317-1-j...@joelfernandes.org/T/#t
Signed-off-by: Joel Fernandes (Google)
---
man2/memfd_create.2 | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git
More details of the seal can be found in the LKML patch:
https://lore.kernel.org/lkml/20181120052137.74317-1-j...@joelfernandes.org/T/#t
Signed-off-by: Joel Fernandes (Google)
---
man2/memfd_create.2 | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git
More details of the seal can be found in the LKML patch:
https://lore.kernel.org/lkml/20181120052137.74317-1-j...@joelfernandes.org/T/#t
Signed-off-by: Joel Fernandes (Google)
---
man2/fcntl.2 | 15 +++
1 file changed, 15 insertions(+)
diff --git a/man2/fcntl.2 b/man2/fcntl.2
index
More details of the seal can be found in the LKML patch:
https://lore.kernel.org/lkml/20181120052137.74317-1-j...@joelfernandes.org/T/#t
Signed-off-by: Joel Fernandes (Google)
---
man2/fcntl.2 | 15 +++
1 file changed, 15 insertions(+)
diff --git a/man2/fcntl.2 b/man2/fcntl.2
index
A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week
where we don't need to modify core VFS structures to get the same
behavior of the seal. This solves several side-effects pointed out by
Andy [2].
[1] https://lore.kernel.org/lkml/2018173650.ga256...@google.com/
[2]
Modify the tests for F_SEAL_FUTURE_WRITE based on the changes
introduced in previous patch.
Also add a test to make sure the reopen issue pointed by Jann Horn [1]
is fixed.
[1]
https://lore.kernel.org/lkml/CAG48ez1h=v-JYnDw81HaYJzOfrNhwYksxmc2r=cjvdqvgym...@mail.gmail.com/
Cc: Jann Horn
A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week
where we don't need to modify core VFS structures to get the same
behavior of the seal. This solves several side-effects pointed out by
Andy [2].
[1] https://lore.kernel.org/lkml/2018173650.ga256...@google.com/
[2]
Modify the tests for F_SEAL_FUTURE_WRITE based on the changes
introduced in previous patch.
Also add a test to make sure the reopen issue pointed by Jann Horn [1]
is fixed.
[1]
https://lore.kernel.org/lkml/CAG48ez1h=v-JYnDw81HaYJzOfrNhwYksxmc2r=cjvdqvgym...@mail.gmail.com/
Cc: Jann Horn
Hi Matias,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f2ce1065e767fc7da106a5f5381d1e8f842dc6f4
commit: 73569e11032fc5a9b314b6351632cfca7793afd5 lightnvm: remove dependencies
on BLK_DEV_NVME and PCI
date: 6
Hi Matias,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f2ce1065e767fc7da106a5f5381d1e8f842dc6f4
commit: 73569e11032fc5a9b314b6351632cfca7793afd5 lightnvm: remove dependencies
on BLK_DEV_NVME and PCI
date: 6
On Mon, 19 Nov 2018, Yu Zhao wrote:
> On Mon, Nov 19, 2018 at 02:11:27PM -0800, Hugh Dickins wrote:
> > On Sun, 18 Nov 2018, Yu Zhao wrote:
> >
> > > We used to have a single swap address space with swp_entry_t.val
> > > as its radix tree index. This is not the case anymore. Now Each
> > >
On Mon, 19 Nov 2018, Yu Zhao wrote:
> On Mon, Nov 19, 2018 at 02:11:27PM -0800, Hugh Dickins wrote:
> > On Sun, 18 Nov 2018, Yu Zhao wrote:
> >
> > > We used to have a single swap address space with swp_entry_t.val
> > > as its radix tree index. This is not the case anymore. Now Each
> > >
Hi Marc,
On Mon, Nov 19, 2018 at 05:57:12PM +, Marc Zyngier wrote:
> On 19/11/2018 17:09, Manivannan Sadhasivam wrote:
> > Add clock driver for RDA Micro RDA8810PL SoC supporting OSTIMER
> > and HWTIMER.
> >
> > Signed-off-by: Andreas Färber
> > Signed-off-by: Manivannan Sadhasivam
> > ---
From: Andi Kleen
Fix incorrect event names for the Load_Miss_Real_Latency metric for
Skylake and Skylake Server.
Fixes https://github.com/andikleen/pmu-tools/issues/158
Before:
% perf stat -M Load_Miss_Real_Latency true
event syntax error:
Hi Marc,
On Mon, Nov 19, 2018 at 05:57:12PM +, Marc Zyngier wrote:
> On 19/11/2018 17:09, Manivannan Sadhasivam wrote:
> > Add clock driver for RDA Micro RDA8810PL SoC supporting OSTIMER
> > and HWTIMER.
> >
> > Signed-off-by: Andreas Färber
> > Signed-off-by: Manivannan Sadhasivam
> > ---
From: Andi Kleen
Fix incorrect event names for the Load_Miss_Real_Latency metric for
Skylake and Skylake Server.
Fixes https://github.com/andikleen/pmu-tools/issues/158
Before:
% perf stat -M Load_Miss_Real_Latency true
event syntax error:
From: Andi Kleen
This is a fix for another instance of the skid problem Milian
recently found [1]
The LBRs don't freeze at the exact same time as the PMI is triggered.
The perf script brstackinsn code that dumps LBR assembler
assumes that the last branch in the LBR leads to the sample point.
From: Andi Kleen
This is a fix for another instance of the skid problem Milian
recently found [1]
The LBRs don't freeze at the exact same time as the PMI is triggered.
The perf script brstackinsn code that dumps LBR assembler
assumes that the last branch in the LBR leads to the sample point.
Hi all,
Changes since 20181119:
The regulator tree gained a build failure so I used the version from
next-20181119.
The tip tree still had its build failure for which I applied a fix patch.
The staging tree gained a conflict against the drm tree.
Non-merge commits (relative to Linus' tree
Hi all,
Changes since 20181119:
The regulator tree gained a build failure so I used the version from
next-20181119.
The tip tree still had its build failure for which I applied a fix patch.
The staging tree gained a conflict against the drm tree.
Non-merge commits (relative to Linus' tree
On 19/11/18 4:46 PM, Faiz Abbas wrote:
The sdhci_execute_tuning() function has assignment of
private pointers multiple times. Remove the redundant assignment.
Signed-off-by: Faiz Abbas
Acked-by: Kishon Vijay Abraham I
---
drivers/mmc/host/sdhci-omap.c | 4
1 file changed, 4
On 19/11/18 4:46 PM, Faiz Abbas wrote:
The sdhci_execute_tuning() function has assignment of
private pointers multiple times. Remove the redundant assignment.
Signed-off-by: Faiz Abbas
Acked-by: Kishon Vijay Abraham I
---
drivers/mmc/host/sdhci-omap.c | 4
1 file changed, 4
On 19/11/18 4:46 PM, Faiz Abbas wrote:
The TRM (SPRUIC2C - January 2017 - Revised May 2018 [1]) forbids
assertion of data reset while tuning is happening. Implement a
platform specific callback that takes care of this condition.
[1] http://www.ti.com/lit/pdf/spruic2 Section 25.5.1.2.4
On 19/11/18 4:46 PM, Faiz Abbas wrote:
The TRM (SPRUIC2C - January 2017 - Revised May 2018 [1]) forbids
assertion of data reset while tuning is happening. Implement a
platform specific callback that takes care of this condition.
[1] http://www.ti.com/lit/pdf/spruic2 Section 25.5.1.2.4
Daniel Colascione writes:
> On Mon, Nov 19, 2018 at 1:37 PM Christian Brauner
> wrote:
>>
>> On Mon, Nov 19, 2018 at 01:26:22PM -0800, Daniel Colascione wrote:
>> > On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
>> > wrote:
>> > > That can be done without a loop by comparing the level
Daniel Colascione writes:
> On Mon, Nov 19, 2018 at 1:37 PM Christian Brauner
> wrote:
>>
>> On Mon, Nov 19, 2018 at 01:26:22PM -0800, Daniel Colascione wrote:
>> > On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
>> > wrote:
>> > > That can be done without a loop by comparing the level
Hi,
On 19/11/18 4:46 PM, Faiz Abbas wrote:
Commit 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802")
disabled DCRC interrupts during tuning. This write to the interrupt
enable register gets overwritten in sdhci_prepare_data() and the
interrupt is not in fact disabled. Fix this by
Hi,
On 19/11/18 4:46 PM, Faiz Abbas wrote:
Commit 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802")
disabled DCRC interrupts during tuning. This write to the interrupt
enable register gets overwritten in sdhci_prepare_data() and the
interrupt is not in fact disabled. Fix this by
On 19-11-18, 14:18, Quentin Perret wrote:
> @@ -223,20 +222,33 @@ static unsigned long sugov_get_util(struct sugov_cpu
> *sg_cpu)
> - if ((util + cpu_util_dl(rq)) >= max)
> - return max;
> + if (type == FREQUENCY_UTIL) {
> + /*
> + * For frequency
On 19-11-18, 14:18, Quentin Perret wrote:
> @@ -223,20 +222,33 @@ static unsigned long sugov_get_util(struct sugov_cpu
> *sg_cpu)
> - if ((util + cpu_util_dl(rq)) >= max)
> - return max;
> + if (type == FREQUENCY_UTIL) {
> + /*
> + * For frequency
On 11/9/2018 10:09 PM, Niklas Cassel wrote:
On Mon, Nov 05, 2018 at 05:17:45PM -0600, Rob Herring wrote:
On Mon, Oct 15, 2018 at 02:47:49PM +0200, Niklas Cassel wrote:
Extend qcom-opp bindings with properties needed for Core Power Reduction
(CPR).
CPR is included in a great variety of
On 11/9/2018 10:09 PM, Niklas Cassel wrote:
On Mon, Nov 05, 2018 at 05:17:45PM -0600, Rob Herring wrote:
On Mon, Oct 15, 2018 at 02:47:49PM +0200, Niklas Cassel wrote:
Extend qcom-opp bindings with properties needed for Core Power Reduction
(CPR).
CPR is included in a great variety of
On Mon, Nov 19, 2018 at 01:39:02PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:bae4e109837b mlxsw: spectrum: Expose discard counters via ..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=11b5e77b40
>
On Mon, Nov 19, 2018 at 01:39:02PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:bae4e109837b mlxsw: spectrum: Expose discard counters via ..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=11b5e77b40
>
> On Fri, Nov 16, 2018 at 11:19:41AM -0800, Todd Kjos wrote:
> > On Thu, Nov 15, 2018 at 2:54 PM gre...@linuxfoundation.org
> > wrote:
> > ...
> > >
> > > A number of us have talked about this in the plumbers Android track, and
> > > a different proposal for how to solve this has been made that
> On Fri, Nov 16, 2018 at 11:19:41AM -0800, Todd Kjos wrote:
> > On Thu, Nov 15, 2018 at 2:54 PM gre...@linuxfoundation.org
> > wrote:
> > ...
> > >
> > > A number of us have talked about this in the plumbers Android track, and
> > > a different proposal for how to solve this has been made that
On Tue, 2018-11-13 at 08:18 -0800, Nicolas Boichat wrote:
> On Mon, Nov 5, 2018 at 10:43 PM Weiyi Lu wrote:
> >
> > From: Owen Chen
> >
> > 1. pcwibits: The integer bits of pcw for plls is extend to 8 bits,
> >add a variable to indicate this change and
> >backward-compatible.
> > 2.
On Tue, 2018-11-13 at 08:18 -0800, Nicolas Boichat wrote:
> On Mon, Nov 5, 2018 at 10:43 PM Weiyi Lu wrote:
> >
> > From: Owen Chen
> >
> > 1. pcwibits: The integer bits of pcw for plls is extend to 8 bits,
> >add a variable to indicate this change and
> >backward-compatible.
> > 2.
On Tue, 20 Nov 2018, Masahiro Yamada wrote:
> My main motivation of this commit is to clean up scripts/Kbuild.include
> and scripts/Makefile.build.
>
> Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick;
> possibly exported symbols are detected by letting $(CPP) replace
>
On Tue, 20 Nov 2018, Masahiro Yamada wrote:
> My main motivation of this commit is to clean up scripts/Kbuild.include
> and scripts/Makefile.build.
>
> Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick;
> possibly exported symbols are detected by letting $(CPP) replace
>
Hi Marc,
Thanks for the quick review!
On Mon, Nov 19, 2018 at 05:36:49PM +, Marc Zyngier wrote:
> Manivannan,
>
> On 19/11/2018 17:09, Manivannan Sadhasivam wrote:
> > Add interrupt driver for RDA Micro RDA8810PL SoC.
> >
> > Signed-off-by: Andreas Färber
> > Signed-off-by: Manivannan
Hi Marc,
Thanks for the quick review!
On Mon, Nov 19, 2018 at 05:36:49PM +, Marc Zyngier wrote:
> Manivannan,
>
> On 19/11/2018 17:09, Manivannan Sadhasivam wrote:
> > Add interrupt driver for RDA Micro RDA8810PL SoC.
> >
> > Signed-off-by: Andreas Färber
> > Signed-off-by: Manivannan
1 - 100 of 3448 matches
Mail list logo
