On Mon, Apr 23, 2018 at 2:59 PM, Mahesh J Salgaonkar
wrote:
> From: Mahesh Salgaonkar
>
> The current code extracts the physical address for UE errors and then
> hooks it up into memory failure infrastructure. On successful extraction
> of physical address it wrongly sets "handled = 1" which mean
On Tue, Apr 17, 2018 at 04:33:14PM +0200, Laurent Dufour wrote:
> From: Peter Zijlstra
>
> Wrap the VMA modifications (vma_adjust/unmap_page_range) with sequence
> counts such that we can easily test if a VMA is changed.
So, seqcount is to protect modifying all attributes of vma?
>
> The unmap
On Tue, Apr 17, 2018 at 04:33:12PM +0200, Laurent Dufour wrote:
> pte_unmap_same() is making the assumption that the page table are still
> around because the mmap_sem is held.
> This is no more the case when running a speculative page fault and
> additional check must be made to ensure that the fi
Hi Laurent,
I guess it's good timing to review. Guess LSF/MM goes so might change
a lot since then. :) Anyway, I grap a time to review.
On Tue, Apr 17, 2018 at 04:33:07PM +0200, Laurent Dufour wrote:
> This configuration variable will be used to build the code needed to
> handle speculative page
On 04/22/2018 07:28 AM, Nicholas Piggin wrote:
> On Fri, 20 Apr 2018 10:34:35 +0530
> Mahesh J Salgaonkar wrote:
>
>> From: Mahesh Salgaonkar
>>
>> otherwise the fadump registration in new kexec-ed kernel complains that
>> fadump is already registered. This makes new kernel to continue using
>>
On 04/22/2018 07:28 AM, Nicholas Piggin wrote:
> On Fri, 20 Apr 2018 10:34:18 +0530
> Mahesh J Salgaonkar wrote:
>
>> From: Mahesh Salgaonkar
>>
>> Currently the metadata region that holds crash info structure and ELF core
>> header is placed towards the end of reserved memory area. This patch p
From: Mahesh Salgaonkar
The current code extracts the physical address for UE errors and then
hooks it up into memory failure infrastructure. On successful extraction
of physical address it wrongly sets "handled = 1" which means this UE error
has been recovered. Since MCE handler gets return valu
From: Thomas Falcon
Date: Fri, 20 Apr 2018 14:25:32 -0500
> Avoid using value stored in the login response buffer when
> cleaning TX and RX buffer pools since these could be inconsistent
> depending on the device state. Instead use the field in the driver's
> private data that tracks the number o
On Fri, Apr 20, 2018 at 7:38 AM, Arnd Bergmann wrote:
> On Fri, Apr 20, 2018 at 3:53 PM, Jeffrey Walton wrote:
>>> +#if !defined(__x86_64__) || !defined(__ilp32__)
>>> #include
>>> +#else
>>
>> I understand there's some progress having Clang compile the kernel.
>> Clang treats __ILP32__ and fri
On Sun, Apr 22, 2018 at 2:38 PM, H.J. Lu wrote:
> On Fri, Apr 20, 2018 at 7:38 AM, Arnd Bergmann wrote:
>> On Fri, Apr 20, 2018 at 3:53 PM, Jeffrey Walton wrote:
>
> Glibc has correct header files for system calls. I have a very old
> program to check if Linux kernel header files are correct fo
On Sun, Apr 22, 2018 at 11:14:08AM +0200, Wolfram Sang wrote:
> I got tired of fixing this in Renesas drivers manually, so I took the big
> hammer. Remove this cumbersome code pattern which got copy-pasted too much
> already:
>
> - struct platform_device *pdev = to_platform_device(dev);
> -
On Sun, Apr 22, 2018 at 11:47:33AM +0530, Vinod Koul wrote:
> On Thu, Apr 19, 2018 at 04:05:37PM +0200, Wolfram Sang wrote:
> > We should get drvdata from struct device directly. Going via
> > platform_device is an unneeded step back and forth.
>
> Do you mind splitting this per driver please, tha
I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+ s
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply to your tree directly.
drivers/dma/fsldma.c | 6 ++
1 file changed, 2 insertions(+), 4 deletio
14 matches
Mail list logo
