Re: [RFC PATCH 2/3] perf tools: Add support for "report" for some spe events

[Tan Xiaojun]

On 2019/10/4 21:46, James Clark wrote:
> Hi Xiaojun,
> 
> I wanted to ask if you are still working on this?
> 
> I've noticed that it doesn't apply cleanly to perf/core anymore and I was 
> working on re-basing it.
> Would you be interested in me posting my progress?
> 
> I was also interested in decoding the "data source" of events and displaying 
> that information. Does this
> clash with any of your current work?
> 
> 
> Thanks
> James
> 

Hi, James,

Sorry, I did not respond in time because of the National Day holiday in China.

I am still doing this, but I have been scheduled for other tasks some time ago, 
so that there is no obvious progress on spe.

By the way, you mentioned before that you want the spe event to be in the form 
of "event:pp" like pebs. Is that the whole framework should be made similar to 
pebs? Or is it just a modification to the command format? For the former, this 
may be a bit difficult. For the latter, there is currently no modification to 
the record part, so "-c -F, etc." is only for instructions rather than events, 
so it may be misunderstood by users.

So I haven't figured out how to do. What do you think of this?

Thanks.
Xiaojun.

> On 09/08/2019 07:12, Tan Xiaojun wrote:
>> On 2019/8/9 5:00, Jeremy Linton wrote:
>>> Hi,
>>>
>>> First thanks for posting this!
>>>
>>> I ran this on our DAWN platform and it does what it says. Its a pretty 
>>> reasonable start, but I get -1's in the command row rather than "dd" (or 
>>> similar) and this also results in [unknown] for the shared object and most 
>>> userspace addresses. This is quite possibly something I'm not doing right, 
>>> but I didn't spend a lot of time testing/debugging it.
>>>
>>> I did a quick glance at the code to, and had a couple comments, although 
>>> I'm not a perf tool expert.
>>>
>>
>> Hi,
>>
>> Thank you for your reply.
>>
>> I have only recently started working on this aspect of the perf tool, so 
>> your reply is very important to me.
>>
>> I need to be sorry, my example here is not complete, until you said that I 
>> found that I only posted a part of the example. The complete example is as 
>> follows:
>>
>> Example usage:
>>
>> # perf record -e arm_spe/ts_enable=1,pa_enable=1/ dd if=/dev/zero 
>> of=/dev/null count=1
>> # perf report
>>
>> 
>> ...
>> # Samples: 37  of event 'llc-miss'
>> # Event count (approx.): 37
>> #
>> # Children  Self  Command  Shared Object  Symbol
>> #     ...  .  
>> 
>> #
>> 37.84%37.84%  dd   [kernel.kallsyms]  [k] 
>> perf_iterate_ctx.constprop.64
>> 16.22%16.22%  dd   [kernel.kallsyms]  [k] copy_page
>>  5.41% 5.41%  dd   [kernel.kallsyms]  [k] find_vma
>>  5.41% 5.41%  dd   [kernel.kallsyms]  [k] perf_event_mmap
>>  5.41% 5.41%  dd   [kernel.kallsyms]  [k] zap_pte_range
>>  5.41% 5.41%  dd   ld-2.28.so [.] _dl_lookup_symbol_x
>>  5.41% 5.41%  dd   libc-2.28.so   [.] _nl_intern_locale_data
>>  2.70% 2.70%  dd   [kernel.kallsyms]  [k] 
>> __remove_shared_vm_struct.isra.1
>>  2.70% 2.70%  dd   [kernel.kallsyms]  [k] kmem_cache_free
>>  2.70% 2.70%  dd   [kernel.kallsyms]  [k] ttwu_do_wakeup.isra.19
>>  2.70% 2.70%  dd   dd [.] 0xd9d8
>>  2.70% 2.70%  dd   ld-2.28.so [.] _dl_relocate_object
>>  2.70% 2.70%  dd   libc-2.28.so   [.] __unregister_atfork
>>  2.70% 2.70%  dd   libc-2.28.so   [.] _dl_addr
>>
>>
>> # Samples: 8  of event 'tlb-miss'
>> # Event count (approx.): 8
>> #
>> # Children  Self  Command  Shared Object  Symbol
>> #     ...  .  
>> .
>> #
>> 12.50%12.50%  dd   [kernel.kallsyms]  [k] __audit_syscall_entry
>> 12.50%12.50%  dd   [kernel.kallsyms]  [k] kmem_cache_free
>> 12.50%12.50%  dd   [kernel.kallsyms]  [k] 
>> perf_iterate_ctx.constprop.64
>> 12.50%12.50%  dd   [kernel.kallsyms]  [k] ttwu_do_wakeup.isra.19
>> 12.50%12.50%  dd   dd [.] 0xd9d8
>> 12.50%12.50%  dd   libc-2.28.so   [.] __unregister_atfork
>> 12.50%12.50%  dd   libc-2.28.so   [.] _nl_intern_locale_data
>> 12.50%12.50%  dd   libc-2.28.so   [.] vfprintf
>>
>>
>> # Samples: 12  of event 'branch-miss'
>> # Event count (approx.): 12
>> #
>> # Children  Self  Command  Shared Object  Symbol
>> #     ...  .  ..
>> #
>> 16.67%16.67%  dd   libc-2.28.so   [.] read_alias_file
>>  8.33% 8.33%  dd   [kernel.kallsyms]  [k] __arch_copy_from_user
>>  8.33% 8.33%  dd   [kernel.kallsyms]  [k] __arch_copy_to_user
>>  8.33% 

Re: [RESEND PATCH 0/2] Add bluetooth support for Orange Pi 3

[Maxime Ripard]

On Mon, Oct 07, 2019 at 10:31:50PM +0200, meg...@megous.com wrote:
> From: Ondrej Jirman 
>
> (Re-send for Maxime, with already applied patches dropped. Nothing new.)
>
> This series implements bluetooth support for Xunlong Orange Pi 3 board.
>
> The board uses AP6256 WiFi/BT 5.0 chip.
>
> Summary of changes:
>
> - add more delay to let initialize the chip
> - let the kernel detect firmware file path
> - add new compatible and update dt-bindings
> - update Orange Pi 3 / H6 DTS
>
> Please take a look.

Applied both, thanks!
Maxime


signature.asc
Description: PGP signature

Re: [PATCH] x86/purgatory: Make sure we fail the build if purgatory.ro has missing symbols

[Hans de Goede]

HI,

On 07-10-2019 23:52, Arvind Sankar wrote:

On Mon, Oct 07, 2019 at 10:31:49PM +0200, Hans de Goede wrote:

HI,

On 07-10-2019 22:05, Nathan Chancellor wrote:

On Mon, Oct 07, 2019 at 07:55:46PM +0200, Hans de Goede wrote:

Since we link purgatory.ro with -r aka we enable "incremental linking"
no checks for unresolved symbols is done while linking purgatory.ro.

Changes to the sha256 code has caused the purgatory in 5.4-rc1 to have
a missing symbol on memzero_explicit, yet things still happily build.

This commit adds an extra check for unresolved symbols by calling ld
without -r before running bin2c to generate kexec-purgatory.c.

This causes a build of 5.4-rc1 with this patch added to fail as it should:

CHK arch/x86/purgatory/purgatory.ro
ld: arch/x86/purgatory/purgatory.ro: in function `sha256_transform':
sha256.c:(.text+0x1c0c): undefined reference to `memzero_explicit'
make[2]: *** [arch/x86/purgatory/Makefile:72:
  arch/x86/purgatory/kexec-purgatory.c] Error 1
make[1]: *** [scripts/Makefile.build:509: arch/x86/purgatory] Error 2
make: *** [Makefile:1650: arch/x86] Error 2

This will help us catch missing symbols in the purgatory sooner.

Note this commit also removes --no-undefined from LDFLAGS_purgatory.ro
as that has no effect.

Signed-off-by: Hans de Goede 
---
   arch/x86/purgatory/Makefile | 8 +++-
   1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index fb4ee5444379..0da0794ef1f0 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -14,7 +14,7 @@ $(obj)/sha256.o: $(srctree)/lib/crypto/sha256.c FORCE
   
   CFLAGS_sha256.o := -D__DISABLE_EXPORTS
   
-LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined -nostdlib -z nodefaultlib

+LDFLAGS_purgatory.ro := -e purgatory_start -r -nostdlib -z nodefaultlib
   targets += purgatory.ro
   
   KASAN_SANITIZE	:= n

@@ -60,10 +60,16 @@ $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
   
   targets += kexec-purgatory.c
   
+# Since we link purgatory.ro with -r unresolved symbols are not checked,

+# so we check this before generating kexec-purgatory.c instead
+quiet_cmd_check_purgatory = CHK $<
+  cmd_check_purgatory = ld -e purgatory_start $<


I think this should be $(LD) -e ... so that using a cross compile prefix
(like x86_64-linux-) or an alternative linker like ld.lld works properly.


Good point, also the ld command is actually outputting an a.out file
which is also something which we do not want.

I will prepare a new version fixing both.

Regards,

Hans


We could just use $(NM) -u, right?


That would require wrapping it in some shell code like this (untested):

SHOULD_BE_EMPTY=$(nm -u purgatory.ro); if [ "$SHOULD_BE_EMPTY" == "" ]; then 
true; else false; fi

And then escaping the $ in there and in injecting $(NM) into it, IMHO
it is easier to just do:

$(LD) $PURGATORY_LDFLAGS) purgatory.ro -o /dev/null

Also it seems better to actually use the linker for this test then usig an other
tool which may have subtly different semantics.

Regards,

Hans

Re: [PATCH] cgroup, blkcg: prevent dirty inodes to pin dying memory cgroups

[Roman Gushchin]

On Tue, Oct 08, 2019 at 03:06:31PM +1100, Dave Chinner wrote:
> On Fri, Oct 04, 2019 at 03:11:04PM -0700, Roman Gushchin wrote:
> > This is a RFC patch, which is not intended to be merged as is,
> > but hopefully will start a discussion which can result in a good
> > solution for the described problem.
> > 
> > --
> > 
> > We've noticed that the number of dying cgroups on our production hosts
> > tends to grow with the uptime. This time it's caused by the writeback
> > code.
> > 
> > An inode which is getting dirty for the first time is associated
> > with the wb structure (look at __inode_attach_wb()). It can later
> > be switched to another wb under some conditions (e.g. some other
> > cgroup is writing a lot of data to the same inode), but generally
> > stays associated up to the end of life of the inode structure.
> > 
> > The problem is that the wb structure holds a reference to the original
> > memory cgroup. So if the inode was dirty once, it has a good chance
> > to pin down the original memory cgroup.
> > 
> > An example from the real life: some service runs periodically and
> > updates rpm packages. Each time in a new memory cgroup. Installed
> > .so files are heavily used by other cgroups, so corresponding inodes
> > tend to stay alive for a long. So do pinned memory cgroups.
> > In production I've seen many hosts with 1-2 thousands of dying
> > cgroups.
> > 
> > This is not the first problem with the dying memory cgroups. As
> > always, the problem is with their relative size: memory cgroups
> > are large objects, easily 100x-1000x larger that inodes. So keeping
> > a couple of thousands of dying cgroups in memory without a good reason
> > (what we easily do with inodes) is quite costly (and is measured
> > in tens and hundreds of Mb).
> > 
> > One possible approach to this problem is to switch inodes associated
> > with dying wbs to the root wb. Switching is a best effort operation
> > which can fail silently, so unfortunately we can't run once over a
> > list of associated inodes (even if we'd have such a list). So we
> > really have to scan all inodes.
> > 
> > In the proposed patch I schedule a work on each memory cgroup
> > deletion, which is probably too often. Alternatively, we can do it
> > periodically under some conditions (e.g. the number of dying memory
> > cgroups is larger than X). So it's basically a gc run.
> > 
> > I wonder if there are any better ideas?
> > 
> > Signed-off-by: Roman Gushchin 
> > ---
> >  fs/fs-writeback.c | 29 +
> >  mm/memcontrol.c   |  5 +
> >  2 files changed, 34 insertions(+)
> > 
> > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> > index 542b02d170f8..4bbc9a200b2c 100644
> > --- a/fs/fs-writeback.c
> > +++ b/fs/fs-writeback.c
> > @@ -545,6 +545,35 @@ static void inode_switch_wbs(struct inode *inode, int 
> > new_wb_id)
> > up_read(>wb_switch_rwsem);
> >  }
> >  
> > +static void reparent_dirty_inodes_one_sb(struct super_block *sb, void *arg)
> > +{
> > +   struct inode *inode, *next;
> > +
> > +   spin_lock(>s_inode_list_lock);
> > +   list_for_each_entry_safe(inode, next, >s_inodes, i_sb_list) {
> > +   spin_lock(>i_lock);
> > +   if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE)) {
> > +   spin_unlock(>i_lock);
> > +   continue;
> > +   }
> > +
> > +   if (inode->i_wb && wb_dying(inode->i_wb)) {
> > +   spin_unlock(>i_lock);
> > +   inode_switch_wbs(inode, root_mem_cgroup->css.id);
> > +   continue;
> > +   }
> > +
> > +   spin_unlock(>i_lock);
> > +   }
> > +   spin_unlock(>s_inode_list_lock);
> 
> No idea what the best solution is, but I think this is fundamentally
> unworkable. It's not uncommon to have a hundred million cached
> inodes these days, often on a single filesystem. Anything that
> requires a brute-force system wide inode scan, especially without
> conditional reschedule points, is largely a non-starter.
> 
> Also, inode_switch_wbs() is not guaranteed to move the inode to the
> destination wb.  There can only be WB_FRN_MAX_IN_FLIGHT (1024)
> switches in flight at once and switches are run via RCU callbacks,
> so I suspect that using inode_switch_wbs() for bulk re-assignment is
> going to be a lot more complex than just finding inodes to call
> inode_switch_wbs() on


We can schedule it only if the number of dying cgroups exceeds a certain
number (like 100), which will make it relatively rare event. Maybe we can
add some other conditions, e.g. count the number of inodes associated with
a wb and skip scanning if it's zero.

Alternatively the wb structure can keep the list of associated inodes,
and scan only them, but then it's not trivial to implement without
additional complication of already quite complex locking scheme.
And because inode_switch_wbs() can fail, we can't guarantee that a single
pass over such a list will be enough. That means the we need to 

Re: [PATCH] rtl8xxxu: make arrays static, makes object smaller

[Chris Chiu]

On Mon, Oct 7, 2019 at 9:53 PM Colin King  wrote:
>
> From: Colin Ian King 
>
> Don't populate const arrays on the stack but instead make them
> static. Makes the object code smaller by 60 bytes.
>
> Before:
>textdata bss dec hex filename
>   151338768   0   239015d5d realtek/rtl8xxxu/rtl8xxxu_8192e.o
>   152096392   0   216015461 realtek/rtl8xxxu/rtl8xxxu_8723b.o
>  103254   31202 576  135032   20f78 realtek/rtl8xxxu/rtl8xxxu_core.o
>
> After:
>textdata bss dec hex filename
>   148619024   0   238855d4d realtek/rtl8xxxu/rtl8xxxu_8192e.o
>   149536616   0   215695441 realtek/rtl8xxxu/rtl8xxxu_8723b.o
>  102986   31458 576  135020   20f6c realtek/rtl8xxxu/rtl8xxxu_core.o
>
> (gcc version 9.2.1, amd64)
>
> Signed-off-by: Colin Ian King 
> ---
Reviewed-by: Chris Chiu 

Re: [PATCH v2 for 5.4 2/4] media: hantro: Fix H264 max frmsize supported on RK3288

[Tomasz Figa]

Hi Ezequiel, Jonas,

On Tue, Oct 8, 2019 at 2:46 AM Ezequiel Garcia  wrote:
>
> From: Jonas Karlman 
>
> TRM specify supported image size 48x48 to 4096x2304 at step size 16 pixels,
> change frmsize max_width/max_height to match TRM.
>
> Fixes: 760327930e10 ("media: hantro: Enable H264 decoding on rk3288")
> Signed-off-by: Jonas Karlman 
> ---
> v2:
> * No changes.
>
>  drivers/staging/media/hantro/rk3288_vpu_hw.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/hantro/rk3288_vpu_hw.c 
> b/drivers/staging/media/hantro/rk3288_vpu_hw.c
> index 6bfcc47d1e58..ebb017b8a334 100644
> --- a/drivers/staging/media/hantro/rk3288_vpu_hw.c
> +++ b/drivers/staging/media/hantro/rk3288_vpu_hw.c
> @@ -67,10 +67,10 @@ static const struct hantro_fmt rk3288_vpu_dec_fmts[] = {
> .max_depth = 2,
> .frmsize = {
> .min_width = 48,
> -   .max_width = 3840,
> +   .max_width = 4096,
> .step_width = H264_MB_DIM,
> .min_height = 48,
> -   .max_height = 2160,
> +   .max_height = 2304,

This doesn't match the datasheet I have, which is RK3288 Datasheet Rev
1.4 and which has the values as in current code. What's the one you
got the values from?

Best regards,
Tomasz

Re: [PATCH 4.4 00/36] 4.4.196-stable review

[Greg Kroah-Hartman]

On Mon, Oct 07, 2019 at 03:36:46PM -0700, Guenter Roeck wrote:
> On 10/7/19 7:49 AM, Greg Kroah-Hartman wrote:
> > On Mon, Oct 07, 2019 at 05:53:55AM -0700, Guenter Roeck wrote:
> > > On 10/6/19 10:18 AM, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 4.4.196 release.
> > > > There are 36 patches in this series, all will be posted as a response
> > > > to this one.  If anyone has any issues with these being applied, please
> > > > let me know.
> > > > 
> > > > Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
> > > > Anything received after that time might be too late.
> > > > 
> > > 
> > > powerpc:defconfig fails to build.
> > > 
> > > arch/powerpc/kernel/eeh_driver.c: In function ‘eeh_handle_normal_event’:
> > > arch/powerpc/kernel/eeh_driver.c:678:2: error: implicit declaration of 
> > > function ‘eeh_for_each_pe’; did you mean ‘bus_for_each_dev’?
> > > 
> > > It has a point:
> > > 
> > > ... HEAD is now at 13cac61d31df Linux 4.4.196-rc1
> > > $ git grep eeh_for_each_pe
> > > arch/powerpc/kernel/eeh_driver.c:   eeh_for_each_pe(pe, tmp_pe)
> > > arch/powerpc/kernel/eeh_driver.c:   
> > > eeh_for_each_pe(pe, tmp_pe)
> > > 
> > > Caused by commit 3fb431be8de3a ("powerpc/eeh: Clear stale 
> > > EEH_DEV_NO_HANDLER flag").
> > > Full report will follow later.
> > 
> > Thanks for letting me know, I've dropped this from the queue now and
> > pushed out a -rc2 with that removed.
> > 
> 
> For v4.4.195-36-g898f6e5cf82f:
> 
> Build results:
>   total: 170 pass: 170 fail: 0
> Qemu test results:
>   total: 324 pass: 324 fail: 0

Wonderful, thanks for letting me know!

greg k-h

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Al Viro]

On Mon, Oct 07, 2019 at 09:14:51PM -0700, Linus Torvalds wrote:
> On Mon, Oct 7, 2019 at 9:09 PM Linus Torvalds
>  wrote:
> >
> > Try the attached patch, and then count the number of "rorx"
> > instructions in the kernel. Hint: not many. On my personal config,
> > this triggers 15 times in the whole kernel build (not counting
> > modules).
> 
> So here's a serious patch that doesn't just mark things for counting -
> it just removes the cases entirely.
> 
> Doesn't this look nice:
> 
>   2 files changed, 2 insertions(+), 133 deletions(-)
> 
> and it is one less thing to worry about when doing further cleanup.
> 
> Seriously, if any of those __copy_{to,from}_user() constant cases were
> a big deal, we can turn them into get_user/put_user calls. But only
> after they show up as an actual performance issue.

Makes sense.  I'm not arguing against doing that.  Moreover, I suspect
that other architectures will be similar, at least once the
sigframe-related code for given architecture is dealt with.  But that's
more of a "let's look at that later" thing (hopefully with maintainers
of architectures getting involved).

[PATCH] rcu: Avoid to modify mask_ofl_ipi in sync_rcu_exp_select_node_cpus()

[Boqun Feng]

"mask_ofl_ipi" is used for iterate CPUs which IPIs are needed to send
to, however in the IPI sending loop, "mask_ofl_ipi" along with another
variable "mask_ofl_test" might also get modified to record which CPU's
quiesent state can be reported by sync_rcu_exp_select_node_cpus(). Two
variables seems to be redundant for such a propose, so this patch clean
things a little by solely using "mask_ofl_test" for recording and
"mask_ofl_ipi" for iteration. This would improve the readibility of the
IPI sending loop in sync_rcu_exp_select_node_cpus().

Signed-off-by: Boqun Feng 
---
 kernel/rcu/tree_exp.h | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
index 69c5aa64fcfd..212470018752 100644
--- a/kernel/rcu/tree_exp.h
+++ b/kernel/rcu/tree_exp.h
@@ -387,10 +387,10 @@ static void sync_rcu_exp_select_node_cpus(struct 
work_struct *wp)
}
ret = smp_call_function_single(cpu, rcu_exp_handler, NULL, 0);
put_cpu();
-   if (!ret) {
-   mask_ofl_ipi &= ~mask;
+   /* The CPU responses the IPI, and will report QS itself */
+   if (!ret)
continue;
-   }
+
/* Failed, raced with CPU hotplug operation. */
raw_spin_lock_irqsave_rcu_node(rnp, flags);
if ((rnp->qsmaskinitnext & mask) &&
@@ -401,13 +401,12 @@ static void sync_rcu_exp_select_node_cpus(struct 
work_struct *wp)
schedule_timeout_uninterruptible(1);
goto retry_ipi;
}
-   /* CPU really is offline, so we can ignore it. */
-   if (!(rnp->expmask & mask))
-   mask_ofl_ipi &= ~mask;
+   /* CPU really is offline, and we need its QS to pass GP. */
+   if (rnp->expmask & mask)
+   mask_ofl_test |= mask;
raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
}
/* Report quiescent states for those that went offline. */
-   mask_ofl_test |= mask_ofl_ipi;
if (mask_ofl_test)
rcu_report_exp_cpu_mult(rnp, mask_ofl_test, false);
 }
-- 
2.23.0

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Al Viro]

On Mon, Oct 07, 2019 at 09:09:14PM -0700, Linus Torvalds wrote:

> > 1) cross-architecture user_access_begin_dont_use(): on everything
> > except x86 it's empty, on x86 - __uaccess_begin_nospec().
> 
> No, just do a proper range check, and use user_access_begin()
> 
> Stop trying to optimize that range check away. It's a couple of fast
> instructions.
> 
> The only ones who don't want the range check are the actual kernel
> copy ones, but they don't want the user_access_begin() either.

Not at the first step.  Sure, in the end we want exactly that, and
we want it ASAP.  However, the main reason it grows into a tangled
mess that would be over the top for this cycle is the impacts in
arseload of places all over arch/*.

That way we can untangle those.  The initial segment that would
allow to use raw_copy_to_user() cleanly in readdir.c et.al.
could be done with provably zero impact on anything in arch/*
outside of arch/x86 usercopy-related code.

Moreover, it will be fairly small.  And after that the rest can
be done in any order, independent from each other.  I want to
kill __copy_... completely, and I believe we'll be able to do
just that in a cycle or two.

Once that is done, the helper disappears along with __copy_...().
And it will be documented as a temporary kludge, don't use
anywhere else, no matter what from the very beginning.  For
all the couple of cycles it'll take.

I'm serious about getting rid of __copy_...() in that timeframe.
There's not that much left.

The reason I don't want to do a blanket search-and-replace turning
them all into copy_...() is simply that their use is a good indicator
of code in need of serious beating^Wamount of careful review.

And hell, we might end up doing just that on case-by-case basis.
Often enough we will, by what I'd seen there...

Again, this kluge is only a splitup aid - by the end of the series
it's gone.  All it allows is to keep it easier to review.

Note, BTW, that bits and pieces converting a given pointless use
of __copy_...() to copy_...() can be reordered freely at any point
of the sequence - I've already got several.  _Some_ of (5) will
be conversions a-la readdir.c one and that has to follow (4), but
most of it won't be like that.

> > void *copy_mount_options(const void __user * data)
> > {
> > unsigned offs, size;
> > char *copy;
> >
> > if (!data)
> > return NULL;
> >
> > copy = kmalloc(PAGE_SIZE, GFP_KERNEL);
> > if (!copy)
> > return ERR_PTR(-ENOMEM);
> >
> > offs = (unsigned long)untagged_addr(data) & (PAGE_SIZE - 1);
> >
> > if (copy_from_user(copy, data, PAGE_SIZE - offs)) {
> > kfree(copy);
> > return ERR_PTR(-EFAULT);
> > }
> > if (offs) {
> > if (copy_from_user(copy, data + PAGE_SIZE - offs, offs))
> > memset(copy + PAGE_SIZE - offs, 0, offs);
> > }
> > return copy;
> > }
> >
> > on the theory that any fault halfway through a page means a race with
> > munmap/mprotect/etc. and we can just pretend we'd lost the race entirely.
> > And to hell with exact_copy_from_user(), byte-by-byte copying, etc.
> 
> Looks reasonable.

OK...  BTW, do you agree that the use of access_ok() in
drivers/tty/n_hdlc.c:n_hdlc_tty_read() is wrong?  It's used as an early
cutoff, so we don't bother waiting if user has passed an obviously bogus
address.  copy_to_user() is used for actual copying there...

There are other places following that pattern and IMO they are all
wrong.  Another variety is a half-arsed filter trying to prevent warnings
from too large (and user-controllable) kmalloc() of buffer we'll be
copying to.  Which is worth very little, since kmalloc() will scream and
fail well before access_ok() limits will trip.  Those need explicit capping
of the size, IMO...

Re: [PATCH 0/7] pinctrl: Fixes for AST2600 support

[Joel Stanley]

On Tue, 8 Oct 2019 at 04:41, Andrew Jeffery  wrote:
>
> Hello,
>
> This series resolves several issues found in testing by Johnny Huang from
> ASPEED, who also contributed the patches to fix them. We'll have more patches
> from him in the near future (which I'm pretty happy about).

For the series:

Reviewed-by: Joel Stanley 

These patches have been in the OpenBMC tree for a while and look good.

Cheers,

Joel

>
> The major issue resolved is the way I grouped the eMMC pins. What I had was
> ugly and I want to get rid of it before the binding is solidified with the 5.4
> release.
>
> The remaining fixes are minor issues that stem from lack of documentation or
> understanding on my part, and at least one brain-fart.
>
> Please review!
>
> Andrew
>
> Andrew Jeffery (4):
>   dt-bindings: pinctrl: aspeed-g6: Rework SD3 function and groups
>   pinctrl: aspeed-g6: Sort pins for sanity
>   pinctrl: aspeed-g6: Fix I2C14 SDA description
>   pinctrl: aspeed-g6: Make SIG_DESC_CLEAR() behave intuitively
>
> Johnny Huang (3):
>   pinctrl: aspeed-g6: Fix I3C3/I3C4 pinmux configuration
>   pinctrl: aspeed-g6: Fix UART13 group pinmux
>   pinctrl: aspeed-g6: Rename SD3 to EMMC and rework pin groups
>
>  .../pinctrl/aspeed,ast2600-pinctrl.yaml   |  86 ++--
>  drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c| 124 --
>  drivers/pinctrl/aspeed/pinmux-aspeed.h|   3 +-
>  3 files changed, 98 insertions(+), 115 deletions(-)
>
> --
> 2.20.1
>

Re: [PATCH v22 16/24] x86/vdso: Add support for exception fixup in vDSO functions

[Sean Christopherson]

On Mon, Oct 07, 2019 at 03:04:12PM +0300, Jarkko Sakkinen wrote:
> On Mon, Oct 07, 2019 at 11:10:24AM +0300, Jarkko Sakkinen wrote:
> > Actually, maybe like this:
> > 
> > struct sgx_enclave_add_page_desc {
> > __u64   addr;
> > __u64   offset;
> > __u64   secinfo;
> > __u16   mrmask;
> > __u8reserved[6];
> > };
> > 
> > struct sgx_enclave_add_page {
> > __u64   src;
> > __u64   nr_pages;
> > __u64   pages;
> > };
> 
> Of course we should remove @addr:
> 
> struct sgx_enclave_add_page_desc {
>   __u64   offset;
>   __u16   mrmask;
>   __u8reserved[6];
> };
> 
> struct sgx_enclave_add_page {
>   __u64   src;
>   __u64   secinfo;
>   __u64   nr_pages;
>   __u64   pages;
> };
> 
> That is something we have forgot to do. We should have started to use
> offset instead of address when we moved to fd based API. Anyway I think
> this kind of API where you give array of descriptors from one source
> would be optimal.
> 
> Also, @secinfo is better to be out of the descriptor so that let say
> LSM checks could be done with a single callback.

Famous last words, but hopefully I can get this to you tomorrow, as well
as the vDSO changelog rewrite.

[PATCH 7/7] pinctrl: aspeed-g6: Rename SD3 to EMMC and rework pin groups

[Andrew Jeffery]

From: Johnny Huang 

AST2600 EMMC support 3 types DAT bus sizes (1, 4 and 8-bit),
corresponding to 3 groups: EMMCG1, EMMCG4 and EMMCG8

Fixes: 58dc52ad00a0 ("pinctrl: aspeed: Add AST2600 pinmux support")
Signed-off-by: Johnny Huang 
Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 72 ++
 drivers/pinctrl/aspeed/pinmux-aspeed.h |  1 +
 2 files changed, 33 insertions(+), 40 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
index dc17cf3d3549..c6800d220920 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
@@ -1440,74 +1440,72 @@ FUNC_GROUP_DECL(RGMII2, D4, C2, C1, D3, E4, F5, D2, E3, 
D1, F4, E2, E1);
 FUNC_GROUP_DECL(RMII2, D4, C2, C1, D3, D2, D1, F4, E2, E1);
 
 #define AB4 232
-SIG_EXPR_LIST_DECL_SESG(AB4, SD3CLK, SD3, SIG_DESC_SET(SCU400, 24));
-PIN_DECL_1(AB4, GPIO18D0, SD3CLK);
+SIG_EXPR_LIST_DECL_SEMG(AB4, EMMCCLK, EMMCG1, EMMC, SIG_DESC_SET(SCU400, 24));
+PIN_DECL_1(AB4, GPIO18D0, EMMCCLK);
 
 #define AA4 233
-SIG_EXPR_LIST_DECL_SESG(AA4, SD3CMD, SD3, SIG_DESC_SET(SCU400, 25));
-PIN_DECL_1(AA4, GPIO18D1, SD3CMD);
+SIG_EXPR_LIST_DECL_SEMG(AA4, EMMCCMD, EMMCG1, EMMC, SIG_DESC_SET(SCU400, 25));
+PIN_DECL_1(AA4, GPIO18D1, EMMCCMD);
 
 #define AC4 234
-SIG_EXPR_LIST_DECL_SESG(AC4, SD3DAT0, SD3, SIG_DESC_SET(SCU400, 26));
-PIN_DECL_1(AC4, GPIO18D2, SD3DAT0);
+SIG_EXPR_LIST_DECL_SEMG(AC4, EMMCDAT0, EMMCG1, EMMC, SIG_DESC_SET(SCU400, 26));
+PIN_DECL_1(AC4, GPIO18D2, EMMCDAT0);
 
 #define AA5 235
-SIG_EXPR_LIST_DECL_SESG(AA5, SD3DAT1, SD3, SIG_DESC_SET(SCU400, 27));
-PIN_DECL_1(AA5, GPIO18D3, SD3DAT1);
+SIG_EXPR_LIST_DECL_SEMG(AA5, EMMCDAT1, EMMCG4, EMMC, SIG_DESC_SET(SCU400, 27));
+PIN_DECL_1(AA5, GPIO18D3, EMMCDAT1);
 
 #define Y5 236
-SIG_EXPR_LIST_DECL_SESG(Y5, SD3DAT2, SD3, SIG_DESC_SET(SCU400, 28));
-PIN_DECL_1(Y5, GPIO18D4, SD3DAT2);
+SIG_EXPR_LIST_DECL_SEMG(Y5, EMMCDAT2, EMMCG4, EMMC, SIG_DESC_SET(SCU400, 28));
+PIN_DECL_1(Y5, GPIO18D4, EMMCDAT2);
 
 #define AB5 237
-SIG_EXPR_LIST_DECL_SESG(AB5, SD3DAT3, SD3, SIG_DESC_SET(SCU400, 29));
-PIN_DECL_1(AB5, GPIO18D5, SD3DAT3);
+SIG_EXPR_LIST_DECL_SEMG(AB5, EMMCDAT3, EMMCG4, EMMC, SIG_DESC_SET(SCU400, 29));
+PIN_DECL_1(AB5, GPIO18D5, EMMCDAT3);
 
 #define AB6 238
-SIG_EXPR_LIST_DECL_SESG(AB6, SD3CD, SD3, SIG_DESC_SET(SCU400, 30));
-PIN_DECL_1(AB6, GPIO18D6, SD3CD);
+SIG_EXPR_LIST_DECL_SEMG(AB6, EMMCCD, EMMCG1, EMMC, SIG_DESC_SET(SCU400, 30));
+PIN_DECL_1(AB6, GPIO18D6, EMMCCD);
 
 #define AC5 239
-SIG_EXPR_LIST_DECL_SESG(AC5, SD3WP, SD3, SIG_DESC_SET(SCU400, 31));
-PIN_DECL_1(AC5, GPIO18D7, SD3WP);
+SIG_EXPR_LIST_DECL_SEMG(AC5, EMMCWP, EMMCG1, EMMC, SIG_DESC_SET(SCU400, 31));
+PIN_DECL_1(AC5, GPIO18D7, EMMCWP);
 
-FUNC_GROUP_DECL(SD3, AB4, AA4, AC4, AA5, Y5, AB5, AB6, AC5);
+GROUP_DECL(EMMCG1, AB4, AA4, AC4, AB6, AC5);
+GROUP_DECL(EMMCG4, AB4, AA4, AC4, AA5, Y5, AB5, AB6, AC5);
 
 #define Y1 240
 SIG_EXPR_LIST_DECL_SEMG(Y1, FWSPIDCS, FWSPID, FWSPID, SIG_DESC_SET(SCU500, 3));
 SIG_EXPR_LIST_DECL_SESG(Y1, VBCS, VB, SIG_DESC_SET(SCU500, 5));
-SIG_EXPR_LIST_DECL_SESG(Y1, SD3DAT4, SD3DAT4, SIG_DESC_SET(SCU404, 0));
-PIN_DECL_3(Y1, GPIO18E0, FWSPIDCS, VBCS, SD3DAT4);
-FUNC_GROUP_DECL(SD3DAT4, Y1);
+SIG_EXPR_LIST_DECL_SEMG(Y1, EMMCDAT4, EMMCG8, EMMC, SIG_DESC_SET(SCU404, 0));
+PIN_DECL_3(Y1, GPIO18E0, FWSPIDCS, VBCS, EMMCDAT4);
 
 #define Y2 241
 SIG_EXPR_LIST_DECL_SEMG(Y2, FWSPIDCK, FWSPID, FWSPID, SIG_DESC_SET(SCU500, 3));
 SIG_EXPR_LIST_DECL_SESG(Y2, VBCK, VB, SIG_DESC_SET(SCU500, 5));
-SIG_EXPR_LIST_DECL_SESG(Y2, SD3DAT5, SD3DAT5, SIG_DESC_SET(SCU404, 1));
-PIN_DECL_3(Y2, GPIO18E1, FWSPIDCK, VBCK, SD3DAT5);
-FUNC_GROUP_DECL(SD3DAT5, Y2);
+SIG_EXPR_LIST_DECL_SEMG(Y2, EMMCDAT5, EMMCG8, EMMC, SIG_DESC_SET(SCU404, 1));
+PIN_DECL_3(Y2, GPIO18E1, FWSPIDCK, VBCK, EMMCDAT5);
 
 #define Y3 242
 SIG_EXPR_LIST_DECL_SEMG(Y3, FWSPIDMOSI, FWSPID, FWSPID,
SIG_DESC_SET(SCU500, 3));
 SIG_EXPR_LIST_DECL_SESG(Y3, VBMOSI, VB, SIG_DESC_SET(SCU500, 5));
-SIG_EXPR_LIST_DECL_SESG(Y3, SD3DAT6, SD3DAT6, SIG_DESC_SET(SCU404, 2));
-PIN_DECL_3(Y3, GPIO18E2, FWSPIDMOSI, VBMOSI, SD3DAT6);
-FUNC_GROUP_DECL(SD3DAT6, Y3);
+SIG_EXPR_LIST_DECL_SEMG(Y3, EMMCDAT6, EMMCG8, EMMC, SIG_DESC_SET(SCU404, 2));
+PIN_DECL_3(Y3, GPIO18E2, FWSPIDMOSI, VBMOSI, EMMCDAT6);
 
 #define Y4 243
 SIG_EXPR_LIST_DECL_SEMG(Y4, FWSPIDMISO, FWSPID, FWSPID,
SIG_DESC_SET(SCU500, 3));
 SIG_EXPR_LIST_DECL_SESG(Y4, VBMISO, VB, SIG_DESC_SET(SCU500, 5));
-SIG_EXPR_LIST_DECL_SESG(Y4, SD3DAT7, SD3DAT7, SIG_DESC_SET(SCU404, 3));
-PIN_DECL_3(Y4, GPIO18E3, FWSPIDMISO, VBMISO, SD3DAT7);
-FUNC_GROUP_DECL(SD3DAT7, Y4);
+SIG_EXPR_LIST_DECL_SEMG(Y4, EMMCDAT7, EMMCG8, EMMC, SIG_DESC_SET(SCU404, 3));
+PIN_DECL_3(Y4, GPIO18E3, FWSPIDMISO, VBMISO, EMMCDAT7);
 
 GROUP_DECL(FWSPID, Y1, Y2, Y3, Y4);
 GROUP_DECL(FWQSPID, Y1, Y2, Y3, Y4, AE12, AF12);
+GROUP_DECL(EMMCG8, AB4, AA4, AC4, AA5, Y5, AB5, AB6, AC5, Y1, Y2, Y3, Y4);
 

[PATCH 4/7] pinctrl: aspeed-g6: Fix I3C3/I3C4 pinmux configuration

[Andrew Jeffery]

From: Johnny Huang 

The documentation to configure I3C3/FSI1 and I3C4/FSI2 was initially
unclear.

Fixes: 58dc52ad00a0 ("pinctrl: aspeed: Add AST2600 pinmux support")
Signed-off-by: Johnny Huang 
[AJ: Tweak commit message, resolve rebase conflicts]
Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 24 --
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
index 9079655cc818..68b066594461 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
@@ -1513,18 +1513,14 @@ FUNC_GROUP_DECL(VB, Y1, Y2, Y3, Y4);
  * following 4 pins
  */
 #define AF25 244
-SIG_EXPR_LIST_DECL_SEMG(AF25, I3C3SCL, I3C3, I3C3, SIG_DESC_SET(SCU438, 20),
-   SIG_DESC_SET(SCU4D8, 20));
-SIG_EXPR_LIST_DECL_SESG(AF25, FSI1CLK, FSI1, SIG_DESC_CLEAR(SCU438, 20),
-   SIG_DESC_SET(SCU4D8, 20));
+SIG_EXPR_LIST_DECL_SEMG(AF25, I3C3SCL, I3C3, I3C3, SIG_DESC_SET(SCU438, 20));
+SIG_EXPR_LIST_DECL_SESG(AF25, FSI1CLK, FSI1, SIG_DESC_SET(SCU4D8, 20));
 PIN_DECL_(AF25, SIG_EXPR_LIST_PTR(AF25, I3C3SCL),
  SIG_EXPR_LIST_PTR(AF25, FSI1CLK));
 
 #define AE26 245
-SIG_EXPR_LIST_DECL_SEMG(AE26, I3C3SDA, I3C3, I3C3, SIG_DESC_SET(SCU438, 21),
-   SIG_DESC_SET(SCU4D8, 21));
-SIG_EXPR_LIST_DECL_SESG(AE26, FSI1DATA, FSI1, SIG_DESC_CLEAR(SCU438, 21),
-   SIG_DESC_SET(SCU4D8, 21));
+SIG_EXPR_LIST_DECL_SEMG(AE26, I3C3SDA, I3C3, I3C3, SIG_DESC_SET(SCU438, 21));
+SIG_EXPR_LIST_DECL_SESG(AE26, FSI1DATA, FSI1, SIG_DESC_SET(SCU4D8, 21));
 PIN_DECL_(AE26, SIG_EXPR_LIST_PTR(AE26, I3C3SDA),
  SIG_EXPR_LIST_PTR(AE26, FSI1DATA));
 
@@ -1533,18 +1529,14 @@ FUNC_DECL_2(I3C3, HVI3C3, I3C3);
 FUNC_GROUP_DECL(FSI1, AF25, AE26);
 
 #define AE25 246
-SIG_EXPR_LIST_DECL_SEMG(AE25, I3C4SCL, I3C4, I3C4, SIG_DESC_SET(SCU438, 22),
-   SIG_DESC_SET(SCU4D8, 22));
-SIG_EXPR_LIST_DECL_SESG(AE25, FSI2CLK, FSI2, SIG_DESC_CLEAR(SCU438, 22),
-   SIG_DESC_SET(SCU4D8, 22));
+SIG_EXPR_LIST_DECL_SEMG(AE25, I3C4SCL, I3C4, I3C4, SIG_DESC_SET(SCU438, 22));
+SIG_EXPR_LIST_DECL_SESG(AE25, FSI2CLK, FSI2, SIG_DESC_SET(SCU4D8, 22));
 PIN_DECL_(AE25, SIG_EXPR_LIST_PTR(AE25, I3C4SCL),
  SIG_EXPR_LIST_PTR(AE25, FSI2CLK));
 
 #define AF24 247
-SIG_EXPR_LIST_DECL_SEMG(AF24, I3C4SDA, I3C4, I3C4, SIG_DESC_SET(SCU438, 23),
-   SIG_DESC_SET(SCU4D8, 23));
-SIG_EXPR_LIST_DECL_SESG(AF24, FSI2DATA, FSI2, SIG_DESC_CLEAR(SCU438, 23),
-   SIG_DESC_SET(SCU4D8, 23));
+SIG_EXPR_LIST_DECL_SEMG(AF24, I3C4SDA, I3C4, I3C4, SIG_DESC_SET(SCU438, 23));
+SIG_EXPR_LIST_DECL_SESG(AF24, FSI2DATA, FSI2, SIG_DESC_SET(SCU4D8, 23));
 PIN_DECL_(AF24, SIG_EXPR_LIST_PTR(AF24, I3C4SDA),
  SIG_EXPR_LIST_PTR(AF24, FSI2DATA));
 
-- 
2.20.1

[PATCH 5/7] pinctrl: aspeed-g6: Make SIG_DESC_CLEAR() behave intuitively

[Andrew Jeffery]

Signal descriptors can represent multi-bit bitfields and so have
explicit "enable" and "disable" states. However many descriptor
instances only describe a single bit, and so the SIG_DESC_SET() macro is
provides an abstraction for the single-bit cases: Its expansion
configures the "enable" state to set the bit and "disable" to clear.

SIG_DESC_CLEAR() was introduced to provide a similar single-bit
abstraction for for descriptors to clear the bit of interest. However
its behaviour was defined as the literal inverse of SIG_DESC_SET() - the
impact is the bit of interest is set in the disable path. This behaviour
isn't intuitive and doesn't align with how we want to use the macro in
practice, so make it clear the bit for both the enable and disable
paths.

Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinmux-aspeed.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.h 
b/drivers/pinctrl/aspeed/pinmux-aspeed.h
index a2c0d52e4f7b..d5202241f411 100644
--- a/drivers/pinctrl/aspeed/pinmux-aspeed.h
+++ b/drivers/pinctrl/aspeed/pinmux-aspeed.h
@@ -508,7 +508,7 @@ struct aspeed_pin_desc {
  * @idx: The bit index in the register
  */
 #define SIG_DESC_SET(reg, idx) SIG_DESC_IP_BIT(ASPEED_IP_SCU, reg, idx, 1)
-#define SIG_DESC_CLEAR(reg, idx) SIG_DESC_IP_BIT(ASPEED_IP_SCU, reg, idx, 0)
+#define SIG_DESC_CLEAR(reg, idx) { ASPEED_IP_SCU, reg, BIT_MASK(idx), 0, 0 }
 
 #define SIG_DESC_LIST_SYM(sig, group) sig_descs_ ## sig ## _ ## group
 #define SIG_DESC_LIST_DECL(sig, group, ...) \
-- 
2.20.1

[PATCH 6/7] pinctrl: aspeed-g6: Fix UART13 group pinmux

[Andrew Jeffery]

From: Johnny Huang 

When UART13G1 is set the pinmux configuration in SCU4B8 for UART13G0
should be cleared.

Fixes: 58dc52ad00a0 ("pinctrl: aspeed: Add AST2600 pinmux support")
Signed-off-by: Johnny Huang 
[AJ: Tweak commit message]
Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
index 68b066594461..dc17cf3d3549 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
@@ -1262,13 +1262,13 @@ GROUP_DECL(SPI1, AB11, AC11, AA11);
 #define AD11 206
 SIG_EXPR_LIST_DECL_SEMG(AD11, SPI1DQ2, QSPI1, SPI1, SIG_DESC_SET(SCU438, 14));
 SIG_EXPR_LIST_DECL_SEMG(AD11, TXD13, UART13G1, UART13,
-   SIG_DESC_SET(SCU438, 14));
+   SIG_DESC_CLEAR(SCU4B8, 2), SIG_DESC_SET(SCU4D8, 14));
 PIN_DECL_2(AD11, GPIOZ6, SPI1DQ2, TXD13);
 
 #define AF10 207
 SIG_EXPR_LIST_DECL_SEMG(AF10, SPI1DQ3, QSPI1, SPI1, SIG_DESC_SET(SCU438, 15));
 SIG_EXPR_LIST_DECL_SEMG(AF10, RXD13, UART13G1, UART13,
-   SIG_DESC_SET(SCU438, 15));
+   SIG_DESC_CLEAR(SCU4B8, 3), SIG_DESC_SET(SCU4D8, 15));
 PIN_DECL_2(AF10, GPIOZ7, SPI1DQ3, RXD13);
 
 GROUP_DECL(QSPI1, AB11, AC11, AA11, AD11, AF10);
-- 
2.20.1

[PATCH 3/7] pinctrl: aspeed-g6: Fix I2C14 SDA description

[Andrew Jeffery]

The I2C function the pin participated in was incorrectly named SDA14
which lead to a failure to mux:

[6.884344] No function I2C14 found on pin 7 (7). Found signal(s) MACLINK4, 
SDA14, GPIOA7 for function(s) MACLINK4, SDA14, GPIOA7

Fixes: 58dc52ad00a0 ("pinctrl: aspeed: Add AST2600 pinmux support")
Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
index ff208b7c75a8..9079655cc818 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
@@ -87,7 +87,7 @@ FUNC_GROUP_DECL(MACLINK3, L23);
 
 #define K25 7
 SIG_EXPR_LIST_DECL_SESG(K25, MACLINK4, MACLINK4, SIG_DESC_SET(SCU410, 7));
-SIG_EXPR_LIST_DECL_SESG(K25, SDA14, SDA14, SIG_DESC_SET(SCU4B0, 7));
+SIG_EXPR_LIST_DECL_SESG(K25, SDA14, I2C14, SIG_DESC_SET(SCU4B0, 7));
 PIN_DECL_2(K25, GPIOA7, MACLINK4, SDA14);
 FUNC_GROUP_DECL(MACLINK4, K25);
 
-- 
2.20.1

[PATCH 2/7] pinctrl: aspeed-g6: Sort pins for sanity

[Andrew Jeffery]

Some pins crept in that weren't ordered in the list.

Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
index 648ddb7f038a..ff208b7c75a8 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
@@ -1574,6 +1574,8 @@ static struct pinctrl_pin_desc 
aspeed_g6_pins[ASPEED_G6_NR_PINS] = {
ASPEED_PINCTRL_PIN(A3),
ASPEED_PINCTRL_PIN(AA11),
ASPEED_PINCTRL_PIN(AA12),
+   ASPEED_PINCTRL_PIN(AA16),
+   ASPEED_PINCTRL_PIN(AA17),
ASPEED_PINCTRL_PIN(AA23),
ASPEED_PINCTRL_PIN(AA24),
ASPEED_PINCTRL_PIN(AA25),
@@ -1585,6 +1587,8 @@ static struct pinctrl_pin_desc 
aspeed_g6_pins[ASPEED_G6_NR_PINS] = {
ASPEED_PINCTRL_PIN(AB11),
ASPEED_PINCTRL_PIN(AB12),
ASPEED_PINCTRL_PIN(AB15),
+   ASPEED_PINCTRL_PIN(AB16),
+   ASPEED_PINCTRL_PIN(AB17),
ASPEED_PINCTRL_PIN(AB18),
ASPEED_PINCTRL_PIN(AB19),
ASPEED_PINCTRL_PIN(AB22),
@@ -1602,6 +1606,7 @@ static struct pinctrl_pin_desc 
aspeed_g6_pins[ASPEED_G6_NR_PINS] = {
ASPEED_PINCTRL_PIN(AC11),
ASPEED_PINCTRL_PIN(AC12),
ASPEED_PINCTRL_PIN(AC15),
+   ASPEED_PINCTRL_PIN(AC16),
ASPEED_PINCTRL_PIN(AC17),
ASPEED_PINCTRL_PIN(AC18),
ASPEED_PINCTRL_PIN(AC19),
@@ -1619,6 +1624,7 @@ static struct pinctrl_pin_desc 
aspeed_g6_pins[ASPEED_G6_NR_PINS] = {
ASPEED_PINCTRL_PIN(AD12),
ASPEED_PINCTRL_PIN(AD14),
ASPEED_PINCTRL_PIN(AD15),
+   ASPEED_PINCTRL_PIN(AD16),
ASPEED_PINCTRL_PIN(AD19),
ASPEED_PINCTRL_PIN(AD20),
ASPEED_PINCTRL_PIN(AD22),
@@ -1634,8 +1640,11 @@ static struct pinctrl_pin_desc 
aspeed_g6_pins[ASPEED_G6_NR_PINS] = {
ASPEED_PINCTRL_PIN(AE12),
ASPEED_PINCTRL_PIN(AE14),
ASPEED_PINCTRL_PIN(AE15),
+   ASPEED_PINCTRL_PIN(AE16),
ASPEED_PINCTRL_PIN(AE18),
ASPEED_PINCTRL_PIN(AE19),
+   ASPEED_PINCTRL_PIN(AE25),
+   ASPEED_PINCTRL_PIN(AE26),
ASPEED_PINCTRL_PIN(AE7),
ASPEED_PINCTRL_PIN(AE8),
ASPEED_PINCTRL_PIN(AF10),
@@ -1643,6 +1652,8 @@ static struct pinctrl_pin_desc 
aspeed_g6_pins[ASPEED_G6_NR_PINS] = {
ASPEED_PINCTRL_PIN(AF12),
ASPEED_PINCTRL_PIN(AF14),
ASPEED_PINCTRL_PIN(AF15),
+   ASPEED_PINCTRL_PIN(AF24),
+   ASPEED_PINCTRL_PIN(AF25),
ASPEED_PINCTRL_PIN(AF7),
ASPEED_PINCTRL_PIN(AF8),
ASPEED_PINCTRL_PIN(AF9),
@@ -1792,17 +1803,6 @@ static struct pinctrl_pin_desc 
aspeed_g6_pins[ASPEED_G6_NR_PINS] = {
ASPEED_PINCTRL_PIN(Y3),
ASPEED_PINCTRL_PIN(Y4),
ASPEED_PINCTRL_PIN(Y5),
-   ASPEED_PINCTRL_PIN(AB16),
-   ASPEED_PINCTRL_PIN(AA17),
-   ASPEED_PINCTRL_PIN(AB17),
-   ASPEED_PINCTRL_PIN(AE16),
-   ASPEED_PINCTRL_PIN(AC16),
-   ASPEED_PINCTRL_PIN(AA16),
-   ASPEED_PINCTRL_PIN(AD16),
-   ASPEED_PINCTRL_PIN(AF25),
-   ASPEED_PINCTRL_PIN(AE26),
-   ASPEED_PINCTRL_PIN(AE25),
-   ASPEED_PINCTRL_PIN(AF24),
 };
 
 static const struct aspeed_pin_group aspeed_g6_groups[] = {
-- 
2.20.1

[PATCH 0/7] pinctrl: Fixes for AST2600 support

[Andrew Jeffery]

Hello,

This series resolves several issues found in testing by Johnny Huang from
ASPEED, who also contributed the patches to fix them. We'll have more patches
from him in the near future (which I'm pretty happy about).

The major issue resolved is the way I grouped the eMMC pins. What I had was
ugly and I want to get rid of it before the binding is solidified with the 5.4
release.

The remaining fixes are minor issues that stem from lack of documentation or
understanding on my part, and at least one brain-fart.

Please review!

Andrew

Andrew Jeffery (4):
  dt-bindings: pinctrl: aspeed-g6: Rework SD3 function and groups
  pinctrl: aspeed-g6: Sort pins for sanity
  pinctrl: aspeed-g6: Fix I2C14 SDA description
  pinctrl: aspeed-g6: Make SIG_DESC_CLEAR() behave intuitively

Johnny Huang (3):
  pinctrl: aspeed-g6: Fix I3C3/I3C4 pinmux configuration
  pinctrl: aspeed-g6: Fix UART13 group pinmux
  pinctrl: aspeed-g6: Rename SD3 to EMMC and rework pin groups

 .../pinctrl/aspeed,ast2600-pinctrl.yaml   |  86 ++--
 drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c| 124 --
 drivers/pinctrl/aspeed/pinmux-aspeed.h|   3 +-
 3 files changed, 98 insertions(+), 115 deletions(-)

-- 
2.20.1

[PATCH 1/7] dt-bindings: pinctrl: aspeed-g6: Rework SD3 function and groups

[Andrew Jeffery]

Rename SD3 functions and groups to EMMC to better reflect their intended
use before the binding escapes too far into the wild. Also clean up the
SD3 pin groups to eliminate some silliness that slipped through the
cracks (SD3DAT[4-7]) by unifying them into three new groups: EMMCG1,
EMMCG4 and EMMCG8 for 1, 4 and 8-bit data buses respectively.

Signed-off-by: Andrew Jeffery 
---
Unfortunately reflowing the list creates a lot of noise in this change. As
mentioned the SD3DAT[4-7] groups are renamed, as is the SD3 function. There
should be no functional changes beyond that.

 .../pinctrl/aspeed,ast2600-pinctrl.yaml   | 86 +--
 1 file changed, 42 insertions(+), 44 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml 
b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml
index f83d888176cc..064b7dfc4252 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml
@@ -33,13 +33,13 @@ patternProperties:
   allOf:
 - $ref: "/schemas/types.yaml#/definitions/string"
 - enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15,
-  ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, ESPI,
-  ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1,
-  GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2,
-  GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, I2C1, I2C10, I2C11, I2C12,
-  I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, I2C6, I2C7,
-  I2C8, I2C9, I3C3, I3C4, I3C5, I3C6, JTAGM, LHPD, LHSIRQ, LPC,
-  LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, MACLINK1, MACLINK2,
+  ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMC,
+  ESPI, ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWSPIWP, GPIT0,
+  GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1,
+  GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, I2C1, I2C10, I2C11,
+  I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, I2C6,
+  I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, I3C6, JTAGM, LHPD, LHSIRQ,
+  LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, MACLINK1, MACLINK2,
   MACLINK3, MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4, NCTS1, NCTS2,
   NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, NDSR3,
   NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, NRTS1,
@@ -48,47 +48,45 @@ patternProperties:
   PWM8, PWM9, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3,
   RMII4, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12,
   SALT13, SALT14, SALT15, SALT16, SALT2, SALT3, SALT4, SALT5,
-  SALT6, SALT7, SALT8, SALT9, SD1, SD2, SD3, SD3DAT4, SD3DAT5,
-  SD3DAT6, SD3DAT7, SGPM1, SGPS1, SIOONCTRL, SIOPBI, SIOPBO,
-  SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1,
-  SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11,
-  TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, TACH4, TACH5,
-  TACH6, TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, THRU3, TXD1,
-  TXD2, TXD3, TXD4, UART10, UART11, UART12, UART13, UART6, UART7,
-  UART8, UART9, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3,
-  WDTRST4, ]
+  SALT6, SALT7, SALT8, SALT9, SD1, SD2, SGPM1, SGPS1, SIOONCTRL,
+  SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1,
+  SPI1ABR, SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1,
+  TACH10, TACH11, TACH12, TACH13, TACH14, TACH15, TACH2, TACH3,
+  TACH4, TACH5, TACH6, TACH7, TACH8, TACH9, THRU0, THRU1, THRU2,
+  THRU3, TXD1, TXD2, TXD3, TXD4, UART10, UART11, UART12, UART13,
+  UART6, UART7, UART8, UART9, VB, VGAHS, VGAVS, WDTRST1, WDTRST2,
+  WDTRST3, WDTRST4, ]
 groups:
   allOf:
 - $ref: "/schemas/types.yaml#/definitions/string"
 - enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15,
-  ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, ESPI,
-  ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWQSPID, FWSPIWP, GPIT0,
-  GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1,
-  GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, HVI3C3, HVI3C4, I2C1,
-  I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3,
-  I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, I3C6,
-  JTAGM, LHPD, LHSIRQ, LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ,
-  MACLINK1, MACLINK2, MACLINK3, MACLINK4, MDIO1, MDIO2, MDIO3,
-  MDIO4, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4,
-  NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, 

Re: [PATCH V8 2/2] arm64/mm: Enable memory hot remove

[Anshuman Khandual]

On 10/07/2019 07:47 PM, Catalin Marinas wrote:
> On Mon, Sep 23, 2019 at 11:13:45AM +0530, Anshuman Khandual wrote:
>> The arch code for hot-remove must tear down portions of the linear map and
>> vmemmap corresponding to memory being removed. In both cases the page
>> tables mapping these regions must be freed, and when sparse vmemmap is in
>> use the memory backing the vmemmap must also be freed.
>>
>> This patch adds unmap_hotplug_range() and free_empty_tables() helpers which
>> can be used to tear down either region and calls it from vmemmap_free() and
>> ___remove_pgd_mapping(). The sparse_vmap argument determines whether the
>> backing memory will be freed.
> 
> Can you change the 'sparse_vmap' name to something more meaningful which
> would suggest freeing of the backing memory?

free_mapped_mem or free_backed_mem ? Even shorter forms like free_mapped or
free_backed might do as well. Do you have a particular preference here ? But
yes, sparse_vmap has been very much specific to vmemmap for these functions
which are now very generic in nature.

> 
>> It makes two distinct passes over the kernel page table. In the first pass
>> with unmap_hotplug_range() it unmaps, invalidates applicable TLB cache and
>> frees backing memory if required (vmemmap) for each mapped leaf entry. In
>> the second pass with free_empty_tables() it looks for empty page table
>> sections whose page table page can be unmapped, TLB invalidated and freed.
>>
>> While freeing intermediate level page table pages bail out if any of its
>> entries are still valid. This can happen for partially filled kernel page
>> table either from a previously attempted failed memory hot add or while
>> removing an address range which does not span the entire page table page
>> range.
>>
>> The vmemmap region may share levels of table with the vmalloc region.
>> There can be conflicts between hot remove freeing page table pages with
>> a concurrent vmalloc() walking the kernel page table. This conflict can
>> not just be solved by taking the init_mm ptl because of existing locking
>> scheme in vmalloc(). So free_empty_tables() implements a floor and ceiling
>> method which is borrowed from user page table tear with free_pgd_range()
>> which skips freeing page table pages if intermediate address range is not
>> aligned or maximum floor-ceiling might not own the entire page table page.
>>
>> While here update arch_add_memory() to handle __add_pages() failures by
>> just unmapping recently added kernel linear mapping. Now enable memory hot
>> remove on arm64 platforms by default with ARCH_ENABLE_MEMORY_HOTREMOVE.
>>
>> This implementation is overall inspired from kernel page table tear down
>> procedure on X86 architecture and user page table tear down method.
>>
>> Acked-by: Steve Capper 
>> Acked-by: David Hildenbrand 
>> Signed-off-by: Anshuman Khandual 
> 
> Given the amount of changes since version 7, do the acks still stand?

I had taken the liberty to carry them till V7 where the implementation has
been sort of structurally similar but as you mention, there have been some
basic changes in the approach since V7. Will drop these tags in next version
and request their fresh ACKs once again.

> 
> [...]
>> +static void free_pte_table(pmd_t *pmdp, unsigned long addr, unsigned long 
>> end,
>> +   unsigned long floor, unsigned long ceiling)
>> +{
>> +struct page *page;
>> +pte_t *ptep;
>> +int i;
>> +
>> +if (!pgtable_range_aligned(addr, end, floor, ceiling, PMD_MASK))
>> +return;
>> +
>> +ptep = pte_offset_kernel(pmdp, 0UL);
>> +for (i = 0; i < PTRS_PER_PTE; i++) {
>> +if (!pte_none(READ_ONCE(ptep[i])))
>> +return;
>> +}
>> +
>> +page = pmd_page(READ_ONCE(*pmdp));
> 
> Arguably, that's not the pmd page we are freeing here. Even if you get
> the same result, pmd_page() is normally used for huge pages pointed at
> by the pmd entry. Since you have the ptep already, why not use
> virt_to_page(ptep)?

Makes sense, will do.

> 
>> +pmd_clear(pmdp);
>> +__flush_tlb_kernel_pgtable(addr);
>> +free_hotplug_pgtable_page(page);
>> +}
>> +
>> +static void free_pmd_table(pud_t *pudp, unsigned long addr, unsigned long 
>> end,
>> +   unsigned long floor, unsigned long ceiling)
>> +{
>> +struct page *page;
>> +pmd_t *pmdp;
>> +int i;
>> +
>> +if (CONFIG_PGTABLE_LEVELS <= 2)
>> +return;
>> +
>> +if (!pgtable_range_aligned(addr, end, floor, ceiling, PUD_MASK))
>> +return;
>> +
>> +pmdp = pmd_offset(pudp, 0UL);
>> +for (i = 0; i < PTRS_PER_PMD; i++) {
>> +if (!pmd_none(READ_ONCE(pmdp[i])))
>> +return;
>> +}
>> +
>> +page = pud_page(READ_ONCE(*pudp));
> 
> Same here, virt_to_page(pmdp).

Will do.

> 
>> +pud_clear(pudp);
>> +__flush_tlb_kernel_pgtable(addr);
>> +free_hotplug_pgtable_page(page);
>> +}
>> +
>> +static void 

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Linus Torvalds]

On Mon, Oct 7, 2019 at 9:09 PM Linus Torvalds
 wrote:
>
> Try the attached patch, and then count the number of "rorx"
> instructions in the kernel. Hint: not many. On my personal config,
> this triggers 15 times in the whole kernel build (not counting
> modules).

.. and four of them are in perf_callchain_user(), and are due to those
"__copy_from_user_nmi()" with either 4-byte or 8-byte copies.

It might as well just use __get_user() instead.

The point being that the silly code in the header files is just
pointless. We shouldn't do it.

Linus

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Linus Torvalds]

On Mon, Oct 7, 2019 at 9:09 PM Linus Torvalds
 wrote:
>
> Try the attached patch, and then count the number of "rorx"
> instructions in the kernel. Hint: not many. On my personal config,
> this triggers 15 times in the whole kernel build (not counting
> modules).

So here's a serious patch that doesn't just mark things for counting -
it just removes the cases entirely.

Doesn't this look nice:

  2 files changed, 2 insertions(+), 133 deletions(-)

and it is one less thing to worry about when doing further cleanup.

Seriously, if any of those __copy_{to,from}_user() constant cases were
a big deal, we can turn them into get_user/put_user calls. But only
after they show up as an actual performance issue.

Linus
 arch/x86/include/asm/uaccess_32.h |  27 --
 arch/x86/include/asm/uaccess_64.h | 108 +-
 2 files changed, 2 insertions(+), 133 deletions(-)

diff --git a/arch/x86/include/asm/uaccess_32.h b/arch/x86/include/asm/uaccess_32.h
index ba2dc1930630..388a40660c7b 100644
--- a/arch/x86/include/asm/uaccess_32.h
+++ b/arch/x86/include/asm/uaccess_32.h
@@ -23,33 +23,6 @@ raw_copy_to_user(void __user *to, const void *from, unsigned long n)
 static __always_inline unsigned long
 raw_copy_from_user(void *to, const void __user *from, unsigned long n)
 {
-	if (__builtin_constant_p(n)) {
-		unsigned long ret;
-
-		switch (n) {
-		case 1:
-			ret = 0;
-			__uaccess_begin_nospec();
-			__get_user_asm_nozero(*(u8 *)to, from, ret,
-	  "b", "b", "=q", 1);
-			__uaccess_end();
-			return ret;
-		case 2:
-			ret = 0;
-			__uaccess_begin_nospec();
-			__get_user_asm_nozero(*(u16 *)to, from, ret,
-	  "w", "w", "=r", 2);
-			__uaccess_end();
-			return ret;
-		case 4:
-			ret = 0;
-			__uaccess_begin_nospec();
-			__get_user_asm_nozero(*(u32 *)to, from, ret,
-	  "l", "k", "=r", 4);
-			__uaccess_end();
-			return ret;
-		}
-	}
 	return __copy_user_ll(to, (__force const void *)from, n);
 }
 
diff --git a/arch/x86/include/asm/uaccess_64.h b/arch/x86/include/asm/uaccess_64.h
index 5cd1caa8bc65..bc10e3dc64fe 100644
--- a/arch/x86/include/asm/uaccess_64.h
+++ b/arch/x86/include/asm/uaccess_64.h
@@ -65,117 +65,13 @@ copy_to_user_mcsafe(void *to, const void *from, unsigned len)
 static __always_inline __must_check unsigned long
 raw_copy_from_user(void *dst, const void __user *src, unsigned long size)
 {
-	int ret = 0;
-
-	if (!__builtin_constant_p(size))
-		return copy_user_generic(dst, (__force void *)src, size);
-	switch (size) {
-	case 1:
-		__uaccess_begin_nospec();
-		__get_user_asm_nozero(*(u8 *)dst, (u8 __user *)src,
-			  ret, "b", "b", "=q", 1);
-		__uaccess_end();
-		return ret;
-	case 2:
-		__uaccess_begin_nospec();
-		__get_user_asm_nozero(*(u16 *)dst, (u16 __user *)src,
-			  ret, "w", "w", "=r", 2);
-		__uaccess_end();
-		return ret;
-	case 4:
-		__uaccess_begin_nospec();
-		__get_user_asm_nozero(*(u32 *)dst, (u32 __user *)src,
-			  ret, "l", "k", "=r", 4);
-		__uaccess_end();
-		return ret;
-	case 8:
-		__uaccess_begin_nospec();
-		__get_user_asm_nozero(*(u64 *)dst, (u64 __user *)src,
-			  ret, "q", "", "=r", 8);
-		__uaccess_end();
-		return ret;
-	case 10:
-		__uaccess_begin_nospec();
-		__get_user_asm_nozero(*(u64 *)dst, (u64 __user *)src,
-			   ret, "q", "", "=r", 10);
-		if (likely(!ret))
-			__get_user_asm_nozero(*(u16 *)(8 + (char *)dst),
-   (u16 __user *)(8 + (char __user *)src),
-   ret, "w", "w", "=r", 2);
-		__uaccess_end();
-		return ret;
-	case 16:
-		__uaccess_begin_nospec();
-		__get_user_asm_nozero(*(u64 *)dst, (u64 __user *)src,
-			   ret, "q", "", "=r", 16);
-		if (likely(!ret))
-			__get_user_asm_nozero(*(u64 *)(8 + (char *)dst),
-   (u64 __user *)(8 + (char __user *)src),
-   ret, "q", "", "=r", 8);
-		__uaccess_end();
-		return ret;
-	default:
-		return copy_user_generic(dst, (__force void *)src, size);
-	}
+	return copy_user_generic(dst, (__force void *)src, size);
 }
 
 static __always_inline __must_check unsigned long
 raw_copy_to_user(void __user *dst, const void *src, unsigned long size)
 {
-	int ret = 0;
-
-	if (!__builtin_constant_p(size))
-		return copy_user_generic((__force void *)dst, src, size);
-	switch (size) {
-	case 1:
-		__uaccess_begin();
-		__put_user_asm(*(u8 *)src, (u8 __user *)dst,
-			  ret, "b", "b", "iq", 1);
-		__uaccess_end();
-		return ret;
-	case 2:
-		__uaccess_begin();
-		__put_user_asm(*(u16 *)src, (u16 __user *)dst,
-			  ret, "w", "w", "ir", 2);
-		__uaccess_end();
-		return ret;
-	case 4:
-		__uaccess_begin();
-		__put_user_asm(*(u32 *)src, (u32 __user *)dst,
-			  ret, "l", "k", "ir", 4);
-		__uaccess_end();
-		return ret;
-	case 8:
-		__uaccess_begin();
-		__put_user_asm(*(u64 *)src, (u64 __user *)dst,
-			  ret, "q", "", "er", 8);
-		__uaccess_end();
-		return ret;
-	case 10:
-		__uaccess_begin();
-		__put_user_asm(*(u64 *)src, (u64 __user *)dst,
-			   ret, "q", "", "er", 10);
-		if (likely(!ret)) {
-			

[PATCH] staging: octeon: Remove typedef declaration

[Wambui Karuga]

Fixes checkpatch.pl warning: do not add new typedefs in
drivers/staging/octeon/octeon-stubs.h:41

Signed-off-by: Wambui Karuga 
---
 drivers/staging/octeon/octeon-stubs.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/octeon/octeon-stubs.h 
b/drivers/staging/octeon/octeon-stubs.h
index a4ac3bfb62a8..773591348ef4 100644
--- a/drivers/staging/octeon/octeon-stubs.h
+++ b/drivers/staging/octeon/octeon-stubs.h
@@ -38,7 +38,7 @@
 #define CVMX_NPI_RSL_INT_BLOCKS0
 #define CVMX_POW_WQ_INT_PC 0
 
-typedef union {
+union cvmx_pip_wqe_word2 {
uint64_t u64;
struct {
uint64_t bufs:8;
@@ -114,7 +114,7 @@ typedef union {
uint64_t err_code:8;
} snoip;
 
-} cvmx_pip_wqe_word2;
+};
 
 union cvmx_pip_wqe_word0 {
struct {
@@ -183,7 +183,7 @@ union cvmx_buf_ptr {
 typedef struct {
union cvmx_wqe_word0 word0;
union cvmx_wqe_word1 word1;
-   cvmx_pip_wqe_word2 word2;
+   union cvmx_pip_wqe_word2 word2;
union cvmx_buf_ptr packet_ptr;
uint8_t packet_data[96];
 } cvmx_wqe_t;
-- 
2.23.0

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Linus Torvalds]

On Mon, Oct 7, 2019 at 8:29 PM Al Viro  wrote:
>
> For x86?  Sure, why not...  Note, BTW, that for short constant-sized
> copies we *do* STAC/CLAC at the call site - see those
> __uaccess_begin_nospec();
> in raw_copy_{from,to}_user() in the switches...

Yeah, an that code almost never actually triggers in practice. The
code is pointless and dead.

The thing is, it's only ever used for the double undescore versions,
and the ones that do have have it are almost never constant sizes in
the first place.

And yes, there's like a couple of cases in the whole kernel.

Just remove those constant size cases. They are pointless and just
complicate our headers and slow down the compile for no good reason.

Try the attached patch, and then count the number of "rorx"
instructions in the kernel. Hint: not many. On my personal config,
this triggers 15 times in the whole kernel build (not counting
modules).

It's not worth it. The "speedup" from using __copy_{to,from}_user()
with the fancy inlining is negligible. All the cost is in the
STAC/CLAC anyway, the code might as well be deleted.

> 1) cross-architecture user_access_begin_dont_use(): on everything
> except x86 it's empty, on x86 - __uaccess_begin_nospec().

No, just do a proper range check, and use user_access_begin()

Stop trying to optimize that range check away. It's a couple of fast
instructions.

The only ones who don't want the range check are the actual kernel
copy ones, but they don't want the user_access_begin() either.

> void *copy_mount_options(const void __user * data)
> {
> unsigned offs, size;
> char *copy;
>
> if (!data)
> return NULL;
>
> copy = kmalloc(PAGE_SIZE, GFP_KERNEL);
> if (!copy)
> return ERR_PTR(-ENOMEM);
>
> offs = (unsigned long)untagged_addr(data) & (PAGE_SIZE - 1);
>
> if (copy_from_user(copy, data, PAGE_SIZE - offs)) {
> kfree(copy);
> return ERR_PTR(-EFAULT);
> }
> if (offs) {
> if (copy_from_user(copy, data + PAGE_SIZE - offs, offs))
> memset(copy + PAGE_SIZE - offs, 0, offs);
> }
> return copy;
> }
>
> on the theory that any fault halfway through a page means a race with
> munmap/mprotect/etc. and we can just pretend we'd lost the race entirely.
> And to hell with exact_copy_from_user(), byte-by-byte copying, etc.

Looks reasonable.

  Linus
diff --git a/arch/x86/include/asm/uaccess_64.h b/arch/x86/include/asm/uaccess_64.h
index 5cd1caa8bc65..db58c4436ce3 100644
--- a/arch/x86/include/asm/uaccess_64.h
+++ b/arch/x86/include/asm/uaccess_64.h
@@ -62,6 +62,8 @@ copy_to_user_mcsafe(void *to, const void *from, unsigned len)
 	return ret;
 }
 
+#define marker(x) asm volatile("rorx $" #x ",%rax,%rdx")
+
 static __always_inline __must_check unsigned long
 raw_copy_from_user(void *dst, const void __user *src, unsigned long size)
 {
@@ -72,30 +74,35 @@ raw_copy_from_user(void *dst, const void __user *src, unsigned long size)
 	switch (size) {
 	case 1:
 		__uaccess_begin_nospec();
+		marker(1);
 		__get_user_asm_nozero(*(u8 *)dst, (u8 __user *)src,
 			  ret, "b", "b", "=q", 1);
 		__uaccess_end();
 		return ret;
 	case 2:
 		__uaccess_begin_nospec();
+		marker(2);
 		__get_user_asm_nozero(*(u16 *)dst, (u16 __user *)src,
 			  ret, "w", "w", "=r", 2);
 		__uaccess_end();
 		return ret;
 	case 4:
 		__uaccess_begin_nospec();
+		marker(4);
 		__get_user_asm_nozero(*(u32 *)dst, (u32 __user *)src,
 			  ret, "l", "k", "=r", 4);
 		__uaccess_end();
 		return ret;
 	case 8:
 		__uaccess_begin_nospec();
+		marker(8);
 		__get_user_asm_nozero(*(u64 *)dst, (u64 __user *)src,
 			  ret, "q", "", "=r", 8);
 		__uaccess_end();
 		return ret;
 	case 10:
 		__uaccess_begin_nospec();
+		marker(10);
 		__get_user_asm_nozero(*(u64 *)dst, (u64 __user *)src,
 			   ret, "q", "", "=r", 10);
 		if (likely(!ret))
@@ -106,6 +113,7 @@ raw_copy_from_user(void *dst, const void __user *src, unsigned long size)
 		return ret;
 	case 16:
 		__uaccess_begin_nospec();
+		marker(16);
 		__get_user_asm_nozero(*(u64 *)dst, (u64 __user *)src,
 			   ret, "q", "", "=r", 16);
 		if (likely(!ret))
@@ -129,30 +137,35 @@ raw_copy_to_user(void __user *dst, const void *src, unsigned long size)
 	switch (size) {
 	case 1:
 		__uaccess_begin();
+		marker(51);
 		__put_user_asm(*(u8 *)src, (u8 __user *)dst,
 			  ret, "b", "b", "iq", 1);
 		__uaccess_end();
 		return ret;
 	case 2:
 		__uaccess_begin();
+		marker(52);
 		__put_user_asm(*(u16 *)src, (u16 __user *)dst,
 			  ret, "w", "w", "ir", 2);
 		__uaccess_end();
 		return ret;
 	case 4:
 		__uaccess_begin();
+		marker(54);
 		__put_user_asm(*(u32 *)src, (u32 __user *)dst,
 			  ret, "l", "k", "ir", 4);
 		__uaccess_end();
 		return ret;
 	case 8:
 		__uaccess_begin();
+		marker(58);
 		__put_user_asm(*(u64 *)src, (u64 __user *)dst,
 			  ret, "q", "", "er", 8);
 		

RE: [EXT] Re: [v2 2/2] arm64: dts: ls1028a: Update the DT node definition for dpclk

[Wen He]

> -Original Message-
> From: Shawn Guo 
> Sent: 2019年10月7日 20:35
> To: Wen He 
> Cc: linux-de...@linux.nxdi.nxp.com; Leo Li ; Rob Herring
> ; Mark Rutland ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org
> Subject: [EXT] Re: [v2 2/2] arm64: dts: ls1028a: Update the DT node definition
> for dpclk
> 
> 
> On Fri, Sep 20, 2019 at 04:34:19PM +0800, Wen He wrote:
> > Update DT node name clock-controller to clock-display,
> 
> The node name clock-controller is so good, and I do not understand why you
> need to change it.
> 

The node name clock-controller used for the system clockgen and this clock only 
used for
the Display core. 
To clearly the node, that why I have to use clock-display to instead of the 
clock-controller

Best Regards,
Wen

> Shawn
> 
> > also change
> > the property #clock-cells value to zero.
> >
> > This update according the feedback of the Display output interface
> > clock driver upstream.
> >
> > Link:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F1113832%2Fdata=02%7C01%
> 7Cwen.he
> >
> _1%40nxp.com%7C61934346fa6646d28bac08d74b22e08c%7C686ea1d3bc2b
> 4c6fa92c
> >
> d99c5c301635%7C0%7C0%7C637060485478218390sdata=%2FLG2KvA
> LdOGp6T06
> > 2fuKGQXYegswsEOWPAvzWnLkftM%3Dreserved=0
> > Signed-off-by: Wen He 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > index 51fa8f57fdac..db1e186352d8 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > @@ -79,10 +79,10 @@
> >   clock-output-names = "phy_27m";
> >   };
> >
> > - dpclk: clock-controller@f1f {
> > + dpclk: clock-display@f1f {
> >   compatible = "fsl,ls1028a-plldig";
> >   reg = <0x0 0xf1f 0x0 0x>;
> > - #clock-cells = <1>;
> > + #clock-cells = <0>;
> >   clocks = <_27m>;
> >   };
> >
> > @@ -665,7 +665,7 @@
> >   interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
> ><0 223 IRQ_TYPE_LEVEL_HIGH>;
> >   interrupt-names = "DE", "SE";
> > - clocks = < 0>, < 2 2>, < 2 2>,
> > + clocks = <>, < 2 2>, < 2 2>,
> >< 2 2>;
> >   clock-names = "pxlclk", "mclk", "aclk", "pclk";
> >   arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
> > --
> > 2.17.1
> >

linux-next: Tree for Oct 8

[Stephen Rothwell]

Hi all,

Changes since 20191004:

My fixes tree is empty again.

The hid tree lost its build failure.

The net-next tree gained a semantic conflict against the net tree.

The bpf-next tree gained a conflict against the bpf tree.

The drm-misc tree gained a semantic conflict against the v4l-dvb tree.

The sound-asoc tree gained a conflict against the sound tree.

The staging tree gained a build failure for which I disabled a driver.

The rtc tree lost its build failure.

The akpm tree gained a conflict against the hyperv tree.

Non-merge commits (relative to Linus' tree): 2654
 2974 files changed, 89779 insertions(+), 43880 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 314 trees (counting Linus' and 78 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (da0c9ea146cb Linux 5.4-rc2)
Merging fixes/master (54ecb8f7028c Linux 5.4-rc1)
Merging kbuild-current/fixes (da6221f246f9 scripts: setlocalversion: fix a 
bashism)
Merging arc-current/for-curr (41277ba7eb4e ARC: mm: tlb flush optim: elide 
redundant uTLB invalidates for MMUv3)
Merging arm-current/fixes (5b3efa4f1479 ARM: 8901/1: add a criteria for 
pfn_valid of arm)
Merging arm-soc-fixes/arm/fixes (60c1b3e25728 ARM: multi_v7_defconfig: Fix 
SPI_STM32_QSPI support)
Merging arm64-fixes/for-next/fixes (7c4791c9efca arm64: Kconfig: Make 
CONFIG_COMPAT_VDSO a proper Kconfig option)
Merging m68k-current/for-linus (0f1979b402df m68k: Remove ioremap_fullcache())
Merging powerpc-fixes/fixes (3439595d5b85 selftests/powerpc: Fix compile error 
on tlbie_test due to newer gcc)
Merging s390-fixes/fixes (da0c9ea146cb Linux 5.4-rc2)
Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (503c9addef61 ptp: fix typo of "mechanism" in Kconfig help 
text)
Merging bpf/master (98beb3edeb97 samples/bpf: Add a workaround for asm_inline)
Merging ipsec/master (68ce6688a5ba net: sched: taprio: Fix potential integer 
overflow in taprio_set_picos_per_byte)
Merging netfilter/master (2d00aee21a5d Merge tag 'kbuild-fixes-v5.4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging ipvs/master (34a4c95abd25 netfilter: nft_connlimit: disable bh on 
garbage collection)
Merging wireless-drivers/master (c91a9cfe9f6d rt2x00: initialize last_reset)
Merging mac80211/master (4ac2813cc867 cfg80211: wext: avoid copying malformed 
SSIDs)
Merging rdma-fixes/for-rc (0417791536ae RDMA/mlx5: Add missing 
synchronize_srcu() for MW cases)
Merging sound-current/for-linus (130bce3afbbb ALSA: hdac: clear link output 
stream mapping)
Merging sound-asoc-fixes/for-linus (46cf184eaf69 Merge branch 'asoc-5.4' into 
asoc-linus)
Merging regmap-fixes/for-linus (54ecb8f7028c Linux 5.4-rc1)
Merging regulator-fixes/for-linus (84d8ea8e109c Merge branch 'regulator-5.4' 
into regulator-linus)
Merging spi-fixes/for-linus (3ffe8dcc62ee Merge branch 'spi-5.4' into spi-linus)
Merging pci-current/for-linus (54ecb8f7028c Linux 5.4-rc1)
Merging driver-core.current/driver-core-linus (82af5b660967 sysfs: Fixes 
__BIN_ATTR_WO() macro)
Merging tty.current/tty-linus (fc64f7abbef2 serial: 8250_omap: Fix gpio check 
for auto RTS/CTS)
Merging usb.current/usb-linus (623170ff5971 usb:cdns3: Fix for CV CH9 running 

Re: [PATCH] cgroup, blkcg: prevent dirty inodes to pin dying memory cgroups

[Dave Chinner]

On Fri, Oct 04, 2019 at 03:11:04PM -0700, Roman Gushchin wrote:
> This is a RFC patch, which is not intended to be merged as is,
> but hopefully will start a discussion which can result in a good
> solution for the described problem.
> 
> --
> 
> We've noticed that the number of dying cgroups on our production hosts
> tends to grow with the uptime. This time it's caused by the writeback
> code.
> 
> An inode which is getting dirty for the first time is associated
> with the wb structure (look at __inode_attach_wb()). It can later
> be switched to another wb under some conditions (e.g. some other
> cgroup is writing a lot of data to the same inode), but generally
> stays associated up to the end of life of the inode structure.
> 
> The problem is that the wb structure holds a reference to the original
> memory cgroup. So if the inode was dirty once, it has a good chance
> to pin down the original memory cgroup.
> 
> An example from the real life: some service runs periodically and
> updates rpm packages. Each time in a new memory cgroup. Installed
> .so files are heavily used by other cgroups, so corresponding inodes
> tend to stay alive for a long. So do pinned memory cgroups.
> In production I've seen many hosts with 1-2 thousands of dying
> cgroups.
> 
> This is not the first problem with the dying memory cgroups. As
> always, the problem is with their relative size: memory cgroups
> are large objects, easily 100x-1000x larger that inodes. So keeping
> a couple of thousands of dying cgroups in memory without a good reason
> (what we easily do with inodes) is quite costly (and is measured
> in tens and hundreds of Mb).
> 
> One possible approach to this problem is to switch inodes associated
> with dying wbs to the root wb. Switching is a best effort operation
> which can fail silently, so unfortunately we can't run once over a
> list of associated inodes (even if we'd have such a list). So we
> really have to scan all inodes.
> 
> In the proposed patch I schedule a work on each memory cgroup
> deletion, which is probably too often. Alternatively, we can do it
> periodically under some conditions (e.g. the number of dying memory
> cgroups is larger than X). So it's basically a gc run.
> 
> I wonder if there are any better ideas?
> 
> Signed-off-by: Roman Gushchin 
> ---
>  fs/fs-writeback.c | 29 +
>  mm/memcontrol.c   |  5 +
>  2 files changed, 34 insertions(+)
> 
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index 542b02d170f8..4bbc9a200b2c 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -545,6 +545,35 @@ static void inode_switch_wbs(struct inode *inode, int 
> new_wb_id)
>   up_read(>wb_switch_rwsem);
>  }
>  
> +static void reparent_dirty_inodes_one_sb(struct super_block *sb, void *arg)
> +{
> + struct inode *inode, *next;
> +
> + spin_lock(>s_inode_list_lock);
> + list_for_each_entry_safe(inode, next, >s_inodes, i_sb_list) {
> + spin_lock(>i_lock);
> + if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE)) {
> + spin_unlock(>i_lock);
> + continue;
> + }
> +
> + if (inode->i_wb && wb_dying(inode->i_wb)) {
> + spin_unlock(>i_lock);
> + inode_switch_wbs(inode, root_mem_cgroup->css.id);
> + continue;
> + }
> +
> + spin_unlock(>i_lock);
> + }
> + spin_unlock(>s_inode_list_lock);

No idea what the best solution is, but I think this is fundamentally
unworkable. It's not uncommon to have a hundred million cached
inodes these days, often on a single filesystem. Anything that
requires a brute-force system wide inode scan, especially without
conditional reschedule points, is largely a non-starter.

Also, inode_switch_wbs() is not guaranteed to move the inode to the
destination wb.  There can only be WB_FRN_MAX_IN_FLIGHT (1024)
switches in flight at once and switches are run via RCU callbacks,
so I suspect that using inode_switch_wbs() for bulk re-assignment is
going to be a lot more complex than just finding inodes to call
inode_switch_wbs() on

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH v22 07/24] x86/sgx: Add wrappers for ENCLS leaf functions

[Sean Christopherson]

On Fri, Oct 04, 2019 at 11:45:13AM +0200, Borislav Petkov wrote:
> On Tue, Sep 03, 2019 at 05:26:38PM +0300, Jarkko Sakkinen wrote:
> > +/**
> > + * ENCLS_FAULT_FLAG - flag signifying an ENCLS return code is a trapnr
> > + *
> > + * ENCLS has its own (positive value) error codes and also generates
> > + * ENCLS specific #GP and #PF faults.  And the ENCLS values get munged
> > + * with system error codes as everything percolates back up the stack.
> > + * Unfortunately (for us), we need to precisely identify each unique
> > + * error code, e.g. the action taken if EWB fails varies based on the
> > + * type of fault and on the exact SGX error code, i.e. we can't simply
> > + * convert all faults to -EFAULT.
> > + *
> > + * To make all three error types coexist, we set bit 30 to identify an
> > + * ENCLS fault.  Bit 31 (technically bits N:31) is used to differentiate
> > + * between positive (faults and SGX error codes) and negative (system
> > + * error codes) values.
> > + */
> > +#define ENCLS_FAULT_FLAG 0x4000
> 
> BIT(30)

This is intentionally open coded so that it can be stringified in asm.
Alternatively, the asm could use the raw value or a different define.  Is
there a third option?

#define __encls_ret_N(rax, inputs...)   \
({  \
int ret;\
asm volatile(   \
"1: .byte 0x0f, 0x01, 0xcf;\n\t"\
"2:\n"  \
".section .fixup,\"ax\"\n"  \
"3: orl $"__stringify(ENCLS_FAULT_FLAG)",%%eax\n"   \  <
"   jmp 2b\n"   \
".previous\n"   \
_ASM_EXTABLE_FAULT(1b, 3b)  \
: "=a"(ret) \
: "a"(rax), inputs  \
: "memory", "cc");  \
ret;\
})

checkpatch error

[Zhenzhong Duan]

Hi,

When I run checkpatch.pl with a patch doing reverting operation, it 
reports a false positive error, Should I ignore the error or it's a bug?


0001-Revert-KVM-X86-Fix-setup-the-virt_spin_lock_key-befo.patch
---
ERROR: Please use git commit description style 'commit <12+ chars of 
sha1> ("")' - ie: 'commit 090d54bcbc54 ("Revert 
"x86/paravirt: Set up the v'

#14:
The similar change for XEN is in commit 090d54bcbc54 ("Revert

total: 1 errors, 0 warnings, 31 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or 
--fix-inplace.



# cat 0001-Revert-KVM-X86-Fix-setup-the-virt_spin_lock_key-befo.patch
From 5d90690ba0476cab223f5e1d13955858b9c91623 Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan 
Date: Mon, 7 Oct 2019 09:20:58 +0800
Subject: [PATCH v5 1/5] Revert "KVM: X86: Fix setup the virt_spin_lock_key
 before static key get initialized"

This reverts commit 34226b6b70980a8f81fff3c09a2c889f77edeeff.

Commit 8990cac6e5ea ("x86/jump_label: Initialize static branching
early") adds jump_label_init() call in setup_arch() to make static
keys initialized early, so we could use the original simpler code
again.

The similar change for XEN is in commit 090d54bcbc54 ("Revert
"x86/paravirt: Set up the virt_spin_lock_key after static keys get
initialized"")
...


Thanks

Zhenzhong

Re: [linux-sunxi] [PATCH] bus: sunxi-rsb: Make interrupt handling more robust

[Samuel Holland]

On 10/7/19 10:19 AM, Chen-Yu Tsai wrote:
> On Sun, Aug 25, 2019 at 1:50 AM Samuel Holland  wrote:
>>
>> The RSB controller has two registers for controlling interrupt inputs:
>> RSB_INTE, which has bits for each possible interrupt, and the global
>> interrupt enable bit in RSB_CTRL.
>>
>> Currently, we enable the bits in RSB_INTE before each transfer, but this
>> is unnecessary because we never disable them. Move the initialization of
>> RSB_INTE so it is done only once.
>>
>> We also set the global interrupt enable bit before each transfer. Unlike
>> other bits in RSB_CTRL, this bit is cleared by writing a zero. Thus, we
>> clear the bit in the post-timeout cleanup code, so note that in the
>> comment.
>>
>> However, if we do receive an interrupt, we do not clear the bit. Nor do
>> we clear interrupt statuses before starting a transfer. Thus, if some
>> other driver uses the RSB bus while Linux is suspended (as both Trusted
>> Firmware and SCP firmware do to control the PMIC), we receive spurious
>> interrupts upon resume. This causes false completion of a transfer, and
>> the next transfer starts prematurely, causing a LOAD_BSY condition. The
>> end result is that some transfers at resume fail with -EBUSY.
> 
> If we are expecting the hardware to not be in the state we assume to be
> or left it in, then maybe we should also keep setting the interrupt enable
> bits on each transfer?
> 
> Surely we expect to have exclusive use of the controller most of the time.
> If it's to handle suspend/resume, shouldn't we be adding power management
> callbacks instead? That would reset the controller to a known state when
> the system comes out of suspend, including clearing any pending interrupts.

Yes, this change is only to handle suspend/resume. You're right, that's a better
way to do it. I'll develop a patch using device power management callbacks.

Samuel

> Maxime, anything you want to add? (BTW, Maxime switched email addresses.)
> 
> ChenYu
> 
>> With this patch, all transfers reliably succeed during/after resume.
>>
>> Signed-off-by: Samuel Holland 
>> ---
>>  drivers/bus/sunxi-rsb.c | 10 --
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
>> index be79d6c6a4e4..b8043b58568a 100644
>> --- a/drivers/bus/sunxi-rsb.c
>> +++ b/drivers/bus/sunxi-rsb.c
>> @@ -274,7 +274,7 @@ static int _sunxi_rsb_run_xfer(struct sunxi_rsb *rsb)
>> reinit_completion(>complete);
>>
>> writel(RSB_INTS_LOAD_BSY | RSB_INTS_TRANS_ERR | RSB_INTS_TRANS_OVER,
>> -  rsb->regs + RSB_INTE);
>> +  rsb->regs + RSB_INTS);
>> writel(RSB_CTRL_START_TRANS | RSB_CTRL_GLOBAL_INT_ENB,
>>rsb->regs + RSB_CTRL);
>>
>> @@ -282,7 +282,7 @@ static int _sunxi_rsb_run_xfer(struct sunxi_rsb *rsb)
>> msecs_to_jiffies(100))) {
>> dev_dbg(rsb->dev, "RSB timeout\n");
>>
>> -   /* abort the transfer */
>> +   /* abort the transfer and disable interrupts */
>> writel(RSB_CTRL_ABORT_TRANS, rsb->regs + RSB_CTRL);
>>
>> /* clear any interrupt flags */
>> @@ -480,6 +480,9 @@ static irqreturn_t sunxi_rsb_irq(int irq, void *dev_id)
>> status = readl(rsb->regs + RSB_INTS);
>> rsb->status = status;
>>
>> +   /* Disable any further interrupts */
>> +   writel(0, rsb->regs + RSB_CTRL);
>> +
>> /* Clear interrupts */
>> status &= (RSB_INTS_LOAD_BSY | RSB_INTS_TRANS_ERR |
>>RSB_INTS_TRANS_OVER);
>> @@ -718,6 +721,9 @@ static int sunxi_rsb_probe(struct platform_device *pdev)
>> goto err_reset_assert;
>> }
>>
>> +   writel(RSB_INTS_LOAD_BSY | RSB_INTS_TRANS_ERR | RSB_INTS_TRANS_OVER,
>> +  rsb->regs + RSB_INTE);
>> +
>> /* initialize all devices on the bus into RSB mode */
>> ret = sunxi_rsb_init_device_mode(rsb);
>> if (ret)
>> --
>> 2.21.0
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to linux-sunxi+unsubscr...@googlegroups.com.
>> To view this discussion on the web, visit 
>> https://groups.google.com/d/msgid/linux-sunxi/20190824175013.28840-1-samuel%40sholland.org.

Re: [PATCH 02/15] fs: Introduce i_blocks_per_page

[Dave Chinner]

On Fri, Oct 04, 2019 at 12:28:12PM -0700, Matthew Wilcox wrote:
> On Wed, Sep 25, 2019 at 06:36:50PM +1000, Dave Chinner wrote:
> > I'm actually working on abstrcting this code from both block size
> > and page size via the helpers below. We ahve need to support block
> > size > page size, and so that requires touching a bunch of all the
> > same code as this patchset. I'm currently trying to combine your
> > last patch set with my patchset so I can easily test allocating 64k
> > page cache pages on a 64k block size filesystem on a 4k page size
> > machine with XFS
> 
> This all makes sense ...
> 
> > > - if (iop || i_blocksize(inode) == PAGE_SIZE)
> > > + if (iop || i_blocks_per_page(inode, page) <= 1)
> > >   return iop;
> > 
> > That also means checks like these become:
> > 
> > if (iop || iomap_chunks_per_page(inode, page) <= 1)
> > 
> > as a single file can now have multiple pages per block, a page per
> > block and multiple blocks per page as the page size changes...
> > 
> > I'd like to only have to make one pass over this code to abstract
> > out page and block sizes, so I'm guessing we'll need to do some
> > co-ordination here
> 
> Yup.  I'm happy if you want to send your patches out; I'll keep going
> with the patches I have for the moment, and we'll figure out how to
> merge the two series in a way that makes sense.

I'm waiting for the xfs -> iomap writeback changes to land in a
stable branch so I don't have to do things twice in slightly
different ways in the patchset. Once we get that in an iomap-next
branch I'll rebase my patches on top of it and go from there...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

[PATCH] PCI/MSI: Fix restoring of MSI-X vector control's mask bit

[Jian-Hong Pan]

MSI-X vector control's bit 0 is the mask bit, which masks the
corresponding interrupt request, or not. Other reserved bits might be
used for other purpose by device vendors. For example, the values of
Kingston NVMe SSD's MSI-X vector control are neither 0, nor 1, but other
values [1].

The original restoring logic in system resuming uses the whole MSI-X
vector control value as the flag to set/clear the mask bit. However,
this logic conflicts the idea mentioned above. It may mislead system to
disable the MSI-X vector entries. That makes system get no interrupt
from Kingston NVMe SSD after resume and usually get NVMe I/O timeout
error.

[  174.715534] nvme nvme0: I/O 978 QID 3 timeout, completion polled

This patch takes only the mask bit of original MSI-X vector control
value as the flag to fix this issue.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=204887#c8

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204887
Fixed: f2440d9acbe8 ("PCI MSI: Refactor interrupt masking code")
Signed-off-by: Jian-Hong Pan 
---
 drivers/pci/msi.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 0884bedcfc7a..deae3d5acaf6 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -433,6 +433,7 @@ static void __pci_restore_msi_state(struct pci_dev *dev)
 static void __pci_restore_msix_state(struct pci_dev *dev)
 {
struct msi_desc *entry;
+   u32 flag;
 
if (!dev->msix_enabled)
return;
@@ -444,8 +445,10 @@ static void __pci_restore_msix_state(struct pci_dev *dev)
PCI_MSIX_FLAGS_ENABLE | PCI_MSIX_FLAGS_MASKALL);
 
arch_restore_msi_irqs(dev);
-   for_each_pci_msi_entry(entry, dev)
-   msix_mask_irq(entry, entry->masked);
+   for_each_pci_msi_entry(entry, dev) {
+   flag = entry->masked & PCI_MSIX_ENTRY_CTRL_MASKBIT;
+   msix_mask_irq(entry, flag);
+   }
 
pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0);
 }
-- 
2.23.0

linux-next: manual merge of the akpm tree with the hyperv tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm tree got a conflict in:

  lib/Kconfig.debug

between commit:

  54dc8d00a0be ("drivers: hv: vmbus: Introduce latency testing")

from the hyperv tree and patch:

  "kernel-hacking: create submenu for arch special debugging options"

from the akpm 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 lib/Kconfig.debug
index 905ce80e6ac4,9a6d7e4955a5..
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@@ -2156,13 -2156,10 +2156,17 @@@ config DEBUG_AID_FOR_SYZBO
 help
   This option is intended for testing by syzbot.
  
+ menu "$(SRCARCH) Debugging"
+ 
  source "arch/$(SRCARCH)/Kconfig.debug"
  
+ endmenu
+ 
 +config HYPERV_TESTING
 +  bool "Microsoft Hyper-V driver testing"
 +  default n
 +  depends on HYPERV && DEBUG_FS
 +  help
 +Select this option to enable Hyper-V vmbus testing.
 +
  endmenu # Kernel hacking


pgpneMMUy91_I.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 for 5.4 3/4] media: hantro: Fix motion vectors usage condition

[Tomasz Figa]

Hi Jonas,

On Tue, Oct 8, 2019 at 3:33 AM Jonas Karlman  wrote:
>
> On 2019-10-07 19:45, Ezequiel Garcia wrote:
> > From: Francois Buergisser 
> >
> > The setting of the motion vectors usage and the setting of motion
> > vectors address are currently done under different conditions.
> >
> > When decoding pre-recorded videos, this results of leaving the motion
> > vectors address unset, resulting in faulty memory accesses. Fix it
> > by using the same condition everywhere, which matches the profiles
> > that support motion vectors.
>
> This does not fully match hantro sdk:
>
>   enable direct MV writing and POC tables for high/main streams.
>   enable it also for any "baseline" stream which have main/high tools enabled.
>
>   (sps->profile_idc > 66 && sps->constrained_set0_flag == 0) ||
>   sps->frame_mbs_only_flag != 1 ||
>   sps->chroma_format_idc != 1 ||
>   sps->scaling_matrix_present_flag != 0 ||
>   pps->entropy_coding_mode_flag != 0 ||
>   pps->weighted_pred_flag != 0 ||
>   pps->weighted_bi_pred_idc != 0 ||
>   pps->transform8x8_flag != 0 ||
>   pps->scaling_matrix_present_flag != 0

Thanks for double checking this. I can confirm that it's what Hantro
SDK does indeed.

However, would a stream with sps->profile_idc <= 66 and those other
conditions met be still a compliant stream?

>
> Above check is used when DIR_MV_BASE should be written.
> And WRITE_MVS_E is set to nal_ref_idc != 0 when above is true.
>
> I think it may be safer to always set DIR_MV_BASE and keep the existing 
> nal_ref_idc check for WRITE_MVS_E.

That might have a performance penalty or some other side effects,
though. Otherwise Hantro SDK wouldn't have enable it conditionally.

> (That is what I did in my "media: hantro: H264 fixes and improvements" 
> series, v2 is incoming)
> Or have you found any video that is having issues in such case?

We've been running the code with sps->profile_idc > 66 in production
for 4 years and haven't seen any reports of a stream that wasn't
decoded correctly.

If we decide to go with a different behavior, I'd suggest thoroughly
verifying the behavior on a big number of streams, including some
performance measurements.

Best regards,
Tomasz

>
> Regards,
> Jonas
>
> >
> > Fixes: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1")
> > Signed-off-by: Francois Buergisser 
> > Signed-off-by: Ezequiel Garcia 
> > ---
> > v2:
> > * New patch.
> >
> >  drivers/staging/media/hantro/hantro_g1_h264_dec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c 
> > b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
> > index 7ab534936843..c92460407613 100644
> > --- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
> > +++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
> > @@ -35,7 +35,7 @@ static void set_params(struct hantro_ctx *ctx)
> >   if (sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD)
> >   reg |= G1_REG_DEC_CTRL0_SEQ_MBAFF_E;
> >   reg |= G1_REG_DEC_CTRL0_PICORD_COUNT_E;
> > - if (dec_param->nal_ref_idc)
> > + if (sps->profile_idc > 66)
> >   reg |= G1_REG_DEC_CTRL0_WRITE_MVS_E;
> >
> >   if (!(sps->flags & V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY) &&
>

Re: [PATCH] lib/list-test: add a test for the 'list' doubly linked list

[Kees Cook]

On Mon, Oct 07, 2019 at 02:36:33PM -0700, David Gow wrote:
> +config LIST_TEST
> + bool "KUnit Test for Kernel Linked-list stuctures"

I missed this the first time through: typo of "structures"

-- 
Kees Cook

Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()

[Al Viro]

On Mon, Oct 07, 2019 at 11:26:35AM -0700, Linus Torvalds wrote:

> But on x86, if we move the STAC/CLAC out of the low-level copy
> routines and into the callers, we'll have a _lot_ of churn. I thought
> it would be mostly a "teach objtool" thing, but we have lots of
> different versions of it. Not just the 32-bit vs 64-bit, it's embedded
> in all the low-level asm implementations.
> 
> And we don't want the regular "copy_to/from_user()" to then have to
> add the STAC/CLAC at the call-site. So then we'd want to un-inline
> copy_to_user() entirely.

For x86?  Sure, why not...  Note, BTW, that for short constant-sized
copies we *do* STAC/CLAC at the call site - see those
__uaccess_begin_nospec();
in raw_copy_{from,to}_user() in the switches...

> Which all sounds like a really good idea, don't get me wrong. I think
> we inline it way too aggressively now. But it'sa  _big_ job.
> 
> So we probably _should_
> 
>  - remove INLINE_COPY_TO/FROM_USER
> 
>  - remove all the "small constant size special cases".
> 
>  - make "raw_copy_to/from_user()" have the "unsafe" semantics and make
> the out-of-line copy in lib/usercopy.c be the only real interface
> 
>  - get rid of a _lot_ of oddities

Not that many, really.  All we need is a temporary cross-architecture
__uaccess_begin_nospec(), so that __copy_{to,from}_user() could have
that used, instead of having it done in (x86) raw_copy_..._...().

Other callers of raw_copy_...() would simply wrap it into user_access_begin()/
user_access_end() pairs; this kludge is needed only in __copy_from_user()
and __copy_to_user(), and only until we kill their callers outside of
arch/*.  Which we can do, in a cycle or two.  _ANY_ use of
that temporary kludge outside of those two functions will be grepped
for and LARTed into the ground.

> I hope you prove me wrong. But I'll look at a smaller change to just
> make x86 use the current special copy loop (as
> "unsafe_copy_to_user()") and have everybody else do the trivial
> wrapper.
> 
> Because we definitely should do that cleanup (it also fixes the whole
> "atomic copy in kernel space" issue that you pointed to that doesn't
> actually want STAC/CLAC at all), but it just looks fairly massive to
> me.

AFAICS, it splits nicely.

1) cross-architecture user_access_begin_dont_use(): on everything
except x86 it's empty, on x86 - __uaccess_begin_nospec().

2) stac/clac lifted into x86 raw_copy_..._user() out of
copy_user_generic_unrolled(), copy_user_generic_string() and
copy_user_enhanced_fast_string().  Similar lift out of
__copy_user_nocache().

3) lifting that thing as user_access_begin_dont_use() into
__copy_..._user...() and as user_access_begin() into other
generic callers, consuming access_ok() in the latter.
__copy_to_user_inatomic() can die at the same stage.

4) possibly uninlining on x86 (and yes, killing the special
size handling off).  We don't need to touch the inlining
decisions for any other architectures.

At that point raw_copy_to_user() is available for e.g.
readdir.c to play with.

And up to that point only x86 sees any kind of code changes,
so we don't have to worry about other architectures.

5) kill the __copy_...() users outside of arch/*, alone with
quite a few other weird shits in there.  A cycle or two,
with the final goal being to kill the damn things off.

6) arch/* users get arch-by-arch treatment - mostly
it's sigframe handling.  Won't affect the generic code
and would be independent for different architectures.
Can happen in parallel with (5), actually.

7) ... at that point user_access_begin_dont_user() gets
removed and thrown into the pile of mangled fingers of
those who'd ignored all warnings and used it somewhere
else.

I don't believe that (5) would be doable entirely in
this cycle, but quite a few bits might be.

On a somewhat related note, do you see any problems with

void *copy_mount_options(const void __user * data)
{
unsigned offs, size;
char *copy;

if (!data)
return NULL;

copy = kmalloc(PAGE_SIZE, GFP_KERNEL);
if (!copy)
return ERR_PTR(-ENOMEM);

offs = (unsigned long)untagged_addr(data) & (PAGE_SIZE - 1);

if (copy_from_user(copy, data, PAGE_SIZE - offs)) {
kfree(copy);
return ERR_PTR(-EFAULT);
}
if (offs) {
if (copy_from_user(copy, data + PAGE_SIZE - offs, offs))
memset(copy + PAGE_SIZE - offs, 0, offs);
}
return copy;
}

on the theory that any fault halfway through a page means a race with
munmap/mprotect/etc. and we can just pretend we'd lost the race entirely.
And to hell with exact_copy_from_user(), byte-by-byte copying, etc.

Re: [RFC PATCH v1 2/3] usb: chipidea: set mode for usb phy driver

[Peter Chen]

On 19-10-07 15:46:06, Igor Opaniuk wrote:
> From: Igor Opaniuk 
> 
> After enters one specific role, notify usb phy driver.
> 
> Signed-off-by: Li Jun 
> Signed-off-by: Igor Opaniuk 
> ---
> 
>  drivers/usb/chipidea/ci.h | 21 ++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 6911aef500e9..a11d23910b12 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -275,9 +275,21 @@ static inline int ci_role_start(struct ci_hdrc *ci, enum 
> ci_role role)
>   return -ENXIO;
>  
>   ret = ci->roles[role]->start(ci);
> - if (!ret)
> - ci->role = role;
> - return ret;
> + if (ret)
> + return ret;
> +
> + ci->role = role;
> +
> + if (ci->usb_phy) {
> + if (role == CI_ROLE_HOST)
> + usb_phy_set_mode(ci->usb_phy,
> + USB_MODE_HOST);
> + else
> + usb_phy_set_mode(ci->usb_phy,
> + USB_MODE_DEVICE);
> + }
> +
> + return 0;
>  }
>  
>  static inline void ci_role_stop(struct ci_hdrc *ci)
> @@ -290,6 +302,9 @@ static inline void ci_role_stop(struct ci_hdrc *ci)
>   ci->role = CI_ROLE_END;
>  
>   ci->roles[role]->stop(ci);
> +
> + if (ci->usb_phy)
> + usb_phy_set_mode(ci->usb_phy, USB_MODE_NONE);
>  }
>  
>  static inline enum usb_role ci_role_to_usb_role(struct ci_hdrc *ci)
> -- 

Hi Igor,

Thanks for doing that.

We just find this series patch will break ARM32 multi_v7_defconfig
build. You may need to fix it at next revision, see below.

  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm200.o
In file included from 
/home/b29397/work/projects/usb/drivers/phy/ti/phy-omap-usb2.c:20:0:
/home/b29397/work/projects/usb/include/linux/phy/omap_control_phy.h:36:2: 
error: redeclaration of enumerator ‘USB_MODE_HOST’
  USB_MODE_HOST,
  ^
In file included from 
/home/b29397/work/projects/usb/include/linux/usb/otg.h:14:0,
 from 
/home/b29397/work/projects/usb/include/linux/phy/omap_usb.h:13,
 from 
/home/b29397/work/projects/usb/drivers/phy/ti/phy-omap-usb2.c:14:
/home/b29397/work/projects/usb/include/linux/usb/phy.h:69:2: note: previous 
definition of ‘USB_MODE_HOST’ was here
  USB_MODE_HOST,
  ^
In file included from 
/home/b29397/work/projects/usb/drivers/phy/ti/phy-omap-usb2.c:20:0:
/home/b29397/work/projects/usb/include/linux/phy/omap_control_phy.h:37:2: 
error: redeclaration of enumerator ‘USB_MODE_DEVICE’
  USB_MODE_DEVICE,
  ^~~
In file included from 
/home/b29397/work/projects/usb/include/linux/usb/otg.h:14:0,
 from 
/home/b29397/work/projects/usb/include/linux/phy/omap_usb.h:13,
 from 
/home/b29397/work/projects/usb/drivers/phy/ti/phy-omap-usb2.c:14:
/home/b29397/work/projects/usb/include/linux/usb/phy.h:70:2: note: previous 
definition of ‘USB_MODE_DEVICE’ was here
  USB_MODE_DEVICE,
  ^~~
/home/b29397/work/projects/usb/scripts/Makefile.build:280: recipe for target 
'drivers/phy/ti/phy-omap-usb2.o' failed
make[4]: *** [drivers/phy/ti/phy-omap-usb2.o] Error 1
make[4]: *** Waiting for unfinished jobs
  CC  drivers/pinctrl/qcom/pinctrl-ssbi-gpio.o
  CC  drivers/regulator/bcm590xx-regulator.o
  CC  drivers/pinctrl/qcom/pinctrl-spmi-mpp.o
  CC  drivers/pinctrl/qcom/pinctrl-ssbi-mpp.o
  CC  drivers/rpmsg/imx_rpmsg.o
  CC [M]  drivers/rpmsg/rpmsg_core.o
  CC  drivers/regulator/da9210-regulator.o
  CC  drivers/gpu/drm/drm_crtc_helper.o
  CC  drivers/pinctrl/samsung/pinctrl-exynos.o
  CC  drivers/gpu/drm/drm_dp_helper.o
/home/b29397/work/projects/usb/scripts/Makefile.build:497: recipe for target 
'drivers/phy/ti' failed
make[3]: *** [drivers/phy/ti] Error 2

-- 

Thanks,
Peter Chen

Re: [PATCH 1/6] arm64: dts: rockchip: Fix rk3399-roc-pc pwm2 pin

[djw]

Jagan Teki  writes:

> Hi Heiko,
>
> On Mon, Sep 30, 2019 at 2:51 AM Heiko Stuebner  wrote:
>>
>> Hi Jagan,
>>
>> Am Donnerstag, 19. September 2019, 07:28:17 CEST schrieb Jagan Teki:
>> > ROC-PC is not able to boot linux console if PWM2_d is
>> > unattached to any pinctrl logic.
>> >
>> > To be precise the linux boot hang with last logs as,
>> > ...
>> > .
>> > [0.003367] Console: colour dummy device 80x25
>> > [0.003788] printk: console [tty0] enabled
>> > [0.004178] printk: bootconsole [uart8250] disabled
>> >
>> > In ROC-PC the PWM2_d pin is connected to LOG_DVS_PWM of
>> > VDD_LOG. So, for normal working operations this needs to
>> > active and pull-down.
>> >
>> > This patch fix, by attaching pinctrl active and pull-down
>> > the pwm2.
>>
>> This looks highly dubious on first glance. The pwm subsystem nor
>> the Rockchip pwm driver do not do any pinctrl handling.
>>
>> So I don't really see where that "active" pinctrl state is supposed
>> to come from.
>>
>> Comparing with the pwm driver in the vendor tree I see that there
>> is such a state defined there. But that code there also looks strange
>> as that driver never again leaves this active state after entering it.
>>
>> Also for example all the Gru devices run with quite a number of pwm-
>> regulators without needing additional fiddling with the pwm itself, so
>> I don't really see why that should be different here.
>
> I deed, I was supposed to think the same. but the vendor kernel dts
> from firefly do follow the pwm2 pinctrl [1]. I wouldn't find any
> information other than this vensor information, ie one of the reason I
> have marked "Levin Du" who initially supported this board.
>
> One, think I have seen was this pinctrl active fixed the boot hang.
> any inputs from would be very helpful.
>
> Levin Du, any inputs?
>
> [1] 
> https://github.com/FireflyTeam/kernel/blob/stable-4.4-rk3399-linux/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi#L1184
>

A grep of the `pwm2` shows that there's such block in rk3399-nanopi4.dtsi:

 {
pinctrl-names = "active";
pinctrl-0 = <_pin_pull_down>;
status = "okay";
};

But last time I checked, using the mainline U-Boot (the roc-rk3399-pc is
in mainline now) with mainline linux v5.2-rc7, no such setting is
necessary, and the board boots happily.

I cannot find the use of "active" pinctrl state in the
`drivers/pwm/pwm-rockchip.c`. If the pinctrl state needs to be setup as
default, the `pinctrl-names` needs to be "default" or "init" (see
`drivers/base/pinctrl.c`) .

Jagan, what version of board do you use? I checked with
"ROC-RK3399-PC-V1.0-A 2018-07-12". 

Thanks

--
Levin Du

Re: [linux-sunxi] [PATCH 2/2] power: supply: axp20x_usb_power: add applied max Vbus support for AXP813

[Chen-Yu Tsai]

On Tue, Oct 8, 2019 at 11:09 AM Icenowy Zheng  wrote:
> 于 2019年10月8日 GMT+08:00 上午12:07:05, Chen-Yu Tsai  写到:
> >Hi,
> >
> >On Wed, Oct 2, 2019 at 7:27 PM Icenowy Zheng  wrote:
> >>
> >> AXP813 PMIC has two Vbus maximum value settings -- one is the default
> >> value, which is currently the only supported one; the other is the
> >> really applied value, which is set according to the default value if
> >the
> >> BC detection module detected a charging port, or 500mA if no charging
> >> port is detected.
> >>
> >> Add support for reading and writing of the really applied Vbus
> >maxmium
> >> value. Interestingly it has a larger range than the default value.
> >>
> >> Signed-off-by: Icenowy Zheng 
> >> ---
> >>  drivers/power/supply/axp20x_usb_power.c | 132
> >+++-
> >>  1 file changed, 129 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/power/supply/axp20x_usb_power.c
> >b/drivers/power/supply/axp20x_usb_power.c
> >> index 5f0a5722b19e..905668a2727f 100644
> >> --- a/drivers/power/supply/axp20x_usb_power.c
> >> +++ b/drivers/power/supply/axp20x_usb_power.c
> >
> >[...]
> >
> >> @@ -354,6 +451,9 @@ static int axp20x_usb_power_set_property(struct
> >power_supply *psy,
> >>
> >val->intval);
> >> return axp20x_usb_power_set_current_max(power,
> >val->intval);
> >>
> >> +   case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
> >> +   return
> >axp20x_usb_power_set_input_current_limit(power, val->intval);
> >> +
> >
> >So I think there are two things that should be adjusted.
> >
> >First, we should be using POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT for all
> >PMICs.
> >As far as the sysfs documents go, CURRENT_MAX is read-only, and should
> >refer to
> >the hard limit the hardware can support, i.e. maximum power ratings.
> >INPUT_CURRENT_LIMIT and INPUT_VOLTAGE_LIMIT are for configurable upper
> >and lower
> >limits respectively.
> >
> >Sebastian, is my understanding of this correct?
> >
> >We already use INPUT_CURRENT_LIMIT for the AXP813 in the axp20x-ac
> >driver, and
> >it would be nice to have both drivers expose the same attributes.
> >
> >Second, since the value set in register 0x35 is the one that actually
> >has an
> >effect, as opposed to just being a default, we should just use that
> >one.
>
> However, that default value is also important, otherwise users will
> get dropped back to 500mAh each time they re-insert USB jack.
>
> Is there a property to export the default value?

Not that I know of. I suppose you could piggy back on INPUT_CURRENT_LIMIT
and just set both values at the same time. Of course the default value
has a smaller range, so you would end up setting the highest value for
actual values above its range.

> BTW, if possible, apply patch 1 first, because it can raise current to 1.5A
> in the default situation.

Agreed.

ChenYu

> >Could you restructure the series based on what I described, with a new
> >patch 1
> >switching from CURRENT_MAX to INPUT_CURRENT_LIMIT, and then this patch
> >as patch 2?
> >And both patches should have Fixes tags and possibly CC stable so they
> >get backported
> >for people that are using stable kernels? And then the original patch
> >2 as patch 3.
> >
> >ChenYu
> >
> >> default:
> >> return -EINVAL;
> >> }
> >> @@ -365,7 +465,8 @@ static int axp20x_usb_power_prop_writeable(struct
> >power_supply *psy,
> >>enum power_supply_property
> >psp)
> >>  {
> >> return psp == POWER_SUPPLY_PROP_VOLTAGE_MIN ||
> >> -  psp == POWER_SUPPLY_PROP_CURRENT_MAX;
> >> +  psp == POWER_SUPPLY_PROP_CURRENT_MAX ||
> >> +  psp == POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT;
> >>  }
> >>
> >>  static enum power_supply_property axp20x_usb_power_properties[] = {
> >> @@ -386,6 +487,15 @@ static enum power_supply_property
> >axp22x_usb_power_properties[] = {
> >> POWER_SUPPLY_PROP_CURRENT_MAX,
> >>  };
> >>
> >> +static enum power_supply_property axp813_usb_power_properties[] = {
> >> +   POWER_SUPPLY_PROP_HEALTH,
> >> +   POWER_SUPPLY_PROP_PRESENT,
> >> +   POWER_SUPPLY_PROP_ONLINE,
> >> +   POWER_SUPPLY_PROP_VOLTAGE_MIN,
> >> +   POWER_SUPPLY_PROP_CURRENT_MAX,
> >> +   POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
> >> +};
> >> +
> >>  static const struct power_supply_desc axp20x_usb_power_desc = {
> >> .name = "axp20x-usb",
> >> .type = POWER_SUPPLY_TYPE_USB,
> >> @@ -406,6 +516,16 @@ static const struct power_supply_desc
> >axp22x_usb_power_desc = {
> >> .set_property = axp20x_usb_power_set_property,
> >>  };
> >>
> >> +static const struct power_supply_desc axp813_usb_power_desc = {
> >> +   .name = "axp20x-usb",
> >> +   .type = POWER_SUPPLY_TYPE_USB,
> >> +   .properties = axp813_usb_power_properties,
> >> +   .num_properties = ARRAY_SIZE(axp813_usb_power_properties),
> >> +   .property_is_writeable = axp20x_usb_power_prop_writeable,
> >> +   

Re: [PATCH 4.4 00/36] 4.4.196-stable review

[Guenter Roeck]

On 10/7/19 6:49 PM, Sasha Levin wrote:

On Mon, Oct 07, 2019 at 04:16:51PM -0700, Guenter Roeck wrote:

On 10/7/19 4:07 PM, Sasha Levin wrote:

On Mon, Oct 07, 2019 at 04:49:51PM +0200, Greg Kroah-Hartman wrote:

On Mon, Oct 07, 2019 at 05:53:55AM -0700, Guenter Roeck wrote:

On 10/6/19 10:18 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.4.196 release.
There are 36 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
Anything received after that time might be too late.



powerpc:defconfig fails to build.

arch/powerpc/kernel/eeh_driver.c: In function ‘eeh_handle_normal_event’:
arch/powerpc/kernel/eeh_driver.c:678:2: error: implicit declaration of function 
‘eeh_for_each_pe’; did you mean ‘bus_for_each_dev’?

It has a point:

... HEAD is now at 13cac61d31df Linux 4.4.196-rc1
$ git grep eeh_for_each_pe
arch/powerpc/kernel/eeh_driver.c:   eeh_for_each_pe(pe, tmp_pe)
arch/powerpc/kernel/eeh_driver.c:   
eeh_for_each_pe(pe, tmp_pe)

Caused by commit 3fb431be8de3a ("powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER 
flag").
Full report will follow later.


Thanks for letting me know, I've dropped this from the queue now and
pushed out a -rc2 with that removed.

Sasha, I thought your builder would have caught stuff like this?


Interesting, the 4.4 build fails for me with vanilla 4.4 LTS kernel
(which is why this was missed):

 AS  arch/powerpc/kernel/systbl.o
arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1599: Warning: invalid register expression
arch/powerpc/kernel/exceptions-64s.S:1640: Warning: invalid register expression
arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
arch/powerpc/kernel/exceptions-64s.S:840: Error: attempt to move .org backwards
arch/powerpc/kernel/exceptions-64s.S:864: Error: attempt to move .org backwards
arch/powerpc/kernel/exceptions-64s.S:865: Error: attempt to move .org backwards
scripts/Makefile.build:375: recipe for target 'arch/powerpc/kernel/head_64.o' 
failed



Is this allmodconfig ? That is correct - it won't build in 4.4.y, and it would 
not be
easy to fix.


Oh, interesting, so no allmodconfig? I've disabled everything but
allmodconfig on a few architectures in an attempt to save to build time.



If I recall correctly, it stopped working quite some time ago for v4.4.y, and 
the powerpc
maintainers didn't want to spend the time fixing it. It works with v4.9.y and 
later.

Guenter

Re: [PATCH v2] mfd: intel-lpss: use devm_ioremap_uc for MMIO

[AceLan Kao]

Confirmed the patch works well on Dell XPS 7390 2-in-1 machine.

Tested-by: AceLan Kao 

Tuowen Zhao  於 2019年10月8日 週二 上午2:43寫道：
>
> Some BIOS erroneously specifies write-combining BAR for intel-lpss-pci
> in MTRR. This will cause the system to hang during boot. If possible,
> this bug could be corrected with a firmware update.
>
> This patch adds devm_ioremap_uc as a new managed wrapper to ioremap_uc
> and with it overwrite the MTRR settings to force the use of strongly
> uncachable pages for intel-lpss.
>
> The BIOS bug is present on Dell XPS 13 7390 2-in-1:
>
> [0.001734]   5 base 40 mask 60 write-combining
>
> 40-7f : PCI Bus :00
>   40-400fff : :00:02.0 (i915)
>   401000-401fff : :00:15.0 (intel-lpss-pci)
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=203485
> Signed-off-by: Tuowen Zhao 
> ---
> Changes from previous version:
>
>   * changed commit message
>
>  drivers/mfd/intel-lpss.c |  2 +-
>  include/linux/io.h   |  2 ++
>  lib/devres.c | 19 +++
>  3 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
> index bfe4ff337581..b0f0781a6b9c 100644
> --- a/drivers/mfd/intel-lpss.c
> +++ b/drivers/mfd/intel-lpss.c
> @@ -384,7 +384,7 @@ int intel_lpss_probe(struct device *dev,
> if (!lpss)
> return -ENOMEM;
>
> -   lpss->priv = devm_ioremap(dev, info->mem->start + LPSS_PRIV_OFFSET,
> +   lpss->priv = devm_ioremap_uc(dev, info->mem->start + LPSS_PRIV_OFFSET,
>   LPSS_PRIV_SIZE);
> if (!lpss->priv)
> return -ENOMEM;
> diff --git a/include/linux/io.h b/include/linux/io.h
> index accac822336a..a59834bc0a11 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -64,6 +64,8 @@ static inline void devm_ioport_unmap(struct device *dev, 
> void __iomem *addr)
>
>  void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
>resource_size_t size);
> +void __iomem *devm_ioremap_uc(struct device *dev, resource_size_t offset,
> +  resource_size_t size);
>  void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t 
> offset,
>resource_size_t size);
>  void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
> diff --git a/lib/devres.c b/lib/devres.c
> index 6a0e9bd6524a..beb0a064b891 100644
> --- a/lib/devres.c
> +++ b/lib/devres.c
> @@ -9,6 +9,7 @@
>  enum devm_ioremap_type {
> DEVM_IOREMAP = 0,
> DEVM_IOREMAP_NC,
> +   DEVM_IOREMAP_UC,
> DEVM_IOREMAP_WC,
>  };
>
> @@ -39,6 +40,9 @@ static void __iomem *__devm_ioremap(struct device *dev, 
> resource_size_t offset,
> case DEVM_IOREMAP_NC:
> addr = ioremap_nocache(offset, size);
> break;
> +   case DEVM_IOREMAP_UC:
> +   addr = ioremap_uc(offset, size);
> +   break;
> case DEVM_IOREMAP_WC:
> addr = ioremap_wc(offset, size);
> break;
> @@ -68,6 +72,21 @@ void __iomem *devm_ioremap(struct device *dev, 
> resource_size_t offset,
>  }
>  EXPORT_SYMBOL(devm_ioremap);
>
> +/**
> + * devm_ioremap_uc - Managed ioremap_uc()
> + * @dev: Generic device to remap IO address for
> + * @offset: Resource address to map
> + * @size: Size of map
> + *
> + * Managed ioremap_uc().  Map is automatically unmapped on driver detach.
> + */
> +void __iomem *devm_ioremap_uc(struct device *dev, resource_size_t offset,
> + resource_size_t size)
> +{
> +   return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_UC);
> +}
> +EXPORT_SYMBOL(devm_ioremap_uc);
> +
>  /**
>   * devm_ioremap_nocache - Managed ioremap_nocache()
>   * @dev: Generic device to remap IO address for
> --
> 2.23.0
>

Re: [linux-sunxi] [PATCH 2/2] power: supply: axp20x_usb_power: add applied max Vbus support for AXP813

[Icenowy Zheng]

于 2019年10月8日 GMT+08:00 上午12:07:05, Chen-Yu Tsai  写到:
>Hi,
>
>On Wed, Oct 2, 2019 at 7:27 PM Icenowy Zheng  wrote:
>>
>> AXP813 PMIC has two Vbus maximum value settings -- one is the default
>> value, which is currently the only supported one; the other is the
>> really applied value, which is set according to the default value if
>the
>> BC detection module detected a charging port, or 500mA if no charging
>> port is detected.
>>
>> Add support for reading and writing of the really applied Vbus
>maxmium
>> value. Interestingly it has a larger range than the default value.
>>
>> Signed-off-by: Icenowy Zheng 
>> ---
>>  drivers/power/supply/axp20x_usb_power.c | 132
>+++-
>>  1 file changed, 129 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/power/supply/axp20x_usb_power.c
>b/drivers/power/supply/axp20x_usb_power.c
>> index 5f0a5722b19e..905668a2727f 100644
>> --- a/drivers/power/supply/axp20x_usb_power.c
>> +++ b/drivers/power/supply/axp20x_usb_power.c
>
>[...]
>
>> @@ -354,6 +451,9 @@ static int axp20x_usb_power_set_property(struct
>power_supply *psy,
>>
>val->intval);
>> return axp20x_usb_power_set_current_max(power,
>val->intval);
>>
>> +   case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
>> +   return
>axp20x_usb_power_set_input_current_limit(power, val->intval);
>> +
>
>So I think there are two things that should be adjusted.
>
>First, we should be using POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT for all
>PMICs.
>As far as the sysfs documents go, CURRENT_MAX is read-only, and should
>refer to
>the hard limit the hardware can support, i.e. maximum power ratings.
>INPUT_CURRENT_LIMIT and INPUT_VOLTAGE_LIMIT are for configurable upper
>and lower
>limits respectively.
>
>Sebastian, is my understanding of this correct?
>
>We already use INPUT_CURRENT_LIMIT for the AXP813 in the axp20x-ac
>driver, and
>it would be nice to have both drivers expose the same attributes.
>
>Second, since the value set in register 0x35 is the one that actually
>has an
>effect, as opposed to just being a default, we should just use that
>one.

However, that default value is also important, otherwise users will
get dropped back to 500mAh each time they re-insert USB jack.

Is there a property to export the default value?

BTW, if possible, apply patch 1 first, because it can raise current to 1.5A
in the default situation.

>
>Could you restructure the series based on what I described, with a new
>patch 1
>switching from CURRENT_MAX to INPUT_CURRENT_LIMIT, and then this patch
>as patch 2?
>And both patches should have Fixes tags and possibly CC stable so they
>get backported
>for people that are using stable kernels? And then the original patch
>2 as patch 3.
>
>ChenYu
>
>> default:
>> return -EINVAL;
>> }
>> @@ -365,7 +465,8 @@ static int axp20x_usb_power_prop_writeable(struct
>power_supply *psy,
>>enum power_supply_property
>psp)
>>  {
>> return psp == POWER_SUPPLY_PROP_VOLTAGE_MIN ||
>> -  psp == POWER_SUPPLY_PROP_CURRENT_MAX;
>> +  psp == POWER_SUPPLY_PROP_CURRENT_MAX ||
>> +  psp == POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT;
>>  }
>>
>>  static enum power_supply_property axp20x_usb_power_properties[] = {
>> @@ -386,6 +487,15 @@ static enum power_supply_property
>axp22x_usb_power_properties[] = {
>> POWER_SUPPLY_PROP_CURRENT_MAX,
>>  };
>>
>> +static enum power_supply_property axp813_usb_power_properties[] = {
>> +   POWER_SUPPLY_PROP_HEALTH,
>> +   POWER_SUPPLY_PROP_PRESENT,
>> +   POWER_SUPPLY_PROP_ONLINE,
>> +   POWER_SUPPLY_PROP_VOLTAGE_MIN,
>> +   POWER_SUPPLY_PROP_CURRENT_MAX,
>> +   POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
>> +};
>> +
>>  static const struct power_supply_desc axp20x_usb_power_desc = {
>> .name = "axp20x-usb",
>> .type = POWER_SUPPLY_TYPE_USB,
>> @@ -406,6 +516,16 @@ static const struct power_supply_desc
>axp22x_usb_power_desc = {
>> .set_property = axp20x_usb_power_set_property,
>>  };
>>
>> +static const struct power_supply_desc axp813_usb_power_desc = {
>> +   .name = "axp20x-usb",
>> +   .type = POWER_SUPPLY_TYPE_USB,
>> +   .properties = axp813_usb_power_properties,
>> +   .num_properties = ARRAY_SIZE(axp813_usb_power_properties),
>> +   .property_is_writeable = axp20x_usb_power_prop_writeable,
>> +   .get_property = axp20x_usb_power_get_property,
>> +   .set_property = axp20x_usb_power_set_property,
>> +};
>> +
>>  static int configure_iio_channels(struct platform_device *pdev,
>>   struct axp20x_usb_power *power)
>>  {
>> @@ -487,10 +607,16 @@ static int axp20x_usb_power_probe(struct
>platform_device *pdev)
>> usb_power_desc = _usb_power_desc;
>> irq_names = axp20x_irq_names;
>> } else if (power->axp20x_id == 

[PATCH v3] arm64: dts: enable otg mode for dwc3 usb ip on layerscape

[Yinbo Zhu]

layerscape otg function should be supported HNP SRP and ADP protocol
accroing to rm doc, but dwc3 code not realize it and use id pin to
detect who is host or device(0 is host 1 is device) this patch is to
enable OTG mode on ls1028ardb ls1088ardb and ls1046ardb in dts

Signed-off-by: Yinbo Zhu 
---
Changed in v3:
updated the patch title with "arm64: dts"

 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 4 
 arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 4 
 arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 1 +
 3 files changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index 9fb9113..076cac6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -171,3 +171,7 @@
  {
status = "okay";
 };
+
+ {
+   dr_mode = "otg";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index 6a6514d..0c742be 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -122,6 +122,10 @@
};
 };
 
+ {
+   dr_mode = "otg";
+};
+
 #include "fsl-ls1046-post.dtsi"
 
  {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
index 8e925df..90b1989 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
@@ -95,5 +95,6 @@
 };
 
  {
+   dr_mode = "otg";
status = "okay";
 };
-- 
2.9.5

linux-next: build failure after merge of the staging tree

[Stephen Rothwell]

Hi all,

After merging the staging tree, today's linux-next build (powerpc
allyesconfig) failed like this:

In file included from include/linux/byteorder/big_endian.h:5,
 from arch/powerpc/include/uapi/asm/byteorder.h:14,
 from include/asm-generic/bitops/le.h:6,
 from arch/powerpc/include/asm/bitops.h:243,
 from include/linux/bitops.h:26,
 from include/linux/kernel.h:12,
 from include/asm-generic/bug.h:19,
 from arch/powerpc/include/asm/bug.h:120,
 from include/linux/bug.h:5,
 from include/linux/gpio/consumer.h:5,
 from drivers/staging/wfx/bh.c:8:
drivers/staging/wfx/bh.c: In function 'rx_helper':
drivers/staging/wfx/bh.c:86:19: warning: passing argument 1 of '__swab16s' 
makes pointer from integer without a cast [-Wint-conversion]
   86 |   le16_to_cpus(hif->len);
include/uapi/linux/byteorder/big_endian.h:97:38: note: in definition of macro 
'__le16_to_cpus'
   97 | #define __le16_to_cpus(x) __swab16s((x))
  |  ^
drivers/staging/wfx/bh.c:86:3: note: in expansion of macro 'le16_to_cpus'
   86 |   le16_to_cpus(hif->len);
  |   ^~~~
In file included from include/linux/swab.h:5,
 from include/uapi/linux/byteorder/big_endian.h:13,
 from include/linux/byteorder/big_endian.h:5,
 from arch/powerpc/include/uapi/asm/byteorder.h:14,
 from include/asm-generic/bitops/le.h:6,
 from arch/powerpc/include/asm/bitops.h:243,
 from include/linux/bitops.h:26,
 from include/linux/kernel.h:12,
 from include/asm-generic/bug.h:19,
 from arch/powerpc/include/asm/bug.h:120,
 from include/linux/bug.h:5,
 from include/linux/gpio/consumer.h:5,
 from drivers/staging/wfx/bh.c:8:
include/uapi/linux/swab.h:230:37: note: expected '__u16 *' {aka 'short unsigned 
int *'} but argument is of type 'uint16_t' {aka 'short unsigned int'}
  230 | static inline void __swab16s(__u16 *p)
  |  ~~~^
In file included from include/linux/byteorder/big_endian.h:5,
 from arch/powerpc/include/uapi/asm/byteorder.h:14,
 from include/asm-generic/bitops/le.h:6,
 from arch/powerpc/include/asm/bitops.h:243,
 from include/linux/bitops.h:26,
 from include/linux/kernel.h:12,
 from include/asm-generic/bug.h:19,
 from arch/powerpc/include/asm/bug.h:120,
 from include/linux/bug.h:5,
 from include/linux/gpio/consumer.h:5,
 from drivers/staging/wfx/bh.c:8:
drivers/staging/wfx/bh.c:91:19: warning: passing argument 1 of '__swab16s' 
makes pointer from integer without a cast [-Wint-conversion]
   91 |   le16_to_cpus(hif->len);
include/uapi/linux/byteorder/big_endian.h:97:38: note: in definition of macro 
'__le16_to_cpus'
   97 | #define __le16_to_cpus(x) __swab16s((x))
  |  ^
drivers/staging/wfx/bh.c:91:3: note: in expansion of macro 'le16_to_cpus'
   91 |   le16_to_cpus(hif->len);
  |   ^~~~
In file included from include/linux/swab.h:5,
 from include/uapi/linux/byteorder/big_endian.h:13,
 from include/linux/byteorder/big_endian.h:5,
 from arch/powerpc/include/uapi/asm/byteorder.h:14,
 from include/asm-generic/bitops/le.h:6,
 from arch/powerpc/include/asm/bitops.h:243,
 from include/linux/bitops.h:26,
 from include/linux/kernel.h:12,
 from include/asm-generic/bug.h:19,
 from arch/powerpc/include/asm/bug.h:120,
 from include/linux/bug.h:5,
 from include/linux/gpio/consumer.h:5,
 from drivers/staging/wfx/bh.c:8:
include/uapi/linux/swab.h:230:37: note: expected '__u16 *' {aka 'short unsigned 
int *'} but argument is of type 'uint16_t' {aka 'short unsigned int'}
  230 | static inline void __swab16s(__u16 *p)
  |  ~~~^
In file included from include/linux/byteorder/big_endian.h:5,
 from arch/powerpc/include/uapi/asm/byteorder.h:14,
 from include/asm-generic/bitops/le.h:6,
 from arch/powerpc/include/asm/bitops.h:243,
 from include/linux/bitops.h:26,
 from include/linux/kernel.h:12,
 from include/asm-generic/bug.h:19,
 from arch/powerpc/include/asm/bug.h:120,
 from include/linux/bug.h:5,
 from include/net/mac80211.h:16,
 from drivers/staging/wfx/key.c:8:
drivers/staging/wfx/hif_tx_mib.h: In function 'hif_set_mfp':
drivers/staging/wfx/hif_tx_mib.h:139:15: error: 

Re: [PATCH v2 2/2] reset: Reset controller driver for Intel LGM SoC

[Dilip Kota]

Hi Martin,Philipp,

On 10/8/2019 3:53 AM, Martin Blumenstingl wrote:

Hi Philipp,

On Thu, Oct 3, 2019 at 4:19 PM Philipp Zabel  wrote:
[...]

because the register layout was greatly simplified for the newer SoCs
(for which there is reset-intel) compared to the older ones
(reset-lantiq).
Dilip's suggestion (in my own words) is that you take his new
reset-intel driver, then we will work on porting reset-lantiq over to
that so in the end we can drop the reset-lantiq driver.

Just to be sure, you are suggesting to add support for the current
lantiq,reset binding to the reset-intel driver at a later point? I
see no reason not to do that, but I'm also not quite sure what the
benefit will be over just keeping reset-lantiq as is?

according to Chuan and Dilip the current reset-lantiq implementation
is wrong [0].
my understanding is that the Lantiq and Intel LGM reset controllers
are identical except:
- the Lantiq variant uses a weird register layout (reset and status
registers not at consecutive offsets)
- the bits of the reset and status registers sometimes don't match on
the Lantiq variant
- the Intel variant has a dedicated registers area for the reset
controller registers, while the Lantiq variant mixes them with various
other functionality (for example: USB2 PHYs)


This approach means more work for me (as I am probably the one who
then has to do the work to port reset-lantiq over to reset-intel).

More work than what alternative?

compared to "fixing" the existing reset-lantiq driver (reset callback)
and then (instead of adding a new driver) integrating Intel LGM
support into reset-lantiq


Integrating Intel LGM support into reset-lantiq boils down to re-writing 
reset-lantiq driver as intel-reset driver and adding Lantiq variant 
support. Why because reset-lantiq driver is not according to hardware 
design[1].


I see the final best solution is to integrate Lantiq variant driver to 
intel-reset driver.[1]

I hope you guys are ok with it. Please let me know your view.


Regards,
Dilip

[1]: https://www.spinics.net/lists/devicetree/msg308930.html




I'm happy to do that work if you think that it's worth following this
approach.  So I want your opinion on this before I spend any effort on
porting reset-lantiq over to reset-intel.

Reset drivers are typically so simple, I'm not quite sure whether it is
worth to integrate multiple drivers if it complicates matters too much.
In this case though I expect it would just be adding support for a
custom .of_xlate and lantiq specific register property parsing?

yes, that's how I understand the Lantiq and Intel reset controllers:
- reset/status/assert/deassert callbacks would be shared across all variants
- register parsing and of_xlate are SoC specific


Martin


[0] https://www.spinics.net/lists/devicetree/msg305951.html

Re: linux-next: Signed-off-by missing for commit in the kbuild-current tree

[Masahiro Yamada]

Hi Stephen,

On Tue, Oct 8, 2019 at 5:05 AM Stephen Rothwell  wrote:
>
> Hi all,
>
> Commit
>
>   da6221f246f9 ("scripts: setlocalversion: fix a bashism")
>
> is missing a Signed-off-by from its committer.

I fixed it now. Thanks!


> --
> Cheers,
> Stephen Rothwell



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2] arm64: armv8_deprecated: Checking return value for memory allocation

[Yunfeng Ye]

On 2019/10/7 23:37, Will Deacon wrote:
> On Mon, Oct 07, 2019 at 06:06:35PM +0800, Yunfeng Ye wrote:
>> There are no return value checking when using kzalloc() and kcalloc() for
>> memory allocation. so add it.
>>
>> Signed-off-by: Yunfeng Ye 
>> ---
>> v1 -> v2:
>>  - return error code when memory allocation failure
>>
>>  arch/arm64/kernel/armv8_deprecated.c | 57 
>> +++-
>>  1 file changed, 43 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/armv8_deprecated.c 
>> b/arch/arm64/kernel/armv8_deprecated.c
>> index 2ec09de..2284fcb 100644
>> --- a/arch/arm64/kernel/armv8_deprecated.c
>> +++ b/arch/arm64/kernel/armv8_deprecated.c
>> @@ -168,12 +168,15 @@ static int update_insn_emulation_mode(struct 
>> insn_emulation *insn,
>>  return ret;
>>  }
>>
>> -static void __init register_insn_emulation(struct insn_emulation_ops *ops)
>> +static int __init register_insn_emulation(struct insn_emulation_ops *ops)
>>  {
>>  unsigned long flags;
>>  struct insn_emulation *insn;
>>
>>  insn = kzalloc(sizeof(*insn), GFP_KERNEL);
>> +if (!insn)
>> +return -ENOMEM;
>> +
>>  insn->ops = ops;
>>  insn->min = INSN_UNDEF;
>>
>> @@ -197,6 +200,7 @@ static void __init register_insn_emulation(struct 
>> insn_emulation_ops *ops)
>>
>>  /* Register any handlers if required */
>>  update_insn_emulation_mode(insn, INSN_UNDEF);
>> +return 0;
>>  }
>>
>>  static int emulation_proc_handler(struct ctl_table *table, int write,
>> @@ -224,7 +228,7 @@ static int emulation_proc_handler(struct ctl_table 
>> *table, int write,
>>  return ret;
>>  }
>>
>> -static void __init register_insn_emulation_sysctl(void)
>> +static int __init register_insn_emulation_sysctl(void)
>>  {
>>  unsigned long flags;
>>  int i = 0;
>> @@ -233,6 +237,8 @@ static void __init register_insn_emulation_sysctl(void)
>>
>>  insns_sysctl = kcalloc(nr_insn_emulated + 1, sizeof(*sysctl),
>> GFP_KERNEL);
>> +if (!insns_sysctl)
>> +return -ENOMEM;
>>
>>  raw_spin_lock_irqsave(_emulation_lock, flags);
>>  list_for_each_entry(insn, _emulation, node) {
>> @@ -251,6 +257,7 @@ static void __init register_insn_emulation_sysctl(void)
>>  raw_spin_unlock_irqrestore(_emulation_lock, flags);
>>
>>  register_sysctl("abi", insns_sysctl);
>> +return 0;
>>  }
>>
>>  /*
>> @@ -617,25 +624,47 @@ static int t16_setend_handler(struct pt_regs *regs, 
>> u32 instr)
>>   */
>>  static int __init armv8_deprecated_init(void)
>>  {
>> -if (IS_ENABLED(CONFIG_SWP_EMULATION))
>> -register_insn_emulation(_ops);
>> +int ret = 0;
>> +int err = 0;
>> +
>> +if (IS_ENABLED(CONFIG_SWP_EMULATION)) {
>> +ret = register_insn_emulation(_ops);
>> +if (ret) {
>> +pr_err("register insn emulation swp: fail\n");
>> +err = ret;
>> +}
>> +}
> 
> Is there much point in continuing here? May as well just return ret, I
> think. I also don't think you need to print anything, since kmalloc
> should already have shouted.
> 
The registration of each instruction simulation is independent. I think
that one failure does not affect the registration of other instructions.
In addition, if return directly, is it need to unregister? Of course,
the first instruction registration can be directly returned, If the
following instruction registration fails, is it need unregister operation?
currently the unregistration of instruction simulation is not be implemented
yet.

The purpose of printing information is to replace the direct return, which
can distinguish which instruction failed to register. There is no need to print
information if it returns directly.

thanks.

>> -if (IS_ENABLED(CONFIG_CP15_BARRIER_EMULATION))
>> -register_insn_emulation(_barrier_ops);
>> +if (IS_ENABLED(CONFIG_CP15_BARRIER_EMULATION)) {
>> +ret = register_insn_emulation(_barrier_ops);
>> +if (ret) {
>> +pr_err("register insn emulation cpu15_barrier: fail\n");
>> +err = ret;
>> +}
>> +}
>>
>>  if (IS_ENABLED(CONFIG_SETEND_EMULATION)) {
>> -if(system_supports_mixed_endian_el0())
>> -register_insn_emulation(_ops);
>> -else
>> +if (system_supports_mixed_endian_el0()) {
>> +ret = register_insn_emulation(_ops);
>> +if (ret) {
>> +pr_err("register insn emulation setend: 
>> fail\n");
>> +err = ret;
>> +}
>> +} else {
>>  pr_info("setend instruction emulation is not supported 
>> on this system\n");
>> +}
>>  }
>>
>> -cpuhp_setup_state_nocalls(CPUHP_AP_ARM64_ISNDEP_STARTING,
>> -  "arm64/isndep:starting",
>> -

Re: [PATCH RFC 2/3] mtd: rawnand: Add support Macronix Block Protection function

[masonccyang]

Hi Miquel,

> > 
> > > Macronix AC series support using SET/GET_FEATURES to change
> > > Block Protection and Unprotection.
> > > 
> > > MTD default _lock/_unlock function replacement by manufacturer
> > > postponed initialization. 
> > 
> > Why would we do that?
> > 
> > Anyway your solution looks overkill, if we ever decide to
> > implement these hooks for raw nand, it is better just to not
> > overwrite them in nand_scan_tail() if they have been filled
> > previously (ie. by the manufacturer code).
> 
> Actually you should add two NAND hooks that do the interface with the
> MTD hooks. In the NAND hooks, check that the request is to lock all the
> device, otherwise return -ENOTSUPP.

sorry, can't get your point.

Because the NAND entire chip will be protected if PT(protection) pin 
is active high at power-on.

> 
> Then fill-in these two hooks from the manufacturer code, without the
> postponed init.
> 

But in the final of nand_scan_tail(), mtd->_lock/_unlock will be
filled by NULL, right ?

thanks & best regards,
Mason

CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information 
and/or personal data, which is protected by applicable laws. Please be 
reminded that duplication, disclosure, distribution, or use of this e-mail 
(and/or its attachments) or any part thereof is prohibited. If you receive 
this e-mail in error, please notify us immediately and delete this mail as 
well as its attachment(s) from your system. In addition, please be 
informed that collection, processing, and/or use of personal data is 
prohibited unless expressly permitted by personal data protection laws. 
Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=





CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information and/or 
personal data, which is protected by applicable laws. Please be reminded that 
duplication, disclosure, distribution, or use of this e-mail (and/or its 
attachments) or any part thereof is prohibited. If you receive this e-mail in 
error, please notify us immediately and delete this mail as well as its 
attachment(s) from your system. In addition, please be informed that 
collection, processing, and/or use of personal data is prohibited unless 
expressly permitted by personal data protection laws. Thank you for your 
attention and cooperation.

Macronix International Co., Ltd.

=

RE: [PATCH v10 2/3] arm64: mm: implement arch_faults_on_old_pte() on arm64

[Justin He (Arm Technology China)]

> -Original Message-
> From: Justin He (Arm Technology China)
> Sent: 2019年10月8日 9:55
> To: Marc Zyngier ; Will Deacon 
> Cc: Catalin Marinas ; Mark Rutland
> ; James Morse ;
> Matthew Wilcox ; Kirill A. Shutemov
> ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux...@kvack.org; Punit Agrawal
> ; Thomas Gleixner ;
> Andrew Morton ; hejia...@gmail.com; Kaly
> Xin (Arm Technology China) ; nd 
> Subject: RE: [PATCH v10 2/3] arm64: mm: implement
> arch_faults_on_old_pte() on arm64
> 
> Hi Will and Marc
> 
> > -Original Message-
> > From: Marc Zyngier 
> > Sent: 2019年10月1日 21:32
> > To: Will Deacon 
> > Cc: Justin He (Arm Technology China) ; Catalin
> > Marinas ; Mark Rutland
> > ; James Morse ;
> > Matthew Wilcox ; Kirill A. Shutemov
> > ; linux-arm-ker...@lists.infradead.org;
> > linux-kernel@vger.kernel.org; linux...@kvack.org; Punit Agrawal
> > ; Thomas Gleixner ;
> > Andrew Morton ; hejia...@gmail.com;
> Kaly
> > Xin (Arm Technology China) 
> > Subject: Re: [PATCH v10 2/3] arm64: mm: implement
> > arch_faults_on_old_pte() on arm64
> >
> > On Tue, 1 Oct 2019 13:50:32 +0100
> > Will Deacon  wrote:
> >
> > > On Mon, Sep 30, 2019 at 09:57:39AM +0800, Jia He wrote:
> > > > On arm64 without hardware Access Flag, copying fromuser will fail
> > because
> > > > the pte is old and cannot be marked young. So we always end up with
> > zeroed
> > > > page after fork() + CoW for pfn mappings. we don't always have a
> > > > hardware-managed access flag on arm64.
> > > >
> > > > Hence implement arch_faults_on_old_pte on arm64 to indicate that
> it
> > might
> > > > cause page fault when accessing old pte.
> > > >
> > > > Signed-off-by: Jia He 
> > > > Reviewed-by: Catalin Marinas 
> > > > ---
> > > >  arch/arm64/include/asm/pgtable.h | 14 ++
> > > >  1 file changed, 14 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/include/asm/pgtable.h
> > b/arch/arm64/include/asm/pgtable.h
> > > > index 7576df00eb50..e96fb82f62de 100644
> > > > --- a/arch/arm64/include/asm/pgtable.h
> > > > +++ b/arch/arm64/include/asm/pgtable.h
> > > > @@ -885,6 +885,20 @@ static inline void update_mmu_cache(struct
> > vm_area_struct *vma,
> > > >  #define phys_to_ttbr(addr) (addr)
> > > >  #endif
> > > >
> > > > +/*
> > > > + * On arm64 without hardware Access Flag, copying from user will
> fail
> > because
> > > > + * the pte is old and cannot be marked young. So we always end up
> > with zeroed
> > > > + * page after fork() + CoW for pfn mappings. We don't always have a
> > > > + * hardware-managed access flag on arm64.
> > > > + */
> > > > +static inline bool arch_faults_on_old_pte(void)
> > > > +{
> > > > +   WARN_ON(preemptible());
> > > > +
> > > > +   return !cpu_has_hw_af();
> > > > +}
> > >
> > > Does this work correctly in a KVM guest? (i.e. is the MMFR sanitised in
> > that
> > > case, despite not being the case on the host?)
> >
> > Yup, all the 64bit MMFRs are trapped (HCR_EL2.TID3 is set for an
> > AArch64 guest), and we return the sanitised version.
> Thanks for Marc's explanation. I verified the patch series on a kvm guest (-
> M virt)
> with simulated nvdimm device created by qemu. The host is ThunderX2
> aarch64.
> 
> >
> > But that's an interesting remark: we're now trading an extra fault on
> > CPUs that do not support HWAFDBS for a guaranteed trap for each and
> > every guest under the sun that will hit the COW path...
> >
> > My gut feeling is that this is going to be pretty visible. Jia, do you
> > have any numbers for this kind of behaviour?
> It is not a common COW path, but a COW for PFN mapping pages only.
> I add a g_counter before pte_mkyoung in force_mkyoung{} when testing
> vmmalloc_fork at [1].
> 
> In this test case, it will start M fork processes and N pthreads. The default 
> is
> M=2,N=4. the g_counter is about 241, that is it will hit my patch series for
> 241
> times.
> If I set M=20 and N=40 for TEST3, the g_counter is about 1492.

The time overhead of test vmmalloc_fork is:
real0m5.411s
user0m4.206s
sys 0m2.699s

> 
> [1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
> 
> 
> --
> Cheers,
> Justin (Jia He)
> 

Re: [PATCH v4 1/4] x86/kvm: Add "nopvspin" parameter to disable PV spinlocks

[Zhenzhong Duan]

On 2019/10/7 22:46, Boris Ostrovsky wrote:

On 10/6/19 3:49 AM, Zhenzhong Duan wrote:

On 2019/10/4 22:52, Boris Ostrovsky wrote:


On 10/3/19 10:02 AM, Zhenzhong Duan wrote:

   void __init kvm_spinlock_init(void)
   {
-    /* Does host kernel support KVM_FEATURE_PV_UNHALT? */
-    if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT))
-    return;
-
-    if (kvm_para_has_hint(KVM_HINTS_REALTIME))
+    /*
+ * Don't use the pvqspinlock code if no KVM_FEATURE_PV_UNHALT
feature
+ * support, or there is REALTIME hints or only 1 vCPU.
+ */
+    if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT) ||
+    kvm_para_has_hint(KVM_HINTS_REALTIME) ||
+    num_possible_cpus() == 1) {
+    pr_info("PV spinlocks disabled\n");
   return;
+    }
   -    /* Don't use the pvqspinlock code if there is only 1 vCPU. */
-    if (num_possible_cpus() == 1)
+    if (nopvspin) {
+    pr_info("PV spinlocks disabled forced by \"nopvspin\"
parameter.\n");
+    static_branch_disable(_spin_lock_key);

Would it make sense to bring here the other site where the key is
disabled (in kvm_smp_prepare_cpus())?

Thanks for point out, I'll do it. Just not clear if I should do that
in a separate patch,
there is a history about that code:

Its original place was here and then moved to kvm_smp_prepare_cpus()
by below commit:
34226b6b ("KVM: X86: Fix setup the virt_spin_lock_key before static
key get initialized")
which fixed jump_label_init() calling late issue.

Then 8990cac6 ("x86/jump_label: Initialize static branching early")
move jump_label_init()
early, so commit 34226b6b could be reverted.

Which is similar to what you did earlier for Xen.


You remember that, ok, I'll do the same for KVM.

Thanks

Zhenzhong

RE: [PATCH v10 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared

[Justin He (Arm Technology China)]

Hi Will

> -Original Message-
> From: Will Deacon 
> Sent: 2019年10月1日 20:54
> To: Justin He (Arm Technology China) 
> Cc: Catalin Marinas ; Mark Rutland
> ; James Morse ; Marc
> Zyngier ; Matthew Wilcox ; Kirill A.
> Shutemov ; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> m...@kvack.org; Punit Agrawal ; Thomas
> Gleixner ; Andrew Morton  foundation.org>; hejia...@gmail.com; Kaly Xin (Arm Technology China)
> 
> Subject: Re: [PATCH v10 3/3] mm: fix double page fault on arm64 if PTE_AF
> is cleared
> 
> On Mon, Sep 30, 2019 at 09:57:40AM +0800, Jia He wrote:
> > When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest,
> there
> > will be a double page fault in __copy_from_user_inatomic of
> cow_user_page.
> >
> > Below call trace is from arm64 do_page_fault for debugging purpose
> > [  110.016195] Call trace:
> > [  110.016826]  do_page_fault+0x5a4/0x690
> > [  110.017812]  do_mem_abort+0x50/0xb0
> > [  110.018726]  el1_da+0x20/0xc4
> > [  110.019492]  __arch_copy_from_user+0x180/0x280
> > [  110.020646]  do_wp_page+0xb0/0x860
> > [  110.021517]  __handle_mm_fault+0x994/0x1338
> > [  110.022606]  handle_mm_fault+0xe8/0x180
> > [  110.023584]  do_page_fault+0x240/0x690
> > [  110.024535]  do_mem_abort+0x50/0xb0
> > [  110.025423]  el0_da+0x20/0x24
> >
> > The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
> > [9b007000] pgd=00023d4f8003, pud=00023da9b003,
> pmd=00023d4b3003, pte=36298607bd3
> >
> > As told by Catalin: "On arm64 without hardware Access Flag, copying
> from
> > user will fail because the pte is old and cannot be marked young. So we
> > always end up with zeroed page after fork() + CoW for pfn mappings. we
> > don't always have a hardware-managed access flag on arm64."
> >
> > This patch fix it by calling pte_mkyoung. Also, the parameter is
> > changed because vmf should be passed to cow_user_page()
> >
> > Add a WARN_ON_ONCE when __copy_from_user_inatomic() returns
> error
> > in case there can be some obscure use-case.(by Kirill)
> >
> > [1]
> https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
> >
> > Signed-off-by: Jia He 
> > Reported-by: Yibo Cai 
> > Reviewed-by: Catalin Marinas 
> > Acked-by: Kirill A. Shutemov 
> > ---
> >  mm/memory.c | 99
> +
> >  1 file changed, 84 insertions(+), 15 deletions(-)
> >
> > diff --git a/mm/memory.c b/mm/memory.c
> > index b1ca51a079f2..1f56b0118ef5 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
> > 2;
> >  #endif
> >
> > +#ifndef arch_faults_on_old_pte
> > +static inline bool arch_faults_on_old_pte(void)
> > +{
> > +   return false;
> > +}
> > +#endif
> 
> Kirill has acked this, so I'm happy to take the patch as-is, however isn't
> it the case that /most/ architectures will want to return true for
> arch_faults_on_old_pte()? In which case, wouldn't it make more sense for
> that to be the default, and have x86 and arm64 provide an override? For
> example, aren't most architectures still going to hit the double fault
> scenario even with your patch applied?

No, after applying my patch series, only those architectures which don't provide
setting access flag by hardware AND don't implement their arch_faults_on_old_pte
will hit the double page fault.

The meaning of true for arch_faults_on_old_pte() is "this arch doesn't have the 
hardware
setting access flag way, it might cause page fault on an old pte"
I don't want to change other architectures' default behavior here. So by 
default, 
arch_faults_on_old_pte() is false.

Btw, currently I only observed this double pagefault on arm64's guest (host is 
ThunderX2).
On X86 guest (host is Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz ), there is no 
such double
pagefault. It has the similar setting access flag way by hardware.


--
Cheers,
Justin (Jia He)

Re: [PATCH RFC 3/3] mtd: rawnand: Add support Macronix power down mode

[masonccyang]

Hi Miquel,


 
> > +int nand_power_down_op(struct nand_chip *chip)
> > +{
> > +   int ret;
> > +
> > +   if (nand_has_exec_op(chip)) {
> > +  struct nand_op_instr instrs[] = {
> > + NAND_OP_CMD(NAND_CMD_POWER_DOWN, 0),
> > +  };
> > +
> > +  struct nand_operation op = NAND_OPERATION(chip->cur_cs, 
instrs);
> > +
> > +  ret = nand_exec_op(chip, );
> > +  if (ret)
> > + return ret;
> > +
> > +   } else {
> > +  chip->legacy.cmdfunc(chip, NAND_CMD_POWER_DOWN, -1, -1);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int mxic_nand_suspend(struct mtd_info *mtd)
> > +{
> > +   struct nand_chip *chip = mtd_to_nand(mtd);
> > +
> > +   mutex_lock(>lock);
> > +
> > +   nand_select_target(chip, 0);
> > +   nand_power_down_op(chip);
> > +   nand_deselect_target(chip);
> > +
> > +   chip->suspend = 1;
> > +   mutex_unlock(>lock);
> > +
> > +   return 0;
> > +}
> > +
> > +static void mxic_nand_resume(struct mtd_info *mtd)
> > +{
> > +   struct nand_chip *chip = mtd_to_nand(mtd);
> > +
> > +   mutex_lock(>lock);
> > +   // toggle #CS pin to resume NAND device
> 
> C++ style comments are forbidden in code.

okay, got it. thanks.

> 
> > +   nand_select_target(chip, 0);
> 
> On several NAND controllers there is no way to act on the CS line
> without actually writing bytes to the NAND chip. So basically this
> is very likely to not work.

any other way to make it work ? GPIO ?
or just have some comments description here.
i.e,.

/* The NAND chip will exit the deep power down mode with #CS toggling, 
 * please refer to datasheet for the timing requirement of tCRDP and tRDP.
 */

> 
> > +   ndelay(20);
> 
> Is this delay known somewhere? Is this purely experimental?

it's timing requirement tCRDP 20 ns(min) to release device
from deep power-down mode. 
You may download datasheet at
https://www.macronix.com/zh-tw/products/NAND-Flash/SLC-NAND-Flash/Pages/spec.aspx?p=MX30LF4G28AD=SLC%20NAND=PM2579
 


> 
> > +   nand_deselect_target(chip);
> > +
> > +   if (chip->suspend)
> > +  chip->suspended = 0;
> > +   else
> > +  pr_err("%s call for a chip which is not in suspended state\n",
> > + __func__);
> > +   mutex_unlock(>lock);
> > +}

thanks & best regards,
Mason

CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information 
and/or personal data, which is protected by applicable laws. Please be 
reminded that duplication, disclosure, distribution, or use of this e-mail 
(and/or its attachments) or any part thereof is prohibited. If you receive 
this e-mail in error, please notify us immediately and delete this mail as 
well as its attachment(s) from your system. In addition, please be 
informed that collection, processing, and/or use of personal data is 
prohibited unless expressly permitted by personal data protection laws. 
Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=





CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information and/or 
personal data, which is protected by applicable laws. Please be reminded that 
duplication, disclosure, distribution, or use of this e-mail (and/or its 
attachments) or any part thereof is prohibited. If you receive this e-mail in 
error, please notify us immediately and delete this mail as well as its 
attachment(s) from your system. In addition, please be informed that 
collection, processing, and/or use of personal data is prohibited unless 
expressly permitted by personal data protection laws. Thank you for your 
attention and cooperation.

Macronix International Co., Ltd.

=

Re: [PATCH] media: vimc: Make capture devices and subdevices use different link_validates

[Helen Koike]

On 10/6/19 9:42 PM, Helen Koike wrote:
> Hi Nícolas,
> 
> Thanks for you patch, just some small comments below.
> 
> On 10/6/19 4:14 PM, Nícolas F. R. A. Prado wrote:
>> Instead of validating the links to capture devices and subdevices with
>> the same function, use the default v4l function for links between
>> subdevices and only use a different function for validating between
>> capture device and subdevice.
>> This change should also ease future work to associate multiple mbus
>> codes for the same pixelformat in vimc_pix_map.
>>
>> These changes were tested with 
>> v4l2-compliance SHA: 3f806630e2ecbcebe31872b865c5c4b42f111a99, 64 bits
>> and passed all tests:
>> Grand Total for vimc device /dev/media0: 451, Succeeded: 451, Failed: 0, 
>> Warnings: 0
>>
>> Signed-off-by: Nícolas F. R. A. Prado 
>> ---
>>  drivers/media/platform/vimc/vimc-capture.c |  78 +++-
>>  drivers/media/platform/vimc/vimc-common.c  | 103 -
>>  drivers/media/platform/vimc/vimc-common.h  |   3 +
>>  3 files changed, 96 insertions(+), 88 deletions(-)
>>
>> diff --git a/drivers/media/platform/vimc/vimc-capture.c 
>> b/drivers/media/platform/vimc/vimc-capture.c
>> index 602f80323031..924b99f82123 100644
>> --- a/drivers/media/platform/vimc/vimc-capture.c
>> +++ b/drivers/media/platform/vimc/vimc-capture.c
>> @@ -321,8 +321,84 @@ static const struct vb2_ops vimc_cap_qops = {
>>  .wait_finish= vb2_ops_wait_finish,
>>  };
>>  
>> +int vimc_cap_link_validate(struct media_link *link)
> 
> This function is only used inside the capture, it could be static.

Actually, I was thinking that it is maybe better to leave this function in
vimc-common and rename it to vimc_vdev_link_validate(), as it is generic
to any video_device, and we also avoid to moving it to from vimc-common to
vimc-cap and back to vimc-common again if we add other video devices.

Regards,
Helen

> 
> Unless if you want to make it a generic function in vimc-common.h, so the 
> future
> output device could use it as well, but it can be done in the output patch.
> 
> 
>> +{
>> +struct v4l2_pix_format source_fmt, sink_fmt;
>> +int ret;
>> +
>> +ret = vimc_get_pix_format(link->source, _fmt);
>> +if (ret)
>> +return ret;
>> +
>> +ret = vimc_get_pix_format(link->sink, _fmt);
>> +if (ret)
>> +return ret;
>> +
>> +pr_info("vimc link validate: "
>> +"%s:src:%dx%d (0x%x, %d, %d, %d, %d) "
>> +"%s:snk:%dx%d (0x%x, %d, %d, %d, %d)\n",
>> +/* src */
>> +link->source->entity->name,
>> +source_fmt.width, source_fmt.height,
>> +source_fmt.pixelformat, source_fmt.colorspace,
>> +source_fmt.quantization, source_fmt.xfer_func,
>> +source_fmt.ycbcr_enc,
>> +/* sink */
>> +link->sink->entity->name,
>> +sink_fmt.width, sink_fmt.height,
>> +sink_fmt.pixelformat, sink_fmt.colorspace,
>> +sink_fmt.quantization, sink_fmt.xfer_func,
>> +sink_fmt.ycbcr_enc);
>> +
>> +/* The width, height and pixelformat must match. */
>> +if (source_fmt.width != sink_fmt.width
>> +|| source_fmt.height != sink_fmt.height
>> +|| source_fmt.pixelformat != sink_fmt.pixelformat)
>> +return -EPIPE;
>> +
>> +/*
>> + * The field order must match, or the sink field order must be NONE
>> + * to support interlaced hardware connected to bridges that support
>> + * progressive formats only.
>> + */
>> +if (source_fmt.field != sink_fmt.field &&
>> +sink_fmt.field != V4L2_FIELD_NONE)
>> +return -EPIPE;
>> +
>> +/*
>> + * If colorspace is DEFAULT, then assume all the colorimetry is also
>> + * DEFAULT, return 0 to skip comparing the other colorimetry parameters
>> + */
>> +if (source_fmt.colorspace == V4L2_COLORSPACE_DEFAULT
>> +|| sink_fmt.colorspace == V4L2_COLORSPACE_DEFAULT)
>> +return 0;
>> +
>> +/* Colorspace must match. */
>> +if (source_fmt.colorspace != sink_fmt.colorspace)
>> +return -EPIPE;
>> +
>> +/* Colorimetry must match if they are not set to DEFAULT */
>> +if (source_fmt.ycbcr_enc != V4L2_YCBCR_ENC_DEFAULT
>> +&& sink_fmt.ycbcr_enc != V4L2_YCBCR_ENC_DEFAULT
>> +&& source_fmt.ycbcr_enc != sink_fmt.ycbcr_enc)
>> +return -EPIPE;
>> +
>> +if (source_fmt.quantization != V4L2_QUANTIZATION_DEFAULT
>> +&& sink_fmt.quantization != V4L2_QUANTIZATION_DEFAULT
>> +&& source_fmt.quantization != sink_fmt.quantization)
>> +return -EPIPE;
>> +
>> +if (source_fmt.xfer_func != V4L2_XFER_FUNC_DEFAULT
>> +&& sink_fmt.xfer_func != V4L2_XFER_FUNC_DEFAULT
>> +&& source_fmt.xfer_func != sink_fmt.xfer_func)
>> +return -EPIPE;
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(vimc_cap_link_validate);
> 
> No need to export it here.
> 
>> +
>>  

Re: [PATCH] sgi-gru: simplify procfs code some more

[Dimitri Sivanich]

While a reduction in object size is welcome, in this case it does come at the
expense of some clarity, as field sizes are no longer as clear.
Nevertheless, will add my ack.

Acked-by: Dimitri Sivanich 

On Mon, Oct 07, 2019 at 11:30:46AM -0700, Joe Perches wrote:
> Use seq_puts and simple string output and not seq_printf with formats
> and individual strings to reduce overall object size.
> 
> $ size drivers/misc/sgi-gru/gruprocfs.o* (x86-64 defconfig with gru)
>text  data bss dec hex filename
>7006 8   070141b66 
> drivers/misc/sgi-gru/gruprocfs.o.new
>7472 8   074801d38 
> drivers/misc/sgi-gru/gruprocfs.o.old
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/misc/sgi-gru/gruprocfs.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/misc/sgi-gru/gruprocfs.c 
> b/drivers/misc/sgi-gru/gruprocfs.c
> index 3a8d76d1ccae..2817f4751306 100644
> --- a/drivers/misc/sgi-gru/gruprocfs.c
> +++ b/drivers/misc/sgi-gru/gruprocfs.c
> @@ -119,7 +119,7 @@ static int mcs_statistics_show(struct seq_file *s, void 
> *p)
>   "cch_interrupt_sync", "cch_deallocate", "tfh_write_only",
>   "tfh_write_restart", "tgh_invalidate"};
>  
> - seq_printf(s, "%-20s%12s%12s%12s\n", "#id", "count", "aver-clks", 
> "max-clks");
> + seq_puts(s, "#idcount   aver-clks
> max-clks\n");
>   for (op = 0; op < mcsop_last; op++) {
>   count = atomic_long_read(_op_statistics[op].count);
>   total = atomic_long_read(_op_statistics[op].total);
> @@ -165,8 +165,7 @@ static int cch_seq_show(struct seq_file *file, void *data)
>   const char *mode[] = { "??", "UPM", "INTR", "OS_POLL" };
>  
>   if (gid == 0)
> - seq_printf(file, "#%5s%5s%6s%7s%9s%6s%8s%8s\n", "gid", "bid",
> -"ctx#", "asid", "pid", "cbrs", "dsbytes", "mode");
> + seq_puts(file, "#  gid  bid  ctx#   asid  pid  cbrs dsbytes 
>mode\n");
>   if (gru)
>   for (i = 0; i < GRU_NUM_CCH; i++) {
>   ts = gru->gs_gts[i];
> @@ -191,10 +190,8 @@ static int gru_seq_show(struct seq_file *file, void 
> *data)
>   struct gru_state *gru = GID_TO_GRU(gid);
>  
>   if (gid == 0) {
> - seq_printf(file, "#%5s%5s%7s%6s%6s%8s%6s%6s\n", "gid", "nid",
> -"ctx", "cbr", "dsr", "ctx", "cbr", "dsr");
> - seq_printf(file, "#%5s%5s%7s%6s%6s%8s%6s%6s\n", "", "", "busy",
> -"busy", "busy", "free", "free", "free");
> + seq_puts(file, "#  gid  nidctx   cbr   dsr ctx   cbr   
> dsr\n");
> + seq_puts(file, "# busy  busy  busyfree  free  
> free\n");
>   }
>   if (gru) {
>   ctxfree = GRU_NUM_CCH - gru->gs_active_contexts;
> 
> 

RE: [PATCH v10 2/3] arm64: mm: implement arch_faults_on_old_pte() on arm64

[Justin He (Arm Technology China)]

Hi Will and Marc

> -Original Message-
> From: Marc Zyngier 
> Sent: 2019年10月1日 21:32
> To: Will Deacon 
> Cc: Justin He (Arm Technology China) ; Catalin
> Marinas ; Mark Rutland
> ; James Morse ;
> Matthew Wilcox ; Kirill A. Shutemov
> ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux...@kvack.org; Punit Agrawal
> ; Thomas Gleixner ;
> Andrew Morton ; hejia...@gmail.com; Kaly
> Xin (Arm Technology China) 
> Subject: Re: [PATCH v10 2/3] arm64: mm: implement
> arch_faults_on_old_pte() on arm64
> 
> On Tue, 1 Oct 2019 13:50:32 +0100
> Will Deacon  wrote:
> 
> > On Mon, Sep 30, 2019 at 09:57:39AM +0800, Jia He wrote:
> > > On arm64 without hardware Access Flag, copying fromuser will fail
> because
> > > the pte is old and cannot be marked young. So we always end up with
> zeroed
> > > page after fork() + CoW for pfn mappings. we don't always have a
> > > hardware-managed access flag on arm64.
> > >
> > > Hence implement arch_faults_on_old_pte on arm64 to indicate that it
> might
> > > cause page fault when accessing old pte.
> > >
> > > Signed-off-by: Jia He 
> > > Reviewed-by: Catalin Marinas 
> > > ---
> > >  arch/arm64/include/asm/pgtable.h | 14 ++
> > >  1 file changed, 14 insertions(+)
> > >
> > > diff --git a/arch/arm64/include/asm/pgtable.h
> b/arch/arm64/include/asm/pgtable.h
> > > index 7576df00eb50..e96fb82f62de 100644
> > > --- a/arch/arm64/include/asm/pgtable.h
> > > +++ b/arch/arm64/include/asm/pgtable.h
> > > @@ -885,6 +885,20 @@ static inline void update_mmu_cache(struct
> vm_area_struct *vma,
> > >  #define phys_to_ttbr(addr)   (addr)
> > >  #endif
> > >
> > > +/*
> > > + * On arm64 without hardware Access Flag, copying from user will fail
> because
> > > + * the pte is old and cannot be marked young. So we always end up
> with zeroed
> > > + * page after fork() + CoW for pfn mappings. We don't always have a
> > > + * hardware-managed access flag on arm64.
> > > + */
> > > +static inline bool arch_faults_on_old_pte(void)
> > > +{
> > > + WARN_ON(preemptible());
> > > +
> > > + return !cpu_has_hw_af();
> > > +}
> >
> > Does this work correctly in a KVM guest? (i.e. is the MMFR sanitised in
> that
> > case, despite not being the case on the host?)
> 
> Yup, all the 64bit MMFRs are trapped (HCR_EL2.TID3 is set for an
> AArch64 guest), and we return the sanitised version.
Thanks for Marc's explanation. I verified the patch series on a kvm guest (-M 
virt)
with simulated nvdimm device created by qemu. The host is ThunderX2 aarch64.

> 
> But that's an interesting remark: we're now trading an extra fault on
> CPUs that do not support HWAFDBS for a guaranteed trap for each and
> every guest under the sun that will hit the COW path...
> 
> My gut feeling is that this is going to be pretty visible. Jia, do you
> have any numbers for this kind of behaviour?
It is not a common COW path, but a COW for PFN mapping pages only.
I add a g_counter before pte_mkyoung in force_mkyoung{} when testing 
vmmalloc_fork at [1].

In this test case, it will start M fork processes and N pthreads. The default is
M=2,N=4. the g_counter is about 241, that is it will hit my patch series for 241
times.
If I set M=20 and N=40 for TEST3, the g_counter is about 1492.
  
[1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork


--
Cheers,
Justin (Jia He)

Re: [PATCH 4.4 00/36] 4.4.196-stable review

[Sasha Levin]

On Mon, Oct 07, 2019 at 04:16:51PM -0700, Guenter Roeck wrote:

On 10/7/19 4:07 PM, Sasha Levin wrote:

On Mon, Oct 07, 2019 at 04:49:51PM +0200, Greg Kroah-Hartman wrote:

On Mon, Oct 07, 2019 at 05:53:55AM -0700, Guenter Roeck wrote:

On 10/6/19 10:18 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.4.196 release.
There are 36 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
Anything received after that time might be too late.



powerpc:defconfig fails to build.

arch/powerpc/kernel/eeh_driver.c: In function ‘eeh_handle_normal_event’:
arch/powerpc/kernel/eeh_driver.c:678:2: error: implicit declaration of function 
‘eeh_for_each_pe’; did you mean ‘bus_for_each_dev’?

It has a point:

... HEAD is now at 13cac61d31df Linux 4.4.196-rc1
$ git grep eeh_for_each_pe
arch/powerpc/kernel/eeh_driver.c:   eeh_for_each_pe(pe, tmp_pe)
arch/powerpc/kernel/eeh_driver.c:   
eeh_for_each_pe(pe, tmp_pe)

Caused by commit 3fb431be8de3a ("powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER 
flag").
Full report will follow later.


Thanks for letting me know, I've dropped this from the queue now and
pushed out a -rc2 with that removed.

Sasha, I thought your builder would have caught stuff like this?


Interesting, the 4.4 build fails for me with vanilla 4.4 LTS kernel
(which is why this was missed):

 AS  arch/powerpc/kernel/systbl.o
arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1599: Warning: invalid register expression
arch/powerpc/kernel/exceptions-64s.S:1640: Warning: invalid register expression
arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
arch/powerpc/kernel/exceptions-64s.S:840: Error: attempt to move .org backwards
arch/powerpc/kernel/exceptions-64s.S:864: Error: attempt to move .org backwards
arch/powerpc/kernel/exceptions-64s.S:865: Error: attempt to move .org backwards
scripts/Makefile.build:375: recipe for target 'arch/powerpc/kernel/head_64.o' 
failed



Is this allmodconfig ? That is correct - it won't build in 4.4.y, and it would 
not be
easy to fix.


Oh, interesting, so no allmodconfig? I've disabled everything but
allmodconfig on a few architectures in an attempt to save to build time.

--
Thanks,
Sasha

RE: [PATCH] ACPI: PM: Revert "ACPI / PM: Blacklist Low Power S0 Idle _DSM for Dell XPS13 9360"

[Mario.Limonciello]

> On 26.09.19 18:08, Mario Limonciello wrote:
> > This reverts part of
> > commit 71630b7a832f ("ACPI / PM: Blacklist Low Power S0 Idle _DSM for
> > Dell XPS13 9360") to remove the S0ix blacklist for the XPS 9360.
> >
> > The problems with this system occurred in one possible NVME SSD when
> > putting system into s0ix.  As the NVME sleep behavior has been
> > adjusted in d916b1be this is expected to be now resolved.
> 
> 1.  Please add, that it was the Hynix(?) SSD.
> 2.  Please add the commit message summary of d916b1be.
> 
>  nvme-pci: use host managed power state for suspend
> 

Rafael, let me know if you want me to adjust the commit message and resubmit
or if you would just handle this task.

> > Cc: 'Paul Menzel '
> > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=196907
> > Signed-off-by: Mario Limonciello 
> 
> Tag it for the stable series? d916b1be (first tag v5.3-rc1) is not tagged for 
> stable.
> 

Although Dell arranged a lot of testing with partners I don't feel d916b1be is 
a stable
candidate.  Rafael found a corner case with regards to ASPM configuration last 
minute
in 5.3rcX, I found a another corner case related to order of events and timing 
around
PC10 entry that's getting fixed in 5.4.

> > ---
> > The particular failing configuration was reported by only ever failed
> > for Paul Menzel, so hopefully he can test on his failing system.
> 
> I successfully tested Linux 5.4-rc1+ with this commit last Friday on the Dell 
> XPS
> 13 9360.
> 
> Tested-by: Paul Menzel 
> 

Well that's great, appreciate your testing and confirmation.

Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y

[Anand Moon]

Hi Martin.

On Tue, 8 Oct 2019 at 01:40, Martin Blumenstingl
 wrote:
>
> On Mon, Oct 7, 2019 at 3:17 PM Anand Moon  wrote:
> [...]
> > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > index c9a867ac32d4..72f6a7dca0d6 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -774,7 +774,7 @@ CONFIG_MPL3115=m
> >  CONFIG_PWM=y
> >  CONFIG_PWM_BCM2835=m
> >  CONFIG_PWM_CROS_EC=m
> > -CONFIG_PWM_MESON=m
> > +CONFIG_PWM_MESON=y
> some time ago I submitted a similar patch for the 32-bit SoCs
> it turned that that pwm-meson can be built as module because the
> kernel will run without CPU DVFS as long as the clock and regulator
> drivers are returning -EPROBE_DEFER (-517)
>
> did you check whether there's some other problem like some unused
> clock which is being disabled at that moment?
> I've been hunting weird problems in the past where it turned out that
> changing kernel config bits changed the boot timing - that masked the
> original problem

OK.

>
>
> Martin

Sorry for linking this two separate issue PWM failed and microSD detect failed.
Thanks for the input, I will check if you patch help, I will try to
investigate more why it fails at my end.

Best Regards
-Anand

Re: [PATCH V2 2/3] arm64: dts: imx8mm-evk: Add i2c3 support

[Fabio Estevam]

Hi Anson,

On Mon, Oct 7, 2019 at 10:28 PM Anson Huang  wrote:
>
> Enable i2c3 for i.MX8MM EVK board.
>
> Signed-off-by: Anson Huang 

You could combine this patch with 3/3.

Re: [PATCH RFC 1/3] symlink.7: document magic-links more completely

[Aleksa Sarai]

On 2019-10-07, Jann Horn  wrote:
> On Thu, Oct 3, 2019 at 4:56 PM Aleksa Sarai  wrote:
> > Traditionally, magic-links have not been a well-understood topic in
> > Linux. Given the new changes in their semantics (related to the link
> > mode of trailing magic-links), it seems like a good opportunity to shine
> > more light on magic-links and their semantics.
> [...]
> > +++ b/man7/symlink.7
> > @@ -84,6 +84,25 @@ as they are implemented on Linux and other systems,
> >  are outlined here.
> >  It is important that site-local applications also conform to these rules,
> >  so that the user interface can be as consistent as possible.
> > +.SS Magic-links
> > +There is a special class of symlink-like objects known as "magic-links" 
> > which
> 
> I think names like that normally aren't hypenated in english, and
> instead of "magic-links", it'd be "magic links"? Just like how you
> wouldn't write "symbolic-link", but "symbolic link". But this is
> bikeshedding, and if you disagree, feel free to ignore this comment.

Looking at it now, I think you're right -- I hyphenated it here because
that's how I wrote it when documenting the feature in comments. But I
think that's because "symlink" and "magic-link" (the "abbreviated"
versions) seem to match better than "symlink" and "magic link".

I'll use "magic link" in documentation, but "magic-link" for all cases
where I would normally write "symlink".

> > +can be found in certain pseudo-filesystems such as
> > +.BR proc (5)
> > +(examples include
> > +.IR /proc/[pid]/exe " and " /proc/[pid]/fd/* .)
> > +Unlike normal symlinks, magic-links are not resolved through
> 
> nit: AFAICS symlinks are always referred to as "symbolic links"
> throughout the manpages.

:+1:

> > +pathname-expansion, but instead act as direct references to the kernel's 
> > own
> > +representation of a file handle. As such, these magic-links allow users to
> > +access files which cannot be referenced with normal paths (such as unlinked
> > +files still referenced by a running program.)
> 
> Could maybe add "and files in different mount namespaces" as another
> example here; at least for me, that's the main usecases for
> /proc/*/root.

Will do.

> [...]
> > +However, magic-links do not follow this rule. They can have a non-0777 
> > mode,
> > +which is used for permission checks when the final
> > +component of an
> > +.BR open (2)'s
> 
> Maybe leave out the "open" part, since the same restriction has to
> also apply to other syscalls operating on files, like truncate() and
> so on?

Yes (though I've just realised I hadn't implemented that -- oops.) Given
how expansive this patchset will get -- I might end up splitting it into
the magic-link stuff (and O_EMPTYPATH) and a separate series for
openat2(2) and the path resolution restrictions.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature

[PATCH V2 2/3] arm64: dts: imx8mm-evk: Add i2c3 support

[Anson Huang]

Enable i2c3 for i.MX8MM EVK board.

Signed-off-by: Anson Huang 
---
No changes.
---
 arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts 
b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
index f6d367c..9624d7d 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
@@ -244,6 +244,13 @@
};
 };
 
+ {
+   clock-frequency = <40>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c3>;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_sai3>;
@@ -355,6 +362,13 @@
>;
};
 
+   pinctrl_i2c3: i2c3grp {
+   fsl,pins = <
+   MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL  
0x41c3
+   MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA  
0x41c3
+   >;
+   };
+
pinctrl_pmic: pmicirq {
fsl,pins = <
MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3   0x41
-- 
2.7.4

[PATCH V2 3/3] arm64: dts: imx8mm-evk: Enable pca6416 on i2c3 bus

[Anson Huang]

Enable pca6416 on i.MX8MM EVK board's i2c3 bus.

Signed-off-by: Anson Huang 
---
No changes.
---
 arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts 
b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
index 9624d7d..faefb71 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
@@ -249,6 +249,13 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c3>;
status = "okay";
+
+   pca6416: gpio@20 {
+   compatible = "ti,tca6416";
+   reg = <0x20>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
 };
 
  {
-- 
2.7.4

[PATCH V2 1/3] arm64: dts: imx8mm-evk: Adjust i2c nodes following alphabetical sort

[Anson Huang]

The iomuxc node is being put at end of file because of its huge
pinctrl data. I2C devices should be placed in alphabetical sort.

Signed-off-by: Anson Huang 
---
new patch.
---
 arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 124 +--
 1 file changed, 62 insertions(+), 62 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts 
b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
index f7a15f3..f6d367c 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
@@ -94,68 +94,6 @@
};
 };
 
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_sai3>;
-   assigned-clocks = < IMX8MM_CLK_SAI3>;
-   assigned-clock-parents = < IMX8MM_AUDIO_PLL1_OUT>;
-   assigned-clock-rates = <24576000>;
-   status = "okay";
-};
-
-_pwrkey {
-   status = "okay";
-};
-
- { /* console */
-   pinctrl-names = "default";
-   pinctrl-0 = <_uart2>;
-   status = "okay";
-};
-
- {
-   dr_mode = "otg";
-   hnp-disable;
-   srp-disable;
-   adp-disable;
-   usb-role-switch;
-   status = "okay";
-
-   port {
-   usb1_drd_sw: endpoint {
-   remote-endpoint = <_dr_sw>;
-   };
-   };
-};
-
- {
-   pinctrl-names = "default", "state_100mhz", "state_200mhz";
-   pinctrl-0 = <_usdhc2>, <_usdhc2_gpio>;
-   pinctrl-1 = <_usdhc2_100mhz>, <_usdhc2_gpio>;
-   pinctrl-2 = <_usdhc2_200mhz>, <_usdhc2_gpio>;
-   cd-gpios = < 15 GPIO_ACTIVE_LOW>;
-   bus-width = <4>;
-   vmmc-supply = <_usdhc2_vmmc>;
-   status = "okay";
-};
-
- {
-   pinctrl-names = "default", "state_100mhz", "state_200mhz";
-   pinctrl-0 = <_usdhc3>;
-   pinctrl-1 = <_usdhc3_100mhz>;
-   pinctrl-2 = <_usdhc3_200mhz>;
-   bus-width = <8>;
-   non-removable;
-   status = "okay";
-};
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_wdog>;
-   fsl,ext-reset-output;
-   status = "okay";
-};
-
  {
clock-frequency = <40>;
pinctrl-names = "default";
@@ -306,6 +244,68 @@
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_sai3>;
+   assigned-clocks = < IMX8MM_CLK_SAI3>;
+   assigned-clock-parents = < IMX8MM_AUDIO_PLL1_OUT>;
+   assigned-clock-rates = <24576000>;
+   status = "okay";
+};
+
+_pwrkey {
+   status = "okay";
+};
+
+ { /* console */
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart2>;
+   status = "okay";
+};
+
+ {
+   dr_mode = "otg";
+   hnp-disable;
+   srp-disable;
+   adp-disable;
+   usb-role-switch;
+   status = "okay";
+
+   port {
+   usb1_drd_sw: endpoint {
+   remote-endpoint = <_dr_sw>;
+   };
+   };
+};
+
+ {
+   pinctrl-names = "default", "state_100mhz", "state_200mhz";
+   pinctrl-0 = <_usdhc2>, <_usdhc2_gpio>;
+   pinctrl-1 = <_usdhc2_100mhz>, <_usdhc2_gpio>;
+   pinctrl-2 = <_usdhc2_200mhz>, <_usdhc2_gpio>;
+   cd-gpios = < 15 GPIO_ACTIVE_LOW>;
+   bus-width = <4>;
+   vmmc-supply = <_usdhc2_vmmc>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default", "state_100mhz", "state_200mhz";
+   pinctrl-0 = <_usdhc3>;
+   pinctrl-1 = <_usdhc3_100mhz>;
+   pinctrl-2 = <_usdhc3_200mhz>;
+   bus-width = <8>;
+   non-removable;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_wdog>;
+   fsl,ext-reset-output;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
 
-- 
2.7.4

RE: [PATCH 1/2] arm64: dts: imx8mm-evk: Add i2c3 support

[Anson Huang]

Hi, Shawn

> On Thu, Sep 19, 2019 at 05:46:47PM +0800, Anson Huang wrote:
> > Enable i2c3 for i.MX8MM EVK board.
> >
> > Signed-off-by: Anson Huang 
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> > index f7a15f3..7758c1c 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> > @@ -306,6 +306,13 @@
> > };
> >  };
> >
> > + {
> > +   clock-frequency = <40>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_i2c3>;
> > +   status = "okay";
> > +};
> > +
> >   {
> 
> The iomuxc node is being put at end of file because of its huge pinctrl data.
> I2C devices should be placed in alphabetical sort though.  Can you please
> have a patch moving i2c1 and i2c2 to correct place first, and then add i2c3?

Done in V2.

Thanks,
Anson

Re: mount on tmpfs failing to parse context option

[Al Viro]

On Mon, Oct 07, 2019 at 05:50:31PM -0700, Hugh Dickins wrote:

[sorry for being MIA - had been sick through the last week, just digging
myself from under piles of mail; my apologies]

> (tmpfs, very tiresomely, supports a NUMA "mpol" mount option which can
> have commas in it e.g "mpol=bind:0,2": which makes all its comma parsing
> awkward.  I assume that where the new mount API commits bend over to
> accommodate that peculiarity, they end up mishandling the comma in
> the context string above.)

Dumber than that, I'm afraid.  mpol is the reason for having
->parse_monolithic() in the first place, all right, but the problem is
simply the lack of security_sb_eat_lsm_opts() call in it.

Could you check if the following fixes that one?

diff --git a/mm/shmem.c b/mm/shmem.c
index 0f7fd4a85db6..8dcc8d04cbaf 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -3482,6 +3482,12 @@ static int shmem_parse_options(struct fs_context *fc, 
void *data)
 {
char *options = data;
 
+   if (options) {
+   int err = security_sb_eat_lsm_opts(options, >security);
+   if (err)
+   return err;
+   }
+
while (options != NULL) {
char *this_char = options;
for (;;) {

RE: [PATCH 2/6] dt-bindings: Add DT binding for PCIE GEN4 EP of the layerscape

[Xiaowei Bao]

> -Original Message-
> From: Rob Herring 
> Sent: 2019年10月1日 6:22
> To: Xiaowei Bao 
> Cc: Z.q. Hou ; bhelg...@google.com;
> mark.rutl...@arm.com; shawn...@kernel.org; Leo Li
> ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h. Lian
> ; andrew.mur...@arm.com; Mingkai Hu
> ; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/6] dt-bindings: Add DT binding for PCIE GEN4 EP of the
> layerscape
> 
> On Mon, Sep 16, 2019 at 10:17:38AM +0800, Xiaowei Bao wrote:
> > Add the documentation for the Device Tree binding of the layerscape
> > PCIe GEN4 controller with EP mode.
> >
> > Signed-off-by: Xiaowei Bao 
> > ---
> >  .../bindings/pci/layerscape-pcie-gen4.txt  | 28
> +-
> >  1 file changed, 27 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
> > b/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
> > index b40fb5d..414a86c 100644
> > --- a/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
> > +++ b/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
> > @@ -3,6 +3,8 @@ NXP Layerscape PCIe Gen4 controller  This PCIe
> > controller is based on the Mobiveil PCIe IP and thus inherits all  the
> > common properties defined in mobiveil-pcie.txt.
> >
> > +HOST MODE
> > +=
> >  Required properties:
> >  - compatible: should contain the platform identifier such as:
> >"fsl,lx2160a-pcie"
> > @@ -23,7 +25,20 @@ Required properties:
> >  - msi-parent : See the generic MSI binding described in
> >Documentation/devicetree/bindings/interrupt-controller/msi.txt.
> >
> > -Example:
> > +DEVICE MODE
> > +=
> > +Required properties:
> > +- compatible: should contain the platform identifier such as:
> > +  "fsl,lx2160a-pcie-ep"
> > +- reg: base addresses and lengths of the PCIe controller register blocks.
> > +  "regs": PCIe controller registers.
> > +  "addr_space" EP device CPU address.
> > +- apio-wins: number of requested apio outbound windows.
> > +
> > +Optional Property:
> > +- max-functions: Maximum number of functions that can be configured
> (default 1).
> > +
> > +RC Example:
> >
> > pcie@340 {
> > compatible = "fsl,lx2160a-pcie";
> > @@ -50,3 +65,14 @@ Example:
> > < 0 0 3  0 0 GIC_SPI 111
> IRQ_TYPE_LEVEL_HIGH>,
> > < 0 0 4  0 0 GIC_SPI 112
> IRQ_TYPE_LEVEL_HIGH>;
> > };
> > +
> > +EP Example:
> > +
> > +   pcie_ep@340 {
> 
> pcie-endpoint@...
> 
> > +   compatible = "fsl,lx2160a-pcie-ep";
> > +   reg = <0x00 0x0340 0x0 0x0010
> > +  0x80 0x 0x8 0x>;
> > +   reg-names = "regs", "addr_space";
> > +   apio-wins = <8>;
> > +   status = "disabled";
> 
> Don't show status in examples.

Sorry, I will add it, thanks

Thanks
Xiaowei

> 
> > +   };
> > --
> > 2.9.5
> >

Re: [PATCH v7 02/13] dt-bindings: soc: Add MT8183 power dt-bindings

[Weiyi Lu]

On Wed, 2019-08-28 at 11:39 +0200, Matthias Brugger wrote:
> 
> On 28/08/2019 11:11, Weiyi Lu wrote:
> > Add power dt-bindings of MT8183 and introduces "BASIC" and
> > "SUBSYS" clock types in binding document.
> > The "BASIC" type is compatible to the original power control with
> > clock name [a-z]+[0-9]*, e.g. mm, vpu1.
> > The "SUBSYS" type is used for bus protection control with clock
> > name [a-z]+-[0-9]+, e.g. isp-0, cam-1.
> > 
> > Signed-off-by: Weiyi Lu 
> > ---
> >  .../devicetree/bindings/soc/mediatek/scpsys.txt| 14 
> >  include/dt-bindings/power/mt8183-power.h   | 26 
> > ++
> >  2 files changed, 40 insertions(+)
> >  create mode 100644 include/dt-bindings/power/mt8183-power.h
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt 
> > b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> > index 876693a..00eab7e 100644
> > --- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> > +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> > @@ -14,6 +14,7 @@ power/power_domain.txt. It provides the power domains 
> > defined in
> >  - include/dt-bindings/power/mt2701-power.h
> >  - include/dt-bindings/power/mt2712-power.h
> >  - include/dt-bindings/power/mt7622-power.h
> > +- include/dt-bindings/power/mt8183-power.h
> >  
> >  Required properties:
> >  - compatible: Should be one of:
> > @@ -25,18 +26,31 @@ Required properties:
> > - "mediatek,mt7623a-scpsys": For MT7623A SoC
> > - "mediatek,mt7629-scpsys", "mediatek,mt7622-scpsys": For MT7629 SoC
> > - "mediatek,mt8173-scpsys"
> > +   - "mediatek,mt8183-scpsys"
> >  - #power-domain-cells: Must be 1
> >  - reg: Address range of the SCPSYS unit
> >  - infracfg: must contain a phandle to the infracfg controller
> >  - clock, clock-names: clocks according to the common clock binding.
> >These are clocks which hardware needs to be
> >enabled before enabling certain power domains.
> > +  The new clock type "BASIC" belongs to the type above.
> > +  As to the new clock type "SUBSYS" needs to be
> > +  enabled before releasing bus protection.
> 
> The new clock type won't be new in a couple of month, better reword this. 
> E.g.:
> Some SoCs have to groups of clocks. BASIC clocks need to be enabled before
> enabling the corresponding power domain. SUBSYS clocks need to be enabled 
> before
> releasing the bus protection.
> 

Got it, I'll reword in next version. Many thanks.

> > Required clocks for MT2701 or MT7623: "mm", "mfg", "ethif"
> > Required clocks for MT2712: "mm", "mfg", "venc", "jpgdec", "audio", 
> > "vdec"
> > Required clocks for MT6797: "mm", "mfg", "vdec"
> > Required clocks for MT7622 or MT7629: "hif_sel"
> > Required clocks for MT7623A: "ethif"
> > Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt"
> > +   Required clocks for MT8183: BASIC: "audio", "mfg", "mm", "cam", "isp",
> > +  "vpu", "vpu1", "vpu2", "vpu3"
> > +   SUBSYS: "mm-0", "mm-1", "mm-2", "mm-3",
> > +   "mm-4", "mm-5", "mm-6", "mm-7",
> > +   "mm-8", "mm-9", "isp-0", "isp-1",
> > +   "cam-0", "cam-1", "cam-2", "cam-3",
> > +   "cam-4", "cam-5", "cam-6", "vpu-0",
> > +   "vpu-1", "vpu-2", "vpu-3", "vpu-4",
> > +   "vpu-5"
> >  
> >  Optional properties:
> >  - vdec-supply: Power supply for the vdec power domain
> > diff --git a/include/dt-bindings/power/mt8183-power.h 
> > b/include/dt-bindings/power/mt8183-power.h
> > new file mode 100644
> > index 000..5c0c8c7
> > --- /dev/null
> > +++ b/include/dt-bindings/power/mt8183-power.h
> > @@ -0,0 +1,26 @@
> > +/* SPDX-License-Identifier: GPL-2.0
> > + *
> > + * Copyright (c) 2018 MediaTek Inc.
> > + * Author: Weiyi Lu 
> > + */
> > +
> > +#ifndef _DT_BINDINGS_POWER_MT8183_POWER_H
> > +#define _DT_BINDINGS_POWER_MT8183_POWER_H
> > +
> > +#define MT8183_POWER_DOMAIN_AUDIO  0
> > +#define MT8183_POWER_DOMAIN_CONN   1
> > +#define MT8183_POWER_DOMAIN_MFG_ASYNC  2
> > +#define MT8183_POWER_DOMAIN_MFG3
> > +#define MT8183_POWER_DOMAIN_MFG_CORE0  4
> > +#define MT8183_POWER_DOMAIN_MFG_CORE1  5
> > +#define MT8183_POWER_DOMAIN_MFG_2D 6
> > +#define MT8183_POWER_DOMAIN_DISP   7
> > +#define MT8183_POWER_DOMAIN_CAM8
> > +#define MT8183_POWER_DOMAIN_ISP9
> > +#define MT8183_POWER_DOMAIN_VDEC   10
> > +#define MT8183_POWER_DOMAIN_VENC   11
> > +#define MT8183_POWER_DOMAIN_VPU_TOP12
> > +#define MT8183_POWER_DOMAIN_VPU_CORE0  13
> > +#define MT8183_POWER_DOMAIN_VPU_CORE1  14
> > +
> > +#endif /* _DT_BINDINGS_POWER_MT8183_POWER_H */
> > 

RE: [PATCH v4 11/11] misc: pci_endpoint_test: Add LS1088a in pci_device_id table

[Xiaowei Bao]

> -Original Message-
> From: Andrew Murray 
> Sent: 2019年9月30日 22:57
> To: Xiaowei Bao 
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org
> Subject: Re: [PATCH v4 11/11] misc: pci_endpoint_test: Add LS1088a in
> pci_device_id table
> 
> On Tue, Sep 24, 2019 at 10:18:49AM +0800, Xiaowei Bao wrote:
> > Add LS1088a in pci_device_id table so that pci-epf-test can be used
> > for testing PCIe EP in LS1088a.
> >
> > Signed-off-by: Xiaowei Bao 
> > ---
> > v2:
> >  - No change.
> > v3:
> >  - No change.
> > v4:
> >  - Use a maco to define the LS1088a device ID.
> >
> >  drivers/misc/pci_endpoint_test.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/misc/pci_endpoint_test.c
> > b/drivers/misc/pci_endpoint_test.c
> > index 6e208a0..8c222a6 100644
> > --- a/drivers/misc/pci_endpoint_test.c
> > +++ b/drivers/misc/pci_endpoint_test.c
> > @@ -65,6 +65,7 @@
> >  #define PCI_ENDPOINT_TEST_IRQ_NUMBER   0x28
> >
> >  #define PCI_DEVICE_ID_TI_AM654 0xb00c
> > +#define PCI_DEVICE_ID_LS1088A  0x80c0
> 
> Reviewed-by: Andrew Murray 

Thanks Andrew.

> 
> >
> >  #define is_am654_pci_dev(pdev) \
> > ((pdev)->device == PCI_DEVICE_ID_TI_AM654) @@ -793,6 +794,7
> @@
> > static const struct pci_device_id pci_endpoint_test_tbl[] = {
> > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x) },
> > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x) },
> > { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x81c0) },
> > +   { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, PCI_DEVICE_ID_LS1088A) },
> > { PCI_DEVICE_DATA(SYNOPSYS, EDDA, NULL) },
> > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_AM654),
> >   .driver_data = (kernel_ulong_t)_data
> > --
> > 2.9.5
> >

[PATCH net-next 0/6] net: hns3: add some new feature

[Huazhong Tan]

This patch-set includes some new features for the HNS3 ethernet
controller driver.

[patch 01/06] adds support for configuring VF link status on the host.

[patch 02/06] adds support for configuring VF spoof check.

[patch 03/06] adds support for configuring VF trust.

[patch 04/06] adds support for configuring VF bandwidth on the host.

[patch 05/06] adds support for configuring VF MAC on the host.

[patch 06/06] adds support for tx-scatter-gather-fraglist.

Huazhong Tan (1):
  net: hns3: add support for configuring VF MAC from the host

Jian Shen (2):
  net: hns3: add support for spoof check setting
  net: hns3: add support for setting VF trust

Yonglong Liu (1):
  net: hns3: add support for configuring bandwidth of VF on the host

Yufeng Mo (1):
  net: hns3: add support for setting VF link status on the host

Yunsheng Lin (1):
  net: hns3: support tx-scatter-gather-fraglist feature

 drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h|   1 +
 drivers/net/ethernet/hisilicon/hns3/hnae3.h|  23 ++
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 355 -
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.h|  12 +-
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h |   5 +-
 .../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c |  79 
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 434 -
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h|  17 +-
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c |  85 +++-
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c  |  43 ++
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h  |   8 +
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c  |  64 +--
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h  |   1 +
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c   |  12 +
 14 files changed, 986 insertions(+), 153 deletions(-)

-- 
2.7.4

[PATCH net-next 6/6] net: hns3: support tx-scatter-gather-fraglist feature

[Huazhong Tan]

From: Yunsheng Lin 

The hardware supports up to 8 TX BD for non-tso skb and up to
63 TX BD for TSO skb. Currently, the hns3 driver supports RX skb
with fraglist when HW GRO is enabled, when the stack forwards a
RX skb with fraglist, the stack need to linearize the skb before
sending to other interface without TX fraglist support.

This patch adds support for TX fraglist. The performance increases
from 1 GByte to 1.5 GByte for one iperf TCP stream during
forwarding test after this patch. BTW, the minimum BD number of
ring should be updated to 72 for supporting TX fraglist.

This patch also changes the error handling of some function that
called by hns3_fill_desc, which returns BD num when there is no
error, change some macro to more meaningful name.

Signed-off-by: Yunsheng Lin 
Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 249 +++-
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.h |  12 +-
 2 files changed, 168 insertions(+), 93 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 4e304b4..6e0b261 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -681,7 +681,7 @@ static int hns3_set_tso(struct sk_buff *skb, u32 *paylen,
return 0;
 
ret = skb_cow_head(skb, 0);
-   if (unlikely(ret))
+   if (unlikely(ret < 0))
return ret;
 
l3.hdr = skb_network_header(skb);
@@ -962,14 +962,6 @@ static int hns3_set_l2l3l4(struct sk_buff *skb, u8 
ol4_proto,
return 0;
 }
 
-static void hns3_set_txbd_baseinfo(u16 *bdtp_fe_sc_vld_ra_ri, int frag_end)
-{
-   /* Config bd buffer end */
-   if (!!frag_end)
-   hns3_set_field(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_FE_B, 1U);
-   hns3_set_field(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_VLD_B, 1U);
-}
-
 static int hns3_handle_vtags(struct hns3_enet_ring *tx_ring,
 struct sk_buff *skb)
 {
@@ -1062,7 +1054,7 @@ static int hns3_fill_skb_desc(struct hns3_enet_ring *ring,
skb_reset_mac_len(skb);
 
ret = hns3_get_l4_protocol(skb, _proto, _proto);
-   if (unlikely(ret)) {
+   if (unlikely(ret < 0)) {
u64_stats_update_begin(>syncp);
ring->stats.tx_l4_proto_err++;
u64_stats_update_end(>syncp);
@@ -1072,7 +1064,7 @@ static int hns3_fill_skb_desc(struct hns3_enet_ring *ring,
ret = hns3_set_l2l3l4(skb, ol4_proto, il4_proto,
  _cs_vlan_tso,
  _type_vlan_len_msec);
-   if (unlikely(ret)) {
+   if (unlikely(ret < 0)) {
u64_stats_update_begin(>syncp);
ring->stats.tx_l2l3l4_err++;
u64_stats_update_end(>syncp);
@@ -1081,7 +1073,7 @@ static int hns3_fill_skb_desc(struct hns3_enet_ring *ring,
 
ret = hns3_set_tso(skb, , ,
   _cs_vlan_tso);
-   if (unlikely(ret)) {
+   if (unlikely(ret < 0)) {
u64_stats_update_begin(>syncp);
ring->stats.tx_tso_err++;
u64_stats_update_end(>syncp);
@@ -1102,9 +1094,10 @@ static int hns3_fill_skb_desc(struct hns3_enet_ring 
*ring,
 }
 
 static int hns3_fill_desc(struct hns3_enet_ring *ring, void *priv,
- unsigned int size, int frag_end,
- enum hns_desc_type type)
+ unsigned int size, enum hns_desc_type type)
 {
+#define HNS3_LIKELY_BD_NUM 1
+
struct hns3_desc_cb *desc_cb = >desc_cb[ring->next_to_use];
struct hns3_desc *desc = >desc[ring->next_to_use];
struct device *dev = ring_to_dev(ring);
@@ -1118,7 +,7 @@ static int hns3_fill_desc(struct hns3_enet_ring *ring, 
void *priv,
int ret;
 
ret = hns3_fill_skb_desc(ring, skb, desc);
-   if (unlikely(ret))
+   if (unlikely(ret < 0))
return ret;
 
dma = dma_map_single(dev, skb->data, size, DMA_TO_DEVICE);
@@ -1137,19 +1130,16 @@ static int hns3_fill_desc(struct hns3_enet_ring *ring, 
void *priv,
desc_cb->length = size;
 
if (likely(size <= HNS3_MAX_BD_SIZE)) {
-   u16 bdtp_fe_sc_vld_ra_ri = 0;
-
desc_cb->priv = priv;
desc_cb->dma = dma;
desc_cb->type = type;
desc->addr = cpu_to_le64(dma);
desc->tx.send_size = cpu_to_le16(size);
-   hns3_set_txbd_baseinfo(_fe_sc_vld_ra_ri, frag_end);
desc->tx.bdtp_fe_sc_vld_ra_ri =
-   cpu_to_le16(bdtp_fe_sc_vld_ra_ri);
+   cpu_to_le16(BIT(HNS3_TXD_VLD_B));
 

[PATCH net-next 3/6] net: hns3: add support for setting VF trust

[Huazhong Tan]

From: Jian Shen 

This patch adds supports for setting VF trust by host. If specified
VF is trusted, then it can enable promisc(include allmulti mode).
If a trusted VF enabled promisc, and being untrusted, host will
disable promisc mode for this VF.

For VF will update its promisc mode from set_rx_mode now, so it's
unnecessary to set broadcst promisc mode when initialization or
reset.

Signed-off-by: Jian Shen 
Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h|  1 +
 drivers/net/ethernet/hisilicon/hns3/hnae3.h|  4 ++
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 11 
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h |  3 --
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 60 ++
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h|  8 +--
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 36 +++--
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c  | 34 +---
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c   | 12 +
 9 files changed, 129 insertions(+), 40 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h 
b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
index f8a87f8..0059d44 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
@@ -45,6 +45,7 @@ enum HCLGE_MBX_OPCODE {
HCLGE_MBX_GET_LINK_MODE,/* (VF -> PF) get the link mode of pf */
HCLGE_MBX_PUSH_VLAN_INFO,   /* (PF -> VF) push port base vlan */
HCLGE_MBX_GET_MEDIA_TYPE,   /* (VF -> PF) get media type */
+   HCLGE_MBX_PUSH_PROMISC_INFO,/* (PF -> VF) push vf promisc info */
 
HCLGE_MBX_GET_VF_FLR_STATUS = 200, /* (M7 -> PF) get vf reset status */
HCLGE_MBX_PUSH_LINK_STATUS, /* (M7 -> PF) get port link status */
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h 
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index b7b8169..ef56f37 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -370,6 +370,9 @@ struct hnae3_ae_dev {
  *   Set VF link status
  * set_vf_spoofchk
  *   Enable/disable spoof check for specified vf
+ * set_vf_trust
+ *   Enable/disable trust for specified vf, if the vf being trusted, then
+ *   it can enable promisc mode
  */
 struct hnae3_ae_ops {
int (*init_ae_dev)(struct hnae3_ae_dev *ae_dev);
@@ -541,6 +544,7 @@ struct hnae3_ae_ops {
 int link_state);
int (*set_vf_spoofchk)(struct hnae3_handle *handle, int vf,
   bool enable);
+   int (*set_vf_trust)(struct hnae3_handle *handle, int vf, bool enable);
 };
 
 struct hnae3_dcb_ops {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 4a5404e..5c50555 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1656,6 +1656,16 @@ static int hns3_set_vf_spoofchk(struct net_device 
*netdev, int vf, bool enable)
return handle->ae_algo->ops->set_vf_spoofchk(handle, vf, enable);
 }
 
+static int hns3_set_vf_trust(struct net_device *netdev, int vf, bool enable)
+{
+   struct hnae3_handle *handle = hns3_get_handle(netdev);
+
+   if (!handle->ae_algo->ops->set_vf_trust)
+   return -EOPNOTSUPP;
+
+   return handle->ae_algo->ops->set_vf_trust(handle, vf, enable);
+}
+
 static int hns3_nic_change_mtu(struct net_device *netdev, int new_mtu)
 {
struct hnae3_handle *h = hns3_get_handle(netdev);
@@ -1856,6 +1866,7 @@ static const struct net_device_ops hns3_nic_netdev_ops = {
.ndo_vlan_rx_kill_vid   = hns3_vlan_rx_kill_vid,
.ndo_set_vf_vlan= hns3_ndo_set_vf_vlan,
.ndo_set_vf_spoofchk= hns3_set_vf_spoofchk,
+   .ndo_set_vf_trust   = hns3_set_vf_trust,
 #ifdef CONFIG_RFS_ACCEL
.ndo_rx_flow_steer  = hns3_rx_flow_steer,
 #endif
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 4821fe0..265695a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -1090,9 +1090,6 @@ void hclge_cmd_setup_basic_desc(struct hclge_desc *desc,
enum hclge_opcode_type opcode, bool is_read);
 void hclge_cmd_reuse_desc(struct hclge_desc *desc, bool is_read);
 
-int hclge_cmd_set_promisc_mode(struct hclge_dev *hdev,
-  struct hclge_promisc_param *param);
-
 enum hclge_cmd_status hclge_cmd_mdio_write(struct hclge_hw *hw,
   struct hclge_desc *desc);
 enum hclge_cmd_status hclge_cmd_mdio_read(struct hclge_hw *hw,
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 7c72862..c63f723 100644
--- 

[PATCH net-next 1/6] net: hns3: add support for setting VF link status on the host

[Huazhong Tan]

From: Yufeng Mo 

This patch adds support to configure VF link properties.
The options are auto, enable, and disable. Even if the PF
is down, the communication between VFs will be normal
if the VFs are set to enable. The commands are as follows:

'ip link set  vf  state '
change the VF status

'ip link show'
show the setting status

Signed-off-by: Yufeng Mo 
Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hnae3.h|  8 +++
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 24 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 57 ++
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h|  6 +++
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 17 ++-
 5 files changed, 111 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h 
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index c4b7bf8..1fc3728 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -364,6 +364,10 @@ struct hnae3_ae_dev {
  *   Enable/disable HW GRO
  * add_arfs_entry
  *   Check the 5-tuples of flow, and create flow director rule
+ * get_vf_config
+ *   Get the VF configuration setting by the host
+ * set_vf_link_state
+ *   Set VF link status
  */
 struct hnae3_ae_ops {
int (*init_ae_dev)(struct hnae3_ae_dev *ae_dev);
@@ -529,6 +533,10 @@ struct hnae3_ae_ops {
int (*mac_connect_phy)(struct hnae3_handle *handle);
void (*mac_disconnect_phy)(struct hnae3_handle *handle);
void (*restore_vlan_table)(struct hnae3_handle *handle);
+   int (*get_vf_config)(struct hnae3_handle *handle, int vf,
+struct ifla_vf_info *ivf);
+   int (*set_vf_link_state)(struct hnae3_handle *handle, int vf,
+int link_state);
 };
 
 struct hnae3_dcb_ops {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 616cad0..2136323 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1805,6 +1805,28 @@ static int hns3_rx_flow_steer(struct net_device *dev, 
const struct sk_buff *skb,
 }
 #endif
 
+static int hns3_nic_get_vf_config(struct net_device *ndev, int vf,
+ struct ifla_vf_info *ivf)
+{
+   struct hnae3_handle *h = hns3_get_handle(ndev);
+
+   if (!h->ae_algo->ops->get_vf_config)
+   return -EOPNOTSUPP;
+
+   return h->ae_algo->ops->get_vf_config(h, vf, ivf);
+}
+
+static int hns3_nic_set_vf_link_state(struct net_device *ndev, int vf,
+ int link_state)
+{
+   struct hnae3_handle *h = hns3_get_handle(ndev);
+
+   if (!h->ae_algo->ops->set_vf_link_state)
+   return -EOPNOTSUPP;
+
+   return h->ae_algo->ops->set_vf_link_state(h, vf, link_state);
+}
+
 static const struct net_device_ops hns3_nic_netdev_ops = {
.ndo_open   = hns3_nic_net_open,
.ndo_stop   = hns3_nic_net_stop,
@@ -1823,6 +1845,8 @@ static const struct net_device_ops hns3_nic_netdev_ops = {
 #ifdef CONFIG_RFS_ACCEL
.ndo_rx_flow_steer  = hns3_rx_flow_steer,
 #endif
+   .ndo_get_vf_config  = hns3_nic_get_vf_config,
+   .ndo_set_vf_link_state  = hns3_nic_set_vf_link_state,
 
 };
 
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index fd7f943..931a311 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -55,6 +55,8 @@
 
 #define HCLGE_LINK_STATUS_MS   10
 
+#define HCLGE_VF_VPORT_START_NUM   1
+
 static int hclge_set_mac_mtu(struct hclge_dev *hdev, int new_mps);
 static int hclge_init_vlan_config(struct hclge_dev *hdev);
 static void hclge_sync_vlan_filter(struct hclge_dev *hdev);
@@ -1633,6 +1635,7 @@ static int hclge_alloc_vport(struct hclge_dev *hdev)
for (i = 0; i < num_vport; i++) {
vport->back = hdev;
vport->vport_id = i;
+   vport->vf_info.link_state = IFLA_VF_LINK_STATE_AUTO;
vport->mps = HCLGE_MAC_DEFAULT_FRAME;
vport->port_base_vlan_cfg.state = HNAE3_PORT_BASE_VLAN_DISABLE;
vport->rxvlan_cfg.rx_vlan_offload_en = true;
@@ -2853,6 +2856,58 @@ static int hclge_get_status(struct hnae3_handle *handle)
return hdev->hw.mac.link;
 }
 
+static struct hclge_vport *hclge_get_vf_vport(struct hclge_dev *hdev, int vf)
+{
+   if (pci_num_vf(hdev->pdev) == 0) {
+   dev_err(>pdev->dev,
+   "SRIOV is disabled, can not get vport(%d) info.\n", vf);
+   return NULL;
+   }
+
+   if (vf < 0 || vf >= pci_num_vf(hdev->pdev)) {
+   dev_err(>pdev->dev,
+   "vf id(%d) is out of range(0 <= vfid < %d)\n",
+   

[PATCH net-next 4/6] net: hns3: add support for configuring bandwidth of VF on the host

[Huazhong Tan]

From: Yonglong Liu 

This patch adds support for configuring bandwidth of VF on the host
for HNS3 drivers.

Signed-off-by: Yonglong Liu 
Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hnae3.h|   4 +
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c|  14 ++-
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h |   2 +-
 .../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c |  79 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 130 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h|   2 +
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c  |  43 +++
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h  |   8 ++
 8 files changed, 280 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h 
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index ef56f37..1202bbc 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -373,6 +373,8 @@ struct hnae3_ae_dev {
  * set_vf_trust
  *   Enable/disable trust for specified vf, if the vf being trusted, then
  *   it can enable promisc mode
+ * set_vf_rate
+ *   Set the max tx rate of specified vf.
  */
 struct hnae3_ae_ops {
int (*init_ae_dev)(struct hnae3_ae_dev *ae_dev);
@@ -545,6 +547,8 @@ struct hnae3_ae_ops {
int (*set_vf_spoofchk)(struct hnae3_handle *handle, int vf,
   bool enable);
int (*set_vf_trust)(struct hnae3_handle *handle, int vf, bool enable);
+   int (*set_vf_rate)(struct hnae3_handle *handle, int vf,
+  int min_tx_rate, int max_tx_rate, bool force);
 };
 
 struct hnae3_dcb_ops {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 5c50555..5a8c316 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1850,6 +1850,18 @@ static int hns3_nic_set_vf_link_state(struct net_device 
*ndev, int vf,
return h->ae_algo->ops->set_vf_link_state(h, vf, link_state);
 }
 
+static int hns3_nic_set_vf_rate(struct net_device *ndev, int vf,
+   int min_tx_rate, int max_tx_rate)
+{
+   struct hnae3_handle *h = hns3_get_handle(ndev);
+
+   if (!h->ae_algo->ops->set_vf_rate)
+   return -EOPNOTSUPP;
+
+   return h->ae_algo->ops->set_vf_rate(h, vf, min_tx_rate, max_tx_rate,
+   false);
+}
+
 static const struct net_device_ops hns3_nic_netdev_ops = {
.ndo_open   = hns3_nic_net_open,
.ndo_stop   = hns3_nic_net_stop,
@@ -1872,7 +1884,7 @@ static const struct net_device_ops hns3_nic_netdev_ops = {
 #endif
.ndo_get_vf_config  = hns3_nic_get_vf_config,
.ndo_set_vf_link_state  = hns3_nic_set_vf_link_state,
-
+   .ndo_set_vf_rate= hns3_nic_set_vf_rate,
 };
 
 bool hns3_is_phys_func(struct pci_dev *pdev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 265695a..3578832 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -244,7 +244,7 @@ enum hclge_opcode_type {
/* QCN commands */
HCLGE_OPC_QCN_MOD_CFG   = 0x1A01,
HCLGE_OPC_QCN_GRP_TMPLT_CFG = 0x1A02,
-   HCLGE_OPC_QCN_SHAPPING_IR_CFG   = 0x1A03,
+   HCLGE_OPC_QCN_SHAPPING_CFG  = 0x1A03,
HCLGE_OPC_QCN_SHAPPING_BS_CFG   = 0x1A04,
HCLGE_OPC_QCN_QSET_LINK_CFG = 0x1A05,
HCLGE_OPC_QCN_RP_STATUS_GET = 0x1A06,
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
index d0128d7..0ccc8e7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
@@ -1110,6 +1110,82 @@ static void hclge_dbg_dump_mac_tnl_status(struct 
hclge_dev *hdev)
}
 }
 
+static void hclge_dbg_dump_qs_shaper_single(struct hclge_dev *hdev, u16 qsid)
+{
+   struct hclge_qs_shapping_cmd *shap_cfg_cmd;
+   u8 ir_u, ir_b, ir_s, bs_b, bs_s;
+   struct hclge_desc desc;
+   u32 shapping_para;
+   int ret;
+
+   hclge_cmd_setup_basic_desc(, HCLGE_OPC_QCN_SHAPPING_CFG, true);
+
+   shap_cfg_cmd = (struct hclge_qs_shapping_cmd *)desc.data;
+   shap_cfg_cmd->qs_id = cpu_to_le16(qsid);
+
+   ret = hclge_cmd_send(>hw, , 1);
+   if (ret) {
+   dev_err(>pdev->dev,
+   "qs%u failed to get tx_rate, ret=%d\n",
+   qsid, ret);
+   return;
+   }
+
+   shapping_para = le32_to_cpu(shap_cfg_cmd->qs_shapping_para);
+   ir_b = hclge_tm_get_field(shapping_para, IR_B);
+   ir_u = hclge_tm_get_field(shapping_para, IR_U);
+   ir_s = 

[PATCH net-next 5/6] net: hns3: add support for configuring VF MAC from the host

[Huazhong Tan]

This patch adds support of configuring VF MAC from the host
for the HNS3 driver.

BTW, the parameter init in the hns3_init_mac_addr is
unnecessary now, since the MAC address will not read from
NCL_CONFIG when doing reset, so it should be removed,
otherwise it will affect VF's MAC address initialization.

Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hnae3.h|  3 ++
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 43 ---
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 62 ++
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 29 ++
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c  | 28 +-
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h  |  1 +
 6 files changed, 158 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h 
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 1202bbc..c15d7fc 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -375,6 +375,8 @@ struct hnae3_ae_dev {
  *   it can enable promisc mode
  * set_vf_rate
  *   Set the max tx rate of specified vf.
+ * set_vf_mac
+ *   Configure the default MAC for specified VF
  */
 struct hnae3_ae_ops {
int (*init_ae_dev)(struct hnae3_ae_dev *ae_dev);
@@ -549,6 +551,7 @@ struct hnae3_ae_ops {
int (*set_vf_trust)(struct hnae3_handle *handle, int vf, bool enable);
int (*set_vf_rate)(struct hnae3_handle *handle, int vf,
   int min_tx_rate, int max_tx_rate, bool force);
+   int (*set_vf_mac)(struct hnae3_handle *handle, int vf, u8 *p);
 };
 
 struct hnae3_dcb_ops {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 5a8c316..4e304b4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1413,6 +1413,16 @@ static int hns3_nic_net_set_mac_address(struct 
net_device *netdev, void *p)
return 0;
}
 
+   /* For VF device, if there is a perm_addr, then the user will not
+* be allowed to change the address.
+*/
+   if (!hns3_is_phys_func(h->pdev) &&
+   !is_zero_ether_addr(netdev->perm_addr)) {
+   netdev_err(netdev, "has permanent MAC %pM, user MAC %pM not 
allow\n",
+  netdev->perm_addr, mac_addr->sa_data);
+   return -EPERM;
+   }
+
ret = h->ae_algo->ops->set_mac_addr(h, mac_addr->sa_data, false);
if (ret) {
netdev_err(netdev, "set_mac_address fail, ret=%d!\n", ret);
@@ -1862,6 +1872,23 @@ static int hns3_nic_set_vf_rate(struct net_device *ndev, 
int vf,
false);
 }
 
+static int hns3_nic_set_vf_mac(struct net_device *netdev, int vf_id, u8 *mac)
+{
+   struct hnae3_handle *h = hns3_get_handle(netdev);
+
+   if (!h->ae_algo->ops->set_vf_mac)
+   return -EOPNOTSUPP;
+
+   if (is_multicast_ether_addr(mac)) {
+   netdev_err(netdev,
+  "Invalid MAC:%pM specified. Could not set MAC\n",
+  mac);
+   return -EINVAL;
+   }
+
+   return h->ae_algo->ops->set_vf_mac(h, vf_id, mac);
+}
+
 static const struct net_device_ops hns3_nic_netdev_ops = {
.ndo_open   = hns3_nic_net_open,
.ndo_stop   = hns3_nic_net_stop,
@@ -1885,6 +1912,7 @@ static const struct net_device_ops hns3_nic_netdev_ops = {
.ndo_get_vf_config  = hns3_nic_get_vf_config,
.ndo_set_vf_link_state  = hns3_nic_set_vf_link_state,
.ndo_set_vf_rate= hns3_nic_set_vf_rate,
+   .ndo_set_vf_mac = hns3_nic_set_vf_mac,
 };
 
 bool hns3_is_phys_func(struct pci_dev *pdev)
@@ -3804,23 +3832,24 @@ int hns3_uninit_all_ring(struct hns3_nic_priv *priv)
 }
 
 /* Set mac addr if it is configured. or leave it to the AE driver */
-static int hns3_init_mac_addr(struct net_device *netdev, bool init)
+static int hns3_init_mac_addr(struct net_device *netdev)
 {
struct hns3_nic_priv *priv = netdev_priv(netdev);
struct hnae3_handle *h = priv->ae_handle;
u8 mac_addr_temp[ETH_ALEN];
int ret = 0;
 
-   if (h->ae_algo->ops->get_mac_addr && init) {
+   if (h->ae_algo->ops->get_mac_addr)
h->ae_algo->ops->get_mac_addr(h, mac_addr_temp);
-   ether_addr_copy(netdev->dev_addr, mac_addr_temp);
-   }
 
/* Check if the MAC address is valid, if not get a random one */
-   if (!is_valid_ether_addr(netdev->dev_addr)) {
+   if (!is_valid_ether_addr(mac_addr_temp)) {
eth_hw_addr_random(netdev);
dev_warn(priv->dev, "using random MAC address %pM\n",
 netdev->dev_addr);
+   } else {
+   ether_addr_copy(netdev->dev_addr, mac_addr_temp);
+   

[PATCH net-next 2/6] net: hns3: add support for spoof check setting

[Huazhong Tan]

From: Jian Shen 

This patch adds support for spoof check configuration for VFs.
When it is enabled, "spoof checking" is done for both mac address
and VLAN. For each VF, the HW ensures that the source MAC address
(or VLAN) of every outgoing packet exists in the MAC-list (or
VLAN-list) configured for RX filtering for that VF. If not,
the packet is dropped.

Signed-off-by: Jian Shen 
Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hnae3.h|   4 +
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c|  14 +++
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 125 +++--
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h|   1 +
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c |   3 +
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c  |   2 +-
 6 files changed, 140 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h 
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 1fc3728..b7b8169 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -368,6 +368,8 @@ struct hnae3_ae_dev {
  *   Get the VF configuration setting by the host
  * set_vf_link_state
  *   Set VF link status
+ * set_vf_spoofchk
+ *   Enable/disable spoof check for specified vf
  */
 struct hnae3_ae_ops {
int (*init_ae_dev)(struct hnae3_ae_dev *ae_dev);
@@ -537,6 +539,8 @@ struct hnae3_ae_ops {
 struct ifla_vf_info *ivf);
int (*set_vf_link_state)(struct hnae3_handle *handle, int vf,
 int link_state);
+   int (*set_vf_spoofchk)(struct hnae3_handle *handle, int vf,
+  bool enable);
 };
 
 struct hnae3_dcb_ops {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 2136323..4a5404e 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1643,6 +1643,19 @@ static int hns3_ndo_set_vf_vlan(struct net_device 
*netdev, int vf, u16 vlan,
return ret;
 }
 
+static int hns3_set_vf_spoofchk(struct net_device *netdev, int vf, bool enable)
+{
+   struct hnae3_handle *handle = hns3_get_handle(netdev);
+
+   if (hns3_nic_resetting(netdev))
+   return -EBUSY;
+
+   if (!handle->ae_algo->ops->set_vf_spoofchk)
+   return -EOPNOTSUPP;
+
+   return handle->ae_algo->ops->set_vf_spoofchk(handle, vf, enable);
+}
+
 static int hns3_nic_change_mtu(struct net_device *netdev, int new_mtu)
 {
struct hnae3_handle *h = hns3_get_handle(netdev);
@@ -1842,6 +1855,7 @@ static const struct net_device_ops hns3_nic_netdev_ops = {
.ndo_vlan_rx_add_vid= hns3_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid   = hns3_vlan_rx_kill_vid,
.ndo_set_vf_vlan= hns3_ndo_set_vf_vlan,
+   .ndo_set_vf_spoofchk= hns3_set_vf_spoofchk,
 #ifdef CONFIG_RFS_ACCEL
.ndo_rx_flow_steer  = hns3_rx_flow_steer,
 #endif
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 931a311..7c72862 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2888,6 +2888,7 @@ static int hclge_get_vf_config(struct hnae3_handle 
*handle, int vf,
 
ivf->vf = vf;
ivf->linkstate = vport->vf_info.link_state;
+   ivf->spoofchk = vport->vf_info.spoofchk;
ether_addr_copy(ivf->mac, vport->vf_info.mac);
 
return 0;
@@ -7619,6 +7620,8 @@ static int hclge_set_vf_vlan_common(struct hclge_dev 
*hdev, u16 vfid,
__be16 proto)
 {
 #define HCLGE_MAX_VF_BYTES  16
+
+   struct hclge_vport *vport = >vport[vfid];
struct hclge_vlan_filter_vf_cfg_cmd *req0;
struct hclge_vlan_filter_vf_cfg_cmd *req1;
struct hclge_desc desc[2];
@@ -7627,10 +7630,18 @@ static int hclge_set_vf_vlan_common(struct hclge_dev 
*hdev, u16 vfid,
int ret;
 
/* if vf vlan table is full, firmware will close vf vlan filter, it
-* is unable and unnecessary to add new vlan id to vf vlan filter
+* is unable and unnecessary to add new vlan id to vf vlan filter.
+* If spoof check is enable, and vf vlan is full, it shouldn't add
+* new vlan, because tx packets with these vlan id will be dropped.
 */
-   if (test_bit(vfid, hdev->vf_vlan_full) && !is_kill)
+   if (test_bit(vfid, hdev->vf_vlan_full) && !is_kill) {
+   if (vport->vf_info.spoofchk && vlan) {
+   dev_err(>pdev->dev,
+   "Can't add vlan due to spoof check is on and vf 
vlan table is full\n");
+   return -EPERM;
+   }
return 0;
+   }
 
hclge_cmd_setup_basic_desc([0],
   

RE: [PATCH v10 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()

[Justin He (Arm Technology China)]

Hi Will and Marc
Sorry for the late response, just came back from a vacation.

> -Original Message-
> From: Marc Zyngier 
> Sent: 2019年10月1日 21:19
> To: Will Deacon 
> Cc: Justin He (Arm Technology China) ; Catalin
> Marinas ; Mark Rutland
> ; James Morse ;
> Matthew Wilcox ; Kirill A. Shutemov
> ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux...@kvack.org; Punit Agrawal
> ; Thomas Gleixner ;
> Andrew Morton ; hejia...@gmail.com; Kaly
> Xin (Arm Technology China) 
> Subject: Re: [PATCH v10 1/3] arm64: cpufeature: introduce helper
> cpu_has_hw_af()
>
> On Tue, 1 Oct 2019 13:54:47 +0100
> Will Deacon  wrote:
>
> > On Mon, Sep 30, 2019 at 09:57:38AM +0800, Jia He wrote:
> > > We unconditionally set the HW_AFDBM capability and only enable it on
> > > CPUs which really have the feature. But sometimes we need to know
> > > whether this cpu has the capability of HW AF. So decouple AF from
> > > DBM by new helper cpu_has_hw_af().
> > >
> > > Signed-off-by: Jia He 
> > > Suggested-by: Suzuki Poulose 
> > > Reviewed-by: Catalin Marinas 
> > > ---
> > >  arch/arm64/include/asm/cpufeature.h | 10 ++
> > >  1 file changed, 10 insertions(+)
> > >
> > > diff --git a/arch/arm64/include/asm/cpufeature.h
> b/arch/arm64/include/asm/cpufeature.h
> > > index 9cde5d2e768f..949bc7c85030 100644
> > > --- a/arch/arm64/include/asm/cpufeature.h
> > > +++ b/arch/arm64/include/asm/cpufeature.h
> > > @@ -659,6 +659,16 @@ static inline u32
> id_aa64mmfr0_parange_to_phys_shift(int parange)
> > >   default: return CONFIG_ARM64_PA_BITS;
> > >   }
> > >  }
> > > +
> > > +/* Check whether hardware update of the Access flag is supported */
> > > +static inline bool cpu_has_hw_af(void)
> > > +{
> > > + if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM))
> > > + return read_cpuid(ID_AA64MMFR1_EL1) & 0xf;
> >
> > 0xf? I think we should have a mask in sysreg.h for this constant.
>
> We don't have the mask, but we certainly have the shift.
>
> GENMASK(ID_AA64MMFR1_HADBS_SHIFT + 3,
> ID_AA64MMFR1_HADBS_SHIFT) is a bit
> of a mouthful though. Ideally, we'd have a helper for that.
>
Ok, I will implement the helper if there isn't so far.
And then replace the 0xf with it.


--
Cheers,
Justin (Jia He)


>   M.
> --
> Without deviation from the norm, progress is not possible.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH v2] KVM: Don't shrink/grow vCPU halt_poll_ns if host side polling is disabled

[Wanpeng Li]

ping,
On Sun, 29 Sep 2019 at 09:07, Wanpeng Li  wrote:
>
> From: Wanpeng Li 
>
> Don't waste cycles to shrink/grow vCPU halt_poll_ns if host
> side polling is disabled.
>
> Acked-by: Marcelo Tosatti 
> Cc: Marcelo Tosatti 
> Signed-off-by: Wanpeng Li 
> ---
> v1 -> v2:
>  * fix coding style
>
>  virt/kvm/kvm_main.c | 29 -
>  1 file changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index e6de315..9d5eed9 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2359,20 +2359,23 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
> kvm_arch_vcpu_unblocking(vcpu);
> block_ns = ktime_to_ns(cur) - ktime_to_ns(start);
>
> -   if (!vcpu_valid_wakeup(vcpu))
> -   shrink_halt_poll_ns(vcpu);
> -   else if (halt_poll_ns) {
> -   if (block_ns <= vcpu->halt_poll_ns)
> -   ;
> -   /* we had a long block, shrink polling */
> -   else if (vcpu->halt_poll_ns && block_ns > halt_poll_ns)
> +   if (!kvm_arch_no_poll(vcpu)) {
> +   if (!vcpu_valid_wakeup(vcpu)) {
> shrink_halt_poll_ns(vcpu);
> -   /* we had a short halt and our poll time is too small */
> -   else if (vcpu->halt_poll_ns < halt_poll_ns &&
> -   block_ns < halt_poll_ns)
> -   grow_halt_poll_ns(vcpu);
> -   } else
> -   vcpu->halt_poll_ns = 0;
> +   } else if (halt_poll_ns) {
> +   if (block_ns <= vcpu->halt_poll_ns)
> +   ;
> +   /* we had a long block, shrink polling */
> +   else if (vcpu->halt_poll_ns && block_ns > 
> halt_poll_ns)
> +   shrink_halt_poll_ns(vcpu);
> +   /* we had a short halt and our poll time is too small 
> */
> +   else if (vcpu->halt_poll_ns < halt_poll_ns &&
> +   block_ns < halt_poll_ns)
> +   grow_halt_poll_ns(vcpu);
> +   } else {
> +   vcpu->halt_poll_ns = 0;
> +   }
> +   }
>
> trace_kvm_vcpu_wakeup(block_ns, waited, vcpu_valid_wakeup(vcpu));
> kvm_arch_vcpu_block_finish(vcpu);
> --
> 2.7.4
>

[PATCH 1/3] regulator: rk808: Constify rk817 regulator_ops

[Axel Lin]

These regulator_ops variables never need to be modified, make them const so
compiler can put them to .rodata.

Signed-off-by: Axel Lin 
---
 drivers/regulator/rk808-regulator.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/regulator/rk808-regulator.c 
b/drivers/regulator/rk808-regulator.c
index 61bd5ef0806c..eda056fce65f 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -686,7 +686,7 @@ static const struct regulator_linear_range 
rk805_buck_1_2_voltage_ranges[] = {
REGULATOR_LINEAR_RANGE(230, 63, 63, 0),
 };
 
-static struct regulator_ops rk809_buck5_ops_range = {
+static const struct regulator_ops rk809_buck5_ops_range = {
.list_voltage   = regulator_list_voltage_linear_range,
.map_voltage= regulator_map_voltage_linear_range,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
@@ -700,7 +700,7 @@ static struct regulator_ops rk809_buck5_ops_range = {
.set_suspend_disable= rk817_set_suspend_disable,
 };
 
-static struct regulator_ops rk817_reg_ops = {
+static const struct regulator_ops rk817_reg_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
@@ -713,7 +713,7 @@ static struct regulator_ops rk817_reg_ops = {
.set_suspend_disable= rk817_set_suspend_disable,
 };
 
-static struct regulator_ops rk817_boost_ops = {
+static const struct regulator_ops rk817_boost_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
@@ -725,7 +725,7 @@ static struct regulator_ops rk817_boost_ops = {
.set_suspend_disable= rk817_set_suspend_disable,
 };
 
-static struct regulator_ops rk817_buck_ops_range = {
+static const struct regulator_ops rk817_buck_ops_range = {
.list_voltage   = regulator_list_voltage_linear_range,
.map_voltage= regulator_map_voltage_linear_range,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
@@ -743,7 +743,7 @@ static struct regulator_ops rk817_buck_ops_range = {
.set_suspend_disable= rk817_set_suspend_disable,
 };
 
-static struct regulator_ops rk817_switch_ops = {
+static const struct regulator_ops rk817_switch_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = rk8xx_is_enabled_wmsk_regmap,
-- 
2.20.1

[PATCH 3/3] regulator: rk808: Remove rk817_set_suspend_voltage function

[Axel Lin]

The implement is exactly the same as rk808_set_suspend_voltage, so just
use rk808_set_suspend_voltage instead.

Signed-off-by: Axel Lin 
---
 drivers/regulator/rk808-regulator.c | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/regulator/rk808-regulator.c 
b/drivers/regulator/rk808-regulator.c
index d0d1b868b0cd..5b4003226484 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -411,21 +411,6 @@ static int rk808_set_suspend_voltage(struct regulator_dev 
*rdev, int uv)
  sel);
 }
 
-static int rk817_set_suspend_voltage(struct regulator_dev *rdev, int uv)
-{
-   unsigned int reg;
-   int sel = regulator_map_voltage_linear(rdev, uv, uv);
-   /* only ldo1~ldo9 */
-   if (sel < 0)
-   return -EINVAL;
-
-   reg = rdev->desc->vsel_reg + RK808_SLP_REG_OFFSET;
-
-   return regmap_update_bits(rdev->regmap, reg,
- rdev->desc->vsel_mask,
- sel);
-}
-
 static int rk808_set_suspend_voltage_range(struct regulator_dev *rdev, int uv)
 {
unsigned int reg;
@@ -708,7 +693,7 @@ static const struct regulator_ops rk817_reg_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = rk8xx_is_enabled_wmsk_regmap,
-   .set_suspend_voltage= rk817_set_suspend_voltage,
+   .set_suspend_voltage= rk808_set_suspend_voltage,
.set_suspend_enable = rk817_set_suspend_enable,
.set_suspend_disable= rk817_set_suspend_disable,
 };
-- 
2.20.1

[PATCH 2/3] regulator: rk808: Fix warning message in rk817_set_ramp_delay

[Axel Lin]

The default in rk817_set_ramp_delay is 25MV rather than 10MV.

Signed-off-by: Axel Lin 
---
 drivers/regulator/rk808-regulator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/rk808-regulator.c 
b/drivers/regulator/rk808-regulator.c
index eda056fce65f..d0d1b868b0cd 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -388,7 +388,7 @@ static int rk817_set_ramp_delay(struct regulator_dev *rdev, 
int ramp_delay)
break;
default:
dev_warn(>dev,
-"%s ramp_delay: %d not supported, setting 1\n",
+"%s ramp_delay: %d not supported, setting 25000\n",
 rdev->desc->name, ramp_delay);
}
 
-- 
2.20.1

Re: [PATCH] lib/list-test: add a test for the 'list' doubly linked list

[Kees Cook]

On Mon, Oct 07, 2019 at 02:36:33PM -0700, David Gow wrote:
> This change adds a KUnit test for the kernel doubly linked list
> implementation in include/linux/list.h
> 
> Note that, at present, it only tests the list_ types (not the
> singly-linked hlist_), and does not yet test all of the
> list_for_each_entry* macros (and some related things like
> list_prepare_entry).
> 
> This change depends on KUnit, so should be merged via the 'test' branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/log/?h=test
> 
> Signed-off-by: David Gow 
> ---
>  lib/Kconfig.debug |  12 +
>  lib/Makefile  |   3 +
>  lib/list-test.c   | 711 ++
>  3 files changed, 726 insertions(+)
>  create mode 100644 lib/list-test.c
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index a3017a5dadcd..60691c0aac3e 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1961,6 +1961,18 @@ config SYSCTL_KUNIT_TEST
>  
> If unsure, say N.
>  
> +config LIST_TEST
> + bool "KUnit Test for Kernel Linked-list stuctures"
> + depends on KUNIT
> + help
> +   This builds the linked list unit test, which runs on boot.
> +   It tests that the API and basic functionality of the list_head type
> +   and associated macros.
> +   For more information on KUnit and unit tests in general please refer
> +   to the KUnit documentation in Documentation/dev-tools/kunit/.
> +
> +   If unsure, say N.
> +
>  config TEST_UDELAY
>   tristate "udelay test driver"
>   help
> diff --git a/lib/Makefile b/lib/Makefile
> index bba1fd5485f7..309e174ee35d 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -292,3 +292,6 @@ obj-$(CONFIG_GENERIC_LIB_MULDI3) += muldi3.o
>  obj-$(CONFIG_GENERIC_LIB_CMPDI2) += cmpdi2.o
>  obj-$(CONFIG_GENERIC_LIB_UCMPDI2) += ucmpdi2.o
>  obj-$(CONFIG_OBJAGG) += objagg.o
> +
> +# KUnit tests
> +obj-$(CONFIG_LIST_TEST) += list-test.o
> diff --git a/lib/list-test.c b/lib/list-test.c
> new file mode 100644
> index ..f333e8b0d9fe
> --- /dev/null
> +++ b/lib/list-test.c
> @@ -0,0 +1,711 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include 
> +
> +#include 
> +
> +struct list_test_struct {
> + int data;
> + struct list_head list;
> +};
> +
> +static void list_init_test(struct kunit *test)
> +{
> + /* Test the different ways of initialising a list. */
> + struct list_head list1 = LIST_HEAD_INIT(list1);
> + struct list_head list2;
> + LIST_HEAD(list3);
> +
> + INIT_LIST_HEAD();

Can you also add different storage locations and initial contents tests?
For example:

struct list_head *list4;
struct list_head *list5;

list4 = kzalloc(sizeof(*list4));
INIT_LIST_HEAD(list4);

list5 = kmalloc(sizeof(*list5));
memset(list4, 0xff, sizeof(*list5));
INIT_LIST_HEAD(list5);


KUNIT_EXPECT_TRUE(test, list_empty_careful());
KUNIT_EXPECT_TRUE(test, list_empty_careful());

kfree(list4);
kfree(list5);

Then we know it's not an accident that INIT_LIST_HEAD() works when both
all-zeros and all-0xFF initial contents are there. :)

> +
> + /* list_empty_careful() checks both next and prev. */
> + KUNIT_EXPECT_TRUE(test, list_empty_careful());
> + KUNIT_EXPECT_TRUE(test, list_empty_careful());
> + KUNIT_EXPECT_TRUE(test, list_empty_careful());
> +}
> +
> +static void list_add_test(struct kunit *test)
> +{
> + struct list_head a, b;
> + LIST_HEAD(list);
> +
> + list_add(, );
> + list_add(, );
> +
> + /* should be [list] -> b -> a */
> + KUNIT_EXPECT_PTR_EQ(test, list.next, );
> + KUNIT_EXPECT_PTR_EQ(test, b.prev, );
> + KUNIT_EXPECT_PTR_EQ(test, b.next, );
> +}
> +
> +static void list_add_tail_test(struct kunit *test)
> +{
> + struct list_head a, b;
> + LIST_HEAD(list);
> +
> + list_add_tail(, );
> + list_add_tail(, );
> +
> + /* should be [list] -> a -> b */
> + KUNIT_EXPECT_PTR_EQ(test, list.next, );
> + KUNIT_EXPECT_PTR_EQ(test, a.prev, );
> + KUNIT_EXPECT_PTR_EQ(test, a.next, );
> +}
> +
> +static void list_del_test(struct kunit *test)
> +{
> + struct list_head a, b;
> + LIST_HEAD(list);
> +
> + list_add_tail(, );
> + list_add_tail(, );
> +
> + /* before: [list] -> a -> b */
> + list_del();
> +
> + /* now: [list] -> b */
> + KUNIT_EXPECT_PTR_EQ(test, list.next, );
> + KUNIT_EXPECT_PTR_EQ(test, b.prev, );
> +}
> +
> +static void list_replace_test(struct kunit *test)
> +{
> + struct list_head a_old, a_new, b;
> + LIST_HEAD(list);
> +
> + list_add_tail(_old, );
> + list_add_tail(, );
> +
> + /* before: [list] -> a_old -> b */
> + list_replace(_old, _new);
> +
> + /* now: [list] -> a_new -> b */
> + KUNIT_EXPECT_PTR_EQ(test, list.next, _new);
> + KUNIT_EXPECT_PTR_EQ(test, b.prev, _new);
> +}
> +
> +static void list_replace_init_test(struct kunit *test)
> +{
> 

RE: [PATCH 1/3] arm64: dts: imx8mq: Use correct clock for usdhc's ipg clk

[Anson Huang]

Hi, Shawn

> On Thu, Sep 19, 2019 at 01:05:57PM +0800, Anson Huang wrote:
> > On i.MX8MQ, usdhc's ipg clock is from IMX8MQ_CLK_IPG_ROOT, assign it
> > explicitly instead of using IMX8MQ_CLK_DUMMY.
> >
> > Signed-off-by: Anson Huang 
> 
> Fixes tag?

OK, added them in V2.

Thanks,
Anson

[PATCH V2 3/3] arm64: dts: imx8mn: Use correct clock for usdhc's ipg clk

[Anson Huang]

On i.MX8MN, usdhc's ipg clock is from IMX8MN_CLK_IPG_ROOT,
assign it explicitly instead of using IMX8MN_CLK_DUMMY.

Fixes: 6c3debcbae47 ("arm64: dts: freescale: Add i.MX8MN dtsi support")
Signed-off-by: Anson Huang 
---
Changes since V1:
- Add fixes tag.
---
 arch/arm64/boot/dts/freescale/imx8mn.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 6cb6c9c..725a3a3 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -594,7 +594,7 @@
compatible = "fsl,imx8mn-usdhc", 
"fsl,imx7d-usdhc";
reg = <0x30b4 0x1>;
interrupts = ;
-   clocks = < IMX8MN_CLK_DUMMY>,
+   clocks = < IMX8MN_CLK_IPG_ROOT>,
 < IMX8MN_CLK_NAND_USDHC_BUS>,
 < IMX8MN_CLK_USDHC1_ROOT>;
clock-names = "ipg", "ahb", "per";
@@ -610,7 +610,7 @@
compatible = "fsl,imx8mn-usdhc", 
"fsl,imx7d-usdhc";
reg = <0x30b5 0x1>;
interrupts = ;
-   clocks = < IMX8MN_CLK_DUMMY>,
+   clocks = < IMX8MN_CLK_IPG_ROOT>,
 < IMX8MN_CLK_NAND_USDHC_BUS>,
 < IMX8MN_CLK_USDHC2_ROOT>;
clock-names = "ipg", "ahb", "per";
@@ -624,7 +624,7 @@
compatible = "fsl,imx8mn-usdhc", 
"fsl,imx7d-usdhc";
reg = <0x30b6 0x1>;
interrupts = ;
-   clocks = < IMX8MN_CLK_DUMMY>,
+   clocks = < IMX8MN_CLK_IPG_ROOT>,
 < IMX8MN_CLK_NAND_USDHC_BUS>,
 < IMX8MN_CLK_USDHC3_ROOT>;
clock-names = "ipg", "ahb", "per";
-- 
2.7.4

[PATCH V2 2/3] arm64: dts: imx8mm: Use correct clock for usdhc's ipg clk

[Anson Huang]

On i.MX8MM, usdhc's ipg clock is from IMX8MM_CLK_IPG_ROOT,
assign it explicitly instead of using IMX8MM_CLK_DUMMY.

Fixes: a05ea40eb384 ("arm64: dts: imx: Add i.mx8mm dtsi support")
Signed-off-by: Anson Huang 
---
Changes since V1:
- Add fixes tag.
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 7c4dcce..8aafad2 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -694,7 +694,7 @@
compatible = "fsl,imx8mm-usdhc", 
"fsl,imx7d-usdhc";
reg = <0x30b4 0x1>;
interrupts = ;
-   clocks = < IMX8MM_CLK_DUMMY>,
+   clocks = < IMX8MM_CLK_IPG_ROOT>,
 < IMX8MM_CLK_NAND_USDHC_BUS>,
 < IMX8MM_CLK_USDHC1_ROOT>;
clock-names = "ipg", "ahb", "per";
@@ -710,7 +710,7 @@
compatible = "fsl,imx8mm-usdhc", 
"fsl,imx7d-usdhc";
reg = <0x30b5 0x1>;
interrupts = ;
-   clocks = < IMX8MM_CLK_DUMMY>,
+   clocks = < IMX8MM_CLK_IPG_ROOT>,
 < IMX8MM_CLK_NAND_USDHC_BUS>,
 < IMX8MM_CLK_USDHC2_ROOT>;
clock-names = "ipg", "ahb", "per";
@@ -724,7 +724,7 @@
compatible = "fsl,imx8mm-usdhc", 
"fsl,imx7d-usdhc";
reg = <0x30b6 0x1>;
interrupts = ;
-   clocks = < IMX8MM_CLK_DUMMY>,
+   clocks = < IMX8MM_CLK_IPG_ROOT>,
 < IMX8MM_CLK_NAND_USDHC_BUS>,
 < IMX8MM_CLK_USDHC3_ROOT>;
clock-names = "ipg", "ahb", "per";
-- 
2.7.4

[PATCH V2 1/3] arm64: dts: imx8mq: Use correct clock for usdhc's ipg clk

[Anson Huang]

On i.MX8MQ, usdhc's ipg clock is from IMX8MQ_CLK_IPG_ROOT,
assign it explicitly instead of using IMX8MQ_CLK_DUMMY.

Fixes: 748f908cc882 ("arm64: add basic DTS for i.MX8MQ")
Signed-off-by: Anson Huang 
---
Changes since V1:
- Add fixes tag.
---
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 04115ca..55a3d1c 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -850,7 +850,7 @@
 "fsl,imx7d-usdhc";
reg = <0x30b4 0x1>;
interrupts = ;
-   clocks = < IMX8MQ_CLK_DUMMY>,
+   clocks = < IMX8MQ_CLK_IPG_ROOT>,
 < IMX8MQ_CLK_NAND_USDHC_BUS>,
 < IMX8MQ_CLK_USDHC1_ROOT>;
clock-names = "ipg", "ahb", "per";
@@ -867,7 +867,7 @@
 "fsl,imx7d-usdhc";
reg = <0x30b5 0x1>;
interrupts = ;
-   clocks = < IMX8MQ_CLK_DUMMY>,
+   clocks = < IMX8MQ_CLK_IPG_ROOT>,
 < IMX8MQ_CLK_NAND_USDHC_BUS>,
 < IMX8MQ_CLK_USDHC2_ROOT>;
clock-names = "ipg", "ahb", "per";
-- 
2.7.4

Re: mount on tmpfs failing to parse context option

[Hugh Dickins]

On Mon, 7 Oct 2019, Laura Abbott wrote:
> On 9/30/19 12:07 PM, Laura Abbott wrote:
> > Hi,
> > 
> > Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1757104
> > of a failure to parse options with the context mount option. From the
> > reporter:
> > 
> > 
> > $ unshare -rm mount -t tmpfs tmpfs /tmp -o
> > 'context="system_u:object_r:container_file_t:s0:c475,c690"'
> > mount: /tmp: wrong fs type, bad option, bad superblock on tmpfs, missing
> > codepage or helper program, or other error.
> > 
> > 
> > Sep 30 16:50:42 kernel: tmpfs: Unknown parameter 'c690"'
> > 
> > I haven't asked the reporter to bisect yet but I'm suspecting one of the
> > conversion to the new mount API:
> > 
> > $ git log --oneline v5.3..origin/master mm/shmem.c
> > edf445ad7c8d Merge branch 'hugepage-fallbacks' (hugepatch patches from
> > David Rientjes)
> > 19deb7695e07 Revert "Revert "Revert "mm, thp: consolidate THP gfp handling
> > into alloc_hugepage_direct_gfpmask""
> > 28eb3c808719 shmem: fix obsolete comment in shmem_getpage_gfp()
> > 4101196b19d7 mm: page cache: store only head pages in i_pages
> > d8c6546b1aea mm: introduce compound_nr()
> > f32356261d44 vfs: Convert ramfs, shmem, tmpfs, devtmpfs, rootfs to use the
> > new mount API
> > 626c3920aeb4 shmem_parse_one(): switch to use of fs_parse()
> > e04dc423ae2c shmem_parse_options(): take handling a single option into a
> > helper
> > f6490b7fbb82 shmem_parse_options(): don't bother with mpol in separate
> > variable
> > 0b5071dd323d shmem_parse_options(): use a separate structure to keep the
> > results
> > 7e30d2a5eb0b make shmem_fill_super() static
> > 
> > 
> > I didn't find another report or a fix yet. Is it worth asking the reporter
> > to bisect?
> > 
> > Thanks,
> > Laura
> 
> Ping again, I never heard anything back and I didn't see anything come in
> with -rc2

Sorry for not responding sooner, Laura, I was travelling: and dearly
hoping that David or Al would take it.  I'm afraid this is rather beyond
my capability (can I admit that it's the first time I even heard of the
"context" mount option? and grepping for "context" has not yet shown me
at what level it is handled; and I've no idea of what a valid "context"
is for my own tmpfs mounts, to start playing around with its parsing).

Yes, I think we can assume that this bug comes from f32356261d44 ("vfs:
Convert ramfs, shmem, tmpfs, devtmpfs, rootfs to use the new mount API")
or one of shmem_parse ones associated with it; but I'm pretty sure that
it's not worth troubling the reporter to bisect.  I expect David and Al
are familiar with "context", and can go straight to where it's handled,
and see what's up.

(tmpfs, very tiresomely, supports a NUMA "mpol" mount option which can
have commas in it e.g "mpol=bind:0,2": which makes all its comma parsing
awkward.  I assume that where the new mount API commits bend over to
accommodate that peculiarity, they end up mishandling the comma in
the context string above.)

And since we're on the subject of new mount API breakage in tmpfs, I'll
take the liberty of repeating this different case, reported earlier and
still broken in rc2: again something that I'd be hard-pressed to fix
myself, without endangering some other filesystem's mount parsing:-

My /etc/fstab has a line in for one of my test mounts:
tmpfs/tlo tmpfs  size=4G   0 0
and that "size=4G" is what causes the problem: because each time
shmem_parse_options(fc, data) is called for a remount, data (that is,
options) points to a string starting with "size=4G,", followed by
what's actually been asked for in the remount options.

So if I try
mount -o remount,size=0 /tlo
that succeeds, setting the filesystem size to 0 meaning unlimited.
So if then as a test I try
mount -o remount,size=1M /tlo
that correctly fails with "Cannot retroactively limit size".
But then when I try
mount -o remount,nr_inodes=0 /tlo
I again get "Cannot retroactively limit size",
when it should have succeeded (again, 0 here meaning unlimited).

That's because the options in shmem_parse_options() are
"size=4G,nr_inodes=0", which indeed looks like an attempt to
retroactively limit size; but the user never asked "size=4G" there.

Hugh

RE: [PATCH V2] firmware: imx: Skip return value check for some special SCU firmware APIs

[Anson Huang]

Hi, Marco

> On 19-10-07 09:15, Anson Huang wrote:
> > The SCU firmware does NOT always have return value stored in message
> > header's function element even the API has response data, those
> > special APIs are defined as void function in SCU firmware, so they
> > should be treated as return success always.
> >
> > Signed-off-by: Anson Huang 
> > ---
> > Changes since V1:
> > - Use direct API check instead of calling another function to check.
> > - This patch is based on
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fpatch%2F11129553%2Fdata=02%7C01%7Canson.
> huang%
> >
> 40nxp.com%7C2de0a6be69b74cc249ad08d74afc9730%7C686ea1d3bc2b4c6f
> a92cd99
> >
> c5c301635%7C0%7C0%7C637060321046247040sdata=RMFAdLKGKb6
> mEdhycrzHX
> > R03E6Qr5pWyRc8Zk6ErlBc%3Dreserved=0
> 
> Thanks for this v2. It would be good to change the callers within this series.

NOT quite understand your point, the callers does NOT need to be changed, those
2 special APIs callers are already following the right way of calling the APIs.

Anson

Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default

[Atish Patra]

On Mon, 2019-10-07 at 05:11 -0400, Alex Ghiti wrote:
> On 10/4/19 10:12 PM, Atish Patra wrote:
> > On Thu, 2019-08-08 at 02:17 -0400, Alexandre Ghiti wrote:
> > > In order to avoid wasting user address space by using bottom-up
> > > mmap
> > > allocation scheme, prefer top-down scheme when possible.
> > > 
> > > Before:
> > > root@qemuriscv64:~# cat /proc/self/maps
> > > 0001-00016000 r-xp  fe:00
> > > 6389   /bin/cat.coreutils
> > > 00016000-00017000 r--p 5000 fe:00
> > > 6389   /bin/cat.coreutils
> > > 00017000-00018000 rw-p 6000 fe:00
> > > 6389   /bin/cat.coreutils
> > > 00018000-00039000 rw-p  00:00 0  [heap]
> > > 156000-16d000 r-xp  fe:00 7193   /lib/ld-2.28.so
> > > 16d000-16e000 r--p 00016000 fe:00 7193   /lib/ld-2.28.so
> > > 16e000-16f000 rw-p 00017000 fe:00 7193   /lib/ld-2.28.so
> > > 16f000-17 rw-p  00:00 0
> > > 17-172000 r-xp  00:00 0  [vdso]
> > > 174000-176000 rw-p  00:00 0
> > > 176000-1555674000 r-xp  fe:00 7187   /lib/libc-
> > > 2.28.so
> > > 1555674000-1555678000 r--p 000fd000 fe:00 7187   /lib/libc-
> > > 2.28.so
> > > 1555678000-155567a000 rw-p 00101000 fe:00 7187   /lib/libc-
> > > 2.28.so
> > > 155567a000-15556a rw-p  00:00 0
> > > 3fffb9-3fffbb1000 rw-p  00:00 0  [stack]
> > > 
> > > After:
> > > root@qemuriscv64:~# cat /proc/self/maps
> > > 0001-00016000 r-xp  fe:00
> > > 6389   /bin/cat.coreutils
> > > 00016000-00017000 r--p 5000 fe:00
> > > 6389   /bin/cat.coreutils
> > > 00017000-00018000 rw-p 6000 fe:00
> > > 6389   /bin/cat.coreutils
> > > 2de81000-2dea2000 rw-p  00:00 0  [heap]
> > > 3ff7eb6000-3ff7ed8000 rw-p  00:00 0
> > > 3ff7ed8000-3ff7fd6000 r-xp  fe:00 7187   /lib/libc-
> > > 2.28.so
> > > 3ff7fd6000-3ff7fda000 r--p 000fd000 fe:00 7187   /lib/libc-
> > > 2.28.so
> > > 3ff7fda000-3ff7fdc000 rw-p 00101000 fe:00 7187   /lib/libc-
> > > 2.28.so
> > > 3ff7fdc000-3ff7fe2000 rw-p  00:00 0
> > > 3ff7fe4000-3ff7fe6000 r-xp  00:00 0  [vdso]
> > > 3ff7fe6000-3ff7ffd000 r-xp  fe:00 7193   /lib/ld-2.28.so
> > > 3ff7ffd000-3ff7ffe000 r--p 00016000 fe:00 7193   /lib/ld-2.28.so
> > > 3ff7ffe000-3ff7fff000 rw-p 00017000 fe:00 7193   /lib/ld-2.28.so
> > > 3ff7fff000-3ff800 rw-p  00:00 0
> > > 3fff888000-3fff8a9000 rw-p  00:00 0  [stack]
> > > 
> > > Signed-off-by: Alexandre Ghiti 
> > > Acked-by: Paul Walmsley 
> > > Reviewed-by: Christoph Hellwig 
> > > Reviewed-by: Kees Cook 
> > > Reviewed-by: Luis Chamberlain 
> > > ---
> > >   arch/riscv/Kconfig | 12 
> > >   1 file changed, 12 insertions(+)
> > > 
> > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > index 59a4727ecd6c..87dc5370becb 100644
> > > --- a/arch/riscv/Kconfig
> > > +++ b/arch/riscv/Kconfig
> > > @@ -54,6 +54,18 @@ config RISCV
> > >   select EDAC_SUPPORT
> > >   select ARCH_HAS_GIGANTIC_PAGE
> > >   select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
> > > + select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
> > > + select HAVE_ARCH_MMAP_RND_BITS
> > > +
> > > +config ARCH_MMAP_RND_BITS_MIN
> > > + default 18 if 6legacy_va_layout4BIT
> > > + default 8
> > > +
> > > +# max bits determined by the following formula:
> > > +#  VA_BITS - PAGE_SHIFT - 3
> > > +config ARCH_MMAP_RND_BITS_MAX
> > > + default 24 if 64BIT # SV39 based
> > > + default 17
> > >   
> > >   config MMU
> > >   def_bool y
> > With this patch, I am not able to boot a Fedora Linux(a Gnome
> > desktop
> > image) on RISC-V hardware (Unleashed + Microsemi Expansion board).
> > The
> > booting gets stuck right after systemd starts.
> > 
> > https://paste.fedoraproject.org/paste/TOrUMqqKH-pGFX7CnfajDg
> > 
> > Reverting just this patch allow to boot Fedora successfully on
> > specific
> > RISC-V hardware. I have not root caused the issue but it looks like
> > it
> > might have messed userpsace mapping.
> 
> It might have messed userspace mapping but not enough to make
> userspace 
> completely broken
> as systemd does some things. I would try to boot in legacy layout:
> if 
> you can try to set sysctl legacy_va_layout
> at boottime, it will map userspace as it was before (bottom-up). If
> that 
> does not work, the problem could
> be the randomization that is activated by default now.

Randomization may not be the issue. I just removed
ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT from the config and that seems to
work. Here is the bottom-up layout with randomization on.

[root@fedora-riscv ~]# cat /proc/self/maps 
156000-17 r-xp  103:01
280098/usr/lib64/ld-2.28.so
17-171000 r--p 00019000 103:01
280098/usr/lib64/ld-2.28.so
171000-172000 rw-p 0001a000 103:01
280098/usr/lib64/ld-2.28.so
172000-173000 rw-p  

Re: [PATCH] x86/cpu/vmware: use the full form of inl in VMWARE_PORT

[Kees Cook]

On Mon, Oct 07, 2019 at 12:21:29PM -0700, Sami Tolvanen wrote:
> LLVM's assembler doesn't accept the short form inl (%%dx) instruction,
> but instead insists on the output register to be explicitly specified:
> 
>   :1:7: error: invalid operand for instruction
>   inl (%dx)
>  ^
>   LLVM ERROR: Error parsing inline asm
> 
> Use the full form of the instruction to fix the build.
> 
> Signed-off-by: Sami Tolvanen 

Reviewed-by: Kees Cook 

-Kees

> ---
>  arch/x86/kernel/cpu/vmware.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
> index 9735139cfdf8..46d732696c1c 100644
> --- a/arch/x86/kernel/cpu/vmware.c
> +++ b/arch/x86/kernel/cpu/vmware.c
> @@ -49,7 +49,7 @@
>  #define VMWARE_CMD_VCPU_RESERVED 31
>  
>  #define VMWARE_PORT(cmd, eax, ebx, ecx, edx) \
> - __asm__("inl (%%dx)" :  \
> + __asm__("inl (%%dx), %%eax" :   \
>   "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
>   "a"(VMWARE_HYPERVISOR_MAGIC),   \
>   "c"(VMWARE_CMD_##cmd),  \
> -- 
> 2.23.0.581.g78d2f28ef7-goog
> 

-- 
Kees Cook

Re: [PATCH] media: i2c: adv7180: fix adv7280 BT.656-4 compatibility

[Steve Longerbeam]

On 10/2/19 2:31 PM, Tim Harvey wrote:

On Fri, Sep 27, 2019 at 1:43 PM Niklas Söderlund
  wrote:

Hi Tim,

On 2019-09-27 12:26:40 -0700, Tim Harvey wrote:

On Fri, Sep 27, 2019 at 12:04 PM Niklas Söderlund
  wrote:

Hi Tim,

Sorry for taking to so long to look at this.

On 2019-09-23 15:04:47 -0700, Tim Harvey wrote:

On Thu, Aug 29, 2019 at 7:29 AM Niklas Söderlund
  wrote:

Hi,

On 2019-08-29 13:43:49 +0200, Hans Verkuil wrote:

Adding Niklas.

Niklas, can you take a look at this?

I'm happy to have a look at this. I'm currently moving so all my boards
are in a box somewhere. I hope to have my lab up and running next week,
so if this is not urgent I will look at it then.


Niklas,

Have you looked at this yet? Without this patch the ADV7280A does not
output proper BT.656. We tested this on a Gateworks Ventana GW5404-G
which uses the ADV7280A connected to the IMX6 CSI parallel bus. I'm
hoping to see this get merged and perhaps backported to older kernels.

I only have access to an adv7180 so I was unable to test this patch.
After reviewing the documentation I think the patch is OK if what you
want is to unconditionally switch the driver from outputting BT.656-3 to
outputting BT.656-4.

As this change would effect a large number of compat strings (adv7280,
adv7280-m, adv7281, adv7281-m, adv7281-ma, adv7282, adv7282-m) and the
goal is to back port it I'm a bit reluctant to adding my tag to this
patch as I'm not sure if this will break other setups.

 From the documentation about the BT.656-4 register (address 0x04 bit 7):

 Between Revision 3 and Revision 4 of the ITU-R BT.656 standards,
 the ITU has changed the toggling position for the V bit within
 the SAV EAV codes for NTSC. The ITU-R BT.656-4 standard
 bit allows the user to select an output mode that is compliant
 with either the previous or new standard. For further information,
 visit the International Telecommunication Union website.

 Note that the standard change only affects NTSC and has no
 bearing on PAL.

 When ITU-R BT.656-4 is 0 (default), the ITU-R BT.656-3
 specification is used. The V bit goes low at EAV of Line 10
 and Line 273.

 When ITU-R BT.656-4 is 1, the ITU-R BT.656-4 specification is
 used. The V bit goes low at EAV of Line 20 and Line 283.

Do you know what effects such a change would bring? Looking at the
driver BT.656-4 seems to be set unconditionally for some adv7180 chips.


Niklas,

Quite simply, we have a board that has an ADV7180 attached to the
parallel CSI of an IMX6 that worked fine with mainline drivers then
when we revised this board to attach an ADV7280A in the same way
capture failed to sync. Investigation showed that the NEWAVMODE
differed between the two.

I understand your problem, the driver configures adv7180 and adv7280
differently.


So if the point of the driver is to configure the variants in the same
way, this patch needs to be applied.

I'm not sure that is the point of the driver. As the driver today
configures different compatible strings differently. Some as ITU-R
BT.656-3 and some as ITU-R BT.656-4, I can only assume there is a reason
for that.


I would maintain that the adv7180 comes up with NEWAVMODE enabled and
in order to be compatible we must configure the adv7282 the same.

The same argument can be made for setting the V bit end position in
NTSC mode - its done for the adv7180 so for compatible output it
should be done for the adv7282.

I understand that this is needed to make it a drop-in replacement for
the adv7180 in your use-case. But I'm not sure it is a good idea for
other users of the driver. What if someone is already using a adv7282 on
a board and depends on it providing ITU-R BT.656-3 and the old settings?
If this patch is picked up there use-cases may break.

I'm not sure what the best way forward is I'm afraid. Looking at
video-interfaces.txt we have a device tree property bus-type which is
used to describe the bus is a BT.656 bus but not which revision of it.

I'm not really found of driver specific bus descriptions, but maybe this
is a case where one might consider adding one? Hans what do you think?


Niklas / Hans,

Thanks for the feedback. I thought that the goal of any 'compatible'
device should be to be configured identically. If that's not the case
then we need more discussion for sure.

There are 3 registers being changed by this patch which do the
following for the adv7182/adv7280/adv7181/adv7282:
- change output from BT656-3 to BT656-4 (as the driver does this for adv7180)
- enable NEWAVMODE meaning EAV/SAV codes are configurable (new code
but adv7180 enables this by power-on default and adv7280 does not)
- configure V bit end count (to be what adv7180 uses; this isn't used
if NEWAVMODE is disabled)

So its not only the question of how to decide to configure BT656-3 vs
BT656-4 but how to deal with differences in the EAV/SAV codes. I'm not
an expert so I don't know what configuration is BT656 compliant and of

Re: [PATCH 4/4] riscv: remove the switch statement in do_trap_break()

[Vincent Chen]

Sorry,  I missed the comment. Christoph's suggestion is also good to me.
I will modify it as you suggested.
Thanks

On Tue, Oct 8, 2019 at 12:31 AM Paul Walmsley  wrote:
>
> On Mon, 7 Oct 2019, Christoph Hellwig wrote:
>
> > On Mon, Oct 07, 2019 at 09:08:23AM -0700, Paul Walmsley wrote:
> > > force_sig_fault(SIGTRAP, TRAP_BRKPT,
> > > (void __user *)(regs->sepc));
> >
> > No nee for the extra braces, which also means it all fits onto a single
> > line.
>
> Good point, will drop the extra parens and remove the braces.
>
>
> - Paul

linux-next: build warning after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

sound/soc/jz4740/jz4740-i2s.c: In function 'jz4740_i2s_dev_probe':
sound/soc/jz4740/jz4740-i2s.c:500:29: warning: unused variable 'match' 
[-Wunused-variable]
  500 |  const struct of_device_id *match;
  | ^

Introduced by commit

  67ad656bdd70 ("ASoC: jz4740: Use of_device_get_match_data()")

-- 
Cheers,
Stephen Rothwell


pgpvaQmKQikeu.pgp
Description: OpenPGP digital signature

Re: ehci-pci breakage with dma-mapping changes in 5.4-rc2

[Arvind Sankar]

On Mon, Oct 07, 2019 at 06:10:55PM -0400, Arvind Sankar wrote:
> On Mon, Oct 07, 2019 at 08:47:54PM +0200, Christoph Hellwig wrote:
> > On Mon, Oct 07, 2019 at 02:32:07PM -0400, Arvind Sankar wrote:
> > > On Mon, Oct 07, 2019 at 01:58:57PM -0400, Arvind Sankar wrote:
> > > > On Mon, Oct 07, 2019 at 10:56:30AM -0700, Christoph Hellwig wrote:
> > > > > On Mon, Oct 07, 2019 at 07:55:28PM +0200, Christoph Hellwig wrote:
> > > > > > On Mon, Oct 07, 2019 at 01:54:32PM -0400, Arvind Sankar wrote:
> > > > > > > It doesn't boot with the patch. Won't it go
> > > > > > >   dma_get_required_mask
> > > > > > >   -> intel_get_required_mask
> > > > > > >   -> iommu_need_mapping
> > > > > > >   -> dma_get_required_mask
> > > > > > > ?
> > > > > > > 
> > > > > > > Should the call to dma_get_required_mask in iommu_need_mapping be
> > > > > > > replaced with dma_direct_get_required_mask on top of your patch?
> > > > > > 
> > > > > > Yes, sorry.
> > > > > 
> > > > > Actually my patch already calls dma_direct_get_required_mask.
> > > > > How did you get the loop?
> > > > 
> > > > The function iommu_need_mapping (not changed by your patch) calls
> > > > dma_get_required_mask internally, to check whether the device's dma_mask
> > > > is big enough or not. That's the call I was asking whether it needs to
> > > > be changed.
> > > 
> > > Yeah the attached patch seems to fix it.
> > 
> > That looks fine to me:
> > 
> > Acked-by: Christoph Hellwig 
> 
> Do you want me to resend the patch as its own mail, or do you just take
> it with a Tested-by: from me? If the former, I assume you're ok with me
> adding your Signed-off-by?
> 
> Thanks

A question on the original change though -- what happens if a single
device (or a single IOMMU domain really) does want >4G DMA address
space? Was that not previously allowed either?

Re: [RFC][PATCH v2 2/5] usb: dwc3: Execute GCTL Core Soft Reset while switch mdoe for Hisilicon Kirin Soc

[John Stultz]

On Mon, Oct 7, 2019 at 4:39 PM Jack Pham  wrote:
>
> Hi John, Yu, Felipe,
>
> On Mon, Oct 07, 2019 at 05:55:50PM +, John Stultz wrote:
> > From: Yu Chen 
> >
> > A GCTL soft reset should be executed when switch mode for dwc3 core
> > of Hisilicon Kirin Soc.
> >
> > Cc: Greg Kroah-Hartman 
> > Cc: Felipe Balbi 
> > Cc: Andy Shevchenko 
> > Cc: Rob Herring 
> > Cc: Mark Rutland 
> > Cc: Yu Chen 
> > Cc: Matthias Brugger 
> > Cc: Chunfeng Yun 
> > Cc: linux-...@vger.kernel.org
> > Cc: devicet...@vger.kernel.org
> > Signed-off-by: Yu Chen 
> > Signed-off-by: John Stultz 
> > ---
> >  drivers/usb/dwc3/core.c | 20 
> >  drivers/usb/dwc3/core.h |  3 +++
> >  2 files changed, 23 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > index 999ce5e84d3c..440261432421 100644
> > --- a/drivers/usb/dwc3/core.c
> > +++ b/drivers/usb/dwc3/core.c
> > @@ -112,6 +112,19 @@ void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
> >   dwc->current_dr_role = mode;
> >  }
> >
> > +static void dwc3_gctl_core_soft_reset(struct dwc3 *dwc)
> > +{
> > + u32 reg;
> > +
> > + reg = dwc3_readl(dwc->regs, DWC3_GCTL);
> > + reg |= DWC3_GCTL_CORESOFTRESET;
> > + dwc3_writel(dwc->regs, DWC3_GCTL, reg);
> > +
> > + reg = dwc3_readl(dwc->regs, DWC3_GCTL);
> > + reg &= ~DWC3_GCTL_CORESOFTRESET;
> > + dwc3_writel(dwc->regs, DWC3_GCTL, reg);
> > +}
> > +
> >  static void __dwc3_set_mode(struct work_struct *work)
> >  {
> >   struct dwc3 *dwc = work_to_dwc(work);
> > @@ -156,6 +169,10 @@ static void __dwc3_set_mode(struct work_struct *work)
> >
> >   dwc3_set_prtcap(dwc, dwc->desired_dr_role);
> >
> > + /* Execute a GCTL Core Soft Reset when switch mode */
> > + if (dwc->gctl_reset_quirk)
> > + dwc3_gctl_core_soft_reset(dwc);
> > +
>
> In fact it is mentioned in the Synopsys databook to perform a GCTL
> CoreSoftReset when changing the PrtCapDir between device & host modes.
> So I think this should apply generally without a quirk. Further, it
> states to do this *prior* to writing PrtCapDir, so should it go before
> dwc3_set_prtcap() instead?

Sounds good. I have no such access to the hardware docs, so I really
appreciate your input here!

I'll refactor it as you describe and remove the quirk flag.

thanks
-john

linux-next: manual merge of the sound-asoc tree with the sound tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the sound-asoc tree got a conflict in:

  sound/soc/samsung/Kconfig

between commit:

  82e8d723e9e6 ("sound: Fix Kconfig indentation")

from the sound tree and commits:

  03081cc370b9 ("ASoC: samsung: arndale: Add support for WM1811 CODEC")
  dca6408d6f7e ("ASoC: samsung: Rename Arndale card driver")

from the sound-asoc tree.

I fixed it up (this latter commit also does what the sound tree commit
did) 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


pgp7RpKsOnEEI.pgp
Description: OpenPGP digital signature

Re: [PATCH] arm64: fix alternatives with LLVM's integrated assembler

[Sami Tolvanen]

On Mon, Oct 7, 2019 at 2:34 PM Nick Desaulniers  wrote:
> Should the definition of the ALTERNATIVE macro
> (arch/arm64/include/asm/alternative.h#L295) also be updated in this
> patch to not pass `1` as the final parameter?

No, that's the default value for cfg in case the caller omits the
parameter, and it's still needed.

> I get one error on linux-next that looks related:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang AS=clang
> -j71 arch/arm64/kvm/
> ...

This patch only touches the inline assembly version (i.e. when
compiling without -no-integrated-as), while with AS=clang you are
using clang also for stand-alone assembly code. I believe some
additional work is needed before we can do that.

> arch/arm64/kvm/hyp/entry.S:109:87: error: too many positional arguments
>  alternative_insn nop, .inst (0xd500401f | ((0) << 16 | (4) << 5) |
> ((!!1) << 8)), 4, 1
>
>^
>
> Since __ALTERNATIVE_CFG now takes one less arg, with your patch?

__ALTERNATIVE_CFG (with two underscores) is only defined for C code,
and this patch doesn't change the definition of _ALTERNATIVE_CFG (with
one underscore) that's used for stand-alone assembly.

Sami

Re: [PATCH] tpm: add check after commands attribs tab allocation

[Jerry Snitselaar]

On Mon Oct 07 19, Tadeusz Struk wrote:

devm_kcalloc() can fail and return NULL so we need to check for that.

Fixes: 58472f5cd4f6f ("tpm: validate TPM 2.0 commands")
Signed-off-by: Tadeusz Struk 
---
drivers/char/tpm/tpm2-cmd.c |4 
1 file changed, 4 insertions(+)

diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index ba9acae83bff..5817dfe5c5d2 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -939,6 +939,10 @@ static int tpm2_get_cc_attrs_tbl(struct tpm_chip *chip)

chip->cc_attrs_tbl = devm_kcalloc(>dev, 4, nr_commands,
  GFP_KERNEL);
+   if (!chip->cc_attrs_tbl) {
+   rc = -ENOMEM;
+   goto out;
+   }

rc = tpm_buf_init(, TPM2_ST_NO_SESSIONS, TPM2_CC_GET_CAPABILITY);
if (rc)



Reviewed-by: Jerry Snitselaar 

Re: [PATCH v3 1/2] tpm: Use GFP_KERNEL for allocating struct tpm_buf

[Jerry Snitselaar]

On Mon Oct 07 19, James Bottomley wrote:

From: James Bottomley 
Subject: [PATCH] tpm: use GFP kernel for tpm_buf allocations

The current code uses GFP_HIGHMEM, which is wrong because GFP_HIGHMEM
(on 32 bit systems) is memory ordinarily inaccessible to the kernel
and should only be used for allocations affecting userspace.  In order
to make highmem visible to the kernel on 32 bit it has to be kmapped,
which consumes valuable entries in the kmap region.  Since the tpm_buf
is only ever used in the kernel, switch to using a GFP_KERNEL
allocation so as not to waste kmap space on 32 bits.

Fixes: a74f8b36352e (tpm: introduce tpm_buf)
Signed-off-by: James Bottomley 
---


Reviewed-by: Jerry Snitselaar 

Re: Build regressions/improvements in v5.4-rc2

[Randy Dunlap]

On 10/7/19 2:04 PM, Geert Uytterhoeven wrote:
> Hi Randy,
> 
> On Mon, Oct 7, 2019 at 10:48 PM Randy Dunlap  wrote:
>> On 10/7/19 12:18 AM, Geert Uytterhoeven wrote:
>>> Below is the list of build error/warning regressions/improvements in
>>> v5.4-rc2[1] compared to v5.3[2].
>>>
>>> Summarized:
>>>   - build errors: +10/-3
>>>   - build warnings: +152/-143
>>>
>>> JFYI, when comparing v5.4-rc2[1] to v5.4-rc1[3], the summaries are:
>>>   - build errors: +5/-10
>>>   - build warnings: +44/-133
>>>
>>> Note that there may be false regressions, as some logs are incomplete.
>>> Still, they're build errors/warnings.
>>>
>>> Happy fixing! ;-)
>>>
>>> Thanks to the linux-next team for providing the build service.
>>>
>>> [1] 
>>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/da0c9ea146cbe92b832f1b0f694840ea8eb33cce/
>>>  (233 out of 242 configs)
>>> [2] 
>>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/4d856f72c10ecb060868ed10ff1b1453943fc6c8/
>>>  (all 242 configs)
>>> [3] 
>>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c/
>>>  (233 out of 242 configs)
>>>
>>>
>>> *** ERRORS ***
>>>
>>> 10 error regressions:
>>
>>>   + error: "__delay" [drivers/net/phy/mdio-cavium.ko] undefined!:  => N/A
>>
>> Hi Geert,
>>
>> What arch & config is the above build error from?
> 
> That was a new one in v5.4-rc1 for sh-allmodconfig (blamed on David Daney).

so it seems arch/sh/ needs include/asm/delay.h that at least does
#include 

eh?

>> Sorry to bug you about this.
> 
> Np.


-- 
~Randy