[PATCH] mm/gup: fix follow_page_mask kernel-doc comment

[Mike Rapoport]

Commit df06b37ffe5a ("mm/gup: cache dev_pagemap while pinning pages")
modified the signature of follow_page_mask() function but left the
parameter description behind.

Update the description to make the code and comments agree again.

While on it, update formatting of the return value description to match
Documentation/doc-guide/kernel-doc.rst guidelines.

Signed-off-by: Mike Rapoport 
---
 mm/gup.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index f76e77a..aa43620 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -385,11 +385,17 @@ static struct page *follow_p4d_mask(struct vm_area_struct 
*vma,
  * @vma: vm_area_struct mapping @address
  * @address: virtual address to look up
  * @flags: flags modifying lookup behaviour
- * @page_mask: on output, *page_mask is set according to the size of the page
+ * @ctx: contains dev_pagemap for %ZONE_DEVICE memory pinning and a
+ *   pointer to output page_mask
  *
  * @flags can have FOLL_ flags set, defined in 
  *
- * Returns the mapped (struct page *), %NULL if no mapping exists, or
+ * When getting pages from ZONE_DEVICE memory, the @ctx->pgmap caches
+ * the device's dev_pagemap metadata to avoid repeating expensive lookups.
+ *
+ * On output, the @ctx->page_mask is set according to the size of the page.
+ *
+ * Return: the mapped (struct page *), %NULL if no mapping exists, or
  * an error pointer if there is a mapping to something not represented
  * by a page descriptor (see also vm_normal_page()).
  */
-- 
2.7.4

Re: [PATCH v2] doc: tracing: Fix a number of typos

[Jonathan Corbet]

On Thu,  1 Nov 2018 09:57:17 -0400
Amir Livneh  wrote:

> Trivial fixes to spelling mistakes in ftrace.rst
> 
> v2: tripple -> triple
> 
> Signed-off-by: Amir Livneh 

Applied, thanks.

jon

[PATCH] [trivial] Documentation/ras: Typo s/use use/use/

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/admin-guide/ras.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/ras.rst 
b/Documentation/admin-guide/ras.rst
index 197896718f813036..c7495e42e6f48bcb 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -54,7 +54,7 @@ those errors are correctable.
 Types of errors
 ---
 
-Most mechanisms used on modern systems use use technologies like Hamming
+Most mechanisms used on modern systems use technologies like Hamming
 Codes that allow error correction when the number of errors on a bit packet
 is below a threshold. If the number of errors is above, those mechanisms
 can indicate with a high degree of confidence that an error happened, but
-- 
2.17.1

Re: [PATCH v10 00/22] kasan: add software tag-based mode for arm64

[Andrey Konovalov]

On Tue, Nov 6, 2018 at 6:30 PM, Andrey Konovalov  wrote:
> This patchset adds a new software tag-based mode to KASAN [1].
> (Initially this mode was called KHWASAN, but it got renamed,
>  see the naming rationale at the end of this section).

[...]

> Reviewed-by: Andrey Ryabinin 
> Reviewed-by: Dmitry Vyukov 
> Signed-off-by: Andrey Konovalov 

Hi Andrew,

This patchset has now been reviewed-by KASAN maintainers. Could you
take a look and consider taking this into the -mm tree?

Thanks!

Re: [PATCH v10 00/22] kasan: add software tag-based mode for arm64

[Will Deacon]

On Wed, Nov 07, 2018 at 03:56:03PM +0100, Andrey Konovalov wrote:
> On Tue, Nov 6, 2018 at 6:30 PM, Andrey Konovalov  
> wrote:
> > This patchset adds a new software tag-based mode to KASAN [1].
> > (Initially this mode was called KHWASAN, but it got renamed,
> >  see the naming rationale at the end of this section).
> 
> [...]
> 
> > Reviewed-by: Andrey Ryabinin 
> > Reviewed-by: Dmitry Vyukov 
> > Signed-off-by: Andrey Konovalov 
> 
> Hi Andrew,
> 
> This patchset has now been reviewed-by KASAN maintainers. Could you
> take a look and consider taking this into the -mm tree?

I would much prefer to take the arm64 parts (which still need to be reviewed
by Catalin afaict) via the arm64 tree, so please can you split those out
separately?

Will

[PATCH] kernel-doc: extend $type_param to match members referenced by pointer

[Mike Rapoport]

Currently, function parameter description can match '@type.member'
expressions but fails to match '@type->member'.
Extend the $type_param regex to allow matching both

Signed-off-by: Mike Rapoport 
---
 scripts/kernel-doc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index ffbe901..3ce8800 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -212,7 +212,7 @@ my $anon_struct_union = 0;
 my $type_constant = '\b``([^\`]+)``\b';
 my $type_constant2 = '\%([-_\w]+)';
 my $type_func = '(\w+)\(\)';
-my $type_param = '\@(\w*(\.\w+)*(\.\.\.)?)';
+my $type_param = '\@(\w*((\.\w+)|(->\w+))*(\.\.\.)?)';
 my $type_fp_param = '\@(\w+)\(\)';  # Special RST handling for func ptr params
 my $type_env = '(\$\w+)';
 my $type_enum = '\&(enum\s*([_\w]+))';
@@ -361,7 +361,7 @@ my $doc_com = '\s*\*\s*';
 my $doc_com_body = '\s*\* ?';
 my $doc_decl = $doc_com . '(\w+)';
 # @params and a strictly limited set of supported section names
-my $doc_sect = $doc_com . 
+my $doc_sect = $doc_com .
 
'\s*(\@[.\w]+|\@\.\.\.|description|context|returns?|notes?|examples?)\s*:(.*)';
 my $doc_content = $doc_com_body . '(.*)';
 my $doc_block = $doc_com . 'DOC:\s*(.*)?';
@@ -751,7 +751,7 @@ sub output_blockhead_rst(%) {
 
 #
 # Apply the RST highlights to a sub-block of text.
-#   
+#  
 sub highlight_block($) {
 # The dohighlight kludge requires the text be called $contents
 my $contents = shift;
-- 
2.7.4

Re: [PATCH v10 00/22] kasan: add software tag-based mode for arm64

[Andrey Konovalov]

On Wed, Nov 7, 2018 at 3:59 PM, Will Deacon  wrote:
> On Wed, Nov 07, 2018 at 03:56:03PM +0100, Andrey Konovalov wrote:
>> On Tue, Nov 6, 2018 at 6:30 PM, Andrey Konovalov  
>> wrote:
>> > This patchset adds a new software tag-based mode to KASAN [1].
>> > (Initially this mode was called KHWASAN, but it got renamed,
>> >  see the naming rationale at the end of this section).
>>
>> [...]
>>
>> > Reviewed-by: Andrey Ryabinin 
>> > Reviewed-by: Dmitry Vyukov 
>> > Signed-off-by: Andrey Konovalov 
>>
>> Hi Andrew,
>>
>> This patchset has now been reviewed-by KASAN maintainers. Could you
>> take a look and consider taking this into the -mm tree?
>
> I would much prefer to take the arm64 parts (which still need to be reviewed
> by Catalin afaict) via the arm64 tree, so please can you split those out
> separately?

Which parts do you mean exactly, which patches? I don't think it makes
sense to split this patchset, as one part won't function without the
other.

Re: [PATCH 1/3] i3c: master: Add driver for Synopsys DesignWare IP

[vitor]

Hi Matthew,

Thank for your feedback.

On 29/10/18 13:41, Matthew Wilcox wrote:

On Mon, Oct 29, 2018 at 10:06:56AM +, Vitor soares wrote:

+config DW_I3C_MASTER
+   tristate "Synospsys DesignWare I3C master driver"
+   depends on I3C
+   depends on !(ALPHA || PARISC)

why?


Please check this email thread: https://lkml.org/lkml/2018/10/8/393




+   help
+ Support·for·Synopsys·DesignWare·MIPI·I3C·Controller.

These strange characters (displayed as a centred dot on my terminal)
should probably be spaces.


Something went wrong here. I need to check it.




+static struct dw_i3c_xfer *
+dw_i3c_master_alloc_xfer(struct dw_i3c_master *master, unsigned int ncmds)
+{
+   struct dw_i3c_xfer *xfer;
+
+   xfer = kzalloc(sizeof(*xfer) + (ncmds * sizeof(*xfer->cmds)),
+  GFP_KERNEL);

You should be using struct_size() here.


This seem to be recent. I will use it next version :D

Best regards,
Vitor Soares

Re: [PATCH 1/3] i3c: master: Add driver for Synopsys DesignWare IP

[Geert Uytterhoeven]

Hi Vitor,

On Wed, Nov 7, 2018 at 4:15 PM vitor  wrote:
> On 29/10/18 13:41, Matthew Wilcox wrote:
> > On Mon, Oct 29, 2018 at 10:06:56AM +, Vitor soares wrote:
> >> +config DW_I3C_MASTER
> >> +tristate "Synospsys DesignWare I3C master driver"
> >> +depends on I3C
> >> +depends on !(ALPHA || PARISC)
> > why?
>
> Please check this email thread: https://lkml.org/lkml/2018/10/8/393

Hence this deserves a comment, so we know when/what to do to drop the
dependency:

depends on  !(ALPHA || PARISC) # needs {read,write}sl()

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v10 00/22] kasan: add software tag-based mode for arm64

[Will Deacon]

On Wed, Nov 07, 2018 at 04:11:35PM +0100, Andrey Konovalov wrote:
> On Wed, Nov 7, 2018 at 3:59 PM, Will Deacon  wrote:
> > On Wed, Nov 07, 2018 at 03:56:03PM +0100, Andrey Konovalov wrote:
> >> On Tue, Nov 6, 2018 at 6:30 PM, Andrey Konovalov  
> >> wrote:
> >> > This patchset adds a new software tag-based mode to KASAN [1].
> >> > (Initially this mode was called KHWASAN, but it got renamed,
> >> >  see the naming rationale at the end of this section).
> >>
> >> [...]
> >>
> >> > Reviewed-by: Andrey Ryabinin 
> >> > Reviewed-by: Dmitry Vyukov 
> >> > Signed-off-by: Andrey Konovalov 
> >>
> >> Hi Andrew,
> >>
> >> This patchset has now been reviewed-by KASAN maintainers. Could you
> >> take a look and consider taking this into the -mm tree?
> >
> > I would much prefer to take the arm64 parts (which still need to be reviewed
> > by Catalin afaict) via the arm64 tree, so please can you split those out
> > separately?
> 
> Which parts do you mean exactly, which patches? I don't think it makes
> sense to split this patchset, as one part won't function without the
> other.

I would like the patches that touch code under arch/arm64/ to be reviewed by
somebody from the arm64 community. Since the core parts have already been
reviewed, I was suggesting that you could split them out so that they are
not blocked by the architecture code. Is it not possible to preserve the
existing KASAN behaviour for arm64 with the core parts merged? I figured it
must be, since you're not touching any other architectures here and they
assumedly continue to function correctly.

However, if you'd rather keep everything together, please can we give it a
couple of weeks so we can at least get the architecture bits reviewed? Most
people are out at LPC next week (and I'm at another conference this week).

Will

Re: [PATCH v2] Document /proc/pid PID reuse behavior

[Daniel Colascione]

On Tue, Nov 6, 2018 at 1:05 PM, Michal Hocko  wrote:
> On Mon 05-11-18 13:22:05, Daniel Colascione wrote:
>> State explicitly that holding a /proc/pid file descriptor open does
>> not reserve the PID. Also note that in the event of PID reuse, these
>> open file descriptors refer to the old, now-dead process, and not the
>> new one that happens to be named the same numeric PID.
>
> This sounds quite obvious

Many people *on* *LKML* were wrong about this behavior. If it's not
obvious to experienced kernel developers, it's certainly not obvious
to the public.

> otherwise anybody could simply DoS the system
> by consuming all available pids.

People can do that today using the instrument of terror widely known
as fork(2). The only thing standing between fork(2) and a full process
table is RLIMIT_NPROC. In a world where we really did reserve a
numeric PID through the lifetime of any struct pid to which it refers
(i.e., where "cd /proc/$PID" held $PID), we could charge these struct
pid reservations against RLIMIT_NPROC and achieve behavior as safe as
what we have today. The details would be subtle (you'd have to take
pains to avoid double-counting, for example), but it could be made to
work. Other people, on the various lkml threads about my process API
improvement proposals, have proposed fixing the longstanding PID race
problem by making struct pid behave the way people mistakenly believe
it behaves today. It's a serious idea worth actual consideration.

Re: [PATCH v10 00/22] kasan: add software tag-based mode for arm64

[Andrey Konovalov]

On Wed, Nov 7, 2018 at 4:34 PM, Will Deacon  wrote:
> On Wed, Nov 07, 2018 at 04:11:35PM +0100, Andrey Konovalov wrote:
>> On Wed, Nov 7, 2018 at 3:59 PM, Will Deacon  wrote:
>> > On Wed, Nov 07, 2018 at 03:56:03PM +0100, Andrey Konovalov wrote:
>> >> On Tue, Nov 6, 2018 at 6:30 PM, Andrey Konovalov  
>> >> wrote:
>> >> > This patchset adds a new software tag-based mode to KASAN [1].
>> >> > (Initially this mode was called KHWASAN, but it got renamed,
>> >> >  see the naming rationale at the end of this section).
>> >>
>> >> [...]
>> >>
>> >> > Reviewed-by: Andrey Ryabinin 
>> >> > Reviewed-by: Dmitry Vyukov 
>> >> > Signed-off-by: Andrey Konovalov 
>> >>
>> >> Hi Andrew,
>> >>
>> >> This patchset has now been reviewed-by KASAN maintainers. Could you
>> >> take a look and consider taking this into the -mm tree?
>> >
>> > I would much prefer to take the arm64 parts (which still need to be 
>> > reviewed
>> > by Catalin afaict) via the arm64 tree, so please can you split those out
>> > separately?
>>
>> Which parts do you mean exactly, which patches? I don't think it makes
>> sense to split this patchset, as one part won't function without the
>> other.
>
> I would like the patches that touch code under arch/arm64/ to be reviewed by
> somebody from the arm64 community. Since the core parts have already been
> reviewed, I was suggesting that you could split them out so that they are
> not blocked by the architecture code. Is it not possible to preserve the
> existing KASAN behaviour for arm64 with the core parts merged? I figured it
> must be, since you're not touching any other architectures here and they
> assumedly continue to function correctly.
>
> However, if you'd rather keep everything together, please can we give it a
> couple of weeks so we can at least get the architecture bits reviewed? Most
> people are out at LPC next week (and I'm at another conference this week).
>
> Will

Re: [PATCH v10 00/22] kasan: add software tag-based mode for arm64

[Andrey Konovalov]

On Wed, Nov 7, 2018 at 4:34 PM, Will Deacon  wrote:
>
> I would like the patches that touch code under arch/arm64/ to be reviewed by
> somebody from the arm64 community. Since the core parts have already been
> reviewed, I was suggesting that you could split them out so that they are
> not blocked by the architecture code. Is it not possible to preserve the
> existing KASAN behaviour for arm64 with the core parts merged? I figured it
> must be, since you're not touching any other architectures here and they
> assumedly continue to function correctly.

It's possible to split out the core mm part, but it doesn't make much
sense to merge it separately from the arm64 changes.

> However, if you'd rather keep everything together, please can we give it a
> couple of weeks so we can at least get the architecture bits reviewed? Most
> people are out at LPC next week (and I'm at another conference this week).

OK, sounds good!

Catalin, could you take a look at the arm64 specific changes?

Re: [PATCH v2] Document /proc/pid PID reuse behavior

[Michal Hocko]

On Wed 07-11-18 15:48:20, Daniel Colascione wrote:
> On Tue, Nov 6, 2018 at 1:05 PM, Michal Hocko  wrote:
> > On Mon 05-11-18 13:22:05, Daniel Colascione wrote:
> >> State explicitly that holding a /proc/pid file descriptor open does
> >> not reserve the PID. Also note that in the event of PID reuse, these
> >> open file descriptors refer to the old, now-dead process, and not the
> >> new one that happens to be named the same numeric PID.
> >
> > This sounds quite obvious
> 
> Many people *on* *LKML* were wrong about this behavior. If it's not
> obvious to experienced kernel developers, it's certainly not obvious
> to the public.

Fair enough

> > otherwise anybody could simply DoS the system
> > by consuming all available pids.
> 
> People can do that today using the instrument of terror widely known
> as fork(2). The only thing standing between fork(2) and a full process
> table is RLIMIT_NPROC.

not really. If you really do care about pid space depletion then you
should use pid cgroup controller.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2] Document /proc/pid PID reuse behavior

[Daniel Colascione]

On Wed, Nov 7, 2018 at 4:00 PM, Michal Hocko  wrote:
> On Wed 07-11-18 15:48:20, Daniel Colascione wrote:
>> On Tue, Nov 6, 2018 at 1:05 PM, Michal Hocko  wrote:
>> > otherwise anybody could simply DoS the system
>> > by consuming all available pids.
>>
>> People can do that today using the instrument of terror widely known
>> as fork(2). The only thing standing between fork(2) and a full process
>> table is RLIMIT_NPROC.
>
> not really.

What else, besides memory consumption and (as you mention below)
cgroups? In practice, nobody uses RLIMIT_NPROC, so outside of various
container-y namespaced setups, avoidance of
system-DoS-through-PID-exhaustion isn't a pressing problem.

If you really do care about pid space depletion then you
> should use pid cgroup controller.

Or that, sure. But since cgroups are optional, the problem with the
core model remains. In general, if there's a problem X with the core
system API, and you can mitigate X by using a cgroup, X is still a
problem.

Re: [PATCH v2] Document /proc/pid PID reuse behavior

[Michal Hocko]

On Wed 07-11-18 16:10:01, Daniel Colascione wrote:
> On Wed, Nov 7, 2018 at 4:00 PM, Michal Hocko  wrote:
[...]
> > If you really do care about pid space depletion then you
> > should use pid cgroup controller.
> 
> Or that, sure. But since cgroups are optional, the problem with the
> core model remains. In general, if there's a problem X with the core
> system API, and you can mitigate X by using a cgroup, X is still a
> problem.

I am not questioning that. All that I am saying is that there is a way to
mitigate the issue. This is not the only resource where the standard
rlimit is not sufficient and there is no other way than cgroups.
Actually cgroups were introduced to address rlimit limits IIRC.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v15 23/23] x86/sgx: Driver documentation

[Jarkko Sakkinen]

On Tue, Nov 06, 2018 at 08:45:37AM -0800, Dave Hansen wrote:
> On 11/5/18 9:49 PM, Jarkko Sakkinen wrote:
> > On Mon, Nov 05, 2018 at 12:27:11PM -0800, Dave Hansen wrote:
> >> The ABI seems entirely undocumented and rather lightly designed, which
> >> seems like something we should fix before this is merged.
> > 
> > ABI is documented in arch/x86/include/uapi/asm/sgx.h that from which the
> > documentation is included to intel_sgx.rst. I'm not saying that there is
> > no space refine it but it is neither undocumented.
> 
> I specifically mean the instruction flow around asynchronous exits or
> explicit enclave exit calls via EEXIT.  Signals are part of the ABI but
> go unmentioned in the documentation.

Ok, thanks for clarification. We will document it.
> 
> It's also worth noting that EENTER *can* act (from the kernel's
> perspective) like an instruction that both jumps and sets a bunch of
> registers (including %rsp).  It's certainly abnormal in that regard.

Agreed.

> In fact, in the docs:
> 
> > +Enclave can only execute code inside the ELRANGE. Instructions that may 
> > cause
> > +VMEXIT, IO instructions and instructions that require a privilege change 
> > are
> > +prohibited inside the enclave. Interrupts and exceptions always cause 
> > enclave
> > +to exit and jump to an address outside the enclave given when the enclave 
> > is
> > +entered by using the leaf instruction ENCLS(EENTER).
> 
> it's probably a really good idea to explain that the address outside of
> the enclave is enclave-provided, and is not, for instance, just the next
> instruction after EENTER.
> 
> >> Also, for a feature as massive and complicated as this one, it seems
> >> irresponsible to not have a selftest.  Is that not feasible for some 
> >> reason?
> > 
> > I do have the in-kernel launch enclave stuff backed up here:
> > 
> > https://github.com/jsakkine-intel/sgx-le-host
> > https://github.com/jsakkine-intel/sgx-le
> > 
> > This is about as simple as it gets without any type of run-time.
> 
> Does this code run when I type "make kselftest"?  If not, I think we
> should rectify that.

No, it doesn't. It is just my backup for the non-SDK user space code
that I've made that I will use to fork my user space SGX projects in
the future.

I can work-out a selftest (and provide a new patch in the series) but
I'm still wondering what the enclave should do. I would suggest that
we start with an enclave that does just EEXIT and nothing else.

/Jarkko

Re: [PATCH] kernel-doc: extend $type_param to match members referenced by pointer

[Mike Rapoport]

On Wed, Nov 07, 2018 at 05:00:08PM +0200, Mike Rapoport wrote:
> Currently, function parameter description can match '@type.member'
> expressions but fails to match '@type->member'.
> Extend the $type_param regex to allow matching both
> 
> Signed-off-by: Mike Rapoport 
> ---

It seems I've really screwed up with the whitespace here :(
v2 is on the way, sorry for the noise.

>  scripts/kernel-doc | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index ffbe901..3ce8800 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -212,7 +212,7 @@ my $anon_struct_union = 0;
>  my $type_constant = '\b``([^\`]+)``\b';
>  my $type_constant2 = '\%([-_\w]+)';
>  my $type_func = '(\w+)\(\)';
> -my $type_param = '\@(\w*(\.\w+)*(\.\.\.)?)';
> +my $type_param = '\@(\w*((\.\w+)|(->\w+))*(\.\.\.)?)';
>  my $type_fp_param = '\@(\w+)\(\)';  # Special RST handling for func ptr 
> params
>  my $type_env = '(\$\w+)';
>  my $type_enum = '\&(enum\s*([_\w]+))';
> @@ -361,7 +361,7 @@ my $doc_com = '\s*\*\s*';
>  my $doc_com_body = '\s*\* ?';
>  my $doc_decl = $doc_com . '(\w+)';
>  # @params and a strictly limited set of supported section names
> -my $doc_sect = $doc_com . 
> +my $doc_sect = $doc_com .
>  
> '\s*(\@[.\w]+|\@\.\.\.|description|context|returns?|notes?|examples?)\s*:(.*)';
>  my $doc_content = $doc_com_body . '(.*)';
>  my $doc_block = $doc_com . 'DOC:\s*(.*)?';
> @@ -751,7 +751,7 @@ sub output_blockhead_rst(%) {
>  
>  #
>  # Apply the RST highlights to a sub-block of text.
> -#   
> +#  
>  sub highlight_block($) {
>  # The dohighlight kludge requires the text be called $contents
>  my $contents = shift;
> -- 
> 2.7.4
> 

-- 
Sincerely yours,
Mike.

[PATCH v2 0/2] kernel-doc: extend $type_param to match members referenced by pointer

[Mike Rapoport]

Hi,

v2: separate whitespace and functional changes

Mike Rapoport (2):
  kernel-doc: kill trailing whitespace
  kernel-doc: extend $type_param to match members referenced by pointer

 scripts/kernel-doc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.7.4

[PATCH v2 2/2] kernel-doc: extend $type_param to match members referenced by pointer

[Mike Rapoport]

Currently, function parameter description can match '@type.member'
expressions but fails to match '@type->member'.
Extend the $type_param regex to allow matching both

Signed-off-by: Mike Rapoport 
---
 scripts/kernel-doc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 24d3550..f9f1431 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -212,7 +212,7 @@ my $anon_struct_union = 0;
 my $type_constant = '\b``([^\`]+)``\b';
 my $type_constant2 = '\%([-_\w]+)';
 my $type_func = '(\w+)\(\)';
-my $type_param = '\@(\w*(\.\w+)*(\.\.\.)?)';
+my $type_param = '\@(\w*((\.\w+)|(->\w+))*(\.\.\.)?)';
 my $type_fp_param = '\@(\w+)\(\)';  # Special RST handling for func ptr params
 my $type_env = '(\$\w+)';
 my $type_enum = '\&(enum\s*([_\w]+))';
-- 
2.7.4

[PATCH v2 1/2] kernel-doc: kill trailing whitespace

[Mike Rapoport]

Signed-off-by: Mike Rapoport 
---
 scripts/kernel-doc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index ffbe901..24d3550 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -361,7 +361,7 @@ my $doc_com = '\s*\*\s*';
 my $doc_com_body = '\s*\* ?';
 my $doc_decl = $doc_com . '(\w+)';
 # @params and a strictly limited set of supported section names
-my $doc_sect = $doc_com . 
+my $doc_sect = $doc_com .
 
'\s*(\@[.\w]+|\@\.\.\.|description|context|returns?|notes?|examples?)\s*:(.*)';
 my $doc_content = $doc_com_body . '(.*)';
 my $doc_block = $doc_com . 'DOC:\s*(.*)?';
@@ -751,7 +751,7 @@ sub output_blockhead_rst(%) {
 
 #
 # Apply the RST highlights to a sub-block of text.
-#   
+#
 sub highlight_block($) {
 # The dohighlight kludge requires the text be called $contents
 my $contents = shift;
-- 
2.7.4

Re: [PATCH v10 08/22] kasan, arm64: untag address in __kimg_to_phys and _virt_addr_is_linear

[Mark Rutland]

Hi Andrey,

On Tue, Nov 06, 2018 at 06:30:23PM +0100, Andrey Konovalov wrote:
> __kimg_to_phys (which is used by virt_to_phys) and _virt_addr_is_linear
> (which is used by virt_addr_valid) assume that the top byte of the address
> is 0xff, which isn't always the case with tag-based KASAN.

I'm confused by this. Why/when do kimg address have a non-default tag?

Any kimg address is part of the static kernel image, so it's not obvious
to me how a kimg address would gain a tag. Could you please explain how
this happens in the commit message?

> This patch resets the tag in those macros.
> 
> Reviewed-by: Andrey Ryabinin 
> Reviewed-by: Dmitry Vyukov 
> Signed-off-by: Andrey Konovalov 
> ---
>  arch/arm64/include/asm/memory.h | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 0f1e024a951f..3226a0218b0b 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -92,6 +92,15 @@
>  #define KASAN_THREAD_SHIFT   0
>  #endif
>  
> +#ifdef CONFIG_KASAN_SW_TAGS
> +#define KASAN_TAG_SHIFTED(tag)   ((unsigned long)(tag) << 56)
> +#define KASAN_SET_TAG(addr, tag) (((addr) & ~KASAN_TAG_SHIFTED(0xff)) | \
> + KASAN_TAG_SHIFTED(tag))
> +#define KASAN_RESET_TAG(addr)KASAN_SET_TAG(addr, 0xff)
> +#else
> +#define KASAN_RESET_TAG(addr)addr
> +#endif

Nit: the rest of the helper macros in this file are lower-case, with
specialised helpers prefixed with several underscores. Could we please
stick with that convention?

e.g. have __tag_set() and __tag_reset() helpers.

> +
>  #define MIN_THREAD_SHIFT (14 + KASAN_THREAD_SHIFT)
>  
>  /*
> @@ -232,7 +241,7 @@ static inline unsigned long kaslr_offset(void)
>  #define __is_lm_address(addr)(!!((addr) & BIT(VA_BITS - 1)))
>  
>  #define __lm_to_phys(addr)   (((addr) & ~PAGE_OFFSET) + PHYS_OFFSET)
> -#define __kimg_to_phys(addr) ((addr) - kimage_voffset)
> +#define __kimg_to_phys(addr) (KASAN_RESET_TAG(addr) - kimage_voffset)

IIUC You need to adjust __lm_to_phys() too, since that could be passed
an address from SLAB.

Maybe that's done in a later patch, but if so it's confusing to split it
out that way. It would be nicer to fix all the *_to_*() helpers in one
go.

>  
>  #define __virt_to_phys_nodebug(x) ({ \
>   phys_addr_t __x = (phys_addr_t)(x); \
> @@ -308,7 +317,8 @@ static inline void *phys_to_virt(phys_addr_t x)
>  #endif
>  #endif
>  
> -#define _virt_addr_is_linear(kaddr)  (((u64)(kaddr)) >= PAGE_OFFSET)
> +#define _virt_addr_is_linear(kaddr)  (KASAN_RESET_TAG((u64)(kaddr)) >= \
> + PAGE_OFFSET)

This is painful to read. Could you please split this like:

#define _virt_addr_is_linear(kaddr) \
(__tag_reset((u64)(kaddr)) >= PAGE_OFFSET)

... and we could reformat virt_addr_valid() in the same way while we're
at it.

Thanks,
Mark.

Re: [PATCH v10 06/22] kasan, arm64: adjust shadow size for tag-based mode

[Mark Rutland]

Hi Andrey,

On Tue, Nov 06, 2018 at 06:30:21PM +0100, Andrey Konovalov wrote:
> Tag-based KASAN uses 1 shadow byte for 16 bytes of kernel memory, so it
> requires 1/16th of the kernel virtual address space for the shadow memory.
> 
> This commit sets KASAN_SHADOW_SCALE_SHIFT to 4 when the tag-based KASAN
> mode is enabled.
> 
> Reviewed-by: Andrey Ryabinin 
> Reviewed-by: Dmitry Vyukov 
> Signed-off-by: Andrey Konovalov 
> ---
>  arch/arm64/Makefile |  2 +-
>  arch/arm64/include/asm/memory.h | 13 +
>  2 files changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 6cb9fc7e9382..9887492381d9 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -94,7 +94,7 @@ endif
>  # KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - 
> KASAN_SHADOW_SCALE_SHIFT))
>  # - (1 << (64 - KASAN_SHADOW_SCALE_SHIFT))
>  # in 32-bit arithmetic
> -KASAN_SHADOW_SCALE_SHIFT := 3
> +KASAN_SHADOW_SCALE_SHIFT := $(if $(CONFIG_KASAN_SW_TAGS), 4, 3)


We could make this something like:

ifeq ($(CONFIG_KASAN_SW_TAGS), y)
KASAN_SHADOW_SCALE_SHIFT := 4
else
KASAN_SHADOW_SCALE_SHIFT := 3
endif

KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)

>  KASAN_SHADOW_OFFSET := $(shell printf "0x%08x\n" $$(( \
>   (0x & (-1 << ($(CONFIG_ARM64_VA_BITS) - 32))) \
>   + (1 << ($(CONFIG_ARM64_VA_BITS) - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) \
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index b96442960aea..0f1e024a951f 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -74,12 +74,17 @@
>  #define KERNEL_END_end
>  
>  /*
> - * KASAN requires 1/8th of the kernel virtual address space for the shadow
> - * region. KASAN can bloat the stack significantly, so double the (minimum)
> - * stack size when KASAN is in use.
> + * Generic and tag-based KASAN require 1/8th and 1/16th of the kernel virtual
> + * address space for the shadow region respectively. They can bloat the stack
> + * significantly, so double the (minimum) stack size when they are in use.
>   */
> -#ifdef CONFIG_KASAN
> +#ifdef CONFIG_KASAN_GENERIC
>  #define KASAN_SHADOW_SCALE_SHIFT 3
> +#endif
> +#ifdef CONFIG_KASAN_SW_TAGS
> +#define KASAN_SHADOW_SCALE_SHIFT 4
> +#endif
> +#ifdef CONFIG_KASAN

... and remove the constant entirely here, avoiding duplication.

Maybe factor that into a Makefile.kasan if things are going to get much
more complicated.

Thanks,
Mark.

>  #define KASAN_SHADOW_SIZE(UL(1) << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
>  #define KASAN_THREAD_SHIFT   1
>  #else
> -- 
> 2.19.1.930.g4563a0d9d0-goog
> 

Re: [PATCH v2] Document /proc/pid PID reuse behavior

[Martin Steigerwald]

Michal Hocko - 07.11.18, 17:00:
> > > otherwise anybody could simply DoS the system
> > > by consuming all available pids.
> > 
> > People can do that today using the instrument of terror widely known
> > as fork(2). The only thing standing between fork(2) and a full
> > process table is RLIMIT_NPROC.
> 
> not really. If you really do care about pid space depletion then you
> should use pid cgroup controller.

Its not quite on-topic, but I am curious now: AFAIK PID limit is 16 
bits. Right? Could it be raised to 32 bits? I bet it would be a major 
change throughout different parts of the kernel.

16 bits sound a bit low these days, not only for PIDs, but also for 
connections / ports.

-- 
Martin

Re: [PATCH v10 05/22] kasan: add CONFIG_KASAN_GENERIC and CONFIG_KASAN_SW_TAGS

[Mark Rutland]

On Tue, Nov 06, 2018 at 06:30:20PM +0100, Andrey Konovalov wrote:
> This commit splits the current CONFIG_KASAN config option into two:
> 1. CONFIG_KASAN_GENERIC, that enables the generic KASAN mode (the one
>that exists now);
> 2. CONFIG_KASAN_SW_TAGS, that enables the software tag-based KASAN mode.
> 
> The name CONFIG_KASAN_SW_TAGS is chosen as in the future we will have
> another hardware tag-based KASAN mode, that will rely on hardware memory
> tagging support in arm64.
> 
> With CONFIG_KASAN_SW_TAGS enabled, compiler options are changed to
> instrument kernel files with -fsantize=kernel-hwaddress (except the ones
> for which KASAN_SANITIZE := n is set).
> 
> Both CONFIG_KASAN_GENERIC and CONFIG_KASAN_SW_TAGS support both
> CONFIG_KASAN_INLINE and CONFIG_KASAN_OUTLINE instrumentation modes.
> 
> This commit also adds empty placeholder (for now) implementation of
> tag-based KASAN specific hooks inserted by the compiler and adjusts
> common hooks implementation to compile correctly with each of the
> config options.
> 
> Reviewed-by: Andrey Ryabinin 
> Reviewed-by: Dmitry Vyukov 
> Signed-off-by: Andrey Konovalov 
> ---
>  arch/arm64/Kconfig  |  1 +
>  include/linux/compiler-clang.h  |  5 +-
>  include/linux/compiler-gcc.h|  6 ++
>  include/linux/compiler_attributes.h | 13 -
>  include/linux/kasan.h   | 16 --
>  lib/Kconfig.kasan   | 87 +++--
>  mm/kasan/Makefile   |  6 +-
>  mm/kasan/generic.c  |  2 +-
>  mm/kasan/kasan.h|  3 +-
>  mm/kasan/tags.c | 75 +
>  mm/slub.c   |  2 +-
>  scripts/Makefile.kasan  | 27 -
>  12 files changed, 201 insertions(+), 42 deletions(-)
>  create mode 100644 mm/kasan/tags.c
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 787d7850e064..8b331dcfb48e 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -111,6 +111,7 @@ config ARM64
>   select HAVE_ARCH_JUMP_LABEL
>   select HAVE_ARCH_JUMP_LABEL_RELATIVE
>   select HAVE_ARCH_KASAN if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
> + select HAVE_ARCH_KASAN_SW_TAGS if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)

Given this relies on a compiler feature, can we please gate this on
compiler feature detection? e.g. in some common Kconfig have:

select CC_HAS_ASAN_HWADDRESS if $(cc-option -fsanitize=kernel-hwaddress)

... and on arm64 we can do:

select HAVE_ARCH_KASAN_SW_TAGS if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)

... and core KASAN Kconfig can have:

config KASAN_SW_TAGS
depends on HAVE_ARCH_KASAN_SW_TAGS
depends on CC_HAS_ASAN_HWADDRESS

[...]

> +ifeq ($(call cc-option, $(CFLAGS_KASAN) -Werror),)
> +ifneq ($(CONFIG_COMPILE_TEST),y)
> +$(warning Cannot use CONFIG_KASAN_SW_TAGS: \
> +-fsanitize=hwaddress is not supported by compiler)
> +endif
> +endif

... and then this warning shouldn't be possible, and can go.

Thanks,
Mark.

Re: [PATCH 1/3] i3c: master: Add driver for Synopsys DesignWare IP

[Matthew Wilcox]

On Mon, Oct 29, 2018 at 10:06:56AM +, Vitor soares wrote:
> Add driver for Synopsys DesignWare I3C master IP

The so-called "data sheet" (actually just an advertising brochure)
on your website claims DMA support.  I don't see that support
anywhere in this driver.

Re: [PATCH v10 07/22] kasan: initialize shadow to 0xff for tag-based mode

[Mark Rutland]

On Tue, Nov 06, 2018 at 06:30:22PM +0100, Andrey Konovalov wrote:
> A tag-based KASAN shadow memory cell contains a memory tag, that
> corresponds to the tag in the top byte of the pointer, that points to that
> memory. The native top byte value of kernel pointers is 0xff, so with
> tag-based KASAN we need to initialize shadow memory to 0xff.
> 
> Reviewed-by: Andrey Ryabinin 
> Reviewed-by: Dmitry Vyukov 
> Signed-off-by: Andrey Konovalov 
> ---
>  arch/arm64/mm/kasan_init.c | 16 ++--
>  include/linux/kasan.h  |  8 
>  mm/kasan/common.c  |  3 ++-
>  3 files changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> index 63527e585aac..18ebc8994a7b 100644
> --- a/arch/arm64/mm/kasan_init.c
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -43,6 +43,15 @@ static phys_addr_t __init kasan_alloc_zeroed_page(int node)
>   return __pa(p);
>  }
>  
> +static phys_addr_t __init kasan_alloc_raw_page(int node)
> +{
> + void *p = memblock_alloc_try_nid_raw(PAGE_SIZE, PAGE_SIZE,
> + __pa(MAX_DMA_ADDRESS),
> + MEMBLOCK_ALLOC_ACCESSIBLE,
> + node);
> + return __pa(p);
> +}
> +
>  static pte_t *__init kasan_pte_offset(pmd_t *pmdp, unsigned long addr, int 
> node,
> bool early)
>  {
> @@ -88,7 +97,9 @@ static void __init kasan_pte_populate(pmd_t *pmdp, unsigned 
> long addr,
>  
>   do {
>   phys_addr_t page_phys = early ? __pa_symbol(kasan_zero_page)
> -   : kasan_alloc_zeroed_page(node);
> +   : kasan_alloc_raw_page(node);
> + if (!early)
> + memset(__va(page_phys), KASAN_SHADOW_INIT, PAGE_SIZE);
>   next = addr + PAGE_SIZE;
>   set_pte(ptep, pfn_pte(__phys_to_pfn(page_phys), PAGE_KERNEL));
>   } while (ptep++, addr = next, addr != end && 
> pte_none(READ_ONCE(*ptep)));
> @@ -138,6 +149,7 @@ asmlinkage void __init kasan_early_init(void)
>   KASAN_SHADOW_END - (1UL << (64 - KASAN_SHADOW_SCALE_SHIFT)));
>   BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_START, PGDIR_SIZE));
>   BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE));
> +
>   kasan_pgd_populate(KASAN_SHADOW_START, KASAN_SHADOW_END, NUMA_NO_NODE,
>  true);
>  }
> @@ -234,7 +246,7 @@ void __init kasan_init(void)
>   set_pte(&kasan_zero_pte[i],
>   pfn_pte(sym_to_pfn(kasan_zero_page), PAGE_KERNEL_RO));
>  
> - memset(kasan_zero_page, 0, PAGE_SIZE);
> + memset(kasan_zero_page, KASAN_SHADOW_INIT, PAGE_SIZE);

If this isn't going to contain zero, can we please have a preparatory
patch renaming this to something which isn't misleading?

Perhaps kasan_common_shadow_page?

Thanks,
Mark.

Re: [PATCH v15 23/23] x86/sgx: Driver documentation

[Dave Hansen]

On 11/7/18 8:30 AM, Jarkko Sakkinen wrote:
>> Does this code run when I type "make kselftest"?  If not, I think we
>> should rectify that.
> No, it doesn't. It is just my backup for the non-SDK user space code
> that I've made that I will use to fork my user space SGX projects in
> the future.
> 
> I can work-out a selftest (and provide a new patch in the series) but
> I'm still wondering what the enclave should do. I would suggest that
> we start with an enclave that does just EEXIT and nothing else.

Yeah, that's a start.  But, a good selftest would include things like
faults and error conditions.

[PATCH v2 01/11] thermal: remove unused function parameter

[Lukasz Luba]

Clean unused parameter from internal framework function.

Cc: Zhang Rui 
Cc: Eduardo Valentin 
Cc: Daniel Lezcano 
Signed-off-by: Lukasz Luba 
---
 drivers/thermal/thermal_core.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index d6ebc1c..39fc812 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -315,9 +315,7 @@ static void monitor_thermal_zone(struct thermal_zone_device 
*tz)
mutex_unlock(&tz->lock);
 }
 
-static void handle_non_critical_trips(struct thermal_zone_device *tz,
- int trip,
- enum thermal_trip_type trip_type)
+static void handle_non_critical_trips(struct thermal_zone_device *tz, int trip)
 {
tz->governor ? tz->governor->throttle(tz, trip) :
   def_governor->throttle(tz, trip);
@@ -418,7 +416,7 @@ static void handle_thermal_trip(struct thermal_zone_device 
*tz, int trip)
if (type == THERMAL_TRIP_CRITICAL || type == THERMAL_TRIP_HOT)
handle_critical_trips(tz, trip, type);
else
-   handle_non_critical_trips(tz, trip, type);
+   handle_non_critical_trips(tz, trip);
/*
 * Alright, we handled this trip successfully.
 * So, start monitoring again.
-- 
2.7.4

[PATCH v2 11/11] arm: dts: exynos5410: add support for thermal trip irq-mode

[Lukasz Luba]

This patch adds support for new flag which indicates
that trip point triggers IRQ when temperature is met.
Change existing trip points to be expicitly marked with the new flag.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Lukasz Luba 
---
 arch/arm/boot/dts/exynos5410-odroidxu.dts | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts 
b/arch/arm/boot/dts/exynos5410-odroidxu.dts
index 434a759..e85a5d6 100644
--- a/arch/arm/boot/dts/exynos5410-odroidxu.dts
+++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
@@ -121,22 +121,26 @@
cpu_alert0: cpu-alert-0 {
temperature = <5>; /* millicelsius */
hysteresis = <5000>; /* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu_alert1: cpu-alert-1 {
temperature = <6>; /* millicelsius */
hysteresis = <5000>; /* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu_alert2: cpu-alert-2 {
temperature = <7>; /* millicelsius */
hysteresis = <5000>; /* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu_crit0: cpu-crit-0 {
temperature = <12>; /* millicelsius */
hysteresis = <0>; /* millicelsius */
type = "critical";
+   irq-mode;
};
};
 
-- 
2.7.4

[PATCH v2 09/11] arm: dts: exynos5420: add support for thermal trip irq-mode

[Lukasz Luba]

This patch adds support for new flag which indicates
that trip point triggers IRQ when temperature is met.
Change existing trip points to be expicitly marked with the new flag.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Lukasz Luba 
---
 arch/arm/boot/dts/exynos5420-trip-points.dtsi | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420-trip-points.dtsi 
b/arch/arm/boot/dts/exynos5420-trip-points.dtsi
index a67a3807..9e16970 100644
--- a/arch/arm/boot/dts/exynos5420-trip-points.dtsi
+++ b/arch/arm/boot/dts/exynos5420-trip-points.dtsi
@@ -11,21 +11,25 @@ trips {
cpu-alert-0 {
temperature = <85000>; /* millicelsius */
hysteresis = <1>; /* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu-alert-1 {
temperature = <103000>; /* millicelsius */
hysteresis = <1>; /* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu-alert-2 {
temperature = <11>; /* millicelsius */
hysteresis = <1>; /* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu-crit-0 {
temperature = <12>; /* millicelsius */
hysteresis = <0>; /* millicelsius */
type = "critical";
+   irq-mode;
};
 };
-- 
2.7.4

[PATCH v2 00/11] thermal: add new flag irq-mode for trip point

[Lukasz Luba]

Hi all,

This patch set adds a new flag and mechanism in thermal trip points in
DT.  The old implementation in thermal zone in DT sets the same
configuration for all internal trip points. It does not work for all
HW.  There are SoCs which support IRQs for some trip points (i.e.
Exynos 4 has 4 trip points with IRQs). For additional one defined
inside the thermal zone there is a need of 'polling'. When developer
adds polling mode settings inside the thermal zone, all the trip
points will be registered for polling, even those supporting IRQs,
which does not make sense. Thus, developers create workarounds, which
are confusing for some other developers.  To workaround, 
people declare some trip points as 'active' (those with IRQ support).
It allows to bypass polling mode in thermal framework applied for 
all thermal zone's trip points.

Thermal framework defines 4 types of trip points. The 'passive' means
passive cooling using DVFS, 'active' is designed for fan and other
devices actively changing the outside conditions. Therefore, a workaround
mentioned earlier is confusing when someone does not know about the
framework limitations.

This patch set tries to solve the issue by adding one flag inside the
trip point: 'irq-mode;'.  The trip point 'passive' declared in DT with
explicit flag 'irq-mode;' will not register itself as polling mode.
Thermal framework will skip it during scheduling next read out work.
The old global-polling-mode-configuration-inside-thermal-zone is still
valid.  Patch set does not break existing design for trip points which
do not have 'irq-mode' flag - they will use polling.

As an example please check patch #10 for Exynos4 SoC family, where there
is 4 HW supported trip points and there is a need of 6. The rest 2 are
declared as 'passive' without 'irq-mode;' flag, which means polling
mode needed for them.

Patch #1 is a small cleanup in thermal framework.

Change log:
v2
- changed description in cover letter
- change commit messages according to Krzysztof comments
- rebase on top of current mainline (v4.20-rc1)

Regards,
Lukasz Luba

Lukasz Luba (11):
  thermal: remove unused function parameter
  thermal: add irq-mode configuration for trip point
  thermal: add new sysfs file for irq-mode
  Doc: thermal: new irq-mode for trip point
  Doc: DT: thermal: new irq-mode for trip point
  arm64: dts: exynos5433: add support for thermal trip irq-mode
  arm64: dts: exynos7: add support for thermal trip irq-mode
  arm: dts: exynos4: add support for thermal trip irq-mode
  arm: dts: exynos5420: add support for thermal trip irq-mode
  arm: dts: exynos5422: add support for thermal trip irq-mode
  arm: dts: exynos5410: add support for thermal trip irq-mode

 .../devicetree/bindings/thermal/thermal.txt|   7 ++
 Documentation/thermal/sysfs-api.txt|   9 ++
 arch/arm/boot/dts/exynos4-cpu-thermal.dtsi |  10 +-
 arch/arm/boot/dts/exynos5410-odroidxu.dts  |  10 +-
 arch/arm/boot/dts/exynos5420-trip-points.dtsi  |  10 +-
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  40 +---
 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi | 105 ++---
 .../arm64/boot/dts/exynos/exynos7-trip-points.dtsi |   8 ++
 drivers/thermal/of-thermal.c   |  17 
 drivers/thermal/thermal_core.c |  16 ++--
 drivers/thermal/thermal_sysfs.c|  53 ++-
 include/linux/thermal.h|   5 +
 12 files changed, 226 insertions(+), 64 deletions(-)

-- 
2.7.4

[PATCH v2 10/11] arm: dts: exynos5422: add support for thermal trip irq-mode

[Lukasz Luba]

This patch adds support for new flag which indicates
that trip point triggers IRQ when temperature is met.
Exynos5422 supports 4 trip points which will trigger IRQ.
Additional trip points should be registered without 'irq-mode' flag.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Lukasz Luba 
---
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 40 +++---
 1 file changed, 28 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index e522edb..389548f 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -59,22 +59,26 @@
cpu0_alert0: cpu-alert-0 {
temperature = <5>; /* millicelsius 
*/
hysteresis = <5000>; /* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu0_alert1: cpu-alert-1 {
temperature = <6>; /* millicelsius 
*/
hysteresis = <5000>; /* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu0_alert2: cpu-alert-2 {
temperature = <7>; /* millicelsius 
*/
hysteresis = <5000>; /* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu0_crit0: cpu-crit-0 {
temperature = <12>; /* millicelsius 
*/
hysteresis = <0>; /* millicelsius */
type = "critical";
+   irq-mode;
};
/*
 * Exynos542x supports only 4 trip-points
@@ -142,22 +146,26 @@
cpu1_alert0: cpu-alert-0 {
temperature = <5>;
hysteresis = <5000>;
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu1_alert1: cpu-alert-1 {
temperature = <6>;
hysteresis = <5000>;
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu1_alert2: cpu-alert-2 {
temperature = <7>;
hysteresis = <5000>;
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu1_crit0: cpu-crit-0 {
temperature = <12>;
hysteresis = <0>;
type = "critical";
+   irq-mode;
};
cpu1_alert3: cpu-alert-3 {
temperature = <7>;
@@ -209,22 +217,26 @@
cpu2_alert0: cpu-alert-0 {
temperature = <5>;
hysteresis = <5000>;
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu2_alert1: cpu-alert-1 {
temperature = <6>;
hysteresis = <5000>;
-   type = "active";
+   type = "passive";
+   irq-mode;
};
  

[PATCH v2 03/11] thermal: add new sysfs file for irq-mode

[Lukasz Luba]

Patch adds show functions for irq-mode feature.
It allocates new attributes and extends the old list.

Cc: Zhang Rui 
Cc: Eduardo Valentin 
Cc: Daniel Lezcano 
Signed-off-by: Lukasz Luba 
---
 drivers/thermal/thermal_sysfs.c | 53 +++--
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
index 2241cea..372b439 100644
--- a/drivers/thermal/thermal_sysfs.c
+++ b/drivers/thermal/thermal_sysfs.c
@@ -21,6 +21,8 @@
 
 #include "thermal_core.h"
 
+#define TRIP_ATTR_NUM 4
+
 /* sys I/F for thermal zone */
 
 static ssize_t
@@ -167,6 +169,28 @@ trip_point_temp_show(struct device *dev, struct 
device_attribute *attr,
 }
 
 static ssize_t
+trip_point_irq_mode_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+   struct thermal_zone_device *tz = to_thermal_zone(dev);
+   int trip, ret;
+   bool mode;
+
+   if (!tz->ops->get_trip_irq_mode)
+   return -EPERM;
+
+   if (sscanf(attr->attr.name, "trip_point_%d_irq", &trip) != 1)
+   return -EINVAL;
+
+   ret = tz->ops->get_trip_irq_mode(tz, trip, &mode);
+
+   if (ret)
+   return ret;
+
+   return sprintf(buf, "%d\n", mode);
+}
+
+static ssize_t
 trip_point_hyst_store(struct device *dev, struct device_attribute *attr,
  const char *buf, size_t count)
 {
@@ -520,10 +544,19 @@ static int create_trip_attrs(struct thermal_zone_device 
*tz, int mask)
if (!tz->trip_type_attrs)
return -ENOMEM;
 
+   tz->trip_irq_mode_attrs = kcalloc(tz->trips,
+ sizeof(*tz->trip_irq_mode_attrs),
+ GFP_KERNEL);
+   if (!tz->trip_irq_mode_attrs) {
+   kfree(tz->trip_type_attrs);
+   return -ENOMEM;
+   }
+
tz->trip_temp_attrs = kcalloc(tz->trips, sizeof(*tz->trip_temp_attrs),
  GFP_KERNEL);
if (!tz->trip_temp_attrs) {
kfree(tz->trip_type_attrs);
+   kfree(tz->trip_irq_mode_attrs);
return -ENOMEM;
}
 
@@ -533,14 +566,17 @@ static int create_trip_attrs(struct thermal_zone_device 
*tz, int mask)
  GFP_KERNEL);
if (!tz->trip_hyst_attrs) {
kfree(tz->trip_type_attrs);
+   kfree(tz->trip_irq_mode_attrs);
kfree(tz->trip_temp_attrs);
return -ENOMEM;
}
}
 
-   attrs = kcalloc(tz->trips * 3 + 1, sizeof(*attrs), GFP_KERNEL);
+   attrs = kcalloc(tz->trips * TRIP_ATTR_NUM + 1, sizeof(*attrs),
+   GFP_KERNEL);
if (!attrs) {
kfree(tz->trip_type_attrs);
+   kfree(tz->trip_irq_mode_attrs);
kfree(tz->trip_temp_attrs);
if (tz->ops->get_trip_hyst)
kfree(tz->trip_hyst_attrs);
@@ -559,6 +595,19 @@ static int create_trip_attrs(struct thermal_zone_device 
*tz, int mask)
tz->trip_type_attrs[indx].attr.show = trip_point_type_show;
attrs[indx] = &tz->trip_type_attrs[indx].attr.attr;
 
+   /* create trip irq_mode attribute */
+   snprintf(tz->trip_irq_mode_attrs[indx].name,
+THERMAL_NAME_LENGTH, "trip_point_%d_irq", indx);
+
+   sysfs_attr_init(&tz->trip_irq_mode_attrs[indx].attr.attr);
+   tz->trip_irq_mode_attrs[indx].attr.attr.name =
+   tz->trip_irq_mode_attrs[indx].name;
+   tz->trip_irq_mode_attrs[indx].attr.attr.mode = S_IRUGO;
+   tz->trip_irq_mode_attrs[indx].attr.show =
+   trip_point_irq_mode_show;
+   attrs[indx + tz->trips * 3] =
+   &tz->trip_irq_mode_attrs[indx].attr.attr;
+
/* create trip temp attribute */
snprintf(tz->trip_temp_attrs[indx].name, THERMAL_NAME_LENGTH,
 "trip_point_%d_temp", indx);
@@ -595,7 +644,7 @@ static int create_trip_attrs(struct thermal_zone_device 
*tz, int mask)
attrs[indx + tz->trips * 2] =
&tz->trip_hyst_attrs[indx].attr.attr;
}
-   attrs[tz->trips * 3] = NULL;
+   attrs[tz->trips * TRIP_ATTR_NUM] = NULL;
 
tz->trips_attribute_group.attrs = attrs;
 
-- 
2.7.4

[PATCH v2 05/11] Doc: DT: thermal: new irq-mode for trip point

[Lukasz Luba]

Thermal trip point gets new flag in DT: irq-mode.
Trip point may have a new explicit flag which indicate
IRQ support when the temperature is met (so the thermal framework
deos not need to set polling for it).
It is useful for 'passive' cooling trip point,
which now will not register for polling the temperature.

Update documentation about irq-mode for trip points.

Cc: Zhang Rui 
Cc: Eduardo Valentin 
Cc: Daniel Lezcano 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Signed-off-by: Lukasz Luba 
---
 Documentation/devicetree/bindings/thermal/thermal.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
b/Documentation/devicetree/bindings/thermal/thermal.txt
index ca14ba9..bee21e3 100644
--- a/Documentation/devicetree/bindings/thermal/thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -90,6 +90,10 @@ Required properties:
"critical": Hardware not reliable.
   Type: string
 
+- irq-mode:A flag indicating that trip rises irq, so there is no
+  Type: bool   need of polling in thermal framework.
+  Size: one cell
+
 * Cooling device maps
 
 The cooling device maps node is a node to describe how cooling devices
@@ -256,16 +260,19 @@ thermal-zones {
temperature = <9>; /* millicelsius */
hysteresis = <2000>; /* millicelsius */
type = "active";
+   irq-mode;
};
cpu_alert1: cpu-alert1 {
temperature = <10>; /* millicelsius */
hysteresis = <2000>; /* millicelsius */
type = "passive";
+   irq-mode;
};
cpu_crit: cpu-crit {
temperature = <125000>; /* millicelsius */
hysteresis = <2000>; /* millicelsius */
type = "critical";
+   irq-mode;
};
};
 
-- 
2.7.4

[PATCH v2 06/11] arm64: dts: exynos5433: add support for thermal trip irq-mode

[Lukasz Luba]

This patch adds support for new flag which indicates
that trip point triggers IRQ when temperature is met.
Exynos5433 supports 8 trip point which will trigger IRQ.
Above that number other trip points should be registered
without 'irq-mode' flag.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Lukasz Luba 
---
 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi | 105 -
 1 file changed, 70 insertions(+), 35 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
index fe3a0b1..c4330f6 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
@@ -17,37 +17,44 @@ thermal-zones {
atlas0_alert_0: atlas0-alert-0 {
temperature = <65000>;  /* millicelsius */
hysteresis = <1000>;/* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
atlas0_alert_1: atlas0-alert-1 {
temperature = <7>;  /* millicelsius */
hysteresis = <1000>;/* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
atlas0_alert_2: atlas0-alert-2 {
temperature = <75000>;  /* millicelsius */
hysteresis = <1000>;/* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
atlas0_alert_3: atlas0-alert-3 {
temperature = <8>;  /* millicelsius */
hysteresis = <1000>;/* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
atlas0_alert_4: atlas0-alert-4 {
temperature = <85000>;  /* millicelsius */
hysteresis = <1000>;/* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
atlas0_alert_5: atlas0-alert-5 {
temperature = <9>;  /* millicelsius */
hysteresis = <1000>;/* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
atlas0_alert_6: atlas0-alert-6 {
temperature = <95000>;  /* millicelsius */
hysteresis = <1000>;/* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
};
 
@@ -98,37 +105,44 @@ thermal-zones {
atlas1_alert_0: atlas1-alert-0 {
temperature = <65000>;  /* millicelsius */
hysteresis = <1000>;/* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
atlas1_alert_1: atlas1-alert-1 {
temperature = <7>;  /* millicelsius */
hysteresis = <1000>;/* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
atlas1_alert_2: atlas1-alert-2 {
temperature = <75000>;  /* millicelsius */
hysteresis = <1000>;/* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
atlas1_alert_3: atlas1-alert-3 {
temperature = <8>;  /* millicelsius */
hysteresis = <1000>;/* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;

[PATCH v2 07/11] arm64: dts: exynos7: add support for thermal trip irq-mode

[Lukasz Luba]

This patch adds support for new flag which indicates
that trip point triggers IRQ when temperature is met.
Change existing trip points to be expicitly marked with the new flag.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Lukasz Luba 
---
 arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
index d3301b8..39185af 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
@@ -11,40 +11,48 @@ trips {
temperature = <75000>; /* millicelsius */
hysteresis = <1>; /* millicelsius */
type = "passive";
+   irq-mode;
};
cpu-alert-1 {
temperature = <8>; /* millicelsius */
hysteresis = <1>; /* millicelsius */
type = "passive";
+   irq-mode;
};
cpu-alert-2 {
temperature = <85000>; /* millicelsius */
hysteresis = <1>; /* millicelsius */
type = "passive";
+   irq-mode;
};
cpu-alert-3 {
temperature = <9>; /* millicelsius */
hysteresis = <1>; /* millicelsius */
type = "passive";
+   irq-mode;
};
cpu-alert-4 {
temperature = <95000>; /* millicelsius */
hysteresis = <1>; /* millicelsius */
type = "passive";
+   irq-mode;
};
cpu-alert-5 {
temperature = <10>; /* millicelsius */
hysteresis = <1>; /* millicelsius */
type = "passive";
+   irq-mode;
};
cpu-alert-6 {
temperature = <11>; /* millicelsius */
hysteresis = <1>; /* millicelsius */
type = "passive";
+   irq-mode;
};
cpu-crit-0 {
temperature = <115000>; /* millicelsius */
hysteresis = <0>; /* millicelsius */
type = "critical";
+   irq-mode;
};
 };
-- 
2.7.4

[PATCH v2 08/11] arm: dts: exynos4: add support for thermal trip irq-mode

[Lukasz Luba]

This patch adds support for new flag which indicates
that trip point triggers IRQ when temperature is met.
Change existing trip points to be expicitly marked with the new flag.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Lukasz Luba 
---
 arch/arm/boot/dts/exynos4-cpu-thermal.dtsi | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4-cpu-thermal.dtsi 
b/arch/arm/boot/dts/exynos4-cpu-thermal.dtsi
index 021d9fc..5e07289 100644
--- a/arch/arm/boot/dts/exynos4-cpu-thermal.dtsi
+++ b/arch/arm/boot/dts/exynos4-cpu-thermal.dtsi
@@ -17,22 +17,26 @@ thermal-zones {
cpu_alert0: cpu-alert-0 {
temperature = <7>; /* millicelsius */
hysteresis = <1>; /* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu_alert1: cpu-alert-1 {
temperature = <95000>; /* millicelsius */
hysteresis = <1>; /* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu_alert2: cpu-alert-2 {
temperature = <11>; /* millicelsius */
hysteresis = <1>; /* millicelsius */
-   type = "active";
+   type = "passive";
+   irq-mode;
};
cpu_crit0: cpu-crit-0 {
temperature = <12>; /* millicelsius */
hysteresis = <0>; /* millicelsius */
type = "critical";
+   irq-mode;
};
};
cooling-maps {
-- 
2.7.4

[PATCH v2 04/11] Doc: thermal: new irq-mode for trip point

[Lukasz Luba]

Thermal trip point gets new flag in DT: irq-mode.
Trip point may have a new explicit flag which indicate
IRQ support when the temperature is met (so the thermal framework
deos not need to set polling for it).
It is useful for 'passive' cooling trip point,
which now will not be register for polling the temperature.

Update documentation about irq-mode for trip points.
The new sysfs file shows 1 if the trip point supports IRQ.

Cc: Jonathan Corbet 
Cc: Zhang Rui 
Cc: linux-doc@vger.kernel.org
Signed-off-by: Lukasz Luba 
---
 Documentation/thermal/sysfs-api.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/thermal/sysfs-api.txt 
b/Documentation/thermal/sysfs-api.txt
index 9113997..e405724 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -272,6 +272,7 @@ Thermal zone device sys I/F, created once it's registered:
 |---trip_point_[0-*]_temp: Trip point temperature
 |---trip_point_[0-*]_type: Trip point type
 |---trip_point_[0-*]_hyst: Hysteresis value for this trip point
+|---trip_point_[0-*]_irq:  Trip point supports triggering irq
 |---emul_temp: Emulated temperature set node
 |---sustainable_power:  Sustainable dissipatable power
 |---k_po:   Proportional term during temperature overshoot
@@ -365,6 +366,10 @@ trip_point_[0-*]_type
thermal zone.
RO, Optional
 
+trip_point_[0-*]_irq
+   Boolean which indicate that the trip point triggers irq.
+   RO, Optional
+
 trip_point_[0-*]_hyst
The hysteresis value for a trip point, represented as an integer
Unit: Celsius
@@ -544,12 +549,16 @@ method, the sys I/F structure will be built like this:
 |---available_policies:step_wise fair_share
 |---trip_point_0_temp: 10
 |---trip_point_0_type: critical
+|---trip_point_0_irq:  1
 |---trip_point_1_temp: 8
 |---trip_point_1_type: passive
+|---trip_point_1_irq:  1
 |---trip_point_2_temp: 7
 |---trip_point_2_type: active0
+|---trip_point_2_irq:  0
 |---trip_point_3_temp: 6
 |---trip_point_3_type: active1
+|---trip_point_3_irq:  1
 |---cdev0: --->/sys/class/thermal/cooling_device0
 |---cdev0_trip_point:  1   /* cdev0 can be used for passive */
 |---cdev0_weight:   1024
-- 
2.7.4

[PATCH v2 02/11] thermal: add irq-mode configuration for trip point

[Lukasz Luba]

This patch adds support irq mode in trip point.
When that flag is set in DT, there is no need for polling
in thermal framework. Crossing the trip point will rise an IRQ.
The naming convention for tip point 'type' can be confussing
and 'passive' (whic is passive cooling) might be interpretted wrongly.

This mechanism prevents from missue and adds explicit setting
for hardware which support interrupts for pre-configured temperature
threshold.

Cc: Zhang Rui 
Cc: Eduardo Valentin 
Cc: Daniel Lezcano 
Signed-off-by: Lukasz Luba 
---
 drivers/thermal/of-thermal.c   | 17 +
 drivers/thermal/thermal_core.c | 10 --
 include/linux/thermal.h|  5 +
 3 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 4bfdb4a..1a75946a 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -312,6 +312,20 @@ static int of_thermal_get_trip_type(struct 
thermal_zone_device *tz, int trip,
return 0;
 }
 
+static int
+of_thermal_get_trip_irq_mode(struct thermal_zone_device *tz, int trip,
+bool *mode)
+{
+   struct __thermal_zone *data = tz->devdata;
+
+   if (trip >= data->ntrips || trip < 0)
+   return -EDOM;
+
+   *mode = data->trips[trip].irq_mode;
+
+   return 0;
+}
+
 static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
int *temp)
 {
@@ -394,6 +408,7 @@ static struct thermal_zone_device_ops of_thermal_ops = {
.set_mode = of_thermal_set_mode,
 
.get_trip_type = of_thermal_get_trip_type,
+   .get_trip_irq_mode = of_thermal_get_trip_irq_mode,
.get_trip_temp = of_thermal_get_trip_temp,
.set_trip_temp = of_thermal_set_trip_temp,
.get_trip_hyst = of_thermal_get_trip_hyst,
@@ -827,6 +842,8 @@ static int thermal_of_populate_trip(struct device_node *np,
return ret;
}
 
+   trip->irq_mode = of_property_read_bool(np, "irq-mode");
+
/* Required for cooling map matching */
trip->np = np;
of_node_get(np);
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 39fc812..6d41e08 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -406,6 +406,7 @@ static void handle_critical_trips(struct 
thermal_zone_device *tz,
 static void handle_thermal_trip(struct thermal_zone_device *tz, int trip)
 {
enum thermal_trip_type type;
+   bool irq_mode = false;
 
/* Ignore disabled trip points */
if (test_bit(trip, &tz->trips_disabled))
@@ -419,9 +420,14 @@ static void handle_thermal_trip(struct thermal_zone_device 
*tz, int trip)
handle_non_critical_trips(tz, trip);
/*
 * Alright, we handled this trip successfully.
-* So, start monitoring again.
+* So, start monitoring in polling mode if
+* trip is not using irq HW support.
 */
-   monitor_thermal_zone(tz);
+   if (tz->ops->get_trip_irq_mode)
+   tz->ops->get_trip_irq_mode(tz, trip, &irq_mode);
+
+   if (!irq_mode)
+   monitor_thermal_zone(tz);
 }
 
 static void update_temperature(struct thermal_zone_device *tz)
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 5f4705f..b064565 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -103,6 +103,7 @@ struct thermal_zone_device_ops {
enum thermal_device_mode);
int (*get_trip_type) (struct thermal_zone_device *, int,
enum thermal_trip_type *);
+   int (*get_trip_irq_mode) (struct thermal_zone_device *, int, bool *);
int (*get_trip_temp) (struct thermal_zone_device *, int, int *);
int (*set_trip_temp) (struct thermal_zone_device *, int, int);
int (*get_trip_hyst) (struct thermal_zone_device *, int, int *);
@@ -196,6 +197,7 @@ struct thermal_zone_device {
struct thermal_attr *trip_temp_attrs;
struct thermal_attr *trip_type_attrs;
struct thermal_attr *trip_hyst_attrs;
+   struct thermal_attr *trip_irq_mode_attrs;
void *devdata;
int trips;
unsigned long trips_disabled;   /* bitmap for disabled trips */
@@ -364,6 +366,8 @@ struct thermal_zone_of_device_ops {
  * @temperature: temperature value in miliCelsius
  * @hysteresis: relative hysteresis in miliCelsius
  * @type: trip point type
+ * @irq_mode: to not use polling in framework set support of HW irq (which will
+ *   be triggered when temperature reaches this level).
  */
 
 struct thermal_trip {
@@ -371,6 +375,7 @@ struct thermal_trip {
int temperature;
int hysteresis;
enum thermal_trip_type type;
+   bool irq_mode;
 };
 
 /* Function declarations */
-- 
2.7.4

Re: [PATCH 1/3] i3c: master: Add driver for Synopsys DesignWare IP

[vitor]

Hi Geert,

On 07/11/18 15:34, Geert Uytterhoeven wrote:

Hi Vitor,

On Wed, Nov 7, 2018 at 4:15 PM vitor  wrote:

On 29/10/18 13:41, Matthew Wilcox wrote:

On Mon, Oct 29, 2018 at 10:06:56AM +, Vitor soares wrote:

+config DW_I3C_MASTER
+tristate "Synospsys DesignWare I3C master driver"
+depends on I3C
+depends on !(ALPHA || PARISC)

why?

Please check this email thread: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2018_10_8_393&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=qVuU64u9x77Y0Kd0PhDK_lpxFgg6PK9PateHwjb_DY0&m=dVPXOATdi751iTXEXYcWuChJA6hcIkXr8tF-i9hrv4E&s=Nk3lXNpRMzhvKMnlXUsFySTr5VYAr2228vXaZfiGBgM&e=

Hence this deserves a comment, so we know when/what to do to drop the
dependency:

 depends on  !(ALPHA || PARISC) # needs {read,write}sl()

Gr{oetje,eeting}s,

 Geert

I agree with you, I just didn't know if I should comment or not. I will 
do that next version.



Best regards,

Vitor Soares

Re: [PATCH v2] Document /proc/pid PID reuse behavior

[Matthew Wilcox]

On Tue, Nov 06, 2018 at 08:01:13AM +0200, Mike Rapoport wrote:
> > diff --git a/Documentation/filesystems/proc.txt 
> > b/Documentation/filesystems/proc.txt
> > index 12a5e6e693b6..0b14460f721d 100644
> > --- a/Documentation/filesystems/proc.txt
> > +++ b/Documentation/filesystems/proc.txt
> > @@ -125,6 +125,13 @@ process running on the system, which is named after 
> > the process ID (PID).
> >  The link  self  points  to  the  process reading the file system. Each 
> > process
> >  subdirectory has the entries listed in Table 1-1.
> >  
> > +Note that an open a file descriptor to /proc/ or to any of its

"open file descriptor" (the "a" is unnecessary)

> > +contained files or subdirectories does not prevent  being reused
> > +for some other process in the event that  exits. Operations on
> > +open /proc/ file descriptors corresponding to dead processes
> > +never act on any new process that the kernel may, through chance, have
> > +also assigned the process ID . Instead, operations on these FDs
> > +usually fail with ESRCH.

The paragraph is a bit wordy.  More pithy:

An open file descriptor for /proc/ (or any of the files or
subdirectories in it) does not prevent  from being reused after
the process exits.  Operations on a file descriptor referring to a dead
process usually return ESRCH.  They do not act on any new process which
has been assigned the same .

Re: [PATCH v10 09/22] kasan: add tag related helper functions

[Mark Rutland]

On Tue, Nov 06, 2018 at 06:30:24PM +0100, Andrey Konovalov wrote:
> This commit adds a few helper functions, that are meant to be used to
> work with tags embedded in the top byte of kernel pointers: to set, to
> get or to reset (set to 0xff) the top byte.
> 
> Reviewed-by: Andrey Ryabinin 
> Reviewed-by: Dmitry Vyukov 
> Signed-off-by: Andrey Konovalov 
> ---
>  arch/arm64/mm/kasan_init.c |  2 ++
>  include/linux/kasan.h  | 13 +
>  mm/kasan/kasan.h   | 55 ++
>  mm/kasan/tags.c| 37 +
>  4 files changed, 107 insertions(+)
> 
> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> index 18ebc8994a7b..370b19d0e2fb 100644
> --- a/arch/arm64/mm/kasan_init.c
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -249,6 +249,8 @@ void __init kasan_init(void)
>   memset(kasan_zero_page, KASAN_SHADOW_INIT, PAGE_SIZE);
>   cpu_replace_ttbr1(lm_alias(swapper_pg_dir));
>  
> + kasan_init_tags();
> +
>   /* At this point kasan is fully initialized. Enable error messages */
>   init_task.kasan_depth = 0;
>   pr_info("KernelAddressSanitizer initialized\n");
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 7f6574c35c62..4c9d6f9029f2 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -169,6 +169,19 @@ static inline void kasan_cache_shutdown(struct 
> kmem_cache *cache) {}
>  
>  #define KASAN_SHADOW_INIT 0xFF
>  
> +void kasan_init_tags(void);
> +
> +void *kasan_reset_tag(const void *addr);
> +
> +#else /* CONFIG_KASAN_SW_TAGS */
> +
> +static inline void kasan_init_tags(void) { }
> +
> +static inline void *kasan_reset_tag(const void *addr)
> +{
> + return (void *)addr;
> +}
> +

> +#ifdef CONFIG_KASAN_SW_TAGS
> +
> +#define KASAN_PTR_TAG_SHIFT 56
> +#define KASAN_PTR_TAG_MASK (0xFFUL << KASAN_PTR_TAG_SHIFT)
> +
> +u8 random_tag(void);
> +
> +static inline void *set_tag(const void *addr, u8 tag)
> +{
> + u64 a = (u64)addr;
> +
> + a &= ~KASAN_PTR_TAG_MASK;
> + a |= ((u64)tag << KASAN_PTR_TAG_SHIFT);
> +
> + return (void *)a;
> +}
> +
> +static inline u8 get_tag(const void *addr)
> +{
> + return (u8)((u64)addr >> KASAN_PTR_TAG_SHIFT);
> +}
> +
> +static inline void *reset_tag(const void *addr)
> +{
> + return set_tag(addr, KASAN_TAG_KERNEL);
> +}

We seem to be duplicating this functionality in several places.

Could we please make it so that the arch code defines macros:

arch_kasan_set_tag(addr, tag)
arch_kasan_get_tag(addr)
arch_kasan_reset_tag(addr)

... and use thoses consistently rather than open-coding them?

> +
> +#else /* CONFIG_KASAN_SW_TAGS */
> +
> +static inline u8 random_tag(void)
> +{
> + return 0;
> +}
> +
> +static inline void *set_tag(const void *addr, u8 tag)
> +{
> + return (void *)addr;
> +}
> +
> +static inline u8 get_tag(const void *addr)
> +{
> + return 0;
> +}
> +
> +static inline void *reset_tag(const void *addr)
> +{
> + return (void *)addr;
> +}

... these can be defined in linux/kasan.h as:

#define arch_kasan_set_tag(addr, tag)   (addr)
#define arch_kasan_get_tag(addr)0
#define arch_kasan_reset_tag(addr)  (addr)

Thanks,
Mark.

Re: [PATCH 1/3] i3c: master: Add driver for Synopsys DesignWare IP

[vitor]

Hi Matthew,


On 07/11/18 17:05, Matthew Wilcox wrote:

On Mon, Oct 29, 2018 at 10:06:56AM +, Vitor soares wrote:

Add driver for Synopsys DesignWare I3C master IP

The so-called "data sheet" (actually just an advertising brochure)



The datasheet is there to download.



on your website claims DMA support.  I don't see that support
anywhere in this driver.



Right now the driver does not support DMA interface which will be added 
later as the other missed I3C features.


What do you suggest to avoid this misunderstanding?


Best regards,

Vitor Soares

Re: [PATCH 1/3] i3c: master: Add driver for Synopsys DesignWare IP

[Matthew Wilcox]

On Wed, Nov 07, 2018 at 05:30:22PM +, vitor wrote:
> Hi Matthew,
> 
> 
> On 07/11/18 17:05, Matthew Wilcox wrote:
> > On Mon, Oct 29, 2018 at 10:06:56AM +, Vitor soares wrote:
> > > Add driver for Synopsys DesignWare I3C master IP
> > The so-called "data sheet" (actually just an advertising brochure)
> 
> The datasheet is there to download.

Really?  I went to the link in your message, filled out the stupid
information box that your company has now decided to start spamming
me with, and I got a 2-page brochure telling me how wonderful it was.
It's *called* a datasheet.  Even right there in its name: dwc_mipi_i3c_ds.pdf
It's not a data sheet.

> Right now the driver does not support DMA interface which will be added
> later as the other missed I3C features.
> 
> What do you suggest to avoid this misunderstanding?

A big missing feature like that is probably worth mentioning in a comment.
eg: TODO: DMA support.

Re: [PATCH v10 08/22] kasan, arm64: untag address in __kimg_to_phys and _virt_addr_is_linear

[Catalin Marinas]

On Tue, Nov 06, 2018 at 06:30:23PM +0100, Andrey Konovalov wrote:
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -92,6 +92,15 @@
>  #define KASAN_THREAD_SHIFT   0
>  #endif
>  
> +#ifdef CONFIG_KASAN_SW_TAGS
> +#define KASAN_TAG_SHIFTED(tag)   ((unsigned long)(tag) << 56)
> +#define KASAN_SET_TAG(addr, tag) (((addr) & ~KASAN_TAG_SHIFTED(0xff)) | \
> + KASAN_TAG_SHIFTED(tag))
> +#define KASAN_RESET_TAG(addr)KASAN_SET_TAG(addr, 0xff)
> +#else
> +#define KASAN_RESET_TAG(addr)addr
> +#endif

I think we should reuse the untagged_addr() macro we have in uaccess.h
(make it more general and move to another header file).

-- 
Catalin

Re: [PATCH v2] Document /proc/pid PID reuse behavior

[Daniel Colascione]

On Wed, Nov 7, 2018 at 9:16 AM, Matthew Wilcox  wrote:
> On Tue, Nov 06, 2018 at 08:01:13AM +0200, Mike Rapoport wrote:
>> > diff --git a/Documentation/filesystems/proc.txt 
>> > b/Documentation/filesystems/proc.txt
>> > index 12a5e6e693b6..0b14460f721d 100644
>> > --- a/Documentation/filesystems/proc.txt
>> > +++ b/Documentation/filesystems/proc.txt
>> > @@ -125,6 +125,13 @@ process running on the system, which is named after 
>> > the process ID (PID).
>> >  The link  self  points  to  the  process reading the file system. Each 
>> > process
>> >  subdirectory has the entries listed in Table 1-1.
>> >
>> > +Note that an open a file descriptor to /proc/ or to any of its
>
> "open file descriptor" (the "a" is unnecessary)

Thanks for spotting that. I had to re-read that sentence three times
or so before even seeing that extra "a".

>> > +contained files or subdirectories does not prevent  being reused
>> > +for some other process in the event that  exits. Operations on
>> > +open /proc/ file descriptors corresponding to dead processes
>> > +never act on any new process that the kernel may, through chance, have
>> > +also assigned the process ID . Instead, operations on these FDs
>> > +usually fail with ESRCH.
>
> The paragraph is a bit wordy.  More pithy:
>
> An open file descriptor for /proc/ (or any of the files or
> subdirectories in it) does not prevent  from being reused after
> the process exits.  Operations on a file descriptor referring to a dead
> process usually return ESRCH.  They do not act on any new process which
> has been assigned the same .

I'll send a new patch version --- unless we can just tweak the patch
when we merge it into the tree?

Re: [PATCH v10 12/22] kasan, arm64: fix up fault handling logic

[Catalin Marinas]

On Tue, Nov 06, 2018 at 06:30:27PM +0100, Andrey Konovalov wrote:
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 7d9571f4ae3d..d9a84d6f3343 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -141,6 +142,8 @@ void show_pte(unsigned long addr)
>   pgd_t *pgdp;
>   pgd_t pgd;
>  
> + addr = (unsigned long)kasan_reset_tag((void *)addr);
> +
>   if (addr < TASK_SIZE) {
>   /* TTBR0 */
>   mm = current->active_mm;

I think we should clear the tag earlier on in the fault handling code,
before reaching show_pte().

-- 
Catalin

Re: [PATCH v2 2/2] kernel-doc: extend $type_param to match members referenced by pointer

[Markus Heiser]

Am 07.11.18 um 17:47 schrieb Mike Rapoport:

Currently, function parameter description can match '@type.member'
expressions but fails to match '@type->member'.
Extend the $type_param regex to allow matching both

Signed-off-by: Mike Rapoport 
---
  scripts/kernel-doc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 24d3550..f9f1431 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -212,7 +212,7 @@ my $anon_struct_union = 0;
  my $type_constant = '\b``([^\`]+)``\b';
  my $type_constant2 = '\%([-_\w]+)';
  my $type_func = '(\w+)\(\)';
-my $type_param = '\@(\w*(\.\w+)*(\.\.\.)?)';
+my $type_param = '\@(\w*((\.\w+)|(->\w+))*(\.\.\.)?)';


Thanks, works! FWIW: added [1] this to the linuxdoc project (a kernel-doc
spinoff).  There we have a small frmaework for testing kernel-doc patches [2].
Which found a few hundert usages of '->' pointers in the whole kernel sources.

[1] https://github.com/return42/linuxdoc/commit/cce336ce0
[2] https://github.com/return42/linuxdoc/blob/master/Makefile#L95

-- Markus --

Re: [PATCHv10 3/8] firmware: add Intel Stratix10 service layer driver

[Richard Gong]

Hi Randy,

On 11/6/18 11:03 AM, Randy Dunlap wrote:

On 11/6/18 8:52 AM, richard.g...@linux.intel.com wrote:

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 7273e50..b6813bc 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -216,6 +216,18 @@ config FW_CFG_SYSFS_CMDLINE
  WARNING: Using incorrect parameters (base address in particular)
  may crash your system.
  
+config INTEL_STRATIX10_SERVICE

+   tristate "Intel Stratix10 Service Layer"
+   depends on HAVE_ARM_SMCCC
+   default n
+   help
+Intel Stratix10 service layer runs at privileged exception level,
+   interfaces with the service providers (FPGA manager is one of them) and
+   manages secure monitor call to communicate with secure monitor software
+   at secure monitor exception level.
+
+Say Y here if you want Stratix10 service layer support.


from Documentation/process/coding-style.rst:

Lines under a ``config`` definition are indented with one tab,
while help text is indented an additional two spaces.




I will correct that in the next submission.


thanks.



Regards,
Richard

Re: [PATCHv10 8/8] firmware: add remote status update client support

[Richard Gong]

Hi Moritz,

On 11/6/18 11:22 AM, Moritz Fischer wrote:

Hi Richard,

On Tue, Nov 06, 2018 at 10:52:52AM -0600, richard.g...@linux.intel.com wrote:

From: Richard Gong 

Extend Intel Stratix10 service layer to support the second service layer
client, Remote Status Update (RSU).

RSU is used to provide our customers with protection against loading bas

Nit: 'bas' -> 'bad'

bitstreams onto their devices when those device are booting from flash.



I will correct that in the next submission.


Signed-off-by: Richard Gong 
Signed-off-by: Alan Tull 
---
v7: this patch is added in patch set version 7
v8: no change
v9: add case for COMMAND_RSU_UPDATE at svc_thread_recv_status_ok() at
 stratix10-svc.c file
 add RSU related definitions at stratix10-smc.h file
v10: s/misc/firmware at commit header
---
  drivers/firmware/stratix10-svc.c   | 35 +++-
  include/linux/firmware/intel/stratix10-smc.h   | 47 ++
  .../linux/firmware/intel/stratix10-svc-client.h| 20 -
  3 files changed, 98 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/stratix10-svc.c b/drivers/firmware/stratix10-svc.c
index 898e588..ae99221 100644
--- a/drivers/firmware/stratix10-svc.c
+++ b/drivers/firmware/stratix10-svc.c
@@ -34,7 +34,7 @@
   * timeout is set to 30 seconds (30 * 1000) at Intel Stratix10 SoC.
   */
  #define SVC_NUM_DATA_IN_FIFO  32
-#define SVC_NUM_CHANNEL1
+#define SVC_NUM_CHANNEL2
  #define FPGA_CONFIG_DATA_CLAIM_TIMEOUT_MS 200
  #define FPGA_CONFIG_STATUS_TIMEOUT_SEC30
  
@@ -271,7 +271,7 @@ static void svc_thread_cmd_config_status(struct stratix10_svc_controller *ctrl,

   * @cb_data: pointer to callback data structure to service client
   * @res: result from SMC or HVC call
   *
- * Send back the correspond status to the service client (FPGA manager etc).
+ * Send back the correspond status to the service clients.
   */
  static void svc_thread_recv_status_ok(struct stratix10_svc_data *p_data,
  struct stratix10_svc_cb_data *cb_data,
@@ -295,6 +295,9 @@ static void svc_thread_recv_status_ok(struct 
stratix10_svc_data *p_data,
case COMMAND_RECONFIG_STATUS:
cb_data->status = BIT(SVC_STATUS_RECONFIG_COMPLETED);
break;
+   case COMMAND_RSU_UPDATE:
+   cb_data->status = BIT(SVC_STATUS_RSU_OK);
+   break;
default:
pr_warn("it shouldn't happen\n");
break;
@@ -373,6 +376,16 @@ static int svc_normal_to_secure_thread(void *data)
a1 = 0;
a2 = 0;
break;
+   case COMMAND_RSU_STATUS:
+   a0 = INTEL_SIP_SMC_RSU_STATUS;
+   a1 = 0;
+   a2 = 0;
+   break;
+   case COMMAND_RSU_UPDATE:
+   a0 = INTEL_SIP_SMC_RSU_UPDATE;
+   a1 = pdata->arg[0];
+   a2 = 0;
+   break;
default:
pr_warn("it shouldn't happen\n");
break;
@@ -389,6 +402,19 @@ static int svc_normal_to_secure_thread(void *data)
 (unsigned int)res.a1, (unsigned int)res.a2);
pr_debug(" res.a3=0x%016x\n", (unsigned int)res.a3);
  
+		if (pdata->command == COMMAND_RSU_STATUS) {

+   if (res.a0 == INTEL_SIP_SMC_RSU_ERROR)
+   cbdata->status = BIT(SVC_STATUS_RSU_ERROR);
+   else
+   cbdata->status = BIT(SVC_STATUS_RSU_OK);
+
+   cbdata->kaddr1 = &res;
+   cbdata->kaddr2 = NULL;
+   cbdata->kaddr3 = NULL;
+   pdata->chan->scl->receive_cb(pdata->chan->scl, cbdata);
+   continue;
+   }
+
switch (res.a0) {
case INTEL_SIP_SMC_STATUS_OK:
svc_thread_recv_status_ok(pdata, cbdata, res);
@@ -941,6 +967,11 @@ static int stratix10_svc_drv_probe(struct platform_device 
*pdev)
chans[0].name = SVC_CLIENT_FPGA;
spin_lock_init(&chans[0].lock);
  
+	chans[1].scl = NULL;

+   chans[1].ctrl = controller;
+   chans[1].name = SVC_CLIENT_RSU;
+   spin_lock_init(&chans[1].lock);
+
list_add_tail(&controller->node, &svc_ctrl);
platform_set_drvdata(pdev, controller);
  
diff --git a/include/linux/firmware/intel/stratix10-smc.h b/include/linux/firmware/intel/stratix10-smc.h

index a109e4c..5be5dab 100644
--- a/include/linux/firmware/intel/stratix10-smc.h
+++ b/include/linux/firmware/intel/stratix10-smc.h
@@ -67,6 +67,12 @@
   *
   * INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR:
   * There is error during the FPGA configuration process.
+ *
+ * INTEL_SIP_SM

Re: [PATCH v14 00/12] Enable cpuset controller in default hierarchy

[Tejun Heo]

Hello,

On Tue, Nov 06, 2018 at 09:06:01AM -0500, Waiman Long wrote:
> On 11/06/2018 06:55 AM, Peter Zijlstra wrote:
> > On Tue, Nov 06, 2018 at 12:53:35PM +0100, Peter Zijlstra wrote:
> >> On Mon, Nov 05, 2018 at 08:36:56AM -0800, Tejun Heo wrote:
> >>> Hello,
> >>>
> >>> So, this looks good to me.  Peter, I'm gonna roll the series into
> >>> cgroup/for-4.21-cpuset.  Please holler if you have any objections /
> >>> comments.
> >> Mostly nits, except I think the interface for cpuset.sched.partition
> >> needs to find another term for "not a parition", "normal" really doesn't
> >> work for me.
> > cpuset.sched.partition: "true", "false", "error"
> >
> > makes more sense to me.
> 
> The terms "true", "false", "error" look good to me. I can change the
> patchset to use those if Tejun has no objection. I will fix the other
> nits you have as well.

How about the following?

Interface file is named "cpuset.cpus.partition" as it's a partition of
cpus.  The writeable keys are "root" and "member" - a partition root
and a partition member.  When "root" is requested but can't be
satisfied it shows "root invalid".  This seems pretty consistent with
cgroup.type and other cpuset files.

Thanks.

-- 
tejun

Re: [PATCH v14 00/12] Enable cpuset controller in default hierarchy

[Waiman Long]

On 11/07/2018 04:32 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, Nov 06, 2018 at 09:06:01AM -0500, Waiman Long wrote:
>> On 11/06/2018 06:55 AM, Peter Zijlstra wrote:
>>> On Tue, Nov 06, 2018 at 12:53:35PM +0100, Peter Zijlstra wrote:
 On Mon, Nov 05, 2018 at 08:36:56AM -0800, Tejun Heo wrote:
> Hello,
>
> So, this looks good to me.  Peter, I'm gonna roll the series into
> cgroup/for-4.21-cpuset.  Please holler if you have any objections /
> comments.
 Mostly nits, except I think the interface for cpuset.sched.partition
 needs to find another term for "not a parition", "normal" really doesn't
 work for me.
>>> cpuset.sched.partition: "true", "false", "error"
>>>
>>> makes more sense to me.
>> The terms "true", "false", "error" look good to me. I can change the
>> patchset to use those if Tejun has no objection. I will fix the other
>> nits you have as well.
> How about the following?
>
> Interface file is named "cpuset.cpus.partition" as it's a partition of
> cpus.  The writeable keys are "root" and "member" - a partition root
> and a partition member.  When "root" is requested but can't be
> satisfied it shows "root invalid".  This seems pretty consistent with
> cgroup.type and other cpuset files.
>
> Thanks.
>
Yes, that looks good. I will revise my patchset to include those changes
unless Peter has other better idea.

Thanks,
Longman

Re: [PATCH V2] doc:it_IT: add some process/* translations

[Jonathan Corbet]

On Fri,  5 Oct 2018 20:51:57 +0200
Federico Vaga  wrote:

> This patch does not translate entirely the subfolder "process/"
> but only part of it (to begin with).
> 
> In order to avoid broken links, I included empty documents
> for those which are not yet translated.
> 
> In order to be able to refer to all documents in "process/",
> I added a sphinx label to those which had not one.
> 
> Translated documents:
> - howto
> - 1.Intro
> - clang-format
> - coding-style
> - kernel-driver-statement
> - magic-number
> - volatile-considered-harmful
> - development-process

So I'm (finally) ready to apply this, but it has conflicts against current
docs-next.  Could I ask you, please, to send me a respin?

Thanks,

jon

Re: [PATCH] Documentation: dynamic_debug: fix a couple of typos

[Jonathan Corbet]

On Fri, 19 Oct 2018 16:55:34 -0700
Randy Dunlap  wrote:

> Fix a few "typos" in dynamic-debug-howto.rst.
> 
> s/dyndbg_query/ddebug_query/
> s/sysfs/debugfs/
> 
> Signed-off-by: Randy Dunlap 
> Cc: Jason Baron 
> Cc: Jonathan Corbet 
> Cc: linux-doc@vger.kernel.org

Applied, thanks.

jon

Re: [PATCH v2] Documentation: dynamic-debug: fix wildcard description

[Jonathan Corbet]

On Fri, 19 Oct 2018 18:10:58 -0700
Randy Dunlap  wrote:

> Fix grammar about wildcards and insert a space between sentences.
> 
> Signed-off-by: Randy Dunlap 
> Cc: Jason Baron 
> Cc: Jonathan Corbet 
> Cc: linux-doc@vger.kernel.org
> Cc: Will Korteland 

Applied, thanks.

jon

Re: [PATCH v2] Documentation/proc.txt: Add 2 missing fields for /proc//status

[Jonathan Corbet]

On Tue, 23 Oct 2018 17:25:51 -0400
Waiman Long  wrote:

> It was found that two of the fields in the /proc//status file were
> missing - CapAmb & Speculation_Store_Bypass. They are now added to the
> proc.txt documentation file.
> 
> v2: Update the example as well.
> 
> Signed-off-by: Waiman Long 

Applied, thanks.

jon

Re: [PATCH] Documentation: fix spelling mistake, EACCESS -> EACCES

[Jonathan Corbet]

On Fri, 26 Oct 2018 18:25:49 +0100
Colin King  wrote:

> Trivial fix to a spelling mistake of the error access name EACCESS,
> rename to EACCES
> 
> Signed-off-by: Colin Ian King 
> ---
>  Documentation/filesystems/spufs.txt | 2 +-
>  Documentation/gpu/drm-uapi.rst  | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)

Applied, thanks.  

This is the first patch to spufs.txt since 2006...I wonder if that stuff
is being used by anybody...

jon

Re: [PATCH] doc-guide:kernel-doc.rst: Reference to foobar

[Jonathan Corbet]

On Sun, 28 Oct 2018 20:28:28 +0100
Joris Gutjahr  wrote:

> In the Function documentation Section of kernel-doc.rst
> there is a function_name() function as an example for
> how to make a comment about a function.
> 
> But at the end of that example there is a reference to foobar 
> instead of function_name.
> 
> I think that should rather be function_name, because that
> was the placeholder the whole example was using.
> 
> Signed-off-by: Joris Gutjahr 

Sure, make sense.  Applied, thanks.

jon

Re: [PATCH v2 2/2] kernel-doc: extend $type_param to match members referenced by pointer

[Jonathan Corbet]

On Wed,  7 Nov 2018 18:47:13 +0200
Mike Rapoport  wrote:

> Currently, function parameter description can match '@type.member'
> expressions but fails to match '@type->member'.
> Extend the $type_param regex to allow matching both
> 
> Signed-off-by: Mike Rapoport 

That makes a lot of changes to the generated output but, as far as I can
tell, they're all correct.  A definite improvement.  Applied, thanks.

jon

Re: [PATCH] [trivial] Documentation/ras: Typo s/use use/use/

[Jonathan Corbet]

On Wed,  7 Nov 2018 14:46:17 +0100
Geert Uytterhoeven  wrote:

> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/admin-guide/ras.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/admin-guide/ras.rst 
> b/Documentation/admin-guide/ras.rst
> index 197896718f813036..c7495e42e6f48bcb 100644
> --- a/Documentation/admin-guide/ras.rst
> +++ b/Documentation/admin-guide/ras.rst
> @@ -54,7 +54,7 @@ those errors are correctable.
>  Types of errors
>  ---
>  
> -Most mechanisms used on modern systems use use technologies like Hamming
> +Most mechanisms used on modern systems use technologies like Hamming
>  Codes that allow error correction when the number of errors on a bit packet
>  is below a threshold. If the number of errors is above, those mechanisms
>  can indicate with a high degree of confidence that an error happened, but

Applied, thanks.

jon

Re: [PATCH resend] Documentation/dev-tools: clean up kselftest.rst

[Jonathan Corbet]

On Sun, 4 Nov 2018 14:06:23 -0800
Randy Dunlap  wrote:

> This is a small cleanup to kselftest.rst:
> 
> - Fix some language typos in the usage instructions.
> - Change one non-ASCII space to an ASCII space.
> 
> Signed-off-by: Randy Dunlap 
> Cc: Shuah Khan 
> Cc: Jonathan Corbet 
> Cc: linux-kselft...@vger.kernel.org
> Cc: linux-doc@vger.kernel.org

Applied, thanks.

jon

Re: [PATCH v14 10/12] cpuset: Add documentation about the new "cpuset.sched.partition" flag

[Waiman Long]

On 11/06/2018 06:50 AM, Peter Zijlstra wrote:
> On Mon, Oct 15, 2018 at 04:29:35PM -0400, Waiman Long wrote:
>> The cgroup-v2.rst file is updated to document the purpose of the new
>> "cpuset.sched.partition" flag and how its usage.
>>
>> Signed-off-by: Waiman Long 
>> ---
>>  Documentation/admin-guide/cgroup-v2.rst | 66 +
>>  1 file changed, 66 insertions(+)
>>
>> diff --git a/Documentation/admin-guide/cgroup-v2.rst 
>> b/Documentation/admin-guide/cgroup-v2.rst
>> index 533e85cb851b..178cda473a26 100644
>> --- a/Documentation/admin-guide/cgroup-v2.rst
>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>> @@ -1686,6 +1686,72 @@ Cpuset Interface Files
>>  
>>  Its value will be affected by memory nodes hotplug events.
>>  
>> +  cpuset.sched.partition
>> +A read-write single value file which exists on non-root
>> +cpuset-enabled cgroups.  It accepts either "0" (off) or "1"
>> +(on) when written to.  
>> + This flag is set and owned by the
>> +parent cgroup.
> What does that mean? The parent cgroup doesn't 'set' anything at all.
> The user will.
>
>> +
>> +If set, it indicates that the current cgroup is the root of a
>> +new partition or scheduling domain that comprises itself and
>> +all its descendants except those that are separate partition
>> +roots themselves and their descendants.  The root cgroup is
>> +always a partition root.
>> +
>> +There are constraints on where this flag can be set.  It can
>> +only be set in a cgroup if all the following conditions are true.
>> +
>> +1) The "cpuset.cpus" is not empty and the list of CPUs are
>> +   exclusive, i.e. they are not shared by any of its siblings.
>> +2) The parent cgroup is a partition root.
>> +3) The "cpuset.cpus" is also a proper subset of the parent's
>> +   "cpuset.cpus.effective".
>> +4) There is no child cgroups with cpuset enabled.  This is for
>> +   eliminating corner cases that have to be handled if such a
>> +   condition is allowed.
>> +
>> +Setting this flag will take the CPUs away from the effective
>> +CPUs of the parent cgroup.  Once it is set, this flag cannot
>> +be cleared if there are any child cgroups with cpuset enabled.
>> +
>> +A parent partition cannot distribute all its CPUs to its
>> +child partitions.  There must be at least one cpu left in the
>> +parent partition.
>> +
>> +Once becoming a partition root, changes to "cpuset.cpus" is
>> +generally allowed as long as the first condition above is true,
>> +the change will not take away all the CPUs from the parent
>> +partition and the new "cpuset.cpus" value is a superset of its
>> +children's "cpuset.cpus" values.
>> +Sometimes, external factors like changes to ancestors'
>> +"cpuset.cpus" or cpu hotplug can cause the state of the partition
>> +root to change.  On read, the "cpuset.sched.partition" file
>> +can show the following values.
> Are those the only conditions under which that -1 can happen? Parent
> taking away CPUs it previously granted and hotplug?

Yes, if none of the cpus are available. It will become invalid. It still
remains a partition (a partial one) if at least one cpu is allocated to
that partition.

>> +
>> +"0"  Not a partition root
>> +"1"  Partition root
>> +"-1" Erroneous partition root
>> +
>> +It is a partition root if the first 2 partition root conditions
>> +above are true and at least one CPU from "cpuset.cpus" is
>> +granted by the parent cgroup.
>> +
>> +A partition root can become an erroneous partition root if none
>> +of CPUs requested in "cpuset.cpus" can be granted by the parent
>> +cgroup or the parent cgroup is no longer a partition root.
>> +In this case, it is not a real partition even though the
>> +restriction of the first partition root condition above will
>> +still apply.  All the tasks in the cgroup will be migrated to
>> +the nearest ancestor partition.
> Effectively or actual? Actual migrating tasks out of the cgroup is
> irreversible.

I am not talking about actual migration to a different cgroup. I am
talking moving to a different partition. When a partition become
invalid, it will inherent the partition parent's effective cpumask.

>> +An erroneous partition root can be transitioned back to a real
>> +partition root if at least one of the requested CPUs can now be
>> +granted by its parent.  In this case, the tasks will be migrated
>> +back to the newly created partition.  Clearing the partition
>> +flag of an erroneous partition root is always allowed even if
>> +child cpusets are present.
> So you need to clarify the above point (I think it is effectively),
> because otherwise you don't know which tasks to put back.

I will clarify that.

Thanks,
Longman

Re: [PATCH v14 05/12] cpuset: Add an error state to cpuset.sched.partition

[Waiman Long]

On 11/06/2018 06:40 AM, Peter Zijlstra wrote:
> On Mon, Oct 15, 2018 at 04:29:30PM -0400, Waiman Long wrote:
>> +spin_lock_irq(&callback_lock);
>> +clear_bit(CS_CPU_EXCLUSIVE, &cp->flags);
>> +spin_unlock_irq(&callback_lock);
> A single atomic bitop wrapped in a spinlock..  maybe it is correct, but
> it looks suspicous.

Yes, you are right. The spin_lock() should not be needed in this case.

Thanks,
Longman

Re: [PATCH] Documentation: fix spelling mistake, EACCESS -> EACCES

[Jeremy Kerr]

Hi Jon,


Signed-off-by: Colin Ian King 
---
  Documentation/filesystems/spufs.txt | 2 +-
  Documentation/gpu/drm-uapi.rst  | 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)


Applied, thanks.

This is the first patch to spufs.txt since 2006...I wonder if that stuff
is being used by anybody...


Anyone who is using the vector processors on the Cell BE processors will
be using it. However, that hardware is becoming pretty rare now.

We'll want to remove the spufs bits if/when we drop support for the cell
platforms (IBM QSxx, PS3, celleb). mpe: any ides on that? Do you have a 
policy for dropping platform support?


Cheers,


Jeremy

Re: [PATCH v3 1/2] kretprobe: produce sane stack traces

[Aleksa Sarai]

On 2018-11-06, Steven Rostedt  wrote:
> On Sun, 4 Nov 2018 22:59:13 +1100
> Aleksa Sarai  wrote:
> 
> > The same issue is present in __save_stack_trace
> > (arch/x86/kernel/stacktrace.c). This is likely the only reason that --
> > as Steven said -- stacktraces wouldn't work with ftrace-graph (and thus
> > with the refactor both of you are discussing).
> 
> By the way, I was playing with the the orc unwinder and stack traces
> from the function graph tracer return code, and got it working with the
> below patch. Caution, that patch also has a stack trace hardcoded in
> the return path of the function graph tracer, so you don't want to run
> function graph tracing without filtering.

Neat!

> diff --git a/kernel/trace/trace_functions_graph.c 
> b/kernel/trace/trace_functions_graph.c
> index 169b3c44ee97..aaeca73218cc 100644
> --- a/kernel/trace/trace_functions_graph.c
> +++ b/kernel/trace/trace_functions_graph.c
> @@ -242,13 +242,16 @@ ftrace_pop_return_trace(struct ftrace_graph_ret *trace, 
> unsigned long *ret,
>   trace->calltime = current->ret_stack[index].calltime;
>   trace->overrun = atomic_read(¤t->trace_overrun);
>   trace->depth = index;
> +
> + trace_dump_stack(0);

Right, this works because save_stack is not being passed a pt_regs. But if
you pass a pt_regs (as happens with bpf_getstackid -- which is what
spawned this discussion) then the top-most entry of the stack will still
be a trampoline because there is no ftrace_graph_ret_addr call.

(I'm struggling with how to fix this -- I can't figure out what retp
should be if you have a pt_regs. ->sp doesn't appear to work -- it's off
by a few bytes.)

I will attach what I have at the moment to hopefully explain what the
issue I've found is (re-using the kretprobe architecture but with the
shadow-stack idea).

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



signature.asc
Description: PGP signature