The probe function references >dev many times. Add 'dev' as
a shorthand.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali_dt.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git
The probe function references >dev many times. Add 'dev' as
a shorthand.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali_dt.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git
On Thu, Jun 14, 2018 at 11:30:34PM +0200, Oscar Salvador wrote:
> On Thu, Jun 14, 2018 at 06:34:55AM +, Naoya Horiguchi wrote:
> > On Thu, Jun 14, 2018 at 07:38:59AM +0200, Oscar Salvador wrote:
> > > On Thu, Jun 14, 2018 at 05:16:18AM +, Naoya Horiguchi wrote:
> > ...
> > > >
> > > > My
On Thu, Jun 14, 2018 at 11:30:34PM +0200, Oscar Salvador wrote:
> On Thu, Jun 14, 2018 at 06:34:55AM +, Naoya Horiguchi wrote:
> > On Thu, Jun 14, 2018 at 07:38:59AM +0200, Oscar Salvador wrote:
> > > On Thu, Jun 14, 2018 at 05:16:18AM +, Naoya Horiguchi wrote:
> > ...
> > > >
> > > > My
On Thu, Jun 14, 2018 at 01:24:37PM +0200, Oscar Salvador wrote:
> On Thu, Jun 14, 2018 at 09:21:03AM +0200, Oscar Salvador wrote:
> > On Thu, Jun 14, 2018 at 06:34:55AM +, Naoya Horiguchi wrote:
> > > On Thu, Jun 14, 2018 at 07:38:59AM +0200, Oscar Salvador wrote:
> > > > On Thu, Jun 14, 2018
On Thu, Jun 14, 2018 at 01:24:37PM +0200, Oscar Salvador wrote:
> On Thu, Jun 14, 2018 at 09:21:03AM +0200, Oscar Salvador wrote:
> > On Thu, Jun 14, 2018 at 06:34:55AM +, Naoya Horiguchi wrote:
> > > On Thu, Jun 14, 2018 at 07:38:59AM +0200, Oscar Salvador wrote:
> > > > On Thu, Jun 14, 2018
On Thu, Jun 14, 2018 at 09:00:50AM +0200, Michal Hocko wrote:
> On Thu 14-06-18 05:16:18, Naoya Horiguchi wrote:
> > On Wed, Jun 13, 2018 at 11:07:00AM +0200, Michal Hocko wrote:
> > > On Wed 13-06-18 05:41:08, Naoya Horiguchi wrote:
> > > [...]
> > > > From: Naoya Horiguchi
> > > > Date: Wed, 13
On Thu, Jun 14, 2018 at 09:00:50AM +0200, Michal Hocko wrote:
> On Thu 14-06-18 05:16:18, Naoya Horiguchi wrote:
> > On Wed, Jun 13, 2018 at 11:07:00AM +0200, Michal Hocko wrote:
> > > On Wed 13-06-18 05:41:08, Naoya Horiguchi wrote:
> > > [...]
> > > > From: Naoya Horiguchi
> > > > Date: Wed, 13
From: "Joel Fernandes (Google)"
Currently, trace event triggers are called regardless of if the event
filter checks pass or fail. Thus if one were to enable event triggers
and filters at the same time, then the triggers will always be called
even if the filter checks didn't pass.
This is a
From: "Joel Fernandes (Google)"
Currently, trace event triggers are called regardless of if the event
filter checks pass or fail. Thus if one were to enable event triggers
and filters at the same time, then the triggers will always be called
even if the filter checks didn't pass.
This is a
Hi Roger,
If possible, Could you please review this patch?
Regards,
Chanwoo Choi
On 2018년 06월 14일 20:33, H. Nikolaus Schaller wrote:
>
>> Am 14.06.2018 um 12:39 schrieb H. Nikolaus Schaller :
>>
>> Hi Roger and Chanwoo,
>>
>>> Am 14.06.2018 um 12:18 schrieb Chanwoo Choi :
>>>
>>> + H.
Hi Roger,
If possible, Could you please review this patch?
Regards,
Chanwoo Choi
On 2018년 06월 14일 20:33, H. Nikolaus Schaller wrote:
>
>> Am 14.06.2018 um 12:39 schrieb H. Nikolaus Schaller :
>>
>> Hi Roger and Chanwoo,
>>
>>> Am 14.06.2018 um 12:18 schrieb Chanwoo Choi :
>>>
>>> + H.
On 14 June 2018 at 19:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.16.16 release.
> There are 43 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 14 June 2018 at 19:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.16.16 release.
> There are 43 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 14 June 2018 at 19:33, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.2 release.
> There are 45 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 14 June 2018 at 19:33, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.2 release.
> There are 45 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
Hi Arnd,
Today's linux-next merge of the y2038 tree got conflicts in:
fs/inode.c
fs/overlayfs/inode.c
fs/overlayfs/overlayfs.h
between various commits from the overlayfs tree and commits:
8efd6894ff08 ("fs: add timespec64_truncate()")
95582b008388 ("vfs: change inode times to use
Hi Arnd,
Today's linux-next merge of the y2038 tree got conflicts in:
fs/inode.c
fs/overlayfs/inode.c
fs/overlayfs/overlayfs.h
between various commits from the overlayfs tree and commits:
8efd6894ff08 ("fs: add timespec64_truncate()")
95582b008388 ("vfs: change inode times to use
On 14 June 2018 at 19:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.50 release.
> There are 36 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 14 June 2018 at 19:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.50 release.
> There are 36 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 14 June 2018 at 19:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.109 release.
> There are 30 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 14 June 2018 at 19:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.109 release.
> There are 30 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.
>
>
---
kernel: 4.4.138-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.138-rc1-hikey-20180614-218
git commit: 55a4e4dfb0ebf4bbc212a778883e72f06d3735b7
git describe: 4.4.138-rc1-hikey-20180614-218
Test details: https://qa-reports.linaro
Hi Vinod
Thank you for your feedback
> > From: Kuninori Morimoto
> >
> > Current rcar-dmac is using DMAC error interrupt which will handle all
> > channel's error. But in this design, error handling itself will be
> > issue if user want to use virtualization, multi OS, etc.
> > This patch
---
kernel: 4.4.138-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.138-rc1-hikey-20180614-218
git commit: 55a4e4dfb0ebf4bbc212a778883e72f06d3735b7
git describe: 4.4.138-rc1-hikey-20180614-218
Test details: https://qa-reports.linaro
Hi Vinod
Thank you for your feedback
> > From: Kuninori Morimoto
> >
> > Current rcar-dmac is using DMAC error interrupt which will handle all
> > channel's error. But in this design, error handling itself will be
> > issue if user want to use virtualization, multi OS, etc.
> > This patch
ping
Ted,
Any comment is appreciated.
Regards,
Yang
On 5/30/18 4:56 PM, Yang Shi wrote:
commit 1efff914afac8a965ad63817ecf8861a927c2ace ("fs: add
dirtytime_expire_seconds sysctl") introduced dirtytime_expire_seconds
knob, but there is not description about it in
ping
Ted,
Any comment is appreciated.
Regards,
Yang
On 5/30/18 4:56 PM, Yang Shi wrote:
commit 1efff914afac8a965ad63817ecf8861a927c2ace ("fs: add
dirtytime_expire_seconds sysctl") introduced dirtytime_expire_seconds
knob, but there is not description about it in
Depending on how it is configured the autofs user space daemon can
leave in use mounts mounted at exit and re-connect to them at start
up. But for this to work best the state of the autofs file system
needs to be left intact over the restart.
Also, at system shutdown, mounts in an autofs file
Depending on how it is configured the autofs user space daemon can
leave in use mounts mounted at exit and re-connect to them at start
up. But for this to work best the state of the autofs file system
needs to be left intact over the restart.
Also, at system shutdown, mounts in an autofs file
Wire up the restartable sequences (rseq) syscall for MIPS. This was
introduced by commit d7822b1e24f2 ("rseq: Introduce restartable
sequences system call") & MIPS now supports the prerequisites.
Signed-off-by: Paul Burton
Cc: James Hogan
Cc: Ralf Baechle
Cc: Mathieu Desnoyers
Cc: Peter
Wire up the restartable sequences (rseq) syscall for MIPS. This was
introduced by commit d7822b1e24f2 ("rseq: Introduce restartable
sequences system call") & MIPS now supports the prerequisites.
Signed-off-by: Paul Burton
Cc: James Hogan
Cc: Ralf Baechle
Cc: Mathieu Desnoyers
Cc: Peter
Implement support for both MIPS32 & MIPS64 in the rseq selftests, in
order to sanity check the recently enabled rseq syscall.
The tests all pass on a MIPS Boston development board running either a
MIPS32r2 interAptiv CPU & a MIPS64r6 I6500 CPU, both of which were
configured with 2 cores each of
Implement support for both MIPS32 & MIPS64 in the rseq selftests, in
order to sanity check the recently enabled rseq syscall.
The tests all pass on a MIPS Boston development board running either a
MIPS32r2 interAptiv CPU & a MIPS64r6 I6500 CPU, both of which were
configured with 2 cores each of
Implement support for restartable sequences on MIPS, which requires 3
simple things:
- Call rseq_handle_notify_resume() on return to userspace if
TIF_NOTIFY_RESUME is set.
- Call rseq_signal_deliver() to fixup the pre-signal stack frame when
a signal is delivered whilst executing a
Implement support for restartable sequences on MIPS, which requires 3
simple things:
- Call rseq_handle_notify_resume() on return to userspace if
TIF_NOTIFY_RESUME is set.
- Call rseq_signal_deliver() to fixup the pre-signal stack frame when
a signal is delivered whilst executing a
Syscalls are not allowed inside restartable sequences, so add a call to
rseq_syscall() at the very beginning of the system call exit path when
CONFIG_DEBUG_RSEQ=y. This will help us to detect whether there is a
syscall issued erroneously inside a restartable sequence.
Signed-off-by: Paul Burton
This series implements MIPS support for restartable sequences, hooks up
the rseq syscall & implements MIPS support in the rseq selftests.
Applies atop Linus' master as of 2837461dbe6f ("Merge tag 'scsi-fixes'
of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi").
Thanks,
Paul
Paul
This series implements MIPS support for restartable sequences, hooks up
the rseq syscall & implements MIPS support in the rseq selftests.
Applies atop Linus' master as of 2837461dbe6f ("Merge tag 'scsi-fixes'
of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi").
Thanks,
Paul
Paul
Syscalls are not allowed inside restartable sequences, so add a call to
rseq_syscall() at the very beginning of the system call exit path when
CONFIG_DEBUG_RSEQ=y. This will help us to detect whether there is a
syscall issued erroneously inside a restartable sequence.
Signed-off-by: Paul Burton
On Thu, 2018-06-14 at 10:27 +0200, Geert Uytterhoeven wrote:
> > --- a/include/linux/of_address.h
> > +++ b/include/linux/of_address.h
> > @@ -40,6 +40,11 @@ extern void __iomem *of_iomap(struct device_node
> > *device, int index);
> > void __iomem *of_io_request_and_map(struct device_node
On Thu, 2018-06-14 at 10:27 +0200, Geert Uytterhoeven wrote:
> > --- a/include/linux/of_address.h
> > +++ b/include/linux/of_address.h
> > @@ -40,6 +40,11 @@ extern void __iomem *of_iomap(struct device_node
> > *device, int index);
> > void __iomem *of_io_request_and_map(struct device_node
- vkuzn...@redhat.com wrote:
> From: Ladi Prosek
>
> The state related to the VP assist page is still managed by the LAPIC
> code in the pv_eoi field.
>
> Signed-off-by: Ladi Prosek
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/kvm/hyperv.c | 23 +--
>
- vkuzn...@redhat.com wrote:
> From: Ladi Prosek
>
> The state related to the VP assist page is still managed by the LAPIC
> code in the pv_eoi field.
>
> Signed-off-by: Ladi Prosek
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/kvm/hyperv.c | 23 +--
>
- vkuzn...@redhat.com wrote:
> When Enlightened VMCS is in use by L1 hypervisor we can avoid
> vmwriting
> VMCS fields which did not change.
>
> Our first goal is to achieve minimal impact on traditional VMCS case
> so
> we're not wrapping each vmwrite() with an if-changed checker. We also
- vkuzn...@redhat.com wrote:
> When Enlightened VMCS is in use by L1 hypervisor we can avoid
> vmwriting
> VMCS fields which did not change.
>
> Our first goal is to achieve minimal impact on traditional VMCS case
> so
> we're not wrapping each vmwrite() with an if-changed checker. We also
- vkuzn...@redhat.com wrote:
> Adds hv_evmcs pointer and implement copy_enlightened_to_vmcs12() and
> copy_enlightened_to_vmcs12().
>
> prepare_vmcs02()/prepare_vmcs02_full() separation is not valid for
> Enlightened VMCS, do full sync for now.
>
> Suggested-by: Ladi Prosek
>
- vkuzn...@redhat.com wrote:
> Adds hv_evmcs pointer and implement copy_enlightened_to_vmcs12() and
> copy_enlightened_to_vmcs12().
>
> prepare_vmcs02()/prepare_vmcs02_full() separation is not valid for
> Enlightened VMCS, do full sync for now.
>
> Suggested-by: Ladi Prosek
>
When zram test is skipped because of unmet dependencies and/or
unsupported configuration, it exits with error which is treated as
a fail by the Kselftest framework. This leads to false negative result
even when the test could not be run.
Change it to return kselftest skip code when a test gets
When zram test is skipped because of unmet dependencies and/or
unsupported configuration, it exits with error which is treated as
a fail by the Kselftest framework. This leads to false negative result
even when the test could not be run.
Change it to return kselftest skip code when a test gets
- vkuzn...@redhat.com wrote:
> Per Hyper-V TLFS 5.0b:
>
> "The L1 hypervisor may choose to use enlightened VMCSs by writing 1
> to
> the corresponding field in the VP assist page (see section 7.8.7).
> Another field in the VP assist page controls the currently active
> enlightened VMCS.
- vkuzn...@redhat.com wrote:
> Per Hyper-V TLFS 5.0b:
>
> "The L1 hypervisor may choose to use enlightened VMCSs by writing 1
> to
> the corresponding field in the VP assist page (see section 7.8.7).
> Another field in the VP assist page controls the currently active
> enlightened VMCS.
The mm-of-the-moment snapshot 2018-06-14-16-20 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
The mm-of-the-moment snapshot 2018-06-14-16-20 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On Thu, Jun 14, 2018 at 10:24 AM, Jason Gunthorpe wrote:
> On Thu, Jun 14, 2018 at 10:03:09AM -0700, Cong Wang wrote:
>> On Thu, Jun 14, 2018 at 7:24 AM, Jason Gunthorpe wrote:
>> >
>> > This was my brief reaction too, this code path almost certainly has a
>> > use-after-free, and we should fix
On Thu, Jun 14, 2018 at 10:24 AM, Jason Gunthorpe wrote:
> On Thu, Jun 14, 2018 at 10:03:09AM -0700, Cong Wang wrote:
>> On Thu, Jun 14, 2018 at 7:24 AM, Jason Gunthorpe wrote:
>> >
>> > This was my brief reaction too, this code path almost certainly has a
>> > use-after-free, and we should fix
On Thu, Jun 14, 2018 at 10:18:58AM +0200, Greg Kroah-Hartman wrote:
>On Fri, Jun 08, 2018 at 07:42:47PM +0100, Ben Hutchings wrote:
>> On Mon, 2018-05-28 at 12:00 +0200, Greg Kroah-Hartman wrote:
>> > 4.4-stable review patch. If anyone has any objections, please let me know.
>> >
>> >
On Thu, Jun 14, 2018 at 10:18:58AM +0200, Greg Kroah-Hartman wrote:
>On Fri, Jun 08, 2018 at 07:42:47PM +0100, Ben Hutchings wrote:
>> On Mon, 2018-05-28 at 12:00 +0200, Greg Kroah-Hartman wrote:
>> > 4.4-stable review patch. If anyone has any objections, please let me know.
>> >
>> >
- vkuzn...@redhat.com wrote:
> Enlightened VMCS is opt-in. The current version does not contain all
> fields supported by nested VMX so we must not advertise the
> corresponding VMX features if enlightened VMCS is enabled.
>
> Userspace is given the enlightened VMCS version supported by
- vkuzn...@redhat.com wrote:
> Enlightened VMCS is opt-in. The current version does not contain all
> fields supported by nested VMX so we must not advertise the
> corresponding VMX features if enlightened VMCS is enabled.
>
> Userspace is given the enlightened VMCS version supported by
As per the documentation, Kernel Samepage Merging (available
since 2.6.32) is a memory-saving de-duplication feature,
enabled by CONFIG_KSM=y and activated via sysfs. More
information can be found here:
https://www.kernel.org/doc/Documentation/vm/ksm.txt
When enabled in the kernel, the default
As per the documentation, Kernel Samepage Merging (available
since 2.6.32) is a memory-saving de-duplication feature,
enabled by CONFIG_KSM=y and activated via sysfs. More
information can be found here:
https://www.kernel.org/doc/Documentation/vm/ksm.txt
When enabled in the kernel, the default
As per the documentation, Kernel Samepage Merging (available
since 2.6.32) is a memory-saving de-duplication feature,
enabled by CONFIG_KSM=y and activated via sysfs. More
information can be found here:
https://www.kernel.org/doc/Documentation/vm/ksm.txt
When enabled in the kernel, the default
As per the documentation, Kernel Samepage Merging (available
since 2.6.32) is a memory-saving de-duplication feature,
enabled by CONFIG_KSM=y and activated via sysfs. More
information can be found here:
https://www.kernel.org/doc/Documentation/vm/ksm.txt
When enabled in the kernel, the default
On 06/14/2018 08:04 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.138 release.
> There are 24 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 06/14/2018 08:04 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.138 release.
> There are 24 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 06/14/2018 08:04 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.109 release.
> There are 30 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 06/14/2018 08:04 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.109 release.
> There are 30 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 06/14/2018 08:04 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.50 release.
> There are 36 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 06/14/2018 08:04 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.50 release.
> There are 36 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 06/14/2018 08:04 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.16.16 release.
> There are 43 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 06/14/2018 08:04 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.16.16 release.
> There are 43 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
From: Jiri Kosina
Xen PV domain is not by design affected by meltdown as it's enforcing
split CR3 itself. Let's not report such systems as "Vulnerable" in sysfs
(we're also already forcing PTI to off in X86_HYPER_XEN_PV cases)
Reported-and-tested-by: Mike Latimer
Signed-off-by: Jiri Kosina
From: Jiri Kosina
Xen PV domain is not by design affected by meltdown as it's enforcing
split CR3 itself. Let's not report such systems as "Vulnerable" in sysfs
(we're also already forcing PTI to off in X86_HYPER_XEN_PV cases)
Reported-and-tested-by: Mike Latimer
Signed-off-by: Jiri Kosina
On Thu, 14 Jun 2018 22:55:56 +0100
Ben Hutchings wrote:
> On Mon, 2018-05-28 at 12:02 +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Davidlohr Bueso
> >
> > [ Upstream commit
On Thu, 14 Jun 2018 22:55:56 +0100
Ben Hutchings wrote:
> On Mon, 2018-05-28 at 12:02 +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Davidlohr Bueso
> >
> > [ Upstream commit
On 6/14/2018 12:25 PM, Andy Shevchenko wrote:
> On Thu, Jun 14, 2018 at 5:22 PM, Stuart Hayes
> wrote:
>> On 6/13/2018 3:54 AM, Andy Shevchenko wrote:
>
+* Provide physical address of command buffer field within
+* the struct smi_cmd... can't use
On 06/14/2018 08:03 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.2 release.
> There are 45 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 06/14/2018 08:03 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.2 release.
> There are 45 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 6/14/2018 12:25 PM, Andy Shevchenko wrote:
> On Thu, Jun 14, 2018 at 5:22 PM, Stuart Hayes
> wrote:
>> On 6/13/2018 3:54 AM, Andy Shevchenko wrote:
>
+* Provide physical address of command buffer field within
+* the struct smi_cmd... can't use
Modify the driver so it no longer requests and manipulates the
"keybrd_pwr" GPIO pin but a "vcc" regulator supply instead.
For this to work with Amstrad Delta, define a regulator over the
"keybrd_pwr" GPIO pin with the "vcc" supply for ams-delta-serio device
and register it from the board file.
Modify the driver so it no longer requests and manipulates the
"keybrd_pwr" GPIO pin but a "vcc" regulator supply instead.
For this to work with Amstrad Delta, define a regulator over the
"keybrd_pwr" GPIO pin with the "vcc" supply for ams-delta-serio device
and register it from the board file.
From:
Adds debugfs access to registers in the Cannonlake PCH PMC that are
useful for debugging #SLP_S0 signal assertion and other low power
related activities. Device pm states are latched in these registers
whenever the package enters C10 and can be read from slp_s0_debug_status.
The pm states
From:
Adds debugfs access to registers in the Cannonlake PCH PMC that are
useful for debugging #SLP_S0 signal assertion and other low power
related activities. Device pm states are latched in these registers
whenever the package enters C10 and can be read from slp_s0_debug_status.
The pm states
On Thu, Jun 07, 2018 at 10:24:46PM +0200, Borislav Petkov wrote:
> tglx just took 1 and 3, 2/3 had a minor issue but the merge window
> happened so I'll send it later. It is nice to have anyway.
Did you fix up part 2/3? I see 1 & 3 were staged by Thomas in
TIP ras/urgent and ras-urgent-for-linus
On Thu, Jun 07, 2018 at 10:24:46PM +0200, Borislav Petkov wrote:
> tglx just took 1 and 3, 2/3 had a minor issue but the merge window
> happened so I'll send it later. It is nice to have anyway.
Did you fix up part 2/3? I see 1 & 3 were staged by Thomas in
TIP ras/urgent and ras-urgent-for-linus
From: Ilia Lin
The driver provides kernel level API for other drivers
to access the MSM8996 L2 cache registers.
Separating the L2 access code from the PMU driver and
making it public to allow other drivers use it.
The accesses must be separated with a single spinlock,
maintained in this driver.
From: Ilia Lin
The driver provides kernel level API for other drivers
to access the MSM8996 L2 cache registers.
Separating the L2 access code from the PMU driver and
making it public to allow other drivers use it.
The accesses must be separated with a single spinlock,
maintained in this driver.
From: Ilia Lin
Each of the CPU clusters (Power and Perf) on msm8996 are
clocked via 2 PLLs, a primary and alternate. There are also
2 Mux'es, a primary and secondary all connected together
as shown below
+---+
XO | |
From: Ilia Lin
Each of the CPU clusters (Power and Perf) on msm8996 are
clocked via 2 PLLs, a primary and alternate. There are also
2 Mux'es, a primary and secondary all connected together
as shown below
+---+
XO | |
From: Ilia Lin
Each of the CPU clusters (Power and Perf) on msm8996 are
clocked via 2 PLLs, a primary and alternate. There are also
2 Mux'es, a primary and secondary all connected together
as shown below
+---+
XO | |
From: Ilia Lin
Each of the CPU clusters (Power and Perf) on msm8996 are
clocked via 2 PLLs, a primary and alternate. There are also
2 Mux'es, a primary and secondary all connected together
as shown below
+---+
XO | |
From: Rajendra Nayak
The CPU clock controller's primary PLL operates on a single VCO range,
between 600MHz and 3GHz. However the CPUs do support OPPs with
frequencies between 300MHz and 600MHz. In order to support running the
CPUs at those frequencies we end up having to lock the PLL at twice
From: Rajendra Nayak
The CPU clock controller's primary PLL operates on a single VCO range,
between 600MHz and 3GHz. However the CPUs do support OPPs with
frequencies between 300MHz and 600MHz. In order to support running the
CPUs at those frequencies we end up having to lock the PLL at twice
On Mon, 2018-05-28 at 12:02 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Davidlohr Bueso
>
> [ Upstream commit d29a20645d5e929aa7e8616f28e5d8e1c49263ec ]
>
> While running rt-tests' pi_stress
From: Rajendra Nayak
Allow clk_alpha_pll_configure to be called from loadable
kernel modules.
Signed-off-by: Rajendra Nayak
Signed-off-by: Ilia Lin
Tested-by: Amit Kucheria
---
drivers/clk/qcom/clk-alpha-pll.c | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Ilia Lin
The PMUX for each duplex allows for selection of ACD clock source.
The DVM (Dynamic Variation Monitor) will flag an error
when a voltage droop event is detected. This flagged error
enables ACD to provide a div-by-2 clock, sourced from the primary PLL.
The duplex will be provided
From: Rajendra Nayak
Allow clk_alpha_pll_configure to be called from loadable
kernel modules.
Signed-off-by: Rajendra Nayak
Signed-off-by: Ilia Lin
Tested-by: Amit Kucheria
---
drivers/clk/qcom/clk-alpha-pll.c | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Ilia Lin
The PMUX for each duplex allows for selection of ACD clock source.
The DVM (Dynamic Variation Monitor) will flag an error
when a voltage droop event is detected. This flagged error
enables ACD to provide a div-by-2 clock, sourced from the primary PLL.
The duplex will be provided
On Mon, 2018-05-28 at 12:02 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Davidlohr Bueso
>
> [ Upstream commit d29a20645d5e929aa7e8616f28e5d8e1c49263ec ]
>
> While running rt-tests' pi_stress
101 - 200 of 1344 matches
Mail list logo
