* Re: [PATCH v3 04/10] ASoC: tegra: add Tegra210 based I2S driver
From: Jon Hunter @ 2020-02-20 14:45 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: devicetree, alsa-devel, atalambedu, lgirdwood, linux-kernel,
viswanathl, sharadg, broonie, thierry.reding, linux-tegra, digetx,
rlokhande, mkumard, dramesh
In-Reply-To: <1582180492-25297-5-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Inter-IC Sound (I2S) controller implements full-duplex, bi-directional
> and single direction point to point serial interface. It can interface
> with I2S compatible devices. Tegra I2S controller can operate as both
> master and slave.
>
> This patch registers I2S controller with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes I2S interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The I2S devices can be enabled in the DT via
> "nvidia,tegra210-i2s" compatible binding.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/Kconfig | 10 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra210_i2s.c | 938 +++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra210_i2s.h | 132 ++++++
> 4 files changed, 1082 insertions(+)
> create mode 100644 sound/soc/tegra/tegra210_i2s.c
> create mode 100644 sound/soc/tegra/tegra210_i2s.h
Thanks!
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* RE: [PATCH] drm/amdgpu: Add a chunk ID for spm trace
From: He, Jacob @ 2020-02-20 14:46 UTC (permalink / raw)
To: Zhou, David(ChunMing), Koenig, Christian,
amd-gfx@lists.freedesktop.org
In-Reply-To: <MN2PR12MB337663C5CCF3D53744FD377D9B130@MN2PR12MB3376.namprd12.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 11426 bytes --]
amdgpu_vm_reserve_vmid doesn’t return the reserved vmid back to user space. There is no chance for user mode driver to update RLC_SPM_VMID.
Thanks
Jacob
From: He, Jacob<mailto:Jacob.He@amd.com>
Sent: Thursday, February 20, 2020 6:20 PM
To: Zhou, David(ChunMing)<mailto:David1.Zhou@amd.com>; Koenig, Christian<mailto:Christian.Koenig@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: RE: [PATCH] drm/amdgpu: Add a chunk ID for spm trace
Looks like amdgpu_vm_reserve_vmid could work, let me have a try to update the RLC_SPM_VMID with pm4 packets in UMD.
Thanks
Jacob
From: Zhou, David(ChunMing)<mailto:David1.Zhou@amd.com>
Sent: Thursday, February 20, 2020 10:13 AM
To: Koenig, Christian<mailto:Christian.Koenig@amd.com>; He, Jacob<mailto:Jacob.He@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: RE: [PATCH] drm/amdgpu: Add a chunk ID for spm trace
[AMD Official Use Only - Internal Distribution Only]
Christian is right here, that will cause many problems for simply using VMID in kernel.
We already have an pair interface for RGP, I think you can use it instead of involving additional kernel change.
amdgpu_vm_reserve_vmid/ amdgpu_vm_unreserve_vmid.
-David
-----Original Message-----
From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> On Behalf Of Christian König
Sent: Wednesday, February 19, 2020 7:03 PM
To: He, Jacob <Jacob.He@amd.com>; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Add a chunk ID for spm trace
Am 19.02.20 um 11:15 schrieb Jacob He:
> [WHY]
> When SPM trace enabled, SPM_VMID should be updated with the current
> vmid.
>
> [HOW]
> Add a chunk id, AMDGPU_CHUNK_ID_SPM_TRACE, so that UMD can tell us
> which job should update SPM_VMID.
> Right before a job is submitted to GPU, set the SPM_VMID accordingly.
>
> [Limitation]
> Running more than one SPM trace enabled processes simultaneously is
> not supported.
Well there are multiple problems with that patch.
First of all you need to better describe what SPM tracing is in the commit message.
Then the updating of mmRLC_SPM_MC_CNTL must be executed asynchronously on the ring. Otherwise we might corrupt an already executing SPM trace.
And you also need to make sure to disable the tracing again or otherwise we run into a bunch of trouble when the VMID is reused.
You also need to make sure that IBs using the SPM trace are serialized with each other, e.g. hack into amdgpu_ids.c file and make sure that only one VMID at a time can have that attribute.
Regards,
Christian.
>
> Change-Id: Ic932ef6ac9dbf244f03aaee90550e8ff3a675666
> Signed-off-by: Jacob He <jacob.he@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 7 +++++++
> drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 10 +++++++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h | 1 +
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 15 ++++++++++++++-
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 3 ++-
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 3 ++-
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 15 ++++++++++++++-
> 8 files changed, 48 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index f9fa6e104fef..3f32c4db5232 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -113,6 +113,7 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, union drm_amdgpu_cs
> uint32_t uf_offset = 0;
> int i;
> int ret;
> + bool update_spm_vmid = false;
>
> if (cs->in.num_chunks == 0)
> return 0;
> @@ -221,6 +222,10 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, union drm_amdgpu_cs
> case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL:
> break;
>
> + case AMDGPU_CHUNK_ID_SPM_TRACE:
> + update_spm_vmid = true;
> + break;
> +
> default:
> ret = -EINVAL;
> goto free_partial_kdata;
> @@ -231,6 +236,8 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, union drm_amdgpu_cs
> if (ret)
> goto free_all_kdata;
>
> + p->job->need_update_spm_vmid = update_spm_vmid;
> +
> if (p->ctx->vram_lost_counter != p->job->vram_lost_counter) {
> ret = -ECANCELED;
> goto free_all_kdata;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> index cae81914c821..36faab12b585 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> @@ -156,9 +156,13 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned num_ibs,
> return -EINVAL;
> }
>
> - if (vm && !job->vmid) {
> - dev_err(adev->dev, "VM IB without ID\n");
> - return -EINVAL;
> + if (vm) {
> + if (!job->vmid) {
> + dev_err(adev->dev, "VM IB without ID\n");
> + return -EINVAL;
> + } else if (adev->gfx.rlc.funcs->update_spm_vmid && job->need_update_spm_vmid) {
> + adev->gfx.rlc.funcs->update_spm_vmid(adev, job->vmid);
> + }
> }
>
> alloc_size = ring->funcs->emit_frame_size + num_ibs * diff --git
> a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> index 2e2110dddb76..4582536961c7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> @@ -52,6 +52,7 @@ struct amdgpu_job {
> bool vm_needs_flush;
> uint64_t vm_pd_addr;
> unsigned vmid;
> + bool need_update_spm_vmid;
> unsigned pasid;
> uint32_t gds_base, gds_size;
> uint32_t gws_base, gws_size;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
> index d3d4707f2168..52509c254cbd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
> @@ -126,6 +126,7 @@ struct amdgpu_rlc_funcs {
> void (*stop)(struct amdgpu_device *adev);
> void (*reset)(struct amdgpu_device *adev);
> void (*start)(struct amdgpu_device *adev);
> + void (*update_spm_vmid)(struct amdgpu_device *adev, unsigned vmid);
> };
>
> struct amdgpu_rlc {
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> index 5e9fb0976c6c..91eb788d6229 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> @@ -4214,6 +4214,18 @@ static int gfx_v10_0_update_gfx_clock_gating(struct amdgpu_device *adev,
> return 0;
> }
>
> +static void gfx_v10_0_update_spm_vmid(struct amdgpu_device *adev,
> +unsigned vmid) {
> + u32 data;
> +
> + data = RREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL);
> +
> + data &= ~RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK;
> + data |= (vmid & RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK) <<
> +RLC_SPM_MC_CNTL__RLC_SPM_VMID__SHIFT;
> +
> + WREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL, data); }
> +
> static const struct amdgpu_rlc_funcs gfx_v10_0_rlc_funcs = {
> .is_rlc_enabled = gfx_v10_0_is_rlc_enabled,
> .set_safe_mode = gfx_v10_0_set_safe_mode, @@ -4224,7 +4236,8 @@
> static const struct amdgpu_rlc_funcs gfx_v10_0_rlc_funcs = {
> .resume = gfx_v10_0_rlc_resume,
> .stop = gfx_v10_0_rlc_stop,
> .reset = gfx_v10_0_rlc_reset,
> - .start = gfx_v10_0_rlc_start
> + .start = gfx_v10_0_rlc_start,
> + .update_spm_vmid = gfx_v10_0_update_spm_vmid
> };
>
> static int gfx_v10_0_set_powergating_state(void *handle, diff --git
> a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> index 8f20a5dd44fe..b24fc55cf13a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> @@ -4221,7 +4221,8 @@ static const struct amdgpu_rlc_funcs gfx_v7_0_rlc_funcs = {
> .resume = gfx_v7_0_rlc_resume,
> .stop = gfx_v7_0_rlc_stop,
> .reset = gfx_v7_0_rlc_reset,
> - .start = gfx_v7_0_rlc_start
> + .start = gfx_v7_0_rlc_start,
> + .update_spm_vmid = NULL
> };
>
> static int gfx_v7_0_early_init(void *handle) diff --git
> a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index fa245973de12..66640d2b6b37 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -5600,7 +5600,8 @@ static const struct amdgpu_rlc_funcs iceland_rlc_funcs = {
> .resume = gfx_v8_0_rlc_resume,
> .stop = gfx_v8_0_rlc_stop,
> .reset = gfx_v8_0_rlc_reset,
> - .start = gfx_v8_0_rlc_start
> + .start = gfx_v8_0_rlc_start,
> + .update_spm_vmid = NULL
> };
>
> static void gfx_v8_0_update_medium_grain_clock_gating(struct
> amdgpu_device *adev, diff --git
> a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 9b7ff783e9a5..df872f949f68 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -4704,6 +4704,18 @@ static int gfx_v9_0_update_gfx_clock_gating(struct amdgpu_device *adev,
> return 0;
> }
>
> +static void gfx_v9_0_update_spm_vmid(struct amdgpu_device *adev,
> +unsigned vmid) {
> + u32 data;
> +
> + data = RREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL);
> +
> + data &= ~RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK;
> + data |= (vmid & RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK) <<
> +RLC_SPM_MC_CNTL__RLC_SPM_VMID__SHIFT;
> +
> + WREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL, data); }
> +
> static const struct amdgpu_rlc_funcs gfx_v9_0_rlc_funcs = {
> .is_rlc_enabled = gfx_v9_0_is_rlc_enabled,
> .set_safe_mode = gfx_v9_0_set_safe_mode, @@ -4715,7 +4727,8 @@
> static const struct amdgpu_rlc_funcs gfx_v9_0_rlc_funcs = {
> .resume = gfx_v9_0_rlc_resume,
> .stop = gfx_v9_0_rlc_stop,
> .reset = gfx_v9_0_rlc_reset,
> - .start = gfx_v9_0_rlc_start
> + .start = gfx_v9_0_rlc_start,
> + .update_spm_vmid = gfx_v9_0_update_spm_vmid
> };
>
> static int gfx_v9_0_set_powergating_state(void *handle,
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cdavid1.zhou%40amd.com%7C354be34ff18e4f424f6708d7b52b43b0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637177069753914395&sdata=9rSL4kgPJweuZ4EJpdqtqTxyCVGEkmsg6aUzbtvGFrs%3D&reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cjacob.he%40amd.com%7C0b340cec0e2d41dd4f8c08d7b5ee6f65%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637177908007702357&sdata=dRtYat6X178kHA8kJgsJOfiM9XhjDpmhM7dZTZy11lk%3D&reserved=0>
[-- Attachment #1.2: Type: text/html, Size: 21048 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* [PATCH blktests] nbd/003: fix compiling error with gcc version 4.8.5
From: Yi Zhang @ 2020-02-20 14:46 UTC (permalink / raw)
To: osandov; +Cc: linux-block, sunke32
cc -O2 -Wall -Wshadow -o mount_clear_sock mount_clear_sock.c
mount_clear_sock.c: In function ‘main’:
mount_clear_sock.c:39:2: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int i = 0; i < loops; i++) {
^
mount_clear_sock.c:39:2: note: use option -std=c99 or -std=gnu99 to compile your code
Signed-off-by: Yi Zhang <yi.zhang@redhat.com>
---
src/mount_clear_sock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mount_clear_sock.c b/src/mount_clear_sock.c
index 4030a4a..984395e 100644
--- a/src/mount_clear_sock.c
+++ b/src/mount_clear_sock.c
@@ -18,7 +18,7 @@
int main(int argc, char **argv)
{
const char *mountpoint, *dev, *fstype;
- int loops, fd;
+ int loops, fd, i;
if (argc != 5) {
fprintf(stderr, "usage: %s DEV MOUNTPOINT FSTYPE LOOPS", argv[0]);
@@ -36,7 +36,7 @@ int main(int argc, char **argv)
return EXIT_FAILURE;
}
- for (int i = 0; i < loops; i++) {
+ for (i = 0; i < loops; i++) {
pid_t mount_pid, clear_sock_pid;
int wstatus;
--
2.21.0
^ permalink raw reply related
* [igt-dev] ✓ Fi.CI.BAT: success for tools/i915-perf: Fix compiler warning
From: Patchwork @ 2020-02-20 14:47 UTC (permalink / raw)
To: Petri Latvala; +Cc: igt-dev
In-Reply-To: <20200220131245.17108-1-petri.latvala@intel.com>
== Series Details ==
Series: tools/i915-perf: Fix compiler warning
URL : https://patchwork.freedesktop.org/series/73714/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> IGTPW_4195
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4195/index.html
New tests
---------
New tests have been introduced between CI_DRM_7973 and IGTPW_4195:
### New IGT tests (4) ###
* igt@i915_pm_backlight@basic-brightness:
- Statuses : 1 dmesg-warn(s) 16 pass(s) 21 skip(s)
- Exec time: [0.0, 0.22] s
* igt@i915_pm_rpm@basic-pci-d3-state:
- Statuses : 1 dmesg-warn(s) 28 pass(s) 9 skip(s)
- Exec time: [0.0, 4.95] s
* igt@i915_pm_rpm@basic-rte:
- Statuses : 1 dmesg-warn(s) 28 pass(s) 9 skip(s)
- Exec time: [0.67, 30.91] s
* igt@i915_pm_rps@basic-api:
- Statuses : 34 pass(s) 4 skip(s)
- Exec time: [0.0, 0.02] s
Known issues
------------
Here are the changes found in IGTPW_4195 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2] ([i915#694] / [i915#816])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-hsw-peppy/igt@gem_close_race@basic-threads.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4195/fi-hsw-peppy/igt@gem_close_race@basic-threads.html
* igt@gem_mmap_gtt@basic:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([CI#94] / [i915#402])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@gem_mmap_gtt@basic.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4195/fi-tgl-y/igt@gem_mmap_gtt@basic.html
* igt@i915_selftest@live_gtt:
- fi-cfl-guc: [PASS][5] -> [TIMEOUT][6] ([fdo#112271])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cfl-guc/igt@i915_selftest@live_gtt.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4195/fi-cfl-guc/igt@i915_selftest@live_gtt.html
#### Possible fixes ####
* igt@gem_exec_parallel@contexts:
- fi-byt-n2820: [FAIL][7] ([i915#694]) -> [PASS][8]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-n2820/igt@gem_exec_parallel@contexts.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4195/fi-byt-n2820/igt@gem_exec_parallel@contexts.html
* igt@gem_mmap@basic:
- fi-tgl-y: [DMESG-WARN][9] ([CI#94] / [i915#402]) -> [PASS][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@gem_mmap@basic.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4195/fi-tgl-y/igt@gem_mmap@basic.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][11] ([i915#877]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4195/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][13] ([i915#217]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4195/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
#### Warnings ####
* igt@gem_exec_parallel@fds:
- fi-byt-n2820: [FAIL][15] ([i915#694]) -> [TIMEOUT][16] ([fdo#112271] / [i915#1084])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-n2820/igt@gem_exec_parallel@fds.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4195/fi-byt-n2820/igt@gem_exec_parallel@fds.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][17] ([fdo#111407]) -> [FAIL][18] ([fdo#111096] / [i915#323])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4195/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 43)
------------------------------
Additional (5): fi-kbl-soraka fi-ivb-3770 fi-pnv-d510 fi-skl-lmem fi-kbl-7560u
Missing (11): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-skl-6770hq fi-byt-squawks fi-bsw-cyan fi-cfl-8700k fi-ctg-p8600 fi-gdg-551 fi-kbl-8809g fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5453 -> IGTPW_4195
CI-20190529: 20190529
CI_DRM_7973: 07350317e4b2be54b1de7f1e73f77875df5e43f3 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4195: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4195/index.html
IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4195/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH] lttng-modules: Check the pid_ns before using it because it may be NULL
From: Jonathan Rajotte-Julien @ 2020-02-20 14:47 UTC (permalink / raw)
To: Li Zhou; +Cc: openembedded-core
In-Reply-To: <1582165584-187223-1-git-send-email-li.zhou@windriver.com>
Hi,
Can we get more info on the kernel version and config?
Did you submit this on our mailing list?(lttng-dev). If not I would highly recommend that you do so in the future so we can eliminate *custom* patches and get to the bottom of the issue at hand so that the whole community benefit from it.
Cheers
----- Li Zhou <li.zhou@windriver.com> wrote:
> Check the pid_ns before using it because it may be NULL to fix below
> issue:
> <1>[ 22.637196] Unable to handle kernel NULL pointer dereference at
> virtual address 0000000000000080
> <1>[ 22.645982] Mem abort info:
> <1>[ 22.648769] ESR = 0x96000007
> <1>[ 22.651817] Exception class = DABT (current EL), IL = 32 bits
> <1>[ 22.657730] SET = 0, FnV = 0
> <1>[ 22.660777] EA = 0, S1PTW = 0
> <1>[ 22.663910] Data abort info:
> <1>[ 22.666784] ISV = 0, ISS = 0x00000007
> <1>[ 22.670611] CM = 0, WnR = 0
> <1>[ 22.673574] user pgtable: 4k pages, 39-bit VAs, pgdp =
> 0000000012378f78
> <1>[ 22.680180] [0000000000000080] pgd=000000007f023003,
> pud=000000007f023003, pmd=000000007f01f003, pte=0000000000000000
> <0>[ 22.690794] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> <4>[ 22.690797] Modules linked in: adkNetD ncp
> lttng_ring_buffer_client_overwrite(C)
> lttng_ring_buffer_metadata_client(C) lttng_ring_buffer_client_discard(C)
> lttng_ring_buffer_client_mmap_overwrite(C)
> lttng_ring_buffer_client_mmap_discard(C)
> lttng_ring_buffer_metadata_mmap_client(C) lttng_probe_signal(C)
> lttng_probe_printk(C) lttng_probe_sched(C) lttng_probe_irq(C)
> lttng_tracer(C) lttng_statedump(C) lttng_ftrace(C)
> lttng_lib_ring_buffer(C) lttng_clock_plugin_arm_cntpct(C) lttng_clock(C)
> <0>[ 22.690823] Process lttng-sessiond (pid: 3093, stack limit =
> 0x000000005d27910f)
> <4>[ 22.690828] CPU: 1 PID: 3093 Comm: lttng-sessiond Tainted: G C
> 4.18.37-rt820-custom #1
> <4>[ 22.690830] Hardware name: DUS33 (CPM2-20) (DT)
> <4>[ 22.690833] pstate: 60000005 (nZCv daif -PAN -UAO)
> <4>[ 22.690845] pc : do_lttng_statedump+0xcc/0x8a8 [lttng_statedump]
> <4>[ 22.690849] lr : do_lttng_statedump+0xc4/0x8a8 [lttng_statedump]
> <4>[ 22.690851] sp : ffffffc07fe57ad0
> <4>[ 22.690852] x29: ffffffc07fe57ad0 x28: ffffffc008ae2700
> <4>[ 22.690856] x27: ffffff8000724000 x26: 0000000000000001
> <4>[ 22.690859] x25: ffffff80089c9620 x24: 0000000000000000
> <4>[ 22.690862] x23: ffffffc008ae2e10 x22: ffffff80089d3380
> <4>[ 22.690865] x21: ffffffc07f450000 x20: ffffffc008ae2700
> <4>[ 22.690869] x19: 0000000000000007 x18: 00000000fffffffe
> <4>[ 22.690871] x17: 0000000000000000 x16: ffffff800824b980
> <4>[ 22.690874] x15: 0000000000000000 x14: 736162203b656e6f
> <4>[ 22.690877] x13: 6e203d20676e6964 x12: 0000000000000000
> <4>[ 22.690880] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
> <4>[ 22.690882] x9 : 3c1f647968721eff x8 : ffffffc0877504c8
> <4>[ 22.690886] x7 : 09093a7c093a7c08 x6 : ffffff8010c4b317
> <4>[ 22.690888] x5 : 0000000000000000 x4 : 00000040a7575000
> <4>[ 22.690891] x3 : ffffffc008ae2e28 x2 : 0000000000000000
> <4>[ 22.690894] x1 : 0000000000000000 x0 : 0000000000000000
> <4>[ 22.690896] Call trace:
> <4>[ 22.690902] do_lttng_statedump+0xcc/0x8a8 [lttng_statedump]
> <4>[ 22.690905] lttng_statedump_start+0x20/0x30 [lttng_statedump]
> <4>[ 22.690981] lttng_session_enable+0xf0/0x120 [lttng_tracer]
> <4>[ 22.691018] lttng_session_ioctl+0x22c/0x328 [lttng_tracer]
> <4>[ 22.691026] compat_sys_ioctl+0x110/0x778
>
> Signed-off-by: Li Zhou <li.zhou@windriver.com>
> ---
> ...es-Check-the-pid_ns-before-using-it-becau.patch | 86 ++++++++++++++++++++++
> meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb | 2 +
> 2 files changed, 88 insertions(+)
> create mode 100644 meta/recipes-kernel/lttng/lttng-modules/0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch
>
> diff --git a/meta/recipes-kernel/lttng/lttng-modules/0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch b/meta/recipes-kernel/lttng/lttng-modules/0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch
> new file mode 100644
> index 0000000..5306c79
> --- /dev/null
> +++ b/meta/recipes-kernel/lttng/lttng-modules/0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch
> @@ -0,0 +1,86 @@
> +From 0c0072e005ce9d591518d1819a39264859132561 Mon Sep 17 00:00:00 2001
> +From: Li Zhou <li.zhou@windriver.com>
> +Date: Wed, 19 Feb 2020 11:14:38 +0800
> +Subject: [PATCH] lttng-modules: Check the pid_ns before using it because it
> + may be NULL
> +
> +<1>[ 22.637196] Unable to handle kernel NULL pointer dereference at
> +virtual address 0000000000000080
> +<1>[ 22.645982] Mem abort info:
> +<1>[ 22.648769] ESR = 0x96000007
> +<1>[ 22.651817] Exception class = DABT (current EL), IL = 32 bits
> +<1>[ 22.657730] SET = 0, FnV = 0
> +<1>[ 22.660777] EA = 0, S1PTW = 0
> +<1>[ 22.663910] Data abort info:
> +<1>[ 22.666784] ISV = 0, ISS = 0x00000007
> +<1>[ 22.670611] CM = 0, WnR = 0
> +<1>[ 22.673574] user pgtable: 4k pages, 39-bit VAs, pgdp =
> +0000000012378f78
> +<1>[ 22.680180] [0000000000000080] pgd=000000007f023003,
> +pud=000000007f023003, pmd=000000007f01f003, pte=0000000000000000
> +<0>[ 22.690794] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> +<4>[ 22.690797] Modules linked in: adkNetD ncp
> +lttng_ring_buffer_client_overwrite(C)
> +lttng_ring_buffer_metadata_client(C) lttng_ring_buffer_client_discard(C)
> +lttng_ring_buffer_client_mmap_overwrite(C)
> +lttng_ring_buffer_client_mmap_discard(C)
> +lttng_ring_buffer_metadata_mmap_client(C) lttng_probe_signal(C)
> +lttng_probe_printk(C) lttng_probe_sched(C) lttng_probe_irq(C)
> +lttng_tracer(C) lttng_statedump(C) lttng_ftrace(C)
> +lttng_lib_ring_buffer(C) lttng_clock_plugin_arm_cntpct(C) lttng_clock(C)
> +<0>[ 22.690823] Process lttng-sessiond (pid: 3093, stack limit =
> +0x000000005d27910f)
> +<4>[ 22.690828] CPU: 1 PID: 3093 Comm: lttng-sessiond Tainted: G C
> +4.18.37-rt820-custom #1
> +<4>[ 22.690830] Hardware name: DUS33 (CPM2-20) (DT)
> +<4>[ 22.690833] pstate: 60000005 (nZCv daif -PAN -UAO)
> +<4>[ 22.690845] pc : do_lttng_statedump+0xcc/0x8a8 [lttng_statedump]
> +<4>[ 22.690849] lr : do_lttng_statedump+0xc4/0x8a8 [lttng_statedump]
> +<4>[ 22.690851] sp : ffffffc07fe57ad0
> +<4>[ 22.690852] x29: ffffffc07fe57ad0 x28: ffffffc008ae2700
> +<4>[ 22.690856] x27: ffffff8000724000 x26: 0000000000000001
> +<4>[ 22.690859] x25: ffffff80089c9620 x24: 0000000000000000
> +<4>[ 22.690862] x23: ffffffc008ae2e10 x22: ffffff80089d3380
> +<4>[ 22.690865] x21: ffffffc07f450000 x20: ffffffc008ae2700
> +<4>[ 22.690869] x19: 0000000000000007 x18: 00000000fffffffe
> +<4>[ 22.690871] x17: 0000000000000000 x16: ffffff800824b980
> +<4>[ 22.690874] x15: 0000000000000000 x14: 736162203b656e6f
> +<4>[ 22.690877] x13: 6e203d20676e6964 x12: 0000000000000000
> +<4>[ 22.690880] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
> +<4>[ 22.690882] x9 : 3c1f647968721eff x8 : ffffffc0877504c8
> +<4>[ 22.690886] x7 : 09093a7c093a7c08 x6 : ffffff8010c4b317
> +<4>[ 22.690888] x5 : 0000000000000000 x4 : 00000040a7575000
> +<4>[ 22.690891] x3 : ffffffc008ae2e28 x2 : 0000000000000000
> +<4>[ 22.690894] x1 : 0000000000000000 x0 : 0000000000000000
> +<4>[ 22.690896] Call trace:
> +<4>[ 22.690902] do_lttng_statedump+0xcc/0x8a8 [lttng_statedump]
> +<4>[ 22.690905] lttng_statedump_start+0x20/0x30 [lttng_statedump]
> +<4>[ 22.690981] lttng_session_enable+0xf0/0x120 [lttng_tracer]
> +<4>[ 22.691018] lttng_session_ioctl+0x22c/0x328 [lttng_tracer]
> +<4>[ 22.691026] compat_sys_ioctl+0x110/0x778
> +
> +Signed-off-by: Liguang Li <liguang.li@windriver.com>
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Li Zhou <li.zhou@windriver.com>
> +---
> + lttng-statedump-impl.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/lttng-statedump-impl.c b/lttng-statedump-impl.c
> +index 1c09e51..fb609e3 100644
> +--- a/lttng-statedump-impl.c
> ++++ b/lttng-statedump-impl.c
> +@@ -397,7 +397,7 @@ void lttng_statedump_process_ns(struct lttng_session *session,
> + do {
> + trace_lttng_statedump_process_state(session,
> + p, type, mode, submode, status, pid_ns);
> +- pid_ns = pid_ns->parent;
> ++ pid_ns = pid_ns ? pid_ns->parent : NULL;
> + } while (pid_ns);
> + }
> +
> +--
> +1.9.1
> +
> diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb b/meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb
> index c833ff7..cbd43e3 100644
> --- a/meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb
> +++ b/meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb
> @@ -11,6 +11,7 @@ COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm|riscv).*-linux'
> SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
> file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch \
> file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
> + file://0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch \
> "
>
> SRC_URI[md5sum] = "0d964723c8765b39835e5e6efc60a604"
> @@ -36,6 +37,7 @@ DEFAULT_PREFERENCE_class-devupstream = "-1"
> SRC_URI_class-devupstream = "git://git.lttng.org/lttng-modules;branch=stable-2.11 \
> file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch \
> file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
> + file://0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch \
> "
> SRCREV_class-devupstream = "6ad0e68b43c3e52fcb3d47c4d823a7b84aeb443a"
> PV_class-devupstream = "2.11.1+git${SRCPV}"
> --
> 1.9.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [PATCH] proc: faster open/read/close with "permanent" files (fwd)
From: Julia Lawall @ 2020-02-20 14:47 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 5578 bytes --]
Hello,
It looks like an unlock may be needed o lines 721 and 732.
julia
---------- Forwarded message ----------
Hi Alexey,
I love your patch! Perhaps something to improve:
[auto build test WARNING on jeyu/modules-next]
[also build test WARNING on linus/master v5.6-rc2 next-20200218]
[cannot apply to linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Alexey-Dobriyan/proc-faster-open-read-close-with-permanent-files/20200218-231203
base: https://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git modules-next
:::::: branch date: 6 hours ago
:::::: commit date: 6 hours ago
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
>> fs/proc/generic.c:721:2-8: preceding lock on line 706
fs/proc/generic.c:732:4-10: preceding lock on line 706
fs/proc/generic.c:732:4-10: preceding lock on line 748
# https://github.com/0day-ci/linux/commit/3cd4ad42ca7c52d1513e7ba9f08a06197a7380c8
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 3cd4ad42ca7c52d1513e7ba9f08a06197a7380c8
vim +721 fs/proc/generic.c
8ce584c7416d8a Al Viro 2013-03-30 699
8ce584c7416d8a Al Viro 2013-03-30 700 int remove_proc_subtree(const char *name, struct proc_dir_entry *parent)
8ce584c7416d8a Al Viro 2013-03-30 701 {
8ce584c7416d8a Al Viro 2013-03-30 702 struct proc_dir_entry *root = NULL, *de, *next;
8ce584c7416d8a Al Viro 2013-03-30 703 const char *fn = name;
8ce584c7416d8a Al Viro 2013-03-30 704 unsigned int len;
8ce584c7416d8a Al Viro 2013-03-30 705
ecf1a3dfff22bd Waiman Long 2015-09-09 @706 write_lock(&proc_subdir_lock);
8ce584c7416d8a Al Viro 2013-03-30 707 if (__xlate_proc_name(name, &parent, &fn) != 0) {
ecf1a3dfff22bd Waiman Long 2015-09-09 708 write_unlock(&proc_subdir_lock);
8ce584c7416d8a Al Viro 2013-03-30 709 return -ENOENT;
8ce584c7416d8a Al Viro 2013-03-30 710 }
8ce584c7416d8a Al Viro 2013-03-30 711 len = strlen(fn);
8ce584c7416d8a Al Viro 2013-03-30 712
710585d4922fd3 Nicolas Dichtel 2014-12-10 713 root = pde_subdir_find(parent, fn, len);
8ce584c7416d8a Al Viro 2013-03-30 714 if (!root) {
ecf1a3dfff22bd Waiman Long 2015-09-09 715 write_unlock(&proc_subdir_lock);
8ce584c7416d8a Al Viro 2013-03-30 716 return -ENOENT;
8ce584c7416d8a Al Viro 2013-03-30 717 }
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 718 if (unlikely(pde_is_permanent(root))) {
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 719 WARN(1, "removing permanent /proc entry '%s/%s'",
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 720 root->parent->name, root->name);
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 @721 return -EINVAL;
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 722 }
4f1134370a29a5 Alexey Dobriyan 2018-04-10 723 rb_erase(&root->subdir_node, &parent->subdir);
710585d4922fd3 Nicolas Dichtel 2014-12-10 724
8ce584c7416d8a Al Viro 2013-03-30 725 de = root;
8ce584c7416d8a Al Viro 2013-03-30 726 while (1) {
710585d4922fd3 Nicolas Dichtel 2014-12-10 727 next = pde_subdir_first(de);
8ce584c7416d8a Al Viro 2013-03-30 728 if (next) {
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 729 if (unlikely(pde_is_permanent(root))) {
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 730 WARN(1, "removing permanent /proc entry '%s/%s'",
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 731 next->parent->name, next->name);
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 732 return -EINVAL;
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 733 }
4f1134370a29a5 Alexey Dobriyan 2018-04-10 734 rb_erase(&next->subdir_node, &de->subdir);
8ce584c7416d8a Al Viro 2013-03-30 735 de = next;
8ce584c7416d8a Al Viro 2013-03-30 736 continue;
8ce584c7416d8a Al Viro 2013-03-30 737 }
8ce584c7416d8a Al Viro 2013-03-30 738 next = de->parent;
8ce584c7416d8a Al Viro 2013-03-30 739 if (S_ISDIR(de->mode))
8ce584c7416d8a Al Viro 2013-03-30 740 next->nlink--;
e06689bf57017a Alexey Dobriyan 2019-12-04 741 write_unlock(&proc_subdir_lock);
e06689bf57017a Alexey Dobriyan 2019-12-04 742
e06689bf57017a Alexey Dobriyan 2019-12-04 743 proc_entry_rundown(de);
8ce584c7416d8a Al Viro 2013-03-30 744 if (de == root)
8ce584c7416d8a Al Viro 2013-03-30 745 break;
8ce584c7416d8a Al Viro 2013-03-30 746 pde_put(de);
8ce584c7416d8a Al Viro 2013-03-30 747
ecf1a3dfff22bd Waiman Long 2015-09-09 748 write_lock(&proc_subdir_lock);
8ce584c7416d8a Al Viro 2013-03-30 749 de = next;
8ce584c7416d8a Al Viro 2013-03-30 750 }
8ce584c7416d8a Al Viro 2013-03-30 751 pde_put(root);
8ce584c7416d8a Al Viro 2013-03-30 752 return 0;
8ce584c7416d8a Al Viro 2013-03-30 753 }
8ce584c7416d8a Al Viro 2013-03-30 754 EXPORT_SYMBOL(remove_proc_subtree);
4a520d2769beb7 David Howells 2013-04-12 755
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* Re: [PATCH] proc: faster open/read/close with "permanent" files (fwd)
From: Julia Lawall @ 2020-02-20 14:47 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: akpm, linux-kernel, linux-fsdevel, linux-kernel, linux-fsdevel,
kbuild-all
Hello,
It looks like an unlock may be needed o lines 721 and 732.
julia
---------- Forwarded message ----------
Hi Alexey,
I love your patch! Perhaps something to improve:
[auto build test WARNING on jeyu/modules-next]
[also build test WARNING on linus/master v5.6-rc2 next-20200218]
[cannot apply to linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Alexey-Dobriyan/proc-faster-open-read-close-with-permanent-files/20200218-231203
base: https://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git modules-next
:::::: branch date: 6 hours ago
:::::: commit date: 6 hours ago
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
>> fs/proc/generic.c:721:2-8: preceding lock on line 706
fs/proc/generic.c:732:4-10: preceding lock on line 706
fs/proc/generic.c:732:4-10: preceding lock on line 748
# https://github.com/0day-ci/linux/commit/3cd4ad42ca7c52d1513e7ba9f08a06197a7380c8
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 3cd4ad42ca7c52d1513e7ba9f08a06197a7380c8
vim +721 fs/proc/generic.c
8ce584c7416d8a Al Viro 2013-03-30 699
8ce584c7416d8a Al Viro 2013-03-30 700 int remove_proc_subtree(const char *name, struct proc_dir_entry *parent)
8ce584c7416d8a Al Viro 2013-03-30 701 {
8ce584c7416d8a Al Viro 2013-03-30 702 struct proc_dir_entry *root = NULL, *de, *next;
8ce584c7416d8a Al Viro 2013-03-30 703 const char *fn = name;
8ce584c7416d8a Al Viro 2013-03-30 704 unsigned int len;
8ce584c7416d8a Al Viro 2013-03-30 705
ecf1a3dfff22bd Waiman Long 2015-09-09 @706 write_lock(&proc_subdir_lock);
8ce584c7416d8a Al Viro 2013-03-30 707 if (__xlate_proc_name(name, &parent, &fn) != 0) {
ecf1a3dfff22bd Waiman Long 2015-09-09 708 write_unlock(&proc_subdir_lock);
8ce584c7416d8a Al Viro 2013-03-30 709 return -ENOENT;
8ce584c7416d8a Al Viro 2013-03-30 710 }
8ce584c7416d8a Al Viro 2013-03-30 711 len = strlen(fn);
8ce584c7416d8a Al Viro 2013-03-30 712
710585d4922fd3 Nicolas Dichtel 2014-12-10 713 root = pde_subdir_find(parent, fn, len);
8ce584c7416d8a Al Viro 2013-03-30 714 if (!root) {
ecf1a3dfff22bd Waiman Long 2015-09-09 715 write_unlock(&proc_subdir_lock);
8ce584c7416d8a Al Viro 2013-03-30 716 return -ENOENT;
8ce584c7416d8a Al Viro 2013-03-30 717 }
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 718 if (unlikely(pde_is_permanent(root))) {
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 719 WARN(1, "removing permanent /proc entry '%s/%s'",
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 720 root->parent->name, root->name);
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 @721 return -EINVAL;
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 722 }
4f1134370a29a5 Alexey Dobriyan 2018-04-10 723 rb_erase(&root->subdir_node, &parent->subdir);
710585d4922fd3 Nicolas Dichtel 2014-12-10 724
8ce584c7416d8a Al Viro 2013-03-30 725 de = root;
8ce584c7416d8a Al Viro 2013-03-30 726 while (1) {
710585d4922fd3 Nicolas Dichtel 2014-12-10 727 next = pde_subdir_first(de);
8ce584c7416d8a Al Viro 2013-03-30 728 if (next) {
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 729 if (unlikely(pde_is_permanent(root))) {
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 730 WARN(1, "removing permanent /proc entry '%s/%s'",
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 731 next->parent->name, next->name);
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 732 return -EINVAL;
3cd4ad42ca7c52 Alexey Dobriyan 2020-02-16 733 }
4f1134370a29a5 Alexey Dobriyan 2018-04-10 734 rb_erase(&next->subdir_node, &de->subdir);
8ce584c7416d8a Al Viro 2013-03-30 735 de = next;
8ce584c7416d8a Al Viro 2013-03-30 736 continue;
8ce584c7416d8a Al Viro 2013-03-30 737 }
8ce584c7416d8a Al Viro 2013-03-30 738 next = de->parent;
8ce584c7416d8a Al Viro 2013-03-30 739 if (S_ISDIR(de->mode))
8ce584c7416d8a Al Viro 2013-03-30 740 next->nlink--;
e06689bf57017a Alexey Dobriyan 2019-12-04 741 write_unlock(&proc_subdir_lock);
e06689bf57017a Alexey Dobriyan 2019-12-04 742
e06689bf57017a Alexey Dobriyan 2019-12-04 743 proc_entry_rundown(de);
8ce584c7416d8a Al Viro 2013-03-30 744 if (de == root)
8ce584c7416d8a Al Viro 2013-03-30 745 break;
8ce584c7416d8a Al Viro 2013-03-30 746 pde_put(de);
8ce584c7416d8a Al Viro 2013-03-30 747
ecf1a3dfff22bd Waiman Long 2015-09-09 748 write_lock(&proc_subdir_lock);
8ce584c7416d8a Al Viro 2013-03-30 749 de = next;
8ce584c7416d8a Al Viro 2013-03-30 750 }
8ce584c7416d8a Al Viro 2013-03-30 751 pde_put(root);
8ce584c7416d8a Al Viro 2013-03-30 752 return 0;
8ce584c7416d8a Al Viro 2013-03-30 753 }
8ce584c7416d8a Al Viro 2013-03-30 754 EXPORT_SYMBOL(remove_proc_subtree);
4a520d2769beb7 David Howells 2013-04-12 755
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH 16/18] clocksource: Replace setup_irq() by request_irq()
From: Linus Walleij @ 2020-02-20 14:48 UTC (permalink / raw)
To: afzal mohammed
Cc: linux-kernel@vger.kernel.org, linux-rpi-kernel, Linux ARM,
linux-samsung-soc, open list:ARM/Amlogic Meson..., Daniel Lezcano,
Thomas Gleixner, Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, Nicolas Saenz Julienne, Kukjin Kim,
Krzysztof Kozlowski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Barry Song, Uwe Kleine-König, Kevin Hilman, Tony Prisk,
Allison Randal, Enrico Weigelt, Greg Kroah-Hartman, Kate Stewart
In-Reply-To: <109d17402bc75ed186a2e151dfda1edf05463b5a.1581478324.git.afzal.mohd.ma@gmail.com>
On Wed, Feb 12, 2020 at 9:05 AM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> request_irq() is preferred over setup_irq(). Existing callers of
> setup_irq() reached mostly via 'init_IRQ()' & 'time_init()', while
> memory allocators are ready by 'mm_init()'.
>
> Per tglx[1], setup_irq() existed in olden days when allocators were not
> ready by the time early interrupts were initialized.
>
> Hence replace setup_irq() by request_irq().
>
> Seldom remove_irq() usage has been observed coupled with setup_irq(),
> wherever that has been found, it too has been replaced by free_irq().
>
> [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos
>
> Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
This makes the kernel a better place.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* S variable for svn fetcher Was: State of OE world - 2020-02-18
From: Martin Jansa @ 2020-02-20 14:48 UTC (permalink / raw)
To: Khem Raj; +Cc: openembeded-devel
In-Reply-To: <CAMKF1squjefU4rg3Rzn6Xn85mLkRHwWr5jha3YU18Z3rT3J-2g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2571 bytes --]
On Wed, Feb 19, 2020 at 09:29:58AM -0800, Khem Raj wrote:
> http://www.openembedded.org/wiki/Bitbake_World_Status
>
> == Failed tasks /media/ra_build_share/buildlogs/oe/world/dunfell/2020-02-18 ==
>
> INFO: jenkins-job.sh-1.8.46 Complete log available at
> /media/ra_build_share/buildlogs/oe/world/dunfell//media/ra_build_share/buildlogs/oe/world/dunfell/log.report.20200219_150007.log
>
> === common (0) ===
>
> === common-x86 (0) ===
>
> === qemuarm (0) ===
>
> === qemuarm64 (0) ===
>
> === qemux86 (0) ===
>
> === qemux86_64 (0) ===
Looks great! Thanks
I was running some world builds recently as well and was surprised that
there are a few failing recipes in meta-oe:
s3c24xx-gpio
s3c64xx-gpio
wmiconfig
usbpath
which are all using svn fetcher.
Any idea why these aren't shown in our build? I was able to reproduce
this on thud as well as latest master build:
/OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/usbpath/usbpath_svn.bb:do_patch
/OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_svn.bb:do_compile
/OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_svn.bb:do_compile
/OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_svn.bb:do_populate_lic
/OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_svn.bb:do_populate_lic
/OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/wmiconfig/wmiconfig_svn.bb:do_patch
they have all the same root cause and that is that the
S variable points to directory where the sources used to be, but now
they are checked out somewhere else, e.g. s3c24xx-gpio:
LIC_FILES_CHKSUM = "file://gpio.c;endline=12;md5=cfb91c686857b2e60852b4925d90a3e1"
SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=gpio;protocol=http"
S = "${WORKDIR}/gpio"
And now S looks like this:
$ ls /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/s3c24xx-gpio/1.0+svnr4949-r2/gpio/
branches trunk
While before I believe it was checking out just this directory (as ${WORKDIR}/gpio):
$ ls /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/s3c24xx-gpio/1.0+svnr4949-r2/gpio/trunk/src/target/gpio/
gpio.c gpio-glamo.c gpio-s3c6410.c Makefile README
Anyone still actively using svn fetcher for something?
I'll check with even older bitbake to see when it changed, but it's
still surprising that you wouldn't be seeing it with latest bitbake
in world builds.
Cheers,
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 201 bytes --]
^ permalink raw reply
* Re: [PATCH 16/18] clocksource: Replace setup_irq() by request_irq()
From: Linus Walleij @ 2020-02-20 14:48 UTC (permalink / raw)
To: afzal mohammed
Cc: Kate Stewart, Fabio Estevam, linux-samsung-soc, Kevin Hilman,
Daniel Lezcano, Allison Randal, Krzysztof Kozlowski, Kukjin Kim,
bcm-kernel-feedback-list, NXP Linux Team, Uwe Kleine-König,
Ray Jui, Sascha Hauer, Florian Fainelli, linux-rpi-kernel,
open list:ARM/Amlogic Meson..., Thomas Gleixner, Linux ARM,
Barry Song, Scott Branden, Enrico Weigelt,
linux-kernel@vger.kernel.org, Tony Prisk, Pengutronix Kernel Team,
Greg Kroah-Hartman, Shawn Guo, Nicolas Saenz Julienne
In-Reply-To: <109d17402bc75ed186a2e151dfda1edf05463b5a.1581478324.git.afzal.mohd.ma@gmail.com>
On Wed, Feb 12, 2020 at 9:05 AM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> request_irq() is preferred over setup_irq(). Existing callers of
> setup_irq() reached mostly via 'init_IRQ()' & 'time_init()', while
> memory allocators are ready by 'mm_init()'.
>
> Per tglx[1], setup_irq() existed in olden days when allocators were not
> ready by the time early interrupts were initialized.
>
> Hence replace setup_irq() by request_irq().
>
> Seldom remove_irq() usage has been observed coupled with setup_irq(),
> wherever that has been found, it too has been replaced by free_irq().
>
> [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos
>
> Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
This makes the kernel a better place.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
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 16/18] clocksource: Replace setup_irq() by request_irq()
From: Linus Walleij @ 2020-02-20 14:48 UTC (permalink / raw)
To: afzal mohammed
Cc: Kate Stewart, Fabio Estevam, linux-samsung-soc, Kevin Hilman,
Daniel Lezcano, Allison Randal, Krzysztof Kozlowski, Kukjin Kim,
bcm-kernel-feedback-list, NXP Linux Team, Uwe Kleine-König,
Ray Jui, Sascha Hauer, Florian Fainelli, linux-rpi-kernel,
open list:ARM/Amlogic Meson..., Thomas Gleixner, Linux ARM,
Barry Song, Scott Branden, Enrico Weigelt,
linux-kernel@vger.kernel.org, Tony Prisk, Pengutronix Kernel Team,
Greg Kroah-Hartman, Shawn Guo, Nicolas Saenz Julienne
In-Reply-To: <109d17402bc75ed186a2e151dfda1edf05463b5a.1581478324.git.afzal.mohd.ma@gmail.com>
On Wed, Feb 12, 2020 at 9:05 AM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> request_irq() is preferred over setup_irq(). Existing callers of
> setup_irq() reached mostly via 'init_IRQ()' & 'time_init()', while
> memory allocators are ready by 'mm_init()'.
>
> Per tglx[1], setup_irq() existed in olden days when allocators were not
> ready by the time early interrupts were initialized.
>
> Hence replace setup_irq() by request_irq().
>
> Seldom remove_irq() usage has been observed coupled with setup_irq(),
> wherever that has been found, it too has been replaced by free_irq().
>
> [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos
>
> Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
This makes the kernel a better place.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* Re: [PATCH 18/18] genirq: Remove setup_irq() and remove_irq()
From: Linus Walleij @ 2020-02-20 14:49 UTC (permalink / raw)
To: afzal mohammed
Cc: linux-kernel@vger.kernel.org, Thomas Gleixner, Marc Zyngier,
Peter Xu, Brian Masney, Maulik Shah, Lokesh Vutla
In-Reply-To: <0570d4c790f89fa070835fbaa4a106ec07ae6b76.1581478324.git.afzal.mohd.ma@gmail.com>
On Wed, Feb 12, 2020 at 9:06 AM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> Now that all the users of setup_irq() & remove_irq() has been replaced
> by request_irq() & free_irq() respectively, delete them.
>
> Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
Nice, cutting down and simplifying core code.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 08/10] arm64: tegra: add AHUB components for few Tegra chips
From: Jon Hunter @ 2020-02-20 14:49 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-9-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> This patch adds few AHUB modules for Tegra210, Tegra186 and Tegra194.
> Following modules are common to all above SoCs,
> * AHUB added as a child node under ACONNECT
> * AHUB includes many HW accelerators and below components are added
> as its children.
> * ADMAIF
> * I2S
> * DMIC
> * DSPK (added for Tegra186 and Tegra194 only, since Tegra210 does
> not have this module)
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 231 ++++++++++++++++++++++++++++-
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 239 ++++++++++++++++++++++++++++++-
> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 145 +++++++++++++++++++
> 3 files changed, 613 insertions(+), 2 deletions(-)
Thanks!
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 08/10] arm64: tegra: add AHUB components for few Tegra chips
From: Jon Hunter @ 2020-02-20 14:49 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: broonie, lgirdwood, thierry.reding, digetx, alsa-devel,
devicetree, linux-tegra, linux-kernel, sharadg, mkumard,
viswanathl, rlokhande, dramesh, atalambedu
In-Reply-To: <1582180492-25297-9-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> This patch adds few AHUB modules for Tegra210, Tegra186 and Tegra194.
> Following modules are common to all above SoCs,
> * AHUB added as a child node under ACONNECT
> * AHUB includes many HW accelerators and below components are added
> as its children.
> * ADMAIF
> * I2S
> * DMIC
> * DSPK (added for Tegra186 and Tegra194 only, since Tegra210 does
> not have this module)
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 231 ++++++++++++++++++++++++++++-
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 239 ++++++++++++++++++++++++++++++-
> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 145 +++++++++++++++++++
> 3 files changed, 613 insertions(+), 2 deletions(-)
Thanks!
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 0/5] Support Argon2 KDF in LUKS2
From: Patrick Steinhardt @ 2020-02-20 14:50 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Daniel Kiper, gmazyland, leif, agraf, pjones, mjg59, phcoder
In-Reply-To: <20200213114259.j5oalczscie6unyr@tomti.i.net-space.pl>
[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]
On Thu, Feb 13, 2020 at 12:42:59PM +0100, Daniel Kiper wrote:
> On Wed, Feb 12, 2020 at 08:47:49AM +0100, Patrick Steinhardt wrote:
> > On Tue, Feb 11, 2020 at 10:53:59PM +0100, Daniel Kiper wrote:
> > > > GRUB's codebase. This included both stripping off unneeded
> > > > functionality as well as converting the code to use our own coding
> > >
> > > Stripping unneeded functionality is OK. However, I think that it does
> > > not make sense to convert coding style to the GRUB one. Especially if we
> > > do not do that for other modules. So, I would leave coding style in
> > > Argon2 module as is and save your precious minutes for something more
> > > productive... ;-)
> >
> >
> > Fair enough, I'll send out a v2 with the original coding style. I
> > thought as much when I was ready with v1, but was too lazy to do the
> > work and change back the coding style.
> >
> > Anyway, to save myself another roundtrip: would you prefer to merge
> > Argon2 functionality into a single file like I've done it right now or
> > to retain the original set of files? The reason why I've opted for the
> > latter is mainly to be able to annotate more functions as static.
>
> I think that you should retain original set of files. And please add
> a description to the docs/grub-dev.texi how to update Argon2 lib in
> the future.
>
> Daniel
In the ideal case, we'd just compile Argon2 with the POSIX compat layer
so that we wouldn't need to modify most of the types and functions used
by it, like uint32, malloc, etc. As a result, libgrubkern.a would grow a
dependency on C{,PP}FLAGS_POSIX, though. I did notice compilation errors
in other modules when trying that, so my question is which path to go:
fix resulting incompatibilities when adding POSIX includes or just
replace types and function calls in Argon2 code?
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 08/10] arm64: tegra: add AHUB components for few Tegra chips
From: Jon Hunter @ 2020-02-20 14:49 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: devicetree, alsa-devel, atalambedu, lgirdwood, linux-kernel,
viswanathl, sharadg, broonie, thierry.reding, linux-tegra, digetx,
rlokhande, mkumard, dramesh
In-Reply-To: <1582180492-25297-9-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> This patch adds few AHUB modules for Tegra210, Tegra186 and Tegra194.
> Following modules are common to all above SoCs,
> * AHUB added as a child node under ACONNECT
> * AHUB includes many HW accelerators and below components are added
> as its children.
> * ADMAIF
> * I2S
> * DMIC
> * DSPK (added for Tegra186 and Tegra194 only, since Tegra210 does
> not have this module)
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 231 ++++++++++++++++++++++++++++-
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 239 ++++++++++++++++++++++++++++++-
> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 145 +++++++++++++++++++
> 3 files changed, 613 insertions(+), 2 deletions(-)
Thanks!
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Corey Minyard @ 2020-02-20 14:50 UTC (permalink / raw)
To: Marc Zyngier
Cc: Will Deacon, Catalin Marinas, linux-arm-kernel, Corey Minyard,
linux-kernel
In-Reply-To: <1416dca51b52dff349923184f41d48e8@kernel.org>
On Thu, Feb 20, 2020 at 02:21:36PM +0000, Marc Zyngier wrote:
> On 2020-02-19 15:24, minyard@acm.org wrote:
> > From: Corey Minyard <cminyard@mvista.com>
>
> [...]
>
> > After studying the EL0 handling for this, I realized an issue with using
> > MDSCR to check if single step is enabled: it can be expensive on a VM.
> > So check the task flag first to see if single step is enabled. Then
> > check MDSCR if the task flag is set.
>
> Very tangential remark: I'd really like people *not* to try and optimize
> Linux based on the behaviour of a hypervisor. In general, reading a
> system register is fast, and the fact that it traps on a given hypervisor
> at some point may not be true in the future, nor be a valid assumption
> across hypervisors.
Normally I would agree, but I based this upon git commit
https://github.com/torvalds/linux/commit/2a2830703a2371b47f7b50b1d35cb15dc0e2b717
which seemed to say that it was a significant enough factor to do in the
EL0 case.
-corey
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v3 0/3] arm: allwinner: Wire up USB ports
From: Peter Maydell @ 2020-02-20 14:50 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Beniamino Galvani, qemu-arm, Gerd Hoffmann, QEMU Developers
In-Reply-To: <20200217204812.9857-1-linux@roeck-us.net>
On Mon, 17 Feb 2020 at 20:48, Guenter Roeck <linux@roeck-us.net> wrote:
>
> Instantiate EHCI and OHCI controllers on Allwinner A10.
>
> The first patch in the series moves the declaration of EHCISysBusState
> from hcd-ohci.c to hcd-ohci.h. This lets us add the structure to
> AwA10State. Similar, TYPE_SYSBUS_OHCI is moved to be able to use it
> outside its driver.
>
> The second patch introduces the ehci-sysbus property "companion-enable".
> This lets us use object_property_set_bool() to enable companion mode.
>
> The third patch instantiates EHCI and OHCI ports for Allwinner-A10
> and marks the OHCI ports as companions of the respective EHCI ports.
>
> Tested by attaching various high speed and full speed devices, and by
> booting from USB drive.
>
> v3: Rebased to master
> v2: Add summary
> Rewrite to instantiate OHCI in companion mode; add patch 2/3
> Merge EHCI and OHCI instantiation into a single patch
>
Applied to target-arm.next, thanks.
-- PMM
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Corey Minyard @ 2020-02-20 14:50 UTC (permalink / raw)
To: Marc Zyngier
Cc: Catalin Marinas, Will Deacon, linux-kernel, linux-arm-kernel,
Corey Minyard
In-Reply-To: <1416dca51b52dff349923184f41d48e8@kernel.org>
On Thu, Feb 20, 2020 at 02:21:36PM +0000, Marc Zyngier wrote:
> On 2020-02-19 15:24, minyard@acm.org wrote:
> > From: Corey Minyard <cminyard@mvista.com>
>
> [...]
>
> > After studying the EL0 handling for this, I realized an issue with using
> > MDSCR to check if single step is enabled: it can be expensive on a VM.
> > So check the task flag first to see if single step is enabled. Then
> > check MDSCR if the task flag is set.
>
> Very tangential remark: I'd really like people *not* to try and optimize
> Linux based on the behaviour of a hypervisor. In general, reading a
> system register is fast, and the fact that it traps on a given hypervisor
> at some point may not be true in the future, nor be a valid assumption
> across hypervisors.
Normally I would agree, but I based this upon git commit
https://github.com/torvalds/linux/commit/2a2830703a2371b47f7b50b1d35cb15dc0e2b717
which seemed to say that it was a significant enough factor to do in the
EL0 case.
-corey
>
> M.
> --
> Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v3 05/27] qcow2: Document the Extended L2 Entries feature
From: Alberto Garcia @ 2020-02-20 14:49 UTC (permalink / raw)
To: Eric Blake, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <3a946970-5a26-6c40-a212-0aefdccef509@redhat.com>
On Thu 20 Feb 2020 03:28:17 PM CET, Eric Blake wrote:
>> +An image uses Extended L2 Entries if bit 3 is set on the incompatible_features
>> +field of the header.
>> +
>> +In these images standard data clusters are divided into 32 subclusters of the
>> +same size. They are contiguous and start from the beginning of the cluster.
>> +Subclusters can be allocated independently and the L2 entry contains information
>> +indicating the status of each one of them. Compressed data clusters don't have
>> +subclusters so they are treated like in images without this feature.
>
> Grammar; I'd suggest:
>
> ...don't have subclusters, so they are treated the same as in images
> without this feature.
Ok
> Are they truly the same, or do you still need to document that the
> extra 64 bits of the extended L2 entry are all zero?
It is documented later in the same patch ("Subcluster Allocation Bitmap
for compressed clusters").
By the way, this series treats an L2 entry as invalid if any of those
bits is not zero, but I think I'll change that. Conceivably those bits
could be used for a future compatible feature, but it can only be
compatible if the previous versions ignore those bits.
>> + 32 - 63 Subcluster reads as zeros (one bit per subcluster)
>> +
>> + 1: the subcluster reads as zeros. In this case the
>> + allocation status bit must be unset. The host
>> + cluster offset field may or may not be set.
>
> Why must the allocation bit be unset? When we preallocate, we want a
> cluster to reserve space, but still read as zero, so the combination
> of both bits set makes sense to me.
Since 00 means unallocated and 01 allocated, there are two options left
to represent the "reads as zero" case: 10 and 11.
I think that one could argue for either one and there is no "right"
choice. I chose the former because I understood the allocation bit as
"the guest visible data is obtained from the raw data in that
subcluster" but the other option also makes sense.
Berto
^ permalink raw reply
* [PATCH 1/3] regulator: max14577: Add proper dt-compatible strings
From: Marek Szyprowski @ 2020-02-20 14:51 UTC (permalink / raw)
To: linux-pm, linux-kernel
Cc: Marek Szyprowski, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz,
Chanwoo Choi, MyungJoo Ham, Sebastian Reichel, Mark Brown
In-Reply-To: <CGME20200220145134eucas1p288ae1910d3e8d12dc12f010ed0b07b45@eucas1p2.samsung.com>
Add device tree compatible strings and create proper modalias structures
to let this driver load automatically if compiled as module, because
max14577 MFD driver creates MFD cells with such compatible strings.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/regulator/max14577-regulator.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/regulator/max14577-regulator.c b/drivers/regulator/max14577-regulator.c
index 07a150c9bbf2..19e779dd961e 100644
--- a/drivers/regulator/max14577-regulator.c
+++ b/drivers/regulator/max14577-regulator.c
@@ -238,6 +238,15 @@ static const struct platform_device_id max14577_regulator_id[] = {
};
MODULE_DEVICE_TABLE(platform, max14577_regulator_id);
+static const struct of_device_id of_max14577_regulator_dt_match[] = {
+ { .compatible = "maxim,max77836-regulator",
+ .data = (void *)MAXIM_DEVICE_TYPE_MAX77836, },
+ { .compatible = "maxim,max14577-regulator",
+ .data = (void *)MAXIM_DEVICE_TYPE_MAX14577, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_max14577_regulator_dt_match);
+
static struct platform_driver max14577_regulator_driver = {
.driver = {
.name = "max14577-regulator",
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v1 0/2] perf report: Support annotation of code without symbols
From: Jiri Olsa @ 2020-02-20 14:51 UTC (permalink / raw)
To: Jin, Yao
Cc: acme, jolsa, peterz, mingo, alexander.shishkin, Linux-kernel, ak,
kan.liang, yao.jin
In-Reply-To: <1fc1c4f5-ca94-ebd7-fae0-28765070662f@linux.intel.com>
On Thu, Feb 20, 2020 at 10:42:11PM +0800, Jin, Yao wrote:
>
>
> On 2/20/2020 8:06 PM, Jiri Olsa wrote:
> > On Thu, Feb 20, 2020 at 08:03:18PM +0800, Jin, Yao wrote:
> > >
> > >
> > > On 2/20/2020 7:56 PM, Jiri Olsa wrote:
> > > > On Thu, Feb 20, 2020 at 08:59:00AM +0800, Jin Yao wrote:
> > > > > For perf report on stripped binaries it is currently impossible to do
> > > > > annotation. The annotation state is all tied to symbols, but there are
> > > > > either no symbols, or symbols are not covering all the code.
> > > > >
> > > > > We should support the annotation functionality even without symbols.
> > > > >
> > > > > The first patch uses al_addr to print because it's easy to dump
> > > > > the instructions from this address in binary for branch mode.
> > > > >
> > > > > The second patch supports the annotation on stripped binary.
> > > > >
> > > > > Jin Yao (2):
> > > > > perf util: Print al_addr when symbol is not found
> > > > > perf annotate: Support interactive annotation of code without symbols
> > > >
> > > > looks good, but I'm getting crash when annotating unresolved kernel address:
> > > >
> > > > jirka
> > > >
> > > >
> > >
> > > Thanks for reporting the issue.
> > >
> > > I guess you are trying the "0xffffffff81c00ae7", let me try to reproduce
> > > this issue.
> >
> > yes, I also checked and it did not happen before
> >
> > jirka
> >
>
> Hi Jiri,
>
> Can you try this fix?
>
> diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
> index ff5711899234..5144528b2931 100644
> --- a/tools/perf/ui/browsers/hists.c
> +++ b/tools/perf/ui/browsers/hists.c
> @@ -2497,7 +2497,7 @@ add_annotate_opt(struct hist_browser *browser,
> struct map_symbol *ms,
> u64 addr)
> {
> - if (ms->map->dso->annotate_warned)
> + if (!ms->map || !ms->map->dso || ms->map->dso->annotate_warned)
> return 0;
>
> if (!ms->sym) {
>
> It's tested OK at my side.
yep, the crash is gone
thanks,
jirka
^ permalink raw reply
* [PATCH 2/3] extcon: max14577: Add proper dt-compatible strings
From: Marek Szyprowski @ 2020-02-20 14:51 UTC (permalink / raw)
To: linux-pm, linux-kernel
Cc: Marek Szyprowski, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz,
Chanwoo Choi, MyungJoo Ham, Sebastian Reichel, Mark Brown
In-Reply-To: <20200220145127.21273-1-m.szyprowski@samsung.com>
Add device tree compatible strings and create proper modalias structures
to let this driver load automatically if compiled as module, because
max14577 MFD driver creates MFD cells with such compatible strings.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/extcon/extcon-max14577.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 32f663436e6e..6df814cffe37 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -782,6 +782,15 @@ static const struct platform_device_id max14577_muic_id[] = {
};
MODULE_DEVICE_TABLE(platform, max14577_muic_id);
+static const struct of_device_id of_max14577_muic_dt_match[] = {
+ { .compatible = "maxim,max77836-muic",
+ .data = (void *)MAXIM_DEVICE_TYPE_MAX77836, },
+ { .compatible = "maxim,max14577-muic",
+ .data = (void *)MAXIM_DEVICE_TYPE_MAX14577, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_max14577_muic_dt_match);
+
static struct platform_driver max14577_muic_driver = {
.driver = {
.name = "max14577-muic",
--
2.17.1
^ permalink raw reply related
* [PATCH 3/3] power: charger: max14577: Add proper dt-compatible strings
From: Marek Szyprowski @ 2020-02-20 14:51 UTC (permalink / raw)
To: linux-pm, linux-kernel
Cc: Marek Szyprowski, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz,
Chanwoo Choi, MyungJoo Ham, Sebastian Reichel, Mark Brown
In-Reply-To: <20200220145127.21273-1-m.szyprowski@samsung.com>
Add device tree compatible strings and create proper modalias structures
to let this driver load automatically if compiled as module, because
max14577 MFD driver creates MFD cells with such compatible strings.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/power/supply/max14577_charger.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/power/supply/max14577_charger.c b/drivers/power/supply/max14577_charger.c
index 8a59feac6468..891ba9f6f295 100644
--- a/drivers/power/supply/max14577_charger.c
+++ b/drivers/power/supply/max14577_charger.c
@@ -623,6 +623,15 @@ static const struct platform_device_id max14577_charger_id[] = {
};
MODULE_DEVICE_TABLE(platform, max14577_charger_id);
+static const struct of_device_id of_max14577_charger_dt_match[] = {
+ { .compatible = "maxim,max77836-charger",
+ .data = (void *)MAXIM_DEVICE_TYPE_MAX77836, },
+ { .compatible = "maxim,max14577-charger",
+ .data = (void *)MAXIM_DEVICE_TYPE_MAX14577, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_max14577_charger_dt_match);
+
static struct platform_driver max14577_charger_driver = {
.driver = {
.name = "max14577-charger",
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 09/10] arm64: tegra: enable AHUB modules for few Tegra chips
From: Jon Hunter @ 2020-02-20 14:52 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-10-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> This patch enables AHUB, ADMAIF modules for following Tegra platforms.
> Along with this specific instances of I/O modules are enabled as per
> the board design.
>
> * Jetson TX1
> - I2S1, I2S2, I2S3, I2S4 and I2S5
> - DMIC1, DMIC2 and DMIC3
>
> * Jetson TX2
> - I2S1, I2S2, I2S3, I2S4, I2S5 and I2S6
> - DMIC1, DMIC2 and DMIC3
> - DSPK2
>
> * Jetson AGX Xavier
> - I2S1, I2S2, I2S4 and I2S6
> - DMIC2 and DMIC3
> - DSPK1
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts | 48 ++++++++++++++++++++++
> arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts | 36 ++++++++++++++++
> arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts | 40 ++++++++++++++++++
> 3 files changed, 124 insertions(+)
Thanks!
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.