On 06/29/2018 02:12 PM, Vineet Gupta wrote:
> On 06/29/2018 01:57 PM, Mike Rapoport wrote:
>> I think that would be something like this:
>> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
>> index e81bcd271be7..44a20141639a 100644
>> --- a/arch/arc/Kconfig
>> +++ b/arch/arc/Kconfig
>> @@ -556,12 +
On 06/29/2018 01:57 PM, Mike Rapoport wrote:
> I think that would be something like this:
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index e81bcd271be7..44a20141639a 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -556,12 +556,14 @@ endmenu
>
> endmenu # "ARC Archit
On 06/29/2018 06:42 AM, Mike Rapoport wrote:
> Otherwise mm configuration options show up in the top level menu.
>
> Signed-off-by: Mike Rapoport
>
LGTM ! Added to for-curr
Thx,
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.o
We process signals in the end of syscall/exception handler.
It the signal is fatal we print register's content using
show_regs function. show_regs() also prints information about
last exception happened.
In case of multicore system we can catch the situation when we
will print wrong information ab
This was triggered by investigation of a deadlock after OOM killer invocation,
see [1] for more details.
Looks like our handling of fatal signal in do_page_fault() has some issues:
1. We only want to do special (read "early") handling of fatal signal
if handle_mm_fault() returned VM_FAULT_RETR
On 06/28/2018 07:14 AM, Eugeniy Paltsev wrote:
> The ARC HS processor provides an IOC port (I/O coherency bus
> interface) that allows external devices such as DMA devices
> to access memory through the cache hierarchy, providing
> coherency between I/O transactions and the complete memory
> hierar
On Thu, Jun 28, 2018 at 05:14:52PM +0300, Eugeniy Paltsev wrote:
> And if we get DMA buffer from ZONE_HIGHMEM memory we need to
> do real flush/invalidate operations on that buffer, which is obviously
> not done by "dma_direct_ops".
>
> So I am not sure about "dma_direct_ops" using - probably we n
