Re: [PATCH v2 15/18] serial: intel: Support more platform
On Fri, Aug 03, 2018 at 11:02:34AM +0800, Songjun Wu wrote: > Support more platform. > > Signed-off-by: Songjun Wu > --- Your changelog text makes no sense, sorry. greg k-h
Re: [PATCH v2 15/18] serial: intel: Support more platform
On Fri, Aug 03, 2018 at 11:02:34AM +0800, Songjun Wu wrote: > Support more platform. > > Signed-off-by: Songjun Wu > --- Your changelog text makes no sense, sorry. greg k-h
Re: [PATCH v2 14/18] serial: intel: Add CCF support
On Fri, Aug 03, 2018 at 11:02:33AM +0800, Songjun Wu wrote: > Previous implementation uses platform-dependent API to get the clock. > Those functions are not available for other SoC which uses the same IP. > The CCF (Common Clock Framework) have an abstraction based APIs for > clock. In future, the platform specific code will be removed when the > legacy soc use CCF as well. > Change to use CCF APIs to get clock and rate. So that different SoCs > can use the same driver. > > Signed-off-by: Songjun Wu > --- > > Changes in v2: None > > drivers/tty/serial/lantiq.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c > index 36479d66fb7c..35518ab3a80d 100644 > --- a/drivers/tty/serial/lantiq.c > +++ b/drivers/tty/serial/lantiq.c > @@ -26,7 +26,9 @@ > #include > #include > > +#ifdef CONFIG_LANTIQ > #include > +#endif That is never how you do this in Linux, you know better. Please go and get this patchset reviewed and signed-off-by from other internal Intel kernel developers before resending it next time. It is their job to find and fix your basic errors like this, not ours. greg k-h
Re: [PATCH v2 14/18] serial: intel: Add CCF support
On Fri, Aug 03, 2018 at 11:02:33AM +0800, Songjun Wu wrote: > Previous implementation uses platform-dependent API to get the clock. > Those functions are not available for other SoC which uses the same IP. > The CCF (Common Clock Framework) have an abstraction based APIs for > clock. In future, the platform specific code will be removed when the > legacy soc use CCF as well. > Change to use CCF APIs to get clock and rate. So that different SoCs > can use the same driver. > > Signed-off-by: Songjun Wu > --- > > Changes in v2: None > > drivers/tty/serial/lantiq.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c > index 36479d66fb7c..35518ab3a80d 100644 > --- a/drivers/tty/serial/lantiq.c > +++ b/drivers/tty/serial/lantiq.c > @@ -26,7 +26,9 @@ > #include > #include > > +#ifdef CONFIG_LANTIQ > #include > +#endif That is never how you do this in Linux, you know better. Please go and get this patchset reviewed and signed-off-by from other internal Intel kernel developers before resending it next time. It is their job to find and fix your basic errors like this, not ours. greg k-h
[PATCH v1] mm:memcg: skip memcg of current in mem_cgroup_soft_limit_reclaim
for the soft_limit reclaim has more directivity than global reclaim, we
have current memcg be skipped to avoid potential page thrashing.
Signed-off-by: Zhaoyang Huang
---
mm/memcontrol.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8c0280b..9d09e95 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2537,12 +2537,21 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t
*pgdat, int order,
mz = mem_cgroup_largest_soft_limit_node(mctz);
if (!mz)
break;
-
+ /*
+* skip current memcg to avoid page thrashing, for the
+* mem_cgroup_soft_reclaim has more directivity than
+* global reclaim.
+*/
+ if (get_mem_cgroup_from_mm(current->mm) == mz->memcg) {
+ reclaimed = 0;
+ goto next;
+ }
nr_scanned = 0;
reclaimed = mem_cgroup_soft_reclaim(mz->memcg, pgdat,
gfp_mask, _scanned);
nr_reclaimed += reclaimed;
*total_scanned += nr_scanned;
+next:
spin_lock_irq(>lock);
__mem_cgroup_remove_exceeded(mz, mctz);
--
1.9.1
[PATCH v1] mm:memcg: skip memcg of current in mem_cgroup_soft_limit_reclaim
for the soft_limit reclaim has more directivity than global reclaim, we
have current memcg be skipped to avoid potential page thrashing.
Signed-off-by: Zhaoyang Huang
---
mm/memcontrol.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8c0280b..9d09e95 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2537,12 +2537,21 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t
*pgdat, int order,
mz = mem_cgroup_largest_soft_limit_node(mctz);
if (!mz)
break;
-
+ /*
+* skip current memcg to avoid page thrashing, for the
+* mem_cgroup_soft_reclaim has more directivity than
+* global reclaim.
+*/
+ if (get_mem_cgroup_from_mm(current->mm) == mz->memcg) {
+ reclaimed = 0;
+ goto next;
+ }
nr_scanned = 0;
reclaimed = mem_cgroup_soft_reclaim(mz->memcg, pgdat,
gfp_mask, _scanned);
nr_reclaimed += reclaimed;
*total_scanned += nr_scanned;
+next:
spin_lock_irq(>lock);
__mem_cgroup_remove_exceeded(mz, mctz);
--
1.9.1
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
On (08/03/18 14:23), Sergey Senozhatsky wrote: > > Hmm, any chance a WB device can be async on its own? We add a page > to a new bio and submit it to another async device driver. Then we > return back to the upper layer (swap), which can free a page before > the device picks up a request. Can this happen? Nevermind these questions. Sorry for the noise. -ss
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
On (08/03/18 14:23), Sergey Senozhatsky wrote: > > Hmm, any chance a WB device can be async on its own? We add a page > to a new bio and submit it to another async device driver. Then we > return back to the upper layer (swap), which can free a page before > the device picks up a request. Can this happen? Nevermind these questions. Sorry for the noise. -ss
Re: [PATCH v2 08/18] serial: intel: Get serial id from dts
On Fri, Aug 03, 2018 at 11:02:27AM +0800, Songjun Wu wrote: > Get serial id from dts. > > "#ifdef CONFIG_LANTIQ" preprocessor is used because LTQ_EARLY_ASC > macro is defined in lantiq_soc.h. > lantiq_soc.h is in arch path for legacy product support. > > arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h > > If "#ifdef preprocessor" is changed to > "if (IS_ENABLED(CONFIG_LANTIQ))", when CONFIG_LANTIQ is not enabled, > code using LTQ_EARLY_ASC is compiled. > Compilation will fail for no LTQ_EARLY_ASC defined. > > Signed-off-by: Songjun Wu > --- > > Changes in v2: None > > drivers/tty/serial/lantiq.c | 19 +++ > 1 file changed, 15 insertions(+), 4 deletions(-) > > diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c > index 044128277248..836ca51460f2 100644 > --- a/drivers/tty/serial/lantiq.c > +++ b/drivers/tty/serial/lantiq.c > @@ -6,6 +6,7 @@ > * Copyright (C) 2007 Felix Fietkau > * Copyright (C) 2007 John Crispin > * Copyright (C) 2010 Thomas Langer, > + * Copyright (C) 2018 Intel Corporation. Your changes here do not warrent the addition of a copyright line, don't you agree? If not, please get a signed-off-by from your corporate lawyer who does this this is warrented when you resend this patch. thanks, greg k-h
Re: [PATCH v2 08/18] serial: intel: Get serial id from dts
On Fri, Aug 03, 2018 at 11:02:27AM +0800, Songjun Wu wrote: > Get serial id from dts. > > "#ifdef CONFIG_LANTIQ" preprocessor is used because LTQ_EARLY_ASC > macro is defined in lantiq_soc.h. > lantiq_soc.h is in arch path for legacy product support. > > arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h > > If "#ifdef preprocessor" is changed to > "if (IS_ENABLED(CONFIG_LANTIQ))", when CONFIG_LANTIQ is not enabled, > code using LTQ_EARLY_ASC is compiled. > Compilation will fail for no LTQ_EARLY_ASC defined. > > Signed-off-by: Songjun Wu > --- > > Changes in v2: None > > drivers/tty/serial/lantiq.c | 19 +++ > 1 file changed, 15 insertions(+), 4 deletions(-) > > diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c > index 044128277248..836ca51460f2 100644 > --- a/drivers/tty/serial/lantiq.c > +++ b/drivers/tty/serial/lantiq.c > @@ -6,6 +6,7 @@ > * Copyright (C) 2007 Felix Fietkau > * Copyright (C) 2007 John Crispin > * Copyright (C) 2010 Thomas Langer, > + * Copyright (C) 2018 Intel Corporation. Your changes here do not warrent the addition of a copyright line, don't you agree? If not, please get a signed-off-by from your corporate lawyer who does this this is warrented when you resend this patch. thanks, greg k-h
Re: [PATCH 4.14 000/246] 4.14.60-stable review
On Thu, Aug 02, 2018 at 06:21:39PM -0700, Guenter Roeck wrote: > On 08/02/2018 12:45 PM, Greg Kroah-Hartman wrote: > [ ... ] > > > > I've pushed out -rc2 releases for all of these with that patch removed. > > > > Boot tests with updated images passed for all three releases. Wonderful, thanks for letting me know. greg k-h
Re: [PATCH 4.14 000/246] 4.14.60-stable review
On Thu, Aug 02, 2018 at 06:21:39PM -0700, Guenter Roeck wrote: > On 08/02/2018 12:45 PM, Greg Kroah-Hartman wrote: > [ ... ] > > > > I've pushed out -rc2 releases for all of these with that patch removed. > > > > Boot tests with updated images passed for all three releases. Wonderful, thanks for letting me know. greg k-h
Re: [PATCH] firmware: make sure builtin firmware is page alignment
On Fri, Aug 03, 2018 at 09:45:21AM +0800, Zhang Ning wrote: > when firmware is in filesystem, request_firmware will load it, > and copy it to vmalloc memory, that is page align memory. > > but when firmware is builtin, it is 8 bytes or 4 bytes alignment. > > make sure builtin firmware is page algnment, that can simplify algorithm > to handle firmware. How is it simplified? I don't see any such change like that here :(
Re: [PATCH] firmware: make sure builtin firmware is page alignment
On Fri, Aug 03, 2018 at 09:45:21AM +0800, Zhang Ning wrote: > when firmware is in filesystem, request_firmware will load it, > and copy it to vmalloc memory, that is page align memory. > > but when firmware is builtin, it is 8 bytes or 4 bytes alignment. > > make sure builtin firmware is page algnment, that can simplify algorithm > to handle firmware. How is it simplified? I don't see any such change like that here :(
Re: [PATCH 23/25] selftests/ftrace: Add max stack tracer testcase
On Fri, 27 Jul 2018 21:20:47 +0900 Masami Hiramatsu wrote: > Add a testcase for max stack tracer, which checks basic > max stack usage tracing and its filter feature. > Hmm, this test sometimes fails. (not always) Let me check what happens. Thank you, > Signed-off-by: Masami Hiramatsu > --- > .../ftrace/test.d/ftrace/func_stack_tracer.tc | 39 > > 1 file changed, 39 insertions(+) > create mode 100644 > tools/testing/selftests/ftrace/test.d/ftrace/func_stack_tracer.tc > > diff --git > a/tools/testing/selftests/ftrace/test.d/ftrace/func_stack_tracer.tc > b/tools/testing/selftests/ftrace/test.d/ftrace/func_stack_tracer.tc > new file mode 100644 > index ..b414f0e3c646 > --- /dev/null > +++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_stack_tracer.tc > @@ -0,0 +1,39 @@ > +#!/bin/sh > +# SPDX-License-Identifier: GPL-2.0 > +# description: ftrace - Max stack tracer > +# Test the basic function of max-stack usage tracing > + > +if [ ! -f stack_trace ]; then > + echo "Max stack tracer is not supported - please make > CONFIG_STACK_TRACER=y" > + exit_unsupported > +fi > + > +echo > stack_trace_filter > +echo 0 > stack_max_size > +echo 1 > /proc/sys/kernel/stack_tracer_enabled > + > +: "Fork and wait for the first entry become !lock" > +timeout=10 > +while [ $timeout -ne 0 ]; do > + ( echo "forked" ) > + FL=`grep " 0)" stack_trace` > + echo $FL | grep -q "lock" || break; > + timeout=$((timeout - 1)) > +done > +echo 0 > /proc/sys/kernel/stack_tracer_enabled > + > +echo '*lock*' > stack_trace_filter > +test `cat stack_trace_filter | wc -l` -eq `grep lock stack_trace_filter | wc > -l` > + > +echo 0 > stack_max_size > +echo 1 > /proc/sys/kernel/stack_tracer_enabled > + > +: "Fork and always the first entry including lock" > +timeout=10 > +while [ $timeout -ne 0 ]; do > + ( echo "forked" ) > + FL=`grep " 0)" stack_trace` > + echo $FL | grep -q "lock" > + timeout=$((timeout - 1)) > +done > +echo 0 > /proc/sys/kernel/stack_tracer_enabled > -- Masami Hiramatsu
Re: [PATCH 23/25] selftests/ftrace: Add max stack tracer testcase
On Fri, 27 Jul 2018 21:20:47 +0900 Masami Hiramatsu wrote: > Add a testcase for max stack tracer, which checks basic > max stack usage tracing and its filter feature. > Hmm, this test sometimes fails. (not always) Let me check what happens. Thank you, > Signed-off-by: Masami Hiramatsu > --- > .../ftrace/test.d/ftrace/func_stack_tracer.tc | 39 > > 1 file changed, 39 insertions(+) > create mode 100644 > tools/testing/selftests/ftrace/test.d/ftrace/func_stack_tracer.tc > > diff --git > a/tools/testing/selftests/ftrace/test.d/ftrace/func_stack_tracer.tc > b/tools/testing/selftests/ftrace/test.d/ftrace/func_stack_tracer.tc > new file mode 100644 > index ..b414f0e3c646 > --- /dev/null > +++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_stack_tracer.tc > @@ -0,0 +1,39 @@ > +#!/bin/sh > +# SPDX-License-Identifier: GPL-2.0 > +# description: ftrace - Max stack tracer > +# Test the basic function of max-stack usage tracing > + > +if [ ! -f stack_trace ]; then > + echo "Max stack tracer is not supported - please make > CONFIG_STACK_TRACER=y" > + exit_unsupported > +fi > + > +echo > stack_trace_filter > +echo 0 > stack_max_size > +echo 1 > /proc/sys/kernel/stack_tracer_enabled > + > +: "Fork and wait for the first entry become !lock" > +timeout=10 > +while [ $timeout -ne 0 ]; do > + ( echo "forked" ) > + FL=`grep " 0)" stack_trace` > + echo $FL | grep -q "lock" || break; > + timeout=$((timeout - 1)) > +done > +echo 0 > /proc/sys/kernel/stack_tracer_enabled > + > +echo '*lock*' > stack_trace_filter > +test `cat stack_trace_filter | wc -l` -eq `grep lock stack_trace_filter | wc > -l` > + > +echo 0 > stack_max_size > +echo 1 > /proc/sys/kernel/stack_tracer_enabled > + > +: "Fork and always the first entry including lock" > +timeout=10 > +while [ $timeout -ne 0 ]; do > + ( echo "forked" ) > + FL=`grep " 0)" stack_trace` > + echo $FL | grep -q "lock" > + timeout=$((timeout - 1)) > +done > +echo 0 > /proc/sys/kernel/stack_tracer_enabled > -- Masami Hiramatsu
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
On (08/03/18 13:51), Minchan Kim wrote: > > AFAIK, onging writeback page couldn't freed so it was not writeabck problem. > > What I'm tryig to fix is read part. > If we use swapcache, it shouldn't be a problem either because swapcache > has a reference count and we should wait PG_lock release before the freeing > from the swapcache so there is no race condition. Hmm, any chance a WB device can be async on its own? We add a page to a new bio and submit it to another async device driver. Then we return back to the upper layer (swap), which can free a page before the device picks up a request. Can this happen? [..] > However, I decided, at this moment, going this simple way for > stable-material to solve #0 and #1 problems at the same time. Agreed. Thanks. -ss
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
On (08/03/18 13:51), Minchan Kim wrote: > > AFAIK, onging writeback page couldn't freed so it was not writeabck problem. > > What I'm tryig to fix is read part. > If we use swapcache, it shouldn't be a problem either because swapcache > has a reference count and we should wait PG_lock release before the freeing > from the swapcache so there is no race condition. Hmm, any chance a WB device can be async on its own? We add a page to a new bio and submit it to another async device driver. Then we return back to the upper layer (swap), which can free a page before the device picks up a request. Can this happen? [..] > However, I decided, at this moment, going this simple way for > stable-material to solve #0 and #1 problems at the same time. Agreed. Thanks. -ss
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
On Fri, Aug 03, 2018 at 01:13:02PM +0900, Sergey Senozhatsky wrote: > Hi Minchan, > > On (08/03/18 12:00), Minchan Kim wrote: > > > "Device is so fast that asynchronous IO would be inefficient." > > > > > > Which is not the reason why BDI_CAP_SYNCHRONOUS_IO is used by ZRAM. > > > Probably, the comment needs to be updated as well. > > > > I couldn't catch your point. Could you clarify a little bit more? > > What do you want to correct for the comment? > > > > > Both SWP_SYNCHRONOUS_IO and BDI_CAP_SYNCHRONOUS_IO tend to pivot > > > "efficiency" [looking at the comments], but in ZRAM's case the whole > > > reason to use SYNC IO is a race condition and user-after-free that > > > follows. > > > > Actually, it's not whole reason. As I wrote down, without it, swap_readpage > > waits the IO completion for a long time by blk_poll so it causes system > > sluggish problem when device is slow(e.g., zram with backing device). > > Sure, this is problem #1. But slow swap device probably doesn't do any > irreversible harm to the system. Unlike use-after-free, which does. Thus > use-after-free is a problem #0. BDI_CAP_SYNCHRONOUS_IO comment doesn't > mention problem #0; it talks about problem #1 only. So, nothing serious, > just wanted to point that out. > > So we probably can make ZRAM always ASYNC when WB is enabled. > > > Or... maybe we can make swap out to be SYNC and perform WB in background. > In __zram_bvec_write() we can always write compressed object to zmalloc, > even the huge ones. > Things to note: > a) even when WB is enabled we still allocate huge classes > b) even when WB is enabled we still may use those huge classes (consider >a case when backing devices is full) > > So huge classes are still there and we still use them. So let's use > them? > > For a huge object, after we stored it into zsmalloc, we can schedule a WB > work, which would: > a) write that particular object (page) to the backing device > b) mark entry as WB entry > c) remove object from zsmalloc, unlock necessary locks > > So swap in should either see object in zsmalloc or on backing device. > How does this sound? > > And reading from a backing device can always be SYNC. Can it? > Am I missing something? AFAIK, onging writeback page couldn't freed so it was not writeabck problem. What I'm tryig to fix is read part. If we use swapcache, it shouldn't be a problem either because swapcache has a reference count and we should wait PG_lock release before the freeing from the swapcache so there is no race condition. However, by the skip swapcache logic, we don't have a refcount any longer. I think we can hold a new refcount in zram driver itself. With that, we could get both benefits from writeback feature and skip swapcache. However, I decided, at this moment, going this simple way for stable-material to solve #0 and #1 problems at the same time. Thanks. > > -ss
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
On Fri, Aug 03, 2018 at 01:13:02PM +0900, Sergey Senozhatsky wrote: > Hi Minchan, > > On (08/03/18 12:00), Minchan Kim wrote: > > > "Device is so fast that asynchronous IO would be inefficient." > > > > > > Which is not the reason why BDI_CAP_SYNCHRONOUS_IO is used by ZRAM. > > > Probably, the comment needs to be updated as well. > > > > I couldn't catch your point. Could you clarify a little bit more? > > What do you want to correct for the comment? > > > > > Both SWP_SYNCHRONOUS_IO and BDI_CAP_SYNCHRONOUS_IO tend to pivot > > > "efficiency" [looking at the comments], but in ZRAM's case the whole > > > reason to use SYNC IO is a race condition and user-after-free that > > > follows. > > > > Actually, it's not whole reason. As I wrote down, without it, swap_readpage > > waits the IO completion for a long time by blk_poll so it causes system > > sluggish problem when device is slow(e.g., zram with backing device). > > Sure, this is problem #1. But slow swap device probably doesn't do any > irreversible harm to the system. Unlike use-after-free, which does. Thus > use-after-free is a problem #0. BDI_CAP_SYNCHRONOUS_IO comment doesn't > mention problem #0; it talks about problem #1 only. So, nothing serious, > just wanted to point that out. > > So we probably can make ZRAM always ASYNC when WB is enabled. > > > Or... maybe we can make swap out to be SYNC and perform WB in background. > In __zram_bvec_write() we can always write compressed object to zmalloc, > even the huge ones. > Things to note: > a) even when WB is enabled we still allocate huge classes > b) even when WB is enabled we still may use those huge classes (consider >a case when backing devices is full) > > So huge classes are still there and we still use them. So let's use > them? > > For a huge object, after we stored it into zsmalloc, we can schedule a WB > work, which would: > a) write that particular object (page) to the backing device > b) mark entry as WB entry > c) remove object from zsmalloc, unlock necessary locks > > So swap in should either see object in zsmalloc or on backing device. > How does this sound? > > And reading from a backing device can always be SYNC. Can it? > Am I missing something? AFAIK, onging writeback page couldn't freed so it was not writeabck problem. What I'm tryig to fix is read part. If we use swapcache, it shouldn't be a problem either because swapcache has a reference count and we should wait PG_lock release before the freeing from the swapcache so there is no race condition. However, by the skip swapcache logic, we don't have a refcount any longer. I think we can hold a new refcount in zram driver itself. With that, we could get both benefits from writeback feature and skip swapcache. However, I decided, at this moment, going this simple way for stable-material to solve #0 and #1 problems at the same time. Thanks. > > -ss
Re: Re: [PATCH] i2c: xlp9xx: Fix case where SSIF read transaction completes early
Hi Wolfran,
Thanks for the review.
I will update the patch with a small comment section above
len --;
so that there is no confusion.
On 08/01/2018 02:35 AM, Wolfram Sang wrote:
--- a/drivers/i2c/busses/i2c-xlp9xx.c
+++ b/drivers/i2c/busses/i2c-xlp9xx.c
@@ -191,28 +191,30 @@ static void xlp9xx_i2c_drain_rx_fifo(struct
xlp9xx_i2c_dev *priv)
if (priv->len_recv) {
/* read length byte */
rlen = xlp9xx_read_i2c_reg(priv, XLP9XX_I2C_MRXFIFO);
+ len--;
I don't know the HW and assume the above line is correct because of
merging two interrupts into one. However, the line looks a bit stray,
and I wonder if we shouldn't add a comment somewhere explaining the
situation similar to the second paragraph of the commit message?
Regards,
-George
Re: Re: [PATCH] i2c: xlp9xx: Fix case where SSIF read transaction completes early
Hi Wolfran,
Thanks for the review.
I will update the patch with a small comment section above
len --;
so that there is no confusion.
On 08/01/2018 02:35 AM, Wolfram Sang wrote:
--- a/drivers/i2c/busses/i2c-xlp9xx.c
+++ b/drivers/i2c/busses/i2c-xlp9xx.c
@@ -191,28 +191,30 @@ static void xlp9xx_i2c_drain_rx_fifo(struct
xlp9xx_i2c_dev *priv)
if (priv->len_recv) {
/* read length byte */
rlen = xlp9xx_read_i2c_reg(priv, XLP9XX_I2C_MRXFIFO);
+ len--;
I don't know the HW and assume the above line is correct because of
merging two interrupts into one. However, the line looks a bit stray,
and I wonder if we shouldn't add a comment somewhere explaining the
situation similar to the second paragraph of the commit message?
Regards,
-George
linux-next: build warning after merge of the spi tree
Hi Mark,
After merging the spi tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/spi/spi-mem.c: In function 'spi_mem_probe':
drivers/spi/spi-mem.c:375:13: warning: assignment discards 'const' qualifier
from pointer target type [-Wdiscarded-qualifiers]
mem->name = ctlr->mem_ops->get_name(mem);
^
drivers/spi/spi-mem.c:377:13: warning: assignment discards 'const' qualifier
from pointer target type [-Wdiscarded-qualifiers]
mem->name = dev_name(>dev);
^
Introduced by commit
5d27a9c8ea9e ("spi: spi-mem: Extend the SPI mem interface to set a custom
memory name")
"const" is good :-)
--
Cheers,
Stephen Rothwell
pgptCzauBoeZL.pgp
Description: OpenPGP digital signature
[PATCH v2] staging: rtlwifi: refactor rtl_get_tcb_desc
Refactored rtl_get_tcb_desc slightly to stay within the 80 character
line limit.
Signed-off-by: Luke Triantafyllidis
---
Changes in v2:
- Fixed the formatting of the comments
- Unwrapped some of the lines that were originally wrapped over multiple
lines to stay within the 80 character limit
Note:
- I didn't CC the first version of this patch to a public mailing list, so if
you're not Greg KH, you probably want to look at this in its entirety
drivers/staging/rtlwifi/base.c | 102 +++-
1 files changed, 48 insertions(+), 54 deletions(-)
diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
index e46e47d..b1b2f78 100644
--- a/drivers/staging/rtlwifi/base.c
+++ b/drivers/staging/rtlwifi/base.c
@@ -1237,67 +1237,61 @@ void rtl_get_tcb_desc(struct ieee80211_hw *hw,
if (rtl_is_tx_report_skb(hw, skb))
tcb_desc->use_spe_rpt = 1;
- if (ieee80211_is_data(fc)) {
- /*
-*we set data rate INX 0
-*in rtl_rc.c if skb is special data or
-*mgt which need low data rate.
-*/
-
- /*
-*So tcb_desc->hw_rate is just used for
-*special data and mgt frames
-*/
- if (info->control.rates[0].idx == 0 ||
- ieee80211_is_nullfunc(fc)) {
- tcb_desc->use_driver_rate = true;
- tcb_desc->ratr_index =
- SET_RATE_ID(RATR_INX_WIRELESS_MC);
+ if (!ieee80211_is_data(fc)) {
+ tcb_desc->use_driver_rate = true;
+ tcb_desc->ratr_index = SET_RATE_ID(RATR_INX_WIRELESS_MC);
+ tcb_desc->disable_ratefallback = 1;
+ tcb_desc->mac_id = 0;
+ tcb_desc->packet_bw = false;
- tcb_desc->disable_ratefallback = 1;
- } else {
- /* because hw will never use hw_rate
-* when tcb_desc->use_driver_rate = false
-* so we never set highest N rate here,
-* and N rate will all be controlled by FW
-* when tcb_desc->use_driver_rate = false
-*/
- if (sta && sta->vht_cap.vht_supported) {
- tcb_desc->hw_rate =
- _rtl_get_vht_highest_n_rate(hw, sta);
- } else {
- if (sta && sta->ht_cap.ht_supported) {
- tcb_desc->hw_rate =
- _rtl_get_highest_n_rate(hw, sta);
- } else {
- if (rtlmac->mode == WIRELESS_MODE_B) {
- tcb_desc->hw_rate =
-
rtlpriv->cfg->maps[RTL_RC_CCK_RATE11M];
- } else {
- tcb_desc->hw_rate =
-
rtlpriv->cfg->maps[RTL_RC_OFDM_RATE54M];
- }
- }
- }
- }
+ return;
+ }
- if (is_multicast_ether_addr(hdr->addr1))
- tcb_desc->multicast = 1;
- else if (is_broadcast_ether_addr(hdr->addr1))
- tcb_desc->broadcast = 1;
+ /*
+* We set data rate INX 0
+* in rtl_rc.c if skb is special data or
+* mgt which need low data rate.
+*/
- _rtl_txrate_selectmode(hw, sta, tcb_desc);
- _rtl_query_bandwidth_mode(hw, sta, tcb_desc);
- _rtl_qurey_shortpreamble_mode(hw, tcb_desc, info);
- _rtl_query_shortgi(hw, sta, tcb_desc, info);
- _rtl_query_protection_mode(hw, tcb_desc, info);
- } else {
+ /*
+* So tcb_desc->hw_rate is just used for
+* special data and mgt frames
+*/
+ if (info->control.rates[0].idx == 0 || ieee80211_is_nullfunc(fc)) {
tcb_desc->use_driver_rate = true;
tcb_desc->ratr_index = SET_RATE_ID(RATR_INX_WIRELESS_MC);
+
tcb_desc->disable_ratefallback = 1;
- tcb_desc->mac_id = 0;
- tcb_desc->packet_bw = false;
+ } else if (sta && sta->vht_cap.vht_supported) {
+ /*
+* Because hw will never use hw_rate
+* when tcb_desc->use_driver_rate = false
+* so we never set highest N rate here,
+* and N rate will all be controlled by FW
+* when tcb_desc->use_driver_rate = false
+*/
+ tcb_desc->hw_rate = _rtl_get_vht_highest_n_rate(hw, sta);
+
linux-next: build warning after merge of the spi tree
Hi Mark,
After merging the spi tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/spi/spi-mem.c: In function 'spi_mem_probe':
drivers/spi/spi-mem.c:375:13: warning: assignment discards 'const' qualifier
from pointer target type [-Wdiscarded-qualifiers]
mem->name = ctlr->mem_ops->get_name(mem);
^
drivers/spi/spi-mem.c:377:13: warning: assignment discards 'const' qualifier
from pointer target type [-Wdiscarded-qualifiers]
mem->name = dev_name(>dev);
^
Introduced by commit
5d27a9c8ea9e ("spi: spi-mem: Extend the SPI mem interface to set a custom
memory name")
"const" is good :-)
--
Cheers,
Stephen Rothwell
pgptCzauBoeZL.pgp
Description: OpenPGP digital signature
[PATCH v2] staging: rtlwifi: refactor rtl_get_tcb_desc
Refactored rtl_get_tcb_desc slightly to stay within the 80 character
line limit.
Signed-off-by: Luke Triantafyllidis
---
Changes in v2:
- Fixed the formatting of the comments
- Unwrapped some of the lines that were originally wrapped over multiple
lines to stay within the 80 character limit
Note:
- I didn't CC the first version of this patch to a public mailing list, so if
you're not Greg KH, you probably want to look at this in its entirety
drivers/staging/rtlwifi/base.c | 102 +++-
1 files changed, 48 insertions(+), 54 deletions(-)
diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
index e46e47d..b1b2f78 100644
--- a/drivers/staging/rtlwifi/base.c
+++ b/drivers/staging/rtlwifi/base.c
@@ -1237,67 +1237,61 @@ void rtl_get_tcb_desc(struct ieee80211_hw *hw,
if (rtl_is_tx_report_skb(hw, skb))
tcb_desc->use_spe_rpt = 1;
- if (ieee80211_is_data(fc)) {
- /*
-*we set data rate INX 0
-*in rtl_rc.c if skb is special data or
-*mgt which need low data rate.
-*/
-
- /*
-*So tcb_desc->hw_rate is just used for
-*special data and mgt frames
-*/
- if (info->control.rates[0].idx == 0 ||
- ieee80211_is_nullfunc(fc)) {
- tcb_desc->use_driver_rate = true;
- tcb_desc->ratr_index =
- SET_RATE_ID(RATR_INX_WIRELESS_MC);
+ if (!ieee80211_is_data(fc)) {
+ tcb_desc->use_driver_rate = true;
+ tcb_desc->ratr_index = SET_RATE_ID(RATR_INX_WIRELESS_MC);
+ tcb_desc->disable_ratefallback = 1;
+ tcb_desc->mac_id = 0;
+ tcb_desc->packet_bw = false;
- tcb_desc->disable_ratefallback = 1;
- } else {
- /* because hw will never use hw_rate
-* when tcb_desc->use_driver_rate = false
-* so we never set highest N rate here,
-* and N rate will all be controlled by FW
-* when tcb_desc->use_driver_rate = false
-*/
- if (sta && sta->vht_cap.vht_supported) {
- tcb_desc->hw_rate =
- _rtl_get_vht_highest_n_rate(hw, sta);
- } else {
- if (sta && sta->ht_cap.ht_supported) {
- tcb_desc->hw_rate =
- _rtl_get_highest_n_rate(hw, sta);
- } else {
- if (rtlmac->mode == WIRELESS_MODE_B) {
- tcb_desc->hw_rate =
-
rtlpriv->cfg->maps[RTL_RC_CCK_RATE11M];
- } else {
- tcb_desc->hw_rate =
-
rtlpriv->cfg->maps[RTL_RC_OFDM_RATE54M];
- }
- }
- }
- }
+ return;
+ }
- if (is_multicast_ether_addr(hdr->addr1))
- tcb_desc->multicast = 1;
- else if (is_broadcast_ether_addr(hdr->addr1))
- tcb_desc->broadcast = 1;
+ /*
+* We set data rate INX 0
+* in rtl_rc.c if skb is special data or
+* mgt which need low data rate.
+*/
- _rtl_txrate_selectmode(hw, sta, tcb_desc);
- _rtl_query_bandwidth_mode(hw, sta, tcb_desc);
- _rtl_qurey_shortpreamble_mode(hw, tcb_desc, info);
- _rtl_query_shortgi(hw, sta, tcb_desc, info);
- _rtl_query_protection_mode(hw, tcb_desc, info);
- } else {
+ /*
+* So tcb_desc->hw_rate is just used for
+* special data and mgt frames
+*/
+ if (info->control.rates[0].idx == 0 || ieee80211_is_nullfunc(fc)) {
tcb_desc->use_driver_rate = true;
tcb_desc->ratr_index = SET_RATE_ID(RATR_INX_WIRELESS_MC);
+
tcb_desc->disable_ratefallback = 1;
- tcb_desc->mac_id = 0;
- tcb_desc->packet_bw = false;
+ } else if (sta && sta->vht_cap.vht_supported) {
+ /*
+* Because hw will never use hw_rate
+* when tcb_desc->use_driver_rate = false
+* so we never set highest N rate here,
+* and N rate will all be controlled by FW
+* when tcb_desc->use_driver_rate = false
+*/
+ tcb_desc->hw_rate = _rtl_get_vht_highest_n_rate(hw, sta);
+
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
Hi Minchan, On (08/03/18 12:00), Minchan Kim wrote: > > "Device is so fast that asynchronous IO would be inefficient." > > > > Which is not the reason why BDI_CAP_SYNCHRONOUS_IO is used by ZRAM. > > Probably, the comment needs to be updated as well. > > I couldn't catch your point. Could you clarify a little bit more? > What do you want to correct for the comment? > > > Both SWP_SYNCHRONOUS_IO and BDI_CAP_SYNCHRONOUS_IO tend to pivot > > "efficiency" [looking at the comments], but in ZRAM's case the whole > > reason to use SYNC IO is a race condition and user-after-free that > > follows. > > Actually, it's not whole reason. As I wrote down, without it, swap_readpage > waits the IO completion for a long time by blk_poll so it causes system > sluggish problem when device is slow(e.g., zram with backing device). Sure, this is problem #1. But slow swap device probably doesn't do any irreversible harm to the system. Unlike use-after-free, which does. Thus use-after-free is a problem #0. BDI_CAP_SYNCHRONOUS_IO comment doesn't mention problem #0; it talks about problem #1 only. So, nothing serious, just wanted to point that out. So we probably can make ZRAM always ASYNC when WB is enabled. Or... maybe we can make swap out to be SYNC and perform WB in background. In __zram_bvec_write() we can always write compressed object to zmalloc, even the huge ones. Things to note: a) even when WB is enabled we still allocate huge classes b) even when WB is enabled we still may use those huge classes (consider a case when backing devices is full) So huge classes are still there and we still use them. So let's use them? For a huge object, after we stored it into zsmalloc, we can schedule a WB work, which would: a) write that particular object (page) to the backing device b) mark entry as WB entry c) remove object from zsmalloc, unlock necessary locks So swap in should either see object in zsmalloc or on backing device. How does this sound? And reading from a backing device can always be SYNC. Can it? Am I missing something? -ss
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
Hi Minchan, On (08/03/18 12:00), Minchan Kim wrote: > > "Device is so fast that asynchronous IO would be inefficient." > > > > Which is not the reason why BDI_CAP_SYNCHRONOUS_IO is used by ZRAM. > > Probably, the comment needs to be updated as well. > > I couldn't catch your point. Could you clarify a little bit more? > What do you want to correct for the comment? > > > Both SWP_SYNCHRONOUS_IO and BDI_CAP_SYNCHRONOUS_IO tend to pivot > > "efficiency" [looking at the comments], but in ZRAM's case the whole > > reason to use SYNC IO is a race condition and user-after-free that > > follows. > > Actually, it's not whole reason. As I wrote down, without it, swap_readpage > waits the IO completion for a long time by blk_poll so it causes system > sluggish problem when device is slow(e.g., zram with backing device). Sure, this is problem #1. But slow swap device probably doesn't do any irreversible harm to the system. Unlike use-after-free, which does. Thus use-after-free is a problem #0. BDI_CAP_SYNCHRONOUS_IO comment doesn't mention problem #0; it talks about problem #1 only. So, nothing serious, just wanted to point that out. So we probably can make ZRAM always ASYNC when WB is enabled. Or... maybe we can make swap out to be SYNC and perform WB in background. In __zram_bvec_write() we can always write compressed object to zmalloc, even the huge ones. Things to note: a) even when WB is enabled we still allocate huge classes b) even when WB is enabled we still may use those huge classes (consider a case when backing devices is full) So huge classes are still there and we still use them. So let's use them? For a huge object, after we stored it into zsmalloc, we can schedule a WB work, which would: a) write that particular object (page) to the backing device b) mark entry as WB entry c) remove object from zsmalloc, unlock necessary locks So swap in should either see object in zsmalloc or on backing device. How does this sound? And reading from a backing device can always be SYNC. Can it? Am I missing something? -ss
Re: [PATCH v5 4/6] KVM: X86: Implement PV IPIs send hypercall
On Thu, 2 Aug 2018 at 21:04, Paolo Bonzini wrote: > > On 23/07/2018 08:39, Wanpeng Li wrote: > > +Returns 0 if successfully delivery the IPIs and 1 if discarded. > > I'm changing this to > > "Returns the number of CPUs to which the IPIs were delivered successfully" > > with an obvious change to x86.c. Thanks Paolo! Regards, Wanpeng Li
Re: [PATCH v5 4/6] KVM: X86: Implement PV IPIs send hypercall
On Thu, 2 Aug 2018 at 21:04, Paolo Bonzini wrote: > > On 23/07/2018 08:39, Wanpeng Li wrote: > > +Returns 0 if successfully delivery the IPIs and 1 if discarded. > > I'm changing this to > > "Returns the number of CPUs to which the IPIs were delivered successfully" > > with an obvious change to x86.c. Thanks Paolo! Regards, Wanpeng Li
Re: [RFC 1/2] slub: Avoid trying to allocate memory on offline nodes
Hi,
On 08/02/2018 04:15 AM, Michal Hocko wrote:
On Wed 01-08-18 15:04:17, Jeremy Linton wrote:
[...]
@@ -2519,6 +2519,8 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t
gfpflags, int node,
if (unlikely(!node_match(page, searchnode))) {
stat(s, ALLOC_NODE_MISMATCH);
deactivate_slab(s, page, c->freelist, c);
+ if (!node_online(searchnode))
+ node = NUMA_NO_NODE;
goto new_slab;
This is inherently racy. Numa node can get offline at any point after
you check it here. Making it race free would involve some sort of
locking and I am not really convinced this is a good idea.
I spent some time looking/thinking about this, and i'm pretty sure its
not creating any new problems. But OTOH, I think the node_online() check
is probably a bit misleading as what we really want to assure is that
nodeNODE_DATA() so we don't deference null.
}
}
--
2.14.3
Re: [RFC 1/2] slub: Avoid trying to allocate memory on offline nodes
Hi,
On 08/02/2018 04:15 AM, Michal Hocko wrote:
On Wed 01-08-18 15:04:17, Jeremy Linton wrote:
[...]
@@ -2519,6 +2519,8 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t
gfpflags, int node,
if (unlikely(!node_match(page, searchnode))) {
stat(s, ALLOC_NODE_MISMATCH);
deactivate_slab(s, page, c->freelist, c);
+ if (!node_online(searchnode))
+ node = NUMA_NO_NODE;
goto new_slab;
This is inherently racy. Numa node can get offline at any point after
you check it here. Making it race free would involve some sort of
locking and I am not really convinced this is a good idea.
I spent some time looking/thinking about this, and i'm pretty sure its
not creating any new problems. But OTOH, I think the node_online() check
is probably a bit misleading as what we really want to assure is that
nodeNODE_DATA() so we don't deference null.
}
}
--
2.14.3
Re: [RFC 2/2] mm: harden alloc_pages code paths against bogus nodes
Hi,
On 08/02/2018 02:31 AM, Michal Hocko wrote:
On Wed 01-08-18 15:04:18, Jeremy Linton wrote:
Its possible to crash __alloc_pages_nodemask by passing it
bogus node ids. This is caused by NODE_DATA() returning null
(hopefully) when the requested node is offline. We can
harded against the basic case of a mostly valid node, that
isn't online by checking for null and failing prepare_alloc_pages.
But this then suggests we should also harden NODE_DATA() like this
#define NODE_DATA(nid) ( (nid) < MAX_NUMNODES ? node_data[(nid)] : NULL)
eventually this starts to add a bunch of generally uneeded checks
in some code paths that are called quite frequently.
But the page allocator is really a hot path and people will not be happy
to have yet another branch there. No code should really use invalid numa
node ids in the first place.
If I remember those bugs correctly then it was the arch code which was
doing something wrong. I would prefer that code to be fixed instead.
Yes, I think the consensus is that 2/2 should be dropped.
The arch code is being fixed (both cases) this patch set is just an
attempt to harden this code path against future failures like that so
that we get some warnings/ugly messages rather than early boot failures.
Thanks,
Signed-off-by: Jeremy Linton
---
include/linux/gfp.h | 2 ++
mm/page_alloc.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index a6afcec53795..17d70271c42e 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -436,6 +436,8 @@ static inline int gfp_zonelist(gfp_t flags)
*/
static inline struct zonelist *node_zonelist(int nid, gfp_t flags)
{
+ if (unlikely(!NODE_DATA(nid))) //VM_WARN_ON?
+ return NULL;
return NODE_DATA(nid)->node_zonelists + gfp_zonelist(flags);
}
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a790ef4be74e..3a3d9ac2662a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4306,6 +4306,8 @@ static inline bool prepare_alloc_pages(gfp_t gfp_mask,
unsigned int order,
{
ac->high_zoneidx = gfp_zone(gfp_mask);
ac->zonelist = node_zonelist(preferred_nid, gfp_mask);
+ if (!ac->zonelist)
+ return false;
ac->nodemask = nodemask;
ac->migratetype = gfpflags_to_migratetype(gfp_mask);
--
2.14.3
Re: [RFC 2/2] mm: harden alloc_pages code paths against bogus nodes
Hi,
On 08/02/2018 02:31 AM, Michal Hocko wrote:
On Wed 01-08-18 15:04:18, Jeremy Linton wrote:
Its possible to crash __alloc_pages_nodemask by passing it
bogus node ids. This is caused by NODE_DATA() returning null
(hopefully) when the requested node is offline. We can
harded against the basic case of a mostly valid node, that
isn't online by checking for null and failing prepare_alloc_pages.
But this then suggests we should also harden NODE_DATA() like this
#define NODE_DATA(nid) ( (nid) < MAX_NUMNODES ? node_data[(nid)] : NULL)
eventually this starts to add a bunch of generally uneeded checks
in some code paths that are called quite frequently.
But the page allocator is really a hot path and people will not be happy
to have yet another branch there. No code should really use invalid numa
node ids in the first place.
If I remember those bugs correctly then it was the arch code which was
doing something wrong. I would prefer that code to be fixed instead.
Yes, I think the consensus is that 2/2 should be dropped.
The arch code is being fixed (both cases) this patch set is just an
attempt to harden this code path against future failures like that so
that we get some warnings/ugly messages rather than early boot failures.
Thanks,
Signed-off-by: Jeremy Linton
---
include/linux/gfp.h | 2 ++
mm/page_alloc.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index a6afcec53795..17d70271c42e 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -436,6 +436,8 @@ static inline int gfp_zonelist(gfp_t flags)
*/
static inline struct zonelist *node_zonelist(int nid, gfp_t flags)
{
+ if (unlikely(!NODE_DATA(nid))) //VM_WARN_ON?
+ return NULL;
return NODE_DATA(nid)->node_zonelists + gfp_zonelist(flags);
}
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a790ef4be74e..3a3d9ac2662a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4306,6 +4306,8 @@ static inline bool prepare_alloc_pages(gfp_t gfp_mask,
unsigned int order,
{
ac->high_zoneidx = gfp_zone(gfp_mask);
ac->zonelist = node_zonelist(preferred_nid, gfp_mask);
+ if (!ac->zonelist)
+ return false;
ac->nodemask = nodemask;
ac->migratetype = gfpflags_to_migratetype(gfp_mask);
--
2.14.3
Re: [RFC 0/2] harden alloc_pages against bogus nid
Hi, On 08/01/2018 07:14 PM, Andrew Morton wrote: On Wed, 1 Aug 2018 17:56:46 -0500 Jeremy Linton wrote: Hi, On 08/01/2018 04:50 PM, Andrew Morton wrote: On Wed, 1 Aug 2018 15:04:16 -0500 Jeremy Linton wrote: The thread "avoid alloc memory on offline node" https://lkml.org/lkml/2018/6/7/251 Asked at one point why the kzalloc_node was crashing rather than returning memory from a valid node. The thread ended up fixing the immediate causes of the crash but left open the case of bad proximity values being in DSDT tables without corrisponding SRAT/SLIT entries as is happening on another machine. Its also easy to fix that, but we should also harden the allocator sufficiently that it doesn't crash when passed an invalid node id. There are a couple possible ways to do this, and i've attached two separate patches which individually fix that problem. The first detects the offline node before calling the new_slab code path when it becomes apparent that the allocation isn't going to succeed. The second actually hardens node_zonelist() and prepare_alloc_pages() in the face of NODE_DATA(nid) returning a NULL zonelist. This latter case happens if the node has never been initialized or is possibly out of range. There are other places (NODE_DATA & online_node) which should be checking if the node id's are > MAX_NUMNODES. What is it that leads to a caller requesting memory from an invalid node? A race against offlining? If so then that's a lack of appropriate locking, isn't it? There were a couple unrelated cases, both having to do with the PXN associated with a PCI port. The first case AFAIK, the domain wasn't really invalid if the entire SRAT was parsed and nodes created even when there weren't associated CPUs. The second case (a different machine) is simply a PXN value that is completely invalid (no associated SLIT/SRAT/etc entries) due to firmware making a mistake when a socket isn't populated. There have been a few other suggested or merged patches for the individual problems above, this set is just an attempt at avoiding a full crash if/when another similar problem happens. Please add the above info to the changelog. Sure. I don't see a problem with emitting a warning and then selecting a different node so we can keep running. But we do want that warning, so we can understand the root cause and fix it? Yes, we do want to know when an invalid id is passed, i will add the VM_WARN in the first one. The second one I wasn't sure about as failing prepare_alloc_pages() generates a couple of error messages, but the system then continues operation. I guess my question though is which method (or both/something else?) is the preferred way to harden this up? The first patch looked neater. Can we get a WARN_ON in there as well? Yes, Thanks,
Re: [RFC 0/2] harden alloc_pages against bogus nid
Hi, On 08/01/2018 07:14 PM, Andrew Morton wrote: On Wed, 1 Aug 2018 17:56:46 -0500 Jeremy Linton wrote: Hi, On 08/01/2018 04:50 PM, Andrew Morton wrote: On Wed, 1 Aug 2018 15:04:16 -0500 Jeremy Linton wrote: The thread "avoid alloc memory on offline node" https://lkml.org/lkml/2018/6/7/251 Asked at one point why the kzalloc_node was crashing rather than returning memory from a valid node. The thread ended up fixing the immediate causes of the crash but left open the case of bad proximity values being in DSDT tables without corrisponding SRAT/SLIT entries as is happening on another machine. Its also easy to fix that, but we should also harden the allocator sufficiently that it doesn't crash when passed an invalid node id. There are a couple possible ways to do this, and i've attached two separate patches which individually fix that problem. The first detects the offline node before calling the new_slab code path when it becomes apparent that the allocation isn't going to succeed. The second actually hardens node_zonelist() and prepare_alloc_pages() in the face of NODE_DATA(nid) returning a NULL zonelist. This latter case happens if the node has never been initialized or is possibly out of range. There are other places (NODE_DATA & online_node) which should be checking if the node id's are > MAX_NUMNODES. What is it that leads to a caller requesting memory from an invalid node? A race against offlining? If so then that's a lack of appropriate locking, isn't it? There were a couple unrelated cases, both having to do with the PXN associated with a PCI port. The first case AFAIK, the domain wasn't really invalid if the entire SRAT was parsed and nodes created even when there weren't associated CPUs. The second case (a different machine) is simply a PXN value that is completely invalid (no associated SLIT/SRAT/etc entries) due to firmware making a mistake when a socket isn't populated. There have been a few other suggested or merged patches for the individual problems above, this set is just an attempt at avoiding a full crash if/when another similar problem happens. Please add the above info to the changelog. Sure. I don't see a problem with emitting a warning and then selecting a different node so we can keep running. But we do want that warning, so we can understand the root cause and fix it? Yes, we do want to know when an invalid id is passed, i will add the VM_WARN in the first one. The second one I wasn't sure about as failing prepare_alloc_pages() generates a couple of error messages, but the system then continues operation. I guess my question though is which method (or both/something else?) is the preferred way to harden this up? The first patch looked neater. Can we get a WARN_ON in there as well? Yes, Thanks,
Re: [PATCH 1/4] genirq: Provide basic NMI management for interrupt lines
On Thu, Aug 02, 2018 at 11:40:55AM +0200, Thomas Gleixner wrote: > On Thu, 2 Aug 2018, Marc Zyngier wrote: > > On Thu, 02 Aug 2018 07:55:49 +0100, > > Thomas Gleixner wrote: > > > > > > On Thu, 2 Aug 2018, Marc Zyngier wrote: > > > > > > > > If we need to distinguish between the two, then we need two flags. One > > > > that indicates the generation capability, and one that indicates the > > > > forwarding capability. > > > > > > There is absolutely no reason to expose this on x86, really. > > > > > > Why? > > > > > > Because NMI is an utter trainwreck on x86. It's a single entry point > > > without the ability of differentiation from which source the NMI > > > originated. So mapping it to anything generic is just not going to work. > > > > > > It has absolutely nothing to do with the normal way of vector based > > > interrupt operation and I don't see at all how adding this just because > > > would improve anything on x86. In fact it would create more problems than > > > it solves. > > > > Fair enough. Does it mean Julien can completely ignore the x86 > > requirements for this and focus on something that fit the need of > > architectures where (pseudo-)NMIs can be managed similarly to normal > > interrupts (arm, arm64, sparc...)? > > Yes, focussing on "sane" architectures (by some definition of sane) where > the NMI mode is just changing the delivery restrictions allows to still > differentiate from which source the NMI originates. Let me assume that one can find a way to reliably identify the source of an NMI in x86. If we cannot use the proposed request_nmi() as it does not fit x86, is it acceptable to bypass the existing irq framework and directly program the delivery mode as NMI in the relevant hardware (e.g., a register holding the MSI data)? For instance, in my initial attempt to have the HPET timer to generate NMIs [1]. I could directly write to the FSB Interrupt Route Register. In my view, it makes sense because, as you say, in x86 NMIs are handled separately from the normal vector based interrupts. I guess this would also imply reserving the relevant hardware so that it is not used when calling request_irq(). Thanks and BR, Ricardo [1]. https://lore.kernel.org/patchwork/cover/953394/
Re: [PATCH 1/4] genirq: Provide basic NMI management for interrupt lines
On Thu, Aug 02, 2018 at 11:40:55AM +0200, Thomas Gleixner wrote: > On Thu, 2 Aug 2018, Marc Zyngier wrote: > > On Thu, 02 Aug 2018 07:55:49 +0100, > > Thomas Gleixner wrote: > > > > > > On Thu, 2 Aug 2018, Marc Zyngier wrote: > > > > > > > > If we need to distinguish between the two, then we need two flags. One > > > > that indicates the generation capability, and one that indicates the > > > > forwarding capability. > > > > > > There is absolutely no reason to expose this on x86, really. > > > > > > Why? > > > > > > Because NMI is an utter trainwreck on x86. It's a single entry point > > > without the ability of differentiation from which source the NMI > > > originated. So mapping it to anything generic is just not going to work. > > > > > > It has absolutely nothing to do with the normal way of vector based > > > interrupt operation and I don't see at all how adding this just because > > > would improve anything on x86. In fact it would create more problems than > > > it solves. > > > > Fair enough. Does it mean Julien can completely ignore the x86 > > requirements for this and focus on something that fit the need of > > architectures where (pseudo-)NMIs can be managed similarly to normal > > interrupts (arm, arm64, sparc...)? > > Yes, focussing on "sane" architectures (by some definition of sane) where > the NMI mode is just changing the delivery restrictions allows to still > differentiate from which source the NMI originates. Let me assume that one can find a way to reliably identify the source of an NMI in x86. If we cannot use the proposed request_nmi() as it does not fit x86, is it acceptable to bypass the existing irq framework and directly program the delivery mode as NMI in the relevant hardware (e.g., a register holding the MSI data)? For instance, in my initial attempt to have the HPET timer to generate NMIs [1]. I could directly write to the FSB Interrupt Route Register. In my view, it makes sense because, as you say, in x86 NMIs are handled separately from the normal vector based interrupts. I guess this would also imply reserving the relevant hardware so that it is not used when calling request_irq(). Thanks and BR, Ricardo [1]. https://lore.kernel.org/patchwork/cover/953394/
Re: [RFC 1/2] slub: Avoid trying to allocate memory on offline nodes
Hi,
On 08/02/2018 09:23 AM, Christopher Lameter wrote:
On Wed, 1 Aug 2018, Jeremy Linton wrote:
diff --git a/mm/slub.c b/mm/slub.c
index 51258eff4178..e03719bac1e2 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2519,6 +2519,8 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t
gfpflags, int node,
if (unlikely(!node_match(page, searchnode))) {
stat(s, ALLOC_NODE_MISMATCH);
deactivate_slab(s, page, c->freelist, c);
+ if (!node_online(searchnode))
+ node = NUMA_NO_NODE;
goto new_slab;
}
}
Would it not be better to implement this check in the page allocator?
There is also the issue of how to fallback to the nearest node.
Possibly? Falling back to the nearest node though, should be handled if
memory-less nodes is enabled, which in the problematic case isn't.
NUMA_NO_NODE should fallback to the current memory allocation policy but
it seems by inserting it here you would end up just with the default node
for the processor.
I picked this spot (compared to 2/2) because a number of paths are
funneling through here, and in this case it shouldn't be a very hot path.
Re: [RFC 1/2] slub: Avoid trying to allocate memory on offline nodes
Hi,
On 08/02/2018 09:23 AM, Christopher Lameter wrote:
On Wed, 1 Aug 2018, Jeremy Linton wrote:
diff --git a/mm/slub.c b/mm/slub.c
index 51258eff4178..e03719bac1e2 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2519,6 +2519,8 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t
gfpflags, int node,
if (unlikely(!node_match(page, searchnode))) {
stat(s, ALLOC_NODE_MISMATCH);
deactivate_slab(s, page, c->freelist, c);
+ if (!node_online(searchnode))
+ node = NUMA_NO_NODE;
goto new_slab;
}
}
Would it not be better to implement this check in the page allocator?
There is also the issue of how to fallback to the nearest node.
Possibly? Falling back to the nearest node though, should be handled if
memory-less nodes is enabled, which in the problematic case isn't.
NUMA_NO_NODE should fallback to the current memory allocation policy but
it seems by inserting it here you would end up just with the default node
for the processor.
I picked this spot (compared to 2/2) because a number of paths are
funneling through here, and in this case it shouldn't be a very hot path.
[PATCH v2 12/18] serial: intel: Rename fpiclk to freqclk
Rename fpiclk to freqclk.
Signed-off-by: Songjun Wu
---
Changes in v2: None
drivers/tty/serial/lantiq.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 2e1b35b1cf4d..28086d52e980 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -106,7 +106,7 @@ static DEFINE_SPINLOCK(ltq_asc_lock);
struct ltq_uart_port {
struct uart_portport;
/* clock used to derive divider */
- struct clk *fpiclk;
+ struct clk *freqclk;
/* clock gating of the ASC core */
struct clk *clk;
unsigned inttx_irq;
@@ -310,7 +310,7 @@ lqasc_startup(struct uart_port *port)
if (!IS_ERR(ltq_port->clk))
clk_enable(ltq_port->clk);
- port->uartclk = clk_get_rate(ltq_port->fpiclk);
+ port->uartclk = clk_get_rate(ltq_port->freqclk);
asc_update_bits(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
port->membase + LTQ_ASC_CLC);
@@ -633,7 +633,7 @@ lqasc_console_setup(struct console *co, char *options)
if (!IS_ERR(ltq_port->clk))
clk_enable(ltq_port->clk);
- port->uartclk = clk_get_rate(ltq_port->fpiclk);
+ port->uartclk = clk_get_rate(ltq_port->freqclk);
if (options)
uart_parse_options(options, , , , );
@@ -744,8 +744,8 @@ lqasc_probe(struct platform_device *pdev)
port->irq = irqres[0].start;
port->mapbase = mmres->start;
- ltq_port->fpiclk = clk_get_fpi();
- if (IS_ERR(ltq_port->fpiclk)) {
+ ltq_port->freqclk = clk_get_fpi();
+ if (IS_ERR(ltq_port->freqclk)) {
pr_err("failed to get fpi clk\n");
return -ENOENT;
}
--
2.11.0
[PATCH v2 12/18] serial: intel: Rename fpiclk to freqclk
Rename fpiclk to freqclk.
Signed-off-by: Songjun Wu
---
Changes in v2: None
drivers/tty/serial/lantiq.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 2e1b35b1cf4d..28086d52e980 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -106,7 +106,7 @@ static DEFINE_SPINLOCK(ltq_asc_lock);
struct ltq_uart_port {
struct uart_portport;
/* clock used to derive divider */
- struct clk *fpiclk;
+ struct clk *freqclk;
/* clock gating of the ASC core */
struct clk *clk;
unsigned inttx_irq;
@@ -310,7 +310,7 @@ lqasc_startup(struct uart_port *port)
if (!IS_ERR(ltq_port->clk))
clk_enable(ltq_port->clk);
- port->uartclk = clk_get_rate(ltq_port->fpiclk);
+ port->uartclk = clk_get_rate(ltq_port->freqclk);
asc_update_bits(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
port->membase + LTQ_ASC_CLC);
@@ -633,7 +633,7 @@ lqasc_console_setup(struct console *co, char *options)
if (!IS_ERR(ltq_port->clk))
clk_enable(ltq_port->clk);
- port->uartclk = clk_get_rate(ltq_port->fpiclk);
+ port->uartclk = clk_get_rate(ltq_port->freqclk);
if (options)
uart_parse_options(options, , , , );
@@ -744,8 +744,8 @@ lqasc_probe(struct platform_device *pdev)
port->irq = irqres[0].start;
port->mapbase = mmres->start;
- ltq_port->fpiclk = clk_get_fpi();
- if (IS_ERR(ltq_port->fpiclk)) {
+ ltq_port->freqclk = clk_get_fpi();
+ if (IS_ERR(ltq_port->freqclk)) {
pr_err("failed to get fpi clk\n");
return -ENOENT;
}
--
2.11.0
[PATCH v2 17/18] serial: intel: Change init_lqasc to static declaration
init_lqasc() is only used internally, change to static declaration.
Signed-off-by: Songjun Wu
---
Changes in v2: None
drivers/tty/serial/lantiq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 804aad60ed80..2bb8e37e6886 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -788,7 +788,7 @@ static struct platform_driver lqasc_driver = {
},
};
-int __init
+static int __init
init_lqasc(void)
{
int ret;
--
2.11.0
[PATCH v2 18/18] dt-bindings: serial: lantiq: Add optional properties for CCF
Clocks and clock-names are updated in device tree binding.
Signed-off-by: Songjun Wu
---
Changes in v2: None
Documentation/devicetree/bindings/serial/lantiq_asc.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
index 3acbd309ab9d..40e81a5818f6 100644
--- a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
+++ b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
@@ -6,8 +6,23 @@ Required properties:
- interrupts: the 3 (tx rx err) interrupt numbers. The interrupt specifier
depends on the interrupt-parent interrupt controller.
+Optional properties:
+- clocks: Should contain frequency clock and gate clock
+- clock-names: Should be "freq" and "asc"
+
Example:
+asc0: serial@1660 {
+ compatible = "lantiq,asc";
+ reg = <0x1660 0x10>;
+ interrupt-parent = <>;
+ interrupts = ,
+ ,
+ ;
+ clocks = < CLK_SSX4>, < GCLK_UART>;
+ clock-names = "freq", "asc";
+};
+
asc1: serial@e100c00 {
compatible = "lantiq,asc";
reg = <0xE100C00 0x400>;
--
2.11.0
[PATCH v2 17/18] serial: intel: Change init_lqasc to static declaration
init_lqasc() is only used internally, change to static declaration.
Signed-off-by: Songjun Wu
---
Changes in v2: None
drivers/tty/serial/lantiq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 804aad60ed80..2bb8e37e6886 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -788,7 +788,7 @@ static struct platform_driver lqasc_driver = {
},
};
-int __init
+static int __init
init_lqasc(void)
{
int ret;
--
2.11.0
[PATCH v2 18/18] dt-bindings: serial: lantiq: Add optional properties for CCF
Clocks and clock-names are updated in device tree binding.
Signed-off-by: Songjun Wu
---
Changes in v2: None
Documentation/devicetree/bindings/serial/lantiq_asc.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
index 3acbd309ab9d..40e81a5818f6 100644
--- a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
+++ b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
@@ -6,8 +6,23 @@ Required properties:
- interrupts: the 3 (tx rx err) interrupt numbers. The interrupt specifier
depends on the interrupt-parent interrupt controller.
+Optional properties:
+- clocks: Should contain frequency clock and gate clock
+- clock-names: Should be "freq" and "asc"
+
Example:
+asc0: serial@1660 {
+ compatible = "lantiq,asc";
+ reg = <0x1660 0x10>;
+ interrupt-parent = <>;
+ interrupts = ,
+ ,
+ ;
+ clocks = < CLK_SSX4>, < GCLK_UART>;
+ clock-names = "freq", "asc";
+};
+
asc1: serial@e100c00 {
compatible = "lantiq,asc";
reg = <0xE100C00 0x400>;
--
2.11.0
[PATCH v2 14/18] serial: intel: Add CCF support
Previous implementation uses platform-dependent API to get the clock.
Those functions are not available for other SoC which uses the same IP.
The CCF (Common Clock Framework) have an abstraction based APIs for
clock. In future, the platform specific code will be removed when the
legacy soc use CCF as well.
Change to use CCF APIs to get clock and rate. So that different SoCs
can use the same driver.
Signed-off-by: Songjun Wu
---
Changes in v2: None
drivers/tty/serial/lantiq.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 36479d66fb7c..35518ab3a80d 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -26,7 +26,9 @@
#include
#include
+#ifdef CONFIG_LANTIQ
#include
+#endif
#define PORT_LTQ_ASC 111
#define MAXPORTS 2
@@ -744,14 +746,23 @@ lqasc_probe(struct platform_device *pdev)
port->irq = irqres[0].start;
port->mapbase = mmres->start;
+#if (IS_ENABLED(CONFIG_LANTIQ) && !IS_ENABLED(CONFIG_COMMON_CLK))
ltq_port->freqclk = clk_get_fpi();
+#else
+ ltq_port->freqclk = devm_clk_get(>dev, "freq");
+#endif
+
if (IS_ERR(ltq_port->freqclk)) {
pr_err("failed to get fpi clk\n");
return -ENOENT;
}
/* not all asc ports have clock gates, lets ignore the return code */
+#if (IS_ENABLED(CONFIG_LANTIQ) && !IS_ENABLED(CONFIG_COMMON_CLK))
ltq_port->clk = clk_get(>dev, NULL);
+#else
+ ltq_port->clk = devm_clk_get(>dev, "asc");
+#endif
ltq_port->tx_irq = irqres[0].start;
ltq_port->rx_irq = irqres[1].start;
--
2.11.0
[PATCH v2 07/18] MIPS: dts: Add aliases node for lantiq danube serial
Previous implementation uses a hard-coded register value to check
if the current serial entity is the console entity.
Now the lantiq serial driver uses the aliases for the index of the
serial port.
The lantiq danube serial dts are updated with aliases to support this.
Signed-off-by: Songjun Wu
---
Changes in v2: None
arch/mips/boot/dts/lantiq/danube.dtsi | 2 +-
arch/mips/boot/dts/lantiq/easy50712.dts | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/mips/boot/dts/lantiq/danube.dtsi
b/arch/mips/boot/dts/lantiq/danube.dtsi
index 510be63c8bdf..73746d7577d7 100644
--- a/arch/mips/boot/dts/lantiq/danube.dtsi
+++ b/arch/mips/boot/dts/lantiq/danube.dtsi
@@ -74,7 +74,7 @@
reg = <0xe100a00 0x100>;
};
- serial@e100c00 {
+ asc1: serial@e100c00 {
compatible = "lantiq,asc";
reg = <0xe100c00 0x400>;
interrupt-parent = <>;
diff --git a/arch/mips/boot/dts/lantiq/easy50712.dts
b/arch/mips/boot/dts/lantiq/easy50712.dts
index 1ce20b7d05cb..452860ca1868 100644
--- a/arch/mips/boot/dts/lantiq/easy50712.dts
+++ b/arch/mips/boot/dts/lantiq/easy50712.dts
@@ -4,6 +4,10 @@
/include/ "danube.dtsi"
/ {
+ aliases {
+ serial0 =
+ };
+
chosen {
bootargs = "console=ttyLTQ0,115200 init=/etc/preinit";
};
--
2.11.0
[PATCH v2 09/18] serial: intel: Change ltq_w32_mask to asc_update_bits
ltq prefix is platform specific function, asc prefix
is more generic.
Signed-off-by: Songjun Wu
---
Changes in v2: None
drivers/tty/serial/lantiq.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 836ca51460f2..e36e6a267e7a 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -114,6 +114,13 @@ struct ltq_uart_port {
unsigned interr_irq;
};
+static inline void asc_update_bits(u32 clear, u32 set, void __iomem *reg)
+{
+ u32 tmp = readl(reg);
+
+ writel((tmp & ~clear) | set, reg);
+}
+
static inline struct
ltq_uart_port *to_ltq_uart_port(struct uart_port *port)
{
@@ -164,16 +171,16 @@ lqasc_rx_chars(struct uart_port *port)
if (rsr & ASCSTATE_ANY) {
if (rsr & ASCSTATE_PE) {
port->icount.parity++;
- ltq_w32_mask(0, ASCWHBSTATE_CLRPE,
+ asc_update_bits(0, ASCWHBSTATE_CLRPE,
port->membase + LTQ_ASC_WHBSTATE);
} else if (rsr & ASCSTATE_FE) {
port->icount.frame++;
- ltq_w32_mask(0, ASCWHBSTATE_CLRFE,
+ asc_update_bits(0, ASCWHBSTATE_CLRFE,
port->membase + LTQ_ASC_WHBSTATE);
}
if (rsr & ASCSTATE_ROE) {
port->icount.overrun++;
- ltq_w32_mask(0, ASCWHBSTATE_CLRROE,
+ asc_update_bits(0, ASCWHBSTATE_CLRROE,
port->membase + LTQ_ASC_WHBSTATE);
}
@@ -253,7 +260,7 @@ lqasc_err_int(int irq, void *_port)
struct uart_port *port = (struct uart_port *)_port;
spin_lock_irqsave(_asc_lock, flags);
/* clear any pending interrupts */
- ltq_w32_mask(0, ASCWHBSTATE_CLRPE | ASCWHBSTATE_CLRFE |
+ asc_update_bits(0, ASCWHBSTATE_CLRPE | ASCWHBSTATE_CLRFE |
ASCWHBSTATE_CLRROE, port->membase + LTQ_ASC_WHBSTATE);
spin_unlock_irqrestore(_asc_lock, flags);
return IRQ_HANDLED;
@@ -305,7 +312,7 @@ lqasc_startup(struct uart_port *port)
clk_enable(ltq_port->clk);
port->uartclk = clk_get_rate(ltq_port->fpiclk);
- ltq_w32_mask(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
+ asc_update_bits(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
port->membase + LTQ_ASC_CLC);
ltq_w32(0, port->membase + LTQ_ASC_PISEL);
@@ -321,7 +328,7 @@ lqasc_startup(struct uart_port *port)
* setting enable bits
*/
wmb();
- ltq_w32_mask(0, ASCCON_M_8ASYNC | ASCCON_FEN | ASCCON_TOEN |
+ asc_update_bits(0, ASCCON_M_8ASYNC | ASCCON_FEN | ASCCON_TOEN |
ASCCON_ROEN, port->membase + LTQ_ASC_CON);
retval = request_irq(ltq_port->tx_irq, lqasc_tx_int,
@@ -365,9 +372,9 @@ lqasc_shutdown(struct uart_port *port)
free_irq(ltq_port->err_irq, port);
ltq_w32(0, port->membase + LTQ_ASC_CON);
- ltq_w32_mask(ASCRXFCON_RXFEN, ASCRXFCON_RXFFLU,
+ asc_update_bits(ASCRXFCON_RXFEN, ASCRXFCON_RXFFLU,
port->membase + LTQ_ASC_RXFCON);
- ltq_w32_mask(ASCTXFCON_TXFEN, ASCTXFCON_TXFFLU,
+ asc_update_bits(ASCTXFCON_TXFEN, ASCTXFCON_TXFFLU,
port->membase + LTQ_ASC_TXFCON);
if (!IS_ERR(ltq_port->clk))
clk_disable(ltq_port->clk);
@@ -439,7 +446,7 @@ lqasc_set_termios(struct uart_port *port,
spin_lock_irqsave(_asc_lock, flags);
/* set up CON */
- ltq_w32_mask(0, con, port->membase + LTQ_ASC_CON);
+ asc_update_bits(0, con, port->membase + LTQ_ASC_CON);
/* Set baud rate - take a divider of 2 into account */
baud = uart_get_baud_rate(port, new, old, 0, port->uartclk / 16);
@@ -447,19 +454,19 @@ lqasc_set_termios(struct uart_port *port,
divisor = divisor / 2 - 1;
/* disable the baudrate generator */
- ltq_w32_mask(ASCCON_R, 0, port->membase + LTQ_ASC_CON);
+ asc_update_bits(ASCCON_R, 0, port->membase + LTQ_ASC_CON);
/* make sure the fractional divider is off */
- ltq_w32_mask(ASCCON_FDE, 0, port->membase + LTQ_ASC_CON);
+ asc_update_bits(ASCCON_FDE, 0, port->membase + LTQ_ASC_CON);
/* set up to use divisor of 2 */
- ltq_w32_mask(ASCCON_BRS, 0, port->membase + LTQ_ASC_CON);
+ asc_update_bits(ASCCON_BRS, 0, port->membase + LTQ_ASC_CON);
/* now we can write the new baudrate into the register */
ltq_w32(divisor, port->membase + LTQ_ASC_BG);
/* turn the baudrate generator back on */
- ltq_w32_mask(0, ASCCON_R, port->membase + LTQ_ASC_CON);
+
[PATCH v2 15/18] serial: intel: Support more platform
Support more platform. Signed-off-by: Songjun Wu --- Changes in v2: None drivers/tty/serial/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index df8bd0c7b97d..564c71fc24bb 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1062,7 +1062,7 @@ config SERIAL_OMAP_CONSOLE config SERIAL_LANTIQ bool "Lantiq serial driver" - depends on LANTIQ + depends on LANTIQ || INTEL_MIPS || COMPILE_TEST select SERIAL_CORE select SERIAL_CORE_CONSOLE select SERIAL_EARLYCON -- 2.11.0
[PATCH v2 11/18] serial: intel: Use readl/writel instead of ltq_r32/ltq_w32
Previous implementation uses platform-dependent functions
ltq_w32()/ltq_r32() to access registers. Those functions are not
available for other SoC which uses the same IP.
Change to OS provided readl()/writel() and readb()/writeb(), so
that different SoCs can use the same driver.
Signed-off-by: Songjun Wu
---
Changes in v2: None
drivers/tty/serial/lantiq.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index e36e6a267e7a..2e1b35b1cf4d 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -146,7 +146,7 @@ lqasc_start_tx(struct uart_port *port)
static void
lqasc_stop_rx(struct uart_port *port)
{
- ltq_w32(ASCWHBSTATE_CLRREN, port->membase + LTQ_ASC_WHBSTATE);
+ writel(ASCWHBSTATE_CLRREN, port->membase + LTQ_ASC_WHBSTATE);
}
static int
@@ -155,11 +155,11 @@ lqasc_rx_chars(struct uart_port *port)
struct tty_port *tport = >state->port;
unsigned int ch = 0, rsr = 0, fifocnt;
- fifocnt = ltq_r32(port->membase + LTQ_ASC_FSTAT) & ASCFSTAT_RXFFLMASK;
+ fifocnt = readl(port->membase + LTQ_ASC_FSTAT) & ASCFSTAT_RXFFLMASK;
while (fifocnt--) {
u8 flag = TTY_NORMAL;
- ch = ltq_r8(port->membase + LTQ_ASC_RBUF);
- rsr = (ltq_r32(port->membase + LTQ_ASC_STATE)
+ ch = readb(port->membase + LTQ_ASC_RBUF);
+ rsr = (readl(port->membase + LTQ_ASC_STATE)
& ASCSTATE_ANY) | UART_DUMMY_UER_RX;
tty_flip_buffer_push(tport);
port->icount.rx++;
@@ -219,10 +219,10 @@ lqasc_tx_chars(struct uart_port *port)
return;
}
- while (((ltq_r32(port->membase + LTQ_ASC_FSTAT) &
+ while (((readl(port->membase + LTQ_ASC_FSTAT) &
ASCFSTAT_TXFREEMASK) >> ASCFSTAT_TXFREEOFF) != 0) {
if (port->x_char) {
- ltq_w8(port->x_char, port->membase + LTQ_ASC_TBUF);
+ writeb(port->x_char, port->membase + LTQ_ASC_TBUF);
port->icount.tx++;
port->x_char = 0;
continue;
@@ -231,7 +231,7 @@ lqasc_tx_chars(struct uart_port *port)
if (uart_circ_empty(xmit))
break;
- ltq_w8(port->state->xmit.buf[port->state->xmit.tail],
+ writeb(port->state->xmit.buf[port->state->xmit.tail],
port->membase + LTQ_ASC_TBUF);
xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
port->icount.tx++;
@@ -247,7 +247,7 @@ lqasc_tx_int(int irq, void *_port)
unsigned long flags;
struct uart_port *port = (struct uart_port *)_port;
spin_lock_irqsave(_asc_lock, flags);
- ltq_w32(ASC_IRNCR_TIR, port->membase + LTQ_ASC_IRNCR);
+ writel(ASC_IRNCR_TIR, port->membase + LTQ_ASC_IRNCR);
spin_unlock_irqrestore(_asc_lock, flags);
lqasc_start_tx(port);
return IRQ_HANDLED;
@@ -272,7 +272,7 @@ lqasc_rx_int(int irq, void *_port)
unsigned long flags;
struct uart_port *port = (struct uart_port *)_port;
spin_lock_irqsave(_asc_lock, flags);
- ltq_w32(ASC_IRNCR_RIR, port->membase + LTQ_ASC_IRNCR);
+ writel(ASC_IRNCR_RIR, port->membase + LTQ_ASC_IRNCR);
lqasc_rx_chars(port);
spin_unlock_irqrestore(_asc_lock, flags);
return IRQ_HANDLED;
@@ -282,7 +282,7 @@ static unsigned int
lqasc_tx_empty(struct uart_port *port)
{
int status;
- status = ltq_r32(port->membase + LTQ_ASC_FSTAT) & ASCFSTAT_TXFFLMASK;
+ status = readl(port->membase + LTQ_ASC_FSTAT) & ASCFSTAT_TXFFLMASK;
return status ? 0 : TIOCSER_TEMT;
}
@@ -315,12 +315,12 @@ lqasc_startup(struct uart_port *port)
asc_update_bits(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
port->membase + LTQ_ASC_CLC);
- ltq_w32(0, port->membase + LTQ_ASC_PISEL);
- ltq_w32(
+ writel(0, port->membase + LTQ_ASC_PISEL);
+ writel(
((TXFIFO_FL << ASCTXFCON_TXFITLOFF) & ASCTXFCON_TXFITLMASK) |
ASCTXFCON_TXFEN | ASCTXFCON_TXFFLU,
port->membase + LTQ_ASC_TXFCON);
- ltq_w32(
+ writel(
((RXFIFO_FL << ASCRXFCON_RXFITLOFF) & ASCRXFCON_RXFITLMASK)
| ASCRXFCON_RXFEN | ASCRXFCON_RXFFLU,
port->membase + LTQ_ASC_RXFCON);
@@ -352,7 +352,7 @@ lqasc_startup(struct uart_port *port)
goto err2;
}
- ltq_w32(ASC_IRNREN_RX | ASC_IRNREN_ERR | ASC_IRNREN_TX,
+ writel(ASC_IRNREN_RX | ASC_IRNREN_ERR | ASC_IRNREN_TX,
port->membase + LTQ_ASC_IRNREN);
return 0;
@@ -371,7 +371,7 @@ lqasc_shutdown(struct uart_port *port)
free_irq(ltq_port->rx_irq, port);
free_irq(ltq_port->err_irq, port);
-
[PATCH v2 14/18] serial: intel: Add CCF support
Previous implementation uses platform-dependent API to get the clock.
Those functions are not available for other SoC which uses the same IP.
The CCF (Common Clock Framework) have an abstraction based APIs for
clock. In future, the platform specific code will be removed when the
legacy soc use CCF as well.
Change to use CCF APIs to get clock and rate. So that different SoCs
can use the same driver.
Signed-off-by: Songjun Wu
---
Changes in v2: None
drivers/tty/serial/lantiq.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 36479d66fb7c..35518ab3a80d 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -26,7 +26,9 @@
#include
#include
+#ifdef CONFIG_LANTIQ
#include
+#endif
#define PORT_LTQ_ASC 111
#define MAXPORTS 2
@@ -744,14 +746,23 @@ lqasc_probe(struct platform_device *pdev)
port->irq = irqres[0].start;
port->mapbase = mmres->start;
+#if (IS_ENABLED(CONFIG_LANTIQ) && !IS_ENABLED(CONFIG_COMMON_CLK))
ltq_port->freqclk = clk_get_fpi();
+#else
+ ltq_port->freqclk = devm_clk_get(>dev, "freq");
+#endif
+
if (IS_ERR(ltq_port->freqclk)) {
pr_err("failed to get fpi clk\n");
return -ENOENT;
}
/* not all asc ports have clock gates, lets ignore the return code */
+#if (IS_ENABLED(CONFIG_LANTIQ) && !IS_ENABLED(CONFIG_COMMON_CLK))
ltq_port->clk = clk_get(>dev, NULL);
+#else
+ ltq_port->clk = devm_clk_get(>dev, "asc");
+#endif
ltq_port->tx_irq = irqres[0].start;
ltq_port->rx_irq = irqres[1].start;
--
2.11.0
[PATCH v2 07/18] MIPS: dts: Add aliases node for lantiq danube serial
Previous implementation uses a hard-coded register value to check
if the current serial entity is the console entity.
Now the lantiq serial driver uses the aliases for the index of the
serial port.
The lantiq danube serial dts are updated with aliases to support this.
Signed-off-by: Songjun Wu
---
Changes in v2: None
arch/mips/boot/dts/lantiq/danube.dtsi | 2 +-
arch/mips/boot/dts/lantiq/easy50712.dts | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/mips/boot/dts/lantiq/danube.dtsi
b/arch/mips/boot/dts/lantiq/danube.dtsi
index 510be63c8bdf..73746d7577d7 100644
--- a/arch/mips/boot/dts/lantiq/danube.dtsi
+++ b/arch/mips/boot/dts/lantiq/danube.dtsi
@@ -74,7 +74,7 @@
reg = <0xe100a00 0x100>;
};
- serial@e100c00 {
+ asc1: serial@e100c00 {
compatible = "lantiq,asc";
reg = <0xe100c00 0x400>;
interrupt-parent = <>;
diff --git a/arch/mips/boot/dts/lantiq/easy50712.dts
b/arch/mips/boot/dts/lantiq/easy50712.dts
index 1ce20b7d05cb..452860ca1868 100644
--- a/arch/mips/boot/dts/lantiq/easy50712.dts
+++ b/arch/mips/boot/dts/lantiq/easy50712.dts
@@ -4,6 +4,10 @@
/include/ "danube.dtsi"
/ {
+ aliases {
+ serial0 =
+ };
+
chosen {
bootargs = "console=ttyLTQ0,115200 init=/etc/preinit";
};
--
2.11.0
[PATCH v2 09/18] serial: intel: Change ltq_w32_mask to asc_update_bits
ltq prefix is platform specific function, asc prefix
is more generic.
Signed-off-by: Songjun Wu
---
Changes in v2: None
drivers/tty/serial/lantiq.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 836ca51460f2..e36e6a267e7a 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -114,6 +114,13 @@ struct ltq_uart_port {
unsigned interr_irq;
};
+static inline void asc_update_bits(u32 clear, u32 set, void __iomem *reg)
+{
+ u32 tmp = readl(reg);
+
+ writel((tmp & ~clear) | set, reg);
+}
+
static inline struct
ltq_uart_port *to_ltq_uart_port(struct uart_port *port)
{
@@ -164,16 +171,16 @@ lqasc_rx_chars(struct uart_port *port)
if (rsr & ASCSTATE_ANY) {
if (rsr & ASCSTATE_PE) {
port->icount.parity++;
- ltq_w32_mask(0, ASCWHBSTATE_CLRPE,
+ asc_update_bits(0, ASCWHBSTATE_CLRPE,
port->membase + LTQ_ASC_WHBSTATE);
} else if (rsr & ASCSTATE_FE) {
port->icount.frame++;
- ltq_w32_mask(0, ASCWHBSTATE_CLRFE,
+ asc_update_bits(0, ASCWHBSTATE_CLRFE,
port->membase + LTQ_ASC_WHBSTATE);
}
if (rsr & ASCSTATE_ROE) {
port->icount.overrun++;
- ltq_w32_mask(0, ASCWHBSTATE_CLRROE,
+ asc_update_bits(0, ASCWHBSTATE_CLRROE,
port->membase + LTQ_ASC_WHBSTATE);
}
@@ -253,7 +260,7 @@ lqasc_err_int(int irq, void *_port)
struct uart_port *port = (struct uart_port *)_port;
spin_lock_irqsave(_asc_lock, flags);
/* clear any pending interrupts */
- ltq_w32_mask(0, ASCWHBSTATE_CLRPE | ASCWHBSTATE_CLRFE |
+ asc_update_bits(0, ASCWHBSTATE_CLRPE | ASCWHBSTATE_CLRFE |
ASCWHBSTATE_CLRROE, port->membase + LTQ_ASC_WHBSTATE);
spin_unlock_irqrestore(_asc_lock, flags);
return IRQ_HANDLED;
@@ -305,7 +312,7 @@ lqasc_startup(struct uart_port *port)
clk_enable(ltq_port->clk);
port->uartclk = clk_get_rate(ltq_port->fpiclk);
- ltq_w32_mask(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
+ asc_update_bits(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
port->membase + LTQ_ASC_CLC);
ltq_w32(0, port->membase + LTQ_ASC_PISEL);
@@ -321,7 +328,7 @@ lqasc_startup(struct uart_port *port)
* setting enable bits
*/
wmb();
- ltq_w32_mask(0, ASCCON_M_8ASYNC | ASCCON_FEN | ASCCON_TOEN |
+ asc_update_bits(0, ASCCON_M_8ASYNC | ASCCON_FEN | ASCCON_TOEN |
ASCCON_ROEN, port->membase + LTQ_ASC_CON);
retval = request_irq(ltq_port->tx_irq, lqasc_tx_int,
@@ -365,9 +372,9 @@ lqasc_shutdown(struct uart_port *port)
free_irq(ltq_port->err_irq, port);
ltq_w32(0, port->membase + LTQ_ASC_CON);
- ltq_w32_mask(ASCRXFCON_RXFEN, ASCRXFCON_RXFFLU,
+ asc_update_bits(ASCRXFCON_RXFEN, ASCRXFCON_RXFFLU,
port->membase + LTQ_ASC_RXFCON);
- ltq_w32_mask(ASCTXFCON_TXFEN, ASCTXFCON_TXFFLU,
+ asc_update_bits(ASCTXFCON_TXFEN, ASCTXFCON_TXFFLU,
port->membase + LTQ_ASC_TXFCON);
if (!IS_ERR(ltq_port->clk))
clk_disable(ltq_port->clk);
@@ -439,7 +446,7 @@ lqasc_set_termios(struct uart_port *port,
spin_lock_irqsave(_asc_lock, flags);
/* set up CON */
- ltq_w32_mask(0, con, port->membase + LTQ_ASC_CON);
+ asc_update_bits(0, con, port->membase + LTQ_ASC_CON);
/* Set baud rate - take a divider of 2 into account */
baud = uart_get_baud_rate(port, new, old, 0, port->uartclk / 16);
@@ -447,19 +454,19 @@ lqasc_set_termios(struct uart_port *port,
divisor = divisor / 2 - 1;
/* disable the baudrate generator */
- ltq_w32_mask(ASCCON_R, 0, port->membase + LTQ_ASC_CON);
+ asc_update_bits(ASCCON_R, 0, port->membase + LTQ_ASC_CON);
/* make sure the fractional divider is off */
- ltq_w32_mask(ASCCON_FDE, 0, port->membase + LTQ_ASC_CON);
+ asc_update_bits(ASCCON_FDE, 0, port->membase + LTQ_ASC_CON);
/* set up to use divisor of 2 */
- ltq_w32_mask(ASCCON_BRS, 0, port->membase + LTQ_ASC_CON);
+ asc_update_bits(ASCCON_BRS, 0, port->membase + LTQ_ASC_CON);
/* now we can write the new baudrate into the register */
ltq_w32(divisor, port->membase + LTQ_ASC_BG);
/* turn the baudrate generator back on */
- ltq_w32_mask(0, ASCCON_R, port->membase + LTQ_ASC_CON);
+
[PATCH v2 15/18] serial: intel: Support more platform
Support more platform. Signed-off-by: Songjun Wu --- Changes in v2: None drivers/tty/serial/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index df8bd0c7b97d..564c71fc24bb 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1062,7 +1062,7 @@ config SERIAL_OMAP_CONSOLE config SERIAL_LANTIQ bool "Lantiq serial driver" - depends on LANTIQ + depends on LANTIQ || INTEL_MIPS || COMPILE_TEST select SERIAL_CORE select SERIAL_CORE_CONSOLE select SERIAL_EARLYCON -- 2.11.0
[PATCH v2 11/18] serial: intel: Use readl/writel instead of ltq_r32/ltq_w32
Previous implementation uses platform-dependent functions
ltq_w32()/ltq_r32() to access registers. Those functions are not
available for other SoC which uses the same IP.
Change to OS provided readl()/writel() and readb()/writeb(), so
that different SoCs can use the same driver.
Signed-off-by: Songjun Wu
---
Changes in v2: None
drivers/tty/serial/lantiq.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index e36e6a267e7a..2e1b35b1cf4d 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -146,7 +146,7 @@ lqasc_start_tx(struct uart_port *port)
static void
lqasc_stop_rx(struct uart_port *port)
{
- ltq_w32(ASCWHBSTATE_CLRREN, port->membase + LTQ_ASC_WHBSTATE);
+ writel(ASCWHBSTATE_CLRREN, port->membase + LTQ_ASC_WHBSTATE);
}
static int
@@ -155,11 +155,11 @@ lqasc_rx_chars(struct uart_port *port)
struct tty_port *tport = >state->port;
unsigned int ch = 0, rsr = 0, fifocnt;
- fifocnt = ltq_r32(port->membase + LTQ_ASC_FSTAT) & ASCFSTAT_RXFFLMASK;
+ fifocnt = readl(port->membase + LTQ_ASC_FSTAT) & ASCFSTAT_RXFFLMASK;
while (fifocnt--) {
u8 flag = TTY_NORMAL;
- ch = ltq_r8(port->membase + LTQ_ASC_RBUF);
- rsr = (ltq_r32(port->membase + LTQ_ASC_STATE)
+ ch = readb(port->membase + LTQ_ASC_RBUF);
+ rsr = (readl(port->membase + LTQ_ASC_STATE)
& ASCSTATE_ANY) | UART_DUMMY_UER_RX;
tty_flip_buffer_push(tport);
port->icount.rx++;
@@ -219,10 +219,10 @@ lqasc_tx_chars(struct uart_port *port)
return;
}
- while (((ltq_r32(port->membase + LTQ_ASC_FSTAT) &
+ while (((readl(port->membase + LTQ_ASC_FSTAT) &
ASCFSTAT_TXFREEMASK) >> ASCFSTAT_TXFREEOFF) != 0) {
if (port->x_char) {
- ltq_w8(port->x_char, port->membase + LTQ_ASC_TBUF);
+ writeb(port->x_char, port->membase + LTQ_ASC_TBUF);
port->icount.tx++;
port->x_char = 0;
continue;
@@ -231,7 +231,7 @@ lqasc_tx_chars(struct uart_port *port)
if (uart_circ_empty(xmit))
break;
- ltq_w8(port->state->xmit.buf[port->state->xmit.tail],
+ writeb(port->state->xmit.buf[port->state->xmit.tail],
port->membase + LTQ_ASC_TBUF);
xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
port->icount.tx++;
@@ -247,7 +247,7 @@ lqasc_tx_int(int irq, void *_port)
unsigned long flags;
struct uart_port *port = (struct uart_port *)_port;
spin_lock_irqsave(_asc_lock, flags);
- ltq_w32(ASC_IRNCR_TIR, port->membase + LTQ_ASC_IRNCR);
+ writel(ASC_IRNCR_TIR, port->membase + LTQ_ASC_IRNCR);
spin_unlock_irqrestore(_asc_lock, flags);
lqasc_start_tx(port);
return IRQ_HANDLED;
@@ -272,7 +272,7 @@ lqasc_rx_int(int irq, void *_port)
unsigned long flags;
struct uart_port *port = (struct uart_port *)_port;
spin_lock_irqsave(_asc_lock, flags);
- ltq_w32(ASC_IRNCR_RIR, port->membase + LTQ_ASC_IRNCR);
+ writel(ASC_IRNCR_RIR, port->membase + LTQ_ASC_IRNCR);
lqasc_rx_chars(port);
spin_unlock_irqrestore(_asc_lock, flags);
return IRQ_HANDLED;
@@ -282,7 +282,7 @@ static unsigned int
lqasc_tx_empty(struct uart_port *port)
{
int status;
- status = ltq_r32(port->membase + LTQ_ASC_FSTAT) & ASCFSTAT_TXFFLMASK;
+ status = readl(port->membase + LTQ_ASC_FSTAT) & ASCFSTAT_TXFFLMASK;
return status ? 0 : TIOCSER_TEMT;
}
@@ -315,12 +315,12 @@ lqasc_startup(struct uart_port *port)
asc_update_bits(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
port->membase + LTQ_ASC_CLC);
- ltq_w32(0, port->membase + LTQ_ASC_PISEL);
- ltq_w32(
+ writel(0, port->membase + LTQ_ASC_PISEL);
+ writel(
((TXFIFO_FL << ASCTXFCON_TXFITLOFF) & ASCTXFCON_TXFITLMASK) |
ASCTXFCON_TXFEN | ASCTXFCON_TXFFLU,
port->membase + LTQ_ASC_TXFCON);
- ltq_w32(
+ writel(
((RXFIFO_FL << ASCRXFCON_RXFITLOFF) & ASCRXFCON_RXFITLMASK)
| ASCRXFCON_RXFEN | ASCRXFCON_RXFFLU,
port->membase + LTQ_ASC_RXFCON);
@@ -352,7 +352,7 @@ lqasc_startup(struct uart_port *port)
goto err2;
}
- ltq_w32(ASC_IRNREN_RX | ASC_IRNREN_ERR | ASC_IRNREN_TX,
+ writel(ASC_IRNREN_RX | ASC_IRNREN_ERR | ASC_IRNREN_TX,
port->membase + LTQ_ASC_IRNREN);
return 0;
@@ -371,7 +371,7 @@ lqasc_shutdown(struct uart_port *port)
free_irq(ltq_port->rx_irq, port);
free_irq(ltq_port->err_irq, port);
-
[PATCH v2 16/18] serial: intel: Reorder the head files
Reorder the head files according to the coding style. Signed-off-by: Songjun Wu --- Changes in v2: - New patch to reorder the head files according to the coding style. drivers/tty/serial/lantiq.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c index 35518ab3a80d..804aad60ed80 100644 --- a/drivers/tty/serial/lantiq.c +++ b/drivers/tty/serial/lantiq.c @@ -9,22 +9,22 @@ * Copyright (C) 2018 Intel Corporation. */ -#include -#include -#include +#include #include -#include #include -#include -#include -#include -#include -#include +#include +#include +#include +#include #include #include -#include -#include -#include +#include +#include +#include +#include +#include +#include +#include #ifdef CONFIG_LANTIQ #include -- 2.11.0
[PATCH v2 06/18] MIPS: dts: Change upper case to lower case
All the upper case in unit-address and hex constants are
changed to lower case according to the Linux conventions.
Signed-off-by: Songjun Wu
---
Changes in v2: None
arch/mips/boot/dts/lantiq/danube.dtsi | 42 -
arch/mips/boot/dts/lantiq/easy50712.dts | 14 +--
2 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/mips/boot/dts/lantiq/danube.dtsi
b/arch/mips/boot/dts/lantiq/danube.dtsi
index 2dd950181f8a..510be63c8bdf 100644
--- a/arch/mips/boot/dts/lantiq/danube.dtsi
+++ b/arch/mips/boot/dts/lantiq/danube.dtsi
@@ -10,12 +10,12 @@
};
};
- biu@1F80 {
+ biu@1f80 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "lantiq,biu", "simple-bus";
- reg = <0x1F80 0x80>;
- ranges = <0x0 0x1F80 0x7F>;
+ reg = <0x1f80 0x80>;
+ ranges = <0x0 0x1f80 0x7f>;
icu0: icu@80200 {
#interrupt-cells = <1>;
@@ -24,18 +24,18 @@
reg = <0x80200 0x120>;
};
- watchdog@803F0 {
+ watchdog@803f0 {
compatible = "lantiq,wdt";
- reg = <0x803F0 0x10>;
+ reg = <0x803f0 0x10>;
};
};
- sram@1F00 {
+ sram@1f00 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "lantiq,sram";
- reg = <0x1F00 0x80>;
- ranges = <0x0 0x1F00 0x7F>;
+ reg = <0x1f00 0x80>;
+ ranges = <0x0 0x1f00 0x7f>;
eiu0: eiu@101000 {
#interrupt-cells = <1>;
@@ -66,41 +66,41 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "lantiq,fpi", "simple-bus";
- ranges = <0x0 0x1000 0xEEF>;
- reg = <0x1000 0xEF0>;
+ ranges = <0x0 0x1000 0xeef>;
+ reg = <0x1000 0xef0>;
- gptu@E100A00 {
+ gptu@e100a00 {
compatible = "lantiq,gptu-xway";
- reg = <0xE100A00 0x100>;
+ reg = <0xe100a00 0x100>;
};
- serial@E100C00 {
+ serial@e100c00 {
compatible = "lantiq,asc";
- reg = <0xE100C00 0x400>;
+ reg = <0xe100c00 0x400>;
interrupt-parent = <>;
interrupts = <112 113 114>;
};
- dma0: dma@E104100 {
+ dma0: dma@e104100 {
compatible = "lantiq,dma-xway";
- reg = <0xE104100 0x800>;
+ reg = <0xe104100 0x800>;
};
- ebu0: ebu@E105300 {
+ ebu0: ebu@e105300 {
compatible = "lantiq,ebu-xway";
- reg = <0xE105300 0x100>;
+ reg = <0xe105300 0x100>;
};
- pci0: pci@E105400 {
+ pci0: pci@e105400 {
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
compatible = "lantiq,pci-xway";
bus-range = <0x0 0x0>;
ranges = <0x200 0 0x800 0x800 0 0x200
/* pci memory */
- 0x100 0 0x 0xAE0 0 0x20>;
/* io space */
+ 0x100 0 0x 0xae0 0 0x20>;
/* io space */
reg = <0x700 0x8000 /* config space */
- 0xE105400 0x400>; /* pci bridge */
+ 0xe105400 0x400>; /* pci bridge */
};
};
};
diff --git a/arch/mips/boot/dts/lantiq/easy50712.dts
b/arch/mips/boot/dts/lantiq/easy50712.dts
index c37a33962f28..1ce20b7d05cb 100644
--- a/arch/mips/boot/dts/lantiq/easy50712.dts
+++ b/arch/mips/boot/dts/lantiq/easy50712.dts
@@ -52,14 +52,14 @@
};
};
- gpio: pinmux@E100B10 {
+ gpio: pinmux@e100b10 {
compatible = "lantiq,danube-pinctrl";
pinctrl-names = "default";
pinctrl-0 = <_default>;
#gpio-cells = <2>;
gpio-controller;
- reg = <0xE100B10 0xA0>;
+ reg = <0xe100b10 0xa0>;
state_default: pinmux {
stp {
@@ -82,26 +82,26 @@
};
[PATCH v2 13/18] serial: intel: Replace clk_enable/clk_disable with clk generic API
The clk driver has introduced new clock APIs that replace the existing clk_enable and clk_disable. -clk_enable() APIs is replaced with clk_prepare_enable(). -clk_disable() API is replaced with clk_disable_unprepare(). Signed-off-by: Songjun Wu --- Changes in v2: None drivers/tty/serial/lantiq.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c index 28086d52e980..36479d66fb7c 100644 --- a/drivers/tty/serial/lantiq.c +++ b/drivers/tty/serial/lantiq.c @@ -309,7 +309,7 @@ lqasc_startup(struct uart_port *port) int retval; if (!IS_ERR(ltq_port->clk)) - clk_enable(ltq_port->clk); + clk_prepare_enable(ltq_port->clk); port->uartclk = clk_get_rate(ltq_port->freqclk); asc_update_bits(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET), @@ -377,7 +377,7 @@ lqasc_shutdown(struct uart_port *port) asc_update_bits(ASCTXFCON_TXFEN, ASCTXFCON_TXFFLU, port->membase + LTQ_ASC_TXFCON); if (!IS_ERR(ltq_port->clk)) - clk_disable(ltq_port->clk); + clk_disable_unprepare(ltq_port->clk); } static void @@ -631,7 +631,7 @@ lqasc_console_setup(struct console *co, char *options) port = _port->port; if (!IS_ERR(ltq_port->clk)) - clk_enable(ltq_port->clk); + clk_prepare_enable(ltq_port->clk); port->uartclk = clk_get_rate(ltq_port->freqclk); -- 2.11.0
[PATCH v2 10/18] MIPS: lantiq: Unselect SWAP_IO_SPACE when LANTIQ is selected
SWAP_IO_SPACE macro prevents serial driver /drivers/tty/serial/lantiq.c to use readl/writel to replace ltq_r32/w32 which are SoC or platform specific APIs. readl/writel are used for this serial driver to support multiple platforms and multiple architectures. The legacy lantiq platform(Danube) enables SWAP_IO_SPACE for supporting PCI due to some hardware bugs. It's a little-endian bus plus PCI TX/RX swap enable impacted both data and control path for MIPS based platforms. But it is better to let PCI device driver to do endian swap since SWAP_IO_SPACE is a global wide macro which potentially impacts other peripheral like USB. ltq_r32/ltq_w32 is not impacted in other device drivers based on MIPS when SWAP_IO_SPACE is not selected as they use non-byte swapping OS API (__raw_read/__raw_writel). Signed-off-by: Songjun Wu --- Changes in v2: None arch/mips/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 2d34f17f3e24..2e7e0b538e52 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -400,7 +400,6 @@ config LANTIQ select SYS_SUPPORTS_VPE_LOADER select SYS_HAS_EARLY_PRINTK select GPIOLIB - select SWAP_IO_SPACE select BOOT_RAW select CLKDEV_LOOKUP select USE_OF -- 2.11.0
[PATCH v2 08/18] serial: intel: Get serial id from dts
Get serial id from dts.
"#ifdef CONFIG_LANTIQ" preprocessor is used because LTQ_EARLY_ASC
macro is defined in lantiq_soc.h.
lantiq_soc.h is in arch path for legacy product support.
arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h
If "#ifdef preprocessor" is changed to
"if (IS_ENABLED(CONFIG_LANTIQ))", when CONFIG_LANTIQ is not enabled,
code using LTQ_EARLY_ASC is compiled.
Compilation will fail for no LTQ_EARLY_ASC defined.
Signed-off-by: Songjun Wu
---
Changes in v2: None
drivers/tty/serial/lantiq.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 044128277248..836ca51460f2 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -6,6 +6,7 @@
* Copyright (C) 2007 Felix Fietkau
* Copyright (C) 2007 John Crispin
* Copyright (C) 2010 Thomas Langer,
+ * Copyright (C) 2018 Intel Corporation.
*/
#include
@@ -688,7 +689,7 @@ lqasc_probe(struct platform_device *pdev)
struct ltq_uart_port *ltq_port;
struct uart_port *port;
struct resource *mmres, irqres[3];
- int line = 0;
+ int line;
int ret;
mmres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -699,9 +700,19 @@ lqasc_probe(struct platform_device *pdev)
return -ENODEV;
}
- /* check if this is the console port */
- if (mmres->start != CPHYSADDR(LTQ_EARLY_ASC))
- line = 1;
+ /* get serial id */
+ line = of_alias_get_id(node, "serial");
+ if (line < 0) {
+#ifdef CONFIG_LANTIQ
+ if (mmres->start == CPHYSADDR(LTQ_EARLY_ASC))
+ line = 0;
+ else
+ line = 1;
+#else
+ dev_err(>dev, "failed to get alias id, errno %d\n", line);
+ return line;
+#endif
+ }
if (lqasc_port[line]) {
dev_err(>dev, "port %d already allocated\n", line);
--
2.11.0
[PATCH v2 16/18] serial: intel: Reorder the head files
Reorder the head files according to the coding style. Signed-off-by: Songjun Wu --- Changes in v2: - New patch to reorder the head files according to the coding style. drivers/tty/serial/lantiq.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c index 35518ab3a80d..804aad60ed80 100644 --- a/drivers/tty/serial/lantiq.c +++ b/drivers/tty/serial/lantiq.c @@ -9,22 +9,22 @@ * Copyright (C) 2018 Intel Corporation. */ -#include -#include -#include +#include #include -#include #include -#include -#include -#include -#include -#include +#include +#include +#include +#include #include #include -#include -#include -#include +#include +#include +#include +#include +#include +#include +#include #ifdef CONFIG_LANTIQ #include -- 2.11.0
[PATCH v2 06/18] MIPS: dts: Change upper case to lower case
All the upper case in unit-address and hex constants are
changed to lower case according to the Linux conventions.
Signed-off-by: Songjun Wu
---
Changes in v2: None
arch/mips/boot/dts/lantiq/danube.dtsi | 42 -
arch/mips/boot/dts/lantiq/easy50712.dts | 14 +--
2 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/mips/boot/dts/lantiq/danube.dtsi
b/arch/mips/boot/dts/lantiq/danube.dtsi
index 2dd950181f8a..510be63c8bdf 100644
--- a/arch/mips/boot/dts/lantiq/danube.dtsi
+++ b/arch/mips/boot/dts/lantiq/danube.dtsi
@@ -10,12 +10,12 @@
};
};
- biu@1F80 {
+ biu@1f80 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "lantiq,biu", "simple-bus";
- reg = <0x1F80 0x80>;
- ranges = <0x0 0x1F80 0x7F>;
+ reg = <0x1f80 0x80>;
+ ranges = <0x0 0x1f80 0x7f>;
icu0: icu@80200 {
#interrupt-cells = <1>;
@@ -24,18 +24,18 @@
reg = <0x80200 0x120>;
};
- watchdog@803F0 {
+ watchdog@803f0 {
compatible = "lantiq,wdt";
- reg = <0x803F0 0x10>;
+ reg = <0x803f0 0x10>;
};
};
- sram@1F00 {
+ sram@1f00 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "lantiq,sram";
- reg = <0x1F00 0x80>;
- ranges = <0x0 0x1F00 0x7F>;
+ reg = <0x1f00 0x80>;
+ ranges = <0x0 0x1f00 0x7f>;
eiu0: eiu@101000 {
#interrupt-cells = <1>;
@@ -66,41 +66,41 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "lantiq,fpi", "simple-bus";
- ranges = <0x0 0x1000 0xEEF>;
- reg = <0x1000 0xEF0>;
+ ranges = <0x0 0x1000 0xeef>;
+ reg = <0x1000 0xef0>;
- gptu@E100A00 {
+ gptu@e100a00 {
compatible = "lantiq,gptu-xway";
- reg = <0xE100A00 0x100>;
+ reg = <0xe100a00 0x100>;
};
- serial@E100C00 {
+ serial@e100c00 {
compatible = "lantiq,asc";
- reg = <0xE100C00 0x400>;
+ reg = <0xe100c00 0x400>;
interrupt-parent = <>;
interrupts = <112 113 114>;
};
- dma0: dma@E104100 {
+ dma0: dma@e104100 {
compatible = "lantiq,dma-xway";
- reg = <0xE104100 0x800>;
+ reg = <0xe104100 0x800>;
};
- ebu0: ebu@E105300 {
+ ebu0: ebu@e105300 {
compatible = "lantiq,ebu-xway";
- reg = <0xE105300 0x100>;
+ reg = <0xe105300 0x100>;
};
- pci0: pci@E105400 {
+ pci0: pci@e105400 {
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
compatible = "lantiq,pci-xway";
bus-range = <0x0 0x0>;
ranges = <0x200 0 0x800 0x800 0 0x200
/* pci memory */
- 0x100 0 0x 0xAE0 0 0x20>;
/* io space */
+ 0x100 0 0x 0xae0 0 0x20>;
/* io space */
reg = <0x700 0x8000 /* config space */
- 0xE105400 0x400>; /* pci bridge */
+ 0xe105400 0x400>; /* pci bridge */
};
};
};
diff --git a/arch/mips/boot/dts/lantiq/easy50712.dts
b/arch/mips/boot/dts/lantiq/easy50712.dts
index c37a33962f28..1ce20b7d05cb 100644
--- a/arch/mips/boot/dts/lantiq/easy50712.dts
+++ b/arch/mips/boot/dts/lantiq/easy50712.dts
@@ -52,14 +52,14 @@
};
};
- gpio: pinmux@E100B10 {
+ gpio: pinmux@e100b10 {
compatible = "lantiq,danube-pinctrl";
pinctrl-names = "default";
pinctrl-0 = <_default>;
#gpio-cells = <2>;
gpio-controller;
- reg = <0xE100B10 0xA0>;
+ reg = <0xe100b10 0xa0>;
state_default: pinmux {
stp {
@@ -82,26 +82,26 @@
};
[PATCH v2 13/18] serial: intel: Replace clk_enable/clk_disable with clk generic API
The clk driver has introduced new clock APIs that replace the existing clk_enable and clk_disable. -clk_enable() APIs is replaced with clk_prepare_enable(). -clk_disable() API is replaced with clk_disable_unprepare(). Signed-off-by: Songjun Wu --- Changes in v2: None drivers/tty/serial/lantiq.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c index 28086d52e980..36479d66fb7c 100644 --- a/drivers/tty/serial/lantiq.c +++ b/drivers/tty/serial/lantiq.c @@ -309,7 +309,7 @@ lqasc_startup(struct uart_port *port) int retval; if (!IS_ERR(ltq_port->clk)) - clk_enable(ltq_port->clk); + clk_prepare_enable(ltq_port->clk); port->uartclk = clk_get_rate(ltq_port->freqclk); asc_update_bits(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET), @@ -377,7 +377,7 @@ lqasc_shutdown(struct uart_port *port) asc_update_bits(ASCTXFCON_TXFEN, ASCTXFCON_TXFFLU, port->membase + LTQ_ASC_TXFCON); if (!IS_ERR(ltq_port->clk)) - clk_disable(ltq_port->clk); + clk_disable_unprepare(ltq_port->clk); } static void @@ -631,7 +631,7 @@ lqasc_console_setup(struct console *co, char *options) port = _port->port; if (!IS_ERR(ltq_port->clk)) - clk_enable(ltq_port->clk); + clk_prepare_enable(ltq_port->clk); port->uartclk = clk_get_rate(ltq_port->freqclk); -- 2.11.0
[PATCH v2 10/18] MIPS: lantiq: Unselect SWAP_IO_SPACE when LANTIQ is selected
SWAP_IO_SPACE macro prevents serial driver /drivers/tty/serial/lantiq.c to use readl/writel to replace ltq_r32/w32 which are SoC or platform specific APIs. readl/writel are used for this serial driver to support multiple platforms and multiple architectures. The legacy lantiq platform(Danube) enables SWAP_IO_SPACE for supporting PCI due to some hardware bugs. It's a little-endian bus plus PCI TX/RX swap enable impacted both data and control path for MIPS based platforms. But it is better to let PCI device driver to do endian swap since SWAP_IO_SPACE is a global wide macro which potentially impacts other peripheral like USB. ltq_r32/ltq_w32 is not impacted in other device drivers based on MIPS when SWAP_IO_SPACE is not selected as they use non-byte swapping OS API (__raw_read/__raw_writel). Signed-off-by: Songjun Wu --- Changes in v2: None arch/mips/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 2d34f17f3e24..2e7e0b538e52 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -400,7 +400,6 @@ config LANTIQ select SYS_SUPPORTS_VPE_LOADER select SYS_HAS_EARLY_PRINTK select GPIOLIB - select SWAP_IO_SPACE select BOOT_RAW select CLKDEV_LOOKUP select USE_OF -- 2.11.0
[PATCH v2 08/18] serial: intel: Get serial id from dts
Get serial id from dts.
"#ifdef CONFIG_LANTIQ" preprocessor is used because LTQ_EARLY_ASC
macro is defined in lantiq_soc.h.
lantiq_soc.h is in arch path for legacy product support.
arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h
If "#ifdef preprocessor" is changed to
"if (IS_ENABLED(CONFIG_LANTIQ))", when CONFIG_LANTIQ is not enabled,
code using LTQ_EARLY_ASC is compiled.
Compilation will fail for no LTQ_EARLY_ASC defined.
Signed-off-by: Songjun Wu
---
Changes in v2: None
drivers/tty/serial/lantiq.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 044128277248..836ca51460f2 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -6,6 +6,7 @@
* Copyright (C) 2007 Felix Fietkau
* Copyright (C) 2007 John Crispin
* Copyright (C) 2010 Thomas Langer,
+ * Copyright (C) 2018 Intel Corporation.
*/
#include
@@ -688,7 +689,7 @@ lqasc_probe(struct platform_device *pdev)
struct ltq_uart_port *ltq_port;
struct uart_port *port;
struct resource *mmres, irqres[3];
- int line = 0;
+ int line;
int ret;
mmres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -699,9 +700,19 @@ lqasc_probe(struct platform_device *pdev)
return -ENODEV;
}
- /* check if this is the console port */
- if (mmres->start != CPHYSADDR(LTQ_EARLY_ASC))
- line = 1;
+ /* get serial id */
+ line = of_alias_get_id(node, "serial");
+ if (line < 0) {
+#ifdef CONFIG_LANTIQ
+ if (mmres->start == CPHYSADDR(LTQ_EARLY_ASC))
+ line = 0;
+ else
+ line = 1;
+#else
+ dev_err(>dev, "failed to get alias id, errno %d\n", line);
+ return line;
+#endif
+ }
if (lqasc_port[line]) {
dev_err(>dev, "port %d already allocated\n", line);
--
2.11.0
[PATCH v2 05/18] dt-binding: MIPS: Add documentation of Intel MIPS SoCs
From: Hua Ma This patch adds binding documentation for the compatible values of the Intel MIPS SoCs. Signed-off-by: Hua Ma Signed-off-by: Songjun Wu --- Changes in v2: - New patch split from previous patch - Add the board and chip compatible in dt document Documentation/devicetree/bindings/mips/intel.txt | 17 + 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/mips/intel.txt diff --git a/Documentation/devicetree/bindings/mips/intel.txt b/Documentation/devicetree/bindings/mips/intel.txt new file mode 100644 index ..ac594ef303b7 --- /dev/null +++ b/Documentation/devicetree/bindings/mips/intel.txt @@ -0,0 +1,17 @@ +Intel MIPS SoC device tree bindings + +1, SoCs + +Each device tree must specify a compatible value for the Intel SoC +it uses in the compatible property of the root node. The compatible +value must be one of the following values: + + intel,xrx500 + +2, Boards + +Each device tree must specify a compatible value for the Intel Board +it uses in the compatible property of the root node. The compatible +value must be one of the following values: + + intel,easy350-anywan -- 2.11.0
[PATCH v2 03/18] dt-bindings: clk: Add documentation of grx500 clock controller
From: Yixin Zhu
This patch adds binding documentation for grx500 clock controller.
Signed-off-by: YiXin Zhu
Signed-off-by: Songjun Wu
---
Changes in v2:
- Rewrite clock driver's dt-binding document according to Rob Herring's
comments.
- Simplify device tree docoment, remove some clock description.
.../devicetree/bindings/clock/intel,grx500-clk.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
diff --git a/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
new file mode 100644
index ..e54e1dad9196
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
@@ -0,0 +1,39 @@
+Device Tree Clock bindings for grx500 PLL controller.
+
+This binding uses the common clock binding:
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The grx500 clock controller supplies clock to various controllers within the
+SoC.
+
+Required properties for clock node
+- compatible: Should be "intel,grx500-cgu".
+- reg: physical base address of the controller and length of memory range.
+- #clock-cells: should be 1.
+
+Optional Propteries:
+- intel,osc-frequency: frequency of the osc clock.
+if missing, driver will use clock rate defined in the driver.
+
+Example: Clock controller node:
+
+ cgu: cgu@1620 {
+compatible = "intel,grx500-cgu", "syscon";
+ reg = <0x1620 0x200>;
+ #clock-cells = <1>;
+ };
+
+
+Example: UART controller node that consumes the clock generated by clock
+ controller.
+
+ asc0: serial@1660 {
+ compatible = "lantiq,asc";
+ reg = <0x1660 0x10>;
+ interrupt-parent = <>;
+ interrupts = ,
+ ,
+ ;
+ clocks = < CLK_SSX4>, < GCLK_UART>;
+ clock-names = "freq", "asc";
+ };
--
2.11.0
[PATCH v2 04/18] MIPS: dts: Add initial support for Intel MIPS SoCs
From: Hua Ma
Add dts files to support Intel MIPS SoCs:
- xrx500.dtsi is the chip dts
- easy350_anywan.dts is the board dts
Signed-off-by: Hua Ma
Signed-off-by: Songjun Wu
---
Changes in v2:
- New patch split from previous patch
- The memory address is changed to @2000
- Update to obj-$(CONFIG_BUILTIN_DTB) as per commit fca3aa166422
arch/mips/boot/dts/Makefile | 1 +
arch/mips/boot/dts/intel-mips/Makefile | 4 ++
arch/mips/boot/dts/intel-mips/easy350_anywan.dts | 26 ++
arch/mips/boot/dts/intel-mips/xrx500.dtsi| 66
4 files changed, 97 insertions(+)
create mode 100644 arch/mips/boot/dts/intel-mips/Makefile
create mode 100644 arch/mips/boot/dts/intel-mips/easy350_anywan.dts
create mode 100644 arch/mips/boot/dts/intel-mips/xrx500.dtsi
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 1e79cab8e269..05f52f279047 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -3,6 +3,7 @@ subdir-y+= brcm
subdir-y += cavium-octeon
subdir-y += img
subdir-y += ingenic
+subdir-y += intel-mips
subdir-y += lantiq
subdir-y += mscc
subdir-y += mti
diff --git a/arch/mips/boot/dts/intel-mips/Makefile
b/arch/mips/boot/dts/intel-mips/Makefile
new file mode 100644
index ..adfaa07c
--- /dev/null
+++ b/arch/mips/boot/dts/intel-mips/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_DTB_INTEL_MIPS_GRX500)+= easy350_anywan.dtb
+
+obj-$(CONFIG_BUILTIN_DTB) += $(addsuffix .o, $(dtb-y))
diff --git a/arch/mips/boot/dts/intel-mips/easy350_anywan.dts
b/arch/mips/boot/dts/intel-mips/easy350_anywan.dts
new file mode 100644
index ..e5e95f90c5e7
--- /dev/null
+++ b/arch/mips/boot/dts/intel-mips/easy350_anywan.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include
+#include
+
+#include "xrx500.dtsi"
+
+/ {
+ model = "EASY350 ANYWAN (GRX350) Main model";
+ compatible = "intel,easy350-anywan";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ bootargs = "earlycon=lantiq,0x1660 clk_ignore_unused";
+ stdout-path = "serial0";
+ };
+
+ memory@2000 {
+ device_type = "memory";
+ reg = <0x2000 0x0e00>;
+ };
+};
diff --git a/arch/mips/boot/dts/intel-mips/xrx500.dtsi
b/arch/mips/boot/dts/intel-mips/xrx500.dtsi
new file mode 100644
index ..54c5f8f8b604
--- /dev/null
+++ b/arch/mips/boot/dts/intel-mips/xrx500.dtsi
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "intel,xrx500";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "mti,interaptiv";
+ clocks = < CLK_CPU>;
+ reg = <0>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "mti,interaptiv";
+ reg = <1>;
+ };
+ };
+
+ cpu_intc: interrupt-controller {
+ compatible = "mti,cpu-interrupt-controller";
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ gic: gic@1232 {
+ compatible = "mti,gic";
+ reg = <0x1232 0x2>;
+
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ /*
+* Declare the interrupt-parent even though the mti,gic
+* binding doesn't require it, such that the kernel can
+* figure out that cpu_intc is the root interrupt
+* controller & should be probed first.
+*/
+ interrupt-parent = <_intc>;
+ mti,reserved-ipi-vectors = <56 8>;
+ };
+
+ cgu: cgu@1620 {
+ compatible = "intel,grx500-cgu", "syscon";
+ reg = <0x1620 0x200>;
+ #clock-cells = <1>;
+ };
+
+ asc0: serial@1660 {
+ compatible = "lantiq,asc";
+ reg = <0x1660 0x10>;
+
+ interrupt-parent = <>;
+ interrupts = ,
+ ,
+ ;
+ clocks = < CLK_SSX4>, < GCLK_UART>;
+ clock-names = "freq", "asc";
+ };
+};
--
2.11.0
[PATCH v2 05/18] dt-binding: MIPS: Add documentation of Intel MIPS SoCs
From: Hua Ma This patch adds binding documentation for the compatible values of the Intel MIPS SoCs. Signed-off-by: Hua Ma Signed-off-by: Songjun Wu --- Changes in v2: - New patch split from previous patch - Add the board and chip compatible in dt document Documentation/devicetree/bindings/mips/intel.txt | 17 + 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/mips/intel.txt diff --git a/Documentation/devicetree/bindings/mips/intel.txt b/Documentation/devicetree/bindings/mips/intel.txt new file mode 100644 index ..ac594ef303b7 --- /dev/null +++ b/Documentation/devicetree/bindings/mips/intel.txt @@ -0,0 +1,17 @@ +Intel MIPS SoC device tree bindings + +1, SoCs + +Each device tree must specify a compatible value for the Intel SoC +it uses in the compatible property of the root node. The compatible +value must be one of the following values: + + intel,xrx500 + +2, Boards + +Each device tree must specify a compatible value for the Intel Board +it uses in the compatible property of the root node. The compatible +value must be one of the following values: + + intel,easy350-anywan -- 2.11.0
[PATCH v2 03/18] dt-bindings: clk: Add documentation of grx500 clock controller
From: Yixin Zhu
This patch adds binding documentation for grx500 clock controller.
Signed-off-by: YiXin Zhu
Signed-off-by: Songjun Wu
---
Changes in v2:
- Rewrite clock driver's dt-binding document according to Rob Herring's
comments.
- Simplify device tree docoment, remove some clock description.
.../devicetree/bindings/clock/intel,grx500-clk.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
diff --git a/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
new file mode 100644
index ..e54e1dad9196
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
@@ -0,0 +1,39 @@
+Device Tree Clock bindings for grx500 PLL controller.
+
+This binding uses the common clock binding:
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The grx500 clock controller supplies clock to various controllers within the
+SoC.
+
+Required properties for clock node
+- compatible: Should be "intel,grx500-cgu".
+- reg: physical base address of the controller and length of memory range.
+- #clock-cells: should be 1.
+
+Optional Propteries:
+- intel,osc-frequency: frequency of the osc clock.
+if missing, driver will use clock rate defined in the driver.
+
+Example: Clock controller node:
+
+ cgu: cgu@1620 {
+compatible = "intel,grx500-cgu", "syscon";
+ reg = <0x1620 0x200>;
+ #clock-cells = <1>;
+ };
+
+
+Example: UART controller node that consumes the clock generated by clock
+ controller.
+
+ asc0: serial@1660 {
+ compatible = "lantiq,asc";
+ reg = <0x1660 0x10>;
+ interrupt-parent = <>;
+ interrupts = ,
+ ,
+ ;
+ clocks = < CLK_SSX4>, < GCLK_UART>;
+ clock-names = "freq", "asc";
+ };
--
2.11.0
[PATCH v2 04/18] MIPS: dts: Add initial support for Intel MIPS SoCs
From: Hua Ma
Add dts files to support Intel MIPS SoCs:
- xrx500.dtsi is the chip dts
- easy350_anywan.dts is the board dts
Signed-off-by: Hua Ma
Signed-off-by: Songjun Wu
---
Changes in v2:
- New patch split from previous patch
- The memory address is changed to @2000
- Update to obj-$(CONFIG_BUILTIN_DTB) as per commit fca3aa166422
arch/mips/boot/dts/Makefile | 1 +
arch/mips/boot/dts/intel-mips/Makefile | 4 ++
arch/mips/boot/dts/intel-mips/easy350_anywan.dts | 26 ++
arch/mips/boot/dts/intel-mips/xrx500.dtsi| 66
4 files changed, 97 insertions(+)
create mode 100644 arch/mips/boot/dts/intel-mips/Makefile
create mode 100644 arch/mips/boot/dts/intel-mips/easy350_anywan.dts
create mode 100644 arch/mips/boot/dts/intel-mips/xrx500.dtsi
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 1e79cab8e269..05f52f279047 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -3,6 +3,7 @@ subdir-y+= brcm
subdir-y += cavium-octeon
subdir-y += img
subdir-y += ingenic
+subdir-y += intel-mips
subdir-y += lantiq
subdir-y += mscc
subdir-y += mti
diff --git a/arch/mips/boot/dts/intel-mips/Makefile
b/arch/mips/boot/dts/intel-mips/Makefile
new file mode 100644
index ..adfaa07c
--- /dev/null
+++ b/arch/mips/boot/dts/intel-mips/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_DTB_INTEL_MIPS_GRX500)+= easy350_anywan.dtb
+
+obj-$(CONFIG_BUILTIN_DTB) += $(addsuffix .o, $(dtb-y))
diff --git a/arch/mips/boot/dts/intel-mips/easy350_anywan.dts
b/arch/mips/boot/dts/intel-mips/easy350_anywan.dts
new file mode 100644
index ..e5e95f90c5e7
--- /dev/null
+++ b/arch/mips/boot/dts/intel-mips/easy350_anywan.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include
+#include
+
+#include "xrx500.dtsi"
+
+/ {
+ model = "EASY350 ANYWAN (GRX350) Main model";
+ compatible = "intel,easy350-anywan";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ bootargs = "earlycon=lantiq,0x1660 clk_ignore_unused";
+ stdout-path = "serial0";
+ };
+
+ memory@2000 {
+ device_type = "memory";
+ reg = <0x2000 0x0e00>;
+ };
+};
diff --git a/arch/mips/boot/dts/intel-mips/xrx500.dtsi
b/arch/mips/boot/dts/intel-mips/xrx500.dtsi
new file mode 100644
index ..54c5f8f8b604
--- /dev/null
+++ b/arch/mips/boot/dts/intel-mips/xrx500.dtsi
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "intel,xrx500";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "mti,interaptiv";
+ clocks = < CLK_CPU>;
+ reg = <0>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "mti,interaptiv";
+ reg = <1>;
+ };
+ };
+
+ cpu_intc: interrupt-controller {
+ compatible = "mti,cpu-interrupt-controller";
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ gic: gic@1232 {
+ compatible = "mti,gic";
+ reg = <0x1232 0x2>;
+
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ /*
+* Declare the interrupt-parent even though the mti,gic
+* binding doesn't require it, such that the kernel can
+* figure out that cpu_intc is the root interrupt
+* controller & should be probed first.
+*/
+ interrupt-parent = <_intc>;
+ mti,reserved-ipi-vectors = <56 8>;
+ };
+
+ cgu: cgu@1620 {
+ compatible = "intel,grx500-cgu", "syscon";
+ reg = <0x1620 0x200>;
+ #clock-cells = <1>;
+ };
+
+ asc0: serial@1660 {
+ compatible = "lantiq,asc";
+ reg = <0x1660 0x10>;
+
+ interrupt-parent = <>;
+ interrupts = ,
+ ,
+ ;
+ clocks = < CLK_SSX4>, < GCLK_UART>;
+ clock-names = "freq", "asc";
+ };
+};
--
2.11.0
[PATCH v2 00/18] MIPS: intel: add initial support for Intel MIPS SoCs
This patch series is for adding the support for Intel MIPS interAptiv SoC GRX500 family. It includes CCF support, serial driver optimization and DTS modification. This patch series is applied on top of linux v4.18-rc7. Basic verification is performed on GRX500 board. We propose merging this patch series into MIPS Linux tree. Changes in v2: - Remove unused _END macros - Remove the redundant check and not accurate comments - Replace the get_counter_resolution function with fixed value 2 - Use obj-y and split into per line per .o - Add EVA mapping description in code comments - Remove unused include header file - Do a clean-up for grx500_defconfig - Rewrite clock driver, add platform clock description details in clock driver. - Rewrite clock driver's dt-binding document according to Rob Herring's comments. - Simplify device tree docoment, remove some clock description. - New patch split from previous patch - The memory address is changed to @2000 - Update to obj-$(CONFIG_BUILTIN_DTB) as per commit fca3aa166422 - New patch split from previous patch - Add the board and chip compatible in dt document - New patch to reorder the head files according to the coding style. Hua Ma (3): MIPS: intel: Add initial support for Intel MIPS SoCs MIPS: dts: Add initial support for Intel MIPS SoCs dt-binding: MIPS: Add documentation of Intel MIPS SoCs Songjun Wu (13): MIPS: dts: Change upper case to lower case MIPS: dts: Add aliases node for lantiq danube serial serial: intel: Get serial id from dts serial: intel: Change ltq_w32_mask to asc_update_bits MIPS: lantiq: Unselect SWAP_IO_SPACE when LANTIQ is selected serial: intel: Use readl/writel instead of ltq_r32/ltq_w32 serial: intel: Rename fpiclk to freqclk serial: intel: Replace clk_enable/clk_disable with clk generic API serial: intel: Add CCF support serial: intel: Support more platform serial: intel: Reorder the head files serial: intel: Change init_lqasc to static declaration dt-bindings: serial: lantiq: Add optional properties for CCF Yixin Zhu (2): clk: intel: Add clock driver for Intel MIPS SoCs dt-bindings: clk: Add documentation of grx500 clock controller .../devicetree/bindings/clock/intel,grx500-clk.txt | 39 ++ Documentation/devicetree/bindings/mips/intel.txt | 17 + .../devicetree/bindings/serial/lantiq_asc.txt | 15 + arch/mips/Kbuild.platforms | 1 + arch/mips/Kconfig | 30 +- arch/mips/boot/dts/Makefile| 1 + arch/mips/boot/dts/intel-mips/Makefile | 4 + arch/mips/boot/dts/intel-mips/easy350_anywan.dts | 26 ++ arch/mips/boot/dts/intel-mips/xrx500.dtsi | 66 +++ arch/mips/boot/dts/lantiq/danube.dtsi | 42 +- arch/mips/boot/dts/lantiq/easy50712.dts| 18 +- arch/mips/configs/grx500_defconfig | 138 ++ .../asm/mach-intel-mips/cpu-feature-overrides.h| 61 +++ arch/mips/include/asm/mach-intel-mips/ioremap.h| 39 ++ arch/mips/include/asm/mach-intel-mips/irq.h| 17 + .../asm/mach-intel-mips/kernel-entry-init.h| 104 + arch/mips/include/asm/mach-intel-mips/spaces.h | 27 ++ arch/mips/include/asm/mach-intel-mips/war.h| 18 + arch/mips/intel-mips/Kconfig | 22 + arch/mips/intel-mips/Makefile | 5 + arch/mips/intel-mips/Platform | 12 + arch/mips/intel-mips/irq.c | 35 ++ arch/mips/intel-mips/prom.c| 172 arch/mips/intel-mips/time.c| 42 ++ drivers/clk/Kconfig| 1 + drivers/clk/Makefile | 3 + drivers/clk/intel/Kconfig | 20 + drivers/clk/intel/Makefile | 7 + drivers/clk/intel/clk-cgu-pll.c| 166 drivers/clk/intel/clk-cgu-pll.h| 34 ++ drivers/clk/intel/clk-cgu.c| 470 + drivers/clk/intel/clk-cgu.h| 259 drivers/clk/intel/clk-grx500.c | 168 drivers/tty/serial/Kconfig | 2 +- drivers/tty/serial/lantiq.c| 143 --- include/dt-bindings/clock/intel,grx500-clk.h | 69 +++ 36 files changed, 2206 insertions(+), 87 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/intel,grx500-clk.txt create mode 100644 Documentation/devicetree/bindings/mips/intel.txt create mode 100644 arch/mips/boot/dts/intel-mips/Makefile create mode 100644 arch/mips/boot/dts/intel-mips/easy350_anywan.dts create mode 100644 arch/mips/boot/dts/intel-mips/xrx500.dtsi create mode 100644 arch/mips/configs/grx500_defconfig create mode 100644 arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h create mode 100644
[PATCH v2 00/18] MIPS: intel: add initial support for Intel MIPS SoCs
This patch series is for adding the support for Intel MIPS interAptiv SoC GRX500 family. It includes CCF support, serial driver optimization and DTS modification. This patch series is applied on top of linux v4.18-rc7. Basic verification is performed on GRX500 board. We propose merging this patch series into MIPS Linux tree. Changes in v2: - Remove unused _END macros - Remove the redundant check and not accurate comments - Replace the get_counter_resolution function with fixed value 2 - Use obj-y and split into per line per .o - Add EVA mapping description in code comments - Remove unused include header file - Do a clean-up for grx500_defconfig - Rewrite clock driver, add platform clock description details in clock driver. - Rewrite clock driver's dt-binding document according to Rob Herring's comments. - Simplify device tree docoment, remove some clock description. - New patch split from previous patch - The memory address is changed to @2000 - Update to obj-$(CONFIG_BUILTIN_DTB) as per commit fca3aa166422 - New patch split from previous patch - Add the board and chip compatible in dt document - New patch to reorder the head files according to the coding style. Hua Ma (3): MIPS: intel: Add initial support for Intel MIPS SoCs MIPS: dts: Add initial support for Intel MIPS SoCs dt-binding: MIPS: Add documentation of Intel MIPS SoCs Songjun Wu (13): MIPS: dts: Change upper case to lower case MIPS: dts: Add aliases node for lantiq danube serial serial: intel: Get serial id from dts serial: intel: Change ltq_w32_mask to asc_update_bits MIPS: lantiq: Unselect SWAP_IO_SPACE when LANTIQ is selected serial: intel: Use readl/writel instead of ltq_r32/ltq_w32 serial: intel: Rename fpiclk to freqclk serial: intel: Replace clk_enable/clk_disable with clk generic API serial: intel: Add CCF support serial: intel: Support more platform serial: intel: Reorder the head files serial: intel: Change init_lqasc to static declaration dt-bindings: serial: lantiq: Add optional properties for CCF Yixin Zhu (2): clk: intel: Add clock driver for Intel MIPS SoCs dt-bindings: clk: Add documentation of grx500 clock controller .../devicetree/bindings/clock/intel,grx500-clk.txt | 39 ++ Documentation/devicetree/bindings/mips/intel.txt | 17 + .../devicetree/bindings/serial/lantiq_asc.txt | 15 + arch/mips/Kbuild.platforms | 1 + arch/mips/Kconfig | 30 +- arch/mips/boot/dts/Makefile| 1 + arch/mips/boot/dts/intel-mips/Makefile | 4 + arch/mips/boot/dts/intel-mips/easy350_anywan.dts | 26 ++ arch/mips/boot/dts/intel-mips/xrx500.dtsi | 66 +++ arch/mips/boot/dts/lantiq/danube.dtsi | 42 +- arch/mips/boot/dts/lantiq/easy50712.dts| 18 +- arch/mips/configs/grx500_defconfig | 138 ++ .../asm/mach-intel-mips/cpu-feature-overrides.h| 61 +++ arch/mips/include/asm/mach-intel-mips/ioremap.h| 39 ++ arch/mips/include/asm/mach-intel-mips/irq.h| 17 + .../asm/mach-intel-mips/kernel-entry-init.h| 104 + arch/mips/include/asm/mach-intel-mips/spaces.h | 27 ++ arch/mips/include/asm/mach-intel-mips/war.h| 18 + arch/mips/intel-mips/Kconfig | 22 + arch/mips/intel-mips/Makefile | 5 + arch/mips/intel-mips/Platform | 12 + arch/mips/intel-mips/irq.c | 35 ++ arch/mips/intel-mips/prom.c| 172 arch/mips/intel-mips/time.c| 42 ++ drivers/clk/Kconfig| 1 + drivers/clk/Makefile | 3 + drivers/clk/intel/Kconfig | 20 + drivers/clk/intel/Makefile | 7 + drivers/clk/intel/clk-cgu-pll.c| 166 drivers/clk/intel/clk-cgu-pll.h| 34 ++ drivers/clk/intel/clk-cgu.c| 470 + drivers/clk/intel/clk-cgu.h| 259 drivers/clk/intel/clk-grx500.c | 168 drivers/tty/serial/Kconfig | 2 +- drivers/tty/serial/lantiq.c| 143 --- include/dt-bindings/clock/intel,grx500-clk.h | 69 +++ 36 files changed, 2206 insertions(+), 87 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/intel,grx500-clk.txt create mode 100644 Documentation/devicetree/bindings/mips/intel.txt create mode 100644 arch/mips/boot/dts/intel-mips/Makefile create mode 100644 arch/mips/boot/dts/intel-mips/easy350_anywan.dts create mode 100644 arch/mips/boot/dts/intel-mips/xrx500.dtsi create mode 100644 arch/mips/configs/grx500_defconfig create mode 100644 arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h create mode 100644
[PATCH v2 02/18] clk: intel: Add clock driver for Intel MIPS SoCs
From: Yixin Zhu This driver provides PLL clock registration as well as various clock branches, e.g. MUX clock, gate clock, divider clock and so on. PLLs that provide clock to DDR, CPU and peripherals are shown below: +-+ |--->| LCPLL3 0|--PCIe clk--> XO |+-+ +---| |+-+ ||3|--PAE clk--> |--->| PLL0B 2|--GSWIP clk--> ||1|--DDR clk-->DDR PHY clk--> ||0|--CPU1 clk--+ +-+ |+-+|--->0| | | MUX |--CPU clk--> |+-+|--->1| ||0|--CPU0 clk--+ +-+ |--->| PLLOA 1|--SSX4 clk--> |2|--NGI clk--> |3|--CBM clk--> +-+ Signed-off-by: Yixin Zhu Signed-off-by: Songjun Wu --- Changes in v2: - Rewrite clock driver, add platform clock description details in clock driver. drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 3 + drivers/clk/intel/Kconfig| 20 ++ drivers/clk/intel/Makefile | 7 + drivers/clk/intel/clk-cgu-pll.c | 166 ++ drivers/clk/intel/clk-cgu-pll.h | 34 ++ drivers/clk/intel/clk-cgu.c | 470 +++ drivers/clk/intel/clk-cgu.h | 259 +++ drivers/clk/intel/clk-grx500.c | 168 ++ include/dt-bindings/clock/intel,grx500-clk.h | 69 10 files changed, 1197 insertions(+) create mode 100644 drivers/clk/intel/Kconfig create mode 100644 drivers/clk/intel/Makefile create mode 100644 drivers/clk/intel/clk-cgu-pll.c create mode 100644 drivers/clk/intel/clk-cgu-pll.h create mode 100644 drivers/clk/intel/clk-cgu.c create mode 100644 drivers/clk/intel/clk-cgu.h create mode 100644 drivers/clk/intel/clk-grx500.c create mode 100644 include/dt-bindings/clock/intel,grx500-clk.h diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 721572a8c429..5e0c1597b0d3 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -281,6 +281,7 @@ source "drivers/clk/actions/Kconfig" source "drivers/clk/bcm/Kconfig" source "drivers/clk/hisilicon/Kconfig" source "drivers/clk/imgtec/Kconfig" +source "drivers/clk/intel/Kconfig" source "drivers/clk/keystone/Kconfig" source "drivers/clk/mediatek/Kconfig" source "drivers/clk/meson/Kconfig" diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index 0bb25dd009d1..d929ca4607cf 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -72,6 +72,9 @@ obj-$(CONFIG_ARCH_HISI) += hisilicon/ obj-y += imgtec/ obj-$(CONFIG_ARCH_MXC) += imx/ obj-$(CONFIG_MACH_INGENIC) += ingenic/ +ifeq ($(CONFIG_COMMON_CLK), y) +obj-y +=intel/ +endif obj-$(CONFIG_ARCH_KEYSTONE)+= keystone/ obj-$(CONFIG_MACH_LOONGSON32) += loongson1/ obj-y += mediatek/ diff --git a/drivers/clk/intel/Kconfig b/drivers/clk/intel/Kconfig new file mode 100644 index ..c7d3fb1721fa --- /dev/null +++ b/drivers/clk/intel/Kconfig @@ -0,0 +1,20 @@ +# SPDX-License-Identifier: GPL-2.0 +config INTEL_CGU_CLK + depends on COMMON_CLK + depends on INTEL_MIPS || COMPILE_TEST + select MFD_SYSCON + bool "Intel clock controller support" + help + This driver support Intel CGU (Clock Generation Unit). + +choice + prompt "SoC platform selection" + depends on INTEL_CGU_CLK + default INTEL_GRX500_CGU_CLK + +config INTEL_GRX500_CGU_CLK + bool "GRX500 CLK" + help + Clock driver of GRX500 platform. + +endchoice diff --git a/drivers/clk/intel/Makefile b/drivers/clk/intel/Makefile new file mode 100644 index ..16a0138e52c2 --- /dev/null +++ b/drivers/clk/intel/Makefile @@ -0,0 +1,7 @@ +# SPDX-License-Identifier: GPL-2.0 +# Makefile for intel specific clk + +obj-$(CONFIG_INTEL_CGU_CLK) += clk-cgu.o clk-cgu-pll.o +ifneq ($(CONFIG_INTEL_GRX500_CGU_CLK),) + obj-y += clk-grx500.o +endif diff --git a/drivers/clk/intel/clk-cgu-pll.c b/drivers/clk/intel/clk-cgu-pll.c new file mode 100644 index ..20759bc27e95 --- /dev/null +++ b/drivers/clk/intel/clk-cgu-pll.c @@ -0,0 +1,166 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2018 Intel Corporation. + * Zhu YiXin + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include "clk-cgu-pll.h" +#include "clk-cgu.h" + +#define to_intel_clk_pll(_hw) container_of(_hw, struct intel_clk_pll, hw) + +/* + * Calculate formula: + * rate = (prate * mult + (prate * frac) / frac_div) / div + */ +static unsigned long
[PATCH v2 01/18] MIPS: intel: Add initial support for Intel MIPS SoCs
From: Hua Ma Add initial support for Intel MIPS interAptiv SoCs made by Intel. This series will add support for the grx500 family. The series allows booting a minimal system using a initramfs. Signed-off-by: Hua Ma Signed-off-by: Songjun Wu --- Changes in v2: - Remove unused _END macros - Remove the redundant check and not accurate comments - Replace the get_counter_resolution function with fixed value 2 - Use obj-y and split into per line per .o - Add EVA mapping description in code comments - Remove unused include header file - Do a clean-up for grx500_defconfig arch/mips/Kbuild.platforms | 1 + arch/mips/Kconfig | 29 arch/mips/configs/grx500_defconfig | 138 + .../asm/mach-intel-mips/cpu-feature-overrides.h| 61 arch/mips/include/asm/mach-intel-mips/ioremap.h| 39 + arch/mips/include/asm/mach-intel-mips/irq.h| 17 ++ .../asm/mach-intel-mips/kernel-entry-init.h| 104 + arch/mips/include/asm/mach-intel-mips/spaces.h | 27 arch/mips/include/asm/mach-intel-mips/war.h| 18 +++ arch/mips/intel-mips/Kconfig | 22 +++ arch/mips/intel-mips/Makefile | 5 + arch/mips/intel-mips/Platform | 12 ++ arch/mips/intel-mips/irq.c | 35 + arch/mips/intel-mips/prom.c| 172 + arch/mips/intel-mips/time.c| 42 + 15 files changed, 722 insertions(+) create mode 100644 arch/mips/configs/grx500_defconfig create mode 100644 arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h create mode 100644 arch/mips/include/asm/mach-intel-mips/ioremap.h create mode 100644 arch/mips/include/asm/mach-intel-mips/irq.h create mode 100644 arch/mips/include/asm/mach-intel-mips/kernel-entry-init.h create mode 100644 arch/mips/include/asm/mach-intel-mips/spaces.h create mode 100644 arch/mips/include/asm/mach-intel-mips/war.h create mode 100644 arch/mips/intel-mips/Kconfig create mode 100644 arch/mips/intel-mips/Makefile create mode 100644 arch/mips/intel-mips/Platform create mode 100644 arch/mips/intel-mips/irq.c create mode 100644 arch/mips/intel-mips/prom.c create mode 100644 arch/mips/intel-mips/time.c diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms index ac7ad54f984f..bcd647060f3e 100644 --- a/arch/mips/Kbuild.platforms +++ b/arch/mips/Kbuild.platforms @@ -12,6 +12,7 @@ platforms += cobalt platforms += dec platforms += emma platforms += generic +platforms += intel-mips platforms += jazz platforms += jz4740 platforms += lantiq diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 08c10c518f83..2d34f17f3e24 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -409,6 +409,34 @@ config LANTIQ select ARCH_HAS_RESET_CONTROLLER select RESET_CONTROLLER +config INTEL_MIPS + bool "Intel MIPS interAptiv SoC based platforms" + select BOOT_RAW + select CEVT_R4K + select COMMON_CLK + select CPU_MIPS32_3_5_EVA + select CPU_MIPS32_3_5_FEATURES + select CPU_MIPSR2_IRQ_EI + select CPU_MIPSR2_IRQ_VI + select CSRC_R4K + select DMA_NONCOHERENT + select GENERIC_ISA_DMA + select IRQ_MIPS_CPU + select MFD_CORE + select MFD_SYSCON + select MIPS_CPU_SCACHE + select MIPS_GIC + select SYS_HAS_CPU_MIPS32_R1 + select SYS_HAS_CPU_MIPS32_R2 + select SYS_HAS_CPU_MIPS32_R3_5 + select SYS_SUPPORTS_BIG_ENDIAN + select SYS_SUPPORTS_32BIT_KERNEL + select SYS_SUPPORTS_MIPS_CPS + select SYS_SUPPORTS_MULTITHREADING + select SYS_SUPPORTS_ZBOOT + select TIMER_OF + select USE_OF + config LASAT bool "LASAT Networks platforms" select CEVT_R4K @@ -1016,6 +1044,7 @@ source "arch/mips/bcm47xx/Kconfig" source "arch/mips/bcm63xx/Kconfig" source "arch/mips/bmips/Kconfig" source "arch/mips/generic/Kconfig" +source "arch/mips/intel-mips/Kconfig" source "arch/mips/jazz/Kconfig" source "arch/mips/jz4740/Kconfig" source "arch/mips/lantiq/Kconfig" diff --git a/arch/mips/configs/grx500_defconfig b/arch/mips/configs/grx500_defconfig new file mode 100644 index ..9dd7ba8e1f74 --- /dev/null +++ b/arch/mips/configs/grx500_defconfig @@ -0,0 +1,138 @@ +CONFIG_INTEL_MIPS=y +CONFIG_DTB_INTEL_MIPS_GRX500=y +CONFIG_CPU_MIPS32_R2=y +CONFIG_SCHED_SMT=y +# CONFIG_MIPS_MT_FPAFF is not set +CONFIG_MIPS_CPS=y +CONFIG_DEFAULT_MMAP_MIN_ADDR=65536 +CONFIG_NR_CPUS=2 +CONFIG_HZ_100=y +# CONFIG_SECCOMP is not set +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_DEFAULT_HOSTNAME="GRX500" +CONFIG_SYSVIPC=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_LOG_BUF_SHIFT=18 +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_RD_GZIP is not set +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +# CONFIG_RD_LZO is not set +#
[PATCH v2 02/18] clk: intel: Add clock driver for Intel MIPS SoCs
From: Yixin Zhu This driver provides PLL clock registration as well as various clock branches, e.g. MUX clock, gate clock, divider clock and so on. PLLs that provide clock to DDR, CPU and peripherals are shown below: +-+ |--->| LCPLL3 0|--PCIe clk--> XO |+-+ +---| |+-+ ||3|--PAE clk--> |--->| PLL0B 2|--GSWIP clk--> ||1|--DDR clk-->DDR PHY clk--> ||0|--CPU1 clk--+ +-+ |+-+|--->0| | | MUX |--CPU clk--> |+-+|--->1| ||0|--CPU0 clk--+ +-+ |--->| PLLOA 1|--SSX4 clk--> |2|--NGI clk--> |3|--CBM clk--> +-+ Signed-off-by: Yixin Zhu Signed-off-by: Songjun Wu --- Changes in v2: - Rewrite clock driver, add platform clock description details in clock driver. drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 3 + drivers/clk/intel/Kconfig| 20 ++ drivers/clk/intel/Makefile | 7 + drivers/clk/intel/clk-cgu-pll.c | 166 ++ drivers/clk/intel/clk-cgu-pll.h | 34 ++ drivers/clk/intel/clk-cgu.c | 470 +++ drivers/clk/intel/clk-cgu.h | 259 +++ drivers/clk/intel/clk-grx500.c | 168 ++ include/dt-bindings/clock/intel,grx500-clk.h | 69 10 files changed, 1197 insertions(+) create mode 100644 drivers/clk/intel/Kconfig create mode 100644 drivers/clk/intel/Makefile create mode 100644 drivers/clk/intel/clk-cgu-pll.c create mode 100644 drivers/clk/intel/clk-cgu-pll.h create mode 100644 drivers/clk/intel/clk-cgu.c create mode 100644 drivers/clk/intel/clk-cgu.h create mode 100644 drivers/clk/intel/clk-grx500.c create mode 100644 include/dt-bindings/clock/intel,grx500-clk.h diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 721572a8c429..5e0c1597b0d3 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -281,6 +281,7 @@ source "drivers/clk/actions/Kconfig" source "drivers/clk/bcm/Kconfig" source "drivers/clk/hisilicon/Kconfig" source "drivers/clk/imgtec/Kconfig" +source "drivers/clk/intel/Kconfig" source "drivers/clk/keystone/Kconfig" source "drivers/clk/mediatek/Kconfig" source "drivers/clk/meson/Kconfig" diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index 0bb25dd009d1..d929ca4607cf 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -72,6 +72,9 @@ obj-$(CONFIG_ARCH_HISI) += hisilicon/ obj-y += imgtec/ obj-$(CONFIG_ARCH_MXC) += imx/ obj-$(CONFIG_MACH_INGENIC) += ingenic/ +ifeq ($(CONFIG_COMMON_CLK), y) +obj-y +=intel/ +endif obj-$(CONFIG_ARCH_KEYSTONE)+= keystone/ obj-$(CONFIG_MACH_LOONGSON32) += loongson1/ obj-y += mediatek/ diff --git a/drivers/clk/intel/Kconfig b/drivers/clk/intel/Kconfig new file mode 100644 index ..c7d3fb1721fa --- /dev/null +++ b/drivers/clk/intel/Kconfig @@ -0,0 +1,20 @@ +# SPDX-License-Identifier: GPL-2.0 +config INTEL_CGU_CLK + depends on COMMON_CLK + depends on INTEL_MIPS || COMPILE_TEST + select MFD_SYSCON + bool "Intel clock controller support" + help + This driver support Intel CGU (Clock Generation Unit). + +choice + prompt "SoC platform selection" + depends on INTEL_CGU_CLK + default INTEL_GRX500_CGU_CLK + +config INTEL_GRX500_CGU_CLK + bool "GRX500 CLK" + help + Clock driver of GRX500 platform. + +endchoice diff --git a/drivers/clk/intel/Makefile b/drivers/clk/intel/Makefile new file mode 100644 index ..16a0138e52c2 --- /dev/null +++ b/drivers/clk/intel/Makefile @@ -0,0 +1,7 @@ +# SPDX-License-Identifier: GPL-2.0 +# Makefile for intel specific clk + +obj-$(CONFIG_INTEL_CGU_CLK) += clk-cgu.o clk-cgu-pll.o +ifneq ($(CONFIG_INTEL_GRX500_CGU_CLK),) + obj-y += clk-grx500.o +endif diff --git a/drivers/clk/intel/clk-cgu-pll.c b/drivers/clk/intel/clk-cgu-pll.c new file mode 100644 index ..20759bc27e95 --- /dev/null +++ b/drivers/clk/intel/clk-cgu-pll.c @@ -0,0 +1,166 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2018 Intel Corporation. + * Zhu YiXin + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include "clk-cgu-pll.h" +#include "clk-cgu.h" + +#define to_intel_clk_pll(_hw) container_of(_hw, struct intel_clk_pll, hw) + +/* + * Calculate formula: + * rate = (prate * mult + (prate * frac) / frac_div) / div + */ +static unsigned long
[PATCH v2 01/18] MIPS: intel: Add initial support for Intel MIPS SoCs
From: Hua Ma Add initial support for Intel MIPS interAptiv SoCs made by Intel. This series will add support for the grx500 family. The series allows booting a minimal system using a initramfs. Signed-off-by: Hua Ma Signed-off-by: Songjun Wu --- Changes in v2: - Remove unused _END macros - Remove the redundant check and not accurate comments - Replace the get_counter_resolution function with fixed value 2 - Use obj-y and split into per line per .o - Add EVA mapping description in code comments - Remove unused include header file - Do a clean-up for grx500_defconfig arch/mips/Kbuild.platforms | 1 + arch/mips/Kconfig | 29 arch/mips/configs/grx500_defconfig | 138 + .../asm/mach-intel-mips/cpu-feature-overrides.h| 61 arch/mips/include/asm/mach-intel-mips/ioremap.h| 39 + arch/mips/include/asm/mach-intel-mips/irq.h| 17 ++ .../asm/mach-intel-mips/kernel-entry-init.h| 104 + arch/mips/include/asm/mach-intel-mips/spaces.h | 27 arch/mips/include/asm/mach-intel-mips/war.h| 18 +++ arch/mips/intel-mips/Kconfig | 22 +++ arch/mips/intel-mips/Makefile | 5 + arch/mips/intel-mips/Platform | 12 ++ arch/mips/intel-mips/irq.c | 35 + arch/mips/intel-mips/prom.c| 172 + arch/mips/intel-mips/time.c| 42 + 15 files changed, 722 insertions(+) create mode 100644 arch/mips/configs/grx500_defconfig create mode 100644 arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h create mode 100644 arch/mips/include/asm/mach-intel-mips/ioremap.h create mode 100644 arch/mips/include/asm/mach-intel-mips/irq.h create mode 100644 arch/mips/include/asm/mach-intel-mips/kernel-entry-init.h create mode 100644 arch/mips/include/asm/mach-intel-mips/spaces.h create mode 100644 arch/mips/include/asm/mach-intel-mips/war.h create mode 100644 arch/mips/intel-mips/Kconfig create mode 100644 arch/mips/intel-mips/Makefile create mode 100644 arch/mips/intel-mips/Platform create mode 100644 arch/mips/intel-mips/irq.c create mode 100644 arch/mips/intel-mips/prom.c create mode 100644 arch/mips/intel-mips/time.c diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms index ac7ad54f984f..bcd647060f3e 100644 --- a/arch/mips/Kbuild.platforms +++ b/arch/mips/Kbuild.platforms @@ -12,6 +12,7 @@ platforms += cobalt platforms += dec platforms += emma platforms += generic +platforms += intel-mips platforms += jazz platforms += jz4740 platforms += lantiq diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 08c10c518f83..2d34f17f3e24 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -409,6 +409,34 @@ config LANTIQ select ARCH_HAS_RESET_CONTROLLER select RESET_CONTROLLER +config INTEL_MIPS + bool "Intel MIPS interAptiv SoC based platforms" + select BOOT_RAW + select CEVT_R4K + select COMMON_CLK + select CPU_MIPS32_3_5_EVA + select CPU_MIPS32_3_5_FEATURES + select CPU_MIPSR2_IRQ_EI + select CPU_MIPSR2_IRQ_VI + select CSRC_R4K + select DMA_NONCOHERENT + select GENERIC_ISA_DMA + select IRQ_MIPS_CPU + select MFD_CORE + select MFD_SYSCON + select MIPS_CPU_SCACHE + select MIPS_GIC + select SYS_HAS_CPU_MIPS32_R1 + select SYS_HAS_CPU_MIPS32_R2 + select SYS_HAS_CPU_MIPS32_R3_5 + select SYS_SUPPORTS_BIG_ENDIAN + select SYS_SUPPORTS_32BIT_KERNEL + select SYS_SUPPORTS_MIPS_CPS + select SYS_SUPPORTS_MULTITHREADING + select SYS_SUPPORTS_ZBOOT + select TIMER_OF + select USE_OF + config LASAT bool "LASAT Networks platforms" select CEVT_R4K @@ -1016,6 +1044,7 @@ source "arch/mips/bcm47xx/Kconfig" source "arch/mips/bcm63xx/Kconfig" source "arch/mips/bmips/Kconfig" source "arch/mips/generic/Kconfig" +source "arch/mips/intel-mips/Kconfig" source "arch/mips/jazz/Kconfig" source "arch/mips/jz4740/Kconfig" source "arch/mips/lantiq/Kconfig" diff --git a/arch/mips/configs/grx500_defconfig b/arch/mips/configs/grx500_defconfig new file mode 100644 index ..9dd7ba8e1f74 --- /dev/null +++ b/arch/mips/configs/grx500_defconfig @@ -0,0 +1,138 @@ +CONFIG_INTEL_MIPS=y +CONFIG_DTB_INTEL_MIPS_GRX500=y +CONFIG_CPU_MIPS32_R2=y +CONFIG_SCHED_SMT=y +# CONFIG_MIPS_MT_FPAFF is not set +CONFIG_MIPS_CPS=y +CONFIG_DEFAULT_MMAP_MIN_ADDR=65536 +CONFIG_NR_CPUS=2 +CONFIG_HZ_100=y +# CONFIG_SECCOMP is not set +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_DEFAULT_HOSTNAME="GRX500" +CONFIG_SYSVIPC=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_LOG_BUF_SHIFT=18 +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_RD_GZIP is not set +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +# CONFIG_RD_LZO is not set +#
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
Hi Sergey, On Fri, Aug 03, 2018 at 11:39:29AM +0900, Sergey Senozhatsky wrote: > On (08/02/18 14:13), Andrew Morton wrote: > [..] > > That changelog is rather hard to follow. Please review my edits: > > > > : If zram supports writeback feature, it's no longer a BD_CAP_SYNCHRONOUS_IO > ^BDI_CAP_SYNCHRONOUS_IO > > [..] > > > A reader looking at this would wonder "why the heck are we doing that". > > Adding a code comment would help them. > > The interesting thing here is that include/linux/backing-dev.h > BDI_CAP_SYNCHRONOUS_IO comment says > > "Device is so fast that asynchronous IO would be inefficient." > > Which is not the reason why BDI_CAP_SYNCHRONOUS_IO is used by ZRAM. > Probably, the comment needs to be updated as well. I couldn't catch your point. Could you clarify a little bit more? What do you want to correct for the comment? > > Both SWP_SYNCHRONOUS_IO and BDI_CAP_SYNCHRONOUS_IO tend to pivot > "efficiency" [looking at the comments], but in ZRAM's case the whole > reason to use SYNC IO is a race condition and user-after-free that > follows. Actually, it's not whole reason. As I wrote down, without it, swap_readpage waits the IO completion for a long time by blk_poll so it causes system sluggish problem when device is slow(e.g., zram with backing device). Thanks.
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
Hi Sergey, On Fri, Aug 03, 2018 at 11:39:29AM +0900, Sergey Senozhatsky wrote: > On (08/02/18 14:13), Andrew Morton wrote: > [..] > > That changelog is rather hard to follow. Please review my edits: > > > > : If zram supports writeback feature, it's no longer a BD_CAP_SYNCHRONOUS_IO > ^BDI_CAP_SYNCHRONOUS_IO > > [..] > > > A reader looking at this would wonder "why the heck are we doing that". > > Adding a code comment would help them. > > The interesting thing here is that include/linux/backing-dev.h > BDI_CAP_SYNCHRONOUS_IO comment says > > "Device is so fast that asynchronous IO would be inefficient." > > Which is not the reason why BDI_CAP_SYNCHRONOUS_IO is used by ZRAM. > Probably, the comment needs to be updated as well. I couldn't catch your point. Could you clarify a little bit more? What do you want to correct for the comment? > > Both SWP_SYNCHRONOUS_IO and BDI_CAP_SYNCHRONOUS_IO tend to pivot > "efficiency" [looking at the comments], but in ZRAM's case the whole > reason to use SYNC IO is a race condition and user-after-free that > follows. Actually, it's not whole reason. As I wrote down, without it, swap_readpage waits the IO completion for a long time by blk_poll so it causes system sluggish problem when device is slow(e.g., zram with backing device). Thanks.
Re: [PATCH v12 0/3] tracing: Centralize preemptirq tracepoints and unify their usage
Hi Masami,
On Thu, Aug 2, 2018 at 7:55 AM, Masami Hiramatsu wrote:
> Hi Joel,
>
> I found this caused several issues when testing ftrace.
>
> #1) ftrace boottest (FTRACE_STARTUP_TEST) fails
This sadly appears to be a real issue. The startup test for
"preemptirqsoff" tracer fails, however it passes for only preemptoff
or only irqsoff. I tested only the last 2 tracers, not the first one,
that's why I didn't catch it. I need to debug this more.
> #2) mmiotrace reports "IRQs not enabled as expected" error
> #3) lock subsystem event boottest causes "IRQs not disabled as expected"
> error (sometimes)
Could you try the below patch and let me know if you still see the
issue? In the v11 I removed the lockdep_recursing() check since it
seemed unnecessary. But I'd like to rule out that there's still some
issue lurking there. Thanks and I appreciate your help, diff is
attached to this email.
> #4) ftracetest test.d/event/toplevel-enable.tc causes "suspicious RCU usage"
> warning
I sent a patch fixing this with you on CC. I tested that it fixes the
issue you're reporting.
diff --git a/kernel/trace/trace_preemptirq.c b/kernel/trace/trace_preemptirq.c
index e76b78bf258e..13e2c6e99465 100644
--- a/kernel/trace/trace_preemptirq.c
+++ b/kernel/trace/trace_preemptirq.c
@@ -19,7 +19,7 @@ static DEFINE_PER_CPU(int, tracing_irq_cpu);
void trace_hardirqs_on(void)
{
- if (!this_cpu_read(tracing_irq_cpu))
+ if (lockdep_recursing(current) || !this_cpu_read(tracing_irq_cpu))
return;
trace_irq_enable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
@@ -29,7 +29,7 @@ EXPORT_SYMBOL(trace_hardirqs_on);
void trace_hardirqs_off(void)
{
- if (this_cpu_read(tracing_irq_cpu))
+ if (lockdep_recursing(current) || this_cpu_read(tracing_irq_cpu))
return;
this_cpu_write(tracing_irq_cpu, 1);
@@ -39,7 +39,7 @@ EXPORT_SYMBOL(trace_hardirqs_off);
__visible void trace_hardirqs_on_caller(unsigned long caller_addr)
{
- if (!this_cpu_read(tracing_irq_cpu))
+ if (lockdep_recursing(current) || !this_cpu_read(tracing_irq_cpu))
return;
trace_irq_enable_rcuidle(CALLER_ADDR0, caller_addr);
@@ -49,7 +49,7 @@ EXPORT_SYMBOL(trace_hardirqs_on_caller);
__visible void trace_hardirqs_off_caller(unsigned long caller_addr)
{
- if (this_cpu_read(tracing_irq_cpu))
+ if (lockdep_recursing(current) || this_cpu_read(tracing_irq_cpu))
return;
this_cpu_write(tracing_irq_cpu, 1);
Re: [PATCH v12 0/3] tracing: Centralize preemptirq tracepoints and unify their usage
Hi Masami,
On Thu, Aug 2, 2018 at 7:55 AM, Masami Hiramatsu wrote:
> Hi Joel,
>
> I found this caused several issues when testing ftrace.
>
> #1) ftrace boottest (FTRACE_STARTUP_TEST) fails
This sadly appears to be a real issue. The startup test for
"preemptirqsoff" tracer fails, however it passes for only preemptoff
or only irqsoff. I tested only the last 2 tracers, not the first one,
that's why I didn't catch it. I need to debug this more.
> #2) mmiotrace reports "IRQs not enabled as expected" error
> #3) lock subsystem event boottest causes "IRQs not disabled as expected"
> error (sometimes)
Could you try the below patch and let me know if you still see the
issue? In the v11 I removed the lockdep_recursing() check since it
seemed unnecessary. But I'd like to rule out that there's still some
issue lurking there. Thanks and I appreciate your help, diff is
attached to this email.
> #4) ftracetest test.d/event/toplevel-enable.tc causes "suspicious RCU usage"
> warning
I sent a patch fixing this with you on CC. I tested that it fixes the
issue you're reporting.
diff --git a/kernel/trace/trace_preemptirq.c b/kernel/trace/trace_preemptirq.c
index e76b78bf258e..13e2c6e99465 100644
--- a/kernel/trace/trace_preemptirq.c
+++ b/kernel/trace/trace_preemptirq.c
@@ -19,7 +19,7 @@ static DEFINE_PER_CPU(int, tracing_irq_cpu);
void trace_hardirqs_on(void)
{
- if (!this_cpu_read(tracing_irq_cpu))
+ if (lockdep_recursing(current) || !this_cpu_read(tracing_irq_cpu))
return;
trace_irq_enable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
@@ -29,7 +29,7 @@ EXPORT_SYMBOL(trace_hardirqs_on);
void trace_hardirqs_off(void)
{
- if (this_cpu_read(tracing_irq_cpu))
+ if (lockdep_recursing(current) || this_cpu_read(tracing_irq_cpu))
return;
this_cpu_write(tracing_irq_cpu, 1);
@@ -39,7 +39,7 @@ EXPORT_SYMBOL(trace_hardirqs_off);
__visible void trace_hardirqs_on_caller(unsigned long caller_addr)
{
- if (!this_cpu_read(tracing_irq_cpu))
+ if (lockdep_recursing(current) || !this_cpu_read(tracing_irq_cpu))
return;
trace_irq_enable_rcuidle(CALLER_ADDR0, caller_addr);
@@ -49,7 +49,7 @@ EXPORT_SYMBOL(trace_hardirqs_on_caller);
__visible void trace_hardirqs_off_caller(unsigned long caller_addr)
{
- if (this_cpu_read(tracing_irq_cpu))
+ if (lockdep_recursing(current) || this_cpu_read(tracing_irq_cpu))
return;
this_cpu_write(tracing_irq_cpu, 1);
Re: linux-next: build failure after merge of the pstore tree
On Thu, Aug 2, 2018 at 6:00 PM, Stephen Rothwell wrote:
> Hi Kees,
>
> After merging the pstore tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> fs/pstore/platform.o: In function `zbufsize_zstd':
> platform.c:(.text+0x172): undefined reference to `ZSTD_compressBound'
>
> Caused by commit
>
> 48ed452ca6ad ("pstore: add zstd compression support")
Yikes. I have no idea how this slipped through. allmodconfig builds
are my standard sanity-check but I clearly made some kind of error in
my scripting.
I'll get it fixed. Thanks!
-Kees
--
Kees Cook
Pixel Security
Re: linux-next: build failure after merge of the pstore tree
On Thu, Aug 2, 2018 at 6:00 PM, Stephen Rothwell wrote:
> Hi Kees,
>
> After merging the pstore tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> fs/pstore/platform.o: In function `zbufsize_zstd':
> platform.c:(.text+0x172): undefined reference to `ZSTD_compressBound'
>
> Caused by commit
>
> 48ed452ca6ad ("pstore: add zstd compression support")
Yikes. I have no idea how this slipped through. allmodconfig builds
are my standard sanity-check but I clearly made some kind of error in
my scripting.
I'll get it fixed. Thanks!
-Kees
--
Kees Cook
Pixel Security
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
Hi Andrew,
On Thu, Aug 02, 2018 at 02:13:04PM -0700, Andrew Morton wrote:
> On Thu, 2 Aug 2018 14:11:12 +0900 Minchan Kim wrote:
>
> > If zram supports writeback feature, it's no more syncrhonous
> > device beause zram does synchronous IO opeation for
> > incompressible page.
> >
> > Do not pretend to be syncrhonous IO device. It makes system
> > very sluggish as waiting IO completion from upper layer.
> >
> > Furthermore, it makes user-after-free problem because swap
> > think the opearion is done when the IO functions returns so
> > it could free page by will(e.g., lock_page_or_retry and
> > goto out_release in do_swap_page) but in fact, IO is
> > asynchrnous so driver could access just freed page afterward.
> >
> > This patch fixes the problem.
I fixed my faults from original description.
Otherwise, ones you corrected looks good to me.
>
> That changelog is rather hard to follow. Please review my edits:
>
> : If zram supports writeback feature, it's no longer a BD_CAP_SYNCHRONOUS_IO
> : device beause zram does synchronous IO operations for incompressible pages.
asynchronous
> :
> : Do not pretend to be synchronous IO device. It makes the system very
> : sluggish due to waiting for IO completion from upper layers.
> :
> : Furthermore, it causes a user-after-free problem because swap thinks the
> : opearion is done when the IO functions returns so it can free the page
> : (e.g., lock_page_or_retry and goto out_release in do_swap_page) but in
> : fact, IO is asynchrnous so the driver could access a just freed page
asynchronous
> : afterward.
> :
> : This patch fixes the problem.
>
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index 7436b2d27fa3..0b6eda1bd77a 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -298,7 +298,8 @@ static void reset_bdev(struct zram *zram)
> > zram->backing_dev = NULL;
> > zram->old_block_size = 0;
> > zram->bdev = NULL;
> > -
> > + zram->disk->queue->backing_dev_info->capabilities |=
> > + BDI_CAP_SYNCHRONOUS_IO;
> > kvfree(zram->bitmap);
> > zram->bitmap = NULL;
> > }
> > @@ -400,6 +401,8 @@ static ssize_t backing_dev_store(struct device *dev,
> > zram->backing_dev = backing_dev;
> > zram->bitmap = bitmap;
> > zram->nr_pages = nr_pages;
> > + zram->disk->queue->backing_dev_info->capabilities &=
> > + ~BDI_CAP_SYNCHRONOUS_IO;
> > up_write(>init_lock);
> >
> > pr_info("setup backing device %s\n", file_name);
>
> A reader looking at this would wonder "why the heck are we doing that".
> Adding a code comment would help them.
I will add
/*
* With writeback feature, zram does a asynchronous IO so it's no longer
* synchronous device. If it pretend to be, upper layer could wait IO
* completion rather than (submit and return), which will cause system
* sluggish.
* Furthermore, when the IO function returns(e.g., swap_readpage),
* uppler lay could guess IO was done so it could deallocate the page
* freely but in fact, IO is going on and it finally could cause
* use-after-free when the IO is really done.
*/
>
> Is it legitimate to be altering the bdi capabilities at this level? Or
> is this hacky?
Most of device's bdi capability seems to be static but there are few drivers
which can change capability. For example, BDI_CAP_STABLE_WRITES
drivers/scsi/iscsi_tcp.c
drivers/md/raid5.c
I believe it's driver itself advertisement stuff so I hope it's not hack.
>
> If "yes" then should reset_bdev() be unconditionally setting
> BDI_CAP_SYNCHRONOUS_IO? Shouldn't it be restoring that flag to its
> previous setting?
>
Yu, reset_bdev should set it unconditionally. Because zram's default
mode is synchronous and it changed only if user set backing device.
I will respin the patch with revised comment and description.
Thanks.
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
On (08/03/18 11:39), Sergey Senozhatsky wrote: > [..] > > > A reader looking at this would wonder "why the heck are we doing that". > > Adding a code comment would help them. > > The interesting thing here is that include/linux/backing-dev.h > BDI_CAP_SYNCHRONOUS_IO comment says > > "Device is so fast that asynchronous IO would be inefficient." > > Which is not the reason why BDI_CAP_SYNCHRONOUS_IO is used by ZRAM. > Probably, the comment needs to be updated as well. > > Both SWP_SYNCHRONOUS_IO and BDI_CAP_SYNCHRONOUS_IO tend to pivot > "efficiency" [looking at the comments], but in ZRAM's case the whole > reason to use SYNC IO is a race condition and user-after-free that ^ASYNC IO -ss
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
Hi Andrew,
On Thu, Aug 02, 2018 at 02:13:04PM -0700, Andrew Morton wrote:
> On Thu, 2 Aug 2018 14:11:12 +0900 Minchan Kim wrote:
>
> > If zram supports writeback feature, it's no more syncrhonous
> > device beause zram does synchronous IO opeation for
> > incompressible page.
> >
> > Do not pretend to be syncrhonous IO device. It makes system
> > very sluggish as waiting IO completion from upper layer.
> >
> > Furthermore, it makes user-after-free problem because swap
> > think the opearion is done when the IO functions returns so
> > it could free page by will(e.g., lock_page_or_retry and
> > goto out_release in do_swap_page) but in fact, IO is
> > asynchrnous so driver could access just freed page afterward.
> >
> > This patch fixes the problem.
I fixed my faults from original description.
Otherwise, ones you corrected looks good to me.
>
> That changelog is rather hard to follow. Please review my edits:
>
> : If zram supports writeback feature, it's no longer a BD_CAP_SYNCHRONOUS_IO
> : device beause zram does synchronous IO operations for incompressible pages.
asynchronous
> :
> : Do not pretend to be synchronous IO device. It makes the system very
> : sluggish due to waiting for IO completion from upper layers.
> :
> : Furthermore, it causes a user-after-free problem because swap thinks the
> : opearion is done when the IO functions returns so it can free the page
> : (e.g., lock_page_or_retry and goto out_release in do_swap_page) but in
> : fact, IO is asynchrnous so the driver could access a just freed page
asynchronous
> : afterward.
> :
> : This patch fixes the problem.
>
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index 7436b2d27fa3..0b6eda1bd77a 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -298,7 +298,8 @@ static void reset_bdev(struct zram *zram)
> > zram->backing_dev = NULL;
> > zram->old_block_size = 0;
> > zram->bdev = NULL;
> > -
> > + zram->disk->queue->backing_dev_info->capabilities |=
> > + BDI_CAP_SYNCHRONOUS_IO;
> > kvfree(zram->bitmap);
> > zram->bitmap = NULL;
> > }
> > @@ -400,6 +401,8 @@ static ssize_t backing_dev_store(struct device *dev,
> > zram->backing_dev = backing_dev;
> > zram->bitmap = bitmap;
> > zram->nr_pages = nr_pages;
> > + zram->disk->queue->backing_dev_info->capabilities &=
> > + ~BDI_CAP_SYNCHRONOUS_IO;
> > up_write(>init_lock);
> >
> > pr_info("setup backing device %s\n", file_name);
>
> A reader looking at this would wonder "why the heck are we doing that".
> Adding a code comment would help them.
I will add
/*
* With writeback feature, zram does a asynchronous IO so it's no longer
* synchronous device. If it pretend to be, upper layer could wait IO
* completion rather than (submit and return), which will cause system
* sluggish.
* Furthermore, when the IO function returns(e.g., swap_readpage),
* uppler lay could guess IO was done so it could deallocate the page
* freely but in fact, IO is going on and it finally could cause
* use-after-free when the IO is really done.
*/
>
> Is it legitimate to be altering the bdi capabilities at this level? Or
> is this hacky?
Most of device's bdi capability seems to be static but there are few drivers
which can change capability. For example, BDI_CAP_STABLE_WRITES
drivers/scsi/iscsi_tcp.c
drivers/md/raid5.c
I believe it's driver itself advertisement stuff so I hope it's not hack.
>
> If "yes" then should reset_bdev() be unconditionally setting
> BDI_CAP_SYNCHRONOUS_IO? Shouldn't it be restoring that flag to its
> previous setting?
>
Yu, reset_bdev should set it unconditionally. Because zram's default
mode is synchronous and it changed only if user set backing device.
I will respin the patch with revised comment and description.
Thanks.
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
On (08/03/18 11:39), Sergey Senozhatsky wrote: > [..] > > > A reader looking at this would wonder "why the heck are we doing that". > > Adding a code comment would help them. > > The interesting thing here is that include/linux/backing-dev.h > BDI_CAP_SYNCHRONOUS_IO comment says > > "Device is so fast that asynchronous IO would be inefficient." > > Which is not the reason why BDI_CAP_SYNCHRONOUS_IO is used by ZRAM. > Probably, the comment needs to be updated as well. > > Both SWP_SYNCHRONOUS_IO and BDI_CAP_SYNCHRONOUS_IO tend to pivot > "efficiency" [looking at the comments], but in ZRAM's case the whole > reason to use SYNC IO is a race condition and user-after-free that ^ASYNC IO -ss
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
On (08/02/18 14:13), Andrew Morton wrote: [..] > That changelog is rather hard to follow. Please review my edits: > > : If zram supports writeback feature, it's no longer a BD_CAP_SYNCHRONOUS_IO ^BDI_CAP_SYNCHRONOUS_IO [..] > A reader looking at this would wonder "why the heck are we doing that". > Adding a code comment would help them. The interesting thing here is that include/linux/backing-dev.h BDI_CAP_SYNCHRONOUS_IO comment says "Device is so fast that asynchronous IO would be inefficient." Which is not the reason why BDI_CAP_SYNCHRONOUS_IO is used by ZRAM. Probably, the comment needs to be updated as well. Both SWP_SYNCHRONOUS_IO and BDI_CAP_SYNCHRONOUS_IO tend to pivot "efficiency" [looking at the comments], but in ZRAM's case the whole reason to use SYNC IO is a race condition and user-after-free that follows. -ss
Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature
On (08/02/18 14:13), Andrew Morton wrote: [..] > That changelog is rather hard to follow. Please review my edits: > > : If zram supports writeback feature, it's no longer a BD_CAP_SYNCHRONOUS_IO ^BDI_CAP_SYNCHRONOUS_IO [..] > A reader looking at this would wonder "why the heck are we doing that". > Adding a code comment would help them. The interesting thing here is that include/linux/backing-dev.h BDI_CAP_SYNCHRONOUS_IO comment says "Device is so fast that asynchronous IO would be inefficient." Which is not the reason why BDI_CAP_SYNCHRONOUS_IO is used by ZRAM. Probably, the comment needs to be updated as well. Both SWP_SYNCHRONOUS_IO and BDI_CAP_SYNCHRONOUS_IO tend to pivot "efficiency" [looking at the comments], but in ZRAM's case the whole reason to use SYNC IO is a race condition and user-after-free that follows. -ss
[PATCH] trace: Use rcu_dereference_raw for hooks from trace-event subsystem
Since we switched to using SRCU for tracepoints used in the idle path,
we can no longer use rcu_dereference_sched for dereferencing points in
trace-event hooks.
Since tracepoints can now use either SRCU or sched-RCU, just use
rcu_dereference_raw for traceevents just like we're doing when
dereferencing the tracepoint table.
This prevents an RCU warning reported by Masami:
[ 282.060593] WARNING: can't dereference registers at f3c7f62b
[ 282.063200] =
[ 282.064082] WARNING: suspicious RCU usage
[ 282.064963] 4.18.0-rc6+ #15 Tainted: GW
[ 282.066048] -
[ 282.066923] /home/mhiramat/ksrc/linux/kernel/trace/trace_events.c:242
suspicious rcu_dereference_check() usage!
[ 282.068974]
[ 282.068974] other info that might help us debug this:
[ 282.068974]
[ 282.070770]
[ 282.070770] RCU used illegally from idle CPU!
[ 282.070770] rcu_scheduler_active = 2, debug_locks = 1
[ 282.072938] RCU used illegally from extended quiescent state!
[ 282.074183] no locks held by swapper/0/0.
[ 282.075071]
[ 282.075071] stack backtrace:
[ 282.076121] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW
[ 282.077782] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
[ 282.079604] Call Trace:
[ 282.080212]
[ 282.080755] dump_stack+0x85/0xcb
[ 282.081523] trace_event_ignore_this_pid+0x66/0x70
[ 282.082541] trace_event_raw_event_preemptirq_template+0xa2/0xb0
[ 282.083774] ? interrupt_entry+0xc4/0xe0
[ 282.084665] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 282.085669] trace_hardirqs_off_caller+0x90/0xd0
[ 282.086597] trace_hardirqs_off_thunk+0x1a/0x1c
[ 282.087433] ? call_function_interrupt+0xa/0x20
[ 282.088201] interrupt_entry+0xc4/0xe0
[ 282.088848] ? call_function_interrupt+0xa/0x20
[ 282.089579]
[ 282.090029] ? native_safe_halt+0x2/0x10
[ 282.090695] ? default_idle+0x1f/0x160
[ 282.091330] ? default_idle_call+0x24/0x40
[ 282.091997] ? do_idle+0x210/0x250
[ 282.092658] ? cpu_startup_entry+0x6f/0x80
[ 282.093338] ? start_kernel+0x49d/0x4bd
[ 282.093987] ? secondary_startup_64+0xa5/0xb0
Reported-by: Masami Hiramatsu
Fixes: e6753f23d961 ("tracepoint: Make rcuidle tracepoint callers use SRCU")
Signed-off-by: Joel Fernandes (Google)
---
kernel/trace/trace_events.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 14ff4ff3caab..7b508ce8ac44 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -239,7 +239,7 @@ bool trace_event_ignore_this_pid(struct trace_event_file
*trace_file)
struct trace_array_cpu *data;
struct trace_pid_list *pid_list;
- pid_list = rcu_dereference_sched(tr->filtered_pids);
+ pid_list = rcu_dereference_raw(tr->filtered_pids);
if (!pid_list)
return false;
@@ -512,7 +512,7 @@ event_filter_pid_sched_process_exit(void *data, struct
task_struct *task)
struct trace_pid_list *pid_list;
struct trace_array *tr = data;
- pid_list = rcu_dereference_sched(tr->filtered_pids);
+ pid_list = rcu_dereference_raw(tr->filtered_pids);
trace_filter_add_remove_task(pid_list, NULL, task);
}
--
2.18.0.597.ga71716f1ad-goog
[PATCH] trace: Use rcu_dereference_raw for hooks from trace-event subsystem
Since we switched to using SRCU for tracepoints used in the idle path,
we can no longer use rcu_dereference_sched for dereferencing points in
trace-event hooks.
Since tracepoints can now use either SRCU or sched-RCU, just use
rcu_dereference_raw for traceevents just like we're doing when
dereferencing the tracepoint table.
This prevents an RCU warning reported by Masami:
[ 282.060593] WARNING: can't dereference registers at f3c7f62b
[ 282.063200] =
[ 282.064082] WARNING: suspicious RCU usage
[ 282.064963] 4.18.0-rc6+ #15 Tainted: GW
[ 282.066048] -
[ 282.066923] /home/mhiramat/ksrc/linux/kernel/trace/trace_events.c:242
suspicious rcu_dereference_check() usage!
[ 282.068974]
[ 282.068974] other info that might help us debug this:
[ 282.068974]
[ 282.070770]
[ 282.070770] RCU used illegally from idle CPU!
[ 282.070770] rcu_scheduler_active = 2, debug_locks = 1
[ 282.072938] RCU used illegally from extended quiescent state!
[ 282.074183] no locks held by swapper/0/0.
[ 282.075071]
[ 282.075071] stack backtrace:
[ 282.076121] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW
[ 282.077782] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
[ 282.079604] Call Trace:
[ 282.080212]
[ 282.080755] dump_stack+0x85/0xcb
[ 282.081523] trace_event_ignore_this_pid+0x66/0x70
[ 282.082541] trace_event_raw_event_preemptirq_template+0xa2/0xb0
[ 282.083774] ? interrupt_entry+0xc4/0xe0
[ 282.084665] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 282.085669] trace_hardirqs_off_caller+0x90/0xd0
[ 282.086597] trace_hardirqs_off_thunk+0x1a/0x1c
[ 282.087433] ? call_function_interrupt+0xa/0x20
[ 282.088201] interrupt_entry+0xc4/0xe0
[ 282.088848] ? call_function_interrupt+0xa/0x20
[ 282.089579]
[ 282.090029] ? native_safe_halt+0x2/0x10
[ 282.090695] ? default_idle+0x1f/0x160
[ 282.091330] ? default_idle_call+0x24/0x40
[ 282.091997] ? do_idle+0x210/0x250
[ 282.092658] ? cpu_startup_entry+0x6f/0x80
[ 282.093338] ? start_kernel+0x49d/0x4bd
[ 282.093987] ? secondary_startup_64+0xa5/0xb0
Reported-by: Masami Hiramatsu
Fixes: e6753f23d961 ("tracepoint: Make rcuidle tracepoint callers use SRCU")
Signed-off-by: Joel Fernandes (Google)
---
kernel/trace/trace_events.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 14ff4ff3caab..7b508ce8ac44 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -239,7 +239,7 @@ bool trace_event_ignore_this_pid(struct trace_event_file
*trace_file)
struct trace_array_cpu *data;
struct trace_pid_list *pid_list;
- pid_list = rcu_dereference_sched(tr->filtered_pids);
+ pid_list = rcu_dereference_raw(tr->filtered_pids);
if (!pid_list)
return false;
@@ -512,7 +512,7 @@ event_filter_pid_sched_process_exit(void *data, struct
task_struct *task)
struct trace_pid_list *pid_list;
struct trace_array *tr = data;
- pid_list = rcu_dereference_sched(tr->filtered_pids);
+ pid_list = rcu_dereference_raw(tr->filtered_pids);
trace_filter_add_remove_task(pid_list, NULL, task);
}
--
2.18.0.597.ga71716f1ad-goog
linux-next: build failure after merge of the pstore tree
Hi Kees,
After merging the pstore tree, today's linux-next build (x86_64
allmodconfig) failed like this:
fs/pstore/platform.o: In function `zbufsize_zstd':
platform.c:(.text+0x172): undefined reference to `ZSTD_compressBound'
Caused by commit
48ed452ca6ad ("pstore: add zstd compression support")
I have used the pstore tree from next-20180802 for today.
--
Cheers,
Stephen Rothwell
pgpqkh2PNeXBK.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the pstore tree
Hi Kees,
After merging the pstore tree, today's linux-next build (x86_64
allmodconfig) failed like this:
fs/pstore/platform.o: In function `zbufsize_zstd':
platform.c:(.text+0x172): undefined reference to `ZSTD_compressBound'
Caused by commit
48ed452ca6ad ("pstore: add zstd compression support")
I have used the pstore tree from next-20180802 for today.
--
Cheers,
Stephen Rothwell
pgpqkh2PNeXBK.pgp
Description: OpenPGP digital signature
Re: [PATCH v4 2/4] x86/boot: Add acpitb.c to parse acpi tables
On Fri, Aug 03, 2018 at 10:00:48AM +0800, Dou Liyang wrote:
>
>
>At 07/23/2018 05:29 PM, Chao Fan wrote:
>> Imitate the ACPI code to parse ACPI tables. Functions are simplified
>> cause some operations are not needed here.
>> And also, this method won't influence the initialization of ACPI.
>>
>> Signed-off-by: Chao Fan
>
>Hi Fan,
>
>I know you got the code from acpica subsystem and EFI code... and do
>many adaptation work for KASLR. It's awesome!
>
>I think you can add some other simple comments.
>
> - what differences between your function and the function you based on
>and why did you do that?
>
>... to make this more credible and easy to remember the details as time
>goes on.
That's a good idea, will add more comments.
>
>Also some concerns below.
>> ---
>[...]
>> +else if (!strncmp(sig, EFI32_LOADER_SIGNATURE, 4))
>> +efi_64 = false;
>> +else {
>> +debug_putstr("Wrong efi loader signature.\n");
>
>s/efi/EFI/, also need fix in the comments below.
>
>> +return false;
>> +}
>> +
>[...]
>> +/*
>> + * Get rsdp from efi tables.
>> + * If we find acpi table, go on searching for acpi20 table.
>> + * If we didn't get acpi20 table then use acpi table.
>> + * If neither acpi table nor acpi20 table found,
>> + * return false.
>> + */
>> +if (!(efi_guidcmp(guid, ACPI_TABLE_GUID)) && !acpi_20) {
>> +*rsdp_addr = (acpi_physical_address)table;
>> +acpi_20 = false;
>> +find_rsdp = true;
>> +} else if (!(efi_guidcmp(guid, ACPI_20_TABLE_GUID))) {
>> +*rsdp_addr = (acpi_physical_address)table;
>> +acpi_20 = true;
>> +return true;
>
>If we find the ACPI 2.0, we will return immediately, so the variable and
>logic of _acpi_20_ is redundant.
I will check the logical and fix the mistake.
Thanks,
Chao Fan
>
>Thanks,
> dou
Re: [PATCH v4 2/4] x86/boot: Add acpitb.c to parse acpi tables
On Fri, Aug 03, 2018 at 10:00:48AM +0800, Dou Liyang wrote:
>
>
>At 07/23/2018 05:29 PM, Chao Fan wrote:
>> Imitate the ACPI code to parse ACPI tables. Functions are simplified
>> cause some operations are not needed here.
>> And also, this method won't influence the initialization of ACPI.
>>
>> Signed-off-by: Chao Fan
>
>Hi Fan,
>
>I know you got the code from acpica subsystem and EFI code... and do
>many adaptation work for KASLR. It's awesome!
>
>I think you can add some other simple comments.
>
> - what differences between your function and the function you based on
>and why did you do that?
>
>... to make this more credible and easy to remember the details as time
>goes on.
That's a good idea, will add more comments.
>
>Also some concerns below.
>> ---
>[...]
>> +else if (!strncmp(sig, EFI32_LOADER_SIGNATURE, 4))
>> +efi_64 = false;
>> +else {
>> +debug_putstr("Wrong efi loader signature.\n");
>
>s/efi/EFI/, also need fix in the comments below.
>
>> +return false;
>> +}
>> +
>[...]
>> +/*
>> + * Get rsdp from efi tables.
>> + * If we find acpi table, go on searching for acpi20 table.
>> + * If we didn't get acpi20 table then use acpi table.
>> + * If neither acpi table nor acpi20 table found,
>> + * return false.
>> + */
>> +if (!(efi_guidcmp(guid, ACPI_TABLE_GUID)) && !acpi_20) {
>> +*rsdp_addr = (acpi_physical_address)table;
>> +acpi_20 = false;
>> +find_rsdp = true;
>> +} else if (!(efi_guidcmp(guid, ACPI_20_TABLE_GUID))) {
>> +*rsdp_addr = (acpi_physical_address)table;
>> +acpi_20 = true;
>> +return true;
>
>If we find the ACPI 2.0, we will return immediately, so the variable and
>logic of _acpi_20_ is redundant.
I will check the logical and fix the mistake.
Thanks,
Chao Fan
>
>Thanks,
> dou
Re: [V9fs-developer] [PATCH v2] net/9p/trans_virtio.c: add null terminal for mount tag
Dominique Martinet wrote on Fri, Aug 03, 2018: > (the code is currently not safe if it returns an error, I'm sending > another mail about it right after this one as we already have a partial > fix) I take that one back, ksys_mount() does check for error properly so just the null checks we have in Tomas' patch[1] are enough ; sorry for the double-mail [1] http://lkml.kernel.org/r/20180727110558.5479-1-tomasbort...@gmail.com -- Dominique
Re: [V9fs-developer] [PATCH v2] net/9p/trans_virtio.c: add null terminal for mount tag
Dominique Martinet wrote on Fri, Aug 03, 2018: > (the code is currently not safe if it returns an error, I'm sending > another mail about it right after this one as we already have a partial > fix) I take that one back, ksys_mount() does check for error properly so just the null checks we have in Tomas' patch[1] are enough ; sorry for the double-mail [1] http://lkml.kernel.org/r/20180727110558.5479-1-tomasbort...@gmail.com -- Dominique
Re: [V9fs-developer] [PATCH v2] net/9p/trans_virtio.c: add null terminal for mount tag
piaojun wrote on Fri, Aug 03, 2018: > We'd better reach an agreement about the patch fix. The way I read Greg's comment was that he agreed to the proposed changes and is waiting for a new version. I'm writing a longer reply than I should because I don't like people saying strncmp is safe just because it's strncmp, feel free to skim through the rest as it's just ranting. > In my opinion, replacing strlen(chan->tag) with a local variable > sounds reasonable, So we agree here > and changing strncmp to strcmp may be little beneficial, as strcmp is more > dangerours such as buffer-flow. strcmp is more dangerous for buffer-overflow if you're comparing "unsafe" non-null terminated strings. This isn't the case here as you've constructed chan->tag yourself and you rely on it being null-terminated by calling strlen() on it yourself. strncmp(x, y, strlen(y)+1) is at best awkward, but it's a false sense of security if you think this is any better than strcmp here. It implies that: - y is null-terminated (for strlen() to work) - x is either null-terminated or longer than y Here, x is the devname argument to p9_virtio_create, which comes straight from the mount syscall with "copy_mount_string", using strndup_user, which returns a null-terminated string or an error. (the code is currently not safe if it returns an error, I'm sending another mail about it right after this one as we already have a partial fix) strcmp(x, y) on the other hand assumes that x and y are null-terminated in this case, which is the same assumptions you have, so is strictly as "safe" as strncmp used that way. (it could also assume that one is null terminated and the other one is at least as long as that, e.g. when comparing a "char buf[42]" to the constant "foo" then we don't care if buf is null-terminated) Thanks, -- Dominique
Re: [V9fs-developer] [PATCH v2] net/9p/trans_virtio.c: add null terminal for mount tag
piaojun wrote on Fri, Aug 03, 2018: > We'd better reach an agreement about the patch fix. The way I read Greg's comment was that he agreed to the proposed changes and is waiting for a new version. I'm writing a longer reply than I should because I don't like people saying strncmp is safe just because it's strncmp, feel free to skim through the rest as it's just ranting. > In my opinion, replacing strlen(chan->tag) with a local variable > sounds reasonable, So we agree here > and changing strncmp to strcmp may be little beneficial, as strcmp is more > dangerours such as buffer-flow. strcmp is more dangerous for buffer-overflow if you're comparing "unsafe" non-null terminated strings. This isn't the case here as you've constructed chan->tag yourself and you rely on it being null-terminated by calling strlen() on it yourself. strncmp(x, y, strlen(y)+1) is at best awkward, but it's a false sense of security if you think this is any better than strcmp here. It implies that: - y is null-terminated (for strlen() to work) - x is either null-terminated or longer than y Here, x is the devname argument to p9_virtio_create, which comes straight from the mount syscall with "copy_mount_string", using strndup_user, which returns a null-terminated string or an error. (the code is currently not safe if it returns an error, I'm sending another mail about it right after this one as we already have a partial fix) strcmp(x, y) on the other hand assumes that x and y are null-terminated in this case, which is the same assumptions you have, so is strictly as "safe" as strncmp used that way. (it could also assume that one is null terminated and the other one is at least as long as that, e.g. when comparing a "char buf[42]" to the constant "foo" then we don't care if buf is null-terminated) Thanks, -- Dominique
