Re: [PATCH v3 12/13] dt-bindings: clock: Add Marvell MMP Audio Clock Controller binding
On Wed, 20 May 2020 00:41:50 +0200, Lubomir Rintel wrote: > This describes the bindings for a controller that generates master and bit > clocks for the I2S interface. > > Signed-off-by: Lubomir Rintel > > --- > Changes since v1: > - Fix commit message wording > - Define MMP2_CLK_AUDIO_NR_CLKS > - Make clock ids start at 0, not 1 > - Fix dt-bindings/clock/marvell,mmp2-audio.h file name > - Rename node from "clocks" to "clock-controller" > > .../clock/marvell,mmp2-audio-clock.yaml | 74 +++ > .../dt-bindings/clock/marvell,mmp2-audio.h| 10 +++ > 2 files changed, 84 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml > create mode 100644 include/dt-bindings/clock/marvell,mmp2-audio.h > Reviewed-by: Rob Herring
Re: [PATCH] tpm: Revert "tpm: fix invalid locking in NONBLOCKING mode"
On Tue, 2020-05-26 at 15:19 -0700, Alex Guzman wrote:
[...]
> When using your patch, I get a hang when trying to use tpm2_getcap,
> and dmesg shows some info.
Are you sure it's all applied? This
> [ 570.913803] tpm_tcg_write_bytes+0x2f/0x40
> [ 570.913805] release_locality+0x49/0x220
> [ 570.913807] tpm_relinquish_locality+0x1f/0x40
> [ 570.913808] tpm_chip_stop+0x21/0x40
> [ 570.913810] tpm_put_ops+0x9/0x30
> [ 570.913811] tpm_common_write+0x179/0x190
> [ 570.913813] vfs_write+0xb1/0x1a0
Implies an unmatched tpm_put_ops() in the async write path, as though
this hunk:
> @@ -211,11 +202,19 @@ ssize_t tpm_common_write(struct file *file,
> const char __user *buf,
> if (file->f_flags & O_NONBLOCK) {
> priv->command_enqueued = true;
> queue_work(tpm_dev_wq, >async_work);
> - tpm_put_ops(priv->chip);
> mutex_unlock(>buffer_mutex);
> return size;
> }
Is missing. I actually booted the patch in my TPM based VM and it all
seems to work OK when I execute tpm2_getcap (I verified it's using
O_NONBLOCK) and tssgetcapability in sync mode.
James
Re: [PATCH v3 09/13] dt-bindings: clock: Make marvell,mmp2-clock a power controller
On Wed, May 20, 2020 at 12:41:47AM +0200, Lubomir Rintel wrote: > This is a binding for the MMP2 power management units. As such apart from > providing the clocks, they also manage the power islands. > > Signed-off-by: Lubomir Rintel > > --- > Changes since v2: > - Added this patch > > .../devicetree/bindings/clock/marvell,mmp2-clock.yaml| 5 + > 1 file changed, 5 insertions(+) Acked-by: Rob Herring
Re: [PATCH 1/2] clk: hisilicon: Use correct return value about hisi_reset_init()
Quoting Tiezhu Yang (2020-05-24 20:31:55)
> The return value about hisi_reset_init() is not correct, fix it.
>
> Signed-off-by: Tiezhu Yang
> ---
> drivers/clk/hisilicon/clk-hi3519.c | 4 ++--
> drivers/clk/hisilicon/crg-hi3516cv300.c | 4 ++--
> drivers/clk/hisilicon/crg-hi3798cv200.c | 4 ++--
> drivers/clk/hisilicon/reset.c | 4 ++--
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/clk/hisilicon/clk-hi3519.c
> b/drivers/clk/hisilicon/clk-hi3519.c
> index ad0c7f3..803fa66 100644
> --- a/drivers/clk/hisilicon/clk-hi3519.c
> +++ b/drivers/clk/hisilicon/clk-hi3519.c
> @@ -149,8 +149,8 @@ static int hi3519_clk_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> crg->rstc = hisi_reset_init(pdev);
> - if (!crg->rstc)
> - return -ENOMEM;
> + if (IS_ERR(crg->rstc))
> + return PTR_ERR(crg->rstc);
>
> crg->clk_data = hi3519_clk_register(pdev);
> if (IS_ERR(crg->clk_data)) {
The code I see is returning NULL or a valid pointer from
hisi_reset_init(). Can you add a "Fixes" tag to this patch so we can
figure out which patch changed the behavior and where this patch needs
to be backported to?
Re: Some -serious- BPF-related litmus tests
On Tue, 26 May 2020 13:19:36 -0700, Andrii Nakryiko wrote: > On Tue, May 26, 2020 at 7:02 AM Akira Yokosawa wrote: >> >> On Tue, 26 May 2020 19:50:47 +0900, Akira Yokosawa wrote: >>> On Mon, 25 May 2020 16:31:05 -0700, Andrii Nakryiko wrote: On Mon, May 25, 2020 at 3:01 PM Akira Yokosawa wrote: > >>> [...] > Yes, that should work. Ok, assigning to zero didn't work (it still complained about uninitialized read), but using a separate int *lenFail to assign to rLenPtr worked. Curiously, if I used rLenPtr = len1; in error case, it actually takes a bit more time to verify. So I've converted everything else as you suggested. I compiled latest herd7 and it doesn't produce any warnings. But it's also extremely slow, compared to the herd7 that I get by default. Validating simple 1p1c cases takes about 2.5x times longer (0.03s vs 0.07), >> >> Wait a moment! >> >> This 0.03s was the run time of the original 1p1c litmus test, wasn't it? >> Then you are comparing apples and oranges. >> >> How long does your default herd7 take to complete the updated 1p1c test? >> >> Thanks, Akira > > It could be new test vs old test, so I re-ran again. Identical > 1p1c-unbound test: > > OLD version: > > $ herd7 -version && herd7 -unroll 0 -conf linux-kernel.cfg > ../../Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+unbound.litmus > 7.52, Rev: exported > Test bpf-rb+1p1c+unbound Allowed > States 2 > 0:rFail=0; 1:rFail=0; cx=0; len1=1; px=1; > 0:rFail=0; 1:rFail=0; cx=1; len1=1; px=1; > Ok > Witnesses > Positive: 3 Negative: 0 > Condition exists (0:rFail=0 /\ 1:rFail=0 /\ px=1 /\ len1=1 /\ (cx=0 \/ cx=1)) > Observation bpf-rb+1p1c+unbound Always 3 0 > Time bpf-rb+1p1c+unbound 0.03 > Hash=20a68cc69b09fbb79f407f825c015623 > > LATEST from sources version: > > $ herd7 -version && herd7 -unroll 0 -conf linux-kernel.cfg > ../../Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+unbound.litmus > 7.55+01(dev), Rev: 61e23aaee7bba87ccf4cdf1a620a3a9fa8f9a586 > Test bpf-rb+1p1c+unbound Allowed > States 2 > 0:rFail=0; 1:rFail=0; cx=0; len1=1; px=1; > 0:rFail=0; 1:rFail=0; cx=1; len1=1; px=1; > Ok > Witnesses > Positive: 3 Negative: 0 > Condition exists (0:rFail=0 /\ 1:rFail=0 /\ px=1 /\ len1=1 /\ (cx=0 \/ cx=1)) > Observation bpf-rb+1p1c+unbound Always 3 0 > Time bpf-rb+1p1c+unbound 0.06 > Hash=20a68cc69b09fbb79f407f825c015623 > > Still 2x difference. I see opposite tendency on a different set of time consuming litmus tests comparing herd7 7.52 and HEAD. herd7 7.52 herd7 HEAD C-SB+l-o-o-u+l-o-o-u+l-o-o-u+l-o-o-u+l-o-o-u 8.44 6.12 C-SB+l-o-o-u+l-o-o-u+l-o-o-u+l-o-o-u-C 77.19 69.92 C-SB+l-o-o-u+l-o-o-u+l-o-o-u+l-o-o-u-CE 355.62 287.27 C-SB+l-o-o-u+l-o-o-u+l-o-o-u+l-o-o-u-X 157.87 191.50 C-SB+l-o-o-u+l-o-o-u+l-o-o-u+l-o-o-u 2.36 0.94 C-SB+l-o-o-u+l-o-o-u-+l-o-o-u-C 2.32 0.93 C-SB+l-o-o-u+l-o-o-u-+l-o-o-u-CE 5.64 3.52 C-SB+l-o-o-u+l-o-o-u+l-o-o-u-X3.18 2.52 C-SB+l-o-o-u+l-o-o-u+l-o-o-u-XE 11.81 10.35 C-SB+l-o-o-u+l-o-o-u+l-o-o-u 0.25 0.19 C-SB+l-o-o-u+l-o-o-u-C0.15 0.12 C-SB+l-o-o-u+l-o-o-u-CE 0.26 0.20 C-SB+l-o-o-u+l-o-o-u-X0.17 0.14 C-SB+l-o-o-u+l-o-o-u-XE 0.38 0.30 C-SB+l-o-o-u+l-o-o-u 0.04 0.03 NOTE: These were taken on a fairly old PC, with power-saving mode enabled. Did you used the original 1p1c unbound test? I'd like you to compare the updated 1p1c unbound test. Thanks, Akira > >> but trying to validate 2p1c case, which normally validates in 42s (unbounded) and 110s (bounded), it took more than 20 minutes and hasn't finished, before I gave up. So I don't know what's going on there... >>> >>> herdtools7 has recently been heavily restructured. >>> On the performance regression, I must defer to Luc. >>> >>> Luc, do you have any idea? >>> As for klitmus7, I managed to generate everything without warnings, but couldn't make it build completely due to: $ make make -C /lib/modules/5.6.13-01802-g938d64da97c6/build/ >>> >>> So you are on Linux 5.6.x which requires cutting-edge klitmus7. >>> M=/home/andriin/local/linux-trees/tools/memory-model/mymodules modules make[1]: Entering directory `/data/users/andriin/linux-build/fb-config' make[2]: Entering directory `/data/users/andriin/linux-build/default-x86_64' CC [M] /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.o /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:
[PATCH RESEND v2] mtd: physmap: Add Baikal-T1 physically mapped ROMs support
Baikal-T1 Boot Controller provides an access to a RO storages, which are
physically mapped into the MMIO space. In particularly there are the
Internal ROM embedded into the SoC with a pre-installed firmware,
externally attached SPI flash (also accessed in the read-only mode) and a
memory region, which mirrors one of them in accordance with the currently
enabled system boot mode (also called Boot ROM).
This commit adds the ROMs support to the physmap driver of the MTD kernel
subsystem. Currently the driver only supports the Internal ROM, since
physically mapped SPI flash is utilized by the Baikal-T1 System Boot
Controller driver so won't be available over mtd-rom interface and
the Boot ROM mirror mapping has dependency on the SPI flash mapping
switcher available within the SPI flash registers space. The real access
to the Boot ROM memory will be added in future.
Note we had to create a dedicated code for the ROMs since read from the
corresponding memory regions must be done via the dword-aligned addresses.
In addition the driver in future states will have to take into account
that the Boot ROM might mirror the SPI flash region so before accessing it
the SPI flash direct mapping must be enabled by means of a dedicated flag
in the Baikal-T1 System SPI register flag.
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Maxim Kaurkin
Cc: Pavel Parkhomenko
Cc: Ramil Zaripov
Cc: Ekaterina Skachko
Cc: Vadim Vlasov
Cc: Alexey Kolotnikov
Cc: Thomas Bogendoerfer
Cc: Arnd Bergmann
Cc: Lee Jones
Cc: linux-m...@vger.kernel.org
---
Miquel, Richard, Vignesh, the merge window is upon us, please review/merge
in/whatever this patch.
This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
base-commit: 0e698dfa2822 ("Linux 5.7-rc4")
tag: v5.7-rc4
New vendor prefix will be added in the framework of the next patchset:
https://lkml.org/lkml/2020/5/6/1047
Note since the next patchset is no longer relevant (as a result of a
discussion with @Lee and @Miquel)
https://lkml.org/lkml/2020/3/6/421
and Boot ROM mtd is currently unsupported I can freely submit this patch,
while in former case I had to wait for the patchset merged.
Link:
https://lore.kernel.org/linux-mtd/20200508100905.5854-1-sergey.se...@baikalelectronics.ru/
Changelog v2:
- Resend.
---
drivers/mtd/maps/Kconfig | 8 ++
drivers/mtd/maps/Makefile | 1 +
drivers/mtd/maps/physmap-bt1-rom.c | 189 +
drivers/mtd/maps/physmap-bt1-rom.h | 17 +++
drivers/mtd/maps/physmap-core.c| 5 +
5 files changed, 220 insertions(+)
create mode 100644 drivers/mtd/maps/physmap-bt1-rom.c
create mode 100644 drivers/mtd/maps/physmap-bt1-rom.h
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index b28225a7c4f3..60b4285cd86a 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -107,6 +107,14 @@ config MTD_PHYSMAP_IXP4XX
This provides some extra DT physmap parsing for the Intel IXP4xx
platforms, some elaborate endianness handling in particular.
+config MTD_PHYSMAP_BT1_ROM
+ bool "Baikal-T1 Boot ROMs OF-based physical memory map handling"
+ depends on (MIPS_BAIKAL_T1 && MTD_PHYSMAP_OF) || COMPILE_TEST
+ select MTD_COMPLEX_MAPPINGS
+ help
+ This provides some extra DT physmap parsing for the Baikal-T1
+ platforms, some detection and setting up ROMs-specific accessors.
+
config MTD_PHYSMAP_GPIO_ADDR
bool "GPIO-assisted Flash Chip Support"
depends on MTD_PHYSMAP
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index c0da86a5d26f..45f3a151f568 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -21,6 +21,7 @@ physmap-objs-y+= physmap-core.o
physmap-objs-$(CONFIG_MTD_PHYSMAP_VERSATILE) += physmap-versatile.o
physmap-objs-$(CONFIG_MTD_PHYSMAP_GEMINI) += physmap-gemini.o
physmap-objs-$(CONFIG_MTD_PHYSMAP_IXP4XX) += physmap-ixp4xx.o
+physmap-objs-$(CONFIG_MTD_PHYSMAP_BT1_ROM) += physmap-bt1-rom.o
physmap-objs := $(physmap-objs-y)
obj-$(CONFIG_MTD_PHYSMAP) += physmap.o
obj-$(CONFIG_MTD_PISMO)+= pismo.o
diff --git a/drivers/mtd/maps/physmap-bt1-rom.c
b/drivers/mtd/maps/physmap-bt1-rom.c
new file mode 100644
index ..55149af18729
--- /dev/null
+++ b/drivers/mtd/maps/physmap-bt1-rom.c
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
+ *
+ * Authors:
+ * Serge Semin
+ *
+ * Baikal-T1 Physically Mapped ROMs driver
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "physmap-bt1-rom.h"
+
+struct bt1_rom_io {
+ map_word (*read)(struct map_info *map, unsigned long ofs);
+ void (*copy_from)(struct map_info *map, void *to, unsigned long from,
+ ssize_t len);
+};
+
+/*
+ * Baikal-T1 SoC ROMs are only accessible by the
Re: [PATCH] drm/radeon: Convert get_user_pages() --> pin_user_pages()
On 2020-05-26 14:00, Souptick Joarder wrote: This code was using get_user_pages(), in a "Case 2" scenario (DMA/RDMA), using the categorization from [1]. That means that it's time to convert the get_user_pages() + release_pages() calls to pin_user_pages() + unpin_user_pages() calls. There is some helpful background in [2]: basically, this is a small part of fixing a long-standing disconnect between pinning pages, and file systems' use of those pages. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Signed-off-by: Souptick Joarder Cc: John Hubbard Hi, I'm compile tested this, but unable to run-time test, so any testing help is much appriciated. --- drivers/gpu/drm/radeon/radeon_ttm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5d50c9e..e927de2 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -506,7 +506,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm) uint64_t userptr = gtt->userptr + pinned * PAGE_SIZE; struct page **pages = ttm->pages + pinned; - r = get_user_pages(userptr, num_pages, write ? FOLL_WRITE : 0, + r = pin_user_pages(userptr, num_pages, write ? FOLL_WRITE : 0, pages, NULL); if (r < 0) goto release_pages; @@ -535,7 +535,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm) kfree(ttm->sg); release_pages: - release_pages(ttm->pages, pinned); + unpin_user_pages(ttm->pages, pinned); return r; } @@ -562,7 +562,7 @@ static void radeon_ttm_tt_unpin_userptr(struct ttm_tt *ttm) set_page_dirty(page); Maybe we also need a preceding patch, to fix the above? It should be set_page_dirty_lock(), rather than set_page_dirty(), unless I'm overlooking something (which is very possible!). Either way, from a tunnel vision perspective of changing gup to pup, this looks good to me, so Acked-by: John Hubbard thanks, -- John Hubbard NVIDIA mark_page_accessed(page); - put_page(page); + unpin_user_page(page); } sg_free_table(ttm->sg);
[PATCH] mlxsw: spectrum_router: remove redundant initialization of pointer br_dev
From: Colin Ian King
The pointer br_dev is being initialized with a value that is never read
and is being updated with a new value later on. The initialization
is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 71aee4914619..8f485f9a07a7 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -7572,11 +7572,12 @@ static struct mlxsw_sp_fid *
mlxsw_sp_rif_vlan_fid_get(struct mlxsw_sp_rif *rif,
struct netlink_ext_ack *extack)
{
- struct net_device *br_dev = rif->dev;
+ struct net_device *br_dev;
u16 vid;
int err;
if (is_vlan_dev(rif->dev)) {
+
vid = vlan_dev_vlan_id(rif->dev);
br_dev = vlan_dev_real_dev(rif->dev);
if (WARN_ON(!netif_is_bridge_master(br_dev)))
--
2.25.1
[tip:x86/urgent] BUILD SUCCESS 187b96db5ca79423618dfa29a05c438c34f9e1f0
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent branch HEAD: 187b96db5ca79423618dfa29a05c438c34f9e1f0 x86/unwind/orc: Fix unwind_get_return_address_ptr() for inactive tasks elapsed time: 5936m configs tested: 106 configs skipped: 74 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig sh landisk_defconfig arc allyesconfig c6xevmc6472_defconfig mips ath25_defconfig arm s3c2410_defconfig sh se7722_defconfig arcvdk_hs38_defconfig arm gemini_defconfig sh sdk7786_defconfig powerpc ppc64e_defconfig h8300 defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a001-20200526 i386 randconfig-a004-20200526 i386 randconfig-a003-20200526 i386 randconfig-a006-20200526 i386 randconfig-a002-20200526 i386 randconfig-a005-20200526 x86_64 randconfig-a015-20200526 x86_64 randconfig-a013-20200526 x86_64 randconfig-a016-20200526 x86_64 randconfig-a012-20200526 x86_64 randconfig-a014-20200526 x86_64 randconfig-a011-20200526 i386 randconfig-a013-20200526 i386 randconfig-a015-20200526 i386 randconfig-a012-20200526 i386 randconfig-a011-20200526 i386 randconfig-a016-20200526 i386 randconfig-a014-20200526 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparc defconfig sparc64 allnoconfig sparcallyesconfig sparc64 defconfig sparc64 allyesconfig sparc64 allmodconfig um allmodconfig umallnoconfig um defconfig um allyesconfig x86_64 rhel x86_64
Re: [PATCH] vdpa: bypass waking up vhost_woker for vdpa vq kick
Hi Zhu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on vhost/linux-next]
[also build test WARNING on v5.7-rc7 next-20200526]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Zhu-Lingshan/vdpa-bypass-waking-up-vhost_woker-for-vdpa-vq-kick/20200526-133819
base: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=alpha
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/vhost/vdpa.c:290:6: warning: no previous prototype for
>> 'vhost_vdpa_poll_stop' [-Wmissing-prototypes]
290 | void vhost_vdpa_poll_stop(struct vhost_virtqueue *vq)
| ^~~~
>> drivers/vhost/vdpa.c:295:5: warning: no previous prototype for
>> 'vhost_vdpa_poll_start' [-Wmissing-prototypes]
295 | int vhost_vdpa_poll_start(struct vhost_virtqueue *vq)
| ^
>> drivers/vhost/vdpa.c:750:6: warning: no previous prototype for
>> 'vhost_vdpa_poll_init' [-Wmissing-prototypes]
750 | void vhost_vdpa_poll_init(struct vhost_dev *dev)
| ^~~~
vim +/vhost_vdpa_poll_stop +290 drivers/vhost/vdpa.c
276
277 static long vhost_vdpa_get_vring_num(struct vhost_vdpa *v, u16 __user
*argp)
278 {
279 struct vdpa_device *vdpa = v->vdpa;
280 const struct vdpa_config_ops *ops = vdpa->config;
281 u16 num;
282
283 num = ops->get_vq_num_max(vdpa);
284
285 if (copy_to_user(argp, , sizeof(num)))
286 return -EFAULT;
287
288 return 0;
289 }
> 290 void vhost_vdpa_poll_stop(struct vhost_virtqueue *vq)
291 {
292 vhost_poll_stop(>poll);
293 }
294
> 295 int vhost_vdpa_poll_start(struct vhost_virtqueue *vq)
296 {
297 struct vhost_poll *poll = >poll;
298 struct file *file = vq->kick;
299 __poll_t mask;
300
301
302 if (poll->wqh)
303 return 0;
304
305 mask = vfs_poll(file, >table);
306 if (mask)
307 vq->handle_kick(>poll.work);
308 if (mask & EPOLLERR) {
309 vhost_poll_stop(poll);
310 return -EINVAL;
311 }
312
313 return 0;
314 }
315
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] MAINTAINERS: Update my maintainer entries to reorder email addresses
On 5/26/20 4:27 PM, Joe Perches wrote: On Tue, 2020-05-26 at 11:04 -0600, Shuah Khan wrote: On 5/22/20 8:26 PM, Joe Perches wrote: On Fri, 2020-05-22 at 20:19 -0600, Shuah Khan wrote: get_maintainer.pl picks only the first email address found in the file. Reorder my email addresses so it finds my linuxfoundation.org email. OK. [] Sadly, people that don't run get_maintainer.pl, leave alone running it with --noremove-duplicates option. So your suggestion doesn't really help me. My preference is to get patches to both Inboxes if possible which isn't possible unless -noremove-duplicate is default. Having this option as default probably will annoy lot of people . So I am not asking for that. That being said, I don't understand your comment. Are you recommending using just one email in these entries? Yes. And maybe set an autoforward rule in that email to forward the received email to your other address. Sounds good. thanks, -- Shuah
Re: [PATCH v5 06/14] dt-bindings: PCI: cadence: Remove "mem" from reg binding
On Fri, 22 May 2020 09:06:23 +0530, Kishon Vijay Abraham I wrote: > "mem" is not a memory resource and it overlaps with PCIe config space > and memory region. Removve "mem" from reg binding. > > Signed-off-by: Kishon Vijay Abraham I > --- > .../devicetree/bindings/pci/cdns,cdns-pcie-host.yaml | 8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH net-next v2 0/2] net: enetc: remove bootloader dependency
These patches were picked from the following series: https://lore.kernel.org/netdev/1567779344-30965-1-git-send-email-claudiu.man...@nxp.com/ They have never been resent. I've picked them up, addressed Andrews comments, fixed some more bugs and asked Claudiu if I can keep their SOB tags; he agreed. I've tested this on our board which happens to have a bootloader which doesn't do the enetc setup in all cases. If my SOB is wrong in the patches, please let me know. -michael
[PATCH v3 01/10] dt-bindings: dma: dw: Convert DW DMAC to DT binding
Modern device tree bindings are supposed to be created as YAML-files in accordance with dt-schema. This commit replaces the Synopsis Designware DMA controller legacy bare text bindings with YAML file. The only required prorties are "compatible", "reg", "#dma-cells" and "interrupts", which will be used by the driver to correctly find the controller memory region and handle its events. The rest of the properties are optional, since in case if either "dma-channels" or "dma-masters" isn't specified, the driver will attempt to auto-detect the IP core configuration. Signed-off-by: Serge Semin Reviewed-by: Rob Herring Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Arnd Bergmann Cc: Andy Shevchenko Cc: linux-m...@vger.kernel.org --- Changelog v2: - Rearrange SoBs. - Move $ref to the root level of the properties. So do do with the constraints. - Discard default settings defined out of the property enum constraint. - Replace "additionalProperties: false" with "unevaluatedProperties: false" property. - Remove a label definition from the binding example. --- .../bindings/dma/snps,dma-spear1340.yaml | 161 ++ .../devicetree/bindings/dma/snps-dma.txt | 69 2 files changed, 161 insertions(+), 69 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml delete mode 100644 Documentation/devicetree/bindings/dma/snps-dma.txt diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml new file mode 100644 index ..e7611840a7cf --- /dev/null +++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml @@ -0,0 +1,161 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/snps,dma-spear1340.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys Designware DMA Controller + +maintainers: + - Viresh Kumar + - Andy Shevchenko + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: +const: snps,dma-spear1340 + + "#dma-cells": +const: 3 +description: | + First cell is a phandle pointing to the DMA controller. Second one is + the DMA request line number. Third cell is the memory master identifier + for transfers on dynamically allocated channel. Fourth cell is the + peripheral master identifier for transfers on an allocated channel. + + reg: +maxItems: 1 + + interrupts: +maxItems: 1 + + clocks: +maxItems: 1 + + clock-names: +description: AHB interface reference clock. +const: hclk + + dma-channels: +description: | + Number of DMA channels supported by the controller. In case if + not specified the driver will try to auto-detect this and + the rest of the optional parameters. +minimum: 1 +maximum: 8 + + dma-requests: +minimum: 1 +maximum: 16 + + dma-masters: +$ref: /schemas/types.yaml#definitions/uint32 +description: | + Number of DMA masters supported by the controller. In case if + not specified the driver will try to auto-detect this and + the rest of the optional parameters. +minimum: 1 +maximum: 4 + + chan_allocation_order: +$ref: /schemas/types.yaml#definitions/uint32 +description: | + DMA channels allocation order specifier. Zero means ascending order + (first free allocated), while one - descending (last free allocated). +default: 0 +enum: [0, 1] + + chan_priority: +$ref: /schemas/types.yaml#definitions/uint32 +description: | + DMA channels priority order. Zero means ascending channels priority + so the very first channel has the highest priority. While 1 means + descending priority (the last channel has the highest priority). +default: 0 +enum: [0, 1] + + block_size: +$ref: /schemas/types.yaml#definitions/uint32 +description: Maximum block size supported by the DMA controller. +enum: [3, 7, 15, 31, 63, 127, 255, 511, 1023, 2047, 4095] + + data-width: +$ref: /schemas/types.yaml#/definitions/uint32-array +description: Data bus width per each DMA master in bytes. +items: + maxItems: 4 + items: +enum: [4, 8, 16, 32] + + data_width: +$ref: /schemas/types.yaml#/definitions/uint32-array +deprecated: true +description: | + Data bus width per each DMA master in (2^n * 8) bits. This property is + deprecated. It' usage is discouraged in favor of data-width one. Moreover + the property incorrectly permits to define data-bus width of 8 and 16 + bits, which is impossible in accordance with DW DMAC IP-core data book. +items: + maxItems: 4 + items: +enum: + - 0 # 8 bits + - 1 # 16 bits + - 2 # 32 bits + - 3 # 64 bits + - 4 # 128 bits + - 5 # 256 bits +default: 0 + + multi-block: +$ref:
[PATCH v3 04/10] dmaengine: Introduce max SG list entries capability
Some devices may lack the support of the hardware accelerated SG list
entries automatic walking through and execution. In this case a burden of
the SG list traversal and DMA engine re-initialization lies on the
DMA engine driver (normally implemented by using a DMA transfer completion
IRQ to recharge the DMA device with a next SG list entry). But such
solution may not be suitable for some DMA consumers. In particular SPI
devices need both Tx and Rx DMA channels work synchronously in order
to avoid the Rx FIFO overflow. In case if Rx DMA channel is paused for
some time while the Tx DMA channel works implicitly pulling data into the
Rx FIFO, the later will be eventually overflown, which will cause the data
loss. So if SG list entries aren't automatically fetched by the DMA
engine, but are one-by-one manually selected for execution in the
ISRs/deferred work/etc., such problem will eventually happen due to the
non-deterministic latencies of the service execution.
In order to let the DMA consumer know about the DMA device capabilities
regarding the hardware accelerated SG list traversal we introduce the
max_sg_list capability. It is supposed to be initialized by the DMA engine
driver with 0 if there is no limitation for the number of SG entries
atomically executed and with non-zero value if there is such constraints,
so the upper limit is determined by the number set to the property.
Suggested-by: Andy Shevchenko
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Arnd Bergmann
Cc: Rob Herring
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinud and
Andy in the framework of DW DMA burst and LLP capabilities.
---
drivers/dma/dmaengine.c | 1 +
include/linux/dmaengine.h | 8
2 files changed, 9 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index b332ffe52780..ad56ad58932c 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -592,6 +592,7 @@ int dma_get_slave_caps(struct dma_chan *chan, struct
dma_slave_caps *caps)
caps->directions = device->directions;
caps->min_burst = device->min_burst;
caps->max_burst = device->max_burst;
+ caps->max_sg_nents = device->max_sg_nents;
caps->residue_granularity = device->residue_granularity;
caps->descriptor_reuse = device->descriptor_reuse;
caps->cmd_pause = !!device->device_pause;
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 0c7403b27133..6801200c76b6 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -467,6 +467,9 @@ enum dma_residue_granularity {
* should be checked by controller as well
* @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
+ * @max_sg_nents: max number of SG list entries executed in a single atomic
+ * DMA tansaction with no intermediate IRQ for reinitialization. Zero
+ * value means unlimited number if entries.
* @cmd_pause: true, if pause is supported (i.e. for reading residue or
*for resume later)
* @cmd_resume: true, if resume is supported
@@ -481,6 +484,7 @@ struct dma_slave_caps {
u32 directions;
u32 min_burst;
u32 max_burst;
+ u32 max_sg_nents;
bool cmd_pause;
bool cmd_resume;
bool cmd_terminate;
@@ -773,6 +777,9 @@ struct dma_filter {
* should be checked by controller as well
* @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
+ * @max_sg_nents: max number of SG list entries executed in a single atomic
+ * DMA tansaction with no intermediate IRQ for reinitialization. Zero
+ * value means unlimited number if entries.
* @residue_granularity: granularity of the transfer residue reported
* by tx_status
* @device_alloc_chan_resources: allocate resources and return the
@@ -844,6 +851,7 @@ struct dma_device {
u32 directions;
u32 min_burst;
u32 max_burst;
+ u32 max_sg_nents;
bool descriptor_reuse;
enum dma_residue_granularity residue_granularity;
--
2.26.2
[PATCH v3 03/10] dmaengine: Introduce min burst length capability
Some hardware aside from default 0/1 may have greater minimum burst
transactions length constraints. Here we introduce the DMA device
and slave capability, which if required can be initialized by the DMA
engine driver with the device-specific value.
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Arnd Bergmann
Cc: Andy Shevchenko
Cc: Rob Herring
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinud and
Andy in the framework of DW DMA burst and LLP capabilities.
---
drivers/dma/dmaengine.c | 1 +
include/linux/dmaengine.h | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index d31076d9ef25..b332ffe52780 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -590,6 +590,7 @@ int dma_get_slave_caps(struct dma_chan *chan, struct
dma_slave_caps *caps)
caps->src_addr_widths = device->src_addr_widths;
caps->dst_addr_widths = device->dst_addr_widths;
caps->directions = device->directions;
+ caps->min_burst = device->min_burst;
caps->max_burst = device->max_burst;
caps->residue_granularity = device->residue_granularity;
caps->descriptor_reuse = device->descriptor_reuse;
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index e1c03339918f..0c7403b27133 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -465,6 +465,7 @@ enum dma_residue_granularity {
* Since the enum dma_transfer_direction is not defined as bit flag for
* each type, the dma controller should set BIT() and same
* should be checked by controller as well
+ * @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
* @cmd_pause: true, if pause is supported (i.e. for reading residue or
*for resume later)
@@ -478,6 +479,7 @@ struct dma_slave_caps {
u32 src_addr_widths;
u32 dst_addr_widths;
u32 directions;
+ u32 min_burst;
u32 max_burst;
bool cmd_pause;
bool cmd_resume;
@@ -769,6 +771,7 @@ struct dma_filter {
* Since the enum dma_transfer_direction is not defined as bit flag for
* each type, the dma controller should set BIT() and same
* should be checked by controller as well
+ * @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
* @residue_granularity: granularity of the transfer residue reported
* by tx_status
@@ -839,6 +842,7 @@ struct dma_device {
u32 src_addr_widths;
u32 dst_addr_widths;
u32 directions;
+ u32 min_burst;
u32 max_burst;
bool descriptor_reuse;
enum dma_residue_granularity residue_granularity;
--
2.26.2
[PATCH v3 06/10] dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config
Full multi-block transfers functionality is enabled in DW DMA
controller only if CHx_MULTI_BLK_EN is set. But LLP-based transfers
can be executed only if hardcode channel x LLP register feature isn't
enabled, which can be switched on at the IP core synthesis for
optimization. If it's enabled then the LLP register is hardcoded to
zero, so the blocks chaining based on the LLPs is unsupported.
Signed-off-by: Serge Semin
Reviewed-by: Andy Shevchenko
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Arnd Bergmann
Cc: Rob Herring
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Add comment about why hardware accelerated LLP list support depends
on both MBLK_EN and HC_LLP configs setting.
- Use explicit bits state comparison operator.
Changelog v3:
- Move the patch to the head of the series.
---
drivers/dma/dw/core.c | 11 ++-
drivers/dma/dw/regs.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 21cb2a58dbd2..33e99d95b3d3 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1178,8 +1178,17 @@ int do_dma_probe(struct dw_dma_chip *chip)
*/
dwc->block_size =
(4 << ((pdata->block_size >> 4 * i) & 0xf)) - 1;
+
+ /*
+* According to the DW DMA databook the true scatter-
+* gether LLPs aren't available if either multi-block
+* config is disabled (CHx_MULTI_BLK_EN == 0) or the
+* LLP register is hard-coded to zeros
+* (CHx_HC_LLP == 1).
+*/
dwc->nollp =
- (dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0;
+ (dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0 ||
+ (dwc_params >> DWC_PARAMS_HC_LLP & 0x1) == 1;
} else {
dwc->block_size = pdata->block_size;
dwc->nollp = !pdata->multi_block[i];
diff --git a/drivers/dma/dw/regs.h b/drivers/dma/dw/regs.h
index 3fce66ecee7a..1ab840b06e79 100644
--- a/drivers/dma/dw/regs.h
+++ b/drivers/dma/dw/regs.h
@@ -125,6 +125,7 @@ struct dw_dma_regs {
/* Bitfields in DWC_PARAMS */
#define DWC_PARAMS_MBLK_EN 11 /* multi block transfer */
+#define DWC_PARAMS_HC_LLP 13 /* set LLP register to zero */
/* bursts size */
enum dw_dma_msize {
--
2.26.2
[PATCH v3 10/10] dmaengine: dw: Initialize max_sg_nents with nollp flag
Multi-block support provides a way to map the kernel-specific SG-table so the DW DMA device would handle it as a whole instead of handling the SG-list items or so called LLP block items one by one. So if true LLP list isn't supported by the DW DMA engine, then soft-LLP mode will be utilized to load and execute each LLP-block one by one. The soft-LLP mode of the DMA transactions execution might not work well for some DMA consumers like SPI due to its Tx and Rx buffers inter-dependency. Let's expose the nollp flag indicating the soft-LLP mode by means of the max_sg_nents capability, so the DMA consumer would be ready to somehow workaround errors caused by such mode being utilized. Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Arnd Bergmann Cc: Rob Herring Cc: linux-m...@vger.kernel.org Cc: devicet...@vger.kernel.org --- Changelog v3: - This is a new patch created as a result of the discussion with Vinud and Andy in the framework of DW DMA burst and LLP capabilities. --- drivers/dma/dw/core.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c index 29c4ef08311d..b850eb7fd084 100644 --- a/drivers/dma/dw/core.c +++ b/drivers/dma/dw/core.c @@ -1054,6 +1054,15 @@ static void dwc_caps(struct dma_chan *chan, struct dma_slave_caps *caps) struct dw_dma_chan *dwc = to_dw_dma_chan(chan); caps->max_burst = dwc->max_burst; + + /* +* It might be crucial for some devices to have the hardware +* accelerated multi-block transfers supported, aka LLPs in DW DMAC +* notation. So if LLPs are supported then max_sg_nents is set to +* zero which means unlimited number of SG entries can be handled in a +* single DMA transaction, otherwise it's just one SG entry. +*/ + caps->max_sg_nents = dwc->nollp; } int do_dma_probe(struct dw_dma_chip *chip) -- 2.26.2
[PATCH v3 00/10] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
with currently implemented in the kernel DW DMAC driver, but there are some
peculiarities which must be taken into account in order to have the device
fully supported.
First of all traditionally we replaced the legacy plain text-based dt-binding
file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
channels, which alas have different max burst length configuration.
In particular first two channels may burst up to 128 bits (16 bytes) at a time
while the rest of them just up to 32 bits. We must make sure that the DMA
subsystem doesn't set values exceeding these limitations otherwise the
controller will hang up. In third currently we discovered the problem in using
the DW APB SPI driver together with DW DMAC. The problem happens if there is no
natively implemented multi-block LLP transfers support and the SPI-transfer
length exceeds the max lock size. In this case due to asynchronous handling of
Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
the DMAC to asynchronously execute the transfers we'd have to at least warn
the user of the possible errors. In forth it's worth to set the DMA device max
segment size with max block size config specific to the DW DMA controller. It
shall help the DMA clients to create size-optimized SG-list items for the
controller. This in turn will cause less dw_desc allocations, less LLP
reinitializations, better DMA device performance.
Finally there is a bug in the algorithm of the nollp flag detection.
In particular even if DW DMAC parameters state the multi-block transfers
support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
by the driver true multi-block LLP functionality unusable. This happens cause'
if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
contiguous multi-block transfers will be only supported. We must take the
flag into account when detecting the LLP support otherwise the driver just
won't work correctly.
This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
0e698dfa2822 ("Linux 5.7-rc4")
tag: v5.7-rc4
Changelog v2:
- Rearrange SoBs.
- Move $ref to the root level of the properties. So do do with the
constraints in the DT binding.
- Replace "additionalProperties: false" with "unevaluatedProperties: false"
property in the DT binding file.
- Discard default settings defined out of property enum constraint.
- Set default max-burst-len to 256 TR-WIDTH words in the DT binding.
- Discard noLLP and block_size accessors.
- Set max segment size of the DMA device structure with the DW DMA block size
config.
- Print warning if noLLP flag is set.
- Discard max burst length accessor.
- Add comment about why hardware accelerated LLP list support depends
on both MBLK_EN and HC_LLP configs setting.
- Use explicit bits state comparison operator in noLLP flag setting.
Changelog v3:
- Use the block_size found for the very first channel instead of looking for
the maximum of maximum block sizes.
- Don't define device-specific device_dma_parameters object, since it has
already been defined by the platform device core.
- Add more details into the property description about what limitations
snps,max-burst-len defines.
- Move commit fb7e3bbfc830 ("dmaengine: dw: Take HC_LLP flag into account for
noLLP auto-config") to the head of the series.
- Add a new patch "dmaengine: Introduce min burst length capability" as a
result of the discussion with Vinod and Andy regarding the burst length
capability.
- Add a new patch "dmaengine: Introduce max SG list entries capability"
suggested by Andy.
- Add a new patch "dmaengine: Introduce DMA-device device_caps callback" as
a result of the discussion with Vinud and Andy in the framework of DW DMA
burst and LLP capabilities.
- Add a new patch "dmaengine: dw: Add dummy device_caps callback" as a
preparation commit before setting the max_burst and max_sg_nents
DW DMA capabilities.
- Override the slave channel max_burst capability instead of calculating
the minimum value of max burst lengths and setting the DMA-device
generic capability.
- Add a new patch "dmaengine: dw: Initialize max_sg_nents with nollp flag".
This is required to fix the DW APB SSI issue of the Tx and Rx DMA
channels de-synchronization.
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Maxim Kaurkin
Cc: Pavel Parkhomenko
Cc: Ramil Zaripov
Cc: Ekaterina Skachko
Cc: Vadim Vlasov
Cc: Alexey Kolotnikov
Cc: Thomas Bogendoerfer
Cc: Arnd Bergmann
Cc: Andy Shevchenko
Cc: Rob Herring
Cc: linux-m...@vger.kernel.org
Cc: dmaeng...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (10):
dt-bindings: dma: dw: Convert DW DMAC to DT binding
dt-bindings: dma: dw:
[PATCH v3 02/10] dt-bindings: dma: dw: Add max burst transaction length property
This array property is used to indicate the maximum burst transaction length supported by each DMA channel. Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Arnd Bergmann Cc: Andy Shevchenko Cc: linux-m...@vger.kernel.org --- Changelog v2: - Rearrange SoBs. - Move $ref to the root level of the properties. So do with the constraints. - Set default max-burst-len to 256 TR-WIDTH words. Changelog v3: - Add more details into the property description about what limitations snps,max-burst-len defines. --- .../bindings/dma/snps,dma-spear1340.yaml | 15 +++ 1 file changed, 15 insertions(+) diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml index e7611840a7cf..20870f5c14dd 100644 --- a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml +++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml @@ -120,6 +120,21 @@ properties: enum: [0, 1] default: 1 + snps,max-burst-len: +$ref: /schemas/types.yaml#/definitions/uint32-array +description: | + Maximum length of the burst transactions supported by the controller. + This property defines the upper limit of the run-time burst setting + (CTLx.SRC_MSIZE/CTLx.DST_MSIZE fields) so the allowed burst length + will be from 1 to max-burst-len words. It's an array property with one + cell per channel in the units determined by the value set in the + CTLx.SRC_TR_WIDTH/CTLx.DST_TR_WIDTH fields (data width). +items: + maxItems: 8 + items: +enum: [4, 8, 16, 32, 64, 128, 256] +default: 256 + snps,dma-protection-control: $ref: /schemas/types.yaml#definitions/uint32 description: | -- 2.26.2
[PATCH net-next v2 2/2] net: enetc: Use DT protocol information to set up the ports
From: Alex Marginean
Use DT information rather than in-band information from bootloader to
set up MAC for XGMII. For RGMII use the DT indication in addition to
RGMII defaults in hardware.
However, this implies that PHY connection information needs to be
extracted before netdevice creation, when the ENETC Port MAC is
being configured.
Signed-off-by: Alex Marginean
Signed-off-by: Claudiu Manoil
Signed-off-by: Michael Walle
---
.../net/ethernet/freescale/enetc/enetc_pf.c | 57 ++-
.../net/ethernet/freescale/enetc/enetc_pf.h | 3 +
2 files changed, 34 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 5836486314a7..c105bbf90aae 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -481,7 +481,8 @@ static void enetc_port_si_configure(struct enetc_si *si)
enetc_port_wr(hw, ENETC_PSIVLANFMR, ENETC_PSIVLANFMR_VS);
}
-static void enetc_configure_port_mac(struct enetc_hw *hw)
+static void enetc_configure_port_mac(struct enetc_hw *hw,
+phy_interface_t phy_mode)
{
enetc_port_wr(hw, ENETC_PM0_MAXFRM,
ENETC_SET_MAXFRM(ENETC_RX_MAXFRM_SIZE));
@@ -497,9 +498,11 @@ static void enetc_configure_port_mac(struct enetc_hw *hw)
ENETC_PM0_CMD_TXP | ENETC_PM0_PROMISC |
ENETC_PM0_TX_EN | ENETC_PM0_RX_EN);
/* set auto-speed for RGMII */
- if (enetc_port_rd(hw, ENETC_PM0_IF_MODE) & ENETC_PMO_IFM_RG)
+ if (enetc_port_rd(hw, ENETC_PM0_IF_MODE) & ENETC_PMO_IFM_RG ||
+ phy_interface_mode_is_rgmii(phy_mode))
enetc_port_wr(hw, ENETC_PM0_IF_MODE, ENETC_PM0_IFM_RGAUTO);
- if (enetc_global_rd(hw, ENETC_G_EPFBLPR(1)) == ENETC_G_EPFBLPR1_XGMII)
+
+ if (phy_mode == PHY_INTERFACE_MODE_XGMII)
enetc_port_wr(hw, ENETC_PM0_IF_MODE, ENETC_PM0_IFM_XGMII);
}
@@ -523,7 +526,7 @@ static void enetc_configure_port(struct enetc_pf *pf)
enetc_configure_port_pmac(hw);
- enetc_configure_port_mac(hw);
+ enetc_configure_port_mac(hw, pf->if_mode);
enetc_port_si_configure(pf->si);
@@ -783,27 +786,27 @@ static void enetc_mdio_remove(struct enetc_pf *pf)
mdiobus_unregister(pf->mdio);
}
-static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
+static int enetc_of_get_phy(struct enetc_pf *pf)
{
- struct enetc_pf *pf = enetc_si_priv(priv->si);
- struct device_node *np = priv->dev->of_node;
+ struct device *dev = >si->pdev->dev;
+ struct device_node *np = dev->of_node;
struct device_node *mdio_np;
int err;
- priv->phy_node = of_parse_phandle(np, "phy-handle", 0);
- if (!priv->phy_node) {
+ pf->phy_node = of_parse_phandle(np, "phy-handle", 0);
+ if (!pf->phy_node) {
if (!of_phy_is_fixed_link(np)) {
- dev_err(priv->dev, "PHY not specified\n");
+ dev_err(dev, "PHY not specified\n");
return -ENODEV;
}
err = of_phy_register_fixed_link(np);
if (err < 0) {
- dev_err(priv->dev, "fixed link registration failed\n");
+ dev_err(dev, "fixed link registration failed\n");
return err;
}
- priv->phy_node = of_node_get(np);
+ pf->phy_node = of_node_get(np);
}
mdio_np = of_get_child_by_name(np, "mdio");
@@ -811,15 +814,15 @@ static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
of_node_put(mdio_np);
err = enetc_mdio_probe(pf);
if (err) {
- of_node_put(priv->phy_node);
+ of_node_put(pf->phy_node);
return err;
}
}
- err = of_get_phy_mode(np, >if_mode);
+ err = of_get_phy_mode(np, >if_mode);
if (err) {
- dev_err(priv->dev, "missing phy type\n");
- of_node_put(priv->phy_node);
+ dev_err(dev, "missing phy type\n");
+ of_node_put(pf->phy_node);
if (of_phy_is_fixed_link(np))
of_phy_deregister_fixed_link(np);
else
@@ -831,14 +834,14 @@ static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
return 0;
}
-static void enetc_of_put_phy(struct enetc_ndev_priv *priv)
+static void enetc_of_put_phy(struct enetc_pf *pf)
{
- struct device_node *np = priv->dev->of_node;
+ struct device_node *np = pf->si->pdev->dev.of_node;
if (np && of_phy_is_fixed_link(np))
of_phy_deregister_fixed_link(np);
- if (priv->phy_node)
- of_node_put(priv->phy_node);
+ if (pf->phy_node)
+
Re: [PATCH v12 00/18] Enable FSGSBASE instructions
On Tue, May 26, 2020 at 06:03:35PM -0400, Don Porter wrote: On 5/26/20 4:27 PM, Sasha Levin wrote: I'm really worried about the disconnect between how you view the current state of Graphene (and the industry) vs Intel and the various cloud providers. You keep suggesting that its just past the academic research state, while Intel and the big cloud providers are already pushing it to external customers. Every one of those cloud providers has a preview/GA secure enclave offering. I wonder if you are conflating Graphene with SGX? I understand that many cloud vendors are offering SGX in preview/GA, but there are other frameworks to build these offerings on, such as Intel's SGX SDK or Haven. It would be news to me if every major cloud vendor were putting Graphene in production. Sorry, I wasn't trying to suggest that all cloud vendors are pushing Graphene, but rather than SGX enabled platforms became a commodity product, users will end up using Graphene-like applications. Let me provide an example: https://www.alibabacloud.com/blog/protecting-go-language-applications-with-the-graphene-library-os-on-intel%C2%AE-sgx%C2%AE-secured-alibaba-cloud_594889 - a "practical" guide on how to run Graphene in production environment on one of the big cloud vendor platforms. -- Thanks, Sasha
[PATCH v3 05/10] dmaengine: Introduce DMA-device device_caps callback
There are DMA devices (like ours version of Synopsys DW DMAC) which have
DMA capabilities non-uniformly redistributed amongst the device channels.
In order to provide a way of exposing the channel-specific parameters to
the DMA engine consumers, we introduce a new DMA-device callback. In case
if provided it gets called from the dma_get_slave_caps() method and is
able to override the generic DMA-device capabilities.
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Arnd Bergmann
Cc: Andy Shevchenko
Cc: Rob Herring
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinod and
Andy in the framework of DW DMA burst and LLP capabilities.
---
drivers/dma/dmaengine.c | 3 +++
include/linux/dmaengine.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index ad56ad58932c..edbb11d56cde 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -599,6 +599,9 @@ int dma_get_slave_caps(struct dma_chan *chan, struct
dma_slave_caps *caps)
caps->cmd_resume = !!device->device_resume;
caps->cmd_terminate = !!device->device_terminate_all;
+ if (device->device_caps)
+ device->device_caps(chan, caps);
+
return 0;
}
EXPORT_SYMBOL_GPL(dma_get_slave_caps);
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 6801200c76b6..429eef3a702b 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -899,6 +899,8 @@ struct dma_device {
struct dma_chan *chan, dma_addr_t dst, u64 data,
unsigned long flags);
+ void (*device_caps)(struct dma_chan *chan,
+ struct dma_slave_caps *caps);
int (*device_config)(struct dma_chan *chan,
struct dma_slave_config *config);
int (*device_pause)(struct dma_chan *chan);
--
2.26.2
[PATCH net-next v2 1/2] net: enetc: Initialize SerDes for SGMII and SXGMII protocols
From: Claudiu Manoil
ENETC has ethernet MACs capable of SGMII and SXGMII but in order to use
these protocols some serdes configurations need to be performed. The
SerDes is configurable via an internal MDIO bus connected to an internal
PCS device, all reads/writes are performed at address 0.
This patch basically removes the dependency on bootloader regarding
SerDes initialization.
Signed-off-by: Alex Marginean
Signed-off-by: Claudiu Manoil
Signed-off-by: Michael Walle
---
.../net/ethernet/freescale/enetc/enetc_hw.h | 17
.../net/ethernet/freescale/enetc/enetc_pf.c | 98 +++
.../net/ethernet/freescale/enetc/enetc_pf.h | 1 +
3 files changed, 116 insertions(+)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
index 6314051bc6c1..ee5851486388 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
@@ -224,6 +224,23 @@ enum enetc_bdr_type {TX, RX};
#define ENETC_PM0_MAXFRM 0x8014
#define ENETC_SET_TX_MTU(val) ((val) << 16)
#define ENETC_SET_MAXFRM(val) ((val) & 0x)
+
+#define ENETC_PM_IMDIO_BASE0x8030
+/* PCS registers */
+#define ENETC_PCS_CR 0x0
+#define ENETC_PCS_CR_RESET_AN 0x1200
+#define ENETC_PCS_CR_DEF_VAL 0x0140
+#define ENETC_PCS_CR_LANE_RESET0x8000
+#define ENETC_PCS_DEV_ABILITY 0x04
+#define ENETC_PCS_DEV_ABILITY_SGMII0x4001
+#define ENETC_PCS_DEV_ABILITY_SXGMII 0x5001
+#define ENETC_PCS_LINK_TIMER1 0x12
+#define ENETC_PCS_LINK_TIMER1_VAL 0x06a0
+#define ENETC_PCS_LINK_TIMER2 0x13
+#define ENETC_PCS_LINK_TIMER2_VAL 0x0003
+#define ENETC_PCS_IF_MODE 0x14
+#define ENETC_PCS_IF_MODE_SGMII_AN 0x0003
+
#define ENETC_PM0_IF_MODE 0x8300
#define ENETC_PMO_IFM_RG BIT(2)
#define ENETC_PM0_IFM_RLP (BIT(5) | BIT(11))
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 824d211ec00f..5836486314a7 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -841,6 +841,99 @@ static void enetc_of_put_phy(struct enetc_ndev_priv *priv)
of_node_put(priv->phy_node);
}
+static int enetc_imdio_init(struct enetc_pf *pf)
+{
+ struct device *dev = >si->pdev->dev;
+ struct enetc_mdio_priv *mdio_priv;
+ struct mii_bus *bus;
+ int err;
+
+ bus = devm_mdiobus_alloc_size(dev, sizeof(*mdio_priv));
+ if (!bus)
+ return -ENOMEM;
+
+ bus->name = "Freescale ENETC internal MDIO Bus";
+ bus->read = enetc_mdio_read;
+ bus->write = enetc_mdio_write;
+ bus->parent = dev;
+ bus->phy_mask = ~0;
+ mdio_priv = bus->priv;
+ mdio_priv->hw = >si->hw;
+ mdio_priv->mdio_base = ENETC_PM_IMDIO_BASE;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "imdio-%s", dev_name(dev));
+
+ err = mdiobus_register(bus);
+ if (err) {
+ dev_err(dev, "cannot register internal MDIO bus (%d)\n", err);
+ devm_mdiobus_free(dev, bus);
+ return err;
+ }
+
+ pf->imdio = bus;
+
+ return 0;
+}
+
+static void enetc_imdio_remove(struct enetc_pf *pf)
+{
+ if (pf->imdio)
+ mdiobus_unregister(pf->imdio);
+}
+
+static void enetc_configure_sgmii(struct mii_bus *imdio)
+{
+ /* Set to SGMII mode, use AN */
+ mdiobus_write(imdio, 0, ENETC_PCS_IF_MODE,
+ ENETC_PCS_IF_MODE_SGMII_AN);
+
+ /* Dev ability - SGMII */
+ mdiobus_write(imdio, 0, ENETC_PCS_DEV_ABILITY,
+ ENETC_PCS_DEV_ABILITY_SGMII);
+
+ /* Adjust link timer for SGMII */
+ mdiobus_write(imdio, 0, ENETC_PCS_LINK_TIMER1,
+ ENETC_PCS_LINK_TIMER1_VAL);
+ mdiobus_write(imdio, 0, ENETC_PCS_LINK_TIMER2,
+ ENETC_PCS_LINK_TIMER2_VAL);
+
+ /* restart PCS AN */
+ mdiobus_write(imdio, 0, ENETC_PCS_CR,
+ ENETC_PCS_CR_RESET_AN | ENETC_PCS_CR_DEF_VAL);
+}
+
+static void enetc_configure_sxgmii(struct mii_bus *imdio)
+{
+ /* Dev ability - SXGMII */
+ mdiobus_write(imdio, 0, ENETC_PCS_DEV_ABILITY | MII_ADDR_C45,
+ ENETC_PCS_DEV_ABILITY_SXGMII);
+
+ /* Restart PCS AN */
+ mdiobus_write(imdio, 0, ENETC_PCS_CR | MII_ADDR_C45,
+ ENETC_PCS_CR_LANE_RESET | ENETC_PCS_CR_RESET_AN);
+}
+
+static int enetc_configure_serdes(struct enetc_ndev_priv *priv)
+{
+ struct enetc_pf *pf = enetc_si_priv(priv->si);
+ int err;
+
+ if (priv->if_mode != PHY_INTERFACE_MODE_SGMII &&
+ priv->if_mode != PHY_INTERFACE_MODE_XGMII)
+ return 0;
+
+ err = enetc_imdio_init(pf);
+ if (err)
+ return err;
+
+ if (priv->if_mode == PHY_INTERFACE_MODE_SGMII)
+
[PATCH v3 07/10] dmaengine: dw: Set DMA device max segment size parameter
Maximum block size DW DMAC configuration corresponds to the max segment size DMA parameter in the DMA core subsystem notation. Lets set it with a value specific to the probed DW DMA controller. It shall help the DMA clients to create size-optimized SG-list items for the controller. This in turn will cause less dw_desc allocations, less LLP reinitializations, better DMA device performance. Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Arnd Bergmann Cc: Rob Herring Cc: linux-m...@vger.kernel.org Cc: devicet...@vger.kernel.org --- Changelog v2: - This is a new patch created in place of the dropped one: "dmaengine: dw: Add LLP and block size config accessors". Changelog v3: - Use the block_size found for the very first channel instead of looking for the maximum of maximum block sizes. - Don't define device-specific device_dma_parameters object, since it has already been defined by the platform device core. --- drivers/dma/dw/core.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c index 33e99d95b3d3..fb95920c429e 100644 --- a/drivers/dma/dw/core.c +++ b/drivers/dma/dw/core.c @@ -1229,6 +1229,13 @@ int do_dma_probe(struct dw_dma_chip *chip) BIT(DMA_MEM_TO_MEM); dw->dma.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST; + /* +* For now there is no hardware with non uniform maximum block size +* across all of the device channels, so we set the maximum segment +* size as the block size found for the very first channel. +*/ + dma_set_max_seg_size(dw->dma.dev, dw->chan[0].block_size); + err = dma_async_device_register(>dma); if (err) goto err_dma_register; -- 2.26.2
[PATCH v3 08/10] dmaengine: dw: Add dummy device_caps callback
Since some DW DMA controllers (like one installed on Baikal-T1 SoC) may
have non-uniform DMA capabilities per device channels, let's add
the DW DMA specific device_caps callback to expose that specifics up to
the DMA consumer. It's a dummy function for now. We'll fill it in with
capabilities overrides in the next commits.
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Arnd Bergmann
Cc: Rob Herring
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinud and
Andy in the framework of DW DMA burst and LLP capabilities.
---
drivers/dma/dw/core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index fb95920c429e..ceded21537e2 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1049,6 +1049,11 @@ static void dwc_free_chan_resources(struct dma_chan
*chan)
dev_vdbg(chan2dev(chan), "%s: done\n", __func__);
}
+static void dwc_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
+{
+
+}
+
int do_dma_probe(struct dw_dma_chip *chip)
{
struct dw_dma *dw = chip->dw;
@@ -1214,6 +1219,7 @@ int do_dma_probe(struct dw_dma_chip *chip)
dw->dma.device_prep_dma_memcpy = dwc_prep_dma_memcpy;
dw->dma.device_prep_slave_sg = dwc_prep_slave_sg;
+ dw->dma.device_caps = dwc_caps;
dw->dma.device_config = dwc_config;
dw->dma.device_pause = dwc_pause;
dw->dma.device_resume = dwc_resume;
--
2.26.2
[PATCH v3 09/10] dmaengine: dw: Introduce max burst length hw config
IP core of the DW DMA controller may be synthesized with different
max burst length of the transfers per each channel. According to Synopsis
having the fixed maximum burst transactions length may provide some
performance gain. At the same time setting up the source and destination
multi size exceeding the max burst length limitation may cause a serious
problems. In our case the DMA transaction just hangs up. In order to fix
this lets introduce the max burst length platform config of the DW DMA
controller device and don't let the DMA channels configuration code
exceed the burst length hardware limitation.
Note the maximum burst length parameter can be detected either in runtime
from the DWC parameter registers or from the dedicated DT property.
Depending on the IP core configuration the maximum value can vary from
channel to channel so by overriding the channel slave max_burst capability
we make sure a DMA consumer will get the channel-specific max burst
length.
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Arnd Bergmann
Cc: Rob Herring
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Discard dwc_get_maxburst() accessor. It's enough to have a clamping
guard against exceeding the hardware max burst limitation.
Changelog v3:
- Override the slave channel max_burst capability instead of calculating
the minimum value of max burst lengths and setting the DMA-device
generic capability.
---
drivers/dma/dw/core.c| 5 +
drivers/dma/dw/dw.c | 1 +
drivers/dma/dw/of.c | 9 +
drivers/dma/dw/regs.h| 2 ++
include/linux/platform_data/dma-dw.h | 4
5 files changed, 21 insertions(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index ceded21537e2..29c4ef08311d 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1051,7 +1051,9 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
static void dwc_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
{
+ struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
+ caps->max_burst = dwc->max_burst;
}
int do_dma_probe(struct dw_dma_chip *chip)
@@ -1194,9 +1196,12 @@ int do_dma_probe(struct dw_dma_chip *chip)
dwc->nollp =
(dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0 ||
(dwc_params >> DWC_PARAMS_HC_LLP & 0x1) == 1;
+ dwc->max_burst =
+ (0x4 << (dwc_params >> DWC_PARAMS_MSIZE & 0x7));
} else {
dwc->block_size = pdata->block_size;
dwc->nollp = !pdata->multi_block[i];
+ dwc->max_burst = pdata->max_burst[i] ?:
DW_DMA_MAX_BURST;
}
}
diff --git a/drivers/dma/dw/dw.c b/drivers/dma/dw/dw.c
index 7a085b3c1854..4d6b1ecabda4 100644
--- a/drivers/dma/dw/dw.c
+++ b/drivers/dma/dw/dw.c
@@ -86,6 +86,7 @@ static void dw_dma_encode_maxburst(struct dw_dma_chan *dwc,
u32 *maxburst)
* Fix burst size according to dw_dmac. We need to convert them as:
* 1 -> 0, 4 -> 1, 8 -> 2, 16 -> 3.
*/
+ *maxburst = clamp(*maxburst, 0U, dwc->max_burst);
*maxburst = *maxburst > 1 ? fls(*maxburst) - 2 : 0;
}
diff --git a/drivers/dma/dw/of.c b/drivers/dma/dw/of.c
index 9e27831dee32..d7323aad7cb5 100644
--- a/drivers/dma/dw/of.c
+++ b/drivers/dma/dw/of.c
@@ -98,6 +98,15 @@ struct dw_dma_platform_data *dw_dma_parse_dt(struct
platform_device *pdev)
pdata->multi_block[tmp] = 1;
}
+ if (!of_property_read_u32_array(np, "snps,max-burst-len", mb,
+ nr_channels)) {
+ for (tmp = 0; tmp < nr_channels; tmp++)
+ pdata->max_burst[tmp] = mb[tmp];
+ } else {
+ for (tmp = 0; tmp < nr_channels; tmp++)
+ pdata->max_burst[tmp] = DW_DMA_MAX_BURST;
+ }
+
if (!of_property_read_u32(np, "snps,dma-protection-control", )) {
if (tmp > CHAN_PROTCTL_MASK)
return NULL;
diff --git a/drivers/dma/dw/regs.h b/drivers/dma/dw/regs.h
index 1ab840b06e79..76654bd13c1a 100644
--- a/drivers/dma/dw/regs.h
+++ b/drivers/dma/dw/regs.h
@@ -126,6 +126,7 @@ struct dw_dma_regs {
/* Bitfields in DWC_PARAMS */
#define DWC_PARAMS_MBLK_EN 11 /* multi block transfer */
#define DWC_PARAMS_HC_LLP 13 /* set LLP register to zero */
+#define DWC_PARAMS_MSIZE 16 /* max group transaction size */
/* bursts size */
enum dw_dma_msize {
@@ -284,6 +285,7 @@ struct dw_dma_chan {
/* hardware configuration */
unsigned intblock_size;
boolnollp;
+ u32 max_burst;
/* custom slave configuration */
struct
[PATCH net-next v2 0/2] net: enetc: remove bootloader dependency
These patches were picked from the following series: https://lore.kernel.org/netdev/1567779344-30965-1-git-send-email-claudiu.man...@nxp.com/ They have never been resent. I've picked them up, addressed Andrews comments, fixed some more bugs and asked Claudiu if I can keep their SOB tags; he agreed. I've tested this on our board which happens to have a bootloader which doesn't do the enetc setup in all cases. changes since v1: - mdiobus id is '"imdio-%s", dev_name(dev)' because the plain dev_name() is used by the emdio. - use mdiobus_write() instead of imdio->write(imdio, ..), since this is already a full featured mdiobus - set phy_mask to ~0 to avoid scanning the bus - use phy_interface_mode_is_rgmii(phy_mode) to also include the RGMII modes with pad delays. - move enetc_imdio_init() to enetc_pf.c, there shouldn't be any other users, should it? - renamed serdes to SerDes - printing the error code of mdiobus_register() in the error path - call mdiobus_unregister() on _remove() - call devm_mdiobus_free() if mdiobus_register() fails, since an error is not fatal Alex Marginean (1): net: enetc: Use DT protocol information to set up the ports Claudiu Manoil (1): net: enetc: Initialize SerDes for SGMII and SXGMII protocols .../net/ethernet/freescale/enetc/enetc_hw.h | 17 ++ .../net/ethernet/freescale/enetc/enetc_pf.c | 151 +++--- .../net/ethernet/freescale/enetc/enetc_pf.h | 4 + 3 files changed, 148 insertions(+), 24 deletions(-) -- 2.20.1
Re: [PATCH 08/10] rcu: Allow to deactivate nocb on a CPU
On Tue, May 26, 2020 at 05:20:17PM -0400, Joel Fernandes wrote:
> > The switch happens on the target with IRQs disabled and rdp->nocb_lock
> > held to avoid races between local callbacks handling and kthread
> > offloaded callbacks handling.
> > nocb_cb kthread is first parked to avoid any future race with
> > concurrent rcu_do_batch() executions. Then the cblist is set to offloaded
> > so that the nocb_gp kthread ignores this rdp.
>
> nit: you mean cblist is set to non-offloaded mode right?
>
> Also, could you clarify better the rcu_barrier bits in the changelog. I know
> there's some issue if the cblist has both offloaded and non-offloaded
> callbacks, but it would be good to clarify this here better IMHO.
And for archival purposes: rcu_barrier needs excluding here because it is
possible that for a brief period of time, the callback kthread has been
parked to do the mode-switch, and it could be executing a bunch of callbacks
when it was asked to park.
Meanwhile, more interrupts happen and more callbacks are queued which are now
executing in softirq. This ruins the ordering of callbacks that rcu_barrier
needs.
thanks,
- Joel
>
> [...]
> > diff --git a/kernel/rcu/rcu_segcblist.c b/kernel/rcu/rcu_segcblist.c
> > index d8ea2bef5574..4bed48da7702 100644
> > --- a/kernel/rcu/rcu_segcblist.c
> > +++ b/kernel/rcu/rcu_segcblist.c
> > @@ -171,9 +171,9 @@ void rcu_segcblist_disable(struct rcu_segcblist *rsclp)
> > * Mark the specified rcu_segcblist structure as offloaded. This
> > * structure must be empty.
> > */
> > -void rcu_segcblist_offload(struct rcu_segcblist *rsclp)
> > +void rcu_segcblist_offload(struct rcu_segcblist *rsclp, bool offload)
> > {
> > - rsclp->offloaded = 1;
> > + rsclp->offloaded = offload;
> > }
> > #endif
> >
> > diff --git a/kernel/rcu/rcu_segcblist.h b/kernel/rcu/rcu_segcblist.h
> > index 4c1503a82492..8f7c6c34cb1b 100644
> > --- a/kernel/rcu/rcu_segcblist.h
> > +++ b/kernel/rcu/rcu_segcblist.h
> > @@ -83,7 +83,7 @@ void rcu_segcblist_inc_len(struct rcu_segcblist *rsclp);
> > void rcu_segcblist_init(struct rcu_segcblist *rsclp);
> > void rcu_segcblist_disable(struct rcu_segcblist *rsclp);
> > #ifdef CONFIG_RCU_NOCB_CPU
> > -void rcu_segcblist_offload(struct rcu_segcblist *rsclp);
> > +void rcu_segcblist_offload(struct rcu_segcblist *rsclp, bool offload);
> > #endif
> > bool rcu_segcblist_ready_cbs(struct rcu_segcblist *rsclp);
> > bool rcu_segcblist_pend_cbs(struct rcu_segcblist *rsclp);
> > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> > index f19e81e0c691..c74a4df8d5f2 100644
> > --- a/kernel/rcu/tree_plugin.h
> > +++ b/kernel/rcu/tree_plugin.h
> > @@ -1943,6 +1943,10 @@ static void nocb_gp_wait(struct rcu_data *my_rdp)
> > for (rdp = my_rdp; rdp; rdp = rdp->nocb_next_cb_rdp) {
> > trace_rcu_nocb_wake(rcu_state.name, rdp->cpu, TPS("Check"));
> > raw_spin_lock_irqsave(>nocb_lock, flags);
> > + if (!rcu_segcblist_is_offloaded(>cblist)) {
> > + raw_spin_unlock_irqrestore(>nocb_lock, flags);
> > + continue;
> > + }
> > bypass_ncbs = rcu_cblist_n_cbs(>nocb_bypass);
> > if (bypass_ncbs &&
> > (time_after(j, READ_ONCE(rdp->nocb_bypass_first) + 1) ||
> > @@ -2176,6 +2180,50 @@ static void do_nocb_deferred_wakeup(struct rcu_data
> > *rdp)
> > do_nocb_deferred_wakeup_common(rdp);
> > }
> >
> > +static void __rcu_nocb_rdp_deoffload(struct rcu_data *rdp)
> > +{
> > + unsigned long flags;
> > + struct rcu_node *rnp = rdp->mynode;
> > +
> > + printk("De-offloading %d\n", rdp->cpu);
>
> nit: s/printk/pr_debug/ ?
>
> thanks,
>
> - Joel
>
> > + kthread_park(rdp->nocb_cb_kthread);
> > +
> > + raw_spin_lock_irqsave(>nocb_lock, flags);
> > + rcu_nocb_flush_bypass(rdp, NULL, jiffies);
> > + raw_spin_lock_rcu_node(rnp);
> > + rcu_segcblist_offload(>cblist, false);
> > + raw_spin_unlock_rcu_node(rnp);
> > + raw_spin_unlock_irqrestore(>nocb_lock, flags);
> > +}
> > +
> > +static long rcu_nocb_rdp_deoffload(void *arg)
> > +{
> > + struct rcu_data *rdp = arg;
> > +
> > + WARN_ON_ONCE(rdp->cpu != raw_smp_processor_id());
> > + __rcu_nocb_rdp_deoffload(rdp);
> > +
> > + return 0;
> > +}
> > +
> > +void rcu_nocb_cpu_deoffload(int cpu)
> > +{
> > + struct rcu_data *rdp = per_cpu_ptr(_data, cpu);
> > +
> > + mutex_lock(_state.barrier_mutex);
> > + cpus_read_lock();
> > + if (rcu_segcblist_is_offloaded(>cblist)) {
> > + if (cpu_online(cpu)) {
> > + work_on_cpu(cpu, rcu_nocb_rdp_deoffload, rdp);
> > + } else {
> > + __rcu_nocb_rdp_deoffload(rdp);
> > + }
> > + cpumask_clear_cpu(cpu, rcu_nocb_mask);
> > + }
> > + cpus_read_unlock();
> > + mutex_unlock(_state.barrier_mutex);
> > +}
> > +
> > void __init rcu_init_nohz(void)
> > {
> > int cpu;
> > @@ -2218,7 +2266,7 @@ void __init rcu_init_nohz(void)
>
[PATCH][next] block: blk-crypto-fallback: remove redundant initialization of variable err
From: Colin Ian King
The variable err is being initialized with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
block/blk-crypto-fallback.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-crypto-fallback.c b/block/blk-crypto-fallback.c
index 74ab137ae3ba..6e49688a2d80 100644
--- a/block/blk-crypto-fallback.c
+++ b/block/blk-crypto-fallback.c
@@ -529,7 +529,7 @@ static bool blk_crypto_fallback_inited;
static int blk_crypto_fallback_init(void)
{
int i;
- int err = -ENOMEM;
+ int err;
if (blk_crypto_fallback_inited)
return 0;
--
2.25.1
Re: [PATCH 4/6] mm/hmm: add output flag for compound page mapping
On 5/26/20 3:29 PM, Zi Yan wrote: On 8 May 2020, at 16:06, Ralph Campbell wrote: On 5/8/20 12:51 PM, Christoph Hellwig wrote: On Fri, May 08, 2020 at 12:20:07PM -0700, Ralph Campbell wrote: hmm_range_fault() returns an array of page frame numbers and flags for how the pages are mapped in the requested process' page tables. The PFN can be used to get the struct page with hmm_pfn_to_page() and the page size order can be determined with compound_order(page) but if the page is larger than order 0 (PAGE_SIZE), there is no indication that the page is mapped using a larger page size. To be fully general, hmm_range_fault() would need to return the mapping size to handle cases like a 1GB compound page being mapped with 2MB PMD entries. However, the most common case is the mapping size the same as the underlying compound page size. Add a new output flag to indicate this so that callers know it is safe to use a large device page table mapping if one is available. Why do you need the flag? The caller should be able to just use page_size() (or willys new thp_size helper). The question is whether or not a large page can be mapped with smaller page table entries with different permissions. If one process has a 2MB page mapped with 4K PTEs with different read/write permissions, I don't think it would be OK for a device to map the whole 2MB with write access enabled. The flag is supposed to indicate that the whole page can be mapped by the device with the indicated read/write permissions. If hmm_range_fault() only walks one VMA at a time, you would not have this permission issue, right? Since all pages from one VMA should have the same permission. But it seems that hmm_range_fault() deals with pages across multiple VMAs. Maybe we should make hmm_range_fault() bail out early when it encounters a VMA with a different permission than the existing ones? — Best Regards, Yan Zi I don't think so. The VMA might have read/write permission but the page table might have read-only permission in order to trigger a fault for copy-on-write. Or the PTE might be read-only or invalid to trigger faults for architectures that don't have hardware updated accessed bits and are using the minor faults to update LRU. The goal is that the MM core see the same faults whether the HMM device accesses memory or a CPU thread.
Re: [PATCH v3 0/8] kernel: taint when the driver firmware crashes
On Tue, 26 May 2020 14:58:07 + Luis Chamberlain wrote: > To those new on CC -- this is intended to be a simple generic interface > to the kernel to annotate when the firwmare has crashed leaving the > driver or system in a questionable state, in the worst case requiring > full system reboot. This series is first addressing only a few > networking patches, however, I already have an idea of where such > firmware crashes happen across the tree. The goal with this series then > is to first introduce the simple framework, and only if that moves > forward will I continue to chug on with the rest of the drivers / > subsystems. > > This is *not* a networking specific problem only. > > This v3 augments the last series by introducing the uevent for panic > events, one of them is during tainting. The uvent mechanism is > independent from any of this firmware taint mechanism. I've also > addressed Jessica Yu's feedback. Given I've extended the patches a bit > with other minor cleanup which checkpatch.pl complains over, and since > this infrastructure is still being discussed, I've trimmed the patch > series size to only cover drivers for which I've received an Acked-by > from the respective driver maintainer, or where we have bug reports to > support such dire situations on the driver such as ath10k. > > During the last v2 it was discussed that we should instead use devlink > for this work, however the initial RFC patches produced by Jakub > Kicinski [0] shows how devlink is networking specific, and the intent > behind this series is to produce simple helpers which can be used by *any* > device driver, for any subsystem, not just networking. Subsystem > specific infrastructure to help address firwmare crashes may still make > sense, however that does not mean we *don't* need something even more > generic regardless of the subsystem the issue happens on. Since uevents > for taints are exposed, we now expose these through uapi as well, and > that was something which eventually had to happen given that the current > scheme of relying on sensible character representations for each taint > will not scale beyond the alphabet. Nacked-by: Jakub Kicinski
[PATCH] clk: versatile: remove redundant assignment to pointer clk
From: Colin Ian King
The pointer clk is being initialized with a value that is never read
and is being updated with a new value later on. The initialization
is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/clk/versatile/clk-versatile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/versatile/clk-versatile.c
b/drivers/clk/versatile/clk-versatile.c
index fd54d5c0251c..8ed7a179f651 100644
--- a/drivers/clk/versatile/clk-versatile.c
+++ b/drivers/clk/versatile/clk-versatile.c
@@ -56,7 +56,7 @@ static const struct clk_icst_desc versatile_auxosc_desc
__initconst = {
static void __init cm_osc_setup(struct device_node *np,
const struct clk_icst_desc *desc)
{
- struct clk *clk = ERR_PTR(-EINVAL);
+ struct clk *clk;
const char *clk_name = np->name;
const char *parent_name;
--
2.25.1
Re: [PATCH] fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info()
On Mon, May 25, 2020 at 12:45:35AM +0100, Al Viro wrote:
> On Wed, May 13, 2020 at 04:33:49AM +0100, Al Viro wrote:
>
> > FWIW, what I'm going to do is
> > * make all callers of copy_regset_to_user() pass 0 as pos
> > (there are very few exceptions - one on arm64, three on sparc32
> > and five on sparc64; I hadn't dealt with arm64 one yet, but all
> > cases on sparc are handled)
>
> [snip]
>
> Any of that would be easy to backport, though. Several questions
> regaring XSAVE and friends:
>
> * do we ever run on XSAVE/XSAVES-capable hardware with XFEATURE_FP
> turned off?
>
> * is it possible for x86 to have gaps between the state components
> area as reported by CPUID 0x0d? IOW, can area for feature 2
> (XFEATURE_YMM) to start *not* at 0x200 and can area for N start
> not right after the end of area for N-1 for some N > 2?
>
> I think I have an easy-to-backport solution, but I'm really confused
> about XFEATURE_FP situation...
Folks, could you test the following?
copy_xstate_to_kernel(): don't leave parts of destination uninitialized
copy the corresponding pieces of init_fpstate into the gaps instead.
Signed-off-by: Al Viro
---
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 32b153d38748..6a54e83d5589 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -957,18 +957,31 @@ static inline bool xfeatures_mxcsr_quirk(u64 xfeatures)
return true;
}
-/*
- * This is similar to user_regset_copyout(), but will not add offset to
- * the source data pointer or increment pos, count, kbuf, and ubuf.
- */
-static inline void
-__copy_xstate_to_kernel(void *kbuf, const void *data,
- unsigned int offset, unsigned int size, unsigned int
size_total)
+static void fill_gap(unsigned to, void **kbuf, unsigned *pos, unsigned *count)
{
- if (offset < size_total) {
- unsigned int copy = min(size, size_total - offset);
+ if (*pos < to) {
+ unsigned size = to - *pos;
+
+ if (size > *count)
+ size = *count;
+ memcpy(*kbuf, (void *)_fpstate.xsave + *pos, size);
+ *kbuf += size;
+ *pos += size;
+ *count -= size;
+ }
+}
- memcpy(kbuf + offset, data, copy);
+static void copy_part(unsigned offset, unsigned size, void *from,
+ void **kbuf, unsigned *pos, unsigned *count)
+{
+ fill_gap(offset, kbuf, pos, count);
+ if (size > *count)
+ size = *count;
+ if (size) {
+ memcpy(*kbuf, from, size);
+ *kbuf += size;
+ *pos += size;
+ *count -= size;
}
}
@@ -981,8 +994,9 @@ __copy_xstate_to_kernel(void *kbuf, const void *data,
*/
int copy_xstate_to_kernel(void *kbuf, struct xregs_state *xsave, unsigned int
offset_start, unsigned int size_total)
{
- unsigned int offset, size;
struct xstate_header header;
+ const unsigned off_mxcsr = offsetof(struct fxregs_state, mxcsr);
+ unsigned count = size_total;
int i;
/*
@@ -998,46 +1012,42 @@ int copy_xstate_to_kernel(void *kbuf, struct xregs_state
*xsave, unsigned int of
header.xfeatures = xsave->header.xfeatures;
header.xfeatures &= ~XFEATURE_MASK_SUPERVISOR;
+ if (header.xfeatures & XFEATURE_MASK_FP)
+ copy_part(0, off_mxcsr,
+ >i387, , _start, );
+ if (header.xfeatures & (XFEATURE_MASK_SSE | XFEATURE_MASK_YMM))
+ copy_part(off_mxcsr, MXCSR_AND_FLAGS_SIZE,
+ >i387.mxcsr, , _start, );
+ if (header.xfeatures & XFEATURE_MASK_FP)
+ copy_part(offsetof(struct fxregs_state, st_space), 128,
+ >i387.st_space, , _start, );
+ if (header.xfeatures & XFEATURE_MASK_SSE)
+ copy_part(xstate_offsets[XFEATURE_MASK_SSE], 256,
+ >i387.xmm_space, , _start, );
+ /*
+* Fill xsave->i387.sw_reserved value for ptrace frame:
+*/
+ copy_part(offsetof(struct fxregs_state, sw_reserved), 48,
+ xstate_fx_sw_bytes, , _start, );
/*
* Copy xregs_state->header:
*/
- offset = offsetof(struct xregs_state, header);
- size = sizeof(header);
-
- __copy_xstate_to_kernel(kbuf, , offset, size, size_total);
+ copy_part(offsetof(struct xregs_state, header), sizeof(header),
+ , , _start, );
- for (i = 0; i < XFEATURE_MAX; i++) {
+ for (i = FIRST_EXTENDED_XFEATURE; i < XFEATURE_MAX; i++) {
/*
* Copy only in-use xstates:
*/
if ((header.xfeatures >> i) & 1) {
void *src = __raw_xsave_addr(xsave, i);
- offset = xstate_offsets[i];
- size = xstate_sizes[i];
-
- /* The
Re: [RESEND][V5 PATCH 1/2] dt-bindings: Added device tree binding for max98390
On Mon, May 18, 2020 at 09:49:30AM +0900, Steve Lee wrote:
> Add documentation for DT binding of max98390 amplifier driver.
>
> Signed-off-by: Steve Lee
> ---
>
>
> Changed since V4:
> * No changes.
> Changed since V3:
> * No changes.
> Changed since V2:
> * No changes.
> Changed since V1:
> * Modified sample text in example
You are obviously sending patches too quickly. Give folks a chance to
review.
>
> .../devicetree/bindings/sound/max98390.txt| 26 +++
Bindings are now in DT schema format. Please convert this. See
Documentation/devicetree/writing-schema.rst
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/max98390.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/max98390.txt
> b/Documentation/devicetree/bindings/sound/max98390.txt
> new file mode 100644
> index ..0ddd4c6ae55e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/max98390.txt
> @@ -0,0 +1,26 @@
> +Maxim Integrated MAX98390 Speaker Amplifier
> +
> +This device supports I2C.
> +
> +Required properties:
> +
> + - compatible : "maxim,max98390"
> +
> + - reg : the I2C address of the device.
> +
> +Optional properties:
> +
> +- maxim,temperature_calib
> + u32. The calculated temperature data was measured while doing the
> calibration. Data : Temp / 100 * 2^12
> +
> +- maxim,r0_calib
> + u32. This is r0 calibration data which was measured in factory mode.
Unless these are shared already with other Maxim chips, s/_/-/.
> +
> +Example:
> +
> +codec: max98390@38 {
amplifier@38
> + compatible = "maxim,max98390";
> + reg = <0x38>;
> + maxim,temperature_calib = <1024>;
> + maxim,r0_calib = <100232>;
> +};
> --
> 2.17.1
>
Re: [PATCH] tpm: Revert "tpm: fix invalid locking in NONBLOCKING mode"
On Tue, 2020-05-26 at 14:33 -0700, Tadeusz Struk wrote: > On 5/26/20 1:00 PM, James Bottomley wrote: > > I don't think there is a root cause other than a TIS TPM is getting > > annoyed by us cycling localities too rapidly because we don't do an > > actual TPM operation between request and relinquish. Since the > > first > > request/relinquish seems unnecessary for the async case, moving the > > ops > > get eliminates the problem. > > Could be, so maybe we could try both patches. > More debug info on the error path won't hurt. > Thanks, > Tadeusz With your logging patch, I consistently see this message in dmesg when tpm2_getcap fails: tpm tpm0: request_locality: failed to request locality 0 after 750 ms
Re: [PATCH net-next 0/4] net: phy: mscc-miim: reduce waiting time between MDIO transactions
From: Antoine Tenart Date: Tue, 26 May 2020 18:22:52 +0200 > This series aims at reducing the waiting time between MDIO transactions > when using the MSCC MIIM MDIO controller. > > I'm not sure we need patch 4/4 and we could reasonably drop it from the > series. I'm including the patch as it could help to ensure the system > is functional with a non optimal configuration. > > We needed to improve the driver's performances as when using a PHY > requiring lots of registers accesses (such as the VSC85xx family), > delays would add up and ended up to be quite large which would cause > issues such as: a slow initialization of the PHY, and issues when using > timestamping operations (this feature will be sent quite soon to the > mailing lists). Series applied, thank you.
Re: [PATCH] nvmem: qfprom: remove incorrect write support
Hi,
On Fri, May 22, 2020 at 4:34 AM Srinivas Kandagatla
wrote:
>
> qfprom has different address spaces for read and write. Reads are
> always done from corrected address space, where as writes are done
> on raw address space.
> Writing to corrected address space is invalid and ignored, so it
> does not make sense to have this support in the driver which only
> supports corrected address space regions at the moment.
>
> Fixes: 4ab11996b489 ("nvmem: qfprom: Add Qualcomm QFPROM support.")
> Signed-off-by: Srinivas Kandagatla
> ---
> drivers/nvmem/qfprom.c | 14 --
> 1 file changed, 14 deletions(-)
Reviewed-by: Douglas Anderson
[RFC PATCH 2/2] Drivers: hv: vmbus: Re-balance channel interrupts across CPUs at device hotplug
Device hot removals and additions (closure and opening) also present a
valid opportunity for (re-)balancing the channel interrupts across the
available CPUs. Current code balances interrupts as they are offered,
but it does not modify the interrupts-to-CPUs assignment if interrupts
are "rescinded"/removed from the system. Moreover, in case of channel
/device offers, the interrupt assignments are performed *one at a time*
and without full visibility into other channels/devices; the result is
that, globally, interrupts are sometimes not evenly spread across CPUs.
Introduce the vmbus_balance_vp_indexes_at_devhp() primitive to balance
the channel interrupts across online CPUs at device hotplug operations.
The primitive triggers a "full" balancing of the interrupts across the
online CPUs and NUMA nodes. The balancing process at device addition/
opening is deferred to a delayed work, to give channels of such device
more chances to be opened. As in vmbus_balance_vp_indexes_at_cpuhp(),
the balancing is applied to "performance" channels only, and it relies
on the (new) capability to re-assign a channel interrupt.
Suggested-by: Nuno Das Neves
Signed-off-by: Andrea Parri (Microsoft)
---
drivers/hv/channel.c | 43
drivers/hv/channel_mgmt.c | 52 ---
drivers/hv/connection.c | 9 +++
drivers/hv/hyperv_vmbus.h | 6 +
include/linux/hyperv.h| 6 +
5 files changed, 112 insertions(+), 4 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 2974aa9dc956c..076f2d68a1efe 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -112,6 +113,19 @@ int vmbus_alloc_ring(struct vmbus_channel *newchannel,
}
EXPORT_SYMBOL_GPL(vmbus_alloc_ring);
+static void vmbus_add_device_work(struct work_struct *work)
+{
+ struct hv_device *hv_dev =
+ container_of((struct delayed_work *)work, struct hv_device,
+add_device_work);
+
+ cpus_read_lock();
+ mutex_lock(_connection.channel_mutex);
+ vmbus_balance_vp_indexes_at_devhp(hv_dev, true);
+ mutex_unlock(_connection.channel_mutex);
+ cpus_read_unlock();
+}
+
static int __vmbus_open(struct vmbus_channel *newchannel,
void *userdata, u32 userdatalen,
void (*onchannelcallback)(void *context), void *context)
@@ -217,6 +231,24 @@ static int __vmbus_open(struct vmbus_channel *newchannel,
}
newchannel->state = CHANNEL_OPENED_STATE;
+ /*
+* If this is a primary channel and a "perf" channel, queue the
+* add_device_work to balance the channels of the device across
+* the online CPUs; the queueing delay should be greater than
+* the "typical" time required to open such channels, since the
+* balancing will only apply to *open* channels. The closure
+* path will wait for our work to complete and start a new re-
+* balancing, cf. vmbus_disconnect_ring().
+*/
+ if (newchannel->primary_channel == NULL &&
+ hv_is_perf_channel(newchannel)) {
+ struct delayed_work *dwork =
+ >device_obj->add_device_work;
+
+ INIT_DELAYED_WORK(dwork, vmbus_add_device_work);
+ queue_delayed_work(vmbus_connection.handle_dev_wq, dwork,
+ 8 * HZ);
+ }
kfree(open_info);
return 0;
@@ -750,6 +782,8 @@ static int vmbus_close_internal(struct vmbus_channel
*channel)
/* disconnect ring - close all channels */
int vmbus_disconnect_ring(struct vmbus_channel *channel)
{
+ struct hv_device *hv_dev = channel->device_obj;
+ bool perf_chn = hv_is_perf_channel(channel);
struct vmbus_channel *cur_channel, *tmp;
int ret;
@@ -773,9 +807,18 @@ int vmbus_disconnect_ring(struct vmbus_channel *channel)
/*
* Now close the primary.
*/
+
+ /* See inline comment in __vmbus_open(). */
+ if (perf_chn)
+ cancel_delayed_work_sync(_dev->add_device_work);
+
+ cpus_read_lock();
mutex_lock(_connection.channel_mutex);
+ if (perf_chn)
+ vmbus_balance_vp_indexes_at_devhp(hv_dev, false);
ret = vmbus_close_internal(channel);
mutex_unlock(_connection.channel_mutex);
+ cpus_read_unlock();
return ret;
}
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index c158f86787940..91b1bd2914d79 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -815,6 +815,49 @@ static void balance_vp_index(struct vmbus_channel *chn,
inc_chn_counts(_connection.chn_cnt, tgt_cpu);
}
+void vmbus_balance_vp_indexes_at_devhp(struct hv_device *hv_dev, bool add)
+{
+ struct vmbus_channel *chn, *sc;
+
[RFC PATCH 0/2] VMBus channel interrupts re-balancing
The RFC introduces constructs to re-balance the channel interrupts at CPU hotplug and at device hotplug operations, the latter being indeed "closure/opening operations" to enable the re-balancing also in cases when the device is just being closed/re-opened (as in "ethtool -L"). These changes originated from (and address /try to resolve) two known limitations of the current interrupts-to-CPUs mapping scheme, that is, (1) the "static" nature of this mapping scheme (that, e.g., can end up preventing the hot removal of certain CPUs) and (2) the lack of global visibility in such scheme (where devices/channels are mapped only "one at a time"/as they are offered, with the end result that globally the various interrupts are not always evenly spread across CPUs). Andrea Parri (Microsoft) (2): Drivers: hv: vmbus: Re-balance channel interrupts across CPUs at CPU hotplug Drivers: hv: vmbus: Re-balance channel interrupts across CPUs at device hotplug drivers/hv/channel.c | 81 drivers/hv/channel_mgmt.c | 263 ++ drivers/hv/connection.c | 32 +++-- drivers/hv/hv.c | 62 + drivers/hv/hyperv_vmbus.h | 78 +++ drivers/hv/vmbus_drv.c| 45 ++- include/linux/hyperv.h| 26 kernel/cpu.c | 1 + 8 files changed, 523 insertions(+), 65 deletions(-) -- 2.25.1
Re: [PATCH v5 1/5] dt-bindings: remoteproc: Add Qualcomm PIL info binding
On Tue, 12 May 2020 22:56:37 -0700, Bjorn Andersson wrote: > Add a devicetree binding for the Qualcomm peripheral image loader > relocation information region found in the IMEM. > > Reviewed-by: Stephen Boyd > Signed-off-by: Bjorn Andersson > --- > > Changes since v4: > - Fixed reg in example to make it compile > > .../bindings/remoteproc/qcom,pil-info.yaml| 44 +++ > 1 file changed, 44 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml > Reviewed-by: Rob Herring
[RFC PATCH 1/2] Drivers: hv: vmbus: Re-balance channel interrupts across CPUs at CPU hotplug
CPU hot removals and additions present an opportunity for (re-)balancing
the channel interrupts across the available CPUs. Current code does not
balance the interrupts at CPU hotplug; furthermore/consequently, the hot
removal path currently fails (to remove the specified CPU) whenever some
interrupt is bound to the CPU to be removed and the VMBus is connected.
Address such issues by implementing vmbus_balance_vp_indexes_at_cpuhp():
invoke this primitive to balance the channel interrupts across available
CPUs at CPU hotplug operations. In the hot removal path, such primitive
will (try to) move/balance interrupts out of the to-be-removed CPU so as
to meet the user request to hot remove the CPU.
The balancing algorithm distributes the channel interrupts evenly across
the available CPUs and NUMA nodes; to do so, it introduces and maintains
per-device and per-connection channel statistics/counts to keep track of
the (current) assignments of the channels to the CPUs/nodes. By design,
only "performance"-critical channels/devices are "balanced".
The proposed algorithm relies on the (recently introduced) capability to
reassign a channel interrupt to a CPU (cf., the CHANNELMSG_MODIFYCHANNEL
message type). As such, the new balancing process is effective starting
with VMBus version 4.1 (no changes in semantics or behavior are intended
for VMBus versions lower than 4.1).
Suggested-by: Nuno Das Neves
Signed-off-by: Andrea Parri (Microsoft)
---
drivers/hv/channel.c | 38 +++
drivers/hv/channel_mgmt.c | 219 ++
drivers/hv/connection.c | 23 ++--
drivers/hv/hv.c | 62 ++-
drivers/hv/hyperv_vmbus.h | 72 +
drivers/hv/vmbus_drv.c| 45 +++-
include/linux/hyperv.h| 22 +++-
kernel/cpu.c | 1 +
8 files changed, 416 insertions(+), 66 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 90070b337c10d..2974aa9dc956c 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "hyperv_vmbus.h"
@@ -317,6 +318,43 @@ int vmbus_send_modifychannel(u32 child_relid, u32
target_vp)
}
EXPORT_SYMBOL_GPL(vmbus_send_modifychannel);
+bool vmbus_modifychannel(struct vmbus_channel *channel,
+u32 origin_cpu, u32 target_cpu)
+{
+ if (vmbus_send_modifychannel(channel->offermsg.child_relid,
+hv_cpu_number_to_vp_number(target_cpu)))
+ return false;
+
+ /*
+* Warning. At this point, there is *no* guarantee that the host will
+* have successfully processed the vmbus_send_modifychannel() request.
+* See the header comment of vmbus_send_modifychannel() for more info.
+*
+* Lags in the processing of the above vmbus_send_modifychannel() can
+* result in missed interrupts if the "old" target CPU is taken offline
+* before Hyper-V starts sending interrupts to the "new" target CPU.
+* But apart from this offlining scenario, the code tolerates such
+* lags. It will function correctly even if a channel interrupt comes
+* in on a CPU that is different from the channel target_cpu value.
+*/
+
+ channel->target_cpu = target_cpu;
+ channel->target_vp = hv_cpu_number_to_vp_number(target_cpu);
+ channel->numa_node = cpu_to_node(target_cpu);
+
+ /* See init_vp_index(). */
+ if (hv_is_perf_channel(channel))
+ hv_update_alloced_cpus(origin_cpu, target_cpu);
+
+ /* Currently set only for storvsc channels. */
+ if (channel->change_target_cpu_callback) {
+ (*channel->change_target_cpu_callback)(channel,
+ origin_cpu, target_cpu);
+ }
+
+ return true;
+}
+
/*
* create_gpadl_header - Creates a gpadl for the specified buffer
*/
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 417a95e5094dd..c158f86787940 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -497,10 +497,14 @@ static void vmbus_add_channel_work(struct work_struct
*work)
/*
* Start the process of binding the primary channel to the driver
*/
+
+ /* See vmbus_balance_vp_indexes_at_cpuhp(). */
+ mutex_lock(_connection.channel_mutex);
newchannel->device_obj = vmbus_device_create(
>offermsg.offer.if_type,
>offermsg.offer.if_instance,
newchannel);
+ mutex_unlock(_connection.channel_mutex);
if (!newchannel->device_obj)
goto err_deq_chan;
@@ -515,6 +519,8 @@ static void vmbus_add_channel_work(struct work_struct *work)
if (ret != 0) {
pr_err("unable to add child device object (relid %d)\n",
newchannel->offermsg.child_relid);
+ if (hv_is_perf_channel(newchannel))
+
Re: [RFC v1 2/3] drivers: nvmem: Add driver for QTI qfprom-efuse support
Hi,
On Fri, May 22, 2020 at 4:18 AM Srinivas Kandagatla
wrote:
>
> On 21/05/2020 22:28, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, May 21, 2020 at 8:56 AM Srinivas Kandagatla
> > wrote:
> >>
> >> On 21/05/2020 16:10, Doug Anderson wrote:
> On 20/05/2020 23:48, Doug Anderson wrote:
> >> Is this only applicable for corrected address space?
> > I guess I was proposing a two dts-node / two drive approach here.
> >
> > dts node #1:just covers the memory range for accessing the
> > FEC-corrected data
> > driver #1: read-only and reads the FEC-corrected data
> >
> > dts node #2: covers the memory range that's_not_ the FEC-corrected
> > memory range.
> > driver #2: read-write. reading reads uncorrected data
> >
> > Does that seem sane?
> I see your point but it does not make sense to have two node for same
> thing.
> >>> OK, so that sounds as if we want to go with the proposal where we
> >>> "deprecate the old driver and/or bindings and say that there really
> >>> should just be one node and one driver".
> >>>
> >>> Would this be acceptable to you?
> >>>
> >>> 1. Officially mark the old bindings as deprecated.
> >>
> >> Possibly Yes for some reasons below!
> >>
> >>>
> >>> 2. Leave the old driver there to support the old deprecated bindings,
> >>> at least until everyone can be transferred over. There seem to be
> >>> quite a few existing users of "qcom,qfprom" and we're supposed to make
> >>> an attempt at keeping the old device trees working, at least for a
> >>> little while. Once everyone is transferred over we could decide to
> >>> delete the old driver.
> >> we could consider "qcom,qfrom" to be only passing corrected address
> >> space. Till we transition users to new bindings!
> >>
> >>>
> >> Yes.
> >>
> >>> 3. We will have a totally new driver here.
> >> No, we should still be using the same driver. But the exiting driver
> >> seems to incorrect and is need of fixing.
> >>
> >> Having a look at the memory map for old SoCs like msm8996 and msm8916
> >> shows that memory map that was passed to qfprom driver is corrected
> >> address space. Writes will not obviously work!
> >>
> >> This should also be true with sdm845 or sc7180
> >>
> >> That needs to be fixed first!
> >
> > OK, so to summarize:
> >
>
> > 1. We will have one driver: "drivers/nvmem/qfprom.c"
>
> Yes, we should one driver for this because we are dealing with exactly
> same IP.
>
> >
> > 2. If the driver detects that its reg is pointing to the corrected
> > address space then it should operate in read-only mode. Maybe it can
> > do this based on the compatible string being just "qcom,qfprom" or
> > maybe it can do this based on the size of the "reg".
>
> I found out that there is a version register at offset of 0x6000 which
> can give MAJOR, MINOR and STEP numbers.
>
> So we could still potentially continue using "qcom,qfprom"
OK, sounds good. I think it's still good practice to include both the
SoC specific and the generic. Even if the driver never does anything
with the SoC-specific compatible string it doesn't hurt to have it
there. Thus, we'd want:
compatible = "qcom,msm8996-qfprom", "qcom,qfprom"
The driver itself would never need to refer to the SoC-specific name
but that does give us more flexibility.
> The address space can be split into 3 resources, which is inline with
> Specs as well
>
> 1. Raw address space ("raw")
> 2. Configuration address space ("conf" or "core")
> 3. Corrected address space ("corrected")
Sure, this is OK with me then. Originally Ravi had 3 ranges but then
he was (in the driver) treating it as one range. As long as the
driver truly treats it as 3 ranges I have no problem doing it like
this.
In general, over the years, there has been a push to keep
implementation details out of the dts and rely more on the "of_match"
table to add SoC-specific details. This becomes really important when
1 year down the road you realize that you need one more random
property or address range to fix some bug and then you need to figure
out how to try to keep old "dts" files compatible. It's not a
hard-and-fast rule, though.
> Exiting qfprom entries or read-only qfprom will have "corrected"
> address space which can be the only resource provided by device tree
> entries.
> Other two entries("raw" and "conf") are optional.
>
> qfprom: qfprom@78 {
> compatible = "qcom,qfprom";
> reg = <0 0x0078 0 0x8ff>,
> <0 0x00782000 0 0x100>,
> <0 0x00784000 0 0x8ff>;
> reg-names = "raw", "conf", "corrected";
>
> vcc-supply = <_xyz>;
>
> clocks = < GCC_SEC_CTRL_CLK_SRC>;
> clock-names = "secclk";
>
> assigned-clocks = < GCC_SEC_CTRL_CLK_SRC>;
> assigned-clock-rates = <1920>;
>
> qcom,fuse-blow-frequency = <480>
>
> #address-cells = <1>;
> #size-cells = <1>;
>
> qusb2p_hstx_trim: hstx-trim-primary@25b {
>
Re: [PATCH V5 5/5] dt-bindings: clock: Convert i.MX6UL clock to json-schema
On Wed, 13 May 2020 08:11:24 +0800, Anson Huang wrote: > Convert the i.MX6UL clock binding to DT schema format using json-schema. > > Signed-off-by: Anson Huang > Acked-by: Stephen Boyd > --- > Changes since V4: > - add descriptions for interrupts and each item of it. > --- > .../devicetree/bindings/clock/imx6ul-clock.txt | 13 - > .../devicetree/bindings/clock/imx6ul-clock.yaml| 66 > ++ > 2 files changed, 66 insertions(+), 13 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/clock/imx6ul-clock.txt > create mode 100644 Documentation/devicetree/bindings/clock/imx6ul-clock.yaml > Applied, thanks!
Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics
On Tue, 26 May 2020 13:03:10 +0200 Emanuele Giuseppe Esposito wrote: > There is currently no common way for Linux kernel subsystems to expose > statistics to userspace shared throughout the Linux kernel; subsystems have > to take care of gathering and displaying statistics by themselves, for > example in the form of files in debugfs. For example KVM has its own code > section that takes care of this in virt/kvm/kvm_main.c, where it sets up > debugfs handlers for displaying values and aggregating them from various > subfolders to obtain information about the system state (i.e. displaying > the total number of exits, calculated by summing all exits of all cpus of > all running virtual machines). > > Allowing each section of the kernel to do so has two disadvantages. First, > it will introduce redundant code. Second, debugfs is anyway not the right > place for statistics (for example it is affected by lockdown) > > In this patch series I introduce statsfs, a synthetic ram-based virtual > filesystem that takes care of gathering and displaying statistics for the > Linux kernel subsystems. > > The file system is mounted on /sys/kernel/stats and would be already used > by kvm. Statsfs was initially introduced by Paolo Bonzini [1]. What's the direct motivation for this work? Moving KVM stats out of debugfs? In my experience stats belong in the API used for creating/enumerating objects, statsfs sounds like going in the exact opposite direction - creating a parallel structure / hierarchy for exposing stats. I know nothing about KVM but are you sure all the info that has to be exposed will be stats? In case of networking we have the basic stats in sysfs, under the netdevice's kobject. But since we're not using sysfs much any more for config, new stats are added in netlink APIs. Again - same APIs used for enumeration and config.
Re: [PATCH V5 4/5] dt-bindings: clock: Convert i.MX6SLL clock to json-schema
On Wed, 13 May 2020 08:11:23 +0800, Anson Huang wrote: > Convert the i.MX6SLL clock binding to DT schema format using json-schema. > > Signed-off-by: Anson Huang > Acked-by: Stephen Boyd > --- > Changes since V4: > - add descriptions for interrupts and each item of it. > --- > .../devicetree/bindings/clock/imx6sll-clock.txt| 36 > .../devicetree/bindings/clock/imx6sll-clock.yaml | 66 > ++ > 2 files changed, 66 insertions(+), 36 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/clock/imx6sll-clock.txt > create mode 100644 Documentation/devicetree/bindings/clock/imx6sll-clock.yaml > Applied, thanks!
Re: [PATCH V5 2/5] dt-bindings: clock: Convert i.MX6SX clock to json-schema
On Wed, 13 May 2020 08:11:21 +0800, Anson Huang wrote: > Convert the i.MX6SX clock binding to DT schema format using json-schema. > > Signed-off-by: Anson Huang > Acked-by: Stephen Boyd > --- > Changes since V4: > - add descriptions for interrupts and each item of it. > --- > .../devicetree/bindings/clock/imx6sx-clock.txt | 13 > .../devicetree/bindings/clock/imx6sx-clock.yaml| 70 > ++ > 2 files changed, 70 insertions(+), 13 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/clock/imx6sx-clock.txt > create mode 100644 Documentation/devicetree/bindings/clock/imx6sx-clock.yaml > Applied, thanks!
Re: [PATCH V5 1/5] dt-bindings: clock: Convert i.MX6Q clock to json-schema
On Wed, 13 May 2020 08:11:20 +0800, Anson Huang wrote: > Convert the i.MX6Q clock binding to DT schema format using json-schema. > > Signed-off-by: Anson Huang > Acked-by: Stephen Boyd > --- > Changes since V4: > - add descriptions for interrupts and each item of it. > --- > .../devicetree/bindings/clock/imx6q-clock.txt | 41 > .../devicetree/bindings/clock/imx6q-clock.yaml | 72 > ++ > 2 files changed, 72 insertions(+), 41 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/clock/imx6q-clock.txt > create mode 100644 Documentation/devicetree/bindings/clock/imx6q-clock.yaml > Applied, thanks!
Re: [PATCH V5 3/5] dt-bindings: clock: Convert i.MX6SL clock to json-schema
On Wed, 13 May 2020 08:11:22 +0800, Anson Huang wrote: > Convert the i.MX6SL clock binding to DT schema format using json-schema. > > Signed-off-by: Anson Huang > Acked-by: Stephen Boyd > --- > Changes since V4: > - add descriptions for interrupts and each item of it. > --- > .../devicetree/bindings/clock/imx6sl-clock.txt | 10 - > .../devicetree/bindings/clock/imx6sl-clock.yaml| 48 > ++ > 2 files changed, 48 insertions(+), 10 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/clock/imx6sl-clock.txt > create mode 100644 Documentation/devicetree/bindings/clock/imx6sl-clock.yaml > Applied, thanks!
Re: [PATCH 4/6] mm/hmm: add output flag for compound page mapping
On 8 May 2020, at 16:06, Ralph Campbell wrote: > On 5/8/20 12:51 PM, Christoph Hellwig wrote: >> On Fri, May 08, 2020 at 12:20:07PM -0700, Ralph Campbell wrote: >>> hmm_range_fault() returns an array of page frame numbers and flags for >>> how the pages are mapped in the requested process' page tables. The PFN >>> can be used to get the struct page with hmm_pfn_to_page() and the page size >>> order can be determined with compound_order(page) but if the page is larger >>> than order 0 (PAGE_SIZE), there is no indication that the page is mapped >>> using a larger page size. To be fully general, hmm_range_fault() would need >>> to return the mapping size to handle cases like a 1GB compound page being >>> mapped with 2MB PMD entries. However, the most common case is the mapping >>> size the same as the underlying compound page size. >>> Add a new output flag to indicate this so that callers know it is safe to >>> use a large device page table mapping if one is available. >> >> Why do you need the flag? The caller should be able to just use >> page_size() (or willys new thp_size helper). >> > > The question is whether or not a large page can be mapped with smaller > page table entries with different permissions. If one process has a 2MB > page mapped with 4K PTEs with different read/write permissions, I don't think > it would be OK for a device to map the whole 2MB with write access enabled. > The flag is supposed to indicate that the whole page can be mapped by the > device with the indicated read/write permissions. If hmm_range_fault() only walks one VMA at a time, you would not have this permission issue, right? Since all pages from one VMA should have the same permission. But it seems that hmm_range_fault() deals with pages across multiple VMAs. Maybe we should make hmm_range_fault() bail out early when it encounters a VMA with a different permission than the existing ones? — Best Regards, Yan Zi signature.asc Description: OpenPGP digital signature
Re: [PATCH v6 3/5] dt-bindings: iio: magnetometer: ak8975: add gpio reset support
On Mon, 25 May 2020 17:10:37 +0200, Jonathan Albrieux wrote: > Add reset-gpio support. > > Without reset's deassertion during ak8975_power_on(), driver's probe fails > on ak8975_who_i_am() while checking for device identity for AK09911 chip. > > AK09911 has an active low reset gpio to handle register's reset. > AK09911 datasheet says that, if not used, reset pin should be connected > to VID. This patch emulates this situation. > > Signed-off-by: Jonathan Albrieux > --- > .../bindings/iio/magnetometer/asahi-kasei,ak8975.yaml | 7 +++ > 1 file changed, 7 insertions(+) > Reviewed-by: Rob Herring
Re: [fixup] kunit: use --build_dir=.kunit as default
On 5/26/20 12:34 PM, Vitor Massaru Iha wrote: To make KUnit easier to use, and to avoid overwriting object and .config files, the default KUnit build directory is set to .kunit * Related bug: https://bugzilla.kernel.org/show_bug.cgi?id=205221 Fixed up minor merge conflicts - Shuah Khan Signed-off-by: Vitor Massaru Iha Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan --- version after merge on kunit brach: * fix identation (tabs instead of spaces) You mentioned spaces breaking python. Please include the python errors and make it clear in the change log what is fixes. thanks, -- Shuah
Re: [PATCH v6 2/5] dt-bindings: iio: magnetometer: ak8975: convert format to yaml, add maintainer
On Mon, May 25, 2020 at 05:10:36PM +0200, Jonathan Albrieux wrote:
> Converts documentation from txt format to yaml.
I would have converted to yaml and do any re-formatting/wording, then
added 'interrupts', but this is fine.
> Signed-off-by: Jonathan Albrieux
> ---
> .../bindings/iio/magnetometer/ak8975.txt | 37 -
> .../iio/magnetometer/asahi-kasei,ak8975.yaml | 78 +++
> 2 files changed, 78 insertions(+), 37 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> create mode 100644
> Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> deleted file mode 100644
> index 0576b9df0bf2..
> --- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> +++ /dev/null
> @@ -1,37 +0,0 @@
> -* AsahiKASEI AK8975 magnetometer sensor
> -
> -Required properties:
> -
> - - compatible : should be "asahi-kasei,ak8975".
> - - reg : the I2C address of the magnetometer.
> -
> -Optional properties:
> -
> - - gpios : AK8975 has a "Data ready" pin (DRDY) which informs that data
> - is ready to be read and is possible to listen on it. If used,
> - this should be active high. Prefer interrupt over this.
> -
> - - interrupts : interrupt for DRDY pin. Triggered on rising edge.
> -
> - - vdd-supply: an optional regulator that needs to be on to provide VDD.
> -
> - - mount-matrix: an optional 3x3 mounting rotation matrix.
> -
> -Example:
> -
> -ak8975@c {
> -compatible = "asahi-kasei,ak8975";
> -reg = <0x0c>;
> -interrupt-parent = <>;
> -interrupts = <15 IRQ_TYPE_EDGE_RISING>;
> -vdd-supply = <_3v3_gnss>;
> -mount-matrix = "-0.984807753012208", /* x0 */
> - "0", /* y0 */
> - "-0.173648177666930", /* z0 */
> - "0", /* x1 */
> - "-1", /* y1 */
> - "0", /* z1 */
> - "-0.173648177666930", /* x2 */
> - "0", /* y2 */
> - "0.984807753012208"; /* z2 */
> -};
> diff --git
> a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
> b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
> new file mode 100644
> index ..a603659d5fa5
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
> @@ -0,0 +1,78 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/magnetometer/asahi-kasei,ak8975.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AsahiKASEI AK8975 magnetometer sensor
> +
> +maintainers:
> + - Jonathan Albrieux
> +
> +properties:
> + compatible:
> +oneOf:
> + - const: asahi-kasei,ak8975
> + - const: asahi-kasei,ak8963
> + - const: asahi-kasei,ak09911
> + - const: asahi-kasei,ak09912
These 4 can be an enum.
> + - const: ak8975
> +deprecated: true
> + - const: ak8963
> +deprecated: true
> + - const: ak09911
> +deprecated: true
> + - const: ak09912
> +deprecated: true
And these 4 can be an enum+deprecated.
> +
> + reg:
> +maxItems: 1
> +description: the I2C address of the magnetometer.
Don't need a description.
> +
> + gpios:
> +description: |
> + AK8975 has a "Data ready" pin (DRDY) which informs that data
> + is ready to be read and is possible to listen on it. If used,
> + this should be active high. Prefer interrupt over this.
Need to define how many GPIOs (maxItems: 1).
> +
> + interrupts:
> +maxItems: 1
> +description: interrupt for DRDY pin. Triggered on rising edge.
> +
> + vdd-supply:
> +maxItems: 1
> +description: |
> + an optional regulator that needs to be on to provide VDD power to
> + the sensor.
> +
> + mount-matrix:
> +description: an optional 3x3 mounting rotation matrix.
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> +#include
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +magnetometer@c {
> +compatible = "asahi-kasei,ak8975";
> +reg = <0x0c>;
> +interrupt-parent = <>;
> +interrupts = <15 IRQ_TYPE_EDGE_RISING>;
> +vdd-supply = <_3v3_gnss>;
> +mount-matrix = "-0.984807753012208", /* x0 */
> + "0", /* y0 */
> + "-0.173648177666930", /* z0 */
> + "0", /* x1 */
> + "-1", /* y1 */
> +
Re: [PATCH 01/10] rcu: Directly lock rdp->nocb_lock on nocb code entrypoints
On Tue, May 26, 2020 at 05:27:56PM -0400, Joel Fernandes wrote: > On Tue, May 26, 2020 at 02:09:47PM -0700, Paul E. McKenney wrote: > [...] > > > > > BTW, I'm really itching to give it a try to make the scheduler more > > > > > deadlock > > > > > resilient (that is, if the scheduler wake up path detects a deadlock, > > > > > then it > > > > > defers the wake up using timers, or irq_work on its own instead of > > > > > passing > > > > > the burden of doing so to the callers). Thoughts? > > > > > > > > I have used similar approaches within RCU, but on the other hand the > > > > scheduler often has tighter latency constraints than RCU does. So I > > > > think that is a better question for the scheduler maintainers than it > > > > is for me. ;-) > > > > > > Ok, it definitely keeps coming up in my radar first with the > > > rcu_read_unlock_special() stuff, and now the nocb ;-). Perhaps it could > > > also > > > be good for a conference discussion! > > > > Again, please understand that RCU has way looser latency constraints > > than the scheduler does. Adding half a jiffy to wakeup latency might > > not go over well, especially in the real-time application area. > > Yeah, agreed that the "deadlock detection" code should be pretty light weight > if/when it is written. In addition, to even stand a chance, you would need to use hrtimers. The half-jiffy (at a minimum) delay from any other deferral mechanism that I know of would be the kiss of death, especially from the viewpoint of the real-time guys. > > But what did the scheduler maintainers say about this idea? > > Last I remember when it came up during the rcu_read_unlock_special() deadlock > discussions, there's no way to know for infra like RCU to know that it was > invoked from the scheduler. > > The idea I am bringing up now (about the scheduler itself detecting a > recursion) was never brought up (not yet) with the sched maintainers (at > least not by me). It might be good to bounce if off of them sooner rather than later. Thanx, Paul
Re: [PATCH] locking/lockdep: Increase MAX_LOCKDEP_ENTRIES by half
On 5/26/20 5:27 PM, Peter Zijlstra wrote: On Tue, May 26, 2020 at 04:30:58PM -0400, Waiman Long wrote: On 5/26/20 3:56 PM, Peter Zijlstra wrote: On Tue, May 26, 2020 at 02:58:50PM -0400, Qian Cai wrote: I still don't understand why reading all sysfs files on this system could increase that much, but here is the lockdep file after running sysfs read to see if you could spot anything obviously, https://cailca.github.io/files/lockdep.txt f011a2a5 OPS: 20 FD: 45 BD:1 .+.+: kn->active#834 is that somewhere near the number of CPUs you have? Anyway, there's very long "kn->active#..." chains in there, which seems to suggest some annotation is all sorts of buggered. It is actually one active lock per instance of the kerfs_node structures. That means more than 800 sysfs files are accessed in some way. As we could have much more than 800 sysfs files in the system, we could easily overwhelm the lockdep tables if we really try to access all of them. A lock per instance is crazy, that's not what lockdep is made for. Fixing this seems like a far better idea than increasing the numbers. Thinking about it, one lock per sysfs file does make sense as access to those sysfs files can invoke vastly different code path and unifying them into one single lock can easily lead to false positive warning. Cheers, Longman
Re: [PATCH] MAINTAINERS: Update my maintainer entries to reorder email addresses
On Tue, 2020-05-26 at 11:04 -0600, Shuah Khan wrote: > On 5/22/20 8:26 PM, Joe Perches wrote: > > On Fri, 2020-05-22 at 20:19 -0600, Shuah Khan wrote: > > > get_maintainer.pl picks only the first email address found in the file. > > > Reorder my email addresses so it finds my linuxfoundation.org email. > > > > OK. [] > Sadly, people that don't run get_maintainer.pl, leave alone running it > with --noremove-duplicates option. So your suggestion doesn't really > help me. > > My preference is to get patches to both Inboxes if possible which isn't > possible unless -noremove-duplicate is default. Having this option as > default probably will annoy lot of people . So I am not asking for > that. > > That being said, I don't understand your comment. Are you recommending > using just one email in these entries? Yes. And maybe set an autoforward rule in that email to forward the received email to your other address.
[PATCH] media: v4l2-ctrls: Unset correct HEVC loop filter flag
Wrong loop filter flag is unset when tiles enabled flag is not set,
this cause HEVC decoding issues with Rockchip Video Decoder.
Fix this by unsetting the loop filter across tiles enabled flag instead of
the pps loop filter across slices enabled flag when tiles are disabled.
Fixes: 256fa3920874 ("media: v4l: Add definitions for HEVC stateless decoding")
Signed-off-by: Jonas Karlman
---
drivers/media/v4l2-core/v4l2-ctrls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b2e5804f1aa9..ebd7054d18ac 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2081,7 +2081,7 @@ static int std_validate_compound(const struct v4l2_ctrl
*ctrl, u32 idx,
sizeof(p_hevc_pps->row_height_minus1));
p_hevc_pps->flags &=
-
~V4L2_HEVC_PPS_FLAG_PPS_LOOP_FILTER_ACROSS_SLICES_ENABLED;
+
~V4L2_HEVC_PPS_FLAG_LOOP_FILTER_ACROSS_TILES_ENABLED;
}
if (p_hevc_pps->flags &
--
2.17.1
Re: [PATCH v6 1/5] dt-bindings: iio: magnetometer: ak8975: reword gpios, add interrupts, fix style
On Mon, 25 May 2020 17:10:35 +0200, Jonathan Albrieux wrote: > Reword gpios documentation, add interrupt documentation and fix styles. > Update example to use interrupts instead of gpios. > > Signed-off-by: Jonathan Albrieux > --- > .../bindings/iio/magnetometer/ak8975.txt | 19 +-- > 1 file changed, 13 insertions(+), 6 deletions(-) > Reviewed-by: Rob Herring
Re: Some -serious- BPF-related litmus tests
On Tue, 26 May 2020 13:15:49 -0700, Andrii Nakryiko wrote:
> On Tue, May 26, 2020 at 3:50 AM Akira Yokosawa wrote:
>>
>> On Mon, 25 May 2020 16:31:05 -0700, Andrii Nakryiko wrote:
>>> On Mon, May 25, 2020 at 3:01 PM Akira Yokosawa wrote:
>> [...]
Yes, that should work.
>>>
>>> Ok, assigning to zero didn't work (it still complained about
>>> uninitialized read), but using a separate int *lenFail to assign to
>>> rLenPtr worked. Curiously, if I used rLenPtr = len1; in error case, it
>>> actually takes a bit more time to verify.
>>>
>>> So I've converted everything else as you suggested. I compiled latest
>>> herd7 and it doesn't produce any warnings. But it's also extremely
>>> slow, compared to the herd7 that I get by default. Validating simple
>>> 1p1c cases takes about 2.5x times longer (0.03s vs 0.07), but trying
>>> to validate 2p1c case, which normally validates in 42s (unbounded) and
>>> 110s (bounded), it took more than 20 minutes and hasn't finished,
>>> before I gave up. So I don't know what's going on there...
>>
>> herdtools7 has recently been heavily restructured.
>> On the performance regression, I must defer to Luc.
>>
>> Luc, do you have any idea?
>>
>>>
>>> As for klitmus7, I managed to generate everything without warnings,
>>> but couldn't make it build completely due to:
>>>
>>> $ make
>>> make -C /lib/modules/5.6.13-01802-g938d64da97c6/build/
>>
>> So you are on Linux 5.6.x which requires cutting-edge klitmus7.
>>
>
> Right, so I retried with the klitmus7 built from sources:
>
> $ klitmus7 -version
>
> 7.55+01(dev)
>
> Still can't compile, though task_struct problem went away, proc_ops
> error is still present:
>
> $ make
> grep:
> /lib/modules/5.7.0-rc5-02014-gb16540c748e9/build/include/linux/proc_fs.h:
> No such file or directory
Hmm, have you installed kernel-headers on your system?
You are now on Linux 5.7-rc5 based system...
Thanks, Akira
> make -C /lib/modules/5.7.0-rc5-02014-gb16540c748e9/build/
> M=/home/andriin/local/linux-trees/tools/memory-model/mymodules modules
> make[1]: Entering directory `/data/users/andriin/linux-build/fb-config'
> make[2]: Entering directory `/data/users/andriin/linux-build/default-x86_64'
> grep:
> /lib/modules/5.7.0-rc5-02014-gb16540c748e9/build/include/linux/proc_fs.h:
> No such file or directory
> CC [M]
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.o
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:
> In function ‘litmus_init’:
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:621:67:
> error: passing argument 4 of ‘proc_create’ from incompatible pointer
> type [-Werror=incompatible-pointer-types]
>struct proc_dir_entry *litmus_pde =
> proc_create("litmus",0,NULL,_proc_ops);
>
> ^~~~
> In file included from
> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:15:
> /data/users/andriin/linux/include/linux/proc_fs.h:79:24: note:
> expected ‘const struct proc_ops *’ but argument is of type ‘const
> struct file_operations *’
> struct proc_dir_entry *proc_create(const char *name, umode_t mode,
> struct proc_dir_entry *parent, const struct proc_ops *proc_ops);
> ^~~
> cc1: some warnings being treated as errors
> make[3]: ***
> [/home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.o]
> Error 1
> make[2]: *** [/home/andriin/local/linux-trees/tools/memory-model/mymodules]
> Error 2
> make[2]: Leaving directory `/data/users/andriin/linux-build/default-x86_64'
> make[1]: *** [sub-make] Error 2
> make[1]: Leaving directory `/data/users/andriin/linux-build/fb-config'
> make: *** [all] Error 2
>
> Don't know if I'm missing some headers or whatever.
>
>>> M=/home/andriin/local/linux-trees/tools/memory-model/mymodules modules
>>> make[1]: Entering directory `/data/users/andriin/linux-build/fb-config'
>>> make[2]: Entering directory `/data/users/andriin/linux-build/default-x86_64'
>>> CC [M]
>>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.o
>>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:
>>> In function ‘zyva’:
>>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:507:12:
>>> warning: ISO C90 forbids variable length array ‘th’ [-Wvla]
>>> struct task_struct *th[nth];
>>> ^~~
>>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:
>>> In function ‘litmus_init’:
>>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:605:67:
>>> error: passing argument 4 of ‘proc_create’ from incompatible pointer
>>> type [-Werror=incompatible-pointer-types]
>>>struct proc_dir_entry *litmus_pde =
>>> proc_create("litmus",0,NULL,_proc_fops);
>>>
>>> ^
>>> In file included from
>>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:15:
>>>
Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface
On Tue, May 26, 2020 at 03:44:30PM +0200, Alexander Graf wrote: > > > On 26.05.20 15:17, Greg KH wrote: > > > > On Tue, May 26, 2020 at 02:44:18PM +0200, Alexander Graf wrote: > > > > > > > > > On 26.05.20 14:33, Greg KH wrote: > > > > > > > > On Tue, May 26, 2020 at 01:42:41PM +0200, Alexander Graf wrote: > > > > > > > > > > > > > > > On 26.05.20 08:51, Greg KH wrote: > > > > > > > > > > > > On Tue, May 26, 2020 at 01:13:23AM +0300, Andra Paraschiv wrote: > > > > > > > +#define NE "nitro_enclaves: " > > > > > > > > > > > > Again, no need for this. > > > > > > > > > > > > > +#define NE_DEV_NAME "nitro_enclaves" > > > > > > > > > > > > KBUILD_MODNAME? > > > > > > > > > > > > > +#define NE_IMAGE_LOAD_OFFSET (8 * 1024UL * 1024UL) > > > > > > > + > > > > > > > +static char *ne_cpus; > > > > > > > +module_param(ne_cpus, charp, 0644); > > > > > > > +MODULE_PARM_DESC(ne_cpus, " - CPU pool used for Nitro > > > > > > > Enclaves"); > > > > > > > > > > > > Again, please do not do this. > > > > > > > > > > I actually asked her to put this one in specifically. > > > > > > > > > > The concept of this parameter is very similar to isolcpus= and > > > > > maxcpus= in > > > > > that it takes CPUs away from Linux and instead donates them to the > > > > > underlying hypervisor, so that it can spawn enclaves using them. > > > > > > > > > > From an admin's point of view, this is a setting I would like to > > > > > keep > > > > > persisted across reboots. How would this work with sysfs? > > > > > > > > How about just as the "initial" ioctl command to set things up? Don't > > > > grab any cpu pools until asked to. Otherwise, what happens when you > > > > load this module on a system that can't support it? > > > > > > That would give any user with access to the enclave device the ability to > > > remove CPUs from the system. That's clearly a CAP_ADMIN task in my book. > > > > Ok, what's wrong with that? > > Would you want random users to get the ability to hot unplug CPUs from your > system? At unlimited quantity? I don't :). A random user, no, but one with admin rights, why not? They can do that already today on your system, this isn't new. > > > Hence this whole split: The admin defines the CPU Pool, users can safely > > > consume this pool to spawn enclaves from it. > > > > But having the admin define that at module load / boot time, is a major > > pain. What tools do they have that allow them to do that easily? > > The normal toolbox: editing /etc/default/grub, adding an /etc/modprobe.d/ > file. Editing grub files is horrid, come on... > When but at module load / boot time would you define it? I really don't want > to have a device node that in theory "the world" can use which then allows > any user on the system to hot unplug every CPU but 0 from my system. But you have that already when the PCI device is found, right? What is the initial interface to the driver? What's wrong with using that? Or am I really missing something as to how this all fits together with the different pieces? Seeing the patches as-is doesn't really provide a good overview, sorry. > > > So I really don't think an ioctl would be a great user experience. Same > > > for > > > a sysfs file - although that's probably slightly better than the ioctl. > > > > You already are using ioctls to control this thing, right? What's wrong > > with "one more"? :) > > So what we *could* do is add an ioctl to set the pool size which then does a > CAP_ADMIN check. That however means you now are in priority hell: > > A user that wants to spawn an enclave as part of an nginx service would need > to create another service to set the pool size and indicate the dependency > in systemd control files. > > Is that really better than a module parameter? module parameters are hard to change, and manage control over who really is changing them. thanks, greg k-h
Re: [PATCH v6 3/3] dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd
On Wed, May 13, 2020 at 02:59:02PM -0700, Douglas Anderson wrote: > The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware > HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP > because of excessive debouncing in hardware. Specifically there is no > way to disable the debouncing and for eDP debouncing hurts you because > HPD is just used for knowing when the panel is ready, not for > detecting physical plug events. > > Currently the driver in Linux just assumes that nobody has HPD hooked > up. It relies on folks setting the "no-hpd" property in the panel > node to specify that HPD isn't hooked up and then the panel driver > using this to add some worst case delays when turning on the panel. > > Apparently it's also useful to specify "no-hpd" in the bridge node so > that the bridge driver can make sure it's doing the right thing > without peeking into the panel [1]. This would be used if anyone ever > found it useful to implement support for the HW HPD pin on the bridge. > Let's add this property to the bindings. > > NOTES: > - This is somewhat of a backward-incompatible change. All current > known users of ti-sn65dsi86 didn't have "no-hpd" specified in the > bridge node yet none of them had HPD hooked up. This worked because > the current Linux driver just assumed that HPD was never hooked up. > We could make it less incompatible by saying that for this bridge > it's assumed HPD isn't hooked up _unless_ a property is defined, but > "no-hpd" is much more standard and it's unlikely to matter unless > someone quickly goes and implements HPD in the driver. > - It is sensible to specify "no-hpd" at the bridge chip level and > specify "hpd-gpios" at the panel level. That would mean HPD is > hooked up to some other GPIO in the system, just not the hardware > HPD pin on the bridge chip. I would say 'no-hpd' belongs wherever HPD is broken. So it may still make sense in the panel. (Otherwise, it needs to be removed from panel-common.yaml and some panel bindings, right?) > [1] https://lore.kernel.org/r/20200417180819.ge5...@pendragon.ideasonboard.com > > Signed-off-by: Douglas Anderson > Reviewed-by: Stephen Boyd > Reviewed-by: Linus Walleij > Reviewed-by: Laurent Pinchart > --- In any case, Reviewed-by: Rob Herring
[PATCH v3 1/4] dt-bindings: clk: Add Baikal-T1 CCU PLLs binding
Baikal-T1 Clocks Control Unit is responsible for transformation of a signal coming from an external oscillator into clocks of various frequencies to propagate them then to the corresponding clocks consumers (either individual IP-blocks or clock domains). In order to create a set of high-frequency clocks the external signal is firstly handled by the embedded into CCU PLLs. So the corresponding dts-node is just a normal clock-provider node with standard set of properties. Note as being part of the Baikal-T1 System Controller its DT node is supposed to be a child the system controller node. Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Arnd Bergmann Cc: linux-m...@vger.kernel.org --- Changelog v2: - Rearrange the SoBs. - Discard comments in the bindings file header. - Add dual GPL/BSD license. - Add spaces around the ASCII-graphics in the binding description. - Remove reference to Documentation/devicetree/bindings/clock/clock-bindings.txt file. - Discard redundant object check against "/schemas/clock/clock.yaml#" schema. - Discard redundant descriptions of the "#clock-cells" property. - Remove "reg" property since from now the clock DT node is supposed to be a child of the syscon-compatible system controller node. - Remove "clock-output-names" property support. - Replace "additionalProperties: false" with "unevaluatedProperties: false". - Lowercase the nodes name in the examples. - Use "clock-controller" node name suffix in the examples. - Remove unnecessary comments in the clocks dt-bindings header file. Changelog v3: - Get the reg property back even though the driver is using the parental syscon regmap. - The DT schema will live separately from the system controller, but the corresponding sub-node of the later DT schema will $ref this one. --- .../bindings/clock/baikal,bt1-ccu-pll.yaml| 131 ++ include/dt-bindings/clock/bt1-ccu.h | 16 +++ 2 files changed, 147 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml create mode 100644 include/dt-bindings/clock/bt1-ccu.h diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml new file mode 100644 index ..97131bfa6f87 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml @@ -0,0 +1,131 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/baikal,bt1-ccu-pll.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Baikal-T1 Clock Control Unit PLL + +maintainers: + - Serge Semin + +description: | + Clocks Control Unit is the core of Baikal-T1 SoC System Controller + responsible for the chip subsystems clocking and resetting. The CCU is + connected with an external fixed rate oscillator, which signal is transformed + into clocks of various frequencies and then propagated to either individual + IP-blocks or to groups of blocks (clock domains). The transformation is done + by means of PLLs and gateable/non-gateable dividers embedded into the CCU. + It's logically divided into the next components: + 1) External oscillator (normally XTAL's 25 MHz crystal oscillator, but + in general can provide any frequency supported by the CCU PLLs). + 2) PLLs clocks generators (PLLs) - described in this binding file. + 3) AXI-bus clock dividers (AXI). + 4) System devices reference clock dividers (SYS). + which are connected with each other as shown on the next figure: + + +---+ + | Baikal-T1 CCU | + | ++--|- MIPS P5600 cores + | +-|PLLs|--|- DDR controller + | | ++ | + ++ | | | | | + |XTAL|--|-+ | | +---+-| + ++ | | | +-|AXI|-|- AXI-bus + | | |+---+-| + | | | | + | | ++---+-|- APB-bus + | +---|SYS|-|- Low-speed Devices + | +---+-|- High-speed Devices + +---+ + + Each CCU sub-block is represented as a separate dts-node and has an + individual driver to be bound with. + + In order to create signals of wide range frequencies the external oscillator + output is primarily connected to a set of CCU PLLs. There are five PLLs + to create a clock for the MIPS P5600 cores, the embedded DDR controller, + SATA, Ethernet and PCIe domains. The last three domains though named by the + biggest system interfaces in fact include nearly all of the rest SoC + peripherals. Each of the PLLs is based on True Circuits TSMC CLN28HPM core + with an interface wrapper (so called safe PLL' clocks switcher) to simplify + the PLL configuration procedure. The PLLs work as depicted on the next + diagram: + + +--+ + | | + +-->+---++---+ +---+ | +---+ 0|\ +
[PATCH v3 3/4] clk: Add Baikal-T1 CCU PLLs driver
Baikal-T1 is supposed to be supplied with a high-frequency external
oscillator. But in order to create signals suitable for each IP-block
embedded into the SoC the oscillator output is primarily connected to
a set of CCU PLLs. There are five of them to create clocks for the MIPS
P5600 cores, an embedded DDR controller, SATA, Ethernet and PCIe domains.
The last three domains though named by the biggest system interfaces in
fact include nearly all of the rest SoC peripherals. Each of the PLLs is
based on True Circuits TSMC CLN28HPM IP-core with an interface wrapper
(so called safe PLL' clocks switcher) to simplify the PLL configuration
procedure.
This driver creates the of-based hardware clocks to use them then in
the corresponding subsystems. In order to simplify the driver code we
split the functionality up into the PLLs clocks operations and hardware
clocks declaration/registration procedures.
Even though the PLLs are based on the same IP-core, they may have some
differences. In particular, some CCU PLLs support the output clock change
without gating them (like CPU or PCIe PLLs), while the others don't, some
CCU PLLs are critical and aren't supposed to be gated. In order to cover
all of these cases the hardware clocks driver is designed with an
info-descriptor pattern. So there are special static descriptors declared
for each PLL, which is then used to create a hardware clock with proper
operations. Additionally debugfs-files are provided for each PLL' field
to make sure the implemented rate-PLLs-dividers calculation algorithm is
correct.
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Arnd Bergmann
Cc: Rob Herring
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
Changelog v2:
- Rearrange the SoBs.
- Don't enable the CCU clock drivers by default for COMPILE_TEST config.
- Make sure the CCU drivers depend on OF kernel config only when built for
Baikal-T1-based platform.
- Fix spelling in the CCU PLL kernel config description.
- Replace lock delay and frequency calculation macro with inline functions.
- Use 64-bits arithmetics in the PLL output frequency calculation method.
- Use readl_poll_timeout_atomic() to poll the PLL lock state.
- Use FIELD_{GET,PREP}() macro instead of handwritten field setters and
getters.
- Discard CLK_IGNORE_UNUSED flag setting. It's redundant since CLK_IS_CRITICAL
is enough for cases when it's appropriate.
- Don't declare private copies of the Common Clock Flags.
- Comment out the CLK_IS_CRITICAL flag settings.
- Discard !pll test in ccu_pll_hw_unregister() method.
- Discard ccu_pll_get_clk_id() method. Use not-null check instead of FFs-
based invalid ID value.
- Discard alive probe message.
- Remove "clock-output-names" property support.
- Convert the driver to using syscon regmap instead of direct IO methods,
since now the PLLs DT node is supposed to be a sub-node of the Baikal-T1
System Controller node.
- Add DebugFS nodes in RO-mode by default.
---
drivers/clk/Kconfig | 1 +
drivers/clk/Makefile| 1 +
drivers/clk/baikal-t1/Kconfig | 30 ++
drivers/clk/baikal-t1/Makefile | 2 +
drivers/clk/baikal-t1/ccu-pll.c | 558
drivers/clk/baikal-t1/ccu-pll.h | 64
drivers/clk/baikal-t1/clk-ccu-pll.c | 204 ++
7 files changed, 860 insertions(+)
create mode 100644 drivers/clk/baikal-t1/Kconfig
create mode 100644 drivers/clk/baikal-t1/Makefile
create mode 100644 drivers/clk/baikal-t1/ccu-pll.c
create mode 100644 drivers/clk/baikal-t1/ccu-pll.h
create mode 100644 drivers/clk/baikal-t1/clk-ccu-pll.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index bcb257baed06..b32da34ebcf9 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -341,6 +341,7 @@ config COMMON_CLK_FIXED_MMIO
source "drivers/clk/actions/Kconfig"
source "drivers/clk/analogbits/Kconfig"
+source "drivers/clk/baikal-t1/Kconfig"
source "drivers/clk/bcm/Kconfig"
source "drivers/clk/hisilicon/Kconfig"
source "drivers/clk/imgtec/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f4169cc2fd31..1496045d4e01 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -75,6 +75,7 @@ obj-y += analogbits/
obj-$(CONFIG_COMMON_CLK_AT91) += at91/
obj-$(CONFIG_ARCH_ARTPEC) += axis/
obj-$(CONFIG_ARC_PLAT_AXS10X) += axs10x/
+obj-$(CONFIG_CLK_BAIKAL_T1)+= baikal-t1/
obj-y += bcm/
obj-$(CONFIG_ARCH_BERLIN) += berlin/
obj-$(CONFIG_ARCH_DAVINCI) += davinci/
diff --git a/drivers/clk/baikal-t1/Kconfig b/drivers/clk/baikal-t1/Kconfig
new file mode 100644
index ..00398ee916dc
--- /dev/null
+++ b/drivers/clk/baikal-t1/Kconfig
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config CLK_BAIKAL_T1
+ bool "Baikal-T1 Clocks Control Unit interface"
+ depends on (MIPS_BAIKAL_T1 && OF) ||
[PATCH v3 4/4] clk: Add Baikal-T1 CCU Dividers driver
Nearly each Baikal-T1 IP-core is supposed to have a clock source
of particular frequency. But since there are greater than five
IP-blocks embedded into the SoC, the CCU PLLs can't fulfill all the
needs. Baikal-T1 CCU provides a set of fixed and configurable clock
dividers in order to generate a necessary signal for each chip
sub-block.
This driver creates the of-based hardware clocks for each divider
available in Baikal-T1 CCU. The same way as for PLLs we split the
functionality up into the clocks operations (gate, ungate, set rate,
etc) and hardware clocks declaration/registration procedures.
In accordance with the CCU documentation all its dividers are distributed
into two CCU sub-blocks: AXI-bus and system devices reference clocks.
The former sub-block is used to supply the clocks for AXI-bus interfaces
(AXI clock domains) and the later one provides the SoC IP-cores reference
clocks. Each sub-block is represented by a dedicated DT node, so they
have different compatible strings to distinguish one from another.
For some reason CCU provides the dividers of different types. Some
dividers can be gateable some can't, some are fixed while the others
are variable, some have special divider' limitations, some've got a
non-standard register layout and so on. In order to cover all of these
cases the hardware clocks driver is designed with an info-descriptor
pattern. So there are special static descriptors declared for the
dividers of each type with additional flags describing the block
peculiarity. These descriptors are then used to create hardware clocks
with proper operations.
Some CCU dividers provide a way to reset a domain they generate
a clock for. So the CCU AXI-bus and CCU system devices clock
drivers also perform the reset controller registration.
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Arnd Bergmann
Cc: Rob Herring
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
Changelog v2:
- Rearrange the SoBs.
- Alter the commit message, since CCU isn't considered as MFD anymore.
- Enable the CCU Divider clock driver by default only if MIPS_BAIKAL_T1
config.
- Fix spelling in the CCU Dividers kernel config description.
- Replace lock delay and frequency calculation macros with inline functions.
- Replace the data field setter and getter macro with handwritten inliners.
Alas FIELD_{GET,PREP} can't be used here due to non-constant mask.
- Discard CLK_IGNORE_UNUSED flag setting. It's redundant since CLK_IS_CRITICAL
is enough for cases when it's appropriate.
- Don't declare private copies of the Common Clock flags. Driver specific flags
I renamed to "features".
- Comment out the CLK_IS_CRITICAL flag settings.
- Discard !div test in ccu_div_hw_unregister() method.
- Discard ccu_div_get_clk_id() method. Use not-null check instead of FFs-based
invalid ID value.
- Discard alive probe message.
- Remove "clock-output-names" property support.
- Convert the driver to using syscon regmap instead of direct IO methods,
since now the PLLs DT node is supposed to be a sub-node of the Baikal-T1
System Controller node.
- Add DebugFS nodes in RO-mode by default.
---
drivers/clk/baikal-t1/Kconfig | 12 +
drivers/clk/baikal-t1/Makefile | 1 +
drivers/clk/baikal-t1/ccu-div.c | 602
drivers/clk/baikal-t1/ccu-div.h | 110 +
drivers/clk/baikal-t1/clk-ccu-div.c | 487 ++
5 files changed, 1212 insertions(+)
create mode 100644 drivers/clk/baikal-t1/ccu-div.c
create mode 100644 drivers/clk/baikal-t1/ccu-div.h
create mode 100644 drivers/clk/baikal-t1/clk-ccu-div.c
diff --git a/drivers/clk/baikal-t1/Kconfig b/drivers/clk/baikal-t1/Kconfig
index 00398ee916dc..03102f1094bc 100644
--- a/drivers/clk/baikal-t1/Kconfig
+++ b/drivers/clk/baikal-t1/Kconfig
@@ -27,4 +27,16 @@ config CLK_BT1_CCU_PLL
CPUs, DDR, etc.) or passed over the clock dividers to be only
then used as an individual reference clock of a target device.
+config CLK_BT1_CCU_DIV
+ bool "Baikal-T1 CCU Dividers support"
+ select RESET_CONTROLLER
+ select MFD_SYSCON
+ default MIPS_BAIKAL_T1
+ help
+ Enable this to support the CCU dividers used to distribute clocks
+ between AXI-bus and system devices coming from CCU PLLs of Baikal-T1
+ SoC. CCU dividers can be either configurable or with fixed divider,
+ either gateable or ungateable. Some of the CCU dividers can be as well
+ used to reset the domains they're supplying clock to.
+
endif
diff --git a/drivers/clk/baikal-t1/Makefile b/drivers/clk/baikal-t1/Makefile
index 4a612bbacc37..b3b9590b95ed 100644
--- a/drivers/clk/baikal-t1/Makefile
+++ b/drivers/clk/baikal-t1/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_CLK_BT1_CCU_PLL) += ccu-pll.o clk-ccu-pll.o
+obj-$(CONFIG_CLK_BT1_CCU_DIV) += ccu-div.o clk-ccu-div.o
diff --git a/drivers/clk/baikal-t1/ccu-div.c b/drivers/clk/baikal-t1/ccu-div.c
[PATCH v3 0/4] clk: Add Baikal-T1 SoC Clock Control Unit support
Stephen, Michael, the merge window is upon us, please review/merge in/whatever
this patchset.
Clocks Control Unit is the core of Baikal-T1 SoC responsible for the chip
subsystems clocking and resetting. The CCU is connected with an external
fixed rate oscillator, which signal is transformed into clocks of various
frequencies and then propagated to either individual IP-blocks or to groups
of blocks (clock domains). The transformation is done by means of PLLs and
gateable/non-gateable, fixed/variable dividers embedded into the CCU. There
are five PLLs to create a clock for the MIPS P5600 cores, the embedded DDR
controller, SATA, Ethernet and PCIe domains. The last three PLLs CLKOUT are
then passed over CCU dividers to create signals required for the target clock
domains: individual AXI and APB bus clocks, SoC devices reference clocks.
The CCU divider registers may also provide a way to reset the target devices
state.
So this patchset introduces the Baikal-T1 clock and reset drivers of CCU
PLLs, AXI-bus clock dividers and system devices clock dividers.
This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
0e698dfa2822 ("Linux 5.7-rc4")
tag: v5.7-rc4
Changelog v2:
- Rearrange the SoBs.
- Discard comments in the binding files headers.
- Add dual GPL/BSD license to the bindings.
- Add spaces around the ASCII-graphics in the bindings description.
- Discard redundant dt objects check against "/schemas/clock/clock.yaml#"
schema.
- Discard redundant descriptions of the "#clock-cells" and "#reset-cells"
properties in dt bindings schema.
- Discard "reg" property since the CCU dividers DT nodes are supposed be
children of the syscon-compatible system controller node.
- Remove "clock-output-names" property support.
- Replace "additionalProperties: false" with "unevaluatedProperties: false"
in the bindings.
- Lowercase the nodes name in the binding examples.
- Use "clock-controller" node name suffix in the binding examples.
- Remove unnecessary comments in the clocks and resets dt-binding header
files.
- Don't enable the CCU clock drivers by default for COMPILE_TEST config.
- Make sure the CCU drivers depend on OF kernel config only when built for
Baikal-T1-based platform.
- Fix spelling in the CCU PLL and Dividers kernel configs description.
- Replace lock delay and frequency calculation macros with inline functions.
- Use 64-bits arithmetics in the CCU PLL frequency calculation function.
- Use FIELD_{GET,PREP}() macro instead of handwritten field setters and
getters.
- Discard CLK_IGNORE_UNUSED flag setting. It's redundant since CLK_IS_CRITICAL
is enough for cases when it's appropriate.
- Comment out the CLK_IS_CRITICAL flag settings.
- Discard !pll and !div tests from ccu_pll_hw_unregister() and
ccu_div_get_clk_id()
methods respectively.
- Discard alive probe messages.
- Convert the drivers to using syscon regmap instead of direct IO methods,
since now the PLLs DT node is supposed to be a sub-node of the Baikal-T1
System Controller node.
- Add DebugFS nodes in RO-mode by default.
Link:
https://lore.kernel.org/linux-clk/20200506222300.30895-1-sergey.se...@baikalelectronics.ru/
Changelog v3:
- Get the reg property back to the DT bindings even though the driver is
using the parental syscon regmap.
- The DT schema will live separately from the system controller, but the
corresponding sub-node of the later DT schema will $ref this one.
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Maxim Kaurkin
Cc: Pavel Parkhomenko
Cc: Ramil Zaripov
Cc: Ekaterina Skachko
Cc: Vadim Vlasov
Cc: Alexey Kolotnikov
Cc: Arnd Bergmann
Cc: Rob Herring
Cc: linux-...@vger.kernel.org
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (4):
dt-bindings: clk: Add Baikal-T1 CCU PLLs binding
dt-bindings: clk: Add Baikal-T1 CCU Dividers binding
clk: Add Baikal-T1 CCU PLLs driver
clk: Add Baikal-T1 CCU Dividers driver
.../bindings/clock/baikal,bt1-ccu-div.yaml| 188 ++
.../bindings/clock/baikal,bt1-ccu-pll.yaml| 131
drivers/clk/Kconfig | 1 +
drivers/clk/Makefile | 1 +
drivers/clk/baikal-t1/Kconfig | 42 ++
drivers/clk/baikal-t1/Makefile| 3 +
drivers/clk/baikal-t1/ccu-div.c | 602 ++
drivers/clk/baikal-t1/ccu-div.h | 110
drivers/clk/baikal-t1/ccu-pll.c | 558
drivers/clk/baikal-t1/ccu-pll.h | 64 ++
drivers/clk/baikal-t1/clk-ccu-div.c | 487 ++
drivers/clk/baikal-t1/clk-ccu-pll.c | 204 ++
include/dt-bindings/clock/bt1-ccu.h | 48 ++
include/dt-bindings/reset/bt1-ccu.h | 25 +
14 files changed, 2464 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml
create mode 100644
[PATCH v3 2/4] dt-bindings: clk: Add Baikal-T1 CCU Dividers binding
After being gained by the CCU PLLs the signals must be transformed to be suitable for the clock-consumers. This is done by a set of dividers embedded into the CCU. A first block of dividers is used to create reference clocks for AXI-bus of high-speed peripheral IP-cores of the chip. The second block dividers alter the PLLs output signals to be then consumed by SoC peripheral devices. Both block DT nodes are ordinary clock-providers with standard set of properties supported. But in addition to that each clock provider can be used to reset the corresponding clock domain. This makes the AXI-bus and System Devices CCU DT nodes to be also reset-providers. Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Arnd Bergmann Cc: linux-m...@vger.kernel.org --- Changelog v2: - Rearrange the SoBs. - Combine AXI-bus and System Devices CCU bindings into a single file. - Discard comments in the bindings file header. - Add dual GPL/BSD license. - Add spaces around the ASCII-graphics in the binding description. - Remove reference to Documentation/devicetree/bindings/clock/clock-bindings.txt file. - Discard redundant object check against "/schemas/clock/clock.yaml#" schema. - Discard redundant descriptions of "#clock-cells" and "#reset-cells" properties. - Discard "reg" property since the CCU dividers DT nodes are supposed be children of the syscon-compatible system controller node. - Remove "clock-output-names" property support. - Replace "additionalProperties: false" with "unevaluatedProperties: false". - Lowercase the nodes name in the examples. - Use "clock-controller" node name suffix in the examples. - Remove unnecessary comments in the clocks and resets dt-binding header files. - Discard label definitions in the examples. Changelog v3: - Get the reg property back even though the driver is using the parental syscon regmap. - The DT schema will live separately from the system controller, but the corresponding sub-node of the later DT schema will $ref this one. --- .../bindings/clock/baikal,bt1-ccu-div.yaml| 188 ++ include/dt-bindings/clock/bt1-ccu.h | 32 +++ include/dt-bindings/reset/bt1-ccu.h | 25 +++ 3 files changed, 245 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml create mode 100644 include/dt-bindings/reset/bt1-ccu.h diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml new file mode 100644 index ..2821425ee445 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml @@ -0,0 +1,188 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/baikal,bt1-ccu-div.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Baikal-T1 Clock Control Unit Dividers + +maintainers: + - Serge Semin + +description: | + Clocks Control Unit is the core of Baikal-T1 SoC System Controller + responsible for the chip subsystems clocking and resetting. The CCU is + connected with an external fixed rate oscillator, which signal is transformed + into clocks of various frequencies and then propagated to either individual + IP-blocks or to groups of blocks (clock domains). The transformation is done + by means of an embedded into CCU PLLs and gateable/non-gateable dividers. The + later ones are described in this binding. Each clock domain can be also + individually reset by using the domain clocks divider configuration + registers. Baikal-T1 CCU is logically divided into the next components: + 1) External oscillator (normally XTAL's 25 MHz crystal oscillator, but + in general can provide any frequency supported by the CCU PLLs). + 2) PLLs clocks generators (PLLs). + 3) AXI-bus clock dividers (AXI) - described in this binding file. + 4) System devices reference clock dividers (SYS) - described in this binding + file. + which are connected with each other as shown on the next figure: + + +---+ + | Baikal-T1 CCU | + | ++--|- MIPS P5600 cores + | +-|PLLs|--|- DDR controller + | | ++ | + ++ | | | | | + |XTAL|--|-+ | | +---+-| + ++ | | | +-|AXI|-|- AXI-bus + | | |+---+-| + | | | | + | | ++---+-|- APB-bus + | +---|SYS|-|- Low-speed Devices + | +---+-|- High-speed Devices + +---+ + + Each sub-block is represented as a separate DT node and has an individual + driver to be bound with. + + In order to create signals of wide range frequencies the external oscillator + output is primarily connected to a set of CCU PLLs. Some of PLLs CLKOUT are + then passed over CCU dividers to create signals required for the target clock + domain (like AXI-bus or System Device
Re: [PATCH v3 02/18] nitro_enclaves: Define the PCI device interface
On Tue, May 26, 2020 at 08:01:36PM +0300, Paraschiv, Andra-Irina wrote:
>
>
> On 26/05/2020 09:44, Greg KH wrote:
> > On Tue, May 26, 2020 at 01:13:18AM +0300, Andra Paraschiv wrote:
> > > +struct enclave_get_slot_req {
> > > + /* Context ID (CID) for the enclave vsock device. */
> > > + u64 enclave_cid;
> > > +} __attribute__ ((__packed__));
> > Can you really "pack" a single member structure?
> >
> > Anyway, we have better ways to specify this instead of the "raw"
> > __attribute__ option. But first see if you really need any of these, at
> > first glance, I do not think you do at all, and they can all be removed.
>
> There are a couple of data structures with more than one member and multiple
> field sizes. And for the ones that are not, gathered as feedback from
> previous rounds of review that should consider adding a "flags" field in
> there for further extensibility.
Please do not do that in ioctls. Just create new calls instead of
trying to "extend" existing ones. It's always much easier.
> I can modify to have "__packed" instead of the attribute callout.
Make sure you even need that, as I don't think you do for structures
like the above one, right?
thanks,
greg k-h
Re: [PATCH v4 36/36] mm: Align THP mappings for non-DAX
On Tue, May 26, 2020 at 04:05:58PM -0600, William Kucharski wrote: > Thinking about this, if the intent is to make THP usable for any > greater than PAGESIZE page size, this routine should probably go back > to taking a size or perhaps order parameter so it could be called to > align addresses accordingly rather than hard code PMD_SIZE. Yes, that's a good point. For example, on ARM, we'd want to 64kB-align files which we could use 64kB pages, but there would be no point doing that on x86. I'll revert to the earlier version of this patch that you sent. Not sure how best to allow the architecture to tell us what page sizes are useful to align to, but that earlier patch is a better base to build on than this version.
Re: [PATCH v3 04/18] nitro_enclaves: Init PCI device driver
On Tue, May 26, 2020 at 09:35:33PM +0300, Paraschiv, Andra-Irina wrote: > > > On 26/05/2020 09:48, Greg KH wrote: > > On Tue, May 26, 2020 at 01:13:20AM +0300, Andra Paraschiv wrote: > > > The Nitro Enclaves PCI device is used by the kernel driver as a means of > > > communication with the hypervisor on the host where the primary VM and > > > the enclaves run. It handles requests with regard to enclave lifetime. > > > > > > Setup the PCI device driver and add support for MSI-X interrupts. > > > > > > Signed-off-by: Alexandru-Catalin Vasile > > > Signed-off-by: Alexandru Ciobotaru > > > Signed-off-by: Andra Paraschiv > > > --- > > > Changelog > > > > > > v2 -> v3 > > > > > > * Remove the GPL additional wording as SPDX-License-Identifier is already > > > in > > > place. > > > * Remove the WARN_ON calls. > > > * Remove linux/bug include that is not needed. > > > * Update static calls sanity checks. > > > * Remove "ratelimited" from the logs that are not in the ioctl call paths. > > > * Update kzfree() calls to kfree(). > > > > > > v1 -> v2 > > > > > > * Add log pattern for NE. > > > * Update PCI device setup functions to receive PCI device data structure > > > and > > > then get private data from it inside the functions logic. > > > * Remove the BUG_ON calls. > > > * Add teardown function for MSI-X setup. > > > * Update goto labels to match their purpose. > > > * Implement TODO for NE PCI device disable state check. > > > * Update function name for NE PCI device probe / remove. > > > --- > > > drivers/virt/nitro_enclaves/ne_pci_dev.c | 252 +++ > > > 1 file changed, 252 insertions(+) > > > create mode 100644 drivers/virt/nitro_enclaves/ne_pci_dev.c > > > > > > diff --git a/drivers/virt/nitro_enclaves/ne_pci_dev.c > > > b/drivers/virt/nitro_enclaves/ne_pci_dev.c > > > new file mode 100644 > > > index ..0b66166787b6 > > > --- /dev/null > > > +++ b/drivers/virt/nitro_enclaves/ne_pci_dev.c > > > @@ -0,0 +1,252 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * Copyright 2020 Amazon.com, Inc. or its affiliates. All Rights > > > Reserved. > > > + */ > > > + > > > +/* Nitro Enclaves (NE) PCI device driver. */ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#include "ne_misc_dev.h" > > > +#include "ne_pci_dev.h" > > > + > > > +#define DEFAULT_TIMEOUT_MSECS (12) /* 120 sec */ > > > + > > > +#define NE "nitro_enclaves: " > > Why is this needed? The dev_* functions should give you all the > > information that you need to properly describe the driver and device in > > question. No extra "prefixes" should be needed at all. > > This was needed to have an identifier for the overall NE logic - PCI dev, > ioctl and misc dev. Why? They are all different "devices", and refer to different interfaces. Stick to what the dev_* gives you for them. You probably want to stick with the pci dev for almost all of those anyway. > The ioctl and misc dev logic has pr_* logs, but I can update them to dev_* > with misc dev, then remove this prefix. That would be good, thanks. greg k-h
Re: [PATCH] tpm: Revert "tpm: fix invalid locking in NONBLOCKING mode"
On Tue, 2020-05-26 at 12:38 -0700, James Bottomley wrote:
> On Tue, 2020-05-26 at 19:23 +, mario.limoncie...@dell.com wrote:
> > > On Tue, 2020-05-26 at 13:32 -0500, Mario Limonciello wrote:
> > > > This reverts commit d23d12484307b40eea549b8a858f5fffad913897.
> > > >
> > > > This commit has caused regressions for the XPS 9560 containing
> > > > a Nuvoton TPM.
> > >
> > > Presumably this is using the tis driver?
> >
> > Correct.
> >
> > > > As mentioned by the reporter all TPM2 commands are failing
> > > > with:
> > > > ERROR:tcti:src/tss2-tcti/tcti-
> > > > device.c:290:tcti_device_receive()
> > > > Failed to read response from fd 3, got errno 1: Operation not
> > > > permitted
> > > >
> > > > The reporter bisected this issue back to this commit which was
> > > > backported to stable as commit 4d6ebc4.
> > >
> > > I think the problem is request_locality ... for some inexplicable
> > > reason a failure there returns -1, which is EPERM to user space.
> > >
> > > That seems to be a bug in the async code since everything else
> > > gives a ESPIPE error if tpm_try_get_ops fails ... at least no-one
> > > assumes it gives back a sensible return code.
> > >
> > > What I think is happening is that with the patch the TPM goes
> > > through a quick sequence of request, relinquish, request,
> > > relinquish and it's the third request which is failing (likely
> > > timing out). Without the patch, the patch there's only one
> > > request,relinquish cycle because the ops are held while the async
> > > work is executed. I have a vague recollection that there is a
> > > problem with too many locality request in quick succession, but
> > > I'll defer to Jason, who I think understands the intricacies of
> > > localities better than I do.
> >
> > Thanks, I don't pretend to understand the nuances of this
> > particular
> > code, but I was hoping that the request to revert got some
> > attention
> > since Alex's kernel Bugzilla and message a few months ago to linux
> > integrity weren't.
> >
> > > If that's the problem, the solution looks simple enough: just
> > > move
> > > the ops get down because the priv state is already protected by
> > > the
> > > buffer mutex
> >
> > Yeah, if that works for Alex's situation it certainly sounds like a
> > better solution than reverting this patch as this patch actually
> > does
> > fix a problem reported by Jeffrin originally.
> >
> > Could you propose a specific patch that Alex and Jeffrin can
> > perhaps
> > both try?
>
> Um, what's wrong with the one I originally attached and which you
> quote
> below? It's only compile tested, but I think it will work, if the
> theory is correct.
>
> James
>
> > > James
> > >
> > > ---
> > >
> > > diff --git a/drivers/char/tpm/tpm-dev-common.c
> > > b/drivers/char/tpm/tpm-dev-
> > > common.c
> > > index 87f449340202..1784530b8387 100644
> > > --- a/drivers/char/tpm/tpm-dev-common.c
> > > +++ b/drivers/char/tpm/tpm-dev-common.c
> > > @@ -189,15 +189,6 @@ ssize_t tpm_common_write(struct file *file,
> > > const char
> > > __user *buf,
> > > goto out;
> > > }
> > >
> > > - /* atomic tpm command send and result receive. We only
> > > hold the ops
> > > - * lock during this period so that the tpm can be
> > > unregistered even if
> > > - * the char dev is held open.
> > > - */
> > > - if (tpm_try_get_ops(priv->chip)) {
> > > - ret = -EPIPE;
> > > - goto out;
> > > - }
> > > -
> > > priv->response_length = 0;
> > > priv->response_read = false;
> > > *off = 0;
> > > @@ -211,11 +202,19 @@ ssize_t tpm_common_write(struct file *file,
> > > const char
> > > __user *buf,
> > > if (file->f_flags & O_NONBLOCK) {
> > > priv->command_enqueued = true;
> > > queue_work(tpm_dev_wq, >async_work);
> > > - tpm_put_ops(priv->chip);
> > > mutex_unlock(>buffer_mutex);
> > > return size;
> > > }
> > >
> > > + /* atomic tpm command send and result receive. We only
> > > hold the ops
> > > + * lock during this period so that the tpm can be
> > > unregistered even if
> > > + * the char dev is held open.
> > > + */
> > > + if (tpm_try_get_ops(priv->chip)) {
> > > + ret = -EPIPE;
> > > + goto out;
> > > + }
> > > +
> > > ret = tpm_dev_transmit(priv->chip, priv->space, priv-
> > > > data_buffer,
> > >
> > > sizeof(priv->data_buffer));
> > > tpm_put_ops(priv->chip);
When using your patch, I get a hang when trying to use tpm2_getcap, and
dmesg shows some info.
[ 570.913779] BUG: unable to handle page fault for address: b20001247000
[ 570.913782] #PF: supervisor write access in kernel mode
[ 570.913783] #PF: error_code(0x0002) - not-present page
[ 570.913784] PGD 0 P4D 0
[ 570.913785] Oops: 0002 [#3] SMP PTI
[ 570.913787] CPU: 6 PID: 24744 Comm: tpm2_getcap Tainted: G UD
5.7.0-rc7+ #31
[ 570.913788] Hardware name: Dell Inc. XPS 15 9560/05FFDN, BIOS 1.18.0
11/17/2019
[ 570.913791] RIP:
[PATCH] iommu: Relax ACS requirement for Intel RCiEP devices.
All Intel platforms guarantee that all root complex implementations
must send transactions up to IOMMU for address translations. Hence for
RCiEP devices that are Vendor ID Intel, can claim exception for lack of
ACS support.
3.16 Root-Complex Peer to Peer Considerations
When DMA remapping is enabled, peer-to-peer requests through the
Root-Complex must be handled
as follows:
• The input address in the request is translated (through first-level,
second-level or nested translation) to a host physical address (HPA).
The address decoding for peer addresses must be done only on the
translated HPA. Hardware implementations are free to further limit
peer-to-peer accesses to specific host physical address regions
(or to completely disallow peer-forwarding of translated requests).
• Since address translation changes the contents (address field) of
the PCI Express Transaction Layer Packet (TLP), for PCI Express
peer-to-peer requests with ECRC, the Root-Complex hardware must use
the new ECRC (re-computed with the translated address) if it
decides to forward the TLP as a peer request.
• Root-ports, and multi-function root-complex integrated endpoints, may
support additional peerto-peer control features by supporting PCI Express
Access Control Services (ACS) capability. Refer to ACS capability in
PCI Express specifications for details.
Since Linux didn't give special treatment to allow this exception, certain
RCiEP MFD devices are getting grouped in a single iommu group. This
doesn't permit a single device to be assigned to a guest for instance.
In one vendor system: Device 14.x were grouped in a single IOMMU group.
/sys/kernel/iommu_groups/5/devices/:00:14.0
/sys/kernel/iommu_groups/5/devices/:00:14.2
/sys/kernel/iommu_groups/5/devices/:00:14.3
After the patch:
/sys/kernel/iommu_groups/5/devices/:00:14.0
/sys/kernel/iommu_groups/5/devices/:00:14.2
/sys/kernel/iommu_groups/6/devices/:00:14.3 <<< new group
14.0 and 14.2 are integrated devices, but legacy end points.
Whereas 14.3 was a PCIe compliant RCiEP.
00:14.3 Network controller: Intel Corporation Device 9df0 (rev 30)
Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
This permits assigning this device to a guest VM.
Fixes: f096c061f552 ("iommu: Rework iommu_group_get_for_pci_dev()")
Signed-off-by: Ashok Raj
To: Joerg Roedel
To: Bjorn Helgaas
Cc: linux-kernel@vger.kernel.org
Cc: io...@lists.linux-foundation.org
Cc: Lu Baolu
Cc: Alex Williamson
Cc: Darrel Goeddel
Cc: Mark Scott ,
Cc: Romil Sharma
Cc: Ashok Raj
---
drivers/iommu/iommu.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 2b471419e26c..31b595dfedde 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1187,7 +1187,18 @@ static struct iommu_group
*get_pci_function_alias_group(struct pci_dev *pdev,
struct pci_dev *tmp = NULL;
struct iommu_group *group;
- if (!pdev->multifunction || pci_acs_enabled(pdev, REQ_ACS_FLAGS))
+ /*
+* Intel VT-d Specification Section 3.16, Root-Complex Peer to Peer
+* Considerations manadate that all transactions in RCiEP's and
+* even Integrated MFD's *must* be sent up to the IOMMU. P2P is
+* only possible on translated addresses. This gives enough
+* guarantee that such devices can be forgiven for lack of ACS
+* support.
+*/
+ if (!pdev->multifunction ||
+ (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+pci_pcie_type(pdev) == PCI_EXP_TYPE_RC_END) ||
+pci_acs_enabled(pdev, REQ_ACS_FLAGS))
return NULL;
for_each_pci_dev(tmp) {
--
2.7.4
[PATCH][next] ice: Replace one-element arrays with flexible-arrays
The current codebase makes use of one-element arrays in the following
form:
struct something {
int length;
u8 data[1];
};
struct something *instance;
instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);
but the preferred mechanism to declare variable-length types such as
these ones is a flexible array member[1][2], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on. So, replace
the one-element array with a flexible-array member.
Also, make use of the sizeof_field() and offsetof() helpers to simplify
some macros and properly calcualte the size of the structures that
contain flexible-array members.
This issue was found with the help of Coccinelle and, audited and fixed
_manually_.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva
---
.../net/ethernet/intel/ice/ice_adminq_cmd.h | 6 ++---
drivers/net/ethernet/intel/ice/ice_switch.c | 22 +--
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
index 586d69491268a..faa21830e40d8 100644
--- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
@@ -570,7 +570,7 @@ struct ice_sw_rule_lkup_rx_tx {
* lookup-type
*/
__le16 hdr_len;
- u8 hdr[1];
+ u8 hdr[];
} __packed;
/* Add/Update/Remove large action command/response entry
@@ -580,7 +580,7 @@ struct ice_sw_rule_lkup_rx_tx {
struct ice_sw_rule_lg_act {
__le16 index; /* Index in large action table */
__le16 size;
- __le32 act[1]; /* array of size for actions */
+ __le32 act[]; /* array of size for actions */
/* Max number of large actions */
#define ICE_MAX_LG_ACT 4
/* Bit 0:1 - Action type */
@@ -640,7 +640,7 @@ struct ice_sw_rule_lg_act {
struct ice_sw_rule_vsi_list {
__le16 index; /* Index of VSI/Prune list */
__le16 number_vsi;
- __le16 vsi[1]; /* Array of number_vsi VSI numbers */
+ __le16 vsi[]; /* Array of number_vsi VSI numbers */
};
/* Query VSI list command/response entry */
diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c
b/drivers/net/ethernet/intel/ice/ice_switch.c
index 0156b73df1b1f..e3e2ee7bec9e7 100644
--- a/drivers/net/ethernet/intel/ice/ice_switch.c
+++ b/drivers/net/ethernet/intel/ice/ice_switch.c
@@ -30,24 +30,22 @@ static const u8 dummy_eth_header[DUMMY_ETH_HDR_LEN] = {
0x2, 0, 0, 0, 0, 0,
#define ICE_SW_RULE_RX_TX_ETH_HDR_SIZE \
(sizeof(struct ice_aqc_sw_rules_elem) - \
-sizeof(((struct ice_aqc_sw_rules_elem *)0)->pdata) + \
-sizeof(struct ice_sw_rule_lkup_rx_tx) + DUMMY_ETH_HDR_LEN - 1)
+sizeof_field(struct ice_aqc_sw_rules_elem, pdata) + \
+sizeof(struct ice_sw_rule_lkup_rx_tx) + DUMMY_ETH_HDR_LEN)
#define ICE_SW_RULE_RX_TX_NO_HDR_SIZE \
(sizeof(struct ice_aqc_sw_rules_elem) - \
-sizeof(((struct ice_aqc_sw_rules_elem *)0)->pdata) + \
-sizeof(struct ice_sw_rule_lkup_rx_tx) - 1)
+sizeof_field(struct ice_aqc_sw_rules_elem, pdata) + \
+sizeof(struct ice_sw_rule_lkup_rx_tx))
#define ICE_SW_RULE_LG_ACT_SIZE(n) \
(sizeof(struct ice_aqc_sw_rules_elem) - \
-sizeof(((struct ice_aqc_sw_rules_elem *)0)->pdata) + \
-sizeof(struct ice_sw_rule_lg_act) - \
-sizeof(((struct ice_sw_rule_lg_act *)0)->act) + \
-((n) * sizeof(((struct ice_sw_rule_lg_act *)0)->act)))
+sizeof_field(struct ice_aqc_sw_rules_elem, pdata) + \
+offsetof(struct ice_sw_rule_lg_act, act) + \
+((n) * sizeof(__le32)))
#define ICE_SW_RULE_VSI_LIST_SIZE(n) \
(sizeof(struct ice_aqc_sw_rules_elem) - \
-sizeof(((struct ice_aqc_sw_rules_elem *)0)->pdata) + \
-sizeof(struct ice_sw_rule_vsi_list) - \
-sizeof(((struct ice_sw_rule_vsi_list *)0)->vsi) + \
-((n) * sizeof(((struct ice_sw_rule_vsi_list *)0)->vsi)))
+sizeof_field(struct ice_aqc_sw_rules_elem, pdata) + \
+offsetof(struct ice_sw_rule_vsi_list, vsi) + \
+((n) * sizeof(__le16)))
/**
* ice_init_def_sw_recp - initialize the recipe book keeping tables
--
2.26.2
Re: [RFC 16/16] KVM: Unmap protected pages from direct mapping
On Tue, May 26, 2020 at 09:16:38AM +0300, Mike Rapoport wrote:
> On Fri, May 22, 2020 at 03:52:14PM +0300, Kirill A. Shutemov wrote:
> > If the protected memory feature enabled, unmap guest memory from
> > kernel's direct mappings.
> >
> > Migration and KSM is disabled for protected memory as it would require a
> > special treatment.
> >
> > Signed-off-by: Kirill A. Shutemov
> > ---
> > arch/x86/mm/pat/set_memory.c | 1 +
> > include/linux/kvm_host.h | 3 ++
> > mm/huge_memory.c | 9 +
> > mm/ksm.c | 3 ++
> > mm/memory.c | 13 +++
> > mm/rmap.c| 4 ++
> > virt/kvm/kvm_main.c | 74
> > 7 files changed, 107 insertions(+)
> >
> > diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> > index 6f075766bb94..13988413af40 100644
> > --- a/arch/x86/mm/pat/set_memory.c
> > +++ b/arch/x86/mm/pat/set_memory.c
> > @@ -2227,6 +2227,7 @@ void __kernel_map_pages(struct page *page, int
> > numpages, int enable)
> >
> > arch_flush_lazy_mmu_mode();
> > }
> > +EXPORT_SYMBOL_GPL(__kernel_map_pages);
> >
> > #ifdef CONFIG_HIBERNATION
> > bool kernel_page_present(struct page *page)
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index b6944f88033d..e1d7762b615c 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -705,6 +705,9 @@ int kvm_protect_all_memory(struct kvm *kvm);
> > int kvm_protect_memory(struct kvm *kvm,
> >unsigned long gfn, unsigned long npages, bool protect);
> >
> > +void kvm_map_page(struct page *page, int nr_pages);
> > +void kvm_unmap_page(struct page *page, int nr_pages);
> > +
> > int gfn_to_page_many_atomic(struct kvm_memory_slot *slot, gfn_t gfn,
> > struct page **pages, int nr_pages);
> >
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index c3562648a4ef..d8a444a401cc 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -33,6 +33,7 @@
> > #include
> > #include
> > #include
> > +#include
>
> This does not seem right...
I agree. I try to find a more clean way to deal with it.
> > #include
> > #include
> > @@ -650,6 +651,10 @@ static vm_fault_t __do_huge_pmd_anonymous_page(struct
> > vm_fault *vmf,
> > spin_unlock(vmf->ptl);
> > count_vm_event(THP_FAULT_ALLOC);
> > count_memcg_events(memcg, THP_FAULT_ALLOC, 1);
> > +
> > + /* Unmap page from direct mapping */
> > + if (vma_is_kvm_protected(vma))
> > + kvm_unmap_page(page, HPAGE_PMD_NR);
>
> ... and neither does this.
>
> I think the map/unmap primitives shoud be a part of the generic mm and
> not burried inside KVM.
Well, yes. Except, kvm_map_page() also clears the page before bringing it
back to direct mappings. Not sure yet how to deal with it.
> > return 0;
> > @@ -1886,6 +1891,10 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct
> > vm_area_struct *vma,
> > page_remove_rmap(page, true);
> > VM_BUG_ON_PAGE(page_mapcount(page) < 0, page);
> > VM_BUG_ON_PAGE(!PageHead(page), page);
> > +
> > + /* Map the page back to the direct mapping */
> > + if (vma_is_kvm_protected(vma))
> > + kvm_map_page(page, HPAGE_PMD_NR);
> > } else if (thp_migration_supported()) {
> > swp_entry_t entry;
> >
> > diff --git a/mm/ksm.c b/mm/ksm.c
> > index 281c00129a2e..942b88782ac2 100644
> > --- a/mm/ksm.c
> > +++ b/mm/ksm.c
> > @@ -527,6 +527,9 @@ static struct vm_area_struct *find_mergeable_vma(struct
> > mm_struct *mm,
> > return NULL;
> > if (!(vma->vm_flags & VM_MERGEABLE) || !vma->anon_vma)
> > return NULL;
> > + /* TODO */
>
> Probably this is not something that should be done. For a security
> sensitive environment that wants protected memory, KSM woudn't be
> relevant anyway...
Hm. True.
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index 71aac117357f..defc33d3a124 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -51,6 +51,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -2718,6 +2719,72 @@ void kvm_vcpu_mark_page_dirty(struct kvm_vcpu *vcpu,
> > gfn_t gfn)
> > }
> > EXPORT_SYMBOL_GPL(kvm_vcpu_mark_page_dirty);
> >
> > +void kvm_map_page(struct page *page, int nr_pages)
> > +{
> > + int i;
> > +
> > + /* Clear page before returning it to the direct mapping */
> > + for (i = 0; i < nr_pages; i++) {
> > + void *p = map_page_atomic(page + i);
> > + memset(p, 0, PAGE_SIZE);
> > + unmap_page_atomic(p);
> > + }
> > +
> > + kernel_map_pages(page, nr_pages, 1);
> > +}
> > +EXPORT_SYMBOL_GPL(kvm_map_page);
> > +
> > +void kvm_unmap_page(struct page *page,
Re: [RFC] perf/core: allow ftrace for functions in kernel/event/core.c
> On May 26, 2020, at 3:04 PM, Steven Rostedt wrote: > > On Tue, 26 May 2020 23:54:15 +0200 > Peter Zijlstra wrote: > >> On Tue, May 26, 2020 at 09:46:29PM +, Song Liu wrote: >>> >>> On May 26, 2020, at 2:39 PM, Peter Zijlstra wrote: On Tue, May 26, 2020 at 02:28:26PM -0700, Song Liu wrote: > It is useful to trace functions in kernel/event/core.c. Allow ftrace for > them by removing $(CC_FLAGS_FTRACE) from Makefile. Did you try using the ftrace event with perf with this on? >>> >>> I have tried a few things, like >>> >>> perf stat -e probe:perf_read -I 1000 >>> perf record -e probe:__x64_sys_perf_event_open -aR >>> >>> They all work fine. >>> >>> Do you have some tricky functions that we should double check? >> >> I've no idea what probe: does. iirc there's something like >> ftrace:function that is like regular function tracing. >> >> At some point using that made the kernel really sick due to recursion >> between ftrace and perf. Quite possibly that's been fixed, dunno. > > In the early days there was a lot of issues with recursions, but I added a > lot of recursion protection since then. I'll give this patch a spin and see > if I can make it crash. Thanks! Song
Re: [RFC] perf/core: allow ftrace for functions in kernel/event/core.c
> On May 26, 2020, at 2:54 PM, Peter Zijlstra wrote: > > On Tue, May 26, 2020 at 09:46:29PM +, Song Liu wrote: >> >> >>> On May 26, 2020, at 2:39 PM, Peter Zijlstra wrote: >>> >>> On Tue, May 26, 2020 at 02:28:26PM -0700, Song Liu wrote: It is useful to trace functions in kernel/event/core.c. Allow ftrace for them by removing $(CC_FLAGS_FTRACE) from Makefile. >>> >>> Did you try using the ftrace event with perf with this on? >> >> I have tried a few things, like >> >> perf stat -e probe:perf_read -I 1000 >> perf record -e probe:__x64_sys_perf_event_open -aR >> >> They all work fine. >> >> Do you have some tricky functions that we should double check? > > I've no idea what probe: does. iirc there's something like > ftrace:function that is like regular function tracing. Those are kprobes. I have CONFIG_HAVE_KPROBES_ON_FTRACE=y in .config. > > At some point using that made the kernel really sick due to recursion > between ftrace and perf. Quite possibly that's been fixed, dunno. I also tried on ctx_sched_out() and event_sched_out(). They also work as expected. Thanks, Song
[PATCH v3] driver core: Update device link status correctly for SYNC_STATE_ONLY links
When SYNC_STATE_ONLY support was added in commit 05ef983e0d65 ("driver
core: Add device link support for SYNC_STATE_ONLY flag"),
SYNC_STATE_ONLY links were treated similar to STATELESS links in terms
of not blocking consumer probe if the supplier hasn't probed yet.
That caused a SYNC_STATE_ONLY device link's status to not get updated.
Since SYNC_STATE_ONLY device link is no longer useful once the
consumer probes, commit 21c27f06587d ("driver core: Fix
SYNC_STATE_ONLY device link implementation") addresses the status
update issue by deleting the SYNC_STATE_ONLY device link instead of
complicating the status update code.
However, there are still some cases where we need to update the status
of a SYNC_STATE_ONLY device link. This is because a SYNC_STATE_ONLY
device link can later get converted into a normal MANAGED device link
when a normal MANAGED device link is created between a supplier and
consumer that already have a SYNC_STATE_ONLY device link between them.
If a SYNC_STATE_ONLY device link's status isn't maintained correctly
till it's converted to a normal MANAGED device link, then the normal
MANAGED device link will end up with a wrong link status. This can cause
a warning stack trace[1] when the consumer device probes successfully.
This commit fixes the SYNC_STATE_ONLY device link status update issue
where it wouldn't transition correctly from DL_STATE_DORMANT or
DL_STATE_AVAILABLE to DL_STATE_CONSUMER_PROBE. It also resets the status
back to DL_STATE_DORMANT or DL_STATE_AVAILABLE if the consumer probe
fails.
[1] - https://lore.kernel.org/lkml/20200522204120.3b3c9ed6@apollo/
Fixes: 05ef983e0d65 ("driver core: Add device link support for SYNC_STATE_ONLY
flag")
Fixes: 21c27f06587d ("driver core: Fix SYNC_STATE_ONLY device link
implementation")
Reported-by: Michael Walle
Tested-by: Michael Walle
Signed-off-by: Saravana Kannan
---
v1->v2:
- Added code to "revert" the link status if consumer probe fails
v2->v3:
- Fixed copy-pasta where I was checking link->status instead of
link->flags.
drivers/base/core.c | 34 ++
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 791b7530599f..9a76dd44cb37 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -646,9 +646,17 @@ static void device_links_missing_supplier(struct device
*dev)
{
struct device_link *link;
- list_for_each_entry(link, >links.suppliers, c_node)
- if (link->status == DL_STATE_CONSUMER_PROBE)
+ list_for_each_entry(link, >links.suppliers, c_node) {
+ if (link->status != DL_STATE_CONSUMER_PROBE)
+ continue;
+
+ if (link->supplier->links.status == DL_DEV_DRIVER_BOUND) {
WRITE_ONCE(link->status, DL_STATE_AVAILABLE);
+ } else {
+ WARN_ON(!(link->flags & DL_FLAG_SYNC_STATE_ONLY));
+ WRITE_ONCE(link->status, DL_STATE_DORMANT);
+ }
+ }
}
/**
@@ -687,11 +695,11 @@ int device_links_check_suppliers(struct device *dev)
device_links_write_lock();
list_for_each_entry(link, >links.suppliers, c_node) {
- if (!(link->flags & DL_FLAG_MANAGED) ||
- link->flags & DL_FLAG_SYNC_STATE_ONLY)
+ if (!(link->flags & DL_FLAG_MANAGED))
continue;
- if (link->status != DL_STATE_AVAILABLE) {
+ if (link->status != DL_STATE_AVAILABLE &&
+ !(link->flags & DL_FLAG_SYNC_STATE_ONLY)) {
device_links_missing_supplier(dev);
ret = -EPROBE_DEFER;
break;
@@ -952,11 +960,21 @@ static void __device_links_no_driver(struct device *dev)
if (!(link->flags & DL_FLAG_MANAGED))
continue;
- if (link->flags & DL_FLAG_AUTOREMOVE_CONSUMER)
+ if (link->flags & DL_FLAG_AUTOREMOVE_CONSUMER) {
device_link_drop_managed(link);
- else if (link->status == DL_STATE_CONSUMER_PROBE ||
-link->status == DL_STATE_ACTIVE)
+ continue;
+ }
+
+ if (link->status != DL_STATE_CONSUMER_PROBE &&
+ link->status != DL_STATE_ACTIVE)
+ continue;
+
+ if (link->supplier->links.status == DL_DEV_DRIVER_BOUND) {
WRITE_ONCE(link->status, DL_STATE_AVAILABLE);
+ } else {
+ WARN_ON(!(link->flags & DL_FLAG_SYNC_STATE_ONLY));
+ WRITE_ONCE(link->status, DL_STATE_DORMANT);
+ }
}
dev->links.status = DL_DEV_NO_DRIVER;
--
2.27.0.rc0.183.gde8f92d652-goog
Re: [PATCH v6 2/3] dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml
On Wed, 13 May 2020 14:59:01 -0700, Douglas Anderson wrote: > This moves the bindings over, based a lot on toshiba,tc358768.yaml. > Unless there's someone known to be better, I've set the maintainer in > the yaml as the first person to submit bindings. > > Signed-off-by: Douglas Anderson > Reviewed-by: Stephen Boyd > --- > I removed Stephen's review tag on v5 since I squashed in a bunch of > other stuff. > > Changes in v6: None > Changes in v5: > - Squash > https://lore.kernel.org/r/20200506140208.v2.2.I0a2bca02b09c1fcb6b09479b489736d600b3e57f@changeid/ > > Changes in v4: None > Changes in v3: None > Changes in v2: > - specification => specifier. > - power up => power. > - Added back missing suspend-gpios. > - data-lanes and lane-polarities are are the right place now. > - endpoints don't need to be patternProperties. > - Specified more details for data-lanes and lane-polarities. > - Added old example back in, fixing bugs in it. > - Example i2c bus is just called "i2c", not "i2c1" now. > > .../bindings/display/bridge/ti,sn65dsi86.txt | 87 -- > .../bindings/display/bridge/ti,sn65dsi86.yaml | 285 ++ > 2 files changed, 285 insertions(+), 87 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt > create mode 100644 > Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > Reviewed-by: Rob Herring
Re: [PATCH v4 36/36] mm: Align THP mappings for non-DAX
Thinking about this, if the intent is to make THP usable for any
greater than PAGESIZE page size, this routine should probably go back
to taking a size or perhaps order parameter so it could be called to
align addresses accordingly rather than hard code PMD_SIZE.
> On May 15, 2020, at 7:16 AM, Matthew Wilcox wrote:
>
> From: William Kucharski
>
> When we have the opportunity to use transparent huge pages to map a
> file, we want to follow the same rules as DAX.
>
> Signed-off-by: William Kucharski
> [Inline __thp_get_unmapped_area() into thp_get_unmapped_area()]
> Signed-off-by: Matthew Wilcox (Oracle)
> ---
> mm/huge_memory.c | 40 +---
> 1 file changed, 13 insertions(+), 27 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 15a86b06befc..e78686b628ae 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -535,30 +535,30 @@ bool is_transparent_hugepage(struct page *page)
> }
> EXPORT_SYMBOL_GPL(is_transparent_hugepage);
>
> -static unsigned long __thp_get_unmapped_area(struct file *filp,
> - unsigned long addr, unsigned long len,
> - loff_t off, unsigned long flags, unsigned long size)
> +unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr,
> + unsigned long len, unsigned long pgoff, unsigned long flags)
> {
> + loff_t off = (loff_t)pgoff << PAGE_SHIFT;
> loff_t off_end = off + len;
> - loff_t off_align = round_up(off, size);
> + loff_t off_align = round_up(off, PMD_SIZE);
> unsigned long len_pad, ret;
>
> - if (off_end <= off_align || (off_end - off_align) < size)
> - return 0;
> + if (off_end <= off_align || (off_end - off_align) < PMD_SIZE)
> + goto regular;
>
> - len_pad = len + size;
> + len_pad = len + PMD_SIZE;
> if (len_pad < len || (off + len_pad) < off)
> - return 0;
> + goto regular;
>
> ret = current->mm->get_unmapped_area(filp, addr, len_pad,
> off >> PAGE_SHIFT, flags);
>
> /*
> - * The failure might be due to length padding. The caller will retry
> - * without the padding.
> + * The failure might be due to length padding. Retry without
> + * the padding.
>*/
> if (IS_ERR_VALUE(ret))
> - return 0;
> + goto regular;
>
> /*
>* Do not try to align to THP boundary if allocation at the address
> @@ -567,23 +567,9 @@ static unsigned long __thp_get_unmapped_area(struct file
> *filp,
> if (ret == addr)
> return addr;
>
> - ret += (off - ret) & (size - 1);
> + ret += (off - ret) & (PMD_SIZE - 1);
> return ret;
> -}
> -
> -unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr,
> - unsigned long len, unsigned long pgoff, unsigned long flags)
> -{
> - unsigned long ret;
> - loff_t off = (loff_t)pgoff << PAGE_SHIFT;
> -
> - if (!IS_DAX(filp->f_mapping->host) || !IS_ENABLED(CONFIG_FS_DAX_PMD))
> - goto out;
> -
> - ret = __thp_get_unmapped_area(filp, addr, len, off, flags, PMD_SIZE);
> - if (ret)
> - return ret;
> -out:
> +regular:
> return current->mm->get_unmapped_area(filp, addr, len, pgoff, flags);
> }
> EXPORT_SYMBOL_GPL(thp_get_unmapped_area);
> --
> 2.26.2
>
Re: [RFC] perf/core: allow ftrace for functions in kernel/event/core.c
On Tue, 26 May 2020 18:04:37 -0400 Steven Rostedt wrote: > > In the early days there was a lot of issues with recursions, but I added a > lot of recursion protection since then. I'll give this patch a spin and see > if I can make it crash. I also have some patches that make both perf and the trace directory visible by function tracing. I'll see if I can dig them out too. -- Steve
Re: [PATCH net-next 4/4] net: phy: mscc-miim: read poll when high resolution timers are disabled
On 5/26/2020 3:01 PM, Andrew Lunn wrote:
>>> +/* When high resolution timers aren't built-in: we can't use
>>> usleep_range() as
>>> + * we would sleep way too long. Use udelay() instead.
>>> + */
>>> +#define mscc_readl_poll_timeout(addr, val, cond, delay_us, timeout_us)
>>> \
>>> +({ \
>>> + if (!IS_ENABLED(CONFIG_HIGH_RES_TIMERS))\
>>> + readl_poll_timeout_atomic(addr, val, cond, delay_us,\
>>> + timeout_us); \
>>> + readl_poll_timeout(addr, val, cond, delay_us, timeout_us); \
>>> +})
>>> +
>>
>> I would make this a regular function which would not harm the compiler's
>> ability to optimize it, but would give you type checking. With that fixed:
>
> Hi Florian
>
> cond makes that difficult, since it is not a parameter in the usual
> sense, but an expression to evaluate if the polling should terminate.
>
> readl_poll_timeout() and readl_poll_timeout_atomic() themselves are
> #define's, and there are more levels of macros under them.
Oh that's right, thanks for reminding me of this.
--
Florian
Re: [RFC] perf/core: allow ftrace for functions in kernel/event/core.c
On Tue, 26 May 2020 23:54:15 +0200 Peter Zijlstra wrote: > On Tue, May 26, 2020 at 09:46:29PM +, Song Liu wrote: > > > > > > > On May 26, 2020, at 2:39 PM, Peter Zijlstra wrote: > > > > > > On Tue, May 26, 2020 at 02:28:26PM -0700, Song Liu wrote: > > >> It is useful to trace functions in kernel/event/core.c. Allow ftrace for > > >> them by removing $(CC_FLAGS_FTRACE) from Makefile. > > > > > > Did you try using the ftrace event with perf with this on? > > > > I have tried a few things, like > > > > perf stat -e probe:perf_read -I 1000 > > perf record -e probe:__x64_sys_perf_event_open -aR > > > > They all work fine. > > > > Do you have some tricky functions that we should double check? > > I've no idea what probe: does. iirc there's something like > ftrace:function that is like regular function tracing. > > At some point using that made the kernel really sick due to recursion > between ftrace and perf. Quite possibly that's been fixed, dunno. In the early days there was a lot of issues with recursions, but I added a lot of recursion protection since then. I'll give this patch a spin and see if I can make it crash. -- Steve
Re: [PATCH v7 2/2] dt-bindings: usb: qcom,dwc3: Add compatible for SC7180
On Thu, May 21, 2020 at 09:08:19PM +0530, Sandeep Maheswaram wrote: > Add compatible for SC7180 in usb dwc3 bindings. > > Signed-off-by: Sandeep Maheswaram > Reviewed-by: Douglas Anderson > Acked-by: Rob Herring > Reviewed-by: Stephen Boyd > --- > Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 1 + > 1 file changed, 1 insertion(+) Applied, thanks!
Re: [RFC 07/16] KVM: mm: Introduce VM_KVM_PROTECTED
On Mon, May 25, 2020 at 11:40:01PM -0700, John Hubbard wrote: > On 2020-05-22 05:52, Kirill A. Shutemov wrote: > ... > > @@ -2773,6 +2780,7 @@ struct page *follow_page(struct vm_area_struct *vma, > > unsigned long address, > > #define FOLL_LONGTERM 0x1 /* mapping lifetime is indefinite: see > > below */ > > #define FOLL_SPLIT_PMD0x2 /* split huge pmd before returning */ > > #define FOLL_PIN 0x4 /* pages must be released via unpin_user_page */ > > +#define FOLL_KVM 0x8 /* access to VM_KVM_PROTECTED VMAs */ > > I grabbed 0x8 already, for FOLL_FAST_ONLY. :) Let's see who getting upstream first :P (Spoiler: you) -- Kirill A. Shutemov
Re: [PATCH v12 00/18] Enable FSGSBASE instructions
On 5/26/20 4:27 PM, Sasha Levin wrote: On Tue, May 26, 2020 at 08:42:09AM -0400, Don Porter wrote: On 5/22/20 8:45 PM, Thomas Gleixner wrote: let me clarify, that despite your intentions: - there is not a single word in any paper, slide deck, documentation etc. which mentions that loading this module and enabling FSGSBASE behind the kernels back is a fully unpriviledged root hole. - the module lacks a big fat warning emitted to dmesg, that this turns the host kernel into a complete security disaster. - the module fails to set the TAINT_CRAP flag when initialized. This shows a pretty obvious discrepancy between intention and action. I think there is a significant misunderstanding here. This line of research assumes the kernel is already compromised and behaving adversarially toward a more trusted application. Thus, the attack surface under scrutiny in these projects is between the enclave and the rest of the system. Not that we want kernels to be rooted, or make this easier, but exploits happen in practice. The threat model for Graphene, and most SGX papers, is quite explicit: we assume that Intel’s CPU package, the software in the enclave, and possibly Intel’s Attestation Service (IAS) are the only trusted components. Any other software should be assumed compromised, and one can even assume memory is physically tampered or that one has plugged in an adversarial device. It is not a question of the limitations of the kernel, the threat model assumes that the kernel is already rooted. You really have to look beyond just what Graphene guarantees at this point; it does not live on it's own island and it's success isn't measured purely based on how well it handles it's threat model. Yes, the threat model assumes the kernel was rooted, but you don't go off and set the root password to '12345678' on those machines, right? Attackers would be more than happy to run botnets, spam mailers, and host child porn on your servers if you give them the opportunity, let's not do that. I think we are in agreement and have a common interest here. For the community these papers are typically written to, this assumption would be well understood. And thus it is common to see code artifacts that might emulate or even undermine security of untrusted components. Not appropriate for production use, but for the typical audience, this risk would be understood. And, initially, when people started using Graphene, I checked who they were - almost exclusively SGX researchers who would have this context. It has only been recently that the interest has grown to a level that these sorts of warnings need to be revised for a more general audience. But the point that we should revise our readme and warnings for a more general audience is well taken. I'm really worried about the disconnect between how you view the current state of Graphene (and the industry) vs Intel and the various cloud providers. You keep suggesting that its just past the academic research state, while Intel and the big cloud providers are already pushing it to external customers. Every one of those cloud providers has a preview/GA secure enclave offering. I wonder if you are conflating Graphene with SGX? I understand that many cloud vendors are offering SGX in preview/GA, but there are other frameworks to build these offerings on, such as Intel's SGX SDK or Haven. It would be news to me if every major cloud vendor were putting Graphene in production.
Re: [PATCH v7 1/2] dt-bindings: usb: qcom,dwc3: Convert USB DWC3 bindings
On Thu, 21 May 2020 21:08:18 +0530, Sandeep Maheswaram wrote: > Convert USB DWC3 bindings to DT schema format using json-schema. > > Signed-off-by: Sandeep Maheswaram > --- > .../devicetree/bindings/usb/qcom,dwc3.txt | 104 - > .../devicetree/bindings/usb/qcom,dwc3.yaml | 167 > + > 2 files changed, 167 insertions(+), 104 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.txt > create mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.yaml > Applied, thanks!
Re: [PATCH 11/12] mm: add kiocb_wait_page_queue_init() helper
On Tue, May 26, 2020 at 01:51:22PM -0600, Jens Axboe wrote: > Checks if the file supports it, and initializes the values that we need. > Caller passes in 'data' pointer, if any, and the callback function to > be used. > > Signed-off-by: Jens Axboe Acked-by: Johannes Weiner
Re: [PATCH v2] driver core: Update device link status correctly for SYNC_STATE_ONLY links
On Tue, May 26, 2020 at 2:53 PM Michael Walle wrote:
>
> Am 2020-05-26 23:45, schrieb Saravana Kannan:
> > On Tue, May 26, 2020 at 2:13 PM Michael Walle wrote:
> >>
> >> Am 2020-05-26 21:43, schrieb Saravana Kannan:
> >> > When SYNC_STATE_ONLY support was added in commit 05ef983e0d65 ("driver
> >> > core: Add device link support for SYNC_STATE_ONLY flag"),
> >> > SYNC_STATE_ONLY links were treated similar to STATELESS links in terms
> >> > of not blocking consumer probe if the supplier hasn't probed yet.
> >> >
> >> > That caused a SYNC_STATE_ONLY device link's status to not get updated.
> >> > Since SYNC_STATE_ONLY device link is no longer useful once the
> >> > consumer probes, commit 21c27f06587d ("driver core: Fix
> >> > SYNC_STATE_ONLY device link implementation") addresses the status
> >> > update issue by deleting the SYNC_STATE_ONLY device link instead of
> >> > complicating the status update code.
> >> >
> >> > However, there are still some cases where we need to update the status
> >> > of a SYNC_STATE_ONLY device link. This is because a SYNC_STATE_ONLY
> >> > device link can later get converted into a normal MANAGED device link
> >> > when a normal MANAGED device link is created between a supplier and
> >> > consumer that already have a SYNC_STATE_ONLY device link between them.
> >> >
> >> > If a SYNC_STATE_ONLY device link's status isn't maintained correctly
> >> > till it's converted to a normal MANAGED device link, then the normal
> >> > MANAGED device link will end up with a wrong link status. This can
> >> > cause
> >> > a warning stack trace[1] when the consumer device probes successfully.
> >> >
> >> > This commit fixes the SYNC_STATE_ONLY device link status update issue
> >> > where it wouldn't transition correctly from DL_STATE_DORMANT or
> >> > DL_STATE_AVAILABLE to DL_STATE_CONSUMER_PROBE. It also resets the
> >> > status
> >> > back to DL_STATE_DORMANT or DL_STATE_AVAILABLE if the consumer probe
> >> > fails.
> >> >
> >> > [1] - https://lore.kernel.org/lkml/20200522204120.3b3c9ed6@apollo/
> >> > Fixes: 05ef983e0d65 ("driver core: Add device link support for
> >> > SYNC_STATE_ONLY flag")
> >> > Fixes: 21c27f06587d ("driver core: Fix SYNC_STATE_ONLY device link
> >> > implementation")
> >> > Reported-by: Michael Walle
> >> > Signed-off-by: Saravana Kannan
> >> > ---
> >> >
> >> > v1->v2:
> >> > - Added code to "revert" the link status if consumer probe fails
> >> >
> >> > Greg,
> >> >
> >> > I think this is the issue Michael ran into. I'd like him to test the
> >> > fix
> >> > before it's pulled in.
> >> >
> >> > Michael,
> >> >
> >> > If you can test this on the branch you saw the issue in and give a
> >> > Tested-by if it works, that'd be great.
> >>
> >> with v2 I'm triggering the
> >>WARN_ON(!(link->status & DL_FLAG_SYNC_STATE_ONLY));
> >> in __device_links_no_driver().
> >
> > Thanks for the logs! The WARNING is due to a dump typo in this line. I
> > should be checking link->flags, not link->status here. I'll send out a
> > v3, but you can test with this change too.
>
> Ahh, right. With that fix you can add:
>
> Tested-by: Michael Walle
Phew! Finally! Thanks.
-Saravana
Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
Hello Andy,
On Tue, May 26, 2020 at 4:54 PM Andy Shevchenko
wrote:
>
> On Tue, May 26, 2020 at 03:12:48PM -0400, Jim Quinlan wrote:
> > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> > similar to 'dma_pfn_offset' except that the offset chosen depends on the
> > cpu or dma address involved.
> >
> > Signed-off-by: Jim Quinlan
> > ---
> > drivers/of/address.c| 65 +++--
> > drivers/usb/core/message.c | 3 ++
> > drivers/usb/core/usb.c | 3 ++
> > include/linux/device.h | 10 +-
> > include/linux/dma-direct.h | 10 --
> > include/linux/dma-mapping.h | 46 ++
> > kernel/dma/Kconfig | 13
> > 7 files changed, 144 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 96d8cfb14a60..a01afffcde7d 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -918,6 +918,47 @@ void __iomem *of_io_request_and_map(struct device_node
> > *np, int index,
> > }
> > EXPORT_SYMBOL(of_io_request_and_map);
> >
> > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > +static int attach_dma_pfn_offset_map(struct device *dev,
> > + struct device_node *node, int num_ranges)
> > +{
> > + struct of_range_parser parser;
> > + struct of_range range;
> > + size_t r_size = (num_ranges + 1)
> > + * sizeof(struct dma_pfn_offset_region);
> > + struct dma_pfn_offset_region *r;
> > +
>
> > + r = devm_kzalloc(dev, r_size, GFP_KERNEL);
>
> devm_?!
Yes, otherwise if the device gets unbound/bound repeatedly then there
would be a memory leak.
>
>
> Looking at r_size it should be rather kcalloc().
Yep.
>
>
> > + if (!r)
> > + return -ENOMEM;
> > + dev->dma_pfn_offset_map = r;
> > + of_dma_range_parser_init(, node);
> > +
> > + /*
> > + * Record all info for DMA ranges array. We could
> > + * just use the of_range struct, but if we did that it
> > + * would require more calculations for phys_to_dma and
> > + * dma_to_phys conversions.
> > + */
> > + for_each_of_range(, ) {
> > + r->cpu_beg = range.cpu_addr;
> > + r->cpu_end = r->cpu_beg + range.size;
> > + r->dma_beg = range.bus_addr;
> > + r->dma_end = r->dma_beg + range.size;
> > + r->pfn_offset = PFN_DOWN(range.cpu_addr)
> > + - PFN_DOWN(range.bus_addr);
> > + r++;
> > + }
> > + return 0;
> > +}
> > +#else
> > +static int attach_dma_pfn_offset_map(struct device *dev,
> > + struct device_node *node, int num_ranges)
> > +{
> > + return 0;
> > +}
> > +#endif
> > +
> > /**
> > * of_dma_get_range - Get DMA range info
> > * @dev: device pointer; only needed for a corner case.
> > @@ -947,6 +988,8 @@ int of_dma_get_range(struct device *dev, struct
> > device_node *np, u64 *dma_addr,
> > struct of_range_parser parser;
> > struct of_range range;
> > u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
> > + bool dma_multi_pfn_offset = false;
> > + int num_ranges = 0;
> >
> > while (node) {
> > ranges = of_get_property(node, "dma-ranges", );
> > @@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct
> > device_node *np, u64 *dma_addr,
> > pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> >range.bus_addr, range.cpu_addr, range.size);
> >
> > + num_ranges++;
> > if (dma_offset && range.cpu_addr - range.bus_addr !=
> > dma_offset) {
> > - pr_warn("Can't handle multiple dma-ranges with
> > different offsets on node(%pOF)\n", node);
> > - /* Don't error out as we'd break some existing DTs */
> > - continue;
> > + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
> > + pr_warn("Can't handle multiple dma-ranges
> > with different offsets on node(%pOF)\n", node);
> > + pr_warn("Perhaps set
> > DMA_PFN_OFFSET_MAP=y?\n");
> > + /*
> > + * Don't error out as we'd break some existing
> > + * DTs that are using configs w/o
> > + * CONFIG_DMA_PFN_OFFSET_MAP set.
> > + */
> > + continue;
> > + }
> > + dma_multi_pfn_offset = true;
> > }
> > dma_offset = range.cpu_addr - range.bus_addr;
> >
> > @@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct
> > device_node *np, u64 *dma_addr,
> > dma_end = range.bus_addr + range.size;
> > }
> >
> > + if
Re: [RFC 07/16] KVM: mm: Introduce VM_KVM_PROTECTED
On Tue, May 26, 2020 at 09:15:52AM +0300, Mike Rapoport wrote: > On Fri, May 22, 2020 at 03:52:05PM +0300, Kirill A. Shutemov wrote: > > The new VMA flag that indicate a VMA that is not accessible to userspace > > but usable by kernel with GUP if FOLL_KVM is specified. > > > > The FOLL_KVM is only used in the KVM code. The code has to know how to > > deal with such pages. > > > > Signed-off-by: Kirill A. Shutemov > > --- > > include/linux/mm.h | 8 > > mm/gup.c| 20 > > mm/huge_memory.c| 20 > > mm/memory.c | 3 +++ > > mm/mmap.c | 3 +++ > > virt/kvm/async_pf.c | 4 ++-- > > virt/kvm/kvm_main.c | 9 + > > 7 files changed, 53 insertions(+), 14 deletions(-) > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index e1882eec1752..4f7195365cc0 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -329,6 +329,8 @@ extern unsigned int kobjsize(const void *objp); > > # define VM_MAPPED_COPYVM_ARCH_1 /* T if mapped copy of data > > (nommu mmap) */ > > #endif > > > > +#define VM_KVM_PROTECTED 0 > > With all the ideas about removing pages from the direct mapi floating > around I wouldn't limit this to KVM. > > VM_NOT_IN_DIRECT_MAP would describe such areas better, but I realise > it's very far from perfect and nothing better does not comes to mind :) I don't like VM_NOT_IN_DIRECT_MAP. It's not only about direct mapping, but about userspace mapping as well. For the same reason other naming proposals don't fit as well. > > diff --git a/mm/mmap.c b/mm/mmap.c > > index f609e9ec4a25..d56c3f6efc99 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -112,6 +112,9 @@ pgprot_t vm_get_page_prot(unsigned long vm_flags) > > (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) | > > pgprot_val(arch_vm_get_page_prot(vm_flags))); > > > > + if (vm_flags & VM_KVM_PROTECTED) > > + ret = PAGE_NONE; > > Nit: vma_is_kvm_protected()? Which VMA? :P -- Kirill A. Shutemov
Re: [PATCH 04/12] mm: add support for async page locking
On 5/26/20 3:59 PM, Johannes Weiner wrote: > On Tue, May 26, 2020 at 01:51:15PM -0600, Jens Axboe wrote: >> Normally waiting for a page to become unlocked, or locking the page, >> requires waiting for IO to complete. Add support for lock_page_async() >> and wait_on_page_locked_async(), which are callback based instead. This > > wait_on_page_locked_async() is actually in the next patch, requiring > some back and forth to review. I wonder if this and the next patch > could be merged to have the new API and callers introduced together? I'm fine with that, if that is preferable. Don't feel strongly about that at all, just tried to do it as piecemeal as possible to make it easier to review. -- Jens Axboe
Re: [PATCH net-next 4/4] net: phy: mscc-miim: read poll when high resolution timers are disabled
> > +/* When high resolution timers aren't built-in: we can't use
> > usleep_range() as
> > + * we would sleep way too long. Use udelay() instead.
> > + */
> > +#define mscc_readl_poll_timeout(addr, val, cond, delay_us, timeout_us)
> > \
> > +({ \
> > + if (!IS_ENABLED(CONFIG_HIGH_RES_TIMERS))\
> > + readl_poll_timeout_atomic(addr, val, cond, delay_us,\
> > + timeout_us); \
> > + readl_poll_timeout(addr, val, cond, delay_us, timeout_us); \
> > +})
> > +
>
> I would make this a regular function which would not harm the compiler's
> ability to optimize it, but would give you type checking. With that fixed:
Hi Florian
cond makes that difficult, since it is not a parameter in the usual
sense, but an expression to evaluate if the polling should terminate.
readl_poll_timeout() and readl_poll_timeout_atomic() themselves are
#define's, and there are more levels of macros under them.
Andrew
Re: [PATCH 05/12] mm: support async buffered reads in generic_file_buffered_read()
On Tue, May 26, 2020 at 01:51:16PM -0600, Jens Axboe wrote: > Use the async page locking infrastructure, if IOCB_WAITQ is set in the > passed in iocb. The caller must expect an -EIOCBQUEUED return value, > which means that IO is started but not done yet. This is similar to how > O_DIRECT signals the same operation. Once the callback is received by > the caller for IO completion, the caller must retry the operation. > > Signed-off-by: Jens Axboe Acked-by: Johannes Weiner
Re: [PATCH v4] PCI: cadence: Use "dma-ranges" instead of "cdns,no-bar-match-nbits" property
On Thu, May 21, 2020 at 2:02 AM Kishon Vijay Abraham I wrote:
>
> Cadence PCIe core driver (host mode) uses "cdns,no-bar-match-nbits"
> property to configure the number of bits passed through from PCIe
> address to internal address in Inbound Address Translation register.
> This only used the NO MATCH BAR.
>
> However standard PCI dt-binding already defines "dma-ranges" to
> describe the address ranges accessible by PCIe controller. Add support
> in Cadence PCIe host driver to parse dma-ranges and configure the
> inbound regions for BAR0, BAR1 and NO MATCH BAR. Cadence IP specifies
> maximum size for BAR0 as 256GB, maximum size for BAR1 as 2 GB.
>
> This adds support to take the next biggest region in "dma-ranges" and
> find the smallest BAR that each of the regions fit in and if there is
> no BAR big enough to hold the region, split the region to see if it can
> be fitted using multiple BARs.
>
> "dma-ranges" of J721E will be
> dma-ranges = <0x0200 0x0 0x0 0x0 0x0 0x1 0x0>;
> Since there is no BAR which can hold 2^48 size, NO_MATCH_BAR will be
> used here.
>
> Legacy device tree binding compatibility is maintained by retaining
> support for "cdns,no-bar-match-nbits".
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> The previous version of the patch can be found @
> https://lore.kernel.org/linux-arm-kernel/20200508130646.23939-5-kis...@ti.com/
>
> Changes from v3:
> *) The whole logic of how we select a BAR to fit a region from
> dma-ranges has been changed.
> 1) First select the biggest region in "dma-ranges" (after combining
> adjacent regions)
> 2) Try to fit this region in a smallest available BAR whose size is
> greater than the region size
> 3) If no such BAR is available try to find biggest availalbe BAR
> whose size is lesser than the region size and only fit part of the
> region in that BAR.
> 4) Repeat steps 3 and 4, to fit the remaining region size.
> .../controller/cadence/pcie-cadence-host.c| 254 +-
> drivers/pci/controller/cadence/pcie-cadence.h | 28 +-
> 2 files changed, 265 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c
> b/drivers/pci/controller/cadence/pcie-cadence-host.c
> index 6ecebb79057a..cf8b34b71b8f 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
> @@ -11,6 +11,12 @@
>
> #include "pcie-cadence.h"
>
> +static u64 bar_max_size[] = {
> + [RP_BAR0] = _ULL(128 * SZ_2G),
> + [RP_BAR1] = SZ_2G,
> + [RP_NO_BAR] = _BITULL(63),
> +};
> +
> void __iomem *cdns_pci_map_bus(struct pci_bus *bus, unsigned int devfn,
>int where)
> {
> @@ -106,6 +112,226 @@ static int cdns_pcie_host_init_root_port(struct
> cdns_pcie_rc *rc)
> return 0;
> }
>
> +static int cdns_pcie_host_bar_ib_config(struct cdns_pcie_rc *rc,
> + enum cdns_pcie_rp_bar bar,
> + u64 cpu_addr, u64 size,
> + unsigned long flags)
> +{
> + struct cdns_pcie *pcie = >pcie;
> + u32 addr0, addr1, aperture, value;
> +
> + if (!rc->avail_ib_bar[bar])
> + return -EBUSY;
> +
> + rc->avail_ib_bar[bar] = false;
> +
> + aperture = ilog2(size);
> + addr0 = CDNS_PCIE_AT_IB_RP_BAR_ADDR0_NBITS(aperture) |
> + (lower_32_bits(cpu_addr) & GENMASK(31, 8));
> + addr1 = upper_32_bits(cpu_addr);
> + cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_RP_BAR_ADDR0(bar), addr0);
> + cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_RP_BAR_ADDR1(bar), addr1);
> +
> + if (bar == RP_NO_BAR)
> + return 0;
> +
> + value = cdns_pcie_readl(pcie, CDNS_PCIE_LM_RC_BAR_CFG);
Why do you need to read this first? If you do, don't you need to clear
out any fields you're potentially writing?
> + if (size + cpu_addr >= SZ_4G) {
> + if (!(flags & IORESOURCE_PREFETCH))
> + value |= LM_RC_BAR_CFG_CTRL_MEM_64BITS(bar);
> + value |= LM_RC_BAR_CFG_CTRL_PREF_MEM_64BITS(bar);
> + } else {
> + if (!(flags & IORESOURCE_PREFETCH))
> + value |= LM_RC_BAR_CFG_CTRL_MEM_32BITS(bar);
> + value |= LM_RC_BAR_CFG_CTRL_PREF_MEM_32BITS(bar);
> + }
> +
> + value |= LM_RC_BAR_CFG_APERTURE(bar, aperture);
> + cdns_pcie_writel(pcie, CDNS_PCIE_LM_RC_BAR_CFG, value);
> +
> + return 0;
> +}
> +
> +static enum cdns_pcie_rp_bar
> +cdns_pcie_host_find_min_bar(struct cdns_pcie_rc *rc, u64 size)
> +{
> + enum cdns_pcie_rp_bar bar, sel_bar;
> +
> + sel_bar = RP_BAR_UNDEFINED;
> + for (bar = RP_BAR0; bar <= RP_NO_BAR; bar++) {
> + if (!rc->avail_ib_bar[bar])
> + continue;
> +
> + if (size <= bar_max_size[bar]) {
> + if (sel_bar ==
Re: [PATCH 04/12] mm: add support for async page locking
On Tue, May 26, 2020 at 01:51:15PM -0600, Jens Axboe wrote: > Normally waiting for a page to become unlocked, or locking the page, > requires waiting for IO to complete. Add support for lock_page_async() > and wait_on_page_locked_async(), which are callback based instead. This wait_on_page_locked_async() is actually in the next patch, requiring some back and forth to review. I wonder if this and the next patch could be merged to have the new API and callers introduced together? > allows a caller to get notified when a page becomes unlocked, rather > than wait for it. > > We add a new iocb field, ki_waitq, to pass in the necessary data for this > to happen. We can unionize this with ki_cookie, since that is only used > for polled IO. Polled IO can never co-exist with async callbacks, as it is > (by definition) polled completions. struct wait_page_key is made public, > and we define struct wait_page_async as the interface between the caller > and the core. > > Signed-off-by: Jens Axboe Acked-by: Johannes Weiner
Re: [RFC 10/16] KVM: x86: Enabled protected memory extension
On Tue, May 26, 2020 at 09:16:09AM +0300, Mike Rapoport wrote: > On Fri, May 22, 2020 at 03:52:08PM +0300, Kirill A. Shutemov wrote: > > Wire up hypercalls for the feature and define VM_KVM_PROTECTED. > > > > Signed-off-by: Kirill A. Shutemov > > --- > > arch/x86/Kconfig | 1 + > > arch/x86/kvm/cpuid.c | 3 +++ > > arch/x86/kvm/x86.c | 9 + > > include/linux/mm.h | 4 > > 4 files changed, 17 insertions(+) > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index 58dd44a1b92f..420e3947f0c6 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -801,6 +801,7 @@ config KVM_GUEST > > select ARCH_CPUIDLE_HALTPOLL > > select X86_MEM_ENCRYPT_COMMON > > select SWIOTLB > > + select ARCH_USES_HIGH_VMA_FLAGS > > default y > > ---help--- > > This option enables various optimizations for running under the KVM > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > > index 901cd1fdecd9..94cc5e45467e 100644 > > --- a/arch/x86/kvm/cpuid.c > > +++ b/arch/x86/kvm/cpuid.c > > @@ -714,6 +714,9 @@ static inline int __do_cpuid_func(struct > > kvm_cpuid_array *array, u32 function) > > (1 << KVM_FEATURE_POLL_CONTROL) | > > (1 << KVM_FEATURE_PV_SCHED_YIELD); > > > > + if (VM_KVM_PROTECTED) > > + entry->eax |=(1 << KVM_FEATURE_MEM_PROTECTED); > > + > > if (sched_info_on()) > > entry->eax |= (1 << KVM_FEATURE_STEAL_TIME); > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index c17e6eb9ad43..acba0ac07f61 100644 > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -7598,6 +7598,15 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) > > kvm_sched_yield(vcpu->kvm, a0); > > ret = 0; > > break; > > + case KVM_HC_ENABLE_MEM_PROTECTED: > > + ret = kvm_protect_all_memory(vcpu->kvm); > > + break; > > + case KVM_HC_MEM_SHARE: > > + ret = kvm_protect_memory(vcpu->kvm, a0, a1, false); > > + break; > > + case KVM_HC_MEM_UNSHARE: > > + ret = kvm_protect_memory(vcpu->kvm, a0, a1, true); > > + break; > > default: > > ret = -KVM_ENOSYS; > > break; > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 4f7195365cc0..6eb771c14968 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -329,7 +329,11 @@ extern unsigned int kobjsize(const void *objp); > > # define VM_MAPPED_COPYVM_ARCH_1 /* T if mapped copy of data > > (nommu mmap) */ > > #endif > > > > +#if defined(CONFIG_X86_64) && defined(CONFIG_KVM) > > This would be better spelled as ARCH_WANTS_PROTECTED_MEMORY, IMHO. Sure. I though it's good enough for RFC :) > > +#define VM_KVM_PROTECTED VM_HIGH_ARCH_4 > > Maybe this should be VM_HIGH_ARCH_5 so that powerpc could enable this > feature eventually? Okay-okay. -- Kirill A. Shutemov
Re: [PATCH] bitops: use the same mechanism for get_count_order[_long]
On Tue, May 26, 2020 at 10:04:57AM +0300, Andy Shevchenko wrote:
>On Mon, May 25, 2020 at 09:59:58PM +, Wei Yang wrote:
>> These two functions share the same logic.
>
>So, same comment. Please, add test first, make sure it works on current kernel,
>then after your patch applied, and send it as a series, thanks!
>
>P.S. W/o test code looks good, but based on my experience I'm very suspicious
>about "small" changes that may lead to big issues. Hope you understand my
>point.
>
Sure, I see your point.
>> Signed-off-by: Wei Yang
>> ---
>> include/linux/bitops.h | 8 +++-
>> 1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
>> index 5b5609e81a84..80703ef27aee 100644
>> --- a/include/linux/bitops.h
>> +++ b/include/linux/bitops.h
>> @@ -188,12 +188,10 @@ static inline unsigned fls_long(unsigned long l)
>>
>> static inline int get_count_order(unsigned int count)
>> {
>> -int order;
>> +if (count == 0)
>> +return -1;
>>
>> -order = fls(count) - 1;
>> -if (count & (count - 1))
>> -order++;
>> -return order;
>> +return fls(--count);
>> }
>>
>> /**
>> --
>> 2.23.0
>>
>
>--
>With Best Regards,
>Andy Shevchenko
>
--
Wei Yang
Help you, Help me
[PATCH v3 00/12] i2c: designeware: Add Baikal-T1 System I2C support
Jarkko, Wolfram, the merge window is upon us, please review/merge in/whatever
the patchset.
Initially this has been a small patchset which embedded the Baikal-T1
System I2C support into the DW APB I2C driver as is by using a simplest
way. After a short discussion with Andy we decided to implement what he
suggested (introduce regmap-based accessors and create a glue driver) and
even more than that to provide some cleanups of the code. So here is what
this patchset consists of.
First of all we've found out that current implementation of scripts/dtc
didn't support i2c dt nodes with 10bit and slave flags set in the
reg property. You'll see an error if you try to dt_binding_check it.
So the very first patch fixes the problem by adding these flags support
into the check_i2c_bus_reg() method.
Traditionally we converted the plain text-based DT binding to the DT schema
and added Baikal-T1 System I2C device support there. This required to mark
the reg property redundant for Baikal-T1 I2C since its reg-space is
indirectly accessed by means of the System Controller cmd/read/write
registers.
Then as Andy suggested we replaced the Synopsys DW APB I2C common driver
registers IO accessors into the regmap API methods. This doesn't change
the code logic much, though in two places we managed to replace some bulky
peaces of code with a ready-to-use regmap methods.
Additionally before adding the glue layer API we initiated a set of cleanups:
- Define components of the multi-object drivers (like i2c-designware-core.o
and i2c-designware-paltform.o) with using `-y` suffixed makefile
variables instead of `-objs` suffixed one. This is encouraged by
Documentation/kbuild/makefiles.rst text since `-objs` is supposed to be used
to build host programs.
- Make DW I2C slave driver depended on the DW I2C core code instead of the
platform one, which it really is.
- Move Intel Baytrail semaphore feature to the platform if-clause of the
kernel config.
After this we finally can introduce the glue layer API for the DW APB I2C
platform driver. So there are three methods exported from the driver:
i2c_dw_plat_setup(), i2c_dw_plat_clear(), _dw_plat_dev_pm_ops to
setup, cleanup and add PM operations to the glue driven I2C device. Before
setting the platform DW I2C device up the glue probe code is supposed to
create an instance of DW I2C device generic object and pre-initialize
its `struct device` pointer together with optional platform-specific
flags. In addition to that we converted the MSCC Ocelot SoC I2C specific
code into the glue layer seeing it's really too specific and, which is more
important, isn't that complicated so we could unpin it without much of
worrying to break something.
Meanwhile we discovered that MODEL_CHERRYTRAIL and MODEL_MASK actually
were no longer used in the code. MODEL_MSCC flag has been discarded since
the MSCC Ocelot I2C code conversion to the glue driver. So now we can get
rid of all the MODEL-specific flags.
Finally we introduced a glue driver with Baikal-T1 System I2C device
support. The driver probe tries to find a syscon regmap, creates the DW
APB I2C regmap based on it and passes it further to the DW I2C device
descriptor. Then it does normal DW APB I2C platform setup by calling a
generic setup method. Cleanup is straightforward. It's just calling a
generic DW APB I2C clean method.
This patchset is rebased and tested on the mainline Linux kernel 5.6-rc4:
base-commit: 0e698dfa2822 ("Linux 5.7-rc4")
tag: v5.7-rc4
Note new vendor prefix for Baikal-T1 System I2C device will be added in
the framework of the next patchset:
https://lkml.org/lkml/2020/5/6/1047
Changelog v2:
- Fix the SoB tags.
- Use a shorter summary describing the bindings convertion patch.
- Patch "i2c: designware: Detect the FIFO size in the common code" has
been acked by Jarkko and applied by Wolfram to for-next so drop it from
the set.
- Patch "i2c: designware: Discard i2c_dw_read_comp_param() function" has
been acked by Jarkko and applied by Wolfram to for-next so drop it from
the set.
- Make sure that "mscc,ocelot-i2c" compatible node may have up to two
registers space defined in the DT node, while normal DW I2C controller
will have only one registers space.
- Add "mscc,ocelot-i2c" DT schema example to test the previous fix.
- Declare "unevaluatedProperties" property instead of
"additionalProperties" one in the DT schema.
- Due to the previous fix we can now discard the dummy boolean properties
declaration, since the proper type evaluation will be performed by the
generic i2c-controller.yaml schema.
- Refactor the DW I2C APB driver related series to address the Andies
notes.
- Convert DW APB I2C driver to using regmap instead of handwritten
accessors.
- Use `-y` to build multi-object DW APB drivers.
- Fix DW APB I2C slave code dependency. It should depend on
I2C_DESIGNWARE_CORE instead I2C_DESIGNWARE_PLATFORM.
- Move Baytrail semaphore config to the platform if-clause.
- Introduce a glue-layer
RE: [PATCH] compiler/gcc: Raise minimum GCC version for kernel builds to 4.8
> -Original Message- > From: linux-hexagon-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Nick Desaulniers ... > On Tue, May 26, 2020 at 8:30 AM Guenter Roeck wrote: > > > > On Mon, May 11, 2020 at 09:41:37PM +0100, Will Deacon wrote: > > > It is very rare to see versions of GCC prior to 4.8 being used to > > > build the mainline kernel. These old compilers are also known to > > > have codegen issues which can lead to silent miscompilation: > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 > > > > > > Raise the minimum GCC version to 4.8 for building the kernel and > > > remove some tautological Kconfig dependencies as a consequence. > > > > My hexagon compiler is v4.6.1, and I have been unable to find a more > > recent version. Does anyone happen to have a pointer to a hexagon > > toolchain with gcc 4.8 or later ? > > IIUC, hexagon moved to LLVM, though that target still has issues building the > kernel. > https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aopen+is%3Aissue+lab > el%3A%22%5BARCH%5D+hexagon%22 Indeed, we did move to llvm. The build works with the clang_rt-builtins lib. But that issue indicates that it's an unnecessary wart to require that. From what I understand, other arches contribute these builtins content to the kernel build, so we'll do the same. I'll prioritize this update. -Brian
[PATCH v3 03/12] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example
dtc currently doesn't support I2C_OWN_SLAVE_ADDRESS flag set in the
i2c "reg" property. If it is the compiler will print a warning:
Warning (i2c_bus_reg): /example-2/i2c@112/eeprom@64: I2C bus unit address
format error, expected "4064"
Warning (i2c_bus_reg): /example-2/i2c@112/eeprom@64:reg: I2C address must
be less than 10-bits, got "0x4064"
In order to silence dtc up let's discard the flag from the DW I2C DT
binding example for now. Just revert this commit when dtc is fixed.
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Andy Shevchenko
Cc: Mika Westerberg
Cc: linux-m...@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the Rob request to remove
the EEPROM-slave bit setting in the DT binndings example until the dtc
is fixed.
---
Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
index 4bd430b2b41d..101d78e8f19d 100644
--- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
@@ -137,7 +137,7 @@ examples:
eeprom@64 {
compatible = "linux,slave-24c02";
-reg = <0x4064>;
+reg = <0x64>;
};
};
- |
--
2.26.2
[PATCH v3 02/12] dt-bindings: i2c: Convert DW I2C binding to DT schema
Modern device tree bindings are supposed to be created as YAML-files
in accordance with dt-schema. This commit replaces Synopsys DW I2C
legacy bare text bindings with YAML file. As before the bindings file
states that the corresponding dts node is supposed to be compatible
either with generic DW I2C controller or with Microsemi Ocelot SoC I2C
one, to have registers, interrupts and clocks properties. In addition
the node may have clock-frequency, i2c-sda-hold-time-ns,
i2c-scl-falling-time-ns and i2c-sda-falling-time-ns optional properties.
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Andy Shevchenko
Cc: Mika Westerberg
Cc: linux-m...@vger.kernel.org
---
Changelog v2:
- Make sure that "mscc,ocelot-i2c" compatible node may have up to two
registers space defined, while normal DW I2C controller will have only
one registers space.
- Add "mscc,ocelot-i2c" example to test the previous fix.
- Declare "unevaluatedProperties" property instead of
"additionalProperties" one.
- Due to the previous fix we can now discard the dummy boolean properties
definitions, since the proper type evaluation will be performed by the
generic i2c-controller.yaml schema.
Changelog v3:
- Discard $ref from the "-ns" suffixed properties since they've got the
uint32-array type by default applied in the common schema. Set "maxItems: 1"
there instead to make sure the property will have a single value specified.
---
.../bindings/i2c/i2c-designware.txt | 73 -
.../bindings/i2c/snps,designware-i2c.yaml | 154 ++
2 files changed, 154 insertions(+), 73 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-designware.txt
create mode 100644
Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
deleted file mode 100644
index 08be4d3846e5..
--- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-* Synopsys DesignWare I2C
-
-Required properties :
-
- - compatible : should be "snps,designware-i2c"
-or "mscc,ocelot-i2c" with "snps,designware-i2c" for fallback
- - reg : Offset and length of the register set for the device
- - interrupts : where IRQ is the interrupt number.
- - clocks : phandles for the clocks, see the description of clock-names below.
- The phandle for the "ic_clk" clock is required. The phandle for the "pclk"
- clock is optional. If a single clock is specified but no clock-name, it is
- the "ic_clk" clock. If both clocks are listed, the "ic_clk" must be first.
-
-Recommended properties :
-
- - clock-frequency : desired I2C bus clock frequency in Hz.
-
-Optional properties :
-
- - clock-names : Contains the names of the clocks:
-"ic_clk", for the core clock used to generate the external I2C clock.
-"pclk", the interface clock, required for register access.
-
- - reg : for "mscc,ocelot-i2c", a second register set to configure the SDA hold
- time, named ICPU_CFG:TWI_DELAY in the datasheet.
-
- - i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds.
- This option is only supported in hardware blocks version 1.11a or newer and
- on Microsemi SoCs ("mscc,ocelot-i2c" compatible).
-
- - i2c-scl-falling-time-ns : should contain the SCL falling time in
nanoseconds.
- This value which is by default 300ns is used to compute the tLOW period.
-
- - i2c-sda-falling-time-ns : should contain the SDA falling time in
nanoseconds.
- This value which is by default 300ns is used to compute the tHIGH period.
-
-Examples :
-
- i2c@f {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "snps,designware-i2c";
- reg = <0xf 0x1000>;
- interrupts = <11>;
- clock-frequency = <40>;
- };
-
- i2c@112 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "snps,designware-i2c";
- reg = <0x112 0x1000>;
- interrupt-parent = <>;
- interrupts = <12 1>;
- clock-frequency = <40>;
- i2c-sda-hold-time-ns = <300>;
- i2c-sda-falling-time-ns = <300>;
- i2c-scl-falling-time-ns = <300>;
- };
-
- i2c@112 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x2000 0x100>;
- clock-frequency = <40>;
- clocks = <>;
- interrupts = <0>;
-
- eeprom@64 {
- compatible = "linux,slave-24c02";
- reg = <0x4064>;
- };
- };
diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
new file mode
