Re: [PATCH v2 1/1] i2c: iproc: Add i2c repeated start capability
Hi Wolfram,
Please review the patch and let me know if you still have any review comments.
Best regards,
Rayagonda
On Thu, Oct 10, 2019 at 3:02 PM Rayagonda Kokatanur
wrote:
>
> Hi Wolfram,
>
> Did you get a chance to review this patch.
>
> Best regards,
> Rayagonda
>
>
> On Mon, Sep 30, 2019 at 12:19 PM Rayagonda Kokatanur
> wrote:
> >
> > From: Lori Hikichi
> >
> > Enable handling of i2c repeated start. The current code
> > handles a multi msg i2c transfer as separate i2c bus
> > transactions. This change will now handle this case
> > using the i2c repeated start protocol. The number of msgs
> > in a transfer is limited to two, and must be a write
> > followed by a read.
> >
> > Signed-off-by: Lori Hikichi
> > Signed-off-by: Rayagonda Kokatanur
> > Signed-off-by: Icarus Chau
> > Signed-off-by: Ray Jui
> > Signed-off-by: Shivaraj Shetty
> > ---
> > changes from v1:
> > - Address following review comments from Wolfarm Sang,
> >Use i2c_8bit_addr_from_msg() api instead of decoding i2c_msg struct and
> >remove check against number of i2c message as it will be taken care
> >by core using quirks flags.
> >
> > drivers/i2c/busses/i2c-bcm-iproc.c | 63
> > ++
> > 1 file changed, 50 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c
> > b/drivers/i2c/busses/i2c-bcm-iproc.c
> > index d7fd76b..e478db7 100644
> > --- a/drivers/i2c/busses/i2c-bcm-iproc.c
> > +++ b/drivers/i2c/busses/i2c-bcm-iproc.c
> > @@ -81,6 +81,7 @@
> > #define M_CMD_PROTOCOL_MASK 0xf
> > #define M_CMD_PROTOCOL_BLK_WR0x7
> > #define M_CMD_PROTOCOL_BLK_RD0x8
> > +#define M_CMD_PROTOCOL_PROCESS 0xa
> > #define M_CMD_PEC_SHIFT 8
> > #define M_CMD_RD_CNT_SHIFT 0
> > #define M_CMD_RD_CNT_MASK0xff
> > @@ -675,13 +676,20 @@ static int bcm_iproc_i2c_xfer_wait(struct
> > bcm_iproc_i2c_dev *iproc_i2c,
> > return 0;
> > }
> >
> > -static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev
> > *iproc_i2c,
> > -struct i2c_msg *msg)
> > +/*
> > + * If 'process_call' is true, then this is a multi-msg transfer that
> > requires
> > + * a repeated start between the messages.
> > + * More specifically, it must be a write (reg) followed by a read (data).
> > + * The i2c quirks are set to enforce this rule.
> > + */
> > +static int bcm_iproc_i2c_xfer_internal(struct bcm_iproc_i2c_dev *iproc_i2c,
> > + struct i2c_msg *msgs, bool
> > process_call)
> > {
> > int i;
> > u8 addr;
> > u32 val, tmp, val_intr_en;
> > unsigned int tx_bytes;
> > + struct i2c_msg *msg = [0];
> >
> > /* check if bus is busy */
> > if (!!(iproc_i2c_rd_reg(iproc_i2c,
> > @@ -707,14 +715,29 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
> > bcm_iproc_i2c_dev *iproc_i2c,
> > val = msg->buf[i];
> >
> > /* mark the last byte */
> > - if (i == msg->len - 1)
> > - val |= BIT(M_TX_WR_STATUS_SHIFT);
> > + if (!process_call && (i == msg->len - 1))
> > + val |= 1 << M_TX_WR_STATUS_SHIFT;
> >
> > iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
> > }
> > iproc_i2c->tx_bytes = tx_bytes;
> > }
> >
> > + /* Process the read message if this is process call */
> > + if (process_call) {
> > + msg++;
> > + iproc_i2c->msg = msg; /* point to second msg */
> > +
> > + /*
> > +* The last byte to be sent out should be a slave
> > +* address with read operation
> > +*/
> > + addr = i2c_8bit_addr_from_msg(msg);
> > + /* mark it the last byte out */
> > + val = addr | (1 << M_TX_WR_STATUS_SHIFT);
> > + iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
> > + }
> > +
> > /* mark as incomplete before starting the transaction */
> > if (iproc_i2c->irq)
> > reinit_completion(_i2c->done);
> > @@ -733,7 +756,7 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
> > bcm_iproc_i2c_dev *iproc_i2c,
> > * underrun interrupt, which will be triggerred when the TX FIFO is
> > * empty. When that happens we can then pump more data into the FIFO
> > */
> > - if (!(msg->flags & I2C_M_RD) &&
> > + if (!process_call && !(msg->flags & I2C_M_RD) &&
> > msg->len > iproc_i2c->tx_bytes)
> > val_intr_en |= BIT(IE_M_TX_UNDERRUN_SHIFT);
> >
> > @@ -743,6 +766,8 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
> > bcm_iproc_i2c_dev *iproc_i2c,
> > */
> > val = BIT(M_CMD_START_BUSY_SHIFT);
> > if (msg->flags & I2C_M_RD) {
> > +
[PATCH v3] cpupower : Handle set and info subcommands correctly
Cpupower tool has set and info options which are being used only by
x86 machines. This patch removes support for these two subcommands
from cpupower utility for POWER. Thus, these two subcommands will now be
available only for intel.
This removes the ambiguous error message while using set option in case
of using non-intel systems.
Without this patch on a POWER system:
root@ubuntu:~# cpupower info
System does not support Intel's performance bias setting
root@ubuntu:~# cpupower set -b 10
Error setting perf-bias value on CPU
With this patch on a POWER box:
root@ubuntu:~# cpupower info
Subcommand not supported on POWER
Same result for set subcommand.
This patch does not affect results on a intel box.
Signed-off-by: Abhishek Goel
Acked-by: Thomas Renninger
---
v1 -> v2 : Instead of bailing out early in set and info commands, in V2,
we are cutting out support for these two commands for non-intel
systems.
v2 -> v3 : Using architecture identification in subcommands to make
decision instead of cutting out support altogether
tools/power/cpupower/utils/cpupower-info.c | 9 +
tools/power/cpupower/utils/cpupower-set.c | 9 +
2 files changed, 18 insertions(+)
diff --git a/tools/power/cpupower/utils/cpupower-info.c
b/tools/power/cpupower/utils/cpupower-info.c
index 4c9d342b70ff..d3755ea70d4d 100644
--- a/tools/power/cpupower/utils/cpupower-info.c
+++ b/tools/power/cpupower/utils/cpupower-info.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include "helpers/helpers.h"
#include "helpers/sysfs.h"
@@ -30,6 +31,7 @@ int cmd_info(int argc, char **argv)
extern char *optarg;
extern int optind, opterr, optopt;
unsigned int cpu;
+ struct utsname uts;
union {
struct {
@@ -39,6 +41,13 @@ int cmd_info(int argc, char **argv)
} params = {};
int ret = 0;
+ ret = uname();
+ if (!ret && (!strcmp(uts.machine, "ppc64le") ||
+!strcmp(uts.machine, "ppc64"))) {
+ fprintf(stderr, _("Subcommand not supported on POWER.\n"));
+ return ret;
+ }
+
setlocale(LC_ALL, "");
textdomain(PACKAGE);
diff --git a/tools/power/cpupower/utils/cpupower-set.c
b/tools/power/cpupower/utils/cpupower-set.c
index 3cd95c6cb974..3cca6f715dd9 100644
--- a/tools/power/cpupower/utils/cpupower-set.c
+++ b/tools/power/cpupower/utils/cpupower-set.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include "helpers/helpers.h"
#include "helpers/sysfs.h"
@@ -31,6 +32,7 @@ int cmd_set(int argc, char **argv)
extern char *optarg;
extern int optind, opterr, optopt;
unsigned int cpu;
+ struct utsname uts;
union {
struct {
@@ -41,6 +43,13 @@ int cmd_set(int argc, char **argv)
int perf_bias = 0;
int ret = 0;
+ ret = uname();
+ if (!ret && (!strcmp(uts.machine, "ppc64le") ||
+!strcmp(uts.machine, "ppc64"))) {
+ fprintf(stderr, _("Subcommand not supported on POWER.\n"));
+ return ret;
+ }
+
setlocale(LC_ALL, "");
textdomain(PACKAGE);
--
2.17.1
Re: [PATCH] net: dsa: rtl8366rb: add missing of_node_put after calling of_get_child_by_name
On 2019/10/2 1:03 上午, David Miller wrote:
From: Wen Yang
Date: Sun, 29 Sep 2019 15:00:47 +0800
of_node_put needs to be called when the device node which is got
from of_get_child_by_name finished using.
irq_domain_add_linear() also calls of_node_get() to increase refcount,
so irq_domain will not be affected when it is released.
fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver")
Signed-off-by: Wen Yang
Please capitalize Fixes:, seriously I am very curious where did you
learned to specify the fixes tag non-capitalized?
Patch applied, t hanks.
Thank you for your comments.
We checked the code repository and found that both ‘Fixes’ and ‘fixes’
are being used, such as:
commit a53651ec93a8d7ab5b26c5390e0c389048b4b4b6
…
net: ena: don't wake up tx queue when down
…
fixes: 1738cd3ed342 (net: ena: Add a driver for Amazon Elastic
Network Adapters (ENA))
…
And,
commit 1df379924304b687263942452836db1d725155df
…
clk: consoldiate the __clk_get_hw() declarations
…
Fixes: 59fcdce425b7 ("clk: Remove ifdef for COMMON_CLK in
clk-provider.h")
fixes: 73e0e496afda ("clkdev: Always allocate a struct clk and call
__clk_get() w/ CCF")
…
It is also found that the sha1 following ‘Fixes:’ requires at least 12
digits.
So we plan to modify the checkpatch.pl script to check for these issues.
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index a85d719..ddcd2d0 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2925,7 +2925,7 @@ sub process {
}
# check for invalid commit id
- if ($in_commit_log && $line =~
/(^fixes:|\bcommit)\s+([0-9a-f]{6,40})\b/i) {
+ if ($in_commit_log && $line =~
/(\bcommit)\s+([0-9a-f]{6,40})\b/i) {
my $id;
my $description;
($id, $description) = git_commit_info($2, undef, undef);
@@ -2935,6 +2935,25 @@ sub process {
}
}
+# check for fixes tag
+ if ($in_commit_log && $line =~
/(^fixes:)\s+([0-9a-f]{6,40})\b/i) {
+ my $id;
+ my $description;
+ ($id, $description) = git_commit_info($2, undef, undef);
+ if (!defined($id)) {
+ WARN("UNKNOWN_COMMIT_ID",
+"Unknown commit id '$2', maybe rebased or not
pulled?\n" .
$herecurr);
+ }
+ if ($1 ne "Fixes") {
+ WARN("FIXES_TAG_STYLE",
+"The fixes tag should be capitalized
(Fixes:).\n" . $hereprev);
+ }
+ if (length($2) < 12) {
+ WARN("FIXES_TAG_STYLE",
+"SHA1 should be at least 12 digits
long.\n" . $hereprev);
+ }
+ }
+
# ignore non-hunk lines and lines being removed
next if (!$hunk_line || $line =~ /^-/);
--
Best wishes,
Wen Yang
Re: [PATCH] media: st-mipid02: add a check for devm_gpiod_get_optional
Hello Chuhong,
Is this check necessary ?
since looking into code it seems to me devm_gpiod_get_optional() can only
return NULL in case of error due to following check in
devm_gpiod_get_index_optional()
if (IS_ERR(desc)) {
if (PTR_ERR(desc) == -ENOENT)
return NULL;
}
And in that case reset_gpio is not used
Regards
Mickael
On 10/16/19 12:56, Chuhong Yuan wrote:
> mipid02_probe misses a check for devm_gpiod_get_optional and may miss
> the failure.
> Add a check to fix the problem.
>
> Signed-off-by: Chuhong Yuan
> ---
> drivers/media/i2c/st-mipid02.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/media/i2c/st-mipid02.c b/drivers/media/i2c/st-mipid02.c
> index 81285b8d5cfb..d38e888b0a43 100644
> --- a/drivers/media/i2c/st-mipid02.c
> +++ b/drivers/media/i2c/st-mipid02.c
> @@ -971,6 +971,9 @@ static int mipid02_probe(struct i2c_client *client)
> bridge->reset_gpio = devm_gpiod_get_optional(dev, "reset",
>GPIOD_OUT_HIGH);
>
> + if (IS_ERR(bridge->reset_gpio))
> + return PTR_ERR(bridge->reset_gpio);
> +
> ret = mipid02_get_regulators(bridge);
> if (ret) {
> dev_err(dev, "failed to get regulators %d", ret);
>
Re: [PATCH] net: mscc: ocelot: add missing of_node_put after calling of_get_child_by_name
On 2019/10/2 1:02 上午, David Miller wrote:
From: Wen Yang
Date: Sun, 29 Sep 2019 14:54:24 +0800
of_node_put needs to be called when the device node which is got
from of_get_child_by_name finished using.
In both cases of success and failure, we need to release 'ports',
so clean up the code using goto.
fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")
Signed-off-by: Wen Yang
Applied.
Thank you for your comments.
We checked the code repository and found that both ‘Fixes’ and ‘fixes’
are being used, such as:
commit a53651ec93a8d7ab5b26c5390e0c389048b4b4b6
…
net: ena: don't wake up tx queue when down
…
fixes: 1738cd3ed342 (net: ena: Add a driver for Amazon Elastic
Network Adapters (ENA))
…
And,
commit 1df379924304b687263942452836db1d725155df
…
clk: consoldiate the __clk_get_hw() declarations
…
Fixes: 59fcdce425b7 ("clk: Remove ifdef for COMMON_CLK in
clk-provider.h")
fixes: 73e0e496afda ("clkdev: Always allocate a struct clk and call
__clk_get() w/ CCF")
…
It is also found that the sha1 following ‘Fixes:’ requires at least 12
digits.
So we plan to modify the checkpatch.pl script to check for these issues.
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index a85d719..ddcd2d0 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2925,7 +2925,7 @@ sub process {
}
# check for invalid commit id
- if ($in_commit_log && $line =~
/(^fixes:|\bcommit)\s+([0-9a-f]{6,40})\b/i) {
+ if ($in_commit_log && $line =~
/(\bcommit)\s+([0-9a-f]{6,40})\b/i) {
my $id;
my $description;
($id, $description) = git_commit_info($2, undef, undef);
@@ -2935,6 +2935,25 @@ sub process {
}
}
+# check for fixes tag
+ if ($in_commit_log && $line =~
/(^fixes:)\s+([0-9a-f]{6,40})\b/i) {
+ my $id;
+ my $description;
+ ($id, $description) = git_commit_info($2, undef, undef);
+ if (!defined($id)) {
+ WARN("UNKNOWN_COMMIT_ID",
+ "Unknown commit id '$2', maybe rebased or not pulled?\n" .
$herecurr);
+ }
+ if ($1 ne "Fixes") {
+ WARN("FIXES_TAG_STYLE",
+"The fixes tag should be capitalized
(Fixes:).\n" . $hereprev);
+ }
+ if (length($2) < 12) {
+ WARN("FIXES_TAG_STYLE",
+"SHA1 should be at least 12 digits
long.\n" . $hereprev);
+ }
+ }
+
# ignore non-hunk lines and lines being removed
next if (!$hunk_line || $line =~ /^-/);
--
Best wishes,
Wen Yang
Re: WARNING: bad unlock balance in rcu_lock_release
On Tue, Oct 15, 2019 at 09:56:31AM +0200, Jan Kara wrote:
> On Sun 13-10-19 14:28:06, syzbot wrote:
> > syzbot has found a reproducer for the following crash on:
> >
> > HEAD commit:da940012 Merge tag 'char-misc-5.4-rc3' of git://git.kernel..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=12cfdf4f60
> > kernel config: https://syzkaller.appspot.com/x/.config?x=2d2fd92a28d3e50
> > dashboard link: https://syzkaller.appspot.com/bug?extid=f9545ab3e9f85cd43a3a
> > compiler: clang version 9.0.0 (/home/glider/llvm/clang
> > 80fee25776c2fb61e74c1ecb1a523375c2500b69)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=148c9fc760
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=100d3f8b60
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+f9545ab3e9f85cd43...@syzkaller.appspotmail.com
> >
> > =
> > WARNING: bad unlock balance detected!
> > 5.4.0-rc2+ #0 Not tainted
> > -
> > syz-executor111/7877 is trying to release lock (rcu_callback) at:
> > [] rcu_lock_release+0x4/0x20 include/linux/rcupdate.h:212
> > but there are no more locks to release!
>
> Hum, this is really weird. Look:
>
> > other info that might help us debug this:
> > 1 lock held by syz-executor111/7877:
> > #0: 8880a3c600d8 (>s_umount_key#42/1){+.+.}, at:
> > alloc_super+0x15f/0x790 fs/super.c:229
> >
> > stack backtrace:
> > CPU: 1 PID: 7877 Comm: syz-executor111 Not tainted 5.4.0-rc2+ #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> >
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
> > print_unlock_imbalance_bug+0x20b/0x240 kernel/locking/lockdep.c:4008
> > __lock_release kernel/locking/lockdep.c:4244 [inline]
> > lock_release+0x473/0x780 kernel/locking/lockdep.c:4506
> > rcu_lock_release+0x1c/0x20 include/linux/rcupdate.h:214
> > __rcu_reclaim kernel/rcu/rcu.h:223 [inline]
>
> __rcu_reclaim_kernel() has:
>
> rcu_lock_acquire(_callback_map);
> if (__is_kfree_rcu_offset(offset)) {
> trace_rcu_invoke_kfree_callback(rn, head, offset);
> kfree((void *)head - offset);
> rcu_lock_release(_callback_map);
> return true;
> } else {
> trace_rcu_invoke_callback(rn, head);
> f = head->func;
> WRITE_ONCE(head->func, (rcu_callback_t)0L);
> f(head);
> rcu_lock_release(_callback_map);
> return false;
> }
>
> So RCU locking is clearly balanced there. The only possibility I can see
> how this can happen is that RCU callback we have called actually released
> rcu_callback_map but grepping the kernel doesn't show any other place where
> that would get released? Confused.
>
> But apparently there is even a reproducer for this so we could dig
> further...
>
It's probably the same cause as "WARNING: bad unlock balance in rcu_core", see
the thread:
https://lkml.kernel.org/linux-fsdevel/c0bffa0586795...@google.com/T/#u
Looks related to the lockdep_off() in ntfs_fill_super().
- Eric
Re: [PATCH V2] mm/page_alloc: Add alloc_contig_pages()
On 10/16/2019 10:18 PM, David Hildenbrand wrote: > On 16.10.19 17:31, Anshuman Khandual wrote: >> >> >> On 10/16/2019 06:11 PM, Michal Hocko wrote: >>> On Wed 16-10-19 14:29:05, David Hildenbrand wrote: On 16.10.19 13:51, Michal Hocko wrote: > On Wed 16-10-19 16:43:57, Anshuman Khandual wrote: >> >> >> On 10/16/2019 04:39 PM, David Hildenbrand wrote: > [...] >>> Just to make sure, you ignored my comment regarding alignment >>> although I explicitly mentioned it a second time? Thanks. >> >> I had asked Michal explicitly what to be included for the respin. Anyways >> seems like the previous thread is active again. I am happy to incorporate >> anything new getting agreed on there. > > Your patch is using the same alignment as the original code would do. If > an explicit alignement is needed then this can be added on top, right? > Again, the "issue" I see here is that we could now pass in numbers that are not a power of two. For gigantic pages it was clear that we always have a number of two. The alignment does not make any sense otherwise. >> >> ALIGN() does expect nr_pages two be power of two otherwise the mask >> value might not be correct, affecting start pfn value for a zone. >> >> #define ALIGN(x, a) __ALIGN_KERNEL((x), (a)) >> #define __ALIGN_KERNEL(x, a) __ALIGN_KERNEL_MASK(x, >> (typeof(x))(a) - 1) >> #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask)) >> What I'm asking for is a) Document "The resulting PFN is aligned to nr_pages" and "nr_pages should be a power of two". >>> >>> OK, this makes sense. >> Sure, will add this to the alloc_contig_pages() helper description and >> in the commit message as well. > > As long as it is documented that implicit alignment will happen, fine with me. > > The thing about !is_power_of2() is that we usually don't need an alignment > there (or instead an explicit one). And as I mentioned, the current function > might fail easily to allocate a suitable range due to the way the search > works (== check aligned blocks only). The search really only provides > reliable results when size==alignment and it's a power of two IMHO. Not > documenting that is in my opinion misleading - somebody who wants > !is_power_of2() and has no alignment requirements should probably rework the > function first. > > So with some documentation regarding that Does this add-on documentation look okay ? Should we also mention about the possible reduction in chances of success during pfn block search for the non-power-of-two cases as the implicit alignment will probably turn out to be bigger than nr_pages itself ? * Requested nr_pages may or may not be power of two. The search for suitable * memory range in a zone happens in nr_pages aligned pfn blocks. But in case * when nr_pages is not power of two, an implicitly aligned pfn block search * will happen which in turn will impact allocated memory block's alignment. * In these cases, the size (i.e nr_pages) and the alignment of the allocated * memory will be different. This problem does not exist when nr_pages is power * of two where the size and the alignment of the allocated memory will always * be nr_pages. > > Acked-by: David Hildenbrand >
RE: [EXT] [PATCH v1 3/3] tty: serial: lpuart: Add RS485 support for 32-bit uart flavour
From: Philippe Schenker Sent: Wednesday,
October 16, 2019 11:19 PM
> This commits adds RS485 support for LPUART hardware that uses 32-bit
> registers. These are typically found in i.MX8 processors.
>
> Signed-off-by: Philippe Schenker
Reviewed-by: Fugang Duan
>
> ---
>
> drivers/tty/serial/fsl_lpuart.c | 65 -
> 1 file changed, 63 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/fsl_lpuart.c
> b/drivers/tty/serial/fsl_lpuart.c index
> 346b4a070ce9..22df5f8f48b6 100644
> --- a/drivers/tty/serial/fsl_lpuart.c
> +++ b/drivers/tty/serial/fsl_lpuart.c
> @@ -1280,6 +1280,57 @@ static int lpuart_config_rs485(struct uart_port
> *port,
> return 0;
> }
>
> +static int lpuart32_config_rs485(struct uart_port *port,
> + struct serial_rs485 *rs485) {
> + struct lpuart_port *sport = container_of(port,
> + struct lpuart_port, port);
> +
> + unsigned long modem = lpuart32_read(>port, UARTMODIR)
> + & ~(UARTMODEM_TXRTSPOL |
> UARTMODEM_TXRTSE);
> + lpuart32_write(>port, modem, UARTMODIR);
> +
> + /* clear unsupported configurations */
> + rs485->delay_rts_before_send = 0;
> + rs485->delay_rts_after_send = 0;
> + rs485->flags &= ~SER_RS485_RX_DURING_TX;
> +
> + if (rs485->flags & SER_RS485_ENABLED) {
> + /* Enable auto RS-485 RTS mode */
> + modem |= UARTMODEM_TXRTSE;
> +
> + /*
> +* RTS needs to be logic HIGH either during transer _or_
> after
> +* transfer, other variants are not supported by the
> hardware.
> +*/
> +
> + if (!(rs485->flags & (SER_RS485_RTS_ON_SEND |
> + SER_RS485_RTS_AFTER_SEND)))
> + rs485->flags |= SER_RS485_RTS_ON_SEND;
> +
> + if (rs485->flags & SER_RS485_RTS_ON_SEND &&
> + rs485->flags &
> SER_RS485_RTS_AFTER_SEND)
> + rs485->flags &=
> ~SER_RS485_RTS_AFTER_SEND;
> +
> + /*
> +* The hardware defaults to RTS logic HIGH while
> transfer.
> +* Switch polarity in case RTS shall be logic HIGH
> +* after transfer.
> +* Note: UART is assumed to be active high.
> +*/
> + if (rs485->flags & SER_RS485_RTS_ON_SEND)
> + modem &= ~UARTMODEM_TXRTSPOL;
> + else if (rs485->flags & SER_RS485_RTS_AFTER_SEND)
> + modem |= UARTMODEM_TXRTSPOL;
> + }
> +
> + /* Store the new configuration */
> + sport->port.rs485 = *rs485;
> +
> + lpuart32_write(>port, modem, UARTMODIR);
> + return 0;
> +}
> +
> static unsigned int lpuart_get_mctrl(struct uart_port *port) {
> unsigned int temp = 0;
> @@ -1878,6 +1929,13 @@ lpuart32_set_termios(struct uart_port *port,
> struct ktermios *termios,
> ctrl |= UARTCTRL_M;
> }
>
> + /*
> +* When auto RS-485 RTS mode is enabled,
> +* hardware flow control need to be disabled.
> +*/
> + if (sport->port.rs485.flags & SER_RS485_ENABLED)
> + termios->c_cflag &= ~CRTSCTS;
> +
> if (termios->c_cflag & CRTSCTS) {
> modem |= (UARTMODIR_RXRTSE |
> UARTMODIR_TXCTSE);
> } else {
> @@ -2405,7 +2463,10 @@ static int lpuart_probe(struct platform_device
> *pdev)
> sport->port.ops = _pops;
> sport->port.flags = UPF_BOOT_AUTOCONF;
>
> - sport->port.rs485_config = lpuart_config_rs485;
> + if (lpuart_is_32(sport))
> + sport->port.rs485_config = lpuart32_config_rs485;
> + else
> + sport->port.rs485_config = lpuart_config_rs485;
>
> sport->ipg_clk = devm_clk_get(>dev, "ipg");
> if (IS_ERR(sport->ipg_clk)) {
> @@ -2459,7 +2520,7 @@ static int lpuart_probe(struct platform_device
> *pdev)
> sport->port.rs485.delay_rts_after_send)
> dev_err(>dev, "driver doesn't support RTS
> delays\n");
>
> - lpuart_config_rs485(>port, >port.rs485);
> + sport->port.rs485_config(>port, >port.rs485);
>
> sport->dma_tx_chan =
> dma_request_slave_channel(sport->port.dev, "tx");
> if (!sport->dma_tx_chan)
> --
> 2.23.0
RE: [EXT] [PATCH v1 2/3] tty: serial: lpuart: Use defines that correspond to correct register
From: Philippe Schenker Sent: Wednesday,
October 16, 2019 11:19 PM
> Use UARTMODIR defines instead of UARTMODEM as it is a 32-bit function
>
> Signed-off-by: Philippe Schenker
Reviewed-by: Fugang Duan
> ---
>
> drivers/tty/serial/fsl_lpuart.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/fsl_lpuart.c
> b/drivers/tty/serial/fsl_lpuart.c index
> f3271857621c..346b4a070ce9 100644
> --- a/drivers/tty/serial/fsl_lpuart.c
> +++ b/drivers/tty/serial/fsl_lpuart.c
> @@ -1879,10 +1879,10 @@ lpuart32_set_termios(struct uart_port *port,
> struct ktermios *termios,
> }
>
> if (termios->c_cflag & CRTSCTS) {
> - modem |= UARTMODEM_RXRTSE |
> UARTMODEM_TXCTSE;
> + modem |= (UARTMODIR_RXRTSE |
> UARTMODIR_TXCTSE);
> } else {
> termios->c_cflag &= ~CRTSCTS;
> - modem &= ~(UARTMODEM_RXRTSE |
> UARTMODEM_TXCTSE);
> + modem &= ~(UARTMODIR_RXRTSE |
> UARTMODIR_TXCTSE);
> }
>
> if (termios->c_cflag & CSTOPB)
> --
> 2.23.0
RE: [EXT] [PATCH v1 1/3] tty: serial: lpuart: Remove unnecessary code from set_mctrl
From: Philippe Schenker Sent: Wednesday,
October 16, 2019 11:19 PM
> Currently flow control is not working due to lpuart32_set_mctrl that is
> clearing TXCTSE bit in all cases. This bit gets earlier setup by
> lpuart32_set_termios.
>
> As I read in Documentation set_mctrl is also not meant for hardware flow
> control rather than gpio setting and clearing a RTS signal.
> Therefore I guess it is safe to remove the whole code in lpuart32_set_mctrl.
>
> This was tested with console on a i.MX8QXP SoC.
>
> Signed-off-by: Philippe Schenker
Reviewed-by: Fugang Duan
> ---
>
> drivers/tty/serial/fsl_lpuart.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/tty/serial/fsl_lpuart.c
> b/drivers/tty/serial/fsl_lpuart.c index
> 537896c4d887..f3271857621c 100644
> --- a/drivers/tty/serial/fsl_lpuart.c
> +++ b/drivers/tty/serial/fsl_lpuart.c
> @@ -1333,18 +1333,7 @@ static void lpuart_set_mctrl(struct uart_port
> *port, unsigned int mctrl)
>
> static void lpuart32_set_mctrl(struct uart_port *port, unsigned int mctrl) {
> - unsigned long temp;
> -
> - temp = lpuart32_read(port, UARTMODIR) &
> - ~(UARTMODIR_RXRTSE |
> UARTMODIR_TXCTSE);
> -
> - if (mctrl & TIOCM_RTS)
> - temp |= UARTMODIR_RXRTSE;
> -
> - if (mctrl & TIOCM_CTS)
> - temp |= UARTMODIR_TXCTSE;
>
> - lpuart32_write(port, temp, UARTMODIR);
> }
>
> static void lpuart_break_ctl(struct uart_port *port, int break_state)
> --
> 2.23.0
Re: [PATCH v2] Bluetooth: hci_core: fix init for HCI_USER_CHANNEL
Hi Mattijs,
> During the setup() stage, HCI device drivers expect the chip to
> acknowledge its setup() completion via vendor specific frames.
>
> If userspace opens() such HCI device in HCI_USER_CHANNEL [1] mode,
> the vendor specific frames are never tranmitted to the driver, as
> they are filtered in hci_rx_work().
>
> Allow HCI devices which operate in HCI_USER_CHANNEL mode to receive
> frames if the HCI device is is HCI_INIT state.
>
> [1] https://www.spinics.net/lists/linux-bluetooth/msg37345.html
>
> Fixes: 23500189d7e0 ("Bluetooth: Introduce new HCI socket channel for user
> operation")
> Signed-off-by: Mattijs Korpershoek
> ---
> Changelog:
> v2:
> * change test logic to transfer packets when in INIT phase
> for user channel mode as recommended by Marcel
> * renamed patch from
> "Bluetooth: hci_core: fix init with HCI_QUIRK_NON_PERSISTENT_SETUP"
>
> v1:
> * https://lkml.org/lkml/2019/10/3/2250
>
> Some more background on the change follows:
>
> The Android bluetooth stack (Bluedroid) also has a HAL implementation
> which follows Linux's standard rfkill interface [1].
>
> This implementation relies on the HCI_CHANNEL_USER feature to get
> exclusive access to the underlying bluetooth device.
>
> When testing this along with the btkmtksdio driver, the
> chip appeared unresponsive when calling the following from userspace:
>
>struct sockaddr_hci addr;
>int fd;
>
>fd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);
>
>memset(, 0, sizeof(addr));
>addr.hci_family = AF_BLUETOOTH;
>addr.hci_dev = 0;
>addr.hci_channel = HCI_CHANNEL_USER;
>
>bind(fd, (struct sockaddr *) , sizeof(addr)); # device hangs
>
> In the case of bluetooth drivers exposing QUIRK_NON_PERSISTENT_SETUP
> such as btmtksdio, setup() is called each multiple times.
> In particular, when userspace calls bind(), the setup() is called again
> and vendor specific commands might be send to re-initialize the chip.
>
> Those commands are filtered out by hci_core in HCI_CHANNEL_USER mode,
> preventing setup() from completing successfully.
>
> This has been tested on a 4.19 kernel based on Android Common Kernel.
> It has also been compile tested on bluetooth-next.
>
> [1]
> https://android.googlesource.com/platform/system/bt/+/refs/heads/master/vendor_libs/linux/interface/
>
> net/bluetooth/hci_core.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
Re: [PATCH 4.19 00/81] 4.19.80-stable review
stable-rc/linux-4.19.y boot: 106 boots: 0 failed, 99 passed with 7 offline (v4.19.79-82-g99661e9ccf92) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.79-82-g99661e9ccf92/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.79-82-g99661e9ccf92/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.79-82-g99661e9ccf92 Git Commit: 99661e9ccf9206876ca8f509555b7b0d3e45cc13 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 69 unique boards, 23 SoC families, 15 builds out of 206 Offline Platforms: arm: sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab multi_v7_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab --- For more info write to
Re: [PATCH 5.3 000/112] 5.3.7-stable review
stable-rc/linux-5.3.y boot: 118 boots: 1 failed, 109 passed with 7 offline, 1 untried/unknown (v5.3.6-112-gcbb18cd3e478) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.3.y/kernel/v5.3.6-112-gcbb18cd3e478/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.3.y/kernel/v5.3.6-112-gcbb18cd3e478/ Tree: stable-rc Branch: linux-5.3.y Git Describe: v5.3.6-112-gcbb18cd3e478 Git Commit: cbb18cd3e47885e336b42ce05d553b44e1e3a7a0 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 78 unique boards, 25 SoC families, 17 builds out of 208 Boot Failure Detected: arm64: defconfig: gcc-8: meson-gxm-khadas-vim2: 1 failed lab Offline Platforms: arm: sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab multi_v7_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab --- For more info write to
linux-next: Tree for Oct 17
Hi all, Changes since 20191016: Non-merge commits (relative to Linus' tree): 4283 4317 files changed, 145570 insertions(+), 67942 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 315 trees (counting Linus' and 78 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (bc88f85c6c09 kthread: make __kthread_queue_delayed_work static) Merging fixes/master (54ecb8f7028c Linux 5.4-rc1) Merging kbuild-current/fixes (991b78fbd223 scripts: setlocalversion: fix a bashism) Merging arc-current/for-curr (41277ba7eb4e ARC: mm: tlb flush optim: elide redundant uTLB invalidates for MMUv3) Merging arm-current/fixes (4c0742f65b4e ARM: 8914/1: NOMMU: Fix exc_ret for XIP) Merging arm-soc-fixes/arm/fixes (dd163ca3fb49 Merge tag 'mvebu-fixes-5.4-1' of git://git.infradead.org/linux-mvebu into arm/fixes) Merging arm64-fixes/for-next/fixes (597399d0cb91 arm64: tags: Preserve tags for addresses translated via TTBR1) Merging m68k-current/for-linus (0f1979b402df m68k: Remove ioremap_fullcache()) Merging powerpc-fixes/fixes (2272905a4580 spufs: fix a crash in spufs_create_root()) Merging s390-fixes/fixes (062795fcdcb2 s390/uaccess: avoid (false positive) compiler warnings) Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (2ca4f6ca4562 rxrpc: use rcu protection while reading sk->sk_user_data) Merging bpf/master (9e8acd9c44a0 bpf: lwtunnel: Fix reroute supplying invalid dst) Merging ipsec/master (68ce6688a5ba net: sched: taprio: Fix potential integer overflow in taprio_set_picos_per_byte) Merging netfilter/master (503c9addef61 ptp: fix typo of "mechanism" in Kconfig help text) Merging ipvs/master (503c9addef61 ptp: fix typo of "mechanism" in Kconfig help text) Merging wireless-drivers/master (d79749f7716d ath10k: fix latency issue for QCA988x) Merging mac80211/master (82ad862115c2 Merge branch 'smc-fixes') Merging rdma-fixes/for-rc (0417791536ae RDMA/mlx5: Add missing synchronize_srcu() for MW cases) Merging sound-current/for-linus (130bce3afbbb ALSA: hdac: clear link output stream mapping) Merging sound-asoc-fixes/for-linus (a4ff7dff4e65 Merge branch 'asoc-5.4' into asoc-linus) Merging regmap-fixes/for-linus (da0c9ea146cb Linux 5.4-rc2) Merging regulator-fixes/for-linus (68a2d13c4d54 Merge branch 'regulator-5.4' into regulator-linus) Merging spi-fixes/for-linus (09ee9e1664ba Merge branch 'spi-5.4' into spi-linus) Merging pci-current/for-linus (54ecb8f7028c Linux 5.4-rc1) Merging driver-core.current/driver-core-linus (82af5b660967 sysfs: Fixes __BIN_ATTR_WO() macro) Merging tty.current/tty-linus (f50b6805dbb9 8250-men-mcb: fix error checking when get_num_ports returns -ENODEV) Merging usb.current/usb-linus (7a7591979748 USB: usblp: fix use-after-free on disconnect) Merging usb-gadget-fixes/fixes (4a56a478a525 usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt) Merging usb-serial-fixes/usb-linus (bc25770f00d3 USB: serial: ti_usb_3410_5052: clean up serial data access) Merging usb-chipidea-fixes/ci-for-usb-stable (16009db47c51 usb: chipidea: udc: workaround for endpoint conflict issue) Merging phy/fixes (68eeb39a53d5 phy: qcom-usb-hs: Fix extcon
Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the DPDMAI(Data Path DMA Interface) support
On 30-09-19, 02:04, Peng Ma wrote: > The MC(Management Complex) exports the DPDMAI(Data Path DMA Interface) > object as an interface to operate the DPAA2(Data Path Acceleration > Architecture 2) qDMA Engine. The DPDMAI enables sending frame-based > requests to qDMA and receiving back confirmation response on transaction > completion, utilizing the DPAA2 QBMan(Queue Manager and Buffer Manager > hardware) infrastructure. DPDMAI object provides up to two priorities for > processing qDMA requests. > The following list summarizes the DPDMAI main features and capabilities: > 1. Supports up to two scheduling priorities for processing > service requests. > - Each DPDMAI transmit queue is mapped to one of two service > priorities, allowing further prioritization in hardware between > requests from different DPDMAI objects. > 2. Supports up to two receive queues for incoming transaction > completion confirmations. > - Each DPDMAI receive queue is mapped to one of two receive > priorities, allowing further prioritization between other > interfaces when associating the DPDMAI receive queues to DPIO > or DPCON(Data Path Concentrator) objects. > 3. Supports different scheduling options for processing received > packets: > - Queues can be configured either in 'parked' mode (default), > or attached to a DPIO object, or attached to DPCON object. > 4. Allows interaction with one or more DPIO objects for > dequeueing/enqueueing frame descriptors(FD) and for > acquiring/releasing buffers. > 5. Supports enable, disable, and reset operations. > > Add dpdmai to support some platforms with dpaa2 qdma engine. Applied both, thanks -- ~Vinod
RE: [PATCH 2/2] usb: cdns3: Add TI specific wrapper driver
Hi Roger,
>The J721e platform comes with 2 Cadence USB3 controller
>
>instances. This driver supports the TI specific wrapper
>
>on this platform.
>
>
>
>Signed-off-by: Roger Quadros
>
>Signed-off-by: Sekhar Nori
>
>---
>
> drivers/usb/cdns3/Kconfig| 10 ++
>
> drivers/usb/cdns3/Makefile | 1 +
>
> drivers/usb/cdns3/cdns3-ti.c | 244 +++
>
> 3 files changed, 255 insertions(+)
>
> create mode 100644 drivers/usb/cdns3/cdns3-ti.c
>
>
>
>diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig
>
>index d0331613a355..2a1e89d12ed9 100644
>
>--- a/drivers/usb/cdns3/Kconfig
>
>+++ b/drivers/usb/cdns3/Kconfig
>
>@@ -43,4 +43,14 @@ config USB_CDNS3_PCI_WRAP
>
> If you choose to build this driver as module it will
>
> be dynamically linked and module will be called cdns3-pci.ko
>
>
>
>+config USB_CDNS3_TI
>
>+ tristate "Cadence USB3 support on TI platforms"
>
>+ depends on ARCH_K3 || COMPILE_TEST
>
>+ default USB_CDNS3
>
>+ help
>
>+Say 'Y' or 'M' here if you are building for Texas Instruments
>
>+platforms that contain Cadence USB3 controller core.
>
>+
>
>+e.g. J721e.
>
>+
>
> endif
>
>diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
>
>index a703547350bb..948e6b88d1a9 100644
>
>--- a/drivers/usb/cdns3/Makefile
>
>+++ b/drivers/usb/cdns3/Makefile
>
>@@ -14,3 +14,4 @@ endif
>
> cdns3-$(CONFIG_USB_CDNS3_HOST)+= host.o
>
>
>
> obj-$(CONFIG_USB_CDNS3_PCI_WRAP) += cdns3-pci-wrap.o
>
>+obj-$(CONFIG_USB_CDNS3_TI)+= cdns3-ti.o
>
>diff --git a/drivers/usb/cdns3/cdns3-ti.c b/drivers/usb/cdns3/cdns3-ti.c
>
>new file mode 100644
>
>index ..7447f5fcbe64
>
>--- /dev/null
>
>+++ b/drivers/usb/cdns3/cdns3-ti.c
>
>@@ -0,0 +1,244 @@
>
>+// SPDX-License-Identifier: GPL-2.0
>
>+/**
>
>+ * cdns_ti-ti.c - TI specific Glue layer for Cadence USB Controller
>
>+ *
>
>+ * Copyright (C) 2019 Texas Instruments Incorporated -
>https://urldefense.proofpoint.com/v2/url?u=http-
>3A__www.ti.com=DwIBAg=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY=e1OgxfvkL0qo9XO6fX1gscva-
>w03uSYC1nIyxl89-
>rI=cRVMFQ8EW2o1zPxOk40aNbOduH3ZSMTGs3Gjr6j7DIw=CX3YTCKJekxIRkpi36cPmm8eEH1NK7Ipaag0MVAL4cc=
>
>+ */
>
>+
>
>+#include
>
>+#include
>
>+#include
>
>+#include
>
>+#include
>
>+#include
>
>+#include
>
>+#include
>
>+#include
>
>+#include
>
>+
>
>+/* USB Wrapper register offsets */
>
>+#define USBSS_PID 0x0
>
>+#define USBSS_W10x4
>
>+#define USBSS_STATIC_CONFIG 0x8
>
>+#define USBSS_PHY_TEST0xc
>
>+#define USBSS_DEBUG_CTRL0x10
>
>+#define USBSS_DEBUG_INFO0x14
>
>+#define USBSS_DEBUG_LINK_STATE 0x18
>
>+#define USBSS_DEVICE_CTRL 0x1c
>
>+
>
>+/* Wrapper 1 register bits */
>
>+#define USBSS_W1_PWRUP_RSTBIT(0)
>
>+#define USBSS_W1_OVERCURRENT_SEL BIT(8)
>
>+#define USBSS_W1_MODESTRAP_SELBIT(9)
>
>+#define USBSS_W1_OVERCURRENT BIT(16)
>
>+#define USBSS_W1_MODESTRAP_MASK GENMASK(18, 17)
>
>+#define USBSS_W1_MODESTRAP_SHIFT 17
>
>+#define USBSS_W1_USB2_ONLYBIT(19)
>
>+
>
>+/* Static config register bits */
>
>+#define USBSS1_STATIC_PLL_REF_SEL_MASKGENMASK(8, 5)
>
>+#define USBSS1_STATIC_PLL_REF_SEL_SHIFT 5
>
>+#define USBSS1_STATIC_LOOPBACK_MODE_MASK GENMASK(4, 3)
>
>+#define USBSS1_STATIC_LOOPBACK_MODE_SHIFT 3
>
>+#define USBSS1_STATIC_VBUS_SEL_MASK GENMASK(2, 1)
>
>+#define USBSS1_STATIC_VBUS_SEL_SHIFT 1
>
>+#define USBSS1_STATIC_LANE_REVERSEBIT(0)
>
>+
>
>+/* Modestrap modes */
>
>+enum modestrap_mode { USBSS_MODESTRAP_MODE_NONE,
>
>+USBSS_MODESTRAP_MODE_HOST,
>
>+USBSS_MODESTRAP_MODE_PERIPHERAL};
>
>+
>
>+struct cdns_ti {
>
>+ struct device *dev;
>
>+ void __iomem *usbss;
>
>+ int usb2_only:1;
>
>+ int vbus_divider:1;
>
>+ struct clk *usb2_refclk;
>
>+ struct clk *lpm_clk;
>
>+};
>
>+
>
>+static const int cdns_ti_rate_table[] = { /* in KHZ */
>
>+ 9600,
>
>+ 1,
>
>+ 12000,
>
>+ 19200,
>
>+ 2,
>
>+ 24000,
>
>+ 25000,
>
>+ 26000,
>
>+ 38400,
>
>+ 4,
>
>+ 58000,
>
>+ 5,
>
>+ 52000,
>
>+};
>
>+
>
>+static inline u32 cdns_ti_readl(struct cdns_ti *data, u32 offset)
>
>+{
>
>+ return readl(data->usbss + offset);
>
>+}
>
>+
>
>+static inline void cdns_ti_writel(struct cdns_ti *data, u32 offset, u32 value)
>
>+{
>
>+ writel(value, data->usbss + offset);
>
>+}
>
>+
>
>+static int cdns_ti_probe(struct platform_device *pdev)
>
>+{
>
>+ struct device *dev = >dev;
>
>+ struct device_node *node = pdev->dev.of_node;
>
>+ struct cdns_ti *data;
>
>+ struct resource *res;
>
>+ int error;
>
>+ u32 reg;
>
>+ int modestrap_mode;
>
>+ int rate_code, i;
>
>+ unsigned long rate;
>
>+
>
>+ data =
I need Your Urgent assistance.
I need Your Urgent assistance. My name is Beatrice Johnson. The only daughter of the late Mr. Madou Johnson. Here in Burkina Faso, i got your profile while searching for contact on internet; I am contacting you to help me receive some amount of money in your country. So that I can travel To America to continue my education over there, Before my father died he deposited the Sum of ($4.5Million) in a bank here and he advised me before he died to look for a faithful and reliable foreigner, who can help receive the Funds outside country, So that I can travel to meet you in your country. For my share percentage of the total amount 4.5 Million, from your county I will travel to America to continue my education and business. I hope you are capable to receive the 4.5 Million in your country with trust. I will like to travel to your country immediately the bank wire the funds into your account. You will take 30% of the total 4.5 Million for your good and kind assistance to me. I will send to you the full details concerning the funds immediately I hear from you soon. My Regards, Beatrice Johnson.
Re: [PATCH net 0/4] net: bcmgenet: restore internal EPHY support
On 10/16/2019 4:06 PM, Doug Berger wrote: > I managed to get my hands on an old BCM97435SVMB board to do some > testing with the latest kernel and uncovered a number of things > that managed to get broken over the years (some by me ;). > > This commit set attempts to correct the errors I observed in my > testing. > > The first commit applies to all internal PHYs to restore proper > reporting of link status when a link comes up. > > The second commit restores the soft reset to the initialization of > the older internal EPHYs used by 40nm Set-Top Box devices. > > The third corrects a bug I introduced when removing excessive soft > resets by altering the initialization sequence in a way that keeps > the GENETv3 MAC interface happy. > > Finally, I observed a number of issues when manually configuring > the network interface of the older EPHYs that appear to be resolved > by the fourth commit. Thank you very much for addressing all of those problems! > > Doug Berger (4): > net: bcmgenet: don't set phydev->link from MAC > net: phy: bcm7xxx: define soft_reset for 40nm EPHY > net: bcmgenet: soft reset 40nm EPHYs before MAC init > net: bcmgenet: reset 40nm EPHY on energy detect > > drivers/net/ethernet/broadcom/genet/bcmgenet.c | 41 + > drivers/net/ethernet/broadcom/genet/bcmgenet.h | 2 +- > drivers/net/ethernet/broadcom/genet/bcmmii.c | 112 > +++-- > drivers/net/phy/bcm7xxx.c | 1 + > 4 files changed, 79 insertions(+), 77 deletions(-) > -- Florian
Re: [PATCH net 4/4] net: bcmgenet: reset 40nm EPHY on energy detect
On 10/16/2019 4:06 PM, Doug Berger wrote:
> The EPHY integrated into the 40nm Set-Top Box devices can falsely
> detect energy when connected to a disabled peer interface. When the
> peer interface is enabled the EPHY will detect and report the link
> as active, but on occasion may get into a state where it is not
> able to exchange data with the connected GENET MAC. This issue has
> not been observed when the link parameters are auto-negotiated;
> however, it has been observed with a manually configured link.
>
> It has been empirically determined that issuing a soft reset to the
> EPHY when energy is detected prevents it from getting into this bad
> state.
>
> Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
> Signed-off-by: Doug Berger
Acked-by: Florian Fainelli
--
Florian
Re: [PATCH RESEND v2] staging: wfx: fix an undefined reference error when CONFIG_MMC=m
On 2019/10/14 18:06, Jerome Pouiller wrote: > On Monday 14 October 2019 11:53:19 CEST Jérôme Pouiller wrote: > [...] >> Hello Zhong, >> >> Now, I see the problem. It happens when CONFIG_MMC=m and CONFIG_WFX=y >> (if CONFIG_WFX=m, it works). >> >> I think the easiest way to solve problem is to disallow CONFIG_WFX=y if >> CONFIG_MMC=m. >> >> This solution impacts users who want to use SPI bus with configuration: >> CONFIG_WFX=y + CONFIG_SPI=y + CONFIG_MMC=m. However, I think this is a >> twisted case. So, I think it won't be missed. >> >> I think that patch below do the right thing: >> >> -8<--8<--8<- >> >> diff --git i/drivers/staging/wfx/Kconfig w/drivers/staging/wfx/Kconfig >> index 9b8a1c7a9e90..833f3b05b6b4 100644 >> --- i/drivers/staging/wfx/Kconfig >> +++ w/drivers/staging/wfx/Kconfig >> @@ -1,7 +1,7 @@ >> config WFX >> tristate "Silicon Labs wireless chips WF200 and further" >> depends on MAC80211 >> - depends on (SPI || MMC) >> + depends on (MMC=m && m) || MMC=y || (SPI && MMC!=m) >> help >> This is a driver for Silicons Labs WFxxx series (WF200 and further) >> chipsets. This chip can be found on SPI or SDIO buses. >> >> >> > An alternative (more understandable?): > > diff --git i/drivers/staging/wfx/Kconfig w/drivers/staging/wfx/Kconfig > index 9b8a1c7a9e90..83ee4d0ca8c6 100644 > --- i/drivers/staging/wfx/Kconfig > +++ w/drivers/staging/wfx/Kconfig > @@ -1,6 +1,7 @@ > config WFX > tristate "Silicon Labs wireless chips WF200 and further" > depends on MAC80211 > + depends on MMC || !MMC # do not allow WFX=y if MMC=m > depends on (SPI || MMC) > help > This is a driver for Silicons Labs WFxxx series (WF200 and further) > > Hi, Jerome It's better to understandable. Could you send the patch or want to repost by me? Thanks, zhong jiang
[PATCH -next] CIFS: remove set but not used variables 'cinode' and 'netfid'
Fixes gcc '-Wunused-but-set-variable' warning: fs/cifs/file.c: In function 'cifs_flock': fs/cifs/file.c:1704:8: warning: variable 'netfid' set but not used [-Wunused-but-set-variable] fs/cifs/file.c:1702:24: warning: variable 'cinode' set but not used [-Wunused-but-set-variable] Reported-by: Hulk Robot Signed-off-by: YueHaibing --- fs/cifs/file.c | 4 1 file changed, 4 deletions(-) diff --git a/fs/cifs/file.c b/fs/cifs/file.c index 936e03892e2a..02a81dc6861a 100644 --- a/fs/cifs/file.c +++ b/fs/cifs/file.c @@ -1699,9 +1699,7 @@ int cifs_flock(struct file *file, int cmd, struct file_lock *fl) bool posix_lck = false; struct cifs_sb_info *cifs_sb; struct cifs_tcon *tcon; - struct cifsInodeInfo *cinode; struct cifsFileInfo *cfile; - __u16 netfid; __u32 type; rc = -EACCES; @@ -1716,8 +1714,6 @@ int cifs_flock(struct file *file, int cmd, struct file_lock *fl) cifs_read_flock(fl, , , , _flag, tcon->ses->server); cifs_sb = CIFS_FILE_SB(file); - netfid = cfile->fid.netfid; - cinode = CIFS_I(file_inode(file)); if (cap_unix(tcon->ses) && (CIFS_UNIX_FCNTL_CAP & le64_to_cpu(tcon->fsUnixInfo.Capability)) &&
Re: [PATCH net 3/4] net: bcmgenet: soft reset 40nm EPHYs before MAC init
On 10/16/2019 4:06 PM, Doug Berger wrote:
> It turns out that the "Workaround for putting the PHY in IDDQ mode"
> used by the internal EPHYs on 40nm Set-Top Box chips when powering
> down puts the interface to the GENET MAC in a state that can cause
> subsequent MAC resets to be incomplete.
>
> Rather than restore the forced soft reset when powering up internal
> PHYs, this commit moves the invocation of phy_init_hw earlier in
> the MAC initialization sequence to just before the MAC reset in the
> open and resume functions. This allows the interface to be stable
> and allows the MAC resets to be successful.
>
> The bcmgenet_mii_probe() function is split in two to accommodate
> this. The new function bcmgenet_mii_connect() handles the first
> half of the functionality before the MAC initialization, and the
> bcmgenet_mii_config() function is extended to provide the remaining
> PHY configuration following the MAC initialization.
>
> Fixes: 484bfa1507bf ("Revert "net: bcmgenet: Software reset EPHY after power
> on"")
> Signed-off-by: Doug Berger
Acked-by: Florian Fainelli
We will have to see how difficult it might be to back port towards
stable trees of interest, hopefully not too difficult.
--
Florian
Re: [PATCH net 2/4] net: phy: bcm7xxx: define soft_reset for 40nm EPHY
On 10/16/2019 4:06 PM, Doug Berger wrote:
> The internal 40nm EPHYs use a "Workaround for putting the PHY in
> IDDQ mode." These PHYs require a soft reset to restore functionality
> after they are powered back up.
>
> This commit defines the soft_reset function to use genphy_soft_reset
> during phy_init_hw to accommodate this.
>
> Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
> Signed-off-by: Doug Berger
Acked-by: Florian Fainelli
--
Florian
Re: [PATCH net 1/4] net: bcmgenet: don't set phydev->link from MAC
On 10/16/2019 4:06 PM, Doug Berger wrote:
> When commit 28b2e0d2cd13 ("net: phy: remove parameter new_link from
> phy_mac_interrupt()") removed the new_link parameter it set the
> phydev->link state from the MAC before invoking phy_mac_interrupt().
>
> However, once commit 88d6272acaaa ("net: phy: avoid unneeded MDIO
> reads in genphy_read_status") was added this initialization prevents
> the proper determination of the connection parameters by the function
> genphy_read_status().
>
> This commit removes that initialization to restore the proper
> functionality.
>
> Fixes: 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in
> genphy_read_status")
> Signed-off-by: Doug Berger
Acked-by: Florian Fainelli
--
Florian
Re: [PATCH 0/4] [RFC] Migrate Pages in lieu of discard
On Wed, Oct 16, 2019 at 3:49 PM Dave Hansen wrote: > > We're starting to see systems with more and more kinds of memory such > as Intel's implementation of persistent memory. > > Let's say you have a system with some DRAM and some persistent memory. > Today, once DRAM fills up, reclaim will start and some of the DRAM > contents will be thrown out. Allocations will, at some point, start > falling over to the slower persistent memory. > > That has two nasty properties. First, the newer allocations can end > up in the slower persistent memory. Second, reclaimed data in DRAM > are just discarded even if there are gobs of space in persistent > memory that could be used. > > This set implements a solution to these problems. At the end of the > reclaim process in shrink_page_list() just before the last page > refcount is dropped, the page is migrated to persistent memory instead > of being dropped. > > While I've talked about a DRAM/PMEM pairing, this approach would > function in any environment where memory tiers exist. > > This is not perfect. It "strands" pages in slower memory and never > brings them back to fast DRAM. Other things need to be built to > promote hot pages back to DRAM. > > This is part of a larger patch set. If you want to apply these or > play with them, I'd suggest using the tree from here. It includes > autonuma-based hot page promotion back to DRAM: > > > http://lkml.kernel.org/r/c3d6de4d-f7c3-b505-2e64-8ee5f70b2...@intel.com > > This is also all based on an upstream mechanism that allows > persistent memory to be onlined and used as if it were volatile: > > http://lkml.kernel.org/r/20190124231441.37a4a...@viggo.jf.intel.com The memory cgroup part of the story is missing here. Since PMEM is treated as slow DRAM, shouldn't its usage be accounted to the corresponding memcg's memory/memsw counters and the migration should not happen for memcg limit reclaim? Otherwise some jobs can hog the whole PMEM. Also what happens when PMEM is full? Can the memory migrated to PMEM be reclaimed (or discarded)? Shakeel
Re: [PATCH -tip v4 0/4] x86: kprobes: Prohibit kprobes on Xen/KVM emulate prefixes
Hi Peter, On Wed, 9 Oct 2019 14:31:06 +0200 Peter Zijlstra wrote: > On Tue, Sep 17, 2019 at 03:14:03PM +0900, Masami Hiramatsu wrote: > > Hi Peter, > > > > Could you review this version? > > These look good to me; shall I merge them or what was the plan? Thanks for the review, yes, could you merge this series to support emulated prefixes correctly? Thank you, -- Masami Hiramatsu
Re: [PATCH net-next 00/12] net: hns3: add some bugfixes and optimizations
On 2019/10/17 1:50, David Miller wrote: From: Jakub Kicinski Date: Wed, 16 Oct 2019 10:19:43 -0700 On Wed, 16 Oct 2019 15:16:59 +0800, Huazhong Tan wrote: This patch-set includes some bugfixes and code optimizations for the HNS3 ethernet controller driver. The code LGTM, mostly, but it certainly seems like patches 2, 3 and 4 should be a separate series targeting the net tree :( Agreed, there are legitimate bug fixes. I have to say that I see this happening a lot, hns3 bug fixes targetting net-next in a larger series of cleanups and other kinds of changes. Please handle this delegation properly. Send bug fixes as a series targetting 'net', and send everything else targetting 'net-next'. Hi, David & Jakub. BTW, patch01 is a cleanup which is needed by patch02, if patch01 targetting 'net-next', patch02 targetting 'net', there will be a gap again. How should I deal with this case? MBR. Huazhong. .
[PATCH v2] Bluetooth: hci_core: fix init for HCI_USER_CHANNEL
During the setup() stage, HCI device drivers expect the chip to
acknowledge its setup() completion via vendor specific frames.
If userspace opens() such HCI device in HCI_USER_CHANNEL [1] mode,
the vendor specific frames are never tranmitted to the driver, as
they are filtered in hci_rx_work().
Allow HCI devices which operate in HCI_USER_CHANNEL mode to receive
frames if the HCI device is is HCI_INIT state.
[1] https://www.spinics.net/lists/linux-bluetooth/msg37345.html
Fixes: 23500189d7e0 ("Bluetooth: Introduce new HCI socket channel for user
operation")
Signed-off-by: Mattijs Korpershoek
---
Changelog:
v2:
* change test logic to transfer packets when in INIT phase
for user channel mode as recommended by Marcel
* renamed patch from
"Bluetooth: hci_core: fix init with HCI_QUIRK_NON_PERSISTENT_SETUP"
v1:
* https://lkml.org/lkml/2019/10/3/2250
Some more background on the change follows:
The Android bluetooth stack (Bluedroid) also has a HAL implementation
which follows Linux's standard rfkill interface [1].
This implementation relies on the HCI_CHANNEL_USER feature to get
exclusive access to the underlying bluetooth device.
When testing this along with the btkmtksdio driver, the
chip appeared unresponsive when calling the following from userspace:
struct sockaddr_hci addr;
int fd;
fd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);
memset(, 0, sizeof(addr));
addr.hci_family = AF_BLUETOOTH;
addr.hci_dev = 0;
addr.hci_channel = HCI_CHANNEL_USER;
bind(fd, (struct sockaddr *) , sizeof(addr)); # device hangs
In the case of bluetooth drivers exposing QUIRK_NON_PERSISTENT_SETUP
such as btmtksdio, setup() is called each multiple times.
In particular, when userspace calls bind(), the setup() is called again
and vendor specific commands might be send to re-initialize the chip.
Those commands are filtered out by hci_core in HCI_CHANNEL_USER mode,
preventing setup() from completing successfully.
This has been tested on a 4.19 kernel based on Android Common Kernel.
It has also been compile tested on bluetooth-next.
[1]
https://android.googlesource.com/platform/system/bt/+/refs/heads/master/vendor_libs/linux/interface/
net/bluetooth/hci_core.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index b2559d4bed81..0cc9ce917222 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -4440,7 +4440,14 @@ static void hci_rx_work(struct work_struct *work)
hci_send_to_sock(hdev, skb);
}
- if (hci_dev_test_flag(hdev, HCI_USER_CHANNEL)) {
+ /* If the device has been opened in HCI_USER_CHANNEL,
+* the userspace has exclusive access to device.
+* When device is HCI_INIT, we still need to process
+* the data packets to the driver in order
+* to complete its setup().
+*/
+ if (hci_dev_test_flag(hdev, HCI_USER_CHANNEL) &&
+ !test_bit(HCI_INIT, >flags)) {
kfree_skb(skb);
continue;
}
--
2.20.1
Re: [PATCH V2] mm/page_alloc: Add alloc_contig_pages()
On 10/17/2019 06:20 AM, Mike Kravetz wrote: > On 10/16/19 4:02 AM, Anshuman Khandual wrote: >> HugeTLB helper alloc_gigantic_page() implements fairly generic allocation >> method where it scans over various zones looking for a large contiguous pfn >> range before trying to allocate it with alloc_contig_range(). Other than >> deriving the requested order from 'struct hstate', there is nothing HugeTLB >> specific in there. This can be made available for general use to allocate >> contiguous memory which could not have been allocated through the buddy >> allocator. >> >> alloc_gigantic_page() has been split carving out actual allocation method >> which is then made available via new alloc_contig_pages() helper wrapped >> under CONFIG_CONTIG_ALLOC. All references to 'gigantic' have been replaced >> with more generic term 'contig'. Allocated pages here should be freed with >> free_contig_range() or by calling __free_page() on each allocated page. > > I had a 'test harness' used when previously working on such an interface. > It simply provides a user interface to call the allocator with random > values for nr_pages. Several tasks are then started doing random allocations > in parallel. The new interface is pretty straight forward, but the idea > was to stress the underlying code. In fact, it did identify issues with > isolation which were corrected. > > I exercised this new interface in the same way and am happy to report that > no issues were detected. Cool, thanks Mike.
[PATCH 3/3] arm64: dts: imx8mn: Add LPDDR4 EVK board support
i.MX8MN LPDDR4 EVK board shares most of the device as DDR4 EVK board,
the ONLY difference are the DDR type and PMIC, add support for it
and make it default i.MX8MN EVK board as usual.
The PMIC driver is NOT ready, so cpu-freq needs to be disabled as
it depends on regulator provided by PMIC.
Signed-off-by: Anson Huang
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/imx8mn-evk.dts | 30
2 files changed, 31 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-evk.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile
b/arch/arm64/boot/dts/freescale/Makefile
index 93fce8f..783a92c 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -22,6 +22,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-qds.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-hummingboard-pulse.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-evk.dts
b/arch/arm64/boot/dts/freescale/imx8mn-evk.dts
new file mode 100644
index 000..61f3519
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mn-evk.dts
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2019 NXP
+ */
+
+/dts-v1/;
+
+#include "imx8mn.dtsi"
+#include "imx8mn-evk.dtsi"
+
+/ {
+ model = "NXP i.MX8MNano EVK board";
+ compatible = "fsl,imx8mn-evk", "fsl,imx8mn";
+};
+
+_0 {
+ /delete-property/operating-points-v2;
+};
+
+_1 {
+ /delete-property/operating-points-v2;
+};
+
+_2 {
+ /delete-property/operating-points-v2;
+};
+
+_3 {
+ /delete-property/operating-points-v2;
+};
--
2.7.4
[PATCH 1/3] arm64: dts: imx8mn: Create EVK dtsi file for common use
i.MX8MN has different EVK boards to support different DDR types,
the ONLY differences are DDR chips and PMIC, so most of the devices
can be shared between these EVK boards, create a EVK dtsi file for
common use.
Signed-off-by: Anson Huang
---
- This patch is based on https://patchwork.kernel.org/patch/11192221/
---
arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts | 241 +
arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi | 252 ++
2 files changed, 253 insertions(+), 240 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
index 5c96203..0719494 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
@@ -6,71 +6,18 @@
/dts-v1/;
#include "imx8mn.dtsi"
+#include "imx8mn-evk.dtsi"
/ {
model = "NXP i.MX8MNano DDR4 EVK board";
compatible = "fsl,imx8mn-ddr4-evk", "fsl,imx8mn";
-
- chosen {
- stdout-path =
- };
-
- gpio-leds {
- compatible = "gpio-leds";
- pinctrl-names = "default";
- pinctrl-0 = <_gpio_led>;
-
- status {
- label = "yellow:status";
- gpios = < 16 GPIO_ACTIVE_HIGH>;
- default-state = "on";
- };
- };
-
- reg_usdhc2_vmmc: regulator-usdhc2 {
- compatible = "regulator-fixed";
- pinctrl-names = "default";
- pinctrl-0 = <_reg_usdhc2_vmmc>;
- regulator-name = "VSD_3V3";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- gpio = < 19 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
};
_0 {
cpu-supply = <_reg>;
};
- {
- pinctrl-names = "default";
- pinctrl-0 = <_fec1>;
- phy-mode = "rgmii-id";
- phy-handle = <>;
- fsl,magic-packet;
- status = "okay";
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ethphy0: ethernet-phy@0 {
- compatible = "ethernet-phy-ieee802.3-c22";
- reg = <0>;
- at803x,led-act-blind-workaround;
- at803x,eee-disabled;
- at803x,vddio-1p8v;
- };
- };
-};
-
{
- clock-frequency = <40>;
- pinctrl-names = "default";
- pinctrl-0 = <_i2c1>;
- status = "okay";
-
pmic@4b {
compatible = "rohm,bd71847";
reg = <0x4b>;
@@ -175,196 +122,10 @@
};
};
-_pwrkey {
- status = "okay";
-};
-
- { /* console */
- pinctrl-names = "default";
- pinctrl-0 = <_uart2>;
- status = "okay";
-};
-
- {
- assigned-clocks = < IMX8MN_CLK_USDHC2>;
- assigned-clock-rates = <2>;
- pinctrl-names = "default", "state_100mhz", "state_200mhz";
- pinctrl-0 = <_usdhc2>, <_usdhc2_gpio>;
- pinctrl-1 = <_usdhc2_100mhz>, <_usdhc2_gpio>;
- pinctrl-2 = <_usdhc2_200mhz>, <_usdhc2_gpio>;
- cd-gpios = < 15 GPIO_ACTIVE_LOW>;
- bus-width = <4>;
- vmmc-supply = <_usdhc2_vmmc>;
- status = "okay";
-};
-
- {
- assigned-clocks = < IMX8MN_CLK_USDHC3_ROOT>;
- assigned-clock-rates = <4>;
- pinctrl-names = "default", "state_100mhz", "state_200mhz";
- pinctrl-0 = <_usdhc3>;
- pinctrl-1 = <_usdhc3_100mhz>;
- pinctrl-2 = <_usdhc3_200mhz>;
- bus-width = <8>;
- non-removable;
- status = "okay";
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_wdog>;
- fsl,ext-reset-output;
- status = "okay";
-};
-
{
- pinctrl-names = "default";
-
- pinctrl_fec1: fec1grp {
- fsl,pins = <
- MX8MN_IOMUXC_ENET_MDC_ENET1_MDC 0x3
- MX8MN_IOMUXC_ENET_MDIO_ENET1_MDIO 0x3
- MX8MN_IOMUXC_ENET_TD3_ENET1_RGMII_TD3 0x1f
- MX8MN_IOMUXC_ENET_TD2_ENET1_RGMII_TD2 0x1f
- MX8MN_IOMUXC_ENET_TD1_ENET1_RGMII_TD1 0x1f
- MX8MN_IOMUXC_ENET_TD0_ENET1_RGMII_TD0 0x1f
- MX8MN_IOMUXC_ENET_RD3_ENET1_RGMII_RD3 0x91
- MX8MN_IOMUXC_ENET_RD2_ENET1_RGMII_RD2 0x91
- MX8MN_IOMUXC_ENET_RD1_ENET1_RGMII_RD1 0x91
- MX8MN_IOMUXC_ENET_RD0_ENET1_RGMII_RD0 0x91
- MX8MN_IOMUXC_ENET_TXC_ENET1_RGMII_TXC 0x1f
- MX8MN_IOMUXC_ENET_RXC_ENET1_RGMII_RXC 0x91
- MX8MN_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL 0x91
- MX8MN_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL 0x1f
-
[PATCH 2/3] dt-bindings: arm: imx: Add the i.MX8MN LPDDR4 EVK board
Add board binding for i.MX8MN LPDDR4 EVK board. Signed-off-by: Anson Huang --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 41db01d..2d8248a 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -246,6 +246,7 @@ properties: items: - enum: - fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board + - fsl,imx8mn-evk# i.MX8MN LPDDR4 EVK Board - const: fsl,imx8mn - description: i.MX8MQ based Boards -- 2.7.4
[PATCH v2 1/2] dt-bindings: gpio: brcm: Add bindings for xgs-iproc
This GPIO controller is present on a number of Broadcom switch ASICs
with integrated SoCs. It is similar to the nsp-gpio and iproc-gpio
blocks but different enough to require a separate driver.
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
- Document as DT schema
- Include ngpios, #gpio-cells and gpio-controller properties
.../bindings/gpio/brcm,xgs-iproc.yaml | 83 +++
1 file changed, 83 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml
diff --git a/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml
b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml
new file mode 100644
index ..71998551209e
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/brcm,xgs-iproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom XGS iProc GPIO controller
+
+maintainers:
+ - Chris Packham
+
+description: |
+ This controller is the Chip Common A GPIO present on a number of Broadcom
+ switch ASICs with integrated SoCs.
+
+properties:
+ compatible:
+enum:
+ - brcm,iproc-gpio-cca
+
+ reg:
+minItems: 2
+maxItems: 2
+description:
+ The first region defines the base I/O address containing
+ the GPIO controller registers. The second region defines
+ the I/O address containing the Chip Common A interrupt
+ registers.
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ ngpios:
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 0
+maximum: 32
+
+ interrupt-controller:
+type: boolean
+
+ '#interrupt-cells':
+const: 2
+
+ interrupts:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#gpio-cells"
+ - gpio-controller
+
+allOf:
+ - if:
+ properties:
+ interrupt-controller:
+ contains:
+ const: true
+ then:
+ required:
+ - interrupts
+ - '#interrupt-cells'
+
+examples:
+ - |
+#include
+#include
+gpio@1860 {
+compatible = "brcm,iproc-gpio-cca";
+#gpio-cells = <2>;
+reg = <0x1860 0x50>,
+ <0x1800 0x50>;
+ngpios = <12>;
+gpio-controller;
+interrupt-controller;
+#interrupt-cells = <2>;
+interrupts = ;
+};
+
+
+...
--
2.23.0
[PATCH v2 2/2] gpio: Add xgs-iproc driver
This driver supports the Chip Common A GPIO controller present on a
number of Broadcom switch ASICs with integrated SoCs. The controller is
similar to the pinctrl-nsp-gpio and pinctrl-iproc-gpio blocks but
different enough that a separate driver is required.
This has been ported from Broadcom's XLDK 5.0.3 retaining only the CCA
support (pinctrl-iproc-gpio covers CCB).
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
- use more of the generic infrastructure for gpio chips
- handling the root interrupt is still done manually due to sharing with
uart0.
drivers/gpio/Kconfig | 9 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-xgs-iproc.c | 301 ++
3 files changed, 311 insertions(+)
create mode 100644 drivers/gpio/gpio-xgs-iproc.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 38e096e6925f..4b3c0f8397d7 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -156,6 +156,15 @@ config GPIO_BRCMSTB
help
Say yes here to enable GPIO support for Broadcom STB (BCM7XXX) SoCs.
+config GPIO_XGS_IPROC
+ tristate "BRCM XGS iProc GPIO support"
+ depends on OF_GPIO && (ARCH_BCM_IPROC || COMPILE_TEST)
+ select GPIO_GENERIC
+ select GPIOLIB_IRQCHIP
+ default ARCH_BCM_IPROC
+ help
+ Say yes here to enable GPIO support for Broadcom XGS iProc SoCs.
+
config GPIO_CADENCE
tristate "Cadence GPIO support"
depends on OF_GPIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index d2fd19c15bae..3783c3d43fbe 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_GPIO_BCM_KONA) += gpio-bcm-kona.o
obj-$(CONFIG_GPIO_BD70528) += gpio-bd70528.o
obj-$(CONFIG_GPIO_BD9571MWV) += gpio-bd9571mwv.o
obj-$(CONFIG_GPIO_BRCMSTB) += gpio-brcmstb.o
+obj-$(CONFIG_GPIO_XGS_IPROC) += gpio-xgs-iproc.o
obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
obj-$(CONFIG_GPIO_CADENCE) += gpio-cadence.o
obj-$(CONFIG_GPIO_CLPS711X)+= gpio-clps711x.o
diff --git a/drivers/gpio/gpio-xgs-iproc.c b/drivers/gpio/gpio-xgs-iproc.c
new file mode 100644
index ..a0277acf9369
--- /dev/null
+++ b/drivers/gpio/gpio-xgs-iproc.c
@@ -0,0 +1,301 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Broadcom Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CCA_INT_F_GPIOINT BIT(0)
+#define CCA_INT_STS0x20
+#define CCA_INT_MASK 0x24
+
+#define GPIO_CCA_DIN 0x0
+#define GPIO_CCA_DOUT 0x4
+#define GPIO_CCA_OUT_EN0x8
+#define GPIO_CCA_INT_LEVEL 0x10
+#define GPIO_CCA_INT_LEVEL_MASK0x14
+#define GPIO_CCA_INT_EVENT 0x18
+#define GPIO_CCA_INT_EVENT_MASK0x1C
+#define GPIO_CCA_INT_EDGE 0x24
+
+struct iproc_gpio_chip {
+ struct irq_chip irqchip;
+ struct gpio_chip gc;
+ spinlock_t lock;
+ struct device *dev;
+ void __iomem *base;
+ void __iomem *intr;
+};
+
+static inline struct iproc_gpio_chip *
+to_iproc_gpio(struct gpio_chip *gc)
+{
+ return container_of(gc, struct iproc_gpio_chip, gc);
+}
+
+static void iproc_gpio_irq_ack(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct iproc_gpio_chip *chip = to_iproc_gpio(gc);
+ int pin = d->hwirq;
+ u32 irq = d->irq;
+ u32 irq_type, event_status = 0;
+
+ irq_type = irq_get_trigger_type(irq);
+ if (irq_type & IRQ_TYPE_EDGE_BOTH) {
+ event_status |= BIT(pin);
+ writel(event_status, chip->base + GPIO_CCA_INT_EVENT);
+ }
+}
+
+static void iproc_gpio_irq_unmask(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct iproc_gpio_chip *chip = to_iproc_gpio(gc);
+ int pin = d->hwirq;
+ u32 irq = d->irq;
+ u32 int_mask, irq_type, event_mask;
+
+ irq_type = irq_get_trigger_type(irq);
+ event_mask = readl(chip->base + GPIO_CCA_INT_EVENT_MASK);
+ int_mask = readl(chip->base + GPIO_CCA_INT_LEVEL_MASK);
+
+ if (irq_type & IRQ_TYPE_EDGE_BOTH) {
+ event_mask |= 1 << pin;
+ writel(event_mask, chip->base + GPIO_CCA_INT_EVENT_MASK);
+ } else {
+ int_mask |= 1 << pin;
+ writel(int_mask, chip->base + GPIO_CCA_INT_LEVEL_MASK);
+ }
+}
+
+static void iproc_gpio_irq_mask(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct iproc_gpio_chip *chip = to_iproc_gpio(gc);
+ int pin = d->hwirq;
+ u32 irq = d->irq;
+ u32 irq_type, int_mask, event_mask;
+
+ irq_type = irq_get_trigger_type(irq);
+
[PATCH v2 0/2] gpio: brcm: XGS iProc GPIO driver
This is ported this from Broadcom's XLDK (now heavily modified). There seem to be 3 different IP blocks for 3 separate banks of GPIOs in the iProc chips. I've dropped everything except support for the Chip Common A GPIO controller because the other blocks actually seem to be supportable with other drivers. The driver itself is halfway between pinctrl-nsp-gpio.c and pinctrl-iproc-gpio.c. Chris Packham (2): dt-bindings: gpio: brcm: Add bindings for xgs-iproc gpio: Add xgs-iproc driver .../bindings/gpio/brcm,xgs-iproc.yaml | 83 + drivers/gpio/Kconfig | 9 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-xgs-iproc.c | 301 ++ 4 files changed, 394 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml create mode 100644 drivers/gpio/gpio-xgs-iproc.c -- 2.23.0
[PATCH 0/2] Add basic dts support for RK3308
RK3308 is a quad Cortex A35 based SOC with rich audio interfaces(I2S/PCM/TDM/PDM/SPDIF/VAD/HDMI ARC), which designed for intelligent voice interaction and audio input/output processing. As the clk and pinctrl drivers are landed, we post the basic dts support, make it convenient for other module development. Andy Yan (2): arm64: dts: rockchip: Add core dts for RK3308 SOC arm64: dts: rockchip: Add basic dts for RK3308 EVB .../devicetree/bindings/arm/rockchip.yaml |5 + arch/arm64/boot/dts/rockchip/Makefile |1 + arch/arm64/boot/dts/rockchip/rk3308-evb.dts | 206 ++ arch/arm64/boot/dts/rockchip/rk3308.dtsi | 1875 + 4 files changed, 2087 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3308-evb.dts create mode 100644 arch/arm64/boot/dts/rockchip/rk3308.dtsi -- 2.17.1
[PATCH 2/2] arm64: dts: rockchip: Add basic dts for RK3308 EVB
This board use uart4 as debug port and arm core voltage
is modulated by pwm.
Signed-off-by: Andy Yan
---
.../devicetree/bindings/arm/rockchip.yaml | 5 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3308-evb.dts | 206 ++
3 files changed, 212 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3308-evb.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml
b/Documentation/devicetree/bindings/arm/rockchip.yaml
index c82c5e57d44c..b680c4b8b2c9 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -447,6 +447,11 @@ properties:
- const: rockchip,r88
- const: rockchip,rk3368
+ - description: Rockchip RK3308 Evaluation board
+items:
+ - const: rockchip,rk3308-evb
+ - const: rockchip,rk3308
+
- description: Rockchip RK3228 Evaluation board
items:
- const: rockchip,rk3228-evb
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 1f18a9392d15..a959434ad46e 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3308-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3308-evb.dts
b/arch/arm64/boot/dts/rockchip/rk3308-evb.dts
new file mode 100644
index ..16be04f38b30
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3308-evb.dts
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ */
+
+/dts-v1/;
+#include
+#include "rk3308.dtsi"
+
+/ {
+ model = "Rockchip RK3308 EVB";
+ compatible = "rockchip,rk3308-evb", "rockchip,rk3308";
+
+ chosen {
+ stdout-path = "serial4:150n8";
+ };
+
+ adc-keys0 {
+ compatible = "adc-keys";
+ io-channels = < 0>;
+ io-channel-names = "buttons";
+ poll-interval = <100>;
+ keyup-threshold-microvolt = <180>;
+
+ func-key {
+ linux,code = ;
+ label = "function";
+ press-threshold-microvolt = <18000>;
+ };
+ };
+
+ adc-keys1 {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ poll-interval = <100>;
+ keyup-threshold-microvolt = <180>;
+
+ esc-key {
+ linux,code = ;
+ label = "micmute";
+ press-threshold-microvolt = <113>;
+ };
+
+ home-key {
+ linux,code = ;
+ label = "mode";
+ press-threshold-microvolt = <901000>;
+ };
+
+ menu-key {
+ linux,code = ;
+ label = "play";
+ press-threshold-microvolt = <624000>;
+ };
+
+ vol-down-key {
+ linux,code = ;
+ label = "volume down";
+ press-threshold-microvolt = <30>;
+ };
+
+ vol-up-key {
+ linux,code = ;
+ label = "volume up";
+ press-threshold-microvolt = <18000>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_key>;
+
+ power {
+ gpios = < RK_PA6 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ label = "GPIO Key Power";
+ wakeup-source;
+ debounce-interval = <100>;
+ };
+ };
+
+ vdd_log: vdd_core: vdd-core {
+ compatible = "pwm-regulator";
+ pwms = < 0 5000 1>;
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <827000>;
+ regulator-max-microvolt = <134>;
+ regulator-init-microvolt = <1015000>;
+ regulator-early-min-microvolt = <1015000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-settling-time-up-us = <250>;
+ status = "okay";
+ };
+
+ vdd_1v0: vdd-1v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_1v0";
+ regulator-always-on;
+
[PATCH 1/2] arm64: dts: rockchip: Add core dts for RK3308 SOC
RK3308 is a quad Cortex A35 based SOC with rich audio
interfaces(I2S/PCM/TDM/PDM/SPDIF/VAD/HDMI ARC), which
designed for intelligent voice interaction and audio
input/output processing.
This patch add basic core dtsi file for it.
Signed-off-by: Andy Yan
---
arch/arm64/boot/dts/rockchip/rk3308.dtsi | 1875 ++
1 file changed, 1875 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3308.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
new file mode 100644
index ..cda63ffb0d2f
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
@@ -0,0 +1,1875 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/ {
+ compatible = "rockchip,rk3308";
+
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ ethernet0 =
+ i2c0 =
+ i2c1 =
+ i2c2 =
+ i2c3 =
+ serial0 =
+ serial1 =
+ serial2 =
+ serial3 =
+ serial4 =
+ spi0 =
+ spi1 =
+ spi2 =
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35", "arm,armv8";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ clocks = < ARMCLK>;
+ #cooling-cells = <2>;
+ dynamic-power-coefficient = <90>;
+ operating-points-v2 = <_opp_table>;
+ cpu-idle-states = <_SLEEP>;
+ next-level-cache = <>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35", "arm,armv8";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ operating-points-v2 = <_opp_table>;
+ cpu-idle-states = <_SLEEP>;
+ next-level-cache = <>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35", "arm,armv8";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ operating-points-v2 = <_opp_table>;
+ cpu-idle-states = <_SLEEP>;
+ next-level-cache = <>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35", "arm,armv8";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ operating-points-v2 = <_opp_table>;
+ cpu-idle-states = <_SLEEP>;
+ next-level-cache = <>;
+ };
+
+ idle-states {
+ entry-method = "psci";
+
+ CPU_SLEEP: cpu-sleep {
+ compatible = "arm,idle-state";
+ local-timer-stop;
+ arm,psci-suspend-param = <0x001>;
+ entry-latency-us = <120>;
+ exit-latency-us = <250>;
+ min-residency-us = <900>;
+ };
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ cpu0_opp_table: cpu0-opp-table {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-40800 {
+ opp-hz = /bits/ 64 <40800>;
+ opp-microvolt = <95 95 134>;
+ clock-latency-ns = <4>;
+ opp-suspend;
+ };
+ opp-6 {
+ opp-hz = /bits/ 64 <6>;
+ opp-microvolt = <95 95 134>;
+ clock-latency-ns = <4>;
+ };
+ opp-81600 {
+ opp-hz = /bits/ 64 <81600>;
+ opp-microvolt = <1025000 1025000 134>;
+ clock-latency-ns = <4>;
+ };
+ opp-100800 {
+ opp-hz = /bits/ 64 <100800>;
+ opp-microvolt = <1125000 1125000 134>;
+ clock-latency-ns = <4>;
+ };
+ };
+
+ arm-pmu {
+
Re: [PATCH 6/7] rcu: rename some CONFIG_PREEMPTION to CONFIG_PREEMPT_RCU
On Wed, Oct 16, 2019 at 11:26:23PM +0800, Lai Jiangshan wrote:
>
>
> On 2019/10/16 11:54 上午, Paul E. McKenney wrote:
> > On Tue, Oct 15, 2019 at 10:28:48AM +, Lai Jiangshan wrote:
> > > CONFIG_PREEMPTION and CONFIG_PREEMPT_RCU are always identical,
> > > but some code depends on CONFIG_PREEMPTION to access to
> > > rcu_preempt functionalitis. This patch changes CONFIG_PREEMPTION
> > > to CONFIG_PREEMPT_RCU in these cases.
> > >
> > > Signed-off-by: Lai Jiangshan
> > > Signed-off-by: Lai Jiangshan
> >
> > I believe that this does not cause problems with Sebastian's patch
> > "[PATCH 27/34] rcu: Use CONFIG_PREEMPTION where appropriate", but could
> > you please check?
>
> I don't know for which commit the patch "[PATCH 27/34] rcu: Use
> CONFIG_PREEMPTION where appropriate" should be applied against
> after several tries. But I don't think there will be any conflicts
> which this patch by "eye" applying.
Well, git didn't see any either, so it is now applied for review and
testing. Thank you!
Thanx, Paul
> Thanks,
> Lai
>
>
>
> >
> > Thanx, Paul
> >
> > > ---
> > > kernel/rcu/tree.c | 4 ++--
> > > kernel/rcu/tree_stall.h | 6 +++---
> > > 2 files changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index 7db5ea06a9ed..81eb64fcf5ab 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -1926,7 +1926,7 @@ rcu_report_unblock_qs_rnp(struct rcu_node *rnp,
> > > unsigned long flags)
> > > struct rcu_node *rnp_p;
> > > raw_lockdep_assert_held_rcu_node(rnp);
> > > - if (WARN_ON_ONCE(!IS_ENABLED(CONFIG_PREEMPTION)) ||
> > > + if (WARN_ON_ONCE(!IS_ENABLED(CONFIG_PREEMPT_RCU)) ||
> > > WARN_ON_ONCE(rcu_preempt_blocked_readers_cgp(rnp)) ||
> > > rnp->qsmask != 0) {
> > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> > > @@ -2294,7 +2294,7 @@ static void force_qs_rnp(int (*f)(struct rcu_data
> > > *rdp))
> > > mask = 0;
> > > raw_spin_lock_irqsave_rcu_node(rnp, flags);
> > > if (rnp->qsmask == 0) {
> > > - if (!IS_ENABLED(CONFIG_PREEMPTION) ||
> > > + if (!IS_ENABLED(CONFIG_PREEMPT_RCU) ||
> > > rcu_preempt_blocked_readers_cgp(rnp)) {
> > > /*
> > >* No point in scanning bits because
> > > they
> > > diff --git a/kernel/rcu/tree_stall.h b/kernel/rcu/tree_stall.h
> > > index 0b75426ebb3e..55f9b84790d3 100644
> > > --- a/kernel/rcu/tree_stall.h
> > > +++ b/kernel/rcu/tree_stall.h
> > > @@ -163,7 +163,7 @@ static void rcu_iw_handler(struct irq_work *iwp)
> > > //
> > > // Printing RCU CPU stall warnings
> > > -#ifdef CONFIG_PREEMPTION
> > > +#ifdef CONFIG_PREEMPT_RCU
> > > /*
> > >* Dump detailed information for all tasks blocking the current RCU
> > > @@ -215,7 +215,7 @@ static int rcu_print_task_stall(struct rcu_node *rnp)
> > > return ndetected;
> > > }
> > > -#else /* #ifdef CONFIG_PREEMPTION */
> > > +#else /* #ifdef CONFIG_PREEMPT_RCU */
> > > /*
> > >* Because preemptible RCU does not exist, we never have to check for
> > > @@ -233,7 +233,7 @@ static int rcu_print_task_stall(struct rcu_node *rnp)
> > > {
> > > return 0;
> > > }
> > > -#endif /* #else #ifdef CONFIG_PREEMPTION */
> > > +#endif /* #else #ifdef CONFIG_PREEMPT_RCU */
> > > /*
> > >* Dump stacks of all tasks running on stalled CPUs. First try using
> > > --
> > > 2.20.1
> > >
[PATCH] ASoC: Intel: sof-rt5682: add a check for devm_clk_get
sof_audio_probe misses a check for devm_clk_get and may cause problems.
Add a check for it to fix the bug.
Signed-off-by: Chuhong Yuan
---
sound/soc/intel/boards/sof_rt5682.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sound/soc/intel/boards/sof_rt5682.c
b/sound/soc/intel/boards/sof_rt5682.c
index a437567b8cee..6d15c7ff66bf 100644
--- a/sound/soc/intel/boards/sof_rt5682.c
+++ b/sound/soc/intel/boards/sof_rt5682.c
@@ -576,6 +576,15 @@ static int sof_audio_probe(struct platform_device *pdev)
/* need to get main clock from pmc */
if (sof_rt5682_quirk & SOF_RT5682_MCLK_BYTCHT_EN) {
ctx->mclk = devm_clk_get(>dev, "pmc_plt_clk_3");
+ if (IS_ERR(ctx->mclk)) {
+ ret = PTR_ERR(ctx->mclk);
+
+ dev_err(>dev,
+ "Failed to get MCLK from pmc_plt_clk_3: %d\n",
+ ret);
+ return ret;
+ }
+
ret = clk_prepare_enable(ctx->mclk);
if (ret < 0) {
dev_err(>dev,
--
2.20.1
Re: KASAN: use-after-free Read in mnt_warn_timestamp_expiry
On Thu, Oct 17, 2019 at 03:37:35AM +0100, Al Viro wrote:
> On Wed, Oct 16, 2019 at 07:27:05PM -0700, Eric Biggers wrote:
>
> > How about the following?
> >
> > pr_warn("%s filesystem being %s at %s supports timestamps until %04ld
> > (0x%llx)\n",
> > sb->s_type->name,
> > is_mounted(mnt) ? "remounted" : "mounted",
> > mntpath,
> > tm.tm_year+1900, (unsigned long long)sb->s_time_max);
> >
> > I think more people would understand "remounted" than "reconfigured". Also,
> > is_mounted(mnt) seems like a better choice than
> > mnt_has_parent(real_mount(mnt)).
>
> Works for me(tm). Care to fold that into your patch and resend?
>
Sent:
https://lkml.kernel.org/linux-fsdevel/20191017024814.61980-1-ebigg...@kernel.org/T/#u
[PATCH] spi: pxa2xx: Add missed security checks
pxa2xx_spi_init_pdata misses checks for devm_clk_get and platform_get_irq. Add checks for them to fix the bugs. Signed-off-by: Chuhong Yuan --- drivers/spi/spi-pxa2xx.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c index bb6a14d1ab0f..2e73d75a6ac5 100644 --- a/drivers/spi/spi-pxa2xx.c +++ b/drivers/spi/spi-pxa2xx.c @@ -1565,7 +1565,13 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev) #endif ssp->clk = devm_clk_get(>dev, NULL); + if (IS_ERR(ssp->clk)) + return NULL; + ssp->irq = platform_get_irq(pdev, 0); + if (ssp->irq < 0) + return NULL; + ssp->type = type; ssp->pdev = pdev; ssp->port_id = pxa2xx_spi_get_port_id(adev); -- 2.20.1
Re: [PATCH 0/3] cpufreq: merge arm_big_little and vexpress-spc
+Nico in case he has any issues with this series. On 16-10-19, 12:03, Sudeep Holla wrote: > Hi, > > Since vexpress-spc is the sole user of arm_big_little cpufreq driver, > there's no point in keeping it separate anymore. I wanted to post these > patches for ages but kept postponing for no reason. > > Regards, > Sudeep > > Sudeep Holla (3): > cpufreq: scpi: remove stale/outdated comment about the driver > cpufreq: merge arm_big_little and vexpress-spc > cpufreq: simplify and remove lots of debug messages > > MAINTAINERS| 5 +- > drivers/cpufreq/Kconfig.arm| 12 +- > drivers/cpufreq/Makefile | 2 - > drivers/cpufreq/arm_big_little.c | 658 - > drivers/cpufreq/arm_big_little.h | 43 -- > drivers/cpufreq/scpi-cpufreq.c | 2 - > drivers/cpufreq/vexpress-spc-cpufreq.c | 559 - > 7 files changed, 539 insertions(+), 742 deletions(-) > delete mode 100644 drivers/cpufreq/arm_big_little.c > delete mode 100644 drivers/cpufreq/arm_big_little.h > > -- > 2.17.1 -- viresh
Re: WARNING: refcount bug in find_key_to_update
syzbot has bisected this bug to:
commit 0570bc8b7c9b41deba6f61ac218922e7168ad648
Author: Linus Torvalds
Date: Thu Jul 18 19:26:59 2019 +
Merge tag 'riscv/for-v5.3-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11b6e2bb60
start commit: bc88f85c kthread: make __kthread_queue_delayed_work static
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=13b6e2bb60
console output: https://syzkaller.appspot.com/x/log.txt?x=15b6e2bb60
kernel config: https://syzkaller.appspot.com/x/.config?x=e0ac4d9b35046343
dashboard link: https://syzkaller.appspot.com/bug?extid=6455648abc28dbdd1e7f
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11c8adab60
Reported-by: syzbot+6455648abc28dbdd1...@syzkaller.appspotmail.com
Fixes: 0570bc8b7c9b ("Merge tag 'riscv/for-v5.3-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH 3/3] cpufreq: simplify and remove lots of debug messages
On 16-10-19, 12:03, Sudeep Holla wrote: > cpufreq_arm_bL_ops is no longer needed after merging the generic > arm_big_little and vexpress-spc driver. Remove cpufreq_arm_bL_ops > and rename all the bL_* function names to ve_spc_*. > > This driver have been used for year now and the extensive debug > messages in the driver are not really required anymore. This does lots of cleanup in this patch and not strictly what the commit log says. Can you please create separate patches for remove ops, debug messages and other formatting things ? -- viresh
Re: [PATCH 2/3] cpufreq: merge arm_big_little and vexpress-spc
On 16-10-19, 12:03, Sudeep Holla wrote: > arm_big_little cpufreq driver was designed as a generic big little > driver that could be used by any platform and make use of bL switcher. > Over years alternate solutions have be designed and merged to deal with > bL/HMP systems like EAS. > > Also since no other driver made use of generic arm_big_little cpufreq > driver except Vexpress SPC, we can merge them together as vexpress-spc > driver used only on Vexpress TC2(CA15_CA7) platform. > > Signed-off-by: Sudeep Holla > --- > MAINTAINERS| 5 +- > drivers/cpufreq/Kconfig.arm| 12 +- > drivers/cpufreq/Makefile | 2 - > drivers/cpufreq/arm_big_little.c | 658 > drivers/cpufreq/arm_big_little.h | 43 -- > drivers/cpufreq/vexpress-spc-cpufreq.c | 661 - > 6 files changed, 652 insertions(+), 729 deletions(-) > delete mode 100644 drivers/cpufreq/arm_big_little.c > delete mode 100644 drivers/cpufreq/arm_big_little.h The delta produced here is enormous probably because you copy/pasted things. I am wondering if using git mv to rename arm_big_little.c and then move spc bits into it will make this delta smaller to review ? -- viresh
Re: KASAN: use-after-free Read in mnt_warn_timestamp_expiry
On Wed, Oct 16, 2019 at 07:27:05PM -0700, Eric Biggers wrote:
> How about the following?
>
> pr_warn("%s filesystem being %s at %s supports timestamps until %04ld
> (0x%llx)\n",
> sb->s_type->name,
> is_mounted(mnt) ? "remounted" : "mounted",
> mntpath,
> tm.tm_year+1900, (unsigned long long)sb->s_time_max);
>
> I think more people would understand "remounted" than "reconfigured". Also,
> is_mounted(mnt) seems like a better choice than
> mnt_has_parent(real_mount(mnt)).
Works for me(tm). Care to fold that into your patch and resend?
Re: [PATCH v1 07/17] cpufreq: tegra20: Use generic cpufreq-dt driver (Tegra30 supported now)
On 16-10-19, 00:16, Dmitry Osipenko wrote: > Re-parenting to intermediate clock is supported now by the clock driver > and thus there is no need in a customized CPUFreq driver, all that code > is common for both Tegra20 and Tegra30. The available CPU freqs are now > specified in device-tree in a form of OPPs, all users should update their > device-trees. > > Signed-off-by: Dmitry Osipenko > --- > drivers/cpufreq/Kconfig.arm | 4 +- > drivers/cpufreq/cpufreq-dt-platdev.c | 2 + > drivers/cpufreq/tegra20-cpufreq.c| 236 ++- > 3 files changed, 55 insertions(+), 187 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [PATCH 2/2] virtio_ring: Use DMA API if memory is encrypted
On 2019/10/15 下午3:35, Christoph Hellwig wrote: On Fri, Oct 11, 2019 at 06:25:19PM -0700, Ram Pai wrote: From: Thiago Jung Bauermann Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must be set by both device and guest driver. However, as a hack, when DMA API returns physical addresses, guest driver can use the DMA API; even though device does not set VIRTIO_F_IOMMU_PLATFORM and just uses physical addresses. Sorry, but this is a complete bullshit hack. Driver must always use the DMA API if they do DMA, and if virtio devices use physical addresses that needs to be returned through the platform firmware interfaces for the dma setup. If you don't do that yet (which based on previous informations you don't), you need to fix it, and we can then quirk old implementations that already are out in the field. In other words: we finally need to fix that virtio mess and not pile hacks on top of hacks. I agree, the only reason for IOMMU_PLATFORM is to make sure guest works for some old and buggy qemu when vIOMMU is enabled which seems useless (note we don't even support vIOMMU migration in that case). Thanks
Re: [PATCH v1 11/17] ARM: dts: tegra20: Add CPU Operating Performance Points
On 16-10-19, 00:16, Dmitry Osipenko wrote:
> Operating Point are specified per HW version. The OPP voltages are kept
> in a separate DTSI file because some boards may not define CPU regulator
> in their device-tree if voltage scaling isn't necessary, like for example
> in a case of tegra20-trimslice which is outlet-powered device.
>
> Signed-off-by: Dmitry Osipenko
> ---
> .../boot/dts/tegra20-cpu-opp-microvolt.dtsi | 201
> arch/arm/boot/dts/tegra20-cpu-opp.dtsi| 302 ++
> 2 files changed, 503 insertions(+)
> create mode 100644 arch/arm/boot/dts/tegra20-cpu-opp-microvolt.dtsi
> create mode 100644 arch/arm/boot/dts/tegra20-cpu-opp.dtsi
>
> diff --git a/arch/arm/boot/dts/tegra20-cpu-opp-microvolt.dtsi
> b/arch/arm/boot/dts/tegra20-cpu-opp-microvolt.dtsi
> new file mode 100644
> index ..e85ffdbef876
> --- /dev/null
> +++ b/arch/arm/boot/dts/tegra20-cpu-opp-microvolt.dtsi
> @@ -0,0 +1,201 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/ {
> + cpu0_opp_table: cpu_opp_table0 {
> + opp@21600_750 {
> + opp-microvolt = <75 75 1125000>;
> + };
> +
> + opp@21600_800 {
> + opp-microvolt = <80 80 1125000>;
> + };
> +
> + opp@31200_750 {
> + opp-microvolt = <75 75 1125000>;
> + };
> +
> + opp@31200_800 {
> + opp-microvolt = <80 80 1125000>;
> + };
> +
> + opp@45600_750 {
> + opp-microvolt = <75 75 1125000>;
> + };
> +
> + opp@45600_800 {
> + opp-microvolt = <80 80 1125000>;
> + };
> +
> + opp@45600_800_2_2 {
> + opp-microvolt = <80 80 1125000>;
> + };
> +
> + opp@45600_800_3_2 {
> + opp-microvolt = <80 80 1125000>;
> + };
> +
> + opp@45600_825 {
> + opp-microvolt = <825000 825000 1125000>;
> + };
> +
> + opp@60800_750 {
> + opp-microvolt = <75 75 1125000>;
> + };
> +
> + opp@60800_800 {
> + opp-microvolt = <80 80 1125000>;
> + };
> +
> + opp@60800_800_3_2 {
> + opp-microvolt = <80 80 1125000>;
> + };
> +
> + opp@60800_825 {
> + opp-microvolt = <825000 825000 1125000>;
> + };
> +
> + opp@60800_850 {
> + opp-microvolt = <85 85 1125000>;
> + };
> +
> + opp@60800_900 {
> + opp-microvolt = <90 90 1125000>;
> + };
> +
> + opp@76000_775 {
> + opp-microvolt = <775000 775000 1125000>;
> + };
> +
> + opp@76000_800 {
> + opp-microvolt = <80 80 1125000>;
> + };
> +
> + opp@76000_850 {
> + opp-microvolt = <85 85 1125000>;
> + };
> +
> + opp@76000_875 {
> + opp-microvolt = <875000 875000 1125000>;
> + };
> +
> + opp@76000_875_1_1 {
> + opp-microvolt = <875000 875000 1125000>;
> + };
> +
> + opp@76000_875_0_2 {
> + opp-microvolt = <875000 875000 1125000>;
> + };
> +
> + opp@76000_875_1_2 {
> + opp-microvolt = <875000 875000 1125000>;
> + };
> +
> + opp@76000_900 {
> + opp-microvolt = <90 90 1125000>;
> + };
> +
> + opp@76000_975 {
> + opp-microvolt = <975000 975000 1125000>;
> + };
> +
> + opp@81600_800 {
> + opp-microvolt = <80 80 1125000>;
> + };
> +
> + opp@81600_850 {
> + opp-microvolt = <85 85 1125000>;
> + };
> +
> + opp@81600_875 {
> + opp-microvolt = <875000 875000 1125000>;
> + };
> +
> + opp@81600_950 {
> + opp-microvolt = <95 95 1125000>;
> + };
> +
> + opp@81600_1000 {
> + opp-microvolt = <100 100 1125000>;
> + };
> +
> + opp@91200_850 {
> + opp-microvolt = <85 85 1125000>;
> + };
> +
> + opp@91200_900 {
> + opp-microvolt = <90 90 1125000>;
> + };
> +
> + opp@91200_925 {
> + opp-microvolt =
Re: [PATCH v1 12/17] ARM: dts: tegra30: Add CPU Operating Performance Points
On 16-10-19, 00:16, Dmitry Osipenko wrote: > Operating Point are specified per HW version. The OPP voltages are kept > in a separate DTSI file because some boards may not define CPU regulator > in their device-tree if voltage scaling isn't necessary for them. > > Signed-off-by: Dmitry Osipenko > --- > .../boot/dts/tegra30-cpu-opp-microvolt.dtsi | 801 +++ > arch/arm/boot/dts/tegra30-cpu-opp.dtsi| 1202 + > 2 files changed, 2003 insertions(+) > create mode 100644 arch/arm/boot/dts/tegra30-cpu-opp-microvolt.dtsi > create mode 100644 arch/arm/boot/dts/tegra30-cpu-opp.dtsi Acked-by: Viresh Kumar -- viresh
Re: [PATCH v1 06/17] dt-bindings: cpufreq: Add binding for NVIDIA Tegra20/30
On 16-10-19, 00:16, Dmitry Osipenko wrote:
> Add device-tree binding that describes CPU frequency-scaling hardware
> found on NVIDIA Tegra20/30 SoCs.
>
> Signed-off-by: Dmitry Osipenko
> ---
> .../cpufreq/nvidia,tegra20-cpufreq.txt| 56 +++
> 1 file changed, 56 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
>
> diff --git
> a/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
> b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
> new file mode 100644
> index ..daeca6ae6b76
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
> @@ -0,0 +1,56 @@
> +Binding for NVIDIA Tegra20 CPUFreq
> +==
> +
> +Required properties:
> +- clocks: Must contain an entry for the CPU clock.
> + See ../clocks/clock-bindings.txt for details.
> +- operating-points-v2: See ../bindings/opp/opp.txt for details.
> +- #cooling-cells: Should be 2. See ../thermal/thermal.txt for details.
> +
> +For each opp entry in 'operating-points-v2' table:
> +- opp-supported-hw: Two bitfields indicating:
> + On Tegra20:
> + 1. CPU process ID mask
> + 2. SoC speedo ID mask
> +
> + On Tegra30:
> + 1. CPU process ID mask
> + 2. CPU speedo ID mask
> +
> + A bitwise AND is performed against these values and if any bit
> + matches, the OPP gets enabled.
> +
> +- opp-microvolt: CPU voltage triplet.
> +
> +Optional properties:
> +- cpu-supply: Phandle to the CPU power supply.
> +
> +Example:
> + regulators {
> + cpu_reg: regulator0 {
> + regulator-name = "vdd_cpu";
> + };
> + };
> +
> + cpu0_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> +
> + opp@45600 {
> + clock-latency-ns = <125000>;
> + opp-microvolt = <825000 825000 1125000>;
> + opp-supported-hw = <0x03 0x0001>;
> + opp-hz = /bits/ 64 <45600>;
> + };
> +
> + ...
> + };
> +
> + cpus {
> + cpu@0 {
> + compatible = "arm,cortex-a9";
> + clocks = <_car TEGRA20_CLK_CCLK>;
> + operating-points-v2 = <_opp_table>;
> + cpu-supply = <_reg>;
> + #cooling-cells = <2>;
> + };
> + };
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH v1 07/17] cpufreq: tegra20: Use generic cpufreq-dt driver (Tegra30 supported now)
On 16-10-19, 21:19, Dmitry Osipenko wrote: > 16.10.2019 17:58, Peter Geis пишет: > > On Wed, Oct 16, 2019 at 9:29 AM Dmitry Osipenko wrote: > >> > >> 16.10.2019 08:18, Viresh Kumar пишет: > >>> On 16-10-19, 00:16, Dmitry Osipenko wrote: > Re-parenting to intermediate clock is supported now by the clock driver > and thus there is no need in a customized CPUFreq driver, all that code > is common for both Tegra20 and Tegra30. The available CPU freqs are now > specified in device-tree in a form of OPPs, all users should update their > device-trees. > > Signed-off-by: Dmitry Osipenko > --- > drivers/cpufreq/Kconfig.arm | 4 +- > drivers/cpufreq/cpufreq-dt-platdev.c | 2 + > drivers/cpufreq/tegra20-cpufreq.c| 236 ++- > 3 files changed, 55 insertions(+), 187 deletions(-) > > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm > index a905796f7f85..2118c45d0acd 100644 > --- a/drivers/cpufreq/Kconfig.arm > +++ b/drivers/cpufreq/Kconfig.arm > @@ -301,8 +301,8 @@ config ARM_TANGO_CPUFREQ > default y > > config ARM_TEGRA20_CPUFREQ > -tristate "Tegra20 CPUFreq support" > -depends on ARCH_TEGRA > +bool "Tegra20 CPUFreq support" > >>> > >>> Google is currently working on the GKI (generic kernel image) project > >>> where they > >>> want to use a single kernel image with modules for all kind of android > >>> devices. > >>> And for that they need all such drivers to be built as module. Since this > >>> is > >>> already an module, I would ask you to keep it as is instead of moving it > >>> to bool > >>> here. Else some google guy will switch it back as module later on. > >>> > >>> LGTM otherwise. Nice work. Thanks. > >>> > >> > >> Okay, I'll keep the modularity in v2. > >> > >> Although, tegra20-cpufreq isn't a driver anymore because now it merely > >> prepares OPP table for the cpufreq-dt driver, which is really a one-shot > >> action that is enough to do during boot and thus modularity is a bit > >> redundant here. > > > > I doubt Google will care much, since Android has moved on to aarch64. > > Do they even support arm32 any more? > > Yes, I don't think there is a real need to care about Google. They won't > use pure upstream and won't care about older hardware any ways. Well, using (almost) pure upstream is the idea I believe. And the thing is they want to use a single multi-platform image which should be as small as possible in size. So it won't have any drivers or platform stuff (if possible) and everything is module. I am not sure about arm32/64 thing though. And it is okay if you don't want to care about Google right now. That was just some side knowledge I had :) -- viresh
RE: [PATCH] MAINTAINERS: Add Marek and Shimoda-san as R-Car PCIE co-maintainers
Hi Simon-san, > From: Simon Horman, Sent: Wednesday, October 16, 2019 9:03 PM > > At the end of the v5.3 upstream development cycle I stepped down > from my role at Renesas. > > Pass maintainership of the R-Car PCIE to Marek and Shimoda-san. > > Signed-off-by: Simon Horman Thank you very much for your support until now! Acked-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda
Re: [PATCH v1 11/17] ARM: dts: tegra20: Add CPU Operating Performance Points
On 16-10-19, 16:21, Dmitry Osipenko wrote:
> 16.10.2019 08:23, Viresh Kumar пишет:
> > On 16-10-19, 00:16, Dmitry Osipenko wrote:
> >> Operating Point are specified per HW version. The OPP voltages are kept
> >> in a separate DTSI file because some boards may not define CPU regulator
> >> in their device-tree if voltage scaling isn't necessary, like for example
> >> in a case of tegra20-trimslice which is outlet-powered device.
> >>
> >> Signed-off-by: Dmitry Osipenko
> >> ---
> >> .../boot/dts/tegra20-cpu-opp-microvolt.dtsi | 201
> >> arch/arm/boot/dts/tegra20-cpu-opp.dtsi| 302 ++
> >> 2 files changed, 503 insertions(+)
> >> create mode 100644 arch/arm/boot/dts/tegra20-cpu-opp-microvolt.dtsi
> >> create mode 100644 arch/arm/boot/dts/tegra20-cpu-opp.dtsi
> >>
> >> diff --git a/arch/arm/boot/dts/tegra20-cpu-opp-microvolt.dtsi
> >> b/arch/arm/boot/dts/tegra20-cpu-opp-microvolt.dtsi
> >> new file mode 100644
> >> index ..e85ffdbef876
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/tegra20-cpu-opp-microvolt.dtsi
> >> @@ -0,0 +1,201 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +
> >> +/ {
> >> + cpu0_opp_table: cpu_opp_table0 {
> >> + opp@21600_750 {
> >
> > Maybe just drop the _750 (i.e. voltage) from the names as we don't generally
> > follow it :)
>
> The reason for the _750 postfix is that there are multiple OPPs for
> 216MHz and they have different voltages for different versions of
> hardware, thus those are separate OPPs and they can't be squashed into a
> single OPP node.
Ah, okay. I missed that you are using supported-hw bindings.
--
viresh
Re: KASAN: use-after-free Read in mnt_warn_timestamp_expiry
On Thu, Oct 17, 2019 at 02:58:53AM +0100, Al Viro wrote:
> On Wed, Oct 16, 2019 at 06:47:55PM -0700, Eric Biggers wrote:
> > On Wed, Oct 16, 2019 at 06:42:11PM -0700, syzbot wrote:
> > > ==
> > > BUG: KASAN: use-after-free in mnt_warn_timestamp_expiry+0x4a/0x250
> > > fs/namespace.c:2471
> > > Read of size 8 at addr 888099937328 by task syz-executor.1/18510
> > >
> >
> > Looks like a duplicate of this:
> >
> > #syz dup: KASAN: use-after-free Read in do_mount
> >
> > See the existing thread and proposed fix here:
> > https://lkml.kernel.org/linux-fsdevel/805e5505945a2...@google.com/T/#u
>
> FWIW, I'd go with your "move mnt_warn_timestamp_expiry() up". However,
> I'd probably turn the message into something like
> foofs filesystem getting mounted at /mnt/barf supports...
> And s/mounted/reconfigured/ if mnt_has_parent(mnt) is already true.
>
> Objections?
>
How about the following?
pr_warn("%s filesystem being %s at %s supports timestamps until %04ld
(0x%llx)\n",
sb->s_type->name,
is_mounted(mnt) ? "remounted" : "mounted",
mntpath,
tm.tm_year+1900, (unsigned long long)sb->s_time_max);
I think more people would understand "remounted" than "reconfigured". Also,
is_mounted(mnt) seems like a better choice than mnt_has_parent(real_mount(mnt)).
- Eric
Re: [PATCH v2] rtl8xxxu: fix RTL8723BU connection failure issue after warm reboot
On Wed, Oct 16, 2019 at 9:54 AM Chris Chiu wrote: > > The RTL8723BU has problems connecting to AP after each warm reboot. > Sometimes it returns no scan result, and in most cases, it fails > the authentication for unknown reason. However, it works totally > fine after cold reboot. > > Compare the value of register SYS_CR and SYS_CLK_MAC_CLK_ENABLE > for cold reboot and warm reboot, the registers imply that the MAC > is already powered and thus some procedures are skipped during > driver initialization. Double checked the vendor driver, it reads > the SYS_CR and SYS_CLK_MAC_CLK_ENABLE also but doesn't skip any > during initialization based on them. This commit only tells the > RTL8723BU to do full initialization without checking MAC status. > > Signed-off-by: Chris Chiu Signed-off-by: Jes Sorensen Sorry, I forgot to add Jes. Chris > --- > > Note: > v2: fix typo of commit message > >
[RFC PATCH 4/4] interconnect: qcom: sdm845: Split qnodes into their respective NoCs
In order to better represent the hardware and its different Network-On-Chip
devices, split the sdm845 provider driver into NoC specific providers.
Remove duplicate functionality already provided by the icc rpmh and
bcm voter drivers to calculate and commit bandwidth requests to hardware.
Signed-off-by: David Dai
---
drivers/interconnect/qcom/sdm845.c | 727 +++--
1 file changed, 206 insertions(+), 521 deletions(-)
diff --git a/drivers/interconnect/qcom/sdm845.c
b/drivers/interconnect/qcom/sdm845.c
index 502a6c2..a731f4d 100644
--- a/drivers/interconnect/qcom/sdm845.c
+++ b/drivers/interconnect/qcom/sdm845.c
@@ -16,133 +16,8 @@
#include
#include
-#include
-#include
-#include
-
-#define to_qcom_provider(_provider) \
- container_of(_provider, struct qcom_icc_provider, provider)
-
-struct qcom_icc_provider {
- struct icc_provider provider;
- struct device *dev;
- struct qcom_icc_bcm **bcms;
- size_t num_bcms;
-};
-
-/**
- * struct bcm_db - Auxiliary data pertaining to each Bus Clock Manager (BCM)
- * @unit: divisor used to convert bytes/sec bw value to an RPMh msg
- * @width: multiplier used to convert bytes/sec bw value to an RPMh msg
- * @vcd: virtual clock domain that this bcm belongs to
- * @reserved: reserved field
- */
-struct bcm_db {
- __le32 unit;
- __le16 width;
- u8 vcd;
- u8 reserved;
-};
-
-#define SDM845_MAX_LINKS 43
-#define SDM845_MAX_BCMS30
-#define SDM845_MAX_BCM_PER_NODE2
-#define SDM845_MAX_VCD 10
-
-/*
- * The AMC bucket denotes constraints that are applied to hardware when
- * icc_set_bw() completes, whereas the WAKE and SLEEP constraints are applied
- * when the execution environment transitions between active and low power
mode.
- */
-#define QCOM_ICC_BUCKET_AMC0
-#define QCOM_ICC_BUCKET_WAKE 1
-#define QCOM_ICC_BUCKET_SLEEP 2
-#define QCOM_ICC_NUM_BUCKETS 3
-#define QCOM_ICC_TAG_AMC BIT(QCOM_ICC_BUCKET_AMC)
-#define QCOM_ICC_TAG_WAKE BIT(QCOM_ICC_BUCKET_WAKE)
-#define QCOM_ICC_TAG_SLEEP BIT(QCOM_ICC_BUCKET_SLEEP)
-#define QCOM_ICC_TAG_ACTIVE_ONLY (QCOM_ICC_TAG_AMC | QCOM_ICC_TAG_WAKE)
-#define QCOM_ICC_TAG_ALWAYS(QCOM_ICC_TAG_AMC | QCOM_ICC_TAG_WAKE |\
-QCOM_ICC_TAG_SLEEP)
-
-/**
- * struct qcom_icc_node - Qualcomm specific interconnect nodes
- * @name: the node name used in debugfs
- * @links: an array of nodes where we can go next while traversing
- * @id: a unique node identifier
- * @num_links: the total number of @links
- * @channels: num of channels at this node
- * @buswidth: width of the interconnect between a node and the bus
- * @sum_avg: current sum aggregate value of all avg bw requests
- * @max_peak: current max aggregate value of all peak bw requests
- * @bcms: list of bcms associated with this logical node
- * @num_bcms: num of @bcms
- */
-struct qcom_icc_node {
- const char *name;
- u16 links[SDM845_MAX_LINKS];
- u16 id;
- u16 num_links;
- u16 channels;
- u16 buswidth;
- u64 sum_avg[QCOM_ICC_NUM_BUCKETS];
- u64 max_peak[QCOM_ICC_NUM_BUCKETS];
- struct qcom_icc_bcm *bcms[SDM845_MAX_BCM_PER_NODE];
- size_t num_bcms;
-};
-
-/**
- * struct qcom_icc_bcm - Qualcomm specific hardware accelerator nodes
- * known as Bus Clock Manager (BCM)
- * @name: the bcm node name used to fetch BCM data from command db
- * @type: latency or bandwidth bcm
- * @addr: address offsets used when voting to RPMH
- * @vote_x: aggregated threshold values, represents sum_bw when @type is bw bcm
- * @vote_y: aggregated threshold values, represents peak_bw when @type is bw
bcm
- * @dirty: flag used to indicate whether the bcm needs to be committed
- * @keepalive: flag used to indicate whether a keepalive is required
- * @aux_data: auxiliary data used when calculating threshold values and
- * communicating with RPMh
- * @list: used to link to other bcms when compiling lists for commit
- * @num_nodes: total number of @num_nodes
- * @nodes: list of qcom_icc_nodes that this BCM encapsulates
- */
-struct qcom_icc_bcm {
- const char *name;
- u32 type;
- u32 addr;
- u64 vote_x[QCOM_ICC_NUM_BUCKETS];
- u64 vote_y[QCOM_ICC_NUM_BUCKETS];
- bool dirty;
- bool keepalive;
- struct bcm_db aux_data;
- struct list_head list;
- size_t num_nodes;
- struct qcom_icc_node *nodes[];
-};
-
-struct qcom_icc_fabric {
- struct qcom_icc_node **nodes;
- size_t num_nodes;
-};
-
-struct qcom_icc_desc {
- struct qcom_icc_node **nodes;
- size_t num_nodes;
- struct qcom_icc_bcm **bcms;
- size_t num_bcms;
-};
-
-#define DEFINE_QNODE(_name, _id, _channels, _buswidth, \
- _numlinks, ...) \
- static struct qcom_icc_node
[RFC PATCH 3/4] interconnect: qcom: Refactor icc rpmh support
Add bcm voter driver and add support for RPMh specific interconnect
providers so that they may be re-used for icc-next RPMh based provider
drivers.
Signed-off-by: David Dai
---
drivers/interconnect/qcom/Kconfig | 8 +
drivers/interconnect/qcom/Makefile| 4 +
drivers/interconnect/qcom/bcm-voter.c | 355 ++
drivers/interconnect/qcom/bcm-voter.h | 28 +++
drivers/interconnect/qcom/icc-rpmh.c | 154 +++
drivers/interconnect/qcom/icc-rpmh.h | 150 ++
6 files changed, 699 insertions(+)
create mode 100644 drivers/interconnect/qcom/bcm-voter.c
create mode 100644 drivers/interconnect/qcom/bcm-voter.h
create mode 100644 drivers/interconnect/qcom/icc-rpmh.c
create mode 100644 drivers/interconnect/qcom/icc-rpmh.h
diff --git a/drivers/interconnect/qcom/Kconfig
b/drivers/interconnect/qcom/Kconfig
index 6ab4012..8ff255d 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -18,9 +18,17 @@ config INTERCONNECT_QCOM_SDM845
tristate "Qualcomm SDM845 interconnect driver"
depends on INTERCONNECT_QCOM
depends on (QCOM_RPMH && QCOM_COMMAND_DB && OF) || COMPILE_TEST
+ select INTERCONNECT_QCOM_RPMH
+ select INTERCONNECT_QCOM_BCM_VOTER
help
This is a driver for the Qualcomm Network-on-Chip on sdm845-based
platforms.
+config INTERCONNECT_QCOM_BCM_VOTER
+ tristate
+
+config INTERCONNECT_QCOM_RPMH
+ tristate
+
config INTERCONNECT_QCOM_SMD_RPM
tristate
diff --git a/drivers/interconnect/qcom/Makefile
b/drivers/interconnect/qcom/Makefile
index 67dafb7..0f5e88d 100644
--- a/drivers/interconnect/qcom/Makefile
+++ b/drivers/interconnect/qcom/Makefile
@@ -3,7 +3,11 @@
qnoc-qcs404-objs := qcs404.o
qnoc-sdm845-objs := sdm845.o
icc-smd-rpm-objs := smd-rpm.o
+bcm-voter-objs := bcm-voter.o
+icc-rpmh-obj := icc-rpmh.o
obj-$(CONFIG_INTERCONNECT_QCOM_QCS404) += qnoc-qcs404.o
obj-$(CONFIG_INTERCONNECT_QCOM_SDM845) += qnoc-sdm845.o
obj-$(CONFIG_INTERCONNECT_QCOM_SMD_RPM) += icc-smd-rpm.o
+obj-$(CONFIG_INTERCONNECT_QCOM_BCM_VOTER) += bcm-voter.o
+obj-$(CONFIG_INTERCONNECT_QCOM_RPMH) += icc-rpmh.o
diff --git a/drivers/interconnect/qcom/bcm-voter.c
b/drivers/interconnect/qcom/bcm-voter.c
new file mode 100644
index 000..f74ae5f
--- /dev/null
+++ b/drivers/interconnect/qcom/bcm-voter.c
@@ -0,0 +1,355 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "bcm-voter.h"
+#include "icc-rpmh.h"
+
+static LIST_HEAD(bcm_voters);
+
+/**
+ * struct bcm_voter - Bus Clock Manager voter
+ * @dev: reference to the device that communicates with the BCM
+ * @np: reference to the device node to match bcm voters
+ * @lock: mutex to protect commit and wake/sleep lists in the voter
+ * @commit_list: list containing bcms to be committed to hardware
+ * @ws_list: list containing bcms that have different wake/sleep votes
+ * @voter_node: list of bcm voters
+ */
+struct bcm_voter {
+ struct device *dev;
+ struct device_node *np;
+ struct mutex lock;
+ struct list_head commit_list;
+ struct list_head ws_list;
+ struct list_head voter_node;
+};
+
+static int cmp_vcd(void *priv, struct list_head *a, struct list_head *b)
+{
+ const struct qcom_icc_bcm *bcm_a =
+ list_entry(a, struct qcom_icc_bcm, list);
+ const struct qcom_icc_bcm *bcm_b =
+ list_entry(b, struct qcom_icc_bcm, list);
+
+ if (bcm_a->aux_data.vcd < bcm_b->aux_data.vcd)
+ return -1;
+ else if (bcm_a->aux_data.vcd == bcm_b->aux_data.vcd)
+ return 0;
+ else
+ return 1;
+}
+
+static void bcm_aggregate(struct qcom_icc_bcm *bcm)
+{
+ size_t i, bucket;
+ u64 agg_avg[QCOM_ICC_NUM_BUCKETS] = {0};
+ u64 agg_peak[QCOM_ICC_NUM_BUCKETS] = {0};
+ u64 temp;
+
+ for (bucket = 0; bucket < QCOM_ICC_NUM_BUCKETS; bucket++) {
+ for (i = 0; i < bcm->num_nodes; i++) {
+ temp = bcm->nodes[i]->sum_avg[bucket] *
bcm->aux_data.width;
+ do_div(temp, bcm->nodes[i]->buswidth *
bcm->nodes[i]->channels);
+ agg_avg[bucket] = max(agg_avg[bucket], temp);
+
+ temp = bcm->nodes[i]->max_peak[bucket] *
bcm->aux_data.width;
+ do_div(temp, bcm->nodes[i]->buswidth);
+ agg_peak[bucket] = max(agg_peak[bucket], temp);
+ }
+
+ temp = agg_avg[bucket] * 1000ULL;
+ do_div(temp, bcm->aux_data.unit);
+ bcm->vote_x[bucket] = temp;
+
+ temp = agg_peak[bucket] * 1000ULL;
+
[RFC PATCH 2/4] arm64: dts: sdm845: Redefine interconnect provider DT nodes
Add the DT nodes for each of the Network-On-Chip interconnect
buses found on SDM845 based platform and redefine the rsc_hlos
child node as a bcm-voter device to better represent the hardware.
Signed-off-by: David Dai
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 60 ++--
1 file changed, 57 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index f406a43..a7ad79d 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1362,6 +1362,54 @@
reg = <0 0x0110 0 0x20>, <0 0x0130 0
0x5>;
reg-names = "llcc_base", "llcc_broadcast_base";
interrupts = ;
+
+ mem_noc: interconnect@138 {
+ compatible = "qcom,sdm845-mem-noc";
+ reg = <0 0x0138 0 0x27200>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ dc_noc: interconnect@14e {
+ compatible = "qcom,sdm845-dc-noc";
+ reg = <0 0x014e 0 0x400>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ config_noc: interconnect@150 {
+ compatible = "qcom,sdm845-config-noc";
+ reg = <0 0x0150 0 0x5080>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ system_noc: interconnect@162 {
+ compatible = "qcom,sdm845-system-noc";
+ reg = <0 0x0162 0 0x18080>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@16e {
+ compatible = "qcom,sdm845-aggre1-noc";
+ reg = <0 0x016e 0 0xd080>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ aggre2_noc: interconnect@170 {
+ compatible = "qcom,sdm845-aggre2-noc";
+ reg = <0 0x0170 0 0x3b100>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ mmss_noc: interconnect@174 {
+ compatible = "qcom,sdm845-mmss-noc";
+ reg = <0 0x0174 0 0x1c1000>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
};
ufs_mem_hc: ufshc@1d84000 {
@@ -3090,6 +3138,13 @@
#mbox-cells = <1>;
};
+ gladiator_noc: interconnect@1790 {
+ compatible = "qcom,sdm845-gladiator-noc";
+ reg = <0 0x1790 0 0xd080>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
apps_rsc: rsc@179c {
label = "apps_rsc";
compatible = "qcom,rpmh-rsc";
@@ -3164,9 +3219,8 @@
};
};
- rsc_hlos: interconnect {
- compatible = "qcom,sdm845-rsc-hlos";
- #interconnect-cells = <1>;
+ apps_bcm_voter: bcm-voter {
+ compatible = "qcom,sdm845-bcm-voter";
};
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[RFC PATCH 1/4] dt-bindings: interconnect: Update Qualcomm SDM845 DT bindings
Redefine the Network-on-Chip devices to more accurately describe
the interconnect topology on Qualcomm's SDM845 platform. Each
interconnect device can communicate with different instances of the
RPMh hardware which are described as RSCs(Resource State Coordinators).
As part of updating the DT bindings, convert the existing sdm845 bindings
to DT schema format using json-schema.
Signed-off-by: David Dai
---
.../bindings/interconnect/qcom,bcm-voter.yaml | 45 +
.../bindings/interconnect/qcom,sdm845.txt | 24 -
.../bindings/interconnect/qcom,sdm845.yaml | 108 +
3 files changed, 153 insertions(+), 24 deletions(-)
create mode 100644
Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml
delete mode 100644
Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
create mode 100644
Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml
b/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml
new file mode 100644
index 000..74f0715
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,bcm-voter.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm BCM-Voter Interconnect
+
+maintainers:
+ - David Dai
+
+description: |
+The Bus Clock Manager (BCM) is a dedicated hardware accelerator
+that manages shared system resources by aggregating requests
+from multiple Resource State Coordinators (RSC). Interconnect
+providers are able to vote for aggregated thresholds values from
+consumers by communicating through their respective RSCs.
+
+properties:
+ compatible:
+enum:
+ - qcom,sdm845-bcm-voter
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+apps_rsc: interconnect@179c {
+compatible = "qcom,rpmh-rsc";
+
+apps_bcm_voter: bcm_voter {
+compatible = "qcom,sdm845-bcm-voter";
+};
+};
+
+disp_rsc: interconnect@179d {
+compatible = "qcom,rpmh-rsc";
+
+disp_bcm_voter: bcm_voter {
+compatible = "qcom,sdm845-bcm-voter";
+};
+};
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
b/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
deleted file mode 100644
index 5c4f1d9..000
--- a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Qualcomm SDM845 Network-On-Chip interconnect driver binding
-
-SDM845 interconnect providers support system bandwidth requirements through
-RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
-able to communicate with the BCM through the Resource State Coordinator (RSC)
-associated with each execution environment. Provider nodes must reside within
-an RPMh device node pertaining to their RSC and each provider maps to a single
-RPMh resource.
-
-Required properties :
-- compatible : shall contain only one of the following:
- "qcom,sdm845-rsc-hlos"
-- #interconnect-cells : should contain 1
-
-Examples:
-
-apps_rsc: rsc {
- rsc_hlos: interconnect {
- compatible = "qcom,sdm845-rsc-hlos";
- #interconnect-cells = <1>;
- };
-};
-
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml
b/Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml
new file mode 100644
index 000..1aec321
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sdm845.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM845 Network-On-Chip Interconnect
+
+maintainers:
+ - David Dai
+
+description: |
+ SDM845 interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator
(RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+properties:
+ reg:
+maxItems: 1
+
+ compatible:
+enum:
+ - qcom,sdm845-aggre1-noc
+ - qcom,sdm845-aggre2-noc
+ - qcom,sdm845-config-noc
+ - qcom,sdm845-dc-noc
+ - qcom,sdm845-gladiator-noc
+ - qcom,sdm845-mem-noc
+ - qcom,sdm845-mmss-noc
+ - qcom,sdm845-system-noc
+
+ '#interconnect-cells':
+const: 1
+
+ qcom,bcm-voters:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
[RFC PATCH 0/4] Redefine interconnect provider DT nodes for SDM845
While there are no current consumers of the SDM845 interconnect device in devicetree, take this opportunity to redefine the interconnect device nodes as the previous definitions of using a single child node under the apps_rsc device did not accurately capture the description of the hardware. The Network-On-Chip (NoC) interconnect devices should be represented in a manner akin to QCS404 platforms[1] where there is a separation of NoC devices and its RPM/RPMh counterparts. The bcm-voter devices are representing the RPMh devices that the interconnect providers need to communicate with and there can be more than one instance of the Bus Clock Manager (BCM) which can live under different instances of Resource State Coordinators (RSC). There are display use cases where consumers may need to target a different bcm-voter (Some display specific RSC) than the default, and there needs to be a way to represent this connection in devicetree. This patches series extends the original discussion involving the SDM845 interconnect bindings[2] by adding accompanying driver implementations using the split NoC devices. The first patch also updates existing sdm845 binding documentation to DT schema format using json-schema. [1]: https://lkml.org/lkml/2019/6/13/143 [2]: https://lkml.org/lkml/2019/7/19/1063 David Dai (4): dt-bindings: interconnect: Update Qualcomm SDM845 DT bindings arm64: dts: sdm845: Redefine interconnect provider DT nodes interconnect: qcom: Refactor icc rpmh support interconnect: qcom: sdm845: Split qnodes into their respective NoCs .../bindings/interconnect/qcom,bcm-voter.yaml | 45 ++ .../bindings/interconnect/qcom,sdm845.txt | 24 - .../bindings/interconnect/qcom,sdm845.yaml | 108 +++ arch/arm64/boot/dts/qcom/sdm845.dtsi | 60 +- drivers/interconnect/qcom/Kconfig | 8 + drivers/interconnect/qcom/Makefile | 4 + drivers/interconnect/qcom/bcm-voter.c | 355 ++ drivers/interconnect/qcom/bcm-voter.h | 28 + drivers/interconnect/qcom/icc-rpmh.c | 154 + drivers/interconnect/qcom/icc-rpmh.h | 150 + drivers/interconnect/qcom/sdm845.c | 727 ++--- 11 files changed, 1115 insertions(+), 548 deletions(-) create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml delete mode 100644 Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml create mode 100644 drivers/interconnect/qcom/bcm-voter.c create mode 100644 drivers/interconnect/qcom/bcm-voter.h create mode 100644 drivers/interconnect/qcom/icc-rpmh.c create mode 100644 drivers/interconnect/qcom/icc-rpmh.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH] net: aquantia: add an error handling in aq_nic_set_multicast_list
From: Chenwandun Signed-off-by: Chenwandun --- drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c index 2a18439..137c1de 100644 --- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c +++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c @@ -664,6 +664,8 @@ int aq_nic_set_multicast_list(struct aq_nic_s *self, struct net_device *ndev) err = hw_ops->hw_multicast_list_set(self->aq_hw, self->mc_list.ar, self->mc_list.count); + if (err < 0) + return err; } return aq_nic_set_packet_filter(self, packet_filter); } -- 2.7.4
RE: [PATCH] usb: renesas_usbhs: fix __le16 warnings
Hi Simon-san,
> From: Simon Horman, Sent: Wednesday, October 16, 2019 9:27 PM
> > diff --git a/drivers/usb/renesas_usbhs/common.c
> > b/drivers/usb/renesas_usbhs/common.c
> > index 4c3de777ef6c..a3c30b609433 100644
> > --- a/drivers/usb/renesas_usbhs/common.c
> > +++ b/drivers/usb/renesas_usbhs/common.c
> > @@ -162,17 +162,17 @@ void usbhs_usbreq_get_val(struct usbhs_priv *priv,
> > struct usb_ctrlrequest *req)
> > req->bRequest = (val >> 8) & 0xFF;
> > req->bRequestType = (val >> 0) & 0xFF;
> >
> > - req->wValue = usbhs_read(priv, USBVAL);
> > - req->wIndex = usbhs_read(priv, USBINDX);
> > - req->wLength= usbhs_read(priv, USBLENG);
> > + req->wValue = cpu_to_le16(usbhs_read(priv, USBVAL));
> > + req->wIndex = cpu_to_le16(usbhs_read(priv, USBINDX));
> > + req->wLength= cpu_to_le16(usbhs_read(priv, USBLENG));
>
> usbhs_read is backed by readl which performs
> a le->cpu conversion. Rather than have a double conversion
> perhaps it would be nicer to introduce usbhs_read_le.
> Likewise for write.
I'm afraid but, I could not understand these comments.
At the moment, the usbhs_{read,write}() call io{read,write}16(),
not {read,write}l().
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/renesas_usbhs/common.c?h=v5.4-rc3#n62
Best regards,
Yoshihiro Shimoda
>
> > }
> >
> > void usbhs_usbreq_set_val(struct usbhs_priv *priv, struct usb_ctrlrequest
> > *req)
> > {
> > usbhs_write(priv, USBREQ, (req->bRequest << 8) | req->bRequestType);
> > - usbhs_write(priv, USBVAL, req->wValue);
> > - usbhs_write(priv, USBINDX, req->wIndex);
> > - usbhs_write(priv, USBLENG, req->wLength);
> > + usbhs_write(priv, USBVAL, le16_to_cpu(req->wValue));
> > + usbhs_write(priv, USBINDX, le16_to_cpu(req->wIndex));
> > + usbhs_write(priv, USBLENG, le16_to_cpu(req->wLength));
> >
> > usbhs_bset(priv, DCPCTR, SUREQ, SUREQ);
> > }
> > --
> > 2.23.0
> >
Re: [PATCH] KVM: SVM: Fix potential wrong physical id in avic_handle_ldr_update
Vitaly Kuznetsov writes: >> Guest physical APIC ID may not equal to vcpu->vcpu_id in some case. >> We may set the wrong physical id in avic_handle_ldr_update as we >> always use vcpu->vcpu_id. Hi, Vitaly, thanks for your reply. Do you think there may be a wrong physical id in avic_handle_ldr_update too ? >> >> @@ -4591,6 +4591,8 @@ static int avic_handle_ldr_update(struct kvm_vcpu >> *vcpu) >> int ret = 0; >> struct vcpu_svm *svm = to_svm(vcpu); >> u32 ldr = kvm_lapic_get_reg(vcpu->arch.apic, APIC_LDR); >> +u32 apic_id_reg = kvm_lapic_get_reg(vcpu->arch.apic, APIC_ID); >> +u32 id = (apic_id_reg >> 24) & 0xff; > >If we reach here than we're guaranteed to be in xAPIC mode, right? Could you >maybe export and use kvm_xapic_id() here then (and in >avic_handle_apic_id_update() too)? > I think we're guaranteed to be in xAPIC mode when we reach here. I would have a try to export and use use kvm_xapic_id here and in avic_handle_apic_id_update too. Thanks for your suggestion. Have a nice day. Best wishes.
Re: [PATCH] kheaders: substituting --sort in archive creation
On Mon, Oct 14, 2019 at 10:40 PM Quentin Perret wrote:
>
> Hi Dmitry,
>
> On Wednesday 09 Oct 2019 at 13:42:14 (+), Dmitry Goldin wrote:
> > From: Dmitry Goldin
> >
> > The option --sort=ORDER was only introduced in tar 1.28 (2014), which
> > is rather new and might not be available in some setups.
> >
> > This patch tries to replicate the previous behaviour as closely as possible
> > to fix the kheaders build for older environments. It does not produce
> > identical
> > archives compared to the previous version due to minor sorting
> > differences but produces reproducible results itself in my tests.
> >
> > Signed-off-by: Dmitry Goldin
> > ---
> > kernel/gen_kheaders.sh | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/gen_kheaders.sh b/kernel/gen_kheaders.sh
> > index aff79e461fc9..5a0fc0b0403a 100755
> > --- a/kernel/gen_kheaders.sh
> > +++ b/kernel/gen_kheaders.sh
> > @@ -71,10 +71,13 @@ done | cpio --quiet -pd $cpio_dir >/dev/null 2>&1
> > find $cpio_dir -type f -print0 |
> > xargs -0 -P8 -n1 perl -pi -e 'BEGIN {undef $/;};
> > s/\/\*((?!SPDX).)*?\*\///smg;'
> >
> > -# Create archive and try to normalize metadata for reproducibility
> > -tar "${KBUILD_BUILD_TIMESTAMP:+--mtime=$KBUILD_BUILD_TIMESTAMP}" \
> > ---owner=0 --group=0 --sort=name --numeric-owner \
> > --Jcf $tarfile -C $cpio_dir/ . > /dev/null
> > +# Create archive and try to normalize metadata for reproducibility.
> > +# For compatibility with older versions of tar, files are fed to tar
> > +# pre-sorted, as --sort=name might not be available.
> > +find $cpio_dir -printf "./%P\n" | LC_ALL=C sort | \
> > +tar "${KBUILD_BUILD_TIMESTAMP:+--mtime=$KBUILD_BUILD_TIMESTAMP}" \
> > +--owner=0 --group=0 --numeric-owner --no-recursion \
> > +-Jcf $tarfile -C $cpio_dir/ -T - > /dev/null
> >
> > echo "$src_files_md5" > kernel/kheaders.md5
> > echo "$obj_files_md5" >> kernel/kheaders.md5
> > --
> > 2.23.0
>
> FWIW:
>
> Tested-by: Quentin Perret
>
> It turns out this issue broke something in our CI, could this patch be
> queued as a -rc4 fix ?
Applied to linux-kbuild/fixes. Thanks.
I will send a pull request for -rc4.
--
Best Regards
Masahiro Yamada
Re: KASAN: use-after-free Read in mnt_warn_timestamp_expiry
On Wed, Oct 16, 2019 at 06:47:55PM -0700, Eric Biggers wrote: > On Wed, Oct 16, 2019 at 06:42:11PM -0700, syzbot wrote: > > == > > BUG: KASAN: use-after-free in mnt_warn_timestamp_expiry+0x4a/0x250 > > fs/namespace.c:2471 > > Read of size 8 at addr 888099937328 by task syz-executor.1/18510 > > > > Looks like a duplicate of this: > > #syz dup: KASAN: use-after-free Read in do_mount > > See the existing thread and proposed fix here: > https://lkml.kernel.org/linux-fsdevel/805e5505945a2...@google.com/T/#u FWIW, I'd go with your "move mnt_warn_timestamp_expiry() up". However, I'd probably turn the message into something like foofs filesystem getting mounted at /mnt/barf supports... And s/mounted/reconfigured/ if mnt_has_parent(mnt) is already true. Objections? Al, currently experiencing the joy of being ears-deep in 5 different shitpiles simultaneously...
Re: [PATCH] staging: sm750fb: format description of parameters the to kernel doc format
On 10/16/19 6:29 PM, gbittencourt wrote: > Hi Randy, > > On 10/16/19 10:25 PM, Randy Dunlap wrote: >> Hi, >> >> On 10/16/19 6:18 PM, Gabriela Bittencourt wrote: >>> Cluster comments that describes parameters of functions and create one >>> single comment before the function in kernel doc format. >> Good plan. >> >> How did you test this patch? > I haven't test it. How can I do it? Hm. There used to be a comment in a (now deleted) document named Documentation/kernel-doc-nano-HOWTO.txt about how to test kernel-doc. I took that comment and made a script from it. I'll attach the script. It's easy to use, but it is made to test only one function or struct or union or enum at a time. You need to have a script named 'kernel-doc' in your PATH or you can specify where the script is located by using $ KERNDOC=path/to/scripts/kernel-doc kdoc_function _parameters_ Its usage is: kdoc_function filename funcname [text|man|html|docbook|xml] where funcname can be a function, struct, union, or enum name. The output format can be any of those listed, but the default is "text". Let me know if you have any questions or problems. >>> Signed-off-by: Gabriela Bittencourt >>> --- >>> drivers/staging/sm750fb/sm750_accel.c | 65 +++ >>> 1 file changed, 37 insertions(+), 28 deletions(-) -- ~Randy #! /bin/sh # from linux/Documentation/kernel-doc-nano-HOWTO.txt # uses linux/scripts/kernel-doc or a copy of it (in $PATH). # using "LANG=C or LC_ALL=C kdoc_function " can be useful. # Can use "KERNDOC= kdoc_function " to vary # which kernel-doc script is used. verbose= debug= if [ "$KERNDOC" = "" ]; then KERNDOC=kernel-doc fi # careful: must enter -v before -x: if [ "$1" = "-v" ]; then verbose="-v" shift fi if [ "$1" = "-x" ]; then debug="-x" shift fi file="$1" fn="$2" # fmt can be "text|man|html|docbook|xml" (default is "text") # docbook produces xml fmt="$3" if [ x$3 = x ]; then fmt="text" fi if [ "$2" = "" ]; then echo "usage: kdoc_function filename funcname [text|man|html|docbook|xml]" exit 1 fi case $fmt in man) $KERNDOC $verbose $debug -man -function $fn $file | nroff -man | less ;; html) $KERNDOC $verbose $debug -html -function $fn $file >kerneldoc.html echo "see kerneldoc.html" ;; docbook|xml) $KERNDOC $verbose $debug -docbook -function $fn $file >kerneldoc.xml echo "see kerneldoc.xml" ;; *) $KERNDOC $verbose $debug -text -function $fn $file | less ;; esac
Re: [RFC PATCH 2/3] perf tools: Add support for "report" for some spe events
On 2019/10/16 18:12, James Clark wrote: > Hi Xiaojun, > >>> >>> What do you mean when the user specifies "event:pp", if the SPE is >>> available, configure and record the spe data directly via the perf event >>> open syscall? >>> (perf.data itself is the same as using -e arm_spe_0//xxx?) >> >> I mean, for the perf record, if the user does not add ":pp" to these events, >> the original process is taken, and if ":pp" is added, the spe process is >> taken. >> > > Yes we think this is the best way to do it considering that SPE has been > implemented as a separate PMU and it will be very difficult to do it in the > Kernel when the precise_ip attribute is set. > > I think doing everything in userspace is easiest. This will at least mean > that users of Perf don't have to be aware of the details of SPE to get > precise sample data. > > So if the user specifies "event:p" when SPE is available, the SPE PMU is > automatically configured data is recorded. If the user also specifies -e > arm_spe_0//xxx and wants to do some manual configuration, then that could > override the automatic configuration. > > > James > > > OK. I got it. I found a bug in the test. If I specify cpu_list(use -a or -C) when logging spe data, some events with "pid:0 tid:0" is logged. This is obviously wrong. I want to solve this problem, but I haven't found out what went wrong. -- [root@server121 perf]# perf record -e arm_spe_0/branch_filter=1,ts_enable=1,pa_enable=1,load_filter=1,jitter=0,store_filter=1,min_latency=0/ -a [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 7.925 MB perf.data ] [root@server121 perf]# perf report -D > spe_dump.out [root@server121 perf]# vim spe_dump.out -- ... 0xd0330 [0x30]: event: 12 . . ... raw event: size 48 bytes . : 0c 00 00 00 00 00 30 00 00 00 00 00 00 00 00 00 ..0. . 0010: 00 00 00 00 00 00 00 00 f8 d9 fe bd f7 08 02 00 . 0020: 00 00 00 00 00 00 00 00 4c bc 14 00 00 00 00 00 L... 0 572810090961400 0xd0330 [0x30]: PERF_RECORD_ITRACE_START pid: 0 tid: 0 0xd0438 [0x30]: event: 12 . . ... raw event: size 48 bytes . : 0c 00 00 00 00 00 30 00 00 00 00 00 00 00 00 00 ..0. . 0010: 00 00 00 00 00 00 00 00 d8 ef fe bd f7 08 02 00 . 0020: 01 00 00 00 00 00 00 00 4d bc 14 00 00 00 00 00 M... 1 572810090967000 0xd0438 [0x30]: PERF_RECORD_ITRACE_START pid: 0 tid: 0 ... -- Thanks. Xiaojun.
[PATCH v2 1/2] kasan: detect negative size in memory operation function
KASAN missed detecting size is negative numbers in memset(), memcpy(),
and memmove(), it will cause out-of-bounds bug, so needs to be detected
by KASAN.
If size is negative numbers, then it has three reasons to be
defined as heap-out-of-bounds bug type.
1) Casting negative numbers to size_t would indeed turn up as
a large size_t and its value will be larger than ULONG_MAX/2,
so that this can qualify as out-of-bounds.
2) If KASAN has new bug type and user-space passes negative size,
then there are duplicate reports. So don't produce new bug type
in order to prevent duplicate reports by some systems (e.g. syzbot)
to report the same bug twice.
3) When size is negative numbers, it may be passed from user-space.
So we always print heap-out-of-bounds in order to prevent that
kernel-space and user-space have the same bug but have duplicate
reports.
KASAN report:
BUG: KASAN: heap-out-of-bounds in kmalloc_memmove_invalid_size+0x70/0xa0
Read of size 18446744073709551608 at addr ff8069660904 by task cat/72
CPU: 2 PID: 72 Comm: cat Not tainted
5.4.0-rc1-next-20191004ajb-1-gdb8af2f372b2-dirty #1
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x0/0x288
show_stack+0x14/0x20
dump_stack+0x10c/0x164
print_address_description.isra.9+0x68/0x378
__kasan_report+0x164/0x1a0
kasan_report+0xc/0x18
check_memory_region+0x174/0x1d0
memmove+0x34/0x88
kmalloc_memmove_invalid_size+0x70/0xa0
[1] https://bugzilla.kernel.org/show_bug.cgi?id=199341
Changes in v2:
Fix the indentation bug, thanks for the reminder Matthew.
Signed-off-by: Walter Wu
Reported-by: Dmitry Vyukov
Suggested-by: Dmitry Vyukov
Reviewed-by: Dmitry Vyukov
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
---
mm/kasan/common.c | 13 -
mm/kasan/generic.c| 5 +
mm/kasan/generic_report.c | 18 ++
mm/kasan/tags.c | 5 +
mm/kasan/tags_report.c| 18 ++
5 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 6814d6d6a023..16a370023425 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -102,7 +102,8 @@ EXPORT_SYMBOL(__kasan_check_write);
#undef memset
void *memset(void *addr, int c, size_t len)
{
- check_memory_region((unsigned long)addr, len, true, _RET_IP_);
+ if (!check_memory_region((unsigned long)addr, len, true, _RET_IP_))
+ return NULL;
return __memset(addr, c, len);
}
@@ -110,8 +111,9 @@ void *memset(void *addr, int c, size_t len)
#undef memmove
void *memmove(void *dest, const void *src, size_t len)
{
- check_memory_region((unsigned long)src, len, false, _RET_IP_);
- check_memory_region((unsigned long)dest, len, true, _RET_IP_);
+ if (!check_memory_region((unsigned long)src, len, false, _RET_IP_) ||
+ !check_memory_region((unsigned long)dest, len, true, _RET_IP_))
+ return NULL;
return __memmove(dest, src, len);
}
@@ -119,8 +121,9 @@ void *memmove(void *dest, const void *src, size_t len)
#undef memcpy
void *memcpy(void *dest, const void *src, size_t len)
{
- check_memory_region((unsigned long)src, len, false, _RET_IP_);
- check_memory_region((unsigned long)dest, len, true, _RET_IP_);
+ if (!check_memory_region((unsigned long)src, len, false, _RET_IP_) ||
+ !check_memory_region((unsigned long)dest, len, true, _RET_IP_))
+ return NULL;
return __memcpy(dest, src, len);
}
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index 616f9dd82d12..02148a317d27 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -173,6 +173,11 @@ static __always_inline bool
check_memory_region_inline(unsigned long addr,
if (unlikely(size == 0))
return true;
+ if (unlikely((long)size < 0)) {
+ kasan_report(addr, size, write, ret_ip);
+ return false;
+ }
+
if (unlikely((void *)addr <
kasan_shadow_to_mem((void *)KASAN_SHADOW_START))) {
kasan_report(addr, size, write, ret_ip);
diff --git a/mm/kasan/generic_report.c b/mm/kasan/generic_report.c
index 36c645939bc9..52a92c7db697 100644
--- a/mm/kasan/generic_report.c
+++ b/mm/kasan/generic_report.c
@@ -107,6 +107,24 @@ static const char *get_wild_bug_type(struct
kasan_access_info *info)
const char *get_bug_type(struct kasan_access_info *info)
{
+ /*
+* If access_size is negative numbers, then it has three reasons
+* to be defined as heap-out-of-bounds bug type.
+* 1) Casting negative numbers to size_t would indeed turn up as
+*a large size_t and its value will be larger than ULONG_MAX/2,
+*so that this can qualify as out-of-bounds.
+* 2) If KASAN has new bug type and user-space passes negative size,
+*then there are duplicate reports. So don't produce new bug type
+*in order to
Re: KASAN: use-after-free Read in mnt_warn_timestamp_expiry
On Wed, Oct 16, 2019 at 06:42:11PM -0700, syzbot wrote: > == > BUG: KASAN: use-after-free in mnt_warn_timestamp_expiry+0x4a/0x250 > fs/namespace.c:2471 > Read of size 8 at addr 888099937328 by task syz-executor.1/18510 > Looks like a duplicate of this: #syz dup: KASAN: use-after-free Read in do_mount See the existing thread and proposed fix here: https://lkml.kernel.org/linux-fsdevel/805e5505945a2...@google.com/T/#u - Eric
[PATCH] apparmor: Fix use-after-free in aa_audit_rule_init
In the implementation of aa_audit_rule_init(), when aa_label_parse()
fails the allocated memory for rule is released using
aa_audit_rule_free(). But after this release the the return statement
tries to access the label field of the rule which results in
use-after-free. Before releaseing the rule, copy errNo and return it
after releasing rule.
Fixes: 52e8c38001d8 ("apparmor: Fix memory leak of rule on error exit path")
Signed-off-by: Navid Emamdoost
---
security/apparmor/audit.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/security/apparmor/audit.c b/security/apparmor/audit.c
index 5a98661a8b46..48c15fb0aafe 100644
--- a/security/apparmor/audit.c
+++ b/security/apparmor/audit.c
@@ -178,6 +178,7 @@ void aa_audit_rule_free(void *vrule)
int aa_audit_rule_init(u32 field, u32 op, char *rulestr, void **vrule)
{
struct aa_audit_rule *rule;
+ int err;
switch (field) {
case AUDIT_SUBJ_ROLE:
@@ -197,8 +198,9 @@ int aa_audit_rule_init(u32 field, u32 op, char *rulestr,
void **vrule)
rule->label = aa_label_parse(_ns->unconfined->label, rulestr,
GFP_KERNEL, true, false);
if (IS_ERR(rule->label)) {
+ err = rule->label;
aa_audit_rule_free(rule);
- return PTR_ERR(rule->label);
+ return PTR_ERR(err);
}
*vrule = rule;
--
2.17.1
KASAN: use-after-free Read in mnt_warn_timestamp_expiry
Hello,
syzbot found the following crash on:
HEAD commit:3b1f00ac Merge tag 'for_linus' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=137ae2bb60
kernel config: https://syzkaller.appspot.com/x/.config?x=f0a8b0a0736a2ac1
dashboard link: https://syzkaller.appspot.com/bug?extid=76a43f2b4d34cfc53548
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10dde730e0
The bug was bisected to:
commit 452c2779410a03ac0c6be0a8a91c83aa80bdd7e5
Author: Deepa Dinamani
Date: Fri Mar 8 20:40:03 2019 +
fs: sysv: Initialize filesystem timestamp ranges
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13c6e2bb60
final crash:https://syzkaller.appspot.com/x/report.txt?x=1026e2bb60
console output: https://syzkaller.appspot.com/x/log.txt?x=17c6e2bb60
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+76a43f2b4d34cfc53...@syzkaller.appspotmail.com
Fixes: 452c2779410a ("fs: sysv: Initialize filesystem timestamp ranges")
==
BUG: KASAN: use-after-free in mnt_warn_timestamp_expiry+0x4a/0x250
fs/namespace.c:2471
Read of size 8 at addr 888099937328 by task syz-executor.1/18510
CPU: 0 PID: 18510 Comm: syz-executor.1 Not tainted 5.4.0-rc3+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
print_address_description+0x75/0x5c0 mm/kasan/report.c:374
__kasan_report+0x14b/0x1c0 mm/kasan/report.c:506
kasan_report+0x26/0x50 mm/kasan/common.c:634
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
mnt_warn_timestamp_expiry+0x4a/0x250 fs/namespace.c:2471
do_new_mount_fc fs/namespace.c:2773 [inline]
do_new_mount fs/namespace.c:2825 [inline]
do_mount+0x2160/0x2510 fs/namespace.c:3143
ksys_mount+0xcc/0x100 fs/namespace.c:3352
__do_sys_mount fs/namespace.c:3366 [inline]
__se_sys_mount fs/namespace.c:3363 [inline]
__x64_sys_mount+0xbf/0xd0 fs/namespace.c:3363
do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459a59
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f1f46735c78 EFLAGS: 0246 ORIG_RAX: 00a5
RAX: ffda RBX: 0005 RCX: 00459a59
RDX: 2a40 RSI: 25c0 RDI:
RBP: 0075bf20 R08: R09:
R10: R11: 0246 R12: 7f1f467366d4
R13: 004c62a4 R14: 004db438 R15:
Allocated by task 18510:
save_stack mm/kasan/common.c:69 [inline]
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc+0x11c/0x1b0 mm/kasan/common.c:510
kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:518
slab_post_alloc_hook mm/slab.h:584 [inline]
slab_alloc mm/slab.c:3319 [inline]
kmem_cache_alloc+0x1f5/0x2e0 mm/slab.c:3483
kmem_cache_zalloc include/linux/slab.h:680 [inline]
alloc_vfsmnt+0x27/0x470 fs/namespace.c:177
vfs_create_mount+0x87/0x440 fs/namespace.c:940
do_new_mount_fc fs/namespace.c:2763 [inline]
do_new_mount fs/namespace.c:2825 [inline]
do_mount+0x1ee0/0x2510 fs/namespace.c:3143
ksys_mount+0xcc/0x100 fs/namespace.c:3352
__do_sys_mount fs/namespace.c:3366 [inline]
__se_sys_mount fs/namespace.c:3363 [inline]
__x64_sys_mount+0xbf/0xd0 fs/namespace.c:3363
do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 16:
save_stack mm/kasan/common.c:69 [inline]
set_track mm/kasan/common.c:77 [inline]
kasan_set_free_info mm/kasan/common.c:332 [inline]
__kasan_slab_free+0x12a/0x1e0 mm/kasan/common.c:471
kasan_slab_free+0xe/0x10 mm/kasan/common.c:480
__cache_free mm/slab.c:3425 [inline]
kmem_cache_free+0x81/0xf0 mm/slab.c:3693
free_vfsmnt fs/namespace.c:554 [inline]
delayed_free_vfsmnt+0x74/0x80 fs/namespace.c:559
__rcu_reclaim kernel/rcu/rcu.h:222 [inline]
rcu_do_batch kernel/rcu/tree.c:2157 [inline]
rcu_core+0x843/0x1050 kernel/rcu/tree.c:2377
rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2386
__do_softirq+0x333/0x7c4 arch/x86/include/asm/paravirt.h:766
The buggy address belongs to the object at 888099937300
which belongs to the cache mnt_cache of size 312
The buggy address is located 40 bytes inside of
312-byte region [888099937300, 888099937438)
The buggy address belongs to the page:
page:ea0002664dc0 refcount:1 mapcount:0 mapping:8880aa5a9a80
index:0x888099937180
flags: 0x1fffc000200(slab)
raw: 01fffc000200 ea000285d4c8 ea00026ab308
KMSAN: uninit-value in read_sensor_register (2)
Hello, syzbot found the following crash on: HEAD commit:c2453450 kmsan: kcov: prettify the code unpoisoning area->.. git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=14c95fe760 kernel config: https://syzkaller.appspot.com/x/.config?x=3684f3c73f43899a dashboard link: https://syzkaller.appspot.com/bug?extid=64437af5c781a7f0e08e compiler: clang version 9.0.0 (/home/glider/llvm/clang 80fee25776c2fb61e74c1ecb1a523375c2500b69) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15e1a3a0e0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=119f406b60 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+64437af5c781a7f0e...@syzkaller.appspotmail.com usb 1-1: New USB device found, idVendor=0ac8, idProduct=c301, bcdDevice=8b.4c usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-1: config 0 descriptor?? gspca_main: vc032x-2.14.0 probing 0ac8:c301 gspca_vc032x: reg_w err -71 = BUG: KMSAN: uninit-value in read_sensor_register+0x4b7/0xd30 drivers/media/usb/gspca/vc032x.c:2971 CPU: 1 PID: 3904 Comm: kworker/1:2 Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x14a/0x2f0 mm/kmsan/kmsan_report.c:109 __msan_warning+0x73/0xf0 mm/kmsan/kmsan_instr.c:245 read_sensor_register+0x4b7/0xd30 drivers/media/usb/gspca/vc032x.c:2971 vc032x_probe_sensor drivers/media/usb/gspca/vc032x.c:3032 [inline] sd_init+0x2cf3/0x4530 drivers/media/usb/gspca/vc032x.c:3163 gspca_dev_probe2+0xe93/0x2230 drivers/media/usb/gspca/gspca.c:1532 gspca_dev_probe+0x346/0x3b0 drivers/media/usb/gspca/gspca.c:1605 sd_probe+0x8d/0xa0 drivers/media/usb/gspca/gl860/gl860.c:511 usb_probe_interface+0xd19/0x1310 drivers/usb/core/driver.c:361 really_probe+0xd91/0x1f90 drivers/base/dd.c:552 driver_probe_device+0x1ba/0x510 drivers/base/dd.c:721 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:828 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:430 __device_attach+0x489/0x750 drivers/base/dd.c:894 device_initial_probe+0x4a/0x60 drivers/base/dd.c:941 bus_probe_device+0x131/0x390 drivers/base/bus.c:490 device_add+0x25b5/0x2df0 drivers/base/core.c:2201 usb_set_configuration+0x309f/0x3710 drivers/usb/core/message.c:2027 generic_probe+0xe7/0x280 drivers/usb/core/generic.c:210 usb_probe_device+0x146/0x200 drivers/usb/core/driver.c:266 really_probe+0xd91/0x1f90 drivers/base/dd.c:552 driver_probe_device+0x1ba/0x510 drivers/base/dd.c:721 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:828 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:430 __device_attach+0x489/0x750 drivers/base/dd.c:894 device_initial_probe+0x4a/0x60 drivers/base/dd.c:941 bus_probe_device+0x131/0x390 drivers/base/bus.c:490 device_add+0x25b5/0x2df0 drivers/base/core.c:2201 usb_new_device+0x23e5/0x2fb0 drivers/usb/core/hub.c:2536 hub_port_connect drivers/usb/core/hub.c:5098 [inline] hub_port_connect_change drivers/usb/core/hub.c:5213 [inline] port_event drivers/usb/core/hub.c:5359 [inline] hub_event+0x581d/0x72f0 drivers/usb/core/hub.c:5441 process_one_work+0x1572/0x1ef0 kernel/workqueue.c:2269 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415 kthread+0x4b5/0x4f0 kernel/kthread.c:256 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:150 [inline] kmsan_internal_poison_shadow+0x60/0x110 mm/kmsan/kmsan.c:133 kmsan_slab_alloc+0xaa/0x130 mm/kmsan/kmsan_hooks.c:101 slab_alloc_node mm/slub.c:2792 [inline] slab_alloc mm/slub.c:2801 [inline] kmem_cache_alloc_trace+0x8c5/0xd20 mm/slub.c:2818 kmalloc include/linux/slab.h:556 [inline] gspca_dev_probe2+0x30d/0x2230 drivers/media/usb/gspca/gspca.c:1464 gspca_dev_probe+0x346/0x3b0 drivers/media/usb/gspca/gspca.c:1605 sd_probe+0x8d/0xa0 drivers/media/usb/gspca/gl860/gl860.c:511 usb_probe_interface+0xd19/0x1310 drivers/usb/core/driver.c:361 really_probe+0xd91/0x1f90 drivers/base/dd.c:552 driver_probe_device+0x1ba/0x510 drivers/base/dd.c:721 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:828 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:430 __device_attach+0x489/0x750 drivers/base/dd.c:894 device_initial_probe+0x4a/0x60 drivers/base/dd.c:941 bus_probe_device+0x131/0x390 drivers/base/bus.c:490 device_add+0x25b5/0x2df0 drivers/base/core.c:2201 usb_set_configuration+0x309f/0x3710 drivers/usb/core/message.c:2027 generic_probe+0xe7/0x280 drivers/usb/core/generic.c:210 usb_probe_device+0x146/0x200 drivers/usb/core/driver.c:266 really_probe+0xd91/0x1f90 drivers/base/dd.c:552 driver_probe_device+0x1ba/0x510 drivers/base/dd.c:721 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:828
Re: [PATCH 4.9 00/92] 4.9.197-stable review
stable-rc/linux-4.9.y boot: 42 boots: 0 failed, 39 passed with 3 offline (v4.9.196-93-g8811b6f62880) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.196-93-g8811b6f62880/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.196-93-g8811b6f62880/ Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.196-93-g8811b6f62880 Git Commit: 8811b6f62880b7a4b6d43be23d9837491ce18ea0 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 36 unique boards, 12 SoC families, 13 builds out of 197 Offline Platforms: arm: sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab --- For more info write to
KASAN: slab-out-of-bounds Read in ld_usb_read (3)
Hello, syzbot found the following crash on: HEAD commit:22be26f7 usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=14f6dc5f60 kernel config: https://syzkaller.appspot.com/x/.config?x=387eccb7ac68ec5 dashboard link: https://syzkaller.appspot.com/bug?extid=6fe95b826644f7f12b0b compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=102c322760 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12a503a0e0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+6fe95b826644f7f12...@syzkaller.appspotmail.com ldusb 1-1:0.28: Read buffer overflow, -131383859965943 bytes dropped == BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x124/0x150 lib/usercopy.c:28 Read of size 102391 at addr 8881cfb40008 by task syz-executor372/1737 CPU: 0 PID: 1737 Comm: syz-executor372 Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 print_address_description.constprop.0+0x36/0x50 mm/kasan/report.c:374 __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:506 kasan_report+0xe/0x20 mm/kasan/common.c:634 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x128/0x190 mm/kasan/generic.c:192 _copy_to_user+0x124/0x150 lib/usercopy.c:28 copy_to_user include/linux/uaccess.h:152 [inline] ld_usb_read+0x329/0x760 drivers/usb/misc/ldusb.c:492 __vfs_read+0x76/0x100 fs/read_write.c:425 vfs_read+0x1ea/0x430 fs/read_write.c:461 ksys_read+0x1e8/0x250 fs/read_write.c:587 do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4421d9 Code: e8 7c e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 bb 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffc08eb0888 EFLAGS: 0246 ORIG_RAX: RAX: ffda RBX: 7ffc08eb0ae0 RCX: 004421d9 RDX: 00018ff7 RSI: 2a80 RDI: 0004 RBP: R08: 000f R09: 00402eb0 R10: R11: 0246 R12: R13: 00402eb0 R14: R15: The buggy address belongs to the page: page:ea00073ed000 refcount:1 mapcount:0 mapping: index:0x0 compound_mapcount: 0 flags: 0x201(head) raw: 0201 dead0100 dead0122 raw: 0001 page dumped because: kasan: bad access detected Memory state around the buggy address: 8881cfb55500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8881cfb55580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8881cfb55600: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe ^ 8881cfb55680: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe 8881cfb55700: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH 4.4 00/79] 4.4.197-stable review
stable-rc/linux-4.4.y boot: 80 boots: 2 failed, 72 passed with 6 offline (v4.4.196-80-g645def690295) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.196-80-g645def690295/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.196-80-g645def690295/ Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.196-80-g645def690295 Git Commit: 645def69029558d1f5833e6b95e81180671da907 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 42 unique boards, 17 SoC families, 13 builds out of 190 Boot Failures Detected: x86_64: x86_64_defconfig: gcc-8: qemu_x86_64: 1 failed lab i386: i386_defconfig: gcc-8: qemu_i386: 1 failed lab Offline Platforms: arm: sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab multi_v7_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab --- For more info write to
Re: [PATCH 4.14 00/65] 4.14.150-stable review
stable-rc/linux-4.14.y boot: 104 boots: 1 failed, 97 passed with 6 offline (v4.14.149-65-gb29fcefccab6) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.149-65-gb29fcefccab6/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.149-65-gb29fcefccab6/ Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.149-65-gb29fcefccab6 Git Commit: b29fcefccab67589bcd5b49b74967d723e708013 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 60 unique boards, 21 SoC families, 13 builds out of 201 Boot Failure Detected: arm64: defconfig: gcc-8: meson-gxbb-p200: 1 failed lab Offline Platforms: arm: sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab multi_v7_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab --- For more info write to
KMSAN: kernel-usb-infoleak in pcan_usb_wait_rsp
Hello, syzbot found the following crash on: HEAD commit:c2453450 kmsan: kcov: prettify the code unpoisoning area->.. git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=11934730e0 kernel config: https://syzkaller.appspot.com/x/.config?x=3684f3c73f43899a dashboard link: https://syzkaller.appspot.com/bug?extid=863724e7128e14b26732 compiler: clang version 9.0.0 (/home/glider/llvm/clang 80fee25776c2fb61e74c1ecb1a523375c2500b69) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1243128760 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1743306b60 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+863724e7128e14b26...@syzkaller.appspotmail.com usb 1-1: config 0 interface 210 altsetting 0 endpoint 0x1 has an invalid bInterval 0, changing to 7 usb 1-1: New USB device found, idVendor=0c72, idProduct=000c, bcdDevice=7c.aa usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-1: config 0 descriptor?? hub 1-1:0.210: ignoring external hub = BUG: KMSAN: kernel-usb-infoleak in kmsan_handle_urb+0x28/0x40 mm/kmsan/kmsan_hooks.c:381 CPU: 0 PID: 2900 Comm: kworker/0:2 Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x14a/0x2f0 mm/kmsan/kmsan_report.c:109 kmsan_internal_check_memory+0x3bb/0x4e0 mm/kmsan/kmsan.c:469 kmsan_handle_urb+0x28/0x40 mm/kmsan/kmsan_hooks.c:381 usb_submit_urb+0x7ef/0x1f50 drivers/usb/core/urb.c:405 usb_start_wait_urb+0x143/0x410 drivers/usb/core/message.c:58 usb_bulk_msg+0x811/0x920 drivers/usb/core/message.c:257 pcan_usb_send_cmd drivers/net/can/usb/peak_usb/pcan_usb.c:127 [inline] pcan_usb_wait_rsp+0x25c/0x6e0 drivers/net/can/usb/peak_usb/pcan_usb.c:151 pcan_usb_get_serial drivers/net/can/usb/peak_usb/pcan_usb.c:310 [inline] pcan_usb_init+0xcc/0x450 drivers/net/can/usb/peak_usb/pcan_usb.c:801 peak_usb_create_dev drivers/net/can/usb/peak_usb/pcan_usb_core.c:809 [inline] peak_usb_probe+0x1416/0x1b20 drivers/net/can/usb/peak_usb/pcan_usb_core.c:907 usb_probe_interface+0xd19/0x1310 drivers/usb/core/driver.c:361 really_probe+0xd91/0x1f90 drivers/base/dd.c:552 driver_probe_device+0x1ba/0x510 drivers/base/dd.c:721 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:828 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:430 __device_attach+0x489/0x750 drivers/base/dd.c:894 device_initial_probe+0x4a/0x60 drivers/base/dd.c:941 bus_probe_device+0x131/0x390 drivers/base/bus.c:490 device_add+0x25b5/0x2df0 drivers/base/core.c:2201 usb_set_configuration+0x309f/0x3710 drivers/usb/core/message.c:2027 generic_probe+0xe7/0x280 drivers/usb/core/generic.c:210 usb_probe_device+0x146/0x200 drivers/usb/core/driver.c:266 really_probe+0xd91/0x1f90 drivers/base/dd.c:552 driver_probe_device+0x1ba/0x510 drivers/base/dd.c:721 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:828 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:430 __device_attach+0x489/0x750 drivers/base/dd.c:894 device_initial_probe+0x4a/0x60 drivers/base/dd.c:941 bus_probe_device+0x131/0x390 drivers/base/bus.c:490 device_add+0x25b5/0x2df0 drivers/base/core.c:2201 usb_new_device+0x23e5/0x2fb0 drivers/usb/core/hub.c:2536 hub_port_connect drivers/usb/core/hub.c:5098 [inline] hub_port_connect_change drivers/usb/core/hub.c:5213 [inline] port_event drivers/usb/core/hub.c:5359 [inline] hub_event+0x581d/0x72f0 drivers/usb/core/hub.c:5441 process_one_work+0x1572/0x1ef0 kernel/workqueue.c:2269 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415 kthread+0x4b5/0x4f0 kernel/kthread.c:256 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:150 [inline] kmsan_internal_poison_shadow+0x60/0x110 mm/kmsan/kmsan.c:133 kmsan_slab_alloc+0xaa/0x130 mm/kmsan/kmsan_hooks.c:101 slab_alloc_node mm/slub.c:2792 [inline] slab_alloc mm/slub.c:2801 [inline] kmem_cache_alloc_trace+0x8c5/0xd20 mm/slub.c:2818 kmalloc include/linux/slab.h:556 [inline] peak_usb_create_dev drivers/net/can/usb/peak_usb/pcan_usb_core.c:753 [inline] peak_usb_probe+0x544/0x1b20 drivers/net/can/usb/peak_usb/pcan_usb_core.c:907 usb_probe_interface+0xd19/0x1310 drivers/usb/core/driver.c:361 really_probe+0xd91/0x1f90 drivers/base/dd.c:552 driver_probe_device+0x1ba/0x510 drivers/base/dd.c:721 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:828 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:430 __device_attach+0x489/0x750 drivers/base/dd.c:894 device_initial_probe+0x4a/0x60 drivers/base/dd.c:941 bus_probe_device+0x131/0x390 drivers/base/bus.c:490 device_add+0x25b5/0x2df0 drivers/base/core.c:2201 usb_set_configuration+0x309f/0x3710
WARNING: refcount bug in find_key_to_update
Hello, syzbot found the following crash on: HEAD commit:bc88f85c kthread: make __kthread_queue_delayed_work static git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1730584b60 kernel config: https://syzkaller.appspot.com/x/.config?x=e0ac4d9b35046343 dashboard link: https://syzkaller.appspot.com/bug?extid=6455648abc28dbdd1e7f compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11c8adab60 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+6455648abc28dbdd1...@syzkaller.appspotmail.com [ cut here ] refcount_t: increment on 0; use-after-free. WARNING: CPU: 1 PID: 9064 at lib/refcount.c:156 refcount_inc_checked lib/refcount.c:156 [inline] WARNING: CPU: 1 PID: 9064 at lib/refcount.c:156 refcount_inc_checked+0x61/0x70 lib/refcount.c:154 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 9064 Comm: syz-executor.5 Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 panic+0x2e3/0x75c kernel/panic.c:221 __warn.cold+0x2f/0x35 kernel/panic.c:582 report_bug+0x289/0x300 lib/bug.c:195 fixup_bug arch/x86/kernel/traps.c:179 [inline] fixup_bug arch/x86/kernel/traps.c:174 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028 RIP: 0010:refcount_inc_checked lib/refcount.c:156 [inline] RIP: 0010:refcount_inc_checked+0x61/0x70 lib/refcount.c:154 Code: 1d 58 46 7e 06 31 ff 89 de e8 0b cb 2e fe 84 db 75 dd e8 c2 c9 2e fe 48 c7 c7 40 ad e6 87 c6 05 38 46 7e 06 01 e8 67 0c 00 fe <0f> 0b eb c1 90 90 90 90 90 90 90 90 90 90 90 55 48 89 e5 41 57 41 RSP: 0018:888081447c68 EFLAGS: 00010286 RAX: RBX: RCX: RDX: RSI: 815cb646 RDI: ed1010288f7f RBP: 888081447c78 R08: 8880a231a080 R09: ed1015d26159 R10: ed1015d26158 R11: 8880ae930ac7 R12: 8880a4518940 R13: R14: 888081447e10 R15: 8880a4518c40 __key_get include/linux/key.h:281 [inline] find_key_to_update+0x8b/0xc0 security/keys/keyring.c:1127 key_create_or_update+0x588/0xbe0 security/keys/key.c:905 __do_sys_add_key security/keys/keyctl.c:132 [inline] __se_sys_add_key security/keys/keyctl.c:72 [inline] __x64_sys_add_key+0x2bd/0x4f0 security/keys/keyctl.c:72 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x459a59 Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f22e3171c78 EFLAGS: 0246 ORIG_RAX: 00f8 RAX: ffda RBX: 0005 RCX: 00459a59 RDX: 2440 RSI: 2000 RDI: 2040 RBP: 0075bf20 R08: fffe R09: R10: 0001 R11: 0246 R12: 7f22e31726d4 R13: 004bfab8 R14: 004d1ad8 R15: Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
BUG: bad usercopy in ld_usb_read (3)
Hello, syzbot found the following crash on: HEAD commit:22be26f7 usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=1756ff7760 kernel config: https://syzkaller.appspot.com/x/.config?x=387eccb7ac68ec5 dashboard link: https://syzkaller.appspot.com/bug?extid=acee996f6938b9ded381 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+acee996f6938b9ded...@syzkaller.appspotmail.com ldusb 5-1:0.28: Read buffer overflow, 177886378725897 bytes dropped usercopy: Kernel memory exposure attempt detected from process stack (offset 0, size 2147479552)! [ cut here ] kernel BUG at mm/usercopy.c:99! invalid opcode: [#1] SMP KASAN CPU: 1 PID: 6543 Comm: syz-executor.5 Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:usercopy_abort+0xb9/0xbb mm/usercopy.c:99 Code: e8 32 51 d6 ff 49 89 d9 4d 89 e8 4c 89 e1 41 56 48 89 ee 48 c7 c7 40 d9 cd 85 ff 74 24 08 41 57 48 8b 54 24 20 e8 46 e3 c0 ff <0f> 0b e8 06 51 d6 ff e8 31 8b fd ff 8b 54 24 04 49 89 d8 4c 89 e1 RSP: 0018:8881d35f7c58 EFLAGS: 00010282 RAX: 0061 RBX: 85cdd660 RCX: RDX: RSI: 8128bcbd RDI: ed103a6bef7d RBP: 85cdd820 R08: 0061 R09: fbfff11b23be R10: fbfff11b23bd R11: 88d91def R12: 85cdda40 R13: 85cdd660 R14: 7000 R15: 85cdd660 FS: 7fb330338700() GS:8881db30() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f07cea47000 CR3: 0001cc11e000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __check_object_size mm/usercopy.c:282 [inline] __check_object_size.cold+0x91/0xbb mm/usercopy.c:256 check_object_size include/linux/thread_info.h:119 [inline] check_copy_size include/linux/thread_info.h:150 [inline] copy_to_user include/linux/uaccess.h:151 [inline] ld_usb_read+0x31a/0x760 drivers/usb/misc/ldusb.c:492 __vfs_read+0x76/0x100 fs/read_write.c:425 vfs_read+0x1ea/0x430 fs/read_write.c:461 ksys_read+0x1e8/0x250 fs/read_write.c:587 do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x459a59 Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fb330337c78 EFLAGS: 0246 ORIG_RAX: RAX: ffda RBX: 0003 RCX: 00459a59 RDX: ffad RSI: 20003200 RDI: 0004 RBP: 0075bfc8 R08: R09: R10: R11: 0246 R12: 7fb3303386d4 R13: 004c7120 R14: 004dcae8 R15: Modules linked in: ---[ end trace 0fa22c64036b6ebe ]--- RIP: 0010:usercopy_abort+0xb9/0xbb mm/usercopy.c:99 Code: e8 32 51 d6 ff 49 89 d9 4d 89 e8 4c 89 e1 41 56 48 89 ee 48 c7 c7 40 d9 cd 85 ff 74 24 08 41 57 48 8b 54 24 20 e8 46 e3 c0 ff <0f> 0b e8 06 51 d6 ff e8 31 8b fd ff 8b 54 24 04 49 89 d8 4c 89 e1 RSP: 0018:8881d35f7c58 EFLAGS: 00010282 RAX: 0061 RBX: 85cdd660 RCX: RDX: RSI: 8128bcbd RDI: ed103a6bef7d RBP: 85cdd820 R08: 0061 R09: fbfff11b23be R10: fbfff11b23bd R11: 88d91def R12: 85cdda40 R13: 85cdd660 R14: 7000 R15: 85cdd660 FS: 7fb330338700() GS:8881db30() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f07cea47000 CR3: 0001cc11e000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH] mm: Unsigned 'nr_pages' always larger than zero
On 2019/10/17 8:49, Andrew Morton wrote:
> On Wed, 16 Oct 2019 17:07:44 +0800 zhong jiang wrote:
>
--- a/mm/gup.c~a
+++ a/mm/gup.c
@@ -1450,6 +1450,7 @@ static long check_and_migrate_cma_pages(
bool drain_allow = true;
bool migrate_allow = true;
LIST_HEAD(cma_page_list);
+long ret;
check_again:
for (i = 0; i < nr_pages;) {
@@ -1511,17 +1512,18 @@ check_again:
* again migrating any new CMA pages which we failed to isolate
* earlier.
*/
-nr_pages = __get_user_pages_locked(tsk, mm, start, nr_pages,
+ret = __get_user_pages_locked(tsk, mm, start, nr_pages,
pages, vmas, NULL,
gup_flags);
-if ((nr_pages > 0) && migrate_allow) {
+nr_pages = ret;
+if (ret > 0 && migrate_allow) {
drain_allow = true;
goto check_again;
}
}
-return nr_pages;
+return ret;
}
#else
static long check_and_migrate_cma_pages(struct task_struct *tsk,
>>> +1 for this approach, please.
>>>
>>>
>>> thanks,
>> Hi, Andrew
>>
>> I didn't see the fix for the issue in the upstream. Your proposal should be
>> appiled to upstream. Could you appiled the patch or repost by me ?
> Forgotten about it ;) Please send a patch sometime?
>
> .
>
I will repost the patch as your suggestion. Thanks,
Sincerely,
zhong jiang
Re: [PATCH 2/2] hfsplus: add a check for hfs_bnode_find
On Thu, Oct 17, 2019 at 8:07 AM Ernesto A. Fernández wrote: > > Hi, > > On Wed, Oct 16, 2019 at 08:06:20PM +0800, Chuhong Yuan wrote: > > hfs_brec_update_parent misses a check for hfs_bnode_find and may miss > > the failure. > > Add a check for it like what is done in again. > > > > Signed-off-by: Chuhong Yuan > > --- > > fs/hfsplus/brec.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/fs/hfsplus/brec.c b/fs/hfsplus/brec.c > > index 1918544a7871..22bada8288c4 100644 > > --- a/fs/hfsplus/brec.c > > +++ b/fs/hfsplus/brec.c > > @@ -434,6 +434,8 @@ static int hfs_brec_update_parent(struct hfs_find_data > > *fd) > > new_node->parent = tree->root; > > } > > fd->bnode = hfs_bnode_find(tree, new_node->parent); > > + if (IS_ERR(fd->bnode)) > > + return PTR_ERR(fd->bnode); > > You shouldn't just return here, you still hold a reference to new_node. > The call to hfs_bnode_find() after the again label seems to be making a > similar mistake. > > I don't think either one can actually fail though, because the parent > nodes have all been read and hashed before, haven't they? > I find that after hfs_bnode_findhash in hfs_bnode_find, there is a test for HFS_BNODE_ERROR and may return an error. I'm not sure whether it can happen here. > > /* create index key and entry */ > > hfs_bnode_read_key(new_node, fd->search_key, 14); > > cnid = cpu_to_be32(new_node->this); > > -- > > 2.20.1 > >
Re: [PATCH] staging: sm750fb: format description of parameters the to kernel doc format
Hi Randy,
On 10/16/19 10:25 PM, Randy Dunlap wrote:
Hi,
On 10/16/19 6:18 PM, Gabriela Bittencourt wrote:
Cluster comments that describes parameters of functions and create one
single comment before the function in kernel doc format.
Good plan.
How did you test this patch?
I haven't test it. How can I do it?
Signed-off-by: Gabriela Bittencourt
---
drivers/staging/sm750fb/sm750_accel.c | 65 +++
1 file changed, 37 insertions(+), 28 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c
b/drivers/staging/sm750fb/sm750_accel.c
index dbcbbd1055da..d5564cd60f3b 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -130,20 +130,24 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
return 0;
}
-int sm750_hw_copyarea(
-struct lynx_accel *accel,
-unsigned int sBase, /* Address of source: offset in frame buffer */
-unsigned int sPitch, /* Pitch value of source surface in BYTE */
-unsigned int sx,
-unsigned int sy, /* Starting coordinate of source surface */
-unsigned int dBase, /* Address of destination: offset in frame buffer */
-unsigned int dPitch, /* Pitch value of destination surface in BYTE */
-unsigned int Bpp,/* Color depth of destination surface */
-unsigned int dx,
-unsigned int dy, /* Starting coordinate of destination surface */
-unsigned int width,
-unsigned int height, /* width and height of rectangle in pixel value */
-unsigned int rop2) /* ROP value */
+/**
Missing function name and short description.
Documentation/doc-guide/kernel-doc.rst says:
The general format of a function and function-like macro kernel-doc comment is::
/**
* function_name() - Brief description of function.
* @arg1: Describe the first argument.
* @arg2: Describe the second argument.
*One can provide multiple line descriptions
*for arguments.
*
* A longer description, with more discussion of the function function_name()
* that might be useful to those using or modifying it. Begins with an
* empty comment line, and may include additional embedded empty
* comment lines.
*
* The longer description may have multiple paragraphs.
*
* Context: Describes whether the function can sleep, what locks it takes,
* releases, or expects to be held. It can extend over multiple
* lines.
* Return: Describe the return value of function_name.
*
* The return value description can also have multiple paragraphs, and should
* be placed at the end of the comment block.
*/
+ * @sBase: Address of source: offset in frame buffer
+ * @sPitch: Pitch value of source surface in BYTE
+ * @sx, @sy: Starting coordinate of source surface
Those should be on separate lines.
+ * @dBase: Address of destination: offset in frame buffer
+ * @dPitch: Pitch value of destination surface in BYTE
+ * @Bpp: Color depth of destination surface
+ * @dx, @dy: Starting coordinate of destination surface
Ditto.
+ * @width, @height: width and height of rectangle in pixel value
+ * @rop2: ROP value
+ */
+int sm750_hw_copyarea(struct lynx_accel *accel,
+ unsigned int sBase, unsigned int sPitch,
+ unsigned int sx, unsigned int sy,
+ unsigned int dBase, unsigned int dPitch,
+ unsigned int Bpp, unsigned int dx, unsigned int dy,
+ unsigned int width, unsigned int height,
+ unsigned int rop2)
{
unsigned int nDirection, de_ctrl;
@@ -288,20 +292,25 @@ static unsigned int deGetTransparency(struct lynx_accel *accel)
return de_ctrl;
}
-int sm750_hw_imageblit(struct lynx_accel *accel,
-const char *pSrcbuf, /* pointer to start of source buffer in
system memory */
-u32 srcDelta, /* Pitch value (in bytes) of the source
buffer, +ive means top down and -ive mean button up */
-u32 startBit, /* Mono data can start at any bit in a byte,
this value should be 0 to 7 */
-u32 dBase,/* Address of destination: offset in frame
buffer */
-u32 dPitch, /* Pitch value of destination surface in BYTE */
-u32 bytePerPixel, /* Color depth of destination surface */
-u32 dx,
-u32 dy, /* Starting coordinate of destination surface */
-u32 width,
-u32 height, /* width and height of rectangle in pixel value
*/
-u32 fColor, /* Foreground color (corresponding to a 1 in the
monochrome data */
-u32 bColor, /* Background color (corresponding to a 0 in the
monochrome data */
-u32 rop2) /* ROP value */
+/**
Similar comments here...
+ * @pSrcbuf: pointer to start of source buffer in system memory
+ * @srcDelta: Pitch value (in bytes) of the source buffer, +ive means top down
+ * and -ive
Re: [PATCH v2] ftgmac100: Disable HW checksum generation on AST2500
On Fri, 2019-10-11 at 14:30 -0700, Vijay Khemka wrote:
> HW checksum generation is not working for AST2500, specially with
> IPV6
> over NCSI. All TCP packets with IPv6 get dropped. By disabling this
> it works perfectly fine with IPV6. As it works for IPV4 so enabled
> hw checksum back for IPV4.
>
> Verified with IPV6 enabled and can do ssh.
So while this probably works, I don't think this is the right
approach, at least according to the comments in skbuff.h
The driver should have handled unsupported csum via SW fallback
already in ftgmac100_prep_tx_csum()
Can you check why this didn't work for you ?
Cheers,
Ben.
> Signed-off-by: Vijay Khemka
> ---
> Changes since v1:
> Enabled IPV4 hw checksum generation as it works for IPV4.
>
> drivers/net/ethernet/faraday/ftgmac100.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/faraday/ftgmac100.c
> b/drivers/net/ethernet/faraday/ftgmac100.c
> index 030fed65393e..0255a28d2958 100644
> --- a/drivers/net/ethernet/faraday/ftgmac100.c
> +++ b/drivers/net/ethernet/faraday/ftgmac100.c
> @@ -1842,8 +1842,19 @@ static int ftgmac100_probe(struct
> platform_device *pdev)
> /* AST2400 doesn't have working HW checksum generation */
> if (np && (of_device_is_compatible(np, "aspeed,ast2400-mac")))
> netdev->hw_features &= ~NETIF_F_HW_CSUM;
> +
> + /* AST2500 doesn't have working HW checksum generation for IPV6
> + * but it works for IPV4, so disabling hw checksum and enabling
> + * it for only IPV4.
> + */
> + if (np && (of_device_is_compatible(np, "aspeed,ast2500-mac")))
> {
> + netdev->hw_features &= ~NETIF_F_HW_CSUM;
> + netdev->hw_features |= NETIF_F_IP_CSUM;
> + }
> +
> if (np && of_get_property(np, "no-hw-checksum", NULL))
> - netdev->hw_features &= ~(NETIF_F_HW_CSUM |
> NETIF_F_RXCSUM);
> + netdev->hw_features &= ~(NETIF_F_HW_CSUM |
> NETIF_F_RXCSUM
> + | NETIF_F_IP_CSUM);
> netdev->features |= netdev->hw_features;
>
> /* register network device */
[PATCH v9 5/5] kasan debug: track pages allocated for vmalloc shadow
Provide the current number of vmalloc shadow pages in
/sys/kernel/debug/kasan/vmalloc_shadow_pages.
Signed-off-by: Daniel Axtens
---
v8: rename kasan_vmalloc/shadow_pages -> kasan/vmalloc_shadow_pages
On v4 (no dynamic freeing), I saw the following approximate figures
on my test VM:
- fresh boot: 720
- after test_vmalloc: ~14000
With v5 (lazy dynamic freeing):
- boot: ~490-500
- running modprobe test_vmalloc pushes the figures up to sometimes
as high as ~14000, but they drop down to ~560 after the test ends.
I'm not sure where the extra sixty pages are from, but running the
test repeately doesn't cause the number to keep growing, so I don't
think we're leaking.
- with vmap_stack, spawning tasks pushes the figure up to ~4200, then
some clearing kicks in and drops it down to previous levels again.
---
mm/kasan/common.c | 26 ++
1 file changed, 26 insertions(+)
diff --git mm/kasan/common.c mm/kasan/common.c
index 81521d180bec..ac05038afa5a 100644
--- mm/kasan/common.c
+++ mm/kasan/common.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
@@ -750,6 +751,8 @@ core_initcall(kasan_memhotplug_init);
#endif
#ifdef CONFIG_KASAN_VMALLOC
+static u64 vmalloc_shadow_pages;
+
static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
void *unused)
{
@@ -782,6 +785,7 @@ static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned
long addr,
if (likely(pte_none(*ptep))) {
set_pte_at(_mm, addr, ptep, pte);
page = 0;
+ vmalloc_shadow_pages++;
}
spin_unlock(_mm.page_table_lock);
if (page)
@@ -836,6 +840,7 @@ static int kasan_depopulate_vmalloc_pte(pte_t *ptep,
unsigned long addr,
pte_clear(_mm, addr, ptep);
flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
free_page(page);
+ vmalloc_shadow_pages--;
}
spin_unlock(_mm.page_table_lock);
@@ -954,4 +959,25 @@ void kasan_release_vmalloc(unsigned long start, unsigned
long end,
(unsigned long)shadow_end);
}
}
+
+static __init int kasan_init_debugfs(void)
+{
+ struct dentry *root, *count;
+
+ root = debugfs_create_dir("kasan", NULL);
+ if (IS_ERR(root)) {
+ if (PTR_ERR(root) == -ENODEV)
+ return 0;
+ return PTR_ERR(root);
+ }
+
+ count = debugfs_create_u64("vmalloc_shadow_pages", 0444, root,
+ _shadow_pages);
+
+ if (IS_ERR(count))
+ return PTR_ERR(root);
+
+ return 0;
+}
+late_initcall(kasan_init_debugfs);
#endif
--
2.20.1
[PATCH v9 4/5] x86/kasan: support KASAN_VMALLOC
In the case where KASAN directly allocates memory to back vmalloc
space, don't map the early shadow page over it.
We prepopulate pgds/p4ds for the range that would otherwise be empty.
This is required to get it synced to hardware on boot, allowing the
lower levels of the page tables to be filled dynamically.
Acked-by: Dmitry Vyukov
Signed-off-by: Daniel Axtens
---
v5: fix some checkpatch CHECK warnings. There are some that remain
around lines ending with '(': I have not changed these because
it's consistent with the rest of the file and it's not easy to
see how to fix it without creating an overlong line or lots of
temporary variables.
v2: move from faulting in shadow pgds to prepopulating
---
arch/x86/Kconfig| 1 +
arch/x86/mm/kasan_init_64.c | 60 +
2 files changed, 61 insertions(+)
diff --git arch/x86/Kconfig arch/x86/Kconfig
index abe822d52167..92f5d5d5c78a 100644
--- arch/x86/Kconfig
+++ arch/x86/Kconfig
@@ -135,6 +135,7 @@ config X86
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN if X86_64
+ select HAVE_ARCH_KASAN_VMALLOC if X86_64
select HAVE_ARCH_KGDB
select HAVE_ARCH_MMAP_RND_BITS if MMU
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if MMU && COMPAT
diff --git arch/x86/mm/kasan_init_64.c arch/x86/mm/kasan_init_64.c
index 296da58f3013..8f00f462709e 100644
--- arch/x86/mm/kasan_init_64.c
+++ arch/x86/mm/kasan_init_64.c
@@ -245,6 +245,51 @@ static void __init kasan_map_early_shadow(pgd_t *pgd)
} while (pgd++, addr = next, addr != end);
}
+static void __init kasan_shallow_populate_p4ds(pgd_t *pgd,
+ unsigned long addr,
+ unsigned long end,
+ int nid)
+{
+ p4d_t *p4d;
+ unsigned long next;
+ void *p;
+
+ p4d = p4d_offset(pgd, addr);
+ do {
+ next = p4d_addr_end(addr, end);
+
+ if (p4d_none(*p4d)) {
+ p = early_alloc(PAGE_SIZE, nid, true);
+ p4d_populate(_mm, p4d, p);
+ }
+ } while (p4d++, addr = next, addr != end);
+}
+
+static void __init kasan_shallow_populate_pgds(void *start, void *end)
+{
+ unsigned long addr, next;
+ pgd_t *pgd;
+ void *p;
+ int nid = early_pfn_to_nid((unsigned long)start);
+
+ addr = (unsigned long)start;
+ pgd = pgd_offset_k(addr);
+ do {
+ next = pgd_addr_end(addr, (unsigned long)end);
+
+ if (pgd_none(*pgd)) {
+ p = early_alloc(PAGE_SIZE, nid, true);
+ pgd_populate(_mm, pgd, p);
+ }
+
+ /*
+* we need to populate p4ds to be synced when running in
+* four level mode - see sync_global_pgds_l4()
+*/
+ kasan_shallow_populate_p4ds(pgd, addr, next, nid);
+ } while (pgd++, addr = next, addr != (unsigned long)end);
+}
+
#ifdef CONFIG_KASAN_INLINE
static int kasan_die_handler(struct notifier_block *self,
unsigned long val,
@@ -352,9 +397,24 @@ void __init kasan_init(void)
shadow_cpu_entry_end = (void *)round_up(
(unsigned long)shadow_cpu_entry_end, PAGE_SIZE);
+ /*
+* If we're in full vmalloc mode, don't back vmalloc space with early
+* shadow pages. Instead, prepopulate pgds/p4ds so they are synced to
+* the global table and we can populate the lower levels on demand.
+*/
+#ifdef CONFIG_KASAN_VMALLOC
+ kasan_shallow_populate_pgds(
+ kasan_mem_to_shadow((void *)PAGE_OFFSET + MAXMEM),
+ kasan_mem_to_shadow((void *)VMALLOC_END));
+
+ kasan_populate_early_shadow(
+ kasan_mem_to_shadow((void *)VMALLOC_END + 1),
+ shadow_cpu_entry_begin);
+#else
kasan_populate_early_shadow(
kasan_mem_to_shadow((void *)PAGE_OFFSET + MAXMEM),
shadow_cpu_entry_begin);
+#endif
kasan_populate_shadow((unsigned long)shadow_cpu_entry_begin,
(unsigned long)shadow_cpu_entry_end, 0);
--
2.20.1
Re: [PATCH 1/4] KVM: VMX: rename {vmx,nested_vmx}_vcpu_setup functions
On 10/17/2019 2:09 AM, Krish Sadhukhan wrote:
On 10/15/19 6:27 PM, Xiaoyao Li wrote:
On 10/16/2019 6:05 AM, Krish Sadhukhan wrote:
On 10/15/2019 09:40 AM, Xiaoyao Li wrote:
Rename {vmx,nested_vmx}_vcpu_setup to {vmx,nested_vmx}_vmcs_setup,
to match what they really do.
No functional change.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/vmx/nested.c | 2 +-
arch/x86/kvm/vmx/nested.h | 2 +-
arch/x86/kvm/vmx/vmx.c | 9 +++--
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 5e231da00310..7935422d311f 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -5768,7 +5768,7 @@ static int vmx_set_nested_state(struct
kvm_vcpu *vcpu,
return ret;
}
-void nested_vmx_vcpu_setup(void)
+void nested_vmx_vmcs_setup(void)
{
if (enable_shadow_vmcs) {
vmcs_write64(VMREAD_BITMAP, __pa(vmx_vmread_bitmap));
diff --git a/arch/x86/kvm/vmx/nested.h b/arch/x86/kvm/vmx/nested.h
index 187d39bf0bf1..2be1ba7482c9 100644
--- a/arch/x86/kvm/vmx/nested.h
+++ b/arch/x86/kvm/vmx/nested.h
@@ -11,7 +11,7 @@ void nested_vmx_setup_ctls_msrs(struct
nested_vmx_msrs *msrs, u32 ept_caps,
bool apicv);
void nested_vmx_hardware_unsetup(void);
__init int nested_vmx_hardware_setup(int (*exit_handlers[])(struct
kvm_vcpu *));
-void nested_vmx_vcpu_setup(void);
+void nested_vmx_vmcs_setup(void);
void nested_vmx_free_vcpu(struct kvm_vcpu *vcpu);
int nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu, bool
from_vmentry);
bool nested_vmx_exit_reflected(struct kvm_vcpu *vcpu, u32
exit_reason);
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index e660e28e9ae0..58b77a882426 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -4161,15 +4161,12 @@ static void ept_set_mmio_spte_mask(void)
#define VMX_XSS_EXIT_BITMAP 0
-/*
- * Sets up the vmcs for emulated real mode.
- */
-static void vmx_vcpu_setup(struct vcpu_vmx *vmx)
+static void vmx_vmcs_setup(struct vcpu_vmx *vmx)
{
int i;
if (nested)
- nested_vmx_vcpu_setup();
+ nested_vmx_vmcs_setup();
if (cpu_has_vmx_msr_bitmap())
vmcs_write64(MSR_BITMAP, __pa(vmx->vmcs01.msr_bitmap));
@@ -6777,7 +6774,7 @@ static struct kvm_vcpu *vmx_create_vcpu(struct
kvm *kvm, unsigned int id)
cpu = get_cpu();
vmx_vcpu_load(>vcpu, cpu);
vmx->vcpu.cpu = cpu;
- vmx_vcpu_setup(vmx);
+ vmx_vmcs_setup(vmx);
vmx_vcpu_put(>vcpu);
put_cpu();
if (cpu_need_virtualize_apic_accesses(>vcpu)) {
May be we should rename vmx_vcpu_reset() to vmx_vmcs_reset() as well ?
Not really. vmx_vcpu_reset() not only resets vmcs but also the
emulated field of vmx vcpu.
It would be a better organization of the code if the resetting of the
VMCS fields were placed in a separate function.
OK, will do it in next version.
Reviewed-by: Krish Sadhukhan
[PATCH v9 0/5] kasan: support backing vmalloc space with real shadow memory
Currently, vmalloc space is backed by the early shadow page. This means that kasan is incompatible with VMAP_STACK. This series provides a mechanism to back vmalloc space with real, dynamically allocated memory. I have only wired up x86, because that's the only currently supported arch I can work with easily, but it's very easy to wire up other architectures, and it appears that there is some work-in-progress code to do this on arm64 and s390. This has been discussed before in the context of VMAP_STACK: - https://bugzilla.kernel.org/show_bug.cgi?id=202009 - https://lkml.org/lkml/2018/7/22/198 - https://lkml.org/lkml/2019/7/19/822 In terms of implementation details: Most mappings in vmalloc space are small, requiring less than a full page of shadow space. Allocating a full shadow page per mapping would therefore be wasteful. Furthermore, to ensure that different mappings use different shadow pages, mappings would have to be aligned to KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE. Instead, share backing space across multiple mappings. Allocate a backing page when a mapping in vmalloc space uses a particular page of the shadow region. This page can be shared by other vmalloc mappings later on. We hook in to the vmap infrastructure to lazily clean up unused shadow memory. v1: https://lore.kernel.org/linux-mm/20190725055503.19507-1-...@axtens.net/ v2: https://lore.kernel.org/linux-mm/20190729142108.23343-1-...@axtens.net/ Address review comments: - Patch 1: use kasan_unpoison_shadow's built-in handling of ranges that do not align to a full shadow byte - Patch 3: prepopulate pgds rather than faulting things in v3: https://lore.kernel.org/linux-mm/20190731071550.31814-1-...@axtens.net/ Address comments from Mark Rutland: - kasan_populate_vmalloc is a better name - handle concurrency correctly - various nits and cleanups - relax module alignment in KASAN_VMALLOC case v4: https://lore.kernel.org/linux-mm/20190815001636.12235-1-...@axtens.net/ Changes to patch 1 only: - Integrate Mark's rework, thanks Mark! - handle the case where kasan_populate_shadow might fail - poision shadow on free, allowing the alloc path to just unpoision memory that it uses v5: https://lore.kernel.org/linux-mm/20190830003821.10737-1-...@axtens.net/ Address comments from Christophe Leroy: - Fix some issues with my descriptions in commit messages and docs - Dynamically free unused shadow pages by hooking into the vmap book-keeping - Split out the test into a separate patch - Optional patch to track the number of pages allocated - minor checkpatch cleanups v6: https://lore.kernel.org/linux-mm/20190902112028.23773-1-...@axtens.net/ Properly guard freeing pages in patch 1, drop debugging code. v7: https://lore.kernel.org/linux-mm/20190903145536.3390-1-...@axtens.net/ Add a TLB flush on freeing, thanks Mark Rutland. Explain more clearly how I think freeing is concurrency-safe. v8: https://lore.kernel.org/linux-mm/20191001065834.8880-1-...@axtens.net/ rename kasan_vmalloc/shadow_pages to kasan/vmalloc_shadow_pages v9: address a number of review comments for patch 1. Daniel Axtens (5): kasan: support backing vmalloc space with real shadow memory kasan: add test for vmalloc fork: support VMAP_STACK with KASAN_VMALLOC x86/kasan: support KASAN_VMALLOC kasan debug: track pages allocated for vmalloc shadow Documentation/dev-tools/kasan.rst | 63 arch/Kconfig | 9 +- arch/x86/Kconfig | 1 + arch/x86/mm/kasan_init_64.c | 60 include/linux/kasan.h | 31 include/linux/moduleloader.h | 2 +- include/linux/vmalloc.h | 12 ++ kernel/fork.c | 4 + lib/Kconfig.kasan | 16 ++ lib/test_kasan.c | 26 mm/kasan/common.c | 237 ++ mm/kasan/generic_report.c | 3 + mm/kasan/kasan.h | 1 + mm/vmalloc.c | 48 +- 14 files changed, 503 insertions(+), 10 deletions(-) -- 2.20.1
[PATCH v9 1/5] kasan: support backing vmalloc space with real shadow memory
Hook into vmalloc and vmap, and dynamically allocate real shadow memory to back the mappings. Most mappings in vmalloc space are small, requiring less than a full page of shadow space. Allocating a full shadow page per mapping would therefore be wasteful. Furthermore, to ensure that different mappings use different shadow pages, mappings would have to be aligned to KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE. Instead, share backing space across multiple mappings. Allocate a backing page when a mapping in vmalloc space uses a particular page of the shadow region. This page can be shared by other vmalloc mappings later on. We hook in to the vmap infrastructure to lazily clean up unused shadow memory. To avoid the difficulties around swapping mappings around, this code expects that the part of the shadow region that covers the vmalloc space will not be covered by the early shadow page, but will be left unmapped. This will require changes in arch-specific code. This allows KASAN with VMAP_STACK, and may be helpful for architectures that do not have a separate module space (e.g. powerpc64, which I am currently working on). It also allows relaxing the module alignment back to PAGE_SIZE. Link: https://bugzilla.kernel.org/show_bug.cgi?id=202009 Acked-by: Vasily Gorbik Co-developed-by: Mark Rutland Signed-off-by: Mark Rutland [shadow rework] Signed-off-by: Daniel Axtens -- [I haven't tried to resolve the question of spurious faults. My understanding is that in order to see the issue, you'd need to: a) on CPU 0, allocate shadow memory for memory in the vmalloc or module region, where the allocation is located at a fixed address, and b) on CPU 1, access that shadow memory via the fixed address (to avoid the dependency that would otherwise require the correct ordering) If this is an issue on x86, we can fix it in the x86 enablement patch. Hopefully someone from x86land can let us know.] v2: let kasan_unpoison_shadow deal with ranges that do not use a full shadow byte. v3: relax module alignment rename to kasan_populate_vmalloc which is a much better name deal with concurrency correctly v4: Mark's rework Poision pages on vfree Handle allocation failures v5: Per Christophe Leroy, split out test and dynamically free pages. v6: Guard freeing page properly. Drop WARN_ON_ONCE(pte_none(*ptep)), on reflection it's unnecessary debugging cruft with too high a false positive rate. v7: tlb flush, thanks Mark. explain more clearly how freeing works and is concurrency-safe. v9: - Pull in Uladzislau Rezki's changes to better line up with the design of the new vmalloc implementation. Thanks Vlad. - clarify comment explaining smp_wmb() per Mark and Andrey's discussion - tighten up the allocation of backing memory so that it only happens for vmalloc or module space allocations. Thanks Andrey Ryabinin. - A TLB flush in the freeing path, thanks Mark Rutland. --- Documentation/dev-tools/kasan.rst | 63 + include/linux/kasan.h | 31 + include/linux/moduleloader.h | 2 +- include/linux/vmalloc.h | 12 ++ lib/Kconfig.kasan | 16 +++ mm/kasan/common.c | 211 ++ mm/kasan/generic_report.c | 3 + mm/kasan/kasan.h | 1 + mm/vmalloc.c | 48 ++- 9 files changed, 381 insertions(+), 6 deletions(-) diff --git Documentation/dev-tools/kasan.rst Documentation/dev-tools/kasan.rst index 525296121d89..e4d66e7c50de 100644 --- Documentation/dev-tools/kasan.rst +++ Documentation/dev-tools/kasan.rst @@ -218,3 +218,66 @@ brk handler is used to print bug reports. A potential expansion of this mode is a hardware tag-based mode, which would use hardware memory tagging support instead of compiler instrumentation and manual shadow memory manipulation. + +What memory accesses are sanitised by KASAN? + + +The kernel maps memory in a number of different parts of the address +space. This poses something of a problem for KASAN, which requires +that all addresses accessed by instrumented code have a valid shadow +region. + +The range of kernel virtual addresses is large: there is not enough +real memory to support a real shadow region for every address that +could be accessed by the kernel. + +By default +~~ + +By default, architectures only map real memory over the shadow region +for the linear mapping (and potentially other small areas). For all +other areas - such as vmalloc and vmemmap space - a single read-only +page is mapped over the shadow area. This read-only shadow page +declares all memory accesses as permitted. + +This presents a problem for modules: they do not live in the linear +mapping, but in a dedicated module space. By hooking in to the module +allocator, KASAN can temporarily map real shadow memory to cover +them. This allows
Re: [PATCH] staging: sm750fb: format description of parameters the to kernel doc format
Hi,
On 10/16/19 6:18 PM, Gabriela Bittencourt wrote:
> Cluster comments that describes parameters of functions and create one
> single comment before the function in kernel doc format.
Good plan.
How did you test this patch?
> Signed-off-by: Gabriela Bittencourt
> ---
> drivers/staging/sm750fb/sm750_accel.c | 65 +++
> 1 file changed, 37 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750_accel.c
> b/drivers/staging/sm750fb/sm750_accel.c
> index dbcbbd1055da..d5564cd60f3b 100644
> --- a/drivers/staging/sm750fb/sm750_accel.c
> +++ b/drivers/staging/sm750fb/sm750_accel.c
> @@ -130,20 +130,24 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
> return 0;
> }
>
> -int sm750_hw_copyarea(
> -struct lynx_accel *accel,
> -unsigned int sBase, /* Address of source: offset in frame buffer */
> -unsigned int sPitch, /* Pitch value of source surface in BYTE */
> -unsigned int sx,
> -unsigned int sy, /* Starting coordinate of source surface */
> -unsigned int dBase, /* Address of destination: offset in frame buffer */
> -unsigned int dPitch, /* Pitch value of destination surface in BYTE */
> -unsigned int Bpp,/* Color depth of destination surface */
> -unsigned int dx,
> -unsigned int dy, /* Starting coordinate of destination surface */
> -unsigned int width,
> -unsigned int height, /* width and height of rectangle in pixel value */
> -unsigned int rop2) /* ROP value */
> +/**
Missing function name and short description.
Documentation/doc-guide/kernel-doc.rst says:
The general format of a function and function-like macro kernel-doc comment is::
/**
* function_name() - Brief description of function.
* @arg1: Describe the first argument.
* @arg2: Describe the second argument.
*One can provide multiple line descriptions
*for arguments.
*
* A longer description, with more discussion of the function function_name()
* that might be useful to those using or modifying it. Begins with an
* empty comment line, and may include additional embedded empty
* comment lines.
*
* The longer description may have multiple paragraphs.
*
* Context: Describes whether the function can sleep, what locks it takes,
* releases, or expects to be held. It can extend over multiple
* lines.
* Return: Describe the return value of function_name.
*
* The return value description can also have multiple paragraphs, and should
* be placed at the end of the comment block.
*/
> + * @sBase: Address of source: offset in frame buffer
> + * @sPitch: Pitch value of source surface in BYTE
> + * @sx, @sy: Starting coordinate of source surface
Those should be on separate lines.
> + * @dBase: Address of destination: offset in frame buffer
> + * @dPitch: Pitch value of destination surface in BYTE
> + * @Bpp: Color depth of destination surface
> + * @dx, @dy: Starting coordinate of destination surface
Ditto.
> + * @width, @height: width and height of rectangle in pixel value
> + * @rop2: ROP value
> + */
> +int sm750_hw_copyarea(struct lynx_accel *accel,
> + unsigned int sBase, unsigned int sPitch,
> + unsigned int sx, unsigned int sy,
> + unsigned int dBase, unsigned int dPitch,
> + unsigned int Bpp, unsigned int dx, unsigned int dy,
> + unsigned int width, unsigned int height,
> + unsigned int rop2)
> {
> unsigned int nDirection, de_ctrl;
>
> @@ -288,20 +292,25 @@ static unsigned int deGetTransparency(struct lynx_accel
> *accel)
> return de_ctrl;
> }
>
> -int sm750_hw_imageblit(struct lynx_accel *accel,
> - const char *pSrcbuf, /* pointer to start of source buffer in
> system memory */
> - u32 srcDelta, /* Pitch value (in bytes) of the source
> buffer, +ive means top down and -ive mean button up */
> - u32 startBit, /* Mono data can start at any bit in a byte,
> this value should be 0 to 7 */
> - u32 dBase,/* Address of destination: offset in frame
> buffer */
> - u32 dPitch, /* Pitch value of destination surface in BYTE */
> - u32 bytePerPixel, /* Color depth of destination surface */
> - u32 dx,
> - u32 dy, /* Starting coordinate of destination surface */
> - u32 width,
> - u32 height, /* width and height of rectangle in pixel value
> */
> - u32 fColor, /* Foreground color (corresponding to a 1 in the
> monochrome data */
> - u32 bColor, /* Background color (corresponding to a 0 in the
> monochrome data */
> - u32 rop2) /* ROP value */
> +/**
Similar comments here...
> + * @pSrcbuf: pointer to start of source buffer in system memory
> + * @srcDelta: Pitch value (in bytes) of the source buffer, +ive means top
> down
> + * and -ive mean button
[PATCH v9 3/5] fork: support VMAP_STACK with KASAN_VMALLOC
Supporting VMAP_STACK with KASAN_VMALLOC is straightforward: - clear the shadow region of vmapped stacks when swapping them in - tweak Kconfig to allow VMAP_STACK to be turned on with KASAN Reviewed-by: Dmitry Vyukov Signed-off-by: Daniel Axtens --- arch/Kconfig | 9 + kernel/fork.c | 4 2 files changed, 9 insertions(+), 4 deletions(-) diff --git arch/Kconfig arch/Kconfig index 5f8a5d84dbbe..2d914990402f 100644 --- arch/Kconfig +++ arch/Kconfig @@ -843,16 +843,17 @@ config HAVE_ARCH_VMAP_STACK config VMAP_STACK default y bool "Use a virtually-mapped stack" - depends on HAVE_ARCH_VMAP_STACK && !KASAN + depends on HAVE_ARCH_VMAP_STACK + depends on !KASAN || KASAN_VMALLOC ---help--- Enable this if you want the use virtually-mapped kernel stacks with guard pages. This causes kernel stack overflows to be caught immediately rather than causing difficult-to-diagnose corruption. - This is presently incompatible with KASAN because KASAN expects - the stack to map directly to the KASAN shadow map using a formula - that is incorrect if the stack is in vmalloc space. + To use this with KASAN, the architecture must support backing + virtual mappings with real shadow memory, and KASAN_VMALLOC must + be enabled. config ARCH_OPTIONAL_KERNEL_RWX def_bool n diff --git kernel/fork.c kernel/fork.c index bcdf53125210..484ca6b0ae6c 100644 --- kernel/fork.c +++ kernel/fork.c @@ -94,6 +94,7 @@ #include #include #include +#include #include #include @@ -224,6 +225,9 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node) if (!s) continue; + /* Clear the KASAN shadow of the stack. */ + kasan_unpoison_shadow(s->addr, THREAD_SIZE); + /* Clear stale pointers from reused stack. */ memset(s->addr, 0, THREAD_SIZE); -- 2.20.1
[PATCH v9 2/5] kasan: add test for vmalloc
Test kasan vmalloc support by adding a new test to the module.
Signed-off-by: Daniel Axtens
--
v5: split out per Christophe Leroy
---
lib/test_kasan.c | 26 ++
1 file changed, 26 insertions(+)
diff --git lib/test_kasan.c lib/test_kasan.c
index 49cc4d570a40..328d33beae36 100644
--- lib/test_kasan.c
+++ lib/test_kasan.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
@@ -748,6 +749,30 @@ static noinline void __init kmalloc_double_kzfree(void)
kzfree(ptr);
}
+#ifdef CONFIG_KASAN_VMALLOC
+static noinline void __init vmalloc_oob(void)
+{
+ void *area;
+
+ pr_info("vmalloc out-of-bounds\n");
+
+ /*
+* We have to be careful not to hit the guard page.
+* The MMU will catch that and crash us.
+*/
+ area = vmalloc(3000);
+ if (!area) {
+ pr_err("Allocation failed\n");
+ return;
+ }
+
+ ((volatile char *)area)[3100];
+ vfree(area);
+}
+#else
+static void __init vmalloc_oob(void) {}
+#endif
+
static int __init kmalloc_tests_init(void)
{
/*
@@ -793,6 +818,7 @@ static int __init kmalloc_tests_init(void)
kasan_strings();
kasan_bitops();
kmalloc_double_kzfree();
+ vmalloc_oob();
kasan_restore_multi_shot(multishot);
--
2.20.1
RE: [PATCH] rtlwifi: Fix potential overflow on P2P code
> -Original Message-
> From: linux-wireless-ow...@vger.kernel.org
> [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf
> Of Laura Abbott
> Sent: Thursday, October 17, 2019 4:57 AM
> To: Pkshih; Kalle Valo
> Cc: Laura Abbott; David S. Miller; linux-wirel...@vger.kernel.org;
> net...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Nicolas Waisman
> Subject: [PATCH] rtlwifi: Fix potential overflow on P2P code
>
> Nicolas Waisman noticed that even though noa_len is checked for
> a compatible length it's still possible to overrun the buffers
> of p2pinfo since there's no check on the upper bound of noa_num.
> Bounds check noa_num against P2P_MAX_NOA_NUM.
>
> Reported-by: Nicolas Waisman
> Signed-off-by: Laura Abbott
> ---
> Compile tested only as this was reported to the security list.
> ---
> drivers/net/wireless/realtek/rtlwifi/ps.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/ps.c
> b/drivers/net/wireless/realtek/rtlwifi/ps.c
> index 70f04c2f5b17..c5cff598383d 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/ps.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
> @@ -754,6 +754,13 @@ static void rtl_p2p_noa_ie(struct ieee80211_hw *hw, void
> *data,
> return;
> } else {
> noa_num = (noa_len - 2) / 13;
> + if (noa_num > P2P_MAX_NOA_NUM) {
> + RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD,
> + "P2P notice of absence:
> invalid noa_num.%d\n",
> + noa_num);
> + return;
As the discussion at , I think it'd be better to use
the min between noa_num and P2P_MAX_NOA_NUM, and fall through the code instead
of return. Because ignore all NoA isn't better than apply two of them.
> + }
> +
> }
> noa_index = ie[3];
> if (rtlpriv->psc.p2p_ps_info.p2p_ps_mode ==
> @@ -848,6 +855,13 @@ static void rtl_p2p_action_ie(struct ieee80211_hw *hw,
> void *data,
> return;
> } else {
> noa_num = (noa_len - 2) / 13;
> + if (noa_num > P2P_MAX_NOA_NUM) {
> + RT_TRACE(rtlpriv, COMP_FW, DBG_LOUD,
> + "P2P notice of absence:
> invalid noa_len.%d\n",
> + noa_len);
> + return;
> +
> + }
> }
> noa_index = ie[3];
> if (rtlpriv->psc.p2p_ps_info.p2p_ps_mode ==
> --
> 2.21.0
Re: [PATCH v9 09/17] x86/split_lock: Handle #AC exception for split lock
On 10/17/2019 1:42 AM, Sean Christopherson wrote: On Wed, Oct 16, 2019 at 09:23:37AM -0700, Sean Christopherson wrote: On Wed, Oct 16, 2019 at 05:43:53PM +0200, Paolo Bonzini wrote: On 16/10/19 17:41, Sean Christopherson wrote: On Wed, Oct 16, 2019 at 04:08:14PM +0200, Paolo Bonzini wrote: SIGBUS (actually a new KVM_EXIT_INTERNAL_ERROR result from KVM_RUN is better, but that's the idea) is for when you're debugging guests. Global disable (or alternatively, disable SMT) is for production use. Alternatively, for guests without split-lock #AC enabled, what if KVM were to emulate the faulting instruction with split-lock detection temporarily disabled? Yes we can get fancy, but remember that KVM is not yet supporting emulation of locked instructions. Adding it is possible but shouldn't be in the critical path for the whole feature. Ah, didn't realize that. I'm surprised emulating all locks with cmpxchg doesn't cause problems (or am I misreading the code?). Assuming I'm reading the code correctly, the #AC path could kick all other vCPUS on emulation failure and then retry emulation to "guarantee" success. Though that's starting to build quite the house of cards. Ugh, doesn't the existing emulation behavior create another KVM issue? KVM uses a locked cmpxchg in emulator_cmpxchg_emulated() and the address is guest controlled, e.g. a guest could coerce the host into disabling split-lock detection via the host's #AC handler by triggering emulation and inducing an #AC in the emulator. Exactly right. I have tested with force_emulation_prefix. It did go into the #AC handler and disable the split-lock detection in host. However, without force_emulation_prefix enabled, I'm not sure whether malicious guest can create the case causing the emulation with a lock prefix and going to the emulator_cmpxchg_emulated(). I found it impossible without force_emulation_prefix enabled and I'm not familiar with emulation at all. If I missed something, please let me know. How would you disable split-lock detection temporarily? Just tweak MSR_TEST_CTRL for the time of running the one instruction, and cross fingers that the sibling doesn't notice? Tweak MSR_TEST_CTRL, with logic to handle the scenario where split-lock detection is globally disable during emulation (so KVM doesn't inadvertantly re-enable it). There isn't much for the sibling to notice. The kernel would temporarily allow split-locks on the sibling, but that's a performance issue and isn't directly fatal. A missed #AC in the host kernel would only delay the inevitable global disabling of split-lock. A missed #AC in userspace would again just delay the inevitable SIGBUS.
[PATCH] staging: sm750fb: format description of parameters the to kernel doc format
Cluster comments that describes parameters of functions and create one
single comment before the function in kernel doc format.
Signed-off-by: Gabriela Bittencourt
---
drivers/staging/sm750fb/sm750_accel.c | 65 +++
1 file changed, 37 insertions(+), 28 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c
b/drivers/staging/sm750fb/sm750_accel.c
index dbcbbd1055da..d5564cd60f3b 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -130,20 +130,24 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
return 0;
}
-int sm750_hw_copyarea(
-struct lynx_accel *accel,
-unsigned int sBase, /* Address of source: offset in frame buffer */
-unsigned int sPitch, /* Pitch value of source surface in BYTE */
-unsigned int sx,
-unsigned int sy, /* Starting coordinate of source surface */
-unsigned int dBase, /* Address of destination: offset in frame buffer */
-unsigned int dPitch, /* Pitch value of destination surface in BYTE */
-unsigned int Bpp,/* Color depth of destination surface */
-unsigned int dx,
-unsigned int dy, /* Starting coordinate of destination surface */
-unsigned int width,
-unsigned int height, /* width and height of rectangle in pixel value */
-unsigned int rop2) /* ROP value */
+/**
+ * @sBase: Address of source: offset in frame buffer
+ * @sPitch: Pitch value of source surface in BYTE
+ * @sx, @sy: Starting coordinate of source surface
+ * @dBase: Address of destination: offset in frame buffer
+ * @dPitch: Pitch value of destination surface in BYTE
+ * @Bpp: Color depth of destination surface
+ * @dx, @dy: Starting coordinate of destination surface
+ * @width, @height: width and height of rectangle in pixel value
+ * @rop2: ROP value
+ */
+int sm750_hw_copyarea(struct lynx_accel *accel,
+ unsigned int sBase, unsigned int sPitch,
+ unsigned int sx, unsigned int sy,
+ unsigned int dBase, unsigned int dPitch,
+ unsigned int Bpp, unsigned int dx, unsigned int dy,
+ unsigned int width, unsigned int height,
+ unsigned int rop2)
{
unsigned int nDirection, de_ctrl;
@@ -288,20 +292,25 @@ static unsigned int deGetTransparency(struct lynx_accel
*accel)
return de_ctrl;
}
-int sm750_hw_imageblit(struct lynx_accel *accel,
-const char *pSrcbuf, /* pointer to start of source buffer in
system memory */
-u32 srcDelta, /* Pitch value (in bytes) of the source
buffer, +ive means top down and -ive mean button up */
-u32 startBit, /* Mono data can start at any bit in a byte,
this value should be 0 to 7 */
-u32 dBase,/* Address of destination: offset in frame
buffer */
-u32 dPitch, /* Pitch value of destination surface in BYTE */
-u32 bytePerPixel, /* Color depth of destination surface */
-u32 dx,
-u32 dy, /* Starting coordinate of destination surface */
-u32 width,
-u32 height, /* width and height of rectangle in pixel value
*/
-u32 fColor, /* Foreground color (corresponding to a 1 in the
monochrome data */
-u32 bColor, /* Background color (corresponding to a 0 in the
monochrome data */
-u32 rop2) /* ROP value */
+/**
+ * @pSrcbuf: pointer to start of source buffer in system memory
+ * @srcDelta: Pitch value (in bytes) of the source buffer, +ive means top down
+ * and -ive mean button up
+ * @startBit: Mono data can start at any bit in a byte, this value should be
+ * 0 to 7
+ * @dBase: Address of destination: offset in frame buffer
+ * @dPitch: Pitch value of destination surface in BYTE
+ * @bytePerPixel: Color depth of destination surface
+ * @dx, @dy: Starting coordinate of destination surface
+ * @width, @height: width and height of rectangle in pixel value
+ * @fColor: Foreground color (corresponding to a 1 in the monochrome data
+ * @bColor: Background color (corresponding to a 0 in the monochrome data
+ * @rop2: ROP value
+ */
+int sm750_hw_imageblit(struct lynx_accel *accel, const char *pSrcbuf,
+ u32 srcDelta, u32 startBit, u32 dBase, u32 dPitch,
+ u32 bytePerPixel, u32 dx, u32 dy, u32 width,
+ u32 height, u32 fColor, u32 bColor, u32 rop2)
{
unsigned int ulBytesPerScan;
unsigned int ul4BytesPerScan;
--
2.20.1
Re: [PATCH net-next 00/12] net: hns3: add some bugfixes and optimizations
On 2019/10/17 1:50, David Miller wrote: From: Jakub Kicinski Date: Wed, 16 Oct 2019 10:19:43 -0700 On Wed, 16 Oct 2019 15:16:59 +0800, Huazhong Tan wrote: This patch-set includes some bugfixes and code optimizations for the HNS3 ethernet controller driver. The code LGTM, mostly, but it certainly seems like patches 2, 3 and 4 should be a separate series targeting the net tree :( Agreed, there are legitimate bug fixes. I have to say that I see this happening a lot, hns3 bug fixes targetting net-next in a larger series of cleanups and other kinds of changes. Please handle this delegation properly. Send bug fixes as a series targetting 'net', and send everything else targetting 'net-next'. ok, thanks. .
Re: [PATCH net-next 00/12] net: hns3: add some bugfixes and optimizations
On 2019/10/17 1:19, Jakub Kicinski wrote: On Wed, 16 Oct 2019 15:16:59 +0800, Huazhong Tan wrote: This patch-set includes some bugfixes and code optimizations for the HNS3 ethernet controller driver. The code LGTM, mostly, but it certainly seems like patches 2, 3 and 4 should be a separate series targeting the net tree :( ok, I will pick out the bugfix and upstream to net tree firstly. Thanks.
Re: [PATCH net-next 11/12] net: hns3: do not allocate linear data for fraglist skb
On 2019/10/17 1:18, Jakub Kicinski wrote:
On Wed, 16 Oct 2019 15:17:10 +0800, Huazhong Tan wrote:
From: Yunsheng Lin
Currently, napi_alloc_skb() is used to allocate skb for fraglist
when the head skb is not enough to hold the remaining data, and
the remaining data is added to the frags part of the fraglist skb,
leaving the linear part unused.
So this patch passes length of 0 to allocate fraglist skb with
zero size of linear data.
Fixes: 81ae0e0491f3 ("net: hns3: Add skb chain when num of RX buf exceeds
MAX_SKB_FRAGS")
Signed-off-by: Yunsheng Lin
Signed-off-by: Huazhong Tan
Is this really a fix? I just wastes memory, right?
It is a minor optimizations. This fix tag is a mistake.
Thanks.
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 6172eb2..14111af 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2866,8 +2866,7 @@ static int hns3_add_frag(struct hns3_enet_ring *ring,
struct hns3_desc *desc,
return -ENXIO;
if (unlikely(ring->frag_num >= MAX_SKB_FRAGS)) {
- new_skb = napi_alloc_skb(>tqp_vector->napi,
-HNS3_RX_HEAD_SIZE);
+ new_skb = napi_alloc_skb(>tqp_vector->napi, 0);
if (unlikely(!new_skb)) {
hns3_rl_err(ring_to_netdev(ring),
"alloc rx fraglist skb fail\n");
.
Re: [PATCH V2] mm/page_alloc: Add alloc_contig_pages()
On 10/16/19 4:02 AM, Anshuman Khandual wrote: > HugeTLB helper alloc_gigantic_page() implements fairly generic allocation > method where it scans over various zones looking for a large contiguous pfn > range before trying to allocate it with alloc_contig_range(). Other than > deriving the requested order from 'struct hstate', there is nothing HugeTLB > specific in there. This can be made available for general use to allocate > contiguous memory which could not have been allocated through the buddy > allocator. > > alloc_gigantic_page() has been split carving out actual allocation method > which is then made available via new alloc_contig_pages() helper wrapped > under CONFIG_CONTIG_ALLOC. All references to 'gigantic' have been replaced > with more generic term 'contig'. Allocated pages here should be freed with > free_contig_range() or by calling __free_page() on each allocated page. I had a 'test harness' used when previously working on such an interface. It simply provides a user interface to call the allocator with random values for nr_pages. Several tasks are then started doing random allocations in parallel. The new interface is pretty straight forward, but the idea was to stress the underlying code. In fact, it did identify issues with isolation which were corrected. I exercised this new interface in the same way and am happy to report that no issues were detected. -- Mike Kravetz
