[PATCH v8 3/9] remoteproc: qcom: Add support for split q6 + m3 wlan firmware
IPQ8074 supports split firmware for q6 and m3 as well.
So add support for loading the m3 firmware before q6.
Now the drivers works fine for both split and unified
firmwares.
Signed-off-by: Gokul Sriram Palanisamy
Signed-off-by: Sricharan R
Signed-off-by: Nikhil Prakash V
---
drivers/remoteproc/qcom_q6v5_wcss.c | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
b/drivers/remoteproc/qcom_q6v5_wcss.c
index 4e35e5c..2ecbd73 100644
--- a/drivers/remoteproc/qcom_q6v5_wcss.c
+++ b/drivers/remoteproc/qcom_q6v5_wcss.c
@@ -139,6 +139,7 @@ struct q6v5_wcss {
u32 version;
bool requires_force_stop;
bool need_mem_protection;
+ const char *m3_firmware_name;
struct qcom_rproc_glink glink_subdev;
struct qcom_rproc_ssr ssr_subdev;
@@ -147,7 +148,8 @@ struct q6v5_wcss {
struct wcss_data {
int (*init_clock)(struct q6v5_wcss *wcss);
int (*init_regulator)(struct q6v5_wcss *wcss);
- const char *firmware_name;
+ const char *q6_firmware_name;
+ const char *m3_firmware_name;
unsigned int crash_reason_smem;
u32 version;
bool aon_reset_required;
@@ -788,8 +790,29 @@ static void *q6v5_wcss_da_to_va(struct rproc *rproc, u64
da, size_t len)
static int q6v5_wcss_load(struct rproc *rproc, const struct firmware *fw)
{
struct q6v5_wcss *wcss = rproc->priv;
+ const struct firmware *m3_fw;
int ret;
+ if (wcss->m3_firmware_name) {
+ ret = request_firmware(_fw, wcss->m3_firmware_name,
+ wcss->dev);
+ if (ret)
+ goto skip_m3;
+
+ ret = qcom_mdt_load_no_init(wcss->dev, m3_fw,
+ wcss->m3_firmware_name, 0,
+ wcss->mem_region, wcss->mem_phys,
+ wcss->mem_size, >mem_reloc);
+
+ release_firmware(m3_fw);
+
+ if (ret) {
+ dev_err(wcss->dev, "can't load m3_fw.bXX\n");
+ return ret;
+ }
+ }
+
+skip_m3:
if (wcss->need_mem_protection)
ret = qcom_mdt_load(wcss->dev, fw, rproc->firmware,
WCNSS_PAS_ID, wcss->mem_region,
@@ -1068,7 +1091,7 @@ static int q6v5_wcss_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
rproc = rproc_alloc(>dev, pdev->name, desc->ops,
- desc->firmware_name, sizeof(*wcss));
+ desc->q6_firmware_name, sizeof(*wcss));
if (!rproc) {
dev_err(>dev, "failed to allocate rproc\n");
return -ENOMEM;
@@ -1081,6 +1104,7 @@ static int q6v5_wcss_probe(struct platform_device *pdev)
wcss->version = desc->version;
wcss->requires_force_stop = desc->requires_force_stop;
wcss->need_mem_protection = desc->need_mem_protection;
+ wcss->m3_firmware_name = desc->m3_firmware_name;
ret = q6v5_wcss_init_mmio(wcss, pdev);
if (ret)
@@ -1145,7 +1169,8 @@ static int q6v5_wcss_remove(struct platform_device *pdev)
static const struct wcss_data wcss_ipq8074_res_init = {
.init_clock = ipq8074_init_clock,
- .firmware_name = "IPQ8074/q6_fw.mdt",
+ .q6_firmware_name = "IPQ8074/q6_fw.mdt",
+ .m3_firmware_name = "IPQ8074/m3_fw.mdt",
.crash_reason_smem = WCSS_CRASH_REASON,
.aon_reset_required = true,
.wcss_q6_reset_required = true,
@@ -1158,7 +1183,7 @@ static const struct wcss_data wcss_qcs404_res_init = {
.init_clock = qcs404_init_clock,
.init_regulator = qcs404_init_regulator,
.crash_reason_smem = WCSS_CRASH_REASON,
- .firmware_name = "wcnss.mdt",
+ .q6_firmware_name = "wcnss.mdt",
.version = WCSS_QCS404,
.aon_reset_required = false,
.wcss_q6_reset_required = false,
--
2.7.4
[PATCH v3 34/34] misc: HDDL device management for IA host
From: "C, Udhayakumar"
Add IA host hddl device management driver for Intel Edge.AI Computer Vision
platforms.
About Intel Edge.AI Computer Vision platforms:
-
The Intel Edge.AI Computer Vision platforms are vision processing systems
targeting machine vision applications for connected devices.
They are based on ARM A53 CPU running Linux and acts as a PCIe
endpoint device.
High-level architecture:
Remote Host IA CPU Local Host ARM CPU
---
| * Send time as xlink packet | |* Sync time with IA host |
| * receive sensor details| |* Prepare and share sensor|
| and register as i2c or| | details to IA host as |
| xlink smbus slaves| | xlink packets |
---
| hddl server | <=> | hddl client |
--- xlink
hddl device module:
---
The HDDL client driver acts as an software RTC to sync with network
time. It abstracts xlink protocol to communicate with remote host.
This driver exports the details about sensors available in the
platform to remote host as xlink packets.
This driver also handles device connect/disconnect events and
identifies board id and soc id using gpio's, based on platform
configuration.
- Remote Host driver
* Intended for IA CPU
* It is based on xlink Framework
* Driver path:
{tree}/drivers/misc/hddl_device/hddl_device_server.c
Local arm host and Remote IA host drivers communicates using
XLINK protocol.
Signed-off-by: C, Udhayakumar
---
.../misc-devices/hddl_device_server.rst | 205 +
Documentation/misc-devices/index.rst | 1 +
drivers/misc/hddl_device/Kconfig | 12 +
drivers/misc/hddl_device/Makefile | 2 +
drivers/misc/hddl_device/hddl_device_rh.c | 837 ++
5 files changed, 1057 insertions(+)
create mode 100644 Documentation/misc-devices/hddl_device_server.rst
create mode 100644 drivers/misc/hddl_device/hddl_device_rh.c
diff --git a/Documentation/misc-devices/hddl_device_server.rst
b/Documentation/misc-devices/hddl_device_server.rst
new file mode 100644
index ..0be37973d1fe
--- /dev/null
+++ b/Documentation/misc-devices/hddl_device_server.rst
@@ -0,0 +1,205 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver: hddl_device_server
+=
+
+Supported chips:
+ * Intel Edge.AI Computer Vision platforms: Keem Bay
+
+Authors:
+- Thalaiappan, Rathina
+- Udhayakumar C
+
+High-level architecture
+===
+::
+
+Remote Host IA CPU Local Host ARM CPU
+---
+| * Send time as xlink packet | |* Sync time with IA host |
+| * receive sensor details| |* Prepare and share sensor|
+| and register as i2c or| | details to IA host as |
+| xlink smbus slaves| | xlink packets |
+---
+| hddl server | <=> | hddl client |
+--- xlink
+
+Overview
+
+
+This driver supports hddl device management for Intel Edge.AI Computer Vision
+platforms. This driver runs in IA host
+
+This driver supports the following features:
+
+ - Receives deatils of temperature sensor, current sensor and fan controller
+present in Intel Edge.AI Computer Vision platforms.
+ - Send Time sync data to Intel Edge.AI Computer Vision platform.
+ - Handles device connect and disconnect events.
+ - Get free slave address for memory mapped thermal sensors present in SoC
+(Documentation/hwmon/intel_tsens_sensors.rst) and share it with Intel
+Edge.AI Computer Vision platform.
+ - Registers i2c slave device for slaves present in Intel Edge.AI Computer
+Vision platform
+
+Keem Bay platform has
+Onchip sensors:
+
+ - Media Subsystem (mss) temperature sensor
+ - NN subsystem (nce) temperature sensor
+ - Compute subsystem (cse) temperature sensor
+ - SOC(Maximum of mss, nce and cse).
+
+Onboard sensors:
+
+ - two lm75 temperature sensors
+ - emc2103 fan controller
+ - ina3221 current sensor
+
+Driver Structure
+
+
+The driver provides a platform device where the ``probe`` and ``remove``
+operations are provided.
+
+ - probe: spawn kernel thread to monitor new PCIE devices.
+
+ - init task: Poll for new PCIE device with time interval of 5 seconds and
+creates connect task to setup new device.
+
+ - connect task: Connect task is the main entity which connects to hddl
+device client
[PATCH v4 33/34] misc: Hddl device management for local host
From: "C, Udhayakumar"
Add local host hddl device management for Intel Edge.AI Computer Vision
platforms.
About Intel Edge.AI Computer Vision platforms:
-
The Intel Edge.AI Computer Vision platforms are vision processing systems
targeting machine vision applications for connected devices.
They are based on ARM A53 CPU running Linux and acts as a PCIe
endpoint device.
High-level architecture:
Remote Host IA CPU Local Host ARM CPU
---
| * Send time as xlink packet | |* Sync time with IA host |
| * receive sensor details| |* Prepare and share sensor|
| and register as i2c or| | details to IA host as |
| xlink smbus slaves| | xlink packets |
---
| hddl server | <=> | hddl client |
--- xlink
hddl device module:
---
The HDDL client driver acts as an software RTC to sync with network
time. It abstracts xlink protocol to communicate with remote host.
This driver exports the details about sensors available in the
platform to remote host as xlink packets.
This driver also handles device connect/disconnect events and
identifies board id and soc id using gpio's, based on platform
configuration.
- Local Host driver
* Intended for ARM CPU
* It is based on xlink Framework
* Driver path:
{tree}/drivers/misc/hddl_device/hddl_device_client.c
Local arm host and Remote IA host drivers communicates using
XLINK protocol.
Signed-off-by: C Udhayakumar
Signed-off-by: Mark Gross
---
.../misc-devices/hddl_device_client.rst | 212 +
Documentation/misc-devices/index.rst | 1 +
Documentation/vpu/index.rst | 1 +
MAINTAINERS | 1 +
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile | 1 +
drivers/misc/hddl_device/Kconfig | 14 +
drivers/misc/hddl_device/Makefile | 5 +
drivers/misc/hddl_device/hddl_device.c| 565 +
drivers/misc/hddl_device/hddl_device_lh.c | 764 ++
drivers/misc/hddl_device/hddl_device_util.h | 52 ++
11 files changed, 1617 insertions(+)
create mode 100644 Documentation/misc-devices/hddl_device_client.rst
create mode 100644 drivers/misc/hddl_device/Kconfig
create mode 100644 drivers/misc/hddl_device/Makefile
create mode 100644 drivers/misc/hddl_device/hddl_device.c
create mode 100644 drivers/misc/hddl_device/hddl_device_lh.c
create mode 100644 drivers/misc/hddl_device/hddl_device_util.h
diff --git a/Documentation/misc-devices/hddl_device_client.rst
b/Documentation/misc-devices/hddl_device_client.rst
new file mode 100644
index ..413643b6b500
--- /dev/null
+++ b/Documentation/misc-devices/hddl_device_client.rst
@@ -0,0 +1,212 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+Kernel driver: hddl_device_client
+=
+
+Supported chips:
+ * Intel Edge.AI Computer Vision platforms: Keem Bay
+
+Authors:
+- Thalaiappan, Rathina
+- Udhayakumar C
+
+
+Overview
+
+
+This driver supports hddl device management for Intel Edge.AI Computer Vision
+platforms.
+
+This driver supports the following features:
+
+ - Exports deatils of temperature sensor, current sensor and fan controller
+present in Intel Edge.AI Computer Vision platforms to IA host.
+ - Enable Time sync of Intel Edge.AI Computer Vision platform with IA host.
+ - Handles device connect and disconnect events.
+ - Receives slave address from the IA host for memory mapped thermal sensors
+present in SoC (Documentation/hwmon/intel_tsens_sensors.rst).
+ - Registers i2c slave device for slaves present in Intel Edge.AI Computer
+Vision platform
+
+Keem Bay platform has
+Onchip sensors:
+
+ - Media Subsystem (mss) temperature sensor
+ - NN subsystem (nce) temperature sensor
+ - Compute subsystem (cse) temperature sensor
+ - SOC(Maximum of mss, nce and cse).
+
+Onboard sensors:
+
+ - two lm75 temperature sensors
+ - emc2103 fan controller
+ - ina3221 current sensor
+
+High-level architecture
+===
+::
+
+Remote Host IA CPU Local Host ARM CPU
+---
+| * Send time as xlink packet | |* Sync time with IA host |
+| * receive sensor details| |* Prepare and share sensor|
+| and register as i2c or| | details to IA host as |
+| xlink smbus slaves| | xlink packets |
+---
+
Re: [PATCH 1/2] net: atm: pppoatm: use tasklet_init to initialize wakeup tasklet
Hello: This series was applied to netdev/net-next.git (refs/heads/master): On Wed, 27 Jan 2021 18:32:55 +0100 you wrote: > Previously a temporary tasklet structure was initialized on the stack > using DECLARE_TASKLET_OLD() and then copied over and modified. Nothing > else in the kernel seems to use this pattern, so let's just call > tasklet_init() like everyone else. > > Signed-off-by: Emil Renner Berthing > > [...] Here is the summary with links: - [1/2] net: atm: pppoatm: use tasklet_init to initialize wakeup tasklet https://git.kernel.org/netdev/net-next/c/a5b88632fc96 - [2/2] net: atm: pppoatm: use new API for wakeup tasklet https://git.kernel.org/netdev/net-next/c/a58745979cdd You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
[PATCH v3 22/34] xlink-core: Enable VPU IP management and runtime control
From: Seamus Kelly
Enable VPU management including, enumeration, boot and runtime control.
Add APIs:
write control data:
used to transmit small, local data
start vpu:
calls boot_device API ( soon to be deprecated )
stop vpu
calls reset_device API ( soon to be deprecated )
reset vpu
calls reset_device API ( soon to be deprecated )
get device name:
Returns the device name for the input device id
This could be a char device path, for example "/dev/ttyUSB0"
for a serial device; or it could be a device string
description, for example, for PCIE "00:00.0 Host bridge: Intel
Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01)"
get device list:
Returns the list of software device IDs for all connected
physical devices
get device status:
returns the current state of the input device
OFF - The device is off (D3cold/Slot power removed).
BUSY - device is busy and not available (device is
booting)
READY - device is available for use
ERROR - device HW failure is detected
RECOVERY - device is in recovery mode, waiting for
recovery operations
boot device:
When used on the remote host - starts the SOC device by calling
corresponding function from VPU Driver.
Takes firmware's 'binary_name' as input.
For Linux, the firmware image is expected to be located in
'/lib/firmware' folder or its subfolders.
For Linux, 'binary_name' is not a path but an image name that
will be searched in the default Linux search paths
('/lib/firmware').
When used on the local host - triggers the booting of VPUIP
device.
reset device:
When used on the remote host - resets the device by calling
corresponding VPU Driver function.
When used on the local host - resets the VPUIP device
get device mode:
query and returns the current device power mode
set device mode:
used for device throttling or entering various power modes
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Seamus Kelly
---
drivers/misc/xlink-core/xlink-core.c| 235
drivers/misc/xlink-core/xlink-defs.h| 2 +
drivers/misc/xlink-core/xlink-ioctl.c | 214 ++
drivers/misc/xlink-core/xlink-ioctl.h | 9 +
drivers/misc/xlink-core/xlink-multiplexer.c | 56 +
drivers/misc/xlink-core/xlink-platform.c| 86 +++
include/linux/xlink.h | 27 +++
7 files changed, 629 insertions(+)
diff --git a/drivers/misc/xlink-core/xlink-core.c
b/drivers/misc/xlink-core/xlink-core.c
index bdbf8c6a99ca..d0a3f98d16af 100644
--- a/drivers/misc/xlink-core/xlink-core.c
+++ b/drivers/misc/xlink-core/xlink-core.c
@@ -73,6 +73,8 @@ struct keembay_xlink_dev {
struct mutex lock; // protect access to xlink_dev
};
+static u8 volbuf[XLINK_MAX_BUF_SIZE]; // buffer for volatile transactions
+
/*
* global variable pointing to our xlink device.
*
@@ -264,6 +266,9 @@ static long xlink_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
case XL_READ_DATA:
rc = ioctl_read_data(arg);
break;
+ case XL_READ_TO_BUFFER:
+ rc = ioctl_read_to_buffer(arg);
+ break;
case XL_WRITE_DATA:
rc = ioctl_write_data(arg);
break;
@@ -276,9 +281,39 @@ static long xlink_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
case XL_CLOSE_CHANNEL:
rc = ioctl_close_channel(arg);
break;
+ case XL_START_VPU:
+ rc = ioctl_start_vpu(arg);
+ break;
+ case XL_STOP_VPU:
+ rc = xlink_stop_vpu();
+ break;
+ case XL_RESET_VPU:
+ rc = xlink_stop_vpu();
+ break;
case XL_DISCONNECT:
rc = ioctl_disconnect(arg);
break;
+ case XL_GET_DEVICE_NAME:
+ rc = ioctl_get_device_name(arg);
+ break;
+ case XL_GET_DEVICE_LIST:
+ rc = ioctl_get_device_list(arg);
+ break;
+ case XL_GET_DEVICE_STATUS:
+ rc = ioctl_get_device_status(arg);
+ break;
+ case XL_BOOT_DEVICE:
+ rc = ioctl_boot_device(arg);
+ break;
+ case XL_RESET_DEVICE:
+ rc = ioctl_reset_device(arg);
+ break;
+ case XL_GET_DEVICE_MODE:
+ rc
[PATCH v4 12/34] misc: xlink-pcie: lh: Prepare changes for adding remote host driver
From: Srikanth Thokala
Move logic that can be reused between local host and remote host to
common/ folder
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
drivers/misc/xlink-pcie/{local_host => common}/core.h | 8 +++-
drivers/misc/xlink-pcie/{local_host => common}/util.c | 8 +++-
drivers/misc/xlink-pcie/{local_host => common}/util.h | 8 +++-
drivers/misc/xlink-pcie/{local_host => common}/xpcie.h | 8 +++-
drivers/misc/xlink-pcie/local_host/Makefile| 2 +-
drivers/misc/xlink-pcie/local_host/core.c | 4 ++--
drivers/misc/xlink-pcie/local_host/epf.h | 4 ++--
7 files changed, 17 insertions(+), 25 deletions(-)
rename drivers/misc/xlink-pcie/{local_host => common}/core.h (96%)
rename drivers/misc/xlink-pcie/{local_host => common}/util.c (97%)
rename drivers/misc/xlink-pcie/{local_host => common}/util.h (91%)
rename drivers/misc/xlink-pcie/{local_host => common}/xpcie.h (92%)
diff --git a/drivers/misc/xlink-pcie/local_host/core.h
b/drivers/misc/xlink-pcie/common/core.h
similarity index 96%
rename from drivers/misc/xlink-pcie/local_host/core.h
rename to drivers/misc/xlink-pcie/common/core.h
index 84985ef41a64..656b5e2dbfae 100644
--- a/drivers/misc/xlink-pcie/local_host/core.h
+++ b/drivers/misc/xlink-pcie/common/core.h
@@ -1,11 +1,9 @@
/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- *
+/*
* Intel Keem Bay XLink PCIe Driver
*
- * Copyright (C) 2020 Intel Corporation
- *
- /
+ * Copyright (C) 2021 Intel Corporation
+ */
#ifndef XPCIE_CORE_HEADER_
#define XPCIE_CORE_HEADER_
diff --git a/drivers/misc/xlink-pcie/local_host/util.c
b/drivers/misc/xlink-pcie/common/util.c
similarity index 97%
rename from drivers/misc/xlink-pcie/local_host/util.c
rename to drivers/misc/xlink-pcie/common/util.c
index ec808b0cd72b..d99125f61ba0 100644
--- a/drivers/misc/xlink-pcie/local_host/util.c
+++ b/drivers/misc/xlink-pcie/common/util.c
@@ -1,11 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-only
-/*
- *
+/*
* Intel Keem Bay XLink PCIe Driver
*
- * Copyright (C) 2020 Intel Corporation
- *
- /
+ * Copyright (C) 2021 Intel Corporation
+ */
#include "util.h"
diff --git a/drivers/misc/xlink-pcie/local_host/util.h
b/drivers/misc/xlink-pcie/common/util.h
similarity index 91%
rename from drivers/misc/xlink-pcie/local_host/util.h
rename to drivers/misc/xlink-pcie/common/util.h
index 908be897a61d..5295783b0437 100644
--- a/drivers/misc/xlink-pcie/local_host/util.h
+++ b/drivers/misc/xlink-pcie/common/util.h
@@ -1,11 +1,9 @@
/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- *
+/*
* Intel Keem Bay XLink PCIe Driver
*
- * Copyright (C) 2020 Intel Corporation
- *
- /
+ * Copyright (C) 2021 Intel Corporation
+ */
#ifndef XPCIE_UTIL_HEADER_
#define XPCIE_UTIL_HEADER_
diff --git a/drivers/misc/xlink-pcie/local_host/xpcie.h
b/drivers/misc/xlink-pcie/common/xpcie.h
similarity index 92%
rename from drivers/misc/xlink-pcie/local_host/xpcie.h
rename to drivers/misc/xlink-pcie/common/xpcie.h
index 8a559617daba..48529eb49be0 100644
--- a/drivers/misc/xlink-pcie/local_host/xpcie.h
+++ b/drivers/misc/xlink-pcie/common/xpcie.h
@@ -1,11 +1,9 @@
/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- *
+/*
* Intel Keem Bay XLink PCIe Driver
*
- * Copyright (C) 2020 Intel Corporation
- *
- /
+ * Copyright (C) 2021 Intel Corporation
+ */
#ifndef XPCIE_HEADER_
#define XPCIE_HEADER_
diff --git a/drivers/misc/xlink-pcie/local_host/Makefile
b/drivers/misc/xlink-pcie/local_host/Makefile
index 28761751d43b..65df94c7e860 100644
--- a/drivers/misc/xlink-pcie/local_host/Makefile
+++ b/drivers/misc/xlink-pcie/local_host/Makefile
@@ -2,4 +2,4 @@ obj-$(CONFIG_XLINK_PCIE_LH_DRIVER) += mxlk_ep.o
mxlk_ep-objs := epf.o
mxlk_ep-objs += dma.o
mxlk_ep-objs += core.o
-mxlk_ep-objs += util.o
+mxlk_ep-objs += ../common/util.o
diff --git a/drivers/misc/xlink-pcie/local_host/core.c
b/drivers/misc/xlink-pcie/local_host/core.c
index c67ce2c3067d..2c4e29bce7f7 100644
--- a/drivers/misc/xlink-pcie/local_host/core.c
+++ b/drivers/misc/xlink-pcie/local_host/core.c
@@ -8,8 +8,8 @@
#include
#include "epf.h"
-#include "core.h"
-#include "util.h"
+#include "../common/core.h"
+#include "../common/util.h"
static struct xpcie *global_xpcie;
diff --git a/drivers/misc/xlink-pcie/local_host/epf.h
Re: [PATCH 4.19 00/26] 4.19.172-rc1 review
On Fri, 29 Jan 2021 at 16:45, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.172 release. > There are 26 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 31 Jan 2021 10:59:01 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.172-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.19.172-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: d36f1541af5ac2e86ea3548b7da2e962e4ef5266 git describe: v4.19.171-27-gd36f1541af5a Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.171-27-gd36f1541af5a No regressions (compared to build v4.19.171) No fixes (compared to build v4.19.171) Ran 48448 total tests in the following environments and test suites. Environments -- - arm - arm64 - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - mips - nxp-ls2088 - nxp-ls2088-64k_page_size - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - s390 - sparc - x15 - arm - x86_64 - x86-kasan - x86_64 Test Suites --- * build * linux-log-parser * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * perf * fwts * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-sched-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * v4l2-compliance * ltp-open-posix-tests * kvm-unit-tests * rcutorture * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH net] rxrpc: Fix deadlock around release of dst cached on udp tunnel
Hello: This patch was applied to netdev/net.git (refs/heads/master): On Fri, 29 Jan 2021 23:53:50 + you wrote: > AF_RXRPC sockets use UDP ports in encap mode. This causes socket and dst > from an incoming packet to get stolen and attached to the UDP socket from > whence it is leaked when that socket is closed. > > When a network namespace is removed, the wait for dst records to be cleaned > up happens before the cleanup of the rxrpc and UDP socket, meaning that the > wait never finishes. > > [...] Here is the summary with links: - [net] rxrpc: Fix deadlock around release of dst cached on udp tunnel https://git.kernel.org/netdev/net/c/5399d52233c4 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
[PATCH v8 7/9] clk: qcom: Add WCSSAON reset
Add WCSSAON reset required for Q6v5 on IPQ8074 SoC.
Signed-off-by: Gokul Sriram Palanisamy
Signed-off-by: Sricharan R
Signed-off-by: Nikhil Prakash V
Acked-by: Stephen Boyd
---
drivers/clk/qcom/gcc-ipq8074.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/qcom/gcc-ipq8074.c b/drivers/clk/qcom/gcc-ipq8074.c
index 108fe27..d347364 100644
--- a/drivers/clk/qcom/gcc-ipq8074.c
+++ b/drivers/clk/qcom/gcc-ipq8074.c
@@ -4745,6 +4745,7 @@ static const struct qcom_reset_map gcc_ipq8074_resets[] =
{
[GCC_PCIE1_AXI_SLAVE_ARES] = { 0x76040, 4 },
[GCC_PCIE1_AHB_ARES] = { 0x76040, 5 },
[GCC_PCIE1_AXI_MASTER_STICKY_ARES] = { 0x76040, 6 },
+ [GCC_WCSSAON_RESET] = { 0x59010, 0 },
};
static const struct of_device_id gcc_ipq8074_match_table[] = {
--
2.7.4
[PATCH] arm64: dts: meson-gx: remove wrong reserved BL31 memory
Kernel boot fail on Khadas VIM1 VIM2 (meson GX) boards
SOLUTION: just remove wrong mem reservation for 0x1000 0x20
## Booting kernel from Legacy Image at 0808 ...
Image Name: kernel
Image Type: AArch64 Linux Kernel Image (lzma compressed)
Data Size:4657736 Bytes = 4.4 MiB
Load Address: 0f08
Entry Point: 0f08
Verifying Checksum ... OK
## Flattened Device Tree blob at 08008000
Booting using the fdt blob at 0x8008000
Uncompressing Kernel Image
ERROR: reserving fdt memory region failed (addr=1000 size=20)
Loading Device Tree to 7bf23000, end 7bf2d3ce ... OK
Starting kernel ...
bl31 reboot reason: 0xd
bl31 reboot reason: 0x0
system cmd 1.
Signed-off-by: Artem Lapkin
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 726b91d3a..71083b89d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -32,12 +32,6 @@ hwrom_reserved: hwrom@0 {
no-map;
};
- /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
- secmon_reserved: secmon@1000 {
- reg = <0x0 0x1000 0x0 0x20>;
- no-map;
- };
-
/* Alternate 3 MiB reserved for ARM Trusted Firmware (BL31) */
secmon_reserved_alt: secmon@500 {
reg = <0x0 0x0500 0x0 0x30>;
--
2.25.1
RE: [PATCH] platform/x86: dell-wmi-sysman: fix a NULL pointer dereference
> -Original Message-
> From: Limonciello, Mario
> Sent: 2021年1月30日 1:29
> To: Hans De Goede; Mark Gross
> Cc: LKML; platform-driver-...@vger.kernel.org; Bharathi, Divya; Ksr, Prasanth;
> Yuan, Perry
> Subject: RE: [PATCH] platform/x86: dell-wmi-sysman: fix a NULL pointer
> dereference
>
> +Divya, +Prasanth, +Perry
>
> > -Original Message-
> > From: Limonciello, Mario
> > Sent: Friday, January 29, 2021 11:27
> > To: Hans De Goede; Mark Gross
> > Cc: LKML; platform-driver-...@vger.kernel.org; Limonciello, Mario
> > Subject: [PATCH] platform/x86: dell-wmi-sysman: fix a NULL pointer
> > dereference
> >
> > An upcoming Dell platform is causing a NULL pointer dereference in
> > dell-wmi-sysman initialization. Validate that the input from BIOS
> > matches correct ACPI types and abort module initialization if it
> > fails.
> >
> > This leads to a memory leak that needs to be cleaned up properly.
> >
> > Signed-off-by: Mario Limonciello
> > ---
> > drivers/platform/x86/dell-wmi-sysman/sysman.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/platform/x86/dell-wmi-sysman/sysman.c
> > b/drivers/platform/x86/dell-wmi-sysman/sysman.c
> > index dc6dd531c996..38b497991071 100644
> > --- a/drivers/platform/x86/dell-wmi-sysman/sysman.c
> > +++ b/drivers/platform/x86/dell-wmi-sysman/sysman.c
> > @@ -419,13 +419,19 @@ static int init_bios_attributes(int attr_type,
> > const char *guid)
> > return retval;
> > /* need to use specific instance_id and guid combination to get
> > right data */
> > obj = get_wmiobj_pointer(instance_id, guid);
> > - if (!obj)
> > + if (!obj || obj->type != ACPI_TYPE_PACKAGE) {
> > + release_attributes_data();
> > return -ENODEV;
> > + }
> > elements = obj->package.elements;
> >
> > mutex_lock(_priv.mutex);
> > while (elements) {
> > /* sanity checking */
> > + if (elements[ATTR_NAME].type != ACPI_TYPE_STRING) {
> > + pr_debug("incorrect element type\n");
> > + goto nextobj;
> > + }
> > if (strlen(elements[ATTR_NAME].string.pointer) == 0) {
> > pr_debug("empty attribute found\n");
> > goto nextobj;
> > --
> > 2.25.1
Tested on the Dell laptop system which I found the issue.
Kernel can boot up with this new fix patch without any panic triggered.
Tested-by: Perry Yuan
[PATCH v8 4/9] remoteproc: qcom: Add ssr subdevice identifier
Add name for ssr subdevice on IPQ8074 SoC.
Signed-off-by: Gokul Sriram Palanisamy
Signed-off-by: Sricharan R
Signed-off-by: Nikhil Prakash V
---
drivers/remoteproc/qcom_q6v5_wcss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
b/drivers/remoteproc/qcom_q6v5_wcss.c
index 2ecbd73..eb804eb 100644
--- a/drivers/remoteproc/qcom_q6v5_wcss.c
+++ b/drivers/remoteproc/qcom_q6v5_wcss.c
@@ -1174,6 +1174,7 @@ static const struct wcss_data wcss_ipq8074_res_init = {
.crash_reason_smem = WCSS_CRASH_REASON,
.aon_reset_required = true,
.wcss_q6_reset_required = true,
+ .ssr_name = "q6wcss",
.ops = _wcss_ipq8074_ops,
.requires_force_stop = true,
.need_mem_protection = true,
--
2.7.4
[PATCH v9 4/4] remoteproc: qcom: wcss: explicitly request exclusive reset control
From: Govind Singh
Use request exclusive reset control for wcss reset controls.
Signed-off-by: Govind Singh
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/qcom_q6v5_wcss.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
b/drivers/remoteproc/qcom_q6v5_wcss.c
index 7a6cadc..7628259 100644
--- a/drivers/remoteproc/qcom_q6v5_wcss.c
+++ b/drivers/remoteproc/qcom_q6v5_wcss.c
@@ -788,21 +788,21 @@ static int q6v5_wcss_init_reset(struct q6v5_wcss *wcss,
struct device *dev = wcss->dev;
if (desc->aon_reset_required) {
- wcss->wcss_aon_reset = devm_reset_control_get(dev,
"wcss_aon_reset");
+ wcss->wcss_aon_reset = devm_reset_control_get_exclusive(dev,
"wcss_aon_reset");
if (IS_ERR(wcss->wcss_aon_reset)) {
dev_err(wcss->dev, "fail to acquire wcss_aon_reset\n");
return PTR_ERR(wcss->wcss_aon_reset);
}
}
- wcss->wcss_reset = devm_reset_control_get(dev, "wcss_reset");
+ wcss->wcss_reset = devm_reset_control_get_exclusive(dev, "wcss_reset");
if (IS_ERR(wcss->wcss_reset)) {
dev_err(wcss->dev, "unable to acquire wcss_reset\n");
return PTR_ERR(wcss->wcss_reset);
}
if (desc->wcss_q6_reset_required) {
- wcss->wcss_q6_reset = devm_reset_control_get(dev,
"wcss_q6_reset");
+ wcss->wcss_q6_reset = devm_reset_control_get_exclusive(dev,
"wcss_q6_reset");
if (IS_ERR(wcss->wcss_q6_reset)) {
dev_err(wcss->dev, "unable to acquire wcss_q6_reset\n");
return PTR_ERR(wcss->wcss_q6_reset);
--
2.7.4
[PATCH v9 3/4] remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404
From: Govind Singh
Add non PAS WCSS remoteproc driver support for QCS404 SOC.
Add WCSS q6 bootup and shutdown sequence handled from
Application Processor SubSystem(APSS).
Signed-off-by: Govind Singh
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/qcom_q6v5_wcss.c | 566 +---
1 file changed, 528 insertions(+), 38 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
b/drivers/remoteproc/qcom_q6v5_wcss.c
index d2e1416..7a6cadc 100644
--- a/drivers/remoteproc/qcom_q6v5_wcss.c
+++ b/drivers/remoteproc/qcom_q6v5_wcss.c
@@ -4,13 +4,18 @@
* Copyright (C) 2014 Sony Mobile Communications AB
* Copyright (c) 2012-2018, The Linux Foundation. All rights reserved.
*/
+#include
+#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
#include "qcom_common.h"
@@ -24,6 +29,9 @@
#define Q6SS_GFMUX_CTL_REG 0x020
#define Q6SS_PWR_CTL_REG 0x030
#define Q6SS_MEM_PWR_CTL 0x0B0
+#define Q6SS_STRAP_ACC 0x110
+#define Q6SS_CGC_OVERRIDE 0x034
+#define Q6SS_BCR_REG 0x6000
/* AXI Halt Register Offsets */
#define AXI_HALTREQ_REG0x0
@@ -37,14 +45,19 @@
#define Q6SS_CORE_ARES BIT(1)
#define Q6SS_BUS_ARES_ENABLE BIT(2)
+/* Q6SS_BRC_RESET */
+#define Q6SS_BRC_BLK_ARES BIT(0)
+
/* Q6SS_GFMUX_CTL */
#define Q6SS_CLK_ENABLEBIT(1)
+#define Q6SS_SWITCH_CLK_SRCBIT(8)
/* Q6SS_PWR_CTL */
#define Q6SS_L2DATA_STBY_N BIT(18)
#define Q6SS_SLP_RET_N BIT(19)
#define Q6SS_CLAMP_IO BIT(20)
#define QDSS_BHS_ONBIT(21)
+#define QDSS_Q6_MEMORIES GENMASK(15, 0)
/* Q6SS parameters */
#define Q6SS_LDO_BYP BIT(25)
@@ -53,6 +66,7 @@
#define Q6SS_CLAMP_QMC_MEM BIT(22)
#define HALT_CHECK_MAX_LOOPS 200
#define Q6SS_XO_CBCR GENMASK(5, 3)
+#define Q6SS_SLEEP_CBCRGENMASK(5, 2)
/* Q6SS config/status registers */
#define TCSR_GLOBAL_CFG0 0x0
@@ -71,9 +85,23 @@
#define TCSR_WCSS_CLK_MASK 0x1F
#define TCSR_WCSS_CLK_ENABLE 0x14
+#define MAX_HALT_REG 3
+enum {
+ WCSS_IPQ8074,
+ WCSS_QCS404,
+};
+
struct wcss_data {
const char *firmware_name;
unsigned int crash_reason_smem;
+ u32 version;
+ bool aon_reset_required;
+ bool wcss_q6_reset_required;
+ const char *ssr_name;
+ const char *sysmon_name;
+ int ssctl_id;
+ const struct rproc_ops *ops;
+ bool requires_force_stop;
};
struct q6v5_wcss {
@@ -87,9 +115,26 @@ struct q6v5_wcss {
u32 halt_wcss;
u32 halt_nc;
+ struct clk *xo;
+ struct clk *ahbfabric_cbcr_clk;
+ struct clk *gcc_abhs_cbcr;
+ struct clk *gcc_axim_cbcr;
+ struct clk *lcc_csr_cbcr;
+ struct clk *ahbs_cbcr;
+ struct clk *tcm_slave_cbcr;
+ struct clk *qdsp6ss_abhm_cbcr;
+ struct clk *qdsp6ss_sleep_cbcr;
+ struct clk *qdsp6ss_axim_cbcr;
+ struct clk *qdsp6ss_xo_cbcr;
+ struct clk *qdsp6ss_core_gfmux;
+ struct clk *lcc_bcr_sleep;
+ struct regulator *cx_supply;
+ struct qcom_sysmon *sysmon;
+
struct reset_control *wcss_aon_reset;
struct reset_control *wcss_reset;
struct reset_control *wcss_q6_reset;
+ struct reset_control *wcss_q6_bcr_reset;
struct qcom_q6v5 q6v5;
@@ -99,6 +144,8 @@ struct q6v5_wcss {
size_t mem_size;
unsigned int crash_reason_smem;
+ u32 version;
+ bool requires_force_stop;
struct qcom_rproc_glink glink_subdev;
struct qcom_rproc_ssr ssr_subdev;
@@ -244,6 +291,207 @@ static int q6v5_wcss_start(struct rproc *rproc)
return ret;
}
+static int q6v5_wcss_qcs404_power_on(struct q6v5_wcss *wcss)
+{
+ unsigned long val;
+ int ret, idx;
+
+ /* Toggle the restart */
+ reset_control_assert(wcss->wcss_reset);
+ usleep_range(200, 300);
+ reset_control_deassert(wcss->wcss_reset);
+ usleep_range(200, 300);
+
+ /* Enable GCC_WDSP_Q6SS_AHBS_CBCR clock */
+ ret = clk_prepare_enable(wcss->gcc_abhs_cbcr);
+ if (ret)
+ return ret;
+
+ /* Remove reset to the WCNSS QDSP6SS */
+ reset_control_deassert(wcss->wcss_q6_bcr_reset);
+
+ /* Enable Q6SSTOP_AHBFABRIC_CBCR clock */
+ ret = clk_prepare_enable(wcss->ahbfabric_cbcr_clk);
+ if (ret)
+ goto disable_gcc_abhs_cbcr_clk;
+
+ /* Enable the LCCCSR CBC clock, Q6SSTOP_Q6SSTOP_LCC_CSR_CBCR clock */
+ ret = clk_prepare_enable(wcss->lcc_csr_cbcr);
+ if (ret)
+ goto disable_ahbfabric_cbcr_clk;
+
+ /* Enable the Q6AHBS CBC, Q6SSTOP_Q6SS_AHBS_CBCR clock */
+ ret =
[PATCH v9 2/4] dt-bindings: remoteproc: qcom: Add Q6V5 Modem PIL binding for QCS404
From: Govind Singh Add a new modem compatible string for Qualcomm QCS404 SoCs Signed-off-by: Govind Singh Signed-off-by: Gokul Sriram Palanisamy Acked-by: Rob Herring --- .../devicetree/bindings/remoteproc/qcom,q6v5.txt | 15 +++ 1 file changed, 15 insertions(+) diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 7ccd553..69c49c7 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -9,6 +9,7 @@ on the Qualcomm Hexagon core. Definition: must be one of: "qcom,q6v5-pil", "qcom,ipq8074-wcss-pil" + "qcom,qcs404-wcss-pil" "qcom,msm8916-mss-pil", "qcom,msm8974-mss-pil" "qcom,msm8996-mss-pil" @@ -39,6 +40,7 @@ on the Qualcomm Hexagon core. string: qcom,q6v5-pil: qcom,ipq8074-wcss-pil: + qcom,qcs404-wcss-pil: qcom,msm8916-mss-pil: qcom,msm8974-mss-pil: must be "wdog", "fatal", "ready", "handover", "stop-ack" @@ -67,6 +69,11 @@ on the Qualcomm Hexagon core. Definition: The clocks needed depend on the compatible string: qcom,ipq8074-wcss-pil: no clock names required + qcom,qcs404-wcss-pil: + must be "xo", "gcc_abhs_cbcr", "gcc_abhs_cbcr", + "gcc_axim_cbcr", "lcc_ahbfabric_cbc", "tcsr_lcc_cbc", + "lcc_abhs_cbc", "lcc_tcm_slave_cbc", "lcc_abhm_cbc", + "lcc_axim_cbc", "lcc_bcr_sleep" qcom,q6v5-pil: qcom,msm8916-mss-pil: qcom,msm8974-mss-pil: @@ -133,6 +140,14 @@ For the compatible string below the following supplies are required: booting of the Hexagon core For the compatible string below the following supplies are required: + "qcom,qcs404-wcss-pil" +- cx-supply: + Usage: required + Value type: + Definition: reference to the regulators to be held on behalf of the + booting of the Hexagon core + +For the compatible string below the following supplies are required: "qcom,msm8996-mss-pil" - pll-supply: Usage: required -- 2.7.4
[PATCH v8 2/9] remoteproc: qcom: Add secure PIL support
IPQ8074 uses secure PIL. Hence, adding the support for the same.
Signed-off-by: Gokul Sriram Palanisamy
Signed-off-by: Sricharan R
Signed-off-by: Nikhil Prakash V
---
drivers/remoteproc/qcom_q6v5_wcss.c | 43 ++---
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
b/drivers/remoteproc/qcom_q6v5_wcss.c
index c0368bb..4e35e5c 100644
--- a/drivers/remoteproc/qcom_q6v5_wcss.c
+++ b/drivers/remoteproc/qcom_q6v5_wcss.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "qcom_common.h"
#include "qcom_pil_info.h"
#include "qcom_q6v5.h"
@@ -86,6 +87,9 @@
#define TCSR_WCSS_CLK_ENABLE 0x14
#define MAX_HALT_REG 3
+
+#define WCNSS_PAS_ID 6
+
enum {
WCSS_IPQ8074,
WCSS_QCS404,
@@ -134,6 +138,7 @@ struct q6v5_wcss {
unsigned int crash_reason_smem;
u32 version;
bool requires_force_stop;
+ bool need_mem_protection;
struct qcom_rproc_glink glink_subdev;
struct qcom_rproc_ssr ssr_subdev;
@@ -152,6 +157,7 @@ struct wcss_data {
int ssctl_id;
const struct rproc_ops *ops;
bool requires_force_stop;
+ bool need_mem_protection;
};
static int q6v5_wcss_reset(struct q6v5_wcss *wcss)
@@ -251,6 +257,15 @@ static int q6v5_wcss_start(struct rproc *rproc)
qcom_q6v5_prepare(>q6v5);
+ if (wcss->need_mem_protection) {
+ ret = qcom_scm_pas_auth_and_reset(WCNSS_PAS_ID);
+ if (ret) {
+ dev_err(wcss->dev, "wcss_reset failed\n");
+ return ret;
+ }
+ goto wait_for_reset;
+ }
+
/* Release Q6 and WCSS reset */
ret = reset_control_deassert(wcss->wcss_reset);
if (ret) {
@@ -285,6 +300,7 @@ static int q6v5_wcss_start(struct rproc *rproc)
if (ret)
goto wcss_q6_reset;
+wait_for_reset:
ret = qcom_q6v5_wait_for_start(>q6v5, 5 * HZ);
if (ret == -ETIMEDOUT)
dev_err(wcss->dev, "start timed out\n");
@@ -717,6 +733,15 @@ static int q6v5_wcss_stop(struct rproc *rproc)
struct q6v5_wcss *wcss = rproc->priv;
int ret;
+ if (wcss->need_mem_protection) {
+ ret = qcom_scm_pas_shutdown(WCNSS_PAS_ID);
+ if (ret) {
+ dev_err(wcss->dev, "not able to shutdown\n");
+ return ret;
+ }
+ goto pas_done;
+ }
+
/* WCSS powerdown */
if (wcss->requires_force_stop) {
ret = qcom_q6v5_request_stop(>q6v5, NULL);
@@ -741,6 +766,7 @@ static int q6v5_wcss_stop(struct rproc *rproc)
return ret;
}
+pas_done:
clk_disable_unprepare(wcss->prng_clk);
qcom_q6v5_unprepare(>q6v5);
@@ -764,9 +790,15 @@ static int q6v5_wcss_load(struct rproc *rproc, const
struct firmware *fw)
struct q6v5_wcss *wcss = rproc->priv;
int ret;
- ret = qcom_mdt_load_no_init(wcss->dev, fw, rproc->firmware,
- 0, wcss->mem_region, wcss->mem_phys,
- wcss->mem_size, >mem_reloc);
+ if (wcss->need_mem_protection)
+ ret = qcom_mdt_load(wcss->dev, fw, rproc->firmware,
+ WCNSS_PAS_ID, wcss->mem_region,
+ wcss->mem_phys, wcss->mem_size,
+ >mem_reloc);
+ else
+ ret = qcom_mdt_load_no_init(wcss->dev, fw, rproc->firmware,
+ 0, wcss->mem_region, wcss->mem_phys,
+ wcss->mem_size, >mem_reloc);
if (ret)
return ret;
@@ -1032,6 +1064,9 @@ static int q6v5_wcss_probe(struct platform_device *pdev)
if (!desc)
return -EINVAL;
+ if (desc->need_mem_protection && !qcom_scm_is_available())
+ return -EPROBE_DEFER;
+
rproc = rproc_alloc(>dev, pdev->name, desc->ops,
desc->firmware_name, sizeof(*wcss));
if (!rproc) {
@@ -1045,6 +1080,7 @@ static int q6v5_wcss_probe(struct platform_device *pdev)
wcss->version = desc->version;
wcss->requires_force_stop = desc->requires_force_stop;
+ wcss->need_mem_protection = desc->need_mem_protection;
ret = q6v5_wcss_init_mmio(wcss, pdev);
if (ret)
@@ -1115,6 +1151,7 @@ static const struct wcss_data wcss_ipq8074_res_init = {
.wcss_q6_reset_required = true,
.ops = _wcss_ipq8074_ops,
.requires_force_stop = true,
+ .need_mem_protection = true,
};
static const struct wcss_data wcss_qcs404_res_init = {
--
2.7.4
Re: [PATCH v5 net-next] net: Remove redundant calls of sk_tx_queue_clear().
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Fri, 29 Jan 2021 00:02:17 +0900 you wrote:
> The commit 41b14fb8724d ("net: Do not clear the sock TX queue in
> sk_set_socket()") removes sk_tx_queue_clear() from sk_set_socket() and adds
> it instead in sk_alloc() and sk_clone_lock() to fix an issue introduced in
> the commit e022f0b4a03f ("net: Introduce sk_tx_queue_mapping"). On the
> other hand, the original commit had already put sk_tx_queue_clear() in
> sk_prot_alloc(): the callee of sk_alloc() and sk_clone_lock(). Thus
> sk_tx_queue_clear() is called twice in each path.
>
> [...]
Here is the summary with links:
- [v5,net-next] net: Remove redundant calls of sk_tx_queue_clear().
https://git.kernel.org/netdev/net-next/c/df610cd9163b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH v7 3/5] counter: Add character device interface
On Thu, Jan 28, 2021 at 10:01:13AM +0100, Oleksij Rempel wrote:
> Hello William,
>
>
> On Fri, Dec 25, 2020 at 07:15:36PM -0500, William Breathitt Gray wrote:
> > This patch introduces a character device interface for the Counter
> > subsystem. Device data is exposed through standard character device read
> > operations. Device data is gathered when a Counter event is pushed by
> > the respective Counter device driver. Configuration is handled via ioctl
> > operations on the respective Counter character device node.
> >
> > Cc: David Lechner
> > Cc: Gwendal Grignou
> > Cc: Dan Carpenter
> > Signed-off-by: William Breathitt Gray
> > ---
> ...
> > +struct counter_event {
> > + __aligned_u64 timestamp;
> > + __aligned_u64 value;
> > + struct counter_watch watch;
> > + __u8 errno;
>
> This variable clashed in user space, as soon as you include errno.h,
> with the libc's "magic" definition of errno. What about "err" instead.
> I'm not sure it an __u8 is the proper type, IIRC usually it's an int.
>
> Regards,
> Oleksij
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Sure, I can rename this to avoid a possible clash with libc's errno.
Maybe "status" would be more apt to indicate that this is an exit status
for the event -- the code returned may simply be a warning and not
necessarily a critical error.
Regarding the datatype for this value, I've opened up the discussion in
my reply to David Lechner [1], so perhaps we can continue it there.
[1] https://lkml.org/lkml/2021/1/30/5
William Breathitt Gray
signature.asc
Description: PGP signature
Re: [PATCH v6 net-next] vmxnet3: Remove buf_info from device accessible structures
On Thu, 28 Jan 2021 11:38:34 -0800 Ronak Doshi wrote: > buf_info structures in RX & TX queues are private driver data that > do not need to be visible to the device. Although there is physical > address and length in the queue descriptor that points to these > structures, their layout is not standardized, and device never looks > at them. > > So lets allocate these structures in non-DMA-able memory, and fill > physical address as all-ones and length as zero in the queue > descriptor. > > That should alleviate worries brought by Martin Radev in > https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20210104/022829.html > that malicious vmxnet3 device could subvert SVM/TDX guarantees. > > Signed-off-by: Petr Vandrovec > Signed-off-by: Ronak Doshi Applied, thanks!
[PATCH v2 1/2] counter: 104-quad-8: Remove IIO counter ABI
The IIO counter driver has been superseded by the Counter subsystem as discussed in [1]. This patch removes the IIO counter ABI from the 104-QUAD-8 driver. [1] https://lore.kernel.org/lkml/20210119104105.1...@huawei.com/ Cc: Syed Nayyar Waris Signed-off-by: William Breathitt Gray --- .../testing/sysfs-bus-iio-counter-104-quad-8 | 133 MAINTAINERS | 1 - drivers/counter/104-quad-8.c | 653 ++ drivers/counter/Kconfig | 2 +- 4 files changed, 65 insertions(+), 724 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8 diff --git a/Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8 b/Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8 deleted file mode 100644 index bac3d0d48b7b.. --- a/Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8 +++ /dev/null @@ -1,133 +0,0 @@ -What: /sys/bus/iio/devices/iio:deviceX/in_count_count_mode_available -What: /sys/bus/iio/devices/iio:deviceX/in_count_noise_error_available -What: /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available -What: /sys/bus/iio/devices/iio:deviceX/in_index_index_polarity_available -What: /sys/bus/iio/devices/iio:deviceX/in_index_synchronous_mode_available -KernelVersion: 4.10 -Contact: linux-...@vger.kernel.org -Description: - This interface is deprecated; please use the Counter subsystem. - - Discrete set of available values for the respective counter - configuration are listed in this file. - -What: /sys/bus/iio/devices/iio:deviceX/in_countY_count_mode -KernelVersion: 4.10 -Contact: linux-...@vger.kernel.org -Description: - This interface is deprecated; please use the Counter subsystem. - - Count mode for channel Y. Four count modes are available: - normal, range limit, non-recycle, and modulo-n. The preset value - for channel Y is used by the count mode where required. - - Normal: - Counting is continuous in either direction. - - Range Limit: - An upper or lower limit is set, mimicking limit switches - in the mechanical counterpart. The upper limit is set to - the preset value, while the lower limit is set to 0. The - counter freezes at count = preset when counting up, and - at count = 0 when counting down. At either of these - limits, the counting is resumed only when the count - direction is reversed. - - Non-recycle: - Counter is disabled whenever a 24-bit count overflow or - underflow takes place. The counter is re-enabled when a - new count value is loaded to the counter via a preset - operation or write to raw. - - Modulo-N: - A count boundary is set between 0 and the preset value. - The counter is reset to 0 at count = preset when - counting up, while the counter is set to the preset - value at count = 0 when counting down; the counter does - not freeze at the bundary points, but counts - continuously throughout. - -What: /sys/bus/iio/devices/iio:deviceX/in_countY_noise_error -KernelVersion: 4.10 -Contact: linux-...@vger.kernel.org -Description: - This interface is deprecated; please use the Counter subsystem. - - Read-only attribute that indicates whether excessive noise is - present at the channel Y count inputs in quadrature clock mode; - irrelevant in non-quadrature clock mode. - -What: /sys/bus/iio/devices/iio:deviceX/in_countY_preset -KernelVersion: 4.10 -Contact: linux-...@vger.kernel.org -Description: - This interface is deprecated; please use the Counter subsystem. - - If the counter device supports preset registers, the preset - count for channel Y is provided by this attribute. - -What: /sys/bus/iio/devices/iio:deviceX/in_countY_quadrature_mode -KernelVersion: 4.10 -Contact: linux-...@vger.kernel.org -Description: - This interface is deprecated; please use the Counter subsystem. - - Configure channel Y counter for non-quadrature or quadrature - clock mode. Selecting non-quadrature clock mode will disable - synchronous load mode. In quadrature clock mode, the channel Y - scale attribute selects the encoder phase division (scale of 1 - selects full-cycle, scale of 0.5 selects half-cycle, scale of -
Re: [PATCH v7 3/5] counter: Add character device interface
On Wed, Dec 30, 2020 at 03:36:35PM -0600, David Lechner wrote:
> On 12/25/20 6:15 PM, William Breathitt Gray wrote:
>
> > diff --git a/include/uapi/linux/counter.h b/include/uapi/linux/counter.h
> > new file mode 100644
> > index ..7585dc9db19d
> > --- /dev/null
> > +++ b/include/uapi/linux/counter.h
> > @@ -0,0 +1,123 @@
> > +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > +/*
> > + * Userspace ABI for Counter character devices
> > + * Copyright (C) 2020 William Breathitt Gray
> > + */
> > +#ifndef _UAPI_COUNTER_H_
> > +#define _UAPI_COUNTER_H_
> > +
> > +#include
> > +#include
> > +
> > +/* Component type definitions */
> > +enum counter_component_type {
> > + COUNTER_COMPONENT_NONE,
> > + COUNTER_COMPONENT_SIGNAL,
> > + COUNTER_COMPONENT_COUNT,
> > + COUNTER_COMPONENT_FUNCTION,
> > + COUNTER_COMPONENT_SYNAPSE_ACTION,
> > + COUNTER_COMPONENT_EXTENSION,
> > +};
> > +
> > +/* Component scope definitions */
> > +enum counter_scope {
>
> Do we need COUNTER_SCOPE_NONE to go with COUNTER_COMPONENT_NONE?
COUNTER_COMPONENT_NONE alone should be fine because it already indicates
that the 'component' member of the struct counter_watch is to be ignored
(i.e. type, scope, etc. will not be evaluated and that section of code
is bypassed).
> > + COUNTER_SCOPE_DEVICE,
> > + COUNTER_SCOPE_SIGNAL,
> > + COUNTER_SCOPE_COUNT,
> > +};
> > +
> > +/**
> > + * struct counter_component - Counter component identification
> > + * @type: component type (Count, extension, etc.)
>
> Instead of "Count, extension, etc.", it could be more helpful
> to say one of enum counter_component_type.
Ack.
> > + * @scope: component scope (Device, Count, or Signal)
>
> Same here. @scope must be one of enum counter_scope.
Ack.
> > + * @parent: parent component identification number
> > + * @id: component identification number
>
> It could be helpful to say that these id numbers match
> the X/Y/Z in the sysfs paths as described in the sysfs
> ABI.
Ack.
> > + */
> > +struct counter_component {
> > + __u8 type;
> > + __u8 scope;
> > + __u8 parent;
> > + __u8 id;
> > +};
> > +
> > +/* Event type definitions */
> > +enum counter_event_type {
> > + COUNTER_EVENT_OVERFLOW,
> > + COUNTER_EVENT_UNDERFLOW,
> > + COUNTER_EVENT_OVERFLOW_UNDERFLOW,
> > + COUNTER_EVENT_THRESHOLD,
> > + COUNTER_EVENT_INDEX,
> > +};
> > +
> > +/**
> > + * struct counter_watch - Counter component watch configuration
> > + * @component: component to watch when event triggers
> > + * @event: event that triggers
>
> It would be helpful to say that @event must be one of
> enum counter_event_type.
Ack.
> > + * @channel: event channel
>
> It would be useful to say that @channel should be 0 unless
> a component has more than one event of the same type.
I'll make this clearer.
> > + */
> > +struct counter_watch {
> > + struct counter_component component;
> > + __u8 event;
> > + __u8 channel;
> > +};
> > +
> > +/* ioctl commands */
> > +#define COUNTER_CLEAR_WATCHES_IOCTL _IO(0x3E, 0x00)
> > +#define COUNTER_ADD_WATCH_IOCTL _IOW(0x3E, 0x01, struct counter_watch)
> > +#define COUNTER_LOAD_WATCHES_IOCTL _IO(0x3E, 0x02)
> > +
> > +/**
> > + * struct counter_event - Counter event data
> > + * @timestamp: best estimate of time of event occurrence, in nanoseconds
> > + * @value: component value
> > + * @watch: component watch configuration
> > + * @errno: system error number
> > + */
> > +struct counter_event {
> > + __aligned_u64 timestamp;
> > + __aligned_u64 value;
> > + struct counter_watch watch;
> > + __u8 errno;
>
> There are error codes larger than 255. Probably better
> make this __u32.
Are error codes larger than 255 actually useful in this case? I noticed
the exit() function will only return the least significant byte of
status to the parent: https://man7.org/linux/man-pages/man3/exit.3.html
William Breathitt Gray
signature.asc
Description: PGP signature
Re: [PATCH] drm/msm/dsi: save PLL registers across first PHY reset
On 10/30/20 6:55 AM, Dmitry Baryshkov wrote:
> Hello,
>
> On 07/10/2020 03:10, benl-kernelpatc...@squareup.com wrote:
>> From: Benjamin Li
>>
>> Take advantage of previously-added support for persisting PLL
>> registers across DSI PHY disable/enable cycles (see 328e1a6
>> 'drm/msm/dsi: Save/Restore PLL status across PHY reset') to
>> support persisting across the very first DSI PHY enable at
>> boot.
>
> Interesting enough, this breaks exactly on 8016. On DB410c with latest
> bootloader and w/o splash screen this patch causes boot freeze. Without this
> patch the board would successfully boot with display routed to HDMI.
Hi Dimtry,
Thanks for your fix for the DB410c breakage ("drm/msm/dsi: do not
try reading 28nm vco rate if it's not enabled") that this patch
causes.
I re-tested my patch on top of qcom/linux for-next (3e6a8ce094759)
which now has your fix, on a DB410c with HDMI display and no splash
(which seems to be the default using the Linaro SD card image's LK),
and indeed it is fixed.
I assume you already also did the same & are okay with this going in.
Appreciate the testing!
Ben
>
>> The bootloader may have left the PLL registers in a non-default
>> state. For example, for dsi_pll_28nm.c on 8x16/8x39, the byte
>> clock mux's power-on reset configuration is to bypass DIV1, but
>> depending on bandwidth requirements[1] the bootloader may have
>> set the DIV1 path.
>>
>> When the byte clock mux is registered with the generic clock
>> framework at probe time, the framework reads & caches the value
>> of the mux bit field (the initial clock parent). After PHY enable,
>> when clk_set_rate is called on the byte clock, the framework
>> assumes there is no need to reparent, and doesn't re-write the
>> mux bit field. But PHY enable resets PLL registers, so the mux
>> bit field actually silently reverted to the DIV1 bypass path.
>> This causes the byte clock to be off by a factor of e.g. 2 for
>> our tested WXGA panel.
>>
>> The above issue manifests as the display not working and a
>> constant stream of FIFO/LP0 contention errors.
>>
>> [1] The specific requirement for triggering the DIV1 path (and
>> thus this issue) on 28nm is a panel with pixel clock <116.7MHz
>> (one-third the minimum VCO setting). FHD/1080p (~145MHz) is fine,
>> WXGA/1280x800 (~75MHz) is not.
>>
>> Signed-off-by: Benjamin Li
>> ---
>> drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 16
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
>> b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
>> index 009f5b843dd1..139b4a5aaf86 100644
>> --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
>> +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
>> @@ -621,6 +621,22 @@ static int dsi_phy_driver_probe(struct platform_device
>> *pdev)
>> phy->pll = NULL;
>> }
>> + /*
>> + * As explained in msm_dsi_phy_enable, resetting the DSI PHY (as done
>> + * in dsi_mgr_phy_enable) silently changes its PLL registers to power-on
>> + * defaults, but the generic clock framework manages and caches several
>> + * of the PLL registers. It initializes these caches at registration
>> + * time via register read.
>> + *
>> + * As a result, we need to save DSI PLL registers once at probe in order
>> + * for the first call to msm_dsi_phy_enable to successfully bring PLL
>> + * registers back in line with what the generic clock framework expects.
>> + *
>> + * Subsequent PLL restores during msm_dsi_phy_enable will always be
>> + * paired with PLL saves in msm_dsi_phy_disable.
>> + */
>> + msm_dsi_pll_save_state(phy->pll);
>> +
>> dsi_phy_disable_resource(phy);
>> platform_set_drvdata(pdev, phy);
>>
>
>
cxgb4_ethtool.c:undefined reference to `ethtool_rx_flow_rule_create'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0e9bcda5d286f4a26a5407bb38f55c55b453ecfb commit: c8729cac2a11e4bc170f5d0041d5561bb7fe82a0 cxgb4: add ethtool n-tuple filter insertion date: 7 months ago config: powerpc64-randconfig-r033-20210130 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c8729cac2a11e4bc170f5d0041d5561bb7fe82a0 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout c8729cac2a11e4bc170f5d0041d5561bb7fe82a0 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o: in function `remove_one': cxgb4_main.c:(.text+0x9620): undefined reference to `unregister_netdev' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o: in function `t4_register_netevent_notifier': (.text+0x9fc0): undefined reference to `register_netevent_notifier' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o: in function `t4_fatal_err': (.text+0xa0c8): undefined reference to `netif_tx_stop_all_queues' powerpc-linux-ld: (.text+0xa0d0): undefined reference to `netif_carrier_off' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o: in function `cxgb_open': (.text+0xacf8): undefined reference to `netif_carrier_off' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o: in function `init_one': cxgb4_main.c:(.text+0xba64): undefined reference to `alloc_etherdev_mqs' powerpc-linux-ld: cxgb4_main.c:(.text+0xc720): undefined reference to `netdev_info' powerpc-linux-ld: cxgb4_main.c:(.text+0xc744): undefined reference to `netif_set_real_num_tx_queues' powerpc-linux-ld: cxgb4_main.c:(.text+0xc750): undefined reference to `netif_set_real_num_rx_queues' powerpc-linux-ld: cxgb4_main.c:(.text+0xc758): undefined reference to `netif_carrier_off' powerpc-linux-ld: cxgb4_main.c:(.text+0xc760): undefined reference to `register_netdev' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o: in function `t4_os_portmod_changed': (.text.unlikely+0xb5c): undefined reference to `netdev_info' powerpc-linux-ld: (.text.unlikely+0xbb4): undefined reference to `netdev_info' powerpc-linux-ld: (.text.unlikely+0xc68): undefined reference to `netdev_info' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o: in function `__crc_cxgb4_remove_server_filter': (.rodata+0x344): undefined reference to `eth_validate_addr' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/l2t.o: in function `neigh_event_send.constprop.0': l2t.c:(.text+0x690): undefined reference to `__neigh_event_send' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/l2t.o: in function `write_l2e': l2t.c:(.text+0x788): undefined reference to `__alloc_skb' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/l2t.o: in function `neigh_release': l2t.c:(.text+0xb64): undefined reference to `neigh_destroy' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/l2t.o: in function `cxgb4_l2t_release': (.text+0xe74): undefined reference to `kfree_skb' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/l2t.o: in function `t4_l2t_alloc_switching': (.text+0x1b68): undefined reference to `kfree_skb' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/smt.o: in function `cxgb4_smt_alloc_switching': (.text+0x294): undefined reference to `__alloc_skb' powerpc-linux-ld: (.text+0x2cc): undefined reference to `__alloc_skb' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/sge.o: in function `ctrl_xmit': sge.c:(.text+0x1024): undefined reference to `consume_skb' powerpc-linux-ld: sge.c:(.text+0x1160): undefined reference to `kfree_skb' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/sge.o: in function `restart_ctrlq': sge.c:(.text+0x1240): undefined reference to `kfree_skb' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/sge.o: in function `skb_tx_timestamp': sge.c:(.text+0x1560): undefined reference to `skb_tstamp_tx' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/sge.o: in function `t4_systim_to_hwstamp.isra.0': sge.c:(.text+0x19a4): undefined reference to `skb_pull' powerpc-linux-ld: drivers/net/ethernet/chelsio/cxgb4/sge.o: in function `napi_schedule': sge.c:(.text+0x1a1c): undefined reference to `napi_schedule_prep' powerpc-linux-ld:
[PATCH v4 05/34] keembay-ipc: Add Keem Bay IPC module
From: Daniele Alessandrelli On the Intel Movidius SoC code named Keem Bay, communication between the Application Processor(AP) and the VPU is enabled by the Keem Bay Inter-Processor Communication (IPC) mechanism. Add the driver for using Keem Bay IPC from within the Linux Kernel. The IPC uses the following terminology: - Node:A processing entity that can use the IPC to communicate (currently, we just have two nodes, the AP and the VPU). - Link:Two nodes that can communicate over IPC form an IPC link (currently, we just have one link, the one formed by the AP and the VPU). - Channel: An IPC link can provide multiple IPC channels. IPC channels allow communication multiplexing, i.e., the same IPC link can be used by different applications for different communications. Each channel is identified by a channel ID, which must be unique within a single IPC link. Channels are divided in two categories, High-Speed (HS) channels and General-Purpose (GP) channels. HS channels have higher priority over GP channels. The Keem Bay IPC mechanism is built on top of the VPU IPC mailbox, which allows the AP and the VPU to exchange 32-bit messages. Specifically, the IPC uses shared memory (shared between the AP and the VPU) to allocate IPC packets and then exchanges them using the VPU IPC mailbox (the 32-bit physical address of the packet is passed as a message to the VPU IPC mailbox). IPC packets have a fixed structure containing the (VPU) physical address of the payload (which must be located in shared memory too) as well as other information (payload size, IPC channel ID, etc.). Each IPC node (i.e., both the AP and the VPU) has its own reserved memory region (in shared memory) from which it instantiates its own pool of IPC packets. When instantiated, IPC packets are marked as free. When the node needs to send an IPC message, it gets the first free packet it finds (from its own pool), marks it as allocated (used), and transfer its physical address to the destination node using the VPU IPC mailbox. The destination node uses the received physical address to access the IPC packet, process the packet, and, once done with it, marks it as free (so that the sender can reuse it). Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Borislav Petkov Cc: Damien Le Moal Cc: Peng Fan Cc: Shawn Guo Reviewed-by: Mark Gross Signed-off-by: Daniele Alessandrelli Signed-off-by: Mark Gross --- MAINTAINERS |8 + drivers/soc/Kconfig |1 + drivers/soc/Makefile |1 + drivers/soc/intel/Kconfig | 18 + drivers/soc/intel/Makefile|4 + drivers/soc/intel/keembay-ipc.c | 1364 + include/linux/soc/intel/keembay-ipc.h | 30 + 7 files changed, 1426 insertions(+) create mode 100644 drivers/soc/intel/Kconfig create mode 100644 drivers/soc/intel/Makefile create mode 100644 drivers/soc/intel/keembay-ipc.c create mode 100644 include/linux/soc/intel/keembay-ipc.h diff --git a/MAINTAINERS b/MAINTAINERS index de23f6e5cfce..684e64e958a4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9060,6 +9060,14 @@ F: drivers/crypto/keembay/keembay-ocs-aes-core.c F: drivers/crypto/keembay/ocs-aes.c F: drivers/crypto/keembay/ocs-aes.h +INTEL KEEM BAY IPC DRIVER +M: Daniele Alessandrelli +M: Mark Gross +S: Supported +F: Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml +F: drivers/soc/intel/keembay-ipc.c +F: include/linux/soc/intel/keembay-ipc.h + INTEL MANAGEMENT ENGINE (mei) M: Tomas Winkler L: linux-kernel@vger.kernel.org diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index d097d070f579..b9d69a1eedc7 100644 --- a/drivers/soc/Kconfig +++ b/drivers/soc/Kconfig @@ -8,6 +8,7 @@ source "drivers/soc/atmel/Kconfig" source "drivers/soc/bcm/Kconfig" source "drivers/soc/fsl/Kconfig" source "drivers/soc/imx/Kconfig" +source "drivers/soc/intel/Kconfig" source "drivers/soc/ixp4xx/Kconfig" source "drivers/soc/litex/Kconfig" source "drivers/soc/mediatek/Kconfig" diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 699b758d28e4..1a6c00d2e32e 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -12,6 +12,7 @@ obj-$(CONFIG_MACH_DOVE) += dove/ obj-y += fsl/ obj-$(CONFIG_ARCH_GEMINI) += gemini/ obj-y += imx/ +obj-y += intel/ obj-$(CONFIG_ARCH_IXP4XX) += ixp4xx/ obj-$(CONFIG_SOC_XWAY) += lantiq/ obj-$(CONFIG_LITEX_SOC_CONTROLLER) += litex/ diff --git a/drivers/soc/intel/Kconfig b/drivers/soc/intel/Kconfig new file mode 100644 index ..a575e31e47b4 --- /dev/null +++ b/drivers/soc/intel/Kconfig @@ -0,0 +1,18 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Keem Bay SoC drivers +# + +menu "Intel SoC drivers" +
[PATCH v3 28/34] misc: Intel tsens IA host driver.
From: "C, Udhayakumar"
Add Intel tsens IA host driver for Intel Edge.AI Computer Vision
platforms.
About Intel Edge.AI Computer Vision platforms:
-
The Intel Edge.AI Computer Vision platforms are vision processing systems
targeting machine vision applications for connected devices.
They are based on ARM A53 CPU running Linux and acts as a PCIe
endpoint device.
High-level architecture:
Remote Host IA CPU Local Host ARM CPU
--
| Platform| | Thermal Daemon|
| Management SW| ||
--
| Intel tsens | | intel tsens i2c slave |
| i2c client | | and thermal driver|
--
| XLINK I2C | | XLINK I2C Slave |
| controller | <=> | controller |
xlink smbus --
intel tsens module:
---
The tsens module enables reading of on chip sensors present
in the Intel Edge.AI Computer Vision platforms.In the tsens module
various junction and SoC temperatures are reported using thermal
subsystem and i2c subsystem.
Temperature data reported using thermal subsystem will be used for
various cooling agents such as DVFS, fan control and shutdown the
system in case of critical temperature.
Temperature data reported using i2c subsystem will be used by
platform manageability software running in IA host.
- Remote Host driver
* Intended for IA CPU
* It is a I2C client driver
* Driver path:
{tree}/drivers/misc/intel_tsens/intel_tsens_host.c
Local host and Remote host drivers communicates using
I2C SMBUS protocol.
Acked-by: Mark Mross
Signed-off-by: C, Udhayakumar
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/intel_tsens_host.rst| 71
drivers/misc/intel_tsens/Kconfig| 13 +
drivers/misc/intel_tsens/Makefile | 1 +
drivers/misc/intel_tsens/intel_tsens_host.c | 351
include/linux/intel_tsens_host.h| 34 ++
6 files changed, 471 insertions(+)
create mode 100644 Documentation/hwmon/intel_tsens_host.rst
create mode 100644 drivers/misc/intel_tsens/intel_tsens_host.c
create mode 100644 include/linux/intel_tsens_host.h
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index fc29100bef73..7a9eaddd1ab3 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -81,6 +81,7 @@ Hardware Monitoring Kernel Drivers
isl68137
it87
intel_tsens_sensor.rst
+ intel_tsens_host.rst
jc42
k10temp
k8temp
diff --git a/Documentation/hwmon/intel_tsens_host.rst
b/Documentation/hwmon/intel_tsens_host.rst
new file mode 100644
index ..012c593f969f
--- /dev/null
+++ b/Documentation/hwmon/intel_tsens_host.rst
@@ -0,0 +1,71 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+Kernel driver: intel_tsens
+==
+
+Supported chips:
+ * Intel Edge.AI Computer Vision platforms: Keem Bay
+
+Slave address: The address is assigned by the hddl device management
+ driver.
+
+Datasheet:
+ Documentation/hwmon/intel_tsens_sensor.rst#Remote Thermal Interface
+
+Authors:
+- Thalaiappan, Rathina
+
+Description
+===
+The intel_tsens is a temperature sensor driver receiving the junction
temperature
+from different heating points inside the SOC. The driver will receive the
+temperature on SMBUS connection. The reported temperature is in degrees
Celsius.
+
+In Keem Bay, the four thermal junction temperature points are,
+Media Subsystem (mss), NN subsystem (nce), Compute subsystem (cse) and
+SOC(Maximum of mss, nce and cse).
+
+Example
+===
+Temperature reported by a Keem Bay on the Linux Thermal sysfs interface.
+
+# cat /sys/class/thermal/thermal_zone*/type
+mss
+css
+nce
+soc
+
+# cat /sys/class/thermal/thermal_zone*/temp
+0
+29210
+28478
+29210
+
++---+-+
+| offset| Sensor|
++---+-+
+| 0 | mss |
++---+-+
+| 1 | css |
++---+-+
+| 2 | nce |
++---+-+
+| 3 | soc |
++---+-+
+
+#sudo i2cdetect -l
+i2c-8 smbus SMBus I801 adapter at efa0 SMBus adapte
r
+
+To read mss junction temperature:
+#i2cget -y 8 0x0 w
+
+To read cse junction temperature:
+#i2cget -y 8 0x1 w
+
+To read nce junction temperature:
+#i2cget -y 8 0x2 w
+
+To read overall SoC temperature:
+#i2cget -y 8 0x3 w
diff --git a/drivers/misc/intel_tsens/Kconfig b/drivers/misc/intel_tsens/Kconfig
index
[PATCH v3 00/34] Intel Vision Processing base enabling
From: Mark Gross The Intel Vision Processing Unit (VPU) is an IP block that is showing up for the first time as part of the Keem Bay SOC. Keem Bay is a quad core A53 Arm SOC. It is designed to be used as a stand alone SOC as well as in an PCIe Vision Processing accelerator add in card. This thrid version of this patch set includes updates to xling-pci some minor updates to a Kconfig help text and global use of EXPORT_SYMBOL_GPL based on review feedback. At the bottom of this coverletter is the delta between v2 and V3 for easy review of the modifications. Feels like things are converging. :) Thanks for looking at these and providing feedback. --mark C, Udhayakumar (8): dt-bindings: misc: intel_tsens: Add tsens thermal bindings documentation misc: Tsens ARM host thermal driver. misc: Intel tsens IA host driver. Intel tsens i2c slave driver. misc:intel_tsens: Intel Keem Bay tsens driver. dt-bindings: misc: hddl_dev: Add hddl device management documentation misc: Hddl device management for local host misc: HDDL device management for IA host Daniele Alessandrelli (4): dt-bindings: mailbox: Add Intel VPU IPC mailbox bindings mailbox: vpu-ipc-mailbox: Add support for Intel VPU IPC mailbox dt-bindings: Add bindings for Keem Bay IPC driver keembay-ipc: Add Keem Bay IPC module Li, Tingqian (2): dt-bindings: misc: Add Keem Bay vpumgr misc: Add Keem Bay VPU manager Paul Murphy (2): dt-bindings: Add bindings for Keem Bay VPU IPC driver keembay-vpu-ipc: Add Keem Bay VPU IPC module Ramya P Karanth (1): Intel Keem Bay XLink SMBus driver Seamus Kelly (7): xlink-ipc: Add xlink ipc device tree bindings xlink-ipc: Add xlink ipc driver xlink-core: Add xlink core device tree bindings xlink-core: Add xlink core driver xLink xlink-core: Enable xlink protocol over pcie xlink-core: Enable VPU IP management and runtime control xlink-core: add async channel and events Srikanth Thokala (9): misc: xlink-pcie: Add documentation for XLink PCIe driver misc: xlink-pcie: lh: Add PCIe EPF driver for Local Host misc: xlink-pcie: lh: Add PCIe EP DMA functionality misc: xlink-pcie: lh: Add core communication logic misc: xlink-pcie: lh: Prepare changes for adding remote host driver misc: xlink-pcie: rh: Add PCIe EP driver for Remote Host misc: xlink-pcie: rh: Add core communication logic misc: xlink-pcie: Add XLink API interface misc: xlink-pcie: Add asynchronous event notification support for XLink mark gross (1): Add Vision Processing Unit (VPU) documentation. .../mailbox/intel,vpu-ipc-mailbox.yaml| 69 + .../bindings/misc/intel,hddl-client.yaml | 114 + .../bindings/misc/intel,intel-tsens.yaml | 122 + .../bindings/misc/intel,keembay-vpu-mgr.yaml | 48 + .../misc/intel,keembay-xlink-ipc.yaml | 49 + .../bindings/misc/intel,keembay-xlink.yaml| 27 + .../bindings/soc/intel/intel,keembay-ipc.yaml | 45 + .../soc/intel/intel,keembay-vpu-ipc.yaml | 153 ++ Documentation/hwmon/index.rst |2 + Documentation/hwmon/intel_tsens_host.rst | 71 + Documentation/hwmon/intel_tsens_sensor.rst| 67 + Documentation/i2c/busses/index.rst|1 + .../i2c/busses/intel-xlink-smbus.rst | 71 + Documentation/index.rst |1 + .../misc-devices/hddl_device_client.rst | 212 ++ .../misc-devices/hddl_device_server.rst | 205 ++ Documentation/misc-devices/index.rst |2 + Documentation/vpu/index.rst | 20 + Documentation/vpu/vpu-stack-overview.rst | 270 +++ Documentation/vpu/xlink-core.rst | 81 + Documentation/vpu/xlink-ipc.rst | 51 + Documentation/vpu/xlink-pcie.rst | 90 + MAINTAINERS | 54 + drivers/mailbox/Kconfig | 11 + drivers/mailbox/Makefile |2 + drivers/mailbox/vpu-ipc-mailbox.c | 297 +++ drivers/misc/Kconfig |7 + drivers/misc/Makefile |7 + drivers/misc/hddl_device/Kconfig | 26 + drivers/misc/hddl_device/Makefile |7 + drivers/misc/hddl_device/hddl_device.c| 565 + drivers/misc/hddl_device/hddl_device_lh.c | 764 +++ drivers/misc/hddl_device/hddl_device_rh.c | 837 +++ drivers/misc/hddl_device/hddl_device_util.h | 52 + drivers/misc/intel_tsens/Kconfig | 55 + drivers/misc/intel_tsens/Makefile | 10 + drivers/misc/intel_tsens/intel_tsens_host.c | 351 +++ drivers/misc/intel_tsens/intel_tsens_i2c.c| 119 + .../misc/intel_tsens/intel_tsens_thermal.c| 651 ++ .../misc/intel_tsens/intel_tsens_thermal.h| 38 + drivers/misc/intel_tsens/keembay_thermal.c| 169 ++ drivers/misc/intel_tsens/keembay_tsens.h | 366 +++ drivers/misc/vpumgr/Kconfig |
[PATCH v3 11/34] misc: xlink-pcie: lh: Add core communication logic
From: Srikanth Thokala
Add logic to establish communication with the remote host which is through
ring buffer management and MSI/Doorbell interrupts
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
drivers/misc/xlink-pcie/local_host/Makefile | 2 +
drivers/misc/xlink-pcie/local_host/core.c | 806
drivers/misc/xlink-pcie/local_host/core.h | 247 ++
drivers/misc/xlink-pcie/local_host/epf.c| 116 ++-
drivers/misc/xlink-pcie/local_host/epf.h| 23 +
drivers/misc/xlink-pcie/local_host/util.c | 375 +
drivers/misc/xlink-pcie/local_host/util.h | 70 ++
drivers/misc/xlink-pcie/local_host/xpcie.h | 63 ++
include/linux/xlink_drv_inf.h | 58 ++
9 files changed, 1752 insertions(+), 8 deletions(-)
create mode 100644 drivers/misc/xlink-pcie/local_host/core.c
create mode 100644 drivers/misc/xlink-pcie/local_host/core.h
create mode 100644 drivers/misc/xlink-pcie/local_host/util.c
create mode 100644 drivers/misc/xlink-pcie/local_host/util.h
create mode 100644 include/linux/xlink_drv_inf.h
diff --git a/drivers/misc/xlink-pcie/local_host/Makefile
b/drivers/misc/xlink-pcie/local_host/Makefile
index 54fc118e2dd1..28761751d43b 100644
--- a/drivers/misc/xlink-pcie/local_host/Makefile
+++ b/drivers/misc/xlink-pcie/local_host/Makefile
@@ -1,3 +1,5 @@
obj-$(CONFIG_XLINK_PCIE_LH_DRIVER) += mxlk_ep.o
mxlk_ep-objs := epf.o
mxlk_ep-objs += dma.o
+mxlk_ep-objs += core.o
+mxlk_ep-objs += util.o
diff --git a/drivers/misc/xlink-pcie/local_host/core.c
b/drivers/misc/xlink-pcie/local_host/core.c
new file mode 100644
index ..c67ce2c3067d
--- /dev/null
+++ b/drivers/misc/xlink-pcie/local_host/core.c
@@ -0,0 +1,806 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel Keem Bay XLink PCIe Driver
+ *
+ * Copyright (C) 2021 Intel Corporation
+ */
+
+#include
+
+#include "epf.h"
+#include "core.h"
+#include "util.h"
+
+static struct xpcie *global_xpcie;
+
+static struct xpcie *intel_xpcie_core_get_by_id(u32 sw_device_id)
+{
+ return (sw_device_id == xlink_sw_id) ? global_xpcie : NULL;
+}
+
+static int intel_xpcie_map_dma(struct xpcie *xpcie, struct xpcie_buf_desc *bd,
+ int direction)
+{
+ struct xpcie_epf *xpcie_epf = container_of(xpcie,
+ struct xpcie_epf, xpcie);
+ struct pci_epf *epf = xpcie_epf->epf;
+ struct device *dma_dev = epf->epc->dev.parent;
+
+ bd->phys = dma_map_single(dma_dev, bd->data, bd->length, direction);
+
+ return dma_mapping_error(dma_dev, bd->phys);
+}
+
+static void intel_xpcie_unmap_dma(struct xpcie *xpcie,
+ struct xpcie_buf_desc *bd, int direction)
+{
+ struct xpcie_epf *xpcie_epf = container_of(xpcie,
+ struct xpcie_epf, xpcie);
+ struct pci_epf *epf = xpcie_epf->epf;
+ struct device *dma_dev = epf->epc->dev.parent;
+
+ dma_unmap_single(dma_dev, bd->phys, bd->length, direction);
+}
+
+static void intel_xpcie_set_cap_txrx(struct xpcie *xpcie)
+{
+ size_t tx_len = sizeof(struct xpcie_transfer_desc) *
+ XPCIE_NUM_TX_DESCS;
+ size_t rx_len = sizeof(struct xpcie_transfer_desc) *
+ XPCIE_NUM_RX_DESCS;
+ size_t hdr_len = sizeof(struct xpcie_cap_txrx);
+ u32 start = sizeof(struct xpcie_mmio);
+ struct xpcie_cap_txrx *cap;
+ struct xpcie_cap_hdr *hdr;
+ u16 next;
+
+ next = (u16)(start + hdr_len + tx_len + rx_len);
+ intel_xpcie_iowrite32(start, xpcie->mmio + XPCIE_MMIO_CAP_OFF);
+ cap = (void *)xpcie->mmio + start;
+ memset(cap, 0, sizeof(struct xpcie_cap_txrx));
+ cap->hdr.id = XPCIE_CAP_TXRX;
+ cap->hdr.next = next;
+ cap->fragment_size = XPCIE_FRAGMENT_SIZE;
+ cap->tx.ring = start + hdr_len;
+ cap->tx.ndesc = XPCIE_NUM_TX_DESCS;
+ cap->rx.ring = start + hdr_len + tx_len;
+ cap->rx.ndesc = XPCIE_NUM_RX_DESCS;
+
+ hdr = (struct xpcie_cap_hdr *)((void *)xpcie->mmio + next);
+ hdr->id = XPCIE_CAP_NULL;
+}
+
+static void intel_xpcie_txrx_cleanup(struct xpcie *xpcie)
+{
+ struct xpcie_epf *xpcie_epf = container_of(xpcie,
+ struct xpcie_epf, xpcie);
+ struct device *dma_dev = xpcie_epf->epf->epc->dev.parent;
+ struct xpcie_interface *inf = >interfaces[0];
+ struct xpcie_stream *tx = >tx;
+ struct xpcie_stream *rx = >rx;
+ struct xpcie_transfer_desc *td;
+ int index;
+
+ xpcie->stop_flag = true;
+ xpcie->no_tx_buffer = false;
+ inf->data_avail = true;
+ wake_up_interruptible(>tx_waitq);
+ wake_up_interruptible(>rx_waitq);
+ mutex_lock(>wlock);
+ mutex_lock(>rlock);
+
+ for (index = 0; index < rx->pipe.ndesc; index++) {
+ td =
Re: [PATCH v1 0/2] Make fw_devlink=on more forgiving
On Fri, Jan 29, 2021 at 8:03 PM Saravana Kannan wrote:
>
> This patch series solves two general issues with fw_devlink=on
>
> Patch 1/2 addresses the issue of firmware nodes that look like they'll
> have struct devices created for them, but will never actually have
> struct devices added for them. For example, DT nodes with a compatible
> property that don't have devices added for them.
>
> Patch 2/2 address (for static kernels) the issue of optional suppliers
> that'll never have a driver registered for them. So, if the device could
> have probed with fw_devlink=permissive with a static kernel, this patch
> should allow those devices to probe with a fw_devlink=on. This doesn't
> solve it for the case where modules are enabled because there's no way
> to tell if a driver will never be registered or it's just about to be
> registered. I have some other ideas for that, but it'll have to come
> later thinking about it a bit.
>
> These two patches might remove the need for several other patches that
> went in as fixes for commit e590474768f1 ("driver core: Set
> fw_devlink=on by default"), but I think all those fixes are good
> changes. So I think we should leave those in.
>
> Marek, Geert,
>
> Can you try this series on a static kernel with your OF_POPULATED
> changes reverted? I just want to make sure these patches can identify
> and fix those cases.
>
> Tudor,
>
> You should still make the clock driver fix (because it's a bug), but I
> think this series will fix your issue too (even without the clock driver
> fix). Can you please give this a shot?
Marek, Geert, Tudor,
Forgot to say that this will probably fix your issues only in a static
kernel. So please try this with a static kernel. If you can also try
and confirm that this does not fix the issue for a modular kernel,
that'd be good too.
-Saravana
>
> Marc,
>
> Can you try this series with the gpiolib fix reverted please? I'm pretty
> sure this will fix that case.
>
> Linus,
>
> This series very likely removes the need for the gpiolib patch (we can
> wait for Marc to confirm). I'm split on whether we should leave it in or
> not. Thoughts?
>
> Thanks,
> Saravana
>
> Saravana Kannan (2):
> driver core: fw_devlink: Detect supplier devices that will never be
> added
> driver core: fw_devlink: Handle missing drivers for optional suppliers
>
> drivers/base/base.h | 2 +
> drivers/base/core.c | 134 +---
> drivers/base/dd.c | 5 ++
> 3 files changed, 121 insertions(+), 20 deletions(-)
>
> --
> 2.30.0.365.g02bc693789-goog
>
[PATCH v4 10/34] misc: xlink-pcie: lh: Add PCIe EP DMA functionality
From: Srikanth Thokala Add Synopsys PCIe DWC core embedded-DMA functionality for local host Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Reviewed-by: Mark Gross Signed-off-by: Mark Gross Signed-off-by: Srikanth Thokala --- drivers/misc/xlink-pcie/local_host/Makefile | 1 + drivers/misc/xlink-pcie/local_host/dma.c| 575 drivers/misc/xlink-pcie/local_host/epf.c| 15 +- drivers/misc/xlink-pcie/local_host/epf.h| 41 ++ 4 files changed, 629 insertions(+), 3 deletions(-) create mode 100644 drivers/misc/xlink-pcie/local_host/dma.c diff --git a/drivers/misc/xlink-pcie/local_host/Makefile b/drivers/misc/xlink-pcie/local_host/Makefile index 514d3f0c91bc..54fc118e2dd1 100644 --- a/drivers/misc/xlink-pcie/local_host/Makefile +++ b/drivers/misc/xlink-pcie/local_host/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_XLINK_PCIE_LH_DRIVER) += mxlk_ep.o mxlk_ep-objs := epf.o +mxlk_ep-objs += dma.o diff --git a/drivers/misc/xlink-pcie/local_host/dma.c b/drivers/misc/xlink-pcie/local_host/dma.c new file mode 100644 index ..42978fb0db49 --- /dev/null +++ b/drivers/misc/xlink-pcie/local_host/dma.c @@ -0,0 +1,575 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Intel Keem Bay XLink PCIe Driver + * + * Copyright (C) 2021 Intel Corporation + */ +#include +#include +#include + +#include "epf.h" + +#define DMA_DBI_OFFSET (0x38) + +/* PCIe DMA control 1 register definitions. */ +#define DMA_CH_CONTROL1_CB_SHIFT (0) +#define DMA_CH_CONTROL1_TCB_SHIFT (1) +#define DMA_CH_CONTROL1_LLP_SHIFT (2) +#define DMA_CH_CONTROL1_LIE_SHIFT (3) +#define DMA_CH_CONTROL1_CS_SHIFT (5) +#define DMA_CH_CONTROL1_CCS_SHIFT (8) +#define DMA_CH_CONTROL1_LLE_SHIFT (9) +#define DMA_CH_CONTROL1_CB_MASK(BIT(DMA_CH_CONTROL1_CB_SHIFT)) +#define DMA_CH_CONTROL1_TCB_MASK (BIT(DMA_CH_CONTROL1_TCB_SHIFT)) +#define DMA_CH_CONTROL1_LLP_MASK (BIT(DMA_CH_CONTROL1_LLP_SHIFT)) +#define DMA_CH_CONTROL1_LIE_MASK (BIT(DMA_CH_CONTROL1_LIE_SHIFT)) +#define DMA_CH_CONTROL1_CS_MASK(0x3 << DMA_CH_CONTROL1_CS_SHIFT) +#define DMA_CH_CONTROL1_CCS_MASK (BIT(DMA_CH_CONTROL1_CCS_SHIFT)) +#define DMA_CH_CONTROL1_LLE_MASK (BIT(DMA_CH_CONTROL1_LLE_SHIFT)) + +/* DMA control 1 register Channel Status */ +#define DMA_CH_CONTROL1_CS_RUNNING (0x1 << DMA_CH_CONTROL1_CS_SHIFT) +#define DMA_CH_CONTROL1_CS_HALTED (0x2 << DMA_CH_CONTROL1_CS_SHIFT) +#define DMA_CH_CONTROL1_CS_STOPPED (0x3 << DMA_CH_CONTROL1_CS_SHIFT) + +/* PCIe DMA Engine enable register definitions. */ +#define DMA_ENGINE_EN_SHIFT(0) +#define DMA_ENGINE_EN_MASK (BIT(DMA_ENGINE_EN_SHIFT)) + +/* PCIe DMA interrupt registers definitions. */ +#define DMA_ABORT_INTERRUPT_SHIFT (16) +#define DMA_ABORT_INTERRUPT_MASK (0xFF << DMA_ABORT_INTERRUPT_SHIFT) +#define DMA_ABORT_INTERRUPT_CH_MASK(_c) (BIT(_c) << DMA_ABORT_INTERRUPT_SHIFT) +#define DMA_DONE_INTERRUPT_MASK(0xFF) +#define DMA_DONE_INTERRUPT_CH_MASK(_c) (BIT(_c)) +#define DMA_ALL_INTERRUPT_MASK \ + (DMA_ABORT_INTERRUPT_MASK | DMA_DONE_INTERRUPT_MASK) + +#define DMA_LL_ERROR_SHIFT (16) +#define DMA_CPL_ABORT_SHIFT(8) +#define DMA_CPL_TIMEOUT_SHIFT (16) +#define DMA_DATA_POI_SHIFT (24) +#define DMA_AR_ERROR_CH_MASK(_c) (BIT(_c)) +#define DMA_LL_ERROR_CH_MASK(_c) (BIT(_c) << DMA_LL_ERROR_SHIFT) +#define DMA_UNREQ_ERROR_CH_MASK(_c)(BIT(_c)) +#define DMA_CPL_ABORT_ERROR_CH_MASK(_c)(BIT(_c) << DMA_CPL_ABORT_SHIFT) +#define DMA_CPL_TIMEOUT_ERROR_CH_MASK(_c) (BIT(_c) << DMA_CPL_TIMEOUT_SHIFT) +#define DMA_DATA_POI_ERROR_CH_MASK(_c) (BIT(_c) << DMA_DATA_POI_SHIFT) + +#define DMA_LLLAIE_SHIFT (16) +#define DMA_LLLAIE_MASK(0xF << DMA_LLLAIE_SHIFT) + +#define DMA_CHAN_WRITE_MAX_WEIGHT (0x7) +#define DMA_CHAN_READ_MAX_WEIGHT (0x3) +#define DMA_CHAN0_WEIGHT_OFFSET(0) +#define DMA_CHAN1_WEIGHT_OFFSET(5) +#define DMA_CHAN2_WEIGHT_OFFSET(10) +#define DMA_CHAN3_WEIGHT_OFFSET(15) +#define DMA_CHAN_WRITE_ALL_MAX_WEIGHT \ + ((DMA_CHAN_WRITE_MAX_WEIGHT << DMA_CHAN0_WEIGHT_OFFSET) | \ +(DMA_CHAN_WRITE_MAX_WEIGHT << DMA_CHAN1_WEIGHT_OFFSET) | \ +(DMA_CHAN_WRITE_MAX_WEIGHT << DMA_CHAN2_WEIGHT_OFFSET) | \ +(DMA_CHAN_WRITE_MAX_WEIGHT << DMA_CHAN3_WEIGHT_OFFSET)) +#define DMA_CHAN_READ_ALL_MAX_WEIGHT \ + ((DMA_CHAN_READ_MAX_WEIGHT << DMA_CHAN0_WEIGHT_OFFSET) |\ +(DMA_CHAN_READ_MAX_WEIGHT << DMA_CHAN1_WEIGHT_OFFSET) |\ +(DMA_CHAN_READ_MAX_WEIGHT << DMA_CHAN2_WEIGHT_OFFSET) |\ +(DMA_CHAN_READ_MAX_WEIGHT << DMA_CHAN3_WEIGHT_OFFSET)) + +#define PCIE_REGS_PCIE_APP_CNTRL 0x8 +#define APP_XFER_PENDING BIT(6)
[PATCH v3 14/34] misc: xlink-pcie: rh: Add core communication logic
From: Srikanth Thokala
Add logic to establish communication with the local host which is through
ring buffer management and MSI/Doorbell interrupts
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
drivers/misc/xlink-pcie/common/core.h| 11 +-
drivers/misc/xlink-pcie/remote_host/Makefile | 2 +
drivers/misc/xlink-pcie/remote_host/core.c | 621 +++
drivers/misc/xlink-pcie/remote_host/pci.c| 48 +-
4 files changed, 670 insertions(+), 12 deletions(-)
create mode 100644 drivers/misc/xlink-pcie/remote_host/core.c
diff --git a/drivers/misc/xlink-pcie/common/core.h
b/drivers/misc/xlink-pcie/common/core.h
index 656b5e2dbfae..f43c175b7a48 100644
--- a/drivers/misc/xlink-pcie/common/core.h
+++ b/drivers/misc/xlink-pcie/common/core.h
@@ -8,15 +8,11 @@
#ifndef XPCIE_CORE_HEADER_
#define XPCIE_CORE_HEADER_
-#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
+#include
+#include
#include
+#include
#include
@@ -62,6 +58,7 @@ struct xpcie_buf_desc {
struct xpcie_stream {
size_t frag;
struct xpcie_pipe pipe;
+ struct xpcie_buf_desc **ddr;
};
struct xpcie_list {
diff --git a/drivers/misc/xlink-pcie/remote_host/Makefile
b/drivers/misc/xlink-pcie/remote_host/Makefile
index 96374a43023e..e8074dbb1161 100644
--- a/drivers/misc/xlink-pcie/remote_host/Makefile
+++ b/drivers/misc/xlink-pcie/remote_host/Makefile
@@ -1,3 +1,5 @@
obj-$(CONFIG_XLINK_PCIE_RH_DRIVER) += mxlk.o
mxlk-objs := main.o
mxlk-objs += pci.o
+mxlk-objs += core.o
+mxlk-objs += ../common/util.o
diff --git a/drivers/misc/xlink-pcie/remote_host/core.c
b/drivers/misc/xlink-pcie/remote_host/core.c
new file mode 100644
index ..3be0492aa57c
--- /dev/null
+++ b/drivers/misc/xlink-pcie/remote_host/core.c
@@ -0,0 +1,621 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel Keem Bay XLink PCIe Driver
+ *
+ * Copyright (C) 2021 Intel Corporation
+ */
+
+#include "pci.h"
+
+#include "../common/core.h"
+#include "../common/util.h"
+
+static int intel_xpcie_map_dma(struct xpcie *xpcie, struct xpcie_buf_desc *bd,
+ int direction)
+{
+ struct xpcie_dev *xdev = container_of(xpcie, struct xpcie_dev, xpcie);
+ struct device *dev = >pci->dev;
+
+ bd->phys = dma_map_single(dev, bd->data, bd->length, direction);
+
+ return dma_mapping_error(dev, bd->phys);
+}
+
+static void intel_xpcie_unmap_dma(struct xpcie *xpcie,
+ struct xpcie_buf_desc *bd,
+ int direction)
+{
+ struct xpcie_dev *xdev = container_of(xpcie, struct xpcie_dev, xpcie);
+ struct device *dev = >pci->dev;
+
+ dma_unmap_single(dev, bd->phys, bd->length, direction);
+}
+
+static void intel_xpcie_txrx_cleanup(struct xpcie *xpcie)
+{
+ struct xpcie_interface *inf = >interfaces[0];
+ struct xpcie_stream *tx = >tx;
+ struct xpcie_stream *rx = >rx;
+ struct xpcie_buf_desc *bd;
+ int index;
+
+ xpcie->stop_flag = true;
+ xpcie->no_tx_buffer = false;
+ inf->data_avail = true;
+ wake_up_interruptible(>tx_waitq);
+ wake_up_interruptible(>rx_waitq);
+ mutex_lock(>wlock);
+ mutex_lock(>rlock);
+
+ if (tx->ddr) {
+ for (index = 0; index < tx->pipe.ndesc; index++) {
+ struct xpcie_transfer_desc *td = tx->pipe.tdr + index;
+
+ bd = tx->ddr[index];
+ if (bd) {
+ intel_xpcie_unmap_dma(xpcie, bd, DMA_TO_DEVICE);
+ intel_xpcie_free_tx_bd(xpcie, bd);
+ intel_xpcie_set_td_address(td, 0);
+ intel_xpcie_set_td_length(td, 0);
+ }
+ }
+ kfree(tx->ddr);
+ }
+
+ if (rx->ddr) {
+ for (index = 0; index < rx->pipe.ndesc; index++) {
+ struct xpcie_transfer_desc *td = rx->pipe.tdr + index;
+
+ bd = rx->ddr[index];
+ if (bd) {
+ intel_xpcie_unmap_dma(xpcie,
+ bd, DMA_FROM_DEVICE);
+ intel_xpcie_free_rx_bd(xpcie, bd);
+ intel_xpcie_set_td_address(td, 0);
+ intel_xpcie_set_td_length(td, 0);
+ }
+ }
+ kfree(rx->ddr);
+ }
+
+ intel_xpcie_list_cleanup(>tx_pool);
+ intel_xpcie_list_cleanup(>rx_pool);
+
+ mutex_unlock(>rlock);
+ mutex_unlock(>wlock);
+}
+
+static int intel_xpcie_txrx_init(struct xpcie *xpcie,
+struct xpcie_cap_txrx *cap)
+{
+ struct xpcie_stream *tx = >tx;
+ struct xpcie_stream *rx = >rx;
+ int tx_pool_size,
[PATCH v3 09/34] misc: xlink-pcie: lh: Add PCIe EPF driver for Local Host
From: Srikanth Thokala
Add PCIe EPF driver for local host (lh) to configure BAR's and other
HW resources. Underlying PCIe HW controller is a Synopsys DWC PCIe core.
Cc: Derek Kiernan
Cc: Dragan Cvetic
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
MAINTAINERS | 6 +
drivers/misc/Kconfig| 1 +
drivers/misc/Makefile | 1 +
drivers/misc/xlink-pcie/Kconfig | 9 +
drivers/misc/xlink-pcie/Makefile| 1 +
drivers/misc/xlink-pcie/local_host/Makefile | 2 +
drivers/misc/xlink-pcie/local_host/epf.c| 373
drivers/misc/xlink-pcie/local_host/epf.h| 37 ++
drivers/misc/xlink-pcie/local_host/xpcie.h | 38 ++
9 files changed, 468 insertions(+)
create mode 100644 drivers/misc/xlink-pcie/Kconfig
create mode 100644 drivers/misc/xlink-pcie/Makefile
create mode 100644 drivers/misc/xlink-pcie/local_host/Makefile
create mode 100644 drivers/misc/xlink-pcie/local_host/epf.c
create mode 100644 drivers/misc/xlink-pcie/local_host/epf.h
create mode 100644 drivers/misc/xlink-pcie/local_host/xpcie.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 6742a1827cd9..3ca6c8c6341b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1961,6 +1961,12 @@ F:
Documentation/devicetree/bindings/arm/intel,keembay.yaml
F: arch/arm64/boot/dts/intel/keembay-evm.dts
F: arch/arm64/boot/dts/intel/keembay-soc.dtsi
+ARM KEEM BAY XLINK PCIE SUPPORT
+M: Srikanth Thokala
+M: Mark Gross
+S: Supported
+F: drivers/misc/xlink-pcie/
+
ARM/INTEL RESEARCH IMOTE/STARGATE 2 MACHINE SUPPORT
M: Jonathan Cameron
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index fafa8b0d8099..dfb98e444c6e 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -481,4 +481,5 @@ source "drivers/misc/ocxl/Kconfig"
source "drivers/misc/cardreader/Kconfig"
source "drivers/misc/habanalabs/Kconfig"
source "drivers/misc/uacce/Kconfig"
+source "drivers/misc/xlink-pcie/Kconfig"
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d23231e73330..d17621fc43d5 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_HABANA_AI) += habanalabs/
obj-$(CONFIG_UACCE)+= uacce/
obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o
obj-$(CONFIG_HISI_HIKEY_USB) += hisi_hikey_usb.o
+obj-y += xlink-pcie/
diff --git a/drivers/misc/xlink-pcie/Kconfig b/drivers/misc/xlink-pcie/Kconfig
new file mode 100644
index ..46aa401d79b7
--- /dev/null
+++ b/drivers/misc/xlink-pcie/Kconfig
@@ -0,0 +1,9 @@
+config XLINK_PCIE_LH_DRIVER
+ tristate "XLink PCIe Local Host driver"
+ depends on PCI_ENDPOINT && ARCH_KEEMBAY
+ help
+ This option enables XLink PCIe Local Host driver.
+
+ Choose M here to compile this driver as a module, name is mxlk_ep.
+ This driver is used for XLink communication over PCIe and is to be
+ loaded on the Intel Keem Bay platform.
diff --git a/drivers/misc/xlink-pcie/Makefile b/drivers/misc/xlink-pcie/Makefile
new file mode 100644
index ..d693d382e9c6
--- /dev/null
+++ b/drivers/misc/xlink-pcie/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_XLINK_PCIE_LH_DRIVER) += local_host/
diff --git a/drivers/misc/xlink-pcie/local_host/Makefile
b/drivers/misc/xlink-pcie/local_host/Makefile
new file mode 100644
index ..514d3f0c91bc
--- /dev/null
+++ b/drivers/misc/xlink-pcie/local_host/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_XLINK_PCIE_LH_DRIVER) += mxlk_ep.o
+mxlk_ep-objs := epf.o
diff --git a/drivers/misc/xlink-pcie/local_host/epf.c
b/drivers/misc/xlink-pcie/local_host/epf.c
new file mode 100644
index ..0234756e89ae
--- /dev/null
+++ b/drivers/misc/xlink-pcie/local_host/epf.c
@@ -0,0 +1,373 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel Keem Bay XLink PCIe Driver
+ *
+ * Copyright (C) 2021 Intel Corporation
+ */
+
+#include
+#include
+
+#include "epf.h"
+
+#define BAR2_MIN_SIZE SZ_16K
+#define BAR4_MIN_SIZE SZ_16K
+
+#define PCIE_REGS_PCIE_INTR_ENABLE 0x18
+#define PCIE_REGS_PCIE_INTR_FLAGS 0x1C
+#define LBC_CII_EVENT_FLAG BIT(18)
+#define PCIE_REGS_PCIE_ERR_INTR_FLAGS 0x24
+#define LINK_REQ_RST_FLG BIT(15)
+
+static struct pci_epf_header xpcie_header = {
+ .vendorid = PCI_VENDOR_ID_INTEL,
+ .deviceid = PCI_DEVICE_ID_INTEL_KEEMBAY,
+ .baseclass_code = PCI_BASE_CLASS_MULTIMEDIA,
+ .subclass_code = 0x0,
+ .subsys_vendor_id = 0x0,
+ .subsys_id = 0x0,
+};
+
+static const struct pci_epf_device_id xpcie_epf_ids[] = {
+ {
+ .name = "mxlk_pcie_epf",
+ },
+ {},
+};
+
+static irqreturn_t intel_xpcie_err_interrupt(int irq, void *args)
+{
+
答复: [PATCH -next] ACPI: tables: Mark acpi_init_fpdt with static keyword
Hi Rui,
You can fix it in your patch together.
-邮件原件-
发件人: Zhang Rui [mailto:rui.zh...@intel.com]
发送时间: 2021年1月29日 14:25
收件人: Zouwei (Samuel) ; r...@rjwysocki.net; l...@kernel.org
抄送: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
主题: Re: [PATCH -next] ACPI: tables: Mark acpi_init_fpdt with static keyword
Hi, Wei,
Thanks for the patch.
Given that there are a couple of things need to be fixed in the orignal patch,
I'd prefer to refresh the patch with all the fixes included
https://patchwork.kernel.org/project/linux-acpi/patch/20210129061548.13448-1-rui.zh...@intel.com/
what do you think?
thanks,
rui
On Thu, 2021-01-28 at 19:31 +0800, Zou Wei wrote:
> Fix the following sparse warning:
>
> drivers/acpi/acpi_fpdt.c:230:6: warning: symbol 'acpi_init_fpdt' was
> not declared. Should it be static?
>
> Signed-off-by: Zou Wei
> ---
> drivers/acpi/acpi_fpdt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpi_fpdt.c b/drivers/acpi/acpi_fpdt.c index
> b810811..968f9cc 100644
> --- a/drivers/acpi/acpi_fpdt.c
> +++ b/drivers/acpi/acpi_fpdt.c
> @@ -227,7 +227,7 @@ static int fpdt_process_subtable(u64 address, u32
> subtable_type)
> return 0;
> }
>
> -void acpi_init_fpdt(void)
> +static void acpi_init_fpdt(void)
> {
> acpi_status status;
> struct acpi_table_header *header;
Re: [PATCH v3 1/3] perf/smmuv3: Don't reserve the PMCG register spaces
On 2021/1/29 23:06, Robin Murphy wrote:
> On 2021-01-27 11:32, Zhen Lei wrote:
>> According to the SMMUv3 specification:
>> Each PMCG counter group is represented by one 4KB page (Page 0) with one
>> optional additional 4KB page (Page 1), both of which are at IMPLEMENTATION
>> DEFINED base addresses.
>>
>> This means that the PMCG register spaces may be within the 64KB pages of
>> the SMMUv3 register space. When both the SMMU and PMCG drivers reserve
>> their own resources, a resource conflict occurs.
>>
>> To avoid this conflict, don't reserve the PMCG regions.
>
> I'm still not a fan of this get_and_ioremap notion in general, especially
> when the "helper" function ends up over twice the size of all the code it
> replaces[1], but for the actual functional change here,
OK，I'll change it to [1] and add some comments.
>
> Reviewed-by: Robin Murphy
>
>> Suggested-by: Robin Murphy
>> Signed-off-by: Zhen Lei
>> ---
>> drivers/perf/arm_smmuv3_pmu.c | 27 +--
>> 1 file changed, 25 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
>> index 74474bb322c3f26..e5e505a0804fe53 100644
>> --- a/drivers/perf/arm_smmuv3_pmu.c
>> +++ b/drivers/perf/arm_smmuv3_pmu.c
>> @@ -761,6 +761,29 @@ static void smmu_pmu_get_acpi_options(struct smmu_pmu
>> *smmu_pmu)
>> dev_notice(smmu_pmu->dev, "option mask 0x%x\n", smmu_pmu->options);
>> }
>> +static void __iomem *
>> +smmu_pmu_get_and_ioremap_resource(struct platform_device *pdev,
>> + unsigned int index,
>> + struct resource **res)
>> +{
>> + void __iomem *base;
>> + struct resource *r;
>> +
>> + r = platform_get_resource(pdev, IORESOURCE_MEM, index);
>> + if (!r) {
>> + dev_err(>dev, "invalid resource\n");
>> + return ERR_PTR(-EINVAL);
>> + }
>> + if (res)
>> + *res = r;
>> +
>> + base = devm_ioremap(>dev, r->start, resource_size(r));
>> + if (!base)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + return base;
>> +}
>> +
>> static int smmu_pmu_probe(struct platform_device *pdev)
>> {
>> struct smmu_pmu *smmu_pmu;
>> @@ -793,7 +816,7 @@ static int smmu_pmu_probe(struct platform_device *pdev)
>> .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
>> };
>> - smmu_pmu->reg_base = devm_platform_get_and_ioremap_resource(pdev, 0,
>> _0);
>> + smmu_pmu->reg_base = smmu_pmu_get_and_ioremap_resource(pdev, 0, _0);
>> if (IS_ERR(smmu_pmu->reg_base))
>> return PTR_ERR(smmu_pmu->reg_base);
>> @@ -801,7 +824,7 @@ static int smmu_pmu_probe(struct platform_device *pdev)
>> /* Determine if page 1 is present */
>> if (cfgr & SMMU_PMCG_CFGR_RELOC_CTRS) {
>> - smmu_pmu->reloc_base = devm_platform_ioremap_resource(pdev, 1);
>> + smmu_pmu->reloc_base = smmu_pmu_get_and_ioremap_resource(pdev, 1,
>> NULL);
>> if (IS_ERR(smmu_pmu->reloc_base))
>> return PTR_ERR(smmu_pmu->reloc_base);
>> } else {
>>
>
> [1]
> ->8-
> drivers/perf/arm_smmuv3_pmu.c | 35 +--
> 1 file changed, 9 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
> index e5e505a0804f..c9adbc7b55a1 100644
> --- a/drivers/perf/arm_smmuv3_pmu.c
> +++ b/drivers/perf/arm_smmuv3_pmu.c
> @@ -761,33 +761,10 @@ static void smmu_pmu_get_acpi_options(struct smmu_pmu
> *smmu_pmu)
> dev_notice(smmu_pmu->dev, "option mask 0x%x\n", smmu_pmu->options);
> }
>
> -static void __iomem *
> -smmu_pmu_get_and_ioremap_resource(struct platform_device *pdev,
> - unsigned int index,
> - struct resource **res)
> -{
> - void __iomem *base;
> - struct resource *r;
> -
> - r = platform_get_resource(pdev, IORESOURCE_MEM, index);
> - if (!r) {
> - dev_err(>dev, "invalid resource\n");
> - return ERR_PTR(-EINVAL);
> - }
> - if (res)
> - *res = r;
> -
> - base = devm_ioremap(>dev, r->start, resource_size(r));
> - if (!base)
> - return ERR_PTR(-ENOMEM);
> -
> - return base;
> -}
> -
> static int smmu_pmu_probe(struct platform_device *pdev)
> {
> struct smmu_pmu *smmu_pmu;
> - struct resource *res_0;
> + struct resource *res_0, *res_1;
> u32 cfgr, reg_size;
> u64 ceid_64[2];
> int irq, err;
> @@ -816,7 +793,10 @@ static int smmu_pmu_probe(struct platform_device *pdev)
> .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
> };
>
> - smmu_pmu->reg_base = smmu_pmu_get_and_ioremap_resource(pdev, 0, _0);
> + res_0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res_0)
> + return ERR_PTR(-EINVAL);
> + smmu_pmu->reg_base = devm_ioremap(dev, res_0->start,
> resource_size(res_0));
> if (IS_ERR(smmu_pmu->reg_base))
> return PTR_ERR(smmu_pmu->reg_base);
>
> @@ -824,7 +804,10 @@ static int smmu_pmu_probe(struct platform_device
Re: [PATCH] gpiolib: free device name on error path to fix kmemleak
Hi Andy, On 1/30/21 1:26 AM, Andy Shevchenko wrote: On Fri, Jan 29, 2021 at 2:01 PM wrote: From: Quanyang Wang In gpiochip_add_data_with_key, we should check the return value of dev_set_name to ensure that device name is allocated successfully and then add a label on the error path to free device name to fix kmemleak as below: Thanks for the report. Unfortunately... + ret = dev_set_name(>dev, GPIOCHIP_NAME "%d", gdev->id); + if (ret) + goto err_free_ida; ... +err_free_dev_name: + kfree(dev_name(>dev)); ...this approach seems to create a possible double free if I'm not mistaken. Thanks for your comment. I didn't catch the double free. Would you please point it out? The idea is that device name should be cleaned in kobject ->release() callback when device is put. Yes, the device name should be freed by calling put_device(>dev). But int gpiochip_add_data_with_key, when running dev_set_name, "gdev->dev.release" hasn't been installed until in the tail of gpiochip_add_data_with_key. So we couldn't call put_device here. Any suggestion is much appreciated. Thanks, Quanyang Can you elaborate?
[PATCH] mtd: rawnand: Do not check for bad block if bbt is unavailable
The bbt pointer will be unavailable when NAND_SKIP_BBTSCAN option is set for a NAND chip. The intention is to skip scanning for the bad blocks during boot time. However, the MTD core will call _block_isreserved() and _block_isbad() callbacks unconditionally for the rawnand devices due to the callbacks always present while collecting the ecc stats. The _block_isreserved() callback for rawnand will bail out if bbt pointer is not available. But _block_isbad() will continue without checking for it. So this contradicts with the NAND_SKIP_BBTSCAN option since the bad block check will happen anyways (ie., not much difference between scanning for bad blocks and checking each block for bad ones). Hence, do not check for the bad block if bbt pointer is unavailable. Signed-off-by: Manivannan Sadhasivam --- drivers/mtd/nand/raw/nand_base.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c index c33fa1b1847f..f18cd1db79a9 100644 --- a/drivers/mtd/nand/raw/nand_base.c +++ b/drivers/mtd/nand/raw/nand_base.c @@ -4286,6 +4286,9 @@ static int nand_block_isbad(struct mtd_info *mtd, loff_t offs) int chipnr = (int)(offs >> chip->chip_shift); int ret; + if (!chip->bbt) + return 0; + /* Select the NAND device */ ret = nand_get_device(chip); if (ret) -- 2.25.1
[PATCH v4 21/34] xlink-core: Enable xlink protocol over pcie
From: Seamus Kelly
Enable host system access to the VPU over the xlink protocol over PCIe by
enabling channel multiplexing and dispatching. This allows for remote host
communication channels across pcie links.
add dispatcher
update multiplexer to utilise dispatcher
xlink-core: Patch set 2
Add xlink-dispatcher
creates tx and rx threads
enables queueing of messages for transmission and on reception
Update multiplexer to utilise dispatcher:
handle multiplexing channels over single interface link e.g.
PCIe
process messages received by dispatcher
pass messages created by API calls to dispatcher for
transmission
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Mark Gross
Signed-off-by: Seamus Kelly
---
drivers/misc/xlink-core/Makefile| 2 +-
drivers/misc/xlink-core/xlink-core.c| 35 +-
drivers/misc/xlink-core/xlink-dispatcher.c | 441 +
drivers/misc/xlink-core/xlink-dispatcher.h | 26 +
drivers/misc/xlink-core/xlink-multiplexer.c | 498 +++-
5 files changed, 999 insertions(+), 3 deletions(-)
create mode 100644 drivers/misc/xlink-core/xlink-dispatcher.c
create mode 100644 drivers/misc/xlink-core/xlink-dispatcher.h
diff --git a/drivers/misc/xlink-core/Makefile b/drivers/misc/xlink-core/Makefile
index e82b7c72b6b9..ee81f9d05f2b 100644
--- a/drivers/misc/xlink-core/Makefile
+++ b/drivers/misc/xlink-core/Makefile
@@ -2,4 +2,4 @@
# Makefile for Keem Bay xlink Linux driver
#
obj-$(CONFIG_XLINK_CORE) += xlink.o
-xlink-objs += xlink-core.o xlink-multiplexer.o xlink-platform.o xlink-ioctl.o
+xlink-objs += xlink-core.o xlink-multiplexer.o xlink-dispatcher.o
xlink-platform.o xlink-ioctl.o
diff --git a/drivers/misc/xlink-core/xlink-core.c
b/drivers/misc/xlink-core/xlink-core.c
index dd8db834c184..bdbf8c6a99ca 100644
--- a/drivers/misc/xlink-core/xlink-core.c
+++ b/drivers/misc/xlink-core/xlink-core.c
@@ -21,6 +21,7 @@
#include "xlink-core.h"
#include "xlink-defs.h"
+#include "xlink-dispatcher.h"
#include "xlink-ioctl.h"
#include "xlink-multiplexer.h"
#include "xlink-platform.h"
@@ -151,6 +152,12 @@ static int kmb_xlink_probe(struct platform_device *pdev)
goto r_multiplexer;
}
+ // initialize dispatcher
+ rc = xlink_dispatcher_init(xlink_dev->pdev);
+ if (rc != X_LINK_SUCCESS) {
+ pr_err("Dispatcher initialization failed\n");
+ goto r_dispatcher;
+ }
// initialize xlink data structure
xlink_dev->nmb_connected_links = 0;
mutex_init(_dev->lock);
@@ -168,7 +175,7 @@ static int kmb_xlink_probe(struct platform_device *pdev)
/*Allocating Major number*/
if ((alloc_chrdev_region(, 0, 1, "xlinkdev")) < 0) {
dev_info(>dev, "Cannot allocate major number\n");
- goto r_multiplexer;
+ goto r_dispatcher;
}
dev_info(>dev, "Major = %d Minor = %d\n", MAJOR(xdev),
MINOR(xdev));
@@ -205,6 +212,8 @@ static int kmb_xlink_probe(struct platform_device *pdev)
class_destroy(dev_class);
r_class:
unregister_chrdev_region(xdev, 1);
+r_dispatcher:
+ xlink_dispatcher_destroy();
r_multiplexer:
xlink_multiplexer_destroy();
return -1;
@@ -220,6 +229,10 @@ static int kmb_xlink_remove(struct platform_device *pdev)
rc = xlink_multiplexer_destroy();
if (rc != X_LINK_SUCCESS)
pr_err("Multiplexer destroy failed\n");
+ // stop dispatchers and destroy
+ rc = xlink_dispatcher_destroy();
+ if (rc != X_LINK_SUCCESS)
+ pr_err("Dispatcher destroy failed\n");
mutex_unlock(>lock);
mutex_destroy(>lock);
@@ -314,6 +327,14 @@ enum xlink_error xlink_connect(struct xlink_handle *handle)
link->handle = *handle;
xlink->nmb_connected_links++;
kref_init(>refcount);
+ if (interface != IPC_INTERFACE) {
+ // start dispatcher
+ rc = xlink_dispatcher_start(link->id, >handle);
+ if (rc) {
+ pr_err("dispatcher start failed\n");
+ goto r_cleanup;
+ }
+ }
// initialize multiplexer connection
rc = xlink_multiplexer_connect(link->id);
if (rc) {
@@ -649,6 +670,7 @@ EXPORT_SYMBOL_GPL(xlink_release_data);
enum xlink_error xlink_disconnect(struct xlink_handle *handle)
{
struct xlink_link *link;
+ int interface = NULL_INTERFACE;
enum xlink_error rc = X_LINK_ERROR;
if (!xlink || !handle)
@@ -661,6 +683,17 @@ enum xlink_error xlink_disconnect(struct xlink_handle
*handle)
// decrement refcount, if count is 0 lock mutex and disconnect
if
Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform
On Fri 29 Jan 16:19 CST 2021, Dmitry Baryshkov wrote: > On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas wrote: > > > > On Fri, Jan 29, 2021 at 06:45:21AM +0300, Dmitry Baryshkov wrote: > > > On 28/01/2021 22:26, Rob Herring wrote: > > > > On Thu, Jan 28, 2021 at 11:52 AM Dmitry Baryshkov > > > > wrote: > > > > > > > > > > Some Qualcomm platforms require to power up an external device before > > > > > probing the PCI bus. E.g. on RB5 platform the QCA6390 WiFi/BT chip > > > > > needs > > > > > to be powered up before PCIe0 bus is probed. Add a quirk to the > > > > > respective PCIe root bridge to attach to the power domain if one is > > > > > required, so that the QCA chip is started before scanning the PCIe > > > > > bus. > > > > > > > > This is solving a generic problem in a specific driver. It needs to be > > > > solved for any PCI host and any device. > > > > > > Ack. I see your point here. > > > > > > As this would require porting code from powerpc/spark of-pci code and > > > changing pcie port driver to apply power supply before bus probing > > > happens, > > > I'd also ask for the comments from PCI maintainers. Will that solution be > > > acceptable to you? > > > > I can't say without seeing the code. I don't know enough about this > > scenario to envision how it might look. > > > > I guess the QCA6390 is a PCIe device? Why does it need to be powered > > up before probing? Shouldn't we get a link-up interrupt when it is > > powered up so we could probe it then? > > Not quite. QCA6390 is a multifunction device, with PCIe and serial > parts. It has internal power regulators which once enabled will > powerup the PCIe, serial and radio parts. There is no need to manage > regulators. Once enabled they will automatically handle device > suspend/resume, etc. > So what you're saying is that if either the PCI controller or bluetooth driver probes these regulators will be turned on, indefinitely? If so, why do we need a driver to turn them on, rather than just mark them as always-on? What's the timing requirement wrt regulators vs WL_EN/BT_EN? Regards, Bjorn A > I'm not sure about link-up interrupt. I've just lightly tested using > PCIe HP on this port, getting no interrupts from it. > If I manually rescan the bus after enabling the qca6390 device (e.g. > via sysfs), it gets enabled, but then I see PCIe link errors (most > probably because the PCIe link was not retrained after the device > comes up). > > > Nit: when changing any file, please take a look at the commit history > > and make yours match, e.g., > > > > pcie-qcom: provide a way to power up qca6390 chip on RB5 platform > > > > does not look like: > > Ack. > > > -- > With best wishes > Dmitry
[PATCH v3 33/34] misc: Hddl device management for local host
From: "C, Udhayakumar"
Add local host hddl device management for Intel Edge.AI Computer Vision
platforms.
About Intel Edge.AI Computer Vision platforms:
-
The Intel Edge.AI Computer Vision platforms are vision processing systems
targeting machine vision applications for connected devices.
They are based on ARM A53 CPU running Linux and acts as a PCIe
endpoint device.
High-level architecture:
Remote Host IA CPU Local Host ARM CPU
---
| * Send time as xlink packet | |* Sync time with IA host |
| * receive sensor details| |* Prepare and share sensor|
| and register as i2c or| | details to IA host as |
| xlink smbus slaves| | xlink packets |
---
| hddl server | <=> | hddl client |
--- xlink
hddl device module:
---
The HDDL client driver acts as an software RTC to sync with network
time. It abstracts xlink protocol to communicate with remote host.
This driver exports the details about sensors available in the
platform to remote host as xlink packets.
This driver also handles device connect/disconnect events and
identifies board id and soc id using gpio's, based on platform
configuration.
- Local Host driver
* Intended for ARM CPU
* It is based on xlink Framework
* Driver path:
{tree}/drivers/misc/hddl_device/hddl_device_client.c
Local arm host and Remote IA host drivers communicates using
XLINK protocol.
Signed-off-by: C, Udhayakumar
---
.../misc-devices/hddl_device_client.rst | 212 +
Documentation/misc-devices/index.rst | 1 +
Documentation/vpu/index.rst | 1 +
MAINTAINERS | 1 +
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile | 1 +
drivers/misc/hddl_device/Kconfig | 14 +
drivers/misc/hddl_device/Makefile | 5 +
drivers/misc/hddl_device/hddl_device.c| 565 +
drivers/misc/hddl_device/hddl_device_lh.c | 764 ++
drivers/misc/hddl_device/hddl_device_util.h | 52 ++
11 files changed, 1617 insertions(+)
create mode 100644 Documentation/misc-devices/hddl_device_client.rst
create mode 100644 drivers/misc/hddl_device/Kconfig
create mode 100644 drivers/misc/hddl_device/Makefile
create mode 100644 drivers/misc/hddl_device/hddl_device.c
create mode 100644 drivers/misc/hddl_device/hddl_device_lh.c
create mode 100644 drivers/misc/hddl_device/hddl_device_util.h
diff --git a/Documentation/misc-devices/hddl_device_client.rst
b/Documentation/misc-devices/hddl_device_client.rst
new file mode 100644
index ..413643b6b500
--- /dev/null
+++ b/Documentation/misc-devices/hddl_device_client.rst
@@ -0,0 +1,212 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+Kernel driver: hddl_device_client
+=
+
+Supported chips:
+ * Intel Edge.AI Computer Vision platforms: Keem Bay
+
+Authors:
+- Thalaiappan, Rathina
+- Udhayakumar C
+
+
+Overview
+
+
+This driver supports hddl device management for Intel Edge.AI Computer Vision
+platforms.
+
+This driver supports the following features:
+
+ - Exports deatils of temperature sensor, current sensor and fan controller
+present in Intel Edge.AI Computer Vision platforms to IA host.
+ - Enable Time sync of Intel Edge.AI Computer Vision platform with IA host.
+ - Handles device connect and disconnect events.
+ - Receives slave address from the IA host for memory mapped thermal sensors
+present in SoC (Documentation/hwmon/intel_tsens_sensors.rst).
+ - Registers i2c slave device for slaves present in Intel Edge.AI Computer
+Vision platform
+
+Keem Bay platform has
+Onchip sensors:
+
+ - Media Subsystem (mss) temperature sensor
+ - NN subsystem (nce) temperature sensor
+ - Compute subsystem (cse) temperature sensor
+ - SOC(Maximum of mss, nce and cse).
+
+Onboard sensors:
+
+ - two lm75 temperature sensors
+ - emc2103 fan controller
+ - ina3221 current sensor
+
+High-level architecture
+===
+::
+
+Remote Host IA CPU Local Host ARM CPU
+---
+| * Send time as xlink packet | |* Sync time with IA host |
+| * receive sensor details| |* Prepare and share sensor|
+| and register as i2c or| | details to IA host as |
+| xlink smbus slaves| | xlink packets |
+---
+| hddl server
[PATCH v3 24/34] dt-bindings: misc: Add Keem Bay vpumgr
From: "Li, Tingqian"
Add DT binding schema for VPU on Keem Bay ASoC platform
Signed-off-by: Li, Tingqian
---
.../bindings/misc/intel,keembay-vpu-mgr.yaml | 48 +++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/misc/intel,keembay-vpu-mgr.yaml
diff --git a/Documentation/devicetree/bindings/misc/intel,keembay-vpu-mgr.yaml
b/Documentation/devicetree/bindings/misc/intel,keembay-vpu-mgr.yaml
new file mode 100644
index ..7fad14274ee2
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/intel,keembay-vpu-mgr.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright (C) 2020 Intel
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/intel,keembay-vpu-mgr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel VPU manager bindings
+
+maintainers:
+ - Li, Tingqian
+ - Zhou, Luwei
+
+description: |
+ The Intel VPU manager provides shared memory and process
+ depedent context management for Intel VPU hardware IP.
+
+properties:
+ compatible:
+items:
+ - enum:
+- intel,keembay-vpu-mgr
+- intel,keembay-vpusmm
+
+ memory-region:
+description:
+ phandle to a node describing reserved memory (System RAM memory)
+ used by VPU (see bindings/reserved-memory/reserved-memory.txt)
+maxItems: 1
+
+ intel,keembay-vpu-ipc-id:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+ the index of the VPU slice to be managed. Default is 0.
+
+required:
+ - compatible
+ - memory-region
+
+additionalProperties: false
+
+examples:
+ - |
+vpumgr0 {
+compatible = "intel,keembay-vpu-mgr";
+memory-region = <_reserved>;
+intel,keembay-vpu-ipc-id = <0x0>;
+};
--
2.17.1
[PATCH v4 14/34] misc: xlink-pcie: rh: Add core communication logic
From: Srikanth Thokala
Add logic to establish communication with the local host which is through
ring buffer management and MSI/Doorbell interrupts
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
drivers/misc/xlink-pcie/common/core.h| 11 +-
drivers/misc/xlink-pcie/remote_host/Makefile | 2 +
drivers/misc/xlink-pcie/remote_host/core.c | 621 +++
drivers/misc/xlink-pcie/remote_host/pci.c| 48 +-
4 files changed, 670 insertions(+), 12 deletions(-)
create mode 100644 drivers/misc/xlink-pcie/remote_host/core.c
diff --git a/drivers/misc/xlink-pcie/common/core.h
b/drivers/misc/xlink-pcie/common/core.h
index 656b5e2dbfae..f43c175b7a48 100644
--- a/drivers/misc/xlink-pcie/common/core.h
+++ b/drivers/misc/xlink-pcie/common/core.h
@@ -8,15 +8,11 @@
#ifndef XPCIE_CORE_HEADER_
#define XPCIE_CORE_HEADER_
-#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
+#include
+#include
#include
+#include
#include
@@ -62,6 +58,7 @@ struct xpcie_buf_desc {
struct xpcie_stream {
size_t frag;
struct xpcie_pipe pipe;
+ struct xpcie_buf_desc **ddr;
};
struct xpcie_list {
diff --git a/drivers/misc/xlink-pcie/remote_host/Makefile
b/drivers/misc/xlink-pcie/remote_host/Makefile
index 96374a43023e..e8074dbb1161 100644
--- a/drivers/misc/xlink-pcie/remote_host/Makefile
+++ b/drivers/misc/xlink-pcie/remote_host/Makefile
@@ -1,3 +1,5 @@
obj-$(CONFIG_XLINK_PCIE_RH_DRIVER) += mxlk.o
mxlk-objs := main.o
mxlk-objs += pci.o
+mxlk-objs += core.o
+mxlk-objs += ../common/util.o
diff --git a/drivers/misc/xlink-pcie/remote_host/core.c
b/drivers/misc/xlink-pcie/remote_host/core.c
new file mode 100644
index ..3be0492aa57c
--- /dev/null
+++ b/drivers/misc/xlink-pcie/remote_host/core.c
@@ -0,0 +1,621 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel Keem Bay XLink PCIe Driver
+ *
+ * Copyright (C) 2021 Intel Corporation
+ */
+
+#include "pci.h"
+
+#include "../common/core.h"
+#include "../common/util.h"
+
+static int intel_xpcie_map_dma(struct xpcie *xpcie, struct xpcie_buf_desc *bd,
+ int direction)
+{
+ struct xpcie_dev *xdev = container_of(xpcie, struct xpcie_dev, xpcie);
+ struct device *dev = >pci->dev;
+
+ bd->phys = dma_map_single(dev, bd->data, bd->length, direction);
+
+ return dma_mapping_error(dev, bd->phys);
+}
+
+static void intel_xpcie_unmap_dma(struct xpcie *xpcie,
+ struct xpcie_buf_desc *bd,
+ int direction)
+{
+ struct xpcie_dev *xdev = container_of(xpcie, struct xpcie_dev, xpcie);
+ struct device *dev = >pci->dev;
+
+ dma_unmap_single(dev, bd->phys, bd->length, direction);
+}
+
+static void intel_xpcie_txrx_cleanup(struct xpcie *xpcie)
+{
+ struct xpcie_interface *inf = >interfaces[0];
+ struct xpcie_stream *tx = >tx;
+ struct xpcie_stream *rx = >rx;
+ struct xpcie_buf_desc *bd;
+ int index;
+
+ xpcie->stop_flag = true;
+ xpcie->no_tx_buffer = false;
+ inf->data_avail = true;
+ wake_up_interruptible(>tx_waitq);
+ wake_up_interruptible(>rx_waitq);
+ mutex_lock(>wlock);
+ mutex_lock(>rlock);
+
+ if (tx->ddr) {
+ for (index = 0; index < tx->pipe.ndesc; index++) {
+ struct xpcie_transfer_desc *td = tx->pipe.tdr + index;
+
+ bd = tx->ddr[index];
+ if (bd) {
+ intel_xpcie_unmap_dma(xpcie, bd, DMA_TO_DEVICE);
+ intel_xpcie_free_tx_bd(xpcie, bd);
+ intel_xpcie_set_td_address(td, 0);
+ intel_xpcie_set_td_length(td, 0);
+ }
+ }
+ kfree(tx->ddr);
+ }
+
+ if (rx->ddr) {
+ for (index = 0; index < rx->pipe.ndesc; index++) {
+ struct xpcie_transfer_desc *td = rx->pipe.tdr + index;
+
+ bd = rx->ddr[index];
+ if (bd) {
+ intel_xpcie_unmap_dma(xpcie,
+ bd, DMA_FROM_DEVICE);
+ intel_xpcie_free_rx_bd(xpcie, bd);
+ intel_xpcie_set_td_address(td, 0);
+ intel_xpcie_set_td_length(td, 0);
+ }
+ }
+ kfree(rx->ddr);
+ }
+
+ intel_xpcie_list_cleanup(>tx_pool);
+ intel_xpcie_list_cleanup(>rx_pool);
+
+ mutex_unlock(>rlock);
+ mutex_unlock(>wlock);
+}
+
+static int intel_xpcie_txrx_init(struct xpcie *xpcie,
+struct xpcie_cap_txrx *cap)
+{
+ struct xpcie_stream *tx = >tx;
+ struct xpcie_stream *rx = >rx;
+
[PATCH v4 07/34] keembay-vpu-ipc: Add Keem Bay VPU IPC module
From: Paul Murphy Intel Keem Bay SoC contains a Vision Processing Unit (VPU) to enable machine vision and other applications. Enable Linux to control the VPU processor and provides an interface to the Keem Bay IPC for communicating with the VPU firmware. Specifically the driver provides the following functionality to other kernel components: - Starting (including loading the VPU firmware) / Stopping / Rebooting the VPU. - Getting notifications of VPU events (e.g., WDT events). - Communicating with the VPU via the Keem Bay IPC mechanism. In addition to the above, the driver also exposes SoC information (like stepping, device ID, etc.) to user-space via sysfs. Specifically, the following sysfs files are provided: - /sys/firmware/keembay-vpu-ipc/device_id - /sys/firmware/keembay-vpu-ipc/feature_exclusion - /sys/firmware/keembay-vpu-ipc/hardware_id - /sys/firmware/keembay-vpu-ipc/sku - /sys/firmware/keembay-vpu-ipc/stepping Co-developed-by: Daniele Alessandrelli Signed-off-by: Daniele Alessandrelli Signed-off-by: Mark Gross Signed-off-by: Paul Murphy --- MAINTAINERS |9 + drivers/soc/intel/Kconfig | 15 + drivers/soc/intel/Makefile|3 +- drivers/soc/intel/keembay-vpu-ipc.c | 2026 + include/linux/soc/intel/keembay-vpu-ipc.h | 62 + 5 files changed, 2114 insertions(+), 1 deletion(-) create mode 100644 drivers/soc/intel/keembay-vpu-ipc.c create mode 100644 include/linux/soc/intel/keembay-vpu-ipc.h diff --git a/MAINTAINERS b/MAINTAINERS index 684e64e958a4..6742a1827cd9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9068,6 +9068,15 @@ F: Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml F: drivers/soc/intel/keembay-ipc.c F: include/linux/soc/intel/keembay-ipc.h +INTEL KEEM BAY VPU IPC DRIVER +M: Paul J Murphy +M: Daniele Alessandrelli +M: Mark Gross +S: Supported +F: Documentation/devicetree/bindings/soc/intel/intel,keembay-vpu-ipc.yaml +F: drivers/soc/intel/keembay-vpu-ipc.c +F: include/linux/soc/intel/keembay-vpu-ipc.h + INTEL MANAGEMENT ENGINE (mei) M: Tomas Winkler L: linux-kernel@vger.kernel.org diff --git a/drivers/soc/intel/Kconfig b/drivers/soc/intel/Kconfig index a575e31e47b4..ebd23ea57d04 100644 --- a/drivers/soc/intel/Kconfig +++ b/drivers/soc/intel/Kconfig @@ -15,4 +15,19 @@ config KEEMBAY_IPC Select this if you are compiling the Kernel for an Intel SoC that includes the Intel Vision Processing Unit (VPU) such as Keem Bay. + +config KEEMBAY_VPU_IPC + tristate "Intel Keem Bay VPU IPC Driver" + depends on KEEMBAY_IPC + depends on HAVE_ARM_SMCCC + help + This option enables support for loading and communicating with + the firmware on the Vision Processing Unit (VPU) of the Keem Bay + SoC. The driver depends on the Keem Bay IPC driver to do + communication, and it depends on secure world monitor software to + do the control of the VPU state. + + Select this if you are compiling the Kernel for an Intel SoC that + includes the Intel Vision Processing Unit (VPU) such as Keem Bay. + endmenu diff --git a/drivers/soc/intel/Makefile b/drivers/soc/intel/Makefile index ecf0246e7822..363a81848843 100644 --- a/drivers/soc/intel/Makefile +++ b/drivers/soc/intel/Makefile @@ -1,4 +1,5 @@ # # Makefile for Keem Bay IPC Linux driver # -obj-$(CONFIG_KEEMBAY_IPC) += keembay-ipc.o +obj-$(CONFIG_KEEMBAY_IPC) += keembay-ipc.o +obj-$(CONFIG_KEEMBAY_VPU_IPC) += keembay-vpu-ipc.o diff --git a/drivers/soc/intel/keembay-vpu-ipc.c b/drivers/soc/intel/keembay-vpu-ipc.c new file mode 100644 index ..8f3d6a466629 --- /dev/null +++ b/drivers/soc/intel/keembay-vpu-ipc.c @@ -0,0 +1,2026 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Keem Bay VPU IPC Driver. + * + * Copyright (c) 2018-2020 Intel Corporation. + * + * The purpose of this driver is to facilitate booting, control and + * communication with the VPU IP on the Keem Bay SoC. + * + * Specifically the driver provides the following functionality to other kernel + * components: + * - Loading the VPU firmware into DDR for the VPU to execute. + * - Starting / Stopping / Rebooting the VPU. + * - Getting notifications of VPU events (e.g., WDT events). + * - Communicating with the VPU using the Keem Bay IPC mechanism. + * + * In addition to the above, the driver also exposes SoC information (like + * stepping, device ID, etc.) to user-space via sysfs. + * + * + * VPU Firmware loading + * + * + * The VPU Firmware consists of both the RTOS and the application code meant to + * be run by the VPU. + * + * The VPU Firmware is loaded into DDR using the Linux Firmware API. The + * firmware is loaded into a specific reserved memory region in DDR and + * executed by the VPU directly from there. + * + * The VPU Firmware binary is expected to have the
[PATCH v3 12/34] misc: xlink-pcie: lh: Prepare changes for adding remote host driver
From: Srikanth Thokala
Move logic that can be reused between local host and remote host to
common/ folder
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
drivers/misc/xlink-pcie/{local_host => common}/core.h | 8 +++-
drivers/misc/xlink-pcie/{local_host => common}/util.c | 8 +++-
drivers/misc/xlink-pcie/{local_host => common}/util.h | 8 +++-
drivers/misc/xlink-pcie/{local_host => common}/xpcie.h | 8 +++-
drivers/misc/xlink-pcie/local_host/Makefile| 2 +-
drivers/misc/xlink-pcie/local_host/core.c | 4 ++--
drivers/misc/xlink-pcie/local_host/epf.h | 4 ++--
7 files changed, 17 insertions(+), 25 deletions(-)
rename drivers/misc/xlink-pcie/{local_host => common}/core.h (96%)
rename drivers/misc/xlink-pcie/{local_host => common}/util.c (97%)
rename drivers/misc/xlink-pcie/{local_host => common}/util.h (91%)
rename drivers/misc/xlink-pcie/{local_host => common}/xpcie.h (92%)
diff --git a/drivers/misc/xlink-pcie/local_host/core.h
b/drivers/misc/xlink-pcie/common/core.h
similarity index 96%
rename from drivers/misc/xlink-pcie/local_host/core.h
rename to drivers/misc/xlink-pcie/common/core.h
index 84985ef41a64..656b5e2dbfae 100644
--- a/drivers/misc/xlink-pcie/local_host/core.h
+++ b/drivers/misc/xlink-pcie/common/core.h
@@ -1,11 +1,9 @@
/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- *
+/*
* Intel Keem Bay XLink PCIe Driver
*
- * Copyright (C) 2020 Intel Corporation
- *
- /
+ * Copyright (C) 2021 Intel Corporation
+ */
#ifndef XPCIE_CORE_HEADER_
#define XPCIE_CORE_HEADER_
diff --git a/drivers/misc/xlink-pcie/local_host/util.c
b/drivers/misc/xlink-pcie/common/util.c
similarity index 97%
rename from drivers/misc/xlink-pcie/local_host/util.c
rename to drivers/misc/xlink-pcie/common/util.c
index ec808b0cd72b..d99125f61ba0 100644
--- a/drivers/misc/xlink-pcie/local_host/util.c
+++ b/drivers/misc/xlink-pcie/common/util.c
@@ -1,11 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-only
-/*
- *
+/*
* Intel Keem Bay XLink PCIe Driver
*
- * Copyright (C) 2020 Intel Corporation
- *
- /
+ * Copyright (C) 2021 Intel Corporation
+ */
#include "util.h"
diff --git a/drivers/misc/xlink-pcie/local_host/util.h
b/drivers/misc/xlink-pcie/common/util.h
similarity index 91%
rename from drivers/misc/xlink-pcie/local_host/util.h
rename to drivers/misc/xlink-pcie/common/util.h
index 908be897a61d..5295783b0437 100644
--- a/drivers/misc/xlink-pcie/local_host/util.h
+++ b/drivers/misc/xlink-pcie/common/util.h
@@ -1,11 +1,9 @@
/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- *
+/*
* Intel Keem Bay XLink PCIe Driver
*
- * Copyright (C) 2020 Intel Corporation
- *
- /
+ * Copyright (C) 2021 Intel Corporation
+ */
#ifndef XPCIE_UTIL_HEADER_
#define XPCIE_UTIL_HEADER_
diff --git a/drivers/misc/xlink-pcie/local_host/xpcie.h
b/drivers/misc/xlink-pcie/common/xpcie.h
similarity index 92%
rename from drivers/misc/xlink-pcie/local_host/xpcie.h
rename to drivers/misc/xlink-pcie/common/xpcie.h
index 8a559617daba..48529eb49be0 100644
--- a/drivers/misc/xlink-pcie/local_host/xpcie.h
+++ b/drivers/misc/xlink-pcie/common/xpcie.h
@@ -1,11 +1,9 @@
/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- *
+/*
* Intel Keem Bay XLink PCIe Driver
*
- * Copyright (C) 2020 Intel Corporation
- *
- /
+ * Copyright (C) 2021 Intel Corporation
+ */
#ifndef XPCIE_HEADER_
#define XPCIE_HEADER_
diff --git a/drivers/misc/xlink-pcie/local_host/Makefile
b/drivers/misc/xlink-pcie/local_host/Makefile
index 28761751d43b..65df94c7e860 100644
--- a/drivers/misc/xlink-pcie/local_host/Makefile
+++ b/drivers/misc/xlink-pcie/local_host/Makefile
@@ -2,4 +2,4 @@ obj-$(CONFIG_XLINK_PCIE_LH_DRIVER) += mxlk_ep.o
mxlk_ep-objs := epf.o
mxlk_ep-objs += dma.o
mxlk_ep-objs += core.o
-mxlk_ep-objs += util.o
+mxlk_ep-objs += ../common/util.o
diff --git a/drivers/misc/xlink-pcie/local_host/core.c
b/drivers/misc/xlink-pcie/local_host/core.c
index c67ce2c3067d..2c4e29bce7f7 100644
--- a/drivers/misc/xlink-pcie/local_host/core.c
+++ b/drivers/misc/xlink-pcie/local_host/core.c
@@ -8,8 +8,8 @@
#include
#include "epf.h"
-#include "core.h"
-#include "util.h"
+#include "../common/core.h"
+#include "../common/util.h"
static struct xpcie *global_xpcie;
diff --git a/drivers/misc/xlink-pcie/local_host/epf.h
[PATCH v4 13/34] misc: xlink-pcie: rh: Add PCIe EP driver for Remote Host
From: Srikanth Thokala
Add PCIe Endpoint driver that configures PCIe BARs and MSIs on the
Remote Host
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
MAINTAINERS | 2 +-
drivers/misc/xlink-pcie/Kconfig | 11 +
drivers/misc/xlink-pcie/Makefile | 1 +
drivers/misc/xlink-pcie/common/xpcie.h | 1 +
drivers/misc/xlink-pcie/remote_host/Makefile | 3 +
drivers/misc/xlink-pcie/remote_host/main.c | 90
drivers/misc/xlink-pcie/remote_host/pci.c| 449 +++
drivers/misc/xlink-pcie/remote_host/pci.h| 62 +++
8 files changed, 618 insertions(+), 1 deletion(-)
create mode 100644 drivers/misc/xlink-pcie/remote_host/Makefile
create mode 100644 drivers/misc/xlink-pcie/remote_host/main.c
create mode 100644 drivers/misc/xlink-pcie/remote_host/pci.c
create mode 100644 drivers/misc/xlink-pcie/remote_host/pci.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 3ca6c8c6341b..e05fa34d72ce 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1961,7 +1961,7 @@ F:
Documentation/devicetree/bindings/arm/intel,keembay.yaml
F: arch/arm64/boot/dts/intel/keembay-evm.dts
F: arch/arm64/boot/dts/intel/keembay-soc.dtsi
-ARM KEEM BAY XLINK PCIE SUPPORT
+ARM/INTEL KEEM BAY XLINK PCIE SUPPORT
M: Srikanth Thokala
M: Mark Gross
S: Supported
diff --git a/drivers/misc/xlink-pcie/Kconfig b/drivers/misc/xlink-pcie/Kconfig
index 46aa401d79b7..448b9bfbdfa2 100644
--- a/drivers/misc/xlink-pcie/Kconfig
+++ b/drivers/misc/xlink-pcie/Kconfig
@@ -1,3 +1,14 @@
+config XLINK_PCIE_RH_DRIVER
+ tristate "XLink PCIe Remote Host driver"
+ depends on PCI && X86_64
+ help
+ This option enables XLink PCIe Remote Host driver.
+
+ Choose M here to compile this driver as a module, name is mxlk.
+ This driver is used for XLink communication over PCIe,
+ and is to be loaded on the IA host which is connected to
+ the Intel Keem Bay.
+
config XLINK_PCIE_LH_DRIVER
tristate "XLink PCIe Local Host driver"
depends on PCI_ENDPOINT && ARCH_KEEMBAY
diff --git a/drivers/misc/xlink-pcie/Makefile b/drivers/misc/xlink-pcie/Makefile
index d693d382e9c6..1dd984d8d88c 100644
--- a/drivers/misc/xlink-pcie/Makefile
+++ b/drivers/misc/xlink-pcie/Makefile
@@ -1 +1,2 @@
+obj-$(CONFIG_XLINK_PCIE_RH_DRIVER) += remote_host/
obj-$(CONFIG_XLINK_PCIE_LH_DRIVER) += local_host/
diff --git a/drivers/misc/xlink-pcie/common/xpcie.h
b/drivers/misc/xlink-pcie/common/xpcie.h
index 48529eb49be0..b5cf9242a59a 100644
--- a/drivers/misc/xlink-pcie/common/xpcie.h
+++ b/drivers/misc/xlink-pcie/common/xpcie.h
@@ -69,6 +69,7 @@ struct xpcie_mmio {
struct xpcie {
u32 status;
bool legacy_a0;
+ void *bar0;
void *mmio;
void *bar4;
diff --git a/drivers/misc/xlink-pcie/remote_host/Makefile
b/drivers/misc/xlink-pcie/remote_host/Makefile
new file mode 100644
index ..96374a43023e
--- /dev/null
+++ b/drivers/misc/xlink-pcie/remote_host/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_XLINK_PCIE_RH_DRIVER) += mxlk.o
+mxlk-objs := main.o
+mxlk-objs += pci.o
diff --git a/drivers/misc/xlink-pcie/remote_host/main.c
b/drivers/misc/xlink-pcie/remote_host/main.c
new file mode 100644
index ..ed1a431ed5d4
--- /dev/null
+++ b/drivers/misc/xlink-pcie/remote_host/main.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel Keem Bay XLink PCIe Driver
+ *
+ * Copyright (C) 2021 Intel Corporation
+ */
+
+#include "pci.h"
+#include "../common/core.h"
+
+#define HW_ID_LO_MASK GENMASK(7, 0)
+#define HW_ID_HI_MASK GENMASK(15, 8)
+
+static const struct pci_device_id xpcie_pci_table[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_KEEMBAY), 0 },
+ { 0 }
+};
+
+static int intel_xpcie_probe(struct pci_dev *pdev,
+const struct pci_device_id *ent)
+{
+ bool new_device = false;
+ struct xpcie_dev *xdev;
+ u32 sw_devid;
+ u16 hw_id;
+ int ret;
+
+ hw_id = FIELD_PREP(HW_ID_HI_MASK, pdev->bus->number) |
+ FIELD_PREP(HW_ID_LO_MASK, PCI_SLOT(pdev->devfn));
+
+ sw_devid = FIELD_PREP(XLINK_DEV_INF_TYPE_MASK,
+ XLINK_DEV_INF_PCIE) |
+ FIELD_PREP(XLINK_DEV_PHYS_ID_MASK, hw_id) |
+ FIELD_PREP(XLINK_DEV_TYPE_MASK, XLINK_DEV_TYPE_KMB) |
+ FIELD_PREP(XLINK_DEV_PCIE_ID_MASK, XLINK_DEV_PCIE_0) |
+ FIELD_PREP(XLINK_DEV_FUNC_MASK, XLINK_DEV_FUNC_VPU);
+
+ xdev = intel_xpcie_get_device_by_id(sw_devid);
+ if (!xdev) {
+ xdev = intel_xpcie_create_device(sw_devid, pdev);
+ if (!xdev)
+ return -ENOMEM;
+
+ new_device = true;
+ }
+
+ ret = intel_xpcie_pci_init(xdev, pdev);
+ if (ret) {
+
[PATCH v4 27/34] misc: Tsens ARM host thermal driver.
From: "C, Udhayakumar"
Add tsens ARM host thermal driver for Intel Edge.AI Computer Vision
platforms.
About Intel Edge.AI Computer Vision platforms:
-
The Intel Edge.AI Computer Vision platforms are vision processing systems
targeting machine vision applications for connected devices.
They are based on ARM A53 CPU running Linux and acts as a PCIe
endpoint device.
High-level architecture:
Remote Host IA CPULocal Host ARM CPU
--
| Platform| | Thermal Daemon|
| Management SW| ||
--
| Intel tsens | | intel tsens i2c slave |
| i2c client | | and thermal driver|
--
| XLINK I2C | | XLINK I2C Slave |
| controller | <=> | controller |
smbus--
intel tsens module:
---
The tsens module enables reading of on chip sensors present
in the Intel Edge.AI Computer Vision platforms. In the tsens module
various junction and SoC temperatures are reported using thermal
subsystem and i2c subsystem.
Temperature data reported using thermal subsystem will be used for
various cooling agents such as DVFS, fan control and shutdown the
system in case of critical temperature.
Temperature data reported using i2c subsystem will be used by
platform manageability software running in IA host.
- Local Host driver
* Intended for ARM CPU
* It is based on Thermal and I2C slave Framework
* Driver path:
{tree}/drivers/misc/intel_tsens/intel_tsens_thermal.c
Local host and Remote host drivers communicates using
XLINK I2C SMBUS protocol.
Acked-by: Mark Gross
Signed-off-by: C Udhayakumar
Signed-off-by: Mark Gross
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/intel_tsens_sensor.rst| 67 ++
MAINTAINERS | 5 +
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile | 1 +
drivers/misc/intel_tsens/Kconfig | 15 +
drivers/misc/intel_tsens/Makefile | 7 +
.../misc/intel_tsens/intel_tsens_thermal.c| 651 ++
.../misc/intel_tsens/intel_tsens_thermal.h| 38 +
include/linux/hddl_device.h | 153
10 files changed, 939 insertions(+)
create mode 100644 Documentation/hwmon/intel_tsens_sensor.rst
create mode 100644 drivers/misc/intel_tsens/Kconfig
create mode 100644 drivers/misc/intel_tsens/Makefile
create mode 100644 drivers/misc/intel_tsens/intel_tsens_thermal.c
create mode 100644 drivers/misc/intel_tsens/intel_tsens_thermal.h
create mode 100644 include/linux/hddl_device.h
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index fcb870ce6286..fc29100bef73 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -80,6 +80,7 @@ Hardware Monitoring Kernel Drivers
ir38064
isl68137
it87
+ intel_tsens_sensor.rst
jc42
k10temp
k8temp
diff --git a/Documentation/hwmon/intel_tsens_sensor.rst
b/Documentation/hwmon/intel_tsens_sensor.rst
new file mode 100644
index ..0f53dfca477e
--- /dev/null
+++ b/Documentation/hwmon/intel_tsens_sensor.rst
@@ -0,0 +1,67 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+Kernel driver: intel_tsens_thermal
+==
+
+Supported chips:
+ * Intel Edge.AI Computer Vision platforms: Keem Bay
+
+Slave address: The address is assigned by the hddl device management
+ driver.
+
+Authors:
+- Thalaiappan, Rathina
+- Udhayakumar C
+
+Description
+===
+The Intel Edge.AI Computer Vision platforms have memory mapped thermal sensors
+which are accessible locally. The intel_tsens_thermal driver handles these
+thermal sensor and exposes the temperature to
+
+* the external host similar to the standard SMBUS based thermal sensor
+(like LM73) to the host by registering to the I2C subsystem as
+slave interface (Documentation/i2c/slave-interface.rst).
+* the local CPU as a standard thermal device.
+
+In Keem Bay, the four thermal junction temperature points are,
+Media Subsystem (mss), NN subsystem (nce), Compute subsystem (cse) and
+SOC(Maximum of mss, nce and cse).
+
+Similarity: /drivers/thermal/qcom
+
+Example
+===
+Local Thermal Interface:
+
+Temperature reported in Keem Bay on the Linux Thermal sysfs interface.
+
+# cat /sys/class/thermal/thermal_zone*/type
+mss
+css
+nce
+soc
+
+# cat /sys/class/thermal/thermal_zone*/temp
+0
+29210
+28478
+29210
+
+Remote Thermal Interface:
+
+tsens i2c slave driver reports temperature of
[PATCH v4 30/34] misc:intel_tsens: Intel Keem Bay tsens driver.
From: "C, Udhayakumar"
Add keembey_thermal driver to expose on chip temperature
sensors, and register call back functions for periodic sampling.
This driver does following:
* Reads temperature data from on chip sensors present in Keem Bay
platform.
* Registers callback function to intel tsens driver for sampling
temperature values periodically.
* Decode the raw values from registers to Celsius.
Acked-by: mark gross
Signed-off-by: C Udhayakumar
Signed-off-by: Mark Gross
---
drivers/misc/intel_tsens/Kconfig | 12 +
drivers/misc/intel_tsens/Makefile | 1 +
drivers/misc/intel_tsens/keembay_thermal.c | 169 ++
drivers/misc/intel_tsens/keembay_tsens.h | 366 +
4 files changed, 548 insertions(+)
create mode 100644 drivers/misc/intel_tsens/keembay_thermal.c
create mode 100644 drivers/misc/intel_tsens/keembay_tsens.h
diff --git a/drivers/misc/intel_tsens/Kconfig b/drivers/misc/intel_tsens/Kconfig
index be8d27e81864..5cfe6b4004e5 100644
--- a/drivers/misc/intel_tsens/Kconfig
+++ b/drivers/misc/intel_tsens/Kconfig
@@ -28,6 +28,18 @@ config INTEL_TSENS_I2C_SLAVE
Say Y if using a processor that includes the Intel VPU such as
Keem Bay. If unsure, say N.
+config KEEMBAY_THERMAL
+ tristate "Temperature sensor driver for intel Keem Bay"
+ depends on INTEL_TSENS_LOCAL_HOST && ARCH_KEEMBAY
+ help
+ Enable this option if you want to have support for Keem Bay
+ thermal management sensors.
+
+ This driver is used for reading onchip temperature sensor
+ values from Keem Bay SoC.
+ Say Y if using a processor that includes the Intel VPU such as
+ Keem Bay. If unsure, say N.
+
config INTEL_TSENS_IA_HOST
tristate "Temperature sensor driver for intel tsens remote host"
depends on I2C && THERMAL
diff --git a/drivers/misc/intel_tsens/Makefile
b/drivers/misc/intel_tsens/Makefile
index f6f41bbca80c..00f63c2d5b2f 100644
--- a/drivers/misc/intel_tsens/Makefile
+++ b/drivers/misc/intel_tsens/Makefile
@@ -7,3 +7,4 @@
obj-$(CONFIG_INTEL_TSENS_LOCAL_HOST) += intel_tsens_thermal.o
obj-$(CONFIG_INTEL_TSENS_I2C_SLAVE)+= intel_tsens_i2c.o
obj-$(CONFIG_INTEL_TSENS_IA_HOST) += intel_tsens_host.o
+obj-$(CONFIG_KEEMBAY_THERMAL) += keembay_thermal.o
diff --git a/drivers/misc/intel_tsens/keembay_thermal.c
b/drivers/misc/intel_tsens/keembay_thermal.c
new file mode 100644
index ..d6c8fa8fc3aa
--- /dev/null
+++ b/drivers/misc/intel_tsens/keembay_thermal.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ *
+ * Intel Keem Bay thermal Driver
+ *
+ * Copyright (C) 2020 Intel Corporation
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "intel_tsens_thermal.h"
+#include "keembay_tsens.h"
+
+struct keembay_thermal_priv {
+ const char *name;
+ void __iomem *base_addr;
+ /* sensor lock*/
+ spinlock_t lock;
+ int current_temp[KEEMBAY_SENSOR_MAX];
+ struct intel_tsens_plat_data *plat_data;
+};
+
+static void kmb_sensor_read_temp(void __iomem *regs_val,
+int offset,
+int sample_valid_mask,
+int sample_value,
+int bit_shift,
+int *temp)
+{
+ int reg_val, kmb_raw_index;
+
+ /* clear the bit of TSENS_EN and re-enable again */
+ iowrite32(0x00, regs_val + AON_TSENS_CFG);
+ iowrite32(CFG_MASK_MANUAL, regs_val + AON_TSENS_CFG);
+ reg_val = ioread32(regs_val + offset);
+ if (reg_val & sample_valid_mask) {
+ reg_val = (reg_val >> bit_shift) & sample_value;
+ kmb_raw_index = reg_val - KEEMBAY_SENSOR_BASE_TEMP;
+ if (kmb_raw_index < 0)
+ reg_val = raw_kmb[0];
+ else if (kmb_raw_index > (raw_kmb_size - 1))
+ reg_val = raw_kmb[raw_kmb_size - 1];
+ else
+ reg_val = raw_kmb[kmb_raw_index];
+ *temp = reg_val;
+ } else {
+ *temp = -255;
+ }
+}
+
+/*The lock is assumed to be held by the caller.*/
+static int keembay_get_temp(struct platform_device *pdev, int type, int *temp)
+{
+ struct keembay_thermal_priv *priv = platform_get_drvdata(pdev);
+
+ spin_lock(>lock);
+ switch (type) {
+ case KEEMBAY_SENSOR_MSS:
+ kmb_sensor_read_temp(priv->base_addr,
+AON_TSENS_DATA0,
+MSS_T_SAMPLE_VALID,
+MSS_T_SAMPLE,
+MSS_BIT_SHIFT,
+temp);
+ priv->current_temp[KEEMBAY_SENSOR_MSS] = *temp;
+ break;
+
+ case KEEMBAY_SENSOR_CSS:
+
[PATCH v4 03/34] mailbox: vpu-ipc-mailbox: Add support for Intel VPU IPC mailbox
From: Daniele Alessandrelli Add mailbox controller enabling inter-processor communication (IPC) between the CPU (aka, the Application Processor - AP) and the VPU on Intel Movidius SoCs like Keem Bay. The controller uses HW FIFOs to enable such communication. Specifically, there are two FIFOs, one for the CPU and one for VPU. Each FIFO can hold 128 entries (messages) of 32-bit each (but only 26 bits are actually usable, since the 6 least-significant bits are reserved). When the Linux kernel on the AP needs to send messages to the VPU firmware, it writes them to the VPU FIFO; similarly, when the VPU firmware needs to send messages to the AP, it writes them to the CPU FIFO. The AP is notified of pending messages in the CPU FIFO by means of the 'FIFO-not-empty' interrupt, which is generated by the CPU FIFO while not empty. This interrupt is cleared automatically once all messages have been read from the FIFO (i.e., the FIFO has been emptied). The hardware doesn't provide an TX done IRQ (i.e., an IRQ that allows the VPU firmware to notify the AP that the message put into the VPU FIFO has been received); however the AP can ensure that the message has been successfully put into the VPU FIFO (and therefore transmitted) by checking the VPU FIFO status register to ensure that writing the message didn't cause the FIFO to overflow. Therefore, the mailbox controller is configured as capable of tx_done IRQs and a tasklet is used to simulate the tx_done IRQ. The tasklet is activated by send_data() right after the message has been put into the VPU FIFO and the VPU FIFO status registers has been checked. If an overflow is reported by the status register, the tasklet passes -EBUSY to mbox_chan_txdone(), to notify the mailbox client of the failed TX. The client should therefore register a tx_done() callback to properly handle failed transmissions. Note: the 'txdone_poll' mechanism cannot be used because it doesn't provide a way to report a failed transmission. Reviewed-by: Mark Gross Signed-off-by: Daniele Alessandrelli Signed-off-by: Mark Gross --- MAINTAINERS | 1 + drivers/mailbox/Kconfig | 11 ++ drivers/mailbox/Makefile | 2 + drivers/mailbox/vpu-ipc-mailbox.c | 297 ++ 4 files changed, 311 insertions(+) create mode 100644 drivers/mailbox/vpu-ipc-mailbox.c diff --git a/MAINTAINERS b/MAINTAINERS index 2b82526a00dc..de23f6e5cfce 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9186,6 +9186,7 @@ M:Daniele Alessandrelli M: Mark Gross S: Supported F: Documentation/devicetree/bindings/mailbox/intel,vpu-ipc-mailbox.yaml +F: drivers/mailbox/vpu-ipc-mailbox.c INTEL WIRELESS 3945ABG/BG, 4965AGN (iwlegacy) M: Stanislaw Gruszka diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index f4abe3529acd..cb50b541a5c6 100644 --- a/drivers/mailbox/Kconfig +++ b/drivers/mailbox/Kconfig @@ -29,6 +29,17 @@ config IMX_MBOX help Mailbox implementation for i.MX Messaging Unit (MU). +config INTEL_VPU_IPC_MBOX + tristate "Intel VPU IPC Mailbox" + depends on HAS_IOMEM + depends on OF || COMPILE_TEST + help + Mailbox implementation for enabling inter-processor communication + between application processors and Intel VPUs. + + Say Y or M here if you are building for an SoC equipped with an Intel + VPU. If M is selected, the module will be called vpu-ipc-mailbox. + config PLATFORM_MHU tristate "Platform MHU Mailbox" depends on OF diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index 7194fa92c787..68768bb2ee43 100644 --- a/drivers/mailbox/Makefile +++ b/drivers/mailbox/Makefile @@ -56,3 +56,5 @@ obj-$(CONFIG_SUN6I_MSGBOX)+= sun6i-msgbox.o obj-$(CONFIG_SPRD_MBOX)+= sprd-mailbox.o obj-$(CONFIG_QCOM_IPCC)+= qcom-ipcc.o + +obj-$(CONFIG_INTEL_VPU_IPC_MBOX) += vpu-ipc-mailbox.o diff --git a/drivers/mailbox/vpu-ipc-mailbox.c b/drivers/mailbox/vpu-ipc-mailbox.c new file mode 100644 index ..ad161a7bbabb --- /dev/null +++ b/drivers/mailbox/vpu-ipc-mailbox.c @@ -0,0 +1,297 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Intel VPU IPC mailbox driver. + * + * Copyright (c) 2020-2021 Intel Corporation. + */ + +#include +#include +#include +#include +#include +#include +#include + +/* + * The IPC FIFO registers (offsets to the base address defined in device tree). + */ + +/* + * TIM_IPC_FIFO - Write a 32-bit entry to FIFO. + * + * The entry to be put in the FIFO must be written to this register. + * + * NOTE: the 6 least-significant bits are reserved for the writing processor + * to include its processor ID, 0 <= x <= 62, so it can determine if the entry + * was written correctly by checking the appropriate bit of register + * TIM_IPC_FIFO_OF_FLAG[n]. + * + * Internally, the hardware increments FIFO write pointer and fill level. + * + */ +#define
[PATCH v3 10/34] misc: xlink-pcie: lh: Add PCIe EP DMA functionality
From: Srikanth Thokala Add Synopsys PCIe DWC core embedded-DMA functionality for local host Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Reviewed-by: Mark Gross Signed-off-by: Srikanth Thokala --- drivers/misc/xlink-pcie/local_host/Makefile | 1 + drivers/misc/xlink-pcie/local_host/dma.c| 575 drivers/misc/xlink-pcie/local_host/epf.c| 15 +- drivers/misc/xlink-pcie/local_host/epf.h| 41 ++ 4 files changed, 629 insertions(+), 3 deletions(-) create mode 100644 drivers/misc/xlink-pcie/local_host/dma.c diff --git a/drivers/misc/xlink-pcie/local_host/Makefile b/drivers/misc/xlink-pcie/local_host/Makefile index 514d3f0c91bc..54fc118e2dd1 100644 --- a/drivers/misc/xlink-pcie/local_host/Makefile +++ b/drivers/misc/xlink-pcie/local_host/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_XLINK_PCIE_LH_DRIVER) += mxlk_ep.o mxlk_ep-objs := epf.o +mxlk_ep-objs += dma.o diff --git a/drivers/misc/xlink-pcie/local_host/dma.c b/drivers/misc/xlink-pcie/local_host/dma.c new file mode 100644 index ..42978fb0db49 --- /dev/null +++ b/drivers/misc/xlink-pcie/local_host/dma.c @@ -0,0 +1,575 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Intel Keem Bay XLink PCIe Driver + * + * Copyright (C) 2021 Intel Corporation + */ +#include +#include +#include + +#include "epf.h" + +#define DMA_DBI_OFFSET (0x38) + +/* PCIe DMA control 1 register definitions. */ +#define DMA_CH_CONTROL1_CB_SHIFT (0) +#define DMA_CH_CONTROL1_TCB_SHIFT (1) +#define DMA_CH_CONTROL1_LLP_SHIFT (2) +#define DMA_CH_CONTROL1_LIE_SHIFT (3) +#define DMA_CH_CONTROL1_CS_SHIFT (5) +#define DMA_CH_CONTROL1_CCS_SHIFT (8) +#define DMA_CH_CONTROL1_LLE_SHIFT (9) +#define DMA_CH_CONTROL1_CB_MASK(BIT(DMA_CH_CONTROL1_CB_SHIFT)) +#define DMA_CH_CONTROL1_TCB_MASK (BIT(DMA_CH_CONTROL1_TCB_SHIFT)) +#define DMA_CH_CONTROL1_LLP_MASK (BIT(DMA_CH_CONTROL1_LLP_SHIFT)) +#define DMA_CH_CONTROL1_LIE_MASK (BIT(DMA_CH_CONTROL1_LIE_SHIFT)) +#define DMA_CH_CONTROL1_CS_MASK(0x3 << DMA_CH_CONTROL1_CS_SHIFT) +#define DMA_CH_CONTROL1_CCS_MASK (BIT(DMA_CH_CONTROL1_CCS_SHIFT)) +#define DMA_CH_CONTROL1_LLE_MASK (BIT(DMA_CH_CONTROL1_LLE_SHIFT)) + +/* DMA control 1 register Channel Status */ +#define DMA_CH_CONTROL1_CS_RUNNING (0x1 << DMA_CH_CONTROL1_CS_SHIFT) +#define DMA_CH_CONTROL1_CS_HALTED (0x2 << DMA_CH_CONTROL1_CS_SHIFT) +#define DMA_CH_CONTROL1_CS_STOPPED (0x3 << DMA_CH_CONTROL1_CS_SHIFT) + +/* PCIe DMA Engine enable register definitions. */ +#define DMA_ENGINE_EN_SHIFT(0) +#define DMA_ENGINE_EN_MASK (BIT(DMA_ENGINE_EN_SHIFT)) + +/* PCIe DMA interrupt registers definitions. */ +#define DMA_ABORT_INTERRUPT_SHIFT (16) +#define DMA_ABORT_INTERRUPT_MASK (0xFF << DMA_ABORT_INTERRUPT_SHIFT) +#define DMA_ABORT_INTERRUPT_CH_MASK(_c) (BIT(_c) << DMA_ABORT_INTERRUPT_SHIFT) +#define DMA_DONE_INTERRUPT_MASK(0xFF) +#define DMA_DONE_INTERRUPT_CH_MASK(_c) (BIT(_c)) +#define DMA_ALL_INTERRUPT_MASK \ + (DMA_ABORT_INTERRUPT_MASK | DMA_DONE_INTERRUPT_MASK) + +#define DMA_LL_ERROR_SHIFT (16) +#define DMA_CPL_ABORT_SHIFT(8) +#define DMA_CPL_TIMEOUT_SHIFT (16) +#define DMA_DATA_POI_SHIFT (24) +#define DMA_AR_ERROR_CH_MASK(_c) (BIT(_c)) +#define DMA_LL_ERROR_CH_MASK(_c) (BIT(_c) << DMA_LL_ERROR_SHIFT) +#define DMA_UNREQ_ERROR_CH_MASK(_c)(BIT(_c)) +#define DMA_CPL_ABORT_ERROR_CH_MASK(_c)(BIT(_c) << DMA_CPL_ABORT_SHIFT) +#define DMA_CPL_TIMEOUT_ERROR_CH_MASK(_c) (BIT(_c) << DMA_CPL_TIMEOUT_SHIFT) +#define DMA_DATA_POI_ERROR_CH_MASK(_c) (BIT(_c) << DMA_DATA_POI_SHIFT) + +#define DMA_LLLAIE_SHIFT (16) +#define DMA_LLLAIE_MASK(0xF << DMA_LLLAIE_SHIFT) + +#define DMA_CHAN_WRITE_MAX_WEIGHT (0x7) +#define DMA_CHAN_READ_MAX_WEIGHT (0x3) +#define DMA_CHAN0_WEIGHT_OFFSET(0) +#define DMA_CHAN1_WEIGHT_OFFSET(5) +#define DMA_CHAN2_WEIGHT_OFFSET(10) +#define DMA_CHAN3_WEIGHT_OFFSET(15) +#define DMA_CHAN_WRITE_ALL_MAX_WEIGHT \ + ((DMA_CHAN_WRITE_MAX_WEIGHT << DMA_CHAN0_WEIGHT_OFFSET) | \ +(DMA_CHAN_WRITE_MAX_WEIGHT << DMA_CHAN1_WEIGHT_OFFSET) | \ +(DMA_CHAN_WRITE_MAX_WEIGHT << DMA_CHAN2_WEIGHT_OFFSET) | \ +(DMA_CHAN_WRITE_MAX_WEIGHT << DMA_CHAN3_WEIGHT_OFFSET)) +#define DMA_CHAN_READ_ALL_MAX_WEIGHT \ + ((DMA_CHAN_READ_MAX_WEIGHT << DMA_CHAN0_WEIGHT_OFFSET) |\ +(DMA_CHAN_READ_MAX_WEIGHT << DMA_CHAN1_WEIGHT_OFFSET) |\ +(DMA_CHAN_READ_MAX_WEIGHT << DMA_CHAN2_WEIGHT_OFFSET) |\ +(DMA_CHAN_READ_MAX_WEIGHT << DMA_CHAN3_WEIGHT_OFFSET)) + +#define PCIE_REGS_PCIE_APP_CNTRL 0x8 +#define APP_XFER_PENDING BIT(6) +#define
[PATCH v3 25/34] misc: Add Keem Bay VPU manager
From: "Li, Tingqian"
VPU IP on Keem Bay SOC is a vision acceleration IP complex
under the control of a RTOS-based firmware (running on RISC
MCU inside the VPU IP) serving user-space application
running on CPU side for HW accelerated computer vision tasks.
This module is kernel counterpart of the VPUAL(VPU abstraction
layer) which bridges firmware on VPU side and applications on
CPU user-space, it assists firmware on VPU side serving multiple
user space application processes on CPU side concurrently while
also performing necessary data buffer management on behave of
VPU IP.
objmgr provides basic infrastructure for create/destroy VPU side
software object concurrently on demand of user-space application
and also automatically release leaked objects during handling of
application termination. Note this module only cares about the
life-cycle of such objects, it's up to the application and firmware
to define the behavior/operations of each object.
objmgr does it's job by communicating with firmware through a fixed
reserved xlink channel, using a very simple message protocol.
smm provides DMABuf allocation/import facilities to allow user-space
app pass data to/from VPU in zero-copy fashion. it also provided a
convenient ioctl function for converting virtual pointer of a mem-mapped
and imported DMABuf into it's corresponding dma address, to allow
user-space app to specify the sub-regions of a bigger DMABuf to be
processed by VPU.
Signed-off-by: Li, Tingqian
Signed-off-by: Zhou, Luwei
Signed-off-by: Wang, jue
---
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile| 1 +
drivers/misc/vpumgr/Kconfig | 9 +
drivers/misc/vpumgr/Makefile | 3 +
drivers/misc/vpumgr/vpu_common.h | 31 ++
drivers/misc/vpumgr/vpu_mgr.c| 370
drivers/misc/vpumgr/vpu_smm.c| 554 +
drivers/misc/vpumgr/vpu_smm.h| 30 ++
drivers/misc/vpumgr/vpu_vcm.c| 584 +++
drivers/misc/vpumgr/vpu_vcm.h| 84 +
include/uapi/misc/vpumgr.h | 64
11 files changed, 1731 insertions(+)
create mode 100644 drivers/misc/vpumgr/Kconfig
create mode 100644 drivers/misc/vpumgr/Makefile
create mode 100644 drivers/misc/vpumgr/vpu_common.h
create mode 100644 drivers/misc/vpumgr/vpu_mgr.c
create mode 100644 drivers/misc/vpumgr/vpu_smm.c
create mode 100644 drivers/misc/vpumgr/vpu_smm.h
create mode 100644 drivers/misc/vpumgr/vpu_vcm.c
create mode 100644 drivers/misc/vpumgr/vpu_vcm.h
create mode 100644 include/uapi/misc/vpumgr.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 09ae65e98681..2d1f7b165cc8 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -484,4 +484,5 @@ source "drivers/misc/uacce/Kconfig"
source "drivers/misc/xlink-pcie/Kconfig"
source "drivers/misc/xlink-ipc/Kconfig"
source "drivers/misc/xlink-core/Kconfig"
+source "drivers/misc/vpumgr/Kconfig"
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f3a6eb03bae9..2936930f3edc 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -60,3 +60,4 @@ obj-$(CONFIG_HISI_HIKEY_USB) += hisi_hikey_usb.o
obj-y += xlink-pcie/
obj-$(CONFIG_XLINK_IPC)+= xlink-ipc/
obj-$(CONFIG_XLINK_CORE) += xlink-core/
+obj-$(CONFIG_VPUMGR) += vpumgr/
diff --git a/drivers/misc/vpumgr/Kconfig b/drivers/misc/vpumgr/Kconfig
new file mode 100644
index ..bb82ff83afd3
--- /dev/null
+++ b/drivers/misc/vpumgr/Kconfig
@@ -0,0 +1,9 @@
+config VPUMGR
+ tristate "VPU Manager"
+ depends on ARM64 && XLINK_CORE
+ help
+ VPUMGR manages life-cycle of VPU related resources which were
+ dynamically allocated on demands of user-space application
+
+ Select y or m if you have a processor including the Intel
+ Vision Processor (VPU) on it.
diff --git a/drivers/misc/vpumgr/Makefile b/drivers/misc/vpumgr/Makefile
new file mode 100644
index ..51441dc8a930
--- /dev/null
+++ b/drivers/misc/vpumgr/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_VPUMGR) += vpumgr.o
+vpumgr-objs := vpu_mgr.o vpu_smm.o vpu_vcm.o
diff --git a/drivers/misc/vpumgr/vpu_common.h b/drivers/misc/vpumgr/vpu_common.h
new file mode 100644
index ..cd474ffc05f3
--- /dev/null
+++ b/drivers/misc/vpumgr/vpu_common.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0-only
+ * VPUMGR Kernel module - common definition
+ * Copyright (C) 2020-2021 Intel Corporation
+ */
+#ifndef _VPU_COMMON_H
+#define _VPU_COMMON_H
+#include
+#include
+
+#include
+
+#include "vpu_vcm.h"
+
+/* there will be one such device for each HW instance */
+struct vpumgr_device {
+ struct device *sdev;
+ struct device *dev;
+ dev_t devnum;
+ struct cdev cdev;
+ struct platform_device *pdev;
+
+ struct vcm_dev vcm;
+ struct dentry *debugfs_root;
+
+ struct mutex client_mutex;
Re: [PATCH V3 0/6] x86: don't abuse tss.sp1
On Sat, Jan 30, 2021 at 12:43 AM Borislav Petkov wrote: > > On Fri, Jan 29, 2021 at 11:35:46PM +0800, Lai Jiangshan wrote: > > Any feedback? > > Yes: be patient please. > > Thx. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette Thank you for your reply and this gentle hint. I did "reply to all", but I have no clue why the mail failed to be delivered to LKML, and maybe it also failed to be delivered to other guys in the cc-list. Hopefully this won't happen again to this reply. Thanks Lai
[PATCH v4 28/34] misc: Intel tsens IA host driver.
From: "C, Udhayakumar"
Add Intel tsens IA host driver for Intel Edge.AI Computer Vision
platforms.
About Intel Edge.AI Computer Vision platforms:
-
The Intel Edge.AI Computer Vision platforms are vision processing systems
targeting machine vision applications for connected devices.
They are based on ARM A53 CPU running Linux and acts as a PCIe
endpoint device.
High-level architecture:
Remote Host IA CPU Local Host ARM CPU
--
| Platform| | Thermal Daemon|
| Management SW| ||
--
| Intel tsens | | intel tsens i2c slave |
| i2c client | | and thermal driver|
--
| XLINK I2C | | XLINK I2C Slave |
| controller | <=> | controller |
xlink smbus --
intel tsens module:
---
The tsens module enables reading of on chip sensors present
in the Intel Edge.AI Computer Vision platforms.In the tsens module
various junction and SoC temperatures are reported using thermal
subsystem and i2c subsystem.
Temperature data reported using thermal subsystem will be used for
various cooling agents such as DVFS, fan control and shutdown the
system in case of critical temperature.
Temperature data reported using i2c subsystem will be used by
platform manageability software running in IA host.
- Remote Host driver
* Intended for IA CPU
* It is a I2C client driver
* Driver path:
{tree}/drivers/misc/intel_tsens/intel_tsens_host.c
Local host and Remote host drivers communicates using
I2C SMBUS protocol.
Acked-by: Mark Mross
Signed-off-by: C Udhayakumar
Signed-off-by: Mark Gross
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/intel_tsens_host.rst| 71
drivers/misc/intel_tsens/Kconfig| 13 +
drivers/misc/intel_tsens/Makefile | 1 +
drivers/misc/intel_tsens/intel_tsens_host.c | 351
include/linux/intel_tsens_host.h| 34 ++
6 files changed, 471 insertions(+)
create mode 100644 Documentation/hwmon/intel_tsens_host.rst
create mode 100644 drivers/misc/intel_tsens/intel_tsens_host.c
create mode 100644 include/linux/intel_tsens_host.h
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index fc29100bef73..7a9eaddd1ab3 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -81,6 +81,7 @@ Hardware Monitoring Kernel Drivers
isl68137
it87
intel_tsens_sensor.rst
+ intel_tsens_host.rst
jc42
k10temp
k8temp
diff --git a/Documentation/hwmon/intel_tsens_host.rst
b/Documentation/hwmon/intel_tsens_host.rst
new file mode 100644
index ..012c593f969f
--- /dev/null
+++ b/Documentation/hwmon/intel_tsens_host.rst
@@ -0,0 +1,71 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+Kernel driver: intel_tsens
+==
+
+Supported chips:
+ * Intel Edge.AI Computer Vision platforms: Keem Bay
+
+Slave address: The address is assigned by the hddl device management
+ driver.
+
+Datasheet:
+ Documentation/hwmon/intel_tsens_sensor.rst#Remote Thermal Interface
+
+Authors:
+- Thalaiappan, Rathina
+
+Description
+===
+The intel_tsens is a temperature sensor driver receiving the junction
temperature
+from different heating points inside the SOC. The driver will receive the
+temperature on SMBUS connection. The reported temperature is in degrees
Celsius.
+
+In Keem Bay, the four thermal junction temperature points are,
+Media Subsystem (mss), NN subsystem (nce), Compute subsystem (cse) and
+SOC(Maximum of mss, nce and cse).
+
+Example
+===
+Temperature reported by a Keem Bay on the Linux Thermal sysfs interface.
+
+# cat /sys/class/thermal/thermal_zone*/type
+mss
+css
+nce
+soc
+
+# cat /sys/class/thermal/thermal_zone*/temp
+0
+29210
+28478
+29210
+
++---+-+
+| offset| Sensor|
++---+-+
+| 0 | mss |
++---+-+
+| 1 | css |
++---+-+
+| 2 | nce |
++---+-+
+| 3 | soc |
++---+-+
+
+#sudo i2cdetect -l
+i2c-8 smbus SMBus I801 adapter at efa0 SMBus adapte
r
+
+To read mss junction temperature:
+#i2cget -y 8 0x0 w
+
+To read cse junction temperature:
+#i2cget -y 8 0x1 w
+
+To read nce junction temperature:
+#i2cget -y 8 0x2 w
+
+To read overall SoC temperature:
+#i2cget -y 8 0x3 w
diff --git a/drivers/misc/intel_tsens/Kconfig
Re: kprobes broken since 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()")
On Fri, 29 Jan 2021 18:59:43 +0100
Peter Zijlstra wrote:
> On Fri, Jan 29, 2021 at 09:45:48AM -0800, Alexei Starovoitov wrote:
> > Same things apply to bpf side. We can statically prove safety for
> > ftrace and kprobe attaching whereas to deal with NMI situation we
> > have to use run-time checks for recursion prevention, etc.
>
> I have no idea what you're saying. You can attach to functions that are
> called with random locks held, you can create kprobes in some very
> sensitive places.
>
> What can you staticlly prove about that?
For the bpf and the kprobe tracer, if a probe hits in the NMI context,
it can call the handler with another handler processing events.
kprobes is carefully avoiding the deadlock by checking recursion
with per-cpu variable. But if the handler is shared with the other events
like tracepoints, it needs to its own recursion cheker too.
So, Alexei, maybe you need something like this instead of in_nmi() check.
DEFINE_PER_CPU(bool, under_running_bpf);
common_handler()
{
if (__this_cpu_read(under_running_bpf))
return;
__this_cpu_write(under_running_bpf, true);
/* execute bpf prog */
__this_cpu_write(under_running_bpf, false);
}
Does this work for you?
Thank you,
--
Masami Hiramatsu
[PATCH v3 01/34] Add Vision Processing Unit (VPU) documentation.
From: mark gross The Intel VPU needs a complicated SW stack to make it work. Add a directory to hold VPU related documentation including an architectural overview of the SW stack that the patches implement. Cc: Jonathan Corbet Signed-off-by: Mark Gross --- Documentation/index.rst | 1 + Documentation/vpu/index.rst | 16 ++ Documentation/vpu/vpu-stack-overview.rst | 270 +++ 3 files changed, 287 insertions(+) create mode 100644 Documentation/vpu/index.rst create mode 100644 Documentation/vpu/vpu-stack-overview.rst diff --git a/Documentation/index.rst b/Documentation/index.rst index 5888e8a7272f..81a02f2af939 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -137,6 +137,7 @@ needed). misc-devices/index scheduler/index mhi/index + vpu/index Architecture-agnostic documentation --- diff --git a/Documentation/vpu/index.rst b/Documentation/vpu/index.rst new file mode 100644 index ..7e290e048910 --- /dev/null +++ b/Documentation/vpu/index.rst @@ -0,0 +1,16 @@ +.. SPDX-License-Identifier: GPL-2.0-only + + +Vision Processor Unit Documentation + + +This documentation contains information for the Intel VPU stack. + +.. class:: toc-title + + Table of contents + +.. toctree:: + :maxdepth: 2 + + vpu-stack-overview diff --git a/Documentation/vpu/vpu-stack-overview.rst b/Documentation/vpu/vpu-stack-overview.rst new file mode 100644 index ..1fe9ce423177 --- /dev/null +++ b/Documentation/vpu/vpu-stack-overview.rst @@ -0,0 +1,270 @@ +.. SPDX-License-Identifier: GPL-2.0 + +== +Intel VPU architecture +== + +Overview + + +The Intel Movidius acquisition has developed a Vision Processing Unit (VPU) +roadmap of products starting with Keem Bay (KMB). The hardware configurations +the VPU can support include: + +1. Standalone smart camera that does local Computer Vision (CV) processing in + camera +2. Standalone appliance or signel board computer connected to a network and + tethered cameras doing local CV processing +3. Embedded in a USB dongle or M.2 as an CV accelerator. +4. Multiple VPU enabled SOC's on a PCIe card as a CV accelerator in a larger IA + box or server. + +Keem Bay is the first instance of this family of products. This document +provides an architectural overview of the software stack supporting the VPU +enabled products. + +Keem Bay (KMB) is a Computer Vision AI processing SoC based on ARM A53 CPU that +provides Edge neural network acceleration (inference) and includes a Vision +Processing Unit (VPU) hardware. The ARM CPU SubSystem (CPUSS) interfaces +locally to the VPU and enables integration/interfacing with a remote host over +PCIe or USB or Ethernet interfaces. The interface between the CPUSS and the VPU +is implemented with hardware FIFOs (Control) and coherent memory mapping (Data) +such that zero copy processing can happen within the VPU. + +The KMB can be used in all 4 of the above classes of designs. + +We refer to the 'local host' as being the ARM part of the SoC, while the +'remote host' as the IA system hosting the KMB device(s). The KMB SoC boots +from an eMMC via uBoot and ARM Linux compatible device tree interface with an +expectation to fully boot within hundreds of milliseconds. There is also +support for downloading the kernel and root file system image from a remote +host. + +The eMMC can be updated with standard Mender update process. +See https://github.com/mendersoftware/mender + +The VPU is started and controlled from the A53 local host. Its firmware image +is loaded using the drive firware helper KAPI's. + +The VPU IP firware payload consists of a SPARC ISA RTEMS bootloader and/or +application binary. + +The interface allowing (remote or local) host clients to access VPU IP +capabilities is realized through an abstracted programming model, which +provides Remote Proxy APIs for a host CPU application to dynamically create and +execute CV and NN workloads on the VPU. All frameworks exposed through +programming model’s APIs are contained in the pre-compiled standard firmware +image. + +There is a significant software stack built up to support KMB and the use +cases. The rest of this documentation provides an overview of the components +of the stack. + +Keem Bay IPC + + +Directly interfaces with the KMB hardware FIFOs to provide zero copy processing +from the VPU. It implements the lowest level protocol for interacting with the +VPU. + +The Keem Bay IPC mechanism is based on shared memory and hardware FIFOs. +Specifically there are: + +* Two 128-entry hardware FIFOs, one for the CPU and one for the VPU. +* Two shared memory regions, used as memory pool for allocating IPC buffers. + +An IPC channel is a software abstraction allowing communication multiplexing, +so that multiple
Re: [PATCH net-next 1/8] dt-bindings: net: dsa: dt bindings for microchip lan937x
On Thu, Jan 28, 2021 at 12:11:05PM +0530, Prasanna Vengateshan wrote:
> + spi-max-frequency:
> +maximum: 5000
And it actually works at 50 MHz? Cool.
> +
> + reset-gpios:
> +description: Optional gpio specifier for a reset line
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +//Ethernet switch connected via spi to the host, CPU port wired to eth1
> +eth1 {
So if you do bother to add the DSA master in the example, can this be
so that we could associate with the phandle below?
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + fixed-link {
> +speed = <1000>;
> +full-duplex;
> + };
> +};
> +
> +spi1 {
Is this a label or a node name? spi1 or spi@1?
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-0 = <_spi_ksz>;
> + cs-gpios = <0>, <0>, <0>, < 28 0>;
> + id = <1>;
I know this is the SPI controller and thus mostly irrelevant, but what
is "id = <1>"?
> +
> + lan9374: switch@0 {
> +compatible = "microchip,lan9374";
> +reg = <0>;
> +
> +spi-max-frequency = <4400>;
> +
> +ethernet-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> +reg = <0>;
> +label = "lan1";
> + };
> + port@1 {
> +reg = <1>;
> +label = "lan2";
> + };
> + port@2 {
> +reg = <7>;
reg should match node index (port@2), here and everywhere below. As for
the net device labels, I'm not sure if the mismatch is deliberate there.
> +label = "lan3";
> + };
> + port@3 {
> +reg = <2>;
> +label = "lan4";
> + };
> + port@4 {
> +reg = <6>;
> +label = "lan5";
> + };
> + port@5 {
> +reg = <3>;
> +label = "lan6";
> + };
> + port@6 {
> +reg = <4>;
> +label = "cpu";
label for CPU port is not needed/used.
> +ethernet = <>;
> +fixed-link {
> + speed = <1000>;
> + full-duplex;
> +};
> + };
> + port@7 {
> +reg = <5>;
> +label = "lan7";
> +fixed-link {
> + speed = <1000>;
> + full-duplex;
> +};
> + };
> +};
> + };
> +};
Re: [PATCH v3 06/34] dt-bindings: Add bindings for Keem Bay VPU IPC driver
On Wed, Jan 27, 2021 at 08:00:11AM -0600, Rob Herring wrote: > On Mon, 25 Jan 2021 21:40:08 -0800, mgr...@linux.intel.com wrote: > > From: Paul Murphy > > > > Add DT bindings documentation for the Keem Bay VPU IPC driver. > > > > Cc: Rob Herring > > Cc: devicet...@vger.kernel.org > > Reviewed-by: Mark Gross > > Signed-off-by: Paul Murphy > > Co-developed-by: Daniele Alessandrelli > > Signed-off-by: Daniele Alessandrelli > > --- > > .../soc/intel/intel,keembay-vpu-ipc.yaml | 153 ++ > > 1 file changed, 153 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/soc/intel/intel,keembay-vpu-ipc.yaml > > > > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > ./Documentation/devicetree/bindings/soc/intel/intel,keembay-vpu-ipc.yaml:21:9: > [warning] wrong indentation: expected 10 but found 8 (indentation) > > dtschema/dtc warnings/errors: fixed. > > See https://patchwork.ozlabs.org/patch/1432168 > > This check can fail if there are any dependencies. The base for a patch > series is generally the most recent rc1. > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit. >
Re: [PATCH V5 5/5] gpio: gpio-xilinx: Add check if width exceeds 32
On Fri, Jan 29, 2021 at 07:56:50PM +0530, Srinivas Neeli wrote: > Add check to see if gpio-width property does not exceed 32. > If it exceeds then return -EINVAL. > > Signed-off-by: Srinivas Neeli > Reviewed-by: Linus Walleij Acked-by: William Breathitt Gray > --- > Changes in V5: > -None > Changes in V4: > -New patch. > --- > drivers/gpio/gpio-xilinx.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c > index acd574779ca6..b411d3156e0b 100644 > --- a/drivers/gpio/gpio-xilinx.c > +++ b/drivers/gpio/gpio-xilinx.c > @@ -589,6 +589,9 @@ static int xgpio_probe(struct platform_device *pdev) > if (of_property_read_u32(np, "xlnx,gpio-width", >gpio_width[0])) > chip->gpio_width[0] = 32; > > + if (chip->gpio_width[0] > 32) > + return -EINVAL; > + > spin_lock_init(>gpio_lock); > > if (of_property_read_u32(np, "xlnx,is-dual", _dual)) > @@ -613,6 +616,8 @@ static int xgpio_probe(struct platform_device *pdev) >>gpio_width[1])) > chip->gpio_width[1] = 32; > > + if (chip->gpio_width[1] > 32) > + return -EINVAL; > } > > chip->gc.base = -1; > -- > 2.7.4 > signature.asc Description: PGP signature
Re: [PATCH 2/2] security.capability: fix conversions on getxattr
On Fri, Jan 29, 2021 at 05:11:53PM -0600, Eric W. Biederman wrote:
> "Serge E. Hallyn" writes:
>
> > On Thu, Jan 28, 2021 at 08:44:26PM +0100, Miklos Szeredi wrote:
> >> On Thu, Jan 28, 2021 at 6:09 PM Serge E. Hallyn wrote:
> >> >
> >> > On Tue, Jan 19, 2021 at 07:34:49PM -0600, Eric W. Biederman wrote:
> >> > > Miklos Szeredi writes:
> >> > >
> >> > > > if (!rootid_owns_currentns(kroot)) {
> >> > > > - kfree(tmpbuf);
> >> > > > - return -EOPNOTSUPP;
> >> > > > + size = -EOVERFLOW;
> >> >
> >> > Why this change? Christian (cc:d) noticed that this is a user visible
> >> > change.
> >> > Without this change, if you are in a userns which has different rootid,
> >> > the
> >> > EOVERFLOW tells vfs_getxattr to vall back to __vfs_getxattr() and so you
> >> > can
> >> > see the v3 capability with its rootid.
> >> >
> >> > With this change, you instead just get EOVERFLOW.
> >>
> >> Why would the user want to see nonsense (in its own userns) rootid and
> >> what would it do with it?
> >
> > They would know that the data is there.
>
> But an error of -EOVERFLOW still indicates data is there.
> You just don't get the data because it can not be represented.
Ok - and this happens *after* the check for whether the rootid to maps
into the current ns.
That sounds reasonable, thanks.
> >> Please give an example where an untranslatable rootid would make any
> >> sense at all to the user.
> >
> > I may have accidentally, from init_user_ns, as uid 1000, set an
> > fscap with rootid 11 instead of 10, and wonder why the
> > cap is not working in the container where 10 is root.
>
> Getting -EOVERFLOW when attempting to read the cap from inside
> the user namespace will immediately tell you what is wrong. The rootid
> does not map.
>
> That is how all the non-mapping situations are handled. Either
> -EOVERFLOW or returning INVALID_UID/the unmapped user id aka nobody.
>
> The existing code is wrong because it returns a completely untranslated
> uid, which is completely non-sense.
>
> An argument could be made for returning a rootid of 0x aka
> INVALID_UID in a v3 cap xattr when the rootid can not be mapped. I
> think that is what we do with posix_acls that contain ids that don't
> map. My sense is returning -EOVERFLOW inside the container and
> returning the v3 cap xattr outside the container will most quickly get
> the problem diagnosed, and will be the most likely to not cause
> problems.
>
> If there is a good case for returning a v3 cap with rootid of 0x
> instead of -EOVERFLOW we can do that. Right now I don't see anything
> that would be compelling in either direction.
>
> Eric
>
>
>
Re: [PATCH v7 2/2] Kbuild: implement support for DWARF v5
On Fri, Jan 29, 2021 at 04:44:01PM -0800, Nick Desaulniers wrote:
> DWARF v5 is the latest standard of the DWARF debug info format.
>
> Feature detection of DWARF5 is onerous, especially given that we've
> removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> support.
>
> The DWARF version of a binary can be validated with:
> $ llvm-dwarfdump vmlinux | head -n 4 | grep version
> or
> $ readelf --debug-dump=info vmlinux 2>/dev/null | grep Version
>
> DWARF5 wins significantly in terms of size when mixed with compression
> (CONFIG_DEBUG_INFO_COMPRESSED).
>
> 363Mvmlinux.clang12.dwarf5.compressed
> 434Mvmlinux.clang12.dwarf4.compressed
> 439Mvmlinux.clang12.dwarf2.compressed
> 457Mvmlinux.clang12.dwarf5
> 536Mvmlinux.clang12.dwarf4
> 548Mvmlinux.clang12.dwarf2
>
> 515Mvmlinux.gcc10.2.dwarf5.compressed
> 599Mvmlinux.gcc10.2.dwarf4.compressed
> 624Mvmlinux.gcc10.2.dwarf2.compressed
> 630Mvmlinux.gcc10.2.dwarf5
> 765Mvmlinux.gcc10.2.dwarf4
> 809Mvmlinux.gcc10.2.dwarf2
>
> Though the quality of debug info is harder to quantify; size is not a
> proxy for quality.
>
> Jakub notes:
> All [GCC] 5.1 - 6.x did was start accepting -gdwarf-5 as experimental
> option that enabled some small DWARF subset (initially only a few
> DW_LANG_* codes newly added to DWARF5 drafts). Only GCC 7 (released
> after DWARF 5 has been finalized) started emitting DWARF5 section
> headers and got most of the DWARF5 changes in...
>
> Version check GCC so that we don't need to worry about the difference in
> command line args between GNU readelf and llvm-readelf/llvm-dwarfdump to
> validate the DWARF Version in the assembler feature detection script.
>
> GNU `as` only recently gained support for specifying -gdwarf-5, so when
> compiling with Clang but without Clang's integrated assembler
> (LLVM_IAS=1 is not set), explicitly add -Wa,-gdwarf-5 to DEBUG_CFLAGS.
>
> Disabled for now if CONFIG_DEBUG_INFO_BTF is set; pahole doesn't yet
> recognize the new additions to the DWARF debug info. Thanks to Sedat for
> the report.
>
> Link: http://www.dwarfstd.org/doc/DWARF5.pdf
> Reported-by: Sedat Dilek
> Suggested-by: Arvind Sankar
> Suggested-by: Caroline Tice
> Suggested-by: Fangrui Song
> Suggested-by: Jakub Jelinek
> Suggested-by: Masahiro Yamada
> Suggested-by: Nathan Chancellor
> Signed-off-by: Nick Desaulniers
Reviewed-by: Nathan Chancellor
> ---
> Makefile | 1 +
> include/asm-generic/vmlinux.lds.h | 7 ++-
> lib/Kconfig.debug | 18 ++
> scripts/test_dwarf5_support.sh| 8
> 4 files changed, 33 insertions(+), 1 deletion(-)
> create mode 100755 scripts/test_dwarf5_support.sh
>
> diff --git a/Makefile b/Makefile
> index d2b4980807e0..5387a6f2f62d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -831,6 +831,7 @@ KBUILD_AFLAGS += -Wa,-gdwarf-2
> endif
>
> dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
> DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
>
> ifdef CONFIG_DEBUG_INFO_REDUCED
> diff --git a/include/asm-generic/vmlinux.lds.h
> b/include/asm-generic/vmlinux.lds.h
> index 34b7e0d2346c..1e7cde4bd3f9 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -842,8 +842,13 @@
> /* DWARF 4 */ \
> .debug_types0 : { *(.debug_types) } \
> /* DWARF 5 */ \
> + .debug_addr 0 : { *(.debug_addr) } \
> + .debug_line_str 0 : { *(.debug_line_str) } \
> + .debug_loclists 0 : { *(.debug_loclists) } \
> .debug_macro0 : { *(.debug_macro) } \
> - .debug_addr 0 : { *(.debug_addr) }
> + .debug_names0 : { *(.debug_names) } \
> + .debug_rnglists 0 : { *(.debug_rnglists) } \
> + .debug_str_offsets 0 : { *(.debug_str_offsets) }
>
> /* Stabs debugging sections. */
> #define STABS_DEBUG \
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 94c1a7ed6306..ad6f78989d4f 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -268,6 +268,24 @@ config DEBUG_INFO_DWARF4
> It makes the debug information larger, but it significantly
> improves the success of resolving variables in gdb on optimized code.
>
> +config DEBUG_INFO_DWARF5
> + bool "Generate DWARF Version 5 debuginfo"
> + depends on GCC_VERSION >= 5 || CC_IS_CLANG
> + depends on CC_IS_GCC ||
> $(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC) $(CLANG_FLAGS))
> + depends on !DEBUG_INFO_BTF
> + help
> + Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc
> +
Re: [PATCH net-next] net: packet: make pkt_sk() inline
Hello: This patch was applied to netdev/net-next.git (refs/heads/master): On Wed, 27 Jan 2021 04:33:02 -0800 you wrote: > From: Menglong Dong > > It's better make 'pkt_sk()' inline here, as non-inline function > shouldn't occur in headers. Besides, this function is simple > enough to be inline. > > Signed-off-by: Menglong Dong > > [...] Here is the summary with links: - [net-next] net: packet: make pkt_sk() inline https://git.kernel.org/netdev/net-next/c/8c22475148a8 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
[PATCH 1/2] docs: Make syscalls' helpers naming consistent
The documentation explains the need to create internal syscalls' helpers,
and that they should be called `kern_xyzzy()`. However, the comment at
include/linux/syscall.h says that they should be named as
`ksys_xyzzy()`, and so are all the helpers declared bellow it. Change the
documentation to reflect this.
Cc: Dominik Brodowski
Fixes: 819671ff849b ("syscalls: define and explain goal to not call syscalls in
the kernel")
Signed-off-by: André Almeida
---
Documentation/process/adding-syscalls.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/process/adding-syscalls.rst
b/Documentation/process/adding-syscalls.rst
index a3ecb236576c..61bdaec188ea 100644
--- a/Documentation/process/adding-syscalls.rst
+++ b/Documentation/process/adding-syscalls.rst
@@ -501,7 +501,7 @@ table, but not from elsewhere in the kernel. If the
syscall functionality is
useful to be used within the kernel, needs to be shared between an old and a
new syscall, or needs to be shared between a syscall and its compatibility
variant, it should be implemented by means of a "helper" function (such as
-``kern_xyzzy()``). This kernel function may then be called within the
+``ksys_xyzzy()``). This kernel function may then be called within the
syscall stub (``sys_xyzzy()``), the compatibility syscall stub
(``compat_sys_xyzzy()``), and/or other kernel code.
--
2.30.0
[PATCH 2/2] Documentation: admin-guide: Update kvm/xen config option
Since commit 9bba03d4473d ("kconfig: remove 'kvmconfig' and 'xenconfig'
shorthands") kvm/xen config shortcuts are not available anymore. Update
the file to reflect how they should be used, with the full filename.
Signed-off-by: André Almeida
---
Documentation/admin-guide/README.rst | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/README.rst
b/Documentation/admin-guide/README.rst
index 261b7b4cca1f..35314b63008c 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -226,10 +226,11 @@ Configuring the kernel
all module options to built in (=y) options. You can
also preserve modules by LMC_KEEP.
- "make kvmconfig" Enable additional options for kvm guest kernel support.
+ "make kvm_guest.config" Enable additional options for kvm guest kernel
+ support.
- "make xenconfig" Enable additional options for xen dom0 guest kernel
-support.
+ "make xen.config" Enable additional options for xen dom0 guest kernel
+ support.
"make tinyconfig" Configure the tiniest possible kernel.
--
2.30.0
Re: kprobes broken since 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()")
On Fri, 29 Jan 2021 13:05:33 -0800
Alexei Starovoitov wrote:
> On Fri, Jan 29, 2021 at 02:01:03PM -0500, Steven Rostedt wrote:
> > On Fri, 29 Jan 2021 18:59:43 +0100
> > Peter Zijlstra wrote:
> >
> > > On Fri, Jan 29, 2021 at 09:45:48AM -0800, Alexei Starovoitov wrote:
> > > > Same things apply to bpf side. We can statically prove safety for
> > > > ftrace and kprobe attaching whereas to deal with NMI situation we
> > > > have to use run-time checks for recursion prevention, etc.
> > >
> > > I have no idea what you're saying. You can attach to functions that are
> > > called with random locks held, you can create kprobes in some very
> > > sensitive places.
> > >
> > > What can you staticlly prove about that?
> >
> > I think the main difference is, if you attach a kprobe or ftrace function,
> > you can theoretically analyze the location before you do the attachment.
>
> Excatly.
> When we're writing bpf helpers we need to carefully think about reentrance
> and NMI.
> If the helper looks like:
> int nokprobe notrace bpf_something(...)
> {
> // access variables A and B
> }
>
> The implementation can rely on the fact that even if the helper is reentrant
> the state of A and B will be consistent. Either both got touched or none.
> Only NMI condition we have to worry about, because A could be modified
> without touching B.
> If we write it as
> int nokprobe bpf_something(...) { ... }
> that would be another case.
> Here we need to consider the case that bpf prog can be attached to it via
> fentry nop.
> But no need to worry about instructions split in the middle because of kprobe
> via int3.
> Since we have big "if (in_nmi()) goto unsupported;" check in the beginning we
> only need to worry about combinations of kprobe at the start of the func,
> kprobe anywhere inside the func via int3, and ftrace at the start.
> Not having to think of NMI helps a ton.
> My earlier this_cpu vs __this_cpu comment is an example of that.
> If in_nmi is filtered early it's one implementation. If nmi has to be handled
> it's completely different algorithm.
> Now you've broke all this logic by making int3 to be marked as 'in_nmi' and
> bpf in kprobe in the middle of the func are now broken.
> Do people use that? Yeah they do.
> We have to fix it.
> What were your reasons to make int3 in_nmi?
> I've read the commit log, but I don't see in it the actual motivation
> for int3 other than "it looks like NMI to me. Let's make it so".
> The commit logs talk about cpu exceptions. I agree that #DB and #MC do behave
> like NMI.
> But #BP is not really. My understanding it's used by kprobes and text_poke_bp
> only.
> If the motivation was to close some issue with text_poke_bp then, sure,
> let's make handling of text_poke_bp to be treated as nmi.
> But kprobe is not that.
> I'm thinking either of the following solutions would be generic:
> - introduce another state to preempt flags like "kernel exception"
I like this solution. Or, at least there should be a way to provide the
probed context is NMI or not.
(BTW, would the NMI has a specific stack area? If so, nmi_context(regs)
can be implemented.)
> - remove kprobe's int3 from in_nmi
> As bpf specific alternative we can do:
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 6c0018abe68a..37cc549ad52e 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -96,7 +96,7 @@ unsigned int trace_call_bpf(struct trace_event_call *call,
> void *ctx)
> {
> unsigned int ret;
>
> - if (in_nmi()) /* not supported yet */
> + if (in_nmi() && !kprobe_running()) /* not supported yet */
This doesn't make sense, because kprobe_running() always true in the kprobe
handler.
The problem is that the in_nmi() checks whether the current context is NMI
context,
but you want to know the context where the kprobe is invoked, is NMI context or
not.
Thank you,
--
Masami Hiramatsu
Re: aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/ftrace.o' being placed in section `.eh_frame'
On Sat, Jan 30, 2021 at 09:21:49AM +0800, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: bec4c2968fce2f44ce62d05288a633cd99a722eb > commit: b3e5d80d0c48c0cc7bce56473672f4e6e1210910 arm64/build: Warn on orphan > section placement > date: 5 months ago > config: arm64-randconfig-r013-20210130 (attached as .config) > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project > 275c6af7d7f1ed63a03d05b4484413e447133269) > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # install arm64 cross compiling tool for clang build > # apt-get install binutils-aarch64-linux-gnu > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3e5d80d0c48c0cc7bce56473672f4e6e1210910 > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout b3e5d80d0c48c0cc7bce56473672f4e6e1210910 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All warnings (new ones prefixed by >>): > >aarch64-linux-gnu-ld: warning: -z norelro ignored >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/main.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/version.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/do_mounts.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/do_mounts_rd.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/do_mounts_initrd.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/initramfs.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/calibrate.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/init_task.o' being placed in section `.eh_frame' https://lore.kernel.org/lkml/20210130004650.2682422-1-nat...@kernel.org/ Cheers, Nathan
Re: [PATCH] ext4: Remove unreachable code
On Fri, Jan 29, 2021 at 06:58:56PM +, Vinicius Tinti wrote:
> By enabling -Wunreachable-code-aggressive on Clang the following code
> paths are unreachable.
>
> Commit dd73b5d5cb67 ("ext4: convert dx_probe() to use the ERR_PTR
> convention")
> Commit ac27a0ec112a ("[PATCH] ext4: initial copy of files from ext3")
>
> Clang warns:
>
> fs/ext4/namei.c:831:17: warning: code will never be executed
> [-Wunreachable-code]
> unsigned n = count - 1;
> ^
> fs/ext4/namei.c:830:7: note: silence by adding parentheses to mark code as
> explicitly dead
> if (0) { // linear search cross check
> ^
> /* DISABLES CODE */ ( )
The commit message might be a little clearer if it were restructured a
bit, maybe something like so?
By enabling -Wunreachable-code-aggressive on Clang, the following code
paths are unreachable:
fs/ext4/namei.c:831:17: warning: code will never be executed
[-Wunreachable-code]
unsigned n = count - 1;
^
fs/ext4/namei.c:830:7: note: silence by adding parentheses to mark code as
explicitly dead
if (0) { // linear search cross check
^
/* DISABLES CODE */ ( )
This has been present since commit ac27a0ec112a ("[PATCH] ext4: initial
copy of files from ext3") and fs/ext3 had it present at the beginning of
git history so it is safe to remove.
> Signed-off-by: Vinicius Tinti
Regardless of the commit message, I believe this is the right way to get
rid of the warning:
Reviewed-by: Nathan Chancellor
> ---
> fs/ext4/namei.c | 15 ---
> 1 file changed, 15 deletions(-)
>
> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
> index cf652ba3e74d..1f64dbd7237b 100644
> --- a/fs/ext4/namei.c
> +++ b/fs/ext4/namei.c
> @@ -827,21 +827,6 @@ dx_probe(struct ext4_filename *fname, struct inode *dir,
> p = m + 1;
> }
>
> - if (0) { // linear search cross check
> - unsigned n = count - 1;
> - at = entries;
> - while (n--)
> - {
> - dxtrace(printk(KERN_CONT ","));
> - if (dx_get_hash(++at) > hash)
> - {
> - at--;
> - break;
> - }
> - }
> - ASSERT(at == p - 1);
> - }
> -
> at = p - 1;
> dxtrace(printk(KERN_CONT " %x->%u\n",
> at == entries ? 0 : dx_get_hash(at),
> --
> 2.25.1
>
Re: [PATCH v3 2/3] perf/smmuv3: Add a MODULE_SOFTDEP() to indicate dependency on SMMU
On 2021/1/30 1:03, Robin Murphy wrote: > On 2021-01-29 15:34, John Garry wrote: >> On 29/01/2021 15:12, Robin Murphy wrote: >>> On 2021-01-27 11:32, Zhen Lei wrote: The MODULE_SOFTDEP() gives user space a hint of the loading sequence. And when command "modprobe arm_smmuv3_pmu" is executed, the arm_smmu_v3.ko is automatically loaded in advance. >>> >>> Why do we need this? If probe order doesn't matter when both drivers are >>> built-in, why should module load order? >>> >>> TBH I'm not sure why we even have a Kconfig dependency on ARM_SMMU_V3, >>> given that the drivers operate completely independently :/ >> >> Can that Kconfig dependency just be removed? I think that it was added under >> the idea that there is no point in having the SMMUv3 PMU driver without the >> SMMUv3 driver. > > A PMCG *might* be usable for simply counting transactions to measure device > activity regardless of its associated SMMU being enabled. If that's the case, the SOFTDEP really shouldn't be added. I wasn't trying to make sure they were loaded in order, just to make sure that the SMMU was not forgotten to load. > Either way, it's not really Kconfig's job to decide what makes sense (beyond > the top-level "can this driver *ever* be used on this platform" visibility > choices). Imagine if we gave every PCI/USB/etc. device driver an explicit > ?dependency on at least one host controller driver being enabled... > > Robin. > > . >
mipsel-linux-ld: decompress.c:undefined reference to `__ubsan_handle_out_of_bounds'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0e9bcda5d286f4a26a5407bb38f55c55b453ecfb commit: d0a3ac549f389c1511a4df0d7638536305205d20 ubsan: enable for all*config builds date: 6 weeks ago config: mips-randconfig-r025-20210130 (attached as .config) compiler: mipsel-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d0a3ac549f389c1511a4df0d7638536305205d20 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout d0a3ac549f389c1511a4df0d7638536305205d20 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `get_bits': decompress.c:(.text+0x288): undefined reference to `__ubsan_handle_shift_out_of_bounds' mipsel-linux-ld: decompress.c:(.text+0x2a0): undefined reference to `__ubsan_handle_shift_out_of_bounds' mipsel-linux-ld: decompress.c:(.text+0x2bc): undefined reference to `__ubsan_handle_shift_out_of_bounds' mipsel-linux-ld: decompress.c:(.text+0x2dc): undefined reference to `__ubsan_handle_shift_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `get_next_block': decompress.c:(.text+0xdb8): undefined reference to `__ubsan_handle_out_of_bounds' >> mipsel-linux-ld: decompress.c:(.text+0xdd4): undefined reference to >> `__ubsan_handle_out_of_bounds' mipsel-linux-ld: decompress.c:(.text+0xde8): undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: decompress.c:(.text+0xe3c): undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: decompress.c:(.text+0xe4c): undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/decompress.o:decompress.c:(.text+0xe64): more undefined references to `__ubsan_handle_out_of_bounds' follow mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `get_next_block': decompress.c:(.text+0x1000): undefined reference to `__ubsan_handle_shift_out_of_bounds' mipsel-linux-ld: decompress.c:(.text+0x1020): undefined reference to `__ubsan_handle_shift_out_of_bounds' mipsel-linux-ld: decompress.c:(.text+0x1044): undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: decompress.c:(.text+0x1074): undefined reference to `__ubsan_handle_shift_out_of_bounds' mipsel-linux-ld: decompress.c:(.text+0x1098): undefined reference to `__ubsan_handle_shift_out_of_bounds' mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `decompress_kernel': decompress.c:(.text+0x14c4): undefined reference to `__ubsan_handle_out_of_bounds' mipsel-linux-ld: decompress.c:(.text+0x14ec): undefined reference to `__ubsan_handle_out_of_bounds' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH v7 0/2] Kbuild: DWARF v5 support
DWARF v5 is the latest standard of the DWARF debug info format. DWARF5 wins significantly in terms of size and especially so when mixed with compression (CONFIG_DEBUG_INFO_COMPRESSED). Link: http://www.dwarfstd.org/doc/DWARF5.pdf Patch 1 is a cleanup that lays the ground work and isn't DWARF v5 specific. Patch 2 implements Kconfig and Kbuild support for DWARFv5. Changes from v6: * Reorder sections from linker script to match order from BFD's internal linker script. * Add .debug_names section, as per Fangrui. * Drop CONFIG_DEBUG_INFO_DWARF2. Patch 0001 becomes a menu with 1 choice. GCC's implicit default version of DWARF has been DWARF v4 since ~4.8. * Modify the test script to check for the presence of https://sourceware.org/bugzilla/show_bug.cgi?id=27195. * Drop the clang without integrated assembler block in 0002. Bumps the version requirement for GAS to 2.35.2, which isn't released yet (but should be released soon). Folks looking to test with clang but without the integrated assembler should fetch binutils-gdb, build it from source, add a symlink to binutils-gdb/gas/as-new to binutils-gdb/gas/as, then prefix binutils-gdb/gas/as to their $PATH when building the kernel. Changes from v5: * Drop previous patch 1, it has been accepted into kbuild: https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild=3f4d8ce271c7082be75bacbcbd2048aa78ce2b44 * Trying to set -Wa,-gdwarf-4 in the earlier patch was the source of additional complexity. Drop it that part of the patch. We can revisit clang without the integrated assembler setting -Wa,-gdwarf-4 later. That is a separate problem from generally supporting DWARF v5. * Rework the final patch for clang without the integrated assembler. -Wa,-gdwarf-5 is required for DWARF5 in that case otherwise GAS will not accept the assembler directives clang produces from C code when generating asm. Changes from v4: * drop set -e from script as per Nathan. * add dependency on !CONFIG_DEBUG_INFO_BTF for DWARF v5 as per Sedat. * Move LLVM_IAS=1 complexity from patch 2 to patch 3 as per Arvind and Masahiro. Sorry it took me a few tries to understand the point (I might still not), but it looks much cleaner this way. Sorry Nathan, I did not carry forward your previous reviews as a result, but I would appreciate if you could look again. * Add Nathan's reviewed by tag to patch 1. * Reword commit message for patch 3 to mention LLVM_IAS=1 and -gdwarf-5 binutils addition later, and BTF issue. * I still happen to see a pahole related error spew for the combination of: * LLVM=1 * LLVM_IAS=1 * CONFIG_DEBUG_INFO_DWARF4 * CONFIG_DEBUG_INFO_BTF Though they're non-fatal to the build. I'm not sure yet why removing any one of the above prevents the warning spew. Maybe we'll need a v6. Changes from v3: Changes as per Arvind: * only add -Wa,-gdwarf-5 for (LLVM=1|CC=clang)+LLVM_IAS=0 builds. * add -gdwarf-5 to Kconfig shell script. * only run Kconfig shell script for Clang. Apologies to Sedat and Nathan; I appreciate previous testing/review, but I did no carry forward your Tested-by and Reviewed-by tags, as the patches have changed too much IMO. Changes from v2: * Drop two of the earlier patches that have been accepted already. * Add measurements with GCC 10.2 to commit message. * Update help text as per Arvind with help from Caroline. * Improve case/wording between DWARF Versions as per Masahiro. Changes from the RFC: * split patch in 3 patch series, include Fangrui's patch, too. * prefer `DWARF vX` format, as per Fangrui. * use spaces between assignment in Makefile as per Masahiro. * simplify setting dwarf-version-y as per Masahiro. * indent `prompt` in Kconfig change as per Masahiro. * remove explicit default in Kconfig as per Masahiro. * add comments to test_dwarf5_support.sh. * change echo in test_dwarf5_support.sh as per Masahiro. * remove -u from test_dwarf5_support.sh as per Masahiro. * add a -gdwarf-5 cc-option check to Kconfig as per Jakub. Nick Desaulniers (2): Kbuild: make DWARF version a choice Kbuild: implement support for DWARF v5 Makefile | 6 +++--- include/asm-generic/vmlinux.lds.h | 7 +- lib/Kconfig.debug | 36 +-- scripts/test_dwarf5_support.sh| 8 +++ 4 files changed, 47 insertions(+), 10 deletions(-) create mode 100755 scripts/test_dwarf5_support.sh -- 2.30.0.365.g02bc693789-goog
Re: [PATCH v6 0/2] Kbuild: DWARF v5 support
On Fri, Jan 29, 2021 at 4:46 PM 'Nick Desaulniers' via Clang Built Linux wrote: > > On Fri, Jan 29, 2021 at 4:08 PM Sedat Dilek wrote: > > > > On Fri, Jan 29, 2021 at 8:43 PM Nick Desaulniers > > wrote: > > > > > > DWARF v5 is the latest standard of the DWARF debug info format. > > > > > > DWARF5 wins significantly in terms of size and especially so when mixed > > > with compression (CONFIG_DEBUG_INFO_COMPRESSED). > > > > > > Link: http://www.dwarfstd.org/doc/DWARF5.pdf > > > > > > Patch 1 is a cleanup that lays the ground work and isn't DWARF > > > v5 specific. > > > Patch 2 implements Kconfig and Kbuild support for DWARFv5. > > > > > > > When you will do a v7... > > > > Can you look also at places where we have hardcoded DWARF-2 handling... > > Ah, sorry, I just saw this now, after sending v7. Can we wait to > purge DWARF v2 until after we have DWARF v5? > > In fact, if they are orthogonal like I suspect, why don't you send > some patches and I will help you test them? > -- > Thanks, > ~Nick Desaulniers Basically the distinction is just between DWARF v2 .debug_line and DWARF v5 .debug_line . (-gdwarf-4 adds an extra maximum_operations_per_instruction (constant 1) compared with -gdwarf-2 but that can mostly be ignored). Refinement among -gdwarf-[234] just clarifies things and is not going to affect debugging experience in any case. So I agree with Nick that it can be done separately. Note: such clarification can make things a bit ugly because binutils before 2020 does not recognize -gdwarf-[345]. -- 宋方睿
[RESEND PATCH] spmi: spmi-pmic-arb: Fix hw_irq overflow
Currently, when handling the SPMI summary interrupt, the hw_irq
number is calculated based on SID, Peripheral ID, IRQ index and
APID. This is then passed to irq_find_mapping() to see if a
mapping exists for this hw_irq and if available, invoke the
interrupt handler. Since the IRQ index uses an "int" type, hw_irq
which is of unsigned long data type can take a large value when
SID has its MSB set to 1 and the type conversion happens. Because
of this, irq_find_mapping() returns 0 as there is no mapping
for this hw_irq. This ends up invoking cleanup_irq() as if
the interrupt is spurious whereas it is actually a valid
interrupt. Fix this by using the proper data type (u32) for id.
Cc: sta...@vger.kernel.org
Signed-off-by: Subbaraman Narayanamurthy
---
drivers/spmi/spmi-pmic-arb.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
index de844b4..bbbd311 100644
--- a/drivers/spmi/spmi-pmic-arb.c
+++ b/drivers/spmi/spmi-pmic-arb.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Copyright (c) 2012-2015, 2017, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2012-2015, 2017, 2021, The Linux Foundation. All rights
reserved.
*/
#include
#include
@@ -505,8 +505,7 @@ static void cleanup_irq(struct spmi_pmic_arb *pmic_arb, u16
apid, int id)
static void periph_interrupt(struct spmi_pmic_arb *pmic_arb, u16 apid)
{
unsigned int irq;
- u32 status;
- int id;
+ u32 status, id;
u8 sid = (pmic_arb->apid_data[apid].ppid >> 8) & 0xF;
u8 per = pmic_arb->apid_data[apid].ppid & 0xFF;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v3] vmlinux.lds.h: Define SANTIZER_DISCARDS with CONFIG_GCOV_KERNEL=y
clang produces .eh_frame sections when CONFIG_GCOV_KERNEL is enabled,
even when -fno-asynchronous-unwind-tables is in KBUILD_CFLAGS:
$ make CC=clang vmlinux
...
ld: warning: orphan section `.eh_frame' from `init/main.o' being placed in
section `.eh_frame'
ld: warning: orphan section `.eh_frame' from `init/version.o' being placed in
section `.eh_frame'
ld: warning: orphan section `.eh_frame' from `init/do_mounts.o' being placed in
section `.eh_frame'
ld: warning: orphan section `.eh_frame' from `init/do_mounts_initrd.o' being
placed in section `.eh_frame'
ld: warning: orphan section `.eh_frame' from `init/initramfs.o' being placed in
section `.eh_frame'
ld: warning: orphan section `.eh_frame' from `init/calibrate.o' being placed in
section `.eh_frame'
ld: warning: orphan section `.eh_frame' from `init/init_task.o' being placed in
section `.eh_frame'
...
$ rg "GCOV_KERNEL|GCOV_PROFILE_ALL" .config
CONFIG_GCOV_KERNEL=y
CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
CONFIG_GCOV_PROFILE_ALL=y
This was already handled for a couple of other options in
commit d812db78288d ("vmlinux.lds.h: Avoid KASAN and KCSAN's unwanted
sections") and there is an open LLVM bug for this issue. Take advantage
of that section for this config as well so that there are no more orphan
warnings.
Link: https://bugs.llvm.org/show_bug.cgi?id=46478
Link: https://github.com/ClangBuiltLinux/linux/issues/1069
Reported-by: kernel test robot
Reviewed-by: Fangrui Song
Reviewed-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
v2 -> v3:
* Fix double "unwanted" in comment section per Sedat.
v1 -> v2:
* Keep configs and flag names alphabetized.
* Drop mention of -ftest-coverage since it does not cause this issue per
Fangrui.
* Pick up review tags from Fangrui and Nick.
include/asm-generic/vmlinux.lds.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index b2b3d81b1535..b61b537177fb 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -988,12 +988,13 @@
#endif
/*
- * Clang's -fsanitize=kernel-address and -fsanitize=thread produce
- * unwanted sections (.eh_frame and .init_array.*), but
- * CONFIG_CONSTRUCTORS wants to keep any .init_array.* sections.
+ * Clang's -fprofile-arcs, -fsanitize=kernel-address, and
+ * -fsanitize=thread produce unwanted sections (.eh_frame
+ * and .init_array.*), but CONFIG_CONSTRUCTORS wants to
+ * keep any .init_array.* sections.
* https://bugs.llvm.org/show_bug.cgi?id=46478
*/
-#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN)
+#if defined(CONFIG_GCOV_KERNEL) || defined(CONFIG_KASAN_GENERIC) ||
defined(CONFIG_KCSAN)
# ifdef CONFIG_CONSTRUCTORS
# define SANITIZER_DISCARDS \
*(.eh_frame)
base-commit: bec4c2968fce2f44ce62d05288a633cd99a722eb
--
2.30.0
[PATCH v7 1/2] Kbuild: make DWARF version a choice
Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice which is the default. Does so in a way that's forward compatible with existing configs, and makes adding future versions more straightforward. GCC since ~4.8 has defaulted to this DWARF version implicitly. Suggested-by: Arvind Sankar Suggested-by: Fangrui Song Suggested-by: Nathan Chancellor Suggested-by: Masahiro Yamada Signed-off-by: Nick Desaulniers --- Makefile | 5 ++--- lib/Kconfig.debug | 16 +++- 2 files changed, 13 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 95ab9856f357..d2b4980807e0 100644 --- a/Makefile +++ b/Makefile @@ -830,9 +830,8 @@ ifneq ($(LLVM_IAS),1) KBUILD_AFLAGS += -Wa,-gdwarf-2 endif -ifdef CONFIG_DEBUG_INFO_DWARF4 -DEBUG_CFLAGS += -gdwarf-4 -endif +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4 +DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y) ifdef CONFIG_DEBUG_INFO_REDUCED DEBUG_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly) \ diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index e906ea906cb7..94c1a7ed6306 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -256,13 +256,19 @@ config DEBUG_INFO_SPLIT to know about the .dwo files and include them. Incompatible with older versions of ccache. +choice + prompt "DWARF version" + help + Which version of DWARF debug info to emit. + config DEBUG_INFO_DWARF4 - bool "Generate dwarf4 debuginfo" + bool "Generate DWARF Version 4 debuginfo" help - Generate dwarf4 debug info. This requires recent versions - of gcc and gdb. It makes the debug information larger. - But it significantly improves the success of resolving - variables in gdb on optimized code. + Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+. + It makes the debug information larger, but it significantly + improves the success of resolving variables in gdb on optimized code. + +endchoice # "DWARF version" config DEBUG_INFO_BTF bool "Generate BTF typeinfo" -- 2.30.0.365.g02bc693789-goog
[GIT PULL] Btrfs fixes for 5.11-rc6
Hi, I'm not sure the first post of this pull request made it through so sending again. A few more fixes for a late rc: - fix lockdep complaint on 32bit arches and also remove an unsafe memory use due to device vs filesystem lifetime - two fixes for free space tree - race during log replay and cache rebuild, now more likely to happen due to changes in this dev cycle - possible free space tree corruption with online conversion during initial tree population Please pull, thanks. The following changes since commit 34d1eb0e599875064955a74712f08ff14c8e3d5f: btrfs: don't clear ret in btrfs_start_dirty_block_groups (2021-01-18 16:00:11 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.11-rc5-tag for you to fetch changes up to 9ad6d91f056b99dbe59a262810cb342519ea8d39: btrfs: fix log replay failure due to race with space cache rebuild (2021-01-25 18:44:53 +0100) Filipe Manana (1): btrfs: fix log replay failure due to race with space cache rebuild Josef Bacik (1): btrfs: fix possible free space tree corruption with online conversion Su Yue (1): btrfs: fix lockdep warning due to seqcount_mutex on 32bit arch fs/btrfs/block-group.c | 10 +++- fs/btrfs/ctree.h | 3 +++ fs/btrfs/extent-tree.c | 61 ++ fs/btrfs/free-space-tree.c | 10 +++- fs/btrfs/volumes.c | 2 +- fs/btrfs/volumes.h | 11 + 6 files changed, 46 insertions(+), 51 deletions(-)
Re: [PATCH V5 3/5] gpio: gpio-xilinx: Add interrupt support
Noticed one issue, see below:
On Fri, 2021-01-29 at 19:56 +0530, Srinivas Neeli wrote:
> Adds interrupt support to the Xilinx GPIO driver so that rising and
> falling edge line events can be supported. Since interrupt support is
> an optional feature in the Xilinx IP, the driver continues to support
> devices which have no interrupt provided.
> Depends on OF_GPIO framework for of_xlate function to translate
> gpiospec to the GPIO number and flags.
>
> Signed-off-by: Robert Hancock
> Signed-off-by: Shubhrajyoti Datta
> Signed-off-by: Srinivas Neeli
> ---
> Changes in V5:
> -Removed IRQ_DOMAIN_HIERARCHY from Kconfig and
> #include from includes.
> -Fixed "detected irqchip that is shared with multiple
> gpiochips: please fix the driver"error message.
> -Added check for #gpio-cells and error message in failure case.
> Changes in V4:
> -Added more commit description.
> Changes in V3:
> -Created separate patch for Clock changes and runtime resume
> and suspend.
> -Updated minor review comments.
>
> Changes in V2:
> -Added check for return value of platform_get_irq() API.
> -Updated code to support rising edge and falling edge.
> -Added xgpio_xlate() API to support switch.
> -Added MAINTAINERS fragment.
> ---
> drivers/gpio/Kconfig | 2 +
> drivers/gpio/gpio-xilinx.c | 246
> -
> 2 files changed, 244 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index c70f46e80a3b..2ee57797d908 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -690,6 +690,8 @@ config GPIO_XGENE_SB
>
> config GPIO_XILINX
> tristate "Xilinx GPIO support"
> + select GPIOLIB_IRQCHIP
> + depends on OF_GPIO
> help
> Say yes here to support the Xilinx FPGA GPIO device
>
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index f88db56543c2..62deb755f910 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -10,7 +10,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -22,6 +24,11 @@
>
> #define XGPIO_CHANNEL_OFFSET 0x8
>
> +#define XGPIO_GIER_OFFSET0x11c /* Global Interrupt Enable */
> +#define XGPIO_GIER_IEBIT(31)
> +#define XGPIO_IPISR_OFFSET 0x120 /* IP Interrupt Status */
> +#define XGPIO_IPIER_OFFSET 0x128 /* IP Interrupt Enable */
> +
> /* Read/Write access to the GPIO registers */
> #if defined(CONFIG_ARCH_ZYNQ) || defined(CONFIG_X86)
> # define xgpio_readreg(offset) readl(offset)
> @@ -36,9 +43,15 @@
> * @gc: GPIO chip
> * @regs: register block
> * @gpio_width: GPIO width for every channel
> - * @gpio_state: GPIO state shadow register
> + * @gpio_state: GPIO write state shadow register
> + * @gpio_last_irq_read: GPIO read state register from last interrupt
> * @gpio_dir: GPIO direction shadow register
> * @gpio_lock: Lock used for synchronization
> + * @irq: IRQ used by GPIO device
> + * @irqchip: IRQ chip
> + * @irq_enable: GPIO IRQ enable/disable bitfield
> + * @irq_rising_edge: GPIO IRQ rising edge enable/disable bitfield
> + * @irq_falling_edge: GPIO IRQ falling edge enable/disable bitfield
> * @clk: clock resource for this driver
> */
> struct xgpio_instance {
> @@ -46,8 +59,14 @@ struct xgpio_instance {
> void __iomem *regs;
> unsigned int gpio_width[2];
> u32 gpio_state[2];
> + u32 gpio_last_irq_read[2];
> u32 gpio_dir[2];
> spinlock_t gpio_lock; /* For serializing operations */
> + int irq;
> + struct irq_chip irqchip;
> + u32 irq_enable[2];
> + u32 irq_rising_edge[2];
> + u32 irq_falling_edge[2];
> struct clk *clk;
> };
>
> @@ -277,6 +296,175 @@ static int xgpio_remove(struct platform_device *pdev)
> }
>
> /**
> + * xgpio_irq_ack - Acknowledge a child GPIO interrupt.
> + * @irq_data: per IRQ and chip data passed down to chip functions
> + * This currently does nothing, but irq_ack is unconditionally called by
> + * handle_edge_irq and therefore must be defined.
> + */
> +static void xgpio_irq_ack(struct irq_data *irq_data)
> +{
> +}
> +
> +/**
> + * xgpio_irq_mask - Write the specified signal of the GPIO device.
> + * @irq_data: per IRQ and chip data passed down to chip functions
> + */
> +static void xgpio_irq_mask(struct irq_data *irq_data)
> +{
> + unsigned long flags;
> + struct xgpio_instance *chip = irq_data_get_irq_chip_data(irq_data);
> + int irq_offset = irqd_to_hwirq(irq_data);
> + int index = xgpio_index(chip, irq_offset);
> + int offset = xgpio_offset(chip, irq_offset);
> +
> + spin_lock_irqsave(>gpio_lock, flags);
> +
> + chip->irq_enable[index] &= ~BIT(offset);
> +
> + if (!chip->irq_enable[index]) {
> + /* Disable per channel interrupt */
> + u32 temp = xgpio_readreg(chip->regs + XGPIO_IPIER_OFFSET);
> +
> + temp &= ~BIT(index);
> +
[PATCH 3/3] IMA: add support to measure duplicate buffer for critical data hook
process_buffer_measurement() and the underlying functions do not use the
policy condition to measure duplicate buffer entries for integrity
critical data.
Update process_buffer_measurement(), ima_add_template_entry(), and
ima_store_template() to use the policy condition to decide if a
duplicate buffer entry for integrity critical data should be measured.
Signed-off-by: Tushar Sugandhi
---
security/integrity/ima/ima.h | 4 ++--
security/integrity/ima/ima_api.c | 9 +
security/integrity/ima/ima_init.c | 2 +-
security/integrity/ima/ima_main.c | 5 +++--
security/integrity/ima/ima_queue.c | 5 +++--
5 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 59324173497f..b06732560949 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -139,7 +139,7 @@ int ima_init(void);
int ima_fs_init(void);
int ima_add_template_entry(struct ima_template_entry *entry, int violation,
const char *op, struct inode *inode,
- const unsigned char *filename);
+ const unsigned char *filename, bool allow_dup);
int ima_calc_file_hash(struct file *file, struct ima_digest_data *hash);
int ima_calc_buffer_hash(const void *buf, loff_t len,
struct ima_digest_data *hash);
@@ -278,7 +278,7 @@ int ima_alloc_init_template(struct ima_event_data
*event_data,
struct ima_template_desc *template_desc);
int ima_store_template(struct ima_template_entry *entry, int violation,
struct inode *inode,
- const unsigned char *filename, int pcr);
+ const unsigned char *filename, int pcr, bool allow_dup);
void ima_free_template_entry(struct ima_template_entry *entry);
const char *ima_d_path(const struct path *path, char **pathbuf, char
*filename);
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index d273373e6be9..f84369f9905e 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -101,7 +101,7 @@ int ima_alloc_init_template(struct ima_event_data
*event_data,
*/
int ima_store_template(struct ima_template_entry *entry,
int violation, struct inode *inode,
- const unsigned char *filename, int pcr)
+ const unsigned char *filename, int pcr, bool allow_dup)
{
static const char op[] = "add_template_measure";
static const char audit_cause[] = "hashing_error";
@@ -119,7 +119,8 @@ int ima_store_template(struct ima_template_entry *entry,
}
}
entry->pcr = pcr;
- result = ima_add_template_entry(entry, violation, op, inode, filename);
+ result = ima_add_template_entry(entry, violation, op, inode, filename,
+ allow_dup);
return result;
}
@@ -152,7 +153,7 @@ void ima_add_violation(struct file *file, const unsigned
char *filename,
goto err_out;
}
result = ima_store_template(entry, violation, inode,
- filename, CONFIG_IMA_MEASURE_PCR_IDX);
+ filename, CONFIG_IMA_MEASURE_PCR_IDX,
false);
if (result < 0)
ima_free_template_entry(entry);
err_out:
@@ -330,7 +331,7 @@ void ima_store_measurement(struct integrity_iint_cache
*iint,
return;
}
- result = ima_store_template(entry, violation, inode, filename, pcr);
+ result = ima_store_template(entry, violation, inode, filename, pcr,
false);
if ((!result || result == -EEXIST) && !(file->f_flags & O_DIRECT)) {
iint->flags |= IMA_MEASURED;
iint->measured_pcrs |= (0x1 << pcr);
diff --git a/security/integrity/ima/ima_init.c
b/security/integrity/ima/ima_init.c
index 6e8742916d1d..d0a79d7b8d89 100644
--- a/security/integrity/ima/ima_init.c
+++ b/security/integrity/ima/ima_init.c
@@ -88,7 +88,7 @@ static int __init ima_add_boot_aggregate(void)
result = ima_store_template(entry, violation, NULL,
boot_aggregate_name,
- CONFIG_IMA_MEASURE_PCR_IDX);
+ CONFIG_IMA_MEASURE_PCR_IDX, false);
if (result < 0) {
ima_free_template_entry(entry);
audit_cause = "store_entry";
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index 2774139845b6..ff6d15d7594c 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -843,6 +843,7 @@ void process_buffer_measurement(struct inode *inode, const
void *buf, int size,
int digest_hash_len = hash_digest_size[ima_hash_algo];
int violation = 0;
int action = 0;
+ bool allow_dup = false;
u32 secid;
[PATCH 2/3] IMA: update functions to read allow_dup policy condition
IMA functions ima_get_action() and ima_match_policy() do not consume the
policy condition to allow measuring duplicate entries for integrity
critical data.
Update ima_get_action() and ima_match_policy() to consume the IMA policy
condition to measure duplicate buffer entries for integrity critical
data.
Signed-off-by: Tushar Sugandhi
---
security/integrity/ima/ima.h | 4 ++--
security/integrity/ima/ima_api.c | 6 --
security/integrity/ima/ima_appraise.c | 2 +-
security/integrity/ima/ima_main.c | 6 +++---
security/integrity/ima/ima_policy.c | 7 ++-
5 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index aa312472c7c5..59324173497f 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -257,7 +257,7 @@ static inline void ima_process_queued_keys(void) {}
int ima_get_action(struct inode *inode, const struct cred *cred, u32 secid,
int mask, enum ima_hooks func, int *pcr,
struct ima_template_desc **template_desc,
- const char *func_data);
+ const char *func_data, bool *allow_dup);
int ima_must_measure(struct inode *inode, int mask, enum ima_hooks func);
int ima_collect_measurement(struct integrity_iint_cache *iint,
struct file *file, void *buf, loff_t size,
@@ -286,7 +286,7 @@ const char *ima_d_path(const struct path *path, char
**pathbuf, char *filename);
int ima_match_policy(struct inode *inode, const struct cred *cred, u32 secid,
enum ima_hooks func, int mask, int flags, int *pcr,
struct ima_template_desc **template_desc,
-const char *func_data);
+const char *func_data, bool *allow_dup);
void ima_init_policy(void);
void ima_update_policy(void);
void ima_update_policy_flag(void);
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index 1dd70dc68ffd..d273373e6be9 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -171,6 +171,8 @@ void ima_add_violation(struct file *file, const unsigned
char *filename,
* @pcr: pointer filled in if matched measure policy sets pcr=
* @template_desc: pointer filled in if matched measure policy sets template=
* @func_data: func specific data, may be NULL
+ * @allow_dup: pointer filled in to decide if a duplicate buffer entry
+ * should be measured
*
* The policy is defined in terms of keypairs:
* subj=, obj=, type=, func=, mask=, fsmagic=
@@ -186,14 +188,14 @@ void ima_add_violation(struct file *file, const unsigned
char *filename,
int ima_get_action(struct inode *inode, const struct cred *cred, u32 secid,
int mask, enum ima_hooks func, int *pcr,
struct ima_template_desc **template_desc,
- const char *func_data)
+ const char *func_data, bool *allow_dup)
{
int flags = IMA_MEASURE | IMA_AUDIT | IMA_APPRAISE | IMA_HASH;
flags &= ima_policy_flag;
return ima_match_policy(inode, cred, secid, func, mask, flags, pcr,
- template_desc, func_data);
+ template_desc, func_data, allow_dup);
}
/*
diff --git a/security/integrity/ima/ima_appraise.c
b/security/integrity/ima/ima_appraise.c
index 46ffa38bab12..e317a7698a47 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -77,7 +77,7 @@ int ima_must_appraise(struct inode *inode, int mask, enum
ima_hooks func)
security_task_getsecid(current, );
return ima_match_policy(inode, current_cred(), secid, func, mask,
- IMA_APPRAISE | IMA_HASH, NULL, NULL, NULL);
+ IMA_APPRAISE | IMA_HASH, NULL, NULL, NULL,
NULL);
}
static int ima_fix_xattr(struct dentry *dentry,
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index 6a429846f90a..2774139845b6 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -219,7 +219,7 @@ static int process_measurement(struct file *file, const
struct cred *cred,
* Included is the appraise submask.
*/
action = ima_get_action(inode, cred, secid, mask, func, ,
- _desc, NULL);
+ _desc, NULL, NULL);
violation_check = ((func == FILE_CHECK || func == MMAP_CHECK) &&
(ima_policy_flag & IMA_MEASURE));
if (!action && !violation_check)
@@ -432,7 +432,7 @@ int ima_file_mprotect(struct vm_area_struct *vma, unsigned
long prot)
security_task_getsecid(current, );
inode = file_inode(vma->vm_file);
action = ima_get_action(inode, current_cred(), secid, MAY_EXEC,
- MMAP_CHECK, , , 0);
+
Re: [PATCH v6 0/2] Kbuild: DWARF v5 support
On Fri, Jan 29, 2021 at 4:08 PM Sedat Dilek wrote: > > On Fri, Jan 29, 2021 at 8:43 PM Nick Desaulniers > wrote: > > > > DWARF v5 is the latest standard of the DWARF debug info format. > > > > DWARF5 wins significantly in terms of size and especially so when mixed > > with compression (CONFIG_DEBUG_INFO_COMPRESSED). > > > > Link: http://www.dwarfstd.org/doc/DWARF5.pdf > > > > Patch 1 is a cleanup that lays the ground work and isn't DWARF > > v5 specific. > > Patch 2 implements Kconfig and Kbuild support for DWARFv5. > > > > When you will do a v7... > > Can you look also at places where we have hardcoded DWARF-2 handling... Ah, sorry, I just saw this now, after sending v7. Can we wait to purge DWARF v2 until after we have DWARF v5? In fact, if they are orthogonal like I suspect, why don't you send some patches and I will help you test them? -- Thanks, ~Nick Desaulniers
Re: [PATCH 05/14] cxl/mem: Register CXL memX devices
On Fri, Jan 29, 2021 at 4:25 PM Ben Widawsky wrote:
>
> From: Dan Williams
>
> Create the /sys/bus/cxl hierarchy to enumerate:
>
> * Memory Devices (per-endpoint control devices)
>
> * Memory Address Space Devices (platform address ranges with
> interleaving, performance, and persistence attributes)
>
> * Memory Regions (active provisioned memory from an address space device
> that is in use as System RAM or delegated to libnvdimm as Persistent
> Memory regions).
>
> For now, only the per-endpoint control devices are registered on the
> 'cxl' bus. However, going forward it will provide a mechanism to
> coordinate cross-device interleave.
>
> Signed-off-by: Dan Williams
> Signed-off-by: Ben Widawsky
> ---
> Documentation/ABI/testing/sysfs-bus-cxl | 26 ++
> .../driver-api/cxl/memory-devices.rst | 17 +
> drivers/base/core.c | 14 +
> drivers/cxl/Makefile | 3 +
> drivers/cxl/bus.c | 29 ++
> drivers/cxl/cxl.h | 4 +
> drivers/cxl/mem.c | 308 +-
> include/linux/device.h| 1 +
> 8 files changed, 400 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-cxl
> create mode 100644 drivers/cxl/bus.c
[..]
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 25e08e5f40bd..33432a4cbe23 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -3179,6 +3179,20 @@ struct device *get_device(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(get_device);
>
> +/**
> + * get_live_device() - increment reference count for device iff !dead
> + * @dev: device.
> + *
> + * Forward the call to get_device() if the device is still alive. If
> + * this is called with the device_lock() held then the device is
> + * guaranteed to not die until the device_lock() is dropped.
> + */
> +struct device *get_live_device(struct device *dev)
> +{
> + return dev && !dev->p->dead ? get_device(dev) : NULL;
> +}
> +EXPORT_SYMBOL_GPL(get_live_device);
Disregard this hunk, it's an abandoned idea that I failed to cleanup.
[PATCH 12/14] cxl/mem: Add set of informational commands
In order to solidify support for a reasonable set of commands a set of
relatively safe commands are added and thus nullifying the need to use
raw operations to access them.
Signed-off-by: Ben Widawsky
---
drivers/cxl/mem.c| 8
include/uapi/linux/cxl_mem.h | 4
2 files changed, 12 insertions(+)
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 787417c4d5dc..b8ca6dff37b5 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -42,12 +42,16 @@
enum opcode {
CXL_MBOX_OP_INVALID = 0x,
#define CXL_MBOX_OP_RAWCXL_MBOX_OP_INVALID
+ CXL_MBOX_OP_GET_FW_INFO = 0x0200,
CXL_MBOX_OP_ACTIVATE_FW = 0x0202,
CXL_MBOX_OP_GET_SUPPORTED_LOGS = 0x0400,
CXL_MBOX_OP_GET_LOG = 0x0401,
CXL_MBOX_OP_IDENTIFY= 0x4000,
+ CXL_MBOX_OP_GET_PARTITION_INFO = 0x4100,
CXL_MBOX_OP_SET_PARTITION_INFO = 0x4101,
+ CXL_MBOX_OP_GET_LSA = 0x4102,
CXL_MBOX_OP_SET_LSA = 0x4103,
+ CXL_MBOX_OP_GET_HEALTH_INFO = 0x4200,
CXL_MBOX_OP_SET_SHUTDOWN_STATE = 0x4204,
CXL_MBOX_OP_SCAN_MEDIA = 0x4304,
CXL_MBOX_OP_GET_SCAN_MEDIA = 0x4305,
@@ -168,6 +172,10 @@ static struct cxl_mem_command mem_commands[] = {
CXL_CMD(IDENTIFY, NONE, 0, 0x43, MANDATORY),
CXL_CMD(RAW, NONE, ~0, ~0, PSEUDO),
CXL_CMD(GET_SUPPORTED_LOGS, NONE, 0, ~0, MANDATORY),
+ CXL_CMD(GET_FW_INFO, NONE, 0, 0x50, NONE),
+ CXL_CMD(GET_PARTITION_INFO, NONE, 0, 0x20, NONE),
+ CXL_CMD(GET_LSA, NONE, 0x8, ~0, MANDATORY),
+ CXL_CMD(GET_HEALTH_INFO, NONE, 0, 0x12, MANDATORY),
};
/*
diff --git a/include/uapi/linux/cxl_mem.h b/include/uapi/linux/cxl_mem.h
index 64cb9753a077..766c231d6150 100644
--- a/include/uapi/linux/cxl_mem.h
+++ b/include/uapi/linux/cxl_mem.h
@@ -35,6 +35,10 @@ extern "C" {
___C(IDENTIFY, "Identify Command"), \
___C(RAW, "Raw device command"), \
___C(GET_SUPPORTED_LOGS, "Get Supported Logs"), \
+ ___C(GET_FW_INFO, "Get FW Info"), \
+ ___C(GET_PARTITION_INFO, "Get Partition Information"),\
+ ___C(GET_LSA, "Get Label Storage Area"), \
+ ___C(GET_HEALTH_INFO, "Get Health Info"), \
___C(MAX, "Last command")
#define ___C(a, b) CXL_MEM_COMMAND_ID_##a
--
2.30.0
[PATCH 11/14] cxl/mem: Use CEL for enabling commands
The Command Effects Log (CEL) is specified in the CXL 2.0 specification.
The CEL is one of two types of logs, the other being vendor specific.
They are distinguished in hardware/spec via UUID. The CEL is immediately
useful for 2 things:
1. Determine which optional commands are supported by the CXL device.
2. Enumerate any vendor specific commands
The CEL can be used by the driver to determine which commands are
available in the hardware (though it isn't, yet). That set of commands
might itself be a subset of commands which are available to be used via
CXL_MEM_SEND_COMMAND IOCTL.
Prior to this, all commands that the driver exposed were explicitly
enabled. After this, only those commands that are found in the CEL are
enabled.
Signed-off-by: Ben Widawsky
---
drivers/cxl/mem.c| 186 ++-
include/uapi/linux/cxl_mem.h | 1 +
2 files changed, 182 insertions(+), 5 deletions(-)
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index d01c6ee32a6b..787417c4d5dc 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -43,6 +43,8 @@ enum opcode {
CXL_MBOX_OP_INVALID = 0x,
#define CXL_MBOX_OP_RAWCXL_MBOX_OP_INVALID
CXL_MBOX_OP_ACTIVATE_FW = 0x0202,
+ CXL_MBOX_OP_GET_SUPPORTED_LOGS = 0x0400,
+ CXL_MBOX_OP_GET_LOG = 0x0401,
CXL_MBOX_OP_IDENTIFY= 0x4000,
CXL_MBOX_OP_SET_PARTITION_INFO = 0x4101,
CXL_MBOX_OP_SET_LSA = 0x4103,
@@ -101,6 +103,18 @@ static DEFINE_IDA(cxl_memdev_ida);
static struct dentry *cxl_debugfs;
static bool raw_allow_all;
+enum {
+ CEL_UUID,
+ DEBUG_UUID
+};
+
+static const uuid_t log_uuid[] = {
+ [CEL_UUID] = UUID_INIT(0xda9c0b5, 0xbf41, 0x4b78, 0x8f, 0x79, 0x96,
+ 0xb1, 0x62, 0x3b, 0x3f, 0x17),
+ [DEBUG_UUID] = UUID_INIT(0xe1819d9, 0x11a9, 0x400c, 0x81, 0x1f, 0xd6,
+0x07, 0x19, 0x40, 0x3d, 0x86)
+};
+
/**
* struct cxl_mem_command - Driver representation of a memory device command
* @info: Command information as it exists for the UAPI
@@ -153,6 +167,7 @@ static struct cxl_mem_command mem_commands[] = {
CXL_CMD(INVALID, KERNEL, 0, 0, HIDDEN),
CXL_CMD(IDENTIFY, NONE, 0, 0x43, MANDATORY),
CXL_CMD(RAW, NONE, ~0, ~0, PSEUDO),
+ CXL_CMD(GET_SUPPORTED_LOGS, NONE, 0, ~0, MANDATORY),
};
/*
@@ -1168,6 +1183,101 @@ static int cxl_mem_add_memdev(struct cxl_mem *cxlm)
return rc;
}
+struct cxl_mbox_get_supported_logs {
+ __le16 entries;
+ u8 rsvd[6];
+ struct gsl_entry {
+ uuid_t uuid;
+ __le32 size;
+ } __packed entry[2];
+} __packed;
+struct cxl_mbox_get_log {
+ uuid_t uuid;
+ __le32 offset;
+ __le32 length;
+} __packed;
+
+static int cxl_xfer_log(struct cxl_mem *cxlm, uuid_t *uuid, u32 size, u8 *out)
+{
+ u32 remaining = size;
+ u32 offset = 0;
+
+ while (remaining) {
+ u32 xfer_size = min_t(u32, remaining, cxlm->mbox.payload_size);
+ struct mbox_cmd mbox_cmd;
+ int rc;
+ struct cxl_mbox_get_log log = {
+ .uuid = *uuid,
+ .offset = cpu_to_le32(offset),
+ .length = cpu_to_le32(xfer_size)
+ };
+
+ mbox_cmd = (struct mbox_cmd) {
+ .opcode = CXL_MBOX_OP_GET_LOG,
+ .payload_in = ,
+ .payload_out = out,
+ .size_in = sizeof(log),
+ };
+
+ rc = cxl_mem_mbox_send_cmd(cxlm, _cmd);
+ if (rc)
+ return rc;
+
+ WARN_ON(mbox_cmd.size_out != xfer_size);
+
+ out += xfer_size;
+ remaining -= xfer_size;
+ offset += xfer_size;
+ }
+
+ return 0;
+}
+
+static void cxl_enable_cmd(struct cxl_mem *cxlm,
+ const struct cxl_mem_command *cmd)
+{
+ if (test_and_set_bit(cmd->info.id, cxlm->enabled_cmds))
+ dev_warn(>pdev->dev, "Command enabled twice\n");
+
+ dev_info(>pdev->dev, "%s enabled",
+cxl_command_names[cmd->info.id].name);
+}
+
+/**
+ * cxl_walk_cel() - Walk through the Command Effects Log.
+ * @cxlm: Device.
+ * @size: Length of the Command Effects Log.
+ * @cel: CEL
+ *
+ * Iterate over each entry in the CEL and determine if the driver supports the
+ * command. If so, the command is enabled for the device and can be used later.
+ */
+static void cxl_walk_cel(struct cxl_mem *cxlm, size_t size, u8 *cel)
+{
+ struct cel_entry {
+ __le16 opcode;
+ __le16 effect;
+ } *cel_entry;
+ const int cel_entries = size / sizeof(*cel_entry);
+ int i;
+
+ cel_entry = (struct cel_entry *)cel;
+
+ for (i = 0; i < cel_entries; i++) {
+ const
[PATCH 13/14] cxl/mem: Add limited Get Log command (0401h)
The Get Log command returns the actual log entries that are advertised
via the Get Supported Logs command (0400h). CXL device logs are selected
by UUID which is part of the CXL spec. Because the driver tries to
sanitize what is sent to hardware, there becomes a need to restrict the
types of logs which can be accessed by userspace. For example, the
vendor specific log might only be consumable by proprietary, or offline
applications, and therefore a good candidate for userspace.
The current driver infrastructure does allow basic validation for all
commands, but doesn't inspect any of the payload data. Along with Get
Log support comes new infrastructure to add a hook for payload
validation. This infrastructure is used to filter out the CEL UUID,
which the userspace driver doesn't have business knowing, and taints on
invalid UUIDs being sent to hardware.
Signed-off-by: Ben Widawsky
---
drivers/cxl/mem.c| 42 +++-
include/uapi/linux/cxl_mem.h | 1 +
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index b8ca6dff37b5..086268f1dd6c 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -119,6 +119,8 @@ static const uuid_t log_uuid[] = {
0x07, 0x19, 0x40, 0x3d, 0x86)
};
+static int validate_log_uuid(void __user *payload, size_t size);
+
/**
* struct cxl_mem_command - Driver representation of a memory device command
* @info: Command information as it exists for the UAPI
@@ -132,6 +134,10 @@ static const uuid_t log_uuid[] = {
* * %CXL_CMD_INTERNAL_FLAG_PSEUDO: This is a pseudo command which doesn't
have
*a direct mapping to hardware. They are implicitly always enabled.
*
+ * @validate_payload: A function called after the command is validated but
+ * before it's sent to the hardware. The primary purpose is to validate, or
+ * fixup the actual payload.
+ *
* The cxl_mem_command is the driver's internal representation of commands that
* are supported by the driver. Some of these commands may not be supported by
* the hardware. The driver will use @info to validate the fields passed in by
@@ -147,9 +153,11 @@ struct cxl_mem_command {
#define CXL_CMD_INTERNAL_FLAG_HIDDEN BIT(0)
#define CXL_CMD_INTERNAL_FLAG_MANDATORY BIT(1)
#define CXL_CMD_INTERNAL_FLAG_PSEUDO BIT(2)
+
+ int (*validate_payload)(void __user *payload, size_t size);
};
-#define CXL_CMD(_id, _flags, sin, sout, f)
\
+#define CXL_CMD_VALIDATE(_id, _flags, sin, sout, f, v)
\
[CXL_MEM_COMMAND_ID_##_id] = { \
.info = { \
.id = CXL_MEM_COMMAND_ID_##_id,\
@@ -159,8 +167,12 @@ struct cxl_mem_command {
}, \
.flags = CXL_CMD_INTERNAL_FLAG_##f,\
.opcode = CXL_MBOX_OP_##_id, \
+ .validate_payload = v, \
}
+#define CXL_CMD(_id, _flags, sin, sout, f)
\
+ CXL_CMD_VALIDATE(_id, _flags, sin, sout, f, NULL)
+
/*
* This table defines the supported mailbox commands for the driver. This table
* is made up of a UAPI structure. Non-negative values as parameters in the
@@ -176,6 +188,8 @@ static struct cxl_mem_command mem_commands[] = {
CXL_CMD(GET_PARTITION_INFO, NONE, 0, 0x20, NONE),
CXL_CMD(GET_LSA, NONE, 0x8, ~0, MANDATORY),
CXL_CMD(GET_HEALTH_INFO, NONE, 0, 0x12, MANDATORY),
+ CXL_CMD_VALIDATE(GET_LOG, MUTEX, 0x18, ~0, MANDATORY,
+validate_log_uuid),
};
/*
@@ -563,6 +577,13 @@ static int handle_mailbox_cmd_from_user(struct cxl_memdev
*cxlmd,
kvzalloc(cxlm->mbox.payload_size, GFP_KERNEL);
if (cmd->info.size_in) {
+ if (cmd->validate_payload) {
+ rc = cmd->validate_payload(u64_to_user_ptr(in_payload),
+ cmd->info.size_in);
+ if (rc)
+ goto out;
+ }
+
mbox_cmd.payload_in = kvzalloc(cmd->info.size_in, GFP_KERNEL);
if (!mbox_cmd.payload_in) {
rc = -ENOMEM;
@@ -1205,6 +1226,25 @@ struct cxl_mbox_get_log {
__le32 length;
} __packed;
+static int validate_log_uuid(void __user *input, size_t size)
+{
+ struct cxl_mbox_get_log __user *get_log = input;
+ uuid_t payload_uuid;
+
+ if (copy_from_user(_uuid, _log->uuid, sizeof(uuid_t)))
+ return -EFAULT;
+
+ /* All unspec'd logs shall taint */
+ if (uuid_equal(_uuid, _uuid[CEL_UUID]))
+ return 0;
+ if
[PATCH 04/14] cxl/mem: Implement polled mode mailbox
Provide enough functionality to utilize the mailbox of a memory device.
The mailbox is used to interact with the firmware running on the memory
device.
The CXL specification defines separate capabilities for the mailbox and
the memory device. The mailbox interface has a doorbell to indicate
ready to accept commands and the memory device has a capability register
that indicates the mailbox interface is ready. The expectation is that
the doorbell-ready is always later than the memory-device-indication
that the mailbox is ready.
Create a function to handle sending a command, optionally with a
payload, to the memory device, polling on a result, and then optionally
copying out the payload. The algorithm for doing this comes straight out
of the CXL 2.0 specification.
Primary mailboxes are capable of generating an interrupt when submitting
a command in the background. That implementation is saved for a later
time.
Secondary mailboxes aren't implemented at this time.
The flow is proven with one implemented command, "identify". Because the
class code has already told the driver this is a memory device and the
identify command is mandatory.
Signed-off-by: Ben Widawsky
---
drivers/cxl/Kconfig | 14 ++
drivers/cxl/cxl.h | 39 +
drivers/cxl/mem.c | 342 +++-
3 files changed, 394 insertions(+), 1 deletion(-)
diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
index 3b66b46af8a0..fe591f74af96 100644
--- a/drivers/cxl/Kconfig
+++ b/drivers/cxl/Kconfig
@@ -32,4 +32,18 @@ config CXL_MEM
Chapter 2.3 Type 3 CXL Device in the CXL 2.0 specification.
If unsure say 'm'.
+
+config CXL_MEM_INSECURE_DEBUG
+ bool "CXL.mem debugging"
+ depends on CXL_MEM
+ help
+ Enable debug of all CXL command payloads.
+
+ Some CXL devices and controllers support encryption and other
+ security features. The payloads for the commands that enable
+ those features may contain sensitive clear-text security
+ material. Disable debug of those command payloads by default.
+ If you are a kernel developer actively working on CXL
+ security enabling say Y, otherwise say N.
+
endif
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index a3da7f8050c4..df3d97154b63 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -31,9 +31,36 @@
#define CXLDEV_MB_CAPS_OFFSET 0x00
#define CXLDEV_MB_CAP_PAYLOAD_SIZE_MASK GENMASK(4, 0)
#define CXLDEV_MB_CTRL_OFFSET 0x04
+#define CXLDEV_MB_CTRL_DOORBELL BIT(0)
#define CXLDEV_MB_CMD_OFFSET 0x08
+#define CXLDEV_MB_CMD_COMMAND_OPCODE_MASK GENMASK(15, 0)
+#define CXLDEV_MB_CMD_PAYLOAD_LENGTH_MASK GENMASK(36, 16)
#define CXLDEV_MB_STATUS_OFFSET 0x10
+#define CXLDEV_MB_STATUS_RET_CODE_MASK GENMASK(47, 32)
#define CXLDEV_MB_BG_CMD_STATUS_OFFSET 0x18
+#define CXLDEV_MB_PAYLOAD_OFFSET 0x20
+
+/* Memory Device (CXL 2.0 - 8.2.8.5.1.1) */
+#define CXLMDEV_STATUS_OFFSET 0x0
+#define CXLMDEV_DEV_FATAL BIT(0)
+#define CXLMDEV_FW_HALT BIT(1)
+#define CXLMDEV_STATUS_MEDIA_STATUS_MASK GENMASK(3, 2)
+#define CXLMDEV_MS_NOT_READY 0
+#define CXLMDEV_MS_READY 1
+#define CXLMDEV_MS_ERROR 2
+#define CXLMDEV_MS_DISABLED 3
+#define CXLMDEV_READY(status) \
+ (CXL_GET_FIELD(status, CXLMDEV_STATUS_MEDIA_STATUS) ==
CXLMDEV_MS_READY)
+#define CXLMDEV_MBOX_IF_READY BIT(4)
+#define CXLMDEV_RESET_NEEDED_SHIFT 5
+#define CXLMDEV_RESET_NEEDED_MASK GENMASK(7, 5)
+#define CXLMDEV_RESET_NEEDED_NOT 0
+#define CXLMDEV_RESET_NEEDED_COLD 1
+#define CXLMDEV_RESET_NEEDED_WARM 2
+#define CXLMDEV_RESET_NEEDED_HOT 3
+#define CXLMDEV_RESET_NEEDED_CXL 4
+#define CXLMDEV_RESET_NEEDED(status) \
+ (CXL_GET_FIELD(status, CXLMDEV_RESET_NEEDED) !=
CXLMDEV_RESET_NEEDED_NOT)
/**
* struct cxl_mem - A CXL memory device
@@ -44,6 +71,16 @@ struct cxl_mem {
struct pci_dev *pdev;
void __iomem *regs;
+ struct {
+ struct range range;
+ } pmem;
+
+ struct {
+ struct range range;
+ } ram;
+
+ char firmware_version[0x10];
+
/* Cap 0001h - CXL_CAP_CAP_ID_DEVICE_STATUS */
struct {
void __iomem *regs;
@@ -51,6 +88,7 @@ struct cxl_mem {
/* Cap 0002h - CXL_CAP_CAP_ID_PRIMARY_MAILBOX */
struct {
+ struct mutex mutex; /* Protects device mailbox and firmware */
void __iomem *regs;
size_t payload_size;
} mbox;
@@ -89,5 +127,6 @@ struct cxl_mem {
cxl_reg(status);
cxl_reg(mbox);
+cxl_reg(mem);
#endif /* __CXL_H__ */
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index fa14d51243ee..69ed15bfa5d4 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -6,6 +6,270 @@
#include "pci.h"
#include "cxl.h"
+#define cxl_doorbell_busy(cxlm)
\
+ (cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CTRL_OFFSET) &
[PATCH 00/14] CXL 2.0 Support
# Changes since RFC v3 [1] * Added error message when payload size is too small. (Ben) * Fix includes in UAPI for Clang (LKP) * Reorder CXL in MAINTAINERS (Joe Perches) * Kconfig whitespace and spelling fixes (Randy) * Remove excess frees controlled by devm, introduced in v3 (Jonathan, Dan) * Use 'PCI Express' instead of 'PCI-E' in Kconfig (Jonathan) * Fail when mailbox commands return value is an error (Jonathan) * Add comment to mailbox protocol to explain ordering of operations (Jonathan, Ben) * Fail mailbox xfer when doorbell is busy. (Jonathan) * Remove extraneous SHIFT defines. (Jonathan) * Change kdocs for mbox_cmd size_out to output only. (Jonathan) * Fix transient bug (ENOTTY) in CXL_MEM_QUERY_COMMANDS (Jonathan) * Add some comments and code beautification to mbox commands (Jonathan) * Add some comments and code beautification to user commands (Jonathan) * Fix bogus check of memcpy return value (Ben) * Add concept of blocking certain RAW opcodes (Dan) * Add debugfs knob to allow all RAW opcodes (Vishal) * Move docs to driver-api/ (Dan) * Use bounce buffer again like in v2 (Jonathan) * Use kvzalloc instead of memdup (Ben) * Wordsmith some changelogs and documentation (Dan) * Use a percpu_ref counter to protect devm allocated data in the ioctl path (Dan) * Rework cdev registration and lookup to use inode->i_cdev (Dan) * Drop mutex_lock_interruptible() from ioctl path (Dan) * Convert add_taint() to WARN_TAINT_ONCE() * Drop ACPI coordination for pure mailbox driver milestone (Dan) * Permit GET_LOG with CEL_UUID (Ben) * Cover letter overhaul (Ben) * Use info.id instead of CXL_COMMAND_INDEX (Dan) * Add several new commands to the mailbox interface (Ben) --- In addition to the mailing list, please feel free to use #cxl on oftc IRC for discussion. --- # Summary Introduce support for “type-3” memory devices defined in the Compute Express Link (CXL) 2.0 specification [2]. Specifically, these are the memory devices defined by section 8.2.8.5 of the CXL 2.0 spec. A reference implementation emulating these devices has been submitted to the QEMU mailing list [3] and is available on gitlab [4], but will move to a shared tree on kernel.org after initial acceptance. “Type-3” is a CXL device that acts as a memory expander for RAM or Persistent Memory. The device might be interleaved with other CXL devices in a given physical address range. In addition to the core functionality of discovering the spec defined registers and resources, introduce a CXL device model that will be the foundation for translating CXL capabilities into existing Linux infrastructure for Persistent Memory and other memory devices. For now, this only includes support for the management command mailbox the surfacing of type-3 devices. These control devices fill the role of “DIMMs” / nmemX memory-devices in LIBNVDIMM terms. ## Userspace Interaction Interaction with the driver and type-3 devices via the CXL drivers is introduced in this patch series and considered stable ABI. They include * sysfs - Documentation/ABI/testing/sysfs-bus-cxl * IOCTL - Documentation/driver-api/cxl/memory-devices.rst * debugfs - Documentation/ABI/testing/debugfs-debug Work is in process to add support for CXL interactions to the ndctl project [5] ### Development plans One of the unique challenges that CXL imposes on the Linux driver model is that it requires the operating system to perform physical address space management interleaved across devices and bridges. Whereas LIBNVDIMM handles a list of established static persistent memory address ranges (for example from the ACPI NFIT), CXL introduces hotplug and the concept of allocating address space to instantiate persistent memory ranges. This is similar to PCI in the sense that the platform establishes the MMIO range for PCI BARs to be allocated, but it is significantly complicated by the fact that a given device can optionally be interleaved with other devices and can participate in several interleave-sets at once. LIBNVDIMM handled something like this with the aliasing between PMEM and BLOCK-WINDOW mode, but CXL adds flexibility to alias DEVICE MEMORY through up to 10 decoders per device. All of the above needs to be enabled with respect to PCI hotplug events on Type-3 memory device which needs hooks to determine if a given device is contributing to a "System RAM" address range that is unable to be unplugged. In other words CXL ties PCI hotplug to Memory Hotplug and PCI hotplug needs to be able to negotiate with memory hotplug. In the medium term the implications of CXL hotplug vs ACPI SRAT/SLIT/HMAT need to be reconciled. One capability that seems to be needed is either the dynamic allocation of new memory nodes, or default initializing extra pgdat instances beyond what is enumerated in ACPI SRAT to accommodate hot-added CXL memory. Patches welcome, questions welcome as the development
[PATCH 01/14] cxl/mem: Introduce a driver for CXL-2.0-Type-3 endpoints
From: Dan Williams The CXL.mem protocol allows a device to act as a provider of "System RAM" and/or "Persistent Memory" that is fully coherent as if the memory was attached to the typical CPU memory controller. With the CXL-2.0 specification a PCI endpoint can implement a "Type-3" device interface and give the operating system control over "Host Managed Device Memory". See section 2.3 Type 3 CXL Device. The memory range exported by the device may optionally be described by the platform firmware memory map, or by infrastructure like LIBNVDIMM to provision persistent memory capacity from one, or more, CXL.mem devices. A pre-requisite for Linux-managed memory-capacity provisioning is this cxl_mem driver that can speak the mailbox protocol defined in section 8.2.8.4 Mailbox Registers. For now just land the initial driver boiler-plate and Documentation/ infrastructure. Link: https://www.computeexpresslink.org/download-the-specification Cc: Jonathan Corbet Signed-off-by: Dan Williams Signed-off-by: Ben Widawsky --- Documentation/driver-api/cxl/index.rst| 12 .../driver-api/cxl/memory-devices.rst | 29 + Documentation/driver-api/index.rst| 1 + drivers/Kconfig | 1 + drivers/Makefile | 1 + drivers/cxl/Kconfig | 35 +++ drivers/cxl/Makefile | 4 ++ drivers/cxl/mem.c | 61 +++ drivers/cxl/pci.h | 20 ++ 9 files changed, 164 insertions(+) create mode 100644 Documentation/driver-api/cxl/index.rst create mode 100644 Documentation/driver-api/cxl/memory-devices.rst create mode 100644 drivers/cxl/Kconfig create mode 100644 drivers/cxl/Makefile create mode 100644 drivers/cxl/mem.c create mode 100644 drivers/cxl/pci.h diff --git a/Documentation/driver-api/cxl/index.rst b/Documentation/driver-api/cxl/index.rst new file mode 100644 index ..036e49553542 --- /dev/null +++ b/Documentation/driver-api/cxl/index.rst @@ -0,0 +1,12 @@ +.. SPDX-License-Identifier: GPL-2.0 + + +Compute Express Link + + +.. toctree:: + :maxdepth: 1 + + memory-devices + +.. only:: subproject and html diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst new file mode 100644 index ..43177e700d62 --- /dev/null +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -0,0 +1,29 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +=== +Compute Express Link Memory Devices +=== + +A Compute Express Link Memory Device is a CXL component that implements the +CXL.mem protocol. It contains some amount of volatile memory, persistent memory, +or both. It is enumerated as a PCI device for configuration and passing +messages over an MMIO mailbox. Its contribution to the System Physical +Address space is handled via HDM (Host Managed Device Memory) decoders +that optionally define a device's contribution to an interleaved address +range across multiple devices underneath a host-bridge or interleaved +across host-bridges. + +Driver Infrastructure += + +This section covers the driver infrastructure for a CXL memory device. + +CXL Memory Device +- + +.. kernel-doc:: drivers/cxl/mem.c + :doc: cxl mem + +.. kernel-doc:: drivers/cxl/mem.c + :internal: diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 2456d0a97ed8..d246a18fd78f 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -35,6 +35,7 @@ available subsections can be seen below. usb/index firewire pci/index + cxl/index spi i2c ipmb diff --git a/drivers/Kconfig b/drivers/Kconfig index dcecc9f6e33f..62c753a73651 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -6,6 +6,7 @@ menu "Device Drivers" source "drivers/amba/Kconfig" source "drivers/eisa/Kconfig" source "drivers/pci/Kconfig" +source "drivers/cxl/Kconfig" source "drivers/pcmcia/Kconfig" source "drivers/rapidio/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile index fd11b9ac4cc3..678ea810410f 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -73,6 +73,7 @@ obj-$(CONFIG_NVM) += lightnvm/ obj-y += base/ block/ misc/ mfd/ nfc/ obj-$(CONFIG_LIBNVDIMM)+= nvdimm/ obj-$(CONFIG_DAX) += dax/ +obj-$(CONFIG_CXL_BUS) += cxl/ obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/ obj-$(CONFIG_NUBUS)+= nubus/ obj-y += macintosh/ diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig new file mode 100644 index ..3b66b46af8a0 --- /dev/null +++ b/drivers/cxl/Kconfig @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: GPL-2.0-only +menuconfig CXL_BUS +
[PATCH 02/14] cxl/mem: Map memory device registers
All the necessary bits are initialized in order to find and map the
register space for CXL Memory Devices. This is accomplished by using the
Register Locator DVSEC (CXL 2.0 - 8.1.9.1) to determine which PCI BAR to
use, and how much of an offset from that BAR should be added.
If the memory device registers are found and mapped a new internal data
structure tracking device state is allocated.
Signed-off-by: Ben Widawsky
---
drivers/cxl/cxl.h | 17 ++
drivers/cxl/mem.c | 83 +--
drivers/cxl/pci.h | 14
3 files changed, 112 insertions(+), 2 deletions(-)
create mode 100644 drivers/cxl/cxl.h
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
new file mode 100644
index ..d81d0ba4617c
--- /dev/null
+++ b/drivers/cxl/cxl.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/* Copyright(c) 2020 Intel Corporation. */
+
+#ifndef __CXL_H__
+#define __CXL_H__
+
+/**
+ * struct cxl_mem - A CXL memory device
+ * @pdev: The PCI device associated with this CXL device.
+ * @regs: IO mappings to the device's MMIO
+ */
+struct cxl_mem {
+ struct pci_dev *pdev;
+ void __iomem *regs;
+};
+
+#endif
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index f4ee9a507ac9..a869c8dc24cc 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -4,6 +4,58 @@
#include
#include
#include "pci.h"
+#include "cxl.h"
+
+/**
+ * cxl_mem_create() - Create a new cxl_mem.
+ * @pdev: The pci device associated with the new cxl_mem.
+ * @reg_lo: Lower 32b of the register locator
+ * @reg_hi: Upper 32b of the register locator.
+ *
+ * Return: The new cxl_mem on success, NULL on failure.
+ *
+ * Map the BAR for a CXL memory device. This BAR has the memory device's
+ * registers for the device as specified in CXL specification.
+ */
+static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo,
+ u32 reg_hi)
+{
+ struct device *dev = >dev;
+ struct cxl_mem *cxlm;
+ void __iomem *regs;
+ u64 offset;
+ u8 bar;
+ int rc;
+
+ offset = ((u64)reg_hi << 32) | (reg_lo & CXL_REGLOC_ADDR_MASK);
+ bar = (reg_lo >> CXL_REGLOC_BIR_SHIFT) & CXL_REGLOC_BIR_MASK;
+
+ /* Basic sanity check that BAR is big enough */
+ if (pci_resource_len(pdev, bar) < offset) {
+ dev_err(dev, "BAR%d: %pr: too small (offset: %#llx)\n", bar,
+ >resource[bar], (unsigned long long)offset);
+ return NULL;
+ }
+
+ rc = pcim_iomap_regions(pdev, BIT(bar), pci_name(pdev));
+ if (rc != 0) {
+ dev_err(dev, "failed to map registers\n");
+ return NULL;
+ }
+
+ cxlm = devm_kzalloc(>dev, sizeof(*cxlm), GFP_KERNEL);
+ if (!cxlm) {
+ dev_err(dev, "No memory available\n");
+ return NULL;
+ }
+
+ regs = pcim_iomap_table(pdev)[bar];
+ cxlm->pdev = pdev;
+ cxlm->regs = regs + offset;
+
+ dev_dbg(dev, "Mapped CXL Memory Device resource\n");
+ return cxlm;
+}
static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
{
@@ -32,15 +84,42 @@ static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct device *dev = >dev;
- int regloc;
+ struct cxl_mem *cxlm;
+ int rc, regloc, i;
+
+ rc = pcim_enable_device(pdev);
+ if (rc)
+ return rc;
regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
if (!regloc) {
dev_err(dev, "register location dvsec not found\n");
return -ENXIO;
}
+ regloc += 0xc; /* Skip DVSEC + reserved fields */
- return 0;
+ rc = -ENXIO;
+ for (i = regloc; i < regloc + 0x24; i += 8) {
+ u32 reg_lo, reg_hi;
+ u8 reg_type;
+
+ /* "register low and high" contain other bits */
+ pci_read_config_dword(pdev, i, _lo);
+ pci_read_config_dword(pdev, i + 4, _hi);
+
+ reg_type =
+ (reg_lo >> CXL_REGLOC_RBI_SHIFT) & CXL_REGLOC_RBI_MASK;
+
+ if (reg_type == CXL_REGLOC_RBI_MEMDEV) {
+ rc = 0;
+ cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
+ if (!cxlm)
+ rc = -ENODEV;
+ break;
+ }
+ }
+
+ return rc;
}
static const struct pci_device_id cxl_mem_pci_tbl[] = {
diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
index a8a9935fa90b..df222edb6ac3 100644
--- a/drivers/cxl/pci.h
+++ b/drivers/cxl/pci.h
@@ -17,4 +17,18 @@
#define PCI_DVSEC_ID_CXL_REGLOC0x8
+/* BAR Indicator Register (BIR) */
+#define CXL_REGLOC_BIR_SHIFT 0
+#define CXL_REGLOC_BIR_MASK 0x7
+
+/* Register Block Identifier (RBI) */
+#define CXL_REGLOC_RBI_SHIFT 8
Re: [PATCH 1/5] docs: arm: marvell: turn the automatic links into labels
Lubomir Rintel writes: > Lines ending with obscenely long URLs at the end don't look good. > > Even if these links are not that long at this point, they will be when > replaced with an archive link in a subsequent patch -- let's prepare for > that. > > Signed-off-by: Lubomir Rintel > --- > Documentation/arm/marvel.rst | 209 --- > 1 file changed, 143 insertions(+), 66 deletions(-) > > diff --git a/Documentation/arm/marvel.rst b/Documentation/arm/marvel.rst > index 16ab2eb085b86..716551f9b60a1 100644 > --- a/Documentation/arm/marvel.rst > +++ b/Documentation/arm/marvel.rst > @@ -18,12 +18,12 @@ Orion family > - 88F5181L > - 88F5182 > > - - Datasheet: > http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf > - - Programmer's User Guide: > http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf > - - User Manual: > http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf > + - Datasheet: `MV88F5182-datasheet.pdf`_ > + - Programmer's User Guide: `MV88F5182-opensource-manual.pdf`_ > + - User Manual: `MV88F5182-usermanual.pdf`_ > - 88F5281 > > - - Datasheet: > http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf > + - Datasheet: `marvel_88f5281_data_sheet.pdf`_ > - 88F6183 >Core: > Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible > @@ -32,37 +32,42 @@ Orion family >Linux kernel plat directory: > arch/arm/plat-orion > > +.. _MV88F5182-datasheet.pdf: > http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf > +.. _MV88F5182-opensource-manual.pdf: > http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf > +.. _MV88F5182-usermanual.pdf: > http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf > +.. _marvel_88f5281_data_sheet.pdf: > http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf So I see what you're trying to do, but this has the effect of prettying up the processed docs at the expense of making the plain-text version harder to read. Somebody who wants to find one of these datasheets from the plain-text version has to skip further down in the file, hoping that they pick out the right one among a set of long, similar URLs. Honestly, I think we may be better off leaving them as they are. Failing that, the right thing to do is to keep the lines defining the URL labels right next to where they are referenced. See what I'm getting at? Thanks, jon
Re: [PATCH] Updates Documentation/Makefile to use Python3 as fallback
Noa Sakurajin writes:
[CC += kbuild maintainers]
> Before the command python was needed for the documentation to build.
> This patch checks if python is available and uses python3 as
> fallback.
>
> This is needed because a lot of distribution (at least Ubuntu)
> only provide python3 and not python. scripts/sphinx-pre-install
> checks for python3 first and does not check if python exists
> which causes it to report that everything is installed even
> if the documentation build failed.
>
> Signed-off-by: Noa Sakurajin
> ---
> Documentation/Makefile | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index 61a7310b49e0..8a4a7df3b74a 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -75,7 +75,8 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath
> $(BUILDDIR)/$3/$4)
>cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR))
> $(build)=Documentation/userspace-api/media $2 && \
> PYTHONDONTWRITEBYTECODE=1 \
> BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath
> $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
> - $(PYTHON) $(srctree)/scripts/jobserver-exec \
> + PY=$(shell command -v $(PYTHON) 2> /dev/null) \
> + $${PY:-"$(PYTHON3)"} $(srctree)/scripts/jobserver-exec \
So I see what you're trying to do, and we definitely want this to work.
I susped this isn't the right fix, though; it could leave us open to
similar issues elsewhere in the tree.
Personally, I think that $(PYTHON) should get a working Python if it's
installed, so I would suggest fixing the top-level Makefile to set it
correctly. Masahiro, thoughts on that?
Alternatively, we could just say $(PYTHON3) and explicitly leave Python2
behind; that needs to happen in the not-too-distant future regardless
but we haven't decided to actually do it yet.
Thanks,
jon
[PATCH v2] MAINTAINERS: Add pattern that matches powerpc perf to the perf entry.
From: Michal Suchanek The powerpc perf code is under arch/powerpc/perf, add a matching pattern to the perf MAINTAINERS entry. Signed-off-by: Michal Suchanek [mpe: Rebase and add change log] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191113162754.6991-1-msucha...@suse.de --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6eff4f720c72..d556d15505b3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13930,6 +13930,8 @@ F: arch/*/kernel/*/*/perf_event*.c F: arch/*/kernel/*/perf_event*.c F: arch/*/kernel/perf_callchain.c F: arch/*/kernel/perf_event*.c +F: arch/*/perf/* +F: arch/*/perf/*/* F: include/linux/perf_event.h F: include/uapi/linux/perf_event.h F: kernel/events/* -- 2.25.1
[tip:x86/fpu] BUILD SUCCESS 0a74d61c7d842b583f33f74d7a9e93201826f4c5
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/fpu branch HEAD: 0a74d61c7d842b583f33f74d7a9e93201826f4c5 x86/fpu/xstate: Use sizeof() instead of a constant elapsed time: 725m configs tested: 103 configs skipped: 29 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig mips gcw0_defconfig mips tb0219_defconfig s390 allyesconfig arm netwinder_defconfig mips ath25_defconfig ia64zx1_defconfig powerpc chrp32_defconfig mips loongson1c_defconfig sh secureedge5410_defconfig powerpc sbc8548_defconfig arm milbeaut_m10v_defconfig powerpc bamboo_defconfig sparc sparc64_defconfig c6xevmc6472_defconfig arm integrator_defconfig sh rts7751r2dplus_defconfig sh se7780_defconfig sh polaris_defconfig shecovec24-romimage_defconfig mips bmips_stb_defconfig xtensasmp_lx200_defconfig mips malta_defconfig mips tb0226_defconfig powerpc powernv_defconfig m68k m5475evb_defconfig arm ixp4xx_defconfig arm collie_defconfig openriscor1ksim_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a001-20210129 i386 randconfig-a002-20210129 i386 randconfig-a004-20210129 i386 randconfig-a005-20210129 i386 randconfig-a003-20210129 i386 randconfig-a006-20210129 i386 randconfig-a013-20210129 i386 randconfig-a011-20210129 i386 randconfig-a012-20210129 i386 randconfig-a016-20210129 i386 randconfig-a014-20210129 i386 randconfig-a015-20210129 x86_64 randconfig-a002-20210129 x86_64 randconfig-a003-20210129 x86_64 randconfig-a001-20210129 x86_64 randconfig-a005-20210129 x86_64 randconfig-a006-20210129 x86_64 randconfig-a004-20210129 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a012-20210129 x86_64 randconfig-a015-20210129 x86_64 randconfig-a016-20210129
Re: [PATCH v6 0/2] Kbuild: DWARF v5 support
On Fri, Jan 29, 2021 at 8:43 PM Nick Desaulniers wrote: > > DWARF v5 is the latest standard of the DWARF debug info format. > > DWARF5 wins significantly in terms of size and especially so when mixed > with compression (CONFIG_DEBUG_INFO_COMPRESSED). > > Link: http://www.dwarfstd.org/doc/DWARF5.pdf > > Patch 1 is a cleanup that lays the ground work and isn't DWARF > v5 specific. > Patch 2 implements Kconfig and Kbuild support for DWARFv5. > When you will do a v7... Can you look also at places where we have hardcoded DWARF-2 handling... For example: arch/x86/purgatory/Makefile:AFLAGS_REMOVE_setup-x86_$(BITS).o += -Wa,-gdwarf-2 arch/x86/purgatory/Makefile:AFLAGS_REMOVE_entry64.o += -Wa,-gdwarf-2 - Sedat - > Changes from v5: > * Drop previous patch 1, it has been accepted into kbuild: > > https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild=3f4d8ce271c7082be75bacbcbd2048aa78ce2b44 > * Trying to set -Wa,-gdwarf-4 in the earlier patch was the source of > additional complexity. Drop it that part of the patch. We can revisit > clang without the integrated assembler setting -Wa,-gdwarf-4 later. > That is a separate problem from generally supporting DWARF v5. > * Rework the final patch for clang without the integrated assembler. > -Wa,-gdwarf-5 is required for DWARF5 in that case otherwise GAS will > not accept the assembler directives clang produces from C code when > generating asm. > > Changes from v4: > * drop set -e from script as per Nathan. > * add dependency on !CONFIG_DEBUG_INFO_BTF for DWARF v5 as per Sedat. > * Move LLVM_IAS=1 complexity from patch 2 to patch 3 as per Arvind and > Masahiro. Sorry it took me a few tries to understand the point (I > might still not), but it looks much cleaner this way. Sorry Nathan, I > did not carry forward your previous reviews as a result, but I would > appreciate if you could look again. > * Add Nathan's reviewed by tag to patch 1. > * Reword commit message for patch 3 to mention LLVM_IAS=1 and -gdwarf-5 > binutils addition later, and BTF issue. > * I still happen to see a pahole related error spew for the combination > of: > * LLVM=1 > * LLVM_IAS=1 > * CONFIG_DEBUG_INFO_DWARF4 > * CONFIG_DEBUG_INFO_BTF > Though they're non-fatal to the build. I'm not sure yet why removing > any one of the above prevents the warning spew. Maybe we'll need a v6. > > Changes from v3: > > Changes as per Arvind: > * only add -Wa,-gdwarf-5 for (LLVM=1|CC=clang)+LLVM_IAS=0 builds. > * add -gdwarf-5 to Kconfig shell script. > * only run Kconfig shell script for Clang. > > Apologies to Sedat and Nathan; I appreciate previous testing/review, but > I did no carry forward your Tested-by and Reviewed-by tags, as the > patches have changed too much IMO. > > Changes from v2: > * Drop two of the earlier patches that have been accepted already. > * Add measurements with GCC 10.2 to commit message. > * Update help text as per Arvind with help from Caroline. > * Improve case/wording between DWARF Versions as per Masahiro. > > Changes from the RFC: > * split patch in 3 patch series, include Fangrui's patch, too. > * prefer `DWARF vX` format, as per Fangrui. > * use spaces between assignment in Makefile as per Masahiro. > * simplify setting dwarf-version-y as per Masahiro. > * indent `prompt` in Kconfig change as per Masahiro. > * remove explicit default in Kconfig as per Masahiro. > * add comments to test_dwarf5_support.sh. > * change echo in test_dwarf5_support.sh as per Masahiro. > * remove -u from test_dwarf5_support.sh as per Masahiro. > * add a -gdwarf-5 cc-option check to Kconfig as per Jakub. > > Nick Desaulniers (2): > Kbuild: make DWARF version a choice > Kbuild: implement support for DWARF v5 > > Makefile | 16 ++-- > include/asm-generic/vmlinux.lds.h | 6 - > lib/Kconfig.debug | 41 ++- > scripts/test_dwarf5_support.sh| 8 ++ > 4 files changed, 62 insertions(+), 9 deletions(-) > create mode 100755 scripts/test_dwarf5_support.sh > > -- > 2.30.0.365.g02bc693789-goog >
[PATCH net] rxrpc: Fix deadlock around release of dst cached on udp tunnel
AF_RXRPC sockets use UDP ports in encap mode. This causes socket and dst
from an incoming packet to get stolen and attached to the UDP socket from
whence it is leaked when that socket is closed.
When a network namespace is removed, the wait for dst records to be cleaned
up happens before the cleanup of the rxrpc and UDP socket, meaning that the
wait never finishes.
Fix this by moving the rxrpc (and, by dependence, the afs) private
per-network namespace registrations to the device group rather than subsys
group. This allows cached rxrpc local endpoints to be cleared and their
UDP sockets closed before we try waiting for the dst records.
The symptom is that lines looking like the following:
unregister_netdevice: waiting for lo to become free
get emitted at regular intervals after running something like the
referenced syzbot test.
Thanks to Vadim for tracking this down and work out the fix.
Reported-by: syzbot+df400f2f24a1677cd...@syzkaller.appspotmail.com
Reported-by: Vadim Fedorenko
Fixes: 5271953cad31 ("rxrpc: Use the UDP encap_rcv hook")
Signed-off-by: David Howells
Acked-by: Vadim Fedorenko
---
fs/afs/main.c|6 +++---
net/rxrpc/af_rxrpc.c |6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/afs/main.c b/fs/afs/main.c
index accdd8970e7c..b2975256dadb 100644
--- a/fs/afs/main.c
+++ b/fs/afs/main.c
@@ -193,7 +193,7 @@ static int __init afs_init(void)
goto error_cache;
#endif
- ret = register_pernet_subsys(_net_ops);
+ ret = register_pernet_device(_net_ops);
if (ret < 0)
goto error_net;
@@ -213,7 +213,7 @@ static int __init afs_init(void)
error_proc:
afs_fs_exit();
error_fs:
- unregister_pernet_subsys(_net_ops);
+ unregister_pernet_device(_net_ops);
error_net:
#ifdef CONFIG_AFS_FSCACHE
fscache_unregister_netfs(_cache_netfs);
@@ -244,7 +244,7 @@ static void __exit afs_exit(void)
proc_remove(afs_proc_symlink);
afs_fs_exit();
- unregister_pernet_subsys(_net_ops);
+ unregister_pernet_device(_net_ops);
#ifdef CONFIG_AFS_FSCACHE
fscache_unregister_netfs(_cache_netfs);
#endif
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 0a2f4817ec6c..41671af6b33f 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -990,7 +990,7 @@ static int __init af_rxrpc_init(void)
goto error_security;
}
- ret = register_pernet_subsys(_net_ops);
+ ret = register_pernet_device(_net_ops);
if (ret)
goto error_pernet;
@@ -1035,7 +1035,7 @@ static int __init af_rxrpc_init(void)
error_sock:
proto_unregister(_proto);
error_proto:
- unregister_pernet_subsys(_net_ops);
+ unregister_pernet_device(_net_ops);
error_pernet:
rxrpc_exit_security();
error_security:
@@ -1057,7 +1057,7 @@ static void __exit af_rxrpc_exit(void)
unregister_key_type(_type_rxrpc);
sock_unregister(PF_RXRPC);
proto_unregister(_proto);
- unregister_pernet_subsys(_net_ops);
+ unregister_pernet_device(_net_ops);
ASSERTCMP(atomic_read(_n_tx_skbs), ==, 0);
ASSERTCMP(atomic_read(_n_rx_skbs), ==, 0);
RE: [PATCH] media: allegro-dvt: Use __packed sentence
From: Emmanuel Arias
> Sent: 29 January 2021 20:02
>
> Fix coding style using __packed sentece instead of
> __attribute__((__packed__)).
>
> Signed-off-by: Emmanuel Arias
> ---
> drivers/staging/media/allegro-dvt/allegro-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/allegro-dvt/allegro-core.c
> b/drivers/staging/media/allegro-
> dvt/allegro-core.c
> index 9f718f43282b..cee624dac61a 100644
> --- a/drivers/staging/media/allegro-dvt/allegro-core.c
> +++ b/drivers/staging/media/allegro-dvt/allegro-core.c
> @@ -670,7 +670,7 @@ static ssize_t allegro_mbox_read(struct allegro_mbox
> *mbox,
> struct {
> u16 length;
> u16 type;
> - } __attribute__ ((__packed__)) *header;
> + } __packed *header;
> struct regmap *sram = mbox->dev->sram;
Does this actually need to be packed?
The only reason would be if the structure could exist on a 2n+1
boundary.
But that is only likely if part of some binary sequence.
In which case I'd expect it to be marked __be or __le.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [PATCH] PCI: quirk for preventing bus reset on TI C667X
On Tue, Jan 26, 2021 at 01:22:18PM +0200, Antti Järvinen wrote: > On 22.1.2021 1.55, Bjorn Helgaas wrote:> > > > It looks like we would probably be trying a Secondary Bus Reset using > > the bridge leading to the C667X. Can you confirm? > > Yes, this is my understanding too. > > > Wonder if you > > could try doing what pci_reset_secondary_bus() does by hand: > > > > I tried this by hand. It looks that result is same as through VFIO. > > # cat sbr.sh > BRIDGE=10:00.0 > C667X=11:00.0 > > setpci -s$C667X VENDOR_ID.w > > VAL=$(setpci -s$BRIDGE BRIDGE_CONTROL.w) > echo $VAL > setpci -s$BRIDGE BRIDGE_CONTROL.w=$(($VAL | 0x40)) > sleep 1 > setpci -s$BRIDGE BRIDGE_CONTROL.w=$VAL > sleep 1 > setpci -s$C667X VENDOR_ID.w=0 > setpci -s$C667X VENDOR_ID.w > > > # ./sbr.sh > 104c > 0003 > > > > > # BRIDGE=... # PCI address, e.g., 00:1c.0 > > # C667X=... > > # setpci -s$C667X VENDOR_ID.w > > # setpci -s$BRIDGE BRIDGE_CONTROL.w # prints "val" > > # setpci -s$BRIDGE BRIDGE_CONTROL.w= # val | 0x40 (set SBR) > > # sleep 1 > > # setpci -s$BRIDGE BRIDGE_CONTROL.w= # val (clear SBR) > > # sleep 1 > > # setpci -s$C667X VENDOR_ID.w=0 > > # setpci -s$C667X VENDOR_ID.w > > > > If we use this quirk and avoid the reset, I assume that means > > assigning the device to VMs with VFIO will leak state between VMs? > > I think this is true. Alex, is there some warning about situations like this where a device may leak state between VMs? There's nothing in quirk_no_bus_reset() itself where we set PCI_DEV_FLAGS_NO_BUS_RESET, and nothing in pci_parent_bus_reset() or pci_dev_reset_slot_function() where we test it, but I didn't chase into VFIO. Seems important enough that we might want to mention it at least once and maybe even every time we try to reset the device. I hope the leak isn't completely silent. Bjorn
Re: [PATCH 1/3] drm/msm: Fix race of GPU init vs timestamp power management.
On Thu, Jan 28, 2021 at 11:17:16AM -0800, Eric Anholt wrote:
> On Thu, Jan 28, 2021 at 10:52 AM Jordan Crouse wrote:
> >
> > On Wed, Jan 27, 2021 at 03:39:44PM -0800, Eric Anholt wrote:
> > > We were using the same force-poweron bit in the two codepaths, so they
> > > could race to have one of them lose GPU power early.
> > >
> > > Signed-off-by: Eric Anholt
> > > Cc: sta...@vger.kernel.org # v5.9
> >
> > You can add:
> > Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
> >
> > Because that was my ugly.
> >
> > Reviewed-by: Jordan Crouse
>
> I only pointed it at 5.9 because it looked like it would probably
> conflict against older branches. I can add the fixes tag if you'd
> like, though.
Fair enough. It is a good bug to fix but not if there are a lot of conflicts to
deal with.
Jordan
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
RE: [PATCH] af_unix: Allow Unix sockets to raise SIGURG
> I'd encourage anyone thinking about "using OOB" to read > https://tools.ietf.org/html/rfc6093 first. Basically, TCP does not > actually provide an OOB mechanism, and frankly Unix sockets shouldn't > try either. OOB data maps much better onto ISO transport 'expedited data' than anything in a bytestream protocol like TCP. There you can send a message (it is message oriented) that isn't subject to normal data flow control. The length is limited (IIRC 32 bytes) and expedited data has its own credit of one, but can overtake (and is expected to overtake) flow control blocked normal data. All TCP provides is a byte sequence number for OOB data. This is just a marker in the bytestream. It really doesn't map onto the socket OOB data data all. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
[PATCH] mm/page_owner: Record the timestamp of all pages during free
Collect the time when each allocation is freed, to help with memory
analysis with kdump/ramdump.
Having another timestamp when we free the page helps for debugging
page migration issues. For example both alloc and free timestamps
being the same can gave hints that there is an issue with migrating
memory, as opposed to a page just being dropped during migration.
Signed-off-by: Georgi Djakov
---
Documentation/vm/page_owner.rst | 2 +-
mm/page_owner.c | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst
index 4e67c2e9bbed..5d7a62c2be28 100644
--- a/Documentation/vm/page_owner.rst
+++ b/Documentation/vm/page_owner.rst
@@ -47,7 +47,7 @@ size change due to this facility.
textdata bss dec hex filename
48800 2445 644 51889cab1 mm/page_alloc.o
- 6574 108 2967111a37 mm/page_owner.o
+ 6644 108 2967771a79 mm/page_owner.o
1025 8 81041 411 mm/page_ext.o
Although, roughly, 8 KB code is added in total, page_alloc.o increase by
diff --git a/mm/page_owner.c b/mm/page_owner.c
index d15c7c4994f5..fbdf064e7494 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -27,6 +27,7 @@ struct page_owner {
depot_stack_handle_t handle;
depot_stack_handle_t free_handle;
u64 ts_nsec;
+ u64 free_ts_nsec;
pid_t pid;
};
@@ -148,6 +149,7 @@ void __reset_page_owner(struct page *page, unsigned int
order)
struct page_ext *page_ext;
depot_stack_handle_t handle = 0;
struct page_owner *page_owner;
+ u64 free_ts_nsec = local_clock();
handle = save_stack(GFP_NOWAIT | __GFP_NOWARN);
@@ -158,6 +160,7 @@ void __reset_page_owner(struct page *page, unsigned int
order)
__clear_bit(PAGE_EXT_OWNER_ALLOCATED, _ext->flags);
page_owner = get_page_owner(page_ext);
page_owner->free_handle = handle;
+ page_owner->free_ts_nsec = free_ts_nsec;
page_ext = page_ext_next(page_ext);
}
}
@@ -177,6 +180,7 @@ static inline void __set_page_owner_handle(struct page
*page,
page_owner->last_migrate_reason = -1;
page_owner->pid = current->pid;
page_owner->ts_nsec = local_clock();
+ page_owner->free_ts_nsec = 0;
__set_bit(PAGE_EXT_OWNER, _ext->flags);
__set_bit(PAGE_EXT_OWNER_ALLOCATED, _ext->flags);
@@ -243,6 +247,7 @@ void __copy_page_owner(struct page *oldpage, struct page
*newpage)
new_page_owner->handle = old_page_owner->handle;
new_page_owner->pid = old_page_owner->pid;
new_page_owner->ts_nsec = old_page_owner->ts_nsec;
+ new_page_owner->free_ts_nsec = old_page_owner->ts_nsec;
/*
* We don't clear the bit on the oldpage as it's going to be freed
Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform
On Thu, Jan 28, 2021 at 9:45 PM Dmitry Baryshkov wrote: > > On 28/01/2021 22:26, Rob Herring wrote: > > On Thu, Jan 28, 2021 at 11:52 AM Dmitry Baryshkov > > wrote: > >> > >> Some Qualcomm platforms require to power up an external device before > >> probing the PCI bus. E.g. on RB5 platform the QCA6390 WiFi/BT chip needs > >> to be powered up before PCIe0 bus is probed. Add a quirk to the > >> respective PCIe root bridge to attach to the power domain if one is > >> required, so that the QCA chip is started before scanning the PCIe bus. > > > > This is solving a generic problem in a specific driver. It needs to be > > solved for any PCI host and any device. > > Ack. I see your point here. > > As this would require porting code from powerpc/spark of-pci code and > changing pcie port driver to apply power supply before bus probing > happens, I'd also ask for the comments from PCI maintainers. Will that > solution be acceptable to you? Oh good, something exists. :) FYI, there's another similar case needing this that just popped up[1]. Rob [1] https://lore.kernel.org/linux-pci/20210129173057.30288...@coco.lan/
Re: [PATCH] tpm_tis: Add missing start/stop_tpm_chip calls
On 1/29/21 2:49 PM, Jarkko Sakkinen wrote: > On Mon, Jan 25, 2021 at 09:18:46AM -0800, Guenter Roeck wrote: >> Hi Lukasz, >> >> On Sat, Jan 23, 2021 at 02:42:47AM +0100, Lukasz Majczak wrote: >>> There is a missing call to start_tpm_chip before the call to >>> the tpm_get_timeouts() and tpm_tis_probe_irq_single(). As the current >>> approach maight work for tpm2, it fails for tpm1.x - in that case >>> call to tpm_get_timeouts() or tpm_tis_probe_irq_single() tries to >>> transmit TPM commands on a disabled chip what what doesn't succeed >> >> s/what what/what/ > > s/maight/might/ > > Also, would be nice to have the capatalization of acronyms correct > and consistent. E.g. tpm1.x should be rather written as "TPM 1.x > chips". > > It's also incorrect to state that something fails for TPM 1.x chips, > unless you can somehow make a sense that every single TPM 1.x at wild > fails, which probably is not true. > >>> and in turn causes tpm_tis_core_init() to fail. >>> Tested on Samsung Chromebook Pro (Caroline). > > Anyone can tell me what does Caroline mean anyway? > "Caroline" is the code name for Samsung Chromebook Pro. The term "Samsung Chromebook Pro (Caroline)" is quite widely used for this system. Or, alternatively, "Caroline (Samsung Chromebook Pro)". Guenter
Re: [PATCH v6 2/2] Kbuild: implement support for DWARF v5
On Fri, Jan 29, 2021 at 3:25 PM Nick Desaulniers
wrote:
>
> On Fri, Jan 29, 2021 at 2:10 PM Jakub Jelinek wrote:
> >
> > On Fri, Jan 29, 2021 at 02:05:59PM -0800, Nick Desaulniers wrote:
> > > Ah, I see. Then I should update the script I add
> > > (scripts/test_dwarf5_support.sh) to feature detect that bug, since
> > > it's the latest of the bunch. Also, should update my comment to note
> > > that this requires binutils greater than 2.35.1 (which is what I have,
> > > which fails, since the backport landed in ... what?!) How was this
> > > backported to 2.35
> > > (https://sourceware.org/bugzilla/show_bug.cgi?id=27195#c12, Jan 26
> > > 2021) when binutils-2_35_1 was tagged sept 19 2020? Or will there be
> > > a binutils 2.35.2 point release?
> >
> > AFAIK yes, soon.
>
> Err...perhaps https://sourceware.org/bugzilla/show_bug.cgi?id=27195
> was about `.file 0`, but it looks like `.file 1 "filename" md5
> 0x7a0b65214090b6693bd1dc24dd248245` without -gdwarf-5. Specifically
> the md5 ... .
>
> So https://sourceware.org/bugzilla/show_bug.cgi?id=25611 needs a rework
> perhaps?
$ echo '.file 1 "filename" md5 0x7a0b65214090b6693bd1dc24dd248245' |
binutils-gdb/gas/as -
{standard input}: Assembler messages:
{standard input}:1: Error: junk at end of line, first unrecognized
character is `m'
$ echo '.file 1 "filename" md5 0x7a0b65214090b6693bd1dc24dd248245' |
binutils-gdb/gas/as -gdwarf-5 -
$
https://sourceware.org/bugzilla/show_bug.cgi?id=27280
--
Thanks,
~Nick Desaulniers
Re: [PATCH v4] certs: Add EFI_CERT_X509_GUID support for dbx entries
On Wed, Jan 27, 2021 at 09:03:59AM -0500, Mimi Zohar wrote: > [Cc'ing linux-integrity] > > On Wed, 2021-01-27 at 11:46 +, David Howells wrote: > > Jarkko Sakkinen wrote: > > > > > > I suppose a user space tool could be created. But wouldn’t what is > > > > currently done in the kernel in this area need to be removed? > > > > > > Right. I don't think this was a great idea in the first place to > > > do to the kernel but since it exists, I guess the patch does make > > > sense. > > > > This information needs to be loaded from the UEFI tables before the system > > starts loading any kernel modules or running any programs (if we do > > verification of such, which I think IMA can do). > > There needs to a clear distinction between the pre-boot and post-boot > keys. UEFI has its own trust model, which should be limited to UEFI. > The .platform keyring was upstreamed and limited to verifying the kexec > kernel image. Any other usage of the .platform keyring keys is > abusing its intended purpose. > > The cover letter says, "Anytime the .platform keyring is used, the > keys in the .blacklist keyring are referenced, if a matching key is > found, the key will be rejected." I don't have a problem with loading > the UEFI X509 dbx entries as long as its usage is limited to verifying > the kexec kernel image. > > Mimi Thanks Mimi, this is a valid argument. I agree. /Jarkko
[RESEND PATCH net v4] udp: ipv4: manipulate network header of NATed UDP GRO fraglist
UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
forwarding. Only the header of head_skb from ip_finish_output_gso ->
skb_gso_segment is updated but following frag_skbs are not updated.
A call path skb_mac_gso_segment -> inet_gso_segment ->
udp4_ufo_fragment -> __udp_gso_segment -> __udp_gso_segment_list
does not try to update UDP/IP header of the segment list but copy
only the MAC header.
Update port, addr and check of each skb of the segment list in
__udp_gso_segment_list. It covers both SNAT and DNAT.
Fixes: 9fd1ff5d2ac7 (udp: Support UDP fraglist GRO/GSO.)
Signed-off-by: Dongseok Yi
Acked-by: Steffen Klassert
---
v1:
Steffen Klassert said, there could be 2 options.
https://lore.kernel.org/patchwork/patch/1362257/
I was trying to write a quick fix, but it was not easy to forward
segmented list. Currently, assuming DNAT only.
v2:
Per Steffen Klassert request, moved the procedure from
udp4_ufo_fragment to __udp_gso_segment_list and support SNAT.
v3:
Per Steffen Klassert request, applied fast return by comparing seg
and seg->next at the beginning of __udpv4_gso_segment_list_csum.
Fixed uh->dest = *newport and iph->daddr = *newip to
*oldport = *newport and *oldip = *newip.
v4:
Clear "Changes Requested" mark in
https://patchwork.kernel.org/project/netdevbpf
Simplified the return statement in __udp_gso_segment_list.
include/net/udp.h | 2 +-
net/ipv4/udp_offload.c | 69 ++
net/ipv6/udp_offload.c | 2 +-
3 files changed, 66 insertions(+), 7 deletions(-)
diff --git a/include/net/udp.h b/include/net/udp.h
index 877832b..01351ba 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -178,7 +178,7 @@ struct sk_buff *udp_gro_receive(struct list_head *head,
struct sk_buff *skb,
int udp_gro_complete(struct sk_buff *skb, int nhoff, udp_lookup_t lookup);
struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
- netdev_features_t features);
+ netdev_features_t features, bool is_ipv6);
static inline struct udphdr *udp_gro_udphdr(struct sk_buff *skb)
{
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index ff39e94..cfc8726 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -187,8 +187,67 @@ struct sk_buff *skb_udp_tunnel_segment(struct sk_buff *skb,
}
EXPORT_SYMBOL(skb_udp_tunnel_segment);
+static void __udpv4_gso_segment_csum(struct sk_buff *seg,
+__be32 *oldip, __be32 *newip,
+__be16 *oldport, __be16 *newport)
+{
+ struct udphdr *uh;
+ struct iphdr *iph;
+
+ if (*oldip == *newip && *oldport == *newport)
+ return;
+
+ uh = udp_hdr(seg);
+ iph = ip_hdr(seg);
+
+ if (uh->check) {
+ inet_proto_csum_replace4(>check, seg, *oldip, *newip,
+true);
+ inet_proto_csum_replace2(>check, seg, *oldport, *newport,
+false);
+ if (!uh->check)
+ uh->check = CSUM_MANGLED_0;
+ }
+ *oldport = *newport;
+
+ csum_replace4(>check, *oldip, *newip);
+ *oldip = *newip;
+}
+
+static struct sk_buff *__udpv4_gso_segment_list_csum(struct sk_buff *segs)
+{
+ struct sk_buff *seg;
+ struct udphdr *uh, *uh2;
+ struct iphdr *iph, *iph2;
+
+ seg = segs;
+ uh = udp_hdr(seg);
+ iph = ip_hdr(seg);
+
+ if ((udp_hdr(seg)->dest == udp_hdr(seg->next)->dest) &&
+ (udp_hdr(seg)->source == udp_hdr(seg->next)->source) &&
+ (ip_hdr(seg)->daddr == ip_hdr(seg->next)->daddr) &&
+ (ip_hdr(seg)->saddr == ip_hdr(seg->next)->saddr))
+ return segs;
+
+ while ((seg = seg->next)) {
+ uh2 = udp_hdr(seg);
+ iph2 = ip_hdr(seg);
+
+ __udpv4_gso_segment_csum(seg,
+>saddr, >saddr,
+>source, >source);
+ __udpv4_gso_segment_csum(seg,
+>daddr, >daddr,
+>dest, >dest);
+ }
+
+ return segs;
+}
+
static struct sk_buff *__udp_gso_segment_list(struct sk_buff *skb,
- netdev_features_t features)
+ netdev_features_t features,
+ bool is_ipv6)
{
unsigned int mss = skb_shinfo(skb)->gso_size;
@@ -198,11 +257,11 @@ static struct sk_buff *__udp_gso_segment_list(struct
sk_buff *skb,
udp_hdr(skb)->len = htons(sizeof(struct udphdr) + mss);
- return skb;
+ return is_ipv6 ? skb : __udpv4_gso_segment_list_csum(skb);
}
struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
- netdev_features_t features)
+
Re: [PATCH v6 2/2] Kbuild: implement support for DWARF v5
On Fri, Jan 29, 2021 at 2:10 PM Jakub Jelinek wrote: > > On Fri, Jan 29, 2021 at 02:05:59PM -0800, Nick Desaulniers wrote: > > Ah, I see. Then I should update the script I add > > (scripts/test_dwarf5_support.sh) to feature detect that bug, since > > it's the latest of the bunch. Also, should update my comment to note > > that this requires binutils greater than 2.35.1 (which is what I have, > > which fails, since the backport landed in ... what?!) How was this > > backported to 2.35 > > (https://sourceware.org/bugzilla/show_bug.cgi?id=27195#c12, Jan 26 > > 2021) when binutils-2_35_1 was tagged sept 19 2020? Or will there be > > a binutils 2.35.2 point release? > > AFAIK yes, soon. Err...perhaps https://sourceware.org/bugzilla/show_bug.cgi?id=27195 was about `.file 0`, but it looks like `.file 1 "filename" md5 0x7a0b65214090b6693bd1dc24dd248245` without -gdwarf-5. Specifically the md5 ... . So https://sourceware.org/bugzilla/show_bug.cgi?id=25611 needs a rework perhaps? -- Thanks, ~Nick Desaulniers
