Re: [PATCH 1/1] PM / devfreq: Replace devfreq->dev.parent as dev in devfreq_add_device

2020-12-28 Thread pierre kuo
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

[PATCH 1/1] PM / devfreq: Replace devfreq->dev.parent as dev in devfreq_add_device

2020-12-15 Thread pierre Kuo
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

Re: [PATCH 2/2] driver core: platform: provide devm_platform_iounremap_resource

2020-10-05 Thread pierre kuo
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

Re: [PATCH 2/2] driver core: platform: provide devm_platform_iounremap_resource

2020-10-04 Thread pierre kuo
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

Re: [PATCH 2/2] driver core: platform: provide devm_platform_iounremap_resource

2020-09-28 Thread pierre kuo
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

[PATCH 1/2] lib: devres: provide devm_iounremap_resource()

2020-09-20 Thread pierre Kuo
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/

[PATCH 2/2] driver core: platform: provide devm_platform_iounremap_resource

2020-09-20 Thread pierre Kuo
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

Re: [PATCH v3 1/2] kaslr: shift linear region randomization ahead of memory_limit

2019-05-12 Thread pierre kuo
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_

Re: [PATCH 1/1] of: reserved_mem: fix reserve memory leak

2019-05-09 Thread pierre kuo
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

Re: [PATCH v3 1/2] kaslr: shift linear region randomization ahead of memory_limit

2019-04-15 Thread pierre kuo
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

Re: [PATCH 1/1] of: reserved_mem: fix reserve memory leak

2019-04-08 Thread pierre kuo
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

Re: [PATCH 1/1] of: reserved_mem: fix reserve memory leak

2019-04-08 Thread pierre kuo
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,

[PATCH v3 2/2] initrd: move initrd_start calculate within linear mapping range check

2019-04-08 Thread pierre Kuo
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

[PATCH v3 1/2] kaslr: shift linear region randomization ahead of memory_limit

2019-04-08 Thread pierre Kuo
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/

Re: [PATCH v2 1/1] initrd: move initrd_start calculate within linear mapping range check

2019-04-08 Thread pierre kuo
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

Re: [PATCH v2 1/1] initrd: move initrd_start calculate within linear mapping range check

2019-04-03 Thread pierre kuo
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}

Re: [PATCH v2 1/1] initrd: move initrd_start calculate within linear mapping range check

2019-04-01 Thread pierre kuo
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

Re: [PATCH v2 1/1] initrd: move initrd_start calculate within linear mapping range check

2019-03-31 Thread pierre kuo
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

Re: [PATCH v2 1/1] initrd: move initrd_start calculate within linear mapping range check

2019-03-17 Thread pierre kuo
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

[PATCH v2 1/1] initrd: move initrd_start calculate within linear mapping range check

2019-03-13 Thread pierre Kuo
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

[PATCH 1/1] initrd: move initrd_start calculate within linear mapping range check

2019-03-11 Thread pierre Kuo
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

Re: [PATCH 1/1] of: reserved_mem: fix reserve memory leak

2019-03-11 Thread pierre kuo
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

Re: [PATCH 1/1] of: reserved_mem: fix reserve memory leak

2019-03-04 Thread pierre kuo
> 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

[PATCH 1/1] of: reserved_mem: fix reserve memory leak

2019-02-18 Thread pierre Kuo
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

Re: [RFC V2] printk: add warning while drop partial text in msg

2017-10-17 Thread pierre kuo
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

Re: [RFC V2] printk: add warning while drop partial text in msg

2017-10-17 Thread pierre kuo
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

Re: [RFC V2] printk: add warning while drop partial text in msg

2017-09-27 Thread pierre kuo
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

Re: [RFC V2] printk: add warning while drop partial text in msg

2017-09-11 Thread pierre kuo
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

Re: [RFC V2] printk: add warning while drop partial text in msg

2017-08-10 Thread pierre kuo
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

Re: [RFC V2] printk: add warning while drop partial text in msg

2017-08-10 Thread pierre kuo
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

[RFC V2] printk: add warning while drop partial text in msg

2017-07-30 Thread pierre Kuo
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/

[RFC] printk: add warning while drop partial text in msg

2017-07-28 Thread pierre Kuo
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

Re: [PATCH] printk: modify console_unlock with printk-safe macros

2017-07-17 Thread pierre kuo
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

[PATCH] printk: modify console_unlock with printk-safe macros

2017-07-15 Thread Pierre Kuo
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

[PATCH v2] printk: Modify operators of printed_len and text_len

2017-07-10 Thread Pierre Kuo
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

Re: [PATCH] printk: Modify operators of printed_len

2017-07-10 Thread pierre kuo
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

[PATCH] printk: Modify operators of printed_len

2017-07-07 Thread Pierre Kuo
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

Re: [PATCH] printk: Modify operators of printed_len

2017-07-07 Thread pierre kuo
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 +=

Re: [PATCH] printk: Modify operators of printed_len

2017-07-07 Thread pierre kuo
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

[PATCH] printk: Modify operators of printed_len

2017-07-07 Thread Pierre Kuo
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