On Wed 2018-09-19 15:43:42, Chen Yu wrote:
> From: Zhimin Gu
>
> Update the in_suspend variable to reflect the actual hibernation
> status. Back-port from 64bit system.
>
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Zhimin Gu
> Signed-off-by: Chen Yu
Acked-by: Pavel Machek
On Wed 2018-09-19 15:43:42, Chen Yu wrote:
> From: Zhimin Gu
>
> Update the in_suspend variable to reflect the actual hibernation
> status. Back-port from 64bit system.
>
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Zhimin Gu
> Signed-off-by: Chen Yu
Acked-by: Pavel Machek
On Wed 2018-09-19 15:43:22, Chen Yu wrote:
> From: Zhimin Gu
>
> Set up the temporary text mapping for the final jump address
> so that the system could jump to the right address after all
> the pages have been copied back to their original address.
>
> Back-port from 64bit system.
>
> Cc:
On Wed 2018-09-19 15:43:22, Chen Yu wrote:
> From: Zhimin Gu
>
> Set up the temporary text mapping for the final jump address
> so that the system could jump to the right address after all
> the pages have been copied back to their original address.
>
> Back-port from 64bit system.
>
> Cc:
On Wed 2018-09-19 15:43:12, Chen Yu wrote:
> From: Zhimin Gu
>
> Code should be executed in a safe page during page
> restoring, as the page where instruction is running
> during resume might be scribbled and causes issues.
>
> Backport the code from 64 bit system to fix this bug.
On 32 bit,
On Wed 2018-09-19 15:43:12, Chen Yu wrote:
> From: Zhimin Gu
>
> Code should be executed in a safe page during page
> restoring, as the page where instruction is running
> during resume might be scribbled and causes issues.
>
> Backport the code from 64 bit system to fix this bug.
On 32 bit,
On Wed 2018-09-19 12:36:40, Rafael J. Wysocki wrote:
> On Wed, Sep 19, 2018 at 12:34 PM Ingo Molnar wrote:
> >
> >
> > * Rafael J. Wysocki wrote:
> >
> > > > index ..fbde8f0e8fe0
> > > > --- /dev/null
> > > > +++ b/arch/x86/power/hibernate.c
> > > > @@ -0,0 +1,249 @@
> > > > +//
On Wed 2018-09-19 12:36:40, Rafael J. Wysocki wrote:
> On Wed, Sep 19, 2018 at 12:34 PM Ingo Molnar wrote:
> >
> >
> > * Rafael J. Wysocki wrote:
> >
> > > > index ..fbde8f0e8fe0
> > > > --- /dev/null
> > > > +++ b/arch/x86/power/hibernate.c
> > > > @@ -0,0 +1,249 @@
> > > > +//
On Tue, 18 Sep 2018 16:24:51 +0200
Eric Auger wrote:
> From: Jacob Pan
>
> Device faults detected by IOMMU can be reported outside IOMMU
> subsystem for further processing. This patch intends to provide
> a generic device fault data such that device drivers can be
> communicated with IOMMU
On Tue, 18 Sep 2018 16:24:51 +0200
Eric Auger wrote:
> From: Jacob Pan
>
> Device faults detected by IOMMU can be reported outside IOMMU
> subsystem for further processing. This patch intends to provide
> a generic device fault data such that device drivers can be
> communicated with IOMMU
On Wed 2018-09-19 15:43:05, Chen Yu wrote:
> From: Zhimin Gu
>
> After all the pages are restored to previous address, the page
> table switches back to current swapper_pg_dir. However the
> swapper_pg_dir currently in used might not be consistent with
> previous page table, which might cause
On Wed 2018-09-19 15:42:57, Chen Yu wrote:
> From: Zhimin Gu
>
> Convert the hard code into PAGE_SIZE for better scalability.
>
> No functional change.
>
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Zhimin Gu
> Signed-off-by: Chen Yu
Acked-by: Pavel Machek
On Wed 2018-09-19 15:42:57, Chen Yu wrote:
> From: Zhimin Gu
>
> Convert the hard code into PAGE_SIZE for better scalability.
>
> No functional change.
>
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Zhimin Gu
> Signed-off-by: Chen Yu
Acked-by: Pavel Machek
On Wed 2018-09-19 15:43:05, Chen Yu wrote:
> From: Zhimin Gu
>
> After all the pages are restored to previous address, the page
> table switches back to current swapper_pg_dir. However the
> swapper_pg_dir currently in used might not be consistent with
> previous page table, which might cause
On Wed 2018-09-19 15:38:17, Chen Yu wrote:
> Currently if get_e820_md5() fails, then it will hibernate nevertheless.
> Actually the error code should be propagated to upper caller so that
> the hibernation could be aware of the result and terminates the process
> if md5 digest fails.
>
>
On Wed 2018-09-19 15:37:15, Chen Yu wrote:
> From: Zhimin Gu
>
> On 32bit systems, nosave_regions(non RAM areas) located between
> max_low_pfn and max_pfn are not excluded from hibernation snapshot
> currently, which may result in a machine check exception when
> trying to access these unsafe
On Wed 2018-09-19 15:42:48, Chen Yu wrote:
> From: Zhimin Gu
>
> This is to reuse the temp_pgt for both 32bit and 64bit
> system.
>
> No functional change.
>
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Zhimin Gu
> Signed-off-by: Chen Yu
Acked-by: Pavel Machek
On Wed 2018-09-19 15:38:17, Chen Yu wrote:
> Currently if get_e820_md5() fails, then it will hibernate nevertheless.
> Actually the error code should be propagated to upper caller so that
> the hibernation could be aware of the result and terminates the process
> if md5 digest fails.
>
>
On Wed 2018-09-19 15:37:15, Chen Yu wrote:
> From: Zhimin Gu
>
> On 32bit systems, nosave_regions(non RAM areas) located between
> max_low_pfn and max_pfn are not excluded from hibernation snapshot
> currently, which may result in a machine check exception when
> trying to access these unsafe
On Wed 2018-09-19 15:42:48, Chen Yu wrote:
> From: Zhimin Gu
>
> This is to reuse the temp_pgt for both 32bit and 64bit
> system.
>
> No functional change.
>
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Zhimin Gu
> Signed-off-by: Chen Yu
Acked-by: Pavel Machek
On Wed 2018-09-19 15:42:39, Chen Yu wrote:
> From: Zhimin Gu
>
> As 32bit system is not using 4-level page, rename it
> to temp_pgt so that it can be reused for both 32bit
> and 64bit hibernation.
>
> No functional change.
>
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Zhimin Gu
>
On Wed 2018-09-19 15:42:39, Chen Yu wrote:
> From: Zhimin Gu
>
> As 32bit system is not using 4-level page, rename it
> to temp_pgt so that it can be reused for both 32bit
> and 64bit hibernation.
>
> No functional change.
>
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Zhimin Gu
>
Hi!
> >>> Easy to maintain will be a dedicated LED class driver.
> >>
> >> You mean, 3 dedicated LED class drivers and 3 MFD drivers with LED
> >> parts? We'll need complex driver anyway, and I'd really like to have
> >> just one.
> >
> > In the LED subsystem we can wrap common functionalities
>
Hi!
> > > +#ifdef CONFIG_ATA_LEDS
> > > + /* register LED triggers for all ports */
> > > + for (i = 0; i < host->n_ports; i++) {
> > > + if (unlikely(!host->ports[i]->ledtrig))
> > > + continue;
> > > +
> > > + snprintf(host->ports[i]->ledtrig_name,
> > > +
Hi!
> >>> Easy to maintain will be a dedicated LED class driver.
> >>
> >> You mean, 3 dedicated LED class drivers and 3 MFD drivers with LED
> >> parts? We'll need complex driver anyway, and I'd really like to have
> >> just one.
> >
> > In the LED subsystem we can wrap common functionalities
>
Hi!
> > > +#ifdef CONFIG_ATA_LEDS
> > > + /* register LED triggers for all ports */
> > > + for (i = 0; i < host->n_ports; i++) {
> > > + if (unlikely(!host->ports[i]->ledtrig))
> > > + continue;
> > > +
> > > + snprintf(host->ports[i]->ledtrig_name,
> > > +
On Tue 2018-08-07 10:33:26, Marc Zyngier wrote:
> It recently came to light that userspace can execute WFI, and that
> the arm64 kernel doesn trap this event. This sounds rather benign,
> but the kernel should decide when it wants to wait for an interrupt,
> and not userspace.
>
> Let's trap WFI
On Tue 2018-08-07 10:33:26, Marc Zyngier wrote:
> It recently came to light that userspace can execute WFI, and that
> the arm64 kernel doesn trap this event. This sounds rather benign,
> but the kernel should decide when it wants to wait for an interrupt,
> and not userspace.
>
> Let's trap WFI
On Wed, Sep 12, 2018 at 6:54 AM Suzuki K Poulose wrote:
> Switch to the new coresight bindings
>
> Cc: Linus Walleij
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
Applied to the ux500 tree.
Yours,
Linus Walleij
On Wed, Sep 12, 2018 at 6:54 AM Suzuki K Poulose wrote:
> Switch to the new coresight bindings
>
> Cc: Linus Walleij
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
Applied to the ux500 tree.
Yours,
Linus Walleij
* Suzuki K Poulose [180912 06:58]:
> Switch to the new coresight bindings for hardware ports
>
> Cc: linux-o...@vger.kernel.org
> Cc: "Benoît Cousson"
> Cc: Tony Lindgren
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> arch/arm/boot/dts/omap3-beagle-xm.dts | 17
* Suzuki K Poulose [180912 06:58]:
> Switch to the new coresight bindings for hardware ports
>
> Cc: linux-o...@vger.kernel.org
> Cc: "Benoît Cousson"
> Cc: Tony Lindgren
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> arch/arm/boot/dts/omap3-beagle-xm.dts | 17
On 09/19/2018 04:35 PM, Tim Chen wrote:
> This patchset provides an option to apply IBPB and STIBP mitigation
> to only non-dumpable processes.
>
> Jiri's patch to harden spectre_v2 makes IBPB and STIBP available for
> general spectre v2 app to app mitigation. IBPB will be issued for
> switching
On 09/20/2018 02:33 PM, Ard Biesheuvel wrote:
> On 20 September 2018 at 14:31, Florian Fainelli wrote:
>> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
>>> On 20 September 2018 at 13:55, Florian Fainelli
>>> wrote:
On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
> On 19 September 2018 at
On 09/19/2018 04:35 PM, Tim Chen wrote:
> This patchset provides an option to apply IBPB and STIBP mitigation
> to only non-dumpable processes.
>
> Jiri's patch to harden spectre_v2 makes IBPB and STIBP available for
> general spectre v2 app to app mitigation. IBPB will be issued for
> switching
On 09/20/2018 02:33 PM, Ard Biesheuvel wrote:
> On 20 September 2018 at 14:31, Florian Fainelli wrote:
>> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
>>> On 20 September 2018 at 13:55, Florian Fainelli
>>> wrote:
On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
> On 19 September 2018 at
On Thu, Sep 13, 2018 at 04:05:54PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Aug 29, 2018 at 11:04:08AM +0800, Jisheng Zhang wrote:
> > When programming inbound/outbound atu, we call usleep_range() after
> > each checking PCIE_ATU_ENABLE bit. Unfortunately, the atu programming
> > can be called in
On Thu, Sep 13, 2018 at 04:05:54PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Aug 29, 2018 at 11:04:08AM +0800, Jisheng Zhang wrote:
> > When programming inbound/outbound atu, we call usleep_range() after
> > each checking PCIE_ATU_ENABLE bit. Unfortunately, the atu programming
> > can be called in
On Wed, Sep 12, 2018 at 10:23 PM Dan Williams wrote:
>
> The UIO file mask in MAINTAINERS was incorrectly directing UACCESS
> (include/linux/uio.h) patches to Greg.
>
> Tag Al as the UACCESS maintainer as Ingo and others have explicitly
> required his ack before taking architecture patches that
On Wed, Sep 12, 2018 at 10:23 PM Dan Williams wrote:
>
> The UIO file mask in MAINTAINERS was incorrectly directing UACCESS
> (include/linux/uio.h) patches to Greg.
>
> Tag Al as the UACCESS maintainer as Ingo and others have explicitly
> required his ack before taking architecture patches that
On 20 September 2018 at 14:31, Florian Fainelli wrote:
> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
>> On 20 September 2018 at 13:55, Florian Fainelli wrote:
>>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
On 19 September 2018 at 07:31, Jim Quinlan wrote:
> The Broadcom STB PCIe
On 20 September 2018 at 14:31, Florian Fainelli wrote:
> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
>> On 20 September 2018 at 13:55, Florian Fainelli wrote:
>>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
On 19 September 2018 at 07:31, Jim Quinlan wrote:
> The Broadcom STB PCIe
On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
> On 20 September 2018 at 13:55, Florian Fainelli wrote:
>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
>>> On 19 September 2018 at 07:31, Jim Quinlan wrote:
The Broadcom STB PCIe host controller is intimately related to the
memory
On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
> On 20 September 2018 at 13:55, Florian Fainelli wrote:
>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
>>> On 19 September 2018 at 07:31, Jim Quinlan wrote:
The Broadcom STB PCIe host controller is intimately related to the
memory
On Thu, Sep 20, 2018 at 10:23 PM, Souptick Joarder wrote:
> There is a plan to remove vm_insert_page permanently
> and replace it with new API vmf_insert_page which will
> return vm_fault_t type. As part of it vm_insert_page
> is removed from this driver.
A link to the discussion/plan would be
On Thu, Sep 20, 2018 at 10:23 PM, Souptick Joarder wrote:
> There is a plan to remove vm_insert_page permanently
> and replace it with new API vmf_insert_page which will
> return vm_fault_t type. As part of it vm_insert_page
> is removed from this driver.
A link to the discussion/plan would be
* Janusz Krzysztofik [180910 12:53]:
> GPIOs with no kernel drivers can still be used from user space, don't
> request them from the board file.
>
> Signed-off-by: Janusz Krzysztofik
Thanks applying into omap-for-v4.20/omap1.
Regards,
Tony
* Janusz Krzysztofik [180910 12:53]:
> GPIOs with no kernel drivers can still be used from user space, don't
> request them from the board file.
>
> Signed-off-by: Janusz Krzysztofik
Thanks applying into omap-for-v4.20/omap1.
Regards,
Tony
* Janusz Krzysztofik [180910 10:50]:
> Instead of defining symbols already defined in
> linux/platform_data/gpio-omap.h, use that header file.
>
> Since we include the header into an assembler code, prevent C only bits
> from being read in.
>
> Signed-off-by: Janusz Krzysztofik
Thanks
* Janusz Krzysztofik [180910 10:50]:
> Instead of defining symbols already defined in
> linux/platform_data/gpio-omap.h, use that header file.
>
> Since we include the header into an assembler code, prevent C only bits
> from being read in.
>
> Signed-off-by: Janusz Krzysztofik
Thanks
* Janusz Krzysztofik [180910 21:52]:
> On Monday, September 10, 2018 1:44:16 AM CEST Janusz Krzysztofik wrote:
> >
> > Convert modem related GPIO setup from integer space to GPIO descriptors.
> > Also, restore original initialization order of the MODEM device and its
> > related GPIO pins.
> >
* Janusz Krzysztofik [180910 21:52]:
> On Monday, September 10, 2018 1:44:16 AM CEST Janusz Krzysztofik wrote:
> >
> > Convert modem related GPIO setup from integer space to GPIO descriptors.
> > Also, restore original initialization order of the MODEM device and its
> > related GPIO pins.
> >
Commit-ID: 05ab1d8a4b36ee912b7087c6da127439ed0a903e
Gitweb: https://git.kernel.org/tip/05ab1d8a4b36ee912b7087c6da127439ed0a903e
Author: Feng Tang
AuthorDate: Thu, 20 Sep 2018 10:58:28 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 20 Sep 2018 23:17:22 +0200
x86/mm: Expand static
Commit-ID: 05ab1d8a4b36ee912b7087c6da127439ed0a903e
Gitweb: https://git.kernel.org/tip/05ab1d8a4b36ee912b7087c6da127439ed0a903e
Author: Feng Tang
AuthorDate: Thu, 20 Sep 2018 10:58:28 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 20 Sep 2018 23:17:22 +0200
x86/mm: Expand static
From: Long Li
With direct I/O read, we transfer the data directly from transport layer to
the user data buffer.
Change in v3: add support for kernel AIO
Signed-off-by: Long Li
---
fs/cifs/cifsfs.h | 1 +
fs/cifs/cifsglob.h | 5 ++
fs/cifs/file.c | 210
From: Long Li
With direct I/O read, we transfer the data directly from transport layer to
the user data buffer.
Change in v3: add support for kernel AIO
Signed-off-by: Long Li
---
fs/cifs/cifsfs.h | 1 +
fs/cifs/cifsglob.h | 5 ++
fs/cifs/file.c | 210
From: Long Li
With direct I/O write, user supplied buffers are pinned to the memory and data
are transferred directly from user buffers to the transport layer.
Change in v3: add support for kernel AIO
Signed-off-by: Long Li
---
fs/cifs/cifsfs.h | 1 +
fs/cifs/file.c | 196
From: Long Li
It is not necessary to deregister a memory registration after it has been
successfully invalidated.
Signed-off-by: Long Li
---
fs/cifs/smbdirect.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/fs/cifs/smbdirect.c
From: Long Li
With direct read/write functions implemented, add them to file_operations.
Dircet I/O is used under two conditions:
1. When mounting with "cache=none", CIFS uses direct I/O for all user file
data transfer.
2. When opening a file with O_DIRECT, CIFS uses direct I/O for all data
From: Long Li
With direct I/O write, user supplied buffers are pinned to the memory and data
are transferred directly from user buffers to the transport layer.
Change in v3: add support for kernel AIO
Signed-off-by: Long Li
---
fs/cifs/cifsfs.h | 1 +
fs/cifs/file.c | 196
From: Long Li
With direct read/write functions implemented, add them to file_operations.
Dircet I/O is used under two conditions:
1. When mounting with "cache=none", CIFS uses direct I/O for all user file
data transfer.
2. When opening a file with O_DIRECT, CIFS uses direct I/O for all data
From: Long Li
It is not necessary to deregister a memory registration after it has been
successfully invalidated.
Signed-off-by: Long Li
---
fs/cifs/smbdirect.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/fs/cifs/smbdirect.c
From: Long Li
When issuing SMB1 read/write, pass the page offset to transport.
Signed-off-by: Long Li
---
fs/cifs/cifssmb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index 41329f4..f82fd34 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
From: Long Li
When issuing SMB1 read/write, pass the page offset to transport.
Signed-off-by: Long Li
---
fs/cifs/cifssmb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index 41329f4..f82fd34 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
The CoC is extremely ambiguously written for an enforceable document, any
behavior disliked by the maintainers can be punished, and the level of
naivete of the maintainers defending it is suprising for such a far reaching
document.
> In the interest of fostering an open and welcoming environment,
The CoC is extremely ambiguously written for an enforceable document, any
behavior disliked by the maintainers can be punished, and the level of
naivete of the maintainers defending it is suprising for such a far reaching
document.
> In the interest of fostering an open and welcoming environment,
mmit:a0cb0cabe4bb Add linux-next specific files for 20180920
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1513972140
> > kernel config: https://syzkaller.appspot.com/x/.config?x=786006c5dafbadf6
> > dashboard link
mmit:a0cb0cabe4bb Add linux-next specific files for 20180920
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1513972140
> > kernel config: https://syzkaller.appspot.com/x/.config?x=786006c5dafbadf6
> > dashboard link
Thanks. Let's cc the ashmem folks.
On Thu, 20 Sep 2018 14:04:05 -0700 syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:a0cb0cabe4bb Add linux-next specific files for 20180920
> git tree: linux-next
> console output: https://sy
Thanks. Let's cc the ashmem folks.
On Thu, 20 Sep 2018 14:04:05 -0700 syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:a0cb0cabe4bb Add linux-next specific files for 20180920
> git tree: linux-next
> console output: https://sy
On 9/20/2018 4:55 PM, Thomas Gleixner wrote:
On Mon, 10 Sep 2018, Masayoshi Mizuma wrote:
CC+ Kan
From: Masayoshi Mizuma
Physical package id 0 is not always exists. We should use
boot_cpu_data.phys_proc_id here.
Signed-off-by: Masayoshi Mizuma
---
arch/x86/events/intel/uncore_snbep.c
On 9/20/2018 4:55 PM, Thomas Gleixner wrote:
On Mon, 10 Sep 2018, Masayoshi Mizuma wrote:
CC+ Kan
From: Masayoshi Mizuma
Physical package id 0 is not always exists. We should use
boot_cpu_data.phys_proc_id here.
Signed-off-by: Masayoshi Mizuma
---
arch/x86/events/intel/uncore_snbep.c
On 9/20/18, 8:46 AM, "Linus Walleij" wrote:
> Actually this is much more intuitive too, it is the typical way to handle
> a down-counting timer. Good catch!
> Reviewed-by: Linus Walleij
Thank you Linus for the quick review!
> Sorry for any cargo-cult programming on my part :/
> Would be
On 9/20/18, 8:46 AM, "Linus Walleij" wrote:
> Actually this is much more intuitive too, it is the typical way to handle
> a down-counting timer. Good catch!
> Reviewed-by: Linus Walleij
Thank you Linus for the quick review!
> Sorry for any cargo-cult programming on my part :/
> Would be
The mm-of-the-moment snapshot 2018-09-20-14-08 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-09-20-14-08 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 20 September 2018 at 13:55, Florian Fainelli wrote:
> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
>> On 19 September 2018 at 07:31, Jim Quinlan wrote:
>>> The Broadcom STB PCIe host controller is intimately related to the
>>> memory subsystem. This close relationship adds complexity to how
On 20 September 2018 at 13:55, Florian Fainelli wrote:
> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
>> On 19 September 2018 at 07:31, Jim Quinlan wrote:
>>> The Broadcom STB PCIe host controller is intimately related to the
>>> memory subsystem. This close relationship adds complexity to how
Hello,
syzbot found the following crash on:
HEAD commit:a0cb0cabe4bb Add linux-next specific files for 20180920
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1513972140
kernel config: https://syzkaller.appspot.com/x/.config?x=786006c5dafbadf6
Hello,
syzbot found the following crash on:
HEAD commit:42a037ca8d9d kmsan: update README.md to reference LLVM r34..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=1392c14940
kernel config:
Hello,
syzbot found the following crash on:
HEAD commit:a0cb0cabe4bb Add linux-next specific files for 20180920
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1513972140
kernel config: https://syzkaller.appspot.com/x/.config?x=786006c5dafbadf6
Hello,
syzbot found the following crash on:
HEAD commit:42a037ca8d9d kmsan: update README.md to reference LLVM r34..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=1392c14940
kernel config:
On Thu, Sep 20, 2018 at 1:45 PM Matthew Whitehead wrote:
>
> On power up, the cpuid instruction is disabled on Cyrix 6x86 and 6x86L
> processors and it needs to be enabled. There is code to do this, but it
> does not work because it uses the broken {set,get}Cx86_old() macros.
>
> There are
On Thu, Sep 20, 2018 at 1:45 PM Matthew Whitehead wrote:
>
> On power up, the cpuid instruction is disabled on Cyrix 6x86 and 6x86L
> processors and it needs to be enabled. There is code to do this, but it
> does not work because it uses the broken {set,get}Cx86_old() macros.
>
> There are
On 9/19/18 6:08 AM, Oscar Salvador wrote:
> From: Oscar Salvador
>
> Currently, when !CONFIG_HIGHMEM, status_change_nid_high is being set
> to status_change_nid_normal, but on such systems N_HIGH_MEMORY falls
> back to N_NORMAL_MEMORY.
> That means that if status_change_nid_normal is not -1,
>
On 9/19/18 6:08 AM, Oscar Salvador wrote:
> From: Oscar Salvador
>
> Currently, when !CONFIG_HIGHMEM, status_change_nid_high is being set
> to status_change_nid_normal, but on such systems N_HIGH_MEMORY falls
> back to N_NORMAL_MEMORY.
> That means that if status_change_nid_normal is not -1,
>
On Mon, 10 Sep 2018, Masayoshi Mizuma wrote:
CC+ Kan
> From: Masayoshi Mizuma
>
> Physical package id 0 is not always exists. We should use
> boot_cpu_data.phys_proc_id here.
>
> Signed-off-by: Masayoshi Mizuma
> ---
> arch/x86/events/intel/uncore_snbep.c | 2 +-
> 1 file changed, 1
Clang warns when multiple pairs of parentheses are used for a single
conditional statement.
drivers/scsi/arcmsr/arcmsr_hba.c:4138:19: warning: equality comparison
with extraneous parentheses [-Wparentheses-equality]
if ((acb->dev_id == 0x1680)) {
^
On Mon, 10 Sep 2018, Masayoshi Mizuma wrote:
CC+ Kan
> From: Masayoshi Mizuma
>
> Physical package id 0 is not always exists. We should use
> boot_cpu_data.phys_proc_id here.
>
> Signed-off-by: Masayoshi Mizuma
> ---
> arch/x86/events/intel/uncore_snbep.c | 2 +-
> 1 file changed, 1
Clang warns when multiple pairs of parentheses are used for a single
conditional statement.
drivers/scsi/arcmsr/arcmsr_hba.c:4138:19: warning: equality comparison
with extraneous parentheses [-Wparentheses-equality]
if ((acb->dev_id == 0x1680)) {
^
On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
> On 19 September 2018 at 07:31, Jim Quinlan wrote:
>> The Broadcom STB PCIe host controller is intimately related to the
>> memory subsystem. This close relationship adds complexity to how cpu
>> system memory is mapped to PCIe memory. Ideally,
On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
> On 19 September 2018 at 07:31, Jim Quinlan wrote:
>> The Broadcom STB PCIe host controller is intimately related to the
>> memory subsystem. This close relationship adds complexity to how cpu
>> system memory is mapped to PCIe memory. Ideally,
On 9/19/18 6:08 AM, Oscar Salvador wrote:
> From: Oscar Salvador
>
> In node_states_check_changes_online, we check if the node will
> have to be set for any of the N_*_MEMORY states after the pages
> have been onlined.
>
> Later on, we perform the activation in node_states_set_node.
>
Hello,
On Thu, Sep 20, 2018 at 06:18:21PM +0800, Jianchao Wang wrote:
> -static inline void percpu_ref_get_many(struct percpu_ref *ref, unsigned long
> nr)
> +static inline void __percpu_ref_get_many(struct percpu_ref *ref, unsigned
> long nr)
> {
> unsigned long __percpu *percpu_count;
On 9/19/18 6:08 AM, Oscar Salvador wrote:
> From: Oscar Salvador
>
> In node_states_check_changes_online, we check if the node will
> have to be set for any of the N_*_MEMORY states after the pages
> have been onlined.
>
> Later on, we perform the activation in node_states_set_node.
>
Hello,
On Thu, Sep 20, 2018 at 06:18:21PM +0800, Jianchao Wang wrote:
> -static inline void percpu_ref_get_many(struct percpu_ref *ref, unsigned long
> nr)
> +static inline void __percpu_ref_get_many(struct percpu_ref *ref, unsigned
> long nr)
> {
> unsigned long __percpu *percpu_count;
On power up, the cpuid instruction is disabled on Cyrix 6x86 and 6x86L
processors and it needs to be enabled. There is code to do this, but it
does not work because it uses the broken {set,get}Cx86_old() macros.
There are comments in processor-cyrix.h advising you to _not_ make calls
using the
On power up, the cpuid instruction is disabled on Cyrix 6x86 and 6x86L
processors and it needs to be enabled. There is code to do this, but it
does not work because it uses the broken {set,get}Cx86_old() macros.
There are comments in processor-cyrix.h advising you to _not_ make calls
using the
On 21/09/18 03:57, Gregory CLEMENT wrote:
> Hi Chris,
>
> On jeu., juil. 26 2018, Chris Packham
> wrote:
>
>> This series updates the armada-xp-98dx3236 SoC and related boards to use the
>> new style dts bindings for nand.
>>
>> I've also added a new db-88f6820-amc board which is an
On 21/09/18 03:57, Gregory CLEMENT wrote:
> Hi Chris,
>
> On jeu., juil. 26 2018, Chris Packham
> wrote:
>
>> This series updates the armada-xp-98dx3236 SoC and related boards to use the
>> new style dts bindings for nand.
>>
>> I've also added a new db-88f6820-amc board which is an
201 - 300 of 1302 matches
Mail list logo
