* [PATCH 4.4 031/107] x86/speculation: Update Speculation Control microcode blacklist
From: Greg Kroah-Hartman @ 2018-07-23 12:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Woodhouse, Andy Lutomirski,
Arjan van de Ven, Borislav Petkov, Dan Williams, Dave Hansen,
David Woodhouse, Josh Poimboeuf, Linus Torvalds, Peter Zijlstra,
Thomas Gleixner, arjan.van.de.ven, jmattson, karahmed, kvm,
pbonzini, rkrcmar, sironi, Ingo Molnar, Srivatsa S. Bhat,
"Matt Helsley (VMware)" <matt
In-Reply-To: <20180723122413.003644357@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Woodhouse <dwmw@amazon.co.uk>
commit 1751342095f0d2b36fa8114d8e12c5688c455ac4 upstream.
Intel have retroactively blessed the 0xc2 microcode on Skylake mobile
and desktop parts, and the Gemini Lake 0x22 microcode is apparently fine
too. We blacklisted the latter purely because it was present with all
the other problematic ones in the 2018-01-08 release, but now it's
explicitly listed as OK.
We still list 0x84 for the various Kaby Lake / Coffee Lake parts, as
that appeared in one version of the blacklist and then reverted to
0x80 again. We can change it if 0x84 is actually announced to be safe.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan.van.de.ven@intel.com
Cc: jmattson@google.com
Cc: karahmed@amazon.de
Cc: kvm@vger.kernel.org
Cc: pbonzini@redhat.com
Cc: rkrcmar@redhat.com
Cc: sironi@amazon.de
Link: http://lkml.kernel.org/r/1518305967-31356-2-git-send-email-dwmw@amazon.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Srivatsa S. Bhat <srivatsa@csail.mit.edu>
Reviewed-by: Matt Helsley (VMware) <matt.helsley@gmail.com>
Reviewed-by: Alexey Makhalov <amakhalov@vmware.com>
Reviewed-by: Bo Gan <ganb@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/intel.c | 4 ----
1 file changed, 4 deletions(-)
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -47,8 +47,6 @@ static const struct sku_microcode spectr
{ INTEL_FAM6_KABYLAKE_MOBILE, 0x09, 0x84 },
{ INTEL_FAM6_SKYLAKE_X, 0x03, 0x0100013e },
{ INTEL_FAM6_SKYLAKE_X, 0x04, 0x0200003c },
- { INTEL_FAM6_SKYLAKE_MOBILE, 0x03, 0xc2 },
- { INTEL_FAM6_SKYLAKE_DESKTOP, 0x03, 0xc2 },
{ INTEL_FAM6_BROADWELL_CORE, 0x04, 0x28 },
{ INTEL_FAM6_BROADWELL_GT3E, 0x01, 0x1b },
{ INTEL_FAM6_BROADWELL_XEON_D, 0x02, 0x14 },
@@ -60,8 +58,6 @@ static const struct sku_microcode spectr
{ INTEL_FAM6_HASWELL_X, 0x02, 0x3b },
{ INTEL_FAM6_HASWELL_X, 0x04, 0x10 },
{ INTEL_FAM6_IVYBRIDGE_X, 0x04, 0x42a },
- /* Updated in the 20180108 release; blacklist until we know otherwise */
- { INTEL_FAM6_ATOM_GEMINI_LAKE, 0x01, 0x22 },
/* Observed in the wild */
{ INTEL_FAM6_SANDYBRIDGE_X, 0x06, 0x61b },
{ INTEL_FAM6_SANDYBRIDGE_X, 0x07, 0x712 },
^ permalink raw reply
* [PATCH 4.4 018/107] x86/paravirt: Make native_save_fl() extern inline
From: Greg Kroah-Hartman @ 2018-07-23 12:41 UTC (permalink / raw)
To: linux-kernel
Cc: andrea.parri, kstewart, linux-efi, brijesh.singh, Peter Zijlstra,
jan.kiszka, will.deacon, jarkko.sakkinen, virtualization,
yamada.masahiro, manojgupta, H. Peter Anvin, Thomas Gleixner,
tweek, mawilcox, akataria, ghackmann, Ingo Molnar, mjg59, mka,
geert, rientjes, aryabinin, thomas.lendacky, Arnd Bergmann,
linux-kbuild, pombredanne, rostedt, acme, caoj.fnst, jpoimboe,
Sedat Dilek, boris.ostrovsky
In-Reply-To: <20180723122413.003644357@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nick Desaulniers <ndesaulniers@google.com>
commit d0a8d9378d16eb3c69bd8e6d23779fbdbee3a8c7 upstream.
native_save_fl() is marked static inline, but by using it as
a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.
paravirt's use of native_save_fl() also requires that no GPRs other than
%rax are clobbered.
Compilers have different heuristics which they use to emit stack guard
code, the emittance of which can break paravirt's callee saved assumption
by clobbering %rcx.
Marking a function definition extern inline means that if this version
cannot be inlined, then the out-of-line version will be preferred. By
having the out-of-line version be implemented in assembly, it cannot be
instrumented with a stack protector, which might violate custom calling
conventions that code like paravirt rely on.
The semantics of extern inline has changed since gnu89. This means that
folks using GCC versions >= 5.1 may see symbol redefinition errors at
link time for subdirs that override KBUILD_CFLAGS (making the C standard
used implicit) regardless of this patch. This has been cleaned up
earlier in the patch set, but is left as a note in the commit message
for future travelers.
Reports:
https://lkml.org/lkml/2018/5/7/534
https://github.com/ClangBuiltLinux/linux/issues/16
Discussion:
https://bugs.llvm.org/show_bug.cgi?id=37512
https://lkml.org/lkml/2018/5/24/1371
Thanks to the many folks that participated in the discussion.
[Backport for 4.4. 4.4 is missing commit 784d5699eddc "x86: move exports to
actual definitions" which doesn't apply cleanly, and not really worth
backporting IMO. It's simpler to change this patch from upstream:
+ #include <asm-generic/export.h>
rather than
+ #include <asm/export.h>]
Debugged-by: Alistair Strachan <astrachan@google.com>
Debugged-by: Matthias Kaehlcke <mka@chromium.org>
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: H. Peter Anvin <hpa@zytor.com>
Suggested-by: Tom Stellar <tstellar@redhat.com>
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: acme@redhat.com
Cc: akataria@vmware.com
Cc: akpm@linux-foundation.org
Cc: andrea.parri@amarulasolutions.com
Cc: ard.biesheuvel@linaro.org
Cc: aryabinin@virtuozzo.com
Cc: astrachan@google.com
Cc: boris.ostrovsky@oracle.com
Cc: brijesh.singh@amd.com
Cc: caoj.fnst@cn.fujitsu.com
Cc: geert@linux-m68k.org
Cc: ghackmann@google.com
Cc: gregkh@linuxfoundation.org
Cc: jan.kiszka@siemens.com
Cc: jarkko.sakkinen@linux.intel.com
Cc: joe@perches.com
Cc: jpoimboe@redhat.com
Cc: keescook@google.com
Cc: kirill.shutemov@linux.intel.com
Cc: kstewart@linuxfoundation.org
Cc: linux-efi@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Cc: manojgupta@google.com
Cc: mawilcox@microsoft.com
Cc: michal.lkml@markovi.net
Cc: mjg59@google.com
Cc: mka@chromium.org
Cc: pombredanne@nexb.com
Cc: rientjes@google.com
Cc: rostedt@goodmis.org
Cc: thomas.lendacky@amd.com
Cc: tweek@google.com
Cc: virtualization@lists.linux-foundation.org
Cc: will.deacon@arm.com
Cc: yamada.masahiro@socionext.com
Link: http://lkml.kernel.org/r/20180621162324.36656-4-ndesaulniers@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/irqflags.h | 2 +-
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/irqflags.S | 26 ++++++++++++++++++++++++++
3 files changed, 28 insertions(+), 1 deletion(-)
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -8,7 +8,7 @@
* Interrupt control:
*/
-static inline unsigned long native_save_fl(void)
+extern inline unsigned long native_save_fl(void)
{
unsigned long flags;
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -41,6 +41,7 @@ obj-y += alternative.o i8253.o pci-nom
obj-y += tsc.o tsc_msr.o io_delay.o rtc.o
obj-y += pci-iommu_table.o
obj-y += resource.o
+obj-y += irqflags.o
obj-y += process.o
obj-y += fpu/
--- /dev/null
+++ b/arch/x86/kernel/irqflags.S
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include <asm/asm.h>
+#include <asm-generic/export.h>
+#include <linux/linkage.h>
+
+/*
+ * unsigned long native_save_fl(void)
+ */
+ENTRY(native_save_fl)
+ pushf
+ pop %_ASM_AX
+ ret
+ENDPROC(native_save_fl)
+EXPORT_SYMBOL(native_save_fl)
+
+/*
+ * void native_restore_fl(unsigned long flags)
+ * %eax/%rdi: flags
+ */
+ENTRY(native_restore_fl)
+ push %_ASM_ARG1
+ popf
+ ret
+ENDPROC(native_restore_fl)
+EXPORT_SYMBOL(native_restore_fl)
^ permalink raw reply
* [PATCH v2 1/3] Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"
From: Leonard Crestez @ 2018-07-23 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHQ1cqF6TphuN8Ls54YA6bjty-bJF8twYboaG-RM=jox8CeQPA@mail.gmail.com>
On Fri, 2018-07-20 at 08:33 -0700, Andrey Smirnov wrote:
> On Fri, Jul 20, 2018 at 5:48 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
> >
> > This reverts commit 1c86c9dd82f859b474474a7fee0d5195da2c9c1d.
> >
> > That commit followed the reference manual but unfortunately the imx7d
> > manual is incorrect.
>
> I'd also add similar comment to DT file to prevent people from trying
> to "fix" this in the future.
I'll try to see if I can follow up internally with docs team to get
this updated in the next revision of the reference manual.
> Also, this change is going to break QEMU's mapping found here:
I had no idea that existed, I guess somebody needs to fix that as well.
Do you have an imx7d board using pci or did you just test in emulation?
--
Regards,
Leonard
^ permalink raw reply
* Re: [PATCH v2 1/3] Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"
From: Leonard Crestez @ 2018-07-23 12:41 UTC (permalink / raw)
To: andrew.smirnov@gmail.com
Cc: Richard Zhu, linux-kernel@vger.kernel.org, A.s. Dong,
jingoohan1@gmail.com, dl-linux-imx, lorenzo.pieralisi@arm.com,
linux-pm@vger.kernel.org, Fabio Estevam, Joao.Pinto@synopsys.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org,
bhelgaas@google.com, l.stach@pengutronix.de,
kernel@pengutronix.de, linux-pci@vger.kernel.org
In-Reply-To: <CAHQ1cqF6TphuN8Ls54YA6bjty-bJF8twYboaG-RM=jox8CeQPA@mail.gmail.com>
On Fri, 2018-07-20 at 08:33 -0700, Andrey Smirnov wrote:
> On Fri, Jul 20, 2018 at 5:48 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
> >
> > This reverts commit 1c86c9dd82f859b474474a7fee0d5195da2c9c1d.
> >
> > That commit followed the reference manual but unfortunately the imx7d
> > manual is incorrect.
>
> I'd also add similar comment to DT file to prevent people from trying
> to "fix" this in the future.
I'll try to see if I can follow up internally with docs team to get
this updated in the next revision of the reference manual.
> Also, this change is going to break QEMU's mapping found here:
I had no idea that existed, I guess somebody needs to fix that as well.
Do you have an imx7d board using pci or did you just test in emulation?
--
Regards,
Leonard
^ permalink raw reply
* Re: [PATCH v2 1/3] Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"
From: Leonard Crestez @ 2018-07-23 12:41 UTC (permalink / raw)
To: andrew.smirnov@gmail.com
Cc: A.s. Dong, lorenzo.pieralisi@arm.com, Richard Zhu,
linux-pm@vger.kernel.org, jingoohan1@gmail.com,
linux-kernel@vger.kernel.org, bhelgaas@google.com,
Joao.Pinto@synopsys.com, dl-linux-imx, kernel@pengutronix.de,
linux-pci@vger.kernel.org, Fabio Estevam, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org, l.stach@pengutronix.de
In-Reply-To: <CAHQ1cqF6TphuN8Ls54YA6bjty-bJF8twYboaG-RM=jox8CeQPA@mail.gmail.com>
On Fri, 2018-07-20 at 08:33 -0700, Andrey Smirnov wrote:
> On Fri, Jul 20, 2018 at 5:48 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
> >
> > This reverts commit 1c86c9dd82f859b474474a7fee0d5195da2c9c1d.
> >
> > That commit followed the reference manual but unfortunately the imx7d
> > manual is incorrect.
>
> I'd also add similar comment to DT file to prevent people from trying
> to "fix" this in the future.
I'll try to see if I can follow up internally with docs team to get
this updated in the next revision of the reference manual.
> Also, this change is going to break QEMU's mapping found here:
I had no idea that existed, I guess somebody needs to fix that as well.
Do you have an imx7d board using pci or did you just test in emulation?
--
Regards,
Leonard
_______________________________________________
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 v4 02/20] virtio: pci-legacy: Validate queue pfn
From: Marc Zyngier @ 2018-07-23 12:54 UTC (permalink / raw)
To: Suzuki K Poulose, Michael S. Tsirkin
Cc: cdall, kvm, catalin.marinas, Jason Wang, will.deacon, dave.martin,
pbonzini, kvmarm, linux-arm-kernel
In-Reply-To: <5a659490-13ce-87c1-a9bc-d89a8f8ee111@arm.com>
On 23/07/18 10:44, Suzuki K Poulose wrote:
> On 07/22/2018 04:53 PM, Michael S. Tsirkin wrote:
>> On Wed, Jul 18, 2018 at 10:18:45AM +0100, Suzuki K Poulose wrote:
>>> Legacy PCI over virtio uses a 32bit PFN for the queue. If the
>>> queue pfn is too large to fit in 32bits, which we could hit on
>>> arm64 systems with 52bit physical addresses (even with 64K page
>>> size), we simply miss out a proper link to the other side of
>>> the queue.
>>>
>>> Add a check to validate the PFN, rather than silently breaking
>>> the devices.
>>>
>>> Cc: "Michael S. Tsirkin" <mst@redhat.com>
>>> Cc: Jason Wang <jasowang@redhat.com>
>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>> Cc: Christoffer Dall <cdall@kernel.org>
>>> Cc: Peter Maydel <peter.maydell@linaro.org>
>>> Cc: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>
>> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
>
> Michael,
>
> Thanks.
>
>>
>> I assume this will be merged through some other tree.
>>
>
>
> As such these two virtio patches do not have any code dependencies with
> the rest of the series. So, if you could pick this up it should be fine.
> Otherwise, may be Marc can push it with the rest of the series.
>
> Marc,
>
> Are you OK with that ?
Given that these two patches completely independent, I think their
natural path should be the virtio tree. But if Michael doesn't want to
pick them, I'll do it as part of this series.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [4.4,002/107] x86/MCE: Remove min interval polling limitation
From: Greg Kroah-Hartman @ 2018-07-23 12:40 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dewet Thibaut, Alexander Sverdlin,
Borislav Petkov, Thomas Gleixner, Tony Luck, linux-edac
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dewet Thibaut <thibaut.dewet@nokia.com>
commit fbdb328c6bae0a7c78d75734a738b66b86dffc96 upstream.
commit b3b7c4795c ("x86/MCE: Serialize sysfs changes") introduced a min
interval limitation when setting the check interval for polled MCEs.
However, the logic is that 0 disables polling for corrected MCEs, see
Documentation/x86/x86_64/machinecheck. The limitation prevents disabling.
Remove this limitation and allow the value 0 to disable polling again.
Fixes: b3b7c4795c ("x86/MCE: Serialize sysfs changes")
Signed-off-by: Dewet Thibaut <thibaut.dewet@nokia.com>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
[ Massage commit message. ]
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20180716084927.24869-1-alexander.sverdlin@nokia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/mcheck/mce.c | 3 ---
1 file changed, 3 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-edac" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -2294,9 +2294,6 @@ static ssize_t store_int_with_restart(st
if (check_interval == old_check_interval)
return ret;
- if (check_interval < 1)
- check_interval = 1;
-
mutex_lock(&mce_sysfs_mutex);
mce_restart();
mutex_unlock(&mce_sysfs_mutex);
^ permalink raw reply
* Re: Hash algorithm analysis
From: demerphq @ 2018-07-23 12:40 UTC (permalink / raw)
To: brian m. carlson, Johannes Schindelin, Jonathan Nieder, Git,
Linus Torvalds, agl, keccak
In-Reply-To: <20180721235941.GG18502@genre.crustytoothpaste.net>
On Sun, 22 Jul 2018 at 01:59, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> I will admit that I don't love making this decision by myself, because
> right now, whatever I pick, somebody is going to be unhappy. I want to
> state, unambiguously, that I'm trying to make a decision that is in the
> interests of the Git Project, the community, and our users.
>
> I'm happy to wait a few more days to see if a consensus develops; if so,
> I'll follow it. If we haven't come to one by, say, Wednesday, I'll make
> a decision and write my patches accordingly. The community is free, as
> always, to reject my patches if taking them is not in the interest of
> the project.
Hi Brian.
I do not envy you this decision.
Personally I would aim towards pushing this decision out to the git
user base and facilitating things so we can choose whatever hash
function (and config) we wish, including ones not invented yet.
Failing that I would aim towards a hashing strategy which has the most
flexibility. Keccak for instance has the interesting property that its
security level is tunable, and that it can produce aribitrarily long
hashes. Leaving aside other concerns raised elsewhere in this thread,
these two features alone seem to make it a superior choice for an
initial implementation. You can find bugs by selecting unusual hash
sizes, including very long ones, and you can provide ways to tune the
function to peoples security and speed preferences. Someone really
paranoid can specify an unusually large round count and a very long
hash.
Also frankly I keep thinking that the ability to arbitrarily extend
the hash size has to be useful /somewhere/ in git.
cheers,
Yves
I am not a cryptographer.
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [PATCH] oe-selftest: fix for changes to buildhistory-diff
From: Paul Eggleton @ 2018-07-23 12:40 UTC (permalink / raw)
To: openembedded-core
Now we're not reporting the related fields (as of openembedded-core
8658b3677b9f7cb70806061c41570c709086ef05) we shouldn't expect to see
PR reported here since it's not monitored by buildhistory-diff. However,
with a bit of messing about we can check for the exact output that we
should now see as a result of the test changing PR to go backwards.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/lib/oeqa/selftest/cases/oescripts.py | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/oescripts.py b/meta/lib/oeqa/selftest/cases/oescripts.py
index 1ee753763ec..bcdc2d5ac07 100644
--- a/meta/lib/oeqa/selftest/cases/oescripts.py
+++ b/meta/lib/oeqa/selftest/cases/oescripts.py
@@ -10,6 +10,19 @@ class BuildhistoryDiffTests(BuildhistoryBase):
target = 'xcursor-transparent-theme'
self.run_buildhistory_operation(target, target_config="PR = \"r1\"", change_bh_location=True)
self.run_buildhistory_operation(target, target_config="PR = \"r0\"", change_bh_location=False, expect_error=True)
+ result = runCmd("oe-pkgdata-util read-value PKGV %s" % target)
+ pkgv = result.output.rstrip()
result = runCmd("buildhistory-diff -p %s" % get_bb_var('BUILDHISTORY_DIR'))
- expected_output = 'PR changed from "r1" to "r0"'
- self.assertTrue(expected_output in result.output, msg="Did not find expected output: %s" % result.output)
+ expected_endlines = [
+ "xcursor-transparent-theme-dev: RDEPENDS: removed \"xcursor-transparent-theme (['= %s-r1'])\", added \"xcursor-transparent-theme (['= %s-r0'])\"" % (pkgv, pkgv),
+ "xcursor-transparent-theme-staticdev: RDEPENDS: removed \"xcursor-transparent-theme-dev (['= %s-r1'])\", added \"xcursor-transparent-theme-dev (['= %s-r0'])\"" % (pkgv, pkgv)
+ ]
+ for line in result.output.splitlines():
+ for el in expected_endlines:
+ if line.endswith(el):
+ expected_endlines.remove(el)
+ break
+ else:
+ self.fail('Unexpected line:\n%s\nExpected line endings:\n %s' % (line, '\n '.join(expected_endlines)))
+ if expected_endlines:
+ self.fail('Missing expected line endings:\n %s' % '\n '.join(expected_endlines))
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] [RESEND] firewire: ohci: stop using get_seconds() for BUS_TIME
From: Stefan Richter @ 2018-07-23 12:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: y2038, Clemens Ladisch, Ingo Molnar, Paul E. McKenney,
Mark Rutland, Hector Martin, linux1394-devel, linux-kernel
In-Reply-To: <20180711124923.1205200-1-arnd@arndb.de>
On Jul 11 Arnd Bergmann wrote:
> The ohci driver uses the get_seconds() function to implement the 32-bit
> CSR_BUS_TIME register. This was added in 2010 commit a48777e03ad5
> ("firewire: add CSR BUS_TIME support").
>
> As get_seconds() returns a 32-bit value (on 32-bit architectures), it
> seems like a good fit for that register, but it is also deprecated because
> of the y2038/y2106 overflow problem, and should be replaced throughout
> the kernel with either ktime_get_real_seconds() or ktime_get_seconds().
>
> I'm using the latter here, which uses monotonic time. This has the
> advantage of behaving better during concurrent settimeofday() updates
> or leap second adjustments and won't overflow a 32-bit integer, but
> the downside of using CLOCK_MONOTONIC instead of CLOCK_REALTIME is
> that the observed values are not related to external clocks.
>
> If we instead need UTC but can live with clock jumps or overflows,
> then we should use ktime_get_real_seconds() instead, retaining the
> existing behavior.
>
> Reviewed-by: Clemens Ladisch <clemens@ladisch.de>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> I notice that Stefan Richter has not been active on the mailing lists
> since February 2018.
Thanks Arnd and Clemens.
I resurrected and updated one of my FireWire enabled PCs, and try to get
pack to reasonable response times to firewire driver patches.
The switch from CLOCK_REALTIME to CLOCK_MONOTONIC looks good to me, but
I'll have another look at the context.
> Andrew, could you pick it up in the meantime?
> ---
> drivers/firewire/ohci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
> index 45c048751f3b..5125841ea338 100644
> --- a/drivers/firewire/ohci.c
> +++ b/drivers/firewire/ohci.c
> @@ -1765,7 +1765,7 @@ static u32 update_bus_time(struct fw_ohci *ohci)
>
> if (unlikely(!ohci->bus_time_running)) {
> reg_write(ohci, OHCI1394_IntMaskSet, OHCI1394_cycle64Seconds);
> - ohci->bus_time = (lower_32_bits(get_seconds()) & ~0x7f) |
> + ohci->bus_time = (lower_32_bits(ktime_get_seconds()) & ~0x7f) |
> (cycle_time_seconds & 0x40);
> ohci->bus_time_running = true;
> }
--
Stefan Richter
-======---=- -=== =-===
http://arcgraph.de/sr/
^ permalink raw reply
* [PATCH/RFT 2/7] ASoC: rsnd: Document R-Car M3-N support
From: Yoshihiro Kaneko @ 2018-07-23 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r2jy4yfl.wl-kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
Thank you for your review.
I will exclude this patch from the series and repost this as a single
patch to ALSA SoC ML.
Best regards,
Kaneko
2018-07-20 8:12 GMT+09:00 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
>
> Hi
>
> Thnak you for your patch
>
>> From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
>>
>> Document support for the sound modules in the Renesas M3-N (r8a77965)
>> SoC.
>>
>> No driver update is needed.
>>
>> Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
>> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>> ---
>
> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> But, I think this patch should go to ALSA SoC ML.
>
>
>> Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
>> index b86d790..9e764270 100644
>> --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
>> +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
>> @@ -352,6 +352,7 @@ Required properties:
>> - "renesas,rcar_sound-r8a7794" (R-Car E2)
>> - "renesas,rcar_sound-r8a7795" (R-Car H3)
>> - "renesas,rcar_sound-r8a7796" (R-Car M3-W)
>> + - "renesas,rcar_sound-r8a77965" (R-Car M3-N)
>> - reg : Should contain the register physical address.
>> required register is
>> SRU/ADG/SSI if generation1
>> --
>> 1.9.1
>>
^ permalink raw reply
* Re: [PATCH v4 00/26] arm64: provide pseudo NMI with GICv3
From: Julien Thierry @ 2018-07-23 12:39 UTC (permalink / raw)
To: Daniel Thompson
Cc: linux-arm-kernel, linux-kernel, joel, marc.zyngier, mark.rutland,
christoffer.dall, james.morse, catalin.marinas, will.deacon
In-Reply-To: <20180720150943.i4u2s7wie7falh7p@holly.lan>
Hi Daniel,
On 20/07/18 16:09, Daniel Thompson wrote:
> On Fri, May 25, 2018 at 10:49:06AM +0100, Julien Thierry wrote:
>> This series is a continuation of the work started by Daniel [1]. The goal
>> is to use GICv3 interrupt priorities to simulate an NMI.
>>
>> To achieve this, set two priorities, one for standard interrupts and
>> another, higher priority, for NMIs. Whenever we want to disable interrupts,
>> we mask the standard priority instead so NMIs can still be raised. Some
>> corner cases though still require to actually mask all interrupts
>> effectively disabling the NMI.
>>
>> Currently, only PPIs and SPIs can be set as NMIs. IPIs being currently
>> hardcoded IRQ numbers, there isn't a generic interface to set SGIs as NMI
>> for now. I don't think there is any reason LPIs should be allowed to be set
>> as NMI as they do not have an active state.
>> When an NMI is active on a CPU, no other NMI can be triggered on the CPU.
>>
>> After the big refactoring I get performances similar to the ones I had
>> in v3[2], reposting old results here:
>>
>> - "hackbench 200 process 1000" (average over 20 runs)
>> +-----------+----------+------------+------------------+
>> | | native | PMR guest | v4.17-rc6 guest |
>> +-----------+----------+------------+------------------+
>> | PMR host | 40.0336s | 39.3039s | 39.2044s |
>> | v4.17-rc6 | 40.4040s | 39.6011s | 39.1147s |
>> +-----------+----------+------------+------------------+
>>
>> - Kernel build from defconfig:
>> PMR host: 13m45.743s
>> v4.17-rc6: 13m40.400s
>>
>> I'll try to post more detailed benchmarks later if I find notable
>> differences with the previous version.
>
> So... I'm rather late sharing these benchmarks but...
>
> I ran some kernel build benchmarks on the Developerbox from 96Boards
> (aka Synquacer E-series by Socionext): 24 C-A53 cores running at 1GHz.
> This is obviously a real workload and one that anything called
> Developerbox needs to care about!
>
> The difference in performance is slight but PMR based locking is
> marginally slower than using the I-bit. It varies with the
> parrallel-ness of the build slightly but the slowdown on this platform
> is between 0.2% and 0.6% [1].
>
> This delta was sufficiently small that I was willing to leave the PMR
> masking in place for a fair amount of my day to day work. On that basis
> these patches could also be described as:
>
> Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
>
Thanks very much for doing this testing. Things have changed a bit in
the NMI side of the series and I am trying to get a saner API to get
upstreamed before posting a new version of these patches. But the PMR
masking/unmasking remains the same so the benchmarks should still be
valid in the future version.
Thanks,
>
> Daniel.
>
>
> [1] For anyone interested in the raw numbers then the spreadsheet where
> I checked the results is here:
> https://docs.google.com/spreadsheets/d/1gGxAJd_gL-HjeTF-x0Ut5lWT4JULNRDeTbPvPInZ4H4/edit?usp=sharing
>
--
Julien Thierry
^ permalink raw reply
* [PATCH v4 00/26] arm64: provide pseudo NMI with GICv3
From: Julien Thierry @ 2018-07-23 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180720150943.i4u2s7wie7falh7p@holly.lan>
Hi Daniel,
On 20/07/18 16:09, Daniel Thompson wrote:
> On Fri, May 25, 2018 at 10:49:06AM +0100, Julien Thierry wrote:
>> This series is a continuation of the work started by Daniel [1]. The goal
>> is to use GICv3 interrupt priorities to simulate an NMI.
>>
>> To achieve this, set two priorities, one for standard interrupts and
>> another, higher priority, for NMIs. Whenever we want to disable interrupts,
>> we mask the standard priority instead so NMIs can still be raised. Some
>> corner cases though still require to actually mask all interrupts
>> effectively disabling the NMI.
>>
>> Currently, only PPIs and SPIs can be set as NMIs. IPIs being currently
>> hardcoded IRQ numbers, there isn't a generic interface to set SGIs as NMI
>> for now. I don't think there is any reason LPIs should be allowed to be set
>> as NMI as they do not have an active state.
>> When an NMI is active on a CPU, no other NMI can be triggered on the CPU.
>>
>> After the big refactoring I get performances similar to the ones I had
>> in v3[2], reposting old results here:
>>
>> - "hackbench 200 process 1000" (average over 20 runs)
>> +-----------+----------+------------+------------------+
>> | | native | PMR guest | v4.17-rc6 guest |
>> +-----------+----------+------------+------------------+
>> | PMR host | 40.0336s | 39.3039s | 39.2044s |
>> | v4.17-rc6 | 40.4040s | 39.6011s | 39.1147s |
>> +-----------+----------+------------+------------------+
>>
>> - Kernel build from defconfig:
>> PMR host: 13m45.743s
>> v4.17-rc6: 13m40.400s
>>
>> I'll try to post more detailed benchmarks later if I find notable
>> differences with the previous version.
>
> So... I'm rather late sharing these benchmarks but...
>
> I ran some kernel build benchmarks on the Developerbox from 96Boards
> (aka Synquacer E-series by Socionext): 24 C-A53 cores running at 1GHz.
> This is obviously a real workload and one that anything called
> Developerbox needs to care about!
>
> The difference in performance is slight but PMR based locking is
> marginally slower than using the I-bit. It varies with the
> parrallel-ness of the build slightly but the slowdown on this platform
> is between 0.2% and 0.6% [1].
>
> This delta was sufficiently small that I was willing to leave the PMR
> masking in place for a fair amount of my day to day work. On that basis
> these patches could also be described as:
>
> Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
>
Thanks very much for doing this testing. Things have changed a bit in
the NMI side of the series and I am trying to get a saner API to get
upstreamed before posting a new version of these patches. But the PMR
masking/unmasking remains the same so the benchmarks should still be
valid in the future version.
Thanks,
>
> Daniel.
>
>
> [1] For anyone interested in the raw numbers then the spreadsheet where
> I checked the results is here:
> https://docs.google.com/spreadsheets/d/1gGxAJd_gL-HjeTF-x0Ut5lWT4JULNRDeTbPvPInZ4H4/edit?usp=sharing
>
--
Julien Thierry
^ permalink raw reply
* Re: [PATCH v3 0/6] *** Add support for wifi QMI client handshakes ***
From: Govind Singh @ 2018-07-23 12:38 UTC (permalink / raw)
To: Niklas Cassel
Cc: andy.gross, david.brown, linux-wireless, ath10k, bjorn.andersson
In-Reply-To: <20180719175105.GA2633@centauri.lan>
Hi Niklas,
Thanks for the review.
On 2018-07-19 23:21, Niklas Cassel wrote:
> On Fri, Jul 06, 2018 at 02:26:17PM +0530, Govind Singh wrote:
>> Add QMI client handshakes for Q6 integrated WLAN connectivity
>> subsystem.
>> This module is responsible for communicating WLAN control messages to
>> FW
>> over QMI interface. This patch series enables the qmi handshakes
>> required for
>> WCN3990 chipset.
>
> (cut)
>
> Hello Govind,
>
> I ran make W=1, sparse, and checkpatch on your new iteration of
> patches.
> (I didn't do a full manual review this time, since I did that last
> time.)
>
> Building with warnings and checkpatch looks good,
> but sparse reports the two following warnings:
>
> CHECK drivers/net/wireless/ath/ath10k//qmi.c
> drivers/net/wireless/ath/ath10k//qmi.c:935:29: warning: incorrect type
> in assignment (different address spaces)
> drivers/net/wireless/ath/ath10k//qmi.c:935:29: expected void *msa_va
> drivers/net/wireless/ath/ath10k//qmi.c:935:29: got void [noderef]
> <asn:2>*
>
Fixed in v4 version.
> and
>
> drivers/net/wireless/ath/ath10k//snoc.c:76:22: warning: incorrect type
> in initializer (different base types)
> drivers/net/wireless/ath/ath10k//snoc.c:76:22: expected restricted
> __le16 [usertype] reg_offset
> drivers/net/wireless/ath/ath10k//snoc.c:76:22: got int
> drivers/net/wireless/ath/ath10k//snoc.c:77:19: warning: incorrect type
> in initializer (different base types)
> drivers/net/wireless/ath/ath10k//snoc.c:77:19: expected restricted
> __le16 [usertype] ce_id
> drivers/net/wireless/ath/ath10k//snoc.c:77:19: got int
> drivers/net/wireless/ath/ath10k//snoc.c:77:22: warning: incorrect type
> in initializer (different base types)
> drivers/net/wireless/ath/ath10k//snoc.c:77:22: expected restricted
> __le16 [usertype] reg_offset
> drivers/net/wireless/ath/ath10k//snoc.c:77:22: got int
> drivers/net/wireless/ath/ath10k//snoc.c:78:19: warning: incorrect type
> in initializer (different base types)
> drivers/net/wireless/ath/ath10k//snoc.c:78:19: expected restricted
Fixed in v4 version.
Thanks,
Govind
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* [Qemu-arm] [PATCH] target/arm: Escalate to correct HardFault when AIRCR.BFHFNMINS is set
From: Peter Maydell @ 2018-07-23 12:34 UTC (permalink / raw)
To: qemu-arm, qemu-devel; +Cc: patches
When we escalate a v8M exception to HardFault, if AIRCR.BFHFNMINNS is
set then we need to decide whether it should become a secure HardFault
or a nonsecure HardFault. We should always escalate to the same
target security state as the original exception. The current code
tries to test this using the 'secure' bool, which is not right because
that flag indicates whether the target security state only for
banked exceptions; the effect was that we were incorrectly escalating
always-secure exceptions like SecureFault to a nonsecure HardFault.
Fix this by defining, logging and using a new 'targets_secure' bool
which tracks the condition we actually want.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/intc/armv7m_nvic.c | 8 ++++++--
hw/intc/trace-events | 2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
index bf92fe0972c..e160b02eab4 100644
--- a/hw/intc/armv7m_nvic.c
+++ b/hw/intc/armv7m_nvic.c
@@ -529,13 +529,17 @@ static void do_armv7m_nvic_set_pending(void *opaque, int irq, bool secure,
NVICState *s = (NVICState *)opaque;
bool banked = exc_is_banked(irq);
VecInfo *vec;
+ bool targets_secure;
assert(irq > ARMV7M_EXCP_RESET && irq < s->num_irq);
assert(!secure || banked);
vec = (banked && secure) ? &s->sec_vectors[irq] : &s->vectors[irq];
- trace_nvic_set_pending(irq, secure, derived, vec->enabled, vec->prio);
+ targets_secure = banked ? secure : exc_targets_secure(s, irq);
+
+ trace_nvic_set_pending(irq, secure, targets_secure,
+ derived, vec->enabled, vec->prio);
if (derived) {
/* Derived exceptions are always synchronous. */
@@ -615,7 +619,7 @@ static void do_armv7m_nvic_set_pending(void *opaque, int irq, bool secure,
*/
irq = ARMV7M_EXCP_HARD;
if (arm_feature(&s->cpu->env, ARM_FEATURE_M_SECURITY) &&
- (secure ||
+ (targets_secure ||
!(s->cpu->env.v7m.aircr & R_V7M_AIRCR_BFHFNMINS_MASK))) {
vec = &s->sec_vectors[irq];
} else {
diff --git a/hw/intc/trace-events b/hw/intc/trace-events
index b6cb5e6048d..33e932fb918 100644
--- a/hw/intc/trace-events
+++ b/hw/intc/trace-events
@@ -177,7 +177,7 @@ nvic_set_prio(int irq, bool secure, uint8_t prio) "NVIC set irq %d secure-bank %
nvic_irq_update(int vectpending, int pendprio, int exception_prio, int level) "NVIC vectpending %d pending prio %d exception_prio %d: setting irq line to %d"
nvic_escalate_prio(int irq, int irqprio, int runprio) "NVIC escalating irq %d to HardFault: insufficient priority %d >= %d"
nvic_escalate_disabled(int irq) "NVIC escalating irq %d to HardFault: disabled"
-nvic_set_pending(int irq, bool secure, bool derived, int en, int prio) "NVIC set pending irq %d secure-bank %d derived %d (enabled: %d priority %d)"
+nvic_set_pending(int irq, bool secure, bool targets_secure, bool derived, int en, int prio) "NVIC set pending irq %d secure-bank %d targets_secure %d derived %d (enabled: %d priority %d)"
nvic_clear_pending(int irq, bool secure, int en, int prio) "NVIC clear pending irq %d secure-bank %d (enabled: %d priority %d)"
nvic_set_pending_level(int irq) "NVIC set pending: irq %d higher prio than vectpending: setting irq line to 1"
nvic_acknowledge_irq(int irq, int prio) "NVIC acknowledge IRQ: %d now active (prio %d)"
--
2.17.1
^ permalink raw reply related
* Re: [RFC 1/2] x86/entry/64: Use the TSS sp2 slot for rsp_scratch
From: Dave Hansen @ 2018-07-23 12:38 UTC (permalink / raw)
To: Andy Lutomirski, x86, LKML; +Cc: Borislav Petkov, Linus Torvalds
In-Reply-To: <38b5a24f3c9f519dd7dc98171eb3a3c669fff48c.1532281180.git.luto@kernel.org>
On 07/22/2018 10:45 AM, Andy Lutomirski wrote:
> + /*
> + * sp2 is scratch space used by the SYSCALL64 handler. Linux does
> + * not use rung 2, so sp2 is not otherwise needed.
> + */
> u64 sp2;
Could we call out the actual thing that we use this slot for, and the
symbol name so folks can find the corresponding code that does this?
While I know the spot in entry_64 you're talking about, it might not be
patently obvious to everyone, and it's also a bit more challenging to
grep for than normal C code.
Maybe:
/*
* Since Linux does not use ring 2, the 'sp2' slot is unused.
* entry_SYSCALL_64 uses this as scratch space to stash the user
* %RSP value.
*/
^ permalink raw reply
* Re: [PATCH 6/8] clk: tegra30: add 2d and 3d idle clocks
From: Ben Dooks @ 2018-07-23 11:37 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: pdeschrijver, jonathanh, thierry.reding, linux-clk, linux-tegra,
linux-kernel, pgaikwad, linux-kernel
In-Reply-To: <22870833.4JC6Is3odW@dimapc>
On 2018-07-23 12:33, Dmitry Osipenko wrote:
> On Monday, 23 July 2018 11:28:25 MSK Ben Dooks wrote:
>> On 2018-07-22 12:55, Dmitry Osipenko wrote:
>> > On Friday, 20 July 2018 16:45:30 MSK Ben Dooks wrote:
>> >> The 2D and 3D clocks have an IDLE field in bits 15:8 so add these
>> >> clocks by making a 2D and 3D mux, and split the divider into the
>> >> standard 2D/3D ones and 2D/3D idle clocks.
>> >>
>> >> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>
>> [snip]
>
>> @@ -658,8 +658,12 @@ static struct tegra_devclk devclks[] __initdata =
>> {
>> { .dev_id = "mpe", .dt_id = TEGRA30_CLK_MPE },
>> { .dev_id = "host1x", .dt_id = TEGRA30_CLK_HOST1X },
>> { .dev_id = "3d", .dt_id = TEGRA30_CLK_GR3D },
>> + { .dev_id = "3d", .con_id = "mux", .dt_id = TEGRA30_CLK_GR3D_MUX },
>> + { .dev_id = "3d", .con_id = "idle", .dt_id = TEGRA30_CLK_GR3D_IDLE
>> },
>> { .dev_id = "3d2", .dt_id = TEGRA30_CLK_GR3D2 },
>
> The "3d2" also has the "idle" divisor, why have you skipped it?
Thanks, missed this.
>> { .dev_id = "2d", .dt_id = TEGRA30_CLK_GR2D },
>> + { .dev_id = "2d", .con_id = "mux", .dt_id = TEGRA30_CLK_GR2D_MUX },
>> + { .dev_id = "2d", .con_id = "idle", .dt_id = TEGRA30_CLK_GR2D_IDLE
>> },
>> { .dev_id = "se", .dt_id = TEGRA30_CLK_SE },
>> { .dev_id = "mselect", .dt_id = TEGRA30_CLK_MSELECT },
>> { .dev_id = "tegra-nor", .dt_id = TEGRA30_CLK_NOR },
>
> [snip]
>
>>
>> > According to TRM, Tegra20 and Tegra114 have these "idle-mode" clock
>> > dividers
>> > as well. Why only T30 should have them?
>>
>> I've got a separate series to sort t20 bits out, i've not used the
>> tegra114
>>
>
> This makes this series to look a bit inconsistent, please send out all
> the
> patches to give a consistent view.
>
> I don't see anything that could really stop you from adding the clocks
> for
> T114, its 2d/3d clocks definition pretty matches to T20/30.
I'd prefer not to be touch architectures I don't have access to do.
> >> a/include/dt-bindings/clock/tegra30-car.h
>> >> b/include/dt-bindings/clock/tegra30-car.h index
>> >> 3c90f1535551..eda4ca60351e
>> >> 100644
>> >> --- a/include/dt-bindings/clock/tegra30-car.h
>> >> +++ b/include/dt-bindings/clock/tegra30-car.h
>> >> @@ -269,6 +269,11 @@
>> >>
>> >> #define TEGRA30_CLK_AUDIO3_MUX 306
>> >> #define TEGRA30_CLK_AUDIO4_MUX 307
>> >> #define TEGRA30_CLK_SPDIF_MUX 308
>> >>
>> >> -#define TEGRA30_CLK_CLK_MAX 309
>> >> +
>> >> +#define TEGRA30_CLK_GR2D_MUX 309
>> >> +#define TEGRA30_CLK_GR3D_MUX 310
>> >> +#define TEGRA30_CLK_GR2D_IDLE 311
>> >> +#define TEGRA30_CLK_GR3D_IDLE 312
>> >> +#define TEGRA30_CLK_CLK_MAX 313
>> >>
>> >> #endif /* _DT_BINDINGS_CLOCK_TEGRA30_CAR_H */
>> >
>> > IIUC, that "idle-mode" divisor is just some kind of power-safe feature,
>> > is
>> > there any real use-case for these clocks? Why not to just pre-configure
>> > the
>> > "idle-mode" bits during the clocks initialization?
>>
>> It is is nice to have it available after to check,
>
> Please initialize the "idle" clock rate via the tegra_clk_init_table in
> the
> patch that adds the clock or in a followup patch within the same
> patchset.
>
>> other than that we're
>> not
>> using any drivers that currently dynamically change the values of
>> this.
>
> All changes made to upstream kernel must be justified, the only
> acceptable
> justification is that a change is required for the upstream driver.
^ permalink raw reply
* [PATCH] cpufreq: qcom-kryo: add NULL entry to the end of_device_id array
From: YueHaibing @ 2018-07-23 12:34 UTC (permalink / raw)
To: ilia.lin, rjw, viresh.kumar; +Cc: linux-kernel, linux-pm, YueHaibing
Make sure of_device_id tables are NULL terminated
Found by coccinelle spatch "misc/of_table.cocci"
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/cpufreq/qcom-cpufreq-kryo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c b/drivers/cpufreq/qcom-cpufreq-kryo.c
index 29389ac..efc9a7a 100644
--- a/drivers/cpufreq/qcom-cpufreq-kryo.c
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -183,6 +183,7 @@ static struct platform_driver qcom_cpufreq_kryo_driver = {
static const struct of_device_id qcom_cpufreq_kryo_match_list[] __initconst = {
{ .compatible = "qcom,apq8096", },
{ .compatible = "qcom,msm8996", },
+ {}
};
/*
--
2.7.0
^ permalink raw reply related
* [igt-dev] ✗ Fi.CI.BAT: failure for series starting with [i-g-t,1/4] lib/igt_pm: Make exit handlers signal safe
From: Patchwork @ 2018-07-23 12:37 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: igt-dev
In-Reply-To: <20180723114658.13025-1-tvrtko.ursulin@linux.intel.com>
== Series Details ==
Series: series starting with [i-g-t,1/4] lib/igt_pm: Make exit handlers signal safe
URL : https://patchwork.freedesktop.org/series/47052/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4521 -> IGTPW_1627 =
== Summary - FAILURE ==
Serious unknown changes coming with IGTPW_1627 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_1627, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://patchwork.freedesktop.org/api/1.0/series/47052/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in IGTPW_1627:
=== IGT changes ===
==== Possible regressions ====
igt@pm_rpm@basic-rte:
fi-cfl-s3: PASS -> WARN +1
== Known issues ==
Here are the changes found in IGTPW_1627 that come from known issues:
=== IGT changes ===
==== Issues hit ====
igt@drv_module_reload@basic-no-display:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106725)
igt@drv_module_reload@basic-reload:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106248, fdo#106725)
igt@kms_chamelium@hdmi-hpd-fast:
fi-kbl-7500u: SKIP -> FAIL (fdo#103841, fdo#102672)
igt@kms_flip@basic-flip-vs-wf_vblank:
fi-glk-j4005: PASS -> FAIL (fdo#100368)
==== Possible fixes ====
igt@prime_vgem@basic-fence-flip:
fi-ilk-650: FAIL (fdo#104008) -> PASS
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248
fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725
== Participating hosts (47 -> 43) ==
Additional (1): fi-bsw-kefka
Missing (5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u
== Build changes ==
* IGT: IGT_4570 -> IGTPW_1627
CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_1627: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1627/
IGT_4570: 65cdccdc7bcbb791d791aeeeecb784a382110a3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1627/issues.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* [PATCH v2 3/3] PCI: imx: Initial imx7d pm support
From: Leonard Crestez @ 2018-07-23 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1532338685.3163.93.camel@pengutronix.de>
On Mon, 2018-07-23 at 11:38 +0200, Lucas Stach wrote:
> Hi Leonard,
>
> Am Freitag, den 20.07.2018, 15:47 +0300 schrieb Leonard Crestez:
> > On imx7d the pcie-phy power domain is turned off in suspend and this can
> > make the system hang after resume when attempting any read from PCI.
> >
> > Fix this by adding minimal suspend/resume code from the nxp internal
> > tree. This will prepare for powering down on suspend and reset the block
> > on resume.
> >
> > Code is only for imx7d but a very similar sequence can be used for
> > other socs.
> >
> > +static void imx6_pcie_ltssm_disable(struct device *dev)
> > +{
> > + struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
> > +
> > + switch (imx6_pcie->variant) {
> > + case IMX6Q:
> > + case IMX6SX:
> > + case IMX6QP:
> > + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> > + IMX6Q_GPR12_PCIE_CTL_2, 0);
>
> Has this been tested on i.MX6? LTSSM disable requires a more complex
> sequence on this SoC to avoid hanging the system. See commit
> 3e3e406e3807 "PCI: imx6: Put LTSSM in "Detect" state before disabling
> it".
This patch only enables suspend/resume for imx7d with other SOCs to
follow later. The ltssm_disable function is just symmetric with
ltssm_enable.
The 6Q parts are affected by errata "ERR005723 PCIe: PCIe does not
support L2 power down [i.MX 6Dual/6Quad Only]".
This design error seems to have the same root cause as your problem (no
dedicated reset control) so this works out quite nicely: the solution
is to never power down pci on affected chips.
> > +static int imx6_pcie_resume_noirq(struct device *dev)
> > +{
> > + int ret = 0;
> > + struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
> > + struct pcie_port *pp = &imx6_pcie->pci->pp;
> > +
> > + if (imx6_pcie->variant != IMX7D)
> > + return 0;
> > +
> > + imx6_pcie_assert_core_reset(imx6_pcie);
> > + imx6_pcie_init_phy(imx6_pcie);
> > + imx6_pcie_deassert_core_reset(imx6_pcie);
> > + dw_pcie_setup_rc(pp);
> > +
> > + ret = imx6_pcie_establish_link(imx6_pcie);
> > + if (ret < 0)
> > + pr_err("pcie link is down after resume.\n");
>
> dev_err(), please.
The imx6_pcie_establish_link function already seems to link error
information so the message could be dropped. However it's still helpful
to know that those pci link errors are specifically related to resume.
Fabio suggested I propagate the return code but I'm not sure that's
helpful since "link down" is what happens when the slot is empty and
this is clearly not a "error" or "failure". It's not clear if "slot
empty" can be distinguished in some way.
I'll switch to dev_info and drop the error code, is this OK?
One aspect that I skipped is PME_Turn_Off support: The PCI standard
mandates that this is sent before entering L2/L3 and the designware
core supports this but it's not part of this patch.
Is it fine if I post this separately or should it be part of the same
series? The turnoff bit is in IOMUX gpr for imx6 but SRC for imx7 so it
would require additional patches in reset, dts and then pci.
^ permalink raw reply
* Re: [PATCH v2 3/3] PCI: imx: Initial imx7d pm support
From: Leonard Crestez @ 2018-07-23 12:37 UTC (permalink / raw)
To: l.stach@pengutronix.de, Richard Zhu, Fabio Estevam
Cc: A.s. Dong, linux-kernel@vger.kernel.org, dl-linux-imx,
jingoohan1@gmail.com, lorenzo.pieralisi@arm.com,
linux-pm@vger.kernel.org, Joao.Pinto@synopsys.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org,
andrew.smirnov@gmail.com, bhelgaas@google.com,
linux-pci@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <1532338685.3163.93.camel@pengutronix.de>
On Mon, 2018-07-23 at 11:38 +0200, Lucas Stach wrote:
> Hi Leonard,
>
> Am Freitag, den 20.07.2018, 15:47 +0300 schrieb Leonard Crestez:
> > On imx7d the pcie-phy power domain is turned off in suspend and this can
> > make the system hang after resume when attempting any read from PCI.
> >
> > Fix this by adding minimal suspend/resume code from the nxp internal
> > tree. This will prepare for powering down on suspend and reset the block
> > on resume.
> >
> > Code is only for imx7d but a very similar sequence can be used for
> > other socs.
> >
> > +static void imx6_pcie_ltssm_disable(struct device *dev)
> > +{
> > + struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
> > +
> > + switch (imx6_pcie->variant) {
> > + case IMX6Q:
> > + case IMX6SX:
> > + case IMX6QP:
> > + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> > + IMX6Q_GPR12_PCIE_CTL_2, 0);
>
> Has this been tested on i.MX6? LTSSM disable requires a more complex
> sequence on this SoC to avoid hanging the system. See commit
> 3e3e406e3807 "PCI: imx6: Put LTSSM in "Detect" state before disabling
> it".
This patch only enables suspend/resume for imx7d with other SOCs to
follow later. The ltssm_disable function is just symmetric with
ltssm_enable.
The 6Q parts are affected by errata "ERR005723 PCIe: PCIe does not
support L2 power down [i.MX 6Dual/6Quad Only]".
This design error seems to have the same root cause as your problem (no
dedicated reset control) so this works out quite nicely: the solution
is to never power down pci on affected chips.
> > +static int imx6_pcie_resume_noirq(struct device *dev)
> > +{
> > + int ret = 0;
> > + struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
> > + struct pcie_port *pp = &imx6_pcie->pci->pp;
> > +
> > + if (imx6_pcie->variant != IMX7D)
> > + return 0;
> > +
> > + imx6_pcie_assert_core_reset(imx6_pcie);
> > + imx6_pcie_init_phy(imx6_pcie);
> > + imx6_pcie_deassert_core_reset(imx6_pcie);
> > + dw_pcie_setup_rc(pp);
> > +
> > + ret = imx6_pcie_establish_link(imx6_pcie);
> > + if (ret < 0)
> > + pr_err("pcie link is down after resume.\n");
>
> dev_err(), please.
The imx6_pcie_establish_link function already seems to link error
information so the message could be dropped. However it's still helpful
to know that those pci link errors are specifically related to resume.
Fabio suggested I propagate the return code but I'm not sure that's
helpful since "link down" is what happens when the slot is empty and
this is clearly not a "error" or "failure". It's not clear if "slot
empty" can be distinguished in some way.
I'll switch to dev_info and drop the error code, is this OK?
One aspect that I skipped is PME_Turn_Off support: The PCI standard
mandates that this is sent before entering L2/L3 and the designware
core supports this but it's not part of this patch.
Is it fine if I post this separately or should it be part of the same
series? The turnoff bit is in IOMUX gpr for imx6 but SRC for imx7 so it
would require additional patches in reset, dts and then pci.
^ permalink raw reply
* Re: [PATCH v2 3/3] PCI: imx: Initial imx7d pm support
From: Leonard Crestez @ 2018-07-23 12:37 UTC (permalink / raw)
To: l.stach@pengutronix.de, Richard Zhu, Fabio Estevam
Cc: A.s. Dong, lorenzo.pieralisi@arm.com, linux-pm@vger.kernel.org,
andrew.smirnov@gmail.com, jingoohan1@gmail.com,
linux-kernel@vger.kernel.org, Joao.Pinto@synopsys.com,
dl-linux-imx, kernel@pengutronix.de, linux-pci@vger.kernel.org,
bhelgaas@google.com, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1532338685.3163.93.camel@pengutronix.de>
On Mon, 2018-07-23 at 11:38 +0200, Lucas Stach wrote:
> Hi Leonard,
>
> Am Freitag, den 20.07.2018, 15:47 +0300 schrieb Leonard Crestez:
> > On imx7d the pcie-phy power domain is turned off in suspend and this can
> > make the system hang after resume when attempting any read from PCI.
> >
> > Fix this by adding minimal suspend/resume code from the nxp internal
> > tree. This will prepare for powering down on suspend and reset the block
> > on resume.
> >
> > Code is only for imx7d but a very similar sequence can be used for
> > other socs.
> >
> > +static void imx6_pcie_ltssm_disable(struct device *dev)
> > +{
> > + struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
> > +
> > + switch (imx6_pcie->variant) {
> > + case IMX6Q:
> > + case IMX6SX:
> > + case IMX6QP:
> > + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> > + IMX6Q_GPR12_PCIE_CTL_2, 0);
>
> Has this been tested on i.MX6? LTSSM disable requires a more complex
> sequence on this SoC to avoid hanging the system. See commit
> 3e3e406e3807 "PCI: imx6: Put LTSSM in "Detect" state before disabling
> it".
This patch only enables suspend/resume for imx7d with other SOCs to
follow later. The ltssm_disable function is just symmetric with
ltssm_enable.
The 6Q parts are affected by errata "ERR005723 PCIe: PCIe does not
support L2 power down [i.MX 6Dual/6Quad Only]".
This design error seems to have the same root cause as your problem (no
dedicated reset control) so this works out quite nicely: the solution
is to never power down pci on affected chips.
> > +static int imx6_pcie_resume_noirq(struct device *dev)
> > +{
> > + int ret = 0;
> > + struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
> > + struct pcie_port *pp = &imx6_pcie->pci->pp;
> > +
> > + if (imx6_pcie->variant != IMX7D)
> > + return 0;
> > +
> > + imx6_pcie_assert_core_reset(imx6_pcie);
> > + imx6_pcie_init_phy(imx6_pcie);
> > + imx6_pcie_deassert_core_reset(imx6_pcie);
> > + dw_pcie_setup_rc(pp);
> > +
> > + ret = imx6_pcie_establish_link(imx6_pcie);
> > + if (ret < 0)
> > + pr_err("pcie link is down after resume.\n");
>
> dev_err(), please.
The imx6_pcie_establish_link function already seems to link error
information so the message could be dropped. However it's still helpful
to know that those pci link errors are specifically related to resume.
Fabio suggested I propagate the return code but I'm not sure that's
helpful since "link down" is what happens when the slot is empty and
this is clearly not a "error" or "failure". It's not clear if "slot
empty" can be distinguished in some way.
I'll switch to dev_info and drop the error code, is this OK?
One aspect that I skipped is PME_Turn_Off support: The PCI standard
mandates that this is sent before entering L2/L3 and the designware
core supports this but it's not part of this patch.
Is it fine if I post this separately or should it be part of the same
series? The turnoff bit is in IOMUX gpr for imx6 but SRC for imx7 so it
would require additional patches in reset, dts and then pci.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/6] dt: bindings: add bindings for msa memory region
From: Govind Singh @ 2018-07-23 12:36 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, niklas.cassel, linux-wireless, ath10k,
bjorn.andersson, david.brown, andy.gross
In-Reply-To: <20180711152718.GA18470@rob-hp-laptop>
Hi Rob,
On 2018-07-11 20:57, Rob Herring wrote:
> On Fri, Jul 06, 2018 at 02:30:43PM +0530, Govind Singh wrote:
>> Add device tree binding documentation details of msa
>> memory region for ath10k qmi client for SDM845/APQ8098
>> SoC into "qcom,ath10k.txt".
>>
>> Signed-off-by: Govind Singh <govinds@codeaurora.org>
>> ---
>> .../bindings/net/wireless/qcom,ath10k.txt | 13
>> +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>> index 7fd4e8ce4149..87489054aea5 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>> @@ -57,6 +57,16 @@ Optional properties:
>> - <supply-name>-supply: handle to the regulator device tree node
>> optional "supply-name" is "vdd-0.8-cx-mx".
>>
>> += SUBNODES:
>> +wcn3990-wifi node may contain one subnode, named "msa" representing
>> +the fixed msa memory regions used by the wifi firmware running in Q6.
>> +This sub-node must contain:
>
> Why do you need a sub-node? Just add memory-region property.
>
Fixed in v4 version.
Thanks,
Govind
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: [PATCH v3 3/6] dt: bindings: add bindings for msa memory region
From: Govind Singh @ 2018-07-23 12:36 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
andy.gross-QSEj5FYQhm4dnm+yROfE0A,
niklas.cassel-QSEj5FYQhm4dnm+yROfE0A,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180711152718.GA18470@rob-hp-laptop>
Hi Rob,
On 2018-07-11 20:57, Rob Herring wrote:
> On Fri, Jul 06, 2018 at 02:30:43PM +0530, Govind Singh wrote:
>> Add device tree binding documentation details of msa
>> memory region for ath10k qmi client for SDM845/APQ8098
>> SoC into "qcom,ath10k.txt".
>>
>> Signed-off-by: Govind Singh <govinds-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>> .../bindings/net/wireless/qcom,ath10k.txt | 13
>> +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>> index 7fd4e8ce4149..87489054aea5 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>> @@ -57,6 +57,16 @@ Optional properties:
>> - <supply-name>-supply: handle to the regulator device tree node
>> optional "supply-name" is "vdd-0.8-cx-mx".
>>
>> += SUBNODES:
>> +wcn3990-wifi node may contain one subnode, named "msa" representing
>> +the fixed msa memory regions used by the wifi firmware running in Q6.
>> +This sub-node must contain:
>
> Why do you need a sub-node? Just add memory-region property.
>
Fixed in v4 version.
Thanks,
Govind
^ permalink raw reply
* [PATCH 26/26] ARM: tegra: colibri_t30: update compatibility comment
From: Marcel Ziswiler @ 2018-07-23 12:36 UTC (permalink / raw)
To: devicetree, linux-tegra, linux-kernel
Cc: Marcel Ziswiler, Thierry Reding, Jonathan Hunter, Rob Herring,
Mark Rutland
In-Reply-To: <20180723123658.980-1-marcel@ziswiler.com>
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Update compatibility comment.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
arch/arm/boot/dts/tegra30-colibri.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi b/arch/arm/boot/dts/tegra30-colibri.dtsi
index e10e0f2b6034..cf7637cfb47d 100644
--- a/arch/arm/boot/dts/tegra30-colibri.dtsi
+++ b/arch/arm/boot/dts/tegra30-colibri.dtsi
@@ -3,7 +3,7 @@
/*
* Toradex Colibri T30 Module Device Tree
- * Compatible for Revisions V1.1B, V1.1C, V1.1D, V1.1E; IT: V1.1A
+ * Compatible for Revisions V1.1B, V1.1C, V1.1D, V1.1E, V1.1F; IT: V1.1A, V1.1B
*/
/ {
model = "Toradex Colibri T30";
--
2.14.4
^ 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.