Re: [PATCH v2 BUGFIX] ARM: dts: imx6ull: fix the imx6ull-14x14-evk configuration

[Shawn Guo]

On Fri, Jan 26, 2018 at 09:52:18AM +0100, Lothar Waßmann wrote:
> imx6ull-14x14-evk.dts currently includes the imx6ul.dtsi file for an
> i.MX6ULL SoC which is plain wrong.
> 
> Rename the current imx6ul-14x14-evk.dts to .dtsi and include it from
> imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts, so that both can
> include the appropriate SoC specific (imx6ul.dtsi/imx6ull.dtsi) file.
> 
> Signed-off-by: Lothar Waßmann 

Which base is the patch generated against?  I cannot apply it to any
branch in my tree.

Shawn

Re: [PATCH v2 BUGFIX] ARM: dts: imx6ull: fix the imx6ull-14x14-evk configuration

[Shawn Guo]

On Fri, Jan 26, 2018 at 09:52:18AM +0100, Lothar Waßmann wrote:
> imx6ull-14x14-evk.dts currently includes the imx6ul.dtsi file for an
> i.MX6ULL SoC which is plain wrong.
> 
> Rename the current imx6ul-14x14-evk.dts to .dtsi and include it from
> imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts, so that both can
> include the appropriate SoC specific (imx6ul.dtsi/imx6ull.dtsi) file.
> 
> Signed-off-by: Lothar Waßmann 

Which base is the patch generated against?  I cannot apply it to any
branch in my tree.

Shawn

Re: [PATCH 02/20] KVM: PPC: Book3S PR: Fix broken select due to misspelling

[Paul Mackerras]

On Mon, Feb 05, 2018 at 05:58:59AM +0100, Ulf Magnusson wrote:
> On Mon, Feb 5, 2018 at 5:48 AM, Paul Mackerras  wrote:
> > On Mon, Feb 05, 2018 at 02:21:14AM +0100, Ulf Magnusson wrote:
> >> Commit 76d837a4c0f9 ("KVM: PPC: Book3S PR: Don't include SPAPR TCE code
> >> on non-pseries platforms") added a reference to the globally undefined
> >> symbol PPC_SERIES. Looking at the rest of the commit, PPC_PSERIES was
> >> probably intended.
> >>
> >> Change PPC_SERIES to PPC_PSERIES.
> >>
> >> Discovered with the
> >> https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
> >> script.
> >>
> >> Signed-off-by: Ulf Magnusson 
> >
> > Acked-by: Paul Mackerras 
> >
> > Which tree is this series going into?
> >
> > Paul.
> 
> I didn't have a particular one in mind. I imagined people would pick
> up individual patches into the trees that make the most sense. It was
> easiest to do the undefined symbol removal as a kernel-wide batch job.

OK, I'll take this one then.

Paul.

Re: [PATCH 02/20] KVM: PPC: Book3S PR: Fix broken select due to misspelling

[Paul Mackerras]

On Mon, Feb 05, 2018 at 05:58:59AM +0100, Ulf Magnusson wrote:
> On Mon, Feb 5, 2018 at 5:48 AM, Paul Mackerras  wrote:
> > On Mon, Feb 05, 2018 at 02:21:14AM +0100, Ulf Magnusson wrote:
> >> Commit 76d837a4c0f9 ("KVM: PPC: Book3S PR: Don't include SPAPR TCE code
> >> on non-pseries platforms") added a reference to the globally undefined
> >> symbol PPC_SERIES. Looking at the rest of the commit, PPC_PSERIES was
> >> probably intended.
> >>
> >> Change PPC_SERIES to PPC_PSERIES.
> >>
> >> Discovered with the
> >> https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
> >> script.
> >>
> >> Signed-off-by: Ulf Magnusson 
> >
> > Acked-by: Paul Mackerras 
> >
> > Which tree is this series going into?
> >
> > Paul.
> 
> I didn't have a particular one in mind. I imagined people would pick
> up individual patches into the trees that make the most sense. It was
> easiest to do the undefined symbol removal as a kernel-wide batch job.

OK, I'll take this one then.

Paul.

Re: [PATCH] ARM: dts: use 'atmel' as at24 manufacturer for imx6qdl-zii-rdu2

[Shawn Guo]

On Wed, Jan 24, 2018 at 10:28:23PM +0100, Bartosz Golaszewski wrote:
> Using 'at' as the  part of the compatible string is now
> deprecated. Use a correct string: 'atmel,'.
> 
> Signed-off-by: Bartosz Golaszewski 

Applied, thanks.

Re: [PATCH] ARM: dts: use 'atmel' as at24 manufacturer for imx6qdl-rex

[Shawn Guo]

On Wed, Jan 24, 2018 at 10:31:16PM +0100, Bartosz Golaszewski wrote:
> Using 'at' as the  part of the compatible string is now
> deprecated. Use a correct string: 'atmel,'.
> 
> Signed-off-by: Bartosz Golaszewski 

Applied, thanks.

Re: [PATCH] ARM: dts: use 'atmel' as at24 manufacturer for imx6qdl-rex

[Shawn Guo]

On Wed, Jan 24, 2018 at 10:31:16PM +0100, Bartosz Golaszewski wrote:
> Using 'at' as the  part of the compatible string is now
> deprecated. Use a correct string: 'atmel,'.
> 
> Signed-off-by: Bartosz Golaszewski 

Applied, thanks.

Re: [PATCH] ARM: dts: use 'atmel' as at24 manufacturer for imx6qdl-zii-rdu2

[Shawn Guo]

On Wed, Jan 24, 2018 at 10:28:23PM +0100, Bartosz Golaszewski wrote:
> Using 'at' as the  part of the compatible string is now
> deprecated. Use a correct string: 'atmel,'.
> 
> Signed-off-by: Bartosz Golaszewski 

Applied, thanks.

Re: [PATCH] ARM: dts: fix the at24 compatible string in imx6q-h100

[Shawn Guo]

On Wed, Jan 24, 2018 at 10:31:48PM +0100, Bartosz Golaszewski wrote:
> Using 'at24' as fallback is now deprecated - use the full
> 'atmel,' string.
> 
> Signed-off-by: Bartosz Golaszewski 

Applied, thanks.

Re: [PATCH] ARM: dts: fix the at24 compatible string in imx6q-h100

[Shawn Guo]

On Wed, Jan 24, 2018 at 10:31:48PM +0100, Bartosz Golaszewski wrote:
> Using 'at24' as fallback is now deprecated - use the full
> 'atmel,' string.
> 
> Signed-off-by: Bartosz Golaszewski 

Applied, thanks.

Re: [PATCH v3 1/3] ARM: dts: imx: Pass empty memory size on board dts

[Shawn Guo]

On Wed, Jan 24, 2018 at 11:22:12AM -0200, Marco Franchi wrote:
> In preparation for removing 'reg = <0 0>;' from the dtsi SoC files, pass
> 'reg = <0 0 >;' to the dts/dtsi board files that do not pass the memory
> size.
> 
> Signed-off-by: Marco Franchi 

Applied all, thanks.

Re: [PATCH v3 1/3] ARM: dts: imx: Pass empty memory size on board dts

[Shawn Guo]

On Wed, Jan 24, 2018 at 11:22:12AM -0200, Marco Franchi wrote:
> In preparation for removing 'reg = <0 0>;' from the dtsi SoC files, pass
> 'reg = <0 0 >;' to the dts/dtsi board files that do not pass the memory
> size.
> 
> Signed-off-by: Marco Franchi 

Applied all, thanks.

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

[Chao Yu]

On 2018/2/5 14:40, Yunlong Song wrote:
> Is it necessary to make atomic commit fail? What's the problem of this
> patch (no lock at all and does not make atomic fail)? These two patches
> aims to provide ability to gc old blocks of opened atomic file, with no
> affection to original atomic commit and no mix with inmem pages.
> 
> On 2018/2/5 14:29, Chao Yu wrote:
>> On 2018/2/5 10:53, Yunlong Song wrote:
>>> Is it necessary to add a lock here? What's the problem of this patch (no
>>> lock at all)? Anyway, the problem is expected to be fixed asap, since
>>> attackers can easily write an app with only atomic start and no atomic
>>> commit, which will cause f2fs run into loop gc if the disk layout is
>>> much fragmented, since f2fs_gc will select the same target victim all
>>> the time (e.g. one block of target victim belongs to the opened atomic
>>> file, and it will not be moved and do_garbage_collect will finally
>>> return 0, and that victim is selected again next time) and goto gc_more
>>> time and time again, which will block all the fs ops (all the fs ops
>>> will hang up in f2fs_balance_fs).
>>
>> Hmm.. w/ original commit log and implementation, I supposed that the patch
>> intended to fix to make atomic write be isolated from other IOs like GC
>> triggered writes...
>>
>> Alright, we have discuss the problem before in below link:
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1571951.html
>>
>> I meant, for example:
>>
>> f2fs_ioc_start_atomic_write()
>> inode->atomic_open_time = get_mtime();
>>
>> f2fs_ioc_commit_atomic_write()
>> inode->atomic_open_time = 0;
>>
>> f2fs_balance_fs_bg()
>> for_each_atomic_open_file()
>>  if (inode->atomic_open_time &&
>>  inode->atomic_open_time > threshold) {
>>  drop_inmem_pages();
>>  f2fs_msg();
>>  }
>>
>> threshold = 30s
>>
>> Any thoughts?
>>
>> Thanks,
>>
>>>
>>> On 2018/2/4 22:56, Chao Yu wrote:
 On 2018/2/3 10:47, Yunlong Song wrote:
> If inode has already started to atomic commit, then set_page_dirty will
> not mix the gc pages with the inmem atomic pages, so the page can be
> gced safely.

 Let's avoid Ccing fs mailing list if the patch didn't change vfs common
 codes.

 As you know, the problem here is mixed dnode block flushing w/o 
 writebacking
 gced data block, result in making transaction unintegrated.

OK, details as I explained before:

atomic_commit   GC
- file_write_and_wait_range
- move_data_block
 - f2fs_submit_page_write
  - f2fs_update_data_blkaddr
   - set_page_dirty
 - fsync_node_pages

1. atomic writes data page #1 & update node #1
2. GC data page #2 & update node #2
3. page #1 & node #1 & #2 can be committed into nand flash before page #2 be
committed.

After a sudden pow-cut, database transaction will be inconsistent. So I think
there will be better to exclude gc/atomic_write to each other, with a lock
instead of flag checking.

Thanks,


 So how about just using dio_rwsem[WRITE] during atomic committing to 
 exclude
 GCing data block of atomic opened file?

 Thanks,

>
> Signed-off-by: Yunlong Song 
> ---
>fs/f2fs/data.c | 5 ++---
>fs/f2fs/gc.c   | 6 --
>2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 7435830..edafcb6 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -1580,14 +1580,13 @@ bool should_update_outplace(struct inode *inode, 
> struct f2fs_io_info *fio)
>   return true;
>   if (S_ISDIR(inode->i_mode))
>   return true;
> - if (f2fs_is_atomic_file(inode))
> - return true;
>   if (fio) {
>   if (is_cold_data(fio->page))
>   return true;
>   if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
>   return true;
> - }
> + } else if (f2fs_is_atomic_file(inode))
> + return true;
>   return false;
>}
>
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index b9d93fd..84ab3ff 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -622,7 +622,8 @@ static void move_data_block(struct inode *inode, 
> block_t bidx,
>   if (!check_valid_map(F2FS_I_SB(inode), segno, off))
>   goto out;
>
> - if (f2fs_is_atomic_file(inode))
> + if (f2fs_is_atomic_file(inode) &&
> + !f2fs_is_commit_atomic_write(inode))
>   goto out;
>
>   if (f2fs_is_pinned_file(inode)) {
> @@ -729,7 +730,8 @@ static void move_data_page(struct inode *inode, 
> block_t 

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

[Chao Yu]

On 2018/2/5 14:40, Yunlong Song wrote:
> Is it necessary to make atomic commit fail? What's the problem of this
> patch (no lock at all and does not make atomic fail)? These two patches
> aims to provide ability to gc old blocks of opened atomic file, with no
> affection to original atomic commit and no mix with inmem pages.
> 
> On 2018/2/5 14:29, Chao Yu wrote:
>> On 2018/2/5 10:53, Yunlong Song wrote:
>>> Is it necessary to add a lock here? What's the problem of this patch (no
>>> lock at all)? Anyway, the problem is expected to be fixed asap, since
>>> attackers can easily write an app with only atomic start and no atomic
>>> commit, which will cause f2fs run into loop gc if the disk layout is
>>> much fragmented, since f2fs_gc will select the same target victim all
>>> the time (e.g. one block of target victim belongs to the opened atomic
>>> file, and it will not be moved and do_garbage_collect will finally
>>> return 0, and that victim is selected again next time) and goto gc_more
>>> time and time again, which will block all the fs ops (all the fs ops
>>> will hang up in f2fs_balance_fs).
>>
>> Hmm.. w/ original commit log and implementation, I supposed that the patch
>> intended to fix to make atomic write be isolated from other IOs like GC
>> triggered writes...
>>
>> Alright, we have discuss the problem before in below link:
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1571951.html
>>
>> I meant, for example:
>>
>> f2fs_ioc_start_atomic_write()
>> inode->atomic_open_time = get_mtime();
>>
>> f2fs_ioc_commit_atomic_write()
>> inode->atomic_open_time = 0;
>>
>> f2fs_balance_fs_bg()
>> for_each_atomic_open_file()
>>  if (inode->atomic_open_time &&
>>  inode->atomic_open_time > threshold) {
>>  drop_inmem_pages();
>>  f2fs_msg();
>>  }
>>
>> threshold = 30s
>>
>> Any thoughts?
>>
>> Thanks,
>>
>>>
>>> On 2018/2/4 22:56, Chao Yu wrote:
 On 2018/2/3 10:47, Yunlong Song wrote:
> If inode has already started to atomic commit, then set_page_dirty will
> not mix the gc pages with the inmem atomic pages, so the page can be
> gced safely.

 Let's avoid Ccing fs mailing list if the patch didn't change vfs common
 codes.

 As you know, the problem here is mixed dnode block flushing w/o 
 writebacking
 gced data block, result in making transaction unintegrated.

OK, details as I explained before:

atomic_commit   GC
- file_write_and_wait_range
- move_data_block
 - f2fs_submit_page_write
  - f2fs_update_data_blkaddr
   - set_page_dirty
 - fsync_node_pages

1. atomic writes data page #1 & update node #1
2. GC data page #2 & update node #2
3. page #1 & node #1 & #2 can be committed into nand flash before page #2 be
committed.

After a sudden pow-cut, database transaction will be inconsistent. So I think
there will be better to exclude gc/atomic_write to each other, with a lock
instead of flag checking.

Thanks,


 So how about just using dio_rwsem[WRITE] during atomic committing to 
 exclude
 GCing data block of atomic opened file?

 Thanks,

>
> Signed-off-by: Yunlong Song 
> ---
>fs/f2fs/data.c | 5 ++---
>fs/f2fs/gc.c   | 6 --
>2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 7435830..edafcb6 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -1580,14 +1580,13 @@ bool should_update_outplace(struct inode *inode, 
> struct f2fs_io_info *fio)
>   return true;
>   if (S_ISDIR(inode->i_mode))
>   return true;
> - if (f2fs_is_atomic_file(inode))
> - return true;
>   if (fio) {
>   if (is_cold_data(fio->page))
>   return true;
>   if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
>   return true;
> - }
> + } else if (f2fs_is_atomic_file(inode))
> + return true;
>   return false;
>}
>
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index b9d93fd..84ab3ff 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -622,7 +622,8 @@ static void move_data_block(struct inode *inode, 
> block_t bidx,
>   if (!check_valid_map(F2FS_I_SB(inode), segno, off))
>   goto out;
>
> - if (f2fs_is_atomic_file(inode))
> + if (f2fs_is_atomic_file(inode) &&
> + !f2fs_is_commit_atomic_write(inode))
>   goto out;
>
>   if (f2fs_is_pinned_file(inode)) {
> @@ -729,7 +730,8 @@ static void move_data_page(struct inode *inode, 
> block_t bidx, int gc_type,
> 

Re: [PATCH 1/5] backlight: lp8788: document sysfs attributes

[Aishwarya Pant]

On Thu, Feb 01, 2018 at 11:36:04AM +, Daniel Thompson wrote:
> On Wed, Jan 31, 2018 at 01:51:21PM +0200, Jani Nikula wrote:
> > On Wed, 31 Jan 2018, Daniel Thompson  wrote:
> > > On Fri, Jan 26, 2018 at 08:20:08PM +0530, Aishwarya Pant wrote:
> > >> Add documentation for sysfs interfaces of lp8788 backlight driver by
> > >> looking through the code and the git commit history.
> > >> 
> > >> Signed-off-by: Aishwarya Pant 
> > >> ---
> > >>  Documentation/ABI/testing/sysfs-class-backlight-lp8788 | 10 ++
> > >>  1 file changed, 10 insertions(+)
> > >>  create mode 100644 
> > >> Documentation/ABI/testing/sysfs-class-backlight-lp8788
> > >> 
> > >> diff --git a/Documentation/ABI/testing/sysfs-class-backlight-lp8788 
> > >> b/Documentation/ABI/testing/sysfs-class-backlight-lp8788
> > >> new file mode 100644
> > >> index ..c0e565c8d63d
> > >> --- /dev/null
> > >> +++ b/Documentation/ABI/testing/sysfs-class-backlight-lp8788
> > >> @@ -0,0 +1,10 @@
> > >> +sysfs interface for Texas Instruments lp8788 mfd backlight driver
> > >> +-
> > >> +
> > >> +What:   /sys/class/backlight//bl_ctl_mode
> > >> +Date:   Feb, 2013
> > >> +KernelVersion:  v3.10
> > >> +Contact:Milo Kim 
> > >> +Description:
> > >> +(RO) Displays whether the brightness is controlled by 
> > >> the PWM
> > >> +input("PWM based") or the I2C register("Register 
> > >> based").
> > >
> > > I rather dislike drivers with this type of "bonus" sysfs controls. I'm
> > > struggling to come up with any reason why the userspace would want to
> > > read this control (and I think bl_ctl_mode gets the fewest hits after
> > > searching with google hits of any search I've tried) . It looks to me 
> > > like this is debug information that should never have gone into sysfs 
> > > at all.
> > 
> > Agreed. I think the same holds for the other extra sysfs attributes. At
> > worst, having these prevents the backlight class from adding the names
> > later on, which is just backwards.
> 
> The problem is that they do exist...
> 
> For controls which appear to be misplaced debug attributes I think I am
> happy to nuke the values entirely. It is extremely improbable that any
> userspace will notice.
> 
> Unfortunately some of the controls look like they could be poked by an
> custom userspace so I'm quite so confident about nuking these ones...and if we
> don't nuke we should document (so thanks Aishwarya!). 
> 

Hi

Thanks for reviewing. Should I take it to assume that we would like to keep the
debug-like attributes in documentation for now?

Aishwarya

> 
> Daniel.

Re: [PATCH 1/5] backlight: lp8788: document sysfs attributes

[Aishwarya Pant]

On Thu, Feb 01, 2018 at 11:36:04AM +, Daniel Thompson wrote:
> On Wed, Jan 31, 2018 at 01:51:21PM +0200, Jani Nikula wrote:
> > On Wed, 31 Jan 2018, Daniel Thompson  wrote:
> > > On Fri, Jan 26, 2018 at 08:20:08PM +0530, Aishwarya Pant wrote:
> > >> Add documentation for sysfs interfaces of lp8788 backlight driver by
> > >> looking through the code and the git commit history.
> > >> 
> > >> Signed-off-by: Aishwarya Pant 
> > >> ---
> > >>  Documentation/ABI/testing/sysfs-class-backlight-lp8788 | 10 ++
> > >>  1 file changed, 10 insertions(+)
> > >>  create mode 100644 
> > >> Documentation/ABI/testing/sysfs-class-backlight-lp8788
> > >> 
> > >> diff --git a/Documentation/ABI/testing/sysfs-class-backlight-lp8788 
> > >> b/Documentation/ABI/testing/sysfs-class-backlight-lp8788
> > >> new file mode 100644
> > >> index ..c0e565c8d63d
> > >> --- /dev/null
> > >> +++ b/Documentation/ABI/testing/sysfs-class-backlight-lp8788
> > >> @@ -0,0 +1,10 @@
> > >> +sysfs interface for Texas Instruments lp8788 mfd backlight driver
> > >> +-
> > >> +
> > >> +What:   /sys/class/backlight//bl_ctl_mode
> > >> +Date:   Feb, 2013
> > >> +KernelVersion:  v3.10
> > >> +Contact:Milo Kim 
> > >> +Description:
> > >> +(RO) Displays whether the brightness is controlled by 
> > >> the PWM
> > >> +input("PWM based") or the I2C register("Register 
> > >> based").
> > >
> > > I rather dislike drivers with this type of "bonus" sysfs controls. I'm
> > > struggling to come up with any reason why the userspace would want to
> > > read this control (and I think bl_ctl_mode gets the fewest hits after
> > > searching with google hits of any search I've tried) . It looks to me 
> > > like this is debug information that should never have gone into sysfs 
> > > at all.
> > 
> > Agreed. I think the same holds for the other extra sysfs attributes. At
> > worst, having these prevents the backlight class from adding the names
> > later on, which is just backwards.
> 
> The problem is that they do exist...
> 
> For controls which appear to be misplaced debug attributes I think I am
> happy to nuke the values entirely. It is extremely improbable that any
> userspace will notice.
> 
> Unfortunately some of the controls look like they could be poked by an
> custom userspace so I'm quite so confident about nuking these ones...and if we
> don't nuke we should document (so thanks Aishwarya!). 
> 

Hi

Thanks for reviewing. Should I take it to assume that we would like to keep the
debug-like attributes in documentation for now?

Aishwarya

> 
> Daniel.

Re: [PATCH v4 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

[Knut Omang]

On Mon, 2018-02-05 at 16:03 +0900, Masahiro Yamada wrote:
> 2018-02-05 15:41 GMT+09:00 Knut Omang :
> > On Fri, 2018-01-19 at 11:14 +0100, Knut Omang wrote:
> >> Add scripts/runchecks which has generic support for running
> >> checker tools in a convenient and user friendly way that
> >> the author hopes can contribute to rein in issues detected
> >> by these tools in a manageable and convenient way.
> >>
> >> scripts/runchecks provides the following basic functionality:
> >>
> >> * Makes it possible to selectively suppress output from individual
> >>   checks on a per file or per subsystem basis.
> >> * Unifies output and suppression input from different tools
> >>   by providing a single unified syntax and presentation for the
> >>   underlying tools in the style of "scripts/checkpatch.pl --show-types".
> >> * Allows selective run of one, or more (or all) configured tools
> >>   for each file.
> >>
> >> In the Makefile system, the sparse specific setup has been replaced
> >> by setup for runchecks.
> >
> > Hi all,
> >
> > - Anything more I can/need to do to bring this forward?
> > - Any quiet concerns?
> >
> > I realize it is a subsystem crossing change,
> 
> Is it?  Only Kbuild this is related to.

Ok, I see!

> > and a lot going on elsewhere,
> > nevertheless I believe this is a time saver in the slightly longer run,
> > as it allows automation of checking, even without a "perfect"
> > code base to begin with.
> >
> 
> Sorry for the delay.

I understand, no problem - just was afraid it was about to get lost 
in between subsystems,

> I have not been able to find time to dive into the detail yet.
> (Actually, I tried to do that for v2 or v3, where Python code was so dirty,
> then consumed my time to figure out what the code was trying to do)

Hopefully v4 is cleaner from a Python code style point of view at least,
but let me know if you have any particular part of the code in mind wrt 
readability. Also hopefully the docs should be of help.

> I find my concern here:
> https://lkml.org/lkml/2018/1/5/497

I believe I have addressed the issues there in v4.

> Anyway, I will take a look again when I find some time.
> You do not need to take care of the detail until I request to do so.

Ok, thanks a lot for your time and the quick response now!

Best regards,
Knut

Re: [PATCH v4 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

[Knut Omang]

On Mon, 2018-02-05 at 16:03 +0900, Masahiro Yamada wrote:
> 2018-02-05 15:41 GMT+09:00 Knut Omang :
> > On Fri, 2018-01-19 at 11:14 +0100, Knut Omang wrote:
> >> Add scripts/runchecks which has generic support for running
> >> checker tools in a convenient and user friendly way that
> >> the author hopes can contribute to rein in issues detected
> >> by these tools in a manageable and convenient way.
> >>
> >> scripts/runchecks provides the following basic functionality:
> >>
> >> * Makes it possible to selectively suppress output from individual
> >>   checks on a per file or per subsystem basis.
> >> * Unifies output and suppression input from different tools
> >>   by providing a single unified syntax and presentation for the
> >>   underlying tools in the style of "scripts/checkpatch.pl --show-types".
> >> * Allows selective run of one, or more (or all) configured tools
> >>   for each file.
> >>
> >> In the Makefile system, the sparse specific setup has been replaced
> >> by setup for runchecks.
> >
> > Hi all,
> >
> > - Anything more I can/need to do to bring this forward?
> > - Any quiet concerns?
> >
> > I realize it is a subsystem crossing change,
> 
> Is it?  Only Kbuild this is related to.

Ok, I see!

> > and a lot going on elsewhere,
> > nevertheless I believe this is a time saver in the slightly longer run,
> > as it allows automation of checking, even without a "perfect"
> > code base to begin with.
> >
> 
> Sorry for the delay.

I understand, no problem - just was afraid it was about to get lost 
in between subsystems,

> I have not been able to find time to dive into the detail yet.
> (Actually, I tried to do that for v2 or v3, where Python code was so dirty,
> then consumed my time to figure out what the code was trying to do)

Hopefully v4 is cleaner from a Python code style point of view at least,
but let me know if you have any particular part of the code in mind wrt 
readability. Also hopefully the docs should be of help.

> I find my concern here:
> https://lkml.org/lkml/2018/1/5/497

I believe I have addressed the issues there in v4.

> Anyway, I will take a look again when I find some time.
> You do not need to take care of the detail until I request to do so.

Ok, thanks a lot for your time and the quick response now!

Best regards,
Knut

Re: [PATCH 2/2] KVM: X86: Add per-VM no-HLT-exiting capability

[Wanpeng Li]

2018-02-03 3:02 GMT+08:00 Radim Krčmář :
> 2018-02-01 23:11-0800, Wanpeng Li:
>> From: Wanpeng Li 
>>
>> If host CPUs are dedicated to a VM, we can avoid VM exits on HLT.
>> This patch adds the per-VM non-HLT-exiting capability.
>>
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Signed-off-by: Wanpeng Li 
>> ---
>
> SMM handling needs more work: I think we should vmx_clear_hlt() upon SMI
> and RSM needs to implement auto halt restart (AMD might differ).

Do it in v2.

>
> And also look if we don't need vmx_clear_hlt() around INIT handling,

You are right, the guest stuck after utilizing system_reset command in
qemu monitor w/o vmx_clear_hlt() around INIT handling, fix it in v2.

Regards,
Wanpeng Li

Re: [PATCH 2/2] KVM: X86: Add per-VM no-HLT-exiting capability

[Wanpeng Li]

2018-02-03 3:02 GMT+08:00 Radim Krčmář :
> 2018-02-01 23:11-0800, Wanpeng Li:
>> From: Wanpeng Li 
>>
>> If host CPUs are dedicated to a VM, we can avoid VM exits on HLT.
>> This patch adds the per-VM non-HLT-exiting capability.
>>
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Signed-off-by: Wanpeng Li 
>> ---
>
> SMM handling needs more work: I think we should vmx_clear_hlt() upon SMI
> and RSM needs to implement auto halt restart (AMD might differ).

Do it in v2.

>
> And also look if we don't need vmx_clear_hlt() around INIT handling,

You are right, the guest stuck after utilizing system_reset command in
qemu monitor w/o vmx_clear_hlt() around INIT handling, fix it in v2.

Regards,
Wanpeng Li

Re: [PATCH] Documentation/ABI: update infiniband sysfs interfaces

[Aishwarya Pant]

On Thu, Feb 01, 2018 at 12:48:18PM -0500, Hal Rosenstock wrote:
> On 2/1/2018 8:32 AM, Aishwarya Pant wrote:
> > Add documentation for core and hardware specific infiniband interfaces.
> > The descriptions have been collected from git commit logs, reading
> > through code and data sheets. Some drivers have incomplete doc and are
> > annotated with the comment '[to be documented]'.
> > 
> > Signed-off-by: Aishwarya Pant 
> > ---
> >  Documentation/ABI/testing/sysfs-class-infiniband | 755 
> > +++
> >  1 file changed, 755 insertions(+)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-class-infiniband 
> > b/Documentation/ABI/testing/sysfs-class-infiniband
> > index a86abe66a316..2e150169633b 100644
> > --- a/Documentation/ABI/testing/sysfs-class-infiniband
> > +++ b/Documentation/ABI/testing/sysfs-class-infiniband
> > @@ -1,3 +1,194 @@
> > +sysfs interface common for all infiniband devices
> > +-
> > +
> > +What:  /sys/class/infiniband//node_type
> > +What:  /sys/class/infiniband//node_guid
> > +What:  /sys/class/infiniband//sys_image_guid
> > +Date:  Apr, 2005
> > +KernelVersion: v2.6.12
> > +Contact:   linux-r...@vger.kernel.org
> > +Description:
> > +   node_type:  (RO) Node type (CA, RNIC, usNIC, usNIC UDP,
> > +   switch or router)
> > +
> > +   node_guid:  (RO) Node GUID
> > +
> > +   sys_image_guid: (RO) System image GUID
> > +
> > +
> > +What:  /sys/class/infiniband//node_desc
> > +Date:  Feb, 2006
> > +KernelVersion: v2.6.17
> > +Contact:   linux-r...@vger.kernel.org
> > +Description:
> > +   (RW) Update the node description with information such as the
> > +   node's hostname, so that IB network management software can tie
> > +   its view to the real world.
> > +
> > +
> > +What:  /sys/class/infiniband//fw_ver
> > +Date:  Jun, 2016
> > +KernelVersion: v4.10
> > +Contact:   linux-r...@vger.kernel.org
> > +Description:
> > +   (RO) Display firmware version
> > +
> > +
> > +What:  /sys/class/infiniband//ports//lid
> > +What:  /sys/class/infiniband//ports//rate
> > +What:  
> > /sys/class/infiniband//ports//lid_mask_count
> > +What:  /sys/class/infiniband//ports//sm_sl
> > +What:  /sys/class/infiniband//ports//sm_lid
> > +What:  /sys/class/infiniband//ports//state
> > +What:  
> > /sys/class/infiniband//ports//phys_state
> > +What:  /sys/class/infiniband//ports//cap_mask
> > +Date:  Apr, 2005
> > +KernelVersion: v2.6.12
> > +Contact:   linux-r...@vger.kernel.org
> > +Description:
> > +
> > +   lid:(RO) Port LID
> > +
> > +   rate:   (RO) Port data rate (active width * active
> > +   speed)
> > +
> > +   lid_mask_count: (RO) Port LID mask count
> > +
> > +   sm_slL  (RO) Subnet manager SL for port's subnet
> 
> Typo sm_sl:
> 
> > +
> > +   sm_lid: (RO) Subnet manager LID for port's subnet
> > +
> > +   state:  (RO) Port state (DOWN, INIT, ARMED, ACTIVE or
> > +   ACTIVE_DEFER> +
> > +   phys_state: (RO) Port physical state (Sleep, Polling,
> > +   LinkUp, etc)
> > +
> > +   cap_mask:   (RO) Port capability mask
> 
> 2 bits here are settable: IsCommunicationManagementSupported and IsSM.

Hi

Sorry, I don't quite understand this. cap_mask is a read only value which
indicates the supported functions. So the two bits-
IsCommunicationManagementSupported and IsSM, should not be setttable?

Aishwarya

Re: [PATCH] Documentation/ABI: update infiniband sysfs interfaces

[Aishwarya Pant]

On Thu, Feb 01, 2018 at 12:48:18PM -0500, Hal Rosenstock wrote:
> On 2/1/2018 8:32 AM, Aishwarya Pant wrote:
> > Add documentation for core and hardware specific infiniband interfaces.
> > The descriptions have been collected from git commit logs, reading
> > through code and data sheets. Some drivers have incomplete doc and are
> > annotated with the comment '[to be documented]'.
> > 
> > Signed-off-by: Aishwarya Pant 
> > ---
> >  Documentation/ABI/testing/sysfs-class-infiniband | 755 
> > +++
> >  1 file changed, 755 insertions(+)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-class-infiniband 
> > b/Documentation/ABI/testing/sysfs-class-infiniband
> > index a86abe66a316..2e150169633b 100644
> > --- a/Documentation/ABI/testing/sysfs-class-infiniband
> > +++ b/Documentation/ABI/testing/sysfs-class-infiniband
> > @@ -1,3 +1,194 @@
> > +sysfs interface common for all infiniband devices
> > +-
> > +
> > +What:  /sys/class/infiniband//node_type
> > +What:  /sys/class/infiniband//node_guid
> > +What:  /sys/class/infiniband//sys_image_guid
> > +Date:  Apr, 2005
> > +KernelVersion: v2.6.12
> > +Contact:   linux-r...@vger.kernel.org
> > +Description:
> > +   node_type:  (RO) Node type (CA, RNIC, usNIC, usNIC UDP,
> > +   switch or router)
> > +
> > +   node_guid:  (RO) Node GUID
> > +
> > +   sys_image_guid: (RO) System image GUID
> > +
> > +
> > +What:  /sys/class/infiniband//node_desc
> > +Date:  Feb, 2006
> > +KernelVersion: v2.6.17
> > +Contact:   linux-r...@vger.kernel.org
> > +Description:
> > +   (RW) Update the node description with information such as the
> > +   node's hostname, so that IB network management software can tie
> > +   its view to the real world.
> > +
> > +
> > +What:  /sys/class/infiniband//fw_ver
> > +Date:  Jun, 2016
> > +KernelVersion: v4.10
> > +Contact:   linux-r...@vger.kernel.org
> > +Description:
> > +   (RO) Display firmware version
> > +
> > +
> > +What:  /sys/class/infiniband//ports//lid
> > +What:  /sys/class/infiniband//ports//rate
> > +What:  
> > /sys/class/infiniband//ports//lid_mask_count
> > +What:  /sys/class/infiniband//ports//sm_sl
> > +What:  /sys/class/infiniband//ports//sm_lid
> > +What:  /sys/class/infiniband//ports//state
> > +What:  
> > /sys/class/infiniband//ports//phys_state
> > +What:  /sys/class/infiniband//ports//cap_mask
> > +Date:  Apr, 2005
> > +KernelVersion: v2.6.12
> > +Contact:   linux-r...@vger.kernel.org
> > +Description:
> > +
> > +   lid:(RO) Port LID
> > +
> > +   rate:   (RO) Port data rate (active width * active
> > +   speed)
> > +
> > +   lid_mask_count: (RO) Port LID mask count
> > +
> > +   sm_slL  (RO) Subnet manager SL for port's subnet
> 
> Typo sm_sl:
> 
> > +
> > +   sm_lid: (RO) Subnet manager LID for port's subnet
> > +
> > +   state:  (RO) Port state (DOWN, INIT, ARMED, ACTIVE or
> > +   ACTIVE_DEFER> +
> > +   phys_state: (RO) Port physical state (Sleep, Polling,
> > +   LinkUp, etc)
> > +
> > +   cap_mask:   (RO) Port capability mask
> 
> 2 bits here are settable: IsCommunicationManagementSupported and IsSM.

Hi

Sorry, I don't quite understand this. cap_mask is a read only value which
indicates the supported functions. So the two bits-
IsCommunicationManagementSupported and IsSM, should not be setttable?

Aishwarya

Re: [GIT PULL tools] Linux kernel memory model

[Paul E. McKenney]

On Sun, Feb 04, 2018 at 11:37:59AM -0500, Alan Stern wrote:
> On Sun, 4 Feb 2018, Paul E. McKenney wrote:
> 
> > --- a/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
> > +++ b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
> > @@ -1,5 +1,11 @@
> >  C CoRW+poonceonce+Once
> >  
> > +(*
> > + * Test of read-write coherence, that is, whether or not a read from a
> > + * given variable followed by a write to that same variable are ordered.
> 
> The syntax of this sentence is a little tortured.  Suggestion:
> 
>   ... whether or not a read from a given variable and a later
>   write to that same variable are ordered.
> 
> > + * This should be ordered, that is, this test should be forbidden.
> 
> s/This/They/

Good catches, both changed as suggested.

> > --- a/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> > +++ b/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> > @@ -1,5 +1,11 @@
> >  C CoWR+poonceonce+Once
> >  
> > +(*
> > + * Test of write-read coherence, that is, whether or not a write to a
> > + * given variable followed by a read from that same variable are ordered.
> 
> Same syntax issue as above.

Analogous fixed applied!

> > --- a/tools/memory-model/litmus-tests/ISA2+poonceonces.litmus
> > +++ b/tools/memory-model/litmus-tests/ISA2+poonceonces.litmus
> > @@ -1,5 +1,13 @@
> >  C ISA2+poonceonces
> >  
> > +(*
> > + * Given a release-acquire chain ordering the first process's store
> > + * against the last process's load, is ordering preserved if all of the
> > + * smp_store_release() invocations be replaced by WRITE_ONCE() and all
> 
> s/be/are/
> 
> > + * of the smp_load_acquire() invocations be replaced by READ_ONCE()?
> 
> s/be/are/

Good eyes, fixed!

> > --- a/tools/memory-model/litmus-tests/LB+ctrlonceonce+mbonceonce.litmus
> > +++ b/tools/memory-model/litmus-tests/LB+ctrlonceonce+mbonceonce.litmus
> > @@ -1,5 +1,14 @@
> >  C LB+ctrlonceonce+mbonceonce
> >  
> > +(*
> > + * This litmus test demonstrates that lightweight ordering suffices for
> > + * the load-buffering pattern, in other words, preventing all processes
> > + * reading from the preceding process's write.  In this example, the
> > + * combination of a control dependency and a full memory barrier are to do
> 
> s/are to/are enough to/

Ditto!

> > --- a/tools/memory-model/litmus-tests/MP+polocks.litmus
> > +++ b/tools/memory-model/litmus-tests/MP+polocks.litmus
> > @@ -1,5 +1,14 @@
> >  C MP+polocks
> >  
> > +(*
> > + * This litmus test demonstrates how lock acquisitions and releases can
> > + * stand in for smp_load_acquire() and smp_store_release(), respectively.
> > + * In other words, when holding a given lock (or indeed after relaasing a
> 
> s/relaasing/releasing/
> 
> > + * given lock), a CPU is not only guaranteed to see the accesses that other
> > + * CPOs made while previously holding that lock, it are also guaranteed
> 
> s/CPO/CPU/
> s/are/is/

Andrea beat you to the first two of these three, but fixed.  ;-)

> > + * to see all prior accesses by those other CPUs.
> 
> Doesn't say whether the test should be allowed.  This is true of several
> other litmus tests too.

Added the "Forbidden".

You know, I should use the machine-generated syntax that my scripts
recognize, shouldn't I?  Doing that as well.

> > --- a/tools/memory-model/litmus-tests/MP+porevlocks.litmus
> > +++ b/tools/memory-model/litmus-tests/MP+porevlocks.litmus
> > @@ -1,5 +1,14 @@
> >  C MP+porevlocks
> >  
> > +(*
> > + * This litmus test demonstrates how lock acquisitions and releases can
> > + * stand in for smp_load_acquire() and smp_store_release(), respectively.
> > + * In other words, when holding a given lock (or indeed after relaasing a
> 
> s/relaasing/releasing
> 
> > + * given lock), a CPU is not only guaranteed to see the accesses that other
> > + * CPOs made while previously holding that lock, it are also guaranteed
> 
> s/CPO/CPU/
> s/are/is/

Fixed!

> > --- a/tools/memory-model/litmus-tests/R+poonceonces.litmus
> > +++ b/tools/memory-model/litmus-tests/R+poonceonces.litmus
> > @@ -1,5 +1,11 @@
> >  C R+poonceonces
> >  
> > +(*
> > + * This is the unordered (via smp_mb()) version of one of the classic
> 
> Does "unordered (via smp_mb())" mean that the test uses smp_mb() to
> "unorder" the accesses, or does it mean that the test doesn't use smp_mb()
> to order the accesses?

That is a bit ambiguous...  Though I would be interested in seeing a
litmus test that really did use smp_mb() to unorder the accesses!

How about the following?

* Result: Sometimes
*
* This is the unordered (thus lacking smp_mb()) version of one of the 
* classic counterintuitive litmus tests that illustrates the effects of
* store propagation delays.

> > --- a/tools/memory-model/litmus-tests/S+poonceonces.litmus
> > +++ b/tools/memory-model/litmus-tests/S+poonceonces.litmus
> > @@ -1,5 +1,13 @@
> >  C S+poonceonces
> >  
> > +(*
> > + * Starting with a two-process 

Re: [GIT PULL tools] Linux kernel memory model

[Paul E. McKenney]

On Sun, Feb 04, 2018 at 11:37:59AM -0500, Alan Stern wrote:
> On Sun, 4 Feb 2018, Paul E. McKenney wrote:
> 
> > --- a/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
> > +++ b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
> > @@ -1,5 +1,11 @@
> >  C CoRW+poonceonce+Once
> >  
> > +(*
> > + * Test of read-write coherence, that is, whether or not a read from a
> > + * given variable followed by a write to that same variable are ordered.
> 
> The syntax of this sentence is a little tortured.  Suggestion:
> 
>   ... whether or not a read from a given variable and a later
>   write to that same variable are ordered.
> 
> > + * This should be ordered, that is, this test should be forbidden.
> 
> s/This/They/

Good catches, both changed as suggested.

> > --- a/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> > +++ b/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> > @@ -1,5 +1,11 @@
> >  C CoWR+poonceonce+Once
> >  
> > +(*
> > + * Test of write-read coherence, that is, whether or not a write to a
> > + * given variable followed by a read from that same variable are ordered.
> 
> Same syntax issue as above.

Analogous fixed applied!

> > --- a/tools/memory-model/litmus-tests/ISA2+poonceonces.litmus
> > +++ b/tools/memory-model/litmus-tests/ISA2+poonceonces.litmus
> > @@ -1,5 +1,13 @@
> >  C ISA2+poonceonces
> >  
> > +(*
> > + * Given a release-acquire chain ordering the first process's store
> > + * against the last process's load, is ordering preserved if all of the
> > + * smp_store_release() invocations be replaced by WRITE_ONCE() and all
> 
> s/be/are/
> 
> > + * of the smp_load_acquire() invocations be replaced by READ_ONCE()?
> 
> s/be/are/

Good eyes, fixed!

> > --- a/tools/memory-model/litmus-tests/LB+ctrlonceonce+mbonceonce.litmus
> > +++ b/tools/memory-model/litmus-tests/LB+ctrlonceonce+mbonceonce.litmus
> > @@ -1,5 +1,14 @@
> >  C LB+ctrlonceonce+mbonceonce
> >  
> > +(*
> > + * This litmus test demonstrates that lightweight ordering suffices for
> > + * the load-buffering pattern, in other words, preventing all processes
> > + * reading from the preceding process's write.  In this example, the
> > + * combination of a control dependency and a full memory barrier are to do
> 
> s/are to/are enough to/

Ditto!

> > --- a/tools/memory-model/litmus-tests/MP+polocks.litmus
> > +++ b/tools/memory-model/litmus-tests/MP+polocks.litmus
> > @@ -1,5 +1,14 @@
> >  C MP+polocks
> >  
> > +(*
> > + * This litmus test demonstrates how lock acquisitions and releases can
> > + * stand in for smp_load_acquire() and smp_store_release(), respectively.
> > + * In other words, when holding a given lock (or indeed after relaasing a
> 
> s/relaasing/releasing/
> 
> > + * given lock), a CPU is not only guaranteed to see the accesses that other
> > + * CPOs made while previously holding that lock, it are also guaranteed
> 
> s/CPO/CPU/
> s/are/is/

Andrea beat you to the first two of these three, but fixed.  ;-)

> > + * to see all prior accesses by those other CPUs.
> 
> Doesn't say whether the test should be allowed.  This is true of several
> other litmus tests too.

Added the "Forbidden".

You know, I should use the machine-generated syntax that my scripts
recognize, shouldn't I?  Doing that as well.

> > --- a/tools/memory-model/litmus-tests/MP+porevlocks.litmus
> > +++ b/tools/memory-model/litmus-tests/MP+porevlocks.litmus
> > @@ -1,5 +1,14 @@
> >  C MP+porevlocks
> >  
> > +(*
> > + * This litmus test demonstrates how lock acquisitions and releases can
> > + * stand in for smp_load_acquire() and smp_store_release(), respectively.
> > + * In other words, when holding a given lock (or indeed after relaasing a
> 
> s/relaasing/releasing
> 
> > + * given lock), a CPU is not only guaranteed to see the accesses that other
> > + * CPOs made while previously holding that lock, it are also guaranteed
> 
> s/CPO/CPU/
> s/are/is/

Fixed!

> > --- a/tools/memory-model/litmus-tests/R+poonceonces.litmus
> > +++ b/tools/memory-model/litmus-tests/R+poonceonces.litmus
> > @@ -1,5 +1,11 @@
> >  C R+poonceonces
> >  
> > +(*
> > + * This is the unordered (via smp_mb()) version of one of the classic
> 
> Does "unordered (via smp_mb())" mean that the test uses smp_mb() to
> "unorder" the accesses, or does it mean that the test doesn't use smp_mb()
> to order the accesses?

That is a bit ambiguous...  Though I would be interested in seeing a
litmus test that really did use smp_mb() to unorder the accesses!

How about the following?

* Result: Sometimes
*
* This is the unordered (thus lacking smp_mb()) version of one of the 
* classic counterintuitive litmus tests that illustrates the effects of
* store propagation delays.

> > --- a/tools/memory-model/litmus-tests/S+poonceonces.litmus
> > +++ b/tools/memory-model/litmus-tests/S+poonceonces.litmus
> > @@ -1,5 +1,13 @@
> >  C S+poonceonces
> >  
> > +(*
> > + * Starting with a two-process 

Re: [PATCH 01/14] dt-bindings: Document STM32MP1 Reset Clock Controller (RCC) bindings

[Gabriel FERNANDEZ]

On 02/05/2018 07:09 AM, Rob Herring wrote:
> On Fri, Feb 02, 2018 at 03:03:29PM +0100, gabriel.fernan...@st.com wrote:
>> From: Gabriel Fernandez 
>>
>> The RCC block is responsible of the management of the clock and reset
>> generation for the complete circuit.
>>
>> Signed-off-by: Gabriel Fernandez 
>> ---
>>   .../devicetree/bindings/mfd/st,stm32-rcc.txt   | 85 
>> ++
>>   1 file changed, 85 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt 
>> b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> new file mode 100644
>> index 000..28017a1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> @@ -0,0 +1,85 @@
>> +STMicroelectronics STM32 Peripheral Reset Clock Controller
>> +==
>> +
>> +The RCC IP is both a reset and a clock controller.
>> +
>> +Please also refer to reset.txt for common reset controller binding usage.
>> +
>> +Please also refer to clock-bindings.txt for common clock controller
>> +binding usage.
>> +
>> +
>> +Required properties:
>> +- compatible: "simple-mfd", "syscon"
>
>> +- reg: should be register base and length as documented in the datasheet
>> +
>> +- Sub-nodes:
>> +  - compatible: "st,stm32mp1-rcc-clk"
>> +- #clock-cells: 1, device nodes should specify the clock in their
>> +  "clocks" property, containing a phandle to the clock device node,
>> +  an index specifying the clock to use.
>> +
>> +  - compatible: "st,stm32mp1-rcc-rst"
>> +- #reset-cells: Shall be 1
>> +
>> +Example:
>> +rcc: rcc@5000 {
>> +compatible = "syscon", "simple-mfd";
>> +reg = <0x5000 0x1000>;
>> +
>> +rcc_clk: rcc-clk@5000 {
>> +#clock-cells = <1>;
>> +compatible = "st,stm32mp1-rcc-clk";
>> +};
>> +
>> +rcc_rst: rcc-reset@5000 {
> You should not have the same unit-address twice.
i can change if you want into:

         rcc: rcc@5000 {
             compatible = "syscon", "simple-mfd";

             reg = <0x5000 0x1000>;

             rcc_clk: rcc-clk {
                 #clock-cells = <1>;
                 compatible = "st,stm32mp1-rcc-clk";
             };

             rcc_rst: rcc-reset {
                 #reset-cells = <1>;
                 compatible = "st,stm32mp1-rcc-rst";
             };
BR
Gabriel

> IMO, this should just be:
>
>   rcc: rcc@5000 {
>   compatible = "st-stm32mp1-rcc";
>   reg = <0x5000 0x1000>;
>   #clock-cells = <1>;
>   #reset-cells = <1>;
>   };
>
> There's no reason a node can't provide more than 1 function.
>
>
>> +#reset-cells = <1>;
>> +compatible = "st,stm32mp1-rcc-rst";
>> +};
>> +};
>> +
>> +Specifying clocks
>> +=
>> +
>> +All available clocks are defined as preprocessor macros in
>> +dt-bindings/clock/stm32mp1-clks.h header and can be used in device
>> +tree sources.
>> +
>> +Example:
>> +
>> +/* Accessing DMA1 clock */
>> +... {
>> +clocks = <_clk DMA1>
>> +};
>> +
>> +/* Accessing SPI6 kernel clock */
>> +... {
>> +clocks = <_clk SPI6_K>
>> +};
> Other than the path to header, the clock binding explains all this. No
> need to duplicate here.
>
>> +
>> +Specifying softreset control of devices
>> +===
>> +
>> +Device nodes should specify the reset channel required in their "resets"
>> +property, containing a phandle to the reset device node and an index 
>> specifying
>> +which channel to use.
>> +The index is the bit number within the RCC registers bank, starting from RCC
>> +base address.
>> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
>> +Where bit_offset is the bit offset within the register.
>> +
>> +For example on STM32MP1, for LTDC reset:
>> + ltdc = APB4_RSTSETR_offset / 4 * 32 + LTDC_bit_offset
>> +  = 0x180 / 4 * 32 + 0 = 3072
>> +
>> +The list of valid indices for STM32MP1 is available in:
>> +include/dt-bindings/reset-controller/stm32mp1-resets.h
>> +
>> +This file implements defines like:
>> +#define LTDC_R  3072
>> +
>> +example:
>> +
>> +ltdc {
>> +resets = <_rst LTDC_R>;
>> +};
>> -- 
>> 1.9.1
>>

Re: [PATCH 01/14] dt-bindings: Document STM32MP1 Reset Clock Controller (RCC) bindings

[Gabriel FERNANDEZ]

On 02/05/2018 07:09 AM, Rob Herring wrote:
> On Fri, Feb 02, 2018 at 03:03:29PM +0100, gabriel.fernan...@st.com wrote:
>> From: Gabriel Fernandez 
>>
>> The RCC block is responsible of the management of the clock and reset
>> generation for the complete circuit.
>>
>> Signed-off-by: Gabriel Fernandez 
>> ---
>>   .../devicetree/bindings/mfd/st,stm32-rcc.txt   | 85 
>> ++
>>   1 file changed, 85 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt 
>> b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> new file mode 100644
>> index 000..28017a1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> @@ -0,0 +1,85 @@
>> +STMicroelectronics STM32 Peripheral Reset Clock Controller
>> +==
>> +
>> +The RCC IP is both a reset and a clock controller.
>> +
>> +Please also refer to reset.txt for common reset controller binding usage.
>> +
>> +Please also refer to clock-bindings.txt for common clock controller
>> +binding usage.
>> +
>> +
>> +Required properties:
>> +- compatible: "simple-mfd", "syscon"
>
>> +- reg: should be register base and length as documented in the datasheet
>> +
>> +- Sub-nodes:
>> +  - compatible: "st,stm32mp1-rcc-clk"
>> +- #clock-cells: 1, device nodes should specify the clock in their
>> +  "clocks" property, containing a phandle to the clock device node,
>> +  an index specifying the clock to use.
>> +
>> +  - compatible: "st,stm32mp1-rcc-rst"
>> +- #reset-cells: Shall be 1
>> +
>> +Example:
>> +rcc: rcc@5000 {
>> +compatible = "syscon", "simple-mfd";
>> +reg = <0x5000 0x1000>;
>> +
>> +rcc_clk: rcc-clk@5000 {
>> +#clock-cells = <1>;
>> +compatible = "st,stm32mp1-rcc-clk";
>> +};
>> +
>> +rcc_rst: rcc-reset@5000 {
> You should not have the same unit-address twice.
i can change if you want into:

         rcc: rcc@5000 {
             compatible = "syscon", "simple-mfd";

             reg = <0x5000 0x1000>;

             rcc_clk: rcc-clk {
                 #clock-cells = <1>;
                 compatible = "st,stm32mp1-rcc-clk";
             };

             rcc_rst: rcc-reset {
                 #reset-cells = <1>;
                 compatible = "st,stm32mp1-rcc-rst";
             };
BR
Gabriel

> IMO, this should just be:
>
>   rcc: rcc@5000 {
>   compatible = "st-stm32mp1-rcc";
>   reg = <0x5000 0x1000>;
>   #clock-cells = <1>;
>   #reset-cells = <1>;
>   };
>
> There's no reason a node can't provide more than 1 function.
>
>
>> +#reset-cells = <1>;
>> +compatible = "st,stm32mp1-rcc-rst";
>> +};
>> +};
>> +
>> +Specifying clocks
>> +=
>> +
>> +All available clocks are defined as preprocessor macros in
>> +dt-bindings/clock/stm32mp1-clks.h header and can be used in device
>> +tree sources.
>> +
>> +Example:
>> +
>> +/* Accessing DMA1 clock */
>> +... {
>> +clocks = <_clk DMA1>
>> +};
>> +
>> +/* Accessing SPI6 kernel clock */
>> +... {
>> +clocks = <_clk SPI6_K>
>> +};
> Other than the path to header, the clock binding explains all this. No
> need to duplicate here.
>
>> +
>> +Specifying softreset control of devices
>> +===
>> +
>> +Device nodes should specify the reset channel required in their "resets"
>> +property, containing a phandle to the reset device node and an index 
>> specifying
>> +which channel to use.
>> +The index is the bit number within the RCC registers bank, starting from RCC
>> +base address.
>> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
>> +Where bit_offset is the bit offset within the register.
>> +
>> +For example on STM32MP1, for LTDC reset:
>> + ltdc = APB4_RSTSETR_offset / 4 * 32 + LTDC_bit_offset
>> +  = 0x180 / 4 * 32 + 0 = 3072
>> +
>> +The list of valid indices for STM32MP1 is available in:
>> +include/dt-bindings/reset-controller/stm32mp1-resets.h
>> +
>> +This file implements defines like:
>> +#define LTDC_R  3072
>> +
>> +example:
>> +
>> +ltdc {
>> +resets = <_rst LTDC_R>;
>> +};
>> -- 
>> 1.9.1
>>

Re: [PATCHv2 0/8] hw_breakpoint: Breakpoint modification fixes and new modify ioctl

[Jiri Olsa]

PING

thanks,
jirka

On Wed, Nov 29, 2017 at 09:38:45AM +0100, Jiri Olsa wrote:
> hi,
> Milind Chabbi introduced new ioctl interface to change
> live breakpoint [1]. It allows to change its bp_addr,
> bp_len and bp_type throught new ioctl for perf breakpoint
> event.
> 
> We already have a kernel interface for this via 
> modify_user_hw_breakpoint function. This function however
> does not update the breakpoint slot counts.
> 
> So when the same functionality was exposed to user space
> (Milind's change), with simple test program I could put wrong
> slots count on arm server [2] and ended up with no breakpoints
> available on the system. Note it's not an issue on x86, because
> it shares slot single counter for both data and inst types
> (CONFIG_HAVE_MIXED_BREAKPOINTS_REGS).
> 
> This patchset contains my fixes for keeping breakpoint slots
> count updated. On top of it there's Milind's change for new
> _IOC_MODIFY_ATTRIBUTES ioctl interface to change a breakpoint.
> 
> As I mentioned above there're kernel users of
> modify_user_hw_breakpoint function, all ptrace related
> AFAICS, which could got broken.. so cc-ing Oleg ;-)
> 
> I ran gdb and strace tests suites and got same amount of
> skip/fail tests as when I run them on unpatched machine,
> so I assume nothing new got broken.
> 
> It's also available in here:
>   https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>   perf/bp
> 
> v2 changes:
>   - added check for the rest of the perf_event_attr fields
> to be the same as for kernel event
> 
> thanks,
> jirka
> 
> 
> [1] https://marc.info/?l=linux-kernel=151012255331565=2
> [2] https://marc.info/?l=linux-man=151172469807302=2
> ---
> Jiri Olsa (7):
>   hw_breakpoint: Pass bp_type directly as find_slot_idx argument
>   hw_breakpoint: Pass bp_type argument to 
> __reserve_bp_slot|__release_bp_slot
>   hw_breakpoint: Add modify_bp_slot function
>   hw_breakpoint: Factor out __modify_user_hw_breakpoint function
>   hw_breakpoint: Add perf_event_attr fields check in 
> __modify_user_hw_breakpoint
>   perf/core: Move perf_event_attr::sample_max_stack into perf_copy_attr
>   perf tests: Add breakpoint accounting/modify test
> 
> Milind Chabbi (1):
>   perf/core: fast breakpoint modification via _IOC_MODIFY_ATTRIBUTES.
> 
>  include/linux/hw_breakpoint.h |   7 +
>  include/uapi/linux/perf_event.h   |   2 ++
>  kernel/events/core.c  |  53 +--
>  kernel/events/hw_breakpoint.c | 115 
> ---
>  tools/include/uapi/linux/perf_event.h |   2 ++
>  tools/perf/tests/Build|   1 +
>  tools/perf/tests/bp_account.c | 195 
> +
>  tools/perf/tests/builtin-test.c   |   4 +++
>  tools/perf/tests/tests.h  |   1 +
>  9 files changed, 344 insertions(+), 36 deletions(-)
>  create mode 100644 tools/perf/tests/bp_account.c

Re: [PATCHv2 0/8] hw_breakpoint: Breakpoint modification fixes and new modify ioctl

[Jiri Olsa]

PING

thanks,
jirka

On Wed, Nov 29, 2017 at 09:38:45AM +0100, Jiri Olsa wrote:
> hi,
> Milind Chabbi introduced new ioctl interface to change
> live breakpoint [1]. It allows to change its bp_addr,
> bp_len and bp_type throught new ioctl for perf breakpoint
> event.
> 
> We already have a kernel interface for this via 
> modify_user_hw_breakpoint function. This function however
> does not update the breakpoint slot counts.
> 
> So when the same functionality was exposed to user space
> (Milind's change), with simple test program I could put wrong
> slots count on arm server [2] and ended up with no breakpoints
> available on the system. Note it's not an issue on x86, because
> it shares slot single counter for both data and inst types
> (CONFIG_HAVE_MIXED_BREAKPOINTS_REGS).
> 
> This patchset contains my fixes for keeping breakpoint slots
> count updated. On top of it there's Milind's change for new
> _IOC_MODIFY_ATTRIBUTES ioctl interface to change a breakpoint.
> 
> As I mentioned above there're kernel users of
> modify_user_hw_breakpoint function, all ptrace related
> AFAICS, which could got broken.. so cc-ing Oleg ;-)
> 
> I ran gdb and strace tests suites and got same amount of
> skip/fail tests as when I run them on unpatched machine,
> so I assume nothing new got broken.
> 
> It's also available in here:
>   https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>   perf/bp
> 
> v2 changes:
>   - added check for the rest of the perf_event_attr fields
> to be the same as for kernel event
> 
> thanks,
> jirka
> 
> 
> [1] https://marc.info/?l=linux-kernel=151012255331565=2
> [2] https://marc.info/?l=linux-man=151172469807302=2
> ---
> Jiri Olsa (7):
>   hw_breakpoint: Pass bp_type directly as find_slot_idx argument
>   hw_breakpoint: Pass bp_type argument to 
> __reserve_bp_slot|__release_bp_slot
>   hw_breakpoint: Add modify_bp_slot function
>   hw_breakpoint: Factor out __modify_user_hw_breakpoint function
>   hw_breakpoint: Add perf_event_attr fields check in 
> __modify_user_hw_breakpoint
>   perf/core: Move perf_event_attr::sample_max_stack into perf_copy_attr
>   perf tests: Add breakpoint accounting/modify test
> 
> Milind Chabbi (1):
>   perf/core: fast breakpoint modification via _IOC_MODIFY_ATTRIBUTES.
> 
>  include/linux/hw_breakpoint.h |   7 +
>  include/uapi/linux/perf_event.h   |   2 ++
>  kernel/events/core.c  |  53 +--
>  kernel/events/hw_breakpoint.c | 115 
> ---
>  tools/include/uapi/linux/perf_event.h |   2 ++
>  tools/perf/tests/Build|   1 +
>  tools/perf/tests/bp_account.c | 195 
> +
>  tools/perf/tests/builtin-test.c   |   4 +++
>  tools/perf/tests/tests.h  |   1 +
>  9 files changed, 344 insertions(+), 36 deletions(-)
>  create mode 100644 tools/perf/tests/bp_account.c

Re: [PATCH v4 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

[Masahiro Yamada]

2018-02-05 15:41 GMT+09:00 Knut Omang :
> On Fri, 2018-01-19 at 11:14 +0100, Knut Omang wrote:
>> Add scripts/runchecks which has generic support for running
>> checker tools in a convenient and user friendly way that
>> the author hopes can contribute to rein in issues detected
>> by these tools in a manageable and convenient way.
>>
>> scripts/runchecks provides the following basic functionality:
>>
>> * Makes it possible to selectively suppress output from individual
>>   checks on a per file or per subsystem basis.
>> * Unifies output and suppression input from different tools
>>   by providing a single unified syntax and presentation for the
>>   underlying tools in the style of "scripts/checkpatch.pl --show-types".
>> * Allows selective run of one, or more (or all) configured tools
>>   for each file.
>>
>> In the Makefile system, the sparse specific setup has been replaced
>> by setup for runchecks.
>
> Hi all,
>
> - Anything more I can/need to do to bring this forward?
> - Any quiet concerns?
>
> I realize it is a subsystem crossing change,

Is it?  Only Kbuild this is related to.


> and a lot going on elsewhere,
> nevertheless I believe this is a time saver in the slightly longer run,
> as it allows automation of checking, even without a "perfect"
> code base to begin with.
>

Sorry for the delay.

I have not been able to find time to dive into the detail yet.
(Actually, I tried to do that for v2 or v3, where Python code was so dirty,
then consumed my time to figure out what the code was trying to do)


I find my concern here:
https://lkml.org/lkml/2018/1/5/497


Anyway, I will take a look again when I find some time.
You do not need to take care of the detail until I request to do so.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v4 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

[Masahiro Yamada]

2018-02-05 15:41 GMT+09:00 Knut Omang :
> On Fri, 2018-01-19 at 11:14 +0100, Knut Omang wrote:
>> Add scripts/runchecks which has generic support for running
>> checker tools in a convenient and user friendly way that
>> the author hopes can contribute to rein in issues detected
>> by these tools in a manageable and convenient way.
>>
>> scripts/runchecks provides the following basic functionality:
>>
>> * Makes it possible to selectively suppress output from individual
>>   checks on a per file or per subsystem basis.
>> * Unifies output and suppression input from different tools
>>   by providing a single unified syntax and presentation for the
>>   underlying tools in the style of "scripts/checkpatch.pl --show-types".
>> * Allows selective run of one, or more (or all) configured tools
>>   for each file.
>>
>> In the Makefile system, the sparse specific setup has been replaced
>> by setup for runchecks.
>
> Hi all,
>
> - Anything more I can/need to do to bring this forward?
> - Any quiet concerns?
>
> I realize it is a subsystem crossing change,

Is it?  Only Kbuild this is related to.


> and a lot going on elsewhere,
> nevertheless I believe this is a time saver in the slightly longer run,
> as it allows automation of checking, even without a "perfect"
> code base to begin with.
>

Sorry for the delay.

I have not been able to find time to dive into the detail yet.
(Actually, I tried to do that for v2 or v3, where Python code was so dirty,
then consumed my time to figure out what the code was trying to do)


I find my concern here:
https://lkml.org/lkml/2018/1/5/497


Anyway, I will take a look again when I find some time.
You do not need to take care of the detail until I request to do so.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 02/14] dt-bindings: clock: add STM32MP1 clocks

[Gabriel FERNANDEZ]

On 02/05/2018 07:09 AM, Rob Herring wrote:
> On Fri, Feb 02, 2018 at 03:03:30PM +0100, gabriel.fernan...@st.com wrote:
>> From: Gabriel Fernandez 
>>
>> This patch adds the clock binding entry for STM32MP1
>>
>> Signed-off-by: Gabriel Fernandez 
>> ---
>>   include/dt-bindings/clock/stm32mp1-clks.h | 248 
>> ++
>>   1 file changed, 248 insertions(+)
>>   create mode 100644 include/dt-bindings/clock/stm32mp1-clks.h
> You can squash this into the previous patch.
Ok Thanks!

BR
Gabriel

Re: [PATCH 02/14] dt-bindings: clock: add STM32MP1 clocks

[Gabriel FERNANDEZ]

On 02/05/2018 07:09 AM, Rob Herring wrote:
> On Fri, Feb 02, 2018 at 03:03:30PM +0100, gabriel.fernan...@st.com wrote:
>> From: Gabriel Fernandez 
>>
>> This patch adds the clock binding entry for STM32MP1
>>
>> Signed-off-by: Gabriel Fernandez 
>> ---
>>   include/dt-bindings/clock/stm32mp1-clks.h | 248 
>> ++
>>   1 file changed, 248 insertions(+)
>>   create mode 100644 include/dt-bindings/clock/stm32mp1-clks.h
> You can squash this into the previous patch.
Ok Thanks!

BR
Gabriel

Re: [PATCH 01/14] dt-bindings: Document STM32MP1 Reset Clock Controller (RCC) bindings

[Gabriel FERNANDEZ]

Hi Rob,

Thanks for reviewing.


On 02/05/2018 07:09 AM, Rob Herring wrote:
> On Fri, Feb 02, 2018 at 03:03:29PM +0100, gabriel.fernan...@st.com wrote:
>> From: Gabriel Fernandez 
>>
>> The RCC block is responsible of the management of the clock and reset
>> generation for the complete circuit.
>>
>> Signed-off-by: Gabriel Fernandez 
>> ---
>>   .../devicetree/bindings/mfd/st,stm32-rcc.txt   | 85 
>> ++
>>   1 file changed, 85 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt 
>> b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> new file mode 100644
>> index 000..28017a1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> @@ -0,0 +1,85 @@
>> +STMicroelectronics STM32 Peripheral Reset Clock Controller
>> +==
>> +
>> +The RCC IP is both a reset and a clock controller.
>> +
>> +Please also refer to reset.txt for common reset controller binding usage.
>> +
>> +Please also refer to clock-bindings.txt for common clock controller
>> +binding usage.
>> +
>> +
>> +Required properties:
>> +- compatible: "simple-mfd", "syscon"
>
>> +- reg: should be register base and length as documented in the datasheet
>> +
>> +- Sub-nodes:
>> +  - compatible: "st,stm32mp1-rcc-clk"
>> +- #clock-cells: 1, device nodes should specify the clock in their
>> +  "clocks" property, containing a phandle to the clock device node,
>> +  an index specifying the clock to use.
>> +
>> +  - compatible: "st,stm32mp1-rcc-rst"
>> +- #reset-cells: Shall be 1
>> +
>> +Example:
>> +rcc: rcc@5000 {
>> +compatible = "syscon", "simple-mfd";
>> +reg = <0x5000 0x1000>;
>> +
>> +rcc_clk: rcc-clk@5000 {
>> +#clock-cells = <1>;
>> +compatible = "st,stm32mp1-rcc-clk";
>> +};
>> +
>> +rcc_rst: rcc-reset@5000 {
> You should not have the same unit-address twice.
>
> IMO, this should just be:
>
>   rcc: rcc@5000 {
>   compatible = "st-stm32mp1-rcc";
>   reg = <0x5000 0x1000>;
>   #clock-cells = <1>;
>   #reset-cells = <1>;
>   };
>
> There's no reason a node can't provide more than 1 function.
RCC is an dedicated IP for clocks and resets, but also for power 
management (patches will be sent later)
Then i need to probe 3 drivers with same IP.
It's also a way to avoid use of 'CLK_OF_DECLARE_DRIVER' and i need it to 
probe the 3th driver.

BR
Gabriel

>
>
>> +#reset-cells = <1>;
>> +compatible = "st,stm32mp1-rcc-rst";
>> +};
>> +};
>> +
>> +Specifying clocks
>> +=
>> +
>> +All available clocks are defined as preprocessor macros in
>> +dt-bindings/clock/stm32mp1-clks.h header and can be used in device
>> +tree sources.
>> +
>> +Example:
>> +
>> +/* Accessing DMA1 clock */
>> +... {
>> +clocks = <_clk DMA1>
>> +};
>> +
>> +/* Accessing SPI6 kernel clock */
>> +... {
>> +clocks = <_clk SPI6_K>
>> +};
> Other than the path to header, the clock binding explains all this. No
> need to duplicate here.
ok
>> +
>> +Specifying softreset control of devices
>> +===
>> +
>> +Device nodes should specify the reset channel required in their "resets"
>> +property, containing a phandle to the reset device node and an index 
>> specifying
>> +which channel to use.
>> +The index is the bit number within the RCC registers bank, starting from RCC
>> +base address.
>> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
>> +Where bit_offset is the bit offset within the register.
>> +
>> +For example on STM32MP1, for LTDC reset:
>> + ltdc = APB4_RSTSETR_offset / 4 * 32 + LTDC_bit_offset
>> +  = 0x180 / 4 * 32 + 0 = 3072
>> +
>> +The list of valid indices for STM32MP1 is available in:
>> +include/dt-bindings/reset-controller/stm32mp1-resets.h
>> +
>> +This file implements defines like:
>> +#define LTDC_R  3072
>> +
>> +example:
>> +
>> +ltdc {
>> +resets = <_rst LTDC_R>;
>> +};
>> -- 
>> 1.9.1
>>

Re: [PATCH 01/14] dt-bindings: Document STM32MP1 Reset Clock Controller (RCC) bindings

[Gabriel FERNANDEZ]

Hi Rob,

Thanks for reviewing.


On 02/05/2018 07:09 AM, Rob Herring wrote:
> On Fri, Feb 02, 2018 at 03:03:29PM +0100, gabriel.fernan...@st.com wrote:
>> From: Gabriel Fernandez 
>>
>> The RCC block is responsible of the management of the clock and reset
>> generation for the complete circuit.
>>
>> Signed-off-by: Gabriel Fernandez 
>> ---
>>   .../devicetree/bindings/mfd/st,stm32-rcc.txt   | 85 
>> ++
>>   1 file changed, 85 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt 
>> b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> new file mode 100644
>> index 000..28017a1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> @@ -0,0 +1,85 @@
>> +STMicroelectronics STM32 Peripheral Reset Clock Controller
>> +==
>> +
>> +The RCC IP is both a reset and a clock controller.
>> +
>> +Please also refer to reset.txt for common reset controller binding usage.
>> +
>> +Please also refer to clock-bindings.txt for common clock controller
>> +binding usage.
>> +
>> +
>> +Required properties:
>> +- compatible: "simple-mfd", "syscon"
>
>> +- reg: should be register base and length as documented in the datasheet
>> +
>> +- Sub-nodes:
>> +  - compatible: "st,stm32mp1-rcc-clk"
>> +- #clock-cells: 1, device nodes should specify the clock in their
>> +  "clocks" property, containing a phandle to the clock device node,
>> +  an index specifying the clock to use.
>> +
>> +  - compatible: "st,stm32mp1-rcc-rst"
>> +- #reset-cells: Shall be 1
>> +
>> +Example:
>> +rcc: rcc@5000 {
>> +compatible = "syscon", "simple-mfd";
>> +reg = <0x5000 0x1000>;
>> +
>> +rcc_clk: rcc-clk@5000 {
>> +#clock-cells = <1>;
>> +compatible = "st,stm32mp1-rcc-clk";
>> +};
>> +
>> +rcc_rst: rcc-reset@5000 {
> You should not have the same unit-address twice.
>
> IMO, this should just be:
>
>   rcc: rcc@5000 {
>   compatible = "st-stm32mp1-rcc";
>   reg = <0x5000 0x1000>;
>   #clock-cells = <1>;
>   #reset-cells = <1>;
>   };
>
> There's no reason a node can't provide more than 1 function.
RCC is an dedicated IP for clocks and resets, but also for power 
management (patches will be sent later)
Then i need to probe 3 drivers with same IP.
It's also a way to avoid use of 'CLK_OF_DECLARE_DRIVER' and i need it to 
probe the 3th driver.

BR
Gabriel

>
>
>> +#reset-cells = <1>;
>> +compatible = "st,stm32mp1-rcc-rst";
>> +};
>> +};
>> +
>> +Specifying clocks
>> +=
>> +
>> +All available clocks are defined as preprocessor macros in
>> +dt-bindings/clock/stm32mp1-clks.h header and can be used in device
>> +tree sources.
>> +
>> +Example:
>> +
>> +/* Accessing DMA1 clock */
>> +... {
>> +clocks = <_clk DMA1>
>> +};
>> +
>> +/* Accessing SPI6 kernel clock */
>> +... {
>> +clocks = <_clk SPI6_K>
>> +};
> Other than the path to header, the clock binding explains all this. No
> need to duplicate here.
ok
>> +
>> +Specifying softreset control of devices
>> +===
>> +
>> +Device nodes should specify the reset channel required in their "resets"
>> +property, containing a phandle to the reset device node and an index 
>> specifying
>> +which channel to use.
>> +The index is the bit number within the RCC registers bank, starting from RCC
>> +base address.
>> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
>> +Where bit_offset is the bit offset within the register.
>> +
>> +For example on STM32MP1, for LTDC reset:
>> + ltdc = APB4_RSTSETR_offset / 4 * 32 + LTDC_bit_offset
>> +  = 0x180 / 4 * 32 + 0 = 3072
>> +
>> +The list of valid indices for STM32MP1 is available in:
>> +include/dt-bindings/reset-controller/stm32mp1-resets.h
>> +
>> +This file implements defines like:
>> +#define LTDC_R  3072
>> +
>> +example:
>> +
>> +ltdc {
>> +resets = <_rst LTDC_R>;
>> +};
>> -- 
>> 1.9.1
>>

[PATCH v2 1/2] KVM: X86: Add per-VM no-HLT-exiting capability

[Wanpeng Li]

From: Wanpeng Li 

If host CPUs are dedicated to a VM, we can avoid VM exits on HLT.
This patch adds the per-VM non-HLT-exiting capability.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
v1 -> v2:
 * vmx_clear_hlt() around INIT handling
 * vmx_clear_hlt() upon SMI and implement auto halt restart 

 Documentation/virtual/kvm/api.txt  | 11 +++
 arch/x86/include/asm/kvm_emulate.h |  1 +
 arch/x86/include/asm/kvm_host.h|  7 +++
 arch/x86/kvm/emulate.c |  2 ++
 arch/x86/kvm/vmx.c | 38 ++
 arch/x86/kvm/x86.c | 27 +++
 arch/x86/kvm/x86.h |  5 +
 include/uapi/linux/kvm.h   |  1 +
 8 files changed, 88 insertions(+), 4 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index 023da07..865b029 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4302,6 +4302,17 @@ enables QEMU to build error log and branch to guest 
kernel registered
 machine check handling routine. Without this capability KVM will
 branch to guests' 0x200 interrupt vector.
 
+7.13 KVM_CAP_X86_GUEST_HLT
+
+Architectures: x86
+Parameters: none
+Returns: 0 on success
+
+This capability indicates that a guest using HLT to stop a virtual CPU
+will not cause a VM exit. As such, time spent while a virtual CPU is
+halted in this way will then be accounted for as guest running time on
+the host, KVM_FEATURE_PV_UNHALT should be disabled.
+
 8. Other capabilities.
 --
 
diff --git a/arch/x86/include/asm/kvm_emulate.h 
b/arch/x86/include/asm/kvm_emulate.h
index b24b1c8..78cfe8ca 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -225,6 +225,7 @@ struct x86_emulate_ops {
unsigned (*get_hflags)(struct x86_emulate_ctxt *ctxt);
void (*set_hflags)(struct x86_emulate_ctxt *ctxt, unsigned hflags);
int (*pre_leave_smm)(struct x86_emulate_ctxt *ctxt, u64 smbase);
+   void (*smm_auto_halt_restart)(struct x86_emulate_ctxt *ctxt);
 
 };
 
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 8f0f09a..95b2c44 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -623,6 +623,11 @@ struct kvm_vcpu_arch {
unsigned nmi_pending; /* NMI queued after currently running handler */
bool nmi_injected;/* Trying to inject an NMI this entry */
bool smi_pending;/* SMI queued after currently running handler */
+   /*
+* bit 0 is set if Value of Auto HALT Restart after Entry to SMM is true
+* bit 1 is set if Value of Auto HALT Restart When Exiting SMM is true
+*/
+   int smm_auto_halt_restart;
 
struct kvm_mtrr mtrr_state;
u64 pat;
@@ -806,6 +811,8 @@ struct kvm_arch {
 
gpa_t wall_clock;
 
+   bool hlt_in_guest;
+
bool ept_identity_pagetable_done;
gpa_t ept_identity_map_addr;
 
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index d91eaeb..ee5bc65 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2597,6 +2597,8 @@ static int em_rsm(struct x86_emulate_ctxt *ctxt)
 
smbase = ctxt->ops->get_smbase(ctxt);
 
+   if (GET_SMSTATE(u16, smbase, 0x7f02) & 0x1)
+   ctxt->ops->smm_auto_halt_restart(ctxt);
/*
 * Give pre_leave_smm() a chance to make ISA-specific changes to the
 * vCPU state (e.g. enter guest mode) before loading state from the SMM
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 3e71086..23789c9 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2474,6 +2474,24 @@ static int nested_vmx_check_exception(struct kvm_vcpu 
*vcpu, unsigned long *exit
return 0;
 }
 
+static bool vmx_need_clear_hlt(struct kvm_vcpu *vcpu)
+{
+   return kvm_hlt_in_guest(vcpu->kvm) &&
+   vmcs_read32(GUEST_ACTIVITY_STATE) == GUEST_ACTIVITY_HLT;
+}
+
+static void vmx_clear_hlt(struct kvm_vcpu *vcpu)
+{
+   /*
+* Ensure that we clear the HLT state in the VMCS.  We don't need to
+* explicitly skip the instruction because if the HLT state is set,
+* then the instruction is already executing and RIP has already been
+* advanced.
+*/
+   if (vmx_need_clear_hlt(vcpu))
+   vmcs_write32(GUEST_ACTIVITY_STATE, GUEST_ACTIVITY_ACTIVE);
+}
+
 static void vmx_queue_exception(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -2504,6 +2522,8 @@ static void vmx_queue_exception(struct kvm_vcpu *vcpu)
intr_info |= INTR_TYPE_HARD_EXCEPTION;
 
vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr_info);
+
+   vmx_clear_hlt(vcpu);
 }
 
 static bool vmx_rdtscp_supported(void)
@@ -5359,6 +5379,8 @@ static u32 

[PATCH v2 1/2] KVM: X86: Add per-VM no-HLT-exiting capability

[Wanpeng Li]

From: Wanpeng Li 

If host CPUs are dedicated to a VM, we can avoid VM exits on HLT.
This patch adds the per-VM non-HLT-exiting capability.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
v1 -> v2:
 * vmx_clear_hlt() around INIT handling
 * vmx_clear_hlt() upon SMI and implement auto halt restart 

 Documentation/virtual/kvm/api.txt  | 11 +++
 arch/x86/include/asm/kvm_emulate.h |  1 +
 arch/x86/include/asm/kvm_host.h|  7 +++
 arch/x86/kvm/emulate.c |  2 ++
 arch/x86/kvm/vmx.c | 38 ++
 arch/x86/kvm/x86.c | 27 +++
 arch/x86/kvm/x86.h |  5 +
 include/uapi/linux/kvm.h   |  1 +
 8 files changed, 88 insertions(+), 4 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index 023da07..865b029 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4302,6 +4302,17 @@ enables QEMU to build error log and branch to guest 
kernel registered
 machine check handling routine. Without this capability KVM will
 branch to guests' 0x200 interrupt vector.
 
+7.13 KVM_CAP_X86_GUEST_HLT
+
+Architectures: x86
+Parameters: none
+Returns: 0 on success
+
+This capability indicates that a guest using HLT to stop a virtual CPU
+will not cause a VM exit. As such, time spent while a virtual CPU is
+halted in this way will then be accounted for as guest running time on
+the host, KVM_FEATURE_PV_UNHALT should be disabled.
+
 8. Other capabilities.
 --
 
diff --git a/arch/x86/include/asm/kvm_emulate.h 
b/arch/x86/include/asm/kvm_emulate.h
index b24b1c8..78cfe8ca 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -225,6 +225,7 @@ struct x86_emulate_ops {
unsigned (*get_hflags)(struct x86_emulate_ctxt *ctxt);
void (*set_hflags)(struct x86_emulate_ctxt *ctxt, unsigned hflags);
int (*pre_leave_smm)(struct x86_emulate_ctxt *ctxt, u64 smbase);
+   void (*smm_auto_halt_restart)(struct x86_emulate_ctxt *ctxt);
 
 };
 
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 8f0f09a..95b2c44 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -623,6 +623,11 @@ struct kvm_vcpu_arch {
unsigned nmi_pending; /* NMI queued after currently running handler */
bool nmi_injected;/* Trying to inject an NMI this entry */
bool smi_pending;/* SMI queued after currently running handler */
+   /*
+* bit 0 is set if Value of Auto HALT Restart after Entry to SMM is true
+* bit 1 is set if Value of Auto HALT Restart When Exiting SMM is true
+*/
+   int smm_auto_halt_restart;
 
struct kvm_mtrr mtrr_state;
u64 pat;
@@ -806,6 +811,8 @@ struct kvm_arch {
 
gpa_t wall_clock;
 
+   bool hlt_in_guest;
+
bool ept_identity_pagetable_done;
gpa_t ept_identity_map_addr;
 
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index d91eaeb..ee5bc65 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2597,6 +2597,8 @@ static int em_rsm(struct x86_emulate_ctxt *ctxt)
 
smbase = ctxt->ops->get_smbase(ctxt);
 
+   if (GET_SMSTATE(u16, smbase, 0x7f02) & 0x1)
+   ctxt->ops->smm_auto_halt_restart(ctxt);
/*
 * Give pre_leave_smm() a chance to make ISA-specific changes to the
 * vCPU state (e.g. enter guest mode) before loading state from the SMM
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 3e71086..23789c9 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2474,6 +2474,24 @@ static int nested_vmx_check_exception(struct kvm_vcpu 
*vcpu, unsigned long *exit
return 0;
 }
 
+static bool vmx_need_clear_hlt(struct kvm_vcpu *vcpu)
+{
+   return kvm_hlt_in_guest(vcpu->kvm) &&
+   vmcs_read32(GUEST_ACTIVITY_STATE) == GUEST_ACTIVITY_HLT;
+}
+
+static void vmx_clear_hlt(struct kvm_vcpu *vcpu)
+{
+   /*
+* Ensure that we clear the HLT state in the VMCS.  We don't need to
+* explicitly skip the instruction because if the HLT state is set,
+* then the instruction is already executing and RIP has already been
+* advanced.
+*/
+   if (vmx_need_clear_hlt(vcpu))
+   vmcs_write32(GUEST_ACTIVITY_STATE, GUEST_ACTIVITY_ACTIVE);
+}
+
 static void vmx_queue_exception(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -2504,6 +2522,8 @@ static void vmx_queue_exception(struct kvm_vcpu *vcpu)
intr_info |= INTR_TYPE_HARD_EXCEPTION;
 
vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr_info);
+
+   vmx_clear_hlt(vcpu);
 }
 
 static bool vmx_rdtscp_supported(void)
@@ -5359,6 +5379,8 @@ static u32 vmx_exec_control(struct vcpu_vmx *vmx)
exec_control |= CPU_BASED_CR3_STORE_EXITING |
   

[PATCH v2 2/2] KVM: X86: Avoid traversing all the cpus for pv tlb flush when steal time is disabled

[Wanpeng Li]

From: Wanpeng Li 

Avoid traversing all the cpus for pv tlb flush when steal time 
is disabled since pv tlb flush depends on the field in steal time 
for shared data.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kernel/kvm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index f2a09cf..4f3c997 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -546,7 +546,8 @@ static void __init kvm_guest_init(void)
}
 
if (kvm_para_has_feature(KVM_FEATURE_PV_TLB_FLUSH) &&
-   !kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED))
+   !kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED) &&
+   kvm_para_has_feature(KVM_FEATURE_STEAL_TIME))
pv_mmu_ops.flush_tlb_others = kvm_flush_tlb_others;
 
if (kvm_para_has_feature(KVM_FEATURE_PV_EOI))
@@ -635,7 +636,8 @@ static __init int kvm_setup_pv_tlb_flush(void)
int cpu;
 
if (kvm_para_has_feature(KVM_FEATURE_PV_TLB_FLUSH) &&
-   !kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED)) {
+   !kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED) &&
+   kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) {
for_each_possible_cpu(cpu) {
zalloc_cpumask_var_node(per_cpu_ptr(&__pv_tlb_mask, 
cpu),
GFP_KERNEL, cpu_to_node(cpu));
-- 
2.7.4

[PATCH v2 2/2] KVM: X86: Avoid traversing all the cpus for pv tlb flush when steal time is disabled

[Wanpeng Li]

From: Wanpeng Li 

Avoid traversing all the cpus for pv tlb flush when steal time 
is disabled since pv tlb flush depends on the field in steal time 
for shared data.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kernel/kvm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index f2a09cf..4f3c997 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -546,7 +546,8 @@ static void __init kvm_guest_init(void)
}
 
if (kvm_para_has_feature(KVM_FEATURE_PV_TLB_FLUSH) &&
-   !kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED))
+   !kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED) &&
+   kvm_para_has_feature(KVM_FEATURE_STEAL_TIME))
pv_mmu_ops.flush_tlb_others = kvm_flush_tlb_others;
 
if (kvm_para_has_feature(KVM_FEATURE_PV_EOI))
@@ -635,7 +636,8 @@ static __init int kvm_setup_pv_tlb_flush(void)
int cpu;
 
if (kvm_para_has_feature(KVM_FEATURE_PV_TLB_FLUSH) &&
-   !kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED)) {
+   !kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED) &&
+   kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) {
for_each_possible_cpu(cpu) {
zalloc_cpumask_var_node(per_cpu_ptr(&__pv_tlb_mask, 
cpu),
GFP_KERNEL, cpu_to_node(cpu));
-- 
2.7.4

Re: [PATCH 08/20] s390/kconfig: Remove ARCH_WANTS_PROT_NUMA_PROT_NONE select

[Heiko Carstens]

On Mon, Feb 05, 2018 at 02:21:20AM +0100, Ulf Magnusson wrote:
> The ARCH_WANTS_PROT_NUMA_PROT_NONE symbol was removed by
> commit 6a33979d5bd7 ("mm: remove misleading ARCH_USES_NUMA_PROT_NONE"),
> but S390 still selects it.
> 
> Remove the ARCH_WANTS_PROT_NUMA_PROT_NONE select from the S390 symbol.
> 
> Discovered with the
> https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
> script.
> 
> Signed-off-by: Ulf Magnusson 
> ---
>  arch/s390/Kconfig | 1 -
>  1 file changed, 1 deletion(-)

Applied, thanks!

Re: [PATCH 08/20] s390/kconfig: Remove ARCH_WANTS_PROT_NUMA_PROT_NONE select

[Heiko Carstens]

On Mon, Feb 05, 2018 at 02:21:20AM +0100, Ulf Magnusson wrote:
> The ARCH_WANTS_PROT_NUMA_PROT_NONE symbol was removed by
> commit 6a33979d5bd7 ("mm: remove misleading ARCH_USES_NUMA_PROT_NONE"),
> but S390 still selects it.
> 
> Remove the ARCH_WANTS_PROT_NUMA_PROT_NONE select from the S390 symbol.
> 
> Discovered with the
> https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
> script.
> 
> Signed-off-by: Ulf Magnusson 
> ---
>  arch/s390/Kconfig | 1 -
>  1 file changed, 1 deletion(-)

Applied, thanks!

Re: linux-next: Signed-off-by missing for commits in the s390 tree

[Martin Schwidefsky]

Hi Stephen,

On Sat, 3 Feb 2018 13:03:48 +1100
Stephen Rothwell  wrote:

> Commits
> 
>   a39892ed47bf ("s390/runtime_instrumentation: re-add signum system call 
> parameter")
>   279d2cea3aad ("s390/cio: fix kernel-doc usage")
> 
> are missing a Signed-off-by from their committer.

Thanks for the heads up, fixed it.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: linux-next: Signed-off-by missing for commits in the s390 tree

[Martin Schwidefsky]

Hi Stephen,

On Sat, 3 Feb 2018 13:03:48 +1100
Stephen Rothwell  wrote:

> Commits
> 
>   a39892ed47bf ("s390/runtime_instrumentation: re-add signum system call 
> parameter")
>   279d2cea3aad ("s390/cio: fix kernel-doc usage")
> 
> are missing a Signed-off-by from their committer.

Thanks for the heads up, fixed it.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

[Yunlong Song]

Is it necessary to make atomic commit fail? What's the problem of this
patch (no lock at all and does not make atomic fail)? These two patches
aims to provide ability to gc old blocks of opened atomic file, with no
affection to original atomic commit and no mix with inmem pages.

On 2018/2/5 14:29, Chao Yu wrote:

On 2018/2/5 10:53, Yunlong Song wrote:

Is it necessary to add a lock here? What's the problem of this patch (no
lock at all)? Anyway, the problem is expected to be fixed asap, since
attackers can easily write an app with only atomic start and no atomic
commit, which will cause f2fs run into loop gc if the disk layout is
much fragmented, since f2fs_gc will select the same target victim all
the time (e.g. one block of target victim belongs to the opened atomic
file, and it will not be moved and do_garbage_collect will finally
return 0, and that victim is selected again next time) and goto gc_more
time and time again, which will block all the fs ops (all the fs ops
will hang up in f2fs_balance_fs).


Hmm.. w/ original commit log and implementation, I supposed that the patch
intended to fix to make atomic write be isolated from other IOs like GC
triggered writes...

Alright, we have discuss the problem before in below link:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1571951.html

I meant, for example:

f2fs_ioc_start_atomic_write()
inode->atomic_open_time = get_mtime();

f2fs_ioc_commit_atomic_write()
inode->atomic_open_time = 0;

f2fs_balance_fs_bg()
for_each_atomic_open_file()
if (inode->atomic_open_time &&
inode->atomic_open_time > threshold) {
drop_inmem_pages();
f2fs_msg();
}

threshold = 30s

Any thoughts?

Thanks,



On 2018/2/4 22:56, Chao Yu wrote:

On 2018/2/3 10:47, Yunlong Song wrote:

If inode has already started to atomic commit, then set_page_dirty will
not mix the gc pages with the inmem atomic pages, so the page can be
gced safely.


Let's avoid Ccing fs mailing list if the patch didn't change vfs common
codes.

As you know, the problem here is mixed dnode block flushing w/o writebacking
gced data block, result in making transaction unintegrated.

So how about just using dio_rwsem[WRITE] during atomic committing to exclude
GCing data block of atomic opened file?

Thanks,



Signed-off-by: Yunlong Song 
---
   fs/f2fs/data.c | 5 ++---
   fs/f2fs/gc.c   | 6 --
   2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7435830..edafcb6 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1580,14 +1580,13 @@ bool should_update_outplace(struct inode *inode, struct 
f2fs_io_info *fio)
return true;
if (S_ISDIR(inode->i_mode))
return true;
-   if (f2fs_is_atomic_file(inode))
-   return true;
if (fio) {
if (is_cold_data(fio->page))
return true;
if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
return true;
-   }
+   } else if (f2fs_is_atomic_file(inode))
+   return true;
return false;
   }
   
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c

index b9d93fd..84ab3ff 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -622,7 +622,8 @@ static void move_data_block(struct inode *inode, block_t 
bidx,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
   
-	if (f2fs_is_atomic_file(inode))

+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode))
goto out;
   
   	if (f2fs_is_pinned_file(inode)) {

@@ -729,7 +730,8 @@ static void move_data_page(struct inode *inode, block_t 
bidx, int gc_type,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
   
-	if (f2fs_is_atomic_file(inode))

+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode))
goto out;
if (f2fs_is_pinned_file(inode)) {
if (gc_type == FG_GC)



.






.



--
Thanks,
Yunlong Song

Re: [PATCH v4 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

[Knut Omang]

On Fri, 2018-01-19 at 11:14 +0100, Knut Omang wrote:
> Add scripts/runchecks which has generic support for running
> checker tools in a convenient and user friendly way that
> the author hopes can contribute to rein in issues detected
> by these tools in a manageable and convenient way.
> 
> scripts/runchecks provides the following basic functionality:
> 
> * Makes it possible to selectively suppress output from individual
>   checks on a per file or per subsystem basis.
> * Unifies output and suppression input from different tools
>   by providing a single unified syntax and presentation for the
>   underlying tools in the style of "scripts/checkpatch.pl --show-types".
> * Allows selective run of one, or more (or all) configured tools
>   for each file.
> 
> In the Makefile system, the sparse specific setup has been replaced
> by setup for runchecks.

Hi all,

- Anything more I can/need to do to bring this forward?
- Any quiet concerns?

I realize it is a subsystem crossing change, and a lot going on elsewhere, 
nevertheless I believe this is a time saver in the slightly longer run,
as it allows automation of checking, even without a "perfect"
code base to begin with.

Thanks,
Knut

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

[Yunlong Song]

Is it necessary to make atomic commit fail? What's the problem of this
patch (no lock at all and does not make atomic fail)? These two patches
aims to provide ability to gc old blocks of opened atomic file, with no
affection to original atomic commit and no mix with inmem pages.

On 2018/2/5 14:29, Chao Yu wrote:

On 2018/2/5 10:53, Yunlong Song wrote:

Is it necessary to add a lock here? What's the problem of this patch (no
lock at all)? Anyway, the problem is expected to be fixed asap, since
attackers can easily write an app with only atomic start and no atomic
commit, which will cause f2fs run into loop gc if the disk layout is
much fragmented, since f2fs_gc will select the same target victim all
the time (e.g. one block of target victim belongs to the opened atomic
file, and it will not be moved and do_garbage_collect will finally
return 0, and that victim is selected again next time) and goto gc_more
time and time again, which will block all the fs ops (all the fs ops
will hang up in f2fs_balance_fs).


Hmm.. w/ original commit log and implementation, I supposed that the patch
intended to fix to make atomic write be isolated from other IOs like GC
triggered writes...

Alright, we have discuss the problem before in below link:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1571951.html

I meant, for example:

f2fs_ioc_start_atomic_write()
inode->atomic_open_time = get_mtime();

f2fs_ioc_commit_atomic_write()
inode->atomic_open_time = 0;

f2fs_balance_fs_bg()
for_each_atomic_open_file()
if (inode->atomic_open_time &&
inode->atomic_open_time > threshold) {
drop_inmem_pages();
f2fs_msg();
}

threshold = 30s

Any thoughts?

Thanks,



On 2018/2/4 22:56, Chao Yu wrote:

On 2018/2/3 10:47, Yunlong Song wrote:

If inode has already started to atomic commit, then set_page_dirty will
not mix the gc pages with the inmem atomic pages, so the page can be
gced safely.


Let's avoid Ccing fs mailing list if the patch didn't change vfs common
codes.

As you know, the problem here is mixed dnode block flushing w/o writebacking
gced data block, result in making transaction unintegrated.

So how about just using dio_rwsem[WRITE] during atomic committing to exclude
GCing data block of atomic opened file?

Thanks,



Signed-off-by: Yunlong Song 
---
   fs/f2fs/data.c | 5 ++---
   fs/f2fs/gc.c   | 6 --
   2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7435830..edafcb6 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1580,14 +1580,13 @@ bool should_update_outplace(struct inode *inode, struct 
f2fs_io_info *fio)
return true;
if (S_ISDIR(inode->i_mode))
return true;
-   if (f2fs_is_atomic_file(inode))
-   return true;
if (fio) {
if (is_cold_data(fio->page))
return true;
if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
return true;
-   }
+   } else if (f2fs_is_atomic_file(inode))
+   return true;
return false;
   }
   
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c

index b9d93fd..84ab3ff 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -622,7 +622,8 @@ static void move_data_block(struct inode *inode, block_t 
bidx,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
   
-	if (f2fs_is_atomic_file(inode))

+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode))
goto out;
   
   	if (f2fs_is_pinned_file(inode)) {

@@ -729,7 +730,8 @@ static void move_data_page(struct inode *inode, block_t 
bidx, int gc_type,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
   
-	if (f2fs_is_atomic_file(inode))

+   if (f2fs_is_atomic_file(inode) &&
+   !f2fs_is_commit_atomic_write(inode))
goto out;
if (f2fs_is_pinned_file(inode)) {
if (gc_type == FG_GC)



.






.



--
Thanks,
Yunlong Song

Re: [PATCH v4 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

[Knut Omang]

On Fri, 2018-01-19 at 11:14 +0100, Knut Omang wrote:
> Add scripts/runchecks which has generic support for running
> checker tools in a convenient and user friendly way that
> the author hopes can contribute to rein in issues detected
> by these tools in a manageable and convenient way.
> 
> scripts/runchecks provides the following basic functionality:
> 
> * Makes it possible to selectively suppress output from individual
>   checks on a per file or per subsystem basis.
> * Unifies output and suppression input from different tools
>   by providing a single unified syntax and presentation for the
>   underlying tools in the style of "scripts/checkpatch.pl --show-types".
> * Allows selective run of one, or more (or all) configured tools
>   for each file.
> 
> In the Makefile system, the sparse specific setup has been replaced
> by setup for runchecks.

Hi all,

- Anything more I can/need to do to bring this forward?
- Any quiet concerns?

I realize it is a subsystem crossing change, and a lot going on elsewhere, 
nevertheless I believe this is a time saver in the slightly longer run,
as it allows automation of checking, even without a "perfect"
code base to begin with.

Thanks,
Knut

Re: [PATCH 1/2] soc: imx: gpc: ARM power domain should be always-on

[Shawn Guo]

On Wed, Jan 24, 2018 at 12:42:13AM +0800, Anson Huang wrote:
> ARM power domain does NOT support runtime off, always-on
> flag should be set to avoid incorrect power state in
> pm_genpd_summary:
> 
> Before:
> 
> root@imx6qpdlsolox:~# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
> domain  status  slaves
> /device runtime status
> --
> ARM off-0
> 
> After:
> 
> root@imx6qpdlsolox:~# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
> domain  status  slaves
> /device runtime status
> --
> ARM on
> 
> Signed-off-by: Anson Huang 

Applied both, thanks.

Re: [PATCH 1/2] soc: imx: gpc: ARM power domain should be always-on

[Shawn Guo]

On Wed, Jan 24, 2018 at 12:42:13AM +0800, Anson Huang wrote:
> ARM power domain does NOT support runtime off, always-on
> flag should be set to avoid incorrect power state in
> pm_genpd_summary:
> 
> Before:
> 
> root@imx6qpdlsolox:~# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
> domain  status  slaves
> /device runtime status
> --
> ARM off-0
> 
> After:
> 
> root@imx6qpdlsolox:~# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
> domain  status  slaves
> /device runtime status
> --
> ARM on
> 
> Signed-off-by: Anson Huang 

Applied both, thanks.

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

[Chao Yu]

On 2018/2/5 10:53, Yunlong Song wrote:
> Is it necessary to add a lock here? What's the problem of this patch (no 
> lock at all)? Anyway, the problem is expected to be fixed asap, since 
> attackers can easily write an app with only atomic start and no atomic 
> commit, which will cause f2fs run into loop gc if the disk layout is 
> much fragmented, since f2fs_gc will select the same target victim all 
> the time (e.g. one block of target victim belongs to the opened atomic 
> file, and it will not be moved and do_garbage_collect will finally 
> return 0, and that victim is selected again next time) and goto gc_more 
> time and time again, which will block all the fs ops (all the fs ops 
> will hang up in f2fs_balance_fs).

Hmm.. w/ original commit log and implementation, I supposed that the patch
intended to fix to make atomic write be isolated from other IOs like GC
triggered writes...

Alright, we have discuss the problem before in below link:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1571951.html

I meant, for example:

f2fs_ioc_start_atomic_write()
inode->atomic_open_time = get_mtime();

f2fs_ioc_commit_atomic_write()
inode->atomic_open_time = 0;

f2fs_balance_fs_bg()
for_each_atomic_open_file()
if (inode->atomic_open_time &&
inode->atomic_open_time > threshold) {
drop_inmem_pages();
f2fs_msg();
}

threshold = 30s

Any thoughts?

Thanks,

> 
> On 2018/2/4 22:56, Chao Yu wrote:
>> On 2018/2/3 10:47, Yunlong Song wrote:
>>> If inode has already started to atomic commit, then set_page_dirty will
>>> not mix the gc pages with the inmem atomic pages, so the page can be
>>> gced safely.
>>
>> Let's avoid Ccing fs mailing list if the patch didn't change vfs common
>> codes.
>>
>> As you know, the problem here is mixed dnode block flushing w/o writebacking
>> gced data block, result in making transaction unintegrated.
>>
>> So how about just using dio_rwsem[WRITE] during atomic committing to exclude
>> GCing data block of atomic opened file?
>>
>> Thanks,
>>
>>>
>>> Signed-off-by: Yunlong Song 
>>> ---
>>>   fs/f2fs/data.c | 5 ++---
>>>   fs/f2fs/gc.c   | 6 --
>>>   2 files changed, 6 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>> index 7435830..edafcb6 100644
>>> --- a/fs/f2fs/data.c
>>> +++ b/fs/f2fs/data.c
>>> @@ -1580,14 +1580,13 @@ bool should_update_outplace(struct inode *inode, 
>>> struct f2fs_io_info *fio)
>>> return true;
>>> if (S_ISDIR(inode->i_mode))
>>> return true;
>>> -   if (f2fs_is_atomic_file(inode))
>>> -   return true;
>>> if (fio) {
>>> if (is_cold_data(fio->page))
>>> return true;
>>> if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
>>> return true;
>>> -   }
>>> +   } else if (f2fs_is_atomic_file(inode))
>>> +   return true;
>>> return false;
>>>   }
>>>   
>>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
>>> index b9d93fd..84ab3ff 100644
>>> --- a/fs/f2fs/gc.c
>>> +++ b/fs/f2fs/gc.c
>>> @@ -622,7 +622,8 @@ static void move_data_block(struct inode *inode, 
>>> block_t bidx,
>>> if (!check_valid_map(F2FS_I_SB(inode), segno, off))
>>> goto out;
>>>   
>>> -   if (f2fs_is_atomic_file(inode))
>>> +   if (f2fs_is_atomic_file(inode) &&
>>> +   !f2fs_is_commit_atomic_write(inode))
>>> goto out;
>>>   
>>> if (f2fs_is_pinned_file(inode)) {
>>> @@ -729,7 +730,8 @@ static void move_data_page(struct inode *inode, block_t 
>>> bidx, int gc_type,
>>> if (!check_valid_map(F2FS_I_SB(inode), segno, off))
>>> goto out;
>>>   
>>> -   if (f2fs_is_atomic_file(inode))
>>> +   if (f2fs_is_atomic_file(inode) &&
>>> +   !f2fs_is_commit_atomic_write(inode))
>>> goto out;
>>> if (f2fs_is_pinned_file(inode)) {
>>> if (gc_type == FG_GC)
>>>
>>
>> .
>>
> 

Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

[Chao Yu]

On 2018/2/5 10:53, Yunlong Song wrote:
> Is it necessary to add a lock here? What's the problem of this patch (no 
> lock at all)? Anyway, the problem is expected to be fixed asap, since 
> attackers can easily write an app with only atomic start and no atomic 
> commit, which will cause f2fs run into loop gc if the disk layout is 
> much fragmented, since f2fs_gc will select the same target victim all 
> the time (e.g. one block of target victim belongs to the opened atomic 
> file, and it will not be moved and do_garbage_collect will finally 
> return 0, and that victim is selected again next time) and goto gc_more 
> time and time again, which will block all the fs ops (all the fs ops 
> will hang up in f2fs_balance_fs).

Hmm.. w/ original commit log and implementation, I supposed that the patch
intended to fix to make atomic write be isolated from other IOs like GC
triggered writes...

Alright, we have discuss the problem before in below link:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1571951.html

I meant, for example:

f2fs_ioc_start_atomic_write()
inode->atomic_open_time = get_mtime();

f2fs_ioc_commit_atomic_write()
inode->atomic_open_time = 0;

f2fs_balance_fs_bg()
for_each_atomic_open_file()
if (inode->atomic_open_time &&
inode->atomic_open_time > threshold) {
drop_inmem_pages();
f2fs_msg();
}

threshold = 30s

Any thoughts?

Thanks,

> 
> On 2018/2/4 22:56, Chao Yu wrote:
>> On 2018/2/3 10:47, Yunlong Song wrote:
>>> If inode has already started to atomic commit, then set_page_dirty will
>>> not mix the gc pages with the inmem atomic pages, so the page can be
>>> gced safely.
>>
>> Let's avoid Ccing fs mailing list if the patch didn't change vfs common
>> codes.
>>
>> As you know, the problem here is mixed dnode block flushing w/o writebacking
>> gced data block, result in making transaction unintegrated.
>>
>> So how about just using dio_rwsem[WRITE] during atomic committing to exclude
>> GCing data block of atomic opened file?
>>
>> Thanks,
>>
>>>
>>> Signed-off-by: Yunlong Song 
>>> ---
>>>   fs/f2fs/data.c | 5 ++---
>>>   fs/f2fs/gc.c   | 6 --
>>>   2 files changed, 6 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>> index 7435830..edafcb6 100644
>>> --- a/fs/f2fs/data.c
>>> +++ b/fs/f2fs/data.c
>>> @@ -1580,14 +1580,13 @@ bool should_update_outplace(struct inode *inode, 
>>> struct f2fs_io_info *fio)
>>> return true;
>>> if (S_ISDIR(inode->i_mode))
>>> return true;
>>> -   if (f2fs_is_atomic_file(inode))
>>> -   return true;
>>> if (fio) {
>>> if (is_cold_data(fio->page))
>>> return true;
>>> if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
>>> return true;
>>> -   }
>>> +   } else if (f2fs_is_atomic_file(inode))
>>> +   return true;
>>> return false;
>>>   }
>>>   
>>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
>>> index b9d93fd..84ab3ff 100644
>>> --- a/fs/f2fs/gc.c
>>> +++ b/fs/f2fs/gc.c
>>> @@ -622,7 +622,8 @@ static void move_data_block(struct inode *inode, 
>>> block_t bidx,
>>> if (!check_valid_map(F2FS_I_SB(inode), segno, off))
>>> goto out;
>>>   
>>> -   if (f2fs_is_atomic_file(inode))
>>> +   if (f2fs_is_atomic_file(inode) &&
>>> +   !f2fs_is_commit_atomic_write(inode))
>>> goto out;
>>>   
>>> if (f2fs_is_pinned_file(inode)) {
>>> @@ -729,7 +730,8 @@ static void move_data_page(struct inode *inode, block_t 
>>> bidx, int gc_type,
>>> if (!check_valid_map(F2FS_I_SB(inode), segno, off))
>>> goto out;
>>>   
>>> -   if (f2fs_is_atomic_file(inode))
>>> +   if (f2fs_is_atomic_file(inode) &&
>>> +   !f2fs_is_commit_atomic_write(inode))
>>> goto out;
>>> if (f2fs_is_pinned_file(inode)) {
>>> if (gc_type == FG_GC)
>>>
>>
>> .
>>
> 

Re: [PATCH] ARM: dts: imx6sx: add pu power domain support

[Shawn Guo]

On Tue, Jan 23, 2018 at 11:12:23PM +0800, Anson Huang wrote:
> Add PU power domain support, GPU is the only
> module inside PU power domain, and PU power
> is supplied by LDO_SOC.
> 
> Signed-off-by: Anson Huang 

Applied, thanks.

Re: [PATCH] ARM: dts: imx6sx: add pu power domain support

[Shawn Guo]

On Tue, Jan 23, 2018 at 11:12:23PM +0800, Anson Huang wrote:
> Add PU power domain support, GPU is the only
> module inside PU power domain, and PU power
> is supplied by LDO_SOC.
> 
> Signed-off-by: Anson Huang 

Applied, thanks.

Re: [PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl

[gengdongjiu]

James,
   Thank you for your time to reply me.

On 2018/1/31 3:21, James Morse wrote:
> Hi gengdongjiu,
> 
> On 24/01/18 20:06, gengdongjiu wrote:
>>> On 06/01/18 16:02, Dongjiu Geng wrote:
 The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the
 guest and user space needs a way to tell KVM this value. So we add a
 new ioctl. Before user space specifies the Exception Syndrome Register
 ESR(ESR), it firstly checks that whether KVM has the capability to set
 the guest ESR, If has, will set it. Otherwise, nothing to do.

 For this ESR specifying, Only support for AArch64, not support AArch32.
>>>
>>> After this patch user-space can trigger an SError in the guest. If it wants 
>>> to migrate the guest, how does the pending SError get migrated?
>>>
>>> I think we need to fix migration first. Andrew Jones suggested using
>>> KVM_GET/SET_VCPU_EVENTS:
>>> https://www.spinics.net/lists/arm-kernel/msg616846.html
>>>
>>> Given KVM uses kvm_inject_vabt() on v8.0 hardware too, we should cover 
>>> systems without the v8.2 RAS Extensions with the same API. I
>>> think this means a bit to read/write whether SError is pending, and another 
>>> to indicate the ESR should be set/read.
>>> CPUs without the v8.2 RAS Extensions can reject pending-SError that had an 
>>> ESR.
>>
>> For the CPUs without the v8.2 RAS Extensions, its ESR is always 0, 
>> we only can inject a SError with ESR 0 to guest, cannot set its ESR.
> 
> 0? It's always implementation-defined. On Juno it seems to be always-0, but
> other systems may behave differently. (Juno may generate another ESR value 
> when
> I'm not watching it...)
For the armv8.0 cpu without RAS Extensions, it does not have vsesr_el2, so when 
guest take a virtual SError,
its ESR is 0, can not control the virtual SError's syndrom value, it does not 
have such registers to control that.

Does Juno not have RAS Extension? if yes, I think we can only inject an SError, 
but can not change its ESR value, because it does not have vsesr_el2.

> 
> Just because we can't control the ESR doesn't mean injecting an SError isn't
> something user-space may want to do.
yes, we may need to support user-space injects an SError even through CPU does 
not have RAS Extension.

> If we tackle migration of pending-SError first, I think that will give us the
> API to create a new pending SError with/without an ESR as appropriate.

sure, we should. Last week, I checked the KVM_GET/SET_VCPU_EVENTS IOCTL, it 
should meet our migration requirements

> 
> 
>> About how about to use the KVM_GET/SET_VCPU_EVENTS, I will check the code, 
>> and
>> consider your suggestion at the same time.
> 
> (Not my suggestion, It was Andrew Jones idea.)
Got it.

> 
>> The IOCTL KVM_GET/SET_VCPU_EVENTS has been used by X86.
> 
> We would be re-using the struct to have values with slightly different 
> meanings.
> But for migration the upshot is the same, call KVM_GET_VCPU_EVENTS on one
> system, and pass the struct to KVM_SET_VCPU_EVENTS on the new system. If we're
> lucky Qemu may be able to do this in shared x86/arm64 code.
> 
Thanks for the reminder, I know your meaning.
In the x86, the kvm_vcpu_events includes exception/interrupt/nmi/smi. For the 
RAS, we
only involves the exception, so Qemu handling logic is different. Anyway, I 
will try to
share code for the two platform in Qemu.


/* for KVM_GET/SET_VCPU_EVENTS */
struct kvm_vcpu_events {
struct {
__u8 injected;
__u8 nr;
__u8 has_error_code;
__u8 pad;
__u32 error_code;
} exception;
struct {
__u8 injected;
__u8 nr;
__u8 soft;
__u8 shadow;
} interrupt;
struct {
__u8 injected;
__u8 pending;
__u8 masked;
__u8 pad;
} nmi;
__u32 sipi_vector;
__u32 flags;
struct {
__u8 smm;
__u8 pending;
__u8 smm_inside_nmi;
__u8 latched_init;
} smi;
__u32 reserved[9];
};

> 
 diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c index
 5c7f657..738ae90 100644
 --- a/arch/arm64/kvm/guest.c
 +++ b/arch/arm64/kvm/guest.c
 @@ -277,6 +277,11 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu 
 *vcpu,
return -EINVAL;
  }

 +int kvm_arm_set_sei_esr(struct kvm_vcpu *vcpu, u32 *syndrome) {
 +  return -EINVAL;
 +}
>>>
>>> Does nothing in the patch that adds the support? This is a bit odd.
>>> (oh, its hiding in patch 6...)
>>
>> To make this patch simple and small, I add it in patch 6.
> 
> But that made the functionality of this patch: A new API to return -EINVAL 
> from
> the kernel.
> 
> Swapping the patches round would have avoided this.
> Regardless, I think this will fold out in a rebase.
yes, I will, thanks for your kind suggestion.

> 
> 
> 

Re: [PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl

[gengdongjiu]

James,
   Thank you for your time to reply me.

On 2018/1/31 3:21, James Morse wrote:
> Hi gengdongjiu,
> 
> On 24/01/18 20:06, gengdongjiu wrote:
>>> On 06/01/18 16:02, Dongjiu Geng wrote:
 The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the
 guest and user space needs a way to tell KVM this value. So we add a
 new ioctl. Before user space specifies the Exception Syndrome Register
 ESR(ESR), it firstly checks that whether KVM has the capability to set
 the guest ESR, If has, will set it. Otherwise, nothing to do.

 For this ESR specifying, Only support for AArch64, not support AArch32.
>>>
>>> After this patch user-space can trigger an SError in the guest. If it wants 
>>> to migrate the guest, how does the pending SError get migrated?
>>>
>>> I think we need to fix migration first. Andrew Jones suggested using
>>> KVM_GET/SET_VCPU_EVENTS:
>>> https://www.spinics.net/lists/arm-kernel/msg616846.html
>>>
>>> Given KVM uses kvm_inject_vabt() on v8.0 hardware too, we should cover 
>>> systems without the v8.2 RAS Extensions with the same API. I
>>> think this means a bit to read/write whether SError is pending, and another 
>>> to indicate the ESR should be set/read.
>>> CPUs without the v8.2 RAS Extensions can reject pending-SError that had an 
>>> ESR.
>>
>> For the CPUs without the v8.2 RAS Extensions, its ESR is always 0, 
>> we only can inject a SError with ESR 0 to guest, cannot set its ESR.
> 
> 0? It's always implementation-defined. On Juno it seems to be always-0, but
> other systems may behave differently. (Juno may generate another ESR value 
> when
> I'm not watching it...)
For the armv8.0 cpu without RAS Extensions, it does not have vsesr_el2, so when 
guest take a virtual SError,
its ESR is 0, can not control the virtual SError's syndrom value, it does not 
have such registers to control that.

Does Juno not have RAS Extension? if yes, I think we can only inject an SError, 
but can not change its ESR value, because it does not have vsesr_el2.

> 
> Just because we can't control the ESR doesn't mean injecting an SError isn't
> something user-space may want to do.
yes, we may need to support user-space injects an SError even through CPU does 
not have RAS Extension.

> If we tackle migration of pending-SError first, I think that will give us the
> API to create a new pending SError with/without an ESR as appropriate.

sure, we should. Last week, I checked the KVM_GET/SET_VCPU_EVENTS IOCTL, it 
should meet our migration requirements

> 
> 
>> About how about to use the KVM_GET/SET_VCPU_EVENTS, I will check the code, 
>> and
>> consider your suggestion at the same time.
> 
> (Not my suggestion, It was Andrew Jones idea.)
Got it.

> 
>> The IOCTL KVM_GET/SET_VCPU_EVENTS has been used by X86.
> 
> We would be re-using the struct to have values with slightly different 
> meanings.
> But for migration the upshot is the same, call KVM_GET_VCPU_EVENTS on one
> system, and pass the struct to KVM_SET_VCPU_EVENTS on the new system. If we're
> lucky Qemu may be able to do this in shared x86/arm64 code.
> 
Thanks for the reminder, I know your meaning.
In the x86, the kvm_vcpu_events includes exception/interrupt/nmi/smi. For the 
RAS, we
only involves the exception, so Qemu handling logic is different. Anyway, I 
will try to
share code for the two platform in Qemu.


/* for KVM_GET/SET_VCPU_EVENTS */
struct kvm_vcpu_events {
struct {
__u8 injected;
__u8 nr;
__u8 has_error_code;
__u8 pad;
__u32 error_code;
} exception;
struct {
__u8 injected;
__u8 nr;
__u8 soft;
__u8 shadow;
} interrupt;
struct {
__u8 injected;
__u8 pending;
__u8 masked;
__u8 pad;
} nmi;
__u32 sipi_vector;
__u32 flags;
struct {
__u8 smm;
__u8 pending;
__u8 smm_inside_nmi;
__u8 latched_init;
} smi;
__u32 reserved[9];
};

> 
 diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c index
 5c7f657..738ae90 100644
 --- a/arch/arm64/kvm/guest.c
 +++ b/arch/arm64/kvm/guest.c
 @@ -277,6 +277,11 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu 
 *vcpu,
return -EINVAL;
  }

 +int kvm_arm_set_sei_esr(struct kvm_vcpu *vcpu, u32 *syndrome) {
 +  return -EINVAL;
 +}
>>>
>>> Does nothing in the patch that adds the support? This is a bit odd.
>>> (oh, its hiding in patch 6...)
>>
>> To make this patch simple and small, I add it in patch 6.
> 
> But that made the functionality of this patch: A new API to return -EINVAL 
> from
> the kernel.
> 
> Swapping the patches round would have avoided this.
> Regardless, I think this will fold out in a rebase.
yes, I will, thanks for your kind suggestion.

> 
> 
> 

Re: [PATCH] ASoC: codecs: Add support for AK4458 DAC driver

[Rob Herring]

On Wed, Jan 31, 2018 at 03:20:09PM +0200, Cosmin-Gabriel Samoila wrote:
> The AK4458 is a 32-bit 8ch Premium DAC that corresponds
> to a 768kHz PCM input and an 11.2MHz DSD input at maximum.
> It supports I2S, DSD and TDM modes with 24 or 32 bit MSB
> or 16, 24, 32 LSB formats. Its datasheet is available here:
> https://www.akm.com/akm/en/file/datasheet/AK4458VN.pdf
> 
> Signed-off-by: Junichi Wakasugi 
> Signed-off-by: Mihai Serban 
> Signed-off-by: Shengjiu Wang 
> Signed-off-by: Cosmin-Gabriel Samoila 
> ---
>  Documentation/devicetree/bindings/sound/ak4458.txt |   23 +

Separate patch please.

>  sound/soc/codecs/Kconfig   |   18 +
>  sound/soc/codecs/Makefile  |6 +
>  sound/soc/codecs/ak4458-i2c.c  |   79 ++
>  sound/soc/codecs/ak4458-spi.c  |   61 ++
>  sound/soc/codecs/ak4458.c  | 1132 
> 
>  sound/soc/codecs/ak4458.h  |  127 +++
>  7 files changed, 1446 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/ak4458.txt
>  create mode 100644 sound/soc/codecs/ak4458-i2c.c
>  create mode 100644 sound/soc/codecs/ak4458-spi.c
>  create mode 100644 sound/soc/codecs/ak4458.c
>  create mode 100644 sound/soc/codecs/ak4458.h
> 
> diff --git a/Documentation/devicetree/bindings/sound/ak4458.txt 
> b/Documentation/devicetree/bindings/sound/ak4458.txt
> new file mode 100644
> index 000..b9e6eb3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/ak4458.txt
> @@ -0,0 +1,23 @@
> +AK4458 audio DAC
> +
> +This device supports both I2C and SPI modes.
> +
> +Required properties:
> +
> +- compatible : "asahi-kasei,ak4458"
> +- reg : The I2C address of the device for I2C, the chip select number for 
> SPI.
> +- asahi-kasei,pdn-gpios: A GPIO specifier for the GPIO controlling
> + the power down & reset pin.

reset-gpios like the Asahi Kasei ADC under review.
 
> +- asahi-kasei,mute-gpios: A GPIO specifier for the GPIO controlling
> + the soft mute pin.

State the active state.

> +
> +Example:
> +
> + {
> + ak4458: ak4458@10 {

dac@10

> + compatible = "asahi-kasei,ak4458";
> + reg = <0x10>;
> + asahi-kasei,pdn-gpios = < 10 GPIO_ACTIVE_HIGH>
> + asahi-kasei,mute-gpios = < 11 GPIO_ACTIVE_HIGH>
> + };
> +};

Re: [PATCH] ASoC: codecs: Add support for AK4458 DAC driver

[Rob Herring]

On Wed, Jan 31, 2018 at 03:20:09PM +0200, Cosmin-Gabriel Samoila wrote:
> The AK4458 is a 32-bit 8ch Premium DAC that corresponds
> to a 768kHz PCM input and an 11.2MHz DSD input at maximum.
> It supports I2S, DSD and TDM modes with 24 or 32 bit MSB
> or 16, 24, 32 LSB formats. Its datasheet is available here:
> https://www.akm.com/akm/en/file/datasheet/AK4458VN.pdf
> 
> Signed-off-by: Junichi Wakasugi 
> Signed-off-by: Mihai Serban 
> Signed-off-by: Shengjiu Wang 
> Signed-off-by: Cosmin-Gabriel Samoila 
> ---
>  Documentation/devicetree/bindings/sound/ak4458.txt |   23 +

Separate patch please.

>  sound/soc/codecs/Kconfig   |   18 +
>  sound/soc/codecs/Makefile  |6 +
>  sound/soc/codecs/ak4458-i2c.c  |   79 ++
>  sound/soc/codecs/ak4458-spi.c  |   61 ++
>  sound/soc/codecs/ak4458.c  | 1132 
> 
>  sound/soc/codecs/ak4458.h  |  127 +++
>  7 files changed, 1446 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/ak4458.txt
>  create mode 100644 sound/soc/codecs/ak4458-i2c.c
>  create mode 100644 sound/soc/codecs/ak4458-spi.c
>  create mode 100644 sound/soc/codecs/ak4458.c
>  create mode 100644 sound/soc/codecs/ak4458.h
> 
> diff --git a/Documentation/devicetree/bindings/sound/ak4458.txt 
> b/Documentation/devicetree/bindings/sound/ak4458.txt
> new file mode 100644
> index 000..b9e6eb3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/ak4458.txt
> @@ -0,0 +1,23 @@
> +AK4458 audio DAC
> +
> +This device supports both I2C and SPI modes.
> +
> +Required properties:
> +
> +- compatible : "asahi-kasei,ak4458"
> +- reg : The I2C address of the device for I2C, the chip select number for 
> SPI.
> +- asahi-kasei,pdn-gpios: A GPIO specifier for the GPIO controlling
> + the power down & reset pin.

reset-gpios like the Asahi Kasei ADC under review.
 
> +- asahi-kasei,mute-gpios: A GPIO specifier for the GPIO controlling
> + the soft mute pin.

State the active state.

> +
> +Example:
> +
> + {
> + ak4458: ak4458@10 {

dac@10

> + compatible = "asahi-kasei,ak4458";
> + reg = <0x10>;
> + asahi-kasei,pdn-gpios = < 10 GPIO_ACTIVE_HIGH>
> + asahi-kasei,mute-gpios = < 11 GPIO_ACTIVE_HIGH>
> + };
> +};

Re: [PATCHv2] tlv320dac33: Add device tree bindings

[Rob Herring]

On Wed, Jan 31, 2018 at 08:01:12PM +0100, Pavel Machek wrote:
> 
> This adds device tree bindings for tlv320dac33.c.
> 
> Signed-off-by: Pavel Machek 
> 
> diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt 
> b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> new file mode 100644
> index 000..7fdda95
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> @@ -0,0 +1,32 @@
> +Texas Instruments - tlv320dac33 Codec module
> +
> +The tlv320dac33 serial control bus communicates through I2C protocols.
> +
> +Required properties:
> +
> +- compatible - "ti,tlv320dac33"
> +- reg - I2C slave address
> +
> +Optional properties:
> +
> +- reset-gpios - gpio pin to power the device, active low
> +
> +- interrupts   - The interrupt output from the device.
> +- interrupt-parent - The parent interrupt controller.
> +
> +- ti,keep-bclk   - Keep the BCLK running in FIFO modes

space before tab ^

> +- ti,burst-bclkdiv - BCLK divider value in burst mode

What are valid values? What's the default?

> +
> +Example:
> +
> +tlv320dac33: audio-codec@19 {
> + compatible = "ti,tlv320dac33";
> + reg = <0x19>;
> +
> + interrupt-parent = <>;
> + interrupts = <21 1>; /* gpio_53, IRQF_TRIGGER_RISING */
> + reset-gpios = < 28 0>; /* gpio_60 */
> +
> + ti,keep-bclk;
> + ti,burst-bclkdiv = <3>;
> +};
> 
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCHv2] tlv320dac33: Add device tree bindings

[Rob Herring]

On Wed, Jan 31, 2018 at 08:01:12PM +0100, Pavel Machek wrote:
> 
> This adds device tree bindings for tlv320dac33.c.
> 
> Signed-off-by: Pavel Machek 
> 
> diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt 
> b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> new file mode 100644
> index 000..7fdda95
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> @@ -0,0 +1,32 @@
> +Texas Instruments - tlv320dac33 Codec module
> +
> +The tlv320dac33 serial control bus communicates through I2C protocols.
> +
> +Required properties:
> +
> +- compatible - "ti,tlv320dac33"
> +- reg - I2C slave address
> +
> +Optional properties:
> +
> +- reset-gpios - gpio pin to power the device, active low
> +
> +- interrupts   - The interrupt output from the device.
> +- interrupt-parent - The parent interrupt controller.
> +
> +- ti,keep-bclk   - Keep the BCLK running in FIFO modes

space before tab ^

> +- ti,burst-bclkdiv - BCLK divider value in burst mode

What are valid values? What's the default?

> +
> +Example:
> +
> +tlv320dac33: audio-codec@19 {
> + compatible = "ti,tlv320dac33";
> + reg = <0x19>;
> +
> + interrupt-parent = <>;
> + interrupts = <21 1>; /* gpio_53, IRQF_TRIGGER_RISING */
> + reset-gpios = < 28 0>; /* gpio_60 */
> +
> + ti,keep-bclk;
> + ti,burst-bclkdiv = <3>;
> +};
> 
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector

[Rob Herring]

On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
> These bindings allow to describe most known standard USB connectors
> and it should be possible to extend it if necessary.
> USB connectors, beside USB can be used to route other protocols,
> for example UART, Audio, MHL. In such case every device passing data
> through the connector should have appropriate graph bindings.
> 
> Signed-off-by: Andrzej Hajda 
> ---
> v2:
> - moved connector type(A,B,C) to compatible string (Rob),
> - renamed size property to type (Rob),
> - changed type description to be less confusing (Laurent),
> - removed vendor specific compatibles (implied by graph port number),

How so? More below...

> - added requirement of connector being a child of IC (Rob),
> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>   by USB Controller in runtime, downside is that device is not able to
>   report its real capabilities, maybe better would be to make it optional(?)),
> - assigned port numbers to data buses (Rob).
> 
> Regards
> Andrzej
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  .../bindings/connector/usb-connector.txt   | 48 
> ++
>  1 file changed, 48 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/connector/usb-connector.txt
> 
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> new file mode 100644
> index ..02020f5d760a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -0,0 +1,48 @@
> +USB Connector
> +=
> +
> +USB connector node represents physical USB connector. It should be
> +a child of USB interface controller.
> +
> +Required properties:
> +- compatible: describes type of the connector, must be one of:
> +"usb-a-connector", "usb-b-connector", "usb-c-connector",

Nit: one per line.

> +
> +Optional properties:
> +- label: symbolic name for the connector
> +- type: size of the connector, should be specified in case of USB-A, USB-B
> +  non-standard (large) connector sizes: "mini", "micro"
> +
> +Required nodes:
> +- any data bus to the connector should be modeled using the OF graph bindings
> +  specified in bindings/graph.txt, unless the bus is between parent node and
> +  the connector. Since single connector can have multpile data buses every 
> bus
> +  has assigned OF graph port number as follows:
> +0: High Speed (HS), present in all connectors,
> +1: Super Speed (SS), present in SS capable connectors,
> +2: Sideband use (SBU), present in USB-C,
> +3: Mobile High-Definition Link (MHL), present in 11-pin Samsung micro-USB

This is un-muxed unlike Type-C where the signals are muxed with USB SS. 
That makes me think the Samsung connector should have its own compatible 
string.

Can we go ahead and define the video modes of Type-C? Normally, if 2 
data streams are mutually exclusive, then they are a single port with 2 
endpoints. So we'd either have 2 endpoints on port 1 or we stick with 
port 3 is always video. We can still know what is mutually exclusive 
based on the compatible. 

> +
> +Example
> +---
> +
> +muic_max77843@66 {
> + ...
> + musb_con: connector {
> + compatible = "usb-b-connector";
> + label = "micro-USB";
> + type = "micro";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@3 {
> + reg = <3>;
> + musb_con_mhl_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> +};
> -- 
> 2.15.1
> 

Re: [PATCH v2 1/3] Documentation: dt-bindings: arm: Document kryo385 cpu

[Rob Herring]

On Wed, Jan 31, 2018 at 09:49:39PM +0530, Rajendra Nayak wrote:
> Document the compatible string for the Kryo385 cpus found in qualcomm
> SoCs.
> 
> Signed-off-by: Rajendra Nayak 
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt | 1 +
>  1 file changed, 1 insertion(+)

"dt-bindings: arm: " for the subject prefix. Otherwise,

Reviewed-by: Rob Herring 

Re: [PATCH V2 1/2] ARM: dts: imx7s: add temperature monitor support

[Shawn Guo]

On Fri, Jan 26, 2018 at 04:09:39PM +0800, Anson Huang wrote:
> Add i.MX7 temperature monitor support.
> 
> Signed-off-by: Anson Huang 
> Acked-by: Dong Aisheng 
> ---
> no changes since V1.
>  .../devicetree/bindings/thermal/imx-thermal.txt  |  5 +++--

The bindings doc should be a separate patch or part of related
imx-thermal driver patch ...

>  arch/arm/boot/dts/imx7s.dtsi | 20 
> 

..., and shouldn't be mixed with dts changes.

Shawn

Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector

[Rob Herring]

On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
> These bindings allow to describe most known standard USB connectors
> and it should be possible to extend it if necessary.
> USB connectors, beside USB can be used to route other protocols,
> for example UART, Audio, MHL. In such case every device passing data
> through the connector should have appropriate graph bindings.
> 
> Signed-off-by: Andrzej Hajda 
> ---
> v2:
> - moved connector type(A,B,C) to compatible string (Rob),
> - renamed size property to type (Rob),
> - changed type description to be less confusing (Laurent),
> - removed vendor specific compatibles (implied by graph port number),

How so? More below...

> - added requirement of connector being a child of IC (Rob),
> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>   by USB Controller in runtime, downside is that device is not able to
>   report its real capabilities, maybe better would be to make it optional(?)),
> - assigned port numbers to data buses (Rob).
> 
> Regards
> Andrzej
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  .../bindings/connector/usb-connector.txt   | 48 
> ++
>  1 file changed, 48 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/connector/usb-connector.txt
> 
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> new file mode 100644
> index ..02020f5d760a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -0,0 +1,48 @@
> +USB Connector
> +=
> +
> +USB connector node represents physical USB connector. It should be
> +a child of USB interface controller.
> +
> +Required properties:
> +- compatible: describes type of the connector, must be one of:
> +"usb-a-connector", "usb-b-connector", "usb-c-connector",

Nit: one per line.

> +
> +Optional properties:
> +- label: symbolic name for the connector
> +- type: size of the connector, should be specified in case of USB-A, USB-B
> +  non-standard (large) connector sizes: "mini", "micro"
> +
> +Required nodes:
> +- any data bus to the connector should be modeled using the OF graph bindings
> +  specified in bindings/graph.txt, unless the bus is between parent node and
> +  the connector. Since single connector can have multpile data buses every 
> bus
> +  has assigned OF graph port number as follows:
> +0: High Speed (HS), present in all connectors,
> +1: Super Speed (SS), present in SS capable connectors,
> +2: Sideband use (SBU), present in USB-C,
> +3: Mobile High-Definition Link (MHL), present in 11-pin Samsung micro-USB

This is un-muxed unlike Type-C where the signals are muxed with USB SS. 
That makes me think the Samsung connector should have its own compatible 
string.

Can we go ahead and define the video modes of Type-C? Normally, if 2 
data streams are mutually exclusive, then they are a single port with 2 
endpoints. So we'd either have 2 endpoints on port 1 or we stick with 
port 3 is always video. We can still know what is mutually exclusive 
based on the compatible. 

> +
> +Example
> +---
> +
> +muic_max77843@66 {
> + ...
> + musb_con: connector {
> + compatible = "usb-b-connector";
> + label = "micro-USB";
> + type = "micro";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@3 {
> + reg = <3>;
> + musb_con_mhl_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> +};
> -- 
> 2.15.1
> 

Re: [PATCH v2 1/3] Documentation: dt-bindings: arm: Document kryo385 cpu

[Rob Herring]

On Wed, Jan 31, 2018 at 09:49:39PM +0530, Rajendra Nayak wrote:
> Document the compatible string for the Kryo385 cpus found in qualcomm
> SoCs.
> 
> Signed-off-by: Rajendra Nayak 
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt | 1 +
>  1 file changed, 1 insertion(+)

"dt-bindings: arm: " for the subject prefix. Otherwise,

Reviewed-by: Rob Herring 

Re: [PATCH V2 1/2] ARM: dts: imx7s: add temperature monitor support

[Shawn Guo]

On Fri, Jan 26, 2018 at 04:09:39PM +0800, Anson Huang wrote:
> Add i.MX7 temperature monitor support.
> 
> Signed-off-by: Anson Huang 
> Acked-by: Dong Aisheng 
> ---
> no changes since V1.
>  .../devicetree/bindings/thermal/imx-thermal.txt  |  5 +++--

The bindings doc should be a separate patch or part of related
imx-thermal driver patch ...

>  arch/arm/boot/dts/imx7s.dtsi | 20 
> 

..., and shouldn't be mixed with dts changes.

Shawn

Re: [PATCH v3 1/2] ARM: dts: imx25-pinfunc: Use consistent naming for eSDHC

[Rob Herring]

On Wed, Jan 31, 2018 at 10:35:43PM +0100, Benoît Thébaudeau wrote:
> This file had several naming inconsistencies for eSDHC:
>  - the instances were named sometimes SDn, sometimes SDHCn, whereas they
>are named ESDHCn in the reference manual, e.g.:
>  MX25_PAD_SD1_CMD__SD1_CMD
>  MX25_PAD_D15__SDHC1_DAT7
>  - the data ports were named sometimes DATAn, sometimes DATn like in the
>reference manual, e.g.:
>  MX25_PAD_SD1_DATA0__SD1_DATA0
>  MX25_PAD_D15__SDHC1_DAT7
>  - in one case, the clock port was named DAT_CLK instead of CLK:
>  MX25_PAD_CSI_D7__SDHC2_DAT_CLK
> 
> This change:
>  - introduces new definitions using the naming from the reference
>manual,
>  - keeps definitions using the legacy naming in order not to break
>compatibility for out-of-tree users (they can be removed later),
>  - updates the in-tree files that were using the legacy naming.
> 
> Cc: Uwe Kleine-König 
> Signed-off-by: Benoît Thébaudeau 
> Acked-by: Uwe Kleine-König 
> ---
> Changes v2 -> v3:
>  - None.
> Changes v1 -> v2:
>  - New patch (suggested by Uwe).
> ---
>  .../boot/dts/imx25-eukrea-mbimxsd25-baseboard.dts  | 12 ++--
>  arch/arm/boot/dts/imx25-pdk.dts| 12 ++--
>  arch/arm/boot/dts/imx25-pinfunc.h  | 72 
> ++
>  3 files changed, 60 insertions(+), 36 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH v3 1/2] ARM: dts: imx25-pinfunc: Use consistent naming for eSDHC

[Rob Herring]

On Wed, Jan 31, 2018 at 10:35:43PM +0100, Benoît Thébaudeau wrote:
> This file had several naming inconsistencies for eSDHC:
>  - the instances were named sometimes SDn, sometimes SDHCn, whereas they
>are named ESDHCn in the reference manual, e.g.:
>  MX25_PAD_SD1_CMD__SD1_CMD
>  MX25_PAD_D15__SDHC1_DAT7
>  - the data ports were named sometimes DATAn, sometimes DATn like in the
>reference manual, e.g.:
>  MX25_PAD_SD1_DATA0__SD1_DATA0
>  MX25_PAD_D15__SDHC1_DAT7
>  - in one case, the clock port was named DAT_CLK instead of CLK:
>  MX25_PAD_CSI_D7__SDHC2_DAT_CLK
> 
> This change:
>  - introduces new definitions using the naming from the reference
>manual,
>  - keeps definitions using the legacy naming in order not to break
>compatibility for out-of-tree users (they can be removed later),
>  - updates the in-tree files that were using the legacy naming.
> 
> Cc: Uwe Kleine-König 
> Signed-off-by: Benoît Thébaudeau 
> Acked-by: Uwe Kleine-König 
> ---
> Changes v2 -> v3:
>  - None.
> Changes v1 -> v2:
>  - New patch (suggested by Uwe).
> ---
>  .../boot/dts/imx25-eukrea-mbimxsd25-baseboard.dts  | 12 ++--
>  arch/arm/boot/dts/imx25-pdk.dts| 12 ++--
>  arch/arm/boot/dts/imx25-pinfunc.h  | 72 
> ++
>  3 files changed, 60 insertions(+), 36 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH] fbdev: simplefb: add support for 'memory-region' property on DT node

[Rob Herring]

On Thu, Feb 01, 2018 at 04:56:08PM +0100, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Tuesday, January 23, 2018 08:34:56 PM Kunihiko Hayashi wrote:
> > Enables 'memory-region' property referring to the memory description on
> > the reserved-memory node in case of devicetree use.
> > If there is no 'reg' property that specifies the address and size of
> > the framebuffer, the address and size written in the memory description
> > on the reserved-memory node can be used for the framebuffer.
> > 
> > Furthermore, the reserved-memory node needs to have "no-map" attributes
> > because simplefb driver maps the region by ioremap_wc().
> > 
> > Signed-off-by: Kunihiko Hayashi 
> 
> This needs an ACK from Rob or Mark (DT bindings Maintainers).
> 
> > ---
> >  .../bindings/display/simple-framebuffer.txt|  3 ++
> >  drivers/video/fbdev/simplefb.c | 32 
> > ++
> >  2 files changed, 35 insertions(+)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/simple-framebuffer.txt 
> > b/Documentation/devicetree/bindings/display/simple-framebuffer.txt
> > index 5a9ce51..be5139f 100644
> > --- a/Documentation/devicetree/bindings/display/simple-framebuffer.txt
> > +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.txt
> > @@ -56,6 +56,9 @@ Optional properties:
> >framebuffer remains active.
> >  
> >  - display : phandle pointing to the primary display hardware node
> > +- memory-region: phandle to a node describing memory region as framebuffer
> > +memory instead of reg property. The node should include
> > +'no-map'.

This should also state when it's appropriate to use this instead of reg. 
The memory would only be reclaimed if reg is used.

Though I'm wondering what keeps the simple fb memory from getting used 
by the OS if reserved memory is not always used.

Rob

Re: [PATCH 2/2] soc: mediatek: add SCPSYS power domain driver for MediaTek MT7623A SoC

[Rob Herring]

On Thu, Feb 01, 2018 at 06:12:48PM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Add SCPSYS power domain driver for MT7623A SoC. The MT7623A's power
> domains are the subset of MT7623 SoC's ones. As MT7623 SoC has full
> features whereas MT7623A is being designed just for router applications.
> Thus, MT7623A doesn't include those power domains multimedia function
> belongs to. In order to avoid certain errors undoubtedly happening at
> registering those power domains on MT7623A SoC using the existing MT7623
> SCPSYS driver, it's required to define another setup specifically for
> MT7623A SoC. Also, use a meaningful definition for bus_prot_mask instead
> of just hardcoded for it.
> 
> Signed-off-by: Sean Wang 
> ---
>  drivers/soc/mediatek/mtk-scpsys.c | 60 
> +--

>  include/dt-bindings/power/mt7623a-power.h | 10 ++

This belongs in the binding patch.

>  include/linux/soc/mediatek/infracfg.h |  4 +++
>  3 files changed, 72 insertions(+), 2 deletions(-)
>  create mode 100644 include/dt-bindings/power/mt7623a-power.h
> 

Re: [PATCH] fbdev: simplefb: add support for 'memory-region' property on DT node

[Rob Herring]

On Thu, Feb 01, 2018 at 04:56:08PM +0100, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Tuesday, January 23, 2018 08:34:56 PM Kunihiko Hayashi wrote:
> > Enables 'memory-region' property referring to the memory description on
> > the reserved-memory node in case of devicetree use.
> > If there is no 'reg' property that specifies the address and size of
> > the framebuffer, the address and size written in the memory description
> > on the reserved-memory node can be used for the framebuffer.
> > 
> > Furthermore, the reserved-memory node needs to have "no-map" attributes
> > because simplefb driver maps the region by ioremap_wc().
> > 
> > Signed-off-by: Kunihiko Hayashi 
> 
> This needs an ACK from Rob or Mark (DT bindings Maintainers).
> 
> > ---
> >  .../bindings/display/simple-framebuffer.txt|  3 ++
> >  drivers/video/fbdev/simplefb.c | 32 
> > ++
> >  2 files changed, 35 insertions(+)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/simple-framebuffer.txt 
> > b/Documentation/devicetree/bindings/display/simple-framebuffer.txt
> > index 5a9ce51..be5139f 100644
> > --- a/Documentation/devicetree/bindings/display/simple-framebuffer.txt
> > +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.txt
> > @@ -56,6 +56,9 @@ Optional properties:
> >framebuffer remains active.
> >  
> >  - display : phandle pointing to the primary display hardware node
> > +- memory-region: phandle to a node describing memory region as framebuffer
> > +memory instead of reg property. The node should include
> > +'no-map'.

This should also state when it's appropriate to use this instead of reg. 
The memory would only be reclaimed if reg is used.

Though I'm wondering what keeps the simple fb memory from getting used 
by the OS if reserved memory is not always used.

Rob

Re: [PATCH 2/2] soc: mediatek: add SCPSYS power domain driver for MediaTek MT7623A SoC

[Rob Herring]

On Thu, Feb 01, 2018 at 06:12:48PM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Add SCPSYS power domain driver for MT7623A SoC. The MT7623A's power
> domains are the subset of MT7623 SoC's ones. As MT7623 SoC has full
> features whereas MT7623A is being designed just for router applications.
> Thus, MT7623A doesn't include those power domains multimedia function
> belongs to. In order to avoid certain errors undoubtedly happening at
> registering those power domains on MT7623A SoC using the existing MT7623
> SCPSYS driver, it's required to define another setup specifically for
> MT7623A SoC. Also, use a meaningful definition for bus_prot_mask instead
> of just hardcoded for it.
> 
> Signed-off-by: Sean Wang 
> ---
>  drivers/soc/mediatek/mtk-scpsys.c | 60 
> +--

>  include/dt-bindings/power/mt7623a-power.h | 10 ++

This belongs in the binding patch.

>  include/linux/soc/mediatek/infracfg.h |  4 +++
>  3 files changed, 72 insertions(+), 2 deletions(-)
>  create mode 100644 include/dt-bindings/power/mt7623a-power.h
> 

Re: [PATCH 1/3] dt-bindings: pwm-stm32-lp: add #pwm-cells

[Rob Herring]

On Thu, Feb 01, 2018 at 02:44:36PM +0100, Fabrice Gasnier wrote:
> From: Gerald Baeza 
> 
> STM32 Low-Power Timer supports generic 3 cells pwm to encode
> PWM number, period and polarity.
> 
> Signed-off-by: Gerald Baeza 
> Signed-off-by: Fabrice Gasnier 
> ---
>  Documentation/devicetree/bindings/pwm/pwm-stm32-lp.txt | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Rob Herring 

Re: [PATCH v2 2/2] ASoC: ak5558: Add bindings for AK5558 ADC

[Rob Herring]

On Fri, Feb 02, 2018 at 06:20:06PM +0200, Daniel Baluta wrote:
> Signed-off-by: Daniel Baluta 
> ---
>  Documentation/devicetree/bindings/sound/ak5558.txt | 23 
> ++
>  1 file changed, 23 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/ak5558.txt
> 
> diff --git a/Documentation/devicetree/bindings/sound/ak5558.txt 
> b/Documentation/devicetree/bindings/sound/ak5558.txt
> new file mode 100644
> index 000..61c85568
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/ak5558.txt
> @@ -0,0 +1,23 @@
> +AK5558 8 channel differential 32-bit delta-sigma ADC
> +
> +This device supports I2C mode only.
> +
> +Required properties:
> +
> +- compatible : "asahi-kasei,ak5558"
> +- reg : The I2C address of the device for I2C.
> +
> +Optional properties:
> +
> +- reset-gpios: A GPIO specifier for the GPIO controlling
> + the power down & reset pin.
> +
> +Example:
> +
> + {
> + ak5558: ak5558@10 {

adc@10

> + compatible = "asahi-kasei,ak5558";
> + reg = <0x10>;
> + reset-gpios = < 10 GPIO_ACTIVE_LOW>;
> + };
> +};
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] dt-bindings: pwm-stm32-lp: add #pwm-cells

[Rob Herring]

On Thu, Feb 01, 2018 at 02:44:36PM +0100, Fabrice Gasnier wrote:
> From: Gerald Baeza 
> 
> STM32 Low-Power Timer supports generic 3 cells pwm to encode
> PWM number, period and polarity.
> 
> Signed-off-by: Gerald Baeza 
> Signed-off-by: Fabrice Gasnier 
> ---
>  Documentation/devicetree/bindings/pwm/pwm-stm32-lp.txt | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Rob Herring 

Re: [PATCH v2 2/2] ASoC: ak5558: Add bindings for AK5558 ADC

[Rob Herring]

On Fri, Feb 02, 2018 at 06:20:06PM +0200, Daniel Baluta wrote:
> Signed-off-by: Daniel Baluta 
> ---
>  Documentation/devicetree/bindings/sound/ak5558.txt | 23 
> ++
>  1 file changed, 23 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/ak5558.txt
> 
> diff --git a/Documentation/devicetree/bindings/sound/ak5558.txt 
> b/Documentation/devicetree/bindings/sound/ak5558.txt
> new file mode 100644
> index 000..61c85568
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/ak5558.txt
> @@ -0,0 +1,23 @@
> +AK5558 8 channel differential 32-bit delta-sigma ADC
> +
> +This device supports I2C mode only.
> +
> +Required properties:
> +
> +- compatible : "asahi-kasei,ak5558"
> +- reg : The I2C address of the device for I2C.
> +
> +Optional properties:
> +
> +- reset-gpios: A GPIO specifier for the GPIO controlling
> + the power down & reset pin.
> +
> +Example:
> +
> + {
> + ak5558: ak5558@10 {

adc@10

> + compatible = "asahi-kasei,ak5558";
> + reg = <0x10>;
> + reset-gpios = < 10 GPIO_ACTIVE_LOW>;
> + };
> +};
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/14] dt-bindings: Document STM32MP1 Reset Clock Controller (RCC) bindings

[Rob Herring]

On Fri, Feb 02, 2018 at 03:03:29PM +0100, gabriel.fernan...@st.com wrote:
> From: Gabriel Fernandez 
> 
> The RCC block is responsible of the management of the clock and reset
> generation for the complete circuit.
> 
> Signed-off-by: Gabriel Fernandez 
> ---
>  .../devicetree/bindings/mfd/st,stm32-rcc.txt   | 85 
> ++
>  1 file changed, 85 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt 
> b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
> new file mode 100644
> index 000..28017a1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
> @@ -0,0 +1,85 @@
> +STMicroelectronics STM32 Peripheral Reset Clock Controller
> +==
> +
> +The RCC IP is both a reset and a clock controller.
> +
> +Please also refer to reset.txt for common reset controller binding usage.
> +
> +Please also refer to clock-bindings.txt for common clock controller
> +binding usage.
> +
> +
> +Required properties:
> +- compatible: "simple-mfd", "syscon"


> +- reg: should be register base and length as documented in the datasheet
> +
> +- Sub-nodes:
> +  - compatible: "st,stm32mp1-rcc-clk"
> + - #clock-cells: 1, device nodes should specify the clock in their
> +   "clocks" property, containing a phandle to the clock device node,
> +   an index specifying the clock to use.
> +
> +  - compatible: "st,stm32mp1-rcc-rst"
> + - #reset-cells: Shall be 1
> +
> +Example:
> + rcc: rcc@5000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x5000 0x1000>;
> +
> + rcc_clk: rcc-clk@5000 {
> + #clock-cells = <1>;
> + compatible = "st,stm32mp1-rcc-clk";
> + };
> +
> + rcc_rst: rcc-reset@5000 {

You should not have the same unit-address twice.

IMO, this should just be:

rcc: rcc@5000 {
compatible = "st-stm32mp1-rcc";
reg = <0x5000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};

There's no reason a node can't provide more than 1 function.


> + #reset-cells = <1>;
> + compatible = "st,stm32mp1-rcc-rst";
> + };
> + };
> +
> +Specifying clocks
> +=
> +
> +All available clocks are defined as preprocessor macros in
> +dt-bindings/clock/stm32mp1-clks.h header and can be used in device
> +tree sources.
> +
> +Example:
> +
> + /* Accessing DMA1 clock */
> + ... {
> + clocks = <_clk DMA1>
> + };
> +
> + /* Accessing SPI6 kernel clock */
> + ... {
> + clocks = <_clk SPI6_K>
> + };

Other than the path to header, the clock binding explains all this. No 
need to duplicate here.

> +
> +Specifying softreset control of devices
> +===
> +
> +Device nodes should specify the reset channel required in their "resets"
> +property, containing a phandle to the reset device node and an index 
> specifying
> +which channel to use.
> +The index is the bit number within the RCC registers bank, starting from RCC
> +base address.
> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
> +Where bit_offset is the bit offset within the register.
> +
> +For example on STM32MP1, for LTDC reset:
> + ltdc = APB4_RSTSETR_offset / 4 * 32 + LTDC_bit_offset
> +  = 0x180 / 4 * 32 + 0 = 3072
> +
> +The list of valid indices for STM32MP1 is available in:
> +include/dt-bindings/reset-controller/stm32mp1-resets.h
> +
> +This file implements defines like:
> +#define LTDC_R   3072
> +
> +example:
> +
> + ltdc {
> + resets = <_rst LTDC_R>;
> + };
> -- 
> 1.9.1
> 

Re: [PATCH 01/14] dt-bindings: Document STM32MP1 Reset Clock Controller (RCC) bindings

[Rob Herring]

On Fri, Feb 02, 2018 at 03:03:29PM +0100, gabriel.fernan...@st.com wrote:
> From: Gabriel Fernandez 
> 
> The RCC block is responsible of the management of the clock and reset
> generation for the complete circuit.
> 
> Signed-off-by: Gabriel Fernandez 
> ---
>  .../devicetree/bindings/mfd/st,stm32-rcc.txt   | 85 
> ++
>  1 file changed, 85 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt 
> b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
> new file mode 100644
> index 000..28017a1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
> @@ -0,0 +1,85 @@
> +STMicroelectronics STM32 Peripheral Reset Clock Controller
> +==
> +
> +The RCC IP is both a reset and a clock controller.
> +
> +Please also refer to reset.txt for common reset controller binding usage.
> +
> +Please also refer to clock-bindings.txt for common clock controller
> +binding usage.
> +
> +
> +Required properties:
> +- compatible: "simple-mfd", "syscon"


> +- reg: should be register base and length as documented in the datasheet
> +
> +- Sub-nodes:
> +  - compatible: "st,stm32mp1-rcc-clk"
> + - #clock-cells: 1, device nodes should specify the clock in their
> +   "clocks" property, containing a phandle to the clock device node,
> +   an index specifying the clock to use.
> +
> +  - compatible: "st,stm32mp1-rcc-rst"
> + - #reset-cells: Shall be 1
> +
> +Example:
> + rcc: rcc@5000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x5000 0x1000>;
> +
> + rcc_clk: rcc-clk@5000 {
> + #clock-cells = <1>;
> + compatible = "st,stm32mp1-rcc-clk";
> + };
> +
> + rcc_rst: rcc-reset@5000 {

You should not have the same unit-address twice.

IMO, this should just be:

rcc: rcc@5000 {
compatible = "st-stm32mp1-rcc";
reg = <0x5000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};

There's no reason a node can't provide more than 1 function.


> + #reset-cells = <1>;
> + compatible = "st,stm32mp1-rcc-rst";
> + };
> + };
> +
> +Specifying clocks
> +=
> +
> +All available clocks are defined as preprocessor macros in
> +dt-bindings/clock/stm32mp1-clks.h header and can be used in device
> +tree sources.
> +
> +Example:
> +
> + /* Accessing DMA1 clock */
> + ... {
> + clocks = <_clk DMA1>
> + };
> +
> + /* Accessing SPI6 kernel clock */
> + ... {
> + clocks = <_clk SPI6_K>
> + };

Other than the path to header, the clock binding explains all this. No 
need to duplicate here.

> +
> +Specifying softreset control of devices
> +===
> +
> +Device nodes should specify the reset channel required in their "resets"
> +property, containing a phandle to the reset device node and an index 
> specifying
> +which channel to use.
> +The index is the bit number within the RCC registers bank, starting from RCC
> +base address.
> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
> +Where bit_offset is the bit offset within the register.
> +
> +For example on STM32MP1, for LTDC reset:
> + ltdc = APB4_RSTSETR_offset / 4 * 32 + LTDC_bit_offset
> +  = 0x180 / 4 * 32 + 0 = 3072
> +
> +The list of valid indices for STM32MP1 is available in:
> +include/dt-bindings/reset-controller/stm32mp1-resets.h
> +
> +This file implements defines like:
> +#define LTDC_R   3072
> +
> +example:
> +
> + ltdc {
> + resets = <_rst LTDC_R>;
> + };
> -- 
> 1.9.1
> 

Re: [PATCH v3 1/3] dt-bindings: dmaengine: Add MediaTek High-Speed DMA controller bindings

[Rob Herring]

On Thu, Feb 01, 2018 at 11:45:23AM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Document the devicetree bindings for MediaTek High-Speed DMA controller
> which could be found on MT7623 SoC or other similar Mediatek SoCs.
> 
> Signed-off-by: Sean Wang 
> ---
>  .../devicetree/bindings/dma/mtk-hsdma.txt  | 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/mtk-hsdma.txt
> 
> diff --git a/Documentation/devicetree/bindings/dma/mtk-hsdma.txt 
> b/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
> new file mode 100644
> index 000..c07c03e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
> @@ -0,0 +1,33 @@
> +MediaTek High-Speed DMA Controller
> +==
> +
> +This driver follows the generic DMA bindings defined in dma/dma.txt.

Bindings describe h/w, not drivers.

> +
> +Required properties:
> +
> +- compatible:Must be one of
> +   "mediatek,mt7622-hsdma": for MT7622 SoC
> +   "mediatek,mt7623-hsdma": for MT7623 SoC
> +- reg:   Should contain the register's base address and length.
> +- interrupts:Should contain a reference to the interrupt used by this
> + device.
> +- clocks:Should be the clock specifiers corresponding to the entry in
> + clock-names property.
> +- clock-names:   Should contain "hsdma" entries.
> +- power-domains: Phandle to the power domain that the device is part of
> +- #dma-cells:The length of the DMA specifier, must be <1>. This one 
> cell
> + in dmas property of a client device represents the channel
> + number.
> +Example:
> +
> +hsdma: hsdma@1b007000 {

dma-controller@...

> + compatible = "mediatek,mt7623-hsdma";
> + reg = <0 0x1b007000 0 0x1000>;
> + interrupts = ;
> + clocks = < CLK_ETHSYS_HSDMA>;
> + clock-names = "hsdma";
> + power-domains = < MT2701_POWER_DOMAIN_ETH>;
> + #dma-cells = <1>;
> + };
> +
> +DMA clients must use the format described in dma/dma.txt file.
> -- 
> 2.7.4
> 

Re: [PATCH 1/2] dt-bindings: fsi: Add optional property no-scan-on-init

[Joel Stanley]

On Mon, Feb 5, 2018 at 4:37 PM, Rob Herring  wrote:
> On Tue, Jan 30, 2018 at 04:21:15PM +1030, Joel Stanley wrote:
>> From: Christopher Bostic 
>>
>> Add an optional FSI master property 'no-scan-on-init.  This
>> can be specified to indicate that a master should not be
>> automatically scanned at init time.  This is required in cases
>> where a scan could interfere with another FSI master on the same
>> bus.
>>
>> Signed-off-by: Christopher Bostic 
>> Acked-by: Jeremy Kerr 
>> Signed-off-by: Joel Stanley 
>> ---
>>  Documentation/devicetree/bindings/fsi/fsi.txt | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/fsi/fsi.txt 
>> b/Documentation/devicetree/bindings/fsi/fsi.txt
>> index 4eaf488d4015..ab516c673a4b 100644
>> --- a/Documentation/devicetree/bindings/fsi/fsi.txt
>> +++ b/Documentation/devicetree/bindings/fsi/fsi.txt
>> @@ -56,6 +56,13 @@ addresses (link index and slave ID), and no size:
>>  #address-cells = <2>;
>>  #size-cells = <0>;
>>
>> +An optional boolean property can be added to indicate that a particular 
>> master
>> +should not scan for connected devices at initialization time.  This is
>> +necessary in cases where a scan could cause arbitration issues with other
>> +masters that may be present on the bus.
>> +
>> +no-scan-on-init;
>> +
>
> The formatting here is a bit strange compared to most bindings, but no
> point in reformatting the document to add one property.

I'll keep that in mind next time we're working in this area.

Thanks Rob.

>
> Reviewed-by: Rob Herring 
>
> Rob

Re: [PATCH v3 1/3] dt-bindings: dmaengine: Add MediaTek High-Speed DMA controller bindings

[Rob Herring]

On Thu, Feb 01, 2018 at 11:45:23AM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Document the devicetree bindings for MediaTek High-Speed DMA controller
> which could be found on MT7623 SoC or other similar Mediatek SoCs.
> 
> Signed-off-by: Sean Wang 
> ---
>  .../devicetree/bindings/dma/mtk-hsdma.txt  | 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/mtk-hsdma.txt
> 
> diff --git a/Documentation/devicetree/bindings/dma/mtk-hsdma.txt 
> b/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
> new file mode 100644
> index 000..c07c03e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
> @@ -0,0 +1,33 @@
> +MediaTek High-Speed DMA Controller
> +==
> +
> +This driver follows the generic DMA bindings defined in dma/dma.txt.

Bindings describe h/w, not drivers.

> +
> +Required properties:
> +
> +- compatible:Must be one of
> +   "mediatek,mt7622-hsdma": for MT7622 SoC
> +   "mediatek,mt7623-hsdma": for MT7623 SoC
> +- reg:   Should contain the register's base address and length.
> +- interrupts:Should contain a reference to the interrupt used by this
> + device.
> +- clocks:Should be the clock specifiers corresponding to the entry in
> + clock-names property.
> +- clock-names:   Should contain "hsdma" entries.
> +- power-domains: Phandle to the power domain that the device is part of
> +- #dma-cells:The length of the DMA specifier, must be <1>. This one 
> cell
> + in dmas property of a client device represents the channel
> + number.
> +Example:
> +
> +hsdma: hsdma@1b007000 {

dma-controller@...

> + compatible = "mediatek,mt7623-hsdma";
> + reg = <0 0x1b007000 0 0x1000>;
> + interrupts = ;
> + clocks = < CLK_ETHSYS_HSDMA>;
> + clock-names = "hsdma";
> + power-domains = < MT2701_POWER_DOMAIN_ETH>;
> + #dma-cells = <1>;
> + };
> +
> +DMA clients must use the format described in dma/dma.txt file.
> -- 
> 2.7.4
> 

Re: [PATCH 1/2] dt-bindings: fsi: Add optional property no-scan-on-init

[Joel Stanley]

On Mon, Feb 5, 2018 at 4:37 PM, Rob Herring  wrote:
> On Tue, Jan 30, 2018 at 04:21:15PM +1030, Joel Stanley wrote:
>> From: Christopher Bostic 
>>
>> Add an optional FSI master property 'no-scan-on-init.  This
>> can be specified to indicate that a master should not be
>> automatically scanned at init time.  This is required in cases
>> where a scan could interfere with another FSI master on the same
>> bus.
>>
>> Signed-off-by: Christopher Bostic 
>> Acked-by: Jeremy Kerr 
>> Signed-off-by: Joel Stanley 
>> ---
>>  Documentation/devicetree/bindings/fsi/fsi.txt | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/fsi/fsi.txt 
>> b/Documentation/devicetree/bindings/fsi/fsi.txt
>> index 4eaf488d4015..ab516c673a4b 100644
>> --- a/Documentation/devicetree/bindings/fsi/fsi.txt
>> +++ b/Documentation/devicetree/bindings/fsi/fsi.txt
>> @@ -56,6 +56,13 @@ addresses (link index and slave ID), and no size:
>>  #address-cells = <2>;
>>  #size-cells = <0>;
>>
>> +An optional boolean property can be added to indicate that a particular 
>> master
>> +should not scan for connected devices at initialization time.  This is
>> +necessary in cases where a scan could cause arbitration issues with other
>> +masters that may be present on the bus.
>> +
>> +no-scan-on-init;
>> +
>
> The formatting here is a bit strange compared to most bindings, but no
> point in reformatting the document to add one property.

I'll keep that in mind next time we're working in this area.

Thanks Rob.

>
> Reviewed-by: Rob Herring 
>
> Rob

Re: [PATCH 02/14] dt-bindings: clock: add STM32MP1 clocks

[Rob Herring]

On Fri, Feb 02, 2018 at 03:03:30PM +0100, gabriel.fernan...@st.com wrote:
> From: Gabriel Fernandez 
> 
> This patch adds the clock binding entry for STM32MP1
> 
> Signed-off-by: Gabriel Fernandez 
> ---
>  include/dt-bindings/clock/stm32mp1-clks.h | 248 
> ++
>  1 file changed, 248 insertions(+)
>  create mode 100644 include/dt-bindings/clock/stm32mp1-clks.h

You can squash this into the previous patch.

Re: [PATCH 02/14] dt-bindings: clock: add STM32MP1 clocks

[Rob Herring]

On Fri, Feb 02, 2018 at 03:03:30PM +0100, gabriel.fernan...@st.com wrote:
> From: Gabriel Fernandez 
> 
> This patch adds the clock binding entry for STM32MP1
> 
> Signed-off-by: Gabriel Fernandez 
> ---
>  include/dt-bindings/clock/stm32mp1-clks.h | 248 
> ++
>  1 file changed, 248 insertions(+)
>  create mode 100644 include/dt-bindings/clock/stm32mp1-clks.h

You can squash this into the previous patch.

Re: [PATCH 1/2] dt-bindings: soc: add SCPSYS binding for MT7623 and MT7623A SoC

[Rob Herring]

On Thu, Feb 01, 2018 at 06:12:47PM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> document the binding for enabling SCPSYS on MediaTek MT7623 and MT7623A
> SoC. Where MT7623 SoC has the same definition about power domains with
> MT2701, so it's fine to using MT2701 ones as MT7623's fallback.
> 
> Signed-off-by: Sean Wang 
> ---
>  Documentation/devicetree/bindings/soc/mediatek/scpsys.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

Re: [PATCH 1/2] dt-bindings: soc: add SCPSYS binding for MT7623 and MT7623A SoC

[Rob Herring]

On Thu, Feb 01, 2018 at 06:12:47PM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> document the binding for enabling SCPSYS on MediaTek MT7623 and MT7623A
> SoC. Where MT7623 SoC has the same definition about power domains with
> MT2701, so it's fine to using MT2701 ones as MT7623's fallback.
> 
> Signed-off-by: Sean Wang 
> ---
>  Documentation/devicetree/bindings/soc/mediatek/scpsys.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

Re: [PATCH 2/2] dt-bindings: PCI: MediaTek: Correct the interrupt-map properties

[Rob Herring]

On Wed, Jan 31, 2018 at 03:41:50PM +0800, Ryder Lee wrote:
> Move the interrupt-map properties from the child nodes to the root node
> and update each entry accordingly.
> 
> Signed-off-by: Ryder Lee 
> ---
>  .../devicetree/bindings/pci/mediatek-pcie.txt  | 28 
> --
>  1 file changed, 15 insertions(+), 13 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH 5/6] scsi: qedi: fix building with LTO

[Rangankar, Manish]

On 02/02/18 6:42 PM, "Arnd Bergmann"  wrote:

>When link-time optimizations are enabled, qedi fails to build because
>of mismatched prototypes:
>
>drivers/scsi/qedi/qedi_gbl.h:27:37: error: type of 'qedi_dbg_fops' does
>not match original declaration [-Werror=lto-type-mismatch]
> extern const struct file_operations qedi_dbg_fops;
> ^
>drivers/scsi/qedi/qedi_debugfs.c:239:30: note: 'qedi_dbg_fops' was
>previously declared here
> const struct file_operations qedi_dbg_fops[] = {
>  ^
>drivers/scsi/qedi/qedi_gbl.h:26:32: error: type of 'qedi_debugfs_ops'
>does not match original declaration [-Werror=lto-type-mismatch]
> extern struct qedi_debugfs_ops qedi_debugfs_ops;
>^
>drivers/scsi/qedi/qedi_debugfs.c:102:25: note: 'qedi_debugfs_ops' was
>previously declared here
> struct qedi_debugfs_ops qedi_debugfs_ops[] = {
>
>This changes the declaration to match the definition, and adapts the
>users as necessary. Since both array can be constant here, I'm adding
>the 'const' everywhere for consistency.
>
>Signed-off-by: Arnd Bergmann 
>---
> drivers/scsi/qedi/qedi_dbg.h | 2 +-
> drivers/scsi/qedi/qedi_debugfs.c | 4 ++--
> drivers/scsi/qedi/qedi_gbl.h | 4 ++--
> drivers/scsi/qedi/qedi_main.c| 4 ++--
> 4 files changed, 7 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/scsi/qedi/qedi_dbg.h b/drivers/scsi/qedi/qedi_dbg.h
>index c55572badfb0..358f40567849 100644
>--- a/drivers/scsi/qedi/qedi_dbg.h
>+++ b/drivers/scsi/qedi/qedi_dbg.h
>@@ -134,7 +134,7 @@ struct qedi_debugfs_ops {
> }
> 
> void qedi_dbg_host_init(struct qedi_dbg_ctx *qedi,
>-  struct qedi_debugfs_ops *dops,
>+  const struct qedi_debugfs_ops *dops,
>   const struct file_operations *fops);
> void qedi_dbg_host_exit(struct qedi_dbg_ctx *qedi);
> void qedi_dbg_init(char *drv_name);
>diff --git a/drivers/scsi/qedi/qedi_debugfs.c
>b/drivers/scsi/qedi/qedi_debugfs.c
>index fd8a1eea3163..fd914ca4149a 100644
>--- a/drivers/scsi/qedi/qedi_debugfs.c
>+++ b/drivers/scsi/qedi/qedi_debugfs.c
>@@ -19,7 +19,7 @@ static struct dentry *qedi_dbg_root;
> 
> void
> qedi_dbg_host_init(struct qedi_dbg_ctx *qedi,
>- struct qedi_debugfs_ops *dops,
>+ const struct qedi_debugfs_ops *dops,
>  const struct file_operations *fops)
> {
>   char host_dirname[32];
>@@ -99,7 +99,7 @@ static struct qedi_list_of_funcs
>qedi_dbg_do_not_recover_ops[] = {
>   { NULL, NULL }
> };
> 
>-struct qedi_debugfs_ops qedi_debugfs_ops[] = {
>+const struct qedi_debugfs_ops qedi_debugfs_ops[] = {
>   { "gbl_ctx", NULL },
>   { "do_not_recover", qedi_dbg_do_not_recover_ops},
>   { "io_trace", NULL },
>diff --git a/drivers/scsi/qedi/qedi_gbl.h b/drivers/scsi/qedi/qedi_gbl.h
>index f5b5a31999aa..a2aa06ed1620 100644
>--- a/drivers/scsi/qedi/qedi_gbl.h
>+++ b/drivers/scsi/qedi/qedi_gbl.h
>@@ -23,8 +23,8 @@ extern uint qedi_io_tracing;
> extern struct scsi_host_template qedi_host_template;
> extern struct iscsi_transport qedi_iscsi_transport;
> extern const struct qed_iscsi_ops *qedi_ops;
>-extern struct qedi_debugfs_ops qedi_debugfs_ops;
>-extern const struct file_operations qedi_dbg_fops;
>+extern const struct qedi_debugfs_ops qedi_debugfs_ops[];
>+extern const struct file_operations qedi_dbg_fops[];
> extern struct device_attribute *qedi_shost_attrs[];
> 
> int qedi_alloc_sq(struct qedi_ctx *qedi, struct qedi_endpoint *ep);
>diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c
>index 029e2e69b29f..e992f9d3ef00 100644
>--- a/drivers/scsi/qedi/qedi_main.c
>+++ b/drivers/scsi/qedi/qedi_main.c
>@@ -2303,8 +2303,8 @@ static int __qedi_probe(struct pci_dev *pdev, int
>mode)
>   }
> 
> #ifdef CONFIG_DEBUG_FS
>-  qedi_dbg_host_init(>dbg_ctx, _debugfs_ops,
>- _dbg_fops);
>+  qedi_dbg_host_init(>dbg_ctx, qedi_debugfs_ops,
>+ qedi_dbg_fops);
> #endif
>   QEDI_INFO(>dbg_ctx, QEDI_LOG_INFO,
> "QLogic FastLinQ iSCSI Module qedi %s, FW %d.%d.%d.%d\n",
>-- 
>2.9.0

Thanks

Acked-by: Manish Rangankar 


>

Re: [PATCH 2/2] dt-bindings: PCI: MediaTek: Correct the interrupt-map properties

[Rob Herring]

On Wed, Jan 31, 2018 at 03:41:50PM +0800, Ryder Lee wrote:
> Move the interrupt-map properties from the child nodes to the root node
> and update each entry accordingly.
> 
> Signed-off-by: Ryder Lee 
> ---
>  .../devicetree/bindings/pci/mediatek-pcie.txt  | 28 
> --
>  1 file changed, 15 insertions(+), 13 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH 5/6] scsi: qedi: fix building with LTO

[Rangankar, Manish]

On 02/02/18 6:42 PM, "Arnd Bergmann"  wrote:

>When link-time optimizations are enabled, qedi fails to build because
>of mismatched prototypes:
>
>drivers/scsi/qedi/qedi_gbl.h:27:37: error: type of 'qedi_dbg_fops' does
>not match original declaration [-Werror=lto-type-mismatch]
> extern const struct file_operations qedi_dbg_fops;
> ^
>drivers/scsi/qedi/qedi_debugfs.c:239:30: note: 'qedi_dbg_fops' was
>previously declared here
> const struct file_operations qedi_dbg_fops[] = {
>  ^
>drivers/scsi/qedi/qedi_gbl.h:26:32: error: type of 'qedi_debugfs_ops'
>does not match original declaration [-Werror=lto-type-mismatch]
> extern struct qedi_debugfs_ops qedi_debugfs_ops;
>^
>drivers/scsi/qedi/qedi_debugfs.c:102:25: note: 'qedi_debugfs_ops' was
>previously declared here
> struct qedi_debugfs_ops qedi_debugfs_ops[] = {
>
>This changes the declaration to match the definition, and adapts the
>users as necessary. Since both array can be constant here, I'm adding
>the 'const' everywhere for consistency.
>
>Signed-off-by: Arnd Bergmann 
>---
> drivers/scsi/qedi/qedi_dbg.h | 2 +-
> drivers/scsi/qedi/qedi_debugfs.c | 4 ++--
> drivers/scsi/qedi/qedi_gbl.h | 4 ++--
> drivers/scsi/qedi/qedi_main.c| 4 ++--
> 4 files changed, 7 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/scsi/qedi/qedi_dbg.h b/drivers/scsi/qedi/qedi_dbg.h
>index c55572badfb0..358f40567849 100644
>--- a/drivers/scsi/qedi/qedi_dbg.h
>+++ b/drivers/scsi/qedi/qedi_dbg.h
>@@ -134,7 +134,7 @@ struct qedi_debugfs_ops {
> }
> 
> void qedi_dbg_host_init(struct qedi_dbg_ctx *qedi,
>-  struct qedi_debugfs_ops *dops,
>+  const struct qedi_debugfs_ops *dops,
>   const struct file_operations *fops);
> void qedi_dbg_host_exit(struct qedi_dbg_ctx *qedi);
> void qedi_dbg_init(char *drv_name);
>diff --git a/drivers/scsi/qedi/qedi_debugfs.c
>b/drivers/scsi/qedi/qedi_debugfs.c
>index fd8a1eea3163..fd914ca4149a 100644
>--- a/drivers/scsi/qedi/qedi_debugfs.c
>+++ b/drivers/scsi/qedi/qedi_debugfs.c
>@@ -19,7 +19,7 @@ static struct dentry *qedi_dbg_root;
> 
> void
> qedi_dbg_host_init(struct qedi_dbg_ctx *qedi,
>- struct qedi_debugfs_ops *dops,
>+ const struct qedi_debugfs_ops *dops,
>  const struct file_operations *fops)
> {
>   char host_dirname[32];
>@@ -99,7 +99,7 @@ static struct qedi_list_of_funcs
>qedi_dbg_do_not_recover_ops[] = {
>   { NULL, NULL }
> };
> 
>-struct qedi_debugfs_ops qedi_debugfs_ops[] = {
>+const struct qedi_debugfs_ops qedi_debugfs_ops[] = {
>   { "gbl_ctx", NULL },
>   { "do_not_recover", qedi_dbg_do_not_recover_ops},
>   { "io_trace", NULL },
>diff --git a/drivers/scsi/qedi/qedi_gbl.h b/drivers/scsi/qedi/qedi_gbl.h
>index f5b5a31999aa..a2aa06ed1620 100644
>--- a/drivers/scsi/qedi/qedi_gbl.h
>+++ b/drivers/scsi/qedi/qedi_gbl.h
>@@ -23,8 +23,8 @@ extern uint qedi_io_tracing;
> extern struct scsi_host_template qedi_host_template;
> extern struct iscsi_transport qedi_iscsi_transport;
> extern const struct qed_iscsi_ops *qedi_ops;
>-extern struct qedi_debugfs_ops qedi_debugfs_ops;
>-extern const struct file_operations qedi_dbg_fops;
>+extern const struct qedi_debugfs_ops qedi_debugfs_ops[];
>+extern const struct file_operations qedi_dbg_fops[];
> extern struct device_attribute *qedi_shost_attrs[];
> 
> int qedi_alloc_sq(struct qedi_ctx *qedi, struct qedi_endpoint *ep);
>diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c
>index 029e2e69b29f..e992f9d3ef00 100644
>--- a/drivers/scsi/qedi/qedi_main.c
>+++ b/drivers/scsi/qedi/qedi_main.c
>@@ -2303,8 +2303,8 @@ static int __qedi_probe(struct pci_dev *pdev, int
>mode)
>   }
> 
> #ifdef CONFIG_DEBUG_FS
>-  qedi_dbg_host_init(>dbg_ctx, _debugfs_ops,
>- _dbg_fops);
>+  qedi_dbg_host_init(>dbg_ctx, qedi_debugfs_ops,
>+ qedi_dbg_fops);
> #endif
>   QEDI_INFO(>dbg_ctx, QEDI_LOG_INFO,
> "QLogic FastLinQ iSCSI Module qedi %s, FW %d.%d.%d.%d\n",
>-- 
>2.9.0

Thanks

Acked-by: Manish Rangankar 


>

Re: [PATCH v2 1/2] dt-bindings: gpio: Add Spreadtrum GPIO controller documentation

[Rob Herring]

On Thu, Feb 01, 2018 at 11:04:31AM +0800, Baolin Wang wrote:
> This patch adds the device tree bindings for the Spreadtrum
> GPIO controller. The gpios will be supported by the GPIO
> generic library.
> 
> Signed-off-by: Baolin Wang 
> ---
> Changes since v1:
>  - No updates.
> ---
>  .../devicetree/bindings/gpio/gpio-sprd.txt |   28 
> 
>  1 file changed, 28 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-sprd.txt

Reviewed-by: Rob Herring 

Re: [PATCH v2 4/5] dt-bindings: clock: mediatek: update audsys documentation to adapt MFD device

[Rob Herring]

On Wed, Jan 31, 2018 at 03:42:44PM +0800, Ryder Lee wrote:
> As the MediaTek audio hardware block that expose functionalities that are
> handled by separate subsystems in the kernel, and there are registers that
> are shared between related drivers.
> 
> Switch the current device to an MFD device, add more descriptions about the
> subsystem and modify example accordingly.
> 
> Signed-off-by: Ryder Lee 
> ---
>  .../bindings/arm/mediatek/mediatek,audsys.txt  | 37 
> ++
>  1 file changed, 30 insertions(+), 7 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt 
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> index 9b8f578..677af40 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> @@ -1,22 +1,45 @@
> -MediaTek AUDSYS controller
> +MediaTek Audio Subsystem
>  
> +The audio subsystem is one of the multi-function blocks of MediaTek SoCs.
> +It contains a system controller, which provides a number registers giving
> +access to two features: AUDSYS clocks and Audio Front End (AFE) components.
>  
> +For the top level node:
> +- compatible: must be: "syscon", "simple-mfd";

This should have some SoC specific compatible.

> +- reg: register area of the Audio Subsystem
> +
> +Required sub-nodes:
> +
> +AUDSYS clocks:
> +---
>  The MediaTek AUDSYS controller provides various clocks to the system.
>  
>  Required Properties:
>  
>  - compatible: Should be one of:
> - - "mediatek,mt7622-audsys", "syscon"
> + - "mediatek,mt2701-audsys";
> + - "mediatek,mt7622-audsys";
>  - #clock-cells: Must be 1
>  
>  The AUDSYS controller uses the common clk binding from
>  Documentation/devicetree/bindings/clock/clock-bindings.txt
>  The available clocks are defined in dt-bindings/clock/mt*-clk.h.

There's no register range associated with the clocks? If there is, add a 
reg property.

>  
> +AFE components:
> +---
> +For common binding part and usage, refer to
> +../sonud/mt2701-afe-pcm.txt.
> +
>  Example:
>  
> -audsys: audsys@1122 {
> - compatible = "mediatek,mt7622-audsys", "syscon";
> - reg = <0 0x1122 0 0x1000>;
> - #clock-cells = <1>;
> -};
> + audio-subsystem@1122 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0 0x1122 0 0x2000>;
> +
> + audsys: clock {
> + compatible = "mediatek,mt2701-audsys";
> + #clock-cells = <1>;
> + };
> +
> + ...
> + };
> -- 
> 1.9.1
> 

Re: [PATCH v3 2/2] ARM: dts: imx25-pinfunc: Always set SION for eSDHC CMD

[Rob Herring]

On Wed, Jan 31, 2018 at 10:35:44PM +0100, Benoît Thébaudeau wrote:
> The eSDHC does not work properly if the SION bit is not set for the
> bidirectional CMD signal, whatever the eSDHC instance and the selected
> pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do
> this for MX25_PAD_*__ESDHCn_CMD in imx25-pinfunc.h in order to enforce
> this behavior for all boards.
> 
> This had already been done for eSDHC1, but not for eSDHC2. Also, define
> MX25_PAD_FEC_MDC__ESDHC2_CMD so that all the possible cases are covered
> from now on.
> 
> Cc: Uwe Kleine-König 
> Signed-off-by: Benoît Thébaudeau 
> Reviewed-by: Fabio Estevam 
> ---
> Changes v2 -> v3:
>  - Quickly mention SION in each comment, besides the reference to the
>verbose comment (suggested by Uwe).
> Changes v1 -> v2:
>  - Update eSDHC instance and port naming following the addition of "ARM:
>dts: imx25-pinfunc: Use consistent naming for eSDHC".
>  - Reference the more verbose comment for MX25_PAD_SD1_CMD__ESDHC1_CMD
>instead of copying the same less detailed comment everywhere
>(suggested by Uwe).
> ---
>  arch/arm/boot/dts/imx25-pinfunc.h | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH v2 1/2] dt-bindings: gpio: Add Spreadtrum GPIO controller documentation

[Rob Herring]

On Thu, Feb 01, 2018 at 11:04:31AM +0800, Baolin Wang wrote:
> This patch adds the device tree bindings for the Spreadtrum
> GPIO controller. The gpios will be supported by the GPIO
> generic library.
> 
> Signed-off-by: Baolin Wang 
> ---
> Changes since v1:
>  - No updates.
> ---
>  .../devicetree/bindings/gpio/gpio-sprd.txt |   28 
> 
>  1 file changed, 28 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-sprd.txt

Reviewed-by: Rob Herring 

Re: [PATCH v2 4/5] dt-bindings: clock: mediatek: update audsys documentation to adapt MFD device

[Rob Herring]

On Wed, Jan 31, 2018 at 03:42:44PM +0800, Ryder Lee wrote:
> As the MediaTek audio hardware block that expose functionalities that are
> handled by separate subsystems in the kernel, and there are registers that
> are shared between related drivers.
> 
> Switch the current device to an MFD device, add more descriptions about the
> subsystem and modify example accordingly.
> 
> Signed-off-by: Ryder Lee 
> ---
>  .../bindings/arm/mediatek/mediatek,audsys.txt  | 37 
> ++
>  1 file changed, 30 insertions(+), 7 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt 
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> index 9b8f578..677af40 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> @@ -1,22 +1,45 @@
> -MediaTek AUDSYS controller
> +MediaTek Audio Subsystem
>  
> +The audio subsystem is one of the multi-function blocks of MediaTek SoCs.
> +It contains a system controller, which provides a number registers giving
> +access to two features: AUDSYS clocks and Audio Front End (AFE) components.
>  
> +For the top level node:
> +- compatible: must be: "syscon", "simple-mfd";

This should have some SoC specific compatible.

> +- reg: register area of the Audio Subsystem
> +
> +Required sub-nodes:
> +
> +AUDSYS clocks:
> +---
>  The MediaTek AUDSYS controller provides various clocks to the system.
>  
>  Required Properties:
>  
>  - compatible: Should be one of:
> - - "mediatek,mt7622-audsys", "syscon"
> + - "mediatek,mt2701-audsys";
> + - "mediatek,mt7622-audsys";
>  - #clock-cells: Must be 1
>  
>  The AUDSYS controller uses the common clk binding from
>  Documentation/devicetree/bindings/clock/clock-bindings.txt
>  The available clocks are defined in dt-bindings/clock/mt*-clk.h.

There's no register range associated with the clocks? If there is, add a 
reg property.

>  
> +AFE components:
> +---
> +For common binding part and usage, refer to
> +../sonud/mt2701-afe-pcm.txt.
> +
>  Example:
>  
> -audsys: audsys@1122 {
> - compatible = "mediatek,mt7622-audsys", "syscon";
> - reg = <0 0x1122 0 0x1000>;
> - #clock-cells = <1>;
> -};
> + audio-subsystem@1122 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0 0x1122 0 0x2000>;
> +
> + audsys: clock {
> + compatible = "mediatek,mt2701-audsys";
> + #clock-cells = <1>;
> + };
> +
> + ...
> + };
> -- 
> 1.9.1
> 

Re: [PATCH v3 2/2] ARM: dts: imx25-pinfunc: Always set SION for eSDHC CMD

[Rob Herring]

On Wed, Jan 31, 2018 at 10:35:44PM +0100, Benoît Thébaudeau wrote:
> The eSDHC does not work properly if the SION bit is not set for the
> bidirectional CMD signal, whatever the eSDHC instance and the selected
> pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do
> this for MX25_PAD_*__ESDHCn_CMD in imx25-pinfunc.h in order to enforce
> this behavior for all boards.
> 
> This had already been done for eSDHC1, but not for eSDHC2. Also, define
> MX25_PAD_FEC_MDC__ESDHC2_CMD so that all the possible cases are covered
> from now on.
> 
> Cc: Uwe Kleine-König 
> Signed-off-by: Benoît Thébaudeau 
> Reviewed-by: Fabio Estevam 
> ---
> Changes v2 -> v3:
>  - Quickly mention SION in each comment, besides the reference to the
>verbose comment (suggested by Uwe).
> Changes v1 -> v2:
>  - Update eSDHC instance and port naming following the addition of "ARM:
>dts: imx25-pinfunc: Use consistent naming for eSDHC".
>  - Reference the more verbose comment for MX25_PAD_SD1_CMD__ESDHC1_CMD
>instead of copying the same less detailed comment everywhere
>(suggested by Uwe).
> ---
>  arch/arm/boot/dts/imx25-pinfunc.h | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH 1/2] of: change overlay apply input data from EDT to FDT

[Rob Herring]

On Mon, Jan 29, 2018 at 04:01:38PM -0800, Frank Rowand wrote:
> On 01/29/18 06:42, Rob Herring wrote:
> > On Sun, Jan 28, 2018 at 8:53 PM,   wrote:
> >> From: Frank Rowand 
> >>
> >> Move duplicating and unflattening of an overlay flattened devicetree
> >> (FDT) into the overlay application code.  To accomplish this,
> >> of_overlay_apply() is replaced by of_overlay_fdt_apply().
> >>
> >> The copy of the FDT (aka "duplicate FDT") now belongs to devicetree
> >> code, which is thus responsible for freeing the duplicate FDT.  The
> >> caller of of_overlay_fdt_apply() remains responsible for freeing the
> >> original FDT.
> >>
> >> The unflattened device tree (aka expanded device tree, EDT) now
> > 
> > Not really a fan of a new acronym.
> > 
> >> belongs to devicetree code, which is thus responsible for freeing
> >> the EDT.
> >>
> >> These ownership changes prevent early freeing of the duplicated FDT
> >> or the EDT, which could result in use after free errors.
> >>
> >> of_overlay_fdt_apply() is a private function for the anticipated
> >> overlay loader.
> >>
> >> Update unittest.c to use of_overlay_fdt_apply() instead of
> >> of_overlay_apply().
> >>
> >> Move overlay fragments from artificial locations in
> >> drivers/of/unittest-data/tests-overlay.dtsi into one devicetree
> >> source file per overlay.  This led to changes in
> >> drivers/of/unitest-data/Makefile and drivers/of/unitest.c.
> 
> I should have reversed the cause and effect in that sentence to
> instead be:
> 
>   The changes to drivers/of/unittest.c require the test overlays
>   to be in FDT form instead of unflattened devicetree form.  Move
>   overlay fragments from artificial locations in
>   drivers/of/unittest-data/tests-overlay.dtsi into one
>   devicetree source file per overlay and thus create
>   one FDT per overlay.
> 
> 
> > Why the rearranging? That should be a separate patch.
> Bisectability.
> 
> I can make the changes to the devicetree files in a second patch.
> After the first patch, there will be 29 self test fails.
> 
> I will make the change unless you respond back to this saying not to.

One patch is fine for me. Unit test is special.

Rob

Re: [PATCH v2 1/4] soc: samsung: pmu: Populate children syscon nodes

[Rob Herring]

On Tue, Jan 30, 2018 at 10:18:16PM +0100, Krzysztof Kozlowski wrote:
> The syscon poweroff and restart nodes logically belong to the Power
> Management Unit so populate possible children.
> 
> This also requires providing compatibles for Exynos5410 and Exynos7 so
> the PMU device and its children will be instantiated for them as well.
> Just like Exynos5433, these chipsets are not yet supported by the PMU
> driver.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/arm/samsung/pmu.txt | 6 ++
>  drivers/soc/samsung/exynos-pmu.c  | 7 +++
>  2 files changed, 13 insertions(+)

Reviewed-by: Rob Herring 

Re: [PATCH v2 1/5] clk: mediatek: update missing clock data for MT7622 audsys

[Rob Herring]

On Wed, Jan 31, 2018 at 03:42:41PM +0800, Ryder Lee wrote:
> Add missing clock data 'CLK_AUDIO_AFE_CONN' for MT7622 audsys.
> 
> Signed-off-by: Ryder Lee 
> ---
>  drivers/clk/mediatek/clk-mt7622-aud.c  | 1 +
>  include/dt-bindings/clock/mt7622-clk.h | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

Re: [PATCH v2 1/5] clk: mediatek: update missing clock data for MT7622 audsys

[Rob Herring]

On Wed, Jan 31, 2018 at 03:42:41PM +0800, Ryder Lee wrote:
> Add missing clock data 'CLK_AUDIO_AFE_CONN' for MT7622 audsys.
> 
> Signed-off-by: Ryder Lee 
> ---
>  drivers/clk/mediatek/clk-mt7622-aud.c  | 1 +
>  include/dt-bindings/clock/mt7622-clk.h | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

Re: [PATCH 1/2] of: change overlay apply input data from EDT to FDT

[Rob Herring]

On Mon, Jan 29, 2018 at 04:01:38PM -0800, Frank Rowand wrote:
> On 01/29/18 06:42, Rob Herring wrote:
> > On Sun, Jan 28, 2018 at 8:53 PM,   wrote:
> >> From: Frank Rowand 
> >>
> >> Move duplicating and unflattening of an overlay flattened devicetree
> >> (FDT) into the overlay application code.  To accomplish this,
> >> of_overlay_apply() is replaced by of_overlay_fdt_apply().
> >>
> >> The copy of the FDT (aka "duplicate FDT") now belongs to devicetree
> >> code, which is thus responsible for freeing the duplicate FDT.  The
> >> caller of of_overlay_fdt_apply() remains responsible for freeing the
> >> original FDT.
> >>
> >> The unflattened device tree (aka expanded device tree, EDT) now
> > 
> > Not really a fan of a new acronym.
> > 
> >> belongs to devicetree code, which is thus responsible for freeing
> >> the EDT.
> >>
> >> These ownership changes prevent early freeing of the duplicated FDT
> >> or the EDT, which could result in use after free errors.
> >>
> >> of_overlay_fdt_apply() is a private function for the anticipated
> >> overlay loader.
> >>
> >> Update unittest.c to use of_overlay_fdt_apply() instead of
> >> of_overlay_apply().
> >>
> >> Move overlay fragments from artificial locations in
> >> drivers/of/unittest-data/tests-overlay.dtsi into one devicetree
> >> source file per overlay.  This led to changes in
> >> drivers/of/unitest-data/Makefile and drivers/of/unitest.c.
> 
> I should have reversed the cause and effect in that sentence to
> instead be:
> 
>   The changes to drivers/of/unittest.c require the test overlays
>   to be in FDT form instead of unflattened devicetree form.  Move
>   overlay fragments from artificial locations in
>   drivers/of/unittest-data/tests-overlay.dtsi into one
>   devicetree source file per overlay and thus create
>   one FDT per overlay.
> 
> 
> > Why the rearranging? That should be a separate patch.
> Bisectability.
> 
> I can make the changes to the devicetree files in a second patch.
> After the first patch, there will be 29 self test fails.
> 
> I will make the change unless you respond back to this saying not to.

One patch is fine for me. Unit test is special.

Rob

Re: [PATCH v2 1/4] soc: samsung: pmu: Populate children syscon nodes

[Rob Herring]

On Tue, Jan 30, 2018 at 10:18:16PM +0100, Krzysztof Kozlowski wrote:
> The syscon poweroff and restart nodes logically belong to the Power
> Management Unit so populate possible children.
> 
> This also requires providing compatibles for Exynos5410 and Exynos7 so
> the PMU device and its children will be instantiated for them as well.
> Just like Exynos5433, these chipsets are not yet supported by the PMU
> driver.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/arm/samsung/pmu.txt | 6 ++
>  drivers/soc/samsung/exynos-pmu.c  | 7 +++
>  2 files changed, 13 insertions(+)

Reviewed-by: Rob Herring