Re: [PATCH v2] mm: show total hugetlb memory consumption in /proc/meminfo

[Andrew Morton]

On Wed, 15 Nov 2017 23:14:09 + Roman Gushchin  wrote:

> Currently we display some hugepage statistics (total, free, etc)
> in /proc/meminfo, but only for default hugepage size (e.g. 2Mb).
> 
> If hugepages of different sizes are used (like 2Mb and 1Gb on x86-64),
> /proc/meminfo output can be confusing, as non-default sized hugepages
> are not reflected at all, and there are no signs that they are
> existing and consuming system memory.
> 
> To solve this problem, let's display the total amount of memory,
> consumed by hugetlb pages of all sized (both free and used).
> Let's call it "Hugetlb", and display size in kB to match generic
> /proc/meminfo style.
> 
> For example, (1024 2Mb pages and 2 1Gb pages are pre-allocated):
>   $ cat /proc/meminfo
>   MemTotal:8168984 kB
>   MemFree: 3789276 kB
>   <...>
>   CmaFree:   0 kB
>   HugePages_Total:1024
>   HugePages_Free: 1024
>   HugePages_Rsvd:0
>   HugePages_Surp:0
>   Hugepagesize:   2048 kB
>   Hugetlb: 4194304 kB
>   DirectMap4k:   32632 kB
>   DirectMap2M: 4161536 kB
>   DirectMap1G: 6291456 kB
> 
> Also, this patch updates corresponding docs to reflect
> Hugetlb entry meaning and difference between Hugetlb and
> HugePages_Total * Hugepagesize.
> 
> ...
>
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2973,20 +2973,32 @@ int hugetlb_overcommit_handler(struct ctl_table 
> *table, int write,
>  
>  void hugetlb_report_meminfo(struct seq_file *m)
>  {
> - struct hstate *h = _hstate;
> + struct hstate *h;
> + unsigned long total = 0;
> +
>   if (!hugepages_supported())
>   return;
> - seq_printf(m,
> - "HugePages_Total:   %5lu\n"
> - "HugePages_Free:%5lu\n"
> - "HugePages_Rsvd:%5lu\n"
> - "HugePages_Surp:%5lu\n"
> - "Hugepagesize:   %8lu kB\n",
> - h->nr_huge_pages,
> - h->free_huge_pages,
> - h->resv_huge_pages,
> - h->surplus_huge_pages,
> - 1UL << (huge_page_order(h) + PAGE_SHIFT - 10));
> +
> + for_each_hstate(h) {
> + unsigned long count = h->nr_huge_pages;
> +
> + total += (PAGE_SIZE << huge_page_order(h)) * count;
> +
> + if (h == _hstate)

I'm not understanding this test.  Are we assuming that default_hstate
always refers to the highest-index hstate?  If so why, and is that
valid?

> + seq_printf(m,
> +"HugePages_Total:   %5lu\n"
> +"HugePages_Free:%5lu\n"
> +"HugePages_Rsvd:%5lu\n"
> +"HugePages_Surp:%5lu\n"
> +"Hugepagesize:   %8lu kB\n",
> +count,
> +h->free_huge_pages,
> +h->resv_huge_pages,
> +h->surplus_huge_pages,
> +(PAGE_SIZE << huge_page_order(h)) / 1024);
> + }
> +
> + seq_printf(m, "Hugetlb:%8lu kB\n", total / 1024);
>  }

Re: [PATCH v2] mm: show total hugetlb memory consumption in /proc/meminfo

[Andrew Morton]

On Wed, 15 Nov 2017 23:14:09 + Roman Gushchin  wrote:

> Currently we display some hugepage statistics (total, free, etc)
> in /proc/meminfo, but only for default hugepage size (e.g. 2Mb).
> 
> If hugepages of different sizes are used (like 2Mb and 1Gb on x86-64),
> /proc/meminfo output can be confusing, as non-default sized hugepages
> are not reflected at all, and there are no signs that they are
> existing and consuming system memory.
> 
> To solve this problem, let's display the total amount of memory,
> consumed by hugetlb pages of all sized (both free and used).
> Let's call it "Hugetlb", and display size in kB to match generic
> /proc/meminfo style.
> 
> For example, (1024 2Mb pages and 2 1Gb pages are pre-allocated):
>   $ cat /proc/meminfo
>   MemTotal:8168984 kB
>   MemFree: 3789276 kB
>   <...>
>   CmaFree:   0 kB
>   HugePages_Total:1024
>   HugePages_Free: 1024
>   HugePages_Rsvd:0
>   HugePages_Surp:0
>   Hugepagesize:   2048 kB
>   Hugetlb: 4194304 kB
>   DirectMap4k:   32632 kB
>   DirectMap2M: 4161536 kB
>   DirectMap1G: 6291456 kB
> 
> Also, this patch updates corresponding docs to reflect
> Hugetlb entry meaning and difference between Hugetlb and
> HugePages_Total * Hugepagesize.
> 
> ...
>
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2973,20 +2973,32 @@ int hugetlb_overcommit_handler(struct ctl_table 
> *table, int write,
>  
>  void hugetlb_report_meminfo(struct seq_file *m)
>  {
> - struct hstate *h = _hstate;
> + struct hstate *h;
> + unsigned long total = 0;
> +
>   if (!hugepages_supported())
>   return;
> - seq_printf(m,
> - "HugePages_Total:   %5lu\n"
> - "HugePages_Free:%5lu\n"
> - "HugePages_Rsvd:%5lu\n"
> - "HugePages_Surp:%5lu\n"
> - "Hugepagesize:   %8lu kB\n",
> - h->nr_huge_pages,
> - h->free_huge_pages,
> - h->resv_huge_pages,
> - h->surplus_huge_pages,
> - 1UL << (huge_page_order(h) + PAGE_SHIFT - 10));
> +
> + for_each_hstate(h) {
> + unsigned long count = h->nr_huge_pages;
> +
> + total += (PAGE_SIZE << huge_page_order(h)) * count;
> +
> + if (h == _hstate)

I'm not understanding this test.  Are we assuming that default_hstate
always refers to the highest-index hstate?  If so why, and is that
valid?

> + seq_printf(m,
> +"HugePages_Total:   %5lu\n"
> +"HugePages_Free:%5lu\n"
> +"HugePages_Rsvd:%5lu\n"
> +"HugePages_Surp:%5lu\n"
> +"Hugepagesize:   %8lu kB\n",
> +count,
> +h->free_huge_pages,
> +h->resv_huge_pages,
> +h->surplus_huge_pages,
> +(PAGE_SIZE << huge_page_order(h)) / 1024);
> + }
> +
> + seq_printf(m, "Hugetlb:%8lu kB\n", total / 1024);
>  }

Re: [alsa-devel] [PATCH 1/2] ASoC: fsl_ssi: AC'97 ops need regmap, clock and cleaning up on failure

[Maciej S. Szmigiero]

On 21.11.2017 01:32, Nicolin Chen wrote:
> On Mon, Nov 20, 2017 at 11:14:55PM +0100, Maciej S. Szmigiero wrote:
(..)
>> @@ -1460,12 +1460,6 @@ static int fsl_ssi_probe(struct platform_device *pdev)
>>  sizeof(fsl_ssi_ac97_dai));
>>  
>>  fsl_ac97_data = ssi_private;
> 
> By the way, is there any better way to register the ops for AC97
> while we could pass the ssi_private so as to remove the global
> fsl_ac97_data?

This might be possible (if SSI private data is provided to AC'97 codec in
codecs/ac97.c in platform device data which then is modified to make use
of it), but currently ASoC AC'97 only supports one controller per system
so for a real gain this limitation would have to be addressed first.

Maciej

Re: [alsa-devel] [PATCH 1/2] ASoC: fsl_ssi: AC'97 ops need regmap, clock and cleaning up on failure

[Maciej S. Szmigiero]

On 21.11.2017 01:32, Nicolin Chen wrote:
> On Mon, Nov 20, 2017 at 11:14:55PM +0100, Maciej S. Szmigiero wrote:
(..)
>> @@ -1460,12 +1460,6 @@ static int fsl_ssi_probe(struct platform_device *pdev)
>>  sizeof(fsl_ssi_ac97_dai));
>>  
>>  fsl_ac97_data = ssi_private;
> 
> By the way, is there any better way to register the ops for AC97
> while we could pass the ssi_private so as to remove the global
> fsl_ac97_data?

This might be possible (if SSI private data is provided to AC'97 codec in
codecs/ac97.c in platform device data which then is modified to make use
of it), but currently ASoC AC'97 only supports one controller per system
so for a real gain this limitation would have to be addressed first.

Maciej

Re: [GIT PULL] usercopy whitelisting for v4.15-rc1

[Kees Cook]

On Mon, Nov 20, 2017 at 3:29 PM, Matthew Garrett  wrote:
> From a practical perspective this does feel like a completely reasonable
> request - when changing the semantics of kernel APIs in ways that aren't
> amenable to automated analysis, doing so in a way that generates
> warnings rather than triggering breakage is pretty clearly a preferable
> approach. But these features often start off seeming simple and then
> devolving into rounds of "ok just one more fix and we'll have
> everything" and by then it's easy to have lost track of the amount of
> complexity that's developed as a result. Formalising the Right Way of
> approaching these problems would possibly help avoid this kind of
> problem in future - I'll try to write something up for
> Documentation/process.

I'm always trying to balance the requests from both ends of the
security defense spectrum. One of the most common requests I get from
people who are strongly interested in the defenses is "can this please
be enabled by default?" And then I have to explain that it sometimes
takes time for code to shake out, and it sometimes takes time for
developers to trust it, etc. This is rarely a comfort to them, but
they tend to be glad they can turn some config knob to enable the
"strongest" version, etc, because for them, a false positive is no big
deal. At the other end is the requirement that new stuff should not
break the system. Both are reasonable perspectives, but if we violate
the latter, the defense will never end up in the kernel in the first
place.

The implicit process tends to be: land a defense that is optional,
distros enable it by default, kernel enables it by default. My sense
is that the span for these steps is about 3 years. There are countless
examples, but one of the more recent is x86 KASLR. Optional (Jun 2014,
v3.14), then distro default (e.g. Ubuntu 16.10, Oct 2016), then kernel
default (Jul 2017, v4.12). (And, in my opinion, this takes way too
long. But I'd rather have the defense at all.)

The trouble tends to be even in the "optional" phase, where it may be
optional but still very disruptive. If you were using KASLR but there
was a bug, it was basically going to be fatal to the system. So, my
historical perspective for other less disruptive defenses was "oh
good, it's only BUG(), that's WAY better than taking out the entire
system", but as Linus has pointed out in several threads, BUG() can
frequently lead to that too, which is not acceptable.

A variation on "new stuff should not break the system" comes from
things that LOOK like they can't break the system (i.e. disallowing
some pathological condition that would seem to be entirely reasonable
to disallow), and then discovering that stuff does, actually, use a
pathological condition in the real world (e.g. refcount underflows,
memcpy beyond the end of a short source string, 3rd party drivers
reading directly from userspace memory). And then there's just plain
bugs in defenses (e.g. missed usercopy whitelist for SCTPv6). Handling
these conditions means that in addition to being optional, a new
defense frequently has to also be WARN()-only initially.

Though, even then, there is a spectrum of defense capabilities. KASLR
couldn't WARN() initially since it's an architectural state. The
refcount_t API doesn't really need to be stronger than WARN() because
it can defend against overflow while leaving everything running fine.
And here, as already done, usercopy whitelisting needs to WARN() for
its initial implementation to shake out any hard-to-find cases before
becoming more aggressive.

With all this in mind, it can be tricky to find a way to provide the
right level of initial defense behavior that also has a knob for the
users that want to accept the risk of false positives. I'll keep
trying to get it right and keeping helping others find the right path.
We'll get there, steady progress, etc, etc. :)

-Kees

-- 
Kees Cook
Pixel Security

Re: [GIT PULL] usercopy whitelisting for v4.15-rc1

[Kees Cook]

On Mon, Nov 20, 2017 at 3:29 PM, Matthew Garrett  wrote:
> From a practical perspective this does feel like a completely reasonable
> request - when changing the semantics of kernel APIs in ways that aren't
> amenable to automated analysis, doing so in a way that generates
> warnings rather than triggering breakage is pretty clearly a preferable
> approach. But these features often start off seeming simple and then
> devolving into rounds of "ok just one more fix and we'll have
> everything" and by then it's easy to have lost track of the amount of
> complexity that's developed as a result. Formalising the Right Way of
> approaching these problems would possibly help avoid this kind of
> problem in future - I'll try to write something up for
> Documentation/process.

I'm always trying to balance the requests from both ends of the
security defense spectrum. One of the most common requests I get from
people who are strongly interested in the defenses is "can this please
be enabled by default?" And then I have to explain that it sometimes
takes time for code to shake out, and it sometimes takes time for
developers to trust it, etc. This is rarely a comfort to them, but
they tend to be glad they can turn some config knob to enable the
"strongest" version, etc, because for them, a false positive is no big
deal. At the other end is the requirement that new stuff should not
break the system. Both are reasonable perspectives, but if we violate
the latter, the defense will never end up in the kernel in the first
place.

The implicit process tends to be: land a defense that is optional,
distros enable it by default, kernel enables it by default. My sense
is that the span for these steps is about 3 years. There are countless
examples, but one of the more recent is x86 KASLR. Optional (Jun 2014,
v3.14), then distro default (e.g. Ubuntu 16.10, Oct 2016), then kernel
default (Jul 2017, v4.12). (And, in my opinion, this takes way too
long. But I'd rather have the defense at all.)

The trouble tends to be even in the "optional" phase, where it may be
optional but still very disruptive. If you were using KASLR but there
was a bug, it was basically going to be fatal to the system. So, my
historical perspective for other less disruptive defenses was "oh
good, it's only BUG(), that's WAY better than taking out the entire
system", but as Linus has pointed out in several threads, BUG() can
frequently lead to that too, which is not acceptable.

A variation on "new stuff should not break the system" comes from
things that LOOK like they can't break the system (i.e. disallowing
some pathological condition that would seem to be entirely reasonable
to disallow), and then discovering that stuff does, actually, use a
pathological condition in the real world (e.g. refcount underflows,
memcpy beyond the end of a short source string, 3rd party drivers
reading directly from userspace memory). And then there's just plain
bugs in defenses (e.g. missed usercopy whitelist for SCTPv6). Handling
these conditions means that in addition to being optional, a new
defense frequently has to also be WARN()-only initially.

Though, even then, there is a spectrum of defense capabilities. KASLR
couldn't WARN() initially since it's an architectural state. The
refcount_t API doesn't really need to be stronger than WARN() because
it can defend against overflow while leaving everything running fine.
And here, as already done, usercopy whitelisting needs to WARN() for
its initial implementation to shake out any hard-to-find cases before
becoming more aggressive.

With all this in mind, it can be tricky to find a way to provide the
right level of initial defense behavior that also has a knob for the
users that want to accept the risk of false positives. I'll keep
trying to get it right and keeping helping others find the right path.
We'll get there, steady progress, etc, etc. :)

-Kees

-- 
Kees Cook
Pixel Security

[PATCH 1/3] net: core: export dev_alloc_name_ns

[Rasmus Villemoes]

dev_alloc_name_ns and dev_get_valid_name now do exactly the same
thing. Let's expose this functionality as dev_alloc_name_ns
(obviously, a core function like this won't return an invalid
name...).

Signed-off-by: Rasmus Villemoes 
---
 include/linux/netdevice.h | 1 +
 net/core/dev.c| 7 ---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 6b274bfe489f..e249d3d0ff85 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2447,6 +2447,7 @@ struct net_device *dev_get_by_name(struct net *net, const 
char *name);
 struct net_device *dev_get_by_name_rcu(struct net *net, const char *name);
 struct net_device *__dev_get_by_name(struct net *net, const char *name);
 int dev_alloc_name(struct net_device *dev, const char *name);
+int dev_alloc_name_ns(struct net *net, struct net_device *dev, const char 
*name);
 int dev_open(struct net_device *dev);
 void dev_close(struct net_device *dev);
 void dev_close_many(struct list_head *head, bool unlink);
diff --git a/net/core/dev.c b/net/core/dev.c
index 8ee29f4f5fa9..9575e7329823 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1109,9 +1109,9 @@ static int __dev_alloc_name(struct net *net, const char 
*name, char *buf)
return p ? -ENFILE : -EEXIST;
 }
 
-static int dev_alloc_name_ns(struct net *net,
-struct net_device *dev,
-const char *name)
+int dev_alloc_name_ns(struct net *net,
+ struct net_device *dev,
+ const char *name)
 {
char buf[IFNAMSIZ];
int ret;
@@ -1122,6 +1122,7 @@ static int dev_alloc_name_ns(struct net *net,
strlcpy(dev->name, buf, IFNAMSIZ);
return ret;
 }
+EXPORT_SYMBOL(dev_alloc_name_ns);
 
 /**
  * dev_alloc_name - allocate a name for a device
-- 
2.11.0

[PATCH 2/3] net: use dev_alloc_name_ns instead of dev_get_valid_name

[Rasmus Villemoes]

The latter is simply a wrapper for the former; no need to keep both, so
call dev_alloc_name_ns directly.

Signed-off-by: Rasmus Villemoes 
---
 drivers/net/tun.c | 2 +-
 net/core/dev.c| 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 6bb1e604aadd..849a95505f80 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2253,7 +2253,7 @@ static int tun_set_iff(struct net *net, struct file 
*file, struct ifreq *ifr)
 
if (!dev)
return -ENOMEM;
-   err = dev_get_valid_name(net, dev, name);
+   err = dev_alloc_name_ns(net, dev, name);
if (err < 0)
goto err_free_dev;
 
diff --git a/net/core/dev.c b/net/core/dev.c
index 9575e7329823..0de42f39d280 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1183,7 +1183,7 @@ int dev_change_name(struct net_device *dev, const char 
*newname)
 
memcpy(oldname, dev->name, IFNAMSIZ);
 
-   err = dev_get_valid_name(net, dev, newname);
+   err = dev_alloc_name_ns(net, dev, newname);
if (err < 0) {
write_seqcount_end(_rename_seq);
return err;
@@ -7615,7 +7615,7 @@ int register_netdevice(struct net_device *dev)
spin_lock_init(>addr_list_lock);
netdev_set_addr_lockdep_class(dev);
 
-   ret = dev_get_valid_name(net, dev, dev->name);
+   ret = dev_alloc_name_ns(net, dev, dev->name);
if (ret < 0)
goto out;
 
@@ -8354,7 +8354,7 @@ int dev_change_net_namespace(struct net_device *dev, 
struct net *net, const char
/* We get here if we can't use the current device name */
if (!pat)
goto out;
-   if (dev_get_valid_name(net, dev, pat) < 0)
+   if (dev_alloc_name_ns(net, dev, pat) < 0)
goto out;
}
 
-- 
2.11.0

[PATCH 1/3] net: core: export dev_alloc_name_ns

[Rasmus Villemoes]

dev_alloc_name_ns and dev_get_valid_name now do exactly the same
thing. Let's expose this functionality as dev_alloc_name_ns
(obviously, a core function like this won't return an invalid
name...).

Signed-off-by: Rasmus Villemoes 
---
 include/linux/netdevice.h | 1 +
 net/core/dev.c| 7 ---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 6b274bfe489f..e249d3d0ff85 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2447,6 +2447,7 @@ struct net_device *dev_get_by_name(struct net *net, const 
char *name);
 struct net_device *dev_get_by_name_rcu(struct net *net, const char *name);
 struct net_device *__dev_get_by_name(struct net *net, const char *name);
 int dev_alloc_name(struct net_device *dev, const char *name);
+int dev_alloc_name_ns(struct net *net, struct net_device *dev, const char 
*name);
 int dev_open(struct net_device *dev);
 void dev_close(struct net_device *dev);
 void dev_close_many(struct list_head *head, bool unlink);
diff --git a/net/core/dev.c b/net/core/dev.c
index 8ee29f4f5fa9..9575e7329823 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1109,9 +1109,9 @@ static int __dev_alloc_name(struct net *net, const char 
*name, char *buf)
return p ? -ENFILE : -EEXIST;
 }
 
-static int dev_alloc_name_ns(struct net *net,
-struct net_device *dev,
-const char *name)
+int dev_alloc_name_ns(struct net *net,
+ struct net_device *dev,
+ const char *name)
 {
char buf[IFNAMSIZ];
int ret;
@@ -1122,6 +1122,7 @@ static int dev_alloc_name_ns(struct net *net,
strlcpy(dev->name, buf, IFNAMSIZ);
return ret;
 }
+EXPORT_SYMBOL(dev_alloc_name_ns);
 
 /**
  * dev_alloc_name - allocate a name for a device
-- 
2.11.0

[PATCH 2/3] net: use dev_alloc_name_ns instead of dev_get_valid_name

[Rasmus Villemoes]

The latter is simply a wrapper for the former; no need to keep both, so
call dev_alloc_name_ns directly.

Signed-off-by: Rasmus Villemoes 
---
 drivers/net/tun.c | 2 +-
 net/core/dev.c| 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 6bb1e604aadd..849a95505f80 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2253,7 +2253,7 @@ static int tun_set_iff(struct net *net, struct file 
*file, struct ifreq *ifr)
 
if (!dev)
return -ENOMEM;
-   err = dev_get_valid_name(net, dev, name);
+   err = dev_alloc_name_ns(net, dev, name);
if (err < 0)
goto err_free_dev;
 
diff --git a/net/core/dev.c b/net/core/dev.c
index 9575e7329823..0de42f39d280 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1183,7 +1183,7 @@ int dev_change_name(struct net_device *dev, const char 
*newname)
 
memcpy(oldname, dev->name, IFNAMSIZ);
 
-   err = dev_get_valid_name(net, dev, newname);
+   err = dev_alloc_name_ns(net, dev, newname);
if (err < 0) {
write_seqcount_end(_rename_seq);
return err;
@@ -7615,7 +7615,7 @@ int register_netdevice(struct net_device *dev)
spin_lock_init(>addr_list_lock);
netdev_set_addr_lockdep_class(dev);
 
-   ret = dev_get_valid_name(net, dev, dev->name);
+   ret = dev_alloc_name_ns(net, dev, dev->name);
if (ret < 0)
goto out;
 
@@ -8354,7 +8354,7 @@ int dev_change_net_namespace(struct net_device *dev, 
struct net *net, const char
/* We get here if we can't use the current device name */
if (!pat)
goto out;
-   if (dev_get_valid_name(net, dev, pat) < 0)
+   if (dev_alloc_name_ns(net, dev, pat) < 0)
goto out;
}
 
-- 
2.11.0

Re: [dm-devel] [PATCH 00/13] block: assorted cleanup for bio splitting and cloning.

[NeilBrown]

On Mon, Nov 20 2017, Mike Snitzer wrote:

> On Sun, Jun 18, 2017 at 5:36 PM, NeilBrown  wrote:
>> On Sun, Jun 18 2017, Jens Axboe wrote:
>>
>>> On Sun, Jun 18 2017, NeilBrown wrote:
 This is a resend of my series of patches working
 towards removing the bioset work queues.

 This set is based on for-4.13/block.

 It incorporates the revised versions of all the patches that were
 resent following feedback on the last set.

 It also includes a minor grammatic improvement to a comment, and
 simple changes to compensate for a couple of changes to the block tree
 since the last posting.

 I hope to eventually get rid of the new BIOSET_NEED_RESCUER flag,
 but that needs work in dm and probably bcache first.
>>>
>>> Thanks Neil, applied.
>>
>> Thanks a lot Jens.
>
> I missed this line of work until now.  Not quite sure why I wasn't
> cc'd or my review/ack required for the DM changes in this patchset.

Hi Mike,
 I'm sorry you weren't included on those.  My thinking at the time was
 probably that they were purely cosmetic changes which made no
 functional difference to dm.  That is no excuse though and I do
 apologize.

>
> But I've now queued this patch for once Linus gets back (reverts DM
> changes from commit 47e0fb461f):
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next=c9fdc42ba23eabd1ba7aef199fb9bb4b4fe5c545

This patch does two things.
1/ It removes the BIOSET_NEED_RESCUER flag from biosets created by dm.
  This a functional changed over the code from before my patches.
  Previously, all biosets were given a rescuer thread.
  After my patch set, biosets only got a rescuer thread if
  BIOSET_NEED_RESCUER was passed, and it was passed for all biosets.
  I then removed it from places were I was certain it wasn't needed.
  I didn't remove it from dm because I wasn't certain.  Your
  patch does remove the flags, which I think is incorrect - see below.

2/ It changes flush_current_bio_list() so that bios allocated from a
   bioset that does not have a rescue_workqueue are now added to
   the ->rescue_list for their bio_set, and ->rescue_work is queued
   on the NULL ->rescue_workqueue, resulting in a NULL dereference.
   I suspect you don't want this.

The patch description claims that the patch fixes something, but it
isn't clear to me what it is meant to be fixing.

It makes reference to  dbba42d8 which is described as removing an unused
bioset process, though what it actually does is remove an used bioset
(and obvious the process disappears with it).  My patch doesn't change
that behavior.

>
> As is, it is my understanding that DM has no need for a bio_set's
> rescue_workqueue.  So its removal would appear to only be gated by
> bcache?
>
> But I could be mistaken, moving forward please let me know what you
> feel needs doing in DM to make it a better citizen.

I think you are mistaken.
Please see
   https://www.redhat.com/archives/dm-devel/2017-August/msg00310.html
and
   https://www.redhat.com/archives/dm-devel/2017-August/msg00315.html
for which the thread continues:
   https://www.redhat.com/archives/dm-devel/2017-September/msg1.html

These were sent to you, though most of the conversation happened with
Mikulas.

I think that the patches in those threads explain why dm currently needs
rescuer threads, and shows how dm can be changed to no longer need the
rescuer.  I would appreciate your thoughts on these patches.  I can
resend them if that would help.

That would then just leave bcache  I find it a bit of a challenge to
reason about the code in bcache, but if we can remove
BIOSET_NEED_RESCUER from dm, that will be an extra incentive for me to learn :-)

Thanks,
NeilBrown


>
> Thanks,
> Mike
>
> --
> dm-devel mailing list
> dm-de...@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel


signature.asc
Description: PGP signature

Re: [dm-devel] [PATCH 00/13] block: assorted cleanup for bio splitting and cloning.

[NeilBrown]

On Mon, Nov 20 2017, Mike Snitzer wrote:

> On Sun, Jun 18, 2017 at 5:36 PM, NeilBrown  wrote:
>> On Sun, Jun 18 2017, Jens Axboe wrote:
>>
>>> On Sun, Jun 18 2017, NeilBrown wrote:
 This is a resend of my series of patches working
 towards removing the bioset work queues.

 This set is based on for-4.13/block.

 It incorporates the revised versions of all the patches that were
 resent following feedback on the last set.

 It also includes a minor grammatic improvement to a comment, and
 simple changes to compensate for a couple of changes to the block tree
 since the last posting.

 I hope to eventually get rid of the new BIOSET_NEED_RESCUER flag,
 but that needs work in dm and probably bcache first.
>>>
>>> Thanks Neil, applied.
>>
>> Thanks a lot Jens.
>
> I missed this line of work until now.  Not quite sure why I wasn't
> cc'd or my review/ack required for the DM changes in this patchset.

Hi Mike,
 I'm sorry you weren't included on those.  My thinking at the time was
 probably that they were purely cosmetic changes which made no
 functional difference to dm.  That is no excuse though and I do
 apologize.

>
> But I've now queued this patch for once Linus gets back (reverts DM
> changes from commit 47e0fb461f):
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next=c9fdc42ba23eabd1ba7aef199fb9bb4b4fe5c545

This patch does two things.
1/ It removes the BIOSET_NEED_RESCUER flag from biosets created by dm.
  This a functional changed over the code from before my patches.
  Previously, all biosets were given a rescuer thread.
  After my patch set, biosets only got a rescuer thread if
  BIOSET_NEED_RESCUER was passed, and it was passed for all biosets.
  I then removed it from places were I was certain it wasn't needed.
  I didn't remove it from dm because I wasn't certain.  Your
  patch does remove the flags, which I think is incorrect - see below.

2/ It changes flush_current_bio_list() so that bios allocated from a
   bioset that does not have a rescue_workqueue are now added to
   the ->rescue_list for their bio_set, and ->rescue_work is queued
   on the NULL ->rescue_workqueue, resulting in a NULL dereference.
   I suspect you don't want this.

The patch description claims that the patch fixes something, but it
isn't clear to me what it is meant to be fixing.

It makes reference to  dbba42d8 which is described as removing an unused
bioset process, though what it actually does is remove an used bioset
(and obvious the process disappears with it).  My patch doesn't change
that behavior.

>
> As is, it is my understanding that DM has no need for a bio_set's
> rescue_workqueue.  So its removal would appear to only be gated by
> bcache?
>
> But I could be mistaken, moving forward please let me know what you
> feel needs doing in DM to make it a better citizen.

I think you are mistaken.
Please see
   https://www.redhat.com/archives/dm-devel/2017-August/msg00310.html
and
   https://www.redhat.com/archives/dm-devel/2017-August/msg00315.html
for which the thread continues:
   https://www.redhat.com/archives/dm-devel/2017-September/msg1.html

These were sent to you, though most of the conversation happened with
Mikulas.

I think that the patches in those threads explain why dm currently needs
rescuer threads, and shows how dm can be changed to no longer need the
rescuer.  I would appreciate your thoughts on these patches.  I can
resend them if that would help.

That would then just leave bcache  I find it a bit of a challenge to
reason about the code in bcache, but if we can remove
BIOSET_NEED_RESCUER from dm, that will be an extra incentive for me to learn :-)

Thanks,
NeilBrown


>
> Thanks,
> Mike
>
> --
> dm-devel mailing list
> dm-de...@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel


signature.asc
Description: PGP signature

[PATCH 3/3] net: core: remove dev_get_valid_name

[Rasmus Villemoes]

No users left.

Signed-off-by: Rasmus Villemoes 
---
 include/linux/netdevice.h | 2 --
 net/core/dev.c| 7 ---
 2 files changed, 9 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index e249d3d0ff85..7b057ef42906 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3732,8 +3732,6 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, 
const char *name,
unsigned char name_assign_type,
void (*setup)(struct net_device *),
unsigned int txqs, unsigned int rxqs);
-int dev_get_valid_name(struct net *net, struct net_device *dev,
-  const char *name);
 
 #define alloc_netdev(sizeof_priv, name, name_assign_type, setup) \
alloc_netdev_mqs(sizeof_priv, name, name_assign_type, setup, 1, 1)
diff --git a/net/core/dev.c b/net/core/dev.c
index 0de42f39d280..405598c27195 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1144,13 +1144,6 @@ int dev_alloc_name(struct net_device *dev, const char 
*name)
 }
 EXPORT_SYMBOL(dev_alloc_name);
 
-int dev_get_valid_name(struct net *net, struct net_device *dev,
-  const char *name)
-{
-   return dev_alloc_name_ns(net, dev, name);
-}
-EXPORT_SYMBOL(dev_get_valid_name);
-
 /**
  * dev_change_name - change name of a device
  * @dev: device
-- 
2.11.0

[PATCH 3/3] net: core: remove dev_get_valid_name

[Rasmus Villemoes]

No users left.

Signed-off-by: Rasmus Villemoes 
---
 include/linux/netdevice.h | 2 --
 net/core/dev.c| 7 ---
 2 files changed, 9 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index e249d3d0ff85..7b057ef42906 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3732,8 +3732,6 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, 
const char *name,
unsigned char name_assign_type,
void (*setup)(struct net_device *),
unsigned int txqs, unsigned int rxqs);
-int dev_get_valid_name(struct net *net, struct net_device *dev,
-  const char *name);
 
 #define alloc_netdev(sizeof_priv, name, name_assign_type, setup) \
alloc_netdev_mqs(sizeof_priv, name, name_assign_type, setup, 1, 1)
diff --git a/net/core/dev.c b/net/core/dev.c
index 0de42f39d280..405598c27195 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1144,13 +1144,6 @@ int dev_alloc_name(struct net_device *dev, const char 
*name)
 }
 EXPORT_SYMBOL(dev_alloc_name);
 
-int dev_get_valid_name(struct net *net, struct net_device *dev,
-  const char *name)
-{
-   return dev_alloc_name_ns(net, dev, name);
-}
-EXPORT_SYMBOL(dev_get_valid_name);
-
 /**
  * dev_change_name - change name of a device
  * @dev: device
-- 
2.11.0

Re: [PATCH v2] KVM: VMX: Fix rflags cache during vCPU reset

[Wanpeng Li]

2017-11-21 7:09 GMT+08:00 Paolo Bonzini :
> On 20/11/2017 23:52, Wanpeng Li wrote:
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index b348920..131fa1c 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -5590,6 +5590,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool 
>> init_event)
>>   vmcs_write64(GUEST_IA32_DEBUGCTL, 0);
>>   }
>>
>> + kvm_set_rflags(vcpu, 2);
>>   vmcs_writel(GUEST_RFLAGS, 0x02);
>
> I think the vmcs_writel can go, kvm_set_rflags ends up calling
> vmx_set_rflags.

Agreed.

>
>>   kvm_rip_write(vcpu, 0xfff0);
>>
>>
>
> Beautified testcase:
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> long r[5];
> int main()
> {
> struct kvm_debugregs dr = { 0 };
>
> r[2] = open("/dev/kvm", O_RDONLY);
> r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
> r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7);
> struct kvm_guest_debug debug = {
> .control = 0xf0403,
> .arch = {
> .debugreg[6] = 0x2,
> .debugreg[7] = 0x2
> }
> };
> ioctl(r[4], KVM_SET_GUEST_DEBUG, );
> ioctl(r[4], KVM_RUN, 0);
> }
>
> No need to do anything, I'll handle this patch after -rc1.

Thanks for that. :)

Regards,
Wanpeng Li

Re: [PATCH v2] KVM: VMX: Fix rflags cache during vCPU reset

[Wanpeng Li]

2017-11-21 7:09 GMT+08:00 Paolo Bonzini :
> On 20/11/2017 23:52, Wanpeng Li wrote:
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index b348920..131fa1c 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -5590,6 +5590,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool 
>> init_event)
>>   vmcs_write64(GUEST_IA32_DEBUGCTL, 0);
>>   }
>>
>> + kvm_set_rflags(vcpu, 2);
>>   vmcs_writel(GUEST_RFLAGS, 0x02);
>
> I think the vmcs_writel can go, kvm_set_rflags ends up calling
> vmx_set_rflags.

Agreed.

>
>>   kvm_rip_write(vcpu, 0xfff0);
>>
>>
>
> Beautified testcase:
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> long r[5];
> int main()
> {
> struct kvm_debugregs dr = { 0 };
>
> r[2] = open("/dev/kvm", O_RDONLY);
> r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
> r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7);
> struct kvm_guest_debug debug = {
> .control = 0xf0403,
> .arch = {
> .debugreg[6] = 0x2,
> .debugreg[7] = 0x2
> }
> };
> ioctl(r[4], KVM_SET_GUEST_DEBUG, );
> ioctl(r[4], KVM_RUN, 0);
> }
>
> No need to do anything, I'll handle this patch after -rc1.

Thanks for that. :)

Regards,
Wanpeng Li

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: call _fsl_ssi_set_dai_fmt() just once in AC'97 mode

[Maciej S. Szmigiero]

On 21.11.2017 01:00, Nicolin Chen wrote:
> On Mon, Nov 20, 2017 at 11:13:45PM +0100, Maciej S. Szmigiero wrote:
(..)
>> We need to make sure, however, that only proper channel slots are enabled
>> at playback start time since some AC'97 CODECs (like VT1613) were observed
>> requesting via SLOTREQ (and so enabling at SSI) spurious ones just after
>> an AC'97 link is started but before the CODEC is configured by its driver.
> 
> I don't really understand this part. Why do we need to *make sure*
> and set SACCDIS and SACCEN again since they're initialized already> 
> Could you please elaborate a bit more?

SACCDIS and SACCEN aren't just normal registers.
They are a way to disable or enable bits in SACCST register - writing
a '1' bit at some position in SACCDIS unsets the relevant bit in SACCST,
writing a '1' bit at some position in SACCEN sets the relevant bit in
SACCST.

But a bit in SACCST can also be set (and so an AC'97 channel slot
enabled) if a CODEC sets the relevant bit in its SLOTREQ request (it is
enough if this bit was set in SLOTREQ just once, bits in SACCST are
'sticky').
If an extra slot gets enabled that's a disaster for playback because some
of normal left or right channel samples are instead redirected to this
extra slot.

Unfortunately, the VT1613 codec on UDOO board (which is the only user of
fsl_ssi driver in the AC'97 mode) is a bit broken and likes to (sometimes)
set extra bits in its SLOTREQ request - I've confirmed this on two boards
bought a few months apart directly from UDOO shop.

A workaround implemented in fsl-asoc-card of setting an appropriate
CODEC register so that slots 3/4 (the normal stereo playback slots) are
used for S/PDIF seems to mostly fix this issue but since this codec is so
untrustworthy then:
>> let's play safe here and make sure that no extra slots are enabled
>> every time a playback is started.

(..)
>> @@ -1149,9 +1146,16 @@ static int fsl_ssi_trigger(struct snd_pcm_substream 
>> *substream, int cmd,
>>  case SNDRV_PCM_TRIGGER_START:
>>  case SNDRV_PCM_TRIGGER_RESUME:
>>  case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
>> -if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
>> +if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
>> +/* no SACC{ST,EN,DIS} regs on imx21-class SSI */
>> +if (fsl_ssi_is_ac97(ssi_private) &&
>> +!ssi_private->soc->imx21regs) {
>> +regmap_write(regs, CCSR_SSI_SACCDIS, 0xff);
>> +regmap_write(regs, CCSR_SSI_SACCEN, 0x300);
>> +}
> 
> And second, why could we ignore them for STREAM_CAPTURE here?

Capture is not affected by SACCST register content.

> Well, at least this part could be moved into fsl_ssi_tx_config()
> since we have an abstraction layer of register configurations.

Will move this into fsl_ssi_tx_config() in a respin.

> 
> Thanks
> Nic

Thanks,
Maciej

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: call _fsl_ssi_set_dai_fmt() just once in AC'97 mode

[Maciej S. Szmigiero]

On 21.11.2017 01:00, Nicolin Chen wrote:
> On Mon, Nov 20, 2017 at 11:13:45PM +0100, Maciej S. Szmigiero wrote:
(..)
>> We need to make sure, however, that only proper channel slots are enabled
>> at playback start time since some AC'97 CODECs (like VT1613) were observed
>> requesting via SLOTREQ (and so enabling at SSI) spurious ones just after
>> an AC'97 link is started but before the CODEC is configured by its driver.
> 
> I don't really understand this part. Why do we need to *make sure*
> and set SACCDIS and SACCEN again since they're initialized already> 
> Could you please elaborate a bit more?

SACCDIS and SACCEN aren't just normal registers.
They are a way to disable or enable bits in SACCST register - writing
a '1' bit at some position in SACCDIS unsets the relevant bit in SACCST,
writing a '1' bit at some position in SACCEN sets the relevant bit in
SACCST.

But a bit in SACCST can also be set (and so an AC'97 channel slot
enabled) if a CODEC sets the relevant bit in its SLOTREQ request (it is
enough if this bit was set in SLOTREQ just once, bits in SACCST are
'sticky').
If an extra slot gets enabled that's a disaster for playback because some
of normal left or right channel samples are instead redirected to this
extra slot.

Unfortunately, the VT1613 codec on UDOO board (which is the only user of
fsl_ssi driver in the AC'97 mode) is a bit broken and likes to (sometimes)
set extra bits in its SLOTREQ request - I've confirmed this on two boards
bought a few months apart directly from UDOO shop.

A workaround implemented in fsl-asoc-card of setting an appropriate
CODEC register so that slots 3/4 (the normal stereo playback slots) are
used for S/PDIF seems to mostly fix this issue but since this codec is so
untrustworthy then:
>> let's play safe here and make sure that no extra slots are enabled
>> every time a playback is started.

(..)
>> @@ -1149,9 +1146,16 @@ static int fsl_ssi_trigger(struct snd_pcm_substream 
>> *substream, int cmd,
>>  case SNDRV_PCM_TRIGGER_START:
>>  case SNDRV_PCM_TRIGGER_RESUME:
>>  case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
>> -if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
>> +if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
>> +/* no SACC{ST,EN,DIS} regs on imx21-class SSI */
>> +if (fsl_ssi_is_ac97(ssi_private) &&
>> +!ssi_private->soc->imx21regs) {
>> +regmap_write(regs, CCSR_SSI_SACCDIS, 0xff);
>> +regmap_write(regs, CCSR_SSI_SACCEN, 0x300);
>> +}
> 
> And second, why could we ignore them for STREAM_CAPTURE here?

Capture is not affected by SACCST register content.

> Well, at least this part could be moved into fsl_ssi_tx_config()
> since we have an abstraction layer of register configurations.

Will move this into fsl_ssi_tx_config() in a respin.

> 
> Thanks
> Nic

Thanks,
Maciej

Re: [alsa-devel] [PATCH 1/2] ASoC: fsl_ssi: AC'97 ops need regmap, clock and cleaning up on failure

[Nicolin Chen]

On Mon, Nov 20, 2017 at 11:14:55PM +0100, Maciej S. Szmigiero wrote:
> AC'97 ops (register read / write) need SSI regmap and clock, so they have
> to be set after them.
> 
> We also need to set these ops back to NULL if we fail the probe.
> 
> Signed-off-by: Maciej S. Szmigiero 

Acked-by: Nicolin Chen 

> ---
>  sound/soc/fsl/fsl_ssi.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index dad80b4b0cfc..a71bb8391f61 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -1460,12 +1460,6 @@ static int fsl_ssi_probe(struct platform_device *pdev)
>   sizeof(fsl_ssi_ac97_dai));
>  
>   fsl_ac97_data = ssi_private;

By the way, is there any better way to register the ops for AC97
while we could pass the ssi_private so as to remove the global
fsl_ac97_data?

Re: [alsa-devel] [PATCH 1/2] ASoC: fsl_ssi: AC'97 ops need regmap, clock and cleaning up on failure

[Nicolin Chen]

On Mon, Nov 20, 2017 at 11:14:55PM +0100, Maciej S. Szmigiero wrote:
> AC'97 ops (register read / write) need SSI regmap and clock, so they have
> to be set after them.
> 
> We also need to set these ops back to NULL if we fail the probe.
> 
> Signed-off-by: Maciej S. Szmigiero 

Acked-by: Nicolin Chen 

> ---
>  sound/soc/fsl/fsl_ssi.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index dad80b4b0cfc..a71bb8391f61 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -1460,12 +1460,6 @@ static int fsl_ssi_probe(struct platform_device *pdev)
>   sizeof(fsl_ssi_ac97_dai));
>  
>   fsl_ac97_data = ssi_private;

By the way, is there any better way to register the ops for AC97
while we could pass the ssi_private so as to remove the global
fsl_ac97_data?

Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)

[Nicolas Pitre]

On Mon, 20 Nov 2017, Guenter Roeck wrote:

> On Mon, Nov 20, 2017 at 03:21:32PM -0500, Nicolas Pitre wrote:
> > On Mon, 20 Nov 2017, Guenter Roeck wrote:
> > 
> > > On Mon, Nov 20, 2017 at 01:18:38PM -0500, Nicolas Pitre wrote:
> > > > On Sun, 19 Nov 2017, Guenter Roeck wrote:
> > > > 
> > > > > On 11/19/2017 08:08 PM, Nicolas Pitre wrote:
> > > > > > On Sun, 19 Nov 2017, Guenter Roeck wrote:
> > > > > > > On 11/19/2017 12:36 PM, Nicolas Pitre wrote:
> > > > > > > > On Sat, 18 Nov 2017, Guenter Roeck wrote:
> > > > > > > > > On Tue, Oct 03, 2017 at 06:29:49PM -0400, Nicolas Pitre wrote:
> > > > > > > > > > @@ -2295,6 +2295,7 @@ void __init setup_per_cpu_areas(void)
> > > > > > > > > > if (pcpu_setup_first_chunk(ai, fc) < 0)
> > > > > > > > > > panic("Failed to initialize percpu areas.");
> > > > > > > > > > +   pcpu_free_alloc_info(ai);
> > > > > > > > > 
> > > > > > > > > This is the culprit. Everything works fine if I remove this 
> > > > > > > > > line.
> > > > > > > > 
> > > > > > > > Without this line, the memory at the ai pointer is leaked. 
> > > > > > > > Maybe this is
> > > > > > > > modifying the memory allocation pattern and that triggers a bug 
> > > > > > > > later on
> > > > > > > > in your case.
> > > > > > > > 
> > > > > > > > At that point the console driver is not yet initialized and any 
> > > > > > > > error
> > > > > > > > message won't be printed. You should enable the early console 
> > > > > > > > mechanism
> > > > > > > > in your kernel (see arch/cris/arch-v32/kernel/debugport.c) and 
> > > > > > > > see what
> > > > > > > > that might tell you.
> > > > > > > > 
> > > > > > > 
> > > > > > > The problem is that BUG() on crisv32 does not yield useful output.
> > > > > > > Anyway, here is the culprit.
> > > > > > > 
> > > > > > > diff --git a/mm/bootmem.c b/mm/bootmem.c
> > > > > > > index 6aef64254203..2bcc8901450c 100644
> > > > > > > --- a/mm/bootmem.c
> > > > > > > +++ b/mm/bootmem.c
> > > > > > > @@ -382,7 +382,8 @@ static int __init mark_bootmem(unsigned long 
> > > > > > > start,
> > > > > > > unsigned long end,
> > > > > > >  return 0;
> > > > > > >  pos = bdata->node_low_pfn;
> > > > > > >  }
> > > > > > > -   BUG();
> > > > > > > +   WARN(1, "mark_bootmem(): memory range 0x%lx-0x%lx not 
> > > > > > > found\n",
> > > > > > > start,
> > > > > > > end);
> > > > > > > +   return -ENOMEM;
> > > > > > >   }
> > > > > > > 
> > > > > > >   /**
> > > > > > > diff --git a/mm/percpu.c b/mm/percpu.c
> > > > > > > index 79e3549cab0f..c75622d844f1 100644
> > > > > > > --- a/mm/percpu.c
> > > > > > > +++ b/mm/percpu.c
> > > > > > > @@ -1881,6 +1881,7 @@ struct pcpu_alloc_info * __init
> > > > > > > pcpu_alloc_alloc_info(int nr_groups,
> > > > > > >*/
> > > > > > >   void __init pcpu_free_alloc_info(struct pcpu_alloc_info *ai)
> > > > > > >   {
> > > > > > > +   printk("pcpu_free_alloc_info(%p (0x%lx))\n", ai, 
> > > > > > > __pa(ai));
> > > > > > >  memblock_free_early(__pa(ai), ai->__ai_size);
> > > > > > >
> > > > > > > results in:
> > > > > > > 
> > > > > > > pcpu_free_alloc_info(c0534000 (0x40534000))
> > > > > > > [ cut here ]
> > > > > > > WARNING: CPU: 0 PID: 0 at mm/bootmem.c:385 mark_bootmem+0x9a/0xaa
> > > > > > > mark_bootmem(): memory range 0x2029a-0x2029b not found
> > > > > > 
> > > > > > Well... PFN_UP(0x40534000) should give 0x40534. How you might end up
> > > > > > with 0x2029a in mark_bootmem(), let alone not exit on the first "if 
> > > > > > (max
> > > > > > == end) return 0;" within the loop is rather weird.
> > > > > > 
> > > > > pcpu_free_alloc_info: ai=c0536000, __pa(ai)=0x40536000,
> > > > > PFN_UP(__pa(ai))=0x2029b, PFN_UP(ai)=0x6029b
> > > > > 
> > > > > bootmem range is 0x6..0x61000. It doesn't get to "if (max == end)"
> > > > > because "pos (=0x2029b) < bdata->node_min_pfn (=0x6)".
> > > > 
> > > > OK. the 0x2029b is the result of PAGE_SIZE being 8192 in your case.
> > > > However the bootmem allocator deals with physical addresses not virtual 
> > > > ones. So it shouldn't give you a 0x6..0x61000 range.
> > > > 
> > > > Would be interesting to see what result you get on line 860 of 
> > > > mm/bootmem.c.
> > > > 
> > > Nothing; __alloc_bootmem_low_node() is not called.
> > > 
> > > Call chain is:
> > >   pcpu_alloc_alloc_info
> > > memblock_virt_alloc_nopanic
> > >   __alloc_bootmem_nopanic
> > > ___alloc_bootmem_nopanic
> > 
> > But from there it should continue with: 
> > 
> > alloc_bootmem_core() -->
> >   alloc_bootmem_bdata() -->
> > [...]
> > region = phys_to_virt(PFN_PHYS(bdata->node_min_pfn) + start_off);
> > 
> > That's line 585, not 860 as I mentioned. Sorry for the confusion.
> > 
> bdata->node_min_pfn=6 PFN_PHYS(bdata->node_min_pfn)=c000 
> start_off=536000 region=c0536000

If PFN_PHYS(bdata->node_min_pfn)=c000 and
region=c0536000 that means phys_to_virt() is a 

Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)

[Nicolas Pitre]

On Mon, 20 Nov 2017, Guenter Roeck wrote:

> On Mon, Nov 20, 2017 at 03:21:32PM -0500, Nicolas Pitre wrote:
> > On Mon, 20 Nov 2017, Guenter Roeck wrote:
> > 
> > > On Mon, Nov 20, 2017 at 01:18:38PM -0500, Nicolas Pitre wrote:
> > > > On Sun, 19 Nov 2017, Guenter Roeck wrote:
> > > > 
> > > > > On 11/19/2017 08:08 PM, Nicolas Pitre wrote:
> > > > > > On Sun, 19 Nov 2017, Guenter Roeck wrote:
> > > > > > > On 11/19/2017 12:36 PM, Nicolas Pitre wrote:
> > > > > > > > On Sat, 18 Nov 2017, Guenter Roeck wrote:
> > > > > > > > > On Tue, Oct 03, 2017 at 06:29:49PM -0400, Nicolas Pitre wrote:
> > > > > > > > > > @@ -2295,6 +2295,7 @@ void __init setup_per_cpu_areas(void)
> > > > > > > > > > if (pcpu_setup_first_chunk(ai, fc) < 0)
> > > > > > > > > > panic("Failed to initialize percpu areas.");
> > > > > > > > > > +   pcpu_free_alloc_info(ai);
> > > > > > > > > 
> > > > > > > > > This is the culprit. Everything works fine if I remove this 
> > > > > > > > > line.
> > > > > > > > 
> > > > > > > > Without this line, the memory at the ai pointer is leaked. 
> > > > > > > > Maybe this is
> > > > > > > > modifying the memory allocation pattern and that triggers a bug 
> > > > > > > > later on
> > > > > > > > in your case.
> > > > > > > > 
> > > > > > > > At that point the console driver is not yet initialized and any 
> > > > > > > > error
> > > > > > > > message won't be printed. You should enable the early console 
> > > > > > > > mechanism
> > > > > > > > in your kernel (see arch/cris/arch-v32/kernel/debugport.c) and 
> > > > > > > > see what
> > > > > > > > that might tell you.
> > > > > > > > 
> > > > > > > 
> > > > > > > The problem is that BUG() on crisv32 does not yield useful output.
> > > > > > > Anyway, here is the culprit.
> > > > > > > 
> > > > > > > diff --git a/mm/bootmem.c b/mm/bootmem.c
> > > > > > > index 6aef64254203..2bcc8901450c 100644
> > > > > > > --- a/mm/bootmem.c
> > > > > > > +++ b/mm/bootmem.c
> > > > > > > @@ -382,7 +382,8 @@ static int __init mark_bootmem(unsigned long 
> > > > > > > start,
> > > > > > > unsigned long end,
> > > > > > >  return 0;
> > > > > > >  pos = bdata->node_low_pfn;
> > > > > > >  }
> > > > > > > -   BUG();
> > > > > > > +   WARN(1, "mark_bootmem(): memory range 0x%lx-0x%lx not 
> > > > > > > found\n",
> > > > > > > start,
> > > > > > > end);
> > > > > > > +   return -ENOMEM;
> > > > > > >   }
> > > > > > > 
> > > > > > >   /**
> > > > > > > diff --git a/mm/percpu.c b/mm/percpu.c
> > > > > > > index 79e3549cab0f..c75622d844f1 100644
> > > > > > > --- a/mm/percpu.c
> > > > > > > +++ b/mm/percpu.c
> > > > > > > @@ -1881,6 +1881,7 @@ struct pcpu_alloc_info * __init
> > > > > > > pcpu_alloc_alloc_info(int nr_groups,
> > > > > > >*/
> > > > > > >   void __init pcpu_free_alloc_info(struct pcpu_alloc_info *ai)
> > > > > > >   {
> > > > > > > +   printk("pcpu_free_alloc_info(%p (0x%lx))\n", ai, 
> > > > > > > __pa(ai));
> > > > > > >  memblock_free_early(__pa(ai), ai->__ai_size);
> > > > > > >
> > > > > > > results in:
> > > > > > > 
> > > > > > > pcpu_free_alloc_info(c0534000 (0x40534000))
> > > > > > > [ cut here ]
> > > > > > > WARNING: CPU: 0 PID: 0 at mm/bootmem.c:385 mark_bootmem+0x9a/0xaa
> > > > > > > mark_bootmem(): memory range 0x2029a-0x2029b not found
> > > > > > 
> > > > > > Well... PFN_UP(0x40534000) should give 0x40534. How you might end up
> > > > > > with 0x2029a in mark_bootmem(), let alone not exit on the first "if 
> > > > > > (max
> > > > > > == end) return 0;" within the loop is rather weird.
> > > > > > 
> > > > > pcpu_free_alloc_info: ai=c0536000, __pa(ai)=0x40536000,
> > > > > PFN_UP(__pa(ai))=0x2029b, PFN_UP(ai)=0x6029b
> > > > > 
> > > > > bootmem range is 0x6..0x61000. It doesn't get to "if (max == end)"
> > > > > because "pos (=0x2029b) < bdata->node_min_pfn (=0x6)".
> > > > 
> > > > OK. the 0x2029b is the result of PAGE_SIZE being 8192 in your case.
> > > > However the bootmem allocator deals with physical addresses not virtual 
> > > > ones. So it shouldn't give you a 0x6..0x61000 range.
> > > > 
> > > > Would be interesting to see what result you get on line 860 of 
> > > > mm/bootmem.c.
> > > > 
> > > Nothing; __alloc_bootmem_low_node() is not called.
> > > 
> > > Call chain is:
> > >   pcpu_alloc_alloc_info
> > > memblock_virt_alloc_nopanic
> > >   __alloc_bootmem_nopanic
> > > ___alloc_bootmem_nopanic
> > 
> > But from there it should continue with: 
> > 
> > alloc_bootmem_core() -->
> >   alloc_bootmem_bdata() -->
> > [...]
> > region = phys_to_virt(PFN_PHYS(bdata->node_min_pfn) + start_off);
> > 
> > That's line 585, not 860 as I mentioned. Sorry for the confusion.
> > 
> bdata->node_min_pfn=6 PFN_PHYS(bdata->node_min_pfn)=c000 
> start_off=536000 region=c0536000

If PFN_PHYS(bdata->node_min_pfn)=c000 and
region=c0536000 that means phys_to_virt() is a 

Re: [PATCH v3 1/3] leds: core: Introduce generic pattern interface

[Bjorn Andersson]

On Mon 20 Nov 15:20 PST 2017, Pavel Machek wrote:

> On Wed 2017-11-15 08:36:42, Greg KH wrote:
> > On Tue, Nov 14, 2017 at 11:13:43PM -0800, Bjorn Andersson wrote:
> > > Some LED controllers have support for autonomously controlling
> > > brightness over time, according to some preprogrammed pattern or
> > > function.
> > > 
> > > This adds a new optional operator that LED class drivers can implement
> > > if they support such functionality as well as a new device attribute to
> > > configure the pattern for a given LED.
> > > 
> > > Signed-off-by: Bjorn Andersson 
> > > ---
> > > 
> > > Changes since v2:
> > > - None
> > > 
> > > Changes since v1:
> > > - New patch, based on discussions following v1
> > > 
> > >  Documentation/ABI/testing/sysfs-class-led |  20 
> > >  drivers/leds/led-class.c  | 150 
> > > ++
> > >  include/linux/leds.h  |  21 +
> > >  3 files changed, 191 insertions(+)
> > > 
> > > diff --git a/Documentation/ABI/testing/sysfs-class-led 
> > > b/Documentation/ABI/testing/sysfs-class-led
> > > index 5f67f7ab277b..74a7f5b1f89b 100644
> > > --- a/Documentation/ABI/testing/sysfs-class-led
> > > +++ b/Documentation/ABI/testing/sysfs-class-led
> > > @@ -61,3 +61,23 @@ Description:
> > >   gpio and backlight triggers. In case of the backlight trigger,
> > >   it is useful when driving a LED which is intended to indicate
> > >   a device in a standby like state.
> > > +
> > > +What:/sys/class/leds//pattern
> > > +Date:July 2017
> > 
> > That was many months ago :)
> > 
> > > +KernelVersion:   4.14
> > 
> > And that kernel version is long since released :)
> 
> Yeah, the other problem is it has some interesting format with ":|"
> marking repeat,

So what would you prefer?

We can either add another file ("pattern_repeat"?) that allows you to
describe this separately or some other symbol.

> and is not really suitable for RGB LEDs...
> 

I can think of two ways to support patterns for a RGB LED;
1) Provide N files for the N channels
2) Make each entry in the suggested pattern file be N brightness values
   followed by the duration - if we wrap each N-tuple in some symbol
   (e.g. <>) this would transparently support "set all channels to same
   brightness value" and per-channel values.

The latter being fully compatible with the proposed interface.

> I'd really prefer to get driver in first, and add pattern interface
> later.
> 

Sure, I can move all the pattern-related code from the driver into a
separate patch.

Regards,
Bjorn

Re: [PATCH v3 1/3] leds: core: Introduce generic pattern interface

[Bjorn Andersson]

On Mon 20 Nov 15:20 PST 2017, Pavel Machek wrote:

> On Wed 2017-11-15 08:36:42, Greg KH wrote:
> > On Tue, Nov 14, 2017 at 11:13:43PM -0800, Bjorn Andersson wrote:
> > > Some LED controllers have support for autonomously controlling
> > > brightness over time, according to some preprogrammed pattern or
> > > function.
> > > 
> > > This adds a new optional operator that LED class drivers can implement
> > > if they support such functionality as well as a new device attribute to
> > > configure the pattern for a given LED.
> > > 
> > > Signed-off-by: Bjorn Andersson 
> > > ---
> > > 
> > > Changes since v2:
> > > - None
> > > 
> > > Changes since v1:
> > > - New patch, based on discussions following v1
> > > 
> > >  Documentation/ABI/testing/sysfs-class-led |  20 
> > >  drivers/leds/led-class.c  | 150 
> > > ++
> > >  include/linux/leds.h  |  21 +
> > >  3 files changed, 191 insertions(+)
> > > 
> > > diff --git a/Documentation/ABI/testing/sysfs-class-led 
> > > b/Documentation/ABI/testing/sysfs-class-led
> > > index 5f67f7ab277b..74a7f5b1f89b 100644
> > > --- a/Documentation/ABI/testing/sysfs-class-led
> > > +++ b/Documentation/ABI/testing/sysfs-class-led
> > > @@ -61,3 +61,23 @@ Description:
> > >   gpio and backlight triggers. In case of the backlight trigger,
> > >   it is useful when driving a LED which is intended to indicate
> > >   a device in a standby like state.
> > > +
> > > +What:/sys/class/leds//pattern
> > > +Date:July 2017
> > 
> > That was many months ago :)
> > 
> > > +KernelVersion:   4.14
> > 
> > And that kernel version is long since released :)
> 
> Yeah, the other problem is it has some interesting format with ":|"
> marking repeat,

So what would you prefer?

We can either add another file ("pattern_repeat"?) that allows you to
describe this separately or some other symbol.

> and is not really suitable for RGB LEDs...
> 

I can think of two ways to support patterns for a RGB LED;
1) Provide N files for the N channels
2) Make each entry in the suggested pattern file be N brightness values
   followed by the duration - if we wrap each N-tuple in some symbol
   (e.g. <>) this would transparently support "set all channels to same
   brightness value" and per-channel values.

The latter being fully compatible with the proposed interface.

> I'd really prefer to get driver in first, and add pattern interface
> later.
> 

Sure, I can move all the pattern-related code from the driver into a
separate patch.

Regards,
Bjorn

Re: [PATCH] docs: add submitting-pull-requests.rst

[Tobin C. Harding]

On Wed, Nov 15, 2017 at 04:09:32PM +0200, Jani Nikula wrote:
> On Wed, 15 Nov 2017, "Tobin C. Harding"  wrote:
> > On Tue, Nov 14, 2017 at 04:48:16PM -0700, Jonathan Corbet wrote:
> >
> > Awesome comments Jon, I knew there would be more to writing docs than
> > first met the eye.
> >
> >> On Wed, 15 Nov 2017 09:54:21 +1100
> >> "Tobin C. Harding"  wrote:
> >> 
> >> > There is currently no documentation on how to create a pull request for
> >> > Linus.
> >> > 
> >> > Anyway, this actually came up at the kernel summit / maintainer
> >> > meeting a few weeks ago, in that "how do I make a good pull request
> >> > to Linus" is something we need to document.
> >> > 
> >> > Here's what I do, and it seems to work well, so maybe we should turn
> >> > it into the start of the documentation for how to do it.
> >> > 
> >> > Create document from email thread on LKML (referenced in document).
> >> > 
> >> > Signed-off-by: Tobin C. Harding 
> >> > ---
> >> > 
> >> > Is it rude to send this during the merge window? Can resend after it 
> >> > closes if
> >> > it makes life easier.
> >> 
> >> I can handle patches during the merge window.  That said, while I welcome
> >> this effort and think it's a good start, there's a few things I'll
> >> quibble about:
> >> 
> >>  - Much of this was actually written by Greg, I believe, and some by Linus.
> >>That deserves credit in the changelog, if nowhere else.
> >
> > Yeah, I struggled for ages with the tense, Greg's stuff is obviously
> > written as him. But I didn't want to paraphrase and present it as if I'd
> > written it. After your comments I'm still unsure of the _best_ way to
> > present this material with a good flow but still giving credit where
> > credit is due? I didn't seem right to add their names to the document
> > (thereby presenting myself as them). I did not think of the changelog -
> > I'll go that path for v2.
> >
> >>  - Putting it in Documentation/process as RST is good.  But it should be
> >>added to index.rst and made part of the docs build.  I suspect you
> >>haven't run it through sphinx at all yet, right?  Some things are
> >>unlikely to format the way you think they might.
> >
> > My bad, I knew I would botch some of the RST stuff, didn't think to run
> > it through sphinx (I tend to view kernel docs as the raw files ;)
> >
> >> Finally, I see this as being the first installment in what, I hope, will
> >> someday be a nice "how to be a kernel maintainer" manual.  I wouldn't
> >> insist on it before taking a patch like this, but if you could see
> >> through to organizing it as a chapter in a bigger sub-book, that would be
> >> great.
> >
> > Happy to do so. I'm no way qualified to produce much of the text but
> > perhaps can assist in getting things moving.
> >
> >> Finally finally... Dan Williams [CC'd] has plans for doing some
> >> maintainer-level documentation.  He may have thoughts on how this fits
> >> into what he's scheming, and I'd suggest copying him on the next
> >> iteration.
> >
> > Let's liaise on this Dan (if you want to).
> >
> >> Finally finally finally...some specific comments on the text.  Some of
> >> them might be read to suggest a major expansion of the work you've done;
> >> please see that as me saying "that would be nice".  Doing all of this is
> >> not a precondition to getting this document added!
> >
> > There is no rush to get merged, let's get it into shape first :)
> >
> >> > +Submitting Pull Requests to Linus: a guide for maintainers
> >> > +==
> >> > +
> >> > +This document is aimed at kernel maintainers.  It describes a method 
> >> > for creating
> >> > +a pull request to be sent to Linus.
> >> 
> >> Limiting text widths to, say, 75 columns when possible is preferable.  Word
> >> has it some maintainers are still reading the docs on their adm3a
> >> terminals.
> >
> > Got it. (idea for next doc 'column widths howto' - your canonical guide
> > to column widths (includes git brief, commit log, email, source code,
> > and docs).
> >
> > I'm kidding. 75 it is.
> >
> >> Most maintainers push directly to Linus, so that's an obvious best focus,
> >> but pull requests happen at other levels too.  One would hope that this
> >> information would be applicable at all levels, so it might be nice to
> >> describe it as such.
> >
> > Oh, Greg had this, I stripped it out. Back in on next spin.
> >
> >> > +Configure Git
> >> > +-
> >> 
> >> "Configure Git to use your private key"
> >> 
> >> We are, of course, missing the whole discussion on why one would want a
> >> keypair, how to create it, how to get it into the web of trust, etc.  All
> >> fodder for a separate chapter in our shiny new maintainer book :)  But it
> >> is worth saying at least that this is about making Git use your key so you
> >> can sign tags for pull requests.
> >
> > Funny you should say that, I'm trying to get into 

Re: [PATCH] docs: add submitting-pull-requests.rst

[Tobin C. Harding]

On Wed, Nov 15, 2017 at 04:09:32PM +0200, Jani Nikula wrote:
> On Wed, 15 Nov 2017, "Tobin C. Harding"  wrote:
> > On Tue, Nov 14, 2017 at 04:48:16PM -0700, Jonathan Corbet wrote:
> >
> > Awesome comments Jon, I knew there would be more to writing docs than
> > first met the eye.
> >
> >> On Wed, 15 Nov 2017 09:54:21 +1100
> >> "Tobin C. Harding"  wrote:
> >> 
> >> > There is currently no documentation on how to create a pull request for
> >> > Linus.
> >> > 
> >> > Anyway, this actually came up at the kernel summit / maintainer
> >> > meeting a few weeks ago, in that "how do I make a good pull request
> >> > to Linus" is something we need to document.
> >> > 
> >> > Here's what I do, and it seems to work well, so maybe we should turn
> >> > it into the start of the documentation for how to do it.
> >> > 
> >> > Create document from email thread on LKML (referenced in document).
> >> > 
> >> > Signed-off-by: Tobin C. Harding 
> >> > ---
> >> > 
> >> > Is it rude to send this during the merge window? Can resend after it 
> >> > closes if
> >> > it makes life easier.
> >> 
> >> I can handle patches during the merge window.  That said, while I welcome
> >> this effort and think it's a good start, there's a few things I'll
> >> quibble about:
> >> 
> >>  - Much of this was actually written by Greg, I believe, and some by Linus.
> >>That deserves credit in the changelog, if nowhere else.
> >
> > Yeah, I struggled for ages with the tense, Greg's stuff is obviously
> > written as him. But I didn't want to paraphrase and present it as if I'd
> > written it. After your comments I'm still unsure of the _best_ way to
> > present this material with a good flow but still giving credit where
> > credit is due? I didn't seem right to add their names to the document
> > (thereby presenting myself as them). I did not think of the changelog -
> > I'll go that path for v2.
> >
> >>  - Putting it in Documentation/process as RST is good.  But it should be
> >>added to index.rst and made part of the docs build.  I suspect you
> >>haven't run it through sphinx at all yet, right?  Some things are
> >>unlikely to format the way you think they might.
> >
> > My bad, I knew I would botch some of the RST stuff, didn't think to run
> > it through sphinx (I tend to view kernel docs as the raw files ;)
> >
> >> Finally, I see this as being the first installment in what, I hope, will
> >> someday be a nice "how to be a kernel maintainer" manual.  I wouldn't
> >> insist on it before taking a patch like this, but if you could see
> >> through to organizing it as a chapter in a bigger sub-book, that would be
> >> great.
> >
> > Happy to do so. I'm no way qualified to produce much of the text but
> > perhaps can assist in getting things moving.
> >
> >> Finally finally... Dan Williams [CC'd] has plans for doing some
> >> maintainer-level documentation.  He may have thoughts on how this fits
> >> into what he's scheming, and I'd suggest copying him on the next
> >> iteration.
> >
> > Let's liaise on this Dan (if you want to).
> >
> >> Finally finally finally...some specific comments on the text.  Some of
> >> them might be read to suggest a major expansion of the work you've done;
> >> please see that as me saying "that would be nice".  Doing all of this is
> >> not a precondition to getting this document added!
> >
> > There is no rush to get merged, let's get it into shape first :)
> >
> >> > +Submitting Pull Requests to Linus: a guide for maintainers
> >> > +==
> >> > +
> >> > +This document is aimed at kernel maintainers.  It describes a method 
> >> > for creating
> >> > +a pull request to be sent to Linus.
> >> 
> >> Limiting text widths to, say, 75 columns when possible is preferable.  Word
> >> has it some maintainers are still reading the docs on their adm3a
> >> terminals.
> >
> > Got it. (idea for next doc 'column widths howto' - your canonical guide
> > to column widths (includes git brief, commit log, email, source code,
> > and docs).
> >
> > I'm kidding. 75 it is.
> >
> >> Most maintainers push directly to Linus, so that's an obvious best focus,
> >> but pull requests happen at other levels too.  One would hope that this
> >> information would be applicable at all levels, so it might be nice to
> >> describe it as such.
> >
> > Oh, Greg had this, I stripped it out. Back in on next spin.
> >
> >> > +Configure Git
> >> > +-
> >> 
> >> "Configure Git to use your private key"
> >> 
> >> We are, of course, missing the whole discussion on why one would want a
> >> keypair, how to create it, how to get it into the web of trust, etc.  All
> >> fodder for a separate chapter in our shiny new maintainer book :)  But it
> >> is worth saying at least that this is about making Git use your key so you
> >> can sign tags for pull requests.
> >
> > Funny you should say that, I'm trying to get into the web of trust so
> > perhaps I can help 

Re: [PATCH v4 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

On Mon, Nov 20, 2017 at 1:25 PM, Ulf Hansson  wrote:
> On 18 November 2017 at 15:31, Rafael J. Wysocki  wrote:
>> From: Rafael J. Wysocki 
>>
>> Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
>> instruct the PM core and middle-layer (bus type, PM domain, etc.)
>> code that it is desirable to leave the device in runtime suspend
>> after system-wide transitions to the working state (for example,
>> the device may be slow to resume and it may be better to avoid
>> resuming it right away).
>>
>> Generally, the middle-layer code involved in the handling of the
>> device is expected to indicate to the PM core whether or not the
>> device may be left in suspend with the help of the device's
>> power.may_skip_resume status bit.  That has to happen in the "noirq"
>> phase of the preceding system suspend (or analogous) transition.
>> The middle layer is then responsible for handling the device as
>> appropriate in its "noirq" resume callback which is executed
>> regardless of whether or not the device may be left suspended, but
>> the other resume callbacks (except for ->complete) will be skipped
>> automatically by the core if the device really can be left in
>> suspend.
>>
>> The additional power.must_resume status bit introduced for the
>> implementation of this mechanisn is used internally by the PM core
>> to track the requirement to resume the device (which may depend on
>> its children etc).
>>
>> Signed-off-by: Rafael J. Wysocki 
>> Acked-by: Greg Kroah-Hartman 
>
> Reviewed-by: Ulf Hansson 

Thanks!

Re: [PATCH v4 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

On Mon, Nov 20, 2017 at 1:25 PM, Ulf Hansson  wrote:
> On 18 November 2017 at 15:31, Rafael J. Wysocki  wrote:
>> From: Rafael J. Wysocki 
>>
>> Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
>> instruct the PM core and middle-layer (bus type, PM domain, etc.)
>> code that it is desirable to leave the device in runtime suspend
>> after system-wide transitions to the working state (for example,
>> the device may be slow to resume and it may be better to avoid
>> resuming it right away).
>>
>> Generally, the middle-layer code involved in the handling of the
>> device is expected to indicate to the PM core whether or not the
>> device may be left in suspend with the help of the device's
>> power.may_skip_resume status bit.  That has to happen in the "noirq"
>> phase of the preceding system suspend (or analogous) transition.
>> The middle layer is then responsible for handling the device as
>> appropriate in its "noirq" resume callback which is executed
>> regardless of whether or not the device may be left suspended, but
>> the other resume callbacks (except for ->complete) will be skipped
>> automatically by the core if the device really can be left in
>> suspend.
>>
>> The additional power.must_resume status bit introduced for the
>> implementation of this mechanisn is used internally by the PM core
>> to track the requirement to resume the device (which may depend on
>> its children etc).
>>
>> Signed-off-by: Rafael J. Wysocki 
>> Acked-by: Greg Kroah-Hartman 
>
> Reviewed-by: Ulf Hansson 

Thanks!

[PATCH] target-core: don't use "const char*" for a buffer that is written to

[Rasmus Villemoes]

From: Rasmus Villemoes 

iscsi_parse_pr_out_transport_id launders the const away via a call to
strstr(), and then modifies the buffer (writing a nul byte) through
the return value. It's cleaner to be honest and simply declare the
parameter as "char*", fixing up the call chain, and allowing us to
drop the cast in the return statement.

Amusingly, the two current callers found it necessary to cast a
non-const pointer to a const.

Signed-off-by: Rasmus Villemoes 
---
 drivers/target/target_core_fabric_lib.c | 6 +++---
 drivers/target/target_core_internal.h   | 2 +-
 drivers/target/target_core_pr.c | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/target/target_core_fabric_lib.c 
b/drivers/target/target_core_fabric_lib.c
index 508da345b73f..71a80257a052 100644
--- a/drivers/target/target_core_fabric_lib.c
+++ b/drivers/target/target_core_fabric_lib.c
@@ -273,7 +273,7 @@ static int iscsi_get_pr_transport_id_len(
 
 static char *iscsi_parse_pr_out_transport_id(
struct se_portal_group *se_tpg,
-   const char *buf,
+   char *buf,
u32 *out_tid_len,
char **port_nexus_ptr)
 {
@@ -356,7 +356,7 @@ static char *iscsi_parse_pr_out_transport_id(
}
}
 
-   return (char *)[4];
+   return [4];
 }
 
 int target_get_pr_transport_id_len(struct se_node_acl *nacl,
@@ -405,7 +405,7 @@ int target_get_pr_transport_id(struct se_node_acl *nacl,
 }
 
 const char *target_parse_pr_out_transport_id(struct se_portal_group *tpg,
-   const char *buf, u32 *out_tid_len, char **port_nexus_ptr)
+   char *buf, u32 *out_tid_len, char **port_nexus_ptr)
 {
u32 offset;
 
diff --git a/drivers/target/target_core_internal.h 
b/drivers/target/target_core_internal.h
index 18e3eb16e756..cada158cf1c2 100644
--- a/drivers/target/target_core_internal.h
+++ b/drivers/target/target_core_internal.h
@@ -101,7 +101,7 @@ int target_get_pr_transport_id(struct se_node_acl *nacl,
struct t10_pr_registration *pr_reg, int *format_code,
unsigned char *buf);
 const char *target_parse_pr_out_transport_id(struct se_portal_group *tpg,
-   const char *buf, u32 *out_tid_len, char **port_nexus_ptr);
+   char *buf, u32 *out_tid_len, char **port_nexus_ptr);
 
 /* target_core_hba.c */
 struct se_hba *core_alloc_hba(const char *, u32, u32);
diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c
index dd2cd8048582..09941d1ae6c1 100644
--- a/drivers/target/target_core_pr.c
+++ b/drivers/target/target_core_pr.c
@@ -1597,7 +1597,7 @@ core_scsi3_decode_spec_i_port(
dest_rtpi = tmp_lun->lun_rtpi;
 
i_str = target_parse_pr_out_transport_id(tmp_tpg,
-   (const char *)ptr, _len, 
_ptr);
+   ptr, _len, _ptr);
if (!i_str)
continue;
 
@@ -3285,7 +3285,7 @@ core_scsi3_emulate_pro_register_and_move(struct se_cmd 
*cmd, u64 res_key,
goto out;
}
initiator_str = target_parse_pr_out_transport_id(dest_se_tpg,
-   (const char *)[24], _tid_len, _ptr);
+   [24], _tid_len, _ptr);
if (!initiator_str) {
pr_err("SPC-3 PR REGISTER_AND_MOVE: Unable to locate"
" initiator_str from Transport ID\n");
-- 
2.11.0

[PATCH] target-core: don't use "const char*" for a buffer that is written to

[Rasmus Villemoes]

From: Rasmus Villemoes 

iscsi_parse_pr_out_transport_id launders the const away via a call to
strstr(), and then modifies the buffer (writing a nul byte) through
the return value. It's cleaner to be honest and simply declare the
parameter as "char*", fixing up the call chain, and allowing us to
drop the cast in the return statement.

Amusingly, the two current callers found it necessary to cast a
non-const pointer to a const.

Signed-off-by: Rasmus Villemoes 
---
 drivers/target/target_core_fabric_lib.c | 6 +++---
 drivers/target/target_core_internal.h   | 2 +-
 drivers/target/target_core_pr.c | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/target/target_core_fabric_lib.c 
b/drivers/target/target_core_fabric_lib.c
index 508da345b73f..71a80257a052 100644
--- a/drivers/target/target_core_fabric_lib.c
+++ b/drivers/target/target_core_fabric_lib.c
@@ -273,7 +273,7 @@ static int iscsi_get_pr_transport_id_len(
 
 static char *iscsi_parse_pr_out_transport_id(
struct se_portal_group *se_tpg,
-   const char *buf,
+   char *buf,
u32 *out_tid_len,
char **port_nexus_ptr)
 {
@@ -356,7 +356,7 @@ static char *iscsi_parse_pr_out_transport_id(
}
}
 
-   return (char *)[4];
+   return [4];
 }
 
 int target_get_pr_transport_id_len(struct se_node_acl *nacl,
@@ -405,7 +405,7 @@ int target_get_pr_transport_id(struct se_node_acl *nacl,
 }
 
 const char *target_parse_pr_out_transport_id(struct se_portal_group *tpg,
-   const char *buf, u32 *out_tid_len, char **port_nexus_ptr)
+   char *buf, u32 *out_tid_len, char **port_nexus_ptr)
 {
u32 offset;
 
diff --git a/drivers/target/target_core_internal.h 
b/drivers/target/target_core_internal.h
index 18e3eb16e756..cada158cf1c2 100644
--- a/drivers/target/target_core_internal.h
+++ b/drivers/target/target_core_internal.h
@@ -101,7 +101,7 @@ int target_get_pr_transport_id(struct se_node_acl *nacl,
struct t10_pr_registration *pr_reg, int *format_code,
unsigned char *buf);
 const char *target_parse_pr_out_transport_id(struct se_portal_group *tpg,
-   const char *buf, u32 *out_tid_len, char **port_nexus_ptr);
+   char *buf, u32 *out_tid_len, char **port_nexus_ptr);
 
 /* target_core_hba.c */
 struct se_hba *core_alloc_hba(const char *, u32, u32);
diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c
index dd2cd8048582..09941d1ae6c1 100644
--- a/drivers/target/target_core_pr.c
+++ b/drivers/target/target_core_pr.c
@@ -1597,7 +1597,7 @@ core_scsi3_decode_spec_i_port(
dest_rtpi = tmp_lun->lun_rtpi;
 
i_str = target_parse_pr_out_transport_id(tmp_tpg,
-   (const char *)ptr, _len, 
_ptr);
+   ptr, _len, _ptr);
if (!i_str)
continue;
 
@@ -3285,7 +3285,7 @@ core_scsi3_emulate_pro_register_and_move(struct se_cmd 
*cmd, u64 res_key,
goto out;
}
initiator_str = target_parse_pr_out_transport_id(dest_se_tpg,
-   (const char *)[24], _tid_len, _ptr);
+   [24], _tid_len, _ptr);
if (!initiator_str) {
pr_err("SPC-3 PR REGISTER_AND_MOVE: Unable to locate"
" initiator_str from Transport ID\n");
-- 
2.11.0

[GIT PULL] Second batch of KVM changes for Linux 4.15

[Paolo Bonzini]

Linus,

The following changes since commit cf9b0772f2e410645fece13b749bd56505b998b8:

  Merge tag 'armsoc-drivers' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2017-11-16 16:05:01 
-0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

for you to fetch changes up to 2444ba9dcdceb6fc60737b22d4dca0a728296ece:

  KVM: X86: Fix softlockup when get the current kvmclock (2017-11-21 00:11:31 
+0100)


* GICv4 Support for KVM/ARM for v4.15
* x86 bugfixes: APIC, nested virtualization, IOAPIC, AMD+VFIO performance
issue with npt=1
* x86 guest UMIP support (real and emulated)

I am not including the host side of AMD SEV, because it wouldn't have gotten
enough time in linux-next even with a "regular-length" merge window.  It
will be in 4.16.


Christoffer Dall (3):
  Merge git://git.kernel.org/.../tip/tip.git irq/core
  KVM: arm/arm64: Fix GICv4 ITS initialization issues
  KVM: arm/arm64: Don't queue VLPIs on INV/INVALL

David Hildenbrand (1):
  KVM: x86: fix em_fxstor() sleeping while in atomic

Dr. David Alan Gilbert (2):
  KVM: lapic: Split out x2apic ldr calculation
  KVM: lapic: Fixup LDR on load in x2apic

Eric Auger (2):
  KVM: arm/arm64: register irq bypass consumer on ARM/ARM64
  KVM: arm/arm64: vgic: restructure kvm_vgic_(un)map_phys_irq

Eyal Moscovici (1):
  KVM: x86: Allow suppressing prints on RDMSR/WRMSR of unhandled MSRs

Gimcuan Hui (1):
  x86: kvm: mmu: make kvm_mmu_clear_all_pte_masks static

Janakarajan Natarajan (1):
  KVM: x86: Fix CPUID function for word 6 (8001_ECX)

Liran Alon (6):
  KVM: x86: pvclock: Handle first-time write to pvclock-page contains 
random junk
  KVM: nVMX/nSVM: Don't intercept #UD when running L2
  KVM: x86: Exit to user-mode on #UD intercept when emulator requires
  KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure
  KVM: x86: Don't re-execute instruction when not passing CR2 value
  KVM: nVMX: Fix vmx_check_nested_events() return value in case an event 
was reinjected to L2

Marc Zyngier (23):
  KVM: arm: Select ARM_GIC_V3 and ARM_GIC_V3_ITS
  KVM: arm/arm64: vgic: Move kvm_vgic_destroy call around
  KVM: arm/arm64: vITS: Add MSI translation helpers
  KVM: arm/arm64: vITS: Add a helper to update the affinity of an LPI
  KVM: arm/arm64: GICv4: Add property field and per-VM predicate
  KVM: arm/arm64: GICv4: Add init/teardown of the per-VM vPE irq domain
  KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass
  KVM: arm/arm64: GICv4: Handle INT command applied to a VLPI
  KVM: arm/arm64: GICv4: Unmap VLPI when freeing an LPI
  KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS
  KVM: arm/arm64: GICv4: Handle CLEAR applied to a VLPI
  KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE
  KVM: arm/arm64: GICv4: Propagate property updates to VLPIs
  KVM: arm/arm64: GICv4: Handle INVALL applied to a vPE
  KVM: arm/arm64: GICv4: Use pending_last as a scheduling hint
  KVM: arm/arm64: GICv4: Add doorbell interrupt handling
  KVM: arm/arm64: GICv4: Use the doorbell interrupt as an unblocking source
  KVM: arm/arm64: GICv4: Hook vPE scheduling into vgic flush/sync
  KVM: arm/arm64: GICv4: Enable virtual cpuif if VLPIs can be delivered
  KVM: arm/arm64: GICv4: Prevent a VM using GICv4 from being saved
  KVM: arm/arm64: GICv4: Prevent userspace from changing doorbell affinity
  KVM: arm/arm64: GICv4: Enable VLPI support
  KVM: arm/arm64: GICv4: Theory of operations

Nikita Leshenko (5):
  KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race
  KVM: x86: ioapic: Don't fire level irq when Remote IRR set
  KVM: x86: ioapic: Remove redundant check for Remote IRR in ioapic_set_irq
  KVM: x86: ioapic: Clear Remote IRR when entry is switched to 
edge-triggered
  KVM: x86: ioapic: Preserve read-only values in the redirection table

Paolo Bonzini (11):
  Merge tag 'kvm-arm-gicv4-for-v4.15' of 
git://git.kernel.org/.../kvmarm/kvmarm into HEAD
  KVM: SVM: obey guest PAT
  kvm: vmx: Reinstate support for CPUs without virtual NMI
  kvm: vmx: Allow disabling virtual NMI support
  KVM: x86: inject exceptions produced by x86_decode_insn
  KVM: vmx: use X86_CR4_UMIP and X86_FEATURE_UMIP
  KVM: x86: add support for UMIP
  KVM: x86: emulate sldt and str
  KVM: x86: add support for emulating UMIP
  KVM: vmx: add support for emulating UMIP
  KVM: x86: emulate RDPID

Wanpeng Li (4):
  KVM: X86: Fix operand/address-size during instruction decoding
  KVM: nVMX: Validate the IA32_BNDCFGS on nested VM-entry
  KVM: nVMX: Fix mmu context after VMLAUNCH/VMRESUME failure
  KVM: X86: Fix 

[GIT PULL] Second batch of KVM changes for Linux 4.15

[Paolo Bonzini]

Linus,

The following changes since commit cf9b0772f2e410645fece13b749bd56505b998b8:

  Merge tag 'armsoc-drivers' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2017-11-16 16:05:01 
-0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

for you to fetch changes up to 2444ba9dcdceb6fc60737b22d4dca0a728296ece:

  KVM: X86: Fix softlockup when get the current kvmclock (2017-11-21 00:11:31 
+0100)


* GICv4 Support for KVM/ARM for v4.15
* x86 bugfixes: APIC, nested virtualization, IOAPIC, AMD+VFIO performance
issue with npt=1
* x86 guest UMIP support (real and emulated)

I am not including the host side of AMD SEV, because it wouldn't have gotten
enough time in linux-next even with a "regular-length" merge window.  It
will be in 4.16.


Christoffer Dall (3):
  Merge git://git.kernel.org/.../tip/tip.git irq/core
  KVM: arm/arm64: Fix GICv4 ITS initialization issues
  KVM: arm/arm64: Don't queue VLPIs on INV/INVALL

David Hildenbrand (1):
  KVM: x86: fix em_fxstor() sleeping while in atomic

Dr. David Alan Gilbert (2):
  KVM: lapic: Split out x2apic ldr calculation
  KVM: lapic: Fixup LDR on load in x2apic

Eric Auger (2):
  KVM: arm/arm64: register irq bypass consumer on ARM/ARM64
  KVM: arm/arm64: vgic: restructure kvm_vgic_(un)map_phys_irq

Eyal Moscovici (1):
  KVM: x86: Allow suppressing prints on RDMSR/WRMSR of unhandled MSRs

Gimcuan Hui (1):
  x86: kvm: mmu: make kvm_mmu_clear_all_pte_masks static

Janakarajan Natarajan (1):
  KVM: x86: Fix CPUID function for word 6 (8001_ECX)

Liran Alon (6):
  KVM: x86: pvclock: Handle first-time write to pvclock-page contains 
random junk
  KVM: nVMX/nSVM: Don't intercept #UD when running L2
  KVM: x86: Exit to user-mode on #UD intercept when emulator requires
  KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure
  KVM: x86: Don't re-execute instruction when not passing CR2 value
  KVM: nVMX: Fix vmx_check_nested_events() return value in case an event 
was reinjected to L2

Marc Zyngier (23):
  KVM: arm: Select ARM_GIC_V3 and ARM_GIC_V3_ITS
  KVM: arm/arm64: vgic: Move kvm_vgic_destroy call around
  KVM: arm/arm64: vITS: Add MSI translation helpers
  KVM: arm/arm64: vITS: Add a helper to update the affinity of an LPI
  KVM: arm/arm64: GICv4: Add property field and per-VM predicate
  KVM: arm/arm64: GICv4: Add init/teardown of the per-VM vPE irq domain
  KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass
  KVM: arm/arm64: GICv4: Handle INT command applied to a VLPI
  KVM: arm/arm64: GICv4: Unmap VLPI when freeing an LPI
  KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS
  KVM: arm/arm64: GICv4: Handle CLEAR applied to a VLPI
  KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE
  KVM: arm/arm64: GICv4: Propagate property updates to VLPIs
  KVM: arm/arm64: GICv4: Handle INVALL applied to a vPE
  KVM: arm/arm64: GICv4: Use pending_last as a scheduling hint
  KVM: arm/arm64: GICv4: Add doorbell interrupt handling
  KVM: arm/arm64: GICv4: Use the doorbell interrupt as an unblocking source
  KVM: arm/arm64: GICv4: Hook vPE scheduling into vgic flush/sync
  KVM: arm/arm64: GICv4: Enable virtual cpuif if VLPIs can be delivered
  KVM: arm/arm64: GICv4: Prevent a VM using GICv4 from being saved
  KVM: arm/arm64: GICv4: Prevent userspace from changing doorbell affinity
  KVM: arm/arm64: GICv4: Enable VLPI support
  KVM: arm/arm64: GICv4: Theory of operations

Nikita Leshenko (5):
  KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race
  KVM: x86: ioapic: Don't fire level irq when Remote IRR set
  KVM: x86: ioapic: Remove redundant check for Remote IRR in ioapic_set_irq
  KVM: x86: ioapic: Clear Remote IRR when entry is switched to 
edge-triggered
  KVM: x86: ioapic: Preserve read-only values in the redirection table

Paolo Bonzini (11):
  Merge tag 'kvm-arm-gicv4-for-v4.15' of 
git://git.kernel.org/.../kvmarm/kvmarm into HEAD
  KVM: SVM: obey guest PAT
  kvm: vmx: Reinstate support for CPUs without virtual NMI
  kvm: vmx: Allow disabling virtual NMI support
  KVM: x86: inject exceptions produced by x86_decode_insn
  KVM: vmx: use X86_CR4_UMIP and X86_FEATURE_UMIP
  KVM: x86: add support for UMIP
  KVM: x86: emulate sldt and str
  KVM: x86: add support for emulating UMIP
  KVM: vmx: add support for emulating UMIP
  KVM: x86: emulate RDPID

Wanpeng Li (4):
  KVM: X86: Fix operand/address-size during instruction decoding
  KVM: nVMX: Validate the IA32_BNDCFGS on nested VM-entry
  KVM: nVMX: Fix mmu context after VMLAUNCH/VMRESUME failure
  KVM: X86: Fix 

[PATCH] MIPS: Fix CPS SMP NS16550 UART defaults

[James Hogan]

From: James Hogan 

The MIPS_CPS_NS16550_BASE and MIPS_CPS_NS16550_SHIFT options have no
defaults for non-Malta platforms which select SYS_SUPPORTS_MIPS_CPS
(i.e. the pistachio and generic platforms). This is problematic for
automated allyesconfig and allmodconfig builds based on these platforms,
since make silentoldconfig tries to ask the user for values, and
especially since v4.15 where the default platform was switched to
generic.

Default these options to 0 and arrange for MIPS_CPS_NS16550 to be no
when using that default base address, so that the option only has an
effect when the default is provided (i.e. Malta) or when a value is
provided by the user.

Fixes: 609cf6f2291a ("MIPS: CPS: Early debug using an ns16550-compatible UART")
Signed-off-by: James Hogan 
Reviewed-by: Paul Burton 
Cc: Ralf Baechle 
Cc: Guenter Roeck 
Cc: linux-m...@linux-mips.org
---
Guenter: I'm guessing this is the problem you're referring to.
---
 arch/mips/Kconfig.debug | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/mips/Kconfig.debug b/arch/mips/Kconfig.debug
index 464af5e025d6..0749c3724543 100644
--- a/arch/mips/Kconfig.debug
+++ b/arch/mips/Kconfig.debug
@@ -124,30 +124,36 @@ config SCACHE_DEBUGFS
 
  If unsure, say N.
 
-menuconfig MIPS_CPS_NS16550
+menuconfig MIPS_CPS_NS16550_BOOL
bool "CPS SMP NS16550 UART output"
depends on MIPS_CPS
help
  Output debug information via an ns16550 compatible UART if exceptions
  occur early in the boot process of a secondary core.
 
-if MIPS_CPS_NS16550
+if MIPS_CPS_NS16550_BOOL
+
+config MIPS_CPS_NS16550
+   def_bool MIPS_CPS_NS16550_BASE != 0
 
 config MIPS_CPS_NS16550_BASE
hex "UART Base Address"
default 0x1b0003f8 if MIPS_MALTA
+   default 0
help
  The base address of the ns16550 compatible UART on which to output
  debug information from the early stages of core startup.
 
+ This is only used if non-zero.
+
 config MIPS_CPS_NS16550_SHIFT
int "UART Register Shift"
-   default 0 if MIPS_MALTA
+   default 0
help
  The number of bits to shift ns16550 register indices by in order to
  form their addresses. That is, log base 2 of the span between
  adjacent ns16550 registers in the system.
 
-endif # MIPS_CPS_NS16550
+endif # MIPS_CPS_NS16550_BOOL
 
 endmenu
-- 
2.14.1

[PATCH] MIPS: Fix CPS SMP NS16550 UART defaults

[James Hogan]

From: James Hogan 

The MIPS_CPS_NS16550_BASE and MIPS_CPS_NS16550_SHIFT options have no
defaults for non-Malta platforms which select SYS_SUPPORTS_MIPS_CPS
(i.e. the pistachio and generic platforms). This is problematic for
automated allyesconfig and allmodconfig builds based on these platforms,
since make silentoldconfig tries to ask the user for values, and
especially since v4.15 where the default platform was switched to
generic.

Default these options to 0 and arrange for MIPS_CPS_NS16550 to be no
when using that default base address, so that the option only has an
effect when the default is provided (i.e. Malta) or when a value is
provided by the user.

Fixes: 609cf6f2291a ("MIPS: CPS: Early debug using an ns16550-compatible UART")
Signed-off-by: James Hogan 
Reviewed-by: Paul Burton 
Cc: Ralf Baechle 
Cc: Guenter Roeck 
Cc: linux-m...@linux-mips.org
---
Guenter: I'm guessing this is the problem you're referring to.
---
 arch/mips/Kconfig.debug | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/mips/Kconfig.debug b/arch/mips/Kconfig.debug
index 464af5e025d6..0749c3724543 100644
--- a/arch/mips/Kconfig.debug
+++ b/arch/mips/Kconfig.debug
@@ -124,30 +124,36 @@ config SCACHE_DEBUGFS
 
  If unsure, say N.
 
-menuconfig MIPS_CPS_NS16550
+menuconfig MIPS_CPS_NS16550_BOOL
bool "CPS SMP NS16550 UART output"
depends on MIPS_CPS
help
  Output debug information via an ns16550 compatible UART if exceptions
  occur early in the boot process of a secondary core.
 
-if MIPS_CPS_NS16550
+if MIPS_CPS_NS16550_BOOL
+
+config MIPS_CPS_NS16550
+   def_bool MIPS_CPS_NS16550_BASE != 0
 
 config MIPS_CPS_NS16550_BASE
hex "UART Base Address"
default 0x1b0003f8 if MIPS_MALTA
+   default 0
help
  The base address of the ns16550 compatible UART on which to output
  debug information from the early stages of core startup.
 
+ This is only used if non-zero.
+
 config MIPS_CPS_NS16550_SHIFT
int "UART Register Shift"
-   default 0 if MIPS_MALTA
+   default 0
help
  The number of bits to shift ns16550 register indices by in order to
  form their addresses. That is, log base 2 of the span between
  adjacent ns16550 registers in the system.
 
-endif # MIPS_CPS_NS16550
+endif # MIPS_CPS_NS16550_BOOL
 
 endmenu
-- 
2.14.1

Re: [PATCH 2/7] kbuild: Add P= command line flag to run checkpatch

[Jim Davis]

On Mon, Nov 20, 2017 at 2:22 PM, Luc Van Oostenryck
 wrote:

> Should it be possible to somehow keep the distinction between
> the flags coming from KBUILD_CFLAGS and the pure CHECKFLAGS?

Well, the practical problem seems to be that $(CHECK) is called in
scripts/Makefile.build with both $(CHECKFLAGS) and $(c_flags) as
arguments, regardless of what $(CHECK) is.  That can be hacked around
with something inelegant like

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index bb831d49bcfd..102194f9afb9 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -98,14 +98,20 @@ __build: $(if $(KBUILD_BUILTIN),$(builtin-target)
$(lib-target) $(extra-y)) \
 $(subdir-ym) $(always)
@:

-# Linus' kernel sanity checking tool
+# Linus' kernel sanity checking tool, or $CHECK program of choice
+ifneq ($(KBUILD_CHECKSRC),)
+  add_to_checkflags =
+  ifeq ($(CHECK),sparse)
+add_to_checkflags = $(c_flags)
+  endif
+endif
 ifneq ($(KBUILD_CHECKSRC),0)
   ifeq ($(KBUILD_CHECKSRC),2)
 quiet_cmd_force_checksrc = CHECK   $<
-  cmd_force_checksrc = $(CHECK) $(CHECKFLAGS) $(c_flags) $< ;
+  cmd_force_checksrc = $(CHECK) $(CHECKFLAGS) $(add_to_checkflags) $< ;
   else
   quiet_cmd_checksrc = CHECK   $<
-cmd_checksrc = $(CHECK) $(CHECKFLAGS) $(c_flags) $< ;
+cmd_checksrc = $(CHECK) $(CHECKFLAGS) $(add_to_checkflags) $< ;
   endif
 endif

and then if I run scripts/checkpatch.pl as $CHECK and pass --quiet
--file as before it works -- until checkpatch returns with a non-zero
exit code, which causes the Makefile to bail at that point.

So maybe a wrapper script, with an exit 0 fixup to keep on keeping on
in case of checkpatch warnings or errors, would be better after all.


-- 
Jim

Re: [PATCH 2/7] kbuild: Add P= command line flag to run checkpatch

[Jim Davis]

On Mon, Nov 20, 2017 at 2:22 PM, Luc Van Oostenryck
 wrote:

> Should it be possible to somehow keep the distinction between
> the flags coming from KBUILD_CFLAGS and the pure CHECKFLAGS?

Well, the practical problem seems to be that $(CHECK) is called in
scripts/Makefile.build with both $(CHECKFLAGS) and $(c_flags) as
arguments, regardless of what $(CHECK) is.  That can be hacked around
with something inelegant like

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index bb831d49bcfd..102194f9afb9 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -98,14 +98,20 @@ __build: $(if $(KBUILD_BUILTIN),$(builtin-target)
$(lib-target) $(extra-y)) \
 $(subdir-ym) $(always)
@:

-# Linus' kernel sanity checking tool
+# Linus' kernel sanity checking tool, or $CHECK program of choice
+ifneq ($(KBUILD_CHECKSRC),)
+  add_to_checkflags =
+  ifeq ($(CHECK),sparse)
+add_to_checkflags = $(c_flags)
+  endif
+endif
 ifneq ($(KBUILD_CHECKSRC),0)
   ifeq ($(KBUILD_CHECKSRC),2)
 quiet_cmd_force_checksrc = CHECK   $<
-  cmd_force_checksrc = $(CHECK) $(CHECKFLAGS) $(c_flags) $< ;
+  cmd_force_checksrc = $(CHECK) $(CHECKFLAGS) $(add_to_checkflags) $< ;
   else
   quiet_cmd_checksrc = CHECK   $<
-cmd_checksrc = $(CHECK) $(CHECKFLAGS) $(c_flags) $< ;
+cmd_checksrc = $(CHECK) $(CHECKFLAGS) $(add_to_checkflags) $< ;
   endif
 endif

and then if I run scripts/checkpatch.pl as $CHECK and pass --quiet
--file as before it works -- until checkpatch returns with a non-zero
exit code, which causes the Makefile to bail at that point.

So maybe a wrapper script, with an exit 0 fixup to keep on keeping on
in case of checkpatch warnings or errors, would be better after all.


-- 
Jim

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: call _fsl_ssi_set_dai_fmt() just once in AC'97 mode

[Nicolin Chen]

On Mon, Nov 20, 2017 at 11:13:45PM +0100, Maciej S. Szmigiero wrote:
> In AC'97 mode we configure and start SSI RX / TX on probe path via
> a call to _fsl_ssi_set_dai_fmt() function.
> We don't need to call this function again later and in fact don't want to
> do it since this function temporarily sets STCR, SRCR and SCR to some
> intermediate values.
> 
> We need to make sure, however, that only proper channel slots are enabled
> at playback start time since some AC'97 CODECs (like VT1613) were observed
> requesting via SLOTREQ (and so enabling at SSI) spurious ones just after
> an AC'97 link is started but before the CODEC is configured by its driver.

I don't really understand this part. Why do we need to *make sure*
and set SACCDIS and SACCEN again since they're initialized already?

Could you please elaborate a bit more?

> Theoretically, this should be necessary only for the very first playback
> but let's play safe here and make sure that no extra slots are enabled
> every time a playback is started.
> 
> Signed-off-by: Maciej S. Szmigiero 
> ---
>  sound/soc/fsl/fsl_ssi.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index 48bb850a34d9..dad80b4b0cfc 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -630,12 +630,6 @@ static void fsl_ssi_setup_ac97(struct fsl_ssi_private 
> *ssi_private)
>   regmap_write(regs, CCSR_SSI_SACNT,
>   CCSR_SSI_SACNT_AC97EN | CCSR_SSI_SACNT_FV);
>  
> - /* no SACC{ST,EN,DIS} regs on imx21-class SSI */
> - if (!ssi_private->soc->imx21regs) {
> - regmap_write(regs, CCSR_SSI_SACCDIS, 0xff);
> - regmap_write(regs, CCSR_SSI_SACCEN, 0x300);
> - }

> @@ -1149,9 +1146,16 @@ static int fsl_ssi_trigger(struct snd_pcm_substream 
> *substream, int cmd,
>   case SNDRV_PCM_TRIGGER_START:
>   case SNDRV_PCM_TRIGGER_RESUME:
>   case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> + /* no SACC{ST,EN,DIS} regs on imx21-class SSI */
> + if (fsl_ssi_is_ac97(ssi_private) &&
> + !ssi_private->soc->imx21regs) {
> + regmap_write(regs, CCSR_SSI_SACCDIS, 0xff);
> + regmap_write(regs, CCSR_SSI_SACCEN, 0x300);
> + }

And second, why could we ignore them for STREAM_CAPTURE here?

Well, at least this part could be moved into fsl_ssi_tx_config()
since we have an abstraction layer of register configurations.

Thanks
Nic

> +
>   fsl_ssi_tx_config(ssi_private, true);
> - else
> + } else
>   fsl_ssi_rx_config(ssi_private, true);
>   break;
>  
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: call _fsl_ssi_set_dai_fmt() just once in AC'97 mode

[Nicolin Chen]

On Mon, Nov 20, 2017 at 11:13:45PM +0100, Maciej S. Szmigiero wrote:
> In AC'97 mode we configure and start SSI RX / TX on probe path via
> a call to _fsl_ssi_set_dai_fmt() function.
> We don't need to call this function again later and in fact don't want to
> do it since this function temporarily sets STCR, SRCR and SCR to some
> intermediate values.
> 
> We need to make sure, however, that only proper channel slots are enabled
> at playback start time since some AC'97 CODECs (like VT1613) were observed
> requesting via SLOTREQ (and so enabling at SSI) spurious ones just after
> an AC'97 link is started but before the CODEC is configured by its driver.

I don't really understand this part. Why do we need to *make sure*
and set SACCDIS and SACCEN again since they're initialized already?

Could you please elaborate a bit more?

> Theoretically, this should be necessary only for the very first playback
> but let's play safe here and make sure that no extra slots are enabled
> every time a playback is started.
> 
> Signed-off-by: Maciej S. Szmigiero 
> ---
>  sound/soc/fsl/fsl_ssi.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index 48bb850a34d9..dad80b4b0cfc 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -630,12 +630,6 @@ static void fsl_ssi_setup_ac97(struct fsl_ssi_private 
> *ssi_private)
>   regmap_write(regs, CCSR_SSI_SACNT,
>   CCSR_SSI_SACNT_AC97EN | CCSR_SSI_SACNT_FV);
>  
> - /* no SACC{ST,EN,DIS} regs on imx21-class SSI */
> - if (!ssi_private->soc->imx21regs) {
> - regmap_write(regs, CCSR_SSI_SACCDIS, 0xff);
> - regmap_write(regs, CCSR_SSI_SACCEN, 0x300);
> - }

> @@ -1149,9 +1146,16 @@ static int fsl_ssi_trigger(struct snd_pcm_substream 
> *substream, int cmd,
>   case SNDRV_PCM_TRIGGER_START:
>   case SNDRV_PCM_TRIGGER_RESUME:
>   case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> + /* no SACC{ST,EN,DIS} regs on imx21-class SSI */
> + if (fsl_ssi_is_ac97(ssi_private) &&
> + !ssi_private->soc->imx21regs) {
> + regmap_write(regs, CCSR_SSI_SACCDIS, 0xff);
> + regmap_write(regs, CCSR_SSI_SACCEN, 0x300);
> + }

And second, why could we ignore them for STREAM_CAPTURE here?

Well, at least this part could be moved into fsl_ssi_tx_config()
since we have an abstraction layer of register configurations.

Thanks
Nic

> +
>   fsl_ssi_tx_config(ssi_private, true);
> - else
> + } else
>   fsl_ssi_rx_config(ssi_private, true);
>   break;
>  
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[PATCH v3 03/12] dt-bindings: i2c: Add P8 OCC hwmon device documentation

[Eddie James]

From: "Edward A. James" 

Document the bindings for I2C-based OCC hwmon device.

Signed-off-by: Edward A. James 
---
 .../devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt   | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt

diff --git a/Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt 
b/Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
new file mode 100644
index 000..5dc5d2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
@@ -0,0 +1,25 @@
+Device-tree bindings for I2C-based On-Chip Controller hwmon device
+--
+
+Required properties:
+ - compatible = "ibm,p8-occ-hwmon";
+ - reg = ;: I2C bus address
+
+Examples:
+
+i2c-bus@100 {
+#address-cells = <1>;
+#size-cells = <0>;
+clock-frequency = <10>;
+< more properties >
+
+occ-hwmon@1 {
+compatible = "ibm,p8-occ-hwmon";
+reg = <0x50>;
+};
+
+occ-hwmon@2 {
+compatible = "ibm,p8-occ-hwmon";
+reg = <0x51>;
+};
+};
-- 
1.8.3.1

[PATCH v3 02/12] Documentation: ABI: Add occ-hwmon driver sysfs documentation

[Eddie James]

From: "Edward A. James" 

Detail the sysfs attributes provided by the occ-hwmon driver.

Signed-off-by: Edward A. James 
---
 Documentation/ABI/testing/sysfs-driver-occ-hwmon | 85 
 1 file changed, 85 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-occ-hwmon

diff --git a/Documentation/ABI/testing/sysfs-driver-occ-hwmon 
b/Documentation/ABI/testing/sysfs-driver-occ-hwmon
new file mode 100644
index 000..8873cc3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-occ-hwmon
@@ -0,0 +1,85 @@
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_active
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates (with a "1" or a "0",
+   respectively) whether or not this OCC is in the "active" state.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_dvfs_ot
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates (with a "1" or a "0",
+   respectively) whether or not this OCC has limited the processor
+   frequency due to over-temperature.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_dvfs_power
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates (with a "1" or a "0",
+   respectively) whether or not this OCC has limited the processor
+   frequency due to power usage.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_error
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates any error condition
+   observed by the OCC or detected by the driver. Reading the
+   attribute will return an integer. A negative integer indicates
+   either an error response from the OCC or bus error or other
+   error condition detected by the driver. A "0" indicates no
+   error.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_master
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates (with a "1" or a "0",
+   respectively) whether or not this OCC is the "master" OCC.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_mem_throttle
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates (with a "1" or a "0",
+   respectively) whether or not the OCC has throttled memory due
+   to over-temperature.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occs_present
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates the number of OCCs present
+   on the system.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_quick_drop
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates (with a "1" or a "0",
+   respectively) whether or not this OCC has asserted the "quick
+   power drop" signal.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_status
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates the current OCC state. The
+   value of the attribute will be one of the following states:
+   0: Reserved
+   1: Standby
+   2: Observation
+   3: Active
+   4: Safe
+   5: Characterization
-- 
1.8.3.1

[PATCH v3 03/12] dt-bindings: i2c: Add P8 OCC hwmon device documentation

[Eddie James]

From: "Edward A. James" 

Document the bindings for I2C-based OCC hwmon device.

Signed-off-by: Edward A. James 
---
 .../devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt   | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt

diff --git a/Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt 
b/Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
new file mode 100644
index 000..5dc5d2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
@@ -0,0 +1,25 @@
+Device-tree bindings for I2C-based On-Chip Controller hwmon device
+--
+
+Required properties:
+ - compatible = "ibm,p8-occ-hwmon";
+ - reg = ;: I2C bus address
+
+Examples:
+
+i2c-bus@100 {
+#address-cells = <1>;
+#size-cells = <0>;
+clock-frequency = <10>;
+< more properties >
+
+occ-hwmon@1 {
+compatible = "ibm,p8-occ-hwmon";
+reg = <0x50>;
+};
+
+occ-hwmon@2 {
+compatible = "ibm,p8-occ-hwmon";
+reg = <0x51>;
+};
+};
-- 
1.8.3.1

[PATCH v3 02/12] Documentation: ABI: Add occ-hwmon driver sysfs documentation

[Eddie James]

From: "Edward A. James" 

Detail the sysfs attributes provided by the occ-hwmon driver.

Signed-off-by: Edward A. James 
---
 Documentation/ABI/testing/sysfs-driver-occ-hwmon | 85 
 1 file changed, 85 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-occ-hwmon

diff --git a/Documentation/ABI/testing/sysfs-driver-occ-hwmon 
b/Documentation/ABI/testing/sysfs-driver-occ-hwmon
new file mode 100644
index 000..8873cc3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-occ-hwmon
@@ -0,0 +1,85 @@
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_active
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates (with a "1" or a "0",
+   respectively) whether or not this OCC is in the "active" state.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_dvfs_ot
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates (with a "1" or a "0",
+   respectively) whether or not this OCC has limited the processor
+   frequency due to over-temperature.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_dvfs_power
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates (with a "1" or a "0",
+   respectively) whether or not this OCC has limited the processor
+   frequency due to power usage.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_error
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates any error condition
+   observed by the OCC or detected by the driver. Reading the
+   attribute will return an integer. A negative integer indicates
+   either an error response from the OCC or bus error or other
+   error condition detected by the driver. A "0" indicates no
+   error.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_master
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates (with a "1" or a "0",
+   respectively) whether or not this OCC is the "master" OCC.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_mem_throttle
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates (with a "1" or a "0",
+   respectively) whether or not the OCC has throttled memory due
+   to over-temperature.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occs_present
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates the number of OCCs present
+   on the system.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_quick_drop
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates (with a "1" or a "0",
+   respectively) whether or not this OCC has asserted the "quick
+   power drop" signal.
+
+What:  /sys/bus/platform/drivers/occ-hwmon//occ_status
+Date:  November 2017
+KernelVersion: 4.14
+Contact:   eaja...@us.ibm.com
+Description:
+   A read-only attribute that indicates the current OCC state. The
+   value of the attribute will be one of the following states:
+   0: Reserved
+   1: Standby
+   2: Observation
+   3: Active
+   4: Safe
+   5: Characterization
-- 
1.8.3.1

[PATCH v3 07/12] hwmon (occ): Parse OCC poll response

[Eddie James]

From: "Edward A. James" 

Add method to parse the response from the OCC poll command. This only
needs to be done during probe(), since the OCC shouldn't change the
number or format of sensors while it's running. The parsed response
allows quick access to sensor data, as well as information on the
number and version of sensors, which we need to instantiate hwmon
attributes.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/common.c | 50 ++
 drivers/hwmon/occ/common.h | 54 ++
 2 files changed, 104 insertions(+)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index 92f06ae..c55aec0 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 
 #include "common.h"
 
@@ -29,6 +30,53 @@ static int occ_poll(struct occ *occ)
return occ->send_cmd(occ, cmd);
 }
 
+/* only need to do this once at startup, as OCC won't change sensors on us */
+static void occ_parse_poll_response(struct occ *occ)
+{
+   unsigned int i, offset = 0, size = 0;
+   struct occ_sensor *sensor;
+   struct occ_sensors *sensors = >sensors;
+   struct occ_response *resp = >resp;
+   struct occ_poll_response *poll =
+   (struct occ_poll_response *)>data[0];
+   struct occ_poll_response_header *header = >header;
+   struct occ_sensor_data_block *block = >block;
+
+   for (i = 0; i < header->num_sensor_data_blocks; ++i) {
+   block = (struct occ_sensor_data_block *)((u8 *)block + offset);
+   offset = (block->header.num_sensors *
+ block->header.sensor_length) + sizeof(block->header);
+   size += offset;
+
+   /* validate all the length/size fields */
+   if ((size + sizeof(*header)) >= OCC_RESP_DATA_BYTES) {
+   dev_warn(occ->bus_dev, "exceeded response buffer\n");
+   return;
+   }
+
+   /* match sensor block type */
+   if (strncmp(block->header.eye_catcher, "TEMP", 4) == 0)
+   sensor = >temp;
+   else if (strncmp(block->header.eye_catcher, "FREQ", 4) == 0)
+   sensor = >freq;
+   else if (strncmp(block->header.eye_catcher, "POWR", 4) == 0)
+   sensor = >power;
+   else if (strncmp(block->header.eye_catcher, "CAPS", 4) == 0)
+   sensor = >caps;
+   else if (strncmp(block->header.eye_catcher, "EXTN", 4) == 0)
+   sensor = >extended;
+   else {
+   dev_warn(occ->bus_dev, "sensor not supported %.4s\n",
+block->header.eye_catcher);
+   continue;
+   }
+
+   sensor->num_sensors = block->header.num_sensors;
+   sensor->version = block->header.sensor_format;
+   sensor->data = >data;
+   }
+}
+
 int occ_setup(struct occ *occ, const char *name)
 {
int rc;
@@ -40,5 +88,7 @@ int occ_setup(struct occ *occ, const char *name)
return rc;
}
 
+   occ_parse_poll_response(occ);
+
return 0;
 }
diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
index 705dfe3..f52d45a 100644
--- a/drivers/hwmon/occ/common.h
+++ b/drivers/hwmon/occ/common.h
@@ -26,10 +26,64 @@ struct occ_response {
__be16 checksum;
 } __packed;
 
+struct occ_sensor_data_block_header {
+   u8 eye_catcher[4];
+   u8 reserved;
+   u8 sensor_format;
+   u8 sensor_length;
+   u8 num_sensors;
+} __packed;
+
+struct occ_sensor_data_block {
+   struct occ_sensor_data_block_header header;
+   u32 data;
+} __packed;
+
+struct occ_poll_response_header {
+   u8 status;
+   u8 ext_status;
+   u8 occs_present;
+   u8 config_data;
+   u8 occ_state;
+   u8 mode;
+   u8 ips_status;
+   u8 error_log_id;
+   __be32 error_log_start_address;
+   __be16 error_log_length;
+   u16 reserved;
+   u8 occ_code_level[16];
+   u8 eye_catcher[6];
+   u8 num_sensor_data_blocks;
+   u8 sensor_data_block_header_version;
+} __packed;
+
+struct occ_poll_response {
+   struct occ_poll_response_header header;
+   struct occ_sensor_data_block block;
+} __packed;
+
+struct occ_sensor {
+   u8 num_sensors;
+   u8 version;
+   void *data; /* pointer to sensor data start within response */
+};
+
+/* OCC only provides one sensor data block of each type, but any number of
+ * sensors within that block.
+ */
+struct occ_sensors {
+   struct occ_sensor temp;
+   struct occ_sensor freq;
+   struct occ_sensor power;
+   struct occ_sensor caps;
+   struct occ_sensor extended;
+};
+
 struct occ {
struct device *bus_dev;
 
struct occ_response 

[PATCH v3 00/12] hwmon: Add On-Chip Controller hwmon driver

[Eddie James]

From: "Edward A. James" 

This series adds a hwmon driver to support the OCC on POWER8 and POWER9
processors. The OCC is an embedded processor that provides realtime power and
thermal monitoring and management.

This driver has two different platform drivers as a "base" for the
hwmon interface, as the means of communicating with the OCC on P8 and P9 is
completely different. For P8, the driver is an I2C client driver. For P9 the
driver is an FSI-based OCC client driver, and uses the OCC driver in-kernel
API. The OCC driver is on the LKML (latest 
https://lkml.org/lkml/2017/11/20/631).

Changes since v2:
 * Add sysfs_notify for the error and throttling attributes when change is
   detected.
 * Removed occs_present counting of devices bound.
 * Improved remove() of P9 driver to avoid bad behavior with relation to OCC
   driver when unbound.
 * Added default cases (return EINVAL) for all sensor show functions.
 * Added temperature fault sensor.
 * Added back dt binding documentation for P9 to address checkpatch warning.
 * Added occs_present attribute from the poll response.

Changes since v1:
 * Remove wait loop in P9 code, as that is now handled by FSI OCC driver.
 * Removed dt binding documentation for P9, FSI OCC driver will probe OCC hwmon
   driver automatically.
 * Moved OCC response code definitions to the OCC include file.
 * Fixed includes.
 * Changed some structure fields to __beXX as that is what they are.
 * Changed some errnos.
 * Removed some dev_err().
 * Refactored P8 code a bit to use #defined addresses and magic values, and
   changed "goto retry" to a loop.
 * Refactored error handling a bit.

Edward A. James (12):
  Documentation: hwmon: Add OCC documentation
  Documentation: ABI: Add occ-hwmon driver sysfs documentation
  dt-bindings: i2c: Add P8 OCC hwmon device documentation
  dt-bindings: fsi: Add P9 OCC hwmon device documentation
  hwmon (occ): Add On-Chip Controller (OCC) hwmon driver
  hwmon (occ): Add command transport method for P8 and P9
  hwmon (occ): Parse OCC poll response
  hwmon (occ): Add sensor types and versions
  hwmon (occ): Add sensor attributes and register hwmon device
  hwmon (occ): Add non-hwmon attributes
  hwmon (occ): Add error handling
  hwmon (occ): Add sysfs notification for errors and throttling

 Documentation/ABI/testing/sysfs-driver-occ-hwmon   |   85 ++
 .../devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt   |   16 +
 .../devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt   |   25 +
 Documentation/hwmon/occ|   75 ++
 drivers/hwmon/Kconfig  |2 +
 drivers/hwmon/Makefile |1 +
 drivers/hwmon/occ/Kconfig  |   28 +
 drivers/hwmon/occ/Makefile |   11 +
 drivers/hwmon/occ/common.c | 1387 
 drivers/hwmon/occ/common.h |  124 ++
 drivers/hwmon/occ/p8_i2c.c |  262 
 drivers/hwmon/occ/p9_sbe.c |  161 +++
 12 files changed, 2177 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-occ-hwmon
 create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
 create mode 100644 Documentation/hwmon/occ
 create mode 100644 drivers/hwmon/occ/Kconfig
 create mode 100644 drivers/hwmon/occ/Makefile
 create mode 100644 drivers/hwmon/occ/common.c
 create mode 100644 drivers/hwmon/occ/common.h
 create mode 100644 drivers/hwmon/occ/p8_i2c.c
 create mode 100644 drivers/hwmon/occ/p9_sbe.c

-- 
1.8.3.1

[PATCH v3 06/12] hwmon (occ): Add command transport method for P8 and P9

[Eddie James]

From: "Edward A. James" 

For the P8 OCC, add the procedure to send a command to the OCC over I2C
bus. This involves writing the OCC command registers with serial
communication operations (SCOMs) interpreted by the I2C slave. For the
P9 OCC, add a procedure to use the OCC in-kernel API to send a command
to the OCC through the SBE engine.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/p8_i2c.c | 185 -
 drivers/hwmon/occ/p9_sbe.c |  95 ++-
 2 files changed, 278 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/occ/p8_i2c.c b/drivers/hwmon/occ/p8_i2c.c
index 025471f..8032c0b 100644
--- a/drivers/hwmon/occ/p8_i2c.c
+++ b/drivers/hwmon/occ/p8_i2c.c
@@ -9,11 +9,29 @@
 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
+#include 
+#include 
 
 #include "common.h"
 
+#define OCC_TIMEOUT_MS 1000
+#define OCC_CMD_IN_PRG_WAIT_MS 50
+
+/* OCB (on-chip control bridge - interface to OCC) registers */
+#define OCB_DATA1  0x6B035
+#define OCB_ADDR   0x6B070
+#define OCB_DATA3  0x6B075
+
+/* OCC SRAM address space */
+#define OCC_SRAM_ADDR_CMD  0x6000
+#define OCC_SRAM_ADDR_RESP 0x7000
+
+#define OCC_DATA_ATTN  0x2001
+
 struct p8_i2c_occ {
struct occ occ;
struct i2c_client *client;
@@ -21,9 +39,174 @@ struct p8_i2c_occ {
 
 #define to_p8_i2c_occ(x)   container_of((x), struct p8_i2c_occ, occ)
 
+static int p8_i2c_occ_getscom(struct i2c_client *client, u32 address, u8 *data)
+{
+   ssize_t rc;
+   __be64 buf;
+   struct i2c_msg msgs[2];
+
+   /* p8 i2c slave requires shift */
+   address <<= 1;
+
+   msgs[0].addr = client->addr;
+   msgs[0].flags = client->flags & I2C_M_TEN;
+   msgs[0].len = sizeof(u32);
+   /* address is a scom address; bus-endian */
+   msgs[0].buf = (char *)
+
+   /* data from OCC is big-endian */
+   msgs[1].addr = client->addr;
+   msgs[1].flags = (client->flags & I2C_M_TEN) | I2C_M_RD;
+   msgs[1].len = sizeof(u64);
+   msgs[1].buf = (char *)
+
+   rc = i2c_transfer(client->adapter, msgs, 2);
+   if (rc < 0)
+   return rc;
+
+   *(u64 *)data = be64_to_cpu(buf);
+
+   return 0;
+}
+
+static int p8_i2c_occ_putscom(struct i2c_client *client, u32 address, u8 *data)
+{
+   u32 buf[3];
+   ssize_t rc;
+
+   /* p8 i2c slave requires shift */
+   address <<= 1;
+
+   /* address is bus-endian; data passed through from user as-is */
+   buf[0] = address;
+   memcpy([1], [4], sizeof(u32));
+   memcpy([2], data, sizeof(u32));
+
+   rc = i2c_master_send(client, (const char *)buf, sizeof(buf));
+   if (rc < 0)
+   return rc;
+   else if (rc != sizeof(buf))
+   return -EIO;
+
+   return 0;
+}
+
+static int p8_i2c_occ_putscom_u32(struct i2c_client *client, u32 address,
+ u32 data0, u32 data1)
+{
+   u8 buf[8];
+
+   memcpy(buf, , 4);
+   memcpy(buf + 4, , 4);
+
+   return p8_i2c_occ_putscom(client, address, buf);
+}
+
+static int p8_i2c_occ_putscom_be(struct i2c_client *client, u32 address,
+u8 *data)
+{
+   __be32 data0, data1;
+
+   memcpy(, data, 4);
+   memcpy(, data + 4, 4);
+
+   return p8_i2c_occ_putscom_u32(client, address, be32_to_cpu(data0),
+ be32_to_cpu(data1));
+}
+
 static int p8_i2c_occ_send_cmd(struct occ *occ, u8 *cmd)
 {
-   return -EOPNOTSUPP;
+   int i, rc;
+   unsigned long start;
+   u16 data_length;
+   const unsigned long timeout = msecs_to_jiffies(OCC_TIMEOUT_MS);
+   const long int wait_time = msecs_to_jiffies(OCC_CMD_IN_PRG_WAIT_MS);
+   struct p8_i2c_occ *p8_i2c_occ = to_p8_i2c_occ(occ);
+   struct i2c_client *client = p8_i2c_occ->client;
+   struct occ_response *resp = >resp;
+
+   start = jiffies;
+
+   /* set sram address for command */
+   rc = p8_i2c_occ_putscom_u32(client, OCB_ADDR, OCC_SRAM_ADDR_CMD, 0);
+   if (rc)
+   return rc;
+
+   /* write command (expected to already be BE), we need bus-endian... */
+   rc = p8_i2c_occ_putscom_be(client, OCB_DATA3, cmd);
+   if (rc)
+   return rc;
+
+   /* trigger OCC attention */
+   rc = p8_i2c_occ_putscom_u32(client, OCB_DATA1, OCC_DATA_ATTN, 0);
+   if (rc)
+   return rc;
+
+   do {
+   /* set sram address for response */
+   rc = p8_i2c_occ_putscom_u32(client, OCB_ADDR,
+   OCC_SRAM_ADDR_RESP, 0);
+   if (rc)
+   return rc;
+
+   rc = p8_i2c_occ_getscom(client, OCB_DATA3, (u8 *)resp);
+   if (rc)
+   return rc;

[PATCH v3 07/12] hwmon (occ): Parse OCC poll response

[Eddie James]

From: "Edward A. James" 

Add method to parse the response from the OCC poll command. This only
needs to be done during probe(), since the OCC shouldn't change the
number or format of sensors while it's running. The parsed response
allows quick access to sensor data, as well as information on the
number and version of sensors, which we need to instantiate hwmon
attributes.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/common.c | 50 ++
 drivers/hwmon/occ/common.h | 54 ++
 2 files changed, 104 insertions(+)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index 92f06ae..c55aec0 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 
 #include "common.h"
 
@@ -29,6 +30,53 @@ static int occ_poll(struct occ *occ)
return occ->send_cmd(occ, cmd);
 }
 
+/* only need to do this once at startup, as OCC won't change sensors on us */
+static void occ_parse_poll_response(struct occ *occ)
+{
+   unsigned int i, offset = 0, size = 0;
+   struct occ_sensor *sensor;
+   struct occ_sensors *sensors = >sensors;
+   struct occ_response *resp = >resp;
+   struct occ_poll_response *poll =
+   (struct occ_poll_response *)>data[0];
+   struct occ_poll_response_header *header = >header;
+   struct occ_sensor_data_block *block = >block;
+
+   for (i = 0; i < header->num_sensor_data_blocks; ++i) {
+   block = (struct occ_sensor_data_block *)((u8 *)block + offset);
+   offset = (block->header.num_sensors *
+ block->header.sensor_length) + sizeof(block->header);
+   size += offset;
+
+   /* validate all the length/size fields */
+   if ((size + sizeof(*header)) >= OCC_RESP_DATA_BYTES) {
+   dev_warn(occ->bus_dev, "exceeded response buffer\n");
+   return;
+   }
+
+   /* match sensor block type */
+   if (strncmp(block->header.eye_catcher, "TEMP", 4) == 0)
+   sensor = >temp;
+   else if (strncmp(block->header.eye_catcher, "FREQ", 4) == 0)
+   sensor = >freq;
+   else if (strncmp(block->header.eye_catcher, "POWR", 4) == 0)
+   sensor = >power;
+   else if (strncmp(block->header.eye_catcher, "CAPS", 4) == 0)
+   sensor = >caps;
+   else if (strncmp(block->header.eye_catcher, "EXTN", 4) == 0)
+   sensor = >extended;
+   else {
+   dev_warn(occ->bus_dev, "sensor not supported %.4s\n",
+block->header.eye_catcher);
+   continue;
+   }
+
+   sensor->num_sensors = block->header.num_sensors;
+   sensor->version = block->header.sensor_format;
+   sensor->data = >data;
+   }
+}
+
 int occ_setup(struct occ *occ, const char *name)
 {
int rc;
@@ -40,5 +88,7 @@ int occ_setup(struct occ *occ, const char *name)
return rc;
}
 
+   occ_parse_poll_response(occ);
+
return 0;
 }
diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
index 705dfe3..f52d45a 100644
--- a/drivers/hwmon/occ/common.h
+++ b/drivers/hwmon/occ/common.h
@@ -26,10 +26,64 @@ struct occ_response {
__be16 checksum;
 } __packed;
 
+struct occ_sensor_data_block_header {
+   u8 eye_catcher[4];
+   u8 reserved;
+   u8 sensor_format;
+   u8 sensor_length;
+   u8 num_sensors;
+} __packed;
+
+struct occ_sensor_data_block {
+   struct occ_sensor_data_block_header header;
+   u32 data;
+} __packed;
+
+struct occ_poll_response_header {
+   u8 status;
+   u8 ext_status;
+   u8 occs_present;
+   u8 config_data;
+   u8 occ_state;
+   u8 mode;
+   u8 ips_status;
+   u8 error_log_id;
+   __be32 error_log_start_address;
+   __be16 error_log_length;
+   u16 reserved;
+   u8 occ_code_level[16];
+   u8 eye_catcher[6];
+   u8 num_sensor_data_blocks;
+   u8 sensor_data_block_header_version;
+} __packed;
+
+struct occ_poll_response {
+   struct occ_poll_response_header header;
+   struct occ_sensor_data_block block;
+} __packed;
+
+struct occ_sensor {
+   u8 num_sensors;
+   u8 version;
+   void *data; /* pointer to sensor data start within response */
+};
+
+/* OCC only provides one sensor data block of each type, but any number of
+ * sensors within that block.
+ */
+struct occ_sensors {
+   struct occ_sensor temp;
+   struct occ_sensor freq;
+   struct occ_sensor power;
+   struct occ_sensor caps;
+   struct occ_sensor extended;
+};
+
 struct occ {
struct device *bus_dev;
 
struct occ_response resp;
+   struct occ_sensors 

[PATCH v3 00/12] hwmon: Add On-Chip Controller hwmon driver

[Eddie James]

From: "Edward A. James" 

This series adds a hwmon driver to support the OCC on POWER8 and POWER9
processors. The OCC is an embedded processor that provides realtime power and
thermal monitoring and management.

This driver has two different platform drivers as a "base" for the
hwmon interface, as the means of communicating with the OCC on P8 and P9 is
completely different. For P8, the driver is an I2C client driver. For P9 the
driver is an FSI-based OCC client driver, and uses the OCC driver in-kernel
API. The OCC driver is on the LKML (latest 
https://lkml.org/lkml/2017/11/20/631).

Changes since v2:
 * Add sysfs_notify for the error and throttling attributes when change is
   detected.
 * Removed occs_present counting of devices bound.
 * Improved remove() of P9 driver to avoid bad behavior with relation to OCC
   driver when unbound.
 * Added default cases (return EINVAL) for all sensor show functions.
 * Added temperature fault sensor.
 * Added back dt binding documentation for P9 to address checkpatch warning.
 * Added occs_present attribute from the poll response.

Changes since v1:
 * Remove wait loop in P9 code, as that is now handled by FSI OCC driver.
 * Removed dt binding documentation for P9, FSI OCC driver will probe OCC hwmon
   driver automatically.
 * Moved OCC response code definitions to the OCC include file.
 * Fixed includes.
 * Changed some structure fields to __beXX as that is what they are.
 * Changed some errnos.
 * Removed some dev_err().
 * Refactored P8 code a bit to use #defined addresses and magic values, and
   changed "goto retry" to a loop.
 * Refactored error handling a bit.

Edward A. James (12):
  Documentation: hwmon: Add OCC documentation
  Documentation: ABI: Add occ-hwmon driver sysfs documentation
  dt-bindings: i2c: Add P8 OCC hwmon device documentation
  dt-bindings: fsi: Add P9 OCC hwmon device documentation
  hwmon (occ): Add On-Chip Controller (OCC) hwmon driver
  hwmon (occ): Add command transport method for P8 and P9
  hwmon (occ): Parse OCC poll response
  hwmon (occ): Add sensor types and versions
  hwmon (occ): Add sensor attributes and register hwmon device
  hwmon (occ): Add non-hwmon attributes
  hwmon (occ): Add error handling
  hwmon (occ): Add sysfs notification for errors and throttling

 Documentation/ABI/testing/sysfs-driver-occ-hwmon   |   85 ++
 .../devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt   |   16 +
 .../devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt   |   25 +
 Documentation/hwmon/occ|   75 ++
 drivers/hwmon/Kconfig  |2 +
 drivers/hwmon/Makefile |1 +
 drivers/hwmon/occ/Kconfig  |   28 +
 drivers/hwmon/occ/Makefile |   11 +
 drivers/hwmon/occ/common.c | 1387 
 drivers/hwmon/occ/common.h |  124 ++
 drivers/hwmon/occ/p8_i2c.c |  262 
 drivers/hwmon/occ/p9_sbe.c |  161 +++
 12 files changed, 2177 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-occ-hwmon
 create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
 create mode 100644 Documentation/hwmon/occ
 create mode 100644 drivers/hwmon/occ/Kconfig
 create mode 100644 drivers/hwmon/occ/Makefile
 create mode 100644 drivers/hwmon/occ/common.c
 create mode 100644 drivers/hwmon/occ/common.h
 create mode 100644 drivers/hwmon/occ/p8_i2c.c
 create mode 100644 drivers/hwmon/occ/p9_sbe.c

-- 
1.8.3.1

[PATCH v3 06/12] hwmon (occ): Add command transport method for P8 and P9

[Eddie James]

From: "Edward A. James" 

For the P8 OCC, add the procedure to send a command to the OCC over I2C
bus. This involves writing the OCC command registers with serial
communication operations (SCOMs) interpreted by the I2C slave. For the
P9 OCC, add a procedure to use the OCC in-kernel API to send a command
to the OCC through the SBE engine.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/p8_i2c.c | 185 -
 drivers/hwmon/occ/p9_sbe.c |  95 ++-
 2 files changed, 278 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/occ/p8_i2c.c b/drivers/hwmon/occ/p8_i2c.c
index 025471f..8032c0b 100644
--- a/drivers/hwmon/occ/p8_i2c.c
+++ b/drivers/hwmon/occ/p8_i2c.c
@@ -9,11 +9,29 @@
 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
+#include 
+#include 
 
 #include "common.h"
 
+#define OCC_TIMEOUT_MS 1000
+#define OCC_CMD_IN_PRG_WAIT_MS 50
+
+/* OCB (on-chip control bridge - interface to OCC) registers */
+#define OCB_DATA1  0x6B035
+#define OCB_ADDR   0x6B070
+#define OCB_DATA3  0x6B075
+
+/* OCC SRAM address space */
+#define OCC_SRAM_ADDR_CMD  0x6000
+#define OCC_SRAM_ADDR_RESP 0x7000
+
+#define OCC_DATA_ATTN  0x2001
+
 struct p8_i2c_occ {
struct occ occ;
struct i2c_client *client;
@@ -21,9 +39,174 @@ struct p8_i2c_occ {
 
 #define to_p8_i2c_occ(x)   container_of((x), struct p8_i2c_occ, occ)
 
+static int p8_i2c_occ_getscom(struct i2c_client *client, u32 address, u8 *data)
+{
+   ssize_t rc;
+   __be64 buf;
+   struct i2c_msg msgs[2];
+
+   /* p8 i2c slave requires shift */
+   address <<= 1;
+
+   msgs[0].addr = client->addr;
+   msgs[0].flags = client->flags & I2C_M_TEN;
+   msgs[0].len = sizeof(u32);
+   /* address is a scom address; bus-endian */
+   msgs[0].buf = (char *)
+
+   /* data from OCC is big-endian */
+   msgs[1].addr = client->addr;
+   msgs[1].flags = (client->flags & I2C_M_TEN) | I2C_M_RD;
+   msgs[1].len = sizeof(u64);
+   msgs[1].buf = (char *)
+
+   rc = i2c_transfer(client->adapter, msgs, 2);
+   if (rc < 0)
+   return rc;
+
+   *(u64 *)data = be64_to_cpu(buf);
+
+   return 0;
+}
+
+static int p8_i2c_occ_putscom(struct i2c_client *client, u32 address, u8 *data)
+{
+   u32 buf[3];
+   ssize_t rc;
+
+   /* p8 i2c slave requires shift */
+   address <<= 1;
+
+   /* address is bus-endian; data passed through from user as-is */
+   buf[0] = address;
+   memcpy([1], [4], sizeof(u32));
+   memcpy([2], data, sizeof(u32));
+
+   rc = i2c_master_send(client, (const char *)buf, sizeof(buf));
+   if (rc < 0)
+   return rc;
+   else if (rc != sizeof(buf))
+   return -EIO;
+
+   return 0;
+}
+
+static int p8_i2c_occ_putscom_u32(struct i2c_client *client, u32 address,
+ u32 data0, u32 data1)
+{
+   u8 buf[8];
+
+   memcpy(buf, , 4);
+   memcpy(buf + 4, , 4);
+
+   return p8_i2c_occ_putscom(client, address, buf);
+}
+
+static int p8_i2c_occ_putscom_be(struct i2c_client *client, u32 address,
+u8 *data)
+{
+   __be32 data0, data1;
+
+   memcpy(, data, 4);
+   memcpy(, data + 4, 4);
+
+   return p8_i2c_occ_putscom_u32(client, address, be32_to_cpu(data0),
+ be32_to_cpu(data1));
+}
+
 static int p8_i2c_occ_send_cmd(struct occ *occ, u8 *cmd)
 {
-   return -EOPNOTSUPP;
+   int i, rc;
+   unsigned long start;
+   u16 data_length;
+   const unsigned long timeout = msecs_to_jiffies(OCC_TIMEOUT_MS);
+   const long int wait_time = msecs_to_jiffies(OCC_CMD_IN_PRG_WAIT_MS);
+   struct p8_i2c_occ *p8_i2c_occ = to_p8_i2c_occ(occ);
+   struct i2c_client *client = p8_i2c_occ->client;
+   struct occ_response *resp = >resp;
+
+   start = jiffies;
+
+   /* set sram address for command */
+   rc = p8_i2c_occ_putscom_u32(client, OCB_ADDR, OCC_SRAM_ADDR_CMD, 0);
+   if (rc)
+   return rc;
+
+   /* write command (expected to already be BE), we need bus-endian... */
+   rc = p8_i2c_occ_putscom_be(client, OCB_DATA3, cmd);
+   if (rc)
+   return rc;
+
+   /* trigger OCC attention */
+   rc = p8_i2c_occ_putscom_u32(client, OCB_DATA1, OCC_DATA_ATTN, 0);
+   if (rc)
+   return rc;
+
+   do {
+   /* set sram address for response */
+   rc = p8_i2c_occ_putscom_u32(client, OCB_ADDR,
+   OCC_SRAM_ADDR_RESP, 0);
+   if (rc)
+   return rc;
+
+   rc = p8_i2c_occ_getscom(client, OCB_DATA3, (u8 *)resp);
+   if (rc)
+   return rc;
+
+   /* wait for OCC */
+  

[PATCH v3 01/12] Documentation: hwmon: Add OCC documentation

[Eddie James]

From: "Edward A. James" 

Document the hwmon interface for the OCC.

Signed-off-by: Edward A. James 
---
 Documentation/hwmon/occ | 75 +
 1 file changed, 75 insertions(+)
 create mode 100644 Documentation/hwmon/occ

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
new file mode 100644
index 000..c88d0f5
--- /dev/null
+++ b/Documentation/hwmon/occ
@@ -0,0 +1,75 @@
+Kernel driver occ-hwmon
+===
+
+Supported chips:
+  * POWER8
+  * POWER9
+
+Author: Eddie James 
+
+Description
+---
+
+This driver supports hardware monitoring for the On-Chip Controller (OCC)
+embedded on POWER processors. The OCC is a device that collects and aggregates
+sensor data from the processor and the system. The OCC can provide the raw
+sensor data as well as perform thermal and power management on the system.
+
+The P8 version of this driver is a client driver of I2C. It may be probed
+manually if an "ibm,p8-occ-hwmon" compatible device is found under the
+appropriate I2C bus node in the device-tree.
+
+The P9 version of this driver is a client driver of the FSI-based OCC driver.
+It will be probed automatically by the FSI-based OCC driver. Please see the
+device-tree bindings documentation for that driver for details on probing
+an OCC device (Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt).
+
+Sysfs entries
+-
+
+The following attributes are supported. All attributes are read-only unless
+specified.
+
+temp[1-n]_labelOCC sensor id.
+temp[1-n]_inputMeasured temperature in millidegrees C.
+[with temperature sensor version 2+]
+temp[1-n]_fru_type Given FRU (Field Replaceable Unit) type.
+temp[1-n]_faultTemperature sensor fault.
+
+freq[1-n]_labelOCC sensor id.
+freq[1-n]_inputMeasured frequency.
+
+power[1-n]_label   OCC sensor id.
+power[1-n]_input   Measured power in microwatts.
+power[1-n]_update_tag  Number of 250us samples represented in accumulator.
+power[1-n]_accumulator Accumulation of 250us power readings.
+[with power sensor version 2+]
+power[1-n]_function_id Identifies what the power reading is for.
+power[1-n]_apss_channelIndicates APSS channel.
+
+[power version 0xa0 only]
+power1_id  OCC sensor id.
+power[1-n]_label   Sensor type, "system", "proc", "vdd", or "vdn".
+power[1-n]_input   Most recent power reading in microwatts.
+power[1-n]_update_tag  Number of samples in the accumulator.
+power[1-n]_accumulator Accumulation of power readings.
+[with sensor type "system" and "proc" only]
+power[1-n]_update_time Time in us that the power value is read.
+
+caps1_current  Current OCC power cap in watts.
+caps1_reading  Current system output power in watts.
+caps1_norm Power cap without redundant power.
+caps1_max  Maximum power cap.
+[caps version 1 and 2 only]
+caps1_min  Minimum power cap.
+[caps version 3+]
+caps1_min_hard Hard minimum cap that can be set and held.
+caps1_min_soft Soft minimum cap below hard, not guaranteed.
+caps1_user The powercap specified by the user. Will be 0 if no
+   user powercap exists. This attribute is read-write.
+[caps version 1+]
+caps1_user_source  Indicates how the user power limit was set.
+
+extn[1-n]_labelASCII id or sensor id.
+extn[1-n]_flagsIndicates type of label attribute.
+extn[1-n]_inputData.
-- 
1.8.3.1

[PATCH v3 01/12] Documentation: hwmon: Add OCC documentation

[Eddie James]

From: "Edward A. James" 

Document the hwmon interface for the OCC.

Signed-off-by: Edward A. James 
---
 Documentation/hwmon/occ | 75 +
 1 file changed, 75 insertions(+)
 create mode 100644 Documentation/hwmon/occ

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
new file mode 100644
index 000..c88d0f5
--- /dev/null
+++ b/Documentation/hwmon/occ
@@ -0,0 +1,75 @@
+Kernel driver occ-hwmon
+===
+
+Supported chips:
+  * POWER8
+  * POWER9
+
+Author: Eddie James 
+
+Description
+---
+
+This driver supports hardware monitoring for the On-Chip Controller (OCC)
+embedded on POWER processors. The OCC is a device that collects and aggregates
+sensor data from the processor and the system. The OCC can provide the raw
+sensor data as well as perform thermal and power management on the system.
+
+The P8 version of this driver is a client driver of I2C. It may be probed
+manually if an "ibm,p8-occ-hwmon" compatible device is found under the
+appropriate I2C bus node in the device-tree.
+
+The P9 version of this driver is a client driver of the FSI-based OCC driver.
+It will be probed automatically by the FSI-based OCC driver. Please see the
+device-tree bindings documentation for that driver for details on probing
+an OCC device (Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt).
+
+Sysfs entries
+-
+
+The following attributes are supported. All attributes are read-only unless
+specified.
+
+temp[1-n]_labelOCC sensor id.
+temp[1-n]_inputMeasured temperature in millidegrees C.
+[with temperature sensor version 2+]
+temp[1-n]_fru_type Given FRU (Field Replaceable Unit) type.
+temp[1-n]_faultTemperature sensor fault.
+
+freq[1-n]_labelOCC sensor id.
+freq[1-n]_inputMeasured frequency.
+
+power[1-n]_label   OCC sensor id.
+power[1-n]_input   Measured power in microwatts.
+power[1-n]_update_tag  Number of 250us samples represented in accumulator.
+power[1-n]_accumulator Accumulation of 250us power readings.
+[with power sensor version 2+]
+power[1-n]_function_id Identifies what the power reading is for.
+power[1-n]_apss_channelIndicates APSS channel.
+
+[power version 0xa0 only]
+power1_id  OCC sensor id.
+power[1-n]_label   Sensor type, "system", "proc", "vdd", or "vdn".
+power[1-n]_input   Most recent power reading in microwatts.
+power[1-n]_update_tag  Number of samples in the accumulator.
+power[1-n]_accumulator Accumulation of power readings.
+[with sensor type "system" and "proc" only]
+power[1-n]_update_time Time in us that the power value is read.
+
+caps1_current  Current OCC power cap in watts.
+caps1_reading  Current system output power in watts.
+caps1_norm Power cap without redundant power.
+caps1_max  Maximum power cap.
+[caps version 1 and 2 only]
+caps1_min  Minimum power cap.
+[caps version 3+]
+caps1_min_hard Hard minimum cap that can be set and held.
+caps1_min_soft Soft minimum cap below hard, not guaranteed.
+caps1_user The powercap specified by the user. Will be 0 if no
+   user powercap exists. This attribute is read-write.
+[caps version 1+]
+caps1_user_source  Indicates how the user power limit was set.
+
+extn[1-n]_labelASCII id or sensor id.
+extn[1-n]_flagsIndicates type of label attribute.
+extn[1-n]_inputData.
-- 
1.8.3.1

[PATCH v3 10/12] hwmon (occ): Add non-hwmon attributes

[Eddie James]

From: "Edward A. James" 

Create device attributes for additional OCC properties that do not
belong as hwmon sensors. These provide additional information as to the
state of the processor and system.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/common.c | 93 ++
 drivers/hwmon/occ/common.h |  1 +
 drivers/hwmon/occ/p8_i2c.c | 10 +
 drivers/hwmon/occ/p9_sbe.c |  2 +
 4 files changed, 106 insertions(+)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index 337f286b..53e3592 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -24,6 +24,14 @@
 
 #define OCC_FRU_TYPE_VRM   0x3
 
+/* OCC status bits */
+#define OCC_STAT_MASTER0x80
+#define OCC_STAT_ACTIVE0x01
+#define OCC_EXT_STAT_DVFS_OT   0x80
+#define OCC_EXT_STAT_DVFS_POWER0x40
+#define OCC_EXT_STAT_MEM_THROTTLE  0x20
+#define OCC_EXT_STAT_QUICK_DROP0x10
+
 /* OCC sensor type and version definitions */
 
 struct temp_sensor_1 {
@@ -1108,6 +1116,81 @@ static int occ_setup_sensor_attrs(struct occ *occ)
return 0;
 }
 
+static ssize_t occ_show_status(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   int rc;
+   int val = 0;
+   struct occ *occ = dev_get_drvdata(dev);
+   struct occ_poll_response_header *header;
+   struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
+
+   rc = occ_update_response(occ);
+   if (rc)
+   return rc;
+
+   header = (struct occ_poll_response_header *)occ->resp.data;
+
+   switch (sattr->index) {
+   case 0:
+   val = (header->status & OCC_STAT_MASTER) ? 1 : 0;
+   break;
+   case 1:
+   val = (header->status & OCC_STAT_ACTIVE) ? 1 : 0;
+   break;
+   case 2:
+   val = (header->ext_status & OCC_EXT_STAT_DVFS_OT) ? 1 : 0;
+   break;
+   case 3:
+   val = (header->ext_status & OCC_EXT_STAT_DVFS_POWER) ? 1 : 0;
+   break;
+   case 4:
+   val = (header->ext_status & OCC_EXT_STAT_MEM_THROTTLE) ? 1 : 0;
+   break;
+   case 5:
+   val = (header->ext_status & OCC_EXT_STAT_QUICK_DROP) ? 1 : 0;
+   break;
+   case 6:
+   val = header->occ_state;
+   break;
+   case 7:
+   if (header->status & OCC_STAT_MASTER)
+   val = hweight8(header->occs_present);
+   else
+   val = 1;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return snprintf(buf, PAGE_SIZE - 1, "%d\n", val);
+}
+
+static SENSOR_DEVICE_ATTR(occ_master, 0444, occ_show_status, NULL, 0);
+static SENSOR_DEVICE_ATTR(occ_active, 0444, occ_show_status, NULL, 1);
+static SENSOR_DEVICE_ATTR(occ_dvfs_ot, 0444, occ_show_status, NULL, 2);
+static SENSOR_DEVICE_ATTR(occ_dvfs_power, 0444, occ_show_status, NULL, 3);
+static SENSOR_DEVICE_ATTR(occ_mem_throttle, 0444, occ_show_status, NULL, 4);
+static SENSOR_DEVICE_ATTR(occ_quick_drop, 0444, occ_show_status, NULL, 5);
+static SENSOR_DEVICE_ATTR(occ_status, 0444, occ_show_status, NULL, 6);
+static SENSOR_DEVICE_ATTR(occs_present, 0444, occ_show_status, NULL, 7);
+
+static struct attribute *occ_attributes[] = {
+   _dev_attr_occ_master.dev_attr.attr,
+   _dev_attr_occ_active.dev_attr.attr,
+   _dev_attr_occ_dvfs_ot.dev_attr.attr,
+   _dev_attr_occ_dvfs_power.dev_attr.attr,
+   _dev_attr_occ_mem_throttle.dev_attr.attr,
+   _dev_attr_occ_quick_drop.dev_attr.attr,
+   _dev_attr_occ_status.dev_attr.attr,
+   _dev_attr_occs_present.dev_attr.attr,
+   NULL
+};
+
+static const struct attribute_group occ_attr_group = {
+   .attrs = occ_attributes,
+};
+
 /* only need to do this once at startup, as OCC won't change sensors on us */
 static void occ_parse_poll_response(struct occ *occ)
 {
@@ -1188,5 +1271,15 @@ int occ_setup(struct occ *occ, const char *name)
return rc;
}
 
+   rc = sysfs_create_group(>bus_dev->kobj, _attr_group);
+   if (rc)
+   dev_warn(occ->bus_dev, "failed to create status attrs: %d\n",
+rc);
+
return 0;
 }
+
+void occ_shutdown(struct occ *occ)
+{
+   sysfs_remove_group(>bus_dev->kobj, _attr_group);
+}
diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
index 049c3b4..dc9e06d 100644
--- a/drivers/hwmon/occ/common.h
+++ b/drivers/hwmon/occ/common.h
@@ -110,5 +110,6 @@ struct occ {
 };
 
 int occ_setup(struct occ *occ, const char *name);
+void occ_shutdown(struct occ *occ);
 
 #endif /* OCC_COMMON_H */
diff --git a/drivers/hwmon/occ/p8_i2c.c b/drivers/hwmon/occ/p8_i2c.c
index 8032c0b..d719632 100644
--- a/drivers/hwmon/occ/p8_i2c.c
+++ 

[PATCH v3 04/12] dt-bindings: fsi: Add P9 OCC hwmon device documentation

[Eddie James]

From: "Edward A. James" 

Document the bindings for the FSI-based OCC hwmon device.

Signed-off-by: Edward A. James 
---
 .../devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt

diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt 
b/Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
new file mode 100644
index 000..086b1eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
@@ -0,0 +1,16 @@
+Device-tree bindings for FSI-based On-Chip Controller hwmon device
+--
+
+Required properties:
+ - compatible = "ibm,p9-occ-hwmon";
+
+Examples:
+
+occ@1 {
+compatible = "ibm,p9-occ";
+reg = <1>;
+
+occ-hwmon@1 {
+compatible = "ibm,p9-occ-hmwon";
+}
+};
-- 
1.8.3.1

[PATCH v3 10/12] hwmon (occ): Add non-hwmon attributes

[Eddie James]

From: "Edward A. James" 

Create device attributes for additional OCC properties that do not
belong as hwmon sensors. These provide additional information as to the
state of the processor and system.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/common.c | 93 ++
 drivers/hwmon/occ/common.h |  1 +
 drivers/hwmon/occ/p8_i2c.c | 10 +
 drivers/hwmon/occ/p9_sbe.c |  2 +
 4 files changed, 106 insertions(+)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index 337f286b..53e3592 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -24,6 +24,14 @@
 
 #define OCC_FRU_TYPE_VRM   0x3
 
+/* OCC status bits */
+#define OCC_STAT_MASTER0x80
+#define OCC_STAT_ACTIVE0x01
+#define OCC_EXT_STAT_DVFS_OT   0x80
+#define OCC_EXT_STAT_DVFS_POWER0x40
+#define OCC_EXT_STAT_MEM_THROTTLE  0x20
+#define OCC_EXT_STAT_QUICK_DROP0x10
+
 /* OCC sensor type and version definitions */
 
 struct temp_sensor_1 {
@@ -1108,6 +1116,81 @@ static int occ_setup_sensor_attrs(struct occ *occ)
return 0;
 }
 
+static ssize_t occ_show_status(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   int rc;
+   int val = 0;
+   struct occ *occ = dev_get_drvdata(dev);
+   struct occ_poll_response_header *header;
+   struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
+
+   rc = occ_update_response(occ);
+   if (rc)
+   return rc;
+
+   header = (struct occ_poll_response_header *)occ->resp.data;
+
+   switch (sattr->index) {
+   case 0:
+   val = (header->status & OCC_STAT_MASTER) ? 1 : 0;
+   break;
+   case 1:
+   val = (header->status & OCC_STAT_ACTIVE) ? 1 : 0;
+   break;
+   case 2:
+   val = (header->ext_status & OCC_EXT_STAT_DVFS_OT) ? 1 : 0;
+   break;
+   case 3:
+   val = (header->ext_status & OCC_EXT_STAT_DVFS_POWER) ? 1 : 0;
+   break;
+   case 4:
+   val = (header->ext_status & OCC_EXT_STAT_MEM_THROTTLE) ? 1 : 0;
+   break;
+   case 5:
+   val = (header->ext_status & OCC_EXT_STAT_QUICK_DROP) ? 1 : 0;
+   break;
+   case 6:
+   val = header->occ_state;
+   break;
+   case 7:
+   if (header->status & OCC_STAT_MASTER)
+   val = hweight8(header->occs_present);
+   else
+   val = 1;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return snprintf(buf, PAGE_SIZE - 1, "%d\n", val);
+}
+
+static SENSOR_DEVICE_ATTR(occ_master, 0444, occ_show_status, NULL, 0);
+static SENSOR_DEVICE_ATTR(occ_active, 0444, occ_show_status, NULL, 1);
+static SENSOR_DEVICE_ATTR(occ_dvfs_ot, 0444, occ_show_status, NULL, 2);
+static SENSOR_DEVICE_ATTR(occ_dvfs_power, 0444, occ_show_status, NULL, 3);
+static SENSOR_DEVICE_ATTR(occ_mem_throttle, 0444, occ_show_status, NULL, 4);
+static SENSOR_DEVICE_ATTR(occ_quick_drop, 0444, occ_show_status, NULL, 5);
+static SENSOR_DEVICE_ATTR(occ_status, 0444, occ_show_status, NULL, 6);
+static SENSOR_DEVICE_ATTR(occs_present, 0444, occ_show_status, NULL, 7);
+
+static struct attribute *occ_attributes[] = {
+   _dev_attr_occ_master.dev_attr.attr,
+   _dev_attr_occ_active.dev_attr.attr,
+   _dev_attr_occ_dvfs_ot.dev_attr.attr,
+   _dev_attr_occ_dvfs_power.dev_attr.attr,
+   _dev_attr_occ_mem_throttle.dev_attr.attr,
+   _dev_attr_occ_quick_drop.dev_attr.attr,
+   _dev_attr_occ_status.dev_attr.attr,
+   _dev_attr_occs_present.dev_attr.attr,
+   NULL
+};
+
+static const struct attribute_group occ_attr_group = {
+   .attrs = occ_attributes,
+};
+
 /* only need to do this once at startup, as OCC won't change sensors on us */
 static void occ_parse_poll_response(struct occ *occ)
 {
@@ -1188,5 +1271,15 @@ int occ_setup(struct occ *occ, const char *name)
return rc;
}
 
+   rc = sysfs_create_group(>bus_dev->kobj, _attr_group);
+   if (rc)
+   dev_warn(occ->bus_dev, "failed to create status attrs: %d\n",
+rc);
+
return 0;
 }
+
+void occ_shutdown(struct occ *occ)
+{
+   sysfs_remove_group(>bus_dev->kobj, _attr_group);
+}
diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
index 049c3b4..dc9e06d 100644
--- a/drivers/hwmon/occ/common.h
+++ b/drivers/hwmon/occ/common.h
@@ -110,5 +110,6 @@ struct occ {
 };
 
 int occ_setup(struct occ *occ, const char *name);
+void occ_shutdown(struct occ *occ);
 
 #endif /* OCC_COMMON_H */
diff --git a/drivers/hwmon/occ/p8_i2c.c b/drivers/hwmon/occ/p8_i2c.c
index 8032c0b..d719632 100644
--- a/drivers/hwmon/occ/p8_i2c.c
+++ b/drivers/hwmon/occ/p8_i2c.c
@@ -230,6 +230,15 @@ 

[PATCH v3 04/12] dt-bindings: fsi: Add P9 OCC hwmon device documentation

[Eddie James]

From: "Edward A. James" 

Document the bindings for the FSI-based OCC hwmon device.

Signed-off-by: Edward A. James 
---
 .../devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt

diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt 
b/Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
new file mode 100644
index 000..086b1eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
@@ -0,0 +1,16 @@
+Device-tree bindings for FSI-based On-Chip Controller hwmon device
+--
+
+Required properties:
+ - compatible = "ibm,p9-occ-hwmon";
+
+Examples:
+
+occ@1 {
+compatible = "ibm,p9-occ";
+reg = <1>;
+
+occ-hwmon@1 {
+compatible = "ibm,p9-occ-hmwon";
+}
+};
-- 
1.8.3.1

[PATCH v3 08/12] hwmon (occ): Add sensor types and versions

[Eddie James]

From: "Edward A. James" 

Add structures to define all sensor types and versions. Add sysfs show
and store functions for each sensor type. Add a method to construct the
"set user power cap" command and send it to the OCC. Add rate limit to
polling the OCC (in case user-space reads our hwmon entries rapidly).

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/common.c | 648 +
 drivers/hwmon/occ/common.h |   5 +
 2 files changed, 653 insertions(+)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index c55aec0..7783019 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -8,10 +8,119 @@
  */
 
 #include 
+#include 
+#include 
 #include 
+#include 
+#include 
 
 #include "common.h"
 
+#define OCC_UPDATE_FREQUENCY   msecs_to_jiffies(1000)
+
+#define OCC_TEMP_SENSOR_FAULT  0xFF
+
+#define OCC_FRU_TYPE_VRM   0x3
+
+/* OCC sensor type and version definitions */
+
+struct temp_sensor_1 {
+   u16 sensor_id;
+   u16 value;
+} __packed;
+
+struct temp_sensor_2 {
+   u32 sensor_id;
+   u8 fru_type;
+   u8 value;
+} __packed;
+
+struct freq_sensor_1 {
+   u16 sensor_id;
+   u16 value;
+} __packed;
+
+struct freq_sensor_2 {
+   u32 sensor_id;
+   u16 value;
+} __packed;
+
+struct power_sensor_1 {
+   u16 sensor_id;
+   u32 update_tag;
+   u32 accumulator;
+   u16 value;
+} __packed;
+
+struct power_sensor_2 {
+   u32 sensor_id;
+   u8 function_id;
+   u8 apss_channel;
+   u16 reserved;
+   u32 update_tag;
+   u64 accumulator;
+   u16 value;
+} __packed;
+
+struct power_sensor_data {
+   u16 value;
+   u32 update_tag;
+   u64 accumulator;
+} __packed;
+
+struct power_sensor_data_and_time {
+   u16 update_time;
+   u16 value;
+   u32 update_tag;
+   u64 accumulator;
+} __packed;
+
+struct power_sensor_a0 {
+   u32 sensor_id;
+   struct power_sensor_data_and_time system;
+   u32 reserved;
+   struct power_sensor_data_and_time proc;
+   struct power_sensor_data vdd;
+   struct power_sensor_data vdn;
+} __packed;
+
+struct caps_sensor_1 {
+   u16 curr_powercap;
+   u16 curr_powerreading;
+   u16 norm_powercap;
+   u16 max_powercap;
+   u16 min_powercap;
+   u16 user_powerlimit;
+} __packed;
+
+struct caps_sensor_2 {
+   u16 curr_powercap;
+   u16 curr_powerreading;
+   u16 norm_powercap;
+   u16 max_powercap;
+   u16 min_powercap;
+   u16 user_powerlimit;
+   u8 user_powerlimit_source;
+} __packed;
+
+struct caps_sensor_3 {
+   u16 curr_powercap;
+   u16 curr_powerreading;
+   u16 norm_powercap;
+   u16 max_powercap;
+   u16 hard_min_powercap;
+   u16 soft_min_powercap;
+   u16 user_powerlimit;
+   u8 user_powerlimit_source;
+} __packed;
+
+struct extended_sensor {
+   u8 name[4];
+   u8 flags;
+   u8 reserved;
+   u8 data[6];
+} __packed;
+
 static int occ_poll(struct occ *occ)
 {
u16 checksum = occ->poll_cmd_data + 1;
@@ -27,9 +136,545 @@ static int occ_poll(struct occ *occ)
cmd[6] = checksum & 0xFF;   /* checksum lsb */
cmd[7] = 0;
 
+   /* mutex should already be locked if necessary */
return occ->send_cmd(occ, cmd);
 }
 
+static int occ_set_user_power_cap(struct occ *occ, u16 user_power_cap)
+{
+   int rc;
+   u8 cmd[8];
+   u16 checksum = 0x24;
+   __be16 user_power_cap_be = cpu_to_be16(user_power_cap);
+
+   cmd[0] = 0;
+   cmd[1] = 0x22;
+   cmd[2] = 0;
+   cmd[3] = 2;
+
+   memcpy([4], _power_cap_be, 2);
+
+   checksum += cmd[4] + cmd[5];
+   cmd[6] = checksum >> 8;
+   cmd[7] = checksum & 0xFF;
+
+   rc = mutex_lock_interruptible(>lock);
+   if (rc)
+   return rc;
+
+   rc = occ->send_cmd(occ, cmd);
+
+   mutex_unlock(>lock);
+
+   return rc;
+}
+
+static int occ_update_response(struct occ *occ)
+{
+   int rc = mutex_lock_interruptible(>lock);
+
+   if (rc)
+   return rc;
+
+   /* limit the maximum rate of polling the OCC */
+   if (time_after(jiffies, occ->last_update + OCC_UPDATE_FREQUENCY)) {
+   rc = occ_poll(occ);
+   occ->last_update = jiffies;
+   }
+
+   mutex_unlock(>lock);
+   return rc;
+}
+
+static ssize_t occ_show_temp_1(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   int rc;
+   u16 val = 0;
+   struct temp_sensor_1 *temp;
+   struct occ *occ = dev_get_drvdata(dev);
+   struct occ_sensors *sensors = >sensors;
+   struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+
+   rc = occ_update_response(occ);
+   if (rc)
+   return rc;
+
+   temp = ((struct temp_sensor_1 *)sensors->temp.data) + sattr->index;
+
+   switch 

[PATCH v3 08/12] hwmon (occ): Add sensor types and versions

[Eddie James]

From: "Edward A. James" 

Add structures to define all sensor types and versions. Add sysfs show
and store functions for each sensor type. Add a method to construct the
"set user power cap" command and send it to the OCC. Add rate limit to
polling the OCC (in case user-space reads our hwmon entries rapidly).

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/common.c | 648 +
 drivers/hwmon/occ/common.h |   5 +
 2 files changed, 653 insertions(+)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index c55aec0..7783019 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -8,10 +8,119 @@
  */
 
 #include 
+#include 
+#include 
 #include 
+#include 
+#include 
 
 #include "common.h"
 
+#define OCC_UPDATE_FREQUENCY   msecs_to_jiffies(1000)
+
+#define OCC_TEMP_SENSOR_FAULT  0xFF
+
+#define OCC_FRU_TYPE_VRM   0x3
+
+/* OCC sensor type and version definitions */
+
+struct temp_sensor_1 {
+   u16 sensor_id;
+   u16 value;
+} __packed;
+
+struct temp_sensor_2 {
+   u32 sensor_id;
+   u8 fru_type;
+   u8 value;
+} __packed;
+
+struct freq_sensor_1 {
+   u16 sensor_id;
+   u16 value;
+} __packed;
+
+struct freq_sensor_2 {
+   u32 sensor_id;
+   u16 value;
+} __packed;
+
+struct power_sensor_1 {
+   u16 sensor_id;
+   u32 update_tag;
+   u32 accumulator;
+   u16 value;
+} __packed;
+
+struct power_sensor_2 {
+   u32 sensor_id;
+   u8 function_id;
+   u8 apss_channel;
+   u16 reserved;
+   u32 update_tag;
+   u64 accumulator;
+   u16 value;
+} __packed;
+
+struct power_sensor_data {
+   u16 value;
+   u32 update_tag;
+   u64 accumulator;
+} __packed;
+
+struct power_sensor_data_and_time {
+   u16 update_time;
+   u16 value;
+   u32 update_tag;
+   u64 accumulator;
+} __packed;
+
+struct power_sensor_a0 {
+   u32 sensor_id;
+   struct power_sensor_data_and_time system;
+   u32 reserved;
+   struct power_sensor_data_and_time proc;
+   struct power_sensor_data vdd;
+   struct power_sensor_data vdn;
+} __packed;
+
+struct caps_sensor_1 {
+   u16 curr_powercap;
+   u16 curr_powerreading;
+   u16 norm_powercap;
+   u16 max_powercap;
+   u16 min_powercap;
+   u16 user_powerlimit;
+} __packed;
+
+struct caps_sensor_2 {
+   u16 curr_powercap;
+   u16 curr_powerreading;
+   u16 norm_powercap;
+   u16 max_powercap;
+   u16 min_powercap;
+   u16 user_powerlimit;
+   u8 user_powerlimit_source;
+} __packed;
+
+struct caps_sensor_3 {
+   u16 curr_powercap;
+   u16 curr_powerreading;
+   u16 norm_powercap;
+   u16 max_powercap;
+   u16 hard_min_powercap;
+   u16 soft_min_powercap;
+   u16 user_powerlimit;
+   u8 user_powerlimit_source;
+} __packed;
+
+struct extended_sensor {
+   u8 name[4];
+   u8 flags;
+   u8 reserved;
+   u8 data[6];
+} __packed;
+
 static int occ_poll(struct occ *occ)
 {
u16 checksum = occ->poll_cmd_data + 1;
@@ -27,9 +136,545 @@ static int occ_poll(struct occ *occ)
cmd[6] = checksum & 0xFF;   /* checksum lsb */
cmd[7] = 0;
 
+   /* mutex should already be locked if necessary */
return occ->send_cmd(occ, cmd);
 }
 
+static int occ_set_user_power_cap(struct occ *occ, u16 user_power_cap)
+{
+   int rc;
+   u8 cmd[8];
+   u16 checksum = 0x24;
+   __be16 user_power_cap_be = cpu_to_be16(user_power_cap);
+
+   cmd[0] = 0;
+   cmd[1] = 0x22;
+   cmd[2] = 0;
+   cmd[3] = 2;
+
+   memcpy([4], _power_cap_be, 2);
+
+   checksum += cmd[4] + cmd[5];
+   cmd[6] = checksum >> 8;
+   cmd[7] = checksum & 0xFF;
+
+   rc = mutex_lock_interruptible(>lock);
+   if (rc)
+   return rc;
+
+   rc = occ->send_cmd(occ, cmd);
+
+   mutex_unlock(>lock);
+
+   return rc;
+}
+
+static int occ_update_response(struct occ *occ)
+{
+   int rc = mutex_lock_interruptible(>lock);
+
+   if (rc)
+   return rc;
+
+   /* limit the maximum rate of polling the OCC */
+   if (time_after(jiffies, occ->last_update + OCC_UPDATE_FREQUENCY)) {
+   rc = occ_poll(occ);
+   occ->last_update = jiffies;
+   }
+
+   mutex_unlock(>lock);
+   return rc;
+}
+
+static ssize_t occ_show_temp_1(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   int rc;
+   u16 val = 0;
+   struct temp_sensor_1 *temp;
+   struct occ *occ = dev_get_drvdata(dev);
+   struct occ_sensors *sensors = >sensors;
+   struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+
+   rc = occ_update_response(occ);
+   if (rc)
+   return rc;
+
+   temp = ((struct temp_sensor_1 *)sensors->temp.data) + sattr->index;
+
+   switch (sattr->nr) {
+   case 0:
+ 

[PATCH v3 11/12] hwmon (occ): Add error handling

[Eddie James]

From: "Edward A. James" 

Add logic to detect a number of error scenarios on the OCC. Export any
errors through an additional non-hwmon device attribute. The error
counting and state verification are required by the OCC hardware
specification.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/common.c | 55 +-
 drivers/hwmon/occ/common.h |  4 
 2 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index 53e3592..7a0606d 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -18,6 +18,11 @@
 
 #include "common.h"
 
+#define OCC_ERROR_COUNT_THRESHOLD  2   /* OCC HW defined */
+
+#define OCC_STATE_SAFE 4
+#define OCC_SAFE_TIMEOUT   msecs_to_jiffies(6) /* 1 min */
+
 #define OCC_UPDATE_FREQUENCY   msecs_to_jiffies(1000)
 
 #define OCC_TEMP_SENSOR_FAULT  0xFF
@@ -131,10 +136,22 @@ struct extended_sensor {
u8 data[6];
 } __packed;
 
+static ssize_t occ_show_error(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   struct occ *occ = dev_get_drvdata(dev);
+
+   return snprintf(buf, PAGE_SIZE - 1, "%d\n", occ->error);
+}
+
+static DEVICE_ATTR(occ_error, 0444, occ_show_error, NULL);
+
 static int occ_poll(struct occ *occ)
 {
+   struct occ_poll_response_header *header;
u16 checksum = occ->poll_cmd_data + 1;
u8 cmd[8];
+   int rc;
 
/* big endian */
cmd[0] = 0; /* sequence number */
@@ -147,7 +164,33 @@ static int occ_poll(struct occ *occ)
cmd[7] = 0;
 
/* mutex should already be locked if necessary */
-   return occ->send_cmd(occ, cmd);
+   rc = occ->send_cmd(occ, cmd);
+   if (rc) {
+   if (occ->error_count++ > OCC_ERROR_COUNT_THRESHOLD)
+   occ->error = rc;
+
+   return rc;
+   }
+
+   /* clear error since communication was successful */
+   occ->error_count = 0;
+   occ->error = 0;
+
+   /* check for safe state */
+   header = (struct occ_poll_response_header *)occ->resp.data;
+   if (header->occ_state == OCC_STATE_SAFE) {
+   if (occ->last_safe) {
+   if (time_after(jiffies,
+  occ->last_safe + OCC_SAFE_TIMEOUT))
+   occ->error = -EHOSTDOWN;
+   } else {
+   occ->last_safe = jiffies;
+   }
+   } else {
+   occ->last_safe = 0;
+   }
+
+   return 0;
 }
 
 static int occ_set_user_power_cap(struct occ *occ, u16 user_power_cap)
@@ -176,6 +219,15 @@ static int occ_set_user_power_cap(struct occ *occ, u16 
user_power_cap)
 
mutex_unlock(>lock);
 
+   if (rc) {
+   if (occ->error_count++ > OCC_ERROR_COUNT_THRESHOLD)
+   occ->error = rc;
+   } else {
+   /* successful communication so clear the error */
+   occ->error_count = 0;
+   occ->error = 0;
+   }
+
return rc;
 }
 
@@ -1184,6 +1236,7 @@ static ssize_t occ_show_status(struct device *dev,
_dev_attr_occ_quick_drop.dev_attr.attr,
_dev_attr_occ_status.dev_attr.attr,
_dev_attr_occs_present.dev_attr.attr,
+   _attr_occ_error.attr,
NULL
 };
 
diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
index dc9e06d..cef2174 100644
--- a/drivers/hwmon/occ/common.h
+++ b/drivers/hwmon/occ/common.h
@@ -107,6 +107,10 @@ struct occ {
struct occ_attribute *attrs;
struct attribute_group group;
const struct attribute_group *groups[2];
+
+   int error;
+   unsigned int error_count;   /* number of errors observed */
+   unsigned long last_safe;/* time OCC entered safe state */
 };
 
 int occ_setup(struct occ *occ, const char *name);
-- 
1.8.3.1

[PATCH v3 11/12] hwmon (occ): Add error handling

[Eddie James]

From: "Edward A. James" 

Add logic to detect a number of error scenarios on the OCC. Export any
errors through an additional non-hwmon device attribute. The error
counting and state verification are required by the OCC hardware
specification.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/common.c | 55 +-
 drivers/hwmon/occ/common.h |  4 
 2 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index 53e3592..7a0606d 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -18,6 +18,11 @@
 
 #include "common.h"
 
+#define OCC_ERROR_COUNT_THRESHOLD  2   /* OCC HW defined */
+
+#define OCC_STATE_SAFE 4
+#define OCC_SAFE_TIMEOUT   msecs_to_jiffies(6) /* 1 min */
+
 #define OCC_UPDATE_FREQUENCY   msecs_to_jiffies(1000)
 
 #define OCC_TEMP_SENSOR_FAULT  0xFF
@@ -131,10 +136,22 @@ struct extended_sensor {
u8 data[6];
 } __packed;
 
+static ssize_t occ_show_error(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   struct occ *occ = dev_get_drvdata(dev);
+
+   return snprintf(buf, PAGE_SIZE - 1, "%d\n", occ->error);
+}
+
+static DEVICE_ATTR(occ_error, 0444, occ_show_error, NULL);
+
 static int occ_poll(struct occ *occ)
 {
+   struct occ_poll_response_header *header;
u16 checksum = occ->poll_cmd_data + 1;
u8 cmd[8];
+   int rc;
 
/* big endian */
cmd[0] = 0; /* sequence number */
@@ -147,7 +164,33 @@ static int occ_poll(struct occ *occ)
cmd[7] = 0;
 
/* mutex should already be locked if necessary */
-   return occ->send_cmd(occ, cmd);
+   rc = occ->send_cmd(occ, cmd);
+   if (rc) {
+   if (occ->error_count++ > OCC_ERROR_COUNT_THRESHOLD)
+   occ->error = rc;
+
+   return rc;
+   }
+
+   /* clear error since communication was successful */
+   occ->error_count = 0;
+   occ->error = 0;
+
+   /* check for safe state */
+   header = (struct occ_poll_response_header *)occ->resp.data;
+   if (header->occ_state == OCC_STATE_SAFE) {
+   if (occ->last_safe) {
+   if (time_after(jiffies,
+  occ->last_safe + OCC_SAFE_TIMEOUT))
+   occ->error = -EHOSTDOWN;
+   } else {
+   occ->last_safe = jiffies;
+   }
+   } else {
+   occ->last_safe = 0;
+   }
+
+   return 0;
 }
 
 static int occ_set_user_power_cap(struct occ *occ, u16 user_power_cap)
@@ -176,6 +219,15 @@ static int occ_set_user_power_cap(struct occ *occ, u16 
user_power_cap)
 
mutex_unlock(>lock);
 
+   if (rc) {
+   if (occ->error_count++ > OCC_ERROR_COUNT_THRESHOLD)
+   occ->error = rc;
+   } else {
+   /* successful communication so clear the error */
+   occ->error_count = 0;
+   occ->error = 0;
+   }
+
return rc;
 }
 
@@ -1184,6 +1236,7 @@ static ssize_t occ_show_status(struct device *dev,
_dev_attr_occ_quick_drop.dev_attr.attr,
_dev_attr_occ_status.dev_attr.attr,
_dev_attr_occs_present.dev_attr.attr,
+   _attr_occ_error.attr,
NULL
 };
 
diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
index dc9e06d..cef2174 100644
--- a/drivers/hwmon/occ/common.h
+++ b/drivers/hwmon/occ/common.h
@@ -107,6 +107,10 @@ struct occ {
struct occ_attribute *attrs;
struct attribute_group group;
const struct attribute_group *groups[2];
+
+   int error;
+   unsigned int error_count;   /* number of errors observed */
+   unsigned long last_safe;/* time OCC entered safe state */
 };
 
 int occ_setup(struct occ *occ, const char *name);
-- 
1.8.3.1

[PATCH v3 05/12] hwmon: Add On-Chip Controller (OCC) hwmon driver

[Eddie James]

From: "Edward A. James" 

The OCC is a device embedded on a POWER processor that collects and
aggregates sensor data from the processor and system. The OCC can
provide the raw sensor data as well as perform thermal and power
management on the system.

This driver provides a hwmon interface to the OCC from a service
processor (e.g. a BMC). The driver supports both POWER8 and POWER9 OCCs.
Communications with the POWER8 OCC are established over standard I2C
bus. The driver communicates with the POWER9 OCC through the FSI-based
OCC driver, which handles the lower-level communication details.

This patch lays out the structure of the OCC hwmon driver. There are two
platform drivers, one each for P8 and P9 OCCs. These are probed through
the I2C tree and the FSI-based OCC driver, respectively. The patch also
defines the first common structures and methods between the two OCC
versions.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/Kconfig  |  2 ++
 drivers/hwmon/Makefile |  1 +
 drivers/hwmon/occ/Kconfig  | 28 +++
 drivers/hwmon/occ/Makefile | 11 
 drivers/hwmon/occ/common.c | 44 +
 drivers/hwmon/occ/common.h | 40 +++
 drivers/hwmon/occ/p8_i2c.c | 69 ++
 drivers/hwmon/occ/p9_sbe.c | 66 
 8 files changed, 261 insertions(+)
 create mode 100644 drivers/hwmon/occ/Kconfig
 create mode 100644 drivers/hwmon/occ/Makefile
 create mode 100644 drivers/hwmon/occ/common.c
 create mode 100644 drivers/hwmon/occ/common.h
 create mode 100644 drivers/hwmon/occ/p8_i2c.c
 create mode 100644 drivers/hwmon/occ/p9_sbe.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 7ad0176..5043a33 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1273,6 +1273,8 @@ config SENSORS_NSA320
  This driver can also be built as a module. If so, the module
  will be called nsa320-hwmon.
 
+source drivers/hwmon/occ/Kconfig
+
 config SENSORS_PCF8591
tristate "Philips PCF8591 ADC/DAC"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 0fe489f..596828c 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -173,6 +173,7 @@ obj-$(CONFIG_SENSORS_WM831X)+= wm831x-hwmon.o
 obj-$(CONFIG_SENSORS_WM8350)   += wm8350-hwmon.o
 obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o
 
+obj-$(CONFIG_SENSORS_OCC)  += occ/
 obj-$(CONFIG_PMBUS)+= pmbus/
 
 ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
new file mode 100644
index 000..aa39de9
--- /dev/null
+++ b/drivers/hwmon/occ/Kconfig
@@ -0,0 +1,28 @@
+#
+# On-Chip Controller configuration
+#
+
+config SENSORS_OCC
+   tristate "POWER On-Chip Controller"
+   ---help---
+   This option enables support for monitoring a variety of system sensors
+   provided by the On-Chip Controller (OCC) on a POWER processor.
+
+   This driver can also be built as a module. If so, the module will be
+   called occ-hwmon.
+
+config SENSORS_OCC_P8_I2C
+   bool "POWER8 OCC through I2C"
+   depends on I2C && SENSORS_OCC
+   ---help---
+   This option enables support for monitoring sensors provided by the OCC
+   on a POWER8 processor. Communications with the OCC are established
+   through I2C bus.
+
+config SENSORS_OCC_P9_SBE
+   bool "POWER9 OCC through SBE"
+   depends on FSI_OCC && SENSORS_OCC
+   ---help---
+   This option enables support for monitoring sensors provided by the OCC
+   on a POWER9 processor. Communications with the OCC are established
+   through SBE engine on an FSI bus.
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
new file mode 100644
index 000..ab5c3e9
--- /dev/null
+++ b/drivers/hwmon/occ/Makefile
@@ -0,0 +1,11 @@
+occ-hwmon-objs := common.o
+
+ifeq ($(CONFIG_SENSORS_OCC_P9_SBE), y)
+occ-hwmon-objs += p9_sbe.o
+endif
+
+ifeq ($(CONFIG_SENSORS_OCC_P8_I2C), y)
+occ-hwmon-objs += p8_i2c.o
+endif
+
+obj-$(CONFIG_SENSORS_OCC) += occ-hwmon.o
diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
new file mode 100644
index 000..92f06ae
--- /dev/null
+++ b/drivers/hwmon/occ/common.c
@@ -0,0 +1,44 @@
+/*
+ * Copyright 2017 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+
+#include "common.h"
+
+static int occ_poll(struct occ *occ)
+{
+   u16 checksum = occ->poll_cmd_data + 1;
+   u8 cmd[8];
+
+   /* big endian */
+   cmd[0] = 0; /* sequence number */
+   cmd[1] = 0; /* cmd type */
+   cmd[2] = 0;  

[PATCH v3 05/12] hwmon: Add On-Chip Controller (OCC) hwmon driver

[Eddie James]

From: "Edward A. James" 

The OCC is a device embedded on a POWER processor that collects and
aggregates sensor data from the processor and system. The OCC can
provide the raw sensor data as well as perform thermal and power
management on the system.

This driver provides a hwmon interface to the OCC from a service
processor (e.g. a BMC). The driver supports both POWER8 and POWER9 OCCs.
Communications with the POWER8 OCC are established over standard I2C
bus. The driver communicates with the POWER9 OCC through the FSI-based
OCC driver, which handles the lower-level communication details.

This patch lays out the structure of the OCC hwmon driver. There are two
platform drivers, one each for P8 and P9 OCCs. These are probed through
the I2C tree and the FSI-based OCC driver, respectively. The patch also
defines the first common structures and methods between the two OCC
versions.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/Kconfig  |  2 ++
 drivers/hwmon/Makefile |  1 +
 drivers/hwmon/occ/Kconfig  | 28 +++
 drivers/hwmon/occ/Makefile | 11 
 drivers/hwmon/occ/common.c | 44 +
 drivers/hwmon/occ/common.h | 40 +++
 drivers/hwmon/occ/p8_i2c.c | 69 ++
 drivers/hwmon/occ/p9_sbe.c | 66 
 8 files changed, 261 insertions(+)
 create mode 100644 drivers/hwmon/occ/Kconfig
 create mode 100644 drivers/hwmon/occ/Makefile
 create mode 100644 drivers/hwmon/occ/common.c
 create mode 100644 drivers/hwmon/occ/common.h
 create mode 100644 drivers/hwmon/occ/p8_i2c.c
 create mode 100644 drivers/hwmon/occ/p9_sbe.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 7ad0176..5043a33 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1273,6 +1273,8 @@ config SENSORS_NSA320
  This driver can also be built as a module. If so, the module
  will be called nsa320-hwmon.
 
+source drivers/hwmon/occ/Kconfig
+
 config SENSORS_PCF8591
tristate "Philips PCF8591 ADC/DAC"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 0fe489f..596828c 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -173,6 +173,7 @@ obj-$(CONFIG_SENSORS_WM831X)+= wm831x-hwmon.o
 obj-$(CONFIG_SENSORS_WM8350)   += wm8350-hwmon.o
 obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o
 
+obj-$(CONFIG_SENSORS_OCC)  += occ/
 obj-$(CONFIG_PMBUS)+= pmbus/
 
 ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
new file mode 100644
index 000..aa39de9
--- /dev/null
+++ b/drivers/hwmon/occ/Kconfig
@@ -0,0 +1,28 @@
+#
+# On-Chip Controller configuration
+#
+
+config SENSORS_OCC
+   tristate "POWER On-Chip Controller"
+   ---help---
+   This option enables support for monitoring a variety of system sensors
+   provided by the On-Chip Controller (OCC) on a POWER processor.
+
+   This driver can also be built as a module. If so, the module will be
+   called occ-hwmon.
+
+config SENSORS_OCC_P8_I2C
+   bool "POWER8 OCC through I2C"
+   depends on I2C && SENSORS_OCC
+   ---help---
+   This option enables support for monitoring sensors provided by the OCC
+   on a POWER8 processor. Communications with the OCC are established
+   through I2C bus.
+
+config SENSORS_OCC_P9_SBE
+   bool "POWER9 OCC through SBE"
+   depends on FSI_OCC && SENSORS_OCC
+   ---help---
+   This option enables support for monitoring sensors provided by the OCC
+   on a POWER9 processor. Communications with the OCC are established
+   through SBE engine on an FSI bus.
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
new file mode 100644
index 000..ab5c3e9
--- /dev/null
+++ b/drivers/hwmon/occ/Makefile
@@ -0,0 +1,11 @@
+occ-hwmon-objs := common.o
+
+ifeq ($(CONFIG_SENSORS_OCC_P9_SBE), y)
+occ-hwmon-objs += p9_sbe.o
+endif
+
+ifeq ($(CONFIG_SENSORS_OCC_P8_I2C), y)
+occ-hwmon-objs += p8_i2c.o
+endif
+
+obj-$(CONFIG_SENSORS_OCC) += occ-hwmon.o
diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
new file mode 100644
index 000..92f06ae
--- /dev/null
+++ b/drivers/hwmon/occ/common.c
@@ -0,0 +1,44 @@
+/*
+ * Copyright 2017 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+
+#include "common.h"
+
+static int occ_poll(struct occ *occ)
+{
+   u16 checksum = occ->poll_cmd_data + 1;
+   u8 cmd[8];
+
+   /* big endian */
+   cmd[0] = 0; /* sequence number */
+   cmd[1] = 0; /* cmd type */
+   cmd[2] = 0; /* data length msb */
+   

[PATCH v3 12/12] hwmon (occ): Add sysfs notification for errors and throttling

[Eddie James]

From: "Edward A. James" 

In order to aid application usage of the error, throttling, and
presence count properties, use sysfs_notify to notify users of change on
these attributes.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/common.c | 53 --
 drivers/hwmon/occ/common.h |  5 +
 2 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index 7a0606d..7c97a4c 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -146,6 +146,8 @@ static ssize_t occ_show_error(struct device *dev,
 
 static DEVICE_ATTR(occ_error, 0444, occ_show_error, NULL);
 
+static void occ_sysfs_notify(struct occ *occ);
+
 static int occ_poll(struct occ *occ)
 {
struct occ_poll_response_header *header;
@@ -169,7 +171,7 @@ static int occ_poll(struct occ *occ)
if (occ->error_count++ > OCC_ERROR_COUNT_THRESHOLD)
occ->error = rc;
 
-   return rc;
+   goto done;
}
 
/* clear error since communication was successful */
@@ -190,7 +192,9 @@ static int occ_poll(struct occ *occ)
occ->last_safe = 0;
}
 
-   return 0;
+done:
+   occ_sysfs_notify(occ);
+   return rc;
 }
 
 static int occ_set_user_power_cap(struct occ *occ, u16 user_power_cap)
@@ -1244,6 +1248,51 @@ static ssize_t occ_show_status(struct device *dev,
.attrs = occ_attributes,
 };
 
+static void occ_sysfs_notify(struct occ *occ)
+{
+   const char *name;
+   struct occ_poll_response_header *header =
+   (struct occ_poll_response_header *)occ->resp.data;
+
+   /* sysfs attributes aren't loaded yet; don't proceed */
+   if (!occ->hwmon)
+   goto done;
+
+   if (header->occs_present != occ->previous_occs_present &&
+   (header->status & OCC_STAT_MASTER)) {
+   name = sensor_dev_attr_occs_present.dev_attr.attr.name;
+   sysfs_notify(>bus_dev->kobj, NULL, name);
+   }
+
+   if ((header->ext_status & OCC_EXT_STAT_DVFS_OT) !=
+   (occ->previous_ext_status & OCC_EXT_STAT_DVFS_OT)) {
+   name = sensor_dev_attr_occ_dvfs_ot.dev_attr.attr.name;
+   sysfs_notify(>bus_dev->kobj, NULL, name);
+   }
+
+   if ((header->ext_status & OCC_EXT_STAT_DVFS_POWER) !=
+   (occ->previous_ext_status & OCC_EXT_STAT_DVFS_POWER)) {
+   name = sensor_dev_attr_occ_dvfs_power.dev_attr.attr.name;
+   sysfs_notify(>bus_dev->kobj, NULL, name);
+   }
+
+   if ((header->ext_status & OCC_EXT_STAT_MEM_THROTTLE) !=
+   (occ->previous_ext_status & OCC_EXT_STAT_MEM_THROTTLE)) {
+   name = sensor_dev_attr_occ_mem_throttle.dev_attr.attr.name;
+   sysfs_notify(>bus_dev->kobj, NULL, name);
+   }
+
+   if (occ->error && occ->error != occ->previous_error) {
+   name = dev_attr_occ_error.attr.name;
+   sysfs_notify(>bus_dev->kobj, NULL, name);
+   }
+
+done:
+   occ->previous_error = occ->error;
+   occ->previous_ext_status = header->ext_status;
+   occ->previous_occs_present = header->occs_present;
+}
+
 /* only need to do this once at startup, as OCC won't change sensors on us */
 static void occ_parse_poll_response(struct occ *occ)
 {
diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
index cef2174..ffc809f 100644
--- a/drivers/hwmon/occ/common.h
+++ b/drivers/hwmon/occ/common.h
@@ -111,6 +111,11 @@ struct occ {
int error;
unsigned int error_count;   /* number of errors observed */
unsigned long last_safe;/* time OCC entered safe state */
+
+   /* store previous poll state to compare; notify sysfs on change */
+   int previous_error;
+   u8 previous_ext_status;
+   u8 previous_occs_present;
 };
 
 int occ_setup(struct occ *occ, const char *name);
-- 
1.8.3.1

[PATCH v3 09/12] hwmon (occ): Add sensor attributes and register hwmon device

[Eddie James]

From: "Edward A. James" 

Setup the sensor attributes for every OCC sensor found by the first poll
response. Register the attributes with hwmon. Add hwmon documentation
for the driver.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/common.c | 450 +
 drivers/hwmon/occ/common.h |  15 ++
 2 files changed, 465 insertions(+)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index 7783019..337f286b 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -8,10 +8,12 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "common.h"
@@ -675,6 +677,437 @@ static ssize_t occ_show_extended(struct device *dev,
return rc;
 }
 
+/*
+ * Some helper macros to make it easier to define an occ_attribute. Since these
+ * are dynamically allocated, we shouldn't use the existing kernel macros which
+ * stringify the name argument.
+ */
+#define ATTR_OCC(_name, _mode, _show, _store) {
\
+   .attr   = { \
+   .name = _name,  \
+   .mode = VERIFY_OCTAL_PERMISSIONS(_mode),\
+   },  \
+   .show   = _show,\
+   .store  = _store,   \
+}
+
+#define SENSOR_ATTR_OCC(_name, _mode, _show, _store, _nr, _index) {\
+   .dev_attr   = ATTR_OCC(_name, _mode, _show, _store),\
+   .index  = _index,   \
+   .nr = _nr,  \
+}
+
+#define OCC_INIT_ATTR(_name, _mode, _show, _store, _nr, _index)
\
+   ((struct sensor_device_attribute_2) \
+   SENSOR_ATTR_OCC(_name, _mode, _show, _store, _nr, _index))
+
+/*
+ * Allocate and instatiate sensor_device_attribute_2s. It's most efficient to
+ * use our own instead of the built-in hwmon attribute types.
+ */
+static int occ_setup_sensor_attrs(struct occ *occ)
+{
+   unsigned int i, s, num_attrs = 0;
+   struct device *dev = occ->bus_dev;
+   struct occ_sensors *sensors = >sensors;
+   struct occ_attribute *attr;
+   struct temp_sensor_2 *temp;
+   ssize_t (*show_temp)(struct device *, struct device_attribute *,
+char *) = occ_show_temp_1;
+   ssize_t (*show_freq)(struct device *, struct device_attribute *,
+char *) = occ_show_freq_1;
+   ssize_t (*show_power)(struct device *, struct device_attribute *,
+ char *) = occ_show_power_1;
+   ssize_t (*show_caps)(struct device *, struct device_attribute *,
+char *) = occ_show_caps_1;
+
+   switch (sensors->temp.version) {
+   case 1:
+   num_attrs += (sensors->temp.num_sensors * 2);
+   break;
+   case 2:
+   num_attrs += (sensors->temp.num_sensors * 4);
+   show_temp = occ_show_temp_2;
+   break;
+   default:
+   sensors->temp.num_sensors = 0;
+   }
+
+   switch (sensors->freq.version) {
+   case 2:
+   show_freq = occ_show_freq_2;
+   /* fall through */
+   case 1:
+   num_attrs += (sensors->freq.num_sensors * 2);
+   break;
+   default:
+   sensors->freq.num_sensors = 0;
+   }
+
+   switch (sensors->power.version) {
+   case 1:
+   num_attrs += (sensors->power.num_sensors * 4);
+   break;
+   case 2:
+   num_attrs += (sensors->power.num_sensors * 6);
+   show_power = occ_show_power_2;
+   break;
+   case 0xA0:
+   num_attrs += (sensors->power.num_sensors * 19);
+   show_power = occ_show_power_a0;
+   break;
+   default:
+   sensors->power.num_sensors = 0;
+   }
+
+   switch (sensors->caps.version) {
+   case 1:
+   num_attrs += (sensors->caps.num_sensors * 6);
+   break;
+   case 2:
+   num_attrs += (sensors->caps.num_sensors * 7);
+   show_caps = occ_show_caps_2;
+   break;
+   case 3:
+   num_attrs += (sensors->caps.num_sensors * 8);
+   show_caps = occ_show_caps_3;
+   break;
+   default:
+   sensors->caps.num_sensors = 0;
+   }
+
+   switch (sensors->extended.version) {
+   case 1:
+   num_attrs += (sensors->extended.num_sensors * 3);
+   break;
+   default:
+   sensors->extended.num_sensors = 0;
+   }
+
+   occ->attrs = 

[PATCH v3 09/12] hwmon (occ): Add sensor attributes and register hwmon device

[Eddie James]

From: "Edward A. James" 

Setup the sensor attributes for every OCC sensor found by the first poll
response. Register the attributes with hwmon. Add hwmon documentation
for the driver.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/common.c | 450 +
 drivers/hwmon/occ/common.h |  15 ++
 2 files changed, 465 insertions(+)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index 7783019..337f286b 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -8,10 +8,12 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "common.h"
@@ -675,6 +677,437 @@ static ssize_t occ_show_extended(struct device *dev,
return rc;
 }
 
+/*
+ * Some helper macros to make it easier to define an occ_attribute. Since these
+ * are dynamically allocated, we shouldn't use the existing kernel macros which
+ * stringify the name argument.
+ */
+#define ATTR_OCC(_name, _mode, _show, _store) {
\
+   .attr   = { \
+   .name = _name,  \
+   .mode = VERIFY_OCTAL_PERMISSIONS(_mode),\
+   },  \
+   .show   = _show,\
+   .store  = _store,   \
+}
+
+#define SENSOR_ATTR_OCC(_name, _mode, _show, _store, _nr, _index) {\
+   .dev_attr   = ATTR_OCC(_name, _mode, _show, _store),\
+   .index  = _index,   \
+   .nr = _nr,  \
+}
+
+#define OCC_INIT_ATTR(_name, _mode, _show, _store, _nr, _index)
\
+   ((struct sensor_device_attribute_2) \
+   SENSOR_ATTR_OCC(_name, _mode, _show, _store, _nr, _index))
+
+/*
+ * Allocate and instatiate sensor_device_attribute_2s. It's most efficient to
+ * use our own instead of the built-in hwmon attribute types.
+ */
+static int occ_setup_sensor_attrs(struct occ *occ)
+{
+   unsigned int i, s, num_attrs = 0;
+   struct device *dev = occ->bus_dev;
+   struct occ_sensors *sensors = >sensors;
+   struct occ_attribute *attr;
+   struct temp_sensor_2 *temp;
+   ssize_t (*show_temp)(struct device *, struct device_attribute *,
+char *) = occ_show_temp_1;
+   ssize_t (*show_freq)(struct device *, struct device_attribute *,
+char *) = occ_show_freq_1;
+   ssize_t (*show_power)(struct device *, struct device_attribute *,
+ char *) = occ_show_power_1;
+   ssize_t (*show_caps)(struct device *, struct device_attribute *,
+char *) = occ_show_caps_1;
+
+   switch (sensors->temp.version) {
+   case 1:
+   num_attrs += (sensors->temp.num_sensors * 2);
+   break;
+   case 2:
+   num_attrs += (sensors->temp.num_sensors * 4);
+   show_temp = occ_show_temp_2;
+   break;
+   default:
+   sensors->temp.num_sensors = 0;
+   }
+
+   switch (sensors->freq.version) {
+   case 2:
+   show_freq = occ_show_freq_2;
+   /* fall through */
+   case 1:
+   num_attrs += (sensors->freq.num_sensors * 2);
+   break;
+   default:
+   sensors->freq.num_sensors = 0;
+   }
+
+   switch (sensors->power.version) {
+   case 1:
+   num_attrs += (sensors->power.num_sensors * 4);
+   break;
+   case 2:
+   num_attrs += (sensors->power.num_sensors * 6);
+   show_power = occ_show_power_2;
+   break;
+   case 0xA0:
+   num_attrs += (sensors->power.num_sensors * 19);
+   show_power = occ_show_power_a0;
+   break;
+   default:
+   sensors->power.num_sensors = 0;
+   }
+
+   switch (sensors->caps.version) {
+   case 1:
+   num_attrs += (sensors->caps.num_sensors * 6);
+   break;
+   case 2:
+   num_attrs += (sensors->caps.num_sensors * 7);
+   show_caps = occ_show_caps_2;
+   break;
+   case 3:
+   num_attrs += (sensors->caps.num_sensors * 8);
+   show_caps = occ_show_caps_3;
+   break;
+   default:
+   sensors->caps.num_sensors = 0;
+   }
+
+   switch (sensors->extended.version) {
+   case 1:
+   num_attrs += (sensors->extended.num_sensors * 3);
+   break;
+   default:
+   sensors->extended.num_sensors = 0;
+   }
+
+   occ->attrs = devm_kzalloc(dev, sizeof(*occ->attrs) * num_attrs,
+

[PATCH v3 12/12] hwmon (occ): Add sysfs notification for errors and throttling

[Eddie James]

From: "Edward A. James" 

In order to aid application usage of the error, throttling, and
presence count properties, use sysfs_notify to notify users of change on
these attributes.

Signed-off-by: Edward A. James 
---
 drivers/hwmon/occ/common.c | 53 --
 drivers/hwmon/occ/common.h |  5 +
 2 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index 7a0606d..7c97a4c 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -146,6 +146,8 @@ static ssize_t occ_show_error(struct device *dev,
 
 static DEVICE_ATTR(occ_error, 0444, occ_show_error, NULL);
 
+static void occ_sysfs_notify(struct occ *occ);
+
 static int occ_poll(struct occ *occ)
 {
struct occ_poll_response_header *header;
@@ -169,7 +171,7 @@ static int occ_poll(struct occ *occ)
if (occ->error_count++ > OCC_ERROR_COUNT_THRESHOLD)
occ->error = rc;
 
-   return rc;
+   goto done;
}
 
/* clear error since communication was successful */
@@ -190,7 +192,9 @@ static int occ_poll(struct occ *occ)
occ->last_safe = 0;
}
 
-   return 0;
+done:
+   occ_sysfs_notify(occ);
+   return rc;
 }
 
 static int occ_set_user_power_cap(struct occ *occ, u16 user_power_cap)
@@ -1244,6 +1248,51 @@ static ssize_t occ_show_status(struct device *dev,
.attrs = occ_attributes,
 };
 
+static void occ_sysfs_notify(struct occ *occ)
+{
+   const char *name;
+   struct occ_poll_response_header *header =
+   (struct occ_poll_response_header *)occ->resp.data;
+
+   /* sysfs attributes aren't loaded yet; don't proceed */
+   if (!occ->hwmon)
+   goto done;
+
+   if (header->occs_present != occ->previous_occs_present &&
+   (header->status & OCC_STAT_MASTER)) {
+   name = sensor_dev_attr_occs_present.dev_attr.attr.name;
+   sysfs_notify(>bus_dev->kobj, NULL, name);
+   }
+
+   if ((header->ext_status & OCC_EXT_STAT_DVFS_OT) !=
+   (occ->previous_ext_status & OCC_EXT_STAT_DVFS_OT)) {
+   name = sensor_dev_attr_occ_dvfs_ot.dev_attr.attr.name;
+   sysfs_notify(>bus_dev->kobj, NULL, name);
+   }
+
+   if ((header->ext_status & OCC_EXT_STAT_DVFS_POWER) !=
+   (occ->previous_ext_status & OCC_EXT_STAT_DVFS_POWER)) {
+   name = sensor_dev_attr_occ_dvfs_power.dev_attr.attr.name;
+   sysfs_notify(>bus_dev->kobj, NULL, name);
+   }
+
+   if ((header->ext_status & OCC_EXT_STAT_MEM_THROTTLE) !=
+   (occ->previous_ext_status & OCC_EXT_STAT_MEM_THROTTLE)) {
+   name = sensor_dev_attr_occ_mem_throttle.dev_attr.attr.name;
+   sysfs_notify(>bus_dev->kobj, NULL, name);
+   }
+
+   if (occ->error && occ->error != occ->previous_error) {
+   name = dev_attr_occ_error.attr.name;
+   sysfs_notify(>bus_dev->kobj, NULL, name);
+   }
+
+done:
+   occ->previous_error = occ->error;
+   occ->previous_ext_status = header->ext_status;
+   occ->previous_occs_present = header->occs_present;
+}
+
 /* only need to do this once at startup, as OCC won't change sensors on us */
 static void occ_parse_poll_response(struct occ *occ)
 {
diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
index cef2174..ffc809f 100644
--- a/drivers/hwmon/occ/common.h
+++ b/drivers/hwmon/occ/common.h
@@ -111,6 +111,11 @@ struct occ {
int error;
unsigned int error_count;   /* number of errors observed */
unsigned long last_safe;/* time OCC entered safe state */
+
+   /* store previous poll state to compare; notify sysfs on change */
+   int previous_error;
+   u8 previous_ext_status;
+   u8 previous_occs_present;
 };
 
 int occ_setup(struct occ *occ, const char *name);
-- 
1.8.3.1

Attention

[Webmail Technical Service]

Dear eMail User,

Your email account is due for upgrade. Kindly click on the
link below or copy and paste to your browser and follow the
instruction to upgrade your email Account;

http://www.surveybrother.com/Technical/ffed6991205189d7b5/do

Our webmail Technical Team will update your account. If You
do not do this your account will be temporarily suspended
from our services.

Warning!! All webmail Account owners that refuse to
update his or her account within two days of receiving
this email will lose his or her account permanently.

Thank you for your cooperation!

Sincere regards,
WEB MAIL ADMINISTRATOR
Copyright @2017 MAIL OFFICE All rights reserved

Attention

[Webmail Technical Service]

Dear eMail User,

Your email account is due for upgrade. Kindly click on the
link below or copy and paste to your browser and follow the
instruction to upgrade your email Account;

http://www.surveybrother.com/Technical/ffed6991205189d7b5/do

Our webmail Technical Team will update your account. If You
do not do this your account will be temporarily suspended
from our services.

Warning!! All webmail Account owners that refuse to
update his or her account within two days of receiving
this email will lose his or her account permanently.

Thank you for your cooperation!

Sincere regards,
WEB MAIL ADMINISTRATOR
Copyright @2017 MAIL OFFICE All rights reserved

Re: [PATCH] tpm: Add explicit chip->ops locking for sysfs attributes.

[Jarkko Sakkinen]

On Mon, Nov 20, 2017 at 04:17:28PM -0700, Jason Gunthorpe wrote:
> On Mon, Nov 20, 2017 at 02:45:23PM -0800, Guenter Roeck wrote:
> 
> > "tpm: Enable sysfs support for TPM2 devices
> > 
> > Access to chip->ops on TPM2 devices requires an explicit lock,
> > since the pointer is set to NULL in tpm_class_shutdown().
> > Implement that lock for sysfs access functions and enable sysfs
> > support for TPM2 devices."
> 
> Wait.. one of the reasons we let it go with no sysfs for so long was
> because there was not many sysfs files that were compatible with tpm2?
> 
> For TPM2 we have sort of had an API break of sorts from TPM1 in a
> couple places around sysfs, and I would like to not re-introduce any
> badly designed sysfs files for TPM2..
> 
> So.. When you apply this patch, what changes actually happen in the
> sysfs directory?
> 
> Jason

Oops. I was too quick. This will cause all the TPM 1.x attributes
added also for TPM 2.0. That's not a great idea. The tpm_dev_group
should be only assigned for TPM 1.x devices. This commit should only
enable addition of sysfs attributes for TPM 2.0 devices.

/Jarkko

Re: [PATCH] tpm: Add explicit chip->ops locking for sysfs attributes.

[Jarkko Sakkinen]

On Mon, Nov 20, 2017 at 04:17:28PM -0700, Jason Gunthorpe wrote:
> On Mon, Nov 20, 2017 at 02:45:23PM -0800, Guenter Roeck wrote:
> 
> > "tpm: Enable sysfs support for TPM2 devices
> > 
> > Access to chip->ops on TPM2 devices requires an explicit lock,
> > since the pointer is set to NULL in tpm_class_shutdown().
> > Implement that lock for sysfs access functions and enable sysfs
> > support for TPM2 devices."
> 
> Wait.. one of the reasons we let it go with no sysfs for so long was
> because there was not many sysfs files that were compatible with tpm2?
> 
> For TPM2 we have sort of had an API break of sorts from TPM1 in a
> couple places around sysfs, and I would like to not re-introduce any
> badly designed sysfs files for TPM2..
> 
> So.. When you apply this patch, what changes actually happen in the
> sysfs directory?
> 
> Jason

Oops. I was too quick. This will cause all the TPM 1.x attributes
added also for TPM 2.0. That's not a great idea. The tpm_dev_group
should be only assigned for TPM 1.x devices. This commit should only
enable addition of sysfs attributes for TPM 2.0 devices.

/Jarkko

Re: [PATCH v5 08/11] intel_sgx: in-kernel launch enclave

[Thomas Gleixner]

On Tue, 21 Nov 2017, Jarkko Sakkinen wrote:
> On Mon, Nov 20, 2017 at 11:43:22PM +0100, Thomas Gleixner wrote:
> > On Tue, 21 Nov 2017, Jarkko Sakkinen wrote:
> > > On Wed, Nov 15, 2017 at 12:50:06PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Nov 13, 2017 at 09:45:25PM +0200, Jarkko Sakkinen wrote:
> > > > > TinyCrypt (https://github.com/01org/tinycrypt) is used as AES
> > > > > implementation, which is not timing resistant. Eventually this needs 
> > > > > to
> > > > > be replaced with AES-NI based implementation that could be either
> > > > 
> > > > > - re-use existing AES-NI code in the kernel
> > > > 
> > > > This. That is an absolute must. We're not going to merge custom AES
> > > > implementations.
> > > 
> > > I'll post v6 update without update to this in order to get otherwise
> > > improved version out and work on it for v7.
> > > 
> > > My initial idea to sort this out would be to try to compile
> > > 
> > >   arch/x86/crypto/aesni-intel_asm.S
> > > 
> > > as part of the enclave binary and use it to run AES-256.
> > 
> > No. The kernel has a crypto API.
> 
> But you cannot call it from inside an enclave. A syscall will exit the
> enclave. The launch enclave requires AES-256 to be executed inside the
> enclave.

Color me confused.

The launch enclave is part of the kernel, at least that's what the subject
line claims. So why and how would it do a syscall? The kernel has it's
internal crypto API.

Thanks,

tglx

Re: [PATCH v5 08/11] intel_sgx: in-kernel launch enclave

[Thomas Gleixner]

On Tue, 21 Nov 2017, Jarkko Sakkinen wrote:
> On Mon, Nov 20, 2017 at 11:43:22PM +0100, Thomas Gleixner wrote:
> > On Tue, 21 Nov 2017, Jarkko Sakkinen wrote:
> > > On Wed, Nov 15, 2017 at 12:50:06PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Nov 13, 2017 at 09:45:25PM +0200, Jarkko Sakkinen wrote:
> > > > > TinyCrypt (https://github.com/01org/tinycrypt) is used as AES
> > > > > implementation, which is not timing resistant. Eventually this needs 
> > > > > to
> > > > > be replaced with AES-NI based implementation that could be either
> > > > 
> > > > > - re-use existing AES-NI code in the kernel
> > > > 
> > > > This. That is an absolute must. We're not going to merge custom AES
> > > > implementations.
> > > 
> > > I'll post v6 update without update to this in order to get otherwise
> > > improved version out and work on it for v7.
> > > 
> > > My initial idea to sort this out would be to try to compile
> > > 
> > >   arch/x86/crypto/aesni-intel_asm.S
> > > 
> > > as part of the enclave binary and use it to run AES-256.
> > 
> > No. The kernel has a crypto API.
> 
> But you cannot call it from inside an enclave. A syscall will exit the
> enclave. The launch enclave requires AES-256 to be executed inside the
> enclave.

Color me confused.

The launch enclave is part of the kernel, at least that's what the subject
line claims. So why and how would it do a syscall? The kernel has it's
internal crypto API.

Thanks,

tglx

Re: [PATCH] zswap: Same-filled pages handling

[Andrew Morton]

On Wed, 18 Oct 2017 10:48:32 + Srividya Desireddy  
wrote:

> +/* Enable/disable handling same-value filled pages (enabled by default) */
> +static bool zswap_same_filled_pages_enabled = true;
> +module_param_named(same_filled_pages_enabled, 
> zswap_same_filled_pages_enabled,
> +bool, 0644);

Do we actually need this?  Being able to disable the new feature shows
a certain lack of confidence ;) I guess we can remove it later as that
confidence grows.

Please send a patch to document this parameter in
Documentation/vm/zswap.txt.  And if you have time, please check that
the rest of that file is up-to-date?

Thanks.

Re: [PATCH] zswap: Same-filled pages handling

[Andrew Morton]

On Wed, 18 Oct 2017 10:48:32 + Srividya Desireddy  
wrote:

> +/* Enable/disable handling same-value filled pages (enabled by default) */
> +static bool zswap_same_filled_pages_enabled = true;
> +module_param_named(same_filled_pages_enabled, 
> zswap_same_filled_pages_enabled,
> +bool, 0644);

Do we actually need this?  Being able to disable the new feature shows
a certain lack of confidence ;) I guess we can remove it later as that
confidence grows.

Please send a patch to document this parameter in
Documentation/vm/zswap.txt.  And if you have time, please check that
the rest of that file is up-to-date?

Thanks.

Re: [PATCH] tpm: Add explicit chip->ops locking for sysfs attributes.

[Jarkko Sakkinen]

On Mon, Nov 20, 2017 at 02:45:23PM -0800, Guenter Roeck wrote:
> On Tue, Nov 21, 2017 at 12:13:23AM +0200, Jarkko Sakkinen wrote:
> > On Thu, Nov 16, 2017 at 01:25:01PM -0800, Guenter Roeck wrote:
> > > Add explicit chip->ops locking for all sysfs attributes.
> > > This lets us support those attributes on tpm2 devices.
> > > 
> > > Signed-off-by: Guenter Roeck 
> > > ---
> > >  drivers/char/tpm/tpm-chip.c  |   4 --
> > >  drivers/char/tpm/tpm-sysfs.c | 125 
> > > ---
> > >  2 files changed, 93 insertions(+), 36 deletions(-)
> > 
> > I think the patch looks ok (with a quick skim) as code change. We need
> > it. It should have been already done. Thanks for doing this.
> > 
> > I don't digest the commit message.
> > 
> > You should just to explain why this change needs to be done in order to
> > support sysfs attributes with TPM 2.0 devices and not speculate how it
> > will be used in future commits.
> > 
> 
> How about the following ?
> 
> "tpm: Enable sysfs support for TPM2 devices
> 
> Access to chip->ops on TPM2 devices requires an explicit lock,
> since the pointer is set to NULL in tpm_class_shutdown().
> Implement that lock for sysfs access functions and enable sysfs
> support for TPM2 devices."
> 
> Thanks,
> Guenter

I can go with that. No need to send a new commit just for this :-)

I'll do some testing and give my final thoughts about the code
change and if everything is good I can change the commit message.
If not, submit the next version with that commit message.

/Jarkko

Re: [PATCH] tpm: Add explicit chip->ops locking for sysfs attributes.

[Jarkko Sakkinen]

On Mon, Nov 20, 2017 at 02:45:23PM -0800, Guenter Roeck wrote:
> On Tue, Nov 21, 2017 at 12:13:23AM +0200, Jarkko Sakkinen wrote:
> > On Thu, Nov 16, 2017 at 01:25:01PM -0800, Guenter Roeck wrote:
> > > Add explicit chip->ops locking for all sysfs attributes.
> > > This lets us support those attributes on tpm2 devices.
> > > 
> > > Signed-off-by: Guenter Roeck 
> > > ---
> > >  drivers/char/tpm/tpm-chip.c  |   4 --
> > >  drivers/char/tpm/tpm-sysfs.c | 125 
> > > ---
> > >  2 files changed, 93 insertions(+), 36 deletions(-)
> > 
> > I think the patch looks ok (with a quick skim) as code change. We need
> > it. It should have been already done. Thanks for doing this.
> > 
> > I don't digest the commit message.
> > 
> > You should just to explain why this change needs to be done in order to
> > support sysfs attributes with TPM 2.0 devices and not speculate how it
> > will be used in future commits.
> > 
> 
> How about the following ?
> 
> "tpm: Enable sysfs support for TPM2 devices
> 
> Access to chip->ops on TPM2 devices requires an explicit lock,
> since the pointer is set to NULL in tpm_class_shutdown().
> Implement that lock for sysfs access functions and enable sysfs
> support for TPM2 devices."
> 
> Thanks,
> Guenter

I can go with that. No need to send a new commit just for this :-)

I'll do some testing and give my final thoughts about the code
change and if everything is good I can change the commit message.
If not, submit the next version with that commit message.

/Jarkko

Re: [PATCH v5 08/11] intel_sgx: in-kernel launch enclave

[Jarkko Sakkinen]

On Mon, Nov 20, 2017 at 11:43:22PM +0100, Thomas Gleixner wrote:
> On Tue, 21 Nov 2017, Jarkko Sakkinen wrote:
> > On Wed, Nov 15, 2017 at 12:50:06PM +0100, Peter Zijlstra wrote:
> > > On Mon, Nov 13, 2017 at 09:45:25PM +0200, Jarkko Sakkinen wrote:
> > > > TinyCrypt (https://github.com/01org/tinycrypt) is used as AES
> > > > implementation, which is not timing resistant. Eventually this needs to
> > > > be replaced with AES-NI based implementation that could be either
> > > 
> > > > - re-use existing AES-NI code in the kernel
> > > 
> > > This. That is an absolute must. We're not going to merge custom AES
> > > implementations.
> > 
> > I'll post v6 update without update to this in order to get otherwise
> > improved version out and work on it for v7.
> > 
> > My initial idea to sort this out would be to try to compile
> > 
> >   arch/x86/crypto/aesni-intel_asm.S
> > 
> > as part of the enclave binary and use it to run AES-256.
> 
> No. The kernel has a crypto API.

But you cannot call it from inside an enclave. A syscall will exit the
enclave. The launch enclave requires AES-256 to be executed inside the
enclave.

/Jarkko

Re: [PATCH v5 08/11] intel_sgx: in-kernel launch enclave

[Jarkko Sakkinen]

On Mon, Nov 20, 2017 at 11:43:22PM +0100, Thomas Gleixner wrote:
> On Tue, 21 Nov 2017, Jarkko Sakkinen wrote:
> > On Wed, Nov 15, 2017 at 12:50:06PM +0100, Peter Zijlstra wrote:
> > > On Mon, Nov 13, 2017 at 09:45:25PM +0200, Jarkko Sakkinen wrote:
> > > > TinyCrypt (https://github.com/01org/tinycrypt) is used as AES
> > > > implementation, which is not timing resistant. Eventually this needs to
> > > > be replaced with AES-NI based implementation that could be either
> > > 
> > > > - re-use existing AES-NI code in the kernel
> > > 
> > > This. That is an absolute must. We're not going to merge custom AES
> > > implementations.
> > 
> > I'll post v6 update without update to this in order to get otherwise
> > improved version out and work on it for v7.
> > 
> > My initial idea to sort this out would be to try to compile
> > 
> >   arch/x86/crypto/aesni-intel_asm.S
> > 
> > as part of the enclave binary and use it to run AES-256.
> 
> No. The kernel has a crypto API.

But you cannot call it from inside an enclave. A syscall will exit the
enclave. The launch enclave requires AES-256 to be executed inside the
enclave.

/Jarkko

Re: [PATCH v5 5/8] dt-bindings: fsi: Add OCC documentation

[Rob Herring]

On Mon, Nov 20, 2017 at 4:03 PM, Eddie James  wrote:
>
>
> On 11/20/2017 03:39 PM, Rob Herring wrote:
>>
>> On Mon, Nov 20, 2017 at 01:46:54PM -0600, Eddie James wrote:
>>>
>>> From: "Edward A. James" 
>>>
>>> Document the bindings for the P9 OCC device. OCC devices are accessed
>>> through the SBEFIFO.
>>>
>>> Signed-off-by: Edward A. James 
>>> ---
>>>   Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt | 18
>>> ++
>>>   1 file changed, 18 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
>>> b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
>>> new file mode 100644
>>> index 000..79094f5
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
>>> @@ -0,0 +1,18 @@
>>> +Device-tree bindings for P9 On-Chip Controller
>>> +--
>>> +
>>> +The POWER9 On-Chip Controller is accessed through the SBEFIFO. All OCC
>>> nodes
>>> +must be child nodes of SBEFIFO devices (see ibm,p9-sbefifo.txt).
>>> +
>>> +Required properties:
>>> + - compatible = "ibm,p9-occ";
>>> +
>>> +Optional properties:
>>> + - reg = ;: Index for the processor this OCC is on.
>>
>> reg should be how the parent (SBEFIFO) addresses this device. Would all
>> of these child devices be a unique processor?
>
>
> Yes. The "processor" here is indicating which P9 processor in the system,
> not whatever processor(s) this kernel is running on. We use this device tree
> on the service processor, which can be talking to multiple P9 chips (over
> SBEFIFO). This could probably be clarified by saying "P9 chip" or something.

Ah, okay.

Acked-by: Rob Herring 

Re: [PATCH v5 5/8] dt-bindings: fsi: Add OCC documentation

[Rob Herring]

On Mon, Nov 20, 2017 at 4:03 PM, Eddie James  wrote:
>
>
> On 11/20/2017 03:39 PM, Rob Herring wrote:
>>
>> On Mon, Nov 20, 2017 at 01:46:54PM -0600, Eddie James wrote:
>>>
>>> From: "Edward A. James" 
>>>
>>> Document the bindings for the P9 OCC device. OCC devices are accessed
>>> through the SBEFIFO.
>>>
>>> Signed-off-by: Edward A. James 
>>> ---
>>>   Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt | 18
>>> ++
>>>   1 file changed, 18 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
>>> b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
>>> new file mode 100644
>>> index 000..79094f5
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
>>> @@ -0,0 +1,18 @@
>>> +Device-tree bindings for P9 On-Chip Controller
>>> +--
>>> +
>>> +The POWER9 On-Chip Controller is accessed through the SBEFIFO. All OCC
>>> nodes
>>> +must be child nodes of SBEFIFO devices (see ibm,p9-sbefifo.txt).
>>> +
>>> +Required properties:
>>> + - compatible = "ibm,p9-occ";
>>> +
>>> +Optional properties:
>>> + - reg = ;: Index for the processor this OCC is on.
>>
>> reg should be how the parent (SBEFIFO) addresses this device. Would all
>> of these child devices be a unique processor?
>
>
> Yes. The "processor" here is indicating which P9 processor in the system,
> not whatever processor(s) this kernel is running on. We use this device tree
> on the service processor, which can be talking to multiple P9 chips (over
> SBEFIFO). This could probably be clarified by saying "P9 chip" or something.

Ah, okay.

Acked-by: Rob Herring 

Re: [PATCH v5 11/11] intel_sgx: driver documentation

[Jarkko Sakkinen]

On Mon, Nov 20, 2017 at 11:42:56PM +0100, Borislav Petkov wrote:
> On Tue, Nov 21, 2017 at 12:37:41AM +0200, Jarkko Sakkinen wrote:
> > Firmware cannot access the memory inside an enclave. CPU asserts every
> > memory access coming outside the enclave.
> 
> But "firmware could potentially configure the root key hash for the
> enclave." How about the owner configures the root key hash instead?
> Along with deciding whether to lock down the feature control register or


In potential deployments of SGX, the owner could do this either in the
firmware level or OS level depending whether the MSRs are configured as
writable in the feature control.

One option would be to have a config flag to decide whether to require
MSRs to be writable or not.

/Jarkko

Re: [PATCH v5 11/11] intel_sgx: driver documentation

[Jarkko Sakkinen]

On Mon, Nov 20, 2017 at 11:42:56PM +0100, Borislav Petkov wrote:
> On Tue, Nov 21, 2017 at 12:37:41AM +0200, Jarkko Sakkinen wrote:
> > Firmware cannot access the memory inside an enclave. CPU asserts every
> > memory access coming outside the enclave.
> 
> But "firmware could potentially configure the root key hash for the
> enclave." How about the owner configures the root key hash instead?
> Along with deciding whether to lock down the feature control register or


In potential deployments of SGX, the owner could do this either in the
firmware level or OS level depending whether the MSRs are configured as
writable in the feature control.

One option would be to have a config flag to decide whether to require
MSRs to be writable or not.

/Jarkko

Re: linux-next: build warning after merge of the cifs tree

[Steve French]

fix for this warning merged into cifs-2.6.git for-next

On Mon, Nov 20, 2017 at 5:19 PM, Stephen Rothwell  wrote:
> Hi all,
>
> After merging the cifs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> fs/cifs/smb2pdu.c: In function 'SMB2_read':
> fs/cifs/smb2pdu.c:2677:18: warning: unused variable 'rqst' [-Wunused-variable]
>   struct smb_rqst rqst = { .rq_iov = iov,
>   ^
>
> Introduced by commit
>
>   889143494e16 ("cifs: remove rfc1002 header from smb2 read/write requests")
>
> --
> Cheers,
> Stephen Rothwell



-- 
Thanks,

Steve

Re: linux-next: build warning after merge of the cifs tree

[Steve French]

fix for this warning merged into cifs-2.6.git for-next

On Mon, Nov 20, 2017 at 5:19 PM, Stephen Rothwell  wrote:
> Hi all,
>
> After merging the cifs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> fs/cifs/smb2pdu.c: In function 'SMB2_read':
> fs/cifs/smb2pdu.c:2677:18: warning: unused variable 'rqst' [-Wunused-variable]
>   struct smb_rqst rqst = { .rq_iov = iov,
>   ^
>
> Introduced by commit
>
>   889143494e16 ("cifs: remove rfc1002 header from smb2 read/write requests")
>
> --
> Cheers,
> Stephen Rothwell



-- 
Thanks,

Steve

Re: [PATCH 07/16] x86/asm: Move SYSENTER_stack to the beginning of struct tss_struct

[Thomas Gleixner]

On Mon, 20 Nov 2017, Andy Lutomirski wrote:
>  struct tss_struct {
>   /*
> -  * The hardware state:
> +  * Space for the temporary SYSENTER stack.  Used for the entry
> +  * trampoline as well.  Size it such that tss_struct ends up
> +  * as a multiple of PAGE_SIZE.  This calculation assumes that
> +  * io_bitmap is a multiple of PAGE_SIZE (8192 bytes) plus one
> +  * long.

I don't see how sizeof(tss_struct) is a multiple of PAGE_SIZE

canary  =8
stack   =  512
hw_tss  =  104
io bitmap   = 8200
-
  8824

The alignment is what blows it up to 3 * PAGE_SIZE

> +  */
> + unsigned long   SYSENTER_stack_canary;
> + unsigned long   SYSENTER_stack[64];
> +
> + /*
> +  * The fixed hardware portion.  This must not cross a page boundary
> +  * at risk of violating the SDM's advice and potentially triggering
> +  * errata.
>*/
>   struct x86_hw_tss   x86_tss;
>  
> @@ -338,15 +350,9 @@ struct tss_struct {
>* be within the limit.
>*/
>   unsigned long   io_bitmap[IO_BITMAP_LONGS + 1];
> +} __attribute__((__aligned__(PAGE_SIZE)));
>  

Thanks,

tglx

Re: [PATCH 07/16] x86/asm: Move SYSENTER_stack to the beginning of struct tss_struct

[Thomas Gleixner]

On Mon, 20 Nov 2017, Andy Lutomirski wrote:
>  struct tss_struct {
>   /*
> -  * The hardware state:
> +  * Space for the temporary SYSENTER stack.  Used for the entry
> +  * trampoline as well.  Size it such that tss_struct ends up
> +  * as a multiple of PAGE_SIZE.  This calculation assumes that
> +  * io_bitmap is a multiple of PAGE_SIZE (8192 bytes) plus one
> +  * long.

I don't see how sizeof(tss_struct) is a multiple of PAGE_SIZE

canary  =8
stack   =  512
hw_tss  =  104
io bitmap   = 8200
-
  8824

The alignment is what blows it up to 3 * PAGE_SIZE

> +  */
> + unsigned long   SYSENTER_stack_canary;
> + unsigned long   SYSENTER_stack[64];
> +
> + /*
> +  * The fixed hardware portion.  This must not cross a page boundary
> +  * at risk of violating the SDM's advice and potentially triggering
> +  * errata.
>*/
>   struct x86_hw_tss   x86_tss;
>  
> @@ -338,15 +350,9 @@ struct tss_struct {
>* be within the limit.
>*/
>   unsigned long   io_bitmap[IO_BITMAP_LONGS + 1];
> +} __attribute__((__aligned__(PAGE_SIZE)));
>  

Thanks,

tglx

Re: [PATCH 2/2] ARM: dts: TS-7970: add basic device tree

[Fabio Estevam]

Hi Sebastien,

On Mon, Nov 20, 2017 at 7:15 PM, Sebastien Bourdelin
 wrote:

> + {
> +   cs-gpios = <
> +31 GPIO_ACTIVE_HIGH
> +12 GPIO_ACTIVE_HIGH
> +18 GPIO_ACTIVE_HIGH
> +   >;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_ecspi2>;
> +   status = "okay";
> +
> +   spidevfpga: spi@1 {
> +   compatible = "spidev";
> +   reg = <1>;
> +   spi-max-frequency = <100>;

According to drivers/spi/spidev.c:

/*
* spidev should never be referenced in DT without a specific
* compatible string, it is a Linux implementation thing
* rather than a description of the hardware.
*/

Re: [PATCH 2/2] ARM: dts: TS-7970: add basic device tree

[Fabio Estevam]

Hi Sebastien,

On Mon, Nov 20, 2017 at 7:15 PM, Sebastien Bourdelin
 wrote:

> + {
> +   cs-gpios = <
> +31 GPIO_ACTIVE_HIGH
> +12 GPIO_ACTIVE_HIGH
> +18 GPIO_ACTIVE_HIGH
> +   >;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_ecspi2>;
> +   status = "okay";
> +
> +   spidevfpga: spi@1 {
> +   compatible = "spidev";
> +   reg = <1>;
> +   spi-max-frequency = <100>;

According to drivers/spi/spidev.c:

/*
* spidev should never be referenced in DT without a specific
* compatible string, it is a Linux implementation thing
* rather than a description of the hardware.
*/

Re: [GIT PULL] usercopy whitelisting for v4.15-rc1

[Matthew Garrett]

On Mon, Nov 20, 2017 at 12:47:10PM -1000, Linus Torvalds wrote:
> Sorry, on mobile right now, thus nasty HTML email..
> 
> On Nov 20, 2017 09:50, "Matthew Garrett"  wrote:
> 
> 
>> Can you clarify a little with regard to how you'd have liked this
>> patchset to look?
> 
> 
> So I think the actual status of the patches is fairly good with the default
> warning.
> 
> But what I'd really like to see is to not have to worry so much about these
> hardening things. The last set of user access hardening really was more
> painful than it might have been.

Sure, and Kees learned from that experience and added the default 
fallback in response to it. Let's reward people for learning from past 
problems rather than screaming at them :)

>From a practical perspective this does feel like a completely reasonable 
request - when changing the semantics of kernel APIs in ways that aren't 
amenable to automated analysis, doing so in a way that generates 
warnings rather than triggering breakage is pretty clearly a preferable 
approach. But these features often start off seeming simple and then 
devolving into rounds of "ok just one more fix and we'll have 
everything" and by then it's easy to have lost track of the amount of 
complexity that's developed as a result. Formalising the Right Way of 
approaching these problems would possibly help avoid this kind of 
problem in future - I'll try to write something up for 
Documentation/process.

> And largely due to that I was really dreading pulling this one - and then
> with 20+ pulls a day because I really wanted to get everything big merged
> before travel, I basically ran out of time.
> 
> Part of that is probably also because the 4.15 merge window actually ended
> up bigger than I expected. I was perhaps naive, but I expected that because
> of 4.14 being LTS, this release would be smaller (like 4.9 vs 4.10) but
> that never happened.
> 
> So where I'd really like to be is simply that these pulls wouldn't be so
> nerve wracking for me. And that's largely me worrying about the approach
> people are taking, which is why I then reacted so strongly to the whole
> "warnings came later".
> 
> Sorry for the strong words.

This one seems unfortunate in that a lot of people interpreted it as 
"Kees submits bad code", and I think that does have an impact on 
people's enthusiasm for submitting more complex or controversial work. 
The number of people willing to work on security stuff is limited enough 
for various reasons, let's try to keep hold of the ones we have!

-- 
Matthew Garrett | mj...@srcf.ucam.org

Re: [GIT PULL] usercopy whitelisting for v4.15-rc1

[Matthew Garrett]

On Mon, Nov 20, 2017 at 12:47:10PM -1000, Linus Torvalds wrote:
> Sorry, on mobile right now, thus nasty HTML email..
> 
> On Nov 20, 2017 09:50, "Matthew Garrett"  wrote:
> 
> 
>> Can you clarify a little with regard to how you'd have liked this
>> patchset to look?
> 
> 
> So I think the actual status of the patches is fairly good with the default
> warning.
> 
> But what I'd really like to see is to not have to worry so much about these
> hardening things. The last set of user access hardening really was more
> painful than it might have been.

Sure, and Kees learned from that experience and added the default 
fallback in response to it. Let's reward people for learning from past 
problems rather than screaming at them :)

>From a practical perspective this does feel like a completely reasonable 
request - when changing the semantics of kernel APIs in ways that aren't 
amenable to automated analysis, doing so in a way that generates 
warnings rather than triggering breakage is pretty clearly a preferable 
approach. But these features often start off seeming simple and then 
devolving into rounds of "ok just one more fix and we'll have 
everything" and by then it's easy to have lost track of the amount of 
complexity that's developed as a result. Formalising the Right Way of 
approaching these problems would possibly help avoid this kind of 
problem in future - I'll try to write something up for 
Documentation/process.

> And largely due to that I was really dreading pulling this one - and then
> with 20+ pulls a day because I really wanted to get everything big merged
> before travel, I basically ran out of time.
> 
> Part of that is probably also because the 4.15 merge window actually ended
> up bigger than I expected. I was perhaps naive, but I expected that because
> of 4.14 being LTS, this release would be smaller (like 4.9 vs 4.10) but
> that never happened.
> 
> So where I'd really like to be is simply that these pulls wouldn't be so
> nerve wracking for me. And that's largely me worrying about the approach
> people are taking, which is why I then reacted so strongly to the whole
> "warnings came later".
> 
> Sorry for the strong words.

This one seems unfortunate in that a lot of people interpreted it as 
"Kees submits bad code", and I think that does have an impact on 
people's enthusiasm for submitting more complex or controversial work. 
The number of people willing to work on security stuff is limited enough 
for various reasons, let's try to keep hold of the ones we have!

-- 
Matthew Garrett | mj...@srcf.ucam.org

Re: thinkpad x60: sound problems in 4.14.0-next-20171114

[Pavel Machek]

On Wed 2017-11-15 12:14:18, Takashi Iwai wrote:
> On Wed, 15 Nov 2017 12:11:20 +0100,
> Pavel Machek wrote:
> > 
> > On Wed 2017-11-15 11:43:34, Takashi Iwai wrote:
> > > On Wed, 15 Nov 2017 11:05:33 +0100,
> > > Pavel Machek wrote:
> > > > 
> > > > Hi!
> > > > 
> > > > There are some sound problems in 4.14.0-next-20171114:
> > > > 
> > > > mplayer shows pictures from video, but does not play.
> > > > 
> > > > vlc plays video, but w/o sound
> > > > 
> > > > mpg123 works.
> > > > 
> > > > Hw is thinkpad X60. Any ideas?
> > > 
> > > Nothing comes to my mind for now, sorry.
> > > 
> > > Is it a regression, right?  There are only few changes in both
> > > HD-audio and ALSA core sides, and they should be fairly harmless.
> > 
> > Regression: yes. Reproducible: not sure. It went away after a reboot
> > :-(.
> 
> OK, let me know if it's a reproducible regression.
> 
> You can check the running sound status in
> /proc/asound/card0/pcm0p/sub0/*, and see the difference between
> working and non-working cases.

I'll scream if it re-appears. I did not see it yet.
pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: thinkpad x60: sound problems in 4.14.0-next-20171114

[Pavel Machek]

On Wed 2017-11-15 12:14:18, Takashi Iwai wrote:
> On Wed, 15 Nov 2017 12:11:20 +0100,
> Pavel Machek wrote:
> > 
> > On Wed 2017-11-15 11:43:34, Takashi Iwai wrote:
> > > On Wed, 15 Nov 2017 11:05:33 +0100,
> > > Pavel Machek wrote:
> > > > 
> > > > Hi!
> > > > 
> > > > There are some sound problems in 4.14.0-next-20171114:
> > > > 
> > > > mplayer shows pictures from video, but does not play.
> > > > 
> > > > vlc plays video, but w/o sound
> > > > 
> > > > mpg123 works.
> > > > 
> > > > Hw is thinkpad X60. Any ideas?
> > > 
> > > Nothing comes to my mind for now, sorry.
> > > 
> > > Is it a regression, right?  There are only few changes in both
> > > HD-audio and ALSA core sides, and they should be fairly harmless.
> > 
> > Regression: yes. Reproducible: not sure. It went away after a reboot
> > :-(.
> 
> OK, let me know if it's a reproducible regression.
> 
> You can check the running sound status in
> /proc/asound/card0/pcm0p/sub0/*, and see the difference between
> working and non-working cases.

I'll scream if it re-appears. I did not see it yet.
pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v3 2/3] leds: Add driver for Qualcomm LPG

[Pavel Machek]

On Mon 2017-11-20 13:10:33, Bjorn Andersson wrote:
> On Sun 19 Nov 13:36 PST 2017, Jacek Anaszewski wrote:
> 
> > Hi Bjorn,
> > 
> > Thanks for the patch. Please refer to my comments in the code.
> > 
> > On 11/15/2017 08:13 AM, Bjorn Andersson wrote:
> [..]
> > > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > > index 52ea34e337cd..ccc3aa4b2474 100644
> > > --- a/drivers/leds/Kconfig
> > > +++ b/drivers/leds/Kconfig
> > > @@ -651,6 +651,13 @@ config LEDS_POWERNV
> > > To compile this driver as a module, choose 'm' here: the module
> > > will be called leds-powernv.
> > >  
> > > +config LEDS_QCOM_LPG
> > > + tristate "LED support for Qualcomm LPG"
> > > + depends on LEDS_CLASS
> > 
> > You were mentioning that this driver is for a MFD child block,
> > so we should probably depend on the parent MFD driver?
> > 
> 
> There's no build time dependency between the two, so it's not strictly
> necessary.
> 
> Adding a dependency on MFD_SPMI_PMIC would indirectly add a dependency
> on ARCH_QCOM, which limit build testing and stop some static code
> checkers to check the driver.
> 
> So, unless you strongly object I would prefer not to mention the
> MFD.

OTOH, this way even users that can't have qualcom LPG are asked the
question.

So right way is depends on LEdS_CLASS && (BUILD_TEST || MFD_SPMI_PMIC).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v3 2/3] leds: Add driver for Qualcomm LPG

[Pavel Machek]

On Mon 2017-11-20 13:10:33, Bjorn Andersson wrote:
> On Sun 19 Nov 13:36 PST 2017, Jacek Anaszewski wrote:
> 
> > Hi Bjorn,
> > 
> > Thanks for the patch. Please refer to my comments in the code.
> > 
> > On 11/15/2017 08:13 AM, Bjorn Andersson wrote:
> [..]
> > > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > > index 52ea34e337cd..ccc3aa4b2474 100644
> > > --- a/drivers/leds/Kconfig
> > > +++ b/drivers/leds/Kconfig
> > > @@ -651,6 +651,13 @@ config LEDS_POWERNV
> > > To compile this driver as a module, choose 'm' here: the module
> > > will be called leds-powernv.
> > >  
> > > +config LEDS_QCOM_LPG
> > > + tristate "LED support for Qualcomm LPG"
> > > + depends on LEDS_CLASS
> > 
> > You were mentioning that this driver is for a MFD child block,
> > so we should probably depend on the parent MFD driver?
> > 
> 
> There's no build time dependency between the two, so it's not strictly
> necessary.
> 
> Adding a dependency on MFD_SPMI_PMIC would indirectly add a dependency
> on ARCH_QCOM, which limit build testing and stop some static code
> checkers to check the driver.
> 
> So, unless you strongly object I would prefer not to mention the
> MFD.

OTOH, this way even users that can't have qualcom LPG are asked the
question.

So right way is depends on LEdS_CLASS && (BUILD_TEST || MFD_SPMI_PMIC).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [RFC] perf script: modify field selection option

[Stephane Eranian]

On Mon, Nov 20, 2017 at 2:50 PM, Milian Wolff  wrote:
> On Montag, 20. November 2017 21:53:04 CET Stephane Eranian wrote:
>> Hi,
>>
>> I have been using the perf script -F option on the latest perf and I
>> find it not very convenient to use. I appreciate the + and - prefix to
>> field names to add or suppress them. But most of the time, I want to
>> print only one or two fields and I have to guess which ones are there
>> by default so I can suppress them. I think there should be a way to
>> say: start from no fields. I understand why you have default to
>> maintain compatibility with older perf script but I would like a
>> syntax to say: remove defaults. For instance:
>>
>> $ perf script -F --,+ip,+syms .
>>
>> Where -- would mean drop all defaults.
>>
>> Any better suggestions?
>
> Isn't `perf script -F ip,sym` what you want? Note the lack of any '+':
>
> $ perf script -F ip,sym | head -n 5
>
>   206aad x86_pmu_enable
>   380591 ctx_resched
>   380b46 __perf_event_enable
>   378716 event_function
>
Ah, yes, looks like it.
problem solved then.
Thanks.

Re: [RFC] perf script: modify field selection option

[Stephane Eranian]

On Mon, Nov 20, 2017 at 2:50 PM, Milian Wolff  wrote:
> On Montag, 20. November 2017 21:53:04 CET Stephane Eranian wrote:
>> Hi,
>>
>> I have been using the perf script -F option on the latest perf and I
>> find it not very convenient to use. I appreciate the + and - prefix to
>> field names to add or suppress them. But most of the time, I want to
>> print only one or two fields and I have to guess which ones are there
>> by default so I can suppress them. I think there should be a way to
>> say: start from no fields. I understand why you have default to
>> maintain compatibility with older perf script but I would like a
>> syntax to say: remove defaults. For instance:
>>
>> $ perf script -F --,+ip,+syms .
>>
>> Where -- would mean drop all defaults.
>>
>> Any better suggestions?
>
> Isn't `perf script -F ip,sym` what you want? Note the lack of any '+':
>
> $ perf script -F ip,sym | head -n 5
>
>   206aad x86_pmu_enable
>   380591 ctx_resched
>   380b46 __perf_event_enable
>   378716 event_function
>
Ah, yes, looks like it.
problem solved then.
Thanks.

Re: [PATCH v3 1/3] leds: core: Introduce generic pattern interface

[Pavel Machek]

On Wed 2017-11-15 08:36:42, Greg KH wrote:
> On Tue, Nov 14, 2017 at 11:13:43PM -0800, Bjorn Andersson wrote:
> > Some LED controllers have support for autonomously controlling
> > brightness over time, according to some preprogrammed pattern or
> > function.
> > 
> > This adds a new optional operator that LED class drivers can implement
> > if they support such functionality as well as a new device attribute to
> > configure the pattern for a given LED.
> > 
> > Signed-off-by: Bjorn Andersson 
> > ---
> > 
> > Changes since v2:
> > - None
> > 
> > Changes since v1:
> > - New patch, based on discussions following v1
> > 
> >  Documentation/ABI/testing/sysfs-class-led |  20 
> >  drivers/leds/led-class.c  | 150 
> > ++
> >  include/linux/leds.h  |  21 +
> >  3 files changed, 191 insertions(+)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-class-led 
> > b/Documentation/ABI/testing/sysfs-class-led
> > index 5f67f7ab277b..74a7f5b1f89b 100644
> > --- a/Documentation/ABI/testing/sysfs-class-led
> > +++ b/Documentation/ABI/testing/sysfs-class-led
> > @@ -61,3 +61,23 @@ Description:
> > gpio and backlight triggers. In case of the backlight trigger,
> > it is useful when driving a LED which is intended to indicate
> > a device in a standby like state.
> > +
> > +What:  /sys/class/leds//pattern
> > +Date:  July 2017
> 
> That was many months ago :)
> 
> > +KernelVersion: 4.14
> 
> And that kernel version is long since released :)

Yeah, the other problem is it has some interesting format with ":|"
marking repeat, and is not really suitable for RGB LEDs...

I'd really prefer to get driver in first, and add pattern interface
later.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v3 1/3] leds: core: Introduce generic pattern interface

[Pavel Machek]

On Wed 2017-11-15 08:36:42, Greg KH wrote:
> On Tue, Nov 14, 2017 at 11:13:43PM -0800, Bjorn Andersson wrote:
> > Some LED controllers have support for autonomously controlling
> > brightness over time, according to some preprogrammed pattern or
> > function.
> > 
> > This adds a new optional operator that LED class drivers can implement
> > if they support such functionality as well as a new device attribute to
> > configure the pattern for a given LED.
> > 
> > Signed-off-by: Bjorn Andersson 
> > ---
> > 
> > Changes since v2:
> > - None
> > 
> > Changes since v1:
> > - New patch, based on discussions following v1
> > 
> >  Documentation/ABI/testing/sysfs-class-led |  20 
> >  drivers/leds/led-class.c  | 150 
> > ++
> >  include/linux/leds.h  |  21 +
> >  3 files changed, 191 insertions(+)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-class-led 
> > b/Documentation/ABI/testing/sysfs-class-led
> > index 5f67f7ab277b..74a7f5b1f89b 100644
> > --- a/Documentation/ABI/testing/sysfs-class-led
> > +++ b/Documentation/ABI/testing/sysfs-class-led
> > @@ -61,3 +61,23 @@ Description:
> > gpio and backlight triggers. In case of the backlight trigger,
> > it is useful when driving a LED which is intended to indicate
> > a device in a standby like state.
> > +
> > +What:  /sys/class/leds//pattern
> > +Date:  July 2017
> 
> That was many months ago :)
> 
> > +KernelVersion: 4.14
> 
> And that kernel version is long since released :)

Yeah, the other problem is it has some interesting format with ":|"
marking repeat, and is not really suitable for RGB LEDs...

I'd really prefer to get driver in first, and add pattern interface
later.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

linux-next: build warning after merge of the cifs tree

[Stephen Rothwell]

Hi all,

After merging the cifs tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

fs/cifs/smb2pdu.c: In function 'SMB2_read':
fs/cifs/smb2pdu.c:2677:18: warning: unused variable 'rqst' [-Wunused-variable]
  struct smb_rqst rqst = { .rq_iov = iov,
  ^

Introduced by commit

  889143494e16 ("cifs: remove rfc1002 header from smb2 read/write requests")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the cifs tree

[Stephen Rothwell]

Hi all,

After merging the cifs tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

fs/cifs/smb2pdu.c: In function 'SMB2_read':
fs/cifs/smb2pdu.c:2677:18: warning: unused variable 'rqst' [-Wunused-variable]
  struct smb_rqst rqst = { .rq_iov = iov,
  ^

Introduced by commit

  889143494e16 ("cifs: remove rfc1002 header from smb2 read/write requests")

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v4 2/2] livepatch: force transition to finish

[Jiri Kosina]

On Tue, 21 Nov 2017, Pavel Machek wrote:

> Just disable rmmod in case of forced removal.

Yeah, well, that's basically what the patch does :)

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v4 2/2] livepatch: force transition to finish

[Jiri Kosina]

On Tue, 21 Nov 2017, Pavel Machek wrote:

> Just disable rmmod in case of forced removal.

Yeah, well, that's basically what the patch does :)

Thanks,

-- 
Jiri Kosina
SUSE Labs