* Re: [PATCH] docs: packing: move it to core-api book and adjust markups
From: Vladimir Oltean @ 2019-07-04 23:59 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, lkml,
Jonathan Corbet, Mike Rapoport, Andrew Morton, Randy Dunlap,
Matthew Wilcox, Kent Overstreet, Arnd Bergmann,
Jonathan Neuschäfer, David S. Miller, netdev
In-Reply-To: <46cb79dbc4bbff3e5a4e77b548df1e92c105ed0f.1561804613.git.mchehab+samsung@kernel.org>
On Sat, 29 Jun 2019 at 13:37, Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> The packing.txt file was misplaced, as docs should be part of
> a documentation book, and not at the root dir.
>
> So, move it to the core-api directory and add to its index.
>
> Also, ensure that the file will be properly parsed and the bitmap
> ascii artwork will use a monotonic font.
>
> Fixes: 554aae35007e ("lib: Add support for generic packing operations")
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Tested-by: Vladimir Oltean <olteanv@gmail.com>
> ---
> Documentation/core-api/index.rst | 1 +
> .../{packing.txt => core-api/packing.rst} | 81 +++++++++++--------
> 2 files changed, 50 insertions(+), 32 deletions(-)
> rename Documentation/{packing.txt => core-api/packing.rst} (61%)
>
> diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
> index d1e5b95bf86d..aebb16d7771f 100644
> --- a/Documentation/core-api/index.rst
> +++ b/Documentation/core-api/index.rst
> @@ -25,6 +25,7 @@ Core utilities
> librs
> genalloc
> errseq
> + packing
> printk-formats
> circular-buffers
> generic-radix-tree
> diff --git a/Documentation/packing.txt b/Documentation/core-api/packing.rst
> similarity index 61%
> rename from Documentation/packing.txt
> rename to Documentation/core-api/packing.rst
> index f830c98645f1..d8c341fe383e 100644
> --- a/Documentation/packing.txt
> +++ b/Documentation/core-api/packing.rst
> @@ -30,6 +30,7 @@ The solution
> ------------
>
> This API deals with 2 basic operations:
> +
> - Packing a CPU-usable number into a memory buffer (with hardware
> constraints/quirks)
> - Unpacking a memory buffer (which has hardware constraints/quirks)
> @@ -49,10 +50,12 @@ What the examples show is where the logical bytes and bits sit.
>
> 1. Normally (no quirks), we would do it like this:
>
> -63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
> -7 6 5 4
> -31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
> -3 2 1 0
> +::
> +
> + 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
> + 7 6 5 4
> + 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
> + 3 2 1 0
>
> That is, the MSByte (7) of the CPU-usable u64 sits at memory offset 0, and the
> LSByte (0) of the u64 sits at memory offset 7.
> @@ -63,10 +66,12 @@ comments as "logical" notation.
>
> 2. If QUIRK_MSB_ON_THE_RIGHT is set, we do it like this:
>
> -56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39
> -7 6 5 4
> -24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7
> -3 2 1 0
> +::
If this is not too stylistically different from the rest of the kernel
docs, the RST syntax actually allows you to do "we do it like this::"
(with the two colons coming right after the text and not on their own
line, which looks more natural). The same comment applies to the other
changes below.
> +
> + 56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39
> + 7 6 5 4
> + 24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7
> + 3 2 1 0
>
> That is, QUIRK_MSB_ON_THE_RIGHT does not affect byte positioning, but
> inverts bit offsets inside a byte.
> @@ -74,10 +79,12 @@ inverts bit offsets inside a byte.
>
> 3. If QUIRK_LITTLE_ENDIAN is set, we do it like this:
>
> -39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56
> -4 5 6 7
> -7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
> -0 1 2 3
> +::
> +
> + 39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56
> + 4 5 6 7
> + 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
> + 0 1 2 3
>
> Therefore, QUIRK_LITTLE_ENDIAN means that inside the memory region, every
> byte from each 4-byte word is placed at its mirrored position compared to
> @@ -86,18 +93,22 @@ the boundary of that word.
> 4. If QUIRK_MSB_ON_THE_RIGHT and QUIRK_LITTLE_ENDIAN are both set, we do it
> like this:
>
> -32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
> -4 5 6 7
> -0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
> -0 1 2 3
> +::
> +
> + 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
> + 4 5 6 7
> + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
> + 0 1 2 3
>
>
> 5. If just QUIRK_LSW32_IS_FIRST is set, we do it like this:
>
> -31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
> -3 2 1 0
> -63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
> -7 6 5 4
> +::
> +
> + 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
> + 3 2 1 0
> + 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
> + 7 6 5 4
>
> In this case the 8 byte memory region is interpreted as follows: first
> 4 bytes correspond to the least significant 4-byte word, next 4 bytes to
> @@ -107,28 +118,34 @@ the more significant 4-byte word.
> 6. If QUIRK_LSW32_IS_FIRST and QUIRK_MSB_ON_THE_RIGHT are set, we do it like
> this:
>
> -24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7
> -3 2 1 0
> -56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39
> -7 6 5 4
> +::
> +
> + 24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7
> + 3 2 1 0
> + 56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39
> + 7 6 5 4
>
>
> 7. If QUIRK_LSW32_IS_FIRST and QUIRK_LITTLE_ENDIAN are set, it looks like
> this:
>
> -7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
> -0 1 2 3
> -39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56
> -4 5 6 7
> +::
> +
> + 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
> + 0 1 2 3
> + 39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56
> + 4 5 6 7
>
>
> 8. If QUIRK_LSW32_IS_FIRST, QUIRK_LITTLE_ENDIAN and QUIRK_MSB_ON_THE_RIGHT
> are set, it looks like this:
>
> -0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
> -0 1 2 3
> -32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
> -4 5 6 7
> +::
> +
> + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
> + 0 1 2 3
> + 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
> + 4 5 6 7
>
>
> We always think of our offsets as if there were no quirk, and we translate
> --
> 2.21.0
>
^ permalink raw reply
* [RFC PATCH] string.h: Add stracpy/stracpy_pad (was: Re: [PATCH] checkpatch: Added warnings in favor of strscpy().)
From: Joe Perches @ 2019-07-05 0:15 UTC (permalink / raw)
To: Nitin Gote, akpm
Cc: corbet, apw, keescook, linux-doc, linux-kernel, kernel-hardening
In-Reply-To: <f6a4c2b601bb59179cb2e3b8f4d836a1c11379a3.camel@perches.com>
On Thu, 2019-07-04 at 13:46 -0700, Joe Perches wrote:
> On Thu, 2019-07-04 at 11:24 +0530, Nitin Gote wrote:
> > Added warnings in checkpatch.pl script to :
> >
> > 1. Deprecate strcpy() in favor of strscpy().
> > 2. Deprecate strlcpy() in favor of strscpy().
> > 3. Deprecate strncpy() in favor of strscpy() or strscpy_pad().
> >
> > Updated strncpy() section in Documentation/process/deprecated.rst
> > to cover strscpy_pad() case.
[]
I sent a patch series for some strscpy/strlcpy misuses.
How about adding a macro helper to avoid the misuses like:
---
include/linux/string.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/include/linux/string.h b/include/linux/string.h
index 4deb11f7976b..ef01bd6f19df 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -35,6 +35,22 @@ ssize_t strscpy(char *, const char *, size_t);
/* Wraps calls to strscpy()/memset(), no arch specific code required */
ssize_t strscpy_pad(char *dest, const char *src, size_t count);
+#define stracpy(to, from) \
+({ \
+ size_t size = ARRAY_SIZE(to); \
+ BUILD_BUG_ON(!__same_type(typeof(*to), char)); \
+ \
+ strscpy(to, from, size); \
+})
+
+#define stracpy_pad(to, from) \
+({ \
+ size_t size = ARRAY_SIZE(to); \
+ BUILD_BUG_ON(!__same_type(typeof(*to), char)); \
+ \
+ strscpy_pad(to, from, size); \
+})
+
#ifndef __HAVE_ARCH_STRCAT
extern char * strcat(char *, const char *);
#endif
^ permalink raw reply related
* RE: [PATCH v7 1/2] fTPM: firmware TPM running in TEE
From: Thirupathaiah Annapureddy @ 2019-07-05 2:40 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Jarkko Sakkinen, Sasha Levin, peterhuewe@gmx.de, jgg@ziepe.ca,
corbet@lwn.net, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-integrity@vger.kernel.org,
Microsoft Linux Kernel List, Bryan Kelly (CSI),
tee-dev@lists.linaro.org, sumit.garg@linaro.org,
rdunlap@infradead.org, Joakim Bech
In-Reply-To: <20190704181120.GA21445@apalos>
> -----Original Message-----
> From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Sent: Thursday, July 4, 2019 11:11 AM
> To: Thirupathaiah Annapureddy <thiruan@microsoft.com>
> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; Sasha Levin
> <sashal@kernel.org>; peterhuewe@gmx.de; jgg@ziepe.ca; corbet@lwn.net; linux-
> kernel@vger.kernel.org; linux-doc@vger.kernel.org; linux-
> integrity@vger.kernel.org; Microsoft Linux Kernel List <linux-
> kernel@microsoft.com>; Bryan Kelly (CSI) <bryankel@microsoft.com>; tee-
> dev@lists.linaro.org; sumit.garg@linaro.org; rdunlap@infradead.org; Joakim Bech
> <joakim.bech@linaro.org>
> Subject: Re: [PATCH v7 1/2] fTPM: firmware TPM running in TEE
>
> Hi Thirupathaiah,
> [...]
> > > > > > I managed to do some quick testing in QEMU.
> > > > > > Everything works fine when i build this as a module (using IBM's TPM
> 2.0
> > > > > > TSS)
> > > > > >
> > > > > > - As module
> > > > > > # insmod /lib/modules/5.2.0-
> rc1/kernel/drivers/char/tpm/tpm_ftpm_tee.ko
> > > > > > # getrandom -by 8
> > > > > > randomBytes length 8
> > > > > > 23 b9 3d c3 90 13 d9 6b
> > > > > >
> > > > > > - Built-in
> > > > > > # dmesg | grep optee
> > > > > > ftpm-tee firmware:optee: ftpm_tee_probe:tee_client_open_session
> failed,
> > > > > > err=ffff0008
> > > > > This (0xffff0008) translates to TEE_ERROR_ITEM_NOT_FOUND.
> > > > >
> > > > > Where is fTPM TA located in the your test setup?
> > > > > Is it stitched into TEE binary as an EARLY_TA or
> > > > > Is it expected to be loaded during run-time with the help of user mode
> OP-
> > > TEE supplicant?
> > > > >
> > > > > My guess is that you are trying to load fTPM TA through user mode OP-
> TEE
> > > supplicant.
> > > > > Can you confirm?
> > > > I tried both
> > > >
> > >
> > > Ok apparently there was a failure with my built-in binary which i
> > > didn't notice. I did a full rebuilt and checked the elf this time :)
> > >
> > > Built as an earlyTA my error now is:
> > > ftpm-tee firmware:optee: ftpm_tee_probe:tee_client_open_session
> > > failed, err=ffff3024 (translates to TEE_ERROR_TARGET_DEAD)
> > > Since you tested it on real hardware i guess you tried both
> > > module/built-in. Which TEE version are you using?
> >
> > I am glad that the first issue (TEE_ERROR_ITEM_NOT_FOUND) is resolved after
> stitching
> > fTPM TA as an EARLY_TA.
> >
> > Regarding TEE_ERROR_TARGET_DEAD error, may I know which HW platform you are
> using to test?
>
> QEMU, on armv7
>
> > What is the preboot environment (UEFI or U-boot)?
> > Where is the secure storage in that HW platform?
> > I could think of two classes of secure storage.
> > 1. UFS/eMMC RPMB : If Supplicant in U-boot/UEFI initializes the
> > fTPM TA NV Storage, there should be no issue.
> > If fTPM TA NV storage is not initialized in pre-boot environment and you are
> using
> > built-in fTPM Linux driver, you can run into this issue as TA will try to
> initialize
> > NV store and fail.
> >
> > 2. other storage devices like QSPI accessible to only secure mode after
> > EBS/ReadyToBoot mile posts during boot. In this case, there should be no
> issue at all
> > as there is no dependency on non-secure side services provided by supplicant.
> >
>
> Please check the previous mail from Sumit. It explains exaclty what's going on.
> The tl;dr version is that the storage is up only when the supplicant is
> running.
I definitely know that OP-TEE can access storage only when the "user mode" supplicant
is running :). But fTPM NV storage should have been initialized in
in the preboot environment (UEFI/U-boot).
It would also be helpful to understand the overall use case/scenario (Measured boot?)you
are trying to exercise with the fTPM.
I also want to emphasize that this discussion is turning into more of how
fTPM gets integrated/enabled in a new HW platform.
fTPM is hosted in github and you definitely bring any issues/feature requests there.
>
> > If you let me know the HW platform details, I am happy to work with you to
> enable/integrate
> > fTPM TA on that HW platform.
> >
> Thanks,
> The hardware i am waiting for for has an eMMC RPMB. In theory the U-Boot
> supplicant support will be there so i'll be able to test it.
Can you give me the details of HW so that I can order one for myself?
Is it one of the 96boards?
The reason for the ask is that we have not upstreamd u-boot fTPM stack yet,
although we have future plans for it.
--Thiru
^ permalink raw reply
* Re: [PATCH 18/39] docs: admin-guide: add kdump documentation into it
From: Alex Shi @ 2019-07-05 3:43 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet, Dave Young,
Baoquan He, Vivek Goyal, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Harry Wei, Jerry Hoemann, Wim Van Sebroeck,
Guenter Roeck, Russell King, Catalin Marinas, Will Deacon,
Yoshinori Sato, Rich Felker, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, x86, kexec, linuxppc-dev,
linux-watchdog, linux-arm-kernel, linux-sh
In-Reply-To: <654e7591c044632c06257e0f069a52c0bb993554.1561724493.git.mchehab+samsung@kernel.org>
在 2019/6/28 下午8:30, Mauro Carvalho Chehab 写道:
> The Kdump documentation describes procedures with admins use
> in order to solve issues on their systems.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/admin-guide/bug-hunting.rst | 4 ++--
> Documentation/admin-guide/index.rst | 1 +
> Documentation/{ => admin-guide}/kdump/gdbmacros.txt | 0
> Documentation/{ => admin-guide}/kdump/index.rst | 1 -
> Documentation/{ => admin-guide}/kdump/kdump.rst | 0
> Documentation/{ => admin-guide}/kdump/vmcoreinfo.rst | 0
I am not sure if it's convenience for people to have more levels in docs.
But I guess, move archs into a Documentation/arch/ dir should be fine. like Documentation/arch/{x86,arm,arm64,ia64,m68k,s390,powerpc,...}
Thanks
Alex
^ permalink raw reply
* Re: [PATCH 18/39] docs: admin-guide: add kdump documentation into it
From: Dave Young @ 2019-07-05 5:55 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Baoquan He, Vivek Goyal, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Harry Wei, Alex Shi,
Jerry Hoemann, Wim Van Sebroeck, Guenter Roeck, Russell King,
Catalin Marinas, Will Deacon, Yoshinori Sato, Rich Felker,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
x86, kexec, linuxppc-dev, linux-watchdog, linux-arm-kernel,
linux-sh
In-Reply-To: <654e7591c044632c06257e0f069a52c0bb993554.1561724493.git.mchehab+samsung@kernel.org>
On 06/28/19 at 09:30am, Mauro Carvalho Chehab wrote:
> The Kdump documentation describes procedures with admins use
> in order to solve issues on their systems.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/admin-guide/bug-hunting.rst | 4 ++--
> Documentation/admin-guide/index.rst | 1 +
> Documentation/{ => admin-guide}/kdump/gdbmacros.txt | 0
> Documentation/{ => admin-guide}/kdump/index.rst | 1 -
> Documentation/{ => admin-guide}/kdump/kdump.rst | 0
> Documentation/{ => admin-guide}/kdump/vmcoreinfo.rst | 0
> Documentation/admin-guide/kernel-parameters.txt | 6 +++---
> Documentation/powerpc/firmware-assisted-dump.rst | 2 +-
> Documentation/translations/zh_CN/oops-tracing.txt | 4 ++--
> Documentation/watchdog/hpwdt.rst | 2 +-
> MAINTAINERS | 2 +-
> arch/arm/Kconfig | 2 +-
> arch/arm64/Kconfig | 2 +-
> arch/sh/Kconfig | 2 +-
> arch/x86/Kconfig | 4 ++--
> 15 files changed, 16 insertions(+), 16 deletions(-)
> rename Documentation/{ => admin-guide}/kdump/gdbmacros.txt (100%)
> rename Documentation/{ => admin-guide}/kdump/index.rst (97%)
> rename Documentation/{ => admin-guide}/kdump/kdump.rst (100%)
> rename Documentation/{ => admin-guide}/kdump/vmcoreinfo.rst (100%)
>
> diff --git a/Documentation/admin-guide/bug-hunting.rst b/Documentation/admin-guide/bug-hunting.rst
> index b761aa2a51d2..44b8a4edd348 100644
> --- a/Documentation/admin-guide/bug-hunting.rst
> +++ b/Documentation/admin-guide/bug-hunting.rst
> @@ -90,9 +90,9 @@ the disk is not available then you have three options:
> run a null modem to a second machine and capture the output there
> using your favourite communication program. Minicom works well.
>
> -(3) Use Kdump (see Documentation/kdump/kdump.rst),
> +(3) Use Kdump (see Documentation/admin-guide/kdump/kdump.rst),
> extract the kernel ring buffer from old memory with using dmesg
> - gdbmacro in Documentation/kdump/gdbmacros.txt.
> + gdbmacro in Documentation/admin-guide/kdump/gdbmacros.txt.
>
> Finding the bug's location
> --------------------------
> diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
> index 9899b78dbe50..65e821a03aca 100644
> --- a/Documentation/admin-guide/index.rst
> +++ b/Documentation/admin-guide/index.rst
> @@ -39,6 +39,7 @@ problems and bugs in particular.
> ramoops
> dynamic-debug-howto
> init
> + kdump/index
> perf/index
>
> This is the beginning of a section with information of interest to
> diff --git a/Documentation/kdump/gdbmacros.txt b/Documentation/admin-guide/kdump/gdbmacros.txt
> similarity index 100%
> rename from Documentation/kdump/gdbmacros.txt
> rename to Documentation/admin-guide/kdump/gdbmacros.txt
> diff --git a/Documentation/kdump/index.rst b/Documentation/admin-guide/kdump/index.rst
> similarity index 97%
> rename from Documentation/kdump/index.rst
> rename to Documentation/admin-guide/kdump/index.rst
> index 2b17fcf6867a..8e2ebd0383cd 100644
> --- a/Documentation/kdump/index.rst
> +++ b/Documentation/admin-guide/kdump/index.rst
> @@ -1,4 +1,3 @@
> -:orphan:
>
> ================================================================
> Documentation for Kdump - The kexec-based Crash Dumping Solution
> diff --git a/Documentation/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst
> similarity index 100%
> rename from Documentation/kdump/kdump.rst
> rename to Documentation/admin-guide/kdump/kdump.rst
> diff --git a/Documentation/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
> similarity index 100%
> rename from Documentation/kdump/vmcoreinfo.rst
> rename to Documentation/admin-guide/kdump/vmcoreinfo.rst
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index e38b96d061f4..9b535c0e22f3 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -708,14 +708,14 @@
> [KNL, x86_64] select a region under 4G first, and
> fall back to reserve region above 4G when '@offset'
> hasn't been specified.
> - See Documentation/kdump/kdump.rst for further details.
> + See Documentation/admin-guide/kdump/kdump.rst for further details.
>
> crashkernel=range1:size1[,range2:size2,...][@offset]
> [KNL] Same as above, but depends on the memory
> in the running system. The syntax of range is
> start-[end] where start and end are both
> a memory unit (amount[KMG]). See also
> - Documentation/kdump/kdump.rst for an example.
> + Documentation/admin-guide/kdump/kdump.rst for an example.
>
> crashkernel=size[KMG],high
> [KNL, x86_64] range could be above 4G. Allow kernel
> @@ -1207,7 +1207,7 @@
> Specifies physical address of start of kernel core
> image elf header and optionally the size. Generally
> kexec loader will pass this option to capture kernel.
> - See Documentation/kdump/kdump.rst for details.
> + See Documentation/admin-guide/kdump/kdump.rst for details.
>
> enable_mtrr_cleanup [X86]
> The kernel tries to adjust MTRR layout from continuous
> diff --git a/Documentation/powerpc/firmware-assisted-dump.rst b/Documentation/powerpc/firmware-assisted-dump.rst
> index d7fa7c35dd12..9ca12830a48e 100644
> --- a/Documentation/powerpc/firmware-assisted-dump.rst
> +++ b/Documentation/powerpc/firmware-assisted-dump.rst
> @@ -61,7 +61,7 @@ as follows:
> the default calculated size. Use this option if default
> boot memory size is not sufficient for second kernel to
> boot successfully. For syntax of crashkernel= parameter,
> - refer to Documentation/kdump/kdump.rst. If any offset is
> + refer to Documentation/admin-guide/kdump/kdump.rst. If any offset is
> provided in crashkernel= parameter, it will be ignored
> as fadump uses a predefined offset to reserve memory
> for boot memory dump preservation in case of a crash.
> diff --git a/Documentation/translations/zh_CN/oops-tracing.txt b/Documentation/translations/zh_CN/oops-tracing.txt
> index 368ddd05b304..c5f3bda7abcb 100644
> --- a/Documentation/translations/zh_CN/oops-tracing.txt
> +++ b/Documentation/translations/zh_CN/oops-tracing.txt
> @@ -53,8 +53,8 @@ cat /proc/kmsg > file， 然而你必须介入中止传输， kmsg是一个“
> （2）用串口终端启动（请参看Documentation/admin-guide/serial-console.rst），运行一个null
> modem到另一台机器并用你喜欢的通讯工具获取输出。Minicom工作地很好。
>
> -（3）使用Kdump（请参看Documentation/kdump/kdump.rst），
> -使用在Documentation/kdump/gdbmacros.txt中定义的dmesg gdb宏，从旧的内存中提取内核
> +（3）使用Kdump（请参看Documentation/admin-guide/kdump/kdump.rst），
> +使用在Documentation/admin-guide/kdump/gdbmacros.txt中定义的dmesg gdb宏，从旧的内存中提取内核
> 环形缓冲区。
>
> 完整信息
> diff --git a/Documentation/watchdog/hpwdt.rst b/Documentation/watchdog/hpwdt.rst
> index 94a96371113e..49c647dba8aa 100644
> --- a/Documentation/watchdog/hpwdt.rst
> +++ b/Documentation/watchdog/hpwdt.rst
> @@ -59,7 +59,7 @@ Last reviewed: 08/20/2018
> and loop forever. This is generally not what a watchdog user wants.
>
> For those wishing to learn more please see:
> - Documentation/kdump/kdump.rst
> + Documentation/admin-guide/kdump/kdump.rst
> Documentation/admin-guide/kernel-parameters.txt (panic=)
> Your Linux Distribution specific documentation.
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d35ff73f718a..4c622a19ab7d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8622,7 +8622,7 @@ R: Vivek Goyal <vgoyal@redhat.com>
> L: kexec@lists.infradead.org
> W: http://lse.sourceforge.net/kdump/
> S: Maintained
> -F: Documentation/kdump/
> +F: Documentation/admin-guide/kdump/
>
> KEENE FM RADIO TRANSMITTER DRIVER
> M: Hans Verkuil <hverkuil@xs4all.nl>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 8bf8985ec667..d5bd4350fcbd 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -2025,7 +2025,7 @@ config CRASH_DUMP
> kdump/kexec. The crash dump kernel must be compiled to a
> memory address not used by the main kernel
>
> - For more details see Documentation/kdump/kdump.rst
> + For more details see Documentation/admin-guide/kdump/kdump.rst
>
> config AUTO_ZRELADDR
> bool "Auto calculation of the decompressed kernel image address"
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index accb045997c6..e1ea69994e0f 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -997,7 +997,7 @@ config CRASH_DUMP
> reserved region and then later executed after a crash by
> kdump/kexec.
>
> - For more details see Documentation/kdump/kdump.rst
> + For more details see Documentation/admin-guide/kdump/kdump.rst
>
> config XEN_DOM0
> def_bool y
> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index 31a7d12db705..c2858ac6a46a 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -626,7 +626,7 @@ config CRASH_DUMP
> to a memory address not used by the main kernel using
> PHYSICAL_START.
>
> - For more details see Documentation/kdump/kdump.rst
> + For more details see Documentation/admin-guide/kdump/kdump.rst
>
> config KEXEC_JUMP
> bool "kexec jump (EXPERIMENTAL)"
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index c9d59ca5e3ac..489fd833b980 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2057,7 +2057,7 @@ config CRASH_DUMP
> to a memory address not used by the main kernel or BIOS using
> PHYSICAL_START, or it must be built as a relocatable image
> (CONFIG_RELOCATABLE=y).
> - For more details see Documentation/kdump/kdump.rst
> + For more details see Documentation/admin-guide/kdump/kdump.rst
>
> config KEXEC_JUMP
> bool "kexec jump"
> @@ -2094,7 +2094,7 @@ config PHYSICAL_START
> the reserved region. In other words, it can be set based on
> the "X" value as specified in the "crashkernel=YM@XM"
> command line boot parameter passed to the panic-ed
> - kernel. Please take a look at Documentation/kdump/kdump.rst
> + kernel. Please take a look at Documentation/admin-guide/kdump/kdump.rst
> for more details about crash dumps.
>
> Usage of bzImage for capturing the crash dump is recommended as
> --
> 2.21.0
>
Acked-by: Dave Young <dyoung@redhat.com>
Thanks
Dave
^ permalink raw reply
* Re: [PATCH 18/39] docs: admin-guide: add kdump documentation into it
From: Dave Young @ 2019-07-05 5:59 UTC (permalink / raw)
To: Alex Shi
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet, Baoquan He,
Vivek Goyal, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Harry Wei, Jerry Hoemann, Wim Van Sebroeck,
Guenter Roeck, Russell King, Catalin Marinas, Will Deacon,
Yoshinori Sato, Rich Felker, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, x86, kexec, linuxppc-dev,
linux-watchdog, linux-arm-kernel, linux-sh
In-Reply-To: <6911b74c-848f-0060-3db5-b5d7e8061cb5@linux.alibaba.com>
On 07/05/19 at 11:43am, Alex Shi wrote:
>
>
> 在 2019/6/28 下午8:30, Mauro Carvalho Chehab 写道:
> > The Kdump documentation describes procedures with admins use
> > in order to solve issues on their systems.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> > Documentation/admin-guide/bug-hunting.rst | 4 ++--
> > Documentation/admin-guide/index.rst | 1 +
> > Documentation/{ => admin-guide}/kdump/gdbmacros.txt | 0
> > Documentation/{ => admin-guide}/kdump/index.rst | 1 -
> > Documentation/{ => admin-guide}/kdump/kdump.rst | 0
> > Documentation/{ => admin-guide}/kdump/vmcoreinfo.rst | 0
>
> I am not sure if it's convenience for people to have more levels in docs.
>
> But I guess, move archs into a Documentation/arch/ dir should be fine. like Documentation/arch/{x86,arm,arm64,ia64,m68k,s390,powerpc,...}
Alex, moving kdump to admin-guide sounds reasonable to me. I also agree
with you for those arch dependent files can be moved to
Documentation/arch/, maybe you are talking about some other patches in
the series for the arch/?
Thanks
dave
^ permalink raw reply
* Re: [PATCH] Documentation: dmaengine: clean up description of dmatest usage
From: Vinod Koul @ 2019-07-05 6:50 UTC (permalink / raw)
To: Hook, Gary
Cc: dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
In-Reply-To: <156140130017.28986.2649022716558702933.stgit@taos>
On 24-06-19, 18:35, Hook, Gary wrote:
> Fix the formatting of the multi-channel test usage example. Call out
> the note about parameter ordering and add detail on the settings of
> parameters for the new version of dmatest.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH v2 1/2] Documentation: perf: Update documentation for ThunderX2 PMU uncore driver
From: Ganapatrao Kulkarni @ 2019-07-05 9:12 UTC (permalink / raw)
To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Will.Deacon@arm.com, mark.rutland@arm.com, corbet@lwn.net,
Jayachandran Chandrasekharan Nair, rrichter@marvell.coma,
Jan Glauber, gklkml16@gmail.com
In-Reply-To: <1562317967-16329-1-git-send-email-gkulkarni@marvell.com>
Add documentation for Cavium Coherent Processor Interconnect (CCPI2) PMU.
Signed-off-by: Ganapatrao Kulkarni <gkulkarni@marvell.com>
---
Documentation/perf/thunderx2-pmu.txt | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/Documentation/perf/thunderx2-pmu.txt b/Documentation/perf/thunderx2-pmu.txt
index dffc57143736..01315b3d4ad9 100644
--- a/Documentation/perf/thunderx2-pmu.txt
+++ b/Documentation/perf/thunderx2-pmu.txt
@@ -2,24 +2,26 @@ Cavium ThunderX2 SoC Performance Monitoring Unit (PMU UNCORE)
=============================================================
The ThunderX2 SoC PMU consists of independent, system-wide, per-socket
-PMUs such as the Level 3 Cache (L3C) and DDR4 Memory Controller (DMC).
+PMUs such as the Level 3 Cache (L3C), DDR4 Memory Controller (DMC) and
+Cavium Coherent Processor Interconnect (CCPI2).
The DMC has 8 interleaved channels and the L3C has 16 interleaved tiles.
Events are counted for the default channel (i.e. channel 0) and prorated
to the total number of channels/tiles.
-The DMC and L3C support up to 4 counters. Counters are independently
-programmable and can be started and stopped individually. Each counter
-can be set to a different event. Counters are 32-bit and do not support
-an overflow interrupt; they are read every 2 seconds.
+The DMC and L3C support up to 4 counters, while the CCPI2 supports up to 8
+counters. Counters are independently programmable to different events and
+can be started and stopped individually. None of the counters support an
+overflow interrupt. DMC and L3C counters are 32-bit and read every 2 seconds.
+The CCPI2 counters are 64-bit and assumed not to overflow in normal operation.
PMU UNCORE (perf) driver:
The thunderx2_pmu driver registers per-socket perf PMUs for the DMC and
-L3C devices. Each PMU can be used to count up to 4 events
-simultaneously. The PMUs provide a description of their available events
-and configuration options under sysfs, see
-/sys/devices/uncore_<l3c_S/dmc_S/>; S is the socket id.
+L3C devices. Each PMU can be used to count up to 4 (DMC/L3C) or up to 8
+(CCPI2) events simultaneously. The PMUs provide a description of their
+available events and configuration options under sysfs, see
+/sys/devices/uncore_<l3c_S/dmc_S/ccpi2_S/>; S is the socket id.
The driver does not support sampling, therefore "perf record" will not
work. Per-task perf sessions are also not supported.
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/2] drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver.
From: Ganapatrao Kulkarni @ 2019-07-05 9:12 UTC (permalink / raw)
To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Will.Deacon@arm.com, mark.rutland@arm.com, corbet@lwn.net,
Jayachandran Chandrasekharan Nair, rrichter@marvell.coma,
Jan Glauber, gklkml16@gmail.com
In-Reply-To: <1562317967-16329-1-git-send-email-gkulkarni@marvell.com>
CCPI2 is a low-latency high-bandwidth serial interface for connecting
ThunderX2 processors. This patch adds support to capture CCPI2 perf events.
Signed-off-by: Ganapatrao Kulkarni <gkulkarni@marvell.com>
---
drivers/perf/thunderx2_pmu.c | 248 ++++++++++++++++++++++++++++++-----
1 file changed, 214 insertions(+), 34 deletions(-)
diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
index 43d76c85da56..af5bf35e0f24 100644
--- a/drivers/perf/thunderx2_pmu.c
+++ b/drivers/perf/thunderx2_pmu.c
@@ -17,22 +17,31 @@
*/
#define TX2_PMU_MAX_COUNTERS 4
+
#define TX2_PMU_DMC_CHANNELS 8
#define TX2_PMU_L3_TILES 16
#define TX2_PMU_HRTIMER_INTERVAL (2 * NSEC_PER_SEC)
-#define GET_EVENTID(ev) ((ev->hw.config) & 0x1f)
-#define GET_COUNTERID(ev) ((ev->hw.idx) & 0x3)
+#define GET_EVENTID(ev, mask) ((ev->hw.config) & mask)
+#define GET_COUNTERID(ev, mask) ((ev->hw.idx) & mask)
/* 1 byte per counter(4 counters).
* Event id is encoded in bits [5:1] of a byte,
*/
#define DMC_EVENT_CFG(idx, val) ((val) << (((idx) * 8) + 1))
+/* bits[3:0] to select counters, are indexed from 8 to 15. */
+#define CCPI2_COUNTER_OFFSET 8
+
#define L3C_COUNTER_CTL 0xA8
#define L3C_COUNTER_DATA 0xAC
#define DMC_COUNTER_CTL 0x234
#define DMC_COUNTER_DATA 0x240
+#define CCPI2_PERF_CTL 0x108
+#define CCPI2_COUNTER_CTL 0x10C
+#define CCPI2_COUNTER_SEL 0x12c
+#define CCPI2_COUNTER_DATA_L 0x130
+
/* L3C event IDs */
#define L3_EVENT_READ_REQ 0xD
#define L3_EVENT_WRITEBACK_REQ 0xE
@@ -51,15 +60,23 @@
#define DMC_EVENT_READ_TXNS 0xF
#define DMC_EVENT_MAX 0x10
+#define CCPI2_EVENT_REQ_PKT_SENT 0x3D
+#define CCPI2_EVENT_SNOOP_PKT_SENT 0x65
+#define CCPI2_EVENT_DATA_PKT_SENT 0x105
+#define CCPI2_EVENT_GIC_PKT_SENT 0x12D
+#define CCPI2_EVENT_MAX 0x200
+
enum tx2_uncore_type {
PMU_TYPE_L3C,
PMU_TYPE_DMC,
+ PMU_TYPE_CCPI2,
PMU_TYPE_INVALID,
};
+
/*
- * pmu on each socket has 2 uncore devices(dmc and l3c),
- * each device has 4 counters.
+ * pmu on each socket has 3 uncore devices(dmc, l3ci and ccpi2),
+ * dmc and l3c has 4 counters and ccpi2 8.
*/
struct tx2_uncore_pmu {
struct hlist_node hpnode;
@@ -69,12 +86,14 @@ struct tx2_uncore_pmu {
int node;
int cpu;
u32 max_counters;
+ u32 counters_mask;
u32 prorate_factor;
u32 max_events;
+ u32 events_mask;
u64 hrtimer_interval;
void __iomem *base;
DECLARE_BITMAP(active_counters, TX2_PMU_MAX_COUNTERS);
- struct perf_event *events[TX2_PMU_MAX_COUNTERS];
+ struct perf_event **events;
struct device *dev;
struct hrtimer hrtimer;
const struct attribute_group **attr_groups;
@@ -92,7 +111,21 @@ static inline struct tx2_uncore_pmu *pmu_to_tx2_pmu(struct pmu *pmu)
return container_of(pmu, struct tx2_uncore_pmu, pmu);
}
-PMU_FORMAT_ATTR(event, "config:0-4");
+#define TX2_PMU_FORMAT_ATTR(_var, _name, _format) \
+static ssize_t \
+__tx2_pmu_##_var##_show(struct device *dev, \
+ struct device_attribute *attr, \
+ char *page) \
+{ \
+ BUILD_BUG_ON(sizeof(_format) >= PAGE_SIZE); \
+ return sprintf(page, _format "\n"); \
+} \
+ \
+static struct device_attribute format_attr_##_var = \
+ __ATTR(_name, 0444, __tx2_pmu_##_var##_show, NULL)
+
+TX2_PMU_FORMAT_ATTR(event, event, "config:0-4");
+TX2_PMU_FORMAT_ATTR(event_ccpi2, event, "config:0-9");
static struct attribute *l3c_pmu_format_attrs[] = {
&format_attr_event.attr,
@@ -104,6 +137,11 @@ static struct attribute *dmc_pmu_format_attrs[] = {
NULL,
};
+static struct attribute *ccpi2_pmu_format_attrs[] = {
+ &format_attr_event_ccpi2.attr,
+ NULL,
+};
+
static const struct attribute_group l3c_pmu_format_attr_group = {
.name = "format",
.attrs = l3c_pmu_format_attrs,
@@ -114,6 +152,11 @@ static const struct attribute_group dmc_pmu_format_attr_group = {
.attrs = dmc_pmu_format_attrs,
};
+static const struct attribute_group ccpi2_pmu_format_attr_group = {
+ .name = "format",
+ .attrs = ccpi2_pmu_format_attrs,
+};
+
/*
* sysfs event attributes
*/
@@ -164,6 +207,19 @@ static struct attribute *dmc_pmu_events_attrs[] = {
NULL,
};
+TX2_EVENT_ATTR(req_pktsent, CCPI2_EVENT_REQ_PKT_SENT);
+TX2_EVENT_ATTR(snoop_pktsent, CCPI2_EVENT_SNOOP_PKT_SENT);
+TX2_EVENT_ATTR(data_pktsent, CCPI2_EVENT_DATA_PKT_SENT);
+TX2_EVENT_ATTR(gic_pktsent, CCPI2_EVENT_GIC_PKT_SENT);
+
+static struct attribute *ccpi2_pmu_events_attrs[] = {
+ &tx2_pmu_event_attr_req_pktsent.attr.attr,
+ &tx2_pmu_event_attr_snoop_pktsent.attr.attr,
+ &tx2_pmu_event_attr_data_pktsent.attr.attr,
+ &tx2_pmu_event_attr_gic_pktsent.attr.attr,
+ NULL,
+};
+
static const struct attribute_group l3c_pmu_events_attr_group = {
.name = "events",
.attrs = l3c_pmu_events_attrs,
@@ -174,6 +230,11 @@ static const struct attribute_group dmc_pmu_events_attr_group = {
.attrs = dmc_pmu_events_attrs,
};
+static const struct attribute_group ccpi2_pmu_events_attr_group = {
+ .name = "events",
+ .attrs = ccpi2_pmu_events_attrs,
+};
+
/*
* sysfs cpumask attributes
*/
@@ -213,11 +274,23 @@ static const struct attribute_group *dmc_pmu_attr_groups[] = {
NULL
};
+static const struct attribute_group *ccpi2_pmu_attr_groups[] = {
+ &ccpi2_pmu_format_attr_group,
+ &pmu_cpumask_attr_group,
+ &ccpi2_pmu_events_attr_group,
+ NULL
+};
+
static inline u32 reg_readl(unsigned long addr)
{
return readl((void __iomem *)addr);
}
+static inline u32 reg_readq(unsigned long addr)
+{
+ return readq((void __iomem *)addr);
+}
+
static inline void reg_writel(u32 val, unsigned long addr)
{
writel(val, (void __iomem *)addr);
@@ -245,33 +318,58 @@ static void init_cntr_base_l3c(struct perf_event *event,
struct tx2_uncore_pmu *tx2_pmu)
{
struct hw_perf_event *hwc = &event->hw;
+ u32 cmask;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ cmask = tx2_pmu->counters_mask;
/* counter ctrl/data reg offset at 8 */
hwc->config_base = (unsigned long)tx2_pmu->base
- + L3C_COUNTER_CTL + (8 * GET_COUNTERID(event));
+ + L3C_COUNTER_CTL + (8 * GET_COUNTERID(event, cmask));
hwc->event_base = (unsigned long)tx2_pmu->base
- + L3C_COUNTER_DATA + (8 * GET_COUNTERID(event));
+ + L3C_COUNTER_DATA + (8 * GET_COUNTERID(event, cmask));
}
static void init_cntr_base_dmc(struct perf_event *event,
struct tx2_uncore_pmu *tx2_pmu)
{
struct hw_perf_event *hwc = &event->hw;
+ u32 cmask;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ cmask = tx2_pmu->counters_mask;
hwc->config_base = (unsigned long)tx2_pmu->base
+ DMC_COUNTER_CTL;
/* counter data reg offset at 0xc */
hwc->event_base = (unsigned long)tx2_pmu->base
- + DMC_COUNTER_DATA + (0xc * GET_COUNTERID(event));
+ + DMC_COUNTER_DATA + (0xc * GET_COUNTERID(event, cmask));
+}
+
+static void init_cntr_base_ccpi2(struct perf_event *event,
+ struct tx2_uncore_pmu *tx2_pmu)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ u32 cmask;
+
+ cmask = tx2_pmu->counters_mask;
+
+ hwc->config_base = (unsigned long)tx2_pmu->base
+ + CCPI2_COUNTER_CTL + (4 * GET_COUNTERID(event, cmask));
+ hwc->event_base = (unsigned long)tx2_pmu->base;
}
static void uncore_start_event_l3c(struct perf_event *event, int flags)
{
- u32 val;
+ u32 val, emask;
struct hw_perf_event *hwc = &event->hw;
+ struct tx2_uncore_pmu *tx2_pmu;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ emask = tx2_pmu->events_mask;
/* event id encoded in bits [07:03] */
- val = GET_EVENTID(event) << 3;
+ val = GET_EVENTID(event, emask) << 3;
reg_writel(val, hwc->config_base);
local64_set(&hwc->prev_count, 0);
reg_writel(0, hwc->event_base);
@@ -284,10 +382,17 @@ static inline void uncore_stop_event_l3c(struct perf_event *event)
static void uncore_start_event_dmc(struct perf_event *event, int flags)
{
- u32 val;
+ u32 val, cmask, emask;
struct hw_perf_event *hwc = &event->hw;
- int idx = GET_COUNTERID(event);
- int event_id = GET_EVENTID(event);
+ struct tx2_uncore_pmu *tx2_pmu;
+ int idx, event_id;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ cmask = tx2_pmu->counters_mask;
+ emask = tx2_pmu->events_mask;
+
+ idx = GET_COUNTERID(event, cmask);
+ event_id = GET_EVENTID(event, emask);
/* enable and start counters.
* 8 bits for each counter, bits[05:01] of a counter to set event type.
@@ -302,9 +407,14 @@ static void uncore_start_event_dmc(struct perf_event *event, int flags)
static void uncore_stop_event_dmc(struct perf_event *event)
{
- u32 val;
+ u32 val, cmask;
struct hw_perf_event *hwc = &event->hw;
- int idx = GET_COUNTERID(event);
+ struct tx2_uncore_pmu *tx2_pmu;
+ int idx;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ cmask = tx2_pmu->counters_mask;
+ idx = GET_COUNTERID(event, cmask);
/* clear event type(bits[05:01]) to stop counter */
val = reg_readl(hwc->config_base);
@@ -312,6 +422,31 @@ static void uncore_stop_event_dmc(struct perf_event *event)
reg_writel(val, hwc->config_base);
}
+static void uncore_start_event_ccpi2(struct perf_event *event, int flags)
+{
+ u32 emask;
+ struct hw_perf_event *hwc = &event->hw;
+ struct tx2_uncore_pmu *tx2_pmu;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ emask = tx2_pmu->events_mask;
+
+ /* Bit [09:00] to set event id, set level and type to 1 */
+ reg_writel((3 << 10) |
+ GET_EVENTID(event, emask), hwc->config_base);
+ /* reset[4], enable[0] and start[1] counters */
+ reg_writel(0x13, hwc->event_base + CCPI2_PERF_CTL);
+ local64_set(&event->hw.prev_count, 0ULL);
+}
+
+static void uncore_stop_event_ccpi2(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+
+ /* disable and stop counter */
+ reg_writel(0, hwc->event_base + CCPI2_PERF_CTL);
+}
+
static void tx2_uncore_event_update(struct perf_event *event)
{
s64 prev, delta, new = 0;
@@ -319,20 +454,30 @@ static void tx2_uncore_event_update(struct perf_event *event)
struct tx2_uncore_pmu *tx2_pmu;
enum tx2_uncore_type type;
u32 prorate_factor;
+ u32 cmask, emask;
tx2_pmu = pmu_to_tx2_pmu(event->pmu);
type = tx2_pmu->type;
+ cmask = tx2_pmu->counters_mask;
+ emask = tx2_pmu->events_mask;
prorate_factor = tx2_pmu->prorate_factor;
-
- new = reg_readl(hwc->event_base);
- prev = local64_xchg(&hwc->prev_count, new);
-
- /* handles rollover of 32 bit counter */
- delta = (u32)(((1UL << 32) - prev) + new);
+ if (type == PMU_TYPE_CCPI2) {
+ reg_writel(CCPI2_COUNTER_OFFSET +
+ GET_COUNTERID(event, cmask),
+ hwc->event_base + CCPI2_COUNTER_SEL);
+ new = reg_readq(hwc->event_base + CCPI2_COUNTER_DATA_L);
+ prev = local64_xchg(&hwc->prev_count, new);
+ delta = new - prev;
+ } else {
+ new = reg_readl(hwc->event_base);
+ prev = local64_xchg(&hwc->prev_count, new);
+ /* handles rollover of 32 bit counter */
+ delta = (u32)(((1UL << 32) - prev) + new);
+ }
/* DMC event data_transfers granularity is 16 Bytes, convert it to 64 */
if (type == PMU_TYPE_DMC &&
- GET_EVENTID(event) == DMC_EVENT_DATA_TRANSFERS)
+ GET_EVENTID(event, emask) == DMC_EVENT_DATA_TRANSFERS)
delta = delta/4;
/* L3C and DMC has 16 and 8 interleave channels respectively.
@@ -351,6 +496,7 @@ static enum tx2_uncore_type get_tx2_pmu_type(struct acpi_device *adev)
} devices[] = {
{"CAV901D", PMU_TYPE_L3C},
{"CAV901F", PMU_TYPE_DMC},
+ {"CAV901E", PMU_TYPE_CCPI2},
{"", PMU_TYPE_INVALID}
};
@@ -380,7 +526,8 @@ static bool tx2_uncore_validate_event(struct pmu *pmu,
* Make sure the group of events can be scheduled at once
* on the PMU.
*/
-static bool tx2_uncore_validate_event_group(struct perf_event *event)
+static bool tx2_uncore_validate_event_group(struct perf_event *event,
+ int max_counters)
{
struct perf_event *sibling, *leader = event->group_leader;
int counters = 0;
@@ -403,7 +550,7 @@ static bool tx2_uncore_validate_event_group(struct perf_event *event)
* If the group requires more counters than the HW has,
* it cannot ever be scheduled.
*/
- return counters <= TX2_PMU_MAX_COUNTERS;
+ return counters <= max_counters;
}
@@ -439,7 +586,7 @@ static int tx2_uncore_event_init(struct perf_event *event)
hwc->config = event->attr.config;
/* Validate the group */
- if (!tx2_uncore_validate_event_group(event))
+ if (!tx2_uncore_validate_event_group(event, tx2_pmu->max_counters))
return -EINVAL;
return 0;
@@ -456,8 +603,9 @@ static void tx2_uncore_event_start(struct perf_event *event, int flags)
tx2_pmu->start_event(event, flags);
perf_event_update_userpage(event);
- /* Start timer for first event */
- if (bitmap_weight(tx2_pmu->active_counters,
+ /* Start timer for first non ccpi2 event */
+ if (tx2_pmu->type != PMU_TYPE_CCPI2 &&
+ bitmap_weight(tx2_pmu->active_counters,
tx2_pmu->max_counters) == 1) {
hrtimer_start(&tx2_pmu->hrtimer,
ns_to_ktime(tx2_pmu->hrtimer_interval),
@@ -495,7 +643,8 @@ static int tx2_uncore_event_add(struct perf_event *event, int flags)
if (hwc->idx < 0)
return -EAGAIN;
- tx2_pmu->events[hwc->idx] = event;
+ if (tx2_pmu->events)
+ tx2_pmu->events[hwc->idx] = event;
/* set counter control and data registers base address */
tx2_pmu->init_cntr_base(event, tx2_pmu);
@@ -510,14 +659,17 @@ static void tx2_uncore_event_del(struct perf_event *event, int flags)
{
struct tx2_uncore_pmu *tx2_pmu = pmu_to_tx2_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
+ u32 cmask;
+ cmask = tx2_pmu->counters_mask;
tx2_uncore_event_stop(event, PERF_EF_UPDATE);
/* clear the assigned counter */
- free_counter(tx2_pmu, GET_COUNTERID(event));
+ free_counter(tx2_pmu, GET_COUNTERID(event, cmask));
perf_event_update_userpage(event);
- tx2_pmu->events[hwc->idx] = NULL;
+ if (tx2_pmu->events)
+ tx2_pmu->events[hwc->idx] = NULL;
hwc->idx = -1;
}
@@ -580,8 +732,12 @@ static int tx2_uncore_pmu_add_dev(struct tx2_uncore_pmu *tx2_pmu)
cpu_online_mask);
tx2_pmu->cpu = cpu;
- hrtimer_init(&tx2_pmu->hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
- tx2_pmu->hrtimer.function = tx2_hrtimer_callback;
+ /* CCPI2 counters are 64 bit counters, no overflow */
+ if (tx2_pmu->type != PMU_TYPE_CCPI2) {
+ hrtimer_init(&tx2_pmu->hrtimer,
+ CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ tx2_pmu->hrtimer.function = tx2_hrtimer_callback;
+ }
ret = tx2_uncore_pmu_register(tx2_pmu);
if (ret) {
@@ -654,8 +810,10 @@ static struct tx2_uncore_pmu *tx2_uncore_pmu_init_dev(struct device *dev,
switch (tx2_pmu->type) {
case PMU_TYPE_L3C:
tx2_pmu->max_counters = TX2_PMU_MAX_COUNTERS;
+ tx2_pmu->counters_mask = 0x3;
tx2_pmu->prorate_factor = TX2_PMU_L3_TILES;
tx2_pmu->max_events = L3_EVENT_MAX;
+ tx2_pmu->events_mask = 0x1f;
tx2_pmu->hrtimer_interval = TX2_PMU_HRTIMER_INTERVAL;
tx2_pmu->attr_groups = l3c_pmu_attr_groups;
tx2_pmu->name = devm_kasprintf(dev, GFP_KERNEL,
@@ -663,11 +821,15 @@ static struct tx2_uncore_pmu *tx2_uncore_pmu_init_dev(struct device *dev,
tx2_pmu->init_cntr_base = init_cntr_base_l3c;
tx2_pmu->start_event = uncore_start_event_l3c;
tx2_pmu->stop_event = uncore_stop_event_l3c;
+ tx2_pmu->events = devm_kzalloc(dev, tx2_pmu->max_counters *
+ sizeof(*tx2_pmu->events), GFP_KERNEL);
break;
case PMU_TYPE_DMC:
tx2_pmu->max_counters = TX2_PMU_MAX_COUNTERS;
+ tx2_pmu->counters_mask = 0x3;
tx2_pmu->prorate_factor = TX2_PMU_DMC_CHANNELS;
tx2_pmu->max_events = DMC_EVENT_MAX;
+ tx2_pmu->events_mask = 0x1f;
tx2_pmu->hrtimer_interval = TX2_PMU_HRTIMER_INTERVAL;
tx2_pmu->attr_groups = dmc_pmu_attr_groups;
tx2_pmu->name = devm_kasprintf(dev, GFP_KERNEL,
@@ -675,6 +837,23 @@ static struct tx2_uncore_pmu *tx2_uncore_pmu_init_dev(struct device *dev,
tx2_pmu->init_cntr_base = init_cntr_base_dmc;
tx2_pmu->start_event = uncore_start_event_dmc;
tx2_pmu->stop_event = uncore_stop_event_dmc;
+ tx2_pmu->events = devm_kzalloc(dev, tx2_pmu->max_counters *
+ sizeof(*tx2_pmu->events), GFP_KERNEL);
+ break;
+ case PMU_TYPE_CCPI2:
+ /* CCPI2 has 8 counters */
+ tx2_pmu->max_counters = 8;
+ tx2_pmu->counters_mask = 0x7;
+ tx2_pmu->prorate_factor = 1;
+ tx2_pmu->max_events = CCPI2_EVENT_MAX;
+ tx2_pmu->events_mask = 0x1ff;
+ tx2_pmu->attr_groups = ccpi2_pmu_attr_groups;
+ tx2_pmu->name = devm_kasprintf(dev, GFP_KERNEL,
+ "uncore_ccpi2_%d", tx2_pmu->node);
+ tx2_pmu->init_cntr_base = init_cntr_base_ccpi2;
+ tx2_pmu->start_event = uncore_start_event_ccpi2;
+ tx2_pmu->stop_event = uncore_stop_event_ccpi2;
+ tx2_pmu->events = NULL;
break;
case PMU_TYPE_INVALID:
devm_kfree(dev, tx2_pmu);
@@ -744,7 +923,8 @@ static int tx2_uncore_pmu_offline_cpu(unsigned int cpu,
if (cpu != tx2_pmu->cpu)
return 0;
- hrtimer_cancel(&tx2_pmu->hrtimer);
+ if (tx2_pmu->type != PMU_TYPE_CCPI2)
+ hrtimer_cancel(&tx2_pmu->hrtimer);
cpumask_copy(&cpu_online_mask_temp, cpu_online_mask);
cpumask_clear_cpu(cpu, &cpu_online_mask_temp);
new_cpu = cpumask_any_and(
--
2.17.1
^ permalink raw reply related
* [PATCH v2 0/2] Add CCPI2 PMU support
From: Ganapatrao Kulkarni @ 2019-07-05 9:12 UTC (permalink / raw)
To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Will.Deacon@arm.com, mark.rutland@arm.com, corbet@lwn.net,
Jayachandran Chandrasekharan Nair, rrichter@marvell.coma,
Jan Glauber, gklkml16@gmail.com
Add Cavium Coherent Processor Interconnect (CCPI2) PMU
support in ThunderX2 Uncore driver.
v2: Updated with review comments [1]
[1] https://lkml.org/lkml/2019/6/14/965
v1: initial patch
Ganapatrao Kulkarni (2):
Documentation: perf: Update documentation for ThunderX2 PMU uncore
driver
drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver.
Documentation/perf/thunderx2-pmu.txt | 20 ++-
drivers/perf/thunderx2_pmu.c | 248 +++++++++++++++++++++++----
2 files changed, 225 insertions(+), 43 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH 41/43] docs: extcon: convert it to ReST and move to acpi dir
From: Rafael J. Wysocki @ 2019-07-05 9:41 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, MyungJoo Ham, Chanwoo Choi, Len Brown,
linux-acpi
In-Reply-To: <bce6d8c98a188ec5f0efe78962aa12839c7442e9.1561723980.git.mchehab+samsung@kernel.org>
On Friday, June 28, 2019 2:20:37 PM CEST Mauro Carvalho Chehab wrote:
> The intel-int3496.txt file is a documentation for an ACPI driver.
>
> There's no reason to keep it on a separate directory.
>
> So, instead of keeping it on some random location, move it
> to a sub-directory inside the ACPI documentation dir,
> renaming it to .rst.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> .../acpi/extcon-intel-int3496.rst} | 14 ++++++++++----
> Documentation/firmware-guide/acpi/index.rst | 1 +
> MAINTAINERS | 6 +++---
> 3 files changed, 14 insertions(+), 7 deletions(-)
> rename Documentation/{extcon/intel-int3496.txt => firmware-guide/acpi/extcon-intel-int3496.rst} (66%)
>
> diff --git a/Documentation/extcon/intel-int3496.txt b/Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> similarity index 66%
> rename from Documentation/extcon/intel-int3496.txt
> rename to Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> index 8155dbc7fad3..5137ca834b54 100644
> --- a/Documentation/extcon/intel-int3496.txt
> +++ b/Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> @@ -1,5 +1,6 @@
> +=====================================================
> Intel INT3496 ACPI device extcon driver documentation
> ------------------------------------------------------
> +=====================================================
>
> The Intel INT3496 ACPI device extcon driver is a driver for ACPI
> devices with an acpi-id of INT3496, such as found for example on
> @@ -13,15 +14,20 @@ between an USB host and an USB peripheral controller.
> The ACPI devices exposes this functionality by returning an array with up
> to 3 gpio descriptors from its ACPI _CRS (Current Resource Settings) call:
>
> -Index 0: The input gpio for the id-pin, this is always present and valid
> -Index 1: The output gpio for enabling Vbus output from the device to the otg
> +======= =====================================================================
> +Index 0 The input gpio for the id-pin, this is always present and valid
> +Index 1 The output gpio for enabling Vbus output from the device to the otg
> port, write 1 to enable the Vbus output (this gpio descriptor may
> be absent or invalid)
> -Index 2: The output gpio for muxing of the data pins between the USB host and
> +Index 2 The output gpio for muxing of the data pins between the USB host and
> the USB peripheral controller, write 1 to mux to the peripheral
> controller
> +======= =====================================================================
>
> There is a mapping between indices and GPIO connection IDs as follows
> +
> + ======= =======
> id index 0
> vbus index 1
> mux index 2
> + ======= =======
> diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst
> index ae609eec4679..90c90d42d9ad 100644
> --- a/Documentation/firmware-guide/acpi/index.rst
> +++ b/Documentation/firmware-guide/acpi/index.rst
> @@ -24,3 +24,4 @@ ACPI Support
> acpi-lid
> lpit
> video_extension
> + extcon-intel-int3496
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fd6fab0dec77..2cf8abf6d48e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -321,7 +321,7 @@ F: drivers/pnp/pnpacpi/
> F: include/linux/acpi.h
> F: include/linux/fwnode.h
> F: include/acpi/
> -F: Documentation/acpi/
> +F: Documentation/firmware-guide/acpi/
> F: Documentation/ABI/testing/sysfs-bus-acpi
> F: Documentation/ABI/testing/configfs-acpi
> F: drivers/pci/*acpi*
> @@ -4896,7 +4896,7 @@ S: Maintained
> F: Documentation/
> F: scripts/kernel-doc
> X: Documentation/ABI/
> -X: Documentation/acpi/
> +X: Documentation/firmware-guide/acpi/
> X: Documentation/devicetree/
> X: Documentation/i2c/
> X: Documentation/media/
> @@ -6073,7 +6073,7 @@ S: Maintained
> F: drivers/extcon/
> F: include/linux/extcon/
> F: include/linux/extcon.h
> -F: Documentation/extcon/
> +F: Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> F: Documentation/devicetree/bindings/extcon/
>
> EXYNOS DP DRIVER
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] tpm: Document UEFI event log quirks
From: Jarkko Sakkinen @ 2019-07-05 10:11 UTC (permalink / raw)
To: linux-kernel, linux-integrity, linux-doc
Cc: tweek, matthewgarrett, Jonathan Corbet
In-Reply-To: <20190703161109.22935-1-jarkko.sakkinen@linux.intel.com>
> +| Authors:
> +| Stefan Berger <stefanb@linux.vnet.ibm.com>
I was looking how the rst formatting went from Stefan's
document. This one is authored by me.
/Jarkko
^ permalink raw reply
* Re: [PATCH] tpm: Document UEFI event log quirks
From: Jarkko Sakkinen @ 2019-07-05 10:15 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel, linux-integrity, linux-doc
Cc: tweek, matthewgarrett, Jonathan Corbet
In-Reply-To: <6acf78df-b168-14d3-fea4-9a9d2945e77f@infradead.org>
On Wed, 2019-07-03 at 09:45 -0700, Randy Dunlap wrote:
> > +This introduces another problem: nothing guarantees that it is not
> > +called before the stub gets to run. Thus, it needs to copy the final
> > +events table preboot size to the custom configuration table so that
> > +kernel offset it later on.
>
> ? kernel can offset it later on.
EFI stub calculates the total size of the events in the final events
table at the time.
Later on, TPM driver uses this offset to copy only the events that
were actually generated after ExitBootServices():
/*
* Copy any of the final events log that didn't also end up in the
* main log. Events can be logged in both if events are generated
* between GetEventLog() and ExitBootServices().
*/
memcpy((void *)log->bios_event_log + log_size,
final_tbl->events + log_tbl->final_events_preboot_size,
efi_tpm_final_log_size);
What would be a better way to describe this?
/Jarkko
^ permalink raw reply
* Re: [PATCH] tpm: Document UEFI event log quirks
From: Jarkko Sakkinen @ 2019-07-05 10:26 UTC (permalink / raw)
To: Jordan Hand, linux-kernel, linux-integrity, linux-doc
Cc: tweek, matthewgarrett, Jonathan Corbet
In-Reply-To: <dacf145d-49e0-16e5-5963-415bab1884e1@linux.microsoft.com>
On Wed, 2019-07-03 at 10:08 -0700, Jordan Hand wrote:
> > +This introduces another problem: nothing guarantees that it is not
> > +called before the stub gets to run. Thus, it needs to copy the final
> > +events table preboot size to the custom configuration table so that
> > +kernel offset it later on.
>
> This doesn't really explain what the size will be used for. Matthew's
> patch description for "tpm: Don't duplicate events from the final event
> log in the TCG2 log" outlines this well. You could maybe word it
> differently but I think the information is necessary:
>
> "We can avoid this problem by looking at the size of the Final Event Log
> just before we call ExitBootServices() and exporting this to the main
> kernel. The kernel can then skip over all events that occured before
> ExitBootServices() and only append events that were not also logged to
> the main log."
Not exactly sure what is missing from my paragraph. The way I see it has
more information as it states what is used at as the vessel for
exportation (the custom configuration table).
Maybe something like:
"Thus, it nees to save the final events table size at the time to the
custom configuration table so that the TPM driver can later on skip the
events generated during the preboot time."
/Jarkko
^ permalink raw reply
* Re: [PATCH 1/3] docs: s390: restore important non-kdoc parts of s390dbf.rst
From: Christian Borntraeger @ 2019-07-05 10:53 UTC (permalink / raw)
To: Steffen Maier, linux-doc
Cc: linux-s390, Mauro Carvalho Chehab, Mauro Carvalho Chehab,
Heiko Carstens, Vasily Gorbik, linux-kernel
In-Reply-To: <1562149189-1417-2-git-send-email-maier@linux.ibm.com>
On 03.07.19 12:19, Steffen Maier wrote:
> Complements previous ("s390: include/asm/debug.h add kerneldoc markups")
> which seemed to have dropped important non-kdoc parts such as
> user space interface (level, size, flush)
> as well as views and caution regarding strings in the sprintf view.
>
> Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> Documentation/s390/s390dbf.rst | 339 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 339 insertions(+)
>
> diff --git a/Documentation/s390/s390dbf.rst b/Documentation/s390/s390dbf.rst
> index d2595b548879..01d66251643d 100644
> --- a/Documentation/s390/s390dbf.rst
> +++ b/Documentation/s390/s390dbf.rst
> @@ -112,6 +112,345 @@ Kernel Interfaces:
> Predefined views:
> -----------------
>
> +extern struct debug_view debug_hex_ascii_view;
> +
> +extern struct debug_view debug_raw_view;
> +
> +extern struct debug_view debug_sprintf_view;
> +
> +Examples
> +--------
> +
> +::
> +
> + /*
> + * hex_ascii- + raw-view Example
> + */
> +
> + #include <linux/init.h>
> + #include <asm/debug.h>
> +
> + static debug_info_t* debug_info;
> +
> + static int init(void)
> + {
> + /* register 4 debug areas with one page each and 4 byte data field */
> +
> + debug_info = debug_register ("test", 1, 4, 4 );
> + debug_register_view(debug_info,&debug_hex_ascii_view);
> + debug_register_view(debug_info,&debug_raw_view);
> +
> + debug_text_event(debug_info, 4 , "one ");
> + debug_int_exception(debug_info, 4, 4711);
> + debug_event(debug_info, 3, &debug_info, 4);
> +
> + return 0;
> + }
> +
> + static void cleanup(void)
> + {
> + debug_unregister (debug_info);
> + }
> +
> + module_init(init);
> + module_exit(cleanup);
> +
> +::
> +
> + /*
> + * sprintf-view Example
> + */
> +
> + #include <linux/init.h>
> + #include <asm/debug.h>
> +
> + static debug_info_t* debug_info;
> +
> + static int init(void)
> + {
> + /* register 4 debug areas with one page each and data field for */
> + /* format string pointer + 2 varargs (= 3 * sizeof(long)) */
> +
> + debug_info = debug_register ("test", 1, 4, sizeof(long) * 3);
> + debug_register_view(debug_info,&debug_sprintf_view);
> +
> + debug_sprintf_event(debug_info, 2 , "first event in %s:%i\n",__FILE__,__LINE__);
> + debug_sprintf_exception(debug_info, 1, "pointer to debug info: %p\n",&debug_info);
> +
> + return 0;
> + }
> +
> + static void cleanup(void)
> + {
> + debug_unregister (debug_info);
> + }
> +
> + module_init(init);
> + module_exit(cleanup);
> +
> +Debugfs Interface
> +-----------------
> +Views to the debug logs can be investigated through reading the corresponding
> +debugfs-files:
> +
> +Example::
> +
> + > ls /sys/kernel/debug/s390dbf/dasd
> + flush hex_ascii level pages raw
> + > cat /sys/kernel/debug/s390dbf/dasd/hex_ascii | sort -k2,2 -s
> + 00 00974733272:680099 2 - 02 0006ad7e 07 ea 4a 90 | ....
> + 00 00974733272:682210 2 - 02 0006ade6 46 52 45 45 | FREE
> + 00 00974733272:682213 2 - 02 0006adf6 07 ea 4a 90 | ....
> + 00 00974733272:682281 1 * 02 0006ab08 41 4c 4c 43 | EXCP
> + 01 00974733272:682284 2 - 02 0006ab16 45 43 4b 44 | ECKD
> + 01 00974733272:682287 2 - 02 0006ab28 00 00 00 04 | ....
> + 01 00974733272:682289 2 - 02 0006ab3e 00 00 00 20 | ...
> + 01 00974733272:682297 2 - 02 0006ad7e 07 ea 4a 90 | ....
> + 01 00974733272:684384 2 - 00 0006ade6 46 52 45 45 | FREE
> + 01 00974733272:684388 2 - 00 0006adf6 07 ea 4a 90 | ....
> +
> +See section about predefined views for explanation of the above output!
> +
> +Changing the debug level
> +------------------------
> +
> +Example::
> +
> +
> + > cat /sys/kernel/debug/s390dbf/dasd/level
> + 3
> + > echo "5" > /sys/kernel/debug/s390dbf/dasd/level
> + > cat /sys/kernel/debug/s390dbf/dasd/level
> + 5
> +
> +Flushing debug areas
> +--------------------
> +Debug areas can be flushed with piping the number of the desired
> +area (0...n) to the debugfs file "flush". When using "-" all debug areas
> +are flushed.
> +
> +Examples:
> +
> +1. Flush debug area 0::
> +
> + > echo "0" > /sys/kernel/debug/s390dbf/dasd/flush
> +
> +2. Flush all debug areas::
> +
> + > echo "-" > /sys/kernel/debug/s390dbf/dasd/flush
> +
> +Changing the size of debug areas
> +------------------------------------
> +It is possible the change the size of debug areas through piping
> +the number of pages to the debugfs file "pages". The resize request will
> +also flush the debug areas.
> +
> +Example:
> +
> +Define 4 pages for the debug areas of debug feature "dasd"::
> +
> + > echo "4" > /sys/kernel/debug/s390dbf/dasd/pages
> +
> +Stooping the debug feature
> +--------------------------
> +Example:
> +
> +1. Check if stopping is allowed::
> +
> + > cat /proc/sys/s390dbf/debug_stoppable
> +
> +2. Stop debug feature::
> +
> + > echo 0 > /proc/sys/s390dbf/debug_active
> +
> +lcrash Interface
> +----------------
> +It is planned that the dump analysis tool lcrash gets an additional command
> +'s390dbf' to display all the debug logs. With this tool it will be possible
> +to investigate the debug logs on a live system and with a memory dump after
> +a system crash.
> +
> +Investigating raw memory
> +------------------------
> +One last possibility to investigate the debug logs at a live
> +system and after a system crash is to look at the raw memory
> +under VM or at the Service Element.
> +It is possible to find the anker of the debug-logs through
> +the 'debug_area_first' symbol in the System map. Then one has
> +to follow the correct pointers of the data-structures defined
> +in debug.h and find the debug-areas in memory.
> +Normally modules which use the debug feature will also have
> +a global variable with the pointer to the debug-logs. Following
> +this pointer it will also be possible to find the debug logs in
> +memory.
> +
> +For this method it is recommended to use '16 * x + 4' byte (x = 0..n)
> +for the length of the data field in debug_register() in
> +order to see the debug entries well formatted.
> +
> +
> +Predefined Views
> +----------------
> +
> +There are three predefined views: hex_ascii, raw and sprintf.
> +The hex_ascii view shows the data field in hex and ascii representation
> +(e.g. '45 43 4b 44 | ECKD').
> +The raw view returns a bytestream as the debug areas are stored in memory.
> +
> +The sprintf view formats the debug entries in the same way as the sprintf
> +function would do. The sprintf event/exception functions write to the
> +debug entry a pointer to the format string (size = sizeof(long))
> +and for each vararg a long value. So e.g. for a debug entry with a format
> +string plus two varargs one would need to allocate a (3 * sizeof(long))
> +byte data area in the debug_register() function.
> +
> +IMPORTANT:
> + Using "%s" in sprintf event functions is dangerous. You can only
> + use "%s" in the sprintf event functions, if the memory for the passed string
> + is available as long as the debug feature exists. The reason behind this is
> + that due to performance considerations only a pointer to the string is stored
> + in the debug feature. If you log a string that is freed afterwards, you will
> + get an OOPS when inspecting the debug feature, because then the debug feature
> + will access the already freed memory.
> +
> +NOTE:
> + If using the sprintf view do NOT use other event/exception functions
> + than the sprintf-event and -exception functions.
> +
> +The format of the hex_ascii and sprintf view is as follows:
> +
> +- Number of area
> +- Timestamp (formatted as seconds and microseconds since 00:00:00 Coordinated
> + Universal Time (UTC), January 1, 1970)
> +- level of debug entry
> +- Exception flag (* = Exception)
> +- Cpu-Number of calling task
> +- Return Address to caller
> +- data field
> +
> +The format of the raw view is:
> +
> +- Header as described in debug.h
> +- datafield
> +
> +A typical line of the hex_ascii view will look like the following (first line
> +is only for explanation and will not be displayed when 'cating' the view):
> +
> +area time level exception cpu caller data (hex + ascii)
> +--------------------------------------------------------------------------
> +00 00964419409:440690 1 - 00 88023fe
> +
> +
> +Defining views
> +--------------
> +
> +Views are specified with the 'debug_view' structure. There are defined
> +callback functions which are used for reading and writing the debugfs files::
> +
> + struct debug_view {
> + char name[DEBUG_MAX_PROCF_LEN];
> + debug_prolog_proc_t* prolog_proc;
> + debug_header_proc_t* header_proc;
> + debug_format_proc_t* format_proc;
> + debug_input_proc_t* input_proc;
> + void* private_data;
> + };
> +
> +where::
> +
> + typedef int (debug_header_proc_t) (debug_info_t* id,
> + struct debug_view* view,
> + int area,
> + debug_entry_t* entry,
> + char* out_buf);
> +
> + typedef int (debug_format_proc_t) (debug_info_t* id,
> + struct debug_view* view, char* out_buf,
> + const char* in_buf);
> + typedef int (debug_prolog_proc_t) (debug_info_t* id,
> + struct debug_view* view,
> + char* out_buf);
> + typedef int (debug_input_proc_t) (debug_info_t* id,
> + struct debug_view* view,
> + struct file* file, const char* user_buf,
> + size_t in_buf_size, loff_t* offset);
> +
> +
> +The "private_data" member can be used as pointer to view specific data.
> +It is not used by the debug feature itself.
> +
> +The output when reading a debugfs file is structured like this::
> +
> + "prolog_proc output"
> +
> + "header_proc output 1" "format_proc output 1"
> + "header_proc output 2" "format_proc output 2"
> + "header_proc output 3" "format_proc output 3"
> + ...
> +
> +When a view is read from the debugfs, the Debug Feature calls the
> +'prolog_proc' once for writing the prolog.
> +Then 'header_proc' and 'format_proc' are called for each
> +existing debug entry.
> +
> +The input_proc can be used to implement functionality when it is written to
> +the view (e.g. like with 'echo "0" > /sys/kernel/debug/s390dbf/dasd/level).
> +
> +For header_proc there can be used the default function
> +debug_dflt_header_fn() which is defined in debug.h.
> +and which produces the same header output as the predefined views.
> +E.g::
> +
> + 00 00964419409:440761 2 - 00 88023ec
> +
> +In order to see how to use the callback functions check the implementation
> +of the default views!
> +
> +Example::
> +
> + #include <asm/debug.h>
> +
> + #define UNKNOWNSTR "data: %08x"
> +
> + const char* messages[] =
> + {"This error...........\n",
> + "That error...........\n",
> + "Problem..............\n",
> + "Something went wrong.\n",
> + "Everything ok........\n",
> + NULL
> + };
> +
> + static int debug_test_format_fn(
> + debug_info_t * id, struct debug_view *view,
> + char *out_buf, const char *in_buf
> + )
> + {
> + int i, rc = 0;
> +
> + if(id->buf_size >= 4) {
> + int msg_nr = *((int*)in_buf);
> + if(msg_nr < sizeof(messages)/sizeof(char*) - 1)
> + rc += sprintf(out_buf, "%s", messages[msg_nr]);
> + else
> + rc += sprintf(out_buf, UNKNOWNSTR, msg_nr);
> + }
> + out:
> + return rc;
> + }
> +
> + struct debug_view debug_test_view = {
> + "myview", /* name of view */
> + NULL, /* no prolog */
> + &debug_dflt_header_fn, /* default header for each entry */
> + &debug_test_format_fn, /* our own format function */
> + NULL, /* no input function */
> + NULL /* no private data */
> + };
> +
> +test:
> +=====
> +
> ::
>
> debug_info_t *debug_info;
>
^ permalink raw reply
* Re: [PATCH 2/3] docs: s390: unify and update s390dbf kdocs at debug.c
From: Christian Borntraeger @ 2019-07-05 10:54 UTC (permalink / raw)
To: Steffen Maier, linux-doc
Cc: linux-s390, Mauro Carvalho Chehab, Mauro Carvalho Chehab,
Heiko Carstens, Vasily Gorbik, linux-kernel
In-Reply-To: <1562149189-1417-3-git-send-email-maier@linux.ibm.com>
On 03.07.19 12:19, Steffen Maier wrote:
> For non-static-inlines, debug.c already had non-compliant function
> header docs. So move the pure prototype kdocs of
> ("s390: include/asm/debug.h add kerneldoc markups")
> from debug.h to debug.c and merge them with the old function docs.
> Also, I had the impression that kdoc typically is at the implementation
> in the compile unit rather than at the prototype in the header file.
>
> While at it, update the short kdoc description to distinguish the
> different functions. And a few more consistency cleanups.
>
> Added a new kdoc for debug_set_critical() since debug.h comments it
> as part of the API.
>
> Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> Documentation/s390/s390dbf.rst | 1 +
> arch/s390/include/asm/debug.h | 112 ++++++-----------------------------------
> arch/s390/kernel/debug.c | 105 +++++++++++++++++++++++++++++++-------
> 3 files changed, 102 insertions(+), 116 deletions(-)
>
> diff --git a/Documentation/s390/s390dbf.rst b/Documentation/s390/s390dbf.rst
> index 01d66251643d..be42892b159e 100644
> --- a/Documentation/s390/s390dbf.rst
> +++ b/Documentation/s390/s390dbf.rst
> @@ -107,6 +107,7 @@ will stay deactivated.
> Kernel Interfaces:
> ------------------
>
> +.. kernel-doc:: arch/s390/kernel/debug.c
> .. kernel-doc:: arch/s390/include/asm/debug.h
>
> Predefined views:
> diff --git a/arch/s390/include/asm/debug.h b/arch/s390/include/asm/debug.h
> index 02c36eedd780..310134015541 100644
> --- a/arch/s390/include/asm/debug.h
> +++ b/arch/s390/include/asm/debug.h
> @@ -95,77 +95,19 @@ debug_entry_t *debug_exception_common(debug_info_t *id, int level,
>
> /* Debug Feature API: */
>
> -/**
> - * debug_register() - allocates memory for a debug log.
> - *
> - * @name: Name of debug log (e.g. used for debugfs entry)
> - * @pages: Number of pages, which will be allocated per area
> - * @nr_areas: Number of debug areas
> - * @buf_size: Size of data area in each debug entry
> - *
> - * Return:
> - * - Handler for generated debug area
> - * - %NULL if register failed
> - *
> - * Must not be called within an interrupt handler.
> - */
> debug_info_t *debug_register(const char *name, int pages, int nr_areas,
> int buf_size);
>
> -/**
> - * debug_register_mode() - allocates memory for a debug log.
> - *
> - * @name: Name of debug log (e.g. used for debugfs entry)
> - * @pages: Number of pages, which will be allocated per area
> - * @nr_areas: Number of debug areas
> - * @buf_size: Size of data area in each debug entry
> - * @mode: File mode for debugfs files. E.g. S_IRWXUGO
> - * @uid: User ID for debugfs files. Currently only 0 is supported.
> - * @gid: Group ID for debugfs files. Currently only 0 is supported.
> - *
> - * Return:
> - * - Handler for generated debug area
> - * - %NULL if register failed
> - *
> - * Must not be called within an interrupt handler
> - */
> debug_info_t *debug_register_mode(const char *name, int pages, int nr_areas,
> int buf_size, umode_t mode, uid_t uid,
> gid_t gid);
>
> -/**
> - * debug_unregister() - frees memory for a debug log and removes all
> - * registered debug
> - * views.
> - *
> - * @id: handle for debug log
> - *
> - * Return:
> - * none
> - *
> - * Must not be called within an interrupt handler
> - */
> void debug_unregister(debug_info_t *id);
>
> -/**
> - * debug_set_level() - Sets new actual debug level if new_level is valid.
> - *
> - * @id: handle for debug log
> - * @new_level: new debug level
> - *
> - * Return:
> - * none
> - */
> void debug_set_level(debug_info_t *id, int new_level);
>
> void debug_set_critical(void);
>
> -/**
> - * debug_stop_all() - stops the debug feature if stopping is allowed.
> - *
> - * Return:
> - * - none
> - */
> void debug_stop_all(void);
>
> /**
> @@ -184,7 +126,7 @@ static inline bool debug_level_enabled(debug_info_t *id, int level)
> }
>
> /**
> - * debug_event() - writes debug entry to active debug area
> + * debug_event() - writes binary debug entry to active debug area
> * (if level <= actual debug level)
> *
> * @id: handle for debug log
> @@ -194,6 +136,7 @@ static inline bool debug_level_enabled(debug_info_t *id, int level)
> *
> * Return:
> * - Address of written debug entry
> + * - %NULL if error
> */
> static inline debug_entry_t *debug_event(debug_info_t *id, int level,
> void *data, int length)
> @@ -204,7 +147,7 @@ static inline debug_entry_t *debug_event(debug_info_t *id, int level,
> }
>
> /**
> - * debug_int_event() - writes debug entry to active debug area
> + * debug_int_event() - writes unsigned integer debug entry to active debug area
> * (if level <= actual debug level)
> *
> * @id: handle for debug log
> @@ -226,12 +169,12 @@ static inline debug_entry_t *debug_int_event(debug_info_t *id, int level,
> }
>
> /**
> - * debug_long_event() - writes debug entry to active debug area
> + * debug_long_event() - writes unsigned long debug entry to active debug area
> * (if level <= actual debug level)
> *
> * @id: handle for debug log
> * @level: debug level
> - * @tag: integer value for debug entry
> + * @tag: long integer value for debug entry
> *
> * Return:
> * - Address of written debug entry
> @@ -248,7 +191,7 @@ static inline debug_entry_t *debug_long_event(debug_info_t *id, int level,
> }
>
> /**
> - * debug_text_event() - writes debug entry in ascii format to active
> + * debug_text_event() - writes string debug entry in ascii format to active
> * debug area (if level <= actual debug level)
> *
> * @id: handle for debug log
> @@ -306,9 +249,9 @@ static inline debug_entry_t *debug_text_event(debug_info_t *id, int level,
> })
>
> /**
> - * debug_exception() - writes debug entry to active debug area
> - * (if level <= actual debug level) and switches
> - * to next debug area
> + * debug_exception() - writes binary debug entry to active debug area
> + * (if level <= actual debug level)
> + * and switches to next debug area
> *
> * @id: handle for debug log
> * @level: debug level
> @@ -328,7 +271,7 @@ static inline debug_entry_t *debug_exception(debug_info_t *id, int level,
> }
>
> /**
> - * debug_int_exception() - writes debug entry to active debug area
> + * debug_int_exception() - writes unsigned int debug entry to active debug area
> * (if level <= actual debug level)
> * and switches to next debug area
> *
> @@ -351,13 +294,13 @@ static inline debug_entry_t *debug_int_exception(debug_info_t *id, int level,
> }
>
> /**
> - * debug_long_exception() - writes debug entry to active debug area
> + * debug_long_exception() - writes long debug entry to active debug area
> * (if level <= actual debug level)
> * and switches to next debug area
> *
> * @id: handle for debug log
> * @level: debug level
> - * @tag: integer value for debug entry
> + * @tag: long integer value for debug entry
> *
> * Return:
> * - Address of written debug entry
> @@ -374,9 +317,9 @@ static inline debug_entry_t *debug_long_exception (debug_info_t *id, int level,
> }
>
> /**
> - * debug_text_exception() - writes debug entry in ascii format to active
> + * debug_text_exception() - writes string debug entry in ascii format to active
> * debug area (if level <= actual debug level)
> - * and switches to next debug
> + * and switches to next debug area
> * area
> *
> * @id: handle for debug log
> @@ -407,7 +350,7 @@ static inline debug_entry_t *debug_text_exception(debug_info_t *id, int level,
> /**
> * debug_sprintf_exception() - writes debug entry with format string and
> * varargs (longs) to active debug area
> - * (if level $<=$ actual debug level)
> + * (if level <= actual debug level)
> * and switches to next debug area.
> *
> * @_id: handle for debug log
> @@ -435,33 +378,8 @@ static inline debug_entry_t *debug_text_exception(debug_info_t *id, int level,
> __ret; \
> })
>
> -/**
> - * debug_register_view() - registers new debug view and creates debugfs
> - * dir entry
> - *
> - * @id: handle for debug log
> - * @view: pointer to debug view struct
> - *
> - * Return:
> - * - 0 : ok
> - * - < 0: Error
> - */
> int debug_register_view(debug_info_t *id, struct debug_view *view);
>
> -/**
> - * debug_unregister_view()
> - *
> - * @id: handle for debug log
> - * @view: pointer to debug view struct
> - *
> - * Return:
> - * - 0 : ok
> - * - < 0: Error
> - *
> - *
> - * unregisters debug view and removes debugfs dir entry
> - */
> -
> int debug_unregister_view(debug_info_t *id, struct debug_view *view);
>
> /*
> diff --git a/arch/s390/kernel/debug.c b/arch/s390/kernel/debug.c
> index 0ebf08c3b35e..70a44bad625f 100644
> --- a/arch/s390/kernel/debug.c
> +++ b/arch/s390/kernel/debug.c
> @@ -647,11 +647,23 @@ static int debug_close(struct inode *inode, struct file *file)
> return 0; /* success */
> }
>
> -/*
> - * debug_register_mode:
> - * - Creates and initializes debug area for the caller
> - * The mode parameter allows to specify access rights for the s390dbf files
> - * - Returns handle for debug area
> +/**
> + * debug_register_mode() - creates and initializes debug area.
> + *
> + * @name: Name of debug log (e.g. used for debugfs entry)
> + * @pages_per_area: Number of pages, which will be allocated per area
> + * @nr_areas: Number of debug areas
> + * @buf_size: Size of data area in each debug entry
> + * @mode: File mode for debugfs files. E.g. S_IRWXUGO
> + * @uid: User ID for debugfs files. Currently only 0 is supported.
> + * @gid: Group ID for debugfs files. Currently only 0 is supported.
> + *
> + * Return:
> + * - Handle for generated debug area
> + * - %NULL if register failed
> + *
> + * Allocates memory for a debug log.
> + * Must not be called within an interrupt handler.
> */
> debug_info_t *debug_register_mode(const char *name, int pages_per_area,
> int nr_areas, int buf_size, umode_t mode,
> @@ -681,10 +693,21 @@ debug_info_t *debug_register_mode(const char *name, int pages_per_area,
> }
> EXPORT_SYMBOL(debug_register_mode);
>
> -/*
> - * debug_register:
> - * - creates and initializes debug area for the caller
> - * - returns handle for debug area
> +/**
> + * debug_register() - creates and initializes debug area with default file mode.
> + *
> + * @name: Name of debug log (e.g. used for debugfs entry)
> + * @pages_per_area: Number of pages, which will be allocated per area
> + * @nr_areas: Number of debug areas
> + * @buf_size: Size of data area in each debug entry
> + *
> + * Return:
> + * - Handle for generated debug area
> + * - %NULL if register failed
> + *
> + * Allocates memory for a debug log.
> + * The debugfs file mode access permisions are read and write for user.
> + * Must not be called within an interrupt handler.
> */
> debug_info_t *debug_register(const char *name, int pages_per_area,
> int nr_areas, int buf_size)
> @@ -694,9 +717,13 @@ debug_info_t *debug_register(const char *name, int pages_per_area,
> }
> EXPORT_SYMBOL(debug_register);
>
> -/*
> - * debug_unregister:
> - * - give back debug area
> +/**
> + * debug_unregister() - give back debug area.
> + *
> + * @id: handle for debug log
> + *
> + * Return:
> + * none
> */
> void debug_unregister(debug_info_t *id)
> {
> @@ -745,9 +772,14 @@ static int debug_set_size(debug_info_t *id, int nr_areas, int pages_per_area)
> return rc;
> }
>
> -/*
> - * debug_set_level:
> - * - set actual debug level
> +/**
> + * debug_set_level() - Sets new actual debug level if new_level is valid.
> + *
> + * @id: handle for debug log
> + * @new_level: new debug level
> + *
> + * Return:
> + * none
> */
> void debug_set_level(debug_info_t *id, int new_level)
> {
> @@ -873,6 +905,14 @@ static int s390dbf_procactive(struct ctl_table *table, int write,
>
> static struct ctl_table_header *s390dbf_sysctl_header;
>
> +/**
> + * debug_stop_all() - stops the debug feature if stopping is allowed.
> + *
> + * Return:
> + * - none
> + *
> + * Currently used in case of a kernel oops.
> + */
> void debug_stop_all(void)
> {
> if (debug_stoppable)
> @@ -880,6 +920,17 @@ void debug_stop_all(void)
> }
> EXPORT_SYMBOL(debug_stop_all);
>
> +/**
> + * debug_set_critical() - event/exception functions try lock instead of spin.
> + *
> + * Return:
> + * - none
> + *
> + * Currently used in case of stopping all CPUs but the current one.
> + * Once in this state, functions to write a debug entry for an
> + * event or exception no longer spin on the debug area lock,
> + * but only try to get it and fail if they do not get the lock.
> + */
> void debug_set_critical(void)
> {
> debug_critical = 1;
> @@ -1036,8 +1087,16 @@ debug_entry_t *__debug_sprintf_exception(debug_info_t *id, int level, char *stri
> }
> EXPORT_SYMBOL(__debug_sprintf_exception);
>
> -/*
> - * debug_register_view:
> +/**
> + * debug_register_view() - registers new debug view and creates debugfs
> + * dir entry
> + *
> + * @id: handle for debug log
> + * @view: pointer to debug view struct
> + *
> + * Return:
> + * - 0 : ok
> + * - < 0: Error
> */
> int debug_register_view(debug_info_t *id, struct debug_view *view)
> {
> @@ -1077,8 +1136,16 @@ int debug_register_view(debug_info_t *id, struct debug_view *view)
> }
> EXPORT_SYMBOL(debug_register_view);
>
> -/*
> - * debug_unregister_view:
> +/**
> + * debug_unregister_view() - unregisters debug view and removes debugfs
> + * dir entry
> + *
> + * @id: handle for debug log
> + * @view: pointer to debug view struct
> + *
> + * Return:
> + * - 0 : ok
> + * - < 0: Error
> */
> int debug_unregister_view(debug_info_t *id, struct debug_view *view)
> {
>
^ permalink raw reply
* Re: [PATCH 3/3] docs: s390: s390dbf: typos and formatting, update crash command
From: Christian Borntraeger @ 2019-07-05 10:54 UTC (permalink / raw)
To: Steffen Maier, linux-doc
Cc: linux-s390, Mauro Carvalho Chehab, Mauro Carvalho Chehab,
Heiko Carstens, Vasily Gorbik, linux-kernel
In-Reply-To: <1562149189-1417-4-git-send-email-maier@linux.ibm.com>
On 03.07.19 12:19, Steffen Maier wrote:
> Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> Documentation/s390/s390dbf.rst | 122 +++++++++++++++++++++++------------------
> 1 file changed, 68 insertions(+), 54 deletions(-)
>
> diff --git a/Documentation/s390/s390dbf.rst b/Documentation/s390/s390dbf.rst
> index be42892b159e..cdb36842b898 100644
> --- a/Documentation/s390/s390dbf.rst
> +++ b/Documentation/s390/s390dbf.rst
> @@ -23,7 +23,8 @@ The debug feature may also very useful for kernel and driver development.
> Design:
> -------
> Kernel components (e.g. device drivers) can register themselves at the debug
> -feature with the function call debug_register(). This function initializes a
> +feature with the function call :c:func:`debug_register()`.
> +This function initializes a
> debug log for the caller. For each debug log exists a number of debug areas
> where exactly one is active at one time. Each debug area consists of contiguous
> pages in memory. In the debug areas there are stored debug entries (log records)
> @@ -44,8 +45,9 @@ The debug areas themselves are also ordered in form of a ring buffer.
> When an exception is thrown in the last debug area, the following debug
> entries are then written again in the very first area.
>
> -There are three versions for the event- and exception-calls: One for
> -logging raw data, one for text and one for numbers.
> +There are four versions for the event- and exception-calls: One for
> +logging raw data, one for text, one for numbers (unsigned int and long),
> +and one for sprintf-like formatted strings.
>
> Each debug entry contains the following data:
>
> @@ -56,29 +58,29 @@ Each debug entry contains the following data:
> - Flag, if entry is an exception or not
>
> The debug logs can be inspected in a live system through entries in
> -the debugfs-filesystem. Under the toplevel directory "s390dbf" there is
> +the debugfs-filesystem. Under the toplevel directory "``s390dbf``" there is
> a directory for each registered component, which is named like the
> corresponding component. The debugfs normally should be mounted to
> -/sys/kernel/debug therefore the debug feature can be accessed under
> -/sys/kernel/debug/s390dbf.
> +``/sys/kernel/debug`` therefore the debug feature can be accessed under
> +``/sys/kernel/debug/s390dbf``.
>
> The content of the directories are files which represent different views
> to the debug log. Each component can decide which views should be
> -used through registering them with the function debug_register_view().
> +used through registering them with the function :c:func:`debug_register_view()`.
> Predefined views for hex/ascii, sprintf and raw binary data are provided.
> It is also possible to define other views. The content of
> a view can be inspected simply by reading the corresponding debugfs file.
>
> All debug logs have an actual debug level (range from 0 to 6).
> -The default level is 3. Event and Exception functions have a 'level'
> +The default level is 3. Event and Exception functions have a :c:data:`level`
> parameter. Only debug entries with a level that is lower or equal
> than the actual level are written to the log. This means, when
> writing events, high priority log entries should have a low level
> value whereas low priority entries should have a high one.
> The actual debug level can be changed with the help of the debugfs-filesystem
> -through writing a number string "x" to the 'level' debugfs file which is
> +through writing a number string "x" to the ``level`` debugfs file which is
> provided for every debug log. Debugging can be switched off completely
> -by using "-" on the 'level' debugfs file.
> +by using "-" on the ``level`` debugfs file.
>
> Example::
>
> @@ -86,21 +88,21 @@ Example::
>
> It is also possible to deactivate the debug feature globally for every
> debug log. You can change the behavior using 2 sysctl parameters in
> -/proc/sys/s390dbf:
> +``/proc/sys/s390dbf``:
>
> There are currently 2 possible triggers, which stop the debug feature
> -globally. The first possibility is to use the "debug_active" sysctl. If
> -set to 1 the debug feature is running. If "debug_active" is set to 0 the
> +globally. The first possibility is to use the ``debug_active`` sysctl. If
> +set to 1 the debug feature is running. If ``debug_active`` is set to 0 the
> debug feature is turned off.
>
> The second trigger which stops the debug feature is a kernel oops.
> That prevents the debug feature from overwriting debug information that
> happened before the oops. After an oops you can reactivate the debug feature
> -by piping 1 to /proc/sys/s390dbf/debug_active. Nevertheless, its not
> +by piping 1 to ``/proc/sys/s390dbf/debug_active``. Nevertheless, it's not
> suggested to use an oopsed kernel in a production environment.
>
> If you want to disallow the deactivation of the debug feature, you can use
> -the "debug_stoppable" sysctl. If you set "debug_stoppable" to 0 the debug
> +the ``debug_stoppable`` sysctl. If you set ``debug_stoppable`` to 0 the debug
> feature cannot be stopped. If the debug feature is already stopped, it
> will stay deactivated.
>
> @@ -113,16 +115,18 @@ Kernel Interfaces:
> Predefined views:
> -----------------
>
> -extern struct debug_view debug_hex_ascii_view;
> +.. code-block:: c
>
> -extern struct debug_view debug_raw_view;
> + extern struct debug_view debug_hex_ascii_view;
>
> -extern struct debug_view debug_sprintf_view;
> + extern struct debug_view debug_raw_view;
> +
> + extern struct debug_view debug_sprintf_view;
>
> Examples
> --------
>
> -::
> +.. code-block:: c
>
> /*
> * hex_ascii- + raw-view Example
> @@ -131,15 +135,15 @@ Examples
> #include <linux/init.h>
> #include <asm/debug.h>
>
> - static debug_info_t* debug_info;
> + static debug_info_t *debug_info;
>
> static int init(void)
> {
> /* register 4 debug areas with one page each and 4 byte data field */
>
> - debug_info = debug_register ("test", 1, 4, 4 );
> - debug_register_view(debug_info,&debug_hex_ascii_view);
> - debug_register_view(debug_info,&debug_raw_view);
> + debug_info = debug_register("test", 1, 4, 4 );
> + debug_register_view(debug_info, &debug_hex_ascii_view);
> + debug_register_view(debug_info, &debug_raw_view);
>
> debug_text_event(debug_info, 4 , "one ");
> debug_int_exception(debug_info, 4, 4711);
> @@ -150,13 +154,13 @@ Examples
>
> static void cleanup(void)
> {
> - debug_unregister (debug_info);
> + debug_unregister(debug_info);
> }
>
> module_init(init);
> module_exit(cleanup);
>
> -::
> +.. code-block:: c
>
> /*
> * sprintf-view Example
> @@ -165,15 +169,15 @@ Examples
> #include <linux/init.h>
> #include <asm/debug.h>
>
> - static debug_info_t* debug_info;
> + static debug_info_t *debug_info;
>
> static int init(void)
> {
> /* register 4 debug areas with one page each and data field for */
> /* format string pointer + 2 varargs (= 3 * sizeof(long)) */
>
> - debug_info = debug_register ("test", 1, 4, sizeof(long) * 3);
> - debug_register_view(debug_info,&debug_sprintf_view);
> + debug_info = debug_register("test", 1, 4, sizeof(long) * 3);
> + debug_register_view(debug_info, &debug_sprintf_view);
>
> debug_sprintf_event(debug_info, 2 , "first event in %s:%i\n",__FILE__,__LINE__);
> debug_sprintf_exception(debug_info, 1, "pointer to debug info: %p\n",&debug_info);
> @@ -183,7 +187,7 @@ Examples
>
> static void cleanup(void)
> {
> - debug_unregister (debug_info);
> + debug_unregister(debug_info);
> }
>
> module_init(init);
> @@ -252,7 +256,7 @@ Define 4 pages for the debug areas of debug feature "dasd"::
>
> > echo "4" > /sys/kernel/debug/s390dbf/dasd/pages
>
> -Stooping the debug feature
> +Stopping the debug feature
> --------------------------
> Example:
>
> @@ -264,10 +268,11 @@ Example:
>
> > echo 0 > /proc/sys/s390dbf/debug_active
>
> -lcrash Interface
> +crash Interface
> ----------------
> -It is planned that the dump analysis tool lcrash gets an additional command
> -'s390dbf' to display all the debug logs. With this tool it will be possible
> +The ``crash`` tool since v5.1.0 has a built-in command
> +``s390dbf`` to display all the debug logs or export them to the file system.
> +With this tool it is possible
> to investigate the debug logs on a live system and with a memory dump after
> a system crash.
>
> @@ -276,8 +281,8 @@ Investigating raw memory
> One last possibility to investigate the debug logs at a live
> system and after a system crash is to look at the raw memory
> under VM or at the Service Element.
> -It is possible to find the anker of the debug-logs through
> -the 'debug_area_first' symbol in the System map. Then one has
> +It is possible to find the anchor of the debug-logs through
> +the ``debug_area_first`` symbol in the System map. Then one has
> to follow the correct pointers of the data-structures defined
> in debug.h and find the debug-areas in memory.
> Normally modules which use the debug feature will also have
> @@ -286,7 +291,7 @@ this pointer it will also be possible to find the debug logs in
> memory.
>
> For this method it is recommended to use '16 * x + 4' byte (x = 0..n)
> -for the length of the data field in debug_register() in
> +for the length of the data field in :c:func:`debug_register()` in
> order to see the debug entries well formatted.
>
>
> @@ -295,7 +300,7 @@ Predefined Views
>
> There are three predefined views: hex_ascii, raw and sprintf.
> The hex_ascii view shows the data field in hex and ascii representation
> -(e.g. '45 43 4b 44 | ECKD').
> +(e.g. ``45 43 4b 44 | ECKD``).
> The raw view returns a bytestream as the debug areas are stored in memory.
>
> The sprintf view formats the debug entries in the same way as the sprintf
> @@ -335,18 +340,20 @@ The format of the raw view is:
> - datafield
>
> A typical line of the hex_ascii view will look like the following (first line
> -is only for explanation and will not be displayed when 'cating' the view):
> +is only for explanation and will not be displayed when 'cating' the view)::
>
> -area time level exception cpu caller data (hex + ascii)
> ---------------------------------------------------------------------------
> -00 00964419409:440690 1 - 00 88023fe
> + area time level exception cpu caller data (hex + ascii)
> + --------------------------------------------------------------------------
> + 00 00964419409:440690 1 - 00 88023fe
>
>
> Defining views
> --------------
>
> Views are specified with the 'debug_view' structure. There are defined
> -callback functions which are used for reading and writing the debugfs files::
> +callback functions which are used for reading and writing the debugfs files:
> +
> +.. code-block:: c
>
> struct debug_view {
> char name[DEBUG_MAX_PROCF_LEN];
> @@ -357,7 +364,9 @@ callback functions which are used for reading and writing the debugfs files::
> void* private_data;
> };
>
> -where::
> +where:
> +
> +.. code-block:: c
>
> typedef int (debug_header_proc_t) (debug_info_t* id,
> struct debug_view* view,
> @@ -395,10 +404,10 @@ Then 'header_proc' and 'format_proc' are called for each
> existing debug entry.
>
> The input_proc can be used to implement functionality when it is written to
> -the view (e.g. like with 'echo "0" > /sys/kernel/debug/s390dbf/dasd/level).
> +the view (e.g. like with ``echo "0" > /sys/kernel/debug/s390dbf/dasd/level``).
>
> For header_proc there can be used the default function
> -debug_dflt_header_fn() which is defined in debug.h.
> +:c:func:`debug_dflt_header_fn()` which is defined in debug.h.
> and which produces the same header output as the predefined views.
> E.g::
>
> @@ -407,7 +416,9 @@ E.g::
> In order to see how to use the callback functions check the implementation
> of the default views!
>
> -Example::
> +Example:
> +
> +.. code-block:: c
>
> #include <asm/debug.h>
>
> @@ -423,21 +434,20 @@ Example::
> };
>
> static int debug_test_format_fn(
> - debug_info_t * id, struct debug_view *view,
> + debug_info_t *id, struct debug_view *view,
> char *out_buf, const char *in_buf
> )
> {
> int i, rc = 0;
>
> - if(id->buf_size >= 4) {
> + if (id->buf_size >= 4) {
> int msg_nr = *((int*)in_buf);
> - if(msg_nr < sizeof(messages)/sizeof(char*) - 1)
> + if (msg_nr < sizeof(messages) / sizeof(char*) - 1)
> rc += sprintf(out_buf, "%s", messages[msg_nr]);
> else
> rc += sprintf(out_buf, UNKNOWNSTR, msg_nr);
> }
> - out:
> - return rc;
> + return rc;
> }
>
> struct debug_view debug_test_view = {
> @@ -452,13 +462,17 @@ Example::
> test:
> =====
>
> -::
> +.. code-block:: c
>
> debug_info_t *debug_info;
> + int i;
> ...
> - debug_info = debug_register ("test", 0, 4, 4 ));
> + debug_info = debug_register("test", 0, 4, 4);
> debug_register_view(debug_info, &debug_test_view);
> - for(i = 0; i < 10; i ++) debug_int_event(debug_info, 1, i);
> + for (i = 0; i < 10; i ++)
> + debug_int_event(debug_info, 1, i);
> +
> +::
>
> > cat /sys/kernel/debug/s390dbf/test/myview
> 00 00964419734:611402 1 - 00 88042ca This error...........
>
^ permalink raw reply
* Re: [PATCH 2/3] docs: s390: unify and update s390dbf kdocs at debug.c
From: Vasily Gorbik @ 2019-07-05 12:27 UTC (permalink / raw)
To: Steffen Maier
Cc: linux-doc, linux-s390, Mauro Carvalho Chehab,
Mauro Carvalho Chehab, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-kernel
In-Reply-To: <1562149189-1417-3-git-send-email-maier@linux.ibm.com>
On Wed, Jul 03, 2019 at 12:19:48PM +0200, Steffen Maier wrote:
> For non-static-inlines, debug.c already had non-compliant function
> header docs. So move the pure prototype kdocs of
> ("s390: include/asm/debug.h add kerneldoc markups")
> from debug.h to debug.c and merge them with the old function docs.
> Also, I had the impression that kdoc typically is at the implementation
> in the compile unit rather than at the prototype in the header file.
>
> While at it, update the short kdoc description to distinguish the
> different functions. And a few more consistency cleanups.
>
> Added a new kdoc for debug_set_critical() since debug.h comments it
> as part of the API.
>
> Signed-off-by: Steffen Maier <maier@linux.ibm.com>
> ---
> Documentation/s390/s390dbf.rst | 1 +
> arch/s390/include/asm/debug.h | 112 ++++++-----------------------------------
> arch/s390/kernel/debug.c | 105 +++++++++++++++++++++++++++++++-------
> 3 files changed, 102 insertions(+), 116 deletions(-)
>
Applied with "permisions->permissions" and couple of whitespaces removed, thanks.
^ permalink raw reply
* Re: [PATCH 0/3] docs: s390: restore content and update s390dbf.rst
From: Vasily Gorbik @ 2019-07-05 12:28 UTC (permalink / raw)
To: Steffen Maier
Cc: linux-doc, linux-s390, Mauro Carvalho Chehab,
Mauro Carvalho Chehab, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-kernel
In-Reply-To: <1562149189-1417-1-git-send-email-maier@linux.ibm.com>
On Wed, Jul 03, 2019 at 12:19:46PM +0200, Steffen Maier wrote:
> This is based on top of the 3 s390 patches Heiko already queued on our
> s390 features branch.
> [("Re: [PATCH v3 00/33] Convert files to ReST - part 1")
> https://www.spinics.net/lists/linux-doc/msg66137.html
> https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/log/Documentation/s390?h=features]
>
> If I was not mistaken, some documentation was accidentally lost
> and patch 1 restores it.
>
> After having looked closer, I came up with patches 2 and 3.
> Rendered successfully on a current Fedora 30 and it looks good:
> $ make SPHINXDIRS="s390" htmldocs
>
> Steffen Maier (3):
> docs: s390: restore important non-kdoc parts of s390dbf.rst
> docs: s390: unify and update s390dbf kdocs at debug.c
> docs: s390: s390dbf: typos and formatting, update crash command
>
> Documentation/s390/s390dbf.rst | 390 +++++++++++++++++++++++++++++++++++++++--
> arch/s390/include/asm/debug.h | 112 ++----------
> arch/s390/kernel/debug.c | 105 +++++++++--
> 3 files changed, 473 insertions(+), 134 deletions(-)
>
> --
> 1.8.3.1
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v12 01/11] MODSIGN: Export module signature definitions
From: Philipp Rudo @ 2019-07-05 13:00 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: Jessica Yu, linux-integrity, linux-security-module, keyrings,
linux-crypto, linuxppc-dev, linux-doc, linux-kernel, Mimi Zohar,
Dmitry Kasatkin, James Morris, Serge E. Hallyn, David Howells,
David Woodhouse, Herbert Xu, David S. Miller, Jonathan Corbet,
AKASHI, Takahiro, Heiko Carstens, linux-s390
In-Reply-To: <874l41ocf5.fsf@morokweng.localdomain>
Hi Thiago,
On Thu, 04 Jul 2019 15:57:34 -0300
Thiago Jung Bauermann <bauerman@linux.ibm.com> wrote:
> Hello Philipp,
>
> Philipp Rudo <prudo@linux.ibm.com> writes:
>
> > Hi Thiago,
> >
> >
> > On Thu, 04 Jul 2019 03:42:57 -0300
> > Thiago Jung Bauermann <bauerman@linux.ibm.com> wrote:
> >
> >> Jessica Yu <jeyu@kernel.org> writes:
> >>
> >> > +++ Thiago Jung Bauermann [27/06/19 23:19 -0300]:
> >> >>IMA will use the module_signature format for append signatures, so export
> >> >>the relevant definitions and factor out the code which verifies that the
> >> >>appended signature trailer is valid.
> >> >>
> >> >>Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it
> >> >>and be able to use mod_check_sig() without having to depend on either
> >> >>CONFIG_MODULE_SIG or CONFIG_MODULES.
> >> >>
> >> >>Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> >> >>Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> >> >>Cc: Jessica Yu <jeyu@kernel.org>
> >> >>---
> >> >> include/linux/module.h | 3 --
> >> >> include/linux/module_signature.h | 44 +++++++++++++++++++++++++
> >> >> init/Kconfig | 6 +++-
> >> >> kernel/Makefile | 1 +
> >> >> kernel/module.c | 1 +
> >> >> kernel/module_signature.c | 46 ++++++++++++++++++++++++++
> >> >> kernel/module_signing.c | 56 +++++---------------------------
> >> >> scripts/Makefile | 2 +-
> >> >> 8 files changed, 106 insertions(+), 53 deletions(-)
> >> >>
> >> >>diff --git a/include/linux/module.h b/include/linux/module.h
> >> >>index 188998d3dca9..aa56f531cf1e 100644
> >> >>--- a/include/linux/module.h
> >> >>+++ b/include/linux/module.h
> >> >>@@ -25,9 +25,6 @@
> >> >> #include <linux/percpu.h>
> >> >> #include <asm/module.h>
> >> >>
> >> >>-/* In stripped ARM and x86-64 modules, ~ is surprisingly rare. */
> >> >>-#define MODULE_SIG_STRING "~Module signature appended~\n"
> >> >>-
> >> >
> >> > Hi Thiago, apologies for the delay.
> >>
> >> Hello Jessica, thanks for reviewing the patch!
> >>
> >> > It looks like arch/s390/kernel/machine_kexec_file.c also relies on
> >> > MODULE_SIG_STRING being defined, so module_signature.h will need to be
> >> > included there too, otherwise we'll run into a compilation error.
> >>
> >> Indeed. Thanks for spotting that. The patch below fixes it. It's
> >> identical to the previous version except for the changes in
> >> arch/s390/kernel/machine_kexec_file.c and their description in the
> >> commit message. I'm also copying some s390 people in this email.
> >
> > to me the s390 part looks good but for one minor nit.
>
> Thanks for the prompt review!
>
> > In arch/s390/Kconfig KEXEC_VERIFY_SIG currently depends on
> > SYSTEM_DATA_VERIFICATION. I'd prefer when you update this to the new
> > MODULE_SIG_FORMAT. It shouldn't make any difference right now, as we don't
> > use mod_check_sig in our code path. But it could cause problems in the future,
> > when more code might be shared.
>
> Makes sense. Here is the updated patch with the Kconfig change.
>
The patch looks good now.
Thanks a lot
PHilipp
^ permalink raw reply
* [Linux-kernel-mentees] [PATCH] Doc : fs : move xfs.txt to admin-guide
From: Sheriff Esseson @ 2019-07-05 13:14 UTC (permalink / raw)
To: skhan
Cc: darrick.wong, linux-xfs, corbet, linux-doc, linux-kernel,
linux-kernel-mentees
As suggested by Matthew Wilcox, xfs.txt is primarily a guide on available
options when setting up an XFS. This makes it appropriate to be placed under
the admin-guide tree.
Thus, move xfs.txt to admin-guide and fix broken references.
Signed-off-by: Sheriff Esseson <sheriffesseson@gmail.com>
---
The reference to xfs.txt from dax.txt in itself is not looking good. Maybe, we
need something more inspirational.
Documentation/{filesystems => admin-guide}/xfs.txt | 0
Documentation/filesystems/dax.txt | 2 +-
MAINTAINERS | 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename Documentation/{filesystems => admin-guide}/xfs.txt (100%)
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/admin-guide/xfs.txt
similarity index 100%
rename from Documentation/filesystems/xfs.txt
rename to Documentation/admin-guide/xfs.txt
diff --git a/Documentation/filesystems/dax.txt b/Documentation/filesystems/dax.txt
index 6d2c0d340..b2b19738b 100644
--- a/Documentation/filesystems/dax.txt
+++ b/Documentation/filesystems/dax.txt
@@ -76,7 +76,7 @@ exposure of uninitialized data through mmap.
These filesystems may be used for inspiration:
- ext2: see Documentation/filesystems/ext2.txt
- ext4: see Documentation/filesystems/ext4/
-- xfs: see Documentation/filesystems/xfs.txt
+- xfs: see Documentation/admin-guide/xfs.txt
Handling Media Errors
diff --git a/MAINTAINERS b/MAINTAINERS
index 01a52fc96..fc309b0a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17374,7 +17374,7 @@ L: linux-xfs@vger.kernel.org
W: http://xfs.org/
T: git git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git
S: Supported
-F: Documentation/filesystems/xfs.txt
+F: Documentation/admin-guide/xfs.txt
F: fs/xfs/
XILINX AXI ETHERNET DRIVER
--
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
2.22.0
^ permalink raw reply related
* [PATCH] docs/pinctrl: fix compile errors in example code
From: Luca Ceresoli @ 2019-07-05 14:30 UTC (permalink / raw)
To: linux-gpio
Cc: Luca Ceresoli, Linus Walleij, Jonathan Corbet, linux-doc,
linux-kernel
The code in the example does not build for a few trivial errors: type
mismatch in callback, missing semicolon. Fix them to help newcomers using
the example as a starting point.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
Documentation/driver-api/pinctl.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/driver-api/pinctl.rst b/Documentation/driver-api/pinctl.rst
index 2bb1bc484278..3d2deaf48841 100644
--- a/Documentation/driver-api/pinctl.rst
+++ b/Documentation/driver-api/pinctl.rst
@@ -638,8 +638,8 @@ group of pins would work something like this::
}
static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector,
- unsigned ** const pins,
- unsigned * const num_pins)
+ const unsigned ** pins,
+ unsigned * num_pins)
{
*pins = (unsigned *) foo_groups[selector].pins;
*num_pins = foo_groups[selector].num_pins;
@@ -705,7 +705,7 @@ group of pins would work something like this::
{
u8 regbit = (1 << selector + group);
- writeb((readb(MUX)|regbit), MUX)
+ writeb((readb(MUX)|regbit), MUX);
return 0;
}
--
2.22.0
^ permalink raw reply related
* [PATCH] Documentation: usb: convert usb-help to rst
From: Phong Tran @ 2019-07-05 18:55 UTC (permalink / raw)
To: corbet, gregkh, skhan, mchehab
Cc: linux-kernel-mentees, linux-usb, linux-doc, linux-kernel,
Phong Tran
Add new index.rst and change usb-help.txt format
to rst.
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
---
Documentation/index.rst | 1 +
Documentation/usb/index.rst | 22 ++++++++++++++++++++++
Documentation/usb/{usb-help.txt => usb-help.rst} | 1 -
3 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 Documentation/usb/index.rst
rename Documentation/usb/{usb-help.txt => usb-help.rst} (97%)
diff --git a/Documentation/index.rst b/Documentation/index.rst
index a7566ef62411..4e7498f39063 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -102,6 +102,7 @@ needed).
vm/index
bpf/index
misc-devices/index
+ usb/index
Architecture-specific documentation
-----------------------------------
diff --git a/Documentation/usb/index.rst b/Documentation/usb/index.rst
new file mode 100644
index 000000000000..5688ceaf0826
--- /dev/null
+++ b/Documentation/usb/index.rst
@@ -0,0 +1,22 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Linux USB Subsystem Documentation
+===================================
+
+.. only:: html
+
+ .. class:: toc-title
+
+ Table of Contents
+
+.. toctree::
+ :maxdepth: 2
+
+ usb-help
+
+.. only:: html and subproject
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/usb/usb-help.txt b/Documentation/usb/usb-help.rst
similarity index 97%
rename from Documentation/usb/usb-help.txt
rename to Documentation/usb/usb-help.rst
index dc23ecd4d802..03abc4e501ae 100644
--- a/Documentation/usb/usb-help.txt
+++ b/Documentation/usb/usb-help.rst
@@ -1,4 +1,3 @@
-==============
USB references
==============
--
2.11.0
^ permalink raw reply related
* [PATCH] Documentation: dev-tools: Fixed an outdated directory path in gcov.rst
From: Jeffrin Jose T @ 2019-07-05 19:02 UTC (permalink / raw)
To: oberpar, corbet, linux-doc
Cc: linux-kernel, clang-built-linux, Jeffrin Jose T
Fixed an outdated directory path inside gcov related documentation
which is part of an example that shows the way in which the gcov
command should be used in that context
Signed-off-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in>
---
Documentation/dev-tools/gcov.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/dev-tools/gcov.rst b/Documentation/dev-tools/gcov.rst
index 46aae52a41d0..e3d262d8c7de 100644
--- a/Documentation/dev-tools/gcov.rst
+++ b/Documentation/dev-tools/gcov.rst
@@ -8,7 +8,7 @@ To get coverage data for a specific file, change to the kernel build
directory and use gcov with the ``-o`` option as follows (requires root)::
# cd /tmp/linux-out
- # gcov -o /sys/kernel/debug/gcov/tmp/linux-out/kernel spinlock.c
+ # gcov -o /sys/kernel/debug/gcov/tmp/linux-out/kernel/locking spinlock.c
This will create source code files annotated with execution counts
in the current directory. In addition, graphical gcov front-ends such
--
2.20.1
^ permalink raw reply related
* Re: [Linux-kernel-mentees] [PATCH] Doc : fs : move xfs.txt to admin-guide
From: Matthew Wilcox @ 2019-07-05 19:04 UTC (permalink / raw)
To: Sheriff Esseson
Cc: skhan, darrick.wong, linux-xfs, corbet, linux-doc, linux-kernel,
linux-kernel-mentees
In-Reply-To: <20190705131446.GA10045@localhost>
On Fri, Jul 05, 2019 at 02:14:46PM +0100, Sheriff Esseson wrote:
> As suggested by Matthew Wilcox, xfs.txt is primarily a guide on available
> options when setting up an XFS. This makes it appropriate to be placed under
> the admin-guide tree.
>
> Thus, move xfs.txt to admin-guide and fix broken references.
What happened to the conversion to xfs.rst?
^ 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