Re: Documentation/translations: Italian
On Tuesday, 22 May 2018 01:00:35 CEST Jonathan Corbet wrote: > On Mon, 21 May 2018 22:54:18 +0200 > > Federico Vaga wrote: > > I'm writing you because I would like to start an effort to > > translate the Documentation in Italian. I would like also to > > express the idea of providing guide lines for translations. > > Mi sembra un'ottima idea! :) Siamo sulla stessa lunghezza d'onda :) > > I know that there are already translations for Asian languages but > > I am not able to find the history of them. I do not know if > > translations in European languages are going to be accepted > > (perhaps there is the assumption that everyone knows English in > > the European continent and it is a waste of energy to do > > translations[?]). For example, even if French and Germans are > > quite active there are not translations yet in their language: is > > there a particular reason or simply nobody did it? > > Nobody has done it. There certainly is no policy against > translations to any specific language - that would be hard to > justify, to say the least. > > OK, I might draw the line at Klingon. But the discussion of error > handling in Klingon could actually be a lot of fun. > > I'm happy to accept new translations of stuff in the documentation > directory. In general, I've had two concerns about translations: > they are generally impossible for me to review, and there needs to > be somebody committed to keeping the translations current as the > documentation changes. For Italian, the first problem doesn't > exist, but the second is always there. What are your intentions for > maintaining the translations in the long term? I can maintain the Italian translation. > > If you agree with the need to support different translations, I > > would like to do the Italian one. But first I would like to open > > a little discussion about translations "how to write > > translations"; this discussion should produce a document (in > > English) with guide lines for translator (e.g. Documentation/ > > translation/howto.rst): what to translate first, what to NOT > > translate, how to structure it. > > Once this is defined I will start the Italian translation (I > > already have some documents translated). > > This can be a fine plan, assuming we're convinced that the > guidelines document is really needed. I guess I'm not yet > convinced of that. But you might also consider gaining some > experience in writing, merging, and maintaining a translation > before trying to lay down rules for everybody else. In other > words, I think you might want to do things in the opposite order. You are right, probably I was over-engineering this thing :) > > > How to do translations (IMHO) > > - > > Here my personal guide lines for translations > > > > - Translate only sphinx-ready documents, do not translate > > documents which are not yet sphinx. We should avoid useless > > double work; at some point, I guess, everything will be sphinx. > > I wouldn't insist on that. But a better idea in any case would be: > if a document you want to translate isn't yet in RST, just do the > conversion. The amount of work required is usually quite small. ok > > - Include in all documents a disclaimer saying that English is the > > main reference (use sphinx directive 'include' to include it). > > - Include in all documents a reference to the English version. So > > it will be easy jump to the original document. > > Remember that the docs need to be readable *without* Sphinx > processing. Better to just name the source document in a quick line > at the top, IMO. ok > > - Translate in order: non-technical documents (they are stable, > > useful for a wider group of people (developers and managers): > > process/, doc-guide/ ), technical documents about key concepts > > (they are stable, and important for new-comers), subsystems (the > > big picture is stable, typically they do not describe all little > > details that may change), and then other documents > If you want to work in that order, that is more than fine. Others > have agreed - the process docs tend to get translated first. But > if somebody else wants to start elsewhere, I wouldn't try to tell > them not to. > > Anyway, thanks for wanting to help improve the documentation! If > you have some of this work already done, you might want to consider > going ahead and posting some patches. I will review them and push something in the next days -- Federico Vaga http://www.federicovaga.it/ -- 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: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets
Hi Rob,
On Mon, May 21, 2018 at 12:27:42PM +0100, Robert Walker wrote:
> Hi Leo,
>
> On 21/05/18 09:52, Leo Yan wrote:
> >Commit e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight
> >traces") reworks the samples generation flow from CoreSight trace to
> >match the correct format so Perf report tool can display the samples
> >properly. But the change has side effect for packet handling, it only
> >generate samples when 'prev_packet->last_instr_taken_branch' is true,
> >this results in the start tracing packet and exception packets are
> >dropped.
> >
> >This patch checks extra two conditions for complete samples:
> >
> >- If 'prev_packet->sample_type' is zero we can use this condition to
> > get to know this is the start tracing packet; for this case, the start
> > packet's end_addr is zero as well so we need to handle it in the
> > function cs_etm__last_executed_instr();
> >
>
> I think you also need to add something in to handle discontinuities in
> trace - for example it is possible to configure the ETM to only trace
> execution in specific code regions or to trace a few cycles every so
> often. In these cases, prev_packet->sample_type will not be zero, but
> whatever the previous packet was. You will get a CS_ETM_TRACE_ON packet in
> such cases, generated by an I_TRACE_ON element in the trace stream.
> You also get this on exception return.
>
> However, you should also keep the test for prev_packet->sample_type == 0
> as you may not see a CS_ETM_TRACE_ON when decoding a buffer that has
> wrapped.
Thanks for reviewing. Let's dig more detailed into this issue,
especially for handling packet CS_ETM_TRACE_ON, I'd like divide into two
sub cases.
- The first case is for using python script:
I use python script to analyze packets with below command:
./perf script --itrace=ril128 -s arm-cs-trace-disasm.py -F
cpu,event,ip,addr,sym -- -v -d objdump -k ./vmlinux
What I observe is after we pass python script with parameter '-s
arm-cs-trace-disasm.py', then instruction tracing options
'--itrace=ril128' isn't really used; the perf tool creates another
new process for launch python script and re-enter cmd_script()
function, but at the second time when invoke cmd_script() for python
script execution the option '--itrace=ril128' is dropped and all
parameters are only valid defined by the python script.
As result, I can the variable 'etmq->etm->synth_opts.last_branch' is
always FALSE for running python script. So all CS_ETM_TRACE_ON
packets will be ignored in the function cs_etm__flush().
Even the CS_ETM_TRACE_ON packets are missed to handle, the program
flow still can work well. The reason is without the interference by
CS_ETM_TRACE_ON, the CS_ETM_RANGE packets can smoothly create
instruction range by ignore the middle CS_ETM_TRACE_ON packet.
Please see below example, in this example there have 3 packets, the
first one packet is CS_ETM_RANGE packet which is labelled with
'PACKET_1', the first one packet can properly generate branch sample
data with previous packet as expected; the second packet is
PACKET_2 which is CS_ETM_TRACE_ON, but
'etmq->etm->synth_opts.last_branch' is false so function
cs_etm__flush() doesn't handle it and skip the swap operation
"etmq->prev_packet = tmp"; the third packet is PACKET_3, which is
CS_ETM_RANGE packet and we can see it's smoontly to create
continous instruction range between PACKET_1 and PACKET_3.
cs_etm__sample: prev_packet: sample_type=1 exc=0 exc_ret=0 cpu=1
start_addr=0x08a5f79c end_addr=0x08a5f7bc
last_instr_taken_branch=1
PACKET_1: cs_etm__sample: packet: sample_type=1 exc=0 exc_ret=0 cpu=1
start_addr=0x08a5f858 end_addr=0x08a5f864
last_instr_taken_branch=1
cs_etm__synth_branch_sample: ip=0x08a5f7b8 addr=0x08a5f858
pid=2290 tid=2290 id=100021 stream_id=100021 period=1 cpu=1 flags=0
cpumode=2
cs_etm__flush: prev_packet: sample_type=1 exc=0 exc_ret=0 cpu=1
start_addr=0x08a5f858 end_addr=0x08a5f864
last_instr_taken_branch=1
PACKET_2: cs_etm__flush: packet: sample_type=2 exc=0 exc_ret=0 cpu=2
start_addr=0xdeadbeefdeadbeef end_addr=0xdeadbeefdeadbeef
last_instr_taken_branch=1
cs_etm__sample: prev_packet: sample_type=1 exc=0 exc_ret=0 cpu=1
start_addr=0x08a5f858 end_addr=0x08a5f864
last_instr_taken_branch=1
PACKET_3: cs_etm__sample: packet: sample_type=1 exc=0 exc_ret=0 cpu=2
start_addr=0x08be7528 end_addr=0x08be7538
last_instr_taken_branch=1
cs_etm__synth_branch_sample: ip=0x08a5f860 addr=0x08be7528
pid=2290 tid=2290 id=100021 stream_id=100021 period=1 cpu=2 flags=0
cpumode=2
So seems to me, the CS_ETM_TRACE_ON packet doesn't introduce trouble
for the program flow analysis if we can handle all CS_ETM_RANGE
packets and without handling CS_ETM_TRACE_ON packet for branch
samples.
- The second case is for --itrace option without py
Re: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets
On Tue, May 22, 2018 at 04:39:20PM +0800, Leo Yan wrote:
[...]
Rather than the patch I posted in my previous email, I think below new
patch is more reasonable for me.
In the below change, 'etmq->prev_packet' is only used to store the
previous CS_ETM_RANGE packet, we don't need to save CS_ETM_TRACE_ON
packet into 'etmq->prev_packet'.
On the other hand, cs_etm__flush() can use 'etmq->period_instructions'
to indicate if need to generate instruction sample or not. If it's
non-zero, then generate instruction sample and
'etmq->period_instructions' will be cleared; so next time if there
have more tracing CS_ETM_TRACE_ON packet, it can skip to generate
instruction sample due 'etmq->period_instructions' is zero.
How about you think for this?
Thanks,
Leo Yan
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 822ba91..dd354ad 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -495,6 +495,13 @@ static inline void cs_etm__reset_last_branch_rb(struct
cs_etm_queue *etmq)
static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
{
/*
+* The packet is the start tracing packet if the end_addr is zero,
+* returns 0 for this case.
+*/
+ if (!packet->end_addr)
+ return 0;
+
+ /*
* The packet records the execution range with an exclusive end address
*
* A64 instructions are constant size, so the last executed
@@ -897,13 +904,27 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
etmq->period_instructions = instrs_over;
}
- if (etm->sample_branches &&
- etmq->prev_packet &&
- etmq->prev_packet->sample_type == CS_ETM_RANGE &&
- etmq->prev_packet->last_instr_taken_branch) {
- ret = cs_etm__synth_branch_sample(etmq);
- if (ret)
- return ret;
+ if (etm->sample_branches && etmq->prev_packet) {
+ bool generate_sample = false;
+
+ /* Generate sample for start tracing packet */
+ if (etmq->prev_packet->sample_type == 0)
+ generate_sample = true;
+
+ /* Generate sample for exception packet */
+ if (etmq->prev_packet->exc == true)
+ generate_sample = true;
+
+ /* Generate sample for normal branch packet */
+ if (etmq->prev_packet->sample_type == CS_ETM_RANGE &&
+ etmq->prev_packet->last_instr_taken_branch)
+ generate_sample = true;
+
+ if (generate_sample) {
+ ret = cs_etm__synth_branch_sample(etmq);
+ if (ret)
+ return ret;
+ }
}
if (etm->sample_branches || etm->synth_opts.last_branch) {
@@ -922,11 +943,12 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
static int cs_etm__flush(struct cs_etm_queue *etmq)
{
int err = 0;
- struct cs_etm_packet *tmp;
if (etmq->etm->synth_opts.last_branch &&
etmq->prev_packet &&
- etmq->prev_packet->sample_type == CS_ETM_RANGE) {
+ etmq->prev_packet->sample_type == CS_ETM_RANGE &&
+ etmq->period_instructions) {
+
/*
* Generate a last branch event for the branches left in the
* circular buffer at the end of the trace.
@@ -940,14 +962,6 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
etmq, addr,
etmq->period_instructions);
etmq->period_instructions = 0;
-
- /*
-* Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
-* the next incoming packet.
-*/
- tmp = etmq->packet;
- etmq->packet = etmq->prev_packet;
- etmq->prev_packet = tmp;
}
return err;
--
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
[PATCH RFC V2 2/6] hwmon: Add support for RPi voltage sensor
Currently there is no easy way to detect undervoltage conditions on a
remote Raspberry Pi. This hwmon driver retrieves the state of the
undervoltage sensor via mailbox interface. The handling based on
Noralf's modifications to the downstream firmware driver. In case of
an undervoltage condition only an entry is written to the kernel log.
CC: "Noralf Trønnes"
Signed-off-by: Stefan Wahren
---
Documentation/hwmon/raspberrypi-hwmon | 22 +
drivers/hwmon/Kconfig | 10 ++
drivers/hwmon/Makefile| 1 +
drivers/hwmon/raspberrypi-hwmon.c | 168 ++
4 files changed, 201 insertions(+)
create mode 100644 Documentation/hwmon/raspberrypi-hwmon
create mode 100644 drivers/hwmon/raspberrypi-hwmon.c
diff --git a/Documentation/hwmon/raspberrypi-hwmon
b/Documentation/hwmon/raspberrypi-hwmon
new file mode 100644
index 000..3c92e2c
--- /dev/null
+++ b/Documentation/hwmon/raspberrypi-hwmon
@@ -0,0 +1,22 @@
+Kernel driver raspberrypi-hwmon
+===
+
+Supported boards:
+ * Raspberry Pi A+ (via GPIO on SoC)
+ * Raspberry Pi B+ (via GPIO on SoC)
+ * Raspberry Pi 2 B (via GPIO on SoC)
+ * Raspberry Pi 3 B (via GPIO on port expander)
+ * Raspberry Pi 3 B+ (via PMIC)
+
+Author: Stefan Wahren
+
+Description
+---
+
+This driver periodically polls a mailbox property of the VC4 firmware to detect
+undervoltage conditions.
+
+Sysfs entries
+-
+
+in0_lcrit_alarmUndervoltage alarm
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 768aed5..9a5bdb0 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1298,6 +1298,16 @@ config SENSORS_PWM_FAN
This driver can also be built as a module. If so, the module
will be called pwm-fan.
+config SENSORS_RASPBERRYPI_HWMON
+ tristate "Raspberry Pi voltage monitor"
+ depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
+ help
+ If you say yes here you get support for voltage sensor on the
+ Raspberry Pi.
+
+ This driver can also be built as a module. If so, the module
+ will be called raspberrypi-hwmon.
+
config SENSORS_SHT15
tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index e7d52a3..a929770 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -141,6 +141,7 @@ obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
+obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)+= raspberrypi-hwmon.o
obj-$(CONFIG_SENSORS_S3C) += s3c-hwmon.o
obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
obj-$(CONFIG_SENSORS_SCH5627) += sch5627.o
diff --git a/drivers/hwmon/raspberrypi-hwmon.c
b/drivers/hwmon/raspberrypi-hwmon.c
new file mode 100644
index 000..6233e84
--- /dev/null
+++ b/drivers/hwmon/raspberrypi-hwmon.c
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Raspberry Pi voltage sensor driver
+ *
+ * Based on firmware/raspberrypi.c by Noralf Trønnes
+ *
+ * Copyright (C) 2018 Stefan Wahren
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define UNDERVOLTAGE_STICKY_BITBIT(16)
+
+struct rpi_hwmon_data {
+ struct device *hwmon_dev;
+ struct rpi_firmware *fw;
+ u32 last_throttled;
+ struct delayed_work get_values_poll_work;
+};
+
+static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
+{
+ u32 new_uv, old_uv, value;
+ int ret;
+
+ /* Request firmware to clear sticky bits */
+ value = 0x;
+
+ ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_THROTTLED,
+ &value, sizeof(value));
+ if (ret) {
+ dev_err_once(data->hwmon_dev, "Failed to get throttled (%d)\n",
+ret);
+ return;
+ }
+
+ new_uv = value & UNDERVOLTAGE_STICKY_BIT;
+ old_uv = data->last_throttled & UNDERVOLTAGE_STICKY_BIT;
+ data->last_throttled = value;
+
+ if (new_uv == old_uv)
+ return;
+
+ if (new_uv)
+ dev_crit(data->hwmon_dev, "Undervoltage detected!\n");
+ else
+ dev_info(data->hwmon_dev, "Voltage normalised\n");
+
+ sysfs_notify(&data->hwmon_dev->kobj, NULL, "in0_lcrit_alarm");
+}
+
+static void get_values_poll(struct work_struct *work)
+{
+ struct rpi_hwmon_data *data;
+
+ data = container_of(work, struct rpi_hwmon_data,
+ get_values_poll_work.work);
+
+ rpi_firmware_get_throttled(data);
+
+ /*
+* We can't run faster than the sticky shift (100ms) since we get
+* flipping in the sticky bits that are cleared.
+*/
+ schedu
[PATCH RFC V2 6/6] arm64: defconfig: Enable RPi voltage sensor
The patch enables the hwmon driver for the Raspberry Pi. Signed-off-by: Stefan Wahren --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index d25121b..5cdecef 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -352,6 +352,7 @@ CONFIG_BATTERY_BQ27XXX=y CONFIG_SENSORS_ARM_SCPI=y CONFIG_SENSORS_LM90=m CONFIG_SENSORS_INA2XX=m +CONFIG_SENSORS_RASPBERRYPI_HWMON=m CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y CONFIG_CPU_THERMAL=y CONFIG_THERMAL_EMULATION=y -- 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
[PATCH RFC V2 4/6] ARM: bcm2835_defconfig: Enable RPi voltage sensor
The patch enables the hwmon driver for the Raspberry Pi. Signed-off-by: Stefan Wahren --- arch/arm/configs/bcm2835_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig index e4d188f..e9bc889 100644 --- a/arch/arm/configs/bcm2835_defconfig +++ b/arch/arm/configs/bcm2835_defconfig @@ -86,7 +86,7 @@ CONFIG_SPI=y CONFIG_SPI_BCM2835=y CONFIG_SPI_BCM2835AUX=y CONFIG_GPIO_SYSFS=y -# CONFIG_HWMON is not set +CONFIG_SENSORS_RASPBERRYPI_HWMON=m CONFIG_THERMAL=y CONFIG_BCM2835_THERMAL=y CONFIG_WATCHDOG=y -- 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
[PATCH RFC V2 3/6] firmware: raspberrypi: Register hwmon driver
Since the raspberrypi-hwmon driver is tied to the VC4 firmware instead of
particular hardware its registration should be in the firmware driver.
Signed-off-by: Stefan Wahren
---
drivers/firmware/raspberrypi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 6692888f..0602626 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -21,6 +21,8 @@
#define MBOX_DATA28(msg) ((msg) & ~0xf)
#define MBOX_CHAN_PROPERTY 8
+static struct platform_device *rpi_hwmon;
+
struct rpi_firmware {
struct mbox_client cl;
struct mbox_chan *chan; /* The property channel. */
@@ -183,6 +185,20 @@ rpi_firmware_print_firmware_revision(struct rpi_firmware
*fw)
}
}
+static void
+rpi_register_hwmon_driver(struct device *dev, struct rpi_firmware *fw)
+{
+ u32 packet;
+ int ret = rpi_firmware_property(fw, RPI_FIRMWARE_GET_THROTTLED,
+ &packet, sizeof(packet));
+
+ if (ret)
+ return;
+
+ rpi_hwmon = platform_device_register_data(dev, "raspberrypi-hwmon",
+ -1, NULL, 0);
+}
+
static int rpi_firmware_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -209,6 +225,7 @@ static int rpi_firmware_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, fw);
rpi_firmware_print_firmware_revision(fw);
+ rpi_register_hwmon_driver(dev, fw);
return 0;
}
@@ -217,6 +234,8 @@ static int rpi_firmware_remove(struct platform_device *pdev)
{
struct rpi_firmware *fw = platform_get_drvdata(pdev);
+ platform_device_unregister(rpi_hwmon);
+ rpi_hwmon = NULL;
mbox_free_channel(fw->chan);
return 0;
--
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
[PATCH RFC V2 0/6] hwmon: Add support for Raspberry Pi voltage sensor
A common issue for the Raspberry Pi is an inadequate power supply. Noralf Trønnes started a discussion [1] about writing such undervoltage conditions into the kernel log. This series is a draft to upstream the resulting kernel patch and is not intended for 4.18. Changes in V2: - simplified Kconfig dependency suggested by Robin Murphy - replace dt-binding by probing from firmware driver - add hwmon documentation - minor improvements suggested by Guenter Roeck [1] - https://github.com/raspberrypi/linux/issues/2367 Stefan Wahren (6): ARM: bcm2835: Add GET_THROTTLED firmware property hwmon: Add support for RPi voltage sensor firmware: raspberrypi: Register hwmon driver ARM: bcm2835_defconfig: Enable RPi voltage sensor ARM: multi_v7_defconfig: Enable RPi voltage sensor arm64: defconfig: Enable RPi voltage sensor Documentation/hwmon/raspberrypi-hwmon | 22 arch/arm/configs/bcm2835_defconfig | 2 +- arch/arm/configs/multi_v7_defconfig| 1 + arch/arm64/configs/defconfig | 1 + drivers/firmware/raspberrypi.c | 19 drivers/hwmon/Kconfig | 10 ++ drivers/hwmon/Makefile | 1 + drivers/hwmon/raspberrypi-hwmon.c | 168 + include/soc/bcm2835/raspberrypi-firmware.h | 1 + 9 files changed, 224 insertions(+), 1 deletion(-) create mode 100644 Documentation/hwmon/raspberrypi-hwmon create mode 100644 drivers/hwmon/raspberrypi-hwmon.c -- 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
[PATCH RFC V2 1/6] ARM: bcm2835: Add GET_THROTTLED firmware property
Recent Raspberry Pi firmware provides a mailbox property to detect
under-voltage conditions. Here is the current definition.
The u32 value returned by the firmware is divided into 2 parts:
- lower 16-bits are the live value
- upper 16-bits are the history or sticky value
Bits:
0: undervoltage
1: arm frequency capped
2: currently throttled
16: undervoltage has occurred
17: arm frequency capped has occurred
18: throttling has occurred
Signed-off-by: Stefan Wahren
---
include/soc/bcm2835/raspberrypi-firmware.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h
b/include/soc/bcm2835/raspberrypi-firmware.h
index 8ee8991..c4a5c9e 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -75,6 +75,7 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_GET_EDID_BLOCK = 0x00030020,
RPI_FIRMWARE_GET_CUSTOMER_OTP = 0x00030021,
RPI_FIRMWARE_GET_DOMAIN_STATE = 0x00030030,
+ RPI_FIRMWARE_GET_THROTTLED = 0x00030046,
RPI_FIRMWARE_SET_CLOCK_STATE =0x00038001,
RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
RPI_FIRMWARE_SET_VOLTAGE =0x00038003,
--
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
[PATCH RFC V2 5/6] ARM: multi_v7_defconfig: Enable RPi voltage sensor
The patch enables the hwmon driver for the Raspberry Pi. Signed-off-by: Stefan Wahren --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 720461b..5c9dc00 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -477,6 +477,7 @@ CONFIG_SENSORS_LM90=y CONFIG_SENSORS_LM95245=y CONFIG_SENSORS_NTC_THERMISTOR=m CONFIG_SENSORS_PWM_FAN=m +CONFIG_SENSORS_RASPBERRYPI_HWMON=m CONFIG_SENSORS_INA2XX=m CONFIG_CPU_THERMAL=y CONFIG_BCM2835_THERMAL=m -- 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 v2 0/7] mm: pages for hugetlb's overcommit may be able to charge to memcg
Hi Punit, On 2018/05/21 23:52, Punit Agrawal wrote: > Hi Tsukada, > > I was staring at memcg code to better understand your changes and had > the below thought. > > TSUKADA Koutaro writes: > > [...] > >> In this patch-set, introduce the charge_surplus_huge_pages(boolean) to >> struct hstate. If it is true, it charges to the memory cgroup to which the >> task that obtained surplus hugepages belongs. If it is false, do nothing as >> before, and the default value is false. The charge_surplus_huge_pages can >> be controlled procfs or sysfs interfaces. > > Instead of tying the surplus huge page charging control per-hstate, > could the control be made per-memcg? > > This can be done by introducing a per-memory controller file in sysfs > (memory.charge_surplus_hugepages?) that indicates whether surplus > hugepages are to be charged to the controller and forms part of the > total limit. IIUC, the limit already accounts for page and swap cache > pages. > > This would allow the control to be enabled per-cgroup and also keep the > userspace control interface in one place. > > As said earlier, I'm not familiar with memcg so the above might not be a > feasible but think it'll lead to a more coherent user > interface. Hopefully, more knowledgeable folks on the thread can chime > in. > Thank you for good advise. As you mentioned, it is better to be able to control by per-memcg. After organizing my thoughts, I will develop the next version patch-set that can solve issues and challenge again. Thanks, Tsukada > Thanks, > Punit > >> Since THP is very effective in environments with kernel page size of 4KB, >> such as x86, there is no reason to positively use HugeTLBfs, so I think >> that there is no situation to enable charge_surplus_huge_pages. However, in >> some distributions such as arm64, the page size of the kernel is 64KB, and >> the size of THP is too huge as 512MB, making it difficult to use. HugeTLBfs >> may support multiple huge page sizes, and in such a special environment >> there is a desire to use HugeTLBfs. >> >> The patch set is for 4.17.0-rc3+. I don't know whether patch-set are >> acceptable or not, so I just done a simple test. >> >> Thanks, >> Tsukada >> >> TSUKADA Koutaro (7): >> hugetlb: introduce charge_surplus_huge_pages to struct hstate >> hugetlb: supports migrate charging for surplus hugepages >> memcg: use compound_order rather than hpage_nr_pages >> mm, sysctl: make charging surplus hugepages controllable >> hugetlb: add charge_surplus_hugepages attribute >> Documentation, hugetlb: describe about charge_surplus_hugepages >> memcg: supports movement of surplus hugepages statistics >> >> Documentation/vm/hugetlbpage.txt |6 + >> include/linux/hugetlb.h |4 + >> kernel/sysctl.c |7 + >> mm/hugetlb.c | 148 >> +++ >> mm/memcontrol.c | 109 +++- >> 5 files changed, 269 insertions(+), 5 deletions(-) -- 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 v8 2/6] cpuset: Add new v2 cpuset.sched.domain flag
Hi,
On 17/05/18 16:55, Waiman Long wrote:
[...]
> /**
> + * update_isolated_cpumask - update the isolated_cpus mask of parent cpuset
> + * @cpuset: The cpuset that requests CPU isolation
> + * @oldmask: The old isolated cpumask to be removed from the parent
> + * @newmask: The new isolated cpumask to be added to the parent
> + * Return: 0 if successful, an error code otherwise
> + *
> + * Changes to the isolated CPUs are not allowed if any of CPUs changing
> + * state are in any of the child cpusets of the parent except the requesting
> + * child.
> + *
> + * If the sched_domain flag changes, either the oldmask (0=>1) or the
> + * newmask (1=>0) will be NULL.
> + *
> + * Called with cpuset_mutex held.
> + */
> +static int update_isolated_cpumask(struct cpuset *cpuset,
> + struct cpumask *oldmask, struct cpumask *newmask)
> +{
> + int retval;
> + int adding, deleting;
> + cpumask_var_t addmask, delmask;
> + struct cpuset *parent = parent_cs(cpuset);
> + struct cpuset *sibling;
> + struct cgroup_subsys_state *pos_css;
> + int old_count = parent->isolation_count;
> + bool dying = cpuset->css.flags & CSS_DYING;
> +
> + /*
> + * Parent must be a scheduling domain with non-empty cpus_allowed.
> + */
> + if (!is_sched_domain(parent) || cpumask_empty(parent->cpus_allowed))
> + return -EINVAL;
> +
> + /*
> + * The oldmask, if present, must be a subset of parent's isolated
> + * CPUs.
> + */
> + if (oldmask && !cpumask_empty(oldmask) && (!parent->isolation_count ||
> + !cpumask_subset(oldmask, parent->isolated_cpus))) {
> + WARN_ON_ONCE(1);
> + return -EINVAL;
> + }
> +
> + /*
> + * A sched_domain state change is not allowed if there are
> + * online children and the cpuset is not dying.
> + */
> + if (!dying && (!oldmask || !newmask) &&
> + css_has_online_children(&cpuset->css))
> + return -EBUSY;
> +
> + if (!zalloc_cpumask_var(&addmask, GFP_KERNEL))
> + return -ENOMEM;
> + if (!zalloc_cpumask_var(&delmask, GFP_KERNEL)) {
> + free_cpumask_var(addmask);
> + return -ENOMEM;
> + }
> +
> + if (!old_count) {
> + if (!zalloc_cpumask_var(&parent->isolated_cpus, GFP_KERNEL)) {
> + retval = -ENOMEM;
> + goto out;
> + }
> + old_count = 1;
> + }
> +
> + retval = -EBUSY;
> + adding = deleting = false;
> + if (newmask)
> + cpumask_copy(addmask, newmask);
> + if (oldmask)
> + deleting = cpumask_andnot(delmask, oldmask, addmask);
> + if (newmask)
> + adding = cpumask_andnot(addmask, newmask, delmask);
> +
> + if (!adding && !deleting)
> + goto out_ok;
> +
> + /*
> + * The cpus to be added must be in the parent's effective_cpus mask
> + * but not in the isolated_cpus mask.
> + */
> + if (!cpumask_subset(addmask, parent->effective_cpus))
> + goto out;
> + if (parent->isolation_count &&
> + cpumask_intersects(parent->isolated_cpus, addmask))
> + goto out;
> +
> + /*
> + * Check if any CPUs in addmask or delmask are in a sibling cpuset.
> + * An empty sibling cpus_allowed means it is the same as parent's
> + * effective_cpus. This checking is skipped if the cpuset is dying.
> + */
> + if (dying)
> + goto updated_isolated_cpus;
> +
> + cpuset_for_each_child(sibling, pos_css, parent) {
> + if ((sibling == cpuset) || !(sibling->css.flags & CSS_ONLINE))
> + continue;
> + if (cpumask_empty(sibling->cpus_allowed))
> + goto out;
> + if (adding &&
> + cpumask_intersects(sibling->cpus_allowed, addmask))
> + goto out;
> + if (deleting &&
> + cpumask_intersects(sibling->cpus_allowed, delmask))
> + goto out;
> + }
Just got the below by echoing 1 into cpuset.sched.domain of a sibling with
"isolated" cpuset.cpus. Guess you are missing proper locking about here
above.
--->8---
[ 7509.905005] =
[ 7509.905009] WARNING: suspicious RCU usage
[ 7509.905014] 4.17.0-rc5+ #11 Not tainted
[ 7509.905017] -
[ 7509.905023] /home/juri/work/kernel/linux/kernel/cgroup/cgroup.c:3826
cgroup_mutex or RCU read lock required!
[ 7509.905026]
other info that might help us debug this:
[ 7509.905031]
rcu_scheduler_active = 2, debug_locks = 1
[ 7509.905036] 4 locks held by bash/1480:
[ 7509.905039] #0: bf288709 (sb_writers#6){.+.+}, at:
vfs_write+0x18a/0x1b0
[ 7509.905072] #1: ebf23fc9 (&of->mutex){+.+.}, at:
kernfs_fop_write+0xe2/0x1a0
[ 7509.905098] #2: de7c626e (kn->count#302){.+.+}, at:
kernfs_fop_write+0
Re: [PATCH v2 0/7] mm: pages for hugetlb's overcommit may be able to charge to memcg
On 2018/05/22 3:07, Mike Kravetz wrote: > On 05/17/2018 09:27 PM, TSUKADA Koutaro wrote: >> Thanks to Mike Kravetz for comment on the previous version patch. >> >> The purpose of this patch-set is to make it possible to control whether or >> not to charge surplus hugetlb pages obtained by overcommitting to memory >> cgroup. In the future, I am trying to accomplish limiting the memory usage >> of applications that use both normal pages and hugetlb pages by the memory >> cgroup(not use the hugetlb cgroup). >> >> Applications that use shared libraries like libhugetlbfs.so use both normal >> pages and hugetlb pages, but we do not know how much to use each. Please >> suppose you want to manage the memory usage of such applications by cgroup >> How do you set the memory cgroup and hugetlb cgroup limit when you want to >> limit memory usage to 10GB? >> >> If you set a limit of 10GB for each, the user can use a total of 20GB of >> memory and can not limit it well. Since it is difficult to estimate the >> ratio used by user of normal pages and hugetlb pages, setting limits of 2GB >> to memory cgroup and 8GB to hugetlb cgroup is not very good idea. In such a >> case, I thought that by using my patch-set, we could manage resources just >> by setting 10GB as the limit of memory cgoup(there is no limit to hugetlb >> cgroup). >> >> In this patch-set, introduce the charge_surplus_huge_pages(boolean) to >> struct hstate. If it is true, it charges to the memory cgroup to which the >> task that obtained surplus hugepages belongs. If it is false, do nothing as >> before, and the default value is false. The charge_surplus_huge_pages can >> be controlled procfs or sysfs interfaces. >> >> Since THP is very effective in environments with kernel page size of 4KB, >> such as x86, there is no reason to positively use HugeTLBfs, so I think >> that there is no situation to enable charge_surplus_huge_pages. However, in >> some distributions such as arm64, the page size of the kernel is 64KB, and >> the size of THP is too huge as 512MB, making it difficult to use. HugeTLBfs >> may support multiple huge page sizes, and in such a special environment >> there is a desire to use HugeTLBfs. > > One of the basic questions/concerns I have is accounting for surplus huge > pages in the default memory resource controller. The existing huegtlb > resource controller already takes hugetlbfs huge pages into account, > including surplus pages. This series would allow surplus pages to be > accounted for in the default memory controller, or the hugetlb controller > or both. > > I understand that current mechanisms do not meet the needs of the above > use case. The question is whether this is an appropriate way to approach > the issue. My cgroup experience and knowledge is extremely limited, but > it does not appear that any other resource can be controlled by multiple > controllers. Therefore, I am concerned that this may be going against > basic cgroup design philosophy. Thank you for your feedback. That makes sense, surplus hugepages are charged to both memcg and hugetlb cgroup, which may be contrary to cgroup design philosophy. Based on the above advice, I have considered the following improvements, what do you think about? The 'charge_surplus_hugepages' of v2 patch-set was an option to switch "whether to charge memcg in addition to hugetlb cgroup", but it will be abolished. Instead, change to "switch only to memcg instead of hugetlb cgroup" option. This is called 'surplus_charge_to_memcg'. The surplus_charge_to_memcg option is created in per hugetlb cgroup. If it is false(default), charge destination cgroup of various page types is the same as the current kernel version. If it become true, hugetlb cgroup stops accounting for surplus hugepages, and memcg starts accounting instead. A table showing which cgroups are charged: page types | current v2(off) v2(on) v3(off) v3(on) --- normal + THP| m m m mm hugetlb(persistent) | h h h hh hugetlb(surplus)| h h m+h hm --- v2: charge_surplus_hugepages option v3: next version, surplus_charge_to_memcg option m: memory cgroup h: hugetlb cgroup > > It would be good to get comments from people more cgroup knowledgeable, > and especially from those involved in the decision to do separate hugetlb > control. > I stared at the commit log of mm/hugetlb_cgroup.c, but it did not seem to have specially considered of surplus hugepages. Later, I will send a mail to hugetlb cgroup's committer to ask about surplus hugepages charge specifications. -- Thanks, Tsukada -- 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
Re: [PATCH v8 2/6] cpuset: Add new v2 cpuset.sched.domain flag
On 05/22/2018 08:57 AM, Juri Lelli wrote:
> Hi,
>
> On 17/05/18 16:55, Waiman Long wrote:
>
> [...]
>
>> /**
>> + * update_isolated_cpumask - update the isolated_cpus mask of parent cpuset
>> + * @cpuset: The cpuset that requests CPU isolation
>> + * @oldmask: The old isolated cpumask to be removed from the parent
>> + * @newmask: The new isolated cpumask to be added to the parent
>> + * Return: 0 if successful, an error code otherwise
>> + *
>> + * Changes to the isolated CPUs are not allowed if any of CPUs changing
>> + * state are in any of the child cpusets of the parent except the requesting
>> + * child.
>> + *
>> + * If the sched_domain flag changes, either the oldmask (0=>1) or the
>> + * newmask (1=>0) will be NULL.
>> + *
>> + * Called with cpuset_mutex held.
>> + */
>> +static int update_isolated_cpumask(struct cpuset *cpuset,
>> +struct cpumask *oldmask, struct cpumask *newmask)
>> +{
>> +int retval;
>> +int adding, deleting;
>> +cpumask_var_t addmask, delmask;
>> +struct cpuset *parent = parent_cs(cpuset);
>> +struct cpuset *sibling;
>> +struct cgroup_subsys_state *pos_css;
>> +int old_count = parent->isolation_count;
>> +bool dying = cpuset->css.flags & CSS_DYING;
>> +
>> +/*
>> + * Parent must be a scheduling domain with non-empty cpus_allowed.
>> + */
>> +if (!is_sched_domain(parent) || cpumask_empty(parent->cpus_allowed))
>> +return -EINVAL;
>> +
>> +/*
>> + * The oldmask, if present, must be a subset of parent's isolated
>> + * CPUs.
>> + */
>> +if (oldmask && !cpumask_empty(oldmask) && (!parent->isolation_count ||
>> +!cpumask_subset(oldmask, parent->isolated_cpus))) {
>> +WARN_ON_ONCE(1);
>> +return -EINVAL;
>> +}
>> +
>> +/*
>> + * A sched_domain state change is not allowed if there are
>> + * online children and the cpuset is not dying.
>> + */
>> +if (!dying && (!oldmask || !newmask) &&
>> +css_has_online_children(&cpuset->css))
>> +return -EBUSY;
>> +
>> +if (!zalloc_cpumask_var(&addmask, GFP_KERNEL))
>> +return -ENOMEM;
>> +if (!zalloc_cpumask_var(&delmask, GFP_KERNEL)) {
>> +free_cpumask_var(addmask);
>> +return -ENOMEM;
>> +}
>> +
>> +if (!old_count) {
>> +if (!zalloc_cpumask_var(&parent->isolated_cpus, GFP_KERNEL)) {
>> +retval = -ENOMEM;
>> +goto out;
>> +}
>> +old_count = 1;
>> +}
>> +
>> +retval = -EBUSY;
>> +adding = deleting = false;
>> +if (newmask)
>> +cpumask_copy(addmask, newmask);
>> +if (oldmask)
>> +deleting = cpumask_andnot(delmask, oldmask, addmask);
>> +if (newmask)
>> +adding = cpumask_andnot(addmask, newmask, delmask);
>> +
>> +if (!adding && !deleting)
>> +goto out_ok;
>> +
>> +/*
>> + * The cpus to be added must be in the parent's effective_cpus mask
>> + * but not in the isolated_cpus mask.
>> + */
>> +if (!cpumask_subset(addmask, parent->effective_cpus))
>> +goto out;
>> +if (parent->isolation_count &&
>> +cpumask_intersects(parent->isolated_cpus, addmask))
>> +goto out;
>> +
>> +/*
>> + * Check if any CPUs in addmask or delmask are in a sibling cpuset.
>> + * An empty sibling cpus_allowed means it is the same as parent's
>> + * effective_cpus. This checking is skipped if the cpuset is dying.
>> + */
>> +if (dying)
>> +goto updated_isolated_cpus;
>> +
>> +cpuset_for_each_child(sibling, pos_css, parent) {
>> +if ((sibling == cpuset) || !(sibling->css.flags & CSS_ONLINE))
>> +continue;
>> +if (cpumask_empty(sibling->cpus_allowed))
>> +goto out;
>> +if (adding &&
>> +cpumask_intersects(sibling->cpus_allowed, addmask))
>> +goto out;
>> +if (deleting &&
>> +cpumask_intersects(sibling->cpus_allowed, delmask))
>> +goto out;
>> +}
> Just got the below by echoing 1 into cpuset.sched.domain of a sibling with
> "isolated" cpuset.cpus. Guess you are missing proper locking about here
> above.
>
> --->8---
> [ 7509.905005] =
> [ 7509.905009] WARNING: suspicious RCU usage
> [ 7509.905014] 4.17.0-rc5+ #11 Not tainted
> [ 7509.905017] -
> [ 7509.905023] /home/juri/work/kernel/linux/kernel/cgroup/cgroup.c:3826
> cgroup_mutex or RCU read lock required!
> [ 7509.905026]
>other info that might help us debug this:
>
> [ 7509.905031]
>rcu_scheduler_active = 2, debug_locks = 1
> [ 7509.905036] 4 locks held by bash/1480:
> [ 7509.905039] #0: bf288709 (sb_writers#6){.+.+}, at:
> vfs_write+0x18a/0x1b0
> [ 7509.905072] #1: ebf23fc9 (&of->mutex){+.+.},
Re: [PATCH RFC V2 2/6] hwmon: Add support for RPi voltage sensor
On 05/22/2018 04:21 AM, Stefan Wahren wrote:
Currently there is no easy way to detect undervoltage conditions on a
remote Raspberry Pi. This hwmon driver retrieves the state of the
undervoltage sensor via mailbox interface. The handling based on
Noralf's modifications to the downstream firmware driver. In case of
an undervoltage condition only an entry is written to the kernel log.
CC: "Noralf Trønnes"
Signed-off-by: Stefan Wahren
---
Documentation/hwmon/raspberrypi-hwmon | 22 +
drivers/hwmon/Kconfig | 10 ++
drivers/hwmon/Makefile| 1 +
drivers/hwmon/raspberrypi-hwmon.c | 168 ++
4 files changed, 201 insertions(+)
create mode 100644 Documentation/hwmon/raspberrypi-hwmon
create mode 100644 drivers/hwmon/raspberrypi-hwmon.c
diff --git a/Documentation/hwmon/raspberrypi-hwmon
b/Documentation/hwmon/raspberrypi-hwmon
new file mode 100644
index 000..3c92e2c
--- /dev/null
+++ b/Documentation/hwmon/raspberrypi-hwmon
@@ -0,0 +1,22 @@
+Kernel driver raspberrypi-hwmon
+===
+
+Supported boards:
+ * Raspberry Pi A+ (via GPIO on SoC)
+ * Raspberry Pi B+ (via GPIO on SoC)
+ * Raspberry Pi 2 B (via GPIO on SoC)
+ * Raspberry Pi 3 B (via GPIO on port expander)
+ * Raspberry Pi 3 B+ (via PMIC)
+
+Author: Stefan Wahren
+
+Description
+---
+
+This driver periodically polls a mailbox property of the VC4 firmware to detect
+undervoltage conditions.
+
+Sysfs entries
+-
+
+in0_lcrit_alarmUndervoltage alarm
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 768aed5..9a5bdb0 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1298,6 +1298,16 @@ config SENSORS_PWM_FAN
This driver can also be built as a module. If so, the module
will be called pwm-fan.
+config SENSORS_RASPBERRYPI_HWMON
+ tristate "Raspberry Pi voltage monitor"
+ depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
+ help
+ If you say yes here you get support for voltage sensor on the
+ Raspberry Pi.
+
+ This driver can also be built as a module. If so, the module
+ will be called raspberrypi-hwmon.
+
config SENSORS_SHT15
tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index e7d52a3..a929770 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -141,6 +141,7 @@ obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
+obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)+= raspberrypi-hwmon.o
obj-$(CONFIG_SENSORS_S3C) += s3c-hwmon.o
obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
obj-$(CONFIG_SENSORS_SCH5627) += sch5627.o
diff --git a/drivers/hwmon/raspberrypi-hwmon.c
b/drivers/hwmon/raspberrypi-hwmon.c
new file mode 100644
index 000..6233e84
--- /dev/null
+++ b/drivers/hwmon/raspberrypi-hwmon.c
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Raspberry Pi voltage sensor driver
+ *
+ * Based on firmware/raspberrypi.c by Noralf Trønnes
+ *
+ * Copyright (C) 2018 Stefan Wahren
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define UNDERVOLTAGE_STICKY_BITBIT(16)
+
+struct rpi_hwmon_data {
+ struct device *hwmon_dev;
+ struct rpi_firmware *fw;
+ u32 last_throttled;
+ struct delayed_work get_values_poll_work;
+};
+
+static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
+{
+ u32 new_uv, old_uv, value;
+ int ret;
+
+ /* Request firmware to clear sticky bits */
+ value = 0x;
+
+ ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_THROTTLED,
+ &value, sizeof(value));
+ if (ret) {
+ dev_err_once(data->hwmon_dev, "Failed to get throttled (%d)\n",
+ret);
+ return;
+ }
+
+ new_uv = value & UNDERVOLTAGE_STICKY_BIT;
+ old_uv = data->last_throttled & UNDERVOLTAGE_STICKY_BIT;
+ data->last_throttled = value;
+
+ if (new_uv == old_uv)
+ return;
+
+ if (new_uv)
+ dev_crit(data->hwmon_dev, "Undervoltage detected!\n");
+ else
+ dev_info(data->hwmon_dev, "Voltage normalised\n");
+
+ sysfs_notify(&data->hwmon_dev->kobj, NULL, "in0_lcrit_alarm");
+}
+
+static void get_values_poll(struct work_struct *work)
+{
+ struct rpi_hwmon_data *data;
+
+ data = container_of(work, struct rpi_hwmon_data,
+ get_values_poll_work.work);
+
+ rpi_firmware_get_throttled(data);
+
+ /*
+* We can't run faster than the sticky shift (100ms) since we get
+* flipping in t
Re: [PATCH v2 0/7] mm: pages for hugetlb's overcommit may be able to charge to memcg
On Fri 18-05-18 13:27:27, TSUKADA Koutaro wrote: > Thanks to Mike Kravetz for comment on the previous version patch. I am sorry that I didn't join the discussion for the previous version but time just didn't allow that. So sorry if I am repeating something already sorted out. > The purpose of this patch-set is to make it possible to control whether or > not to charge surplus hugetlb pages obtained by overcommitting to memory > cgroup. In the future, I am trying to accomplish limiting the memory usage > of applications that use both normal pages and hugetlb pages by the memory > cgroup(not use the hugetlb cgroup). There was a deliberate decision to keep hugetlb and "normal" memory cgroup controllers separate. Mostly because hugetlb memory is an artificial memory subsystem on its own and it doesn't fit into the rest of memcg accounted memory very well. I believe we want to keep that status quo. > Applications that use shared libraries like libhugetlbfs.so use both normal > pages and hugetlb pages, but we do not know how much to use each. Please > suppose you want to manage the memory usage of such applications by cgroup > How do you set the memory cgroup and hugetlb cgroup limit when you want to > limit memory usage to 10GB? Well such a usecase requires an explicit configuration already. Either by using special wrappers or modifying the code. So I would argue that you have quite a good knowlege of the setup. If you need a greater flexibility then just do not use hugetlb at all and rely on THP. [...] > In this patch-set, introduce the charge_surplus_huge_pages(boolean) to > struct hstate. If it is true, it charges to the memory cgroup to which the > task that obtained surplus hugepages belongs. If it is false, do nothing as > before, and the default value is false. The charge_surplus_huge_pages can > be controlled procfs or sysfs interfaces. I do not really think this is a good idea. We really do not want to make the current hugetlb code more complex than it is already. The current hugetlb cgroup controller is simple and works at least somehow. I would not add more on top unless there is a _really_ strong usecase behind. Please make sure to describe such a usecase in details before we even start considering the code. > Since THP is very effective in environments with kernel page size of 4KB, > such as x86, there is no reason to positively use HugeTLBfs, so I think > that there is no situation to enable charge_surplus_huge_pages. However, in > some distributions such as arm64, the page size of the kernel is 64KB, and > the size of THP is too huge as 512MB, making it difficult to use. HugeTLBfs > may support multiple huge page sizes, and in such a special environment > there is a desire to use HugeTLBfs. Well, then I would argue that you shouldn't use 64kB pages for your setup or allow THP for smaller sizes. Really hugetlb pages are by no means a substitute here. -- Michal Hocko SUSE Labs -- 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 RFC V2 2/6] hwmon: Add support for RPi voltage sensor
Hi Guenter,
> Guenter Roeck hat am 22. Mai 2018 um 15:41 geschrieben:
>
>
> On 05/22/2018 04:21 AM, Stefan Wahren wrote:
> > Currently there is no easy way to detect undervoltage conditions on a
> > remote Raspberry Pi. This hwmon driver retrieves the state of the
> > undervoltage sensor via mailbox interface. The handling based on
> > Noralf's modifications to the downstream firmware driver. In case of
> > an undervoltage condition only an entry is written to the kernel log.
> >
> > CC: "Noralf Trønnes"
> > Signed-off-by: Stefan Wahren
> > ---
> > Documentation/hwmon/raspberrypi-hwmon | 22 +
> > drivers/hwmon/Kconfig | 10 ++
> > drivers/hwmon/Makefile| 1 +
> > drivers/hwmon/raspberrypi-hwmon.c | 168
> > ++
> > 4 files changed, 201 insertions(+)
> > create mode 100644 Documentation/hwmon/raspberrypi-hwmon
> > create mode 100644 drivers/hwmon/raspberrypi-hwmon.c
> >
> > diff --git a/Documentation/hwmon/raspberrypi-hwmon
> > b/Documentation/hwmon/raspberrypi-hwmon
> > new file mode 100644
> > index 000..3c92e2c
> > --- /dev/null
> > +++ b/Documentation/hwmon/raspberrypi-hwmon
> > @@ -0,0 +1,22 @@
> > +Kernel driver raspberrypi-hwmon
> > +===
> > +
> > +Supported boards:
> > + * Raspberry Pi A+ (via GPIO on SoC)
> > + * Raspberry Pi B+ (via GPIO on SoC)
> > + * Raspberry Pi 2 B (via GPIO on SoC)
> > + * Raspberry Pi 3 B (via GPIO on port expander)
> > + * Raspberry Pi 3 B+ (via PMIC)
> > +
> > +Author: Stefan Wahren
> > +
> > +Description
> > +---
> > +
> > +This driver periodically polls a mailbox property of the VC4 firmware to
> > detect
> > +undervoltage conditions.
> > +
> > +Sysfs entries
> > +-
> > +
> > +in0_lcrit_alarmUndervoltage alarm
> > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> > index 768aed5..9a5bdb0 100644
> > --- a/drivers/hwmon/Kconfig
> > +++ b/drivers/hwmon/Kconfig
> > @@ -1298,6 +1298,16 @@ config SENSORS_PWM_FAN
> > This driver can also be built as a module. If so, the module
> > will be called pwm-fan.
> >
> > +config SENSORS_RASPBERRYPI_HWMON
> > + tristate "Raspberry Pi voltage monitor"
> > + depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
> > + help
> > + If you say yes here you get support for voltage sensor on the
> > + Raspberry Pi.
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called raspberrypi-hwmon.
> > +
> > config SENSORS_SHT15
> > tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
> > depends on GPIOLIB || COMPILE_TEST
> > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> > index e7d52a3..a929770 100644
> > --- a/drivers/hwmon/Makefile
> > +++ b/drivers/hwmon/Makefile
> > @@ -141,6 +141,7 @@ obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
> > obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
> > obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
> > obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
> > +obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)+= raspberrypi-hwmon.o
> > obj-$(CONFIG_SENSORS_S3C) += s3c-hwmon.o
> > obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
> > obj-$(CONFIG_SENSORS_SCH5627) += sch5627.o
> > diff --git a/drivers/hwmon/raspberrypi-hwmon.c
> > b/drivers/hwmon/raspberrypi-hwmon.c
> > new file mode 100644
> > index 000..6233e84
> > --- /dev/null
> > +++ b/drivers/hwmon/raspberrypi-hwmon.c
> > @@ -0,0 +1,168 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Raspberry Pi voltage sensor driver
> > + *
> > + * Based on firmware/raspberrypi.c by Noralf Trønnes
> > + *
> > + * Copyright (C) 2018 Stefan Wahren
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define UNDERVOLTAGE_STICKY_BITBIT(16)
> > +
> > +struct rpi_hwmon_data {
> > + struct device *hwmon_dev;
> > + struct rpi_firmware *fw;
> > + u32 last_throttled;
> > + struct delayed_work get_values_poll_work;
> > +};
> > +
> > +static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
> > +{
> > + u32 new_uv, old_uv, value;
> > + int ret;
> > +
> > + /* Request firmware to clear sticky bits */
> > + value = 0x;
> > +
> > + ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_THROTTLED,
> > + &value, sizeof(value));
> > + if (ret) {
> > + dev_err_once(data->hwmon_dev, "Failed to get throttled (%d)\n",
> > +ret);
> > + return;
> > + }
> > +
> > + new_uv = value & UNDERVOLTAGE_STICKY_BIT;
> > + old_uv = data->last_throttled & UNDERVOLTAGE_STICKY_BIT;
> > + data->last_throttled = value;
> > +
> > + if (new_uv == old_uv)
> > + return;
> > +
> > + if (new_uv)
> > + dev_crit(data->hwmon_dev, "Undervoltage detected!\n");
> > + else
> > +
Re: [PATCH v8 6/6] cpuset: Allow reporting of sched domain generation info
Hi,
On 17/05/18 16:55, Waiman Long wrote:
> This patch enables us to report sched domain generation information.
>
> If DYNAMIC_DEBUG is enabled, issuing the following command
>
> echo "file cpuset.c +p" > /sys/kernel/debug/dynamic_debug/control
>
> and setting loglevel to 8 will allow the kernel to show what scheduling
> domain changes are being made.
>
> Signed-off-by: Waiman Long
> ---
> kernel/cgroup/cpuset.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index fb8aa82b..8f586e8 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -820,6 +820,12 @@ static int generate_sched_domains(cpumask_var_t
> **domains,
> }
> BUG_ON(nslot != ndoms);
>
> +#ifdef CONFIG_DEBUG_KERNEL
> + for (i = 0; i < ndoms; i++)
> + pr_debug("generate_sched_domains dom %d: %*pbl\n", i,
> + cpumask_pr_args(doms[i]));
> +#endif
> +
While I'm always in favor of adding debug output, in this case I'm not
sure it's adding much to what we already print when booting with
sched_debug kernel command-line param, e.g.
--->8---
Kernel command line: BOOT_IMAGE=/vmlinuz-4.17.0-rc5+ ... sched_debug
[...]
smp: Bringing up secondary CPUs ...
x86: Booting SMP configuration:
node #0, CPUs:#1 #2 #3 #4 #5
node #1, CPUs:#6 #7 #8 #9 #10 #11
smp: Brought up 2 nodes, 12 CPUs
smpboot: Max logical packages: 2
smpboot: Total of 12 processors activated (45636.50 BogoMIPS)
CPU0 attaching sched-domain(s):
domain-0: span=0-5 level=MC
groups: 0:{ span=0 cap=1016 }, 1:{ span=1 cap=1011 }, 2:{ span=2 }, 3:{
span=3 cap=1023 }, 4:{ span=4 }, 5:{ span=5 }
domain-1: span=0-11 level=NUMA
groups: 0:{ span=0-5 cap=6122 }, 6:{ span=6-11 cap=6141 }
CPU1 attaching sched-domain(s):
domain-0: span=0-5 level=MC
groups: 1:{ span=1 cap=1011 }, 2:{ span=2 }, 3:{ span=3 cap=1023 }, 4:{
span=4 }, 5:{ span=5 }, 0:{ span=0 cap=1016 }
domain-1: span=0-11 level=NUMA
groups: 0:{ span=0-5 cap=6122 }, 6:{ span=6-11 cap=6141 }
CPU2 attaching sched-domain(s):
domain-0: span=0-5 level=MC
groups: 2:{ span=2 }, 3:{ span=3 cap=1023 }, 4:{ span=4 }, 5:{ span=5 }, 0:{
span=0 cap=1016 }, 1:{ span=1 cap=1011 }
domain-1: span=0-11 level=NUMA
groups: 0:{ span=0-5 cap=6122 }, 6:{ span=6-11 cap=6141 }
CPU3 attaching sched-domain(s):
domain-0: span=0-5 level=MC
groups: 3:{ span=3 cap=1023 }, 4:{ span=4 }, 5:{ span=5 }, 0:{ span=0
cap=1016 }, 1:{ span=1 cap=1011 }, 2:{ span=2 }
domain-1: span=0-11 level=NUMA
groups: 0:{ span=0-5 cap=6122 }, 6:{ span=6-11 cap=6141 }
CPU4 attaching sched-domain(s):
domain-0: span=0-5 level=MC
groups: 4:{ span=4 }, 5:{ span=5 }, 0:{ span=0 cap=1016 }, 1:{ span=1
cap=1011 }, 2:{ span=2 }, 3:{ span=3 cap=1023 }
domain-1: span=0-11 level=NUMA
groups: 0:{ span=0-5 cap=6122 }, 6:{ span=6-11 cap=6141 }
CPU5 attaching sched-domain(s):
domain-0: span=0-5 level=MC
groups: 5:{ span=5 }, 0:{ span=0 cap=1016 }, 1:{ span=1 cap=1011 }, 2:{
span=2 }, 3:{ span=3 cap=1023 }, 4:{ span=4 }
domain-1: span=0-11 level=NUMA
groups: 0:{ span=0-5 cap=6122 }, 6:{ span=6-11 cap=6141 }
CPU6 attaching sched-domain(s):
domain-0: span=6-11 level=MC
groups: 6:{ span=6 }, 7:{ span=7 }, 8:{ span=8 cap=1021 }, 9:{ span=9 },
10:{ span=10 }, 11:{ span=11 }
domain-1: span=0-11 level=NUMA
groups: 6:{ span=6-11 cap=6141 }, 0:{ span=0-5 cap=6122 }
CPU7 attaching sched-domain(s):
domain-0: span=6-11 level=MC
groups: 7:{ span=7 }, 8:{ span=8 cap=1021 }, 9:{ span=9 }, 10:{ span=10 },
11:{ span=11 }, 6:{ span=6 }
domain-1: span=0-11 level=NUMA
groups: 6:{ span=6-11 cap=6141 }, 0:{ span=0-5 cap=6122 }
CPU8 attaching sched-domain(s):
domain-0: span=6-11 level=MC
groups: 8:{ span=8 cap=1021 }, 9:{ span=9 }, 10:{ span=10 }, 11:{ span=11 },
6:{ span=6 }, 7:{ span=7 }
domain-1: span=0-11 level=NUMA
groups: 6:{ span=6-11 cap=6141 }, 0:{ span=0-5 cap=6122 }
CPU9 attaching sched-domain(s):
domain-0: span=6-11 level=MC
groups: 9:{ span=9 }, 10:{ span=10 }, 11:{ span=11 }, 6:{ span=6 }, 7:{
span=7 }, 8:{ span=8 cap=1021 }
domain-1: span=0-11 level=NUMA
groups: 6:{ span=6-11 cap=6141 }, 0:{ span=0-5 cap=6122 }
CPU10 attaching sched-domain(s):
domain-0: span=6-11 level=MC
groups: 10:{ span=10 }, 11:{ span=11 }, 6:{ span=6 }, 7:{ span=7 }, 8:{
span=8 cap=1021 }, 9:{ span=9 }
domain-1: span=0-11 level=NUMA
groups: 6:{ span=6-11 cap=6141 }, 0:{ span=0-5 cap=6122 }
CPU11 attaching sched-domain(s):
domain-0: span=6-11 level=MC
groups: 11:{ span=11 }, 6:{ span=6 }, 7:{ span=7 }, 8:{ span=8 cap=1021 },
9:{ span=9 }, 10:{ span=10 }
domain-1: span=0-11 level=NUMA
groups: 6:{ span=6-11 cap=6141 }, 0:{ span=0-5 cap=6122 }
span: 0-11 (max cpu_capacity = 1024)
[...]
generate_sched_domains dom 0: 6-11 <-- this and the one below is what
generate_sched_domains dom 1: 0-5 you are adding
Re: [PATCH RFC V2 2/6] hwmon: Add support for RPi voltage sensor
On 05/22/2018 06:51 AM, Stefan Wahren wrote:
Hi Guenter,
Guenter Roeck hat am 22. Mai 2018 um 15:41 geschrieben:
On 05/22/2018 04:21 AM, Stefan Wahren wrote:
Currently there is no easy way to detect undervoltage conditions on a
remote Raspberry Pi. This hwmon driver retrieves the state of the
undervoltage sensor via mailbox interface. The handling based on
Noralf's modifications to the downstream firmware driver. In case of
an undervoltage condition only an entry is written to the kernel log.
CC: "Noralf Trønnes"
Signed-off-by: Stefan Wahren
---
Documentation/hwmon/raspberrypi-hwmon | 22 +
drivers/hwmon/Kconfig | 10 ++
drivers/hwmon/Makefile| 1 +
drivers/hwmon/raspberrypi-hwmon.c | 168
++
4 files changed, 201 insertions(+)
create mode 100644 Documentation/hwmon/raspberrypi-hwmon
create mode 100644 drivers/hwmon/raspberrypi-hwmon.c
diff --git a/Documentation/hwmon/raspberrypi-hwmon
b/Documentation/hwmon/raspberrypi-hwmon
new file mode 100644
index 000..3c92e2c
--- /dev/null
+++ b/Documentation/hwmon/raspberrypi-hwmon
@@ -0,0 +1,22 @@
+Kernel driver raspberrypi-hwmon
+===
+
+Supported boards:
+ * Raspberry Pi A+ (via GPIO on SoC)
+ * Raspberry Pi B+ (via GPIO on SoC)
+ * Raspberry Pi 2 B (via GPIO on SoC)
+ * Raspberry Pi 3 B (via GPIO on port expander)
+ * Raspberry Pi 3 B+ (via PMIC)
+
+Author: Stefan Wahren
+
+Description
+---
+
+This driver periodically polls a mailbox property of the VC4 firmware to detect
+undervoltage conditions.
+
+Sysfs entries
+-
+
+in0_lcrit_alarmUndervoltage alarm
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 768aed5..9a5bdb0 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1298,6 +1298,16 @@ config SENSORS_PWM_FAN
This driver can also be built as a module. If so, the module
will be called pwm-fan.
+config SENSORS_RASPBERRYPI_HWMON
+ tristate "Raspberry Pi voltage monitor"
+ depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
+ help
+ If you say yes here you get support for voltage sensor on the
+ Raspberry Pi.
+
+ This driver can also be built as a module. If so, the module
+ will be called raspberrypi-hwmon.
+
config SENSORS_SHT15
tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index e7d52a3..a929770 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -141,6 +141,7 @@ obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
obj-$(CONFIG_SENSORS_PCF8591)+= pcf8591.o
obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
obj-$(CONFIG_SENSORS_PWM_FAN)+= pwm-fan.o
+obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)+= raspberrypi-hwmon.o
obj-$(CONFIG_SENSORS_S3C)+= s3c-hwmon.o
obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
obj-$(CONFIG_SENSORS_SCH5627)+= sch5627.o
diff --git a/drivers/hwmon/raspberrypi-hwmon.c
b/drivers/hwmon/raspberrypi-hwmon.c
new file mode 100644
index 000..6233e84
--- /dev/null
+++ b/drivers/hwmon/raspberrypi-hwmon.c
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Raspberry Pi voltage sensor driver
+ *
+ * Based on firmware/raspberrypi.c by Noralf Trønnes
+ *
+ * Copyright (C) 2018 Stefan Wahren
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define UNDERVOLTAGE_STICKY_BITBIT(16)
+
+struct rpi_hwmon_data {
+ struct device *hwmon_dev;
+ struct rpi_firmware *fw;
+ u32 last_throttled;
+ struct delayed_work get_values_poll_work;
+};
+
+static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
+{
+ u32 new_uv, old_uv, value;
+ int ret;
+
+ /* Request firmware to clear sticky bits */
+ value = 0x;
+
+ ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_THROTTLED,
+ &value, sizeof(value));
+ if (ret) {
+ dev_err_once(data->hwmon_dev, "Failed to get throttled (%d)\n",
+ret);
+ return;
+ }
+
+ new_uv = value & UNDERVOLTAGE_STICKY_BIT;
+ old_uv = data->last_throttled & UNDERVOLTAGE_STICKY_BIT;
+ data->last_throttled = value;
+
+ if (new_uv == old_uv)
+ return;
+
+ if (new_uv)
+ dev_crit(data->hwmon_dev, "Undervoltage detected!\n");
+ else
+ dev_info(data->hwmon_dev, "Voltage normalised\n");
+
+ sysfs_notify(&data->hwmon_dev->kobj, NULL, "in0_lcrit_alarm");
+}
+
+static void get_values_poll(struct work_struct *work)
+{
+ struct rpi_hwmon_data *data;
+
+ data = container_of(work, struct rpi_hwmon_data,
+ get_values_poll_work.work);
[PATCH] cgroup, docs: add a note about returning EBUSY in some cases
Explicitly document EBUSY returned by writing into cgroup.procs if controllers are enabled; and writing into cgroup.subtree_control if there are attached processes. The return code might be slightly surprising, and because there is nothing obviously better, let's document it at least. Signed-off-by: Roman Gushchin Cc: Tejun Heo Cc: kernel-t...@fb.com Cc: cgro...@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- Documentation/cgroup-v2.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt index 74cdeaed9f7a..57302f88a4ad 100644 --- a/Documentation/cgroup-v2.txt +++ b/Documentation/cgroup-v2.txt @@ -799,6 +799,9 @@ All cgroup core files are prefixed with "cgroup." When delegating a sub-hierarchy, write access to this file should be granted along with the containing directory. + If the target cgroup has enabled controllers, writing to this + file will fail with EBUSY. + In a threaded cgroup, reading this file fails with EOPNOTSUPP as all the processes belong to the thread root. Writing is supported and moves every thread of the process to the cgroup. @@ -850,6 +853,9 @@ All cgroup core files are prefixed with "cgroup." the last one is effective. When multiple enable and disable operations are specified, either all succeed or all fail. + If the cgroup has attached tasks, writing to this file will + fail with EBUSY. + cgroup.events A read-only flat-keyed file which exists on non-root cgroups. The following entries are defined. Unless specified -- 2.14.3 -- 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 v5 3/5] i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller
On 5/21/2018 2:49 PM, Wolfram Sang wrote:
> Hi,
>
> On Fri, Mar 23, 2018 at 02:20:59PM -0600, Karthikeyan Ramasubramanian wrote:
>> This bus driver supports the GENI based i2c hardware controller in the
>> Qualcomm SOCs. The Qualcomm Generic Interface (GENI) is a programmable
>> module supporting a wide range of serial interfaces including I2C. The
>> driver supports FIFO mode and DMA mode of transfer and switches modes
>> dynamically depending on the size of the transfer.
>>
>> Signed-off-by: Karthikeyan Ramasubramanian
>> Signed-off-by: Sagar Dharia
>> Signed-off-by: Girish Mahadevan
>
> Is one of these people interested in maintaining this driver? Then, an
> entry for MAINTAINERS would be needed, too. (Same goes for
> drivers/soc/qcom/ IMHO, but this is not my realm, so just saying)
One of us will maintain this driver and I will update the MAINTAINERS
appropriately.
>
>> +static const struct geni_i2c_err_log gi2c_log[] = {
>> +[GP_IRQ0] = {-EINVAL, "Unknown I2C err GP_IRQ0"},
>> +[NACK] = {-ENOTCONN, "NACK: slv unresponsive, check its
>> power/reset-ln"},
>> +[GP_IRQ2] = {-EINVAL, "Unknown I2C err GP IRQ2"},
>> +[BUS_PROTO] = {-EPROTO, "Bus proto err, noisy/unepxected start/stop"},
>> +[ARB_LOST] = {-EBUSY, "Bus arbitration lost, clock line undriveable"},
>> +[GP_IRQ5] = {-EINVAL, "Unknown I2C err GP IRQ5"},
>> +[GENI_OVERRUN] = {-EIO, "Cmd overrun, check GENI cmd-state machine"},
>> +[GENI_ILLEGAL_CMD] = {-EILSEQ, "Illegal cmd, check GENI cmd-state
>> machine"},
>> +[GENI_ABORT_DONE] = {-ETIMEDOUT, "Abort after timeout successful"},
>> +[GENI_TIMEOUT] = {-ETIMEDOUT, "I2C TXN timed out"},
>> +};
>
> Please check Documentation/i2c/fault-codes for better -ERRNO values,
> especially for NACK and ARB_LOST.
I will check the fault-codes and fix the error codes here.
>
> Rest looks good from a glimpse.
>
> Thanks,
>
>Wolfram
>
Regards,
Karthik.
--
Qualcomm Innovation Center, 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 v2 11/11] docs: fix broken references with multiple hints
On Wed, May 09, 2018 at 10:18:54AM -0300, Mauro Carvalho Chehab wrote: > The script: > ./scripts/documentation-file-ref-check --fix-rst > > Gives multiple hints for broken references on some files. > Manually use the one that applies for some files. > > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/ABI/obsolete/sysfs-gpio | 2 +- > .../devicetree/bindings/display/bridge/tda998x.txt| 2 +- Acked-by: Rob Herring > Documentation/trace/events.rst| 2 +- > Documentation/trace/tracepoint-analysis.rst | 2 +- > Documentation/translations/zh_CN/SubmittingDrivers| 2 +- > Documentation/translations/zh_CN/gpio.txt | 4 ++-- > MAINTAINERS | 2 +- > drivers/hid/usbhid/Kconfig| 2 +- > drivers/input/Kconfig | 4 ++-- > drivers/input/joystick/Kconfig| 4 ++-- > drivers/input/joystick/iforce/Kconfig | 2 +- > drivers/input/serio/Kconfig | 4 ++-- > drivers/staging/fsl-mc/bus/dpio/dpio-driver.txt | 2 +- > drivers/video/fbdev/skeletonfb.c | 8 > include/linux/tracepoint.h| 2 +- > security/device_cgroup.c | 2 +- > 16 files changed, 23 insertions(+), 23 deletions(-) -- 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 0/7] mm: pages for hugetlb's overcommit may be able to charge to memcg
On Tue 22-05-18 22:04:23, TSUKADA Koutaro wrote: > On 2018/05/22 3:07, Mike Kravetz wrote: > > On 05/17/2018 09:27 PM, TSUKADA Koutaro wrote: > >> Thanks to Mike Kravetz for comment on the previous version patch. > >> > >> The purpose of this patch-set is to make it possible to control whether or > >> not to charge surplus hugetlb pages obtained by overcommitting to memory > >> cgroup. In the future, I am trying to accomplish limiting the memory usage > >> of applications that use both normal pages and hugetlb pages by the memory > >> cgroup(not use the hugetlb cgroup). > >> > >> Applications that use shared libraries like libhugetlbfs.so use both normal > >> pages and hugetlb pages, but we do not know how much to use each. Please > >> suppose you want to manage the memory usage of such applications by cgroup > >> How do you set the memory cgroup and hugetlb cgroup limit when you want to > >> limit memory usage to 10GB? > >> > >> If you set a limit of 10GB for each, the user can use a total of 20GB of > >> memory and can not limit it well. Since it is difficult to estimate the > >> ratio used by user of normal pages and hugetlb pages, setting limits of 2GB > >> to memory cgroup and 8GB to hugetlb cgroup is not very good idea. In such a > >> case, I thought that by using my patch-set, we could manage resources just > >> by setting 10GB as the limit of memory cgoup(there is no limit to hugetlb > >> cgroup). > >> > >> In this patch-set, introduce the charge_surplus_huge_pages(boolean) to > >> struct hstate. If it is true, it charges to the memory cgroup to which the > >> task that obtained surplus hugepages belongs. If it is false, do nothing as > >> before, and the default value is false. The charge_surplus_huge_pages can > >> be controlled procfs or sysfs interfaces. > >> > >> Since THP is very effective in environments with kernel page size of 4KB, > >> such as x86, there is no reason to positively use HugeTLBfs, so I think > >> that there is no situation to enable charge_surplus_huge_pages. However, in > >> some distributions such as arm64, the page size of the kernel is 64KB, and > >> the size of THP is too huge as 512MB, making it difficult to use. HugeTLBfs > >> may support multiple huge page sizes, and in such a special environment > >> there is a desire to use HugeTLBfs. > > > > One of the basic questions/concerns I have is accounting for surplus huge > > pages in the default memory resource controller. The existing huegtlb > > resource controller already takes hugetlbfs huge pages into account, > > including surplus pages. This series would allow surplus pages to be > > accounted for in the default memory controller, or the hugetlb controller > > or both. > > > > I understand that current mechanisms do not meet the needs of the above > > use case. The question is whether this is an appropriate way to approach > > the issue. I do share your view Mike! > > My cgroup experience and knowledge is extremely limited, but > > it does not appear that any other resource can be controlled by multiple > > controllers. Therefore, I am concerned that this may be going against > > basic cgroup design philosophy. > > Thank you for your feedback. > That makes sense, surplus hugepages are charged to both memcg and hugetlb > cgroup, which may be contrary to cgroup design philosophy. > > Based on the above advice, I have considered the following improvements, > what do you think about? > > The 'charge_surplus_hugepages' of v2 patch-set was an option to switch > "whether to charge memcg in addition to hugetlb cgroup", but it will be > abolished. Instead, change to "switch only to memcg instead of hugetlb > cgroup" option. This is called 'surplus_charge_to_memcg'. This all looks so hackish and ad-hoc that I would be tempted to give it an outright nack, but let's here more about why do we need this fiddling at all. I've asked in other email so I guess I will get an answer there but let me just emphasize again that I absolutely detest a possibility to put hugetlb pages into the memcg mix. They just do not belong there. Try to look at previous discussions why it has been decided to have a separate hugetlb pages at all. I am also quite confused why you keep distinguishing surplus hugetlb pages from regular preallocated ones. Being a surplus page is an implementation detail that we use for an internal accounting rather than something to exhibit to the userspace even more than we do currently. Just look at what [sw]hould when you need to adjust accounting - e.g. due to the pool resize. Are you going to uncharge those surplus pages ffrom memcg to reflect their persistence? -- Michal Hocko SUSE Labs -- 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 RFC V2 2/6] hwmon: Add support for RPi voltage sensor
> Guenter Roeck hat am 22. Mai 2018 um 16:10 geschrieben:
>
>
> On 05/22/2018 06:51 AM, Stefan Wahren wrote:
> > Hi Guenter,
> >
> >> Guenter Roeck hat am 22. Mai 2018 um 15:41
> >> geschrieben:
> >>
> >>
> >> On 05/22/2018 04:21 AM, Stefan Wahren wrote:
> >>> Currently there is no easy way to detect undervoltage conditions on a
> >>> remote Raspberry Pi. This hwmon driver retrieves the state of the
> >>> undervoltage sensor via mailbox interface. The handling based on
> >>> Noralf's modifications to the downstream firmware driver. In case of
> >>> an undervoltage condition only an entry is written to the kernel log.
> >>>
> >>> CC: "Noralf Trønnes"
> >>> Signed-off-by: Stefan Wahren
> >>> ---
> >>>Documentation/hwmon/raspberrypi-hwmon | 22 +
> >>>drivers/hwmon/Kconfig | 10 ++
> >>>drivers/hwmon/Makefile| 1 +
> >>>drivers/hwmon/raspberrypi-hwmon.c | 168
> >>> ++
> >>>4 files changed, 201 insertions(+)
> >>>create mode 100644 Documentation/hwmon/raspberrypi-hwmon
> >>>create mode 100644 drivers/hwmon/raspberrypi-hwmon.c
> >>>
> >>> diff --git a/Documentation/hwmon/raspberrypi-hwmon
> >>> b/Documentation/hwmon/raspberrypi-hwmon
> >>> new file mode 100644
> >>> index 000..3c92e2c
> >>> --- /dev/null
> >>> +++ b/Documentation/hwmon/raspberrypi-hwmon
> >>> @@ -0,0 +1,22 @@
> >>> +Kernel driver raspberrypi-hwmon
> >>> +===
> >>> +
> >>> +Supported boards:
> >>> + * Raspberry Pi A+ (via GPIO on SoC)
> >>> + * Raspberry Pi B+ (via GPIO on SoC)
> >>> + * Raspberry Pi 2 B (via GPIO on SoC)
> >>> + * Raspberry Pi 3 B (via GPIO on port expander)
> >>> + * Raspberry Pi 3 B+ (via PMIC)
> >>> +
> >>> +Author: Stefan Wahren
> >>> +
> >>> +Description
> >>> +---
> >>> +
> >>> +This driver periodically polls a mailbox property of the VC4 firmware to
> >>> detect
> >>> +undervoltage conditions.
> >>> +
> >>> +Sysfs entries
> >>> +-
> >>> +
> >>> +in0_lcrit_alarm Undervoltage alarm
> >>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> >>> index 768aed5..9a5bdb0 100644
> >>> --- a/drivers/hwmon/Kconfig
> >>> +++ b/drivers/hwmon/Kconfig
> >>> @@ -1298,6 +1298,16 @@ config SENSORS_PWM_FAN
> >>> This driver can also be built as a module. If so, the module
> >>> will be called pwm-fan.
> >>>
> >>> +config SENSORS_RASPBERRYPI_HWMON
> >>> + tristate "Raspberry Pi voltage monitor"
> >>> + depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
> >>> + help
> >>> + If you say yes here you get support for voltage sensor on the
> >>> + Raspberry Pi.
> >>> +
> >>> + This driver can also be built as a module. If so, the module
> >>> + will be called raspberrypi-hwmon.
> >>> +
> >>>config SENSORS_SHT15
> >>> tristate "Sensiron humidity and temperature sensors. SHT15 and
> >>> compat."
> >>> depends on GPIOLIB || COMPILE_TEST
> >>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> >>> index e7d52a3..a929770 100644
> >>> --- a/drivers/hwmon/Makefile
> >>> +++ b/drivers/hwmon/Makefile
> >>> @@ -141,6 +141,7 @@ obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
> >>>obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
> >>>obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
> >>>obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
> >>> +obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON) += raspberrypi-hwmon.o
> >>>obj-$(CONFIG_SENSORS_S3C) += s3c-hwmon.o
> >>>obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
> >>>obj-$(CONFIG_SENSORS_SCH5627) += sch5627.o
> >>> diff --git a/drivers/hwmon/raspberrypi-hwmon.c
> >>> b/drivers/hwmon/raspberrypi-hwmon.c
> >>> new file mode 100644
> >>> index 000..6233e84
> >>> --- /dev/null
> >>> +++ b/drivers/hwmon/raspberrypi-hwmon.c
> >>> @@ -0,0 +1,168 @@
> >>> +// SPDX-License-Identifier: GPL-2.0+
> >>> +/*
> >>> + * Raspberry Pi voltage sensor driver
> >>> + *
> >>> + * Based on firmware/raspberrypi.c by Noralf Trønnes
> >>> + *
> >>> + * Copyright (C) 2018 Stefan Wahren
> >>> + */
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +
> >>> +#define UNDERVOLTAGE_STICKY_BIT BIT(16)
> >>> +
> >>> +struct rpi_hwmon_data {
> >>> + struct device *hwmon_dev;
> >>> + struct rpi_firmware *fw;
> >>> + u32 last_throttled;
> >>> + struct delayed_work get_values_poll_work;
> >>> +};
> >>> +
> >>> +static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
> >>> +{
> >>> + u32 new_uv, old_uv, value;
> >>> + int ret;
> >>> +
> >>> + /* Request firmware to clear sticky bits */
> >>> + value = 0x;
> >>> +
> >>> + ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_THROTTLED,
> >>> + &value, sizeof(value));
> >>> + if (ret) {
> >>> + dev_err_once(data->hwmon_dev, "Failed to get throttled (%d)\n",
> >>> + r
Re: [PATCH v2 0/7] mm: pages for hugetlb's overcommit may be able to charge to memcg
On 05/22/2018 06:04 AM, TSUKADA Koutaro wrote: > > I stared at the commit log of mm/hugetlb_cgroup.c, but it did not seem to > have specially considered of surplus hugepages. Later, I will send a mail > to hugetlb cgroup's committer to ask about surplus hugepages charge > specifications. > I went back and looked at surplus huge page allocation. Previously, I made a statement that the hugetlb controller accounts for surplus huge pages. Turns out that may not be 100% correct. Thanks to Michal, all surplus huge page allocation is performed via the alloc_surplus_huge_page() routine. This will ultimately call into the buddy allocator without any cgroup charges. Calls to alloc_surplus_huge_page are made from: - alloc_huge_page() when allocating a huge page to a mapping/file. In this case, appropriate calls to the hugetlb controller are in place. So, any limits are enforced here. - gather_surplus_pages() when allocating and setting aside 'reserved' huge pages. No accounting is performed here. Do note that in this case the allocated huge pages are not assigned to the mapping/file. Even though 'reserved', they are deposited into the global pool and also counted as 'free'. When these reserved pages are ultimately used to populate a file/mapping, the code path goes through alloc_huge_page() where appropriate calls to the hugetlb controller are in place. So, the bottom line is that surplus huge pages are not accounted for when they are allocated as 'reserves'. It is not until these reserves are actually used that accounting limits are checked. This 'seems' to align with general allocation of huge pages within the pool. No accounting is done until they are actually allocated to a mapping/file. -- Mike Kravetz -- 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 0/5] Expose PCIe AER stats via sysfs
This patchset exposes the AER stats via the sysfs attributes. Rajat Jain (5): PCI/AER: Define and allocate aer_stats structure for AER capable devices PCI/AER: Add sysfs stats for AER capable devices PCP/AER: Add sysfs attributes to provide breakdown of AERs PCI/AER: Add sysfs attributes for rootport cumulative stats Documentation/PCI: Add details of PCI AER statistics Documentation/PCI/pcieaer-howto.txt| 35 + drivers/pci/pci-sysfs.c| 3 + drivers/pci/pci.h | 4 +- drivers/pci/pcie/aer/Makefile | 2 +- drivers/pci/pcie/aer/aerdrv.h | 15 ++ drivers/pci/pcie/aer/aerdrv_core.c | 11 ++ drivers/pci/pcie/aer/aerdrv_errprint.c | 7 +- drivers/pci/pcie/aer/aerdrv_stats.c| 192 + drivers/pci/probe.c| 1 + include/linux/pci.h| 3 + 10 files changed, 269 insertions(+), 4 deletions(-) create mode 100644 drivers/pci/pcie/aer/aerdrv_stats.c -- 2.17.0.441.gb46fe60e1d-goog -- 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 4/5] PCI/AER: Add sysfs attributes for rootport cumulative stats
Add sysfs attributes for rootport statistics (that are cumulative
of all the ERR_* messages seen on this PCI hierarchy).
Signed-off-by: Rajat Jain
---
drivers/pci/pcie/aer/aerdrv.h | 2 ++
drivers/pci/pcie/aer/aerdrv_core.c | 2 ++
drivers/pci/pcie/aer/aerdrv_stats.c | 31 +
3 files changed, 35 insertions(+)
diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
index 048fbd7c9633..77d831d9 100644
--- a/drivers/pci/pcie/aer/aerdrv.h
+++ b/drivers/pci/pcie/aer/aerdrv.h
@@ -88,6 +88,8 @@ irqreturn_t aer_irq(int irq, void *context);
int pci_aer_stats_init(struct pci_dev *pdev);
void pci_aer_stats_exit(struct pci_dev *pdev);
void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info *info);
+void pci_rootport_aer_stats_incr(struct pci_dev *pdev,
+struct aer_err_source *e_src);
extern const char
*aer_correctable_error_string[AER_MAX_TYPEOF_CORRECTABLE_ERRS];
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
b/drivers/pci/pcie/aer/aerdrv_core.c
index 42a6f913069a..0f70e22563f3 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -424,6 +424,8 @@ static void aer_isr_one_error(struct pcie_device *p_device,
struct aer_rpc *rpc = get_service_data(p_device);
struct aer_err_info *e_info = &rpc->e_info;
+ pci_rootport_aer_stats_incr(p_device->port, e_src);
+
/*
* There is a possibility that both correctable error and
* uncorrectable error being logged. Report correctable error first.
diff --git a/drivers/pci/pcie/aer/aerdrv_stats.c
b/drivers/pci/pcie/aer/aerdrv_stats.c
index 5f0a6e144f56..a526e26c8683 100644
--- a/drivers/pci/pcie/aer/aerdrv_stats.c
+++ b/drivers/pci/pcie/aer/aerdrv_stats.c
@@ -60,6 +60,9 @@ static DEVICE_ATTR_RO(field)
aer_stats_aggregate_attr(dev_total_cor_errs);
aer_stats_aggregate_attr(dev_total_fatal_errs);
aer_stats_aggregate_attr(dev_total_nonfatal_errs);
+aer_stats_aggregate_attr(rootport_total_cor_errs);
+aer_stats_aggregate_attr(rootport_total_fatal_errs);
+aer_stats_aggregate_attr(rootport_total_nonfatal_errs);
#define aer_stats_breakdown_attr(field, stats_array, strings_array)
\
static ssize_t \
@@ -90,6 +93,9 @@ static struct attribute *aer_stats_attrs[] __ro_after_init = {
&dev_attr_dev_total_nonfatal_errs.attr,
&dev_attr_dev_breakdown_correctable.attr,
&dev_attr_dev_breakdown_uncorrectable.attr,
+ &dev_attr_rootport_total_cor_errs.attr,
+ &dev_attr_rootport_total_fatal_errs.attr,
+ &dev_attr_rootport_total_nonfatal_errs.attr,
NULL
};
@@ -102,6 +108,12 @@ static umode_t aer_stats_attrs_are_visible(struct kobject
*kobj,
if (!pdev->aer_stats)
return 0;
+ if ((a == &dev_attr_rootport_total_cor_errs.attr ||
+a == &dev_attr_rootport_total_fatal_errs.attr ||
+a == &dev_attr_rootport_total_nonfatal_errs.attr) &&
+ pci_pcie_type(pdev) != PCI_EXP_TYPE_ROOT_PORT)
+ return 0;
+
return a->mode;
}
@@ -144,6 +156,25 @@ void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct
aer_err_info *info)
counter[i]++;
}
+void pci_rootport_aer_stats_incr(struct pci_dev *pdev,
+struct aer_err_source *e_src)
+{
+ struct aer_stats *aer_stats = pdev->aer_stats;
+
+ if (unlikely(!aer_stats))
+ return;
+
+ if (e_src->status & PCI_ERR_ROOT_COR_RCV)
+ aer_stats->rootport_total_cor_errs++;
+
+ if (e_src->status & PCI_ERR_ROOT_UNCOR_RCV) {
+ if (e_src->status & PCI_ERR_ROOT_FATAL_RCV)
+ aer_stats->rootport_total_fatal_errs++;
+ else
+ aer_stats->rootport_total_nonfatal_errs++;
+ }
+}
+
int pci_aer_stats_init(struct pci_dev *pdev)
{
pdev->aer_stats = kzalloc(sizeof(struct aer_stats), GFP_KERNEL);
--
2.17.0.441.gb46fe60e1d-goog
--
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 5/5] Documentation/PCI: Add details of PCI AER statistics
Add the PCI AER statistics details to Documentation/PCI/pcieaer-howto.txt Signed-off-by: Rajat Jain --- Documentation/PCI/pcieaer-howto.txt | 35 + 1 file changed, 35 insertions(+) diff --git a/Documentation/PCI/pcieaer-howto.txt b/Documentation/PCI/pcieaer-howto.txt index acd06bb8..86ee9f9ff5e1 100644 --- a/Documentation/PCI/pcieaer-howto.txt +++ b/Documentation/PCI/pcieaer-howto.txt @@ -73,6 +73,41 @@ In the example, 'Requester ID' means the ID of the device who sends the error message to root port. Pls. refer to pci express specs for other fields. +2.4 AER statistics + +When AER messages are captured, the statistics are exposed via the following +sysfs attributes under the "aer_stats" folder for the device: + +2.4.1 Device sysfs Attributes + +These attributes show up under all the devices that are AER capable. These +indicate the errors "as seen by the device". Note that this may mean that if +an end point is causing problems, the AER counters may increment at its link +partner (e.g. root port) because the errors will be "seen" by the link partner +and not the the problematic end point itself (which may report all counters +as 0 as it never saw any problems). + + * dev_total_cor_errs: number of correctable errors seen by the device. + * dev_total_fatal_errs: number of fatal uncorrectable errors seen by the device. + * dev_total_nonfatal_errs: number of nonfatal uncorr errors seen by the device. + * dev_breakdown_correctable: Provides a breakdown of different type of + correctable errors seen. + * dev_breakdown_uncorrectable: Provides a breakdown of different type of + uncorrectable errors seen. + +2.4.1 Rootport sysfs Attributes + +These attributes showup under only the rootports that are AER capable. These +indicate the number of error messages as "reported to" the rootport. Please note +that the rootports also transmit (internally) the ERR_* messages for errors seen +by the internal rootport PCI device, so these counters includes them and are +thus cumulative of all the error messages on the PCI hierarchy originating +at that root port. + + * rootport_total_cor_errs: number of ERR_COR messages reported to rootport. + * rootport_total_fatal_errs: number of ERR_FATAL messages reported to rootport. + * rootport_total_nonfatal_errs: number of ERR_NONFATAL messages reporeted to + rootport. 3. Developer Guide -- 2.17.0.441.gb46fe60e1d-goog -- 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/5] PCI/AER: Add sysfs stats for AER capable devices
Add the following AER sysfs stats to represent the counters for each
kind of error as seen by the device:
dev_total_cor_errs
dev_total_fatal_errs
dev_total_nonfatal_errs
Signed-off-by: Rajat Jain
---
drivers/pci/pci-sysfs.c| 3 ++
drivers/pci/pci.h | 4 +-
drivers/pci/pcie/aer/aerdrv.h | 1 +
drivers/pci/pcie/aer/aerdrv_errprint.c | 1 +
drivers/pci/pcie/aer/aerdrv_stats.c| 72 ++
5 files changed, 80 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 366d93af051d..730f985a3dc9 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1743,6 +1743,9 @@ static const struct attribute_group
*pci_dev_attr_groups[] = {
#endif
&pci_bridge_attr_group,
&pcie_dev_attr_group,
+#ifdef CONFIG_PCIEAER
+ &aer_stats_attr_group,
+#endif
NULL,
};
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a07f3f..9a28ec600225 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -181,7 +181,9 @@ extern const struct attribute_group *pci_dev_groups[];
extern const struct attribute_group *pcibus_groups[];
extern const struct device_type pci_dev_type;
extern const struct attribute_group *pci_bus_groups[];
-
+#ifdef CONFIG_PCIEAER
+extern const struct attribute_group aer_stats_attr_group;
+#endif
/**
* pci_match_one_device - Tell if a PCI device structure has a matching
diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
index d8b9fba536ed..b5d5ad6f2c03 100644
--- a/drivers/pci/pcie/aer/aerdrv.h
+++ b/drivers/pci/pcie/aer/aerdrv.h
@@ -87,6 +87,7 @@ void aer_print_port_info(struct pci_dev *dev, struct
aer_err_info *info);
irqreturn_t aer_irq(int irq, void *context);
int pci_aer_stats_init(struct pci_dev *pdev);
void pci_aer_stats_exit(struct pci_dev *pdev);
+void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info *info);
#ifdef CONFIG_ACPI_APEI
int pcie_aer_get_firmware_first(struct pci_dev *pci_dev);
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 21ca5e1b0ded..5e8b98deda08 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -155,6 +155,7 @@ static void __aer_print_error(struct pci_dev *dev,
pci_err(dev, " [%2d] Unknown Error Bit%s\n",
i, info->first_error == i ? " (First)" : "");
}
+ pci_dev_aer_stats_incr(dev, info);
}
void aer_print_error(struct pci_dev *dev, struct aer_err_info *info)
diff --git a/drivers/pci/pcie/aer/aerdrv_stats.c
b/drivers/pci/pcie/aer/aerdrv_stats.c
index b9f251992209..87b7119d0a86 100644
--- a/drivers/pci/pcie/aer/aerdrv_stats.c
+++ b/drivers/pci/pcie/aer/aerdrv_stats.c
@@ -47,6 +47,78 @@ struct aer_stats {
u64 rootport_total_nonfatal_errs;
};
+#define aer_stats_aggregate_attr(field)
\
+ static ssize_t \
+ field##_show(struct device *dev, struct device_attribute *attr,\
+char *buf)\
+{
\
+ struct pci_dev *pdev = to_pci_dev(dev);\
+ return sprintf(buf, "0x%llx\n", pdev->aer_stats->field); \
+}
\
+static DEVICE_ATTR_RO(field)
+
+aer_stats_aggregate_attr(dev_total_cor_errs);
+aer_stats_aggregate_attr(dev_total_fatal_errs);
+aer_stats_aggregate_attr(dev_total_nonfatal_errs);
+
+static struct attribute *aer_stats_attrs[] __ro_after_init = {
+ &dev_attr_dev_total_cor_errs.attr,
+ &dev_attr_dev_total_fatal_errs.attr,
+ &dev_attr_dev_total_nonfatal_errs.attr,
+ NULL
+};
+
+static umode_t aer_stats_attrs_are_visible(struct kobject *kobj,
+ struct attribute *a, int n)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ if (!pdev->aer_stats)
+ return 0;
+
+ return a->mode;
+}
+
+const struct attribute_group aer_stats_attr_group = {
+ .name = "aer_stats",
+ .attrs = aer_stats_attrs,
+ .is_visible = aer_stats_attrs_are_visible,
+};
+
+void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info *info)
+{
+ int status, i, max = -1;
+ u64 *counter = NULL;
+ struct aer_stats *aer_stats = pdev->aer_stats;
+
+ if (unlikely(!aer_stats))
+ return;
+
+ switch (info->severity) {
+ case AER_CORRECTABLE:
+ aer_stats->dev_total_cor_errs++;
+ counter = &aer_stats->dev_cor_errs[0];
+ max = AER_MAX_TYPEOF_CORRECTABLE_ERRS;
+ break;
+ case AER_NO
[PATCH 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices
Define a structure to hold the AER statistics. There are 2 groups
of statistics: dev_* counters that are to be collected for all AER
capable devices and rootport_* counters that are collected for all
(AER capable) rootports only. Allocate and free this structure when
device is added or released (thus counters survive the lifetime of the
device).
Add a new file aerdrv_stats.c to hold the AER stats collection logic.
Signed-off-by: Rajat Jain
---
drivers/pci/pcie/aer/Makefile | 2 +-
drivers/pci/pcie/aer/aerdrv.h | 6 +++
drivers/pci/pcie/aer/aerdrv_core.c | 9
drivers/pci/pcie/aer/aerdrv_stats.c | 64 +
drivers/pci/probe.c | 1 +
include/linux/pci.h | 3 ++
6 files changed, 84 insertions(+), 1 deletion(-)
create mode 100644 drivers/pci/pcie/aer/aerdrv_stats.c
diff --git a/drivers/pci/pcie/aer/Makefile b/drivers/pci/pcie/aer/Makefile
index 09bd890875a3..a06f9cc2bde5 100644
--- a/drivers/pci/pcie/aer/Makefile
+++ b/drivers/pci/pcie/aer/Makefile
@@ -7,7 +7,7 @@ obj-$(CONFIG_PCIEAER) += aerdriver.o
obj-$(CONFIG_PCIE_ECRC)+= ecrc.o
-aerdriver-objs := aerdrv_errprint.o aerdrv_core.o aerdrv.o
+aerdriver-objs := aerdrv_errprint.o aerdrv_core.o aerdrv.o aerdrv_stats.o
aerdriver-$(CONFIG_ACPI) += aerdrv_acpi.o
obj-$(CONFIG_PCIEAER_INJECT) += aer_inject.o
diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
index b4c950683cc7..d8b9fba536ed 100644
--- a/drivers/pci/pcie/aer/aerdrv.h
+++ b/drivers/pci/pcie/aer/aerdrv.h
@@ -33,6 +33,10 @@
PCI_ERR_UNC_MALF_TLP)
#define AER_MAX_MULTI_ERR_DEVICES 5 /* Not likely to have more */
+
+#define AER_MAX_TYPEOF_CORRECTABLE_ERRS 16 /* as per PCI_ERR_COR_STATUS */
+#define AER_MAX_TYPEOF_UNCORRECTABLE_ERRS 26 /* as per PCI_ERR_UNCOR_STATUS*/
+
struct aer_err_info {
struct pci_dev *dev[AER_MAX_MULTI_ERR_DEVICES];
int error_dev_num;
@@ -81,6 +85,8 @@ void aer_isr(struct work_struct *work);
void aer_print_error(struct pci_dev *dev, struct aer_err_info *info);
void aer_print_port_info(struct pci_dev *dev, struct aer_err_info *info);
irqreturn_t aer_irq(int irq, void *context);
+int pci_aer_stats_init(struct pci_dev *pdev);
+void pci_aer_stats_exit(struct pci_dev *pdev);
#ifdef CONFIG_ACPI_APEI
int pcie_aer_get_firmware_first(struct pci_dev *pci_dev);
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
b/drivers/pci/pcie/aer/aerdrv_core.c
index 36e622d35c48..42a6f913069a 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -95,9 +95,18 @@ int pci_cleanup_aer_error_status_regs(struct pci_dev *dev)
int pci_aer_init(struct pci_dev *dev)
{
dev->aer_cap = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ERR);
+
+ if (!dev->aer_cap || pci_aer_stats_init(dev))
+ return -EIO;
+
return pci_cleanup_aer_error_status_regs(dev);
}
+void pci_aer_exit(struct pci_dev *dev)
+{
+ pci_aer_stats_exit(dev);
+}
+
/**
* add_error_device - list device to be handled
* @e_info: pointer to error info
diff --git a/drivers/pci/pcie/aer/aerdrv_stats.c
b/drivers/pci/pcie/aer/aerdrv_stats.c
new file mode 100644
index ..b9f251992209
--- /dev/null
+++ b/drivers/pci/pcie/aer/aerdrv_stats.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Google Inc, All Rights Reserved.
+ * Rajat Jain (raja...@google.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * AER Statistics - exposed to userspace via /sysfs attributes.
+ */
+
+#include
+#include "aerdrv.h"
+
+/* AER stats for the device */
+struct aer_stats {
+
+ /*
+* Fields for all AER capable devices. They indicate the errors
+* "as seen by this device". Note that this may mean that if an
+* end point is causing problems, the AER counters may increment
+* at its link partner (e.g. root port) because the errors will be
+* "seen" by the link partner and not the the problematic end point
+* itself (which may report all counters as 0 as it never saw any
+* problems).
+*/
+ /* Individual counters for different type of correctable errors */
+ u64 dev_cor_errs[AER_MAX_TYPEOF_CORRECTABLE_ERRS];
+ /* Individual counters for different type of uncorrectable errors */
+ u64 dev_uncor_errs[AER_MAX_TYPEOF_UNCORRECTABLE_ERRS];
+ /* Total number of correctable errors seen by this device */
+ u64 dev_total_cor_errs;
+ /* Total number of fatal uncorrectable errors seen by this device */
+ u64 dev_total_fatal_errs;
+ /* Total number of fatal uncorrectable errors seen by this device */
+ u64 dev_total_nonfatal_errs;
+
+ /*
+* Fields for Root ports only, these indicate
[PATCH 3/5] PCP/AER: Add sysfs attributes to provide breakdown of AERs
Add sysfs attributes to provide breakdown of the AERs seen,
into different type of correctable or uncorrectable errors:
dev_breakdown_correctable
dev_breakdown_uncorrectable
Signed-off-by: Rajat Jain
---
drivers/pci/pcie/aer/aerdrv.h | 6 ++
drivers/pci/pcie/aer/aerdrv_errprint.c | 6 --
drivers/pci/pcie/aer/aerdrv_stats.c| 25 +
3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
index b5d5ad6f2c03..048fbd7c9633 100644
--- a/drivers/pci/pcie/aer/aerdrv.h
+++ b/drivers/pci/pcie/aer/aerdrv.h
@@ -89,6 +89,12 @@ int pci_aer_stats_init(struct pci_dev *pdev);
void pci_aer_stats_exit(struct pci_dev *pdev);
void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info *info);
+extern const char
+*aer_correctable_error_string[AER_MAX_TYPEOF_CORRECTABLE_ERRS];
+
+extern const char
+*aer_uncorrectable_error_string[AER_MAX_TYPEOF_UNCORRECTABLE_ERRS];
+
#ifdef CONFIG_ACPI_APEI
int pcie_aer_get_firmware_first(struct pci_dev *pci_dev);
#else
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 5e8b98deda08..5585f309f1a8 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -68,7 +68,8 @@ static const char *aer_error_layer[] = {
"Transaction Layer"
};
-static const char *aer_correctable_error_string[] = {
+const char
+*aer_correctable_error_string[AER_MAX_TYPEOF_CORRECTABLE_ERRS] = {
"Receiver Error", /* Bit Position 0 */
NULL,
NULL,
@@ -87,7 +88,8 @@ static const char *aer_correctable_error_string[] = {
"Header Log Overflow", /* Bit Position 15 */
};
-static const char *aer_uncorrectable_error_string[] = {
+const char
+*aer_uncorrectable_error_string[AER_MAX_TYPEOF_UNCORRECTABLE_ERRS] = {
"Undefined",/* Bit Position 0 */
NULL,
NULL,
diff --git a/drivers/pci/pcie/aer/aerdrv_stats.c
b/drivers/pci/pcie/aer/aerdrv_stats.c
index 87b7119d0a86..5f0a6e144f56 100644
--- a/drivers/pci/pcie/aer/aerdrv_stats.c
+++ b/drivers/pci/pcie/aer/aerdrv_stats.c
@@ -61,10 +61,35 @@ aer_stats_aggregate_attr(dev_total_cor_errs);
aer_stats_aggregate_attr(dev_total_fatal_errs);
aer_stats_aggregate_attr(dev_total_nonfatal_errs);
+#define aer_stats_breakdown_attr(field, stats_array, strings_array)
\
+ static ssize_t \
+ field##_show(struct device *dev, struct device_attribute *attr,\
+char *buf)\
+{
\
+ unsigned int i;\
+ char *str = buf; \
+ struct pci_dev *pdev = to_pci_dev(dev);\
+ u64 *stats = pdev->aer_stats->stats_array; \
+ for (i = 0; i < ARRAY_SIZE(strings_array); i++) { \
+ if (strings_array[i]) \
+ str += sprintf(str, "%s = 0x%llx\n", \
+ strings_array[i], stats[i]);\
+ } \
+ return str-buf;\
+}
\
+static DEVICE_ATTR_RO(field)
+
+aer_stats_breakdown_attr(dev_breakdown_correctable, dev_cor_errs,
+aer_correctable_error_string);
+aer_stats_breakdown_attr(dev_breakdown_uncorrectable, dev_uncor_errs,
+aer_uncorrectable_error_string);
+
static struct attribute *aer_stats_attrs[] __ro_after_init = {
&dev_attr_dev_total_cor_errs.attr,
&dev_attr_dev_total_fatal_errs.attr,
&dev_attr_dev_total_nonfatal_errs.attr,
+ &dev_attr_dev_breakdown_correctable.attr,
+ &dev_attr_dev_breakdown_uncorrectable.attr,
NULL
};
--
2.17.0.441.gb46fe60e1d-goog
--
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/5] PCI/AER: Add sysfs stats for AER capable devices
On 05/22/2018 05:28 PM, Rajat Jain wrote:
> Add the following AER sysfs stats to represent the counters for each
> kind of error as seen by the device:
>
> dev_total_cor_errs
> dev_total_fatal_errs
> dev_total_nonfatal_errs
>
> Signed-off-by: Rajat Jain
> ---
> drivers/pci/pci-sysfs.c| 3 ++
> drivers/pci/pci.h | 4 +-
> drivers/pci/pcie/aer/aerdrv.h | 1 +
> drivers/pci/pcie/aer/aerdrv_errprint.c | 1 +
> drivers/pci/pcie/aer/aerdrv_stats.c| 72 ++
> 5 files changed, 80 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index 366d93af051d..730f985a3dc9 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -1743,6 +1743,9 @@ static const struct attribute_group
> *pci_dev_attr_groups[] = {
> #endif
> &pci_bridge_attr_group,
> &pcie_dev_attr_group,
> +#ifdef CONFIG_PCIEAER
> + &aer_stats_attr_group,
> +#endif
> NULL,
> };
So if the device is removed as part of recovery, then these get reset,
right? So if the device fails intermittently, these counters would keep
getting reset. Is this the intent?
(snip)
> /**
> * pci_match_one_device - Tell if a PCI device structure has a matching
> diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
> index d8b9fba536ed..b5d5ad6f2c03 100644
> --- a/drivers/pci/pcie/aer/aerdrv.h
> +++ b/drivers/pci/pcie/aer/aerdrv.h
> @@ -87,6 +87,7 @@ void aer_print_port_info(struct pci_dev *dev, struct
> aer_err_info *info);
> irqreturn_t aer_irq(int irq, void *context);
> int pci_aer_stats_init(struct pci_dev *pdev);
> void pci_aer_stats_exit(struct pci_dev *pdev);
> +void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info *info);
>
> #ifdef CONFIG_ACPI_APEI
> int pcie_aer_get_firmware_first(struct pci_dev *pci_dev);
> diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c
> b/drivers/pci/pcie/aer/aerdrv_errprint.c
> index 21ca5e1b0ded..5e8b98deda08 100644
> --- a/drivers/pci/pcie/aer/aerdrv_errprint.c
> +++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
> @@ -155,6 +155,7 @@ static void __aer_print_error(struct pci_dev *dev,
> pci_err(dev, " [%2d] Unknown Error Bit%s\n",
> i, info->first_error == i ? " (First)" : "");
> }
> + pci_dev_aer_stats_incr(dev, info);
What about AER errors that are contained by DPC?
Alex
--
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 5/5] Documentation/PCI: Add details of PCI AER statistics
On 05/22/2018 05:28 PM, Rajat Jain wrote: > Add the PCI AER statistics details to > Documentation/PCI/pcieaer-howto.txt > > Signed-off-by: Rajat Jain > --- > Documentation/PCI/pcieaer-howto.txt | 35 + > 1 file changed, 35 insertions(+) > > diff --git a/Documentation/PCI/pcieaer-howto.txt > b/Documentation/PCI/pcieaer-howto.txt > index acd06bb8..86ee9f9ff5e1 100644 > --- a/Documentation/PCI/pcieaer-howto.txt > +++ b/Documentation/PCI/pcieaer-howto.txt > @@ -73,6 +73,41 @@ In the example, 'Requester ID' means the ID of the device > who sends > the error message to root port. Pls. refer to pci express specs for > other fields. > > +2.4 AER statistics > + > +When AER messages are captured, the statistics are exposed via the following > +sysfs attributes under the "aer_stats" folder for the device: > + > +2.4.1 Device sysfs Attributes > + > +These attributes show up under all the devices that are AER capable. These > +indicate the errors "as seen by the device". Note that this may mean that if > +an end point is causing problems, the AER counters may increment at its link > +partner (e.g. root port) because the errors will be "seen" by the link > partner > +and not the the problematic end point itself (which may report all counters > +as 0 as it never saw any problems). I was afraid of that. Is there a way to look at the requester ID to log AER errors to the correct device? Alex -- 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 5/5] Documentation/PCI: Add details of PCI AER statistics
Hi, On Tue, May 22, 2018 at 3:52 PM, Alex G. wrote: > On 05/22/2018 05:28 PM, Rajat Jain wrote: >> Add the PCI AER statistics details to >> Documentation/PCI/pcieaer-howto.txt >> >> Signed-off-by: Rajat Jain >> --- >> Documentation/PCI/pcieaer-howto.txt | 35 + >> 1 file changed, 35 insertions(+) >> >> diff --git a/Documentation/PCI/pcieaer-howto.txt >> b/Documentation/PCI/pcieaer-howto.txt >> index acd06bb8..86ee9f9ff5e1 100644 >> --- a/Documentation/PCI/pcieaer-howto.txt >> +++ b/Documentation/PCI/pcieaer-howto.txt >> @@ -73,6 +73,41 @@ In the example, 'Requester ID' means the ID of the device >> who sends >> the error message to root port. Pls. refer to pci express specs for >> other fields. >> >> +2.4 AER statistics >> + >> +When AER messages are captured, the statistics are exposed via the following >> +sysfs attributes under the "aer_stats" folder for the device: >> + >> +2.4.1 Device sysfs Attributes >> + >> +These attributes show up under all the devices that are AER capable. These >> +indicate the errors "as seen by the device". Note that this may mean that if >> +an end point is causing problems, the AER counters may increment at its link >> +partner (e.g. root port) because the errors will be "seen" by the link >> partner >> +and not the the problematic end point itself (which may report all counters >> +as 0 as it never saw any problems). > > I was afraid of that. Is there a way to look at the requester ID to log > AER errors to the correct device? I do not think it is possible to pin point the source of the problem. Errors may be caused due to sub optimal link tuning, or signal integrity, or either of the link partners. Both the link partners will detect and report the errors that they "see". The bits and errors defined by the PCIe spec, follow the same semantics i.e. => the spec defines the different error conditions "as seen/encountered by the device", => Thus the device reports those errors to the root port => which is what we are counting and reporting here. IMHO, any interpretation / analysis of this error data / counters should be left to the user so that he can look at different devices and the errors they see, and then conclude on what might be the problem. Thanks, Rajat > > Alex -- 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/5] PCI/AER: Add sysfs stats for AER capable devices
On Tue, May 22, 2018 at 3:50 PM, Alex G. wrote:
>
>
> On 05/22/2018 05:28 PM, Rajat Jain wrote:
>> Add the following AER sysfs stats to represent the counters for each
>> kind of error as seen by the device:
>>
>> dev_total_cor_errs
>> dev_total_fatal_errs
>> dev_total_nonfatal_errs
>>
>> Signed-off-by: Rajat Jain
>> ---
>> drivers/pci/pci-sysfs.c| 3 ++
>> drivers/pci/pci.h | 4 +-
>> drivers/pci/pcie/aer/aerdrv.h | 1 +
>> drivers/pci/pcie/aer/aerdrv_errprint.c | 1 +
>> drivers/pci/pcie/aer/aerdrv_stats.c| 72 ++
>> 5 files changed, 80 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
>> index 366d93af051d..730f985a3dc9 100644
>> --- a/drivers/pci/pci-sysfs.c
>> +++ b/drivers/pci/pci-sysfs.c
>> @@ -1743,6 +1743,9 @@ static const struct attribute_group
>> *pci_dev_attr_groups[] = {
>> #endif
>> &pci_bridge_attr_group,
>> &pcie_dev_attr_group,
>> +#ifdef CONFIG_PCIEAER
>> + &aer_stats_attr_group,
>> +#endif
>> NULL,
>> };
>
> So if the device is removed as part of recovery, then these get reset,
> right? So if the device fails intermittently, these counters would keep
> getting reset. Is this the intent?
Umm, kind of.
* One argument is that if a PCI device is removed and then
re-enumerated, how do we know it is the same device and has not been
replaced by another device for e.g.? Note that the root port counters
that have the cumulative counters for all the errors seen will still
have them logged in the situation you describe.
>
> (snip)
>
>> /**
>> * pci_match_one_device - Tell if a PCI device structure has a matching
>> diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
>> index d8b9fba536ed..b5d5ad6f2c03 100644
>> --- a/drivers/pci/pcie/aer/aerdrv.h
>> +++ b/drivers/pci/pcie/aer/aerdrv.h
>> @@ -87,6 +87,7 @@ void aer_print_port_info(struct pci_dev *dev, struct
>> aer_err_info *info);
>> irqreturn_t aer_irq(int irq, void *context);
>> int pci_aer_stats_init(struct pci_dev *pdev);
>> void pci_aer_stats_exit(struct pci_dev *pdev);
>> +void pci_dev_aer_stats_incr(struct pci_dev *pdev, struct aer_err_info
>> *info);
>>
>> #ifdef CONFIG_ACPI_APEI
>> int pcie_aer_get_firmware_first(struct pci_dev *pci_dev);
>> diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c
>> b/drivers/pci/pcie/aer/aerdrv_errprint.c
>> index 21ca5e1b0ded..5e8b98deda08 100644
>> --- a/drivers/pci/pcie/aer/aerdrv_errprint.c
>> +++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
>> @@ -155,6 +155,7 @@ static void __aer_print_error(struct pci_dev *dev,
>> pci_err(dev, " [%2d] Unknown Error Bit%s\n",
>> i, info->first_error == i ? " (First)" : "");
>> }
>> + pci_dev_aer_stats_incr(dev, info);
>
> What about AER errors that are contained by DPC?
Thanks, You are right, this patch does not take care of the DPC. I'll
try to read up on DPC and can integrate it if it turns out to be easy
enough.
Thanks,
Rajat
>
> Alex
--
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/5] PCI/AER: Add sysfs stats for AER capable devices
On 5/22/2018 7:27 PM, Rajat Jain wrote: >> What about AER errors that are contained by DPC? > Thanks, You are right, this patch does not take care of the DPC. I'll > try to read up on DPC and can integrate it if it turns out to be easy > enough. > I'd focus on AER for the moment. DPC is going through major restructuring and will only handle AER_FATAL errors moving forward. > Thanks, > > Rajat > -- Sinan Kaya 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 4/5] acpi/processor: Fix the return value of acpi_processor_ids_walk()
At 05/22/2018 09:47 AM, Dou Liyang wrote:
At 05/19/2018 11:06 PM, Thomas Gleixner wrote:
On Tue, 20 Mar 2018, Dou Liyang wrote:
ACPI driver should make sure all the processor IDs in their ACPI
Namespace
are unique for CPU hotplug. the driver performs a depth-first walk of
the
namespace tree and calls the acpi_processor_ids_walk().
But, the acpi_processor_ids_walk() will return true if one processor is
checked, that cause the walk break after walking pass the first
processor.
Repace the value with AE_OK which is the standard acpi_status value.
Fixes 8c8cb30f49b8 ("acpi/processor: Implement DEVICE operator for
processor enumeration")
Signed-off-by: Dou Liyang
---
drivers/acpi/acpi_processor.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpi_processor.c
b/drivers/acpi/acpi_processor.c
index 449d86d39965..db5bdb59639c 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -663,11 +663,11 @@ static acpi_status __init (acpi_handle handle,
}
processor_validated_ids_update(uid);
- return true;
+ return AE_OK;
err:
acpi_handle_info(handle, "Invalid processor object\n");
- return false;
+ return AE_OK;
I'm not sure whether this is the right return value here. Rafael?
+Cc Rafael's common used email address.
I am sorry, I created the cc list using ./script/get_maintainers.pl ...
and didn't check it.
Thanks,
dou
Hi, Thomas, Rafael,
Yes, I used AE_OK to make sure it can skip the invalid objects and
continue to do the following other objects, I'm also not sure.
For this bug, recently, I sent another patch to remove this check code
away.
https://lkml.org/lkml/2018/5/17/320
IMO, the duplicate IDs can be avoid by the other code
if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) 1)
As the mapping of cpu_id(pr->id) and processor_id is fixed, when
hot-plugging a physical CPU, if its processor_id is duplicated with the
present, the above condition 1) will be 0, and Linux will do not add
this CPU.
And, when every time the system starts, this code will be executed, it
will waste more time with the increase in the number of CPU.
So I prefer to remove this code.
Thanks,
dou
--
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 v6 4/5] arm64: dts: sdm845: Add serial console support
On 03/30/2018 10:38 PM, Karthikeyan Ramasubramanian wrote:
> From: Rajendra Nayak
>
> Add the qup uart node and geni se instance needed to
> support the serial console on the MTP.
>
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Karthikeyan Ramasubramanian
> ---
Andy, is it possible to pull this one in for 4.18?
Sorry, I only realized we somehow missed this after looking at your pull
request.
This is the only patch that prevents linux-next from booting up my sdm845 MTP
to a minimal console shell.
Thanks,
Rajendra
> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 41
> +
> arch/arm64/boot/dts/qcom/sdm845.dtsi| 39 +++
> 2 files changed, 80 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> index 979ab49..17b2fb0 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> @@ -12,4 +12,45 @@
> / {
> model = "Qualcomm Technologies, Inc. SDM845 MTP";
> compatible = "qcom,sdm845-mtp";
> +
> + aliases {
> + serial0 = &uart2;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&soc {
> + geniqup@ac {
> + status = "okay";
> +
> + serial@a84000 {
> + status = "okay";
> + };
> + };
> +
> + pinctrl@340 {
> + qup-uart2-default {
> + pinconf_tx {
> + pins = "gpio4";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + pinconf_rx {
> + pins = "gpio5";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> + };
> +
> + qup-uart2-sleep {
> + pinconf {
> + pins = "gpio4", "gpio5";
> + bias-pull-down;
> + };
> + };
> + };
> };
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 32f8561..71801b9 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -6,6 +6,7 @@
> */
>
> #include
> +#include
>
> / {
> interrupt-parent = <&intc>;
> @@ -194,6 +195,20 @@
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> +
> + qup_uart2_default: qup-uart2-default {
> + pinmux {
> + function = "qup9";
> + pins = "gpio4", "gpio5";
> + };
> + };
> +
> + qup_uart2_sleep: qup-uart2-sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio4", "gpio5";
> + };
> + };
> };
>
> timer@17c9 {
> @@ -272,5 +287,29 @@
> #interrupt-cells = <4>;
> cell-index = <0>;
> };
> +
> + geniqup@ac {
> + compatible = "qcom,geni-se-qup";
> + reg = <0xac 0x6000>;
> + clock-names = "m-ahb", "s-ahb";
> + clocks = <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>,
> + <&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + status = "disabled";
> +
> + uart2: serial@a84000 {
> + compatible = "qcom,geni-debug-uart";
> + reg = <0xa84000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_uart2_default>;
> + pinctrl-1 = <&qup_uart2_sleep>;
> + interrupts = ;
> + status = "disabled";
> + };
> + };
> };
> };
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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
