[PATCH] Add a target to check broken external links in the Documentation
From: Rémy Léone Signed-off-by: Rémy Léone --- Documentation/Makefile.sphinx | 3 +++ Documentation/conf.py | 2 +- Makefile | 2 +- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx index 707c653..bfacb1b 100644 --- a/Documentation/Makefile.sphinx +++ b/Documentation/Makefile.sphinx @@ -68,6 +68,9 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4) htmldocs: @$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,html,$(var),,$(var))) +linkcheck: + @$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,linkcheck,$(var),,$(var))) + latexdocs: @$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,latex,$(var),latex,$(var))) diff --git a/Documentation/conf.py b/Documentation/conf.py index 1ac958c..324fa92 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -34,7 +34,7 @@ from load_config import loadConfig # Add any Sphinx extension module names here, as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom # ones. -extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain'] +extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'sphinx.builders.linkcheck'] # The name of the math extension changed on Sphinx 1.4 if major == 1 and minor > 3: diff --git a/Makefile b/Makefile index 96e2352..1f93b3c 100644 --- a/Makefile +++ b/Makefile @@ -1444,7 +1444,7 @@ $(help-board-dirs): help-%: # Documentation targets # --- -DOC_TARGETS := xmldocs sgmldocs psdocs latexdocs pdfdocs htmldocs mandocs installmandocs epubdocs cleandocs +DOC_TARGETS := xmldocs sgmldocs psdocs latexdocs pdfdocs htmldocs mandocs installmandocs epubdocs cleandocs linkcheck PHONY += $(DOC_TARGETS) $(DOC_TARGETS): scripts_basic FORCE $(Q)$(MAKE) $(build)=scripts build_docproc build_check-lc_ctype -- 2.7.4 -- 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] Add a target to check broken external links in the Documentation
Hi Remy, I like what this does, and it'll be helpful in ensuring we
don't have broken links. However, there are some issues.
On Tue, 14 Feb 2017, Remy Leone wrote:
> From: Rémy Léone
This area here is for the commit message, describing what linkcheck
does, why you think it's a good idea, and that anyone running it should
be aware that it'll try to connect to all URLs referenced in the
documentation.
This also needs a line in 'make help' output, with the warning that
it'll connect.
> Signed-off-by: Rémy Léone
> ---
> Documentation/Makefile.sphinx | 3 +++
> Documentation/conf.py | 2 +-
> Makefile | 2 +-
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
> index 707c653..bfacb1b 100644
> --- a/Documentation/Makefile.sphinx
> +++ b/Documentation/Makefile.sphinx
> @@ -68,6 +68,9 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath
> $(BUILDDIR)/$3/$4)
> htmldocs:
> @$(foreach var,$(SPHINXDIRS),$(call
> loop_cmd,sphinx,html,$(var),,$(var)))
>
> +linkcheck:
> + @$(foreach var,$(SPHINXDIRS),$(call
> loop_cmd,sphinx,linkcheck,$(var),,$(var)))
Documentation/DocBook/Makefile needs a no-op target for
linkcheck. Unfortunately, so does Documentation/media/Makefile. (Did you
not see the "make[2]: *** No rule to make target 'linkcheck'. Stop."
warnings?)
> +
> latexdocs:
> @$(foreach var,$(SPHINXDIRS),$(call
> loop_cmd,sphinx,latex,$(var),latex,$(var)))
>
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index 1ac958c..324fa92 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -34,7 +34,7 @@ from load_config import loadConfig
> # Add any Sphinx extension module names here, as strings. They can be
> # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
> # ones.
> -extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain']
> +extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain',
> 'sphinx.builders.linkcheck']
This results in "WARNING: extension 'sphinx.builders.linkcheck' has no
setup() function; is it really a Sphinx extension module?"
I don't think you need to add builders to extensions at all, do you?
Seems to work just fine without.
>
> # The name of the math extension changed on Sphinx 1.4
> if major == 1 and minor > 3:
> diff --git a/Makefile b/Makefile
> index 96e2352..1f93b3c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1444,7 +1444,7 @@ $(help-board-dirs): help-%:
>
> # Documentation targets
> # ---
> -DOC_TARGETS := xmldocs sgmldocs psdocs latexdocs pdfdocs htmldocs mandocs
> installmandocs epubdocs cleandocs
> +DOC_TARGETS := xmldocs sgmldocs psdocs latexdocs pdfdocs htmldocs mandocs
> installmandocs epubdocs cleandocs linkcheck
Historically the documentation targets were '%docs', i.e. anything with
the docs suffix. I thought it would be better to call out the targets
explicitly, but perhaps that's not the case if it encourages targets
without docs suffix. Otherwise we'll have to keep touching
no-dot-config-targets too, which is not desirable ('make linkcheck'
as-is runs the config target).
In short, I think this should be called linkcheckdocs.
BR,
Jani.
> PHONY += $(DOC_TARGETS)
> $(DOC_TARGETS): scripts_basic FORCE
> $(Q)$(MAKE) $(build)=scripts build_docproc build_check-lc_ctype
--
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
[PATCH] perf: fix documentation of sysctls perf_event_paranoid and perf_event_mlock_kb
Fix misprint CAP_IOC_LOCK -> CAP_IPC_LOCK. This capability have nothing to do with raw tracepoints. This part is about bypassing mlock limits. Sysctl kernel.perf_event_paranoid = -1 allows raw and ftrace function tracepoints without CAP_SYS_ADMIN. Signed-off-by: Konstantin Khlebnikov --- Documentation/sysctl/kernel.txt | 13 - tools/perf/util/evsel.c |4 +++- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index a32b4b748644..f1272ff1fcb5 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -61,6 +61,7 @@ show up in /proc/sys/kernel: - perf_cpu_time_max_percent - perf_event_paranoid - perf_event_max_stack +- perf_event_mlock_kb - perf_event_max_contexts_per_stack - pid_max - powersave-nap [ PPC only ] @@ -654,7 +655,9 @@ Controls use of the performance events system by unprivileged users (without CAP_SYS_ADMIN). The default value is 2. -1: Allow use of (almost) all events by all users ->=0: Disallow raw tracepoint access by users without CAP_IOC_LOCK + Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK +>=0: Disallow ftrace function tracepoint by users without CAP_SYS_ADMIN + Disallow raw tracepoint access by users without CAP_SYS_ADMIN >=1: Disallow CPU event access by users without CAP_SYS_ADMIN >=2: Disallow kernel profiling by users without CAP_SYS_ADMIN @@ -673,6 +676,14 @@ The default value is 127. == +perf_event_mlock_kb: + +Control size of per-cpu ring buffer not counted agains mlock limit. + +The default value is 512 + 1 page + +== + perf_event_max_contexts_per_stack: Controls maximum number of stack frame context entries for diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 04e536ae4d88..9932de565aa7 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -2467,7 +2467,9 @@ int perf_evsel__open_strerror(struct perf_evsel *evsel, struct target *target, "unprivileged users (without CAP_SYS_ADMIN).\n\n" "The current value is %d:\n\n" " -1: Allow use of (almost) all events by all users\n" -">= 0: Disallow raw tracepoint access by users without CAP_IOC_LOCK\n" +" Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK\n" +">= 0: Disallow ftrace function tracepoint by users without CAP_SYS_ADMIN\n" +" Disallow raw tracepoint access by users without CAP_SYS_ADMIN\n" ">= 1: Disallow CPU event access by users without CAP_SYS_ADMIN\n" ">= 2: Disallow kernel profiling by users without CAP_SYS_ADMIN", target->system_wide ? "system-wide " : "", -- 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 v2] Add a target to check broken external links in the Documentation
From: Rémy Léone
Documentation shouldn't have broken links.
sphinx linkcheck builder scans all documents for external links, tries
to open them with urllib2, and writes an overview which ones are broken
and redirected to standard output and to output.txt in the output
directory.
Signed-off-by: Rémy Léone
---
Changes in v2:
- Add a more descriptive commit message
- Add message to make help output about connection to external host
- Add no-op for:
- Documentation/DocBook/Makefile
- Documentation/media/Makefile
- Remove sphinx.builders.linkcheck include
- Change from linkcheck to linkcheckdocs
Documentation/DocBook/Makefile | 1 +
Documentation/Makefile.sphinx | 4
Documentation/media/Makefile | 1 +
Makefile | 2 +-
4 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index a6eb7dc..035a6dd 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -71,6 +71,7 @@ installmandocs: mandocs
# no-op for the DocBook toolchain
epubdocs:
latexdocs:
+linkcheckdocs:
###
#External programs used
diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
index 707c653..c320458 100644
--- a/Documentation/Makefile.sphinx
+++ b/Documentation/Makefile.sphinx
@@ -68,6 +68,9 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath
$(BUILDDIR)/$3/$4)
htmldocs:
@$(foreach var,$(SPHINXDIRS),$(call
loop_cmd,sphinx,html,$(var),,$(var)))
+linkcheckdocs:
+ @$(foreach var,$(SPHINXDIRS),$(call
loop_cmd,sphinx,linkcheck,$(var),,$(var)))
+
latexdocs:
@$(foreach var,$(SPHINXDIRS),$(call
loop_cmd,sphinx,latex,$(var),latex,$(var)))
@@ -109,6 +112,7 @@ dochelp:
@echo ' pdfdocs - PDF'
@echo ' epubdocs- EPUB'
@echo ' xmldocs - XML'
+ @echo ' linkcheckdocs - check for broken external links (will
connect to external hosts)'
@echo ' cleandocs - clean all generated files'
@echo
@echo ' make SPHINXDIRS="s1 s2" [target] Generate only docs of folder
s1, s2'
diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
index 3266360..d576ef1 100644
--- a/Documentation/media/Makefile
+++ b/Documentation/media/Makefile
@@ -103,6 +103,7 @@ html: all
epub: all
xml: all
latex: $(IMGPDF) all
+linkcheckdocs:
clean:
-rm -f $(DOTTGT) $(IMGTGT) ${TARGETS} 2>/dev/null
diff --git a/Makefile b/Makefile
index 96e2352..416849c0 100644
--- a/Makefile
+++ b/Makefile
@@ -1444,7 +1444,7 @@ $(help-board-dirs): help-%:
# Documentation targets
# ---
-DOC_TARGETS := xmldocs sgmldocs psdocs latexdocs pdfdocs htmldocs mandocs
installmandocs epubdocs cleandocs
+DOC_TARGETS := xmldocs sgmldocs psdocs latexdocs pdfdocs htmldocs mandocs
installmandocs epubdocs cleandocs linkcheckdocs
PHONY += $(DOC_TARGETS)
$(DOC_TARGETS): scripts_basic FORCE
$(Q)$(MAKE) $(build)=scripts build_docproc build_check-lc_ctype
--
2.7.4
--
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] Add a target to check broken external links in the Documentation
Hello Thanks for the quick answer. Le 14/02/2017 à 13:28, Jani Nikula a écrit : Hi Remy, I like what this does, and it'll be helpful in ensuring we don't have broken links. However, there are some issues. It's my first Linux kernel patch so this was expected :) Documentation/DocBook/Makefile needs a no-op target for linkcheck. Unfortunately, so does Documentation/media/Makefile. (Did you not see the "make[2]: *** No rule to make target 'linkcheck'. Stop." warnings?) I've seen those warnings but I don't really know how to make them disappear. I've added no-op operation on both Makefile: Documentation/DocBook/Makefile Documentation/media/Makefile I've submitted a new patch. I've got a question, when I receive review on a patch, is it better to resubmit or to reply inside the same thread? Thanks again :) Best regards Rémy -- 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] Add a target to check broken external links in the Documentation
On Tue, 14 Feb 2017, Remy Leone wrote: > I've got a question, when I receive review on a patch, is it better to > resubmit or to reply inside the same thread? Depends on the subsystem, maintainer, and the phase of the Moon. ;) I'm not the documentation maintainer, but personally I prefer sending updated patches in-reply-to the previous ones when they are single patches or updates to just a few patches in a series. When updating more than a few patches in a series, I'd repost the entire series as a new thread and reference the previous series in a cover letter. 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: [PATCH] Add a target to check broken external links in the Documentation
On Tue, 14 Feb 2017 15:52:10 +0200 Jani Nikula wrote: > On Tue, 14 Feb 2017, Remy Leone wrote: > > I've got a question, when I receive review on a patch, is it better to > > resubmit or to reply inside the same thread? > > Depends on the subsystem, maintainer, and the phase of the Moon. ;) > > I'm not the documentation maintainer, but personally I prefer sending > updated patches in-reply-to the previous ones when they are single > patches or updates to just a few patches in a series. When updating more > than a few patches in a series, I'd repost the entire series as a new > thread and reference the previous series in a cover letter. I don't have strong opinions on this matter, but my general preference is to get revised patches in a new thread; they stand out a bit more in my disastrous inbox that way... 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] Add a target to check broken external links in the Documentation
I got another question. There is a lot of broken links. Should I do a big commit to fix all of them at once? What would be the best workflow to fix all those errors? Best regards Rémy Le 14/02/2017 à 15:15, Jonathan Corbet a écrit : On Tue, 14 Feb 2017 15:52:10 +0200 Jani Nikula wrote: On Tue, 14 Feb 2017, Remy Leone wrote: I've got a question, when I receive review on a patch, is it better to resubmit or to reply inside the same thread? Depends on the subsystem, maintainer, and the phase of the Moon. ;) I'm not the documentation maintainer, but personally I prefer sending updated patches in-reply-to the previous ones when they are single patches or updates to just a few patches in a series. When updating more than a few patches in a series, I'd repost the entire series as a new thread and reference the previous series in a cover letter. I don't have strong opinions on this matter, but my general preference is to get revised patches in a new thread; they stand out a bit more in my disastrous inbox that way... 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] Add a target to check broken external links in the Documentation
On Tue, 14 Feb 2017, Jonathan Corbet wrote: > On Tue, 14 Feb 2017 15:52:10 +0200 > Jani Nikula wrote: > >> On Tue, 14 Feb 2017, Remy Leone wrote: >> > I've got a question, when I receive review on a patch, is it better to >> > resubmit or to reply inside the same thread? >> >> Depends on the subsystem, maintainer, and the phase of the Moon. ;) >> >> I'm not the documentation maintainer, but personally I prefer sending >> updated patches in-reply-to the previous ones when they are single >> patches or updates to just a few patches in a series. When updating more >> than a few patches in a series, I'd repost the entire series as a new >> thread and reference the previous series in a cover letter. > > I don't have strong opinions on this matter, but my general preference is > to get revised patches in a new thread; they stand out a bit more in my > disastrous inbox that way... This reminds me, Remy, it's generally preferred to Cc any people who have commented on your patch when sending updated versions. 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: [PATCH] Add a target to check broken external links in the Documentation
On Tue, 14 Feb 2017 15:22:12 +0100 Remy Leone wrote: > I got another question. There is a lot of broken links. Should I do a big > commit to fix all of them at once? What would be the best workflow to fix > all those errors? I'd suggest starting small, since you're just getting going with all this. One other hint for dealing with crotchety kernel folks: try to avoid top-posting when replying to email. It really does make it harder to follow the discussions... 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] cdrom: Make device operations read-only
On 02/13/2017 05:25 PM, Kees Cook wrote: > Since function tables are a common target for attackers, it's best to keep > them in read-only memory. As such, this makes the CDROM device ops tables > const. This drops additionally n_minors, since it isn't used meaningfully, > and sets the only user of cdrom_dummy_generic_packet explicitly so the > variables can all be const. Agree, it's a good change. Applied for 4.11. -- Jens Axboe -- 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 v7 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs
On 02/09/2017 11:31 PM, Joel Stanley wrote:
On Wed, Feb 8, 2017 at 9:40 AM, wrote:
diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
new file mode 100644
index 000..79d1642
--- /dev/null
+++ b/Documentation/hwmon/occ
The kernel is using reStructuredText these days. You should consider
following suit:
https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html#writing-documentation
@@ -0,0 +1,40 @@
+Kernel driver occ
+=
+
+Supported chips:
+ * ASPEED AST2400
+ * ASPEED AST2500
Not really - this will run on any chip that's connected to a P8 or P9.
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f10c28..193a13b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9128,6 +9128,13 @@ T: git git://linuxtv.org/media_tree.git
S: Maintained
F: drivers/media/i2c/ov7670.c
+ON-CHIP CONTROLLER HWMON DRIVER
Mention P8 and P9?
+M: Eddie James
+L: linux-hw...@vger.kernel.org
Have you subscribed to this list? Would you prefer the mail to come to
the openbmc list?
+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/occ.c b/drivers/hwmon/occ/occ.c
new file mode 100644
index 000..af077f2
--- /dev/null
+++ b/drivers/hwmon/occ/occ.c
+ sensors = &resp->data.blocks[b].sensors;
+ if (!sensors) {
+ /* first poll response */
+ sensors = driver->ops.alloc_sensor(dev, sensor_type,
+ block->num_sensors);
+ if (!sensors)
+ return -ENOMEM;
+
+ resp->data.blocks[b].sensors = sensors;
+ resp->data.sensor_block_id[sensor_type] = b;
+ resp->data.blocks[b].header = *block;
+ } else if (block->sensor_length !=
+resp->data.blocks[b].header.sensor_length) {
+ dev_warn(dev,
+"different sensor length than first poll\n");
The driver has changed behaviour from your previous version; now it
discards data if the sensors change.
Under what circumstances does the sensor data change?
+ continue;
+ }
+
+ for (s = 0; s < block->num_sensors &&
+s < resp->data.blocks[b].header.num_sensors; s++) {
+ if (offset + block->sensor_length > num_bytes) {
+ dev_warn(dev, "exceeded data length\n");
+ return 0;
+ }
+
+ driver->ops.parse_sensor(data, sensors, sensor_type,
+offset, s);
+ offset += block->sensor_length;
+ }
+ }
+
+ return 0;
+}
+
+static u8 occ_send_cmd(struct occ *driver, u8 seq, u8 type, u16 length,
+ const u8 *data, u8 *resp)
+{
+ u32 cmd1, cmd2 = 0;
+ u16 checksum = 0;
+ bool retry = false;
+ int i, rc, tries = 0;
+
+ cmd1 = (seq << 24) | (type << 16) | length;
+ memcpy(&cmd2, data, length);
+ cmd2 <<= ((4 - length) * 8);
+
+ /* checksum: sum of every bytes of cmd1, cmd2 */
+ for (i = 0; i < 4; i++) {
+ checksum += (cmd1 >> (i * 8)) & 0xFF;
+ checksum += (cmd2 >> (i * 8)) & 0xFF;
+ }
+
+ cmd2 |= checksum << ((2 - length) * 8);
+
+ /* Init OCB */
You should mention what OCB means in your documentation.
+ rc = driver->bus_ops.putscom(driver->bus, OCB_STATUS_CONTROL_OR,
+OCB_OR_INIT0, OCB_OR_INIT1);
+ if (rc)
+ goto err;
+
+int occ_set_user_powercap(struct occ *occ, u16 cap)
+{
+ u8 resp[8];
+
+ cap = cpu_to_be16(cap);
+
+ return occ_send_cmd(occ, 0, OCC_SET_USER_POWR_CAP, 2, (const u8 *)&cap,
+ resp);
+}
+
Re: [PATCH v4 1/1] DM: inplace compressed DM target (fwd)
On Tue, Feb 14, 2017 at 07:09:04AM +0100, Julia Lawall wrote:
> On line 1759, since ret is unsigned it will not be less than 0.
Thanks fixed it. Infact noticed that dm_icomp_io_range_compress() had missed a
case where
it was supposed to return error; a negative number. Fixed that aswell.
RP
>
> julia
>
> -- Forwarded message --
> Date: Tue, 14 Feb 2017 09:00:39 +0800
> From: kbuild test robot
> To: kbu...@01.org
> Cc: Julia Lawall
> Subject: Re: [PATCH v4 1/1] DM: inplace compressed DM target
>
> CC: kbuild-...@01.org
> In-Reply-To: <1487018545-5061-2-git-send-email-linux...@us.ibm.com>
>
> Hi Ram,
>
> [auto build test WARNING on dm/for-next]
> [also build test WARNING on v4.10-rc8 next-20170213]
> [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/Ram-Pai/DM-inplace-compressed-DM-target/20170214-055727
> base:
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
> for-next
> :: branch date: 3 hours ago
> :: commit date: 3 hours ago
>
> >> drivers/md/dm-inplace-compress.c:1759:5-8: WARNING: Unsigned expression
> >> compared with zero: ret < 0
>
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout e7924efaaba5efdcd28f32efbb949ed1153c932c
> vim +1759 drivers/md/dm-inplace-compress.c
>
> e7924efa Ram Pai 2017-02-13 1743 * @io : io range
> e7924efa Ram Pai 2017-02-13 1744 * @sector_start : the sector on backing
> storage to which the
> e7924efa Ram Pai 2017-02-13 1745 * compressed data needs to be written.
> e7924efa Ram Pai 2017-02-13 1746 * @meta_start: the page index of the bits
> corresponding to
> e7924efa Ram Pai 2017-02-13 1747 * @meta_end : start and end blocks.
> e7924efa Ram Pai 2017-02-13 1748 */
> e7924efa Ram Pai 2017-02-13 1749 static int dm_icomp_compress_write(struct
> dm_icomp_io_range *io,
> e7924efa Ram Pai 2017-02-13 1750 sector_t sector_start, u64
> *meta_start, u64 *meta_end)
> e7924efa Ram Pai 2017-02-13 1751 {
> e7924efa Ram Pai 2017-02-13 1752 struct dm_icomp_req *req = io->req;
> e7924efa Ram Pai 2017-02-13 1753 sector_t count =
> DMCP_BYTES_TO_SECTOR(io->decomp_len);
> e7924efa Ram Pai 2017-02-13 1754 unsigned int comp_len, ret;
> e7924efa Ram Pai 2017-02-13 1755 u64 page_index;
> e7924efa Ram Pai 2017-02-13 1756
> e7924efa Ram Pai 2017-02-13 1757 /* comp_data must be able to
> accommadate a larger compress buffer */
> e7924efa Ram Pai 2017-02-13 1758 ret =
> dm_icomp_io_range_compress(req->info, io, &comp_len);
> e7924efa Ram Pai 2017-02-13 @1759 if (ret < 0) {
> e7924efa Ram Pai 2017-02-13 1760 req->result = -EIO;
> e7924efa Ram Pai 2017-02-13 1761 return -EIO;
> e7924efa Ram Pai 2017-02-13 1762 }
> e7924efa Ram Pai 2017-02-13 1763 WARN_ON(comp_len > io->comp_len);
> e7924efa Ram Pai 2017-02-13 1764
> e7924efa Ram Pai 2017-02-13 1765 dm_icomp_get_req(req);
> e7924efa Ram Pai 2017-02-13 1766
> e7924efa Ram Pai 2017-02-13 1767 io->io_req.bi_op = REQ_OP_WRITE;
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
Ram Pai
--
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
make pdfdocs errors with 4.10-rc8
On a Fedora 25 system,
[...]
build succeeded, 32 warnings.
make PDFLATEX=xelatex LATEXOPTS="-interaction=batchmode" -C
Documentation/output/./latex;
xelatex -interaction=batchmode 'linux-user.tex'
This is XeTeX, Version 3.14159265-2.6-0.6 (TeX Live 2016)
(preloaded format=xelatex)
restricted \write18 enabled.
entering extended mode
Makefile:66: recipe for target 'linux-user.pdf' failed
Documentation/Makefile.sphinx:83: recipe for target 'pdfdocs' failed
Makefile:1450: recipe for target 'pdfdocs' failed
where Documentation/output/latex/linux-user.log contains
[jim@krebstar latex]$ grep '^!' linux-user.log | sort -u
! Extra }, or forgotten \endgroup.
! Missing } inserted.
and that happens often enough that Tex bails:
[jim@krebstar latex]$ tail -20 linux-user.log
[...]
! Extra }, or forgotten \endgroup.
}
l.14911 \hline\end{tabulary}
(That makes 100 errors; please try again.)
[...]
--
Jim
--
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 v8 0/6] drivers: hwmon: Add On-Chip Controller driver
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. Since v7: * change Makefile and Kconfig to build a single module for the driver * include p9 file in build * change Kconfig from "PPC" to "IBM" * remove EXPORT_SYMBOL * bundle occ_config and occ_ops structures into occ_init_data structure * few style tweaks suggested by Joel 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 | 116 +++ MAINTAINERS | 7 + drivers/hwmon/Kconfig | 2 + drivers/hwmon/Makefile | 1 + drivers/hwmon/occ/Kconfig | 39 +++ drivers/hwmon/occ/Makefile | 5 + drivers/hwmon/occ/occ.c | 440 drivers/hwmon/occ/occ.h | 77 + drivers/hwmon/occ/occ_p8.c | 256 ++ drivers/hwmon/occ/occ_p8.h | 25 ++ drivers/hwmon/occ/occ_p8_i2c.c | 99 ++ drivers/hwmon/occ/occ_p9.c | 320 + drivers/hwmon/occ/occ_p9.h | 25 ++ drivers/hwmon/occ/occ_scom_i2c.c| 69 drivers/hwmon/occ/occ_scom_i2c.h| 21 ++ drivers/hwmon/occ/occ_sysfs.c | 245 + drivers/hwmon/occ/occ_sysfs.h | 25 ++ drivers/hwmon/occ/scom.h| 42 +++ 19 files changed, 1827 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_p8_i2c.c 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/scom.h -- 1.8.3.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 v8 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 | 245 ++
drivers/hwmon/occ/occ_sysfs.h | 25 +
4 files changed, 333 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 d1c863b..580af26 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -27,6 +27,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 3ed79a5..67b5367 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o
+obj-$(CONFIG_SENSORS_IBM_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..d6baf8d
--- /dev/null
+++ b/drivers/hwmon/occ/occ_sysfs.c
@@ -0,0 +1,245 @@
+/*
+ * occ_sysfs.c - OCC sysfs interface
+ *
+ * This file contains the methods and data structures for implementing the OCC
+ * hwmon sysfs entries.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "occ.h"
+#include "occ_sysfs.h"
+
+#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;
+ struct hwmon_channel_info **occ_sensors;
+ struct hwmon_chip_info occ_info;
+ u16 user_powercap;
+};
+
+static int occ_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *val)
+{
+ int rc;
+ struct occ_sy
[PATCH linux v8 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/Kconfig | 11 ++
drivers/hwmon/occ/Makefile | 2 +
drivers/hwmon/occ/occ_p9.c | 320 +
drivers/hwmon/occ/occ_p9.h | 25
5 files changed, 361 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 4ec8842..8fb3f41 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -36,6 +36,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/Kconfig b/drivers/hwmon/occ/Kconfig
index d521720..5b8ca27 100644
--- a/drivers/hwmon/occ/Kconfig
+++ b/drivers/hwmon/occ/Kconfig
@@ -25,4 +25,15 @@ config SENSORS_IBM_OCC_P8_I2C
This driver can also be built as a module. If so, the module will be
called hwmon_occ_p8.
+config SENSORS_IBM_OCC_P9
+ tristate "POWER9 OCC hwmon support"
+ depends on !SENSORS_IBM_OCC_P8_I2C
+ help
+ Provide a hwmon sysfs interface for the POWER9 On-Chip Controller,
+ exposing temperature, frequency, and power measurements. This
+ interface runs on the service processor, not the POWER CPU.
+
+ This driver can also be built as a module. If so, the module will be
+ called hwmon_occ_p9.
+
endif
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index 864b044..7b3a612 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1,3 +1,5 @@
obj-$(CONFIG_SENSORS_IBM_OCC_P8_I2C) += hwmon_occ_p8.o
+obj-$(CONFIG_SENSORS_IBM_OCC_P9) += hwmon_occ_p9.o
hwmon_occ_p8-objs := occ.o occ_sysfs.o occ_scom_i2c.o occ_p8.o occ_p8_i2c.o
+hwmon_occ_p9-objs := occ.o occ_sysfs.o occ_p9.o
diff --git a/drivers/hwmon/occ/occ_p9.c b/drivers/hwmon/occ/occ_p9.c
new file mode 100644
index 000..646d764
--- /dev/null
+++ b/drivers/hwmon/occ/occ_p9.c
@@ -0,0 +1,320 @@
+/*
+ * occ_p9.c - OCC hwmon driver
+ *
+ * This file contains the Power9-specific methods and data structures for
+ * the OCC hwmon driver.
+ *
+ * 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
+#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;
+};
+
+/* value, sensor_id */
+#define FREQ_SENSOR_CONFIG (HWMON_I_INPUT | HWMON_I_LABEL)
+
+/* value, sensor_id, fru_type */
+#define TEMP_SENSOR_CONFIG (HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_TYPE)
+
+/* value, sensor_id, accumulator[0], accumulator[1], update_tag,
+ * (function_id | (appss_channel << 8)
+ */
+#define POWER_SENSOR_CONFIG\
+( \
+ HWMON_P_INPUT | HWMON_P_LABEL | HWMON_P_AVERAGE_MIN | \
+ HWMON_P_AVERAGE_MAX | HWMON_P_AVERAGE_INTERVAL |\
+ HWMON_P_RESET_HISTORY \
+)
+
+/* curr_powercap, max_powercap, min_powercap, norm_powercap, user_powerlimit
+ * user_powerlimit_source
+ */
+#define CAPS_SENSOR_CONFIG \
+( \
+ HWMON_P_CAP | HWMON_P_CAP_MAX | HWMON_P_CAP_MIN | HWMON_P_MAX | \
+ HWMON_P_ALARM | HWMON_P_CAP_ALARM \
+)
+
+static const u32 p9_sensor_hwmon_configs[MAX_OCC_SENSOR_TYPE] = {
+ FREQ_SENSOR_CONFIG,
+ TEMP_SENSOR_CONFIG,
+ POWER_SENSO
[PATCH linux v8 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/Makefile | 2 +-
drivers/hwmon/occ/occ_p8.c | 256 +
drivers/hwmon/occ/occ_p8.h | 25 +
4 files changed, 291 insertions(+), 1 deletion(-)
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 580af26..4ec8842 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -27,6 +27,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/Makefile b/drivers/hwmon/occ/Makefile
index 9cc36e7..f59cca4 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o occ_scom_i2c.o
+obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o occ_scom_i2c.o occ_p8.o
diff --git a/drivers/hwmon/occ/occ_p8.c b/drivers/hwmon/occ/occ_p8.c
new file mode 100644
index 000..ae8b453
--- /dev/null
+++ b/drivers/hwmon/occ/occ_p8.c
@@ -0,0 +1,256 @@
+/*
+ * occ_p8.c - OCC hwmon driver
+ *
+ * This file contains the Power8-specific methods and data structures for
+ * the OCC hwmon driver.
+ *
+ * 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
+#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;
+};
+
+/* value, sensor_id */
+#define FREQ_SENSOR_CONFIG (HWMON_I_INPUT | HWMON_I_LABEL)
+#define TEMP_SENSOR_CONFIG (HWMON_T_INPUT | HWMON_T_LABEL)
+
+/* value, sensor_id, accumulator, update_tag */
+#define POWER_SENSOR_CONFIG\
+( \
+ HWMON_P_INPUT | HWMON_P_LABEL | HWMON_P_AVERAGE | \
+ HWMON_P_AVERAGE_INTERVAL\
+)
+
+/* curr_powercap, max_powercap, min_powercap, norm_powercap, user_powerlimit */
+#define CAPS_SENSOR_CONFIG \
+( \
+ HWMON_P_CAP | HWMON_P_CAP_MAX | HWMON_P_CAP_MIN | HWMON_P_MAX | \
+ HWMON_P_ALARM \
+)
+
+static const u32 p8_sensor_hwmon_configs[MAX_OCC_SENSOR_TYPE] = {
+ FREQ_SENSOR_CONFIG,
+ TEMP_SENSOR_CONFIG,
+ POWER_SENSOR_CONFIG,
+ CAPS_SENSOR_CONFIG,
+};
+
+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]));
+ p
[PATCH linux v8 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
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/hwmon/occ.txt | 13
drivers/hwmon/occ/Kconfig | 15
drivers/hwmon/occ/Makefile | 4 +-
drivers/hwmon/occ/occ_p8_i2c.c | 99 +
4 files changed, 130 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/hwmon/occ.txt
create mode 100644 drivers/hwmon/occ/occ_p8_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 61be588..d521720 100644
--- a/drivers/hwmon/occ/Kconfig
+++ b/drivers/hwmon/occ/Kconfig
@@ -11,3 +11,18 @@ menuconfig SENSORS_IBM_OCC
Generally this is used by management controllers such as a BMC
on an OpenPower system.
+
+if SENSORS_IBM_OCC
+
+config SENSORS_IBM_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
+ interface runs on the service processor, not the POWER CPU.
+
+ This driver can also be built as a module. If so, the module will be
+ called hwmon_occ_p8.
+
+endif
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index f59cca4..864b044 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1,3 @@
-obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o occ_scom_i2c.o occ_p8.o
+obj-$(CONFIG_SENSORS_IBM_OCC_P8_I2C) += hwmon_occ_p8.o
+
+hwmon_occ_p8-objs := occ.o occ_sysfs.o occ_scom_i2c.o occ_p8.o occ_p8_i2c.o
diff --git a/drivers/hwmon/occ/occ_p8_i2c.c b/drivers/hwmon/occ/occ_p8_i2c.c
new file mode 100644
index 000..2b4f6dd
--- /dev/null
+++ b/drivers/hwmon/occ/occ_p8_i2c.c
@@ -0,0 +1,99 @@
+/*
+ * occ_p8_i2c.c - hwmon OCC driver
+ *
+ * This file contains the i2c layer for accessing the P8 OCC over i2c bus.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include "occ_p8.h"
+#include "occ_scom_i2c.h"
+#include "occ_sysfs.h"
+#include "scom.h"
+
+#define OCC_P8_I2C_NAME"p8-occ-i2c"
+
+int p8_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+ /* P8 i2c slave requires scom 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 scom address to be shifted by 1 */
+ address = address << 1;
+
+ return occ_i2c_putscom(bus, address, data0, data1);
+}
+
+static const 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_init(&client->dev, client, &p8_bus_ops);
+ if (IS_ERR(occ))
+ return PTR_ERR(occ);
+
+ hwmon = occ_sysfs_start(&client->dev, occ, sensor_hwmon_configs,
+ OCC_P8_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[] = {
+ { OCC_P8_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 = OCC_P8_I2C_NAME,
+ .of_
[PATCH linux v8 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/Makefile | 2 +-
drivers/hwmon/occ/occ_scom_i2c.c | 69
drivers/hwmon/occ/occ_scom_i2c.h | 21
3 files changed, 91 insertions(+), 1 deletion(-)
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/Makefile b/drivers/hwmon/occ/Makefile
index 67b5367..9cc36e7 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o
+obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o occ_scom_i2c.o
diff --git a/drivers/hwmon/occ/occ_scom_i2c.c b/drivers/hwmon/occ/occ_scom_i2c.c
new file mode 100644
index 000..351cbc5
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.c
@@ -0,0 +1,69 @@
+/*
+ * occ_scom_i2c.c - hwmon OCC driver
+ *
+ * This file contains the functions for performing SCOM operations over I2C bus
+ * to access the OCC.
+ *
+ * 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
+#include
+#include "occ_scom_i2c.h"
+#include "scom.h"
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+ ssize_t rc;
+ __be64 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) | 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;
+}
+
+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;
+}
+
+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..f84647d
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.h
@@ -0,0 +1,21 @@
+/*
+ * occ_scom_i2c.h - hwmon OCC driver
+ *
+ * This file contains function protoypes for peforming SCOM operations over I2C
+ * bus to access the OCC.
+ *
+ * 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.
+ */
+
+#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.8.3.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 v8 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| 42 + MAINTAINERS| 7 + drivers/hwmon/Kconfig | 2 + drivers/hwmon/Makefile | 1 + drivers/hwmon/occ/Kconfig | 13 ++ drivers/hwmon/occ/Makefile | 1 + drivers/hwmon/occ/occ.c| 440 + drivers/hwmon/occ/occ.h| 77 drivers/hwmon/occ/scom.h | 42 + 9 files changed, 625 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..d1c863b --- /dev/null +++ b/Documentation/hwmon/occ @@ -0,0 +1,42 @@ += +Kernel driver occ += + +Supported chips: + * POWER8 + * POWER9 + +Please note that the driver does not run on these processors. Instead, the +driver runs on a connected service processor, such as an AST2400. (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 5f10c28..e765b0a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9128,6 +9128,13 @@ T: git git://linuxtv.org/media_tree.git S: Maintained F: drivers/media/i2c/ov7670.c +ON-CHIP CONTROLLER HWMON POWER8/POWER9 DRIVER +M: Eddie James +L: open...@lists.ozlabs.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..2b7edbb 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_IBM_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..61be588 --- /dev/null +++ b/drivers/hwmon/occ/Kconfig @@ -0,0 +1,13 @@ +# +# On Chip Controller configuration +# + +menuconfig SENSORS_IBM_OCC + bool "IBM On-Chip Controller" + help + If you say yes here you get support to monitor IBM Power CPU + sensors via the On-Chip Controller (OCC), from a service + processor. + + Generally this is used by management controllers such as a BMC + on an OpenPower system. diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile new file mode 100644 index 000..3ed79a5 --- /dev/null +++ b/drivers/hwmon/occ/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o diff --git a/drivers/hwmon/occ/occ.c b/drivers/hwmon/occ/occ.c new file mode 100644 index 000..afc21f8 --- /dev/null +++ b/drivers/hwmon/occ/occ
Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks
On Mon, 23 Jan 2017 08:34:58 -0200 Mauro Carvalho Chehab wrote: > The main difference between a "pointer file" and a symlink is that the > first indicates a temporary solution, teaching people that the > file got renamed and were it is located now. As such, we can remove > those "pointer files" on some future Kernel releases without much concern. > > A symlink indicates a more permanent situation, as people will keep > using the symlinked files as before. That means that any attempt to > remove those in the future will generate concerns. > > So, I'm in favor of using the "pointer files" instead, as it > gives us an easier way to get rid of them when we find convenient. So you've all long since forgotten this discussion, I'm sure, but I've been pondering it on and off for quite a while. The movement of some of the more well-known documents has been a concern of mine from the beginning; that is why I delayed those changes for a cycle and raised the issue at a number of conferences, culminating in the kernel summit in November. I got a strong sense of consensus that we should go ahead and move the files. As Mauro says, symlinks are forever; they say we'll never really succeed in rationalizing the structure of Documentation/. But we don't nail down the location of any other files in the kernel source tree in this manner, and my own feeling is that we shouldn't do that here either. The kernel source tree is not an API. So my thinking at the moment is that we should retain the current "pointer files" in the vague hope that, someday, we won't need them anymore. 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] docs: Make CodingStyle and SubmittingPatches symlinks
(adding Greg KH as I doubt he ever saw the original) On Tue, 2017-02-14 at 14:34 -0700, Jonathan Corbet wrote: > On Mon, 23 Jan 2017 08:34:58 -0200 > Mauro Carvalho Chehab wrote: > > > The main difference between a "pointer file" and a symlink is that the > > first indicates a temporary solution, teaching people that the > > file got renamed and were it is located now. As such, we can remove > > those "pointer files" on some future Kernel releases without much concern. > > > > A symlink indicates a more permanent situation, as people will keep > > using the symlinked files as before. That means that any attempt to > > remove those in the future will generate concerns. > > > > So, I'm in favor of using the "pointer files" instead, as it > > gives us an easier way to get rid of them when we find convenient. > > So you've all long since forgotten this discussion, I'm sure, but I've > been pondering it on and off for quite a while. > > The movement of some of the more well-known documents has been a concern > of mine from the beginning; that is why I delayed those changes for > a cycle and raised the issue at a number of conferences, culminating in > the kernel summit in November. I got a strong sense of consensus that we > should go ahead and move the files. > > As Mauro says, symlinks are forever; they say we'll never really succeed > in rationalizing the structure of Documentation/. But we don't nail down > the location of any other files in the kernel source tree in this manner, > and my own feeling is that we shouldn't do that here either. The kernel > source tree is not an API. So my thinking at the moment is that we should > retain the current "pointer files" in the vague hope that, someday, we > won't need them anymore. I'm still of the opposite opinion. -- 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 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit
On 02/08/2017 06:04 PM, Timur Tabi wrote: > On 02/08/2017 04:22 PM, Christopher Covington wrote: >> -while (pl011_read(uap, REG_FR) & uap->vendor->fr_busy) >> +while ((pl011_read(uap, REG_FR) ^ uap->vendor->inv_fr) >> +& uap->vendor->fr_busy) >>> > >>> > I really think the XOR logic needs to be documented wherever it's >>> > used. It's just too confusing. >> References such as the following for basic bit operations like >> setting, clearing, and toggling are easy enough to come by. >> >> http://stackoverflow.com/questions/47981/how-do-you-set-clear-and-toggle-a-single-bit-in-c-c > > I know what XOR does. I was thinking a more high-level comment would > be appropriate. With E44, we want to ignore the BUSY bit and use TXFE > instead. So was hoping to a comment that says that: > > /* Normally, we poll until BUSY=0, but E44 says we should poll until > TXFE=1 instead. So with E44, we set fr_busy to TXFE, but we have to > invert it. */ Oh, yeah, that'd be good. I'll include better comments in v2. Cheers, Cov -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- 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 2/2] tty: pl011: Work around QDF2400 E44 for earlycon
On 02/07/2017 11:31 PM, Shanker Donthineni wrote: > Hi Cov, > > The same PL011 driver will be used in virtutal machine, make sure > your changes have no side effects in VM. Fundamentally, this is the same workaround as has been tested in the qserver downstream kernel for over a year. Cheers, Cov -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- 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 v2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit
The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1
and 2400v1 SoCs. Checking that the Transmit FIFO Empty (TXFE) bit is 0,
instead of checking that the BUSY bit is 1, works around the issue. To
facilitate this substitution when UART AMBA Port (UAP) data is available,
introduce vendor-specific inversion of Feature Register bits. For the
earlycon case, implement alternative putc and early_write functions.
Similar to what how ARMv8 ACPI PCI quirks are detected during MCFG parsing,
check the OEM fields of the Serial Port Console Redirection (SPCR) ACPI
table to determine if the current platform is known to be affected by the
erratum.
Signed-off-by: Christopher Covington
Acked-by: Russell King
---
Changes in v2:
* Improved comments per Timur
* Removed #ifdef CONFIG_QCOM_QDF2400_ERRATUM_44 per Robin
* Moved from MIDR based affected system detection to ACPI based
per Mark and Robin
* Combined earlycon and UAP-available workarounds back into one patch
* Keeping Russell's Acked-by because I don't think I've drastically
changed the PL011 bits, but please let me know if I'm wrong
* Happy Valentine's Day!
---
Documentation/arm64/silicon-errata.txt | 2 +
drivers/acpi/spcr.c| 8
drivers/tty/serial/amba-pl011.c| 67 ++
3 files changed, 70 insertions(+), 7 deletions(-)
diff --git a/Documentation/arm64/silicon-errata.txt
b/Documentation/arm64/silicon-errata.txt
index a71b8095dbd8..bc3d086bc624 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -68,3 +68,5 @@ stable kernels.
|| | |
|
| Qualcomm Tech. | Falkor v1 | E1003 |
QCOM_FALKOR_ERRATUM_1003|
| Qualcomm Tech. | Falkor v1 | E1009 |
QCOM_FALKOR_ERRATUM_1009|
+| Qualcomm Tech. | QDF2432v1 UART | SoC E44 | N/A
|
+| Qualcomm Tech. | QDF2400v1 UART | SoC E44 | N/A
|
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index b8019c4c1d38..59064f10353f 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -93,6 +93,14 @@ int __init parse_spcr(bool earlycon)
goto done;
}
+ if (!memcmp(table->header.oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
+ if (!memcmp(table->header.oem_table_id, "QDF2432 ",
+ ACPI_OEM_TABLE_ID_SIZE) ||
+ (!memcmp(table->header.oem_table_id,
+ "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
+ table->header.oem_revision == 0))
+ uart = "qdf2400_e44";
+
snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
table->serial_port.address, baud_rate);
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index d4171d71a258..4208012d52b2 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -97,6 +97,7 @@ struct vendor_data {
unsigned intfr_dsr;
unsigned intfr_cts;
unsigned intfr_ri;
+ unsigned intinv_fr;
boolaccess_32b;
booloversampling;
booldma_threshold;
@@ -141,6 +142,30 @@ static struct vendor_data vendor_sbsa = {
.fixed_options = true,
};
+/*
+ * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
+ * occasionally getting stuck as 1. To avoid the potential for a hang, check
+ * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
+ * implementations, so only do so if an affected platform is detected in
+ * parse_spcr().
+ */
+static bool qdf2400_e44 = false;
+
+static struct vendor_data vendor_qdt_qdf2400_e44 = {
+ .reg_offset = pl011_std_offsets,
+ .fr_busy= UART011_FR_TXFE,
+ .fr_dsr = UART01x_FR_DSR,
+ .fr_cts = UART01x_FR_CTS,
+ .fr_ri = UART011_FR_RI,
+ .inv_fr = UART011_FR_TXFE,
+ .access_32b = true,
+ .oversampling = false,
+ .dma_threshold = false,
+ .cts_event_workaround = false,
+ .always_enabled = true,
+ .fixed_options = true,
+};
+
static u16 pl011_st_offsets[REG_ARRAY_SIZE] = {
[REG_DR] = UART01x_DR,
[REG_ST_DMAWM] = ST_UART011_DMAWM,
@@ -1518,7 +1543,8 @@ static unsigned int pl011_tx_empty(struct uart_port *port)
{
struct uart_amba_port *uap =
container_of(port, struct uart_amba_port, port);
- unsigned int status = pl011_read(uap, R
Re: [PATCH 00/37] PCI: Support for configurable PCI endpoint
On Wed, Feb 01, 2017 at 06:01:58PM +0530, Kishon Vijay Abraham I wrote: > - list > > Hi Bjorn, > > How do you want to handle this series? I'll send one more version of the > series > including the directory restructuring in the same series. Should it be based > on > your -next? I think if you base it on my pci/host-designware branch, it should work pretty well. I haven't merged that into -next yet, but I will soon. I'm not sure there was consensus on all the patches yet, but if you can group the easy ones at the beginning, I should be able to at least get quite a few out of the way. Bjorn -- 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] tty: pl011: Work around QDF2400 E44 stuck BUSY bit
Christopher Covington wrote:
The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1
and 2400v1 SoCs. Checking that the Transmit FIFO Empty (TXFE) bit is 0,
instead of checking that the BUSY bit is 1, works around the issue. To
facilitate this substitution when UART AMBA Port (UAP) data is available,
introduce vendor-specific inversion of Feature Register bits. For the
earlycon case, implement alternative putc and early_write functions.
Similar to what how ARMv8 ACPI PCI quirks are detected during MCFG parsing,
check the OEM fields of the Serial Port Console Redirection (SPCR) ACPI
table to determine if the current platform is known to be affected by the
erratum.
Please break this up into paragraphs.
+ if (!memcmp(table->header.oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
+ if (!memcmp(table->header.oem_table_id, "QDF2432 ",
+ ACPI_OEM_TABLE_ID_SIZE) ||
+ (!memcmp(table->header.oem_table_id,
+ "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
+ table->header.oem_revision == 0))
+ uart = "qdf2400_e44";
+
Hey, you just wrote this
And it looks crazy
But here's my function
So call it, maybe?
static bool needs_qdf2400_e44(struct acpi_table_header *h)
{
const char *id;
/* The erratum only applies to Qualcomm Technologies SOCs */
if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
return False;
id = h->oem_table_id;
if (!memcmp(id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
return True;
if (!memcmp(id, "QDF2000 ", ACPI_OEM_TABLE_ID_SIZE) &&
h->oem_revision == 0)
return True;
return False;
}
...
if (needs_qdf2400_e44(&table->header))
uart = "qdf2400_e44";
+/*
+ * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
+ * occasionally getting stuck as 1. To avoid the potential for a hang, check
+ * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
+ * implementations, so only do so if an affected platform is detected in
+ * parse_spcr().
+ */
+static bool qdf2400_e44 = false;
Please rename this to needs_qdf2400_e44
static u16 pl011_st_offsets[REG_ARRAY_SIZE] = {
[REG_DR] = UART01x_DR,
[REG_ST_DMAWM] = ST_UART011_DMAWM,
@@ -1518,7 +1543,8 @@ static unsigned int pl011_tx_empty(struct uart_port *port)
{
struct uart_amba_port *uap =
container_of(port, struct uart_amba_port, port);
- unsigned int status = pl011_read(uap, REG_FR);
+ /* Allow feature register bits to be inverted to work around errata */
Blank line above the comment, please.
+ unsigned int status = pl011_read(uap, REG_FR) ^ uap->vendor->inv_fr;
return status & (uap->vendor->fr_busy | UART01x_FR_TXFF) ?
0 : TIOCSER_TEMT;
}
@@ -2215,10 +2241,12 @@ pl011_console_write(struct console *co, const char *s,
unsigned int count)
uart_console_write(&uap->port, s, count, pl011_console_putchar);
/*
-* Finally, wait for transmitter to become empty
-* and restore the TCR
+* Finally, wait for transmitter to become empty and restore the
+* TCR. Allow feature register bits to be inverted to work around
+* errata.
*/
- while (pl011_read(uap, REG_FR) & uap->vendor->fr_busy)
+ while ((pl011_read(uap, REG_FR) ^ uap->vendor->inv_fr)
+ & uap->vendor->fr_busy)
cpu_relax();
if (!uap->vendor->always_enabled)
pl011_write(old_cr, uap, REG_CR);
@@ -2340,8 +2368,13 @@ static int __init pl011_console_match(struct console
*co, char *name, int idx,
resource_size_t addr;
int i;
- if (strcmp(name, "pl011") != 0)
+ if (strcmp(name, "qdf2400_e44") == 0) {
+ if (!qdf2400_e44)
+ pr_info("UART: Working around QDF2400 SoC erratum 44");
Just use pr_once(), and you can skip the "if (!qdf2400_e44)". Although I don't
understand why you need to do that. pl011_console_match() should only be called
once anyway, right?
+ qdf2400_e44 = true;
+ } else if (strcmp(name, "pl011") != 0) {
return -ENODEV;
+ }
if (uart_parse_earlycon(options, &iotype, &addr, &options))
return -ENODEV;
@@ -2383,6 +2416,25 @@ static struct console amba_console = {
#define AMBA_CONSOLE (&amba_console)
+static void qdf2400_e44_putc(struct uart_port *port, int c)
+{
+ while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
+ cpu_relax();
+ if (port->iot
Re: [PATCH] crypto: fix typo in doc
On Tue, Feb 14, 2017 at 08:21:45AM +0200, Gilad Ben-Yossef wrote: > Fix a single letter typo in api-skcipher.rst. > > Signed-off-by: Gilad Ben-Yossef Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
two small PCI documentation fixups
Avoid mentioning deprecated APIs and make the text a little easier to understand. -- 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 1/2] PCI: update pci.txt to talk about pci_alloc_irq_vectors
instead of the deprecated pci_enable_msi* APIs. Signed-off-by: Christoph Hellwig --- Documentation/PCI/pci.txt | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt index 77f49dc5be23..98875f8cb7ba 100644 --- a/Documentation/PCI/pci.txt +++ b/Documentation/PCI/pci.txt @@ -382,18 +382,18 @@ The fundamental difference between MSI and MSI-X is how multiple "vectors" get allocated. MSI requires contiguous blocks of vectors while MSI-X can allocate several individual ones. -MSI capability can be enabled by calling pci_enable_msi() or -pci_enable_msix() before calling request_irq(). This causes -the PCI support to program CPU vector data into the PCI device -capability registers. - -If your PCI device supports both, try to enable MSI-X first. -Only one can be enabled at a time. Many architectures, chip-sets, -or BIOSes do NOT support MSI or MSI-X and the call to pci_enable_msi/msix -will fail. This is important to note since many drivers have -two (or more) interrupt handlers: one for MSI/MSI-X and another for IRQs. -They choose which handler to register with request_irq() based on the -return value from pci_enable_msi/msix(). +MSI capability can be enabled by calling pci_alloc_irq_vectors with the +PCI_IRQ_MSI and/or PCI_IRQ_MSIX flags before calling request_irq(). This +causes the PCI support to program CPU vector data into the PCI device +capability registers. Many architectures, chip-sets, or BIOSes do NOT +support MSI or MSI-X and a call to pci_alloc_irq_vectors with just +the PCI_IRQ_MSI and PCI_IRQ_MSIX flags will fail, so try to always +specify PCI_IRQ_LEGACY as well. + +Drivers that have different interrupt handlers for MSI/MSI-X and +legacy INTx should chose the right one based on the msi_enabled +and msix_enabled flags in the pci_dev structure after calling +pci_alloc_irq_vectors. There are (at least) two really good reasons for using MSI: 1) MSI is an exclusive interrupt vector by definition. -- 2.11.0 -- 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 2/2] PCI: update MSI/MSI-X bits in PCIEBUS-HOWTO
Stop talking about low-level details that mention deprecated APIs and concentrate on what service drivers should do and why. Signed-off-by: Christoph Hellwig --- Documentation/PCI/PCIEBUS-HOWTO.txt | 33 +++-- 1 file changed, 7 insertions(+), 26 deletions(-) diff --git a/Documentation/PCI/PCIEBUS-HOWTO.txt b/Documentation/PCI/PCIEBUS-HOWTO.txt index 6bd5f372adec..15f0bb3b5045 100644 --- a/Documentation/PCI/PCIEBUS-HOWTO.txt +++ b/Documentation/PCI/PCIEBUS-HOWTO.txt @@ -161,21 +161,13 @@ Since all service drivers of a PCI-PCI Bridge Port device are allowed to run simultaneously, below lists a few of possible resource conflicts with proposed solutions. -6.1 MSI Vector Resource - -The MSI capability structure enables a device software driver to call -pci_enable_msi to request MSI based interrupts. Once MSI interrupts -are enabled on a device, it stays in this mode until a device driver -calls pci_disable_msi to disable MSI interrupts and revert back to -INTx emulation mode. Since service drivers of the same PCI-PCI Bridge -port share the same physical device, if an individual service driver -calls pci_enable_msi/pci_disable_msi it may result unpredictable -behavior. For example, two service drivers run simultaneously on the -same physical Root Port. Both service drivers call pci_enable_msi to -request MSI based interrupts. A service driver may not know whether -any other service drivers have run on this Root Port. If either one -of them calls pci_disable_msi, it puts the other service driver -in a wrong interrupt mode. +6.1 MSI and MSI-X Vector Resource + +Once MSI or MSI-X interrupts are enabled on a device, it stays in this +mode until they are disabled again. Since service drivers of the same +PCI-PCI Bridge port share the same physical device, if an individual +service driver enables or disables MSI/MSI-X mode it may result +unpredictable behavior. To avoid this situation all service drivers are not permitted to switch interrupt mode on its device. The PCI Express Port Bus driver @@ -187,17 +179,6 @@ driver. Service drivers should use (struct pcie_device*)dev->irq to call request_irq/free_irq. In addition, the interrupt mode is stored in the field interrupt_mode of struct pcie_device. -6.2 MSI-X Vector Resources - -Similar to the MSI a device driver for an MSI-X capable device can -call pci_enable_msix to request MSI-X interrupts. All service drivers -are not permitted to switch interrupt mode on its device. The PCI -Express Port Bus driver is responsible for determining the interrupt -mode and this should be transparent to service drivers. Any attempt -by service driver to call pci_enable_msix/pci_disable_msix may -result unpredictable behavior. Service drivers should use -(struct pcie_device*)dev->irq and call request_irq/free_irq. - 6.3 PCI Memory/IO Mapped Regions Service drivers for PCI Express Power Management (PME), Advanced -- 2.11.0 -- 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
