Hi myungjoo, kyungmin and cw:
Would you please help to review this patch?
Thanks a lot.
pierre Kuo 於 2020年12月16日 週三 上午10:26寫道：
>
> In devfreq_add_device, replace devfreq->dev.parent
> as dev to keep code simple.
>
> Signed-off-by: pierre Kuo
> ---
> drivers/devfreq
In devfreq_add_device, replace devfreq->dev.parent
as dev to keep code simple.
Signed-off-by: pierre Kuo
---
drivers/devfreq/devfreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 6aa10de792b3..94cc25fd6
hi Greg:
> Why are you adding new functions but not actually calling them anywhere?
Below patch introduce a single helper, devm_platform_ioremap_resource,
which combines
platform_get_resource() and devm_ioremap_resource(). But there is no
single helper to release
those resources in driver removing
el.org/lkml/20200920113808.3-2-vichy@gmail.com
Appreciate your help,
From b141d537904b71b802770d9c0fc3787b98c5cf71 Mon Sep 17 00:00:00 2001
From: pierre Kuo
Date: Tue, 18 Aug 2020 23:05:00 +0800
Subject: [PATCH 1/2] lib: devres: provide devm_iounremap_resource()
Driver doesn't have a single he
ocated by devm_platform_get_and_ioremap_resource().
>
> Signed-off-by: pierre Kuo
> ---
> drivers/base/platform.c | 24
> include/linux/platform_device.h | 4
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/base/platform.c b/drivers/bas
tions.
Signed-off-by: pierre Kuo
---
include/linux/device.h | 2 ++
lib/devres.c | 25 +
2 files changed, 27 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 9e6ea8931a52..33ec7e54c1a9 100644
--- a/include/linux/device.h
+++ b/include/
Combine platform_get_resource() and devm_iounremap_resource() to release
the iomem allocated by devm_platform_get_and_ioremap_resource().
Signed-off-by: pierre Kuo
---
drivers/base/platform.c | 24
include/linux/platform_device.h | 4
2 files changed, 28
hi Ard:
> > The following is schematic diagram of the program before and after the
> > modification.
> >
> > Before:
> > if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) {} --(a)
> > if (memory_limit != PHYS_ADDR_MAX) {} --(b)
> > if (IS_ENABLED(CONFIG_
hi Rob:
> As no one else seems to have any comments, I've applied it.
Sorry for bothering you.
Since I haven't see this patch on below up stream repository,
"git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
if there is anything wrong about the patch, please let me know.
Appreciat
egion
> randomization ahead of memory_init, driver can safely using macro,
> __phys_to_virt, in (b) or (c), if necessary.
>
> Signed-off-by: pierre Kuo
> ---
> Changes in v2:
> - add Fixes tag
>
> Changes in v3:
> - adding patch of shifting linear region randomization ahead of
hi Rob, Marek and Frank:
> >
> > In this patch, we un-reserving memory ONLY if explicit compatible matching
> > fail.
> > That mean driver found something wrong while matching and let OS know.
> > (But reserved-memory without compatible property will not be affected.)
> >
> > So per ur explainati
hi Rob, Marek and Frank:
> > In this patch, we un-reserving memory ONLY if explicit compatible matching
> > fail.
> > That mean driver found something wrong while matching and let OS know.
> > (But reserved-memory without compatible property will not be affected.)
> >
> > So per ur explaination,
irtual address. Here we put
initrd_start/initrd_end to be calculated only when linear mapping check
pass.
Fixes: c756c592e442 ("arm64: Utilize phys_initrd_start/phys_initrd_size")
Reviewed-by: Steven Price
Signed-off-by: pierre Kuo
---
Changes in v2:
- add Fixes tag
Changes in v3:
- adding p
essary.
Signed-off-by: pierre Kuo
---
Changes in v2:
- add Fixes tag
Changes in v3:
- adding patch of shifting linear region randomization ahead of
memory_limit
arch/arm64/mm/init.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/
hi Will:
>
> Maybe, but I don't think we've seen a patch which accomplishes that. I think
> I'll go ahead and commit the basic one-liner, then we can always improve it
> afterwards if somebody sends a patch. It's not like this is a fastpath.
Sorry for not showing the patches I try to explain to si
hi Will:
>
> [+Ard in case I'm missing something]
>
> On Mon, Apr 01, 2019 at 10:59:53PM +0800, pierre kuo wrote:
> > > > With CONFIG_RANDOMIZE_BASE we can get a further change to memstart_addr
> > > > after the place where you moved the initrd_{start,end}
hi Catalin:
> > With CONFIG_RANDOMIZE_BASE we can get a further change to memstart_addr
> > after the place where you moved the initrd_{start,end} setting, which
> > would result in a different value for __phys_to_virt(phys_initrd_start).
>
> I found what you mean, since __phys_to_virt will use PH
hi Catalin:
> On Thu, Mar 14, 2019 at 11:20:47AM +0800, pierre Kuo wrote:
> > in the previous case, initrd_start and initrd_end can be successfully
> > returned either (base < memblock_start_of_DRAM()) or (base + size >
> > memblock_start_of_DRAM() + linear_region_siz
ail for initrd_start and
> initrd_end, it still can get virtual address. Here we put
> initrd_start/initrd_end to be calculated only when linear mapping check
> pass.
>
> Fixes: c756c592e442 ("arm64: Utilize phys_initrd_start/phys_initrd_size")
> Reviewed-by: Steven Price
irtual address. Here we put
initrd_start/initrd_end to be calculated only when linear mapping check
pass.
Fixes: c756c592e442 ("arm64: Utilize phys_initrd_start/phys_initrd_size")
Reviewed-by: Steven Price
Signed-off-by: pierre Kuo
---
Changes in v2:
- add Fixes tag
arch/arm64/mm/init.c
ddress. Here we put
initrd_start/initrd_end to be calculated only when linear mapping check
pass.
Signed-off-by: pierre Kuo
---
arch/arm64/mm/init.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 7205a9085b4d..1adf41
hi Rob, Marek and Frank:
> > > The __reserved_mem_init_node will call region specific reserved memory
> > > init codes, but once all compatibled init codes failed, the memory region
> > > will left in memory.reserved and cause leakage.
> > >
> > > Take cma reserve memory DTS for example, if user de
> You should Cc the author(s) of this code. I've added Marek.
Thanks ^^
The cc lists I got were from get_maintainer.pl, no matter running with
of_reserved_mem.c or patch file.
(with file)
$ perl scripts/get_maintainer.pl --separator , --norolestats
drivers/of/of_reserved_mem.c
Rob Herring ,Frank
atch will remove this kind of memory from memory.reserved, only
when __reserved_mem_init_node return neither 0 nor -ENOENT.
Signed-off-by: pierre Kuo
---
drivers/of/of_reserved_mem.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_reserved
hi Petr and Sergey:
> I wonder what is the motivation for the extra buffering. Did you
> have troubles with direct printk() calls? For example, because
> of performance, mixed messages, deadlocks?
Yes, when using direct printk() calls, we suffer performance and mix
message issues.
(Since originall
hi:
> There are several possible solutions:
>
> + We could update vprintk_emit() to detect all newlines and
> call log_store() for each part. But this would be a waste
> of the space.
>
> + We could increase the size provided by syslog_printk().
> But this is ugly.
>
> + We could go back to t
hi:
> printk_deferred("%s", local_string[2048]) makes no sense anyway,
> since we limit the message size to 1024 - HEADER chars in
> vprintk_emit() // see static char textbuf[LOG_LINE_MAX].
In local_string[2048], it will all be 0 from [590] to [2047].
And vprintk_emit() will cut message from [LOG
hi Sergey and Petr
> Hi,
> On (08/11/17 00:55), pierre kuo wrote:
> [..]
>> And people will be hard to find out some part of message is left behind.
>> (since the tail of original message is elegantly dropped by "\n")
>> That is the reason I try to add such wa
hi Sergey:
(Please ignore previous mail, I apologize for pressing send button too early :)
>> this is not the only place that can truncate the message.
>> vprintk_emit() can do so as well /* vscnprintf() */. but
>> I think we don't care that much. a user likely will notice
>> truncated messages. w
hi Sergey
> this is not the only place that can truncate the message.
> vprintk_emit() can do so as well /* vscnprintf() */. but
> I think we don't care that much. a user likely will notice
> truncated messages. we report lost messages, because this
> is a completely different sort of problem.
Usu
calculate how many
characters of log_text(msg) are dropped and add warning for debugging
purpose.
Signed-off-by: pierre Kuo
---
Changes since v2:
* fix typo in commit message from "waring for debugging purpose" to "warning
for debugging purpose"
kernel/
calculate how many
characters of log_text(msg) are dropped and add waring for debugging
purpose.
Signed-off-by: pierre Kuo
---
kernel/printk/printk.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index
hi Sergey and Andy:
> On (07/15/17 18:36), Pierre Kuo wrote:
> [..]
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> index fc47863..21557cc 100644
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -2194,8
From: pierre Kuo
In commit de6fcbdb68b2 ("printk: convert the rest to printk-safe"), we
create 4 helper macros to make printk-safe usage easier.
Here we modify some part of console_unlock with above marcros.
Signed-off-by: Pierre Kuo
---
kernel/printk/printk.c |6 ++
1 file
With commit ("printk: report lost messages in printk
safe/nmi contexts") and commit <8b1742c9c207> ("printk: remove zap_locks()
function"), it seems we can remove initialization, "=0", of text_len and
directly assign result of log_output to printed_len.
Si
hi Petr
> I just noticed that the same applies also to text_len
> variable. Well, it was caused by another commit ddb9baa822265b55
> ("printk: report lost messages in printk safe/nmi contexts").
> Could you please send a patch for this as well?
sure and it is my pleasure.
>
> This seems to be your
In 8b1742c9c207, we remove printk-recursion detection code in
vprintk_emit(), where it is the first place that printed_len calculated.
After removing above detection, it seems we can directly assign the
result of log_output to printed_len.
Signed-off-by: Pierre Kuo
---
kernel/printk/printk.c
hi Joe
>> > []
>> > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> >
>> > []
>> > > @@ -1754,7 +1754,7 @@ asmlinkage int vprintk_emit(int facility, int
>> > > level,
>> > > if (dict)
>> > > lflags |= LOG_PREFIX|LOG_NEWLINE;
>> > >
>> > > - printed_len +=
hi Joe:
2017-07-08 1:12 GMT+08:00 Joe Perches :
> On Sat, 2017-07-08 at 00:30 +0800, Pierre Kuo wrote:
>> In 8b1742c9c207, we remove printk-recursion detection code in
>> vprintk_emit(), where it is the first place that printed_len calculated.
>> After removing above detec
In 8b1742c9c207, we remove printk-recursion detection code in
vprintk_emit(), where it is the first place that printed_len calculated.
After removing above detection, it seems we can directly assign the
result of log_output to printed_len.
Signed-off-by: Pierre Kuo
---
kernel/printk/printk.c
40 matches
Mail list logo
