* [PATCH nvmem v2 1/2] nvmem: imx: add i.MX8QM platform support
From: fugang.duan @ 2019-08-07 4:03 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: mark.rutland, robh, festevam, fugang.duan, devicetree, gregkh,
s.hauer, linux-kernel, kernel, shawnguo, linux-arm-kernel
In-Reply-To: <20190807040320.1760-1-fugang.duan@nxp.com>
From: Fugang Duan <fugang.duan@nxp.com>
i.MX8QM efuse table has some difference with i.MX8QXP platform,
so add i.MX8QM platform support.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
drivers/nvmem/imx-ocotp-scu.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
index be2f5f0..0d78ab4 100644
--- a/drivers/nvmem/imx-ocotp-scu.c
+++ b/drivers/nvmem/imx-ocotp-scu.c
@@ -16,6 +16,7 @@
enum ocotp_devtype {
IMX8QXP,
+ IMX8QM,
};
struct ocotp_devtype_data {
@@ -39,6 +40,11 @@ static struct ocotp_devtype_data imx8qxp_data = {
.nregs = 800,
};
+static struct ocotp_devtype_data imx8qm_data = {
+ .devtype = IMX8QM,
+ .nregs = 800,
+};
+
static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
u32 *val)
{
@@ -118,6 +124,7 @@ static struct nvmem_config imx_scu_ocotp_nvmem_config = {
static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
{ .compatible = "fsl,imx8qxp-scu-ocotp", (void *)&imx8qxp_data },
+ { .compatible = "fsl,imx8qm-scu-ocotp", (void *)&imx8qm_data },
{ },
};
MODULE_DEVICE_TABLE(of, imx_scu_ocotp_dt_ids);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH nvmem v2 0/2] nvmem: imx: add i.MX8QM platform support
From: fugang.duan @ 2019-08-07 4:03 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: mark.rutland, robh, festevam, fugang.duan, devicetree, gregkh,
s.hauer, linux-kernel, kernel, shawnguo, linux-arm-kernel
From: Fugang Duan <fugang.duan@nxp.com>
The patch set is to add i.MX8QM platform support for i.MX8 SCU
OCOTP driver due to i.MX8QM efuse table has some difference with
i.MX8QXP platform.
V2:
- Add dt-bindings for the new compatible string support.
Fugang Duan (2):
nvmem: imx: add i.MX8QM platform support
dt-bindings: fsl: scu: add new compatible string for ocotp
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 4 +++-
drivers/nvmem/imx-ocotp-scu.c | 7 +++++++
2 files changed, 10 insertions(+), 1 deletion(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 1/1] i2c: iproc: Add i2c repeated start capability
From: Rayagonda Kokatanur @ 2019-08-07 4:09 UTC (permalink / raw)
To: Wolfram Sang, Rob Herring, Mark Rutland
Cc: devicetree, Lori Hikichi, Florian Fainelli, Shivaraj Shetty,
Rayagonda Kokatanur, linux-kernel, Icarus Chau, Ray Jui,
linux-i2c, bcm-kernel-feedback-list, linux-arm-kernel
From: Lori Hikichi <lori.hikichi@broadcom.com>
Enable handling of i2c repeated start. The current code
handles a multi msg i2c transfer as separate i2c bus
transactions. This change will now handle this case
using the i2c repeated start protocol. The number of msgs
in a transfer is limited to two, and must be a write
followed by a read.
Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Signed-off-by: Icarus Chau <icarus.chau@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Shivaraj Shetty <sshetty1@broadcom.com>
---
drivers/i2c/busses/i2c-bcm-iproc.c | 70 +++++++++++++++++++++++++++++++-------
1 file changed, 57 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
index d7fd76b..15fedcf 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -81,6 +81,7 @@
#define M_CMD_PROTOCOL_MASK 0xf
#define M_CMD_PROTOCOL_BLK_WR 0x7
#define M_CMD_PROTOCOL_BLK_RD 0x8
+#define M_CMD_PROTOCOL_PROCESS 0xa
#define M_CMD_PEC_SHIFT 8
#define M_CMD_RD_CNT_SHIFT 0
#define M_CMD_RD_CNT_MASK 0xff
@@ -675,13 +676,20 @@ static int bcm_iproc_i2c_xfer_wait(struct bcm_iproc_i2c_dev *iproc_i2c,
return 0;
}
-static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
- struct i2c_msg *msg)
+/*
+ * If 'process_call' is true, then this is a multi-msg transfer that requires
+ * a repeated start between the messages.
+ * More specifically, it must be a write (reg) followed by a read (data).
+ * The i2c quirks are set to enforce this rule.
+ */
+static int bcm_iproc_i2c_xfer_internal(struct bcm_iproc_i2c_dev *iproc_i2c,
+ struct i2c_msg *msgs, bool process_call)
{
int i;
u8 addr;
u32 val, tmp, val_intr_en;
unsigned int tx_bytes;
+ struct i2c_msg *msg = &msgs[0];
/* check if bus is busy */
if (!!(iproc_i2c_rd_reg(iproc_i2c,
@@ -707,14 +715,29 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
val = msg->buf[i];
/* mark the last byte */
- if (i == msg->len - 1)
- val |= BIT(M_TX_WR_STATUS_SHIFT);
+ if (!process_call && (i == msg->len - 1))
+ val |= 1 << M_TX_WR_STATUS_SHIFT;
iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
}
iproc_i2c->tx_bytes = tx_bytes;
}
+ /* Process the read message if this is process call */
+ if (process_call) {
+ msg++;
+ iproc_i2c->msg = msg; /* point to second msg */
+
+ /*
+ * The last byte to be sent out should be a slave
+ * address with read operation
+ */
+ addr = msg->addr << 1 | 1;
+ /* mark it the last byte out */
+ val = addr | (1 << M_TX_WR_STATUS_SHIFT);
+ iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
+ }
+
/* mark as incomplete before starting the transaction */
if (iproc_i2c->irq)
reinit_completion(&iproc_i2c->done);
@@ -733,7 +756,7 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
* underrun interrupt, which will be triggerred when the TX FIFO is
* empty. When that happens we can then pump more data into the FIFO
*/
- if (!(msg->flags & I2C_M_RD) &&
+ if (!process_call && !(msg->flags & I2C_M_RD) &&
msg->len > iproc_i2c->tx_bytes)
val_intr_en |= BIT(IE_M_TX_UNDERRUN_SHIFT);
@@ -743,6 +766,8 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
*/
val = BIT(M_CMD_START_BUSY_SHIFT);
if (msg->flags & I2C_M_RD) {
+ u32 protocol;
+
iproc_i2c->rx_bytes = 0;
if (msg->len > M_RX_FIFO_MAX_THLD_VALUE)
iproc_i2c->thld_bytes = M_RX_FIFO_THLD_VALUE;
@@ -758,7 +783,10 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
/* enable the RX threshold interrupt */
val_intr_en |= BIT(IE_M_RX_THLD_SHIFT);
- val |= (M_CMD_PROTOCOL_BLK_RD << M_CMD_PROTOCOL_SHIFT) |
+ protocol = process_call ?
+ M_CMD_PROTOCOL_PROCESS : M_CMD_PROTOCOL_BLK_RD;
+
+ val |= (protocol << M_CMD_PROTOCOL_SHIFT) |
(msg->len << M_CMD_RD_CNT_SHIFT);
} else {
val |= (M_CMD_PROTOCOL_BLK_WR << M_CMD_PROTOCOL_SHIFT);
@@ -774,17 +802,31 @@ static int bcm_iproc_i2c_xfer(struct i2c_adapter *adapter,
struct i2c_msg msgs[], int num)
{
struct bcm_iproc_i2c_dev *iproc_i2c = i2c_get_adapdata(adapter);
- int ret, i;
+ bool process_call = false;
+ int ret;
- /* go through all messages */
- for (i = 0; i < num; i++) {
- ret = bcm_iproc_i2c_xfer_single_msg(iproc_i2c, &msgs[i]);
- if (ret) {
- dev_dbg(iproc_i2c->device, "xfer failed\n");
- return ret;
+ if (num > 2) {
+ dev_err(iproc_i2c->device,
+ "Only support up to 2 messages. Current msg count %d\n",
+ num);
+ return -EOPNOTSUPP;
+ }
+
+ if (num == 2) {
+ /* Repeated start, use process call */
+ process_call = true;
+ if (msgs[1].flags & I2C_M_NOSTART) {
+ dev_err(iproc_i2c->device, "Invalid repeated start\n");
+ return -EOPNOTSUPP;
}
}
+ ret = bcm_iproc_i2c_xfer_internal(iproc_i2c, msgs, process_call);
+ if (ret) {
+ dev_dbg(iproc_i2c->device, "xfer failed\n");
+ return ret;
+ }
+
return num;
}
@@ -806,6 +848,8 @@ static uint32_t bcm_iproc_i2c_functionality(struct i2c_adapter *adap)
};
static struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
+ .flags = I2C_AQ_COMB_WRITE_THEN_READ,
+ .max_comb_1st_msg_len = M_TX_RX_FIFO_SIZE,
.max_read_len = M_RX_MAX_READ_LEN,
};
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
From: Alex Deucher @ 2019-08-07 4:03 UTC (permalink / raw)
To: Tao Zhou
Cc: linux-arm-kernel, kernel-build-reports, amd-gfx list, Mark Brown,
Linux-Next Mailing List, Deucher, Alexander, Andrew Morton,
Christian Koenig, Dennis Li, Hawking Zhang
In-Reply-To: <20190807025640.682-1-tao.zhou1@amd.com>
On Tue, Aug 6, 2019 at 10:56 PM Tao Zhou <tao.zhou1@amd.com> wrote:
>
> readq/writeq are not supported on all architectures
>
> Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 558fe6d091ed..7eb9e0b9235a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -272,14 +272,10 @@ void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
> */
> uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
> {
> - uint64_t ret;
> -
> if ((reg * 4) < adev->rmmio_size)
> - ret = readq(((void __iomem *)adev->rmmio) + (reg * 4));
> + return atomic64_read((atomic64_t *)(adev->rmmio + (reg * 4)));
> else
> BUG();
> -
> - return ret;
> }
>
> /**
> @@ -294,7 +290,7 @@ uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
> void amdgpu_mm_wreg64(struct amdgpu_device *adev, uint32_t reg, uint64_t v)
> {
> if ((reg * 4) < adev->rmmio_size)
> - writeq(v, ((void __iomem *)adev->rmmio) + (reg * 4));
> + atomic64_set((atomic64_t *)(adev->rmmio + (reg * 4)), v);
> else
> BUG();
> }
> --
> 2.17.1
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
From: Alex Deucher @ 2019-08-07 4:02 UTC (permalink / raw)
To: Jisheng Zhang
Cc: kernel-build-reports@lists.linaro.org, broonie@kernel.org,
Tao Zhou, amd-gfx@lists.freedesktop.org,
linux-next@vger.kernel.org, dennis.li@amd.com,
alexander.deucher@amd.com, akpm@linux-foundation.org,
christian.koenig@amd.com, linux-arm-kernel@lists.infradead.org,
hawking.zhang@amd.com
In-Reply-To: <20190807105759.58a28ef0@xhacker.debian>
On Tue, Aug 6, 2019 at 11:31 PM Jisheng Zhang
<Jisheng.Zhang@synaptics.com> wrote:
>
> On Wed, 7 Aug 2019 10:56:40 +0800 Tao Zhou wrote:
>
>
> >
> >
> > readq/writeq are not supported on all architectures
> >
> > Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++------
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index 558fe6d091ed..7eb9e0b9235a 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -272,14 +272,10 @@ void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
> > */
> > uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
> > {
> > - uint64_t ret;
> > -
> > if ((reg * 4) < adev->rmmio_size)
> > - ret = readq(((void __iomem *)adev->rmmio) + (reg * 4));
> > + return atomic64_read((atomic64_t *)(adev->rmmio + (reg * 4)));
>
> atomic64_read doesn't equal to readq on some architectures..
What we really wanted originally was atomic64. We basically want a
read or write that is guaranteed to be 64 bits at a time.
Alex
>
> > else
> > BUG();
> > -
> > - return ret;
> > }
> >
> > /**
> > @@ -294,7 +290,7 @@ uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
> > void amdgpu_mm_wreg64(struct amdgpu_device *adev, uint32_t reg, uint64_t v)
> > {
> > if ((reg * 4) < adev->rmmio_size)
> > - writeq(v, ((void __iomem *)adev->rmmio) + (reg * 4));
> > + atomic64_set((atomic64_t *)(adev->rmmio + (reg * 4)), v);
> > else
> > BUG();
> > }
> > --
> > 2.17.1
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 1/3] perf: Add capability-related utilities
From: Lubashev, Igor @ 2019-08-07 3:58 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Jiri Olsa
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra,
linux-kernel@vger.kernel.org, James Morris, Alexander Shishkin,
Ingo Molnar, Namhyung Kim, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190717234652.GJ3624@kernel.org>
On Wed, July 17 at 2019 7:47 PM Arnaldo Carvalho de Melo wrote:
> Em Wed, Jul 17, 2019 at 06:05:51PM -0300, Arnaldo Carvalho de Melo
> escreveu:
> > Em Tue, Jul 16, 2019 at 10:46:43AM +0200, Jiri Olsa escreveu:
> > > On Tue, Jul 02, 2019 at 08:10:03PM -0400, Igor Lubashev wrote:
> > > > Add utilities to help checking capabilities of the running process.
> > > > Make perf link with libcap.
> > > >
> > > > Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
> > > > ---
> > > > tools/perf/Makefile.config | 2 +-
> > > > tools/perf/util/Build | 1 +
> > > > tools/perf/util/cap.c | 24 ++++++++++++++++++++++++
> > > > tools/perf/util/cap.h | 10 ++++++++++
> > > > tools/perf/util/event.h | 1 +
> > > > tools/perf/util/python-ext-sources | 1 +
> > > > tools/perf/util/util.c | 9 +++++++++
> > > > 7 files changed, 47 insertions(+), 1 deletion(-) create mode
> > > > 100644 tools/perf/util/cap.c create mode 100644
> > > > tools/perf/util/cap.h
> > > >
> > > > diff --git a/tools/perf/Makefile.config
> > > > b/tools/perf/Makefile.config index 85fbcd265351..21470a50ed39
> > > > 100644
> > > > --- a/tools/perf/Makefile.config
> > > > +++ b/tools/perf/Makefile.config
> > > > @@ -259,7 +259,7 @@ CXXFLAGS += -Wno-strict-aliasing # adding
> > > > assembler files missing the .GNU-stack linker note.
> > > > LDFLAGS += -Wl,-z,noexecstack
> > > >
> > > > -EXTLIBS = -lpthread -lrt -lm -ldl
> > > > +EXTLIBS = -lpthread -lrt -lm -ldl -lcap
> > >
> > > I wonder we should detect libcap or it's everywhere.. Arnaldo's
> > > compile test suite might tell
> >
> > I'll add this tentatively and try to build it in my test suite.
>
> So, not even in my notebook this worked straight away:
>
> CC /tmp/build/perf/util/cap.o
> CC /tmp/build/perf/util/config.o
> In file included from util/cap.c:5:
> util/cap.h:6:10: fatal error: sys/capability.h: No such file or directory
> 6 | #include <sys/capability.h>
> | ^~~~~~~~~~~~~~~~~~
> compilation terminated.
> mv: cannot stat '/tmp/build/perf/util/.cap.o.tmp': No such file or directory
>
>
> I had to first do:
>
> dnf install libcap-devel
>
> So we need to have a feature test and fail if that is not installed, i.e. libcap
> becomes a hard req for building perf, which I think is reasonable, one more
> shouldn't hurt, right?
>
> With all the features enabled:
>
> [acme@quaco perf]$ ldd ~/bin/perf
> linux-vdso.so.1 (0x00007ffe7278a000)
> libunwind-x86_64.so.8 => /lib64/libunwind-x86_64.so.8
> (0x00007f7be52f1000)
> libunwind.so.8 => /lib64/libunwind.so.8 (0x00007f7be52d7000)
> liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f7be52ae000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7be528d000)
> librt.so.1 => /lib64/librt.so.1 (0x00007f7be5283000)
> libm.so.6 => /lib64/libm.so.6 (0x00007f7be513d000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f7be5135000)
> libcap.so.2 => /lib64/libcap.so.2 (0x00007f7be512e000)
> libelf.so.1 => /lib64/libelf.so.1 (0x00007f7be5113000)
> libdw.so.1 => /lib64/libdw.so.1 (0x00007f7be50c0000)
> libslang.so.2 => /lib64/libslang.so.2 (0x00007f7be4de8000)
> libperl.so.5.28 => /lib64/libperl.so.5.28 (0x00007f7be4ac2000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f7be48fa000)
> libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0
> (0x00007f7be4690000)
> libz.so.1 => /lib64/libz.so.1 (0x00007f7be4676000)
> libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f7be45d1000)
> libnuma.so.1 => /lib64/libnuma.so.1 (0x00007f7be45c3000)
> libbabeltrace-ctf.so.1 => /lib64/libbabeltrace-ctf.so.1
> (0x00007f7be456d000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7be4551000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f7be5331000)
> libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f7be453d000)
> libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f7be4502000)
> libutil.so.1 => /lib64/libutil.so.1 (0x00007f7be44fd000)
> libbabeltrace.so.1 => /lib64/libbabeltrace.so.1
> (0x00007f7be44ed000)
> libpopt.so.0 => /lib64/libpopt.so.0 (0x00007f7be44dd000)
> libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f7be44d3000)
> libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0
> (0x00007f7be44cd000)
> libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f7be43a9000)
> libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f7be4335000)
> [acme@quaco perf]$
>
> ;-)
>
> So, please check tools/build/feature/ and check how this is done and add a
> test and the warning in tools/perf/Makefile.config so that we get an error
> message stating that libcap-dev or libcap-devel should be installed.
I have just posted v2 of the series (https://lkml.kernel.org/lkml/cover.1565146171.git.ilubashe@akamai.com).
Instead of making libcap is "hard req", I made it as "soft" one. We can still build a useful tool w/o libcap. It will just have to assume that perf is running with no capabilities, since we cannot query them.
Many thanks for the pointers on how to go about build feature checking.
- Igor
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [PATCH nvmem 1/1] nvmem: imx: add i.MX8QM platform support
From: Andy Duan @ 2019-08-07 3:50 UTC (permalink / raw)
To: Srinivas Kandagatla, shawnguo@kernel.org, s.hauer@pengutronix.de
Cc: gregkh@linuxfoundation.org, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
linux-kernel@vger.kernel.org
In-Reply-To: <65afeaaf-f703-02f2-a918-90a8bb8f58b6@linaro.org>
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Sent: Tuesday, August 6, 2019 6:04 PM
> On 04/07/2019 15:20, fugang.duan@nxp.com wrote:
> > From: Fugang Duan <fugang.duan@nxp.com>
> >
> > i.MX8QM efuse table has some difference with i.MX8QXP platform, so add
> > i.MX8QM platform support.
> >
> > Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
> > ---
> > drivers/nvmem/imx-ocotp-scu.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/nvmem/imx-ocotp-scu.c
> > b/drivers/nvmem/imx-ocotp-scu.c index be2f5f0..0d78ab4 100644
> > --- a/drivers/nvmem/imx-ocotp-scu.c
> > +++ b/drivers/nvmem/imx-ocotp-scu.c
> > @@ -16,6 +16,7 @@
> >
> > enum ocotp_devtype {
> > IMX8QXP,
> > + IMX8QM,
> > };
> >
> > struct ocotp_devtype_data {
> > @@ -39,6 +40,11 @@ static struct ocotp_devtype_data imx8qxp_data = {
> > .nregs = 800,
> > };
> >
> > +static struct ocotp_devtype_data imx8qm_data = {
> > + .devtype = IMX8QM,
> > + .nregs = 800,
> > +};
> > +
> > static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
> > u32 *val)
> > {
> > @@ -118,6 +124,7 @@ static struct nvmem_config
> > imx_scu_ocotp_nvmem_config = {
> >
> > static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
> > { .compatible = "fsl,imx8qxp-scu-ocotp", (void *)&imx8qxp_data
> > },
> > + { .compatible = "fsl,imx8qm-scu-ocotp", (void *)&imx8qm_data },
> > { },
>
> Looks like you forgot to add this new compatible to device tree bindings
> at ./Documentation/devicetree/bindings/nvmem/imx-ocotp.txt or forgot to
> add me to CC.
>
> Please resend the patch with it, I can not apply this as it is.
>
> Thanks,
> srini
There have no separated binding documentation for imx-ocotp-scu.c driver.
It is reasonable to add the new compatible string on below binding file "fsl,scu.txt":
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
>
> > };
> > MODULE_DEVICE_TABLE(of, imx_scu_ocotp_dt_ids);
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 4/4] perf: Use CAP_SYS_ADMIN instead of euid==0 with ftrace
From: Igor Lubashev @ 2019-08-07 3:35 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
In-Reply-To: <cover.1565146171.git.ilubashe@akamai.com>
Kernel requires CAP_SYS_ADMIN instead of euid==0 to mount debugfs for ftrace.
Make perf do the same.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/perf/builtin-ftrace.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
index ae1466aa3b26..d09eac8a6d57 100644
--- a/tools/perf/builtin-ftrace.c
+++ b/tools/perf/builtin-ftrace.c
@@ -13,6 +13,7 @@
#include <signal.h>
#include <fcntl.h>
#include <poll.h>
+#include <linux/capability.h>
#include "debug.h"
#include <subcmd/parse-options.h>
@@ -21,6 +22,7 @@
#include "target.h"
#include "cpumap.h"
#include "thread_map.h"
+#include "util/cap.h"
#include "util/config.h"
@@ -281,7 +283,7 @@ static int __cmd_ftrace(struct perf_ftrace *ftrace, int argc, const char **argv)
.events = POLLIN,
};
- if (geteuid() != 0) {
+ if (!perf_cap__capable(CAP_SYS_ADMIN)) {
pr_err("ftrace only works for root!\n");
return -1;
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/4] perf: Add capability-related utilities
From: Igor Lubashev @ 2019-08-07 3:35 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
In-Reply-To: <cover.1565146171.git.ilubashe@akamai.com>
Add utilities to help checking capabilities of the running procss.
Make perf link with libcap, if it is available. If no libcap-dev[el],
assume no capabilities.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/build/Makefile.feature | 2 ++
tools/build/feature/Makefile | 4 ++++
tools/build/feature/test-libcap.c | 20 ++++++++++++++++++++
tools/perf/Makefile.config | 11 +++++++++++
tools/perf/Makefile.perf | 2 ++
tools/perf/util/Build | 2 ++
tools/perf/util/cap.c | 29 +++++++++++++++++++++++++++++
tools/perf/util/cap.h | 24 ++++++++++++++++++++++++
tools/perf/util/event.h | 1 +
tools/perf/util/python-ext-sources | 1 +
tools/perf/util/util.c | 9 +++++++++
11 files changed, 105 insertions(+)
create mode 100644 tools/build/feature/test-libcap.c
create mode 100644 tools/perf/util/cap.c
create mode 100644 tools/perf/util/cap.h
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 86b793dffbc4..8a19753cc26a 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -42,6 +42,7 @@ FEATURE_TESTS_BASIC := \
gtk2-infobar \
libaudit \
libbfd \
+ libcap \
libelf \
libelf-getphdrnum \
libelf-gelf_getnote \
@@ -110,6 +111,7 @@ FEATURE_DISPLAY ?= \
gtk2 \
libaudit \
libbfd \
+ libcap \
libelf \
libnuma \
numa_num_possible_cpus \
diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 0658b8cd0e53..8499385365c0 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -20,6 +20,7 @@ FILES= \
test-libbfd-liberty.bin \
test-libbfd-liberty-z.bin \
test-cplus-demangle.bin \
+ test-libcap.bin \
test-libelf.bin \
test-libelf-getphdrnum.bin \
test-libelf-gelf_getnote.bin \
@@ -105,6 +106,9 @@ $(OUTPUT)test-fortify-source.bin:
$(OUTPUT)test-bionic.bin:
$(BUILD)
+$(OUTPUT)test-libcap.bin:
+ $(BUILD) -lcap
+
$(OUTPUT)test-libelf.bin:
$(BUILD) -lelf
diff --git a/tools/build/feature/test-libcap.c b/tools/build/feature/test-libcap.c
new file mode 100644
index 000000000000..d2a2e152195f
--- /dev/null
+++ b/tools/build/feature/test-libcap.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <sys/capability.h>
+#include <linux/capability.h>
+
+int main(void)
+{
+ cap_flag_value_t val;
+ cap_t caps = cap_get_proc();
+
+ if (!caps)
+ return 1;
+
+ if (cap_get_flag(caps, CAP_SYS_ADMIN, CAP_EFFECTIVE, &val) != 0)
+ return 1;
+
+ if (cap_free(caps) != 0)
+ return 1;
+
+ return 0;
+}
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index e4988f49ea79..9a06787fedc6 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -824,6 +824,17 @@ ifndef NO_LIBZSTD
endif
endif
+ifndef NO_LIBCAP
+ ifeq ($(feature-libcap), 1)
+ CFLAGS += -DHAVE_LIBCAP_SUPPORT
+ EXTLIBS += -lcap
+ $(call detected,CONFIG_LIBCAP)
+ else
+ msg := $(warning No libcap found, disables capability support, please install libcap-devel/libcap-dev);
+ NO_LIBCAP := 1
+ endif
+endif
+
ifndef NO_BACKTRACE
ifeq ($(feature-backtrace), 1)
CFLAGS += -DHAVE_BACKTRACE_SUPPORT
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 67512a12276b..f9807d8c005b 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -88,6 +88,8 @@ include ../scripts/utilities.mak
#
# Define NO_LIBBPF if you do not want BPF support
#
+# Define NO_LIBCAP if you do not want process capabilities considered by perf
+#
# Define NO_SDT if you do not want to define SDT event in perf tools,
# note that it doesn't disable SDT scanning support.
#
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 7abf05131889..7cda749059a9 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -148,6 +148,8 @@ perf-$(CONFIG_ZLIB) += zlib.o
perf-$(CONFIG_LZMA) += lzma.o
perf-$(CONFIG_ZSTD) += zstd.o
+perf-$(CONFIG_LIBCAP) += cap.o
+
perf-y += demangle-java.o
perf-y += demangle-rust.o
diff --git a/tools/perf/util/cap.c b/tools/perf/util/cap.c
new file mode 100644
index 000000000000..c3ba841bbf37
--- /dev/null
+++ b/tools/perf/util/cap.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Capability utilities
+ */
+
+#ifdef HAVE_LIBCAP_SUPPORT
+
+#include "cap.h"
+#include <stdbool.h>
+#include <sys/capability.h>
+
+bool perf_cap__capable(cap_value_t cap)
+{
+ cap_flag_value_t val;
+ cap_t caps = cap_get_proc();
+
+ if (!caps)
+ return false;
+
+ if (cap_get_flag(caps, cap, CAP_EFFECTIVE, &val) != 0)
+ val = CAP_CLEAR;
+
+ if (cap_free(caps) != 0)
+ return false;
+
+ return val == CAP_SET;
+}
+
+#endif /* HAVE_LIBCAP_SUPPORT */
diff --git a/tools/perf/util/cap.h b/tools/perf/util/cap.h
new file mode 100644
index 000000000000..514b1f8992f6
--- /dev/null
+++ b/tools/perf/util/cap.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __PERF_CAP_H
+#define __PERF_CAP_H
+
+#include <stdbool.h>
+#include <linux/capability.h>
+#include <linux/compiler.h>
+
+#ifdef HAVE_LIBCAP_SUPPORT
+
+#include <sys/capability.h>
+
+bool perf_cap__capable(cap_value_t cap);
+
+#else
+
+static inline bool perf_cap__capable(int cap __maybe_unused)
+{
+ return false;
+}
+
+#endif /* HAVE_LIBCAP_SUPPORT */
+
+#endif /* __PERF_CAP_H */
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 70841d115349..0e164e8ae28d 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -851,6 +851,7 @@ void cpu_map_data__synthesize(struct cpu_map_data *data, struct perf_cpu_map *m
void event_attr_init(struct perf_event_attr *attr);
int perf_event_paranoid(void);
+bool perf_event_paranoid_check(int max_level);
extern int sysctl_perf_event_max_stack;
extern int sysctl_perf_event_max_contexts_per_stack;
diff --git a/tools/perf/util/python-ext-sources b/tools/perf/util/python-ext-sources
index 235bd9803390..c6dd478956f1 100644
--- a/tools/perf/util/python-ext-sources
+++ b/tools/perf/util/python-ext-sources
@@ -7,6 +7,7 @@
util/python.c
../lib/ctype.c
+util/cap.c
util/evlist.c
util/evsel.c
util/cpumap.c
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 9c3c97697387..6fd130a5d8f2 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -16,10 +16,12 @@
#include <string.h>
#include <errno.h>
#include <limits.h>
+#include <linux/capability.h>
#include <linux/kernel.h>
#include <linux/log2.h>
#include <linux/time64.h>
#include <unistd.h>
+#include "cap.h"
#include "strlist.h"
#include "string2.h"
@@ -403,6 +405,13 @@ int perf_event_paranoid(void)
return value;
}
+
+bool perf_event_paranoid_check(int max_level)
+{
+ return perf_cap__capable(CAP_SYS_ADMIN) ||
+ perf_event_paranoid() <= max_level;
+}
+
static int
fetch_ubuntu_kernel_version(unsigned int *puint)
{
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
From: Igor Lubashev @ 2019-08-07 3:35 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
In-Reply-To: <cover.1565146171.git.ilubashe@akamai.com>
Kernel is using CAP_SYSLOG capability instead of uid==0 and euid==0 when
checking kptr_restrict. Make perf do the same.
Also, the kernel is a more restrictive than "no restrictions" in case of
kptr_restrict==0, so add the same logic to perf.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/perf/util/symbol.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 173f3378aaa0..046271103499 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -4,6 +4,7 @@
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
+#include <linux/capability.h>
#include <linux/kernel.h>
#include <linux/mman.h>
#include <linux/time64.h>
@@ -15,8 +16,10 @@
#include <inttypes.h>
#include "annotate.h"
#include "build-id.h"
+#include "cap.h"
#include "util.h"
#include "debug.h"
+#include "event.h"
#include "machine.h"
#include "map.h"
#include "symbol.h"
@@ -890,7 +893,11 @@ bool symbol__restricted_filename(const char *filename,
{
bool restricted = false;
- if (symbol_conf.kptr_restrict) {
+ /* Per kernel/kallsyms.c:
+ * we also restrict when perf_event_paranoid > 1 w/o CAP_SYSLOG
+ */
+ if (symbol_conf.kptr_restrict ||
+ (perf_event_paranoid() > 1 && !perf_cap__capable(CAP_SYSLOG))) {
char *r = realpath(filename, NULL);
if (r != NULL) {
@@ -2190,9 +2197,9 @@ static bool symbol__read_kptr_restrict(void)
char line[8];
if (fgets(line, sizeof(line), fp) != NULL)
- value = ((geteuid() != 0) || (getuid() != 0)) ?
- (atoi(line) != 0) :
- (atoi(line) == 2);
+ value = perf_cap__capable(CAP_SYSLOG) ?
+ (atoi(line) >= 2) :
+ (atoi(line) != 0);
fclose(fp);
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/4] perf: Use capabilities instead of uid and euid
From: Igor Lubashev @ 2019-08-07 3:35 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
Series v1: https://lkml.kernel.org/lkml/1562112605-6235-1-git-send-email-ilubashe@akamai.com
Kernel is using capabilities instead of uid and euid to restrict access to
kernel pointers and tracing facilities. This patch series updates the perf to
better match the security model used by the kernel.
This series enables instructions in Documentation/admin-guide/perf-security.rst
to actually work, even when kernel.perf_event_paranoid=2 and
kernel.kptr_restrict=1.
The series consists of four patches:
01: perf: Add capability-related utilities
Add utility functions to check capabilities and perf_event_paranoid checks,
if libcap-dev[el] is available. (Otherwise, assume no capabilities.)
02: perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks
Replace the use of euid==0 with a check for CAP_SYS_ADMIN whenever
perf_event_paranoid level is verified.
03: perf: Use CAP_SYSLOG with kptr_restrict checks
Replace the use of uid and euid with a check for CAP_SYSLOG when
kptr_restrict is verified (similar to kernel/kallsyms.c and lib/vsprintf.c).
Consult perf_event_paranoid when kptr_restrict==0 (see kernel/kallsyms.c).
04: perf: Use CAP_SYS_ADMIN instead of euid==0 with ftrace
Replace the use of euid==0 with a check for CAP_SYS_ADMIN before mounting
debugfs for ftrace.
I tested this by following Documentation/admin-guide/perf-security.rst
guidelines and setting sysctls:
kernel.perf_event_paranoid=2
kernel.kptr_restrict=1
As an unpriviledged user who is in perf_users group (setup via instructions
above), I executed:
perf record -a -- sleep 1
Without the patch, perf record did not capture any kernel functions.
With the patch, perf included all kernel funcitons.
Changelog:
v2: * Added a build feature check for libcap-dev[el] as suggested by Arnaldo
Igor Lubashev (4):
perf: Add capability-related utilities
perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks
perf: Use CAP_SYSLOG with kptr_restrict checks
perf: Use CAP_SYS_ADMIN instead of euid==0 with ftrace
tools/build/Makefile.feature | 2 ++
tools/build/feature/Makefile | 4 ++++
tools/build/feature/test-libcap.c | 20 ++++++++++++++++++++
tools/perf/Makefile.config | 11 +++++++++++
tools/perf/Makefile.perf | 2 ++
tools/perf/arch/arm/util/cs-etm.c | 3 ++-
tools/perf/arch/arm64/util/arm-spe.c | 4 ++--
tools/perf/arch/x86/util/intel-bts.c | 3 ++-
tools/perf/arch/x86/util/intel-pt.c | 2 +-
tools/perf/builtin-ftrace.c | 4 +++-
tools/perf/util/Build | 2 ++
tools/perf/util/cap.c | 29 +++++++++++++++++++++++++++++
tools/perf/util/cap.h | 24 ++++++++++++++++++++++++
tools/perf/util/event.h | 1 +
tools/perf/util/evsel.c | 2 +-
tools/perf/util/python-ext-sources | 1 +
tools/perf/util/symbol.c | 15 +++++++++++----
tools/perf/util/util.c | 9 +++++++++
18 files changed, 127 insertions(+), 11 deletions(-)
create mode 100644 tools/build/feature/test-libcap.c
create mode 100644 tools/perf/util/cap.c
create mode 100644 tools/perf/util/cap.h
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/4] perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks
From: Igor Lubashev @ 2019-08-07 3:35 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
In-Reply-To: <cover.1565146171.git.ilubashe@akamai.com>
The kernel is using CAP_SYS_ADMIN instead of euid==0 to override
perf_event_paranoid check. Make perf do the same.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/perf/arch/arm/util/cs-etm.c | 3 ++-
tools/perf/arch/arm64/util/arm-spe.c | 4 ++--
tools/perf/arch/x86/util/intel-bts.c | 3 ++-
tools/perf/arch/x86/util/intel-pt.c | 2 +-
tools/perf/util/evsel.c | 2 +-
5 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c
index 5cb07e8cb296..b87a1ca2968f 100644
--- a/tools/perf/arch/arm/util/cs-etm.c
+++ b/tools/perf/arch/arm/util/cs-etm.c
@@ -18,6 +18,7 @@
#include "../../perf.h"
#include "../../util/auxtrace.h"
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evlist.h"
#include "../../util/evsel.h"
#include "../../util/pmu.h"
@@ -254,7 +255,7 @@ static int cs_etm_recording_options(struct auxtrace_record *itr,
struct perf_pmu *cs_etm_pmu = ptr->cs_etm_pmu;
struct evsel *evsel, *cs_etm_evsel = NULL;
struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = (geteuid() == 0 || perf_event_paranoid() < 0);
+ bool privileged = perf_event_paranoid_check(-1);
int err = 0;
ptr->evlist = evlist;
diff --git a/tools/perf/arch/arm64/util/arm-spe.c b/tools/perf/arch/arm64/util/arm-spe.c
index 00915b8fd05b..200bc973371b 100644
--- a/tools/perf/arch/arm64/util/arm-spe.c
+++ b/tools/perf/arch/arm64/util/arm-spe.c
@@ -12,6 +12,7 @@
#include <time.h>
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evsel.h"
#include "../../util/evlist.h"
#include "../../util/session.h"
@@ -65,8 +66,7 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
struct arm_spe_recording *sper =
container_of(itr, struct arm_spe_recording, itr);
struct perf_pmu *arm_spe_pmu = sper->arm_spe_pmu;
- struct evsel *evsel, *arm_spe_evsel = NULL;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
struct evsel *tracking_evsel;
int err;
diff --git a/tools/perf/arch/x86/util/intel-bts.c b/tools/perf/arch/x86/util/intel-bts.c
index 7b23318ebd7b..56a76142e9fd 100644
--- a/tools/perf/arch/x86/util/intel-bts.c
+++ b/tools/perf/arch/x86/util/intel-bts.c
@@ -12,6 +12,7 @@
#include <linux/zalloc.h>
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evsel.h"
#include "../../util/evlist.h"
#include "../../util/session.h"
@@ -107,7 +108,7 @@ static int intel_bts_recording_options(struct auxtrace_record *itr,
struct perf_pmu *intel_bts_pmu = btsr->intel_bts_pmu;
struct evsel *evsel, *intel_bts_evsel = NULL;
const struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
btsr->evlist = evlist;
btsr->snapshot_mode = opts->auxtrace_snapshot_mode;
diff --git a/tools/perf/arch/x86/util/intel-pt.c b/tools/perf/arch/x86/util/intel-pt.c
index 218a4e694618..43d5088ee824 100644
--- a/tools/perf/arch/x86/util/intel-pt.c
+++ b/tools/perf/arch/x86/util/intel-pt.c
@@ -558,7 +558,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
bool have_timing_info, need_immediate = false;
struct evsel *evsel, *intel_pt_evsel = NULL;
const struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
u64 tsc_bit;
int err;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 64bc32ed6dfa..eafc134bf17c 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -279,7 +279,7 @@ struct evsel *perf_evsel__new_idx(struct perf_event_attr *attr, int idx)
static bool perf_event_can_profile_kernel(void)
{
- return geteuid() == 0 || perf_event_paranoid() == -1;
+ return perf_event_paranoid_check(-1);
}
struct evsel *perf_evsel__new_cycles(bool precise)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
From: Jisheng Zhang @ 2019-08-07 3:09 UTC (permalink / raw)
To: Tao Zhou
Cc: linux-arm-kernel@lists.infradead.org,
kernel-build-reports@lists.linaro.org,
amd-gfx@lists.freedesktop.org, broonie@kernel.org,
linux-next@vger.kernel.org, alexander.deucher@amd.com,
akpm@linux-foundation.org, christian.koenig@amd.com,
dennis.li@amd.com, hawking.zhang@amd.com
In-Reply-To: <20190807025640.682-1-tao.zhou1@amd.com>
On Wed, 7 Aug 2019 10:56:40 +0800 Tao Zhou wrote:
>
>
> readq/writeq are not supported on all architectures
>
> Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 558fe6d091ed..7eb9e0b9235a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -272,14 +272,10 @@ void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
> */
> uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
> {
> - uint64_t ret;
> -
> if ((reg * 4) < adev->rmmio_size)
> - ret = readq(((void __iomem *)adev->rmmio) + (reg * 4));
> + return atomic64_read((atomic64_t *)(adev->rmmio + (reg * 4)));
atomic64_read doesn't equal to readq on some architectures..
> else
> BUG();
> -
> - return ret;
> }
>
> /**
> @@ -294,7 +290,7 @@ uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
> void amdgpu_mm_wreg64(struct amdgpu_device *adev, uint32_t reg, uint64_t v)
> {
> if ((reg * 4) < adev->rmmio_size)
> - writeq(v, ((void __iomem *)adev->rmmio) + (reg * 4));
> + atomic64_set((atomic64_t *)(adev->rmmio + (reg * 4)), v);
> else
> BUG();
> }
> --
> 2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
From: Tao Zhou @ 2019-08-07 2:56 UTC (permalink / raw)
To: amd-gfx, alexander.deucher, hawking.zhang, dennis.li, broonie,
akpm, christian.koenig
Cc: Tao Zhou, linux-next, linux-arm-kernel, kernel-build-reports
readq/writeq are not supported on all architectures
Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 558fe6d091ed..7eb9e0b9235a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -272,14 +272,10 @@ void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
*/
uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
{
- uint64_t ret;
-
if ((reg * 4) < adev->rmmio_size)
- ret = readq(((void __iomem *)adev->rmmio) + (reg * 4));
+ return atomic64_read((atomic64_t *)(adev->rmmio + (reg * 4)));
else
BUG();
-
- return ret;
}
/**
@@ -294,7 +290,7 @@ uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
void amdgpu_mm_wreg64(struct amdgpu_device *adev, uint32_t reg, uint64_t v)
{
if ((reg * 4) < adev->rmmio_size)
- writeq(v, ((void __iomem *)adev->rmmio) + (reg * 4));
+ atomic64_set((atomic64_t *)(adev->rmmio + (reg * 4)), v);
else
BUG();
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] xilinx_sdfec: Convert to IDA
From: Matthew Wilcox @ 2019-08-07 2:50 UTC (permalink / raw)
To: Michal Simek
Cc: linux-arm-kernel, Greg Kroah-Hartman, Arnd Bergmann,
Matthew Wilcox (Oracle), linux-kernel
From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
This driver does not use the lookup abilities of the IDR, so convert it
to the more space-efficient IDA.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
drivers/misc/xilinx_sdfec.c | 25 ++++++-------------------
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index f257d3812110..071b26a8c6a9 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -22,8 +22,7 @@
#define DEV_NAME_LEN 12
-static struct idr dev_idr;
-static struct mutex dev_idr_lock;
+static DEFINE_IDA(dev_nrs);
/**
* struct xsdfec_clks - For managing SD-FEC clocks
@@ -227,13 +226,6 @@ static void xsdfec_disable_all_clks(struct xsdfec_clks *clks)
clk_disable_unprepare(clks->axi_clk);
}
-static void xsdfec_idr_remove(struct xsdfec_dev *xsdfec)
-{
- mutex_lock(&dev_idr_lock);
- idr_remove(&dev_idr, xsdfec->dev_id);
- mutex_unlock(&dev_idr_lock);
-}
-
static int xsdfec_probe(struct platform_device *pdev)
{
struct xsdfec_dev *xsdfec;
@@ -263,9 +255,7 @@ static int xsdfec_probe(struct platform_device *pdev)
/* Save driver private data */
platform_set_drvdata(pdev, xsdfec);
- mutex_lock(&dev_idr_lock);
- err = idr_alloc(&dev_idr, xsdfec->dev_name, 0, 0, GFP_KERNEL);
- mutex_unlock(&dev_idr_lock);
+ err = ida_alloc(&dev_nrs, GFP_KERNEL);
if (err < 0)
goto err_xsdfec_dev;
xsdfec->dev_id = err;
@@ -278,12 +268,12 @@ static int xsdfec_probe(struct platform_device *pdev)
err = misc_register(&xsdfec->miscdev);
if (err) {
dev_err(dev, "error:%d. Unable to register device", err);
- goto err_xsdfec_idr;
+ goto err_xsdfec_ida;
}
return 0;
-err_xsdfec_idr:
- xsdfec_idr_remove(xsdfec);
+err_xsdfec_ida:
+ ida_free(&dev_nrs, xsdfec->dev_id);
err_xsdfec_dev:
xsdfec_disable_all_clks(&xsdfec->clks);
return err;
@@ -295,7 +285,7 @@ static int xsdfec_remove(struct platform_device *pdev)
xsdfec = platform_get_drvdata(pdev);
misc_deregister(&xsdfec->miscdev);
- xsdfec_idr_remove(xsdfec);
+ ida_free(&dev_nrs, xsdfec->dev_id);
xsdfec_disable_all_clks(&xsdfec->clks);
return 0;
}
@@ -321,8 +311,6 @@ static int __init xsdfec_init(void)
{
int err;
- mutex_init(&dev_idr_lock);
- idr_init(&dev_idr);
err = platform_driver_register(&xsdfec_driver);
if (err < 0) {
pr_err("%s Unabled to register SDFEC driver", __func__);
@@ -334,7 +322,6 @@ static int __init xsdfec_init(void)
static void __exit xsdfec_exit(void)
{
platform_driver_unregister(&xsdfec_driver);
- idr_destroy(&dev_idr);
}
module_init(xsdfec_init);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arm64: dts: allwinner: a64: Drop PMU node
From: Vasily Khoruzhick @ 2019-08-07 2:39 UTC (permalink / raw)
To: Robin Murphy
Cc: Mark Rutland, devicetree, Jared D . McNeill, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Harald Geyer, arm-linux
In-Reply-To: <36e60078-7dd5-9c07-ffa1-6092d8c70fa8@arm.com>
On Tue, Aug 6, 2019 at 2:14 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2019-08-06 9:52 pm, Vasily Khoruzhick wrote:
> > On Tue, Aug 6, 2019 at 1:19 PM Harald Geyer <harald@ccbib.org> wrote:
> >>
> >> Vasily Khoruzhick writes:
> >>> On Tue, Aug 6, 2019 at 7:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
> >>>>
> >>>> On 06/08/2019 15:01, Vasily Khoruzhick wrote:
> >>>>> Looks like PMU in A64 is broken, it generates no interrupts at all and
> >>>>> as result 'perf top' shows no events.
> >>>>
> >>>> Does something like 'perf stat sleep 1' at least count cycles correctly?
> >>>> It could well just be that the interrupt numbers are wrong...
> >>>
> >>> Looks like it does, at least result looks plausible:
> >>
> >> I'm using perf stat regularly (cache benchmarks) and it works fine.
> >>
> >> Unfortunately I wasn't aware that perf stat is a poor test for
> >> the interrupts part of the node, when I added it. So I'm not too
> >> surprised I got it wrong.
> >>
> >> However, it would be unfortunate if the node got removed completely,
> >> because perf stat would not work anymore. Maybe we can only remove
> >> the interrupts or just fix them even if the HW doesn't work?
> >
> > I'm not familiar with PMU driver. Is it possible to get it working
> > without interrupts?
>
> Yup - you get a grumpy message from the driver, it will refuse sampling
> events (the ones which weren't working anyway), and if you measure
> anything for long enough that a counter overflows you'll get wonky
> results. But for counting hardware events over relatively short periods
> it'll still do the job.
I tried to drop interrupts completely from the node but 'perf top' is
still broken. Though now in different way: it complains "cycles: PMU
Hardware doesn't support sampling/overflow-interrupts. Try 'perf
stat'"
Is there any way to make it working?
>
> Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] gpio: mpc8xxx: Add new platforms GPIO DT node description
From: Hui Song @ 2019-08-07 2:12 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Mark Rutland, Linus Walleij,
Bartosz Golaszewski
Cc: devicetree, Song Hui, linux-kernel, linux-arm-kernel, linux-gpio
From: Song Hui <hui.song_1@nxp.com>
Update the NXP GPIO node dt-binding file for QorIQ and
Layerscape platforms, and add one more example with
ls1028a GPIO node.
Signed-off-by: Song Hui <hui.song_1@nxp.com>
---
Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
index 69d4616..baf95d9 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
@@ -4,7 +4,7 @@ Required properties:
- compatible : Should be "fsl,<soc>-gpio"
The following <soc>s are known to be supported:
mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq,
- ls1021a, ls1043a, ls2080a.
+ ls1021a, ls1043a, ls2080a, ls1028a.
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all 32 pins.
- #gpio-cells : Should be two. The first cell is the pin number and
@@ -37,3 +37,17 @@ gpio0: gpio@2300000 {
interrupt-controller;
#interrupt-cells = <2>;
};
+
+
+Example of gpio-controller node for a ls1028a SoC:
+
+gpio1: gpio@2300000 {
+ compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
+ reg = <0x0 0x2300000 0x0 0x10000>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ little-endian;
+};
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC,v3 7/9] media: platform: Add Mediatek ISP P1 device driver
From: Jungo Lin @ 2019-08-07 2:11 UTC (permalink / raw)
To: Tomasz Figa
Cc: devicetree, Sean Cheng (鄭昇弘),
Mauro Carvalho Chehab, Rynn Wu (吳育恩),
srv_heupstream, Rob Herring, Ryan Yu (余孟修),
Frankie Chiu (邱文凱), Hans Verkuil,
Matthias Brugger, Sj Huang,
moderated list:ARM/Mediatek SoC support, Laurent Pinchart,
ddavenport, Frederic Chen (陳俊元),
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,,
Linux Media Mailing List
In-Reply-To: <CAAFQd5D5m=gGViSY++r5uUS1+91y9=Gpcss1dEXrin_T07H+uQ@mail.gmail.com>
Hi, Tomasz:
On Tue, 2019-08-06 at 18:47 +0900, Tomasz Figa wrote:
> Hi Jungo,
>
> On Fri, Jul 26, 2019 at 4:24 PM Jungo Lin <jungo.lin@mediatek.com> wrote:
> >
> > Hi, Tomasz:
> >
> > On Thu, 2019-07-25 at 18:23 +0900, Tomasz Figa wrote:
> > > .Hi Jungo,
> > >
> > > On Sat, Jul 20, 2019 at 6:58 PM Jungo Lin <jungo.lin@mediatek.com> wrote:
> > > >
> > > > Hi, Tomasz:
> > > >
> > > > On Wed, 2019-07-10 at 18:56 +0900, Tomasz Figa wrote:
> > > > > Hi Jungo,
> > > > >
> > > > > On Tue, Jun 11, 2019 at 11:53:42AM +0800, Jungo Lin wrote:
> [snip]
I just keep some questions to be clarified.
[snip]
> > > > > > + isp_dev->meta0_vb2_index = meta0_vb2_index;
> > > > > > + isp_dev->meta1_vb2_index = meta1_vb2_index;
> > > > > > + } else {
> > > > > > + if (irq_status & SOF_INT_ST) {
> > > > > > + isp_dev->current_frame = hw_frame_num;
> > > > > > + isp_dev->meta0_vb2_index = meta0_vb2_index;
> > > > > > + isp_dev->meta1_vb2_index = meta1_vb2_index;
> > > > > > + }
> > > > > > + irq_handle_notify_event(isp_dev, irq_status, dma_status, 1);
> > > > > > + }
> > > > >
> > > > > The if and else blocks do almost the same things just in different order. Is
> > > > > it really expected?
> > > > >
> > > >
> > > > If we receive HW_PASS1_DON_ST & SOF_INT_ST IRQ events at the same time,
> > > > the correct sequence should be handle HW_PASS1_DON_ST firstly to check
> > > > any de-queued frame and update the next frame setting later.
> > > > Normally, this is a corner case or system performance issue.
> > >
> > > So it sounds like HW_PASS1_DON_ST means that all data from current
> > > frame has been written, right? If I understand your explanation above
> > > correctly, that would mean following handling of each interrupt:
> > >
> > > HW_PASS1_DON_ST:
> > > - CQ executes with next CQ buffer to prepare for next frame. <- how
> > > is this handled? does the CQ hardware automatically receive this event
> > > from the ISP hadware?
> > > - return VB2 buffers,
> > > - complete requests.
> > >
> > > SOF_INT_ST:
> > > - send VSYNC event to userspace,
> > > - program next CQ buffer to CQ,
> > >
> > > SW_PASS1_DON_ST:
> > > - reclaim CQ buffer and enqueue next frame to composing if available
> > >
> >
> > Sorry for our implementation of HW_PASS1_DON_ST.
> > It is confusing.
> > Below is the revised version based on your conclusion.
> > So in our new implemmenation, we just handle SOF_INT_ST &
> > SW_PASS1_DON_ST events. We just add one warning message for
> > HW_PASS1_DON_ST
> >
> > HW_PASS1_DON_ST:
> > - CQ executes with next CQ buffer to prepare for next frame.
> >
> > SOF_INT_ST:
> > - send VSYNC event to userspace,
> > - program next CQ buffer to CQ,
> >
> > SW_PASS1_DON_ST:
> > - reclaim CQ buffer and enqueue next frame to composing if available
> > - return VB2 buffers,
> > - complete requests.
> >
> > For CQ HW operations, it is listed below:
> >
> > a. The CQ buffer has two kinds of information
> > - Which ISP registers needs to be updated.
> > - Where the corresponding ISP register data to be read.
> > b. The CQ buffer loading procedure is triggered by HW_PASS1_DONT_ST IRQ
> > event periodically.
> > - Normally, if the ISP HW receives the completed frame and it will
> > trigger W_PASS1_DONT_ST IRQ and perform CQ buffer loading immediately.
> > - So the CQ buffer loading is performed by ISP HW automatically.
> > c. The ISP HW will read CQ base address register(REG_CQ_THR0_BASEADDR)
> > to decide which CQ buffer is loaded.
> > - So we configure the next CQ base address in SOF.
> > d. For CQ buffer loading, CQ will read the ISP registers from CQ buffer
> > and update the ISP register values into HW.
> > - SCP composer will compose one dummy CQ buffer and assign it to
> > REG_CQ_THR0_BASEADDR of each CQ buffer.
> > - Dummy CQ buffer has no updated ISP registers comparing with other
> > CQ buffers.
> > - With this design, if there is no updated new CQ buffer by driver
> > which may be caused no en-queue frames from user space. The CQ HW will
> > load dummy CQ buffer and do nothing.
>
> Does the set of registers programmed by CQ include destination buffer
> addresses to? If yes, we would end up overwriting previous frames if
> no new buffers are provided.
>
Yes, the buffer addresses are changed per frame request. We need to
compose CQ to include these DMA destination addresses. For your concern,
we have DMA flow buffer control (FBC) in HW. If there is no FBC counter
increased due to no buffer for each DMA, the ISP HW doesn't output the
data to the corresponding DMA address.
Below is the simple descriptor of CQ buffer.
a. ISP registers in tuning buffer, including 3A registers.
b. All capture buffers informations.
- DMA buffer destination address
- FBC counter
c. Some specif ISP registers for meta DMAs, such as LCE or LMVO.
d. frame sequence number register
> > f. The CQ buffer loading is guaranteed by HW to finish before the next
> > SOF.
> >
>
> Okay, thanks a lot for the explanation. This is much more clear now.
>
> [snip]
> > > > > > +static const struct dev_pm_ops mtk_isp_pm_ops = {
> > > > > > + SET_SYSTEM_SLEEP_PM_OPS(mtk_isp_suspend, mtk_isp_resume)
> > > > > > + SET_RUNTIME_PM_OPS(mtk_isp_suspend, mtk_isp_resume, NULL)
> > > > >
> > > > > For V4L2 drivers system and runtime PM ops would normally be completely
> > > > > different. Runtime PM ops would be called when the hardware is idle already
> > > > > or is about to become active. System PM ops would be called at system power
> > > > > state change and the hardware might be both idle or active. Please also see
> > > > > my comments to mtk_isp_suspend() and mtk_isp_resume() above.
> > > > >
> > > >
> > > > Here is the new implementation. It should be clear to show the
> > > > difference between system and runtime PM ops.
> > > >
> > > > static const struct dev_pm_ops mtk_isp_pm_ops = {
> > > > SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> > > > pm_runtime_force_resume)
> > > > SET_RUNTIME_PM_OPS(mtk_isp_runtime_suspend, mtk_isp_runtime_resume,
> > > > NULL)
> > > > };
> > >
> > > That's still not correct. In runtime suspend/resume ops we already are
> > > not streaming anymore, because we call pm_runtime_get/put_*() when
> > > starting and stopping streaming. In system suspend/resume ops we might
> > > be streaming and that's when we need to stop the hardware and wait for
> > > it to finish. Please implement these ops separately.
> > >
> > > Best regards,
> > > Tomasz
> >
> >
> > Ok, got your point.
> > Below is the new implementation for your review.
> >
> > static int mtk_isp_pm_suspend(struct device *dev)
> > {
> > struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> > u32 val;
> > int ret;
> >
> > dev_dbg(dev, "- %s\n", __func__);
> >
> > /* Check ISP is streaming or not */
> > if (!p1_dev->cam_dev.streaming)
> > goto done;
>
> We would normally check here for pm_runtime_suspended(). Although they
> both should be equivalent. Still, there is no need to call
> pm_runtime_force_suspend() if the latter is true, so we could just
> return 0 instantly.
>
Ok, here is the fixed version.
static int mtk_isp_pm_suspend(struct device *dev)
{
struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
u32 val;
int ret;
dev_dbg(dev, "- %s\n", __func__);
if (pm_runtime_suspended(dev))
return 0;
/* Disable ISP's view finder and wait for TG idle */
dev_dbg(dev, "cam suspend, disable VF\n");
val = readl(p1_dev->regs + REG_TG_VF_CON);
writel(val & (~TG_VF_CON_VFDATA_EN), p1_dev->regs + REG_TG_VF_CON);
ret = readl_poll_timeout_atomic(p1_dev->regs + REG_TG_INTER_ST, val,
(val & TG_CS_MASK) == TG_IDLE_ST,
USEC_PER_MSEC, MTK_ISP_STOP_HW_TIMEOUT);
if (ret)
dev_warn(dev, "can't stop HW:%d:0x%x\n", ret, val);
/* Disable CMOS */
val = readl(p1_dev->regs + REG_TG_SEN_MODE);
writel(val & (~TG_SEN_MODE_CMOS_EN), p1_dev->regs + REG_TG_SEN_MODE);
/* Force ISP HW to idle */
ret = pm_runtime_force_suspend(dev);
if (ret)
return ret;
return 0;
}
[snip]
> > static int mtk_isp_pm_resume(struct device *dev)
> > {
> > struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> > u32 val;
> > int ret;
> >
> > dev_dbg(dev, "- %s\n", __func__);
> >
> > /* Force ISP HW to resume if needed */
> > ret = pm_runtime_force_resume(dev);
> > if (ret)
> > return ret;
>
> We should do this conditionally based on what pm_runtime_suspended()
> returns. If it's non-zero then we can just return 0 instantly.
>
Ok, here is the fixed version.
static int mtk_isp_pm_resume(struct device *dev)
{
struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
u32 val;
int ret;
dev_dbg(dev, "- %s\n", __func__);
if (pm_runtime_suspended(dev))
return 0;
/* Force ISP HW to resume */
ret = pm_runtime_force_resume(dev);
if (ret)
return ret;
/* Enable CMOS */
dev_dbg(dev, "cam resume, enable CMOS/VF\n");
val = readl(p1_dev->regs + REG_TG_SEN_MODE);
writel(val | TG_SEN_MODE_CMOS_EN, p1_dev->regs + REG_TG_SEN_MODE);
/* Enable VF */
val = readl(p1_dev->regs + REG_TG_VF_CON);
writel(val | TG_VF_CON_VFDATA_EN, p1_dev->regs + REG_TG_VF_CON);
return 0;
}
[snip]
> > static int mtk_isp_runtime_suspend(struct device *dev)
> > {
> > struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> >
> > dev_dbg(dev, "- %s\n", __func__);
> >
> > if (pm_runtime_suspended(dev))
> > return 0;
>
> Sorry, I guess I wasn't clear in my reply. It's not possible to get
> this callback called if the device is already runtime suspended.
>
Ok, got it. Need to remove pm_runtime_suspended(dev) checking and move
it into mtk_isp_pm_* functions. If I still don't get your point, could
you kindly provide one sample driver for reference? Based on current
implementation, it is similar to below drivers.
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-mdp/mtk_mdp_core.c#L255
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/exynos4-is/fimc-is-i2c.c#L113
static int mtk_isp_runtime_suspend(struct device *dev)
{
struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
dev_dbg(dev, "%s:disable clock\n", __func__);
clk_bulk_disable_unprepare(p1_dev->num_clks, p1_dev->clks);
return 0;
}
[snip]
> > static int mtk_isp_runtime_resume(struct device *dev)
> > {
> > struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> > int ret;
> >
> > dev_dbg(dev, "- %s\n", __func__);
> >
> > if (pm_runtime_suspended(dev))
> > return 0;
>
> In this case the above call would always return non-zero, so the
> behavior wouldn't be very good.
>
Same as above.
static int mtk_isp_runtime_resume(struct device *dev)
{
struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
int ret;
dev_dbg(dev, "%s:enable clock\n", __func__);
ret = clk_bulk_prepare_enable(p1_dev->num_clks, p1_dev->clks);
if (ret) {
dev_err(dev, "failed to enable clock:%d\n", ret);
return ret;
}
return 0;
}
Thanks for your further comments on these issues.
Best regards,
Jugno
> Best regards,
> Tomasz
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: "of/platform: Pause/resume sync state during init and of_platform_populate()" with a warning on arm64
From: Qian Cai @ 2019-08-07 1:56 UTC (permalink / raw)
To: Saravana Kannan
Cc: Greg Kroah-Hartman, Rob Herring, Linux List Kernel Mailing,
linux-arm-kernel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CAGETcx_KZNMY1Zs=G=HGPfsUA4Fen_m8R4L9jNHtWrZerabwxg@mail.gmail.com>
> On Aug 6, 2019, at 9:50 PM, Saravana Kannan <saravanak@google.com> wrote:
>
> Thanks for confirming. I didn't think ARM64 could even boot without
> DT. I'll send a fix right away.
>
> Any chance you can let us know what device this was tested on?
It is a HPE Apollo 70 arm64 server.
https://h20195.www2.hpe.com/v2/gethtml.aspx?docname=a00039978enw
>
> -Saravana
>
>
>
> -Saravana
>
> On Tue, Aug 6, 2019 at 6:46 PM Qian Cai <cai@lca.pw> wrote:
>>
>>
>>
>>> On Aug 6, 2019, at 9:22 PM, Saravana Kannan <saravanak@google.com> wrote:
>>>
>>> On Tue, Aug 6, 2019 at 5:46 PM Qian Cai <cai@lca.pw> wrote:
>>>>
>>>> It looks like the linux-next commit “of/platform: Pause/resume sync state during init and of_platform_populate()” [1]
>>>> Introduced a warning while booting arm64.
>>>>
>>>> [1] https://lore.kernel.org/lkml/20190731221721.187713-6-saravanak@google.com/
>>>>
>>>> [ 93.449300][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: ias 44-bit, oas 44-bit (features 0x0000170d)
>>>> [ 93.464873][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries for cmdq
>>>> [ 93.485481][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries for evtq
>>>> [ 93.496320][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: option mask 0x2
>>>> [ 93.502917][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: ias 44-bit, oas 44-bit (features 0x0000170d)
>>>> [ 93.621818][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries for cmdq
>>>> [ 93.643000][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries for evtq
>>>> [ 94.519445][ T1] libphy: Fixed MDIO Bus: probed
>>>> [ 94.524649][ T1] EFI Variables Facility v0.08 2004-May-17
>>>> [ 94.601166][ T1] NET: Registered protocol family 17
>>>> [ 94.766008][ T1] zswap: loaded using pool lzo/zbud
>>>> [ 94.774745][ T1] kmemleak: Kernel memory leak detector initialized (mempool size: 16384)
>>>> [ 94.774756][ T1699] kmemleak: Automatic memory scanning thread started
>>>> [ 94.812338][ T1368] pcieport 0000:0f:00.0: Adding to iommu group 0
>>>> [ 94.984466][ T1] ------------[ cut here ]------------
>>>> [ 94.989827][ T1] Unmatched sync_state pause/resume!
>>>> [ 94.989894][ T1] WARNING: CPU: 25 PID: 1 at drivers/base/core.c:691 device_links_supplier_sync_state_resume+0x100/0x128
>>>> [ 95.006062][ T1] Modules linked in:
>>>> [ 95.009815][ T1] CPU: 25 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc3-next-20190806+ #11
>>>> [ 95.018161][ T1] Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019
>>>> [ 95.028593][ T1] pstate: 60400009 (nZCv daif +PAN -UAO)
>>>> [ 95.034077][ T1] pc : device_links_supplier_sync_state_resume+0x100/0x128
>>>> [ 95.041124][ T1] lr : device_links_supplier_sync_state_resume+0x100/0x128
>>>> [ 95.048167][ T1] sp : 34ff800806e6fbc0
>>>> [ 95.052172][ T1] x29: 34ff800806e6fc00 x28: 0000000000000000
>>>> [ 95.058177][ T1] x27: 0000000000000000 x26: 0000000000000000
>>>> [ 95.064181][ T1] x25: 0000000000000038 x24: 0000000000000000
>>>> [ 95.070185][ T1] x23: 0000000000000000 x22: 0000000000000019
>>>> [ 95.076189][ T1] x21: 0000000000000000 x20: f9ff808b804e6c50
>>>> [ 95.082193][ T1] x19: ffff100014a6e600 x18: 0000000000000040
>>>> [ 95.088197][ T1] x17: 0000000000000000 x16: 86ff80099d581b50
>>>> [ 95.094201][ T1] x15: 0000000000000000 x14: ffff100010086d1c
>>>> [ 95.100205][ T1] x13: ffff1000109d8688 x12: ffffffffffffffff
>>>> [ 95.106209][ T1] x11: 00000000000000f9 x10: ffff0808b804e6c6
>>>> [ 95.112213][ T1] x9 : 4b71ad522c851d00 x8 : 4b71ad522c851d00
>>>> [ 95.118217][ T1] x7 : 6170206574617473 x6 : ffff100014076972
>>>> [ 95.124221][ T1] x5 : 34ff800806e6f8f0 x4 : 000000000000000f
>>>> [ 95.130225][ T1] x3 : ffff1000101bfa5c x2 : 0000000000000001
>>>> [ 95.136229][ T1] x1 : 0000000000000001 x0 : 0000000000000022
>>>> [ 95.142233][ T1] Call trace:
>>>> [ 95.145374][ T1] device_links_supplier_sync_state_resume+0x100/0x128
>>>> [ 95.152074][ T1] of_platform_sync_state_init+0x10/0x1c
>>>> [ 95.157557][ T1] do_one_initcall+0x2f8/0x600
>>>> [ 95.162172][ T1] do_initcall_level+0x37c/0x3fc
>>>> [ 95.166959][ T1] do_basic_setup+0x34/0x4c
>>>> [ 95.171313][ T1] kernel_init_freeable+0x188/0x24c
>>>> [ 95.176363][ T1] kernel_init+0x18/0x334
>>>> [ 95.180543][ T1] ret_from_fork+0x10/0x18
>>>> [ 95.184809][ T1] ---[ end trace a9ea68c902540fe5 ]---
>>>> [ 95.269085][ T1] Freeing unused kernel memory: 28672K
>>>> [ 101.069860][ T1] Checked W+X mappings: passed, no W+X pages found
>>>> [ 101.076265][ T1] Run /init as init process
>>>> [ 101.186359][ T1] systemd[1]: System time before build time, advancing clock.
>>>
>>>
>>> I tested it again on my device (on an older kernel) and I don't see
>>> this warning. Is this on an ARM64 target without a populated DT?
>>
>> Probably, /sys/firmware/devicetree is all empty.
>>
>>> That's the only thing I can see that could cause this warning.
>>>
>>> This is literally the code with the matching pause/resume. I can't
>>> think of any other way the pause/resume could have ended up not
>>> matching.
>>>
>>> static int __init of_platform_default_populate_init(void)
>>> {
>>> struct device_node *node;
>>>
>>> if (!of_have_populated_dt())
>>> return -ENODEV;
>>>
>>> platform_bus_type.add_links = of_link_to_suppliers;
>>> device_links_supplier_sync_state_pause(); <=========== PAUSE
>>> /*
>>> * Handle certain compatibles explicitly, since we don't want to create
>>> * platform_devices for every node in /reserved-memory with a
>>> * "compatible",
>>> */
>>> for_each_matching_node(node, reserved_mem_matches)
>>> of_platform_device_create(node, NULL, NULL);
>>>
>>> node = of_find_node_by_path("/firmware");
>>> if (node) {
>>> of_platform_populate(node, NULL, NULL, NULL);
>>> of_node_put(node);
>>> }
>>>
>>> /* Populate everything else. */
>>> of_platform_default_populate(NULL, NULL, NULL);
>>>
>>> return 0;
>>> }
>>> arch_initcall_sync(of_platform_default_populate_init);
>>>
>>> static int __init of_platform_sync_state_init(void)
>>> {
>>> device_links_supplier_sync_state_resume(); <========= RESUME
>>> return 0;
>>> }
>>> late_initcall_sync(of_platform_sync_state_init);
>>>
>>> Thanks,
>>> Saravana
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [PATCH nvmem 1/1] nvmem: imx: add i.MX8QM platform support
From: Andy Duan @ 2019-08-07 1:50 UTC (permalink / raw)
To: Srinivas Kandagatla, shawnguo@kernel.org, s.hauer@pengutronix.de
Cc: gregkh@linuxfoundation.org, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
linux-kernel@vger.kernel.org
In-Reply-To: <65afeaaf-f703-02f2-a918-90a8bb8f58b6@linaro.org>
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Sent: Tuesday, August 6, 2019 6:04 PM
> On 04/07/2019 15:20, fugang.duan@nxp.com wrote:
> > From: Fugang Duan <fugang.duan@nxp.com>
> >
> > i.MX8QM efuse table has some difference with i.MX8QXP platform, so add
> > i.MX8QM platform support.
> >
> > Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
> > ---
> > drivers/nvmem/imx-ocotp-scu.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/nvmem/imx-ocotp-scu.c
> > b/drivers/nvmem/imx-ocotp-scu.c index be2f5f0..0d78ab4 100644
> > --- a/drivers/nvmem/imx-ocotp-scu.c
> > +++ b/drivers/nvmem/imx-ocotp-scu.c
> > @@ -16,6 +16,7 @@
> >
> > enum ocotp_devtype {
> > IMX8QXP,
> > + IMX8QM,
> > };
> >
> > struct ocotp_devtype_data {
> > @@ -39,6 +40,11 @@ static struct ocotp_devtype_data imx8qxp_data = {
> > .nregs = 800,
> > };
> >
> > +static struct ocotp_devtype_data imx8qm_data = {
> > + .devtype = IMX8QM,
> > + .nregs = 800,
> > +};
> > +
> > static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
> > u32 *val)
> > {
> > @@ -118,6 +124,7 @@ static struct nvmem_config
> > imx_scu_ocotp_nvmem_config = {
> >
> > static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
> > { .compatible = "fsl,imx8qxp-scu-ocotp", (void *)&imx8qxp_data
> > },
> > + { .compatible = "fsl,imx8qm-scu-ocotp", (void *)&imx8qm_data },
> > { },
>
> Looks like you forgot to add this new compatible to device tree bindings
> at ./Documentation/devicetree/bindings/nvmem/imx-ocotp.txt or forgot to
> add me to CC.
>
> Please resend the patch with it, I can not apply this as it is.
>
> Thanks,
> srini
Thanks for your review.
I will send the V2 version including the separated device tree bindings patch.
>
> > };
> > MODULE_DEVICE_TABLE(of, imx_scu_ocotp_dt_ids);
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: "of/platform: Pause/resume sync state during init and of_platform_populate()" with a warning on arm64
From: Saravana Kannan @ 2019-08-07 1:50 UTC (permalink / raw)
To: Qian Cai
Cc: Greg Kroah-Hartman, Rob Herring, Linux List Kernel Mailing,
linux-arm-kernel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <6326D2D1-8641-48D1-BDD5-4F4B8BADB286@lca.pw>
Thanks for confirming. I didn't think ARM64 could even boot without
DT. I'll send a fix right away.
Any chance you can let us know what device this was tested on?
-Saravana
-Saravana
On Tue, Aug 6, 2019 at 6:46 PM Qian Cai <cai@lca.pw> wrote:
>
>
>
> > On Aug 6, 2019, at 9:22 PM, Saravana Kannan <saravanak@google.com> wrote:
> >
> > On Tue, Aug 6, 2019 at 5:46 PM Qian Cai <cai@lca.pw> wrote:
> >>
> >> It looks like the linux-next commit “of/platform: Pause/resume sync state during init and of_platform_populate()” [1]
> >> Introduced a warning while booting arm64.
> >>
> >> [1] https://lore.kernel.org/lkml/20190731221721.187713-6-saravanak@google.com/
> >>
> >> [ 93.449300][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: ias 44-bit, oas 44-bit (features 0x0000170d)
> >> [ 93.464873][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries for cmdq
> >> [ 93.485481][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries for evtq
> >> [ 93.496320][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: option mask 0x2
> >> [ 93.502917][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: ias 44-bit, oas 44-bit (features 0x0000170d)
> >> [ 93.621818][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries for cmdq
> >> [ 93.643000][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries for evtq
> >> [ 94.519445][ T1] libphy: Fixed MDIO Bus: probed
> >> [ 94.524649][ T1] EFI Variables Facility v0.08 2004-May-17
> >> [ 94.601166][ T1] NET: Registered protocol family 17
> >> [ 94.766008][ T1] zswap: loaded using pool lzo/zbud
> >> [ 94.774745][ T1] kmemleak: Kernel memory leak detector initialized (mempool size: 16384)
> >> [ 94.774756][ T1699] kmemleak: Automatic memory scanning thread started
> >> [ 94.812338][ T1368] pcieport 0000:0f:00.0: Adding to iommu group 0
> >> [ 94.984466][ T1] ------------[ cut here ]------------
> >> [ 94.989827][ T1] Unmatched sync_state pause/resume!
> >> [ 94.989894][ T1] WARNING: CPU: 25 PID: 1 at drivers/base/core.c:691 device_links_supplier_sync_state_resume+0x100/0x128
> >> [ 95.006062][ T1] Modules linked in:
> >> [ 95.009815][ T1] CPU: 25 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc3-next-20190806+ #11
> >> [ 95.018161][ T1] Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019
> >> [ 95.028593][ T1] pstate: 60400009 (nZCv daif +PAN -UAO)
> >> [ 95.034077][ T1] pc : device_links_supplier_sync_state_resume+0x100/0x128
> >> [ 95.041124][ T1] lr : device_links_supplier_sync_state_resume+0x100/0x128
> >> [ 95.048167][ T1] sp : 34ff800806e6fbc0
> >> [ 95.052172][ T1] x29: 34ff800806e6fc00 x28: 0000000000000000
> >> [ 95.058177][ T1] x27: 0000000000000000 x26: 0000000000000000
> >> [ 95.064181][ T1] x25: 0000000000000038 x24: 0000000000000000
> >> [ 95.070185][ T1] x23: 0000000000000000 x22: 0000000000000019
> >> [ 95.076189][ T1] x21: 0000000000000000 x20: f9ff808b804e6c50
> >> [ 95.082193][ T1] x19: ffff100014a6e600 x18: 0000000000000040
> >> [ 95.088197][ T1] x17: 0000000000000000 x16: 86ff80099d581b50
> >> [ 95.094201][ T1] x15: 0000000000000000 x14: ffff100010086d1c
> >> [ 95.100205][ T1] x13: ffff1000109d8688 x12: ffffffffffffffff
> >> [ 95.106209][ T1] x11: 00000000000000f9 x10: ffff0808b804e6c6
> >> [ 95.112213][ T1] x9 : 4b71ad522c851d00 x8 : 4b71ad522c851d00
> >> [ 95.118217][ T1] x7 : 6170206574617473 x6 : ffff100014076972
> >> [ 95.124221][ T1] x5 : 34ff800806e6f8f0 x4 : 000000000000000f
> >> [ 95.130225][ T1] x3 : ffff1000101bfa5c x2 : 0000000000000001
> >> [ 95.136229][ T1] x1 : 0000000000000001 x0 : 0000000000000022
> >> [ 95.142233][ T1] Call trace:
> >> [ 95.145374][ T1] device_links_supplier_sync_state_resume+0x100/0x128
> >> [ 95.152074][ T1] of_platform_sync_state_init+0x10/0x1c
> >> [ 95.157557][ T1] do_one_initcall+0x2f8/0x600
> >> [ 95.162172][ T1] do_initcall_level+0x37c/0x3fc
> >> [ 95.166959][ T1] do_basic_setup+0x34/0x4c
> >> [ 95.171313][ T1] kernel_init_freeable+0x188/0x24c
> >> [ 95.176363][ T1] kernel_init+0x18/0x334
> >> [ 95.180543][ T1] ret_from_fork+0x10/0x18
> >> [ 95.184809][ T1] ---[ end trace a9ea68c902540fe5 ]---
> >> [ 95.269085][ T1] Freeing unused kernel memory: 28672K
> >> [ 101.069860][ T1] Checked W+X mappings: passed, no W+X pages found
> >> [ 101.076265][ T1] Run /init as init process
> >> [ 101.186359][ T1] systemd[1]: System time before build time, advancing clock.
> >
> >
> > I tested it again on my device (on an older kernel) and I don't see
> > this warning. Is this on an ARM64 target without a populated DT?
>
> Probably, /sys/firmware/devicetree is all empty.
>
> > That's the only thing I can see that could cause this warning.
> >
> > This is literally the code with the matching pause/resume. I can't
> > think of any other way the pause/resume could have ended up not
> > matching.
> >
> > static int __init of_platform_default_populate_init(void)
> > {
> > struct device_node *node;
> >
> > if (!of_have_populated_dt())
> > return -ENODEV;
> >
> > platform_bus_type.add_links = of_link_to_suppliers;
> > device_links_supplier_sync_state_pause(); <=========== PAUSE
> > /*
> > * Handle certain compatibles explicitly, since we don't want to create
> > * platform_devices for every node in /reserved-memory with a
> > * "compatible",
> > */
> > for_each_matching_node(node, reserved_mem_matches)
> > of_platform_device_create(node, NULL, NULL);
> >
> > node = of_find_node_by_path("/firmware");
> > if (node) {
> > of_platform_populate(node, NULL, NULL, NULL);
> > of_node_put(node);
> > }
> >
> > /* Populate everything else. */
> > of_platform_default_populate(NULL, NULL, NULL);
> >
> > return 0;
> > }
> > arch_initcall_sync(of_platform_default_populate_init);
> >
> > static int __init of_platform_sync_state_init(void)
> > {
> > device_links_supplier_sync_state_resume(); <========= RESUME
> > return 0;
> > }
> > late_initcall_sync(of_platform_sync_state_init);
> >
> > Thanks,
> > Saravana
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 00/39] put_user_pages(): miscellaneous call sites
From: John Hubbard @ 2019-08-07 1:49 UTC (permalink / raw)
To: john.hubbard, Andrew Morton
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, sparclinux, Ira Weiny, ceph-devel, devel, rds-devel,
linux-rdma, x86, amd-gfx, Christoph Hellwig, Jason Gunthorpe,
xen-devel, devel, linux-media, intel-gfx, linux-block,
Jérôme Glisse, linux-rpi-kernel, Dan Williams,
linux-arm-kernel, linux-nfs, netdev, LKML, linux-xfs,
linux-crypto, linux-fsdevel
In-Reply-To: <20190807013340.9706-1-jhubbard@nvidia.com>
On 8/6/19 6:32 PM, john.hubbard@gmail.com wrote:
> From: John Hubbard <jhubbard@nvidia.com>
> ...
>
> John Hubbard (38):
> mm/gup: add make_dirty arg to put_user_pages_dirty_lock()
...
> 54 files changed, 191 insertions(+), 323 deletions(-)
>
ahem, yes, apparently this is what happens if I add a few patches while editing
the cover letter... :)
The subject line should read "00/41", and the list of files affected here is
therefore under-reported in this cover letter. However, the patch series itself is
intact and ready for submission.
thanks,
--
John Hubbard
NVIDIA
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: "of/platform: Pause/resume sync state during init and of_platform_populate()" with a warning on arm64
From: Qian Cai @ 2019-08-07 1:46 UTC (permalink / raw)
To: Saravana Kannan
Cc: Greg Kroah-Hartman, Rob Herring, Linux List Kernel Mailing,
linux-arm-kernel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CAGETcx_TYxgohR7C5SRRbSmfKNhS90i64KjtA38N19g_Kz3euA@mail.gmail.com>
> On Aug 6, 2019, at 9:22 PM, Saravana Kannan <saravanak@google.com> wrote:
>
> On Tue, Aug 6, 2019 at 5:46 PM Qian Cai <cai@lca.pw> wrote:
>>
>> It looks like the linux-next commit “of/platform: Pause/resume sync state during init and of_platform_populate()” [1]
>> Introduced a warning while booting arm64.
>>
>> [1] https://lore.kernel.org/lkml/20190731221721.187713-6-saravanak@google.com/
>>
>> [ 93.449300][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: ias 44-bit, oas 44-bit (features 0x0000170d)
>> [ 93.464873][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries for cmdq
>> [ 93.485481][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries for evtq
>> [ 93.496320][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: option mask 0x2
>> [ 93.502917][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: ias 44-bit, oas 44-bit (features 0x0000170d)
>> [ 93.621818][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries for cmdq
>> [ 93.643000][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries for evtq
>> [ 94.519445][ T1] libphy: Fixed MDIO Bus: probed
>> [ 94.524649][ T1] EFI Variables Facility v0.08 2004-May-17
>> [ 94.601166][ T1] NET: Registered protocol family 17
>> [ 94.766008][ T1] zswap: loaded using pool lzo/zbud
>> [ 94.774745][ T1] kmemleak: Kernel memory leak detector initialized (mempool size: 16384)
>> [ 94.774756][ T1699] kmemleak: Automatic memory scanning thread started
>> [ 94.812338][ T1368] pcieport 0000:0f:00.0: Adding to iommu group 0
>> [ 94.984466][ T1] ------------[ cut here ]------------
>> [ 94.989827][ T1] Unmatched sync_state pause/resume!
>> [ 94.989894][ T1] WARNING: CPU: 25 PID: 1 at drivers/base/core.c:691 device_links_supplier_sync_state_resume+0x100/0x128
>> [ 95.006062][ T1] Modules linked in:
>> [ 95.009815][ T1] CPU: 25 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc3-next-20190806+ #11
>> [ 95.018161][ T1] Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019
>> [ 95.028593][ T1] pstate: 60400009 (nZCv daif +PAN -UAO)
>> [ 95.034077][ T1] pc : device_links_supplier_sync_state_resume+0x100/0x128
>> [ 95.041124][ T1] lr : device_links_supplier_sync_state_resume+0x100/0x128
>> [ 95.048167][ T1] sp : 34ff800806e6fbc0
>> [ 95.052172][ T1] x29: 34ff800806e6fc00 x28: 0000000000000000
>> [ 95.058177][ T1] x27: 0000000000000000 x26: 0000000000000000
>> [ 95.064181][ T1] x25: 0000000000000038 x24: 0000000000000000
>> [ 95.070185][ T1] x23: 0000000000000000 x22: 0000000000000019
>> [ 95.076189][ T1] x21: 0000000000000000 x20: f9ff808b804e6c50
>> [ 95.082193][ T1] x19: ffff100014a6e600 x18: 0000000000000040
>> [ 95.088197][ T1] x17: 0000000000000000 x16: 86ff80099d581b50
>> [ 95.094201][ T1] x15: 0000000000000000 x14: ffff100010086d1c
>> [ 95.100205][ T1] x13: ffff1000109d8688 x12: ffffffffffffffff
>> [ 95.106209][ T1] x11: 00000000000000f9 x10: ffff0808b804e6c6
>> [ 95.112213][ T1] x9 : 4b71ad522c851d00 x8 : 4b71ad522c851d00
>> [ 95.118217][ T1] x7 : 6170206574617473 x6 : ffff100014076972
>> [ 95.124221][ T1] x5 : 34ff800806e6f8f0 x4 : 000000000000000f
>> [ 95.130225][ T1] x3 : ffff1000101bfa5c x2 : 0000000000000001
>> [ 95.136229][ T1] x1 : 0000000000000001 x0 : 0000000000000022
>> [ 95.142233][ T1] Call trace:
>> [ 95.145374][ T1] device_links_supplier_sync_state_resume+0x100/0x128
>> [ 95.152074][ T1] of_platform_sync_state_init+0x10/0x1c
>> [ 95.157557][ T1] do_one_initcall+0x2f8/0x600
>> [ 95.162172][ T1] do_initcall_level+0x37c/0x3fc
>> [ 95.166959][ T1] do_basic_setup+0x34/0x4c
>> [ 95.171313][ T1] kernel_init_freeable+0x188/0x24c
>> [ 95.176363][ T1] kernel_init+0x18/0x334
>> [ 95.180543][ T1] ret_from_fork+0x10/0x18
>> [ 95.184809][ T1] ---[ end trace a9ea68c902540fe5 ]---
>> [ 95.269085][ T1] Freeing unused kernel memory: 28672K
>> [ 101.069860][ T1] Checked W+X mappings: passed, no W+X pages found
>> [ 101.076265][ T1] Run /init as init process
>> [ 101.186359][ T1] systemd[1]: System time before build time, advancing clock.
>
>
> I tested it again on my device (on an older kernel) and I don't see
> this warning. Is this on an ARM64 target without a populated DT?
Probably, /sys/firmware/devicetree is all empty.
> That's the only thing I can see that could cause this warning.
>
> This is literally the code with the matching pause/resume. I can't
> think of any other way the pause/resume could have ended up not
> matching.
>
> static int __init of_platform_default_populate_init(void)
> {
> struct device_node *node;
>
> if (!of_have_populated_dt())
> return -ENODEV;
>
> platform_bus_type.add_links = of_link_to_suppliers;
> device_links_supplier_sync_state_pause(); <=========== PAUSE
> /*
> * Handle certain compatibles explicitly, since we don't want to create
> * platform_devices for every node in /reserved-memory with a
> * "compatible",
> */
> for_each_matching_node(node, reserved_mem_matches)
> of_platform_device_create(node, NULL, NULL);
>
> node = of_find_node_by_path("/firmware");
> if (node) {
> of_platform_populate(node, NULL, NULL, NULL);
> of_node_put(node);
> }
>
> /* Populate everything else. */
> of_platform_default_populate(NULL, NULL, NULL);
>
> return 0;
> }
> arch_initcall_sync(of_platform_default_populate_init);
>
> static int __init of_platform_sync_state_init(void)
> {
> device_links_supplier_sync_state_resume(); <========= RESUME
> return 0;
> }
> late_initcall_sync(of_platform_sync_state_init);
>
> Thanks,
> Saravana
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 40/41] mm/mempolicy.c: convert put_page() to put_user_page*()
From: john.hubbard @ 2019-08-07 1:33 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-fbdev, Michal Hocko, Jan Kara, kvm, Dave Hansen,
Dave Chinner, dri-devel, linux-mm, sparclinux, Ira Weiny,
ceph-devel, devel, rds-devel, linux-rdma, x86, amd-gfx,
Christoph Hellwig, Jason Gunthorpe, Vlastimil Babka,
David Rientjes, xen-devel, devel, linux-media, Andrea Arcangeli,
Anshuman Khandual, John Hubbard, intel-gfx, Dominik Brodowski,
linux-block, Jérôme Glisse, linux-rpi-kernel,
Dan Williams, zhong jiang, linux-arm-kernel, linux-nfs, netdev,
LKML, linux-xfs, linux-crypto, linux-fsdevel, Kirill A . Shutemov
In-Reply-To: <20190807013340.9706-1-jhubbard@nvidia.com>
From: John Hubbard <jhubbard@nvidia.com>
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: zhong jiang <zhongjiang@huawei.com>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
mm/mempolicy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index f48693f75b37..76a8e935e2e6 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -832,7 +832,7 @@ static int lookup_node(struct mm_struct *mm, unsigned long addr)
err = get_user_pages_locked(addr & PAGE_MASK, 1, 0, &p, &locked);
if (err >= 0) {
err = page_to_nid(p);
- put_page(p);
+ put_user_page(p);
}
if (locked)
up_read(&mm->mmap_sem);
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 41/41] mm/ksm: convert put_page() to put_user_page*()
From: john.hubbard @ 2019-08-07 1:33 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, Matthew Wilcox, sparclinux, Ira Weiny, ceph-devel,
devel, rds-devel, linux-rdma, x86, amd-gfx, Christoph Hellwig,
Jason Gunthorpe, xen-devel, devel, linux-media, Daniel Black,
John Hubbard, intel-gfx, linux-block, Jérôme Glisse,
linux-rpi-kernel, Dan Williams, linux-arm-kernel, linux-nfs,
netdev, LKML, linux-xfs, linux-crypto, linux-fsdevel,
Mike Kravetz
In-Reply-To: <20190807013340.9706-1-jhubbard@nvidia.com>
From: John Hubbard <jhubbard@nvidia.com>
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Daniel Black <daniel@linux.ibm.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
mm/ksm.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/mm/ksm.c b/mm/ksm.c
index 3dc4346411e4..e10ee4d5fdd8 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -456,7 +456,7 @@ static inline bool ksm_test_exit(struct mm_struct *mm)
* We use break_ksm to break COW on a ksm page: it's a stripped down
*
* if (get_user_pages(addr, 1, 1, 1, &page, NULL) == 1)
- * put_page(page);
+ * put_user_page(page);
*
* but taking great care only to touch a ksm page, in a VM_MERGEABLE vma,
* in case the application has unmapped and remapped mm,addr meanwhile.
@@ -483,7 +483,7 @@ static int break_ksm(struct vm_area_struct *vma, unsigned long addr)
FAULT_FLAG_WRITE | FAULT_FLAG_REMOTE);
else
ret = VM_FAULT_WRITE;
- put_page(page);
+ put_user_page(page);
} while (!(ret & (VM_FAULT_WRITE | VM_FAULT_SIGBUS | VM_FAULT_SIGSEGV | VM_FAULT_OOM)));
/*
* We must loop because handle_mm_fault() may back out if there's
@@ -568,7 +568,7 @@ static struct page *get_mergeable_page(struct rmap_item *rmap_item)
flush_anon_page(vma, page, addr);
flush_dcache_page(page);
} else {
- put_page(page);
+ put_user_page(page);
out:
page = NULL;
}
@@ -1974,10 +1974,10 @@ struct rmap_item *unstable_tree_search_insert(struct rmap_item *rmap_item,
parent = *new;
if (ret < 0) {
- put_page(tree_page);
+ put_user_page(tree_page);
new = &parent->rb_left;
} else if (ret > 0) {
- put_page(tree_page);
+ put_user_page(tree_page);
new = &parent->rb_right;
} else if (!ksm_merge_across_nodes &&
page_to_nid(tree_page) != nid) {
@@ -1986,7 +1986,7 @@ struct rmap_item *unstable_tree_search_insert(struct rmap_item *rmap_item,
* it will be flushed out and put in the right unstable
* tree next time: only merge with it when across_nodes.
*/
- put_page(tree_page);
+ put_user_page(tree_page);
return NULL;
} else {
*tree_pagep = tree_page;
@@ -2328,7 +2328,7 @@ static struct rmap_item *scan_get_next_rmap_item(struct page **page)
&rmap_item->rmap_list;
ksm_scan.address += PAGE_SIZE;
} else
- put_page(*page);
+ put_user_page(*page);
up_read(&mm->mmap_sem);
return rmap_item;
}
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox