* [PATCH 08/22] docs: bpf: get rid of two warnings
From: Mauro Carvalho Chehab @ 2019-05-29 23:23 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, netdev, bpf
In-Reply-To: <cover.1559171394.git.mchehab+samsung@kernel.org>
Documentation/bpf/btf.rst:154: WARNING: Unexpected indentation.
Documentation/bpf/btf.rst:163: WARNING: Unexpected indentation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/bpf/btf.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
index 8820360d00da..4ae022d274ab 100644
--- a/Documentation/bpf/btf.rst
+++ b/Documentation/bpf/btf.rst
@@ -151,6 +151,7 @@ for the type. The maximum value of ``BTF_INT_BITS()`` is 128.
The ``BTF_INT_OFFSET()`` specifies the starting bit offset to calculate values
for this int. For example, a bitfield struct member has:
+
* btf member bit offset 100 from the start of the structure,
* btf member pointing to an int type,
* the int type has ``BTF_INT_OFFSET() = 2`` and ``BTF_INT_BITS() = 4``
@@ -160,6 +161,7 @@ from bits ``100 + 2 = 102``.
Alternatively, the bitfield struct member can be the following to access the
same bits as the above:
+
* btf member bit offset 102,
* btf member pointing to an int type,
* the int type has ``BTF_INT_OFFSET() = 0`` and ``BTF_INT_BITS() = 4``
--
2.21.0
^ permalink raw reply related
* [PATCH 11/22] gpu: amdgpu: fix broken amdgpu_dma_buf.c references
From: Mauro Carvalho Chehab @ 2019-05-29 23:23 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, David Airlie, Daniel Vetter, Maarten Lankhorst,
Maxime Ripard, Sean Paul, dri-devel
In-Reply-To: <cover.1559171394.git.mchehab+samsung@kernel.org>
This file was renamed, but docs weren't updated accordingly.
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function PRIME Buffer Sharing ./drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c' failed with return code 1
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c' failed with return code 2
Fixes: 988076cd8c5c ("drm/amdgpu: rename amdgpu_prime.[ch] into amdgpu_dma_buf.[ch]")
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/gpu/amdgpu.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst
index a740e491dfcc..a15199b1b02e 100644
--- a/Documentation/gpu/amdgpu.rst
+++ b/Documentation/gpu/amdgpu.rst
@@ -37,10 +37,10 @@ Buffer Objects
PRIME Buffer Sharing
--------------------
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
:doc: PRIME Buffer Sharing
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
:internal:
MMU Notifier
--
2.21.0
^ permalink raw reply related
* [PATCH 04/22] docs: zh_CN: get rid of basic_profiling.txt
From: Mauro Carvalho Chehab @ 2019-05-29 23:23 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Harry Wei, Alex Shi
In-Reply-To: <cover.1559171394.git.mchehab+samsung@kernel.org>
Changeset 5700d1974818 ("docs: Get rid of the "basic profiling" guide")
removed an old basic-profiling.txt file that was not updated over
the last 11 years and won't reflect the post-perf era.
It makes no sense to keep its translation, so get rid of it too.
Fixes: 5700d1974818 ("docs: Get rid of the "basic profiling" guide")
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
.../translations/zh_CN/basic_profiling.txt | 71 -------------------
1 file changed, 71 deletions(-)
delete mode 100644 Documentation/translations/zh_CN/basic_profiling.txt
diff --git a/Documentation/translations/zh_CN/basic_profiling.txt b/Documentation/translations/zh_CN/basic_profiling.txt
deleted file mode 100644
index 1e6bf0bdf8f5..000000000000
--- a/Documentation/translations/zh_CN/basic_profiling.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-Chinese translated version of Documentation/basic_profiling
-
-If you have any comment or update to the content, please post to LKML directly.
-However, if you have problem communicating in English you can also ask the
-Chinese maintainer for help. Contact the Chinese maintainer, if this
-translation is outdated or there is problem with translation.
-
-Chinese maintainer: Liang Xie <xieliang@xiaomi.com>
----------------------------------------------------------------------
-Documentation/basic_profiling的中文翻译
-
-如果想评论或更新本文的内容，请直接发信到LKML。如果你使用英文交流有困难的话，也可
-以向中文版维护者求助。如果本翻译更新不及时或者翻译存在问题，请联系中文版维护者。
-
-中文版维护者： 谢良 Liang Xie <xieliang007@gmail.com>
-中文版翻译者： 谢良 Liang Xie <xieliang007@gmail.com>
-中文版校译者：
-以下为正文
----------------------------------------------------------------------
-
-下面这些说明指令都是非常基础的，如果你想进一步了解请阅读相关专业文档：）
-请不要再在本文档增加新的内容，但可以修复文档中的错误：）(mbligh@aracnet.com)
-感谢John Levon，Dave Hansen等在撰写时的帮助
-
-<test> 用于表示要测量的目标
-请先确保您已经有正确的System.map / vmlinux配置！
-
-对于linux系统来说，配置vmlinuz最容易的方法可能就是使用“make install”，然后修改
-/sbin/installkernel将vmlinux拷贝到/boot目录，而System.map通常是默认安装好的
-
-Readprofile
------------
-2.6系列内核需要版本相对较新的readprofile，比如util-linux 2.12a中包含的，可以从:
-
-http://www.kernel.org/pub/linux/utils/util-linux/ 下载
-
-大部分linux发行版已经包含了.
-
-启用readprofile需要在kernel启动命令行增加”profile=2“
-
-clear readprofile -r
- <test>
-dump output readprofile -m /boot/System.map > captured_profile
-
-Oprofile
---------
-
-从http://oprofile.sourceforge.net/获取源代码（请参考Changes以获取匹配的版本）
-在kernel启动命令行增加“idle=poll”
-
-配置CONFIG_PROFILING=y和CONFIG_OPROFILE=y然后重启进入新kernel
-
-./configure --with-kernel-support
-make install
-
-想得到好的测量结果，请确保启用了本地APIC特性。如果opreport显示有0Hz CPU，
-说明APIC特性没有开启。另外注意idle=poll选项可能有损性能。
-
-One time setup:
- opcontrol --setup --vmlinux=/boot/vmlinux
-
-clear opcontrol --reset
-start opcontrol --start
- <test>
-stop opcontrol --stop
-dump output opreport > output_file
-
-如果只看kernel相关的报告结果，请运行命令 opreport -l /boot/vmlinux > output_file
-
-通过reset选项可以清理过期统计数据，相当于重启的效果。
-
--
2.21.0
^ permalink raw reply related
* [PATCH 10/22] docs: amd-memory-encryption.rst get rid of warnings
From: Mauro Carvalho Chehab @ 2019-05-29 23:23 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Paolo Bonzini, Radim Krčmář, kvm
In-Reply-To: <cover.1559171394.git.mchehab+samsung@kernel.org>
Get rid of those warnings:
Documentation/virtual/kvm/amd-memory-encryption.rst:244: WARNING: Citation [white-paper] is not referenced.
Documentation/virtual/kvm/amd-memory-encryption.rst:246: WARNING: Citation [amd-apm] is not referenced.
Documentation/virtual/kvm/amd-memory-encryption.rst:247: WARNING: Citation [kvm-forum] is not referenced.
For references that aren't mentioned at the text by adding an
explicit reference to them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/virtual/kvm/amd-memory-encryption.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/virtual/kvm/amd-memory-encryption.rst b/Documentation/virtual/kvm/amd-memory-encryption.rst
index 33d697ab8a58..6c37ff9a0a3c 100644
--- a/Documentation/virtual/kvm/amd-memory-encryption.rst
+++ b/Documentation/virtual/kvm/amd-memory-encryption.rst
@@ -243,6 +243,9 @@ Returns: 0 on success, -negative on error
References
==========
+
+See [white-paper]_, [api-spec]_, [amd-apm]_ and [kvm-forum]_ for more info.
+
.. [white-paper] http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
.. [api-spec] http://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf
.. [amd-apm] http://support.amd.com/TechDocs/24593.pdf (section 15.34)
--
2.21.0
^ permalink raw reply related
* [PATCH 19/22] docs: security: core.rst: Fix several warnings
From: Mauro Carvalho Chehab @ 2019-05-29 23:23 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, David Howells, keyrings
In-Reply-To: <cover.1559171394.git.mchehab+samsung@kernel.org>
Multi-line literal markups only work when they're idented at the
same level, with is not the case here:
Documentation/security/keys/core.rst:1597: WARNING: Inline literal start-string without end-string.
Documentation/security/keys/core.rst:1597: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1597: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1598: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1598: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1600: WARNING: Inline literal start-string without end-string.
Documentation/security/keys/core.rst:1600: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1600: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1600: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1600: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1666: WARNING: Inline literal start-string without end-string.
Documentation/security/keys/core.rst:1666: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1666: WARNING: Inline emphasis start-string without end-string.
Documentation/security/keys/core.rst:1666: WARNING: Inline emphasis start-string without end-string.
Fix it by using a code-block instead.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/security/keys/core.rst | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst
index 9521c4207f01..3fd60dcb2dc6 100644
--- a/Documentation/security/keys/core.rst
+++ b/Documentation/security/keys/core.rst
@@ -1594,10 +1594,12 @@ The structure has a number of fields, some of which are mandatory:
attempted key link operation. If there is no match, -EINVAL is returned.
- * ``int (*asym_eds_op)(struct kernel_pkey_params *params,
- const void *in, void *out);``
- ``int (*asym_verify_signature)(struct kernel_pkey_params *params,
- const void *in, const void *in2);``
+ * ``asym_eds_op`` and ``asym_verify_signature``::
+
+ int (*asym_eds_op)(struct kernel_pkey_params *params,
+ const void *in, void *out);
+ int (*asym_verify_signature)(struct kernel_pkey_params *params,
+ const void *in, const void *in2);
These methods are optional. If provided the first allows a key to be
used to encrypt, decrypt or sign a blob of data, and the second allows a
@@ -1662,8 +1664,10 @@ The structure has a number of fields, some of which are mandatory:
required crypto isn't available.
- * ``int (*asym_query)(const struct kernel_pkey_params *params,
- struct kernel_pkey_query *info);``
+ * ``asym_query``::
+
+ int (*asym_query)(const struct kernel_pkey_params *params,
+ struct kernel_pkey_query *info);
This method is optional. If provided it allows information about the
public or asymmetric key held in the key to be determined.
--
2.21.0
^ permalink raw reply related
* [PATCH 01/22] ABI: sysfs-devices-system-cpu: point to the right docs
From: Mauro Carvalho Chehab @ 2019-05-29 23:23 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Thomas Gleixner, Jon Masters, Greg Kroah-Hartman,
Borislav Petkov, Josh Poimboeuf, Rafael J. Wysocki, Jiri Kosina
In-Reply-To: <cover.1559171394.git.mchehab+samsung@kernel.org>
The cpuidle doc was split on two, one at the admin guide
and another one at the driver API guide. Instead of pointing
to a non-existent file, point to both (admin guide being
the first one).
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 1528239f69b2..87478ac6c2af 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -137,7 +137,8 @@ Description: Discover cpuidle policy and mechanism
current_governor: (RW) displays current idle policy. Users can
switch the governor at runtime by writing to this file.
- See files in Documentation/cpuidle/ for more information.
+ See Documentation/admin-guide/pm/cpuidle.rst and
+ Documentation/driver-api/pm/cpuidle.rst for more information.
What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/name
--
2.21.0
^ permalink raw reply related
* [PATCH 18/22] docs: security: trusted-encrypted.rst: fix code-block tag
From: Mauro Carvalho Chehab @ 2019-05-29 23:23 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Mimi Zohar, James Bottomley, Jarkko Sakkinen,
linux-integrity, keyrings
In-Reply-To: <cover.1559171394.git.mchehab+samsung@kernel.org>
The code-block tag is at the wrong place, causing those
warnings:
Documentation/security/keys/trusted-encrypted.rst:112: WARNING: Literal block expected; none found.
Documentation/security/keys/trusted-encrypted.rst:121: WARNING: Unexpected indentation.
Documentation/security/keys/trusted-encrypted.rst:122: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/security/keys/trusted-encrypted.rst:123: WARNING: Block quote ends without a blank line; unexpected unindent.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/security/keys/trusted-encrypted.rst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index 7b35fcb58933..50ac8bcd6970 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -107,12 +107,14 @@ Where::
Examples of trusted and encrypted key usage:
-Create and save a trusted key named "kmk" of length 32 bytes::
+Create and save a trusted key named "kmk" of length 32 bytes.
Note: When using a TPM 2.0 with a persistent key with handle 0x81000001,
append 'keyhandle=0x81000001' to statements between quotes, such as
"new 32 keyhandle=0x81000001".
+::
+
$ keyctl add trusted kmk "new 32" @u
440502848
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 21/22] docs: net: sja1105.rst: fix table format
From: Vladimir Oltean @ 2019-05-29 23:26 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, lkml,
Jonathan Corbet, David S. Miller, Florian Fainelli, netdev
In-Reply-To: <c8f6ddd2d538e36f6036681f5756f6ea9499039f.1559171394.git.mchehab+samsung@kernel.org>
On Thu, 30 May 2019 at 02:24, Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> There's a table there with produces two warnings when built
> with Sphinx:
>
> Documentation/networking/dsa/sja1105.rst:91: WARNING: Block quote ends without a blank line; unexpected unindent.
> Documentation/networking/dsa/sja1105.rst:91: WARNING: Block quote ends without a blank line; unexpected unindent.
>
> It will still produce a table, but the html output is wrong, as
> it won't interpret the second line as the continuation for the
> first ones, because identation doesn't match.
>
> After the change, the output looks a way better and we got rid
> of two warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/networking/dsa/sja1105.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/networking/dsa/sja1105.rst b/Documentation/networking/dsa/sja1105.rst
> index ea7bac438cfd..cb2858dece93 100644
> --- a/Documentation/networking/dsa/sja1105.rst
> +++ b/Documentation/networking/dsa/sja1105.rst
> @@ -86,13 +86,13 @@ functionality.
> The following traffic modes are supported over the switch netdevices:
>
> +--------------------+------------+------------------+------------------+
> -| | Standalone | Bridged with | Bridged with |
> -| | ports | vlan_filtering 0 | vlan_filtering 1 |
> +| | Standalone | Bridged with | Bridged with |
> +| | ports | vlan_filtering 0 | vlan_filtering 1 |
> +====================+============+==================+==================+
> | Regular traffic | Yes | Yes | No (use master) |
> +--------------------+------------+------------------+------------------+
> | Management traffic | Yes | Yes | Yes |
> -| (BPDU, PTP) | | | |
> +| (BPDU, PTP) | | | |
> +--------------------+------------+------------------+------------------+
>
> Switching features
> --
> 2.21.0
>
Acked-by: Vladimir Oltean <olteanv@gmail.com>
^ permalink raw reply
* Re: [PATCH 4/5] docs: by default, build docs a lot faster with Sphinx >= 1.7
From: Jonathan Corbet @ 2019-05-29 23:47 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <20190529202005.04dcd4a0@coco.lan>
On Wed, 29 May 2019 20:20:05 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> > So this totally fails to work for me with any version of sphinx, and I'm
> > not enough of a Perl person to figure it out. Sometimes I'll see the
> > sphinx-build output, i.e.:
> >
> > sphinx-build 1.8.4
> >
> > and sometimes (like with 2.0) I don't, but I never get -jauto regardless.
>
> Hmm... with 2.0.0 --version prints the version.
>
> $ sphinx-build --version
> sphinx-build 2.0.0
Yup. The point is that I see the sphinx-build output *in the docs-build
output", not when I run it standalone (where it does the expected thing).
> > Not sure what's going on here?
>
> Do you have SPHINXOPTS already set on your environment? If so, Makefile
> will not override the existing environment.
Yeah, I had it set to -j1 because I want to wait as long as possible for my
docs builds :)
No, I didn't have it set separately, made a point of that.
> Here, if I call it by hand (replacing $$1 by $1), it does the right
> thing. For example:
>
> 1.8.4:
>
> $ sphinx-build --version
> sphinx-build 1.8.4
> $ perl -e 'open IN,"sphinx-build --version |"; while (<IN>) { if (m/([\d\.]+)/) { print "-jauto\n" if ($1 >= "1.7") } ;} close IN'
> -jauto
$ perl -e 'open IN,"sphinx-build --version |"; while (<IN>) { if (m/([\d\.]+)/) { print "-jauto\n" if ($1 >= "1.7") } ;} close IN'
sphinx-build 1.8.4
$
It works properly with 2.0.1 - but only on the command line; I still don't
get the right behavior in a docs build.
Most weird.
This is an Fedora 30 system, FWIW.
jon
^ permalink raw reply
* [PATCH v3 0/4] F2FS Checkpointing without GC, related fixes
From: Daniel Rosenberg @ 2019-05-30 0:49 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu, Jonathan Corbet, linux-f2fs-devel
Cc: linux-kernel, linux-doc, linux-fsdevel, kernel-team,
Daniel Rosenberg
The first patch adjusts the default allowable holes for checkpointing, and
the next two patches fix underflow issues related to inc_valid_block_count
and inc_valid_node_count. The final one adds a new feature for
checkpointing where the user can specify an acceptable amount of space to
lose access to up front in checkpointing=disable mode instead of requiring
garbage collection.
There is still a question around what to do when the current reserved
space is less than reserved. As it stands, when a block is deleted, if it
was an old block, the space is not actually given back, and is marked as
unusable. But current reserve may still rise towards reserve, which would
make freeing one block result in a net loss of one block, as opposed to no
change. Reserved and unusable serve the same function, so it may make
sense to just handle it as max(current_reserved, unusable), which
effectively removes the double counting. I'm leaving that until later.
Changes from v2:
Adjust threshold for initial unusable blocks
Patches to fix underflows
Added option to set a block limit in addition to a percent for initial
unusable space
Daniel Rosenberg (4):
f2fs: Lower threshold for disable_cp_again
f2fs: Fix root reserved on remount
f2fs: Fix accounting for unusable blocks
f2fs: Add option to limit required GC for checkpoint=disable
Documentation/ABI/testing/sysfs-fs-f2fs | 8 ++++
Documentation/filesystems/f2fs.txt | 19 +++++++-
fs/f2fs/f2fs.h | 22 ++++++---
fs/f2fs/segment.c | 21 +++++++--
fs/f2fs/super.c | 62 ++++++++++++++++---------
fs/f2fs/sysfs.c | 16 +++++++
6 files changed, 115 insertions(+), 33 deletions(-)
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply
* [PATCH v3 3/4] f2fs: Fix accounting for unusable blocks
From: Daniel Rosenberg @ 2019-05-30 0:49 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu, Jonathan Corbet, linux-f2fs-devel
Cc: linux-kernel, linux-doc, linux-fsdevel, kernel-team,
Daniel Rosenberg
In-Reply-To: <20190530004906.261170-1-drosen@google.com>
Fixes possible underflows when dealing with unusable blocks.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
---
fs/f2fs/f2fs.h | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 9b3d9977cd1ef..a39cc4ffeb4b1 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1769,8 +1769,12 @@ static inline int inc_valid_block_count(struct f2fs_sb_info *sbi,
if (!__allow_reserved_blocks(sbi, inode, true))
avail_user_block_count -= F2FS_OPTION(sbi).root_reserved_blocks;
- if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED)))
- avail_user_block_count -= sbi->unusable_block_count;
+ if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED))) {
+ if (avail_user_block_count > sbi->unusable_block_count)
+ avail_user_block_count = 0;
+ else
+ avail_user_block_count -= sbi->unusable_block_count;
+ }
if (unlikely(sbi->total_valid_block_count > avail_user_block_count)) {
diff = sbi->total_valid_block_count - avail_user_block_count;
if (diff > *count)
@@ -1970,7 +1974,7 @@ static inline int inc_valid_node_count(struct f2fs_sb_info *sbi,
struct inode *inode, bool is_inode)
{
block_t valid_block_count;
- unsigned int valid_node_count;
+ unsigned int valid_node_count, user_block_count;
int err;
if (is_inode) {
@@ -1997,10 +2001,11 @@ static inline int inc_valid_node_count(struct f2fs_sb_info *sbi,
if (!__allow_reserved_blocks(sbi, inode, false))
valid_block_count += F2FS_OPTION(sbi).root_reserved_blocks;
+ user_block_count = sbi->user_block_count;
if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED)))
- valid_block_count += sbi->unusable_block_count;
+ user_block_count -= sbi->unusable_block_count;
- if (unlikely(valid_block_count > sbi->user_block_count)) {
+ if (unlikely(valid_block_count > user_block_count)) {
spin_unlock(&sbi->stat_lock);
goto enospc;
}
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply related
* [PATCH v3 4/4] f2fs: Add option to limit required GC for checkpoint=disable
From: Daniel Rosenberg @ 2019-05-30 0:49 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu, Jonathan Corbet, linux-f2fs-devel
Cc: linux-kernel, linux-doc, linux-fsdevel, kernel-team,
Daniel Rosenberg
In-Reply-To: <20190530004906.261170-1-drosen@google.com>
This extends the checkpoint option to allow checkpoint=disable:%u[%]
This allows you to specify what how much of the disk you are willing
to lose access to while mounting with checkpoint=disable. If the amount
lost would be higher, the mount will return -EAGAIN. This can be given
as a percent of total space, or in blocks.
Currently, we need to run garbage collection until the amount of holes
is smaller than the OVP space. With the new option, f2fs can mark
space as unusable up front instead of requiring garbage collection until
the number of holes is small enough.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
---
Documentation/ABI/testing/sysfs-fs-f2fs | 8 ++++
Documentation/filesystems/f2fs.txt | 19 +++++++-
fs/f2fs/f2fs.h | 6 ++-
fs/f2fs/segment.c | 17 +++++--
fs/f2fs/super.c | 59 ++++++++++++++++---------
fs/f2fs/sysfs.c | 16 +++++++
6 files changed, 99 insertions(+), 26 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs
index 91822ce258317..dca326e0ee3e1 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -243,3 +243,11 @@ Description:
- Del: echo '[h/c]!extension' > /sys/fs/f2fs/<disk>/extension_list
- [h] means add/del hot file extension
- [c] means add/del cold file extension
+
+What: /sys/fs/f2fs/<disk>/unusable
+Date April 2019
+Contact: "Daniel Rosenberg" <drosen@google.com>
+Description:
+ If checkpoint=disable, it displays the number of blocks that are unusable.
+ If checkpoint=enable it displays the enumber of blocks that would be unusable
+ if checkpoint=disable were to be set.
diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt
index 66aca042988ee..bebd1be3ba495 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -214,11 +214,22 @@ fsync_mode=%s Control the policy of fsync. Currently supports "posix",
non-atomic files likewise "nobarrier" mount option.
test_dummy_encryption Enable dummy encryption, which provides a fake fscrypt
context. The fake fscrypt context is used by xfstests.
-checkpoint=%s Set to "disable" to turn off checkpointing. Set to "enable"
+checkpoint=%s[:%u[%]] Set to "disable" to turn off checkpointing. Set to "enable"
to reenable checkpointing. Is enabled by default. While
disabled, any unmounting or unexpected shutdowns will cause
the filesystem contents to appear as they did when the
filesystem was mounted with that option.
+ While mounting with checkpoint=disabled, the filesystem must
+ run garbage collection to ensure that all available space can
+ be used. If this takes too much time, the mount may return
+ EAGAIN. You may optionally add a value to indicate how much
+ of the disk you would be willing to temporarily give up to
+ avoid additional garbage collection. This can be given as a
+ number of blocks, or as a percent. For instance, mounting
+ with checkpoint=disable:100% would always succeed, but it may
+ hide up to all remaining free space. The actual space that
+ would be unusable can be viewed at /sys/fs/f2fs/<disk>/unusable
+ This space is reclaimed once checkpoint=enable.
================================================================================
DEBUGFS ENTRIES
@@ -396,6 +407,12 @@ Files in /sys/fs/f2fs/<devname>
current_reserved_blocks This shows # of blocks currently reserved.
+ unusable If checkpoint=disable, this shows the number of
+ blocks that are unusable.
+ If checkpoint=enable it shows the number of blocks
+ that would be unusable if checkpoint=disable were
+ to be set.
+
================================================================================
USAGE
================================================================================
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index a39cc4ffeb4b1..11ef20fedfe72 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -136,6 +136,9 @@ struct f2fs_mount_info {
int alloc_mode; /* segment allocation policy */
int fsync_mode; /* fsync policy */
bool test_dummy_encryption; /* test dummy encryption */
+ block_t unusable_cap; /* Amount of space allowed to be
+ * unusable when disabling checkpoint
+ */
};
#define F2FS_FEATURE_ENCRYPT 0x0001
@@ -3085,7 +3088,8 @@ bool f2fs_issue_discard_timeout(struct f2fs_sb_info *sbi);
void f2fs_clear_prefree_segments(struct f2fs_sb_info *sbi,
struct cp_control *cpc);
void f2fs_dirty_to_prefree(struct f2fs_sb_info *sbi);
-int f2fs_disable_cp_again(struct f2fs_sb_info *sbi);
+block_t f2fs_get_unusable_blocks(struct f2fs_sb_info *sbi);
+int f2fs_disable_cp_again(struct f2fs_sb_info *sbi, block_t unusable);
void f2fs_release_discard_addrs(struct f2fs_sb_info *sbi);
int f2fs_npages_for_summary_flush(struct f2fs_sb_info *sbi, bool for_ra);
void f2fs_allocate_new_segments(struct f2fs_sb_info *sbi);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index ec59cbd0e661d..33bf07222f99f 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -873,13 +873,14 @@ void f2fs_dirty_to_prefree(struct f2fs_sb_info *sbi)
mutex_unlock(&dirty_i->seglist_lock);
}
-int f2fs_disable_cp_again(struct f2fs_sb_info *sbi)
+block_t f2fs_get_unusable_blocks(struct f2fs_sb_info *sbi)
{
- struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
int ovp_hole_segs =
(overprovision_segments(sbi) - reserved_segments(sbi));
block_t ovp_holes = ovp_hole_segs << sbi->log_blocks_per_seg;
+ struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
block_t holes[2] = {0, 0}; /* DATA and NODE */
+ block_t unusable;
struct seg_entry *se;
unsigned int segno;
@@ -893,7 +894,17 @@ int f2fs_disable_cp_again(struct f2fs_sb_info *sbi)
}
mutex_unlock(&dirty_i->seglist_lock);
- if (holes[DATA] > ovp_holes || holes[NODE] > ovp_holes)
+ unusable = holes[DATA] > holes[NODE] ? holes[DATA] : holes[NODE];
+ if (unusable > ovp_holes)
+ return unusable - ovp_holes;
+ return 0;
+}
+
+int f2fs_disable_cp_again(struct f2fs_sb_info *sbi, block_t unusable)
+{
+ int ovp_hole_segs =
+ (overprovision_segments(sbi) - reserved_segments(sbi));
+ if (unusable > F2FS_OPTION(sbi).unusable_cap)
return -EAGAIN;
if (is_sbi_flag_set(sbi, SBI_CP_DISABLED_QUICK) &&
dirty_segments(sbi) > ovp_hole_segs)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 359fd68509d16..7d64e97611141 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -136,7 +136,10 @@ enum {
Opt_alloc,
Opt_fsync,
Opt_test_dummy_encryption,
- Opt_checkpoint,
+ Opt_checkpoint_disable,
+ Opt_checkpoint_disable_cap,
+ Opt_checkpoint_disable_cap_perc,
+ Opt_checkpoint_enable,
Opt_err,
};
@@ -195,7 +198,10 @@ static match_table_t f2fs_tokens = {
{Opt_alloc, "alloc_mode=%s"},
{Opt_fsync, "fsync_mode=%s"},
{Opt_test_dummy_encryption, "test_dummy_encryption"},
- {Opt_checkpoint, "checkpoint=%s"},
+ {Opt_checkpoint_disable, "checkpoint=disable"},
+ {Opt_checkpoint_disable_cap, "checkpoint=disable:%u"},
+ {Opt_checkpoint_disable_cap_perc, "checkpoint=disable:%u%%"},
+ {Opt_checkpoint_enable, "checkpoint=enable"},
{Opt_err, NULL},
};
@@ -772,22 +778,30 @@ static int parse_options(struct super_block *sb, char *options)
"Test dummy encryption mount option ignored");
#endif
break;
- case Opt_checkpoint:
- name = match_strdup(&args[0]);
- if (!name)
- return -ENOMEM;
-
- if (strlen(name) == 6 &&
- !strncmp(name, "enable", 6)) {
- clear_opt(sbi, DISABLE_CHECKPOINT);
- } else if (strlen(name) == 7 &&
- !strncmp(name, "disable", 7)) {
- set_opt(sbi, DISABLE_CHECKPOINT);
- } else {
- kvfree(name);
+ case Opt_checkpoint_disable_cap_perc:
+ if (args->from && match_int(args, &arg))
return -EINVAL;
- }
- kvfree(name);
+ if (arg < 0 || arg > 100)
+ return -EINVAL;
+ if (arg == 100)
+ F2FS_OPTION(sbi).unusable_cap =
+ sbi->user_block_count;
+ else
+ F2FS_OPTION(sbi).unusable_cap =
+ (sbi->user_block_count / 100) * arg;
+ set_opt(sbi, DISABLE_CHECKPOINT);
+ break;
+ case Opt_checkpoint_disable_cap:
+ if (args->from && match_int(args, &arg))
+ return -EINVAL;
+ F2FS_OPTION(sbi).unusable_cap = arg;
+ set_opt(sbi, DISABLE_CHECKPOINT);
+ break;
+ case Opt_checkpoint_disable:
+ set_opt(sbi, DISABLE_CHECKPOINT);
+ break;
+ case Opt_checkpoint_enable:
+ clear_opt(sbi, DISABLE_CHECKPOINT);
break;
default:
f2fs_msg(sb, KERN_ERR,
@@ -1410,8 +1424,8 @@ static int f2fs_show_options(struct seq_file *seq, struct dentry *root)
seq_printf(seq, ",alloc_mode=%s", "reuse");
if (test_opt(sbi, DISABLE_CHECKPOINT))
- seq_puts(seq, ",checkpoint=disable");
-
+ seq_printf(seq, ",checkpoint=disable:%u",
+ F2FS_OPTION(sbi).unusable_cap);
if (F2FS_OPTION(sbi).fsync_mode == FSYNC_MODE_POSIX)
seq_printf(seq, ",fsync_mode=%s", "posix");
else if (F2FS_OPTION(sbi).fsync_mode == FSYNC_MODE_STRICT)
@@ -1440,6 +1454,7 @@ static void default_options(struct f2fs_sb_info *sbi)
set_opt(sbi, EXTENT_CACHE);
set_opt(sbi, NOHEAP);
clear_opt(sbi, DISABLE_CHECKPOINT);
+ F2FS_OPTION(sbi).unusable_cap = 0;
sbi->sb->s_flags |= SB_LAZYTIME;
set_opt(sbi, FLUSH_MERGE);
set_opt(sbi, DISCARD);
@@ -1468,6 +1483,7 @@ static int f2fs_disable_checkpoint(struct f2fs_sb_info *sbi)
struct cp_control cpc;
int err = 0;
int ret;
+ block_t unusable;
if (s_flags & SB_RDONLY) {
f2fs_msg(sbi->sb, KERN_ERR,
@@ -1495,7 +1511,8 @@ static int f2fs_disable_checkpoint(struct f2fs_sb_info *sbi)
goto restore_flag;
}
- if (f2fs_disable_cp_again(sbi)) {
+ unusable = f2fs_get_unusable_blocks(sbi);
+ if (f2fs_disable_cp_again(sbi, unusable)) {
err = -EAGAIN;
goto restore_flag;
}
@@ -1508,7 +1525,7 @@ static int f2fs_disable_checkpoint(struct f2fs_sb_info *sbi)
goto out_unlock;
spin_lock(&sbi->stat_lock);
- sbi->unusable_block_count = 0;
+ sbi->unusable_block_count = unusable;
spin_unlock(&sbi->stat_lock);
out_unlock:
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index 729f46a3c9ee0..fa184880cff34 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -68,6 +68,20 @@ static ssize_t dirty_segments_show(struct f2fs_attr *a,
(unsigned long long)(dirty_segments(sbi)));
}
+static ssize_t unusable_show(struct f2fs_attr *a,
+ struct f2fs_sb_info *sbi, char *buf)
+{
+ block_t unusable;
+
+ if (test_opt(sbi, DISABLE_CHECKPOINT))
+ unusable = sbi->unusable_block_count;
+ else
+ unusable = f2fs_get_unusable_blocks(sbi);
+ return snprintf(buf, PAGE_SIZE, "%llu\n",
+ (unsigned long long)unusable);
+}
+
+
static ssize_t lifetime_write_kbytes_show(struct f2fs_attr *a,
struct f2fs_sb_info *sbi, char *buf)
{
@@ -440,6 +454,7 @@ F2FS_GENERAL_RO_ATTR(dirty_segments);
F2FS_GENERAL_RO_ATTR(lifetime_write_kbytes);
F2FS_GENERAL_RO_ATTR(features);
F2FS_GENERAL_RO_ATTR(current_reserved_blocks);
+F2FS_GENERAL_RO_ATTR(unusable);
#ifdef CONFIG_FS_ENCRYPTION
F2FS_FEATURE_RO_ATTR(encryption, FEAT_CRYPTO);
@@ -495,6 +510,7 @@ static struct attribute *f2fs_attrs[] = {
ATTR_LIST(inject_type),
#endif
ATTR_LIST(dirty_segments),
+ ATTR_LIST(unusable),
ATTR_LIST(lifetime_write_kbytes),
ATTR_LIST(features),
ATTR_LIST(reserved_blocks),
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply related
* [PATCH v3 1/4] f2fs: Lower threshold for disable_cp_again
From: Daniel Rosenberg @ 2019-05-30 0:49 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu, Jonathan Corbet, linux-f2fs-devel
Cc: linux-kernel, linux-doc, linux-fsdevel, kernel-team,
Daniel Rosenberg
In-Reply-To: <20190530004906.261170-1-drosen@google.com>
The existing threshold for allowable holes at checkpoint=disable time is
too high. The OVP space contains reserved segments, which are always in
the form of free segments. These must be subtracted from the OVP value.
The current threshold is meant to be the maximum value of holes of a
single type we can have and still guarantee that we can fill the disk
without failing to find space for a block of a given type.
If the disk is full, ignoring current reserved, which only helps us,
the amount of unused blocks is equal to the OVP area. Of that, there
are reserved segments, which must be free segments, and the rest of the
ovp area, which can come from either free segments or holes. The maximum
possible amount of holes is OVP-reserved.
Now, consider the disk when mounting with checkpoint=disable.
We must be able to fill all available free space with either data or
node blocks. When we start with checkpoint=disable, holes are locked to
their current type. Say we have H of one type of hole, and H+X of the
other. We can fill H of that space with arbitrary typed blocks via SSR.
For the remaining H+X blocks, we may not have any of a given block type
left at all. For instance, if we were to fill the disk entirely with
blocks of the type with fewer holes, the H+X blocks of the opposite type
would not be used. If H+X > OVP-reserved, there would be more holes than
could possibly exist, and we would have failed to find a suitable block
earlier on, leading to a crash in update_sit_entry.
If H+X <= OVP-reserved, then the holes end up effectively masked by the OVP
region in this case.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
---
fs/f2fs/segment.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 1a83115284b93..ec59cbd0e661d 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -876,7 +876,9 @@ void f2fs_dirty_to_prefree(struct f2fs_sb_info *sbi)
int f2fs_disable_cp_again(struct f2fs_sb_info *sbi)
{
struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
- block_t ovp = overprovision_segments(sbi) << sbi->log_blocks_per_seg;
+ int ovp_hole_segs =
+ (overprovision_segments(sbi) - reserved_segments(sbi));
+ block_t ovp_holes = ovp_hole_segs << sbi->log_blocks_per_seg;
block_t holes[2] = {0, 0}; /* DATA and NODE */
struct seg_entry *se;
unsigned int segno;
@@ -891,10 +893,10 @@ int f2fs_disable_cp_again(struct f2fs_sb_info *sbi)
}
mutex_unlock(&dirty_i->seglist_lock);
- if (holes[DATA] > ovp || holes[NODE] > ovp)
+ if (holes[DATA] > ovp_holes || holes[NODE] > ovp_holes)
return -EAGAIN;
if (is_sbi_flag_set(sbi, SBI_CP_DISABLED_QUICK) &&
- dirty_segments(sbi) > overprovision_segments(sbi))
+ dirty_segments(sbi) > ovp_hole_segs)
return -EAGAIN;
return 0;
}
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply related
* [PATCH v3 2/4] f2fs: Fix root reserved on remount
From: Daniel Rosenberg @ 2019-05-30 0:49 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu, Jonathan Corbet, linux-f2fs-devel
Cc: linux-kernel, linux-doc, linux-fsdevel, kernel-team,
Daniel Rosenberg
In-Reply-To: <20190530004906.261170-1-drosen@google.com>
On a remount, you can currently set root reserved if it was not
previously set. This can cause an underflow if reserved has been set to
a very high value, since then root reserved + current reserved could be
greater than user_block_count. inc_valid_block_count later subtracts out
these values from user_block_count, causing an underflow.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
---
fs/f2fs/super.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 912e2619d581b..359fd68509d16 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -213,7 +213,8 @@ void f2fs_msg(struct super_block *sb, const char *level, const char *fmt, ...)
static inline void limit_reserve_root(struct f2fs_sb_info *sbi)
{
- block_t limit = (sbi->user_block_count << 1) / 1000;
+ block_t limit = min((sbi->user_block_count << 1) / 1000,
+ sbi->user_block_count - sbi->reserved_blocks);
/* limit is 0.2% */
if (test_opt(sbi, RESERVE_ROOT) &&
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply related
* Re: [PATCH 1/2] hwmon: pmbus: Add Infineon PXE1610 VR driver
From: Guenter Roeck @ 2019-05-30 1:00 UTC (permalink / raw)
To: Vijay Khemka, Jean Delvare, Jonathan Corbet, linux-hwmon,
linux-doc, linux-kernel
Cc: joel, linux-aspeed, sdasari, Greg Kroah-Hartman
In-Reply-To: <20190529223511.4059120-1-vijaykhemka@fb.com>
On 5/29/19 3:35 PM, Vijay Khemka wrote:
> Added pmbus driver for the new device Infineon pxe1610
> voltage regulator. It also supports similar family device
> PXE1110 and PXM1310.
>
> Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> ---
> drivers/hwmon/pmbus/Kconfig | 9 +++
> drivers/hwmon/pmbus/Makefile | 1 +
> drivers/hwmon/pmbus/pxe1610.c | 119 ++++++++++++++++++++++++++++++++++
> 3 files changed, 129 insertions(+)
> create mode 100644 drivers/hwmon/pmbus/pxe1610.c
>
> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> index 30751eb9550a..338ef9b5a395 100644
> --- a/drivers/hwmon/pmbus/Kconfig
> +++ b/drivers/hwmon/pmbus/Kconfig
> @@ -154,6 +154,15 @@ config SENSORS_MAX8688
> This driver can also be built as a module. If so, the module will
> be called max8688.
>
> +config SENSORS_PXE1610
> + tristate "Infineon PXE1610"
> + help
> + If you say yes here you get hardware monitoring support for Infineon
> + PXE1610.
> +
> + This driver can also be built as a module. If so, the module will
> + be called pxe1610.
> +
> config SENSORS_TPS40422
> tristate "TI TPS40422"
> help
> diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> index 2219b9300316..b0fbd017a91a 100644
> --- a/drivers/hwmon/pmbus/Makefile
> +++ b/drivers/hwmon/pmbus/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_SENSORS_MAX20751) += max20751.o
> obj-$(CONFIG_SENSORS_MAX31785) += max31785.o
> obj-$(CONFIG_SENSORS_MAX34440) += max34440.o
> obj-$(CONFIG_SENSORS_MAX8688) += max8688.o
> +obj-$(CONFIG_SENSORS_PXE1610) += pxe1610.o
> obj-$(CONFIG_SENSORS_TPS40422) += tps40422.o
> obj-$(CONFIG_SENSORS_TPS53679) += tps53679.o
> obj-$(CONFIG_SENSORS_UCD9000) += ucd9000.o
> diff --git a/drivers/hwmon/pmbus/pxe1610.c b/drivers/hwmon/pmbus/pxe1610.c
> new file mode 100644
> index 000000000000..01e267944df5
> --- /dev/null
> +++ b/drivers/hwmon/pmbus/pxe1610.c
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Hardware monitoring driver for Infineon PXE1610
> + *
> + * Copyright (c) 2019 Facebook Inc
> + *
> + */
> +
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include "pmbus.h"
> +
> +/*
> + * Identify chip parameters.
> + */
> +static int pxe1610_identify(struct i2c_client *client,
> + struct pmbus_driver_info *info)
Please align continuation lines with '('.
> +{
> + if (pmbus_check_byte_register(client, 0, PMBUS_VOUT_MODE)) {
> + int vout_mode;
> +
> + vout_mode = pmbus_read_byte_data(client, 0, PMBUS_VOUT_MODE);
pmbus_read_byte_data() can return an error. Calling pmbus_check_byte_register()
doesn't really add any value here, since the second call can still fail,
which needs to be checked.
> + switch (vout_mode & 0x1f) {
> + case 1:
> + info->vrm_version = vr12;
> + break;
Alignment is off.
> + case 2:
> + info->vrm_version = vr13;
> + break;
Same here.
> + default:
> + return -ENODEV;
> + }
> + }
> + return 0;
> +}
> +
> +static int pxe1610_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct pmbus_driver_info *info;
> + u8 buf[I2C_SMBUS_BLOCK_MAX];
> + int ret;
> +
> + if (!i2c_check_functionality(client->adapter,
> + I2C_FUNC_SMBUS_READ_BYTE_DATA
> + | I2C_FUNC_SMBUS_READ_WORD_DATA
> + | I2C_FUNC_SMBUS_READ_BLOCK_DATA))
> + return -ENODEV;
> +
> + /* By default this device doesn't boot to page 0, so set page 0
> + * to access all pmbus registers.
> + */
Please use standard multi-line comments.
> + i2c_smbus_write_byte_data(client, 0, 0);
> +
Please use the PMBUS_PAGE command definition.
I wonder if it would make sense to initialize currpage in the core to an unreasonable
number for multi-page chips, but I guess that is a different question.
> + /* Read Manufacturer id */
> + ret = i2c_smbus_read_block_data(client, PMBUS_MFR_ID, buf);
> + if (ret < 0) {
> + dev_err(&client->dev, "Failed to read PMBUS_MFR_ID\n");
> + return ret;
> + }
> + if (ret != 2 || strncmp(buf, "XP", strlen("XP"))) {
The strlen() is really unnecessary here. Just use 2 (and a define
for it if you like).
> + dev_err(&client->dev, "MFR_ID unrecognised\n");
unrecognized. Oh well, turns out unrecognised is the British spelling and
just as valid, so feel free to keep it if you like.
> + return -ENODEV;
> + }
> +
> + info = devm_kzalloc(&client->dev, sizeof(struct pmbus_driver_info),
> + GFP_KERNEL);
> + if (!info)
> + return -ENOMEM;
> +
> + info->format[PSC_VOLTAGE_IN] = linear;
> + info->format[PSC_VOLTAGE_OUT] = vid;
> + info->format[PSC_CURRENT_IN] = linear;
> + info->format[PSC_CURRENT_OUT] = linear;
> + info->format[PSC_POWER] = linear;
> + info->format[PSC_TEMPERATURE] = linear;
> +
> + info->func[0] = PMBUS_HAVE_VIN
> + | PMBUS_HAVE_VOUT | PMBUS_HAVE_IIN
> + | PMBUS_HAVE_IOUT | PMBUS_HAVE_PIN
> + | PMBUS_HAVE_POUT | PMBUS_HAVE_TEMP
> + | PMBUS_HAVE_STATUS_VOUT | PMBUS_HAVE_STATUS_IOUT
> + | PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_STATUS_TEMP;
> + info->func[1] = info->func[0];
> + info->func[2] = info->func[0];
> +
> + info->pages = id->driver_data;
> + info->identify = pxe1610_identify;
> +
It doesn't really add value to initialize all these parameters manually.
I would suggest to use the approach from tps53679.c, ie have a static
structure and use devm_kmemdup() to pass a copy to pmbus_do_probe().
> + return pmbus_do_probe(client, id, info);
> +}
> +
> +static const struct i2c_device_id pxe1610_id[] = {
> + {"pxe1610", 3},
> + {"pxe1110", 3},
> + {"pxm1310", 3},
Unless there are chips with different page counts in the queue, using
driver_data to pass the number of pages does not add any value. Just
set num_pages to 3.
If you like, feel free to use a define instead of a constant.
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, pxe1610_id);
> +
> +/* This is the driver that will be inserted */
This comment does not add any value.
> +static struct i2c_driver pxe1610_driver = {
> + .driver = {
> + .name = "pxe1610",
> + },
> + .probe = pxe1610_probe,
> + .remove = pmbus_do_remove,
> + .id_table = pxe1610_id,
> +};
> +
> +module_i2c_driver(pxe1610_driver);
> +
> +MODULE_AUTHOR("Vijay Khemka <vijaykhemka@fb.com>");
> +MODULE_DESCRIPTION("PMBus driver for Infineon PXE1610, PXE1110 and PXM1310");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [PATCH 2/2] Docs: hwmon: pmbus: Add PXE1610 driver
From: Guenter Roeck @ 2019-05-30 1:05 UTC (permalink / raw)
To: Vijay Khemka, Jean Delvare, Jonathan Corbet, linux-hwmon,
linux-doc, linux-kernel
Cc: joel, linux-aspeed, sdasari, Greg Kroah-Hartman
In-Reply-To: <20190529223511.4059120-2-vijaykhemka@fb.com>
On 5/29/19 3:35 PM, Vijay Khemka wrote:
> Added support for Infenion PXE1610 driver
>
> Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> ---
> Documentation/hwmon/pxe1610 | 84 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 84 insertions(+)
> create mode 100644 Documentation/hwmon/pxe1610
>
> diff --git a/Documentation/hwmon/pxe1610 b/Documentation/hwmon/pxe1610
> new file mode 100644
> index 000000000000..b5c83edf027a
> --- /dev/null
> +++ b/Documentation/hwmon/pxe1610
> @@ -0,0 +1,84 @@
> +Kernel driver pxe1610
> +=====================
> +
> +Supported chips:
> + * Infinion PXE1610
> + Prefix: 'pxe1610'
> + Addresses scanned: -
> + Datasheet: Datasheet is not publicly available.
> +
> + * Infinion PXE1110
> + Prefix: 'pxe1110'
> + Addresses scanned: -
> + Datasheet: Datasheet is not publicly available.
> +
> + * Infinion PXM1310
> + Prefix: 'pxm1310'
> + Addresses scanned: -
> + Datasheet: Datasheet is not publicly available.
> +
> +Author: Vijay Khemka <vijaykhemka@fb.com>
> +
> +
> +Description
> +-----------
> +
> +PXE1610 is a Multi-rail/Multiphase Digital Controllers and
> +it is compliant to Intel VR13 DC-DC converter specifications.
> +
And the others ?
> +
> +Usage Notes
> +-----------
> +
> +This driver can be enabled with kernel config CONFIG_SENSORS_PXE1610
> +set to 'y' or 'm'(for module).
> +
The above does not really add value.
> +This driver does not probe for PMBus devices. You will have
> +to instantiate devices explicitly.
> +
> +Example: the following commands will load the driver for an PXE1610
> +at address 0x70 on I2C bus #4:
> +
> +# modprobe pxe1610
> +# echo pxe1610 0x70 > /sys/bus/i2c/devices/i2c-4/new_device
> +
> +It can also be instantiated by declaring in device tree if it is
> +built as a kernel not as a module.
> +
I assume you mean "built into the kernel".
Why would devicetree based instantiation not work if the driver is built
as module ?
> +
> +Sysfs attributes
> +----------------
> +
> +curr1_label "iin"
> +curr1_input Measured input current
> +curr1_alarm Current high alarm
> +
> +curr[2-4]_label "iout[1-3]"
> +curr[2-4]_input Measured output current
> +curr[2-4]_crit Critical maximum current
> +curr[2-4]_crit_alarm Current critical high alarm
> +
> +in1_label "vin"
> +in1_input Measured input voltage
> +in1_crit Critical maximum input voltage
> +in1_crit_alarm Input voltage critical high alarm
> +
> +in[2-4]_label "vout[1-3]"
> +in[2-4]_input Measured output voltage
> +in[2-4]_lcrit Critical minimum output voltage
> +in[2-4]_lcrit_alarm Output voltage critical low alarm
> +in[2-4]_crit Critical maximum output voltage
> +in[2-4]_crit_alarm Output voltage critical high alarm
> +
> +power1_label "pin"
> +power1_input Measured input power
> +power1_alarm Input power high alarm
> +
> +power[2-4]_label "pout[1-3]"
> +power[2-4]_input Measured output power
> +
> +temp[1-3]_input Measured temperature
> +temp[1-3]_crit Critical high temperature
> +temp[1-3]_crit_alarm Chip temperature critical high alarm
> +temp[1-3]_max Maximum temperature
> +temp[1-3]_max_alarm Chip temperature high alarm
>
^ permalink raw reply
* Re: [PATCH 4/5] docs: by default, build docs a lot faster with Sphinx >= 1.7
From: Mauro Carvalho Chehab @ 2019-05-30 1:53 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <20190529174716.4f0e21ad@lwn.net>
Em Wed, 29 May 2019 17:47:16 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Wed, 29 May 2019 20:20:05 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > > So this totally fails to work for me with any version of sphinx, and I'm
> > > not enough of a Perl person to figure it out. Sometimes I'll see the
> > > sphinx-build output, i.e.:
> > >
> > > sphinx-build 1.8.4
> > >
> > > and sometimes (like with 2.0) I don't, but I never get -jauto regardless.
> >
> > Hmm... with 2.0.0 --version prints the version.
> >
> > $ sphinx-build --version
> > sphinx-build 2.0.0
>
> Yup. The point is that I see the sphinx-build output *in the docs-build
> output", not when I run it standalone (where it does the expected thing).
Weird... could some versions of Sphinx be redirecting the output of
--version to stderr instead of stdout?
If so, something like:
perl -e 'open IN,"sphinx-build --version 2>&1 |"; while (<IN>) { if (m/([\d\.]+)/) { print "-jauto\n" if ($1 >= "1.7") } ;} close IN'
would make it print "-jauto" with those other versions you're trying.
>
> > > Not sure what's going on here?
> >
> > Do you have SPHINXOPTS already set on your environment? If so, Makefile
> > will not override the existing environment.
>
> Yeah, I had it set to -j1 because I want to wait as long as possible for my
> docs builds :)
>
> No, I didn't have it set separately, made a point of that.
>
> > Here, if I call it by hand (replacing $$1 by $1), it does the right
> > thing. For example:
> >
> > 1.8.4:
> >
> > $ sphinx-build --version
> > sphinx-build 1.8.4
> > $ perl -e 'open IN,"sphinx-build --version |"; while (<IN>) { if (m/([\d\.]+)/) { print "-jauto\n" if ($1 >= "1.7") } ;} close IN'
> > -jauto
>
> $ perl -e 'open IN,"sphinx-build --version |"; while (<IN>) { if (m/([\d\.]+)/) { print "-jauto\n" if ($1 >= "1.7") } ;} close IN'
> sphinx-build 1.8.4
> $
>
> It works properly with 2.0.1 - but only on the command line; I still don't
> get the right behavior in a docs build.
>
> Most weird.
>
> This is an Fedora 30 system, FWIW.
Yeah, really weird. Here I'm using Fedora 30 too:
python3-sphinx_rtd_theme-0.4.3-1.fc30.noarch
python3-sphinx-1.8.4-1.fc30.noarch
It works with both installed version and pip3 virtualenvs.
I didn't try the python2 versions, though.
>
> jon
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v6 00/12] Include linux PCI docs into Sphinx TOC tree
From: Bjorn Helgaas @ 2019-05-30 2:56 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Changbin Du, linux-pci, linux-doc, linux-kernel, mchehab+samsung
In-Reply-To: <20190529163510.3dd4dc2d@lwn.net>
On Wed, May 29, 2019 at 04:35:10PM -0600, Jonathan Corbet wrote:
> On Mon, 20 May 2019 06:10:15 +0000
> Changbin Du <changbin.du@gmail.com> wrote:
>
> > Bjorn and Jonathan,
> > Could we consider to merge this serias now? Thanks.
>
> Somewhat belatedly, but I think we could. Bjorn, do you have a preference
> for which tree this goes through? I don't remember if we'd come to an
> agreement on that or not, sorry...
I don't have a preference. I somehow had the impression it would go
through your tree, but I'd be happy to merge it if you'd prefer.
Bjorn
^ permalink raw reply
* Re: [PATCH v6 00/12] Include linux PCI docs into Sphinx TOC tree
From: Bjorn Helgaas @ 2019-05-30 3:01 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Changbin Du, linux-pci, linux-doc, linux-kernel, mchehab+samsung
In-Reply-To: <20190529163510.3dd4dc2d@lwn.net>
On Wed, May 29, 2019 at 04:35:10PM -0600, Jonathan Corbet wrote:
> On Mon, 20 May 2019 06:10:15 +0000
> Changbin Du <changbin.du@gmail.com> wrote:
>
> > Bjorn and Jonathan,
> > Could we consider to merge this serias now? Thanks.
>
> Somewhat belatedly, but I think we could. Bjorn, do you have a preference
> for which tree this goes through? I don't remember if we'd come to an
> agreement on that or not, sorry...
Actually, let me at least take a look at these. I noticed that
renames caused some of the ACPI docs to end up with lines >80 columns,
and I'd prefer to avoid that. So maybe I'll take these after all if
that's OK.
Bjorn
^ permalink raw reply
* [PATCH v8 0/7] iommu: enhance IOMMU default DMA mode build options
From: Zhen Lei @ 2019-05-30 3:48 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei, Hanjun Guo
v7--> v8
1. Split into multiple small patches base on ARCHs or IOMMU drivers.
2. Hide the unsupported build options on the related ARCH or IOMMU.
v6 --> v7:
1. Fix some text editing errors
v5 --> v6:
1. give up adding boot option iommu.dma_mode
v4 --> v5:
As Hanjun and Thomas Gleixner's suggestion:
1. Keep the old ARCH specific boot options no change.
2. Keep build option CONFIG_IOMMU_DEFAULT_PASSTHROUGH no change.
v4:
As Robin Murphy's suggestion:
"It's also not necessarily obvious to the user how this interacts with
IOMMU_DEFAULT_PASSTHROUGH, so if we really do go down this route, maybe it
would be better to refactor the whole lot into a single selection of something
like IOMMU_DEFAULT_MODE anyway."
In this version, I tried to normalize the IOMMU dma mode boot options for all
ARCHs. When IOMMU is enabled, there are 3 dma modes: paasthrough(bypass),
lazy(mapping but defer the IOTLB invalidation), strict. But currently each
ARCHs defined their private boot options, different with each other. For
example, to enable/disable "passthrough", ARM64 use iommu.passthrough=1/0,
X86 use iommu=pt/nopt, PPC/POWERNV use iommu=nobypass.
Zhen Lei (7):
iommu: enhance IOMMU default DMA mode build options
x86/dma: use IS_ENABLED() to simplify the code
s390/pci: add support for IOMMU default DMA mode build options
powernv/iommu: add support for IOMMU default DMA mode build options
iommu/vt-d: add support for IOMMU default DMA mode build options
iommu/amd: add support for IOMMU default DMA mode build options
ia64: hide build option IOMMU_DEFAULT_PASSTHROUGH
arch/powerpc/platforms/powernv/pci-ioda.c | 3 +-
arch/s390/pci/pci_dma.c | 2 +-
arch/x86/kernel/pci-dma.c | 7 ++---
drivers/iommu/Kconfig | 46 ++++++++++++++++++++++++++-----
drivers/iommu/amd_iommu_init.c | 3 +-
drivers/iommu/intel-iommu.c | 2 +-
drivers/iommu/iommu.c | 3 +-
7 files changed, 49 insertions(+), 17 deletions(-)
--
1.8.3
^ permalink raw reply
* [PATCH v8 2/7] x86/dma: use IS_ENABLED() to simplify the code
From: Zhen Lei @ 2019-05-30 3:48 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei, Hanjun Guo
In-Reply-To: <20190530034831.4184-1-thunder.leizhen@huawei.com>
This patch removes the ifdefs around CONFIG_IOMMU_DEFAULT_PASSTHROUGH to
improve readablity.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
arch/x86/kernel/pci-dma.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index dcd272dbd0a9330..9f2b19c35a060df 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -43,11 +43,8 @@
* It is also possible to disable by default in kernel config, and enable with
* iommu=nopt at boot time.
*/
-#ifdef CONFIG_IOMMU_DEFAULT_PASSTHROUGH
-int iommu_pass_through __read_mostly = 1;
-#else
-int iommu_pass_through __read_mostly;
-#endif
+int iommu_pass_through __read_mostly =
+ IS_ENABLED(CONFIG_IOMMU_DEFAULT_PASSTHROUGH);
extern struct iommu_table_entry __iommu_table[], __iommu_table_end[];
--
1.8.3
^ permalink raw reply related
* [PATCH v8 3/7] s390/pci: add support for IOMMU default DMA mode build options
From: Zhen Lei @ 2019-05-30 3:48 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei, Hanjun Guo
In-Reply-To: <20190530034831.4184-1-thunder.leizhen@huawei.com>
The default DMA mode is LAZY on s390, this patch make it can be set to
STRICT at build time. It can be overridden by boot option.
There is no functional change.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
arch/s390/pci/pci_dma.c | 2 +-
drivers/iommu/Kconfig | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/s390/pci/pci_dma.c b/arch/s390/pci/pci_dma.c
index 9e52d1527f71495..784ad1e0acecfb1 100644
--- a/arch/s390/pci/pci_dma.c
+++ b/arch/s390/pci/pci_dma.c
@@ -17,7 +17,7 @@
static struct kmem_cache *dma_region_table_cache;
static struct kmem_cache *dma_page_table_cache;
-static int s390_iommu_strict;
+static int s390_iommu_strict = IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT);
static int zpci_refresh_global(struct zpci_dev *zdev)
{
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d6a1a45f80ffbf5..9b48c2fc20e14d3 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -78,6 +78,7 @@ config IOMMU_DEBUGFS
choice
prompt "IOMMU default DMA mode"
depends on IOMMU_API
+ default IOMMU_DEFAULT_LAZY if S390_IOMMU
default IOMMU_DEFAULT_STRICT
help
This option allows IOMMU DMA mode to be chose at build time, to
@@ -87,6 +88,7 @@ choice
config IOMMU_DEFAULT_PASSTHROUGH
bool "passthrough"
+ depends on !S390_IOMMU
help
In this mode, the DMA access through IOMMU without any addresses
translation. That means, the wrong or illegal DMA access can not
--
1.8.3
^ permalink raw reply related
* [PATCH v8 4/7] powernv/iommu: add support for IOMMU default DMA mode build options
From: Zhen Lei @ 2019-05-30 3:48 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei, Hanjun Guo
In-Reply-To: <20190530034831.4184-1-thunder.leizhen@huawei.com>
The default DMA mode is PASSTHROUGH on powernv, this patch make it can be
set to STRICT at build time. It can be overridden by boot option.
There is no functional change.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++-
drivers/iommu/Kconfig | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 126602b4e39972d..40208b9019be890 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -85,7 +85,8 @@ void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
va_end(args);
}
-static bool pnv_iommu_bypass_disabled __read_mostly;
+static bool pnv_iommu_bypass_disabled __read_mostly =
+ !IS_ENABLED(CONFIG_IOMMU_DEFAULT_PASSTHROUGH);
static bool pci_reset_phbs __read_mostly;
static int __init iommu_setup(char *str)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 9b48c2fc20e14d3..b5af859956c4fda 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -78,6 +78,7 @@ config IOMMU_DEBUGFS
choice
prompt "IOMMU default DMA mode"
depends on IOMMU_API
+ default IOMMU_DEFAULT_PASSTHROUGH if (PPC_POWERNV && PCI)
default IOMMU_DEFAULT_LAZY if S390_IOMMU
default IOMMU_DEFAULT_STRICT
help
@@ -98,6 +99,7 @@ config IOMMU_DEFAULT_PASSTHROUGH
config IOMMU_DEFAULT_LAZY
bool "lazy"
+ depends on !PPC_POWERNV
help
Support lazy mode, where for every IOMMU DMA unmap operation, the
flush operation of IOTLB and the free operation of IOVA are deferred.
--
1.8.3
^ permalink raw reply related
* [PATCH v8 1/7] iommu: enhance IOMMU default DMA mode build options
From: Zhen Lei @ 2019-05-30 3:48 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei, Hanjun Guo
In-Reply-To: <20190530034831.4184-1-thunder.leizhen@huawei.com>
First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
opportunity to set {lazy|strict} mode as default at build time. Then put
the three config options in an choice, make people can only choose one of
the three at a time.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
drivers/iommu/Kconfig | 42 +++++++++++++++++++++++++++++++++++-------
drivers/iommu/iommu.c | 3 ++-
2 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 83664db5221df02..d6a1a45f80ffbf5 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -75,17 +75,45 @@ config IOMMU_DEBUGFS
debug/iommu directory, and then populate a subdirectory with
entries as required.
-config IOMMU_DEFAULT_PASSTHROUGH
- bool "IOMMU passthrough by default"
+choice
+ prompt "IOMMU default DMA mode"
depends on IOMMU_API
- help
- Enable passthrough by default, removing the need to pass in
- iommu.passthrough=on or iommu=pt through command line. If this
- is enabled, you can still disable with iommu.passthrough=off
- or iommu=nopt depending on the architecture.
+ default IOMMU_DEFAULT_STRICT
+ help
+ This option allows IOMMU DMA mode to be chose at build time, to
+ override the default DMA mode of each ARCHs, removing the need to
+ pass in kernel parameters through command line. You can still use
+ ARCHs specific boot options to override this option again.
+
+config IOMMU_DEFAULT_PASSTHROUGH
+ bool "passthrough"
+ help
+ In this mode, the DMA access through IOMMU without any addresses
+ translation. That means, the wrong or illegal DMA access can not
+ be caught, no error information will be reported.
If unsure, say N here.
+config IOMMU_DEFAULT_LAZY
+ bool "lazy"
+ help
+ Support lazy mode, where for every IOMMU DMA unmap operation, the
+ flush operation of IOTLB and the free operation of IOVA are deferred.
+ They are only guaranteed to be done before the related IOVA will be
+ reused.
+
+config IOMMU_DEFAULT_STRICT
+ bool "strict"
+ help
+ For every IOMMU DMA unmap operation, the flush operation of IOTLB and
+ the free operation of IOVA are guaranteed to be done in the unmap
+ function.
+
+ This mode is safer than the two above, but it maybe slower in some
+ high performace scenarios.
+
+endchoice
+
config OF_IOMMU
def_bool y
depends on OF && IOMMU_API
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 67ee6623f9b2a4d..56bce221285b15f 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -43,7 +43,8 @@
#else
static unsigned int iommu_def_domain_type = IOMMU_DOMAIN_DMA;
#endif
-static bool iommu_dma_strict __read_mostly = true;
+static bool iommu_dma_strict __read_mostly =
+ IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT);
struct iommu_group {
struct kobject kobj;
--
1.8.3
^ permalink raw reply related
* [PATCH v8 7/7] ia64: hide build option IOMMU_DEFAULT_PASSTHROUGH
From: Zhen Lei @ 2019-05-30 3:48 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei, Hanjun Guo
In-Reply-To: <20190530034831.4184-1-thunder.leizhen@huawei.com>
The DMA mode PASSTHROUGH is not used on ia64.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
drivers/iommu/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index f6c030433d38048..f7400e35628dce4 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -89,7 +89,7 @@ choice
config IOMMU_DEFAULT_PASSTHROUGH
bool "passthrough"
- depends on !S390_IOMMU
+ depends on (!S390_IOMMU && !IA64)
help
In this mode, the DMA access through IOMMU without any addresses
translation. That means, the wrong or illegal DMA access can not
--
1.8.3
^ permalink raw reply related
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