On 11/12/2019 11:59 AM, Ingo Molnar wrote:
>
> * Anshuman Khandual wrote:
>
>> +config DEBUG_VM_PGTABLE
>> +bool "Debug arch page table for semantics compliance"
>> +depends on MMU
>> +depends on DEBUG_VM
>> +depends on ARCH_HAS_DEBUG_VM_PGTABLE
>> +help
>> + This
* Anshuman Khandual wrote:
> +config DEBUG_VM_PGTABLE
> + bool "Debug arch page table for semantics compliance"
> + depends on MMU
> + depends on DEBUG_VM
> + depends on ARCH_HAS_DEBUG_VM_PGTABLE
> + help
> + This option provides a debug method which can be used to
This adds tests which will validate architecture page table helpers and
other accessors in their compliance with expected generic MM semantics.
This will help various architectures in validating changes to existing
page table helpers or addition of new ones.
This test covers basic page table
On (19/11/12 13:44), Sergey Senozhatsky wrote:
[..]
> > But yes, this per-code-section loglevel is problematic. The feedback
> > against the patchset shows that people want it also the other way.
> > I mean to keep pr_debug() as pr_debug().
>
> Hmm. Right.
>
> > A solution might be to use the
On (19/11/11 10:12), Petr Mladek wrote:
[..]
> > I do recall that we talked about per-CPU printk state bit which would
> > start/end "just print it" section. We probably can extend it to "just
> > log_store" type of functionality. Doesn't look like a very bad idea.
>
> The problem with per-CPU
On 11/12/2019 09:48 AM, Anshuman Khandual wrote:
> This adds tests which will validate architecture page table helpers and
> other accessors in their compliance with expected generic MM semantics.
> This will help various architectures in validating changes to existing
> page table helpers or
On (19/11/12 02:40), Dmitry Safonov wrote:
[..]
> In my point of view the cost of one-time [mostly build] testing every
> architecture is cheaper than introducing some new smart code that will
> live forever.
Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
on that
This adds tests which will validate architecture page table helpers and
other accessors in their compliance with expected generic MM semantics.
This will help various architectures in validating changes to existing
page table helpers or addition of new ones.
This test covers basic page table
Hi Sergey,
On 11/12/19 2:17 AM, Sergey Senozhatsky wrote:
> On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
>> What I'm going to do - is to fix all build and reported issues, I'll
>> send v2 this week and feel free to NAK it, I will forget about those
>> patches and won't be offended.
>
>
On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
> I don't see how bits on task_struct or in per-cpu are easier than
> supplying a log level parameter down the stack.
> How would it work if sysrq_handle_crash() called by key-press?
> How would that interact with deferred printing?
> How would it
On 11/11/19 2:33 PM, Joseph Myers wrote:
> On Mon, 11 Nov 2019, Vineet Gupta wrote:
>
>> Functionally it should not result in code gen changes and if at all
>> those would be better since the scope of those temporaries is greatly
>> reduced now
> This feels like the sort of thing where "should not
On Mon, 11 Nov 2019, Vineet Gupta wrote:
> Functionally it should not result in code gen changes and if at all
> those would be better since the scope of those temporaries is greatly
> reduced now
This feels like the sort of thing where "should not result in code gen
changes" should be tested
Hi Yann,
On 11/11/19 1:09 PM, Yann E. MORIN wrote:
>
>>> This re-use of an existing name is a bit annoying. Indeed, all existing
>>> users of Buildroot that have a configuration with BR2_archs38 will now
>>> be building for a ARC system with a 64-bit multiplier, while they were
>>> previously
Vineet, All,
On 2019-11-11 18:47 +, Vineet Gupta spake thusly:
> On 11/9/19 5:46 AM, Thomas Petazzoni wrote:
> > On Fri, 8 Nov 2019 09:41:10 -0800
> > Vineet Gupta wrote:
> >> Signed-off-by: Vineet Gupta
> >> ---
> >> arch/Config.in.arc | 21 ++---
> >> 1 file changed, 14
Hi Sergey, Petr,
On 11/11/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
>> I agree that it is complicated to pass the loglevel as
>> a parameter. It would be better define the default
>> log level for a given code section. It might be stored
>> in
This came to light when adding hard-flaot support to ARC glibc port
without hardware sqrt support causing glibc build to fail:
| ../sysdeps/ieee754/dbl-64/e_sqrt.c: In function '__ieee754_sqrt':
| ../sysdeps/ieee754/dbl-64/e_sqrt.c:58:54: error: unused variable 'ty'
[-Werror=unused-variable]
|
On Mon, Nov 11, 2019 at 11:29 AM Christoph Hellwig wrote:
>
> On Mon, Nov 11, 2019 at 11:27:27AM +0100, Arnd Bergmann wrote:
> > Ok, fair enough. Let's just go with your version for now, if only to not
> > hold your series up more. I'd still suggest we change atyfb to only
> > use ioremap_uc() on
On 11/7/19 8:27 PM, Anshuman Khandual wrote:
>
> On 11/08/2019 12:35 AM, Vineet Gupta wrote:
>> On 11/6/19 8:44 PM, Anshuman Khandual wrote:
> */
> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE
> #include
> #endif
This in wrong.
Hi Thomas,
On 11/9/19 5:46 AM, Thomas Petazzoni wrote:
> Hello,
>
> +Arnout for legacy handling.
>
> On Fri, 8 Nov 2019 09:41:10 -0800
> Vineet Gupta wrote:
>
>> This corresponds to -mcu=hs38 with mpy-option=9 (64-bit multiplier)
>>
>> Signed-off-by: Vineet Gupta
>> ---
>> arch/Config.in.arc
On Tue, Oct 29, 2019 at 7:48 AM Christoph Hellwig wrote:
>
> On ia64 ioremap_nocache fails if attributes don't match. Not other
> architectures does this, and we plan to get rid of ioremap_nocache.
> So get rid of the special semantics and define ioremap_nocache in
> terms of ioremap as no
On Tue, Oct 29, 2019 at 7:48 AM Christoph Hellwig wrote:
>
> No users of ioremap_cached are left, remove it.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
On Wed, Nov 6, 2019 at 7:16 PM Geert Uytterhoeven wrote:
>
> Hi Palmer,
>
> On Wed, Nov 6, 2019 at 7:11 PM Palmer Dabbelt wrote:
> > It looks like the difference in prototype between the architectures is
> > between
> >
> > void __iomem *ioremap(resource_size_t, size_t)
> > void __iomem
On Mon, Nov 11, 2019 at 11:27:27AM +0100, Arnd Bergmann wrote:
> Ok, fair enough. Let's just go with your version for now, if only to not
> hold your series up more. I'd still suggest we change atyfb to only
> use ioremap_uc() on i386 and maybe ia64. I can send a patch for that.
I don't think we
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig wrote:
>
> All MMU-enabled ports have a non-trivial ioremap and should thus provide
> the prototype for their implementation instead of providing a generic
> one unless a different symbol is not defined. Note that this only
> affects sparc32
On Mon, Nov 11, 2019 at 11:15 AM Christoph Hellwig wrote:
>
> On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote:
> > Maybe we could move the definition into the atyfb driver itself?
> >
> > As I understand it, the difference between ioremap()/ioremap_nocache()
> > and ioremap_uc()
On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote:
> Maybe we could move the definition into the atyfb driver itself?
>
> As I understand it, the difference between ioremap()/ioremap_nocache()
> and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
> Ppro, PII, K6, VIA
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig wrote:
>
> A lot of architectures reuse the same simple ioremap implementation, so
> start lifting the most simple variant to lib/ioremap.c. It provides
> ioremap_prot and iounmap, plus a default ioremap that uses prot_noncached,
> although that
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig wrote:
>
> Various architectures that use asm-generic/io.h still defined their
> own default versions of ioremap_nocache, ioremap_wt and ioremap_wc
> that point back to plain ioremap directly or indirectly. Remove these
> definitions and rely on
On Mon 2019-11-11 10:23:36, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
> > I agree that it is complicated to pass the loglevel as
> > a parameter. It would be better define the default
> > log level for a given code section. It might be stored
> > in task_struct for
29 matches
Mail list logo
