On (19/11/13 02:25), Dmitry Safonov wrote:
> I guess I've pointed that in my point of view price for one-time testing
> code is cheaper than adding a new printk feature to swap log levels on
> the fly.
[..]
> I've gone through functions used by sysrq driver and the same changes
> introducing log le
Ping !
On 11/5/19 9:35 AM, Vineet Gupta wrote:
> Apparently big endian glibc builds just work, if we let the endian
> header allow that (which prev was #error).
>
> So this patch bumps glibc to version which fixes the header (this
> hopefully will become arc-2019.09-release) and then enables arce
On (19/11/13 02:41), Dmitry Safonov wrote:
[..]
>
> I don't strongly disagree, but if you look at those results:
> git grep 'printk("%s.*", \(lvl\|level\)'
>
> it seems to be used in quite a few places.
Yes, you are right, it is used in some places. That's why I said
that I'd prefer to keep that
On 11/12/19 4:25 AM, Sergey Senozhatsky wrote:
> 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
On 11/13/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/12 19:12), Sergey Senozhatsky wrote:
>> On (19/11/12 09:35), Petr Mladek wrote:
>> [..]
>>> This is getting too complicated. It would introduce too many
>>> hidden rules. While the explicitly passed loglevel parameter
>>> is straightforward
On (19/11/12 19:12), Sergey Senozhatsky wrote:
> On (19/11/12 09:35), Petr Mladek wrote:
> [..]
> > This is getting too complicated. It would introduce too many
> > hidden rules. While the explicitly passed loglevel parameter
> > is straightforward and clear.
>
> If loglevel is DEFAULT or NOTICE or
On Tue, 12 Nov 2019 07:34:43 -0800
Vineet Gupta wrote:
> This corresponds to -mcu=hs38 with mpy-option=9 (64-bit multiplier)
>
> Signed-off-by: Vineet Gupta
> ---
> Changes since v1
> - Retained BR2_hs38 build semantics (dropped BR2_archs)
> - Introduced BR2_hs38_64mpy for generating double m
This corresponds to -mcu=hs38 with mpy-option=9 (64-bit multiplier)
Signed-off-by: Vineet Gupta
---
Changes since v1
- Retained BR2_hs38 build semantics (dropped BR2_archs)
- Introduced BR2_hs38_64mpy for generating double multiply instructions
---
arch/Config.in.arc | 17 -
1
Hi,
I have some fixes/updates from ongoing glibc work.
Please review/apply.
P.S. retaining the cover letter despite 1 patch to capture the revision
history of original multi-patch submission.
Chances since v1
- 1/3 reworked as suggested (details in patch itself)
- 2/3 dropped as it didn't seem
On (19/11/12 09:35), Petr Mladek wrote:
[..]
> This is getting too complicated. It would introduce too many
> hidden rules. While the explicitly passed loglevel parameter
> is straightforward and clear.
If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
(either downgrade or upgrade)
Hi,
Christoph Hellwig 於 2019年10月29日 週二 下午2:49寫道：
>
> Use the generic ioremap_prot and iounmap helpers.
>
> Note that the io.h include in pgtable.h had to be removed to not create
> an include loop. As far as I can tell there was no need for it to
> start with.
>
> Signed-off-by: Christoph Hellwi
On Tue 2019-11-12 13:57:04, Sergey Senozhatsky wrote:
> 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_deb
12 matches
Mail list logo
