Re: [PATCH v6 2/6] tracing: Rework synthetic event command parsing

[Tom Zanussi]

On Fri, 2021-01-22 at 22:16 +0900, Masami Hiramatsu wrote:
> On Thu, 21 Jan 2021 11:01:05 -0600
> Tom Zanussi  wrote:
> 
> > Now that command parsing has been delegated to the create functions
> > and we're no longer constrained by argv_split(), we can modify the
> > synthetic event command parser to better match the higher-level
> > structure of the synthetic event commands, which is basically an
> > event
> > name followed by a set of semicolon-separated fields.
> > 
> > Since we're also now passed the raw command, we can also save it
> > directly and can get rid of save_cmdstr().
> > 
> 
> This looks good to me.
> 
> Reviewed-by: Masami Hiramatsu 
> 
> Thank you,
> 

Thanks, Masami.

Tom

> > Signed-off-by: Tom Zanussi 
> > ---
> >  kernel/trace/trace_events_synth.c | 198 +++---
> > 
> >  1 file changed, 98 insertions(+), 100 deletions(-)
> > 
> > diff --git a/kernel/trace/trace_events_synth.c
> > b/kernel/trace/trace_events_synth.c
> > index b2588a5650c9..a79c17b97add 100644
> > --- a/kernel/trace/trace_events_synth.c
> > +++ b/kernel/trace/trace_events_synth.c
> > @@ -48,7 +48,7 @@ static int errpos(const char *str)
> > return err_pos(last_cmd, str);
> >  }
> >  
> > -static void last_cmd_set(char *str)
> > +static void last_cmd_set(const char *str)
> >  {
> > if (!str)
> > return;
> > @@ -579,18 +579,14 @@ static void free_synth_field(struct
> > synth_field *field)
> > kfree(field);
> >  }
> >  
> > -static struct synth_field *parse_synth_field(int argc, const char
> > **argv,
> > -int *consumed)
> > +static struct synth_field *parse_synth_field(int argc, char
> > **argv)
> >  {
> > -   struct synth_field *field;
> > const char *prefix = NULL, *field_type = argv[0], *field_name,
> > *array;
> > -   int len, ret = -ENOMEM;
> > +   int len, consumed, ret = -ENOMEM;
> > +   struct synth_field *field;
> > struct seq_buf s;
> > ssize_t size;
> >  
> > -   if (field_type[0] == ';')
> > -   field_type++;
> > -
> > if (!strcmp(field_type, "unsigned")) {
> > if (argc < 3) {
> > synth_err(SYNTH_ERR_INCOMPLETE_TYPE,
> > errpos(field_type));
> > @@ -599,10 +595,20 @@ static struct synth_field
> > *parse_synth_field(int argc, const char **argv,
> > prefix = "unsigned ";
> > field_type = argv[1];
> > field_name = argv[2];
> > -   *consumed = 3;
> > +   consumed = 3;
> > } else {
> > field_name = argv[1];
> > -   *consumed = 2;
> > +   consumed = 2;
> > +   }
> > +
> > +   if (consumed < argc) {
> > +   synth_err(SYNTH_ERR_INVALID_FIELD, errpos(field_type));
> > +   return ERR_PTR(-EINVAL);
> > +   }
> > +
> > +   if (!field_name) {
> > +   synth_err(SYNTH_ERR_INVALID_FIELD, errpos(field_type));
> > +   return ERR_PTR(-EINVAL);
> > }
> >  
> > field = kzalloc(sizeof(*field), GFP_KERNEL);
> > @@ -613,8 +619,6 @@ static struct synth_field
> > *parse_synth_field(int argc, const char **argv,
> > array = strchr(field_name, '[');
> > if (array)
> > len -= strlen(array);
> > -   else if (field_name[len - 1] == ';')
> > -   len--;
> >  
> > field->name = kmemdup_nul(field_name, len, GFP_KERNEL);
> > if (!field->name)
> > @@ -626,8 +630,6 @@ static struct synth_field
> > *parse_synth_field(int argc, const char **argv,
> > goto free;
> > }
> >  
> > -   if (field_type[0] == ';')
> > -   field_type++;
> > len = strlen(field_type) + 1;
> >  
> > if (array)
> > @@ -644,11 +646,8 @@ static struct synth_field
> > *parse_synth_field(int argc, const char **argv,
> > if (prefix)
> > seq_buf_puts(&s, prefix);
> > seq_buf_puts(&s, field_type);
> > -   if (array) {
> > +   if (array)
> > seq_buf_puts(&s, array);
> > -   if (s.buffer[s.len - 1] == ';')
> > -   s.len--;
> > -   }
> > if (WARN_ON_ONCE(!seq_buf_buffer_left(&s)))
> > goto free;
> >  
> > @@ -1160,46 +1159,12 @@ int synth_event_gen_cmd_array_start(struct
> > dynevent_cmd *cmd, const char *name,
> >  }
> >  EXPORT_SYMBOL_GPL(synth_event_gen_cmd_array_start);
> >  
> > -static int save_cmdstr(int argc, const char *name, const char
> > **argv)
> > -{
> > -   struct seq_buf s;
> > -   char *buf;
> > -   int i;
> > -
> > -   buf = kzalloc(MAX_DYNEVENT_CMD_LEN, GFP_KERNEL);
> > -   if (!buf)
> > -   return -ENOMEM;
> > -
> > -   seq_buf_init(&s, buf, MAX_DYNEVENT_CMD_LEN);
> > -
> > -   seq_buf_puts(&s, name);
> > -
> > -   for (i = 0; i < argc; i++) {
> > -   seq_buf_putc(&s, ' ');
> > -   seq_buf_puts(&s, argv[i]);
> > -   }
> > -
> > -   if (!seq_buf_buffer_left(&s)) {
> > -   synth_err(SYNTH_ERR_CMD_TOO_LONG, 0);
> > -   kfree(buf);
> > -   return -EINVAL;
> > -   }
> > -   buf[s.len] = 0;
> > -   last_cmd_set(buf);
> > -
> > -  

[PATCH v4 0/2] net: sfp: add support for GPON RTL8672/RTL9601C and Ubiquiti U-Fiber

[Pali Rohár]

This is fourth version of patches which add workarounds for
RTL8672/RTL9601C EEPROMs and Ubiquiti U-Fiber Instant SFP.

The only change since third version is modification of commit messages.

Pali Rohár (2):
  net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips
  net: sfp: add mode quirk for GPON module Ubiquiti U-Fiber Instant

 drivers/net/phy/sfp-bus.c |  15 +
 drivers/net/phy/sfp.c | 117 ++
 2 files changed, 97 insertions(+), 35 deletions(-)

-- 
2.20.1

[PATCH v4 1/2] net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips

[Pali Rohár]

The workaround for VSOL V2801F brand based GPON SFP modules added in commit
0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0
workaround") works only for IDs added explicitly to the list. Since there
are rebranded modules where OEM vendors put different strings into the
vendor name field, we cannot base workaround on IDs only.

Moreover the issue which the above mentioned commit tried to work around is
generic not only to VSOL based modules, but rather to all GPON modules
based on Realtek RTL8672 and RTL9601C chips.

These include at least the following GPON modules:
* V-SOL V2801F
* C-Data FD511GX-RM0
* OPTON GP801R
* BAUDCOM BD-1234-SFM
* CPGOS03-0490 v2.0
* Ubiquiti U-Fiber Instant
* EXOT EGS1

These Realtek chips have broken EEPROM emulator which for N-byte read
operation returns just the first byte of EEPROM data, followed by N-1
zeros.

Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules
with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM
reading operation.

Function sfp_i2c_read() now always uses single byte reading when it is
required and when function sfp_hwmon_probe() detects single byte access,
it disables registration of hwmon device, because in this case we cannot
reliably and atomically read 2 bytes as is required by the standard for
retrieving values from diagnostic area.

(These Realtek chips are broken in a way that violates SFP standards for
diagnostic interface. Kernel in this case simply cannot do anything less
of skipping registration of the hwmon interface.)

This patch fixes reading of EEPROM content from SFP modules based on
Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays
broken and cannot be fixed.

Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 
workaround")
Co-developed-by: Russell King 
Signed-off-by: Russell King 
Signed-off-by: Pali Rohár 

---
Changes in v4:
* Rewritten the commit message by Marek's suggestion

Changes in v3:
* Do not break longer info messages
* Do not read memory after the end of buffer in sfp_id_needs_byte_io()
* Add comments for default i2c_block_size and Nokia 3FE46541AA module

Changes in v2:
* Add explanation why also for second address is used one byte read op
* Skip hwmon registration when eeprom does not support atomic 16bit read op
---
 drivers/net/phy/sfp.c | 100 --
 1 file changed, 67 insertions(+), 33 deletions(-)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 91d74c1a920a..f2b5e467a800 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -336,19 +336,11 @@ static int sfp_i2c_read(struct sfp *sfp, bool a2, u8 
dev_addr, void *buf,
size_t len)
 {
struct i2c_msg msgs[2];
-   size_t block_size;
+   u8 bus_addr = a2 ? 0x51 : 0x50;
+   size_t block_size = sfp->i2c_block_size;
size_t this_len;
-   u8 bus_addr;
int ret;
 
-   if (a2) {
-   block_size = 16;
-   bus_addr = 0x51;
-   } else {
-   block_size = sfp->i2c_block_size;
-   bus_addr = 0x50;
-   }
-
msgs[0].addr = bus_addr;
msgs[0].flags = 0;
msgs[0].len = 1;
@@ -1282,6 +1274,20 @@ static void sfp_hwmon_probe(struct work_struct *work)
struct sfp *sfp = container_of(work, struct sfp, hwmon_probe.work);
int err, i;
 
+   /* hwmon interface needs to access 16bit registers in atomic way to
+* guarantee coherency of the diagnostic monitoring data. If it is not
+* possible to guarantee coherency because EEPROM is broken in such way
+* that does not support atomic 16bit read operation then we have to
+* skip registration of hwmon device.
+*/
+   if (sfp->i2c_block_size < 2) {
+   dev_info(sfp->dev,
+"skipping hwmon device registration due to broken 
EEPROM\n");
+   dev_info(sfp->dev,
+"diagnostic EEPROM area cannot be read atomically to 
guarantee data coherency\n");
+   return;
+   }
+
err = sfp_read(sfp, true, 0, &sfp->diag, sizeof(sfp->diag));
if (err < 0) {
if (sfp->hwmon_tries--) {
@@ -1642,26 +1648,30 @@ static int sfp_sm_mod_hpower(struct sfp *sfp, bool 
enable)
return 0;
 }
 
-/* Some modules (Nokia 3FE46541AA) lock up if byte 0x51 is read as a
- * single read. Switch back to reading 16 byte blocks unless we have
- * a CarlitoxxPro module (rebranded VSOL V2801F). Even more annoyingly,
- * some VSOL V2801F have the vendor name changed to OEM.
+/* GPON modules based on Realtek RTL8672 and RTL9601C chips (e.g. V-SOL
+ * V2801F, CarlitoxxPro CPGOS03-0490, Ubiquiti U-Fiber Instant, ...) do
+ * not support multibyte reads from the EEPROM. Each multi-byte read
+ * operation returns just one byte of EEPROM followed by zeros. There is
+ * no way to identify which modules are using

[PATCH] watch_queue: rectify kernel-doc for init_watch()

[Lukas Bulwahn]

The command './scripts/kernel-doc -none kernel/watch_queue.c'
reported a mismatch in the kernel-doc of init_watch().

Rectify the kernel-doc, such that no issues remain for watch_queue.c.

Signed-off-by: Lukas Bulwahn 
---
applies cleanly on v5.11-rc5 and next-20210122

David, please pick this minor kernel-doc fixup.

 kernel/watch_queue.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/watch_queue.c b/kernel/watch_queue.c
index 0ef8f65bd2d7..9c9eb20dd2c5 100644
--- a/kernel/watch_queue.c
+++ b/kernel/watch_queue.c
@@ -413,7 +413,7 @@ static void put_watch(struct watch *watch)
 }
 
 /**
- * init_watch_queue - Initialise a watch
+ * init_watch - Initialise a watch
  * @watch: The watch to initialise.
  * @wqueue: The queue to assign.
  *
-- 
2.17.1

Re: [PATCH 1/3] kvfree_rcu: Allocate a page for a single argument

[Michal Hocko]

On Mon 25-01-21 15:31:50, Uladzislau Rezki wrote:
> > On Wed 20-01-21 17:21:46, Uladzislau Rezki (Sony) wrote:
> > > For a single argument we can directly request a page from a caller
> > > context when a "carry page block" is run out of free spots. Instead
> > > of hitting a slow path we can request an extra page by demand and
> > > proceed with a fast path.
> > > 
> > > A single-argument kvfree_rcu() must be invoked in sleepable contexts,
> > > and that its fallback is the relatively high latency synchronize_rcu().
> > > Single-argument kvfree_rcu() therefore uses GFP_KERNEL|__GFP_RETRY_MAYFAIL
> > > to allow limited sleeping within the memory allocator.
> > 
> > __GFP_RETRY_MAYFAIL can be quite heavy. It is effectively the most heavy
> > way to allocate without triggering the OOM killer. Is this really what
> > you need/want? Is __GFP_NORETRY too weak?
> > 
> Hm... We agreed to proceed with limited lightwait memory direct reclaim.
> Johannes Weiner proposed to go with __GFP_NORETRY flag as a starting
> point: https://www.spinics.net/lists/rcu/msg02856.html
> 
> 
> So I'm inclined to suggest __GFP_NORETRY as a starting point, and make
> further decisions based on instrumentation of the success rates of
> these opportunistic allocations.
> 

I completely agree with Johannes here.

> but for some reason, i can't find a tail or head of it, we introduced
> __GFP_RETRY_MAYFAIL what is a heavy one from a time consuming point of view.
> What we would like to avoid.

Not that I object to this use but I think it would be much better to use
it based on actual data. Going along with it right away might become a
future burden to make any changes in this aspect later on due to lack of 
exact reasoning. General rule of thumb for __GFP_RETRY_MAYFAIL is really
try as hard as it can get without being really disruptive (like OOM
killing something). And your wording didn't really give me that
impression.

-- 
Michal Hocko
SUSE Labs

[PATCH] regulator: pf8x00: set ramp_delay for bucks

[Christoph Fritz]

This patch sets ramp_delay for bucks to the max value given by the
datasheet.

Signed-off-by: Christoph Fritz 
Reviewed-by: Adrien Grassein 
---
 drivers/regulator/pf8x00-regulator.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/regulator/pf8x00-regulator.c 
b/drivers/regulator/pf8x00-regulator.c
index 1e5582d73405..edf5c88bf43e 100644
--- a/drivers/regulator/pf8x00-regulator.c
+++ b/drivers/regulator/pf8x00-regulator.c
@@ -351,6 +351,7 @@ static const struct regulator_ops pf8x00_vsnvs_ops = {
.type = REGULATOR_VOLTAGE,  \
.id = PF8X00_BUCK ## _id,   \
.owner = THIS_MODULE,   \
+   .ramp_delay = 19000,\
.linear_ranges = pf8x00_sw1_to_6_voltages, \
.n_linear_ranges = \
ARRAY_SIZE(pf8x00_sw1_to_6_voltages), \
@@ -381,6 +382,7 @@ static const struct regulator_ops pf8x00_vsnvs_ops = {
.type = REGULATOR_VOLTAGE,  \
.id = PF8X00_BUCK7, \
.owner = THIS_MODULE,   \
+   .ramp_delay = 19000,\
.volt_table = voltages, \
.vsel_reg = (base) + SW_RUN_VOLT,   \
.vsel_mask = 0xff,  \
-- 
2.29.2

Re: linux-next: manual merge of the bpf-next tree with the net-next tree

[Stanislav Fomichev]

Thanks, the merge resolution looks good to me!

On Sun, Jan 24, 2021 at 4:12 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
>   net/ipv4/tcp.c
>
> between commit:
>
>   7eeba1706eba ("tcp: Add receive timestamp support for receive zerocopy.")
>
> from the net-next tree and commit:
>
>   9cacf81f8161 ("bpf: Remove extra lock_sock for TCP_ZEROCOPY_RECEIVE")
>
> from the bpf-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc net/ipv4/tcp.c
> index e1a17c6b473c,26aa923cf522..
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@@ -4160,18 -4098,13 +4160,20 @@@ static int do_tcp_getsockopt(struct soc
> if (copy_from_user(&zc, optval, len))
> return -EFAULT;
> lock_sock(sk);
>  -  err = tcp_zerocopy_receive(sk, &zc);
>  +  err = tcp_zerocopy_receive(sk, &zc, &tss);
> +   err = BPF_CGROUP_RUN_PROG_GETSOCKOPT_KERN(sk, level, optname,
> + &zc, &len, err);
> release_sock(sk);
>  -  if (len >= offsetofend(struct tcp_zerocopy_receive, err))
>  -  goto zerocopy_rcv_sk_err;
>  +  if (len >= offsetofend(struct tcp_zerocopy_receive, 
> msg_flags))
>  +  goto zerocopy_rcv_cmsg;
> switch (len) {
>  +  case offsetofend(struct tcp_zerocopy_receive, msg_flags):
>  +  goto zerocopy_rcv_cmsg;
>  +  case offsetofend(struct tcp_zerocopy_receive, msg_controllen):
>  +  case offsetofend(struct tcp_zerocopy_receive, msg_control):
>  +  case offsetofend(struct tcp_zerocopy_receive, flags):
>  +  case offsetofend(struct tcp_zerocopy_receive, copybuf_len):
>  +  case offsetofend(struct tcp_zerocopy_receive, 
> copybuf_address):
> case offsetofend(struct tcp_zerocopy_receive, err):
> goto zerocopy_rcv_sk_err;
> case offsetofend(struct tcp_zerocopy_receive, inq):

Re: [PATCH] ACPI / device_sysfs: Prefer "compatible" modalias

[Rafael J. Wysocki]

On Fri, Jan 22, 2021 at 2:06 PM Greg Kroah-Hartman
 wrote:
>
> On Fri, Jan 22, 2021 at 08:53:02PM +0800, Kai-Heng Feng wrote:
> > Commit 8765c5ba1949 ("ACPI / scan: Rework modalias creation when
> > "compatible" is present") may create two "MODALIAS=" in uevent file if
> > conditions are met.
> >
> > This breaks systemd-udevd, which assumes each "key" in uevent file is
> > unique. The internal implementation of systemd-udevd overwrites the
> > first MODALIAS with the second one, so its kmod rule doesn't load driver
> > for the first MODALIAS.
> >
> > So if both ACPI modalias and OF modalias are present, use the latter
> > one to ensure there's only one MODALIAS.
> >
> > Reference: https://github.com/systemd/systemd/pull/18163
> > Cc: AceLan Kao 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Greg Kroah-Hartman 
> > Cc: Andy Shevchenko 
> > Suggested-by: Mika Westerberg 
> > Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when 
> > "compatible" is present")
> > Signed-off-by: Kai-Heng Feng 
> > ---
> >  drivers/acpi/device_sysfs.c | 20 ++--
> >  1 file changed, 6 insertions(+), 14 deletions(-)
>
> Thanks for fixing this up!
>
> Reviewed-by: Greg Kroah-Hartman 

Applied as 5.11-rc material with some minor edits in the subject and
changelog and with the tags.

Thanks everyone!

Re: [PATCH] mm/filemap: Adding missing mem_cgroup_uncharge() to __add_to_page_cache_locked()

[Michal Hocko]

On Mon 25-01-21 10:57:54, Waiman Long wrote:
> On 1/25/21 4:28 AM, Michal Hocko wrote:
> > On Sun 24-01-21 23:24:41, Waiman Long wrote:
> > > The commit 3fea5a499d57 ("mm: memcontrol: convert page
> > > cache to a new mem_cgroup_charge() API") introduced a bug in
> > > __add_to_page_cache_locked() causing the following splat:
> > > 
> > >   [ 1570.068330] page dumped because: VM_BUG_ON_PAGE(page_memcg(page))
> > >   [ 1570.068333] pages's memcg:8889a4116000
> > >   [ 1570.068343] [ cut here ]
> > >   [ 1570.068346] kernel BUG at mm/memcontrol.c:2924!
> > >   [ 1570.068355] invalid opcode:  [#1] SMP KASAN PTI
> > >   [ 1570.068359] CPU: 35 PID: 12345 Comm: cat Tainted: G S  W I   
> > > 5.11.0-rc4-debug+ #1
> > >   [ 1570.068363] Hardware name: HP HP Z8 G4 Workstation/81C7, BIOS P60 
> > > v01.25 12/06/2017
> > >   [ 1570.068365] RIP: 0010:commit_charge+0xf4/0x130
> > > :
> > >   [ 1570.068375] RSP: 0018:8881b38d70e8 EFLAGS: 00010286
> > >   [ 1570.068379] RAX:  RBX: ea00260ddd00 RCX: 
> > > 0027
> > >   [ 1570.068382] RDX:  RSI: 0004 RDI: 
> > > 88907ebe05a8
> > >   [ 1570.068384] RBP: ea00260ddd00 R08: ed120fd7c0b6 R09: 
> > > ed120fd7c0b6
> > >   [ 1570.068386] R10: 88907ebe05ab R11: ed120fd7c0b5 R12: 
> > > ea00260ddd38
> > >   [ 1570.068389] R13: 8889a4116000 R14: 8889a4116000 R15: 
> > > 0001
> > >   [ 1570.068391] FS:  7ff039638680() GS:88907ea0() 
> > > knlGS:
> > >   [ 1570.068394] CS:  0010 DS:  ES:  CR0: 80050033
> > >   [ 1570.068396] CR2: 7f36f354cc20 CR3: 0008a0126006 CR4: 
> > > 007706e0
> > >   [ 1570.068398] DR0:  DR1:  DR2: 
> > > 
> > >   [ 1570.068400] DR3:  DR6: fffe0ff0 DR7: 
> > > 0400
> > >   [ 1570.068402] PKRU: 5554
> > >   [ 1570.068404] Call Trace:
> > >   [ 1570.068407]  mem_cgroup_charge+0x175/0x770
> > >   [ 1570.068413]  __add_to_page_cache_locked+0x712/0xad0
> > >   [ 1570.068439]  add_to_page_cache_lru+0xc5/0x1f0
> > >   [ 1570.068461]  cachefiles_read_or_alloc_pages+0x895/0x2e10 [cachefiles]
> > >   [ 1570.068524]  __fscache_read_or_alloc_pages+0x6c0/0xa00 [fscache]
> > >   [ 1570.068540]  __nfs_readpages_from_fscache+0x16d/0x630 [nfs]
> > >   [ 1570.068585]  nfs_readpages+0x24e/0x540 [nfs]
> > >   [ 1570.068693]  read_pages+0x5b1/0xc40
> > >   [ 1570.068711]  page_cache_ra_unbounded+0x460/0x750
> > >   [ 1570.068729]  generic_file_buffered_read_get_pages+0x290/0x1710
> > >   [ 1570.068756]  generic_file_buffered_read+0x2a9/0xc30
> > >   [ 1570.068832]  nfs_file_read+0x13f/0x230 [nfs]
> > >   [ 1570.068872]  new_sync_read+0x3af/0x610
> > >   [ 1570.068901]  vfs_read+0x339/0x4b0
> > >   [ 1570.068909]  ksys_read+0xf1/0x1c0
> > >   [ 1570.068920]  do_syscall_64+0x33/0x40
> > >   [ 1570.068926]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > >   [ 1570.068930] RIP: 0033:0x7ff039135595
> > > 
> > > Before that commit, there was a try_charge() and commit_charge()
> > > in __add_to_page_cache_locked(). These 2 separated charge functions
> > > were replaced by a single mem_cgroup_charge(). However, it forgot
> > > to add a matching mem_cgroup_uncharge() when the xarray insertion
> > > failed with the page released back to the pool. Fix this by adding a
> > > mem_cgroup_uncharge() call when insertion error happens.
> > > 
> > > Fixes: 3fea5a499d57 ("mm: memcontrol: convert page cache to a new 
> > > mem_cgroup_charge() API")
> > > Signed-off-by: Waiman Long 
> > OK, this is indeed a subtle bug. The patch aimed at simplifying the
> > charge lifetime so that users do not really have to think about when to
> > uncharge as that happens when the page is freed. fscache somehow breaks
> > that assumption because it doesn't free up pages but it keeps some of
> > them in the cache.
> > 
> > I have tried to wrap my head around the cached object life time in
> > fscache but failed and got lost in the maze. Is this the only instance
> > of the problem? Would it make more sense to explicitly handle charges in
> > the fscache code or there are other potential users to fall into this
> > trap?
> 
> There may be other places that have similar problem. I focus on the
> filemap.c case as I have a test case that can reliably produce the bug
> splat. This patch does fix it for my test case.

I believe this needs a more general fix than catching a random places
which you can trigger. Would it make more sense to address this at the
fscache level and always make sure that a page returned to the pool is
always uncharged instead?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v3 1/6] drivers: crypto: qce: sha: Restore/save ahash state with custom struct in export/import

[Bjorn Andersson]

On Wed 20 Jan 12:48 CST 2021, Thara Gopinath wrote:

Please drop "drivers: " from $subject.

> Export and import interfaces save and restore partial transformation
> states. The partial states were being stored and restored in struct
> sha1_state for sha1/hmac(sha1) transformations and sha256_state for
> sha256/hmac(sha256) transformations.This led to a bunch of corner cases
> where improper state was being stored and restored. A few of the corner
> cases that turned up during testing are:
> 
> - wrong byte_count restored if export/import is called twice without h/w
> transaction in between
> - wrong buflen restored back if the pending buffer
> length is exactly the block size.
> - wrong state restored if buffer length is 0.
> 
> To fix these issues, save and restore the partial transformation state
> using the newly introduced qce_sha_saved_state struct. This ensures that
> all the pieces required to properly restart the transformation is captured
> and restored back
> 
> Signed-off-by: Thara Gopinath 
> ---
> 
> v1->v2:
>   - Introduced custom struct qce_sha_saved_state to store and
> restore partial sha transformation. v1 was re-using
> qce_sha_reqctx to save and restore partial states and this
> could lead to potential memcpy issues around pointer copying.
> 
>  drivers/crypto/qce/sha.c | 122 +++
>  1 file changed, 34 insertions(+), 88 deletions(-)
> 
> diff --git a/drivers/crypto/qce/sha.c b/drivers/crypto/qce/sha.c
> index 61c418c12345..08aed03e2b59 100644
> --- a/drivers/crypto/qce/sha.c
> +++ b/drivers/crypto/qce/sha.c
> @@ -12,9 +12,15 @@
>  #include "core.h"
>  #include "sha.h"
>  
> -/* crypto hw padding constant for first operation */
> -#define SHA_PADDING  64
> -#define SHA_PADDING_MASK (SHA_PADDING - 1)
> +struct qce_sha_saved_state {
> + u8 pending_buf[QCE_SHA_MAX_BLOCKSIZE];
> + u8 partial_digest[QCE_SHA_MAX_DIGESTSIZE];
> + __be32 byte_count[2];
> + unsigned int pending_buflen;
> + unsigned int flags;
> + u64 count;
> + bool first_blk;
> +};
>  
>  static LIST_HEAD(ahash_algs);
>  
> @@ -139,97 +145,37 @@ static int qce_ahash_init(struct ahash_request *req)
>  
>  static int qce_ahash_export(struct ahash_request *req, void *out)
>  {
> - struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
>   struct qce_sha_reqctx *rctx = ahash_request_ctx(req);
> - unsigned long flags = rctx->flags;
> - unsigned int digestsize = crypto_ahash_digestsize(ahash);
> - unsigned int blocksize =
> - crypto_tfm_alg_blocksize(crypto_ahash_tfm(ahash));
> -
> - if (IS_SHA1(flags) || IS_SHA1_HMAC(flags)) {
> - struct sha1_state *out_state = out;
> -
> - out_state->count = rctx->count;
> - qce_cpu_to_be32p_array((__be32 *)out_state->state,
> -rctx->digest, digestsize);
> - memcpy(out_state->buffer, rctx->buf, blocksize);
> - } else if (IS_SHA256(flags) || IS_SHA256_HMAC(flags)) {
> - struct sha256_state *out_state = out;
> -
> - out_state->count = rctx->count;
> - qce_cpu_to_be32p_array((__be32 *)out_state->state,
> -rctx->digest, digestsize);
> - memcpy(out_state->buf, rctx->buf, blocksize);
> - } else {
> - return -EINVAL;
> - }
> -
> - return 0;
> -}
> -
> -static int qce_import_common(struct ahash_request *req, u64 in_count,
> -  const u32 *state, const u8 *buffer, bool hmac)
> -{
> - struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
> - struct qce_sha_reqctx *rctx = ahash_request_ctx(req);
> - unsigned int digestsize = crypto_ahash_digestsize(ahash);
> - unsigned int blocksize;
> - u64 count = in_count;
> -
> - blocksize = crypto_tfm_alg_blocksize(crypto_ahash_tfm(ahash));
> - rctx->count = in_count;
> - memcpy(rctx->buf, buffer, blocksize);
> -
> - if (in_count <= blocksize) {
> - rctx->first_blk = 1;
> - } else {
> - rctx->first_blk = 0;
> - /*
> -  * For HMAC, there is a hardware padding done when first block
> -  * is set. Therefore the byte_count must be incremened by 64
> -  * after the first block operation.
> -  */
> - if (hmac)
> - count += SHA_PADDING;
> - }
> + struct qce_sha_saved_state *export_state = out;
>  
> - rctx->byte_count[0] = (__force __be32)(count & ~SHA_PADDING_MASK);
> - rctx->byte_count[1] = (__force __be32)(count >> 32);
> - qce_cpu_to_be32p_array((__be32 *)rctx->digest, (const u8 *)state,
> -digestsize);
> - rctx->buflen = (unsigned int)(in_count & (blocksize - 1));
> + memcpy(export_state->pending_buf, rctx->buf, rctx->buflen);
> + memcpy(export_state->partial_digest, rctx->digest,
> +sizeo

Re: [PATCH net-next v2 1/2] dt-bindings: net: dsa: add MT7530 GPIO controller binding

[DENG Qingfang]

On Mon, Jan 25, 2021 at 11:52 PM Rob Herring  wrote:
>
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.

Sorry. Will do that next time.

>
> If a tag was not added on purpose, please state why and what changed.
>

Re: [PATCH v4 1/3] arm64: Improve kernel address detection of __is_lm_address()

[Vincenzo Frascino]

On 1/25/21 2:59 PM, Catalin Marinas wrote:
> On Mon, Jan 25, 2021 at 02:36:34PM +, Vincenzo Frascino wrote:
>> On 1/25/21 1:02 PM, Mark Rutland wrote:
>>> On Fri, Jan 22, 2021 at 03:56:40PM +, Vincenzo Frascino wrote:
 Currently, the __is_lm_address() check just masks out the top 12 bits
 of the address, but if they are 0, it still yields a true result.
 This has as a side effect that virt_addr_valid() returns true even for
 invalid virtual addresses (e.g. 0x0).

 Improve the detection checking that it's actually a kernel address
 starting at PAGE_OFFSET.

 Cc: Catalin Marinas 
 Cc: Will Deacon 
 Suggested-by: Catalin Marinas 
 Reviewed-by: Catalin Marinas 
 Signed-off-by: Vincenzo Frascino 
>>>
>>> Looking around, it seems that there are some existing uses of
>>> virt_addr_valid() that expect it to reject addresses outside of the
>>> TTBR1 range. For example, check_mem_type() in drivers/tee/optee/call.c.
>>>
>>> Given that, I think we need something that's easy to backport to stable.
>>>
>>
>> I agree, I started looking at it this morning and I found cases even in the 
>> main
>> allocators (slub and page_alloc) either then the one you mentioned.
>>
>>> This patch itself looks fine, but it's not going to backport very far,
>>> so I suspect we might need to write a preparatory patch that adds an
>>> explicit range check to virt_addr_valid() which can be trivially
>>> backported.
>>>
>>
>> I checked the old releases and I agree this is not back-portable as it 
>> stands.
>> I propose therefore to add a preparatory patch with the check below:
>>
>> #define __is_ttrb1_address(addr) ((u64)(addr) >= PAGE_OFFSET && \
>>  (u64)(addr) < PAGE_END)
>>
>> If it works for you I am happy to take care of it and post a new version of 
>> my
>> patches.
> 
> I'm not entirely sure we need a preparatory patch. IIUC (it needs
> checking), virt_addr_valid() was fine until 5.4, broken by commit
> 14c127c957c1 ("arm64: mm: Flip kernel VA space"). Will addressed the
> flip case in 68dd8ef32162 ("arm64: memory: Fix virt_addr_valid() using
> __is_lm_address()") but this broke the  NULL address is considered valid.
> 
> Ard's commit f4693c2716b3 ("arm64: mm: extend linear region for 52-bit
> VA configurations") changed the test to no longer rely on va_bits but
> did not change the broken semantics.
> 
> If Ard's change plus the fix proposed in this test works on 5.4, I'd say
> we just merge this patch with the corresponding Cc stable and Fixes tags
> and tweak it slightly when doing the backports as it wouldn't apply
> cleanly. IOW, I wouldn't add another check to virt_addr_valid() as we
> did not need one prior to 5.4.
> 

Thank you for the detailed analysis. I checked on 5.4 and it seems that Ard
patch (not a clean backport) plus my proposed fix works correctly and solves the
issue.

Tomorrow I will post a new version of the series that includes what you are
suggesting.

-- 
Regards,
Vincenzo

Re: [PATCH] sgi-xp: remove h from printk format specifier

[Steve Wahl]

Reviewed-By: Steve Wahl 

On Sat, Jan 23, 2021 at 08:00:03AM -0800, t...@redhat.com wrote:
> From: Tom Rix 
> 
> This change fixes the checkpatch warning described in this commit
> commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of
>   unnecessary %h[xudi] and %hh[xudi]")
> 
> Standard integer promotion is already done and %hx and %hhx is useless
> so do not encourage the use of %hh[xudi] or %h[xudi].
> 
> Signed-off-by: Tom Rix 
> ---
>  drivers/misc/sgi-xp/xpnet.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/misc/sgi-xp/xpnet.c b/drivers/misc/sgi-xp/xpnet.c
> index 23837d0d6f4a..2508f83bdc3f 100644
> --- a/drivers/misc/sgi-xp/xpnet.c
> +++ b/drivers/misc/sgi-xp/xpnet.c
> @@ -208,7 +208,7 @@ xpnet_receive(short partid, int channel, struct 
> xpnet_message *msg)
>   } else {
>   dst = (void *)((u64)skb->data & ~(L1_CACHE_BYTES - 1));
>   dev_dbg(xpnet, "transferring buffer to the skb->data area;\n\t"
> - "xp_remote_memcpy(0x%p, 0x%p, %hu)\n", dst,
> + "xp_remote_memcpy(0x%p, 0x%p, %u)\n", dst,
> (void *)msg->buf_pa, msg->size);
>  
>   ret = xp_remote_memcpy(xp_pa(dst), msg->buf_pa, msg->size);
> @@ -218,7 +218,7 @@ xpnet_receive(short partid, int channel, struct 
> xpnet_message *msg)
>* !!! appears in_use and we can't just call
>* !!! dev_kfree_skb.
>*/
> - dev_err(xpnet, "xp_remote_memcpy(0x%p, 0x%p, 0x%hx) "
> + dev_err(xpnet, "xp_remote_memcpy(0x%p, 0x%p, 0x%x) "
>   "returned error=0x%x\n", dst,
>   (void *)msg->buf_pa, msg->size, ret);
>  
> -- 
> 2.27.0
> 

-- 
Steve Wahl, Hewlett Packard Enterprise

Re: [PATCH] mm/filemap: Adding missing mem_cgroup_uncharge() to __add_to_page_cache_locked()

[Waiman Long]

On 1/25/21 4:28 AM, Michal Hocko wrote:

On Sun 24-01-21 23:24:41, Waiman Long wrote:

The commit 3fea5a499d57 ("mm: memcontrol: convert page
cache to a new mem_cgroup_charge() API") introduced a bug in
__add_to_page_cache_locked() causing the following splat:

  [ 1570.068330] page dumped because: VM_BUG_ON_PAGE(page_memcg(page))
  [ 1570.068333] pages's memcg:8889a4116000
  [ 1570.068343] [ cut here ]
  [ 1570.068346] kernel BUG at mm/memcontrol.c:2924!
  [ 1570.068355] invalid opcode:  [#1] SMP KASAN PTI
  [ 1570.068359] CPU: 35 PID: 12345 Comm: cat Tainted: G S  W I   
5.11.0-rc4-debug+ #1
  [ 1570.068363] Hardware name: HP HP Z8 G4 Workstation/81C7, BIOS P60 v01.25 
12/06/2017
  [ 1570.068365] RIP: 0010:commit_charge+0xf4/0x130
:
  [ 1570.068375] RSP: 0018:8881b38d70e8 EFLAGS: 00010286
  [ 1570.068379] RAX:  RBX: ea00260ddd00 RCX: 
0027
  [ 1570.068382] RDX:  RSI: 0004 RDI: 
88907ebe05a8
  [ 1570.068384] RBP: ea00260ddd00 R08: ed120fd7c0b6 R09: 
ed120fd7c0b6
  [ 1570.068386] R10: 88907ebe05ab R11: ed120fd7c0b5 R12: 
ea00260ddd38
  [ 1570.068389] R13: 8889a4116000 R14: 8889a4116000 R15: 
0001
  [ 1570.068391] FS:  7ff039638680() GS:88907ea0() 
knlGS:
  [ 1570.068394] CS:  0010 DS:  ES:  CR0: 80050033
  [ 1570.068396] CR2: 7f36f354cc20 CR3: 0008a0126006 CR4: 
007706e0
  [ 1570.068398] DR0:  DR1:  DR2: 

  [ 1570.068400] DR3:  DR6: fffe0ff0 DR7: 
0400
  [ 1570.068402] PKRU: 5554
  [ 1570.068404] Call Trace:
  [ 1570.068407]  mem_cgroup_charge+0x175/0x770
  [ 1570.068413]  __add_to_page_cache_locked+0x712/0xad0
  [ 1570.068439]  add_to_page_cache_lru+0xc5/0x1f0
  [ 1570.068461]  cachefiles_read_or_alloc_pages+0x895/0x2e10 [cachefiles]
  [ 1570.068524]  __fscache_read_or_alloc_pages+0x6c0/0xa00 [fscache]
  [ 1570.068540]  __nfs_readpages_from_fscache+0x16d/0x630 [nfs]
  [ 1570.068585]  nfs_readpages+0x24e/0x540 [nfs]
  [ 1570.068693]  read_pages+0x5b1/0xc40
  [ 1570.068711]  page_cache_ra_unbounded+0x460/0x750
  [ 1570.068729]  generic_file_buffered_read_get_pages+0x290/0x1710
  [ 1570.068756]  generic_file_buffered_read+0x2a9/0xc30
  [ 1570.068832]  nfs_file_read+0x13f/0x230 [nfs]
  [ 1570.068872]  new_sync_read+0x3af/0x610
  [ 1570.068901]  vfs_read+0x339/0x4b0
  [ 1570.068909]  ksys_read+0xf1/0x1c0
  [ 1570.068920]  do_syscall_64+0x33/0x40
  [ 1570.068926]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
  [ 1570.068930] RIP: 0033:0x7ff039135595

Before that commit, there was a try_charge() and commit_charge()
in __add_to_page_cache_locked(). These 2 separated charge functions
were replaced by a single mem_cgroup_charge(). However, it forgot
to add a matching mem_cgroup_uncharge() when the xarray insertion
failed with the page released back to the pool. Fix this by adding a
mem_cgroup_uncharge() call when insertion error happens.

Fixes: 3fea5a499d57 ("mm: memcontrol: convert page cache to a new 
mem_cgroup_charge() API")
Signed-off-by: Waiman Long 

OK, this is indeed a subtle bug. The patch aimed at simplifying the
charge lifetime so that users do not really have to think about when to
uncharge as that happens when the page is freed. fscache somehow breaks
that assumption because it doesn't free up pages but it keeps some of
them in the cache.

I have tried to wrap my head around the cached object life time in
fscache but failed and got lost in the maze. Is this the only instance
of the problem? Would it make more sense to explicitly handle charges in
the fscache code or there are other potential users to fall into this
trap?


There may be other places that have similar problem. I focus on the 
filemap.c case as I have a test case that can reliably produce the bug 
splat. This patch does fix it for my test case.


Cheers,
Longman

Re: [External] : Re: [PATCH v2 0/5] Introduce PRU remoteproc consumer API

[Santosh Shilimkar]

On Jan 25, 2021, at 7:43 AM, Suman Anna  wrote:
> 
> Hi Santosh,
> 
> On 1/24/21 10:34 PM, santosh.shilim...@oracle.com wrote:
>> Hi Suman, Mathieu,
>> 
>> On 1/7/21 2:49 PM, Suman Anna wrote:
>>> On 1/7/21 4:44 PM, Mathieu Poirier wrote:
 On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
> Hi Mathieu,
> 
>> [...]
 I only see input from Andy and Lars in the thread you point out, nothing 
 from
 Greg.  I have also taken a look at the patch [1] that made checkpatch 
 complain
 about ENOTSUPP.  From what I see in that commit log the goal is to prevent 
 new
 additions of ENOTSUPP to the kernel.
 
 Please modify and resend, otherwise I'm sure someone will send another 
 patch to
 fix it before the end of the cycle.
>>> 
>>> Yeah ok. I will send out a v3.
>>> 
>> I haven't seen v3 of this series yet. Please post it
>> if you would like to include it for 5.12.
> 
> This series is dependent on couple of patches that would have to come through
> the remoteproc tree first, and I need to post the next versions of those as
> well. So, let me sort out those first. You can drop this from your queue for 
> 5.12.
> 
Sounds good.

Regards,
Santosh

Re: [PATCH 2/5] ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 SoM

[Alexandre TORGUE]

Hi,

On 12/23/20 8:13 PM, Jagan Teki wrote:

MicroGEA STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam.

General features:
- STM32MP157AAC
- Up to 1GB DDR3L-800
- 512MB Nand flash
- I2S

MicroGEA STM32MP1 needs to mount on top of Engicam MicroDev carrier
boards for creating complete platform solutions.

Add support for it.

Signed-off-by: Matteo Lisi 
Signed-off-by: Francesco Utel 
Signed-off-by: Mirko Ardinghi 
Signed-off-by: Jagan Teki 
---
  .../dts/stm32mp157a-microgea-stm32mp1.dtsi| 147 ++
  1 file changed, 147 insertions(+)
  create mode 100644 arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1.dtsi

diff --git a/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1.dtsi 
b/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1.dtsi
new file mode 100644
index ..97d569107bfe
--- /dev/null
+++ b/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1.dtsi
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
+ * Copyright (c) 2020 Engicam srl
+ * Copyright (c) 2020 Amarula Solutons(India)
+ */
+


If STM32MP157AAC is soldered onto this board, you should include SoC 
dtsi here and no into MicroDev 2.0 board. No ?


+#include "stm32mp15-pinctrl.dtsi"
+#include "stm32mp15xxaa-pinctrl.dtsi"


Regards
Alex


+/ {
+   compatible = "engicam,microgea-stm32mp1", "st,stm32mp157";
+
+   memory@c000 {
+   reg = <0xc000 0x1000>;
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   mcuram2: mcuram2@1000 {
+   compatible = "shared-dma-pool";
+   reg = <0x1000 0x4>;
+   no-map;
+   };
+
+   vdev0vring0: vdev0vring0@1004 {
+   compatible = "shared-dma-pool";
+   reg = <0x1004 0x1000>;
+   no-map;
+   };
+
+   vdev0vring1: vdev0vring1@10041000 {
+   compatible = "shared-dma-pool";
+   reg = <0x10041000 0x1000>;
+   no-map;
+   };
+
+   vdev0buffer: vdev0buffer@10042000 {
+   compatible = "shared-dma-pool";
+   reg = <0x10042000 0x4000>;
+   no-map;
+   };
+
+   mcuram: mcuram@3000 {
+   compatible = "shared-dma-pool";
+   reg = <0x3000 0x4>;
+   no-map;
+   };
+
+   retram: retram@3800 {
+   compatible = "shared-dma-pool";
+   reg = <0x3800 0x1>;
+   no-map;
+   };
+   };
+
+   vin: regulator-vin {
+   compatible = "regulator-fixed";
+   regulator-name = "vin";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+
+   vddcore: regulator-vddcore {
+   compatible = "regulator-fixed";
+   regulator-name = "vddcore";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-always-on;
+   vin-supply = <&vin>;
+   };
+
+   vdd: regulator-vdd {
+   compatible = "regulator-fixed";
+   regulator-name = "vdd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   vin-supply = <&vin>;
+   };
+
+   vddq_ddr: regulator-vddq-ddr {
+   compatible = "regulator-fixed";
+   regulator-name = "vddq_ddr";
+   regulator-min-microvolt = <135>;
+   regulator-max-microvolt = <135>;
+   regulator-always-on;
+   vin-supply = <&vin>;
+   };
+};
+
+&dts {
+   status = "okay";
+};
+
+&fmc {
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <&fmc_pins_a>;
+   pinctrl-1 = <&fmc_sleep_pins_a>;
+   status = "okay";
+
+   nand-controller@4,0 {
+   status = "okay";
+
+   nand@0 {
+   reg = <0>;
+   nand-on-flash-bbt;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+   };
+};
+
+&ipcc {
+   status = "okay";
+};
+
+&iwdg2{
+   timeout-sec = <32>;
+   status = "okay";
+};
+
+&m4_rproc{
+   memory-region = <&retram>, <&mcuram>, <&mcuram2>, <&vdev0vring0>,
+   <&vdev0vring1>, <&vdev0buffer>;
+   mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>;
+   mbox-names = "vq0", "vq1", "shutdown";
+   interrupt-parent = <&exti>;
+   interrupts

[PATCH] fs: export kern_path_locked

[Denis Kirjanov]

the function is used outside and we have a prototype
defined in namei.h

Signed-off-by: Denis Kirjanov 
---
 fs/namei.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/namei.c b/fs/namei.c
index 78443a85480a..3de3b3642302 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2450,6 +2450,7 @@ struct dentry *kern_path_locked(const char *name, struct 
path *path)
putname(filename);
return d;
 }
+EXPORT_SYMBOL(kern_path_locked);
 
 int kern_path(const char *name, unsigned int flags, struct path *path)
 {
-- 
2.16.4

Re: [PATCH] ath9k: fix build error with LEDS_CLASS=m

[Arnd Bergmann]

On Mon, Jan 25, 2021 at 4:04 PM Krzysztof Kozlowski  wrote:
> On Mon, 25 Jan 2021 at 15:38, Arnd Bergmann  wrote:
> > On Mon, Jan 25, 2021 at 2:27 PM Krzysztof Kozlowski  wrote:
>
> I meant that having MAC80211_LEDS selected causes the ath9k driver to
> toggle on/off the WiFi LED. Every second, regardless whether it's
> doing something or not. In my setup, I have problems with a WiFi
> dongle somehow crashing (WiFi disappears, nothing comes from the
> dongle... maybe it's Atheros FW, maybe some HW problem) and I found
> this LED on/off slightly increases the chances of this dongle-crash.
> That was the actual reason behind my commits.
>
> Second reason is that I don't want to send USB commands every second
> when the device is idle. It unnecessarily consumes power on my
> low-power device.

Ok, I see.

> Of course another solution is to just disable the trigger via sysfs
> LED API. It would also work but my patch allows entire code to be
> compiled-out (which was conditional in ath9k already).
>
> Therefore the patch I sent allows the ath9k LED option to be fully
> choosable. Someone wants every-second-LED-blink, sure, enable
> ATH9K_LEDS and you have it. Someone wants to reduce the kernel size,
> don't enable ATH9K_LEDS.

Originally, I think this is what CONFIG_MAC80211_LEDS was meant
for, but it seems that this is not actually practical, since this also
gets selected by half of the drivers using it, while the other half have
a dependency on it. Out of the ones that select it, some in turn
select LEDS_CLASS, while some depend on it.

I think this needs a larger-scale cleanup for consistency between
(at least) all the wireless drivers using LEDs. Either your patch
or mine should get applied in the meantime, and I don't care much
which one in this case, as we still have the remaining inconsistency.

Arnd

[PATCH v4 06/21] mfd: axp20x: Allow AXP chips without interrupt lines

[Andre Przywara]

Currently the AXP chip requires to have its IRQ line connected to some
interrupt controller, and will fail probing when this is not the case.

On a new Allwinner SoC (H616) there is no NMI pin anymore, and at
least one board does not connect the AXP's IRQ pin to anything else,
so the interrupt functionality of the AXP chip is simply not available.

Check whether the interrupt line number returned by the platform code is
valid, before trying to register the irqchip. If not, we skip this
registration, to avoid the driver to bail out completely.

Signed-off-by: Andre Przywara 
---
 drivers/mfd/axp20x.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 3eae04e24ac8..00c163a1e20d 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -959,12 +959,17 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
 AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODE);
}
 
-   ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
- IRQF_ONESHOT | IRQF_SHARED | axp20x->irq_flags,
-  -1, axp20x->regmap_irq_chip, &axp20x->regmap_irqc);
-   if (ret) {
-   dev_err(axp20x->dev, "failed to add irq chip: %d\n", ret);
-   return ret;
+   /* Only if there is an interrupt line connected towards the CPU. */
+   if (axp20x->irq > 0) {
+   ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
+   IRQF_ONESHOT | IRQF_SHARED | axp20x->irq_flags,
+   -1, axp20x->regmap_irq_chip,
+   &axp20x->regmap_irqc);
+   if (ret) {
+   dev_err(axp20x->dev, "failed to add irq chip: %d\n",
+   ret);
+   return ret;
+   }
}
 
ret = mfd_add_devices(axp20x->dev, -1, axp20x->cells,
-- 
2.17.5

Re: [PATCH 4/4] vfio-pci/zdev: Introduce the zPCI I/O vfio region

[Matthew Rosato]

On 1/25/21 10:42 AM, Cornelia Huck wrote:

On Mon, 25 Jan 2021 09:40:38 -0500
Matthew Rosato  wrote:


On 1/22/21 6:48 PM, Alex Williamson wrote:

On Tue, 19 Jan 2021 15:02:30 -0500
Matthew Rosato  wrote:
   

Some s390 PCI devices (e.g. ISM) perform I/O operations that have very
specific requirements in terms of alignment as well as the patterns in
which the data is read/written. Allowing these to proceed through the
typical vfio_pci_bar_rw path will cause them to be broken in up in such a
way that these requirements can't be guaranteed. In addition, ISM devices
do not support the MIO codepaths that might be triggered on vfio I/O coming
from userspace; we must be able to ensure that these devices use the
non-MIO instructions.  To facilitate this, provide a new vfio region by
which non-MIO instructions can be passed directly to the host kernel s390
PCI layer, to be reliably issued as non-MIO instructions.

This patch introduces the new vfio VFIO_REGION_SUBTYPE_IBM_ZPCI_IO region
and implements the ability to pass PCISTB and PCILG instructions over it,
as these are what is required for ISM devices.


There have been various discussions about splitting vfio-pci to allow
more device specific drivers rather adding duct tape and bailing wire
for various device specific features to extend vfio-pci.  The latest
iteration is here[1].  Is it possible that such a solution could simply
provide the standard BAR region indexes, but with an implementation that
works on s390, rather than creating new device specific regions to
perform the same task?  Thanks,

Alex

[1]https://lore.kernel.org/lkml/20210117181534.65724-1-mgurto...@nvidia.com/
   


Thanks for the pointer, I'll have to keep an eye on this.  An approach
like this could solve some issues, but I think a main issue that still
remains with relying on the standard BAR region indexes (whether using
the current vfio-pci driver or a device-specific driver) is that QEMU
writes to said BAR memory region are happening in, at most, 8B chunks
(which then, in the current general-purpose vfio-pci code get further
split up into 4B iowrite operations).  The alternate approach I'm
proposing here is allowing for the whole payload (4K) in a single
operation, which is significantly faster.  So, I suspect even with a
device specific driver we'd want this sort of a region anyhow..


I'm also wondering about device specific vs architecture/platform
specific handling.

If we're trying to support ISM devices, that's device specific
handling; but if we're trying to add more generic things like the large
payload support, that's not necessarily tied to a device, is it? For
example, could a device support large payload if plugged into a z, but
not if plugged into another machine? >


Yes, that's correct -- While ISM is providing the impetus and has a hard 
requirement for some of this due to the MIO instruction quirk, the 
mechanism being implemented here is definitely not ISM-specific -- it's 
more like an s390-wide quirk that could really benefit any device that 
wants to do large payloads (PCISTB).


And I think that ultimately goes back to why Pierre wanted to have QEMU 
be as permissive as possible in using the region vs limiting it only to 
ISM.

Re: [PATCH net-next v2 1/2] dt-bindings: net: dsa: add MT7530 GPIO controller binding

[Rob Herring]

On Mon, 25 Jan 2021 12:43:21 +0800, DENG Qingfang wrote:
> Add device tree binding to support MT7530 GPIO controller.
> 
> Signed-off-by: DENG Qingfang 
> ---
> Changes v1 -> v2:
>   No changes.
> 
>  Documentation/devicetree/bindings/net/dsa/mt7530.txt | 6 ++
>  1 file changed, 6 insertions(+)
> 


Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.

If a tag was not added on purpose, please state why and what changed.

Re: [PATCH] amdgpu: fix clang build warning

[Alex Deucher]

On Mon, Jan 25, 2021 at 7:24 AM Arnd Bergmann  wrote:
>
> From: Arnd Bergmann 
>
> clang warns about the -mhard-float command line arguments
> on architectures that do not support this:
>
> clang: error: argument unused during compilation: '-mhard-float' 
> [-Werror,-Wunused-command-line-argument]
>
> Move this into the gcc-specific arguments.
>
> Fixes: e77165bf7b02 ("drm/amd/display: Add DCN3 blocks to Makefile")
> Signed-off-by: Arnd Bergmann 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dcn30/Makefile  | 6 --
>  drivers/gpu/drm/amd/display/dc/dcn301/Makefile | 3 ++-
>  drivers/gpu/drm/amd/display/dc/dcn302/Makefile | 3 ++-
>  3 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile 
> b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
> index c20331eb62e0..dfd77b3cc84d 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
> @@ -32,8 +32,8 @@ DCN30 = dcn30_init.o dcn30_hubbub.o dcn30_hubp.o 
> dcn30_dpp.o dcn30_optc.o \
>
>
>  ifdef CONFIG_X86
> -CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -mhard-float -msse
> -CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o := -mhard-float -msse
> +CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -msse
> +CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o := -msse
>  endif
>
>  ifdef CONFIG_PPC64
> @@ -45,6 +45,8 @@ ifdef CONFIG_CC_IS_GCC
>  ifeq ($(call cc-ifversion, -lt, 0701, y), y)
>  IS_OLD_GCC = 1
>  endif
> +CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o += -mhard-float
> +CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o += -mhard-float
>  endif
>
>  ifdef CONFIG_X86
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn301/Makefile 
> b/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
> index 3ca7d911d25c..09264716d1dc 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
> @@ -14,7 +14,7 @@ DCN301 = dcn301_init.o dcn301_resource.o dcn301_dccg.o \
> dcn301_dio_link_encoder.o dcn301_hwseq.o dcn301_panel_cntl.o 
> dcn301_hubbub.o
>
>  ifdef CONFIG_X86
> -CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o := -mhard-float -msse
> +CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o := -msse
>  endif
>
>  ifdef CONFIG_PPC64
> @@ -25,6 +25,7 @@ ifdef CONFIG_CC_IS_GCC
>  ifeq ($(call cc-ifversion, -lt, 0701, y), y)
>  IS_OLD_GCC = 1
>  endif
> +CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o += -mhard-float
>  endif
>
>  ifdef CONFIG_X86
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile 
> b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
> index 8d4924b7dc22..101620a8867a 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
> @@ -13,7 +13,7 @@
>  DCN3_02 = dcn302_init.o dcn302_hwseq.o dcn302_resource.o
>
>  ifdef CONFIG_X86
> -CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -mhard-float -msse
> +CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -msse
>  endif
>
>  ifdef CONFIG_PPC64
> @@ -24,6 +24,7 @@ ifdef CONFIG_CC_IS_GCC
>  ifeq ($(call cc-ifversion, -lt, 0701, y), y)
>  IS_OLD_GCC = 1
>  endif
> +CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o += -mhard-float
>  endif
>
>  ifdef CONFIG_X86
> --
> 2.29.2
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v10 05/12] mm: HUGE_VMAP arch support cleanup

[Christophe Leroy]

Le 24/01/2021 à 12:40, Christoph Hellwig a écrit :

diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h
index 2ca708ab9b20..597b40405319 100644
--- a/arch/arm64/include/asm/vmalloc.h
+++ b/arch/arm64/include/asm/vmalloc.h
@@ -1,4 +1,12 @@
  #ifndef _ASM_ARM64_VMALLOC_H
  #define _ASM_ARM64_VMALLOC_H
  
+#include 

+
+#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
+bool arch_vmap_p4d_supported(pgprot_t prot);
+bool arch_vmap_pud_supported(pgprot_t prot);
+bool arch_vmap_pmd_supported(pgprot_t prot);
+#endif


Shouldn't the be inlines or macros?  Also it would be useful
if the architectures would not have to override all functions
but just those that are it actually implements?

Also lots of > 80 char lines in the patch.



Since 
https://github.com/linuxppc/linux/commit/bdc48fa11e46f867ea4d75fa59ee87a7f48be144
this 80 char limit is not strongly enforced anymore.

Allthough 80 is still the prefered limit, code is often more readable with a slightly longer single 
line that with lines splited.


Christophe

Re: [PATCH] Bluetooth: drop HCI device reference before return

[Marcel Holtmann]

Hi Pan,

> Call hci_dev_put() to decrement reference count of HCI device hdev if
> fails to duplicate memory.
> 
> Fixes: 0b26ab9dce74 ("Bluetooth: AMP: Handle Accept phylink command status 
> evt")
> Signed-off-by: Pan Bian 
> ---
> net/bluetooth/a2mp.c | 1 +
> 1 file changed, 1 insertion(+)

patch has been applied to bluetooth-next tree.

Regards

Marcel

Re: [PATCH 1/3] Bluetooth: btusb: Refactor gpio reset

[Marcel Holtmann]

Hi Abhishek,

> Refactor gpio reset to use a common gpio reset function.
> 
> Signed-off-by: Abhishek Pandit-Subedi 
> Reviewed-by: Miao-chen Chou 
> ---
> 
> drivers/bluetooth/btusb.c | 59 +--
> 1 file changed, 19 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index b14102fba6018..03341e6cbf3ed 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -547,6 +547,7 @@ struct btusb_data {
>   struct usb_endpoint_descriptor *diag_rx_ep;
> 
>   struct gpio_desc *reset_gpio;
> + unsigned int reset_duration_ms;
> 
>   __u8 cmdreq_type;
>   __u8 cmdreq;
> @@ -566,15 +567,21 @@ struct btusb_data {
>   unsigned cmd_timeout_cnt;
> };
> 
> -static void btusb_intel_cmd_timeout(struct hci_dev *hdev)
> +static void btusb_toggle_gpio(struct gpio_desc *desc, unsigned int duration)
> +{
> + gpiod_set_value_cansleep(desc, 1);
> + msleep(duration);
> + gpiod_set_value_cansleep(desc, 0);
> +}
> +
> +static void btusb_gpio_cmd_timeout(struct hci_dev *hdev)
> {
>   struct btusb_data *data = hci_get_drvdata(hdev);
> - struct gpio_desc *reset_gpio = data->reset_gpio;
> 
>   if (++data->cmd_timeout_cnt < 5)
>   return;
> 
> - if (!reset_gpio) {
> + if (!data->reset_gpio) {
>   bt_dev_err(hdev, "No way to reset. Ignoring and continuing");
>   return;
>   }
> @@ -592,39 +599,7 @@ static void btusb_intel_cmd_timeout(struct hci_dev *hdev)
>   }
> 
>   bt_dev_err(hdev, "Initiating HW reset via gpio");
> - gpiod_set_value_cansleep(reset_gpio, 1);
> - msleep(100);
> - gpiod_set_value_cansleep(reset_gpio, 0);
> -}
> -
> -static void btusb_rtl_cmd_timeout(struct hci_dev *hdev)
> -{
> - struct btusb_data *data = hci_get_drvdata(hdev);
> - struct gpio_desc *reset_gpio = data->reset_gpio;
> -
> - if (++data->cmd_timeout_cnt < 5)
> - return;
> -
> - if (!reset_gpio) {
> - bt_dev_err(hdev, "No gpio to reset Realtek device, ignoring");
> - return;
> - }
> -
> - /* Toggle the hard reset line. The Realtek device is going to
> -  * yank itself off the USB and then replug. The cleanup is handled
> -  * correctly on the way out (standard USB disconnect), and the new
> -  * device is detected cleanly and bound to the driver again like
> -  * it should be.
> -  */
> - if (test_and_set_bit(BTUSB_HW_RESET_ACTIVE, &data->flags)) {
> - bt_dev_err(hdev, "last reset failed? Not resetting again");
> - return;
> - }
> -
> - bt_dev_err(hdev, "Reset Realtek device via gpio");
> - gpiod_set_value_cansleep(reset_gpio, 1);
> - msleep(200);
> - gpiod_set_value_cansleep(reset_gpio, 0);
> + btusb_toggle_gpio(data->reset_gpio, data->reset_duration_ms);
> }

You need to explain why this patch is correct. You are removing more code here. 
And there is an extra check in case of Realtek and a large comment.

Regards

Marcel

Re: [PATCH] Bluetooth: Put HCI device if inquiry procedure interrupts

[Marcel Holtmann]

Hi Pan,

> Jump to the label done to decrement the reference count of HCI device
> hdev on path that the Inquiry procedure is interrupted.
> 
> Fixes: 3e13fa1e1fab ("Bluetooth: Fix hci_inquiry ioctl usage")
> Signed-off-by: Pan Bian 
> ---
> net/bluetooth/hci_core.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

Re: [RFC PATCH v2] uacce: Add uacce_ctrl misc device

[Jason Gunthorpe]

On Mon, Jan 25, 2021 at 04:34:56PM +0800, Zhou Wang wrote:

> +static int uacce_pin_page(struct uacce_pin_container *priv,
> +   struct uacce_pin_address *addr)
> +{
> + unsigned int flags = FOLL_FORCE | FOLL_WRITE;
> + unsigned long first, last, nr_pages;
> + struct page **pages;
> + struct pin_pages *p;
> + int ret;
> +
> + first = (addr->addr & PAGE_MASK) >> PAGE_SHIFT;
> + last = ((addr->addr + addr->size - 1) & PAGE_MASK) >> PAGE_SHIFT;
> + nr_pages = last - first + 1;
> +
> + pages = vmalloc(nr_pages * sizeof(struct page *));
> + if (!pages)
> + return -ENOMEM;
> +
> + p = kzalloc(sizeof(*p), GFP_KERNEL);
> + if (!p) {
> + ret = -ENOMEM;
> + goto free;
> + }
> +
> + ret = pin_user_pages_fast(addr->addr & PAGE_MASK, nr_pages,
> +   flags | FOLL_LONGTERM, pages);

This needs to copy the RLIMIT_MEMLOCK and can_do_mlock() stuff from
other places, like ib_umem_get

> + ret = xa_err(xa_store(&priv->array, p->first, p, GFP_KERNEL));

And this is really weird, I don't think it makes sense to make handles
for DMA based on the starting VA.

> +static int uacce_unpin_page(struct uacce_pin_container *priv,
> + struct uacce_pin_address *addr)
> +{
> + unsigned long first, last, nr_pages;
> + struct pin_pages *p;
> +
> + first = (addr->addr & PAGE_MASK) >> PAGE_SHIFT;
> + last = ((addr->addr + addr->size - 1) & PAGE_MASK) >> PAGE_SHIFT;
> + nr_pages = last - first + 1;
> +
> + /* find pin_pages */
> + p = xa_load(&priv->array, first);
> + if (!p)
> + return -ENODEV;
> +
> + if (p->nr_pages != nr_pages)
> + return -EINVAL;
> +
> + /* unpin */
> + unpin_user_pages(p->pages, p->nr_pages);

And unpinning without guaranteeing there is no ongoing DMA is really
weird

Are you abusing this in conjunction with a SVA scheme just to prevent
page motion? Why wasn't mlock good enough?

Jason

Re: [PATCH v6 0/7] MSFT offloading support for advertisement monitor

[Marcel Holtmann]

Hi Archie,

> This series of patches manages the hardware offloading part of MSFT
> extension API. The full documentation can be accessed by this link:
> https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands-and-events
> 
> Only four of the HCI commands are planned to be implemented:
> HCI_VS_MSFT_Read_Supported_Features (implemented in previous patch),
> HCI_VS_MSFT_LE_Monitor_Advertisement,
> HCI_VS_MSFT_LE_Cancel_Monitor_Advertisement, and
> HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable.
> These are the commands which would be used for advertisement monitor
> feature. Only if the controller supports the MSFT extension would
> these commands be sent. Otherwise, software-based monitoring would be
> performed in the user space instead.
> 
> Thanks in advance for your feedback!
> 
> Archie
> 
> Changes in v6:
> * New patch "advmon offload MSFT interleave scanning integration"
> * New patch "disable advertisement filters during suspend"
> 
> Changes in v5:
> * Discard struct flags on msft_data and use it's members directly
> 
> Changes in v4:
> * Change the logic of merging add_adv_patterns_monitor with rssi
> * Aligning variable declaration on mgmt.h
> * Replacing the usage of BT_DBG with bt_dev_dbg
> 
> Changes in v3:
> * Flips the order of rssi and pattern_count on mgmt struct
> * Fix return type of msft_remove_monitor
> 
> Changes in v2:
> * Add a new opcode instead of modifying an existing one
> * Also implement the new MGMT opcode and merge the functionality with
>  the old one.
> 
> Archie Pusaka (6):
>  Bluetooth: advmon offload MSFT add rssi support
>  Bluetooth: advmon offload MSFT add monitor
>  Bluetooth: advmon offload MSFT remove monitor
>  Bluetooth: advmon offload MSFT handle controller reset
>  Bluetooth: advmon offload MSFT handle filter enablement
>  Bluetooth: advmon offload MSFT interleave scanning integration
> 
> Howard Chung (1):
>  Bluetooth: disable advertisement filters during suspend
> 
> include/net/bluetooth/hci_core.h |  36 ++-
> include/net/bluetooth/mgmt.h |  16 ++
> net/bluetooth/hci_core.c | 174 +---
> net/bluetooth/hci_request.c  |  49 +++-
> net/bluetooth/mgmt.c | 391 +++---
> net/bluetooth/msft.c | 460 ++-
> net/bluetooth/msft.h |  30 ++
> 7 files changed, 1015 insertions(+), 141 deletions(-)

all 7 patches have been applied to bluetooth-next tree.

Regards

Marcel

Re: LTP: madvise08.c:203: TFAIL: No sequence in dump after MADV_DODUMP.

[Arnd Bergmann]

On Mon, Jan 25, 2021 at 3:48 PM Naresh Kamboju
 wrote:
>
> LTP syscalls madvise08 test case failed on all devices from
> Linux next 20210118 to till day.
> strace log attached to this email and link provided below.
>
> BAD: next-20210118
> GOOD: next-20210115
>
> This failure is easily reproducible on Linux next tag 20210118 above.
>
> tst_test.c:1250: TINFO: Timeout per run is 0h 15m 00s
> madvise08.c:73: TINFO: Temporary core pattern is
> '/scratch/ltp-2nftQzNI1K/HclFMH/dump-%p'
> madvise08.c:112: TINFO: Dump file should be dump-10109
> madvise08.c:196: TPASS: madvise(..., MADV_DONTDUMP)
> madvise08.c:112: TINFO: Dump file should be dump-10110
> madvise08.c:203: TFAIL: No sequence in dump after MADV_DODUMP.
>
> strace log,
> https://lkft.validation.linaro.org/scheduler/job/2184866#L1257

Ok, so in this part of the log,

[pid   485] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_DUMPED,
si_pid=487, si_uid=0, si_status=SIGABRT, si_utime=0, si_stime=0} ---
[pid   485] write(2, \"madvise08.c:117: \33[1;34mTINFO: \33\"...,
64madvise08.c:117: [1;34mTINFO: [0mDump file should be dump-487
) = 64
[pid   485] access(\"dump-487\", F_OK)= 0
[pid   485] openat(AT_FDCWD, \"dump-487\", O_RDONLY) = 3
[pid   485] read(3,
\"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\4\0>\0\1\0\0\0\0\0\0\0\0\0\0\0\"...,
1024) = 1024
[pid   485] read(3,
\"\0\320\3\0\0\0\0\0\0\340\375\24\304\177\0\0\0\0\0\0\0\0\0\0\0\20\0\0\0\0\0\0\"...,
1024) = 292
[pid   485] read(3, \"\", 1024)   = 0
[pid   485] close(3)= 0
[pid   485] write(2, \"madvise08.c:208: \33[1;31mTFAIL: \33\"...,
74madvise08.c:208: [1;31mTFAIL: [0mNo sequence in dump after
MADV_DODUMP.

it seems that the data that was requested to be dumped with MADV_DODUMP is
indeed completely absent.

There was exactly one commit that got merged between next-20210115 and
next-20120118
related to core dumps: 8a3cc755b138 ("coredump: don't bother with
do_truncate()").
Adding Al Viro to Cc for that.

Naresh, could you try reverting that patch?

 Arnd

Re: [PATCH 1/2] x86/setup: consolidate early memory reservations

[Mike Rapoport]

On Mon, Jan 25, 2021 at 03:59:11PM +0100, Borislav Petkov wrote:
> On Fri, Jan 15, 2021 at 10:32:54AM +0200, Mike Rapoport wrote:
> > +   trim_low_memory_range();
> 
> Btw, you can get rid of that one too:
> 
> /*
>  * Here we put platform-specific memory range workarounds, i.e.
>  * memory known to be corrupt or otherwise in need to be reserved on
>  * specific platforms.
>  *
>  * If this gets used more widely it could use a real dispatch mechanism.
>  */
> static void __init trim_platform_memory_ranges(void)
> {
> trim_snb_memory();
> }
> 
> yeah, yeah, we can do a real dispatch mechanism but we didn't need one
> since 2012 so I guess we can get rid of trim_platform_memory_ranges()
> and call trim_snb_memory() directly and simplify it even more.

Ok.
 
> Thx.
> 

-- 
Sincerely yours,
Mike.

[PATCH v2 4/4] dmaengine: rcar-dmac: Add support for R-Car V3U

[Geert Uytterhoeven]

The DMACs (both SYS-DMAC and RT-DMAC) on R-Car V3U differ slightly from
the DMACs on R-Car Gen2 and other R-Car Gen3 SoCs:
  1. The per-channel registers are located in a second register block.
 Add support for mapping the second block, using the appropriate
 offsets and stride.
  2. The common Channel Clear Register (DMACHCLR) was replaced by a
 per-channel register.
 Update rcar_dmac_chan_clear{,_all}() to handle this.
 As rcar_dmac_init() needs to clear the status before the individual
 channels are probed, channel index and base address initialization
 are moved forward.

Inspired by a patch in the BSP by Phong Hoang
.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Use two separate named regions instead of an iomem[] array,
  - Drop rcar_dmac_of_data.chan_reg_block, check for
!rcar_dmac_of_data.chan_offset_base instead,
  - Precalculate chan_base in rcar_dmac_probe().
---
 drivers/dma/sh/rcar-dmac.c | 74 --
 1 file changed, 55 insertions(+), 19 deletions(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index 7a0f802c61e5152d..d9589eea98083215 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -189,7 +189,8 @@ struct rcar_dmac_chan {
  * struct rcar_dmac - R-Car Gen2 DMA Controller
  * @engine: base DMA engine object
  * @dev: the hardware device
- * @iomem: remapped I/O memory base
+ * @dmac_base: remapped base register block
+ * @chan_base: remapped channel register block (optional)
  * @n_channels: number of available channels
  * @channels: array of DMAC channels
  * @channels_mask: bitfield of which DMA channels are managed by this driver
@@ -198,7 +199,8 @@ struct rcar_dmac_chan {
 struct rcar_dmac {
struct dma_device engine;
struct device *dev;
-   void __iomem *iomem;
+   void __iomem *dmac_base;
+   void __iomem *chan_base;
 
unsigned int n_channels;
struct rcar_dmac_chan *channels;
@@ -234,7 +236,7 @@ struct rcar_dmac_of_data {
 #define RCAR_DMAOR_PRI_ROUND_ROBIN (3 << 8)
 #define RCAR_DMAOR_AE  (1 << 2)
 #define RCAR_DMAOR_DME (1 << 0)
-#define RCAR_DMACHCLR  0x0080
+#define RCAR_DMACHCLR  0x0080  /* Not on R-Car V3U */
 #define RCAR_DMADPSEC  0x00a0
 
 #define RCAR_DMASAR0x
@@ -297,6 +299,9 @@ struct rcar_dmac_of_data {
 #define RCAR_DMAFIXDAR 0x0014
 #define RCAR_DMAFIXDPBASE  0x0060
 
+/* For R-Car V3U */
+#define RCAR_V3U_DMACHCLR  0x0100
+
 /* Hardcode the MEMCPY transfer size to 4 bytes. */
 #define RCAR_DMAC_MEMCPY_XFER_SIZE 4
 
@@ -307,17 +312,17 @@ struct rcar_dmac_of_data {
 static void rcar_dmac_write(struct rcar_dmac *dmac, u32 reg, u32 data)
 {
if (reg == RCAR_DMAOR)
-   writew(data, dmac->iomem + reg);
+   writew(data, dmac->dmac_base + reg);
else
-   writel(data, dmac->iomem + reg);
+   writel(data, dmac->dmac_base + reg);
 }
 
 static u32 rcar_dmac_read(struct rcar_dmac *dmac, u32 reg)
 {
if (reg == RCAR_DMAOR)
-   return readw(dmac->iomem + reg);
+   return readw(dmac->dmac_base + reg);
else
-   return readl(dmac->iomem + reg);
+   return readl(dmac->dmac_base + reg);
 }
 
 static u32 rcar_dmac_chan_read(struct rcar_dmac_chan *chan, u32 reg)
@@ -339,12 +344,23 @@ static void rcar_dmac_chan_write(struct rcar_dmac_chan 
*chan, u32 reg, u32 data)
 static void rcar_dmac_chan_clear(struct rcar_dmac *dmac,
 struct rcar_dmac_chan *chan)
 {
-   rcar_dmac_write(dmac, RCAR_DMACHCLR, BIT(chan->index));
+   if (dmac->chan_base)
+   rcar_dmac_chan_write(chan, RCAR_V3U_DMACHCLR, 1);
+   else
+   rcar_dmac_write(dmac, RCAR_DMACHCLR, BIT(chan->index));
 }
 
 static void rcar_dmac_chan_clear_all(struct rcar_dmac *dmac)
 {
-   rcar_dmac_write(dmac, RCAR_DMACHCLR, dmac->channels_mask);
+   struct rcar_dmac_chan *chan;
+   unsigned int i;
+
+   if (dmac->chan_base) {
+   for_each_rcar_dmac_chan(i, chan, dmac)
+   rcar_dmac_chan_write(chan, RCAR_V3U_DMACHCLR, 1);
+   } else {
+   rcar_dmac_write(dmac, RCAR_DMACHCLR, dmac->channels_mask);
+   }
 }
 
 /* 
-
@@ -1744,7 +1760,6 @@ static const struct dev_pm_ops rcar_dmac_pm = {
 
 static int rcar_dmac_chan_probe(struct rcar_dmac *dmac,
struct rcar_dmac_chan *rchan,
-   const struct rcar_dmac_of_data *data,
unsigned int index)
 {
struct platform_device *pdev = to_platform_device(dmac->dev);
@@ -1753,9 +1768,6 @@ static int rcar_dmac_chan_probe(struct rcar_dmac *dmac,
char *irqname;
int ret;
 
-  

Re: [PATCH v6 08/14] mm/gup: do not migrate zero page

[Pavel Tatashin]

On Mon, Jan 25, 2021 at 9:28 AM Jason Gunthorpe  wrote:
>
> On Wed, Jan 20, 2021 at 09:26:41AM -0500, Pavel Tatashin wrote:
>
> > I thought about this, and it would code a little cleaner. But, the
> > reason I did not is because zero_page is perfectly pinnable, it is not
> > pinnable only when it is in a movable zone (and it should not be in a
> > movable zones for other reasons as well), but that is another bug that
> > needs to be resolved, and once that bug is resolved this condition can
> > be removed from gup migration.
>
> My point is you've defined the zero page to be pinnable no matter what
> zone it is in, so is_pinnable(zero_page) == true

Sure, I will move it inside is_pinnable in the next update.

Thank you,
Pasha

>
> Jason

[PATCH RESEND V12 0/8] fuse: Add support for passthrough read/write

[Alessio Balsini]

This is the 12th version of the series, rebased on top of v5.11-rc5.
Please find the changelog at the bottom of this cover letter.

Add support for file system passthrough read/write of files when enabled
in userspace through the option FUSE_PASSTHROUGH.

There are file systems based on FUSE that are intended to enforce
special policies or trigger complicated decision makings at the file
operations level. Android, for example, uses FUSE to enforce
fine-grained access policies that also depend on the file contents.
Sometimes it happens that at open or create time a file is identified as
not requiring additional checks for consequent reads/writes, thus FUSE
would simply act as a passive bridge between the process accessing the
FUSE file system and the lower file system. Splicing and caching help
reduce the FUSE overhead, but there are still read/write operations
forwarded to the userspace FUSE daemon that could be avoided.

This series has been inspired by the original patches from Nikhilesh
Reddy, the idea and code of which has been elaborated and improved
thanks to the community support.

When the FUSE_PASSTHROUGH capability is enabled, the FUSE daemon may
decide while handling the open/create operations, if the given file can
be accessed in passthrough mode. This means that all the further read
and write operations would be forwarded by the kernel directly to the
lower file system using the VFS layer rather than to the FUSE daemon.
All the requests other than reads or writes are still handled by the
userspace FUSE daemon.
This allows for improved performance on reads and writes, especially in
the case of reads at random offsets, for which no (readahead) caching
mechanism would help.
Benchmarks show improved performance that is close to native file system
access when doing massive manipulations on a single opened file,
especially in the case of random reads, random writes and sequential
writes. Detailed benchmarking results are presented below.

The creation of this direct connection (passthrough) between FUSE file
objects and file objects in the lower file system happens in a way that
reminds of passing file descriptors via sockets:
- a process requests the opening of a file handled by FUSE, so the
  kernel forwards the request to the FUSE daemon;
- the FUSE daemon opens the target file in the lower file system,
  getting its file descriptor;
- the FUSE daemon also decides according to its internal policies if
  passthrough can be enabled for that file, and, if so, can perform a
  FUSE_DEV_IOC_PASSTHROUGH_OPEN ioctl on /dev/fuse, passing the file
  descriptor obtained at the previous step and the fuse_req unique
  identifier;
- the kernel translates the file descriptor to the file pointer
  navigating through the opened files of the "current" process and
  temporarily stores it in the associated open/create fuse_req's
  passthrough_filp;
- when the FUSE daemon has done with the request and it's time for the
  kernel to close it, it checks if the passthrough_filp is available and
in case updates the additional field in the fuse_file owned by the
process accessing the FUSE file system.
>From now on, all the read/write operations performed by that process
will be redirected to the corresponding lower file system file by
creating new VFS requests.
Since the read/write operation to the lower file system is executed with
the current process's credentials, it might happen that it does not have
enough privileges to succeed. For this reason, the process temporarily
receives the same credentials as the FUSE daemon, that are reverted as
soon as the read/write operation completes, emulating the behavior of
the request to be performed by the FUSE daemon itself. This solution has
been inspired by the way overlayfs handles read/write operations.
Asynchronous IO is supported as well, handled by creating separate AIO
requests for the lower file system that will be internally tracked by
FUSE, that intercepts and propagates their completion through an
internal ki_completed callback similar to the current implementation of
overlayfs.
Finally, also memory-mapped FUSE files are supported in this FUSE
passthrough series as it has been noticed that when a same file with
FUSE passthrough enabled is accessed both with standard
read/write(-iter) operations and memory-mapped read/write operations,
the file content might result corrupted due to an inconsistency between
the FUSE and lower file system caches.

The ioctl has been designed taking as a reference and trying to converge
to the fuse2 implementation. For example, the fuse_passthrough_out data
structure has extra fields that will allow for further extensions of the
feature.


Performance on RAM block device

What follows has been performed using a custom passthrough_hp FUSE
daemon that enables pass-through for each file that is opened during
both "open" and "create". Benchmarks were run on an Intel Xeon W-2135,
64 GiB of RAM workstation, with a RAM block device used as sto

[PATCH RESEND V12 5/8] fuse: Introduce synchronous read and write for passthrough

[Alessio Balsini]

All the read and write operations performed on fuse_files which have the
passthrough feature enabled are forwarded to the associated lower file
system file via VFS.

Sending the request directly to the lower file system avoids the
userspace round-trip that, because of possible context switches and
additional operations might reduce the overall performance, especially
in those cases where caching doesn't help, for example in reads at
random offsets.

Verifying if a fuse_file has a lower file system file associated with
can be done by checking the validity of its passthrough_filp pointer.
This pointer is not NULL only if passthrough has been successfully
enabled via the appropriate ioctl().
When a read/write operation is requested for a FUSE file with
passthrough enabled, a new equivalent VFS request is generated, which
instead targets the lower file system file.
The VFS layer performs additional checks that allow for safer operations
but may cause the operation to fail if the process accessing the FUSE
file system does not have access to the lower file system.

This change only implements synchronous requests in passthrough,
returning an error in the case of asynchronous operations, yet covering
the majority of the use cases.

Signed-off-by: Alessio Balsini 
---
 fs/fuse/file.c|  8 --
 fs/fuse/fuse_i.h  |  2 ++
 fs/fuse/passthrough.c | 57 +++
 3 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 953f3034c375..cddada1e8bd9 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -1581,7 +1581,9 @@ static ssize_t fuse_file_read_iter(struct kiocb *iocb, 
struct iov_iter *to)
if (FUSE_IS_DAX(inode))
return fuse_dax_read_iter(iocb, to);
 
-   if (!(ff->open_flags & FOPEN_DIRECT_IO))
+   if (ff->passthrough.filp)
+   return fuse_passthrough_read_iter(iocb, to);
+   else if (!(ff->open_flags & FOPEN_DIRECT_IO))
return fuse_cache_read_iter(iocb, to);
else
return fuse_direct_read_iter(iocb, to);
@@ -1599,7 +1601,9 @@ static ssize_t fuse_file_write_iter(struct kiocb *iocb, 
struct iov_iter *from)
if (FUSE_IS_DAX(inode))
return fuse_dax_write_iter(iocb, from);
 
-   if (!(ff->open_flags & FOPEN_DIRECT_IO))
+   if (ff->passthrough.filp)
+   return fuse_passthrough_write_iter(iocb, from);
+   else if (!(ff->open_flags & FOPEN_DIRECT_IO))
return fuse_cache_write_iter(iocb, from);
else
return fuse_direct_write_iter(iocb, from);
diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
index 8d39f5304a11..c4730d893324 100644
--- a/fs/fuse/fuse_i.h
+++ b/fs/fuse/fuse_i.h
@@ -1239,5 +1239,7 @@ int fuse_passthrough_open(struct fuse_dev *fud,
 int fuse_passthrough_setup(struct fuse_conn *fc, struct fuse_file *ff,
   struct fuse_open_out *openarg);
 void fuse_passthrough_release(struct fuse_passthrough *passthrough);
+ssize_t fuse_passthrough_read_iter(struct kiocb *iocb, struct iov_iter *to);
+ssize_t fuse_passthrough_write_iter(struct kiocb *iocb, struct iov_iter *from);
 
 #endif /* _FS_FUSE_I_H */
diff --git a/fs/fuse/passthrough.c b/fs/fuse/passthrough.c
index cf993e83803e..d949ca07a83b 100644
--- a/fs/fuse/passthrough.c
+++ b/fs/fuse/passthrough.c
@@ -4,6 +4,63 @@
 
 #include 
 #include 
+#include 
+
+#define PASSTHROUGH_IOCB_MASK  
\
+   (IOCB_APPEND | IOCB_DSYNC | IOCB_HIPRI | IOCB_NOWAIT | IOCB_SYNC)
+
+static void fuse_copyattr(struct file *dst_file, struct file *src_file)
+{
+   struct inode *dst = file_inode(dst_file);
+   struct inode *src = file_inode(src_file);
+
+   i_size_write(dst, i_size_read(src));
+}
+
+ssize_t fuse_passthrough_read_iter(struct kiocb *iocb_fuse,
+  struct iov_iter *iter)
+{
+   ssize_t ret;
+   struct file *fuse_filp = iocb_fuse->ki_filp;
+   struct fuse_file *ff = fuse_filp->private_data;
+   struct file *passthrough_filp = ff->passthrough.filp;
+
+   if (!iov_iter_count(iter))
+   return 0;
+
+   ret = vfs_iter_read(passthrough_filp, iter, &iocb_fuse->ki_pos,
+   iocb_to_rw_flags(iocb_fuse->ki_flags,
+PASSTHROUGH_IOCB_MASK));
+
+   return ret;
+}
+
+ssize_t fuse_passthrough_write_iter(struct kiocb *iocb_fuse,
+   struct iov_iter *iter)
+{
+   ssize_t ret;
+   struct file *fuse_filp = iocb_fuse->ki_filp;
+   struct fuse_file *ff = fuse_filp->private_data;
+   struct inode *fuse_inode = file_inode(fuse_filp);
+   struct file *passthrough_filp = ff->passthrough.filp;
+
+   if (!iov_iter_count(iter))
+   return 0;
+
+   inode_lock(fuse_inode);
+
+   file_start_write(passthrough_filp);
+   ret = vfs_iter_write(passthrough_filp, i

[PATCH v2 4/7] rbtree, perf: Use new rbtree helpers

[Peter Zijlstra]

Reduce rbtree boiler plate by using the new helpers.

One noteworthy change is unification of the various (partial) compare
functions. We construct a subtree match by forcing the sub-order to
always match, see __group_cmp().

Due to 'const' we had to touch cgroup_id().

Cc: Tejun Heo 
Signed-off-by: Peter Zijlstra (Intel) 
---
 include/linux/cgroup.h |4 
 kernel/events/core.c   |  201 ++---
 2 files changed, 95 insertions(+), 110 deletions(-)

--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -307,7 +307,7 @@ void css_task_iter_end(struct css_task_i
  * Inline functions.
  */
 
-static inline u64 cgroup_id(struct cgroup *cgrp)
+static inline u64 cgroup_id(const struct cgroup *cgrp)
 {
return cgrp->kn->id;
 }
@@ -701,7 +701,7 @@ void cgroup_path_from_kernfs_id(u64 id,
 struct cgroup_subsys_state;
 struct cgroup;
 
-static inline u64 cgroup_id(struct cgroup *cgrp) { return 1; }
+static inline u64 cgroup_id(const struct cgroup *cgrp) { return 1; }
 static inline void css_get(struct cgroup_subsys_state *css) {}
 static inline void css_put(struct cgroup_subsys_state *css) {}
 static inline int cgroup_attach_task_all(struct task_struct *from,
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1575,50 +1575,91 @@ static void perf_event_groups_init(struc
groups->index = 0;
 }
 
+static inline struct cgroup *event_cgroup(const struct perf_event *event)
+{
+   struct cgroup *cgroup = NULL;
+
+#ifdef CONFIG_CGROUP_PERF
+   if (event->cgrp)
+   cgroup = event->cgrp->css.cgroup;
+#endif
+
+   return cgroup;
+}
+
 /*
  * Compare function for event groups;
  *
  * Implements complex key that first sorts by CPU and then by virtual index
  * which provides ordering when rotating groups for the same CPU.
  */
-static bool
-perf_event_groups_less(struct perf_event *left, struct perf_event *right)
-{
-   if (left->cpu < right->cpu)
-   return true;
-   if (left->cpu > right->cpu)
-   return false;
+static __always_inline int
+perf_event_groups_cmp(const int left_cpu, const struct cgroup *left_cgroup,
+ const u64 left_group_index, const struct perf_event 
*right)
+{
+   if (left_cpu < right->cpu)
+   return -1;
+   if (left_cpu > right->cpu)
+   return 1;
 
 #ifdef CONFIG_CGROUP_PERF
-   if (left->cgrp != right->cgrp) {
-   if (!left->cgrp || !left->cgrp->css.cgroup) {
-   /*
-* Left has no cgroup but right does, no cgroups come
-* first.
-*/
-   return true;
-   }
-   if (!right->cgrp || !right->cgrp->css.cgroup) {
-   /*
-* Right has no cgroup but left does, no cgroups come
-* first.
-*/
-   return false;
-   }
-   /* Two dissimilar cgroups, order by id. */
-   if (left->cgrp->css.cgroup->kn->id < 
right->cgrp->css.cgroup->kn->id)
-   return true;
+   {
+   const struct cgroup *right_cgroup = event_cgroup(right);
+
+   if (left_cgroup != right_cgroup) {
+   if (!left_cgroup) {
+   /*
+* Left has no cgroup but right does, no
+* cgroups come first.
+*/
+   return -1;
+   }
+   if (!right_cgroup) {
+   /*
+* Right has no cgroup but left does, no
+* cgroups come first.
+*/
+   return 1;
+   }
+   /* Two dissimilar cgroups, order by id. */
+   if (cgroup_id(left_cgroup) < cgroup_id(right_cgroup))
+   return -1;
 
-   return false;
+   return 1;
+   }
}
 #endif
 
-   if (left->group_index < right->group_index)
-   return true;
-   if (left->group_index > right->group_index)
-   return false;
+   if (left_group_index < right->group_index)
+   return -1;
+   if (left_group_index > right->group_index)
+   return 1;
+
+   return 0;
+}
+
+#define __node_2_pe(node) \
+   rb_entry((node), struct perf_event, group_node)
 
-   return false;
+static inline bool __group_less(struct rb_node *a, const struct rb_node *b)
+{
+   struct perf_event *e = __node_2_pe(a);
+   return perf_event_groups_cmp(e->cpu, event_cgroup(e), e->group_index,
+__node_2_pe(b)) < 0;
+}
+
+struct __group_key {
+   int cpu;
+

[PATCH RESEND V12 2/8] fuse: 32-bit user space ioctl compat for fuse device

[Alessio Balsini]

With a 64-bit kernel build the FUSE device cannot handle ioctl requests
coming from 32-bit user space.
This is due to the ioctl command translation that generates different
command identifiers that thus cannot be used for direct comparisons
without proper manipulation.

Explicitly extract type and number from the ioctl command to enable
32-bit user space compatibility on 64-bit kernel builds.

Signed-off-by: Alessio Balsini 
---
 fs/fuse/dev.c | 29 ++---
 include/uapi/linux/fuse.h |  3 ++-
 2 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 588f8d1240aa..ff9f3b83f879 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -2233,37 +2233,44 @@ static int fuse_device_clone(struct fuse_conn *fc, 
struct file *new)
 static long fuse_dev_ioctl(struct file *file, unsigned int cmd,
   unsigned long arg)
 {
-   int err = -ENOTTY;
+   int res;
+   int oldfd;
+   struct fuse_dev *fud = NULL;
 
-   if (cmd == FUSE_DEV_IOC_CLONE) {
-   int oldfd;
+   if (_IOC_TYPE(cmd) != FUSE_DEV_IOC_MAGIC)
+   return -EINVAL;
 
-   err = -EFAULT;
-   if (!get_user(oldfd, (__u32 __user *) arg)) {
+   switch (_IOC_NR(cmd)) {
+   case _IOC_NR(FUSE_DEV_IOC_CLONE):
+   res = -EFAULT;
+   if (!get_user(oldfd, (__u32 __user *)arg)) {
struct file *old = fget(oldfd);
 
-   err = -EINVAL;
+   res = -EINVAL;
if (old) {
-   struct fuse_dev *fud = NULL;
-
/*
 * Check against file->f_op because CUSE
 * uses the same ioctl handler.
 */
if (old->f_op == file->f_op &&
-   old->f_cred->user_ns == 
file->f_cred->user_ns)
+   old->f_cred->user_ns ==
+   file->f_cred->user_ns)
fud = fuse_get_dev(old);
 
if (fud) {
mutex_lock(&fuse_mutex);
-   err = fuse_device_clone(fud->fc, file);
+   res = fuse_device_clone(fud->fc, file);
mutex_unlock(&fuse_mutex);
}
fput(old);
}
}
+   break;
+   default:
+   res = -ENOTTY;
+   break;
}
-   return err;
+   return res;
 }
 
 const struct file_operations fuse_dev_operations = {
diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
index 98ca64d1beb6..54442612c48b 100644
--- a/include/uapi/linux/fuse.h
+++ b/include/uapi/linux/fuse.h
@@ -903,7 +903,8 @@ struct fuse_notify_retrieve_in {
 };
 
 /* Device ioctls: */
-#define FUSE_DEV_IOC_CLONE _IOR(229, 0, uint32_t)
+#define FUSE_DEV_IOC_MAGIC 229
+#define FUSE_DEV_IOC_CLONE _IOR(FUSE_DEV_IOC_MAGIC, 0, uint32_t)
 
 struct fuse_lseek_in {
uint64_tfh;
-- 
2.30.0.280.ga3ce27912f-goog

Re: [PATCH v2 2/2] thermal: Move therm_throt there from x86/mce

[Zhang Rui]

Hi, Borislav,

Thanks for the patch. CC Srinivas.

On Mon, 2021-01-25 at 14:05 +0100, Borislav Petkov wrote:
> From: Borislav Petkov 
> 
> This functionality has nothing to do with MCE, move it to the thermal
> framework and untangle it from MCE.
> 
Agreed.

just one question,
there are many overlaps between this kernel thermal throttling code and
the x86_pkg_temp_thermal driver, is it possible to combine these two
pieces of code altogether?

thanks,
rui


> Have thermal_set_handler() check the build-time assigned default
> handler
> stub was the one used before therm_throt assigns a new one.
> 

> Requested-by: Peter Zijlstra 
> Signed-off-by: Borislav Petkov 
> ---
>  arch/x86/Kconfig  |  4 ---
>  arch/x86/include/asm/irq.h|  4 +++
>  arch/x86/include/asm/mce.h| 16 --
>  arch/x86/include/asm/thermal.h| 21 ++
>  arch/x86/kernel/cpu/intel.c   |  3 ++
>  arch/x86/kernel/cpu/mce/Makefile  |  2 --
>  arch/x86/kernel/cpu/mce/intel.c   |  1 -
>  arch/x86/kernel/irq.c | 29
> +++
>  drivers/thermal/intel/Kconfig |  4 +++
>  drivers/thermal/intel/Makefile|  1 +
>  .../thermal/intel}/therm_throt.c  | 25 ++--
>  drivers/thermal/intel/x86_pkg_temp_thermal.c  |  3 +-
>  12 files changed, 67 insertions(+), 46 deletions(-)
>  create mode 100644 arch/x86/include/asm/thermal.h
>  rename {arch/x86/kernel/cpu/mce =>
> drivers/thermal/intel}/therm_throt.c (97%)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 21f851179ff0..9989db3a9bf5 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1158,10 +1158,6 @@ config X86_MCE_INJECT
> If you don't know what a machine check is and you don't do
> kernel
> QA it is safe to say n.
>  
> -config X86_THERMAL_VECTOR
> - def_bool y
> - depends on X86_MCE_INTEL
> -
>  source "arch/x86/events/Kconfig"
>  
>  config X86_LEGACY_VM86
> diff --git a/arch/x86/include/asm/irq.h b/arch/x86/include/asm/irq.h
> index 528c8a71fe7f..ad65fe7dceb1 100644
> --- a/arch/x86/include/asm/irq.h
> +++ b/arch/x86/include/asm/irq.h
> @@ -53,4 +53,8 @@ void arch_trigger_cpumask_backtrace(const struct
> cpumask *mask,
>  #define arch_trigger_cpumask_backtrace
> arch_trigger_cpumask_backtrace
>  #endif
>  
> +#ifdef CONFIG_X86_THERMAL_VECTOR
> +void thermal_set_handler(void (*handler)(void));
> +#endif
> +
>  #endif /* _ASM_X86_IRQ_H */
> diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
> index def9aa5e1fa4..ddfb3cad8dff 100644
> --- a/arch/x86/include/asm/mce.h
> +++ b/arch/x86/include/asm/mce.h
> @@ -288,22 +288,6 @@ extern void (*mce_threshold_vector)(void);
>  /* Deferred error interrupt handler */
>  extern void (*deferred_error_int_vector)(void);
>  
> -/*
> - * Thermal handler
> - */
> -
> -void intel_init_thermal(struct cpuinfo_x86 *c);
> -
> -/* Interrupt Handler for core thermal thresholds */
> -extern int (*platform_thermal_notify)(__u64 msr_val);
> -
> -/* Interrupt Handler for package thermal thresholds */
> -extern int (*platform_thermal_package_notify)(__u64 msr_val);
> -
> -/* Callback support of rate control, return true, if
> - * callback has rate control */
> -extern bool (*platform_thermal_package_rate_control)(void);
> -
>  /*
>   * Used by APEI to report memory error via /dev/mcelog
>   */
> diff --git a/arch/x86/include/asm/thermal.h
> b/arch/x86/include/asm/thermal.h
> new file mode 100644
> index ..58b0e0a4af6e
> --- /dev/null
> +++ b/arch/x86/include/asm/thermal.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_X86_THERMAL_H
> +#define _ASM_X86_THERMAL_H
> +
> +/* Interrupt Handler for package thermal thresholds */
> +extern int (*platform_thermal_package_notify)(__u64 msr_val);
> +
> +/* Interrupt Handler for core thermal thresholds */
> +extern int (*platform_thermal_notify)(__u64 msr_val);
> +
> +/* Callback support of rate control, return true, if
> + * callback has rate control */
> +extern bool (*platform_thermal_package_rate_control)(void);
> +
> +#ifdef CONFIG_X86_THERMAL_VECTOR
> +void intel_init_thermal(struct cpuinfo_x86 *c);
> +#else
> +static inline void intel_init_thermal(struct cpuinfo_x86 *c) { }
> +#endif
> +
> +#endif /* _ASM_X86_THERMAL_H */
> diff --git a/arch/x86/kernel/cpu/intel.c
> b/arch/x86/kernel/cpu/intel.c
> index 59a1e3ce3f14..71221af87cb1 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_X86_64
>  #include 
> @@ -719,6 +720,8 @@ static void init_intel(struct cpuinfo_x86 *c)
>   tsx_disable();
>  
>   split_lock_init();
> +
> + intel_init_thermal(c);
>  }
>  
>  #ifdef CONFIG_X86_32
> diff --git a/arch/x86/kernel/cpu/mce/Makefile
> b/arch/x86/kernel/cpu/mce/Makefile
> index 9f020

[PATCH RESEND V12 6/8] fuse: Handle asynchronous read and write in passthrough

[Alessio Balsini]

Extend the passthrough feature by handling asynchronous IO both for read
and write operations.

When an AIO request is received, if the request targets a FUSE file with
the passthrough functionality enabled, a new identical AIO request is
created. The new request targets the lower file system file and gets
assigned a special FUSE passthrough AIO completion callback.
When the lower file system AIO request is completed, the FUSE
passthrough AIO completion callback is executed and propagates the
completion signal to the FUSE AIO request by triggering its completion
callback as well.

Signed-off-by: Alessio Balsini 
---
 fs/fuse/passthrough.c | 89 +--
 1 file changed, 78 insertions(+), 11 deletions(-)

diff --git a/fs/fuse/passthrough.c b/fs/fuse/passthrough.c
index d949ca07a83b..c7fa1eeb7639 100644
--- a/fs/fuse/passthrough.c
+++ b/fs/fuse/passthrough.c
@@ -9,6 +9,11 @@
 #define PASSTHROUGH_IOCB_MASK  
\
(IOCB_APPEND | IOCB_DSYNC | IOCB_HIPRI | IOCB_NOWAIT | IOCB_SYNC)
 
+struct fuse_aio_req {
+   struct kiocb iocb;
+   struct kiocb *iocb_fuse;
+};
+
 static void fuse_copyattr(struct file *dst_file, struct file *src_file)
 {
struct inode *dst = file_inode(dst_file);
@@ -17,6 +22,32 @@ static void fuse_copyattr(struct file *dst_file, struct file 
*src_file)
i_size_write(dst, i_size_read(src));
 }
 
+static void fuse_aio_cleanup_handler(struct fuse_aio_req *aio_req)
+{
+   struct kiocb *iocb = &aio_req->iocb;
+   struct kiocb *iocb_fuse = aio_req->iocb_fuse;
+
+   if (iocb->ki_flags & IOCB_WRITE) {
+   __sb_writers_acquired(file_inode(iocb->ki_filp)->i_sb,
+ SB_FREEZE_WRITE);
+   file_end_write(iocb->ki_filp);
+   fuse_copyattr(iocb_fuse->ki_filp, iocb->ki_filp);
+   }
+
+   iocb_fuse->ki_pos = iocb->ki_pos;
+   kfree(aio_req);
+}
+
+static void fuse_aio_rw_complete(struct kiocb *iocb, long res, long res2)
+{
+   struct fuse_aio_req *aio_req =
+   container_of(iocb, struct fuse_aio_req, iocb);
+   struct kiocb *iocb_fuse = aio_req->iocb_fuse;
+
+   fuse_aio_cleanup_handler(aio_req);
+   iocb_fuse->ki_complete(iocb_fuse, res, res2);
+}
+
 ssize_t fuse_passthrough_read_iter(struct kiocb *iocb_fuse,
   struct iov_iter *iter)
 {
@@ -28,9 +59,24 @@ ssize_t fuse_passthrough_read_iter(struct kiocb *iocb_fuse,
if (!iov_iter_count(iter))
return 0;
 
-   ret = vfs_iter_read(passthrough_filp, iter, &iocb_fuse->ki_pos,
-   iocb_to_rw_flags(iocb_fuse->ki_flags,
-PASSTHROUGH_IOCB_MASK));
+   if (is_sync_kiocb(iocb_fuse)) {
+   ret = vfs_iter_read(passthrough_filp, iter, &iocb_fuse->ki_pos,
+   iocb_to_rw_flags(iocb_fuse->ki_flags,
+PASSTHROUGH_IOCB_MASK));
+   } else {
+   struct fuse_aio_req *aio_req;
+
+   aio_req = kmalloc(sizeof(struct fuse_aio_req), GFP_KERNEL);
+   if (!aio_req)
+   return -ENOMEM;
+
+   aio_req->iocb_fuse = iocb_fuse;
+   kiocb_clone(&aio_req->iocb, iocb_fuse, passthrough_filp);
+   aio_req->iocb.ki_complete = fuse_aio_rw_complete;
+   ret = call_read_iter(passthrough_filp, &aio_req->iocb, iter);
+   if (ret != -EIOCBQUEUED)
+   fuse_aio_cleanup_handler(aio_req);
+   }
 
return ret;
 }
@@ -43,20 +89,41 @@ ssize_t fuse_passthrough_write_iter(struct kiocb *iocb_fuse,
struct fuse_file *ff = fuse_filp->private_data;
struct inode *fuse_inode = file_inode(fuse_filp);
struct file *passthrough_filp = ff->passthrough.filp;
+   struct inode *passthrough_inode = file_inode(passthrough_filp);
 
if (!iov_iter_count(iter))
return 0;
 
inode_lock(fuse_inode);
 
-   file_start_write(passthrough_filp);
-   ret = vfs_iter_write(passthrough_filp, iter, &iocb_fuse->ki_pos,
-iocb_to_rw_flags(iocb_fuse->ki_flags,
- PASSTHROUGH_IOCB_MASK));
-   file_end_write(passthrough_filp);
-   if (ret > 0)
-   fuse_copyattr(fuse_filp, passthrough_filp);
-
+   if (is_sync_kiocb(iocb_fuse)) {
+   file_start_write(passthrough_filp);
+   ret = vfs_iter_write(passthrough_filp, iter, &iocb_fuse->ki_pos,
+iocb_to_rw_flags(iocb_fuse->ki_flags,
+ PASSTHROUGH_IOCB_MASK));
+   file_end_write(passthrough_filp);
+   if (ret > 0)
+   fuse_copyattr(fuse_filp, passthrough_filp);
+   } else {
+   struct fuse_ai

[PATCH v4 17/21] dt-bindings: usb: sunxi-musb: Add H616 compatible string

[Andre Przywara]

The H616 MUSB peripheral is presumably compatible to the H3 one.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 .../devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml  | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml 
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
index d9207bf9d894..ad8983debeba 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
@@ -22,6 +22,9 @@ properties:
   - allwinner,sun8i-a83t-musb
   - allwinner,sun50i-h6-musb
   - const: allwinner,sun8i-a33-musb
+  - items:
+  - const: allwinner,sun50i-h616-musb
+  - const: allwinner,sun8i-h3-musb
 
   reg:
 maxItems: 1
-- 
2.17.5

Re: [PATCH] mm/filemap: Adding missing mem_cgroup_uncharge() to __add_to_page_cache_locked()

[Waiman Long]

On 1/25/21 3:07 AM, Muchun Song wrote:

On Mon, Jan 25, 2021 at 12:29 PM Waiman Long  wrote:

The commit 3fea5a499d57 ("mm: memcontrol: convert page
cache to a new mem_cgroup_charge() API") introduced a bug in
__add_to_page_cache_locked() causing the following splat:

  [ 1570.068330] page dumped because: VM_BUG_ON_PAGE(page_memcg(page))
  [ 1570.068333] pages's memcg:8889a4116000
  [ 1570.068343] [ cut here ]
  [ 1570.068346] kernel BUG at mm/memcontrol.c:2924!
  [ 1570.068355] invalid opcode:  [#1] SMP KASAN PTI
  [ 1570.068359] CPU: 35 PID: 12345 Comm: cat Tainted: G S  W I   
5.11.0-rc4-debug+ #1
  [ 1570.068363] Hardware name: HP HP Z8 G4 Workstation/81C7, BIOS P60 v01.25 
12/06/2017
  [ 1570.068365] RIP: 0010:commit_charge+0xf4/0x130
:
  [ 1570.068375] RSP: 0018:8881b38d70e8 EFLAGS: 00010286
  [ 1570.068379] RAX:  RBX: ea00260ddd00 RCX: 
0027
  [ 1570.068382] RDX:  RSI: 0004 RDI: 
88907ebe05a8
  [ 1570.068384] RBP: ea00260ddd00 R08: ed120fd7c0b6 R09: 
ed120fd7c0b6
  [ 1570.068386] R10: 88907ebe05ab R11: ed120fd7c0b5 R12: 
ea00260ddd38
  [ 1570.068389] R13: 8889a4116000 R14: 8889a4116000 R15: 
0001
  [ 1570.068391] FS:  7ff039638680() GS:88907ea0() 
knlGS:
  [ 1570.068394] CS:  0010 DS:  ES:  CR0: 80050033
  [ 1570.068396] CR2: 7f36f354cc20 CR3: 0008a0126006 CR4: 
007706e0
  [ 1570.068398] DR0:  DR1:  DR2: 

  [ 1570.068400] DR3:  DR6: fffe0ff0 DR7: 
0400
  [ 1570.068402] PKRU: 5554
  [ 1570.068404] Call Trace:
  [ 1570.068407]  mem_cgroup_charge+0x175/0x770
  [ 1570.068413]  __add_to_page_cache_locked+0x712/0xad0
  [ 1570.068439]  add_to_page_cache_lru+0xc5/0x1f0
  [ 1570.068461]  cachefiles_read_or_alloc_pages+0x895/0x2e10 [cachefiles]
  [ 1570.068524]  __fscache_read_or_alloc_pages+0x6c0/0xa00 [fscache]
  [ 1570.068540]  __nfs_readpages_from_fscache+0x16d/0x630 [nfs]
  [ 1570.068585]  nfs_readpages+0x24e/0x540 [nfs]
  [ 1570.068693]  read_pages+0x5b1/0xc40
  [ 1570.068711]  page_cache_ra_unbounded+0x460/0x750
  [ 1570.068729]  generic_file_buffered_read_get_pages+0x290/0x1710
  [ 1570.068756]  generic_file_buffered_read+0x2a9/0xc30
  [ 1570.068832]  nfs_file_read+0x13f/0x230 [nfs]
  [ 1570.068872]  new_sync_read+0x3af/0x610
  [ 1570.068901]  vfs_read+0x339/0x4b0
  [ 1570.068909]  ksys_read+0xf1/0x1c0
  [ 1570.068920]  do_syscall_64+0x33/0x40
  [ 1570.068926]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
  [ 1570.068930] RIP: 0033:0x7ff039135595

Before that commit, there was a try_charge() and commit_charge()
in __add_to_page_cache_locked(). These 2 separated charge functions
were replaced by a single mem_cgroup_charge(). However, it forgot
to add a matching mem_cgroup_uncharge() when the xarray insertion
failed with the page released back to the pool. Fix this by adding a
mem_cgroup_uncharge() call when insertion error happens.

Fixes: 3fea5a499d57 ("mm: memcontrol: convert page cache to a new 
mem_cgroup_charge() API")
Signed-off-by: Waiman Long 
---
  mm/filemap.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/mm/filemap.c b/mm/filemap.c
index 5c9d564317a5..aa0e0fb04670 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -835,6 +835,7 @@ noinline int __add_to_page_cache_locked(struct page *page,
 XA_STATE(xas, &mapping->i_pages, offset);
 int huge = PageHuge(page);
 int error;
+   bool charged = false;

 VM_BUG_ON_PAGE(!PageLocked(page), page);
 VM_BUG_ON_PAGE(PageSwapBacked(page), page);
@@ -848,6 +849,7 @@ noinline int __add_to_page_cache_locked(struct page *page,
 error = mem_cgroup_charge(page, current->mm, gfp);
 if (error)
 goto error;
+   charged = true;
 }

 gfp &= GFP_RECLAIM_MASK;
@@ -896,6 +898,8 @@ noinline int __add_to_page_cache_locked(struct page *page,

 if (xas_error(&xas)) {
 error = xas_error(&xas);
+   if (charged)

Can "if (!huge)" replace "if (charged)"?


See my reply to Mathew Wilcox.

Cheers,
Longman

[PATCH v4 02/21] clk: sunxi-ng: Add support for the Allwinner H616 R-CCU

[Andre Przywara]

The clocks itself are identical to the H6 R-CCU, it's just that the H616
has not all of them implemented (or connected).

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/Kconfig   |  2 +-
 drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 48 ++
 2 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index ce5f5847d5d3..feeb8d2074ee 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -33,7 +33,7 @@ config SUN50I_H6_CCU
depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
 
 config SUN50I_H6_R_CCU
-   bool "Support for the Allwinner H6 PRCM CCU"
+   bool "Support for the Allwinner H6 and H616 PRCM CCU"
default ARM64 && ARCH_SUNXI
depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
 
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
index 56e351b513f3..f8909a7ed553 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
@@ -139,6 +139,16 @@ static struct ccu_common *sun50i_h6_r_ccu_clks[] = {
&w1_clk.common,
 };
 
+static struct ccu_common *sun50i_h616_r_ccu_clks[] = {
+   &r_apb1_clk.common,
+   &r_apb2_clk.common,
+   &r_apb1_twd_clk.common,
+   &r_apb2_i2c_clk.common,
+   &r_apb2_rsb_clk.common,
+   &r_apb1_ir_clk.common,
+   &ir_clk.common,
+};
+
 static struct clk_hw_onecell_data sun50i_h6_r_hw_clks = {
.hws= {
[CLK_AR100] = &ar100_clk.common.hw,
@@ -159,6 +169,20 @@ static struct clk_hw_onecell_data sun50i_h6_r_hw_clks = {
.num= CLK_NUMBER,
 };
 
+static struct clk_hw_onecell_data sun50i_h616_r_hw_clks = {
+   .hws= {
+   [CLK_R_AHB] = &r_ahb_clk.hw,
+   [CLK_R_APB1]= &r_apb1_clk.common.hw,
+   [CLK_R_APB2]= &r_apb2_clk.common.hw,
+   [CLK_R_APB1_TWD]= &r_apb1_twd_clk.common.hw,
+   [CLK_R_APB2_I2C]= &r_apb2_i2c_clk.common.hw,
+   [CLK_R_APB2_RSB]= &r_apb2_rsb_clk.common.hw,
+   [CLK_R_APB1_IR] = &r_apb1_ir_clk.common.hw,
+   [CLK_IR]= &ir_clk.common.hw,
+   },
+   .num= CLK_NUMBER,
+};
+
 static struct ccu_reset_map sun50i_h6_r_ccu_resets[] = {
[RST_R_APB1_TIMER]  =  { 0x11c, BIT(16) },
[RST_R_APB1_TWD]=  { 0x12c, BIT(16) },
@@ -170,6 +194,13 @@ static struct ccu_reset_map sun50i_h6_r_ccu_resets[] = {
[RST_R_APB1_W1] =  { 0x1ec, BIT(16) },
 };
 
+static struct ccu_reset_map sun50i_h616_r_ccu_resets[] = {
+   [RST_R_APB1_TWD]=  { 0x12c, BIT(16) },
+   [RST_R_APB2_I2C]=  { 0x19c, BIT(16) },
+   [RST_R_APB2_RSB]=  { 0x1bc, BIT(16) },
+   [RST_R_APB1_IR] =  { 0x1cc, BIT(16) },
+};
+
 static const struct sunxi_ccu_desc sun50i_h6_r_ccu_desc = {
.ccu_clks   = sun50i_h6_r_ccu_clks,
.num_ccu_clks   = ARRAY_SIZE(sun50i_h6_r_ccu_clks),
@@ -180,6 +211,16 @@ static const struct sunxi_ccu_desc sun50i_h6_r_ccu_desc = {
.num_resets = ARRAY_SIZE(sun50i_h6_r_ccu_resets),
 };
 
+static const struct sunxi_ccu_desc sun50i_h616_r_ccu_desc = {
+   .ccu_clks   = sun50i_h616_r_ccu_clks,
+   .num_ccu_clks   = ARRAY_SIZE(sun50i_h616_r_ccu_clks),
+
+   .hw_clks= &sun50i_h616_r_hw_clks,
+
+   .resets = sun50i_h616_r_ccu_resets,
+   .num_resets = ARRAY_SIZE(sun50i_h616_r_ccu_resets),
+};
+
 static void __init sunxi_r_ccu_init(struct device_node *node,
const struct sunxi_ccu_desc *desc)
 {
@@ -200,3 +241,10 @@ static void __init sun50i_h6_r_ccu_setup(struct 
device_node *node)
 }
 CLK_OF_DECLARE(sun50i_h6_r_ccu, "allwinner,sun50i-h6-r-ccu",
   sun50i_h6_r_ccu_setup);
+
+static void __init sun50i_h616_r_ccu_setup(struct device_node *node)
+{
+   sunxi_r_ccu_init(node, &sun50i_h616_r_ccu_desc);
+}
+CLK_OF_DECLARE(sun50i_h616_r_ccu, "allwinner,sun50i-h616-r-ccu",
+  sun50i_h616_r_ccu_setup);
-- 
2.17.5

Re: [PATCH 1/2] x86/setup: consolidate early memory reservations

[Mike Rapoport]

On Mon, Jan 25, 2021 at 03:50:41PM +0100, Borislav Petkov wrote:
> On Fri, Jan 15, 2021 at 10:32:54AM +0200, Mike Rapoport wrote:
> > From: Mike Rapoport 
> > 
> > The early reservations of memory areas used by the firmware, bootloader,
> > kernel text and data are spread over setup_arch(). Moreover, some of them
> > happen *after* memblock allocations, e.g trim_platform_memory_ranges() and
> > trim_low_memory_range() are called after reserve_real_mode() that allocates
> > memory.
> > 
> > We did not observe corruption of these memory regions because memblock
> 
> Make that "We" impersonal, passive voice pls.

Ok.
 
> > always allocates memory either from the end of memory (in top-down mode) or
> > above the kernel image (in bottom-up mode). However, the bottom up mode is
> > going to be updated to span the entire memory [1] to avoid limitations
> > caused by KASLR.
> > 
> > Consolidate early memory reservations in a dedicated function to improve
> > robustness against future changes. Having the early reservations in one
> > place also makes it clearer what memory must be reserved before we allow
> > memblock allocations.
> 
> Would it make sense to have a check with a WARN or so to catch early
> reservations which get added after memblock allocations have been
> allowed? To catch people who don't pay attention...

This would make sense but it's tricky. From memblock perspective,
allocations are always allowed and it is the user responsibility to ensure
all the early reservations are done before allocating memory.

So adding such a WARN would require a new memblock API and it's adoption by
all architectures, which is way beyond the scope of this series :)

-- 
Sincerely yours,
Mike.

[PATCH v4 03/21] clk: sunxi-ng: Add support for the Allwinner H616 CCU

[Andre Przywara]

While the clocks are fairly similar to the H6, many differ in tiny
details, so a separate clock driver seems indicated.

Derived from the H6 clock driver, and adjusted according to the manual.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/Kconfig|5 +
 drivers/clk/sunxi-ng/Makefile   |1 +
 drivers/clk/sunxi-ng/ccu-sun50i-h616.c  | 1150 +++
 drivers/clk/sunxi-ng/ccu-sun50i-h616.h  |   56 +
 include/dt-bindings/clock/sun50i-h616-ccu.h |  115 ++
 include/dt-bindings/reset/sun50i-h616-ccu.h |   70 ++
 6 files changed, 1397 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.h
 create mode 100644 include/dt-bindings/clock/sun50i-h616-ccu.h
 create mode 100644 include/dt-bindings/reset/sun50i-h616-ccu.h

diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index feeb8d2074ee..cd46d8853876 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -32,6 +32,11 @@ config SUN50I_H6_CCU
default ARM64 && ARCH_SUNXI
depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
 
+config SUN50I_H616_CCU
+   bool "Support for the Allwinner H616 CCU"
+   default ARM64 && ARCH_SUNXI
+   depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
+
 config SUN50I_H6_R_CCU
bool "Support for the Allwinner H6 and H616 PRCM CCU"
default ARM64 && ARCH_SUNXI
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 3eb5cff40eac..96c324306d97 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_SUN50I_A64_CCU)  += ccu-sun50i-a64.o
 obj-$(CONFIG_SUN50I_A100_CCU)  += ccu-sun50i-a100.o
 obj-$(CONFIG_SUN50I_A100_R_CCU)+= ccu-sun50i-a100-r.o
 obj-$(CONFIG_SUN50I_H6_CCU)+= ccu-sun50i-h6.o
+obj-$(CONFIG_SUN50I_H616_CCU)  += ccu-sun50i-h616.o
 obj-$(CONFIG_SUN50I_H6_R_CCU)  += ccu-sun50i-h6-r.o
 obj-$(CONFIG_SUN4I_A10_CCU)+= ccu-sun4i-a10.o
 obj-$(CONFIG_SUN5I_CCU)+= ccu-sun5i.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
new file mode 100644
index ..225307305880
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
@@ -0,0 +1,1150 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 Arm Ltd.
+ * Based on the H6 CCU driver, which is:
+ *   Copyright (c) 2017 Icenowy Zheng 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "ccu_common.h"
+#include "ccu_reset.h"
+
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_mp.h"
+#include "ccu_mult.h"
+#include "ccu_nk.h"
+#include "ccu_nkm.h"
+#include "ccu_nkmp.h"
+#include "ccu_nm.h"
+
+#include "ccu-sun50i-h616.h"
+
+/*
+ * The CPU PLL is actually NP clock, with P being /1, /2 or /4. However
+ * P should only be used for output frequencies lower than 288 MHz.
+ *
+ * For now we can just model it as a multiplier clock, and force P to /1.
+ *
+ * The M factor is present in the register's description, but not in the
+ * frequency formula, and it's documented as "M is only used for backdoor
+ * testing", so it's not modelled and then force to 0.
+ */
+#define SUN50I_H616_PLL_CPUX_REG   0x000
+static struct ccu_mult pll_cpux_clk = {
+   .enable = BIT(31),
+   .lock   = BIT(28),
+   .mult   = _SUNXI_CCU_MULT_MIN(8, 8, 12),
+   .common = {
+   .reg= 0x000,
+   .hw.init= CLK_HW_INIT("pll-cpux", "osc24M",
+ &ccu_mult_ops,
+ CLK_SET_RATE_UNGATE),
+   },
+};
+
+/* Some PLLs are input * N / div1 / P. Model them as NKMP with no K */
+#define SUN50I_H616_PLL_DDR0_REG   0x010
+static struct ccu_nkmp pll_ddr0_clk = {
+   .enable = BIT(31),
+   .lock   = BIT(28),
+   .n  = _SUNXI_CCU_MULT_MIN(8, 8, 12),
+   .m  = _SUNXI_CCU_DIV(1, 1), /* input divider */
+   .p  = _SUNXI_CCU_DIV(0, 1), /* output divider */
+   .common = {
+   .reg= 0x010,
+   .hw.init= CLK_HW_INIT("pll-ddr0", "osc24M",
+ &ccu_nkmp_ops,
+ CLK_SET_RATE_UNGATE),
+   },
+};
+
+#define SUN50I_H616_PLL_DDR1_REG   0x018
+static struct ccu_nkmp pll_ddr1_clk = {
+   .enable = BIT(31),
+   .lock   = BIT(28),
+   .n  = _SUNXI_CCU_MULT_MIN(8, 8, 12),
+   .m  = _SUNXI_CCU_DIV(1, 1), /* input divider */
+   .p  = _SUNXI_CCU_DIV(0, 1), /* output divider */
+   .common = {
+   .reg= 0x018,
+   .hw.init= CLK_HW_INIT("pll-ddr1", "osc24M",
+ &cc

[PATCH v4 07/21] dt-bindings: sram: sunxi-sram: Add H616 compatible string

[Andre Przywara]

The H616 adds a second EMAC clock register. We don't know about the
exact SRAM properties yet, so this gets omitted for now.

Signed-off-by: Andre Przywara 
Acked-by: Rob Herring 
---
 .../bindings/sram/allwinner,sun4i-a10-system-control.yaml| 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
 
b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
index b66a07e21d1e..1c426c211e36 100644
--- 
a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
+++ 
b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
@@ -49,6 +49,7 @@ properties:
   - items:
   - const: allwinner,suniv-f1c100s-system-control
   - const: allwinner,sun4i-a10-system-control
+  - const: allwinner,sun50i-h616-system-control
 
   reg:
 maxItems: 1
-- 
2.17.5

[PATCH v4 05/21] Input: axp20x-pek: Bail out if AXP has no interrupt line connected

[Andre Przywara]

On at least one board (Orangepi Zero2) the AXP305 PMIC does not have its
interrupt line connected to the CPU (mostly because the H616 SoC does
not feature an NMI pin anymore).
After allowing the AXP driver to proceed without an "interrupts"
property [1], the axp20x-pek driver crashes with a NULL pointer
dereference (see below).

Check for the regmap_irqc member to be not NULL before proceeding with
probe. This gets normally filled by the call to regmap_add_irq_chip(),
which we allow to skip now, when the DT node lacks an interrupt
property.


[3.843388] sunxi-rsb 7083000.rsb: RSB running at 300 Hz
[3.849972] axp20x-rsb sunxi-rsb-745: AXP20x variant AXP806 found
[3.857971] Unable to handle kernel NULL pointer dereference at
virtual address 01b8
[3.866855] Mem abort info:
[3.869691]   ESR = 0x9604
[3.872749]   EC = 0x25: DABT (current EL), IL = 32 bits
[3.878092]   SET = 0, FnV = 0
[3.881149]   EA = 0, S1PTW = 0
[3.884309] Data abort info:
[3.887210]   ISV = 0, ISS = 0x0004
[3.891062]   CM = 0, WnR = 0
[3.894049] [01b8] user address but active_mm is swapper
[3.900590] Internal error: Oops: 9604 [#1] PREEMPT SMP
[3.906166] Modules linked in:
[3.909227] CPU: 2 PID: 34 Comm: kworker/2:1 Not tainted 5.11.0-rc1
[3.915925] Hardware name: OrangePi Zero2 (DT)
[3.920367] Workqueue: events deferred_probe_work_func
[3.925518] pstate: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
[3.931522] pc : regmap_irq_get_virq+0x0/0x48
[3.935883] lr : axp20x_pek_probe+0x78/0x200
[3.940147] sp : 800012fdb450
[3.943459] x29: 800012fdb450 x28: 054af340
[3.948776] x27: 05534000 x26: 05534810
[3.954091] x25: 800012883028 x24: 0002
[3.959407] x23: 80001157eaf0 x22: 05534810
[3.964722] x21: 05534800 x20: 054b0580
[3.970037] x19: 000b x18: 
[3.975353] x17: 0001 x16: 0019
[3.980668] x15: 02ce4ea04ae6 x14: 014f
[3.985983] x13: 0282 x12: 0030
[3.991298] x11: 0038 x10: 0101010101010101
[3.996613] x9 :  x8 : 7f7f7f7f7f7f7f7f
[4.001928] x7 : ff5141435e4a444f x6 : 0080
[4.007243] x5 :  x4 : 8000
[4.012558] x3 :  x2 : 
[4.017872] x1 : 000b x0 : 
[4.023188] Call trace:
[4.025635]  regmap_irq_get_virq+0x0/0x48
[4.029646]  platform_probe+0x68/0xd8
[4.033312]  really_probe+0xe4/0x3b0
[4.036889]  driver_probe_device+0x58/0xb8
[4.040986]  __device_attach_driver+0x84/0xc8
[4.045342]  bus_for_each_drv+0x78/0xc8
[4.049178]  __device_attach+0xf0/0x150
[4.053013]  device_initial_probe+0x14/0x20
[4.057196]  bus_probe_device+0x9c/0xa8
[4.061032]  device_add+0x36c/0x7b8
[4.064525]  platform_device_add+0x100/0x238
[4.068796]  mfd_add_devices+0x494/0x718
[4.072721]  axp20x_device_probe+0x70/0x158
[4.076904]  axp20x_rsb_probe+0x94/0xd0
[4.080741]  sunxi_rsb_device_probe+0x6c/0x88
[4.085102]  really_probe+0xe4/0x3b0
[4.088679]  driver_probe_device+0x58/0xb8
[4.092776]  __device_attach_driver+0x84/0xc8
[4.097132]  bus_for_each_drv+0x78/0xc8
[4.100967]  __device_attach+0xf0/0x150
[4.104803]  device_initial_probe+0x14/0x20
[4.108986]  bus_probe_device+0x9c/0xa8
[4.112821]  device_add+0x36c/0x7b8
[4.116313]  device_register+0x20/0x30
[4.120065]  sunxi_rsb_probe+0x4e4/0x608


[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2021-January/633392.html

Signed-off-by: Andre Przywara 
---
 drivers/input/misc/axp20x-pek.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
index 9c6386b2af33..abe52ef194ee 100644
--- a/drivers/input/misc/axp20x-pek.c
+++ b/drivers/input/misc/axp20x-pek.c
@@ -309,6 +309,10 @@ static int axp20x_pek_probe(struct platform_device *pdev)
 
axp20x_pek->axp20x = dev_get_drvdata(pdev->dev.parent);
 
+   /* In case there is no interrupt line from the AXP towards the CPU. */
+   if (!axp20x_pek->axp20x->regmap_irqc)
+   return -ENODEV;
+
axp20x_pek->irq_dbr = platform_get_irq_byname(pdev, "PEK_DBR");
if (axp20x_pek->irq_dbr < 0)
return axp20x_pek->irq_dbr;
-- 
2.17.5

Re: [PATCH 1/2] x86/setup: consolidate early memory reservations

[Borislav Petkov]

On Fri, Jan 15, 2021 at 10:32:54AM +0200, Mike Rapoport wrote:
> + trim_low_memory_range();

Btw, you can get rid of that one too:

/*
 * Here we put platform-specific memory range workarounds, i.e.
 * memory known to be corrupt or otherwise in need to be reserved on
 * specific platforms.
 *
 * If this gets used more widely it could use a real dispatch mechanism.
 */
static void __init trim_platform_memory_ranges(void)
{
trim_snb_memory();
}

yeah, yeah, we can do a real dispatch mechanism but we didn't need one
since 2012 so I guess we can get rid of trim_platform_memory_ranges()
and call trim_snb_memory() directly and simplify it even more.

Thx.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v4 1/3] arm64: Improve kernel address detection of __is_lm_address()

[Catalin Marinas]

On Mon, Jan 25, 2021 at 02:36:34PM +, Vincenzo Frascino wrote:
> On 1/25/21 1:02 PM, Mark Rutland wrote:
> > On Fri, Jan 22, 2021 at 03:56:40PM +, Vincenzo Frascino wrote:
> >> Currently, the __is_lm_address() check just masks out the top 12 bits
> >> of the address, but if they are 0, it still yields a true result.
> >> This has as a side effect that virt_addr_valid() returns true even for
> >> invalid virtual addresses (e.g. 0x0).
> >>
> >> Improve the detection checking that it's actually a kernel address
> >> starting at PAGE_OFFSET.
> >>
> >> Cc: Catalin Marinas 
> >> Cc: Will Deacon 
> >> Suggested-by: Catalin Marinas 
> >> Reviewed-by: Catalin Marinas 
> >> Signed-off-by: Vincenzo Frascino 
> > 
> > Looking around, it seems that there are some existing uses of
> > virt_addr_valid() that expect it to reject addresses outside of the
> > TTBR1 range. For example, check_mem_type() in drivers/tee/optee/call.c.
> > 
> > Given that, I think we need something that's easy to backport to stable.
> > 
> 
> I agree, I started looking at it this morning and I found cases even in the 
> main
> allocators (slub and page_alloc) either then the one you mentioned.
> 
> > This patch itself looks fine, but it's not going to backport very far,
> > so I suspect we might need to write a preparatory patch that adds an
> > explicit range check to virt_addr_valid() which can be trivially
> > backported.
> > 
> 
> I checked the old releases and I agree this is not back-portable as it stands.
> I propose therefore to add a preparatory patch with the check below:
> 
> #define __is_ttrb1_address(addr)  ((u64)(addr) >= PAGE_OFFSET && \
>   (u64)(addr) < PAGE_END)
> 
> If it works for you I am happy to take care of it and post a new version of my
> patches.

I'm not entirely sure we need a preparatory patch. IIUC (it needs
checking), virt_addr_valid() was fine until 5.4, broken by commit
14c127c957c1 ("arm64: mm: Flip kernel VA space"). Will addressed the
flip case in 68dd8ef32162 ("arm64: memory: Fix virt_addr_valid() using
__is_lm_address()") but this broke the 

[PATCH v4 22/23] powerpc/syscall: Optimise checks in beginning of system_call_exception()

[Christophe Leroy]

Combine all tests of regs->msr into a single logical one.

Before the patch:

   0:   81 6a 00 84 lwz r11,132(r10)
   4:   90 6a 00 88 stw r3,136(r10)
   8:   69 60 00 02 xorir0,r11,2
   c:   54 00 ff fe rlwinm  r0,r0,31,31,31
  10:   0f 00 00 00 twnei   r0,0
  14:   69 63 40 00 xorir3,r11,16384
  18:   54 63 97 fe rlwinm  r3,r3,18,31,31
  1c:   0f 03 00 00 twnei   r3,0
  20:   69 6b 80 00 xorir11,r11,32768
  24:   55 6b 8f fe rlwinm  r11,r11,17,31,31
  28:   0f 0b 00 00 twnei   r11,0

After the patch:

   0:   81 6a 00 84 lwz r11,132(r10)
   4:   90 6a 00 88 stw r3,136(r10)
   8:   7d 6b 58 f8 not r11,r11
   c:   71 6b c0 02 andi.   r11,r11,49154
  10:   0f 0b 00 00 twnei   r11,0

6 cycles less on powerpc 8xx (328 => 322 cycles).

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/syscall.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/syscall.c b/arch/powerpc/kernel/syscall.c
index a40775daa88b..47ae55f94d1c 100644
--- a/arch/powerpc/kernel/syscall.c
+++ b/arch/powerpc/kernel/syscall.c
@@ -28,6 +28,7 @@ notrace long system_call_exception(long r3, long r4, long r5,
   unsigned long r0, struct pt_regs *regs)
 {
syscall_fn f;
+   unsigned long expected_msr;
 
regs->orig_gpr3 = r3;
 
@@ -39,10 +40,13 @@ notrace long system_call_exception(long r3, long r4, long 
r5,
 
trace_hardirqs_off(); /* finish reconciling */
 
+   expected_msr = MSR_PR;
if (!IS_ENABLED(CONFIG_BOOKE) && !IS_ENABLED(CONFIG_40x))
-   BUG_ON(!(regs->msr & MSR_RI));
-   BUG_ON(!(regs->msr & MSR_PR));
-   BUG_ON(arch_irq_disabled_regs(regs));
+   expected_msr |= MSR_RI;
+   if (IS_ENABLED(CONFIG_PPC32))
+   expected_msr |= MSR_EE;
+   BUG_ON((regs->msr & expected_msr) ^ expected_msr);
+   BUG_ON(IS_ENABLED(CONFIG_PPC64) && arch_irq_disabled_regs(regs));
 
 #ifdef CONFIG_PPC_PKEY
if (mmu_has_feature(MMU_FTR_PKEY)) {
-- 
2.25.0

Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure

[Ard Biesheuvel]

On Mon, 25 Jan 2021 at 15:28, Marc Zyngier  wrote:
>
> On 2021-01-25 14:19, Ard Biesheuvel wrote:
> > On Mon, 25 Jan 2021 at 14:54, Marc Zyngier  wrote:
> >>
> >> On 2021-01-25 12:54, Ard Biesheuvel wrote:
>
> [...]
>
> >> > This struct now takes up
> >> > - ~100 bytes for the characters themselves (which btw are not emitted
> >> > into __initdata or __initconst)
> >> > - 6x8 bytes for the char pointers
> >> > - 6x24 bytes for the RELA relocations that annotate these pointers as
> >> > quantities that need to be relocated at boot (on a kernel built with
> >> > KASLR)
> >> >
> >> > I know it's only a drop in the ocean, but in this case, where the
> >> > struct is statically declared and defined only once, and in the same
> >> > place, we could easily turn this into
> >> >
> >> > static const struct {
> >> >char alias[24];
> >> >char param[20];
> >> > };
> >> >
> >> > and get rid of all the overhead. The only slightly annoying thing is
> >> > that the array sizes need to be kept in sync with the largest instance
> >> > appearing in the array, but this is easy when the struct type is
> >> > declared in the same place where its only instance is defined.
> >>
> >> Fair enough. I personally find the result butt-ugly, but I agree
> >> that it certainly saves some memory. Does the following work for
> >> you? I can even give symbolic names to the various constants (how
> >> generous of me! ;-).
> >>
> >
> > To be honest, I was anticipating more of a discussion, but this looks
> > reasonable to me.
>
> It looked like a reasonable ask: all the strings are completely useless
> once the kernel has booted, and I'm the first to moan that I can't boot
> an arm64 kernel with less than 60MB of RAM (OK, it's a pretty bloated
> kernel...).
>
> > Does 'charfeature[80];' really need 80 bytes though?
>
> It really needs 75 bytes, because of this:
>
> { "arm64.nopauth",
>   "id_aa64isar1.gpi=0 id_aa64isar1.gpa=0 "
>   "id_aa64isar1.api=0 id_aa64isar1.apa=0"  },
>
> 80 is a round enough number.
>

Fair enough. This will inflate the struct substantially, but at least
it's all __initconst data now, and it's all NUL bytes so it compresses
much better than the pointers and RELA entries.

[PATCH v4 21/23] powerpc/syscall: Remove FULL_REGS verification in system_call_exception

[Christophe Leroy]

For book3s/64, FULL_REGS() is 'true' at all time, so the test voids.
For others, non volatile registers are saved inconditionally.

So the verification is pointless.

Should one fail to do it, it would anyway be caught by the
CHECK_FULL_REGS() in copy_thread() as we have removed the
special versions ppc_fork() and friends.

null_syscall benchmark reduction 4 cycles (332 => 328 cycles)

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/syscall.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/kernel/syscall.c b/arch/powerpc/kernel/syscall.c
index 30f8a397a522..a40775daa88b 100644
--- a/arch/powerpc/kernel/syscall.c
+++ b/arch/powerpc/kernel/syscall.c
@@ -42,7 +42,6 @@ notrace long system_call_exception(long r3, long r4, long r5,
if (!IS_ENABLED(CONFIG_BOOKE) && !IS_ENABLED(CONFIG_40x))
BUG_ON(!(regs->msr & MSR_RI));
BUG_ON(!(regs->msr & MSR_PR));
-   BUG_ON(!FULL_REGS(regs));
BUG_ON(arch_irq_disabled_regs(regs));
 
 #ifdef CONFIG_PPC_PKEY
-- 
2.25.0

Re: [PATCH net-next] net: core: devlink: add new trap action HARD_DROP

[Jiri Pirko]

Mon, Jan 25, 2021 at 01:24:27PM CET, oleksandr.ma...@plvision.eu wrote:
>Thu, Jan 21, 2021 at 06:36:05PM CET, k...@kernel.org wrote:
>>On Thu, 21 Jan 2021 14:21:52 +0200 Ido Schimmel wrote:
>>> On Thu, Jan 21, 2021 at 01:29:37PM +0200, Oleksandr Mazur wrote:
>>> > Add new trap action HARD_DROP, which can be used by the
>>> > drivers to register traps, where it's impossible to get
>>> > packet reported to the devlink subsystem by the device
>>> > driver, because it's impossible to retrieve dropped packet
>>> > from the device itself.
>>> > In order to use this action, driver must also register
>>> > additional devlink operation - callback that is used
>>> > to retrieve number of packets that have been dropped by
>>> > the device.  
>>> 
>>> Are these global statistics about number of packets the hardware dropped
>>> for a specific reason or are these per-port statistics?
>>> 
>>> It's a creative use of devlink-trap interface, but I think it makes
>>> sense. Better to re-use an existing interface than creating yet another
>>> one.
>>
>>Not sure if I agree, if we can't trap why is it a trap?
>>It's just a counter.
>
>>+1
>Device might be unable to trap only the 'DROP' packets, and this information 
>should be transparent for the user.
>
>I agree on the statement, that new action might be an overhead.
>I could continue on with the solution Ido Schimmel proposed: since no new 
>action would be needed and no UAPI changes are required, i could simply do the 
>dropped statistics (additional field) output added upon trap stats queiring.
>(In case if driver registerd callback, of course; and do so only for DROP 
>actions)

It is not "a trap". You just need to count dropped packet. You don't
trap anything. That is why I don't think this has anything to do with
"trap" infra.

Re: [PATCH 2/2] x86/setup: merge several reservations of start of the memory

[Borislav Petkov]

On Fri, Jan 15, 2021 at 10:32:55AM +0200, Mike Rapoport wrote:
> From: Mike Rapoport 
> 
> Currently the first several pages are reserved both to avoid leaking their
> contents on systems with L1TF and to avoid corrupting BIOS memory.
> 
> Merge the two memory reservations.
> 
> Signed-off-by: Mike Rapoport 
> ---
>  arch/x86/kernel/setup.c | 29 +++--
>  1 file changed, 11 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 32cd2e790a0a..3f2fd67240f8 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -715,20 +715,6 @@ static int __init parse_reservelow(char *p)
>  
>  early_param("reservelow", parse_reservelow);
>  
> -static void __init trim_low_memory_range(void)
> -{
> - /*
> -  * A special case is the first 4Kb of memory;
> -  * This is a BIOS owned area, not kernel ram, but generally
> -  * not listed as such in the E820 table.
> -  *
> -  * This typically reserves additional memory (64KiB by default)
> -  * since some BIOSes are known to corrupt low memory.  See the
> -  * Kconfig help text for X86_RESERVE_LOW.
> -  */
> - memblock_reserve(0, ALIGN(reserve_low, PAGE_SIZE));
> -}
> -
>  static void __init early_reserve_memory(void)
>  {
>   /*
> @@ -741,10 +727,18 @@ static void __init early_reserve_memory(void)
>(unsigned long)__end_of_kernel_reserve - (unsigned 
> long)_text);
>  
>   /*
> -  * Make sure page 0 is always reserved because on systems with
> -  * L1TF its contents can be leaked to user processes.
> +  * The first 4Kb of memory is a BIOS owned area, but generally it is
> +  * not listed as such in the E820 table.
> +  *
> +  * Reserve the first memory page and typically some additional
> +  * memory (64KiB by default) since some BIOSes are known to corrupt
> +  * low memory. See the Kconfig help text for X86_RESERVE_LOW.
> +  *
> +  * In addition, we must make sure page 0 is always reserved because

s/we must//

Other than that:

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 1/2] x86/setup: consolidate early memory reservations

[Borislav Petkov]

On Fri, Jan 15, 2021 at 10:32:54AM +0200, Mike Rapoport wrote:
> From: Mike Rapoport 
> 
> The early reservations of memory areas used by the firmware, bootloader,
> kernel text and data are spread over setup_arch(). Moreover, some of them
> happen *after* memblock allocations, e.g trim_platform_memory_ranges() and
> trim_low_memory_range() are called after reserve_real_mode() that allocates
> memory.
> 
> We did not observe corruption of these memory regions because memblock

Make that "We" impersonal, passive voice pls.

> always allocates memory either from the end of memory (in top-down mode) or
> above the kernel image (in bottom-up mode). However, the bottom up mode is
> going to be updated to span the entire memory [1] to avoid limitations
> caused by KASLR.
> 
> Consolidate early memory reservations in a dedicated function to improve
> robustness against future changes. Having the early reservations in one
> place also makes it clearer what memory must be reserved before we allow
> memblock allocations.

Would it make sense to have a check with a WARN or so to catch early
reservations which get added after memblock allocations have been
allowed? To catch people who don't pay attention...

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

[PATCH v4 18/23] powerpc/32: Remove verification of MSR_PR on syscall in the ASM entry

[Christophe Leroy]

system_call_exception() checks MSR_PR and BUGs if a syscall
is issued from kernel mode.

No need to handle it anymore from the ASM entry code.

null_syscall reduction 2 cycles (348 => 346 cycles)

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/entry_32.S   | 30 --
 arch/powerpc/kernel/head_32.h|  3 ---
 arch/powerpc/kernel/head_booke.h |  3 ---
 3 files changed, 36 deletions(-)

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index ce5fdb23ed7c..9922a04650f7 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -416,36 +416,6 @@ ret_from_kernel_thread:
li  r3,0
b   ret_from_syscall
 
-   /*
-* System call was called from kernel. We get here with SRR1 in r9.
-* Mark the exception as recoverable once we have retrieved SRR0,
-* trap a warning and return ENOSYS with CR[SO] set.
-*/
-   .globl  ret_from_kernel_syscall
-ret_from_kernel_syscall:
-   mfspr   r9, SPRN_SRR0
-   mfspr   r10, SPRN_SRR1
-#if !defined(CONFIG_4xx) && !defined(CONFIG_BOOKE)
-   LOAD_REG_IMMEDIATE(r11, MSR_KERNEL & ~(MSR_IR|MSR_DR))
-   mtmsr   r11
-#endif
-
-0: trap
-   EMIT_BUG_ENTRY 0b,__FILE__,__LINE__, BUGFLAG_WARNING
-
-   li  r3, ENOSYS
-   crset   so
-#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PERF_EVENTS)
-   mtspr   SPRN_NRI, r0
-#endif
-   mtspr   SPRN_SRR0, r9
-   mtspr   SPRN_SRR1, r10
-   rfi
-#ifdef CONFIG_40x
-   b . /* Prevent prefetch past rfi */
-#endif
-_ASM_NOKPROBE_SYMBOL(ret_from_kernel_syscall)
-
 /*
  * Top-level page fault handling.
  * This is in assembler because if do_page_fault tells us that
diff --git a/arch/powerpc/kernel/head_32.h b/arch/powerpc/kernel/head_32.h
index c2aa0d8f1f63..c0de4acbe3f8 100644
--- a/arch/powerpc/kernel/head_32.h
+++ b/arch/powerpc/kernel/head_32.h
@@ -118,8 +118,6 @@
 .macro SYSCALL_ENTRY trapno
mfspr   r9, SPRN_SRR1
mfspr   r10, SPRN_SRR0
-   andi.   r11, r9, MSR_PR
-   beq-99f
LOAD_REG_IMMEDIATE(r11, MSR_KERNEL) /* can take exceptions 
*/
lis r12, 1f@h
ori r12, r12, 1f@l
@@ -176,7 +174,6 @@
 3:
 #endif
b   transfer_to_syscall /* jump to handler */
-99:b   ret_from_kernel_syscall
 .endm
 
 .macro save_dar_dsisr_on_stack reg1, reg2, sp
diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index faff094b650e..7af84e1e717b 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -106,10 +106,8 @@ ALT_FTR_SECTION_END_IFSET(CPU_FTR_EMB_HV)
 #endif
mfspr   r9, SPRN_SRR1
BOOKE_CLEAR_BTB(r11)
-   andi.   r11, r9, MSR_PR
lwz r11, TASK_STACK - THREAD(r10)
rlwinm  r12,r12,0,4,2   /* Clear SO bit in CR */
-   beq-99f
ALLOC_STACK_FRAME(r11, THREAD_SIZE - INT_FRAME_SIZE)
stw r12, _CCR(r11)  /* save various registers */
mflrr12
@@ -157,7 +155,6 @@ ALT_FTR_SECTION_END_IFSET(CPU_FTR_EMB_HV)
 
 3:
b   transfer_to_syscall /* jump to handler */
-99:b   ret_from_kernel_syscall
 .endm
 
 /* To handle the additional exception priority levels on 40x and Book-E
-- 
2.25.0

[PATCH v4 17/23] powerpc/syscall: implement system call entry/exit logic in C for PPC32

[Christophe Leroy]

That's port of PPC64 syscall entry/exit logic in C to PPC32.

Performancewise on 8xx:
Before : 304 cycles on null_syscall
After  : 348 cycles on null_syscall

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/entry_32.S   | 227 ---
 arch/powerpc/kernel/head_32.h|  16 ---
 arch/powerpc/kernel/head_booke.h |  15 --
 3 files changed, 29 insertions(+), 229 deletions(-)

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 97dc28a68465..ce5fdb23ed7c 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -329,117 +329,22 @@ stack_ovf:
 _ASM_NOKPROBE_SYMBOL(stack_ovf)
 #endif
 
-#ifdef CONFIG_TRACE_IRQFLAGS
-trace_syscall_entry_irq_off:
-   /*
-* Syscall shouldn't happen while interrupts are disabled,
-* so let's do a warning here.
-*/
-0: trap
-   EMIT_BUG_ENTRY 0b,__FILE__,__LINE__, BUGFLAG_WARNING
-   bl  trace_hardirqs_on
-
-   /* Now enable for real */
-   LOAD_REG_IMMEDIATE(r10, MSR_KERNEL | MSR_EE)
-   mtmsr   r10
-
-   REST_GPR(0, r1)
-   REST_4GPRS(3, r1)
-   REST_2GPRS(7, r1)
-   b   DoSyscall
-#endif /* CONFIG_TRACE_IRQFLAGS */
-
.globl  transfer_to_syscall
 transfer_to_syscall:
SAVE_NVGPRS(r1)
 #ifdef CONFIG_PPC_BOOK3S_32
kuep_lock r11, r12
 #endif
-#ifdef CONFIG_TRACE_IRQFLAGS
-   andi.   r12,r9,MSR_EE
-   beq-trace_syscall_entry_irq_off
-#endif /* CONFIG_TRACE_IRQFLAGS */
 
-/*
- * Handle a system call.
- */
-   .stabs  "arch/powerpc/kernel/",N_SO,0,0,0f
-   .stabs  "entry_32.S",N_SO,0,0,0f
-0:
-
-_GLOBAL(DoSyscall)
-   stw r3,ORIG_GPR3(r1)
-   li  r12,0
-   stw r12,RESULT(r1)
-#ifdef CONFIG_TRACE_IRQFLAGS
-   /* Make sure interrupts are enabled */
-   mfmsr   r11
-   andi.   r12,r11,MSR_EE
-   /* We came in with interrupts disabled, we WARN and mark them enabled
-* for lockdep now */
-0: tweqi   r12, 0
-   EMIT_BUG_ENTRY 0b,__FILE__,__LINE__, BUGFLAG_WARNING
-#endif /* CONFIG_TRACE_IRQFLAGS */
-   lwz r11,TI_FLAGS(r2)
-   andi.   r11,r11,_TIF_SYSCALL_DOTRACE
-   bne-syscall_dotrace
-syscall_dotrace_cont:
-   cmplwi  0,r0,NR_syscalls
-   lis r10,sys_call_table@h
-   ori r10,r10,sys_call_table@l
-   slwir0,r0,2
-   bge-66f
-
-   barrier_nospec_asm
-   /*
-* Prevent the load of the handler below (based on the user-passed
-* system call number) being speculatively executed until the test
-* against NR_syscalls and branch to .66f above has
-* committed.
-*/
+   /* Calling convention has r9 = orig r0, r10 = regs */
+   mr  r9,r0
+   addir10,r1,STACK_FRAME_OVERHEAD
+   bl  system_call_exception
 
-   lwzxr10,r10,r0  /* Fetch system call handler [ptr] */
-   mtlrr10
-   addir9,r1,STACK_FRAME_OVERHEAD
-   PPC440EP_ERR42
-   blrl/* Call handler */
-   .globl  ret_from_syscall
 ret_from_syscall:
-#ifdef CONFIG_DEBUG_RSEQ
-   /* Check whether the syscall is issued inside a restartable sequence */
-   stw r3,GPR3(r1)
-   addir3,r1,STACK_FRAME_OVERHEAD
-   bl  rseq_syscall
-   lwz r3,GPR3(r1)
-#endif
-   mr  r6,r3
-   /* disable interrupts so current_thread_info()->flags can't change */
-   LOAD_REG_IMMEDIATE(r10,MSR_KERNEL)  /* doesn't include MSR_EE */
-   /* Note: We don't bother telling lockdep about it */
-   mtmsr   r10
-   lwz r9,TI_FLAGS(r2)
-   li  r8,-MAX_ERRNO
-   andi.   
r0,r9,(_TIF_SYSCALL_DOTRACE|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK)
-   bne-syscall_exit_work
-   cmplw   0,r3,r8
-   blt+syscall_exit_cont
-   lwz r11,_CCR(r1)/* Load CR */
-   neg r3,r3
-   orisr11,r11,0x1000  /* Set SO bit in CR */
-   stw r11,_CCR(r1)
-syscall_exit_cont:
-   lwz r8,_MSR(r1)
-#ifdef CONFIG_TRACE_IRQFLAGS
-   /* If we are going to return from the syscall with interrupts
-* off, we trace that here. It shouldn't normally happen.
-*/
-   andi.   r10,r8,MSR_EE
-   bne+1f
-   stw r3,GPR3(r1)
-   bl  trace_hardirqs_off
-   lwz r3,GPR3(r1)
-1:
-#endif /* CONFIG_TRACE_IRQFLAGS */
+   addir4,r1,STACK_FRAME_OVERHEAD
+   li  r5,0
+   bl  syscall_exit_prepare
 #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
/* If the process has its own DBCR0 value, load it up.  The internal
   debug mode bit tells us that dbcr0 should be loaded. */
@@ -453,34 +358,39 @@ syscall_exit_cont:
cmplwi  cr0,r5,0
bne-2f
 #endif /* CONFIG_PPC_47x */
-1:
-BEGIN_FTR_SECTION
-   lwarx   r7,0,r1
-END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
-   stwcx.  r0,0,r1 /* to clear the

Re: [RFC PATCH v1] sched/fair: limit load balance redo times at the same sched_domain level

[Vincent Guittot]

On Mon, 25 Jan 2021 at 15:00, Li, Aubrey  wrote:
>
> On 2021/1/25 18:56, Vincent Guittot wrote:
> > On Mon, 25 Jan 2021 at 06:50, Aubrey Li  wrote:
> >>
> >> A long-tail load balance cost is observed on the newly idle path,
> >> this is caused by a race window between the first nr_running check
> >> of the busiest runqueue and its nr_running recheck in detach_tasks.
> >>
> >> Before the busiest runqueue is locked, the tasks on the busiest
> >> runqueue could be pulled by other CPUs and nr_running of the busiest
> >> runqueu becomes 1, this causes detach_tasks breaks with LBF_ALL_PINNED
> >
> > We should better detect that when trying to detach task like below
>
> This should be a compromise from my understanding. If we give up load balance
> this time due to the race condition, we do reduce the load balance cost on the
> newly idle path, but if there is an imbalance indeed at the same sched_domain

Redo path is there in case, LB has found an imbalance but it can't
move some loads from this busiest rq to dest rq because of some cpu
affinity. So it tries to fix the imbalance by moving load onto another
rq of the group. In your case, the imbalance has disappeared because
it has already been pulled by another rq so you don't have to try to
find another imbalance. And I would even say you should not in order
to let other level to take a chance to spread the load

> level, we have to wait the next softirq entry to handle that imbalance. This
> means the tasks on the second busiest runqueue have to stay longer, which 
> could
> introduce tail latency as well. That's why I introduced a variable to control
> the redo loops. I'll send this to the benchmark queue to see if it makes any

TBH, I don't like multiplying the number of knobs

> difference.
>
> Thanks,
> -Aubrey
>
> >
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -7688,6 +7688,16 @@ static int detach_tasks(struct lb_env *env)
> >
> > lockdep_assert_held(&env->src_rq->lock);
> >
> > +   /*
> > +* Another CPU has emptied this runqueue in the meantime.
> > +* Just return and leave the load_balance properly.
> > +*/
> > +   if (env->src_rq->nr_running <= 1 && !env->loop) {
> > +   /* Clear the flag as we will not test any task */
> > +   env->flags &= ~LBF_ALL_PINNED;
> > +   return 0;
> > +   }
> > +
> > if (env->imbalance <= 0)
> > return 0;
> >
> >
> >> flag set, and triggers load_balance redo at the same sched_domain level.
> >>
> >> In order to find the new busiest sched_group and CPU, load balance will
> >> recompute and update the various load statistics, which eventually leads
> >> to the long-tail load balance cost.
> >>
> >> This patch introduces a variable(sched_nr_lb_redo) to limit load balance
> >> redo times, combined with sysctl_sched_nr_migrate, the max load balance
> >> cost is reduced from 100+ us to 70+ us, measured on a 4s x86 system with
> >> 192 logical CPUs.
> >>
> >> Cc: Andi Kleen 
> >> Cc: Tim Chen 
> >> Cc: Srinivas Pandruvada 
> >> Cc: Rafael J. Wysocki 
> >> Signed-off-by: Aubrey Li 
> >> ---
> >>  kernel/sched/fair.c | 7 ++-
> >>  1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> >> index ae7ceba..b59f371 100644
> >> --- a/kernel/sched/fair.c
> >> +++ b/kernel/sched/fair.c
> >> @@ -7407,6 +7407,8 @@ struct lb_env {
> >> unsigned intloop;
> >> unsigned intloop_break;
> >> unsigned intloop_max;
> >> +   unsigned intredo_cnt;
> >> +   unsigned intredo_max;
> >>
> >> enum fbq_type   fbq_type;
> >> enum migration_type migration_type;
> >> @@ -9525,6 +9527,7 @@ static int should_we_balance(struct lb_env *env)
> >> return group_balance_cpu(sg) == env->dst_cpu;
> >>  }
> >>
> >> +static const unsigned int sched_nr_lb_redo = 1;
> >>  /*
> >>   * Check this_cpu to ensure it is balanced within domain. Attempt to move
> >>   * tasks if there is an imbalance.
> >> @@ -9547,6 +9550,7 @@ static int load_balance(int this_cpu, struct rq 
> >> *this_rq,
> >> .dst_grpmask= sched_group_span(sd->groups),
> >> .idle   = idle,
> >> .loop_break = sched_nr_migrate_break,
> >> +   .redo_max   = sched_nr_lb_redo,
> >> .cpus   = cpus,
> >> .fbq_type   = all,
> >> .tasks  = LIST_HEAD_INIT(env.tasks),
> >> @@ -9682,7 +9686,8 @@ static int load_balance(int this_cpu, struct rq 
> >> *this_rq,
> >>  * destination group that is receiving any migrated
> >>  * load.
> >>  */
> >> -   if (!cpumask_subset(cpus, env.dst_grpmask)) {
> >> +   if (!cpumask_subset(cpus, env.dst_grpmask) &&
> >> +

Re: [PATCH 1/2] media: venus: core: Add sdm660 DT compatible and resource struct

[AngeloGioacchino Del Regno]

Il 25/01/21 11:40, Hans Verkuil ha scritto:

On 18/01/2021 18:45, AngeloGioacchino Del Regno wrote:

Il 18/01/21 18:21, Stanimir Varbanov ha scritto:

Hi Angelo,

Thanks for the patch!

On 1/15/21 8:52 PM, AngeloGioacchino Del Regno wrote:

Add the SDM660 DT compatible and its resource structure, also
including support for the Venus pmdomains, in order to support
the Venus block in SDM630, SDM636, SDM660 and SDA variants.

This SoC features Venus 4.4 (HFI3XX), with one vcodec used for
both encoding and decoding, switched on through two GDSCs.
The core clock for this Venus chip is powered by the RPM VDD_CX
power domain.

Signed-off-by: AngeloGioacchino Del Regno 

---
   drivers/media/platform/qcom/venus/core.c | 66 
   1 file changed, 66 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/core.c 
b/drivers/media/platform/qcom/venus/core.c
index bdd293faaad0..83ca86a63241 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -565,6 +565,71 @@ static const struct venus_resources sdm845_res_v2 = {
.fwname = "qcom/venus-5.2/venus.mdt",
   };
   
+static const struct freq_tbl sdm660_freq_table[] = {

+   { 0, 51840 },
+   { 0, 44160 },
+   { 0, 40400 },
+   { 0, 32000 },
+   { 0, 26933 },
+   { 0, 1 },
+};
+
+static const struct reg_val sdm660_reg_preset[] = {
+   { 0x80010, 0x001f001f },
+   { 0x80018, 0x0156 },
+   { 0x8001C, 0x0156 },
+};
+
+static const struct bw_tbl sdm660_bw_table_enc[] = {
+   {  979200,  1044000, 0, 2446336, 0 },   /* 4k UHD @ 30 */
+   {  864000,   887000, 0, 2108416, 0 },   /* 720p @ 240 */
+   {  489600,   666000, 0, 1207296, 0 },   /* 1080p @ 60 */
+   {  432000,   578000, 0, 1058816, 0 },   /* 720p @ 120 */
+   {  244800,   346000, 0,  616448, 0 },   /* 1080p @ 30 */
+   {  216000,   293000, 0,  534528, 0 },   /* 720p @ 60 */
+   {  108000,   151000, 0,  271360, 0 },   /* 720p @ 30 */
+};
+
+static const struct bw_tbl sdm660_bw_table_dec[] = {
+   {  979200,  2365000, 0, 1892000, 0 },   /* 4k UHD @ 30 */
+   {  864000,  1978000, 0, 1554000, 0 },   /* 720p @ 240 */
+   {  489600,  1133000, 0,  895000, 0 },   /* 1080p @ 60 */
+   {  432000,   994000, 0,  781000, 0 },   /* 720p @ 120 */
+   {  244800,   58, 0,  46, 0 },   /* 1080p @ 30 */
+   {  216000,   501000, 0,  301000, 0 },   /* 720p @ 60 */
+   {  108000,   255000, 0,  202000, 0 },   /* 720p @ 30 */
+};
+
+static const struct venus_resources sdm660_res = {
+   .freq_tbl = sdm660_freq_table,
+   .freq_tbl_size = ARRAY_SIZE(sdm660_freq_table),
+   .reg_tbl = sdm660_reg_preset,
+   .reg_tbl_size = ARRAY_SIZE(sdm660_reg_preset),
+   .bw_tbl_enc = sdm660_bw_table_enc,
+   .bw_tbl_enc_size = ARRAY_SIZE(sdm660_bw_table_enc),
+   .bw_tbl_dec = sdm660_bw_table_dec,
+   .bw_tbl_dec_size = ARRAY_SIZE(sdm660_bw_table_dec),
+   .clks = {"core", "iface", "bus_throttle", "bus" },
+   .clks_num = 4,
+   .vcodec0_clks = { "vcodec0_core" },
+   .vcodec_clks_num = 1,
+   .vcodec_pmdomains = { "venus", "vcodec0" },
+   .vcodec_pmdomains_num = 2,
+   .opp_pmdomain = (const char *[]) { "cx", NULL },
+   .vcodec_num = 1,
+   .max_load = 1036800,
+   .hfi_version = HFI_VERSION_3XX,
+   .vmem_id = VIDC_RESOURCE_NONE,
+   .vmem_size = 0,
+   .vmem_addr = 0,
+   .cp_start = 0,
+   .cp_size = 0x7900,
+   .cp_nonpixel_start = 0x100,
+   .cp_nonpixel_size = 0x2800,
+   .dma_mask = 0xd900 - 1,
+   .fwname = "qcom/venus-4.4/venus.mdt",


Did you try venus-4.2 firmware from linux-firmware tree [1] ?



No I haven't.. and I can't... my Sony devices (but I think that this is
a practice of all OEMs/ODMs) are using a Sony signed venus firmware, so
I am totally limited to use the firmware that comes with the device.

Besides that, the version is still different so, even if I had any
possibility to try that, I don't think that it would work anyway...


Hello!



I'm a bit confused. "qcom/venus-4.4/venus.mdt" is the Sony signed FW?



In my case it is, but this follows the generic firmware path as was done
for all the other Venus firmwares, so my code is not pointing at Sony
specific things, but just generic ones.

Every Qualcomm-powered consumer device (smartphones, tablets etc) have
got a double sigcheck: one for qcom, one for OEM specific and most of
the times the TZ is configured to accept only firmwares that also have
the OEM signature.

This is not true for all the firmwares - for example, Adreno has this
mechanism only for the ZAP part - but unfortunately I'm not aware of
any consumer device accepting a Venus firmware with the "generic"
Qualcomm signature only (so - without the OEM signature).

Short answer:
1. qcom/venus-4.4/venus.mdt is a generic firmware for Venus
2. 99% of the people needs a different firmware

Re: [PATCH v3 1/3] dt-bindings:drm/bridge:anx7625:add HDCP support flag and swing reg

[Rob Herring]

On Mon, 25 Jan 2021 19:12:21 +0800, Xin Ji wrote:
> Add 'bus-type' and 'data-lanes' define for port0, add HDCP support
> flag and DP tx lane0 and lane1 swing register array define.
> 
> Signed-off-by: Xin Ji 
> ---
>  .../bindings/display/bridge/analogix,anx7625.yaml  | 57 
> --
>  1 file changed, 54 insertions(+), 3 deletions(-)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.example.dt.yaml:
 encoder@58: ports: '#address-cells', '#size-cells' do not match any of the 
regexes: 'pinctrl-[0-9]+'
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.example.dt.yaml:
 encoder@58: ports:port@1:endpoint: Additional properties are not allowed 
('remote-endpoint' was unexpected)
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml

See https://patchwork.ozlabs.org/patch/1431199

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH 2/2] dt-bindings: clock: ad9545: Add documentation

[Rob Herring]

On Mon, 25 Jan 2021 00:13:04 +0200, alexandru.tach...@analog.com wrote:
> From: Alexandru Tachici 
> 
> Add dt bindings for ad9545.
> 
> Signed-off-by: Alexandru Tachici 
> ---
>  .../devicetree/bindings/clock/clk-ad9545.yaml | 352 ++
>  1 file changed, 352 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/clk-ad9545.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/clock/clk-ad9545.yaml:78:6: [warning] wrong 
indentation: expected 4 but found 5 (indentation)

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/clock/clk-ad9545.yaml:
 properties:clocks:maxItems: False schema does not allow 4
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/clock/clk-ad9545.yaml:
 ignoring, error in schema: properties: clocks: maxItems
warning: no schema found in file: 
./Documentation/devicetree/bindings/clock/clk-ad9545.yaml

See https://patchwork.ozlabs.org/patch/1431040

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

[PATCH v4 19/23] powerpc/syscall: Avoid stack frame in likely part of system_call_exception()

[Christophe Leroy]

When r3 is not modified, reload it from regs->orig_r3 to free
volatile registers. This avoids a stack frame for the likely part
of system_call_exception()

Before the patch:

c000b4d4 :
c000b4d4:   7c 08 02 a6 mflrr0
c000b4d8:   94 21 ff e0 stwur1,-32(r1)
c000b4dc:   93 e1 00 1c stw r31,28(r1)
c000b4e0:   90 01 00 24 stw r0,36(r1)
c000b4e4:   90 6a 00 88 stw r3,136(r10)
c000b4e8:   81 6a 00 84 lwz r11,132(r10)
c000b4ec:   69 6b 00 02 xorir11,r11,2
c000b4f0:   55 6b ff fe rlwinm  r11,r11,31,31,31
c000b4f4:   0f 0b 00 00 twnei   r11,0
c000b4f8:   81 6a 00 a0 lwz r11,160(r10)
c000b4fc:   55 6b 07 fe clrlwi  r11,r11,31
c000b500:   0f 0b 00 00 twnei   r11,0
c000b504:   7c 0c 42 e6 mftbr0
c000b508:   83 e2 00 08 lwz r31,8(r2)
c000b50c:   81 82 00 28 lwz r12,40(r2)
c000b510:   90 02 00 24 stw r0,36(r2)
c000b514:   7d 8c f8 50 subfr12,r12,r31
c000b518:   7c 0c 02 14 add r0,r12,r0
c000b51c:   90 02 00 08 stw r0,8(r2)
c000b520:   7c 10 13 a6 mtspr   80,r0
c000b524:   81 62 00 70 lwz r11,112(r2)
c000b528:   71 60 86 91 andi.   r0,r11,34449
c000b52c:   40 82 00 34 bne c000b560 
c000b530:   2b 89 01 b6 cmplwi  cr7,r9,438
c000b534:   41 9d 00 64 bgt cr7,c000b598 

c000b538:   3d 40 c0 5c lis r10,-16292
c000b53c:   55 29 10 3a rlwinm  r9,r9,2,0,29
c000b540:   39 4a 41 e8 addir10,r10,16872
c000b544:   80 01 00 24 lwz r0,36(r1)
c000b548:   7d 2a 48 2e lwzxr9,r10,r9
c000b54c:   7c 08 03 a6 mtlrr0
c000b550:   7d 29 03 a6 mtctr   r9
c000b554:   83 e1 00 1c lwz r31,28(r1)
c000b558:   38 21 00 20 addir1,r1,32
c000b55c:   4e 80 04 20 bctr

After the patch:

c000b4d4 :
c000b4d4:   81 6a 00 84 lwz r11,132(r10)
c000b4d8:   90 6a 00 88 stw r3,136(r10)
c000b4dc:   69 6b 00 02 xorir11,r11,2
c000b4e0:   55 6b ff fe rlwinm  r11,r11,31,31,31
c000b4e4:   0f 0b 00 00 twnei   r11,0
c000b4e8:   80 6a 00 a0 lwz r3,160(r10)
c000b4ec:   54 63 07 fe clrlwi  r3,r3,31
c000b4f0:   0f 03 00 00 twnei   r3,0
c000b4f4:   7d 6c 42 e6 mftbr11
c000b4f8:   81 82 00 08 lwz r12,8(r2)
c000b4fc:   80 02 00 28 lwz r0,40(r2)
c000b500:   91 62 00 24 stw r11,36(r2)
c000b504:   7c 00 60 50 subfr0,r0,r12
c000b508:   7d 60 5a 14 add r11,r0,r11
c000b50c:   91 62 00 08 stw r11,8(r2)
c000b510:   7c 10 13 a6 mtspr   80,r0
c000b514:   80 62 00 70 lwz r3,112(r2)
c000b518:   70 6b 86 91 andi.   r11,r3,34449
c000b51c:   40 82 00 28 bne c000b544 
c000b520:   2b 89 01 b6 cmplwi  cr7,r9,438
c000b524:   41 9d 00 84 bgt cr7,c000b5a8 

c000b528:   80 6a 00 88 lwz r3,136(r10)
c000b52c:   3d 40 c0 5c lis r10,-16292
c000b530:   55 29 10 3a rlwinm  r9,r9,2,0,29
c000b534:   39 4a 41 e4 addir10,r10,16868
c000b538:   7d 2a 48 2e lwzxr9,r10,r9
c000b53c:   7d 29 03 a6 mtctr   r9
c000b540:   4e 80 04 20 bctr

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/syscall.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/kernel/syscall.c b/arch/powerpc/kernel/syscall.c
index a3510fa4e641..476909b11051 100644
--- a/arch/powerpc/kernel/syscall.c
+++ b/arch/powerpc/kernel/syscall.c
@@ -115,6 +115,9 @@ notrace long system_call_exception(long r3, long r4, long 
r5,
return regs->gpr[3];
}
return -ENOSYS;
+   } else {
+   /* Restore r3 from orig_gpr3 to free up a volatile reg */
+   r3 = regs->orig_gpr3;
}
 
/* May be faster to do array_index_nospec? */
-- 
2.25.0

[PATCH v4 20/23] powerpc/syscall: Do not check unsupported scv vector on PPC32

[Christophe Leroy]

Only PPC64 has scv. No need to check the 0x7ff0 trap on PPC32.

And ignore the scv parameter in syscall_exit_prepare (Save 14 cycles
346 => 332 cycles)

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/entry_32.S | 1 -
 arch/powerpc/kernel/syscall.c  | 7 +--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 9922a04650f7..6ae9c7bcb06c 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -343,7 +343,6 @@ transfer_to_syscall:
 
 ret_from_syscall:
addir4,r1,STACK_FRAME_OVERHEAD
-   li  r5,0
bl  syscall_exit_prepare
 #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
/* If the process has its own DBCR0 value, load it up.  The internal
diff --git a/arch/powerpc/kernel/syscall.c b/arch/powerpc/kernel/syscall.c
index 476909b11051..30f8a397a522 100644
--- a/arch/powerpc/kernel/syscall.c
+++ b/arch/powerpc/kernel/syscall.c
@@ -86,7 +86,7 @@ notrace long system_call_exception(long r3, long r4, long r5,
local_irq_enable();
 
if (unlikely(current_thread_info()->flags & _TIF_SYSCALL_DOTRACE)) {
-   if (unlikely(regs->trap == 0x7ff0)) {
+   if (IS_ENABLED(CONFIG_PPC64) && unlikely(regs->trap == 0x7ff0)) 
{
/* Unsupported scv vector */
_exception(SIGILL, regs, ILL_ILLOPC, regs->nip);
return regs->gpr[3];
@@ -109,7 +109,7 @@ notrace long system_call_exception(long r3, long r4, long 
r5,
r8 = regs->gpr[8];
 
} else if (unlikely(r0 >= NR_syscalls)) {
-   if (unlikely(regs->trap == 0x7ff0)) {
+   if (IS_ENABLED(CONFIG_PPC64) && unlikely(regs->trap == 0x7ff0)) 
{
/* Unsupported scv vector */
_exception(SIGILL, regs, ILL_ILLOPC, regs->nip);
return regs->gpr[3];
@@ -187,6 +187,9 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
unsigned long ti_flags;
unsigned long ret = 0;
 
+   if (IS_ENABLED(CONFIG_PPC32))
+   scv = 0;
+
CT_WARN_ON(ct_state() == CONTEXT_USER);
 
kuap_check();
-- 
2.25.0

[PATCH v4 23/23] powerpc/syscall: Avoid storing 'current' in another pointer

[Christophe Leroy]

By saving the pointer pointing to thread_info.flags, gcc copies r2
in a non-volatile register.

We know 'current' doesn't change, so avoid that intermediaite pointer.

Reduces null_syscall benchmark by 2 cycles (322 => 320 cycles)

On PPC64, gcc seems to know that 'current' is not changing, and it keeps
it in a non volatile register to avoid multiple read of 'current' in paca.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/syscall.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/syscall.c b/arch/powerpc/kernel/syscall.c
index 47ae55f94d1c..72e0b18b88d8 100644
--- a/arch/powerpc/kernel/syscall.c
+++ b/arch/powerpc/kernel/syscall.c
@@ -186,7 +186,6 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
   struct pt_regs *regs,
   long scv)
 {
-   unsigned long *ti_flagsp = ¤t_thread_info()->flags;
unsigned long ti_flags;
unsigned long ret = 0;
 
@@ -202,7 +201,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
/* Check whether the syscall is issued inside a restartable sequence */
rseq_syscall(regs);
 
-   ti_flags = *ti_flagsp;
+   ti_flags = current_thread_info()->flags;
 
if (unlikely(r3 >= (unsigned long)-MAX_ERRNO) && !scv) {
if (likely(!(ti_flags & (_TIF_NOERROR | _TIF_RESTOREALL {
@@ -216,7 +215,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
ret = _TIF_RESTOREALL;
else
regs->gpr[3] = r3;
-   clear_bits(_TIF_PERSYSCALL_MASK, ti_flagsp);
+   clear_bits(_TIF_PERSYSCALL_MASK, ¤t_thread_info()->flags);
} else {
regs->gpr[3] = r3;
}
@@ -228,7 +227,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
 
 again:
local_irq_disable();
-   ti_flags = READ_ONCE(*ti_flagsp);
+   ti_flags = READ_ONCE(current_thread_info()->flags);
while (unlikely(ti_flags & (_TIF_USER_WORK_MASK & ~_TIF_RESTORE_TM))) {
local_irq_enable();
if (ti_flags & _TIF_NEED_RESCHED) {
@@ -244,7 +243,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
do_notify_resume(regs, ti_flags);
}
local_irq_disable();
-   ti_flags = READ_ONCE(*ti_flagsp);
+   ti_flags = READ_ONCE(current_thread_info()->flags);
}
 
if (IS_ENABLED(CONFIG_PPC_BOOK3S) && IS_ENABLED(CONFIG_PPC_FPU)) {
-- 
2.25.0

[PATCH v4 07/23] powerpc/8xx: Create C version of kuap_user/kernel_restore() and friends

[Christophe Leroy]

In preparation of porting PPC32 to C syscall entry/exit,
create C version of kuap_user_restore() and kuap_kernel_restore()
and kuap_check() and kuap_get_and_check() on 8xx

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/nohash/32/kup-8xx.h | 27 
 1 file changed, 27 insertions(+)

diff --git a/arch/powerpc/include/asm/nohash/32/kup-8xx.h 
b/arch/powerpc/include/asm/nohash/32/kup-8xx.h
index 17a4a616436f..5ca6c375f767 100644
--- a/arch/powerpc/include/asm/nohash/32/kup-8xx.h
+++ b/arch/powerpc/include/asm/nohash/32/kup-8xx.h
@@ -34,6 +34,33 @@
 
 #include 
 
+static inline void kuap_user_restore(struct pt_regs *regs)
+{
+}
+
+static inline void kuap_kernel_restore(struct pt_regs *regs, unsigned long 
kuap)
+{
+   mtspr(SPRN_MD_AP, kuap);
+}
+
+static inline void kuap_check(void)
+{
+   if (!IS_ENABLED(CONFIG_PPC_KUAP_DEBUG))
+   return;
+
+   WARN_ON_ONCE(mfspr(SPRN_MD_AP) >> 16 != MD_APG_KUAP >> 16);
+}
+
+static inline unsigned long kuap_get_and_check(void)
+{
+   unsigned long kuap = mfspr(SPRN_MD_AP);
+
+   if (IS_ENABLED(CONFIG_PPC_KUAP_DEBUG))
+   WARN_ON_ONCE(mfspr(SPRN_MD_AP) >> 16 != MD_APG_KUAP >> 16);
+
+   return kuap;
+}
+
 static inline void allow_user_access(void __user *to, const void __user *from,
 unsigned long size, unsigned long dir)
 {
-- 
2.25.0

[PATCH v4 11/23] powerpc/syscall: Rename syscall_64.c into syscall.c

[Christophe Leroy]

syscall_64.c will be reused almost as is for PPC32.

Rename it syscall.c

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/Makefile| 2 +-
 arch/powerpc/kernel/{syscall_64.c => syscall.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename arch/powerpc/kernel/{syscall_64.c => syscall.c} (100%)

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index fe2ef598e2ea..1cbc51fc82fd 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -49,7 +49,7 @@ obj-y := cputable.o syscalls.o \
   hw_breakpoint_constraints.o
 obj-y  += ptrace/
 obj-$(CONFIG_PPC64)+= setup_64.o \
-  paca.o nvram_64.o note.o syscall_64.o
+  paca.o nvram_64.o note.o syscall.o
 obj-$(CONFIG_COMPAT)   += sys_ppc32.o signal_32.o
 obj-$(CONFIG_VDSO32)   += vdso32/
 obj-$(CONFIG_PPC_WATCHDOG) += watchdog.o
diff --git a/arch/powerpc/kernel/syscall_64.c b/arch/powerpc/kernel/syscall.c
similarity index 100%
rename from arch/powerpc/kernel/syscall_64.c
rename to arch/powerpc/kernel/syscall.c
-- 
2.25.0

[PATCH v4 06/23] powerpc/32s: Create C version of kuap_user/kernel_restore() and friends

[Christophe Leroy]

In preparation of porting PPC32 to C syscall entry/exit,
create C version of kuap_user_restore() and kuap_kernel_restore()
and kuap_check() and kuap_get_and_check() on book3s/32.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/book3s/32/kup.h | 33 
 1 file changed, 33 insertions(+)

diff --git a/arch/powerpc/include/asm/book3s/32/kup.h 
b/arch/powerpc/include/asm/book3s/32/kup.h
index a0117a9d5b06..a3e72e1141c5 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -103,6 +103,39 @@ static inline void kuap_update_sr(u32 sr, u32 addr, u32 
end)
isync();/* Context sync required after mtsrin() */
 }
 
+static inline void kuap_user_restore(struct pt_regs *regs)
+{
+}
+
+static inline void kuap_kernel_restore(struct pt_regs *regs, unsigned long 
kuap)
+{
+   u32 addr = kuap & 0xf000;
+   u32 end = kuap << 28;
+
+   if (unlikely(!kuap))
+   return;
+
+   current->thread.kuap = 0;
+   kuap_update_sr(mfsrin(addr) & ~SR_KS, addr, end);   /* Clear Ks */
+}
+
+static inline void kuap_check(void)
+{
+   if (!IS_ENABLED(CONFIG_PPC_KUAP_DEBUG))
+   return;
+
+   WARN_ON_ONCE(current->thread.kuap != 0);
+}
+
+static inline unsigned long kuap_get_and_check(void)
+{
+   unsigned long kuap = current->thread.kuap;
+
+   WARN_ON_ONCE(IS_ENABLED(CONFIG_PPC_KUAP_DEBUG) && kuap != 0);
+
+   return kuap;
+}
+
 static __always_inline void allow_user_access(void __user *to, const void 
__user *from,
  u32 size, unsigned long dir)
 {
-- 
2.25.0

[PATCH v4 05/23] powerpc/64s: Make kuap_check_amr() and kuap_get_and_check_amr() generic

[Christophe Leroy]

In preparation of porting powerpc32 to C syscall entry/exit,
rename kuap_check_amr() and kuap_get_and_check_amr() as kuap_check()
and kuap_get_and_check(), and move in the generic asm/kup.h the stub
for when CONFIG_PPC_KUAP is not selected.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/book3s/64/kup.h | 24 ++--
 arch/powerpc/include/asm/kup.h   |  9 -
 arch/powerpc/kernel/syscall_64.c | 12 ++--
 3 files changed, 16 insertions(+), 29 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/kup.h 
b/arch/powerpc/include/asm/book3s/64/kup.h
index f50f72e535aa..1507681ad4ef 100644
--- a/arch/powerpc/include/asm/book3s/64/kup.h
+++ b/arch/powerpc/include/asm/book3s/64/kup.h
@@ -281,7 +281,7 @@ static inline void kuap_kernel_restore(struct pt_regs *regs,
 */
 }
 
-static inline unsigned long kuap_get_and_check_amr(void)
+static inline unsigned long kuap_get_and_check(void)
 {
if (mmu_has_feature(MMU_FTR_BOOK3S_KUAP)) {
unsigned long amr = mfspr(SPRN_AMR);
@@ -292,27 +292,7 @@ static inline unsigned long kuap_get_and_check_amr(void)
return 0;
 }
 
-#else /* CONFIG_PPC_PKEY */
-
-static inline void kuap_user_restore(struct pt_regs *regs)
-{
-}
-
-static inline void kuap_kernel_restore(struct pt_regs *regs, unsigned long amr)
-{
-}
-
-static inline unsigned long kuap_get_and_check_amr(void)
-{
-   return 0;
-}
-
-#endif /* CONFIG_PPC_PKEY */
-
-
-#ifdef CONFIG_PPC_KUAP
-
-static inline void kuap_check_amr(void)
+static inline void kuap_check(void)
 {
if (IS_ENABLED(CONFIG_PPC_KUAP_DEBUG) && 
mmu_has_feature(MMU_FTR_BOOK3S_KUAP))
WARN_ON_ONCE(mfspr(SPRN_AMR) != AMR_KUAP_BLOCKED);
diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
index bf221a2a523e..6ef9f9cfbed0 100644
--- a/arch/powerpc/include/asm/kup.h
+++ b/arch/powerpc/include/asm/kup.h
@@ -66,7 +66,14 @@ bad_kuap_fault(struct pt_regs *regs, unsigned long address, 
bool is_write)
return false;
 }
 
-static inline void kuap_check_amr(void) { }
+static inline void kuap_check(void) { }
+static inline void kuap_user_restore(struct pt_regs *regs) { }
+static inline void kuap_kernel_restore(struct pt_regs *regs, unsigned long 
amr) { }
+
+static inline unsigned long kuap_get_and_check(void)
+{
+   return 0;
+}
 
 /*
  * book3s/64/kup-radix.h defines these functions for the !KUAP case to flush
diff --git a/arch/powerpc/kernel/syscall_64.c b/arch/powerpc/kernel/syscall_64.c
index 32f72965da26..b627a6384029 100644
--- a/arch/powerpc/kernel/syscall_64.c
+++ b/arch/powerpc/kernel/syscall_64.c
@@ -65,7 +65,7 @@ notrace long system_call_exception(long r3, long r4, long r5,
isync();
} else
 #endif
-   kuap_check_amr();
+   kuap_check();
 
account_cpu_user_entry();
 
@@ -181,7 +181,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
 
CT_WARN_ON(ct_state() == CONTEXT_USER);
 
-   kuap_check_amr();
+   kuap_check();
 
regs->result = r3;
 
@@ -303,7 +303,7 @@ notrace unsigned long interrupt_exit_user_prepare(struct 
pt_regs *regs, unsigned
 * We don't need to restore AMR on the way back to userspace for KUAP.
 * AMR can only have been unlocked if we interrupted the kernel.
 */
-   kuap_check_amr();
+   kuap_check();
 
local_irq_save(flags);
 
@@ -381,7 +381,7 @@ notrace unsigned long interrupt_exit_kernel_prepare(struct 
pt_regs *regs, unsign
unsigned long *ti_flagsp = ¤t_thread_info()->flags;
unsigned long flags;
unsigned long ret = 0;
-   unsigned long amr;
+   unsigned long kuap;
 
if (IS_ENABLED(CONFIG_PPC_BOOK3S) && unlikely(!(regs->msr & MSR_RI)))
unrecoverable_exception(regs);
@@ -394,7 +394,7 @@ notrace unsigned long interrupt_exit_kernel_prepare(struct 
pt_regs *regs, unsign
if (TRAP(regs) != 0x700)
CT_WARN_ON(ct_state() == CONTEXT_USER);
 
-   amr = kuap_get_and_check_amr();
+   kuap = kuap_get_and_check();
 
if (unlikely(*ti_flagsp & _TIF_EMULATE_STACK_STORE)) {
clear_bits(_TIF_EMULATE_STACK_STORE, ti_flagsp);
@@ -446,7 +446,7 @@ notrace unsigned long interrupt_exit_kernel_prepare(struct 
pt_regs *regs, unsign
 * which would cause Read-After-Write stalls. Hence, we take the AMR
 * value from the check above.
 */
-   kuap_kernel_restore(regs, amr);
+   kuap_kernel_restore(regs, kuap);
 
return ret;
 }
-- 
2.25.0

Re: [PATCH v3 00/17] KVM: x86/pmu: Add support to enable Guest PEBS via DS

[Liuxiangdong (Aven, Cloud Infrastructure Service Product Dept.)]

Thanks for replying,

On 2021/1/25 10:41, Like Xu wrote:

+ k...@vger.kernel.org

Hi Liuxiangdong,

On 2021/1/22 18:02, Liuxiangdong (Aven, Cloud Infrastructure Service 
Product Dept.) wrote:

Hi Like,

Some questions about 
https://lore.kernel.org/kvm/20210104131542.495413-1-like...@linux.intel.com/ 
 



Thanks for trying the PEBS feature in the guest,
and I assume you have correctly applied the QEMU patches for guest PEBS.

Is there any other patch that needs to be apply? I use qemu 5.2.0. 
(download from github on January 14th)



1)Test in IceLake


In the [PATCH v3 10/17] KVM: x86/pmu: Expose CPUIDs feature bits PDCM, 
DS, DTES64, we only support Ice Lake with the following x86_model(s):


#define INTEL_FAM6_ICELAKE_X0x6A
#define INTEL_FAM6_ICELAKE_D0x6C

you can check the eax output of "cpuid -l 1 -1 -r",
for example "0x000606a4" meets this requirement.

It's INTEL_FAM6_ICELAKE_X
cpuid -l 1 -1 -r

CPU:
   0x0001 0x00: eax=0x000606a6 ebx=0xb4800800 ecx=0x7ffefbf7 
edx=0xbfebfbff




HOST:

CPU family:  6

Model:   106

Model name:  Intel(R) Xeon(R) Platinum 8378A CPU 
$@ $@


microcode: sig=0x606a6, pf=0x1, revision=0xd000122


As long as you get the latest BIOS from the provider,
you may check 'cat /proc/cpuinfo | grep code | uniq' with the latest one.

OK. I'll do it later.




Guest:  linux kernel 5.11.0-rc2


I assume it's the "upstream tag v5.11-rc2" which is fine.

Yes.




We can find pebs/intel_pt flag in guest cpuinfo, but there still 
exists error when we use perf


Just a note, intel_pt and pebs are two features and we can write
pebs records to intel_pt buffer with extra hardware support.
(by default, pebs records are written to the pebs buffer)

You may check the output of "dmesg | grep PEBS" in the guest
to see if the guest PEBS cpuinfo is exposed and use "perf record
–e cycles:pp" to see if PEBS feature actually  works in the guest.


I apply only pebs patch set to linux kernel 5.11.0-rc2, test perf in 
guest and dump stack when return -EOPNOTSUPP


(1)
# perf record -e instructions:pp
Error:
instructions:pp: PMU Hardware doesn't support 
sampling/overflow-interrupts. Try 'perf stat'


[  117.793266] Call Trace:
[  117.793270]  dump_stack+0x57/0x6a
[  117.793275]  intel_pmu_setup_lbr_filter+0x137/0x190
[  117.793280]  intel_pmu_hw_config+0x18b/0x320
[  117.793288]  hsw_hw_config+0xe/0xa0
[  117.793290]  x86_pmu_event_init+0x8e/0x210
[  117.793293]  perf_try_init_event+0x40/0x130
[  117.793297]  perf_event_alloc.part.22+0x611/0xde0
[  117.793299]  ? alloc_fd+0xba/0x180
[  117.793302]  __do_sys_perf_event_open+0x1bd/0xd90
[  117.793305]  do_syscall_64+0x33/0x40
[  117.793308]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Do we need lbr when we use pebs?

I tried to apply lbr patch 
set(https://lore.kernel.org/kvm/911adb63-ba05-ea93-c038-1c09cff15...@intel.com/) 
to kernel and qemu, but there is still other problem.

Error:
The sys_perf_event_open() syscall returned with 22 (Invalid argument) 
for event

...

(2)
# perf record -e instructions:ppp
Error:
instructions:ppp: PMU Hardware doesn't support 
sampling/overflow-interrupts. Try 'perf stat'


[  115.188498] Call Trace:
[  115.188503]  dump_stack+0x57/0x6a
[  115.188509]  x86_pmu_hw_config+0x1eb/0x220
[  115.188515]  intel_pmu_hw_config+0x13/0x320
[  115.188519]  hsw_hw_config+0xe/0xa0
[  115.188521]  x86_pmu_event_init+0x8e/0x210
[  115.188524]  perf_try_init_event+0x40/0x130
[  115.188528]  perf_event_alloc.part.22+0x611/0xde0
[  115.188530]  ? alloc_fd+0xba/0x180
[  115.188534]  __do_sys_perf_event_open+0x1bd/0xd90
[  115.188538]  do_syscall_64+0x33/0x40
[  115.188541]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

This is beacuse x86_pmu.intel_cap.pebs_format is always 0 in 
x86_pmu_max_precise().


We rdmsr MSR_IA32_PERF_CAPABILITIES(0x0345)  from HOST, it's f4c5.
From guest, it's 2000



# perf record –e cycles:pp

Error:

cycles:pp: PMU Hardware doesn’t support sampling/overflow-interrupts. 
Try ‘perf stat’


Could you give some advice?


If you have more specific comments or any concerns, just let me know.



2)Test in Skylake

HOST:

CPU family:  6

Model:   85

Model name:  Intel(R) Xeon(R) Gold 6146 CPU @

   3.20GHz

microcode: 0x264

Guest: linux 4.18

we cannot find intel_pt flag in guest cpuinfo because 
cpu_has_vmx_intel_pt() return false.


You may check vmx_pebs_supported().

It's true.




SECONDARY_EXEC_PT_USE_GPA/VM_EXIT_CLEAR_IA32_RTIT_CTL/VM_ENTRY_LOAD_IA32_RTIT_CTL 
are both disable.


Is it because microcode is not supported?

And, isthere a new macrocode which can support these bits? How can we 
get this?


Currently, this patch set doesn't support guest PEBS on the Skylake
platforms, and if we choose to support it, we will let you know.

And now,

Re: [PATCH] sched/fair: Rate limit calls to update_blocked_averages() for NOHZ

[Vincent Guittot]

On Fri, 22 Jan 2021 at 20:10, Joel Fernandes  wrote:
>
> Hi Vincent,
>
> Thanks for reply. Please see the replies below:
>
> On Fri, Jan 22, 2021 at 05:56:22PM +0100, Vincent Guittot wrote:
> > On Fri, 22 Jan 2021 at 16:46, Joel Fernandes (Google)
> >  wrote:
> > >
> > > On an octacore ARM64 device running ChromeOS Linux kernel v5.4, I found
> > > that there are a lot of calls to update_blocked_averages(). This causes
> > > the schedule loop to slow down to taking upto 500 micro seconds at
> > > times (due to newidle load balance). I have also seen this manifest in
> > > the periodic balancer.
> > >
> > > Closer look shows that the problem is caused by the following
> > > ingredients:
> > > 1. If the system has a lot of inactive CGroups (thanks Dietmar for
> > > suggesting to inspect /proc/sched_debug for this), this can make
> > > __update_blocked_fair() take a long time.
> >
> > Inactive cgroups are removed from the list so they should not impact
> > the duration
>
> I meant blocked CGroups. According to this code, a cfs_rq can be partially
> decayed and not have any tasks running on it but its load needs to be
> decayed, correct? That's what I meant by 'inactive'. I can reword it to
> 'blocked'.

How many blocked cgroups have you got ?

>
>   * There can be a lot of idle CPU cgroups.  Don't let fully
>   * decayed cfs_rqs linger on the list.
>   */
>  if (cfs_rq_is_decayed(cfs_rq))
>  list_del_leaf_cfs_rq(cfs_rq);
>
> > > 2. The device has a lot of CPUs in a cluster which causes schedutil in a
> > > shared frequency domain configuration to be slower than usual. (the load
> >
> > What do you mean exactly by it causes schedutil to be slower than usual ?
>
> sugov_next_freq_shared() is order number of CPUs in the a cluster. This
> system is a 6+2 system with 6 CPUs in a cluster. schedutil shared policy
> frequency update needs to go through utilization of other CPUs in the
> cluster. I believe this could be adding to the problem but is not really
> needed to optimize if we can rate limit the calls to update_blocked_averages
> to begin with.

Qais mentioned half of the time being used by
sugov_next_freq_shared(). Are there any frequency changes resulting in
this call ?

>
> > > average updates also try to update the frequency in schedutil).
> > >
> > > 3. The CPU is running at a low frequency causing the scheduler/schedutil
> > > code paths to take longer than when running at a high CPU frequency.
> >
> > Low frequency usually means low utilization so it should happen that much.
>
> It happens a lot as can be seen with schbench. It is super easy to reproduce.

Happening a lot in itself is not a problem if there is nothing else to
do so it's not a argument in itself

So why is it a problem for you ? You are mentioning newly idle load
balance so I assume that your root problem is the scheduling delay
generated by the newly idle load balance which then calls
update_blocked_averages

rate limiting the call to update_blocked_averages() will only reduce
the number of time it happens but it will not prevent it to happen.

>
> schedule() can result in new idle balance with the CFS pick call happening
> often. Here is a function graph trace.  The tracer shows
> update_blocked_averages taking a lot of time.
>
>  sugov:0-2454  [002]  2657.992570: funcgraph_entry:   |  
> load_balance() {
>  sugov:0-2454  [002]  2657.992577: funcgraph_entry:   |   
>  update_group_capacity() {
>  sugov:0-2454  [002]  2657.992580: funcgraph_entry:2.656 us   |   
>__msecs_to_jiffies();
>  sugov:0-2454  [002]  2657.992585: funcgraph_entry:2.447 us   |   
>_raw_spin_lock_irqsave();
>  sugov:0-2454  [002]  2657.992591: funcgraph_entry:2.552 us   |   
>_raw_spin_unlock_irqrestore();
>  sugov:0-2454  [002]  2657.992595: funcgraph_exit:   + 17.448 us  |   
>  }
>  sugov:0-2454  [002]  2657.992597: funcgraph_entry:1.875 us   |   
>  update_nohz_stats();
>  sugov:0-2454  [002]  2657.992601: funcgraph_entry:1.667 us   |   
>  idle_cpu();
>  sugov:0-2454  [002]  2657.992605: funcgraph_entry:   |   
>  update_nohz_stats() {
>  sugov:0-2454  [002]  2657.992608: funcgraph_entry:  + 33.333 us  |   
>update_blocked_averages();
>  sugov:0-2454  [002]  2657.992643: funcgraph_exit:   + 38.073 us  |   
>  }
>  sugov:0-2454  [002]  2657.992645: funcgraph_entry:1.770 us   |   
>  idle_cpu();
>  sugov:0-2454  [002]  2657.992649: funcgraph_entry:   |   
>  update_nohz_stats() {
>  sugov:0-2454  [002]  2657.992651: funcgraph_entry:  + 41.823 us  |   
>update_blocked_averages();
>  sugov:0-2454  [002]  2657.992694: funcgraph_exit:   + 45.729 us  |   
>  }
>  sugov:0-2454  [002]  2657.992696: funcgraph_entry:1.823 us   |   
>  idle_cpu();
>  sugov:0-245

Re: [PATCH v3 0/2] net: sfp: add support for GPON RTL8672/RTL9601C and Ubiquiti U-Fiber

[Russell King - ARM Linux admin]

On Mon, Jan 25, 2021 at 03:23:01PM +0100, Pali Rohár wrote:
> On Monday 25 January 2021 14:16:44 Russell King - ARM Linux admin wrote:
> > On Mon, Jan 25, 2021 at 03:09:57PM +0100, Pali Rohár wrote:
> > > On Monday 18 January 2021 10:34:35 Pali Rohár wrote:
> > > > On Monday 11 January 2021 12:39:07 Pali Rohár wrote:
> > > > > This is a third version of patches which add workarounds for
> > > > > RTL8672/RTL9601C EEPROMs and Ubiquiti U-Fiber Instant SFP.
> > > > > 
> > > > > Russel's PATCH v2 2/3 was dropped from this patch series as
> > > > > it is being handled separately.
> > > > 
> > > > Andrew and Russel, are you fine with this third iteration of patches?
> > > > Or are there still some issues which needs to be fixed?
> > > 
> > > PING!
> > 
> > What about the commit message suggestions from Marek?
> 
> I have already wrote that I'm fine with those suggestions.
> 
> It is the only thing to handle? If yes, should I send a new patch series
> with fixed commit messages?

Yes, because that's the way the netdev list works - patches sent to
netdev go into patchwork, when they get reviewed and acks etc,
patchwork updates itself. Jakub or David can then see what the status
is and apply them to the net or net-next trees as appropriate.

The "finished" patches need to be posted for this process to start.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

[PATCH] ntp: Use freezable workqueue for RTC synchronization

[Geert Uytterhoeven]

The bug fixed by commit e3fab2f3de081e98 ("ntp: Fix RTC synchronization
on 32-bit platforms") revealed an underlying issue: RTC synchronization
may happen anytime, even while the system is partially suspended.

On systems where the RTC is connected to an I2C bus, the I2C bus
controller may already or still be suspended, triggering a WARNING
during suspend or resume from s2ram:

WARNING: CPU: 0 PID: 124 at drivers/i2c/i2c-core.h:54 
__i2c_transfer+0x634/0x680
i2c i2c-6: Transfer while suspended
[...]
Workqueue: events_power_efficient sync_hw_clock
[...]
[] (__i2c_transfer) from [] (i2c_transfer+0x58/0xf8)
[] (i2c_transfer) from [] (regmap_i2c_read+0x58/0x94)
[] (regmap_i2c_read) from [] 
(_regmap_raw_read+0x19c/0x2f4)
[] (_regmap_raw_read) from [] 
(_regmap_bus_read+0x44/0x68)
[] (_regmap_bus_read) from [] (_regmap_read+0x84/0x1a4)
[] (_regmap_read) from [] 
(_regmap_update_bits+0xa8/0xf4)
[] (_regmap_update_bits) from [] 
(_regmap_select_page+0xe4/0x100)
[] (_regmap_select_page) from [] 
(_regmap_raw_write_impl+0xd4/0x6c4)
[] (_regmap_raw_write_impl) from [] 
(_regmap_raw_write+0xd8/0x114)
[] (_regmap_raw_write) from [] 
(regmap_raw_write+0x58/0x7c)
[] (regmap_raw_write) from [] 
(regmap_bulk_write+0x118/0x13c)
[] (regmap_bulk_write) from [] 
(da9063_rtc_set_time+0x44/0x8c)
[] (da9063_rtc_set_time) from [] 
(rtc_set_time+0xc8/0x228)
[] (rtc_set_time) from [] (sync_hw_clock+0x128/0x1fc)
[] (sync_hw_clock) from [] 
(process_one_work+0x330/0x550)
[] (process_one_work) from [] 
(worker_thread+0x22c/0x2ec)

Fix this race condition by using the freezable instead of the normal
power-efficient workqueue.

Signed-off-by: Geert Uytterhoeven 
---
 kernel/time/ntp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 54d52fab201d283e..6310328fe398406a 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -502,7 +502,7 @@ static struct hrtimer sync_hrtimer;
 
 static enum hrtimer_restart sync_timer_callback(struct hrtimer *timer)
 {
-   queue_work(system_power_efficient_wq, &sync_work);
+   queue_work(system_freezable_power_efficient_wq, &sync_work);
 
return HRTIMER_NORESTART;
 }
@@ -668,7 +668,7 @@ void ntp_notify_cmos_timer(void)
 * just a pointless work scheduled.
 */
if (ntp_synced() && !hrtimer_is_queued(&sync_hrtimer))
-   queue_work(system_power_efficient_wq, &sync_work);
+   queue_work(system_freezable_power_efficient_wq, &sync_work);
 }
 
 static void __init ntp_init_cmos_sync(void)
-- 
2.25.1

Re: [PATCH] ARM: multi_v7_defconfig: add STM32 CEC support

[Alexandre TORGUE]

Hi Yannick

On 1/15/21 3:32 PM, Yannick Fertre wrote:

Enable CEC support for STMicroelectronics as loadable module.

Signed-off-by: Yannick Fertre 
---
  arch/arm/configs/multi_v7_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index c5f25710fedc..05cc0607a9ad 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -656,6 +656,7 @@ CONFIG_V4L_TEST_DRIVERS=y
  CONFIG_VIDEO_VIVID=m
  CONFIG_CEC_PLATFORM_DRIVERS=y
  CONFIG_CEC_SAMSUNG_S5P=m
+CONFIG_CEC_STM32=m
  CONFIG_VIDEO_ADV7180=m
  CONFIG_VIDEO_ADV7604=m
  CONFIG_VIDEO_ADV7604_CEC=y



Applied on stm32-next.

Thanks.
Alex

Re: [PATCH v4 1/3] arm64: Improve kernel address detection of __is_lm_address()

[Vincenzo Frascino]

Hi Mark,

On 1/25/21 1:02 PM, Mark Rutland wrote:
> Hi Vincenzo,
> 
> On Fri, Jan 22, 2021 at 03:56:40PM +, Vincenzo Frascino wrote:
>> Currently, the __is_lm_address() check just masks out the top 12 bits
>> of the address, but if they are 0, it still yields a true result.
>> This has as a side effect that virt_addr_valid() returns true even for
>> invalid virtual addresses (e.g. 0x0).
>>
>> Improve the detection checking that it's actually a kernel address
>> starting at PAGE_OFFSET.
>>
>> Cc: Catalin Marinas 
>> Cc: Will Deacon 
>> Suggested-by: Catalin Marinas 
>> Reviewed-by: Catalin Marinas 
>> Signed-off-by: Vincenzo Frascino 
> 
> Looking around, it seems that there are some existing uses of
> virt_addr_valid() that expect it to reject addresses outside of the
> TTBR1 range. For example, check_mem_type() in drivers/tee/optee/call.c.
> 
> Given that, I think we need something that's easy to backport to stable.
> 

I agree, I started looking at it this morning and I found cases even in the main
allocators (slub and page_alloc) either then the one you mentioned.

> This patch itself looks fine, but it's not going to backport very far,
> so I suspect we might need to write a preparatory patch that adds an
> explicit range check to virt_addr_valid() which can be trivially
> backported.
> 

I checked the old releases and I agree this is not back-portable as it stands.
I propose therefore to add a preparatory patch with the check below:

#define __is_ttrb1_address(addr)((u64)(addr) >= PAGE_OFFSET && \
(u64)(addr) < PAGE_END)

If it works for you I am happy to take care of it and post a new version of my
patches.

Thanks!

> For this patch:
> 
> Acked-by: Mark Rutland 
> 
> Thanks,
> Mark.
> 
>> ---
>>  arch/arm64/include/asm/memory.h | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/memory.h 
>> b/arch/arm64/include/asm/memory.h
>> index 18fce223b67b..99d7e1494aaa 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -247,9 +247,11 @@ static inline const void *__tag_set(const void *addr, 
>> u8 tag)
>>  
>>  
>>  /*
>> - * The linear kernel range starts at the bottom of the virtual address 
>> space.
>> + * Check whether an arbitrary address is within the linear map, which
>> + * lives in the [PAGE_OFFSET, PAGE_END) interval at the bottom of the
>> + * kernel's TTBR1 address range.
>>   */
>> -#define __is_lm_address(addr)   (((u64)(addr) & ~PAGE_OFFSET) < 
>> (PAGE_END - PAGE_OFFSET))
>> +#define __is_lm_address(addr)   (((u64)(addr) ^ PAGE_OFFSET) < 
>> (PAGE_END - PAGE_OFFSET))
>>  
>>  #define __lm_to_phys(addr)  (((addr) & ~PAGE_OFFSET) + PHYS_OFFSET)
>>  #define __kimg_to_phys(addr)((addr) - kimage_voffset)
>> -- 
>> 2.30.0
>>

-- 
Regards,
Vincenzo

Re: [PATCH 1/3] kvfree_rcu: Allocate a page for a single argument

[Uladzislau Rezki]

> On Wed 20-01-21 17:21:46, Uladzislau Rezki (Sony) wrote:
> > For a single argument we can directly request a page from a caller
> > context when a "carry page block" is run out of free spots. Instead
> > of hitting a slow path we can request an extra page by demand and
> > proceed with a fast path.
> > 
> > A single-argument kvfree_rcu() must be invoked in sleepable contexts,
> > and that its fallback is the relatively high latency synchronize_rcu().
> > Single-argument kvfree_rcu() therefore uses GFP_KERNEL|__GFP_RETRY_MAYFAIL
> > to allow limited sleeping within the memory allocator.
> 
> __GFP_RETRY_MAYFAIL can be quite heavy. It is effectively the most heavy
> way to allocate without triggering the OOM killer. Is this really what
> you need/want? Is __GFP_NORETRY too weak?
> 
Hm... We agreed to proceed with limited lightwait memory direct reclaim.
Johannes Weiner proposed to go with __GFP_NORETRY flag as a starting
point: https://www.spinics.net/lists/rcu/msg02856.html


So I'm inclined to suggest __GFP_NORETRY as a starting point, and make
further decisions based on instrumentation of the success rates of
these opportunistic allocations.


but for some reason, i can't find a tail or head of it, we introduced
__GFP_RETRY_MAYFAIL what is a heavy one from a time consuming point of view.
What we would like to avoid.

I tend to say that it was a typo.

Thank you for pointing to it!

--
Vlad Rezki

Re: [PATCH] rtlwifi: rtl8821ae: style: Simplify bool comparison

[Kalle Valo]

YANG LI  wrote:

> Fix the following coccicheck warning:
> ./drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:3853:7-17:
> WARNING: Comparison of 0/1 to bool variable
> 
> Reported-by: Abaci Robot 
> Signed-off-by: YANG LI 

Patchwork gives me this From field:

From: Jiapeng Zhong 

I guess you are sharing the same email address with multiple persons? And 
patchwork stored the first person using that address?

I recommend using individual addresses for each person submitting patches. I
cannot apply this.

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/1610440409-73330-1-git-send-email-abaci-bug...@linux.alibaba.com/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [BACKPORT 5.4 PATCH] pinctrl: ingenic: Fix JZ4760 support

[gregkh]

On Sun, Jan 24, 2021 at 01:49:32PM +, Paul Cercueil wrote:
> 
> 
> Le dim. 24 janv. 2021 à 13:47, Paul Cercueil  a écrit
> :
> > - JZ4760 and JZ4760B have a similar register layout as the JZ4740, and
> >   don't use the new register layout, which was introduced with the
> >   JZ4770 SoC and not the JZ4760 or JZ4760B SoCs.
> > 
> > - The JZ4740 code path only expected two function modes to be
> >   configurable for each pin, and wouldn't work with more than two. Fix
> >   it for the JZ4760, which has four configurable function modes.
> 
> Forgot to add the original commit ID:
> 9a85c09a3f507b925d75cb0c7c8f364467038052

Thanks, now queued up.

greg k-h

Re: [PATCH v3] x86: Treat R_386_PLT32 as R_386_PC32

[Borislav Petkov]

It's a good thing I have a toolchain guy who can explain to me what you
guys are doing because you need to start writing those commit messages
for !toolchain developers.

On Thu, Jan 14, 2021 at 02:48:19PM -0800, Fangrui Song wrote:
> This is similar to commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as
> R_X86_64_PC32"), but for i386.  As far as Linux kernel is concerned,
> R_386_PLT32 can be treated the same as R_386_PC32.
> 
> R_386_PC32/R_X86_64_PC32 are PC-relative relocation types with the
> requirement that the symbol address is significant.
> R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types without the
> address significance requirement.

I was told what "significant" means in that context and while it is
clear to you, I'm pretty sure it is not clear to kernel developers who
haven't looked at toolchains in depth. So please elaborate.

> On x86-64, there is no PIC vs non-PIC PLT distinction and an
> R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and
> `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler.

Also, please explain in short why LLVM is generating R_X86_64_PLT32
relocs now? I.e., is it the same reason as why binutils does that?

I.e., mentioning the big picture of things would help as to why you're
doing this.

> On i386, there are 2 types of PLTs, PIC and non-PIC. Currently the
> convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC
> PLT.

Convention in general or convention for LLVM?

> clang-12 -fno-pic (since
> https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de008232da3f1d6)
> can emit R_386_PLT32 for compiler generated function declarations as
> well to avoid a canonical PLT entry (st_shndx=0, st_value!=0) if the
> symbol turns out to be defined externally. GCC/GNU as will likely keep
> using R_386_PC32 because (1) the ABI is legacy (2) the change will drop
> a GNU ld non-default visibility ifunc for shared objects.
> https://sourceware.org/bugzilla/show_bug.cgi?id=27169

Not sure how useful this paragraph is for kernel developers...

> Link: https://github.com/ClangBuiltLinux/linux/issues/1210
> Reported-by: Arnd Bergmann 
> Signed-off-by: Fangrui Song 
> Reviewed-by: Nick Desaulniers 
> Reviewed-by: Nathan Chancellor 
> Tested-by: Nick Desaulniers 
> Tested-by: Nathan Chancellor 
> 
> ---
> Change in v2:
> * Improve commit message
> ---
> Change in v3:
> * Change the GCC link to the more relevant GNU as link.
> * Fix the relevant llvm-project commit id.
> ---
>  arch/x86/kernel/module.c | 1 +
>  arch/x86/tools/relocs.c  | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
> index 34b153cbd4ac..5e9a34b5bd74 100644
> --- a/arch/x86/kernel/module.c
> +++ b/arch/x86/kernel/module.c
> @@ -114,6 +114,7 @@ int apply_relocate(Elf32_Shdr *sechdrs,
>   *location += sym->st_value;
>   break;
>   case R_386_PC32:
> + case R_386_PLT32:
>   /* Add the value, subtract its position */
>   *location += sym->st_value - (uint32_t)location;
>   break;
> diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
> index ce7188cbdae5..717e48ca28b6 100644
> --- a/arch/x86/tools/relocs.c
> +++ b/arch/x86/tools/relocs.c
> @@ -867,6 +867,7 @@ static int do_reloc32(struct section *sec, Elf_Rel *rel, 
> Elf_Sym *sym,
>   case R_386_PC32:
>   case R_386_PC16:
>   case R_386_PC8:
> + case R_386_PLT32:
>   /*
>* NONE can be ignored and PC relative relocations don't
>* need to be adjusted.

That comment might need adjustment.

> @@ -910,6 +911,7 @@ static int do_reloc_real(struct section *sec, Elf_Rel 
> *rel, Elf_Sym *sym,
>   case R_386_PC32:
>   case R_386_PC16:
>   case R_386_PC8:
> + case R_386_PLT32:
>   /*
>* NONE can be ignored and PC relative relocations don't
>* need to be adjusted.

Ditto.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v3 0/2] net: sfp: add support for GPON RTL8672/RTL9601C and Ubiquiti U-Fiber

[Pali Rohár]

On Monday 25 January 2021 14:16:44 Russell King - ARM Linux admin wrote:
> On Mon, Jan 25, 2021 at 03:09:57PM +0100, Pali Rohár wrote:
> > On Monday 18 January 2021 10:34:35 Pali Rohár wrote:
> > > On Monday 11 January 2021 12:39:07 Pali Rohár wrote:
> > > > This is a third version of patches which add workarounds for
> > > > RTL8672/RTL9601C EEPROMs and Ubiquiti U-Fiber Instant SFP.
> > > > 
> > > > Russel's PATCH v2 2/3 was dropped from this patch series as
> > > > it is being handled separately.
> > > 
> > > Andrew and Russel, are you fine with this third iteration of patches?
> > > Or are there still some issues which needs to be fixed?
> > 
> > PING!
> 
> What about the commit message suggestions from Marek?

I have already wrote that I'm fine with those suggestions.

It is the only thing to handle? If yes, should I send a new patch series
with fixed commit messages?

Re: [PATCH v2] media: doc: pixfmt-yuv: Fix 4:4:4 subsampling info

[Laurent Pinchart]

Hi Helen,

Thank you for the patch.

On Mon, Jan 25, 2021 at 11:10:29AM -0300, Helen Koike wrote:
> YUV 4:4:4 is not subsampled, fix this in the docs.
> 
> Fixes: da785536e007 ("media: doc: pixfmt-yuv: Move all semi-planar YUV 
> formats to common file")
> Signed-off-by: Helen Koike 

Reviewed-by: Laurent Pinchart 

> ---
> Changes in v2:
> 
> - s/No sub-sampling/The chroma plane is not subsampled/ (Laurent)
> - Fixed description regarding the number of bytes (Laurent)
> ---
>  Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst 
> b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
> index 7d4d39201a3f..1e0db602cc1b 100644
> --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
> +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
> @@ -396,9 +396,9 @@ number of lines as the luma plane.
>  NV24 and NV42
>  -
>  
> -Semi-planar YUV 4:4:4 formats. The chroma plane is subsampled by 2 in the
> -horizontal direction. Chroma lines contain half the number of pixels and the
> -same number of bytes as luma lines, and the chroma plane contains the same
> +Semi-planar YUV 4:4:4 formats. The chroma plane is not subsampled.
> +Chroma lines contain the same number of pixels and twice the
> +number of bytes as luma lines, and the chroma plane contains the same
>  number of lines as the luma plane.
>  
>  .. flat-table:: Sample 4x4 NV24 Image

-- 
Regards,

Laurent Pinchart

Re: [PATCH 0/2] mmc: J7200: Add support for higher speed modes in MMCSD subsystems

[Aswath Govindraju]

Hi Nishanth,

On 25/01/21 7:21 pm, Nishanth Menon wrote:
> On 19:12-20210125, Aswath Govindraju wrote:
>> Hi Nishanth,
>>
>> On 22/01/21 11:36 pm, Nishanth Menon wrote:
>>> On 21:54-20210122, Aswath Govindraju wrote:
>>>> The following series of patches
>>>> - adds support for HS200 and HS400 speed modes in MMCSD0 subsystem
>>>> - adds support for UHS-I speed modes in MMCSD1 subsystem 
>>>>
>>>> Aswath Govindraju (2):
>>>>   arm64: dts: ti: k3-j7200-main: Add support for HS200 and HS400 modes
>>>> in MMCSD0 subsystem
>>>>   arm64: dts: ti: k3-j7200-main: Add support for UHS-I modes in MMCSD1
>>>> subsystem
>>>
>>>
>>> Just a curious couple of questions:
>>> Does squashing both the patches create a problem for understanding or a
>>> later bisect? I kind of thought these mostly go hand in hand between the
>>> instances, am I mistaken?
>>>
>>
>> Yes, they can be squashed. I post a respin doing this.
> 
> Thanks.
> 
>>
>>> Are there any otap delay params update needed or the defaults are good
>>> to go?
>>>
>>
>> The otap values are already up-to-date with the data sheet and don't
>> need updation.
> 
> Thanks for the clarification.
> 
>>
>>> Will also help to provide some verification log along with this.
>>>
>>
>> May I know what sort of logs would be best to provide. Would enumeration
>> logs during boot suffice ?
>>
>> Like this,
>> https://pastebin.ubuntu.com/p/v9NRV7GwMw/ ?
> 
> That just says we detected the cards, no?
> I thought we had tests around this? Something including 
> /sys/kernel/debug/mmc*/ios
> 
> Something that demonstrates that this actually runs at the claimed
> speeds? That would be nice on linux-next, if possible as well..
> 

Yes there are tests which confirm that claimed speeds are functional. I
will add them in the respin.

Thanks,
Aswath

[PATCH] Documentation: arm: marvell: Fix dead link to Armada 37xx Product Brief

[Pali Rohár]

Signed-off-by: Pali Rohár 
---
 Documentation/arm/marvell.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/arm/marvell.rst b/Documentation/arm/marvell.rst
index b16e6f7e8dbe..fa22a72d4391 100644
--- a/Documentation/arm/marvell.rst
+++ b/Documentation/arm/marvell.rst
@@ -183,7 +183,7 @@ EBU Armada family ARMv8
http://www.marvell.com/embedded-processors/armada-3700/
 
   Product Brief:
-   http://www.marvell.com/embedded-processors/assets/PB-88F3700-FNL.pdf
+   
http://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-37xx-product-brief-2016-01.pdf
 
   Hardware Spec:

http://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-37xx-hardware-specifications-2019-09.pdf
-- 
2.20.1

[PATCH 1/2] KVM: arm64: Distinguish cases of allocating memcache more precisely

[Yanan Wang]

With a guest translation fault, we don't really need the memcache pages
when only installing a new entry to the existing page table or replacing
the table entry with a block entry. And with a guest permission fault,
we also don't need the memcache pages for a write_fault in dirty-logging
time if VMs are not configured with huge mappings.

The cases where allocations from memcache are required can be much more
precisely distinguished by comparing fault_granule and vma_pagesize.

Signed-off-by: Yanan Wang 
---
 arch/arm64/kvm/mmu.c | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 7d2257cc5438..8e8549ea1d70 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -820,19 +820,6 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, 
phys_addr_t fault_ipa,
gfn = fault_ipa >> PAGE_SHIFT;
mmap_read_unlock(current->mm);
 
-   /*
-* Permission faults just need to update the existing leaf entry,
-* and so normally don't require allocations from the memcache. The
-* only exception to this is when dirty logging is enabled at runtime
-* and a write fault needs to collapse a block entry into a table.
-*/
-   if (fault_status != FSC_PERM || (logging_active && write_fault)) {
-   ret = kvm_mmu_topup_memory_cache(memcache,
-kvm_mmu_cache_min_pages(kvm));
-   if (ret)
-   return ret;
-   }
-
mmu_seq = vcpu->kvm->mmu_notifier_seq;
/*
 * Ensure the read of mmu_notifier_seq happens before we call
@@ -898,6 +885,18 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, 
phys_addr_t fault_ipa,
else if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC))
prot |= KVM_PGTABLE_PROT_X;
 
+   /*
+* Allocations from the memcache are required only when granule of the
+* lookup level where a guest fault happened exceeds the vma_pagesize,
+* which means new page tables will be created in the fault handlers.
+*/
+   if (fault_granule > vma_pagesize) {
+   ret = kvm_mmu_topup_memory_cache(memcache,
+kvm_mmu_cache_min_pages(kvm));
+   if (ret)
+   return ret;
+   }
+
/*
 * Under the premise of getting a FSC_PERM fault, we just need to relax
 * permissions only if vma_pagesize equals fault_granule. Otherwise,
-- 
2.19.1

Re: [PATCH] mm/filemap: Adding missing mem_cgroup_uncharge() to __add_to_page_cache_locked()

[Waiman Long]

On 1/24/21 11:36 PM, Matthew Wilcox wrote:

On Sun, Jan 24, 2021 at 11:24:41PM -0500, Waiman Long wrote:

diff --git a/mm/filemap.c b/mm/filemap.c
index 5c9d564317a5..aa0e0fb04670 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -835,6 +835,7 @@ noinline int __add_to_page_cache_locked(struct page *page,
XA_STATE(xas, &mapping->i_pages, offset);
int huge = PageHuge(page);
int error;
+   bool charged = false;

I don't think we need this extra bool.


@@ -896,6 +898,8 @@ noinline int __add_to_page_cache_locked(struct page *page,
  
  	if (xas_error(&xas)) {

error = xas_error(&xas);
+   if (charged)
+   mem_cgroup_uncharge(page);
goto error;
}

Better:

-   goto error;
+   goto uncharge;
...
+uncharge:
+   if (!huge)
+   mem_cgroup_uncharge(page);
  error:
...

That was my original plan. After finding out there was a potentially 
conflicting patch in linux-next:


commit 7a02fa97b897 ("secretmem: add memcg accounting")

@@ -839,7 +840,7 @@ noinline int __add_to_page_cache_locked(struct page 
*page,

    page->mapping = mapping;
    page->index = offset;

-   if (!huge) {
+   if (!huge && !page_is_secretmem(page)) {
    error = mem_cgroup_charge(page, current->mm, gfp);
    if (error)
    goto error;

Adding a boolean is an easy way out without conflicting it.

Cheers,
Longman

Re: [GIT PULL] Staging/IIO driver fixes for 5.11-rc5

[Greg KH]

On Sun, Jan 24, 2021 at 11:31:59AM -0800, Linus Torvalds wrote:
> On Sun, Jan 24, 2021 at 4:58 AM Greg KH  wrote:
> >
> > David Lechner (1):
> >   counter:ti-eqep: remove floor
> 
> I'm not sure why that ti-eqep counter driver seems to be in your
> "iio/staging" pile rather than "char/misc", but whatever..

Jonathan said why that was needed, I think it was due to fixes in the
counter core code, but he can verify this better than I can...

thanks,

greg k-h

Re: [RFC PATCH 0/4] make jbd2 debug switch per device

[许春光]

Thanks for your reply.

Jan Kara wrote on 2021/1/25 20:41:
> On Fri 22-01-21 14:43:18, Chunguang Xu wrote:
>> On a multi-disk machine, because jbd2 debugging switch is global, this
>> confuses the logs of multiple disks. It is not easy to distinguish the
>> logs of each disk and the amount of generated logs is very large. Or a
>> separate debugging switch for each disk would be better, so that you
>> can easily distinguish the logs of a certain disk.
>>
>> We can enable jbd2 debugging of a device in the following ways:
>> echo X > /proc/fs/jbd2/sdX/jbd2_debug
>>
>> But there is a small disadvantage here. Because the debugging switch is
>> placed in the journal_t object, the log before the object is initialized
>> will be lost. However, usually this will not have much impact on
>> debugging.
>
> OK, I didn't look at the series yet but I'm wondering: How are you using
> jbd2 debugging? I mean obviously it isn't meant for production use but
> rather for debugging JBD2 bugs so I'm kind of wondering in which case too
> many messages matter.
We perform stress testing on machines in the test environment, and use scripts
to capture journal related logs to analyze problems. There are 12 disks on this
machine, and each disk runs different jobs. Our test kernel also adds
some additional
function-related logs. If we adjust the log level to a higher level, a large
number of logs have nothing to do with the disk to be observed. These logs are
generated by system agents or coordinated tasks. This makes the log difficul
to analyze.

> And if the problem is that there's a problem with distinguishing messages
> from multiple filesystems, then it would be perhaps more useful to add
> journal identification to each message similarly as we do it with ext4
> messages (likely by using journal->j_dev) - which is very simple to do
> after your patches 3 and 4.
Our test kernel did this. Because it broke the log format, I was not
sure whether
it would break something, so I didn't bring this part. Even if the
device information
is added, when there are more disks and the log level is higher, there will be a
lot of irrelevant logs, which makes it necessary to consume a lot of
CPU to filter
messages. Therefore, a device-level switch is provided to make
everything simpler.
>
>   Honza
>

[PATCH] x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled

[Juergen Gross]

When booting a kernel which has been built with CONFIG_AMD_MEM_ENCRYPT
enabled as a Xen pv guest a warning is issued for each processor:

[5.964347] [ cut here ]
[5.968314] WARNING: CPU: 0 PID: 1 at 
/home/gross/linux/head/arch/x86/xen/enlighten_pv.c:660 get_trap_addr+0x59/0x90
[5.972321] Modules linked in:
[5.976313] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 
5.11.0-rc5-default #75
[5.980313] Hardware name: Dell Inc. OptiPlex 9020/0PC5F7, BIOS A05 
12/05/2013
[5.984313] RIP: e030:get_trap_addr+0x59/0x90
[5.988313] Code: 42 10 83 f0 01 85 f6 74 04 84 c0 75 1d b8 01 00 00 00 c3 
48 3d 00 80 83 82 72 08 48 3d 20 81 83 82 72 0c b8 01 00 00 00 eb db <0f> 0b 31 
c0 c3 48 2d 00 80 83 82 48 ba 72 1c c7 71 1c c7 71 1c 48
[5.992313] RSP: e02b:c90040033d38 EFLAGS: 00010202
[5.996313] RAX: 0001 RBX: 82a141d0 RCX: 8222ec38
[6.000312] RDX: 8222ec38 RSI: 0005 RDI: c90040033d40
[6.004313] RBP: 8881003984a0 R08: 0007 R09: 888100398000
[6.008312] R10: 0007 R11: c90040246000 R12: 8884082182a8
[6.012313] R13: 0100 R14: 001d R15: 8881003982d0
[6.016316] FS:  () GS:88840820() 
knlGS:
[6.020313] CS:  e030 DS:  ES:  CR0: 80050033
[6.024313] CR2: c900020ef000 CR3: 0220a000 CR4: 00050660
[6.028314] Call Trace:
[6.032313]  cvt_gate_to_trap.part.7+0x3f/0x90
[6.036313]  ? asm_exc_double_fault+0x30/0x30
[6.040313]  xen_convert_trap_info+0x87/0xd0
[6.044313]  xen_pv_cpu_up+0x17a/0x450
[6.048313]  bringup_cpu+0x2b/0xc0
[6.052313]  ? cpus_read_trylock+0x50/0x50
[6.056313]  cpuhp_invoke_callback+0x80/0x4c0
[6.060313]  _cpu_up+0xa7/0x140
[6.064313]  cpu_up+0x98/0xd0
[6.068313]  bringup_nonboot_cpus+0x4f/0x60
[6.072313]  smp_init+0x26/0x79
[6.076313]  kernel_init_freeable+0x103/0x258
[6.080313]  ? rest_init+0xd0/0xd0
[6.084313]  kernel_init+0xa/0x110
[6.088313]  ret_from_fork+0x1f/0x30
[6.092313] ---[ end trace be9ecf17dceeb4f3 ]---

Reason is that there is no Xen pv trap entry for X86_TRAP_VC.

Fix that by defining a trap entry for X86_TRAP_VC in Xen pv mode.

Fixes: 0786138c78e793 ("x86/sev-es: Add a Runtime #VC Exception Handler")
Cc:  # v5.10
Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/idtentry.h |  3 +++
 arch/x86/xen/enlighten_pv.c | 11 +++
 arch/x86/xen/xen-asm.S  |  3 +++
 3 files changed, 17 insertions(+)

diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
index 247a60a47331..115a76e77e65 100644
--- a/arch/x86/include/asm/idtentry.h
+++ b/arch/x86/include/asm/idtentry.h
@@ -609,6 +609,9 @@ DECLARE_IDTENTRY_DF(X86_TRAP_DF,exc_double_fault);
 /* #VC */
 #ifdef CONFIG_AMD_MEM_ENCRYPT
 DECLARE_IDTENTRY_VC(X86_TRAP_VC,   exc_vmm_communication);
+#ifdef CONFIG_XEN_PV
+DECLARE_IDTENTRY_RAW(X86_TRAP_VC,  xenpv_exc_vmm_communication);
+#endif
 #endif
 
 #ifdef CONFIG_XEN_PV
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4409306364dc..82948251f57b 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -583,6 +583,14 @@ DEFINE_IDTENTRY_RAW(xenpv_exc_debug)
exc_debug(regs);
 }
 
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+DEFINE_IDTENTRY_RAW(xenpv_exc_vmm_communication)
+{
+   /* This should never happen and there is no way to handle it. */
+   panic("X86_TRAP_VC in Xen PV mode.");
+}
+#endif
+
 struct trap_array_entry {
void (*orig)(void);
void (*xen)(void);
@@ -625,6 +633,9 @@ static struct trap_array_entry trap_array[] = {
TRAP_ENTRY(exc_coprocessor_error,   false ),
TRAP_ENTRY(exc_alignment_check, false ),
TRAP_ENTRY(exc_simd_coprocessor_error,  false ),
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+   TRAP_ENTRY_REDIR(exc_vmm_communication, true ),
+#endif
 };
 
 static bool __ref get_trap_addr(void **addr, unsigned int ist)
diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
index 1cb0e84b9161..16f4db35de44 100644
--- a/arch/x86/xen/xen-asm.S
+++ b/arch/x86/xen/xen-asm.S
@@ -175,6 +175,9 @@ xen_pv_trap asm_exc_alignment_check
 xen_pv_trap asm_exc_machine_check
 #endif /* CONFIG_X86_MCE */
 xen_pv_trap asm_exc_simd_coprocessor_error
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+xen_pv_trap asm_xenpv_exc_vmm_communication
+#endif /* CONFIG_AMD_MEM_ENCRYPT */
 #ifdef CONFIG_IA32_EMULATION
 xen_pv_trap entry_INT80_compat
 #endif
-- 
2.26.2

[tip:master] BUILD SUCCESS 22840ddac02152c3853c9a59dada585fc85be3c9

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
branch HEAD: 22840ddac02152c3853c9a59dada585fc85be3c9  Merge branch 'linus'

elapsed time: 721m

configs tested: 124
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
nios2 3c120_defconfig
sh  rsk7264_defconfig
mips   jazz_defconfig
powerpc   currituck_defconfig
powerpc  ppc44x_defconfig
h8300 edosk2674_defconfig
arm axm55xx_defconfig
c6x defconfig
powerpc mpc832x_mds_defconfig
arm  colibri_pxa300_defconfig
ia64  tiger_defconfig
arm lpc32xx_defconfig
h8300h8300h-sim_defconfig
s390   zfcpdump_defconfig
armspear6xx_defconfig
x86_64   alldefconfig
powerpc ksi8560_defconfig
arc nsimosci_hs_defconfig
mips tb0287_defconfig
sh  rts7751r2d1_defconfig
mips tb0219_defconfig
mips   ip27_defconfig
m68k apollo_defconfig
arcnsimosci_defconfig
sh   j2_defconfig
sh   sh7770_generic_defconfig
sh ecovec24_defconfig
nios2allyesconfig
powerpc  mgcoge_defconfig
powerpc ep8248e_defconfig
shsh7763rdp_defconfig
armmini2440_defconfig
armmps2_defconfig
shsh7757lcr_defconfig
um   x86_64_defconfig
sh   se7712_defconfig
sparc   sparc32_defconfig
arm  ixp4xx_defconfig
arm hackkit_defconfig
m68k   m5475evb_defconfig
c6xevmc6678_defconfig
powerpc tqm8560_defconfig
xtensa  nommu_kc705_defconfig
mips  cavium_octeon_defconfig
mips   ip28_defconfig
arm eseries_pxa_defconfig
powerpc linkstation_defconfig
powerpc64alldefconfig
xtensa  cadence_csp_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a001-20210125
i386 randconfig-a002-20210125
i386 randconfig-a004-20210125
i386 randconfig-a006-20210125
i386 randconfig-a005-20210125
i386 randconfig-a003-20210125
i386 randconfig-a013-20210125
i386 randconfig-a011-20210125
i386 randconfig-a012-20210125
i386 randconfig-a015-20210125
i386 randconfig-a014-20210125
i386 randconfig-a016-20210125
x86_64   randconfig-a003-20210125
x86_64   randconfig-a002-20210125
x86_64   randconfig-a001-20210

Re: [PATCH] USB: serial: cp210x: Add pid/vid for WSDA-200-USB

[Johan Hovold]

On Mon, Jan 25, 2021 at 09:26:54AM +, Pho Tran wrote:
> Information pid/vid of WSDA-200-USB, Lord corporation company:
> vid: 199b
> pid: ba30
> 
> Signed-off-by: Pho Tran 

Applied, thanks.

Johan

Re: [RFC PATCH v1] sched/fair: limit load balance redo times at the same sched_domain level

[Li, Aubrey]

On 2021/1/25 17:06, Mel Gorman wrote:
> On Mon, Jan 25, 2021 at 02:02:58PM +0800, Aubrey Li wrote:
>> A long-tail load balance cost is observed on the newly idle path,
>> this is caused by a race window between the first nr_running check
>> of the busiest runqueue and its nr_running recheck in detach_tasks.
>>
>> Before the busiest runqueue is locked, the tasks on the busiest
>> runqueue could be pulled by other CPUs and nr_running of the busiest
>> runqueu becomes 1, this causes detach_tasks breaks with LBF_ALL_PINNED
>> flag set, and triggers load_balance redo at the same sched_domain level.
>>
>> In order to find the new busiest sched_group and CPU, load balance will
>> recompute and update the various load statistics, which eventually leads
>> to the long-tail load balance cost.
>>
>> This patch introduces a variable(sched_nr_lb_redo) to limit load balance
>> redo times, combined with sysctl_sched_nr_migrate, the max load balance
>> cost is reduced from 100+ us to 70+ us, measured on a 4s x86 system with
>> 192 logical CPUs.
>>
>> Cc: Andi Kleen 
>> Cc: Tim Chen 
>> Cc: Srinivas Pandruvada 
>> Cc: Rafael J. Wysocki 
>> Signed-off-by: Aubrey Li 
> 
> If redo_max is a constant, why is it not a #define instead of increasing
> the size of lb_env?
> 

I followed the existing variable sched_nr_migrate_break, I think this might
be a tunable as well.

Thanks,
-Aubrey

Re: [PATCH 0/2] mmc: J7200: Add support for higher speed modes in MMCSD subsystems

[Nishanth Menon]

On 19:12-20210125, Aswath Govindraju wrote:
> Hi Nishanth,
> 
> On 22/01/21 11:36 pm, Nishanth Menon wrote:
> > On 21:54-20210122, Aswath Govindraju wrote:
> >> The following series of patches
> >> - adds support for HS200 and HS400 speed modes in MMCSD0 subsystem
> >> - adds support for UHS-I speed modes in MMCSD1 subsystem 
> >>
> >> Aswath Govindraju (2):
> >>   arm64: dts: ti: k3-j7200-main: Add support for HS200 and HS400 modes
> >> in MMCSD0 subsystem
> >>   arm64: dts: ti: k3-j7200-main: Add support for UHS-I modes in MMCSD1
> >> subsystem
> > 
> > 
> > Just a curious couple of questions:
> > Does squashing both the patches create a problem for understanding or a
> > later bisect? I kind of thought these mostly go hand in hand between the
> > instances, am I mistaken?
> > 
> 
> Yes, they can be squashed. I post a respin doing this.

Thanks.

> 
> > Are there any otap delay params update needed or the defaults are good
> > to go?
> > 
> 
> The otap values are already up-to-date with the data sheet and don't
> need updation.

Thanks for the clarification.

> 
> > Will also help to provide some verification log along with this.
> > 
> 
> May I know what sort of logs would be best to provide. Would enumeration
> logs during boot suffice ?
> 
> Like this,
> https://pastebin.ubuntu.com/p/v9NRV7GwMw/ ?

That just says we detected the cards, no?
I thought we had tests around this? Something including 
/sys/kernel/debug/mmc*/ios

Something that demonstrates that this actually runs at the claimed
speeds? That would be nice on linux-next, if possible as well..

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

[PATCH 0/7] USB: serial: cp210x: modem-control fixes

[Johan Hovold]

This series fixes the modem-control handling and its interaction with
hardware flow control in the cp210x driver.

Johan

Johan Hovold (7):
  USB: serial: cp210x: suppress modem-control errors
  USB: serial: cp210x: fix modem-control handling
  USB: serial: cp210x: drop shift macros
  USB: serial: cp210x: clean up flow-control debug message
  USB: serial: cp210x: clean up printk zero padding
  USB: serial: cp210x: fix RTS handling
  USB: serial: cp210x: clean up auto-RTS handling

 drivers/usb/serial/cp210x.c | 113 
 1 file changed, 89 insertions(+), 24 deletions(-)

-- 
2.26.2

[PATCH iproute-next v2] devlink: add support for port params get/set

[Oleksandr Mazur]

Add implementation for the port parameters getting/setting.
Add bash completion for port param.
Add man description for port param.

Signed-off-by: Oleksandr Mazur 
---
V2:
1) Add bash completion for port param;
2) Add man decsription / examples for port param;

 bash-completion/devlink |  55 
 devlink/devlink.c   | 275 +++-
 man/man8/devlink-port.8 |  65 ++
 3 files changed, 389 insertions(+), 6 deletions(-)

diff --git a/bash-completion/devlink b/bash-completion/devlink
index 7395b504..361be9fe 100644
--- a/bash-completion/devlink
+++ b/bash-completion/devlink
@@ -319,6 +319,57 @@ _devlink_port_split()
 esac
 }
 
+# Completion for devlink port param set
+_devlink_port_param_set()
+{
+case $cword in
+7)
+COMPREPLY=( $( compgen -W "value" -- "$cur" ) )
+return
+;;
+8)
+# String argument
+return
+;;
+9)
+COMPREPLY=( $( compgen -W "cmode" -- "$cur" ) )
+return
+;;
+10)
+COMPREPLY=( $( compgen -W "runtime driverinit permanent" -- \
+"$cur" ) )
+return
+;;
+esac
+}
+
+# Completion for devlink port param
+_devlink_port_param()
+{
+case "$cword" in
+3)
+COMPREPLY=( $( compgen -W "show set" -- "$cur" ) )
+return
+;;
+4)
+_devlink_direct_complete "port"
+return
+;;
+5)
+COMPREPLY=( $( compgen -W "name" -- "$cur" ) )
+return
+;;
+6)
+_devlink_direct_complete "param_name"
+return
+;;
+esac
+
+if [[ "${words[3]}" == "set" ]]; then
+_devlink_port_param_set
+fi
+}
+
 # Completion for devlink port
 _devlink_port()
 {
@@ -331,6 +382,10 @@ _devlink_port()
 _devlink_port_split
 return
 ;;
+param)
+_devlink_port_param
+return
+;;
 show|unsplit)
 if [[ $cword -eq 3 ]]; then
 _devlink_direct_complete "port"
diff --git a/devlink/devlink.c b/devlink/devlink.c
index a2e06644..0fc1d4f0 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -2706,7 +2706,8 @@ static void pr_out_param_value(struct dl *dl, const char 
*nla_name,
}
 }
 
-static void pr_out_param(struct dl *dl, struct nlattr **tb, bool array)
+static void pr_out_param(struct dl *dl, struct nlattr **tb, bool array,
+bool is_port_param)
 {
struct nlattr *nla_param[DEVLINK_ATTR_MAX + 1] = {};
struct nlattr *param_value_attr;
@@ -2714,6 +2715,7 @@ static void pr_out_param(struct dl *dl, struct nlattr 
**tb, bool array)
int nla_type;
int err;
 
+
err = mnl_attr_parse_nested(tb[DEVLINK_ATTR_PARAM], attr_cb, nla_param);
if (err != MNL_CB_OK)
return;
@@ -2723,9 +2725,15 @@ static void pr_out_param(struct dl *dl, struct nlattr 
**tb, bool array)
return;
 
if (array)
-   pr_out_handle_start_arr(dl, tb);
+   if (is_port_param)
+   pr_out_port_handle_start_arr(dl, tb, false);
+   else
+   pr_out_handle_start_arr(dl, tb);
else
-   __pr_out_handle_start(dl, tb, true, false);
+   if (is_port_param)
+   pr_out_port_handle_start(dl, tb, false);
+   else
+   __pr_out_handle_start(dl, tb, true, false);
 
nla_type = mnl_attr_get_u8(nla_param[DEVLINK_ATTR_PARAM_TYPE]);
 
@@ -2745,7 +2753,10 @@ static void pr_out_param(struct dl *dl, struct nlattr 
**tb, bool array)
pr_out_entry_end(dl);
}
pr_out_array_end(dl);
-   pr_out_handle_end(dl);
+   if (is_port_param)
+   pr_out_port_handle_end(dl);
+   else
+   pr_out_handle_end(dl);
 }
 
 static int cmd_dev_param_show_cb(const struct nlmsghdr *nlh, void *data)
@@ -2758,7 +2769,7 @@ static int cmd_dev_param_show_cb(const struct nlmsghdr 
*nlh, void *data)
if (!tb[DEVLINK_ATTR_BUS_NAME] || !tb[DEVLINK_ATTR_DEV_NAME] ||
!tb[DEVLINK_ATTR_PARAM])
return MNL_CB_ERROR;
-   pr_out_param(dl, tb, true);
+   pr_out_param(dl, tb, true, false);
return MNL_CB_OK;
 }
 
@@ -2956,6 +2967,21 @@ err_param_value_parse:
return err;
 }
 
+static int cmd_port_param_show_cb(const struct nlmsghdr *nlh, void *data)
+{
+   struct genlmsghdr *genl = mnl_nlmsg_get_payload(nlh);
+   struct nlattr *tb[DEVLINK_ATTR_MAX + 1] = {};
+   struct dl *dl = data;
+
+   mnl_attr_parse(nlh, sizeof(*genl), attr_cb, tb);
+   if (!tb[DEVLINK_ATTR_BUS_NAME] || !tb[DEVLINK_ATTR_DEV_NAME] ||
+   !tb[DEVLINK_ATTR_PORT_INDEX] || !tb[DEVLINK_ATTR_PARAM])
+   return MNL_CB_

Re: [PATCH v6 5/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM

[Laurentiu Palcu]

Hi Liu Ying,

Just some minor comments below.

On Thu, Jan 21, 2021 at 03:14:22PM +0800, Liu Ying wrote:
> This patch introduces i.MX8qm/qxp Display Processing Unit(DPU) DRM support.
> 
> DPU is comprised of two main components that include a blit engine for
> 2D graphics accelerations(with composition support) and a display controller
> for display output processing, as well as a command sequencer.  Outside of
> DPU, optional prefetch engines, a.k.a, Prefetch Resolve Gasket(PRG) and
> Display Prefetch Resolve(DPR), can fetch data from memory prior to some DPU
> fetchunits of blit engine and display controller.  The prefetch engines
> support reading linear formats and resolving Vivante GPU tile formats.
> 
> This patch adds kernel modesetting support for the display controller part.
> The driver supports two CRTCs per display controller, planes backed by
> four fetchunits(decode0/1, fetchlayer, fetchwarp), fetchunit allocation
> logic for the two CRTCs, prefetch engines(with tile resolving supported),
> plane upscaling/deinterlacing/yuv2rgb CSC/alpha blending and CRTC gamma
> correction.  The registers of the controller is accessed without command
> sequencer involved, instead just by using CPU.
> 
> Reference manual can be found at:
> https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM
> 
> Signed-off-by: Liu Ying 
> ---
> v5->v6:
> * Do not use macros where possible. (Laurentiu)
> * Break dpu_plane_atomic_check() into some smaller functions. (Laurentiu)
> * Address some minor comments from Laurentiu.
> * Add dpu_crtc_err() helper marco to tell dmesg which CRTC generates error.
> * Drop calling dev_set_drvdata() from dpu_drm_bind/unbind() as it is done
>   in dpu_drm_probe().
> * Some trivial tweaks.
> 
> v4->v5:
> * Rebase up onto the latest drm-misc-next branch and remove the hook to
>   drm_atomic_helper_legacy_gamma_set(), because it was dropped by the newly
>   landed commit 'drm: automatic legacy gamma support'.
> * Remove a redundant blank line from dpu_plane_atomic_update().
> 
> v3->v4:
> * No change.
> 
> v2->v3:
> * Fix build warnings Reported-by: kernel test robot .
> * Drop build dependency on IMX_SCU, as dummy SCU functions have been added in
>   header files by the patch 'firmware: imx: add dummy functions' which has
>   landed in linux-next/master branch.
> 
> v1->v2:
> * Add compatible for i.MX8qm DPU, as this is tested with i.MX8qm LVDS 
> displays.
>   (Laurentiu)
> * Fix PRG burst size and stride. (Laurentiu)
> * Put 'ports' OF node to fix the bail-out logic in dpu_drm_probe(). 
> (Laurentiu)
> 
>  drivers/gpu/drm/imx/Kconfig   |1 +
>  drivers/gpu/drm/imx/Makefile  |1 +
>  drivers/gpu/drm/imx/dpu/Kconfig   |   10 +
>  drivers/gpu/drm/imx/dpu/Makefile  |   10 +
>  drivers/gpu/drm/imx/dpu/dpu-constframe.c  |  171 +
>  drivers/gpu/drm/imx/dpu/dpu-core.c| 1094 
> +
>  drivers/gpu/drm/imx/dpu/dpu-crtc.c|  967 +
>  drivers/gpu/drm/imx/dpu/dpu-crtc.h|   66 ++
>  drivers/gpu/drm/imx/dpu/dpu-disengcfg.c   |  117 +++
>  drivers/gpu/drm/imx/dpu/dpu-dprc.c|  718 +++
>  drivers/gpu/drm/imx/dpu/dpu-dprc.h|   40 ++
>  drivers/gpu/drm/imx/dpu/dpu-drv.c |  292 
>  drivers/gpu/drm/imx/dpu/dpu-drv.h |   28 +
>  drivers/gpu/drm/imx/dpu/dpu-extdst.c  |  299 
>  drivers/gpu/drm/imx/dpu/dpu-fetchdecode.c |  294 
>  drivers/gpu/drm/imx/dpu/dpu-fetcheco.c|  224 ++
>  drivers/gpu/drm/imx/dpu/dpu-fetchlayer.c  |  154 
>  drivers/gpu/drm/imx/dpu/dpu-fetchunit.c   |  609 
>  drivers/gpu/drm/imx/dpu/dpu-fetchunit.h   |  191 +
>  drivers/gpu/drm/imx/dpu/dpu-fetchwarp.c   |  250 +++
>  drivers/gpu/drm/imx/dpu/dpu-framegen.c|  395 +++
>  drivers/gpu/drm/imx/dpu/dpu-gammacor.c|  223 ++
>  drivers/gpu/drm/imx/dpu/dpu-hscaler.c |  275 
>  drivers/gpu/drm/imx/dpu/dpu-kms.c |  540 ++
>  drivers/gpu/drm/imx/dpu/dpu-kms.h |   23 +
>  drivers/gpu/drm/imx/dpu/dpu-layerblend.c  |  348 +
>  drivers/gpu/drm/imx/dpu/dpu-plane.c   |  799 +
>  drivers/gpu/drm/imx/dpu/dpu-plane.h   |   56 ++
>  drivers/gpu/drm/imx/dpu/dpu-prg.c |  433 
>  drivers/gpu/drm/imx/dpu/dpu-prg.h |   45 ++
>  drivers/gpu/drm/imx/dpu/dpu-prv.h |  233 ++
>  drivers/gpu/drm/imx/dpu/dpu-tcon.c|  250 +++
>  drivers/gpu/drm/imx/dpu/dpu-vscaler.c |  308 
>  drivers/gpu/drm/imx/dpu/dpu.h |  385 ++
>  34 files changed, 9849 insertions(+)
>  create mode 100644 drivers/gpu/drm/imx/dpu/Kconfig
>  create mode 100644 drivers/gpu/drm/imx/dpu/Makefile
>  create mode 100644 drivers/gpu/drm/imx/dpu/dpu-constframe.c
>  create mode 100644 drivers/gpu/drm/imx/dpu/dpu-core.c
>  create mode 100644 drivers/gpu/drm/imx/dpu/dpu-crtc.c
>  create mode 100644 drivers/gpu

Re: [PATCH v4] USB: serial: cp210x: Fix error 32 when hardware flow control is enabled.

[Johan Hovold]

On Thu, Jan 21, 2021 at 09:52:23AM +, Pho Tran wrote:
> Fix error 32 returned by CP210X_SET_MHS when hardware flow control is enabled.
> 
> The root cause of error 32 is that user application (CoolTerm, 
> linux-serial-test)
> opened cp210x device with hardware flow control then attempt to control 
> RTS/DTR pins.
> In hardware flow control, RTS/DTR pins will be controlled by hardware only,
> any attempt to control those pins will cause error 32 from the device.
> This fix will block MHS command(command to control RTS/DTR pins) to the device
> if hardware flow control is being used.
> 
> Signed-off-by: Pho Tran 
> ---
> 01/21/2021: Patch v3 modified based on comment from Greg Kroah-Hartman 
> 
> 01/19/2021: Patch v2  Modified based on comment from Johan Hovold 
> 
> and Greg Kroah-Hartman 

Giving credit in the commit log is nice, but this still doesn't say
anything about *what* you changed.

> ---
>  drivers/usb/serial/cp210x.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index fbb10dfc56e3..814dff5fee98 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -1204,7 +1204,12 @@ static int cp210x_tiocmset(struct tty_struct *tty,
>   unsigned int set, unsigned int clear)
>  {
>   struct usb_serial_port *port = tty->driver_data;
> - return cp210x_tiocmset_port(port, set, clear);
> +
> + /* Don't send SET_MHS command if device in hardware flow control mode. 
> */
> + if (C_CRTSCTS(tty))
> + return 0;

You didn't reply to my comments that what should be done here is to
disable auto-RTS when clearing TIOCM_RST and re-enable it when setting
the same bit. If you disagree with review feedback you need to say so
and not just resend a new version of your patch without an explanation.

Note that the above would also needlessly prevent DTR from being changed
whenever auto-RTS is enabled and return success instead of an error to
user space.

My suggestion for how to suppress the error message from dtr_rts()
suffers from the same problem so I've updated that patch and implemented
proper RTS handling in the driver now.

This takes care not only of the SET_MHS error messages, but also makes
sure that RTS can always be deasserted and some other related issues
with regards to modem control.

> + else
> + return cp210x_tiocmset_port(port, set, clear);
>  }
>  
>  static int cp210x_tiocmset_port(struct usb_serial_port *port,

Johan

Re: [RFC PATCH v0] mm/slub: Let number of online CPUs determine the slub page order

[Vlastimil Babka]

On 1/23/21 1:32 PM, Vincent Guittot wrote:
>> PowerPC PowerNV Host: (160 cpus)
>> num_online_cpus 1 num_present_cpus 160 num_possible_cpus 160 nr_cpu_ids 160
>>
>> PowerPC pseries KVM guest: (-smp 16,maxcpus=160)
>> num_online_cpus 1 num_present_cpus 16 num_possible_cpus 160 nr_cpu_ids 160
>>
>> That's what I see on powerpc, hence I thought num_present_cpus() could
>> be the correct one to use in slub page order calculation.
> 
> num_present_cpus() is set to 1 on arm64 until secondaries cpus boot
> 
> arm64 224cpus acpi host:
> num_online_cpus 1 num_present_cpus 1 num_possible_cpus 224 nr_cpu_ids 224
> arm64 8cpus DT host:
> num_online_cpus 1 num_present_cpus 1 num_possible_cpus 8 nr_cpu_ids 8
> arm64 8cpus qemu-system-aarch64 (-smp 8,maxcpus=256)
> num_online_cpus 1 num_present_cpus 1 num_possible_cpus 8 nr_cpu_ids 8

I would have expected num_present_cpus to be 224, 8, 8, respectively.

> Then present and online increase to num_possible_cpus once all cpus are booted
> 
>>
>> >
>> > What about heuristic:
>> > - num_online_cpus() > 1 - we trust that and use it
>> > - otherwise nr_cpu_ids
>> > Would that work? Too arbitrary?
>>
>> Looking at the following snippet from include/linux/cpumask.h, it
>> appears that num_present_cpus() should be reasonable compromise
>> between online and possible/nr_cpus_ids to use here.
>>
>> /*
>>  * The following particular system cpumasks and operations manage
>>  * possible, present, active and online cpus.
>>  *
>>  * cpu_possible_mask- has bit 'cpu' set iff cpu is populatable
>>  * cpu_present_mask - has bit 'cpu' set iff cpu is populated
>>  * cpu_online_mask  - has bit 'cpu' set iff cpu available to scheduler
>>  * cpu_active_mask  - has bit 'cpu' set iff cpu available to migration
>>  *
>>  *  If !CONFIG_HOTPLUG_CPU, present == possible, and active == online.
>>  *
>>  *  The cpu_possible_mask is fixed at boot time, as the set of CPU id's
>>  *  that it is possible might ever be plugged in at anytime during the
>>  *  life of that system boot.  The cpu_present_mask is dynamic(*),
>>  *  representing which CPUs are currently plugged in.  And
>>  *  cpu_online_mask is the dynamic subset of cpu_present_mask,
>>  *  indicating those CPUs available for scheduling.
>>  *
>>  *  If HOTPLUG is enabled, then cpu_possible_mask is forced to have
>>  *  all NR_CPUS bits set, otherwise it is just the set of CPUs that
>>  *  ACPI reports present at boot.
>>  *
>>  *  If HOTPLUG is enabled, then cpu_present_mask varies dynamically,
>>  *  depending on what ACPI reports as currently plugged in, otherwise
>>  *  cpu_present_mask is just a copy of cpu_possible_mask.
>>  *
>>  *  (*) Well, cpu_present_mask is dynamic in the hotplug case.  If not
>>  *  hotplug, it's a copy of cpu_possible_mask, hence fixed at boot.
>>  */
>>
>> So for host systems, present is (usually) equal to possible and for
> 
> But "cpu_present_mask varies dynamically,  depending on what ACPI
> reports as currently plugged in"
> 
> So it should varies when secondaries cpus are booted

Hm, but booting the secondaries is just a software (kernel) action? They are
already physically there, so it seems to me as if the cpu_present_mask is not
populated correctly on arm64, and it's just a mirror of cpu_online_mask?

Re: [PATCH 2/5] mm,memory_hotplug: Allocate memmap from the added memory range

[Oscar Salvador]

On Mon, Jan 25, 2021 at 11:57:20AM +0100, David Hildenbrand wrote:
> I'm confused.
> 
> 1. Assume we hotplug memory, online it to ZONE_MOVABLE. The vmemmap gets
> allocated from altmap space.

The vmemmap could have never been allocated from altmap in case hpage vmemmap
feature is enabled.

Have a look at [1].
If is_hugetlb_free_vmemmap_enabled(), vmemmap_populate() ends up calling
vmemmap_populate_basepages().

And since no memory was consumed from altmap, and hence altmap_alloc_block_buf()
was never called, vmem_altmap->alloc will be 0, and 
memory_block->nr_vmemmap_pages
will be 0 as well.

But on a second though, true is that we will get in trouble if hpage vmemmap
feature ever gets to work with vmemmap_populate_hugepages.
I will queue that to look in a new future.

[1] 
https://patchwork.kernel.org/project/linux-mm/patch/20210117151053.24600-10-songmuc...@bytedance.com/


-- 
Oscar Salvador
SUSE L3

[RFC PATCH v3 11/13] virtio/vsock: setup SEQPACKET ops for transport

[Arseny Krasnov]

This adds SEQPACKET ops for virtio transport

Signed-off-by: Arseny Krasnov 
---
 net/vmw_vsock/virtio_transport.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 2700a63ab095..5a7ab1befee8 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -469,6 +469,10 @@ static struct virtio_transport virtio_transport = {
.stream_is_active = virtio_transport_stream_is_active,
.stream_allow = virtio_transport_stream_allow,
 
+   .seqpacket_seq_send_len   = 
virtio_transport_seqpacket_seq_send_len,
+   .seqpacket_seq_get_len= 
virtio_transport_seqpacket_seq_get_len,
+   .seqpacket_dequeue= virtio_transport_seqpacket_dequeue,
+
.notify_poll_in   = virtio_transport_notify_poll_in,
.notify_poll_out  = virtio_transport_notify_poll_out,
.notify_recv_init = virtio_transport_notify_recv_init,
-- 
2.25.1

[RFC PATCH v3 12/13] vhost/vsock: setup SEQPACKET ops for transport

[Arseny Krasnov]

This also removes ignore of non-stream type of packets.

Signed-off-by: Arseny Krasnov 
---
 drivers/vhost/vsock.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index 5e78fb719602..4d60a99aed14 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -354,8 +354,7 @@ vhost_vsock_alloc_pkt(struct vhost_virtqueue *vq,
return NULL;
}
 
-   if (le16_to_cpu(pkt->hdr.type) == VIRTIO_VSOCK_TYPE_STREAM)
-   pkt->len = le32_to_cpu(pkt->hdr.len);
+   pkt->len = le32_to_cpu(pkt->hdr.len);
 
/* No payload */
if (!pkt->len)
@@ -424,6 +423,10 @@ static struct virtio_transport vhost_transport = {
.stream_is_active = virtio_transport_stream_is_active,
.stream_allow = virtio_transport_stream_allow,
 
+   .seqpacket_seq_send_len   = 
virtio_transport_seqpacket_seq_send_len,
+   .seqpacket_seq_get_len= 
virtio_transport_seqpacket_seq_get_len,
+   .seqpacket_dequeue= virtio_transport_seqpacket_dequeue,
+
.notify_poll_in   = virtio_transport_notify_poll_in,
.notify_poll_out  = virtio_transport_notify_poll_out,
.notify_recv_init = virtio_transport_notify_recv_init,
-- 
2.25.1

[PATCH v3] mm, oom: Fix a comment in dump_task

[Tang Yizhou]

If p is a kthread, it will be checked in oom_unkillable_task() so
we can delete the corresponding comment.

Signed-off-by: Tang Yizhou 
Acked-by: David Rientjes 
Acked-by: Michal Hocko 
---
v2: Update CC list
v3: Add Acked-by tags
 mm/oom_kill.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 04b19b7b5435..9f043ad29554 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -395,9 +395,8 @@ static int dump_task(struct task_struct *p, void *arg)
task = find_lock_task_mm(p);
if (!task) {
/*
-* This is a kthread or all of p's threads have already
-* detached their mm's.  There's no need to report
-* them; they can't be oom killed anyway.
+* All of p's threads have already detached their mm's. There's
+* no need to report them; they can't be oom killed anyway.
 */
return 0;
}
-- 
2.22.0

[RFC PATCH v3 01/13] af_vsock: prepare for SOCK_SEQPACKET support

[Arseny Krasnov]

This prepares af_vsock.c for SEQPACKET support:
1) As both stream and seqpacket sockets are connection oriented, add
   check for SOCK_SEQPACKET to conditions where SOCK_STREAM is checked.
2) Some functions such as setsockopt(), getsockopt(), connect(),
   recvmsg(), sendmsg() are shared between both types of sockets, so
   rename them in general manner and create entry points for each type
   of socket to call these functions(for stream in this patch, for
   seqpacket in further patches).

Signed-off-by: Arseny Krasnov 
---
 net/vmw_vsock/af_vsock.c | 91 +---
 1 file changed, 67 insertions(+), 24 deletions(-)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index b12d3a322242..c9ce57db9554 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -604,8 +604,8 @@ static void vsock_pending_work(struct work_struct *work)
 
 / SOCKET OPERATIONS /
 
-static int __vsock_bind_stream(struct vsock_sock *vsk,
-  struct sockaddr_vm *addr)
+static int __vsock_bind_connectible(struct vsock_sock *vsk,
+   struct sockaddr_vm *addr)
 {
static u32 port;
struct sockaddr_vm new_addr;
@@ -685,7 +685,7 @@ static int __vsock_bind(struct sock *sk, struct sockaddr_vm 
*addr)
switch (sk->sk_socket->type) {
case SOCK_STREAM:
spin_lock_bh(&vsock_table_lock);
-   retval = __vsock_bind_stream(vsk, addr);
+   retval = __vsock_bind_connectible(vsk, addr);
spin_unlock_bh(&vsock_table_lock);
break;
 
@@ -767,6 +767,11 @@ static struct sock *__vsock_create(struct net *net,
return sk;
 }
 
+static bool sock_type_connectible(u16 type)
+{
+   return (type == SOCK_STREAM || type == SOCK_SEQPACKET);
+}
+
 static void __vsock_release(struct sock *sk, int level)
 {
if (sk) {
@@ -785,7 +790,7 @@ static void __vsock_release(struct sock *sk, int level)
 
if (vsk->transport)
vsk->transport->release(vsk);
-   else if (sk->sk_type == SOCK_STREAM)
+   else if (sock_type_connectible(sk->sk_type))
vsock_remove_sock(vsk);
 
sock_orphan(sk);
@@ -945,7 +950,7 @@ static int vsock_shutdown(struct socket *sock, int mode)
sk = sock->sk;
if (sock->state == SS_UNCONNECTED) {
err = -ENOTCONN;
-   if (sk->sk_type == SOCK_STREAM)
+   if (sock_type_connectible(sk->sk_type))
return err;
} else {
sock->state = SS_DISCONNECTING;
@@ -960,7 +965,7 @@ static int vsock_shutdown(struct socket *sock, int mode)
sk->sk_state_change(sk);
release_sock(sk);
 
-   if (sk->sk_type == SOCK_STREAM) {
+   if (sock_type_connectible(sk->sk_type)) {
sock_reset_flag(sk, SOCK_DONE);
vsock_send_shutdown(sk, mode);
}
@@ -1013,7 +1018,7 @@ static __poll_t vsock_poll(struct file *file, struct 
socket *sock,
if (!(sk->sk_shutdown & SEND_SHUTDOWN))
mask |= EPOLLOUT | EPOLLWRNORM | EPOLLWRBAND;
 
-   } else if (sock->type == SOCK_STREAM) {
+   } else if (sock_type_connectible(sk->sk_type)) {
const struct vsock_transport *transport = vsk->transport;
lock_sock(sk);
 
@@ -1259,8 +1264,8 @@ static void vsock_connect_timeout(struct work_struct 
*work)
sock_put(sk);
 }
 
-static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
-   int addr_len, int flags)
+static int vsock_connect(struct socket *sock, struct sockaddr *addr,
+int addr_len, int flags)
 {
int err;
struct sock *sk;
@@ -1395,6 +1400,12 @@ static int vsock_stream_connect(struct socket *sock, 
struct sockaddr *addr,
return err;
 }
 
+static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
+   int addr_len, int flags)
+{
+   return vsock_connect(sock, addr, addr_len, flags);
+}
+
 static int vsock_accept(struct socket *sock, struct socket *newsock, int flags,
bool kern)
 {
@@ -1410,7 +1421,7 @@ static int vsock_accept(struct socket *sock, struct 
socket *newsock, int flags,
 
lock_sock(listener);
 
-   if (sock->type != SOCK_STREAM) {
+   if (!sock_type_connectible(sock->type)) {
err = -EOPNOTSUPP;
goto out;
}
@@ -1487,7 +1498,7 @@ static int vsock_listen(struct socket *sock, int backlog)
 
lock_sock(sk);
 
-   if (sock->type != SOCK_STREAM) {
+   if (!sock_type_connectible(sk->sk_type)) {
err = -EOPNOTSUPP;
goto out;
}
@@ -1531,11 +1542,11 @@ static void vsock_update_buffer_size(struct vsock_sock 
*vsk

Re: [PATCH 2/5] mm,memory_hotplug: Allocate memmap from the added memory range

[Oscar Salvador]

On Mon, Jan 25, 2021 at 12:02:53PM +0100, David Hildenbrand wrote:
> Assume you have two consecutive memory blocks with 56 sizeof(struct page).
> The first one allocates a PMD (2097152) but only consumes 1835008, the second
> one reuses the remaining part and allocates another PMD (1835008),
> only using parts of it.
> 
> Ripping out a memory block, along with the PMD in the vmemmap would
> remove parts of the vmemmap of another memory block.

Bleh, yeah, I was confused, you are right.

> You might want to take a look at:

Thanks a lot for the hints, I will have a look ;-)


-- 
Oscar Salvador
SUSE L3