Re: [RFC PATCH v1 2/6] kernel-doc: replace kernel-doc perl parser with a pure python one (WIP)
Am 25.01.2017 um 21:59 schrieb Jani Nikula : >> But the problem I see here is, that the perl script generates a >> reST output which I can't use. As an example we can take a look at >> the man-page builder I shipped in the series. > > Sorry, I still don't understand *why* you can't use the same rst. Your > explanation seems to relate to man pages, but man pages come > *afterwards*, and are a separate improvement. I know you talk about lack > of proper structure and all that, but *why* can it strictly not be used, > if the *current* rst clearly can be used? "afterwards" is the word, that lets me slowly realize, that I have to stop solving the world's problems with one patch. Now I guess how my next patch series has to look like. Thanks! ... for being patient with me. Before I start, I want to hear your thoughts about the parsing aspect ... >>> That said, perhaps having an elegant parser (perhaps based on a compiler >>> plugin) is incompatible with the idea of making it a bug-for-bug drop-in >>> replacement of the old one, and it's something we need to think about. Did you have any suggestions? -- Markus -- -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 2/6] kernel-doc: replace kernel-doc perl parser with a pure python one (WIP)
On Thu, 26 Jan 2017, Markus Heiser wrote: > Am 25.01.2017 um 21:59 schrieb Jani Nikula : > >>> But the problem I see here is, that the perl script generates a >>> reST output which I can't use. As an example we can take a look at >>> the man-page builder I shipped in the series. >> >> Sorry, I still don't understand *why* you can't use the same rst. Your >> explanation seems to relate to man pages, but man pages come >> *afterwards*, and are a separate improvement. I know you talk about lack >> of proper structure and all that, but *why* can it strictly not be used, >> if the *current* rst clearly can be used? > > "afterwards" is the word, that lets me slowly realize, that I have to > stop solving the world's problems with one patch. Now I guess how my > next patch series has to look like. Thanks! ... for being patient with > me. Indeed, we change the world, one small incremental patch at a time. ;) > Before I start, I want to hear your thoughts about the parsing > aspect ... > That said, perhaps having an elegant parser (perhaps based on a compiler plugin) is incompatible with the idea of making it a bug-for-bug drop-in replacement of the old one, and it's something we need to think about. > > Did you have any suggestions? The perfect is the enemy of the good... If we see that the current Perl parser just rewritten in Python really is an improvement, we should consider it. But as I wrote, there are still issues there, like performance, that we need to understand. I'll mostly defer to Jon on this. But before we plunge on with this, I would like to see at least some research into reusing existing parsers which I would expect are plentiful. We may end up deciding regexps are the way to go after all, but I'd like it to be based on a decision rather than a lack of one. And we might decide to look at this as a later improvement instead as well. I've looked at python-clang myself, but it's a huge dependency, and it's not trivial to cover all the things that the current one does with that. I'd dismiss that. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 2/6] kernel-doc: replace kernel-doc perl parser with a pure python one (WIP)
On Wed, 25 Jan 2017 20:07:47 +0100 Markus Heiser wrote: > So, what I mean is, the new parser has to generate a complete different reST > output and thats why we can't compare the perl parser with python one on a > reST > basis ... and if reST is different, HTML is different :( > > So we do not have any chance to track regression when switching from > the old to the new parser. > > Thats are my thoughts on this topic, may be you have a solution for this? The solution, I think, is as has been described by others in the thread. I'll make a try at it now :) The objectives in a patch set are something like this: - Replace the kernel-doc utility with one that is easier to maintain and enhance. - Add various enhancements (man pages, linting, better output, better parsing) to the docs build system. What everybody is complaining about here is that all of that stuff is being thrown in together into a single patch set. We don't do things that way because long experience says we'll create a mess that takes a long time to straighten out again. As I said before, I'm very much amenable to the idea of replacing kernel-doc with one that is easier to work with. I haven't yet had the time to look closely enough at yours to have an opinion on whether it does that or not. But, assuming it does, the proper way to make this change is to provide a new kerneldoc that behaves as closely to the old one as possible, with an absolute minimum of output changes. Doing it that way probably seems like a pretty annoying request. But it lets us validate its basic mechanics and be confident that we won't break the docs build in weird ways. It also lets us evaluate the question of whether the replacement has merit in its own right, independent of any other change we want to make. Give me a new kerneldoc that passes those tests, and I'll happily merge it. (I have some sympathy with the idea that we should look into other parsers, but I would not hold up a new kerneldoc that passed those tests on this basis alone.) *Then* we can start adding the other stuff, which, from a first look, appears to be stuff that we very much want to have. Each one of those, too, should stand alone and pass muster on its own merits. Changes presented in this way could be merged in the same development cycle if they are ready, but we need to be able to evaluate each one separately. Does this make sense? We all really appreciate the work you're doing here, we're just asking that it be done in an evolutionary manner so we can evaluate it properly. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Omitting documentation for internal structure members
Here's a little glitch that I'd like to see fixed:
struct radix_tree_iter
radix tree iterator state
Definition
struct radix_tree_iter {
unsigned long index;
unsigned long next_index;
unsigned long tags;
struct radix_tree_node * node;
#ifdef CONFIG_RADIX_TREE_MULTIORDER
unsigned int shift;
#endif
};
I'd like to see the ifdef/endif not included, and the 'unsigned int shift' not
included either.
I think it's appropriate to not include any preprocessor lines in the
definition of the struct (general agreement on that front?)
Then I'd like a way to indicate to kernel-doc that I want to omit 'shift' from
the struct definition. It's not for public use; there's an accessor to get at
it, and I don't want it documented. If there isn't already a way to indicate
this to kernel-doc, might I suggest this little gem ...
/**
* struct radix_tree_iter - radix tree iterator state
* @index: index of current slot
* @next_index: one beyond the last index for this chunk
* @tags: bit-mask for tag-iterating
* @node: node that contains current slot
- @shift: shift for the node that holds our slots
*
* The radix tree iterator works in terms of "chunks" of slots. A chunk is a
* subinterval of slots contained within one radix tree leaf node. It is
* described by a pointer to its first slot and a struct radix_tree_iter
* which holds the chunk's position in the tree and its size. For tagged
* iteration radix_tree_iter also holds the slots' bit-mask for one chosen
* radix tree tag.
*/
If the line starts with a '-' instead of a '*', that indicates that this
definition should be omitted. We're still documenting it for internal usage,
but it doesn't appear in the public documentation. Does that seem reasonable,
or am I just being weird?
N�r��yb�X��ǧv�^�){.n�+{�v�"��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: [RFC PATCH v1 2/6] kernel-doc: replace kernel-doc perl parser with a pure python one (WIP)
On Thu, 26 Jan 2017, Jonathan Corbet wrote: > Give me a new kerneldoc that passes those tests, and I'll happily > merge it. (I have some sympathy with the idea that we should look > into other parsers, but I would not hold up a new kerneldoc that > passed those tests on this basis alone.) I'll just note in passing that having another parser that actually works for our needs might be a pink unicorn pony. It might exist, it might not, and someone would have to put in the hours to try to find it, tame it, and bring it to the kernel. But it would be awesome to have. Switching to a homebrew Python parser first does not preclude a unicorn hunt later. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Omitting documentation for internal structure members
On Thu, 26 Jan 2017, Matthew Wilcox wrote:
> Here's a little glitch that I'd like to see fixed:
>
> struct radix_tree_iter
> radix tree iterator state
> Definition
> struct radix_tree_iter {
> unsigned long index;
> unsigned long next_index;
> unsigned long tags;
> struct radix_tree_node * node;
> #ifdef CONFIG_RADIX_TREE_MULTIORDER
> unsigned int shift;
> #endif
> };
>
> I'd like to see the ifdef/endif not included, and the 'unsigned int
> shift' not included either.
>
> I think it's appropriate to not include any preprocessor lines in the
> definition of the struct (general agreement on that front?)
>
> Then I'd like a way to indicate to kernel-doc that I want to omit
> 'shift' from the struct definition. It's not for public use; there's
> an accessor to get at it, and I don't want it documented. If there
> isn't already a way to indicate this to kernel-doc, might I suggest
> this little gem ...
You can use /* private: */ within the struct to indicate the following
members should not be included in the generated documentation. It does
however mean you can't then document the members either, or you'll get
warnings.
I'm generally not too happy about the mechanism, but it's there, perhaps
not very well advertized.
>
> /**
> * struct radix_tree_iter - radix tree iterator state
> * @index: index of current slot
> * @next_index: one beyond the last index for this chunk
> * @tags: bit-mask for tag-iterating
> * @node: node that contains current slot
> - @shift: shift for the node that holds our slots
> *
> * The radix tree iterator works in terms of "chunks" of slots. A chunk is a
> * subinterval of slots contained within one radix tree leaf node. It is
> * described by a pointer to its first slot and a struct radix_tree_iter
> * which holds the chunk's position in the tree and its size. For tagged
> * iteration radix_tree_iter also holds the slots' bit-mask for one chosen
> * radix tree tag.
> */
>
> If the line starts with a '-' instead of a '*', that indicates that
> this definition should be omitted. We're still documenting it for
> internal usage, but it doesn't appear in the public documentation.
> Does that seem reasonable, or am I just being weird?
The request isn't weird, but I find the '-' prefixes there aesthetically
displeasing. I think I'd prefer fixing this in the inline member
documentation comments using some keyword/syntax. But then you'd have to
document the private fields within the struct comments.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Omitting documentation for internal structure members
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> You can use /* private: */ within the struct to indicate the following
> members should not be included in the generated documentation. It does
> however mean you can't then document the members either, or you'll get
> warnings.
>
> I'm generally not too happy about the mechanism, but it's there, perhaps
> not very well advertized.
I don't know how I failed to see that in the documentation. I read
doc-guide/kernel-doc.rst about three times this week.
@@ -154,6 +157,7 @@ struct radix_tree_iter {
unsigned long next_index;
unsigned long tags;
struct radix_tree_node *node;
+/* private: Do not use directly; call iter_shift() or __set_iter_shift() */
#ifdef CONFIG_RADIX_TREE_MULTIORDER
unsigned intshift;
#endif
That solves my problem. Thanks!
Re: [PATCH] Documentation: dontdiff: Update with additional entries
On Mon, 16 Jan 2017 14:31:15 -0800 Florian Fainelli wrote: > Add a bunch of entries reflective of programs that the kernel build: > sortextable, dtc. And while at it, expand the lex*.c entries to cover > e.g: dtc-lexer.c. Finally, exclude devicetable-offsets.h Does anybody still use the dontdiff file? I wonder if we could automatically generate it from the .gitignore files... Oh well, meanwhile, I've applied this to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dynamic-debug-howto: Correct echo -c to -n
On Tue, 17 Jan 2017 13:38:49 + Steven Price wrote: > Two of the example command lines use an argument to echo of "-c" which > isn't valid in (most versions of) echo causing these examples to fail. > Correct the argument to "-n" which works correctly. Makes sense, applied (though those control files typically ignore a trailing newline, so -n isn't usually needed either). Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Converted zorro.txt to rst format and relocated
On Mon, 23 Jan 2017 08:41:34 +1000 Darryl Bond wrote: > Moved file zorro.rst to > equivalent location as source in main tree, ie drivers/zorro This required > creation of Documentation/drivers. It is my suggestion that the Documentation > tree is organised in the same fashion as the source tree. It is then clear > where the documentation pertains to. There will be times when a document file > pertains to many parts of the tree. This will need to be resolved on a case > by case basis. OK, a good first try. Here's a few notes... - This particular document is clearly aimed at driver authors - it covers the API used to work with this bus. So it's natural home is in the driver API guide. - You should always CC the author of a document like this when you make changes. That's Geert in this case, indicated at the top of the file. For this particular document, I would be really tempted to ask whether the document needs to be preserved at all. - Most of the time, we take section numbers out when doing these conversions; Sphinx can generate them if need be. Thanks for helping with the documentation! jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [linux-next] Doc: Fix double words in Documentation
On Tue, 24 Jan 2017 21:45:15 +0900 Masanari Iida wrote: > This patch fix some double words found in Documentation. Applied, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kernel-doc: Handle returning pointers to pointers
On Mon, 23 Jan 2017 00:18:10 -0800 Matthew Wilcox wrote: > Clearly nobody ever tried to build the documentation for the radix tree > before: > > include/linux/radix-tree.h:400: warning: cannot understand function > prototype: 'void ** radix_tree_iter_init(struct radix_tree_iter *iter, > unsigned long start) ' > > Indeed, the regexes only handled a single '*', not one-or-more. I have > tried to fix that, but now I have perl regexes all over my hands, and > I fear I shall never be clean again. Applied, thanks. About your hands, try Dr Bronner's soap; at least, that's what I use for bicycle grease. What might be harder to shake is your new reputation as somebody who knows how to fix the kernel-doc script...:) jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] zh_CN/CodingStyle: improve translation
On Wed, 25 Jan 2017 12:14:31 +0800 Andy Deng wrote: > Some of the sentences in Chapters 19 and 20 are re-translated: > > - Fixed translation errors in Section 2 of Chapter 19 to prevent > misleading readers; > - Retranslate some sentences to make the translation more clear and > accurate. OK, I've applied the whole set, thanks. One thing, though: your messages came through with this header: Content-Type: text/plain; charset=y The screwy "charset=y" puts "git am" into a severely uncooperative mood, so I had to edit your messages by hand to apply them. Mauro (copied), do I remember correctly that you figured out how that was happening to your emails? It would be good to get that understood, documented, and maybe even fixed... Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH linux v4 2/6] hwmon: occ: Add sysfs interface
From: "Edward A. James"
Add a generic mechanism to expose the sensors provided by the OCC in
sysfs.
Signed-off-by: Edward A. James
Signed-off-by: Andrew Jeffery
---
Documentation/hwmon/occ | 62 ++
drivers/hwmon/occ/Makefile| 2 +-
drivers/hwmon/occ/occ_sysfs.c | 259 ++
drivers/hwmon/occ/occ_sysfs.h | 30 +
4 files changed, 352 insertions(+), 1 deletion(-)
create mode 100644 drivers/hwmon/occ/occ_sysfs.c
create mode 100644 drivers/hwmon/occ/occ_sysfs.h
diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index 79d1642..d0bdf06 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -25,6 +25,68 @@ Currently, all versions of the OCC support four types of
sensor data: power,
temperature, frequency, and "caps," which indicate limits and thresholds used
internally on the OCC.
+sysfs Entries
+-
+
+The OCC driver uses the hwmon sysfs framework to provide data to userspace.
+
+The driver exports a number of sysfs files for each type of sensor. The
+sensor-specific files vary depending on the processor type, though many of the
+attributes are common for both the POWER8 and POWER9.
+
+The hwmon interface cannot define every type of sensor that may be used.
+Therefore, the frequency sensor on the OCC uses the "input" type sensor defined
+by the hwmon interface, rather than defining a new type of custom sensor.
+
+Below are detailed the names and meaning of each sensor file for both types of
+processors. All sensors are read-only unless otherwise specified. indicates
+the hwmon index. sensor id indicates the unique internal OCC identifer. Please
+see the POWER OCC specification for details on all these sensor values.
+
+frequency:
+ all processors:
+ in_input - frequency value
+ in_label - sensor id
+temperature:
+ POWER8:
+ temp_input - temperature value
+ temp_label - sensor id
+ POWER9 (in addition to above):
+ temp_type - FRU type
+
+power:
+ POWER8:
+ power_input - power value
+ power_label - sensor id
+ power_average - accumulator
+ power_average_interval - update tag (number of samples in
+ accumulator)
+ POWER9:
+ power_input - power value
+ power_label - sensor id
+ power_average_min - accumulator[0]
+ power_average_max - accumulator[1] (64 bits total)
+ power_average_interval - update tag
+ power_reset_history - (function_id | (apss_channel << 8)
+
+caps:
+ POWER8:
+ power_cap - current powercap
+ power_cap_max - max powercap
+ power_cap_min - min powercap
+ power_max - normal powercap
+ power_alarm - user powercap, r/w
+ POWER9:
+ power_cap_alarm - user powercap source
+
+The driver also provides two sysfs entries through hwmon to better
+control the driver and monitor the master OCC. Though there may be multiple
+OCCs present on the system, these two files are only present for the "master"
+OCC.
+ name - read the name of the driver
+ update_interval - read or write the minimum interval for polling the
+ OCC.
+
BMC - Host Communications
-
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index 93cb52f..a6881f9 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o
+obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o occ_sysfs.o
diff --git a/drivers/hwmon/occ/occ_sysfs.c b/drivers/hwmon/occ/occ_sysfs.c
new file mode 100644
index 000..ea2aa04
--- /dev/null
+++ b/drivers/hwmon/occ/occ_sysfs.c
@@ -0,0 +1,259 @@
+/*
+ * occ_sysfs.c - OCC sysfs interface
+ *
+ * This file contains the methods and data structures for implementing the OCC
+ * hwmon sysfs entries.
+ *
+ * Copyright 2016 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "occ.h"
+#include "occ_sysfs.h"
+
+#define RESP_RETURN_CMD_INVAL 0x13
+#define OCC_HWMON_NAME_LENGTH 32
+
+struct occ_sysfs {
+ struct device *dev;
+ struct occ *occ;
+
+ char hwmon_name[OCC_HWMON_NAME_LENGTH + 1];
+ const u32 *sensor_hwmon_configs;
+ str
[PATCH linux v4 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs
From: "Edward A. James" Add core support for polling the OCC for it's sensor data and parsing that data into sensor-specific information. Signed-off-by: Edward A. James Signed-off-by: Andrew Jeffery --- Documentation/hwmon/occ| 40 MAINTAINERS| 7 + drivers/hwmon/Kconfig | 2 + drivers/hwmon/Makefile | 1 + drivers/hwmon/occ/Kconfig | 15 ++ drivers/hwmon/occ/Makefile | 1 + drivers/hwmon/occ/occ.c| 479 + drivers/hwmon/occ/occ.h| 80 drivers/hwmon/occ/scom.h | 47 + 9 files changed, 672 insertions(+) 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/occ.c create mode 100644 drivers/hwmon/occ/occ.h create mode 100644 drivers/hwmon/occ/scom.h diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ new file mode 100644 index 000..79d1642 --- /dev/null +++ b/Documentation/hwmon/occ @@ -0,0 +1,40 @@ +Kernel driver occ += + +Supported chips: + * ASPEED AST2400 + * ASPEED AST2500 + +Please note that the chip must be connected to a POWER8 or POWER9 processor +(see the BMC - Host Communications section). + +Author: Eddie James + +Description +--- + +This driver implements support for the OCC (On-Chip Controller) on the IBM +POWER8 and POWER9 processors, from a BMC (Baseboard Management Controller). The +OCC is an embedded processor that provides real time power and thermal +monitoring. + +This driver provides an interface on a BMC to poll OCC sensor data, set user +power caps, and perform some basic OCC error handling. + +Currently, all versions of the OCC support four types of sensor data: power, +temperature, frequency, and "caps," which indicate limits and thresholds used +internally on the OCC. + +BMC - Host Communications +- + +For the POWER8 application, the BMC can communicate with the P8 over I2C bus. +However, to access the OCC register space, any data transfer must use a SCOM +operation. SCOM is a procedure to initiate a data transfer, typically of 8 +bytes. SCOMs consist of writing a 32-bit command register and then +reading/writing two 32-bit data registers. This driver implements these +SCOM operations over I2C bus in order to communicate with the OCC. + +For the POWER9 application, the BMC can communicate with the P9 over FSI bus +and SBE engine. Once again, SCOM operations are required. This driver will +implement SCOM ops over FSI/SBE. This will require the FSI driver. diff --git a/MAINTAINERS b/MAINTAINERS index 5f0420a..f5d4195 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9112,6 +9112,13 @@ T: git git://linuxtv.org/media_tree.git S: Maintained F: drivers/media/i2c/ov7670.c +ON-CHIP CONTROLLER HWMON DRIVER +M: Eddie James +L: linux-hw...@vger.kernel.org +S: Maintained +F: Documentation/hwmon/occ +F: drivers/hwmon/occ/ + ONENAND FLASH DRIVER M: Kyungmin Park L: linux-...@lists.infradead.org diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 190d270..e80ca81 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -1240,6 +1240,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 d2cb7e8..c7ec5d4 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -169,6 +169,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_PPC_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..cdb64a7 --- /dev/null +++ b/drivers/hwmon/occ/Kconfig @@ -0,0 +1,15 @@ +# +# On Chip Controller configuration +# + +menuconfig SENSORS_PPC_OCC + bool "PPC On-Chip Controller" + help + If you say yes here you get support to monitor Power CPU + sensors via the On-Chip Controller (OCC). + + Generally this is used by management controllers such as a BMC + on an OpenPower system. + + This driver can also be built as a module. If so, the module + will be called occ. diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile new file mode 100644 index 000..93cb52f --- /dev/null +++ b/drivers/hwmon/occ/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o diff --git a/drivers/hwmon/occ/occ.c b/drivers/hwmon/occ/occ.c new file mode 100644 index 000..3b233d8 --- /dev/null +++ b/drivers/hwmon/occ/occ.c @@ -0,0 +1,479
[PATCH linux v4 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations
From: "Edward A. James"
Add functions to send SCOM operations over I2C bus. The BMC can
communicate with the Power8 host processor over I2C, but needs to use SCOM
operations in order to access the OCC register space.
Signed-off-by: Edward A. James
Signed-off-by: Andrew Jeffery
---
drivers/hwmon/occ/occ_scom_i2c.c | 77
drivers/hwmon/occ/occ_scom_i2c.h | 26 ++
2 files changed, 103 insertions(+)
create mode 100644 drivers/hwmon/occ/occ_scom_i2c.c
create mode 100644 drivers/hwmon/occ/occ_scom_i2c.h
diff --git a/drivers/hwmon/occ/occ_scom_i2c.c b/drivers/hwmon/occ/occ_scom_i2c.c
new file mode 100644
index 000..74bd6ff
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.c
@@ -0,0 +1,77 @@
+/*
+ * occ_scom_i2c.c - hwmon OCC driver
+ *
+ * This file contains the functions for performing SCOM operations over I2C bus
+ * to access the OCC.
+ *
+ * Copyright 2016 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include "occ_scom_i2c.h"
+#include "scom.h"
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+ ssize_t rc;
+ u64 buf;
+ struct i2c_client *client = bus;
+ struct i2c_msg msgs[2];
+
+ msgs[0].addr = client->addr;
+ msgs[0].flags = client->flags & I2C_M_TEN;
+ msgs[0].len = sizeof(u32);
+ msgs[0].buf = (char *)&address;
+
+ msgs[1].addr = client->addr;
+ msgs[1].flags = client->flags & I2C_M_TEN;
+ msgs[1].flags |= I2C_M_RD;
+ msgs[1].len = sizeof(u64);
+ msgs[1].buf = (char *)&buf;
+
+ rc = i2c_transfer(client->adapter, msgs, 2);
+ if (rc < 0)
+ return rc;
+
+ *data = be64_to_cpu(buf);
+
+ return 0;
+}
+EXPORT_SYMBOL(occ_i2c_getscom);
+
+int occ_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1)
+{
+ u32 buf[3];
+ ssize_t rc;
+ struct i2c_client *client = bus;
+
+ /* send raw data, user can handle endian */
+ buf[0] = address;
+ buf[1] = data1;
+ buf[2] = data0;
+
+ rc = i2c_master_send(client, (const char *)buf, sizeof(u32) * 3);
+ if (rc < 0)
+ return rc;
+ else if (rc != sizeof(u32) * 3)
+ return -EIO;
+
+ return 0;
+}
+EXPORT_SYMBOL(occ_i2c_putscom);
+
+MODULE_AUTHOR("Eddie James ");
+MODULE_DESCRIPTION("I2C OCC SCOM transport");
+MODULE_LICENSE("GPL");
diff --git a/drivers/hwmon/occ/occ_scom_i2c.h b/drivers/hwmon/occ/occ_scom_i2c.h
new file mode 100644
index 000..945739c
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.h
@@ -0,0 +1,26 @@
+/*
+ * occ_scom_i2c.h - hwmon OCC driver
+ *
+ * This file contains function protoypes for peforming SCOM operations over I2C
+ * bus to access the OCC.
+ *
+ * Copyright 2016 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __OCC_SCOM_I2C_H__
+#define __OCC_SCOM_I2C_H__
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data);
+int occ_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1);
+
+#endif /* __OCC_SCOM_I2C_H__ */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH linux v4 4/6] hwmon: occ: Add callbacks for parsing P8 OCC datastructures
From: "Edward A. James"
Add functions to parse the data structures that are specific to the OCC on
the POWER8 processor. These are the sensor data structures, including
temperature, frequency, power, and "caps."
Signed-off-by: Edward A. James
Signed-off-by: Andrew Jeffery
---
Documentation/hwmon/occ| 9 ++
drivers/hwmon/occ/occ_p8.c | 247 +
drivers/hwmon/occ/occ_p8.h | 30 ++
3 files changed, 286 insertions(+)
create mode 100644 drivers/hwmon/occ/occ_p8.c
create mode 100644 drivers/hwmon/occ/occ_p8.h
diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index d0bdf06..143951e 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -25,6 +25,15 @@ Currently, all versions of the OCC support four types of
sensor data: power,
temperature, frequency, and "caps," which indicate limits and thresholds used
internally on the OCC.
+The format for the POWER8 OCC sensor data can be found in the P8 OCC
+specification:
+github.com/open-power/docs/blob/master/occ/OCC_OpenPwr_FW_Interfaces.pdf
+This document provides the details of the OCC sensors: power, frequency,
+temperature, and caps. These sensor formats are specific to the POWER8 OCC. A
+number of data structures, such as command format, response headers, and the
+like, are also defined in this specification, and are common to both POWER8 and
+POWER9 OCCs.
+
sysfs Entries
-
diff --git a/drivers/hwmon/occ/occ_p8.c b/drivers/hwmon/occ/occ_p8.c
new file mode 100644
index 000..32215ed
--- /dev/null
+++ b/drivers/hwmon/occ/occ_p8.c
@@ -0,0 +1,247 @@
+/*
+ * occ_p8.c - OCC hwmon driver
+ *
+ * This file contains the Power8-specific methods and data structures for
+ * the OCC hwmon driver.
+ *
+ * Copyright 2016 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "occ.h"
+#include "occ_p8.h"
+
+/* P8 OCC sensor data format */
+struct p8_occ_sensor {
+ u16 sensor_id;
+ u16 value;
+};
+
+struct p8_power_sensor {
+ u16 sensor_id;
+ u32 update_tag;
+ u32 accumulator;
+ u16 value;
+};
+
+struct p8_caps_sensor {
+ u16 curr_powercap;
+ u16 curr_powerreading;
+ u16 norm_powercap;
+ u16 max_powercap;
+ u16 min_powercap;
+ u16 user_powerlimit;
+};
+
+static const u32 p8_sensor_hwmon_configs[MAX_OCC_SENSOR_TYPE] = {
+ HWMON_I_INPUT | HWMON_I_LABEL, /* freq: value | label */
+ HWMON_T_INPUT | HWMON_T_LABEL, /* temp: value | label */
+ /* power: value | label | accumulator | update_tag */
+ HWMON_P_INPUT | HWMON_P_LABEL | HWMON_P_AVERAGE |
+ HWMON_P_AVERAGE_INTERVAL,
+ /* caps: curr | max | min | norm | user */
+ HWMON_P_CAP | HWMON_P_CAP_MAX | HWMON_P_CAP_MIN | HWMON_P_MAX |
+ HWMON_P_ALARM,
+};
+
+void p8_parse_sensor(u8 *data, void *sensor, int sensor_type, int off,
+int snum)
+{
+ switch (sensor_type) {
+ case FREQ:
+ case TEMP:
+ {
+ struct p8_occ_sensor *os =
+ &(((struct p8_occ_sensor *)sensor)[snum]);
+
+ os->sensor_id = be16_to_cpu(get_unaligned((u16 *)&data[off]));
+ os->value = be16_to_cpu(get_unaligned((u16 *)&data[off + 2]));
+ }
+ break;
+ case POWER:
+ {
+ struct p8_power_sensor *ps =
+ &(((struct p8_power_sensor *)sensor)[snum]);
+
+ ps->sensor_id = be16_to_cpu(get_unaligned((u16 *)&data[off]));
+ ps->update_tag =
+ be32_to_cpu(get_unaligned((u32 *)&data[off + 2]));
+ ps->accumulator =
+ be32_to_cpu(get_unaligned((u32 *)&data[off + 6]));
+ ps->value = be16_to_cpu(get_unaligned((u16 *)&data[off + 10]));
+ }
+ break;
+ case CAPS:
+ {
+ struct p8_caps_sensor *cs =
+ &(((struct p8_caps_sensor *)sensor)[snum]);
+
+ cs->curr_powercap =
+ be16_to_cpu(get_unaligned((u16 *)&data[off]));
+ cs->curr_powerreading =
+ be16_to_cpu(get_unaligned((u16 *)&data[off + 2]));
+ cs->norm_powercap =
+ be16_to_cpu(get_unaligned((u16 *)&data[off + 4]));
+ cs->max_powercap =
+ be16_
[PATCH linux v4 0/6] drivers: hwmon: Add On-Chip Controller drive
From: "Edward A. James" This patchset adds a hwmon driver to support the OCC (On-Chip Controller) on the IBM POWER8 and POWER9 processors, from a BMC (Baseboard Management Controller). The OCC is an embedded processor that provides real time power and thermal monitoring. The driver provides an interface on a BMC to poll OCC sensor data, set user power caps, and perform some basic OCC error handling. It interfaces with userspace through hwmon. The driver is currently functional only for the OCC on POWER8 chips. Communicating with the POWER9 OCC requries FSI support. Edward A. James (6): hwmon: Add core On-Chip Controller support for POWER CPUs hwmon: occ: Add sysfs interface hwmon: occ: Add I2C transport implementation for SCOM operations hwmon: occ: Add callbacks for parsing P8 OCC datastructures hwmon: occ: Add hwmon implementation for the P8 OCC hwmon: occ: Add callbacks for parsing P9 OCC datastructures Documentation/devicetree/bindings/hwmon/occ.txt | 13 + Documentation/hwmon/occ | 114 ++ MAINTAINERS | 7 + drivers/hwmon/Kconfig | 2 + drivers/hwmon/Makefile | 1 + drivers/hwmon/occ/Kconfig | 29 ++ drivers/hwmon/occ/Makefile | 2 + drivers/hwmon/occ/occ.c | 479 drivers/hwmon/occ/occ.h | 80 drivers/hwmon/occ/occ_p8.c | 247 drivers/hwmon/occ/occ_p8.h | 30 ++ drivers/hwmon/occ/occ_p9.c | 308 +++ drivers/hwmon/occ/occ_p9.h | 30 ++ drivers/hwmon/occ/occ_scom_i2c.c| 77 drivers/hwmon/occ/occ_scom_i2c.h| 26 ++ drivers/hwmon/occ/occ_sysfs.c | 259 + drivers/hwmon/occ/occ_sysfs.h | 30 ++ drivers/hwmon/occ/p8_occ_i2c.c | 104 + drivers/hwmon/occ/scom.h| 47 +++ 19 files changed, 1885 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/occ.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/occ.c create mode 100644 drivers/hwmon/occ/occ.h create mode 100644 drivers/hwmon/occ/occ_p8.c create mode 100644 drivers/hwmon/occ/occ_p8.h create mode 100644 drivers/hwmon/occ/occ_p9.c create mode 100644 drivers/hwmon/occ/occ_p9.h create mode 100644 drivers/hwmon/occ/occ_scom_i2c.c create mode 100644 drivers/hwmon/occ/occ_scom_i2c.h create mode 100644 drivers/hwmon/occ/occ_sysfs.c create mode 100644 drivers/hwmon/occ/occ_sysfs.h create mode 100644 drivers/hwmon/occ/p8_occ_i2c.c create mode 100644 drivers/hwmon/occ/scom.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH linux v4 5/6] hwmon: occ: Add hwmon implementation for the P8 OCC
From: "Edward A. James"
Add code to tie the hwmon sysfs code and the POWER8 OCC code together, as
well as probe the entire driver from the I2C bus. I2C is the communication
method between the BMC and the P8 OCC.
Signed-off-by: Edward A. James
Signed-off-by: Andrew Jeffery
---
Documentation/devicetree/bindings/hwmon/occ.txt | 13 +++
drivers/hwmon/occ/Kconfig | 14
drivers/hwmon/occ/Makefile | 1 +
drivers/hwmon/occ/p8_occ_i2c.c | 104
4 files changed, 132 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/occ.txt
create mode 100644 drivers/hwmon/occ/p8_occ_i2c.c
diff --git a/Documentation/devicetree/bindings/hwmon/occ.txt
b/Documentation/devicetree/bindings/hwmon/occ.txt
new file mode 100644
index 000..b0d2b36
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/occ.txt
@@ -0,0 +1,13 @@
+HWMON I2C driver for IBM POWER CPU OCC (On Chip Controller)
+
+Required properties:
+ - compatible: must be "ibm,p8-occ-i2c"
+ - reg: physical address
+
+Example:
+i2c3: i2c-bus@100 {
+ occ@50 {
+ compatible = "ibm,p8-occ-i2c";
+ reg = <0x50>;
+ };
+};
diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
index cdb64a7..3a5188f 100644
--- a/drivers/hwmon/occ/Kconfig
+++ b/drivers/hwmon/occ/Kconfig
@@ -13,3 +13,17 @@ menuconfig SENSORS_PPC_OCC
This driver can also be built as a module. If so, the module
will be called occ.
+
+if SENSORS_PPC_OCC
+
+config SENSORS_PPC_OCC_P8_I2C
+ tristate "POWER8 OCC hwmon support"
+ depends on I2C
+ help
+Provide a hwmon sysfs interface for the POWER8 On-Chip Controller,
+exposing temperature, frequency and power measurements.
+
+This driver can also be built as a module. If so, the module will be
+called p8-occ-i2c.
+
+endif
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index a6881f9..9294b58 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o occ_sysfs.o
+obj-$(CONFIG_SENSORS_PPC_OCC_P8_I2C) += occ_scom_i2c.o occ_p8.o p8_occ_i2c.o
diff --git a/drivers/hwmon/occ/p8_occ_i2c.c b/drivers/hwmon/occ/p8_occ_i2c.c
new file mode 100644
index 000..6273040
--- /dev/null
+++ b/drivers/hwmon/occ/p8_occ_i2c.c
@@ -0,0 +1,104 @@
+/*
+ * p8_occ_i2c.c - hwmon OCC driver
+ *
+ * This file contains the i2c layer for accessing the P8 OCC over i2c bus.
+ *
+ * Copyright 2016 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "occ_p8.h"
+#include "occ_scom_i2c.h"
+#include "occ_sysfs.h"
+#include "scom.h"
+
+#define P8_OCC_I2C_NAME"p8-occ-i2c"
+
+int p8_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+ /* P8 i2c slave requires address to be shifted by 1 */
+ address = address << 1;
+
+ return occ_i2c_getscom(bus, address, data);
+}
+
+int p8_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1)
+{
+ /* P8 i2c slave requires address to be shifted by 1 */
+ address = address << 1;
+
+ return occ_i2c_putscom(bus, address, data0, data1);
+}
+
+static struct occ_bus_ops p8_bus_ops = {
+ .getscom = p8_i2c_getscom,
+ .putscom = p8_i2c_putscom,
+};
+
+static int p8_occ_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct occ *occ;
+ struct occ_sysfs *hwmon;
+ const u32 *sensor_hwmon_configs = p8_get_sensor_hwmon_configs();
+
+ occ = p8_occ_start(&client->dev, client, &p8_bus_ops);
+ if (IS_ERR(occ))
+ return PTR_ERR(occ);
+
+ hwmon = occ_sysfs_start(&client->dev, occ, sensor_hwmon_configs,
+ P8_OCC_I2C_NAME);
+ if (IS_ERR(hwmon))
+ return PTR_ERR(hwmon);
+
+ i2c_set_clientdata(client, occ);
+
+ return 0;
+}
+
+/* used by old-style board info. */
+static const struct i2c_device_id occ_ids[] = {
+ { P8_OCC_I2C_NAME, 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, occ_ids);
+
+/* used by device table */
+static const struct of_device_id occ_of_match[] = {
+ { .compatible = "ibm,p8-occ-i2c" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, occ_of_match);
+
+static struct i2c_driver p8_occ_driver = {
+ .class = I2C_CLASS_HWMON,
+ .driver = {
+ .name = P8
[PATCH linux v4 6/6] hwmon: occ: Add callbacks for parsing P9 OCC datastructures
From: "Edward A. James"
Add functions to parse the data structures that are specific to the OCC on
the POWER9 processor. These are the sensor data structures, including
temperature, frequency, power, and "caps."
Signed-off-by: Edward A. James
Signed-off-by: Andrew Jeffery
---
Documentation/hwmon/occ| 3 +
drivers/hwmon/occ/occ_p9.c | 308 +
drivers/hwmon/occ/occ_p9.h | 30 +
3 files changed, 341 insertions(+)
create mode 100644 drivers/hwmon/occ/occ_p9.c
create mode 100644 drivers/hwmon/occ/occ_p9.h
diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index 143951e..6cea853 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -34,6 +34,9 @@ number of data structures, such as command format, response
headers, and the
like, are also defined in this specification, and are common to both POWER8 and
POWER9 OCCs.
+There is currently no public P9 OCC specification, and the data structures
+defined in the POWER9 OCC driver are subject to change.
+
sysfs Entries
-
diff --git a/drivers/hwmon/occ/occ_p9.c b/drivers/hwmon/occ/occ_p9.c
new file mode 100644
index 000..d99a026
--- /dev/null
+++ b/drivers/hwmon/occ/occ_p9.c
@@ -0,0 +1,308 @@
+/*
+ * occ_p9.c - OCC hwmon driver
+ *
+ * This file contains the Power9-specific methods and data structures for
+ * the OCC hwmon driver.
+ *
+ * Copyright 2016 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "occ.h"
+#include "occ_p9.h"
+
+/* P9 OCC sensor data format */
+struct p9_temp_sensor {
+ u32 sensor_id;
+ u8 fru_type;
+ u8 value;
+};
+
+struct p9_freq_sensor {
+ u32 sensor_id;
+ u16 value;
+};
+
+struct p9_power_sensor {
+ u32 sensor_id;
+ u8 function_id;
+ u8 apss_channel;
+ u16 reserved;
+ u32 update_tag;
+ u64 accumulator;
+ u16 value;
+};
+
+struct p9_caps_sensor {
+ u16 curr_powercap;
+ u16 curr_powerreading;
+ u16 norm_powercap;
+ u16 max_powercap;
+ u16 min_powercap;
+ u16 user_powerlimit;
+ u8 user_powerlimit_source;
+};
+
+static const u32 p9_sensor_hwmon_configs[MAX_OCC_SENSOR_TYPE] = {
+ HWMON_I_INPUT | HWMON_I_LABEL, /* freq: value | label */
+ /* temp: value | label | fru_type */
+ HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_TYPE,
+ /* power: value | label | accum[0] | accum[1] | update_tag |
+* (function_id | (apss_channel << 8))
+*/
+ HWMON_P_INPUT | HWMON_P_LABEL | HWMON_P_AVERAGE_MIN |
+ HWMON_P_AVERAGE_MAX | HWMON_P_AVERAGE_INTERVAL |
+ HWMON_P_RESET_HISTORY,
+ /* caps: curr | max | min | norm | user | source */
+ HWMON_P_CAP | HWMON_P_CAP_MAX | HWMON_P_CAP_MIN | HWMON_P_MAX |
+ HWMON_P_ALARM | HWMON_P_CAP_ALARM,
+};
+
+void p9_parse_sensor(u8 *data, void *sensor, int sensor_type, int off,
+int snum)
+{
+ switch (sensor_type) {
+ case FREQ:
+ {
+ struct p9_freq_sensor *fs =
+ &(((struct p9_freq_sensor *)sensor)[snum]);
+
+ fs->sensor_id = be32_to_cpu(get_unaligned((u32 *)&data[off]));
+ fs->value = be16_to_cpu(get_unaligned((u16 *)&data[off + 4]));
+ }
+ break;
+ case TEMP:
+ {
+ struct p9_temp_sensor *ts =
+ &(((struct p9_temp_sensor *)sensor)[snum]);
+
+ ts->sensor_id = be32_to_cpu(get_unaligned((u32 *)&data[off]));
+ fs->fru_type = data[off + 4];
+ fs->value = data[off + 5];
+ }
+ break;
+ case POWER:
+ {
+ struct p9_power_sensor *ps =
+ &(((struct p9_power_sensor *)sensor)[snum]);
+
+ ps->sensor_id = be32_to_cpu(get_unaligned((u32 *)&data[off]));
+ ps->function_id = data[off + 4];
+ ps->apss_channel = data[off + 5];
+ ps->update_tag =
+ be32_to_cpu(get_unaligned((u32 *)&data[off + 8]));
+ ps->accumulator =
+ be64_to_cpu(get_unaligned((u64 *)&data[off + 12]));
+ ps->value = be16_to_cpu(get_unaligned((u16 *)&data[off + 20]));
+ }
+ break;
+ case CAPS:
+ {
+ struct p9_caps_sensor *cs =
+
Re: [PATCH linux v4 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs
Hi Edward,
[auto build test ERROR on hwmon/hwmon-next]
[also build test ERROR on v4.10-rc5 next-20170125]
[cannot apply to linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/eajames-ibm-gmail-com/drivers-hwmon-Add-On-Chip-Controller-drive/20170127-073116
base:
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
hwmon-next
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha
All error/warnings (new ones prefixed by >>):
In file included from include/linux/linkage.h:6:0,
from include/linux/kernel.h:6,
from include/linux/unaligned/packed_struct.h:4,
from include/linux/unaligned/le_struct.h:4,
from arch/alpha/include/asm/unaligned.h:4,
from drivers/hwmon/occ/occ.c:19:
>> drivers/hwmon/occ/occ.c:433:15: error: 'occ_get_sensor_value' undeclared
>> here (not in a function)
EXPORT_SYMBOL(occ_get_sensor_value);
^
include/linux/export.h:58:16: note: in definition of macro '___EXPORT_SYMBOL'
extern typeof(sym) sym; \
^~~
>> drivers/hwmon/occ/occ.c:433:1: note: in expansion of macro 'EXPORT_SYMBOL'
EXPORT_SYMBOL(occ_get_sensor_value);
^
vim +/occ_get_sensor_value +433 drivers/hwmon/occ/occ.c
427
428 int occ_get_sensor_field(struct occ *occ, int sensor_type, int
sensor_num,
429 u32 hwmon, long *val)
430 {
431 return occ->ops.get_sensor(occ, sensor_type, sensor_num, hwmon,
val);
432 }
> 433 EXPORT_SYMBOL(occ_get_sensor_value);
434
435 void occ_get_response_blocks(struct occ *occ, struct occ_blocks
**blocks)
436 {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v2 1/3] zh_CN/CodingStyle: improve translation
2017-01-27 6:40 GMT+08:00 Jonathan Corbet : > OK, I've applied the whole set, thanks. Thanks for applying! > One thing, though: your messages came through with this header: > > Content-Type: text/plain; charset=y > > The screwy "charset=y" puts "git am" into a severely uncooperative mood, > so I had to edit your messages by hand to apply them. Mauro (copied), do > I remember correctly that you figured out how that was happening to your > emails? It would be good to get that understood, documented, and maybe > even fixed... Oh, I think I found the reason, it's my fault... I used git send-email to send the patch set, git asked me: "Which 8bit encoding should I declare [UTF-8]?" Then I pressed 'y' and hit 'Enter', thus, the header becomes: Content-Type: text/plain; charset=y charset should be "UTF-8", not 'y'... I apologize for the mistake. Today is Chinese New Year's Eve, have a nice day and give my best wishes to you. Thanks, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
