From: Eugeniy Paltsev
[ Upstream commit 4e868f8419cb4cb558c5d428e7ab5629cef864c7 ]
| CC mm/nobootmem.o
|In file included from ./include/asm-generic/bug.h:18:0,
| from ./arch/arc/include/asm/bug.h:32,
| from ./include/linux/bug.h:5,
| from ./i
From: Eugeniy Paltsev
[ Upstream commit 4e868f8419cb4cb558c5d428e7ab5629cef864c7 ]
| CC mm/nobootmem.o
|In file included from ./include/asm-generic/bug.h:18:0,
| from ./arch/arc/include/asm/bug.h:32,
| from ./include/linux/bug.h:5,
| from ./i
From: Eugeniy Paltsev
[ Upstream commit 4e868f8419cb4cb558c5d428e7ab5629cef864c7 ]
| CC mm/nobootmem.o
|In file included from ./include/asm-generic/bug.h:18:0,
| from ./arch/arc/include/asm/bug.h:32,
| from ./include/linux/bug.h:5,
| from ./i
From: Eugeniy Paltsev
[ Upstream commit 4e868f8419cb4cb558c5d428e7ab5629cef864c7 ]
| CC mm/nobootmem.o
|In file included from ./include/asm-generic/bug.h:18:0,
| from ./arch/arc/include/asm/bug.h:32,
| from ./include/linux/bug.h:5,
| from ./i
From: Vineet Gupta
[ Upstream commit ab6c03676cb190156603cf4c5ecf97aa406c9c53 ]
and use smaller/on-stack buffer instead
The motivation for this change was lockdep splat like below.
| potentially unexpected fatal signal 11.
| BUG: sleeping function called from invalid context at ../mm/page_allo
From: Eugeniy Paltsev
[ Upstream commit 4e868f8419cb4cb558c5d428e7ab5629cef864c7 ]
| CC mm/nobootmem.o
|In file included from ./include/asm-generic/bug.h:18:0,
| from ./arch/arc/include/asm/bug.h:32,
| from ./include/linux/bug.h:5,
| from ./i
From: Vineet Gupta
[ Upstream commit ab6c03676cb190156603cf4c5ecf97aa406c9c53 ]
and use smaller/on-stack buffer instead
The motivation for this change was lockdep splat like below.
| potentially unexpected fatal signal 11.
| BUG: sleeping function called from invalid context at ../mm/page_allo
On 2/14/19 12:50 AM, Alexey Brodkin wrote:
> I suspect the slab allocator should be returning 8 byte aligned addresses
> on all systems
why ? As I understand it is still not fool proof against the expected
alignment of
inner members. There ought to be a better way
Handle U-boot arguments paranoidly:
* don't allow to pass unknown tag.
* try to use external device tree blob only if corresponding tag
(TAG_DTB) is set.
* don't check uboot_tag if kernel build with no ARC_UBOOT_SUPPORT.
NOTE:
If U-boot args are invalid we skip them and try to use embedded d
Reworking U-boot args handling and enable uboot support
unconditionally.
Changes v1->v2:
* Drop magic number check [in this patch series]
* Keep comment about cndline appending
Changes RFC->v1:
* Don't add new ABI contract between kernel and uboot
* Eliminate CONFIG_ARC_UBOOT_SUPPORT Kconfig
After reworking U-boot args handling code and adding paranoid
arguments check we can eliminate CONFIG_ARC_UBOOT_SUPPORT and
enable uboot support unconditionally.
For JTAG case we can assume that core registers will come up
reset value of 0 or in worst case we rely on user passing
'-on=clear_regs'
From: Peter Zijlstra
> Sent: 14 February 2019 11:08
> On Thu, Feb 14, 2019 at 10:44:49AM +, Alexey Brodkin wrote:
> > > On Wed, Feb 13, 2019 at 03:23:36PM -0800, Vineet Gupta wrote:
> > > > On 2/13/19 4:56 AM, Peter Zijlstra wrote:
> > > > >
> > > > > Personally I think u64 and company should a
On Thu, Feb 14, 2019 at 12:05:47PM +, Alexey Brodkin wrote:
> > > > So what happens if the data is then split across two cachelines; will a
> > > > STD vs LDD still be single-copy-atomic? I don't _think_ we rely on that
> > > > for > sizeof(unsigned long), with the obvious exception of atomic6
Hi Peter,
> -Original Message-
> From: linux-snps-arc On Behalf
> Of Peter Zijlstra
> Sent: Thursday, February 14, 2019 2:08 PM
> To: Alexey Brodkin
> Cc: Mark Rutland ; Vineet Gupta
> ; linux-
> ker...@vger.kernel.org; sta...@vger.kernel.org; David Laight
> ; Arnd Bergmann
> ; linux-
On Thu, Feb 14, 2019 at 10:44:49AM +, Alexey Brodkin wrote:
> > On Wed, Feb 13, 2019 at 03:23:36PM -0800, Vineet Gupta wrote:
> > > On 2/13/19 4:56 AM, Peter Zijlstra wrote:
> > > >
> > > > Personally I think u64 and company should already force natural
> > > > alignment; but alas.
> > >
> > >
Hi Peter,
> -Original Message-
> From: Peter Zijlstra
> Sent: Thursday, February 14, 2019 1:32 PM
> To: Vineet Gupta
> Cc: David Laight ; Alexey Brodkin
> ; linux-snps-
> a...@lists.infradead.org; Arnd Bergmann ;
> linux-ker...@vger.kernel.org;
> sta...@vger.kernel.org; Mark Rutland
>
On Wed, Feb 13, 2019 at 03:23:36PM -0800, Vineet Gupta wrote:
> On 2/13/19 4:56 AM, Peter Zijlstra wrote:
> >
> > Personally I think u64 and company should already force natural
> > alignment; but alas.
>
> But there is an ISA/ABI angle here too. e.g. On 32-bit ARC, LDD (load double)
> is
> allow
On Thu, Feb 14, 2019 at 08:50:43AM +, Alexey Brodkin wrote:
> But that's pretty much the same for other 32-bit arches that have 64-bit
> atomics
> like ARM etc. From what I may see from ARM's documentation for LDREXD/SRREXD
> they
> require double-word alignment of data as well.
>
> That sa
Hi Vineet, Peter, all,
> -Original Message-
> From: Vineet Gupta
> Sent: Thursday, February 14, 2019 2:24 AM
> To: Peter Zijlstra
> Cc: David Laight ; Alexey Brodkin
> ; linux-snps-
> a...@lists.infradead.org; Arnd Bergmann ;
> linux-ker...@vger.kernel.org;
> sta...@vger.kernel.org; Ma
19 matches
Mail list logo
