Re: [PATCH v3] printf: add support for printing symbolic error codes

[Petr Mladek]

On Sun 2019-09-29 22:09:28, Rasmus Villemoes wrote:
> > On Tue 2019-09-17 08:59:59, Rasmus Villemoes wrote:
> >> With my embedded hat on, I've made it possible to remove this.
> >>
> >> I've tested that the #ifdeffery in errcode.c is sufficient to make
> >> this compile on arm, arm64, mips, powerpc, s390, x86 - I'm sure the
> >> 0day bot will tell me which ones I've missed.
> > 
> > Please, remove the above two paragraphs in the final patch. They make
> > sense for review but not for git history.
>
> Agree for the latter, but not the former - I do want to explain why it's
> possible to configure out; see also below.

I see. It was too cryptic for me. I did not get the proper meaning
and context ;-)

> > This change would deserve to spend some time in linux-next. Anyway,
> > it is already too late for 5.4.
> 
> Yes, it's of course way too late now. Perhaps I should ask you to take
> it via the printk tree? Anyway, let's see what we can agree to.

Yup, I could take it via printk.git.

> >> +config SYMBOLIC_ERRCODE
> > 
> > What is the exact reason to make this configurable, please?
> 
> I am one such person, and while 3K may not be a lot, death by a thousand
> paper cuts...
> 
> > I would personally enable it when CONFIG_PRINTK is enabled.
> 
> Agree. So let's make it 'default y if PRINTK'?

Yeah, it makes perfect sense to me.

> > We could always introduce a new config option later when
> > anyone really wants to disable it.
> 
> No, because by the time the kernel has grown too large for some target,
> it's almost impossible to start figuring out which small pieces can be
> chopped away with suitable config options

OK, if you are the embedded guy and you would appreciate the config
then let's have it. Just please add it by a separate patch,
ideally with some numbers.

> and even harder to get
> upstream to accept such configurability ("why, that would only gain you
> 3K...").

I remeber LWN articles about shrinking the kernel for embeded systems
and that every kB was important.


> >> --- /dev/null
> >> +++ b/lib/errcode.c
> >> @@ -0,0 +1,212 @@
> >> +#define E(err) [err + BUILD_BUG_ON_ZERO(err <= 0 || err > 300)] = #err
> >> +static const char *codes_0[] = {
> >> +  E(E2BIG),
> > 
> > I really like the way how the array is initialized.
> 
> Thanks.
> 
> > 
> >> diff --git a/lib/test_printf.c b/lib/test_printf.c
> >> index 944eb50f3862..0401a2341245 100644
> >> --- a/lib/test_printf.c
> >> +++ b/lib/test_printf.c
> >> +static void __init
> >> +errptr(void)
> >> +{
> >> +  test("-1234", "%p", ERR_PTR(-1234));
> >> +  test(S " " S "ff00", "%px %px", ERR_PTR(-1), 
> >> ERR_PTR(-256));
> >> +#ifdef CONFIG_SYMBOLIC_ERRCODE
> >> +  test("EIO EINVAL ENOSPC", "%p %p %p", ERR_PTR(-EIO), ERR_PTR(-EINVAL), 
> >> ERR_PTR(-ENOSPC));
> >> +  test("EAGAIN EAGAIN", "%p %p", ERR_PTR(-EAGAIN), ERR_PTR(-EWOULDBLOCK));
> > 
> > I like that you check more values. But please split it to check
> > only one value per line to make it better readable.
> 
> Hm, ok, but I actually do it this way on purpose - I want to ensure that
> the test where one passes a random not-zero-but-too-small buffer size
> sometimes hits in the middle of the %p output, sometimes just before and
> sometimes just after.

Is this really tested? do_test() function uses buffer for 256 characters.
There are some consistency checks. But any of your test string
is not truncated by the size of the buffer. Do I miss anything, please?

> The very reason I added test_printf was because
> there were some %p extensions that violated the basic rule of
> snprintf()'s return value and/or wrote beyond the provided buffer.

This sounds like a serious bug. Are your aware of any still
existing %p extension that causes this?

> Not a big deal, so if you insist I'll break it up.

Yes, it is not a big deal. But I would still prefer to
understand what is tested. And it is better to have
more tests focused on different aspects than a single
magic one.


> > 
> >> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> >> index b0967cf17137..299fce317eb3 100644
> >> --- a/lib/vsprintf.c
> >> +++ b/lib/vsprintf.c
> >> @@ -2111,6 +2112,31 @@ static noinline_for_stack
> >>  char *pointer(const char *fmt, char *buf, char *end, void *ptr,
> >>  struct printf_spec spec)
> >>  {
> >> +  /*
> >> +   * If it's an ERR_PTR, try to print its symbolic
> >> +   * representation, except for %px, where the user explicitly
> >> +   * wanted the pointer formatted as a hex value.
> >> +   */
> >> +  if (IS_ERR(ptr) && *fmt != 'x') {
> > 
> > We had similar code before the commit 3e5903eb9cff70730171 ("vsprintf:
> > Prevent crash when dereferencing invalid pointers"). Note that the
> > original code kept the original value also for *fmt == 'K'.
> > 
> > Anyway, the above commit tried to unify the handling of special
> > values:
> > 
> >+ use the same strings for special values
> >+ check for special values only when pointer is dereferenced
> > 
> > This patch makes it incon

[PATCH 1/2] scripts/sphinx-pre-install: Change the function 'check_missing_file'

[Jeremy MAURO]

The current implementation take a simple file as first argument, this
change allows to take a list as a first argument.

Some file could have a different path according distribution version

Signed-off-by: Jeremy MAURO 
---
 scripts/sphinx-pre-install | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index 3b638c0e1a4f..b5077ae63a4b 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -124,11 +124,13 @@ sub add_package($$)
 
 sub check_missing_file($$$)
 {
-   my $file = shift;
+   my $files = shift;
my $package = shift;
my $is_optional = shift;
 
-   return if(-e $file);
+   for (@$files) {
+   return if(-e $_);
+   }
 
add_package($package, $is_optional);
 }
@@ -343,10 +345,10 @@ sub give_debian_hints()
);
 
if ($pdf) {
-   
check_missing_file("/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf",
+   
check_missing_file(["/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf"],
   "fonts-dejavu", 2);
 
-   
check_missing_file("/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc",
+   
check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc"],
   "fonts-noto-cjk", 2);
}
 
@@ -413,7 +415,7 @@ sub give_redhat_hints()
}
 
if ($pdf) {
-   
check_missing_file("/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc",
+   
check_missing_file(["/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc"],
   "google-noto-sans-cjk-ttc-fonts", 2);
}
 
@@ -498,7 +500,7 @@ sub give_mageia_hints()
$map{"latexmk"} = "texlive-collection-basic";
 
if ($pdf) {
-   
check_missing_file("/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc",
+   
check_missing_file(["/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc"],
   "google-noto-sans-cjk-ttc-fonts", 2);
}
 
@@ -528,7 +530,7 @@ sub give_arch_linux_hints()
check_pacman_missing(\@archlinux_tex_pkgs, 2) if ($pdf);
 
if ($pdf) {
-   
check_missing_file("/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc",
+   
check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc"],
   "noto-fonts-cjk", 2);
}
 
@@ -549,11 +551,11 @@ sub give_gentoo_hints()
"rsvg-convert"  => "gnome-base/librsvg",
);
 
-   check_missing_file("/usr/share/fonts/dejavu/DejaVuSans.ttf",
+   check_missing_file(["/usr/share/fonts/dejavu/DejaVuSans.ttf"],
   "media-fonts/dejavu", 2) if ($pdf);
 
if ($pdf) {
-   
check_missing_file("/usr/share/fonts/noto-cjk/NotoSansCJKsc-Regular.otf",
+   
check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJKsc-Regular.otf"],
   "media-fonts/noto-cjk", 2);
}
 
-- 
2.23.0

[PATCH 2/2] scripts/sphinx-pre-install: Add a new path for the debian package "fonts-noto-cjk"

[Jeremy MAURO]

The latest debian version "bullseye/sid" has changed the path of the file
"notoserifcjk-regular.ttc", with the previous change and this change we
keep the backward compatibility and add the latest debian version

Signed-off-by: Jeremy MAURO 
---
 scripts/sphinx-pre-install | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index b5077ae63a4b..b5da4202155b 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -348,7 +348,8 @@ sub give_debian_hints()

check_missing_file(["/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf"],
   "fonts-dejavu", 2);
 
-   
check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc"],
+   
check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc",
+   
"/usr/share/fonts/opentype/noto/NotoSerifCJK-Regular.ttc"],
   "fonts-noto-cjk", 2);
}
 
-- 
2.23.0

Re: [PATCH 1/2] scripts/sphinx-pre-install: Change the function 'check_missing_file'

[Mauro Carvalho Chehab]

Em Wed,  2 Oct 2019 11:53:30 +0200
Jeremy MAURO  escreveu:

> The current implementation take a simple file as first argument, this
> change allows to take a list as a first argument.

Please change the title of this patch in a way that it will describe
what it will do, and not what function was changed.

Something like:

scripts/sphinx-pre-install: allow checking for multiple missing files

> 
> Some file could have a different path according distribution version
> 
> Signed-off-by: Jeremy MAURO 
> ---
>  scripts/sphinx-pre-install | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
> index 3b638c0e1a4f..b5077ae63a4b 100755
> --- a/scripts/sphinx-pre-install
> +++ b/scripts/sphinx-pre-install
> @@ -124,11 +124,13 @@ sub add_package($$)
>  
>  sub check_missing_file($$$)

As it is now expecting a list, I would change this function name as
well to:
check_missing_files


With those changes, feel free to add:

Reviewed-by: Mauro Carvalho Chehab 


>  {
> - my $file = shift;
> + my $files = shift;
>   my $package = shift;
>   my $is_optional = shift;
>  
> - return if(-e $file);
> + for (@$files) {
> + return if(-e $_);
> + }
>  
>   add_package($package, $is_optional);
>  }
> @@ -343,10 +345,10 @@ sub give_debian_hints()
>   );
>  
>   if ($pdf) {
> - 
> check_missing_file("/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf",
> + 
> check_missing_file(["/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf"],
>  "fonts-dejavu", 2);
>  
> - 
> check_missing_file("/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc",
> + 
> check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc"],
>  "fonts-noto-cjk", 2);
>   }
>  
> @@ -413,7 +415,7 @@ sub give_redhat_hints()
>   }
>  
>   if ($pdf) {
> - 
> check_missing_file("/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc",
> + 
> check_missing_file(["/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc"],
>  "google-noto-sans-cjk-ttc-fonts", 2);
>   }
>  
> @@ -498,7 +500,7 @@ sub give_mageia_hints()
>   $map{"latexmk"} = "texlive-collection-basic";
>  
>   if ($pdf) {
> - 
> check_missing_file("/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc",
> + 
> check_missing_file(["/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc"],
>  "google-noto-sans-cjk-ttc-fonts", 2);
>   }
>  
> @@ -528,7 +530,7 @@ sub give_arch_linux_hints()
>   check_pacman_missing(\@archlinux_tex_pkgs, 2) if ($pdf);
>  
>   if ($pdf) {
> - 
> check_missing_file("/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc",
> + 
> check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc"],
>  "noto-fonts-cjk", 2);
>   }
>  
> @@ -549,11 +551,11 @@ sub give_gentoo_hints()
>   "rsvg-convert"  => "gnome-base/librsvg",
>   );
>  
> - check_missing_file("/usr/share/fonts/dejavu/DejaVuSans.ttf",
> + check_missing_file(["/usr/share/fonts/dejavu/DejaVuSans.ttf"],
>  "media-fonts/dejavu", 2) if ($pdf);
>  
>   if ($pdf) {
> - 
> check_missing_file("/usr/share/fonts/noto-cjk/NotoSansCJKsc-Regular.otf",
> + 
> check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJKsc-Regular.otf"],
>  "media-fonts/noto-cjk", 2);
>   }
>  



Thanks,
Mauro

Re: [PATCH 2/2] scripts/sphinx-pre-install: Add a new path for the debian package "fonts-noto-cjk"

[Mauro Carvalho Chehab]

Em Wed,  2 Oct 2019 11:54:06 +0200
Jeremy MAURO  escreveu:

> The latest debian version "bullseye/sid" has changed the path of the file
> "notoserifcjk-regular.ttc", with the previous change and this change we
> keep the backward compatibility and add the latest debian version
> 
> Signed-off-by: Jeremy MAURO 
> ---
>  scripts/sphinx-pre-install | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
> index b5077ae63a4b..b5da4202155b 100755
> --- a/scripts/sphinx-pre-install
> +++ b/scripts/sphinx-pre-install
> @@ -348,7 +348,8 @@ sub give_debian_hints()
>   
> check_missing_file(["/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf"],
>  "fonts-dejavu", 2);
>  
> - 
> check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc"],
> + 
> check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc",
> + 
> "/usr/share/fonts/opentype/noto/NotoSerifCJK-Regular.ttc"],
>  "fonts-noto-cjk", 2);

Please align the second line, e. g:


check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc",

"/usr/share/fonts/opentype/noto/NotoSerifCJK-Regular.ttc"],
   "fonts-noto-cjk", 2);



>   }
>  



Thanks,
Mauro

[PATCH] docs: admin-guide: fix printk_ratelimit explanation

[Oleksandr Natalenko]

The printk_ratelimit value accepts seconds, not jiffies (though it is
converted into jiffies internally). Update documentation to reflect
this.

Also, remove the statement about allowing 1 message in 5 seconds since
bursts up to 10 messages are allowed by default.

Finally, while we are here, mention default value for
printk_ratelimit_burst too.

Signed-off-by: Oleksandr Natalenko 
---
 Documentation/admin-guide/sysctl/kernel.rst | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/sysctl/kernel.rst 
b/Documentation/admin-guide/sysctl/kernel.rst
index 032c7cd3cede..6e0da29e55f1 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -831,8 +831,8 @@ printk_ratelimit:
 =
 
 Some warning messages are rate limited. printk_ratelimit specifies
-the minimum length of time between these messages (in jiffies), by
-default we allow one every 5 seconds.
+the minimum length of time between these messages (in seconds).
+The default value is 5 seconds.
 
 A value of 0 will disable rate limiting.
 
@@ -845,6 +845,8 @@ seconds, we do allow a burst of messages to pass through.
 printk_ratelimit_burst specifies the number of messages we can
 send before ratelimiting kicks in.
 
+The default value is 10 messages.
+
 
 printk_devkmsg:
 ===
-- 
2.23.0

Re: [PATCH v2 1/3] x86/boot: Introduce the kernel_info

[Daniel Kiper]

On Tue, Oct 01, 2019 at 03:28:01PM -0700, H. Peter Anvin wrote:
> On 2019-10-01 04:41, Daniel Kiper wrote:
> >
> > OK, so, this is more or less what I had in my v3 patch before sending
> > this email. So, it looks that I am on good track. Great! Though I am not
> > sure that we should have magic for chunked objects. If yes could you
> > explain why? I would just leave len for chunked objects.
> >
>
> It makes it easier to validate the contents (bugs happen...), and would allow
> for multiple chunks that could come from different object files if it ever
> becomes necessary for some reason.

OK.

> We could also just say that dynamic chunks don't even have pointers, and let
> the boot loader just walk the list.

Yeah... That seams simpler. I will do that.

> >> Also "InfO" is a pretty hideous magic. In general, all-ASCII magics have 
> >> much
> >> higher risk of collision than *RANDOM* binary numbers. However, for a 
> >> chunked
> >> architecture they do have the advantage that they can be used also as a 
> >> human
> >> name or file name for the chunk, e.,g. in sysfs, so maybe something like
> >> "LnuX" or even "LToP" for the top-level chunk might make sense.
> >>
> >> How does that sound?
> >
> > Well, your proposals are more cryptic, especially the second one, than
> > mine but I tend to agree that more *RANDOM* magics are better. So,
> > I would choose "LToP" if you decipher it for me. Linux Top?
> >
>
> Yes, Linux top [structure].

Thx!

Daniel

[RFC PATCH 0/2] software node: API documentation

[Heikki Krogerus]

Hi,

I'm sending this as an RFC first. I would like to wait for the API
change Dmitry proposed [1] before we add the final API documentation
for the software nodes.

At this point I would like to know if the generic use is explained
clearly enough and if there is anything missing that should be added.

[1] https://lkml.org/lkml/2019/9/11/8

thanks,

Heikki Krogerus (2):
  software node: Add missing kernel-doc function descriptions
  software node: Add documentation

 Documentation/driver-api/software_node.rst | 197 +
 drivers/base/swnode.c  |  23 +++
 2 files changed, 220 insertions(+)
 create mode 100644 Documentation/driver-api/software_node.rst

-- 
2.23.0

[RFC PATCH 1/2] software node: Add missing kernel-doc function descriptions

[Heikki Krogerus]

Some of the functions were missing kernel-doc style
descriptions.

Signed-off-by: Heikki Krogerus 
---
 drivers/base/swnode.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index a1f3f0994f9f..51c9e6c56c26 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -33,6 +33,10 @@ static struct kset *swnode_kset;
 
 static const struct fwnode_operations software_node_ops;
 
+/**
+ * is_software_node - Test if fwnode handle is software node
+ * @fwnode: The fwnode handle to test
+ */
 bool is_software_node(const struct fwnode_handle *fwnode)
 {
return !IS_ERR_OR_NULL(fwnode) && fwnode->ops == &software_node_ops;
@@ -71,6 +75,10 @@ software_node_to_swnode(const struct software_node *node)
return swnode;
 }
 
+/**
+ * to_software_node - Convert fwnode handle to software node
+ * @fwnode: The fwnode handle of the software node
+ */
 const struct software_node *to_software_node(struct fwnode_handle *fwnode)
 {
struct swnode *swnode = to_swnode(fwnode);
@@ -79,6 +87,10 @@ const struct software_node *to_software_node(struct 
fwnode_handle *fwnode)
 }
 EXPORT_SYMBOL_GPL(to_software_node);
 
+/**
+ * software_node_fwnode - Convert software node to fwnode handle
+ * @swnode: The software node
+ */
 struct fwnode_handle *software_node_fwnode(const struct software_node *node)
 {
struct swnode *swnode = software_node_to_swnode(node);
@@ -802,6 +814,13 @@ int software_node_register(const struct software_node 
*node)
 }
 EXPORT_SYMBOL_GPL(software_node_register);
 
+/**
+ * fwnode_create_software_node - Create and register a software node
+ * @properties: Device properties for the software node
+ * @parent: The parent node
+ *
+ * Returnes the fwnode handle of the software node on success.
+ */
 struct fwnode_handle *
 fwnode_create_software_node(const struct property_entry *properties,
const struct fwnode_handle *parent)
@@ -834,6 +853,10 @@ fwnode_create_software_node(const struct property_entry 
*properties,
 }
 EXPORT_SYMBOL_GPL(fwnode_create_software_node);
 
+/**
+ * fwnode_remove_software_node - Remove a software node
+ * @fwnode: The fwnode handle of the software node
+ */
 void fwnode_remove_software_node(struct fwnode_handle *fwnode)
 {
struct swnode *swnode = to_swnode(fwnode);
-- 
2.23.0

[RFC PATCH 2/2] software node: Add documentation

[Heikki Krogerus]

API documentation for the software nodes.

Signed-off-by: Heikki Krogerus 
---
 Documentation/driver-api/software_node.rst | 197 +
 1 file changed, 197 insertions(+)
 create mode 100644 Documentation/driver-api/software_node.rst

diff --git a/Documentation/driver-api/software_node.rst 
b/Documentation/driver-api/software_node.rst
new file mode 100644
index ..cf8a05c34e9e
--- /dev/null
+++ b/Documentation/driver-api/software_node.rst
@@ -0,0 +1,197 @@
+
+.. _software_node:
+
+==
+Software nodes
+==
+
+Introduction
+
+
+Software node is a :c:type:`struct fwnode_handle ` type,
+analogous to the ACPI and DT firmware nodes except that the software nodes are
+created in kernel code (hence the name "software" node). The software nodes can
+be used to complement fwnodes representing real firmware nodes when they are
+incomplete, for example missing device properties, and to supply the primary
+fwnode when the firmware lacks hardware description for a device completely.
+
+NOTE! The primary hardware description should always come from either ACPI
+tables or DT. Describing an entire system with software nodes, though possible,
+is not acceptable! The software nodes should only complement the primary
+hardware description.
+
+Hierarchy
+=
+
+The software nodes support hierarchy (i.e. the software nodes can have child
+software nodes and a parent software node) just like ACPI and DT firmware 
nodes,
+but there is no dedicated root software node object. It means that a software
+node at the root level does not have a parent.
+
+Note! Only other software nodes can be children and the parent for a software
+node.
+
+Device properties
+=
+
+The software node device properties are described with :c:type:`struct
+property_entry `. When a software node is created that has
+device properties, it is supplied with a zero terminated array of property
+entries. Normally the properties are described with helper macros::
+
+   static const u8 u8_array[] = { 0, 1, 2, 3 };
+   static const u16 u16_array[] = { 0, 1, 2, 3 };
+   static const u32 u32_array[] = { 0, 1, 2, 3 };
+   static const u64 u64_array[] = { 0, 1, 2, 3 };
+
+   static const struct property_entry my_props[] = {
+   PROPERTY_ENTRY_U8_ARRAY("u8_array_example", u8_array),
+   PROPERTY_ENTRY_U16_ARRAY("u16_array_example", u16_array),
+   PROPERTY_ENTRY_U32_ARRAY("u32_array_example", u32_array),
+   PROPERTY_ENTRY_U64_ARRAY("u64_array_example", u64_array),
+   PROPERTY_ENTRY_U8("u8_example", 0xff),
+   PROPERTY_ENTRY_U16("u16_example", 0x),
+   PROPERTY_ENTRY_U32("u32_example", 0x),
+   PROPERTY_ENTRY_U64("u64_example", 0x),
+   PROPERTY_ENTRY_STRING("string_example", "string"),
+   { }
+   };
+
+Note! If "build-in" device properties are supplied to already existing device
+entries by using :c:func:`device_add_properties`, a software node is actually
+created for that device. That software node is just assigned to the device
+automatically in the function.
+
+Usage
+=
+
+Node creation
+-
+
+Static nodes
+
+
+In a normal case the software nodes are described statically with
+:c:type:`struct software_node `, and then registered with
+:c:func:`software_node_register`. Usually there is more then one software node
+that needs to be registered. A helper :c:func:`software_node_register_nodes`
+registers a zero terminated array of software nodes::
+
+   static const struct property_entry props[] = {
+   PROPERTY_ENTRY_STRING("foo", "bar"),
+   { }
+   };
+
+   static const struct software_node my_nodes[] = {
+   { "grandparent" },  /* no parent nor properties */
+   { "parent", &my_nodes[0] }, /* parent, but no propreties */
+   { "child", &my_nodes[1], props }, /* parent and properties */
+   { }
+   };
+
+   static int my_init(void)
+   {
+   return software_node_register_nodes(my_nodes);
+   }
+
+Note! The above example names the nodes "grandparent", "parent" and "child", 
but
+the software nodes don't actually have to be named. If no name is supplied for 
a
+software node when it's being registered, the API names the node "node" 
where
+ is index number.
+
+Dynamic nodes
+~
+
+The Quick (and dirty) method. A software node can be created on the fly with
+:c:func:`fwnode_create_software_node`. The nodes create "on-the-fly" don't
+differ from statically described software nodes in any way, but for now the API
+does not support naming of these nodes::
+
+   static const struct property_entry my_props[] = {
+   PROPERTY_ENTRY_STRING("foo", "bar"),
+   { }
+   };
+
+   static int my_init(void)
+   {
+   str

[PATCH v5 0/5] Add initial support for S32V234-EVB

[Stefan-gabriel Mirea]

Hello,

NXP's S32V234[1] ("Treerunner") vision microprocessors are targeted for
high-performance, computationally intensive vision and sensor fusion
applications that require automotive safety levels. They include leading
edge Camera Vision modules like APEX-2, ISP and GPU. The S32V234-EVB and
S32V234-SBC boards are available for customer evaluation.

The following patch series introduces minimal enablement support for the
NXP S32V234-EVB2[2] board, which leverages most of the SoC capabilities.
Up to v2, this series also included the fsl_linflexuart driver, which has
been included in Linux 5.4-rc1[3].

In the future, we aim to submit multiple drivers upstream, which can be
found in the kernel of our Auto Linux BSP[4] ("ALB"), starting with basic
pinmuxing, clock and uSDHC drivers.

For validation, you can use the U-Boot bootloader in the ALB[5], which we
build and test with our patched version of the Linaro GCC 6.3.1 2017.05
toolchain for ARM 64-bit, with sources available on [6].

Changes in v5:
* Remove the patch 'dt-bindings: serial: Document Freescale LINFlexD UART'
  following its acceptance in Linux 5.4-rc1[8];
* Rebase the other patches on v5.4-rc1.

Changes in v4:
* Remove the patch 'serial: fsl_linflexuart: Update compatible string'
  following its acceptance[7];
* Rebase the patch 'serial: fsl_linflexuart: Be consistent with the name'
  on the tty-next branch in Greg's tty git tree.

Changes in v3:
* Remove the patch 'tty: serial: Add linflexuart driver for S32V234'
  following its acceptance[3];
* Replace 'Freescale' with 'NXP' in the ARCH_S32 config definition and the
  'model' property from the device tree;
* Remove the 'fsl-' prefixes from the dtsi and dts file names;
* Move the 'model' property from (fsl-)s32v234.dtsi to s32v234-evb.dts;
* Add newlines between the cpu nodes in s32v234.dtsi;
* Make use of GIC_SPI, GIC_PPI, GIC_CPU_MASK_SIMPLE and IRQ_TYPE_* in the
  'interrupts' tuples;
* Move the 'timer' and 'interrupt-controller' nodes before 'soc' in
  s32v234.dtsi;
* Be consistent with the 'LINFlexD' spelling in documentation, strings and
  comments; add new patch 'serial: fsl_linflexuart: Be consistent with the
  name' to update the LINFlexD driver as well;
* Remove from fsl,s32-linflexuart.txt a statement regarding the limitation
  to UART mode;
* Make the compatible string SoC specific ("fsl,s32v234-linflexuart"); add
  new patch 'serial: fsl_linflexuart: Update compatible string' to update
  the LINFlexD driver as well;
* In the LINFlexD binding documentation, insert a space between label and
  node name and remove the 'status' property.

Changes in v2:
* Update the entry in fsl.yaml to apply to all S32V234 based boards;
* Add chosen node to dts, with a 'stdout-path' property for earlycon;
* Remove linflex_verify_port(), because it was only called from
  uart_set_info(), which was going to always fail at the "baud_base < 9600"
  check, as we are not using uartclk from uart_port yet;
* Fix compatible string used in OF_EARLYCON_DECLARE.

[1] 
https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/s32-automotive-platform/vision-processor-for-front-and-surround-view-camera-machine-learning-and-sensor-fusion:S32V234
[2] 
https://www.nxp.com/support/developer-resources/evaluation-and-development-boards/ultra-reliable-dev-platforms/s32v-mpus-platforms/s32v-vision-and-sensor-fusion-evaluation-system:S32V234EVB
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09864c1cdf5c537bd01bff45181406e422ea988c
[4] https://source.codeaurora.org/external/autobsps32/linux/
[5] https://source.codeaurora.org/external/autobsps32/u-boot/
[6] https://source.codeaurora.org/external/s32ds/compiler/gcc/
[7] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bd3661ea0eb2056852cbc58c5d96bb4df2f164f
[8] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e16feab6cce2b91d2996d4bc4eff01ece577c4a

Eddy Petrișor (1):
  dt-bindings: arm: fsl: Add the S32V234-EVB board

Mihaela Martinas (2):
  arm64: Introduce config for S32
  arm64: defconfig: Enable configs for S32V234

Stefan-Gabriel Mirea (1):
  serial: fsl_linflexuart: Be consistent with the name

Stoica Cosmin-Stefan (1):
  arm64: dts: fsl: Add device tree for S32V234-EVB

 .../admin-guide/kernel-parameters.txt |   2 +-
 .../devicetree/bindings/arm/fsl.yaml  |   6 +
 arch/arm64/Kconfig.platforms  |   5 +
 arch/arm64/boot/dts/freescale/Makefile|   2 +
 arch/arm64/boot/dts/freescale/s32v234-evb.dts |  25 
 arch/arm64/boot/dts/freescale/s32v234.dtsi| 139 ++
 arch/arm64/configs/defconfig  |   3 +
 drivers/tty/serial/Kconfig|   8 +-
 drivers/tty/serial/fsl_linflexuart.c  |   4 +-
 include/uapi/linux/serial_core.h  |   4 +-
 10 files changed, 189 insertions(+), 9 deletions(-)
 create mode 100644 arch/arm64/boot/dts/freescale/s32v23

[PATCH v5 1/5] dt-bindings: arm: fsl: Add the S32V234-EVB board

[Stefan-gabriel Mirea]

From: Eddy Petrișor 

Add entry for the NXP S32V234 Customer Evaluation Board to the board/SoC
bindings.

Signed-off-by: Eddy Petrișor 
Signed-off-by: Stefan-Gabriel Mirea 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 1b4b4e6573b5..c211f4f82e25 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -335,4 +335,10 @@ properties:
   - fsl,ls2088a-rdb
   - const: fsl,ls2088a
 
+  - description: S32V234 based Boards
+items:
+  - enum:
+  - fsl,s32v234-evb   # S32V234-EVB2 Customer Evaluation 
Board
+  - const: fsl,s32v234
+
 ...
-- 
2.22.0

[PATCH v5 3/5] serial: fsl_linflexuart: Be consistent with the name

[Stefan-gabriel Mirea]

For consistency reasons, spell the controller name as "LINFlexD" in
comments and documentation.

Signed-off-by: Stefan-Gabriel Mirea 
---
 Documentation/admin-guide/kernel-parameters.txt | 2 +-
 drivers/tty/serial/Kconfig  | 8 
 drivers/tty/serial/fsl_linflexuart.c| 4 ++--
 include/uapi/linux/serial_core.h| 4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index c7ac2f3ac99f..666326d74415 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1101,7 +1101,7 @@
mapped with the correct attributes.
 
linflex,
-   Use early console provided by Freescale LinFlex UART
+   Use early console provided by Freescale LINFlexD UART
serial driver for NXP S32V234 SoCs. A valid base
address must be provided, and the serial port must
already be setup and configured.
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 4789b5d62f63..c8e11f62ea19 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1391,19 +1391,19 @@ config SERIAL_FSL_LPUART_CONSOLE
  you can make it the console by answering Y to this option.
 
 config SERIAL_FSL_LINFLEXUART
-   tristate "Freescale linflexuart serial port support"
+   tristate "Freescale LINFlexD UART serial port support"
depends on PRINTK
select SERIAL_CORE
help
- Support for the on-chip linflexuart on some Freescale SOCs.
+ Support for the on-chip LINFlexD UART on some Freescale SOCs.
 
 config SERIAL_FSL_LINFLEXUART_CONSOLE
-   bool "Console on Freescale linflexuart serial port"
+   bool "Console on Freescale LINFlexD UART serial port"
depends on SERIAL_FSL_LINFLEXUART=y
select SERIAL_CORE_CONSOLE
select SERIAL_EARLYCON
help
- If you have enabled the linflexuart serial port on the Freescale
+ If you have enabled the LINFlexD UART serial port on the Freescale
  SoCs, you can make it the console by answering Y to this option.
 
 config SERIAL_CONEXANT_DIGICOLOR
diff --git a/drivers/tty/serial/fsl_linflexuart.c 
b/drivers/tty/serial/fsl_linflexuart.c
index 68d74f2b5106..2d39e13176e1 100644
--- a/drivers/tty/serial/fsl_linflexuart.c
+++ b/drivers/tty/serial/fsl_linflexuart.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /*
- * Freescale linflexuart serial port driver
+ * Freescale LINFlexD UART serial port driver
  *
  * Copyright 2012-2016 Freescale Semiconductor, Inc.
  * Copyright 2017-2018 NXP
@@ -933,5 +933,5 @@ static void __exit linflex_serial_exit(void)
 module_init(linflex_serial_init);
 module_exit(linflex_serial_exit);
 
-MODULE_DESCRIPTION("Freescale linflex serial port driver");
+MODULE_DESCRIPTION("Freescale LINFlexD serial port driver");
 MODULE_LICENSE("GPL v2");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 0f4f87a6fd54..8ec3dd742ea4 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -290,7 +290,7 @@
 /* Sunix UART */
 #define PORT_SUNIX 121
 
-/* Freescale Linflex UART */
-#define PORT_LINFLEXUART   121
+/* Freescale LINFlexD UART */
+#define PORT_LINFLEXUART   122
 
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
2.22.0

[PATCH v5 2/5] arm64: Introduce config for S32

[Stefan-gabriel Mirea]

From: Mihaela Martinas 

Add configuration option for the NXP S32 platform family in
Kconfig.platforms. For starters, the only SoC supported will be Treerunner
(S32V234), with a single execution target: the S32V234-EVB (rev 29288)
board.

Signed-off-by: Mihaela Martinas 
Signed-off-by: Stoica Cosmin-Stefan 
Signed-off-by: Stefan-Gabriel Mirea 
---
 arch/arm64/Kconfig.platforms | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 16d761475a86..17f1c34ec750 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -212,6 +212,11 @@ config ARCH_ROCKCHIP
  This enables support for the ARMv8 based Rockchip chipsets,
  like the RK3368.
 
+config ARCH_S32
+   bool "NXP S32 SoC Family"
+   help
+ This enables support for the NXP S32 family of processors.
+
 config ARCH_SEATTLE
bool "AMD Seattle SoC Family"
help
-- 
2.22.0

[PATCH v5 4/5] arm64: dts: fsl: Add device tree for S32V234-EVB

[Stefan-gabriel Mirea]

From: Stoica Cosmin-Stefan 

Add initial version of device tree for S32V234-EVB, including nodes for the
4 Cortex-A53 cores, AIPS bus with UART modules, ARM architected timer and
Generic Interrupt Controller (GIC).

Keep SoC level separate from board level to let future boards with this SoC
share common properties, while the dts files will keep board-dependent
properties.

Signed-off-by: Stoica Cosmin-Stefan 
Signed-off-by: Mihaela Martinas 
Signed-off-by: Dan Nica 
Signed-off-by: Larisa Grigore 
Signed-off-by: Phu Luu An 
Signed-off-by: Stefan-Gabriel Mirea 
---
 arch/arm64/boot/dts/freescale/Makefile|   2 +
 arch/arm64/boot/dts/freescale/s32v234-evb.dts |  25 
 arch/arm64/boot/dts/freescale/s32v234.dtsi| 139 ++
 3 files changed, 166 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/s32v234-evb.dts
 create mode 100644 arch/arm64/boot/dts/freescale/s32v234.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index 93fce8f0c66d..730209adb2bc 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -32,3 +32,5 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qxp-ai_ml.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qxp-mek.dtb
+
+dtb-$(CONFIG_ARCH_S32) += s32v234-evb.dtb
diff --git a/arch/arm64/boot/dts/freescale/s32v234-evb.dts 
b/arch/arm64/boot/dts/freescale/s32v234-evb.dts
new file mode 100644
index ..4b802518cefc
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/s32v234-evb.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2016-2017 NXP
+ */
+
+/dts-v1/;
+#include "s32v234.dtsi"
+
+/ {
+   model = "NXP S32V234-EVB2 Board";
+   compatible = "fsl,s32v234-evb", "fsl,s32v234";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
+
+&uart1 {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/s32v234.dtsi 
b/arch/arm64/boot/dts/freescale/s32v234.dtsi
new file mode 100644
index ..37225191ccbf
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/s32v234.dtsi
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2016-2018 NXP
+ */
+
+#include 
+
+/memreserve/ 0x8000 0x0001;
+
+/ {
+   compatible = "fsl,s32v234";
+   interrupt-parent = <&gic>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   serial0 = &uart0;
+   serial1 = &uart1;
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0 0x0>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x0 0x8000>;
+   next-level-cache = <&cluster0_l2_cache>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0 0x1>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x0 0x8000>;
+   next-level-cache = <&cluster0_l2_cache>;
+   };
+
+   cpu2: cpu@100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0 0x100>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x0 0x8000>;
+   next-level-cache = <&cluster1_l2_cache>;
+   };
+
+   cpu3: cpu@101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0 0x101>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x0 0x8000>;
+   next-level-cache = <&cluster1_l2_cache>;
+   };
+
+   cluster0_l2_cache: l2-cache0 {
+   compatible = "cache";
+   };
+
+   cluster1_l2_cache: l2-cache1 {
+   compatible = "cache";
+   };
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   interrupts = ,
+,
+,
+;
+   /* clock-frequency might be modified by u-boot, depending on the
+* chip version.
+*/
+   clock-frequency = <1000>;
+   };
+
+   gic: interrupt-controller@7d0010

[PATCH v5 5/5] arm64: defconfig: Enable configs for S32V234

[Stefan-gabriel Mirea]

From: Mihaela Martinas 

Enable support for the S32V234 SoC, including the previously added UART
driver.

Signed-off-by: Mihaela Martinas 
Signed-off-by: Adrian.Nitu 
Signed-off-by: Stoica Cosmin-Stefan 
Signed-off-by: Stefan-Gabriel Mirea 
---
 arch/arm64/configs/defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8e05c39eab08..aa59450557b8 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -48,6 +48,7 @@ CONFIG_ARCH_MXC=y
 CONFIG_ARCH_QCOM=y
 CONFIG_ARCH_RENESAS=y
 CONFIG_ARCH_ROCKCHIP=y
+CONFIG_ARCH_S32=y
 CONFIG_ARCH_SEATTLE=y
 CONFIG_ARCH_STRATIX10=y
 CONFIG_ARCH_SYNQUACER=y
@@ -352,6 +353,8 @@ CONFIG_SERIAL_XILINX_PS_UART=y
 CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
 CONFIG_SERIAL_FSL_LPUART=y
 CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
+CONFIG_SERIAL_FSL_LINFLEXUART=y
+CONFIG_SERIAL_FSL_LINFLEXUART_CONSOLE=y
 CONFIG_SERIAL_MVEBU_UART=y
 CONFIG_SERIAL_DEV_BUS=y
 CONFIG_VIRTIO_CONSOLE=y
-- 
2.22.0

[PATCH v2 1/2] scripts/sphinx-pre-install: allow checking for multiple missing files

[Jeremy MAURO]

The current implementation take a simple file as first argument, this
change allows to take a list as a first argument.

Some file could have a different path according distribution version

Signed-off-by: Jeremy MAURO 
---
Changes in v2:
- Change the commit message

 scripts/sphinx-pre-install | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index 3b638c0e1a4f..b5077ae63a4b 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -124,11 +124,13 @@ sub add_package($$)
 
 sub check_missing_file($$$)
 {
-   my $file = shift;
+   my $files = shift;
my $package = shift;
my $is_optional = shift;
 
-   return if(-e $file);
+   for (@$files) {
+   return if(-e $_);
+   }
 
add_package($package, $is_optional);
 }
@@ -343,10 +345,10 @@ sub give_debian_hints()
);
 
if ($pdf) {
-   
check_missing_file("/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf",
+   
check_missing_file(["/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf"],
   "fonts-dejavu", 2);
 
-   
check_missing_file("/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc",
+   
check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc"],
   "fonts-noto-cjk", 2);
}
 
@@ -413,7 +415,7 @@ sub give_redhat_hints()
}
 
if ($pdf) {
-   
check_missing_file("/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc",
+   
check_missing_file(["/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc"],
   "google-noto-sans-cjk-ttc-fonts", 2);
}
 
@@ -498,7 +500,7 @@ sub give_mageia_hints()
$map{"latexmk"} = "texlive-collection-basic";
 
if ($pdf) {
-   
check_missing_file("/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc",
+   
check_missing_file(["/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc"],
   "google-noto-sans-cjk-ttc-fonts", 2);
}
 
@@ -528,7 +530,7 @@ sub give_arch_linux_hints()
check_pacman_missing(\@archlinux_tex_pkgs, 2) if ($pdf);
 
if ($pdf) {
-   
check_missing_file("/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc",
+   
check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc"],
   "noto-fonts-cjk", 2);
}
 
@@ -549,11 +551,11 @@ sub give_gentoo_hints()
"rsvg-convert"  => "gnome-base/librsvg",
);
 
-   check_missing_file("/usr/share/fonts/dejavu/DejaVuSans.ttf",
+   check_missing_file(["/usr/share/fonts/dejavu/DejaVuSans.ttf"],
   "media-fonts/dejavu", 2) if ($pdf);
 
if ($pdf) {
-   
check_missing_file("/usr/share/fonts/noto-cjk/NotoSansCJKsc-Regular.otf",
+   
check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJKsc-Regular.otf"],
   "media-fonts/noto-cjk", 2);
}
 
-- 
2.23.0

[PATCH v2 2/2] scripts/sphinx-pre-install: Add a new path for the debian package "fonts-noto-cjk"

[Jeremy MAURO]

The latest debian version "bullseye/sid" has changed the path of the file
"notoserifcjk-regular.ttc", with the previous change and this change we
keep the backward compatibility and add the latest debian version

Signed-off-by: Jeremy MAURO 
---
Changes in V2:
- Align all lines

 scripts/sphinx-pre-install | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index b5077ae63a4b..1f9285274587 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -348,7 +348,8 @@ sub give_debian_hints()

check_missing_file(["/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf"],
   "fonts-dejavu", 2);
 
-   
check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc"],
+   
check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc",
+  
"/usr/share/fonts/opentype/noto/NotoSerifCJK-Regular.ttc"],
   "fonts-noto-cjk", 2);
}
 
-- 
2.23.0

Re: [PATCH RESEND] k10temp: update docs and add temp2_input info

[Guenter Roeck]

On Mon, Sep 23, 2019 at 12:59:31PM +0200, Lukas Zapletal wrote:
> It's been a while since the k10temp documentation has been updated.
> There are new CPU families supported as well as Tdie temp was added.
> This patch adds all missing families which I was able to find from git
> history and provides more info about Tctl vs Tdie exported temps.
> 
> Signed-off-by: Lukas Zapletal 

Applied.

Thanks,
Guenter

> ---
>  Documentation/hwmon/k10temp.rst | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/hwmon/k10temp.rst b/Documentation/hwmon/k10temp.rst
> index 12a86ba17de9..fc9d2a5ad57d 100644
> --- a/Documentation/hwmon/k10temp.rst
> +++ b/Documentation/hwmon/k10temp.rst
> @@ -21,10 +21,16 @@ Supported chips:
>  
>  * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series)
>  
> -* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri", 
> "Carrizo"
> +* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri", 
> "Carrizo", "Stoney Ridge", "Bristol Ridge"
>  
>  * AMD Family 16h processors: "Kabini", "Mullins"
>  
> +* AMD Family 17h processors: "Zen", "Zen 2"
> +
> +* AMD Family 18h processors: "Hygon Dhyana"
> +
> +* AMD Family 19h processors: "Zen 3"
> +
>Prefix: 'k10temp'
>  
>Addresses scanned: PCI space
> @@ -110,3 +116,12 @@ The maximum value for Tctl is available in the file 
> temp1_max.
>  If the BIOS has enabled hardware temperature control, the threshold at
>  which the processor will throttle itself to avoid damage is available in
>  temp1_crit and temp1_crit_hyst.
> +
> +On some AMD CPUs, there is a difference between the die temperature (Tdie) 
> and
> +the reported temperature (Tctl). Tdie is the real measured temperature, and
> +Tctl is used for fan control. While Tctl is always available as temp1_input,
> +the driver exports Tdie temperature as temp2_input for those CPUs which 
> support
> +it.
> +
> +Models from 17h family report relative temperature, the driver aims to
> +compensate and report the real temperature.

Re: [PATCH 1/3] hwmon: Fix HWMON_P_MIN_ALARM mask

[Guenter Roeck]

On Tue, Sep 24, 2019 at 02:49:43PM +0200, Nuno Sá wrote:
> Both HWMON_P_MIN_ALARM and HWMON_P_MAX_ALARM were using
> BIT(hwmon_power_max_alarm).
> 
> Fixes: aa7f29b07c870 ("hwmon: Add support for power min, lcrit, min_alarm and 
> lcrit_alarm")
> CC: 
> Signed-off-by: Nuno Sá 

Applied.

Thanks,
Guenter

> ---
>  include/linux/hwmon.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
> index 04c36b7a61dd..72579168189d 100644
> --- a/include/linux/hwmon.h
> +++ b/include/linux/hwmon.h
> @@ -235,7 +235,7 @@ enum hwmon_power_attributes {
>  #define HWMON_P_LABELBIT(hwmon_power_label)
>  #define HWMON_P_ALARMBIT(hwmon_power_alarm)
>  #define HWMON_P_CAP_ALARMBIT(hwmon_power_cap_alarm)
> -#define HWMON_P_MIN_ALARMBIT(hwmon_power_max_alarm)
> +#define HWMON_P_MIN_ALARMBIT(hwmon_power_min_alarm)
>  #define HWMON_P_MAX_ALARMBIT(hwmon_power_max_alarm)
>  #define HWMON_P_LCRIT_ALARM  BIT(hwmon_power_lcrit_alarm)
>  #define HWMON_P_CRIT_ALARM   BIT(hwmon_power_crit_alarm)

Re: [PATCH 1/3] docs: fix some broken references

[Guenter Roeck]

On Tue, Sep 24, 2019 at 10:01:28AM -0300, Mauro Carvalho Chehab wrote:
> There are a number of documentation files that got moved or
> renamed. update their references.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> Acked-by: Shannon Nelson 
> ---
>  Documentation/devicetree/bindings/cpu/cpu-topology.txt| 2 +-
>  Documentation/devicetree/bindings/timer/ingenic,tcu.txt   | 2 +-
>  Documentation/driver-api/gpio/driver.rst  | 2 +-
>  Documentation/hwmon/inspur-ipsps1.rst | 2 +-

For hwmon:

Acked-by: Guenter Roeck 

>  Documentation/mips/ingenic-tcu.rst| 2 +-
>  Documentation/networking/device_drivers/mellanox/mlx5.rst | 2 +-
>  MAINTAINERS   | 2 +-
>  drivers/net/ethernet/faraday/ftgmac100.c  | 2 +-
>  drivers/net/ethernet/pensando/ionic/ionic_if.h| 4 ++--
>  fs/cifs/cifsfs.c  | 2 +-
>  10 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/cpu/cpu-topology.txt 
> b/Documentation/devicetree/bindings/cpu/cpu-topology.txt
> index 99918189403c..9bd530a35d14 100644
> --- a/Documentation/devicetree/bindings/cpu/cpu-topology.txt
> +++ b/Documentation/devicetree/bindings/cpu/cpu-topology.txt
> @@ -549,5 +549,5 @@ Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system)
>  [2] Devicetree NUMA binding description
>  Documentation/devicetree/bindings/numa.txt
>  [3] RISC-V Linux kernel documentation
> -Documentation/devicetree/bindings/riscv/cpus.txt
> +Documentation/devicetree/bindings/riscv/cpus.yaml
>  [4] https://www.devicetree.org/specifications/
> diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.txt 
> b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
> index 5a4b9ddd9470..7f6fe20503f5 100644
> --- a/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
> +++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
> @@ -2,7 +2,7 @@ Ingenic JZ47xx SoCs Timer/Counter Unit devicetree bindings
>  ==
>  
>  For a description of the TCU hardware and drivers, have a look at
> -Documentation/mips/ingenic-tcu.txt.
> +Documentation/mips/ingenic-tcu.rst.
>  
>  Required properties:
>  
> diff --git a/Documentation/driver-api/gpio/driver.rst 
> b/Documentation/driver-api/gpio/driver.rst
> index 3fdb32422f8a..9076cc76d5bf 100644
> --- a/Documentation/driver-api/gpio/driver.rst
> +++ b/Documentation/driver-api/gpio/driver.rst
> @@ -493,7 +493,7 @@ available but we try to move away from this:
>gpiochip. It will pass the struct gpio_chip* for the chip to all IRQ
>callbacks, so the callbacks need to embed the gpio_chip in its state
>container and obtain a pointer to the container using container_of().
> -  (See Documentation/driver-model/design-patterns.txt)
> +  (See Documentation/driver-api/driver-model/design-patterns.rst)
>  
>  - gpiochip_irqchip_add_nested(): adds a nested cascaded irqchip to a 
> gpiochip,
>as discussed above regarding different types of cascaded irqchips. The
> diff --git a/Documentation/hwmon/inspur-ipsps1.rst 
> b/Documentation/hwmon/inspur-ipsps1.rst
> index 2b871ae3448f..ed32a65c30e1 100644
> --- a/Documentation/hwmon/inspur-ipsps1.rst
> +++ b/Documentation/hwmon/inspur-ipsps1.rst
> @@ -17,7 +17,7 @@ Usage Notes
>  ---
>  
>  This driver does not auto-detect devices. You will have to instantiate the
> -devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst 
> for
>  details.
>  
>  Sysfs entries
> diff --git a/Documentation/mips/ingenic-tcu.rst 
> b/Documentation/mips/ingenic-tcu.rst
> index c4ef4c45aade..c5a646b14450 100644
> --- a/Documentation/mips/ingenic-tcu.rst
> +++ b/Documentation/mips/ingenic-tcu.rst
> @@ -68,4 +68,4 @@ and frameworks can be controlled from the same registers, 
> all of these
>  drivers access their registers through the same regmap.
>  
>  For more information regarding the devicetree bindings of the TCU drivers,
> -have a look at Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
> +have a look at Documentation/devicetree/bindings/timer/ingenic,tcu.txt.
> diff --git a/Documentation/networking/device_drivers/mellanox/mlx5.rst 
> b/Documentation/networking/device_drivers/mellanox/mlx5.rst
> index d071c6b49e1f..a74422058351 100644
> --- a/Documentation/networking/device_drivers/mellanox/mlx5.rst
> +++ b/Documentation/networking/device_drivers/mellanox/mlx5.rst
> @@ -258,7 +258,7 @@ mlx5 tracepoints
>  
>  
>  mlx5 driver provides internal trace points for tracking and debugging using
> -kernel tracepoints interfaces (refer to Documentation/trace/ftrase.rst).
> +kernel tracepoints interfaces (refer to Documentation/trace/ftrace.rst).
>  
>  For the list of support mlx5 events check 
> /sys/kernel/debug/tracing/events/mlx5/

Re: [PATCH v2 1/2] scripts/sphinx-pre-install: allow checking for multiple missing files

[Mauro Carvalho Chehab]

Em Wed,  2 Oct 2019 15:33:39 +0200
Jeremy MAURO  escreveu:

> The current implementation take a simple file as first argument, this
> change allows to take a list as a first argument.
> 
> Some file could have a different path according distribution version
> 
> Signed-off-by: Jeremy MAURO 

Reviewed-by: Mauro Carvalho Chehab 

> ---
> Changes in v2:
> - Change the commit message
> 
>  scripts/sphinx-pre-install | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
> index 3b638c0e1a4f..b5077ae63a4b 100755
> --- a/scripts/sphinx-pre-install
> +++ b/scripts/sphinx-pre-install
> @@ -124,11 +124,13 @@ sub add_package($$)
>  
>  sub check_missing_file($$$)
>  {
> - my $file = shift;
> + my $files = shift;
>   my $package = shift;
>   my $is_optional = shift;
>  
> - return if(-e $file);
> + for (@$files) {
> + return if(-e $_);
> + }
>  
>   add_package($package, $is_optional);
>  }
> @@ -343,10 +345,10 @@ sub give_debian_hints()
>   );
>  
>   if ($pdf) {
> - 
> check_missing_file("/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf",
> + 
> check_missing_file(["/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf"],
>  "fonts-dejavu", 2);
>  
> - 
> check_missing_file("/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc",
> + 
> check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc"],
>  "fonts-noto-cjk", 2);
>   }
>  
> @@ -413,7 +415,7 @@ sub give_redhat_hints()
>   }
>  
>   if ($pdf) {
> - 
> check_missing_file("/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc",
> + 
> check_missing_file(["/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc"],
>  "google-noto-sans-cjk-ttc-fonts", 2);
>   }
>  
> @@ -498,7 +500,7 @@ sub give_mageia_hints()
>   $map{"latexmk"} = "texlive-collection-basic";
>  
>   if ($pdf) {
> - 
> check_missing_file("/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc",
> + 
> check_missing_file(["/usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc"],
>  "google-noto-sans-cjk-ttc-fonts", 2);
>   }
>  
> @@ -528,7 +530,7 @@ sub give_arch_linux_hints()
>   check_pacman_missing(\@archlinux_tex_pkgs, 2) if ($pdf);
>  
>   if ($pdf) {
> - 
> check_missing_file("/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc",
> + 
> check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc"],
>  "noto-fonts-cjk", 2);
>   }
>  
> @@ -549,11 +551,11 @@ sub give_gentoo_hints()
>   "rsvg-convert"  => "gnome-base/librsvg",
>   );
>  
> - check_missing_file("/usr/share/fonts/dejavu/DejaVuSans.ttf",
> + check_missing_file(["/usr/share/fonts/dejavu/DejaVuSans.ttf"],
>  "media-fonts/dejavu", 2) if ($pdf);
>  
>   if ($pdf) {
> - 
> check_missing_file("/usr/share/fonts/noto-cjk/NotoSansCJKsc-Regular.otf",
> + 
> check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJKsc-Regular.otf"],
>  "media-fonts/noto-cjk", 2);
>   }
>  



Thanks,
Mauro

Re: [PATCH v2 2/2] scripts/sphinx-pre-install: Add a new path for the debian package "fonts-noto-cjk"

[Mauro Carvalho Chehab]

Em Wed,  2 Oct 2019 15:35:42 +0200
Jeremy MAURO  escreveu:

> The latest debian version "bullseye/sid" has changed the path of the file
> "notoserifcjk-regular.ttc", with the previous change and this change we
> keep the backward compatibility and add the latest debian version
> 
> Signed-off-by: Jeremy MAURO 

Reviewed-by: Mauro Carvalho Chehab 

> ---
> Changes in V2:
> - Align all lines
> 
>  scripts/sphinx-pre-install | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
> index b5077ae63a4b..1f9285274587 100755
> --- a/scripts/sphinx-pre-install
> +++ b/scripts/sphinx-pre-install
> @@ -348,7 +348,8 @@ sub give_debian_hints()
>   
> check_missing_file(["/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf"],
>  "fonts-dejavu", 2);
>  
> - 
> check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc"],
> + 
> check_missing_file(["/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc",
> +
> "/usr/share/fonts/opentype/noto/NotoSerifCJK-Regular.ttc"],
>  "fonts-noto-cjk", 2);
>   }
>  



Thanks,
Mauro

Re: [PATCH 2/3] bindings: rename links to mason USB2/USB3 DT files

[Rob Herring]

On Tue, 24 Sep 2019 10:01:29 -0300, Mauro Carvalho Chehab wrote:
> Those files got renamed, but another DT file still points to the older
> places.
> 
> Fixes: 87a55485f2fc ("dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to 
> yaml")
> Fixes: da86d286cce8 ("dt-bindings: phy: meson-g12a-usb2-phy: convert to yaml")
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/devicetree/bindings/usb/amlogic,dwc3.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring 

Re: [PATCH 3/3] dt-bindings: iio: Add ltc2947 documentation

[Rob Herring]

On Tue, Sep 24, 2019 at 02:49:45PM +0200, Nuno Sá wrote:
> Document the LTC2947 device devicetree bindings.
> 
> Signed-off-by: Nuno Sá 
> ---
>  .../bindings/hwmon/adi,ltc2947.yaml   | 101 ++
>  MAINTAINERS   |   1 +
>  2 files changed, 102 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml 
> b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
> new file mode 100644
> index ..2ea0187421d4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
> @@ -0,0 +1,101 @@

Missing license. Please make new bindings (GPL-2.0-only OR BSD-2-Clause)

> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/bindings/hwmon/adi,ltc2947.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices LTC2947 high precision power and energy monitor
> +
> +maintainers:
> +  - Nuno Sá 
> +
> +description: |
> +  Analog Devices LTC2947 high precision power and energy monitor over SPI or 
> I2C.
> +
> +  
> https://www.analog.com/media/en/technical-documentation/data-sheets/LTC2947.pdf
> +
> +properties:
> +  compatible:
> +enum:
> +  - adi,ltc2947
> +
> +  reg:
> +maxItems: 1
> +
> +  clocks:
> +description:
> +  The LTC2947 uses either a trimmed internal oscillator or an external 
> clock
> +  as the time base for determining the integration period to represent 
> time,
> +  charge and energy. When an external clock is used, this property must 
> be
> +  set accordingly.
> +maxItems: 1
> +
> +  adi,accumulator-ctl-pol:
> +description:
> +  This property controls the polarity of current that is accumulated to
> +  calculate charge and energy so that, they can be only accumulated for
> +  positive current for example. Since there are two sets of registers for
> +  the accumulated values, this entry can also have two items which sets
> +  energy1/charge1 and energy2/charger2 respectively. Check table 12 of 
> the
> +  datasheet for more information on the supported options.
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/uint32-array
> +  - enum: [0, 1, 2, 3]
> +  - minItems: 2
> +  - maxItems: 2
> +default: [0, 0]

This should be:

allOf:
  - $ref: ...
items:
  enum: [0, 1, 2, 3]
  default: 0
minItems: 2
maxItems: 2

> +
> +  adi,accumulation-deadband-microamp:
> +description:
> +  This property controls the Accumulation Dead band which allows to set 
> the
> +  level of current below which no accumulation takes place.
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/uint32
> +  - maximum: 255

maximum should be at same indent as allOf. Or default should be at the 
same level as maximum (under a single '-' list entry).

> +default: 0
> +
> +  adi,gpio-out-pol:
> +description:
> +  This property controls the GPIO polarity. Setting it to one makes the 
> GPIO
> +  active high, setting it to zero makets it active low. When this 
> property
> +  is present, the GPIO is automatically configured as output and set to
> +  control a fan as a function of measured temperature.
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/uint32
> +  - enum: [0, 1]
> +default: 0

Same here.

> +
> +  adi,gpio-in-accum:
> +description:
> +  When set, this property sets the GPIO as input. It is then used to 
> control
> +  the accumulation of charge, energy and time. This function can be
> +  enabled/configured separately for each of the two sets of accumulation
> +  registers. Check table 13 of the datasheet for more information on the
> +  supported options. This property cannot be used together with
> +  adi,gpio-out-pol.
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/uint32-array
> +  - enum: [0, 1, 2]
> +  - minItems: 2
> +  - maxItems: 2
> +default: [0, 0]

Similar here.

> +
> +required:
> +  - compatible
> +  - reg
> +
> +
> +examples:
> +  - |
> +spi0 {

Just 'spi'

> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   ltc2947_spi: ltc2947@0 {
> +   compatible = "adi,ltc2947";
> +   reg = <0>;
> +   /* accumulation takes place always for energ1/charge1. */
> +   /* accumulation only on positive current for 
> energy2/charge2. */
> +   adi,accumulator-ctl-pol = <0 1>;
> +   };
> +};
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 889f38c1c930..820bdde2044b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9505,6 +9505,7 @@ F:  drivers/hwmon/ltc2947-core.c
>  F:   drivers/hwmon/ltc2947-spi.c
>  F:   drivers/hwmon/ltc2947-i2c.c
>  F:   drivers/hwmon/ltc2947.h
> +F:   Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
>  
>  LTC

Re: [PATCH 1/3] docs: fix some broken references

[Rob Herring]

On Tue, 24 Sep 2019 10:01:28 -0300, Mauro Carvalho Chehab wrote:
> There are a number of documentation files that got moved or
> renamed. update their references.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/devicetree/bindings/cpu/cpu-topology.txt| 2 +-
>  Documentation/devicetree/bindings/timer/ingenic,tcu.txt   | 2 +-
>  Documentation/driver-api/gpio/driver.rst  | 2 +-
>  Documentation/hwmon/inspur-ipsps1.rst | 2 +-
>  Documentation/mips/ingenic-tcu.rst| 2 +-
>  Documentation/networking/device_drivers/mellanox/mlx5.rst | 2 +-
>  MAINTAINERS   | 2 +-
>  drivers/net/ethernet/faraday/ftgmac100.c  | 2 +-
>  drivers/net/ethernet/pensando/ionic/ionic_if.h| 4 ++--
>  fs/cifs/cifsfs.c  | 2 +-
>  10 files changed, 11 insertions(+), 11 deletions(-)
> 

Acked-by: Rob Herring 

[PATCH] Documentation: gpio: driver: Format code blocks properly

[Jonathan Neuschäfer]

This fixes a lot of Sphinx warnings, and makes the code blocks look nice
in HTML.

Signed-off-by: Jonathan Neuschäfer 
---
 Documentation/driver-api/gpio/driver.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/driver-api/gpio/driver.rst 
b/Documentation/driver-api/gpio/driver.rst
index 3fdb32422f8a..18dca55eddfd 100644
--- a/Documentation/driver-api/gpio/driver.rst
+++ b/Documentation/driver-api/gpio/driver.rst
@@ -415,6 +415,8 @@ If you do this, the additional irq_chip will be set up by 
gpiolib at the
 same time as setting up the rest of the GPIO functionality. The following
 is a typical example of a cascaded interrupt handler using gpio_irq_chip:

+.. code-block:: c
+
   /* Typical state container with dynamic irqchip */
   struct my_gpio {
   struct gpio_chip gc;
@@ -450,6 +452,8 @@ is a typical example of a cascaded interrupt handler using 
gpio_irq_chip:
 The helper support using hierarchical interrupt controllers as well.
 In this case the typical set-up will look like this:

+.. code-block:: c
+
   /* Typical state container with dynamic irqchip */
   struct my_gpio {
   struct gpio_chip gc;
--
2.20.1

Re: [PATCH 3/3] dt-bindings: iio: Add ltc2947 documentation

[Sa, Nuno]

On Wed, 2019-10-02 at 09:19 -0500, Rob Herring wrote:
> 
> On Tue, Sep 24, 2019 at 02:49:45PM +0200, Nuno Sá wrote:
> > Document the LTC2947 device devicetree bindings.
> > 
> > Signed-off-by: Nuno Sá 
> > ---
> >  .../bindings/hwmon/adi,ltc2947.yaml   | 101
> > ++
> >  MAINTAINERS   |   1 +
> >  2 files changed, 102 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
> > b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
> > new file mode 100644
> > index ..2ea0187421d4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
> > @@ -0,0 +1,101 @@
> 
> Missing license. Please make new bindings (GPL-2.0-only OR BSD-2-
> Clause)

ack.

> > +%YAML 1.2
> > +---
> > +$id: 
> > http://devicetree.org/schemas/bindings/hwmon/adi,ltc2947.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Analog Devices LTC2947 high precision power and energy
> > monitor
> > +
> > +maintainers:
> > +  - Nuno Sá 
> > +
> > +description: |
> > +  Analog Devices LTC2947 high precision power and energy monitor
> > over SPI or I2C.
> > +
> > +  
> > https://www.analog.com/media/en/technical-documentation/data-sheets/LTC2947.pdf
> > +
> > +properties:
> > +  compatible:
> > +enum:
> > +  - adi,ltc2947
> > +
> > +  reg:
> > +maxItems: 1
> > +
> > +  clocks:
> > +description:
> > +  The LTC2947 uses either a trimmed internal oscillator or an
> > external clock
> > +  as the time base for determining the integration period to
> > represent time,
> > +  charge and energy. When an external clock is used, this
> > property must be
> > +  set accordingly.
> > +maxItems: 1
> > +
> > +  adi,accumulator-ctl-pol:
> > +description:
> > +  This property controls the polarity of current that is
> > accumulated to
> > +  calculate charge and energy so that, they can be only
> > accumulated for
> > +  positive current for example. Since there are two sets of
> > registers for
> > +  the accumulated values, this entry can also have two items
> > which sets
> > +  energy1/charge1 and energy2/charger2 respectively. Check
> > table 12 of the
> > +  datasheet for more information on the supported options.
> > +allOf:
> > +  - $ref: /schemas/types.yaml#/definitions/uint32-array
> > +  - enum: [0, 1, 2, 3]
> > +  - minItems: 2
> > +  - maxItems: 2
> > +default: [0, 0]
> 
> This should be:
> 
> allOf:
>   - $ref: ...
> items:
>   enum: [0, 1, 2, 3]
>   default: 0
> minItems: 2
> maxItems: 2

I was expecting this already. When upstreaming another device, I
realized some errors with `make dt_binding_check` when evaluating the
example. Just for my understanding, is this also incorrect?

allOf:
  - $ref: /schemas/types.yaml#/definitions/uint32-array
  - minItems: 2
maxItems: 2
items:
  enum: [0, 1, 2, 3]
default: 0

I used a similar pattern in another device that is also waiting for
review :).
> > +
> > +  adi,accumulation-deadband-microamp:
> > +description:
> > +  This property controls the Accumulation Dead band which
> > allows to set the
> > +  level of current below which no accumulation takes place.
> > +allOf:
> > +  - $ref: /schemas/types.yaml#/definitions/uint32
> > +  - maximum: 255
> 
> maximum should be at same indent as allOf. Or default should be at
> the 
> same level as maximum (under a single '-' list entry).

So it should be?

allOf:
  - $ref: /schemas/types.yaml#/definitions/uint32
  - maximum: 255
default: 0

> > +default: 0
> > +
> > +  adi,gpio-out-pol:
> > +description:
> > +  This property controls the GPIO polarity. Setting it to one
> > makes the GPIO
> > +  active high, setting it to zero makets it active low. When
> > this property
> > +  is present, the GPIO is automatically configured as output
> > and set to
> > +  control a fan as a function of measured temperature.
> > +allOf:
> > +  - $ref: /schemas/types.yaml#/definitions/uint32
> > +  - enum: [0, 1]
> > +default: 0
> 
> Same here.
> 
> > +
> > +  adi,gpio-in-accum:
> > +description:
> > +  When set, this property sets the GPIO as input. It is then
> > used to control
> > +  the accumulation of charge, energy and time. This function
> > can be
> > +  enabled/configured separately for each of the two sets of
> > accumulation
> > +  registers. Check table 13 of the datasheet for more
> > information on the
> > +  supported options. This property cannot be used together
> > with
> > +  adi,gpio-out-pol.
> > +allOf:
> > +  - $ref: /schemas/types.yaml#/definitions/uint32-array
> > +  - enum: [0, 1, 2]
> > +  - minItems: 2
> > +  - maxItems: 2
> > +default: [0, 0]
> 
> Similar here.
> 
> > +
> > +required

[PATCH] Documentation: networking: device drivers: Remove stray asterisks

[Jonathan Neuschäfer]

These asterisks were once references to a line that said:
  "* Other names and brands may be claimed as the property of others."
But now, they serve no purpose; they can only irritate the reader.

Fixes: de3edab4276c ("e1000: update README for e1000")
Fixes: a3fb65680f65 ("e100.txt: Cleanup license info in kernel doc")
Fixes: da8c01c4502a ("e1000e.txt: Add e1000e documentation")
Fixes: f12a84a9f650 ("Documentation: fm10k: Add kernel documentation")
Fixes: b55c52b1938c ("igb.txt: Add igb documentation")
Fixes: c4e9b56e2442 ("igbvf.txt: Add igbvf Documentation")
Fixes: d7064f4c192c ("Documentation/networking/: Update Intel wired LAN driver 
documentation")
Fixes: c4b8c01112a1 ("ixgbevf.txt: Update ixgbevf documentation")
Fixes: 1e06edcc2f22 ("Documentation: i40e: Prepare documentation for RST 
conversion")
Fixes: 105bf2fe6b32 ("i40evf: add driver to kernel build system")
Fixes: 1fae869bcf3d ("Documentation: ice: Prepare documentation for RST 
conversion")
Fixes: df69ba43217d ("ionic: Add basic framework for IONIC Network device 
driver")
Signed-off-by: Jonathan Neuschäfer 
---
 .../networking/device_drivers/intel/e100.rst   | 14 +++---
 .../networking/device_drivers/intel/e1000.rst  | 12 ++--
 .../networking/device_drivers/intel/e1000e.rst | 14 +++---
 .../networking/device_drivers/intel/fm10k.rst  | 10 +-
 .../networking/device_drivers/intel/i40e.rst   |  8 
 .../networking/device_drivers/intel/iavf.rst   |  8 
 .../networking/device_drivers/intel/ice.rst|  6 +++---
 .../networking/device_drivers/intel/igb.rst| 12 ++--
 .../networking/device_drivers/intel/igbvf.rst  |  6 +++---
 .../networking/device_drivers/intel/ixgbe.rst  | 10 +-
 .../networking/device_drivers/intel/ixgbevf.rst|  6 +++---
 .../networking/device_drivers/pensando/ionic.rst   |  6 +++---
 12 files changed, 56 insertions(+), 56 deletions(-)

diff --git a/Documentation/networking/device_drivers/intel/e100.rst 
b/Documentation/networking/device_drivers/intel/e100.rst
index 2b9f4887beda..caf023cc88de 100644
--- a/Documentation/networking/device_drivers/intel/e100.rst
+++ b/Documentation/networking/device_drivers/intel/e100.rst
@@ -1,8 +1,8 @@
 .. SPDX-License-Identifier: GPL-2.0+
 
-==
-Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters
-==
+=
+Linux Base Driver for the Intel(R) PRO/100 Family of Adapters
+=
 
 June 1, 2018
 
@@ -21,7 +21,7 @@ Contents
 In This Release
 ===
 
-This file describes the Linux* Base Driver for the Intel(R) PRO/100 Family of
+This file describes the Linux Base Driver for the Intel(R) PRO/100 Family of
 Adapters. This driver includes support for Itanium(R)2-based systems.
 
 For questions related to hardware requirements, refer to the documentation
@@ -138,9 +138,9 @@ version 1.6 or later is required for this functionality.
 The latest release of ethtool can be found from
 https://www.kernel.org/pub/software/network/ethtool/
 
-Enabling Wake on LAN* (WoL)

-WoL is provided through the ethtool* utility.  For instructions on
+Enabling Wake on LAN (WoL)
+--
+WoL is provided through the ethtool utility.  For instructions on
 enabling WoL with ethtool, refer to the ethtool man page.  WoL will be
 enabled on the system during the next shut down or reboot.  For this
 driver version, in order to enable WoL, the e100 driver must be loaded
diff --git a/Documentation/networking/device_drivers/intel/e1000.rst 
b/Documentation/networking/device_drivers/intel/e1000.rst
index 956560b6e745..4aaae0f7d6ba 100644
--- a/Documentation/networking/device_drivers/intel/e1000.rst
+++ b/Documentation/networking/device_drivers/intel/e1000.rst
@@ -1,8 +1,8 @@
 .. SPDX-License-Identifier: GPL-2.0+
 
-===
-Linux* Base Driver for Intel(R) Ethernet Network Connection
-===
+==
+Linux Base Driver for Intel(R) Ethernet Network Connection
+==
 
 Intel Gigabit Linux driver.
 Copyright(c) 1999 - 2013 Intel Corporation.
@@ -438,10 +438,10 @@ ethtool
   The latest release of ethtool can be found from
   https://www.kernel.org/pub/software/network/ethtool/
 
-Enabling Wake on LAN* (WoL)

+Enabling Wake on LAN (WoL)
+--
 
-  WoL is configured through the ethtool* utility.
+  WoL is configured through the ethtool utility.
 
   WoL will be enabled on the system during the next shut down or reboot.
   For this driver version, in order to enable WoL, the e1000 driver 

[PATCH] Documentation: update about adding syscalls

[Christian Brauner]

Add additional information on how to ensure that syscalls with structure
arguments are extensible and add a section about naming conventions to
follow when adding revised versions of already existing syscalls.

Co-Developed-by: Aleksa Sarai 
Signed-off-by: Aleksa Sarai 
Signed-off-by: Christian Brauner 
---
 Documentation/process/adding-syscalls.rst | 82 +++
 1 file changed, 70 insertions(+), 12 deletions(-)

diff --git a/Documentation/process/adding-syscalls.rst 
b/Documentation/process/adding-syscalls.rst
index 1c3a840d06b9..93e0221fbb9a 100644
--- a/Documentation/process/adding-syscalls.rst
+++ b/Documentation/process/adding-syscalls.rst
@@ -79,7 +79,7 @@ flags, and reject the system call (with ``EINVAL``) if it 
does::
 For more sophisticated system calls that involve a larger number of arguments,
 it's preferred to encapsulate the majority of the arguments into a structure
 that is passed in by pointer.  Such a structure can cope with future extension
-by including a size argument in the structure::
+by either including a size argument in the structure::
 
 struct xyzzy_params {
 u32 size; /* userspace sets p->size = sizeof(struct xyzzy_params) */
@@ -87,20 +87,56 @@ by including a size argument in the structure::
 u64 param_2;
 u64 param_3;
 };
+int sys_xyzzy(struct xyzzy_params __user *uarg);
+/* in case of -E2BIG, p->size is set to the in-kernel size and thus all
+   extensions after that offset are unsupported. */
 
-As long as any subsequently added field, say ``param_4``, is designed so that a
-zero value gives the previous behaviour, then this allows both directions of
-version mismatch:
+or by including a separate argument that specifies the size::
 
- - To cope with a later userspace program calling an older kernel, the kernel
-   code should check that any memory beyond the size of the structure that it
-   expects is zero (effectively checking that ``param_4 == 0``).
- - To cope with an older userspace program calling a newer kernel, the kernel
-   code can zero-extend a smaller instance of the structure (effectively
-   setting ``param_4 = 0``).
+struct xyzzy_params {
+u32 param_1;
+u64 param_2;
+u64 param_3;
+};
+/* userspace sets @usize = sizeof(struct xyzzy_params) */
+int sys_xyzzy(struct xyzzy_params __user *uarg, size_t usize);
+/* in case of -E2BIG, userspace has to attempt smaller @usize values
+   to figure out which extensions are unsupported. */
+
+Which model you choose to use is down to personal taste. However, please only
+pick one (for a counter-example, see :manpage:`sched_getattr(2)`).
+
+Then, any extensions can be implemented by appending fields to the structure.
+However, all new fields must be designed such that their zero value results in
+identical behaviour to the pre-extension syscall. This allows for compatibility
+between different-vintage kernels and userspace, no matter which is newer:
+
+ - If the userspace is newer, then the older kernel can check whether the
+   fields it doesn't understand are zero-valued. If they are, then it can
+   safely ignore them (since any future extensions will be backwards-compatible
+   as described above). If they aren't, then the kernel doesn't support the
+   feature and can give an error (``-E2BIG`` is traditional).
+
+ - If the userspace is older, then the kernel can treat all extensions that
+   userspace is unaware of as having their zero-value (and effectively
+   zero-extend the userspace structure when copying it for in-kernel usage).
 
-See :manpage:`perf_event_open(2)` and the ``perf_copy_attr()`` function (in
-``kernel/events/core.c``) for an example of this approach.
+ - If they're the same version, just use the structure as-is.
+
+As with the simpler flag-only syscalls, you must always check that any unknown
+values for flag-like parameters in the passed structure are zeroed.
+
+It is also critical to ensure your syscall handles larger-sized arguments from
+the outset, otherwise userspace will have to do additional (fairly pointless)
+fallbacks for some old kernels. An example where this mistake was made is
+:manpage:`rt_sigprocmask(2)` (where any unknown-sized arguments are
+unconditionally rejected).
+
+To help implement this correctly, there is a helper function
+``copy_struct_from_user()`` which handles the compatibility requirements for
+you. For examples using this helper, see :manpage:`perf_event_open(2)` (which
+uses the embedded-size model) and :manpage:`clone3(2)` (which uses the
+separate-argument model).
 
 
 Designing the API: Other Considerations
@@ -173,6 +209,28 @@ registers.  (This concern does not apply if the arguments 
are part of a
 structure that's passed in by pointer.)
 
 
+Designing the API: Revisions of syscalls
+---
+
+Syscalls that were not designed to be extensible or syscalls that use a flag
+argument for extensions running out of b

[PATCH] docs: it_IT: maintainer-pgp-guide: Fix reference to "Nitrokey Pro 2"

[Jonathan Neuschäfer]

This fixes the following Sphinx warning:

Documentation/translations/it_IT/process/maintainer-pgp-guide.rst:458:
  WARNING: Unknown target name: "nitrokey pro".

Signed-off-by: Jonathan Neuschäfer 
---
 .../translations/it_IT/process/maintainer-pgp-guide.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst 
b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst
index 118fb4153e8f..f3c8e8d377ee 100644
--- a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst
+++ b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst
@@ -455,7 +455,7 @@ soluzioni disponibili:
   `GnuK`_ della FSIJ. Questo è uno dei pochi dispositivi a supportare le chiavi
   ECC ED25519, ma offre meno funzionalità di sicurezza (come la resistenza
   alla manomissione o alcuni attacchi ad un canale laterale).
-- `Nitrokey Pro`_: è simile alla Nitrokey Start, ma è più resistente alla
+- `Nitrokey Pro 2`_: è simile alla Nitrokey Start, ma è più resistente alla
   manomissione e offre più funzionalità di sicurezza. La Pro 2 supporta la
   crittografia ECC (NISTP).
 - `Yubikey 5`_: l'hardware e il software sono proprietari, ma è più economica
--
2.20.1

Re: [PATCH] Documentation: networking: device drivers: Remove stray asterisks

[Shannon Nelson]

On 10/2/19 8:09 AM, Jonathan Neuschäfer wrote:

These asterisks were once references to a line that said:
   "* Other names and brands may be claimed as the property of others."
But now, they serve no purpose; they can only irritate the reader.


[...]

Fixes: df69ba43217d ("ionic: Add basic framework for IONIC Network device 
driver")


Acked-by: Shannon Nelson 

Re: [PATCH v2 0/2] docs: Programmatically render MAINTAINERS into ReST

[Jonathan Corbet]

On Tue,  1 Oct 2019 11:25:30 -0700
Kees Cook  wrote:

> v1: https://lore.kernel.org/lkml/20190924230208.12414-1-keesc...@chromium.org
> 
> v2: fix python2 utf-8 issue thanks to Jonathan Corbet
> 
> 
> Commit log from Patch 2 repeated here for cover letter:
> 
> In order to have the MAINTAINERS file visible in the rendered ReST
> output, this makes some small changes to the existing MAINTAINERS file
> to allow for better machine processing, and adds a new Sphinx directive
> "maintainers-include" to perform the rendering.

OK, I've applied this.  Some notes, none of which really require any
action...

It adds a new warning:

  /stuff/k/git/kernel/MAINTAINERS:40416: WARNING: unknown document: 
../misc-devices/xilinx_sdfec   

I wonder if it's worth checking to be sure that documents referenced in
MAINTAINERS actually exist.  OTOH, things as they are generate a warning,
which is what we want anyway.

I did various experiments corrupting the MAINTAINERS file and got some
fairly unphotogenic results.  Again, though, I'm not sure that adding a
bunch of code to generate warnings is really worth the trouble.

The resulting HTML file is 3.4MB and definitely makes my browser sweat when
loading it :)

It adds about 20 seconds to a full "make htmldocs" build, which takes just
over 3 minutes on the system in question.  So a 10% overhead, essentially.

All told, it does what it's expected to do.  Thanks for doing this.

jon

[PATCH v2 0/5] drivers: add a new variant of devm_platform_ioremap_resource()

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

The new devm_platform_ioremap_resource() helper has now been widely
adopted and used in many drivers. Users of the write-combined ioremap()
variants could benefit from the same code shrinkage. This series provides
a write-combined version of devm_platform_ioremap_resource() and uses it in a
relevant driver with the assumption that - just like was the case
previously - a coccinelle script will be developed to ease the transition
for others.

v1 -> v2:
- dropped everything related to nocache ioremap as this is going away

Bartosz Golaszewski (5):
  Documentation: devres: add missing entry for
devm_platform_ioremap_resource()
  lib: devres: prepare devm_ioremap_resource() for more variants
  lib: devres: provide devm_ioremap_resource_wc()
  drivers: platform: provide devm_platform_ioremap_resource_wc()
  misc: sram: use devm_platform_ioremap_resource_wc()

 .../driver-api/driver-model/devres.rst|  3 +
 drivers/base/platform.c   | 27 ++--
 drivers/misc/sram.c   | 28 +++--
 include/linux/device.h|  2 +
 include/linux/platform_device.h   |  3 +
 lib/devres.c  | 62 +--
 6 files changed, 80 insertions(+), 45 deletions(-)

-- 
2.23.0

[PATCH v2 1/5] Documentation: devres: add missing entry for devm_platform_ioremap_resource()

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

devm_platform_ioremap_resource() should be documented in devres.rst.
Add the missing entry.

Signed-off-by: Bartosz Golaszewski 
---
 Documentation/driver-api/driver-model/devres.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/driver-api/driver-model/devres.rst 
b/Documentation/driver-api/driver-model/devres.rst
index a100bef54952..8e3087662daf 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -316,6 +316,7 @@ IOMAP
   devm_ioremap_nocache()
   devm_ioremap_wc()
   devm_ioremap_resource() : checks resource, requests memory region, ioremaps
+  devm_platform_ioremap_resource() : calls devm_ioremap_resource() for 
platform device
   devm_iounmap()
   pcim_iomap()
   pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
-- 
2.23.0

[PATCH v2 3/5] lib: devres: provide devm_ioremap_resource_wc()

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Provide a variant of devm_ioremap_resource() for write-combined ioremap.

Signed-off-by: Bartosz Golaszewski 
---
 Documentation/driver-api/driver-model/devres.rst |  1 +
 include/linux/device.h   |  2 ++
 lib/devres.c | 15 +++
 3 files changed, 18 insertions(+)

diff --git a/Documentation/driver-api/driver-model/devres.rst 
b/Documentation/driver-api/driver-model/devres.rst
index 8e3087662daf..e605bb9df6e1 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -316,6 +316,7 @@ IOMAP
   devm_ioremap_nocache()
   devm_ioremap_wc()
   devm_ioremap_resource() : checks resource, requests memory region, ioremaps
+  devm_ioremap_resource_wc()
   devm_platform_ioremap_resource() : calls devm_ioremap_resource() for 
platform device
   devm_iounmap()
   pcim_iomap()
diff --git a/include/linux/device.h b/include/linux/device.h
index 297239a08bb7..1f4aaf2d4b2a 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -946,6 +946,8 @@ extern void devm_free_pages(struct device *dev, unsigned 
long addr);
 
 void __iomem *devm_ioremap_resource(struct device *dev,
const struct resource *res);
+void __iomem *devm_ioremap_resource_wc(struct device *dev,
+  const struct resource *res);
 
 void __iomem *devm_of_iomap(struct device *dev,
struct device_node *node, int index,
diff --git a/lib/devres.c b/lib/devres.c
index a14c727128c1..97fb44e5b4d6 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -169,6 +169,21 @@ void __iomem *devm_ioremap_resource(struct device *dev,
 }
 EXPORT_SYMBOL(devm_ioremap_resource);
 
+/**
+ * devm_ioremap_resource_wc() - write-combined variant of
+ * devm_ioremap_resource()
+ * @dev: generic device to handle the resource for
+ * @res: resource to be handled
+ *
+ * Returns a pointer to the remapped memory or an ERR_PTR() encoded error code
+ * on failure. Usage example:
+ */
+void __iomem *devm_ioremap_resource_wc(struct device *dev,
+  const struct resource *res)
+{
+   return __devm_ioremap_resource(dev, res, DEVM_IOREMAP_WC);
+}
+
 /*
  * devm_of_iomap - Requests a resource and maps the memory mapped IO
  *for a given device_node managed by a given device
-- 
2.23.0

[PATCH v2 5/5] misc: sram: use devm_platform_ioremap_resource_wc()

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Use the new devm_platform_ioremap_resource_wc() helper instead of
devm_ioremap_wc() combinded with a call to platform_get_resource().
Also use devm_platform_ioremap_resource() where applicable.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/misc/sram.c | 28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index f30448bf3a63..6c1a23cb3e8c 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -340,8 +340,6 @@ static const struct of_device_id sram_dt_ids[] = {
 static int sram_probe(struct platform_device *pdev)
 {
struct sram_dev *sram;
-   struct resource *res;
-   size_t size;
int ret;
int (*init_func)(void);
 
@@ -351,25 +349,14 @@ static int sram_probe(struct platform_device *pdev)
 
sram->dev = &pdev->dev;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   dev_err(sram->dev, "found no memory resource\n");
-   return -EINVAL;
-   }
-
-   size = resource_size(res);
-
-   if (!devm_request_mem_region(sram->dev, res->start, size, pdev->name)) {
-   dev_err(sram->dev, "could not request region for resource\n");
-   return -EBUSY;
-   }
-
if (of_property_read_bool(pdev->dev.of_node, "no-memory-wc"))
-   sram->virt_base = devm_ioremap(sram->dev, res->start, size);
+   sram->virt_base = devm_platform_ioremap_resource(pdev, 0);
else
-   sram->virt_base = devm_ioremap_wc(sram->dev, res->start, size);
-   if (!sram->virt_base)
-   return -ENOMEM;
+   sram->virt_base = devm_platform_ioremap_resource_wc(pdev, 0);
+   if (IS_ERR(sram->virt_base)) {
+   dev_err(&pdev->dev, "could not map SRAM registers\n");
+   return PTR_ERR(sram->virt_base);
+   }
 
sram->pool = devm_gen_pool_create(sram->dev, ilog2(SRAM_GRANULARITY),
  NUMA_NO_NODE, NULL);
@@ -382,7 +369,8 @@ static int sram_probe(struct platform_device *pdev)
else
clk_prepare_enable(sram->clk);
 
-   ret = sram_reserve_regions(sram, res);
+   ret = sram_reserve_regions(sram,
+   platform_get_resource(pdev, IORESOURCE_MEM, 0));
if (ret)
goto err_disable_clk;
 
-- 
2.23.0

[PATCH v2 4/5] drivers: platform: provide devm_platform_ioremap_resource_wc()

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Provide a write-combined variant of devm_platform_ioremap_resource().

While at it: in order not to duplicate code - pass the resource
retrieved by platform_get_resource() directly to the appropriate
devm_ioremap_resource() variant.

Signed-off-by: Bartosz Golaszewski 
---
 .../driver-api/driver-model/devres.rst|  1 +
 drivers/base/platform.c   | 27 +++
 include/linux/platform_device.h   |  3 +++
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/Documentation/driver-api/driver-model/devres.rst 
b/Documentation/driver-api/driver-model/devres.rst
index e605bb9df6e1..480b78ca3871 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -318,6 +318,7 @@ IOMAP
   devm_ioremap_resource() : checks resource, requests memory region, ioremaps
   devm_ioremap_resource_wc()
   devm_platform_ioremap_resource() : calls devm_ioremap_resource() for 
platform device
+  devm_platform_ioremap_resource_wc()
   devm_iounmap()
   pcim_iomap()
   pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b6c6c7d97d5b..8fdf3eb23bda 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -60,6 +60,7 @@ struct resource *platform_get_resource(struct platform_device 
*dev,
 }
 EXPORT_SYMBOL_GPL(platform_get_resource);
 
+#ifdef CONFIG_HAS_IOMEM
 /**
  * devm_platform_ioremap_resource - call devm_ioremap_resource() for a platform
  * device
@@ -68,16 +69,32 @@ EXPORT_SYMBOL_GPL(platform_get_resource);
  *resource management
  * @index: resource index
  */
-#ifdef CONFIG_HAS_IOMEM
 void __iomem *devm_platform_ioremap_resource(struct platform_device *pdev,
 unsigned int index)
 {
-   struct resource *res;
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, index);
-   return devm_ioremap_resource(&pdev->dev, res);
+   return devm_ioremap_resource(&pdev->dev,
+platform_get_resource(pdev,
+  IORESOURCE_MEM,
+  index));
 }
 EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource);
+
+/**
+ * devm_platform_ioremap_resource_wc - write-combined variant of
+ * devm_platform_ioremap_resource()
+ *
+ * @pdev: platform device to use both for memory resource lookup as well as
+ *resource management
+ * @index: resource index
+ */
+void __iomem *devm_platform_ioremap_resource_wc(struct platform_device *pdev,
+   unsigned int index)
+{
+   return devm_ioremap_resource_wc(&pdev->dev,
+   platform_get_resource(pdev,
+ IORESOURCE_MEM,
+ index));
+}
 #endif /* CONFIG_HAS_IOMEM */
 
 static int __platform_get_irq(struct platform_device *dev, unsigned int num)
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 1b5cec067533..83930790c701 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -57,6 +57,9 @@ platform_find_device_by_driver(struct device *start,
 extern void __iomem *
 devm_platform_ioremap_resource(struct platform_device *pdev,
   unsigned int index);
+extern void __iomem *
+devm_platform_ioremap_resource_wc(struct platform_device *pdev,
+ unsigned int index);
 extern int platform_get_irq(struct platform_device *, unsigned int);
 extern int platform_get_irq_optional(struct platform_device *, unsigned int);
 extern int platform_irq_count(struct platform_device *);
-- 
2.23.0

[PATCH v2 2/5] lib: devres: prepare devm_ioremap_resource() for more variants

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

We want to add the write-combined variant of devm_ioremap_resource().
Let's first implement __devm_ioremap_resource() which takes
an additional argument type. The types are the same as for
__devm_ioremap(). The existing devm_ioremap_resource() now simply
calls __devm_ioremap_resource() with regular DEVM_IOREMAP type.

Signed-off-by: Bartosz Golaszewski 
---
 lib/devres.c | 47 +++
 1 file changed, 27 insertions(+), 20 deletions(-)

diff --git a/lib/devres.c b/lib/devres.c
index 6a0e9bd6524a..a14c727128c1 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -114,25 +114,9 @@ void devm_iounmap(struct device *dev, void __iomem *addr)
 }
 EXPORT_SYMBOL(devm_iounmap);
 
-/**
- * devm_ioremap_resource() - check, request region, and ioremap resource
- * @dev: generic device to handle the resource for
- * @res: resource to be handled
- *
- * Checks that a resource is a valid memory region, requests the memory
- * region and ioremaps it. All operations are managed and will be undone
- * on driver detach.
- *
- * Returns a pointer to the remapped memory or an ERR_PTR() encoded error code
- * on failure. Usage example:
- *
- * res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- * base = devm_ioremap_resource(&pdev->dev, res);
- * if (IS_ERR(base))
- * return PTR_ERR(base);
- */
-void __iomem *devm_ioremap_resource(struct device *dev,
-   const struct resource *res)
+static void __iomem *
+__devm_ioremap_resource(struct device *dev, const struct resource *res,
+   enum devm_ioremap_type type)
 {
resource_size_t size;
void __iomem *dest_ptr;
@@ -151,7 +135,7 @@ void __iomem *devm_ioremap_resource(struct device *dev,
return IOMEM_ERR_PTR(-EBUSY);
}
 
-   dest_ptr = devm_ioremap(dev, res->start, size);
+   dest_ptr = __devm_ioremap(dev, res->start, size, type);
if (!dest_ptr) {
dev_err(dev, "ioremap failed for resource %pR\n", res);
devm_release_mem_region(dev, res->start, size);
@@ -160,6 +144,29 @@ void __iomem *devm_ioremap_resource(struct device *dev,
 
return dest_ptr;
 }
+
+/**
+ * devm_ioremap_resource() - check, request region, and ioremap resource
+ * @dev: generic device to handle the resource for
+ * @res: resource to be handled
+ *
+ * Checks that a resource is a valid memory region, requests the memory
+ * region and ioremaps it. All operations are managed and will be undone
+ * on driver detach.
+ *
+ * Returns a pointer to the remapped memory or an ERR_PTR() encoded error code
+ * on failure. Usage example:
+ *
+ * res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ * base = devm_ioremap_resource(&pdev->dev, res);
+ * if (IS_ERR(base))
+ * return PTR_ERR(base);
+ */
+void __iomem *devm_ioremap_resource(struct device *dev,
+   const struct resource *res)
+{
+   return __devm_ioremap_resource(dev, res, DEVM_IOREMAP);
+}
 EXPORT_SYMBOL(devm_ioremap_resource);
 
 /*
-- 
2.23.0

Re: [PATCH v2 0/2] docs: Programmatically render MAINTAINERS into ReST

[Kees Cook]

On Wed, Oct 02, 2019 at 10:25:35AM -0600, Jonathan Corbet wrote:
> On Tue,  1 Oct 2019 11:25:30 -0700
> Kees Cook  wrote:
> 
> > v1: 
> > https://lore.kernel.org/lkml/20190924230208.12414-1-keesc...@chromium.org
> > 
> > v2: fix python2 utf-8 issue thanks to Jonathan Corbet
> > 
> > 
> > Commit log from Patch 2 repeated here for cover letter:
> > 
> > In order to have the MAINTAINERS file visible in the rendered ReST
> > output, this makes some small changes to the existing MAINTAINERS file
> > to allow for better machine processing, and adds a new Sphinx directive
> > "maintainers-include" to perform the rendering.
> 
> OK, I've applied this.  Some notes, none of which really require any
> action...
> 
> It adds a new warning:
> 
>   /stuff/k/git/kernel/MAINTAINERS:40416: WARNING: unknown document: 
> ../misc-devices/xilinx_sdfec   
> 
> I wonder if it's worth checking to be sure that documents referenced in
> MAINTAINERS actually exist.  OTOH, things as they are generate a warning,
> which is what we want anyway.

Yup, I saw this when I was doing the work and already sent an email
last week about it but got no response:
https://lore.kernel.org/lkml/201909231450.4C6CF32@keescook/

I suppose I could literally just send the missing file instead?

> I did various experiments corrupting the MAINTAINERS file and got some
> fairly unphotogenic results.  Again, though, I'm not sure that adding a
> bunch of code to generate warnings is really worth the trouble.
> 
> The resulting HTML file is 3.4MB and definitely makes my browser sweat when
> loading it :)

Yes -- I think a big part of this is the amplification of the subsystem
links (they're in the navigation right-hand side too), but I think that
making them reachable externally was important so a maintainer can have
a stable URL to point to their MAINTAINTERS file entry.

> It adds about 20 seconds to a full "make htmldocs" build, which takes just
> over 3 minutes on the system in question.  So a 10% overhead, essentially.

Yup, it's a lot to parse, but it *seems* to be caching it correctly.

> All told, it does what it's expected to do.  Thanks for doing this.

Cool! Thanks for the help on it. :)

-- 
Kees Cook

[PATCH] docs: misc: xilinx_sdfec: Actually add documentation

[Kees Cook]

From: Derek Kiernan 

Add SD-FEC driver documentation.

Signed-off-by: Derek Kiernan 
Signed-off-by: Dragan Cvetic 
Link: 
https://lore.kernel.org/r/1560274185-264438-11-git-send-email-dragan.cve...@xilinx.com
[kees: extracted from v7 as it was missing in the commit for v8]
Signed-off-by: Kees Cook 
---
As mentioned[1], this file went missing and causes a warning in ReST
parsing, so I've extracted the patch and am sending it directly to Jon.
[1] https://lore.kernel.org/lkml/201909231450.4C6CF32@keescook/
---
 Documentation/misc-devices/xilinx_sdfec.rst | 291 
 1 file changed, 291 insertions(+)
 create mode 100644 Documentation/misc-devices/xilinx_sdfec.rst

diff --git a/Documentation/misc-devices/xilinx_sdfec.rst 
b/Documentation/misc-devices/xilinx_sdfec.rst
new file mode 100644
index ..87966e3aa5fe
--- /dev/null
+++ b/Documentation/misc-devices/xilinx_sdfec.rst
@@ -0,0 +1,291 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Xilinx SD-FEC Driver
+
+
+Overview
+
+
+This driver supports SD-FEC Integrated Block for Zynq |Ultrascale+ (TM)| 
RFSoCs.
+
+.. |Ultrascale+ (TM)| unicode:: Ultrascale+ U+2122
+   .. with trademark sign
+
+For a full description of SD-FEC core features, see the `SD-FEC Product Guide 
(PG256) 
`_
+
+This driver supports the following features:
+
+  - Retrieval of the Integrated Block configuration and status information
+  - Configuration of LDPC codes
+  - Configuration of Turbo decoding
+  - Monitoring errors
+
+Missing features, known issues, and limitations of the SD-FEC driver are as
+follows:
+
+  - Only allows a single open file handler to any instance of the driver at 
any time
+  - Reset of the SD-FEC Integrated Block is not controlled by this driver
+  - Does not support shared LDPC code table wraparound
+
+The device tree entry is described in:
+`linux-xlnx/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt 
`_
+
+
+Modes of Operation
+--
+
+The driver works with the SD-FEC core in two modes of operation:
+
+  - Run-time configuration
+  - Programmable Logic (PL) initialization
+
+
+Run-time Configuration
+~~
+
+For Run-time configuration the role of driver is to allow the software 
application to do the following:
+
+   - Load the configuration parameters for either Turbo decode or LDPC 
encode or decode
+   - Activate the SD-FEC core
+   - Monitor the SD-FEC core for errors
+   - Retrieve the status and configuration of the SD-FEC core
+
+Programmable Logic (PL) Initialization
+~~
+
+For PL initialization, supporting logic loads configuration parameters for 
either
+the Turbo decode or LDPC encode or decode.  The role of the driver is to allow
+the software application to do the following:
+
+   - Activate the SD-FEC core
+   - Monitor the SD-FEC core for errors
+   - Retrieve the status and configuration of the SD-FEC core
+
+
+Driver Structure
+
+
+The driver provides a platform device where the ``probe`` and ``remove``
+operations are provided.
+
+  - probe: Updates configuration register with device-tree entries plus 
determines the current activate state of the core, for example, is the core 
bypassed or has the core been started.
+
+
+The driver defines the following driver file operations to provide user
+application interfaces:
+
+  - open: Implements restriction that only a single file descriptor can be 
open per SD-FEC instance at any time
+  - release: Allows another file descriptor to be open, that is after current 
file descriptor is closed
+  - poll: Provides a method to monitor for SD-FEC Error events
+  - unlocked_ioctl: Provides the the following ioctl commands that allows the 
application configure the SD-FEC core:
+
+   - :c:macro:`XSDFEC_START_DEV`
+   - :c:macro:`XSDFEC_STOP_DEV`
+   - :c:macro:`XSDFEC_GET_STATUS`
+   - :c:macro:`XSDFEC_SET_IRQ`
+   - :c:macro:`XSDFEC_SET_TURBO`
+   - :c:macro:`XSDFEC_ADD_LDPC_CODE_PARAMS`
+   - :c:macro:`XSDFEC_GET_CONFIG`
+   - :c:macro:`XSDFEC_SET_ORDER`
+   - :c:macro:`XSDFEC_SET_BYPASS`
+   - :c:macro:`XSDFEC_IS_ACTIVE`
+   - :c:macro:`XSDFEC_CLEAR_STATS`
+   - :c:macro:`XSDFEC_SET_DEFAULT_CONFIG`
+
+
+Driver Usage
+
+
+
+Overview
+
+
+After opening the driver, the user should find out what operations need to be
+performed to configure and activate the SD-FEC core and determine the
+configuration of the driver.
+The following outlines the flow the user should perform:
+
+  - Determine Configuration
+  - Set the order, if not already configured as desired
+  - Set

Re: [PATCH v2 0/2] docs: Programmatically render MAINTAINERS into ReST

[Mauro Carvalho Chehab]

Em Wed, 2 Oct 2019 10:25:35 -0600
Jonathan Corbet  escreveu:

> On Tue,  1 Oct 2019 11:25:30 -0700
> Kees Cook  wrote:
> 
> > v1: 
> > https://lore.kernel.org/lkml/20190924230208.12414-1-keesc...@chromium.org
> > 
> > v2: fix python2 utf-8 issue thanks to Jonathan Corbet
> > 
> > 
> > Commit log from Patch 2 repeated here for cover letter:
> > 
> > In order to have the MAINTAINERS file visible in the rendered ReST
> > output, this makes some small changes to the existing MAINTAINERS file
> > to allow for better machine processing, and adds a new Sphinx directive
> > "maintainers-include" to perform the rendering.  
> 
> OK, I've applied this.  Some notes, none of which really require any
> action...
> 
> It adds a new warning:
> 
>   /stuff/k/git/kernel/MAINTAINERS:40416: WARNING: unknown document: 
> ../misc-devices/xilinx_sdfec   
> 
> I wonder if it's worth checking to be sure that documents referenced in
> MAINTAINERS actually exist.  OTOH, things as they are generate a warning,
> which is what we want anyway.

We check already links that start with Documentation/ and :doc: via the
scripts/documentation-file-ref-check script. It shouldn't probably be hard
to check other files at MAINTAINERS, although some care should be taken
for this to not take too long.

Right now, the script is very fast here (SSD), doing all the checks on
less than one second.

> I did various experiments corrupting the MAINTAINERS file and got some
> fairly unphotogenic results.  Again, though, I'm not sure that adding a
> bunch of code to generate warnings is really worth the trouble.
> 
> The resulting HTML file is 3.4MB and definitely makes my browser sweat when
> loading it :)

In the future, the script could split the MAINTAINERS output into multiple
files, for example:

maintainers.rst (with an index file)
maintainers_a.rst   # entries that starts with A
maintainers_b.rst   # entries that starts with B
...
maintainers_z.rst   # entries that starts with Z


> 
> It adds about 20 seconds to a full "make htmldocs" build, which takes just
> over 3 minutes on the system in question.  So a 10% overhead, essentially.

Python is slow. On my tests with ABI automation, I also noticed some
performance degradation, and did some measurements. Reading all the
ABI files was very fast (specially since there I opted to use Perl,
with is a lot faster than Python). It was equally fast to output the data
(I wrote .rst files at the Python extension during my tests). What really
took almost all of the time of the extension was the Sphinx's internal
logic that parses ReST, which makes sense.

I guess that the increase of time for "make *docs" targets is
unavoidable: more documentation input means that it will take more time
to produce an output.

I suspect that, if we split the MAINTAINERS into multiple rst files,
the script will speedup, as Sphinx could better use the existing CPUs
in order to split its workload.

> 
> All told, it does what it's expected to do.  Thanks for doing this.
> 
> jon



Thanks,
Mauro

Re: [PATCH v6 1/4] nvmem: core: add nvmem_device_find

[Paul Burton]

Hello,

On Tue, Oct 01, 2019 at 11:11:58AM +0100, Srinivas Kandagatla wrote:
> On 23/09/2019 12:46, Thomas Bogendoerfer wrote:
> > nvmem_device_find provides a way to search for nvmem devices with
> > the help of a match function simlair to bus_find_device.
> > 
> > Signed-off-by: Thomas Bogendoerfer 
> > ---
> 
> Thanks for the patch,
> This patch looks good for me.
> 
> Do you know which tree is going to pick this series up?
> 
> I can either apply this patch to nvmem tree
> 
> or here is my Ack for this patch to take it via other trees.
> 
> Reviewed-by: Srinivas Kandagatla 
> Acked-by: Srinivas Kandagatla 

Thanks - if you don't mind I'll take this through mips-next along with
the following patch that depends on it.

Thomas: I see patch 3 has an issue reported by the kbuild test robot,
and still needs acks from the MFD & network maintainers. Can I
presume it's safe to apply patches 1 & 2 without 3 & 4 in the
meantime?

Paul

Re: [PATCH 3/3] dt-bindings: iio: Add ltc2947 documentation

[Rob Herring]

On Wed, Oct 2, 2019 at 10:09 AM Sa, Nuno  wrote:
>
> On Wed, 2019-10-02 at 09:19 -0500, Rob Herring wrote:
> >
> > On Tue, Sep 24, 2019 at 02:49:45PM +0200, Nuno Sá wrote:
> > > Document the LTC2947 device devicetree bindings.
> > >
> > > Signed-off-by: Nuno Sá 
> > > ---
> > >  .../bindings/hwmon/adi,ltc2947.yaml   | 101
> > > ++
> > >  MAINTAINERS   |   1 +
> > >  2 files changed, 102 insertions(+)
> > >  create mode 100644
> > > Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
> > > b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
> > > new file mode 100644
> > > index ..2ea0187421d4
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
> > > @@ -0,0 +1,101 @@
> >
> > Missing license. Please make new bindings (GPL-2.0-only OR BSD-2-
> > Clause)
>
> ack.
>
> > > +%YAML 1.2
> > > +---
> > > +$id:
> > > http://devicetree.org/schemas/bindings/hwmon/adi,ltc2947.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Analog Devices LTC2947 high precision power and energy
> > > monitor
> > > +
> > > +maintainers:
> > > +  - Nuno Sá 
> > > +
> > > +description: |
> > > +  Analog Devices LTC2947 high precision power and energy monitor
> > > over SPI or I2C.
> > > +
> > > +
> > > https://www.analog.com/media/en/technical-documentation/data-sheets/LTC2947.pdf
> > > +
> > > +properties:
> > > +  compatible:
> > > +enum:
> > > +  - adi,ltc2947
> > > +
> > > +  reg:
> > > +maxItems: 1
> > > +
> > > +  clocks:
> > > +description:
> > > +  The LTC2947 uses either a trimmed internal oscillator or an
> > > external clock
> > > +  as the time base for determining the integration period to
> > > represent time,
> > > +  charge and energy. When an external clock is used, this
> > > property must be
> > > +  set accordingly.
> > > +maxItems: 1
> > > +
> > > +  adi,accumulator-ctl-pol:
> > > +description:
> > > +  This property controls the polarity of current that is
> > > accumulated to
> > > +  calculate charge and energy so that, they can be only
> > > accumulated for
> > > +  positive current for example. Since there are two sets of
> > > registers for
> > > +  the accumulated values, this entry can also have two items
> > > which sets
> > > +  energy1/charge1 and energy2/charger2 respectively. Check
> > > table 12 of the
> > > +  datasheet for more information on the supported options.
> > > +allOf:
> > > +  - $ref: /schemas/types.yaml#/definitions/uint32-array
> > > +  - enum: [0, 1, 2, 3]
> > > +  - minItems: 2
> > > +  - maxItems: 2
> > > +default: [0, 0]
> >
> > This should be:
> >
> > allOf:
> >   - $ref: ...
> > items:
> >   enum: [0, 1, 2, 3]
> >   default: 0
> > minItems: 2
> > maxItems: 2
>
> I was expecting this already. When upstreaming another device, I
> realized some errors with `make dt_binding_check` when evaluating the
> example. Just for my understanding, is this also incorrect?

The allOf structure like this also works. You'll get better error
messages if schemas are not under an allOf.

> allOf:
>   - $ref: /schemas/types.yaml#/definitions/uint32-array
>   - minItems: 2
> maxItems: 2
> items:
>   enum: [0, 1, 2, 3]
> default: 0

However, 'default' needs to be indented under 'items'.

>
> I used a similar pattern in another device that is also waiting for
> review :).
> > > +
> > > +  adi,accumulation-deadband-microamp:
> > > +description:
> > > +  This property controls the Accumulation Dead band which
> > > allows to set the
> > > +  level of current below which no accumulation takes place.
> > > +allOf:
> > > +  - $ref: /schemas/types.yaml#/definitions/uint32
> > > +  - maximum: 255
> >
> > maximum should be at same indent as allOf. Or default should be at
> > the
> > same level as maximum (under a single '-' list entry).
>
> So it should be?
>
> allOf:
>   - $ref: /schemas/types.yaml#/definitions/uint32
>   - maximum: 255
> default: 0

Yes.

Re: [PATCH v6 1/4] nvmem: core: add nvmem_device_find

[Thomas Bogendoerfer]

On Wed, 2 Oct 2019 18:33:28 +
Paul Burton  wrote:

> Hello,
> 
> On Tue, Oct 01, 2019 at 11:11:58AM +0100, Srinivas Kandagatla wrote:
> > On 23/09/2019 12:46, Thomas Bogendoerfer wrote:
> > > nvmem_device_find provides a way to search for nvmem devices with
> > > the help of a match function simlair to bus_find_device.
> > > 
> > > Signed-off-by: Thomas Bogendoerfer 
> > > ---
> > 
> > Thanks for the patch,
> > This patch looks good for me.
> > 
> > Do you know which tree is going to pick this series up?
> > 
> > I can either apply this patch to nvmem tree
> > 
> > or here is my Ack for this patch to take it via other trees.
> > 
> > Reviewed-by: Srinivas Kandagatla 
> > Acked-by: Srinivas Kandagatla 
> 
> Thanks - if you don't mind I'll take this through mips-next along with
> the following patch that depends on it.
> 
> Thomas: I see patch 3 has an issue reported by the kbuild test robot,

yes, that's because kbuild robot tries to build it 32bit. I'm going to make
it depend on 64bit all possible ioc3 platforms only support 64bit kernels.

> and still needs acks from the MFD & network maintainers. Can I
>   presume it's safe to apply patches 1 & 2 without 3 & 4 in the
>   meantime?

yes, thank you.

Thomas.

-- 
SUSE Software Solutions Germany GmbH
HRB 247165 (AG München)
Geschäftsführer: Felix Imendörffer

Re: [PATCH 1/3] docs: fix some broken references

[Paul Walmsley]

On Tue, 24 Sep 2019, Mauro Carvalho Chehab wrote:

> There are a number of documentation files that got moved or
> renamed. update their references.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/devicetree/bindings/cpu/cpu-topology.txt| 2 +-
>  Documentation/devicetree/bindings/timer/ingenic,tcu.txt   | 2 +-
>  Documentation/driver-api/gpio/driver.rst  | 2 +-
>  Documentation/hwmon/inspur-ipsps1.rst | 2 +-
>  Documentation/mips/ingenic-tcu.rst| 2 +-
>  Documentation/networking/device_drivers/mellanox/mlx5.rst | 2 +-
>  MAINTAINERS   | 2 +-
>  drivers/net/ethernet/faraday/ftgmac100.c  | 2 +-
>  drivers/net/ethernet/pensando/ionic/ionic_if.h| 4 ++--
>  fs/cifs/cifsfs.c  | 2 +-
>  10 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/cpu/cpu-topology.txt 
> b/Documentation/devicetree/bindings/cpu/cpu-topology.txt
> index 99918189403c..9bd530a35d14 100644
> --- a/Documentation/devicetree/bindings/cpu/cpu-topology.txt
> +++ b/Documentation/devicetree/bindings/cpu/cpu-topology.txt
> @@ -549,5 +549,5 @@ Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system)
>  [2] Devicetree NUMA binding description
>  Documentation/devicetree/bindings/numa.txt
>  [3] RISC-V Linux kernel documentation
> -Documentation/devicetree/bindings/riscv/cpus.txt
> +Documentation/devicetree/bindings/riscv/cpus.yaml
>  [4] https://www.devicetree.org/specifications/

For the RISC-V related change:

Acked-by: Paul Walmsley  # RISC-V


- Paul

[PATCH] lib: textsearch: fix escapes in example code

[Randy Dunlap]

From: Randy Dunlap 

This textsearch code example does not need the '\' escapes and they can
be misleading to someone reading the example. Also, gcc and sparse warn
that the "\%d" is an unknown escape sequence.

Fixes: 5968a70d7af5 ("textsearch: fix kernel-doc warnings and add kernel-api 
section")
Signed-off-by: Randy Dunlap 
Cc: "David S. Miller" 
Cc: net...@vger.kernel.org
---
 lib/textsearch.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- lnx-54-rc1.orig/lib/textsearch.c
+++ lnx-54-rc1/lib/textsearch.c
@@ -89,9 +89,9 @@
  *   goto errout;
  *   }
  *
- *   pos = textsearch_find_continuous(conf, \&state, example, strlen(example));
+ *   pos = textsearch_find_continuous(conf, &state, example, strlen(example));
  *   if (pos != UINT_MAX)
- *   panic("Oh my god, dancing chickens at \%d\n", pos);
+ *   panic("Oh my god, dancing chickens at %d\n", pos);
  *
  *   textsearch_destroy(conf);
  */

Re: [PATCH] Documentation: networking: device drivers: Remove stray asterisks

[David Miller]

From: Jonathan Neuschäfer 
Date: Wed,  2 Oct 2019 17:09:55 +0200

> These asterisks were once references to a line that said:
>   "* Other names and brands may be claimed as the property of others."
> But now, they serve no purpose; they can only irritate the reader.
> 
> Fixes: de3edab4276c ("e1000: update README for e1000")
> Fixes: a3fb65680f65 ("e100.txt: Cleanup license info in kernel doc")
> Fixes: da8c01c4502a ("e1000e.txt: Add e1000e documentation")
> Fixes: f12a84a9f650 ("Documentation: fm10k: Add kernel documentation")
> Fixes: b55c52b1938c ("igb.txt: Add igb documentation")
> Fixes: c4e9b56e2442 ("igbvf.txt: Add igbvf Documentation")
> Fixes: d7064f4c192c ("Documentation/networking/: Update Intel wired LAN 
> driver documentation")
> Fixes: c4b8c01112a1 ("ixgbevf.txt: Update ixgbevf documentation")
> Fixes: 1e06edcc2f22 ("Documentation: i40e: Prepare documentation for RST 
> conversion")
> Fixes: 105bf2fe6b32 ("i40evf: add driver to kernel build system")
> Fixes: 1fae869bcf3d ("Documentation: ice: Prepare documentation for RST 
> conversion")
> Fixes: df69ba43217d ("ionic: Add basic framework for IONIC Network device 
> driver")
> Signed-off-by: Jonathan Neuschäfer 

Jon, how do you want to handle changes like this?

I mean, there are unlikely to be conflicts from something like this so it
could simply go via the documentation tree.

Acked-by: David S. Miller 

I could also take it via net-next, either way is fine with me.

Just let me know.

Re: [PATCH 2/3] hwmon: Add support for ltc2947

[Guenter Roeck]

On Tue, Sep 24, 2019 at 02:49:44PM +0200, Nuno Sá wrote:
> The ltc2947 is a high precision power and energy monitor with an
> internal sense resistor supporting up to +/- 30A. Three internal no
> Latency ADCs ensure accurate measurement of voltage and current, while
> high-bandwidth analog multiplication of voltage and current provides
> accurate power measurement in a wide range of applications. Internal or
> external clocking options enable precise charge and energy measurements.
> 
> Signed-off-by: Nuno Sá 
> ---
>  Documentation/hwmon/ltc2947.rst |  110 +++
>  MAINTAINERS |   10 +
>  drivers/hwmon/Kconfig   |   27 +
>  drivers/hwmon/Makefile  |3 +
>  drivers/hwmon/ltc2947-core.c| 1421 +++
>  drivers/hwmon/ltc2947-i2c.c |   49 ++
>  drivers/hwmon/ltc2947-spi.c |   50 ++
>  drivers/hwmon/ltc2947.h |   12 +
>  8 files changed, 1682 insertions(+)
>  create mode 100644 Documentation/hwmon/ltc2947.rst
>  create mode 100644 drivers/hwmon/ltc2947-core.c
>  create mode 100644 drivers/hwmon/ltc2947-i2c.c
>  create mode 100644 drivers/hwmon/ltc2947-spi.c
>  create mode 100644 drivers/hwmon/ltc2947.h
> 
> diff --git a/Documentation/hwmon/ltc2947.rst b/Documentation/hwmon/ltc2947.rst
> new file mode 100644
> index ..2dcf7487076d
> --- /dev/null
> +++ b/Documentation/hwmon/ltc2947.rst
> @@ -0,0 +1,110 @@
> +Kernel drivers ltc2947-i2c and ltc2947-spi
> +=
> +
> +Supported chips:
> +  * Analog Devices LTC2947
> +Prefix: 'ltc2947'
> +Addresses scanned: -
> +Datasheet:
> +   
> https://www.analog.com/media/en/technical-documentation/data-sheets/LTC2947.pdf
> +
> +Author: Nuno Sa 
> +
> +Description
> +___
> +
> +The LTC2947 is a high precision power and energy monitor that measures 
> current,
> +voltage, power, temperature, charge and energy. The device supports both SPI
> +and I2C depending on the chip configuration.
> +The device also measures accumulated quantities as energy. It has two banks 
> of
> +register's to read/set energy related values. These banks can be configured
> +independently to have setups like: energy1 accumulates always and enrgy2 only
> +accumulates if current is positive (to check battery charging efficiency for
> +example). The device also supports a GPIO pin that can be configured as 
> output
> +to control a fan as a function of measured temperature. Then, the GPIO 
> becomes
> +active as soon as a temperature reading is higher than a defined threshold. 
> The
> +temp2 channel is used to control this thresholds and to read the respective
> +alarms.
> +
> +Sysfs entries
> +_
> +
> +The following attributes are supported. Limits are read-write, reset_history
> +is write-only and all the other attributes are read-only.
> +
> +in0_inputVP-VM voltage (mV).
> +in0_min  Undervoltage threshold
> +in0_max  Overvoltage threshold
> +in0_lowest   Lowest measured voltage
> +in0_highest  Highest measured voltage
> +in0_reset_historyWrite 1 to reset in1 history
> +in0_min_alarmUndervoltage alarm
> +in0_max_alarmOvervoltage alarm
> +in0_faultFault value

This is a non-standard attribute. What exactly does it reflect ?

> +in0_labelChannel label (VP-VM)
> +
> +in1_inputDVCC voltage (mV)
> +in1_min  Undervoltage threshold
> +in1_max  Overvoltage threshold
> +in1_lowest   Lowest measured voltage
> +in1_highest  Highest measured voltage
> +in1_reset_historyWrite 1 to reset in2 history
> +in1_min_alarmUndervoltage alarm
> +in1_max_alarmOvervoltage alarm
> +in1_faultFault value
> +in1_labelChannel label (DVCC)
> +
> +curr1_input  IP-IM Sense current (mA)
> +curr1_minUndercurrent threshold
> +curr1_maxOvercurrent threshold
> +curr1_lowest Lowest measured current
> +curr1_highestHighest measured current
> +curr1_reset_history  Write 1 to reset curr1 history
> +curr1_min_alarm  Undercurrent alarm
> +curr1_max_alarm  Overcurrent alarm
> +curr1_fault  Fault value
> +curr1_label  Channel label (IP-IM)
> +
> +power1_input Power (in uW)
> +power1_min   Low power threshold
> +power1_max   High power threshold
> +power1_input_lowest  Historical minimum power use
> +power1_input_highest Historical maximum power use
> +power1_reset_history Write 1 to reset power1 history
> +power1_min_alarm Low power alarm
> +power1_max_alarm High power alarm
> +power1_fault Fault value
> +power1_label Channel label (Power)
> +
> +temp1_input  Chip Temperature (in milliC)
> +temp1_minLow temperature threshold
> +temp1_maxHigh temperature thresho