Re: [PATCH] net: stmmac: make some functions static
From: Colin King Date: Thu, 22 Jun 2017 17:17:29 +0100 > From: Colin Ian King > > The functions dwmac4_dma_init_rx_chan, dwmac4_dma_init_tx_chan and > dwmac4_dma_init_channel do not need to be in global scope, so them > static. > > Cleans up sparse warnings: > "symbol 'dwmac4_dma_init_rx_chan' was not declared. Should it be static?" > "symbol 'dwmac4_dma_init_tx_chan' was not declared. Should it be static?" > "symbol 'dwmac4_dma_init_channel' was not declared. Should it be static?" > > Signed-off-by: Colin Ian King Applied to net-next, thanks.
Re: [PATCH 0/3] Enable namespaced file capabilities
"Serge E. Hallyn" writes: > Quoting Casey Schaufler (ca...@schaufler-ca.com): >> On 6/23/2017 9:30 AM, Serge E. Hallyn wrote: >> > Quoting Casey Schaufler (ca...@schaufler-ca.com): >> >> Or maybe just security.ns.capability, taking James' comment into account. >> > That last one may be suitable as an option, useful for his particular >> > (somewhat barbaric :) use case, but it's not ok for the general solution. >> >> security.ns@uid=100.capability > > I'm ok with this. It gives protection from older kernels, and puts > the 'ns@uid=' at predictable locations for security and trusted. > >> It makes the namespace part explicit and separate from >> the rest of the attribute name. It also generalizes for >> other attributes. >> >> security.ns@uid=1000@smack=WestOfOne.SMACK64 > > Looks good to me. > > Do we want to say that '.' ends the attribute list? That of > course means '.' cannot be in the attributes. Perhaps end > with '@@' instead? Just a thought. > > What do others think? I think we have two things that will limit the allowed attributes severely. 1) We need to the names of all of the xattrs when mounting a filesystem with s_user_ns != &init_user_ns. I haven't yet checked the patches to see if they do this properly. 2) Names of xattrs are not fully general and filesystems perform various tricks to encode them more densely. We should see what the games with xattr names do to how densely xattrs can be stored on disk. That matters. Putting the uid of the root user in the name sounds fundamental to doing things this way. I am not at all certain about putting smack labels and generally treating this as something we can add two arbitrarily. If nothing else this reminds me of the frequent problem in certifications with ouids. Arbitrary attributes tend to defeat parsers in a security context on a regular basis. Even the kernel command line parser has seen problems in this area, and it isn't security sensitive most of the time. Extensibility is good in the abstract long term sense. Extensibility in the here and now where we don't even know which attributes we are talking about scares me. I don't see how we can possibily know with multiple attributes which xattrs will be the one to use. As we won't even know which properties of the kernel to look at to match attributes. So while I don't mind reorganizing the order we put the information into the attribute. Let's keep what we place in there very specific. Eric
Re: [PATCH v3 4/4] kmod: throttle kmod thread limit
On Fri, Jun 23, 2017 at 06:16:19PM +0200, Luis R. Rodriguez wrote: > On Thu, Jun 22, 2017 at 05:19:36PM +0200, Petr Mladek wrote: > > On Fri 2017-05-26 14:12:28, Luis R. Rodriguez wrote: > > > --- a/kernel/kmod.c > > > +++ b/kernel/kmod.c > > > @@ -178,6 +175,7 @@ int __request_module(bool wait, const char *fmt, ...) > > > ret = call_modprobe(module_name, wait ? UMH_WAIT_PROC : UMH_WAIT_EXEC); > > > > > > atomic_inc(&kmod_concurrent_max); > > > + wake_up_all(&kmod_wq); > > > > Does it make sense to wake up all waiters when we released the resource > > only for one? IMHO, a simple wake_up() should be here. > > Then we should wake_up() also on failure, otherwise we have the potential > to not wake some in a proper time. I checked and it turns out we have no error paths after we consume a kmod ticket, if you will. Once we bump with atomic_dec_if_positive() we assume we're moving forward with an attempt, and the only failure path is already bundled with a wake at the end of the __request_module() call. Then the next question would be *who* exactly gets woken up next if we just use wake_up() ? The common core wake up code varies depending on use and all this reminded me of the complexity we just don't need, so I have now converted to use swait. swait uses list_add() if empty and then iterates with list_first_entry() on wakeup, so that should get the first item added to the wait list. Works with me. Will run a test a before v4 is sent, but since only 2 patches are modified will only send a respective update for these 2 patches. Luis
Re: [PATCH RESEND 09/13] platform/chrome: cros_ec_lpc: Add MKBP events support over ACPI
Hi Thierry,
On Fri, Jun 23, 2017 at 09:35:06AM +0200, Thierry Escande wrote:
> Hi Benson,
>
> On 22/06/2017 21:35, Benson Leung wrote:
>
>
>
> >>+ adev = ACPI_COMPANION(dev);
> >>+ if (adev) {
> >>+ status = acpi_install_notify_handler(adev->handle,
> >>+ACPI_ALL_NOTIFY,
> >
> >Is there a reason you're using ACPI_ALL_NOTIFY here instead of
> >ACPI_SYSTEM_NOTIFY that is done in the CHROMIUM version of this?
> >
> In the original patch
> (https://chromium-review.googlesource.com/c/358155/) ACPI_ALL_NOTIFY
> is passed to acpi_install_notify_handler() and ACPI_SYSTEM_NOTIFY to
> acpi_remove_notify_handler. I changed it for remove_notify call to
> unsure all handler references were removed.
>
Oh, I see. Looks good. I'll go ahead and make the same change in the
chromeos-4.4 kernel too.
Signed-off-by: Benson Leung
Applied.
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: Digital signature
[PATCH v2 5/7] ARM: B15: Add suspend/resume hooks
The Broadcom Brahma-B15 CPU readahead cache registers will be restored
to their Power-on-Reset values after a S3 suspend/resume cycles, so we
want to restore what we had enabled before.
Another thing we want to take care of is disabling the read-ahead cache
prior to suspending to avoid any sort of side effect with the spinlock
we need to grab to serialize register accesses.
Signed-off-by: Florian Fainelli
---
arch/arm/mm/cache-b15-rac.c | 48 +
1 file changed, 48 insertions(+)
diff --git a/arch/arm/mm/cache-b15-rac.c b/arch/arm/mm/cache-b15-rac.c
index d85b63211759..9ee1d89cced0 100644
--- a/arch/arm/mm/cache-b15-rac.c
+++ b/arch/arm/mm/cache-b15-rac.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -41,6 +42,10 @@ extern void v7_flush_kern_cache_all(void);
RACENPREF_MASK << RACENDATA_SHIFT)
#define RAC_ENABLED0
+/* Special state where we want to bypass the spinlock and call directly
+ * into the v7 cache maintenance operations during suspend/resume
+ */
+#define RAC_SUSPENDED 1
static void __iomem *b15_rac_base;
static DEFINE_SPINLOCK(rac_lock);
@@ -96,6 +101,12 @@ void b15_flush_##name(void)
\
unsigned int do_flush; \
u32 val = 0;\
\
+ if (test_bit(RAC_SUSPENDED, &b15_rac_flags)) { \
+ v7_flush_##name(); \
+ bar;\
+ return; \
+ } \
+ \
spin_lock(&rac_lock); \
do_flush = test_bit(RAC_ENABLED, &b15_rac_flags); \
if (do_flush) \
@@ -208,6 +219,39 @@ static int b15_rac_dead_cpu(unsigned int cpu)
}
#endif /* CONFIG_HOTPLUG_CPU */
+#ifdef CONFIG_PM_SLEEP
+static int b15_rac_suspend(void)
+{
+ /* Suspend the read-ahead cache oeprations, forcing our cache
+* implementation to fallback to the regular ARMv7 calls.
+*
+* We are guaranteed to be running on the boot CPU at this point and
+* with every other CPU quiesced, so setting RAC_SUSPENDED is not racy
+* here.
+*/
+ rac_config0_reg = b15_rac_disable_and_flush();
+ set_bit(RAC_SUSPENDED, &b15_rac_flags);
+
+ return 0;
+}
+
+static void b15_rac_resume(void)
+{
+ /* Coming out of a S3 suspend/resume cycle, the read-ahead cache
+* register RAC_CONFIG0_REG will be restored to its default value, make
+* sure we re-enable it and set the enable flag, we are also guaranteed
+* to run on the boot CPU, so not racy again.
+*/
+ __b15_rac_enable(rac_config0_reg);
+ clear_bit(RAC_SUSPENDED, &b15_rac_flags);
+}
+
+static struct syscore_ops b15_rac_syscore_ops = {
+ .suspend= b15_rac_suspend,
+ .resume = b15_rac_resume,
+};
+#endif
+
static int __init b15_rac_init(void)
{
struct device_node *dn;
@@ -242,6 +286,10 @@ static int __init b15_rac_init(void)
goto out_cpu_dead;
#endif
+#ifdef CONFIG_PM_SLEEP
+ register_syscore_ops(&b15_rac_syscore_ops);
+#endif
+
spin_lock(&rac_lock);
reg = __raw_readl(b15_rac_base + RAC_CONFIG0_REG);
for_each_possible_cpu(cpu)
--
2.9.3
[PATCH v2 7/7] MAINTAINERS: Update brcmstb entries to cover B15 code
Update the brcmstb entry to cover the Broadcom Brahma-B15 processor read-ahead cache support code. Signed-off-by: Florian Fainelli --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 09b5ab6a8a5c..1e2035ef7c1c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2748,6 +2748,8 @@ S:Maintained F: arch/arm/mach-bcm/*brcmstb* F: arch/arm/boot/dts/bcm7*.dts* F: drivers/bus/brcmstb_gisb.c +F: arch/arm/mm/cache-b15-rac.c +F: arch/arm/include/asm/hardware/cache-b15-rac.h N: brcmstb BROADCOM BMIPS MIPS ARCHITECTURE -- 2.9.3
[PATCH v2 2/7] ARM: Add Broadcom Brahma-B15 readahead cache support
This patch adds support for the Broadcom Brahma-B15 CPU readahead cache controller. This cache controller sits between the L2 and the memory bus and its purpose is to provide a friendler burst size towards the DDR interface than the native cache line size. The readahead cache is mostly transparent, except for flush_kern_cache_all, which is precisely what we are overriding here. The readahead cache only intercepts reads, and does invalidate on writes (IOW), as such, some data can remain stale in any of its buffers, such that we need to flush it, which is an operation that needs to happen in a particular order: - disable the readahead cache - flush it - call the appropriate cache-v7.S function - re-enable This patch tries to minimize the impact to the cache-v7.S file by only providing a stub in case CONFIG_CACHE_B15_RAC is enabled (default for ARCH_BRCMSTB since it is the current user). Signed-off-by: Alamy Liu Signed-off-by: Florian Fainelli --- arch/arm/include/asm/glue-cache.h | 4 + arch/arm/include/asm/hardware/cache-b15-rac.h | 10 ++ arch/arm/mm/Kconfig | 8 ++ arch/arm/mm/Makefile | 1 + arch/arm/mm/cache-b15-rac.c | 177 ++ 5 files changed, 200 insertions(+) create mode 100644 arch/arm/include/asm/hardware/cache-b15-rac.h create mode 100644 arch/arm/mm/cache-b15-rac.c diff --git a/arch/arm/include/asm/glue-cache.h b/arch/arm/include/asm/glue-cache.h index 01c3d92624e5..8d1f498e5dd8 100644 --- a/arch/arm/include/asm/glue-cache.h +++ b/arch/arm/include/asm/glue-cache.h @@ -117,6 +117,10 @@ # endif #endif +#if defined(CONFIG_CACHE_B15_RAC) +# define MULTI_CACHE 1 +#endif + #if defined(CONFIG_CPU_V7M) # define MULTI_CACHE 1 #endif diff --git a/arch/arm/include/asm/hardware/cache-b15-rac.h b/arch/arm/include/asm/hardware/cache-b15-rac.h new file mode 100644 index ..3d43ec06fd35 --- /dev/null +++ b/arch/arm/include/asm/hardware/cache-b15-rac.h @@ -0,0 +1,10 @@ +#ifndef __ASM_ARM_HARDWARE_CACHE_B15_RAC_H +#define __ASM_ARM_HARDWARE_CACHE_B15_RAC_H + +#ifndef __ASSEMBLY__ + +void b15_flush_kern_cache_all(void); + +#endif + +#endif diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index c6c4c9c8824b..cf7db07c98f4 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -904,6 +904,14 @@ config OUTER_CACHE_SYNC The outer cache has a outer_cache_fns.sync function pointer that can be used to drain the write buffer of the outer cache. +config CACHE_B15_RAC + bool "Enable the Broadcom Brahma-B15 read-ahead cache controller" + depends on ARCH_BRCMSTB + default y + help + This option enables the Broadcom Brahma-B15 read-ahead cache + controller. If disabled, the read-ahead cache remains off. + config CACHE_FEROCEON_L2 bool "Enable the Feroceon L2 cache controller" depends on ARCH_MV78XX0 || ARCH_MVEBU diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile index b3dea80715b4..0d7937e884f8 100644 --- a/arch/arm/mm/Makefile +++ b/arch/arm/mm/Makefile @@ -102,6 +102,7 @@ AFLAGS_proc-v6.o:=-Wa,-march=armv6 AFLAGS_proc-v7.o :=-Wa,-march=armv7-a obj-$(CONFIG_OUTER_CACHE) += l2c-common.o +obj-$(CONFIG_CACHE_B15_RAC)+= cache-b15-rac.o obj-$(CONFIG_CACHE_FEROCEON_L2)+= cache-feroceon-l2.o obj-$(CONFIG_CACHE_L2X0) += cache-l2x0.o l2c-l2x0-resume.o obj-$(CONFIG_CACHE_L2X0_PMU) += cache-l2x0-pmu.o diff --git a/arch/arm/mm/cache-b15-rac.c b/arch/arm/mm/cache-b15-rac.c new file mode 100644 index ..679d44f003fd --- /dev/null +++ b/arch/arm/mm/cache-b15-rac.c @@ -0,0 +1,177 @@ +/* + * Broadcom Brahma-B15 CPU read-ahead cache management functions + * + * Copyright (C) 2015-2016 Broadcom + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include + +#include +#include + +extern void v7_flush_kern_cache_all(void); + +/* RAC register offsets, relative to the HIF_CPU_BIUCTRL register base */ +#define RAC_CONFIG0_REG(0x78) +#define RACENPREF_MASK(0x3) +#define RACPREFINST_SHIFT (0) +#define RACENINST_SHIFT (2) +#define RACPREFDATA_SHIFT (4) +#define RACENDATA_SHIFT (6) +#define RAC_CPU_SHIFT (8) +#define RACCFG_MASK (0xff) +#define RAC_CONFIG1_REG(0x7c) +#define RAC_FLUSH_REG (0x80) +#define FLUSH_RAC (1 << 0) + +/* Bitmask to enable instruction and data prefetching with a 256-bytes stride */ +#define RAC_DATA_INST_EN_MASK (1 << RACPREFINST_SHIFT | \ +RACENPREF_MASK << RACENINST_SHIFT | \ +
[PATCH v2 6/7] ARM: B15: Register reboot notifier for KEXEC
During kexec, we will go through kernel_kexec() -> syscore_suspend() if
CONFIG_KEXEC_JUMP is set, if not, down the road we end-up calling
kernel_restart_prepare() which invokes reboot notifiers with
SYS_RESTART.
We register a reboot notifier to make sure that the B15 read-ahead cache
is disabled, since it is another level of instruction and data cache,
and we want to avoid any potential side effects with booting a new
kernel with such a cache still turned on.
Signed-off-by: Florian Fainelli
---
arch/arm/mm/cache-b15-rac.c | 44
1 file changed, 44 insertions(+)
diff --git a/arch/arm/mm/cache-b15-rac.c b/arch/arm/mm/cache-b15-rac.c
index 9ee1d89cced0..f76988790011 100644
--- a/arch/arm/mm/cache-b15-rac.c
+++ b/arch/arm/mm/cache-b15-rac.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -151,6 +152,29 @@ static void b15_rac_enable(void)
__b15_rac_enable(enable);
}
+static int b15_rac_reboot_notifier(struct notifier_block *nb,
+ unsigned long action,
+ void *data)
+{
+ /* During kexec, we are not yet migrated on the boot CPU, so we need to
+* make sure we are SMP safe here. Once the RAC is disabled, flag it as
+* suspended such that the hotplug notifier returns early.
+*/
+ if (action == SYS_RESTART) {
+ spin_lock(&rac_lock);
+ b15_rac_disable_and_flush();
+ clear_bit(RAC_ENABLED, &b15_rac_flags);
+ set_bit(RAC_SUSPENDED, &b15_rac_flags);
+ spin_unlock(&rac_lock);
+ }
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block b15_rac_reboot_nb = {
+ .notifier_call = b15_rac_reboot_notifier,
+};
+
#ifdef CONFIG_HOTPLUG_CPU
/* The CPU hotplug case is the most interesting one, we basically need to make
* sure that the RAC is disabled for the entire system prior to having a CPU
@@ -191,6 +215,12 @@ static void b15_rac_enable(void)
/* Running on the dying CPU */
static int b15_rac_dying_cpu(unsigned int cpu)
{
+ /* During kexec/reboot, the RAC is disabled via the reboot notifier
+* return early here.
+*/
+ if (test_bit(RAC_SUSPENDED, &b15_rac_flags))
+ return 0;
+
spin_lock(&rac_lock);
/* Indicate that we are starting a hotplug procedure */
@@ -207,6 +237,12 @@ static int b15_rac_dying_cpu(unsigned int cpu)
/* Running on a non-dying CPU */
static int b15_rac_dead_cpu(unsigned int cpu)
{
+ /* During kexec/reboot, the RAC is disabled via the reboot notifier
+* return early here.
+*/
+ if (test_bit(RAC_SUSPENDED, &b15_rac_flags))
+ return 0;
+
spin_lock(&rac_lock);
/* And enable it */
@@ -272,6 +308,13 @@ static int __init b15_rac_init(void)
goto out;
}
+ ret = register_reboot_notifier(&b15_rac_reboot_nb);
+ if (ret) {
+ pr_err("failed to register reboot notifier\n");
+ iounmap(b15_rac_base);
+ goto out;
+ }
+
#ifdef CONFIG_HOTPLUG_CPU
ret = cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DEAD,
"arm/cache-b15-rac:dead",
@@ -308,6 +351,7 @@ static int __init b15_rac_init(void)
out_cpu_dead:
cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DYING);
out_unmap:
+ unregister_reboot_notifier(&b15_rac_reboot_nb);
iounmap(b15_rac_base);
out:
of_node_put(dn);
--
2.9.3
[PATCH v2 4/7] ARM: B15: Add CPU hotplug awareness
The Broadcom Brahma-B15 readahead cache needs to be disabled,
respectively re-enable during a CPU hotplug. In case we were not to do,
CPU hotplug would occasionally fail with random crashes when a given CPU
exits the coherency domain while the RAC is still enabled, as it would
get stale data from the RAC.
In order to avoid adding any specific B15 readahead-cache awareness to
arch/arm/mach-bcm/hotplug-brcmstb.c we use a CPU hotplug state machine
which allows us to catch CPU hotplug events and disable/flush enable the
RAC accordingly.
Signed-off-by: Alamy Liu
Signed-off-by: Florian Fainelli
---
arch/arm/mm/cache-b15-rac.c | 91 +
include/linux/cpuhotplug.h | 2 +
2 files changed, 93 insertions(+)
diff --git a/arch/arm/mm/cache-b15-rac.c b/arch/arm/mm/cache-b15-rac.c
index 679d44f003fd..d85b63211759 100644
--- a/arch/arm/mm/cache-b15-rac.c
+++ b/arch/arm/mm/cache-b15-rac.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -42,6 +44,7 @@ extern void v7_flush_kern_cache_all(void);
static void __iomem *b15_rac_base;
static DEFINE_SPINLOCK(rac_lock);
+static u32 rac_config0_reg;
/* Initialization flag to avoid checking for b15_rac_base, and to prevent
* multi-platform kernels from crashing here as well.
@@ -137,6 +140,74 @@ static void b15_rac_enable(void)
__b15_rac_enable(enable);
}
+#ifdef CONFIG_HOTPLUG_CPU
+/* The CPU hotplug case is the most interesting one, we basically need to make
+ * sure that the RAC is disabled for the entire system prior to having a CPU
+ * die, in particular prior to this dying CPU having exited the coherency
+ * domain.
+ *
+ * Once this CPU is marked dead, we can safely re-enable the RAC for the
+ * remaining CPUs in the system which are still online.
+ *
+ * Offlining a CPU is the problematic case, onlining a CPU is not much of an
+ * issue since the CPU and its cache-level hierarchy will start filling with
+ * the RAC disabled, so L1 and L2 only.
+ *
+ * In this function, we should NOT have to verify any unsafe setting/condition
+ * b15_rac_base:
+ *
+ * It is protected by the RAC_ENABLED flag which is cleared by default, and
+ * being cleared when initial procedure is done. b15_rac_base had been set at
+ * that time.
+ *
+ * RAC_ENABLED:
+ * There is a small timing windows, in b15_rac_init(), between
+ * cpuhp_setup_state_*()
+ * ...
+ * set RAC_ENABLED
+ * However, there is no hotplug activity based on the Linux booting
procedure.
+ *
+ * Since we have to disable RAC for all cores, we keep RAC on as long as as
+ * possible (disable it as late as possible) to gain the cache benefit.
+ *
+ * Thus, dying/dead states are chosen here
+ *
+ * We are choosing not do disable the RAC on a per-CPU basis, here, if we did
+ * we would want to consider disabling it as early as possible to benefit the
+ * other active CPUs.
+ */
+
+/* Running on the dying CPU */
+static int b15_rac_dying_cpu(unsigned int cpu)
+{
+ spin_lock(&rac_lock);
+
+ /* Indicate that we are starting a hotplug procedure */
+ __clear_bit(RAC_ENABLED, &b15_rac_flags);
+
+ /* Disable the readahead cache and save its value to a global */
+ rac_config0_reg = b15_rac_disable_and_flush();
+
+ spin_unlock(&rac_lock);
+
+ return 0;
+}
+
+/* Running on a non-dying CPU */
+static int b15_rac_dead_cpu(unsigned int cpu)
+{
+ spin_lock(&rac_lock);
+
+ /* And enable it */
+ __b15_rac_enable(rac_config0_reg);
+ __set_bit(RAC_ENABLED, &b15_rac_flags);
+
+ spin_unlock(&rac_lock);
+
+ return 0;
+}
+#endif /* CONFIG_HOTPLUG_CPU */
+
static int __init b15_rac_init(void)
{
struct device_node *dn;
@@ -157,6 +228,20 @@ static int __init b15_rac_init(void)
goto out;
}
+#ifdef CONFIG_HOTPLUG_CPU
+ ret = cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DEAD,
+ "arm/cache-b15-rac:dead",
+ NULL, b15_rac_dead_cpu);
+ if (ret)
+ goto out_unmap;
+
+ ret = cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DYING,
+ "arm/cache-b15-rac:dying",
+ NULL, b15_rac_dying_cpu);
+ if (ret)
+ goto out_cpu_dead;
+#endif
+
spin_lock(&rac_lock);
reg = __raw_readl(b15_rac_base + RAC_CONFIG0_REG);
for_each_possible_cpu(cpu)
@@ -170,6 +255,12 @@ static int __init b15_rac_init(void)
pr_info("Broadcom Brahma-B15 readahead cache at: 0x%p\n",
b15_rac_base + RAC_CONFIG0_REG);
+ goto out;
+
+out_cpu_dead:
+ cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DYING);
+out_unmap:
+ iounmap(b15_rac_base);
out:
of_node_put(dn);
return ret;
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 0f2a80377520..69d
[PATCH v2 3/7] ARM: Hook B15 readahead cache functions based on processor
If we detect that we are running on a Broadcom Brahma-B15 CPU, and CONFIG_CACHE_B15_RAC is enabled, make sure that we pick-up the b15_cache_fns function operations. If CONFIG_CACHE_B15_RAC is enabled, but we are not running on a Broadcom Brahma-B15 CPU, we will fallback to calling into the regular v7_cache_fns with no cost. If CONFIG_CACHE_B15_RAC is disabled, there is no cost and we just use the regular v7_cache_fns. Signed-off-by: Florian Fainelli --- arch/arm/mm/cache-v7.S | 21 + arch/arm/mm/proc-v7.S | 2 +- 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index de78109d002d..215df435bfb9 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -15,6 +15,7 @@ #include #include #include +#include #include "proc-macros.S" @@ -446,3 +447,23 @@ ENDPROC(v7_dma_unmap_area) @ define struct cpu_cache_fns (see and proc-macros.S) define_cache_functions v7 + + /* The Broadcom Brahma-B15 read-ahead cache requires some modifications +* to the v7_cache_fns, we only override the ones we need +*/ +#ifndef CONFIG_CACHE_B15_RAC + globl_equ b15_flush_kern_cache_all, v7_flush_kern_cache_all +#endif + globl_equ b15_flush_icache_all, v7_flush_icache_all + globl_equ b15_flush_kern_cache_louis, v7_flush_kern_cache_louis + globl_equ b15_flush_user_cache_all, v7_flush_user_cache_all + globl_equ b15_flush_user_cache_range, v7_flush_user_cache_range + globl_equ b15_coherent_kern_range,v7_coherent_kern_range + globl_equ b15_coherent_user_range,v7_coherent_user_range + globl_equ b15_flush_kern_dcache_area, v7_flush_kern_dcache_area + + globl_equ b15_dma_map_area, v7_dma_map_area + globl_equ b15_dma_unmap_area, v7_dma_unmap_area + globl_equ b15_dma_flush_range,v7_dma_flush_range + + define_cache_functions b15 diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 812ac861cd23..d55d493f9a1e 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -678,7 +678,7 @@ __v7_ca15mp_proc_info: __v7_b15mp_proc_info: .long 0x420f00f0 .long 0xff00 - __v7_proc __v7_b15mp_proc_info, __v7_b15mp_setup + __v7_proc __v7_b15mp_proc_info, __v7_b15mp_setup, cache_fns = b15_cache_fns .size __v7_b15mp_proc_info, . - __v7_b15mp_proc_info /* -- 2.9.3
[PATCH v2 0/7] ARM: Broadcom Brahma-B15 readahead cache support
Hi all, This patch series adds support for the Broadcom Brahma-B15 readahead cache. I submitted that patch series a couple of years ago, and then slept on it so here is another stab at it. Note that we did not implement this cache as a version of an outer cache for several reasons: - we initially thought we needed to intercept flush_icache_all and flush_kern_cache_louis but upon further inspection we convinced ourselves this is no longer needed, still, flush_cache_all() needs special handling here and needs to be wrapped around - the outer cache does not allow differentiating a DMA transfer direction this is a readahead cache, so it does not participate in writes, flushing it during reads *and* writes kills the performance completely - finally, most operations that outer_cache cares about are on MVA, which is transparent to the readahead cache here Changes in v2: - clarify that the read-ahead caches does invalidates on writes (IOW) based on Russell's feedback Florian Fainelli (7): ARM: v7: allow setting different cache functions ARM: Add Broadcom Brahma-B15 readahead cache support ARM: Hook B15 readahead cache functions based on processor ARM: B15: Add CPU hotplug awareness ARM: B15: Add suspend/resume hooks ARM: B15: Register reboot notifier for KEXEC MAINTAINERS: Update brcmstb entries to cover B15 code MAINTAINERS | 2 + arch/arm/include/asm/glue-cache.h | 4 + arch/arm/include/asm/hardware/cache-b15-rac.h | 10 + arch/arm/mm/Kconfig | 8 + arch/arm/mm/Makefile | 1 + arch/arm/mm/cache-b15-rac.c | 360 ++ arch/arm/mm/cache-v7.S| 21 ++ arch/arm/mm/proc-v7.S | 6 +- include/linux/cpuhotplug.h| 2 + 9 files changed, 411 insertions(+), 3 deletions(-) create mode 100644 arch/arm/include/asm/hardware/cache-b15-rac.h create mode 100644 arch/arm/mm/cache-b15-rac.c -- 2.9.3
Re: [PATCH net-next 1/2] ipmr: restrict mroute "queue full" warning to related error values
On 06/23/2017 10:39 AM, David Miller wrote: > From: Julien Gomes > Date: Wed, 21 Jun 2017 10:58:10 -0700 > >> When sending a cache report on mroute_sk, mroute will emit a >> "pending queue full" warning for every error value returned by >> sock_queue_rcv_skb(). >> This warning can be misleading, for example on the EPERM error value >> that sk_filter() can return. >> >> Restricting this warning to only ENOMEM or ENOBUFS seems more >> appropriate. >> >> Signed-off-by: Julien Gomes > Incorrect, no other error codes are possible. > > We never attach a socket filter to these kernel internal sockets, > therefore sk_filter() is not even applicable in this analysis. > > Therefore, -ENOBUFS and -ENOMEM are the only errors we can ever see > returned from sock_queue_rcv_skb(). > > This goes for your second patch as well. Up to now I would agree, but now that cache reports are also sent through Netlink, wouldn't it make sense to allow the user of mroute_sk to attach a filter to it in order to not receive cache reports on it? I agree this is not crucial in any way, but this could be a way to let the user program choose whether it receives the reports through one of the mediums, and not inevitably both. -- Julien Gomes
[PATCH v2 1/7] ARM: v7: allow setting different cache functions
In preparation for adding support for the Broadcom Brahma-B15 read-ahead cache which requires a different set of cache functions, allow the __v7_proc macro to override the cache_fns settings, and default to v7_cache_fns unless specified otherwise. Signed-off-by: Florian Fainelli --- arch/arm/mm/proc-v7.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 01d64c0b2563..812ac861cd23 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -567,7 +567,7 @@ __v7_setup_stack: /* * Standard v7 proc info content */ -.macro __v7_proc name, initfunc, mm_mmuflags = 0, io_mmuflags = 0, hwcaps = 0, proc_fns = v7_processor_functions +.macro __v7_proc name, initfunc, mm_mmuflags = 0, io_mmuflags = 0, hwcaps = 0, proc_fns = v7_processor_functions, cache_fns = v7_cache_fns ALT_SMP(.long PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AP_READ | \ PMD_SECT_AF | PMD_FLAGS_SMP | \mm_mmuflags) ALT_UP(.longPMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AP_READ | \ @@ -583,7 +583,7 @@ __v7_setup_stack: .long \proc_fns .long v7wbi_tlb_fns .long v6_user_fns - .long v7_cache_fns + .long \cache_fns .endm #ifndef CONFIG_ARM_LPAE -- 2.9.3
Re: [PATCH][mtd-next] mtd: parser: print hex size_t value using correct %zx printk format specifier
On Fri, Jun 23, 2017 at 12:02:34PM +0200, Rafał Miłecki wrote:
> On 2017-06-23 11:00, Colin King wrote:
> >From: Colin Ian King
> >
> >Use %zx instead of %X for size_t variable offset, fixes build warning:
> >
> >warning: format '%X' expects argument of type 'unsigned int', but
> >argument
> >2 has type 'size_t {aka long unsigned int}' [-Wformat=]
> >
> >Signed-off-by: Colin Ian King
>
> I sent similar patch few hours earlier:
> [PATCH] mtd: parsers: trx: fix pr_err format for printing offset
> https://patchwork.ozlabs.org/patch/779789/
>
> Brian: you may pick the one with nicer commit message, whichever one you
> prefer :)
I'll go with:
(a) the earlier one and
(b) the one that doesn't change 'X' to 'x'
That means Rafał, you're our lucky winner today! Thanks for playing,
Colin.
Regards,
Brian
Re: [PATCH v8 3/3] mailbox: qcom: Add support for APCS clock controller
On Fri 23 Jun 09:15 PDT 2017, Georgi Djakov wrote:
> +static int msm8916_register_clk(struct device *dev, void __iomem *base)
> +{
[..]
> + regmap = devm_regmap_init_mmio(dev, base, &a53cc_regmap_config);
> + if (IS_ERR(regmap)) {
> + ret = PTR_ERR(regmap);
> + dev_err(dev, "failed to init regmap mmio: %d\n", ret);
> + goto err;
> + }
I think it would be cleaner if you create the regmap in probe() and we
use that throughout the driver - rather than using two different access
mechanism.
> +
> + a53cc->clkr.regmap = regmap;
> +
> + ret = devm_clk_register_regmap(dev, &a53cc->clkr);
> + if (ret) {
> + dev_err(dev, "failed to register regmap clock: %d\n", ret);
> + goto err;
> + }
> +
> + ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_simple_get,
> + &a53cc->clkr.hw);
> + if (ret) {
> + dev_err(dev, "failed to add clock provider: %d\n", ret);
> + goto err;
> + }
> +
> + return 0;
> +
> +err:
> + clk_notifier_unregister(pclk, &a53cc->clk_nb);
> + return ret;
> +}
> +
> static int qcom_apcs_ipc_probe(struct platform_device *pdev)
> {
> + struct device_node *np = pdev->dev.of_node;
> struct qcom_apcs_ipc *apcs;
> struct resource *res;
> unsigned long offset;
> @@ -63,6 +178,13 @@ static int qcom_apcs_ipc_probe(struct platform_device
> *pdev)
> if (IS_ERR(base))
> return PTR_ERR(base);
>
> + if (of_device_is_compatible(np, "qcom,msm8916-apcs-kpss-global")) {
> + /* register the APCS mux and divider clock */
> + ret = msm8916_register_clk(&pdev->dev, base);
> + if (ret)
> + return ret;
> + }
> +
Don't you need to clean up anything in the below error path and in
remove()?
> offset = (unsigned long)of_device_get_match_data(&pdev->dev);
>
> apcs->reg = base + offset;
Other than that I think this looks reasonable.
Regards,
Bjorn
Re: [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place
On 6/23/2017 5:00 AM, Borislav Petkov wrote:
On Fri, Jun 16, 2017 at 01:56:19PM -0500, Tom Lendacky wrote:
Add the support to encrypt the kernel in-place. This is done by creating
new page mappings for the kernel - a decrypted write-protected mapping
and an encrypted mapping. The kernel is encrypted by copying it through
a temporary buffer.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/mem_encrypt.h |6 +
arch/x86/mm/Makefile |2
arch/x86/mm/mem_encrypt.c | 314
arch/x86/mm/mem_encrypt_boot.S | 150 +
4 files changed, 472 insertions(+)
create mode 100644 arch/x86/mm/mem_encrypt_boot.S
diff --git a/arch/x86/include/asm/mem_encrypt.h
b/arch/x86/include/asm/mem_encrypt.h
index af835cf..7da6de3 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -21,6 +21,12 @@
extern unsigned long sme_me_mask;
+void sme_encrypt_execute(unsigned long encrypted_kernel_vaddr,
+unsigned long decrypted_kernel_vaddr,
+unsigned long kernel_len,
+unsigned long encryption_wa,
+unsigned long encryption_pgd);
+
void __init sme_early_encrypt(resource_size_t paddr,
unsigned long size);
void __init sme_early_decrypt(resource_size_t paddr,
diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile
index 9e13841..0633142 100644
--- a/arch/x86/mm/Makefile
+++ b/arch/x86/mm/Makefile
@@ -38,3 +38,5 @@ obj-$(CONFIG_NUMA_EMU)+= numa_emulation.o
obj-$(CONFIG_X86_INTEL_MPX) += mpx.o
obj-$(CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS) += pkeys.o
obj-$(CONFIG_RANDOMIZE_MEMORY) += kaslr.o
+
+obj-$(CONFIG_AMD_MEM_ENCRYPT) += mem_encrypt_boot.o
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 842c8a6..6e87662 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -24,6 +24,8 @@
#include
#include
#include
+#include
+#include
/*
* Since SME related variables are set early in the boot process they must
@@ -209,8 +211,320 @@ void swiotlb_set_mem_attributes(void *vaddr, unsigned
long size)
set_memory_decrypted((unsigned long)vaddr, size >> PAGE_SHIFT);
}
+static void __init sme_clear_pgd(pgd_t *pgd_base, unsigned long start,
+unsigned long end)
+{
+ unsigned long pgd_start, pgd_end, pgd_size;
+ pgd_t *pgd_p;
+
+ pgd_start = start & PGDIR_MASK;
+ pgd_end = end & PGDIR_MASK;
+
+ pgd_size = (((pgd_end - pgd_start) / PGDIR_SIZE) + 1);
+ pgd_size *= sizeof(pgd_t);
+
+ pgd_p = pgd_base + pgd_index(start);
+
+ memset(pgd_p, 0, pgd_size);
+}
+
+#ifndef CONFIG_X86_5LEVEL
+#define native_make_p4d(_x)(p4d_t) { .pgd = native_make_pgd(_x) }
+#endif
Huh, why isn't this in arch/x86/include/asm/pgtable_types.h in the #else
branch of #if CONFIG_PGTABLE_LEVELS > 4 ?
Normally the __p4d() macro would be used and that would be ok whether
CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the
paravirt ops path I have to use native_make_p4d(). I'd be the only user
of the function and thought it would be best to localize it this way.
Also
ERROR: Macros with complex values should be enclosed in parentheses
#105: FILE: arch/x86/mm/mem_encrypt.c:232:
+#define native_make_p4d(_x)(p4d_t) { .pgd = native_make_pgd(_x) }
so why isn't it a function?
I can define it as an inline function.
+
+#define PGD_FLAGS _KERNPG_TABLE_NOENC
+#define P4D_FLAGS _KERNPG_TABLE_NOENC
+#define PUD_FLAGS _KERNPG_TABLE_NOENC
+#define PMD_FLAGS (__PAGE_KERNEL_LARGE_EXEC & ~_PAGE_GLOBAL)
+
+static void __init *sme_populate_pgd(pgd_t *pgd_base, void *pgtable_area,
+unsigned long vaddr, pmdval_t pmd_val)
+{
+ pgd_t *pgd_p;
+ p4d_t *p4d_p;
+ pud_t *pud_p;
+ pmd_t *pmd_p;
+
+ pgd_p = pgd_base + pgd_index(vaddr);
+ if (native_pgd_val(*pgd_p)) {
+ if (IS_ENABLED(CONFIG_X86_5LEVEL))
Err, I don't understand: so this is a Kconfig symbol and when it is
enabled at build time, you do a 5level pagetable.
But you can't stick a 5level pagetable to a hardware which doesn't know
about it.
True, 5-level will only be turned on for specific hardware which is why
I originally had this as only 4-level pagetables. But in a comment from
you back on the v5 version you said it needed to support 5-level. I
guess we should have discussed this more, but I also thought that should
our hardware ever support 5-level paging in the future then this would
be good to go.
Or do you mean that p4d layer folding at runtime to happen? (I admit, I
haven't looked at that in detail.) But then I'd hope that the generic
macros/functions would give you the ability to not care whether we have
a p4d or not and not add a whole bunch of ifdeffery to this c
Re: [PATCH 0/3] Enable namespaced file capabilities
James Bottomley writes: > On Thu, 2017-06-22 at 18:36 -0500, Serge E. Hallyn wrote: >> Quoting James Bottomley (james.bottom...@hansenpartnership.com): >> > On Thu, 2017-06-22 at 14:59 -0400, Stefan Berger wrote: >> > > This series of patches primary goal is to enable file >> > > capabilities in user namespaces without affecting the file >> > > capabilities that are effective on the host. This is to prevent >> > > that any unprivileged user on the host maps his own uid to root >> > > in a private namespace, writes the xattr, and executes the file >> > > with privilege on the host. >> > > >> > > We achieve this goal by writing extended attributes with a >> > > different name when a user namespace is used. If for example the >> > > root user in a user namespace writes the security.capability >> > > xattr, the name of the xattr that is actually written is encoded >> > > as security.capability@uid=1000 for root mapped to uid 1000 on >> > > the host. When listing the xattrs on the host, the existing >> > > security.capability as well as the security.capability@uid=1000 >> > > will be shown. Inside the namespace only 'security.capability', >> > > with the value of security.capability@uid=1000, is visible. >> > >> > I'm a bit bothered by the @uid=1000 suffix. What if I want to use >> > this capability but am dynamically mapping the namespaces (i.e. I >> > know I want unprivileged root, but I'm going to dynamically select >> > the range to map based on what's currently available on the >> > orchestration system). If we stick with the @uid=X suffix, then >> > dynamic mapping won't work because X is potentially different each >> > time and there'll be a name mismatch in my xattrs. Why not just >> > make the suffix @uid, which means if root is mapped to any >> > unprivileged uid then we pick this up otherwise we go with the >> > unsuffixed property? >> > >> > As far as I can see there's no real advantage to discriminating >> > userns specific xattrs based on where root is mapped to, unless >> > there's a use case I'm missing? >> >> Yes, the use case is: to allow root in the container to set the >> privilege itself, without endangering any resources not owned by >> that root. > > OK, so you envisage the same filesystem being mounted in different user > namespaces and being able to see their own value for the xattr. It > still seems a bit weird that they'd be able to change file contents and > have that seen by the other userns but not xattrs. When you dynamically talk about selecting a range based what is currently available in an orchestration system I don't know exactly what you mean. If it is something like what adduser does, assigning a container a persistent association with uids and gids, that makes sense to me. If it is picking an association just for the lifetime of the conainer processes it makes me nervous. Fundamentally storage is persistent and writing data into it is persistent. Which means that when dealing with storage we need to make things safe by default and not depend upon an assumption that the container tools carefully keeps files separate from each other. >From previous conversations I am happy with and generally expect only a capability xattr per file. Even with one xattr of any type there is something appealing about putting the logic that limits that xattr to a namespace in the name. As that is trivially backwards compatible. As that does not require reving the on disk file format based upon containers. >> As you say a @uid to say "any unprivileged userns" might be useful. >> The implication is that root on the host doesn't trust the image >> enough to write a real global file capability, but trusts it enough >> to 'endanger' all containers on the host. If that's the case, I have >> no objection to adding this as a feature. > > Yes, precisely. The filesystem is certified as permitted to override > the xattr whatever unprivileged mapping for root is in place. > > How would we effect the switch? I suppose some global flag because I > can't see we'd be mixing use cases in a physical system. Mixing use cases in a filesystem almost always happens. At least if we are talking an ordinary multi-user system. Multi-user systems are rarer than they once were because machines are cheap, and security is hard, but that should be what we are designing for. Anything else is just asking for trouble. James when you talk about a global flag and mixing use cases in a physical system it sounds a lot like you are talking about a base filesystem for shiftfs. My gut feel is that if this gets down to something like the shiftfs use case. I would assume either everything is shifted slightly so that all uids are say shifted by 100,000 even the capability names of the capability xattrs. So that shiftfs or some part of the vfs would need to shift the names of the xattrs as well. Certainly I expect filesystems that are mounted with s_user_ns != &init_user_ns to be shiftin
Re: [PATCH 1/4] ARM: exynos_defconfig: Enable Bluetooth, mac80211, NFC and more USB drivers
Hi Krzysztof, On 22 June 2017 at 00:46, Krzysztof Kozlowski wrote: > Enable useful, but not essential, stacks and drivers as modules: > - Bluetooth, > - mac80211, > - NFC, > - some USB network adapters, > - USB storage, > - additional USB devices (printers etc). > > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm/configs/exynos_defconfig | 57 > ++- > 1 file changed, 56 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 25325ed9319e..e6a976f5305c 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -48,7 +48,43 @@ CONFIG_IP_PNP=y > CONFIG_IP_PNP_DHCP=y > CONFIG_IP_PNP_BOOTP=y > CONFIG_IP_PNP_RARP=y > +CONFIG_BT=m > +CONFIG_BT_RFCOMM=m > +CONFIG_BT_RFCOMM_TTY=y > +CONFIG_BT_BNEP=m > +CONFIG_BT_BNEP_MC_FILTER=y > +CONFIG_BT_BNEP_PROTO_FILTER=y > +CONFIG_BT_HIDP=m > +CONFIG_BT_LEDS=y > +CONFIG_BT_HCIBTUSB=m > +CONFIG_BT_HCIBTSDIO=m > +CONFIG_BT_HCIUART=m > +CONFIG_BT_HCIUART_BCSP=y > +CONFIG_BT_HCIUART_ATH3K=y > +CONFIG_BT_HCIUART_3WIRE=y > +CONFIG_BT_HCIUART_INTEL=y > +CONFIG_BT_HCIUART_BCM=y > +CONFIG_BT_HCIUART_QCA=y > +CONFIG_BT_HCIUART_AG6XX=y > +CONFIG_BT_HCIUART_MRVL=y > +CONFIG_BT_HCIBCM203X=m > +CONFIG_BT_HCIBPA10X=m > +CONFIG_BT_HCIBFUSB=m > +CONFIG_BT_HCIVHCI=m > +CONFIG_BT_MRVL=m > +CONFIG_BT_MRVL_SDIO=m > +CONFIG_BT_ATH3K=m > CONFIG_CFG80211=y > +CONFIG_MAC80211=y > +CONFIG_MAC80211_LEDS=y > +CONFIG_NFC=y > +CONFIG_NFC_DIGITAL=m > +CONFIG_NFC_NCI=y > +CONFIG_NFC_NCI_SPI=m > +CONFIG_NFC_NCI_UART=m > +CONFIG_NFC_HCI=m > +CONFIG_NFC_SHDLC=y > +CONFIG_NFC_S3FWRN5_I2C=y > CONFIG_DEVTMPFS=y > CONFIG_DEVTMPFS_MOUNT=y > CONFIG_DMA_CMA=y > @@ -65,7 +101,9 @@ CONFIG_BLK_DEV_DM=y > CONFIG_DM_CRYPT=m > CONFIG_NETDEVICES=y > CONFIG_SMSC911X=y > +CONFIG_USB_RTL8150=m > CONFIG_USB_RTL8152=y > +CONFIG_USB_LAN78XX=m > CONFIG_USB_USBNET=y > CONFIG_USB_NET_SMSC75XX=y > CONFIG_USB_NET_SMSC95XX=y > @@ -189,7 +227,25 @@ CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_EXYNOS=y > CONFIG_USB_OHCI_HCD=y > CONFIG_USB_OHCI_EXYNOS=y > +CONFIG_USB_ACM=m > +CONFIG_USB_PRINTER=m > +CONFIG_USB_WDM=m > +CONFIG_USB_TMC=m > CONFIG_USB_STORAGE=y > +CONFIG_USB_STORAGE_REALTEK=m > +CONFIG_USB_STORAGE_DATAFAB=m > +CONFIG_USB_STORAGE_FREECOM=m > +CONFIG_USB_STORAGE_ISD200=m > +CONFIG_USB_STORAGE_USBAT=m > +CONFIG_USB_STORAGE_SDDR09=m > +CONFIG_USB_STORAGE_SDDR55=m > +CONFIG_USB_STORAGE_JUMPSHOT=m > +CONFIG_USB_STORAGE_ALAUDA=m > +CONFIG_USB_STORAGE_ONETOUCH=m > +CONFIG_USB_STORAGE_KARMA=m > +CONFIG_USB_STORAGE_CYPRESS_ATACB=m > +CONFIG_USB_STORAGE_ENE_UB6250=m > +CONFIG_USB_UAS=m > CONFIG_USB_DWC3=y > CONFIG_USB_DWC2=y > CONFIG_USB_HSIC_USB3503=y > @@ -209,7 +265,6 @@ CONFIG_LEDS_GPIO=y > CONFIG_LEDS_PWM=y > CONFIG_LEDS_MAX77693=y > CONFIG_LEDS_MAX8997=y > -CONFIG_LEDS_TRIGGERS=y > CONFIG_LEDS_TRIGGER_HEARTBEAT=y > CONFIG_RTC_CLASS=y > CONFIG_RTC_DRV_MAX8997=y For whole series. Reviewed-by: Anand Moon Best Regards -Anand Moon
Re: [PATCH V3] tools/testing/selftests/sysctl: Add pre-check to the value of writes_strict
On 23 June 2017 at 23:55, Shuah Khan wrote:
> Hi Orson,
>
> On 06/22/2017 10:24 PM, Orson Zhai wrote:
>> Sysctl test will fail in some items if the value of /proc/sys/kernel
>> /sysctrl_writes_strict is 0 as the default value in kernel older than v4.5.
>>
>> Make this test more robust and compatible with older kernels by checking and
>> update sysctrl_writes_strict value and restore it when test is done.
>>
>> Signed-off-by: Orson Zhai
>> Reviewed-by: Sumit Semwal
>> Tested-by: Sumit Semwal
>
> This patch failed to apply on linux-kselftest next. Could you please
> rebase and send it.
No problem. I will do that with V4.
Orson
>
> thanks,
> -- Shuah
>
>> ---
>> tools/testing/selftests/sysctl/common_tests | 22 ++
>> tools/testing/selftests/sysctl/run_numerictests | 2 +-
>> tools/testing/selftests/sysctl/run_stringtests | 2 +-
>> 3 files changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/testing/selftests/sysctl/common_tests
>> b/tools/testing/selftests/sysctl/common_tests
>> index 17d534b1b7b4..dfb1fcfc3142 100644
>> --- a/tools/testing/selftests/sysctl/common_tests
>> +++ b/tools/testing/selftests/sysctl/common_tests
>> @@ -24,6 +24,14 @@ verify()
>> return 0
>> }
>>
>> +exit_test()
>> +{
>> + if [ ! -z ${old_strict} ]; then
>> + echo ${old_strict} > ${WRITES_STRICT}
>> + fi
>> + exit $rc
>> +}
>> +
>> trap 'set_orig; rm -f "${TEST_FILE}"' EXIT
>>
>> rc=0
>> @@ -63,6 +71,20 @@ else
>> echo "ok"
>> fi
>>
>> +echo -n "Checking write strict setting ... "
>> +WRITES_STRICT="${SYSCTL}/kernel/sysctl_writes_strict"
>> +if [ ! -e ${WRITES_STRICT} ]; then
>> + echo "FAIL, but skip in case of old kernel" >&2
>> +else
>> + old_strict=$(cat ${WRITES_STRICT})
>> + if [ "$old_strict" = "1" ]; then
>> + echo "ok"
>> + else
>> + echo "FAIL, strict value is 0 but force to 1 to continue" >&2
>> + echo "1" > ${WRITES_STRICT}
>> + fi
>> +fi
>> +
>> # Now that we've validated the sanity of "set_test" and "set_orig",
>> # we can use those functions to set starting states before running
>> # specific behavioral tests.
>> diff --git a/tools/testing/selftests/sysctl/run_numerictests
>> b/tools/testing/selftests/sysctl/run_numerictests
>> index 8510f93f2d14..e6e76c93d948 100755
>> --- a/tools/testing/selftests/sysctl/run_numerictests
>> +++ b/tools/testing/selftests/sysctl/run_numerictests
>> @@ -7,4 +7,4 @@ TEST_STR=$(( $ORIG + 1 ))
>>
>> . ./common_tests
>>
>> -exit $rc
>> +exit_test
>> diff --git a/tools/testing/selftests/sysctl/run_stringtests
>> b/tools/testing/selftests/sysctl/run_stringtests
>> index 90a9293d520c..857ec667fb02 100755
>> --- a/tools/testing/selftests/sysctl/run_stringtests
>> +++ b/tools/testing/selftests/sysctl/run_stringtests
>> @@ -74,4 +74,4 @@ else
>> echo "ok"
>> fi
>>
>> -exit $rc
>> +exit_test
>> --
>> 2.12.2
>>
>>
>
Re: [PATCH v7 36/36] x86/mm: Add support to make use of Secure Memory Encryption
On Fri, Jun 16, 2017 at 01:56:39PM -0500, Tom Lendacky wrote:
> Add support to check if SME has been enabled and if memory encryption
> should be activated (checking of command line option based on the
> configuration of the default state). If memory encryption is to be
> activated, then the encryption mask is set and the kernel is encrypted
> "in place."
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/mem_encrypt.h |6 ++-
> arch/x86/kernel/head64.c |4 +-
> arch/x86/mm/mem_encrypt.c | 86
> +++-
> 3 files changed, 90 insertions(+), 6 deletions(-)
...
> +/*
> + * Some SME functions run very early causing issues with the stack-protector
> + * support. Provide a way to turn off this support on a per-function basis.
> + */
> +#define SME_NOSTACKP __attribute__((__optimize__("no-stack-protector")))
__nostackp
just like the others in include/linux/compiler-gcc.h.
> +
> +static char sme_cmdline_arg[] __initdata = "mem_encrypt";
> +static char sme_cmdline_on[] __initdata = "on";
> +static char sme_cmdline_off[] __initdata = "off";
>
> /*
> * Since SME related variables are set early in the boot process they must
> @@ -200,6 +215,8 @@ void __init mem_encrypt_init(void)
>
> /* Call into SWIOTLB to update the SWIOTLB DMA buffers */
> swiotlb_update_mem_attributes();
> +
> + pr_info("AMD Secure Memory Encryption (SME) active\n");
> }
>
> void swiotlb_set_mem_attributes(void *vaddr, unsigned long size)
> @@ -527,8 +544,73 @@ void __init sme_encrypt_kernel(void)
> native_write_cr3(__native_read_cr3());
> }
>
> -void __init sme_enable(void)
> +void __init SME_NOSTACKP sme_enable(struct boot_params *bp)
> {
> + const char *cmdline_ptr, *cmdline_arg, *cmdline_on, *cmdline_off;
> + unsigned int eax, ebx, ecx, edx;
> + bool active_by_default;
> + unsigned long me_mask;
> + char buffer[16];
> + u64 msr;
> +
> + /* Check for the SME support leaf */
> + eax = 0x8000;
> + ecx = 0;
> + native_cpuid(&eax, &ebx, &ecx, &edx);
> + if (eax < 0x801f)
> + return;
> +
> + /*
> + * Check for the SME feature:
> + * CPUID Fn8000_001F[EAX] - Bit 0
> + * Secure Memory Encryption support
> + * CPUID Fn8000_001F[EBX] - Bits 5:0
> + * Pagetable bit position used to indicate encryption
> + */
> + eax = 0x801f;
> + ecx = 0;
> + native_cpuid(&eax, &ebx, &ecx, &edx);
> + if (!(eax & 1))
> + return;
> +
> + me_mask = 1UL << (ebx & 0x3f);
> +
> + /* Check if SME is enabled */
> + msr = __rdmsr(MSR_K8_SYSCFG);
> + if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
> + return;
> +
> + /*
> + * Fixups have not been applied to phys_base yet and we're running
> + * identity mapped, so we must obtain the address to the SME command
> + * line argument data using rip-relative addressing.
> + */
> + asm ("lea sme_cmdline_arg(%%rip), %0"
> + : "=r" (cmdline_arg)
> + : "p" (sme_cmdline_arg));
> + asm ("lea sme_cmdline_on(%%rip), %0"
> + : "=r" (cmdline_on)
> + : "p" (sme_cmdline_on));
> + asm ("lea sme_cmdline_off(%%rip), %0"
> + : "=r" (cmdline_off)
> + : "p" (sme_cmdline_off));
> +
> + if (IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT))
> + active_by_default = true;
> + else
> + active_by_default = false;
> +
> + cmdline_ptr = (const char *)((u64)bp->hdr.cmd_line_ptr |
> + ((u64)bp->ext_cmd_line_ptr << 32));
> +
> + cmdline_find_option(cmdline_ptr, cmdline_arg, buffer, sizeof(buffer));
> +
> + if (strncmp(buffer, cmdline_on, sizeof(buffer)) == 0)
if (!strncmp(...
> + sme_me_mask = me_mask;
> + else if (strncmp(buffer, cmdline_off, sizeof(buffer)) == 0)
else if (!strncmp(...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH net-next 1/2] ipmr: restrict mroute "queue full" warning to related error values
From: Julien Gomes Date: Wed, 21 Jun 2017 10:58:10 -0700 > When sending a cache report on mroute_sk, mroute will emit a > "pending queue full" warning for every error value returned by > sock_queue_rcv_skb(). > This warning can be misleading, for example on the EPERM error value > that sk_filter() can return. > > Restricting this warning to only ENOMEM or ENOBUFS seems more > appropriate. > > Signed-off-by: Julien Gomes Incorrect, no other error codes are possible. We never attach a socket filter to these kernel internal sockets, therefore sk_filter() is not even applicable in this analysis. Therefore, -ENOBUFS and -ENOMEM are the only errors we can ever see returned from sock_queue_rcv_skb(). This goes for your second patch as well.
Re: [PATCH 0/3] Enable namespaced file capabilities
On 06/23/2017 01:07 PM, James Bottomley wrote: On Fri, 2017-06-23 at 11:30 -0500, Serge E. Hallyn wrote: Quoting Casey Schaufler (ca...@schaufler-ca.com): Or maybe just security.ns.capability, taking James' comment into account. That last one may be suitable as an option, useful for his particular (somewhat barbaric :) use case, but it's not ok for the general solution. If uid 1000 was delegated the subuids 10-19, it should be able to write a file capability for use by his subuids, but that file capability must not apply to other subuids. I don't think it's barbaric, I think it's the common use case. Let me give a more comprehensible answer in terms of docker and IMA. Lets suppose I'm running docker locally and in a test cloud both with userns enabled. I build an image locally, mapping my uid (1000) to root. If I begin with a standard base, each of the files has a security.ima signature. Now I add my layer, which involves updating a file, so I need to write a new signature to security.ima. Because I'm running user namespaced, the update gets written at security.ima@uid=1000 when I do a docker save. Now supposing I deploy that image to a cloud. As a tenant, the cloud gives me real uid 4531 and maps that to root. Execution of the binary fails because it tries to use the underlying signature (in security.ima) as there is no xattr named security.ima@uid=4531 Yes. An answer would be to have Docker rewrite these on the fly. It knows what uid the container was running as and specifically looks for security.ima@uid=1000 or security.ima, takes the former if it finds, otherwise the latter or nothing. Stefan So my essential point is that building the real kuid into the permanent record of the xattr damages image portability, which is touted as one of the real advantages of container images. James
Re: [PATCH v3] vsprintf: Add %p extension "%pOF" for device tree
On Fri, 2017-06-23 at 12:30 -0500, Rob Herring wrote:
> From: Pantelis Antoniou
>
> 90% of the usage of device node's full_name is printing it out in a
> kernel message. However, storing the full path for every node is
> wasteful and redundant. With a custom format specifier, we can generate
> the full path at run-time and eventually remove the full path from every
> node.
>
> For instance typical use is:
> pr_info("Frobbing node %s\n", node->full_name);
>
> Which can be written now as:
> pr_info("Frobbing node %pOF\n", node);
>
> '%pO' is the base specifier to represent kobjects with '%pOF'
> representing struct device_node. Currently, struct device_node is the
> only supported type of kobject.
>
> More fine-grained control of formatting includes printing the name,
> flags, path-spec name and others, explained in the documentation entry.
>
> Originally written by Pantelis, but pretty much rewrote the core
> function using existing string/number functions. The 2 passes were
> unnecessary and have been removed. Also, updated the checkpatch.pl
> check. The unittest code was written by Grant Likely.
>
> Signed-off-by: Pantelis Antoniou
> Signed-off-by: Rob Herring
> ---
> v3:
> - Fix missing documentation updates using '%pOF' as the device_node
> specifier.
> - Update the commit msg and documentation to clearly define '%pO' is the
> base specifier for kobjects.
> - Rework device_node_gen_full_name() to avoid creating an array of node
> pointers on the stack.
Thanks Rob.
This all seems sensible to me now.
If you want:
Acked-by: Joe Perches
cheers, Joe
[PATCH net-next 3/4] net: bcmgenet: Remove special handling of "internal" phy-mode
The PHY library now supports an "internal" phy-mode, thus making our
custom parsing code now unnecessary.
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/broadcom/genet/bcmmii.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c
b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index 285676f8da6b..071fcbd14e6a 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -251,11 +251,8 @@ int bcmgenet_mii_config(struct net_device *dev)
priv->ext_phy = !priv->internal_phy &&
(priv->phy_interface != PHY_INTERFACE_MODE_MOCA);
- if (priv->internal_phy)
- priv->phy_interface = PHY_INTERFACE_MODE_NA;
-
switch (priv->phy_interface) {
- case PHY_INTERFACE_MODE_NA:
+ case PHY_INTERFACE_MODE_INTERNAL:
case PHY_INTERFACE_MODE_MOCA:
/* Irrespective of the actually configured PHY speed (100 or
* 1000) GENETv4 only has an internal GPHY so we will just end
@@ -471,7 +468,6 @@ static int bcmgenet_mii_of_init(struct bcmgenet_priv *priv)
{
struct device_node *dn = priv->pdev->dev.of_node;
struct device *kdev = &priv->pdev->dev;
- const char *phy_mode_str = NULL;
struct phy_device *phydev = NULL;
char *compat;
int phy_mode;
@@ -510,23 +506,19 @@ static int bcmgenet_mii_of_init(struct bcmgenet_priv
*priv)
/* Get the link mode */
phy_mode = of_get_phy_mode(dn);
+ if (phy_mode < 0) {
+ dev_err(kdev, "invalid PHY mode property\n");
+ return phy_mode;
+ }
+
priv->phy_interface = phy_mode;
/* We need to specifically look up whether this PHY interface is
internal
* or not *before* we even try to probe the PHY driver over MDIO as we
* may have shut down the internal PHY for power saving purposes.
*/
- if (phy_mode < 0) {
- ret = of_property_read_string(dn, "phy-mode", &phy_mode_str);
- if (ret < 0) {
- dev_err(kdev, "invalid PHY mode property\n");
- return ret;
- }
-
- priv->phy_interface = PHY_INTERFACE_MODE_NA;
- if (!strcasecmp(phy_mode_str, "internal"))
- priv->internal_phy = true;
- }
+ if (priv->phy_interface == PHY_INTERFACE_MODE_INTERNAL)
+ priv->internal_phy = true;
/* Make sure we initialize MoCA PHYs with a link down */
if (phy_mode == PHY_INTERFACE_MODE_MOCA) {
--
2.9.3
Re: [PATCH net-next 0/4] net: phy: Support "internal" PHY interface
On 06/23/2017 10:33 AM, Florian Fainelli wrote: > Hi all, > > This makes the "internal" phy-mode property generally available and > documented and this allows us to remove some custom parsing code > we had for bcmgenet and bcm_sf2 which both used that specific value. Sorry for the resend, this is net-next material. > > Florian Fainelli (4): > dt-bindings: Add "internal" as a valid 'phy-mode' property > net: phy: Support "internal" PHY interface > net: bcmgenet: Remove special handling of "internal" phy-mode > net: dsa: bcm_sf2: Remove special handling of "internal" phy-mode > > Documentation/devicetree/bindings/net/ethernet.txt | 1 + > drivers/net/dsa/bcm_sf2.c | 16 +-- > drivers/net/ethernet/broadcom/genet/bcmmii.c | 24 > -- > include/linux/phy.h| 3 +++ > 4 files changed, 17 insertions(+), 27 deletions(-) > -- Florian
Re: [PATCH] PATCH v3 Convert multiple netdev_info messages to netdev_dbg
From: Michael J Dilmore Date: Wed, 21 Jun 2017 03:08:54 +0100 > The bond_options.c file contains multiple netdev_info messages that > clutter kernel output. This patches replaces these with netdev_dbg messages > and adds a netdev_dbg for packets for slave. > > Signed-off-by: Michael J Dilmore > Suggested-by: Joe Perches This falls under the category of "very low quality patch submission" I'm afraid. First of all your Subject lines need to be done more properly. Puting "PATCH" twice in there is pointless, just once inside of the brackets is enough. The "v3" belongs inside of the brackets too. Seriously, just look at how other developer format their Subject lines on this mailing list, and you are less likely to go wrong. Doing thing your own unique way is asking for trouble. But more importantly, your commit log message says you are converting netdev_info calls into netdev_dbg ones, but that is not at all what this patch does. > netdev_dbg(bond->dev, "%s mode is incompatible with arp > monitoring, start mii monitoring\n", > - newval->string); > +newval->string); You're simply adjusting indentation of the code. There are no "conversions" going on here at all.
[PATCH net-next 4/4] net: dsa: bcm_sf2: Remove special handling of "internal" phy-mode
The PHY library now supports an "internal" phy-mode, thus making our
custom parsing code now unnecessary.
Signed-off-by: Florian Fainelli
---
drivers/net/dsa/bcm_sf2.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 76e98e8ed315..648f91b58d1e 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -498,10 +498,8 @@ static void bcm_sf2_identify_ports(struct bcm_sf2_priv
*priv,
struct device_node *dn)
{
struct device_node *port;
- const char *phy_mode_str;
int mode;
unsigned int port_num;
- int ret;
priv->moca_port = -1;
@@ -515,15 +513,11 @@ static void bcm_sf2_identify_ports(struct bcm_sf2_priv
*priv,
* time
*/
mode = of_get_phy_mode(port);
- if (mode < 0) {
- ret = of_property_read_string(port, "phy-mode",
- &phy_mode_str);
- if (ret < 0)
- continue;
-
- if (!strcasecmp(phy_mode_str, "internal"))
- priv->int_phy_mask |= 1 << port_num;
- }
+ if (mode < 0)
+ continue;
+
+ if (mode == PHY_INTERFACE_MODE_INTERNAL)
+ priv->int_phy_mask |= 1 << port_num;
if (mode == PHY_INTERFACE_MODE_MOCA)
priv->moca_port = port_num;
--
2.9.3
[PATCH net-next 2/4] net: phy: Support "internal" PHY interface
Now that the Device Tree binding has been updated, update the PHY
library phy_interface_t and phy_modes to support the "internal" PHY
interface type.
Signed-off-by: Florian Fainelli
---
include/linux/phy.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 23d2e46dd322..1d8d70193782 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -64,6 +64,7 @@
/* Interface Mode definitions */
typedef enum {
PHY_INTERFACE_MODE_NA,
+ PHY_INTERFACE_MODE_INTERNAL,
PHY_INTERFACE_MODE_MII,
PHY_INTERFACE_MODE_GMII,
PHY_INTERFACE_MODE_SGMII,
@@ -114,6 +115,8 @@ static inline const char *phy_modes(phy_interface_t
interface)
switch (interface) {
case PHY_INTERFACE_MODE_NA:
return "";
+ case PHY_INTERFACE_MODE_INTERNAL:
+ return "internal";
case PHY_INTERFACE_MODE_MII:
return "mii";
case PHY_INTERFACE_MODE_GMII:
--
2.9.3
[PATCH net-next 1/4] dt-bindings: Add "internal" as a valid 'phy-mode' property
A number of Ethernet MACs have internal Ethernet PHYs and the internal wiring makes it so that this knowledge needs to be available using the standard 'phy-mode' property. Signed-off-by: Florian Fainelli --- Documentation/devicetree/bindings/net/ethernet.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt index d4abe9a98109..edd7fd2bbbf9 100644 --- a/Documentation/devicetree/bindings/net/ethernet.txt +++ b/Documentation/devicetree/bindings/net/ethernet.txt @@ -11,6 +11,7 @@ The following properties are common to the Ethernet controllers: the maximum frame size (there's contradiction in ePAPR). - phy-mode: string, operation mode of the PHY interface. This is now a de-facto standard property; supported values are: + * "internal" * "mii" * "gmii" * "sgmii" -- 2.9.3
[PATCH 1/4] dt-bindings: Add "internal" as a valid 'phy-mode' property
A number of Ethernet MACs have internal Ethernet PHYs and the internal wiring makes it so that this knowledge needs to be available using the standard 'phy-mode' property. Signed-off-by: Florian Fainelli --- Documentation/devicetree/bindings/net/ethernet.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt index d4abe9a98109..edd7fd2bbbf9 100644 --- a/Documentation/devicetree/bindings/net/ethernet.txt +++ b/Documentation/devicetree/bindings/net/ethernet.txt @@ -11,6 +11,7 @@ The following properties are common to the Ethernet controllers: the maximum frame size (there's contradiction in ePAPR). - phy-mode: string, operation mode of the PHY interface. This is now a de-facto standard property; supported values are: + * "internal" * "mii" * "gmii" * "sgmii" -- 2.9.3
[PATCH net-next 0/4] net: phy: Support "internal" PHY interface
Hi all, This makes the "internal" phy-mode property generally available and documented and this allows us to remove some custom parsing code we had for bcmgenet and bcm_sf2 which both used that specific value. Florian Fainelli (4): dt-bindings: Add "internal" as a valid 'phy-mode' property net: phy: Support "internal" PHY interface net: bcmgenet: Remove special handling of "internal" phy-mode net: dsa: bcm_sf2: Remove special handling of "internal" phy-mode Documentation/devicetree/bindings/net/ethernet.txt | 1 + drivers/net/dsa/bcm_sf2.c | 16 +-- drivers/net/ethernet/broadcom/genet/bcmmii.c | 24 -- include/linux/phy.h| 3 +++ 4 files changed, 17 insertions(+), 27 deletions(-) -- 2.9.3
[PATCH 3/4] net: bcmgenet: Remove special handling of "internal" phy-mode
The PHY library now supports an "internal" phy-mode, thus making our
custom parsing code now unnecessary.
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/broadcom/genet/bcmmii.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c
b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index 285676f8da6b..071fcbd14e6a 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -251,11 +251,8 @@ int bcmgenet_mii_config(struct net_device *dev)
priv->ext_phy = !priv->internal_phy &&
(priv->phy_interface != PHY_INTERFACE_MODE_MOCA);
- if (priv->internal_phy)
- priv->phy_interface = PHY_INTERFACE_MODE_NA;
-
switch (priv->phy_interface) {
- case PHY_INTERFACE_MODE_NA:
+ case PHY_INTERFACE_MODE_INTERNAL:
case PHY_INTERFACE_MODE_MOCA:
/* Irrespective of the actually configured PHY speed (100 or
* 1000) GENETv4 only has an internal GPHY so we will just end
@@ -471,7 +468,6 @@ static int bcmgenet_mii_of_init(struct bcmgenet_priv *priv)
{
struct device_node *dn = priv->pdev->dev.of_node;
struct device *kdev = &priv->pdev->dev;
- const char *phy_mode_str = NULL;
struct phy_device *phydev = NULL;
char *compat;
int phy_mode;
@@ -510,23 +506,19 @@ static int bcmgenet_mii_of_init(struct bcmgenet_priv
*priv)
/* Get the link mode */
phy_mode = of_get_phy_mode(dn);
+ if (phy_mode < 0) {
+ dev_err(kdev, "invalid PHY mode property\n");
+ return phy_mode;
+ }
+
priv->phy_interface = phy_mode;
/* We need to specifically look up whether this PHY interface is
internal
* or not *before* we even try to probe the PHY driver over MDIO as we
* may have shut down the internal PHY for power saving purposes.
*/
- if (phy_mode < 0) {
- ret = of_property_read_string(dn, "phy-mode", &phy_mode_str);
- if (ret < 0) {
- dev_err(kdev, "invalid PHY mode property\n");
- return ret;
- }
-
- priv->phy_interface = PHY_INTERFACE_MODE_NA;
- if (!strcasecmp(phy_mode_str, "internal"))
- priv->internal_phy = true;
- }
+ if (priv->phy_interface == PHY_INTERFACE_MODE_INTERNAL)
+ priv->internal_phy = true;
/* Make sure we initialize MoCA PHYs with a link down */
if (phy_mode == PHY_INTERFACE_MODE_MOCA) {
--
2.9.3
[PATCH 0/4] net: phy: Support "internal" PHY interface
Hi all, This makes the "internal" phy-mode property generally available and documented and this allows us to remove some custom parsing code we had for bcmgenet and bcm_sf2 which both used that specific value. Florian Fainelli (4): dt-bindings: Add "internal" as a valid 'phy-mode' property net: phy: Support "internal" PHY interface net: bcmgenet: Remove special handling of "internal" phy-mode net: dsa: bcm_sf2: Remove special handling of "internal" phy-mode Documentation/devicetree/bindings/net/ethernet.txt | 1 + drivers/net/dsa/bcm_sf2.c | 16 +-- drivers/net/ethernet/broadcom/genet/bcmmii.c | 24 -- include/linux/phy.h| 3 +++ 4 files changed, 17 insertions(+), 27 deletions(-) -- 2.9.3
[PATCH 4/4] net: dsa: bcm_sf2: Remove special handling of "internal" phy-mode
The PHY library now supports an "internal" phy-mode, thus making our
custom parsing code now unnecessary.
Signed-off-by: Florian Fainelli
---
drivers/net/dsa/bcm_sf2.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 76e98e8ed315..648f91b58d1e 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -498,10 +498,8 @@ static void bcm_sf2_identify_ports(struct bcm_sf2_priv
*priv,
struct device_node *dn)
{
struct device_node *port;
- const char *phy_mode_str;
int mode;
unsigned int port_num;
- int ret;
priv->moca_port = -1;
@@ -515,15 +513,11 @@ static void bcm_sf2_identify_ports(struct bcm_sf2_priv
*priv,
* time
*/
mode = of_get_phy_mode(port);
- if (mode < 0) {
- ret = of_property_read_string(port, "phy-mode",
- &phy_mode_str);
- if (ret < 0)
- continue;
-
- if (!strcasecmp(phy_mode_str, "internal"))
- priv->int_phy_mask |= 1 << port_num;
- }
+ if (mode < 0)
+ continue;
+
+ if (mode == PHY_INTERFACE_MODE_INTERNAL)
+ priv->int_phy_mask |= 1 << port_num;
if (mode == PHY_INTERFACE_MODE_MOCA)
priv->moca_port = port_num;
--
2.9.3
[PATCH 2/4] net: phy: Support "internal" PHY interface
Now that the Device Tree binding has been updated, update the PHY
library phy_interface_t and phy_modes to support the "internal" PHY
interface type.
Signed-off-by: Florian Fainelli
---
include/linux/phy.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 23d2e46dd322..1d8d70193782 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -64,6 +64,7 @@
/* Interface Mode definitions */
typedef enum {
PHY_INTERFACE_MODE_NA,
+ PHY_INTERFACE_MODE_INTERNAL,
PHY_INTERFACE_MODE_MII,
PHY_INTERFACE_MODE_GMII,
PHY_INTERFACE_MODE_SGMII,
@@ -114,6 +115,8 @@ static inline const char *phy_modes(phy_interface_t
interface)
switch (interface) {
case PHY_INTERFACE_MODE_NA:
return "";
+ case PHY_INTERFACE_MODE_INTERNAL:
+ return "internal";
case PHY_INTERFACE_MODE_MII:
return "mii";
case PHY_INTERFACE_MODE_GMII:
--
2.9.3
Re: [PATCH net] net: account for current skb length when deciding about UFO
From: Michal Kubecek
Date: Mon, 19 Jun 2017 13:03:43 +0200 (CEST)
> Our customer encountered stuck NFS writes for blocks starting at specific
> offsets w.r.t. page boundary caused by networking stack sending packets via
> UFO enabled device with wrong checksum. The problem can be reproduced by
> composing a long UDP datagram from multiple parts using MSG_MORE flag:
>
> sendto(sd, buff, 1000, MSG_MORE, ...);
> sendto(sd, buff, 1000, MSG_MORE, ...);
> sendto(sd, buff, 3000, 0, ...);
>
> Assume this packet is to be routed via a device with MTU 1500 and
> NETIF_F_UFO enabled. When second sendto() gets into __ip_append_data(),
> this condition is tested (among others) to decide whether to call
> ip_ufo_append_data():
>
> ((length + fragheaderlen) > mtu) || (skb && skb_is_gso(skb))
>
> At the moment, we already have skb with 1028 bytes of data which is not
> marked for GSO so that the test is false (fragheaderlen is usually 20).
> Thus we append second 1000 bytes to this skb without invoking UFO. Third
> sendto(), however, has sufficient length to trigger the UFO path so that we
> end up with non-UFO skb followed by a UFO one. Later on, udp_send_skb()
> uses udp_csum() to calculate the checksum but that assumes all fragments
> have correct checksum in skb->csum which is not true for UFO fragments.
>
> When checking against MTU, we need to add skb->len to length of new segment
> if we already have a partially filled skb and fragheaderlen only if there
> isn't one.
>
> In the IPv6 case, skb can only be null if this is the first segment so that
> we have to use headersize (length of the first IPv6 header) rather than
> fragheaderlen (length of IPv6 header of further fragments) for skb == NULL.
>
> Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach")
> Fixes: e4c5e13aa45c ("ipv6: Should use consistent conditional judgement for
> ip6 fragment between __ip6_append_data and ip6_finish_output")
> Signed-off-by: Michal Kubecek
Applied and queued up for -stable, thanks.
[PATCH v3] vsprintf: Add %p extension "%pOF" for device tree
From: Pantelis Antoniou
90% of the usage of device node's full_name is printing it out in a
kernel message. However, storing the full path for every node is
wasteful and redundant. With a custom format specifier, we can generate
the full path at run-time and eventually remove the full path from every
node.
For instance typical use is:
pr_info("Frobbing node %s\n", node->full_name);
Which can be written now as:
pr_info("Frobbing node %pOF\n", node);
'%pO' is the base specifier to represent kobjects with '%pOF'
representing struct device_node. Currently, struct device_node is the
only supported type of kobject.
More fine-grained control of formatting includes printing the name,
flags, path-spec name and others, explained in the documentation entry.
Originally written by Pantelis, but pretty much rewrote the core
function using existing string/number functions. The 2 passes were
unnecessary and have been removed. Also, updated the checkpatch.pl
check. The unittest code was written by Grant Likely.
Signed-off-by: Pantelis Antoniou
Signed-off-by: Rob Herring
---
v3:
- Fix missing documentation updates using '%pOF' as the device_node
specifier.
- Update the commit msg and documentation to clearly define '%pO' is the
base specifier for kobjects.
- Rework device_node_gen_full_name() to avoid creating an array of node
pointers on the stack.
v2:
- Change subject
- Rewrite device_node_gen_full_name() to avoid recursion.
- Avoid using sprintf.
- Add unittests Grant L. wrote.
- Drop ref count printing (from discussion 2 years ago).
- Remove fmtp local var.
Documentation/printk-formats.txt | 36 +++
drivers/of/unittest-data/tests-platform.dtsi | 4 +-
drivers/of/unittest.c| 58
lib/vsprintf.c | 135 +++
scripts/checkpatch.pl| 2 +-
5 files changed, 233 insertions(+), 2 deletions(-)
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 5962949944fd..619cdffa5d44 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -275,6 +275,42 @@ struct va_format:
Passed by reference.
+kobjects:
+ %pO
+
+ Base specifier for kobject based structs. Must be followed with
+ character for specific type of kobject as listed below:
+
+ Device tree nodes:
+
+ %pOF[fnpPcCF]
+
+ For printing device tree nodes. The optional arguments are:
+ f device node full_name
+ n device node name
+ p device node phandle
+ P device node path spec (name + @unit)
+ F device node flags
+ c major compatible string
+ C full compatible string
+ Without any arguments prints full_name (same as %pOFf)
+ The separator when using multiple arguments is ':'
+
+ Examples:
+
+ %pOF/foo/bar@0 - Node full name
+ %pOFf /foo/bar@0 - Same as above
+ %pOFfp /foo/bar@0:10 - Node full name + phandle
+ %pOFfcF /foo/bar@0:foo,device:--P- - Node full name +
+ major compatible string +
+ node flags
+ D - dynamic
+ d - detached
+ P - Populated
+ B - Populated bus
+
+ Passed by reference.
+
struct clk:
%pC pll1
diff --git a/drivers/of/unittest-data/tests-platform.dtsi
b/drivers/of/unittest-data/tests-platform.dtsi
index eb20eeb2b062..a0c93822aee3 100644
--- a/drivers/of/unittest-data/tests-platform.dtsi
+++ b/drivers/of/unittest-data/tests-platform.dtsi
@@ -26,7 +26,9 @@
#size-cells = <0>;
dev@100 {
- compatible = "test-sub-device";
+ compatible = "test-sub-device",
+"test-compat2",
+"test-compat3";
reg = <0x100>;
};
};
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 987a1530282a..8f611e9844db 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -239,6 +239,63 @@ static void __init of_unittest_check_tree_linkage(void)
pr_debug("allnodes list size (%i); sibling lists size (%i)\n",
allnode_count, child_count);
}
+static void __init of_unittest_printf_one(struct device_node *np, const char
*fmt,
+ const char *expected)
+{
+ char buf[strlen(expected)+10];
+ int size, i
Re: [PATCH 2/2] selftests/ftrace: Update multiple kprobes test for powerpc
On Thu, 22 Jun 2017 22:33:25 +0530
"Naveen N. Rao" wrote:
> On 2017/06/22 06:07PM, Masami Hiramatsu wrote:
> > On Thu, 22 Jun 2017 00:20:28 +0530
> > "Naveen N. Rao" wrote:
> >
> > > KPROBES_ON_FTRACE is only available on powerpc64le. Update comment to
> > > clarify this.
> > >
> > > Also, we should use an offset of 8 to ensure that the probe does not
> > > fall on ftrace location. The current offset of 4 will fall before the
> > > function local entry point and won't fire, while an offset of 12 or 16
> > > will fall on ftrace location. Offset 8 is currently guaranteed to not be
> > > the ftrace location.
> >
> > OK, these part seems good to me.
> >
> > >
> > > Finally, do not filter out symbols with a dot. Powerpc Elfv1 uses dot
> > > prefix for all functions and this prevents us from testing some of those
> > > symbols. Furthermore, with the patch to derive event names properly in
> > > the presence of ':' and '.', such names are accepted by kprobe_events
> > > and constitutes a good test for those symbols.
> >
> > Hmm, the reason why I added such filter was to avoid symbols including
> > gcc-generated suffixes like as .constprop or .isra etc.
>
> I see.
>
> I do wonder -- is there a problem if we try probing those symbols? On my
> local x86 vm, I don't see an issue probing it especially with the
> previous patch to enable probing with symbols having a '.' or ':'.
>
> Furthermore, since this is for testing kprobe_events, I feel it is good
> to try probing those symbols too to catch any weird errors we may hit.
Yes, and that is not what this testcase is aiming to. That testcase should
be a separated one, with correct error handling.
Thank you,
>
> Thanks for the review!
> - Naveen
>
>
> > So if the Powerpc Elfv1 use dot prefix, that is OK, in that case,
> > could you update the filter as "^.*\\..*" ?
> >
> > Thank you,
> >
> > >
> > > Signed-off-by: Naveen N. Rao
> > > ---
> > > tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc | 8
> > >
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git
> > > a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> > > b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> > > index f4d1ff785d67..d209c071b2c0 100644
> > > --- a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> > > +++ b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> > > @@ -2,16 +2,16 @@
> > > # description: Register/unregister many kprobe events
> > >
> > > # ftrace fentry skip size depends on the machine architecture.
> > > -# Currently HAVE_KPROBES_ON_FTRACE defined on x86 and powerpc
> > > +# Currently HAVE_KPROBES_ON_FTRACE defined on x86 and powerpc64le
> > > case `uname -m` in
> > >x86_64|i[3456]86) OFFS=5;;
> > > - ppc*) OFFS=4;;
> > > + ppc64le) OFFS=8;;
> > >*) OFFS=0;;
> > > esac
> > >
> > > echo "Setup up to 256 kprobes"
> > > -grep t /proc/kallsyms | cut -f3 -d" " | grep -v .*\\..* | \
> > > -head -n 256 | while read i; do echo p ${i}+${OFFS} ; done >
> > > kprobe_events ||:
> > > +grep t /proc/kallsyms | cut -f3 -d" " | head -n 256 | \
> > > +while read i; do echo p ${i}+${OFFS} ; done > kprobe_events ||:
> > >
> > > echo 1 > events/kprobes/enable
> > > echo 0 > events/kprobes/enable
> > > --
> > > 2.13.1
> > >
> >
> >
> > --
> > Masami Hiramatsu
> >
>
--
Masami Hiramatsu
Re: [PATCH 1/2] trace/kprobes: Sanitize derived event names
On Fri, 23 Jun 2017 00:33:45 +0530 "Naveen N. Rao" wrote: > On 2017/06/22 06:29PM, Masami Hiramatsu wrote: > > On Thu, 22 Jun 2017 00:20:27 +0530 > > "Naveen N. Rao" wrote: > > > > > When we derive event names, convert some expected symbols (such as ':' > > > used to specify module:name and '.' present in some symbols) into > > > underscores so that the event name is not rejected. > > > > Oops, ok, this is my mistake. > > > > Acked-by: Masami Hiramatsu > > > > This must be marked as bugfix for stable trees. > > > > Could you also add a testcase for this (module name) bug? > > > > MODNAME=`lsmod | head -n 2 | tail -n 1 | cut -f 1 -d " "` > > FUNCNAME=`grep -m 1 "\\[$MODNAME\\]" /proc/kallsyms | xargs | cut -f 3 -d " > > "` > > > > May gives you a target name :) > > Sure. Here is a test. > > Thanks for the review, > Naveen > > - > [PATCH] selftests/ftrace: Add a test to probe module functions > > Add a kprobes test to ensure that we are able to add a probe on a > module function using 'p :' format, without having to > specify a probe name. > > Suggested-by: Masami Hiramatsu > Signed-off-by: Naveen N. Rao Perfect! :) Acked-by: Masami Hiramatsu Thanks! > --- > .../testing/selftests/ftrace/test.d/kprobe/probe_module.tc | 14 > ++ > 1 file changed, 14 insertions(+) > create mode 100644 > tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc > > diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc > b/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc > new file mode 100644 > index ..ea7657041ba6 > --- /dev/null > +++ b/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc > @@ -0,0 +1,14 @@ > +#!/bin/sh > +# description: Kprobe dynamic event - probing module > + > +[ -f kprobe_events ] || exit_unsupported # this is configurable > + > +echo 0 > events/enable > +echo > kprobe_events > +export MOD=`lsmod | head -n 2 | tail -n 1 | cut -f1 -d" "` > +export FUNC=`grep -m 1 ".* t .*\\[$MOD\\]" /proc/kallsyms | xargs | cut -f3 > -d" "` > +[ "x" != "x$MOD" -a "y" != "y$FUNC" ] || exit_untested > +echo p $MOD:$FUNC > kprobe_events > +grep $MOD kprobe_events > +echo > kprobe_events > +clear_trace > -- > 2.13.1 > -- Masami Hiramatsu
Re: [PATCH 2/2] scripts/gdb: lx-dmesg: Use errors=replace for decoding
On Fri, 2017-06-23 at 18:02 +0200, Jan Kiszka wrote:
> On 2017-06-23 16:20, Leonard Crestez wrote:
> >
> > It is never desirable lx-dmesg to fail on string decoding errors,
> > not
> > even if the log buffer is corrupt.
> >
> > Signed-off-by: Leonard Crestez
> > ---
> > scripts/gdb/linux/dmesg.py | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/scripts/gdb/linux/dmesg.py
> > b/scripts/gdb/linux/dmesg.py
> > index 6f8d2b2..d0cac58 100644
> > --- a/scripts/gdb/linux/dmesg.py
> > +++ b/scripts/gdb/linux/dmesg.py
> > @@ -52,13 +52,13 @@ class LxDmesg(gdb.Command):
> > continue
> >
> > text_len = utils.read_u16(log_buf[pos + 10:pos + 12])
> > -text = log_buf[pos + 16:pos + 16 + text_len].decode()
> > +text = log_buf[pos + 16:pos + 16 +
> > text_len].decode(errors='replace')
> pep8 should complain.
>
> >
> > time_stamp = utils.read_u64(log_buf[pos:pos + 8])
> >
> > for line in text.splitlines():
> > gdb.write("[{time:12.6f}] {line}\n".format(
> > time=time_stamp / 10.0,
> > -line=line))
> > +line=line.encode(errors='replace')))
> You only talk about "decoding" in the commit log, but here you encode
> back. An short explanation why this is also needed would be nice.
>
Apparently .decode(errors='replace') will return an unicode string
where invalid characters are replaced with U+FFFD REPLACEMENT
CHARACTER. Attempting to encode that back to the default ascii encoding
of python2 throws an error, using errors='replace' results in a '?'
instead.
See: https://docs.python.org/2/library/codecs.html#codec-base-classes
In python3 the default encoding seems to be utf8 and errors='replace'
is not obviously required on the encode step.
I don't actually have a gdb version compiled with python3 support and
don't know if gdb.write always properly handles unicode in all cases.
Perhaps it might be better to also explicitly specify 'utf8' as the
encoding?
Linux does occasionally print unicode, for example the jffs2 driver
shows an copyright symbol at startup. Using errors='replace' everywhere
on python2 results in this output from lx-dmesg:
[0.367578] jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
In theory if we use decode('utf8', errors='replace') and encode('utf8')
then errors='replace' would not be required on the encode side.
Honestly for debug code it might be preferable to do the safest
possible thing and go 'ascii' everywhere.
--
Regards,
Leonard
RE: [PATCH V2 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter
Hi all, Any comments for the series? We had some users (from both client and server) reported spurious NMI watchdog timeouts issue. Now, there is a proposed workaround fix from tglx. We are testing it. However, this patch series is believed to be a real fix for the issue. It's better that the patch series can be merged into mainline. Here is the workaround fix, if you are interested. https://patchwork.kernel.org/patch/9803033/ https://patchwork.kernel.org/patch/9805903/ Thanks, Kan > > From: Kan Liang > > The dominant motivation is to make it possible to switch cycles NMI > watchdog to ref_cycles on x86 platform. The new NMI watchdog could > - Free widely used precious cycles fixed counter. For example, topdown >code needs the cycles fixed counter in group counting. Otherwise, >it has to fall back to not use groups, which can cause measurement >inaccuracy due to multiplexing errors. > - Avoiding the NMI watchdog expiring too fast. Cycles can tick faster >than the measured CPU Frequency due to Turbo mode. >Although we can enlarge the period of cycles to workaround the fast >expiring, it is still limited by the Turbo ratio and may fail >eventually. > > CPU ref_cycles can only be counted by fixed counter 2. It uses pseudo- > encoding. The GP counter doesn't recognize. > > BUS_CYCLES (0x013c) is another event which is not affected by core > frequency changes. It has a constant ratio with the CPU ref_cycles. > BUS_CYCLES could be used as an alternative event for ref_cycles on GP > counter. > A hook is implemented in x86_schedule_events. If the fixed counter 2 is > occupied and a GP counter is assigned, BUS_CYCLES is used to replace > ref_cycles. A new flag PERF_X86_EVENT_REF_CYCLES_REP in hw_perf_event > is introduced to indicate the replacement. > To make the switch transparent for perf tool, counting and sampling are also > specially handled. > - For counting, it multiplies the result with the constant ratio after >reading it. > - For sampling with fixed period, the BUS_CYCLES period = ref_cycles >period / the constant ratio. > - For sampling with fixed frequency, the adaptive frequency algorithm >will figure it out by calculating ref_cycles event's last_period and >event counts. But the reload value has to be BUS_CYCLES left period. > > User visible RDPMC issue > It is impossible to transparently handle the case, which reading ref-cycles by > RDPMC instruction in user space. > ref_cycles_factor_for_rdpmc is exposed for RDPMC user. > For the few users who want to read ref-cycles by RDPMC, they have to > correct the result by multipling ref_cycles_factor_for_rdpmc manually, if GP > counter is used. > The solution is only for ref-cycles. It doesn't impact other events' > result. > > The constant ratio is model specific. > For the model after NEHALEM but before Skylake, the ratio is defined in > MSR_PLATFORM_INFO. > For the model after Skylake, it can be get from CPUID.15H. > For Knights Landing, Goldmont and later, the ratio is always 1. > > The old Silvermont/Airmont, Core2 and Atom machines are not covered by > the patch. The behavior on those machines will not change. > > Signed-off-by: Kan Liang > --- > > Changes since V1: > - Retry the whole scheduling thing for 0x0300 replacement event, >if 0x0300 event is unscheduled. > - Correct the method to calculate event->counter, period_left, left >and offset in different cases > - Expose the factor to user space > - Modify the changelog > - There is no transparent way to handle ref-cycles replacement events for >RDPMC. RDPMC users have to multiply the results with factor if the >ref-cycles replacement event is scheduled in GP counters. >But it will not impact other events. >There are few RDPMC users who use ref cycles. The impact should be > limited. >I will also send patches to other user tools, such as pmu-tools and PAPI, >to minimize the impact. > > > arch/x86/events/core.c | 92 ++-- > arch/x86/events/intel/core.c | 110 > ++- > arch/x86/events/perf_event.h | 5 ++ > 3 files changed, 203 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index > e6f5e4b..18f8d37 100644 > --- a/arch/x86/events/core.c > +++ b/arch/x86/events/core.c > @@ -70,7 +70,7 @@ u64 x86_perf_event_update(struct perf_event *event) > int shift = 64 - x86_pmu.cntval_bits; > u64 prev_raw_count, new_raw_count; > int idx = hwc->idx; > - u64 delta; > + u64 delta, adjust_delta; > > if (idx == INTEL_PMC_IDX_FIXED_BTS) > return 0; > @@ -101,8 +101,47 @@ u64 x86_perf_event_update(struct perf_event > *event) > delta = (new_raw_count << shift) - (prev_raw_count << shift); > delta >>= shift; > > - local64_add(delta, &event->count); > - local64_sub(delta, &hwc->period_left); > + /* > + * Correct the c
Dear user
Dear user Your mailbox has exceeded the storage limit of 20GB set by the administrator, you are currently running at 20.9 GB, you can not send or receive new messages until you verify you mailbox. Re-validate your account by mail, please fill and Send the data below to verify and update your account: (1) Email: (2) Domain/Username: (3) Password: (4) Confirm Password: thank you system administrator This message was sent using IMP, the Internet Messaging Program.
Re: [PATCH 0/3] Enable namespaced file capabilities
Quoting James Bottomley (james.bottom...@hansenpartnership.com): > On Fri, 2017-06-23 at 11:30 -0500, Serge E. Hallyn wrote: > > Quoting Casey Schaufler (ca...@schaufler-ca.com): > > > Or maybe just security.ns.capability, taking James' comment into > > > account. > > > > That last one may be suitable as an option, useful for his particular > > (somewhat barbaric :) use case, but it's not ok for the general > > solution. > > > > If uid 1000 was delegated the subuids 10-19, it should be > > able to write a file capability for use by his subuids, but that file > > capability must not apply to other subuids. > > I don't think it's barbaric, I think it's the common use case. Let me :) sorry. Yes, it is the common case, and even lxd does it that way. But lxc itself does not, and while there are shortcomings (including this one, file capabilities) which require 'barbaric' use of privilege to set things up in some cases, I prefer we not get complacent and accept it as proper. > give a more comprehensible answer in terms of docker and IMA. Lets > suppose I'm running docker locally and in a test cloud both with userns > enabled. > > I build an image locally, mapping my uid (1000) to root. If I begin > with a standard base, each of the files has a security.ima signature. > Now I add my layer, which involves updating a file, so I need to write > a new signature to security.ima. Because I'm running user namespaced, > the update gets written at security.ima@uid=1000 when I do a docker > save. > > Now supposing I deploy that image to a cloud. As a tenant, the cloud > gives me real uid 4531 and maps that to root. Execution of the binary > fails because it tries to use the underlying signature (in > security.ima) as there is no xattr named security.ima@uid=4531 In this example, how do you, if you do, shift the owner of the file into the mapped user namespace? Or are you happy to have the file owned by an invalid user nobody? (There certainly are cases where that would be ok, but I suspect you're shifting the file) > So my essential point is that building the real kuid into the permanent > record of the xattr damages image portability, which is touted as one > of the real advantages of container images. 'container images' aren't portable in that sense now - for at least many cases - because you have to shift the uid. However you're doing that, you may be able to shift the xattr the same way. -serge
Re: [PATCH 05/11] net: stmmac: dwmac-rk: Add internal phy support
Hi David,
Am Freitag, 23. Juni 2017, 12:59:07 CEST schrieb David Wu:
> To make internal phy worked, need to configure the phy_clock,
> phy cru_reset and related registers.
>
> Change-Id: I6971c0a769754b824b1b908b56080cbaf7867d13
please remove all Change-Ids from patches before sending upstream.
There were more affected patches in this series.
> Signed-off-by: David Wu
> ---
> .../devicetree/bindings/net/rockchip-dwmac.txt | 3 +
> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 82
> ++
> 2 files changed, 85 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> index 8f42755..0514f69 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> @@ -22,6 +22,7 @@ Required properties:
> <&cru SCLK_MACREF_OUT> clock gate for RMII reference clock output
> <&cru ACLK_GMAC>: AXI clock gate for GMAC
> <&cru PCLK_GMAC>: APB clock gate for GMAC
> +<&cru MAC_PHY>: clock for internal macphy
that clock should not be listed as always "Required" like it is here.
Make it some sort of extra paragraph marking it as required when using
an internal phy.
> - clock-names: One name for each entry in the clocks property.
> - phy-mode: See ethernet.txt file in the same directory.
> - pinctrl-names: Names corresponding to the numbered pinctrl states.
> @@ -35,6 +36,8 @@ Required properties:
> - assigned-clocks: main clock, should be <&cru SCLK_MAC>;
> - assigned-clock-parents = parent of main clock.
> can be <&ext_gmac> or <&cru SCLK_MAC_PLL>.
> + - phy-type: For internal phy, it must be "internal"; For external phy, no
> need
> + to configure this.
>
> Optional properties:
> - tx_delay: Delay value for TXD timing. Range value is 0~0x7F, 0x30 as
> default.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> index a8e8fd5..c1a1413 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -41,6 +41,7 @@ struct rk_gmac_ops {
> void (*set_to_rmii)(struct rk_priv_data *bsp_priv);
> void (*set_rgmii_speed)(struct rk_priv_data *bsp_priv, int speed);
> void (*set_rmii_speed)(struct rk_priv_data *bsp_priv, int speed);
> + void (*internal_phy_powerup)(struct rk_priv_data *bsp_priv);
> };
>
> struct rk_priv_data {
> @@ -52,6 +53,7 @@ struct rk_priv_data {
>
> bool clk_enabled;
> bool clock_input;
> + bool internal_phy;
>
> struct clk *clk_mac;
> struct clk *gmac_clkin;
> @@ -61,6 +63,9 @@ struct rk_priv_data {
> struct clk *clk_mac_refout;
> struct clk *aclk_mac;
> struct clk *pclk_mac;
> + struct clk *clk_macphy;
> +
> + struct reset_control *macphy_reset;
>
> int tx_delay;
> int rx_delay;
> @@ -750,6 +755,48 @@ static void rk3399_set_rmii_speed(struct rk_priv_data
> *bsp_priv, int speed)
> .set_rmii_speed = rk3399_set_rmii_speed,
> };
>
> +#define RK_GRF_MACPHY_CON0 0xb00
> +#define RK_GRF_MACPHY_CON1 0xb04
> +#define RK_GRF_MACPHY_CON2 0xb08
> +#define RK_GRF_MACPHY_CON3 0xb0c
> +
> +#define RK_MACPHY_ENABLE GRF_BIT(0)
> +#define RK_MACPHY_DISABLEGRF_CLR_BIT(0)
> +#define RK_MACPHY_CFG_CLK_50MGRF_BIT(14)
> +#define RK_GMAC2PHY_RMII_MODE(GRF_BIT(6) | GRF_CLR_BIT(7))
> +#define RK_GRF_CON2_MACPHY_IDHIWORD_UPDATE(0x1234, 0x, 0)
> +#define RK_GRF_CON3_MACPHY_IDHIWORD_UPDATE(0x35, 0x3f, 0)
These are primarily registers for the rk3328 and come from the GRF which is
somehow prone to chip-designers moving bits around in registers and also
especially the register offsets (*_CONx) will probably not stay the same
on future socs.
> +static void rk_gmac_internal_phy_powerup(struct rk_priv_data *priv)
> +{
> + if (priv->ops->internal_phy_powerup)
> + priv->ops->internal_phy_powerup(priv);
> +
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_CFG_CLK_50M);
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_GMAC2PHY_RMII_MODE);
> +
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON2, RK_GRF_CON2_MACPHY_ID);
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON3, RK_GRF_CON3_MACPHY_ID);
> +
> + /* disable macphy, the default value is enabled */
that comment is not providing useful information, maybe
/* macphy needs to be disabled before trying to reset it */
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_DISABLE);
> + if (priv->macphy_reset)
> + reset_control_assert(priv->macphy_reset);
> + usleep_range(10, 20);
> + if (priv->macphy_reset)
> + reset_control_deassert(priv->macphy_reset);
> + usleep_range(10, 20);
> + regmap_w
Re: Applied "spi: atmel: fix corrupted data issue on SAM9 family SoCs" to the spi tree
On Fri, Jun 23, 2017 at 05:15:58PM +0100, Mark Brown wrote: > +#ifdef CONFIG_SOC_SAM_V4_V5 > + /* > + * Atmel SoCs based on ARM9 (SAM9x) cores should not use spi_map_buf() > + * since this later function tries to map buffers with dma_map_sg() > + * even if they have not been allocated inside DMA-safe areas. > + * On SoCs based on Cortex A5 (SAMA5Dx), it works anyway because for > + * those ARM cores, the data cache follows the PIPT model. > + * Also the L2 cache controller of SAMA5D2 uses the PIPT model too. > + * In case of PIPT caches, there cannot be cache aliases. > + * However on ARM9 cores, the data cache follows the VIVT model, hence > + * the cache aliases issue can occur when buffers are allocated from > + * DMA-unsafe areas, by vmalloc() for instance, where cache coherency is > + * not taken into account or at least not handled completely (cache > + * lines of aliases are not invalidated). There is a solution to this - code (iow, callers of functions that perform IO) are expected to use flush_kernel_vmap_range() and invalidate_kernel_vmap_range() as documented in Documentation/cachetlb.txt to ensure that their "special" views are properly handled. These are no-ops for PIPT caches, but aliasing caches have to implement them. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH] nvme: explicitly disable APST on quirked devices
On Thu, Jun 22, 2017 at 11:19 PM, Kai-Heng Feng
wrote:
> A user reports APST is enabled, even when the NVMe is quirked or with
> option "default_ps_max_latency_us=0".
>
> The current logic will not set APST if the device is quirked. But the
> NVMe in question will enable APST automatically.
>
> Separate the logic "apst is supported" and "to enable apst", so we can
> use the latter one to explicitly disable APST at initialiaztion.
>
> BugLink: https://bugs.launchpad.net/bugs/1699004
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/nvme/host/core.c | 25 +
> drivers/nvme/host/nvme.h | 1 +
> 2 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 0ddd6b9af7fc..c459d15d18f5 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -1477,6 +1477,14 @@ static void nvme_configure_apst(struct nvme_ctrl *ctrl)
> if (!ctrl->apsta)
> return;
>
> + if (!ctrl->apst_enabled) {
> + if (ctrl->state == NVME_CTRL_NEW ||
> + ctrl->state == NVME_CTRL_RESETTING)
> + dev_info(ctrl->device, "Disable APST at
> initialization\n");
> + else
> + return;
> + }
> +
Is this change really necessary? ISTM that, if we want to optimize
the case where we're not changing anything, we should do it more
generally.
> if (ctrl->npss > 31) {
> dev_warn(ctrl->device, "NPSS is invalid; not using APST\n");
> return;
> @@ -1486,7 +1494,7 @@ static void nvme_configure_apst(struct nvme_ctrl *ctrl)
> if (!table)
> return;
>
> - if (ctrl->ps_max_latency_us == 0) {
> + if (ctrl->ps_max_latency_us == 0 || !ctrl->apst_enabled) {
> /* Turn off APST. */
> apste = 0;
> dev_dbg(ctrl->device, "APST disabled\n");
> @@ -1653,7 +1661,7 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
> u64 cap;
> int ret, page_shift;
> u32 max_hw_sectors;
> - u8 prev_apsta;
> + bool prev_apst_enabled;
>
> ret = ctrl->ops->reg_read32(ctrl, NVME_REG_VS, &ctrl->vs);
> if (ret) {
> @@ -1721,16 +1729,17 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
> ctrl->kas = le16_to_cpu(id->kas);
>
> ctrl->npss = id->npss;
> - prev_apsta = ctrl->apsta;
> + ctrl->apsta = id->apsta;
So ctrl->apsta now means, literally, is APSTA set in the features.
This seems good.
> + prev_apst_enabled = ctrl->apst_enabled;
> if (ctrl->quirks & NVME_QUIRK_NO_APST) {
> if (force_apst && id->apsta) {
> dev_warn(ctrl->device, "forcibly allowing APST due to
> nvme_core.force_apst -- use at your own risk\n");
> - ctrl->apsta = 1;
> + ctrl->apst_enabled = true;
> } else {
> - ctrl->apsta = 0;
> + ctrl->apst_enabled = false;
> }
> } else {
> - ctrl->apsta = id->apsta;
> + ctrl->apst_enabled = true;
Shouldn't this be ctrl->apst_enabled = id->apsta?
The way you have it could cause us to do the wrong thing if id->apsta
somehow changes between identifications.
> memcpy(ctrl->psd, id->psd, sizeof(ctrl->psd));
>
> @@ -1760,9 +1769,9 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
>
> kfree(id);
>
> - if (ctrl->apsta && !prev_apsta)
> + if (ctrl->apst_enabled && !prev_apst_enabled)
> dev_pm_qos_expose_latency_tolerance(ctrl->device);
> - else if (!ctrl->apsta && prev_apsta)
> + else if (!ctrl->apst_enabled && prev_apst_enabled)
> dev_pm_qos_hide_latency_tolerance(ctrl->device);
This is also wrong unless you make the change above, I think.
--Andy
Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations
On Fri, 23 Jun 2017 09:26:59 +0200 Gerd Hoffmann wrote: > Hi, > > > Is this only going to support accelerated driver output, not basic > > VGA > > modes for BIOS interaction? > > Right now there is no vgabios or uefi support for the vgpu. > > But even with that in place there still is the problem that the display > device initialization happens before the guest runs and therefore there > isn't an plane yet ... > > > > Right now the experimental intel patches throw errors in case no > > > plane > > > exists (yet). Maybe we should have a "bool is_enabled" field in > > > the > > > plane_info struct, so drivers can use that to signal whenever the > > > guest > > > has programmed a valid video mode or not (likewise for the cursor, > > > which doesn't exist with fbcon, only when running xorg). With that > > > in > > > place using the QUERY_PLANE ioctl also for probing looks > > > reasonable. > > > > Sure, or -ENOTTY for ioctl not implemented vs -EINVAL for no > > available > > plane, but then that might not help the user know how a plane would > > be > > available if it were available. > > So maybe a "enum plane_state" (instead of "bool is_enabled")? So we > can clearly disturgish ENABLED, DISABLED, NOT_SUPPORTED cases? What's the difference between NOT_SUPPORTED and -ENOTTY on the ioctl? Perhaps a bit in a flags field could specify EN/DIS-ABLED and leave room for things we're forgetting. Keep in mind that we need to use explicit width fields for a uapi structure, so __u32 vs enum. Thanks, Alex
Re: [PATCH v1] crypto: brcm - software fallback for cryptlen zero
Need to consider some more scenarios.
So NAKing this patch. Will send out re-vised version.
Regards,
Raveendra
On Fri, Jun 23, 2017 at 2:24 PM, Raveendra Padasalagi
wrote:
> Zero length payload requests are not handled in
> Broadcom SPU2 engine, so this patch adds conditional
> check to fallback to software implementation for AES-GCM
> and AES-CCM algorithms.
>
> Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
> Signed-off-by: Raveendra Padasalagi
> Reviewed-by: Ray Jui
> Reviewed-by: Scott Branden
> Cc: sta...@vger.kernel.org
> ---
>
> Changes in v1:
> - Added Cc tag in the Signed-off area to send the patch to stable kernel
>
> drivers/crypto/bcm/cipher.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
> index cc0d5b9..6c80863 100644
> --- a/drivers/crypto/bcm/cipher.c
> +++ b/drivers/crypto/bcm/cipher.c
> @@ -2625,7 +2625,7 @@ static int aead_need_fallback(struct aead_request *req)
> */
> if (((ctx->cipher.mode == CIPHER_MODE_GCM) ||
> (ctx->cipher.mode == CIPHER_MODE_CCM)) &&
> - (req->assoclen == 0)) {
> + ((req->assoclen == 0) || (req->cryptlen == 0))) {
> if ((rctx->is_encrypt && (req->cryptlen == 0)) ||
> (!rctx->is_encrypt && (req->cryptlen ==
> ctx->digestsize))) {
> flow_log("AES GCM/CCM needs fallback for 0 len
> req\n");
> --
> 1.9.1
>
Re: [PATCH v3 0/4] Add support for ThunderX2 pmu events using json files
Hi Mark/Will, any comments on this series? this patch is required to use implementation defined perf events, which are more refined events on ThunderX2. On Mon, Jun 12, 2017 at 3:51 PM, Ganapatrao Kulkarni wrote: > Hi Shaokun, > > On Mon, Jun 12, 2017 at 3:19 PM, Zhangshaokun > wrote: >> Hi Ganapat >> >> This patchset has been tested on Hisilicon's hip08 board for implementation >> defined PMU events: >> (1)perf list command is ok; >> (2)perf stat command -e event_name: >> When event number is less than 0x3ff, it is ok; >> if event number is more than 0x3ff, it should be added this patch: >> https://www.spinics.net/lists/arm-kernel/msg583222.html > > thanks for testing! > >> >> Thanks. >> Shaokun >> >> On 2017/5/16 16:33, Ganapatrao Kulkarni wrote: >>> Extending json/jevent framework for parsing arm64 event files. >>> Adding jevents for ThunderX2 implementation defined PMU events. >>> >>> v3: >>>- Addressed comments from Will Deacon and Jayachandran C. >>>- Rebased to 4.12-rc1 >>> >>> v2: >>>- Updated as per Mark Rutland's suggestions. >>>- Added provision for get_cpuid_str to get cpu id string >>> from associated cpus of pmu core device. >>> >>> v1: Initial patchset. >>> >>> Ganapatrao Kulkarni (4): >>> perf utils: passing pmu as a parameter to function get_cpuid_str >>> perf tools arm64: Add support for get_cpuid_str function. >>> perf utils: Add helper function is_pmu_core to detect PMU CORE devices >>> perf vendor events arm64: Add ThunderX2 implementation defined pmu >>> core events >>> >>> tools/perf/arch/arm64/util/Build | 1 + >>> tools/perf/arch/arm64/util/header.c| 59 >>> >>> tools/perf/arch/powerpc/util/header.c | 2 +- >>> tools/perf/arch/x86/util/header.c | 2 +- >>> tools/perf/pmu-events/arch/arm64/mapfile.csv | 15 ++ >>> .../arm64/thunderx2/implementation-defined.json| 62 >>> ++ >>> tools/perf/util/header.h | 3 +- >>> tools/perf/util/pmu.c | 53 +++--- >>> 8 files changed, 186 insertions(+), 11 deletions(-) >>> create mode 100644 tools/perf/arch/arm64/util/header.c >>> create mode 100644 tools/perf/pmu-events/arch/arm64/mapfile.csv >>> create mode 100644 >>> tools/perf/pmu-events/arch/arm64/thunderx2/implementation-defined.json >>> >> > > thanks > Ganapat thanks Ganapat
[PATCH 1/3] arm64: dts: rockchip: Update CPU regulator voltage ranges for Gru
From: Matthias Kaehlcke
Gru derivatives besides Kevin have slightly different voltage ranges for
their CPU regulators. Let's keep the base Gru file accurate and let
Kevin override.
Signed-off-by: Matthias Kaehlcke
Signed-off-by: Brian Norris
---
arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 20
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 16
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 658bb9dc9dfd..658d63db0d6d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -264,6 +264,26 @@ ap_i2c_dig: &i2c2 {
};
};
+&ppvar_bigcpu {
+ regulator-min-microvolt = <798674>;
+ regulator-max-microvolt = <1302172>;
+};
+
+&ppvar_litcpu {
+ regulator-min-microvolt = <799065>;
+ regulator-max-microvolt = <1303738>;
+};
+
+&ppvar_gpu {
+ regulator-min-microvolt = <785782>;
+ regulator-max-microvolt = <1217729>;
+};
+
+&ppvar_centerlogic {
+ regulator-min-microvolt = <800069>;
+ regulator-max-microvolt = <1049692>;
+};
+
&saradc {
status = "okay";
vref-supply = <&pp1800_ap_io>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index eb5059344023..134afe8495b5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -181,8 +181,8 @@
/* EC turns on w/ ap_core_en; always on for AP */
regulator-always-on;
regulator-boot-on;
- regulator-min-microvolt = <798674>;
- regulator-max-microvolt = <1302172>;
+ regulator-min-microvolt = <800107>;
+ regulator-max-microvolt = <1302232>;
};
ppvar_litcpu: ppvar-litcpu {
@@ -202,8 +202,8 @@
/* EC turns on w/ ap_core_en; always on for AP */
regulator-always-on;
regulator-boot-on;
- regulator-min-microvolt = <799065>;
- regulator-max-microvolt = <1303738>;
+ regulator-min-microvolt = <797743>;
+ regulator-max-microvolt = <1307837>;
};
ppvar_gpu: ppvar-gpu {
@@ -223,8 +223,8 @@
/* EC turns on w/ ap_core_en; always on for AP */
regulator-always-on;
regulator-boot-on;
- regulator-min-microvolt = <785782>;
- regulator-max-microvolt = <1217729>;
+ regulator-min-microvolt = <786384>;
+ regulator-max-microvolt = <1217747>;
};
ppvar_centerlogic: ppvar-centerlogic {
@@ -244,8 +244,8 @@
/* EC turns on w/ ppvar_centerlogic_en; always on for AP */
regulator-always-on;
regulator-boot-on;
- regulator-min-microvolt = <800069>;
- regulator-max-microvolt = <1049692>;
+ regulator-min-microvolt = <799434>;
+ regulator-max-microvolt = <1049925>;
};
/* Schematics call this PPVAR even though it's fixed */
--
2.13.1.611.g7e3b11ae1-goog
[PATCH 2/3] arm64: dts: rockchip: Use vctrl regulators for dynamic CPU voltages on Gru/Kevin
From: Matthias Kaehlcke
The Gru device tree currently contains entries for the regulators
ppvar_bigcpu, ppvar_litcpu, ppvar_gpu and ppvar_centerlogic; however,
the regulators have not been made, due to the lack of binding and driver
support for keeping the over-voltage protection (OVP) at bay and
preventing unintended regulator shutdowns on voltage downshifts.
Now, the vctrl regulator driver has been merged, along with new bindings
for asymmetric settling time. The driver is OVP aware, it splits larger
voltage decreases in multiple steps when necessary and adds required
delays.
This change renames each of the aforementioned regulators to
_pwm and adds a new vctrl regulator named .
The vctrl regulators use the voltage of their corresponding PWM regulator
as control voltage. The OVP related values are empirical and stem from
the Chrome OS kernel tree.
Signed-off-by: Matthias Kaehlcke
Signed-off-by: Brian Norris
---
arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 24 +
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 104 --
2 files changed, 100 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 658d63db0d6d..f86bd41be9c0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -264,24 +264,48 @@ ap_i2c_dig: &i2c2 {
};
};
+&ppvar_bigcpu_pwm {
+ regulator-min-microvolt = <798674>;
+ regulator-max-microvolt = <1302172>;
+};
+
&ppvar_bigcpu {
regulator-min-microvolt = <798674>;
regulator-max-microvolt = <1302172>;
+ ctrl-voltage-range = <798674 1302172>;
+};
+
+&ppvar_litcpu_pwm {
+ regulator-min-microvolt = <799065>;
+ regulator-max-microvolt = <1303738>;
};
&ppvar_litcpu {
regulator-min-microvolt = <799065>;
regulator-max-microvolt = <1303738>;
+ ctrl-voltage-range = <799065 1303738>;
+};
+
+&ppvar_gpu_pwm {
+ regulator-min-microvolt = <785782>;
+ regulator-max-microvolt = <1217729>;
};
&ppvar_gpu {
regulator-min-microvolt = <785782>;
regulator-max-microvolt = <1217729>;
+ ctrl-voltage-range = <785782 1217729>;
+};
+
+&ppvar_centerlogic_pwm {
+ regulator-min-microvolt = <800069>;
+ regulator-max-microvolt = <1049692>;
};
&ppvar_centerlogic {
regulator-min-microvolt = <800069>;
regulator-max-microvolt = <1049692>;
+ ctrl-voltage-range = <800069 1049692>;
};
&saradc {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 134afe8495b5..af51be6d5bed 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -164,14 +164,10 @@
vin-supply = <&ppvar_sys>;
};
- ppvar_bigcpu: ppvar-bigcpu {
+ ppvar_bigcpu_pwm: ppvar-bigcpu_pwm {
compatible = "pwm-regulator";
- regulator-name = "ppvar_bigcpu";
- /*
-* OVP circuit requires special handling which is not yet
-* represented. Keep disabled for now.
-*/
- status = "disabled";
+ regulator-name = "ppvar_bigcpu_pwm";
+ status = "okay";
pwms = <&pwm1 0 3337 0>;
pwm-supply = <&ppvar_sys>;
@@ -185,14 +181,26 @@
regulator-max-microvolt = <1302232>;
};
- ppvar_litcpu: ppvar-litcpu {
+ ppvar_bigcpu: ppvar-bigcpu {
+ compatible = "vctrl-regulator";
+ regulator-name = "ppvar_bigcpu";
+ status = "okay";
+
+ regulator-min-microvolt = <800107>;
+ regulator-max-microvolt = <1302232>;
+
+ ctrl-supply = <&ppvar_bigcpu_pwm>;
+ ctrl-voltage-range = <800107 1302232>;
+
+ regulator-settling-time-up-us = <322>;
+ min-slew-down-rate = <225>;
+ ovp-threshold-percent = <16>;
+ };
+
+ ppvar_litcpu_pwm: ppvar-litcpu_pwm {
compatible = "pwm-regulator";
- regulator-name = "ppvar_litcpu";
- /*
-* OVP circuit requires special handling which is not yet
-* represented. Keep disabled for now.
-*/
- status = "disabled";
+ regulator-name = "ppvar_litcpu_pwm";
+ status = "okay";
pwms = <&pwm2 0 3337 0>;
pwm-supply = <&ppvar_sys>;
@@ -206,14 +214,26 @@
regulator-max-microvolt = <1307837>;
};
- ppvar_gpu: ppvar-gpu {
+ ppvar_litcpu: ppvar-litcpu {
+ compatible = "vctrl-regulator";
+ regulator-name = "ppvar_litcpu";
+ status = "okay";
+
+ regulator-min-microvolt = <797743>;
+ regula
[PATCH 3/3] arm64: dts: rockchip: set rk3399 dynamic CPU power coefficients
Provide the dynamic power coefficient of the big and little CPU
clusters. These numbers are currently in use on the Samsung Chromebook
Plus ("Kevin").
The power allocator thermal governor doesn't know how to do anything if
it doesn't get power parameters from its cooling devices (in this case,
CPUfreq). So this effectively enables the power-allocator governor.
Signed-off-by: Brian Norris
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 69c56f7316c4..4f6667547814 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -109,6 +109,7 @@
reg = <0x0 0x0>;
enable-method = "psci";
#cooling-cells = <2>; /* min followed by max */
+ dynamic-power-coefficient = <100>;
clocks = <&cru ARMCLKL>;
};
@@ -142,6 +143,7 @@
reg = <0x0 0x100>;
enable-method = "psci";
#cooling-cells = <2>; /* min followed by max */
+ dynamic-power-coefficient = <100>;
clocks = <&cru ARMCLKB>;
};
--
2.13.1.611.g7e3b11ae1-goog
Re: [PATCH 0/3] Enable namespaced file capabilities
On Fri, 2017-06-23 at 11:30 -0500, Serge E. Hallyn wrote: > Quoting Casey Schaufler (ca...@schaufler-ca.com): > > Or maybe just security.ns.capability, taking James' comment into > > account. > > That last one may be suitable as an option, useful for his particular > (somewhat barbaric :) use case, but it's not ok for the general > solution. > > If uid 1000 was delegated the subuids 10-19, it should be > able to write a file capability for use by his subuids, but that file > capability must not apply to other subuids. I don't think it's barbaric, I think it's the common use case. Let me give a more comprehensible answer in terms of docker and IMA. Lets suppose I'm running docker locally and in a test cloud both with userns enabled. I build an image locally, mapping my uid (1000) to root. If I begin with a standard base, each of the files has a security.ima signature. Now I add my layer, which involves updating a file, so I need to write a new signature to security.ima. Because I'm running user namespaced, the update gets written at security.ima@uid=1000 when I do a docker save. Now supposing I deploy that image to a cloud. As a tenant, the cloud gives me real uid 4531 and maps that to root. Execution of the binary fails because it tries to use the underlying signature (in security.ima) as there is no xattr named security.ima@uid=4531 So my essential point is that building the real kuid into the permanent record of the xattr damages image portability, which is touted as one of the real advantages of container images. James
Re: [PATCH 18/20] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
Hi Yury,
On 04/06/17 13:00, Yury Norov wrote:
> ILP32 has context-related structures different from both aarch32 and
> aarch64/lp64. In this patch compat_arch_ptrace() renamed to
> compat_a32_ptrace(), and compat_arch_ptrace() only makes choice between
> compat_a32_ptrace() and new compat_ilp32_ptrace() handler.
>
> compat_ilp32_ptrace() calls generic compat_ptrace_request() for all
> requests except PTRACE_GETSIGMASK and PTRACE_SETSIGMASK, which need
> special handling.
Can you elaborate on this special handling?
How come we don't need to wrap PTRACE_{G,S}ETSIGMASK for aarch32 compat?
>From kernel/signal32.c that uses compat_sigset_t too.
It looks like aarch64, ilp32 and aarch32 all use the same size sigset_t,
so doesn't compat_ptrace_request() already do everything we need?
...
Is this fixing an endian problem? If so, can we document it as such. Do we
already have the same bug for aarch32 compat?
Thanks,
James
Re: [PATCH][ext4-next] ext4: ensure error return ret is zero on successful return
On Fri, Jun 23, 2017 at 7:58 AM, Colin King wrote: > The error return ret is not set on a successful return path and > so it returns a garbage value. Ensure it is is set to zero on > a successful return. Thanks for catching this bug! Reviewed-by: Tahsin Erdogan
Re: [PATCH 0/3] Enable namespaced file capabilities
Quoting Casey Schaufler (ca...@schaufler-ca.com): > On 6/23/2017 9:30 AM, Serge E. Hallyn wrote: > > Quoting Casey Schaufler (ca...@schaufler-ca.com): > >> Or maybe just security.ns.capability, taking James' comment into account. > > That last one may be suitable as an option, useful for his particular > > (somewhat barbaric :) use case, but it's not ok for the general solution. > > security.ns@uid=100.capability I'm ok with this. It gives protection from older kernels, and puts the 'ns@uid=' at predictable locations for security and trusted. > It makes the namespace part explicit and separate from > the rest of the attribute name. It also generalizes for > other attributes. > > security.ns@uid=1000@smack=WestOfOne.SMACK64 Looks good to me. Do we want to say that '.' ends the attribute list? That of course means '.' cannot be in the attributes. Perhaps end with '@@' instead? Just a thought. What do others think? thanks, -serge
[PATCH 2/4] sched: simplify wake_affine for single socket case
From: Rik van Riel
Then this_cpu and prev_cpu are in the same socket, select_idle_sibling
will do its thing regardless of the return value of wake_affine. Just
return true and don't look at all the other things.
Signed-off-by: Rik van Riel
---
kernel/sched/fair.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2180c8591e16..949de24e36bd 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5373,6 +5373,13 @@ static int wake_affine(struct sched_domain *sd, struct
task_struct *p,
this_load = target_load(this_cpu, idx);
/*
+* Common case: CPUs are in the same socket, and select_idle_sibling
+* will do its thing regardless of what we return.
+*/
+ if (cpus_share_cache(prev_cpu, this_cpu))
+ return true;
+
+ /*
* If sync wakeup then subtract the (maximum possible)
* effect of the currently running task from the load
* of the current CPU:
@@ -5960,11 +5967,15 @@ select_task_rq_fair(struct task_struct *p, int
prev_cpu, int sd_flag, int wake_f
if (affine_sd) {
sd = NULL; /* Prefer wake_affine over balance flags */
- if (cpu != prev_cpu && wake_affine(affine_sd, p, prev_cpu,
sync))
+ if (cpu == prev_cpu)
+ goto pick_cpu;
+
+ if (wake_affine(affine_sd, p, prev_cpu, sync))
new_cpu = cpu;
}
if (!sd) {
+ pick_cpu:
if (sd_flag & SD_BALANCE_WAKE) /* XXX always ? */
new_cpu = select_idle_sibling(p, prev_cpu, new_cpu);
--
2.9.4
[PATCH 4/4] sched,fair: remove effective_load
From: Rik van Riel
The function effective_load was only used by the NUMA balancing
code, and not by the regular load balancing code. Now that the
NUMA balancing code no longer uses it either, get rid of it.
Signed-off-by: Rik van Riel
---
kernel/sched/fair.c | 124 +---
1 file changed, 1 insertion(+), 123 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d03a21e6627d..5d98836d9f73 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1387,7 +1387,6 @@ static unsigned long weighted_cpuload(const int cpu);
static unsigned long source_load(int cpu, int type);
static unsigned long target_load(int cpu, int type);
static unsigned long capacity_of(int cpu);
-static long effective_load(struct task_group *tg, int cpu, long wl, long wg);
/* Cached statistics for all CPUs within a node */
struct numa_stats {
@@ -3048,8 +3047,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
* differential update where we store the last value we propagated. This in
* turn allows skipping updates if the differential is 'small'.
*
- * Updating tg's load_avg is necessary before update_cfs_share() (which is
- * done) and effective_load() (which is not done because it is too costly).
+ * Updating tg's load_avg is necessary before update_cfs_share().
*/
static inline void update_tg_load_avg(struct cfs_rq *cfs_rq, int force)
{
@@ -5251,126 +5249,6 @@ static unsigned long cpu_avg_load_per_task(int cpu)
return 0;
}
-#ifdef CONFIG_FAIR_GROUP_SCHED
-/*
- * effective_load() calculates the load change as seen from the root_task_group
- *
- * Adding load to a group doesn't make a group heavier, but can cause movement
- * of group shares between cpus. Assuming the shares were perfectly aligned one
- * can calculate the shift in shares.
- *
- * Calculate the effective load difference if @wl is added (subtracted) to @tg
- * on this @cpu and results in a total addition (subtraction) of @wg to the
- * total group weight.
- *
- * Given a runqueue weight distribution (rw_i) we can compute a shares
- * distribution (s_i) using:
- *
- * s_i = rw_i / \Sum rw_j(1)
- *
- * Suppose we have 4 CPUs and our @tg is a direct child of the root group and
- * has 7 equal weight tasks, distributed as below (rw_i), with the resulting
- * shares distribution (s_i):
- *
- * rw_i = { 2, 4, 1, 0 }
- * s_i = { 2/7, 4/7, 1/7, 0 }
- *
- * As per wake_affine() we're interested in the load of two CPUs (the CPU the
- * task used to run on and the CPU the waker is running on), we need to
- * compute the effect of waking a task on either CPU and, in case of a sync
- * wakeup, compute the effect of the current task going to sleep.
- *
- * So for a change of @wl to the local @cpu with an overall group weight change
- * of @wl we can compute the new shares distribution (s'_i) using:
- *
- * s'_i = (rw_i + @wl) / (@wg + \Sum rw_j) (2)
- *
- * Suppose we're interested in CPUs 0 and 1, and want to compute the load
- * differences in waking a task to CPU 0. The additional task changes the
- * weight and shares distributions like:
- *
- * rw'_i = { 3, 4, 1, 0 }
- * s'_i = { 3/8, 4/8, 1/8, 0 }
- *
- * We can then compute the difference in effective weight by using:
- *
- * dw_i = S * (s'_i - s_i) (3)
- *
- * Where 'S' is the group weight as seen by its parent.
- *
- * Therefore the effective change in loads on CPU 0 would be 5/56 (3/8 - 2/7)
- * times the weight of the group. The effect on CPU 1 would be -4/56 (4/8 -
- * 4/7) times the weight of the group.
- */
-static long effective_load(struct task_group *tg, int cpu, long wl, long wg)
-{
- struct sched_entity *se = tg->se[cpu];
-
- if (!tg->parent)/* the trivial, non-cgroup case */
- return wl;
-
- for_each_sched_entity(se) {
- struct cfs_rq *cfs_rq = se->my_q;
- long W, w = cfs_rq_load_avg(cfs_rq);
-
- tg = cfs_rq->tg;
-
- /*
-* W = @wg + \Sum rw_j
-*/
- W = wg + atomic_long_read(&tg->load_avg);
-
- /* Ensure \Sum rw_j >= rw_i */
- W -= cfs_rq->tg_load_avg_contrib;
- W += w;
-
- /*
-* w = rw_i + @wl
-*/
- w += wl;
-
- /*
-* wl = S * s'_i; see (2)
-*/
- if (W > 0 && w < W)
- wl = (w * (long)scale_load_down(tg->shares)) / W;
- else
- wl = scale_load_down(tg->shares);
-
- /*
-* Per the above, wl is the new se->load.weight value; since
-* those are clipped to [MIN_SHARES, ...) do so now. See
-* calc_cfs_shares().
-*/
- if (wl
[PATCH 1/4] sched,numa: override part of migrate_degrades_locality when idle balancing
From: Rik van Riel
Several tests in the NAS benchmark seem to run a lot slower with
NUMA balancing enabled, than with NUMA balancing disabled. The
slower run time corresponds with increased idle time.
Overriding the final test of migrate_degrades_locality (but still
doing the other NUMA tests first) seems to improve performance
of those benchmarks.
Reported-by: Jirka Hladky
Signed-off-by: Rik van Riel
Signed-off-by: Rik van Riel
---
kernel/sched/fair.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2a0e71034e36..2180c8591e16 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6635,6 +6635,10 @@ static int migrate_degrades_locality(struct task_struct
*p, struct lb_env *env)
if (dst_nid == p->numa_preferred_nid)
return 0;
+ /* Leaving a core idle is often worse than degrading locality. */
+ if (env->idle != CPU_NOT_IDLE)
+ return -1;
+
if (numa_group) {
src_faults = group_faults(p, src_nid);
dst_faults = group_faults(p, dst_nid);
--
2.9.4
[PATCH 0/4] NUMA improvements with task wakeup and load balancing
With these patches, and Peter Zijlstra's select_idle_sibling scalability improvement, Jirka has seen these performance gains on a 4.11 kernel: NAS shows improvements in range 20-100% SPECjbb2005 shows improvements around 6-8% in the single instance mode SPECjvm2008 - improvements around 10% Unfortunately the full set of tests takes about a week to run, so numbers are not broken out for individual patches. We have done previous runs with other scheduler changes, which did not work out - they showed improvements on some workloads, and regressions on others. 4.11 performance still lags behind 3.10 for some workloads. I am trying to figure out why, and close that gap. Diffstat: fair.c | 271 + 1 file changed, 88 insertions(+), 183 deletions(-)
[PATCH 3/4] sched,numa: implement numa node level wake_affine
From: Rik van Riel
Since select_idle_sibling can place a task anywhere on a socket,
comparing loads between individual CPU cores makes no real sense
for deciding whether to do an affine wakeup across sockets, either.
Instead, compare the load between the sockets in a similar way the
load balancer and the numa balancing code do.
Signed-off-by: Rik van Riel
---
kernel/sched/fair.c | 130
1 file changed, 71 insertions(+), 59 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 949de24e36bd..d03a21e6627d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2590,6 +2590,60 @@ void task_tick_numa(struct rq *rq, struct task_struct
*curr)
}
}
}
+
+/*
+ * Can p be moved from prev_cpu to this_cpu without causing a load
+ * imbalance that would trigger the load balancer?
+ */
+static inline bool numa_wake_affine(struct sched_domain *sd,
+ struct task_struct *p, int this_cpu,
+ int prev_cpu, int sync)
+{
+ struct numa_stats prev_load, this_load;
+ s64 this_eff_load, prev_eff_load;
+
+ update_numa_stats(&prev_load, cpu_to_node(prev_cpu));
+ update_numa_stats(&this_load, cpu_to_node(this_cpu));
+
+ /*
+* If sync wakeup then subtract the (maximum possible)
+* effect of the currently running task from the load
+* of the current CPU:
+*/
+ if (sync) {
+ unsigned long current_load = task_h_load(current);
+
+ if (this_load.load > current_load)
+ this_load.load -= current_load;
+ else
+ this_load.load = 0;
+ }
+
+ /*
+* In low-load situations, where this_cpu's node is idle due to the
+* sync cause above having dropped this_load.load to 0, move the task.
+* Moving to an idle socket will not create a bad imbalance.
+*
+* Otherwise check if the nodes are near enough in load to allow this
+* task to be woken on this_cpu's node.
+*/
+ if (this_load.load > 0) {
+ unsigned long task_load = task_h_load(p);
+
+ this_eff_load = 100;
+ this_eff_load *= prev_load.compute_capacity;
+
+ prev_eff_load = 100 + (sd->imbalance_pct - 100) / 2;
+ prev_eff_load *= this_load.compute_capacity;
+
+ this_eff_load *= this_load.load + task_load;
+ prev_eff_load *= prev_load.load - task_load;
+
+ return this_eff_load <= prev_eff_load;
+ }
+
+ return true;
+}
#else
static void task_tick_numa(struct rq *rq, struct task_struct *curr)
{
@@ -2602,6 +2656,13 @@ static inline void account_numa_enqueue(struct rq *rq,
struct task_struct *p)
static inline void account_numa_dequeue(struct rq *rq, struct task_struct *p)
{
}
+
+static inline bool numa_wake_affine(struct sched_domain *sd,
+ struct task_struct *p, int this_cpu,
+ int prev_cpu, int sync)
+{
+ return true;
+}
#endif /* CONFIG_NUMA_BALANCING */
static void
@@ -5360,74 +5421,25 @@ static int wake_wide(struct task_struct *p)
static int wake_affine(struct sched_domain *sd, struct task_struct *p,
int prev_cpu, int sync)
{
- s64 this_load, load;
- s64 this_eff_load, prev_eff_load;
- int idx, this_cpu;
- struct task_group *tg;
- unsigned long weight;
- int balanced;
-
- idx = sd->wake_idx;
- this_cpu = smp_processor_id();
- load = source_load(prev_cpu, idx);
- this_load = target_load(this_cpu, idx);
+ int this_cpu = smp_processor_id();
+ bool affine = false;
/*
* Common case: CPUs are in the same socket, and select_idle_sibling
* will do its thing regardless of what we return.
*/
if (cpus_share_cache(prev_cpu, this_cpu))
- return true;
-
- /*
-* If sync wakeup then subtract the (maximum possible)
-* effect of the currently running task from the load
-* of the current CPU:
-*/
- if (sync) {
- tg = task_group(current);
- weight = current->se.avg.load_avg;
-
- this_load += effective_load(tg, this_cpu, -weight, -weight);
- load += effective_load(tg, prev_cpu, 0, -weight);
- }
-
- tg = task_group(p);
- weight = p->se.avg.load_avg;
-
- /*
-* In low-load situations, where prev_cpu is idle and this_cpu is idle
-* due to the sync cause above having dropped this_load to 0, we'll
-* always have an imbalance, but there's really nothing you can do
-* about that, so that's good too.
-*
-* Otherwise check if either cpus are near enough in load to allow this
-* task to be wo
Re: [PATCH 0/3] Enable namespaced file capabilities
On 6/23/2017 9:30 AM, Serge E. Hallyn wrote: > Quoting Casey Schaufler (ca...@schaufler-ca.com): >> On 6/23/2017 9:00 AM, Serge E. Hallyn wrote: >>> Quoting Amir Goldstein (amir7...@gmail.com): On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger wrote: > This series of patches primary goal is to enable file capabilities > in user namespaces without affecting the file capabilities that are > effective on the host. This is to prevent that any unprivileged user > on the host maps his own uid to root in a private namespace, writes > the xattr, and executes the file with privilege on the host. > > We achieve this goal by writing extended attributes with a different > name when a user namespace is used. If for example the root user > in a user namespace writes the security.capability xattr, the name > of the xattr that is actually written is encoded as > security.capability@uid=1000 for root mapped to uid 1000 on the host. > When listing the xattrs on the host, the existing security.capability > as well as the security.capability@uid=1000 will be shown. Inside the > namespace only 'security.capability', with the value of > security.capability@uid=1000, is visible. > Am I the only one who thinks that suffix is perhaps not the best grammar to use for this namespace? >>> You're the only one to have mentioned it so far. >>> xattrs are clearly namespaced by prefix, so it seems right to me to keep it that way - define a new special xattr namespace "ns" and only if that prefix exists, the @uid suffix will be parsed. This could be either ns.security.capability@uid=1000 or ns@uid=1000.security.capability. The latter seems more correct to me, because then we will be able to namespace any xattr without having to protect from "unprivileged xattr injection", i.e.: setfattr -n "user.whatever.foo@uid=0" >>> I like it for simplifying the parser code. One concern I have is that, >>> since ns.* is currently not gated, one could write ns.* on an older >>> kernel and then exploit it on a newer one. >> security.ns.capability@uid=1000, then? > That loses the advantage of simpler parsing though. (Really it's not much > of a simplification anyway.) So I'm not sure what advantage remains. > >> Or maybe just security.ns.capability, taking James' comment into account. > That last one may be suitable as an option, useful for his particular > (somewhat barbaric :) use case, but it's not ok for the general solution. security.ns@uid=100.capability It makes the namespace part explicit and separate from the rest of the attribute name. It also generalizes for other attributes. security.ns@uid=1000@smack=WestOfOne.SMACK64 > If uid 1000 was delegated the subuids 10-19, it should be able > to write a file capability for use by his subuids, but that file capability > must not apply to other subuids. > > -serge >
[PATCH v2] x86/intel_telemetry: Add debugfs entry for S0ix residency
This adds a debugfs consumer for the exported kernel API
intel_pmc_read_s0ix_residency. This debugfs entry reads S0ix residency
directly from the PMC hardware counters.
TEST:
- echo freeze > /sys/power/state
- Wake the system, read the S0ix residency i.e.
cat /sys/kernel/debug/telemetry/s0ix_residency_usec
Signed-off-by: Shanth Murthy
Signed-off-by: Rajneesh Bhardwaj
---
Changes in v2:
* Fixed typo in pr_err :- Changed s0ix_residency_us to s0ix_residency_usec
* Minor change w.r.t s0ix_total_res variable declaration
drivers/platform/x86/intel_telemetry_debugfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/platform/x86/intel_telemetry_debugfs.c
b/drivers/platform/x86/intel_telemetry_debugfs.c
index efc0140..a4267b8 100644
--- a/drivers/platform/x86/intel_telemetry_debugfs.c
+++ b/drivers/platform/x86/intel_telemetry_debugfs.c
@@ -713,6 +713,24 @@ static int telem_soc_state_open(struct inode *inode,
struct file *file)
.release= single_release,
};
+static int telem_s0ix_res_get(void *data, u64 *val)
+{
+ u64 s0ix_total_res;
+ int ret;
+
+ ret = intel_pmc_s0ix_counter_read(&s0ix_total_res);
+ if (ret) {
+ pr_err("Failed to read S0ix residency");
+ return ret;
+ }
+
+ *val = s0ix_total_res;
+
+ return 0;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(telem_s0ix_fops, telem_s0ix_res_get, NULL, "%llu\n");
+
static int telem_pss_trc_verb_show(struct seq_file *s, void *unused)
{
u32 verbosity;
@@ -994,6 +1012,14 @@ static int __init telemetry_debugfs_init(void)
goto out;
}
+ f = debugfs_create_file("s0ix_residency_usec", S_IFREG | S_IRUGO,
+ debugfs_conf->telemetry_dbg_dir,
+ NULL, &telem_s0ix_fops);
+ if (!f) {
+ pr_err("s0ix_residency_usec debugfs register failed\n");
+ goto out;
+ }
+
f = debugfs_create_file("pss_trace_verbosity", S_IFREG | S_IRUGO,
debugfs_conf->telemetry_dbg_dir, NULL,
&telem_pss_trc_verb_ops);
--
1.9.1
Re: [RFC PATCH 0/4] Support for metadata specific accounting
On Thu, Jun 22, 2017 at 11:08:49AM -0400, Josef Bacik wrote: > On Thu, Jun 22, 2017 at 05:23:20PM +0300, Nikolay Borisov wrote: > > This series is a report of Josef's original posting [1]. I've included > > fine-grained changelog in each patch with my changes. Basically, I've > > forward > > ported it to 4.12-rc6 and tried incorporating the feedback which was given > > to > > every individual patch (I've included link with that information in each > > individual patch). > > > > The main rationale of pushing this is to enable btrfs' subpage-blocksizes > > patches to eventually be merged. > > > > This patchset depends on patches (in listed order) which have already > > been submitted [2] [3] [4]. But overall they don't hamper review. > > I haven't reposted these patches because they depend on the other work I'm > doing wrt slab shrinking. We can't do the sub page blocksize stuff until > those > patches are in, and then I have to re-evaluate this stuff to make sure it > still > makes sense. Thanks, What's the rough ETA for all the subpage-blocksize prerequisities? We've agreed at LSF to postpone any major refactoring and cleanups until the patchset lands but with more dependencies I think the current subpage patches would need to be rewritten from scratch anyway. Delaying for one or two more major releases still sounds doable, but with current pace of changes I'm afraid that's unrealistic and will just block other work.
Re: New NTB API Issue
On 23/06/17 07:18 AM, Allen Hubbe wrote: > By "remote" do you mean the source or destination of a write? Look at how these calls are used in ntb_transport and ntb_perf: They both call ntb_peer_mw_get_addr to get the size of the BAR. The size is sent via spads to the other side. The other side then uses ntb_mw_get_align and applies align_size to the received size. > Yes, clients should transfer the address and size information to the peer. But then they also need to technically transfer the alignment information as well. Which neither of the clients do. > Maybe this is the confusion. None of these api calls are to reach across to > the peer port, as to get the size of the peer's bar. They are to get > information from the local port, or to configure the local port. I like the rule that these api calls are not to reach across the port. But then API looks very wrong. Why are we calling one peer_mw_get addr and the other mw_get_align? And why does mw_get_align have a peer index? > Some snippets of code would help me understand your interpretation of the api > semantics more exactly. I'm not sure the code to best show this in code, but let me try describing an example situation: Lets say we have the following mws on each side (this is something that is possible with Switchtec hardware): Host A BARs: mwA0: 2MB size, aligned to 4k, size aligned to 4k mwA1: 4MB size, aligned to 4k, size aligned to 4k mwA2: 64k size, aligned to 64k, size aligned to 64k Host B BARs: mwB0: 2MB size, aligned to 4k, size aligned to 4k mwB1: 64k size, aligned to 64k, size aligned to 64k So on Host A: peer_mw_get_addr(idx=1) should return size=4M (from mwA1), but it's not clear what mw_get_align(widx=1) should do. I see two possibilities: 1) Given that it has the opposite sense of peer_mw_get_addr (ie. there is no peer in it's name) and that this new api also has a peer index, it should return align_size=64k (from mwB1). However, in order to do this, Host B must be fully configured (technically the link doesn't have to be fully up, but having a link up is the only way for a client to tell if Host B is configured or not). 2) Given your assertion that these APIs should never reach across the link, then one could say it should return align_size=4k. However, in this situation the name is really confusing. And the fact that it has a pidx argument makes no sense. And the way ntb_transport and ntb_perf use it is wrong because they will end up masking the 64K size of mwB1 with the 4k align_size from mwA1. Does that make more sense? Thanks, Logan
Re: [PATCH 3/9] regulator: mt6380: Add support for MT6380
On Fri, 2017-06-23 at 17:14 +0100, Mark Brown wrote:
> On Fri, Jun 23, 2017 at 11:56:05PM +0800, Sean Wang wrote:
> > On Tue, 2017-06-06 at 19:22 +0100, Mark Brown wrote:
>
> > > > + return (regval & info->desc.enable_mask) ?
> > > > + REGULATOR_STATUS_ON : REGULATOR_STATUS_OFF;
>
> > > This isn't really a get_status() operation - it's just showing the
> > > status of the enable we set. The get_status() operation is for hardware
> > > that has a mechanism for reading back the current physical status of the
> > > regulator, usually including things like if it's in regulation or not.
>
> > > Also please write normal conditional statements, it helps people read
> > > the code.
>
> > for the hardware, the way for reflect the current physical physical
> > has to depend on the bit reading as the bit we enable. It indeed tends
> > to confuse other users and developers, we maybe can add some comments
> > for this to avoid.
>
> It's OK to just not have a get_status() operation - a lot of regulators
> just can't do this and that's fine, the subsystem will cope.
>
understood. it seems to be better with subsystem coping. we'll remove
get_status callback.
> > > > +static const struct of_device_id mt6380_of_match[] = {
> > > > + { .compatible = "mediatek,mt6380-regulator", },
> > > > + { /* sentinel */ },
> > > > +};
> > > > +MODULE_DEVICE_TABLE(of, mt6380_of_match);
>
> > > Given that this driver is entirely specific to the parent PMIC there
> > > should be no need for a separate compatible string, it's redundant.
>
> > the parent of pmic is MediaTek pwrap which is possibly being used with
> > various pmics such as MT6323, MT6797, MT6380 and so on. So extra
> > matching we thought is required to identify which pmic is actually being
> > connected.
>
> > For those opinions, maybe we didn't get your exact point. If something
> > is wrong, please kindly guide us to the right place.
>
> It sounds like pwrap should be a bus rather than using a platform device
> here? But I guess that's how things are for now so OK.
yes, it is a bus , a proprietary bus, which is something like
encapsulation of spi and there's some protocol running on this
between master/slave.
Re: WARN_ON_ONCE() in process_one_work()?
On Wed, Jun 21, 2017 at 08:30:35AM -0700, Paul E. McKenney wrote: > On Tue, Jun 20, 2017 at 09:45:23AM -0700, Paul E. McKenney wrote: > > On Sun, Jun 18, 2017 at 06:40:00AM -0400, Tejun Heo wrote: > > > Hello, > > > > > > On Sat, Jun 17, 2017 at 10:31:05AM -0700, Paul E. McKenney wrote: > > > > On Sat, Jun 17, 2017 at 07:53:14AM -0400, Tejun Heo wrote: > > > > > Hello, > > > > > > > > > > On Fri, Jun 16, 2017 at 10:36:58AM -0700, Paul E. McKenney wrote: > > > > > > And no test failures from yesterday evening. So it looks like we > > > > > > get > > > > > > somewhere on the order of one failure per 138 hours of TREE07 > > > > > > rcutorture > > > > > > runtime with your printk() in the mix. > > > > > > > > > > > > Was the above output from your printk() output of any help? > > > > > > > > > > Yeah, if my suspicion is correct, it'd require new kworker creation > > > > > racing against CPU offline, which would explain why it's so difficult > > > > > to repro. Can you please see whether the following patch resolves the > > > > > issue? > > > > > > > > That could explain why only Steve Rostedt and I saw the issue. As far > > > > as I know, we are the only ones who regularly run CPU-hotplug stress > > > > tests. ;-) > > > > > > I was a bit confused. It has to be racing against either new kworker > > > being created on the wrong CPU or rescuer trying to migrate to the > > > CPU, and it looks like we're mostly seeing the rescuer condition, but, > > > yeah, this would only get triggered rarely. Another contributing > > > factor could be the vmstat work putting on a workqueue w/ rescuer > > > recently. It runs quite often, so probably has increased the chance > > > of hitting the right condition. > > > > Sounds like too much fun! ;-) > > > > But more constructively... If I understand correctly, it is now possible > > to take a CPU partially offline and put it back online again. This should > > allow much more intense testing of this sort of interaction. > > > > And no, I haven't yet tried this with RCU because I would probably need > > to do some mix of just-RCU online/offline and full-up online-offline. > > Plus RCU requires pretty much a full online/offline cycle to fully > > exercise it. :-/ > > > > > > I have a weekend-long run going, but will give this a shot overnight on > > > > Monday, Pacific Time. Thank you for putting it together, looking > > > > forward > > > > to seeing what it does! > > > > > > Thanks a lot for the testing and patience. Sorry that it took so > > > long. I'm not completely sure the patch is correct. It might have to > > > be more specifc about which type of migration or require further > > > synchronization around migration, but hopefully it'll at least be able > > > to show that this was the cause of the problem. > > > > And last night's tests had no failures. Which might actually mean > > something, will get more info when I run without your patch this > > evening. ;-) > > And it didn't fail without the patch, either. 45 hours of test vs. > 60 hours with the patch. This one is not going to be easy to prove > either way. I will try again this evening without the patch and see > what that gets us. And another 36 hours (total of 81 hours) without the patch, still no failure. Sigh. In the sense that the patch doesn't cause any new problem: Tested-by: Paul E. McKenney But I clearly have nothing of statistical significance, so any confidence in the fix is coming from your reproducer. Thanx, Paul
Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations
On Fri, 23 Jun 2017 10:31:28 +0200 Gerd Hoffmann wrote: > On Fri, 2017-06-23 at 15:49 +0800, Zhi Wang wrote: > > Hi: > > Thanks for the discussions! If the userspace application has > > already maintained a LRU list, it looks like we don't need > > generation > > anymore, > > generation isn't required, things are working just fine without that. > It is just a small optimization, userspace can skip the LRU lookup > altogether if the generation didn't change. > > But of couse that only pays off if the kernel doesn't has to put much > effort into maintaining the generation id. Something simple like > increasing it each time the guest writes a register which affects > plane_info. But it seems like that simple management algorithm pretty much guarantees that the kernel will never revisit a generation and therefore caching dmabuf fds is pointless. AIUI the optimization is to allow userspace to 'at a glance' test one plane_info vs another. The user could also do this with a memcmp of the plane_info structs if that's its only purpose. A randomly incremented field within that struct could actually be a hindrance to the user for such a comparison. Are there cases where the plane_info struct is otherwise identical where the user would need to get a new dmabuf fd anyway? Thanks, Alex
Re: [PATCH] qla2xxx: Protect access to qpair members with qpair->qp_lock (fwd)
Please check on whether an unlock is neeed before line 1965.
julia
-- Forwarded message --
Date: Fri, 23 Jun 2017 15:23:00 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: Re: [PATCH] qla2xxx: Protect access to qpair members with
qpair->qp_lock
CC: kbuild-...@01.org
In-Reply-To: <20170622134325.26931-1-jthumsh...@suse.de>
Hi Johannes,
[auto build test WARNING on scsi/for-next]
[also build test WARNING on v4.12-rc6 next-20170622]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Johannes-Thumshirn/qla2xxx-Protect-access-to-qpair-members-with-qpair-qp_lock/20170623-123844
base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
:: branch date: 3 hours ago
:: commit date: 3 hours ago
>> drivers/scsi/qla2xxx/qla_iocb.c:1965:3-9: preceding lock on line 1952
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 4a35d720268dbe9ac016957a3c4fc644398d68ba
vim +1965 drivers/scsi/qla2xxx/qla_iocb.c
d74595278 Michael Hernandez 2016-12-12 1946 /* Only process protection or
>16 cdb in this routine */
d74595278 Michael Hernandez 2016-12-12 1947 if (scsi_get_prot_op(cmd) ==
SCSI_PROT_NORMAL) {
d74595278 Michael Hernandez 2016-12-12 1948 if (cmd->cmd_len <= 16)
d74595278 Michael Hernandez 2016-12-12 1949 return
qla2xxx_start_scsi_mq(sp);
d74595278 Michael Hernandez 2016-12-12 1950 }
d74595278 Michael Hernandez 2016-12-12 1951
4a35d7202 Johannes Thumshirn 2017-06-22 @1952
spin_lock_irqsave(&qpair->qp_lock, flags);
4a35d7202 Johannes Thumshirn 2017-06-22 1953
d74595278 Michael Hernandez 2016-12-12 1954 /* Setup qpair pointers */
d74595278 Michael Hernandez 2016-12-12 1955 rsp = qpair->rsp;
d74595278 Michael Hernandez 2016-12-12 1956 req = qpair->req;
d74595278 Michael Hernandez 2016-12-12 1957
d74595278 Michael Hernandez 2016-12-12 1958 /* So we know we haven't
pci_map'ed anything yet */
d74595278 Michael Hernandez 2016-12-12 1959 tot_dsds = 0;
d74595278 Michael Hernandez 2016-12-12 1960
d74595278 Michael Hernandez 2016-12-12 1961 /* Send marker if required */
d74595278 Michael Hernandez 2016-12-12 1962 if (vha->marker_needed != 0) {
d74595278 Michael Hernandez 2016-12-12 1963 if (qla2x00_marker(vha,
req, rsp, 0, 0, MK_SYNC_ALL) !=
d74595278 Michael Hernandez 2016-12-12 1964 QLA_SUCCESS)
d74595278 Michael Hernandez 2016-12-12 @1965 return
QLA_FUNCTION_FAILED;
d74595278 Michael Hernandez 2016-12-12 1966 vha->marker_needed = 0;
d74595278 Michael Hernandez 2016-12-12 1967 }
d74595278 Michael Hernandez 2016-12-12 1968
:: The code at line 1965 was first introduced by commit
:: d74595278f4ab192af66d9e60a9087464638beee scsi: qla2xxx: Add multiple
queue pair functionality.
:: TO: Michael Hernandez
:: CC: Martin K. Petersen
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH v9 1/5] firmware: add extensible driver data params
On Wed, Jun 21, 2017 at 09:49:35AM +0900, AKASHI Takahiro wrote: > On Tue, Jun 20, 2017 at 07:22:19PM +0200, Luis R. Rodriguez wrote: > > On Tue, Jun 20, 2017 at 09:27:45AM -0700, Vikram Mulukutla wrote: > > > > > > perhaps a light > > > internal rework inside firmware_class might be more suitable towards the > > > extensibility goal while keeping driver API usage as simple as it is today > > > (even if you hate my patch for various reasons)? > > > > > > [1] - > > > https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/drivers/base/firmware_class.c?h=msm-3.18&id=7aa7efd3c150840369739893a84bd1d9f9774319 > > > > What you did is but one step I took, your changes make it easier to shuffle > > data around internally. Its not sufficient to clean things up well enough, > > for > > instance look at the "firmware behavior options" which are cleaned up in > > this > > patch 1/5. That's been one pain on our side for a while, people > > understanding > > when a flag applies or a feature, and making sure we document it all. > > > > Then, one of the end goals is to provide extensibility, this is to allow > > users > > to *pass* similar type of struct for either a sync or async call. Without > > this > > the API remains unflexible and I predict we'll end up with the same > > situation > > later anyway. > > > > The approach I took uses an internal struct for passing required data for > > the > > private internal API use. Then it also provides a public struct which can be > > used to grow requirements to make only *new* API easily extensible. > > > > So we need all three things to move forward. > > Given the discussions here, it would be better to split your [1/5] and > [2/5] into more smaller pieces, say, > * re-factor the old APIs with introducing private fw_desc So patch 1/5 introduces 3 structs: o struct driver_data_req_params - used for user specified parameters o struct driver_data_priv_params - used for internal use only o struct driver_data_params - stiches both of the above together, only for internal use I could certainly split the patch to introduce each separately. > * add new APIs with extra public arguments This was split out already, patch 2 is the first patch introducing new API. > * extend new APIs per-feature > - sync/async callbacks I suppose the base would be what we have today, only in new form. And sure, I can add the features one by one... > - API version, and so on Right. > This way, you can illustrate how your approach evolves and it may > mitigate people's concern about how complicated it is on the surface, > allowing for discussing each of aspects of new APIs separately. This makes sense. Greg, does this make sense to you? Or are you stone cold against all this? Luis
[PATCH] x86: Remove unnecessary return from void function
The patch removes unnecessary return from void function.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton Vasilyev
---
arch/x86/include/asm/paravirt.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 55fa56f..a3dcf89 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -118,7 +118,7 @@ static inline u64 paravirt_read_msr(unsigned msr)
static inline void paravirt_write_msr(unsigned msr,
unsigned low, unsigned high)
{
- return PVOP_VCALL3(pv_cpu_ops.write_msr, msr, low, high);
+ PVOP_VCALL3(pv_cpu_ops.write_msr, msr, low, high);
}
static inline u64 paravirt_read_msr_safe(unsigned msr, int *err)
--
2.7.4
Re: fs, net: deadlock between bind/splice on af_unix
Hi, On Thu, Jun 22, 2017 at 10:49 AM, wrote: > I was getting below crash while running mp4. Are you sure your 3.14 kernel has my patch in this thread? commit 0fb44559ffd67de8517098 is merged in 4.10. Also, your crash is on unix_dgram_sendmsg() path, not unix_bind().
Re: [PATCH 0/3] Enable namespaced file capabilities
Quoting Casey Schaufler (ca...@schaufler-ca.com): > On 6/23/2017 9:00 AM, Serge E. Hallyn wrote: > > Quoting Amir Goldstein (amir7...@gmail.com): > >> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger > >> wrote: > >>> This series of patches primary goal is to enable file capabilities > >>> in user namespaces without affecting the file capabilities that are > >>> effective on the host. This is to prevent that any unprivileged user > >>> on the host maps his own uid to root in a private namespace, writes > >>> the xattr, and executes the file with privilege on the host. > >>> > >>> We achieve this goal by writing extended attributes with a different > >>> name when a user namespace is used. If for example the root user > >>> in a user namespace writes the security.capability xattr, the name > >>> of the xattr that is actually written is encoded as > >>> security.capability@uid=1000 for root mapped to uid 1000 on the host. > >>> When listing the xattrs on the host, the existing security.capability > >>> as well as the security.capability@uid=1000 will be shown. Inside the > >>> namespace only 'security.capability', with the value of > >>> security.capability@uid=1000, is visible. > >>> > >> Am I the only one who thinks that suffix is perhaps not the best grammar > >> to use for this namespace? > > You're the only one to have mentioned it so far. > > > >> xattrs are clearly namespaced by prefix, so it seems right to me to keep > >> it that way - define a new special xattr namespace "ns" and only if that > >> prefix exists, the @uid suffix will be parsed. > >> This could be either ns.security.capability@uid=1000 or > >> ns@uid=1000.security.capability. The latter seems more correct to me, > >> because then we will be able to namespace any xattr without having to > >> protect from "unprivileged xattr injection", i.e.: > >> setfattr -n "user.whatever.foo@uid=0" > > I like it for simplifying the parser code. One concern I have is that, > > since ns.* is currently not gated, one could write ns.* on an older > > kernel and then exploit it on a newer one. > > security.ns.capability@uid=1000, then? That loses the advantage of simpler parsing though. (Really it's not much of a simplification anyway.) So I'm not sure what advantage remains. > Or maybe just security.ns.capability, taking James' comment into account. That last one may be suitable as an option, useful for his particular (somewhat barbaric :) use case, but it's not ok for the general solution. If uid 1000 was delegated the subuids 10-19, it should be able to write a file capability for use by his subuids, but that file capability must not apply to other subuids. -serge
Re: [PATCH V2] kernel/watchdog: fix spurious hard lockups
On Fri, Jun 23, 2017 at 10:01:55AM +0200, Thomas Gleixner wrote:
> On Thu, 22 Jun 2017, Don Zickus wrote:
> > On Wed, Jun 21, 2017 at 11:53:57PM +0200, Thomas Gleixner wrote:
> > > On Wed, 21 Jun 2017, kan.li...@intel.com wrote:
> > > > We now have more and more systems where the Turbo range is wide enough
> > > > that the NMI watchdog expires faster than the soft watchdog timer that
> > > > updates the interrupt tick the NMI watchdog relies on.
> > > >
> > > > This problem was originally added by commit 58687acba592
> > > > ("lockup_detector: Combine nmi_watchdog and softlockup detector").
> > > > Previously the NMI watchdog would always check jiffies, which were
> > > > ticking fast enough. But now the backing is quite slow so the expire
> > > > time becomes more sensitive.
> > >
> > > And slapping a factor 3 on the NMI period is the wrong answer to the
> > > problem. The simple solution would be to increase the hrtimer frequency,
> > > but that's not really desired either.
> > >
> > > Find an untested patch below, which should cure the issue.
> >
> > A simple low pass filter. It compiles. :-) I don't think I have knowledge
> > to test it. Kan?
>
> Yes, and it has an interesting twist. It's only working once we have
> switched to TSC as clocksource.
>
> As long as jiffies are the clocksource, this will miserably fail because
> when the hrtimer interrupt is not delivered jiffies wont be incremented
> either and the NMI will say: Oh. not enough time elapsed. Lather, rinse and
> repeat.
>
> One simple way to fix this is with the delta patch below.
Hmm, all this work for a temp fix. Kan, how much longer until the real fix
of having perf count the right cycles?
Cheers,
Don
>
> Thanks,
>
> tglx
>
> 8<--
> --- a/kernel/watchdog_hld.c
> +++ b/kernel/watchdog_hld.c
> @@ -72,6 +72,7 @@ EXPORT_SYMBOL(touch_nmi_watchdog);
>
> #ifdef CONFIG_HARDLOCKUP_CHECK_TIMESTAMP
> static DEFINE_PER_CPU(ktime_t, last_timestamp);
> +static DEFINE_PER_CPU(unsigned int, nmi_rearmed);
> static ktime_t watchdog_hrtimer_sample_threshold __read_mostly;
>
> void watchdog_update_hrtimer_threshold(u64 period)
> @@ -105,8 +106,11 @@ static bool watchdog_check_timestamp(voi
> ktime_t delta, now = ktime_get_mono_fast_ns();
>
> delta = now - __this_cpu_read(last_timestamp);
> - if (delta < watchdog_hrtimer_sample_threshold)
> - return false;
> + if (delta < watchdog_hrtimer_sample_threshold) {
> + if (__this_cpu_inc_return(nmi_rearmed) < 10)
> + return false;
> + }
> + __this_cpu_write(nmi_rearmed, 0);
> __this_cpu_write(last_timestamp, now);
> return true;
> }
>
>
Re: [PATCH 05/11] net: stmmac: dwmac-rk: Add internal phy support
On 06/22/2017 09:59 PM, David Wu wrote:
> To make internal phy worked, need to configure the phy_clock,
> phy cru_reset and related registers.
>
> Change-Id: I6971c0a769754b824b1b908b56080cbaf7867d13
> Signed-off-by: David Wu
> ---
> .../devicetree/bindings/net/rockchip-dwmac.txt | 3 +
> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 82
> ++
> 2 files changed, 85 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> index 8f42755..0514f69 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> @@ -22,6 +22,7 @@ Required properties:
> <&cru SCLK_MACREF_OUT> clock gate for RMII reference clock output
> <&cru ACLK_GMAC>: AXI clock gate for GMAC
> <&cru PCLK_GMAC>: APB clock gate for GMAC
> +<&cru MAC_PHY>: clock for internal macphy
> - clock-names: One name for each entry in the clocks property.
> - phy-mode: See ethernet.txt file in the same directory.
> - pinctrl-names: Names corresponding to the numbered pinctrl states.
> @@ -35,6 +36,8 @@ Required properties:
> - assigned-clocks: main clock, should be <&cru SCLK_MAC>;
> - assigned-clock-parents = parent of main clock.
> can be <&ext_gmac> or <&cru SCLK_MAC_PLL>.
> + - phy-type: For internal phy, it must be "internal"; For external phy, no
> need
> + to configure this.
Use the standard "phy-mode" property. You will see
drivers/net/ethernet/broadcom/genet/ actually define a phy-mode =
"internal" property specifically for that. This should probably be
generalized so it is useful to other drivers a well, I will do just that.
>
> Optional properties:
> - tx_delay: Delay value for TXD timing. Range value is 0~0x7F, 0x30 as
> default.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> index a8e8fd5..c1a1413 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -41,6 +41,7 @@ struct rk_gmac_ops {
> void (*set_to_rmii)(struct rk_priv_data *bsp_priv);
> void (*set_rgmii_speed)(struct rk_priv_data *bsp_priv, int speed);
> void (*set_rmii_speed)(struct rk_priv_data *bsp_priv, int speed);
> + void (*internal_phy_powerup)(struct rk_priv_data *bsp_priv);
> };
>
> struct rk_priv_data {
> @@ -52,6 +53,7 @@ struct rk_priv_data {
>
> bool clk_enabled;
> bool clock_input;
> + bool internal_phy;
>
> struct clk *clk_mac;
> struct clk *gmac_clkin;
> @@ -61,6 +63,9 @@ struct rk_priv_data {
> struct clk *clk_mac_refout;
> struct clk *aclk_mac;
> struct clk *pclk_mac;
> + struct clk *clk_macphy;
> +
> + struct reset_control *macphy_reset;
>
> int tx_delay;
> int rx_delay;
> @@ -750,6 +755,48 @@ static void rk3399_set_rmii_speed(struct rk_priv_data
> *bsp_priv, int speed)
> .set_rmii_speed = rk3399_set_rmii_speed,
> };
>
> +#define RK_GRF_MACPHY_CON0 0xb00
> +#define RK_GRF_MACPHY_CON1 0xb04
> +#define RK_GRF_MACPHY_CON2 0xb08
> +#define RK_GRF_MACPHY_CON3 0xb0c
> +
> +#define RK_MACPHY_ENABLE GRF_BIT(0)
> +#define RK_MACPHY_DISABLEGRF_CLR_BIT(0)
> +#define RK_MACPHY_CFG_CLK_50MGRF_BIT(14)
> +#define RK_GMAC2PHY_RMII_MODE(GRF_BIT(6) | GRF_CLR_BIT(7))
> +#define RK_GRF_CON2_MACPHY_IDHIWORD_UPDATE(0x1234, 0x, 0)
> +#define RK_GRF_CON3_MACPHY_IDHIWORD_UPDATE(0x35, 0x3f, 0)
> +
> +static void rk_gmac_internal_phy_powerup(struct rk_priv_data *priv)
> +{
> + if (priv->ops->internal_phy_powerup)
> + priv->ops->internal_phy_powerup(priv);
> +
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_CFG_CLK_50M);
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_GMAC2PHY_RMII_MODE);
> +
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON2, RK_GRF_CON2_MACPHY_ID);
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON3, RK_GRF_CON3_MACPHY_ID);
> +
> + /* disable macphy, the default value is enabled */
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_DISABLE);
> + if (priv->macphy_reset)
> + reset_control_assert(priv->macphy_reset);
> + usleep_range(10, 20);
> + if (priv->macphy_reset)
> + reset_control_deassert(priv->macphy_reset);
> + usleep_range(10, 20);
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_ENABLE);
> + msleep(30);
> +}
> +
> +static void rk_gmac_internal_phy_powerdown(struct rk_priv_data *priv)
> +{
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_DISABLE);
> + if (priv->macphy_reset)
> + reset_control_assert(priv->macphy_reset);
> +}
> +
> static int gmac_clk_init(struct rk_priv_data *bsp_priv)
> {
> struct
Re: [PATCH 01/11] net: phy: Add rockchip phy driver support
On 06/22/2017 09:41 PM, David Wu wrote:
> Support internal ephy currently.
>
> Signed-off-by: David Wu
> ---
> drivers/net/phy/Kconfig| 4 ++
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/rockchip.c | 94
> ++
> 3 files changed, 99 insertions(+)
> create mode 100644 drivers/net/phy/rockchip.c
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index c360dd6..86010d4 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -350,6 +350,10 @@ config XILINX_GMII2RGMII
> the Reduced Gigabit Media Independent Interface(RGMII) between
> Ethernet physical media devices and the Gigabit Ethernet controller.
>
> +config ROCKCHIP_MAC_PHY
> + tristate "Drivers for ROCKCHIP MAC PHY"
> + ---help---
> + Currently supports the mac internal ephy.
> endif # PHYLIB
>
> config MICREL_KS8995MA
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index e36db9a..6d96779 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -69,3 +69,4 @@ obj-$(CONFIG_STE10XP) += ste10Xp.o
> obj-$(CONFIG_TERANETICS_PHY) += teranetics.o
> obj-$(CONFIG_VITESSE_PHY)+= vitesse.o
> obj-$(CONFIG_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
> +obj-$(CONFIG_ROCKCHIP_MAC_PHY) += rockchip.o
> diff --git a/drivers/net/phy/rockchip.c b/drivers/net/phy/rockchip.c
> new file mode 100644
> index 000..69e96ec
> --- /dev/null
> +++ b/drivers/net/phy/rockchip.c
> @@ -0,0 +1,94 @@
> +/**
> + * Rockchip mac phy driver
MAC and PHY, capitalized.
> + *
> + * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * David Wu
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int internal_config_init(struct phy_device *phydev)
> +{
> + int val;
> + u32 features;
> +
> + /*enable auto mdix*/
> + phy_write(phydev, 0x11, 0x0080);
That is probably the only meaningful change needed by this driver, and
even that is not quite correct because auto MDI-X can be changed from
user-space through ethtool, see
drivers/net/phy/marvell.c::marvell_config_aneg()
> +
> + features = (SUPPORTED_TP | SUPPORTED_MII
> + | SUPPORTED_AUI | SUPPORTED_FIBRE |
> + SUPPORTED_BNC);
This is not necessary, using driver::features set to PHY_GBIT_FEATURES
> +
> + /* Do we support autonegotiation? */
> + val = phy_read(phydev, MII_BMSR);
> + if (val < 0)
> + return val;
> +
> + if (val & BMSR_ANEGCAPABLE)
> + features |= SUPPORTED_Autoneg;
If we have disabled auto-negotiation prior to probing this driver, and
somehow the PHY is not reset, then you are falsely not advertising
support for auto-negotiation just because it *currently is* disabled.
> +
> + if (val & BMSR_100FULL)
> + features |= SUPPORTED_100baseT_Full;
> + if (val & BMSR_100HALF)
> + features |= SUPPORTED_100baseT_Half;
> + if (val & BMSR_10FULL)
> + features |= SUPPORTED_10baseT_Full;
> + if (val & BMSR_10HALF)
> + features |= SUPPORTED_10baseT_Half;
> +
> + if (val & BMSR_ESTATEN) {
> + val = phy_read(phydev, MII_ESTATUS);
> + if (val < 0)
> + return val;
> +
> + if (val & ESTATUS_1000_TFULL)
> + features |= SUPPORTED_1000baseT_Full;
> + if (val & ESTATUS_1000_THALF)
> + features |= SUPPORTED_1000baseT_Half;
> + }
> +
> + phydev->supported = features;
> + phydev->advertising = features;
> +
> + return 0;
> +}
> +
> +static struct phy_driver rockchip_phy_driver[] = {
> +{
> + .phy_id = 0x1234d400,
> + .phy_id_mask= 0x,
Last 4 digits are supposed to hold the revision, do you really need to
have such a strict mask here?
> + .name = "rockchip internal ephy",
> + .features = 0,
features shoul dbe set to what you support: PHY_GBIT_FEAUTERS
> + .config_init= internal_config_init,
> + .config_aneg= genphy_config_aneg,
> + .read_status= genphy_read_status,
> + .suspend= genphy_suspend,
> + .resume = genphy_resume,
> +},
> +};
> +
> +module_phy_driver(rockchip_phy_driver);
> +
> +static struct mdio_device_id __maybe_unused rockchip_phy_tbl[] = {
> + { 0x1234d400, 0x },
> + { }
> +};
> +
> +MODULE_DEVICE_TABLE(mdio, rockchip_phy_tbl);
> +
> +MODULE_AUTHOR("David Wu");
> +MODULE_DESCRIPTION("Rockchip mac phy driver");
> +MODULE_LICENSE("GPL v2");
>
--
Florian
Re: [PATCH 0/3] Enable namespaced file capabilities
On 6/23/2017 9:00 AM, Serge E. Hallyn wrote: > Quoting Amir Goldstein (amir7...@gmail.com): >> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger >> wrote: >>> This series of patches primary goal is to enable file capabilities >>> in user namespaces without affecting the file capabilities that are >>> effective on the host. This is to prevent that any unprivileged user >>> on the host maps his own uid to root in a private namespace, writes >>> the xattr, and executes the file with privilege on the host. >>> >>> We achieve this goal by writing extended attributes with a different >>> name when a user namespace is used. If for example the root user >>> in a user namespace writes the security.capability xattr, the name >>> of the xattr that is actually written is encoded as >>> security.capability@uid=1000 for root mapped to uid 1000 on the host. >>> When listing the xattrs on the host, the existing security.capability >>> as well as the security.capability@uid=1000 will be shown. Inside the >>> namespace only 'security.capability', with the value of >>> security.capability@uid=1000, is visible. >>> >> Am I the only one who thinks that suffix is perhaps not the best grammar >> to use for this namespace? > You're the only one to have mentioned it so far. > >> xattrs are clearly namespaced by prefix, so it seems right to me to keep >> it that way - define a new special xattr namespace "ns" and only if that >> prefix exists, the @uid suffix will be parsed. >> This could be either ns.security.capability@uid=1000 or >> ns@uid=1000.security.capability. The latter seems more correct to me, >> because then we will be able to namespace any xattr without having to >> protect from "unprivileged xattr injection", i.e.: >> setfattr -n "user.whatever.foo@uid=0" > I like it for simplifying the parser code. One concern I have is that, > since ns.* is currently not gated, one could write ns.* on an older > kernel and then exploit it on a newer one. security.ns.capability@uid=1000, then? Or maybe just security.ns.capability, taking James' comment into account. > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH v8 1/3] clk: qcom: Add A53 PLL support
The CPUs on Qualcomm MSM8916-based platforms are clocked by two PLLs,
a primary (A53) CPU PLL and a secondary fixed-rate GPLL0. These sources
are connected to a mux and half-integer divider, which is feeding the
CPU cores.
This patch adds support for the primary CPU PLL which generates the
higher range of frequencies above 1GHz.
Signed-off-by: Georgi Djakov
---
.../devicetree/bindings/clock/qcom,a53pll.txt | 22 +
drivers/clk/qcom/Kconfig | 9 +++
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/a53-pll.c | 94 ++
4 files changed, 126 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53pll.txt
create mode 100644 drivers/clk/qcom/a53-pll.c
diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.txt
b/Documentation/devicetree/bindings/clock/qcom,a53pll.txt
new file mode 100644
index ..f4c2fddf6e7f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.txt
@@ -0,0 +1,22 @@
+MSM8916 A53 PLL Binding
+---
+The A53 PLL on MSM8916 platforms is the main CPU PLL used used for frequencies
+above 1GHz.
+
+Required properties :
+- compatible : Shall contain only one of the following:
+
+ "qcom,msm8916-a53pll"
+
+- reg : shall contain base register location and length
+
+- #clock-cells : must be set to <0>
+
+Example:
+
+ a53pll: clock@b016000 {
+ compatible = "qcom,msm8916-a53pll";
+ reg = <0xb016000 0x40>;
+ #clock-cells = <0>;
+ };
+
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 9f6c278deead..057cf60ed037 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -12,6 +12,15 @@ config COMMON_CLK_QCOM
select REGMAP_MMIO
select RESET_CONTROLLER
+config QCOM_A53PLL
+ bool "A53 PLL"
+ depends on COMMON_CLK_QCOM
+ help
+ Support for the A53 PLL on Qualcomm MSM8916 devices. It provides
+ support for CPU frequencies above 1GHz.
+ Say Y if you want to support CPU frequency scaling on devices
+ such as MSM8916.
+
config QCOM_CLK_RPM
tristate "RPM based Clock Controller"
depends on COMMON_CLK_QCOM && MFD_QCOM_RPM
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 3f3aff229fb7..19ae884b5166 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -31,5 +31,6 @@ obj-$(CONFIG_MSM_LCC_8960) += lcc-msm8960.o
obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
+obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o
obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
diff --git a/drivers/clk/qcom/a53-pll.c b/drivers/clk/qcom/a53-pll.c
new file mode 100644
index ..e039937e89fc
--- /dev/null
+++ b/drivers/clk/qcom/a53-pll.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (c) 2017, Linaro Limited
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "clk-pll.h"
+#include "clk-regmap.h"
+
+static const struct pll_freq_tbl a53pll_freq[] = {
+ { 99840, 52, 0x0, 0x1, 0 },
+ { 109440, 57, 0x0, 0x1, 0 },
+ { 115200, 62, 0x0, 0x1, 0 },
+ { 120960, 65, 0x0, 0x1, 0 },
+ { 140160, 73, 0x0, 0x1, 0 },
+};
+
+static const struct regmap_config a53pll_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0x40,
+ .fast_io= true,
+ .val_format_endian = REGMAP_ENDIAN_LITTLE,
+};
+
+static const struct of_device_id qcom_a53pll_match_table[] = {
+ { .compatible = "qcom,msm8916-a53pll" },
+ { }
+};
+
+static int qcom_a53pll_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct clk_pll *pll;
+ struct resource *res;
+ void __iomem *base;
+ struct regmap *regmap;
+ struct clk_init_data init = { };
+
+ pll = devm_kzalloc(dev, sizeof(*pll), GFP_KERNEL);
+ if (!pll)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ regmap = devm_regmap_init_mmio(dev, base, &a53pl
Re: [PATCH v3 4/4] kmod: throttle kmod thread limit
On Thu, Jun 22, 2017 at 05:19:36PM +0200, Petr Mladek wrote:
> On Fri 2017-05-26 14:12:28, Luis R. Rodriguez wrote:
> > --- a/kernel/kmod.c
> > +++ b/kernel/kmod.c
> > @@ -163,14 +163,11 @@ int __request_module(bool wait, const char *fmt, ...)
> > return ret;
> >
> > if (atomic_dec_if_positive(&kmod_concurrent_max) < 0) {
> > - /* We may be blaming an innocent here, but unlikely */
> > - if (kmod_loop_msg < 5) {
> > - printk(KERN_ERR
> > - "request_module: runaway loop modprobe %s\n",
> > - module_name);
> > - kmod_loop_msg++;
> > - }
> > - return -ENOMEM;
> > + pr_warn_ratelimited("request_module: kmod_concurrent_max (%u)
> > close to 0 (max_modprobes: %u), for module %s\n, throttling...",
> > + atomic_read(&kmod_concurrent_max),
> > + 50, module_name);
>
> It is weird to pass the constant '50' via %s.
The 50 was passed with %u, so I take it you meant it is odd to use a parameter
for it.
> Also a #define should be
> used to keep it in sync with the kmod_concurrent_max initialization.
OK.
> > + wait_event_interruptible(kmod_wq,
> > +
> > atomic_dec_if_positive(&kmod_concurrent_max) >= 0);
> > }
> >
> > trace_module_request(module_name, wait, _RET_IP_);
> > @@ -178,6 +175,7 @@ int __request_module(bool wait, const char *fmt, ...)
> > ret = call_modprobe(module_name, wait ? UMH_WAIT_PROC : UMH_WAIT_EXEC);
> >
> > atomic_inc(&kmod_concurrent_max);
> > + wake_up_all(&kmod_wq);
>
> Does it make sense to wake up all waiters when we released the resource
> only for one? IMHO, a simple wake_up() should be here.
Then we should wake_up() also on failure, otherwise we have the potential
to not wake some in a proper time.
> I am sorry for the late review. The month ran really fast.
No worries!
Luis
Applied "spi: atmel: fix corrupted data issue on SAM9 family SoCs" to the spi tree
The patch
spi: atmel: fix corrupted data issue on SAM9 family SoCs
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 7094576ccdc3acfe1e06a1e2ab547add375baf7f Mon Sep 17 00:00:00 2001
From: Cyrille Pitchen
Date: Fri, 23 Jun 2017 17:39:16 +0200
Subject: [PATCH] spi: atmel: fix corrupted data issue on SAM9 family SoCs
This patch disables the use of the DMA for data transfer and forces the
use of PIO transfers instead as a quick fixup to solve the cache aliasing
issue on ARM9 based cores, which embeds a VIVT data cache.
Indeed in the case of VIVT data caches, it is not safe to call dma_map_*()
functions to map buffers for DMA transfers when those buffers have been
allocated by vmalloc() or from any DMA-unsafe area.
Further patches may propose a better solution based on the use of a bounce
buffer at the SPI sub-system level but such solution needs more time to be
discussed. Then the use of DMA transfers could be enabled again to improve
the performances but before that, this patch already solves the issue.
Signed-off-by: Cyrille Pitchen
Acked-by: Nicolas Ferre
Signed-off-by: Mark Brown
Cc: sta...@vger.kernel.org
---
drivers/spi/spi-atmel.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 1eb83c9613d5..78c885d80c96 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -269,6 +269,7 @@ struct atmel_spi_caps {
boolis_spi2;
boolhas_wdrbt;
boolhas_dma_support;
+ boolhas_pdc_support;
};
/*
@@ -1426,7 +1427,28 @@ static void atmel_get_caps(struct atmel_spi *as)
as->caps.is_spi2 = version > 0x121;
as->caps.has_wdrbt = version >= 0x210;
+#ifdef CONFIG_SOC_SAM_V4_V5
+ /*
+* Atmel SoCs based on ARM9 (SAM9x) cores should not use spi_map_buf()
+* since this later function tries to map buffers with dma_map_sg()
+* even if they have not been allocated inside DMA-safe areas.
+* On SoCs based on Cortex A5 (SAMA5Dx), it works anyway because for
+* those ARM cores, the data cache follows the PIPT model.
+* Also the L2 cache controller of SAMA5D2 uses the PIPT model too.
+* In case of PIPT caches, there cannot be cache aliases.
+* However on ARM9 cores, the data cache follows the VIVT model, hence
+* the cache aliases issue can occur when buffers are allocated from
+* DMA-unsafe areas, by vmalloc() for instance, where cache coherency is
+* not taken into account or at least not handled completely (cache
+* lines of aliases are not invalidated).
+* This is not a theorical issue: it was reproduced when trying to mount
+* a UBI file-system on a at91sam9g35ek board.
+*/
+ as->caps.has_dma_support = false;
+#else
as->caps.has_dma_support = version >= 0x212;
+#endif
+ as->caps.has_pdc_support = version < 0x212;
}
/*-*/
@@ -1567,7 +1589,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
} else if (ret == -EPROBE_DEFER) {
return ret;
}
- } else {
+ } else if (as->caps.has_pdc_support) {
as->use_pdc = true;
}
--
2.13.1
[PATCH v8 0/3] Add support for Qualcomm A53 CPU clock
This patchset adds support for the A53 CPU clock and allows scaling of the CPU frequency on msm8916 based platforms. Changes since v7 (https://lkml.org/lkml/2016/10/31/296) * Add the APCS clock controller to the APCS driver to expose both the mailbox and clock controller functionality as discussed earlier: https://lkml.org/lkml/2016/11/14/860 * Changed the a53pll compatible string as suggested by Rob. Changes since v6 (https://lkml.org/lkml/2016/9/7/347) * Addressed various comments from Stephen Boyd Changes since v5 (https://lkml.org/lkml/2016/2/1/407) * Rebase to clk-next and update according to the recent API changes. Changes since v4 (https://lkml.org/lkml/2015/12/14/367) * Convert to builtin drivers as now __clk_lookup() is used Changes since v3 (https://lkml.org/lkml/2015/8/12/585) * Split driver into two parts - and separate A53 PLL and A53 clock controller drivers. * Drop the safe switch hook patch. Add a clock notifier in the clock provider to handle switching via safe mux and divider configuration. Changes since v2 (https://lkml.org/lkml/2015/7/24/526) * Drop gpll0_vote patch. * Switch to the new clk_hw_* APIs. * Rebase to the current clk-next. Changes since v1 (https://lkml.org/lkml/2015/6/12/193) * Drop SR2 PLL patch, as it is already applied. * Add gpll0_vote rate propagation patch. * Update/rebase patches to the current clk-next. Georgi Djakov (3): clk: qcom: Add A53 PLL support clk: qcom: Add regmap mux-div clocks support mailbox: qcom: Add support for APCS clock controller .../devicetree/bindings/clock/qcom,a53pll.txt | 22 ++ .../bindings/mailbox/qcom,apcs-kpss-global.txt | 5 + drivers/clk/qcom/Kconfig | 9 + drivers/clk/qcom/Makefile | 2 + drivers/clk/qcom/a53-pll.c | 94 drivers/clk/qcom/clk-regmap-mux-div.c | 237 + drivers/clk/qcom/clk-regmap-mux-div.h | 52 + drivers/mailbox/qcom-apcs-ipc-mailbox.c| 122 +++ 8 files changed, 543 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53pll.txt create mode 100644 drivers/clk/qcom/a53-pll.c create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.c create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.h
[PATCH v8 2/3] clk: qcom: Add regmap mux-div clocks support
Add support for hardware that can switch both parent clock and divider
at the same time. This avoids generating intermediate frequencies from
either the old parent clock and new divider or new parent clock and
old divider combinations.
Signed-off-by: Georgi Djakov
---
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/clk-regmap-mux-div.c | 237 ++
drivers/clk/qcom/clk-regmap-mux-div.h | 52
3 files changed, 290 insertions(+)
create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.c
create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.h
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 19ae884b5166..ac38c2b21847 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -9,6 +9,7 @@ clk-qcom-y += clk-rcg2.o
clk-qcom-y += clk-branch.o
clk-qcom-y += clk-regmap-divider.o
clk-qcom-y += clk-regmap-mux.o
+clk-qcom-y += clk-regmap-mux-div.o
clk-qcom-y += reset.o
clk-qcom-$(CONFIG_QCOM_GDSC) += gdsc.o
diff --git a/drivers/clk/qcom/clk-regmap-mux-div.c
b/drivers/clk/qcom/clk-regmap-mux-div.c
new file mode 100644
index ..5ec31ec3efa7
--- /dev/null
+++ b/drivers/clk/qcom/clk-regmap-mux-div.c
@@ -0,0 +1,237 @@
+/*
+ * Copyright (c) 2017, Linaro Limited
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "clk-regmap-mux-div.h"
+
+#define CMD_RCGR 0x0
+#define CMD_RCGR_UPDATEBIT(0)
+#define CMD_RCGR_DIRTY_CFG BIT(4)
+#define CMD_RCGR_ROOT_OFF BIT(31)
+#define CFG_RCGR 0x4
+
+#define to_clk_regmap_mux_div(_hw) \
+ container_of(to_clk_regmap(_hw), struct clk_regmap_mux_div, clkr)
+
+int __mux_div_set_src_div(struct clk_regmap_mux_div *md, u32 src, u32 div)
+{
+ int ret, count;
+ u32 val, mask;
+ const char *name = clk_hw_get_name(&md->clkr.hw);
+
+ val = (div << md->hid_shift) | (src << md->src_shift);
+ mask = ((BIT(md->hid_width) - 1) << md->hid_shift) |
+ ((BIT(md->src_width) - 1) << md->src_shift);
+
+ ret = regmap_update_bits(md->clkr.regmap, CFG_RCGR + md->reg_offset,
+mask, val);
+ if (ret)
+ return ret;
+
+ ret = regmap_update_bits(md->clkr.regmap, CMD_RCGR + md->reg_offset,
+CMD_RCGR_UPDATE, CMD_RCGR_UPDATE);
+ if (ret)
+ return ret;
+
+ /* Wait for update to take effect */
+ for (count = 500; count > 0; count--) {
+ ret = regmap_read(md->clkr.regmap, CMD_RCGR + md->reg_offset,
+ &val);
+ if (ret)
+ return ret;
+ if (!(val & CMD_RCGR_UPDATE))
+ return 0;
+ udelay(1);
+ }
+
+ pr_err("%s: RCG did not update its configuration", name);
+ return -EBUSY;
+}
+
+static void __mux_div_get_src_div(struct clk_regmap_mux_div *md, u32 *src,
+ u32 *div)
+{
+ u32 val, d, s;
+ const char *name = clk_hw_get_name(&md->clkr.hw);
+
+ regmap_read(md->clkr.regmap, CMD_RCGR + md->reg_offset, &val);
+
+ if (val & CMD_RCGR_DIRTY_CFG) {
+ pr_err("%s: RCG configuration is pending\n", name);
+ return;
+ }
+
+ regmap_read(md->clkr.regmap, CFG_RCGR + md->reg_offset, &val);
+ s = (val >> md->src_shift);
+ s &= BIT(md->src_width) - 1;
+ *src = s;
+
+ d = (val >> md->hid_shift);
+ d &= BIT(md->hid_width) - 1;
+ *div = d;
+}
+
+static inline bool is_better_rate(unsigned long req, unsigned long best,
+ unsigned long new)
+{
+ return (req <= new && new < best) || (best < req && best < new);
+}
+
+static int mux_div_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ struct clk_regmap_mux_div *md = to_clk_regmap_mux_div(hw);
+ unsigned int i, div, max_div;
+ unsigned long actual_rate, best_rate = 0;
+ unsigned long req_rate = req->rate;
+
+ for (i = 0; i < clk_hw_get_num_parents(hw); i++) {
+ struct clk_hw *parent = clk_hw_get_parent_by_index(hw, i);
+ unsigned long parent_rate = clk_hw_get_rate(parent);
+
+ max_div = BIT(md->hid_width) - 1;
+ for (div = 1; div < max_div; div++) {
+
[PATCH v8 3/3] mailbox: qcom: Add support for APCS clock controller
Add a driver for the APCS clock controller. It is part of the APCS
hardware block, which among other things implements also a combined
mux and half integer divider functionality. It can choose between a
fixed-rate clock or the dedicated APCS (A53) PLL. The source and the
divider can be set both at the same time.
This is required for enabling CPU frequency scaling on MSM8916-based
platforms.
Signed-off-by: Georgi Djakov
---
.../bindings/mailbox/qcom,apcs-kpss-global.txt | 5 +
drivers/mailbox/qcom-apcs-ipc-mailbox.c| 122 +
2 files changed, 127 insertions(+)
diff --git
a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt
b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt
index fb961c310f44..2432be307083 100644
--- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt
+++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt
@@ -21,6 +21,11 @@ platforms.
Value type:
Definition: as described in mailbox.txt, must be 1
+- #clock-cells:
+ Usage: required for msm8916 platforms
+ Value type:
+ Definition: as described in clock-bindings.txt, must be 0
+
= EXAMPLE
The following example describes the APCS HMSS found in MSM8996 and part of the
diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c
b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
index 9924c6d7f05d..da363c6580da 100644
--- a/drivers/mailbox/qcom-apcs-ipc-mailbox.c
+++ b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
@@ -11,6 +11,8 @@
* GNU General Public License for more details.
*/
+#include
+#include
#include
#include
#include
@@ -19,6 +21,34 @@
#include
#include
#include
+#include
+
+#include "../clk/qcom/clk-regmap.h"
+#include "../clk/qcom/clk-regmap-mux-div.h"
+
+enum {
+ P_GPLL0,
+ P_A53PLL,
+};
+
+static const struct parent_map gpll0_a53cc_map[] = {
+ { P_GPLL0, 4 },
+ { P_A53PLL, 5 },
+};
+
+static const char * const gpll0_a53cc[] = {
+ "gpll0_vote",
+ "a53pll",
+};
+
+static const struct regmap_config a53cc_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0x1000,
+ .fast_io= true,
+ .val_format_endian = REGMAP_ENDIAN_LITTLE,
+};
#define QCOM_APCS_IPC_BITS 32
@@ -45,8 +75,93 @@ static const struct mbox_chan_ops qcom_apcs_ipc_ops = {
.send_data = qcom_apcs_ipc_send_data,
};
+/*
+ * We use the notifier function for switching to a temporary safe configuration
+ * (mux and divider), while the A53 PLL is reconfigured.
+ */
+static int a53cc_notifier_cb(struct notifier_block *nb, unsigned long event,
+void *data)
+{
+ int ret = 0;
+ struct clk_regmap_mux_div *md = container_of(nb,
+struct clk_regmap_mux_div,
+clk_nb);
+ if (event == PRE_RATE_CHANGE)
+ /* set the mux and divider to safe frequency (400mhz) */
+ ret = __mux_div_set_src_div(md, 4, 3);
+
+ return notifier_from_errno(ret);
+}
+
+static int msm8916_register_clk(struct device *dev, void __iomem *base)
+{
+ struct clk_regmap_mux_div *a53cc;
+ struct clk *pclk;
+ struct regmap *regmap;
+ struct clk_init_data init = { };
+ int ret;
+
+ a53cc = devm_kzalloc(dev, sizeof(*a53cc), GFP_KERNEL);
+ if (!a53cc)
+ return -ENOMEM;
+
+ a53cc->reg_offset = 0x50;
+ a53cc->hid_width = 5;
+ a53cc->hid_shift = 0;
+ a53cc->src_width = 3;
+ a53cc->src_shift = 8;
+ a53cc->parent_map = gpll0_a53cc_map;
+
+ init.name = "a53mux";
+ init.parent_names = gpll0_a53cc;
+ init.num_parents = 2;
+ init.ops = &clk_regmap_mux_div_ops;
+ init.flags = CLK_SET_RATE_PARENT;
+ a53cc->clkr.hw.init = &init;
+
+ pclk = __clk_lookup(gpll0_a53cc[1]);
+ if (!pclk)
+ return -EPROBE_DEFER;
+
+ a53cc->clk_nb.notifier_call = a53cc_notifier_cb;
+ ret = clk_notifier_register(pclk, &a53cc->clk_nb);
+ if (ret) {
+ dev_err(dev, "failed to register clock notifier: %d\n", ret);
+ return ret;
+ }
+
+ regmap = devm_regmap_init_mmio(dev, base, &a53cc_regmap_config);
+ if (IS_ERR(regmap)) {
+ ret = PTR_ERR(regmap);
+ dev_err(dev, "failed to init regmap mmio: %d\n", ret);
+ goto err;
+ }
+
+ a53cc->clkr.regmap = regmap;
+
+ ret = devm_clk_register_regmap(dev, &a53cc->clkr);
+ if (ret) {
+ dev_err(dev, "failed to register regmap clock: %d\n", ret);
+ goto err;
+ }
+
+ ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_simple_get,
+&a53cc->clkr.hw);
+ i
Re: [PATCH 3/9] regulator: mt6380: Add support for MT6380
On Fri, Jun 23, 2017 at 11:56:05PM +0800, Sean Wang wrote:
> On Tue, 2017-06-06 at 19:22 +0100, Mark Brown wrote:
> > > + return (regval & info->desc.enable_mask) ?
> > > + REGULATOR_STATUS_ON : REGULATOR_STATUS_OFF;
> > This isn't really a get_status() operation - it's just showing the
> > status of the enable we set. The get_status() operation is for hardware
> > that has a mechanism for reading back the current physical status of the
> > regulator, usually including things like if it's in regulation or not.
> > Also please write normal conditional statements, it helps people read
> > the code.
> for the hardware, the way for reflect the current physical physical
> has to depend on the bit reading as the bit we enable. It indeed tends
> to confuse other users and developers, we maybe can add some comments
> for this to avoid.
It's OK to just not have a get_status() operation - a lot of regulators
just can't do this and that's fine, the subsystem will cope.
> > > +static const struct of_device_id mt6380_of_match[] = {
> > > + { .compatible = "mediatek,mt6380-regulator", },
> > > + { /* sentinel */ },
> > > +};
> > > +MODULE_DEVICE_TABLE(of, mt6380_of_match);
> > Given that this driver is entirely specific to the parent PMIC there
> > should be no need for a separate compatible string, it's redundant.
> the parent of pmic is MediaTek pwrap which is possibly being used with
> various pmics such as MT6323, MT6797, MT6380 and so on. So extra
> matching we thought is required to identify which pmic is actually being
> connected.
> For those opinions, maybe we didn't get your exact point. If something
> is wrong, please kindly guide us to the right place.
It sounds like pwrap should be a bus rather than using a platform device
here? But I guess that's how things are for now so OK.
signature.asc
Description: PGP signature
Re: [PATCH v3] selftests: lib: Skip tests on missing test modules
Hi Sumit, On 06/19/2017 10:48 PM, Sumit Semwal wrote: > With older kernels, printf.sh and bitmap.sh fail because they can't find > the respective test modules they are looking for. > > Use modprobe dry run to check for missing test_XXX module. Error out with > the same error code as prime_numbers.sh. > --- > v3: As pointed out by Kees, modules can be in-built too, so use 'modprobe > -q -n' to check presence of the module, instead of 'find ..'. > v2: Per Shuah's review, search for the module rather than do modprobe. --- Please note that the patch version details don't belong in the commit log. I edited it before applying to linux-kselftest next. Please make sure to add such information in the right place in future patches. > > Signed-off-by: Sumit Semwal Applied to linux-ksefltest next for 4.13-rc1 thanks, -- Shuah > --- > tools/testing/selftests/lib/bitmap.sh | 4 > tools/testing/selftests/lib/printf.sh | 4 > 2 files changed, 8 insertions(+) > > diff --git a/tools/testing/selftests/lib/bitmap.sh > b/tools/testing/selftests/lib/bitmap.sh > index 2da187b6ddad..b073c22a3435 100755 > --- a/tools/testing/selftests/lib/bitmap.sh > +++ b/tools/testing/selftests/lib/bitmap.sh > @@ -1,5 +1,9 @@ > #!/bin/sh > # Runs bitmap infrastructure tests using test_bitmap kernel module > +if ! /sbin/modprobe -q -n test_bitmap; then > + echo "bitmap: [SKIP]" > + exit 77 > +fi > > if /sbin/modprobe -q test_bitmap; then > /sbin/modprobe -q -r test_bitmap > diff --git a/tools/testing/selftests/lib/printf.sh > b/tools/testing/selftests/lib/printf.sh > index 4fdc70fe6980..cbf3b124bd94 100755 > --- a/tools/testing/selftests/lib/printf.sh > +++ b/tools/testing/selftests/lib/printf.sh > @@ -1,5 +1,9 @@ > #!/bin/sh > # Runs printf infrastructure using test_printf kernel module > +if ! /sbin/modprobe -q -n test_printf; then > + echo "printf: [SKIP]" > + exit 77 > +fi > > if /sbin/modprobe -q test_printf; then > /sbin/modprobe -q -r test_printf >
[PATCH v2 1/3] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup
Update pci and platform files to use devres interface to allocate the PCI
and iomap resources. Also add helper functions to consolicate module init,
exit and power mangagement code duplication.
Signed-off-by: Brijesh Singh
---
drivers/crypto/ccp/ccp-dev-v3.c | 8 +++
drivers/crypto/ccp/ccp-dev.c | 61
drivers/crypto/ccp/ccp-dev.h | 6 ++
drivers/crypto/ccp/ccp-pci.c | 114 +-
drivers/crypto/ccp/ccp-platform.c | 56 ++-
5 files changed, 107 insertions(+), 138 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index 367c2e3..1cae5a3 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -586,6 +586,14 @@ static const struct ccp_actions ccp3_actions = {
.irqhandler = ccp_irq_handler,
};
+const struct ccp_vdata ccpv3_platform = {
+ .version = CCP_VERSION(3, 0),
+ .setup = NULL,
+ .perform = &ccp3_actions,
+ .bar = 2,
+ .offset = 0,
+};
+
const struct ccp_vdata ccpv3 = {
.version = CCP_VERSION(3, 0),
.setup = NULL,
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 2506b50..ce35e43 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -538,8 +538,69 @@ bool ccp_queues_suspended(struct ccp_device *ccp)
return ccp->cmd_q_count == suspended;
}
+
+int ccp_dev_suspend(struct ccp_device *ccp, pm_message_t state)
+{
+ unsigned long flags;
+ unsigned int i;
+
+ spin_lock_irqsave(&ccp->cmd_lock, flags);
+
+ ccp->suspending = 1;
+
+ /* Wake all the queue kthreads to prepare for suspend */
+ for (i = 0; i < ccp->cmd_q_count; i++)
+ wake_up_process(ccp->cmd_q[i].kthread);
+
+ spin_unlock_irqrestore(&ccp->cmd_lock, flags);
+
+ /* Wait for all queue kthreads to say they're done */
+ while (!ccp_queues_suspended(ccp))
+ wait_event_interruptible(ccp->suspend_queue,
+ccp_queues_suspended(ccp));
+
+ return 0;
+}
+
+int ccp_dev_resume(struct ccp_device *ccp)
+{
+ unsigned long flags;
+ unsigned int i;
+
+ spin_lock_irqsave(&ccp->cmd_lock, flags);
+
+ ccp->suspending = 0;
+
+ /* Wake up all the kthreads */
+ for (i = 0; i < ccp->cmd_q_count; i++) {
+ ccp->cmd_q[i].suspended = 0;
+ wake_up_process(ccp->cmd_q[i].kthread);
+ }
+
+ spin_unlock_irqrestore(&ccp->cmd_lock, flags);
+
+ return 0;
+}
#endif
+int ccp_dev_init(struct ccp_device *ccp)
+{
+ if (ccp->vdata->setup)
+ ccp->vdata->setup(ccp);
+
+ ccp->io_regs = ccp->io_map + ccp->vdata->offset;
+
+ return ccp->vdata->perform->init(ccp);
+}
+
+void ccp_dev_destroy(struct ccp_device *ccp)
+{
+ if (!ccp)
+ return;
+
+ ccp->vdata->perform->destroy(ccp);
+}
+
static int __init ccp_mod_init(void)
{
#ifdef CONFIG_X86
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index a70154a..df2e76e 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -652,6 +652,11 @@ void ccp_dmaengine_unregister(struct ccp_device *ccp);
void ccp5_debugfs_setup(struct ccp_device *ccp);
void ccp5_debugfs_destroy(void);
+int ccp_dev_init(struct ccp_device *ccp);
+void ccp_dev_destroy(struct ccp_device *ccp);
+int ccp_dev_suspend(struct ccp_device *ccp, pm_message_t state);
+int ccp_dev_resume(struct ccp_device *ccp);
+
/* Structure for computation functions that are device-specific */
struct ccp_actions {
int (*aes)(struct ccp_op *);
@@ -679,6 +684,7 @@ struct ccp_vdata {
const unsigned int offset;
};
+extern const struct ccp_vdata ccpv3_platform;
extern const struct ccp_vdata ccpv3;
extern const struct ccp_vdata ccpv5a;
extern const struct ccp_vdata ccpv5b;
diff --git a/drivers/crypto/ccp/ccp-pci.c b/drivers/crypto/ccp/ccp-pci.c
index e880d4cf4..490ad0a 100644
--- a/drivers/crypto/ccp/ccp-pci.c
+++ b/drivers/crypto/ccp/ccp-pci.c
@@ -150,28 +150,13 @@ static void ccp_free_irqs(struct ccp_device *ccp)
ccp->irq = 0;
}
-static int ccp_find_mmio_area(struct ccp_device *ccp)
-{
- struct device *dev = ccp->dev;
- struct pci_dev *pdev = to_pci_dev(dev);
- resource_size_t io_len;
- unsigned long io_flags;
-
- io_flags = pci_resource_flags(pdev, ccp->vdata->bar);
- io_len = pci_resource_len(pdev, ccp->vdata->bar);
- if ((io_flags & IORESOURCE_MEM) &&
- (io_len >= (ccp->vdata->offset + 0x800)))
- return ccp->vdata->bar;
-
- return -EIO;
-}
-
static int ccp_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct ccp_device *ccp;
struct ccp_pci *ccp_pci;
struct device *dev = &pdev->dev;
- unsigned int bar;
+ void __iomem * const *iomap_table;
+ int bar
[PATCH v2 3/3] crypto: cpp - Abstract interrupt registeration
The CCP and PSP devices part of AMD Secure Procesor may share the same
interrupt. Hence we expand the SP device to register a common interrupt
handler and provide functions to CCP and PSP devices to register their
interrupt callback which will be invoked upon interrupt.
Signed-off-by: Brijesh Singh
---
drivers/crypto/ccp/ccp-dev-v3.c | 6 +--
drivers/crypto/ccp/ccp-dev-v5.c | 7 ++-
drivers/crypto/ccp/ccp-dev.c | 3 +-
drivers/crypto/ccp/ccp-dev.h | 2 -
drivers/crypto/ccp/ccp-pci.c | 103 +++-
drivers/crypto/ccp/ccp-platform.c | 57 ++--
drivers/crypto/ccp/sp-dev.c | 107 ++
drivers/crypto/ccp/sp-dev.h | 17 +-
8 files changed, 187 insertions(+), 115 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index 57179034..695fde8 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -453,7 +453,7 @@ static int ccp_init(struct ccp_device *ccp)
iowrite32(ccp->qim, ccp->io_regs + IRQ_STATUS_REG);
/* Request an irq */
- ret = ccp->get_irq(ccp);
+ ret = sp_request_ccp_irq(ccp->sp, ccp_irq_handler, ccp->name, ccp);
if (ret) {
dev_err(dev, "unable to allocate an IRQ\n");
goto e_pool;
@@ -510,7 +510,7 @@ static int ccp_init(struct ccp_device *ccp)
if (ccp->cmd_q[i].kthread)
kthread_stop(ccp->cmd_q[i].kthread);
- ccp->free_irq(ccp);
+ sp_free_ccp_irq(ccp->sp, ccp);
e_pool:
for (i = 0; i < ccp->cmd_q_count; i++)
@@ -549,7 +549,7 @@ static void ccp_destroy(struct ccp_device *ccp)
if (ccp->cmd_q[i].kthread)
kthread_stop(ccp->cmd_q[i].kthread);
- ccp->free_irq(ccp);
+ sp_free_ccp_irq(ccp->sp, ccp);
for (i = 0; i < ccp->cmd_q_count; i++)
dma_pool_destroy(ccp->cmd_q[i].dma_pool);
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index 8ed2b37..b0391f0 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -880,7 +880,7 @@ static int ccp5_init(struct ccp_device *ccp)
dev_dbg(dev, "Requesting an IRQ...\n");
/* Request an irq */
- ret = ccp->get_irq(ccp);
+ ret = sp_request_ccp_irq(ccp->sp, ccp5_irq_handler, ccp->name, ccp);
if (ret) {
dev_err(dev, "unable to allocate an IRQ\n");
goto e_pool;
@@ -986,7 +986,7 @@ static int ccp5_init(struct ccp_device *ccp)
kthread_stop(ccp->cmd_q[i].kthread);
e_irq:
- ccp->free_irq(ccp);
+ sp_free_ccp_irq(ccp->sp, ccp);
e_pool:
for (i = 0; i < ccp->cmd_q_count; i++)
@@ -1036,7 +1036,7 @@ static void ccp5_destroy(struct ccp_device *ccp)
if (ccp->cmd_q[i].kthread)
kthread_stop(ccp->cmd_q[i].kthread);
- ccp->free_irq(ccp);
+ sp_free_ccp_irq(ccp->sp, ccp);
for (i = 0; i < ccp->cmd_q_count; i++) {
cmd_q = &ccp->cmd_q[i];
@@ -1105,7 +1105,6 @@ static const struct ccp_actions ccp5_actions = {
.init = ccp5_init,
.destroy = ccp5_destroy,
.get_free_slots = ccp5_get_free_slots,
- .irqhandler = ccp5_irq_handler,
};
const struct ccp_vdata ccpv5a = {
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 8a1674a..7c751bf 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -599,8 +599,7 @@ int ccp_dev_init(struct sp_device *sp)
goto e_err;
}
- ccp->get_irq = sp->get_irq;
- ccp->free_irq = sp->free_irq;
+ ccp->use_tasklet = sp->use_tasklet;
ccp->io_regs = sp->io_map + ccp->vdata->offset;
if (ccp->vdata->setup)
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index ca44821..193f309 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -351,8 +351,6 @@ struct ccp_device {
/* Bus specific device information
*/
void *dev_specific;
- int (*get_irq)(struct ccp_device *ccp);
- void (*free_irq)(struct ccp_device *ccp);
unsigned int qim;
unsigned int irq;
bool use_tasklet;
diff --git a/drivers/crypto/ccp/ccp-pci.c b/drivers/crypto/ccp/ccp-pci.c
index 7eab3c6..f6b9858 100644
--- a/drivers/crypto/ccp/ccp-pci.c
+++ b/drivers/crypto/ccp/ccp-pci.c
@@ -28,67 +28,37 @@
#define MSIX_VECTORS 2
-struct ccp_msix {
- u32 vector;
- char name[16];
-};
-
struct ccp_pci {
int msix_count;
- struct ccp_msix msix[MSIX_VECTORS];
+ struct msix_entry msix_entry[MSIX_VECTORS];
};
-static int ccp_get_msix_irqs(struct ccp_device *ccp)
+static int ccp_get_msix_irqs(struct sp_device *sp)
{
- struct sp_device *sp = ccp->sp;
struct ccp_pci *ccp_pci = sp-
[PATCH v2 2/3] crypto: ccp - Introduce the AMD Secure Processor device
The CCP device is part of the AMD Secure Processor. In order to expand
the usage of the AMD Secure Processor, create a framework that allows
functional components of the AMD Secure Processor to be initialized and
handled appropriately.
Signed-off-by: Brijesh Singh
---
drivers/crypto/Kconfig| 10 +--
drivers/crypto/ccp/Kconfig| 43 +
drivers/crypto/ccp/Makefile | 6 +-
drivers/crypto/ccp/ccp-dev-v3.c | 5 +-
drivers/crypto/ccp/ccp-dev-v5.c | 5 +-
drivers/crypto/ccp/ccp-dev.c | 106 +-
drivers/crypto/ccp/ccp-dev.h | 21 +
drivers/crypto/ccp/ccp-pci.c | 81 +++--
drivers/crypto/ccp/ccp-platform.c | 70 ---
drivers/crypto/ccp/sp-dev.c | 180 ++
drivers/crypto/ccp/sp-dev.h | 120 +
include/linux/ccp.h | 3 +-
12 files changed, 475 insertions(+), 175 deletions(-)
create mode 100644 drivers/crypto/ccp/sp-dev.c
create mode 100644 drivers/crypto/ccp/sp-dev.h
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 0528a62..418f991 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -512,14 +512,14 @@ config CRYPTO_DEV_ATMEL_SHA
To compile this driver as a module, choose M here: the module
will be called atmel-sha.
-config CRYPTO_DEV_CCP
- bool "Support for AMD Cryptographic Coprocessor"
+config CRYPTO_DEV_SP
+ bool "Support for AMD Secure Processor"
depends on ((X86 && PCI) || (ARM64 && (OF_ADDRESS || ACPI))) &&
HAS_IOMEM
help
- The AMD Cryptographic Coprocessor provides hardware offload support
- for encryption, hashing and related operations.
+ The AMD Secure Processor provides hardware offload support for memory
+ encryption in virtualization and cryptographic hashing and related
operations.
-if CRYPTO_DEV_CCP
+if CRYPTO_DEV_SP
source "drivers/crypto/ccp/Kconfig"
endif
diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
index 2238f77..bc08f03 100644
--- a/drivers/crypto/ccp/Kconfig
+++ b/drivers/crypto/ccp/Kconfig
@@ -1,26 +1,37 @@
-config CRYPTO_DEV_CCP_DD
- tristate "Cryptographic Coprocessor device driver"
- depends on CRYPTO_DEV_CCP
- default m
- select HW_RANDOM
- select DMA_ENGINE
- select DMADEVICES
- select CRYPTO_SHA1
- select CRYPTO_SHA256
- help
- Provides the interface to use the AMD Cryptographic Coprocessor
- which can be used to offload encryption operations such as SHA,
- AES and more. If you choose 'M' here, this module will be called
- ccp.
-
config CRYPTO_DEV_CCP_CRYPTO
tristate "Encryption and hashing offload support"
- depends on CRYPTO_DEV_CCP_DD
+ depends on CRYPTO_DEV_SP_DD
default m
select CRYPTO_HASH
select CRYPTO_BLKCIPHER
select CRYPTO_AUTHENC
+ select CRYPTO_DEV_CCP
help
Support for using the cryptographic API with the AMD Cryptographic
Coprocessor. This module supports offload of SHA and AES algorithms.
If you choose 'M' here, this module will be called ccp_crypto.
+
+config CRYPTO_DEV_SP_DD
+ tristate "Secure Processor device driver"
+ depends on CRYPTO_DEV_SP
+ default m
+ help
+ Provides the interface to use the AMD Secure Processor. The
+ AMD Secure Processor support the Platform Security Processor (PSP)
+ and Cryptographic Coprocessor (CCP). If you choose 'M' here, this
+ module will be called ccp.
+
+if CRYPTO_DEV_SP_DD
+config CRYPTO_DEV_CCP
+ bool "Cryptographic Coprocessor interface"
+ default y
+ select HW_RANDOM
+ select DMA_ENGINE
+ select DMADEVICES
+ select CRYPTO_SHA1
+ select CRYPTO_SHA256
+ help
+ Provides the interface to use the AMD Cryptographic Coprocessor
+ which can be used to offload encryption operations such as SHA,
+ AES and more.
+endif
diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index 59493fd..ea42888 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -1,9 +1,9 @@
-obj-$(CONFIG_CRYPTO_DEV_CCP_DD) += ccp.o
-ccp-objs := ccp-dev.o \
+obj-$(CONFIG_CRYPTO_DEV_SP_DD) += ccp.o
+ccp-objs := sp-dev.o ccp-platform.o
+ccp-$(CONFIG_CRYPTO_DEV_CCP) += ccp-dev.o \
ccp-ops.o \
ccp-dev-v3.o \
ccp-dev-v5.o \
- ccp-platform.o \
ccp-dmaengine.o \
ccp-debugfs.o
ccp-$(CONFIG_PCI) += ccp-pci.o
diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index 1cae5a3..57179034 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -359,8 +359,7 @@ static void ccp_irq_bh(unsigned long data)
static irqreturn_t ccp_irq_handler(int irq, void *data)
{
-
[PATCH v2 0/3] Introduce AMD Secure Processor device
CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor, which is not dedicated solely to crypto. The AMD Secure Processor includes CCP and PSP (Platform Secure Processor) devices. This patch series adds a framework that allows functional component of the AMD Secure Processor to be initialized and handled appropriately. The series does not makes any logic modification into CCP - it refactors the code to integerate CCP into AMD secure processor framework. --- Changes since v1: - remove unused function [sp_get_device()] Brijesh Singh (3): crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup crypto: ccp - Introduce the AMD Secure Processor device crypto: cpp - Abstract interrupt registeration drivers/crypto/Kconfig| 10 +- drivers/crypto/ccp/Kconfig| 43 +++--- drivers/crypto/ccp/Makefile | 6 +- drivers/crypto/ccp/ccp-dev-v3.c | 17 ++- drivers/crypto/ccp/ccp-dev-v5.c | 12 +- drivers/crypto/ccp/ccp-dev.c | 124 ++-- drivers/crypto/ccp/ccp-dev.h | 19 +-- drivers/crypto/ccp/ccp-pci.c | 264 --- drivers/crypto/ccp/ccp-platform.c | 165 -- drivers/crypto/ccp/sp-dev.c | 287 ++ drivers/crypto/ccp/sp-dev.h | 133 ++ include/linux/ccp.h | 3 +- 12 files changed, 712 insertions(+), 371 deletions(-) create mode 100644 drivers/crypto/ccp/sp-dev.c create mode 100644 drivers/crypto/ccp/sp-dev.h -- 2.9.4
Re: [PATCH v2] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems
On Fri, 2017-06-23 at 15:37 +, mario.limoncie...@dell.com wrote: [...] > > > > +#define ACPI_LPS0_SCREEN_ON4 > > +#define ACPI_LPS0_ENTRY5 > > +#define ACPI_LPS0_EXIT 6 > The spec you shared also defines device constraints (function 1). It > would be very > useful if these constraints could be parsed and compared against the > actual power > states of devices on the system at least for debugging purposes. I'm > not sure if you > already had a plan for that in a future series. > For debug purpose, I have worked on a patch to dump the constraint table in debugfs. But in the freeze path whether we meet the constraints or not will not make any difference, other than for just debugging. Thanks, Srinivas
Re: [PATCH 1/2] gdb/scripts: lx-dmesg: Cast log_buf to void* for addr fetch
On 2017-06-23 16:20, Leonard Crestez wrote:
> In some cases it is possible for the str() conversion here to throw
> encoding errors because log_buf might not point to valid ascii. For
> example:
>
> (gdb) python print str(gdb.parse_and_eval("log_buf"))
> Traceback (most recent call last):
> File "", line 1, in
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0303' in
> position 24: ordinal not in range(128)
>
> Avoid this by explicitly casting to (void *) inside the gdb expression.
>
> Signed-off-by: Leonard Crestez
> ---
> scripts/gdb/linux/dmesg.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/gdb/linux/dmesg.py b/scripts/gdb/linux/dmesg.py
> index 5afd109..6f8d2b2 100644
> --- a/scripts/gdb/linux/dmesg.py
> +++ b/scripts/gdb/linux/dmesg.py
> @@ -24,7 +24,7 @@ class LxDmesg(gdb.Command):
>
> def invoke(self, arg, from_tty):
> log_buf_addr = int(str(gdb.parse_and_eval(
> -"'printk.c'::log_buf")).split()[0], 16)
> +"(void*)'printk.c'::log_buf")).split()[0], 16)
Nit: (void *)
> log_first_idx = int(gdb.parse_and_eval("'printk.c'::log_first_idx"))
> log_next_idx = int(gdb.parse_and_eval("'printk.c'::log_next_idx"))
> log_buf_len = int(gdb.parse_and_eval("'printk.c'::log_buf_len"))
>
Looks good, makes sense to me.
Reviewed-by: Jan Kiszka
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
Re: [PATCH] selftests: fix memory-hotplug test
Hi Po-Hsu Lin,
On 06/18/2017 09:04 PM, Po-Hsu Lin wrote:
Please split the typo correction and fixes. Please send a patch
for each individual fix. I am seeing several fixes bundled in this
one single patch.
> Typo correction for hotpluggable_offline_memory() function> Check for
> hot-pluggable memory availability in prerequisite().
> Check for precentage range for -r flag>
> Fix the memory offline test, the $ratio was used with RANDOM as the
> possibility to get it offlined, correct it to become the portion of
> available removable memory blocks.
> Also ask the tool to try to offline the next available memory block
> if the attempt is unsuccessful. It will only fail if all removable
> memory blocks are busy.
>
> An nice example:
> PHLin@Latitude:~$ sudo ./test.sh
Remove the user info from this output. Same comment for the rest if
this output.
> Test scope: 10% hotplug memory
>online all hot-pluggable memory in offline state:
> SKIPPED - no hot-pluggable memory in offline state
>offline 10% hot-pluggable memory in online state
>trying to offline 3 out of 28 memory block(s):
> online->offline memory1
> online->offline memory10
> ./test.sh: line 74: echo: write error: Resource temporarily unavailable
> offline_memory_expect_success 10: unexpected fail
> online->offline memory100
> online->offline memory101
>online all hot-pluggable memory in offline state:
> offline->online memory1
> offline->online memory100
> offline->online memory101
> skip extra tests: debugfs is not mounted
> PHLin@Latitude:~$ echo $?
> 0
>
> Signed-off-by: Po-Hsu Lin
thanks,
-- Shuah
> ---
> .../selftests/memory-hotplug/mem-on-off-test.sh| 86
> +++-
> 1 file changed, 67 insertions(+), 19 deletions(-)
>
> diff --git a/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh
> b/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh
> index 6cddde0..f1603e6 100755
> --- a/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh
> +++ b/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh
> @@ -22,6 +22,11 @@ prerequisite()
> echo $msg memory hotplug is not supported >&2
> exit 0
> fi
> +
> + if ! grep -q 1 $SYSFS/devices/system/memory/memory*/removable; then
> + echo $msg no hot-pluggable memory >&2
> + exit 0
> + fi
> }
>
> #
> @@ -39,7 +44,7 @@ hotpluggable_memory()
> done
> }
>
> -hotplaggable_offline_memory()
> +hotpluggable_offline_memory()
> {
> hotpluggable_memory offline
> }
> @@ -75,9 +80,12 @@ online_memory_expect_success()
>
> if ! online_memory $memory; then
> echo $FUNCNAME $memory: unexpected fail >&2
> + return 1
> elif ! memory_is_online $memory; then
> echo $FUNCNAME $memory: unexpected offline >&2
> + return 1
> fi
> + return 0
> }
>
> online_memory_expect_fail()
> @@ -86,9 +94,12 @@ online_memory_expect_fail()
>
> if online_memory $memory 2> /dev/null; then
> echo $FUNCNAME $memory: unexpected success >&2
> + return 1
> elif ! memory_is_offline $memory; then
> echo $FUNCNAME $memory: unexpected online >&2
> + return 1
> fi
> + return 0
> }
>
> offline_memory_expect_success()
> @@ -97,9 +108,12 @@ offline_memory_expect_success()
>
> if ! offline_memory $memory; then
> echo $FUNCNAME $memory: unexpected fail >&2
> + return 1
> elif ! memory_is_offline $memory; then
> echo $FUNCNAME $memory: unexpected offline >&2
> + return 1
> fi
> + return 0
> }
>
> offline_memory_expect_fail()
> @@ -108,14 +122,18 @@ offline_memory_expect_fail()
>
> if offline_memory $memory 2> /dev/null; then
> echo $FUNCNAME $memory: unexpected success >&2
> + return 1
> elif ! memory_is_online $memory; then
> echo $FUNCNAME $memory: unexpected offline >&2
> + return 1
> fi
> + return 0
> }
>
> error=-12
> priority=0
> ratio=10
> +retval=0
>
> while getopts e:hp:r: opt; do
> case $opt in
> @@ -131,6 +149,10 @@ while getopts e:hp:r: opt; do
> ;;
> r)
> ratio=$OPTARG
> + if [ "$ratio" -gt 100 ] || [ "$ratio" -lt 0 ]; then
> + echo "The percentage should be an integer within 0~100
> range"
> + exit
> + fi
> ;;
> esac
> done
> @@ -143,35 +165,58 @@ fi
> prerequisite
>
> echo "Test scope: $ratio% hotplug memory"
> -echo -e "\t online all hotplug memory in offline state"
> -echo -e "\t offline $ratio% hotplug memory in online state"
> -echo -e "\t online all hotplug memory in offline state"
>
> #
> # Online all hot-pluggable memory
> #
> -for memory in `hotplaggable_offline_memory`; do
> - echo offline-online $memory
> -
Re: [PATCH 2/2] scripts/gdb: lx-dmesg: Use errors=replace for decoding
On 2017-06-23 16:20, Leonard Crestez wrote:
> It is never desirable lx-dmesg to fail on string decoding errors, not
> even if the log buffer is corrupt.
>
> Signed-off-by: Leonard Crestez
> ---
> scripts/gdb/linux/dmesg.py | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/gdb/linux/dmesg.py b/scripts/gdb/linux/dmesg.py
> index 6f8d2b2..d0cac58 100644
> --- a/scripts/gdb/linux/dmesg.py
> +++ b/scripts/gdb/linux/dmesg.py
> @@ -52,13 +52,13 @@ class LxDmesg(gdb.Command):
> continue
>
> text_len = utils.read_u16(log_buf[pos + 10:pos + 12])
> -text = log_buf[pos + 16:pos + 16 + text_len].decode()
> +text = log_buf[pos + 16:pos + 16 +
> text_len].decode(errors='replace')
pep8 should complain.
> time_stamp = utils.read_u64(log_buf[pos:pos + 8])
>
> for line in text.splitlines():
> gdb.write("[{time:12.6f}] {line}\n".format(
> time=time_stamp / 10.0,
> -line=line))
> +line=line.encode(errors='replace')))
You only talk about "decoding" in the commit log, but here you encode
back. An short explanation why this is also needed would be nice.
>
> pos += length
>
>
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
Re: [PATCH 0/3] Enable namespaced file capabilities
Quoting Amir Goldstein (amir7...@gmail.com): > On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger > wrote: > > This series of patches primary goal is to enable file capabilities > > in user namespaces without affecting the file capabilities that are > > effective on the host. This is to prevent that any unprivileged user > > on the host maps his own uid to root in a private namespace, writes > > the xattr, and executes the file with privilege on the host. > > > > We achieve this goal by writing extended attributes with a different > > name when a user namespace is used. If for example the root user > > in a user namespace writes the security.capability xattr, the name > > of the xattr that is actually written is encoded as > > security.capability@uid=1000 for root mapped to uid 1000 on the host. > > When listing the xattrs on the host, the existing security.capability > > as well as the security.capability@uid=1000 will be shown. Inside the > > namespace only 'security.capability', with the value of > > security.capability@uid=1000, is visible. > > > > Am I the only one who thinks that suffix is perhaps not the best grammar > to use for this namespace? You're the only one to have mentioned it so far. > xattrs are clearly namespaced by prefix, so it seems right to me to keep > it that way - define a new special xattr namespace "ns" and only if that > prefix exists, the @uid suffix will be parsed. > This could be either ns.security.capability@uid=1000 or > ns@uid=1000.security.capability. The latter seems more correct to me, > because then we will be able to namespace any xattr without having to > protect from "unprivileged xattr injection", i.e.: > setfattr -n "user.whatever.foo@uid=0" I like it for simplifying the parser code. One concern I have is that, since ns.* is currently not gated, one could write ns.* on an older kernel and then exploit it on a newer one.
Re: [PATCH] Staging : rts5208 : checkpatch.pl fixes
On Fri, 2017-06-23 at 15:55 +0200, Simo Koskinen wrote:
> Fixed some issues reported by checkpatch.pl script.
[]
> diff --git a/drivers/staging/rts5208/rtsx.c b/drivers/staging/rts5208/rtsx.c
> index b8177f5..ceef5fc 100644
> --- a/drivers/staging/rts5208/rtsx.c
> +++ b/drivers/staging/rts5208/rtsx.c
> @@ -1009,7 +1009,7 @@ static void rtsx_remove(struct pci_dev *pci)
> {
> struct rtsx_dev *dev = pci_get_drvdata(pci);
>
> - dev_info(&pci->dev, "rtsx_remove() called\n");
> + dev_info(&pci->dev, "%s called\n", "rtsx_remove()");
This would be better as dev_dbg
>
> quiesce_and_remove_host(dev);
> release_everything(dev);
> diff --git a/drivers/staging/rts5208/rtsx_chip.c
> b/drivers/staging/rts5208/rtsx_chip.c
> index 7f4107b..892b97a 100644
> --- a/drivers/staging/rts5208/rtsx_chip.c
> +++ b/drivers/staging/rts5208/rtsx_chip.c
> @@ -616,8 +616,10 @@ int rtsx_reset_chip(struct rtsx_chip *chip)
> else
> retval = rtsx_pre_handle_sdio_new(chip);
>
> - dev_dbg(rtsx_dev(chip), "chip->need_reset = 0x%x
> (rtsx_reset_chip)\n",
> - (unsigned int)(chip->need_reset));
> + dev_dbg(rtsx_dev(chip), "%s = 0x%x (%s)\n",
> + "chip->need_reset",
> + (unsigned int)(chip->need_reset),
> + "rtsx_reset_chip");
This and other changes that take part of the format
and convert them to '"%s", substrings' are not good.
checkpatch doesn't emit a warning for long formats.
> diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
[]
> @@ -910,8 +910,12 @@ static int sd_change_phase(struct rtsx_chip *chip, u8
> sample_point, u8 tune_dir)
> int retval;
> bool ddr_rx = false;
>
> - dev_dbg(rtsx_dev(chip), "sd_change_phase (sample_point = %d, tune_dir =
> %d)\n",
> - sample_point, tune_dir);
> + dev_dbg(rtsx_dev(chip), "%s (%s = %d, %s = %d)\n",
> + "sd_change_phase",
> + "sample_point",
> + sample_point,
> + "tune_dir",
> + tune_dir);
etc.
[patch] obsoleted comment in show_map_vma()
After 1be7107 "mm: larger stack guard gap, between vmas" we do not hide stack guard page in /proc//maps Signed-off-by: Vasily Averin diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 520802d..b836fd6 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -298,7 +298,6 @@ show_map_vma(struct seq_file *m, struct vm_area_struct *vma, int is_pid) pgoff = ((loff_t)vma->vm_pgoff) << PAGE_SHIFT; } - /* We don't show the stack guard page in /proc/maps */ start = vma->vm_start; end = vma->vm_end;
Re: [PATCH 3/9] regulator: mt6380: Add support for MT6380
Hi Mark,
appreciate your effort on reviewing those patches
we'll make next version following your suggestion, here also adding some
comments as inline to explain what thoughts in mind
On Tue, 2017-06-06 at 19:22 +0100, Mark Brown wrote:
> On Sat, Jun 03, 2017 at 01:55:44AM +0800, sean.w...@mediatek.com wrote:
>
> > +static int mt6380_get_status(struct regulator_dev *rdev)
> > +{
> > + int ret;
> > + u32 regval;
> > + struct mt6380_regulator_info *info = rdev_get_drvdata(rdev);
> > +
> > + ret = regmap_read(rdev->regmap, info->desc.enable_reg, ®val);
> > + if (ret != 0) {
> > + dev_err(&rdev->dev, "Failed to get enable reg: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + return (regval & info->desc.enable_mask) ?
> > + REGULATOR_STATUS_ON : REGULATOR_STATUS_OFF;
>
> This isn't really a get_status() operation - it's just showing the
> status of the enable we set. The get_status() operation is for hardware
> that has a mechanism for reading back the current physical status of the
> regulator, usually including things like if it's in regulation or not.
>
> Also please write normal conditional statements, it helps people read
> the code.
for the hardware, the way for reflect the current physical physical
has to depend on the bit reading as the bit we enable. It indeed tends
to confuse other users and developers, we maybe can add some comments
for this to avoid.
> > + ret = regmap_update_bits(rdev->regmap, info->modeset_reg,
> > +info->modeset_mask, val);
> > +
> > + if (regmap_read(rdev->regmap, info->modeset_reg, ®_value) < 0) {
> > + dev_err(&rdev->dev, "Failed to read register value\n");
> > + return -EIO;
> > + }
>
> Is I/O to the device unreliable for some reason? If so this isn't great
> handling for it... also if there is an error from regmap_read() you
> should return the error code.
>
O.K. we'll remove it. that just is debug purpose code which confirms the
value we set is correct.
> > + unsigned int mode;
> > + int ret;
> > + struct mt6380_regulator_info *info = rdev_get_drvdata(rdev);
> > +
> > + if (!info->modeset_mask) {
> > + dev_err(&rdev->dev, "regulator %s doesn't support get_mode\n",
> > + info->desc.name);
> > + return -EINVAL;
> > + }
> > +
> > + ret = regmap_read(rdev->regmap, info->modeset_reg, &val);
> > + if (ret < 0)
> > + return ret;
> > +
> > + val &= info->modeset_mask;
> > + val >>= ffs(info->modeset_mask) - 1;
> > +
> > + if (val & 0x1)
> > + mode = REGULATOR_MODE_STANDBY;
> > + else
> > + mode = REGULATOR_MODE_NORMAL;
> > +
> > + return mode;
> > +}
>
> This won't initialize mode if the regulator is in force PWM mode. It'd
> be clearer and safer to just write a switch statement.
>
we'll fix up the bug with switch statement.
> > + /* Constrain board-specific capabilities according to what
> > +* this driver and the chip itself can actually do.
> > +*/
> > + c = rdev->constraints;
> > + c->valid_modes_mask |= REGULATOR_MODE_NORMAL |
> > + REGULATOR_MODE_STANDBY | REGULATOR_MODE_FAST;
>
> No, this is completely broken. A regulator driver should *never* modify
> constraints, if the constraints are broken the constraints are broken,
> and the constraints will already have been applied when we return from
> registering the regulator.
>
agreed. we shouldn't break any constraint and the violation would be
removed.
> > + c->valid_ops_mask |= REGULATOR_CHANGE_MODE;
>
> > +static const struct of_device_id mt6380_of_match[] = {
> > + { .compatible = "mediatek,mt6380-regulator", },
> > + { /* sentinel */ },
> > +};
> > +MODULE_DEVICE_TABLE(of, mt6380_of_match);
>
> Given that this driver is entirely specific to the parent PMIC there
> should be no need for a separate compatible string, it's redundant.
the parent of pmic is MediaTek pwrap which is possibly being used with
various pmics such as MT6323, MT6797, MT6380 and so on. So extra
matching we thought is required to identify which pmic is actually being
connected.
For those opinions, maybe we didn't get your exact point. If something
is wrong, please kindly guide us to the right place.
Sean
Re: [PATCH V3] tools/testing/selftests/sysctl: Add pre-check to the value of writes_strict
Hi Orson,
On 06/22/2017 10:24 PM, Orson Zhai wrote:
> Sysctl test will fail in some items if the value of /proc/sys/kernel
> /sysctrl_writes_strict is 0 as the default value in kernel older than v4.5.
>
> Make this test more robust and compatible with older kernels by checking and
> update sysctrl_writes_strict value and restore it when test is done.
>
> Signed-off-by: Orson Zhai
> Reviewed-by: Sumit Semwal
> Tested-by: Sumit Semwal
This patch failed to apply on linux-kselftest next. Could you please
rebase and send it.
thanks,
-- Shuah
> ---
> tools/testing/selftests/sysctl/common_tests | 22 ++
> tools/testing/selftests/sysctl/run_numerictests | 2 +-
> tools/testing/selftests/sysctl/run_stringtests | 2 +-
> 3 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/sysctl/common_tests
> b/tools/testing/selftests/sysctl/common_tests
> index 17d534b1b7b4..dfb1fcfc3142 100644
> --- a/tools/testing/selftests/sysctl/common_tests
> +++ b/tools/testing/selftests/sysctl/common_tests
> @@ -24,6 +24,14 @@ verify()
> return 0
> }
>
> +exit_test()
> +{
> + if [ ! -z ${old_strict} ]; then
> + echo ${old_strict} > ${WRITES_STRICT}
> + fi
> + exit $rc
> +}
> +
> trap 'set_orig; rm -f "${TEST_FILE}"' EXIT
>
> rc=0
> @@ -63,6 +71,20 @@ else
> echo "ok"
> fi
>
> +echo -n "Checking write strict setting ... "
> +WRITES_STRICT="${SYSCTL}/kernel/sysctl_writes_strict"
> +if [ ! -e ${WRITES_STRICT} ]; then
> + echo "FAIL, but skip in case of old kernel" >&2
> +else
> + old_strict=$(cat ${WRITES_STRICT})
> + if [ "$old_strict" = "1" ]; then
> + echo "ok"
> + else
> + echo "FAIL, strict value is 0 but force to 1 to continue" >&2
> + echo "1" > ${WRITES_STRICT}
> + fi
> +fi
> +
> # Now that we've validated the sanity of "set_test" and "set_orig",
> # we can use those functions to set starting states before running
> # specific behavioral tests.
> diff --git a/tools/testing/selftests/sysctl/run_numerictests
> b/tools/testing/selftests/sysctl/run_numerictests
> index 8510f93f2d14..e6e76c93d948 100755
> --- a/tools/testing/selftests/sysctl/run_numerictests
> +++ b/tools/testing/selftests/sysctl/run_numerictests
> @@ -7,4 +7,4 @@ TEST_STR=$(( $ORIG + 1 ))
>
> . ./common_tests
>
> -exit $rc
> +exit_test
> diff --git a/tools/testing/selftests/sysctl/run_stringtests
> b/tools/testing/selftests/sysctl/run_stringtests
> index 90a9293d520c..857ec667fb02 100755
> --- a/tools/testing/selftests/sysctl/run_stringtests
> +++ b/tools/testing/selftests/sysctl/run_stringtests
> @@ -74,4 +74,4 @@ else
> echo "ok"
> fi
>
> -exit $rc
> +exit_test
> --
> 2.12.2
>
>
[PATCH 0/2] add eMMC support for fsp2 board
fsp2 based on powerpc 476fpe using eMMC arasan, so we added support of this inside our dts and also enabled via additional dependence for sdhci-st driver in Kconfig. this code depends on commit c4b56b023daa91953e9ebe91143e6ca156f0bcb7 which is located in powerpc linux tree in 'next' branch. Ivan Mikhaylov (2): mmc/host: add FSP2(ppc476fpe) into depends for sdhci-st 44x/fsp2: enable eMMC arasan for fsp2 platform arch/powerpc/boot/dts/fsp2.dts | 19 +++ arch/powerpc/configs/44x/fsp2_defconfig |2 ++ drivers/mmc/host/Kconfig|2 +- 3 files changed, 22 insertions(+), 1 deletions(-)
[PATCH 2/2] 44x/fsp2: enable eMMC arasan for fsp2 platform
* add mmc0 section into dts for arasan
* change defconfig appropriately
Signed-off-by: Ivan Mikhaylov
---
arch/powerpc/boot/dts/fsp2.dts | 19 +++
arch/powerpc/configs/44x/fsp2_defconfig |2 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsp2.dts b/arch/powerpc/boot/dts/fsp2.dts
index de9d606..6a63026 100644
--- a/arch/powerpc/boot/dts/fsp2.dts
+++ b/arch/powerpc/boot/dts/fsp2.dts
@@ -52,6 +52,7 @@
clocks {
mmc_clk: mmc_clk {
compatible = "fixed-clock";
+ #clock-cells = <0>;
clock-frequency = <5000>;
clock-output-names = "mmc_clk";
};
@@ -487,6 +488,24 @@
/*RXDE*/ 4 &UIC1_2 13 0x4>;
};
+ mmc0: sdhci@020c {
+ compatible = "st,sdhci-stih407", "st,sdhci";
+ reg = <0x020c 0x2>;
+ reg-names = "mmc";
+ interrupts = <21 0x4>;
+ interrupt-parent = <&UIC1_3>;
+ interrupt-names = "mmcirq";
+ pinctrl-names = "default";
+ pinctrl-0 = <>;
+ clock-names = "mmc";
+ clocks = <&mmc_clk>;
+ bus-width = <4>;
+ non-removable;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ sd-uhs-ddr50;
+ };
+
opb {
compatible = "ibm,opb";
#address-cells = <1>;
diff --git a/arch/powerpc/configs/44x/fsp2_defconfig
b/arch/powerpc/configs/44x/fsp2_defconfig
index e8e6a69..935aabe 100644
--- a/arch/powerpc/configs/44x/fsp2_defconfig
+++ b/arch/powerpc/configs/44x/fsp2_defconfig
@@ -92,8 +92,10 @@ CONFIG_MMC_DEBUG=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_SDHCI_OF_ARASAN=y
+CONFIG_MMC_SDHCI_ST=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_M41T80=y
+CONFIG_RESET_CONTROLLER=y
CONFIG_EXT2_FS=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
--
1.7.1
