date:20200625

Hi Steven,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on tip/perf/core]
[also build test ERROR on linux/master linus/master v5.8-rc2 next-20200625]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Steven-Rostedt/ring-buffer-Have-nested-events-still-record-running-time-stamp/20200626-105715
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
bb42b3d39781d7fcd3be7f9f9bf11b6661b5fdf1
config: openrisc-allyesconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=openrisc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> kernel/trace/ring_buffer.c:30:10: fatal error: asm/local64.h: No such file 
>> or directory
  30 | #include 
 |  ^~~
   compilation terminated.

vim +30 kernel/trace/ring_buffer.c

28  
29  #include 
  > 30  #include 
31  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH 2/2] xen/privcmd: Convert get_user_pages() to pin_user_pages()

2020-06-25 Thread Souptick Joarder

On Thu, Jun 25, 2020 at 11:19 AM John Hubbard  wrote:
>
> On 2020-06-24 20:02, Souptick Joarder wrote:
> > In 2019, we introduced pin_user_pages*() and now we are converting
> > get_user_pages*() to the new API as appropriate. [1] & [2] could
> > be referred for more information. This is case 5 as per document [1].
> >
> > [1] Documentation/core-api/pin_user_pages.rst
> >
> > [2] "Explicit pinning of user-space pages":
> >  https://lwn.net/Articles/807108/
> >
> > Signed-off-by: Souptick Joarder 
> > Cc: John Hubbard 
> > Cc: Boris Ostrovsky 
> > Cc: Paul Durrant 
> > ---
> > Hi,
> >
> > I'm compile tested this, but unable to run-time test, so any testing
> > help is much appriciated.
> >
> >   drivers/xen/privcmd.c | 10 ++
> >   1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index 0da417c..eb05254 100644
> > --- a/drivers/xen/privcmd.c
> > +++ b/drivers/xen/privcmd.c
> > @@ -595,7 +595,7 @@ static int lock_pages(
> >   if (requested > nr_pages)
> >   return -ENOSPC;
> >
> > - page_count = get_user_pages_fast(
> > + page_count = pin_user_pages_fast(
> >   (unsigned long) kbufs[i].uptr,
> >   requested, FOLL_WRITE, pages);
> >   if (page_count < 0) {
> > @@ -612,13 +612,7 @@ static int lock_pages(
> >
> >   static void unlock_pages(struct page *pages[], unsigned int nr_pages)
> >   {
> > - unsigned int i;
> > -
> > - for (i = 0; i < nr_pages; i++) {
> > - if (!PageDirty(page))
> > - set_page_dirty_lock(page);
> > - put_page(pages[i]);
> > - }
> > + unpin_user_pages_dirty_lock(pages, nr_pages, 1);
>
> "true", not "1", is the correct way to call that function.

Ok.

>
> Also, this approach changes the behavior slightly, but I think it's
> reasonable to just set_page_dirty_lock() on the whole range--hard to
> see much benefit in checking PageDirty first.

unpin_user_pages_dirty_lock() internally will do the same check after
patch [2/2]
So I thought to keep old and new code in sync. Shall we avoid this check ?


>
>
> >   }
> >
> >   static long privcmd_ioctl_dm_op(struct file *file, void __user *udata)
> >
>
> thanks,
> --
> John Hubbard
> NVIDIA

Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry

2020-06-25 Thread Sumit Garg

On Thu, 25 Jun 2020 at 18:22, Maxim Uvarov  wrote:
>
> On Wed, 24 Jun 2020 at 18:44, Jerome Forissier  wrote:
> >
> >
> >
> > On 6/24/20 5:21 PM, James Bottomley wrote:
> > > On Wed, 2020-06-24 at 16:17 +0530, Sumit Garg wrote:
> > >> Apologies for delay in my reply as I was busy with some other stuff.
> > >>
> > >> On Fri, 19 Jun 2020 at 20:30, James Bottomley
> > >>  wrote:
> > > [...]
> > >>> it's about consistency with what the kernel types mean.  When some
> > >>> checker detects your using little endian operations on a big endian
> > >>> structure (like in the prink for instance) they're going to keep
> > >>> emailing you about it.
> > >>
> > >> As mentioned above, using different terminology is meant to cause
> > >> more confusion than just difference in endianness which is manageable
> > >> inside TEE.
> > >>
> > >> And I think it's safe to say that the kernel implements UUID in big
> > >> endian format and thus uses %pUb whereas OP-TEE implements UUID in
> > >> little endian format and thus uses %pUl.
> > >
> > > So what I think you're saying is that if we still had uuid_be and
> > > uuid_le you'd use uuid_le, because that's exactly the structure
> > > described in the docs.  But because we renamed
> > >
> > > uuid_be -> uuid_t
> > > uuid_le -> guid_t
> > >
> > > You can't use guid_t as a kernel type because it has the wrong name?
> >
> > Let me try to clear the confusion that I introduce myself I believe :-/
> > IMO:
> >
> > - optee_register_device(const uuid_t *device_uuid) *is* the correct
> > prototype.
> > - device_uuid is *guaranteed* to be BE because OP-TEE makes this
> > guarantee (it converts from its internal LE representation to BE when
> > enumerating the devices, but it doesn't matter to the kernel).
> > - Therefore %pUb is the correct format.
> >
> > I'm sorry for doubting the BE order initially. I am so used to OP-TEE
> > using LE internally, that I missed the fact that we have an explicit
> > conversion...
> >
> > Does this sound good?
> >
> > Thanks,
> > --
> > Jerome
>
> I think your description is correct. But I think this problem  would
> be solved outside of the current patchset.
> All places should use one single format (LE):
> -  internal optee representation;
> -  device enumeration pta;
> -  this kernel driver which creates sysfs entry and sets
> uid_copy(_device->id.uuid, device_uuid);
> -  matching function;
> -  drivers use UUID_INIT();
>
> In that way everything will be consistent. But it will require
> changing other pieces, not just the kernel. While
> these patches add functionality to support current device enumeration
> in optee os.
> So I think this version is ok to be applied.

I guess here you meant v9 patch-set. If yes then it's fine with me as well.

-Sumit

>
> Regards,
> Maxim.

Re: [PATCH net-next v2] xfrm: introduce oseq-may-wrap flag

2020-06-25 Thread Steffen Klassert

On Sat, May 30, 2020 at 02:39:12PM +0200, Petr Vaněk wrote:
> RFC 4303 in section 3.3.3 suggests to disable anti-replay for manually
> distributed ICVs in which case the sender does not need to monitor or
> reset the counter. However, the sender still increments the counter and
> when it reaches the maximum value, the counter rolls over back to zero.
> 
> This patch introduces new extra_flag XFRM_SA_XFLAG_OSEQ_MAY_WRAP which
> allows sequence number to cycle in outbound packets if set. This flag is
> used only in legacy and bmp code, because esn should not be negotiated
> if anti-replay is disabled (see note in 3.3.3 section).
> 
> Signed-off-by: Petr Vaněk 

Now applied to ipsec-next, thanks a lot!

Re: linux-next: umh: fix processed error when UMH_WAIT_PROC is used seems to break linux bridge on s390x (bisected)

2020-06-25 Thread Christian Borntraeger




On 26.06.20 04:54, Luis Chamberlain wrote:
> On Wed, Jun 24, 2020 at 08:37:55PM +0200, Christian Borntraeger wrote:
>>
>>
>> On 24.06.20 20:32, Christian Borntraeger wrote:
>> [...]> 
>>> So the translations look correct. But your change is actually a sematic 
>>> change
>>> if(ret) will only trigger if there is an error
>>> if (KWIFEXITED(ret)) will always trigger when the process ends. So we will 
>>> always overwrite -ECHILD
>>> and we did not do it before. 
>>>
>>
>> So the right fix is
>>
>> diff --git a/kernel/umh.c b/kernel/umh.c
>> index f81e8698e36e..a3a3196e84d1 100644
>> --- a/kernel/umh.c
>> +++ b/kernel/umh.c
>> @@ -154,7 +154,7 @@ static void call_usermodehelper_exec_sync(struct 
>> subprocess_info *sub_info)
>>  * the real error code is already in sub_info->retval or
>>  * sub_info->retval is 0 anyway, so don't mess with it then.
>>  */
>> -   if (KWIFEXITED(ret))
>> +   if (KWEXITSTATUS(ret))
>> sub_info->retval = KWEXITSTATUS(ret);
>> }
>>  
>> I think.
> 
> Nope, the right form is to check for WIFEXITED() before using WEXITSTATUS().

But this IS a change over the previous code, no?
I will test next week as I am travelling right now.

[rcu:rcu/urgent] BUILD SUCCESS b58e733fd774f3f4b49d9e7640d172a57e35200e

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  
rcu/urgent
branch HEAD: b58e733fd774f3f4b49d9e7640d172a57e35200e  rcu: Fixup noinstr 
warnings

elapsed time: 723m

configs tested: 120
configs skipped: 5

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

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
arc haps_hs_smp_defconfig
s390 allyesconfig
powerpc  g5_defconfig
mipsjmr3927_defconfig
sh   se7751_defconfig
arm   imx_v6_v7_defconfig
armxcep_defconfig
arm  pxa255-idp_defconfig
arm  tango4_defconfig
arm   mainstone_defconfig
arm  moxart_defconfig
m68kq40_defconfig
sh  sdk7786_defconfig
s390  allnoconfig
armmps2_defconfig
arm pxa_defconfig
arm lpc18xx_defconfig
mips   ip27_defconfig
arm eseries_pxa_defconfig
mips  loongson3_defconfig
i386 alldefconfig
nds32 allnoconfig
sh   se7724_defconfig
mips loongson1b_defconfig
pariscallnoconfig
armlart_defconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
powerpc defconfig
i386 randconfig-a002-20200624
i386 randconfig-a006-20200624
i386 randconfig-a003-20200624
i386 randconfig-a001-20200624
i386 randconfig-a005-20200624
i386 randconfig-a004-20200624
i386 randconfig-a013-20200624
i386 randconfig-a016-20200624
i386 randconfig-a012-20200624
i386 randconfig-a014-20200624
i386 randconfig-a011-20200624
i386 randconfig-a015-20200624
x86_64   randconfig-a004-20200624
x86_64   randconfig-a002-20200624
x86_64   randconfig-a003-20200624
x86_64   randconfig-a005-20200624
x86_64   randconfig-a001-20200624
x86_64   randconfig-a006-20200624
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allmodconfig
s390

[rcu:rcu/test] BUILD SUCCESS 12f2d29942ce0b140b8f03679d9f1d36d552fa70

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  rcu/test
branch HEAD: 12f2d29942ce0b140b8f03679d9f1d36d552fa70  Merge remote-tracking 
branch 'linus/master' into HEAD

elapsed time: 723m

configs tested: 120
configs skipped: 5

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

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
arc haps_hs_smp_defconfig
s390 allyesconfig
powerpc  g5_defconfig
mipsjmr3927_defconfig
sh   se7751_defconfig
arm   imx_v6_v7_defconfig
armxcep_defconfig
arm  pxa255-idp_defconfig
arm  tango4_defconfig
arm   mainstone_defconfig
arm  moxart_defconfig
m68kq40_defconfig
sh  sdk7786_defconfig
s390  allnoconfig
armmps2_defconfig
arm pxa_defconfig
arm lpc18xx_defconfig
mips   ip27_defconfig
arm eseries_pxa_defconfig
i386 alldefconfig
nds32 allnoconfig
sh   se7724_defconfig
mips loongson1b_defconfig
pariscallnoconfig
armlart_defconfig
mips  loongson3_defconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a002-20200624
i386 randconfig-a006-20200624
i386 randconfig-a003-20200624
i386 randconfig-a001-20200624
i386 randconfig-a005-20200624
i386 randconfig-a004-20200624
i386 randconfig-a013-20200624
i386 randconfig-a016-20200624
i386 randconfig-a012-20200624
i386 randconfig-a014-20200624
i386 randconfig-a011-20200624
i386 randconfig-a015-20200624
x86_64   randconfig-a004-20200624
x86_64   randconfig-a002-20200624
x86_64   randconfig-a003-20200624
x86_64   randconfig-a005-20200624
x86_64   randconfig-a001-20200624
x86_64   randconfig-a006-20200624
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390

Re: [PATCH v6 0/6] workingset protection/detection on the anonymous LRU list

2020년 6월 17일 (수) 오후 2:26, 님이 작성:
>
> From: Joonsoo Kim 
>
> Hello,
>
> This patchset implements workingset protection and detection on
> the anonymous LRU list.
>
> * Changes on v6
> - rework to reflect a new LRU balance model
> - remove memcg charge timing stuff on v5 since alternative is already
> merged on mainline
> - remove readahead stuff on v5 (reason is the same with above)
> - clear shadow entry if corresponding swap entry is deleted
> (mm/swapcache: support to handle the exceptional entries in swapcache)
> - change experiment environment
> (from ssd swap to ram swap, for fast evaluation and for reducing side-effect 
> of I/O)
> - update performance number

Hello, Johannes.

Could you review the v6 patchset?

Some minor things have changed so it's really welcome if you review the patchset
again. Especially, "mm/swap: implement workingset detection for anonymous LRU"
doesn't get any ack yet. :)

Thanks.

Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry

2020-06-25 Thread Sumit Garg

On Thu, 25 Jun 2020 at 18:22, Maxim Uvarov  wrote:
>
> On Wed, 24 Jun 2020 at 18:44, Jerome Forissier  wrote:
> >
> >
> >
> > On 6/24/20 5:21 PM, James Bottomley wrote:
> > > On Wed, 2020-06-24 at 16:17 +0530, Sumit Garg wrote:
> > >> Apologies for delay in my reply as I was busy with some other stuff.
> > >>
> > >> On Fri, 19 Jun 2020 at 20:30, James Bottomley
> > >>  wrote:
> > > [...]
> > >>> it's about consistency with what the kernel types mean.  When some
> > >>> checker detects your using little endian operations on a big endian
> > >>> structure (like in the prink for instance) they're going to keep
> > >>> emailing you about it.
> > >>
> > >> As mentioned above, using different terminology is meant to cause
> > >> more confusion than just difference in endianness which is manageable
> > >> inside TEE.
> > >>
> > >> And I think it's safe to say that the kernel implements UUID in big
> > >> endian format and thus uses %pUb whereas OP-TEE implements UUID in
> > >> little endian format and thus uses %pUl.
> > >
> > > So what I think you're saying is that if we still had uuid_be and
> > > uuid_le you'd use uuid_le, because that's exactly the structure
> > > described in the docs.  But because we renamed
> > >
> > > uuid_be -> uuid_t
> > > uuid_le -> guid_t
> > >
> > > You can't use guid_t as a kernel type because it has the wrong name?
> >
> > Let me try to clear the confusion that I introduce myself I believe :-/
> > IMO:
> >
> > - optee_register_device(const uuid_t *device_uuid) *is* the correct
> > prototype.
> > - device_uuid is *guaranteed* to be BE because OP-TEE makes this
> > guarantee (it converts from its internal LE representation to BE when
> > enumerating the devices, but it doesn't matter to the kernel).
> > - Therefore %pUb is the correct format.
> >
> > I'm sorry for doubting the BE order initially. I am so used to OP-TEE
> > using LE internally, that I missed the fact that we have an explicit
> > conversion...
> >
> > Does this sound good?
> >
> > Thanks,
> > --
> > Jerome
>
> I think your description is correct. But I think this problem  would
> be solved outside of the current patchset.
> All places should use one single format (LE):

I guess you missed the point that uuid_t is implemented in BE format
in the kernel which is compliant as per RFC 4122.

> -  internal optee representation;
> -  device enumeration pta;
> -  this kernel driver which creates sysfs entry and sets
> uid_copy(_device->id.uuid, device_uuid);
> -  matching function;
> -  drivers use UUID_INIT();

See carefully the implementation of UUID_INIT() which is in BE format.

-Sumit

>
> In that way everything will be consistent. But it will require
> changing other pieces, not just the kernel. While
> these patches add functionality to support current device enumeration
> in optee os.
> So I think this version is ok to be applied.
>
> Regards,
> Maxim.

Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry

2020-06-25 Thread Sumit Garg

On Fri, 26 Jun 2020 at 05:01, James Bottomley
 wrote:
>
> On Thu, 2020-06-25 at 19:54 +0530, Sumit Garg wrote:
> > On Wed, 24 Jun 2020 at 20:51, James Bottomley
> >  wrote:
> > >
> > > On Wed, 2020-06-24 at 16:17 +0530, Sumit Garg wrote:
> > > > Apologies for delay in my reply as I was busy with some other
> > > > stuff.
> > > >
> > > > On Fri, 19 Jun 2020 at 20:30, James Bottomley
> > > >  wrote:
> > >
> > > [...]
> > > > > it's about consistency with what the kernel types mean.  When
> > > > > some checker detects your using little endian operations on a
> > > > > big endian structure (like in the prink for instance) they're
> > > > > going to keep emailing you about it.
> > > >
> > > > As mentioned above, using different terminology is meant to cause
> > > > more confusion than just difference in endianness which is
> > > > manageable inside TEE.
> > > >
> > > > And I think it's safe to say that the kernel implements UUID in
> > > > big endian format and thus uses %pUb whereas OP-TEE implements
> > > > UUID in little endian format and thus uses %pUl.
> > >
> > > So what I think you're saying is that if we still had uuid_be and
> > > uuid_le you'd use uuid_le, because that's exactly the structure
> > > described in the docs.  But because we renamed
> > >
> > > uuid_be -> uuid_t
> > > uuid_le -> guid_t
> > >
> > > You can't use guid_t as a kernel type because it has the wrong
> > > name?
> >
> > Isn't the rename commit description [1] pretty clear about which is
> > the true UUID type from Linux point of view?
>
> I don't think the kernel code takes a position on eternal verity, just
> on logical or arithmetic truth.  We just have to deal with both LE and
> BE UUIDs so we have appropriate types for them and the LE type is now
> named guid_t.  They're both equally correct to use provided the use
> case matches the designed one. So does the name really matter?

Yes it does. I guess I have provided enough reasoning for that. Also,
the rename commit itself illustrates its importance and clarifies the
use case for which they are meant to be used.

> If we
> did
>
> #define uuid_le_t guid_t
>
> would you be happy? (not that the kernel cares about karmic emotional
> states either ...)

It's not about me being happy but more about confusion and
inconsistency it will bring.

IMO, either kernel should be opinionated about UUID endianness like
currently it is:

uuid_t and its corresponding helpers (eg. UUID_INIT) follows BE format.

or support both endianness for UUID (no common type: uuid_t) like we
had earlier prior to rename commit:

uuid_be_t and its corresponding helpers (eg. UUID_BE_INIT) follow BE format.
uuid_le_t and its corresponding helpers (eg. UUID_LE_INIT) follow LE format.

But even if we consider later case as well, I am still not sure if we
can switch to uuid_le_t as it's been part of TEE core ABI
(open_session) where UUID is passed in BE format (see LE to BE
conversion in TEE client [1] and vice-versa in OP-TEE OS [2]) and
won't be a backwards compatible change.

[1] 
https://github.com/OP-TEE/optee_client/blob/master/libteec/src/tee_client_api.c#L595
[2] 
https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/ree_fs_ta.c#L92

-Sumit

>
> James
>

Re: [PATCH 08/12] driver-core: Introduce DEVICE_ATTR_ADMIN_{RO,RW}

2020-06-25 Thread Dan Williams

On Thu, Jun 25, 2020 at 10:06 PM Greg Kroah-Hartman
 wrote:
>
> On Thu, Jun 25, 2020 at 04:51:03PM -0700, Dan Williams wrote:
> > A common pattern for using plain DEVICE_ATTR() instead of
> > DEVICE_ATTR_RO() and DEVICE_ATTR_RW() is for attributes that want to
> > limit read to only root.  I.e. many users of DEVICE_ATTR() are
> > specifying 0400 or 0600 for permissions.
> >
> > Given the expectation that CAP_SYS_ADMIN is needed to access these
> > sensitive attributes and an explicit helper with the _ADMIN_ identifier
> > for DEVICE_ATTR_ADMIN_{RO,RW}.
> >
> > Cc: Greg Kroah-Hartman 
> > Cc: "Rafael J. Wysocki" 
> > Signed-off-by: Dan Williams 
> > ---
> >  include/linux/device.h |4 
> >  include/linux/sysfs.h  |7 +++
> >  2 files changed, 11 insertions(+)
> >
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 15460a5ac024..d7c2570368fa 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -128,8 +128,12 @@ ssize_t device_store_bool(struct device *dev, struct 
> > device_attribute *attr,
> >   __ATTR_PREALLOC(_name, _mode, _show, _store)
> >  #define DEVICE_ATTR_RW(_name) \
> >   struct device_attribute dev_attr_##_name = __ATTR_RW(_name)
> > +#define DEVICE_ATTR_ADMIN_RW(_name) \
> > + struct device_attribute dev_attr_##_name = __ATTR_RW_MODE(_name, 0600)
> >  #define DEVICE_ATTR_RO(_name) \
> >   struct device_attribute dev_attr_##_name = __ATTR_RO(_name)
> > +#define DEVICE_ATTR_ADMIN_RO(_name) \
> > + struct device_attribute dev_attr_##_name = __ATTR_RO_MODE(_name, 0400)
> >  #define DEVICE_ATTR_WO(_name) \
> >   struct device_attribute dev_attr_##_name = __ATTR_WO(_name)
> >  #define DEVICE_ULONG_ATTR(_name, _mode, _var) \
> > diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> > index 86067dbe7745..34e84122f635 100644
> > --- a/include/linux/sysfs.h
> > +++ b/include/linux/sysfs.h
> > @@ -123,6 +123,13 @@ struct attribute_group {
> >   .show   = _name##_show, \
> >  }
> >
> > +#define __ATTR_RW_MODE(_name, _mode) { 
> >   \
> > + .attr   = { .name = __stringify(_name), \
> > + .mode = VERIFY_OCTAL_PERMISSIONS(_mode) },  \
> > + .show   = _name##_show, \
> > + .store  = _name##_store,\
> > +}
> > +
> >  #define __ATTR_WO(_name) {   \
> >   .attr   = { .name = __stringify(_name), .mode = 0200 }, \
> >   .store  = _name##_store,\
> >
>
> Nice!  Want me to take this now, I know of many other places that could
> be cleaned up to use this (like the raw device bug that I just fixed...)

Sure, that'd be great.

> If not:
>
> Reviewed-by: Greg Kroah-Hartman 

 Thanks Greg.

Re: [PATCH v6 4/6] mm/swapcache: support to handle the exceptional entries in swapcache

2020년 6월 19일 (금) 오전 10:33, Joonsoo Kim 님이 작성:
>
> On Wed, Jun 17, 2020 at 05:17:17AM -0700, Matthew Wilcox wrote:
> > On Wed, Jun 17, 2020 at 02:26:21PM +0900, js1...@gmail.com wrote:
> > > From: Joonsoo Kim 
> > >
> > > Swapcache doesn't handle the exceptional entries since there is no case
> >
> > Don't call them exceptional entries.
> >
> > The radix tree has/had the concecpt of exceptional entries.  The swapcache
> > doesn't use the radix tree any more, it uses the XArray.  The XArray
> > has value entries.
> >
> > But you shouldn't call them value entries either; that's an XArray
> > concept.  The swap cache and indeed page cache use value entries to
> > implement shadow entries (they're also used to implement dax entries and
> > swap entries in the page cache).  So just call them shadow entries here.
> >
> > I know there are still places which use the term 'nrexceptional' in
> > the kernel.  I just haven't got round to replacing them yet.  Please
> > don't add more.
>
> Okay! Thanks for commenting.
>
> >
> > > +void clear_shadow_from_swap_cache(int type, unsigned long begin,
> > > +   unsigned long end)
> > > +{
> > > +   unsigned long curr;
> > > +   void *old;
> > > +   swp_entry_t entry = swp_entry(type, begin);
> > > +   struct address_space *address_space = swap_address_space(entry);
> > > +   XA_STATE(xas, _space->i_pages, begin);
> > > +
> > > +retry:
> > > +   xa_lock_irq(_space->i_pages);
> > > +   for (curr = begin; curr <= end; curr++) {
> > > +   entry = swp_entry(type, curr);
> > > +   if (swap_address_space(entry) != address_space) {
> > > +   xa_unlock_irq(_space->i_pages);
> > > +   address_space = swap_address_space(entry);
> > > +   begin = curr;
> > > +   xas_set(, begin);
> > > +   goto retry;
> > > +   }
> > > +
> > > +   old = xas_load();
> > > +   if (!xa_is_value(old))
> > > +   continue;
> > > +   xas_store(, NULL);
> > > +   address_space->nrexceptional--;
> > > +   xas_next();
> > > +   }
> > > +   xa_unlock_irq(_space->i_pages);
> > > +}
> >
> > This is a very clunky loop.  I'm not sure it's even right, given that
> > you change address space without changing the xas's address space.  How
> > about this?
>
> You are correct. The xas's address space should be changed.
>
>
> >   for (;;) {
> >   XA_STATE(xas, _space->i_pages, begin);
> >   unsigned long nr_shadows = 0;
> >
> >   xas_lock_irq();
> >   xas_for_each(, entry, end) {
> >   if (!xa_is_value(entry))
> >   continue;
> >   xas_store(, NULL);
> >   nr_shadows++;
> >   }
> >   address_space->nr_exceptionals -= nr_shadows;
> >   xas_unlock_irq();
> >
> >   if (xas.xa_index >= end)
> >   break;
> >   entry = swp_entry(type, xas.xa_index);
> >   address_space = swap_address_space(entry);
> >   }
>
> Thanks for suggestion.
>
> I make a patch based on your suggestion. IIUC about Xarray,
> after running xas_for_each(), xas.xa_index can be less than the end if
> there are empty slots on last portion of array. Handling this case is
> also considered in my patch.

Hello, Matthew.

Could you check if the following patch (Xarray part) is correct?
Since I made a patch based on your suggestion, I'd like to get your review. :)

Thanks.

> Thanks.
>
> --->8
> From 72e97600ea294372a13ab8e208ebd3c0e1889408 Mon Sep 17 00:00:00 2001
> From: Joonsoo Kim 
> Date: Fri, 15 Nov 2019 09:48:32 +0900
> Subject: [PATCH v6 4/6] mm/swapcache: support to handle the shadow entries
>
> Workingset detection for anonymous page will be implemented in the
> following patch and it requires to store the shadow entries into the
> swapcache. This patch implements an infrastructure to store the shadow
> entry in the swapcache.
>
> Acked-by: Johannes Weiner 
> Signed-off-by: Joonsoo Kim 
> ---
>  include/linux/swap.h | 17 
>  mm/shmem.c   |  3 ++-
>  mm/swap_state.c  | 57 
> ++--
>  mm/swapfile.c|  2 ++
>  mm/vmscan.c  |  2 +-
>  5 files changed, 69 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index f4f5f94..901da54 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -416,9 +416,13 @@ extern struct address_space *swapper_spaces[];
>  extern unsigned long total_swapcache_pages(void);
>  extern void show_swap_cache_info(void);
>  extern int add_to_swap(struct page *page);
> -extern int add_to_swap_cache(struct page *, swp_entry_t, gfp_t);
> -extern void __delete_from_swap_cache(struct page *, swp_entry_t entry);
> +extern int

Re: [PATCH 08/12] driver-core: Introduce DEVICE_ATTR_ADMIN_{RO,RW}

On Thu, Jun 25, 2020 at 04:51:03PM -0700, Dan Williams wrote:
> A common pattern for using plain DEVICE_ATTR() instead of
> DEVICE_ATTR_RO() and DEVICE_ATTR_RW() is for attributes that want to
> limit read to only root.  I.e. many users of DEVICE_ATTR() are
> specifying 0400 or 0600 for permissions.
> 
> Given the expectation that CAP_SYS_ADMIN is needed to access these
> sensitive attributes and an explicit helper with the _ADMIN_ identifier
> for DEVICE_ATTR_ADMIN_{RO,RW}.
> 
> Cc: Greg Kroah-Hartman 
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Dan Williams 
> ---
>  include/linux/device.h |4 
>  include/linux/sysfs.h  |7 +++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 15460a5ac024..d7c2570368fa 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -128,8 +128,12 @@ ssize_t device_store_bool(struct device *dev, struct 
> device_attribute *attr,
>   __ATTR_PREALLOC(_name, _mode, _show, _store)
>  #define DEVICE_ATTR_RW(_name) \
>   struct device_attribute dev_attr_##_name = __ATTR_RW(_name)
> +#define DEVICE_ATTR_ADMIN_RW(_name) \
> + struct device_attribute dev_attr_##_name = __ATTR_RW_MODE(_name, 0600)
>  #define DEVICE_ATTR_RO(_name) \
>   struct device_attribute dev_attr_##_name = __ATTR_RO(_name)
> +#define DEVICE_ATTR_ADMIN_RO(_name) \
> + struct device_attribute dev_attr_##_name = __ATTR_RO_MODE(_name, 0400)
>  #define DEVICE_ATTR_WO(_name) \
>   struct device_attribute dev_attr_##_name = __ATTR_WO(_name)
>  #define DEVICE_ULONG_ATTR(_name, _mode, _var) \
> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> index 86067dbe7745..34e84122f635 100644
> --- a/include/linux/sysfs.h
> +++ b/include/linux/sysfs.h
> @@ -123,6 +123,13 @@ struct attribute_group {
>   .show   = _name##_show, \
>  }
>  
> +#define __ATTR_RW_MODE(_name, _mode) {   
> \
> + .attr   = { .name = __stringify(_name), \
> + .mode = VERIFY_OCTAL_PERMISSIONS(_mode) },  \
> + .show   = _name##_show, \
> + .store  = _name##_store,\
> +}
> +
>  #define __ATTR_WO(_name) {   \
>   .attr   = { .name = __stringify(_name), .mode = 0200 }, \
>   .store  = _name##_store,\
> 

Nice!  Want me to take this now, I know of many other places that could
be cleaned up to use this (like the raw device bug that I just fixed...)

If not:

Reviewed-by: Greg Kroah-Hartman

Re: [PATCH v3 6/8] mm/gup: use a standard migration target allocation callback

2020년 6월 25일 (목) 오후 9:08, Michal Hocko 님이 작성:
>
> On Tue 23-06-20 15:13:46, Joonsoo Kim wrote:
> > From: Joonsoo Kim 
> >
> > There is a well-defined migration target allocation callback.
> > It's mostly similar with new_non_cma_page() except considering CMA pages.
> >
> > This patch adds a CMA consideration to the standard migration target
> > allocation callback and use it on gup.c.
>
> We already can express that by a missing __GFP_MOVABLE so I would rather
> not introduce a duplication in form of another flag.

I replied to this question in a previous email.

Thanks.

Re: [PATCH v3 5/8] mm/migrate: make a standard migration target allocation function

2020년 6월 25일 (목) 오후 9:05, Michal Hocko 님이 작성:
>
> On Tue 23-06-20 15:13:45, Joonsoo Kim wrote:
> > From: Joonsoo Kim 
> >
> > There are some similar functions for migration target allocation. Since
> > there is no fundamental difference, it's better to keep just one rather
> > than keeping all variants. This patch implements base migration target
> > allocation function. In the following patches, variants will be converted
> > to use this function.
> >
> > Note that PageHighmem() call in previous function is changed to open-code
> > "is_highmem_idx()" since it provides more readability.
>
> I was little bit surprised that alloc_migration_target still uses
> private argument while it only accepts migration_target_control
> structure pointer but then I have noticed that you are using it as a
> real callback in a later patch.
>
> > Signed-off-by: Joonsoo Kim 
>
> Few questions inline
> [...]
>
> > diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> > index 47b8ccb..820ea5e 100644
> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -1648,9 +1648,13 @@ EXPORT_SYMBOL(unpoison_memory);
> >
> >  static struct page *new_page(struct page *p, unsigned long private)
> >  {
> > - int nid = page_to_nid(p);
> > + struct migration_target_control mtc = {
> > + .nid = page_to_nid(p),
> > + .nmask = _states[N_MEMORY],
>
> This could be .namsk = NULL, right? alloc_migration_target doesn't
> modify the node mask and NULL nodemask is always interpreted as all
> available nodes.

Will do.

> > + .gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL,
> > + };
> >
> > - return new_page_nodemask(p, nid, _states[N_MEMORY]);
> > + return alloc_migration_target(p, (unsigned long));
> >  }
> >
> [...]
> > diff --git a/mm/migrate.c b/mm/migrate.c
> > index 634f1ea..3afff59 100644
> > --- a/mm/migrate.c
> > +++ b/mm/migrate.c
> > @@ -1536,29 +1536,34 @@ int migrate_pages(struct list_head *from, 
> > new_page_t get_new_page,
> >   return rc;
> >  }
> >
> > -struct page *new_page_nodemask(struct page *page,
> > - int preferred_nid, nodemask_t *nodemask)
> > +struct page *alloc_migration_target(struct page *page, unsigned long 
> > private)
> >  {
> > - gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL;
> > + struct migration_target_control *mtc;
> > + gfp_t gfp_mask;
> >   unsigned int order = 0;
> >   struct page *new_page = NULL;
> > + int zidx;
> > +
> > + mtc = (struct migration_target_control *)private;
> > + gfp_mask = mtc->gfp_mask;
> >
> >   if (PageHuge(page)) {
> >   return alloc_huge_page_nodemask(
> > - page_hstate(compound_head(page)),
> > - preferred_nid, nodemask, 0, false);
> > + page_hstate(compound_head(page)), mtc->nid,
> > + mtc->nmask, gfp_mask, false);
> >   }
> >
> >   if (PageTransHuge(page)) {
> > + gfp_mask &= ~__GFP_RECLAIM;
>
> What's up with this gfp_mask modification?

THP page allocation uses a standard gfp masks, GFP_TRANSHUGE_LIGHT and
GFP_TRANHUGE. __GFP_RECLAIM flags is a big part of this standard mask design.
So, I clear it here so as not to disrupt the THP gfp mask.

> >   gfp_mask |= GFP_TRANSHUGE;
> >   order = HPAGE_PMD_ORDER;
> >   }
> > -
> > - if (PageHighMem(page) || (zone_idx(page_zone(page)) == ZONE_MOVABLE))
> > + zidx = zone_idx(page_zone(page));
> > + if (is_highmem_idx(zidx) || zidx == ZONE_MOVABLE)
> >   gfp_mask |= __GFP_HIGHMEM;
> >
> >   new_page = __alloc_pages_nodemask(gfp_mask, order,
> > - preferred_nid, nodemask);
> > + mtc->nid, mtc->nmask);
> >
> >   if (new_page && PageTransHuge(new_page))
> >   prep_transhuge_page(new_page);
> > diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> > index aec26d9..adba031 100644
> > --- a/mm/page_isolation.c
> > +++ b/mm/page_isolation.c
> > @@ -309,7 +309,11 @@ int test_pages_isolated(unsigned long start_pfn, 
> > unsigned long end_pfn,
> >
> >  struct page *alloc_migrate_target(struct page *page, unsigned long private)
> >  {
> > - int nid = page_to_nid(page);
> > + struct migration_target_control mtc = {
> > + .nid = page_to_nid(page),
> > + .nmask = _states[N_MEMORY],
>
> nmask = NULL again

Okay.

Thanks.

Re: [PATCH] mm/spase: never partially remove memmap for early section

2020-06-25 Thread David Hildenbrand




> Am 26.06.2020 um 00:40 schrieb Wei Yang :
> 
> On Thu, Jun 25, 2020 at 07:53:37AM +0200, David Hildenbrand wrote:
>> 
>> 
 Am 25.06.2020 um 01:47 schrieb Dan Williams :
>>> 
>>> On Wed, Jun 24, 2020 at 3:44 PM Wei Yang
>>>  wrote:
>>> [..]
> So, you are right that there is a mismatch here, but I think the
> comprehensive fix is to allow early sections to be partially
> depopulated/repopulated rather than have section_activate() and
> section_deacticate() special case early sections. The special casing
> is problematic in retrospect as section_deactivate() can't be
> maintained without understand special rules in section_activate().
 
 Hmm... This means we need to adjust pfn_valid() too, which always return 
 true
 for early sections.
>>> 
>>> Right, rather than carry workarounds in 3 locations, and the bug that
>>> has resulted from then getting out of sync, just teach early section
>>> mapping to allow for the subsection populate/depopulate.
>>> 
>> 
>> I prefer the easy fix first - IOW what we Here here. Especially, 
>> pfn_to_online_page() will need changes as well.
>> 
> 
> Hi, David,
> 
> Which part of pfn_to_online_page() needs to be changed? pfn_valid_within()
> would call pfn_valid() to check the pfn first. This looks enough for me.

Not for all configurations. For some (e.g., x86 iirc) it‘s just a nop.

[PATCH RFC 1/5] dt-bindings: add binding for CDNSP-DRD controller

This patch aim at documenting USB related dt-bindings for the
Cadence CDNSP-DRD controller.

Signed-off-by: Pawel Laszczak 
---
 .../devicetree/bindings/usb/cdns-cdnsp.yaml   | 104 ++
 1 file changed, 104 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/cdns-cdnsp.yaml

diff --git a/Documentation/devicetree/bindings/usb/cdns-cdnsp.yaml 
b/Documentation/devicetree/bindings/usb/cdns-cdnsp.yaml
new file mode 100644
index ..83d353711e31
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/cdns-cdnsp.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/cdns-cdnsp.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title:  Device tree binding for Cadence CDNSP (Super Speed Plus) controller
+
+maintainers:
+  - Pawel Laszczak 
+
+description:
+  The Cadence CDNSP controller support Host, Device and DRD mode.
+  It also supports Full Speed, Hight Speed, Super Speed and
+  Super Speed Plus protocols.
+
+properties:
+  compatible:
+items:
+  - enum:
+- cdns,usbssp
+
+  reg:
+description: Physical base address and size of the
+ controller's register areas. Controller has
+ three  different regions.
+minItems: 2
+maxItems: 3
+items:
+  - description: HOST registers area.
+  - description: DEVICE registers area.
+  - description: OTG/DRD registers area.
+
+  reg-names:
+items:
+  - const: xhci
+  - const: dev
+  - const: otg
+
+  interrupts:
+minItems: 2
+maxItems: 3
+items:
+  - description: Interrupt used by XHCI driver.
+  - description: Interrupt used by device driver.
+  - description: Interrupt used by DRD part of driver.
+
+  interrupt-names:
+items:
+  - const: host
+  - const: peripheral
+  - const: otg
+
+  maximum-speed:
+enum:
+  - full-speed
+  - high-speed
+  - super-speed
+  - super-speed-plus
+
+  dr_mode:
+enum:
+  - host
+  - peripheral
+  - otg
+
+  phys:
+description:
+  Reference to the USB PHY.
+  Must contain an entry for each entry in phy-names.
+  See ../phy/phy-bindings.txt for details.
+
+  phy-names:
+items:
+  - const: cdnsp,usb2-phy
+  - const: cdnsp,usb3-phy
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - interrupts
+  - interrupt-names
+
+examples:
+  - |
+#include 
+
+usb_otg: usb@f300 {
+  compatible = "cdns,usbssp";
+  reg = <0x00 0x01c13000 0x00 0x0400>,
+<0x00 0xf301 0x00 0x1>,
+<0x00 0xf302 0x00 0x1>;
+  reg-names = "xhci", "dev", "otg";
+  interrupts = ,
+   ,
+   ;
+  interrupt-names = "host", "peripheral", "otg";
+  phys = < 0>;
+  phy-names = "cdnsp,usb2-phy", "cdnsp,usb3-phy";
+  dr_mode = "peripheral";
+};
+
+...
-- 
2.17.1

[PATCH RFC 3/5] usb: cdnsp: Device side header file for CDNSP driver

Patch defines macros, registers and structures used by
Device side driver.

Because the size of main patch is very big, I’ve decided to create
separate patch for gadget.h. It should simplify reviewing the code.

Signed-off-by: Pawel Laszczak 
---
 drivers/usb/cdnsp/gadget.h | 1446 
 1 file changed, 1446 insertions(+)
 create mode 100644 drivers/usb/cdnsp/gadget.h

diff --git a/drivers/usb/cdnsp/gadget.h b/drivers/usb/cdnsp/gadget.h
new file mode 100644
index ..edc37763a3b7
--- /dev/null
+++ b/drivers/usb/cdnsp/gadget.h
@@ -0,0 +1,1446 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Cadence CDNSP DRD Driver.
+ *
+ * Copyright (C) 2020 Cadence.
+ *
+ * Author: Pawel Laszczak 
+ *
+ * Code based on Linux XHCI driver.
+ * Origin: Copyright (C) 2008 Intel Corp.
+ */
+#ifndef __LINUX_CDNSP_GADGET_H
+#define __LINUX_CDNSP_GADGET_H
+
+#include 
+#include 
+#include 
+
+/* Max number slots - only 1 is allowed. */
+#define CDNSP_DEV_MAX_SLOTS1
+
+#define CDNSP_EP0_SETUP_SIZE   512
+
+/*16 for in and 16 for out. */
+#define CDNSP_ENDPOINTS_NUM32
+
+/* Best Effort Service Latency. */
+#define CDNSP_DEFAULT_BESL 0
+
+/* Device Controller command default timeout value in us */
+#define CDNSP_CMD_TIMEOUT  (15 * 1000)
+
+/* Up to 16 ms to halt an device controller */
+#define CDNSP_MAX_HALT_USEC(16 * 1000)
+
+/*
+ * Controller register interface.
+ */
+
+/**
+ * struct cdnsp_cap_regs - CDNSP Registers.
+ * @hc_capbase:Length of the capabilities register and controller
+ *  version number
+ * @hcs_params1: HCSPARAMS1 - Structural Parameters 1
+ * @hcs_params2: HCSPARAMS2 - Structural Parameters 2
+ * @hcs_params3: HCSPARAMS3 - Structural Parameters 3
+ * @hcc_params: HCCPARAMS - Capability Parameters
+ * @db_off: DBOFF - Doorbell array offset
+ * @run_regs_off: RTSOFF - Runtime register space offset
+ * @hcc_params2: HCCPARAMS2 Capability Parameters 2,
+ */
+struct cdnsp_cap_regs {
+   __le32 hc_capbase;
+   __le32 hcs_params1;
+   __le32 hcs_params2;
+   __le32 hcs_params3;
+   __le32 hcc_params;
+   __le32 db_off;
+   __le32 run_regs_off;
+   __le32 hcc_params2;
+   /* Reserved up to (CAPLENGTH - 0x1C) */
+};
+
+/* hc_capbase bitmasks. */
+/* bits 7:0 - how long is the Capabilities register. */
+#define HC_LENGTH(p)   (((p) >> 00) & GENMASK(7, 0))
+/* bits 31:16  */
+#define HC_VERSION(p)  (((p) >> 16) & GENMASK(15, 1))
+
+/* HCSPARAMS1 - hcs_params1 - bitmasks */
+/* bits 0:7, Max Device Endpoints */
+#define HCS_ENDPOINTS_MASK GENMASK(7, 0)
+#define HCS_ENDPOINTS(p)   (((p) & HCS_ENDPOINTS_MASK) >> 0)
+
+/* HCCPARAMS offset from PCI base address */
+#define HCC_PARAMS_OFFSET  0x10
+
+/* HCCPARAMS - hcc_params - bitmasks */
+/* true: device controller can use 64-bit address pointers. */
+#define HCC_64BIT_ADDR(p)  ((p) & BIT(0))
+/* true: device controller uses 64-byte Device Context structures. */
+#define HCC_64BYTE_CONTEXT(p)  ((p) & BIT(2))
+/* Max size for Primary Stream Arrays - 2^(n+1), where n is bits 12:15. */
+#define HCC_MAX_PSA(p) p) >> 12) & 0xf) + 1)
+/* Extended Capabilities pointer from PCI base. */
+#define HCC_EXT_CAPS(p)(((p) & GENMASK(31, 16)) >> 16)
+
+#define CTX_SIZE(_hcc) (HCC_64BYTE_CONTEXT(_hcc) ? 64 : 32)
+
+/* db_off bitmask - bits 0:1 reserved. */
+#define DBOFF_MASK GENMASK(31, 2)
+
+/* run_regs_off bitmask - bits 0:4 reserved. */
+#define RTSOFF_MASKGENMASK(31, 5)
+
+/**
+ * struct cdnsp_op_regs - Device Controller Operational Registers.
+ * @command: USBCMD - Controller command register.
+ * @status: USBSTS - Controller status register.
+ * @page_size: This indicates the page size that the device controller 
supports.
+ * If bit n is set, the controller supports a page size of 
2^(n+12),
+ * up to a 128MB page size. 4K is the minimum page size.
+ * @dnctrl: DNCTRL - Device notification control register.
+ * @cmd_ring: CRP - 64-bit Command Ring Pointer.
+ * @dcbaa_ptr: DCBAAP - 64-bit Device Context Base Address Array Pointer.
+ * @config_reg:CONFIG - Configure Register
+ * @port_reg_base: PORTSCn - base address for Port Status and Control
+ * Each port has a Port Status and Control register,
+ * followed by a Port Power Management Status and Control
+ * register, a Port Link Info register, and a reserved
+ * register.
+ */
+struct cdnsp_op_regs {
+   __le32 command;
+   __le32 status;
+   __le32 page_size;
+   __le32 reserved1;
+   __le32 reserved2;
+   __le32 dnctrl;
+   __le64 cmd_ring;
+   /* rsvd: offset 0x20-2F. */
+   __le32 reserved3[4];
+   __le64 dcbaa_ptr;
+   __le32 config_reg;
+   /* rsvd: offset 0x3C-3FF. */
+   __le32 reserved4[241];
+   /* port 1 registers, which serve as a base address for other ports. */
+   __le32

[PATCH RFC 2/5] usb:cdns3: Add pci to platform driver wrapper

Patch adds PCI specific glue driver that creates and registers in-system
cdns-usbssp platform device. Thanks to that we will be able to use
the cdns-usbssp platform driver for USBSS-DEV controller
build on PCI board.

Signed-off-by: Pawel Laszczak 
---
 drivers/usb/Kconfig   |   1 +
 drivers/usb/Makefile  |   1 +
 drivers/usb/cdnsp/Kconfig |  26 +
 drivers/usb/cdnsp/Makefile|   3 +
 drivers/usb/cdnsp/cdnsp-pci.c | 214 ++
 5 files changed, 245 insertions(+)
 create mode 100644 drivers/usb/cdnsp/Kconfig
 create mode 100644 drivers/usb/cdnsp/Makefile
 create mode 100644 drivers/usb/cdnsp/cdnsp-pci.c

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 26475b409b53..555c4a4cb465 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -112,6 +112,7 @@ source "drivers/usb/usbip/Kconfig"
 endif
 
 source "drivers/usb/cdns3/Kconfig"
+source "drivers/usb/cdnsp/Kconfig"
 
 source "drivers/usb/mtu3/Kconfig"
 
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 1c1c1d659394..84727f7a4b92 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_USB_DWC2)+= dwc2/
 obj-$(CONFIG_USB_ISP1760)  += isp1760/
 
 obj-$(CONFIG_USB_CDNS3)+= cdns3/
+obj-$(CONFIG_USB_CDNSP)+= cdnsp/
 
 obj-$(CONFIG_USB_MON)  += mon/
 obj-$(CONFIG_USB_MTU3) += mtu3/
diff --git a/drivers/usb/cdnsp/Kconfig b/drivers/usb/cdnsp/Kconfig
new file mode 100644
index ..5796a19bb8a0
--- /dev/null
+++ b/drivers/usb/cdnsp/Kconfig
@@ -0,0 +1,26 @@
+config USB_CDNSP
+   tristate "Cadence CDNSP Dual-Role Controller"
+   depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA
+   select USB_XHCI_PLATFORM if USB_XHCI_HCD
+   select USB_ROLE_SWITCH
+   help
+ Say Y here if your system has a Cadence CDNSP dual-role controller.
+ It supports: dual-role switch Host-only, and Peripheral-only.
+
+ If you choose to build this driver is a dynamically linked
+ module, the module will be called cdnsp.ko.
+
+if USB_CDNSP
+
+config USB_CDNSP_PCI
+   tristate "Cadence CDNSP support on PCIe-based platforms"
+   depends on USB_PCI && ACPI
+   default USB_CDNSP
+   help
+ If you're using the CDNSP Core IP with a PCIe, please say
+ 'Y' or 'M' here.
+
+ If you choose to build this driver as module it will
+ be dynamically linked and module will be called cdnsp-pci.ko
+
+endif
diff --git a/drivers/usb/cdnsp/Makefile b/drivers/usb/cdnsp/Makefile
new file mode 100644
index ..21adf3eb2f7d
--- /dev/null
+++ b/drivers/usb/cdnsp/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_USB_CDNSP_PCI)+= cdnsp-pci.o
diff --git a/drivers/usb/cdnsp/cdnsp-pci.c b/drivers/usb/cdnsp/cdnsp-pci.c
new file mode 100644
index ..7e05d584d57c
--- /dev/null
+++ b/drivers/usb/cdnsp/cdnsp-pci.c
@@ -0,0 +1,214 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cadence PCI Glue driver.
+ *
+ * Copyright (C) 2019 Cadence.
+ *
+ * Author: Pawel Laszczak 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct cdnsp_wrap {
+   struct platform_device *plat_dev;
+   struct resource dev_res[6];
+   int devfn;
+};
+
+#define RES_IRQ_HOST_ID0
+#define RES_IRQ_PERIPHERAL_ID  1
+#define RES_IRQ_OTG_ID 2
+#define RES_HOST_ID3
+#define RES_DEV_ID 4
+#define RES_DRD_ID 5
+
+#define PCI_BAR_HOST   0
+#define PCI_BAR_OTG0
+#define PCI_BAR_DEV2
+
+#define PCI_DEV_FN_HOST_DEVICE 0
+#define PCI_DEV_FN_OTG 1
+
+#define PCI_DRIVER_NAME"cdns-pci-usbssp"
+#define PLAT_DRIVER_NAME   "cdns-usbssp"
+
+#define CDNS_VENDOR_ID 0x17cd
+#define CDNS_DEVICE_ID 0x0100
+#define CDNS_DRD_IF(PCI_CLASS_SERIAL_USB << 8 | 0x80)
+
+static struct pci_dev *cdnsp_get_second_fun(struct pci_dev *pdev)
+{
+   struct pci_dev *func;
+
+   /*
+* Gets the second function.
+* It's little tricky, but this platform has two function.
+* The fist keeps resources for Host/Device while the second
+* keeps resources for DRD/OTG.
+*/
+   func = pci_get_device(pdev->vendor, pdev->device, NULL);
+   if (unlikely(!func))
+   return NULL;
+
+   if (func->devfn == pdev->devfn) {
+   func = pci_get_device(pdev->vendor, pdev->device, func);
+   if (unlikely(!func))
+   return NULL;
+   }
+
+   return func;
+}
+
+static int cdnsp_pci_probe(struct pci_dev *pdev,
+  const struct pci_device_id *id)
+{
+   struct platform_device_info plat_info;
+   struct cdnsp_wrap *wrap;
+   struct resource *res;
+   struct pci_dev *func;
+   int err;
+
+   /*
+* For GADGET/HOST

[PATCH RFC 5/5] usb: cdnsp: Add tracepoints for CDNSP driver

Patch adds the series of tracepoints that can  be used for
debugging issues detected in driver.

Signed-off-by: Pawel Laszczak 
---
 drivers/usb/cdnsp/Makefile |   5 +
 drivers/usb/cdnsp/debug.h  | 583 ++
 drivers/usb/cdnsp/ep0.c|  24 +-
 drivers/usb/cdnsp/gadget.c |  61 ++-
 drivers/usb/cdnsp/gadget.h |   2 +
 drivers/usb/cdnsp/mem.c|  15 +-
 drivers/usb/cdnsp/ring.c   |  75 +++-
 drivers/usb/cdnsp/trace.c  |  12 +
 drivers/usb/cdnsp/trace.h  | 839 +
 9 files changed, 1604 insertions(+), 12 deletions(-)
 create mode 100644 drivers/usb/cdnsp/debug.h
 create mode 100644 drivers/usb/cdnsp/trace.c
 create mode 100644 drivers/usb/cdnsp/trace.h

diff --git a/drivers/usb/cdnsp/Makefile b/drivers/usb/cdnsp/Makefile
index 386b6a7b8b4e..067005c5ac32 100644
--- a/drivers/usb/cdnsp/Makefile
+++ b/drivers/usb/cdnsp/Makefile
@@ -1,9 +1,14 @@
 # SPDX-License-Identifier: GPL-2.0
+# define_trace.h needs to know how to find our header
+CFLAGS_trace.o := -I$(src)
 
 cdnsp-y:= core.o drd.o
 
 obj-$(CONFIG_USB_CDNSP)+= cdnsp.o
 cdnsp-$(CONFIG_USB_CDNSP_GADGET)   += ring.o gadget.o mem.o ep0.o
+ifneq ($(CONFIG_USB_CDNSP_GADGET),)
+cdnsp-$(CONFIG_TRACING)+= trace.o
+endif
 
 cdnsp-$(CONFIG_USB_CDNSP_HOST) += host.o
 
diff --git a/drivers/usb/cdnsp/debug.h b/drivers/usb/cdnsp/debug.h
new file mode 100644
index ..d6345d4d2911
--- /dev/null
+++ b/drivers/usb/cdnsp/debug.h
@@ -0,0 +1,583 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Cadence CDNSP DRD Driver.
+ *
+ * Copyright (C) 2020 Cadence.
+ *
+ * Author: Pawel Laszczak 
+ *
+ */
+#ifndef __LINUX_CDNSP_DEBUG
+#define __LINUX_CDNSP_DEBUG
+
+static inline const char *cdnsp_trb_comp_code_string(u8 status)
+{
+   switch (status) {
+   case COMP_INVALID:
+   return "Invalid";
+   case COMP_SUCCESS:
+   return "Success";
+   case COMP_DATA_BUFFER_ERROR:
+   return "Data Buffer Error";
+   case COMP_BABBLE_DETECTED_ERROR:
+   return "Babble Detected";
+   case COMP_TRB_ERROR:
+   return "TRB Error";
+   case COMP_RESOURCE_ERROR:
+   return "Resource Error";
+   case COMP_NO_SLOTS_AVAILABLE_ERROR:
+   return "No Slots Available Error";
+   case COMP_INVALID_STREAM_TYPE_ERROR:
+   return "Invalid Stream Type Error";
+   case COMP_SLOT_NOT_ENABLED_ERROR:
+   return "Slot Not Enabled Error";
+   case COMP_ENDPOINT_NOT_ENABLED_ERROR:
+   return "Endpoint Not Enabled Error";
+   case COMP_SHORT_PACKET:
+   return "Short Packet";
+   case COMP_RING_UNDERRUN:
+   return "Ring Underrun";
+   case COMP_RING_OVERRUN:
+   return "Ring Overrun";
+   case COMP_VF_EVENT_RING_FULL_ERROR:
+   return "VF Event Ring Full Error";
+   case COMP_PARAMETER_ERROR:
+   return "Parameter Error";
+   case COMP_CONTEXT_STATE_ERROR:
+   return "Context State Error";
+   case COMP_EVENT_RING_FULL_ERROR:
+   return "Event Ring Full Error";
+   case COMP_INCOMPATIBLE_DEVICE_ERROR:
+   return "Incompatible Device Error";
+   case COMP_MISSED_SERVICE_ERROR:
+   return "Missed Service Error";
+   case COMP_COMMAND_RING_STOPPED:
+   return "Command Ring Stopped";
+   case COMP_COMMAND_ABORTED:
+   return "Command Aborted";
+   case COMP_STOPPED:
+   return "Stopped";
+   case COMP_STOPPED_LENGTH_INVALID:
+   return "Stopped - Length Invalid";
+   case COMP_STOPPED_SHORT_PACKET:
+   return "Stopped - Short Packet";
+   case COMP_MAX_EXIT_LATENCY_TOO_LARGE_ERROR:
+   return "Max Exit Latency Too Large Error";
+   case COMP_ISOCH_BUFFER_OVERRUN:
+   return "Isoch Buffer Overrun";
+   case COMP_EVENT_LOST_ERROR:
+   return "Event Lost Error";
+   case COMP_UNDEFINED_ERROR:
+   return "Undefined Error";
+   case COMP_INVALID_STREAM_ID_ERROR:
+   return "Invalid Stream ID Error";
+   default:
+   return "Unknown!!";
+   }
+}
+
+static inline const char *cdnsp_trb_type_string(u8 type)
+{
+   switch (type) {
+   case TRB_NORMAL:
+   return "Normal";
+   case TRB_SETUP:
+   return "Setup Stage";
+   case TRB_DATA:
+   return "Data Stage";
+   case TRB_STATUS:
+   return "Status Stage";
+   case TRB_ISOC:
+   return "Isoch";
+   case TRB_LINK:
+   return "Link";
+   case TRB_EVENT_DATA:
+   return "Event Data";
+   case TRB_TR_NOOP:
+   return "No-Op";
+   case TRB_ENABLE_SLOT:
+   return "Enable Slot

[PATCH RFC 0/5] Introduced new Cadence USBSSP DRD Driver.

This patch introduce new Cadence USBSS DRD driver to linux kernel.

The Cadence USBSS DRD Controller is a highly configurable IP Core which
can be instantiated as Dual-Role Device (DRD), Peripheral Only and
Host Only (XHCI)configurations.

The current driver has been validated with FPGA burned. We have support
for PCIe bus, which is used on FPGA prototyping.

The host side of USBSS-DRD controller is compliance with XHCI
specification, so it works with standard XHCI Linux driver.

The host side of USBSS DRD controller is compliant with XHCI.
The architecture for device side is almost the same as for host side,
and most of the XHCI specification can be used to understand how
this controller operates.

This controller and driver support Full Speed, Hight Speed, Supper Speed
and Supper Speed Plus USB protocol.

The prefix cdnsp used in driver has chosen by analogy to cdn3 driver.
The last letter of this acronym means PLUS. The formal name of controller
is USBSSP but it's to generic so I've decided to use CDNSP.

The patch 1: adds DT binding.
The patch 2: adds PCI to platform wrapper used on Cadnece testing
 platform. It is FPGA based on platform.
The patches 3-5: add the main part of driver and has been intentionally
 split into 3 part. In my opinion such division should not
 affect understanding and reviewing the driver, and cause that
 main patch (4/5) is little smaller. Patch 3 introduces main
 header file for driver, 4 is the main part that implements all
 functionality of driver and 5 introduces tracepoints.

---

Pawel Laszczak (5):
  dt-bindings: add binding for CDNSP-DRD controller
  usb:cdns3: Add pci to platform driver wrapper
  usb: cdnsp: Device side header file for CDNSP driver
  usb: cdnsp: usb:cdns3 Add main part of Cadence USBSSP DRD Driver
  usb: cdnsp: Add tracepoints for CDNSP driver

 .../devicetree/bindings/usb/cdns-cdnsp.yaml   |  104 +
 drivers/usb/Kconfig   |1 +
 drivers/usb/Makefile  |1 +
 drivers/usb/cdnsp/Kconfig |   49 +
 drivers/usb/cdnsp/Makefile|   15 +
 drivers/usb/cdnsp/cdnsp-pci.c |  214 ++
 drivers/usb/cdnsp/core.c  |  632 +
 drivers/usb/cdnsp/core.h  |   90 +
 drivers/usb/cdnsp/debug.h |  583 
 drivers/usb/cdnsp/drd.c   |  372 +++
 drivers/usb/cdnsp/drd.h   |  127 +
 drivers/usb/cdnsp/ep0.c   |  482 
 drivers/usb/cdnsp/export.h|   36 +
 drivers/usb/cdnsp/gadget.c| 1990 ++
 drivers/usb/cdnsp/gadget.h| 1586 +++
 drivers/usb/cdnsp/host.c  |   74 +
 drivers/usb/cdnsp/mem.c   | 1340 +
 drivers/usb/cdnsp/ring.c  | 2443 +
 drivers/usb/cdnsp/trace.c |   12 +
 drivers/usb/cdnsp/trace.h |  839 ++
 20 files changed, 10990 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/cdns-cdnsp.yaml
 create mode 100644 drivers/usb/cdnsp/Kconfig
 create mode 100644 drivers/usb/cdnsp/Makefile
 create mode 100644 drivers/usb/cdnsp/cdnsp-pci.c
 create mode 100644 drivers/usb/cdnsp/core.c
 create mode 100644 drivers/usb/cdnsp/core.h
 create mode 100644 drivers/usb/cdnsp/debug.h
 create mode 100644 drivers/usb/cdnsp/drd.c
 create mode 100644 drivers/usb/cdnsp/drd.h
 create mode 100644 drivers/usb/cdnsp/ep0.c
 create mode 100644 drivers/usb/cdnsp/export.h
 create mode 100644 drivers/usb/cdnsp/gadget.c
 create mode 100644 drivers/usb/cdnsp/gadget.h
 create mode 100644 drivers/usb/cdnsp/host.c
 create mode 100644 drivers/usb/cdnsp/mem.c
 create mode 100644 drivers/usb/cdnsp/ring.c
 create mode 100644 drivers/usb/cdnsp/trace.c
 create mode 100644 drivers/usb/cdnsp/trace.h

-- 
2.17.1

Re: [PATCH 06/10] media: mtk-vcodec: venc: specify supported formats per-chip

2020-06-25 Thread Alexandre Courbot

Hi Tiffany,

On Tue, Jun 23, 2020 at 10:29 AM Tiffany Lin  wrote:
>
> On Mon, 2020-06-22 at 21:44 +0900, Alexandre Courbot wrote:
> > On Fri, Jun 19, 2020 at 4:26 PM Tiffany Lin  
> > wrote:
> > >
> > > On Wed, 2020-05-20 at 17:27 +0900, Alexandre Courbot wrote:
> > > > Different chips have different supported bitrate ranges. Move the list
> > > > of supported formats to the platform data, and split the output and
> > > > capture formats into two lists to make it easier to find the default
> > > > format for each queue.
> > > >
> > >
> > > Does this patch pass v4l2 compliance test?
> >
> > This should not change the behavior towards userspace at all (it's
> > just moving data around and making it more flexible), so the test
> > results should not be affected either.
> >
> I remember that passing compliance tests is required for upstream.
> The tests try to make sure that all V4L2 driver implement interfaces in
> the same way.
> So user space applications could find/enumerate HW capability.

I have confirmed that this CL does not introduce any regression with
v4l2-compliance.

Re: [PATCH v3 4/8] mm/hugetlb: make hugetlb migration callback CMA aware

2020년 6월 25일 (목) 오후 8:54, Michal Hocko 님이 작성:
>
> On Tue 23-06-20 15:13:44, Joonsoo Kim wrote:
> > From: Joonsoo Kim 
> >
> > new_non_cma_page() in gup.c which try to allocate migration target page
> > requires to allocate the new page that is not on the CMA area.
> > new_non_cma_page() implements it by removing __GFP_MOVABLE flag. This way
> > works well for THP page or normal page but not for hugetlb page.
>
> Could you explain why? I mean why cannot you simply remove __GFP_MOVABLE
> flag when calling alloc_huge_page_nodemask and check for it in dequeue
> path?

If we remove __GFP_MOVABLE when calling alloc_huge_page_nodemask, we cannot
use the page in ZONE_MOVABLE on dequeing.

__GFP_MOVABLE is not only used for CMA selector but also used for zone selector.
If we clear it, we cannot use the page in the ZONE_MOVABLE even if
it's not CMA pages.
For THP page or normal page allocation, there is no way to avoid this
weakness without
introducing another flag or argument. For me, introducing another flag
or argument for
these functions looks over-engineering so I don't change them and
leave them as they are
(removing __GFP_MOVABLE).

But, for alloc_huge_page_nodemask(), introducing a new argument
doesn't seem to be
a problem since it is not a general function but just a migration
target allocation function.

If you agree with this argument, I will add more description to the patch.

Thanks.

Re: [PATCH] powerpc/fixmap: Fix FIX_EARLY_DEBUG_BASE when page size is 256k

On Mon, 15 Jun 2020 07:48:25 + (UTC), Christophe Leroy wrote:
> FIX_EARLY_DEBUG_BASE reserves a 128k area for debuging.
> 
> When page size is 256k, the calculation results in a 0 number of
> pages, leading to the following failure:
> 
>   CC  arch/powerpc/kernel/asm-offsets.s
> In file included from ./arch/powerpc/include/asm/nohash/32/pgtable.h:77:0,
>  from ./arch/powerpc/include/asm/nohash/pgtable.h:8,
>  from ./arch/powerpc/include/asm/pgtable.h:20,
>  from ./include/linux/pgtable.h:6,
>  from ./arch/powerpc/include/asm/kup.h:42,
>  from ./arch/powerpc/include/asm/uaccess.h:9,
>  from ./include/linux/uaccess.h:11,
>  from ./include/linux/crypto.h:21,
>  from ./include/crypto/hash.h:11,
>  from ./include/linux/uio.h:10,
>  from ./include/linux/socket.h:8,
>  from ./include/linux/compat.h:15,
>  from arch/powerpc/kernel/asm-offsets.c:14:
> ./arch/powerpc/include/asm/fixmap.h:75:2: error: overflow in enumeration 
> values
>   __end_of_permanent_fixed_addresses,
>   ^
> make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/fixmap: Fix FIX_EARLY_DEBUG_BASE when page size is 256k
  https://git.kernel.org/powerpc/c/03fd42d458fb9cb69e712600bd69ff77ff3a45a8

cheers

Re: [PATCH v3 0/2] powerpc: CMDLINE config cleanup

On Fri, 12 Jun 2020 10:42:18 +1200, Chris Packham wrote:
> This series cleans up the config options related to the boot command line.
> 
> Chris Packham (2):
>   powerpc: Remove inaccessible CMDLINE default
>   powerpc: configs: remove CMDLINE_BOOL
> 
>  arch/powerpc/Kconfig   | 6 +-
>  arch/powerpc/configs/44x/akebono_defconfig | 2 --
>  arch/powerpc/configs/44x/arches_defconfig  | 2 --
>  arch/powerpc/configs/44x/bamboo_defconfig  | 2 --
>  arch/powerpc/configs/44x/bluestone_defconfig   | 2 --
>  arch/powerpc/configs/44x/canyonlands_defconfig | 2 --
>  arch/powerpc/configs/44x/currituck_defconfig   | 2 --
>  arch/powerpc/configs/44x/eiger_defconfig   | 2 --
>  arch/powerpc/configs/44x/fsp2_defconfig| 1 -
>  arch/powerpc/configs/44x/icon_defconfig| 2 --
>  arch/powerpc/configs/44x/iss476-smp_defconfig  | 1 -
>  arch/powerpc/configs/44x/katmai_defconfig  | 2 --
>  arch/powerpc/configs/44x/rainier_defconfig | 2 --
>  arch/powerpc/configs/44x/redwood_defconfig | 2 --
>  arch/powerpc/configs/44x/sam440ep_defconfig| 2 --
>  arch/powerpc/configs/44x/sequoia_defconfig | 2 --
>  arch/powerpc/configs/44x/taishan_defconfig | 2 --
>  arch/powerpc/configs/44x/warp_defconfig| 1 -
>  arch/powerpc/configs/holly_defconfig   | 1 -
>  arch/powerpc/configs/mvme5100_defconfig| 3 +--
>  arch/powerpc/configs/ps3_defconfig | 2 --
>  arch/powerpc/configs/skiroot_defconfig | 1 -
>  arch/powerpc/configs/storcenter_defconfig  | 1 -
>  23 files changed, 2 insertions(+), 43 deletions(-)

Applied to powerpc/next.

[1/2] powerpc: Remove inaccessible CMDLINE default
  https://git.kernel.org/powerpc/c/f134a7cef1d7de45fab028a945b7f34c615718e1
[2/2] powerpc/configs: Remove CMDLINE_BOOL
  https://git.kernel.org/powerpc/c/0488d32530ecff973c40f2592a6eab2907d0a5cc

cheers

Re: [PATCH 2/2] pci: Add parameter to disable attaching untrusted devices

On Thu, Jun 25, 2020 at 05:27:10PM -0700, Rajat Jain wrote:
> Introduce a PCI parameter that disables the automatic attachment of
> untrusted devices to their drivers.

You didn't document this new api anywhere :(

Re: [PATCH] powerpc/8xx: Modify ptep_get()

On Thu, 18 Jun 2020 12:07:46 + (UTC), Christophe Leroy wrote:
> Move ptep_get() close to pte_update(), in an ifdef section already
> dedicated to powerpc 8xx. This section contains explanation about
> the layout of page table entries.
> 
> Also modify it to return 4 times the pte value instead of padding
> with zeroes.

Applied to powerpc/next.

[1/1] powerpc/8xx: Modify ptep_get()
  https://git.kernel.org/powerpc/c/105fb38124a490f38e9c1e23bb4c4a0b6ba12fdb

cheers

Re: [PATCH 0/3] powerpc/dt_cpu_ftrs: Make use of ISA_V3_* macros

On Wed, 10 Jun 2020 18:51:11 -0300, Murilo Opsfelder Araujo wrote:
> The first patch removes unused macro ISA_V2_07B.  The second and third
> patches make use of macros ISA_V3_0B and ISA_V3_1, respectively,
> instead their corresponding literals.
> 
> Murilo Opsfelder Araujo (3):
>   powerpc/dt_cpu_ftrs: Remove unused macro ISA_V2_07B
>   powerpc/dt_cpu_ftrs: Make use of macro ISA_V3_0B
>   powerpc/dt_cpu_ftrs: Make use of macro ISA_V3_1
> 
> [...]

Applied to powerpc/next.

[1/3] powerpc/dt_cpu_ftrs: Remove unused macro ISA_V2_07B
  https://git.kernel.org/powerpc/c/f39eb5d8ac707fd59029a06c3f985f29b1aaa26b
[2/3] powerpc/dt_cpu_ftrs: Make use of macro ISA_V3_0B
  https://git.kernel.org/powerpc/c/e781f12a60a7bddb50909d42478cca8724c8b113
[3/3] powerpc/dt_cpu_ftrs: Make use of macro ISA_V3_1
  https://git.kernel.org/powerpc/c/7714394706c0309b3f3fc474b390463d60eb6cb1

cheers

Re: [PATCH 1/3] crypto: pass the flag CRYPTO_ALG_ALLOCATES_MEMORY

2020-06-25 Thread Herbert Xu

On Wed, Jun 17, 2020 at 11:09:28AM -0400, Mikulas Patocka wrote:
>
> Index: linux-2.6/include/linux/crypto.h
> ===
> --- linux-2.6.orig/include/linux/crypto.h
> +++ linux-2.6/include/linux/crypto.h
> @@ -97,9 +97,18 @@
>  #define CRYPTO_ALG_OPTIONAL_KEY  0x4000
>  
>  /*
> + * The driver may allocate memory during request processing, so it shouldn't 
> be
> + * used in cases where memory allocation failures aren't acceptable, such as
> + * during block device encryption.
> + */
> +#define CRYPTO_ALG_ALLOCATES_MEMORY  0x8000
> +
> +/*
>   * Don't trigger module loading
>   */
> -#define CRYPTO_NOLOAD0x8000
> +#define CRYPTO_NOLOAD0x0001
> +
> +#define CRYPTO_ALG_INHERITED_FLAGS   (CRYPTO_ALG_ASYNC | 
> CRYPTO_ALG_ALLOCATES_MEMORY)

Any reason why you need to renumber NOLOAD? If not please keep
the existing values.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH V2] powerpc/pseries/svm: Drop unused align argument in alloc_shared_lppaca() function

On Fri, 12 Jun 2020 19:59:53 +0530, Satheesh Rajendran wrote:
> Argument "align" in alloc_shared_lppaca() was unused inside the
> function. Let's drop it and update code comment for page alignment.

Applied to powerpc/next.

[1/1] powerpc/pseries/svm: Drop unused align argument in alloc_shared_lppaca() 
function
  https://git.kernel.org/powerpc/c/178748b6d14946f080d49bc7dcc47b7cc4437e4d

cheers

Re: [PATCH] powerpc/mm: Fix typo in IS_ENABLED()

On Fri, 5 Jun 2020 07:18:06 -0700, Kees Cook wrote:
> IS_ENABLED() matches names exactly, so the missing "CONFIG_" prefix
> means this code would never be built.
> 
> Also fixes a missing newline in pr_warn().

Applied to powerpc/next.

[1/1] powerpc/mm: Fix typo in IS_ENABLED()
  https://git.kernel.org/powerpc/c/55bd9ac468397c4f12a33b7ec714b5d0362c3aa2

cheers

Re: [PATCH] powerpc/ptdump: Fix build failure in hashpagetable.c

On Mon, 15 Jun 2020 13:18:39 + (UTC), Christophe Leroy wrote:
> H_SUCCESS is only defined when CONFIG_PPC_PSERIES is defined.
> 
> != H_SUCCESS means != 0. Modify the test accordingly.

Applied to powerpc/next.

[1/1] powerpc/ptdump: Fix build failure in hashpagetable.c
  https://git.kernel.org/powerpc/c/7c466b0807960edc13e4b855be85ea765df9a6cd

cheers

Re: [PATCH] arch: powerpc: ppc4xx compile flag optimizations

On Thu, 22 Dec 2016 09:06:08 +0100, John Crispin wrote:
> This patch splits up the compile flags between ppc40x and ppc44x.

Applied to powerpc/next.

[1/1] powerpc/4xx: ppc4xx compile flag optimizations
  https://git.kernel.org/powerpc/c/548ad77d10f7ad6e5f84a0026978da2ed1df0dae

cheers

Re: [PATCH] powerpc/fsl_booke/32: fix build with CONFIG_RANDOMIZE_BASE

On Sat, 13 Jun 2020 23:28:01 +0700, Arseny Solokha wrote:
> Building the current 5.8 kernel for a e500 machine with
> CONFIG_RANDOMIZE_BASE set yields the following failure:
> 
>   arch/powerpc/mm/nohash/kaslr_booke.c: In function 'kaslr_early_init':
>   arch/powerpc/mm/nohash/kaslr_booke.c:387:2: error: implicit declaration
> of function 'flush_icache_range'; did you mean 'flush_tlb_range'?
> [-Werror=implicit-function-declaration]
> 
> [...]

Applied to powerpc/fixes.

[1/1] powerpc/fsl_booke/32: Fix build with CONFIG_RANDOMIZE_BASE
  https://git.kernel.org/powerpc/c/7e4773f73dcfb92e7e33532162f722ec291e75a4

cheers

Re: [fedora-arm] Banana Pi-R1 - kernel 5.6.0 and later broken - b43 DSA

2020-06-25 Thread Florian Fainelli




On 6/25/2020 4:23 PM, Peter Robinson wrote:
>> I'm having troubles with the Banana Pi-R1 router with newer kernels. No
>> config changes, config works well since a lot of lernel updates ...
>> Banana Pi-R1 is configured via systemd-networkd and uses the DSA
>> (Distributed Switch Architecture) with b53 switch. No visible difference
>> in interfaces, vlan config, bridge config, etc. Looks like actual
>> configuration in the switch in the hardware is broken.
>>
>> # OK: Last good known version (booting that version is also ok)
>> Linux bpi 5.5.18-200.fc31.armv7hl #1 SMP Fri Apr 17 17:25:00 UTC 2020
>> armv7l armv7l armv7l GNU/Linux
>>
>> # NOK: no network
>> Linux bpi 5.6.8-200.fc31.armv7hl #1 SMP Wed Apr 29 19:05:06 UTC 2020
>> armv7l armv7l armv7l GNU/Linux
>>
>> # NOK: no network
>> Linux bpi 5.6.0-300.fc32.armv7hl #1 SMP Mon Mar 30 16:37:50 UTC 2020
>> armv7l armv7l armv7l GNU/Linux
>>
>> # NOK: no network
>> Linux bpi 5.6.19-200.fc31.armv7hl #1 SMP Wed Jun 17 17:10:22 UTC 2020
>> armv7l armv7l armv7l GNU/Linux
>>
>> # NOK: no network
>> Linux bpi 5.7.4-200.fc32.armv7hl #1 SMP Fri Jun 19 00:52:22 UTC 2020
>> armv7l armv7l armv7l GNU/Linux
>>
>>
>> Saw that there were a lot of changes in the near past in the b53 driver:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/net/dsa/b53?h=v5.8-rc1+
> 
> So from your notes above it looks like something regressed between the
> 5.5.x series and the 5.6.0 release? If so I'm not sure what the
> context of the changed in 5.8 are here. If there's more changes to the
> driver in 5.8 dev cycle have you tried one of the Fedora rawhide 5.8
> rc1 or rc2 kernel builds to see if that resolves it?

See my response to Gerhard, there are changes expected to how the
network configuration should be done after:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8fab459e69abfd04a66d76423d18ba853fced4ab

> 
> Failing that looking for the change in the 5.6 cycle would likely be
> the better bet so we can work out what broke it and report it to the
> upstream driver maintainer. Have you searched to see if others are
> seeing a similar issue or have reported a similar issue upstream?
> 

Gerhard is doing exactly this with his email.
-- 
Florian

Re: [klibc] process '/usr/bin/rsync' started with executable stack

2020-06-25 Thread Christophe Leroy

Le 25/06/2020 à 22:20, Kees Cook a écrit :

On Thu, Jun 25, 2020 at 01:04:29PM +0300, Dan Carpenter wrote:

On Wed, Jun 24, 2020 at 12:39:24PM -0700, Kees Cook wrote:

On Wed, Jun 24, 2020 at 07:51:48PM +0300, Dan Carpenter wrote:

In Debian testing the initrd triggers the warning.

[ 34.529809] process '/usr/bin/fstype' started with executable stack

Where does fstype come from there? I am going to guess it is either
busybox or linked against klibc?

klibc has known problems with executable stacks due to its trampoline
implementation:
https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks

Yeah. It comes from klibc-utils.

This is exactly what I was worried about back in Feb:
https://lore.kernel.org/lkml/202002251341.48BC06E@keescook/

This warning, combined with klibc-based initrds, makes the whole thing
pointless because it will always warn once on boot for the klibc stack,
and then not warn about anything else after that.

It looks like upstream klibc hasn't been touched in about 4 years, and
it's been up to Ben to keep it alive in Debian.

A couple ideas, in order of my preference:

1) stop using klibc-utils[1]. initramfs-tools-core is the only thing with a
dependency on klibc-utils. Only a few things are missing from busybox.

Does busybox cleanly build with klibc lib ?
If it does, is the result as small ?

2) make the warning rate-limited instead?

3) fix the use of trampolines in klibc

That's done, see
https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=9d8d648e604026b32cad00a84ed6c29cbd157641

Discussed here
https://lists.zytor.com/archives/klibc/2020-February/004271.html

Christophe

Thoughts?

-Kees

[1] Ben appears well aware of this idea, as he suggested it in 2018. :)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887159

Re: [PATCH] platform/chrome: Clarify SPDX license with GPL-2.0-only

On Thu, Jun 25, 2020 at 10:06:03PM +0300, Andy Shevchenko wrote:
> On Thu, Jun 25, 2020 at 9:25 PM Enric Balletbo i Serra
>  wrote:
> >
> > Remove the ambiguity with GPL-2.0 and use an explicit GPL-2.0-only
> > tag.
> 
> Is there any? Last time IIRC Greg told me that in the kernel the old
> and new variants are okay.

They are just fine, leave it alone, the in-kernel LICENSES/ files show
the valid SPDX tags that the kernel allows at this point in time.

This is not worth the churn at all, once we get to complete coverage of
all kernel files, then you can worry about trivial things like this.

thanks,

greg k-h

Re: [PATCH] fixing ERROR: Macros with complex values must be enclosed within parentheses.

On Thu, Jun 25, 2020 at 10:17:23PM -0400, B K Karthik wrote:
> soc_camera.c:
> 
> fixing ERROR: Macros with complex values must be enclused within parentheses.
> 
> Signed-off-by: B K Karthik 
> ---
>  drivers/staging/media/soc_camera/soc_camera.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what is needed in order to
  properly describe the change.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what a proper Subject: line should
  look like.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: [PATCH v2] ring-buffer: Have nested events still record running time stamp

Hi Steven,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on tip/perf/core]
[also build test WARNING on linux/master linus/master v5.8-rc2 next-20200625]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Steven-Rostedt/ring-buffer-Have-nested-events-still-record-running-time-stamp/20200626-105715
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
bb42b3d39781d7fcd3be7f9f9bf11b6661b5fdf1
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=mips 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   kernel/trace/ring_buffer.c: In function '__rb_reserve_next':
   kernel/trace/ring_buffer.c:2911:6: warning: unused variable 'delta' 
[-Wunused-variable]
2911 |  u64 delta, before, after;
 |  ^
>> kernel/trace/ring_buffer.c:2910:32: warning: variable 'next' set but not 
>> used [-Wunused-but-set-variable]
2910 |  unsigned long tail, write, w, next;
 |^~~~

vim +/next +2910 kernel/trace/ring_buffer.c

  2903  
  2904  static struct ring_buffer_event *
  2905  __rb_reserve_next(struct ring_buffer_per_cpu *cpu_buffer,
  2906struct rb_event_info *info)
  2907  {
  2908  struct ring_buffer_event *event;
  2909  struct buffer_page *tail_page;
> 2910  unsigned long tail, write, w, next;
  2911  u64 delta, before, after;
  2912  bool abs = false;
  2913  
  2914  /* Don't let the compiler play games with cpu_buffer->tail_page 
*/
  2915  tail_page = info->tail_page = READ_ONCE(cpu_buffer->tail_page);
  2916  
  2917   /*A*/  w = local_read(_page->write) & RB_WRITE_MASK;
  2918  barrier();
  2919  before = local64_read(_buffer->before_stamp);
  2920  after = local64_read(_buffer->write_stamp);
  2921  barrier();
  2922  info->ts = rb_time_stamp(cpu_buffer->buffer);
  2923  
  2924  if (ring_buffer_time_stamp_abs(cpu_buffer->buffer)) {
  2925  info->delta = info->ts;
  2926  abs = true;
  2927  } else {
  2928  info->delta = info->ts - after;
  2929  }
  2930  
  2931  if (unlikely(test_time_stamp(info->delta)))
  2932  rb_handle_timestamp(cpu_buffer, info);
  2933  
  2934  /*
  2935   * If interrupting an event time update, we may need an 
absolute timestamp.
  2936   * Don't bother if this is the start of a new page (w == 0).
  2937   */
  2938  if (unlikely(before != after && w))
  2939  info->add_timestamp = RB_ADD_STAMP_FORCE;
  2940  /*
  2941   * If the time delta since the last event is too big to
  2942   * hold in the time field of the event, then we append a
  2943   * TIME EXTEND event ahead of the data event.
  2944   */
  2945  if (unlikely(info->add_timestamp))
  2946  info->length += RB_LEN_TIME_EXTEND;
  2947  
  2948  next = READ_ONCE(cpu_buffer->next_write);
  2949  WRITE_ONCE(cpu_buffer->next_write, w + info->length);
  2950  
  2951   /*B*/  local64_set(_buffer->before_stamp, info->ts);
  2952  
  2953   /*C*/  write = local_add_return(info->length, _page->write);
  2954  
  2955  /* set write to only the index of the write */
  2956  write &= RB_WRITE_MASK;
  2957  
  2958  tail = write - info->length;
  2959  
  2960  /* See if we shot pass the end of this buffer page */
  2961  if (unlikely(write > BUF_PAGE_SIZE)) {
  2962  if (tail != w) {
  2963  /* before and after may now different, fix it 
up*/
  2964  before = 
local64_read(_buffer->before_stamp);
  2965  after = local64_read(_buffer->write_stamp);
  2966  if (before != after)
  2967  
(void)local64_cmpxchg(_buffer->before_stamp, before, after);
  2968  }
  2969  return rb_move_tail(cpu_buffer, tail, info);
  2970  }
  2971  
  2972  if (likely(tail == w)) {
  2973  u64 save_before;
  2974  
  2975

[git pull] drm fixes for v5.8-rc3

2020-06-25 Thread Dave Airlie

Hi Linus,

Usual rc3 pickup, lots of little fixes all over, The core VT
registration regression fix is probably the largest, otherwise ttm,
amdgpu and tegra are the bulk, with some minor driver fixes. No i915
pull this week which may or may not mean I get 2x of it next week,
we'll see how it goes.

Regards,
Dave.

drm-fixes-2020-06-26:
drm fixes for v5.8-rc3

core:
- fix VT registration regression

ttm:
- fix two fence leaks

amdgpu:
- Fix missed mutex unlock in DC error path
- Fix firmware leak for sdma5
- DC bpc property fixes

amdkfd:
- Fix memleak in an error path

radeon:
- Fix copy paste typo in NI DPM spll validation

rcar-du:
- build fix

tegra:
- add missing zpos property
- child driver registration fix
- debugfs cleanup fix
- doc fix

mcde:
- reorder fbdev setup

panel:
- fix connector type
- fix orientation for some panels

sun4i:
- fix dma/iommu configuration

uvesafb:
- respect blank flag
The following changes since commit 48778464bb7d346b47157d21ffde2af6b2d39110:

  Linux 5.8-rc2 (2020-06-21 15:45:29 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-06-26

for you to fetch changes up to 687a0ed337367be5267652af5f6dbcfc954b8732:

  Merge tag 'drm-misc-fixes-2020-06-25' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2020-06-26
13:49:17 +1000)


drm fixes for v5.8-rc3

core:
- fix VT registration regression

ttm:
- fix two fence leaks

amdgpu:
- Fix missed mutex unlock in DC error path
- Fix firmware leak for sdma5
- DC bpc property fixes

amdkfd:
- Fix memleak in an error path

radeon:
- Fix copy paste typo in NI DPM spll validation

rcar-du:
- build fix

tegra:
- add missing zpos property
- child driver registration fix
- debugfs cleanup fix
- doc fix

mcde:
- reorder fbdev setup

panel:
- fix connector type
- fix orientation for some panels

sun4i:
- fix dma/iommu configuration

uvesafb:
- respect blank flag


Adam Ford (1):
  drm/panel-simple: fix connector type for LogicPD Type28 Display

Bartlomiej Zolnierkiewicz (1):
  video: fbdev: uvesafb: fix "noblank" option handling

Bernard Zhao (1):
  drm/amd: fix potential memleak in err branch

Christophe JAILLET (1):
  gpu: host1x: Clean up debugfs in error handling path

Colton Lewis (1):
  gpu: host1x: Correct trivial kernel-doc inconsistencies

Daniel Gomez (1):
  drm: rcar-du: Fix build error

Daniel Vetter (1):
  drm/fb-helper: Fix vt restore

Dave Airlie (4):
  Merge tag 'du-fixes-20200621' of
git://linuxtv.org/pinchartl/media into drm-fixes
  Merge tag 'drm/tegra/for-5.8-rc3' of
git://anongit.freedesktop.org/tegra/linux into drm-fixes
  Merge tag 'amd-drm-fixes-5.8-2020-06-24' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2020-06-25' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

Denis Efremov (1):
  drm/radeon: fix fb_div check in ni_init_smc_spll_table()

Hans de Goede (2):
  drm: panel-orientation-quirks: Add quirk for Asus T101HA panel
  drm: panel-orientation-quirks: Use generic orientation-data for Acer S1003

John van der Kamp (1):
  drm/amdgpu/display: Unlock mutex on error

Linus Walleij (2):
  drm: mcde: Fix display initialization problem
  drm: mcde: Fix forgotten user of drm->dev_private

Maxime Ripard (1):
  drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU

Nicolin Chen (1):
  drm/tegra: hub: Do not enable orphaned window group

Stylon Wang (2):
  drm/amd/display: Enable output_bpc property on all outputs
  drm/amd/display: Fix ineffective setting of max bpc property

Thierry Reding (4):
  gpu: host1x: Register child devices
  drm/tegra: hub: Register child devices
  gpu: host1x: Detach driver on unregister
  drm/tegra: Add zpos property for cursor planes

Thomas Zimmermann (1):
  Merge v5.8-rc1 into drm-misc-fixes

Tomi Valkeinen (1):
  drm/panel-simple: fix connector type for newhaven_nhd_43_480272ef_atxl

Wenhui Sheng (1):
  drm/amdgpu: add fw release for sdma v5_0

Xiyu Yang (2):
  drm/ttm: Fix dma_fence refcnt leak in ttm_bo_vm_fault_reserved
  drm/ttm: Fix dma_fence refcnt leak when adding move fence

 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c |  6 ++-
 drivers/gpu/drm/amd/amdkfd/kfd_process.c   |  1 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  3 +-
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c  |  4 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c |  6 ++-
 drivers/gpu/drm/drm_fb_helper.c| 63 +-
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 14 ++---
 drivers/gpu/drm/mcde/mcde_display.c|  2 +-
 drivers/gpu/drm/mcde/mcde_drv.c|  3 +-
 drivers/gpu/drm/panel/panel-simple.c   |  2 +

Re: [PATCH] Bluetooth: btusb: Comment on unbalanced pm reference

2020-06-25 Thread Marcel Holtmann

Hi Abhishek,

> Add a comment clarifying that a PM reference in btusb_qca_cmd_timeout is
> not unbalanced because it results in a device reset.
> 
> Signed-off-by: Abhishek Pandit-Subedi 
> ---
> 
> drivers/bluetooth/btusb.c | 1 +
> 1 file changed, 1 insertion(+)

patch has been applied to bluetooth-next tree.

Regards

Marcel

[PATCH v3 2/2] USB: serial: cp210x: Proper RTS control when buffers fill

2020-06-25 Thread Phu Luu

From: Brant Merryman 

CP210x hardware disables auto-RTS but leaves auto-CTS when
in hardware flow control mode and UART on cp210x hardware
is disabled. This allows data to flow out, but new data
will not come into the port. When re-opening the port, if
auto-CTS is enabled on the cp210x, then auto-RTS must be
re-enabled in the driver.

Signed-off-by: Phu Luu 
Signed-off-by: Brant Merryman 
---
06/09/2020: Patch v3 2/2 Modified based on feedback from Johan Hovold 

12/18/2019: Patch v2 Broken into two patches and modified based on feedback 
from Johan Hovold 
12/09/2019: Initial submission of patch "Proper RTS control when buffers fill"

 drivers/usb/serial/cp210x.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index bcceb4ad8be0..091441b1c5b9 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -917,6 +917,7 @@ static void cp210x_get_termios_port(struct usb_serial_port 
*port,
u32 baud;
u16 bits;
u32 ctl_hs;
+   u32 flow_repl;
 
cp210x_read_u32_reg(port, CP210X_GET_BAUDRATE, );
 
@@ -1017,6 +1018,23 @@ static void cp210x_get_termios_port(struct 
usb_serial_port *port,
ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
if (ctl_hs & CP210X_SERIAL_CTS_HANDSHAKE) {
dev_dbg(dev, "%s - flow control = CRTSCTS\n", __func__);
+   /*
+* When the port is closed, the CP210x hardware disables
+* auto-RTS and RTS is deasserted but it leaves auto-CTS when
+* in hardware flow control mode. This prevents new data from
+* being received by the port. When re-opening the port, if
+* auto-CTS is enabled on the cp210x, then auto-RTS must be
+* re-enabled in the driver.
+*/
+   flow_repl = le32_to_cpu(flow_ctl.ulFlowReplace);
+   flow_repl &= ~CP210X_SERIAL_RTS_MASK;
+   flow_repl |= 
CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_FLOW_CTL);
+   flow_ctl.ulFlowReplace = cpu_to_le32(flow_repl);
+   cp210x_write_reg_block(port,
+   CP210X_SET_FLOW,
+   _ctl,
+   sizeof(flow_ctl));
+
cflag |= CRTSCTS;
} else {
dev_dbg(dev, "%s - flow control = NONE\n", __func__);
-- 
2.17.0

[PATCH v3 1/2] USB: serial: cp210x: Enable usb generic throttle/unthrottle

2020-06-25 Thread Phu Luu

From: Brant Merryman 

Assign the .throttle and .unthrottle functions to be generic function
in the driver structure to prevent data loss that can otherwise occur
if the host does not enable USB throttling.

Signed-off-by: Phu Luu 
Signed-off-by: Brant Merryman 
---
06/09/2020: Patch v3 1/2 Modified based on feedback from Johan Hovold 

12/18/2019: Patch v2 Broken into two patches and modified based on feedback 
from Johan Hovold 
12/09/2019: Initial submission of patch "Proper RTS control when buffers fill"

 drivers/usb/serial/cp210x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index f5143eedbc48..bcceb4ad8be0 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -272,6 +272,8 @@ static struct usb_serial_driver cp210x_device = {
.break_ctl  = cp210x_break_ctl,
.set_termios= cp210x_set_termios,
.tx_empty   = cp210x_tx_empty,
+   .throttle   = usb_serial_generic_throttle,
+   .unthrottle = usb_serial_generic_unthrottle,
.tiocmget   = cp210x_tiocmget,
.tiocmset   = cp210x_tiocmset,
.attach = cp210x_attach,
-- 
2.17.0

Re: [PATCH] cpufreq: schedutil: force frequency update when limits change

2020-06-25 Thread Wei Wang

On Thu, Jun 25, 2020 at 7:32 PM Viresh Kumar  wrote:
>
> On 26-06-20, 07:44, Viresh Kumar wrote:
> > On 25-06-20, 13:47, Wei Wang wrote:
> > > On Thu, Jun 25, 2020 at 3:23 AM Viresh Kumar  
> > > wrote:
> > > > I am sorry but I am not fully sure of what the problem is. Can you
> > > > describe that by giving an example with some random frequency, and
> > > > tell the expected and actual behavior ?
> > > >
> > > The problem is sugov thought next_freq already updated (but actually
> > > skipped by the rate limit thing) and all following updates will be
> > > skipped.
>
> The rate-limiting thing is specific to android and not present in
> mainline. Even in android I see next_freq getting updated only after
> rate-limiting is verified.
>
> I think you maybe trying to fix an android only problem in mainline,
> which may not be required at all. And I am not sure if Android has a
> problem as well :)
>
Yes, that is Android specific, I added you to the Gerrit already.

Thanks!
-Wei

> > I am sorry, can you please give a detailed example with existing
> > frequency and limits, then the limits changed to new values, then what
> > exactly happens ?
> >
> > > Actually this is specifically for Android common kernel 4.19's issue
> > > which has sugov_up_down_rate_limit in sugov_update_next_freq, let's
> > > continue discussion there.
> >
> > If it is a mainline problem, we will surely get it fixed here. Just
> > that I am not able to understand the problem yet. Sorry about that.
>
> --
> viresh

[GIT RFC PULL rcu/urgent] Fix noinstr warnings for KCSAN

2020-06-25 Thread Paul E. McKenney

Hello!

This pull request contains a single commit that uses "arch_" atomic
operations to avoid the instrumentation that comes with the non-"arch_"
versions.  In preparation for that commit, it also has another commit
that makes these "arch_" atomic operations available to generic code.

Without these commits, KCSAN uses can see pointless errors.

This pull request is currently RFC pending ongoing -next testing.
This was not entirely free of drama, with Stephen needing to handle
a merge conflict:

https://lore.kernel.org/lkml/20200626131425.73ee4...@canb.auug.org.au/

However, the resolution looks straightforward to me.  In addition,
these two commits pass rcutorture testing and associated KCSAN testing.

The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:

  Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/urgent

for you to fetch changes up to b58e733fd774f3f4b49d9e7640d172a57e35200e:

  rcu: Fixup noinstr warnings (2020-06-25 08:24:32 -0700)


Peter Zijlstra (2):
  locking/atomics: Provide the arch_atomic_ interface to generic code
  rcu: Fixup noinstr warnings

 include/linux/atomic-fallback.h   | 236 +-
 include/linux/compiler.h  |   2 +-
 kernel/rcu/tree.c |  32 -
 scripts/atomic/gen-atomic-fallback.sh |  31 +
 4 files changed, 292 insertions(+), 9 deletions(-)

[PATCH net-next] bonding: Remove extraneous parentheses in bond_setup

2020-06-25 Thread Nathan Chancellor

Clang warns:

drivers/net/bonding/bond_main.c:4657:23: warning: equality comparison
with extraneous parentheses [-Wparentheses-equality]
if ((BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP))
 ^

drivers/net/bonding/bond_main.c:4681:23: warning: equality comparison
with extraneous parentheses [-Wparentheses-equality]
if ((BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP))
 ^

This warning occurs when a comparision has two sets of parentheses,
which is usually the convention for doing an assignment within an
if statement. Since equality comparisons do not need a second set of
parentheses, remove them to fix the warning.

Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves")
Link: https://github.com/ClangBuiltLinux/linux/issues/1066
Signed-off-by: Nathan Chancellor 
---
 drivers/net/bonding/bond_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 4ef99efc37f6..b3479584cc16 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4654,7 +4654,7 @@ void bond_setup(struct net_device *bond_dev)
 
 #ifdef CONFIG_XFRM_OFFLOAD
/* set up xfrm device ops (only supported in active-backup right now) */
-   if ((BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP))
+   if (BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP)
bond_dev->xfrmdev_ops = _xfrmdev_ops;
bond->xs = NULL;
 #endif /* CONFIG_XFRM_OFFLOAD */
@@ -4678,7 +4678,7 @@ void bond_setup(struct net_device *bond_dev)
 
bond_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL | NETIF_F_GSO_UDP_L4;
 #ifdef CONFIG_XFRM_OFFLOAD
-   if ((BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP))
+   if (BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP)
bond_dev->hw_features |= BOND_XFRM_FEATURES;
 #endif /* CONFIG_XFRM_OFFLOAD */
bond_dev->features |= bond_dev->hw_features;

base-commit: 7bed14551659875e1cd23a7c0266394a29a773b3
-- 
2.27.0

[PATCH V2] scsi: eesox: Fix different dev_id between 'request_irq()' and 'free_irq()'

2020-06-25 Thread Christophe JAILLET

The dev_id used in 'request_irq()' and 'free_irq()' should match.
So use 'info' in both cases.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Christophe JAILLET 
---
V2: update free_irq instead of request_irq in order not to obviously break
code
---
 drivers/scsi/arm/eesox.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/arm/eesox.c b/drivers/scsi/arm/eesox.c
index 6e204a2e0c8d..591ae2a6dd74 100644
--- a/drivers/scsi/arm/eesox.c
+++ b/drivers/scsi/arm/eesox.c
@@ -571,7 +571,7 @@ static int eesoxscsi_probe(struct expansion_card *ec, const 
struct ecard_id *id)
 
if (info->info.scsi.dma != NO_DMA)
free_dma(info->info.scsi.dma);
-   free_irq(ec->irq, host);
+   free_irq(ec->irq, info);
 
  out_remove:
fas216_remove(host);
-- 
2.25.1

Re: [PATCH v3 3/8] mm/hugetlb: unify migration callbacks

2020년 6월 25일 (목) 오후 8:26, Michal Hocko 님이 작성:
>
> On Tue 23-06-20 15:13:43, Joonsoo Kim wrote:
> > From: Joonsoo Kim 
> >
> > There is no difference between two migration callback functions,
> > alloc_huge_page_node() and alloc_huge_page_nodemask(), except
> > __GFP_THISNODE handling. This patch adds an argument, gfp_mask, on
> > alloc_huge_page_nodemask() and replace the callsite for
> > alloc_huge_page_node() with the call to
> > alloc_huge_page_nodemask(..., __GFP_THISNODE).
> >
> > It's safe to remove a node id check in alloc_huge_page_node() since
> > there is no caller passing NUMA_NO_NODE as a node id.
>
> Yes this is indeed safe. alloc_huge_page_node used to be called from
> other internal hugetlb allocation layer and that allowed NUMA_NO_NODE as
> well. Now it is called only from the mempolicy migration callback and
> that always specifies a node and want to stick with that node.
>
> But I have to say I really dislike the gfp semantic because it is
> different from any other allocation function I can think of. It
> specifies what to be added rather than what should be used.
>
> Removing the function is ok but please use the full gfp mask instead
> or if that is impractical for some reason (wich shouldn't be the case
> as htlb_alloc_mask should be trivial to make static inline) make it
> explicit that this is not a gfp_mask but a gfp modifier and explicitly
> state which modifiers are allowed.

Okay. I will try to solve your concern. Concrete solution is not yet prepared
but perhaps I will use full gfp_mask by using htlb_alloc_mask() in caller sites.

Thanks.

[PATCH V2] scsi: powertec: Fix different dev_id between 'request_irq()' and 'free_irq()'

2020-06-25 Thread Christophe JAILLET

The dev_id used in 'request_irq()' and 'free_irq()' should match.
So use 'info' in both cases.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Christophe JAILLET 
---
V2: update free_irq instead of request_irq in order not to obviously break
code
---
 drivers/scsi/arm/powertec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/arm/powertec.c b/drivers/scsi/arm/powertec.c
index 772a13e5fd91..d99ef014528e 100644
--- a/drivers/scsi/arm/powertec.c
+++ b/drivers/scsi/arm/powertec.c
@@ -378,7 +378,7 @@ static int powertecscsi_probe(struct expansion_card *ec,
 
if (info->info.scsi.dma != NO_DMA)
free_dma(info->info.scsi.dma);
-   free_irq(ec->irq, host);
+   free_irq(ec->irq, info);
 
  out_release:
fas216_release(host);
-- 
2.25.1

Re: [PATCH 1/2] HID: wiimote: Initialize the controller LEDs with a device ID value

2020-06-25 Thread David Korth

On Thursday, June 25, 2020 3:09:46 AM EDT David Rheinsberg wrote:
> Hi
> 
> On Thu, 25 Jun 2020 at 00:09, David Korth  wrote:
> > I've been manually setting the player IDs on Wii controllers when running
> > multiplayer games by writing to the /sys/class/leds/ directory. Having the
> > hid-wiimote driver do this itself significantly reduces setup time.
> 
> What do you mean with "reduces setup time significantly"? Why would it
> take that long to set the LEDs?
> 
> Thanks
> David

The LED setup in this case is done entirely manually by me writing to the 
individual files in /sys/class/leds/. This has to be done when the controllers 
are connected initially, and if a controller has to be reconnected for some 
reason (e.g. it runs out of batteries). I don't know of any userspace tools 
that would make this easier to automate, except maybe a shell script, and I'd 
probably still need to run it manually.

Both the Sixaxis and Xpad drivers appear to implement something similar, so 
perhaps a higher-level "player number" mechanism that works with all 
controllers would be worth looking into. This could in theory be done with a 
userspace daemon too (or a udev hook).

As it is right now, I still think implementing it in the wiimote driver is the 
best method to keep it consistent with the rest of the drivers without having 
to install additional userspace tools.

Thanks

Re: [PATCH] scsi: sd: add runtime pm to open / release

2020-06-25 Thread Bart Van Assche

On 2020-06-25 01:16, Martin Kepplinger wrote:
> Also, why isn't "autopm" used in its ioctl() implementation
> (as opposed to in "sr")?

Some of the scsi_autopm_{get,put}_device() calls in the sr driver
have been introduced by me before I fully understood runtime pm.
I will have a another look to see whether these are really
necessary and if not, post a patch to remove these again.

Bart.

[PATCH] samples cn_test: fix cn leakage

2020-06-25 Thread libolingjl

From: liboling 

Error return when add the second cn_test_id,
we need del the first cn_test_id.

Signed-off-by: liboling 
---
 samples/connector/cn_test.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/samples/connector/cn_test.c b/samples/connector/cn_test.c
index 0958a171d0..275e3f9082 100644
--- a/samples/connector/cn_test.c
+++ b/samples/connector/cn_test.c
@@ -151,6 +151,7 @@ static int cn_test_init(void)
cn_test_id.val++;
err = cn_add_callback(_test_id, cn_test_name, cn_test_callback);
if (err) {
+   cn_test_id.val--;
cn_del_callback(_test_id);
goto err_out;
}
-- 
2.17.1

[PATCH V3 1/3] cpufreq: Fix locking issues with governors

The locking around governors handling isn't adequate currently. The list
of governors should never be traversed without locking in place. Also we
must make sure the governor isn't removed while it is still referenced
by code.

Reported-by: Quentin Perret 
Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 59 ---
 1 file changed, 36 insertions(+), 23 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 0128de3603df..e798a1193bdf 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -621,6 +621,24 @@ static struct cpufreq_governor *find_governor(const char 
*str_governor)
return NULL;
 }
 
+static struct cpufreq_governor *get_governor(const char *str_governor)
+{
+   struct cpufreq_governor *t;
+
+   mutex_lock(_governor_mutex);
+   t = find_governor(str_governor);
+   if (!t)
+   goto unlock;
+
+   if (!try_module_get(t->owner))
+   t = NULL;
+
+unlock:
+   mutex_unlock(_governor_mutex);
+
+   return t;
+}
+
 static unsigned int cpufreq_parse_policy(char *str_governor)
 {
if (!strncasecmp(str_governor, "performance", CPUFREQ_NAME_LEN))
@@ -640,28 +658,14 @@ static struct cpufreq_governor 
*cpufreq_parse_governor(char *str_governor)
 {
struct cpufreq_governor *t;
 
-   mutex_lock(_governor_mutex);
-
-   t = find_governor(str_governor);
-   if (!t) {
-   int ret;
-
-   mutex_unlock(_governor_mutex);
-
-   ret = request_module("cpufreq_%s", str_governor);
-   if (ret)
-   return NULL;
-
-   mutex_lock(_governor_mutex);
+   t = get_governor(str_governor);
+   if (t)
+   return t;
 
-   t = find_governor(str_governor);
-   }
-   if (t && !try_module_get(t->owner))
-   t = NULL;
-
-   mutex_unlock(_governor_mutex);
+   if (request_module("cpufreq_%s", str_governor))
+   return NULL;
 
-   return t;
+   return get_governor(str_governor);
 }
 
 /**
@@ -815,12 +819,14 @@ static ssize_t show_scaling_available_governors(struct 
cpufreq_policy *policy,
goto out;
}
 
+   mutex_lock(_governor_mutex);
for_each_governor(t) {
if (i >= (ssize_t) ((PAGE_SIZE / sizeof(char))
- (CPUFREQ_NAME_LEN + 2)))
-   goto out;
+   break;
i += scnprintf([i], CPUFREQ_NAME_PLEN, "%s ", t->name);
}
+   mutex_unlock(_governor_mutex);
 out:
i += sprintf([i], "\n");
return i;
@@ -1058,11 +1064,14 @@ static int cpufreq_init_policy(struct cpufreq_policy 
*policy)
struct cpufreq_governor *def_gov = cpufreq_default_governor();
struct cpufreq_governor *gov = NULL;
unsigned int pol = CPUFREQ_POLICY_UNKNOWN;
+   bool put_governor = false;
+   int ret;
 
if (has_target()) {
/* Update policy governor to the one used before hotplug. */
-   gov = find_governor(policy->last_governor);
+   gov = get_governor(policy->last_governor);
if (gov) {
+   put_governor = true;
pr_debug("Restoring governor %s for cpu %d\n",
 policy->governor->name, policy->cpu);
} else if (def_gov) {
@@ -1089,7 +1098,11 @@ static int cpufreq_init_policy(struct cpufreq_policy 
*policy)
return -ENODATA;
}
 
-   return cpufreq_set_policy(policy, gov, pol);
+   ret = cpufreq_set_policy(policy, gov, pol);
+   if (put_governor)
+   module_put(gov->owner);
+
+   return ret;
 }
 
 static int cpufreq_add_policy_cpu(struct cpufreq_policy *policy, unsigned int 
cpu)
-- 
2.25.0.rc1.19.g042ed3e048af

[PATCH V3 2/3] cpufreq: Register governors at core_initcall

From: Quentin Perret 

Currently, most CPUFreq governors are registered at core_initcall time
when used as default, and module_init otherwise. In preparation for
letting users specify the default governor on the kernel command line,
change all of them to use core_initcall unconditionally, as is already
the case for schedutil and performance. This will enable us to assume
builtin governors have been registered before the builtin CPUFreq
drivers probe.

And since all governors now have similar init/exit patterns, introduce
two new macros cpufreq_governor_{init,exit}() to factorize the code.

Acked-by: Viresh Kumar 
Signed-off-by: Quentin Perret 
Signed-off-by: Viresh Kumar 
---
 .../platforms/cell/cpufreq_spudemand.c| 26 ++-
 drivers/cpufreq/cpufreq_conservative.c| 22 
 drivers/cpufreq/cpufreq_ondemand.c| 24 +
 drivers/cpufreq/cpufreq_performance.c | 14 ++
 drivers/cpufreq/cpufreq_powersave.c   | 18 +++--
 drivers/cpufreq/cpufreq_userspace.c   | 18 +++--
 include/linux/cpufreq.h   | 14 ++
 kernel/sched/cpufreq_schedutil.c  |  6 +
 8 files changed, 36 insertions(+), 106 deletions(-)

diff --git a/arch/powerpc/platforms/cell/cpufreq_spudemand.c 
b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
index 55b31eadb3c8..ca7849e113d7 100644
--- a/arch/powerpc/platforms/cell/cpufreq_spudemand.c
+++ b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
@@ -126,30 +126,8 @@ static struct cpufreq_governor spu_governor = {
.stop = spu_gov_stop,
.owner = THIS_MODULE,
 };
-
-/*
- * module init and destoy
- */
-
-static int __init spu_gov_init(void)
-{
-   int ret;
-
-   ret = cpufreq_register_governor(_governor);
-   if (ret)
-   printk(KERN_ERR "registration of governor failed\n");
-   return ret;
-}
-
-static void __exit spu_gov_exit(void)
-{
-   cpufreq_unregister_governor(_governor);
-}
-
-
-module_init(spu_gov_init);
-module_exit(spu_gov_exit);
+cpufreq_governor_init(spu_governor);
+cpufreq_governor_exit(spu_governor);
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Christian Krafft ");
-
diff --git a/drivers/cpufreq/cpufreq_conservative.c 
b/drivers/cpufreq/cpufreq_conservative.c
index 737ff3b9c2c0..aa39ff31ec9f 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -322,17 +322,7 @@ static struct dbs_governor cs_governor = {
.start = cs_start,
 };
 
-#define CPU_FREQ_GOV_CONSERVATIVE  (_governor.gov)
-
-static int __init cpufreq_gov_dbs_init(void)
-{
-   return cpufreq_register_governor(CPU_FREQ_GOV_CONSERVATIVE);
-}
-
-static void __exit cpufreq_gov_dbs_exit(void)
-{
-   cpufreq_unregister_governor(CPU_FREQ_GOV_CONSERVATIVE);
-}
+#define CPU_FREQ_GOV_CONSERVATIVE  (cs_governor.gov)
 
 MODULE_AUTHOR("Alexander Clouter ");
 MODULE_DESCRIPTION("'cpufreq_conservative' - A dynamic cpufreq governor for "
@@ -343,11 +333,9 @@ MODULE_LICENSE("GPL");
 #ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
 struct cpufreq_governor *cpufreq_default_governor(void)
 {
-   return CPU_FREQ_GOV_CONSERVATIVE;
+   return _FREQ_GOV_CONSERVATIVE;
 }
-
-core_initcall(cpufreq_gov_dbs_init);
-#else
-module_init(cpufreq_gov_dbs_init);
 #endif
-module_exit(cpufreq_gov_dbs_exit);
+
+cpufreq_governor_init(CPU_FREQ_GOV_CONSERVATIVE);
+cpufreq_governor_exit(CPU_FREQ_GOV_CONSERVATIVE);
diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index 82a4d37ddecb..ac361a8b1d3b 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -408,7 +408,7 @@ static struct dbs_governor od_dbs_gov = {
.start = od_start,
 };
 
-#define CPU_FREQ_GOV_ONDEMAND  (_dbs_gov.gov)
+#define CPU_FREQ_GOV_ONDEMAND  (od_dbs_gov.gov)
 
 static void od_set_powersave_bias(unsigned int powersave_bias)
 {
@@ -429,7 +429,7 @@ static void od_set_powersave_bias(unsigned int 
powersave_bias)
continue;
 
policy = cpufreq_cpu_get_raw(cpu);
-   if (!policy || policy->governor != CPU_FREQ_GOV_ONDEMAND)
+   if (!policy || policy->governor != _FREQ_GOV_ONDEMAND)
continue;
 
policy_dbs = policy->governor_data;
@@ -461,16 +461,6 @@ void od_unregister_powersave_bias_handler(void)
 }
 EXPORT_SYMBOL_GPL(od_unregister_powersave_bias_handler);
 
-static int __init cpufreq_gov_dbs_init(void)
-{
-   return cpufreq_register_governor(CPU_FREQ_GOV_ONDEMAND);
-}
-
-static void __exit cpufreq_gov_dbs_exit(void)
-{
-   cpufreq_unregister_governor(CPU_FREQ_GOV_ONDEMAND);
-}
-
 MODULE_AUTHOR("Venkatesh Pallipadi ");
 MODULE_AUTHOR("Alexey Starikovskiy ");
 MODULE_DESCRIPTION("'cpufreq_ondemand' - A dynamic cpufreq governor for "
@@ -480,11 +470,9 @@ MODULE_LICENSE("GPL");
 #ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
 struct cpufreq_governor

[PATCH V3 3/3] cpufreq: Specify default governor on command line

From: Quentin Perret 

Currently, the only way to specify the default CPUfreq governor is via
Kconfig options, which suits users who can build the kernel themselves
perfectly.

However, for those who use a distro-like kernel (such as Android, with
the Generic Kernel Image project), the only way to use a different
default is to boot to userspace, and to then switch using the sysfs
interface. Being able to specify the default governor on the command
line, like is the case for cpuidle, would enable those users to specify
their governor of choice earlier on, and to simplify slighlty the
userspace boot procedure.

To support this use-case, add a kernel command line parameter enabling
to specify a default governor for CPUfreq, which takes precedence over
the builtin default.

This implementation has one notable limitation: the default governor
must be registered before the driver. This is solved for builtin
governors and drivers using appropriate *_initcall() functions. And in
the modular case, this must be reflected as a constraint on the module
loading order.

Signed-off-by: Quentin Perret 
[ Viresh: Converted 'default_governor' to a string and parsing it only
  at initcall level, and several updates to
  cpufreq_init_policy(). ]
Signed-off-by: Viresh Kumar 
---
 .../admin-guide/kernel-parameters.txt |  5 +++
 Documentation/admin-guide/pm/cpufreq.rst  |  6 ++--
 drivers/cpufreq/cpufreq.c | 36 ++-
 3 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index fb95fad81c79..8deb5a89328a 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -703,6 +703,11 @@
cpufreq.off=1   [CPU_FREQ]
disable the cpufreq sub-system
 
+   cpufreq.default_governor=
+   [CPU_FREQ] Name of the default cpufreq governor or
+   policy to use. This governor must be registered in the
+   kernel before the cpufreq driver probes.
+
cpu_init_udelay=N
[X86] Delay for N microsec between assert and de-assert
of APIC INIT to start processors.  This delay occurs
diff --git a/Documentation/admin-guide/pm/cpufreq.rst 
b/Documentation/admin-guide/pm/cpufreq.rst
index 0c74a7784964..368e612145d2 100644
--- a/Documentation/admin-guide/pm/cpufreq.rst
+++ b/Documentation/admin-guide/pm/cpufreq.rst
@@ -147,9 +147,9 @@ CPUs in it.
 
 The next major initialization step for a new policy object is to attach a
 scaling governor to it (to begin with, that is the default scaling governor
-determined by the kernel configuration, but it may be changed later
-via ``sysfs``).  First, a pointer to the new policy object is passed to the
-governor's ``->init()`` callback which is expected to initialize all of the
+determined by the kernel command line or configuration, but it may be changed
+later via ``sysfs``).  First, a pointer to the new policy object is passed to
+the governor's ``->init()`` callback which is expected to initialize all of the
 data structures necessary to handle the given policy and, possibly, to add
 a governor ``sysfs`` interface to it.  Next, the governor is started by
 invoking its ``->start()`` callback.
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e798a1193bdf..93c6399c1a42 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -50,6 +50,9 @@ static LIST_HEAD(cpufreq_governor_list);
 #define for_each_governor(__governor)  \
list_for_each_entry(__governor, _governor_list, governor_list)
 
+static char cpufreq_param_governor[CPUFREQ_NAME_LEN];
+static char default_governor[CPUFREQ_NAME_LEN];
+
 /**
  * The "cpufreq driver" - the arch- or hardware-dependent low
  * level driver of CPUFreq support, and its spinlock. This lock
@@ -1061,7 +1064,6 @@ __weak struct cpufreq_governor 
*cpufreq_default_governor(void)
 
 static int cpufreq_init_policy(struct cpufreq_policy *policy)
 {
-   struct cpufreq_governor *def_gov = cpufreq_default_governor();
struct cpufreq_governor *gov = NULL;
unsigned int pol = CPUFREQ_POLICY_UNKNOWN;
bool put_governor = false;
@@ -1071,22 +1073,29 @@ static int cpufreq_init_policy(struct cpufreq_policy 
*policy)
/* Update policy governor to the one used before hotplug. */
gov = get_governor(policy->last_governor);
if (gov) {
-   put_governor = true;
pr_debug("Restoring governor %s for cpu %d\n",
-policy->governor->name, policy->cpu);
-   } else if (def_gov) {
-   gov = def_gov;
+gov->name, policy->cpu);
} else {
-

[PATCH v3 0/3] cpufreq: Allow default governor on cmdline and fix locking issues

Hi,

I have picked Quentin's series over my patch, modified both and tested.

V2->V3:
- default_governor is a string now and we don't set it on governor
  registration or unregistration anymore.
- Fixed locking issues in cpufreq_init_policy().

--
Viresh

Original cover letter fro Quentin:

This series enables users of prebuilt kernels (e.g. distro kernels) to
specify their CPUfreq governor of choice using the kernel command line,
instead of having to wait for the system to fully boot to userspace to
switch using the sysfs interface. This is helpful for 2 reasons:
  1. users get to choose the governor that runs during the actual boot;
  2. it simplifies the userspace boot procedure a bit (one less thing to
 worry about).

To enable this, the first patch moves all governor init calls to
core_initcall, to make sure they are registered by the time the drivers
probe. This should be relatively low impact as registering a governor
is a simple procedure (it gets added to a llist), and all governors
already load at core_initcall anyway when they're set as the default
in Kconfig. This also allows to clean-up the governors' init/exit code,
and reduces boilerplate.

The second patch introduces the new command line parameter, inspired by
its cpuidle counterpart. More details can be found in the respective
patch headers.

Changes in v2:
 - added Viresh's ack to patch 01
 - moved the assignment of 'default_governor' in patch 02 to the governor
   registration path instead of the driver registration (Viresh)

Quentin Perret (2):
  cpufreq: Register governors at core_initcall
  cpufreq: Specify default governor on command line

Viresh Kumar (1):
  cpufreq: Fix locking issues with governors

 .../admin-guide/kernel-parameters.txt |  5 +
 Documentation/admin-guide/pm/cpufreq.rst  |  6 +-
 .../platforms/cell/cpufreq_spudemand.c| 26 +-
 drivers/cpufreq/cpufreq.c | 93 ---
 drivers/cpufreq/cpufreq_conservative.c| 22 +
 drivers/cpufreq/cpufreq_ondemand.c| 24 ++---
 drivers/cpufreq/cpufreq_performance.c | 14 +--
 drivers/cpufreq/cpufreq_powersave.c   | 18 +---
 drivers/cpufreq/cpufreq_userspace.c   | 18 +---
 include/linux/cpufreq.h   | 14 +++
 kernel/sched/cpufreq_schedutil.c  |  6 +-
 11 files changed, 106 insertions(+), 140 deletions(-)

-- 
2.25.0.rc1.19.g042ed3e048af

RE: [PATCH v2 2/2] arm64: mm: reserve per-numa CMA after numa_init

2020-06-25 Thread Song Bao Hua (Barry Song)



> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Thursday, June 25, 2020 11:16 PM
> To: Song Bao Hua (Barry Song) ; h...@lst.de;
> m.szyprow...@samsung.com; w...@kernel.org;
> ganapatrao.kulka...@cavium.com; catalin.mari...@arm.com
> Cc: io...@lists.linux-foundation.org; Linuxarm ;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Nicolas
> Saenz Julienne ; Steve Capper
> ; Andrew Morton ;
> Mike Rapoport 
> Subject: Re: [PATCH v2 2/2] arm64: mm: reserve per-numa CMA after
> numa_init
> 
> On 2020-06-25 08:43, Barry Song wrote:
> > Right now, smmu is using dma_alloc_coherent() to get memory to save
> queues
> > and tables. Typically, on ARM64 server, there is a default CMA located at
> > node0, which could be far away from node2, node3 etc.
> > with this patch, smmu will get memory from local numa node to save
> command
> > queues and page tables. that means dma_unmap latency will be shrunk
> much.
> > Meanwhile, when iommu.passthrough is on, device drivers which call dma_
> > alloc_coherent() will also get local memory and avoid the travel between
> > numa nodes.
> >
> > Cc: Christoph Hellwig 
> > Cc: Marek Szyprowski 
> > Cc: Will Deacon 
> > Cc: Robin Murphy 
> > Cc: Ganapatrao Kulkarni 
> > Cc: Catalin Marinas 
> > Cc: Nicolas Saenz Julienne 
> > Cc: Steve Capper 
> > Cc: Andrew Morton 
> > Cc: Mike Rapoport 
> > Signed-off-by: Barry Song 
> > ---
> >   arch/arm64/mm/init.c | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 1e93cfc7c47a..07d4d1fe7983 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -420,6 +420,8 @@ void __init bootmem_init(void)
> >
> > arm64_numa_init();
> >
> > +   dma_pernuma_cma_reserve();
> > +
> 
> It might be worth putting this after the hugetlb_cma_reserve() call for
> clarity, since the comment below applies equally to this call too.

Yep, it looks even better though dma_pernuma_cma_reserve() is self-documenting 
by name.

> 
> Robin.
> 
> > /*
> >  * must be done after arm64_numa_init() which calls numa_init() to
> >  * initialize node_online_map that gets used in hugetlb_cma_reserve()
> >
Thanks
Barry

[PATCH 1/1] drm/bridge: analogix_dp: Add enable_psr param

2020-06-25 Thread Shawn Anastasio

Add a toggle to enable/disable PSR from the kernel commandline.
This is useful in situations where PSR is supported by the hardware
but is not desired by the user. One such use case is working around
hardware errata.

Signed-off-by: Shawn Anastasio 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 76736fb8ed94..9735ab71fca7 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -35,6 +35,10 @@
 
 static const bool verify_fast_training;
 
+static bool enable_psr = true;
+module_param(enable_psr, bool, 0644);
+MODULE_PARM_DESC(enable_psr, "PSR support (1 = enabled (default), 0 = 
disabled)");
+
 struct bridge_init {
struct i2c_client *client;
struct device_node *node;
@@ -979,7 +983,7 @@ static int analogix_dp_commit(struct analogix_dp_device *dp)
if (ret)
return ret;
 
-   if (analogix_dp_detect_sink_psr(dp)) {
+   if (enable_psr && analogix_dp_detect_sink_psr(dp)) {
ret = analogix_dp_enable_sink_psr(dp);
if (ret)
return ret;
-- 
2.26.2

[PATCH 0/1] drm/bridge: analogix_dp: Add PSR toggle

2020-06-25 Thread Shawn Anastasio

This patch adds a commandline toggle for the Panel Self-Refresh feature
to the analogix_dp bridge driver, much like the one in i915.

This is required to work around a hardware fault in some Pinebook Pro units
from the May 2020 batch whose display panels seem to behave sporadically
when PSR is enabled.

Shawn Anastasio (1):
  drm/bridge: analogix_dp: Add enable_psr param

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
2.26.2

mmotm 2020-06-25-20-36 uploaded

2020-06-25 Thread akpm

The mm-of-the-moment snapshot 2020-06-25-20-36 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (5.x
or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

https://github.com/hnaz/linux-mm

The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is also available at

https://github.com/hnaz/linux-mm



This mmotm tree contains the following patches against 5.8-rc2:
(patches marked "*" will be included in linux-next)

  origin.patch
* openrisc-fix-boot-oops-when-debug_vm-is-enabled.patch
* mm-do_swap_page-fix-up-the-error-code-instantiation.patch
* mm-compaction-make-capture-control-handling-safe-wrt-interrupts.patch
* 
kexec-do-not-verify-the-signature-without-the-lockdown-or-mandatory-signature.patch
* ocfs2-avoid-inode-removed-while-nfsd-access-it.patch
* ocfs2-load-global_inode_alloc.patch
* ocfs2-fix-panic-on-nfs-server-over-ocfs2.patch
* ocfs2-fix-value-of-ocfs2_invalid_slot.patch
* lib-fix-test_hmmc-reference-after-free.patch
* linux-bitsh-fix-unsigned-less-than-zero-warnings.patch
* mm-slab-fix-sign-conversion-problem-in-memcg_uncharge_slab.patch
* mm-slab-use-memzero_explicit-in-kzfree.patch
* slub-cure-list_slab_objects-from-double-fix.patch
* mm-fix-swap-cache-node-allocation-mask.patch
* mm-memoryc-properly-pte_offset_map_lock-unlock-in-vm_insert_pages.patch
* mm-debug_vm_pgtable-fix-build-failure-with-powerpc-8xx.patch
* make-asm-generic-cacheflushh-more-standalone.patch
* media-omap3isp-remove-cacheflushh.patch
* mm-fix-a-warning-while-make-xmldocs.patch
* mm-memcontrol-handle-div0-crash-race-condition-in-memorylow.patch
* mm-memcontrol-fix-do-not-put-the-css-reference.patch
* mm-memcg-prevent-missed-memorylow-load-tears.patch
* docs-mm-gup-minor-documentation-update.patch
* doc-thp-cow-fault-no-longer-allocate-thp.patch
* mm-workingset-age-nonresident-information-alongside-anonymous-pages.patch
* 
mm-swap-fix-for-mm-workingset-age-nonresident-information-alongside-anonymous-pages.patch
* mm-memory-fix-io-cost-for-anonymous-page.patch
* x86-hyperv-allocate-the-hypercall-page-with-only-read-and-execute-bits.patch
* arm64-use-page_kernel_rox-directly-in-alloc_insn_page.patch
* mm-remove-vmalloc_exec.patch
* mm-fix-false-softlockup-during-pfn-range-removal.patch
* maintainers-update-info-for-sparse.patch
* mm-shuffle-dont-move-pages-between-zones-and-dont-read-garbage-memmaps.patch
* mm-page_alloc-fix-documentation-error.patch
* proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch
* proc-kpageflags-do-not-use-uninitialized-struct-pages.patch
* checkpatch-test-git_dir-changes.patch
* scripts-tagssh-collect-compiled-source-precisely.patch
* bloat-o-meter-support-comparing-library-archives.patch
* scripts-decode_stacktrace-skip-missing-symbols.patch
* scripts-decode_stacktrace-guess-basepath-if-not-specified.patch
* scripts-decode_stacktrace-guess-path-to-modules.patch
* scripts-decode_stacktrace-guess-path-to-vmlinux-by-release-name.patch
* ocfs2-clear-links-count-in-ocfs2_mknod-if-an-error-occurs.patch
* ocfs2-fix-ocfs2-corrupt-when-iputting-an-inode.patch
* ramfs-support-o_tmpfile.patch
* kernel-watchdog-flush-all-printk-nmi-buffers-when-hardlockup-detected.patch
  mm.patch
* mm-treewide-rename-kzfree-to-kfree_sensitive.patch
* mm-ksize-should-silently-accept-a-null-pointer.patch
* mm-expand-config_slab_freelist_hardened-to-include-slab.patch
* slab-add-naive-detection-of-double-free.patch
* mm-slub-extend-slub_debug-syntax-for-multiple-blocks.patch
* mm-slub-make-some-slub_debug-related-attributes-read-only.patch
* mm-slub-remove-runtime-allocation-order-changes.patch
* mm-slub-make-remaining-slub_debug-related-attributes-read-only.patch
* mm-slub-make-reclaim_account-attribute-read-only.patch
* mm-slub-introduce-static-key-for-slub_debug.patch
*

Re: [RFC][PATCH] ring-buffer: Have nested events still record running time stamp

2020-06-25 Thread Steven Rostedt

On Thu, 25 Jun 2020 22:36:11 -0400
Steven Rostedt  wrote:

> +static void rb_time_set(rb_time_t *t, u64 val)
> +{
> + struct rb_time_read r;
> +
> + rb_time_read_set(, val);
> +
> + do {
> + r.start_cnt = local_inc_return(>start_cnt);
> + local_set(>top, r.top);
> + local_set(>bottom, r.bottom);
> + local_set(>end_cnt, r.start_cnt);
> + } while (r.start_cnt != local_read(>start_cnt));
> +}
> +
> +static bool rb_time_read_cmpxchg(local_t *l, unsigned long expect, unsigned 
> long set)
> +{
> + unsigned long ret;
> +
> + ret = local_cmpxchg(l, expect, set);
> + return ret == expect;
> +}
> +
> +static bool rb_time_cmpxchg(rb_time_t *t, u64 expect, u64 set)
> +{
> + struct rb_time_read e, s;
> +
> + rb_time_read_set(, expect);
> + rb_time_read_set(, set);
> +
> + e.start_cnt = local_read(>start_cnt);
> + e.end_cnt = local_read(>end_cnt);
> +
> + s.start_cnt = e.start_cnt + 1;
> + s.end_cnt = e.start_cnt;
> +
> + if (!rb_time_read_cmpxchg(>start_cnt, e.start_cnt, s.start_cnt))
> + return false;
> + if (!rb_time_read_cmpxchg(>top, e.top, s.top))
> + return false;
> + if (!rb_time_read_cmpxchg(>bottom, e.bottom, s.bottom))
> + return false;
> + return rb_time_read_cmpxchg(>end_cnt, e.end_cnt, s.end_cnt);
> +}
> +

I have to think about this more, as I think there's a flaw in this
cmpxchg algorithm.

-- Steve

[PATCH v4] selftests: tpm: upgrade TPM2 tests from Python 2 to Python 3

2020-06-25 Thread Pengfei Xu

Python 2 is no longer supported by the Python upstream project, so
upgrade TPM2 tests to Python 3.

Signed-off-by: Pengfei Xu 
---
 tools/testing/selftests/tpm2/test_smoke.sh |  4 +-
 tools/testing/selftests/tpm2/test_space.sh |  2 +-
 tools/testing/selftests/tpm2/tpm2.py   | 56 +++---
 tools/testing/selftests/tpm2/tpm2_tests.py | 39 +++
 4 files changed, 52 insertions(+), 49 deletions(-)

diff --git a/tools/testing/selftests/tpm2/test_smoke.sh 
b/tools/testing/selftests/tpm2/test_smoke.sh
index 663062701d5a..d05467f6d258 100755
--- a/tools/testing/selftests/tpm2/test_smoke.sh
+++ b/tools/testing/selftests/tpm2/test_smoke.sh
@@ -6,8 +6,8 @@ ksft_skip=4
 
 [ -f /dev/tpm0 ] || exit $ksft_skip
 
-python -m unittest -v tpm2_tests.SmokeTest
-python -m unittest -v tpm2_tests.AsyncTest
+python3 -m unittest -v tpm2_tests.SmokeTest
+python3 -m unittest -v tpm2_tests.AsyncTest
 
 CLEAR_CMD=$(which tpm2_clear)
 if [ -n $CLEAR_CMD ]; then
diff --git a/tools/testing/selftests/tpm2/test_space.sh 
b/tools/testing/selftests/tpm2/test_space.sh
index 36c9d030a1c6..151c64e8ee9f 100755
--- a/tools/testing/selftests/tpm2/test_space.sh
+++ b/tools/testing/selftests/tpm2/test_space.sh
@@ -6,4 +6,4 @@ ksft_skip=4
 
 [ -f /dev/tpmrm0 ] || exit $ksft_skip
 
-python -m unittest -v tpm2_tests.SpaceTest
+python3 -m unittest -v tpm2_tests.SpaceTest
diff --git a/tools/testing/selftests/tpm2/tpm2.py 
b/tools/testing/selftests/tpm2/tpm2.py
index d0fcb66a88a6..f34486cd7342 100644
--- a/tools/testing/selftests/tpm2/tpm2.py
+++ b/tools/testing/selftests/tpm2/tpm2.py
@@ -247,14 +247,14 @@ class ProtocolError(Exception):
 class AuthCommand(object):
 """TPMS_AUTH_COMMAND"""
 
-def __init__(self, session_handle=TPM2_RS_PW, nonce='', 
session_attributes=0,
- hmac=''):
+def __init__(self, session_handle=TPM2_RS_PW, nonce=bytes(),
+ session_attributes=0, hmac=bytes()):
 self.session_handle = session_handle
 self.nonce = nonce
 self.session_attributes = session_attributes
 self.hmac = hmac
 
-def __str__(self):
+def __bytes__(self):
 fmt = '>I H%us B H%us' % (len(self.nonce), len(self.hmac))
 return struct.pack(fmt, self.session_handle, len(self.nonce),
self.nonce, self.session_attributes, len(self.hmac),
@@ -268,11 +268,11 @@ class AuthCommand(object):
 class SensitiveCreate(object):
 """TPMS_SENSITIVE_CREATE"""
 
-def __init__(self, user_auth='', data=''):
+def __init__(self, user_auth=bytes(), data=bytes()):
 self.user_auth = user_auth
 self.data = data
 
-def __str__(self):
+def __bytes__(self):
 fmt = '>H%us H%us' % (len(self.user_auth), len(self.data))
 return struct.pack(fmt, len(self.user_auth), self.user_auth,
len(self.data), self.data)
@@ -296,8 +296,9 @@ class Public(object):
 return '>HHIH%us%usH%us' % \
 (len(self.auth_policy), len(self.parameters), len(self.unique))
 
-def __init__(self, object_type, name_alg, object_attributes, 
auth_policy='',
- parameters='', unique=''):
+def __init__(self, object_type, name_alg, object_attributes,
+ auth_policy=bytes(), parameters=bytes(),
+ unique=bytes()):
 self.object_type = object_type
 self.name_alg = name_alg
 self.object_attributes = object_attributes
@@ -305,7 +306,7 @@ class Public(object):
 self.parameters = parameters
 self.unique = unique
 
-def __str__(self):
+def __bytes__(self):
 return struct.pack(self.__fmt(),
self.object_type,
self.name_alg,
@@ -343,7 +344,7 @@ def get_algorithm(name):
 
 def hex_dump(d):
 d = [format(ord(x), '02x') for x in d]
-d = [d[i: i + 16] for i in xrange(0, len(d), 16)]
+d = [d[i: i + 16] for i in range(0, len(d), 16)]
 d = [' '.join(x) for x in d]
 d = os.linesep.join(d)
 
@@ -401,7 +402,7 @@ class Client:
 pcrsel_len = max((i >> 3) + 1, 3)
 pcrsel = [0] * pcrsel_len
 pcrsel[i >> 3] = 1 << (i & 7)
-pcrsel = ''.join(map(chr, pcrsel))
+pcrsel = ''.join(map(chr, pcrsel)).encode()
 
 fmt = '>HII IHB%us' % (pcrsel_len)
 cmd = struct.pack(fmt,
@@ -443,7 +444,7 @@ class Client:
 TPM2_CC_PCR_EXTEND,
 i,
 len(auth_cmd),
-str(auth_cmd),
+bytes(auth_cmd),
 1, bank_alg, dig)
 
 self.send_cmd(cmd)
@@ -457,7 +458,7 @@ class Client:
   TPM2_RH_NULL,
   TPM2_RH_NULL,
   16,
-  '\0' * 16,
+  ('\0' * 16).encode(),
   0,
   session_type,
   TPM2_ALG_NULL,
@@ -472,7 +473,7 @@ class Client:
 
 for i in

linux-next: manual merge of the usb tree with the usb.current tree

Hi all,

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

  drivers/usb/cdns3/ep0.c

between commit:

  c0e2a0341cd8 ("usb: cdns3: ep0: fix the test mode set incorrectly")

from the usb.current tree and commit:

  62fb45d317c5 ("USB: ch9: add "USB_" prefix in front of TEST defines")

from the usb 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 drivers/usb/cdns3/ep0.c
index 61ec5bb2b0ca,04a522f5ae58..
--- a/drivers/usb/cdns3/ep0.c
+++ b/drivers/usb/cdns3/ep0.c
@@@ -327,12 -327,11 +327,12 @@@ static int cdns3_ep0_feature_handle_dev
if (!set || (tmode & 0xff) != 0)
return -EINVAL;
  
 -  switch (tmode >> 8) {
 +  tmode >>= 8;
 +  switch (tmode) {
-   case TEST_J:
-   case TEST_K:
-   case TEST_SE0_NAK:
-   case TEST_PACKET:
+   case USB_TEST_J:
+   case USB_TEST_K:
+   case USB_TEST_SE0_NAK:
+   case USB_TEST_PACKET:
cdns3_set_register_bit(_dev->regs->usb_cmd,
   USB_CMD_STMODE |
   USB_STS_TMODE_SEL(tmode - 1));


pgpCRdKSpjJz_.pgp
Description: OpenPGP digital signature

Re: [PATCH v3] selftests: tpm: upgrade TPM2 tests from Python 2 to Python 3

2020-06-25 Thread Pengfei Xu

Hi Jarkko,
  I missed this improvement in previous mail.
  Will do.

Thanks!
BR.

On 2020-06-26 at 00:51:45 +0300, Jarkko Sakkinen wrote:
> On Fri, Jun 26, 2020 at 12:37:54AM +0800, Pengfei Xu wrote:
> > Python 2 is no longer supported by the Python upstream project, so
> > upgrade TPM2 tests to Python 3.
> > 
> > Signed-off-by: Pengfei Xu 
> > ---
> >  tools/testing/selftests/tpm2/test_smoke.sh |  4 +-
> >  tools/testing/selftests/tpm2/test_space.sh |  2 +-
> >  tools/testing/selftests/tpm2/tpm2.py   | 56 +++---
> >  tools/testing/selftests/tpm2/tpm2_tests.py | 39 +++
> >  4 files changed, 52 insertions(+), 49 deletions(-)
> > 
> > diff --git a/tools/testing/selftests/tpm2/test_smoke.sh 
> > b/tools/testing/selftests/tpm2/test_smoke.sh
> > index 663062701d5a..d05467f6d258 100755
> > --- a/tools/testing/selftests/tpm2/test_smoke.sh
> > +++ b/tools/testing/selftests/tpm2/test_smoke.sh
> > @@ -6,8 +6,8 @@ ksft_skip=4
> >  
> >  [ -f /dev/tpm0 ] || exit $ksft_skip
> >  
> > -python -m unittest -v tpm2_tests.SmokeTest
> > -python -m unittest -v tpm2_tests.AsyncTest
> > +python3 -m unittest -v tpm2_tests.SmokeTest
> > +python3 -m unittest -v tpm2_tests.AsyncTest
> >  
> >  CLEAR_CMD=$(which tpm2_clear)
> >  if [ -n $CLEAR_CMD ]; then
> > diff --git a/tools/testing/selftests/tpm2/test_space.sh 
> > b/tools/testing/selftests/tpm2/test_space.sh
> > index 36c9d030a1c6..151c64e8ee9f 100755
> > --- a/tools/testing/selftests/tpm2/test_space.sh
> > +++ b/tools/testing/selftests/tpm2/test_space.sh
> > @@ -6,4 +6,4 @@ ksft_skip=4
> >  
> >  [ -f /dev/tpmrm0 ] || exit $ksft_skip
> >  
> > -python -m unittest -v tpm2_tests.SpaceTest
> > +python3 -m unittest -v tpm2_tests.SpaceTest
> > diff --git a/tools/testing/selftests/tpm2/tpm2.py 
> > b/tools/testing/selftests/tpm2/tpm2.py
> > index d0fcb66a88a6..88a0e7776a23 100644
> > --- a/tools/testing/selftests/tpm2/tpm2.py
> > +++ b/tools/testing/selftests/tpm2/tpm2.py
> > @@ -247,14 +247,14 @@ class ProtocolError(Exception):
> >  class AuthCommand(object):
> >  """TPMS_AUTH_COMMAND"""
> >  
> > -def __init__(self, session_handle=TPM2_RS_PW, nonce='', 
> > session_attributes=0,
> > - hmac=''):
> > +def __init__(self, session_handle=TPM2_RS_PW, nonce=''.encode(),
> > + session_attributes=0, hmac=''.encode()):
> 
> Initialize these just directly as empty bytes objects (e.g.
> nonce=bytes())
> 
> >  self.session_handle = session_handle
> >  self.nonce = nonce
> >  self.session_attributes = session_attributes
> >  self.hmac = hmac
> >  
> > -def __str__(self):
> > +def __bytes__(self):
> >  fmt = '>I H%us B H%us' % (len(self.nonce), len(self.hmac))
> >  return struct.pack(fmt, self.session_handle, len(self.nonce),
> > self.nonce, self.session_attributes, 
> > len(self.hmac),
> > @@ -268,11 +268,11 @@ class AuthCommand(object):
> >  class SensitiveCreate(object):
> >  """TPMS_SENSITIVE_CREATE"""
> >  
> > -def __init__(self, user_auth='', data=''):
> > +def __init__(self, user_auth=''.encode(), data=''.encode()):
> 
> Ditto.
> 
> >  self.user_auth = user_auth
> >  self.data = data
> >  
> > -def __str__(self):
> > +def __bytes__(self):
> >  fmt = '>H%us H%us' % (len(self.user_auth), len(self.data))
> >  return struct.pack(fmt, len(self.user_auth), self.user_auth,
> > len(self.data), self.data)
> > @@ -296,8 +296,9 @@ class Public(object):
> >  return '>HHIH%us%usH%us' % \
> >  (len(self.auth_policy), len(self.parameters), len(self.unique))
> >  
> > -def __init__(self, object_type, name_alg, object_attributes, 
> > auth_policy='',
> > - parameters='', unique=''):
> > +def __init__(self, object_type, name_alg, object_attributes,
> > + auth_policy=''.encode(), parameters=''.encode(),
> > + unique=''.encode()):
> 
> Ditto.
> 
> >  self.object_type = object_type
> >  self.name_alg = name_alg
> >  self.object_attributes = object_attributes
> > @@ -305,7 +306,7 @@ class Public(object):
> >  self.parameters = parameters
> >  self.unique = unique
> >  
> > -def __str__(self):
> > +def __bytes__(self):
> >  return struct.pack(self.__fmt(),
> > self.object_type,
> > self.name_alg,
> > @@ -343,7 +344,7 @@ def get_algorithm(name):
> >  
> >  def hex_dump(d):
> >  d = [format(ord(x), '02x') for x in d]
> > -d = [d[i: i + 16] for i in xrange(0, len(d), 16)]
> > +d = [d[i: i + 16] for i in range(0, len(d), 16)]
> >  d = [' '.join(x) for x in d]
> >  d = os.linesep.join(d)
> >  
> > @@ -401,7 +402,7 @@ class Client:
> >  pcrsel_len = max((i >> 3) + 1, 3)
> >  pcrsel = [0] * pcrsel_len
> >  pcrsel[i >> 3] = 1 << (i & 7)
> > -

linux-next: manual merge of the rcu tree with the tip tree

Hi all,

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

  include/linux/compiler.h

between commit:

  1d8fcbb76bb1 ("compiler.h: Move instrumentation_begin()/end() into new 
 header")

from the tip tree and commit:

  3b9946ebaf2b ("rcu: Fixup noinstr warnings")

from the rcu tree.

I fixed it up (I used the tip version and added the following patch) 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.

From: Stephen Rothwell 
Date: Fri, 26 Jun 2020 13:02:03 +1000
Subject: [PATCH] merge fix for "rcu: Fixup noinstr warnings"

Signed-off-by: Stephen Rothwell 
---
 include/linux/instrumentation.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/instrumentation.h b/include/linux/instrumentation.h
index 19cba99342c2..83d9a3c5204f 100644
--- a/include/linux/instrumentation.h
+++ b/include/linux/instrumentation.h
@@ -6,7 +6,7 @@
 
 /* Begin/end of an instrumentation safe region */
 #define instrumentation_begin() ({ \
-   asm volatile("%c0:\n\t" \
+   asm volatile("%c0: nop\n\t" \
 ".pushsection .discard.instr_begin\n\t"\
 ".long %c0b - .\n\t"   \
 ".popsection\n\t" : : "i" (__COUNTER__));  \
-- 
2.27.0

-- 
Cheers,
Stephen Rothwell


pgpHCi_2Ff6sg.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 0/2] zone-append support in io-uring and aio

2020-06-25 Thread Damien Le Moal

On 2020/06/26 2:18, Kanchan Joshi wrote:
> [Revised as per feedback from Damien, Pavel, Jens, Christoph, Matias, Wilcox]
> 
> This patchset enables zone-append using io-uring/linux-aio, on block IO path.
> Purpose is to provide zone-append consumption ability to applications which 
> are
> using zoned-block-device directly.
> 
> The application may specify RWF_ZONE_APPEND flag with write when it wants to
> send zone-append. RWF_* flags work with a certain subset of APIs e.g. uring,
> aio, and pwritev2. An error is reported if zone-append is requested using
> pwritev2. It is not in the scope of this patchset to support pwritev2 or any
> other sync write API for reasons described later.
> 
> Zone-append completion result --->
> With zone-append, where write took place can only be known after completion.
> So apart from usual return value of write, additional mean is needed to obtain
> the actual written location.
> 
> In aio, this is returned to application using res2 field of io_event -
> 
> struct io_event {
> __u64   data;   /* the data field from the iocb */
> __u64   obj;/* what iocb this event came from */
> __s64   res;/* result code for this event */
> __s64   res2;   /* secondary result */
> };
> 
> In io-uring, cqe->flags is repurposed for zone-append result.
> 
> struct io_uring_cqe {
> __u64   user_data;  /* sqe->data submission passed back */
> __s32   res;/* result code for this event */
> __u32   flags;
> };
> 
> Since 32 bit flags is not sufficient, we choose to return zone-relative offset
> in sector/512b units. This can cover zone-size represented by chunk_sectors.
> Applications will have the trouble to combine this with zone start to know
> disk-relative offset. But if more bits are obtained by pulling from res field
> that too would compel application to interpret res field differently, and it
> seems more painstaking than the former option.
> To keep uniformity, even with aio, zone-relative offset is returned.

I am really not a fan of this, to say the least. The input is byte offset, the
output is 512B relative sector count... Arg... We really cannot do better than
that ?

At the very least, byte relative offset ? The main reason is that this is
_somewhat_ acceptable for raw block device accesses since the "sector"
abstraction has a clear meaning, but once we add iomap/zonefs async zone append
support, we really will want to have byte unit as the interface is regular
files, not block device file. We could argue that 512B sector unit is still
around even for files (e.g. block counts in file stat). Bu the different unit
for input and output of one operation is really ugly. This is not nice for the 
user.

> 
> Append using io_uring fixed-buffer --->
> This is flagged as not-supported at the moment. Reason being, for fixed-buffer
> io-uring sends iov_iter of bvec type. But current append-infra in block-layer
> does not support such iov_iter.
> 
> Block IO vs File IO --->
> For now, the user zone-append interface is supported only for 
> zoned-block-device.
> Regular files/block-devices are not supported. Regular file-system (e.g. F2FS)
> will not need this anyway, because zone peculiarities are abstracted within 
> FS.
> At this point, ZoneFS also likes to use append implicitly rather than 
> explicitly.
> But if/when ZoneFS starts supporting explicit/on-demand zone-append, the check
> allowing-only-block-device should be changed.

Sure, but I think the interface is still a problem. I am not super happy about
the 512B sector unit. Zonefs will be the only file system that will be impacted
since other normal POSIX file system will not have zone append interface for
users. So this is a limited problem. Still, even for raw block device files
accesses, POSIX system calls use Byte unit everywhere. Let's try to use that.

For aio, it is easy since res2 is unsigned long long. For io_uring, as discussed
already, we can still 8 bits from the cqe res. All  you need is to add a small
helper function in userspace iouring.h to simplify the work of the application
to get that result.

> 
> Semantics --->
> Zone-append, by its nature, may perform write on a different location than 
> what
> was specified. It does not fit into POSIX, and trying to fit may just 
> undermine
> its benefit. It may be better to keep semantics as close to zone-append as
> possible i.e. specify zone-start location, and obtain the actual-write 
> location
> post completion. Towards that goal, existing async APIs seem to fit fine.
> Async APIs (uring, linux aio) do not work on implicit write-pointer and demand
> explicit write offset (which is what we need for append). Neither 
> write-pointer

What do you mean by "implicit write pointer" ? Are you referring to the behavior
of AIO write with a block device file open with O_APPEND ? The yes, it does not
work. But that is perfectly fine

Re: [RFC PATCH 10/11] efi: Rename arm-init to efi-init common for all arch

2020-06-25 Thread Heinrich Schuchardt

On 6/26/20 1:45 AM, Atish Patra wrote:
> arm-init is responsible for setting up efi runtime and doesn't actually
> do any ARM specific stuff. RISC-V can use the same source code as it is.
>
> Rename it to efi-init so that RISC-V can use it.
>
> Signed-off-by: Atish Patra 
> ---
>  drivers/firmware/efi/{arm-init.c => efi-init.c} | 0
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  rename drivers/firmware/efi/{arm-init.c => efi-init.c} (100%)
>
> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/efi-init.c
> similarity index 100%
> rename from drivers/firmware/efi/arm-init.c
> rename to drivers/firmware/efi/efi-init.c
>

After each patch we should have code that builds. This helps when
bisecting. Therefore I would have expected an adjustment of
drivers/firmware/efi/Makefile in this patch and not in patch 11/11:

-arm-obj-$(CONFIG_EFI)  := arm-init.o arm-runtime.o
+arm-obj-$(CONFIG_EFI)  := efi-init.o arm-runtime.o

Best regards

Heinrich

Re: linux-next: umh: fix processed error when UMH_WAIT_PROC is used seems to break linux bridge on s390x (bisected)

2020-06-25 Thread Luis Chamberlain

On Wed, Jun 24, 2020 at 08:37:55PM +0200, Christian Borntraeger wrote:
> 
> 
> On 24.06.20 20:32, Christian Borntraeger wrote:
> [...]> 
> > So the translations look correct. But your change is actually a sematic 
> > change
> > if(ret) will only trigger if there is an error
> > if (KWIFEXITED(ret)) will always trigger when the process ends. So we will 
> > always overwrite -ECHILD
> > and we did not do it before. 
> > 
> 
> So the right fix is
> 
> diff --git a/kernel/umh.c b/kernel/umh.c
> index f81e8698e36e..a3a3196e84d1 100644
> --- a/kernel/umh.c
> +++ b/kernel/umh.c
> @@ -154,7 +154,7 @@ static void call_usermodehelper_exec_sync(struct 
> subprocess_info *sub_info)
>  * the real error code is already in sub_info->retval or
>  * sub_info->retval is 0 anyway, so don't mess with it then.
>  */
> -   if (KWIFEXITED(ret))
> +   if (KWEXITSTATUS(ret))
> sub_info->retval = KWEXITSTATUS(ret);
> }
>  
> I think.

Nope, the right form is to check for WIFEXITED() before using WEXITSTATUS().
I'm not able to reproduce this on x86 with a bridge. What type of bridge
are you using on a guest, or did you mean using KVM so that the *host*
can spawn kvm guests?

It would be good if you can try to add a bridge manually and see where
things fail. Can you do something like this:

brctl addbr br0
brctl addif br0 ens6 
ip link set dev br0 up

Note that most callers are for modprobe. I'd be curious to see which
umh is failing which breaks bridge for you. Can you trut this so we can
see which umh call is failing?

diff --git a/kernel/umh.c b/kernel/umh.c
index f81e8698e36e..5ad74bc301d8 100644
--- a/kernel/umh.c
+++ b/kernel/umh.c
@@ -2,6 +2,9 @@
 /*
  * umh - the kernel usermode helper
  */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -154,8 +157,12 @@ static void call_usermodehelper_exec_sync(struct 
subprocess_info *sub_info)
 * the real error code is already in sub_info->retval or
 * sub_info->retval is 0 anyway, so don't mess with it then.
 */
-   if (KWIFEXITED(ret))
+   printk("== ret: %02x\n", ret);
+   printk("== KWIFEXITED(ret): %02x\n", KWIFEXITED(ret));
+   if (KWIFEXITED(ret)) {
+   printk("KWEXITSTATUS(ret): %d\n", KWEXITSTATUS(ret));
sub_info->retval = KWEXITSTATUS(ret);
+   }
}
 
/* Restore default kernel sig handler */
@@ -383,6 +390,7 @@ struct subprocess_info *call_usermodehelper_setup(const 
char *path, char **argv,
void *data)
 {
struct subprocess_info *sub_info;
+   unsigned int i = 0;
sub_info = kzalloc(sizeof(struct subprocess_info), gfp_mask);
if (!sub_info)
goto out;
@@ -394,6 +402,11 @@ struct subprocess_info *call_usermodehelper_setup(const 
char *path, char **argv,
 #else
sub_info->path = path;
 #endif
+   pr_info("sub_info->path: %s\n", sub_info->path);
+   while (argv[i])
+   printk(KERN_INFO "%s ", argv[i++]);
+   printk(KERN_INFO  "\n");
+
sub_info->argv = argv;
sub_info->envp = envp;

Re: [PATCH v2 2/2] cpufreq: Specify default governor on command line

On 23-06-20, 15:21, Quentin Perret wrote:
> @@ -2789,7 +2796,13 @@ static int __init cpufreq_core_init(void)
>   cpufreq_global_kobject = kobject_create_and_add("cpufreq", 
> _subsys.dev_root->kobj);
>   BUG_ON(!cpufreq_global_kobject);
>  
> + mutex_lock(_governor_mutex);
> + if (!default_governor)

Also is this check really required ? The pointer will always be NULL
at this point, isn't it ?

> + default_governor = cpufreq_default_governor();
> + mutex_unlock(_governor_mutex);
> +
>   return 0;
>  }
>  module_param(off, int, 0444);
> +module_param_string(default_governor, cpufreq_param_governor, 
> CPUFREQ_NAME_LEN, 0444);
>  core_initcall(cpufreq_core_init);
> -- 
> 2.27.0.111.gc72c7da667-goog

-- 
viresh

[PATCH v2] ring-buffer: Have nested events still record running time stamp

2020-06-25 Thread Steven Rostedt

From: "Steven Rostedt (VMware)" 

Up until now, if an event is interrupted while it is recorded by an
interrupt, and that interrupt records events, the time of those events will
all be the same. This is because events only record the delta of the time
since the previous event (or beginning of a page), and to handle updating
the time keeping for that of nested events is extremely racy. After years of
thinking about this and several failed attempts, I finally have a solution
to solve this puzzle.

The problem is that you need to atomically calculate the delta and then
update the time stamp you made the delta from, as well as then record it
into the buffer, all this while at any time an interrupt can come in and
do the same thing. This is easy to solve with heavy weight atomics, but that
would be detrimental to the performance of the ring buffer. The current
state of affairs sacrificed the time deltas for nested events for
performance.

The reason for previous failed attempts at solving this puzzle was because I
was trying to completely avoid slow atomic operations like cmpxchg. I final
came to the conclusion to always avoid cmpxchg is not possible, which is why
those previous attempts always failed. But it is possible to pick one path
(the most common case) and avoid cmpxchg in that path, which is the "fast
path". The most common case is that an event will not be interrupted and
have other events added into it. An event can detect if it has
interrupted another event, and for these cases we can make it the slow
path and use the heavy operations like cmpxchg.

One more player was added to the game that made this possible, and that is
the "absolute timestamp" (by Tom Zanussi) that allows us to inject a full 59
bit time stamp. (Of course this breaks if a machine is running for more than
18 years without a reboot!).

There's barrier() placements around for being paranoid, even when they
are not needed because of other atomic functions near by. But those
should not hurt, as if they are not needed, they basically become a nop.

Note, this also makes the race window much smaller, which means there
are less slow paths to slow down the performance.

Here's the design of this solution:

 All this is per cpu, and only needs to worry about nested events (not
 parallel events).

The players:

 write_tail: The index in the buffer where new events can be written to.
 It is incremented via local_add() to reserve space for a new event.

 before_stamp: A time stamp set by all events before reserving space.

 write_stamp: A time stamp updated by events after it has successfully
 reserved space.

 next_write: A copy of "write_tail" used to help with races.

/* Save the current position of write */
 [A]w = local_read(write_tail);
barrier();
/* Read both before and write stamps before touching anything */
before = READ_ONCE(before_stamp);
after = local_read(write_stamp);
barrier();

/*
 * If before and after are the same, then this event is not
 * interrupting a time update. If it is, then reserve space for adding
 * a full time stamp (this can turn into a time extend which is
 * just an extended time delta but fill up the extra space).
 */
if (after != before)
abs = true;

ts = clock();

/* Now update the before_stamp (everyone does this!) */
 [B]WRITE_ONCE(before_stamp, ts);

/* Read the current next_write and update it to what we want write
 * to be after we reserve space. */
next = READ_ONCE(next_write);
WRITE_ONCE(next_write, w + len);

/* Now reserve space on the buffer */
 [C]write = local_add_return(len, write_tail);

/* Set tail to be were this event's data is */
tail = write - len;

if (w == tail) {

/* Nothing interrupted this between A and C */
 [D]local_set(write_stamp, ts);
barrier();
 [E]save_before = READ_ONCE(before_stamp);

if (!abs) {
/* This did not interrupt a time update */
delta = ts - after;
} else {
delta = ts; /* The full time stamp will be in use */
}
if (ts != save_before) {
/* slow path - Was interrupted between C and E */
/* The update to write_stamp could have overwritten the 
update to
 * it by the interrupting event, but before and after 
should be
 * the same for all completed top events */
after = local_read(write_stamp);
if (save_before > after)
local_cmpxchg(write_stamp, after, save_before);
}
} else {
/* slow path - Interrupted between A and C */

after =

Re: [PATCH] fixing ERROR: Macros with complex values must be enclosed within parentheses.

2020-06-25 Thread Laurent Pinchart

Hi Karthik,

Thank you for the patch.

On Thu, Jun 25, 2020 at 10:17:23PM -0400, B K Karthik wrote:
> soc_camera.c:
> 
> fixing ERROR: Macros with complex values must be enclused within parentheses.
> 
> Signed-off-by: B K Karthik 
> ---
>  drivers/staging/media/soc_camera/soc_camera.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/soc_camera/soc_camera.c 
> b/drivers/staging/media/soc_camera/soc_camera.c
> index 39f513f69b89..f609ecf6691c 100644
> --- a/drivers/staging/media/soc_camera/soc_camera.c
> +++ b/drivers/staging/media/soc_camera/soc_camera.c
> @@ -238,8 +238,7 @@ unsigned long soc_camera_apply_board_flags(struct 
> soc_camera_subdev_desc *ssdd,
>  }
>  EXPORT_SYMBOL(soc_camera_apply_board_flags);
>  
> -#define pixfmtstr(x) (x) & 0xff, ((x) >> 8) & 0xff, ((x) >> 16) & 0xff, \
> - ((x) >> 24) & 0xff
> +#define pixfmtstr(x) ((x) & 0xff, ((x) >> 8) & 0xff, ((x) >> 16) & 0xff, 
> ((x) >> 24) & 0xff)

This won't work. Try to compile this driver with CONFIG_DYNAMIC_DEBUG
and the compiler will tell you why.

Regardless, drivers/staging/media/soc_camera/soc_camera.c is in staging
because it will be removed from the kernel, cleanups for this file won't
be accepted.

>  static int soc_camera_try_fmt(struct soc_camera_device *icd,
> struct v4l2_format *f)

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 1/2] fs,block: Introduce RWF_ZONE_APPEND and handling in direct IO path

2020-06-25 Thread Damien Le Moal

On 2020/06/26 2:18, Kanchan Joshi wrote:
> Introduce RWF_ZONE_APPEND flag to represent zone-append. User-space
> sends this with write. Add IOCB_ZONE_APPEND which is set in
> kiocb->ki_flags on receiving RWF_ZONE_APPEND.
> Make direct IO submission path use IOCB_ZONE_APPEND to send bio with
> append op. Direct IO completion returns zone-relative offset, in sector
> unit, to upper layer using kiocb->ki_complete interface.
> Report error if zone-append is requested on regular file or on sync
> kiocb (i.e. one without ki_complete).
> 
> Signed-off-by: Kanchan Joshi 
> Signed-off-by: SelvaKumar S 
> Signed-off-by: Arnav Dawn 
> Signed-off-by: Nitesh Shetty 
> Signed-off-by: Javier Gonzalez 
> ---
>  fs/block_dev.c  | 28 
>  include/linux/fs.h  |  9 +
>  include/uapi/linux/fs.h |  5 -
>  3 files changed, 37 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/block_dev.c b/fs/block_dev.c
> index 47860e5..5180268 100644
> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@ -185,6 +185,10 @@ static unsigned int dio_bio_write_op(struct kiocb *iocb)
>   /* avoid the need for a I/O completion work item */
>   if (iocb->ki_flags & IOCB_DSYNC)
>   op |= REQ_FUA;
> +
> + if (iocb->ki_flags & IOCB_ZONE_APPEND)
> + op |= REQ_OP_ZONE_APPEND;

This is wrong. REQ_OP_WRITE is already set in the declaration of "op". How can
this work ?

> +
>   return op;
>  }
>  
> @@ -295,6 +299,14 @@ static int blkdev_iopoll(struct kiocb *kiocb, bool wait)
>   return blk_poll(q, READ_ONCE(kiocb->ki_cookie), wait);
>  }
>  
> +static inline long blkdev_bio_end_io_append(struct bio *bio)
> +{
> + sector_t zone_sectors = blk_queue_zone_sectors(bio->bi_disk->queue);
> +
> + /* calculate zone relative offset for zone append */

The name of the function may be better spelling out zone_append instead of just
append. But see next comment.

> + return bio->bi_iter.bi_sector & (zone_sectors - 1);
> +}
> +
>  static void blkdev_bio_end_io(struct bio *bio)
>  {
>   struct blkdev_dio *dio = bio->bi_private;
> @@ -307,15 +319,19 @@ static void blkdev_bio_end_io(struct bio *bio)
>   if (!dio->is_sync) {
>   struct kiocb *iocb = dio->iocb;
>   ssize_t ret;
> + long res2 = 0;
>  
>   if (likely(!dio->bio.bi_status)) {
>   ret = dio->size;
>   iocb->ki_pos += ret;
> +

Blank line not needed.

> + if (iocb->ki_flags & IOCB_ZONE_APPEND)> +   
> res2 = blkdev_bio_end_io_append(bio);

The name blkdev_bio_end_io_append() implies a bio end_io callback function,
which is not the case. What about naming this blkdev_bio_res2() and move the if
inside it ?

>   } else {
>   ret = blk_status_to_errno(dio->bio.bi_status);

add "res2 = 0;" here and drop the declaration initialization. That will avoid
doing the assignment twice for zone append case.

>   }
>  
> - dio->iocb->ki_complete(iocb, ret, 0);
> + dio->iocb->ki_complete(iocb, ret, res2);
>   if (dio->multi_bio)
>   bio_put(>bio);
>   } else {
> @@ -382,6 +398,7 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter 
> *iter, int nr_pages)
>   bio->bi_private = dio;
>   bio->bi_end_io = blkdev_bio_end_io;
>   bio->bi_ioprio = iocb->ki_ioprio;
> + bio->bi_opf = is_read ? REQ_OP_READ : dio_bio_write_op(iocb);

Personally, I would prefer a plain "if () else". Or even better: change
dio_bio_write_op() into dio_bio_op() and just have:

bio->bi_opf = dio_bio_op(iocb);

>  
>   ret = bio_iov_iter_get_pages(bio, iter);
>   if (unlikely(ret)) {
> @@ -391,11 +408,9 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter 
> *iter, int nr_pages)
>   }
>  
>   if (is_read) {
> - bio->bi_opf = REQ_OP_READ;
>   if (dio->should_dirty)
>   bio_set_pages_dirty(bio);
>   } else {
> - bio->bi_opf = dio_bio_write_op(iocb);
>   task_io_account_write(bio->bi_iter.bi_size);
>   }
>  
> @@ -465,12 +480,17 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter 
> *iter, int nr_pages)
>  static ssize_t
>  blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
>  {
> + bool is_sync = is_sync_kiocb(iocb);
>   int nr_pages;
>  
> + /* zone-append is supported only on async-kiocb */
> + if (is_sync && iocb->ki_flags & IOCB_ZONE_APPEND)
> + return -EINVAL;
> +
>   nr_pages = iov_iter_npages(iter, BIO_MAX_PAGES + 1);
>   if (!nr_pages)
>   return 0;
> - if

Re: [RFC PATCH 01/11] efi: Fix gcc error around __umoddi3 for 32 bit builds

2020-06-25 Thread Heinrich Schuchardt

On 6/26/20 1:45 AM, Atish Patra wrote:
> 32bit gcc doesn't support modulo operation on 64 bit data. It results in
> a __umoddi3 error while building EFI for 32 bit.
>
> Use bitwise operations instead of modulo operations to fix the issue.
>
> Signed-off-by: Atish Patra 
> ---
>  drivers/firmware/efi/libstub/alignedmem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/libstub/alignedmem.c 
> b/drivers/firmware/efi/libstub/alignedmem.c
> index cc89c4d6196f..1de9878ddd3a 100644
> --- a/drivers/firmware/efi/libstub/alignedmem.c
> +++ b/drivers/firmware/efi/libstub/alignedmem.c
> @@ -44,7 +44,7 @@ efi_status_t efi_allocate_pages_aligned(unsigned long size, 
> unsigned long *addr,
>   *addr = ALIGN((unsigned long)alloc_addr, align);
>
>   if (slack > 0) {
> - int l = (alloc_addr % align) / EFI_PAGE_SIZE;
> + int l = (alloc_addr & (align - 1)) / EFI_PAGE_SIZE;

Here you rely on the compiler to silently convert the division by
EFI_PAGE_SIZE into a right shift. Wouldn't it be cleaner to use
EFI_PAGE_SHIFT to explicitly avoid a dependency on __udivdi3()?

slack = (align >> EFI_PAGE_SHIFT) - 1;
...
int l = (alloc_addr & (align - 1)) >> EFI_PAGE_SHIFT;

Best regards

Heinrich

>
>   if (l) {
>   efi_bs_call(free_pages, alloc_addr, slack - l + 1);
>

Re: [RFC][PATCH] ring-buffer: Have nested events still record running time stamp

2020-06-25 Thread Steven Rostedt

On Thu, 25 Jun 2020 15:35:02 -0400 (EDT)
Mathieu Desnoyers  wrote:

> Those performance and reentrancy concerns are why I always stick to local_t
> (long), and never use a full 64-bit type for anything that has to
> do with concurrent store/load between execution contexts in lttng.

Although the adding of this patch slows the recording down by around 7
nanoseconds (average 55ns brought to 62ns), but I can wrap it so that
it stays local64_t for 64 bit and use this for 32 bit.

I added three primitives:

 bool rb_time_read(rb_time_t *t, u64 *val)

It loads val with t if t wasn't being updated at the time. If it is, it
returns false and val is not touched, otherwise it returns true and val
has a real value (either before, or updated by an interrupt).

 void rb_time_set(rb_time_t *t, u64 val)

This will update t with val, and wont return until it has done so. It
will overwrite any update that interrupted the process.

 bool rb_time_cmpxchg(rb_time_t *t, u64 expect, u64 set);

This will attempt to do a cmpxchg on t, if it matches "expect" it will
write "set". If it gets interrupted, then it will detect that, and return
false. Otherwise it will return true if it fully changed the value.


This is all I need, and is rather trivial to implement. The trick is
the order of rb_time_t is always written from:

  start_cnt
  top
  bottom
  end_cnt

This means that end_cnt will never be greater than start_cnt. If we see
that it is, it means that the process was interrupted with another
update. That process that interrupted a write, would complete its write.

I don't plan on applying this, but if it turns out that local64_t is a
problem on 32 bit archs (and I hear complaints), I add this (and but
still use local64_t on 64 bit archs).

-- Steve

Index: linux-trace.git/kernel/trace/ring_buffer.c
===
--- linux-trace.git.orig/kernel/trace/ring_buffer.c
+++ linux-trace.git/kernel/trace/ring_buffer.c
@@ -446,6 +446,22 @@ enum {
RB_CTX_MAX
 };
 
+struct rb_time_struct {
+   local_t start_cnt;
+   local_t top;
+   local_t bottom;
+   local_t end_cnt;
+};
+
+struct rb_time_read {
+   unsigned long   start_cnt;
+   unsigned long   top;
+   unsigned long   bottom;
+   unsigned long   end_cnt;
+};
+
+typedef struct rb_time_struct rb_time_t;
+
 /*
  * head_page == tail_page && head == tail then buffer is empty.
  */
@@ -482,8 +498,8 @@ struct ring_buffer_per_cpu {
unsigned long   read;
unsigned long   read_bytes;
unsigned long   next_write;
-   local64_t   write_stamp;
-   local64_t   before_stamp;
+   rb_time_t   write_stamp;
+   rb_time_t   before_stamp;
u64 read_stamp;
/* ring buffer pages to update, > 0 to add, < 0 to remove */
longnr_pages_to_update;
@@ -526,6 +542,78 @@ struct ring_buffer_iter {
int missed_events;
 };
 
+static bool rb_time_read(rb_time_t *t, u64 *ret)
+{
+   struct rb_time_read r;
+   u64 val;
+
+   do {
+   r.start_cnt = local_read(>start_cnt);
+   r.top = local_read(>top);
+   r.bottom = local_read(>bottom);
+   r.end_cnt = local_read(>end_cnt);
+   } while (r.start_cnt < r.end_cnt);
+
+   if (r.start_cnt != r.end_cnt)
+   return false;
+
+   val = r.top;
+   val <<= 32;
+   val |= r.bottom;
+   *ret = val;
+   return true;
+}
+
+static inline void rb_time_read_set(struct rb_time_read *r, u64 val)
+{
+   r->top = (unsigned long)(val >> 32);
+   r->bottom = (unsigned long)(val & ((1ULL << 32) - 1));
+}
+
+static void rb_time_set(rb_time_t *t, u64 val)
+{
+   struct rb_time_read r;
+
+   rb_time_read_set(, val);
+
+   do {
+   r.start_cnt = local_inc_return(>start_cnt);
+   local_set(>top, r.top);
+   local_set(>bottom, r.bottom);
+   local_set(>end_cnt, r.start_cnt);
+   } while (r.start_cnt != local_read(>start_cnt));
+}
+
+static bool rb_time_read_cmpxchg(local_t *l, unsigned long expect, unsigned 
long set)
+{
+   unsigned long ret;
+
+   ret = local_cmpxchg(l, expect, set);
+   return ret == expect;
+}
+
+static bool rb_time_cmpxchg(rb_time_t *t, u64 expect, u64 set)
+{
+   struct rb_time_read e, s;
+
+   rb_time_read_set(, expect);
+   rb_time_read_set(, set);
+
+   e.start_cnt = local_read(>start_cnt);
+   e.end_cnt = local_read(>end_cnt);
+
+   s.start_cnt = e.start_cnt + 1;
+   s.end_cnt = e.start_cnt;
+
+   if (!rb_time_read_cmpxchg(>start_cnt, e.start_cnt, s.start_cnt))
+   return false;
+   if (!rb_time_read_cmpxchg(>top, e.top, s.top))
+   return

Re: [PATCH] ima: AppArmor satisfies the audit rule requirements

2020-06-25 Thread Mimi Zohar

On Tue, 2020-06-23 at 18:38 -0500, Tyler Hicks wrote:
> AppArmor meets all the requirements for IMA in terms of audit rules
> since commit e79c26d04043 ("apparmor: Add support for audit rule
> filtering"). Update IMA's Kconfig section for CONFIG_IMA_LSM_RULES to
> reflect this.
> 
> Fixes: e79c26d04043 ("apparmor: Add support for audit rule filtering")
> Signed-off-by: Tyler Hicks 

Thanks

Mimi

Re: [PATCH] cpufreq: schedutil: force frequency update when limits change

On 26-06-20, 07:44, Viresh Kumar wrote:
> On 25-06-20, 13:47, Wei Wang wrote:
> > On Thu, Jun 25, 2020 at 3:23 AM Viresh Kumar  
> > wrote:
> > > I am sorry but I am not fully sure of what the problem is. Can you
> > > describe that by giving an example with some random frequency, and
> > > tell the expected and actual behavior ?
> > >
> > The problem is sugov thought next_freq already updated (but actually
> > skipped by the rate limit thing) and all following updates will be
> > skipped.

The rate-limiting thing is specific to android and not present in
mainline. Even in android I see next_freq getting updated only after
rate-limiting is verified.

I think you maybe trying to fix an android only problem in mainline,
which may not be required at all. And I am not sure if Android has a
problem as well :)

> I am sorry, can you please give a detailed example with existing
> frequency and limits, then the limits changed to new values, then what
> exactly happens ?
> 
> > Actually this is specifically for Android common kernel 4.19's issue
> > which has sugov_up_down_rate_limit in sugov_update_next_freq, let's
> > continue discussion there.
> 
> If it is a mainline problem, we will surely get it fixed here. Just
> that I am not able to understand the problem yet. Sorry about that.

-- 
viresh

[PATCH] fixing ERROR: Macros with complex values must be enclosed within parentheses.

2020-06-25 Thread B K Karthik

soc_camera.c:

fixing ERROR: Macros with complex values must be enclused within parentheses.

Signed-off-by: B K Karthik 
---
 drivers/staging/media/soc_camera/soc_camera.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/media/soc_camera/soc_camera.c 
b/drivers/staging/media/soc_camera/soc_camera.c
index 39f513f69b89..f609ecf6691c 100644
--- a/drivers/staging/media/soc_camera/soc_camera.c
+++ b/drivers/staging/media/soc_camera/soc_camera.c
@@ -238,8 +238,7 @@ unsigned long soc_camera_apply_board_flags(struct 
soc_camera_subdev_desc *ssdd,
 }
 EXPORT_SYMBOL(soc_camera_apply_board_flags);
 
-#define pixfmtstr(x) (x) & 0xff, ((x) >> 8) & 0xff, ((x) >> 16) & 0xff, \
-   ((x) >> 24) & 0xff
+#define pixfmtstr(x) ((x) & 0xff, ((x) >> 8) & 0xff, ((x) >> 16) & 0xff, ((x) 
>> 24) & 0xff)
 
 static int soc_camera_try_fmt(struct soc_camera_device *icd,
  struct v4l2_format *f)
-- 
2.20.1



signature.asc
Description: PGP signature

Re: [PATCH] cpufreq: schedutil: force frequency update when limits change

On 25-06-20, 13:47, Wei Wang wrote:
> On Thu, Jun 25, 2020 at 3:23 AM Viresh Kumar  wrote:
> > I am sorry but I am not fully sure of what the problem is. Can you
> > describe that by giving an example with some random frequency, and
> > tell the expected and actual behavior ?
> >
> The problem is sugov thought next_freq already updated (but actually
> skipped by the rate limit thing) and all following updates will be
> skipped.

I am sorry, can you please give a detailed example with existing
frequency and limits, then the limits changed to new values, then what
exactly happens ?

> Actually this is specifically for Android common kernel 4.19's issue
> which has sugov_up_down_rate_limit in sugov_update_next_freq, let's
> continue discussion there.

If it is a mainline problem, we will surely get it fixed here. Just
that I am not able to understand the problem yet. Sorry about that.

-- 
viresh

Re: [PATCH] Ability to read the MKTME status from userspace (patch v2)

2020-06-25 Thread Alison Schofield

On Thu, Jun 25, 2020 at 06:10:29PM -0300, Daniel Gutson wrote:
> The intent of this patch is to provide visibility of the
> MKTME status to userspace. This is an important factor for
> firmware security related applilcations.
> 
> Changes since v1:
> * Documentation/ABI/stable/securityfs-mktme-status (new file)
> * include/uapi/misc/mktme_status.h (new file)
> * Fixed MAINTAINER title.
> * cpu.h: added values to the enumerands
> * Renamed the function from get_mktme_status to mktme_get_status
> * Improved Kconfig help
> * Removed unnecessary license-related lines since there is a SPDX line
> * Moved pr_fmt macro before the includes
> * Turned global variables (mktme_dir, mktme_file) as static
> * Removed BUFFER_SIZE macro
> * No longer returning -1 for error, but using the previously error.
> * No more pr_info for the normal behavior.
> * Renamed this from a kernel driver to a kernel module.
> 
> Signed-off-by: Daniel Gutson 
> ---
>  .../ABI/stable/securityfs-mktme-status| 12 
>  MAINTAINERS   |  5 ++
>  arch/x86/include/asm/cpu.h|  8 +++
>  arch/x86/kernel/cpu/intel.c   | 12 ++--
>  drivers/misc/Kconfig  | 15 +
>  drivers/misc/Makefile |  1 +
>  drivers/misc/mktme_status.c   | 67 +++
>  include/uapi/misc/mktme_status.h  | 12 
>  8 files changed, 127 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/ABI/stable/securityfs-mktme-status
>  create mode 100644 drivers/misc/mktme_status.c
>  create mode 100644 include/uapi/misc/mktme_status.h
> 
> diff --git a/Documentation/ABI/stable/securityfs-mktme-status 
> b/Documentation/ABI/stable/securityfs-mktme-status
> new file mode 100644
> index ..a791c6ef2c15
> --- /dev/null
> +++ b/Documentation/ABI/stable/securityfs-mktme-status
> @@ -0,0 +1,12 @@
> +What:/securityfs/mktme/status
> +Date:24-Jun-2020
> +KernelVersion:   v5.7
> +Contact: daniel.gut...@eclypsium.com
> +Description: The mktme securityfs interface exports the BIOS status
> + of the MKTME.
> +Values: For possible values see arch/x86/include/asm/cpu.h.
> +
> + Currently these values are:
> + 0 Enabled by BIOS
> + 1 Disabled by BIOS
> + 2 Uninitialized
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7b5ffd646c6b..e034e8ab6fe1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11477,6 +11477,11 @@ W:   https://linuxtv.org
>  T:   git git://linuxtv.org/media_tree.git
>  F:   drivers/media/radio/radio-miropcm20*
>  
> +MKTME STATUS READING SUPPORT
> +M:   Daniel Gutson 
> +S:   Supported
> +F:   drivers/misc/mktme_status.c
> +
>  MMP SUPPORT
>  R:   Lubomir Rintel 
>  L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
> diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
> index dd17c2da1af5..80d2896a3f43 100644
> --- a/arch/x86/include/asm/cpu.h
> +++ b/arch/x86/include/asm/cpu.h
> @@ -26,6 +26,14 @@ struct x86_cpu {
>   struct cpu cpu;
>  };
>  
> +enum mktme_status_type {
> + MKTME_ENABLED = 0,
> + MKTME_DISABLED = 1,
> + MKTME_UNINITIALIZED = 2
> +};
> +
> +extern enum mktme_status_type mktme_get_status(void);
> +
>  #ifdef CONFIG_HOTPLUG_CPU
>  extern int arch_register_cpu(int num);
>  extern void arch_unregister_cpu(int);
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index c25a67a34bd3..134a88685bc3 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -495,11 +495,7 @@ static void srat_detect_node(struct cpuinfo_x86 *c)
>  #define TME_ACTIVATE_CRYPTO_ALGS(x)  ((x >> 48) & 0x)/* Bits 63:48 */
>  #define TME_ACTIVATE_CRYPTO_AES_XTS_128  1
>  
> -/* Values for mktme_status (SW only construct) */
> -#define MKTME_ENABLED0
> -#define MKTME_DISABLED   1
> -#define MKTME_UNINITIALIZED  2
> -static int mktme_status = MKTME_UNINITIALIZED;
> +static enum mktme_status_type mktme_status = MKTME_UNINITIALIZED;
>  
>  static void detect_tme(struct cpuinfo_x86 *c)
>  {
> @@ -1114,6 +1110,12 @@ bool handle_user_split_lock(struct pt_regs *regs, long 
> error_code)
>   return true;
>  }
>  
> +enum mktme_status_type mktme_get_status(void)
> +{
> + return mktme_status;
> +}
> +EXPORT_SYMBOL_GPL(mktme_get_status);
> +

Hi Daniel,

It's not clear this code is getting what it says its getting.
(putting aside for the moment the other feedback)

I think you said you want to know if TME is activated in BIOS. I get that.
You don't want the system to be up and the customer can't tell if they
actually turned on TME or not.

If you only look for MKTME enabled status, you may miss the TME enabled
status. We can have TME on and MKTME off. (Can't have opposite)

Here are the boot message I observe based on BIOS selections:

Re: [PATCH 2/2] irqchip/gic-v3: Support pseudo-NMIs when SCR_EL3.FIQ == 0

Hi Alexandru,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on tip/irq/core v5.8-rc2 next-20200625]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Alexandru-Elisei/irqchip-gic-v3-Support-pseudo-NMIs-when-SCR_EL3-FIQ-0/20200625-230144
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
for-next/core
config: arm64-randconfig-r025-20200624 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
8911a35180c6777188fefe0954a2451a2b91deaf)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   In file included from arch/arm64/kernel/asm-offsets.c:10:
   In file included from include/linux/arm_sdei.h:8:
   In file included from include/acpi/ghes.h:5:
   In file included from include/acpi/apei.h:9:
   In file included from include/linux/acpi.h:13:
   In file included from include/linux/irqdomain.h:35:
   In file included from include/linux/of.h:17:
   In file included from include/linux/kobject.h:20:
   In file included from include/linux/sysfs.h:16:
   In file included from include/linux/kernfs.h:13:
   In file included from include/linux/idr.h:15:
   In file included from include/linux/radix-tree.h:15:
   In file included from include/linux/rcupdate.h:26:
   In file included from include/linux/irqflags.h:16:
>> arch/arm64/include/asm/irqflags.h:45:10: warning: value size does not match 
>> register size specified by the constraint and modifier [-Wasm-operand-widths]
   : "r" (pmr_irqon)
  ^
   arch/arm64/include/asm/irqflags.h:42:29: note: use constraint modifier "w"
   __msr_s(SYS_ICC_PMR_EL1, "%0"),
 ^
   arch/arm64/include/asm/irqflags.h:67:10: warning: value size does not match 
register size specified by the constraint and modifier [-Wasm-operand-widths]
   : "r" (pmr_irqoff)
  ^
   arch/arm64/include/asm/irqflags.h:64:29: note: use constraint modifier "w"
   __msr_s(SYS_ICC_PMR_EL1, "%0"),
 ^
   2 warnings generated.
--
   In file included from drivers/power/supply/ltc2941-battery-gauge.c:12:
   In file included from include/linux/module.h:13:
   In file included from include/linux/stat.h:6:
   In file included from arch/arm64/include/asm/stat.h:12:
   In file included from include/linux/time.h:6:
   In file included from include/linux/seqlock.h:36:
   In file included from include/linux/spinlock.h:54:
   In file included from include/linux/irqflags.h:16:
>> arch/arm64/include/asm/irqflags.h:45:10: warning: value size does not match 
>> register size specified by the constraint and modifier [-Wasm-operand-widths]
   : "r" (pmr_irqon)
  ^
   arch/arm64/include/asm/irqflags.h:42:29: note: use constraint modifier "w"
   __msr_s(SYS_ICC_PMR_EL1, "%0"),
 ^
   arch/arm64/include/asm/irqflags.h:67:10: warning: value size does not match 
register size specified by the constraint and modifier [-Wasm-operand-widths]
   : "r" (pmr_irqoff)
  ^
   arch/arm64/include/asm/irqflags.h:64:29: note: use constraint modifier "w"
   __msr_s(SYS_ICC_PMR_EL1, "%0"),
 ^
   drivers/power/supply/ltc2941-battery-gauge.c:476:13: warning: cast to 
smaller integer type 'enum ltc294x_id' from 'const void *' 
[-Wvoid-pointer-to-enum-cast]
   info->id = (enum ltc294x_id)of_device_get_match_data(>dev);
  ^~~
   3 warnings generated.
--
   In file included from drivers/power/supply/goldfish_battery.c:11:
   In file included from include/linux/module.h:13:
   In file included from include/linux/stat.h:6:
   In file included from arch/arm64/include/asm/stat.h:12:
   In file included from include/linux/time.h:6:
   In file included from include/linux/seqlock.h:36:
   In file included from inclu

Re: [RFC PATCH 00/13] Core scheduling v5

2020-06-25 Thread Joel Fernandes

On Thu, Jun 25, 2020 at 4:12 PM Vineeth Remanan Pillai
 wrote:
[...]
> TODO lists:
>
>  - Interface discussions could not come to a conclusion in v5 and hence would
>like to restart the discussion and reach a consensus on it.
>- 
> https://lwn.net/ml/linux-kernel/20200520222642.70679-1-j...@joelfernandes.org

Thanks Vineeth, just want to add: I have a revised implementation of
prctl(2) where you only pass a TID of a task you'd like to share a
core with (credit to Peter for the idea [1]) so we can make use of
ptrace_may_access() checks. I am currently finishing writing of
kselftests for this and post it all once it is ready.

However a question: If using the prctl(2) on a CGroup tagged task, we
discussed in previous threads [2] to override the CGroup cookie such
that the task may not share a core with any of the tasks in its CGroup
anymore and I think Peter and Phil are Ok with.  My question though is
- would that not be confusing for anyone looking at the CGroup
filesystem's "tag" and "tasks" files?

To resolve this, I am proposing to add a new CGroup file
'tasks.coresched' to the CGroup, and this will only contain tasks that
were assigned cookies due to their CGroup residency. As soon as one
prctl(2)'s the task, it will stop showing up in the CGroup's
"tasks.coresched" file (unless of course it was requesting to
prctl-share a core with someone in its CGroup itself). Are folks Ok
with this solution?

[1]  
https://lore.kernel.org/lkml/20200528170128.gn2...@worktop.programming.kicks-ass.net/
[2] 
https://lore.kernel.org/lkml/20200524140046.ga5...@lorien.usersys.redhat.com/

Re: [PATCH v4 12/12] x86/traps: Fix up invalid PASID


Hi Fenghua,

On 2020/6/26 4:17, Fenghua Yu wrote:

A #GP fault is generated when ENQCMD instruction is executed without
a valid PASID value programmed in the current thread's PASID MSR. The
#GP fault handler will initialize the MSR if a PASID has been allocated
for this process.

Decoding the user instruction is ugly and sets a bad architecture
precedent. It may not function if the faulting instruction is modified
after #GP.

Thomas suggested to provide a reason for the #GP caused by executing ENQCMD
without a valid PASID value programmed. #GP error codes are 16 bits and all
16 bits are taken. Refer to SDM Vol 3, Chapter 16.13 for details. The other
choice was to reflect the error code in an MSR. ENQCMD can also cause #GP
when loading from the source operand, so its not fully comprehending all
the reasons. Rather than special case the ENQCMD, in future Intel may
choose a different fault mechanism for such cases if recovery is needed on
#GP.

The following heuristic is used to avoid decoding the user instructions
to determine the precise reason for the #GP fault:
1) If the mm for the process has not been allocated a PASID, this #GP
cannot be fixed.
2) If the PASID MSR is already initialized, then the #GP was for some
other reason
3) Try initializing the PASID MSR and returning. If the #GP was from
an ENQCMD this will fix it. If not, the #GP fault will be repeated
and will hit case "2".


For changes in Intel VT-d driver,

Reviewed-by: Lu Baolu 

Best regards,
baolu



Suggested-by: Thomas Gleixner 
Signed-off-by: Fenghua Yu 
Reviewed-by: Tony Luck 
---
v4:
- Change PASID type to u32 (Christoph)

v3:
- Check and set current->has_valid_pasid in fixup() (PeterZ)
- Add fpu__pasid_write() to update the MSR (PeterZ)
- Add ioasid_find() sanity check in fixup()

v2:
- Update the first paragraph of the commit message (Thomas)
- Add reasons why don't decode the user instruction and don't use
   #GP error code (Thomas)
- Change get_task_mm() to current->mm (Thomas)
- Add comments on why IRQ is disabled during PASID fixup (Thomas)
- Add comment in fixup() that the function is called when #GP is from
   user (so mm is not NULL) (Dave Hansen)

  arch/x86/include/asm/iommu.h |  1 +
  arch/x86/kernel/traps.c  | 14 +++
  drivers/iommu/intel/svm.c| 78 
  3 files changed, 93 insertions(+)

diff --git a/arch/x86/include/asm/iommu.h b/arch/x86/include/asm/iommu.h
index ed41259fe7ac..e9365a5d6f7d 100644
--- a/arch/x86/include/asm/iommu.h
+++ b/arch/x86/include/asm/iommu.h
@@ -27,5 +27,6 @@ arch_rmrr_sanity_check(struct acpi_dmar_reserved_memory *rmrr)
  }
  
  void __free_pasid(struct mm_struct *mm);

+bool __fixup_pasid_exception(void);
  
  #endif /* _ASM_X86_IOMMU_H */

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index f9727b96961f..2352f3f1f7ed 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -59,6 +59,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #ifdef CONFIG_X86_64

  #include 
@@ -514,6 +515,16 @@ static enum kernel_gp_hint get_kernel_gp_address(struct 
pt_regs *regs,
return GP_CANONICAL;
  }
  
+static bool fixup_pasid_exception(void)

+{
+   if (!IS_ENABLED(CONFIG_INTEL_IOMMU_SVM))
+   return false;
+   if (!static_cpu_has(X86_FEATURE_ENQCMD))
+   return false;
+
+   return __fixup_pasid_exception();
+}
+
  #define GPFSTR "general protection fault"
  
  DEFINE_IDTENTRY_ERRORCODE(exc_general_protection)

@@ -526,6 +537,9 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection)
  
  	cond_local_irq_enable(regs);
  
+	if (user_mode(regs) && fixup_pasid_exception())

+   goto exit;
+
if (static_cpu_has(X86_FEATURE_UMIP)) {
if (user_mode(regs) && fixup_umip_exception(regs))
goto exit;
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 4c70b037..4a84c82a4f8c 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -1105,3 +1105,81 @@ void __free_pasid(struct mm_struct *mm)
 */
ioasid_free(pasid);
  }
+
+/*
+ * Write the current task's PASID MSR/state. This is called only when PASID
+ * is enabled.
+ */
+static void fpu__pasid_write(u32 pasid)
+{
+   u64 msr_val = pasid | MSR_IA32_PASID_VALID;
+
+   fpregs_lock();
+
+   /*
+* If the MSR is active and owned by the current task's FPU, it can
+* be directly written.
+*
+* Otherwise, write the fpstate.
+*/
+   if (!test_thread_flag(TIF_NEED_FPU_LOAD)) {
+   wrmsrl(MSR_IA32_PASID, msr_val);
+   } else {
+   struct ia32_pasid_state *ppasid_state;
+
+   ppasid_state = get_xsave_addr(>thread.fpu.state.xsave,
+ XFEATURE_PASID);
+   /*
+* ppasid_state shouldn't be NULL because XFEATURE_PASID
+* is enabled.
+*/
+

Re: linux-next: build failure after merge of the amdgpu tree

Hi all,

On Fri, 12 Jun 2020 10:25:52 +1000 Stephen Rothwell  
wrote:
>
> After merging the amdgpu tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c: In function 
> 'kfd_sdma_activity_worker':
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:118:2: error: implicit 
> declaration of function 'use_mm' [-Werror=implicit-function-declaration]
>   118 |  use_mm(mm);
>   |  ^~
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:145:2: error: implicit 
> declaration of function 'unuse_mm' [-Werror=implicit-function-declaration]
>   145 |  unuse_mm(mm);
>   |  ^~~~
> 
> Caused by commit
> 
>   32cb59f31362 ("drm/amdkfd: Track SDMA utilization per process")
> 
> interacting with commit
> 
>   f5678e7f2ac3 ("kernel: better document the use_mm/unuse_mm API contract")
> 
> from Linus' tree.
> 
> I have applied the following merge fix for today (that was previously
> part of the akpm tree).

The merge fix patch now looks like:

From: Stephen Rothwell 
Date: Thu, 28 May 2020 20:15:34 +1000
Subject: [PATCH] drm/amdkfd: fix up for {un}use_mm() rename

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/amd/amdkfd/kfd_process.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 013c2b018edc..40695d52e9a8 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -184,7 +184,7 @@ static void kfd_sdma_activity_worker(struct work_struct 
*work)
if (!mm)
goto cleanup;
 
-   use_mm(mm);
+   kthread_use_mm(mm);
 
list_for_each_entry(sdma_q, _q_list.list, list) {
val = 0;
@@ -198,7 +198,7 @@ static void kfd_sdma_activity_worker(struct work_struct 
*work)
}
}
 
-   unuse_mm(mm);
+   kthread_unuse_mm(mm);
mmput(mm);
 
/*

-- 
Cheers,
Stephen Rothwell


pgpBoBuhalELM.pgp
Description: OpenPGP digital signature

Re: [PATCH v4 01/12] iommu: Change type of pasid to u32


Hi Fenghua,

On 2020/6/26 4:17, Fenghua Yu wrote:

PASID is defined as a few different types in iommu including "int",
"u32", and "unsigned int". To be consistent and to match with uapi
definitions, define PASID and its variations (e.g. max PASID) as "u32".
"u32" is also shorter and a little more explicit than "unsigned int".


For changes in Intel VT-d driver,

Reviewed-by: Lu Baolu 

Best regards,
baolu



No PASID type change in uapi although it defines PASID as __u64 in
some places.

Suggested-by: Thomas Gleixner 
Signed-off-by: Fenghua Yu 
Reviewed-by: Tony Luck 
---
v4:
- Change PASID type from "unsigned int" to "u32" (Christoph)

v2:
- Create this new patch to define PASID as "unsigned int" consistently in
   iommu (Thomas)

  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|  4 +--
  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c|  2 +-
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c |  2 +-
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c |  2 +-
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c |  2 +-
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.h |  2 +-
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  |  4 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c   |  6 ++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.h   |  4 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c|  8 ++---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h|  8 ++---
  .../gpu/drm/amd/amdkfd/cik_event_interrupt.c  |  2 +-
  drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c   |  2 +-
  drivers/gpu/drm/amd/amdkfd/kfd_dbgmgr.h   |  2 +-
  .../drm/amd/amdkfd/kfd_device_queue_manager.c |  7 ++---
  drivers/gpu/drm/amd/amdkfd/kfd_events.c   |  8 ++---
  drivers/gpu/drm/amd/amdkfd/kfd_events.h   |  4 +--
  drivers/gpu/drm/amd/amdkfd/kfd_iommu.c|  6 ++--
  drivers/gpu/drm/amd/amdkfd/kfd_pasid.c|  2 +-
  drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 18 +--
  drivers/gpu/drm/amd/amdkfd/kfd_process.c  |  2 +-
  .../gpu/drm/amd/include/kgd_kfd_interface.h   |  2 +-
  drivers/iommu/amd/amd_iommu.h | 10 +++---
  drivers/iommu/amd/iommu.c | 31 ++-
  drivers/iommu/amd/iommu_v2.c  | 20 ++--
  drivers/iommu/intel/dmar.c|  7 +++--
  drivers/iommu/intel/intel-pasid.h | 24 +++---
  drivers/iommu/intel/iommu.c   |  4 +--
  drivers/iommu/intel/pasid.c   | 31 +--
  drivers/iommu/intel/svm.c | 12 +++
  drivers/iommu/iommu.c |  2 +-
  drivers/misc/uacce/uacce.c|  2 +-
  include/linux/amd-iommu.h |  8 ++---
  include/linux/intel-iommu.h   | 12 +++
  include/linux/intel-svm.h |  2 +-
  include/linux/iommu.h | 10 +++---
  include/linux/uacce.h |  2 +-
  38 files changed, 139 insertions(+), 139 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index ffe149aafc39..dfef5a7e0f5a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -207,11 +207,11 @@ uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct kgd_dev 
*dst, struct kgd_dev *s
})
  
  /* GPUVM API */

-int amdgpu_amdkfd_gpuvm_create_process_vm(struct kgd_dev *kgd, unsigned int 
pasid,
+int amdgpu_amdkfd_gpuvm_create_process_vm(struct kgd_dev *kgd, u32 pasid,
void **vm, void **process_info,
struct dma_fence **ef);
  int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,
-   struct file *filp, unsigned int pasid,
+   struct file *filp, u32 pasid,
void **vm, void **process_info,
struct dma_fence **ef);
  void amdgpu_amdkfd_gpuvm_destroy_cb(struct amdgpu_device *adev,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
index bf927f432506..ee531c3988d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
@@ -105,7 +105,7 @@ static void kgd_program_sh_mem_settings(struct kgd_dev 
*kgd, uint32_t vmid,
unlock_srbm(kgd);
  }
  
-static int kgd_set_pasid_vmid_mapping(struct kgd_dev *kgd, unsigned int pasid,

+static int kgd_set_pasid_vmid_mapping(struct kgd_dev *kgd, u32 pasid,
unsigned int vmid)
  {
struct amdgpu_device *adev = get_amdgpu_device(kgd);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
index 744366c7ee85..4d41317b9292 100644
---

Re: [PATCH v4 10/12] x86/mmu: Allocate/free PASID


Hi Fenghua,

On 2020/6/26 4:17, Fenghua Yu wrote:

A PASID is allocated for an "mm" the first time any thread attaches
to an SVM capable device. Later device attachments (whether to the same
device or another SVM device) will re-use the same PASID.

The PASID is freed when the process exits (so no need to keep
reference counts on how many SVM devices are sharing the PASID).


For changes in Intel VT-d driver,

Reviewed-by: Lu Baolu 

Best regards,
baolu



Signed-off-by: Fenghua Yu 
Reviewed-by: Tony Luck 
---
v4:
- Change PASID type to u32 (Christoph)

v3:
- Add sanity checks in alloc_pasid() and _free_pasid() (Baolu)
- Add a comment that the private PASID feature will be removed completely
   from IOMMU and don't track private PASID in mm (Thomas)

v2:
- Define a helper free_bind() to simplify error exit code in bind_mm()
   (Thomas)
- Fix a ret error code in bind_mm() (Thomas)
- Change pasid's type from "int" to "unsigned int" to have consistent
   pasid type in iommu (Thomas)
- Simplify alloc_pasid() a bit.

  arch/x86/include/asm/iommu.h   |   2 +
  arch/x86/include/asm/mmu_context.h |  14 
  drivers/iommu/intel/svm.c  | 128 ++---
  3 files changed, 132 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/iommu.h b/arch/x86/include/asm/iommu.h
index bf1ed2ddc74b..ed41259fe7ac 100644
--- a/arch/x86/include/asm/iommu.h
+++ b/arch/x86/include/asm/iommu.h
@@ -26,4 +26,6 @@ arch_rmrr_sanity_check(struct acpi_dmar_reserved_memory *rmrr)
return -EINVAL;
  }
  
+void __free_pasid(struct mm_struct *mm);

+
  #endif /* _ASM_X86_IOMMU_H */
diff --git a/arch/x86/include/asm/mmu_context.h 
b/arch/x86/include/asm/mmu_context.h
index 47562147e70b..f8c91ce8c451 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -13,6 +13,7 @@
  #include 
  #include 
  #include 
+#include 
  
  extern atomic64_t last_mm_ctx_id;
  
@@ -117,9 +118,22 @@ static inline int init_new_context(struct task_struct *tsk,

init_new_context_ldt(mm);
return 0;
  }
+
+static inline void free_pasid(struct mm_struct *mm)
+{
+   if (!IS_ENABLED(CONFIG_INTEL_IOMMU_SVM))
+   return;
+
+   if (!cpu_feature_enabled(X86_FEATURE_ENQCMD))
+   return;
+
+   __free_pasid(mm);
+}
+
  static inline void destroy_context(struct mm_struct *mm)
  {
destroy_context_ldt(mm);
+   free_pasid(mm);
  }
  
  extern void switch_mm(struct mm_struct *prev, struct mm_struct *next,

diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 8a0cf2f0dd54..4c70b037 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -425,6 +425,69 @@ int intel_svm_unbind_gpasid(struct device *dev, u32 pasid)
return ret;
  }
  
+static void free_bind(struct intel_svm *svm, struct intel_svm_dev *sdev,

+ bool new_pasid)
+{
+   if (new_pasid)
+   ioasid_free(svm->pasid);
+   kfree(svm);
+   kfree(sdev);
+}
+
+/*
+ * If this mm already has a PASID, use it. Otherwise allocate a new one.
+ * Let the caller know if a new PASID is allocated via 'new_pasid'.
+ */
+static int alloc_pasid(struct intel_svm *svm, struct mm_struct *mm,
+  u32 pasid_max, bool *new_pasid,
+  unsigned int flags)
+{
+   u32 pasid;
+
+   *new_pasid = false;
+
+   /*
+* Reuse the PASID if the mm already has a PASID and not a private
+* PASID is requested.
+*/
+   if (mm && mm->pasid && !(flags & SVM_FLAG_PRIVATE_PASID)) {
+   void *p;
+
+   /*
+* Since the mm has a PASID already, the PASID should be
+* bound and unbound to the mm before calling this allocation.
+* So the PASID must be allocated by bind_mm() previously and
+* should still exist in ioasid; but its data must be cleared
+* already by unbind_mm().
+*
+* Do a sanity check here to ensure the PASID has the right
+* status before reusing it.
+*/
+   p = ioasid_find(NULL, mm->pasid, NULL);
+   if (IS_ERR(p) || p)
+   return INVALID_IOASID;
+
+   /*
+* Once the PASID is allocated for this mm, it
+* stays with the mm until the mm is dropped. Reuse
+* the PASID which has been already allocated for the
+* mm instead of allocating a new one.
+*/
+   ioasid_set_data(mm->pasid, svm);
+
+   return mm->pasid;
+   }
+
+   /* Allocate a new pasid. Do not use PASID 0, reserved for init PASID. */
+   pasid = ioasid_alloc(NULL, PASID_MIN, pasid_max - 1, svm);
+   if (pasid != INVALID_IOASID) {
+   /* A new pasid is allocated. */
+   *new_pasid = true;
+   }
+
+   return pasid;
+}
+
  /*

linux-next: manual merge of the drm-misc tree with Linus' tree

Hi all,

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

  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c

between commit:

  eaad0c3aa978 ("drm/amdgpu: rename direct to immediate for VM updates")

from the Linus' and commit:

  b1a8ef952a25 ("drm/amdgpu: move ttm bo->offset to amdgpu_bo")

from the drm-misc 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 drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
index 28bdfb3ac33d,2a7a6f62d627..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
@@@ -144,8 -141,8 +144,8 @@@ static void amdgpu_vm_sdma_copy_ptes(st
  
src += p->num_dw_left * 4;
  
-   pe += amdgpu_gmc_sign_extend(bo->tbo.offset);
+   pe += amdgpu_bo_gpu_offset_no_check(bo);
 -  trace_amdgpu_vm_copy_ptes(pe, src, count, p->direct);
 +  trace_amdgpu_vm_copy_ptes(pe, src, count, p->immediate);
  
amdgpu_vm_copy_pte(p->adev, ib, pe, src, count);
  }
@@@ -171,8 -168,8 +171,8 @@@ static void amdgpu_vm_sdma_set_ptes(str
  {
struct amdgpu_ib *ib = p->job->ibs;
  
-   pe += amdgpu_gmc_sign_extend(bo->tbo.offset);
+   pe += amdgpu_bo_gpu_offset_no_check(bo);
 -  trace_amdgpu_vm_set_ptes(pe, addr, count, incr, flags, p->direct);
 +  trace_amdgpu_vm_set_ptes(pe, addr, count, incr, flags, p->immediate);
if (count < 3) {
amdgpu_vm_write_pte(p->adev, ib, pe, addr | flags,
count, incr);


pgpuMWeGLIVtZ.pgp
Description: OpenPGP digital signature

Re: [PATCH 00/13] iommu: Remove usage of dev->archdata.iommu

2020-06-25 Thread Jerry Snitselaar


On Thu Jun 25 20, Joerg Roedel wrote:

From: Joerg Roedel 

Hi,

here is a patch-set to remove the usage of dev->archdata.iommu from
the IOMMU code in the kernel and replace its uses by the iommu per-device
private data field. The changes also remove the field entirely from
the architectures which no longer need it.

On PowerPC the field is called dev->archdata.iommu_domain and was only
used by the PAMU IOMMU driver. It gets removed as well.

The patches have been runtime tested on Intel VT-d and compile tested
with allyesconfig for:

* x86 (32 and 64 bit)
* arm and arm64
* ia64 (only drivers/ because build failed for me in
arch/ia64)
* PPC64

Besides that the changes also survived my IOMMU tree compile tests.

Please review.

Regards,

Joerg

Joerg Roedel (13):
 iommu/exynos: Use dev_iommu_priv_get/set()
 iommu/vt-d: Use dev_iommu_priv_get/set()
 iommu/msm: Use dev_iommu_priv_get/set()
 iommu/omap: Use dev_iommu_priv_get/set()
 iommu/rockchip: Use dev_iommu_priv_get/set()
 iommu/tegra: Use dev_iommu_priv_get/set()
 iommu/pamu: Use dev_iommu_priv_get/set()
 iommu/mediatek: Do no use dev->archdata.iommu
 x86: Remove dev->archdata.iommu pointer
 ia64: Remove dev->archdata.iommu pointer
 arm: Remove dev->archdata.iommu pointer
 arm64: Remove dev->archdata.iommu pointer
 powerpc/dma: Remove dev->archdata.iommu_domain

arch/arm/include/asm/device.h |  3 ---
arch/arm64/include/asm/device.h   |  3 ---
arch/ia64/include/asm/device.h|  3 ---
arch/powerpc/include/asm/device.h |  3 ---
arch/x86/include/asm/device.h |  3 ---
.../gpu/drm/i915/selftests/mock_gem_device.c  | 10 --
drivers/iommu/exynos-iommu.c  | 20 +--
drivers/iommu/fsl_pamu_domain.c   |  8 
drivers/iommu/intel/iommu.c   | 18 -
drivers/iommu/msm_iommu.c |  4 ++--
drivers/iommu/mtk_iommu.h |  2 ++
drivers/iommu/mtk_iommu_v1.c  | 10 --
drivers/iommu/omap-iommu.c| 20 +--
drivers/iommu/rockchip-iommu.c|  8 
drivers/iommu/tegra-gart.c|  8 
drivers/iommu/tegra-smmu.c|  8 
.../media/platform/s5p-mfc/s5p_mfc_iommu.h|  4 +++-
17 files changed, 64 insertions(+), 71 deletions(-)

--
2.27.0



Reviewed-by: Jerry Snitselaar

Re: [GIT] Networking

2020-06-25 Thread pr-tracker-bot

The pull request you sent on Thu, 25 Jun 2020 16:43:48 -0700 (PDT):

> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net refs/heads/master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4a21185cda0fbb860580eeeb4f1a70a9cda332a4

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PATCH v5 3/3] media: vimc: Add a control to display info on test image

2020-06-25 Thread Helen Koike

Hi Kaaira,

Thanks for your patch, I tested and it works great, just some other comments 
below.

On 6/24/20 10:43 AM, Kaaira Gupta wrote:
> Add a control in VIMC to display information such as the correct order of
> colors for a given test pattern, brightness, hue, saturation, contrast,
> width and height at sensor over test image.
> 
> Signed-off-by: Kaaira Gupta 
> ---
>  drivers/media/test-drivers/vimc/Kconfig   |  2 +
>  drivers/media/test-drivers/vimc/vimc-common.h |  1 +
>  drivers/media/test-drivers/vimc/vimc-core.c   | 10 
>  drivers/media/test-drivers/vimc/vimc-sensor.c | 57 +++
>  4 files changed, 70 insertions(+)
> 
> diff --git a/drivers/media/test-drivers/vimc/Kconfig 
> b/drivers/media/test-drivers/vimc/Kconfig
> index 4068a67585f9..da4b2ad6e40c 100644
> --- a/drivers/media/test-drivers/vimc/Kconfig
> +++ b/drivers/media/test-drivers/vimc/Kconfig
> @@ -2,6 +2,8 @@
>  config VIDEO_VIMC
>   tristate "Virtual Media Controller Driver (VIMC)"
>   depends on VIDEO_DEV && VIDEO_V4L2
> + select FONT_SUPPORT
> + select FONT_8x16
>   select MEDIA_CONTROLLER
>   select VIDEO_V4L2_SUBDEV_API
>   select VIDEOBUF2_VMALLOC
> diff --git a/drivers/media/test-drivers/vimc/vimc-common.h 
> b/drivers/media/test-drivers/vimc/vimc-common.h
> index ae163dec2459..afda52253402 100644
> --- a/drivers/media/test-drivers/vimc/vimc-common.h
> +++ b/drivers/media/test-drivers/vimc/vimc-common.h
> @@ -20,6 +20,7 @@
>  #define VIMC_CID_VIMC_CLASS  (0x00f0 | 1)
>  #define VIMC_CID_TEST_PATTERN(VIMC_CID_VIMC_BASE + 0)
>  #define VIMC_CID_MEAN_WIN_SIZE   (VIMC_CID_VIMC_BASE + 1)
> +#define VIMC_CID_SHOW_INFO   (VIMC_CID_VIMC_BASE + 2)
>  
>  #define VIMC_FRAME_MAX_WIDTH 4096
>  #define VIMC_FRAME_MAX_HEIGHT 2160
> diff --git a/drivers/media/test-drivers/vimc/vimc-core.c 
> b/drivers/media/test-drivers/vimc/vimc-core.c
> index 11210aaa2551..461320ae965c 100644
> --- a/drivers/media/test-drivers/vimc/vimc-core.c
> +++ b/drivers/media/test-drivers/vimc/vimc-core.c
> @@ -5,10 +5,12 @@
>   * Copyright (C) 2015-2017 Helen Koike 
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "vimc-common.h"
> @@ -263,6 +265,7 @@ static int vimc_register_devices(struct vimc_device *vimc)
>  
>  static int vimc_probe(struct platform_device *pdev)
>  {
> + const struct font_desc *font = find_font("VGA8x16");
>   struct vimc_device *vimc;
>   int ret;
>  
> @@ -272,6 +275,13 @@ static int vimc_probe(struct platform_device *pdev)
>   if (!vimc)
>   return -ENOMEM;
>  
> + if (!font) {
> + dev_err(>dev, "vimc: could not find font\n");
> + return -ENODEV;

Move this check above the kzalloc(), otherwise there is a memory leak.

> + }
> +
> + tpg_set_font(font->data);
> +
>   vimc->pipe_cfg = _cfg;
>  
>   /* Link the media device within the v4l2_device */
> diff --git a/drivers/media/test-drivers/vimc/vimc-sensor.c 
> b/drivers/media/test-drivers/vimc/vimc-sensor.c
> index a2f09ac9a360..d776fdcdc3bf 100644
> --- a/drivers/media/test-drivers/vimc/vimc-sensor.c
> +++ b/drivers/media/test-drivers/vimc/vimc-sensor.c
> @@ -19,6 +19,8 @@ struct vimc_sen_device {
>   struct v4l2_subdev sd;
>   struct tpg_data tpg;
>   u8 *frame;
> + unsigned show_info;
> + unsigned ns;
>   /* The active format */
>   struct v4l2_mbus_framefmt mbus_format;
>   struct v4l2_ctrl_handler hdl;
> @@ -185,10 +187,43 @@ static const struct v4l2_subdev_pad_ops 
> vimc_sen_pad_ops = {
>  static void *vimc_sen_process_frame(struct vimc_ent_device *ved,
>   const void *sink_frame)
>  {
> + u8 *basep[TPG_MAX_PLANES][2];
> + char str[100];
> + int line = 1;
>   struct vimc_sen_device *vsen = container_of(ved, struct vimc_sen_device,
>   ved);
>  
>   tpg_fill_plane_buffer(>tpg, 0, 0, vsen->frame);
> + tpg_calc_text_basep(>tpg, basep, 0, vsen->frame);
> +
> + if (vsen->show_info <= 1) {
> + unsigned ms;
> +
> + ms = (ktime_get_ns() - vsen->ns) / 100;
> + snprintf(str, sizeof(str), "%02d:%02d:%02d:%03d",
> +  (ms / (60 * 60 * 1000)) % 24,
> +  (ms / (60 * 1000)) % 60,
> +  (ms / 1000) % 60,
> +  ms % 1000);
> + tpg_gen_text(>tpg, basep, line++ * 16, 16, str);
> + }
> +
> + if (vsen->show_info == 0) {
> + const char *order = tpg_g_color_order(>tpg);
> +
> + tpg_gen_text(>tpg, basep, line++ * 16, 16, order);
> + snprintf(str, sizeof(str),
> +  "brightness %3d, contrast %3d, saturation %3d, hue %d 
> ",
> +  vsen->tpg.brightness,
> +  vsen->tpg.contrast,
> +

Re: [PATCH v4 02/12] iommu/vt-d: Change flags type to unsigned int in binding mm


Hi Fenghua,

On 2020/6/26 4:17, Fenghua Yu wrote:

"flags" passed to intel_svm_bind_mm() is a bit mask and should be
defined as "unsigned int" instead of "int".

Change its type to "unsigned int".


Reviewed-by: Lu Baolu 

Best regards,
baolu



Suggested-by: Thomas Gleixner 
Signed-off-by: Fenghua Yu 
Reviewed-by: Tony Luck 
---
v2:
- Add this new patch per Thomas' comment.

  drivers/iommu/intel/svm.c   | 7 ---
  include/linux/intel-iommu.h | 2 +-
  2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 778089d198eb..8a0cf2f0dd54 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -427,7 +427,8 @@ int intel_svm_unbind_gpasid(struct device *dev, u32 pasid)
  
  /* Caller must hold pasid_mutex, mm reference */

  static int
-intel_svm_bind_mm(struct device *dev, int flags, struct svm_dev_ops *ops,
+intel_svm_bind_mm(struct device *dev, unsigned int flags,
+ struct svm_dev_ops *ops,
  struct mm_struct *mm, struct intel_svm_dev **sd)
  {
struct intel_iommu *iommu = intel_svm_device_to_iommu(dev);
@@ -954,7 +955,7 @@ intel_svm_bind(struct device *dev, struct mm_struct *mm, 
void *drvdata)
  {
struct iommu_sva *sva = ERR_PTR(-EINVAL);
struct intel_svm_dev *sdev = NULL;
-   int flags = 0;
+   unsigned int flags = 0;
int ret;
  
  	/*

@@ -963,7 +964,7 @@ intel_svm_bind(struct device *dev, struct mm_struct *mm, 
void *drvdata)
 * and intel_svm etc.
 */
if (drvdata)
-   flags = *(int *)drvdata;
+   flags = *(unsigned int *)drvdata;
mutex_lock(_mutex);
ret = intel_svm_bind_mm(dev, flags, NULL, mm, );
if (ret)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 314a95870e47..4d20f93a5e2d 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -759,7 +759,7 @@ struct intel_svm {
struct mm_struct *mm;
  
  	struct intel_iommu *iommu;

-   int flags;
+   unsigned int flags;
u32 pasid;
int gpasid; /* In case that guest PASID is different from host PASID */
struct list_head devs;

Re: [PATCH 1/3] v4l2-subdev: Add subdev ioctl support for ENUM/GET/SET INPUT

2020-06-25 Thread Laurent Pinchart

Hi Steve,

On Thu, Jun 25, 2020 at 10:41:09AM -0700, Steve Longerbeam wrote:
> On 6/24/20 7:01 PM, Laurent Pinchart wrote:
> > On Wed, Jun 24, 2020 at 09:53:07AM +0200, Jacopo Mondi wrote:
> >> On Tue, Jun 16, 2020 at 12:00:15PM +0200, Ramzi BEN MEFTAH wrote:
> >>> From: Steve Longerbeam 
> >>   +Niklas, +Laurent
> >>
> >> Niklas, Laurent, how does this play with CAP_IO_MC ?
> > I don't think it's related to CAP_IO_MC, but I don't think it's a good
> > idea either :-) Routing doesn't go through the subdev [gs]_input
> > operations in MC-based drivers. It should be configured through link
> > setup instead. This patch goes in the wrong direction, sorry Steve.
> 
> That's OK! :) I didn't submit this patch, and as stated in the commit 
> header, I never recommended this patch be submitted to upstream in the 
> first place.
> 
> Selecting inputs at a subdev should normally make use of media link 
> setup. But for selecting analog signal inputs, such as the ADV748x AFE 
> standard definition inputs, that would  mean there would need to exist 
> source "analog" subdevs that connect to the AFE inputs, if only for the 
> purpose of selecting those inputs, which seems silly IMHO. The ADV748x 
> AFE subdev defines these inputs as media pads, but have no connections, 
> so link setup API can't be used to select those inputs.
> 
> So a new subdev pad API is clearly needed, not just to get input status 
> at a subdev pad, but to select/make active such analog inputs without 
> requiring link setup API.

There was an attempt to create a subdev ioctl to configure internal
routing. See "[PATCH v4 19/31] media: Documentation: Add GS_ROUTING
documentation" ([1]) and the related patches in the series.

[1] 
https://lore.kernel.org/linux-media/20190328200608.9463-20-jacopo+rene...@jmondi.org/

> >>> This commit enables VIDIOC_ENUMINPUT, VIDIOC_G_INPUT, and VIDIOC_S_INPUT
> >>> ioctls for use via v4l2 subdevice node.
> >>>
> >>> This commit should probably not be pushed upstream, because the (old)
> >>> idea of video inputs conflicts with the newer concept of establishing
> >>> media links between src->sink pads.
> >>>
> >>> However it might make sense for some subdevices to support enum/get/set
> >>> inputs. One example would be the analog front end subdevice for the
> >>> ADV748x. By providing these ioctls, selecting the ADV748x analog inputs
> >>> can be done without requiring the implementation of media entities that
> >>> would define the analog source for which to establish a media link.
> >>>
> >>> Signed-off-by: Steve Longerbeam 
> >>> ---
> >>>   drivers/media/v4l2-core/v4l2-subdev.c |  9 +
> >>>   include/media/v4l2-subdev.h   | 11 +++
> >>>   2 files changed, 20 insertions(+)
> >>>
> >>> diff --git a/drivers/media/v4l2-core/v4l2-subdev.c 
> >>> b/drivers/media/v4l2-core/v4l2-subdev.c
> >>> index 6b989fe..73fbfe9 100644
> >>> --- a/drivers/media/v4l2-core/v4l2-subdev.c
> >>> +++ b/drivers/media/v4l2-core/v4l2-subdev.c
> >>> @@ -378,6 +378,15 @@ static long subdev_do_ioctl(struct file *file, 
> >>> unsigned int cmd, void *arg)
> >>>   return -ENOTTY;
> >>>   return v4l2_querymenu(vfh->ctrl_handler, arg);
> >>>
> >>> + case VIDIOC_ENUMINPUT:
> >>> + return v4l2_subdev_call(sd, video, enuminput, arg);
> >>> +
> >>> + case VIDIOC_G_INPUT:
> >>> + return v4l2_subdev_call(sd, video, g_input, arg);
> >>> +
> >>> + case VIDIOC_S_INPUT:
> >>> + return v4l2_subdev_call(sd, video, s_input, *(u32 *)arg);
> >>> +
> >>>   case VIDIOC_G_CTRL:
> >>>   if (!vfh->ctrl_handler)
> >>>   return -ENOTTY;
> >>> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> >>> index f7fe78a..6e1a9cd 100644
> >>> --- a/include/media/v4l2-subdev.h
> >>> +++ b/include/media/v4l2-subdev.h
> >>> @@ -383,6 +383,14 @@ struct v4l2_mbus_frame_desc {
> >>>* @g_input_status: get input status. Same as the status field in the
> >>>*   _input
> >>>*
> >>> + * @enuminput: enumerate inputs. Should return the same input status as
> >>> + *  @g_input_status if the passed input index is the currently active
> >>> + *  input.
> >>> + *
> >>> + * @g_input: returns the currently active input index.
> >>> + *
> >>> + * @s_input: set the active input.
> >>> + *
> >>>* @s_stream: used to notify the driver that a video stream will start 
> >>> or has
> >>>*  stopped.
> >>>*
> >>> @@ -423,6 +431,9 @@ struct v4l2_subdev_video_ops {
> >>>   int (*g_tvnorms)(struct v4l2_subdev *sd, v4l2_std_id *std);
> >>>   int (*g_tvnorms_output)(struct v4l2_subdev *sd, v4l2_std_id 
> >>> *std);
> >>>   int (*g_input_status)(struct v4l2_subdev *sd, u32 *status);
> >>> + int (*enuminput)(struct v4l2_subdev *sd, struct v4l2_input *input);
> >>> + int (*g_input)(struct v4l2_subdev *sd, u32 *index);
> >>> + int (*s_input)(struct v4l2_subdev *sd, u32 index);
> >>>   int

Re: [PATCH v4 4/5] dm: pci: Assign controller device node to root bridge

2020-06-25 Thread Simon Glass

Hi Nicolas,

On Wed, 17 Jun 2020 at 13:15, Nicolas Saenz Julienne
 wrote:
>
> On Tue, 2020-06-16 at 17:31 -0600, Simon Glass wrote:
> > Hi Nicolas,
> >
> > On Tue, 16 Jun 2020 at 08:09, Nicolas Saenz Julienne
> >  wrote:
> > > On Tue, 2020-06-16 at 07:43 -0600, Simon Glass wrote:
> > > > Hi Nicolas,
> > > >
> > > > On Fri, 12 Jun 2020 at 10:47, Nicolas Saenz Julienne
> > > >  wrote:
> > > > > There is no distinction in DT between the PCI controller device and 
> > > > > the
> > > > > root bridge, whereas such distinction exists from dm's perspective. 
> > > > > Make
> > > > > sure the root bridge ofnode is assigned to the controller's platform
> > > > > device node.
> > > > >
> > > > > This permits setups like this to work correctly:
> > > > >
> > > > > pcie {
> > > > > compatible = "...";
> > > > > ...
> > > > > dev {
> > > > > reg = <0 0 0 0 0>;
> > > > > ...
> > > > > };
> > > > > };
> > > > >
> > > > > Without this the dev node is assigned to the root bridge and the
> > > > > actual device search starts one level lower than expected.
> > > > >
> > > > > Signed-off-by: Nicolas Saenz Julienne 
> > > > > ---
> > > > >  drivers/pci/pci-uclass.c | 15 ++-
> > > > >  1 file changed, 14 insertions(+), 1 deletion(-)
> > > >
> > > > Can you update the tests to handle this case please?
> > >
> > > I'd be glad to, but I'm not familiar with the test FW in u-booy, coud give
> > > me
> > > some pointers on where/how to test this?
> > >
> >
> > Yes it is at test/dm/pci.c and the device tree is test.dts
> >
> > 'make qcheck' to run all tests. To run one test, build for sandbox and
> > then something like
> >
> > u-boot -T -c "ut dm pci_swapcase"
> >
> > for example.
> >
> > You can perhaps use an existing PCI controller in test.dts but feel
> > free to add one more if you need it for your test. Make sure that you
> > don't break other tests.
>
> Thanks for the info.
>
> Actually adding the tests made me doubleguess myself, and now I'm pretty sure
> that what I shoudl've done in DT is the following:
>
>  {
>pci@0 {
>#address-cells = <3>;
>#size-cells = <2>;
>ranges;
>
>reg = <0 0 0 0 0>;
>
>usb@1,0 {
>reg = <0x1 0 0 0 0>;
>resets = < 
> RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
>};
>};
> };
>
>
> (with "lspci -tv": [:00]---00.0-[01]00.0  VIA Technologies, Inc. 
> VL805 USB 3.0 Host Controller)
>
> With this the patch above isn't needed, which is great.
>
> I'll send this to upstream Linux just to get a confirmation this is correct,
> although if you have any comments it'll be appreciated.

Yes it looks OK to me. U-Boot allows PCI and USB devices to be
represented in the device tree.

Regards,
Simon

[PATCH] net: phy: mscc: fix ptr_ret.cocci warnings