* Re: [GIT PULL] KVM/arm fixes for 5.2-rc6
From: Paolo Bonzini @ 2019-06-20 11:38 UTC (permalink / raw)
To: Marc Zyngier, Radim Krčmář
Cc: Andrew Jones, kvm, Suzuki K Poulose, Viresh Kumar, Julien Thierry,
kvmarm, James Morse, Dave Martin, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
On 20/06/19 13:22, Marc Zyngier wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-for-5.2-2
Pulled, thanks.
Paolo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] KVM/arm fixes for 5.2-rc6
From: Paolo Bonzini @ 2019-06-20 11:38 UTC (permalink / raw)
To: Marc Zyngier, Radim Krčmář
Cc: kvm, Viresh Kumar, kvmarm, Dave Martin, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
On 20/06/19 13:22, Marc Zyngier wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-for-5.2-2
Pulled, thanks.
Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [GIT PULL] KVM/arm fixes for 5.2-rc6
From: Paolo Bonzini @ 2019-06-20 11:38 UTC (permalink / raw)
To: Marc Zyngier, Radim Krčmář
Cc: Andrew Jones, Dave Martin, Viresh Kumar, Julien Thierry,
James Morse, Suzuki K Poulose, kvm, kvmarm, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
On 20/06/19 13:22, Marc Zyngier wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-for-5.2-2
Pulled, thanks.
Paolo
^ permalink raw reply
* [tip:x86/cpu] x86/cpufeatures: Combine word 11 and 12 into a new scattered features word
From: tip-bot for Fenghua Yu @ 2019-06-20 11:37 UTC (permalink / raw)
To: linux-tip-commits
Cc: pfeiner, mingo, ravi.v.shankar, Thomas.Lendacky, linux-kernel,
hpa, sean.j.christopherson, luto, rafael.j.wysocki, mhiramat,
jgross, yamada.masahiro, fenghua.yu, chang.seok.bae, peterz,
pasha.tatashin, kvm, frederic, babu.moger, aaronlewis, bp,
konrad.wilk, x86, sherry.hurwitz, pbonzini, jannh, namit, mingo,
tglx, rkrcmar
In-Reply-To: <1560794416-217638-2-git-send-email-fenghua.yu@intel.com>
Commit-ID: acec0ce081de0c36459eea91647faf99296445a3
Gitweb: https://git.kernel.org/tip/acec0ce081de0c36459eea91647faf99296445a3
Author: Fenghua Yu <fenghua.yu@intel.com>
AuthorDate: Wed, 19 Jun 2019 18:51:09 +0200
Committer: Borislav Petkov <bp@suse.de>
CommitDate: Thu, 20 Jun 2019 12:38:44 +0200
x86/cpufeatures: Combine word 11 and 12 into a new scattered features word
It's a waste for the four X86_FEATURE_CQM_* feature bits to occupy two
whole feature bits words. To better utilize feature words, re-define
word 11 to host scattered features and move the four X86_FEATURE_CQM_*
features into Linux defined word 11. More scattered features can be
added in word 11 in the future.
Rename leaf 11 in cpuid_leafs to CPUID_LNX_4 to reflect it's a
Linux-defined leaf.
Rename leaf 12 as CPUID_DUMMY which will be replaced by a meaningful
name in the next patch when CPUID.7.1:EAX occupies world 12.
Maximum number of RMID and cache occupancy scale are retrieved from
CPUID.0xf.1 after scattered CQM features are enumerated. Carve out the
code into a separate function.
KVM doesn't support resctrl now. So it's safe to move the
X86_FEATURE_CQM_* features to scattered features word 11 for KVM.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Aaron Lewis <aaronlewis@google.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Babu Moger <babu.moger@amd.com>
Cc: "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: "Sean J Christopherson" <sean.j.christopherson@intel.com>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jann Horn <jannh@google.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: kvm ML <kvm@vger.kernel.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Nadav Amit <namit@vmware.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Peter Feiner <pfeiner@google.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: Ravi V Shankar <ravi.v.shankar@intel.com>
Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>
Cc: x86 <x86@kernel.org>
Link: https://lkml.kernel.org/r/1560794416-217638-2-git-send-email-fenghua.yu@intel.com
---
arch/x86/include/asm/cpufeature.h | 4 ++--
arch/x86/include/asm/cpufeatures.h | 17 ++++++++++-------
arch/x86/kernel/cpu/common.c | 38 +++++++++++++++-----------------------
arch/x86/kernel/cpu/cpuid-deps.c | 3 +++
arch/x86/kernel/cpu/scattered.c | 4 ++++
arch/x86/kvm/cpuid.h | 2 --
6 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index 1d337c51f7e6..403f70c2e431 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -22,8 +22,8 @@ enum cpuid_leafs
CPUID_LNX_3,
CPUID_7_0_EBX,
CPUID_D_1_EAX,
- CPUID_F_0_EDX,
- CPUID_F_1_EDX,
+ CPUID_LNX_4,
+ CPUID_DUMMY,
CPUID_8000_0008_EBX,
CPUID_6_EAX,
CPUID_8000_000A_EDX,
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 1017b9c7dfe0..be858b86023a 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -271,13 +271,16 @@
#define X86_FEATURE_XGETBV1 (10*32+ 2) /* XGETBV with ECX = 1 instruction */
#define X86_FEATURE_XSAVES (10*32+ 3) /* XSAVES/XRSTORS instructions */
-/* Intel-defined CPU QoS Sub-leaf, CPUID level 0x0000000F:0 (EDX), word 11 */
-#define X86_FEATURE_CQM_LLC (11*32+ 1) /* LLC QoS if 1 */
-
-/* Intel-defined CPU QoS Sub-leaf, CPUID level 0x0000000F:1 (EDX), word 12 */
-#define X86_FEATURE_CQM_OCCUP_LLC (12*32+ 0) /* LLC occupancy monitoring */
-#define X86_FEATURE_CQM_MBM_TOTAL (12*32+ 1) /* LLC Total MBM monitoring */
-#define X86_FEATURE_CQM_MBM_LOCAL (12*32+ 2) /* LLC Local MBM monitoring */
+/*
+ * Extended auxiliary flags: Linux defined - for features scattered in various
+ * CPUID levels like 0xf, etc.
+ *
+ * Reuse free bits when adding new feature flags!
+ */
+#define X86_FEATURE_CQM_LLC (11*32+ 0) /* LLC QoS if 1 */
+#define X86_FEATURE_CQM_OCCUP_LLC (11*32+ 1) /* LLC occupancy monitoring */
+#define X86_FEATURE_CQM_MBM_TOTAL (11*32+ 2) /* LLC Total MBM monitoring */
+#define X86_FEATURE_CQM_MBM_LOCAL (11*32+ 3) /* LLC Local MBM monitoring */
/* AMD-defined CPU features, CPUID level 0x80000008 (EBX), word 13 */
#define X86_FEATURE_CLZERO (13*32+ 0) /* CLZERO instruction */
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index fe6ed9696467..efb114298cfb 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -803,33 +803,25 @@ static void init_speculation_control(struct cpuinfo_x86 *c)
static void init_cqm(struct cpuinfo_x86 *c)
{
- u32 eax, ebx, ecx, edx;
-
- /* Additional Intel-defined flags: level 0x0000000F */
- if (c->cpuid_level >= 0x0000000F) {
+ if (!cpu_has(c, X86_FEATURE_CQM_LLC)) {
+ c->x86_cache_max_rmid = -1;
+ c->x86_cache_occ_scale = -1;
+ return;
+ }
- /* QoS sub-leaf, EAX=0Fh, ECX=0 */
- cpuid_count(0x0000000F, 0, &eax, &ebx, &ecx, &edx);
- c->x86_capability[CPUID_F_0_EDX] = edx;
+ /* will be overridden if occupancy monitoring exists */
+ c->x86_cache_max_rmid = cpuid_ebx(0xf);
- if (cpu_has(c, X86_FEATURE_CQM_LLC)) {
- /* will be overridden if occupancy monitoring exists */
- c->x86_cache_max_rmid = ebx;
+ if (cpu_has(c, X86_FEATURE_CQM_OCCUP_LLC) ||
+ cpu_has(c, X86_FEATURE_CQM_MBM_TOTAL) ||
+ cpu_has(c, X86_FEATURE_CQM_MBM_LOCAL)) {
+ u32 eax, ebx, ecx, edx;
- /* QoS sub-leaf, EAX=0Fh, ECX=1 */
- cpuid_count(0x0000000F, 1, &eax, &ebx, &ecx, &edx);
- c->x86_capability[CPUID_F_1_EDX] = edx;
+ /* QoS sub-leaf, EAX=0Fh, ECX=1 */
+ cpuid_count(0xf, 1, &eax, &ebx, &ecx, &edx);
- if ((cpu_has(c, X86_FEATURE_CQM_OCCUP_LLC)) ||
- ((cpu_has(c, X86_FEATURE_CQM_MBM_TOTAL)) ||
- (cpu_has(c, X86_FEATURE_CQM_MBM_LOCAL)))) {
- c->x86_cache_max_rmid = ecx;
- c->x86_cache_occ_scale = ebx;
- }
- } else {
- c->x86_cache_max_rmid = -1;
- c->x86_cache_occ_scale = -1;
- }
+ c->x86_cache_max_rmid = ecx;
+ c->x86_cache_occ_scale = ebx;
}
}
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 2c0bd38a44ab..fa07a224e7b9 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -59,6 +59,9 @@ static const struct cpuid_dep cpuid_deps[] = {
{ X86_FEATURE_AVX512_4VNNIW, X86_FEATURE_AVX512F },
{ X86_FEATURE_AVX512_4FMAPS, X86_FEATURE_AVX512F },
{ X86_FEATURE_AVX512_VPOPCNTDQ, X86_FEATURE_AVX512F },
+ { X86_FEATURE_CQM_OCCUP_LLC, X86_FEATURE_CQM_LLC },
+ { X86_FEATURE_CQM_MBM_TOTAL, X86_FEATURE_CQM_LLC },
+ { X86_FEATURE_CQM_MBM_LOCAL, X86_FEATURE_CQM_LLC },
{}
};
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index 94aa1c72ca98..adf9b71386ef 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -26,6 +26,10 @@ struct cpuid_bit {
static const struct cpuid_bit cpuid_bits[] = {
{ X86_FEATURE_APERFMPERF, CPUID_ECX, 0, 0x00000006, 0 },
{ X86_FEATURE_EPB, CPUID_ECX, 3, 0x00000006, 0 },
+ { X86_FEATURE_CQM_LLC, CPUID_EDX, 1, 0x0000000f, 0 },
+ { X86_FEATURE_CQM_OCCUP_LLC, CPUID_EDX, 0, 0x0000000f, 1 },
+ { X86_FEATURE_CQM_MBM_TOTAL, CPUID_EDX, 1, 0x0000000f, 1 },
+ { X86_FEATURE_CQM_MBM_LOCAL, CPUID_EDX, 2, 0x0000000f, 1 },
{ X86_FEATURE_CAT_L3, CPUID_EBX, 1, 0x00000010, 0 },
{ X86_FEATURE_CAT_L2, CPUID_EBX, 2, 0x00000010, 0 },
{ X86_FEATURE_CDP_L3, CPUID_ECX, 2, 0x00000010, 1 },
diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
index 9a327d5b6d1f..d78a61408243 100644
--- a/arch/x86/kvm/cpuid.h
+++ b/arch/x86/kvm/cpuid.h
@@ -47,8 +47,6 @@ static const struct cpuid_reg reverse_cpuid[] = {
[CPUID_8000_0001_ECX] = {0x80000001, 0, CPUID_ECX},
[CPUID_7_0_EBX] = { 7, 0, CPUID_EBX},
[CPUID_D_1_EAX] = { 0xd, 1, CPUID_EAX},
- [CPUID_F_0_EDX] = { 0xf, 0, CPUID_EDX},
- [CPUID_F_1_EDX] = { 0xf, 1, CPUID_EDX},
[CPUID_8000_0008_EBX] = {0x80000008, 0, CPUID_EBX},
[CPUID_6_EAX] = { 6, 0, CPUID_EAX},
[CPUID_8000_000A_EDX] = {0x8000000a, 0, CPUID_EDX},
^ permalink raw reply related
* Re: [igt-dev] [PATCH i-g-t 5/5] docs: Embed subtest descriptions in the documentation
From: Arkadiusz Hiler @ 2019-06-20 11:38 UTC (permalink / raw)
To: igt-dev, Daniel Vetter
In-Reply-To: <20190620111159.GE22949@platvala-desk.ger.corp.intel.com>
On Thu, Jun 20, 2019 at 02:11:59PM +0300, Petri Latvala wrote:
> On Thu, Jun 20, 2019 at 01:52:25PM +0300, Arkadiusz Hiler wrote:
> > On Thu, Jun 20, 2019 at 11:20:18AM +0300, Petri Latvala wrote:
> > > On Mon, Jun 17, 2019 at 01:54:43PM +0300, Arkadiusz Hiler wrote:
> > > > This rewrites generate_description_xml in Python, so that we generate
> > > > properly escaped XML. The switch also makes the code more manageable.
> > > >
> > > > Changes in the generated docbook:
> > > >
> > > > 1. subtests are not simply listed anymore, they are now another (sub)section
> > > >
> > > > 2. subtests are now linkable,
> > > > e.g. docs/igt-kms-tests.html#kms_hdmi_inject@inject-4k
> > > >
> > > > 3. subtest's section now includes output of --describe
> > > >
> > > > Python is required already by gtk-doc and we are not using anything
> > > > other than the standard library.
> > >
> > > Python yes, but what about python3? My Debian installation is ancient
> > > even on Debian standards and gtk-doc-tools depends on python2. I'm too
> > > lazy to check if the version used by gitlab-CI depends on python3, so
> > > asking instead: Do you have a fork in gitlab for this? :P
> >
> > It works on Fedora:
> >
> > % head -n 1 $(which gtkdoc-mkhtml)
> > #!/usr/bin/python3
> >
> > https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/.gitlab-ci.yml#L174
> >
> >
> > But for explicitness I can squash in:
> >
> > diff --git a/docs/reference/igt-gpu-tools/meson.build b/docs/reference/igt-gpu-tools/meson.build
> > index e2bdc495..b3a4c0bd 100644
> > --- a/docs/reference/igt-gpu-tools/meson.build
> > +++ b/docs/reference/igt-gpu-tools/meson.build
> > @@ -45,6 +45,7 @@ test_groups = [
> > 'vgem',
> > ]
> >
> > +find_program('python3') # required by doc generators
> > gen_description = find_program('generate_description_xml.py')
> > gen_programs = find_program('generate_programs_xml.sh')
>
>
> For explicitness I'd prefer something the doc building can depend on
> to automatically not build them if you don't have python3.
I forgot that we have this weird conditional subdir().
diff --git a/meson.build b/meson.build
index 6268c58d..1d07af63 100644
--- a/meson.build
+++ b/meson.build
@@ -289,7 +289,8 @@ subdir('overlay')
subdir('man')
gtk_doc = dependency('gtk-doc', required : build_docs)
-if build_tests and gtk_doc.found()
+python3 = find_program('python3', required : build_docs)
+if build_tests and gtk_doc.found() and python3.found()
subdir('docs')
elif build_docs.enabled()
error('Documentation requires building tests')
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* Re: [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183
From: Matthias Brugger @ 2019-06-20 11:38 UTC (permalink / raw)
To: Pi-Hsun Shih, Yong Wu
Cc: youlin.pei,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Nicolas Boichat, srv_heupstream, Joerg Roedel, Will Deacon,
open list, Evan Green, Tomasz Figa, iommu, Rob Herring,
moderated list:ARM/Mediatek SoC support, Sascha Hauer,
yingjoe.chen, anan.sun, Robin Murphy, Matthias Kaehlcke,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <eee15db0-e43f-de9b-28a0-93bdd04836d7@gmail.com>
CCing Sascha
On 20/06/2019 11:35, Matthias Brugger wrote:
>
>
> On 13/06/2019 10:14, Pi-Hsun Shih wrote:
>> Hi,
>> When I tested this patch series (Based on linux 5.2.0-rc2, and with
>> various other patch series about MT8183) with lockdep enabled, and I'm
>> seeing the following lockdep warning on boot.
>>
>> By bisecting the commits, the first commit that introduce this warning
>> is this patch. The warning also doesn't appear if
>> https://lore.kernel.org/patchwork/patch/1086582/ and
>> https://lore.kernel.org/patchwork/patch/1086583/ are not applied.
>>
>> Do anyone have idea on why this is happening, or any suggestion on
>> which part I should be digging into to figure this out? Thanks.
>>
>> [ 4.664194] ======================================================
>> [ 4.670368] WARNING: possible circular locking dependency detected
>> [ 4.676545] 5.2.0-rc2-next-20190528-44527-g6c94b6475c04 #20 Tainted: G S
>> [ 4.684539] ------------------------------------------------------
>> [ 4.690714] kworker/4:1/51 is trying to acquire lock:
>> [ 4.695760] (____ptrval____) (regulator_list_mutex){+.+.},
>> at:regulator_lock_dependent+0xdc/0x6c4
>> [ 4.704732]
>> [ 4.704732] but task is already holding lock:
>> [ 4.710556] (____ptrval____) (&genpd->mlock/1){+.+.},
>> at:genpd_lock_nested_mtx+0x24/0x30
>> [ 4.718740]
>> [ 4.718740] which lock already depends on the new lock.
>> [ 4.718740]
>> [ 4.726908]
>> [ 4.726908] the existing dependency chain (in reverse order) is:
>> [ 4.734382]
>> [ 4.734382] -> #4 (&genpd->mlock/1){+.+.}:
>> [ 4.739963] __mutex_lock_common+0x1a0/0x1fe8
>> [ 4.744836] mutex_lock_nested+0x40/0x50
>> [ 4.749275] genpd_lock_nested_mtx+0x24/0x30
>> [ 4.754063] genpd_add_subdomain+0x150/0x524
>> [ 4.758850] pm_genpd_add_subdomain+0x3c/0x5c
>> [ 4.763723] scpsys_probe+0x520/0xe78
>> [ 4.767902] platform_drv_probe+0xf4/0x134
>> [ 4.772517] really_probe+0x214/0x4dc
>> [ 4.776696] driver_probe_device+0xcc/0x1d4
>> [ 4.781396] __device_attach_driver+0x10c/0x180
>> [ 4.786442] bus_for_each_drv+0x124/0x184
>> [ 4.790968] __device_attach+0x1c0/0x2d8
>> [ 4.795407] device_initial_probe+0x20/0x2c
>> [ 4.800106] bus_probe_device+0x80/0x16c
>> [ 4.804546] deferred_probe_work_func+0x120/0x168
>> [ 4.809767] process_one_work+0x858/0x1208
>> [ 4.814379] worker_thread+0x9ec/0xcb8
>> [ 4.818644] kthread+0x2b8/0x2d0
>> [ 4.822391] ret_from_fork+0x10/0x18
>> [ 4.826480]
>> [ 4.826480] -> #3 (&genpd->mlock){+.+.}:
>> [ 4.831880] __mutex_lock_common+0x1a0/0x1fe8
>> [ 4.836752] mutex_lock_nested+0x40/0x50
>> [ 4.841190] genpd_lock_mtx+0x20/0x2c
>> [ 4.845369] genpd_runtime_resume+0x140/0x434
>> [ 4.850241] __rpm_callback+0xb0/0x1e4
>> [ 4.854506] rpm_callback+0x54/0x1a8
>> [ 4.858597] rpm_resume+0xc6c/0x10c4
>> [ 4.862689] __pm_runtime_resume+0xb4/0x124
>> [ 4.867387] device_link_add+0x598/0x8d0
>
> For this looks as if you have also patch
> [PATCH v2 04/12] memory: mtk-smi: Add device-link between smi-larb and smi-common
> from series
> [PATCH v2 00/12] Clean up "mediatek,larb" after adding device_link
> applied.
>
My guess is, that we run into this, because we call genpd_runtime_resume before
we have finished the subdomain registration in scpsys_probe.
That implies that you also have the scpsys series for mt8183 added to your tree.
Anyway it looks to me as if we have to add the subdomains before we call
of_genpd_add_provider_onecell().
Regards,
Matthias
> Regards,
> Matthias
>
>> [ 4.871829] mtk_smi_larb_probe+0x2b0/0x340
>> [ 4.876528] platform_drv_probe+0xf4/0x134
>> [ 4.881141] really_probe+0x214/0x4dc
>> [ 4.885320] driver_probe_device+0xcc/0x1d4
>> [ 4.890020] __device_attach_driver+0x10c/0x180
>> [ 4.895066] bus_for_each_drv+0x124/0x184
>> [ 4.899591] __device_attach+0x1c0/0x2d8
>> [ 4.904031] device_initial_probe+0x20/0x2c
>> [ 4.908730] bus_probe_device+0x80/0x16c
>> [ 4.913169] deferred_probe_work_func+0x120/0x168
>> [ 4.918387] process_one_work+0x858/0x1208
>> [ 4.923000] worker_thread+0x9ec/0xcb8
>> [ 4.927264] kthread+0x2b8/0x2d0
>> [ 4.931009] ret_from_fork+0x10/0x18
>> [ 4.935098]
>> [ 4.935098] -> #2 (dpm_list_mtx){+.+.}:
>> [ 4.940412] __mutex_lock_common+0x1a0/0x1fe8
>> [ 4.945284] mutex_lock_nested+0x40/0x50
>> [ 4.949722] device_pm_lock+0x1c/0x24
>> [ 4.953900] device_link_add+0x98/0x8d0
>> [ 4.958252] _regulator_get+0x3f0/0x504
>> [ 4.962606] _devm_regulator_get+0x58/0xb8
>> [ 4.967218] devm_regulator_get+0x28/0x34
>> [ 4.971746] pwm_backlight_probe+0x61c/0x1b90
>> [ 4.976617] platform_drv_probe+0xf4/0x134
>> [ 4.981230] really_probe+0x214/0x4dc
>> [ 4.985409] driver_probe_device+0xcc/0x1d4
>> [ 4.990108] device_driver_attach+0xe4/0x104
>> [ 4.994894] __driver_attach+0x134/0x14c
>> [ 4.999333] bus_for_each_dev+0x120/0x180
>> [ 5.003859] driver_attach+0x48/0x54
>> [ 5.007950] bus_add_driver+0x2ac/0x44c
>> [ 5.012303] driver_register+0x160/0x288
>> [ 5.016742] __platform_driver_register+0xcc/0xdc
>> [ 5.021964] pwm_backlight_driver_init+0x1c/0x24
>> [ 5.027097] do_one_initcall+0x38c/0x994
>> [ 5.031536] do_initcall_level+0x3a4/0x4b8
>> [ 5.036148] do_basic_setup+0x84/0xa0
>> [ 5.036153] kernel_init_freeable+0x23c/0x324
>> [ 5.036158] kernel_init+0x14/0x110
>> [ 5.036164] ret_from_fork+0x10/0x18
>> [ 5.036166]
>> [ 5.036166] -> #1 (device_links_lock){+.+.}:
>> [ 5.065905] __mutex_lock_common+0x1a0/0x1fe8
>> [ 5.070777] mutex_lock_nested+0x40/0x50
>> [ 5.075215] device_link_remove+0x40/0xe0
>> [ 5.079740] _regulator_put+0x104/0x2d8
>> [ 5.084093] regulator_put+0x30/0x44
>> [ 5.088184] devm_regulator_release+0x38/0x44
>> [ 5.093056] release_nodes+0x604/0x670
>> [ 5.097320] devres_release_all+0x70/0x8c
>> [ 5.101846] really_probe+0x270/0x4dc
>> [ 5.106024] driver_probe_device+0xcc/0x1d4
>> [ 5.110724] device_driver_attach+0xe4/0x104
>> [ 5.115510] __driver_attach+0x134/0x14c
>> [ 5.119949] bus_for_each_dev+0x120/0x180
>> [ 5.124474] driver_attach+0x48/0x54
>> [ 5.128566] bus_add_driver+0x2ac/0x44c
>> [ 5.132919] driver_register+0x160/0x288
>> [ 5.137357] __platform_driver_register+0xcc/0xdc
>> [ 5.142576] pwm_backlight_driver_init+0x1c/0x24
>> [ 5.147708] do_one_initcall+0x38c/0x994
>> [ 5.152146] do_initcall_level+0x3a4/0x4b8
>> [ 5.156758] do_basic_setup+0x84/0xa0
>> [ 5.160936] kernel_init_freeable+0x23c/0x324
>> [ 5.165807] kernel_init+0x14/0x110
>> [ 5.169813] ret_from_fork+0x10/0x18
>> [ 5.173901]
>> [ 5.173901] -> #0 (regulator_list_mutex){+.+.}:
>> [ 5.179910] lock_acquire+0x350/0x4d4
>> [ 5.184088] __mutex_lock_common+0x1a0/0x1fe8
>> [ 5.184095] mutex_lock_nested+0x40/0x50
>> [ 5.197475] regulator_lock_dependent+0xdc/0x6c4
>> [ 5.197482] regulator_disable+0xa0/0x138
>> [ 5.197487] scpsys_power_off+0x38c/0x4bc
>> [ 5.197495] genpd_power_off+0x3d8/0x6a0
>> [ 5.209399] genpd_power_off+0x530/0x6a0
>> [ 5.209406] genpd_power_off_work_fn+0x74/0xc0
>> [ 5.209411] process_one_work+0x858/0x1208
>> [ 5.209419] worker_thread+0x9ec/0xcb8
>> [ 5.219067] kthread+0x2b8/0x2d0
>> [ 5.219073] ret_from_fork+0x10/0x18
>> [ 5.219077]
>> [ 5.219077] other info that might help us debug this:
>> [ 5.219077]
>> [ 5.219080] Chain exists of:
>> [ 5.219080] regulator_list_mutex --> &genpd->mlock --> &genpd->mlock/1
>> [ 5.219080]
>> [ 5.228039] Possible unsafe locking scenario:
>> [ 5.228039]
>> [ 5.228042] CPU0 CPU1
>> [ 5.228046] ---- ----
>> [ 5.228048] lock(&genpd->mlock/1);
>> [ 5.228058] lock(&genpd->mlock);
>> [ 5.311647] lock(&genpd->mlock/1);
>> [ 5.317736] lock(regulator_list_mutex);
>> [ 5.321742]
>> [ 5.321742] *** DEADLOCK ***
>> [ 5.321742]
>> [ 5.327655] 4 locks held by kworker/4:1/51:
>> [ 5.331831] #0: (____ptrval____) ((wq_completion)pm){+.+.},
>> at:process_one_work+0x57c/0x1208
>> [ 5.340444] #1: (____ptrval____)
>> ((work_completion)(&genpd->power_off_work)){+.+.},
>> at:process_one_work+0x5b8/0x1208
>> [ 5.351139] #2: (____ptrval____) (&genpd->mlock){+.+.},
>> at:genpd_lock_mtx+0x20/0x2c
>> [ 5.358970] #3: (____ptrval____) (&genpd->mlock/1){+.+.},
>> at:genpd_lock_nested_mtx+0x24/0x30
>> [ 5.367584]
>> [ 5.367584] stack backtrace:
>> [ 5.371939] CPU: 4 PID: 51 Comm: kworker/4:1 Tainted: G S
>> 5.2.0-rc2-next-20190528-44527-g6c94b6475c04 #20
>> [ 5.382809] Workqueue: pm genpd_power_off_work_fn
>> [ 5.382816] Call trace:
>> [ 5.382822] dump_backtrace+0x0/0x2c0
>> [ 5.382830] show_stack+0x20/0x2c
>> [ 5.409174] dump_stack+0x10c/0x17c
>> [ 5.412659] print_circular_bug+0x42c/0x4d0
>> [ 5.416838] __lock_acquire+0x4c88/0x5484
>> [ 5.420843] lock_acquire+0x350/0x4d4
>> [ 5.424500] __mutex_lock_common+0x1a0/0x1fe8
>> [ 5.428851] mutex_lock_nested+0x40/0x50
>> [ 5.432770] regulator_lock_dependent+0xdc/0x6c4
>> [ 5.437383] regulator_disable+0xa0/0x138
>> [ 5.441389] scpsys_power_off+0x38c/0x4bc
>> [ 5.445393] genpd_power_off+0x3d8/0x6a0
>> [ 5.449310] genpd_power_off+0x530/0x6a0
>> [ 5.453229] genpd_power_off_work_fn+0x74/0xc0
>> [ 5.457667] process_one_work+0x858/0x1208
>> [ 5.461758] worker_thread+0x9ec/0xcb8
>> [ 5.465503] kthread+0x2b8/0x2d0
>> [ 5.468727] ret_from_fork+0x10/0x18
>>
>> On Mon, Jun 10, 2019 at 8:21 PM Yong Wu <yong.wu@mediatek.com> wrote:
>>> ...
>>
>>
>> On Mon, Jun 10, 2019 at 8:21 PM Yong Wu <yong.wu@mediatek.com> wrote:
>>
>>> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
>>> mmu0 or mmu1 to balance the bandwidth via the smi-common register
>>> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>>>
>>> In mt8183, For better performance, we switch larb1/2/5/7 to enter
>>> mmu1 while the others still keep enter mmu0.
>>>
>>> In mt8173 and mt2712, we don't get the performance issue,
>>> Keep its default value(0x0), that means all the larbs enter mmu0.
>>>
>>> Note: smi gen1(mt2701/mt7623) don't have this bus_sel.
>>>
>>> And, the base of smi-common is completely different with smi_ao_base
>>> of gen1, thus I add new variable for that.
>>>
>>> CC: Matthias Brugger <matthias.bgg@gmail.com>
>>> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
>>> Reviewed-by: Evan Green <evgreen@chromium.org>
>>> ---
>>> drivers/memory/mtk-smi.c | 22 ++++++++++++++++++++--
>>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
>>> index 9790801..08cf40d 100644
>>> --- a/drivers/memory/mtk-smi.c
>>> +++ b/drivers/memory/mtk-smi.c
>>> @@ -49,6 +49,12 @@
>>> #define SMI_LARB_NONSEC_CON(id) (0x380 + ((id) * 4))
>>> #define F_MMU_EN BIT(0)
>>>
>>> +/* SMI COMMON */
>>> +#define SMI_BUS_SEL 0x220
>>> +#define SMI_BUS_LARB_SHIFT(larbid) ((larbid) << 1)
>>> +/* All are MMU0 defaultly. Only specialize mmu1 here. */
>>> +#define F_MMU1_LARB(larbid) (0x1 << SMI_BUS_LARB_SHIFT(larbid))
>>> +
>>> enum mtk_smi_gen {
>>> MTK_SMI_GEN1,
>>> MTK_SMI_GEN2
>>> @@ -57,6 +63,7 @@ enum mtk_smi_gen {
>>> struct mtk_smi_common_plat {
>>> enum mtk_smi_gen gen;
>>> bool has_gals;
>>> + u32 bus_sel; /* Balance some larbs to enter mmu0 or
>>> mmu1 */
>>> };
>>>
>>> struct mtk_smi_larb_gen {
>>> @@ -72,8 +79,8 @@ struct mtk_smi {
>>> struct clk *clk_apb, *clk_smi;
>>> struct clk *clk_gals0, *clk_gals1;
>>> struct clk *clk_async; /*only needed by
>>> mt2701*/
>>> - void __iomem *smi_ao_base;
>>> -
>>> + void __iomem *smi_ao_base; /* only for gen1 */
>>> + void __iomem *base; /* only for gen2 */
>>> const struct mtk_smi_common_plat *plat;
>>> };
>>>
>>> @@ -410,6 +417,8 @@ static int __maybe_unused mtk_smi_larb_suspend(struct
>>> device *dev)
>>> static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
>>> .gen = MTK_SMI_GEN2,
>>> .has_gals = true,
>>> + .bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(5) |
>>> + F_MMU1_LARB(7),
>>> };
>>>
>>> static const struct of_device_id mtk_smi_common_of_ids[] = {
>>> @@ -482,6 +491,11 @@ static int mtk_smi_common_probe(struct
>>> platform_device *pdev)
>>> ret = clk_prepare_enable(common->clk_async);
>>> if (ret)
>>> return ret;
>>> + } else {
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + common->base = devm_ioremap_resource(dev, res);
>>> + if (IS_ERR(common->base))
>>> + return PTR_ERR(common->base);
>>> }
>>> pm_runtime_enable(dev);
>>> platform_set_drvdata(pdev, common);
>>> @@ -497,6 +511,7 @@ static int mtk_smi_common_remove(struct
>>> platform_device *pdev)
>>> static int __maybe_unused mtk_smi_common_resume(struct device *dev)
>>> {
>>> struct mtk_smi *common = dev_get_drvdata(dev);
>>> + u32 bus_sel = common->plat->bus_sel;
>>> int ret;
>>>
>>> ret = mtk_smi_clk_enable(common);
>>> @@ -504,6 +519,9 @@ static int __maybe_unused mtk_smi_common_resume(struct
>>> device *dev)
>>> dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
>>> return ret;
>>> }
>>> +
>>> + if (common->plat->gen == MTK_SMI_GEN2 && bus_sel)
>>> + writel(bus_sel, common->base + SMI_BUS_SEL);
>>> return 0;
>>> }
>>>
>>> --
>>> 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
* Re: [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183
From: Matthias Brugger @ 2019-06-20 11:38 UTC (permalink / raw)
To: Pi-Hsun Shih, Yong Wu
Cc: Joerg Roedel, Robin Murphy, Rob Herring, Evan Green, Tomasz Figa,
Will Deacon, moderated list:ARM/Mediatek SoC support,
srv_heupstream,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, moderated list:ARM/Mediatek SoC support, iommu,
yingjoe.chen, youlin.pei, Nicolas Boichat, anan.sun,
Matthias Kaehlcke, Sascha Hauer
In-Reply-To: <eee15db0-e43f-de9b-28a0-93bdd04836d7@gmail.com>
CCing Sascha
On 20/06/2019 11:35, Matthias Brugger wrote:
>
>
> On 13/06/2019 10:14, Pi-Hsun Shih wrote:
>> Hi,
>> When I tested this patch series (Based on linux 5.2.0-rc2, and with
>> various other patch series about MT8183) with lockdep enabled, and I'm
>> seeing the following lockdep warning on boot.
>>
>> By bisecting the commits, the first commit that introduce this warning
>> is this patch. The warning also doesn't appear if
>> https://lore.kernel.org/patchwork/patch/1086582/ and
>> https://lore.kernel.org/patchwork/patch/1086583/ are not applied.
>>
>> Do anyone have idea on why this is happening, or any suggestion on
>> which part I should be digging into to figure this out? Thanks.
>>
>> [ 4.664194] ======================================================
>> [ 4.670368] WARNING: possible circular locking dependency detected
>> [ 4.676545] 5.2.0-rc2-next-20190528-44527-g6c94b6475c04 #20 Tainted: G S
>> [ 4.684539] ------------------------------------------------------
>> [ 4.690714] kworker/4:1/51 is trying to acquire lock:
>> [ 4.695760] (____ptrval____) (regulator_list_mutex){+.+.},
>> at:regulator_lock_dependent+0xdc/0x6c4
>> [ 4.704732]
>> [ 4.704732] but task is already holding lock:
>> [ 4.710556] (____ptrval____) (&genpd->mlock/1){+.+.},
>> at:genpd_lock_nested_mtx+0x24/0x30
>> [ 4.718740]
>> [ 4.718740] which lock already depends on the new lock.
>> [ 4.718740]
>> [ 4.726908]
>> [ 4.726908] the existing dependency chain (in reverse order) is:
>> [ 4.734382]
>> [ 4.734382] -> #4 (&genpd->mlock/1){+.+.}:
>> [ 4.739963] __mutex_lock_common+0x1a0/0x1fe8
>> [ 4.744836] mutex_lock_nested+0x40/0x50
>> [ 4.749275] genpd_lock_nested_mtx+0x24/0x30
>> [ 4.754063] genpd_add_subdomain+0x150/0x524
>> [ 4.758850] pm_genpd_add_subdomain+0x3c/0x5c
>> [ 4.763723] scpsys_probe+0x520/0xe78
>> [ 4.767902] platform_drv_probe+0xf4/0x134
>> [ 4.772517] really_probe+0x214/0x4dc
>> [ 4.776696] driver_probe_device+0xcc/0x1d4
>> [ 4.781396] __device_attach_driver+0x10c/0x180
>> [ 4.786442] bus_for_each_drv+0x124/0x184
>> [ 4.790968] __device_attach+0x1c0/0x2d8
>> [ 4.795407] device_initial_probe+0x20/0x2c
>> [ 4.800106] bus_probe_device+0x80/0x16c
>> [ 4.804546] deferred_probe_work_func+0x120/0x168
>> [ 4.809767] process_one_work+0x858/0x1208
>> [ 4.814379] worker_thread+0x9ec/0xcb8
>> [ 4.818644] kthread+0x2b8/0x2d0
>> [ 4.822391] ret_from_fork+0x10/0x18
>> [ 4.826480]
>> [ 4.826480] -> #3 (&genpd->mlock){+.+.}:
>> [ 4.831880] __mutex_lock_common+0x1a0/0x1fe8
>> [ 4.836752] mutex_lock_nested+0x40/0x50
>> [ 4.841190] genpd_lock_mtx+0x20/0x2c
>> [ 4.845369] genpd_runtime_resume+0x140/0x434
>> [ 4.850241] __rpm_callback+0xb0/0x1e4
>> [ 4.854506] rpm_callback+0x54/0x1a8
>> [ 4.858597] rpm_resume+0xc6c/0x10c4
>> [ 4.862689] __pm_runtime_resume+0xb4/0x124
>> [ 4.867387] device_link_add+0x598/0x8d0
>
> For this looks as if you have also patch
> [PATCH v2 04/12] memory: mtk-smi: Add device-link between smi-larb and smi-common
> from series
> [PATCH v2 00/12] Clean up "mediatek,larb" after adding device_link
> applied.
>
My guess is, that we run into this, because we call genpd_runtime_resume before
we have finished the subdomain registration in scpsys_probe.
That implies that you also have the scpsys series for mt8183 added to your tree.
Anyway it looks to me as if we have to add the subdomains before we call
of_genpd_add_provider_onecell().
Regards,
Matthias
> Regards,
> Matthias
>
>> [ 4.871829] mtk_smi_larb_probe+0x2b0/0x340
>> [ 4.876528] platform_drv_probe+0xf4/0x134
>> [ 4.881141] really_probe+0x214/0x4dc
>> [ 4.885320] driver_probe_device+0xcc/0x1d4
>> [ 4.890020] __device_attach_driver+0x10c/0x180
>> [ 4.895066] bus_for_each_drv+0x124/0x184
>> [ 4.899591] __device_attach+0x1c0/0x2d8
>> [ 4.904031] device_initial_probe+0x20/0x2c
>> [ 4.908730] bus_probe_device+0x80/0x16c
>> [ 4.913169] deferred_probe_work_func+0x120/0x168
>> [ 4.918387] process_one_work+0x858/0x1208
>> [ 4.923000] worker_thread+0x9ec/0xcb8
>> [ 4.927264] kthread+0x2b8/0x2d0
>> [ 4.931009] ret_from_fork+0x10/0x18
>> [ 4.935098]
>> [ 4.935098] -> #2 (dpm_list_mtx){+.+.}:
>> [ 4.940412] __mutex_lock_common+0x1a0/0x1fe8
>> [ 4.945284] mutex_lock_nested+0x40/0x50
>> [ 4.949722] device_pm_lock+0x1c/0x24
>> [ 4.953900] device_link_add+0x98/0x8d0
>> [ 4.958252] _regulator_get+0x3f0/0x504
>> [ 4.962606] _devm_regulator_get+0x58/0xb8
>> [ 4.967218] devm_regulator_get+0x28/0x34
>> [ 4.971746] pwm_backlight_probe+0x61c/0x1b90
>> [ 4.976617] platform_drv_probe+0xf4/0x134
>> [ 4.981230] really_probe+0x214/0x4dc
>> [ 4.985409] driver_probe_device+0xcc/0x1d4
>> [ 4.990108] device_driver_attach+0xe4/0x104
>> [ 4.994894] __driver_attach+0x134/0x14c
>> [ 4.999333] bus_for_each_dev+0x120/0x180
>> [ 5.003859] driver_attach+0x48/0x54
>> [ 5.007950] bus_add_driver+0x2ac/0x44c
>> [ 5.012303] driver_register+0x160/0x288
>> [ 5.016742] __platform_driver_register+0xcc/0xdc
>> [ 5.021964] pwm_backlight_driver_init+0x1c/0x24
>> [ 5.027097] do_one_initcall+0x38c/0x994
>> [ 5.031536] do_initcall_level+0x3a4/0x4b8
>> [ 5.036148] do_basic_setup+0x84/0xa0
>> [ 5.036153] kernel_init_freeable+0x23c/0x324
>> [ 5.036158] kernel_init+0x14/0x110
>> [ 5.036164] ret_from_fork+0x10/0x18
>> [ 5.036166]
>> [ 5.036166] -> #1 (device_links_lock){+.+.}:
>> [ 5.065905] __mutex_lock_common+0x1a0/0x1fe8
>> [ 5.070777] mutex_lock_nested+0x40/0x50
>> [ 5.075215] device_link_remove+0x40/0xe0
>> [ 5.079740] _regulator_put+0x104/0x2d8
>> [ 5.084093] regulator_put+0x30/0x44
>> [ 5.088184] devm_regulator_release+0x38/0x44
>> [ 5.093056] release_nodes+0x604/0x670
>> [ 5.097320] devres_release_all+0x70/0x8c
>> [ 5.101846] really_probe+0x270/0x4dc
>> [ 5.106024] driver_probe_device+0xcc/0x1d4
>> [ 5.110724] device_driver_attach+0xe4/0x104
>> [ 5.115510] __driver_attach+0x134/0x14c
>> [ 5.119949] bus_for_each_dev+0x120/0x180
>> [ 5.124474] driver_attach+0x48/0x54
>> [ 5.128566] bus_add_driver+0x2ac/0x44c
>> [ 5.132919] driver_register+0x160/0x288
>> [ 5.137357] __platform_driver_register+0xcc/0xdc
>> [ 5.142576] pwm_backlight_driver_init+0x1c/0x24
>> [ 5.147708] do_one_initcall+0x38c/0x994
>> [ 5.152146] do_initcall_level+0x3a4/0x4b8
>> [ 5.156758] do_basic_setup+0x84/0xa0
>> [ 5.160936] kernel_init_freeable+0x23c/0x324
>> [ 5.165807] kernel_init+0x14/0x110
>> [ 5.169813] ret_from_fork+0x10/0x18
>> [ 5.173901]
>> [ 5.173901] -> #0 (regulator_list_mutex){+.+.}:
>> [ 5.179910] lock_acquire+0x350/0x4d4
>> [ 5.184088] __mutex_lock_common+0x1a0/0x1fe8
>> [ 5.184095] mutex_lock_nested+0x40/0x50
>> [ 5.197475] regulator_lock_dependent+0xdc/0x6c4
>> [ 5.197482] regulator_disable+0xa0/0x138
>> [ 5.197487] scpsys_power_off+0x38c/0x4bc
>> [ 5.197495] genpd_power_off+0x3d8/0x6a0
>> [ 5.209399] genpd_power_off+0x530/0x6a0
>> [ 5.209406] genpd_power_off_work_fn+0x74/0xc0
>> [ 5.209411] process_one_work+0x858/0x1208
>> [ 5.209419] worker_thread+0x9ec/0xcb8
>> [ 5.219067] kthread+0x2b8/0x2d0
>> [ 5.219073] ret_from_fork+0x10/0x18
>> [ 5.219077]
>> [ 5.219077] other info that might help us debug this:
>> [ 5.219077]
>> [ 5.219080] Chain exists of:
>> [ 5.219080] regulator_list_mutex --> &genpd->mlock --> &genpd->mlock/1
>> [ 5.219080]
>> [ 5.228039] Possible unsafe locking scenario:
>> [ 5.228039]
>> [ 5.228042] CPU0 CPU1
>> [ 5.228046] ---- ----
>> [ 5.228048] lock(&genpd->mlock/1);
>> [ 5.228058] lock(&genpd->mlock);
>> [ 5.311647] lock(&genpd->mlock/1);
>> [ 5.317736] lock(regulator_list_mutex);
>> [ 5.321742]
>> [ 5.321742] *** DEADLOCK ***
>> [ 5.321742]
>> [ 5.327655] 4 locks held by kworker/4:1/51:
>> [ 5.331831] #0: (____ptrval____) ((wq_completion)pm){+.+.},
>> at:process_one_work+0x57c/0x1208
>> [ 5.340444] #1: (____ptrval____)
>> ((work_completion)(&genpd->power_off_work)){+.+.},
>> at:process_one_work+0x5b8/0x1208
>> [ 5.351139] #2: (____ptrval____) (&genpd->mlock){+.+.},
>> at:genpd_lock_mtx+0x20/0x2c
>> [ 5.358970] #3: (____ptrval____) (&genpd->mlock/1){+.+.},
>> at:genpd_lock_nested_mtx+0x24/0x30
>> [ 5.367584]
>> [ 5.367584] stack backtrace:
>> [ 5.371939] CPU: 4 PID: 51 Comm: kworker/4:1 Tainted: G S
>> 5.2.0-rc2-next-20190528-44527-g6c94b6475c04 #20
>> [ 5.382809] Workqueue: pm genpd_power_off_work_fn
>> [ 5.382816] Call trace:
>> [ 5.382822] dump_backtrace+0x0/0x2c0
>> [ 5.382830] show_stack+0x20/0x2c
>> [ 5.409174] dump_stack+0x10c/0x17c
>> [ 5.412659] print_circular_bug+0x42c/0x4d0
>> [ 5.416838] __lock_acquire+0x4c88/0x5484
>> [ 5.420843] lock_acquire+0x350/0x4d4
>> [ 5.424500] __mutex_lock_common+0x1a0/0x1fe8
>> [ 5.428851] mutex_lock_nested+0x40/0x50
>> [ 5.432770] regulator_lock_dependent+0xdc/0x6c4
>> [ 5.437383] regulator_disable+0xa0/0x138
>> [ 5.441389] scpsys_power_off+0x38c/0x4bc
>> [ 5.445393] genpd_power_off+0x3d8/0x6a0
>> [ 5.449310] genpd_power_off+0x530/0x6a0
>> [ 5.453229] genpd_power_off_work_fn+0x74/0xc0
>> [ 5.457667] process_one_work+0x858/0x1208
>> [ 5.461758] worker_thread+0x9ec/0xcb8
>> [ 5.465503] kthread+0x2b8/0x2d0
>> [ 5.468727] ret_from_fork+0x10/0x18
>>
>> On Mon, Jun 10, 2019 at 8:21 PM Yong Wu <yong.wu@mediatek.com> wrote:
>>> ...
>>
>>
>> On Mon, Jun 10, 2019 at 8:21 PM Yong Wu <yong.wu@mediatek.com> wrote:
>>
>>> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
>>> mmu0 or mmu1 to balance the bandwidth via the smi-common register
>>> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>>>
>>> In mt8183, For better performance, we switch larb1/2/5/7 to enter
>>> mmu1 while the others still keep enter mmu0.
>>>
>>> In mt8173 and mt2712, we don't get the performance issue,
>>> Keep its default value(0x0), that means all the larbs enter mmu0.
>>>
>>> Note: smi gen1(mt2701/mt7623) don't have this bus_sel.
>>>
>>> And, the base of smi-common is completely different with smi_ao_base
>>> of gen1, thus I add new variable for that.
>>>
>>> CC: Matthias Brugger <matthias.bgg@gmail.com>
>>> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
>>> Reviewed-by: Evan Green <evgreen@chromium.org>
>>> ---
>>> drivers/memory/mtk-smi.c | 22 ++++++++++++++++++++--
>>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
>>> index 9790801..08cf40d 100644
>>> --- a/drivers/memory/mtk-smi.c
>>> +++ b/drivers/memory/mtk-smi.c
>>> @@ -49,6 +49,12 @@
>>> #define SMI_LARB_NONSEC_CON(id) (0x380 + ((id) * 4))
>>> #define F_MMU_EN BIT(0)
>>>
>>> +/* SMI COMMON */
>>> +#define SMI_BUS_SEL 0x220
>>> +#define SMI_BUS_LARB_SHIFT(larbid) ((larbid) << 1)
>>> +/* All are MMU0 defaultly. Only specialize mmu1 here. */
>>> +#define F_MMU1_LARB(larbid) (0x1 << SMI_BUS_LARB_SHIFT(larbid))
>>> +
>>> enum mtk_smi_gen {
>>> MTK_SMI_GEN1,
>>> MTK_SMI_GEN2
>>> @@ -57,6 +63,7 @@ enum mtk_smi_gen {
>>> struct mtk_smi_common_plat {
>>> enum mtk_smi_gen gen;
>>> bool has_gals;
>>> + u32 bus_sel; /* Balance some larbs to enter mmu0 or
>>> mmu1 */
>>> };
>>>
>>> struct mtk_smi_larb_gen {
>>> @@ -72,8 +79,8 @@ struct mtk_smi {
>>> struct clk *clk_apb, *clk_smi;
>>> struct clk *clk_gals0, *clk_gals1;
>>> struct clk *clk_async; /*only needed by
>>> mt2701*/
>>> - void __iomem *smi_ao_base;
>>> -
>>> + void __iomem *smi_ao_base; /* only for gen1 */
>>> + void __iomem *base; /* only for gen2 */
>>> const struct mtk_smi_common_plat *plat;
>>> };
>>>
>>> @@ -410,6 +417,8 @@ static int __maybe_unused mtk_smi_larb_suspend(struct
>>> device *dev)
>>> static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
>>> .gen = MTK_SMI_GEN2,
>>> .has_gals = true,
>>> + .bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(5) |
>>> + F_MMU1_LARB(7),
>>> };
>>>
>>> static const struct of_device_id mtk_smi_common_of_ids[] = {
>>> @@ -482,6 +491,11 @@ static int mtk_smi_common_probe(struct
>>> platform_device *pdev)
>>> ret = clk_prepare_enable(common->clk_async);
>>> if (ret)
>>> return ret;
>>> + } else {
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + common->base = devm_ioremap_resource(dev, res);
>>> + if (IS_ERR(common->base))
>>> + return PTR_ERR(common->base);
>>> }
>>> pm_runtime_enable(dev);
>>> platform_set_drvdata(pdev, common);
>>> @@ -497,6 +511,7 @@ static int mtk_smi_common_remove(struct
>>> platform_device *pdev)
>>> static int __maybe_unused mtk_smi_common_resume(struct device *dev)
>>> {
>>> struct mtk_smi *common = dev_get_drvdata(dev);
>>> + u32 bus_sel = common->plat->bus_sel;
>>> int ret;
>>>
>>> ret = mtk_smi_clk_enable(common);
>>> @@ -504,6 +519,9 @@ static int __maybe_unused mtk_smi_common_resume(struct
>>> device *dev)
>>> dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
>>> return ret;
>>> }
>>> +
>>> + if (common->plat->gen == MTK_SMI_GEN2 && bus_sel)
>>> + writel(bus_sel, common->base + SMI_BUS_SEL);
>>> return 0;
>>> }
>>>
>>> --
>>> 1.9.1
>>>
>>>
>>
^ permalink raw reply
* Re: [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183
From: Matthias Brugger @ 2019-06-20 11:38 UTC (permalink / raw)
To: Pi-Hsun Shih, Yong Wu
Cc: youlin.pei,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Nicolas Boichat, srv_heupstream, Will Deacon, open list,
Evan Green, Tomasz Figa, iommu, Rob Herring,
moderated list:ARM/Mediatek SoC support, Sascha Hauer,
yingjoe.chen, anan.sun, Robin Murphy, Matthias Kaehlcke,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <eee15db0-e43f-de9b-28a0-93bdd04836d7@gmail.com>
CCing Sascha
On 20/06/2019 11:35, Matthias Brugger wrote:
>
>
> On 13/06/2019 10:14, Pi-Hsun Shih wrote:
>> Hi,
>> When I tested this patch series (Based on linux 5.2.0-rc2, and with
>> various other patch series about MT8183) with lockdep enabled, and I'm
>> seeing the following lockdep warning on boot.
>>
>> By bisecting the commits, the first commit that introduce this warning
>> is this patch. The warning also doesn't appear if
>> https://lore.kernel.org/patchwork/patch/1086582/ and
>> https://lore.kernel.org/patchwork/patch/1086583/ are not applied.
>>
>> Do anyone have idea on why this is happening, or any suggestion on
>> which part I should be digging into to figure this out? Thanks.
>>
>> [ 4.664194] ======================================================
>> [ 4.670368] WARNING: possible circular locking dependency detected
>> [ 4.676545] 5.2.0-rc2-next-20190528-44527-g6c94b6475c04 #20 Tainted: G S
>> [ 4.684539] ------------------------------------------------------
>> [ 4.690714] kworker/4:1/51 is trying to acquire lock:
>> [ 4.695760] (____ptrval____) (regulator_list_mutex){+.+.},
>> at:regulator_lock_dependent+0xdc/0x6c4
>> [ 4.704732]
>> [ 4.704732] but task is already holding lock:
>> [ 4.710556] (____ptrval____) (&genpd->mlock/1){+.+.},
>> at:genpd_lock_nested_mtx+0x24/0x30
>> [ 4.718740]
>> [ 4.718740] which lock already depends on the new lock.
>> [ 4.718740]
>> [ 4.726908]
>> [ 4.726908] the existing dependency chain (in reverse order) is:
>> [ 4.734382]
>> [ 4.734382] -> #4 (&genpd->mlock/1){+.+.}:
>> [ 4.739963] __mutex_lock_common+0x1a0/0x1fe8
>> [ 4.744836] mutex_lock_nested+0x40/0x50
>> [ 4.749275] genpd_lock_nested_mtx+0x24/0x30
>> [ 4.754063] genpd_add_subdomain+0x150/0x524
>> [ 4.758850] pm_genpd_add_subdomain+0x3c/0x5c
>> [ 4.763723] scpsys_probe+0x520/0xe78
>> [ 4.767902] platform_drv_probe+0xf4/0x134
>> [ 4.772517] really_probe+0x214/0x4dc
>> [ 4.776696] driver_probe_device+0xcc/0x1d4
>> [ 4.781396] __device_attach_driver+0x10c/0x180
>> [ 4.786442] bus_for_each_drv+0x124/0x184
>> [ 4.790968] __device_attach+0x1c0/0x2d8
>> [ 4.795407] device_initial_probe+0x20/0x2c
>> [ 4.800106] bus_probe_device+0x80/0x16c
>> [ 4.804546] deferred_probe_work_func+0x120/0x168
>> [ 4.809767] process_one_work+0x858/0x1208
>> [ 4.814379] worker_thread+0x9ec/0xcb8
>> [ 4.818644] kthread+0x2b8/0x2d0
>> [ 4.822391] ret_from_fork+0x10/0x18
>> [ 4.826480]
>> [ 4.826480] -> #3 (&genpd->mlock){+.+.}:
>> [ 4.831880] __mutex_lock_common+0x1a0/0x1fe8
>> [ 4.836752] mutex_lock_nested+0x40/0x50
>> [ 4.841190] genpd_lock_mtx+0x20/0x2c
>> [ 4.845369] genpd_runtime_resume+0x140/0x434
>> [ 4.850241] __rpm_callback+0xb0/0x1e4
>> [ 4.854506] rpm_callback+0x54/0x1a8
>> [ 4.858597] rpm_resume+0xc6c/0x10c4
>> [ 4.862689] __pm_runtime_resume+0xb4/0x124
>> [ 4.867387] device_link_add+0x598/0x8d0
>
> For this looks as if you have also patch
> [PATCH v2 04/12] memory: mtk-smi: Add device-link between smi-larb and smi-common
> from series
> [PATCH v2 00/12] Clean up "mediatek,larb" after adding device_link
> applied.
>
My guess is, that we run into this, because we call genpd_runtime_resume before
we have finished the subdomain registration in scpsys_probe.
That implies that you also have the scpsys series for mt8183 added to your tree.
Anyway it looks to me as if we have to add the subdomains before we call
of_genpd_add_provider_onecell().
Regards,
Matthias
> Regards,
> Matthias
>
>> [ 4.871829] mtk_smi_larb_probe+0x2b0/0x340
>> [ 4.876528] platform_drv_probe+0xf4/0x134
>> [ 4.881141] really_probe+0x214/0x4dc
>> [ 4.885320] driver_probe_device+0xcc/0x1d4
>> [ 4.890020] __device_attach_driver+0x10c/0x180
>> [ 4.895066] bus_for_each_drv+0x124/0x184
>> [ 4.899591] __device_attach+0x1c0/0x2d8
>> [ 4.904031] device_initial_probe+0x20/0x2c
>> [ 4.908730] bus_probe_device+0x80/0x16c
>> [ 4.913169] deferred_probe_work_func+0x120/0x168
>> [ 4.918387] process_one_work+0x858/0x1208
>> [ 4.923000] worker_thread+0x9ec/0xcb8
>> [ 4.927264] kthread+0x2b8/0x2d0
>> [ 4.931009] ret_from_fork+0x10/0x18
>> [ 4.935098]
>> [ 4.935098] -> #2 (dpm_list_mtx){+.+.}:
>> [ 4.940412] __mutex_lock_common+0x1a0/0x1fe8
>> [ 4.945284] mutex_lock_nested+0x40/0x50
>> [ 4.949722] device_pm_lock+0x1c/0x24
>> [ 4.953900] device_link_add+0x98/0x8d0
>> [ 4.958252] _regulator_get+0x3f0/0x504
>> [ 4.962606] _devm_regulator_get+0x58/0xb8
>> [ 4.967218] devm_regulator_get+0x28/0x34
>> [ 4.971746] pwm_backlight_probe+0x61c/0x1b90
>> [ 4.976617] platform_drv_probe+0xf4/0x134
>> [ 4.981230] really_probe+0x214/0x4dc
>> [ 4.985409] driver_probe_device+0xcc/0x1d4
>> [ 4.990108] device_driver_attach+0xe4/0x104
>> [ 4.994894] __driver_attach+0x134/0x14c
>> [ 4.999333] bus_for_each_dev+0x120/0x180
>> [ 5.003859] driver_attach+0x48/0x54
>> [ 5.007950] bus_add_driver+0x2ac/0x44c
>> [ 5.012303] driver_register+0x160/0x288
>> [ 5.016742] __platform_driver_register+0xcc/0xdc
>> [ 5.021964] pwm_backlight_driver_init+0x1c/0x24
>> [ 5.027097] do_one_initcall+0x38c/0x994
>> [ 5.031536] do_initcall_level+0x3a4/0x4b8
>> [ 5.036148] do_basic_setup+0x84/0xa0
>> [ 5.036153] kernel_init_freeable+0x23c/0x324
>> [ 5.036158] kernel_init+0x14/0x110
>> [ 5.036164] ret_from_fork+0x10/0x18
>> [ 5.036166]
>> [ 5.036166] -> #1 (device_links_lock){+.+.}:
>> [ 5.065905] __mutex_lock_common+0x1a0/0x1fe8
>> [ 5.070777] mutex_lock_nested+0x40/0x50
>> [ 5.075215] device_link_remove+0x40/0xe0
>> [ 5.079740] _regulator_put+0x104/0x2d8
>> [ 5.084093] regulator_put+0x30/0x44
>> [ 5.088184] devm_regulator_release+0x38/0x44
>> [ 5.093056] release_nodes+0x604/0x670
>> [ 5.097320] devres_release_all+0x70/0x8c
>> [ 5.101846] really_probe+0x270/0x4dc
>> [ 5.106024] driver_probe_device+0xcc/0x1d4
>> [ 5.110724] device_driver_attach+0xe4/0x104
>> [ 5.115510] __driver_attach+0x134/0x14c
>> [ 5.119949] bus_for_each_dev+0x120/0x180
>> [ 5.124474] driver_attach+0x48/0x54
>> [ 5.128566] bus_add_driver+0x2ac/0x44c
>> [ 5.132919] driver_register+0x160/0x288
>> [ 5.137357] __platform_driver_register+0xcc/0xdc
>> [ 5.142576] pwm_backlight_driver_init+0x1c/0x24
>> [ 5.147708] do_one_initcall+0x38c/0x994
>> [ 5.152146] do_initcall_level+0x3a4/0x4b8
>> [ 5.156758] do_basic_setup+0x84/0xa0
>> [ 5.160936] kernel_init_freeable+0x23c/0x324
>> [ 5.165807] kernel_init+0x14/0x110
>> [ 5.169813] ret_from_fork+0x10/0x18
>> [ 5.173901]
>> [ 5.173901] -> #0 (regulator_list_mutex){+.+.}:
>> [ 5.179910] lock_acquire+0x350/0x4d4
>> [ 5.184088] __mutex_lock_common+0x1a0/0x1fe8
>> [ 5.184095] mutex_lock_nested+0x40/0x50
>> [ 5.197475] regulator_lock_dependent+0xdc/0x6c4
>> [ 5.197482] regulator_disable+0xa0/0x138
>> [ 5.197487] scpsys_power_off+0x38c/0x4bc
>> [ 5.197495] genpd_power_off+0x3d8/0x6a0
>> [ 5.209399] genpd_power_off+0x530/0x6a0
>> [ 5.209406] genpd_power_off_work_fn+0x74/0xc0
>> [ 5.209411] process_one_work+0x858/0x1208
>> [ 5.209419] worker_thread+0x9ec/0xcb8
>> [ 5.219067] kthread+0x2b8/0x2d0
>> [ 5.219073] ret_from_fork+0x10/0x18
>> [ 5.219077]
>> [ 5.219077] other info that might help us debug this:
>> [ 5.219077]
>> [ 5.219080] Chain exists of:
>> [ 5.219080] regulator_list_mutex --> &genpd->mlock --> &genpd->mlock/1
>> [ 5.219080]
>> [ 5.228039] Possible unsafe locking scenario:
>> [ 5.228039]
>> [ 5.228042] CPU0 CPU1
>> [ 5.228046] ---- ----
>> [ 5.228048] lock(&genpd->mlock/1);
>> [ 5.228058] lock(&genpd->mlock);
>> [ 5.311647] lock(&genpd->mlock/1);
>> [ 5.317736] lock(regulator_list_mutex);
>> [ 5.321742]
>> [ 5.321742] *** DEADLOCK ***
>> [ 5.321742]
>> [ 5.327655] 4 locks held by kworker/4:1/51:
>> [ 5.331831] #0: (____ptrval____) ((wq_completion)pm){+.+.},
>> at:process_one_work+0x57c/0x1208
>> [ 5.340444] #1: (____ptrval____)
>> ((work_completion)(&genpd->power_off_work)){+.+.},
>> at:process_one_work+0x5b8/0x1208
>> [ 5.351139] #2: (____ptrval____) (&genpd->mlock){+.+.},
>> at:genpd_lock_mtx+0x20/0x2c
>> [ 5.358970] #3: (____ptrval____) (&genpd->mlock/1){+.+.},
>> at:genpd_lock_nested_mtx+0x24/0x30
>> [ 5.367584]
>> [ 5.367584] stack backtrace:
>> [ 5.371939] CPU: 4 PID: 51 Comm: kworker/4:1 Tainted: G S
>> 5.2.0-rc2-next-20190528-44527-g6c94b6475c04 #20
>> [ 5.382809] Workqueue: pm genpd_power_off_work_fn
>> [ 5.382816] Call trace:
>> [ 5.382822] dump_backtrace+0x0/0x2c0
>> [ 5.382830] show_stack+0x20/0x2c
>> [ 5.409174] dump_stack+0x10c/0x17c
>> [ 5.412659] print_circular_bug+0x42c/0x4d0
>> [ 5.416838] __lock_acquire+0x4c88/0x5484
>> [ 5.420843] lock_acquire+0x350/0x4d4
>> [ 5.424500] __mutex_lock_common+0x1a0/0x1fe8
>> [ 5.428851] mutex_lock_nested+0x40/0x50
>> [ 5.432770] regulator_lock_dependent+0xdc/0x6c4
>> [ 5.437383] regulator_disable+0xa0/0x138
>> [ 5.441389] scpsys_power_off+0x38c/0x4bc
>> [ 5.445393] genpd_power_off+0x3d8/0x6a0
>> [ 5.449310] genpd_power_off+0x530/0x6a0
>> [ 5.453229] genpd_power_off_work_fn+0x74/0xc0
>> [ 5.457667] process_one_work+0x858/0x1208
>> [ 5.461758] worker_thread+0x9ec/0xcb8
>> [ 5.465503] kthread+0x2b8/0x2d0
>> [ 5.468727] ret_from_fork+0x10/0x18
>>
>> On Mon, Jun 10, 2019 at 8:21 PM Yong Wu <yong.wu@mediatek.com> wrote:
>>> ...
>>
>>
>> On Mon, Jun 10, 2019 at 8:21 PM Yong Wu <yong.wu@mediatek.com> wrote:
>>
>>> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
>>> mmu0 or mmu1 to balance the bandwidth via the smi-common register
>>> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>>>
>>> In mt8183, For better performance, we switch larb1/2/5/7 to enter
>>> mmu1 while the others still keep enter mmu0.
>>>
>>> In mt8173 and mt2712, we don't get the performance issue,
>>> Keep its default value(0x0), that means all the larbs enter mmu0.
>>>
>>> Note: smi gen1(mt2701/mt7623) don't have this bus_sel.
>>>
>>> And, the base of smi-common is completely different with smi_ao_base
>>> of gen1, thus I add new variable for that.
>>>
>>> CC: Matthias Brugger <matthias.bgg@gmail.com>
>>> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
>>> Reviewed-by: Evan Green <evgreen@chromium.org>
>>> ---
>>> drivers/memory/mtk-smi.c | 22 ++++++++++++++++++++--
>>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
>>> index 9790801..08cf40d 100644
>>> --- a/drivers/memory/mtk-smi.c
>>> +++ b/drivers/memory/mtk-smi.c
>>> @@ -49,6 +49,12 @@
>>> #define SMI_LARB_NONSEC_CON(id) (0x380 + ((id) * 4))
>>> #define F_MMU_EN BIT(0)
>>>
>>> +/* SMI COMMON */
>>> +#define SMI_BUS_SEL 0x220
>>> +#define SMI_BUS_LARB_SHIFT(larbid) ((larbid) << 1)
>>> +/* All are MMU0 defaultly. Only specialize mmu1 here. */
>>> +#define F_MMU1_LARB(larbid) (0x1 << SMI_BUS_LARB_SHIFT(larbid))
>>> +
>>> enum mtk_smi_gen {
>>> MTK_SMI_GEN1,
>>> MTK_SMI_GEN2
>>> @@ -57,6 +63,7 @@ enum mtk_smi_gen {
>>> struct mtk_smi_common_plat {
>>> enum mtk_smi_gen gen;
>>> bool has_gals;
>>> + u32 bus_sel; /* Balance some larbs to enter mmu0 or
>>> mmu1 */
>>> };
>>>
>>> struct mtk_smi_larb_gen {
>>> @@ -72,8 +79,8 @@ struct mtk_smi {
>>> struct clk *clk_apb, *clk_smi;
>>> struct clk *clk_gals0, *clk_gals1;
>>> struct clk *clk_async; /*only needed by
>>> mt2701*/
>>> - void __iomem *smi_ao_base;
>>> -
>>> + void __iomem *smi_ao_base; /* only for gen1 */
>>> + void __iomem *base; /* only for gen2 */
>>> const struct mtk_smi_common_plat *plat;
>>> };
>>>
>>> @@ -410,6 +417,8 @@ static int __maybe_unused mtk_smi_larb_suspend(struct
>>> device *dev)
>>> static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
>>> .gen = MTK_SMI_GEN2,
>>> .has_gals = true,
>>> + .bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(5) |
>>> + F_MMU1_LARB(7),
>>> };
>>>
>>> static const struct of_device_id mtk_smi_common_of_ids[] = {
>>> @@ -482,6 +491,11 @@ static int mtk_smi_common_probe(struct
>>> platform_device *pdev)
>>> ret = clk_prepare_enable(common->clk_async);
>>> if (ret)
>>> return ret;
>>> + } else {
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + common->base = devm_ioremap_resource(dev, res);
>>> + if (IS_ERR(common->base))
>>> + return PTR_ERR(common->base);
>>> }
>>> pm_runtime_enable(dev);
>>> platform_set_drvdata(pdev, common);
>>> @@ -497,6 +511,7 @@ static int mtk_smi_common_remove(struct
>>> platform_device *pdev)
>>> static int __maybe_unused mtk_smi_common_resume(struct device *dev)
>>> {
>>> struct mtk_smi *common = dev_get_drvdata(dev);
>>> + u32 bus_sel = common->plat->bus_sel;
>>> int ret;
>>>
>>> ret = mtk_smi_clk_enable(common);
>>> @@ -504,6 +519,9 @@ static int __maybe_unused mtk_smi_common_resume(struct
>>> device *dev)
>>> dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
>>> return ret;
>>> }
>>> +
>>> + if (common->plat->gen == MTK_SMI_GEN2 && bus_sel)
>>> + writel(bus_sel, common->base + SMI_BUS_SEL);
>>> return 0;
>>> }
>>>
>>> --
>>> 1.9.1
>>>
>>>
>>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [PATCH v6 5/7] [media] marvell-ccic/mmp: add devicetree support
From: Lubomir Rintel @ 2019-06-20 11:37 UTC (permalink / raw)
To: Sakari Ailus, Jacopo Mondi
Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-media, linux-kernel,
Pavel Machek
In-Reply-To: <20190620113511.rxoybnxm2exv2ibl@valkosipuli.retiisi.org.uk>
On Thu, 2019-06-20 at 14:35 +0300, Sakari Ailus wrote:
> Ping?
>
> Lubomir: I'm applying the set now, but please addres Jacopo's comment.
> Thanks.
Hi, I'm wondering if you could wait a couple of minutes?
I've tested the patch set on my machine last night and I was about to
submit the updated set just now.
Alternatively, I can just address Jacopo's comment with a patch that
applies on top of the set, but it would make slightly more sense if it
came earlier.
Thanks
Lubo
^ permalink raw reply
* Re: [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183
From: Matthias Brugger @ 2019-06-20 11:38 UTC (permalink / raw)
To: Pi-Hsun Shih, Yong Wu
Cc: youlin.pei,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Nicolas Boichat, srv_heupstream, Joerg Roedel, Will Deacon,
open list, Evan Green, Tomasz Figa, iommu, Rob Herring,
moderated list:ARM/Mediatek SoC support, Sascha Hauer,
yingjoe.chen, anan.sun, Robin Murphy, Matthias Kaehlcke,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <eee15db0-e43f-de9b-28a0-93bdd04836d7@gmail.com>
CCing Sascha
On 20/06/2019 11:35, Matthias Brugger wrote:
>
>
> On 13/06/2019 10:14, Pi-Hsun Shih wrote:
>> Hi,
>> When I tested this patch series (Based on linux 5.2.0-rc2, and with
>> various other patch series about MT8183) with lockdep enabled, and I'm
>> seeing the following lockdep warning on boot.
>>
>> By bisecting the commits, the first commit that introduce this warning
>> is this patch. The warning also doesn't appear if
>> https://lore.kernel.org/patchwork/patch/1086582/ and
>> https://lore.kernel.org/patchwork/patch/1086583/ are not applied.
>>
>> Do anyone have idea on why this is happening, or any suggestion on
>> which part I should be digging into to figure this out? Thanks.
>>
>> [ 4.664194] ======================================================
>> [ 4.670368] WARNING: possible circular locking dependency detected
>> [ 4.676545] 5.2.0-rc2-next-20190528-44527-g6c94b6475c04 #20 Tainted: G S
>> [ 4.684539] ------------------------------------------------------
>> [ 4.690714] kworker/4:1/51 is trying to acquire lock:
>> [ 4.695760] (____ptrval____) (regulator_list_mutex){+.+.},
>> at:regulator_lock_dependent+0xdc/0x6c4
>> [ 4.704732]
>> [ 4.704732] but task is already holding lock:
>> [ 4.710556] (____ptrval____) (&genpd->mlock/1){+.+.},
>> at:genpd_lock_nested_mtx+0x24/0x30
>> [ 4.718740]
>> [ 4.718740] which lock already depends on the new lock.
>> [ 4.718740]
>> [ 4.726908]
>> [ 4.726908] the existing dependency chain (in reverse order) is:
>> [ 4.734382]
>> [ 4.734382] -> #4 (&genpd->mlock/1){+.+.}:
>> [ 4.739963] __mutex_lock_common+0x1a0/0x1fe8
>> [ 4.744836] mutex_lock_nested+0x40/0x50
>> [ 4.749275] genpd_lock_nested_mtx+0x24/0x30
>> [ 4.754063] genpd_add_subdomain+0x150/0x524
>> [ 4.758850] pm_genpd_add_subdomain+0x3c/0x5c
>> [ 4.763723] scpsys_probe+0x520/0xe78
>> [ 4.767902] platform_drv_probe+0xf4/0x134
>> [ 4.772517] really_probe+0x214/0x4dc
>> [ 4.776696] driver_probe_device+0xcc/0x1d4
>> [ 4.781396] __device_attach_driver+0x10c/0x180
>> [ 4.786442] bus_for_each_drv+0x124/0x184
>> [ 4.790968] __device_attach+0x1c0/0x2d8
>> [ 4.795407] device_initial_probe+0x20/0x2c
>> [ 4.800106] bus_probe_device+0x80/0x16c
>> [ 4.804546] deferred_probe_work_func+0x120/0x168
>> [ 4.809767] process_one_work+0x858/0x1208
>> [ 4.814379] worker_thread+0x9ec/0xcb8
>> [ 4.818644] kthread+0x2b8/0x2d0
>> [ 4.822391] ret_from_fork+0x10/0x18
>> [ 4.826480]
>> [ 4.826480] -> #3 (&genpd->mlock){+.+.}:
>> [ 4.831880] __mutex_lock_common+0x1a0/0x1fe8
>> [ 4.836752] mutex_lock_nested+0x40/0x50
>> [ 4.841190] genpd_lock_mtx+0x20/0x2c
>> [ 4.845369] genpd_runtime_resume+0x140/0x434
>> [ 4.850241] __rpm_callback+0xb0/0x1e4
>> [ 4.854506] rpm_callback+0x54/0x1a8
>> [ 4.858597] rpm_resume+0xc6c/0x10c4
>> [ 4.862689] __pm_runtime_resume+0xb4/0x124
>> [ 4.867387] device_link_add+0x598/0x8d0
>
> For this looks as if you have also patch
> [PATCH v2 04/12] memory: mtk-smi: Add device-link between smi-larb and smi-common
> from series
> [PATCH v2 00/12] Clean up "mediatek,larb" after adding device_link
> applied.
>
My guess is, that we run into this, because we call genpd_runtime_resume before
we have finished the subdomain registration in scpsys_probe.
That implies that you also have the scpsys series for mt8183 added to your tree.
Anyway it looks to me as if we have to add the subdomains before we call
of_genpd_add_provider_onecell().
Regards,
Matthias
> Regards,
> Matthias
>
>> [ 4.871829] mtk_smi_larb_probe+0x2b0/0x340
>> [ 4.876528] platform_drv_probe+0xf4/0x134
>> [ 4.881141] really_probe+0x214/0x4dc
>> [ 4.885320] driver_probe_device+0xcc/0x1d4
>> [ 4.890020] __device_attach_driver+0x10c/0x180
>> [ 4.895066] bus_for_each_drv+0x124/0x184
>> [ 4.899591] __device_attach+0x1c0/0x2d8
>> [ 4.904031] device_initial_probe+0x20/0x2c
>> [ 4.908730] bus_probe_device+0x80/0x16c
>> [ 4.913169] deferred_probe_work_func+0x120/0x168
>> [ 4.918387] process_one_work+0x858/0x1208
>> [ 4.923000] worker_thread+0x9ec/0xcb8
>> [ 4.927264] kthread+0x2b8/0x2d0
>> [ 4.931009] ret_from_fork+0x10/0x18
>> [ 4.935098]
>> [ 4.935098] -> #2 (dpm_list_mtx){+.+.}:
>> [ 4.940412] __mutex_lock_common+0x1a0/0x1fe8
>> [ 4.945284] mutex_lock_nested+0x40/0x50
>> [ 4.949722] device_pm_lock+0x1c/0x24
>> [ 4.953900] device_link_add+0x98/0x8d0
>> [ 4.958252] _regulator_get+0x3f0/0x504
>> [ 4.962606] _devm_regulator_get+0x58/0xb8
>> [ 4.967218] devm_regulator_get+0x28/0x34
>> [ 4.971746] pwm_backlight_probe+0x61c/0x1b90
>> [ 4.976617] platform_drv_probe+0xf4/0x134
>> [ 4.981230] really_probe+0x214/0x4dc
>> [ 4.985409] driver_probe_device+0xcc/0x1d4
>> [ 4.990108] device_driver_attach+0xe4/0x104
>> [ 4.994894] __driver_attach+0x134/0x14c
>> [ 4.999333] bus_for_each_dev+0x120/0x180
>> [ 5.003859] driver_attach+0x48/0x54
>> [ 5.007950] bus_add_driver+0x2ac/0x44c
>> [ 5.012303] driver_register+0x160/0x288
>> [ 5.016742] __platform_driver_register+0xcc/0xdc
>> [ 5.021964] pwm_backlight_driver_init+0x1c/0x24
>> [ 5.027097] do_one_initcall+0x38c/0x994
>> [ 5.031536] do_initcall_level+0x3a4/0x4b8
>> [ 5.036148] do_basic_setup+0x84/0xa0
>> [ 5.036153] kernel_init_freeable+0x23c/0x324
>> [ 5.036158] kernel_init+0x14/0x110
>> [ 5.036164] ret_from_fork+0x10/0x18
>> [ 5.036166]
>> [ 5.036166] -> #1 (device_links_lock){+.+.}:
>> [ 5.065905] __mutex_lock_common+0x1a0/0x1fe8
>> [ 5.070777] mutex_lock_nested+0x40/0x50
>> [ 5.075215] device_link_remove+0x40/0xe0
>> [ 5.079740] _regulator_put+0x104/0x2d8
>> [ 5.084093] regulator_put+0x30/0x44
>> [ 5.088184] devm_regulator_release+0x38/0x44
>> [ 5.093056] release_nodes+0x604/0x670
>> [ 5.097320] devres_release_all+0x70/0x8c
>> [ 5.101846] really_probe+0x270/0x4dc
>> [ 5.106024] driver_probe_device+0xcc/0x1d4
>> [ 5.110724] device_driver_attach+0xe4/0x104
>> [ 5.115510] __driver_attach+0x134/0x14c
>> [ 5.119949] bus_for_each_dev+0x120/0x180
>> [ 5.124474] driver_attach+0x48/0x54
>> [ 5.128566] bus_add_driver+0x2ac/0x44c
>> [ 5.132919] driver_register+0x160/0x288
>> [ 5.137357] __platform_driver_register+0xcc/0xdc
>> [ 5.142576] pwm_backlight_driver_init+0x1c/0x24
>> [ 5.147708] do_one_initcall+0x38c/0x994
>> [ 5.152146] do_initcall_level+0x3a4/0x4b8
>> [ 5.156758] do_basic_setup+0x84/0xa0
>> [ 5.160936] kernel_init_freeable+0x23c/0x324
>> [ 5.165807] kernel_init+0x14/0x110
>> [ 5.169813] ret_from_fork+0x10/0x18
>> [ 5.173901]
>> [ 5.173901] -> #0 (regulator_list_mutex){+.+.}:
>> [ 5.179910] lock_acquire+0x350/0x4d4
>> [ 5.184088] __mutex_lock_common+0x1a0/0x1fe8
>> [ 5.184095] mutex_lock_nested+0x40/0x50
>> [ 5.197475] regulator_lock_dependent+0xdc/0x6c4
>> [ 5.197482] regulator_disable+0xa0/0x138
>> [ 5.197487] scpsys_power_off+0x38c/0x4bc
>> [ 5.197495] genpd_power_off+0x3d8/0x6a0
>> [ 5.209399] genpd_power_off+0x530/0x6a0
>> [ 5.209406] genpd_power_off_work_fn+0x74/0xc0
>> [ 5.209411] process_one_work+0x858/0x1208
>> [ 5.209419] worker_thread+0x9ec/0xcb8
>> [ 5.219067] kthread+0x2b8/0x2d0
>> [ 5.219073] ret_from_fork+0x10/0x18
>> [ 5.219077]
>> [ 5.219077] other info that might help us debug this:
>> [ 5.219077]
>> [ 5.219080] Chain exists of:
>> [ 5.219080] regulator_list_mutex --> &genpd->mlock --> &genpd->mlock/1
>> [ 5.219080]
>> [ 5.228039] Possible unsafe locking scenario:
>> [ 5.228039]
>> [ 5.228042] CPU0 CPU1
>> [ 5.228046] ---- ----
>> [ 5.228048] lock(&genpd->mlock/1);
>> [ 5.228058] lock(&genpd->mlock);
>> [ 5.311647] lock(&genpd->mlock/1);
>> [ 5.317736] lock(regulator_list_mutex);
>> [ 5.321742]
>> [ 5.321742] *** DEADLOCK ***
>> [ 5.321742]
>> [ 5.327655] 4 locks held by kworker/4:1/51:
>> [ 5.331831] #0: (____ptrval____) ((wq_completion)pm){+.+.},
>> at:process_one_work+0x57c/0x1208
>> [ 5.340444] #1: (____ptrval____)
>> ((work_completion)(&genpd->power_off_work)){+.+.},
>> at:process_one_work+0x5b8/0x1208
>> [ 5.351139] #2: (____ptrval____) (&genpd->mlock){+.+.},
>> at:genpd_lock_mtx+0x20/0x2c
>> [ 5.358970] #3: (____ptrval____) (&genpd->mlock/1){+.+.},
>> at:genpd_lock_nested_mtx+0x24/0x30
>> [ 5.367584]
>> [ 5.367584] stack backtrace:
>> [ 5.371939] CPU: 4 PID: 51 Comm: kworker/4:1 Tainted: G S
>> 5.2.0-rc2-next-20190528-44527-g6c94b6475c04 #20
>> [ 5.382809] Workqueue: pm genpd_power_off_work_fn
>> [ 5.382816] Call trace:
>> [ 5.382822] dump_backtrace+0x0/0x2c0
>> [ 5.382830] show_stack+0x20/0x2c
>> [ 5.409174] dump_stack+0x10c/0x17c
>> [ 5.412659] print_circular_bug+0x42c/0x4d0
>> [ 5.416838] __lock_acquire+0x4c88/0x5484
>> [ 5.420843] lock_acquire+0x350/0x4d4
>> [ 5.424500] __mutex_lock_common+0x1a0/0x1fe8
>> [ 5.428851] mutex_lock_nested+0x40/0x50
>> [ 5.432770] regulator_lock_dependent+0xdc/0x6c4
>> [ 5.437383] regulator_disable+0xa0/0x138
>> [ 5.441389] scpsys_power_off+0x38c/0x4bc
>> [ 5.445393] genpd_power_off+0x3d8/0x6a0
>> [ 5.449310] genpd_power_off+0x530/0x6a0
>> [ 5.453229] genpd_power_off_work_fn+0x74/0xc0
>> [ 5.457667] process_one_work+0x858/0x1208
>> [ 5.461758] worker_thread+0x9ec/0xcb8
>> [ 5.465503] kthread+0x2b8/0x2d0
>> [ 5.468727] ret_from_fork+0x10/0x18
>>
>> On Mon, Jun 10, 2019 at 8:21 PM Yong Wu <yong.wu@mediatek.com> wrote:
>>> ...
>>
>>
>> On Mon, Jun 10, 2019 at 8:21 PM Yong Wu <yong.wu@mediatek.com> wrote:
>>
>>> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
>>> mmu0 or mmu1 to balance the bandwidth via the smi-common register
>>> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>>>
>>> In mt8183, For better performance, we switch larb1/2/5/7 to enter
>>> mmu1 while the others still keep enter mmu0.
>>>
>>> In mt8173 and mt2712, we don't get the performance issue,
>>> Keep its default value(0x0), that means all the larbs enter mmu0.
>>>
>>> Note: smi gen1(mt2701/mt7623) don't have this bus_sel.
>>>
>>> And, the base of smi-common is completely different with smi_ao_base
>>> of gen1, thus I add new variable for that.
>>>
>>> CC: Matthias Brugger <matthias.bgg@gmail.com>
>>> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
>>> Reviewed-by: Evan Green <evgreen@chromium.org>
>>> ---
>>> drivers/memory/mtk-smi.c | 22 ++++++++++++++++++++--
>>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
>>> index 9790801..08cf40d 100644
>>> --- a/drivers/memory/mtk-smi.c
>>> +++ b/drivers/memory/mtk-smi.c
>>> @@ -49,6 +49,12 @@
>>> #define SMI_LARB_NONSEC_CON(id) (0x380 + ((id) * 4))
>>> #define F_MMU_EN BIT(0)
>>>
>>> +/* SMI COMMON */
>>> +#define SMI_BUS_SEL 0x220
>>> +#define SMI_BUS_LARB_SHIFT(larbid) ((larbid) << 1)
>>> +/* All are MMU0 defaultly. Only specialize mmu1 here. */
>>> +#define F_MMU1_LARB(larbid) (0x1 << SMI_BUS_LARB_SHIFT(larbid))
>>> +
>>> enum mtk_smi_gen {
>>> MTK_SMI_GEN1,
>>> MTK_SMI_GEN2
>>> @@ -57,6 +63,7 @@ enum mtk_smi_gen {
>>> struct mtk_smi_common_plat {
>>> enum mtk_smi_gen gen;
>>> bool has_gals;
>>> + u32 bus_sel; /* Balance some larbs to enter mmu0 or
>>> mmu1 */
>>> };
>>>
>>> struct mtk_smi_larb_gen {
>>> @@ -72,8 +79,8 @@ struct mtk_smi {
>>> struct clk *clk_apb, *clk_smi;
>>> struct clk *clk_gals0, *clk_gals1;
>>> struct clk *clk_async; /*only needed by
>>> mt2701*/
>>> - void __iomem *smi_ao_base;
>>> -
>>> + void __iomem *smi_ao_base; /* only for gen1 */
>>> + void __iomem *base; /* only for gen2 */
>>> const struct mtk_smi_common_plat *plat;
>>> };
>>>
>>> @@ -410,6 +417,8 @@ static int __maybe_unused mtk_smi_larb_suspend(struct
>>> device *dev)
>>> static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
>>> .gen = MTK_SMI_GEN2,
>>> .has_gals = true,
>>> + .bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(5) |
>>> + F_MMU1_LARB(7),
>>> };
>>>
>>> static const struct of_device_id mtk_smi_common_of_ids[] = {
>>> @@ -482,6 +491,11 @@ static int mtk_smi_common_probe(struct
>>> platform_device *pdev)
>>> ret = clk_prepare_enable(common->clk_async);
>>> if (ret)
>>> return ret;
>>> + } else {
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + common->base = devm_ioremap_resource(dev, res);
>>> + if (IS_ERR(common->base))
>>> + return PTR_ERR(common->base);
>>> }
>>> pm_runtime_enable(dev);
>>> platform_set_drvdata(pdev, common);
>>> @@ -497,6 +511,7 @@ static int mtk_smi_common_remove(struct
>>> platform_device *pdev)
>>> static int __maybe_unused mtk_smi_common_resume(struct device *dev)
>>> {
>>> struct mtk_smi *common = dev_get_drvdata(dev);
>>> + u32 bus_sel = common->plat->bus_sel;
>>> int ret;
>>>
>>> ret = mtk_smi_clk_enable(common);
>>> @@ -504,6 +519,9 @@ static int __maybe_unused mtk_smi_common_resume(struct
>>> device *dev)
>>> dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
>>> return ret;
>>> }
>>> +
>>> + if (common->plat->gen == MTK_SMI_GEN2 && bus_sel)
>>> + writel(bus_sel, common->base + SMI_BUS_SEL);
>>> return 0;
>>> }
>>>
>>> --
>>> 1.9.1
>>>
>>>
>>
^ permalink raw reply
* [PATCH] sched/isolation: Prefer housekeeping cpu in local node
From: Wanpeng Li @ 2019-06-20 11:36 UTC (permalink / raw)
To: linux-kernel
Cc: Ingo Molnar, Peter Zijlstra, Ingo Molnar, Frederic Weisbecker
From: Wanpeng Li <wanpengli@tencent.com>
In real product setup, there will be houseeking cpus in each nodes, it
is prefer to do housekeeping from local node, fallback to global online
cpumask if failed to find houseeking cpu from local node.
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
---
kernel/sched/isolation.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index 123ea07..9eb6805 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -16,9 +16,16 @@ static unsigned int housekeeping_flags;
int housekeeping_any_cpu(enum hk_flags flags)
{
+ int cpu;
+
if (static_branch_unlikely(&housekeeping_overridden))
- if (housekeeping_flags & flags)
- return cpumask_any_and(housekeeping_mask, cpu_online_mask);
+ if (housekeeping_flags & flags) {
+ cpu = cpumask_any_and(housekeeping_mask, cpu_cpu_mask(smp_processor_id()));
+ if (cpu < nr_cpu_ids)
+ return cpu;
+ else
+ return cpumask_any_and(housekeeping_mask, cpu_online_mask);
+ }
return smp_processor_id();
}
EXPORT_SYMBOL_GPL(housekeeping_any_cpu);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v6 5/7] [media] marvell-ccic/mmp: add devicetree support
From: Sakari Ailus @ 2019-06-20 11:35 UTC (permalink / raw)
To: Jacopo Mondi, ubomir Rintel
Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-media, linux-kernel,
Pavel Machek
In-Reply-To: <20190614103940.4dg43fo7dmbwnpfs@uno.localdomain>
Ping?
Lubomir: I'm applying the set now, but please addres Jacopo's comment.
Thanks.
--
Sakari Ailus
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 00/28] vhost: add virtio-vhost-user transport
From: Maxime Coquelin @ 2019-06-20 11:35 UTC (permalink / raw)
To: Nikos Dragazis, dev
Cc: Tiwei Bie, Zhihong Wang, Stefan Hajnoczi, Wei Wang,
Stojaczyk Dariusz, Vangelis Koukis
In-Reply-To: <1560957293-17294-1-git-send-email-ndragazis@arrikto.com>
Hi Nikos,
On 6/19/19 5:14 PM, Nikos Dragazis wrote:
> Hi everyone,
>
> this patch series introduces the concept of the virtio-vhost-user
> transport. This is actually a revised version of an earlier RFC
> implementation that has been proposed by Stefan Hajnoczi [1]. Though
> this is a great feature, it seems to have been stalled, so I’d like to
> restart the conversation on this and hopefully get it merged with your
> help. Let me give you an overview.
Thanks for taking over the series!
I think you are already aware of that, but it arrives too late to
consider it for v19.08, as the proposal deadline is over by almost 3
weeks.
That said, it is good that you sent it early, so that we can work to
make it in for v19.11.
> The virtio-vhost-user transport is a vhost-user transport implementation
> that is based on the virtio-vhost-user device. Its key difference with
> the existing transport is that it allows deploying vhost-user targets
> inside dedicated Storage Appliance VMs instead of host user space. In
> other words, it allows having guests that act as vhost-user backends for
> other guests.
>
> The virtio-vhost-user device implements the vhost-user control plane
> (master-slave communication) as follows:
>
> 1. it parses the vhost-user messages from the vhost-user unix domain
> socket and forwards them to the slave guest through virtqueues
>
> 2. it maps the vhost memory regions in QEMU’s process address space and
> exposes them to the slave guest as a RAM-backed PCI MMIO region
>
> 3. it hooks up doorbells to the callfds. The slave guest can use these
> doorbells to interrupt the master guest driver
>
> The device code has not yet been merged into upstream QEMU, but this is
> definitely the end goal.
Could you provide a pointer to the QEMU series, and instructions to test
this new device?
> The current state is that we are awaiting for
> the approval of the virtio spec.
Ditto, a link to the spec patches would be useful.
> I have Cced Darek from the SPDK community who has helped me a lot by
> reviewing this series. Note that any device type could be implemented
> over this new transport. So, adding the virtio-vhost-user transport in
> DPDK would allow using it from SPDK as well.
>
> Getting into the code internals, this patch series makes the following
> changes:
>
> 1. introduce a generic interface for the transport-specific operations.
> Each of the two available transports, the pre-existing AF_UNIX
> transport and the virtio-vhost-user transport, is going to implement
> this interface. The AF_UNIX-specific code has been extracted from the
> core vhost-user code and is now part of the AF_UNIX transport
> implementation in trans_af_unix.c.
>
> 2. introduce the virtio-vhost-user transport. The virtio-vhost-user
> transport requires a driver for the virtio-vhost-user devices. The
> driver along with the transport implementation have been packed into
> a separate library in `drivers/virtio_vhost_user/`. The necessary
> virtio-pci code has been copied from `drivers/net/virtio/`. Some
> additional changes have been made so that the driver can utilize the
> additional resources of the virtio-vhost-user device.
>
> 3. update librte_vhost public API to enable choosing transport for each
> new vhost device. Extend the vhost net driver and vhost-scsi example
> application to export this new API to the end user.
>
> The primary changes I did to Stefan’s RFC implementation are the
> following:
>
> 1. moved postcopy live migration code into trans_af_unix.c. Postcopy
> live migration relies on the userfault fd mechanism, which cannot be
> supported by virtio-vhost-user.
>
> 2. moved setup of the log memory region into trans_af_unix.c. Setting up
> the log memory region involves mapping/unmapping guest memory. This
> is an AF_UNIX transport-specific operation.
>
> 3. introduced a vhost transport operation for
> process_slave_message_reply()
>
> 4. moved the virtio-vhost-user transport/driver into a separate library
> in `drivers/virtio_vhost_user/`. This required making vhost.h and
> vhost_user.h part of librte_vhost public API and exporting some
> private symbols via the version script. This looks better to me that
> just moving the entire librte_vhost into `drivers/`. I am not sure if
> this is the most appropriate solution. I am looking forward to your
> suggestions on this.
I'm not sure this is the right place to put it.
> 5. made use of the virtio PCI capabilities for the additional device
> resources (doorbells, shared memory). This required changes in
> virtio_pci.c and trans_virtio_vhost_user.c.
>
> 6. [minor] changed some commit headlines to comply with
> check-git-log.sh.
>
> Please, have a look and let me know about your thoughts. Any
> reviews/pointers/suggestions are welcome.
Maxime
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 4/4] target/mips: Fix if-else arms checkpatch errors in translate.c
From: Philippe Mathieu-Daudé @ 2019-06-20 11:11 UTC (permalink / raw)
To: Aleksandar Markovic, qemu-devel; +Cc: arikalo, amarkovic
In-Reply-To: <1561022396-20649-5-git-send-email-aleksandar.markovic@rt-rk.com>
On 6/20/19 11:19 AM, Aleksandar Markovic wrote:
> From: Aleksandar Markovic <amarkovic@wavecomp.com>
>
> Remove if-else-arms-related checkpatch errors.
>
> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
> target/mips/translate.c | 106 ++++++++++++++++++++++++++++++------------------
> 1 file changed, 66 insertions(+), 40 deletions(-)
>
> diff --git a/target/mips/translate.c b/target/mips/translate.c
> index 324b32a..3558b2e 100644
> --- a/target/mips/translate.c
> +++ b/target/mips/translate.c
> @@ -2619,16 +2619,18 @@ static const char * const mxuregnames[] = {
> /* General purpose registers moves. */
> static inline void gen_load_gpr(TCGv t, int reg)
> {
> - if (reg == 0)
> + if (reg == 0) {
> tcg_gen_movi_tl(t, 0);
> - else
> + } else {
> tcg_gen_mov_tl(t, cpu_gpr[reg]);
> + }
> }
>
> static inline void gen_store_gpr(TCGv t, int reg)
> {
> - if (reg != 0)
> + if (reg != 0) {
> tcg_gen_mov_tl(cpu_gpr[reg], t);
> + }
> }
>
> /* Moves to/from shadow registers. */
> @@ -2636,9 +2638,9 @@ static inline void gen_load_srsgpr(int from, int to)
> {
> TCGv t0 = tcg_temp_new();
>
> - if (from == 0)
> + if (from == 0) {
> tcg_gen_movi_tl(t0, 0);
> - else {
> + } else {
> TCGv_i32 t2 = tcg_temp_new_i32();
> TCGv_ptr addr = tcg_temp_new_ptr();
>
> @@ -2841,10 +2843,11 @@ static void gen_store_fpr64(DisasContext *ctx, TCGv_i64 t, int reg)
>
> static inline int get_fp_bit(int cc)
> {
> - if (cc)
> + if (cc) {
> return 24 + cc;
> - else
> + } else {
> return 23;
> + }
> }
>
> /* Addresses computation */
> @@ -2908,14 +2911,16 @@ static inline void gen_move_high32(TCGv ret, TCGv_i64 arg)
>
> static inline void check_cp0_enabled(DisasContext *ctx)
> {
> - if (unlikely(!(ctx->hflags & MIPS_HFLAG_CP0)))
> + if (unlikely(!(ctx->hflags & MIPS_HFLAG_CP0))) {
> generate_exception_err(ctx, EXCP_CpU, 0);
> + }
> }
>
> static inline void check_cp1_enabled(DisasContext *ctx)
> {
> - if (unlikely(!(ctx->hflags & MIPS_HFLAG_FPU)))
> + if (unlikely(!(ctx->hflags & MIPS_HFLAG_FPU))) {
> generate_exception_err(ctx, EXCP_CpU, 1);
> + }
> }
>
> /* Verify that the processor is running with COP1X instructions enabled.
> @@ -2924,8 +2929,9 @@ static inline void check_cp1_enabled(DisasContext *ctx)
>
> static inline void check_cop1x(DisasContext *ctx)
> {
> - if (unlikely(!(ctx->hflags & MIPS_HFLAG_COP1X)))
> + if (unlikely(!(ctx->hflags & MIPS_HFLAG_COP1X))) {
> generate_exception_end(ctx, EXCP_RI);
> + }
> }
>
> /* Verify that the processor is running with 64-bit floating-point
> @@ -2933,8 +2939,9 @@ static inline void check_cop1x(DisasContext *ctx)
>
> static inline void check_cp1_64bitmode(DisasContext *ctx)
> {
> - if (unlikely(~ctx->hflags & (MIPS_HFLAG_F64 | MIPS_HFLAG_COP1X)))
> + if (unlikely(~ctx->hflags & (MIPS_HFLAG_F64 | MIPS_HFLAG_COP1X))) {
> generate_exception_end(ctx, EXCP_RI);
> + }
> }
>
> /*
> @@ -2950,8 +2957,9 @@ static inline void check_cp1_64bitmode(DisasContext *ctx)
> */
> static inline void check_cp1_registers(DisasContext *ctx, int regs)
> {
> - if (unlikely(!(ctx->hflags & MIPS_HFLAG_F64) && (regs & 1)))
> + if (unlikely(!(ctx->hflags & MIPS_HFLAG_F64) && (regs & 1))) {
> generate_exception_end(ctx, EXCP_RI);
> + }
> }
>
> /* Verify that the processor is running with DSP instructions enabled.
> @@ -3040,8 +3048,9 @@ static inline void check_ps(DisasContext *ctx)
> instructions are not enabled. */
> static inline void check_mips_64(DisasContext *ctx)
> {
> - if (unlikely(!(ctx->hflags & MIPS_HFLAG_64)))
> + if (unlikely(!(ctx->hflags & MIPS_HFLAG_64))) {
> generate_exception_end(ctx, EXCP_RI);
> + }
> }
> #endif
>
> @@ -3131,8 +3140,7 @@ static inline void check_nms_dl_il_sl_tl_l2c(DisasContext *ctx)
> !(ctx->CP0_Config1 & (1 << CP0C1_IL)) &&
> !(ctx->CP0_Config2 & (1 << CP0C2_SL)) &&
> !(ctx->CP0_Config2 & (1 << CP0C2_TL)) &&
> - !(ctx->CP0_Config5 & (1 << CP0C5_L2C)))
> - {
> + !(ctx->CP0_Config5 & (1 << CP0C5_L2C))) {
> generate_exception_end(ctx, EXCP_RI);
> }
> }
> @@ -3882,22 +3890,25 @@ static void gen_logic_imm(DisasContext *ctx, uint32_t opc,
> uimm = (uint16_t)imm;
> switch (opc) {
> case OPC_ANDI:
> - if (likely(rs != 0))
> + if (likely(rs != 0)) {
> tcg_gen_andi_tl(cpu_gpr[rt], cpu_gpr[rs], uimm);
> - else
> + } else {
> tcg_gen_movi_tl(cpu_gpr[rt], 0);
> + }
> break;
> case OPC_ORI:
> - if (rs != 0)
> + if (rs != 0) {
> tcg_gen_ori_tl(cpu_gpr[rt], cpu_gpr[rs], uimm);
> - else
> + } else {
> tcg_gen_movi_tl(cpu_gpr[rt], uimm);
> + }
> break;
> case OPC_XORI:
> - if (likely(rs != 0))
> + if (likely(rs != 0)) {
> tcg_gen_xori_tl(cpu_gpr[rt], cpu_gpr[rs], uimm);
> - else
> + } else {
> tcg_gen_movi_tl(cpu_gpr[rt], uimm);
> + }
> break;
> case OPC_LUI:
> if (rs != 0 && (ctx->insn_flags & ISA_MIPS32R6)) {
> @@ -6060,8 +6071,9 @@ static void gen_compute_branch (DisasContext *ctx, uint32_t opc,
> }
>
> out:
> - if (insn_bytes == 2)
> + if (insn_bytes == 2) {
> ctx->hflags |= MIPS_HFLAG_B16;
> + }
> tcg_temp_free(t0);
> tcg_temp_free(t1);
> }
> @@ -6708,8 +6720,9 @@ static void gen_mfc0(DisasContext *ctx, TCGv arg, int reg, int sel)
> {
> const char *register_name = "invalid";
>
> - if (sel != 0)
> + if (sel != 0) {
> check_insn(ctx, ISA_MIPS32);
> + }
>
> switch (reg) {
> case CP0_REGISTER_00:
> @@ -7464,8 +7477,9 @@ static void gen_mtc0(DisasContext *ctx, TCGv arg, int reg, int sel)
> {
> const char *register_name = "invalid";
>
> - if (sel != 0)
> + if (sel != 0) {
> check_insn(ctx, ISA_MIPS32);
> + }
>
> if (tb_cflags(ctx->base.tb) & CF_USE_ICOUNT) {
> gen_io_start();
> @@ -8210,8 +8224,9 @@ static void gen_dmfc0(DisasContext *ctx, TCGv arg, int reg, int sel)
> {
> const char *register_name = "invalid";
>
> - if (sel != 0)
> + if (sel != 0) {
> check_insn(ctx, ISA_MIPS64);
> + }
>
> switch (reg) {
> case CP0_REGISTER_00:
> @@ -8920,8 +8935,9 @@ static void gen_dmtc0(DisasContext *ctx, TCGv arg, int reg, int sel)
> {
> const char *register_name = "invalid";
>
> - if (sel != 0)
> + if (sel != 0) {
> check_insn(ctx, ISA_MIPS64);
> + }
>
> if (tb_cflags(ctx->base.tb) & CF_USE_ICOUNT) {
> gen_io_start();
> @@ -10162,8 +10178,9 @@ static void gen_cp0(CPUMIPSState *env, DisasContext *ctx, uint32_t opc,
> break;
> case OPC_TLBWI:
> opn = "tlbwi";
> - if (!env->tlb->helper_tlbwi)
> + if (!env->tlb->helper_tlbwi) {
> goto die;
> + }
> gen_helper_tlbwi(cpu_env);
> break;
> case OPC_TLBINV:
> @@ -10186,20 +10203,23 @@ static void gen_cp0(CPUMIPSState *env, DisasContext *ctx, uint32_t opc,
> break;
> case OPC_TLBWR:
> opn = "tlbwr";
> - if (!env->tlb->helper_tlbwr)
> + if (!env->tlb->helper_tlbwr) {
> goto die;
> + }
> gen_helper_tlbwr(cpu_env);
> break;
> case OPC_TLBP:
> opn = "tlbp";
> - if (!env->tlb->helper_tlbp)
> + if (!env->tlb->helper_tlbp) {
> goto die;
> + }
> gen_helper_tlbp(cpu_env);
> break;
> case OPC_TLBR:
> opn = "tlbr";
> - if (!env->tlb->helper_tlbr)
> + if (!env->tlb->helper_tlbr) {
> goto die;
> + }
> gen_helper_tlbr(cpu_env);
> break;
> case OPC_ERET: /* OPC_ERETNC */
> @@ -10273,8 +10293,9 @@ static void gen_compute_branch1(DisasContext *ctx, uint32_t op,
> goto out;
> }
>
> - if (cc != 0)
> + if (cc != 0) {
> check_insn(ctx, ISA_MIPS4 | ISA_MIPS32);
> + }
>
> btarget = ctx->base.pc_next + 4 + offset;
>
> @@ -10728,10 +10749,11 @@ static void gen_movci(DisasContext *ctx, int rd, int rs, int cc, int tf)
> return;
> }
>
> - if (tf)
> + if (tf) {
> cond = TCG_COND_EQ;
> - else
> + } else {
> cond = TCG_COND_NE;
> + }
>
> l1 = gen_new_label();
> t0 = tcg_temp_new_i32();
> @@ -10753,10 +10775,11 @@ static inline void gen_movcf_s(DisasContext *ctx, int fs, int fd, int cc,
> TCGv_i32 t0 = tcg_temp_new_i32();
> TCGLabel *l1 = gen_new_label();
>
> - if (tf)
> + if (tf) {
> cond = TCG_COND_EQ;
> - else
> + } else {
> cond = TCG_COND_NE;
> + }
>
> tcg_gen_andi_i32(t0, fpu_fcr31, 1 << get_fp_bit(cc));
> tcg_gen_brcondi_i32(cond, t0, 0, l1);
> @@ -10774,10 +10797,11 @@ static inline void gen_movcf_d(DisasContext *ctx, int fs, int fd, int cc,
> TCGv_i64 fp0;
> TCGLabel *l1 = gen_new_label();
>
> - if (tf)
> + if (tf) {
> cond = TCG_COND_EQ;
> - else
> + } else {
> cond = TCG_COND_NE;
> + }
>
> tcg_gen_andi_i32(t0, fpu_fcr31, 1 << get_fp_bit(cc));
> tcg_gen_brcondi_i32(cond, t0, 0, l1);
> @@ -10797,10 +10821,11 @@ static inline void gen_movcf_ps(DisasContext *ctx, int fs, int fd,
> TCGLabel *l1 = gen_new_label();
> TCGLabel *l2 = gen_new_label();
>
> - if (tf)
> + if (tf) {
> cond = TCG_COND_EQ;
> - else
> + } else {
> cond = TCG_COND_NE;
> + }
>
> tcg_gen_andi_i32(t0, fpu_fcr31, 1 << get_fp_bit(cc));
> tcg_gen_brcondi_i32(cond, t0, 0, l1);
> @@ -12096,8 +12121,9 @@ static void gen_farith(DisasContext *ctx, enum fopcode op1,
> TCGLabel *l1 = gen_new_label();
> TCGv_i64 fp0;
>
> - if (ft != 0)
> + if (ft != 0) {
> tcg_gen_brcondi_tl(TCG_COND_NE, cpu_gpr[ft], 0, l1);
> + }
> fp0 = tcg_temp_new_i64();
> gen_load_fpr64(ctx, fp0, fs);
> gen_store_fpr64(ctx, fp0, fd);
>
^ permalink raw reply
* Re: hdpvr mutex deadlock on kernel 5.1.x
From: Hans Verkuil @ 2019-06-20 11:33 UTC (permalink / raw)
To: Keith Pyle, Linux Media Mailing List
In-Reply-To: <15f3c149-4597-2f45-06af-a668db4c694b@austin.rr.com>
On 6/19/19 4:29 AM, Keith Pyle wrote:
> On 06/18/19 02:16, Hans Verkuil wrote:
>> Hi Keith,
>>
>> On 6/18/19 6:17 AM, Keith Pyle wrote:
>>> We made the suggested change, compiled, installed, and rebooted. There was some progress - test 2 (turning the HD-PVR off) no longer produces a splat. Test 1 (start capture) and test 3 (run capture
>>> and trigger HD-PVR to stop streaming) both still produce a traceback (see below). Test 3 also still results in the unkillable process.
>> Try the following patch. Test 2 was caused by locking when it shouldn't, test 3 was caused by not
>> locking when it should :-) and I think test 1 was caused by locking when it is not allowed.
>>
>> Let me know if this works!
>>
>> Regards,
>>
>> Hans
> Good news! With these patches, lockdep does not report any of the prior problems and the capture process does not deadlock for my test3.
>
> There is one item I noted: hdpvr_read has the line
>
> msec_to_jiffies(4000);
Oops!
>
> that doesn't really do anything. This should be a 4 second sleep, based on our discussion back in 2014 (https://www.mail-archive.com/linux-media@vger.kernel.org/msg75163.html), since the restart will
> certainly fail unless the HD-PVR is given at least 3 seconds to reset after the stop.
I think a msleep(4000) at that point is solving only one use-case. I assume
the same problem will occur if you read() from the video device, then close()
it, re-open it and read() again, all within 4 seconds.
The real fix would be to store a timestamp (jiffies) when you stop streaming,
and in start_streaming check if there are less than 4 seconds between the last
stop and new start, and then sleep until 4 seconds have passed.
Is this something you can work on and provide a patch?
For now I'll post a patch fixing the deadlocks etc. so you can develop your
patch for this on top.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 1/1] drivers/staging/rtl8129u: adjust block comments
From: Greg KH @ 2019-06-20 11:33 UTC (permalink / raw)
To: Christian Müller
Cc: johnfwhitmore, devel, linux-kernel, linux-kernel, felix.trommer
In-Reply-To: <20190620094534.5658-2-muellerch-privat@web.de>
On Thu, Jun 20, 2019 at 11:45:34AM +0200, Christian Müller wrote:
> As stated in coding-styles.rst multiline comments should be structured in a way,
> that the actual comment starts on the second line of the commented portion. E.g:
>
> /*
> * Multiline comments
> * should look like
> * this.
> */
>
> The comments in this file were of a format, that looked like this:
>
> /* Multiline comments previous
> * to this patch
> * looked like this.
> */
>
> There is an exception to files in /net and drivers/net,
> where multiline comments are preferred to look like the second example above,
> but since this file resides in a different directory,
> this patch changes the style to match the preferred style.
Ah. Hm. Turns out this is a networking driver, and some day, the goal
would be for it to live under drivers/net/ If it were to move there,
then these comments would be in the correct format already.
So this patch isn't needed, sorry.
greg k-h
^ permalink raw reply
* [Buildroot] [PATCH 1/1] package/gzip: bump to version 1.10
From: Peter Korsgaard @ 2019-06-20 11:32 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20190619213742.13005-1-fontaine.fabrice@gmail.com>
>>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes:
> Remove patch (already in version)
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit] package/gzip: bump to version 1.10
From: Peter Korsgaard @ 2019-06-20 11:32 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=7bf3e78038cb1677de3975d1e5c40be0c352cc3f
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Remove patch (already in version)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
...lush-adjust-to-glibc-2.28-libio.h-removal.patch | 189 ---------------------
package/gzip/gzip.hash | 4 +-
package/gzip/gzip.mk | 2 +-
3 files changed, 3 insertions(+), 192 deletions(-)
diff --git a/package/gzip/0001-fflush-adjust-to-glibc-2.28-libio.h-removal.patch b/package/gzip/0001-fflush-adjust-to-glibc-2.28-libio.h-removal.patch
deleted file mode 100644
index 11d2af6d47..0000000000
--- a/package/gzip/0001-fflush-adjust-to-glibc-2.28-libio.h-removal.patch
+++ /dev/null
@@ -1,189 +0,0 @@
-From 1831628c0630ae96a43586b2a25ca51cbdba3e53 Mon Sep 17 00:00:00 2001
-From: Paul Eggert <address@hidden>
-Date: Mon, 5 Mar 2018 10:56:29 -0800
-Subject: [PATCH] fflush: adjust to glibc 2.28 libio.h removal
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Problem reported by Daniel P. Berrange in:
-https://lists.gnu.org/r/bug-gnulib/2018-03/msg00000.html
-* lib/fbufmode.c (fbufmode):
-* lib/fflush.c (clear_ungetc_buffer_preserving_position)
-(disable_seek_optimization, rpl_fflush):
-* lib/fpending.c (__fpending):
-* lib/fpurge.c (fpurge):
-* lib/freadable.c (freadable):
-* lib/freadahead.c (freadahead):
-* lib/freading.c (freading):
-* lib/freadptr.c (freadptr):
-* lib/freadseek.c (freadptrinc):
-* lib/fseeko.c (fseeko):
-* lib/fseterr.c (fseterr):
-* lib/fwritable.c (fwritable):
-* lib/fwriting.c (fwriting):
-Check _IO_EOF_SEEN instead of _IO_ftrylockfile.
-* lib/stdio-impl.h (_IO_IN_BACKUP) [_IO_EOF_SEEN]:
-Define if not already defined.
----
-
-Upstream-Status: Pending
-Signed-off-by: Khem Raj <raj.khem@gmail.com>
-Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
-
- ChangeLog | 23 +++++++++++++++++++++++
- lib/fbufmode.c | 2 +-
- lib/fflush.c | 6 +++---
- lib/fpending.c | 2 +-
- lib/fpurge.c | 2 +-
- lib/freadable.c | 2 +-
- lib/freadahead.c | 2 +-
- lib/freading.c | 2 +-
- lib/freadptr.c | 2 +-
- lib/freadseek.c | 2 +-
- lib/fseeko.c | 4 ++--
- lib/fseterr.c | 2 +-
- lib/fwritable.c | 2 +-
- lib/fwriting.c | 2 +-
- lib/stdio-impl.h | 6 ++++++
- 15 files changed, 45 insertions(+), 16 deletions(-)
-
-Index: gzip-1.9/ChangeLog
-===================================================================
---- gzip-1.9.orig/ChangeLog
-+++ gzip-1.9/ChangeLog
-@@ -1,3 +1,26 @@
-+2018-03-05 Paul Eggert <address@hidden>
-+
-+ fflush: adjust to glibc 2.28 libio.h removal
-+ Problem reported by Daniel P. Berrange in:
-+ https://lists.gnu.org/r/bug-gnulib/2018-03/msg00000.html
-+ * lib/fbufmode.c (fbufmode):
-+ * lib/fflush.c (clear_ungetc_buffer_preserving_position)
-+ (disable_seek_optimization, rpl_fflush):
-+ * lib/fpending.c (__fpending):
-+ * lib/fpurge.c (fpurge):
-+ * lib/freadable.c (freadable):
-+ * lib/freadahead.c (freadahead):
-+ * lib/freading.c (freading):
-+ * lib/freadptr.c (freadptr):
-+ * lib/freadseek.c (freadptrinc):
-+ * lib/fseeko.c (fseeko):
-+ * lib/fseterr.c (fseterr):
-+ * lib/fwritable.c (fwritable):
-+ * lib/fwriting.c (fwriting):
-+ Check _IO_EOF_SEEN instead of _IO_ftrylockfile.
-+ * lib/stdio-impl.h (_IO_IN_BACKUP) [_IO_EOF_SEEN]:
-+ Define if not already defined.
-+
- 2018-01-07 Jim Meyering <meyering@fb.com>
-
- version 1.9
-Index: gzip-1.9/lib/fflush.c
-===================================================================
---- gzip-1.9.orig/lib/fflush.c
-+++ gzip-1.9/lib/fflush.c
-@@ -33,7 +33,7 @@
- #undef fflush
-
-
--#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
-+#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
-
- /* Clear the stream's ungetc buffer, preserving the value of ftello (fp). */
- static void
-@@ -72,7 +72,7 @@ clear_ungetc_buffer (FILE *fp)
-
- #endif
-
--#if ! (defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */)
-+#if ! (defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */)
-
- # if (defined __sferror || defined __DragonFly__ || defined __ANDROID__) && defined __SNPT
- /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android */
-@@ -148,7 +148,7 @@ rpl_fflush (FILE *stream)
- if (stream == NULL || ! freading (stream))
- return fflush (stream);
-
--#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
-+#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
-
- clear_ungetc_buffer_preserving_position (stream);
-
-Index: gzip-1.9/lib/fpurge.c
-===================================================================
---- gzip-1.9.orig/lib/fpurge.c
-+++ gzip-1.9/lib/fpurge.c
-@@ -62,7 +62,7 @@ fpurge (FILE *fp)
- /* Most systems provide FILE as a struct and the necessary bitmask in
- <stdio.h>, because they need it for implementing getc() and putc() as
- fast macros. */
--# if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
-+# if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
- fp->_IO_read_end = fp->_IO_read_ptr;
- fp->_IO_write_ptr = fp->_IO_write_base;
- /* Avoid memory leak when there is an active ungetc buffer. */
-Index: gzip-1.9/lib/freading.c
-===================================================================
---- gzip-1.9.orig/lib/freading.c
-+++ gzip-1.9/lib/freading.c
-@@ -31,7 +31,7 @@ freading (FILE *fp)
- /* Most systems provide FILE as a struct and the necessary bitmask in
- <stdio.h>, because they need it for implementing getc() and putc() as
- fast macros. */
--# if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
-+# if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
- return ((fp->_flags & _IO_NO_WRITES) != 0
- || ((fp->_flags & (_IO_NO_READS | _IO_CURRENTLY_PUTTING)) == 0
- && fp->_IO_read_base != NULL));
-Index: gzip-1.9/lib/fseeko.c
-===================================================================
---- gzip-1.9.orig/lib/fseeko.c
-+++ gzip-1.9/lib/fseeko.c
-@@ -47,7 +47,7 @@ fseeko (FILE *fp, off_t offset, int when
- #endif
-
- /* These tests are based on fpurge.c. */
--#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
-+#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
- if (fp->_IO_read_end == fp->_IO_read_ptr
- && fp->_IO_write_ptr == fp->_IO_write_base
- && fp->_IO_save_base == NULL)
-@@ -123,7 +123,7 @@ fseeko (FILE *fp, off_t offset, int when
- return -1;
- }
-
--#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
-+#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
- fp->_flags &= ~_IO_EOF_SEEN;
- fp->_offset = pos;
- #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
-Index: gzip-1.9/lib/fseterr.c
-===================================================================
---- gzip-1.9.orig/lib/fseterr.c
-+++ gzip-1.9/lib/fseterr.c
-@@ -29,7 +29,7 @@ fseterr (FILE *fp)
- /* Most systems provide FILE as a struct and the necessary bitmask in
- <stdio.h>, because they need it for implementing getc() and putc() as
- fast macros. */
--#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
-+#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
- fp->_flags |= _IO_ERR_SEEN;
- #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
- /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android */
-Index: gzip-1.9/lib/stdio-impl.h
-===================================================================
---- gzip-1.9.orig/lib/stdio-impl.h
-+++ gzip-1.9/lib/stdio-impl.h
-@@ -18,6 +18,12 @@
- the same implementation of stdio extension API, except that some fields
- have different naming conventions, or their access requires some casts. */
-
-+/* Glibc 2.28 made _IO_IN_BACKUP private. For now, work around this
-+ problem by defining it ourselves. FIXME: Do not rely on glibc
-+ internals. */
-+#if !defined _IO_IN_BACKUP && defined _IO_EOF_SEEN
-+# define _IO_IN_BACKUP 0x100
-+#endif
-
- /* BSD stdio derived implementations. */
diff --git a/package/gzip/gzip.hash b/package/gzip/gzip.hash
index 632176c2b6..5675b3ed50 100644
--- a/package/gzip/gzip.hash
+++ b/package/gzip/gzip.hash
@@ -1,6 +1,6 @@
# Locally calculated after checking pgp signature
-# https://ftp.gnu.org/gnu/gzip/gzip-1.9.tar.xz.sig
+# https://ftp.gnu.org/gnu/gzip/gzip-1.10.tar.xz.sig
# using key 155D3FC500C834486D1EEA677FD9FCCB000BEEEE
-sha256 ae506144fc198bd8f81f1f4ad19ce63d5a2d65e42333255977cf1dcf1479089a gzip-1.9.tar.xz
+sha256 8425ccac99872d544d4310305f915f5ea81e04d0f437ef1a230dc9d1c819d7c0 gzip-1.10.tar.xz
# Locally calculated
sha256 8ceb4b9ee5adedde47b31e975c1d90c73ad27b6b165a1dcd80c7c545eb65b903 COPYING
diff --git a/package/gzip/gzip.mk b/package/gzip/gzip.mk
index 8ac6ddd6ed..17b27b497c 100644
--- a/package/gzip/gzip.mk
+++ b/package/gzip/gzip.mk
@@ -4,7 +4,7 @@
#
################################################################################
-GZIP_VERSION = 1.9
+GZIP_VERSION = 1.10
GZIP_SOURCE = gzip-$(GZIP_VERSION).tar.xz
GZIP_SITE = $(BR2_GNU_MIRROR)/gzip
# Some other tools expect it to be in /bin
^ permalink raw reply related
* Re: [dpdk-dev] [PATCH 00/28] vhost: add virtio-vhost-user transport
From: Ilya Maximets @ 2019-06-20 11:32 UTC (permalink / raw)
To: Nikos Dragazis, dev
Cc: Maxime Coquelin, Tiwei Bie, Zhihong Wang, Stefan Hajnoczi,
Wei Wang, Stojaczyk Dariusz, Vangelis Koukis
In-Reply-To: <1560957293-17294-1-git-send-email-ndragazis@arrikto.com>
On 19.06.2019 18:14, Nikos Dragazis wrote:
> Hi everyone,
Hi. I didn't look at the code, just a few comments inline.
>
> this patch series introduces the concept of the virtio-vhost-user
> transport. This is actually a revised version of an earlier RFC
> implementation that has been proposed by Stefan Hajnoczi [1]. Though
> this is a great feature, it seems to have been stalled, so I’d like to
> restart the conversation on this and hopefully get it merged with your
> help. Let me give you an overview.
>
> The virtio-vhost-user transport is a vhost-user transport implementation
> that is based on the virtio-vhost-user device. Its key difference with
> the existing transport is that it allows deploying vhost-user targets
> inside dedicated Storage Appliance VMs instead of host user space. In
> other words, it allows having guests that act as vhost-user backends for
> other guests.
>
> The virtio-vhost-user device implements the vhost-user control plane
> (master-slave communication) as follows:
>
> 1. it parses the vhost-user messages from the vhost-user unix domain
> socket and forwards them to the slave guest through virtqueues
>
> 2. it maps the vhost memory regions in QEMU’s process address space and
> exposes them to the slave guest as a RAM-backed PCI MMIO region
>
> 3. it hooks up doorbells to the callfds. The slave guest can use these
> doorbells to interrupt the master guest driver
>
> The device code has not yet been merged into upstream QEMU, but this is
> definitely the end goal. The current state is that we are awaiting for
> the approval of the virtio spec.
>
> I have Cced Darek from the SPDK community who has helped me a lot by
> reviewing this series. Note that any device type could be implemented
> over this new transport. So, adding the virtio-vhost-user transport in
> DPDK would allow using it from SPDK as well.
>
> Getting into the code internals, this patch series makes the following
> changes:
>
> 1. introduce a generic interface for the transport-specific operations.
> Each of the two available transports, the pre-existing AF_UNIX
> transport and the virtio-vhost-user transport, is going to implement
> this interface. The AF_UNIX-specific code has been extracted from the
> core vhost-user code and is now part of the AF_UNIX transport
> implementation in trans_af_unix.c.
>
> 2. introduce the virtio-vhost-user transport. The virtio-vhost-user
> transport requires a driver for the virtio-vhost-user devices. The
> driver along with the transport implementation have been packed into
> a separate library in `drivers/virtio_vhost_user/`. The necessary
> virtio-pci code has been copied from `drivers/net/virtio/`. Some
> additional changes have been made so that the driver can utilize the
> additional resources of the virtio-vhost-user device.
>
> 3. update librte_vhost public API to enable choosing transport for each
> new vhost device. Extend the vhost net driver and vhost-scsi example
> application to export this new API to the end user.
>
> The primary changes I did to Stefan’s RFC implementation are the
> following:
>
> 1. moved postcopy live migration code into trans_af_unix.c. Postcopy
> live migration relies on the userfault fd mechanism, which cannot be
> supported by virtio-vhost-user.
>
> 2. moved setup of the log memory region into trans_af_unix.c. Setting up
> the log memory region involves mapping/unmapping guest memory. This
> is an AF_UNIX transport-specific operation.
Logging dirty pages is the main concept of live migration support. Does it
mean that the live migration is not supported for virtio-vhost-user at all?
>
> 3. introduced a vhost transport operation for
> process_slave_message_reply()
>
> 4. moved the virtio-vhost-user transport/driver into a separate library
> in `drivers/virtio_vhost_user/`. This required making vhost.h and
> vhost_user.h part of librte_vhost public API and exporting some
> private symbols via the version script. This looks better to me that
> just moving the entire librte_vhost into `drivers/`. I am not sure if
> this is the most appropriate solution. I am looking forward to your
> suggestions on this.
Moving the virtio-vhost-user code to a separate driver looks strange for me.
What is the purpose?
Exporting a lot of vhost internal structures will lead to a frequent API/ABI
breakages and will slow down accepting changes to releases in general.
It looks inconsistent to have 'trans_af_unix.c' in 'lib/librte_vhost/' and
'trans_virtio_vhost_user.c' in 'drivers/virtio_vhost_user/' because these
files should be similar in provided functionality, hence, should be located
in similar places.
>
> 5. made use of the virtio PCI capabilities for the additional device
> resources (doorbells, shared memory). This required changes in
> virtio_pci.c and trans_virtio_vhost_user.c.
>
> 6. [minor] changed some commit headlines to comply with
> check-git-log.sh.
>
> Please, have a look and let me know about your thoughts. Any
> reviews/pointers/suggestions are welcome.
>
> Best regards,
> Nikos
>
> [1] http://mails.dpdk.org/archives/dev/2018-January/088155.html
>
>
> Nikos Dragazis (23):
> vhost: introduce vhost transport operations structure
> vhost: move socket management code
> vhost: move socket fd and un sockaddr
> vhost: move vhost-user connection
> vhost: move vhost-user reconnection
> vhost: move vhost-user fdset
> vhost: propagate vhost transport operations
> vhost: use a single structure for the device state
> vhost: extract socket I/O into transport
> vhost: move slave request fd and lock
> vhost: move mmap/munmap
> vhost: move setup of the log memory region
> vhost: remove main fd parameter from msg handlers
> vhost: move postcopy live migration code
> vhost: support registering additional vhost-user transports
> drivers/virtio_vhost_user: add virtio PCI framework
> drivers: add virtio-vhost-user transport
> drivers/virtio_vhost_user: use additional device resources
> vhost: add flag for choosing vhost-user transport
> net/vhost: add virtio-vhost-user support
> mk: link apps with virtio-vhost-user driver
> config: add option for the virtio-vhost-user transport
> usertools: add virtio-vhost-user devices to dpdk-devbind.py
>
> Stefan Hajnoczi (5):
> vhost: allocate per-socket transport state
> vhost: move start server/client calls
> vhost: add index field in vhost virtqueues
> examples/vhost_scsi: add --socket-file argument
> examples/vhost_scsi: add virtio-vhost-user support
>
> config/common_base | 6 +
> config/common_linux | 1 +
> drivers/Makefile | 5 +
> drivers/net/vhost/rte_eth_vhost.c | 13 +
> drivers/virtio_vhost_user/Makefile | 27 +
> .../rte_virtio_vhost_user_version.map | 4 +
> .../virtio_vhost_user/trans_virtio_vhost_user.c | 1077 +++++++++++++++++++
> drivers/virtio_vhost_user/virtio_pci.c | 520 ++++++++++
> drivers/virtio_vhost_user/virtio_pci.h | 289 ++++++
> drivers/virtio_vhost_user/virtio_vhost_user.h | 18 +
> drivers/virtio_vhost_user/virtqueue.h | 181 ++++
> examples/vhost_scsi/vhost_scsi.c | 103 +-
> lib/librte_vhost/Makefile | 4 +-
> lib/librte_vhost/rte_vhost.h | 1 +
> lib/librte_vhost/rte_vhost_version.map | 11 +
> lib/librte_vhost/socket.c | 685 +-----------
> lib/librte_vhost/trans_af_unix.c | 1094 ++++++++++++++++++++
> lib/librte_vhost/vhost.c | 22 +-
> lib/librte_vhost/vhost.h | 298 +++++-
> lib/librte_vhost/vhost_user.c | 474 ++-------
> lib/librte_vhost/vhost_user.h | 10 +-
> mk/rte.app.mk | 6 +
> usertools/dpdk-devbind.py | 7 +
> 23 files changed, 3764 insertions(+), 1092 deletions(-)
> create mode 100644 drivers/virtio_vhost_user/Makefile
> create mode 100644 drivers/virtio_vhost_user/rte_virtio_vhost_user_version.map
> create mode 100644 drivers/virtio_vhost_user/trans_virtio_vhost_user.c
> create mode 100644 drivers/virtio_vhost_user/virtio_pci.c
> create mode 100644 drivers/virtio_vhost_user/virtio_pci.h
> create mode 100644 drivers/virtio_vhost_user/virtio_vhost_user.h
> create mode 100644 drivers/virtio_vhost_user/virtqueue.h
> create mode 100644 lib/librte_vhost/trans_af_unix.c
>
^ permalink raw reply
* Re: [git pull] habanalabs fixes for 5.2-rc6
From: Greg KH @ 2019-06-20 11:31 UTC (permalink / raw)
To: Oded Gabbay; +Cc: linux-kernel
In-Reply-To: <20190620092213.GA16781@ogabbay-VM>
On Thu, Jun 20, 2019 at 12:22:13PM +0300, Oded Gabbay wrote:
> Hi Greg,
>
> This is a pull request containing fixes to be merged to 5.2-rc6.
>
> It contains a single minor bug fix. See the tag comment for more details.
>
> Thanks,
> Oded
>
> The following changes since commit 6ad805b82dc5fc0ffd2de1d1f0de47214a050278:
>
> doc: fix documentation about UIO_MEM_LOGICAL using (2019-06-19 19:31:21 +0200)
>
> are available in the Git repository at:
>
> git://people.freedesktop.org/~gabbayo/linux tags/misc-habanalabs-fixes-2019-06-20
Pulled and pushed out,t hanks.
greg k-h
^ permalink raw reply
* Re: [GIT PULL] USB: fixes for v5.2-rc5
From: Greg Kroah-Hartman @ 2019-06-20 11:31 UTC (permalink / raw)
To: Felipe Balbi; +Cc: linux-usb
In-Reply-To: <87h88kbowy.fsf@linux.intel.com>
On Thu, Jun 20, 2019 at 12:13:01PM +0300, Felipe Balbi wrote:
>
> Hi Greg,
>
> Just one pending fix this time.
>
> Let me know if you need anything to be changed
>
> cheers
>
>
> The following changes since commit 9e0babf2c06c73cda2c0cd37a1653d823adb40ec:
>
> Linux 5.2-rc5 (2019-06-16 08:49:45 -1000)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v5.2-rc5
Pulled and pushed out, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH] ACPI: PM: Export the function acpi_sleep_state_supported()
From: Pavel Machek @ 2019-06-20 11:30 UTC (permalink / raw)
To: Dexuan Cui
Cc: Lorenzo Pieralisi, linux-acpi@vger.kernel.org, rjw@rjwysocki.net,
lenb@kernel.org, robert.moore@intel.com, erik.schmauss@intel.com,
Russell King, Russ Dill, Sebastian Capella, Michael Kelley,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
KY Srinivasan, Stephen Hemminger, Haiyang Zhang, Sasha Levin,
olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com, vkuznets,
marcelo.cerri@canonical.com
In-Reply-To: <PU1P153MB016902786ABA34BD01430F83BFE50@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
> > From: linux-hyperv-owner@vger.kernel.org
> > <linux-hyperv-owner@vger.kernel.org> On Behalf Of Lorenzo Pieralisi
> > Sent: Monday, June 17, 2019 9:15 AM
> > > ...
> > > + some ARM experts who worked on arch/arm/kernel/hibernate.c.
> > >
> > > drivers/acpi/sleep.c is only built if ACPI_SYSTEM_POWER_STATES_SUPPORT
> > > is defined, but it looks this option is not defined on ARM.
> > >
> > > It looks ARM does not support the ACPI S4 state, then how do we know
> > > if an ARM host supports hibernation or not?
> >
> > Maybe we should start from understanding why you need to know whether
> > Hibernate is possible to answer your question ?
> >
> > On ARM64 platforms system states are entered through PSCI firmware
> > interface that works for ACPI and device tree alike.
> >
> > Lorenzo
>
> Hi Lorenzo,
> It looks I may have confused you as I didn't realize the word "ARM" only means
> 32-bit ARM. It looks the "ARM" arch and the "ARM64" arch are very different.
>
> As far as I know, Hyper-V only supports x86 and "ARM64", and it's unlikely to
> support 32-bit ARM in the future, so actually I don't really need to know if and
> how a 32-bit ARM machine supports hibernation.
>
> When a Linux guest runs on Hyper-V (x86_32, x86_64, or ARM64) , we have a
> front-end balloon driver in the guest, which balloons up/down and
> hot adds/removes the guest's memory when the host requests that. The problem
> is: the back-end driver on the host can not really save and restore the states
> related to the front-end balloon driver on guest hibernation, so we made the
> decision that balloon up/down and hot-add/remove are not supported when
> we enable hibernation for a guest; BTW, we still want to load the front-end
> driver in the guest, because the dirver has a functionality of reporting the
> guest's memory pressure to the host, which we think is useful.
>
> On x86_32 and x86_64, we enable hibernation for a guest by enabling
> the virtual ACPI S4 state for the guest; on ARM64, so far we don't have the
> host side changes required to support guest hibernation, so the details are
> still unclear.
>
> After I discussed with Michael Kelley, it looks we don't really need to
> export drivers/acpi/sleep.c: acpi_sleep_state_supported(), but I think we do
> need to make it non-static.
>
> Now I propose the below changes. I plan to submit a patch first for the
> changes made to drivers/acpi/sleep.c and include/acpi/acpi_bus.h in a few
> days, if there is no objection.
>
> Please let me know how you think of this. Thanks!
No.
Hibernation should be always supported, no matter what firmware. If it
can powerdown, it can hibernate.
That is for x86-32/64, too.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [Buildroot] [PATCH 2/2] package/haveged: fix legal-info
From: Peter Korsgaard @ 2019-06-20 11:30 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1560974743-20081-2-git-send-email-pjtexier@koncepto.io>
>>>>> "Pierre-Jean" == Pierre-Jean Texier <pjtexier@koncepto.io> writes:
> Add hash for COPYING file
> Fixes:
> $: make haveged-legal-info
>>>> haveged 1.9.4 Collecting legal info
> ERROR: No hash found for COPYING
> Signed-off-by: Pierre-Jean Texier <pjtexier@koncepto.io>
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [PATCH 1/2] package/haveged: bump to version 1.9.4
From: Peter Korsgaard @ 2019-06-20 11:30 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1560974743-20081-1-git-send-email-pjtexier@koncepto.io>
>>>>> "Pierre-Jean" == Pierre-Jean Texier <pjtexier@koncepto.io> writes:
> See https://github.com/jirka-h/haveged/releases/tag/1.9.4
> Also change the site location, upstream release
> mechanism has switched to using github.
> Signed-off-by: Pierre-Jean Texier <pjtexier@koncepto.io>
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit] package/haveged: fix legal-info
From: Peter Korsgaard @ 2019-06-20 11:30 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=0ae29b98d1293b0e89fa2f5686fe743af1f45c34
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Add hash for COPYING file
Fixes:
$: make haveged-legal-info
>>> haveged 1.9.4 Collecting legal info
ERROR: No hash found for COPYING
Signed-off-by: Pierre-Jean Texier <pjtexier@koncepto.io>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
package/haveged/haveged.hash | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/haveged/haveged.hash b/package/haveged/haveged.hash
index d98e1d984b..048941849c 100644
--- a/package/haveged/haveged.hash
+++ b/package/haveged/haveged.hash
@@ -1,2 +1,3 @@
# Locally calculated
sha256 c4959d3cb1fa6391d16a3aa1ba4d82cd3a0d497206ae4b87d638088c0664e5aa haveged-1.9.4.tar.gz
+sha256 8ceb4b9ee5adedde47b31e975c1d90c73ad27b6b165a1dcd80c7c545eb65b903 COPYING
^ permalink raw reply related
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.