* [PATCH 04/10] scripts/documentation-file-ref-check: teach about .txt -> .yaml renames
From: Mauro Carvalho Chehab @ 2019-05-20 14:47 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <cover.1558362030.git.mchehab+samsung@kernel.org>
At DT, files are being renamed to jason. Teach the script how to
handle such renames when used in fix mode.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
scripts/documentation-file-ref-check | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/scripts/documentation-file-ref-check b/scripts/documentation-file-ref-check
index 5d775ca7469b..ff16db269079 100755
--- a/scripts/documentation-file-ref-check
+++ b/scripts/documentation-file-ref-check
@@ -165,13 +165,22 @@ foreach my $ref (keys %broken_ref) {
# usual reason for breakage: DT file moved around
if ($ref =~ /devicetree/) {
- my $search = $new;
- $search =~ s,^.*/,,;
- $f = qx(find Documentation/devicetree/ -iname "*$search*") if ($search);
+ # usual reason for breakage: DT file renamed to .yaml
if (!$f) {
- # Manufacturer name may have changed
- $search =~ s/^.*,//;
+ my $new_ref = $ref;
+ $new_ref =~ s/\.txt$/.yaml/;
+ $f=$new_ref if (-f $new_ref);
+ }
+
+ if (!$f) {
+ my $search = $new;
+ $search =~ s,^.*/,,;
$f = qx(find Documentation/devicetree/ -iname "*$search*") if ($search);
+ if (!$f) {
+ # Manufacturer name may have changed
+ $search =~ s/^.*,//;
+ $f = qx(find Documentation/devicetree/ -iname "*$search*") if ($search);
+ }
}
}
--
2.21.0
^ permalink raw reply related
* [PATCH 03/10] scripts/documentation-file-ref-check: improve tools ref handling
From: Mauro Carvalho Chehab @ 2019-05-20 14:47 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <cover.1558362030.git.mchehab+samsung@kernel.org>
There's a false positive on perf/util:
tools/perf/util/s390-cpumsf.c: Documentation/perf.data-file-format.txt
The file is there at tools/perf/Documentation/, but the logic
with detects relative documentation references inside tools is
not capable of detecting it.
So, improve it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
scripts/documentation-file-ref-check | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/documentation-file-ref-check b/scripts/documentation-file-ref-check
index 05235775cc71..5d775ca7469b 100755
--- a/scripts/documentation-file-ref-check
+++ b/scripts/documentation-file-ref-check
@@ -127,7 +127,7 @@ while (<IN>) {
if ($f =~ m/tools/) {
my $path = $f;
$path =~ s,(.*)/.*,$1,;
- next if (grep -e, glob("$path/$ref $path/$fulref"));
+ next if (grep -e, glob("$path/$ref $path/../$ref $path/$fulref"));
}
# Discard known false-positives
--
2.21.0
^ permalink raw reply related
* [PATCH 07/10] mfd: madera: point to the right pinctrl binding file
From: Mauro Carvalho Chehab @ 2019-05-20 14:47 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Charles Keepax, Richard Fitzgerald, Lee Jones,
alsa-devel, patches
In-Reply-To: <cover.1558362030.git.mchehab+samsung@kernel.org>
The reference to Documentation/pinctrl.txt doesn't exist, but
there is an specific binding for the madera driver.
So, point to it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
include/linux/mfd/madera/pdata.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/mfd/madera/pdata.h b/include/linux/mfd/madera/pdata.h
index 8dc852402dbb..c7e0658eb74b 100644
--- a/include/linux/mfd/madera/pdata.h
+++ b/include/linux/mfd/madera/pdata.h
@@ -34,7 +34,8 @@ struct madera_codec_pdata;
* @micvdd: Substruct of pdata for the MICVDD regulator
* @irq_flags: Mode for primary IRQ (defaults to active low)
* @gpio_base: Base GPIO number
- * @gpio_configs: Array of GPIO configurations (See Documentation/pinctrl.txt)
+ * @gpio_configs: Array of GPIO configurations
+ * (See Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt)
* @n_gpio_configs: Number of entries in gpio_configs
* @gpsw: General purpose switch mode setting. Depends on the external
* hardware connected to the switch. (See the SW1_MODE field
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 10/10] docs: fix broken documentation links
From: Wolfram Sang @ 2019-05-20 15:05 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, x86, linux-acpi, linux-edac, netdev, devicetree,
linux-pci, linux-arm-kernel, linux-amlogic, linux-arm-msm,
linux-gpio, linux-i2c, linuxppc-dev, xen-devel,
platform-driver-x86, devel, kvm, virtualization, devel, linux-mm,
linux-security-module, linux-kselftest
In-Reply-To: <4fd1182b4a41feb2447c7ccde4d7f0a6b3c92686.1558362030.git.mchehab+samsung@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]
On Mon, May 20, 2019 at 11:47:39AM -0300, Mauro Carvalho Chehab wrote:
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Thanks, didn't notice that.
> Documentation/i2c/instantiating-devices | 2 +-
...
> diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices
> index 0d85ac1935b7..5a3e2f331e8c 100644
> --- a/Documentation/i2c/instantiating-devices
> +++ b/Documentation/i2c/instantiating-devices
> @@ -85,7 +85,7 @@ Method 1c: Declare the I2C devices via ACPI
> -------------------------------------------
>
> ACPI can also describe I2C devices. There is special documentation for this
> -which is currently located at Documentation/acpi/enumeration.txt.
> +which is currently located at Documentation/firmware-guide/acpi/enumeration.rst.
>
>
> Method 2: Instantiate the devices explicitly
For this I2C part:
Reviewed-by: Wolfram Sang <wsa@the-dreams.de>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v6 00/12] Include linux PCI docs into Sphinx TOC tree
From: Changbin Du @ 2019-05-20 15:05 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Changbin Du, bhelgaas, corbet, linux-pci, linux-doc, linux-kernel
In-Reply-To: <20190520112350.4679df1c@coco.lan>
On Mon, May 20, 2019 at 11:23:50AM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 20 May 2019 06:10:15 +0000
> Changbin Du <changbin.du@gmail.com> escreveu:
>
> > Bjorn and Jonathan,
> > Could we consider to merge this serias now? Thanks.
>
> Before merging it, did you check if the renames won't cause broken
> reference links? There were such breakages with your x86 and acpi
> patch series. I'm sending the fixes right now, but it would be
> great if you could run the ./scripts/documentation-file-ref-check
> script and address any file name change this series would be
> introducing. There's even a --fix option there that allows
> to automatically fix them (you need to double-check the results).
>
I just ran documentation-file-ref-check, and *no* broken reference found in PCI
documentation. This tool is great!
> Regards,
> Mauro
>
> >
> > On Tue, May 14, 2019 at 10:47:22PM +0800, Changbin Du wrote:
> > > Hi all,
> > >
> > > The kernel now uses Sphinx to generate intelligent and beautiful documentation
> > > from reStructuredText files. I converted most of the Linux PCI docs to rst
> > > format in this serias.
> > >
> > > For you to preview, please visit below url:
> > > http://www.bytemem.com:8080/kernel-doc/PCI/index.html
> > >
> > > Thank you!
> > >
> > > v2: trivial style update.
> > > v3: update titles. (Bjorn Helgaas)
> > > v4: fix comments from Mauro Carvalho Chehab
> > > v5: update MAINTAINERS (Joe Perches)
> > > v6: fix comments.
> > >
> > > Changbin Du (12):
> > > Documentation: add Linux PCI to Sphinx TOC tree
> > > Documentation: PCI: convert pci.txt to reST
> > > Documentation: PCI: convert PCIEBUS-HOWTO.txt to reST
> > > Documentation: PCI: convert pci-iov-howto.txt to reST
> > > Documentation: PCI: convert MSI-HOWTO.txt to reST
> > > Documentation: PCI: convert acpi-info.txt to reST
> > > Documentation: PCI: convert pci-error-recovery.txt to reST
> > > Documentation: PCI: convert pcieaer-howto.txt to reST
> > > Documentation: PCI: convert endpoint/pci-endpoint.txt to reST
> > > Documentation: PCI: convert endpoint/pci-endpoint-cfs.txt to reST
> > > Documentation: PCI: convert endpoint/pci-test-function.txt to reST
> > > Documentation: PCI: convert endpoint/pci-test-howto.txt to reST
> > >
> > > .../PCI/{acpi-info.txt => acpi-info.rst} | 15 +-
> > > Documentation/PCI/endpoint/index.rst | 13 +
> > > ...-endpoint-cfs.txt => pci-endpoint-cfs.rst} | 99 ++---
> > > .../{pci-endpoint.txt => pci-endpoint.rst} | 92 +++--
> > > ...est-function.txt => pci-test-function.rst} | 84 +++--
> > > ...{pci-test-howto.txt => pci-test-howto.rst} | 81 ++--
> > > Documentation/PCI/index.rst | 18 +
> > > .../PCI/{MSI-HOWTO.txt => msi-howto.rst} | 85 +++--
> > > ...or-recovery.txt => pci-error-recovery.rst} | 287 +++++++-------
> > > .../{pci-iov-howto.txt => pci-iov-howto.rst} | 161 ++++----
> > > Documentation/PCI/{pci.txt => pci.rst} | 356 ++++++++----------
> > > .../{pcieaer-howto.txt => pcieaer-howto.rst} | 156 +++++---
> > > .../{PCIEBUS-HOWTO.txt => picebus-howto.rst} | 140 ++++---
> > > Documentation/index.rst | 1 +
> > > MAINTAINERS | 4 +-
> > > include/linux/mod_devicetable.h | 19 +
> > > include/linux/pci.h | 37 ++
> > > 17 files changed, 938 insertions(+), 710 deletions(-)
> > > rename Documentation/PCI/{acpi-info.txt => acpi-info.rst} (96%)
> > > create mode 100644 Documentation/PCI/endpoint/index.rst
> > > rename Documentation/PCI/endpoint/{pci-endpoint-cfs.txt => pci-endpoint-cfs.rst} (64%)
> > > rename Documentation/PCI/endpoint/{pci-endpoint.txt => pci-endpoint.rst} (83%)
> > > rename Documentation/PCI/endpoint/{pci-test-function.txt => pci-test-function.rst} (55%)
> > > rename Documentation/PCI/endpoint/{pci-test-howto.txt => pci-test-howto.rst} (78%)
> > > create mode 100644 Documentation/PCI/index.rst
> > > rename Documentation/PCI/{MSI-HOWTO.txt => msi-howto.rst} (88%)
> > > rename Documentation/PCI/{pci-error-recovery.txt => pci-error-recovery.rst} (67%)
> > > rename Documentation/PCI/{pci-iov-howto.txt => pci-iov-howto.rst} (63%)
> > > rename Documentation/PCI/{pci.txt => pci.rst} (68%)
> > > rename Documentation/PCI/{pcieaer-howto.txt => pcieaer-howto.rst} (72%)
> > > rename Documentation/PCI/{PCIEBUS-HOWTO.txt => picebus-howto.rst} (70%)
> > >
> > > --
> > > 2.20.1
> > >
> >
>
>
>
> Thanks,
> Mauro
--
Cheers,
Changbin Du
^ permalink raw reply
* Re: [PATCH] kbuild: drop support for cc-ldoption
From: Masahiro Yamada @ 2019-05-20 15:08 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Michal Marek, Jonathan Corbet, clang-built-linux,
Linux Kbuild mailing list, open list:DOCUMENTATION,
Linux Kernel Mailing List
In-Reply-To: <20190423212741.12219-1-ndesaulniers@google.com>
On Wed, Apr 24, 2019 at 6:27 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> If you want to see if your linker supports a certain flag, then ask the
> linker directly with ld-option (not the compiler with cc-ldoption).
> Checking for linker flag support is an antipattern that complicates the
> usage of various linkers other than bfd via -fuse-ld={bfd|gold|lld}.
>
> Cc: clang-built-linux@googlegroups.com
> Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
Applied to linux-kbuild. Thanks.
> This should probably wait until all of the call sites have been cleaned
> up. Masahiro sent them for arm and arm64, while I sent cleanups for all
> the rest.
>
>
> Documentation/kbuild/makefiles.txt | 14 --------------
> scripts/Kbuild.include | 5 -----
> 2 files changed, 19 deletions(-)
>
> diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
> index 03c065855eaf..d65ad5746f94 100644
> --- a/Documentation/kbuild/makefiles.txt
> +++ b/Documentation/kbuild/makefiles.txt
> @@ -437,20 +437,6 @@ more details, with real examples.
> The second argument is optional, and if supplied will be used
> if first argument is not supported.
>
> - cc-ldoption
> - cc-ldoption is used to check if $(CC) when used to link object files
> - supports the given option. An optional second option may be
> - specified if first option are not supported.
> -
> - Example:
> - #arch/x86/kernel/Makefile
> - vsyscall-flags += $(call cc-ldoption, -Wl$(comma)--hash-style=sysv)
> -
> - In the above example, vsyscall-flags will be assigned the option
> - -Wl$(comma)--hash-style=sysv if it is supported by $(CC).
> - The second argument is optional, and if supplied will be used
> - if first argument is not supported.
> -
> as-instr
> as-instr checks if the assembler reports a specific instruction
> and then outputs either option1 or option2
> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
> index 7484b9d8272f..fbfb37d1bcc8 100644
> --- a/scripts/Kbuild.include
> +++ b/scripts/Kbuild.include
> @@ -138,11 +138,6 @@ cc-disable-warning = $(call try-run,\
> # Usage: EXTRA_CFLAGS += $(call cc-ifversion, -lt, 0402, -O1)
> cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 ] && echo $(3) || echo $(4))
>
> -# cc-ldoption
> -# Usage: ldflags += $(call cc-ldoption, -Wl$(comma)--hash-style=both)
> -cc-ldoption = $(call try-run,\
> - $(CC) $(1) $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
> -
> # ld-option
> # Usage: KBUILD_LDFLAGS += $(call ld-option, -X, -Y)
> ld-option = $(call try-run, $(LD) $(KBUILD_LDFLAGS) $(1) -v,$(1),$(2),$(3))
> --
> 2.21.0.593.g511ec345e18-goog
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v2 1/5] Documentation: perf: stm32: ddrperfm support
From: Gerald BAEZA @ 2019-05-20 15:27 UTC (permalink / raw)
To: will.deacon@arm.com, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, horms+renesas@verge.net.au,
arnd@arndb.de
Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Gerald BAEZA
In-Reply-To: <1558366019-24214-1-git-send-email-gerald.baeza@st.com>
The DDRPERFM is the DDR Performance Monitor embedded in STM32MP1 SOC.
This documentation introduces the DDRPERFM, the stm32-ddr-pmu driver
supporting it and how to use it with the perf tool.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
Documentation/perf/stm32-ddr-pmu.txt | 41 ++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/perf/stm32-ddr-pmu.txt
diff --git a/Documentation/perf/stm32-ddr-pmu.txt b/Documentation/perf/stm32-ddr-pmu.txt
new file mode 100644
index 0000000..d5b35b3
--- /dev/null
+++ b/Documentation/perf/stm32-ddr-pmu.txt
@@ -0,0 +1,41 @@
+STM32 DDR Performance Monitor (DDRPERFM)
+========================================
+
+The DDRPERFM is the DDR Performance Monitor embedded in STM32MP1 SOC.
+See STM32MP157 reference manual RM0436 to get a description of this peripheral.
+
+
+The five following counters are supported by stm32-ddr-pmu driver:
+ cnt0: read operations counters (read_cnt)
+ cnt1: write operations counters (write_cnt)
+ cnt2: active state counters (activate_cnt)
+ cnt3: idle state counters (idle_cnt)
+ tcnt: time count, present for all sets (time_cnt)
+
+The stm32-ddr-pmu driver relies on the perf PMU framework to expose the
+counters via sysfs:
+ $ ls /sys/bus/event_source/devices/ddrperfm/events
+ activate_cnt idle_cnt read_cnt time_cnt write_cnt
+
+
+The perf PMU framework is usually invoked via the 'perf stat' tool.
+
+The DDRPERFM is a system monitor that cannot isolate the traffic coming from a
+given thread or CPU, that is why stm32-ddr-pmu driver rejects any 'perf stat'
+call that does not request a system-wide collection: the '-a, --all-cpus'
+option is mandatory!
+
+Example:
+ $ perf stat -e ddrperfm/read_cnt/,ddrperfm/time_cnt/ -a sleep 20
+ Performance counter stats for 'system wide':
+
+ 342541560 ddrperfm/read_cnt/
+ 10660011400 ddrperfm/time_cnt/
+
+ 20.021068551 seconds time elapsed
+
+
+The driver also exposes a 'bandwidth' attribute that can be used to display
+the read/write/total bandwidth achieved during the last 'perf stat' execution.
+ $ cat /sys/bus/event_source/devices/ddrperfm/bandwidth
+ Read = 403, Write = 239, Read & Write = 642 (MB/s)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/5] stm32-ddr-pmu driver creation
From: Gerald BAEZA @ 2019-05-20 15:27 UTC (permalink / raw)
To: will.deacon@arm.com, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, horms+renesas@verge.net.au,
arnd@arndb.de
Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Gerald BAEZA
The DDRPERFM is the DDR Performance Monitor embedded in STM32MP1 SOC.
This series adds support for the DDRPERFM via a new stm32-ddr-pmu driver,
registered into the perf framework.
This driver is inspired from arch/arm/mm/cache-l2x0-pmu.c
---
Changes from v1:
- add 'resets' description (bindings) and using (driver). Thanks Rob.
- rebase on 5.2-rc1 (that includes the ddrperfm clock control patch).
Gerald Baeza (5):
Documentation: perf: stm32: ddrperfm support
dt-bindings: perf: stm32: ddrperfm support
perf: stm32: ddrperfm driver creation
ARM: configs: enable STM32_DDR_PMU
ARM: dts: stm32: add ddrperfm on stm32mp157c
.../devicetree/bindings/perf/stm32-ddr-pmu.txt | 20 +
Documentation/perf/stm32-ddr-pmu.txt | 41 ++
arch/arm/boot/dts/stm32mp157c.dtsi | 9 +
arch/arm/configs/multi_v7_defconfig | 1 +
drivers/perf/Kconfig | 6 +
drivers/perf/Makefile | 1 +
drivers/perf/stm32_ddr_pmu.c | 512 +++++++++++++++++++++
7 files changed, 590 insertions(+)
create mode 100644 Documentation/devicetree/bindings/perf/stm32-ddr-pmu.txt
create mode 100644 Documentation/perf/stm32-ddr-pmu.txt
create mode 100644 drivers/perf/stm32_ddr_pmu.c
--
2.7.4
^ permalink raw reply
* [PATCH v2 5/5] ARM: dts: stm32: add ddrperfm on stm32mp157c
From: Gerald BAEZA @ 2019-05-20 15:27 UTC (permalink / raw)
To: will.deacon@arm.com, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, horms+renesas@verge.net.au,
arnd@arndb.de
Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Gerald BAEZA
In-Reply-To: <1558366019-24214-1-git-send-email-gerald.baeza@st.com>
The DDRPERFM is the DDR Performance Monitor embedded
in STM32MP1 SOC.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
arch/arm/boot/dts/stm32mp157c.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
index 2afeee6..7dad246 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -1198,6 +1198,15 @@
};
};
+ ddrperfm: perf@5a007000 {
+ compatible = "st,stm32-ddr-pmu";
+ reg = <0x5a007000 0x400>;
+ clocks = <&rcc DDRPERFM>, <&rcc PLL2_R>;
+ clock-names = "bus", "ddr";
+ resets = <&rcc DDRPERFM_R>;
+ status = "okay";
+ };
+
usart1: serial@5c000000 {
compatible = "st,stm32h7-uart";
reg = <0x5c000000 0x400>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/5] perf: stm32: ddrperfm driver creation
From: Gerald BAEZA @ 2019-05-20 15:27 UTC (permalink / raw)
To: will.deacon@arm.com, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, horms+renesas@verge.net.au,
arnd@arndb.de
Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Gerald BAEZA
In-Reply-To: <1558366019-24214-1-git-send-email-gerald.baeza@st.com>
The DDRPERFM is the DDR Performance Monitor embedded in STM32MP1 SOC.
This perf drivers supports the read, write, activate, idle and total
time counters, described in the reference manual RM0436.
A 'bandwidth' attribute is added in the 'ddrperfm' event_source in order
to directly get the read and write bandwidths (in MB/s), from the last
read, write and total time counters reading.
This attribute is aside the 'events' attributes group because it is not
a counter, as seen by perf tool.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
drivers/perf/Kconfig | 6 +
drivers/perf/Makefile | 1 +
drivers/perf/stm32_ddr_pmu.c | 512 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 519 insertions(+)
create mode 100644 drivers/perf/stm32_ddr_pmu.c
diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index a94e586..9add8a7 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -105,6 +105,12 @@ config THUNDERX2_PMU
The SoC has PMU support in its L3 cache controller (L3C) and
in the DDR4 Memory Controller (DMC).
+config STM32_DDR_PMU
+ tristate "STM32 DDR PMU"
+ depends on MACH_STM32MP157
+ help
+ Support for STM32 DDR performance monitor (DDRPERFM).
+
config XGENE_PMU
depends on ARCH_XGENE
bool "APM X-Gene SoC PMU"
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 3048994..fa64719 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_ARM_SMMU_V3_PMU) += arm_smmuv3_pmu.o
obj-$(CONFIG_HISI_PMU) += hisilicon/
obj-$(CONFIG_QCOM_L2_PMU) += qcom_l2_pmu.o
obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
+obj-$(CONFIG_STM32_DDR_PMU) += stm32_ddr_pmu.o
obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
diff --git a/drivers/perf/stm32_ddr_pmu.c b/drivers/perf/stm32_ddr_pmu.c
new file mode 100644
index 0000000..ae4a813
--- /dev/null
+++ b/drivers/perf/stm32_ddr_pmu.c
@@ -0,0 +1,512 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * This file is the STM32 DDR performance monitor (DDRPERFM) driver
+ *
+ * Copyright (C) 2019, STMicroelectronics - All Rights Reserved
+ * Author: Gerald Baeza <gerald.baeza@st.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/hrtimer.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/perf_event.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+
+#define POLL_MS 4000 /* The counter roll over after ~8s @533MHz */
+#define WORD_LENGTH 4 /* Bytes */
+#define BURST_LENGTH 8 /* Words */
+
+#define DDRPERFM_CTL 0x000
+#define DDRPERFM_CFG 0x004
+#define DDRPERFM_STATUS 0x008
+#define DDRPERFM_CCR 0x00C
+#define DDRPERFM_IER 0x010
+#define DDRPERFM_ISR 0x014
+#define DDRPERFM_ICR 0x018
+#define DDRPERFM_TCNT 0x020
+#define DDRPERFM_CNT(X) (0x030 + 8 * (X))
+#define DDRPERFM_HWCFG 0x3F0
+#define DDRPERFM_VER 0x3F4
+#define DDRPERFM_ID 0x3F8
+#define DDRPERFM_SID 0x3FC
+
+#define CTL_START 0x00000001
+#define CTL_STOP 0x00000002
+#define CCR_CLEAR_ALL 0x8000000F
+#define SID_MAGIC_ID 0xA3C5DD01
+
+#define STRING "Read = %llu, Write = %llu, Read & Write = %llu (MB/s)\n"
+
+enum {
+ READ_CNT,
+ WRITE_CNT,
+ ACTIVATE_CNT,
+ IDLE_CNT,
+ TIME_CNT,
+ PMU_NR_COUNTERS
+};
+
+struct stm32_ddr_pmu {
+ struct pmu pmu;
+ void __iomem *membase;
+ struct clk *clk;
+ struct clk *clk_ddr;
+ unsigned long clk_ddr_rate;
+ struct hrtimer hrtimer;
+ ktime_t poll_period;
+ spinlock_t lock; /* for shared registers access */
+ struct perf_event *events[PMU_NR_COUNTERS];
+ u64 events_cnt[PMU_NR_COUNTERS];
+};
+
+static inline struct stm32_ddr_pmu *pmu_to_stm32_ddr_pmu(struct pmu *p)
+{
+ return container_of(p, struct stm32_ddr_pmu, pmu);
+}
+
+static inline struct stm32_ddr_pmu *hrtimer_to_stm32_ddr_pmu(struct hrtimer *h)
+{
+ return container_of(h, struct stm32_ddr_pmu, hrtimer);
+}
+
+static u64 stm32_ddr_pmu_compute_bw(struct stm32_ddr_pmu *stm32_ddr_pmu,
+ int counter)
+{
+ u64 bw = stm32_ddr_pmu->events_cnt[counter], tmp;
+ u64 div = stm32_ddr_pmu->events_cnt[TIME_CNT];
+ u32 prediv = 1, premul = 1;
+
+ if (bw && div) {
+ /* Maximize the dividend into 64 bits */
+ while ((bw < 0x8000000000000000ULL) &&
+ (premul < 0x40000000UL)) {
+ bw = bw << 1;
+ premul *= 2;
+ }
+ /* Minimize the dividor to fit in 32 bits */
+ while ((div > 0xffffffffUL) && (prediv < 0x40000000UL)) {
+ div = div >> 1;
+ prediv *= 2;
+ }
+ /* Divide counter per time and multiply per DDR settings */
+ do_div(bw, div);
+ tmp = bw * BURST_LENGTH * WORD_LENGTH;
+ tmp *= stm32_ddr_pmu->clk_ddr_rate;
+ if (tmp < bw)
+ goto error;
+ bw = tmp;
+ /* Cancel the prediv and premul factors */
+ while (prediv > 1) {
+ bw = bw >> 1;
+ prediv /= 2;
+ }
+ while (premul > 1) {
+ bw = bw >> 1;
+ premul /= 2;
+ }
+ /* Convert MHz to Hz and B to MB, to finally get MB/s */
+ tmp = bw * 1000000;
+ if (tmp < bw)
+ goto error;
+ bw = tmp;
+ premul = 1024 * 1024;
+ while (premul > 1) {
+ bw = bw >> 1;
+ premul /= 2;
+ }
+ }
+ return bw;
+
+error:
+ pr_warn("stm32-ddr-pmu: overflow detected\n");
+ return 0;
+}
+
+static void stm32_ddr_pmu_event_configure(struct perf_event *event)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = pmu_to_stm32_ddr_pmu(event->pmu);
+ unsigned long lock_flags, config_base = event->hw.config_base;
+ u32 val;
+
+ spin_lock_irqsave(&stm32_ddr_pmu->lock, lock_flags);
+ writel_relaxed(CTL_STOP, stm32_ddr_pmu->membase + DDRPERFM_CTL);
+
+ if (config_base < TIME_CNT) {
+ val = readl_relaxed(stm32_ddr_pmu->membase + DDRPERFM_CFG);
+ val |= (1 << config_base);
+ writel_relaxed(val, stm32_ddr_pmu->membase + DDRPERFM_CFG);
+ }
+ spin_unlock_irqrestore(&stm32_ddr_pmu->lock, lock_flags);
+}
+
+static void stm32_ddr_pmu_event_read(struct perf_event *event)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = pmu_to_stm32_ddr_pmu(event->pmu);
+ unsigned long flags, config_base = event->hw.config_base;
+ struct hw_perf_event *hw = &event->hw;
+ u64 prev_count, new_count, mask;
+ u32 val, offset, bit;
+
+ spin_lock_irqsave(&stm32_ddr_pmu->lock, flags);
+
+ writel_relaxed(CTL_STOP, stm32_ddr_pmu->membase + DDRPERFM_CTL);
+
+ if (config_base == TIME_CNT) {
+ offset = DDRPERFM_TCNT;
+ bit = 1 << 31;
+ } else {
+ offset = DDRPERFM_CNT(config_base);
+ bit = 1 << config_base;
+ }
+ val = readl_relaxed(stm32_ddr_pmu->membase + DDRPERFM_STATUS);
+ if (val & bit)
+ pr_warn("stm32_ddr_pmu hardware overflow\n");
+ val = readl_relaxed(stm32_ddr_pmu->membase + offset);
+ writel_relaxed(bit, stm32_ddr_pmu->membase + DDRPERFM_CCR);
+ writel_relaxed(CTL_START, stm32_ddr_pmu->membase + DDRPERFM_CTL);
+
+ do {
+ prev_count = local64_read(&hw->prev_count);
+ new_count = prev_count + val;
+ } while (local64_xchg(&hw->prev_count, new_count) != prev_count);
+
+ mask = GENMASK_ULL(31, 0);
+ local64_add(val & mask, &event->count);
+
+ if (new_count < prev_count)
+ pr_warn("STM32 DDR PMU counter saturated\n");
+
+ spin_unlock_irqrestore(&stm32_ddr_pmu->lock, flags);
+}
+
+static void stm32_ddr_pmu_event_start(struct perf_event *event, int flags)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = pmu_to_stm32_ddr_pmu(event->pmu);
+ struct hw_perf_event *hw = &event->hw;
+ unsigned long lock_flags;
+
+ if (WARN_ON_ONCE(!(hw->state & PERF_HES_STOPPED)))
+ return;
+
+ if (flags & PERF_EF_RELOAD)
+ WARN_ON_ONCE(!(hw->state & PERF_HES_UPTODATE));
+
+ stm32_ddr_pmu_event_configure(event);
+
+ /* Clear all counters to synchronize them, then start */
+ spin_lock_irqsave(&stm32_ddr_pmu->lock, lock_flags);
+ writel_relaxed(CCR_CLEAR_ALL, stm32_ddr_pmu->membase + DDRPERFM_CCR);
+ writel_relaxed(CTL_START, stm32_ddr_pmu->membase + DDRPERFM_CTL);
+ spin_unlock_irqrestore(&stm32_ddr_pmu->lock, lock_flags);
+
+ hw->state = 0;
+}
+
+static void stm32_ddr_pmu_event_stop(struct perf_event *event, int flags)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = pmu_to_stm32_ddr_pmu(event->pmu);
+ unsigned long lock_flags, config_base = event->hw.config_base;
+ struct hw_perf_event *hw = &event->hw;
+ u32 val, bit;
+
+ if (WARN_ON_ONCE(hw->state & PERF_HES_STOPPED))
+ return;
+
+ spin_lock_irqsave(&stm32_ddr_pmu->lock, lock_flags);
+ writel_relaxed(CTL_STOP, stm32_ddr_pmu->membase + DDRPERFM_CTL);
+ if (config_base == TIME_CNT)
+ bit = 1 << 31;
+ else
+ bit = 1 << config_base;
+ writel_relaxed(bit, stm32_ddr_pmu->membase + DDRPERFM_CCR);
+ if (config_base < TIME_CNT) {
+ val = readl_relaxed(stm32_ddr_pmu->membase + DDRPERFM_CFG);
+ val &= ~bit;
+ writel_relaxed(val, stm32_ddr_pmu->membase + DDRPERFM_CFG);
+ }
+ spin_unlock_irqrestore(&stm32_ddr_pmu->lock, lock_flags);
+
+ hw->state |= PERF_HES_STOPPED;
+
+ if (flags & PERF_EF_UPDATE) {
+ stm32_ddr_pmu_event_read(event);
+ hw->state |= PERF_HES_UPTODATE;
+ }
+}
+
+static int stm32_ddr_pmu_event_add(struct perf_event *event, int flags)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = pmu_to_stm32_ddr_pmu(event->pmu);
+ unsigned long config_base = event->hw.config_base;
+ struct hw_perf_event *hw = &event->hw;
+
+ stm32_ddr_pmu->events_cnt[config_base] = 0;
+ stm32_ddr_pmu->events[config_base] = event;
+
+ clk_enable(stm32_ddr_pmu->clk);
+ hrtimer_start(&stm32_ddr_pmu->hrtimer, stm32_ddr_pmu->poll_period,
+ HRTIMER_MODE_REL);
+
+ stm32_ddr_pmu_event_configure(event);
+
+ hw->state = PERF_HES_STOPPED | PERF_HES_UPTODATE;
+
+ if (flags & PERF_EF_START)
+ stm32_ddr_pmu_event_start(event, 0);
+
+ return 0;
+}
+
+static void stm32_ddr_pmu_event_del(struct perf_event *event, int flags)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = pmu_to_stm32_ddr_pmu(event->pmu);
+ unsigned long config_base = event->hw.config_base;
+ bool stop = true;
+ int i;
+
+ stm32_ddr_pmu_event_stop(event, PERF_EF_UPDATE);
+
+ stm32_ddr_pmu->events_cnt[config_base] += local64_read(&event->count);
+ stm32_ddr_pmu->events[config_base] = NULL;
+
+ for (i = 0; i < PMU_NR_COUNTERS; i++)
+ if (stm32_ddr_pmu->events[i])
+ stop = false;
+ if (stop)
+ hrtimer_cancel(&stm32_ddr_pmu->hrtimer);
+
+ clk_disable(stm32_ddr_pmu->clk);
+}
+
+static int stm32_ddr_pmu_event_init(struct perf_event *event)
+{
+ struct hw_perf_event *hw = &event->hw;
+
+ if (is_sampling_event(event))
+ return -EINVAL;
+
+ if (event->attach_state & PERF_ATTACH_TASK)
+ return -EINVAL;
+
+ if (event->attr.exclude_user ||
+ event->attr.exclude_kernel ||
+ event->attr.exclude_hv ||
+ event->attr.exclude_idle ||
+ event->attr.exclude_host ||
+ event->attr.exclude_guest)
+ return -EINVAL;
+
+ if (event->cpu < 0)
+ return -EINVAL;
+
+ hw->config_base = event->attr.config;
+
+ return 0;
+}
+
+static enum hrtimer_restart stm32_ddr_pmu_poll(struct hrtimer *hrtimer)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = hrtimer_to_stm32_ddr_pmu(hrtimer);
+ int i;
+
+ for (i = 0; i < PMU_NR_COUNTERS; i++)
+ if (stm32_ddr_pmu->events[i])
+ stm32_ddr_pmu_event_read(stm32_ddr_pmu->events[i]);
+
+ hrtimer_forward_now(hrtimer, stm32_ddr_pmu->poll_period);
+
+ return HRTIMER_RESTART;
+}
+
+static ssize_t stm32_ddr_pmu_sysfs_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct dev_ext_attribute *eattr;
+
+ eattr = container_of(attr, struct dev_ext_attribute, attr);
+
+ return sprintf(buf, "config=0x%lx\n", (unsigned long)eattr->var);
+}
+
+static ssize_t bandwidth_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = dev_get_drvdata(dev);
+ u64 r_bw, w_bw;
+ int ret;
+
+ if (stm32_ddr_pmu->events_cnt[TIME_CNT]) {
+ r_bw = stm32_ddr_pmu_compute_bw(stm32_ddr_pmu, READ_CNT);
+ w_bw = stm32_ddr_pmu_compute_bw(stm32_ddr_pmu, WRITE_CNT);
+
+ ret = snprintf(buf, PAGE_SIZE, STRING,
+ r_bw, w_bw, (r_bw + w_bw));
+ } else {
+ ret = snprintf(buf, PAGE_SIZE, "No data available\n");
+ }
+
+ return ret;
+}
+
+#define STM32_DDR_PMU_ATTR(_name, _func, _config) \
+ (&((struct dev_ext_attribute[]) { \
+ { __ATTR(_name, 0444, _func, NULL), (void *)_config } \
+ })[0].attr.attr)
+
+#define STM32_DDR_PMU_EVENT_ATTR(_name, _config) \
+ STM32_DDR_PMU_ATTR(_name, stm32_ddr_pmu_sysfs_show, \
+ (unsigned long)_config)
+
+static struct attribute *stm32_ddr_pmu_event_attrs[] = {
+ STM32_DDR_PMU_EVENT_ATTR(read_cnt, READ_CNT),
+ STM32_DDR_PMU_EVENT_ATTR(write_cnt, WRITE_CNT),
+ STM32_DDR_PMU_EVENT_ATTR(activate_cnt, ACTIVATE_CNT),
+ STM32_DDR_PMU_EVENT_ATTR(idle_cnt, IDLE_CNT),
+ STM32_DDR_PMU_EVENT_ATTR(time_cnt, TIME_CNT),
+ NULL
+};
+
+static DEVICE_ATTR_RO(bandwidth);
+static struct attribute *stm32_ddr_pmu_bandwidth_attrs[] = {
+ &dev_attr_bandwidth.attr,
+ NULL,
+};
+
+static struct attribute_group stm32_ddr_pmu_event_attrs_group = {
+ .name = "events",
+ .attrs = stm32_ddr_pmu_event_attrs,
+};
+
+static struct attribute_group stm32_ddr_pmu_bandwidth_attrs_group = {
+ .attrs = stm32_ddr_pmu_bandwidth_attrs,
+};
+
+static const struct attribute_group *stm32_ddr_pmu_attr_groups[] = {
+ &stm32_ddr_pmu_event_attrs_group,
+ &stm32_ddr_pmu_bandwidth_attrs_group,
+ NULL,
+};
+
+static int stm32_ddr_pmu_device_probe(struct platform_device *pdev)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu;
+ struct reset_control *rst;
+ struct resource *res;
+ int i, ret;
+ u32 val;
+
+ stm32_ddr_pmu = devm_kzalloc(&pdev->dev, sizeof(struct stm32_ddr_pmu),
+ GFP_KERNEL);
+ if (!stm32_ddr_pmu)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, stm32_ddr_pmu);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ stm32_ddr_pmu->membase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(stm32_ddr_pmu->membase)) {
+ pr_warn("Unable to get STM32 DDR PMU membase\n");
+ return PTR_ERR(stm32_ddr_pmu->membase);
+ }
+
+ stm32_ddr_pmu->clk = devm_clk_get(&pdev->dev, "bus");
+ if (IS_ERR(stm32_ddr_pmu->clk)) {
+ pr_warn("Unable to get STM32 DDR PMU clock\n");
+ return PTR_ERR(stm32_ddr_pmu->clk);
+ }
+
+ ret = clk_prepare_enable(stm32_ddr_pmu->clk);
+ if (ret) {
+ pr_warn("Unable to prepare STM32 DDR PMU clock\n");
+ return ret;
+ }
+
+ stm32_ddr_pmu->clk_ddr = devm_clk_get(&pdev->dev, "ddr");
+ if (IS_ERR(stm32_ddr_pmu->clk_ddr)) {
+ pr_warn("Unable to get STM32 DDR clock\n");
+ return PTR_ERR(stm32_ddr_pmu->clk_ddr);
+ }
+ stm32_ddr_pmu->clk_ddr_rate = clk_get_rate(stm32_ddr_pmu->clk_ddr);
+ stm32_ddr_pmu->clk_ddr_rate /= 1000000;
+
+ stm32_ddr_pmu->poll_period = ms_to_ktime(POLL_MS);
+ hrtimer_init(&stm32_ddr_pmu->hrtimer, CLOCK_MONOTONIC,
+ HRTIMER_MODE_REL);
+ stm32_ddr_pmu->hrtimer.function = stm32_ddr_pmu_poll;
+ spin_lock_init(&stm32_ddr_pmu->lock);
+
+ for (i = 0; i < PMU_NR_COUNTERS; i++) {
+ stm32_ddr_pmu->events[i] = NULL;
+ stm32_ddr_pmu->events_cnt[i] = 0;
+ }
+
+ val = readl_relaxed(stm32_ddr_pmu->membase + DDRPERFM_SID);
+ if (val != SID_MAGIC_ID)
+ return -EINVAL;
+
+ stm32_ddr_pmu->pmu = (struct pmu) {
+ .task_ctx_nr = perf_invalid_context,
+ .start = stm32_ddr_pmu_event_start,
+ .stop = stm32_ddr_pmu_event_stop,
+ .add = stm32_ddr_pmu_event_add,
+ .del = stm32_ddr_pmu_event_del,
+ .event_init = stm32_ddr_pmu_event_init,
+ .attr_groups = stm32_ddr_pmu_attr_groups,
+ };
+ ret = perf_pmu_register(&stm32_ddr_pmu->pmu, "ddrperfm", -1);
+ if (ret) {
+ pr_warn("Unable to register STM32 DDR PMU\n");
+ return ret;
+ }
+
+ rst = devm_reset_control_get_exclusive(&pdev->dev, NULL);
+ if (!IS_ERR(rst)) {
+ reset_control_assert(rst);
+ udelay(2);
+ reset_control_deassert(rst);
+ }
+
+ pr_info("stm32-ddr-pmu: probed (ID=0x%08x VER=0x%08x), DDR@%luMHz\n",
+ readl_relaxed(stm32_ddr_pmu->membase + DDRPERFM_ID),
+ readl_relaxed(stm32_ddr_pmu->membase + DDRPERFM_VER),
+ stm32_ddr_pmu->clk_ddr_rate);
+
+ clk_disable(stm32_ddr_pmu->clk);
+
+ return 0;
+}
+
+static int stm32_ddr_pmu_device_remove(struct platform_device *pdev)
+{
+ struct stm32_ddr_pmu *stm32_ddr_pmu = platform_get_drvdata(pdev);
+
+ perf_pmu_unregister(&stm32_ddr_pmu->pmu);
+
+ return 0;
+}
+
+static const struct of_device_id stm32_ddr_pmu_of_match[] = {
+ { .compatible = "st,stm32-ddr-pmu" },
+ { },
+};
+
+static struct platform_driver stm32_ddr_pmu_driver = {
+ .driver = {
+ .name = "stm32-ddr-pmu",
+ .of_match_table = of_match_ptr(stm32_ddr_pmu_of_match),
+ },
+ .probe = stm32_ddr_pmu_device_probe,
+ .remove = stm32_ddr_pmu_device_remove,
+};
+
+module_platform_driver(stm32_ddr_pmu_driver);
+
+MODULE_DESCRIPTION("Perf driver for STM32 DDR performance monitor");
+MODULE_AUTHOR("Gerald Baeza <gerald.baeza@st.com>");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/5] dt-bindings: perf: stm32: ddrperfm support
From: Gerald BAEZA @ 2019-05-20 15:27 UTC (permalink / raw)
To: will.deacon@arm.com, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, horms+renesas@verge.net.au,
arnd@arndb.de
Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Gerald BAEZA
In-Reply-To: <1558366019-24214-1-git-send-email-gerald.baeza@st.com>
The DDRPERFM is the DDR Performance Monitor embedded in STM32MP1 SOC.
This documentation indicates how to enable stm32-ddr-pmu driver on
DDRPERFM peripheral, via the device tree.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
.../devicetree/bindings/perf/stm32-ddr-pmu.txt | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/perf/stm32-ddr-pmu.txt
diff --git a/Documentation/devicetree/bindings/perf/stm32-ddr-pmu.txt b/Documentation/devicetree/bindings/perf/stm32-ddr-pmu.txt
new file mode 100644
index 0000000..9d36209
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/stm32-ddr-pmu.txt
@@ -0,0 +1,20 @@
+* STM32 DDR Performance Monitor (DDRPERFM)
+
+Required properties:
+- compatible: must be "st,stm32-ddr-pmu".
+- reg: physical address and length of the registers set.
+- clocks: list of phandles and specifiers to all input clocks listed in
+ clock-names property.
+- clock-names: "bus" corresponds to the DDRPERFM bus clock and "ddr" to
+ the DDR frequency.
+- resets: phandle to the reset controller and DDRPERFM reset specifier
+
+Example:
+ ddrperfm: perf@5a007000 {
+ compatible = "st,stm32-ddr-pmu";
+ reg = <0x5a007000 0x400>;
+ clocks = <&rcc DDRPERFM>, <&rcc PLL2_R>;
+ clock-names = "bus", "ddr";
+ resets = <&rcc DDRPERFM_R>;
+ };
+
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/5] ARM: configs: enable STM32_DDR_PMU
From: Gerald BAEZA @ 2019-05-20 15:27 UTC (permalink / raw)
To: will.deacon@arm.com, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, horms+renesas@verge.net.au,
arnd@arndb.de
Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Gerald BAEZA
In-Reply-To: <1558366019-24214-1-git-send-email-gerald.baeza@st.com>
STM32_DDR_PMU enables the perf driver that
controls the DDR Performance Monitor (DDRPERFM)
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
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 6b748f2..059b1b9 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1009,6 +1009,7 @@ CONFIG_PHY_DM816X_USB=m
CONFIG_OMAP_USB2=y
CONFIG_TI_PIPE3=y
CONFIG_TWL4030_USB=m
+CONFIG_STM32_DDR_PMU=m
CONFIG_MESON_MX_EFUSE=m
CONFIG_ROCKCHIP_EFUSE=m
CONFIG_NVMEM_IMX_OCOTP=y
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 1/2] ftpm: firmware TPM running in TEE
From: Igor Opaniuk @ 2019-05-20 15:30 UTC (permalink / raw)
To: Sasha Levin
Cc: peterhuewe, jarkko.sakkinen, jgg, corbet, linux-kernel, linux-doc,
linux-integrity, linux-kernel, thiruan, bryankel
In-Reply-To: <20190415155636.32748-2-sashal@kernel.org>
Hi Sasha,
Just my two cents here after a quick look:
On Mon, Apr 15, 2019 at 6:58 PM Sasha Levin <sashal@kernel.org> wrote:
>
> This patch adds support for a software-only implementation of a TPM
> running in TEE.
>
> There is extensive documentation of the design here:
> https://www.microsoft.com/en-us/research/publication/ftpm-software-implementation-tpm-chip/ .
>
> As well as reference code for the firmware available here:
> https://github.com/Microsoft/ms-tpm-20-ref/tree/master/Samples/ARM32-FirmwareTPM
>
> Signed-off-by: Thirupathaiah Annapureddy <thiruan@microsoft.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> drivers/char/tpm/Kconfig | 5 +
> drivers/char/tpm/Makefile | 1 +
> drivers/char/tpm/tpm_ftpm_tee.c | 366 ++++++++++++++++++++++++++++++++
> drivers/char/tpm/tpm_ftpm_tee.h | 47 ++++
> 4 files changed, 419 insertions(+)
> create mode 100644 drivers/char/tpm/tpm_ftpm_tee.c
> create mode 100644 drivers/char/tpm/tpm_ftpm_tee.h
>
> diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> index 536e55d3919f..5638726641eb 100644
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -164,6 +164,11 @@ config TCG_VTPM_PROXY
> /dev/vtpmX and a server-side file descriptor on which the vTPM
> can receive commands.
>
> +config TCG_FTPM_TEE
> + tristate "TEE based fTPM Interface"
> + depends on TEE
depends on OPTEE also.
> + ---help---
> + This driver proxies for fTPM running in TEE
>
> source "drivers/char/tpm/st33zp24/Kconfig"
> endif # TCG_TPM
> diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
> index a01c4cab902a..c354cdff9c62 100644
> --- a/drivers/char/tpm/Makefile
> +++ b/drivers/char/tpm/Makefile
> @@ -33,3 +33,4 @@ obj-$(CONFIG_TCG_TIS_ST33ZP24) += st33zp24/
> obj-$(CONFIG_TCG_XEN) += xen-tpmfront.o
> obj-$(CONFIG_TCG_CRB) += tpm_crb.o
> obj-$(CONFIG_TCG_VTPM_PROXY) += tpm_vtpm_proxy.o
> +obj-$(CONFIG_TCG_FTPM_TEE) += tpm_ftpm_tee.o
> diff --git a/drivers/char/tpm/tpm_ftpm_tee.c b/drivers/char/tpm/tpm_ftpm_tee.c
> new file mode 100644
> index 000000000000..f33cdfeb5376
> --- /dev/null
> +++ b/drivers/char/tpm/tpm_ftpm_tee.c
> @@ -0,0 +1,366 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) Microsoft Corporation
> + */
> +
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/acpi.h>
> +#include <linux/platform_device.h>
> +#include <linux/tee_drv.h>
> +#include <linux/uuid.h>
> +#include <linux/tpm.h>
minor: alphabetical order (simplify detecting duplicate include files etc)
> +
> +#include "tpm.h"
> +#include "tpm_ftpm_tee.h"
> +
> +#define DRIVER_NAME "ftpm-tee"
> +
Please add a comment about TA UUID (what is it etc.), and where it is
defined in the ms-tpm-ta repository.
> +/* TA_FTPM_UUID: BC50D971-D4C9-42C4-82CB-343FB7F37896 */
> +static const uuid_t ftpm_ta_uuid =
> + UUID_INIT(0xBC50D971, 0xD4C9, 0x42C4,
> + 0x82, 0xCB, 0x34, 0x3F, 0xB7, 0xF3, 0x78, 0x96);
> +
> +/*
> + * Note: ftpm_tee_tpm_op_recv and ftpm_tee_tpm_op_send are called from the
> + * same routine tpm_try_transmit in tpm-interface.c. These calls are protected
> + * by chip->tpm_mutex => There is no need for protecting any data shared
> + * between these routines ex: struct ftpm_tee_private
> + */
> +
> +/**
> + * ftpm_tee_tpm_op_recv retrieve fTPM response.
> + * @param: chip, the tpm_chip description as specified in driver/char/tpm/tpm.h.
> + * @param: buf, the buffer to store data.
> + * @param: count, the number of bytes to read.
> + * @return: In case of success the number of bytes received.
> + * In other case, a < 0 value describing the issue.
> + */
> +static int ftpm_tee_tpm_op_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> +{
> + struct ftpm_tee_private *pvt_data = dev_get_drvdata(chip->dev.parent);
> + size_t len;
> +
> + len = pvt_data->resp_len;
> + if (count < len) {
> + dev_err(&chip->dev,
> + "%s:Invalid size in recv: count=%zd, resp_len=%zd\n",
> + __func__, count, len);
> + return -EIO;
> + }
> +
> + memcpy(buf, pvt_data->resp_buf, len);
> + pvt_data->resp_len = 0;
> +
> + return len;
> +}
> +
> +/**
> + * ftpm_tee_tpm_op_send send TPM commands through the TEE shared memory.
> + *
> + * @param: chip, the tpm_chip description as specified in driver/char/tpm/tpm.h
> + * @param: buf, the buffer to send.
> + * @param: len, the number of bytes to send.
> + * @return: In case of success, returns 0.
> + * In other case, a < 0 value describing the issue.
> + */
> +static int ftpm_tee_tpm_op_send(struct tpm_chip *chip, u8 *buf, size_t len)
> +{
> + struct ftpm_tee_private *pvt_data = dev_get_drvdata(chip->dev.parent);
> + size_t resp_len;
> + int rc;
> + u8 *temp_buf;
> + struct tpm_header *resp_header;
> + struct tee_ioctl_invoke_arg transceive_args;
> + struct tee_param command_params[4];
> + struct tee_shm *shm = pvt_data->shm;
> +
> + if (len > MAX_COMMAND_SIZE) {
> + dev_err(&chip->dev,
> + "%s:len=%zd exceeds MAX_COMMAND_SIZE supported by fTPM TA\n",
> + __func__, len);
> + return -EIO;
> + }
> +
> + memset(&transceive_args, 0, sizeof(transceive_args));
> + memset(command_params, 0, sizeof(command_params));
> + pvt_data->resp_len = 0;
> +
> + /* Invoke FTPM_OPTEE_TA_SUBMIT_COMMAND function of fTPM TA */
> + transceive_args = (struct tee_ioctl_invoke_arg) {
> + .func = FTPM_OPTEE_TA_SUBMIT_COMMAND,
> + .session = pvt_data->session,
> + .num_params = 4,
> + };
> +
> + /* Fill FTPM_OPTEE_TA_SUBMIT_COMMAND parameters */
> + command_params[0] = (struct tee_param) {
> + .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT,
> + .u.memref = {
> + .shm = shm,
> + .size = len,
> + .shm_offs = 0,
> + },
> + };
> +
> + temp_buf = tee_shm_get_va(shm, 0);
> + if (IS_ERR(temp_buf)) {
> + dev_err(&chip->dev, "%s:tee_shm_get_va failed for transmit\n",
> + __func__);
> + return PTR_ERR(temp_buf);
> + }
> + memset(temp_buf, 0, (MAX_COMMAND_SIZE + MAX_RESPONSE_SIZE));
> +
> + memcpy(temp_buf, buf, len);
> +
> + command_params[1] = (struct tee_param) {
> + .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT,
> + .u.memref = {
> + .shm = shm,
> + .size = MAX_RESPONSE_SIZE,
> + .shm_offs = MAX_COMMAND_SIZE,
> + },
> + };
> +
> + rc = tee_client_invoke_func(pvt_data->ctx, &transceive_args,
> + command_params);
> + if ((rc < 0) || (transceive_args.ret != 0)) {
> + dev_err(&chip->dev, "%s:SUBMIT_COMMAND invoke error: 0x%x\n",
> + __func__, transceive_args.ret);
> + return (rc < 0) ? rc : transceive_args.ret;
> + }
> +
> + temp_buf = tee_shm_get_va(shm, command_params[1].u.memref.shm_offs);
> + if (IS_ERR(temp_buf)) {
> + dev_err(&chip->dev, "%s:tee_shm_get_va failed for receive\n",
> + __func__);
> + return PTR_ERR(temp_buf);
> + }
> +
> + resp_header = (struct tpm_header *)temp_buf;
> + resp_len = be32_to_cpu(resp_header->length);
> +
> + /* sanity check resp_len */
> + if (resp_len < TPM_HEADER_SIZE) {
> + dev_err(&chip->dev, "%s:tpm response header too small\n",
> + __func__);
> + return -EIO;
> + }
> + if (resp_len > MAX_RESPONSE_SIZE) {
> + dev_err(&chip->dev,
> + "%s:resp_len=%zd exceeds MAX_RESPONSE_SIZE\n",
> + __func__, resp_len);
> + return -EIO;
> + }
> +
> + /* sanity checks look good, cache the response */
> + memcpy(pvt_data->resp_buf, temp_buf, resp_len);
> + pvt_data->resp_len = resp_len;
> +
> + return 0;
> +}
> +
> +static void ftpm_tee_tpm_op_cancel(struct tpm_chip *chip)
> +{
> + /* not supported */
> +}
Check my patch 4f062dc1b75 ("tee: add cancellation support to client
interface"), with this API you can easily implement cancellation using
tee_client_cancel_req(...).
Within MS fwTPM TA implementation it also can be implemented by
checking the cancellation flag calling GP API
TEE_GetCancellationFlag() (AFAIK this should be done in
_plat__IsCanceled(void) wrapper function).
> +
> +static u8 ftpm_tee_tpm_op_status(struct tpm_chip *chip)
> +{
> + return 0;
> +}
> +
> +static bool ftpm_tee_tpm_req_canceled(struct tpm_chip *chip, u8 status)
> +{
> + return 0;
> +}
> +
> +static const struct tpm_class_ops ftpm_tee_tpm_ops = {
> + .flags = TPM_OPS_AUTO_STARTUP,
> + .recv = ftpm_tee_tpm_op_recv,
> + .send = ftpm_tee_tpm_op_send,
> + .cancel = ftpm_tee_tpm_op_cancel,
> + .status = ftpm_tee_tpm_op_status,
> + .req_complete_mask = 0,
> + .req_complete_val = 0,
> + .req_canceled = ftpm_tee_tpm_req_canceled,
> +};
> +
> +/*
> + * Check whether this driver supports the fTPM TA in the TEE instance
> + * represented by the params (ver/data) to this function.
> + */
> +static int ftpm_tee_match(struct tee_ioctl_version_data *ver, const void *data)
> +{
> + /*
> + * Currently this driver only support GP Complaint OPTEE based fTPM TA
> + */
This can be done implicitly by providing tee_ioctl_version_data struct
with proper values as the last param when the context is opened
(tee_client_open_context() invocation).
Something like this:
struct tee_ioctl_version_data vers = {
.impl_id = TEE_OPTEE_CAP_TZ,
.impl_caps = TEE_IMPL_ID_OPTEE,
.gen_caps = TEE_GEN_CAP_GP,
};
And then:
tee_client_open_context(NULL, ftpm_tee_match, NULL, &vers);
> + if ((ver->impl_id == TEE_IMPL_ID_OPTEE) &&
> + (ver->gen_caps & TEE_GEN_CAP_GP))
> + return 1;
> + else
> + return 0;
> +}
> +
> +/*
> + * Undo what has been done in ftpm_tee_probe
> + */
> +static void ftpm_tee_deinit(struct ftpm_tee_private *pvt_data)
> +{
> + /* Release the chip */
> + tpm_chip_unregister(pvt_data->chip);
> +
> + /* frees chip */
> + if (pvt_data->chip)
> + put_device(&pvt_data->chip->dev);
> +
> + if (pvt_data->ctx) {
> + /* Free the shared memory pool */
> + tee_shm_free(pvt_data->shm);
> +
> + /* close the existing session with fTPM TA*/
> + tee_client_close_session(pvt_data->ctx, pvt_data->session);
> +
> + /* close the context with TEE driver */
> + tee_client_close_context(pvt_data->ctx);
> + }
> +
> + /* memory allocated with devm_kzalloc() is freed automatically */
> +}
> +
> +/**
> + * ftpm_tee_probe initialize the fTPM
> + * @param: pdev, the platform_device description.
> + * @return: 0 in case of success.
> + * or a negative value describing the error.
> + */
> +static int ftpm_tee_probe(struct platform_device *pdev)
> +{
> + int rc;
> + struct tpm_chip *chip;
> + struct device *dev = &pdev->dev;
> + struct ftpm_tee_private *pvt_data = NULL;
> + struct tee_ioctl_open_session_arg sess_arg;
> +
> + pvt_data = devm_kzalloc(dev, sizeof(struct ftpm_tee_private),
> + GFP_KERNEL);
> + if (!pvt_data)
> + return -ENOMEM;
> +
> + dev_set_drvdata(dev, pvt_data);
> +
> + /* Open context with TEE driver */
> + pvt_data->ctx = tee_client_open_context(NULL, ftpm_tee_match, NULL,
> + NULL);
Check my comments above about tee_ioctl_version_data struct.
> + if (IS_ERR(pvt_data->ctx)) {
> + dev_err(dev, "%s:tee_client_open_context failed\n", __func__);
> + return -EPROBE_DEFER;
> + }
> +
> + /* Open a session with fTPM TA */
> + memset(&sess_arg, 0, sizeof(sess_arg));
> + memcpy(sess_arg.uuid, ftpm_ta_uuid.b, TEE_IOCTL_UUID_LEN);
> + sess_arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC;
> + sess_arg.num_params = 0;
> +
> + rc = tee_client_open_session(pvt_data->ctx, &sess_arg, NULL);
> + if ((rc < 0) || (sess_arg.ret != 0)) {
> + dev_err(dev, "%s:tee_client_open_session failed, err=%x\n",
> + __func__, sess_arg.ret);
> + rc = -EINVAL;
> + goto out_tee_session;
> + }
> + pvt_data->session = sess_arg.session;
> +
> + /* Allocate dynamic shared memory with fTPM TA */
> + pvt_data->shm = tee_shm_alloc(pvt_data->ctx,
> + (MAX_COMMAND_SIZE + MAX_RESPONSE_SIZE),
> + TEE_SHM_MAPPED | TEE_SHM_DMA_BUF);
Why not to keep stuff in two different shm buffers instead (one for
cmd buffer, another for response)?
It will definitely simplify the implementation from both fwtpm driver
and TA sides.
> + if (IS_ERR(pvt_data->shm)) {
> + dev_err(dev, "%s:tee_shm_alloc failed\n", __func__);
> + rc = -ENOMEM;
> + goto out_shm_alloc;
> + }
> +
> + /* Allocate new struct tpm_chip instance */
> + chip = tpm_chip_alloc(dev, &ftpm_tee_tpm_ops);
> + if (IS_ERR(chip)) {
> + dev_err(dev, "%s:tpm_chip_alloc failed\n", __func__);
> + rc = PTR_ERR(chip);
> + goto out_chip_alloc;
> + }
> +
> + pvt_data->chip = chip;
> + pvt_data->chip->flags |= TPM_CHIP_FLAG_TPM2;
> +
> + /* Create a character device for the fTPM */
> + rc = tpm_chip_register(pvt_data->chip);
> + if (rc) {
> + dev_err(dev, "%s:tpm_chip_register failed with rc=%d\n",
> + __func__, rc);
> + goto out_chip;
> + }
> +
> + return 0;
> +
> +out_chip:
> + put_device(&pvt_data->chip->dev);
> +out_chip_alloc:
> + tee_shm_free(pvt_data->shm);
> +out_shm_alloc:
> + tee_client_close_session(pvt_data->ctx, pvt_data->session);
> +out_tee_session:
> + tee_client_close_context(pvt_data->ctx);
> +
> + return rc;
> +}
> +
> +/**
> + * ftpm_tee_remove remove the TPM device
> + * @param: pdev, the platform_device description.
> + * @return: 0 in case of success.
> + */
> +static int ftpm_tee_remove(struct platform_device *pdev)
> +{
> + struct ftpm_tee_private *pvt_data = dev_get_drvdata(&pdev->dev);
> +
> + /* Release the chip */
> + tpm_chip_unregister(pvt_data->chip);
> +
> + /* frees chip */
> + put_device(&pvt_data->chip->dev);
> +
> + /* Free the shared memory pool */
> + tee_shm_free(pvt_data->shm);
> +
> + /* close the existing session with fTPM TA*/
> + tee_client_close_session(pvt_data->ctx, pvt_data->session);
> +
> + /* close the context with TEE driver */
> + tee_client_close_context(pvt_data->ctx);
> +
> + /* memory allocated with devm_kzalloc() is freed automatically */
> +
> + return 0;
> +}
> +
> +static const struct of_device_id of_ftpm_tee_ids[] = {
> + { .compatible = "microsoft,ftpm" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, of_ftpm_tee_ids);
> +
> +static struct platform_driver ftpm_tee_driver = {
> + .driver = {
> + .name = DRIVER_NAME,
> + .of_match_table = of_match_ptr(of_ftpm_tee_ids),
> + },
> + .probe = ftpm_tee_probe,
> + .remove = ftpm_tee_remove,
> +};
> +
> +module_platform_driver(ftpm_tee_driver);
> +
> +MODULE_AUTHOR("Thirupathaiah Annapureddy <thiruan@microsoft.com>");
> +MODULE_DESCRIPTION("TPM Driver for fTPM TA in TEE");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/char/tpm/tpm_ftpm_tee.h b/drivers/char/tpm/tpm_ftpm_tee.h
> new file mode 100644
> index 000000000000..9de513e72dbb
> --- /dev/null
> +++ b/drivers/char/tpm/tpm_ftpm_tee.h
> @@ -0,0 +1,47 @@
> +// SPDX-License-Identifier: GPL-2.0
... header files, instead, use traditional (/* */) comments for
reasons related to tooling [1]
/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) Microsoft Corporation
> + */
> +
> +#ifndef __TPM_FTPM_TEE_H__
> +#define __TPM_FTPM_TEE_H__
> +
> +#include <linux/tee_drv.h>
> +#include <linux/uuid.h>
> +#include <linux/tpm.h>
minor: alphabetical order of includes?
> +
> +/* The TAFs ID implemented in this TA */
> +#define FTPM_OPTEE_TA_SUBMIT_COMMAND (0)
> +#define FTPM_OPTEE_TA_EMULATE_PPI (1)
> +
> +/* max. buffer size supported by fTPM */
> +#define MAX_COMMAND_SIZE 4096
> +#define MAX_RESPONSE_SIZE 4096
> +
> +/**
> + * struct ftpm_tee_private - fTPM's private data
> + * @chip: struct tpm_chip instance registered with tpm framework.
> + * @state: internal state
> + * @session: fTPM TA session identifier.
> + * @resp_len: cached response buffer length.
> + * @resp_buf: cached response buffer.
> + * @ctx: TEE context handler.
> + * @shm: Memory pool shared with fTPM TA in TEE.
> + */
> +struct ftpm_tee_private {
> + struct tpm_chip *chip;
> + u32 session;
> + size_t resp_len;
> + u8 resp_buf[MAX_RESPONSE_SIZE];
> + struct tee_context *ctx;
> + struct tee_shm *shm;
> +};
> +
> +/*
> + * Note: ftpm_tee_tpm_op_recv and ftpm_tee_tpm_op_send are called from the
> + * same routine tpm_try_transmit in tpm-interface.c. These calls are protected
> + * by chip->tpm_mutex => There is no need for protecting any data shared
> + * between these routines ex: struct ftpm_tee_private
> + */
> +
> +#endif /* __TPM_FTPM_TEE_H__ */
> --
> 2.19.1
>
And also a question, a while ago I implemented a similar fTPM driver
in U-boot and managed to get it working with MS TPM2.0 TA (integrated
into OP-TEE blob as Early TA) ,and eMMC RPMB was used under the hood
as a secure storage.
This also needed some minor changes in the TA.
Let me know if you're planning to introduce/or generally interested in
having a similar driver in U-boot mainline (I think it's better to
have a driver synced with the one in the Linux mainline, just in a
sake of avoiding possible code divergence), if there are no such plans
- I'll send on my own patch-series based on this driver ASAP when it's
accepted.
[1] https://lwn.net/Articles/739183/
Thanks!
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opaniuk@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
^ permalink raw reply
* Re: [PATCH 09/10] dt: fix broken references to nand.txt
From: Miquel Raynal @ 2019-05-20 15:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Liang Yang, David Woodhouse, Brian Norris,
Marek Vasut, Richard Weinberger, Vignesh Raghavendra, Rob Herring,
Mark Rutland, Kevin Hilman, Marc Gonzalez, Mans Rullgard,
linux-mtd, devicetree, linux-arm-kernel, linux-amlogic
In-Reply-To: <ce7602ba4d42e094a8b7fcf1dc2a01d25192a602.1558362030.git.mchehab+samsung@kernel.org>
Hi Mauro,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote on Mon, 20 May
2019 11:47:38 -0300:
> The Documentation/devicetree/bindings/mtd/nand.txt were both renamed
> and converted to YAML on a single patch, without updating references
> to it. That caused several cross-references to break.
>
> Fixes: 212e49693592 ("dt-bindings: mtd: Add YAML schemas for the generic NAND options")
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Thanks for fixing it,
Miquèl
^ permalink raw reply
* Re: [PATCH 07/10] mfd: madera: point to the right pinctrl binding file
From: Charles Keepax @ 2019-05-20 15:42 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Richard Fitzgerald, Lee Jones, alsa-devel,
patches
In-Reply-To: <fb47879d405e624374d7d4e099988296ed2af668.1558362030.git.mchehab+samsung@kernel.org>
On Mon, May 20, 2019 at 11:47:36AM -0300, Mauro Carvalho Chehab wrote:
> The reference to Documentation/pinctrl.txt doesn't exist, but
> there is an specific binding for the madera driver.
>
> So, point to it.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> include/linux/mfd/madera/pdata.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/mfd/madera/pdata.h b/include/linux/mfd/madera/pdata.h
> index 8dc852402dbb..c7e0658eb74b 100644
> --- a/include/linux/mfd/madera/pdata.h
> +++ b/include/linux/mfd/madera/pdata.h
> @@ -34,7 +34,8 @@ struct madera_codec_pdata;
> * @micvdd: Substruct of pdata for the MICVDD regulator
> * @irq_flags: Mode for primary IRQ (defaults to active low)
> * @gpio_base: Base GPIO number
> - * @gpio_configs: Array of GPIO configurations (See Documentation/pinctrl.txt)
> + * @gpio_configs: Array of GPIO configurations
> + * (See Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt)
I believe this is trying to point at the generic pinctrl docs
which now live here:
Documentation/driver-api/pinctl.rst
There is a patch to do this already:
https://lkml.org/lkml/2019/1/9/853
With the latest resend here:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2001752.html
Thanks,
Charles
> * @n_gpio_configs: Number of entries in gpio_configs
> * @gpsw: General purpose switch mode setting. Depends on the external
> * hardware connected to the switch. (See the SW1_MODE field
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH 08/10] dt: fix refs that were renamed to json with the same file name
From: Rob Herring @ 2019-05-20 15:57 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel@vger.kernel.org, Jonathan Corbet, Mark Rutland,
Michael Turquette, Stephen Boyd, Thomas Gleixner, Jason Cooper,
Marc Zyngier, Jacek Anaszewski, Pavel Machek, Dan Murphy,
David S. Miller, Greg Kroah-Hartman, Linus Walleij, Nicolas Ferre,
Paul E. McKenney, devicetree, linux-clk, Linux LED Subsystem
In-Reply-To: <66231286de0f11b45075292216a939858de8c3e5.1558362030.git.mchehab+samsung@kernel.org>
On Mon, May 20, 2019 at 9:48 AM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> This file was converted to json, but the references weren't
Technically, converted to json-schema (the language) or yaml (the format).
> renamed.
>
> Fixes: 66ed144f147a ("dt-bindings: interrupt-controller: Convert ARM GIC to json-schema")
> (and other similar commits)
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/devicetree/bindings/arm/omap/crossbar.txt | 2 +-
> .../devicetree/bindings/clock/samsung,s5pv210-clock.txt | 2 +-
> .../bindings/interrupt-controller/marvell,odmi-controller.txt | 2 +-
> Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt | 2 +-
> MAINTAINERS | 4 ++--
> 5 files changed, 6 insertions(+), 6 deletions(-)
FYI, I'm actively looking for this in conversions now as we've had a
few of these. For cases where we have a lot of references, I'm fixing
this by keeping the .txt file with a reference to the .yaml file.
I'll pick up the DT patches in the series.
Rob
^ permalink raw reply
* Re: [PATCH 08/10] dt: fix refs that were renamed to json with the same file name
From: Mauro Carvalho Chehab @ 2019-05-20 16:13 UTC (permalink / raw)
To: Rob Herring
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel@vger.kernel.org, Jonathan Corbet, Mark Rutland,
Michael Turquette, Stephen Boyd, Thomas Gleixner, Jason Cooper,
Marc Zyngier, Jacek Anaszewski, Pavel Machek, Dan Murphy,
David S. Miller, Greg Kroah-Hartman, Linus Walleij, Nicolas Ferre,
Paul E. McKenney, devicetree, linux-clk, Linux LED Subsystem
In-Reply-To: <CAL_JsqKGzNBjxhvY2Vq9v8SXiND+7sjmsOwKkeu+gEM=2Y-n_A@mail.gmail.com>
Em Mon, 20 May 2019 10:57:47 -0500
Rob Herring <robh+dt@kernel.org> escreveu:
> On Mon, May 20, 2019 at 9:48 AM Mauro Carvalho Chehab
> <mchehab+samsung@kernel.org> wrote:
> >
> > This file was converted to json, but the references weren't
>
> Technically, converted to json-schema (the language) or yaml (the format).
Ok. Do you want me to change it at the patch and resend?
>
> > renamed.
> >
> > Fixes: 66ed144f147a ("dt-bindings: interrupt-controller: Convert ARM GIC to json-schema")
> > (and other similar commits)
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> > Documentation/devicetree/bindings/arm/omap/crossbar.txt | 2 +-
> > .../devicetree/bindings/clock/samsung,s5pv210-clock.txt | 2 +-
> > .../bindings/interrupt-controller/marvell,odmi-controller.txt | 2 +-
> > Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt | 2 +-
> > MAINTAINERS | 4 ++--
> > 5 files changed, 6 insertions(+), 6 deletions(-)
>
> FYI, I'm actively looking for this in conversions now as we've had a
> few of these. For cases where we have a lot of references, I'm fixing
> this by keeping the .txt file with a reference to the .yaml file.
If the file name remains with the same name, except for the .txt -> .yaml,
you can just run the "scripts/documentation-file-ref-check --fix"
after this patch:
Subject: [PATCH 04/10] scripts/documentation-file-ref-check: teach about .txt -> .yaml renames
and it should detect and automatically fix all the references. As any
auto-hint script, you need to double-check the results.
> I'll pick up the DT patches in the series.
OK. There are a few such fixes inside patch 10/10. Do you want me
to split it or can it go through Jonathan's doc tree?
Thanks,
Mauro
^ permalink raw reply
* Re: [TRIVIA] Re: [PATCH] docs: Move kref.txt to core-api/kref.rst
From: Jonathan Corbet @ 2019-05-20 18:23 UTC (permalink / raw)
To: Tobin C. Harding
Cc: Thomas Hellstrom, linux-kernel@vger.kernel.org, minyard@acm.org,
linux-doc@vger.kernel.org, Tobin C. Harding
In-Reply-To: <20190516231949.GA5056@eros.localdomain>
On Fri, 17 May 2019 09:19:49 +1000
"Tobin C. Harding" <me@tobin.cc> wrote:
> I was just going through my editors init file and I see I have default
> column width for kernel RST files set to 75. Did you tell me that some
> time Jon, I vaguely remember?
Don't think it was me, but who knows what I might have said way back
when... 75 doesn't seem outlandish, anyway.
jon
^ permalink raw reply
* Re: [PATCH 07/10] mfd: madera: point to the right pinctrl binding file
From: Mauro Carvalho Chehab @ 2019-05-20 18:48 UTC (permalink / raw)
To: Charles Keepax
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Richard Fitzgerald, Lee Jones, alsa-devel,
patches
In-Reply-To: <20190520154244.GA99937@ediswmail.ad.cirrus.com>
Em Mon, 20 May 2019 16:42:45 +0100
Charles Keepax <ckeepax@opensource.cirrus.com> escreveu:
> On Mon, May 20, 2019 at 11:47:36AM -0300, Mauro Carvalho Chehab wrote:
> > The reference to Documentation/pinctrl.txt doesn't exist, but
> > there is an specific binding for the madera driver.
> >
> > So, point to it.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> > include/linux/mfd/madera/pdata.h | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/mfd/madera/pdata.h b/include/linux/mfd/madera/pdata.h
> > index 8dc852402dbb..c7e0658eb74b 100644
> > --- a/include/linux/mfd/madera/pdata.h
> > +++ b/include/linux/mfd/madera/pdata.h
> > @@ -34,7 +34,8 @@ struct madera_codec_pdata;
> > * @micvdd: Substruct of pdata for the MICVDD regulator
> > * @irq_flags: Mode for primary IRQ (defaults to active low)
> > * @gpio_base: Base GPIO number
> > - * @gpio_configs: Array of GPIO configurations (See Documentation/pinctrl.txt)
> > + * @gpio_configs: Array of GPIO configurations
> > + * (See Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt)
>
> I believe this is trying to point at the generic pinctrl docs
> which now live here:
>
> Documentation/driver-api/pinctl.rst
>
> There is a patch to do this already:
> https://lkml.org/lkml/2019/1/9/853
> With the latest resend here:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2001752.html
Ah, makes sense to me.
Please ignore this one.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH -next] counter: fix Documentation build error due to incorrect source file name
From: Jonathan Corbet @ 2019-05-20 19:20 UTC (permalink / raw)
To: Randy Dunlap
Cc: LKML, William Breathitt Gray, linux-iio,
linux-doc@vger.kernel.org
In-Reply-To: <b6475070-f336-1093-ff0f-6bc8d5fda35e@infradead.org>
On Sat, 18 May 2019 21:29:58 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix kernel-doc build error in Documentation/driver-api/generic-counter.rst
> of incorrect source file name.
> Fixes this warning and error:
>
> Error: Cannot open file ../drivers/counter/generic-counter.c
> WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno -export ../drivers/counter/generic-counter.c' failed with return code 2
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: William Breathitt Gray <vilhelm.gray@gmail.com>
> Cc: linux-iio@vger.kernel.org
> ---
> Documentation/driver-api/generic-counter.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-next-20190517.orig/Documentation/driver-api/generic-counter.rst
> +++ linux-next-20190517/Documentation/driver-api/generic-counter.rst
> @@ -251,7 +251,7 @@ for defining a counter device.
> .. kernel-doc:: include/linux/counter.h
> :internal:
>
> -.. kernel-doc:: drivers/counter/generic-counter.c
> +.. kernel-doc:: drivers/counter/counter.c
> :export:
>
> Implementation
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] Documentation: kdump: fix minor typo
From: Jonathan Corbet @ 2019-05-20 19:27 UTC (permalink / raw)
To: Cengiz Can; +Cc: kexec, linux-doc, linux-kernel
In-Reply-To: <20190514161724.16604-1-cengizc@gmail.com>
On Tue, 14 May 2019 19:17:25 +0300
Cengiz Can <cengizc@gmail.com> wrote:
> kdump.txt had a minor typo.
>
> Signed-off-by: Cengiz Can <cengizc@gmail.com>
> ---
> Documentation/kdump/kdump.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index 51814450a7f8..3162eeb8c262 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -410,7 +410,7 @@ Notes on loading the dump-capture kernel:
> * Boot parameter "1" boots the dump-capture kernel into single-user
> mode without networking. If you want networking, use "3".
>
> -* We generally don' have to bring up a SMP kernel just to capture the
> +* We generally don't have to bring up a SMP kernel just to capture the
Applied, thanks.
jon
^ permalink raw reply
* Print your logo
From: Heather @ 2019-05-20 15:02 UTC (permalink / raw)
To: linux-doc
Hi,
I didn’t know if you had received my email from last week?
We manufacture ALL custom LOGO and branded products – over 300,000 to
choose from.
The most asked about product that we make, is the custom printed USB flash
drives!
We can print your logo on them and load your digital images, videos and
files!
Here is what we include:
-Any size memory you need: 64MB up to 128GB
-We will print your logo on both sides, just ask!
-Very Low Order Minimums
-Need them quickly? Not a problem, we offer Rush Service
Email over a copy of your logo and we will create a design mock up for you
at no cost!
Our higher memory sizes are a really good option right now!
Pricing is low right now, so let us know what you need and we will get you
a quick quote.
We always offer great rates for schools and nonprofits as well.
Let us know what you would like quoted?
Regards,
Heather Millons
Custom USB Account Manager
^ permalink raw reply
* [PATCH] Documentation/x86: Fix path to entry_32.S
From: ira.weiny @ 2019-05-20 20:52 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: x86, linux-kernel, linux-doc, Ira Weiny
From: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
---
Documentation/x86/exception-tables.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/x86/exception-tables.txt b/Documentation/x86/exception-tables.txt
index e396bcd8d830..001c0f1ad935 100644
--- a/Documentation/x86/exception-tables.txt
+++ b/Documentation/x86/exception-tables.txt
@@ -30,7 +30,7 @@ page fault handler
void do_page_fault(struct pt_regs *regs, unsigned long error_code)
in arch/x86/mm/fault.c. The parameters on the stack are set up by
-the low level assembly glue in arch/x86/kernel/entry_32.S. The parameter
+the low level assembly glue in arch/x86/entry/entry_32.S. The parameter
regs is a pointer to the saved registers on the stack, error_code
contains a reason code for the exception.
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 1/4] evm: check hash algorithm passed to init_desc()
From: Mimi Zohar @ 2019-05-20 21:19 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-doc, linux-security-module, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <20190516161257.6640-1-roberto.sassu@huawei.com>
On Thu, 2019-05-16 at 18:12 +0200, Roberto Sassu wrote:
> This patch prevents memory access beyond the evm_tfm array by checking the
> validity of the index (hash algorithm) passed to init_desc(). The hash
> algorithm can be arbitrarily set if the security.ima xattr type is not
> EVM_XATTR_HMAC.
>
> Fixes: 5feeb61183dde ("evm: Allow non-SHA1 digital signatures")
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> Cc: stable@vger.kernel.org
Thanks!
> ---
> security/integrity/evm/evm_crypto.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> index e11564eb645b..82a38e801ee4 100644
> --- a/security/integrity/evm/evm_crypto.c
> +++ b/security/integrity/evm/evm_crypto.c
> @@ -89,6 +89,9 @@ static struct shash_desc *init_desc(char type, uint8_t hash_algo)
> tfm = &hmac_tfm;
> algo = evm_hmac;
> } else {
> + if (hash_algo >= HASH_ALGO__LAST)
> + return ERR_PTR(-EINVAL);
> +
> tfm = &evm_tfm[hash_algo];
> algo = hash_algo_name[hash_algo];
> }
^ permalink raw reply
* Re: [PATCH 2/4] evm: reset status in evm_inode_post_setattr()
From: Mimi Zohar @ 2019-05-20 21:19 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-doc, linux-security-module, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <20190516161257.6640-2-roberto.sassu@huawei.com>
On Thu, 2019-05-16 at 18:12 +0200, Roberto Sassu wrote:
> This patch adds a call to evm_reset_status() in evm_inode_post_setattr(),
> before security.evm is updated. The same is done in the other
> evm_inode_post_* functions.
>
> Fixes: 523b74b16bcbb ("evm: reset EVM status when file attributes change")
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> Cc: stable@vger.kernel.org
Why all of a sudden do we also need to clear the EVM cached status
when modifying the file attributes? The HMAC is being recalculated.
If the reason is because of EVM portable and immutable signatures,
then the "Fixes" tag is incorrect.
Mimi
> ---
> security/integrity/evm/evm_main.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/security/integrity/evm/evm_main.c b/security/integrity/evm/evm_main.c
> index b6d9f14bc234..b41c2d8a8834 100644
> --- a/security/integrity/evm/evm_main.c
> +++ b/security/integrity/evm/evm_main.c
> @@ -512,8 +512,11 @@ void evm_inode_post_setattr(struct dentry *dentry, int ia_valid)
> if (!evm_key_loaded())
> return;
>
> - if (ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID))
> + if (ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID)) {
> + evm_reset_status(dentry->d_inode);
> +
> evm_update_evmxattr(dentry, NULL, NULL, 0);
> + }
> }
>
> /*
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox