[PATCH V4 1/2] soc: imx: Add SCU SoC info driver support
Add i.MX SCU SoC info driver to support i.MX8QXP SoC, introduce
driver dependency into Kconfig as CONFIG_IMX_SCU must be
selected to support i.MX SCU SoC driver, also need to use
platform driver model to make sure IMX_SCU driver is probed
before i.MX SCU SoC driver.
With this patch, SoC info can be read from sysfs:
i.mx8qxp-mek# cat /sys/devices/soc0/family
Freescale i.MX
i.mx8qxp-mek# cat /sys/devices/soc0/soc_id
0x2
i.mx8qxp-mek# cat /sys/devices/soc0/machine
Freescale i.MX8QXP MEK
i.mx8qxp-mek# cat /sys/devices/soc0/revision
1.1
Signed-off-by: Anson Huang
---
Changes since V3:
- remove of_device_id table to make it generic for all i.MX8 SoC with
SCU inside, and check
"fsl,imx-scu" node to devide whether to register soc platform driver;
- for soc_id, just return the value reading from SCU firmware instead
of creating string, for
detail name of soc_id, the machine name already contains it;
- fix some error handling of kasprintf.
---
drivers/soc/imx/Kconfig | 9 +++
drivers/soc/imx/Makefile | 1 +
drivers/soc/imx/soc-imx-scu.c | 155 ++
3 files changed, 165 insertions(+)
create mode 100644 drivers/soc/imx/soc-imx-scu.c
diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
index d80f899..cbc1a41 100644
--- a/drivers/soc/imx/Kconfig
+++ b/drivers/soc/imx/Kconfig
@@ -7,4 +7,13 @@ config IMX_GPCV2_PM_DOMAINS
select PM_GENERIC_DOMAINS
default y if SOC_IMX7D
+config IMX_SCU_SOC
+ bool "i.MX System Controller Unit SoC info support"
+ depends on IMX_SCU
+ select SOC_BUS
+ help
+ If you say yes here you get support for the NXP i.MX System
+ Controller Unit SoC info module, it will provide the SoC info
+ like SoC family, ID and revision etc.
+
endmenu
diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
index d6b529e0..ddf343d 100644
--- a/drivers/soc/imx/Makefile
+++ b/drivers/soc/imx/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
obj-$(CONFIG_ARCH_MXC) += soc-imx8.o
+obj-$(CONFIG_IMX_SCU_SOC) += soc-imx-scu.o
diff --git a/drivers/soc/imx/soc-imx-scu.c b/drivers/soc/imx/soc-imx-scu.c
new file mode 100644
index 000..60458ac
--- /dev/null
+++ b/drivers/soc/imx/soc-imx-scu.c
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IMX_SCU_SOC_DRIVER_NAME"imx-scu-soc"
+
+static struct imx_sc_ipc *soc_ipc_handle;
+
+struct imx_sc_msg_misc_get_soc_id {
+ struct imx_sc_rpc_msg hdr;
+ union {
+ struct {
+ u32 control;
+ u16 resource;
+ } send;
+ struct {
+ u32 id;
+ u16 reserved;
+ } resp;
+ } data;
+} __packed;
+
+static u32 imx_scu_soc_id(void)
+{
+ struct imx_sc_msg_misc_get_soc_id msg;
+ struct imx_sc_rpc_msg *hdr =
+ int ret;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_GET_CONTROL;
+ hdr->size = 3;
+
+ msg.data.send.control = IMX_SC_C_ID;
+ msg.data.send.resource = IMX_SC_R_SYSTEM;
+
+ ret = imx_scu_call_rpc(soc_ipc_handle, , true);
+ if (ret) {
+ pr_err("%s: get soc info failed, ret %d\n", __func__, ret);
+ /* return 0 means getting revision failed */
+ return 0;
+ }
+
+ return msg.data.resp.id;
+}
+
+static int imx_scu_soc_probe(struct platform_device *pdev)
+{
+ struct soc_device_attribute *soc_dev_attr;
+ struct soc_device *soc_dev;
+ struct device_node *root;
+ u32 id, val;
+ int ret;
+
+ /* wait i.MX SCU driver ready */
+ ret = imx_scu_get_handle(_ipc_handle);
+ if (ret)
+ return ret;
+
+ soc_dev_attr = devm_kzalloc(>dev, sizeof(*soc_dev_attr),
+ GFP_KERNEL);
+ if (!soc_dev_attr)
+ return -ENOMEM;
+
+ soc_dev_attr->family = "Freescale i.MX";
+
+ root = of_find_node_by_path("/");
+ ret = of_property_read_string(root,
+ "model",
+ _dev_attr->machine);
+ if (ret)
+ return ret;
+
+ id = imx_scu_soc_id();
+
+ /* format soc_id value passed from SCU firmware */
+ val = id & 0x1f;
+ soc_dev_attr->soc_id = val ? kasprintf(GFP_KERNEL, "0x%x", val)
+ : "unknown";
+ if (!soc_dev_attr->soc_id)
+ return -ENOMEM;
+
+ /* format revision value passed from SCU firmware */
+ val = (id >> 5) & 0xf;
+ val = (((val >> 2) + 1) << 4) | (val & 0x3);
+ soc_dev_attr->revision = val ?
[PATCH V4 2/2] arm64: defconfig: Add i.MX SCU SoC info driver
This patch selects CONFIG_IMX_SCU_SOC by default to support i.MX system controller unit SoC info driver. Signed-off-by: Anson Huang --- No changes. --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 8871cf7..d3a4508 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -691,6 +691,7 @@ CONFIG_RPMSG_QCOM_GLINK_RPM=y CONFIG_RPMSG_QCOM_GLINK_SMEM=m CONFIG_RPMSG_QCOM_SMD=y CONFIG_RASPBERRYPI_POWER=y +CONFIG_IMX_SCU_SOC=y CONFIG_QCOM_COMMAND_DB=y CONFIG_QCOM_GENI_SE=y CONFIG_QCOM_GLINK_SSR=m -- 2.7.4
Re: [PATCH v2] kbuild: check uniqueness of module names
On Thu, May 16, 2019 at 10:37 PM Greg KH wrote: > > On Fri, May 17, 2019 at 01:45:11PM +0900, Masahiro Yamada wrote: > > On Fri, May 17, 2019 at 1:29 PM Masahiro Yamada > > wrote: > > > > > > In the recent build test of linux-next, Stephen saw a build error > > > caused by a broken .tmp_versions/*.mod file: > > > > > > https://lkml.org/lkml/2019/5/13/991 > > > > > > drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same > > > basename, and there is a race in generating .tmp_versions/asix.mod > > > > > > Kbuild has not checked this before, and it suddenly shows up with > > > obscure error message when this kind of race occurs. > > > > > > Non-unique module names cause various sort of problems, but it is > > > not trivial to catch them by eyes. > > > > > > Hence, this script. > > > > > > It checks not only real modules, but also built-in modules (i.e. > > > controlled by tristate CONFIG option, but currently compiled with =y). > > > Non-unique names for built-in modules also cause problems because > > > /sys/modules/ would fall over. > > > > > > I tested allmodconfig on the latest kernel, and it detected the > > > following: > > > > > > warning: same basename if the following are built as modules: > > > drivers/regulator/88pm800.ko > > > drivers/mfd/88pm800.ko > > > warning: same basename if the following are built as modules: > > > drivers/gpu/drm/bridge/adv7511/adv7511.ko > > > drivers/media/i2c/adv7511.ko > > > warning: same basename if the following are built as modules: > > > drivers/net/phy/asix.ko > > > drivers/net/usb/asix.ko > > > warning: same basename if the following are built as modules: > > > fs/coda/coda.ko > > > drivers/media/platform/coda/coda.ko > > > warning: same basename if the following are built as modules: > > > drivers/net/phy/realtek.ko > > > drivers/net/dsa/realtek.ko > > > > > > Reported-by: Stephen Rothwell > > > Signed-off-by: Masahiro Yamada > > > Reviewed-by: Kees Cook > > > --- > > > > > > One more question popped up. > > > > External modules are out of scope of the community, > > but it is possible that people create an external module > > that happens to have the same name as an upstream driver. > > That is their bug, nothing we can do about that :) It's actually not a bug. For external modules it works pretty much as intended. See DEPMOD.D(5): the search directive tells what's the preference among the directories for modules with the same name. depmod respects that order and put the right one into your modules.dep. This allows to put external modules in a different dir and also to make backports of modules from recent to ancient kernels. These modules with the same name are usually the same module, with a different version. Of course what we have here and you are fixing is a different story. Reviewed-by: Lucas De Marchi Lucas De Marchi
Re: [PATCH] dax: Fix last_page check in __bdev_dax_supported()
Dan Williams writes: > On Wed, May 15, 2019 at 10:55 PM Vaibhav Jain wrote: >> >> Presently __bdev_dax_supported() checks if first sector of last >> page ( last_page ) on the block device is aligned to page >> boundary. However the code to compute 'last_page' assumes that there >> are 8 sectors/page assuming a 4K page-size. >> >> This assumption breaks on architectures which use a different page >> size specifically PPC64 where page-size == 64K. Hence a warning is >> seen while trying to mount a xfs/ext4 file-system with dax enabled: >> >> $ sudo mount -o dax /dev/pmem0 /mnt/pmem >> XFS (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk >> XFS (pmem0): DAX unsupported by block device. Turning off DAX. >> >> The patch fixes this issue by updating calculation of 'last_var' to >> take into account number-of-sectors/page instead of assuming it to be >> '8'. > > Yes, I noticed this too and fixed it up in a wider change that also > allows device-mapper to validate each component device. Does this > patch work for you? > > https://lore.kernel.org/lkml/155789172402.748145.11853718580748830476.st...@dwillia2-desk3.amr.corp.intel.com/ Thanks Dan, I tested your patch and not seeing the issue anymore. So, please ignore this patch. -- Vaibhav Jain Linux Technology Center, IBM India Pvt. Ltd.
Re: [PATCH v2] kbuild: check uniqueness of module names
On Fri, May 17, 2019 at 01:45:11PM +0900, Masahiro Yamada wrote: > On Fri, May 17, 2019 at 1:29 PM Masahiro Yamada > wrote: > > > > In the recent build test of linux-next, Stephen saw a build error > > caused by a broken .tmp_versions/*.mod file: > > > > https://lkml.org/lkml/2019/5/13/991 > > > > drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same > > basename, and there is a race in generating .tmp_versions/asix.mod > > > > Kbuild has not checked this before, and it suddenly shows up with > > obscure error message when this kind of race occurs. > > > > Non-unique module names cause various sort of problems, but it is > > not trivial to catch them by eyes. > > > > Hence, this script. > > > > It checks not only real modules, but also built-in modules (i.e. > > controlled by tristate CONFIG option, but currently compiled with =y). > > Non-unique names for built-in modules also cause problems because > > /sys/modules/ would fall over. > > > > I tested allmodconfig on the latest kernel, and it detected the > > following: > > > > warning: same basename if the following are built as modules: > > drivers/regulator/88pm800.ko > > drivers/mfd/88pm800.ko > > warning: same basename if the following are built as modules: > > drivers/gpu/drm/bridge/adv7511/adv7511.ko > > drivers/media/i2c/adv7511.ko > > warning: same basename if the following are built as modules: > > drivers/net/phy/asix.ko > > drivers/net/usb/asix.ko > > warning: same basename if the following are built as modules: > > fs/coda/coda.ko > > drivers/media/platform/coda/coda.ko > > warning: same basename if the following are built as modules: > > drivers/net/phy/realtek.ko > > drivers/net/dsa/realtek.ko > > > > Reported-by: Stephen Rothwell > > Signed-off-by: Masahiro Yamada > > Reviewed-by: Kees Cook > > --- > > > One more question popped up. > > External modules are out of scope of the community, > but it is possible that people create an external module > that happens to have the same name as an upstream driver. That is their bug, nothing we can do about that :) thanks, greg k-h
Re: [PATCH v2] kbuild: check uniqueness of module names
Hi Masahiro,
Thanks for this, looks good to me. Just a nit below.
On Fri, 17 May 2019 13:27:53 +0900 Masahiro Yamada
wrote:
>
> diff --git a/scripts/modules-check.sh b/scripts/modules-check.sh
> new file mode 100755
> index ..c875f6eab01e
> --- /dev/null
> +++ b/scripts/modules-check.sh
> @@ -0,0 +1,20 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +
> +set -e
> +
> +# Check uniqueness of module names
> +check_same_name_modules()
> +{
> + same_name_modules=$(cat modules.order modules.builtin | \
^
This trailing '\' is unnecessary after a pipe symbol.
> + xargs -r basename -a -- | sort | uniq -d)
> +
> + for m in $same_name_modules
> + do
> + echo "warning: same basename if the following are built as
> modules:" >&2
> + grep -h -e "/$m" modules.order modules.builtin | \
Same here
> + sed 's:^kernel/: :' >&2
> + done
> +}
> +
> +check_same_name_modules
Reviewed-by: Stephen ROthwell
--
Cheers,
Stephen Rothwell
pgpO_BjA7Nx9n.pgp
Description: OpenPGP digital signature
[PATCH v4] arm64: dts: ls1028a: Add USB dt nodes
This patch adds USB dt nodes for LS1028A.
Signed-off-by: Ran Wang
---
Changes in v4:
- Move nodes to follow rule of unit-address in the address.
- Use macro to replace 'interrupts' values.
Changes in v3:
- Add space between label and node name.
- Add spcae with properties and '='.
- Add SoC specific compatible.
Changes in v2:
- Rename node from usb3@... to usb@... to meet DTSpec
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 8dd3501..e4ed17f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -294,6 +294,26 @@
status = "disabled";
};
+ usb0: usb@310 {
+ compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
+ reg = <0x0 0x310 0x0 0x1>;
+ interrupts = ;
+ dr_mode = "host";
+ snps,dis_rxdet_inp3_quirk;
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
+ };
+
+ usb1: usb@311 {
+ compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
+ reg = <0x0 0x311 0x0 0x1>;
+ interrupts = ;
+ dr_mode = "host";
+ snps,dis_rxdet_inp3_quirk;
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
+ };
+
sata: sata@320 {
compatible = "fsl,ls1028a-ahci";
reg = <0x0 0x320 0x0 0x1>,
--
1.7.1
Re: Linux 4.19 and GCC 9
On Thu, May 16, 2019 at 08:14:25PM -0700, Ivan Babrou wrote: > We are building the upstream kernel. There are a few patches, but > nothing related to objtool. > > Unless you mean mainline/stable by upstream, I haven't tried that. We > stick to LTS. Please work and all of these issues fixed up in Linus's tree and then I will be glad to take the fixed into the stable releases. thanks, greg k-h
[PATCH v2] arm64: dts: ls1028a: Fix CPU idle fail.
PSCI spec define 1st parameter's bit 16 of function CPU_SUSPEND to
indicate CPU State Type: 0 for standby, 1 for power down. In this
case, we want to select standby for CPU idle feature. But current
setting wrongly select power down and cause CPU SUSPEND fail every
time. Need this fix.
Fixes: 8897f3255c9c ("arm64: dts: Add support for NXP LS1028A SoC")
Signed-off-by: Ran Wang
---
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index b045812..bf7f845 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -28,7 +28,7 @@
enable-method = "psci";
clocks = < 1 0>;
next-level-cache = <>;
- cpu-idle-states = <_PH20>;
+ cpu-idle-states = <_PW20>;
};
cpu1: cpu@1 {
@@ -38,7 +38,7 @@
enable-method = "psci";
clocks = < 1 0>;
next-level-cache = <>;
- cpu-idle-states = <_PH20>;
+ cpu-idle-states = <_PW20>;
};
l2: l2-cache {
@@ -53,13 +53,13 @@
*/
entry-method = "arm,psci";
- CPU_PH20: cpu-ph20 {
- compatible = "arm,idle-state";
- idle-state-name = "PH20";
- arm,psci-suspend-param = <0x0001>;
- entry-latency-us = <1000>;
- exit-latency-us = <1000>;
- min-residency-us = <3000>;
+ CPU_PW20: cpu-pw20 {
+ compatible = "arm,idle-state";
+ idle-state-name = "PW20";
+ arm,psci-suspend-param = <0x0>;
+ entry-latency-us = <2000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <6000>;
};
};
--
1.7.1
[PATCH] bsr: "foo * bar" should be "foo *bar"
From: Naveen Kumar Parna
Fixed the checkpatch error. Used "foo *bar" instead of "foo * bar"
Signed-off-by: Naveen Kumar Parna
---
drivers/char/bsr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/bsr.c b/drivers/char/bsr.c
index a6cef548e01e..d16ba62d03a0 100644
--- a/drivers/char/bsr.c
+++ b/drivers/char/bsr.c
@@ -147,7 +147,7 @@ static int bsr_mmap(struct file *filp, struct
vm_area_struct *vma)
return 0;
}
-static int bsr_open(struct inode * inode, struct file * filp)
+static int bsr_open(struct inode *inode, struct file *filp)
{
struct cdev *cdev = inode->i_cdev;
struct bsr_dev *dev = container_of(cdev, struct bsr_dev, bsr_cdev);
--
2.17.1
Re: [PATCH] memcg: make it work on sparse non-0-node systems
On 16. 05. 19, 15:59, Michal Hocko wrote: >> However, I tend to agree with Michal that (ab)using node[0].memcg_lrus >> to check if a list_lru is memcg aware looks confusing. I guess we could >> simply add a bool flag to list_lru instead. Something like this, may be: > > Yes, this makes much more sense to me! I am not sure if I should send a patch with this solution or Vladimir will (given he is an author and has a diff already)? thanks, -- js suse labs
Re: [PATCH] mm, memory-failure: clarify error message
On 05/17/2019 09:38 AM, Jane Chu wrote:
> Some user who install SIGBUS handler that does longjmp out
What the longjmp about ? Are you referring to the mechanism of catching the
signal which was registered ?
> therefore keeping the process alive is confused by the error
> message
> "[188988.765862] Memory failure: 0x1840200: Killing
>cellsrv:33395 due to hardware memory corruption"
Its a valid point because those are two distinct actions.
> Slightly modify the error message to improve clarity.
>
> Signed-off-by: Jane Chu
> ---
> mm/memory-failure.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index fc8b517..14de5e2 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -216,10 +216,9 @@ static int kill_proc(struct to_kill *tk, unsigned long
> pfn, int flags)
> short addr_lsb = tk->size_shift;
> int ret;
>
> - pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory
> corruption\n",
> - pfn, t->comm, t->pid);
> -
> if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) {
> + pr_err("Memory failure: %#lx: Killing %s:%d due to hardware
> memory "
> + "corruption\n", pfn, t->comm, t->pid);
> ret = force_sig_mceerr(BUS_MCEERR_AR, (void __user *)tk->addr,
> addr_lsb, current);
> } else {
> @@ -229,6 +228,8 @@ static int kill_proc(struct to_kill *tk, unsigned long
> pfn, int flags)
>* This could cause a loop when the user sets SIGBUS
>* to SIG_IGN, but hopefully no one will do that?
>*/
> + pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due to
> hardware "
> + "memory corruption\n", pfn, t->comm, t->pid);
> ret = send_sig_mceerr(BUS_MCEERR_AO, (void __user *)tk->addr,
> addr_lsb, t); /* synchronous? */
As both the pr_err() messages are very similar, could not we just switch
between "Killing"
and "Sending SIGBUS to" based on a variable e.g action_[kill|sigbus] evaluated
previously
with ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm).
Re: [PATCH v2] kbuild: check uniqueness of module names
On Fri, May 17, 2019 at 1:29 PM Masahiro Yamada wrote: > > In the recent build test of linux-next, Stephen saw a build error > caused by a broken .tmp_versions/*.mod file: > > https://lkml.org/lkml/2019/5/13/991 > > drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same > basename, and there is a race in generating .tmp_versions/asix.mod > > Kbuild has not checked this before, and it suddenly shows up with > obscure error message when this kind of race occurs. > > Non-unique module names cause various sort of problems, but it is > not trivial to catch them by eyes. > > Hence, this script. > > It checks not only real modules, but also built-in modules (i.e. > controlled by tristate CONFIG option, but currently compiled with =y). > Non-unique names for built-in modules also cause problems because > /sys/modules/ would fall over. > > I tested allmodconfig on the latest kernel, and it detected the > following: > > warning: same basename if the following are built as modules: > drivers/regulator/88pm800.ko > drivers/mfd/88pm800.ko > warning: same basename if the following are built as modules: > drivers/gpu/drm/bridge/adv7511/adv7511.ko > drivers/media/i2c/adv7511.ko > warning: same basename if the following are built as modules: > drivers/net/phy/asix.ko > drivers/net/usb/asix.ko > warning: same basename if the following are built as modules: > fs/coda/coda.ko > drivers/media/platform/coda/coda.ko > warning: same basename if the following are built as modules: > drivers/net/phy/realtek.ko > drivers/net/dsa/realtek.ko > > Reported-by: Stephen Rothwell > Signed-off-by: Masahiro Yamada > Reviewed-by: Kees Cook > --- One more question popped up. External modules are out of scope of the community, but it is possible that people create an external module that happens to have the same name as an upstream driver. drivers/this/is/upstream/subsystem/foo.ko /home/fred/my/own/external/module/foo.ko Is modprobe confused in this case too? Perhaps, checking for the M= build might be good too... -- Best Regards Masahiro Yamada
drivers/soc/Kconfig:23: 'menu' in different file than 'menu'
Hi Patrick, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0d74471924f2a01dcd32d154510c0500780b531a commit: 524feb799408e5d45c6aa82763a9f52489d1e19f soc: add aspeed folder and misc drivers date: 3 weeks ago config: xtensa-allyesconfig compiler: xtensa-linux-gcc (GCC) 8.1.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 524feb799408e5d45c6aa82763a9f52489d1e19f GCC_VERSION=8.1.0 make.cross ARCH=xtensa allyesconfig GCC_VERSION=8.1.0 make.cross ARCH=xtensa If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> drivers/soc/Kconfig:23: 'menu' in different file than 'menu' >> drivers/soc/aspeed/Kconfig:1: location of the 'menu' >> drivers/Kconfig:233: 'menu' in different file than 'menu' >> drivers/soc/aspeed/Kconfig:1: location of the 'menu' :34: syntax error >> drivers/Kconfig:2: missing end statement for this entry make[2]: *** [allyesconfig] Error 1 make[1]: *** [allyesconfig] Error 2 make: *** [sub-make] Error 2 -- >> drivers/soc/Kconfig:23: 'menu' in different file than 'menu' >> drivers/soc/aspeed/Kconfig:1: location of the 'menu' >> drivers/Kconfig:233: 'menu' in different file than 'menu' >> drivers/soc/aspeed/Kconfig:1: location of the 'menu' :34: syntax error >> drivers/Kconfig:2: missing end statement for this entry make[2]: *** [oldconfig] Error 1 make[1]: *** [oldconfig] Error 2 make: *** [sub-make] Error 2 -- >> drivers/soc/Kconfig:23: 'menu' in different file than 'menu' >> drivers/soc/aspeed/Kconfig:1: location of the 'menu' >> drivers/Kconfig:233: 'menu' in different file than 'menu' >> drivers/soc/aspeed/Kconfig:1: location of the 'menu' :34: syntax error >> drivers/Kconfig:2: missing end statement for this entry make[2]: *** [olddefconfig] Error 1 make[1]: *** [olddefconfig] Error 2 make: *** [sub-make] Error 2 vim +23 drivers/soc/Kconfig 5d144e36 Andy Gross2014-04-24 22 3a6e0821 Santosh Shilimkar 2014-04-23 @23 endmenu :: The code at line 23 was first introduced by commit :: 3a6e08218f36baa9c49282ad2fe0dfbf001d8f23 soc: Introduce drivers/soc place-holder for SOC specific drivers :: TO: Santosh Shilimkar :: CC: Kumar Gala --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[PATCH] char: misc: Move EXPORT_SYMBOL immediately next to the functions/varibles
From: Naveen Kumar Parna According to checkpatch: EXPORT_SYMBOL(foo); should immediately follow its function/variable. This patch fixes the following checkpatch.pl issues in drivers/char/misc.c: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable Signed-off-by: Naveen Kumar Parna --- drivers/char/misc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/char/misc.c b/drivers/char/misc.c index 53cfe574d8d4..f6a147427029 100644 --- a/drivers/char/misc.c +++ b/drivers/char/misc.c @@ -226,6 +226,7 @@ int misc_register(struct miscdevice *misc) mutex_unlock(_mtx); return err; } +EXPORT_SYMBOL(misc_register); /** * misc_deregister - unregister a miscellaneous device @@ -249,8 +250,6 @@ void misc_deregister(struct miscdevice *misc) clear_bit(i, misc_minors); mutex_unlock(_mtx); } - -EXPORT_SYMBOL(misc_register); EXPORT_SYMBOL(misc_deregister); static char *misc_devnode(struct device *dev, umode_t *mode) -- 2.17.1
Re: [PATCH] sched: introduce configurable delay before entering idle
On 2019-05-15 1:43 p.m., Marcelo Tosatti wrote: On Wed, May 15, 2019 at 11:42:56AM -0700, Ankur Arora wrote: On 5/14/19 6:50 AM, Marcelo Tosatti wrote: On Mon, May 13, 2019 at 05:20:37PM +0800, Wanpeng Li wrote: On Wed, 8 May 2019 at 02:57, Marcelo Tosatti wrote: Certain workloads perform poorly on KVM compared to baremetal due to baremetal's ability to perform mwait on NEED_RESCHED bit of task flags (therefore skipping the IPI). KVM supports expose mwait to the guest, if it can solve this? Regards, Wanpeng Li Unfortunately mwait in guest is not feasible (uncompatible with multiple guests). Checking whether a paravirt solution is possible. Hi Ankur, Hi Marcelo, I was also looking at making MWAIT available to guests in a safe manner: whether through emulation or a PV-MWAIT. My (unsolicited) thoughts What use-case are you interested in? Currently Oracle does not make MWAIT available to guests in cloud environments. My interest is 1) allow guests to avoid the IPI and 2) allow the waiting to be in deeper C-states so that other cores could get the benefit of turbo-boost etc. We basically want to handle this sequence: monitor(monitor_address); if (*monitor_address == base_value) mwaitx(max_delay); Emulation seems problematic because, AFAICS this would happen: guest hypervisor = monitor(monitor_address); vmexit ===>monitor(monitor_address) if (*monitor_address == base_value) mwait(); vmexit> mwait() There's a context switch back to the guest in this sequence which seems problematic. Both the AMD and Intel specs list system calls and far calls as events which would lead to the MWAIT being woken up: "Voluntary transitions due to fast system call and far calls (occurring prior to issuing MWAIT but after setting the monitor)". We could do this instead: guest hypervisor = monitor(monitor_address); vmexit ===>cache monitor_address if (*monitor_address == base_value) mwait(); vmexit> monitor(monitor_address) mwait() But, this would miss the "if (*monitor_address == base_value)" check in the host which is problematic if *monitor_address changed simultaneously when monitor was executed. (Similar problem if we cache both the monitor_address and *monitor_address.) So, AFAICS, the only thing that would work is the guest offloading the whole PV-MWAIT operation. AFAICS, that could be a paravirt operation which needs three parameters: (monitor_address, base_value, max_delay.) This would allow the guest to offload this whole operation to the host: monitor(monitor_address); if (*monitor_address == base_value) mwaitx(max_delay); I'm guessing you are thinking on similar lines? Sort of: only trying to avoid the IPI to wake a remote vCPU. Problem is that MWAIT works only on a contiguous range of bits in memory (512 bits max on current CPUs). So if you execute mwait on the host on behalf of the guest, the region of memory monitored must include both host and guest bits. Yeah, an MWAITv would have come pretty handy here ;). My idea of PV-MWAIT didn't include waiting on behalf of the host. I was thinking of waiting in the host but exclusively on behalf of the guest, until the guest is woken up or when it's time-quanta expires. Waiting on behalf of both the guest and the host would clearly be better. If we can do mwait for both the guest and host (say they share a 512 bit region), then the host will need some protection from the guest. Maybe the waking guest-thread could just do a hypercall to wake up the remote vCPU? Or maybe it could poke the monitored region, but that is handled as a special page-fault? The hypercall-to-wake would also allow us to move guest-threads across CPUs. That said, I'm not sure how expensive either of these would be. Assuming host/guest can share a monitored region safely, the host's idle could monitor some region other than its _info->flags. Maybe we could setup a mwait notifier with a percpu waiting area which could be registered by idle, guests etc. Though on second thoughts, if the remote thread will do a hypercall/page-fault then the handling could just as easily be: mark the guest's remote thread runnable and set the resched bit. High level semantics: If the CPU doesn't have any runnable threads, then we actually do this version of PV-MWAIT -- arming a timer if necessary so we only sleep until the time-slice expires or the MWAIT max_delay does. That would kill the sched_wake_idle_without_ipi optimization for the host. Yeah, I was thinking in terms of the MWAIT being exclusively on behalf of the guest so in a
[PATCH v2] kbuild: check uniqueness of module names
In the recent build test of linux-next, Stephen saw a build error
caused by a broken .tmp_versions/*.mod file:
https://lkml.org/lkml/2019/5/13/991
drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same
basename, and there is a race in generating .tmp_versions/asix.mod
Kbuild has not checked this before, and it suddenly shows up with
obscure error message when this kind of race occurs.
Non-unique module names cause various sort of problems, but it is
not trivial to catch them by eyes.
Hence, this script.
It checks not only real modules, but also built-in modules (i.e.
controlled by tristate CONFIG option, but currently compiled with =y).
Non-unique names for built-in modules also cause problems because
/sys/modules/ would fall over.
I tested allmodconfig on the latest kernel, and it detected the
following:
warning: same basename if the following are built as modules:
drivers/regulator/88pm800.ko
drivers/mfd/88pm800.ko
warning: same basename if the following are built as modules:
drivers/gpu/drm/bridge/adv7511/adv7511.ko
drivers/media/i2c/adv7511.ko
warning: same basename if the following are built as modules:
drivers/net/phy/asix.ko
drivers/net/usb/asix.ko
warning: same basename if the following are built as modules:
fs/coda/coda.ko
drivers/media/platform/coda/coda.ko
warning: same basename if the following are built as modules:
drivers/net/phy/realtek.ko
drivers/net/dsa/realtek.ko
Reported-by: Stephen Rothwell
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
---
Changes in v2:
- redirect messages to stderr
- use '--' after 'basename -a'
- use '-r' for xargs to cope with empty modules.order/modules.builtin
Makefile | 1 +
scripts/modules-check.sh | 20
2 files changed, 21 insertions(+)
create mode 100755 scripts/modules-check.sh
diff --git a/Makefile b/Makefile
index a61a95b6b38f..30792fec7a12 100644
--- a/Makefile
+++ b/Makefile
@@ -1290,6 +1290,7 @@ modules: $(vmlinux-dirs) $(if $(KBUILD_BUILTIN),vmlinux)
modules.builtin
$(Q)$(AWK) '!x[$$0]++' $(vmlinux-dirs:%=$(objtree)/%/modules.order) >
$(objtree)/modules.order
@$(kecho) ' Building modules, stage 2.';
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
+ $(Q)$(CONFIG_SHELL) $(srctree)/scripts/modules-check.sh
modules.builtin: $(vmlinux-dirs:%=%/modules.builtin)
$(Q)$(AWK) '!x[$$0]++' $^ > $(objtree)/modules.builtin
diff --git a/scripts/modules-check.sh b/scripts/modules-check.sh
new file mode 100755
index ..c875f6eab01e
--- /dev/null
+++ b/scripts/modules-check.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+
+set -e
+
+# Check uniqueness of module names
+check_same_name_modules()
+{
+ same_name_modules=$(cat modules.order modules.builtin | \
+ xargs -r basename -a -- | sort | uniq -d)
+
+ for m in $same_name_modules
+ do
+ echo "warning: same basename if the following are built as
modules:" >&2
+ grep -h -e "/$m" modules.order modules.builtin | \
+ sed 's:^kernel/: :' >&2
+ done
+}
+
+check_same_name_modules
--
2.17.1
Re: [PATCH v2 05/18] Documentation: fpga: dfl: add descriptions for virtualization and new interfaces.
On Thu, May 16, 2019 at 12:53:00PM -0500, Alan Tull wrote: > On Thu, May 16, 2019 at 12:36 PM Alan Tull wrote: > > > > On Mon, Apr 29, 2019 at 4:12 AM Wu Hao wrote: > > Hi Hao, > > Most of this patchset looks ready to go upstream or nearly so with > pretty straightforward changes . Patches 17 and 18 need minor changes > and please change the scnprintf in the other patches. The patches > that had nontrivial changes are the power and thermal ones involving > hwmon. I'm hoping to send up the patchset minus the hwmon patches in > the next version if there's no unforseen issues. If the hwmon patches > are ready then also, that's great, but otherwise those patches don't > need to hold up all the rest of the patchset. How's that sound? Hi Alan Thanks for your time for reviewing this patchset. This sounds good to me. Only thing here is, I need to split the patch which updates documentation into 2 patches (to remove hwmon description in doc), but for sure, it should be very easy. :) Thanks Hao > > Alan > > > > > > > This patch adds virtualization support description for DFL based > > > FPGA devices (based on PCIe SRIOV), and introductions to new > > > interfaces added by new dfl private feature drivers. > > > > > > Signed-off-by: Xu Yilun > > > Signed-off-by: Wu Hao > > > > Acked-by: Alan Tull > > > > Thanks, > > Alan
Re: [RESEND PATCH v3 04/11] s390/cpacf: mark scpacf_query() as __always_inline
On Fri, May 17, 2019 at 8:01 AM Laura Abbott wrote: > > On 4/22/19 8:49 PM, Masahiro Yamada wrote: > > This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common > > place. We need to eliminate potential issues beforehand. > > > > If it is enabled for s390, the following error is reported: > > > > In file included from arch/s390/crypto/des_s390.c:19: > > ./arch/s390/include/asm/cpacf.h: In function 'cpacf_query': > > ./arch/s390/include/asm/cpacf.h:170:2: warning: asm operand 3 probably > > doesn't match constraints > >asm volatile( > >^~~ > > ./arch/s390/include/asm/cpacf.h:170:2: error: impossible constraint in 'asm' > > > > This also seems to still be broken, again with gcc 9.1.1 > > BUILDSTDERR: In file included from arch/s390/crypto/prng.c:29: > BUILDSTDERR: ./arch/s390/include/asm/cpacf.h: In function 'cpacf_query_func': > BUILDSTDERR: ./arch/s390/include/asm/cpacf.h:170:2: warning: asm operand 3 > probably doesn't match constraints > BUILDSTDERR: 170 | asm volatile( > BUILDSTDERR: | ^~~ > BUILDSTDERR: ./arch/s390/include/asm/cpacf.h:170:2: error: impossible > constraint in 'asm' > > I realized we're still carrying a patch to add -fno-section-anchors > but it's a similar failure to powerpc. Christophe had already pointed out potential issues for "i" constraint, and I have fixups in hand: See https://lkml.org/lkml/2019/5/3/459 My plan was to send it after all of my base patches were merged. This s390 cparf.h is included in the TODO list. Will fix soon. Thanks. -- Best Regards Masahiro Yamada
linux-next: Tree for May 17
Hi all, Please do not add any v5.3 material to your linux-next included trees/branches until after v5.2-rc1 has been released. Changes since 20190516: The kvm tree gained conflicts against Linus' tree. Non-merge commits (relative to Linus' tree): 1023 1119 files changed, 27058 insertions(+), 7629 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 298 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (01be377c6221 Merge tag 'media/v5.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media) Merging fixes/master (2bbacd1a9278 Merge tag 'kconfig-v5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kspp-gustavo/for-next/kspp (ccaa75187a5f memstick: mark expected switch fall-throughs) Merging kbuild-current/fixes (a2d635decbfa Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm) Merging arc-current/for-curr (308a06dc72c0 ARC: mm: do_page_fault refactor #8: release mmap_sem sooner) Merging arm-current/fixes (e17b1af96b2a ARM: 8857/1: efi: enable CP15 DMB instructions before cleaning the cache) Merging arm64-fixes/for-next/fixes (7a0a93c51799 arm64: vdso: Explicitly add build-id option) Merging m68k-current/for-linus (fdd20ec8786a Documentation/features/time: Mark m68k having modern-timekeeping) Merging powerpc-fixes/fixes (12f363511d47 powerpc/32s: Fix BATs setting with CONFIG_STRICT_KERNEL_RWX) Merging sparc/master (63863ee8e2f6 Merge tag 'gcc-plugins-v5.2-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/kees/linux) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (510e2ceda031 ipv6: fix src addr routing with the exception table) Merging bpf/master (d72386fe7a84 libbpf: move logging helpers into libbpf_internal.h) Merging ipsec/master (9b3040a6aafd ipv4: Define __ipv4_neigh_lookup_noref when CONFIG_INET is disabled) Merging netfilter/master (d4c26eb6e721 net: ethernet: stmmac: dwmac-sun8i: enable support of unicast filtering) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (7a0f8ad5ff63 Merge ath-current from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git) Merging mac80211/master (933b40530b4b mac80211: remove set but not used variable 'old') Merging rdma-fixes/for-rc (2557fabd6e29 RDMA/hns: Bugfix for mapping user db) Merging sound-current/for-linus (56df90b631fc ALSA: hda/realtek - Fix for Lenovo B50-70 inverted internal microphone bug) Merging sound-asoc-fixes/for-linus (81566b4cbc5d Merge branch 'asoc-5.1' into asoc-linus) Merging regmap-fixes/for-linus (1d6106cafb37 Merge branch 'regmap-5.1' into regmap-linus) Merging regulator-fixes/for-linus (0d183fc1760f Merge branch 'regulator-5.1' into regulator-linus) Merging spi-fixes/for-linus (72e3b3285a43 Merge branch 'spi-5.1' into spi-linus) Merging pci-current/for-linus (9c9c5fc89b09 PCI/LINK: Add Kconfig option (default off)) Merging driver-core.current/driver-core-linus (83f3ef3de625 Merge tag 'libnvdimm-fixes-5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm) Merging tty.current/tty-linus (83f3ef3de625 Merge tag 'libnvdimm-fixes-5.2-rc1' of git://gi
Re: [RESEND PATCH v3 10/11] powerpc/mm/radix: mark as __tlbie_pid() and friends as__always_inline
Hi Laura,
On Fri, May 17, 2019 at 7:55 AM Laura Abbott wrote:
> What gcc version was this tested with?
I use kernel.org toolchains
https://mirrors.edge.kernel.org/pub/tools/crosstool/
It is GCC 8.1
> We're still seeing errors on
> Fedora rawhide with gcc 9.1.1 on a version
> (8c05f3b965da14e7790711026b32cc10a4c06213)
> that should have this fix in it:
>
> BUILDSTDERR: arch/powerpc/mm/book3s64/radix_tlb.c: In function '_tlbiel_pid':
> BUILDSTDERR: arch/powerpc/mm/book3s64/radix_tlb.c:104:2: warning: asm operand
> 3 probably doesn't match constraints
> BUILDSTDERR: 104 | asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
> BUILDSTDERR: | ^~~
> BUILDSTDERR: arch/powerpc/mm/book3s64/radix_tlb.c:104:2: error: impossible
> constraint in 'asm'
> BUILDSTDERR: make[3]: *** [scripts/Makefile.build:279:
> arch/powerpc/mm/book3s64/radix_tlb.o] Error 1
> BUILDSTDERR: make[2]: *** [scripts/Makefile.build:489:
> arch/powerpc/mm/book3s64] Error 2
> BUILDSTDERR: make[1]: *** [scripts/Makefile.build:489: arch/powerpc/mm] Error
> 2
Thanks for the report.
Does this work for you?
diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c
b/arch/powerpc/mm/book3s64/radix_tlb.c
index 4d841369399f..9a6befdd5e74 100644
--- a/arch/powerpc/mm/book3s64/radix_tlb.c
+++ b/arch/powerpc/mm/book3s64/radix_tlb.c
@@ -239,7 +239,7 @@ static inline void fixup_tlbie_lpid(unsigned long lpid)
/*
* We use 128 set in radix mode and 256 set in hpt mode.
*/
-static inline void _tlbiel_pid(unsigned long pid, unsigned long ric)
+static __always_inline void _tlbiel_pid(unsigned long pid, unsigned long ric)
{
int set;
--
Best Regards
Masahiro Yamada
[PATCH] mm, memory-failure: clarify error message
Some user who install SIGBUS handler that does longjmp out
therefore keeping the process alive is confused by the error
message
"[188988.765862] Memory failure: 0x1840200: Killing
cellsrv:33395 due to hardware memory corruption"
Slightly modify the error message to improve clarity.
Signed-off-by: Jane Chu
---
mm/memory-failure.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index fc8b517..14de5e2 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -216,10 +216,9 @@ static int kill_proc(struct to_kill *tk, unsigned long
pfn, int flags)
short addr_lsb = tk->size_shift;
int ret;
- pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory
corruption\n",
- pfn, t->comm, t->pid);
-
if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) {
+ pr_err("Memory failure: %#lx: Killing %s:%d due to hardware
memory "
+ "corruption\n", pfn, t->comm, t->pid);
ret = force_sig_mceerr(BUS_MCEERR_AR, (void __user *)tk->addr,
addr_lsb, current);
} else {
@@ -229,6 +228,8 @@ static int kill_proc(struct to_kill *tk, unsigned long pfn,
int flags)
* This could cause a loop when the user sets SIGBUS
* to SIG_IGN, but hopefully no one will do that?
*/
+ pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due to
hardware "
+ "memory corruption\n", pfn, t->comm, t->pid);
ret = send_sig_mceerr(BUS_MCEERR_AO, (void __user *)tk->addr,
addr_lsb, t); /* synchronous? */
}
--
1.8.3.1
Re: [PATCH v2 04/18] fpga: dfl: fme: support 512bit data width PR
On Thu, May 16, 2019 at 12:35:27PM -0500, Alan Tull wrote:
> On Mon, Apr 29, 2019 at 4:12 AM Wu Hao wrote:
>
> It looks like this addressed the review comments. Adding my Ack. Is
> there anything else on this patch?
Nothing else, just addressed the review comments. : )
Thanks for the review and ack.
Hao
>
> Alan
>
> >
> > In early partial reconfiguration private feature, it only
> > supports 32bit data width when writing data to hardware for
> > PR. 512bit data width PR support is an important optimization
> > for some specific solutions (e.g. XEON with FPGA integrated),
> > it allows driver to use AVX512 instruction to improve the
> > performance of partial reconfiguration. e.g. programming one
> > 100MB bitstream image via this 512bit data width PR hardware
> > only takes ~300ms, but 32bit revision requires ~3s per test
> > result.
> >
> > Please note now this optimization is only done on revision 2
> > of this PR private feature which is only used in integrated
> > solution that AVX512 is always supported. This revision 2
> > hardware doesn't support 32bit PR.
> >
> > Signed-off-by: Ananda Ravuri
> > Signed-off-by: Xu Yilun
> > Signed-off-by: Wu Hao
>
> Acked-by: Alan Tull
>
>
> > ---
> > v2: check AVX512 support using cpu_feature_enabled()
> > fix other comments from Scott Wood
> > ---
> > drivers/fpga/dfl-fme-main.c | 3 ++
> > drivers/fpga/dfl-fme-mgr.c | 113
> > +---
> > drivers/fpga/dfl-fme-pr.c | 43 +++--
> > drivers/fpga/dfl-fme.h | 2 +
> > drivers/fpga/dfl.h | 5 ++
> > 5 files changed, 135 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> > index 086ad24..076d74f 100644
> > --- a/drivers/fpga/dfl-fme-main.c
> > +++ b/drivers/fpga/dfl-fme-main.c
> > @@ -21,6 +21,8 @@
> > #include "dfl.h"
> > #include "dfl-fme.h"
> >
> > +#define DRV_VERSION"0.8"
> > +
> > static ssize_t ports_num_show(struct device *dev,
> > struct device_attribute *attr, char *buf)
> > {
> > @@ -277,3 +279,4 @@ static int fme_remove(struct platform_device *pdev)
> > MODULE_AUTHOR("Intel Corporation");
> > MODULE_LICENSE("GPL v2");
> > MODULE_ALIAS("platform:dfl-fme");
> > +MODULE_VERSION(DRV_VERSION);
> > diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c
> > index b3f7eee..d1a4ba5 100644
> > --- a/drivers/fpga/dfl-fme-mgr.c
> > +++ b/drivers/fpga/dfl-fme-mgr.c
> > @@ -22,14 +22,18 @@
> > #include
> > #include
> >
> > +#include "dfl.h"
> > #include "dfl-fme-pr.h"
> >
> > +#define DRV_VERSION"0.8"
> > +
> > /* FME Partial Reconfiguration Sub Feature Register Set */
> > #define FME_PR_DFH 0x0
> > #define FME_PR_CTRL0x8
> > #define FME_PR_STS 0x10
> > #define FME_PR_DATA0x18
> > #define FME_PR_ERR 0x20
> > +#define FME_PR_512_DATA0x40 /* Data Register for 512bit
> > datawidth PR */
> > #define FME_PR_INTFC_ID_L 0xA8
> > #define FME_PR_INTFC_ID_H 0xB0
> >
> > @@ -67,8 +71,43 @@
> > #define PR_WAIT_TIMEOUT 800
> > #define PR_HOST_STATUS_IDLE0
> >
> > +#if defined(CONFIG_X86) && defined(CONFIG_AS_AVX512)
> > +
> > +#include
> > +#include
> > +
> > +static inline int is_cpu_avx512_enabled(void)
> > +{
> > + return cpu_feature_enabled(X86_FEATURE_AVX512F);
> > +}
> > +
> > +static inline void copy512(const void *src, void __iomem *dst)
> > +{
> > + kernel_fpu_begin();
> > +
> > + asm volatile("vmovdqu64 (%0), %%zmm0;"
> > +"vmovntdq %%zmm0, (%1);"
> > +:
> > +: "r"(src), "r"(dst)
> > +: "memory");
> > +
> > + kernel_fpu_end();
> > +}
> > +#else
> > +static inline int is_cpu_avx512_enabled(void)
> > +{
> > + return 0;
> > +}
> > +
> > +static inline void copy512(const void *src, void __iomem *dst)
> > +{
> > + WARN_ON_ONCE(1);
> > +}
> > +#endif
> > +
> > struct fme_mgr_priv {
> > void __iomem *ioaddr;
> > + unsigned int pr_datawidth;
> > u64 pr_error;
> > };
> >
> > @@ -169,7 +208,7 @@ static int fme_mgr_write(struct fpga_manager *mgr,
> > struct fme_mgr_priv *priv = mgr->priv;
> > void __iomem *fme_pr = priv->ioaddr;
> > u64 pr_ctrl, pr_status, pr_data;
> > - int delay = 0, pr_credit, i = 0;
> > + int ret = 0, delay = 0, pr_credit;
> >
> > dev_dbg(dev, "start request\n");
> >
> > @@ -181,9 +220,9 @@ static int fme_mgr_write(struct fpga_manager *mgr,
> >
> > /*
> > * driver can push data to PR hardware using PR_DATA register once
> > HW
> > -* has enough pr_credit (> 1), pr_credit reduces one for every 32bit
> > -* pr data write to PR_DATA register. If pr_credit <= 1, driver
> > needs
> > -* to wait for enough pr_credit from hardware by polling.
> > +* has enough
[PATCH v2 2/2] arm64: dts: rockchip: Enable SPI1 on Ficus
Enable SPI1 exposed on both Low and High speed expansion connectors
of Ficus. SPI1 has 3 different chip selects wired as below:
CS0 - Serial Flash (unpopulated)
CS1 - Low Speed expansion
CS2 - High Speed expansion
Signed-off-by: Manivannan Sadhasivam
---
Changes in v2:
* Used pin constants instead of hardcoding cs-gpios
arch/arm64/boot/dts/rockchip/rk3399-ficus.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
index 027d428917b8..9af02d859dcd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
@@ -146,6 +146,12 @@
};
};
+ {
+ /* On both Low speed and High speed expansion */
+ cs-gpios = <0>, < RK_PA6 0>, < RK_PA7 0>;
+ status = "okay";
+};
+
_dwc3_0 {
dr_mode = "host";
};
--
2.17.1
[PATCH v2 1/2] arm64: dts: rockchip: Enable SPI0 and SPI4 on Rock960
Enable SPI0 and SPI4 exposed on the Low and High speed expansion
connectors of Rock960.
Signed-off-by: Manivannan Sadhasivam
---
Changes in v2:
* Dropped the label property since it is not part of SPI binding
arch/arm64/boot/dts/rockchip/rk3399-rock960.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
index 12285c51cceb..c624b4e73129 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
@@ -114,6 +114,16 @@
};
};
+ {
+ /* On Low speed expansion (LS-SPI0) */
+ status = "okay";
+};
+
+ {
+ /* On High speed expansion (HS-SPI1) */
+ status = "okay";
+};
+
_dwc3_0 {
dr_mode = "otg";
};
--
2.17.1
Re: [PATCH v2 18/18] fpga: dfl: fme: add performance reporting support
On Thu, May 16, 2019 at 12:28:08PM -0500, Alan Tull wrote: > On Mon, Apr 29, 2019 at 4:13 AM Wu Hao wrote: > > Hi Hao, > > > > > This patch adds support for performance reporting private feature > > for FPGA Management Engine (FME). Actually it supports 4 categories > > performance counters, 'clock', 'cache', 'iommu' and 'fabric', user > > could read the performance counter via exposed sysfs interfaces. > > Please refer to sysfs doc for more details. > > > > Signed-off-by: Luwei Kang > > Signed-off-by: Xu Yilun > > Signed-off-by: Wu Hao > > --- > > v2: improve sysfs doc > > --- > > Documentation/ABI/testing/sysfs-platform-dfl-fme | 93 +++ > > drivers/fpga/Makefile| 1 + > > drivers/fpga/dfl-fme-main.c | 4 + > > drivers/fpga/dfl-fme-perf.c | 950 > > +++ > > drivers/fpga/dfl-fme.h | 2 + > > drivers/fpga/dfl.c | 1 + > > drivers/fpga/dfl.h | 2 + > > 7 files changed, 1053 insertions(+) > > create mode 100644 drivers/fpga/dfl-fme-perf.c > > > > diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme > > b/Documentation/ABI/testing/sysfs-platform-dfl-fme > > index 503984b..a7f7eb6 100644 > > --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme > > +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme > > @@ -250,3 +250,96 @@ Description: Write-only. Write error code to > > this file to clear all errors > > logged in errors, first_error and next_error. Write fails > > with > > -EINVAL if input parsing fails or input error code doesn't > > match. > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/perf/clock > > +Date: April 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-Only. Read for Accelerator Function Unit (AFU) clock > > + counter. > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/perf/cache/freeze > > +Date: April 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-Write. Read this file for the current status of 'cache' > > + category performance counters, and Write '1' or '0' to > > freeze > > + or unfreeze 'cache' performance counters. > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/perf/cache/ > > +Date: April 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-Only. Read 'cache' category performance counters: > > + read_hit, read_miss, write_hit, write_miss, hold_request, > > + data_write_port_contention, tag_write_port_contention, > > + tx_req_stall, rx_req_stall and rx_eviction. > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/perf/iommu/freeze > > +Date: April 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-Write. Read this file for the current status of 'iommu' > > + category performance counters, and Write '1' or '0' to > > freeze > > + or unfreeze 'iommu' performance counters. > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/perf/iommu/ > > +Date: April 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-Only. Read 'iommu' category 'sip' sub category > > + performance counters: iotlb_4k_hit, iotlb_2m_hit, > > + iotlb_1g_hit, slpwc_l3_hit, slpwc_l4_hit, rcc_hit, > > + rcc_miss, iotlb_4k_miss, iotlb_2m_miss, iotlb_1g_miss, > > + slpwc_l3_miss and slpwc_l4_miss. > > + > > +What: > > /sys/bus/platform/devices/dfl-fme.0/perf/iommu/afu0/ > > +Date: April 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-Only. Read 'iommu' category 'afuX' sub category > > + performance counters: read_transaction, write_transaction, > > + devtlb_read_hit, devtlb_write_hit, devtlb_4k_fill, > > + devtlb_2m_fill and devtlb_1g_fill. > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/perf/fabric/freeze > > +Date: April 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-Write. Read this file for the current status of > > 'fabric' > > + category performance counters, and Write '1' or '0' to > > freeze > > + or unfreeze 'fabric' performance counters. > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/perf/fabric/ > > +Date: April 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-Only. Read 'fabric' category performance counters: > > + pcie0_read, pcie0_write, pcie1_read, pcie1_write, > > + upi_read, upi_write and mmio_read. > > Also mmio_write Thanks for the comments, will fix it.
[GIT PULL] KVM changes for 5.2 merge window
Linus, The following changes since commit 7a223e06b1a411cef6c4cd7a9b9a33c8d225b10e: KVM: x86: avoid misreporting level-triggered irqs as edge-triggered in tracing (2019-04-16 15:38:08 +0200) are available in the git repository at: https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you to fetch changes up to dd53f6102c30a774e0db8e55d49017a38060f6f6: Merge tag 'kvmarm-for-v5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD (2019-05-15 23:41:43 +0200) * ARM: support for SVE and Pointer Authentication in guests, PMU improvements * POWER: support for direct access to the POWER9 XIVE interrupt controller, memory and performance optimizations. * x86: support for accessing memory not backed by struct page, fixes and refactoring * Generic: dirty page tracking improvements Aaron Lewis (5): tests: kvm: Add tests to .gitignore tests: kvm: Add tests for KVM_CAP_MAX_VCPUS and KVM_CAP_MAX_CPU_ID KVM: nVMX: KVM_SET_NESTED_STATE - Tear down old EVMCS state before setting new state tests: kvm: Add tests for KVM_SET_NESTED_STATE kvm: nVMX: Set nested_run_pending in vmx_set_nested_state after checks complete Alexey Kardashevskiy (3): KVM: PPC: Book3S HV: Fix lockdep warning when entering the guest KVM: PPC: Book3S HV: Avoid lockdep debugging in TCE realmode handlers KVM: PPC: Book3S: Allocate guest TCEs on demand too Amit Daniel Kachhap (3): KVM: arm64: Add a vcpu flag to control ptrauth for guest KVM: arm64: Add userspace flag to enable pointer authentication KVM: arm64: Add capability to advertise ptrauth for guest Andrew Murray (9): arm64: arm_pmu: Remove unnecessary isb instruction arm64: KVM: Encapsulate kvm_cpu_context in kvm_host_data arm64: KVM: Add accessors to track guest/host only counters arm64: arm_pmu: Add !VHE support for exclude_host/exclude_guest attributes arm64: KVM: Enable !VHE support for :G/:H perf event modifiers arm64: KVM: Enable VHE support for :G/:H perf event modifiers arm64: KVM: Avoid isb's by using direct pmxevtyper sysreg arm64: docs: Document perf event attributes arm64: KVM: Fix perf cycle counter support for VHE Borislav Petkov (1): x86/kvm: Implement HWCR support Christian Borntraeger (9): KVM: s390: add vector enhancements facility 2 to cpumodel KVM: s390: add vector BCD enhancements facility to cpumodel KVM: s390: add MSA9 to cpumodel KVM: s390: provide query function for instructions returning 32 byte KVM: s390: add enhanced sort facilty to cpu model KVM: s390: add deflate conversion facilty to cpu model KVM: s390: enable MSA9 keywrapping functions depending on cpu model KVM: polling: add architecture backend to disable polling KVM: s390: provide kvm_arch_no_poll function Colin Ian King (1): KVM: PPC: Book3S HV: XIVE: Fix spelling mistake "acessing" -> "accessing" Cédric Le Goater (18): powerpc/xive: add OPAL extensions for the XIVE native exploitation support KVM: PPC: Book3S HV: Add a new KVM device for the XIVE native exploitation mode KVM: PPC: Book3S HV: XIVE: Introduce a new capability KVM_CAP_PPC_IRQ_XIVE KVM: PPC: Book3S HV: XIVE: add a control to initialize a source KVM: PPC: Book3S HV: XIVE: Add a control to configure a source KVM: PPC: Book3S HV: XIVE: Add controls for the EQ configuration KVM: PPC: Book3S HV: XIVE: Add a global reset control KVM: PPC: Book3S HV: XIVE: Add a control to sync the sources KVM: PPC: Book3S HV: XIVE: Add a control to dirty the XIVE EQ pages KVM: PPC: Book3S HV: XIVE: Add get/set accessors for the VP XIVE state KVM: Introduce a 'mmap' method for KVM devices KVM: PPC: Book3S HV: XIVE: Add a TIMA mapping KVM: PPC: Book3S HV: XIVE: Add a mapping for the source ESB pages KVM: PPC: Book3S HV: XIVE: Add passthrough support KVM: PPC: Book3S HV: XIVE: Activate XIVE exploitation mode KVM: Introduce a 'release' method for KVM devices KVM: PPC: Book3S HV: XIVE: Replace the 'destroy' method by a 'release' method KVM: PPC: Book3S: Remove useless checks in 'release' method of KVM device Dan Carpenter (1): KVM: vmx: clean up some debug output Dave Martin (41): KVM: Documentation: Document arm64 core registers in detail arm64: fpsimd: Always set TIF_FOREIGN_FPSTATE on task state flush KVM: arm64: Delete orphaned declaration for __fpsimd_enabled() KVM: arm64: Refactor kvm_arm_num_regs() for easier maintenance KVM: arm64: Add missing #includes to kvm_host.h arm64/sve: Clarify role of the VQ map maintenance functions arm64/sve: Check SVE virtualisability arm64/sve: Enable SVE state tracking for non-task contexts
Re: [PATCH v2 1/3] dt-bindings: arm: stm32: Document Avenger96 devicetree binding
Hi Rob, On Mon, May 13, 2019 at 01:02:46PM -0500, Rob Herring wrote: > On Mon, May 06, 2019 at 03:35:32PM +0530, Manivannan Sadhasivam wrote: > > Document devicetree binding for Avenger96 board. > > > > Signed-off-by: Manivannan Sadhasivam > > --- > > Documentation/devicetree/bindings/arm/stm32/stm32.txt | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.txt > > b/Documentation/devicetree/bindings/arm/stm32/stm32.txt > > index 6808ed9ddfd5..eba363a4b514 100644 > > --- a/Documentation/devicetree/bindings/arm/stm32/stm32.txt > > +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.txt > > @@ -8,3 +8,9 @@ using one of the following compatible strings: > >st,stm32f746 > >st,stm32h743 > >st,stm32mp157 > > + > > +Boards: > > + > > +Root node property compatible must contain one of below depending on board: > > + > > + - Avenger96: "arrow,stm32mp157a-avenger96" > > With which SoC compatible? > I referred some other platform bindings (non YAML) and they don't mention the SoC compatible with boards. Shall I just put it like below? Avenger96: "arrow,stm32mp157a-avenger96", "st,stm32mp157" Thanks, Mani Thanks, Mani > > -- > > 2.17.1 > >
mainline/master boot bisection: v5.1-12065-g8c05f3b965da on meson-g12a-x96-max
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the problem may be somewhere else. *
* Hope this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
mainline/master boot bisection: v5.1-12065-g8c05f3b965da on meson-g12a-x96-max
Summary:
Start: 8c05f3b965da Merge tag 'for-linus' of
git://git.armlinux.org.uk/~rmk/linux-arm
Details:https://kernelci.org/boot/id/5cddbf2e59b51487157a362b
Plain log:
https://storage.kernelci.org//mainline/master/v5.1-12065-g8c05f3b965da/arm64/defconfig/gcc-8/lab-baylibre/boot-meson-g12a-x96-max.txt
HTML log:
https://storage.kernelci.org//mainline/master/v5.1-12065-g8c05f3b965da/arm64/defconfig/gcc-8/lab-baylibre/boot-meson-g12a-x96-max.html
Result: 11a7bea17c9e arm64: dts: meson: g12a: add pinctrl support
controllers
Checks:
revert: PASS
verify: PASS
Parameters:
Tree: mainline
URL:git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Branch: master
Target: meson-g12a-x96-max
CPU arch: arm64
Lab:lab-baylibre
Compiler: gcc-8
Config: defconfig
Test suite: boot
Breaking commit found:
---
commit 11a7bea17c9e0a36daab934d83e15a760f402147
Author: Jerome Brunet
Date: Mon Mar 18 10:58:45 2019 +0100
arm64: dts: meson: g12a: add pinctrl support controllers
Add the peripheral and always-on pinctrl controllers to the g12a soc.
Signed-off-by: Jerome Brunet
Signed-off-by: Neil Armstrong
Signed-off-by: Kevin Hilman
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
index abfa167751af..5e07e4ca3f4b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
@@ -104,6 +104,29 @@
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0x34400 0x0 0x400>;
+
+ periphs_pinctrl: pinctrl@40 {
+ compatible =
"amlogic,meson-g12a-periphs-pinctrl";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gpio: bank@40 {
+ reg = <0x0 0x40 0x0 0x4c>,
+ <0x0 0xe8 0x0 0x18>,
+ <0x0 0x120 0x0 0x18>,
+ <0x0 0x2c0 0x0 0x40>,
+ <0x0 0x340 0x0 0x1c>;
+ reg-names = "gpio",
+ "pull",
+ "pull-enable",
+ "mux",
+ "ds";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <_pinctrl
0 0 86>;
+ };
+ };
};
hiu: bus@3c000 {
@@ -150,6 +173,25 @@
clocks = <>, < CLKID_CLK81>;
clock-names = "xtal", "mpeg-clk";
};
+
+ ao_pinctrl: pinctrl@14 {
+ compatible =
"amlogic,meson-g12a-aobus-pinctrl";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gpio_ao: bank@14 {
+ reg = <0x0 0x14 0x0 0x8>,
+ <0x0 0x1c 0x0 0x8>,
+ <0x0 0x24 0x0 0x14>;
+ reg-names = "mux",
+ "ds",
+ "gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges =
Re: [RFC PATCH] kbuild: check uniqueness of basename of modules
Hi Kees,
On Thu, May 16, 2019 at 3:38 AM Kees Cook wrote:
>
> On Thu, May 16, 2019 at 02:55:02AM +0900, Masahiro Yamada wrote:
> >
> > On Thu, May 16, 2019 at 1:20 AM Kees Cook wrote:
> > >
> > > On Wed, May 15, 2019 at 04:53:15PM +0900, Masahiro Yamada wrote:
> > > > On Wed, May 15, 2019 at 4:40 PM Masahiro Yamada
> > > > wrote:
> > > > >
> > > > > [...]
> > > > > diff --git a/scripts/modules-check.sh b/scripts/modules-check.sh
> > > > > new file mode 100755
> > > > > index ..944e68bd22b0
> > > > > --- /dev/null
> > > > > +++ b/scripts/modules-check.sh
> > > > > @@ -0,0 +1,18 @@
> > > > > +#!/bin/sh
> > > > > +# SPDX-License-Identifier: GPL-2.0
> > > > > +
> > > > > +# Warn if two or more modules have the same basename
> > > > > +check_same_name_modules()
> > > > > +{
> > > > > + same_name_modules=$(cat modules.order modules.builtin | \
> > > > > + xargs basename -a | sort | uniq -d)
> > >
> > > While probably it'll never be a problem, just for robustness, I'd add "--"
> > > to the end basename to terminate argument interpretation:
> > >
> > > xargs basename -a -- | sort | ...
> >
> >
> > Sorry for my ignorance, but could you
> > teach me the effect of "--" ?
> >
> >
> > I sometimes use "--" as a separator
> > when there is ambiguity in arguments
> > for example, "git log -- "
> >
> >
> > In this case, what is intended by "--"?
>
> It means "end of arguments" so that whatever xargs passes into the
> program aren't interpretted as an argument. In this case, if there was
> a module path somehow ever named --weird/build/path/foo.o, xargs would
> launch basename as:
>
> basename -a --weird/build/path/foo.o
>
> and basename would fail since it didn't recognize the argument. Having
> "--" will stop argument parsing:
>
> basename -a -- --weird/build/path/foo.o
>
> This is just a robustness suggestion that I always recommend for xargs
> piping, since this can turn into a security flaw (though not here) when
> an argument may have behavioral side-effects. So, it's just a thing that
> always jumps out at me, though in this particular case I don't think
> we could ever see it cause a problem, but better to always write these
> xargs patterns as safely as possible.
I did not think about the security issue.
Thanks for your expert comments!
--
Best Regards
Masahiro Yamada
[PATCH V2 2/3] Documentation: dt: binding: fsl: Add 'little-endian' and update Chassis define
By default, QorIQ SoC's RCPM register block is Big Endian. But there are some exceptions, such as LS1088A and LS2088A, are Little Endian. So add this optional property to help identify them. Actually LS2021A and other Layerscapes won't totally follow Chassis 2.1, so separate them from powerpc SoC. Signed-off-by: Ran Wang --- Change in v2: - None. Documentation/devicetree/bindings/soc/fsl/rcpm.txt |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt index e284e4e..058154c 100644 --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt @@ -20,6 +20,7 @@ Required properites: * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm + * "fsl,qoriq-rcpm-2.1+": for chassis 2.1+ rcpm All references to "1.0" and "2.0" refer to the QorIQ chassis version to which the chip complies. @@ -27,7 +28,12 @@ Chassis Version Example Chips ------ 1.0p4080, p5020, p5040, p2041, p3041 2.0t4240, b4860, b4420 -2.1t1040, ls1021 +2.1t1040, +2.1+ ls1021a, ls1012a, ls1043a, ls1046a + +Optional properties: + - little-endian : RCPM register block is Little Endian. Without it RCPM + will be Big Endian (default case). Example: The RCPM node for T4240: -- 1.7.1
[PATCH V2 3/3] soc: fsl: add RCPM driver
The NXP's QorIQ Processors based on ARM Core have RCPM module
(Run Control and Power Management), which performs all device-level
tasks associated with power management such as wakeup source control.
This driver depends on PM wakeup source framework which help to
collect wake information.
Signed-off-by: Ran Wang
---
Change in v2:
- Rebase Kconfig and Makefile update to latest mainline.
drivers/soc/fsl/Kconfig |8 +++
drivers/soc/fsl/Makefile |1 +
drivers/soc/fsl/rcpm.c | 124 ++
3 files changed, 133 insertions(+), 0 deletions(-)
create mode 100644 drivers/soc/fsl/rcpm.c
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index 61f8e14..8e84e40 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -29,4 +29,12 @@ config FSL_MC_DPIO
other DPAA2 objects. This driver does not expose the DPIO
objects individually, but groups them under a service layer
API.
+
+config FSL_RCPM
+ bool "Freescale RCPM support"
+ depends on PM_SLEEP
+ help
+ The NXP's QorIQ Processors based on ARM Core have RCPM module
+ (Run Control and Power Management), which performs all device-level
+ tasks associated with power management, such as wakeup source control.
endmenu
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 803ef1b..c1be6ee 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
obj-$(CONFIG_FSL_GUTS) += guts.o
obj-$(CONFIG_FSL_MC_DPIO) += dpio/
+obj-$(CONFIG_FSL_RCPM) += rcpm.o
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
new file mode 100644
index 000..b817319
--- /dev/null
+++ b/drivers/soc/fsl/rcpm.c
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// rcpm.c - Freescale QorIQ RCPM driver
+//
+// Copyright 2019 NXP
+//
+// Author: Ran Wang ,
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RCPM_WAKEUP_CELL_MAX_SIZE 7
+
+struct rcpm {
+ unsigned int wakeup_cells;
+ void __iomem *ippdexpcr_base;
+ boollittle_endian;
+};
+
+static int rcpm_pm_prepare(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct wakeup_source *ws;
+ struct rcpm *rcpm;
+ u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1], tmp;
+ int i, ret;
+
+ rcpm = dev_get_drvdata(dev);
+ if (!rcpm)
+ return -EINVAL;
+
+ /* Begin with first registered wakeup source */
+ ws = wakeup_source_get_next(NULL);
+ while (ws) {
+ ret = device_property_read_u32_array(ws->attached_dev,
+ "fsl,rcpm-wakeup", value, rcpm->wakeup_cells +
1);
+
+ /* Wakeup source should refer to current rcpm device */
+ if (ret || (np->phandle != value[0])) {
+ dev_info(dev, "%s doesn't refer to this rcpm\n",
+ ws->name);
+ ws = wakeup_source_get_next(ws);
+ continue;
+ }
+
+ for (i = 0; i < rcpm->wakeup_cells; i++) {
+ /* We can only OR related bits */
+ if (value[i + 1]) {
+ if (rcpm->little_endian) {
+ tmp = ioread32(rcpm->ippdexpcr_base + i
* 4);
+ tmp |= value[i + 1];
+ iowrite32(tmp, rcpm->ippdexpcr_base + i
* 4);
+ } else {
+ tmp = ioread32be(rcpm->ippdexpcr_base +
i * 4);
+ tmp |= value[i + 1];
+ iowrite32be(tmp, rcpm->ippdexpcr_base +
i * 4);
+ }
+ }
+ }
+ ws = wakeup_source_get_next(ws);
+ }
+
+ return 0;
+}
+
+static const struct dev_pm_ops rcpm_pm_ops = {
+ .prepare = rcpm_pm_prepare,
+};
+
+static int rcpm_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct resource *r;
+ struct rcpm *rcpm;
+ int ret;
+
+ rcpm = devm_kzalloc(dev, sizeof(*rcpm), GFP_KERNEL);
+ if (!rcpm)
+ return -ENOMEM;
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!r)
+ return -ENODEV;
+
+ rcpm->ippdexpcr_base = devm_ioremap_resource(>dev, r);
+ if (IS_ERR(rcpm->ippdexpcr_base)) {
+ ret = PTR_ERR(rcpm->ippdexpcr_base);
+ return ret;
+ }
+
+ rcpm->little_endian = device_property_read_bool(
+ >dev, "little-endian");
+
+ ret =
[PATCH V2 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
Some user might want to go through all registered wakeup sources
and doing things accordingly. For example, SoC PM driver might need to
do HW programming to prevent powering down specific IP which wakeup
source depending on. And is user's responsibility to identify if this
wakeup source he is interested in.
Signed-off-by: Ran Wang
---
Change in v2:
- None.
drivers/base/power/wakeup.c | 18 ++
include/linux/pm_wakeup.h |3 +++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index 5b2b6a0..6904485 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -226,6 +227,22 @@ void wakeup_source_unregister(struct wakeup_source *ws)
}
}
EXPORT_SYMBOL_GPL(wakeup_source_unregister);
+/**
+ * wakeup_source_get_next - Get next wakeup source from the list
+ * @ws: Previous wakeup source object, null means caller want first one.
+ */
+struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws)
+{
+ struct list_head *ws_head = _sources;
+
+ if (ws)
+ return list_next_or_null_rcu(ws_head, >entry,
+ struct wakeup_source, entry);
+ else
+ return list_entry_rcu(ws_head->next,
+ struct wakeup_source, entry);
+}
+EXPORT_SYMBOL_GPL(wakeup_source_get_next);
/**
* device_wakeup_attach - Attach a wakeup source object to a device object.
@@ -242,6 +259,7 @@ static int device_wakeup_attach(struct device *dev, struct
wakeup_source *ws)
return -EEXIST;
}
dev->power.wakeup = ws;
+ ws->attached_dev = dev;
if (dev->power.wakeirq)
device_wakeup_attach_irq(dev, dev->power.wakeirq);
spin_unlock_irq(>power.lock);
diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h
index 0ff134d..3d300f5 100644
--- a/include/linux/pm_wakeup.h
+++ b/include/linux/pm_wakeup.h
@@ -50,6 +50,7 @@
* @wakeup_count: Number of times the wakeup source might abort suspend.
* @active: Status of the wakeup source.
* @has_timeout: The wakeup source has been activated with a timeout.
+ * @attached_dev: The device it attached to
*/
struct wakeup_source {
const char *name;
@@ -70,6 +71,7 @@ struct wakeup_source {
unsigned long wakeup_count;
boolactive:1;
boolautosleep_enabled:1;
+ struct device *attached_dev;
};
#ifdef CONFIG_PM_SLEEP
@@ -101,6 +103,7 @@ static inline void device_set_wakeup_path(struct device
*dev)
extern void wakeup_source_remove(struct wakeup_source *ws);
extern struct wakeup_source *wakeup_source_register(const char *name);
extern void wakeup_source_unregister(struct wakeup_source *ws);
+extern struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws);
extern int device_wakeup_enable(struct device *dev);
extern int device_wakeup_disable(struct device *dev);
extern void device_set_wakeup_capable(struct device *dev, bool capable);
--
1.7.1
Re: [RFC PATCH] kbuild: check uniqueness of basename of modules
Hi Kees,
On Thu, May 16, 2019 at 3:31 AM Kees Cook wrote:
>
> On Thu, May 16, 2019 at 03:07:54AM +0900, Masahiro Yamada wrote:
> > On Wed, May 15, 2019 at 4:40 PM Masahiro Yamada
> > wrote:
> >
> > > $(Q)$(AWK) '!x[$$0]++' $^ > $(objtree)/modules.builtin
> > > diff --git a/scripts/modules-check.sh b/scripts/modules-check.sh
> > > new file mode 100755
> > > index ..944e68bd22b0
> > > --- /dev/null
> > > +++ b/scripts/modules-check.sh
> > > @@ -0,0 +1,18 @@
> > > +#!/bin/sh
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +
> > > +# Warn if two or more modules have the same basename
> > > +check_same_name_modules()
> > > +{
> > > + same_name_modules=$(cat modules.order modules.builtin | \
> > > + xargs basename -a | sort | uniq -d)
> >
> >
> > I noticed a bug here.
> >
> >
> > allnoconfig + CONFIG_MODULES=y
> > will create empty modules.order and modules.builtin.
> >
> > Then, 'basename -a' will emit the error messages
> > since it receives zero arguments.
>
> You can skip running it by adding "-r" to xargs:
>
>-r, --no-run-if-empty
> If the standard input does not contain any nonblanks, do not run
> the command. Normally, the command is run once even if there is
> no input. This option is a GNU extension.
Good idea!
I will use this in v2.
Thanks.
--
Best Regards
Masahiro Yamada
Re: [PATCH v6 08/12] soc: mediatek: cmdq: define the instruction struct
Hi, Bibby: On Thu, 2019-05-16 at 17:02 +0800, Bibby Hsieh wrote: > Define a instruction structure for gce driver to append command. > This structure can make the client's code more readability. > > Signed-off-by: Bibby Hsieh > --- > drivers/soc/mediatek/mtk-cmdq-helper.c | 113 +++ > include/linux/mailbox/mtk-cmdq-mailbox.h | 2 + > include/linux/soc/mediatek/mtk-cmdq.h| 14 +-- > 3 files changed, 84 insertions(+), 45 deletions(-) > [snip] > > /** > * cmdq_pkt_write_mask() - append write command with mask to the CMDQ packet > * @pkt: the CMDQ packet > - * @value: the specified target register value > * @subsys: the CMDQ sub system code > * @offset: register offset from CMDQ sub system > + * @value: the specified target register value > * @mask:the specified target register mask > * > * Return: 0 for success; else the error code is returned > */ > -int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value, > - u32 subsys, u32 offset, u32 mask); > +int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys, u16 offset, > + u32 value, u32 mask); You have do two things for this interface: one is reordering the parameter, another one is changing type of subsys from u32 to u8. Define the instruction struct is not necessary to change the order and type. I would like you to separate these two things to another patches. So the patch sequence may be: 1. Reorder parameter of cmdq_pkt_write_mask() 2. Change subsys type to u8 3. define the instruction struct Regards, CK > > /** > * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet > @@ -88,7 +88,7 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value, > * > * Return: 0 for success; else the error code is returned > */ > -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event); > +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event); > > /** > * cmdq_pkt_clear_event() - append clear event command to the CMDQ packet > @@ -97,7 +97,7 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event); > * > * Return: 0 for success; else the error code is returned > */ > -int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u32 event); > +int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event); > > /** > * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
[PATCH V2] ASoC: cs42xx8: Add regcache mask dirty
Add regcache_mark_dirty before regcache_sync for power
of codec may be lost at suspend, then all the register
need to be reconfigured.
Fixes: 0c516b4ff85c ("ASoC: cs42xx8: Add codec driver support for
CS42448/CS42888")
Cc:
Signed-off-by: Shengjiu Wang
---
Changs in V2
- Don't split Fixes tag.
sound/soc/codecs/cs42xx8.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/cs42xx8.c b/sound/soc/codecs/cs42xx8.c
index ebb9e0cf8364..28a4ac36c4f8 100644
--- a/sound/soc/codecs/cs42xx8.c
+++ b/sound/soc/codecs/cs42xx8.c
@@ -558,6 +558,7 @@ static int cs42xx8_runtime_resume(struct device *dev)
msleep(5);
regcache_cache_only(cs42xx8->regmap, false);
+ regcache_mark_dirty(cs42xx8->regmap);
ret = regcache_sync(cs42xx8->regmap);
if (ret) {
--
2.21.0
RE: [EXT] Re: [PATCH 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
Hi Arnd,
-Original Message-
From: Arnd Bergmann
Sent: 2019年5月15日 16:05
To: Xiaowei Bao
Cc: Bjorn Helgaas ; Rob Herring ; Mark
Rutland ; Shawn Guo ; Leo Li
; Kishon ; Lorenzo Pieralisi
; gregkh ; M.h. Lian
; Mingkai Hu ; Roy Zang
; Kate Stewart ; Philippe
Ombredanne ; Shawn Lin ;
linux-pci ; DTML ; Linux
Kernel Mailing List ; Linux ARM
; linuxppc-dev
Subject: [EXT] Re: [PATCH 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
Caution: EXT Email
On Wed, May 15, 2019 at 9:36 AM Xiaowei Bao wrote:
> Signed-off-by: Xiaowei Bao
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 52
>
> 1 files changed, 52 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index b045812..50b579b 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -398,6 +398,58 @@
> status = "disabled";
> };
>
> + pcie@340 {
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0340 0x0 0x0010 /* controller
> registers */
> + 0x80 0x 0x0 0x2000>; /*
> configuration space */
> + reg-names = "regs", "config";
> + interrupts = , /*
> PME interrupt */
> +; /*
> aer interrupt */
> + interrupt-names = "pme", "aer";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + dma-coherent;
> + num-lanes = <4>;
> + bus-range = <0x0 0xff>;
> + ranges = <0x8100 0x0 0x 0x80 0x0001
> 0x0 0x0001 /* downstream I/O */
> + 0x8200 0x0 0x4000 0x80 0x4000
> 0x0 0x4000>; /* non-prefetchable memory */
Are you sure there is no support for 64-bit BARs or prefetchable memory?
[Xiaowei Bao] sorry for late reply, Thought that our Layerscape platform has
not added prefetchable memory support in DTS, so this platform has not been
added, I will submit a separate patch to add prefetchable memory support for
all Layerscape platforms.
Of course, the prefetchable PCIE device can work in our boards, because the RC
will assign non-prefetchable memory for this device. We reserve 1G
no-prefetchable memory for PCIE device, it is enough for general devices.
Is this a hardware bug, or something that can be fixed in firmware?
[Xiaowei Bao] this is not a hardware bug, our HW support the 64-bit
prefetchable memory.
Arnd
Re: [PATCH V3 4/4] arm64/mm: Enable memory hot remove
On 05/16/2019 04:27 PM, Mark Rutland wrote:
> On Thu, May 16, 2019 at 11:04:48AM +0530, Anshuman Khandual wrote:
>> On 05/15/2019 05:19 PM, Mark Rutland wrote:
>>> On Tue, May 14, 2019 at 02:30:07PM +0530, Anshuman Khandual wrote:
Memory removal from an arch perspective involves tearing down two different
kernel based mappings i.e vmemmap and linear while releasing related page
table and any mapped pages allocated for given physical memory range to be
removed.
Define a common kernel page table tear down helper remove_pagetable() which
can be used to unmap given kernel virtual address range. In effect it can
tear down both vmemap or kernel linear mappings. This new helper is called
from both vmemamp_free() and ___remove_pgd_mapping() during memory removal.
For linear mapping there are no actual allocated pages which are mapped to
create the translation. Any pfn on a given entry is derived from physical
address (__va(PA) --> PA) whose linear translation is to be created. They
need not be freed as they were never allocated in the first place. But for
vmemmap which is a real virtual mapping (like vmalloc) physical pages are
allocated either from buddy or memblock which get mapped in the kernel page
table. These allocated and mapped pages need to be freed during translation
tear down. But page table pages need to be freed in both these cases.
>>>
>>> As previously discussed, we should only hot-remove memory which was
>>> hot-added, so we shouldn't encounter memory allocated from memblock.
>>
>> Right, not applicable any more. Will drop this word.
>>
These mappings need to be differentiated while deciding if a mapped page at
any level i.e [pte|pmd|pud]_page() should be freed or not. Callers for the
mapping tear down process should pass on 'sparse_vmap' variable identifying
kernel vmemmap mappings.
>>>
>>> I think that you can simplify the paragraphs above down to:
>>>
>>> The arch code for hot-remove must tear down portions of the linear map
>>> and vmemmap corresponding to memory being removed. In both cases the
>>> page tables mapping these regions must be freed, and when sparse
>>> vmemmap is in use the memory backing the vmemmap must also be freed.
>>>
>>> This patch adds a new remove_pagetable() helper which can be used to
>>> tear down either region, and calls it from vmemmap_free() and
>>> ___remove_pgd_mapping(). The sparse_vmap argument determines whether
>>> the backing memory will be freed.
>>
>> The current one is bit more descriptive on detail. Anyways will replace with
>> the above writeup if that is preferred.
>
> I would prefer the suggested form above, as it's easier to extract the
> necessary details from it.
Fair enough.
>
> [...]
>
+static void
+remove_pagetable(unsigned long start, unsigned long end, bool sparse_vmap)
+{
+ unsigned long addr, next;
+ pud_t *pudp_base;
+ pgd_t *pgdp;
+
+ spin_lock(_mm.page_table_lock);
>>>
>>> It would be good to explain why we need to take the ptl here.
>>
>> Will update both commit message and add an in-code comment here.
>>
>>>
>>> IIUC that shouldn't be necessary for the linear map. Am I mistaken?
>>
>> Its not absolutely necessary for linear map right now because both memory hot
>> plug & ptdump which modifies or walks the page table ranges respectively take
>> memory hotplug lock. That apart, no other callers creates or destroys linear
>> mapping at runtime.
>>
>>>
>>> Is there a specific race when tearing down the vmemmap?
>>
>> This is trickier than linear map. vmemmap additions would be protected with
>> memory hotplug lock but this can potential collide with vmalloc/IO regions.
>> Even if they dont right now that will be because they dont share intermediate
>> page table levels.
>
> Sure; if we could just state something like:
>
> The vmemmap region may share levels of table with the vmalloc region.
> Take the ptl so that we can safely free potentially-sahred tables.
>
> ... I think that would be sufficient.
Will do.
Re: Linux 4.19 and GCC 9
We are building the upstream kernel. There are a few patches, but nothing related to objtool. Unless you mean mainline/stable by upstream, I haven't tried that. We stick to LTS. On Thu, May 16, 2019 at 7:04 PM Josh Poimboeuf wrote: > > On Thu, May 16, 2019 at 11:20:54PM +0200, Miguel Ojeda wrote: > > > mm/slub.o: warning: objtool: init_cache_random_seq()+0x36: sibling > > > call from callable instruction with modified stack frame > > > mm/slub.o: warning: objtool: slab_out_of_memory()+0x3b: sibling call > > > from callable instruction with modified stack frame > > > mm/slub.o: warning: objtool: slab_pad_check.part.0()+0x7c: sibling > > > call from callable instruction with modified stack frame > > > mm/slub.o: warning: objtool: check_slab()+0x1c: sibling call from > > > callable instruction with modified stack frame > > > > AFAIK those are non-critical, i.e. stack traces may be wrong (or not), > > but it does not mean the generated kernel itself is wrong. CC'ing the > > objtool maintainers too. > > I don't think I recognize those warnings. Do you also see them in the > upstream kernel? > > -- > Josh
RE: [alsa-devel] [PATCH] ASoC: cs42xx8: Add regcache mask dirty
Hi
> Add regcache_mark_dirty before regcache_sync for power of codec may be
> lost at suspend, then all the register need to be reconfigured.
>
> Fixes: 0c516b4ff85c ("ASoC: cs42xx8: Add codec driver support for
> CS42448/CS42888")
The Fixes tag is split, will send v2.
Best regards
Wang shengjiu
[git pull] vfs.git mount followups
Propagation of new syscalls to other architectures + cosmetical change from Christian (fscontext didn't follow the convention for anon inode names). What is _not_ included is cloexec changes - I really don't see the benefits for the cloexec-by-default for new syscalls, when there's no chance in hell of switching to that policy for old ones. The following changes since commit 05883eee857eab4693e7d13ebab06716475c5754: do_move_mount(): fix an unsafe use of is_anon_ns() (2019-05-09 02:32:50 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes for you to fetch changes up to d8076bdb56af5e5918376cd1573a6b0007fc1a89: uapi: Wire up the mount API syscalls on non-x86 arches [ver #2] (2019-05-16 12:23:45 -0400) Christian Brauner (1): uapi, fsopen: use square brackets around "fscontext" [ver #2] David Howells (2): uapi, x86: Fix the syscall numbering of the mount API syscalls [ver #2] uapi: Wire up the mount API syscalls on non-x86 arches [ver #2] arch/alpha/kernel/syscalls/syscall.tbl | 6 ++ arch/arm/tools/syscall.tbl | 6 ++ arch/arm64/include/asm/unistd.h | 2 +- arch/arm64/include/asm/unistd32.h | 12 arch/ia64/kernel/syscalls/syscall.tbl | 6 ++ arch/m68k/kernel/syscalls/syscall.tbl | 6 ++ arch/microblaze/kernel/syscalls/syscall.tbl | 6 ++ arch/mips/kernel/syscalls/syscall_n32.tbl | 6 ++ arch/mips/kernel/syscalls/syscall_n64.tbl | 6 ++ arch/mips/kernel/syscalls/syscall_o32.tbl | 6 ++ arch/parisc/kernel/syscalls/syscall.tbl | 6 ++ arch/powerpc/kernel/syscalls/syscall.tbl| 6 ++ arch/s390/kernel/syscalls/syscall.tbl | 6 ++ arch/sh/kernel/syscalls/syscall.tbl | 6 ++ arch/sparc/kernel/syscalls/syscall.tbl | 6 ++ arch/x86/entry/syscalls/syscall_32.tbl | 12 ++-- arch/x86/entry/syscalls/syscall_64.tbl | 12 ++-- arch/xtensa/kernel/syscalls/syscall.tbl | 6 ++ fs/fsopen.c | 2 +- include/uapi/asm-generic/unistd.h | 14 +- 20 files changed, 123 insertions(+), 15 deletions(-)
[PATCH] ASoC: fsl_esai: fix the channel swap issue after xrun
There is chip errata ERR008000, the reference doc is
(https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf),
The issue is "While using ESAI transmit or receive and
an underrun/overrun happens, channel swap may occur.
The only recovery mechanism is to reset the ESAI."
In this commit add a tasklet to handle reset of ESAI
after xrun happens
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_esai.c | 166 +++
1 file changed, 166 insertions(+)
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 10d2210c91ef..149972894c95 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -52,17 +52,20 @@ struct fsl_esai {
struct clk *extalclk;
struct clk *fsysclk;
struct clk *spbaclk;
+ struct tasklet_struct task;
u32 fifo_depth;
u32 slot_width;
u32 slots;
u32 tx_mask;
u32 rx_mask;
+ u32 tx_channels;
u32 hck_rate[2];
u32 sck_rate[2];
bool hck_dir[2];
bool sck_div[2];
bool slave_mode;
bool synchronous;
+ bool reset_at_xrun;
char name[32];
};
@@ -71,8 +74,14 @@ static irqreturn_t esai_isr(int irq, void *devid)
struct fsl_esai *esai_priv = (struct fsl_esai *)devid;
struct platform_device *pdev = esai_priv->pdev;
u32 esr;
+ u32 saisr;
regmap_read(esai_priv->regmap, REG_ESAI_ESR, );
+ regmap_read(esai_priv->regmap, REG_ESAI_SAISR, );
+
+ if ((saisr & (ESAI_SAISR_TUE | ESAI_SAISR_ROE))
+ && esai_priv->reset_at_xrun)
+ tasklet_schedule(_priv->task);
if (esr & ESAI_ESR_TINIT_MASK)
dev_dbg(>dev, "isr: Transmission Initialized\n");
@@ -552,6 +561,9 @@ static int fsl_esai_trigger(struct snd_pcm_substream
*substream, int cmd,
u32 pins = DIV_ROUND_UP(channels, esai_priv->slots);
u32 mask;
+ if (tx)
+ esai_priv->tx_channels = channels;
+
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
@@ -585,10 +597,16 @@ static int fsl_esai_trigger(struct snd_pcm_substream
*substream, int cmd,
regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(mask));
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
+ ESAI_xCR_xEIE_MASK, ESAI_xCR_xEIE);
+
break;
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
+ ESAI_xCR_xEIE_MASK, 0);
+
regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK, 0);
regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
@@ -618,6 +636,145 @@ static const struct snd_soc_dai_ops fsl_esai_dai_ops = {
.set_tdm_slot = fsl_esai_set_dai_tdm_slot,
};
+static void fsl_esai_reset(unsigned long arg)
+{
+ struct fsl_esai *esai_priv = (struct fsl_esai *)arg;
+ u32 saisr;
+ u32 tsma, tsmb, rsma, rsmb, tcr, rcr, tfcr, rfcr;
+ int i;
+
+ /*
+* stop the tx & rx
+*/
+ regmap_read(esai_priv->regmap, REG_ESAI_TSMA, );
+ regmap_read(esai_priv->regmap, REG_ESAI_TSMB, );
+ regmap_read(esai_priv->regmap, REG_ESAI_RSMA, );
+ regmap_read(esai_priv->regmap, REG_ESAI_RSMB, );
+
+ regmap_read(esai_priv->regmap, REG_ESAI_TCR, );
+ regmap_read(esai_priv->regmap, REG_ESAI_RCR, );
+
+ regmap_read(esai_priv->regmap, REG_ESAI_TFCR, );
+ regmap_read(esai_priv->regmap, REG_ESAI_RFCR, );
+
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
+ ESAI_xCR_xEIE_MASK | ESAI_xCR_TE_MASK, 0);
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR,
+ ESAI_xCR_xEIE_MASK | ESAI_xCR_RE_MASK, 0);
+
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_TSMA,
+ ESAI_xSMA_xS_MASK, 0);
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_TSMB,
+ ESAI_xSMB_xS_MASK, 0);
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_RSMA,
+ ESAI_xSMA_xS_MASK, 0);
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_RSMB,
+ ESAI_xSMB_xS_MASK, 0);
+
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_TFCR,
+ ESAI_xFCR_xFR | ESAI_xFCR_xFEN, ESAI_xFCR_xFR);
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_TFCR,
+ ESAI_xFCR_xFR, 0);
+
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_RFCR,
+ ESAI_xFCR_xFR | ESAI_xFCR_xFEN, ESAI_xFCR_xFR);
+
Re: [GIT PULL] RISC-V Patches for the 5.2 Merge Window, Part 1 v2
On Thu, 16 May 2019 19:17:17 PDT (-0700), Linus Torvalds wrote: On Thu, May 16, 2019 at 5:27 PM Palmer Dabbelt wrote: git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git tags/riscv-for-linus-5.2-mw1 Oh no no no. You're creating a binary file from your build or something like that: modules.builtin.modinfo| Bin 0 -> 46064 bytes which is completely unacceptable. I have no idea what you're doing, but this kind of "random garbage in git commits" is not going to fly. And the fact that you're adding random files really means that you are doing something *horribly* wrong. Sorry, I have no idea how I missed that. It looks like I managed to screw something up while trying to fix up that patch, but I'm not really sure what I did. I'll try to figure out how to not screw it up next time. Thanks for catching this!
[PATCH 2/3] Documentation: dt: binding: fsl: Add 'little-endian' and update Chassis define
By default, QorIQ SoC's RCPM register block is Big Endian. But there are some exceptions, such as LS1088A and LS2088A, are Little Endian. So add this optional property to help identify them. Actually LS2021A and other Layerscapes won't totally follow Chassis 2.1, so separate them from powerpc SoC. Signed-off-by: Ran Wang --- Documentation/devicetree/bindings/soc/fsl/rcpm.txt |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt index e284e4e..058154c 100644 --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt @@ -20,6 +20,7 @@ Required properites: * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm + * "fsl,qoriq-rcpm-2.1+": for chassis 2.1+ rcpm All references to "1.0" and "2.0" refer to the QorIQ chassis version to which the chip complies. @@ -27,7 +28,12 @@ Chassis Version Example Chips ------ 1.0p4080, p5020, p5040, p2041, p3041 2.0t4240, b4860, b4420 -2.1t1040, ls1021 +2.1t1040, +2.1+ ls1021a, ls1012a, ls1043a, ls1046a + +Optional properties: + - little-endian : RCPM register block is Little Endian. Without it RCPM + will be Big Endian (default case). Example: The RCPM node for T4240: -- 1.7.1
[PATCH 3/3] soc: fsl: add RCPM driver
The NXP's QorIQ Processors based on ARM Core have RCPM module
(Run Control and Power Management), which performs all device-level
tasks associated with power management such as wakeup source control.
This driver depends on PM wakeup source framework which help to
collect wake information.
Signed-off-by: Ran Wang
---
drivers/soc/fsl/Kconfig |8 +++
drivers/soc/fsl/Makefile |1 +
drivers/soc/fsl/rcpm.c | 124 ++
3 files changed, 133 insertions(+), 0 deletions(-)
create mode 100644 drivers/soc/fsl/rcpm.c
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index 3b85e18..a25e05b 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -50,4 +50,12 @@ config FSL_SLEEP_FSM
if ARM || ARM64
source "drivers/soc/fsl/Kconfig.arm"
endif
+
+config FSL_RCPM
+ bool "Freescale RCPM support"
+ depends on PM_SLEEP
+ help
+ The NXP's QorIQ Processors based on ARM Core have RCPM module
+ (Run Control and Power Management), which performs all device-level
+ tasks associated with power management, such as wakeup source control.
endmenu
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index db7b09b..aab9f9b 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_FSL_MC_DPIO) += dpio/
obj-$(CONFIG_FSL_LS2_CONSOLE) += ls2-console/
obj-$(CONFIG_LS_SOC_DRIVERS) += layerscape/
obj-$(CONFIG_FSL_SLEEP_FSM)+= sleep_fsm.o
+obj-$(CONFIG_FSL_RCPM) += rcpm.o
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
new file mode 100644
index 000..b817319
--- /dev/null
+++ b/drivers/soc/fsl/rcpm.c
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// rcpm.c - Freescale QorIQ RCPM driver
+//
+// Copyright 2019 NXP
+//
+// Author: Ran Wang ,
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RCPM_WAKEUP_CELL_MAX_SIZE 7
+
+struct rcpm {
+ unsigned int wakeup_cells;
+ void __iomem *ippdexpcr_base;
+ boollittle_endian;
+};
+
+static int rcpm_pm_prepare(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct wakeup_source *ws;
+ struct rcpm *rcpm;
+ u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1], tmp;
+ int i, ret;
+
+ rcpm = dev_get_drvdata(dev);
+ if (!rcpm)
+ return -EINVAL;
+
+ /* Begin with first registered wakeup source */
+ ws = wakeup_source_get_next(NULL);
+ while (ws) {
+ ret = device_property_read_u32_array(ws->attached_dev,
+ "fsl,rcpm-wakeup", value, rcpm->wakeup_cells +
1);
+
+ /* Wakeup source should refer to current rcpm device */
+ if (ret || (np->phandle != value[0])) {
+ dev_info(dev, "%s doesn't refer to this rcpm\n",
+ ws->name);
+ ws = wakeup_source_get_next(ws);
+ continue;
+ }
+
+ for (i = 0; i < rcpm->wakeup_cells; i++) {
+ /* We can only OR related bits */
+ if (value[i + 1]) {
+ if (rcpm->little_endian) {
+ tmp = ioread32(rcpm->ippdexpcr_base + i
* 4);
+ tmp |= value[i + 1];
+ iowrite32(tmp, rcpm->ippdexpcr_base + i
* 4);
+ } else {
+ tmp = ioread32be(rcpm->ippdexpcr_base +
i * 4);
+ tmp |= value[i + 1];
+ iowrite32be(tmp, rcpm->ippdexpcr_base +
i * 4);
+ }
+ }
+ }
+ ws = wakeup_source_get_next(ws);
+ }
+
+ return 0;
+}
+
+static const struct dev_pm_ops rcpm_pm_ops = {
+ .prepare = rcpm_pm_prepare,
+};
+
+static int rcpm_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct resource *r;
+ struct rcpm *rcpm;
+ int ret;
+
+ rcpm = devm_kzalloc(dev, sizeof(*rcpm), GFP_KERNEL);
+ if (!rcpm)
+ return -ENOMEM;
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!r)
+ return -ENODEV;
+
+ rcpm->ippdexpcr_base = devm_ioremap_resource(>dev, r);
+ if (IS_ERR(rcpm->ippdexpcr_base)) {
+ ret = PTR_ERR(rcpm->ippdexpcr_base);
+ return ret;
+ }
+
+ rcpm->little_endian = device_property_read_bool(
+ >dev, "little-endian");
+
+ ret = device_property_read_u32(>dev,
+ "fsl,#rcpm-wakeup-cells", >wakeup_cells);
+ if (ret)
+ return ret;
+
+ dev_set_drvdata(>dev, rcpm);
+
[PATCH 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
Some user might want to go through all registered wakeup sources
and doing things accordingly. For example, SoC PM driver might need to
do HW programming to prevent powering down specific IP which wakeup
source depending on. And is user's responsibility to identify if this
wakeup source he is interested in.
Signed-off-by: Ran Wang
---
drivers/base/power/wakeup.c | 18 ++
include/linux/pm_wakeup.h |3 +++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index 5fa1898..8d75795 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -236,6 +237,22 @@ void wakeup_source_unregister(struct wakeup_source *ws)
}
}
EXPORT_SYMBOL_GPL(wakeup_source_unregister);
+/**
+ * wakeup_source_get_next - Get next wakeup source from the list
+ * @ws: Previous wakeup source object, null means caller want first one.
+ */
+struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws)
+{
+ struct list_head *ws_head = _sources;
+
+ if (ws)
+ return list_next_or_null_rcu(ws_head, >entry,
+ struct wakeup_source, entry);
+ else
+ return list_entry_rcu(ws_head->next,
+ struct wakeup_source, entry);
+}
+EXPORT_SYMBOL_GPL(wakeup_source_get_next);
/**
* device_wakeup_attach - Attach a wakeup source object to a device object.
@@ -252,6 +269,7 @@ static int device_wakeup_attach(struct device *dev, struct
wakeup_source *ws)
return -EEXIST;
}
dev->power.wakeup = ws;
+ ws->attached_dev = dev;
if (dev->power.wakeirq)
device_wakeup_attach_irq(dev, dev->power.wakeirq);
spin_unlock_irq(>power.lock);
diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h
index 4238dde..1335487 100644
--- a/include/linux/pm_wakeup.h
+++ b/include/linux/pm_wakeup.h
@@ -50,6 +50,7 @@
* @wakeup_count: Number of times the wakeup source might abort suspend.
* @active: Status of the wakeup source.
* @has_timeout: The wakeup source has been activated with a timeout.
+ * @attached_dev: The device it attached to
*/
struct wakeup_source {
const char *name;
@@ -70,6 +71,7 @@ struct wakeup_source {
unsigned long wakeup_count;
boolactive:1;
boolautosleep_enabled:1;
+ struct device *attached_dev;
};
#ifdef CONFIG_PM_SLEEP
@@ -102,6 +104,7 @@ static inline void device_set_wakeup_path(struct device
*dev)
extern void wakeup_source_remove(struct wakeup_source *ws);
extern struct wakeup_source *wakeup_source_register(const char *name);
extern void wakeup_source_unregister(struct wakeup_source *ws);
+extern struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws);
extern int device_wakeup_enable(struct device *dev);
extern int device_wakeup_disable(struct device *dev);
extern void device_set_wakeup_capable(struct device *dev, bool capable);
--
1.7.1
Re: [PATCH] KVM: selftests: Compile code with warnings enabled
Hi, Thomas, On Thu, May 16, 2019 at 03:02:57PM +0200, Thomas Huth wrote: > So far the KVM selftests are compiled without any compiler warnings > enabled. That's quite bad, since we miss a lot of possible bugs this > way. Let's enable at least "-Wall" and some other useful warning flags > now. > > Signed-off-by: Thomas Huth > --- > This patch fixes most of the warnings in the x86 code already - but > for some warnings, I was not quite sure (e.g. about the need for the > kvm_get_supported_cpuid_entry(1) in some tests), so I did not touch If you mean the two calls in state_test and evmcs_test I would agree they should be dropped directly. Just to mention that the patch may not apply cleanly to kvm/queue now probably because the dirty-log-test.c touchup recently, so may need a rebase. Otherwise it looks nice at least to me to have these checks. Thanks, -- Peter Xu
Re: [PATCH RESEND] firmware: imx: SCU irq should ONLY be enabled after SCU IPC is ready
On Sun, May 12, 2019 at 08:38:22AM +, Anson Huang wrote:
> The imx_scu_irq_group_enable() is normally called during module driver
> probe phase to enable SCU group irq, if SCU IPC is NOT ready, below
> dump will show out:
>
> [0.933001] Hardware name: Freescale i.MX8QXP MEK (DT)
> [0.938129] pstate: 6005 (nZCv daif -PAN -UAO)
> [0.942907] pc : imx_scu_call_rpc+0x114/0x158
> [0.947251] lr : imx_scu_irq_group_enable+0x74/0xc4
> [0.952113] sp : 1005bae0
> [0.955415] x29: 1005bae0 x28: 111bb0a0
> [0.960712] x27: 1140b000 x26: 068c
> [0.966011] x25: 111bb100 x24:
> [0.971311] x23: 113d9cd8 x22: 0001
> [0.976610] x21: 0001 x20: 80083b51a410
> [0.981909] x19: 11259000 x18: 0480
> [0.987209] x17: 0023ffb8 x16: 0010
> [0.992508] x15: 023f x14:
> [0.997807] x13: 0018 x12: 0030
> [1.003107] x11: 0003 x10: 0101010101010101
> [1.008406] x9 : x8 : 7f7f7f7f7f7f7f7f
> [1.013706] x7 : fefefeff646c606d x6 :
> [1.019005] x5 : 112596c8 x4 : 0008
> [1.024304] x3 : 0003 x2 : 0001
> [1.029604] x1 : 1005bb58 x0 :
> [1.034905] Call trace:
> [1.037341] imx_scu_call_rpc+0x114/0x158
> [1.041334] imx_scu_irq_group_enable+0x74/0xc4
> [1.045856] imx_sc_wdt_probe+0x24/0x150
> [1.049766] platform_drv_probe+0x4c/0xb0
> [1.053762] really_probe+0x1f8/0x2c8
> [1.057407] driver_probe_device+0x58/0xfc
> [1.061490] device_driver_attach+0x68/0x70
> [1.065660] __driver_attach+0x94/0xdc
> [1.069397] bus_for_each_dev+0x64/0xc0
> [1.073220] driver_attach+0x20/0x28
> [1.076782] bus_add_driver+0x148/0x1fc
> [1.080601] driver_register+0x68/0x120
> [1.084424] __platform_driver_register+0x4c/0x54
> [1.089120] imx_sc_wdt_driver_init+0x18/0x20
> [1.093463] do_one_initcall+0x58/0x1b8
> [1.097287] kernel_init_freeable+0x1cc/0x288
> [1.101630] kernel_init+0x10/0x100
> [1.105101] ret_from_fork+0x10/0x18
> [1.108669] ---[ end trace 9e03302114457de9 ]---
> [1.113296] enable irq failed, group 1, mask 1, ret -22
>
> To avoid such scenario, return -EPROBE_DEFER in imx_scu_irq_group_enable()
> API if SCU IPC is NOT ready, then module driver which calls this API
> in probe phase will defer probe after SCU IPC ready.
>
> Fixes: 851826c7566e ("firmware: imx: enable imx scu general irq function")
> Signed-off-by: Anson Huang
Applied, thanks.
RE: linux-next: Fixes tag needs some work in the sound-asoc tree
Hi
Do I need to resend the patch?
Best regards
Wang shengjiu
>
> In commit
>
> b06c58c2a1ee ("ASoC: fsl_asrc: Fix the issue about unsupported rate")
>
> Fixes tag
>
> Fixes: fff6e03c7b65 ("ASoC: fsl_asrc: add support for 8-30kHz
>
> has these problem(s):
>
> - Subject has leading but no trailing parentheses
> - Subject has leading but no trailing quotes
>
> Please do not split fixes tags over more that one line.
>
> --
> Cheers,
> Stephen Rothwell
Re: [PATCH] Input: walkera0701 - Fix possible NULL pointer dereference in walkera0701_detach
ping...
On 2019/4/23 22:56, Yue Haibing wrote:
> From: YueHaibing
>
> KASAN report this:
>
> walkera0701: failed to allocate input device
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: [#1] SMP KASAN PTI
> CPU: 1 PID: 5324 Comm: syz-executor.0 Tainted: G C5.1.0-rc3+
> #8
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
> 04/01/2014
> RIP: 0010:input_unregister_device+0x21/0xe0 drivers/input/input.c:2192
> Code: 2e 0f 1f 84 00 00 00 00 00 53 48 89 fb e8 07 41 f6 fe 48 8d bb 20 07 00
> 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74
> 08 84 c0 0f 8e 92 00 00 00 80 bb 20 07 00 00
> RSP: 0018:8881f58dfd30 EFLAGS: 00010206
> RAX: dc00 RBX: RCX: 82460ca9
> RDX: 00e4 RSI: c900013d3000 RDI: 0720
> RBP: R08: ed103d30caf7 R09:
> R10: R11: R12: dc00
> R13: c1633000 R14: c086b320 R15: 11103eb1bfaf
> FS: 7fa407200700() GS:8881f730() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 001b33924000 CR3: 0001e270c006 CR4: 007606e0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> PKRU: 5554
> Call Trace:
> walkera0701_detach+0x8e/0xba [walkera0701]
> port_detach+0x73/0x90 [parport]
> bus_for_each_dev+0x154/0x1e0 drivers/base/bus.c:304
> parport_unregister_driver+0x1f8/0x270 [parport]
> __do_sys_delete_module kernel/module.c:1018 [inline]
> __se_sys_delete_module kernel/module.c:961 [inline]
> __x64_sys_delete_module+0x30c/0x480 kernel/module.c:961
> do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x462e99
> Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48
> 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73
> 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
> RSP: 002b:7fa4071ffc58 EFLAGS: 0246 ORIG_RAX: 00b0
> RAX: ffda RBX: 0073bf00 RCX: 00462e99
> RDX: RSI: RDI: 21c0
> RBP: 0002 R08: R09:
> R10: R11: 0246 R12: 7fa4072006bc
> R13: 004bcca9 R14: 006f6b48 R15:
> Modules linked in: walkera0701(-) tps65090_regulator intel_th mptbase adm1031
> snd_soc_wm8753 snd_soc_core snd_pcm_dmaengine snd_pcm ac97_bus snd_compress
> rtc_ds1286 snd_seq_dummy snd_seq snd_timer snd_seq_device snd soundcore
> comedi(C) i2c_mux_ltc4306 i2c_mux max14577_regulator max14577 usbcore hid
> cmac mc13783_regulator mc13xxx_regulator_core mc13xxx_core of_mdio fixed_phy
> libphy iptable_security iptable_raw iptable_mangle iptable_nat nf_nat
> nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti
> ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth netdevsim vxcan batman_adv
> cfg80211 rfkill chnl_net caif nlmon dummy team bonding vcan bridge stp llc
> ip6_gre gre ip6_tunnel tunnel6 tun joydev mousedev ppdev tpm kvm_intel kvm
> irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel
> ide_pci_generic aesni_intel aes_x86_64 piix crypto_simd cryptd input_leds
> ide_core psmouse glue_helper intel_agp serio_raw intel_gtt ata_generic
> agpgart i2c_piix4
> pata_acpi parport_pc parport floppy rtc_cmos sch_fq_codel ip_tables x_tables
> sha1_ssse3 sha1_generic ipv6 [last unloaded: walkera0701]
> Dumping ftrace buffer:
>(ftrace buffer empty)
> ---[ end trace 17f6dd401f34af3e ]---
>
> In walkera0701_attach(), if input_allocate_device failed,
> w->input_dev is set to NULL. But in walkera0701_detach it
> is not checked while passing to input_unregister_device(),
> this will trigger a NULL pointer dereference issue.
>
> There is also another possible use-after-free issue, when
> input_register_device() fails, input_free_device be
> called to free input dev, then in walkera0701_detach()
> calling input_unregister_device will trigger use-after-free
> while accessing input dev
>
> This patch set w->parport to NULL on walkera0701_attach failed,
> and only do detach in case attach success.
>
> Reported-by: Hulk Robot
> Fixes: 221bcb24c653 ("Input: walkera0701 - use parallel port device model")
> Signed-off-by: YueHaibing
> ---
> drivers/input/joystick/walkera0701.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/joystick/walkera0701.c
> b/drivers/input/joystick/walkera0701.c
> index dce313d..852b8c5 100644
> --- a/drivers/input/joystick/walkera0701.c
> +++ b/drivers/input/joystick/walkera0701.c
> @@ -207,13 +207,13 @@ static void
Re: [PATCH] arm64: dts: ls1028a: fix watchdog device node
On Thu, May 09, 2019 at 03:06:57PM +0800, Chuanhua Han wrote:
> ls1028a platform uses sp805 watchdog, and use 1/16 platform clock as
> timer clock, this patch fix device tree node.
>
> Signed-off-by: Zhang Ying-22455
> Signed-off-by: Chuanhua Han
> ---
> .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 19 ---
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index b04581249f0b..1510b1858246 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -285,13 +285,18 @@
> #interrupt-cells = <2>;
> };
>
> - wdog0: watchdog@23c {
> - compatible = "fsl,ls1028a-wdt", "fsl,imx21-wdt";
> - reg = <0x0 0x23c 0x0 0x1>;
> - interrupts = ;
> - clocks = < 4 1>;
> - big-endian;
> - status = "disabled";
> + cluster1_core0_watchdog: wdt@c00 {
Keep 'watchdog' as the node name, and keep nodes sort in unit-address.
Shawn
> + compatible = "arm,sp805", "arm,primecell";
> + reg = <0x0 0xc00 0x0 0x1000>;
> + clocks = < 4 15>, < 4 15>;
> + clock-names = "apb_pclk", "wdog_clk";
> + };
> +
> + cluster1_core1_watchdog: wdt@c01 {
> + compatible = "arm,sp805", "arm,primecell";
> + reg = <0x0 0xc01 0x0 0x1000>;
> + clocks = < 4 15>, < 4 15>;
> + clock-names = "apb_pclk", "wdog_clk";
> };
>
> sata: sata@320 {
> --
> 2.17.1
>
Re: [PATCH v2 1/3] dt-bindings: Add pixart vendor
On Tue, Apr 23, 2019 at 5:40 AM Alexandre Mergnat wrote: > > PixArt Imaging Inc. is expertized in CMOS image sensors (CIS), > capacitive touch controllers and related imaging application development. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) I've converted this file to json-schema as of v5.2-rc1. See commit 8122de54602e. Sorry, but you will have to rework this patch. Rob
Re: [PATCH 2/2] add dts file to enable support for ls1046afrwy board.
On Wed, May 08, 2019 at 01:53:10PM +, Pramod Kumar wrote:
> ls1046afrwy board is based on nxp ls1046a SoC.
>
> Signed-off-by: Vabhav Sharma
> Signed-off-by: Pramod Kumar
Please have a subject prefix like 'arm64: dts: ...'
Shawn
> ---
> arch/arm64/boot/dts/freescale/Makefile| 1 +
> .../boot/dts/freescale/fsl-ls1046a-frwy.dts | 156 ++
> 2 files changed, 157 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1046a-frwy.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile
> b/arch/arm64/boot/dts/freescale/Makefile
> index 13604e558dc1..84ff6995b41e 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -8,6 +8,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-rdb.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1043a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1043a-rdb.dtb
> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1046a-frwy.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1046a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1046a-rdb.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-qds.dtb
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-frwy.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1046a-frwy.dts
> new file mode 100644
> index ..de0d19c02944
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-frwy.dts
> @@ -0,0 +1,156 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Device Tree Include file for Freescale Layerscape-1046A family SoC.
> + *
> + * Copyright 2019 NXP.
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "fsl-ls1046a.dtsi"
> +
> +/ {
> + model = "LS1046A FRWY Board";
> + compatible = "fsl,ls1046a-frwy", "fsl,ls1046a";
> +
> + aliases {
> + serial0 =
> + serial1 =
> + serial2 =
> + serial3 =
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + sb_3v3: regulator-sb3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "LT8642SEV-3.3V";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +
> + i2c-mux@77 {
> + compatible = "nxp,pca9546";
> + reg = <0x77>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + i2c-mux-never-disable;
> +
> + i2c@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + eeprom@52 {
> + compatible = "atmel,24c512";
> + reg = <0x52>;
> + };
> +
> + eeprom@53 {
> + compatible = "atmel,24c512";
> + reg = <0x53>;
> + };
> +
> + power-monitor@40 {
> + compatible = "ti,ina220";
> + reg = <0x40>;
> + shunt-resistor = <1000>;
> + };
> +
> + rtc@51 {
> + compatible = "nxp,pcf2129";
> + reg = <0x51>;
> + };
> +
> + temperature-sensor@4c {
> + compatible = "nxp,sa56004";
> + reg = <0x4c>;
> + vcc-supply = <_3v3>;
> + };
> +
> + };
> + };
> +};
> +
> + {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + /* NAND Flash */
> + ranges = <0x0 0x0 0x0 0x7e80 0x0001>;
> + status = "okay";
> +
> + nand@0,0 {
> + compatible = "fsl,ifc-nand";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x0 0x0 0x1>;
> + };
> +
> +};
> +
> +#include "fsl-ls1046-post.dtsi"
> +
> + {
> + ethernet@e {
> + phy-handle = <_phy4>;
> + phy-connection-type = "qsgmii";
> + };
> +
> + ethernet@e8000 {
> + phy-handle = <_phy2>;
> + phy-connection-type = "qsgmii";
> + };
> +
> + ethernet@ea000 {
> + phy-handle = <_phy1>;
> + phy-connection-type = "qsgmii";
> + };
> +
> + ethernet@f2000 {
> + phy-handle = <_phy3>;
> + phy-connection-type = "qsgmii";
> + };
> +
> + mdio@fd000 {
> + qsgmii_phy1: ethernet-phy@1c {
> + reg = <0x1c>;
> + };
> +
>
Re: [PATCH 1/2] dt-bindings: arm: fsl: Add device tree binding for ls1046a-frwy board
On Wed, May 08, 2019 at 01:53:08PM +, Pramod Kumar wrote: > Add "fsl,ls1046a-frwy" bindings for ls1046afrwy board based on ls1046a SoC > > Signed-off-by: Vabhav Sharma > Signed-off-by: Pramod Kumar Sorry. I do not take patch from message using base64 encoding. Shawn > --- > Documentation/devicetree/bindings/arm/fsl.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml > b/Documentation/devicetree/bindings/arm/fsl.yaml > index 7e2cd6ad26bd..873999bf4a43 100644 > --- a/Documentation/devicetree/bindings/arm/fsl.yaml > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml > @@ -205,6 +205,7 @@ properties: >- enum: >- fsl,ls1046a-qds >- fsl,ls1046a-rdb > + - fsl,ls1046a-frwy >- const: fsl,ls1046a > >- description: LS1088A based Boards > -- > 2.17.1 >
Re: [PATCH v2 1/2] dt-bindings: Add vendor prefix for HopeRun
On Wed, May 15, 2019 at 11:35 AM Fabrizio Castro wrote: > > Add "Jiangsu HopeRun Software Co., Ltd." to the list of devicetree > vendor prefixes as "hoperun". > > Website: http://www.hoperun.com/en > > Signed-off-by: Fabrizio Castro > Reviewed-by: Chris Paterson > > --- > v1->v2: > * No change > > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) I've converted this file to json-schema as of v5.2-rc1. See commit 8122de54602e. Sorry, but you will have to rework this patch. Rob
Re: [PATCH v12 3/4] dt-bindings: Add an entry for Purism SPC
On Tue, May 14, 2019 at 8:28 AM Angus Ainslie (Purism) wrote: > > Add an entry for Purism, SPC > > Signed-off-by: Angus Ainslie (Purism) > Reviewed-by: Rob Herring > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) I've converted this file to json-schema as of v5.2-rc1. See commit 8122de54602e. Sorry, but you will have to rework this patch. Rob
Re: [GIT PULL] One more clk change for the merge window
The pull request you sent on Thu, 16 May 2019 16:04:29 -0700: > https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git > tags/clk-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/815d469d8c9a3360ee0a8b7857dd95352a6c7bde Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Kselftest second update for Linux 5.2-rc1
The pull request you sent on Thu, 16 May 2019 15:52:38 -0600: > git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest > tags/linux-kselftest-5.2-rc1-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4c7b63a32d54850a31a00f22131db417face70e4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Devicetree vendor prefix schema for 5.2
The pull request you sent on Thu, 16 May 2019 15:43:27 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git > tags/devicetree-for-5.2-part2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9cbda1bddb4c561f3a7360d36ce13a73bb02bfeb Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] cgroup fix for v5.2-rc1
The pull request you sent on Thu, 16 May 2019 15:38:10 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-5.2-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5f3ab27b9eb7f1b97e6d4460ac4e494588e09f0c Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] RISC-V Patches for the 5.2 Merge Window, Part 1 v2
On Thu, May 16, 2019 at 5:27 PM Palmer Dabbelt wrote: > > > git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git > tags/riscv-for-linus-5.2-mw1 Oh no no no. You're creating a binary file from your build or something like that: > modules.builtin.modinfo| Bin 0 -> 46064 bytes which is completely unacceptable. I have no idea what you're doing, but this kind of "random garbage in git commits" is not going to fly. And the fact that you're adding random files really means that you are doing something *horribly* wrong. Linus
Re: [PATCH v3] arm64: dts: ls1028a: Add USB dt nodes
On Wed, May 08, 2019 at 06:46:37AM +, Ran Wang wrote:
> This patch adds USB dt nodes for LS1028A.
>
> Signed-off-by: Ran Wang
> ---
> Changes in v3:
> - Add space between label and node name.
> - Add spcae with properties and '='.
> - Add SoC specific compatible.
>
> Changes in v2:
> - Rename node from usb3@... to usb@... to meet DTSpec
>
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 20
> 1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 8dd3501..19519df 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -144,6 +144,26 @@
> clocks = <>;
> };
>
> + usb0: usb@310 {
Please sort the nodes with unit-address in the address. That said, it
should go after watchdog@23c.
> + compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
> + reg = <0x0 0x310 0x0 0x1>;
> + interrupts = <0 80 0x4>;
interrupts = ;
Shawn
> + dr_mode = "host";
> + snps,dis_rxdet_inp3_quirk;
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
> + };
> +
> + usb1: usb@311 {
> + compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
> + reg = <0x0 0x311 0x0 0x1>;
> + interrupts = <0 81 0x4>;
> + dr_mode = "host";
> + snps,dis_rxdet_inp3_quirk;
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
> + };
> +
> i2c0: i2c@200 {
> compatible = "fsl,vf610-i2c";
> #address-cells = <1>;
> --
> 1.7.1
>
Re: [PATCH] sched: introduce configurable delay before entering idle
On 2019-05-15 6:07 p.m., Wanpeng Li wrote: On Thu, 16 May 2019 at 02:42, Ankur Arora wrote: On 5/14/19 6:50 AM, Marcelo Tosatti wrote: On Mon, May 13, 2019 at 05:20:37PM +0800, Wanpeng Li wrote: On Wed, 8 May 2019 at 02:57, Marcelo Tosatti wrote: Certain workloads perform poorly on KVM compared to baremetal due to baremetal's ability to perform mwait on NEED_RESCHED bit of task flags (therefore skipping the IPI). KVM supports expose mwait to the guest, if it can solve this? Regards, Wanpeng Li Unfortunately mwait in guest is not feasible (uncompatible with multiple guests). Checking whether a paravirt solution is possible. Hi Marcelo, I was also looking at making MWAIT available to guests in a safe manner: whether through emulation or a PV-MWAIT. My (unsolicited) thoughts MWAIT emulation is not simple, here is a research https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/mwait.html Agreed. I had outlined my attempt to do that below and come to the conclusion that we would need a PV-MWAIT. Ankur Regards, Wanpeng Li follow. We basically want to handle this sequence: monitor(monitor_address); if (*monitor_address == base_value) mwaitx(max_delay); Emulation seems problematic because, AFAICS this would happen: guest hypervisor = monitor(monitor_address); vmexit ===>monitor(monitor_address) if (*monitor_address == base_value) mwait(); vmexit> mwait() There's a context switch back to the guest in this sequence which seems problematic. Both the AMD and Intel specs list system calls and far calls as events which would lead to the MWAIT being woken up: "Voluntary transitions due to fast system call and far calls (occurring prior to issuing MWAIT but after setting the monitor)". We could do this instead: guest hypervisor = monitor(monitor_address); vmexit ===>cache monitor_address if (*monitor_address == base_value) mwait(); vmexit> monitor(monitor_address) mwait() But, this would miss the "if (*monitor_address == base_value)" check in the host which is problematic if *monitor_address changed simultaneously when monitor was executed. (Similar problem if we cache both the monitor_address and *monitor_address.) So, AFAICS, the only thing that would work is the guest offloading the whole PV-MWAIT operation. AFAICS, that could be a paravirt operation which needs three parameters: (monitor_address, base_value, max_delay.) This would allow the guest to offload this whole operation to the host: monitor(monitor_address); if (*monitor_address == base_value) mwaitx(max_delay); I'm guessing you are thinking on similar lines? High level semantics: If the CPU doesn't have any runnable threads, then we actually do this version of PV-MWAIT -- arming a timer if necessary so we only sleep until the time-slice expires or the MWAIT max_delay does. If the CPU has any runnable threads then this could still finish its time-quanta or we could just do a schedule-out. So the semantics guaranteed to the host would be that PV-MWAIT returns after >= max_delay OR with the *monitor_address changed. Ankur
Re: Linux 4.19 and GCC 9
On Thu, May 16, 2019 at 11:20:54PM +0200, Miguel Ojeda wrote: > > mm/slub.o: warning: objtool: init_cache_random_seq()+0x36: sibling > > call from callable instruction with modified stack frame > > mm/slub.o: warning: objtool: slab_out_of_memory()+0x3b: sibling call > > from callable instruction with modified stack frame > > mm/slub.o: warning: objtool: slab_pad_check.part.0()+0x7c: sibling > > call from callable instruction with modified stack frame > > mm/slub.o: warning: objtool: check_slab()+0x1c: sibling call from > > callable instruction with modified stack frame > > AFAIK those are non-critical, i.e. stack traces may be wrong (or not), > but it does not mean the generated kernel itself is wrong. CC'ing the > objtool maintainers too. I don't think I recognize those warnings. Do you also see them in the upstream kernel? -- Josh
Re: [PATCH v6 03/12] dt-binding: gce: add binding for gce subsys property
Hi, Bibby: On Thu, 2019-05-16 at 17:02 +0800, Bibby Hsieh wrote: > tcmdq driver provide a function that get the relationship What is 'tcmdq'? > of sub system number from device node for client. > add specification for #subsys-cells, mediatek,gce-subsys. The property name is mediatek,gce-client-reg. Regards, CK > > Signed-off-by: Bibby Hsieh > --- > .../devicetree/bindings/mailbox/mtk-gce.txt | 15 --- > 1 file changed, 12 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > index 1f7f8f2a3f49..dceab63ccd06 100644 > --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > @@ -21,11 +21,19 @@ Required properties: > priority: Priority of GCE thread. > atomic_exec: GCE processing continuous packets of commands in atomic > way. > +- #subsys-cells: Should be 3. > + < subsys_number start_offset size> > + phandle: Label name of a gce node. > + subsys_number: specify the sub-system id which is corresponding > +to the register address. > + start_offset: the start offset of register address that GCE can access. > + size: the total size of register address that GCE can access. > > Required properties for a client device: > - mboxes: Client use mailbox to communicate with GCE, it should have this >property and list of phandle, mailbox specifiers. > -- mediatek,gce-subsys: u32, specify the sub-system id which is corresponding > +Optional properties for a client device: > +- mediatek,gce-client-reg: u32, specify the sub-system id which is > corresponding >to the register address. > > Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h' > @@ -40,6 +48,7 @@ Example: > clocks = < CLK_INFRA_GCE>; > clock-names = "gce"; > #mbox-cells = <3>; > + #subsys-cells = <3>; > }; > > Example for a client device: > @@ -48,9 +57,9 @@ Example for a client device: > compatible = "mediatek,mt8173-mmsys"; > mboxes = < 0 CMDQ_THR_PRIO_LOWEST 1>, >< 1 CMDQ_THR_PRIO_LOWEST 1>; > - mediatek,gce-subsys = ; > mutex-event-eof =CMDQ_EVENT_MUTEX1_STREAM_EOF>; > - > + mediatek,gce-client-reg = < SUBSYS_1400 0x3000 0x1000>, > + < SUBSYS_1401 0x2000 0x100>; > ... > };
[PATCH] arm64: dts: qcom: sdm845-cheza: add initial cheza dt
From: Rob Clark
This is essentialy a squash of a bunch of history of cheza dt updates
from chromium kernel, some of which were themselves squashes of history
from older chromium kernels.
I don't claim any credit other than wanting to more easily boot upstream
kernel on cheza to have an easier way to test upstream driver work ;-)
I've added below in Cc tags all the original actual authors (apologies
if I missed any).
Cc: Douglas Anderson
Cc: Sibi Sankar
Cc: Evan Green
Cc: Matthias Kaehlcke
Cc: Abhinav Kumar
Cc: Brian Norris
Cc: Venkat Gopalakrishnan
Cc: Rajendra Nayak
Signed-off-by: Rob Clark
---
Updated from review comments and squashed. I left out the the patch
related to deleting gpu_mem/zap_shader nodes as the corresponding
patch that adds them in sdm845.dtsi hasn't landed yet, but once it
has we will need to revisit that patch for cheza.
arch/arm64/boot/dts/qcom/Makefile|3 +
arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts | 238
arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts | 238
arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts | 174 +++
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 1326 ++
5 files changed, 1979 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 21d548f02d39..cf325b263934 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -7,6 +7,9 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8992-bullhead-rev-101.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8994-angler-rev-101.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8998-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r1.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= qcs404-evb-1000.dtb
dtb-$(CONFIG_ARCH_QCOM)+= qcs404-evb-4000.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
b/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
new file mode 100644
index ..bd7c25bb8d35
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Cheza board device tree source
+ *
+ * Copyright 2018 Google LLC.
+ */
+
+/dts-v1/;
+
+#include "sdm845-cheza.dtsi"
+
+/ {
+ model = "Google Cheza (rev1)";
+ compatible = "google,cheza-rev1", "qcom,sdm845";
+
+ /*
+* FIXED REGULATORS (not in sdm845-cheza.dtsi) - parents above children
+*/
+
+ /*
+* NOTE: Technically pp3500_a is not the exact same signal as
+* pp3500_a_vbob (there's a load switch between them and the EC can
+* control pp3500_a via "en_pp3300_a"), but from the AP's point of
+* view they are the same.
+*/
+ pp3500_a:
+ pp3500_a_vbob: pp3500-a-vbob-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_bob";
+
+ /*
+* Comes on automatically when pp5000_ldo comes on, which
+* comes on automatically when ppvar_sys comes on
+*/
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <350>;
+ regulator-max-microvolt = <350>;
+
+ vin-supply = <_sys>;
+ };
+
+ pp3300_dx_edp: pp3300-dx-edp-regulator {
+ /* Yes, it's really 3.5 despite the name of the signal */
+ regulator-min-microvolt = <350>;
+ regulator-max-microvolt = <350>;
+
+ vin-supply = <_a>;
+ };
+};
+
+/* FIXED REGULATOR OVERRIDES (modifications to sdm845-cheza.dtsi) */
+
+/*
+ * L19 and L28 technically go to 3.3V, but most boards have old AOP firmware
+ * that limits them to 3.0, and trying to run at 3.3V with that old firmware
+ * prevents the system from booting.
+ */
+_pp3000_l19a {
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3008000>;
+};
+
+_pp3300_l22a {
+ /delete-property/regulator-boot-on;
+ /delete-property/regulator-always-on;
+};
+
+_pp3300_l28a {
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3008000>;
+};
+
+_vreg_bob {
+ regulator-min-microvolt = <350>;
+ regulator-max-microvolt = <350>;
+ vin-supply = <_a_vbob>;
+};
+
+/*
+ * NON-REGULATOR OVERRIDES
+ * (modifications to sdm845-cheza.dtsi) - alphabetized by dtsi label
+ */
+
+/* PINCTRL - board-specific pinctrl */
+
+ {
+ gpio-line-names = "AP_SPI_FP_MISO",
+ "AP_SPI_FP_MOSI",
+
[PATCH 1/1] LZ4: Port LZ4 1.9.x FAST_DEC_LOOP and enable it on x86 and ARM64
FAST_DEC_LOOP was introduced from LZ4 1.9[1].
This change would be introduce 10% on decompress operation
according to LZ4 benchmark result on X86 devices.
Meanwhile, LZ4 with FAST_DEC_LOOP could get improvements,
however clang compiler has downgrade if FAST_DEC_LOOP enabled.
So FAST_DEC_LOOP only enabled on X86/X86-64 or ARM64 with GCC build.
LZ4 FAST_DEC_LOOP bug fixes include as well.
1. fixed read-after input in LZ4_decompress_safe() (issue 681)
2. Fix out-of-bound read in LZ4_decompress_fast() (issue 676)
PS2:
1. Move common API to lz4defs.h
2. Add PPC related inline Macro defination.
3. Leverge specific LZ4_wildCopy32 for X86 and ARM64
Here is the test result on ARM64(cortex-A53)
Benchmark via ZRAM:
Test case:
fio --bs=32k --randrepeat=1 --randseed=100 --refill_buffers \
--buffer_compress_percentage=75 \
--scramble_buffers=1 --direct=1 --loops=100 --numjobs=8 \
--filename=/dev/block/zram0 --name=seq-write --rw=write --stonewall \
--name=seq-read --rw=read --stonewall --name=seq-readwrite \
--rw=rw --stonewall --name=rand-readwrite --rw=randrw --stonewall
Patched:
READ: bw=8757MiB/s (9182MB/s)
Vanilla:
READ: bw=7765MiB/s (8142MB/s)
[1] https://github.com/lz4/lz4/releases/tag/v1.9.0
Signed-off-by: chenxi.mao
---
lib/lz4/lz4_compress.c | 4 +-
lib/lz4/lz4_decompress.c | 414 ---
lib/lz4/lz4defs.h| 60 +-
lib/lz4/lz4hc_compress.c | 2 +-
4 files changed, 409 insertions(+), 71 deletions(-)
diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c
index cc7b6d4cc7c7..b703ed1ca57d 100644
--- a/lib/lz4/lz4_compress.c
+++ b/lib/lz4/lz4_compress.c
@@ -322,7 +322,7 @@ static FORCE_INLINE int LZ4_compress_generic(
*token = (BYTE)(litLength << ML_BITS);
/* Copy Literals */
- LZ4_wildCopy(op, anchor, op + litLength);
+ LZ4_wildCopy8(op, anchor, op + litLength);
op += litLength;
}
@@ -628,7 +628,7 @@ static int LZ4_compress_destSize_generic(
*token = (BYTE)(litLength << ML_BITS);
/* Copy Literals */
- LZ4_wildCopy(op, anchor, op + litLength);
+ LZ4_wildCopy8(op, anchor, op + litLength);
op += litLength;
}
diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
index 0c9d3ad17e0f..60c134e4699f 100644
--- a/lib/lz4/lz4_decompress.c
+++ b/lib/lz4/lz4_decompress.c
@@ -50,6 +50,113 @@
#define assert(condition) ((void)0)
#endif
+#ifndef LZ4_FAST_DEC_LOOP
+#if defined(__i386__) || defined(__x86_64__)
+#define LZ4_FAST_DEC_LOOP 1
+#elif defined(__aarch64__) && !defined(__clang__)
+ /* On aarch64, we disable this optimization for clang because on certain
+ * mobile chipsets and clang, it reduces performance. For more information
+ * refer to https://github.com/lz4/lz4/pull/707. */
+#define LZ4_FAST_DEC_LOOP 1
+#else
+#define LZ4_FAST_DEC_LOOP 0
+#endif
+#endif
+
+#if LZ4_FAST_DEC_LOOP
+#define FASTLOOP_SAFE_DISTANCE 64
+FORCE_O2_INLINE_GCC_PPC64LE void
+LZ4_memcpy_using_offset_base(BYTE * dstPtr, const BYTE * srcPtr, BYTE * dstEnd,
+const size_t offset)
+{
+ if (offset < 8) {
+ dstPtr[0] = srcPtr[0];
+
+ dstPtr[1] = srcPtr[1];
+ dstPtr[2] = srcPtr[2];
+ dstPtr[3] = srcPtr[3];
+ srcPtr += inc32table[offset];
+ memcpy(dstPtr + 4, srcPtr, 4);
+ srcPtr -= dec64table[offset];
+ dstPtr += 8;
+ } else {
+ memcpy(dstPtr, srcPtr, 8);
+ dstPtr += 8;
+ srcPtr += 8;
+ }
+
+ LZ4_wildCopy8(dstPtr, srcPtr, dstEnd);
+}
+
+/* customized variant of memcpy, which can overwrite up to 32 bytes beyond
dstEnd
+ * this version copies two times 16 bytes (instead of one time 32 bytes)
+ * because it must be compatible with offsets >= 16. */
+FORCE_O2_INLINE_GCC_PPC64LE void
+LZ4_wildCopy32(void *dstPtr, const void *srcPtr, void *dstEnd)
+{
+ BYTE *d = (BYTE *) dstPtr;
+ const BYTE *s = (const BYTE *)srcPtr;
+ BYTE *const e = (BYTE *) dstEnd;
+
+#if defined(__i386__) || defined(__x86_64__)
+ do {
+ memcpy(d, s, 16);
+ memcpy(d + 16, s + 16, 16);
+ d += 32;
+ s += 32;
+ } while (d < e);
+#elif defined(__aarch64__) && !defined(__clang__)
+ do {
+ LZ4_copy8(d, s);
+ d += 8;
+ s += 8;
+ LZ4_copy8(d, s);
+ d += 8;
+ s += 8;
+ LZ4_copy8(d, s);
+ d += 8;
+ s += 8;
+ LZ4_copy8(d, s);
+ d += 8;
+ s += 8;
+ } while (d < e);
+#endif
+}
+
+FORCE_O2_INLINE_GCC_PPC64LE void
+LZ4_memcpy_using_offset(BYTE *dstPtr, const
Re: [PATCH v6 10/12] soc: mediatek: cmdq: add cmdq_dev_get_subsys function
Hi, Bibby:
On Thu, 2019-05-16 at 17:02 +0800, Bibby Hsieh wrote:
> GCE cannot know the register base address, this function
> can help cmdq client to get the relationship of subsys
> and register base address.
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 25 +
> include/linux/soc/mediatek/mtk-cmdq.h | 18 ++
> 2 files changed, 43 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index a53cdd71cfc2..a64060a34e01 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -27,6 +27,31 @@ struct cmdq_instruction {
> u8 op;
> };
>
> +struct cmdq_subsys *cmdq_dev_get_subsys(struct device *dev, int idx)
> +{
> + struct cmdq_subsys *subsys;
> + struct of_phandle_args spec;
> +
> + subsys = devm_kzalloc(dev, sizeof(*subsys), GFP_KERNEL);
> + if (!subsys)
> + return NULL;
> +
> + if (of_parse_phandle_with_args(dev->of_node, "mediatek,gce-client-reg",
> +"#subsys-cells", idx, )) {
> + dev_err(dev, "can't parse gce-client-reg property");
print the idx info.
> +
I think you should free the buffer you allocate. Don't expect this
function is called in caller's probe function.
> + return (struct cmdq_subsys *)-ENODEV;
Why not return NULL?
> + }
> +
> + subsys->id = spec.args[0];
> + subsys->offset = spec.args[1];
> + subsys->size = spec.args[2];
> + of_node_put(spec.np);
> +
> + return subsys;
> +}
> +EXPORT_SYMBOL(cmdq_dev_get_subsys);
> +
> static void cmdq_client_timeout(struct timer_list *t)
> {
> struct cmdq_client *client = from_timer(client, t, timer);
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 0651a0bffa54..574006c5cd76 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -15,6 +15,12 @@
>
> struct cmdq_pkt;
>
> +struct cmdq_subsys {
May be cmdq_client_reg.
> + u8 id;
May be subsys.
Regards,
CK
> + u16 offset;
> + u16 size;
> +};
> +
> struct cmdq_client {
> spinlock_t lock;
> u32 pkt_cnt;
> @@ -142,4 +148,16 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt,
> cmdq_async_flush_cb cb,
> */
> int cmdq_pkt_flush(struct cmdq_pkt *pkt);
>
> +/**
> + * cmdq_dev_get_subsys() - parse sub system from the device node of CMDQ
> client
> + * @dev: device of CMDQ mailbox client
> + * @idx: the index of desired subsys
> + *
> + * Return: CMDQ subsys pointer
> + *
> + * Help CMDQ client pasing the sub system number
> + * from the device node of CMDQ client.
> + */
> +struct cmdq_subsys *cmdq_dev_get_subsys(struct device *dev, int idx);
> +
> #endif /* __MTK_CMDQ_H__ */
Re: [PATCH] arm64: dts: ls1028a: Fix CPU idle fail.
On Tue, May 07, 2019 at 07:43:37AM +, Ran Wang wrote:
> PSCI spec define 1st parameter's bit 16 of function CPU_SUSPEND to
> indicate CPU State Type: 0 for standby, 1 for power down. In this
> case, we want to select standby for CPU idle feature. But current
> setting wrongly select power down and cause CPU SUSPEND fail every
> time. Need this fix.
>
> Signed-off-by: Ran Wang
Do we need a Fixes tag for this?
Shawn
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 18 +-
> 1 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index b045812..bf7f845 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -28,7 +28,7 @@
> enable-method = "psci";
> clocks = < 1 0>;
> next-level-cache = <>;
> - cpu-idle-states = <_PH20>;
> + cpu-idle-states = <_PW20>;
> };
>
> cpu1: cpu@1 {
> @@ -38,7 +38,7 @@
> enable-method = "psci";
> clocks = < 1 0>;
> next-level-cache = <>;
> - cpu-idle-states = <_PH20>;
> + cpu-idle-states = <_PW20>;
> };
>
> l2: l2-cache {
> @@ -53,13 +53,13 @@
>*/
> entry-method = "arm,psci";
>
> - CPU_PH20: cpu-ph20 {
> - compatible = "arm,idle-state";
> - idle-state-name = "PH20";
> - arm,psci-suspend-param = <0x0001>;
> - entry-latency-us = <1000>;
> - exit-latency-us = <1000>;
> - min-residency-us = <3000>;
> + CPU_PW20: cpu-pw20 {
> + compatible = "arm,idle-state";
> + idle-state-name = "PW20";
> + arm,psci-suspend-param = <0x0>;
> + entry-latency-us = <2000>;
> + exit-latency-us = <2000>;
> + min-residency-us = <6000>;
> };
> };
>
> --
> 1.7.1
>
Re: [PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log
On 5/16/19 7:34 AM, Ken Goldman wrote: But outside the client machine this key id is not sufficient to uniquely determine which key the signature corresponds to. Why is this not sufficient? In my implementation, I create a lookup table at the attestation service that maps the 4-byte IMA log key identifier to the signing public key. Are you concerned about collisions? Something else? Yes - the concern is collision. The "Subject Key Identifier" (SKI) for no two certificate can be the same. But since we are using only the last 4 bytes of the SKI it can collide. That's mainly the reason I want to log the entire public key. Are you suggesting that the client supply the verification public key and that the verifier trust it? Wouldn't that make the log self signed? How would the verifier determine that the key from the IMA log is valid / trusted / not revoked from the log itself? IMA log is backed by the TPM. So if the public key is added to the IMA log the attestation service can validate the key information. I am not sure if that answers your question. A minor question here. Are you proposing that the IMA log contain a single ima-sigkey entry per public key followed by ima-sig entries? Or are you proposing that ima-sig be replaced by ima-sigkey, and that each event would contain both the signature and the public key? If the latter, this could add 25M to a server's 100K log. Would that increase in size concern anyone? Could it be a concern on the other end, an IoT device with limited memory? Mimi had raised the same concern. I will update my implementation to include the certification information in the IMA log only once per key - when that key is added to the IMA or Platform keyring. Thanks, -lakshmi
Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
On Thu, May 16, 2019 at 6:06 PM Xing, Cedric wrote: > > > From: Andy Lutomirski [mailto:l...@kernel.org] > > > > On Thu, May 16, 2019 at 3:23 PM Xing, Cedric > > wrote: > > > > > > Hi Andy, > > > > > > > > SIGSTRUCT isn't necessarily stored on disk so may not always have > > a fd. > > > > How about the following? > > > > > void *ss_pointer = mmap(sigstruct_fd, PROT_READ,...); > > > > > ioctl(enclave_fd, SGX_INIT_THE_ENCLAVE, ss_pointer); > > > > > > > > > > The idea here is SIGSTRUCT will still be passed in memory so it > > > > > works > > > > the same way when no LSM modules are loaded or basing its decision > > > > on the .sigstruct file. Otherwise, an LSM module can figure out the > > > > backing file (and offset within that file) by looking into the VMA > > > > covering ss_pointer. > > > > > > > > I don’t love this approach. Application authors seem likely to use > > > > read() instead of mmap(), and it’ll still work in many cares. It > > > > would also complicate the kernel implementation, and looking at the > > > > inode backing the vma that backs a pointer is at least rather > > unusual. > > > > Instead, if the sigstruct isn’t on disk because it’s dynamic or came > > > > from a network, the application can put it in a memfd. > > > > > > I understand your concern here. But I guess we are making too much > > assumption on how enclaves are structured/packaged. My concern is, what > > if a SIGSTRUCT really has to be from memory? For example, an enclave > > (along with its SIGSTRUCT) could be embedded inside a shared object (or > > even the "main" executable) so it shows up in memory to begin with. > > > > Hmm. That's a fair point, although opening /proc/self/exe could be > > somewhat of a workaround. It does suffer from a bit of an in-band > > signaling problem, though, in that it's possible that some other random > > bytes in the library resemble a SIGSTRUCT. > > > > > I was not saying enclaves were exempt to good security practices. What > > I was trying to say was, EPC pages are *not* subject to the same attacks > > as regular pages so I suspect there will be a desire to enforce > > different policies on them, especially after new SGX2 > > features/applications become available. So I think it beneficial to > > distinguish between regular vs. enclave virtual ranges. And to do that, > > a new VM_SGX flag in VMA is probably a very simple/easy way. And with > > that VM_SGX flag, we could add a new security_sgx_mprot() hook so that > > LSM modules/policies could act differently. > > > > I'm not opposed to this, but I also don't think this needs to be in the > > initial upstream driver. VM_SGX also isn't strictly necessary -- an LSM > > could inspect the VMA to decide whether it's an SGX VMA if it really > > wanted to. > > VM_SGX is just what I think is the easiest way for any module to tell enclave > VMAs from all others. I agree totally with you that doesn't have to be in the > initial release! > > > > > That being said, do you have any specific behavior differences in mind > > aside from the oddities involved in loading the enclave. > > The major thing is dynamically linked enclaves. Say if you want something > like dlopen() inside an enclave, the driver would need to EAUG a page as RW > initially, and then change to RX after it has been EACCEPTCOPY'ed by the > enclave. So it's like a RW->RX transition and an LSM module/policy may want > to allow it only if it's within an enclave range (ELRANGE), or deny it > otherwise. I'm not convinced. Given that the kernel has no way to tell that the dynamically loaded code wasn't dynamically generated, I don't think it makes sense to allow this in an enclave but disallow it outside an enclave. > > > > > > > > > And if you are with me on that bigger picture, the next question is: > > what should be the default behavior of security_sgx_mprot() for > > existing/non-SGX-aware LSM modules/policies? I'd say a reasonable > > default is to allow R, RW and RX, but not anything else. It'd suffice to > > get rid of EXECMEM/EXECMOD requirements on enclave applications. For > > SGX1, EPCM permissions are immutable so it really doesn't matter what > > security_sgx_mprot() does. For SGX2 and beyond, there's still time and > > new SGX-aware LSM modules/policies will probably have emerged by then. > > > > I hadn't thought about the SGX1 vs SGX2 difference. If the driver > > initially only wants to support SGX1, then I guess we really could get > > away with constraining the EPC flags based on the source page permission > > and not restricting mprotect() and mmap() permissions on > > /dev/sgx/enclave at all. > > This is exactly what I'm going after! > > But I have to apologize for this silly question because I don't know much > about SELinux: Wouldn't it require changes to existing SELinux policies to > *not* restrict mprotect() on /dev/sgx/enclave? I'm assuming we'd make a small in-kernel change to SELinux to make it work without policy changes, assuming the
linux-next: manual merge of the kvm tree with Linus' tree
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
tools/testing/selftests/kvm/dirty_log_test.c
between commit:
76d58e0f07ec ("KVM: fix KVM_CLEAR_DIRTY_LOG for memory slots of unaligned
size")
from Linus' tree and commit:
65c4189de8c1 ("KVM: fix KVM_CLEAR_DIRTY_LOG for memory slots of unaligned
size")
from the kvm tree.
I fixed it up (the only difference was a comment, so I just used the
former evrsion) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpI8c0_RqcRd.pgp
Description: OpenPGP digital signature
Re: [PATCH RESEND 1/2] ARM: dts: imx6sl: Assign corresponding clocks instead of dummy clock
On Sun, May 12, 2019 at 10:02:10AM +, Anson Huang wrote: > i.MX6SL's KPP and WDOG use IMX6SL_CLK_IPG as clock root, > assign IMX6SL_CLK_IPG to them instead of IMX6SL_CLK_DUMMY. > > Signed-off-by: Anson Huang > Reviewed-by: Dong Aisheng Applied both ,thanks.
Re: [PATCH] igb: add parameter to ignore nvm checksum validation
On Thu, May 16, 2019 at 03:02:18PM -0700, Florian Fainelli wrote: > On 5/16/19 12:55 PM, Nikunj Kela (nkela) wrote: > > > > > > On 5/16/19, 12:35 PM, "Jeff Kirsher" wrote: > > > > On Wed, 2019-05-08 at 23:14 +, Nikunj Kela wrote: > >>> Some of the broken NICs don't have EEPROM programmed correctly. It > >>> results > >>> in probe to fail. This change adds a module parameter that can be > >>> used to > >>> ignore nvm checksum validation. > >>> > >>> Cc: xe-linux-exter...@cisco.com > >>> Signed-off-by: Nikunj Kela > >>> --- > >>> drivers/net/ethernet/intel/igb/igb_main.c | 28 > >>> ++-- > >>> 1 file changed, 22 insertions(+), 6 deletions(-) > > > > >NAK for two reasons. First, module parameters are not desirable > > >because their individual to one driver and a global solution should be > > >found so that all networking device drivers can use the solution. This > > >will keep the interface to change/setup/modify networking drivers > > >consistent for all drivers. > > > > > > >Second and more importantly, if your NIC is broken, fix it. Do not try > > >and create a software workaround so that you can continue to use a > > >broken NIC. There are methods/tools available to properly reprogram > > >the EEPROM on a NIC, which is the right solution for your issue. > > > > I am proposing this as a debug parameter. Obviously, we need to fix EEPROM > > but this helps us continuing the development while manufacturing fixes NIC. > > Then why even bother with sending this upstream? It seems rather drastic to disable the entire driver because the checksum doesn't match. It really should be a warning, even a big warning, to let people know something is wrong, but disabling the whole driver doesn't make sense. Daniel
linux-next: manual merge of the kvm tree with Linus' tree
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
arch/x86/kvm/paging_tmpl.h
between commit:
73b0140bf0fe ("mm/gup: change GUP fast to use flags rather than a write
'bool'")
from Linus' tree and commit:
bd53cb35a3e9 ("X86/KVM: Handle PFNs outside of kernel reach when touching
GPTEs")
from the kvm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/kvm/paging_tmpl.h
index 08715034e315,c40af67d0f44..
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@@ -140,16 -140,36 +140,36 @@@ static int FNAME(cmpxchg_gpte)(struct k
pt_element_t *table;
struct page *page;
- npages = get_user_pages_fast((unsigned long)ptep_user, 1, 1, );
+ npages = get_user_pages_fast((unsigned long)ptep_user, 1, FOLL_WRITE,
);
- /* Check if the user is doing something meaningless. */
- if (unlikely(npages != 1))
- return -EFAULT;
-
- table = kmap_atomic(page);
- ret = CMPXCHG([index], orig_pte, new_pte);
- kunmap_atomic(table);
-
- kvm_release_page_dirty(page);
+ if (likely(npages == 1)) {
+ table = kmap_atomic(page);
+ ret = CMPXCHG([index], orig_pte, new_pte);
+ kunmap_atomic(table);
+
+ kvm_release_page_dirty(page);
+ } else {
+ struct vm_area_struct *vma;
+ unsigned long vaddr = (unsigned long)ptep_user & PAGE_MASK;
+ unsigned long pfn;
+ unsigned long paddr;
+
+ down_read(>mm->mmap_sem);
+ vma = find_vma_intersection(current->mm, vaddr, vaddr +
PAGE_SIZE);
+ if (!vma || !(vma->vm_flags & VM_PFNMAP)) {
+ up_read(>mm->mmap_sem);
+ return -EFAULT;
+ }
+ pfn = ((vaddr - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
+ paddr = pfn << PAGE_SHIFT;
+ table = memremap(paddr, PAGE_SIZE, MEMREMAP_WB);
+ if (!table) {
+ up_read(>mm->mmap_sem);
+ return -EFAULT;
+ }
+ ret = CMPXCHG([index], orig_pte, new_pte);
+ memunmap(table);
+ up_read(>mm->mmap_sem);
+ }
return (ret != orig_pte);
}
pgppVgAY1o2Br.pgp
Description: OpenPGP digital signature
RE: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
> From: Andy Lutomirski [mailto:l...@kernel.org] > > On Thu, May 16, 2019 at 3:23 PM Xing, Cedric > wrote: > > > > Hi Andy, > > > > > > SIGSTRUCT isn't necessarily stored on disk so may not always have > a fd. > > > How about the following? > > > > void *ss_pointer = mmap(sigstruct_fd, PROT_READ,...); > > > > ioctl(enclave_fd, SGX_INIT_THE_ENCLAVE, ss_pointer); > > > > > > > > The idea here is SIGSTRUCT will still be passed in memory so it > > > > works > > > the same way when no LSM modules are loaded or basing its decision > > > on the .sigstruct file. Otherwise, an LSM module can figure out the > > > backing file (and offset within that file) by looking into the VMA > > > covering ss_pointer. > > > > > > I don’t love this approach. Application authors seem likely to use > > > read() instead of mmap(), and it’ll still work in many cares. It > > > would also complicate the kernel implementation, and looking at the > > > inode backing the vma that backs a pointer is at least rather > unusual. > > > Instead, if the sigstruct isn’t on disk because it’s dynamic or came > > > from a network, the application can put it in a memfd. > > > > I understand your concern here. But I guess we are making too much > assumption on how enclaves are structured/packaged. My concern is, what > if a SIGSTRUCT really has to be from memory? For example, an enclave > (along with its SIGSTRUCT) could be embedded inside a shared object (or > even the "main" executable) so it shows up in memory to begin with. > > Hmm. That's a fair point, although opening /proc/self/exe could be > somewhat of a workaround. It does suffer from a bit of an in-band > signaling problem, though, in that it's possible that some other random > bytes in the library resemble a SIGSTRUCT. > > > I was not saying enclaves were exempt to good security practices. What > I was trying to say was, EPC pages are *not* subject to the same attacks > as regular pages so I suspect there will be a desire to enforce > different policies on them, especially after new SGX2 > features/applications become available. So I think it beneficial to > distinguish between regular vs. enclave virtual ranges. And to do that, > a new VM_SGX flag in VMA is probably a very simple/easy way. And with > that VM_SGX flag, we could add a new security_sgx_mprot() hook so that > LSM modules/policies could act differently. > > I'm not opposed to this, but I also don't think this needs to be in the > initial upstream driver. VM_SGX also isn't strictly necessary -- an LSM > could inspect the VMA to decide whether it's an SGX VMA if it really > wanted to. VM_SGX is just what I think is the easiest way for any module to tell enclave VMAs from all others. I agree totally with you that doesn't have to be in the initial release! > > That being said, do you have any specific behavior differences in mind > aside from the oddities involved in loading the enclave. The major thing is dynamically linked enclaves. Say if you want something like dlopen() inside an enclave, the driver would need to EAUG a page as RW initially, and then change to RX after it has been EACCEPTCOPY'ed by the enclave. So it's like a RW->RX transition and an LSM module/policy may want to allow it only if it's within an enclave range (ELRANGE), or deny it otherwise. > > > > > And if you are with me on that bigger picture, the next question is: > what should be the default behavior of security_sgx_mprot() for > existing/non-SGX-aware LSM modules/policies? I'd say a reasonable > default is to allow R, RW and RX, but not anything else. It'd suffice to > get rid of EXECMEM/EXECMOD requirements on enclave applications. For > SGX1, EPCM permissions are immutable so it really doesn't matter what > security_sgx_mprot() does. For SGX2 and beyond, there's still time and > new SGX-aware LSM modules/policies will probably have emerged by then. > > I hadn't thought about the SGX1 vs SGX2 difference. If the driver > initially only wants to support SGX1, then I guess we really could get > away with constraining the EPC flags based on the source page permission > and not restricting mprotect() and mmap() permissions on > /dev/sgx/enclave at all. This is exactly what I'm going after! But I have to apologize for this silly question because I don't know much about SELinux: Wouldn't it require changes to existing SELinux policies to *not* restrict mprotect() on /dev/sgx/enclave? -Cedric
linux-next: manual merge of the kvm tree with Linus' tree
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
Documentation/virtual/kvm/api.txt
between commit:
dbcdae185a70 ("Documentation: kvm: fix dirty log ioctl arch lists")
from Linus' tree and commit:
d7547c55cbe7 ("KVM: Introduce KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2")
from the kvm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/virtual/kvm/api.txt
index 64b38dfcc243,73a501eb9291..
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@@ -3809,8 -3936,8 +3936,8 @@@ to I/O ports
4.117 KVM_CLEAR_DIRTY_LOG (vm ioctl)
- Capability: KVM_CAP_MANUAL_DIRTY_LOG_PROTECT
+ Capability: KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2
-Architectures: x86
+Architectures: x86, arm, arm64, mips
Type: vm ioctl
Parameters: struct kvm_dirty_log (in)
Returns: 0 on success, -1 on error
@@@ -4798,9 -4968,9 +4968,9 @@@ and injected exceptions
* For the new DR6 bits, note that bit 16 is set iff the #DB exception
will clear DR6.RTM.
- 7.18 KVM_CAP_MANUAL_DIRTY_LOG_PROTECT
+ 7.18 KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2
-Architectures: all
+Architectures: x86, arm, arm64, mips
Parameters: args[0] whether feature should be enabled or not
With this capability enabled, KVM_GET_DIRTY_LOG will not automatically
pgpS7iqmXBAM2.pgp
Description: OpenPGP digital signature
[PATCH] libnvdimm/pmem: Bypass CONFIG_HARDENED_USERCOPY overhead
Jeff discovered that performance improves from ~375K iops to ~519K iops
on a simple psync-write fio workload when moving the location of 'struct
page' from the default PMEM location to DRAM. This result is surprising
because the expectation is that 'struct page' for dax is only needed for
third party references to dax mappings. For example, a dax-mapped buffer
passed to another system call for direct-I/O requires 'struct page' for
sending the request down the driver stack and pinning the page. There is
no usage of 'struct page' for first party access to a file via
read(2)/write(2) and friends.
However, this "no page needed" expectation is violated by
CONFIG_HARDENED_USERCOPY and the check_copy_size() performed in
copy_from_iter_full_nocache() and copy_to_iter_mcsafe(). The
check_heap_object() helper routine assumes the buffer is backed by a
page-allocator DRAM page and applies some checks. Those checks are
invalid, dax pages are not from the heap, and redundant,
dax_iomap_actor() has already validated that the I/O is within bounds.
Bypass this overhead and call the 'no check' versions of the
copy_{to,from}_iter operations directly.
Fixes: 0aed55af8834 ("x86, uaccess: introduce copy_from_iter_flushcache...")
Cc: Jan Kara
Cc:
Cc: Jeff Moyer
Cc: Ingo Molnar
Cc: Christoph Hellwig
Cc: Al Viro
Cc: Thomas Gleixner
Cc: Matthew Wilcox
Reported-and-tested-by: Jeff Smits
Signed-off-by: Dan Williams
---
drivers/nvdimm/pmem.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 845c5b430cdd..c894f45e5077 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -281,16 +281,21 @@ static long pmem_dax_direct_access(struct dax_device
*dax_dev,
return __pmem_direct_access(pmem, pgoff, nr_pages, kaddr, pfn);
}
+/*
+ * Use the 'no check' versions of copy_from_iter_flushcache() and
+ * copy_to_iter_mcsafe() to bypass HARDENED_USERCOPY overhead. Bounds
+ * checking is handled by dax_iomap_actor()
+ */
static size_t pmem_copy_from_iter(struct dax_device *dax_dev, pgoff_t pgoff,
void *addr, size_t bytes, struct iov_iter *i)
{
- return copy_from_iter_flushcache(addr, bytes, i);
+ return _copy_from_iter_flushcache(addr, bytes, i);
}
static size_t pmem_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff,
void *addr, size_t bytes, struct iov_iter *i)
{
- return copy_to_iter_mcsafe(addr, bytes, i);
+ return _copy_to_iter_mcsafe(addr, bytes, i);
}
static const struct dax_operations pmem_dax_ops = {
Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
On Thu, May 16, 2019 at 3:23 PM Xing, Cedric wrote: > > Hi Andy, > > > > SIGSTRUCT isn't necessarily stored on disk so may not always have a fd. > > How about the following? > > > void *ss_pointer = mmap(sigstruct_fd, PROT_READ,...); > > > ioctl(enclave_fd, SGX_INIT_THE_ENCLAVE, ss_pointer); > > > > > > The idea here is SIGSTRUCT will still be passed in memory so it works > > the same way when no LSM modules are loaded or basing its decision on > > the .sigstruct file. Otherwise, an LSM module can figure out the backing > > file (and offset within that file) by looking into the VMA covering > > ss_pointer. > > > > I don’t love this approach. Application authors seem likely to use > > read() instead of mmap(), and it’ll still work in many cares. It would > > also complicate the kernel implementation, and looking at the inode > > backing the vma that backs a pointer is at least rather unusual. > > Instead, if the sigstruct isn’t on disk because it’s dynamic or came > > from a network, the application can put it in a memfd. > > I understand your concern here. But I guess we are making too much assumption > on how enclaves are structured/packaged. My concern is, what if a SIGSTRUCT > really has to be from memory? For example, an enclave (along with its > SIGSTRUCT) could be embedded inside a shared object (or even the "main" > executable) so it shows up in memory to begin with. Hmm. That's a fair point, although opening /proc/self/exe could be somewhat of a workaround. It does suffer from a bit of an in-band signaling problem, though, in that it's possible that some other random bytes in the library resemble a SIGSTRUCT. > I was not saying enclaves were exempt to good security practices. What I was > trying to say was, EPC pages are *not* subject to the same attacks as regular > pages so I suspect there will be a desire to enforce different policies on > them, especially after new SGX2 features/applications become available. So I > think it beneficial to distinguish between regular vs. enclave virtual > ranges. And to do that, a new VM_SGX flag in VMA is probably a very > simple/easy way. And with that VM_SGX flag, we could add a new > security_sgx_mprot() hook so that LSM modules/policies could act differently. I'm not opposed to this, but I also don't think this needs to be in the initial upstream driver. VM_SGX also isn't strictly necessary -- an LSM could inspect the VMA to decide whether it's an SGX VMA if it really wanted to. That being said, do you have any specific behavior differences in mind aside from the oddities involved in loading the enclave. > > And if you are with me on that bigger picture, the next question is: what > should be the default behavior of security_sgx_mprot() for > existing/non-SGX-aware LSM modules/policies? I'd say a reasonable default is > to allow R, RW and RX, but not anything else. It'd suffice to get rid of > EXECMEM/EXECMOD requirements on enclave applications. For SGX1, EPCM > permissions are immutable so it really doesn't matter what > security_sgx_mprot() does. For SGX2 and beyond, there's still time and new > SGX-aware LSM modules/policies will probably have emerged by then. I hadn't thought about the SGX1 vs SGX2 difference. If the driver initially only wants to support SGX1, then I guess we really could get away with constraining the EPC flags based on the source page permission and not restricting mprotect() and mmap() permissions on /dev/sgx/enclave at all.
[GIT PULL] RISC-V Patches for the 5.2 Merge Window, Part 1 v2
The following changes since commit 085b7755808aa11f78ab9377257e1dad2e6fa4bb:
Linux 5.1-rc6 (2019-04-21 10:45:57 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git
tags/riscv-for-linus-5.2-mw1
for you to fetch changes up to 81eba518d95f43d9f81ed5eb6dd9edb4179687aa:
RISC-V: sifive_l2_cache: Add L2 cache controller driver for SiFive SoCs
(2019-05-15 18:40:14 -0700)
RISC-V Patches for the 5.2 Merge Window, Part 1 v2
This patch set contains an assortment of RISC-V related patches that I'd
like to target for the 5.2 merge window. Most of the patches are
cleanups, but there are a handful of user-visible changes:
* The nosmp and nr_cpus command-line arguments are now supported, which
work like normal.
* The SBI console no longer installs itself as a preferred console, we
rely on standard mechanisms (/chosen, command-line, hueristics)
instead.
* sfence_remove_sfence_vma{,_asid} now pass their arguments along to the
SBI call.
* Modules now support BUG().
* A missing sfence.vma during boot has been added. This bug only
manifests during boot.
* The arch/riscv support for SiFive's L2 cache controller has been
merged, which should un-block the EDAC framework work.
I've only tested this on QEMU again, as I didn't have time to get things
running on the Unleashed. The latest master from this morning merges in
cleanly and passes the tests as well.
This patch set rebased my "5.2 MW, Part 1" patch set which includes an
erronous empty file. That patch set has not been merged.
Anup Patel (4):
RISC-V: Use tabs to align macro values in asm/csr.h
RISC-V: Add interrupt related SCAUSE defines in asm/csr.h
RISC-V: Access CSRs using CSR numbers
tty: Don't force RISCV SBI console as preferred console
Atish Patra (4):
RISC-V: Add RISC-V specific arch_match_cpu_phys_id
RISC-V: Implement nosmp commandline option.
RISC-V: Support nr_cpus command line option.
RISC-V: Fix minor checkpatch issues.
Christoph Hellwig (11):
riscv: use asm-generic/extable.h
riscv: turn mm_segment_t into a struct
riscv: remove unreachable big endian code
riscv: remove CONFIG_RISCV_ISA_A
riscv: clear all pending interrupts when booting
riscv: simplify the stack pointer setup in head.S
riscv: cleanup the parse_dtb calling conventions
riscv: remove unreachable !HAVE_FUNCTION_GRAPH_RET_ADDR_PTR code
riscv: remove duplicate macros from ptrace.h
riscv: print the unexpected interrupt cause
riscv: call pm_power_off from machine_halt / machine_power_off
Gary Guo (3):
riscv: move flush_icache_{all,mm} to cacheflush.c
riscv: move switch_mm to its own file
riscv: fix sbi_remote_sfence_vma{,_asid}.
Guo Ren (1):
riscv/signal: Fixup additional syscall restarting
Nick Desaulniers (1):
riscv: vdso: drop unnecessary cc-ldoption
Palmer Dabbelt (1):
RISC-V: Avoid using invalid intermediate translations
Vincent Chen (3):
riscv: support trap-based WARN()
riscv: Add the support for c.ebreak check in is_valid_bugaddr()
riscv: Support BUG() in kernel module
Yash Shah (2):
RISC-V: Add DT documentation for SiFive L2 Cache Controller
RISC-V: sifive_l2_cache: Add L2 cache controller driver for SiFive SoCs
.../devicetree/bindings/riscv/sifive-l2-cache.txt | 51 ++
arch/riscv/Kconfig | 6 +-
arch/riscv/Makefile| 5 +-
arch/riscv/include/asm/Kbuild | 1 +
arch/riscv/include/asm/bug.h | 35 +++--
arch/riscv/include/asm/cacheflush.h| 2 +-
arch/riscv/include/asm/csr.h | 123 +--
arch/riscv/include/asm/elf.h | 6 -
arch/riscv/include/asm/futex.h | 13 --
arch/riscv/include/asm/irqflags.h | 10 +-
arch/riscv/include/asm/mmu_context.h | 59 +--
arch/riscv/include/asm/ptrace.h| 21 +--
arch/riscv/include/asm/sbi.h | 19 ++-
arch/riscv/include/asm/sifive_l2_cache.h | 16 ++
arch/riscv/include/asm/thread_info.h | 4 +-
arch/riscv/include/asm/uaccess.h | 28 ++--
arch/riscv/kernel/asm-offsets.c| 3 -
arch/riscv/kernel/cpu.c| 3 +-
arch/riscv/kernel/entry.S | 22 +--
arch/riscv/kernel/head.S | 33 ++--
arch/riscv/kernel/irq.c| 19 +--
arch/riscv/kernel/perf_event.c | 4 +-
arch/riscv/kernel/reset.c | 15 +-
arch/riscv/kernel/setup.c | 6 +-
Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
On Thu, May 16, 2019 at 5:03 PM Sean Christopherson wrote: > > On Wed, May 15, 2019 at 11:27:04AM -0700, Andy Lutomirski wrote: > > Here's a very vague proposal that's kind of like what I've been > > thinking over the past few days. The SGX inode could track, for each > > page, a "safe-to-execute" bit. When you first open /dev/sgx/enclave, > > you get a blank enclave and all pages are safe-to-execute. When you > > do the ioctl to load context (which could be code, data, or anything > > else), the kernel will check whether the *source* VMA is executable > > and, if not, mark the page of the enclave being loaded as unsafe. > > Once the enclave is initialized, the driver will clear the > > safe-to-execute bit for any page that is successfully mapped writably. > > > > The intent is that a page of the enclave is safe-to-execute if that > > page was populated from executable memory and not modified since then. > > LSMs could then enforce a policy that you can map an enclave page RX > > if the page is safe-to-execute, you can map any page you want for > > write if there are no executable mappings, and you can only map a page > > for write and execute simultaneously if you can EXECMOD permission. > > This should allow an enclave to be loaded by userspace from a file > > with EXECUTE rights. > > I'm still confused as to why you want to track execute permissions on the > enclave pages and add SGX-specific LSM hooks. Is there anything that > prevents userspace from building the enclave like any other DSO and then > copying it into enclave memory? It's entirely possible that I'm the one missing something. But here's why I think this: > I feel like I'm missing something. > > 1. Userspace loads enclave into regular memory, e.g. like a normal DSO. > All mmap(), mprotect(), etc... calls are subject to all existing > LSM policies. > > 2. Userspace opens /dev/sgx/enclave to instantiate a new enclave. > > 3. Userspace uses mmap() to allocate virtual memory for its enclave, > again subject to all existing LSM policies (sane userspaces map it RO > since the permissions eventually get tossed anyways). Is userspace actually requred to mmap() the enclave prior to EADDing things? > > 4. SGX subsystem refuses to service page faults for enclaves that have > not yet been initialized, e.g. signals SIGBUS or SIGSEGV. > > 5. Userspace invokes SGX ioctl() to copy enclave from regulary VMA to > enclave VMA. > > 6. SGX ioctl() propagates VMA protection-related flags from source VMA > to enclave VMA, e.g. invokes mprotect_fixup(). Enclave VMA(s) may > be split as part of this process. Does this also call the LSM? If so, what is it expected to do? What happens if there are different regions with different permissions on the same page? SGX has 256-byte granularity right? > > 7. At all times, mprotect() calls on the enclave VMA are subject to > existing LSM policies, i.e. it's not special cased for enclaves. I don't think the normal behavior actually works here. An enclave is always MAP_SHARED, so (with SELinux) mprotecting() to X or RX requires EXECUTE and mprotecting() to RWX requires extra permissions. But user code can also mmap() the enclave again. What is supposed to happen in that case?
Re: [GIT PULL] Ceph updates for 5.2-rc1
The pull request you sent on Thu, 16 May 2019 17:40:05 +0200: > https://github.com/ceph/ceph-client.git tags/ceph-for-5.2-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1d9d7cbf28a1c2f84f2a0224466f8eb5f0a62ace Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] afs: Fix callback promise handling
The pull request you sent on Fri, 17 May 2019 00:02:04 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > tags/afs-fixes-b-20190516 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0d74471924f2a01dcd32d154510c0500780b531a Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] afs: Miscellaneous fixes
The pull request you sent on Fri, 17 May 2019 00:00:21 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > tags/afs-fixes-20190516 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fefb2483dc10c736e4235984fed4f3a61c99e1c2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] afs: Miscellaneous fixes
On Thu, May 16, 2019 at 4:00 PM David Howells wrote: > > Could you pull this series please? I've pulled this, but I'm seriously considering just stopping pulling from you entirely. Not only is this late in the merge window, EVERY SINGLE commit I pulled from you is from within a day or two. And this is not a new thing. I literally dread stuff from you. Because it's happened before, and it keeps happening. Out-of-window changes to the keys layer etc etc. Why does this keep happening? Linus
Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
On Wed, May 15, 2019 at 11:27:04AM -0700, Andy Lutomirski wrote: > Here's a very vague proposal that's kind of like what I've been > thinking over the past few days. The SGX inode could track, for each > page, a "safe-to-execute" bit. When you first open /dev/sgx/enclave, > you get a blank enclave and all pages are safe-to-execute. When you > do the ioctl to load context (which could be code, data, or anything > else), the kernel will check whether the *source* VMA is executable > and, if not, mark the page of the enclave being loaded as unsafe. > Once the enclave is initialized, the driver will clear the > safe-to-execute bit for any page that is successfully mapped writably. > > The intent is that a page of the enclave is safe-to-execute if that > page was populated from executable memory and not modified since then. > LSMs could then enforce a policy that you can map an enclave page RX > if the page is safe-to-execute, you can map any page you want for > write if there are no executable mappings, and you can only map a page > for write and execute simultaneously if you can EXECMOD permission. > This should allow an enclave to be loaded by userspace from a file > with EXECUTE rights. I'm still confused as to why you want to track execute permissions on the enclave pages and add SGX-specific LSM hooks. Is there anything that prevents userspace from building the enclave like any other DSO and then copying it into enclave memory? I feel like I'm missing something. 1. Userspace loads enclave into regular memory, e.g. like a normal DSO. All mmap(), mprotect(), etc... calls are subject to all existing LSM policies. 2. Userspace opens /dev/sgx/enclave to instantiate a new enclave. 3. Userspace uses mmap() to allocate virtual memory for its enclave, again subject to all existing LSM policies (sane userspaces map it RO since the permissions eventually get tossed anyways). 4. SGX subsystem refuses to service page faults for enclaves that have not yet been initialized, e.g. signals SIGBUS or SIGSEGV. 5. Userspace invokes SGX ioctl() to copy enclave from regulary VMA to enclave VMA. 6. SGX ioctl() propagates VMA protection-related flags from source VMA to enclave VMA, e.g. invokes mprotect_fixup(). Enclave VMA(s) may be split as part of this process. 7. At all times, mprotect() calls on the enclave VMA are subject to existing LSM policies, i.e. it's not special cased for enclaves. The SGX ioctl() would need to take mmap_sem for write, but we can mitigate that issue by changing the ioctl() to take a range of memory instead of a single page. That'd also provide "EADD batching" that folks have requested.
Re: [PATCH v2 0/6] mm/devm_memremap_pages: Fix page release race
On 5/16/2019 2:51 PM, Dan Williams wrote: On Thu, May 16, 2019 at 9:45 AM Jane Chu wrote: Hi, I'm able to reproduce the panic below by running two sets of ndctl commands that actually serve legitimate purpose in parallel (unlike the brute force experiment earlier), each set in a indefinite loop. This time it takes about an hour to panic. But I gather the cause is probably the same: I've overlapped ndctl commands on the same region. Could we add a check in nd_ioctl(), such that if there is an ongoing ndctl command on a region, subsequent ndctl request will fail immediately with something to the effect of EAGAIN? The rationale being that kernel should protect itself against user mistakes. We do already have locking in the driver to prevent configuration collisions. The problem looks to be broken assumptions about running the device unregistration path in a separate thread outside the lock. I suspect it may be incorrect assumptions about the userspace visibility of the device relative to teardown actions. To be clear this isn't the nd_ioctl() path this is the sysfs path. I see, thanks! Also, sensing the subject fix is for a different problem, and has been verified, I'm happy to see it in upstream, so we have a better code base to digger deeper in terms of how the destructive ndctl commands interacts to typical mission critical applications, include but not limited to rdma. Right, the crash signature you are seeing looks unrelated to the issue being address in these patches which is device-teardown racing active page pins. I'll start the investigation on the crash signature, but again I don't think it reads on this fix series. Agreed on investigating the crash as separate issue, looking forward to see this patchset in upstream. Thanks! -jane
Re: [GIT PULL] locking fix
On Thu, May 16, 2019 at 11:42:58AM -0700, Linus Torvalds wrote:
On Thu, May 16, 2019 at 11:39 AM Greg KH wrote:
Thanks, I'll work on that later tonight...
Note that it probably is almost entirely impossible to trigger the
problem in practice, so it's not like this is a particularly important
stable back-port.
I just happened to look at it and go "hmm, it's not _marked_ for stable".
I've addressed a missing a8654596f03 ("locking/rwsem: Enable lock event
counting") and queued up a backport for 5.1-4.9.
--
Thanks,
Sasha
Getting empty callchain from perf_callchain_kernel()
Hi,
We found a failure with selftests/bpf/tests_prog in test_stacktrace_map (on
bpf/master
branch).
After digging into the code, we found that perf_callchain_kernel() is giving
empty
callchain for tracepoint sched/sched_switch. And it seems related to commit
d15d356887e770c5f2dcf963b52c7cb510c9e42d
("perf/x86: Make perf callchains work without CONFIG_FRAME_POINTER")
Before this commit, perf_callchain_kernel() returns callchain with regs->ip.
With
this commit, regs->ip is not sent for !perf_hw_regs(regs) case.
I found the following change fixes the selftest. But I am not very sure, it is
the best solution here.
Please share comments and suggestions on this.
Thanks in advance!
Song
diff --git i/arch/x86/events/core.c w/arch/x86/events/core.c
index f315425d8468..7b8a9eb4d5fd 100644
--- i/arch/x86/events/core.c
+++ w/arch/x86/events/core.c
@@ -2402,9 +2402,9 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx
*entry, struct pt_regs *re
return;
}
+ if (perf_callchain_store(entry, regs->ip))
+ return;
if (perf_hw_regs(regs)) {
- if (perf_callchain_store(entry, regs->ip))
- return;
unwind_start(, current, regs, NULL);
} else {
unwind_start(, current, NULL, (void *)regs->sp);
[PATCHv3 1/3] vfio/mdev: Improve the create/remove sequence
This patch addresses below two issues and prepares the code to address
3rd issue listed below.
1. mdev device is placed on the mdev bus before it is created in the
vendor driver. Once a device is placed on the mdev bus without creating
its supporting underlying vendor device, mdev driver's probe() gets triggered.
However there isn't a stable mdev available to work on.
create_store()
mdev_create_device()
device_register()
...
vfio_mdev_probe()
[...]
parent->ops->create()
vfio_ap_mdev_create()
mdev_set_drvdata(mdev, matrix_mdev);
/* Valid pointer set above */
Due to this way of initialization, mdev driver who wants to use the mdev,
doesn't have a valid mdev to work on.
2. Current creation sequence is,
parent->ops_create()
groups_register()
Remove sequence is,
parent->ops->remove()
groups_unregister()
However, remove sequence should be exact mirror of creation sequence.
Once this is achieved, all users of the mdev will be terminated first
before removing underlying vendor device.
(Follow standard linux driver model).
At that point vendor's remove() ops shouldn't fail because taking the
device off the bus should terminate any usage.
3. When remove operation fails, mdev sysfs removal attempts to add the
file back on already removed device. Following call trace [1] is observed.
[1] call trace:
kernel: WARNING: CPU: 2 PID: 9348 at fs/sysfs/file.c:327
sysfs_create_file_ns+0x7f/0x90
kernel: CPU: 2 PID: 9348 Comm: bash Kdump: loaded Not tainted
5.1.0-rc6-vdevbus+ #6
kernel: Hardware name: Supermicro SYS-6028U-TR4+/X10DRU-i+, BIOS 2.0b 08/09/2016
kernel: RIP: 0010:sysfs_create_file_ns+0x7f/0x90
kernel: Call Trace:
kernel: remove_store+0xdc/0x100 [mdev]
kernel: kernfs_fop_write+0x113/0x1a0
kernel: vfs_write+0xad/0x1b0
kernel: ksys_write+0x5a/0xe0
kernel: do_syscall_64+0x5a/0x210
kernel: entry_SYSCALL_64_after_hwframe+0x49/0xbe
Therefore, mdev core is improved in following ways.
1. Split the device registration/deregistration sequence so that some
things can be done between initialization of the device and
hooking it up to the bus respectively after deregistering it
from the bus but before giving up our final reference.
In particular, this means invoking the ->create and ->remove
callbacks in those new windows. This gives the vendor driver an
initialized mdev device to work with during creation.
At the same time, a bus driver who wish to bind to mdev driver also
gets initialized mdev device.
This follows standard Linux kernel bus and device model.
2. During remove flow, first remove the device from the bus. This
ensures that any bus specific devices are removed.
Once device is taken off the mdev bus, invoke remove() of mdev
from the vendor driver.
3. The driver core device model provides way to register and auto
unregister the device sysfs attribute groups at dev->groups.
Make use of dev->groups to let core create the groups and eliminate
code to avoid explicit groups creation and removal.
To ensure, that new sequence is solid, a below stack dump of a
process is taken who attempts to remove the device while device is in
use by vfio driver and user application.
This stack dump validates that vfio driver guards against such device
removal when device is in use.
cat /proc/21962/stack
[<0>] vfio_del_group_dev+0x216/0x3c0 [vfio]
[<0>] mdev_remove+0x21/0x40 [mdev]
[<0>] device_release_driver_internal+0xe8/0x1b0
[<0>] bus_remove_device+0xf9/0x170
[<0>] device_del+0x168/0x350
[<0>] mdev_device_remove_common+0x1d/0x50 [mdev]
[<0>] mdev_device_remove+0x8c/0xd0 [mdev]
[<0>] remove_store+0x71/0x90 [mdev]
[<0>] kernfs_fop_write+0x113/0x1a0
[<0>] vfs_write+0xad/0x1b0
[<0>] ksys_write+0x5a/0xe0
[<0>] do_syscall_64+0x5a/0x210
[<0>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[<0>] 0x
This prepares the code to eliminate calling device_create_file() in
subsquent patch.
Signed-off-by: Parav Pandit
---
drivers/vfio/mdev/mdev_core.c| 94 +---
drivers/vfio/mdev/mdev_private.h | 2 +-
drivers/vfio/mdev/mdev_sysfs.c | 2 +-
3 files changed, 27 insertions(+), 71 deletions(-)
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 3cc1a05fde1c..0bef0cae1d4b 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -102,55 +102,10 @@ static void mdev_put_parent(struct mdev_parent *parent)
kref_put(>ref, mdev_release_parent);
}
-static int mdev_device_create_ops(struct kobject *kobj,
- struct mdev_device *mdev)
-{
- struct mdev_parent *parent = mdev->parent;
- int ret;
-
- ret = parent->ops->create(kobj, mdev);
- if (ret)
- return ret;
-
- ret = sysfs_create_groups(>dev.kobj,
- parent->ops->mdev_attr_groups);
- if (ret)
- parent->ops->remove(mdev);
-
- return ret;
-}
-
-/*
- *
[PATCHv3 2/3] vfio/mdev: Avoid creating sysfs remove file on stale device removal
If device is removal is initiated by two threads as below, mdev core
attempts to create a syfs remove file on stale device.
During this flow, below [1] call trace is observed.
cpu-0cpu-1
--
mdev_unregister_device()
device_for_each_child
mdev_device_remove_cb
mdev_device_remove
user_syscall
remove_store()
mdev_device_remove()
[..]
unregister device();
/* not found in list or
* active=false.
*/
sysfs_create_file()
..Call trace
Now that mdev core follows correct device removal system of the linux
bus model, remove shouldn't fail in normal cases. If it fails, there is
no point of creating a stale file or checking for specific error status.
kernel: WARNING: CPU: 2 PID: 9348 at fs/sysfs/file.c:327
sysfs_create_file_ns+0x7f/0x90
kernel: CPU: 2 PID: 9348 Comm: bash Kdump: loaded Not tainted
5.1.0-rc6-vdevbus+ #6
kernel: Hardware name: Supermicro SYS-6028U-TR4+/X10DRU-i+, BIOS 2.0b
08/09/2016
kernel: RIP: 0010:sysfs_create_file_ns+0x7f/0x90
kernel: Call Trace:
kernel: remove_store+0xdc/0x100 [mdev]
kernel: kernfs_fop_write+0x113/0x1a0
kernel: vfs_write+0xad/0x1b0
kernel: ksys_write+0x5a/0xe0
kernel: do_syscall_64+0x5a/0x210
kernel: entry_SYSCALL_64_after_hwframe+0x49/0xbe
Signed-off-by: Parav Pandit
---
drivers/vfio/mdev/mdev_sysfs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/vfio/mdev/mdev_sysfs.c b/drivers/vfio/mdev/mdev_sysfs.c
index 9f774b91d275..ffa3dcebf201 100644
--- a/drivers/vfio/mdev/mdev_sysfs.c
+++ b/drivers/vfio/mdev/mdev_sysfs.c
@@ -237,10 +237,8 @@ static ssize_t remove_store(struct device *dev, struct
device_attribute *attr,
int ret;
ret = mdev_device_remove(dev);
- if (ret) {
- device_create_file(dev, attr);
+ if (ret)
return ret;
- }
}
return count;
--
2.19.2
[PATCHv3 0/3] vfio/mdev: Improve vfio/mdev core module
As we would like to use mdev subsystem for wider use case as discussed in [1], [2] apart from an offline discussion. This use case is also discussed with wider forum in [4] in track 'Lightweight NIC HW functions for container offload use cases'. This series is prep-work and improves vfio/mdev module in following ways. Patch-1 Improves the mdev create/remove sequence to match Linux bus, device model Patch-2 Avoid recreating remove file on stale device to eliminate call trace Patch-3 Fix race conditions of create/remove with parent removal. This is improved version than using srcu as srcu can take seconds to minutes. This series is tested using (a) mtty with VM using vfio_mdev driver for positive tests and device removal while device in use by VM using vfio_mdev driver. (b) mlx5 core driver using RFC patches [3] and internal patches. Internal patches are large and cannot be combined with this prep-work patches. It will posted once prep-work completes. [1] https://www.spinics.net/lists/netdev/msg556978.html [2] https://lkml.org/lkml/2019/3/7/696 [3] https://lkml.org/lkml/2019/3/8/819 [4] https://netdevconf.org/0x13/session.html?workshop-hardware-offload --- Changelog: --- v2->v3: - Addressed comment from Cornelia - Corrected several errors in commit log, updated commit log - Dropped already merged 7 patches v1->v2: - Addressed comments from Alex - Rebased - Inserted the device checking loop in Patch-6 as original code - Added patch 7 to 10 - Added fixes for race condition in create/remove with parent removal Patch-10 uses simplified refcount and completion, instead of srcu which might take seconds to minutes on busy system. - Added fix for device create/remove sequence to match Linux device, bus model v0->v1: - Dropped device placement on bus sequence patch for this series - Addressed below comments from Alex, Kirti, Maxim. - Added Review-by tag for already reviewed patches. - Dropped incorrect patch of put_device(). - Corrected Fixes commit tag for sysfs remove sequence fix - Split last 8th patch to smaller refactor and fixes patch - Following coding style commenting format - Fixed accidental delete of mutex_lock in mdev_unregister_device - Renamed remove helped to mdev_device_remove_common(). - Rebased for uuid/guid change Parav Pandit (3): vfio/mdev: Improve the create/remove sequence vfio/mdev: Avoid creating sysfs remove file on stale device removal vfio/mdev: Synchronize device create/remove with parent removal drivers/vfio/mdev/mdev_core.c| 150 ++- drivers/vfio/mdev/mdev_private.h | 8 +- drivers/vfio/mdev/mdev_sysfs.c | 6 +- 3 files changed, 73 insertions(+), 91 deletions(-) -- 2.19.2
[PATCHv3 3/3] vfio/mdev: Synchronize device create/remove with parent removal
In following sequences, child devices created while removing mdev parent
device can be left out, or it may lead to race of removing half
initialized child mdev devices.
issue-1:
cpu-0 cpu-1
- -
mdev_unregister_device()
device_for_each_child()
mdev_device_remove_cb()
mdev_device_remove()
create_store()
mdev_device_create() [...]
device_add()
parent_remove_sysfs_files()
/* BUG: device added by cpu-0
* whose parent is getting removed
* and it won't process this mdev.
*/
issue-2:
Below crash is observed when user initiated remove is in progress
and mdev_unregister_driver() completes parent unregistration.
cpu-0 cpu-1
- -
remove_store()
mdev_device_remove()
active = false;
mdev_unregister_device()
parent device removed.
[...]
parents->ops->remove()
/*
* BUG: Accessing invalid parent.
*/
This is similar race like create() racing with mdev_unregister_device().
BUG: unable to handle kernel paging request at c0585668
PGD e8f618067 P4D e8f618067 PUD e8f61a067 PMD 85adca067 PTE 0
Oops: [#1] SMP PTI
CPU: 41 PID: 37403 Comm: bash Kdump: loaded Not tainted 5.1.0-rc6-vdevbus+ #6
Hardware name: Supermicro SYS-6028U-TR4+/X10DRU-i+, BIOS 2.0b 08/09/2016
RIP: 0010:mdev_device_remove+0xfa/0x140 [mdev]
Call Trace:
remove_store+0x71/0x90 [mdev]
kernfs_fop_write+0x113/0x1a0
vfs_write+0xad/0x1b0
ksys_write+0x5a/0xe0
do_syscall_64+0x5a/0x210
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Therefore, mdev core is improved as below to overcome above issues.
Wait for any ongoing mdev create() and remove() to finish before
unregistering parent device using refcount and completion.
This continues to allow multiple create and remove to progress in
parallel for different mdev devices as most common case.
At the same time guard parent removal while parent is being access by
create() and remove callbacks.
Code is simplified from kref to use refcount as unregister_device() has
to wait anyway for all create/remove to finish.
While removing mdev devices during parent unregistration, there isn't
need to acquire refcount of parent device, hence code is restructured
using mdev_device_remove_common() to avoid it.
Fixes: 7b96953bc640 ("vfio: Mediated device Core driver")
Signed-off-by: Parav Pandit
---
drivers/vfio/mdev/mdev_core.c| 86
drivers/vfio/mdev/mdev_private.h | 6 ++-
2 files changed, 60 insertions(+), 32 deletions(-)
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 0bef0cae1d4b..ca33246c1dc3 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -78,34 +78,41 @@ static struct mdev_parent *__find_parent_device(struct
device *dev)
return NULL;
}
-static void mdev_release_parent(struct kref *kref)
+static bool mdev_try_get_parent(struct mdev_parent *parent)
{
- struct mdev_parent *parent = container_of(kref, struct mdev_parent,
- ref);
- struct device *dev = parent->dev;
-
- kfree(parent);
- put_device(dev);
+ if (parent)
+ return refcount_inc_not_zero(>refcount);
+ return false;
}
-static struct mdev_parent *mdev_get_parent(struct mdev_parent *parent)
+static void mdev_put_parent(struct mdev_parent *parent)
{
- if (parent)
- kref_get(>ref);
-
- return parent;
+ if (parent && refcount_dec_and_test(>refcount))
+ complete(>unreg_completion);
}
-static void mdev_put_parent(struct mdev_parent *parent)
+static void mdev_device_remove_common(struct mdev_device *mdev)
{
- if (parent)
- kref_put(>ref, mdev_release_parent);
+ struct mdev_parent *parent;
+ struct mdev_type *type;
+ int ret;
+
+ type = to_mdev_type(mdev->type_kobj);
+ mdev_remove_sysfs_files(>dev, type);
+ device_del(>dev);
+ parent = mdev->parent;
+ ret = parent->ops->remove(mdev);
+ if (ret)
+ dev_err(>dev, "Remove failed: err=%d\n", ret);
+
+ /* Balances with device_initialize() */
+ put_device(>dev);
}
static int mdev_device_remove_cb(struct device *dev, void *data)
{
if (dev_is_mdev(dev))
- mdev_device_remove(dev);
+ mdev_device_remove_common(to_mdev_device(dev));
return 0;
}
@@ -147,7 +154,8 @@ int mdev_register_device(struct device *dev, const struct
mdev_parent_ops *ops)
goto add_dev_err;
}
- kref_init(>ref);
+ refcount_set(>refcount, 1);
+
RE: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
> > > There is a problem here though. Usually the enclave itself is just a > > > loader that then loads the application from outside source and > > > creates the executable pages from the content. > > > > > > A great example of this is Graphene that bootstraps unmodified Linux > > > applications to an enclave: > > > > > > https://github.com/oscarlab/graphene > > > > > > > ISTM you should need EXECMEM or similar to run Graphene, then. > > Agreed, Graphene is effectively running arbitrary enclave code. I'm > guessing there is nothing that prevents extending/reworking Graphene to > allow generating the enclave ahead of time so as to avoid populating the > guts of the enclave at runtime, i.e. it's likely possible to run an > unmodified application in an enclave without EXECMEM if that's something > Graphene or its users really care about. Inefficient use of memory is a problem of running Graphene on SGX1, from at least 2 aspects: 1) heaps/stacks have to be pre-allocated but only a small portion of those pages will be actually used; and 2) dynamic linking is commonly used in *unmodified* applications and all dependent libraries have to be loaded, but only a subset of those pages will actually be used - e.g. most applications use only a small set of functions in libc.so but the whole library still has to be loaded. Hence a practical/efficient solution will require/involve EDMM features available in SGX2. I guess we shall look a bit further into future in order to address this problem properly. And I think it necessary to distinguish enclave virtual ranges from regular ones (probably at VMA level) before we could have a practical solution.
[REPOST PATCH v2 0/3] USB: dwc2: Allow wakeup from suspend; enable for rk3288-veyron
This is a re-post of the last 3 patches of a series I posted earlier at: https://lkml.kernel.org/r/20190418001356.124334-1-diand...@chromium.org The first two patches were applied but the last three weren't because they didn't apply at the time. They apply fine now so are ready to land. Changes in v2: - Rebased to mainline atop rk3288 remote wake quirk series. - rk3288-veyron dts patch new for v2. Douglas Anderson (3): Documentation: dt-bindings: Add snps,need-phy-for-wake for dwc2 USB USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled ARM: dts: rockchip: Allow wakeup from rk3288-veyron's dwc2 USB ports .../devicetree/bindings/usb/dwc2.txt | 3 ++ arch/arm/boot/dts/rk3288-veyron.dtsi | 2 + drivers/usb/dwc2/core.h | 5 +++ drivers/usb/dwc2/platform.c | 43 ++- 4 files changed, 51 insertions(+), 2 deletions(-) -- 2.21.0.1020.gf2820cf01a-goog
[REPOST PATCH v2 2/3] USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled
If the 'snps,need-phy-for-wake' is set in the device tree then:
- We know that we can wakeup, so call device_set_wakeup_capable().
The USB core will use this knowledge to enable wakeup by default.
- We know that we should keep the PHY on during suspend if something
on our root hub needs remote wakeup. This requires the patch (USB:
Export usb_wakeup_enabled_descendants()). Note that we don't keep
the PHY on at suspend time if it's not needed because it would be a
power draw.
If we later find some users of dwc2 that can support wakeup without
keeping the PHY on we may want to add a way to call
device_set_wakeup_capable() without keeping the PHY on at suspend
time.
Signed-off-by: Douglas Anderson
Signed-off-by: Chris Zhong
---
For relevant prior discussion of this idea, see:
https://lkml.kernel.org/r/1436207224-21849-4-git-send-email-diand...@chromium.org
If I'm reading all the responses correctly folks were of the opinion
that this patch is still the right way to go.
Changes in v2:
- Rebased to mainline atop rk3288 remote wake quirk series.
drivers/usb/dwc2/core.h | 5 +
drivers/usb/dwc2/platform.c | 43 +++--
2 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 152ac41dfb2d..73c1e998f27a 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -861,6 +861,9 @@ struct dwc2_hregs_backup {
* @hibernated:True if core is hibernated
* @reset_phy_on_wake: Quirk saying that we should assert PHY reset on a
* remote wakeup.
+ * @phy_off_for_suspend: Status of whether we turned the PHY off at suspend.
+ * @need_phy_for_wake: Quirk saying that we should keep the PHY on at
+ * suspend if we need USB to wake us up.
* @frame_number: Frame number read from the core. For both device
* and host modes. The value ranges are from 0
* to HFNUM_MAX_FRNUM.
@@ -1049,6 +1052,8 @@ struct dwc2_hsotg {
unsigned int ll_hw_enabled:1;
unsigned int hibernated:1;
unsigned int reset_phy_on_wake:1;
+ unsigned int need_phy_for_wake:1;
+ unsigned int phy_off_for_suspend:1;
u16 frame_number;
struct phy *phy;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index d10a7f8daec3..31be644d1273 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -47,7 +47,9 @@
#include
#include
#include
+#include
+#include
#include
#include "core.h"
@@ -447,6 +449,10 @@ static int dwc2_driver_probe(struct platform_device *dev)
if (retval)
goto error;
+ hsotg->need_phy_for_wake =
+ of_property_read_bool(dev->dev.of_node,
+ "snps,need-phy-for-wake");
+
/*
* Reset before dwc2_get_hwparams() then it could get power-on real
* reset value form registers.
@@ -478,6 +484,14 @@ static int dwc2_driver_probe(struct platform_device *dev)
hsotg->gadget_enabled = 1;
}
+ /*
+* If we need PHY for wakeup we must be wakeup capable.
+* When we have a device that can wake without the PHY we
+* can adjust this condition.
+*/
+ if (hsotg->need_phy_for_wake)
+ device_set_wakeup_capable(>dev, true);
+
hsotg->reset_phy_on_wake =
of_property_read_bool(dev->dev.of_node,
"snps,reset-phy-on-wake");
@@ -513,6 +527,28 @@ static int dwc2_driver_probe(struct platform_device *dev)
return retval;
}
+static bool __maybe_unused dwc2_can_poweroff_phy(struct dwc2_hsotg *dwc2)
+{
+ struct usb_device *root_hub = dwc2_hsotg_to_hcd(dwc2)->self.root_hub;
+
+ if (!dwc2->ll_hw_enabled)
+ return false;
+
+ /* If the controller isn't allowed to wakeup then we can power off. */
+ if (!device_may_wakeup(dwc2->dev))
+ return true;
+
+ /*
+* We don't want to power off the PHY if something under the
+* root hub has wakeup enabled.
+*/
+ if (usb_wakeup_enabled_descendants(root_hub))
+ return false;
+
+ /* No reason to keep the PHY powered, so allow poweroff */
+ return true;
+}
+
static int __maybe_unused dwc2_suspend(struct device *dev)
{
struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
@@ -521,8 +557,10 @@ static int __maybe_unused dwc2_suspend(struct device *dev)
if (dwc2_is_device_mode(dwc2))
dwc2_hsotg_suspend(dwc2);
- if (dwc2->ll_hw_enabled)
+ if (dwc2_can_poweroff_phy(dwc2)) {
ret = __dwc2_lowlevel_hw_disable(dwc2);
+ dwc2->phy_off_for_suspend = true;
+ }
return ret;
}
@@ -532,11 +570,12 @@ static int __maybe_unused dwc2_resume(struct device *dev)
struct dwc2_hsotg *dwc2 =
[GIT PULL] One more clk change for the merge window
The following changes since commit c1157f60d72e8b20efc670cef28883832f42406c: Merge branch 'clk-parent-rewrite-1' into clk-next (2019-05-07 11:46:13 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git tags/clk-for-linus for you to fetch changes up to 62e59c4e69b3cdbad67e3c2d49e4df4cfe1679e3: clk: Remove io.h from clk-provider.h (2019-05-15 13:21:37 -0700) One more patch to remove io.h from clk-provider.h. We used to need this include when we had clk_readl() and clk_writel(), but those are gone now so this patch pushes the dependency out to the users of clk-provider.h. Stephen Boyd (1): clk: Remove io.h from clk-provider.h arch/arm/mach-davinci/da830.c | 1 + arch/arm/mach-davinci/da850.c | 1 + arch/arm/mach-davinci/devices-da8xx.c | 1 + arch/arm/mach-davinci/dm355.c | 1 + arch/arm/mach-davinci/dm365.c | 1 + arch/arm/mach-davinci/dm644x.c | 1 + arch/arm/mach-davinci/dm646x.c | 1 + arch/arm/mach-dove/common.c | 1 + arch/arm/mach-mediatek/mediatek.c | 1 + arch/arm/mach-mv78xx0/common.c | 1 + arch/arm/mach-orion5x/common.c | 1 + arch/arm/mach-rockchip/rockchip.c | 1 + arch/arm/mach-zynq/common.c | 1 + arch/h8300/kernel/setup.c | 1 + arch/mips/ath79/clock.c | 1 + arch/mips/ath79/setup.c | 1 + arch/mips/txx9/generic/setup.c | 1 + arch/xtensa/platforms/xtfpga/setup.c| 1 + drivers/acpi/acpi_apd.c | 1 + drivers/clk/axs10x/i2s_pll_clock.c | 1 + drivers/clk/axs10x/pll_clock.c | 1 + drivers/clk/bcm/clk-bcm2835-aux.c | 1 + drivers/clk/bcm/clk-bcm2835.c | 1 + drivers/clk/bcm/clk-kona.c | 3 ++- drivers/clk/berlin/berlin2-div.c| 1 + drivers/clk/berlin/bg2.c| 1 + drivers/clk/berlin/bg2q.c | 1 + drivers/clk/clk-fixed-mmio.c| 3 ++- drivers/clk/clk-fractional-divider.c| 1 + drivers/clk/clk-hsdk-pll.c | 1 + drivers/clk/clk-multiplier.c| 1 + drivers/clk/davinci/pll-da850.c | 1 + drivers/clk/h8300/clk-div.c | 1 + drivers/clk/h8300/clk-h8s2678.c | 3 ++- drivers/clk/hisilicon/clk-hi3660-stub.c | 1 + drivers/clk/imx/clk-composite-8m.c | 3 ++- drivers/clk/imx/clk-frac-pll.c | 1 + drivers/clk/imx/clk-imx21.c | 1 + drivers/clk/imx/clk-imx27.c | 1 + drivers/clk/imx/clk-pfdv2.c | 1 + drivers/clk/imx/clk-pllv4.c | 1 + drivers/clk/imx/clk-sccg-pll.c | 1 + drivers/clk/ingenic/cgu.c | 1 + drivers/clk/ingenic/jz4740-cgu.c| 1 + drivers/clk/ingenic/jz4770-cgu.c| 1 + drivers/clk/ingenic/jz4780-cgu.c| 1 + drivers/clk/loongson1/clk-loongson1c.c | 1 + drivers/clk/microchip/clk-core.c| 1 + drivers/clk/microchip/clk-pic32mzda.c | 1 + drivers/clk/mvebu/armada-37xx-periph.c | 1 + drivers/clk/mvebu/armada-37xx-tbg.c | 1 + drivers/clk/mvebu/clk-corediv.c | 1 + drivers/clk/nxp/clk-lpc18xx-ccu.c | 1 + drivers/clk/nxp/clk-lpc18xx-cgu.c | 1 + drivers/clk/nxp/clk-lpc32xx.c | 1 + drivers/clk/pxa/clk-pxa.c | 1 + drivers/clk/renesas/clk-r8a73a4.c | 1 + drivers/clk/renesas/clk-r8a7740.c | 1 + drivers/clk/renesas/clk-rcar-gen2.c | 1 + drivers/clk/renesas/clk-rz.c| 1 + drivers/clk/renesas/clk-sh73a0.c| 1 + drivers/clk/renesas/r9a06g032-clocks.c | 1 + drivers/clk/renesas/rcar-usb2-clock-sel.c | 1 + drivers/clk/renesas/renesas-cpg-mssr.c | 1 + drivers/clk/rockchip/clk-half-divider.c | 3 ++- drivers/clk/rockchip/clk-px30.c | 1 + drivers/clk/rockchip/clk-rk3036.c | 1 + drivers/clk/rockchip/clk-rk3128.c | 1 + drivers/clk/rockchip/clk-rk3188.c | 1 + drivers/clk/rockchip/clk-rk3228.c | 1 + drivers/clk/rockchip/clk-rk3288.c | 1 + drivers/clk/rockchip/clk-rk3328.c | 1 + drivers/clk/rockchip/clk-rk3368.c | 1 + drivers/clk/rockchip/clk-rk3399.c | 1 + drivers/clk/rockchip/clk-rv1108.c | 1 + drivers/clk/rockchip/clk.c | 1 + drivers/clk/samsung/clk-cpu.c | 1 + drivers/clk/samsung/clk-exynos-clkout.c | 1 + drivers/clk/samsung/clk-exynos3250.c| 1 + drivers/clk/samsung/clk-exynos4.c | 1 + drivers/clk/samsung/clk-exynos5-subcmu.c| 1 +
Re: [RESEND PATCH v3 04/11] s390/cpacf: mark scpacf_query() as __always_inline
On 4/22/19 8:49 PM, Masahiro Yamada wrote:
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for s390, the following error is reported:
In file included from arch/s390/crypto/des_s390.c:19:
./arch/s390/include/asm/cpacf.h: In function 'cpacf_query':
./arch/s390/include/asm/cpacf.h:170:2: warning: asm operand 3 probably doesn't
match constraints
asm volatile(
^~~
./arch/s390/include/asm/cpacf.h:170:2: error: impossible constraint in 'asm'
This also seems to still be broken, again with gcc 9.1.1
BUILDSTDERR: In file included from arch/s390/crypto/prng.c:29:
BUILDSTDERR: ./arch/s390/include/asm/cpacf.h: In function 'cpacf_query_func':
BUILDSTDERR: ./arch/s390/include/asm/cpacf.h:170:2: warning: asm operand 3
probably doesn't match constraints
BUILDSTDERR: 170 | asm volatile(
BUILDSTDERR: | ^~~
BUILDSTDERR: ./arch/s390/include/asm/cpacf.h:170:2: error: impossible
constraint in 'asm'
I realized we're still carrying a patch to add -fno-section-anchors
but it's a similar failure to powerpc.
Thanks,
Laura
(config attached, full build log at
https://kojipkgs.fedoraproject.org//work/tasks/6330/34886330/build.log)
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2:
- split into a separate patch
arch/s390/include/asm/cpacf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/include/asm/cpacf.h b/arch/s390/include/asm/cpacf.h
index 3cc52e37b4b2..f316de40e51b 100644
--- a/arch/s390/include/asm/cpacf.h
+++ b/arch/s390/include/asm/cpacf.h
@@ -202,7 +202,7 @@ static inline int __cpacf_check_opcode(unsigned int opcode)
}
}
-static inline int cpacf_query(unsigned int opcode, cpacf_mask_t *mask)
+static __always_inline int cpacf_query(unsigned int opcode, cpacf_mask_t *mask)
{
if (__cpacf_check_opcode(opcode)) {
__cpacf_query(opcode, mask);
# s390
#
# Automatically generated file; DO NOT EDIT.
# Linux/s390 5.1.0 Kernel Configuration
#
#
# Compiler: gcc (GCC) 9.0.1 20190312 (Red Hat 9.0.1-0.10)
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=90001
CONFIG_CLANG_VERSION=0
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_HAVE_KERNEL_UNCOMPRESSED=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
# CONFIG_KERNEL_UNCOMPRESSED is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_COUNT=y
#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_PSI=y
# CONFIG_PSI_DEFAULT_DISABLED is not set
# CONFIG_CPU_ISOLATION is not set
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_BUILD_BIN2C=y
# CONFIG_IKCONFIG is not set
CONFIG_IKHEADERS_PROC=m
CONFIG_LOG_BUF_SHIFT=16
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING=y
# CONFIG_NUMA_BALANCING_DEFAULT_ENABLED is not set
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_MEMCG_KMEM=y
CONFIG_BLK_CGROUP=y
CONFIG_DEBUG_BLK_CGROUP=y
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_CGROUP_PIDS=y
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_HUGETLB is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_BPF=y
# CONFIG_CGROUP_DEBUG
[GIT PULL] afs: Fix callback promise handling
Hi Linus, Could you pull this series on top of the "afs: Miscellaneous fixes" series please? The two are consecutive on the same branch. This series fixes a bunch of problems in callback promise handling, where a callback promise indicates a promise on the part of the server to notify the client in the event of some sort of change to a file or volume. In the event of a break, the client has to go and refetch the client status from the server and discard any cached permission information as the ACL might have changed. The problem in the current code is that changes made by other clients aren't always noticed, primarily because the file status information and the callback information aren't updated in the same critical section, even if these are carried in the same reply from an RPC operation, and so the AFS_VNODE_CB_PROMISED flag is unreliable. Arranging for them to be done in the same critical section during reply decoding is tricky because of the FS.InlineBulkStatus op - which has all the statuses in the reply arriving and then all the callbacks, so they have to be buffered. It simplifies things a lot to move the critical section out of the decode phase and do it after the RPC function returns. Also new inodes (either newly fetched or newly created) aren't properly managed against a callback break happening before we get the local inode up and running. Fix this by: (1) There's now a combined file status and callback record (struct afs_status_cb) to carry both plus some flags. (2) Each operation wrapper function allocates sufficient afs_status_cb records for all the vnodes it is interested in and passes them into RPC operations to be filled in from the reply. (3) The FileStatus and CallBack record decoders no longer apply the new/revised status and callback information to the inode/vnode at the point of decoding and instead store the information into the record from (2). (4) afs_vnode_commit_status() then revises the file status, detects deletion and notes callback information inside of a single critical section. It also checks the callback break counters and cancels the callback promise if they changed during the operation. [*] Note that "callback break counters" are counters of server events that cancel one or more callback promises that the client thinks it has. The client counts the events and compares the counters before and after an operation to see if the callback promise it thinks it just got evaporated before it got recorded under lock. (5) Volume and server callback break counters are passed into afs_iget() allowing callback breaks concurrent with inode set up to be detected and the callback promise thence to be cancelled. (6) AFS validation checks are now done under RCU conditions using a read lock on cb_lock. This requires vnode->cb_interest to be made RCU safe. (7) If the checks in (6) fail, the callback breaker is then called under write lock on the cb_lock - but only if the callback break counter didn't change from the value read before the checks were made. (8) Results from FS.InlineBulkStatus that correspond to inodes we currently have in memory are now used to update those inodes' status and callback information rather than being discarded. This requires those inodes to be looked up before the RPC op is made and all their callback break values saved. To aid in this, the following changes have also been made: (A) Don't pass the vnode into the reply delivery functions or the decoders. The vnode shouldn't be altered anywhere in those paths. The only exception, for the moment, is for the call done hook for file lock ops that wants access to both the vnode and the call - this can be fixed at a later time. (B) Get rid of the call->reply[] void* array and replace it with named and typed members. This avoids confusion since different ops were mapping different reply[] members to different things. (C) Fix an order-1 kmalloc allocation in afs_do_lookup() and replace it with kvcalloc(). (D) Always get the reply time. Since callback, lock and fileserver record expiry times are calculated for several RPCs, make this mandatory. (E) Call afs_pages_written_back() from the operation wrapper rather than from the delivery function. (F) Don't store the version and type from a callback promise in a reply as the information in them is of very limited use. Signed-off-by: David Howells Tested-by: Marc Dionne --- The following changes since commit fd711586bb7d63f257da5eff234e68c446ac35ea: afs: Fix double inc of vnode->cb_break (2019-05-16 16:25:21 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/afs-fixes-b-20190516 for you to fetch changes up to 39db9815da489b47b50b8e6e4fc7566a77bd
[GIT PULL] afs: Miscellaneous fixes
Hi Linus, Could you pull this series please? It fixes a set of miscellaneous issues in the afs filesystem, including: (1) Leak of keys on file close. (2) Broken error handling in xattr functions. (3) Missing locking when updating VL server list. (4) Volume location server DNS lookup whereby preloaded cells may not ever get a lookup and regular DNS lookups to maintain server lists consume power unnecessarily. (5) Incorrect error propagation and handling in the fileserver iteration code causes operations to sometimes apparently succeed. (6) Interruption of server record check/update side op during fileserver iteration causes uninterruptible main operations to fail unexpectedly. (7) Callback promise expiry time miscalculation. (8) Over invalidation of the callback promise on directories. (9) Double locking on callback break waking up file locking waiters. (10) Double increment of the vnode callback break counter. Note that it makes some changes outside of the afs code, including: (A) Adding an extra parameter to dns_query() to allow the dns_resolver key just accessed to be immediately invalidated. AFS is caching the results itself, so the key can be discarded. (B) Adding an interruptible version of wait_var_event(). (C) Adding an rxrpc function to allow the maximum lifespan to be set on a call. (D) Adding a way for an rxrpc call to be marked as non-interruptible. Signed-off-by: David Howells Tested-by: Marc Dionne --- The following changes since commit 80f232121b69cc69a31ccb2b38c1665d770b0710: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2019-05-07 22:03:58 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/afs-fixes-20190516 for you to fetch changes up to fd711586bb7d63f257da5eff234e68c446ac35ea: afs: Fix double inc of vnode->cb_break (2019-05-16 16:25:21 +0100) AFS fixes David Howells (19): afs: Fix key leak in afs_release() and afs_evict_inode() afs: Fix incorrect error handling in afs_xattr_get_acl() afs: Fix afs_xattr_get_yfs() to not try freeing an error value afs: Fix missing lock when replacing VL server list afs: Fix afs_cell records to always have a VL server list record dns_resolver: Allow used keys to be invalidated Add wait_var_event_interruptible() afs: Fix cell DNS lookup afs: Fix "kAFS: AFS vnode with undefined type 0" rxrpc: Provide kernel interface to set max lifespan on a call afs: Fix the maximum lifespan of VL and probe calls afs: Fix error propagation from server record check/update rxrpc: Allow the kernel to mark a call as being non-interruptible afs: Make some RPC operations non-interruptible afs: Make dynamic root population wait uninterruptibly for proc_cells_lock afs: Fix calculation of callback expiry time afs: Don't invalidate callback if AFS_VNODE_DIR_VALID not set afs: Fix lock-wait/callback-break double locking afs: Fix double inc of vnode->cb_break Documentation/networking/rxrpc.txt | 21 - fs/afs/addr_list.c | 2 +- fs/afs/afs.h | 3 + fs/afs/callback.c | 8 +- fs/afs/cell.c | 187 ++--- fs/afs/dir.c | 18 ++-- fs/afs/dir_silly.c | 4 +- fs/afs/dynroot.c | 5 +- fs/afs/file.c | 9 +- fs/afs/flock.c | 9 +- fs/afs/fsclient.c | 77 +-- fs/afs/inode.c | 12 +-- fs/afs/internal.h | 22 +++-- fs/afs/proc.c | 8 +- fs/afs/rotate.c| 29 -- fs/afs/rxrpc.c | 7 +- fs/afs/security.c | 4 +- fs/afs/server.c| 17 +++- fs/afs/super.c | 2 +- fs/afs/vl_list.c | 20 ++-- fs/afs/vl_rotate.c | 28 +- fs/afs/vlclient.c | 4 + fs/afs/write.c | 2 +- fs/afs/xattr.c | 103 ++-- fs/afs/yfsclient.c | 98 +-- fs/cifs/dns_resolve.c | 2 +- fs/nfs/dns_resolve.c | 2 +- include/linux/dns_resolver.h | 3 +- include/linux/wait_bit.h | 13 +++ include/net/af_rxrpc.h | 3 + net/ceph/messenger.c | 2 +- net/dns_resolver/dns_query.c | 6 +- net/rxrpc/af_rxrpc.c | 28 ++ net/rxrpc/ar-internal.h| 2 + net/rxrpc/call_object.c| 2 + net/rxrpc/conn_client.c| 8 +- net
