Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever
On Thu, 20 Jul 2017, Tetsuo Handa wrote:
> Hugh Dickins wrote:
> > You probably won't welcome getting into alternatives at this late stage;
> > but after hacking around it one way or another because of its pointless
> > lockups, I lost patience with that too_many_isolated() loop a few months
> > back (on realizing the enormous number of pages that may be isolated via
> > migrate_pages(2)), and we've been running nicely since with something like:
> >
> > bool got_mutex = false;
> >
> > if (unlikely(too_many_isolated(pgdat, file, sc))) {
> > if (mutex_lock_killable(&pgdat->too_many_isolated))
> > return SWAP_CLUSTER_MAX;
> > got_mutex = true;
> > }
> > ...
> > if (got_mutex)
> > mutex_unlock(&pgdat->too_many_isolated);
> >
> > Using a mutex to provide the intended throttling, without an infinite
> > loop or an arbitrary delay; and without having to worry (as we often did)
> > about whether those numbers in too_many_isolated() are really appropriate.
> > No premature OOMs complained of yet.
>
> Roughly speaking, there is a moment where shrink_inactive_list() acts
> like below.
>
> bool got_mutex = false;
>
> if (!current_is_kswapd()) {
> if (mutex_lock_killable(&pgdat->too_many_isolated))
> return SWAP_CLUSTER_MAX;
> got_mutex = true;
> }
>
> // kswapd is blocked here waiting for !current_is_kswapd().
That would be a shame, for kswapd to wait for !current_is_kswapd()!
But seriously, I think I understand what you mean by that, you're
thinking that kswapd would be waiting on some other task to clear
the too_many_isolated() condition?
No, it does not work that way: kswapd (never seeing too_many_isolated()
because that always says false when current_is_kswapd()) never tries to
take the pgdat->too_many_isolated mutex itself: it does not wait there
at all, although other tasks may be waiting there at the time.
Perhaps my naming the mutex "too_many_isolated", same as the function,
is actually confusing, when I had intended it to be helpful.
>
> if (got_mutex)
> mutex_unlock(&pgdat->too_many_isolated);
>
> >
> > But that was on a different kernel, and there I did have to make sure
> > that PF_MEMALLOC always prevented us from nesting: I'm not certain of
> > that in the current kernel (but do remember Johannes changing the memcg
> > end to make it use PF_MEMALLOC too). I offer the preview above, to see
> > if you're interested in that alternative: if you are, then I'll go ahead
> > and make it into an actual patch against v4.13-rc.
>
> I don't know what your actual patch looks like, but the problem is that
> pgdat->too_many_isolated waits for kswapd while kswapd waits for
> pgdat->too_many_isolated; nobody can unlock pgdat->too_many_isolated if
> once we hit it.
Not so (and we'd hardly be finding it a useful patch if that were so).
Hugh
Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever
On Thu, 20 Jul 2017, Michal Hocko wrote:
> On Wed 19-07-17 18:54:40, Hugh Dickins wrote:
> [...]
> > You probably won't welcome getting into alternatives at this late stage;
> > but after hacking around it one way or another because of its pointless
> > lockups, I lost patience with that too_many_isolated() loop a few months
> > back (on realizing the enormous number of pages that may be isolated via
> > migrate_pages(2)), and we've been running nicely since with something like:
> >
> > bool got_mutex = false;
> >
> > if (unlikely(too_many_isolated(pgdat, file, sc))) {
> > if (mutex_lock_killable(&pgdat->too_many_isolated))
> > return SWAP_CLUSTER_MAX;
> > got_mutex = true;
> > }
> > ...
> > if (got_mutex)
> > mutex_unlock(&pgdat->too_many_isolated);
> >
> > Using a mutex to provide the intended throttling, without an infinite
> > loop or an arbitrary delay; and without having to worry (as we often did)
> > about whether those numbers in too_many_isolated() are really appropriate.
> > No premature OOMs complained of yet.
> >
> > But that was on a different kernel, and there I did have to make sure
> > that PF_MEMALLOC always prevented us from nesting: I'm not certain of
> > that in the current kernel (but do remember Johannes changing the memcg
> > end to make it use PF_MEMALLOC too). I offer the preview above, to see
> > if you're interested in that alternative: if you are, then I'll go ahead
> > and make it into an actual patch against v4.13-rc.
>
> I would rather get rid of any additional locking here and my ultimate
> goal is to make throttling at the page allocator layer rather than
> inside the reclaim.
Fair enough, I'm certainly in no hurry to send the patch,
but thought it worth mentioning.
Hugh
[PATCH v2 2/4] crypto: add crypto_(un)register_ahashes()
From: Rabin Vincent
There are already helpers to (un)register multiple normal
and AEAD algos. Add one for ahashes too.
Signed-off-by: Lars Persson
---
crypto/ahash.c | 29 +
include/crypto/internal/hash.h | 2 ++
2 files changed, 31 insertions(+)
diff --git a/crypto/ahash.c b/crypto/ahash.c
index 826cd7ab4d4a..5e8666e6ccae 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -588,6 +588,35 @@ int crypto_unregister_ahash(struct ahash_alg *alg)
}
EXPORT_SYMBOL_GPL(crypto_unregister_ahash);
+int crypto_register_ahashes(struct ahash_alg *algs, int count)
+{
+ int i, ret;
+
+ for (i = 0; i < count; i++) {
+ ret = crypto_register_ahash(&algs[i]);
+ if (ret)
+ goto err;
+ }
+
+ return 0;
+
+err:
+ for (--i; i >= 0; --i)
+ crypto_unregister_ahash(&algs[i]);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(crypto_register_ahashes);
+
+void crypto_unregister_ahashes(struct ahash_alg *algs, int count)
+{
+ int i;
+
+ for (i = count - 1; i >= 0; --i)
+ crypto_unregister_ahash(&algs[i]);
+}
+EXPORT_SYMBOL_GPL(crypto_unregister_ahashes);
+
int ahash_register_instance(struct crypto_template *tmpl,
struct ahash_instance *inst)
{
diff --git a/include/crypto/internal/hash.h b/include/crypto/internal/hash.h
index f6d9af3efa45..f0b44c16e88f 100644
--- a/include/crypto/internal/hash.h
+++ b/include/crypto/internal/hash.h
@@ -76,6 +76,8 @@ static inline int crypto_ahash_walk_last(struct
crypto_hash_walk *walk)
int crypto_register_ahash(struct ahash_alg *alg);
int crypto_unregister_ahash(struct ahash_alg *alg);
+int crypto_register_ahashes(struct ahash_alg *algs, int count);
+void crypto_unregister_ahashes(struct ahash_alg *algs, int count);
int ahash_register_instance(struct crypto_template *tmpl,
struct ahash_instance *inst);
void ahash_free_instance(struct crypto_instance *inst);
--
2.11.0
[PATCH v2 4/4] MAINTAINERS: Add ARTPEC crypto maintainer
Assign the Axis kernel team as maintainer for crypto drivers under drivers/crypto/axis. Signed-off-by: Lars Persson --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index d5b6c71e783e..72186cf9820d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1129,6 +1129,7 @@ L:linux-arm-ker...@axis.com F: arch/arm/mach-artpec F: arch/arm/boot/dts/artpec6* F: drivers/clk/axis +F: drivers/crypto/axis F: drivers/pinctrl/pinctrl-artpec* F: Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt -- 2.11.0
[PATCH v2 0/4] crypto: add driver for Axis ARTPEC crypto accelerator
This series adds a driver for the crypto accelerator in the ARTPEC series of SoCs from Axis Communications AB. Changelog v2: - Use xts_check_key() for xts keys. - Use CRYPTO_ALG_TYPE_SKCIPHER instead of CRYPTO_ALG_TYPE_ABLKCIPHER in cra_flags. Lars Persson (3): dt-bindings: crypto: add ARTPEC crypto crypto: axis: add ARTPEC-6/7 crypto accelerator driver MAINTAINERS: Add ARTPEC crypto maintainer Rabin Vincent (1): crypto: add crypto_(un)register_ahashes() .../devicetree/bindings/crypto/artpec6-crypto.txt | 16 + MAINTAINERS|1 + crypto/ahash.c | 29 + drivers/crypto/Kconfig | 21 + drivers/crypto/Makefile|1 + drivers/crypto/axis/Makefile |1 + drivers/crypto/axis/artpec6_crypto.c | 3193 include/crypto/internal/hash.h |2 + 8 files changed, 3264 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/artpec6-crypto.txt create mode 100644 drivers/crypto/axis/Makefile create mode 100644 drivers/crypto/axis/artpec6_crypto.c -- 2.11.0
[PATCH v2 1/4] dt-bindings: crypto: add ARTPEC crypto
Document the device tree bindings for the ARTPEC crypto accelerator on
ARTPEC-6 and ARTPEC-7 SoCs.
Signed-off-by: Lars Persson
---
.../devicetree/bindings/crypto/artpec6-crypto.txt| 16
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/artpec6-crypto.txt
diff --git a/Documentation/devicetree/bindings/crypto/artpec6-crypto.txt
b/Documentation/devicetree/bindings/crypto/artpec6-crypto.txt
new file mode 100644
index ..d9cca4875bd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/artpec6-crypto.txt
@@ -0,0 +1,16 @@
+Axis crypto engine with PDMA interface.
+
+Required properties:
+- compatible : Should be one of the following strings:
+ "axis,artpec6-crypto" for the version in the Axis ARTPEC-6 SoC
+ "axis,artpec7-crypto" for the version in the Axis ARTPEC-7 SoC.
+- reg: Base address and size for the PDMA register area.
+- interrupts: Interrupt handle for the PDMA interrupt line.
+
+Example:
+
+crypto@f4264000 {
+ compatible = "axis,artpec6-crypto";
+ reg = <0xf4264000 0x1000>;
+ interrupts = ;
+};
--
2.11.0
[PATCH v2 3/4] crypto: axis: add ARTPEC-6/7 crypto accelerator driver
This is an asynchronous crypto API driver for the accelerator present in the ARTPEC-6 and -7 SoCs from Axis Communications AB. The driver supports AES in ECB/CTR/CBC/XTS/GCM modes and SHA1/2 hash standards. Signed-off-by: Lars Persson --- drivers/crypto/Kconfig | 21 + drivers/crypto/Makefile |1 + drivers/crypto/axis/Makefile |1 + drivers/crypto/axis/artpec6_crypto.c | 3193 ++ 4 files changed, 3216 insertions(+) create mode 100644 drivers/crypto/axis/Makefile create mode 100644 drivers/crypto/axis/artpec6_crypto.c diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 5b5393f1b87a..fe33c199fc1a 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -708,4 +708,25 @@ config CRYPTO_DEV_SAFEXCEL chain mode, AES cipher mode and SHA1/SHA224/SHA256/SHA512 hash algorithms. +config CRYPTO_DEV_ARTPEC6 + tristate "Support for Axis ARTPEC-6/7 hardware crypto acceleration." + depends on ARM && (ARCH_ARTPEC || COMPILE_TEST) + depends on HAS_DMA + depends on OF + select CRYPTO_AEAD + select CRYPTO_AES + select CRYPTO_ALGAPI + select CRYPTO_BLKCIPHER + select CRYPTO_CTR + select CRYPTO_HASH + select CRYPTO_SHA1 + select CRYPTO_SHA256 + select CRYPTO_SHA384 + select CRYPTO_SHA512 + help + Enables the driver for the on-chip crypto accelerator + of Axis ARTPEC SoCs. + + To compile this driver as a module, choose M here. + endif # CRYPTO_HW diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index de629165fde7..7bf0997eae25 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -44,3 +44,4 @@ obj-$(CONFIG_CRYPTO_DEV_VIRTIO) += virtio/ obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/ obj-$(CONFIG_CRYPTO_DEV_BCM_SPU) += bcm/ obj-$(CONFIG_CRYPTO_DEV_SAFEXCEL) += inside-secure/ +obj-$(CONFIG_CRYPTO_DEV_ARTPEC6) += axis/ diff --git a/drivers/crypto/axis/Makefile b/drivers/crypto/axis/Makefile new file mode 100644 index ..be9a84a4b667 --- /dev/null +++ b/drivers/crypto/axis/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_CRYPTO_DEV_ARTPEC6) := artpec6_crypto.o diff --git a/drivers/crypto/axis/artpec6_crypto.c b/drivers/crypto/axis/artpec6_crypto.c new file mode 100644 index ..72ce5acf9a24 --- /dev/null +++ b/drivers/crypto/axis/artpec6_crypto.c @@ -0,0 +1,3193 @@ +/* + * Driver for ARTPEC-6 crypto block using the kernel asynchronous crypto api. + * + *Copyright (C) 2014-2017 Axis Communications AB + */ +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +/* Max length of a line in all cache levels for Artpec SoCs. */ +#define ARTPEC_CACHE_LINE_MAX 32 + +#define PDMA_OUT_CFG 0x +#define PDMA_OUT_BUF_CFG 0x0004 +#define PDMA_OUT_CMD 0x0008 +#define PDMA_OUT_DESCRQ_PUSH 0x0010 +#define PDMA_OUT_DESCRQ_STAT 0x0014 + +#define A6_PDMA_IN_CFG 0x0028 +#define A6_PDMA_IN_BUF_CFG 0x002c +#define A6_PDMA_IN_CMD 0x0030 +#define A6_PDMA_IN_STATQ_PUSH 0x0038 +#define A6_PDMA_IN_DESCRQ_PUSH 0x0044 +#define A6_PDMA_IN_DESCRQ_STAT 0x0048 +#define A6_PDMA_INTR_MASK 0x0068 +#define A6_PDMA_ACK_INTR 0x006c +#define A6_PDMA_MASKED_INTR0x0074 + +#define A7_PDMA_IN_CFG 0x002c +#define A7_PDMA_IN_BUF_CFG 0x0030 +#define A7_PDMA_IN_CMD 0x0034 +#define A7_PDMA_IN_STATQ_PUSH 0x003c +#define A7_PDMA_IN_DESCRQ_PUSH 0x0048 +#define A7_PDMA_IN_DESCRQ_STAT 0x004C +#define A7_PDMA_INTR_MASK 0x006c +#define A7_PDMA_ACK_INTR 0x0070 +#define A7_PDMA_MASKED_INTR0x0078 + +#define PDMA_OUT_CFG_ENBIT(0) + +#define PDMA_OUT_BUF_CFG_DATA_BUF_SIZE GENMASK(4, 0) +#define PDMA_OUT_BUF_CFG_DESCR_BUF_SIZEGENMASK(9, 5) + +#define PDMA_OUT_CMD_START BIT(0) +#define A6_PDMA_OUT_CMD_STOP BIT(3) +#define A7_PDMA_OUT_CMD_STOP BIT(2) + +#define PDMA_OUT_DESCRQ_PUSH_LEN GENMASK(5, 0) +#define PDMA_OUT_DESCRQ_PUSH_ADDR GENMASK(31, 6) + +#define PDMA_OUT_DESCRQ_STAT_LEVEL GENMASK(3, 0) +#define PDMA_OUT_DESCRQ_STAT_SIZE GENMASK(7, 4) + +#define PDMA_IN_CFG_EN BIT(0) + +#define PDMA_IN_BUF_CFG_DATA_BUF_SIZE GENMASK(4, 0) +#define PDMA_IN_BUF_CFG_DESCR_BUF_SIZE GENMASK(9, 5) +#define PDMA_IN_BUF_CFG_STAT_BUF_SIZE GENMASK(14, 10) + +#define PDMA_IN_CMD_START BIT(0) +#define A6_PDMA_IN_CMD_FLUSH_STAT BIT(2) +#define A6_PDMA_IN_CMD_STOPBIT(3) +#define A7_PDMA_IN_CMD_FLUSH_STAT BIT(1) +#def
Re: [PATCH] Staging: greybus: Match alignment with open parenthesis.
I don't understand why greybus has to be special instead of the same as everything else. Who cares about this stuff really? Just do whatever is easiest and most common. regards, dan carpenter
Re: [PATCH v2 1/2] x86/amd: Refactor topology extension related code
On Mon, Jul 24, 2017 at 10:28:34AM +0700, Suravee Suthikulpanit wrote:
> Are you referring to the part that I moved the "node_id = ecx & 0xff" ...
Yes, that's what I'm referring to. Btw, I went and did it myself, now
look at my diff below. Now that diff is pretty straight-forward - stuff
is picked from one place and put somewhere else. Exactly like it should
be done.
Your diff is intermixing the new and old function because, *since*
you're touching stuff in there, the diff algorithm can't really detect
the move. Or maybe because you're using an old git but it doesn't look
like it because your patch applied gives the same "intermixed" diff
here.
Also, note that I've made the new function:
+static void __get_topoext(struct cpuinfo_x86 *c, int cpu)
so that you don't have to do smp_processor_id() twice.
Now, after you get it this way, you can start doing your cleanups and
improvements ontop because a diff like that is very easy to review.
Thanks.
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 110ca5d2bb87..ee55f811b8c6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -297,13 +297,55 @@ static int nearby_node(int apicid)
}
#endif
+#ifdef CONFIG_SMP
+
+/*
+ * Get topology information via X86_FEATURE_TOPOEXT.
+ */
+static void __get_topoext(struct cpuinfo_x86 *c, int cpu)
+{
+ u32 eax, ebx, ecx, edx;
+ u8 node_id;
+
+ cpuid(0x801e, &eax, &ebx, &ecx, &edx);
+
+ node_id = ecx & 0xff;
+ smp_num_siblings = ((ebx >> 8) & 0xff) + 1;
+
+ if (c->x86 == 0x15)
+ c->cu_id = ebx & 0xff;
+
+ if (c->x86 >= 0x17) {
+ c->cpu_core_id = ebx & 0xff;
+
+ if (smp_num_siblings > 1)
+ c->x86_max_cores /= smp_num_siblings;
+ }
+
+ /*
+* We may have multiple LLCs if L3 caches exist, so check if we
+* have an L3 cache by looking at the L3 cache CPUID leaf.
+*/
+ if (cpuid_edx(0x8006)) {
+ if (c->x86 == 0x17) {
+ /*
+* LLC is at the core complex level.
+* Core complex id is ApicId[3].
+*/
+ per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
+ } else {
+ /* LLC is at the node level. */
+ per_cpu(cpu_llc_id, cpu) = node_id;
+ }
+ }
+}
+
/*
* Fixup core topology information for
* (1) AMD multi-node processors
* Assumption: Number of cores in each internal node is the same.
* (2) AMD processors supporting compute units
*/
-#ifdef CONFIG_SMP
static void amd_get_topology(struct cpuinfo_x86 *c)
{
u8 node_id;
@@ -311,39 +353,7 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
/* get information required for multi-node processors */
if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
- u32 eax, ebx, ecx, edx;
-
- cpuid(0x801e, &eax, &ebx, &ecx, &edx);
-
- node_id = ecx & 0xff;
- smp_num_siblings = ((ebx >> 8) & 0xff) + 1;
-
- if (c->x86 == 0x15)
- c->cu_id = ebx & 0xff;
-
- if (c->x86 >= 0x17) {
- c->cpu_core_id = ebx & 0xff;
-
- if (smp_num_siblings > 1)
- c->x86_max_cores /= smp_num_siblings;
- }
-
- /*
-* We may have multiple LLCs if L3 caches exist, so check if we
-* have an L3 cache by looking at the L3 cache CPUID leaf.
-*/
- if (cpuid_edx(0x8006)) {
- if (c->x86 == 0x17) {
- /*
-* LLC is at the core complex level.
-* Core complex id is ApicId[3].
-*/
- per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
- } else {
- /* LLC is at the node level. */
- per_cpu(cpu_llc_id, cpu) = node_id;
- }
- }
+ __get_topoext(c, cpu);
} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
u64 value;
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
PERHATIAN
PERHATIAN Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali memvalidasi email mailbox Anda. Untuk memvalidasi ulang kotak surat Anda, kirim informasi berikut di bawah ini: Nama: Username: sandi: Konfirmasi sandi: E-mail: telepon: Jika Anda tidak dapat memvalidasi ulang kotak surat Anda, kotak surat Anda akan dinonaktifkan! Maaf atas ketidaknyamanan ini. Kode verifikasi: en:0986..web...id..nw..website Admin..id...9876mm.2017 Surat Dukungan Teknis ©2017 terima kasih Sistem Administrator
Re: [PATCH] media: imx: prpencvf: enable double write reduction
Hi Steve, On Sat, 2017-07-22 at 15:04 -0700, Steve Longerbeam wrote: > Hi Philipp, > > This is the same as your patch to CSI, applied to ic-prpencvf. > > I'm not really sure what this cpmem bit is doing. The U/V planes > in memory are already subsampled by 2 in both width and height. > This must be referring to what the IDMAC is transferring on the bus, Right, the IDMAC is just receiving AYUV 4:4:4 pixels from the FIFO, the CPMEM settings decide how they are written to the AXI bus. If this bit is not enabled, all pixels are written fully, even though chroma samples of even and odd lines end up in the same place for 4:2:0 chroma subsampled output formats. If the bit is set, the chroma writes for odd lines are skipped, so there is no overdraw. Unfortunately this does not work for reading, unless there is a line buffer (which only the VDIC has), because otherwise odd lines end up without chroma information. This one of the reasons that YUY2 is the most memory efficient format to read, not NV12. > but why would it place duplicate U/V samples on the bus in the first > place? Don't ask me why the hardware was designed this way :) I see no reason to ever disable this bit for YUV420 or NV12 write channels. > Anyway, thanks for the heads-up on this. regards Philipp
Re: [PATCH] media: imx: prpencvf: enable double write reduction
On Sat, 2017-07-22 at 14:21 -0700, Steve Longerbeam wrote: > For the write channels with 4:2:0 subsampled YUV formats, avoid chroma > overdraw by only writing chroma for even lines. Reduces necessary write > memory bandwidth by at least 25% (more with rotation enabled). > > Signed-off-by: Steve Longerbeam Acked-by: Philipp Zabel regards Philipp
[PATCH] tracing: Fix trace_pipe_raw read panic
per_cpu trace directories and files are created for all possible cpus,
but only the cpus which have ever been on-lined have their own per cpu
ring buffer (allocated by cpuhp threads). While trace_buffers_open, the
open handler for trace file 'trace_pipe_raw' is always trying to access
field of ring_buffer_per_cpu, and would panic with the NULL pointer.
Align the behavior of trace_pipe_raw with trace_pipe, that returns -NODEV
when openning it if that cpu does not have trace ring buffer.
Reproduce:
cat /sys/kernel/debug/tracing/per_cpu/cpu31/trace_pipe_raw
(cpu31 is never on-lined, this is a 16 cores x86_64 box)
Tested with:
1) boot with maxcpus=14, read trace_pipe_raw of cpu15.
Got -NODEV.
2) oneline cpu15, read trace_pipe_raw of cpu15.
Get the raw trace data.
Call trace:
[ 5760.950995] RIP: 0010:ring_buffer_alloc_read_page+0x32/0xe0
[ 5760.961678] tracing_buffers_read+0x1f6/0x230
[ 5760.962695] __vfs_read+0x37/0x160
[ 5760.963498] ? __vfs_read+0x5/0x160
[ 5760.964339] ? security_file_permission+0x9d/0xc0
[ 5760.965451] ? __vfs_read+0x5/0x160
[ 5760.966280] vfs_read+0x8c/0x130
[ 5760.967070] SyS_read+0x55/0xc0
[ 5760.967779] do_syscall_64+0x67/0x150
[ 5760.968687] entry_SYSCALL64_slow_path+0x25/0x25
Signed-off-by: Chunyu Hu
---
kernel/trace/ring_buffer.c | 5 +
kernel/trace/trace.c | 14 +-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 4ae268e..66c109e 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -3002,6 +3002,11 @@ int ring_buffer_write(struct ring_buffer *buffer,
}
EXPORT_SYMBOL_GPL(ring_buffer_write);
+bool rb_per_cpu_allocated(struct ring_buffer *buffer, int cpu)
+{
+ return !!cpumask_test_cpu(cpu, buffer->cpumask);
+}
+
static bool rb_per_cpu_empty(struct ring_buffer_per_cpu *cpu_buffer)
{
struct buffer_page *reader = cpu_buffer->reader_page;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 42b9355..508a1ca 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6542,11 +6542,16 @@ static int snapshot_raw_open(struct inode *inode,
struct file *filp)
#endif /* CONFIG_TRACER_SNAPSHOT */
+extern bool rb_per_cpu_allocated(struct ring_buffer *buffer, int cpu);
+
static int tracing_buffers_open(struct inode *inode, struct file *filp)
{
struct trace_array *tr = inode->i_private;
+ struct trace_buffer *tb = &tr->trace_buffer;
+ struct ring_buffer *buffer = tb->buffer;
struct ftrace_buffer_info *info;
int ret;
+ int cpu_file;
if (tracing_disabled)
return -ENODEV;
@@ -6554,6 +6559,13 @@ static int tracing_buffers_open(struct inode *inode,
struct file *filp)
if (trace_array_get(tr) < 0)
return -ENODEV;
+ cpu_file = tracing_get_cpu(inode);
+
+ /* Make sure, ring buffer for this cpu is allocated. */
+ if (cpu_file != RING_BUFFER_ALL_CPUS &&
+ !rb_per_cpu_allocated(buffer, cpu_file))
+ return -ENODEV;
+
info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info) {
trace_array_put(tr);
@@ -6563,7 +6575,7 @@ static int tracing_buffers_open(struct inode *inode,
struct file *filp)
mutex_lock(&trace_types_lock);
info->iter.tr = tr;
- info->iter.cpu_file = tracing_get_cpu(inode);
+ info->iter.cpu_file = cpu_file;
info->iter.trace= tr->current_trace;
info->iter.trace_buffer = &tr->trace_buffer;
info->spare = NULL;
--
1.8.3.1
[PATCH] mm, oom: allow oom reaper to race with exit_mmap
From: Michal Hocko
David has noticed that the oom killer might kill additional tasks while
the exiting oom victim hasn't terminated yet because the oom_reaper marks
the curent victim MMF_OOM_SKIP too early when mm->mm_users dropped down
to 0. The race is as follows
oom_reap_task do_exit
exit_mm
__oom_reap_task_mm
mmput
__mmput
mmget_not_zero # fails
exit_mmap # frees memory
set_bit(MMF_OOM_SKIP)
The victim is still visible to the OOM killer until it is unhashed.
Currently we try to reduce a risk of this race by taking oom_lock
and wait for out_of_memory sleep while holding the lock to give the
victim some time to exit. This is quite suboptimal approach because
there is no guarantee the victim (especially a large one) will manage
to unmap its address space and free enough memory to the particular oom
domain which needs a memory (e.g. a specific NUMA node).
Fix this problem by allowing __oom_reap_task_mm and __mmput path to
race. __oom_reap_task_mm is basically MADV_DONTNEED and that is allowed
to run in parallel with other unmappers (hence the mmap_sem for read).
The only tricky part is to exclude page tables tear down and all
operations which modify the address space in the __mmput path. exit_mmap
doesn't expect any other users so it doesn't use any locking. Nothing
really forbids us to use mmap_sem for write, though. In fact we are
already relying on this lock earlier in the __mmput path to synchronize
with ksm and khugepaged.
Take the exclusive mmap_sem when calling free_pgtables and destroying
vmas to sync with __oom_reap_task_mm which take the lock for read. All
other operations can safely race with the parallel unmap.
Changes
- bail on null mm->mmap early as per David Rientjes
Reported-by: David Rientjes
Fixes: 26db62f179d1 ("oom: keep mm of the killed task available")
Signed-off-by: Michal Hocko
---
Hi,
I've sent this as an RFC [1] previously and it seems that the original
issue has been resolved [2], although an explicit tested-by would be
appreciated of course. Hugh has pointed out [3] that using mmap_sem
in exit_mmap will allow to drop the tricky
down_write(mmap_sem);
up_write(mmap_sem);
in both paths. I hope I will get to that in a forseeable future.
I am not yet sure this is important enough to merge to stable trees,
I would rather wait for a report to show up.
[1] http://lkml.kernel.org/r/20170626130346.26314-1-mho...@kernel.org
[2]
http://lkml.kernel.org/r/alpine.deb.2.10.1707111336250.60...@chino.kir.corp.google.com
[3] http://lkml.kernel.org/r/alpine.LSU.2.11.1707191716030.2055@eggly.anvils
mm/mmap.c | 7 +++
mm/oom_kill.c | 45 +++--
2 files changed, 14 insertions(+), 38 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 24e9261bdcc0..0eeb658caa30 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2993,6 +2993,11 @@ void exit_mmap(struct mm_struct *mm)
/* Use -1 here to ensure all VMAs in the mm are unmapped */
unmap_vmas(&tlb, vma, 0, -1);
+ /*
+* oom reaper might race with exit_mmap so make sure we won't free
+* page tables or unmap VMAs under its feet
+*/
+ down_write(&mm->mmap_sem);
free_pgtables(&tlb, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
tlb_finish_mmu(&tlb, 0, -1);
@@ -3005,7 +3010,9 @@ void exit_mmap(struct mm_struct *mm)
nr_accounted += vma_pages(vma);
vma = remove_vma(vma);
}
+ mm->mmap = NULL;
vm_unacct_memory(nr_accounted);
+ up_write(&mm->mmap_sem);
}
/* Insert vm structure into process list sorted by address
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 9e8b4f030c1c..a6dabe3691c1 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -470,40 +470,15 @@ static bool __oom_reap_task_mm(struct task_struct *tsk,
struct mm_struct *mm)
{
struct mmu_gather tlb;
struct vm_area_struct *vma;
- bool ret = true;
-
- /*
-* We have to make sure to not race with the victim exit path
-* and cause premature new oom victim selection:
-* __oom_reap_task_mm exit_mm
-* mmget_not_zero
-*mmput
-* atomic_dec_and_test
-*exit_oom_victim
-* [...]
-* out_of_memory
-*select_bad_process
-* # no TIF_MEMDIE task selects new
victim
-* unmap_page_range # frees some memory
-*/
- mutex_lock(&oom_lock);
if (!down_read_trylock(&mm->mmap_sem)) {
- ret = false;
trace_skip_ta
Re: [PATCH 1/3] irq/irq_sim: add a simple interrupt simulator framework
On 07/19/2017 02:20 PM, Bartosz Golaszewski wrote:
[...]
> +void irq_sim_fini(struct irq_sim *sim)
> +{
Not very likely to happen in practice, but for correctness we should
probably put a irq_work_sync() here for each of the IRQs to make sure that
the memory associated with the irq_sim_work_ctx struct is no longer accessed
and that handle_simple_irq() is not called after irq_free_descs().
> + irq_free_descs(sim->irq_base, sim->irq_count);
> + kfree(sim->irqs);
> +}
> +EXPORT_SYMBOL_GPL(irq_sim_fini);
Re: [PATCH 4/4] perf stat: Use group read for event groups
On Sun, Jul 23, 2017 at 09:53:00AM +0900, Namhyung Kim wrote:
SNIP
> > Link: http://lkml.kernel.org/n/tip-b6g8qarwvptr81cqdtfst...@git.kernel.org
> > Signed-off-by: Jiri Olsa
> > ---
> > tools/perf/builtin-stat.c | 30 +++---
> > tools/perf/util/counts.h | 1 +
> > tools/perf/util/evsel.c | 10 ++
> > 3 files changed, 38 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> > index 48ac53b199fc..866da7aa54bf 100644
> > --- a/tools/perf/builtin-stat.c
> > +++ b/tools/perf/builtin-stat.c
> > @@ -213,10 +213,20 @@ static void perf_stat__reset_stats(void)
> > static int create_perf_stat_counter(struct perf_evsel *evsel)
> > {
> > struct perf_event_attr *attr = &evsel->attr;
> > + struct perf_evsel *leader = evsel->leader;
> >
> > - if (stat_config.scale)
> > + if (stat_config.scale) {
> > attr->read_format = PERF_FORMAT_TOTAL_TIME_ENABLED |
> > PERF_FORMAT_TOTAL_TIME_RUNNING;
> > + }
> > +
> > + /*
> > +* The event is part of non trivial group, let's enable
> > +* the group read (for leader) and ID retrieval for all
> > +* members.
> > +*/
> > + if (leader->nr_members > 1)
> > + attr->read_format |= PERF_FORMAT_ID|PERF_FORMAT_GROUP;
>
> I just wonder ID is really necessary. Doesn't it have same order we
> can traverse with the for_each_group_member()?
right, but I don't like to rely on user and kernel space
order to stay the same.. I don't think it's guaranteed
in uapi
jirka
Re: A udev rule to serve the change event of ACPI container?
Hi Yasuaki, On Fri, Jul 14, 2017 at 10:44:14PM +0800, joeyli wrote: > On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote: > > On Thu 13-07-17 20:45:21, Joey Lee wrote: > > > On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > > > > On Thu 13-07-17 14:58:06, Joey Lee wrote: > > [...] > > > > > If BIOS emits ejection event for a ACPI0004 container, someone needs > > > > > to handle the offline/eject jobs of container. Either kernel or user > > > > > space. > > > > > > > > > > Only sending uevent to individual child device can simplify udev rule, > > > > > but it also means that the kernel needs to offline/eject container > > > > > after all children devices are offlined. > > > > > > > > Why cannot kernel send this eject command to the BIOS if the whole > > > > container is offline? If it is not then the kernel would send EBUSY to > > > > > > Current kernel container hot-remove process: > > > > > > BIOS -> SCI event -> Kernel ACPI -> uevent -> userland > > > > > > Then, kernel just calls _OST to expose state to BIOS, then process is > > > stopped. Kernel doesn't wait there for userland to offline each child > > > devices. Either BIOS or userland needs to trigger the container > > > ejection. > > > > > > > container is offline? If it is not then the kernel would send EBUSY to > > > > the BIOS and BIOS would have to retry after some timeout. Or is it a > > > > > > The d429e5c122 patch is merged to mainline. So kernel will send > > > DEVICE_BUSY to BIOS after it emits uevent to userland. BIOS can choice > > > to apply the retry approach until OS returns process failure exactly or > > > BIOS timeout. > > > > > > > problem that currently implemented BIOS firmwares do not implement this > > > > retry? > > > > > > Yes, we should consider the behavior of old BIOS. Old BIOS doesn't > > > retry/resend the ejection event. So kernel or userland need to take the > > > retry job. Obviously userland runs the retry since the caa73ea15 patch > > > is merged. > > > > > > IMHO there have two different expectation from user space application. > > > > > > Applications like DVD player or Burner expect that kernel should > > > info userspace for the ejection, then application can do their cleaning > > > job and re-trigger ejection from userland. > > > > I am not sure I understand the DVD example because I do not see how it > > fits into the container and online/offline scenario. > > > > At least Yasuaki raised similar behavior for container in 2013. > It's similar to the DVD player case, user space application needs > to do something then trigger children offline and ejection of > container. > > Base on Yasuaki's explanation, the reason of that he requested the > userland ejection approach is that he got memory hot-remove problem > in 2013. Maybe his problem is already fixed by your patches in current > mainline. > > Hi Yasuaki, could you please check that your memory hot-remove problem > is fixed on mainline kernel? > > If Yasuaki's issue is already fixed, then we should consider to let > kernel does the container hot-remove transparently. Could you please help to check that your memory hot-remove problem in 2013 is fixed on mainline kernel? Thanks a lot! Joey Lee
Re: [PATCH] staging: vboxvideo: Kconfig: Fix typos in help text
Hi, On 24-07-17 08:45, Martin Kepplinger wrote: This fixes typos in vboxvideo's help text. Signed-off-by: Martin Kepplinger Looks good to me: Acked-by: Hans de Goede Regards, Hans --- drivers/staging/vboxvideo/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/vboxvideo/Kconfig b/drivers/staging/vboxvideo/Kconfig index a52746f9a670..2b058d573cf1 100644 --- a/drivers/staging/vboxvideo/Kconfig +++ b/drivers/staging/vboxvideo/Kconfig @@ -6,7 +6,7 @@ config DRM_VBOXVIDEO This is a KMS driver for the virtual Graphics Card used in Virtual Box virtual machines. - Although it is possible to builtin this module, it is advised + Although it is possible to build in this module, it is advised to build this driver as a module, so that it can be updated - independently of the kernel. Select M to built this driver as a + independently of the kernel. Select M to build this driver as a module and add support for these devices via drm/kms interfaces.
Re: [PATCH 1/3] staging: pi433: Style fix - align block comments
On Sat, Jul 22, 2017 at 03:50:50PM +1200, Derek Robson wrote: > + * // RegOsc1 > + * #define OSC1_RCCAL_START 0x80 > + * #define OSC1_RCCAL_DONE 0x40 > + * Why do we have all these commented out defines? regards, dan carpenter
Re: [PATCH 1/3] iio: adc: stm32: fix common clock rate
On 07/23/2017 12:51 PM, Jonathan Cameron wrote:
> On Tue, 18 Jul 2017 14:35:30 +0200
> Fabrice Gasnier wrote:
>
>> Fixes commit 95e339b6e85d ("iio: adc: stm32: add support for STM32H7")
>>
>> Fix common clock rate used then by stm32-adc sub-devices: take common
>> prescaler into account.
>> Fix ADC max clock rate on STM32H7 (fADC from datasheet)
>>
>> Signed-off-by: Fabrice Gasnier
> Patch itself is fine, but the description could do with
> information on what the result of this being wrong is.
Hi Jonathan,
I agree with you and will improve description in v2. I'm thinking of:
Fixes: 95e339b6e85d ("iio: adc: stm32: add support for STM32H7")
ADC clock input is provided to internal prescaler (that decreases its
frequency). It's then used as reference clock for conversions.
- Fix common clock rate used then by stm32-adc sub-devices. Take common
prescaler into account. Currently, rate is used to set "boost" mode. It
may unnecessarily be set. This impacts power consumption.
- Fix ADC max clock rate on STM32H7 (fADC from datasheet). Currently,
prescaler may be set too low. This can result in ADC reference clock
used for conversion to exceed max allowed clock frequency.
>
> I have no idea if this is a patch I should be sending upstream
> asap or should hold for the next merge window.
Probably yes... I hope the description is better above? Just to mention
this impacts stm32h7 adc, device tree node to use it is not yet integrated.
Thanks for your review,
Best Regards,
Fabrice
>
> Thanks,
>
> Jonathan
>> ---
>> drivers/iio/adc/stm32-adc-core.c | 10 +-
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/iio/adc/stm32-adc-core.c
>> b/drivers/iio/adc/stm32-adc-core.c
>> index e09233b..6096763 100644
>> --- a/drivers/iio/adc/stm32-adc-core.c
>> +++ b/drivers/iio/adc/stm32-adc-core.c
>> @@ -64,7 +64,7 @@
>> #define STM32H7_CKMODE_MASK GENMASK(17, 16)
>>
>> /* STM32 H7 maximum analog clock rate (from datasheet) */
>> -#define STM32H7_ADC_MAX_CLK_RATE7200
>> +#define STM32H7_ADC_MAX_CLK_RATE3600
>>
>> /**
>> * stm32_adc_common_regs - stm32 common registers, compatible dependent data
>> @@ -148,14 +148,14 @@ static int stm32f4_adc_clk_sel(struct platform_device
>> *pdev,
>> return -EINVAL;
>> }
>>
>> -priv->common.rate = rate;
>> +priv->common.rate = rate / stm32f4_pclk_div[i];
>> val = readl_relaxed(priv->common.base + STM32F4_ADC_CCR);
>> val &= ~STM32F4_ADC_ADCPRE_MASK;
>> val |= i << STM32F4_ADC_ADCPRE_SHIFT;
>> writel_relaxed(val, priv->common.base + STM32F4_ADC_CCR);
>>
>> dev_dbg(&pdev->dev, "Using analog clock source at %ld kHz\n",
>> -rate / (stm32f4_pclk_div[i] * 1000));
>> +priv->common.rate / 1000);
>>
>> return 0;
>> }
>> @@ -250,7 +250,7 @@ static int stm32h7_adc_clk_sel(struct platform_device
>> *pdev,
>>
>> out:
>> /* rate used later by each ADC instance to control BOOST mode */
>> -priv->common.rate = rate;
>> +priv->common.rate = rate / div;
>>
>> /* Set common clock mode and prescaler */
>> val = readl_relaxed(priv->common.base + STM32H7_ADC_CCR);
>> @@ -260,7 +260,7 @@ static int stm32h7_adc_clk_sel(struct platform_device
>> *pdev,
>> writel_relaxed(val, priv->common.base + STM32H7_ADC_CCR);
>>
>> dev_dbg(&pdev->dev, "Using %s clock/%d source at %ld kHz\n",
>> -ckmode ? "bus" : "adc", div, rate / (div * 1000));
>> +ckmode ? "bus" : "adc", div, priv->common.rate / 1000);
>>
>> return 0;
>> }
>
Re: [PATCH] perf tool sort: Use default sort if evlist is empty
On Sun, Jul 23, 2017 at 08:09:49AM +0900, Namhyung Kim wrote: SNIP > > > also I've got another crash for (added -a option for above example): > > > > > > [root@krava perf]# ./perf record -e 'sched:sched_switch' -a sleep > > > 1 | ./perf report > > > # To display the perf.data header info, please use > > > --header/--header-only options. > > > # > > > [ perf record: Woken up 1 times to write data ] > > > [ perf record: Captured and wrote 0.000 MB (null) ] > > > Segmentation fault (core dumped) > > > > > > catchsegv got: > > > > > > /home/jolsa/kernel/linux-perf/tools/perf/util/ordered-events.c:85(free_dup_event)[0x51a6a5] > > > ./perf(ordered_events__free+0x5c)[0x51b0b7] > > > > > > /home/jolsa/kernel/linux-perf/tools/perf/util/session.c:1751(__perf_session__process_pipe_events)[0x518abb] > > > ./perf(perf_session__process_events+0x91)[0x5190f0] > > > > > > /home/jolsa/kernel/linux-perf/tools/perf/builtin-report.c:598(__cmd_report)[0x443a91] > > > ./perf(cmd_report+0x169b)[0x4455a3] > > > > > > /home/jolsa/kernel/linux-perf/tools/perf/perf.c:296(run_builtin)[0x4be1b0] > > > > > > /home/jolsa/kernel/linux-perf/tools/perf/perf.c:348(handle_internal_command)[0x4be41d] > > > > > > /home/jolsa/kernel/linux-perf/tools/perf/perf.c:395(run_argv)[0x4be56f] > > > ./perf(main+0x2d6)[0x4be949] > > > /lib64/libc.so.6(__libc_start_main+0xf1)[0x7f3de8a10401] > > > ./perf(_start+0x2a)[0x42831a] > > > > > > looks like some mem corruption.. will try to follow up > > > on this later if nobody beats me to it ;-) > > > > Cannot reproduce it in acme's perf/core building the tool with > > make NO_LIBPYTHON=1 LDFLAGS=-static > > > > If you have a file with the perf record output causing perf report's > > crash, I'd like to take a look. hm, I can't reproduce any longer.. :-\ jirka
[PATCH v5 02/14] spi: qup: Setup DMA mode correctly
To operate in DMA mode, the buffer should be aligned and
the size of the transfer should be a multiple of block size
(for v1). And the no. of words being transferred should
be programmed in the count registers appropriately.
Signed-off-by: Andy Gross
Signed-off-by: Varadarajan Narayanan
---
drivers/spi/spi-qup.c | 118 +++---
1 file changed, 55 insertions(+), 63 deletions(-)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index c0d4def..abe799b 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -149,11 +149,18 @@ struct spi_qup {
int rx_bytes;
int qup_v1;
- int use_dma;
+ int mode;
struct dma_slave_config rx_conf;
struct dma_slave_config tx_conf;
};
+static inline bool spi_qup_is_dma_xfer(int mode)
+{
+ if (mode == QUP_IO_M_MODE_DMOV || mode == QUP_IO_M_MODE_BAM)
+ return true;
+
+ return false;
+}
static inline bool spi_qup_is_valid_state(struct spi_qup *controller)
{
@@ -424,7 +431,7 @@ static irqreturn_t spi_qup_qup_irq(int irq, void *dev_id)
error = -EIO;
}
- if (!controller->use_dma) {
+ if (!spi_qup_is_dma_xfer(controller->mode)) {
if (opflags & QUP_OP_IN_SERVICE_FLAG)
spi_qup_fifo_read(controller, xfer);
@@ -443,34 +450,11 @@ static irqreturn_t spi_qup_qup_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static u32
-spi_qup_get_mode(struct spi_master *master, struct spi_transfer *xfer)
-{
- struct spi_qup *qup = spi_master_get_devdata(master);
- u32 mode;
-
- qup->w_size = 4;
-
- if (xfer->bits_per_word <= 8)
- qup->w_size = 1;
- else if (xfer->bits_per_word <= 16)
- qup->w_size = 2;
-
- qup->n_words = xfer->len / qup->w_size;
-
- if (qup->n_words <= (qup->in_fifo_sz / sizeof(u32)))
- mode = QUP_IO_M_MODE_FIFO;
- else
- mode = QUP_IO_M_MODE_BLOCK;
-
- return mode;
-}
-
/* set clock freq ... bits per word */
static int spi_qup_io_config(struct spi_device *spi, struct spi_transfer *xfer)
{
struct spi_qup *controller = spi_master_get_devdata(spi->master);
- u32 config, iomode, mode, control;
+ u32 config, iomode, control;
int ret, n_words;
if (spi->mode & SPI_LOOP && xfer->len > controller->in_fifo_sz) {
@@ -491,25 +475,30 @@ static int spi_qup_io_config(struct spi_device *spi,
struct spi_transfer *xfer)
return -EIO;
}
- mode = spi_qup_get_mode(spi->master, xfer);
+ controller->w_size = DIV_ROUND_UP(xfer->bits_per_word, 8);
+ controller->n_words = xfer->len / controller->w_size;
n_words = controller->n_words;
- if (mode == QUP_IO_M_MODE_FIFO) {
+ if (n_words <= (controller->in_fifo_sz / sizeof(u32))) {
+
+ controller->mode = QUP_IO_M_MODE_FIFO;
+
writel_relaxed(n_words, controller->base + QUP_MX_READ_CNT);
writel_relaxed(n_words, controller->base + QUP_MX_WRITE_CNT);
/* must be zero for FIFO */
writel_relaxed(0, controller->base + QUP_MX_INPUT_CNT);
writel_relaxed(0, controller->base + QUP_MX_OUTPUT_CNT);
- } else if (!controller->use_dma) {
+ } else if (spi->master->can_dma &&
+ spi->master->can_dma(spi->master, spi, xfer) &&
+ spi->master->cur_msg_mapped) {
+
+ controller->mode = QUP_IO_M_MODE_BAM;
+
writel_relaxed(n_words, controller->base + QUP_MX_INPUT_CNT);
writel_relaxed(n_words, controller->base + QUP_MX_OUTPUT_CNT);
/* must be zero for BLOCK and BAM */
writel_relaxed(0, controller->base + QUP_MX_READ_CNT);
writel_relaxed(0, controller->base + QUP_MX_WRITE_CNT);
- } else {
- mode = QUP_IO_M_MODE_BAM;
- writel_relaxed(0, controller->base + QUP_MX_READ_CNT);
- writel_relaxed(0, controller->base + QUP_MX_WRITE_CNT);
if (!controller->qup_v1) {
void __iomem *input_cnt;
@@ -528,19 +517,28 @@ static int spi_qup_io_config(struct spi_device *spi,
struct spi_transfer *xfer)
writel_relaxed(0, controller->base + QUP_MX_OUTPUT_CNT);
}
+ } else {
+
+ controller->mode = QUP_IO_M_MODE_BLOCK;
+
+ writel_relaxed(n_words, controller->base + QUP_MX_INPUT_CNT);
+ writel_relaxed(n_words, controller->base + QUP_MX_OUTPUT_CNT);
+ /* must be zero for BLOCK and BAM */
+ writel_relaxed(0, controller->base + QUP_MX_READ_CNT);
+ writel_relaxed(0, controller->base + QUP_MX_WRITE_CNT);
}
iomode = readl_relaxed(controller->bas
[PATCH v5 01/14] spi: qup: Enable chip select support
Enable chip select support for QUP versions later than v1. The
chip select support was broken in QUP version 1. Hence the chip
select support was removed earlier in an earlier commit
(4a8573abe "spi: qup: Remove chip select function"). Since the
chip select support is functional in recent versions of QUP,
re-enabling it for QUP versions later than v1.
Signed-off-by: Sham Muthayyan
Signed-off-by: Varadarajan Narayanan
---
drivers/spi/spi-qup.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index 1bfa889..c0d4def 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -750,6 +750,24 @@ static int spi_qup_init_dma(struct spi_master *master,
resource_size_t base)
return ret;
}
+static void spi_qup_set_cs(struct spi_device *spi, bool val)
+{
+ struct spi_qup *controller;
+ u32 spi_ioc;
+ u32 spi_ioc_orig;
+
+ controller = spi_master_get_devdata(spi->master);
+ spi_ioc = readl_relaxed(controller->base + SPI_IO_CONTROL);
+ spi_ioc_orig = spi_ioc;
+ if (!val)
+ spi_ioc |= SPI_IO_C_FORCE_CS;
+ else
+ spi_ioc &= ~SPI_IO_C_FORCE_CS;
+
+ if (spi_ioc != spi_ioc_orig)
+ writel_relaxed(spi_ioc, controller->base + SPI_IO_CONTROL);
+}
+
static int spi_qup_probe(struct platform_device *pdev)
{
struct spi_master *master;
@@ -846,6 +864,9 @@ static int spi_qup_probe(struct platform_device *pdev)
if (of_device_is_compatible(dev->of_node, "qcom,spi-qup-v1.1.1"))
controller->qup_v1 = 1;
+ if (!controller->qup_v1)
+ master->set_cs = spi_qup_set_cs;
+
spin_lock_init(&controller->lock);
init_completion(&controller->done);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
[PATCH v5 00/14] spi: qup: Fixes and add support for >64k transfers
v5: Incorporate feedback from Mark Brown and Geert Uytterhoeven spi: qup: Enable chip select support Update commit log. Include the commit's description Removed "spi: qup: Add completion structures for DMA". This introduced separate completion structures for DMA based rx/tx and FIFO based i/os. This was not needed. Added "spi: qup: Fix QUP version identify method" to identify qup version using of_device_get_match_data instead of of_device_is_compatible. v4: Discard patch #15, 'spi: qup: support for qup v1 dma'. This depends on ADM driver, which is not upstreamed yet. v3: Fix git bisect-ability issues in spi: qup: Add completion structures for DMA spi: qup: Add completion timeout spi: qup: Place the QUP in run mode before DMA spi: qup: Fix transaction done signaling v2: Incorporate feedback from Andy Gross, Sricharan, Stanimir Varbanov Modified the QUP-v1 dma completion sequence to QUP-v2 as per feedback. Removed code that used controller->xfer to identify extra interrupts, since with the fixes done to handle i/o completion we don't see extra interrupts. v1: This series fixes some existing issues in the code for both interrupt and dma mode. Patches 1 - 11 are the fixes. Random failures/timeout are observed without these fixes. Also, the current driver does not support block transfers > 64K and the driver quietly fails. Patches 12 - 18 add support for this in both interrupt and dma mode. The entire series has been tested on ipq4019 with SPI-NOR flash for block sizes > 64k. Varadarajan Narayanan (14): spi: qup: Enable chip select support spi: qup: Setup DMA mode correctly spi: qup: Add completion timeout spi: qup: Place the QUP in run mode before DMA spi: qup: Fix error handling in spi_qup_prep_sg spi: qup: Fix transaction done signaling spi: qup: Do block sized read/write in block mode spi: qup: refactor spi_qup_io_config into two functions spi: qup: call io_config in mode specific function spi: qup: allow block mode to generate multiple transactions spi: qup: refactor spi_qup_prep_sg spi: qup: allow multiple DMA transactions per spi xfer spi: qup: Ensure done detection spi: qup: Fix QUP version identify method drivers/spi/spi-qup.c | 566 ++ 1 file changed, 392 insertions(+), 174 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v5 05/14] spi: qup: Fix error handling in spi_qup_prep_sg
Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c index e6294f8..aa1b7b8 100644 --- a/drivers/spi/spi-qup.c +++ b/drivers/spi/spi-qup.c @@ -311,8 +311,8 @@ static int spi_qup_prep_sg(struct spi_master *master, struct spi_transfer *xfer, } desc = dmaengine_prep_slave_sg(chan, sgl, nents, dir, flags); - if (!desc) - return -EINVAL; + if (IS_ERR_OR_NULL(desc)) + return desc ? PTR_ERR(desc) : -EINVAL; desc->callback = callback; desc->callback_param = qup; -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v5 03/14] spi: qup: Add completion timeout
Add i/o completion timeout for DMA and PIO modes.
Signed-off-by: Andy Gross
Signed-off-by: Varadarajan Narayanan
---
drivers/spi/spi-qup.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index abe799b..92922b6 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -331,7 +331,8 @@ static void spi_qup_dma_terminate(struct spi_master *master,
dmaengine_terminate_all(master->dma_rx);
}
-static int spi_qup_do_dma(struct spi_master *master, struct spi_transfer *xfer)
+static int spi_qup_do_dma(struct spi_master *master, struct spi_transfer *xfer,
+ unsigned long timeout)
{
dma_async_tx_callback rx_done = NULL, tx_done = NULL;
int ret;
@@ -357,10 +358,17 @@ static int spi_qup_do_dma(struct spi_master *master,
struct spi_transfer *xfer)
dma_async_issue_pending(master->dma_tx);
}
+ if (rx_done && !wait_for_completion_timeout(&qup->done, timeout))
+ return -ETIMEDOUT;
+
+ if (tx_done && !wait_for_completion_timeout(&qup->done, timeout))
+ return -ETIMEDOUT;
+
return 0;
}
-static int spi_qup_do_pio(struct spi_master *master, struct spi_transfer *xfer)
+static int spi_qup_do_pio(struct spi_master *master, struct spi_transfer *xfer,
+ unsigned long timeout)
{
struct spi_qup *qup = spi_master_get_devdata(master);
int ret;
@@ -379,6 +387,9 @@ static int spi_qup_do_pio(struct spi_master *master, struct
spi_transfer *xfer)
spi_qup_fifo_write(qup, xfer);
+ if (!wait_for_completion_timeout(&qup->done, timeout))
+ return -ETIMEDOUT;
+
return 0;
}
@@ -632,9 +643,9 @@ static int spi_qup_transfer_one(struct spi_master *master,
spin_unlock_irqrestore(&controller->lock, flags);
if (spi_qup_is_dma_xfer(controller->mode))
- ret = spi_qup_do_dma(master, xfer);
+ ret = spi_qup_do_dma(master, xfer, timeout);
else
- ret = spi_qup_do_pio(master, xfer);
+ ret = spi_qup_do_pio(master, xfer, timeout);
if (ret)
goto exit;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
[PATCH v5 08/14] spi: qup: refactor spi_qup_io_config into two functions
This is in preparation for handling transactions larger than
64K-1 bytes in block mode, which is currently unsupported and
quietly fails.
We need to break these into two functions 1) prep is
called once per spi_message and 2) io_config is called
once per spi-qup bus transaction
This is just refactoring, there should be no functional
change
Signed-off-by: Matthew McClintock
Signed-off-by: Varadarajan Narayanan
---
drivers/spi/spi-qup.c | 91 +++
1 file changed, 62 insertions(+), 29 deletions(-)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index d819f87..82593f6 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -547,12 +547,11 @@ static irqreturn_t spi_qup_qup_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
-/* set clock freq ... bits per word */
-static int spi_qup_io_config(struct spi_device *spi, struct spi_transfer *xfer)
+/* set clock freq ... bits per word, determine mode */
+static int spi_qup_io_prep(struct spi_device *spi, struct spi_transfer *xfer)
{
struct spi_qup *controller = spi_master_get_devdata(spi->master);
- u32 config, iomode, control;
- int ret, n_words;
+ int ret;
if (spi->mode & SPI_LOOP && xfer->len > controller->in_fifo_sz) {
dev_err(controller->dev, "too big size for loopback %d > %d\n",
@@ -567,32 +566,56 @@ static int spi_qup_io_config(struct spi_device *spi,
struct spi_transfer *xfer)
return -EIO;
}
- if (spi_qup_set_state(controller, QUP_STATE_RESET)) {
- dev_err(controller->dev, "cannot set RESET state\n");
- return -EIO;
- }
-
controller->w_size = DIV_ROUND_UP(xfer->bits_per_word, 8);
controller->n_words = xfer->len / controller->w_size;
- n_words = controller->n_words;
-
- if (n_words <= (controller->in_fifo_sz / sizeof(u32))) {
+ if (controller->n_words <= (controller->in_fifo_sz / sizeof(u32)))
controller->mode = QUP_IO_M_MODE_FIFO;
+ else if (spi->master->can_dma &&
+spi->master->can_dma(spi->master, spi, xfer) &&
+spi->master->cur_msg_mapped)
+ controller->mode = QUP_IO_M_MODE_BAM;
+ else
+ controller->mode = QUP_IO_M_MODE_BLOCK;
+
+ return 0;
+}
+
+/* prep qup for another spi transaction of specific type */
+static int spi_qup_io_config(struct spi_device *spi, struct spi_transfer *xfer)
+{
+ struct spi_qup *controller = spi_master_get_devdata(spi->master);
+ u32 config, iomode, control;
+ unsigned long flags;
+
+ spin_lock_irqsave(&controller->lock, flags);
+ controller->xfer = xfer;
+ controller->error= 0;
+ controller->rx_bytes = 0;
+ controller->tx_bytes = 0;
+ spin_unlock_irqrestore(&controller->lock, flags);
+
+
+ if (spi_qup_set_state(controller, QUP_STATE_RESET)) {
+ dev_err(controller->dev, "cannot set RESET state\n");
+ return -EIO;
+ }
- writel_relaxed(n_words, controller->base + QUP_MX_READ_CNT);
- writel_relaxed(n_words, controller->base + QUP_MX_WRITE_CNT);
+ switch (controller->mode) {
+ case QUP_IO_M_MODE_FIFO:
+ writel_relaxed(controller->n_words,
+ controller->base + QUP_MX_READ_CNT);
+ writel_relaxed(controller->n_words,
+ controller->base + QUP_MX_WRITE_CNT);
/* must be zero for FIFO */
writel_relaxed(0, controller->base + QUP_MX_INPUT_CNT);
writel_relaxed(0, controller->base + QUP_MX_OUTPUT_CNT);
- } else if (spi->master->can_dma &&
- spi->master->can_dma(spi->master, spi, xfer) &&
- spi->master->cur_msg_mapped) {
-
- controller->mode = QUP_IO_M_MODE_BAM;
-
- writel_relaxed(n_words, controller->base + QUP_MX_INPUT_CNT);
- writel_relaxed(n_words, controller->base + QUP_MX_OUTPUT_CNT);
+ break;
+ case QUP_IO_M_MODE_BAM:
+ writel_relaxed(controller->n_words,
+ controller->base + QUP_MX_INPUT_CNT);
+ writel_relaxed(controller->n_words,
+ controller->base + QUP_MX_OUTPUT_CNT);
/* must be zero for BLOCK and BAM */
writel_relaxed(0, controller->base + QUP_MX_READ_CNT);
writel_relaxed(0, controller->base + QUP_MX_WRITE_CNT);
@@ -610,19 +633,25 @@ static int spi_qup_io_config(struct spi_device *spi,
struct spi_transfer *xfer)
if (xfer->tx_buf)
writel_relaxed(0, input_cnt);
else
- writel_relaxed(n_words, input_cnt);
+ writel_relaxed(controller->n_words, input_cnt);
[PATCH v5 10/14] spi: qup: allow block mode to generate multiple transactions
This let's you write more to the SPI bus than 64K-1 which is important
if the block size of a SPI device is >= 64K or some other device wants
to do something larger.
This has the benefit of completely removing spi_message from the spi-qup
transactions
Signed-off-by: Matthew McClintock
Signed-off-by: Varadarajan Narayanan
---
drivers/spi/spi-qup.c | 128 +++---
1 file changed, 80 insertions(+), 48 deletions(-)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index b2bda47..67e7463 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -120,7 +120,7 @@
#define SPI_NUM_CHIPSELECTS4
-#define SPI_MAX_DMA_XFER (SZ_64K - 64)
+#define SPI_MAX_XFER (SZ_64K - 64)
/* high speed mode is when bus rate is greater then 26MHz */
#define SPI_HS_MIN_RATE2600
@@ -149,6 +149,8 @@ struct spi_qup {
int n_words;
int tx_bytes;
int rx_bytes;
+ const u8*tx_buf;
+ u8 *rx_buf;
int qup_v1;
int mode;
@@ -173,6 +175,12 @@ static inline bool spi_qup_is_dma_xfer(int mode)
return false;
}
+/* get's the transaction size length */
+static inline unsigned int spi_qup_len(struct spi_qup *controller)
+{
+ return controller->n_words * controller->w_size;
+}
+
static inline bool spi_qup_is_valid_state(struct spi_qup *controller)
{
u32 opstate = readl_relaxed(controller->base + QUP_STATE);
@@ -225,10 +233,9 @@ static int spi_qup_set_state(struct spi_qup *controller,
u32 state)
return 0;
}
-static void spi_qup_read_from_fifo(struct spi_qup *controller,
- struct spi_transfer *xfer, u32 num_words)
+static void spi_qup_read_from_fifo(struct spi_qup *controller, u32 num_words)
{
- u8 *rx_buf = xfer->rx_buf;
+ u8 *rx_buf = controller->rx_buf;
int i, shift, num_bytes;
u32 word;
@@ -236,8 +243,9 @@ static void spi_qup_read_from_fifo(struct spi_qup
*controller,
word = readl_relaxed(controller->base + QUP_INPUT_FIFO);
- num_bytes = min_t(int, xfer->len - controller->rx_bytes,
- controller->w_size);
+ num_bytes = min_t(int, spi_qup_len(controller) -
+ controller->rx_bytes,
+ controller->w_size);
if (!rx_buf) {
controller->rx_bytes += num_bytes;
@@ -258,13 +266,12 @@ static void spi_qup_read_from_fifo(struct spi_qup
*controller,
}
}
-static void spi_qup_read(struct spi_qup *controller,
- struct spi_transfer *xfer)
+static void spi_qup_read(struct spi_qup *controller)
{
u32 remainder, words_per_block, num_words;
bool is_block_mode = controller->mode == QUP_IO_M_MODE_BLOCK;
- remainder = DIV_ROUND_UP(xfer->len - controller->rx_bytes,
+ remainder = DIV_ROUND_UP(spi_qup_len(controller) - controller->rx_bytes,
controller->w_size);
words_per_block = controller->in_blk_sz >> 2;
@@ -285,7 +292,7 @@ static void spi_qup_read(struct spi_qup *controller,
}
/* read up to the maximum transfer size available */
- spi_qup_read_from_fifo(controller, xfer, num_words);
+ spi_qup_read_from_fifo(controller, num_words);
remainder -= num_words;
@@ -307,18 +314,18 @@ static void spi_qup_read(struct spi_qup *controller,
}
-static void spi_qup_write_to_fifo(struct spi_qup *controller,
- struct spi_transfer *xfer, u32 num_words)
+static void spi_qup_write_to_fifo(struct spi_qup *controller, u32 num_words)
{
- const u8 *tx_buf = xfer->tx_buf;
+ const u8 *tx_buf = controller->tx_buf;
int i, num_bytes;
u32 word, data;
for (; num_words; num_words--) {
word = 0;
- num_bytes = min_t(int, xfer->len - controller->tx_bytes,
- controller->w_size);
+ num_bytes = min_t(int, spi_qup_len(controller) -
+ controller->tx_bytes,
+ controller->w_size);
if (tx_buf)
for (i = 0; i < num_bytes; i++) {
data = tx_buf[controller->tx_bytes + i];
@@ -338,13 +345,12 @@ static void spi_qup_dma_done(void *data)
complete(&qup->done);
}
-static void spi_qup_write(struct spi_qup *controller,
- struct spi_transfer *xfer)
+static void spi_qup_write(struct spi_qup *controller)
{
bool is_block_mode = controller->mode == QUP_IO_M_MODE_BLOCK;
u32 remainder, words_per_block, num_words;
- remain
[PATCH v5 09/14] spi: qup: call io_config in mode specific function
DMA transactions should only only need to call io_config only once, but
block mode might call it several times to setup several transactions so
it can handle reads/writes larger than the max size per transaction, so
we move the call to the do_ functions.
This is just refactoring, there should be no functional change
Signed-off-by: Matthew McClintock
Signed-off-by: Varadarajan Narayanan
---
drivers/spi/spi-qup.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index 82593f6..b2bda47 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -156,6 +156,8 @@ struct spi_qup {
struct dma_slave_config tx_conf;
};
+static int spi_qup_io_config(struct spi_device *spi, struct spi_transfer
*xfer);
+
static inline bool spi_qup_is_flag_set(struct spi_qup *controller, u32 flag)
{
u32 opflag = readl_relaxed(controller->base + QUP_OPERATIONAL);
@@ -417,10 +419,12 @@ static void spi_qup_dma_terminate(struct spi_master
*master,
dmaengine_terminate_all(master->dma_rx);
}
-static int spi_qup_do_dma(struct spi_master *master, struct spi_transfer *xfer,
+static int spi_qup_do_dma(struct spi_device *spi, struct spi_transfer *xfer,
unsigned long timeout)
{
dma_async_tx_callback rx_done = NULL, tx_done = NULL;
+ struct spi_master *master = spi->master;
+ struct spi_qup *qup = spi_master_get_devdata(master);
int ret;
if (xfer->rx_buf)
@@ -428,6 +432,10 @@ static int spi_qup_do_dma(struct spi_master *master,
struct spi_transfer *xfer,
else if (xfer->tx_buf)
tx_done = spi_qup_dma_done;
+ ret = spi_qup_io_config(spi, xfer);
+ if (ret)
+ return ret;
+
/* before issuing the descriptors, set the QUP to run */
ret = spi_qup_set_state(qup, QUP_STATE_RUN);
if (ret) {
@@ -461,12 +469,17 @@ static int spi_qup_do_dma(struct spi_master *master,
struct spi_transfer *xfer,
return 0;
}
-static int spi_qup_do_pio(struct spi_master *master, struct spi_transfer *xfer,
+static int spi_qup_do_pio(struct spi_device *spi, struct spi_transfer *xfer,
unsigned long timeout)
{
+ struct spi_master *master = spi->master;
struct spi_qup *qup = spi_master_get_devdata(master);
int ret;
+ ret = spi_qup_io_config(spi, xfer);
+ if (ret)
+ return ret;
+
ret = spi_qup_set_state(qup, QUP_STATE_RUN);
if (ret) {
dev_warn(qup->dev, "cannot set RUN state\n");
@@ -744,10 +757,6 @@ static int spi_qup_transfer_one(struct spi_master *master,
if (ret)
return ret;
- ret = spi_qup_io_config(spi, xfer);
- if (ret)
- return ret;
-
timeout = DIV_ROUND_UP(xfer->speed_hz, MSEC_PER_SEC);
timeout = DIV_ROUND_UP(xfer->len * 8, timeout);
timeout = 100 * msecs_to_jiffies(timeout);
@@ -762,9 +771,9 @@ static int spi_qup_transfer_one(struct spi_master *master,
spin_unlock_irqrestore(&controller->lock, flags);
if (spi_qup_is_dma_xfer(controller->mode))
- ret = spi_qup_do_dma(master, xfer, timeout);
+ ret = spi_qup_do_dma(spi, xfer, timeout);
else
- ret = spi_qup_do_pio(master, xfer, timeout);
+ ret = spi_qup_do_pio(spi, xfer, timeout);
if (ret)
goto exit;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
[PATCH v5 13/14] spi: qup: Ensure done detection
This patch fixes an issue where a SPI transaction has completed, but the
done condition is missed. This occurs because at the time of interrupt the
MAX_INPUT_DONE_FLAG is not asserted. However, in the process of reading
blocks of data from the FIFO, the last portion of data comes in.
The opflags read at the beginning of the irq handler no longer matches the
current opflag state. To get around this condition, the block read
function should update the opflags so that done detection is correct after
the return.
Signed-off-by: Andy Gross
Signed-off-by: Abhishek Sahu
Signed-off-by: Varadarajan Narayanan
---
drivers/spi/spi-qup.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index 3c2c2c0..4c3c938 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -266,7 +266,7 @@ static void spi_qup_read_from_fifo(struct spi_qup
*controller, u32 num_words)
}
}
-static void spi_qup_read(struct spi_qup *controller)
+static void spi_qup_read(struct spi_qup *controller, u32 *opflags)
{
u32 remainder, words_per_block, num_words;
bool is_block_mode = controller->mode == QUP_IO_M_MODE_BLOCK;
@@ -305,10 +305,12 @@ static void spi_qup_read(struct spi_qup *controller)
/*
* Due to extra stickiness of the QUP_OP_IN_SERVICE_FLAG during block
-* mode reads, it has to be cleared again at the very end
+* reads, it has to be cleared again at the very end. However, be sure
+* to refresh opflags value because MAX_INPUT_DONE_FLAG may now be
+* present and this is used to determine if transaction is complete
*/
- if (is_block_mode && spi_qup_is_flag_set(controller,
- QUP_OP_MAX_INPUT_DONE_FLAG))
+ *opflags = readl_relaxed(controller->base + QUP_OPERATIONAL);
+ if (is_block_mode && *opflags & QUP_OP_MAX_INPUT_DONE_FLAG)
writel_relaxed(QUP_OP_IN_SERVICE_FLAG,
controller->base + QUP_OPERATIONAL);
@@ -613,7 +615,7 @@ static irqreturn_t spi_qup_qup_irq(int irq, void *dev_id)
writel_relaxed(opflags, controller->base + QUP_OPERATIONAL);
} else {
if (opflags & QUP_OP_IN_SERVICE_FLAG)
- spi_qup_read(controller);
+ spi_qup_read(controller, &opflags);
if (opflags & QUP_OP_OUT_SERVICE_FLAG)
spi_qup_write(controller);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 2/3] staging: pi433: - style fix, space before tabs
On Sat, Jul 22, 2017 at 10:48:24AM +0200, Marcus Wolf wrote: > Reviewed-by: Marcus Wolf > > >From my point of view, the rearrangement of the block of SET_CHECKED reduces > >the > readability a lot. I like same stuff to be aligned (all brakets below each > other > as a column, all spi->dev below each other and so on) But if it is necessary > to > fullfill the rules, we have to do it the new way. It's not necessary. The rule is just complaining about this: SET_CHECKED(rf69_set_bandwidth (dev->spi, rx_cfg->bw_mantisse, rx_cfg->bw_exponent)); ^ There is a space after the 'h' character. The old code has "[space][tab][tab][space](dev->spi,..." it should be: "[tab][tab][space](dev->spi, ..." Also the rules are there to improve readability. Sometimes they're debatable but if they make readability worse, then we can ignore the rules. regards, dan carpenter
[PATCH v5 14/14] spi: qup: Fix QUP version identify method
Use of_device_get_match_data to identify QUP version instead
of of_device_is_compatible.
Signed-off-by: Varadarajan Narayanan
---
drivers/spi/spi-qup.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index 4c3c938..1364516 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1058,9 +1059,7 @@ static int spi_qup_probe(struct platform_device *pdev)
else if (!ret)
master->can_dma = spi_qup_can_dma;
- /* set v1 flag if device is version 1 */
- if (of_device_is_compatible(dev->of_node, "qcom,spi-qup-v1.1.1"))
- controller->qup_v1 = 1;
+ controller->qup_v1 = (int)of_device_get_match_data(dev);
if (!controller->qup_v1)
master->set_cs = spi_qup_set_cs;
@@ -1256,7 +1255,7 @@ static int spi_qup_remove(struct platform_device *pdev)
}
static const struct of_device_id spi_qup_dt_match[] = {
- { .compatible = "qcom,spi-qup-v1.1.1", },
+ { .compatible = "qcom,spi-qup-v1.1.1", .data = (void *)1, },
{ .compatible = "qcom,spi-qup-v2.1.1", },
{ .compatible = "qcom,spi-qup-v2.2.1", },
{ }
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
[PATCH v5 12/14] spi: qup: allow multiple DMA transactions per spi xfer
Much like the block mode changes, we are breaking up DMA transactions
into 64K chunks so we can reset the QUP engine.
Signed-off-by: Matthew McClintock
Signed-off-by: Varadarajan Narayanan
---
drivers/spi/spi-qup.c | 93 +++
1 file changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index 3ac9b25..3c2c2c0 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -418,12 +418,35 @@ static void spi_qup_dma_terminate(struct spi_master
*master,
dmaengine_terminate_all(master->dma_rx);
}
+static u32 spi_qup_sgl_get_nents_len(struct scatterlist *sgl, u32 max,
+u32 *nents)
+{
+ struct scatterlist *sg;
+ u32 total = 0;
+
+ *nents = 0;
+
+ for (sg = sgl; sg; sg = sg_next(sg)) {
+ unsigned int len = sg_dma_len(sg);
+
+ /* check for overflow as well as limit */
+ if (((total + len) < total) || ((total + len) > max))
+ break;
+
+ total += len;
+ (*nents)++;
+ }
+
+ return total;
+}
+
static int spi_qup_do_dma(struct spi_device *spi, struct spi_transfer *xfer,
unsigned long timeout)
{
dma_async_tx_callback rx_done = NULL, tx_done = NULL;
struct spi_master *master = spi->master;
struct spi_qup *qup = spi_master_get_devdata(master);
+ struct scatterlist *tx_sgl, *rx_sgl;
int ret;
if (xfer->rx_buf)
@@ -431,43 +454,57 @@ static int spi_qup_do_dma(struct spi_device *spi, struct
spi_transfer *xfer,
else if (xfer->tx_buf)
tx_done = spi_qup_dma_done;
- ret = spi_qup_io_config(spi, xfer);
- if (ret)
- return ret;
+ rx_sgl = xfer->rx_sg.sgl;
+ tx_sgl = xfer->tx_sg.sgl;
- /* before issuing the descriptors, set the QUP to run */
- ret = spi_qup_set_state(qup, QUP_STATE_RUN);
- if (ret) {
- dev_warn(qup->dev, "%s(%d): cannot set RUN state\n",
- __func__, __LINE__);
- return ret;
- }
+ do {
+ u32 rx_nents, tx_nents;
+
+ if (rx_sgl)
+ qup->n_words = spi_qup_sgl_get_nents_len(rx_sgl,
+ SPI_MAX_XFER, &rx_nents) / qup->w_size;
+ if (tx_sgl)
+ qup->n_words = spi_qup_sgl_get_nents_len(tx_sgl,
+ SPI_MAX_XFER, &tx_nents) / qup->w_size;
+ if (!qup->n_words)
+ return -EIO;
- if (xfer->rx_buf) {
- ret = spi_qup_prep_sg(master, xfer->rx_sg.sgl,
- xfer->rx_sg.nents, DMA_DEV_TO_MEM,
- rx_done);
+ ret = spi_qup_io_config(spi, xfer);
if (ret)
return ret;
- dma_async_issue_pending(master->dma_rx);
- }
-
- if (xfer->tx_buf) {
- ret = spi_qup_prep_sg(master, xfer->tx_sg.sgl,
- xfer->tx_sg.nents, DMA_MEM_TO_DEV,
- tx_done);
- if (ret)
+ /* before issuing the descriptors, set the QUP to run */
+ ret = spi_qup_set_state(qup, QUP_STATE_RUN);
+ if (ret) {
+ dev_warn(qup->dev, "cannot set RUN state\n");
return ret;
+ }
+ if (rx_sgl) {
+ ret = spi_qup_prep_sg(master, rx_sgl, rx_nents,
+ DMA_DEV_TO_MEM, rx_done);
+ if (ret)
+ return ret;
+ dma_async_issue_pending(master->dma_rx);
+ }
- dma_async_issue_pending(master->dma_tx);
- }
+ if (tx_sgl) {
+ ret = spi_qup_prep_sg(master, tx_sgl, tx_nents,
+ DMA_MEM_TO_DEV, tx_done);
+ if (ret)
+ return ret;
+
+ dma_async_issue_pending(master->dma_tx);
+ }
+
+ if (!wait_for_completion_timeout(&qup->done, timeout))
+ return -ETIMEDOUT;
- if (rx_done && !wait_for_completion_timeout(&qup->done, timeout))
- return -ETIMEDOUT;
+ for (; rx_sgl && rx_nents--; rx_sgl = sg_next(rx_sgl))
+ ;
+ for (; tx_sgl && tx_nents--; tx_sgl = sg_next(tx_sgl))
+ ;
- if (tx_done && !wait_for_completion_timeout(&qup->done, timeout))
- return -ETIMEDOUT;
+ } while (rx_sgl || tx_sgl);
return 0;
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation C
[PATCH v5 07/14] spi: qup: Do block sized read/write in block mode
This patch corrects the behavior of the BLOCK
transactions. During block transactions, the controller
must be read/written to in block size transactions.
Signed-off-by: Andy Gross
Signed-off-by: Varadarajan Narayanan
---
drivers/spi/spi-qup.c | 151 +++---
1 file changed, 119 insertions(+), 32 deletions(-)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index 5e6f7e5..d819f87 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -82,6 +82,8 @@
#define QUP_IO_M_MODE_BAM 3
/* QUP_OPERATIONAL fields */
+#define QUP_OP_IN_BLOCK_READ_REQ BIT(13)
+#define QUP_OP_OUT_BLOCK_WRITE_REQ BIT(12)
#define QUP_OP_MAX_INPUT_DONE_FLAG BIT(11)
#define QUP_OP_MAX_OUTPUT_DONE_FLAGBIT(10)
#define QUP_OP_IN_SERVICE_FLAG BIT(9)
@@ -154,6 +156,13 @@ struct spi_qup {
struct dma_slave_config tx_conf;
};
+static inline bool spi_qup_is_flag_set(struct spi_qup *controller, u32 flag)
+{
+ u32 opflag = readl_relaxed(controller->base + QUP_OPERATIONAL);
+
+ return (opflag & flag) != 0;
+}
+
static inline bool spi_qup_is_dma_xfer(int mode)
{
if (mode == QUP_IO_M_MODE_DMOV || mode == QUP_IO_M_MODE_BAM)
@@ -214,29 +223,26 @@ static int spi_qup_set_state(struct spi_qup *controller,
u32 state)
return 0;
}
-static void spi_qup_fifo_read(struct spi_qup *controller,
- struct spi_transfer *xfer)
+static void spi_qup_read_from_fifo(struct spi_qup *controller,
+ struct spi_transfer *xfer, u32 num_words)
{
u8 *rx_buf = xfer->rx_buf;
- u32 word, state;
- int idx, shift, w_size;
+ int i, shift, num_bytes;
+ u32 word;
- w_size = controller->w_size;
-
- while (controller->rx_bytes < xfer->len) {
-
- state = readl_relaxed(controller->base + QUP_OPERATIONAL);
- if (0 == (state & QUP_OP_IN_FIFO_NOT_EMPTY))
- break;
+ for (; num_words; num_words--) {
word = readl_relaxed(controller->base + QUP_INPUT_FIFO);
+ num_bytes = min_t(int, xfer->len - controller->rx_bytes,
+ controller->w_size);
+
if (!rx_buf) {
- controller->rx_bytes += w_size;
+ controller->rx_bytes += num_bytes;
continue;
}
- for (idx = 0; idx < w_size; idx++, controller->rx_bytes++) {
+ for (i = 0; i < num_bytes; i++, controller->rx_bytes++) {
/*
* The data format depends on bytes per SPI word:
* 4 bytes: 0x12345678
@@ -244,38 +250,80 @@ static void spi_qup_fifo_read(struct spi_qup *controller,
* 1 byte : 0x0012
*/
shift = BITS_PER_BYTE;
- shift *= (w_size - idx - 1);
+ shift *= (controller->w_size - i - 1);
rx_buf[controller->rx_bytes] = word >> shift;
}
}
}
-static void spi_qup_fifo_write(struct spi_qup *controller,
+static void spi_qup_read(struct spi_qup *controller,
struct spi_transfer *xfer)
{
- const u8 *tx_buf = xfer->tx_buf;
- u32 word, state, data;
- int idx, w_size;
+ u32 remainder, words_per_block, num_words;
+ bool is_block_mode = controller->mode == QUP_IO_M_MODE_BLOCK;
+
+ remainder = DIV_ROUND_UP(xfer->len - controller->rx_bytes,
+controller->w_size);
+ words_per_block = controller->in_blk_sz >> 2;
+
+ do {
+ /* ACK by clearing service flag */
+ writel_relaxed(QUP_OP_IN_SERVICE_FLAG,
+ controller->base + QUP_OPERATIONAL);
+
+ if (is_block_mode) {
+ num_words = (remainder > words_per_block) ?
+ words_per_block : remainder;
+ } else {
+ if (!spi_qup_is_flag_set(controller,
+QUP_OP_IN_FIFO_NOT_EMPTY))
+ break;
- w_size = controller->w_size;
+ num_words = 1;
+ }
- while (controller->tx_bytes < xfer->len) {
+ /* read up to the maximum transfer size available */
+ spi_qup_read_from_fifo(controller, xfer, num_words);
- state = readl_relaxed(controller->base + QUP_OPERATIONAL);
- if (state & QUP_OP_OUT_FIFO_FULL)
+ remainder -= num_words;
+
+ /* if block mode, check to see if next block is available */
+ if (is_block_mode && !spi_qup_is_flag_set(controller,
+ QUP_OP_IN_BLOCK_READ_REQ))
break;
[PATCH v5 11/14] spi: qup: refactor spi_qup_prep_sg
Take specific sgl and nent to be prepared. This is in
preparation for splitting DMA into multiple transacations, this
contains no code changes just refactoring.
Signed-off-by: Matthew McClintock
Signed-off-by: Varadarajan Narayanan
---
drivers/spi/spi-qup.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index 67e7463..3ac9b25 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -382,27 +382,20 @@ static void spi_qup_write(struct spi_qup *controller)
} while (remainder);
}
-static int spi_qup_prep_sg(struct spi_master *master, struct spi_transfer
*xfer,
- enum dma_transfer_direction dir,
+static int spi_qup_prep_sg(struct spi_master *master, struct scatterlist *sgl,
+ unsigned int nents, enum dma_transfer_direction dir,
dma_async_tx_callback callback)
{
struct spi_qup *qup = spi_master_get_devdata(master);
unsigned long flags = DMA_PREP_INTERRUPT | DMA_PREP_FENCE;
struct dma_async_tx_descriptor *desc;
- struct scatterlist *sgl;
struct dma_chan *chan;
dma_cookie_t cookie;
- unsigned int nents;
- if (dir == DMA_MEM_TO_DEV) {
+ if (dir == DMA_MEM_TO_DEV)
chan = master->dma_tx;
- nents = xfer->tx_sg.nents;
- sgl = xfer->tx_sg.sgl;
- } else {
+ else
chan = master->dma_rx;
- nents = xfer->rx_sg.nents;
- sgl = xfer->rx_sg.sgl;
- }
desc = dmaengine_prep_slave_sg(chan, sgl, nents, dir, flags);
if (IS_ERR_OR_NULL(desc))
@@ -451,7 +444,9 @@ static int spi_qup_do_dma(struct spi_device *spi, struct
spi_transfer *xfer,
}
if (xfer->rx_buf) {
- ret = spi_qup_prep_sg(master, xfer, DMA_DEV_TO_MEM, rx_done);
+ ret = spi_qup_prep_sg(master, xfer->rx_sg.sgl,
+ xfer->rx_sg.nents, DMA_DEV_TO_MEM,
+ rx_done);
if (ret)
return ret;
@@ -459,7 +454,9 @@ static int spi_qup_do_dma(struct spi_device *spi, struct
spi_transfer *xfer,
}
if (xfer->tx_buf) {
- ret = spi_qup_prep_sg(master, xfer, DMA_MEM_TO_DEV, tx_done);
+ ret = spi_qup_prep_sg(master, xfer->tx_sg.sgl,
+ xfer->tx_sg.nents, DMA_MEM_TO_DEV,
+ tx_done);
if (ret)
return ret;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
[PATCH v5 06/14] spi: qup: Fix transaction done signaling
Wait to signal done until we get all of the interrupts we are expecting
to get for a transaction. If we don't wait for the input done flag, we
can be in between transactions when the done flag comes in and this can
mess up the next transaction.
While here cleaning up the code which sets controller->xfer = NULL and
restores it in the ISR. This looks to be some debug code which is not
required.
Signed-off-by: Andy Gross
Signed-off-by: Varadarajan Narayanan
---
drivers/spi/spi-qup.c | 27 +--
1 file changed, 5 insertions(+), 22 deletions(-)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index aa1b7b8..5e6f7e5 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -411,29 +411,16 @@ static int spi_qup_do_pio(struct spi_master *master,
struct spi_transfer *xfer,
static irqreturn_t spi_qup_qup_irq(int irq, void *dev_id)
{
struct spi_qup *controller = dev_id;
- struct spi_transfer *xfer;
+ struct spi_transfer *xfer = controller->xfer;
u32 opflags, qup_err, spi_err;
- unsigned long flags;
int error = 0;
- spin_lock_irqsave(&controller->lock, flags);
- xfer = controller->xfer;
- controller->xfer = NULL;
- spin_unlock_irqrestore(&controller->lock, flags);
-
qup_err = readl_relaxed(controller->base + QUP_ERROR_FLAGS);
spi_err = readl_relaxed(controller->base + SPI_ERROR_FLAGS);
opflags = readl_relaxed(controller->base + QUP_OPERATIONAL);
writel_relaxed(qup_err, controller->base + QUP_ERROR_FLAGS);
writel_relaxed(spi_err, controller->base + SPI_ERROR_FLAGS);
- writel_relaxed(opflags, controller->base + QUP_OPERATIONAL);
-
- if (!xfer) {
- dev_err_ratelimited(controller->dev, "unexpected irq %08x %08x
%08x\n",
- qup_err, spi_err, opflags);
- return IRQ_HANDLED;
- }
if (qup_err) {
if (qup_err & QUP_ERROR_OUTPUT_OVER_RUN)
@@ -457,7 +444,9 @@ static irqreturn_t spi_qup_qup_irq(int irq, void *dev_id)
error = -EIO;
}
- if (!spi_qup_is_dma_xfer(controller->mode)) {
+ if (spi_qup_is_dma_xfer(controller->mode)) {
+ writel_relaxed(opflags, controller->base + QUP_OPERATIONAL);
+ } else {
if (opflags & QUP_OP_IN_SERVICE_FLAG)
spi_qup_fifo_read(controller, xfer);
@@ -465,12 +454,7 @@ static irqreturn_t spi_qup_qup_irq(int irq, void *dev_id)
spi_qup_fifo_write(controller, xfer);
}
- spin_lock_irqsave(&controller->lock, flags);
- controller->error = error;
- controller->xfer = xfer;
- spin_unlock_irqrestore(&controller->lock, flags);
-
- if (controller->rx_bytes == xfer->len || error)
+ if ((opflags & QUP_OP_MAX_INPUT_DONE_FLAG) || error)
complete(&controller->done);
return IRQ_HANDLED;
@@ -668,7 +652,6 @@ static int spi_qup_transfer_one(struct spi_master *master,
exit:
spi_qup_set_state(controller, QUP_STATE_RESET);
spin_lock_irqsave(&controller->lock, flags);
- controller->xfer = NULL;
if (!ret)
ret = controller->error;
spin_unlock_irqrestore(&controller->lock, flags);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
[PATCH v5 04/14] spi: qup: Place the QUP in run mode before DMA
Signed-off-by: Andy Gross
Signed-off-by: Varadarajan Narayanan
---
drivers/spi/spi-qup.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index 92922b6..e6294f8 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -342,6 +342,14 @@ static int spi_qup_do_dma(struct spi_master *master,
struct spi_transfer *xfer,
else if (xfer->tx_buf)
tx_done = spi_qup_dma_done;
+ /* before issuing the descriptors, set the QUP to run */
+ ret = spi_qup_set_state(qup, QUP_STATE_RUN);
+ if (ret) {
+ dev_warn(qup->dev, "%s(%d): cannot set RUN state\n",
+ __func__, __LINE__);
+ return ret;
+ }
+
if (xfer->rx_buf) {
ret = spi_qup_prep_sg(master, xfer, DMA_DEV_TO_MEM, rx_done);
if (ret)
@@ -387,6 +395,13 @@ static int spi_qup_do_pio(struct spi_master *master,
struct spi_transfer *xfer,
spi_qup_fifo_write(qup, xfer);
+ ret = spi_qup_set_state(qup, QUP_STATE_RUN);
+ if (ret) {
+ dev_warn(qup->dev, "%s(%d): cannot set RUN state\n",
+ __func__, __LINE__);
+ return ret;
+ }
+
if (!wait_for_completion_timeout(&qup->done, timeout))
return -ETIMEDOUT;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 3/3] staging: pi433: - style fix, space at start of line
On Sat, Jul 22, 2017 at 03:51:21PM +1200, Derek Robson wrote: > Fixed checkpatch errors of "please, no spaces at the start of a line" > > Signed-off-by: Derek Robson > --- > drivers/staging/pi433/rf69.c | 4 +- > drivers/staging/pi433/rf69_enum.h | 206 > +++--- > 2 files changed, 105 insertions(+), 105 deletions(-) > > diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c > index d931437f0b6a..f450bbf3fbbc 100644 > --- a/drivers/staging/pi433/rf69.c > +++ b/drivers/staging/pi433/rf69.c > @@ -440,8 +440,8 @@ int rf69_set_bandwidth_intern(struct spi_device *spi, u8 > reg, enum mantisse mant > // check value for mantisse and exponent > if (exponent > 7) INVALID_PARAM; > if ( (mantisse!=mantisse16) && > - (mantisse!=mantisse20) && > - (mantisse!=mantisse24) ) INVALID_PARAM; > + (mantisse!=mantisse20) && > + (mantisse!=mantisse24) ) INVALID_PARAM; > This is wrong. It should be aligned like this: if (exponent > 7) INVALID_PARAM; if (mantisse != mantisse16 && mantisse != mantisse20 && mantisse != mantisse24) INVALID_PARAM; regards, dan carpenter
Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization
Hi Peter,
I put this change in a local tree together with other fixes / cleanups
I plan to submit in the next weeks. Should I send it together with the
other patches, or are you going to apply it separately?
In the first case, what is the correct authorship / SOB chain (I ask
because I keep getting this wrong every time :)
Thanks,
Luca
On Fri, 24 Mar 2017 14:23:51 +0100
Peter Zijlstra wrote:
> On Fri, Mar 24, 2017 at 04:52:55AM +0100, luca abeni wrote:
> > @@ -2518,6 +2520,7 @@ static int dl_overflow(struct task_struct *p, int
> > policy,
> >!__dl_overflow(dl_b, cpus, p->dl.dl_bw, new_bw)) {
> > __dl_clear(dl_b, p->dl.dl_bw);
> > __dl_add(dl_b, new_bw);
> > + dl_change_utilization(p, new_bw);
> > err = 0;
>
> Every time I see that I want to do this..
>
>
> ---
> kernel/sched/core.c | 4 ++--
> kernel/sched/deadline.c | 2 +-
> kernel/sched/sched.h| 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 3b31fc05a0f1..b845ee4b3e55 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2512,11 +2512,11 @@ static int dl_overflow(struct task_struct *p, int
> policy,
> err = 0;
> } else if (dl_policy(policy) && task_has_dl_policy(p) &&
> !__dl_overflow(dl_b, cpus, p->dl.dl_bw, new_bw)) {
> - __dl_clear(dl_b, p->dl.dl_bw);
> + __dl_sub(dl_b, p->dl.dl_bw);
> __dl_add(dl_b, new_bw);
> err = 0;
> } else if (!dl_policy(policy) && task_has_dl_policy(p)) {
> - __dl_clear(dl_b, p->dl.dl_bw);
> + __dl_sub(dl_b, p->dl.dl_bw);
> err = 0;
> }
> raw_spin_unlock(&dl_b->lock);
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index a2ce59015642..229660088138 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -1695,7 +1695,7 @@ static void set_cpus_allowed_dl(struct task_struct *p,
>* until we complete the update.
>*/
> raw_spin_lock(&src_dl_b->lock);
> - __dl_clear(src_dl_b, p->dl.dl_bw);
> + __dl_sub(src_dl_b, p->dl.dl_bw);
> raw_spin_unlock(&src_dl_b->lock);
> }
>
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 5cbf92214ad8..1a521324ecee 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -226,7 +226,7 @@ struct dl_bw {
> };
>
> static inline
> -void __dl_clear(struct dl_bw *dl_b, u64 tsk_bw)
> +void __dl_sub(struct dl_bw *dl_b, u64 tsk_bw)
> {
> dl_b->total_bw -= tsk_bw;
> }
Re: [PATCH 2/3] dt-bindings: iio: adc: stm32: add optional min-sample-time
On 07/23/2017 12:53 PM, Jonathan Cameron wrote:
> On Tue, 18 Jul 2017 14:35:31 +0200
> Fabrice Gasnier wrote:
>
>> STM32 ADC allows each channel to be sampled with a different sampling
>> time. There's an application note that deals with this: 'How to get
>> the best ADC accuracy in STM32...' It basically depends on analog input
>> signal electrical properties (depends on board).
>>
>> Add optional 'min-sample-time' property so this can be tuned in dt.
>>
>> Signed-off-by: Fabrice Gasnier
>
> This isn't yet very standard, so I think it needs a manufacturer
> prefix, e.g. st,min-sample-time. Also convention is I believe
> to include the units as part of the naming where appropriate.
>
> Hence st,min-sample-time-nsecs
Hi Jonathan,
I originally used st,... form, when writing this patch, until I found
out there's 'min-sample-time' in vf610 adc dt-bindings:
- Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
It looks like to me very similar.
I also agree it misses '-nsecs' units. Sure, I can use your suggestion
above...
Please can you just confirm if I should use same property as vf610 adc,
or 'st,min-sample-time-nsecs' ?
Thanks for reviewing,
Best regards,
Fabrice
>
> Otherwise, seems good to me.
>
> Jonathan
>> ---
>> Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
>> b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
>> index 8310073..9cd964b 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
>> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
>> @@ -74,6 +74,11 @@ Optional properties:
>>* can be 6, 8, 10 or 12 on stm32f4
>>* can be 8, 10, 12, 14 or 16 on stm32h7
>>Default is maximum resolution if unset.
>> +- min-sample-time: Minimum sampling time in nanoseconds.
>> + Depending on hardware (board) e.g. high/low analog input source impedance,
>> + fine tune of ADC sampling time may be recommended.
>> + This can be either one value or an array that matches 'st,adc-channels'
>> list,
>> + to set sample time resp. for all channels, or independently for each
>> channel.
>>
>> Example:
>> adc: adc@40012000 {
>
Re: [PATCH] [RESEND] nfs: blocklayout: avoid warnings on 32-bit sector_t
A 32-bit will also cause run-time problems. I think the block layout code should instead grow a depends on 64BIT || LBDAF to ensure we always have a 64-bit sector_t.
Re: [PATCH 0/3] Add ethernet0 alias for several A64 boards
On Sat, Jul 22, 2017 at 10:28:49AM +0800, Icenowy Zheng wrote: > Allwinner A64 SoC has an EMAC which is used to provide Ethernet > function on several boards. > > The EMAC itself doesn't have a fixed MAC address, but the sunxi > mainline U-Boot have the ability to generate one based on the eFUSE > SID in the chip, and add the generated MAC address to the device > tree when booting. > > The MAC address setting step is based on the device tree's aliases, > and device tree nodes prefixed "ethernet" will get the MAC address > added. However, in several A64 boards' device tree, the alias is not > set up, so that the U-Boot won't set the MAC address. > > Add the ethernet0 aliases to these boards. > > I hope this patchset can be queued in 4.13, otherwise 4.13 kernels > won't get non-volatile MAC addresses, and will use random ones > instead, which is annoying to many users. > > Icenowy Zheng (3): > arm64: allwinner: a64: add ethernet0 alias for BPi M64 EMAC node > arm64: allwinner: a64: add ethernet0 alias for Pine64 EMAC node > arm64: allwinner: a64: add ethernet0 alias for SoPine EMAC node Applied all three, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v2 0/2] AXP803 regulators support for Pine64 and SoPine
On Sat, Jul 22, 2017 at 10:18:41AM +0800, Icenowy Zheng wrote: > The Pine64 and SoPine w/ baseboard boards have an AXP803 PMIC, and the > regulators of the PMIC are used. > > This patchset adds the regulators to the device tree of these two boards. > > The first patch is for Pine64 and the second if for SoPine w/ official > baseboard. Applied the two. > The patches that drop the dummy regulators in v1 are removed. Please resend that one. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 1/3] staging: pi433: Style fix - align block comments
Hi Dan, when I started with the RFM69CW about two years ago (at the beginning not as a driver, but everything within the applicaton) I kind of automatically produced a list of all registers of the chip (most probably by importing and reorganizing the datasheet in Excel). Everytime I need to touch a register, I started to crosscheck the names and masks and took them out of comment. All registers, I did not touch the last two years are from this autogeneration and commented. There is stil a lot of functionality of the chip, that's not supported (or not needed) by the driver. Cheers, Marcus > Dan Carpenter hat am 24. Juli 2017 um 09:41 > geschrieben: > > > On Sat, Jul 22, 2017 at 03:50:50PM +1200, Derek Robson wrote: > > + * // RegOsc1 > > + * #define OSC1_RCCAL_START 0x80 > > + * #define OSC1_RCCAL_DONE 0x40 > > + * > > Why do we have all these commented out defines? > > regards, > dan carpenter > >
Re: [PATCH] [RESEND] gpu: ipu-v3: add DRM dependency
Hi Arnd,
On Fri, 2017-07-21 at 22:56 +0200, Arnd Bergmann wrote:
> The new PRE/PRG driver code causes a link failure when DRM is disabled:
>
> drivers/gpu/ipu-v3/ipu-pre.o: In function `ipu_pre_configure':
> ipu-pre.c:(.text.ipu_pre_configure+0x18): undefined reference to
> `drm_format_info'
> drivers/gpu/ipu-v3/ipu-prg.o: In function `ipu_prg_format_supported':
> ipu-prg.c:(.text.ipu_prg_format_supported+0x8): undefined reference to
> `drm_format_info'
>
> Adding a Kconfig dependency on DRM means we don't run into this problem
> any more. This might not be the best solution though, as the ipu seems
> to have been intentionally kept separate from DRM in the past.
>
> Fixes: ea9c260514c1 ("gpu: ipu-v3: add driver for Prefetch Resolve Gasket")
> Link: https://patchwork.kernel.org/patch/9636665/
> Signed-off-by: Arnd Bergmann
> ---
> Originally sent on March 21, but got no reply for it. Resending unchanged
> as it is still needed in v4.13-rc1
thank you for fix and for the resend. I have the original patch in my
inbox, I'm sorry I overlooked it.
I would still like to keep the ipu-v3 driver buildable without DRM
enabled. For now, I have applied your patch as is.
regards
Philipp
Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization
Hi Peter,
On Fri, 24 Mar 2017 22:47:15 +0100
luca abeni wrote:
> Hi Peter,
>
> On Fri, 24 Mar 2017 14:20:41 +0100
> Peter Zijlstra wrote:
>
> > On Fri, Mar 24, 2017 at 04:52:55AM +0100, luca abeni wrote:
> >
> > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > index d67eee8..952cac8 100644
> > > --- a/include/linux/sched.h
> > > +++ b/include/linux/sched.h
> > > @@ -445,16 +445,33 @@ struct sched_dl_entity {
> > >*
> > >* @dl_yielded tells if task gave up the CPU before
> > > consuming
> > >* all its available runtime during the last job.
> > > + *
> > > + * @dl_non_contending tells if task is inactive while still
> > > + * contributing to the active utilization. In other words,
> > > it
> > > + * indicates if the inactive timer has been armed and its
> > > handler
> > > + * has not been executed yet. This flag is useful to avoid
> > > race
> > > + * conditions between the inactive timer handler and the
> > > wakeup
> > > + * code.
> > >*/
> > > int dl_throttled;
> > > int dl_boosted;
> > > int dl_yielded;
> > > + int dl_non_contending;
> >
> > We should maybe look into making those bits :1, not something for this
> > patch though;
>
> Yes, grouping all the flags in a single field was my intention too... I
> planned to submit a patch to do this after merging the reclaiming
> patches... But maybe it is better to do this first :)
I implemented this change, but before submitting the patch I have a
small question.
I implemented some helpers to access the various
{throttled,boosted,yielded,non_contending} flags. I have some
"dl_{throttled,boosted,...}()" inline functions for reading the values
of the flags, and some inline functions for setting / clearing the
flags. For these, I have two possibilities:
- using two separate "dl_set_{throttled,...}()" and
"dl_clear_{throttled,..}()" functions for each flag
- using one single "dl_set_{throttled,...}(dl, value)" function per
flag, in which the flag's value is specified.
I have no preferences (with the first proposal, I introduce more inline
functions, but I think the functions can be made more efficient /
optimized). Which one of the two proposals is preferred? (or, there is
a third, better, idea that I overlooked?)
Thanks,
Luca
>
>
> > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > > index cef9adb..86aed82 100644
> > > --- a/kernel/sched/deadline.c
> > > +++ b/kernel/sched/deadline.c
> > > @@ -65,6 +65,107 @@ void sub_running_bw(u64 dl_bw, struct dl_rq
> > > *dl_rq) dl_rq->running_bw = 0;
> > > }
> > >
> > > +void dl_change_utilization(struct task_struct *p, u64 new_bw)
> > > +{
> > > + if (!task_on_rq_queued(p)) {
> > > + struct rq *rq = task_rq(p);
> > > +
> > > + if (p->dl.dl_non_contending) {
> > > + sub_running_bw(p->dl.dl_bw, &rq->dl);
> > > + p->dl.dl_non_contending = 0;
> > > + /*
> > > + * If the timer handler is currently
> > > running and the
> > > + * timer cannot be cancelled,
> > > inactive_task_timer()
> > > + * will see that dl_not_contending is not
> > > set, and
> > > + * will not touch the rq's active
> > > utilization,
> > > + * so we are still safe.
> > > + */
> > > + if
> > > (hrtimer_try_to_cancel(&p->dl.inactive_timer) == 1)
> > > + put_task_struct(p);
> > > + }
> > > + }
> > > +}
> >
> > If we rearrange that slightly we can avoid the double indent:
> [...]
> Ok; I'll rework the code in this way on Monday.
>
> [...]
> > > + if (hrtimer_try_to_cancel(&dl_se->inactive_timer)
> > > == 1)
> > > + put_task_struct(dl_task_of(dl_se));
> > > + dl_se->dl_non_contending = 0;
> >
> > This had me worried for a little while as being a use-after-free, but
> > this put_task_struct() cannot be the last in this case. Might be
> > worth a comment.
>
> Or maybe it is better to move "dl_se->dl_non_contending = 0;" before
> hrtimer_try_to_cancel()?
>
> >
> > > + } else {
> > > + /*
> > > + * Since "dl_non_contending" is not set, the
> > > + * task's utilization has already been removed from
> > > + * active utilization (either when the task
> > > blocked,
> > > + * when the "inactive timer" fired).
> > > + * So, add it back.
> > > + */
> > > + add_running_bw(dl_se->dl_bw, dl_rq);
> > > + }
> > > +}
> >
> > In general I feel it would be nice to have a state diagram included
> > somewhere near these two functions. It would be nice to not have to
> > dig out the PDF every time.
>
> Ok... Since I am not good at ascii art, would it be ok to add a textual
> descripti
Re: [PATCH 1/2] mmc/host: add FSP2(ppc476fpe) into depends for sdhci-st
On 23/06/17 18:47, Ivan Mikhaylov wrote: > * shdci-st driver can be used for ppc476 fsp2 soc shdci-st -> sdhci-st > > Signed-off-by: Ivan Mikhaylov Acked-by: Adrian Hunter > --- > drivers/mmc/host/Kconfig |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > index 2eb9701..e6c0d86 100644 > --- a/drivers/mmc/host/Kconfig > +++ b/drivers/mmc/host/Kconfig > @@ -354,8 +354,8 @@ config MMC_MOXART > > config MMC_SDHCI_ST > tristate "SDHCI support on STMicroelectronics SoC" > - depends on ARCH_STI > depends on MMC_SDHCI_PLTFM > + depends on ARCH_STI || FSP2 > select MMC_SDHCI_IO_ACCESSORS > help > This selects the Secure Digital Host Controller Interface in >
Re: [PATCH] staging: vboxvideo: Kconfig: Fix typos in help text
On Mon, Jul 24, 2017 at 08:45:16AM +0200, Martin Kepplinger wrote: > This fixes typos in vboxvideo's help text. > > Signed-off-by: Martin Kepplinger > --- > drivers/staging/vboxvideo/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/vboxvideo/Kconfig > b/drivers/staging/vboxvideo/Kconfig > index a52746f9a670..2b058d573cf1 100644 > --- a/drivers/staging/vboxvideo/Kconfig > +++ b/drivers/staging/vboxvideo/Kconfig > @@ -6,7 +6,7 @@ config DRM_VBOXVIDEO > This is a KMS driver for the virtual Graphics Card used in > Virtual Box virtual machines. > > - Although it is possible to builtin this module, it is advised > + Although it is possible to build in this module, it is advised I feel like this is unclear. Perhaps say something like: Although it is possible to build this driver built-in to the kernel, it is advised ... regards, dan carpenter
ammin
ATTENZIONE; La cassetta postale ha superato il limite di archiviazione, che è 5 GB come definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra casella di posta, inviare le seguenti informazioni qui di seguito: nome: Nome utente: Password: Conferma Password: E-mail: telefono: Se non si riesce a rinnovare la vostra casella di posta, la vostra caselladi posta sarà disabilitato! Ci dispiace per l'inconvenienza. Codice di verifica: en:0085362LK.ft6789000.2017 Mail Technical Support ©2017 grazie Sistemi amministratore
Re: [PATCH v2] ovl: drop CAP_SYS_RESOURCE from saved mounter's credentials
On Sat, Jul 22, 2017 at 11:30 AM, Amir Goldstein wrote:
> Bumped into this patch (Now upstream commit 51f8f3c4e225) and realized
> it is missing cc: stable # v4.8
>
> At least this docker PR suggests that regression introduced in v4.8 will not
> be
> appreciated down the road:
> https://github.com/moby/moby/issues/29364
Greg,
Can you please queue 51f8f3c4e225 ("ovl: drop CAP_SYS_RESOURCE from
saved mounter's credentials") for 4.9.y?
Thanks,
Miklos
>
>
> On Tue, Jan 10, 2017 at 9:17 PM, Vivek Goyal wrote:
>> On Tue, Jan 10, 2017 at 09:30:21PM +0300, Konstantin Khlebnikov wrote:
>>> If overlay was mounted by root then quota set for upper layer does not work
>>> because overlay now always use mounter's credentials for operations.
>>> Also overlay might deplete reserved space and inodes in ext4.
>>>
>>> This patch drops capability SYS_RESOURCE from saved credentials.
>>> This affects creation new files, whiteouts, and copy-up operations.
>>>
>>
>> I am not an expert in this area, but I thought previous patch was
>> better. I am not sure why overlay internal operations should be
>> done without CAP_SYS_RESOURCES when caller has CAP_SYS_RESOURCES. That
>> might be counter-intuitive.
>>
>> If some task is allowed to bypass quota limitations on a file system
>> then same should be true when task is working on overlay.
>>
>> Similary if a task is allowed to use reserved space on filesystem, then same
>> task should be allowed to use reserved space on underlying filesystem
>> when doing overlay. It should not be overlay's job to prevent that?
>>
>> May be it is just me
>>
>
> Vivek,
>
> Since your question was not answered in this thread, IMO, your concern
> is just, but in practice I think that:
> 1. It's going to be harder to implement for every operation to combine the
> mounter's creds with the process capabilities... weird
> 2. The use case of ext4 reserved blocks is to allow sys admin some slack
> for disk allocations that are needed in order to free up disk space or for
> other critical tasks to prevent the system from hanging. It doesn't sound
> like this use case fits an overlayfs mount that well.
> 3. FYI, xfs project quota (which as you know can be applied to docker
> overlayfs container) does not check CAP_SYS_RESOURCES at all.
> and if and when ext4 project quotas can also be applied to docker
> overlayfs container, I am sure that containers admin will not appreciate
> a container exceeding its quota, even if that was a privileged process
> writing to that container
>
> So IMO that fix as it is is good for all practical purpose.
>
> Cheers,
> Amir.
>
>>
>>
>>> Signed-off-by: Konstantin Khlebnikov
>>> Fixes: 1175b6b8d963 ("ovl: do operations on underlying file system in
>>> mounter's context")
>>> Cc: Vivek Goyal
>>> Cc: Miklos Szeredi
>>> ---
>>> fs/overlayfs/super.c |9 +++--
>>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>>> index 20f48abbb82f..8dba982e1af5 100644
>>> --- a/fs/overlayfs/super.c
>>> +++ b/fs/overlayfs/super.c
>>> @@ -701,6 +701,7 @@ static int ovl_fill_super(struct super_block *sb, void
>>> *data, int silent)
>>> unsigned int stacklen = 0;
>>> unsigned int i;
>>> bool remote = false;
>>> + struct cred *cred;
>>> int err;
>>>
>>> err = -ENOMEM;
>>> @@ -870,10 +871,14 @@ static int ovl_fill_super(struct super_block *sb,
>>> void *data, int silent)
>>> else
>>> sb->s_d_op = &ovl_dentry_operations;
>>>
>>> - ufs->creator_cred = prepare_creds();
>>> - if (!ufs->creator_cred)
>>> + cred = prepare_creds();
>>> + if (!cred)
>>> goto out_put_lower_mnt;
>>>
>>> + /* Never override disk quota limits or use reserved space */
>>> + cap_lower(cred->cap_effective, CAP_SYS_RESOURCE);
>>> + ufs->creator_cred = cred;
>>> +
>>> err = -ENOMEM;
>>> oe = ovl_alloc_entry(numlower);
>>> if (!oe)
Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume
On Jul 22 2017 or thereabouts, Lyude wrote:
> So it looks like that suspend/resume has actually always been broken on
> hid-rmi. The fact it worked was a rather silly coincidence that was
> relying on the HID device to already be opened upon resume. This means
> that so long as anything was reading the /dev/input/eventX node for for
> an RMI device, it would suspend and resume correctly. As well, if
> nothing happened to be keeping the HID device away it would shut off,
> then the RMI driver would get confused on resume when it stopped
> responding and explode.
Oh, good finding. However, given that there are few other drivers not
calling hid_hw_open during their .reset_resume() callback and those
drivers also are communicating with the device, I wonder if we should
not have something more generic, that will call hid_hw_open/close in the
transport layer directly.
I do not recall having seen bugs for Wacom devices, so maybe this is
something i2c-hid related, but it wouldn't hurt I guess to open/close
the device before calling reset_resume.
Cheers,
Benjamin
>
> So, call hid_hw_open() in rmi_post_resume() so we make sure that the
> device is alive before we try talking to it.
>
> This fixes RMI device suspend/resume over HID.
>
> Signed-off-by: Lyude
> Cc: Andrew Duggan
> Cc: sta...@vger.kernel.org
> ---
> drivers/hid/hid-rmi.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index 5b40c2614599..e7d124f9a27f 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c
> @@ -431,22 +431,29 @@ static int rmi_post_resume(struct hid_device *hdev)
> {
> struct rmi_data *data = hid_get_drvdata(hdev);
> struct rmi_device *rmi_dev = data->xport.rmi_dev;
> - int ret;
> + int ret = 0;
>
> if (!(data->device_flags & RMI_DEVICE))
> return 0;
>
> - ret = rmi_reset_attn_mode(hdev);
> + /* Make sure the HID device is ready to receive events */
> + ret = hid_hw_open(hdev);
> if (ret)
> return ret;
>
> + ret = rmi_reset_attn_mode(hdev);
> + if (ret)
> + goto out;
> +
> ret = rmi_driver_resume(rmi_dev, false);
> if (ret) {
> hid_warn(hdev, "Failed to resume device: %d\n", ret);
> - return ret;
> + goto out;
> }
>
> - return 0;
> +out:
> + hid_hw_close(hdev);
> + return ret;
> }
> #endif /* CONFIG_PM */
>
> --
> 2.13.3
>
Re: [PATCH 3/3] iio: adc: stm32: add optional min-sample-time
On 07/23/2017 01:00 PM, Jonathan Cameron wrote:
> On Tue, 18 Jul 2017 14:35:32 +0200
> Fabrice Gasnier wrote:
>
>> STM32 ADC allows each channel to be sampled with a different sampling time,
>> by setting SMPR registers. Basically, value depends on local electrical
>> properties. Selecting correct value for sampling time highly depends on
>> analog source impedance. There is a manual that may help in this process:
>> 'How to get the best ADC accuracy in STM32...'
>>
>> This patch allows to configure min-sample-time via device tree, either for:
>> - all channels at once:
>> min-sample-time = <1>; /* nanosecs */
>>
>> - independently for each channel (must match "st,adc-channels" list):
>> st,adc-channels = <0 1>;
>> min-sample-time = <5000 1>; /* nanosecs */
>>
>> Signed-off-by: Fabrice Gasnier
>
> On question inline which may well just be down to me missing what
> happens when you query index element 2 from a 1 element device tree
> array.
Hi Jonathan,
I should probably comment on it, please see inline.
>> ---
>> drivers/iio/adc/stm32-adc.c | 134
>> ++--
>> 1 file changed, 130 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
>> index 5bfcc1f..e6f6b5e 100644
>> --- a/drivers/iio/adc/stm32-adc.c
>> +++ b/drivers/iio/adc/stm32-adc.c
>> @@ -83,6 +83,8 @@
>> #define STM32H7_ADC_IER 0x04
>> #define STM32H7_ADC_CR 0x08
>> #define STM32H7_ADC_CFGR0x0C
>> +#define STM32H7_ADC_SMPR1 0x14
>> +#define STM32H7_ADC_SMPR2 0x18
>> #define STM32H7_ADC_PCSEL 0x1C
>> #define STM32H7_ADC_SQR10x30
>> #define STM32H7_ADC_SQR20x34
>> @@ -151,6 +153,7 @@ enum stm32h7_adc_dmngt {
>> #define STM32H7_BOOST_CLKRATE 2000UL
>>
>> #define STM32_ADC_MAX_SQ16 /* SQ1..SQ16 */
>> +#define STM32_ADC_MAX_SMP 7 /* SMPx range is [0..7] */
>> #define STM32_ADC_TIMEOUT_US10
>> #define STM32_ADC_TIMEOUT (msecs_to_jiffies(STM32_ADC_TIMEOUT_US / 1000))
>>
>> @@ -227,6 +230,8 @@ struct stm32_adc_regs {
>> * @exten: trigger control register & bitfield
>> * @extsel: trigger selection register & bitfield
>> * @res:resolution selection register & bitfield
>> + * @smpr: smpr1 & smpr2 registers offset array
>> + * @smp_bits: smpr1 & smpr2 index and bitfields
>> */
>> struct stm32_adc_regspec {
>> const u32 dr;
>> @@ -236,6 +241,8 @@ struct stm32_adc_regspec {
>> const struct stm32_adc_regs exten;
>> const struct stm32_adc_regs extsel;
>> const struct stm32_adc_regs res;
>> +const u32 smpr[2];
>> +const struct stm32_adc_regs *smp_bits;
>> };
>>
>> struct stm32_adc;
>> @@ -251,6 +258,7 @@ struct stm32_adc_regspec {
>> * @start_conv: routine to start conversions
>> * @stop_conv: routine to stop conversions
>> * @unprepare: optional unprepare routine (disable, power-down)
>> + * @smp_cycles: programmable sampling time (ADC clock cycles)
>> */
>> struct stm32_adc_cfg {
>> const struct stm32_adc_regspec *regs;
>> @@ -262,6 +270,7 @@ struct stm32_adc_cfg {
>> void (*start_conv)(struct stm32_adc *, bool dma);
>> void (*stop_conv)(struct stm32_adc *);
>> void (*unprepare)(struct stm32_adc *);
>> +const unsigned int *smp_cycles;
>> };
>>
>> /**
>> @@ -283,6 +292,7 @@ struct stm32_adc_cfg {
>> * @rx_dma_buf: dma rx buffer bus address
>> * @rx_buf_sz: dma rx buffer size
>> * @pcsel bitmask to preselect channels on some devices
>> + * @smpr_val: sampling time settings (e.g. smpr1 / smpr2)
>> * @cal:optional calibration data on some devices
>> */
>> struct stm32_adc {
>> @@ -303,6 +313,7 @@ struct stm32_adc {
>> dma_addr_t rx_dma_buf;
>> unsigned intrx_buf_sz;
>> u32 pcsel;
>> +u32 smpr_val[2];
>> struct stm32_adc_calib cal;
>> };
>>
>> @@ -431,6 +442,39 @@ struct stm32_adc_info {
>> {}, /* sentinel */
>> };
>>
>> +/**
>> + * stm32f4_smp_bits[] - describe sampling time register index & bit fields
>> + * Sorted so it can be indexed by channel number.
>> + */
>> +static const struct stm32_adc_regs stm32f4_smp_bits[] = {
>> +/* STM32F4_ADC_SMPR2: smpr[] index, mask, shift for SMP0 to SMP9 */
>> +{ 1, GENMASK(2, 0), 0 },
>> +{ 1, GENMASK(5, 3), 3 },
>> +{ 1, GENMASK(8, 6), 6 },
>> +{ 1, GENMASK(11, 9), 9 },
>> +{ 1, GENMASK(14, 12), 12 },
>> +{ 1, GENMASK(17, 15), 15 },
>> +{ 1, GENMASK(20, 18), 18 },
>> +{ 1, GENMASK(23, 21), 21 },
>> +{ 1, GENMASK(26, 24), 24 },
>> +{ 1, GENMASK(29, 27), 27 },
>> +/* STM32F4_ADC_SMPR1, smpr[] index, mask, shift for SMP10 to SMP18 */
>> +
[PATCH] KVM: LAPIC: Fix cancel preemption timer repeatedly due to preemption
From: Wanpeng Li
Preemption can occur in the preemption timer expiration handler:
CPU0CPU1
preemption timer vmexit
handle_preemption_timer(vCPU0)
kvm_lapic_expired_hv_timer
hv_timer_is_use == true
sched_out
sched_in
kvm_arch_vcpu_load
kvm_lapic_restart_hv_timer
restart_apic_timer
start_hv_timer
already-expired timer or sw timer triggerd in the window
start_sw_timer
cancel_hv_timer
/* back in kvm_lapic_expired_hv_timer */
cancel_hv_timer
WARN_ON(!apic->lapic_timer.hv_timer_in_use); ==> Oops
This can be reproduced if CONFIG_PREEMPT is enabled.
[ cut here ]
WARNING: CPU: 4 PID: 2972 at /home/kernel/linux/arch/x86/kvm//lapic.c:1563
kvm_lapic_expired_hv_timer+0x9e/0xb0 [kvm]
CPU: 4 PID: 2972 Comm: qemu-system-x86 Tainted: G OE 4.13.0-rc2+
#16
RIP: 0010:kvm_lapic_expired_hv_timer+0x9e/0xb0 [kvm]
Call Trace:
handle_preemption_timer+0xe/0x20 [kvm_intel]
vmx_handle_exit+0xb8/0xd70 [kvm_intel]
kvm_arch_vcpu_ioctl_run+0xdd1/0x1be0 [kvm]
? kvm_arch_vcpu_load+0x47/0x230 [kvm]
? kvm_arch_vcpu_load+0x62/0x230 [kvm]
kvm_vcpu_ioctl+0x340/0x700 [kvm]
? kvm_vcpu_ioctl+0x340/0x700 [kvm]
? __fget+0xfc/0x210
do_vfs_ioctl+0xa4/0x6a0
? __fget+0x11d/0x210
SyS_ioctl+0x79/0x90
do_syscall_64+0x81/0x220
entry_SYSCALL64_slow_path+0x25/0x25
[ cut here ]
WARNING: CPU: 4 PID: 2972 at /home/kernel/linux/arch/x86/kvm//lapic.c:1498
cancel_hv_timer.isra.40+0x4f/0x60 [kvm]
CPU: 4 PID: 2972 Comm: qemu-system-x86 Tainted: GW OE 4.13.0-rc2+
#16
RIP: 0010:cancel_hv_timer.isra.40+0x4f/0x60 [kvm]
Call Trace:
kvm_lapic_expired_hv_timer+0x3e/0xb0 [kvm]
handle_preemption_timer+0xe/0x20 [kvm_intel]
vmx_handle_exit+0xb8/0xd70 [kvm_intel]
kvm_arch_vcpu_ioctl_run+0xdd1/0x1be0 [kvm]
? kvm_arch_vcpu_load+0x47/0x230 [kvm]
? kvm_arch_vcpu_load+0x62/0x230 [kvm]
kvm_vcpu_ioctl+0x340/0x700 [kvm]
? kvm_vcpu_ioctl+0x340/0x700 [kvm]
? __fget+0xfc/0x210
do_vfs_ioctl+0xa4/0x6a0
? __fget+0x11d/0x210
SyS_ioctl+0x79/0x90
do_syscall_64+0x81/0x220
entry_SYSCALL64_slow_path+0x25/0x25
This patch fixes it by don't cancel preemption timer repeatedly if
the preemption timer has already been cancelled due to preemption
since already-expired timer or sw timer triggered in the window.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 2819d4c..8341b40 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1560,9 +1560,13 @@ void kvm_lapic_expired_hv_timer(struct kvm_vcpu *vcpu)
{
struct kvm_lapic *apic = vcpu->arch.apic;
- WARN_ON(!apic->lapic_timer.hv_timer_in_use);
- WARN_ON(swait_active(&vcpu->wq));
- cancel_hv_timer(apic);
+ preempt_disable();
+ if (!(!apic_lvtt_period(apic) &&
atomic_read(&apic->lapic_timer.pending))) {
+ WARN_ON(!apic->lapic_timer.hv_timer_in_use);
+ WARN_ON(swait_active(&vcpu->wq));
+ cancel_hv_timer(apic);
+ }
+ preempt_enable();
apic_timer_expired(apic);
if (apic_lvtt_period(apic) && apic->lapic_timer.period) {
--
2.7.4
Re: [PATCH v2] ovl: drop CAP_SYS_RESOURCE from saved mounter's credentials
On Tue, Jan 10, 2017 at 8:17 PM, Vivek Goyal wrote: > On Tue, Jan 10, 2017 at 09:30:21PM +0300, Konstantin Khlebnikov wrote: >> If overlay was mounted by root then quota set for upper layer does not work >> because overlay now always use mounter's credentials for operations. >> Also overlay might deplete reserved space and inodes in ext4. >> >> This patch drops capability SYS_RESOURCE from saved credentials. >> This affects creation new files, whiteouts, and copy-up operations. >> > > I am not an expert in this area, but I thought previous patch was > better. I am not sure why overlay internal operations should be > done without CAP_SYS_RESOURCES when caller has CAP_SYS_RESOURCES. That > might be counter-intuitive. > > If some task is allowed to bypass quota limitations on a file system > then same should be true when task is working on overlay. > > Similary if a task is allowed to use reserved space on filesystem, then same > task should be allowed to use reserved space on underlying filesystem > when doing overlay. It should not be overlay's job to prevent that? > > May be it is just me Well, depends how you look at at it. Overlayfs just uses the underlying filesystem as storage. So this patch basically asserts that overlayfs can only use non-reserved space for its storage. I don't see a problem with and it's the simpler fix, but if real use cases turn up then this can be revisited. Thanks, Miklos
Re: linux-next: build failure after merge of the drm-misc tree
On Mon, Jul 24, 2017 at 2:03 AM, Stephen Rothwell wrote: > Hi Daniel, > > On Fri, 21 Jul 2017 09:24:49 +0200 Daniel Vetter > wrote: >> >> How are we going to handle this now? The refactor is deeply burried in >> drm-misc, I guess you could cherry-pick the relevant patches over. But >> that'll probably lead to more conflicts because git will get confused. > > I'll just keep applying the merge resolution patch and will remind Dave > and Greg about it during the week before the merge window opens so that > they can let Linus know that the fix up is needed. Well, Greg squeezed the vbox driver into -rc2, so now we already get to resolve this in a backmerge. And hopefully the bikeshed patches in -staging won't interfere too badly with whatever refactoring we'll do in drm-next. Greg, fyi this is the last time I'll ack a drm driver for staging. This just doesn't work. We're spending more time here working the -staging vs. drm-next conflicts than the actual vbox driver review has taken me. And probly less than the cleanup for merging directly to drm-next will end up taking. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2] staging: vboxvideo: Kconfig: Fix typos in help text
This fixes typos in vboxvideo's help text. Most notably, "to builtin this module" becomes "to build this driver built-in to the kernel". Signed-off-by: Martin Kepplinger --- Thanks Dan. I actually also had the feeling that even though it's better, it's not as clear as it could be. It's either a module or built-in; not both. revision history v2: Say "to build this driver built-in to the kernel" instead of "build in this module". drivers/staging/vboxvideo/Kconfig | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/staging/vboxvideo/Kconfig b/drivers/staging/vboxvideo/Kconfig index a52746f9a670..b8df8f60823a 100644 --- a/drivers/staging/vboxvideo/Kconfig +++ b/drivers/staging/vboxvideo/Kconfig @@ -6,7 +6,8 @@ config DRM_VBOXVIDEO This is a KMS driver for the virtual Graphics Card used in Virtual Box virtual machines. - Although it is possible to builtin this module, it is advised - to build this driver as a module, so that it can be updated - independently of the kernel. Select M to built this driver as a - module and add support for these devices via drm/kms interfaces. + Although it is possible to build this driver built-in to the + kernel, it is advised to build this driver as a module, so that + it can be updated independently of the kernel. Select M to build + this driver as a module and add support for these devices via + drm/kms interfaces. -- 2.11.0
Re: [PATCH v3 3/5] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor
On Sun, Jul 23, 2017 at 10:13:52PM +0800, Icenowy Zheng wrote: > This adds support for the Allwinner H3 thermal sensor. > > Allwinner H3 has a thermal sensor like the one in A33, but have its > registers nearly all re-arranged, sample clock moved to CCU and a pair > of bus clock and reset added. It's also the base of newer SoCs' thermal > sensors. > > Some new options is added to gpadc_data struct, to mark the difference > between the old GPADCs and THS's and the new THS's. > > Thermal sampling via interrupts are still not supported, and polling > is used instead. > > The thermal sensors on A64 and H5 is like the one on H3, but with of > course different formula factors. > > Signed-off-by: Icenowy Zheng Could you split it in half? One patch that would rework the existing code, the other one adding the H3 support? That's going to be much easier to review, bisect and revert if need be that way. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
[PATCH v3] staging: vboxvideo: Kconfig: Fix typos in help text
This fixes typos in vboxvideo's help text. Most notably, "to builtin this module" becomes "to build this driver built-in to the kernel". Signed-off-by: Martin Kepplinger --- revision history v3: Avoid a repetition of "this driver". v2: Say "to build this driver built-in to the kernel" instead of "build in this module". - Thanks Dan. drivers/staging/vboxvideo/Kconfig | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/staging/vboxvideo/Kconfig b/drivers/staging/vboxvideo/Kconfig index a52746f9a670..3200b6895178 100644 --- a/drivers/staging/vboxvideo/Kconfig +++ b/drivers/staging/vboxvideo/Kconfig @@ -6,7 +6,8 @@ config DRM_VBOXVIDEO This is a KMS driver for the virtual Graphics Card used in Virtual Box virtual machines. - Although it is possible to builtin this module, it is advised - to build this driver as a module, so that it can be updated - independently of the kernel. Select M to built this driver as a - module and add support for these devices via drm/kms interfaces. + Although it is possible to build this driver built-in to the + kernel, it is advised to build it as a module, so that it can + be updated independently of the kernel. Select M to build this + driver as a module and add support for these devices via drm/kms + interfaces. -- 2.11.0
Re: [PATCH v3] staging: vboxvideo: Kconfig: Fix typos in help text
Looks good. Thanks. regards, dan carpenter
Re: [PATCH 054/102] PCI: rockchip: explicitly request exclusive reset control
Hi Shawn,
On Sat, 2017-07-22 at 21:12 +0800, Shawn Lin wrote:
> Hi Philipp,
>
> On 2017/7/19 23:25, Philipp Zabel wrote:
> > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> > reset lines") started to transition the reset control request API calls
> > to explicitly state whether the driver needs exclusive or shared reset
> > control behavior. Convert all drivers requesting exclusive resets to the
> > explicit API call so the temporary transition helpers can be removed.
> >
> > No functional changes.
> >
> > Cc: Shawn Lin
> > Cc: Bjorn Helgaas
> > Cc: Heiko Stuebner
> > Cc: linux-...@vger.kernel.org
> > Cc: linux-rockc...@lists.infradead.org
> > Signed-off-by: Philipp Zabel
> > ---
> > drivers/pci/host/pcie-rockchip.c | 15 ---
>
> As mentioned in the thread of conversion for phy-rockchip-pcie,
> I would prefer add your patches after the reconstruction work got
> merged.
Feel free to add them when and where it is most convenient for you.
Please let me know if you want me to rebase them somewhere.
regards
Philipp
Re: [PATCH] pwm: Convert to using %pOF instead of full_name
On 07/18/2017 11:43 PM, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
>
> Signed-off-by: Rob Herring
> Cc: Thierry Reding
> Cc: Carlo Caione
> Cc: Kevin Hilman
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-amlo...@lists.infradead.org
> ---
> drivers/pwm/pwm-meson.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
> index cb845edfe2b4..d589331d1884 100644
> --- a/drivers/pwm/pwm-meson.c
> +++ b/drivers/pwm/pwm-meson.c
> @@ -441,7 +441,7 @@ static int meson_pwm_init_channels(struct meson_pwm
> *meson,
> for (i = 0; i < meson->chip.npwm; i++) {
> struct meson_pwm_channel *channel = &channels[i];
>
> - snprintf(name, sizeof(name), "%s#mux%u", np->full_name, i);
> + snprintf(name, sizeof(name), "%pOF#mux%u", np, i);
>
> init.name = name;
> init.ops = &clk_mux_ops;
> --
> 2.11.0
>
>
> ___
> linux-amlogic mailing list
> linux-amlo...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>
Acked-by: Neil Armstrong
Re: [PATCH v3 3/9] clk: at91: add audio pll clock drivers
Hi Stephen,
On 22/07/2017 00:20, Stephen Boyd wrote:
> On 07/13, Quentin Schulz wrote:
>> diff --git a/drivers/clk/at91/clk-audio-pll-pad.c
>> b/drivers/clk/at91/clk-audio-pll-pad.c
>> new file mode 100644
>> index ..10dd6d625696
>> --- /dev/null
>> +++ b/drivers/clk/at91/clk-audio-pll-pad.c
>> @@ -0,0 +1,206 @@
>> +/*
>> + * Copyright (C) 2016 Atmel Corporation,
>> + * Nicolas Ferre
>> + * Copyright (C) 2017 Free Electrons,
>> + * Quentin Schulz
>> + *
>> + * 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
>
> Used?
>
Not really, I need slab.h for kzalloc tough which was included by clkdev.
[...]
>> +static int clk_audio_pll_pad_set_rate(struct clk_hw *hw, unsigned long rate,
>> + unsigned long parent_rate)
>> +{
>> +struct clk_audio_pad *apad_ck = to_clk_audio_pad(hw);
>> +u8 tmp_div;
>> +
>> +pr_debug("A PLL/PAD: %s, rate = %lu (parent_rate = %lu)\n", __func__,
>> + rate, parent_rate);
>> +
>> +if (!rate)
>> +return -EINVAL;
>
> This happens?
>
I don't know, but it's better to do this quick check rather than being
exposed to a division by zero IMHO. Nothing in clk_ops states that the
rate given to set_rate is non-zero, so I made sure this can't happen.
>> +
>> +tmp_div = parent_rate / rate;
>> +if (tmp_div % 3 == 0) {
>> +apad_ck->qdaudio = tmp_div / 3;
>> +apad_ck->div = 3;
>> +} else {
>> +apad_ck->qdaudio = tmp_div / 2;
>> +apad_ck->div = 2;
>> +}[...]
>> +static void __init of_sama5d2_clk_audio_pll_pad_setup(struct device_node
>> *np)
>> +{
>> +struct clk_audio_pad *apad_ck;
>> +struct clk_init_data init;
>
> Best to initialize to { } just in case we add something later.
>
ACK.
>> +struct regmap *regmap;
>> +const char *parent_name;
>> +const char *name = np->name;
>> +int ret;
>> +
>> +parent_name = of_clk_get_parent_name(np, 0);
>> +
>> +of_property_read_string(np, "clock-output-names", &name);
>> +
>> +regmap = syscon_node_to_regmap(of_get_parent(np));
>> +if (IS_ERR(regmap))
>> +return;
>> +
>> +apad_ck = kzalloc(sizeof(*apad_ck), GFP_KERNEL);
>> +if (!apad_ck)
>> +return;
>> +
>> +init.name = name;
>> +init.ops = &audio_pll_pad_ops;
>> +init.parent_names = (parent_name ? &parent_name : NULL);
>
> Use of_clk_parent_fill()?
>
[Deleting `parent_name = of_clk_get_parent_name(np, 0);`]
[Deleting `init.parent_names = (parent_name ? &parent_name : NULL);`]
+ const char *parent_names[1];
[...]
+ of_clk_parent_fill(np, parent_names, 1);
+ init.parent_names = parent_names;
Is it what you're asking?
>> +init.num_parents = 1;
>> +init.flags = CLK_SET_RATE_GATE | CLK_SET_PARENT_GATE |
>> +CLK_SET_RATE_PARENT;
>> +
>> +apad_ck->hw.init = &init;
>> +apad_ck->regmap = regmap;
>> +
>> +ret = clk_hw_register(NULL, &apad_ck->hw);
>> +if (ret)
>> +kfree(apad_ck);
>> +else
>> +of_clk_add_hw_provider(np, of_clk_hw_simple_get, &apad_ck->hw);
>
> Maybe we should make this register sequence a helper function.
> Seems common.
>
I can put such an helper in an header if this is what you meant.
>> +}
>> +
>> +CLK_OF_DECLARE(of_sama5d2_clk_audio_pll_pad_setup,
>> + "atmel,sama5d2-clk-audio-pll-pad",
>> + of_sama5d2_clk_audio_pll_pad_setup);
>
> We can't have a device driver for this?
>
Could you elaborate please?
>> diff --git a/drivers/clk/at91/clk-audio-pll-pmc.c
>> b/drivers/clk/at91/clk-audio-pll-pmc.c
>> new file mode 100644
>> index ..7b0847ed7a4b
>> --- /dev/null
>> +++ b/drivers/clk/at91/clk-audio-pll-pmc.c
[...]
>> +static int clk_audio_pll_pmc_set_rate(struct clk_hw *hw, unsigned long rate,
>> + unsigned long parent_rate)
>> +{
>> +struct clk_audio_pmc *apmc_ck = to_clk_audio_pmc(hw);
>> +
>> +if (!rate)
>> +return -EINVAL;
>> +
>> +pr_debug("A PLL/PMC: %s, rate = %lu (parent_rate = %lu)\n", __func__,
>> + rate, parent_rate);
>> +
>> +apmc_ck->qdpmc = parent_rate / rate - 1;
>
> Hopefully rate isn't 1 or that goes undefined.
>
Thanks to operator precedence, the only check to do is rate != 0 (done
few lines above). Division has precedence over substraction.
[...]
>> +static void __init of_sama5d2_clk_audio_pll_pmc_setup(struct device_node
>> *np)
>> +{
>> +struct clk_audio_pmc *apmc_ck;
>> +struct clk_init_data init;
>> +struct regmap *regmap;
>> +const char *parent_name;
>> +const char *name = np->name;
>> +int ret;
>> +
>> +parent_name = of_clk_get_pare
Re: [PATCH] usb: dwc3: Support the dwc3 host suspend/resume
Hi Baolin,
On 7/24/2017 11:26 AM, Baolin Wang wrote:
Other than what I pushed in my patch -
("usb: dwc3: Don't reinitialize core during host bus-suspend/resume")
Just performing pm_request_resume or handling same in dwc3 glue
driver should be sufficient.
>>> Yes.
>>>
Also, what is trigger for runtime_resume for your platform?
>>> In our platform glue layer, we have extcon events to notify there are
>>> devices connected, then gule layer will resume dwc3 device.
>>>
>> IMO you can just perform resume of &dwc->xhci->dev instead of resuming dwc3.
>> Since, dwc3 is parent of xhci that will trigger resume of dwc3 as well.
> I am not sure this is good enough but it seems can solve some
> problems, then we do not need resume/suspend host in dwc3 core.
In that case can we proceed with this patch:
[1] https://www.spinics.net/lists/linux-usb/msg158682.html
For your platform you can pick this patch and resume dwc->xhci->dev resume
from your glue driver.
Do you have any other concerns?
Re: [PATCH v6 0/2] x86: Implement fast refcount overflow protection
On Mon, Jul 24, 2017 at 04:38:06PM +1000, Michael Ellerman wrote: > What I'm not entirely clear on is what the best trade off is in terms of > overhead vs checks. The summary of behaviour between the fast and full > versions you promised Ingo will help there I think. That's something that's probably completely different for PPC than it is for x86. Both because your primitive is LL/SC and thus the saturation semantics we need a cmpxchg loop for are more natural in your case anyway, and the fact that your LL/SC is horrendously slow in any case. Also, I still haven't seen an actual benchmark where our cmpxchg loop actually regresses anything, just a lot of yelling about potential regressions :/
Re: [PATCH] sched/deadline: fix switching to -deadline
Hi all,
I have this patch in a local tree, together with other fixes / cleanups
I plan to submit in the next weeks...
Since I see that the patch has not been applied, I wonder if some
changes are needed before submitting it another time.
If anyone has requests for changes in the patch, let me know.
Thanks,
Luca
On Thu, 20 Apr 2017 21:30:56 +0200
luca abeni wrote:
> From: Luca Abeni
>
> When switching to -deadline, if the scheduling deadline of a task is
> in the past then switched_to_dl() calls setup_new_entity() to properly
> initialize the scheduling deadline and runtime.
>
> The problem is that the task is enqueued _before_ having its parameters
> initialized by setup_new_entity(), and this can cause problems.
> For example, a task with its out-of-date deadline in the past will
> potentially be enqueued as the highest priority one; however, its
> adjusted deadline may not be the earliest one.
>
> This patch fixes the problem by initializing the task's parameters before
> enqueuing it.
>
> Signed-off-by: Luca Abeni
> Reviewed-by: Daniel Bristot de Oliveira
> ---
> kernel/sched/deadline.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index a2ce590..ec53d24 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -950,6 +950,10 @@ enqueue_dl_entity(struct sched_dl_entity *dl_se,
> update_dl_entity(dl_se, pi_se);
> else if (flags & ENQUEUE_REPLENISH)
> replenish_dl_entity(dl_se, pi_se);
> + else if ((flags & ENQUEUE_RESTORE) &&
> + dl_time_before(dl_se->deadline,
> + rq_clock(rq_of_dl_rq(dl_rq_of_se(dl_se)
> + setup_new_dl_entity(dl_se);
>
> __enqueue_dl_entity(dl_se);
> }
> @@ -1767,14 +1771,6 @@ static void switched_to_dl(struct rq *rq, struct
> task_struct *p)
> if (!task_on_rq_queued(p))
> return;
>
> - /*
> - * If p is boosted we already updated its params in
> - * rt_mutex_setprio()->enqueue_task(..., ENQUEUE_REPLENISH),
> - * p's deadline being now already after rq_clock(rq).
> - */
> - if (dl_time_before(p->dl.deadline, rq_clock(rq)))
> - setup_new_dl_entity(&p->dl);
> -
> if (rq->curr != p) {
> #ifdef CONFIG_SMP
> if (p->nr_cpus_allowed > 1 && rq->dl.overloaded)
[PATCH 0/2] ARM: dts: sabrelite/nitrogen6x: fix USB PHY reset
Hi all, This series is follow-up to those two patches: https://patchwork.kernel.org/patch/9395531/ https://patchwork.kernel.org/patch/9395539/ At the time they were refused because a pwrseq library was supposed to get in. Unfortunately that plan hasn't succeeded yet so re-submitting the original two patches with the following modifications: - Rebase on top of v4.13-rc2 - Reword the title to make it clear this is a fix - Reword the changelog so it is clearly a temporary workaround Let me know if you have any question. Regards, Gary Gary Bisson (2): ARM: dts: imx6qdl-sabrelite: fix USB PHY reset ARM: dts: imx6qdl-nitrogen6x: fix USB PHY reset arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 20 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 20 2 files changed, 40 insertions(+) -- 2.11.0
[PATCH 2/2] ARM: dts: imx6qdl-nitrogen6x: fix USB PHY reset
Declared as a regulator since the driver doesn't have a reset-gpios
property for this.
This ensures that the PHY is woken up, not depending on the state the
second stage bootloader leaves the pin.
This is a workaround until a proper mechanism is provided to reset such
devices like the pwrseq library [1] for instance.
[1] https://lkml.org/lkml/2017/2/10/779
Signed-off-by: Gary Bisson
---
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index f22e5879340b..989376643cf6 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -108,6 +108,19 @@
startup-delay-us = <7>;
enable-active-high;
};
+
+ reg_usb_h1_vbus: regulator@5 {
+ compatible = "regulator-fixed";
+ reg = <5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh1>;
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ };
};
gpio-keys {
@@ -515,6 +528,12 @@
>;
};
+ pinctrl_usbh1: usbh1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x030b0
+ >;
+ };
+
pinctrl_usbotg: usbotggrp {
fsl,pins = <
MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
@@ -629,6 +648,7 @@
};
&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
status = "okay";
};
--
2.11.0
[PATCH 1/2] ARM: dts: imx6qdl-sabrelite: fix USB PHY reset
Declared as a regulator since the driver doesn't have a reset-gpios
property for this.
This ensures that the PHY is woken up, not depending on the state the
second stage bootloader leaves the pin.
This is a workaround until a proper mechanism is provided to reset such
devices like the pwrseq library [1] for instance.
[1] https://lkml.org/lkml/2017/2/10/779
Signed-off-by: Gary Bisson
---
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index afe7449c47da..7bd14e23afb8 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -123,6 +123,19 @@
regulator-max-microvolt = <280>;
regulator-always-on;
};
+
+ reg_usb_h1_vbus: regulator@7 {
+ compatible = "regulator-fixed";
+ reg = <7>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh1>;
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ };
};
mipi_xclk: mipi_xclk {
@@ -610,6 +623,12 @@
>;
};
+ pinctrl_usbh1: usbh1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x030b0
+ >;
+ };
+
pinctrl_usbotg: usbotggrp {
fsl,pins = <
MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
@@ -705,6 +724,7 @@
};
&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
status = "okay";
};
--
2.11.0
Re: [PATCH v2] mm/mremap: Fail map duplication attempts for private mappings
On Fri 21-07-17 14:18:31, Mike Kravetz wrote:
[...]
> >From 5c4a1602bd6a942544ed011dc0a72fd258e874b2 Mon Sep 17 00:00:00 2001
> From: Mike Kravetz
> Date: Wed, 12 Jul 2017 13:52:47 -0700
> Subject: [PATCH] mm/mremap: Fail map duplication attempts for private mappings
>
> mremap will attempt to create a 'duplicate' mapping if old_size
> == 0 is specified. In the case of private mappings, mremap
> will actually create a fresh separate private mapping unrelated
> to the original. This does not fit with the design semantics of
> mremap as the intention is to create a new mapping based on the
> original.
>
> Therefore, return EINVAL in the case where an attempt is made
> to duplicate a private mapping. Also, print a warning message
> (once) if such an attempt is made.
>
> Signed-off-by: Mike Kravetz
Acked-by: Michal Hocko
Thanks!
> ---
> mm/mremap.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/mm/mremap.c b/mm/mremap.c
> index cd8a1b1..75b167d 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -383,6 +383,19 @@ static struct vm_area_struct *vma_to_resize(unsigned
> long addr,
> if (!vma || vma->vm_start > addr)
> return ERR_PTR(-EFAULT);
>
> + /*
> + * !old_len is a special case where an attempt is made to 'duplicate'
> + * a mapping. This makes no sense for private mappings as it will
> + * instead create a fresh/new mapping unrelated to the original. This
> + * is contrary to the basic idea of mremap which creates new mappings
> + * based on the original. There are no known use cases for this
> + * behavior. As a result, fail such attempts.
> + */
> + if (!old_len && !(vma->vm_flags & (VM_SHARED | VM_MAYSHARE))) {
> + pr_warn_once("%s (%d): attempted to duplicate a private mapping
> with mremap. This is not supported.\n", current->comm, current->pid);
> + return ERR_PTR(-EINVAL);
> + }
> +
> if (is_vm_hugetlb_page(vma))
> return ERR_PTR(-EINVAL);
>
> --
> 2.7.5
--
Michal Hocko
SUSE Labs
Re: [PATCH v2] cpufreq: s5pv210: add missing of_node_put
On 21-07-17, 21:53, Julia Lawall wrote:
> for_each_compatible_node performs an of_node_get on each iteration, so a
> return from the loop requires an of_node_put.
>
> The semantic patch that fixes this problem is as follows
> (http://coccinelle.lip6.fr):
>
> //
> @@
> local idexpression n;
> expression e,e1,e2;
> statement S;
> iterator i1;
> iterator name for_each_compatible_node;
> @@
>
> for_each_compatible_node(n,e1,e2) {
>...
> (
>of_node_put(n);
> |
>e = n
> |
>return n;
> |
>i1(...,n,...) S
> |
> + of_node_put(n);
> ? return ...;
> )
>...
> }
> //
>
> Additionally, call of_node_put on the previous value of np, obtained from
> of_find_compatible_node, that is no longer accessible at the point of the
> for_each_compatible_node.
>
> Signed-off-by: Julia Lawall
>
> ---
>
> v2: add the of_node_put for the call to of_find_compatible_node as well.
>
> drivers/cpufreq/s5pv210-cpufreq.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/cpufreq/s5pv210-cpufreq.c
> b/drivers/cpufreq/s5pv210-cpufreq.c
> index f82074e..5d31c2d 100644
> --- a/drivers/cpufreq/s5pv210-cpufreq.c
> +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> @@ -602,6 +602,7 @@ static int s5pv210_cpufreq_probe(struct platform_device
> *pdev)
> }
>
> clk_base = of_iomap(np, 0);
> + of_node_put(np);
> if (!clk_base) {
> pr_err("%s: failed to map clock registers\n", __func__);
> return -EFAULT;
> @@ -612,6 +613,7 @@ static int s5pv210_cpufreq_probe(struct platform_device
> *pdev)
> if (id < 0 || id >= ARRAY_SIZE(dmc_base)) {
> pr_err("%s: failed to get alias of dmc node '%s'\n",
> __func__, np->name);
> + of_node_put(np);
> return id;
> }
>
> @@ -619,6 +621,7 @@ static int s5pv210_cpufreq_probe(struct platform_device
> *pdev)
> if (!dmc_base[id]) {
> pr_err("%s: failed to map dmc%d registers\n",
> __func__, id);
> + of_node_put(np);
> return -EFAULT;
> }
> }
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH 07/10] cpufreq: dt: Add support for some new Allwinner SoCs
On 23-07-17, 18:27, Icenowy Zheng wrote:
> Some new Allwinner SoCs get supported in the kernel after the
> compatibles are added to cpufreq-dt-platdev driver.
>
> Add their compatible strings in the cpufreq-dt-platdev driver.
>
> Cc: "Rafael J. Wysocki"
> Cc: Viresh Kumar
> Signed-off-by: Icenowy Zheng
> ---
> drivers/cpufreq/cpufreq-dt-platdev.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
> b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 2eb40d46d357..c3851453e84a 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -24,7 +24,11 @@ static const struct of_device_id machines[] __initconst = {
> { .compatible = "allwinner,sun8i-a23", },
> { .compatible = "allwinner,sun8i-a33", },
> { .compatible = "allwinner,sun8i-a83t", },
> + { .compatible = "allwinner,sun8i-h2-plus", },
> { .compatible = "allwinner,sun8i-h3", },
> + { .compatible = "allwinner,sun8i-v3s", },
> + { .compatible = "allwinner,sun50i-a64", },
> + { .compatible = "allwinner,sun50i-h5", },
>
> { .compatible = "apm,xgene-shadowcat", },
>
> @@ -43,6 +47,8 @@ static const struct of_device_id machines[] __initconst = {
> { .compatible = "marvell,pxa250", },
> { .compatible = "marvell,pxa270", },
>
> + { .compatible = "nextthing,gr8", },
> +
> { .compatible = "samsung,exynos3250", },
> { .compatible = "samsung,exynos4210", },
> { .compatible = "samsung,exynos4212", },
Acked-by: Viresh Kumar
--
viresh
Re: A udev rule to serve the change event of ACPI container?
On Wed 19-07-17 17:09:10, Joey Lee wrote: > On Mon, Jul 17, 2017 at 11:05:25AM +0200, Michal Hocko wrote: [...] > > The problem I have with this expectation is that userspace will never > > have a good atomic view of the whole container. So it can only try to > > I agreed! > > Even a userspace application can handle part of offline jobs. It's > still possible that other kernel/userland compenents are using the > resource in container. > > > eject and then hope that nobody has onlined part of the container. > > If you emit offline event to the userspace the cleanup can be done and > > after the last component goes offline then the eject can be done > > atomically. > > The thing that we didn't align is how does kernel maintains the flag > of ejection state on container. Why it cannot be an attribute of the container? The flag would be set when the eject operation is requested and cleared when either the operation is successful (all parts offline and eject operation acked by the BIOS) or it is terminated. [...] > Base on the above figure, if userspace didn't do anything or it > just performs part of offline jobs. Then the container's [eject] > state will be always _SET_ there, and kernel will always check > the the latest child offline state when any child be offlined > by userspace. What is a problem about that? The eject is simply in progress until all is set. Or maybe I just misunderstood. > > On the other hand, for retry BIOS, we will apply the same > _eject_ flag approach on retry BIOS. If the OS performs > offline/ejection jobs too long then the retry BIOS is finally > time out. There doesn't have way for OS to aware the timeout. Doesn't BIOS notify the OS that the eject has timed out? > So the _eject_ flag is set forever. > > Thanks a lot! > Joey Lee -- Michal Hocko SUSE Labs
Re: [PATCH v7 1/3] perf: cavium: Support memory controller PMU counters
Hi Jonathan,
On Wed, Jul 19, 2017 at 09:31:01PM +0800, Jonathan Cameron wrote:
> On Wed, 19 Jul 2017 14:08:45 +0200
> Jan Glauber wrote:
>
> > Add support for the PMU counters on Cavium SOC memory controllers.
> >
> > This patch also adds generic functions to allow supporting more
> > devices with PMU counters.
> >
> > Properties of the LMC PMU counters:
> > - not stoppable
> > - fixed purpose
> > - read-only
> > - one PCI device per memory controller
> >
> > Signed-off-by: Jan Glauber
> Hi Jan,
>
> A few little things I noticed whilst taking a quick look.
>
> Jonathan
> > ---
> > drivers/perf/Kconfig | 8 +
> > drivers/perf/Makefile | 1 +
> > drivers/perf/cavium_pmu.c | 416
> > +
> > include/linux/cpuhotplug.h | 1 +
> > 4 files changed, 426 insertions(+)
> > create mode 100644 drivers/perf/cavium_pmu.c
>
> > +
> > +/*
> > + * The pmu events are independent from CPUs. Provide a cpumask
> > + * nevertheless to prevent perf from adding the event per-cpu and just
> > + * set the mask to one online CPU. Use the same cpumask for all "uncore"
> > + * devices.
> > + *
> > + * There is a performance penalty for accessing a device from a CPU on
> > + * another socket, but we do not care.
> > + */
> > +static int cvm_pmu_offline_cpu(unsigned int old_cpu, struct hlist_node
> > *node)
> > +{
> > + struct cvm_pmu_dev *pmu_dev;
> > + int new_cpu;
> > +
> > + pmu_dev = hlist_entry_safe(node, struct cvm_pmu_dev, cpuhp_node);
> > + if (!cpumask_test_and_clear_cpu(old_cpu, &pmu_dev->active_mask))
> > + return 0;
> > +
> > + new_cpu = cpumask_any_but(cpu_online_mask, old_cpu);
> > + if (new_cpu >= nr_cpu_ids)
> > + return 0;
> Blank line.
OK
> > + perf_pmu_migrate_context(&pmu_dev->pmu, old_cpu, new_cpu);
> > + cpumask_set_cpu(new_cpu, &pmu_dev->active_mask);
> nitpick : blank line here would help readability.
OK
> > + return 0;
> > +}
> > +
> > +static ssize_t cvm_pmu_attr_show_cpumask(struct device *dev,
> > +struct device_attribute *attr,
> > +char *buf)
> > +{
> > + struct pmu *pmu = dev_get_drvdata(dev);
> > + struct cvm_pmu_dev *pmu_dev = container_of(pmu, struct cvm_pmu_dev,
> > pmu);
> > +
> > + return cpumap_print_to_pagebuf(true, buf, &pmu_dev->active_mask);
> > +}
> > +
> > +static DEVICE_ATTR(cpumask, S_IRUGO, cvm_pmu_attr_show_cpumask, NULL);
> > +
> > +static struct attribute *cvm_pmu_attrs[] = {
> > + &dev_attr_cpumask.attr,
> > + NULL,
> > +};
> > +
> > +static struct attribute_group cvm_pmu_attr_group = {
> > + .attrs = cvm_pmu_attrs,
> > +};
> > +
> > +/*
> > + * LMC (memory controller) counters:
> > + * - not stoppable, always on, read-only
> > + * - one PCI device per memory controller
> > + */
> > +#define LMC_CONFIG_OFFSET 0x188
> > +#define LMC_CONFIG_RESET_BIT BIT(17)
> > +
> > +/* LMC events */
> > +#define LMC_EVENT_IFB_CNT 0x1d0
> > +#define LMC_EVENT_OPS_CNT 0x1d8
> > +#define LMC_EVENT_DCLK_CNT 0x1e0
> > +#define LMC_EVENT_BANK_CONFLICT1 0x360
> > +#define LMC_EVENT_BANK_CONFLICT2 0x368
> > +
> > +#define CVM_PMU_LMC_EVENT_ATTR(_name, _id)
> > \
> > + &((struct perf_pmu_events_attr[]) {
> > \
> > + {
> > \
> > + __ATTR(_name, S_IRUGO, cvm_pmu_event_sysfs_show, NULL),
> > \
> > + _id,
> > \
> > + "lmc_event=" __stringify(_id),
> > \
> > + }
> > \
> > + })[0].attr.attr
> > +
> > +/* map counter numbers to register offsets */
> > +static int lmc_events[] = {
> > + LMC_EVENT_IFB_CNT,
> > + LMC_EVENT_OPS_CNT,
> > + LMC_EVENT_DCLK_CNT,
> > + LMC_EVENT_BANK_CONFLICT1,
> > + LMC_EVENT_BANK_CONFLICT2,
> > +};
> > +
> > +static int cvm_pmu_lmc_add(struct perf_event *event, int flags)
> > +{
> > + struct hw_perf_event *hwc = &event->hw;
> > +
> > + return cvm_pmu_add(event, flags, LMC_CONFIG_OFFSET,
> > + lmc_events[hwc->config]);
> > +}
> > +
> > +PMU_FORMAT_ATTR(lmc_event, "config:0-2");
> > +
> > +static struct attribute *cvm_pmu_lmc_format_attr[] = {
> > + &format_attr_lmc_event.attr,
> > + NULL,
> > +};
> > +
> > +static struct attribute_group cvm_pmu_lmc_format_group = {
> > + .name = "format",
> > + .attrs = cvm_pmu_lmc_format_attr,
> > +};
> > +
> > +static struct attribute *cvm_pmu_lmc_events_attr[] = {
> > + CVM_PMU_LMC_EVENT_ATTR(ifb_cnt, 0),
> > + CVM_PMU_LMC_EVENT_ATTR(ops_cnt, 1),
> > + CVM_PMU_LMC_EVENT_ATTR(dclk_cnt,2),
> > + CVM_PMU_LMC_EVENT_ATTR(bank_conflict1
Re: [PATCH v7 1/2] cpufreq: schedutil: Make iowait boost more energy efficient
On 23-07-17, 08:54, Joel Fernandes wrote: > Currently the iowait_boost feature in schedutil makes the frequency go to max > on iowait wakeups. This feature was added to handle a case that Peter > described where the throughput of operations involving continuous I/O requests > [1] is reduced due to running at a lower frequency, however the lower > throughput itself causes utilization to be low and hence causing frequency to > be low hence its "stuck". > > Instead of going to max, its also possible to achieve the same effect by > ramping up to max if there are repeated in_iowait wakeups happening. This > patch > is an attempt to do that. We start from a lower frequency (policy->min) > and double the boost for every consecutive iowait update until we reach the > maximum iowait boost frequency (iowait_boost_max). > > I ran a synthetic test (continuous O_DIRECT writes in a loop) on an x86 > machine > with intel_pstate in passive mode using schedutil. In this test the > iowait_boost > value ramped from 800MHz to 4GHz in 60ms. The patch achieves the desired > improved > throughput as the existing behavior. > > [1] https://patchwork.kernel.org/patch/9735885/ > > Cc: Srinivas Pandruvada > Cc: Len Brown > Cc: Rafael J. Wysocki > Cc: Viresh Kumar > Cc: Ingo Molnar > Cc: Peter Zijlstra > Suggested-by: Peter Zijlstra > Suggested-by: Viresh Kumar > Signed-off-by: Joel Fernandes > --- > kernel/sched/cpufreq_schedutil.c | 38 -- > 1 file changed, 32 insertions(+), 6 deletions(-) You Send V7 [1-2]/2 twice, Are they different ? For both the patches: Acked-by: Viresh Kumar -- viresh
[PATCH v2] KVM: LAPIC: Fix cancel preemption timer repeatedly due to preemption
From: Wanpeng Li
Preemption can occur in the preemption timer expiration handler:
CPU0CPU1
preemption timer vmexit
handle_preemption_timer(vCPU0)
kvm_lapic_expired_hv_timer
hv_timer_is_use == true
sched_out
sched_in
kvm_arch_vcpu_load
kvm_lapic_restart_hv_timer
restart_apic_timer
start_hv_timer
already-expired timer or sw timer triggerd
in the window
start_sw_timer
cancel_hv_timer
/* back in kvm_lapic_expired_hv_timer */
cancel_hv_timer
WARN_ON(!apic->lapic_timer.hv_timer_in_use); ==>
Oops
This can be reproduced if CONFIG_PREEMPT is enabled.
[ cut here ]
WARNING: CPU: 4 PID: 2972 at /home/kernel/linux/arch/x86/kvm//lapic.c:1563
kvm_lapic_expired_hv_timer+0x9e/0xb0 [kvm]
CPU: 4 PID: 2972 Comm: qemu-system-x86 Tainted: G OE 4.13.0-rc2+
#16
RIP: 0010:kvm_lapic_expired_hv_timer+0x9e/0xb0 [kvm]
Call Trace:
handle_preemption_timer+0xe/0x20 [kvm_intel]
vmx_handle_exit+0xb8/0xd70 [kvm_intel]
kvm_arch_vcpu_ioctl_run+0xdd1/0x1be0 [kvm]
? kvm_arch_vcpu_load+0x47/0x230 [kvm]
? kvm_arch_vcpu_load+0x62/0x230 [kvm]
kvm_vcpu_ioctl+0x340/0x700 [kvm]
? kvm_vcpu_ioctl+0x340/0x700 [kvm]
? __fget+0xfc/0x210
do_vfs_ioctl+0xa4/0x6a0
? __fget+0x11d/0x210
SyS_ioctl+0x79/0x90
do_syscall_64+0x81/0x220
entry_SYSCALL64_slow_path+0x25/0x25
[ cut here ]
WARNING: CPU: 4 PID: 2972 at /home/kernel/linux/arch/x86/kvm//lapic.c:1498
cancel_hv_timer.isra.40+0x4f/0x60 [kvm]
CPU: 4 PID: 2972 Comm: qemu-system-x86 Tainted: GW OE 4.13.0-rc2+
#16
RIP: 0010:cancel_hv_timer.isra.40+0x4f/0x60 [kvm]
Call Trace:
kvm_lapic_expired_hv_timer+0x3e/0xb0 [kvm]
handle_preemption_timer+0xe/0x20 [kvm_intel]
vmx_handle_exit+0xb8/0xd70 [kvm_intel]
kvm_arch_vcpu_ioctl_run+0xdd1/0x1be0 [kvm]
? kvm_arch_vcpu_load+0x47/0x230 [kvm]
? kvm_arch_vcpu_load+0x62/0x230 [kvm]
kvm_vcpu_ioctl+0x340/0x700 [kvm]
? kvm_vcpu_ioctl+0x340/0x700 [kvm]
? __fget+0xfc/0x210
do_vfs_ioctl+0xa4/0x6a0
? __fget+0x11d/0x210
SyS_ioctl+0x79/0x90
do_syscall_64+0x81/0x220
entry_SYSCALL64_slow_path+0x25/0x25
This patch fixes it by don't cancel preemption timer repeatedly if
the preemption timer has already been cancelled due to preemption
since already-expired timer or sw timer triggered in the window.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 2819d4c..8341b40 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1560,9 +1560,13 @@ void kvm_lapic_expired_hv_timer(struct kvm_vcpu *vcpu)
{
struct kvm_lapic *apic = vcpu->arch.apic;
- WARN_ON(!apic->lapic_timer.hv_timer_in_use);
- WARN_ON(swait_active(&vcpu->wq));
- cancel_hv_timer(apic);
+ preempt_disable();
+ if (!(!apic_lvtt_period(apic) &&
atomic_read(&apic->lapic_timer.pending))) {
+ WARN_ON(!apic->lapic_timer.hv_timer_in_use);
+ WARN_ON(swait_active(&vcpu->wq));
+ cancel_hv_timer(apic);
+ }
+ preempt_enable();
apic_timer_expired(apic);
if (apic_lvtt_period(apic) && apic->lapic_timer.period) {
--
2.7.4
Re: [PATCH v12 6/8] mm: support reporting free page blocks
On Wed 19-07-17 20:01:18, Wei Wang wrote: > On 07/19/2017 04:13 PM, Michal Hocko wrote: [... > >All you should need is the check for the page reference count, no? I > >assume you do some sort of pfn walk and so you should be able to get an > >access to the struct page. > > Not necessarily - the guest struct page is not seen by the hypervisor. The > hypervisor only gets those guest pfns which are hinted as unused. From the > hypervisor (host) point of view, a guest physical address corresponds to a > virtual address of a host process. So, once the hypervisor knows a guest > physical page is unsued, it knows that the corresponding virtual memory of > the process doesn't need to be transferred in the 1st round. I am sorry, but I do not understand. Why cannot _guest_ simply check the struct page ref count and send them to the hypervisor? Is there any documentation which describes the workflow or code which would use your new API? -- Michal Hocko SUSE Labs
Re: [PATCH] tracing: Fix trace_pipe_raw read panic
On 24 July 2017 at 03:21, Chunyu Hu wrote:
> per_cpu trace directories and files are created for all possible cpus,
> but only the cpus which have ever been on-lined have their own per cpu
> ring buffer (allocated by cpuhp threads). While trace_buffers_open, the
> open handler for trace file 'trace_pipe_raw' is always trying to access
> field of ring_buffer_per_cpu, and would panic with the NULL pointer.
>
> Align the behavior of trace_pipe_raw with trace_pipe, that returns -NODEV
> when openning it if that cpu does not have trace ring buffer.
>
> Reproduce:
> cat /sys/kernel/debug/tracing/per_cpu/cpu31/trace_pipe_raw
> (cpu31 is never on-lined, this is a 16 cores x86_64 box)
>
> Tested with:
> 1) boot with maxcpus=14, read trace_pipe_raw of cpu15.
>Got -NODEV.
> 2) oneline cpu15, read trace_pipe_raw of cpu15.
>Get the raw trace data.
>
> Call trace:
> [ 5760.950995] RIP: 0010:ring_buffer_alloc_read_page+0x32/0xe0
> [ 5760.961678] tracing_buffers_read+0x1f6/0x230
> [ 5760.962695] __vfs_read+0x37/0x160
> [ 5760.963498] ? __vfs_read+0x5/0x160
> [ 5760.964339] ? security_file_permission+0x9d/0xc0
> [ 5760.965451] ? __vfs_read+0x5/0x160
> [ 5760.966280] vfs_read+0x8c/0x130
> [ 5760.967070] SyS_read+0x55/0xc0
> [ 5760.967779] do_syscall_64+0x67/0x150
> [ 5760.968687] entry_SYSCALL64_slow_path+0x25/0x25
>
> Signed-off-by: Chunyu Hu
> ---
> kernel/trace/ring_buffer.c | 5 +
> kernel/trace/trace.c | 14 +-
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 4ae268e..66c109e 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -3002,6 +3002,11 @@ int ring_buffer_write(struct ring_buffer *buffer,
> }
> EXPORT_SYMBOL_GPL(ring_buffer_write);
>
> +bool rb_per_cpu_allocated(struct ring_buffer *buffer, int cpu)
> +{
> + return !!cpumask_test_cpu(cpu, buffer->cpumask);
> +}
> +
> static bool rb_per_cpu_empty(struct ring_buffer_per_cpu *cpu_buffer)
> {
> struct buffer_page *reader = cpu_buffer->reader_page;
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 42b9355..508a1ca 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -6542,11 +6542,16 @@ static int snapshot_raw_open(struct inode *inode,
> struct file *filp)
>
> #endif /* CONFIG_TRACER_SNAPSHOT */
>
> +extern bool rb_per_cpu_allocated(struct ring_buffer *buffer, int cpu);
> +
> static int tracing_buffers_open(struct inode *inode, struct file *filp)
> {
> struct trace_array *tr = inode->i_private;
> + struct trace_buffer *tb = &tr->trace_buffer;
> + struct ring_buffer *buffer = tb->buffer;
> struct ftrace_buffer_info *info;
> int ret;
> + int cpu_file;
>
> if (tracing_disabled)
> return -ENODEV;
> @@ -6554,6 +6559,13 @@ static int tracing_buffers_open(struct inode *inode,
> struct file *filp)
> if (trace_array_get(tr) < 0)
> return -ENODEV;
>
> + cpu_file = tracing_get_cpu(inode);
> +
> + /* Make sure, ring buffer for this cpu is allocated. */
> + if (cpu_file != RING_BUFFER_ALL_CPUS &&
> + !rb_per_cpu_allocated(buffer, cpu_file))
oops, here miss a trace_array_put.
> + return -ENODEV;
> +
> info = kzalloc(sizeof(*info), GFP_KERNEL);
> if (!info) {
> trace_array_put(tr);
> @@ -6563,7 +6575,7 @@ static int tracing_buffers_open(struct inode *inode,
> struct file *filp)
> mutex_lock(&trace_types_lock);
>
> info->iter.tr = tr;
> - info->iter.cpu_file = tracing_get_cpu(inode);
> + info->iter.cpu_file = cpu_file;
> info->iter.trace= tr->current_trace;
> info->iter.trace_buffer = &tr->trace_buffer;
> info->spare = NULL;
> --
> 1.8.3.1
>
Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization
On Mon, Jul 24, 2017 at 10:06:09AM +0200, Luca Abeni wrote:
> > Yes, grouping all the flags in a single field was my intention too... I
> > planned to submit a patch to do this after merging the reclaiming
> > patches... But maybe it is better to do this first :)
>
> I implemented this change, but before submitting the patch I have a
> small question.
> I implemented some helpers to access the various
> {throttled,boosted,yielded,non_contending} flags. I have some
> "dl_{throttled,boosted,...}()" inline functions for reading the values
> of the flags, and some inline functions for setting / clearing the
> flags. For these, I have two possibilities:
> - using two separate "dl_set_{throttled,...}()" and
> "dl_clear_{throttled,..}()" functions for each flag
> - using one single "dl_set_{throttled,...}(dl, value)" function per
> flag, in which the flag's value is specified.
>
> I have no preferences (with the first proposal, I introduce more inline
> functions, but I think the functions can be made more efficient /
> optimized). Which one of the two proposals is preferred? (or, there is
> a third, better, idea that I overlooked?)
- Use bitfields and let the compiler sort it out.
- Use macros to generate all the inlines as per the first.
Personally, because I'm lazy, I'd try the bitfield thing first and see
what kind code that generates. If that's not too horrendous, keep it :-)
[PATCH] ASoC: max98090 - Expose HP out enable.
From: Hsin-Yu Chao
Expose the headphone output enables to user space. This will allow
userspace to ensure that there is stable output before the headphones
are turned on, avoiding a pop on insertion.
Signed-off-by: Hsin-Yu Chao
Signed-off-by: Enric Balletbo i Serra
---
sound/soc/codecs/max98090.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index 6682848..f38c051 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -1074,6 +1074,15 @@ static SOC_ENUM_SINGLE_DECL(mixhprsel_mux_enum,
static const struct snd_kcontrol_new max98090_mixhprsel_mux =
SOC_DAPM_ENUM("MIXHPRSEL Mux", mixhprsel_mux_enum);
+/* HP output enables. */
+static const struct snd_kcontrol_new max98090_hpl_enable =
+ SOC_DAPM_SINGLE("Switch", M98090_REG_OUTPUT_ENABLE,
+ M98090_HPLEN_SHIFT, 1, 0);
+
+static const struct snd_kcontrol_new max98090_hpr_enable =
+ SOC_DAPM_SINGLE("Switch", M98090_REG_OUTPUT_ENABLE,
+ M98090_HPREN_SHIFT, 1, 0);
+
static const struct snd_soc_dapm_widget max98090_dapm_widgets[] = {
SND_SOC_DAPM_INPUT("MIC1"),
SND_SOC_DAPM_INPUT("MIC2"),
@@ -1218,10 +1227,10 @@ static const struct snd_soc_dapm_widget
max98090_dapm_widgets[] = {
SND_SOC_DAPM_MUX("MIXHPRSEL Mux", M98090_REG_HP_CONTROL,
M98090_MIXHPRSEL_SHIFT, 0, &max98090_mixhprsel_mux),
- SND_SOC_DAPM_PGA("HP Left Out", M98090_REG_OUTPUT_ENABLE,
- M98090_HPLEN_SHIFT, 0, NULL, 0),
- SND_SOC_DAPM_PGA("HP Right Out", M98090_REG_OUTPUT_ENABLE,
- M98090_HPREN_SHIFT, 0, NULL, 0),
+ SND_SOC_DAPM_SWITCH("HP Left Out", SND_SOC_NOPM, 0, 0,
+ &max98090_hpl_enable),
+ SND_SOC_DAPM_SWITCH("HP Right Out", SND_SOC_NOPM, 0, 0,
+ &max98090_hpr_enable),
SND_SOC_DAPM_PGA("SPK Left Out", M98090_REG_OUTPUT_ENABLE,
M98090_SPLEN_SHIFT, 0, NULL, 0),
@@ -1405,8 +1414,8 @@ static const struct snd_soc_dapm_route
max98090_dapm_routes[] = {
* Disable this for lowest power if bypassing
* the DAC with an analog signal
*/
- {"HP Left Out", NULL, "DACL"},
- {"HP Left Out", NULL, "MIXHPLSEL Mux"},
+ {"HP Left Out", "Switch", "DACL"},
+ {"HP Left Out", "Switch", "MIXHPLSEL Mux"},
{"MIXHPRSEL Mux", "HP Mixer", "Right Headphone Mixer"},
@@ -1414,8 +1423,8 @@ static const struct snd_soc_dapm_route
max98090_dapm_routes[] = {
* Disable this for lowest power if bypassing
* the DAC with an analog signal
*/
- {"HP Right Out", NULL, "DACR"},
- {"HP Right Out", NULL, "MIXHPRSEL Mux"},
+ {"HP Right Out", "Switch", "DACR"},
+ {"HP Right Out", "Switch", "MIXHPRSEL Mux"},
{"SPK Left Out", NULL, "Left Speaker Mixer"},
{"SPK Right Out", NULL, "Right Speaker Mixer"},
--
2.9.3
Re: [PATCH v7 3/3] x86/refcount: Implement fast refcount overflow protection
* Kees Cook wrote:
> +config ARCH_HAS_REFCOUNT
> + bool
> + help
> + An architecture selects this when it has implemented refcount_t
> + using primitizes that provide a faster runtime at the expense
> + of some full refcount state checks. The refcount overflow condition,
> + however, must be retained. Catching overflows is the primary
> + security concern for protecting against bugs in reference counts.
s/primitizes/primitives
also, the 'faster runtime' and the whole explanation reads a bit weird to me,
how about something like:
An architecture selects this when it has implemented refcount_t
using open coded assembly primitives that provide an optimized
refcount_t implementation, possibly at the expense of some full
refcount state checks of CONFIG_REFCOUNT_FULL=y.
The refcount overflow check behavior, however, must be retained.
Catching overflows is the primary security concern for protecting
against bugs in reference counts.
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -55,6 +55,7 @@ config X86
> select ARCH_HAS_KCOVif X86_64
> select ARCH_HAS_MMIO_FLUSH
> select ARCH_HAS_PMEM_APIif X86_64
> + select ARCH_HAS_REFCOUNT
> select ARCH_HAS_UACCESS_FLUSHCACHE if X86_64
> select ARCH_HAS_SET_MEMORY
> select ARCH_HAS_SG_CHAIN
Just wonderin, how was the 32-bit kernel tested?
> +/*
> + * Body of refcount error handling: in .text.unlikely, saved into CX the
> + * address of the refcount that has entered a bad state, and trigger an
> + * exception. Fixup address is back in regular execution flow in .text.
I had to read this 4 times to parse it (and even now I'm unsure whether I
parsed
it correctly) - could this explanation be transformed to simpler, more
straightforward English?
> + */
> +#define _REFCOUNT_EXCEPTION \
> + ".pushsection .text.unlikely\n" \
> + "111:\tlea %[counter], %%" _ASM_CX "\n" \
> + "112:\t" ASM_UD0 "\n" \
> + ASM_UNREACHABLE \
> + ".popsection\n" \
> + "113:\n"\
> + _ASM_EXTABLE_REFCOUNT(112b, 113b)
Would it be technically possible to use named labels instead of these random
numbered labels?
> + /*
> + * This function has been called because either a negative refcount
> + * value was seen by any of the refcount functions, or a zero
> + * refcount value was seen by refcount_dec().
> + *
> + * If we crossed from INT_MAX to INT_MIN, the OF flag (result
> + * wrapped around) will be set. Additionally, seeing the refcount
> + * reach 0 will set the ZF flag. In each of these cases we want a
> + * report, since it's a boundary condition.
Small nit: 'ZF' stands for 'zero flag' - so we should either write 'zero flag'
or
'ZF' - 'ZF flag' is kind of redundant.
> +#else
> +static inline void refcount_error_report(struct pt_regs *regs,
> + const char *msg) { }
By now you should know that for x86 code you should not break lines in such an
ugly fashion, right? :-)
Thanks,
Ingo
Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization
On Mon, Jul 24, 2017 at 09:54:54AM +0200, Luca Abeni wrote: > Hi Peter, > > I put this change in a local tree together with other fixes / cleanups > I plan to submit in the next weeks. Should I send it together with the > other patches, or are you going to apply it separately? Posting them in a series is fine; it is customary to put independent things first such that they will not get stuck after the larger changes. > In the first case, what is the correct authorship / SOB chain (I ask > because I keep getting this wrong every time :) Yes, this is a 'fun' case :-) I'd just merge the change into your patch introducing it and forget I 'contributed' the name change. For larger patches you could do something like (in your email body): From: Peter Zijlstra Changelog goes here... Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Luca... --- $PATCH Which says this patch is from me, carried by you, and then I'll stick another SoB on to indicated I took it back. Its a bit weird, but we've done it before.
Re: [PATCH 4.12 00/84] 4.12.3-stable review
On Sat, 2017-07-22 at 08:47 -0700, Kevin Hilman wrote: > + Sjoerd @ Collabora > > Shuah Khan writes: > > > On 07/19/2017 10:29 AM, kernelci.org bot wrote: > > > stable-rc/linux-4.12.y boot: 166 boots: 5 failed, 161 passed > > > (v4.12.2-85-g908a8d27d1c5) > > > > > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/br > > > anch/linux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/ > > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/l > > > inux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/ > > > > > > Tree: stable-rc > > > Branch: linux-4.12.y > > > Git Describe: v4.12.2-85-g908a8d27d1c5 > > > Git Commit: 908a8d27d1c52aaafab80d7267e8e61f9a174ecc > > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/li > > > nux-stable-rc.git > > > Tested: 44 unique boards, 14 SoC families, 24 builds out of 204 > > > > > > Boot Regressions Detected: > > > > > > arm: > > > > > > multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: > > > exynos5422-odroidxu3: > > > lab-collabora: new failure (last pass: v4.12.2) > > > > I am seeing boot failure on odroid-xu4 with 4.13-rc1 with > > exynos_defconfig. > > 4.12 is fine. > > > > I am debugging this and based on this report it sounds like it > > might be > > easier for me to start with 4.12 and try to isolate the change. > > Will keep > > you posted. > > I suspect that these CONFIG_PROVE_LOCKING=y issues are actually not > kernel issues directly, but kernel size limitations based on the load > addresses used in lab-collabora LAVA. > > Comparing against my lab, I'm using load address: 0x4200 where as > lab-collabora is using 0x4100. I'm wondering if that is not > enough > room to ucompress down to the default boot address without > overwriting itself? Adjusting the load address for XU3 resolved the boot failure (changing from memory start + 16M to memory start + 32M which is the default for that board in u-boot/lava as well these days) > I suspect the same problem in the lab-collabora panda boots since the > load address differes from mine in the same way. Correct, tuning the load addresses there results in a happy boot. The kernel does relocate itself on boot if it detects decompression will overwrite itself. On the panda though that seemingly meant the dtb got overwritten, just bumping that out of the way made it boot as well. I didn't check if the same happened on XU3 (which has/had far more space between the kernel and the dtb).. That said, it's far safer (and faster) to avoid running into that corner case :) > @Sjoerd: can someone in lab-collabora maybe have a closer look? > > Kevin -- Sjoerd Simons Collabora Ltd.
Re: [PATCH 2/7] memory: atmel-ebi: Simplify SMC config code
Hello Boris,
while testing v4.13-rc2 on an at91sam9g20 baed platform I'm coming back
to this topic. Meanwhile the whole new SMC and NAND below EBI stuff is
in mainline, this TDF bug however is still in there. See below (all
quoted code parts from v4.13-rc2):
Am Donnerstag, 2. März 2017, 13:30:13 schrieb Boris Brezillon:
> Alexander Dahl wrote:
> > #define ATMEL_SMC_MODE_TDF(x) (((x) - 1) << 16)
[…]
> > The hardware manual (AT91SAM9G20) says values from 0 to 15 (4bit,
> > 0x0 to 0xF) are possible and I guess the goal is to set it to a
> > value corresponding to the value in ns from the dts or to 15 if
> > it's greater (or -EINVAL in the new version).
> >
> > However how can one set it to zero? Put in zero to the div you get
> > zero for ncycles or val and that goes as x into (((x) - 1) << 16)
> > which results in 0xF ending up as TDF_CYCLES in the mode register,
> > right?
>
> Indeed.
>
> > I can of course set a slightly greater value, which ends up in a
> > calculated register value of zero, but that seems more a hack to me
> > and is not obvious if I just look at the DTS.
>
> No, we should fix the bug.
>
> > If I'm right this might be topic of another bugfix patch, or should
> > it be done right in a v2 of this one?
>
> It should be done right in a v2. Something like:
>
> if (ncycles < ATMEL_SMC_MODE_TDF_MIN)
> ncycles = ATMEL_SMC_MODE_TDF_MIN;
>
> with
>
> #define ATMEL_SMC_MODE_TDF_MIN 1
I checked the SAMA5D3x datasheet today and it has the same mode register
layout regarding the TDF parts. So allowed are register values from 0 to
15 ending up in 0 to 15 clock cycles of Data Float Time.
The code in include/linux/mfd/syscon/atmel-smc.h is this:
#define ATMEL_SMC_MODE_TDF_MASK GENMASK(19, 16)
#define ATMEL_SMC_MODE_TDF(x) (((x) - 1) << 16)
#define ATMEL_SMC_MODE_TDF_MAX 16
#define ATMEL_SMC_MODE_TDF_MIN 1
#define ATMEL_SMC_MODE_TDFMODE_OPTIMIZEDBIT(20)
This ATMEL_SMC_MODE_TDF() is used in drivers/memory/atmel-ebi.c to setup
the external memory interface with timings from dts. A line there inside
an ebi node may look like this (see for example
arch/arm/boot/dts/sama5d3xcm.dtsi):
atmel,smc-tdf-ns = <0>;
The value is expected in nanoseconds and I would expect a direct mapping
from 0ns to a register value of 0. This is not the case in code
(drivers/memory/atmel-ebi.c):
if (ncycles > ATMEL_SMC_MODE_TDF_MAX ||
ncycles < ATMEL_SMC_MODE_TDF_MIN) {
ret = -EINVAL;
goto out;
}
ATMEL_SMC_MODE_TDF_MIN is 1, so a possible 0 value from dts is not
allowed in here and atmel_ebi_xslate_smc_timings() fails. In fact to get
a register value of 0 for 0 TDF clock cycles I would have to set e.g.
8ns in dts. So this didn't make it in some v2 and is still broken.
I could fix this and provide a patch, but I'm not sure about the second
place where ATMEL_SMC_MODE_TDF() is used which is the NAND driver in
drivers/mtd/nand/atmel/nand-controller.c. I'm not familiar enough with
NAND to judge if this "min = 1, max = 16, decrease by 1 for applying to
register" approach is needed there. I would say no, because it also is a
counterintuitive offset, but I would prefer a explanation why the code
is like this, before touching and breaking anything. ;-)
Greets
Alex
[PATCH] f2fs: record quota during dot{,dot} recovery
In ->lookup(), we will have a try to recover dot or dotdot for corrupted directory, once disk quota is on, if it allocates new block during dotdot recovery, we need to record disk quota info for the allocation, so this patch fixes this issue by adding missing dquot_initialize() in __recover_dot_dentries. Signed-off-by: Chao Yu --- fs/f2fs/namei.c | 4 1 file changed, 4 insertions(+) diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c index 2e3552d9d6ee..08c1d3767f22 100644 --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -289,6 +289,10 @@ static int __recover_dot_dentries(struct inode *dir, nid_t pino) return 0; } + err = dquot_initialize(dir); + if (err) + return err; + f2fs_balance_fs(sbi, true); f2fs_lock_op(sbi); -- 2.13.1.388.g69e6b9b4f4a9
Re: [PATCH] usb: dwc3: Support the dwc3 host suspend/resume
Hi Manu,
On 24 July 2017 at 16:42, Manu Gautam wrote:
> Hi Baolin,
>
>
> On 7/24/2017 11:26 AM, Baolin Wang wrote:
>
> Other than what I pushed in my patch -
> ("usb: dwc3: Don't reinitialize core during host bus-suspend/resume")
> Just performing pm_request_resume or handling same in dwc3 glue
> driver should be sufficient.
Yes.
> Also, what is trigger for runtime_resume for your platform?
In our platform glue layer, we have extcon events to notify there are
devices connected, then gule layer will resume dwc3 device.
>>> IMO you can just perform resume of &dwc->xhci->dev instead of resuming dwc3.
>>> Since, dwc3 is parent of xhci that will trigger resume of dwc3 as well.
>> I am not sure this is good enough but it seems can solve some
>> problems, then we do not need resume/suspend host in dwc3 core.
>
> In that case can we proceed with this patch:
> [1] https://www.spinics.net/lists/linux-usb/msg158682.html
>
> For your platform you can pick this patch and resume dwc->xhci->dev resume
> from your glue driver.
> Do you have any other concerns?
The same concern I explained in your patch. If we power off the
controller when suspend, how can controller work well as host if we do
not issue dwc3_core_init()? Suppose below cases:
device attached: resume glue layer (power on dwc3 controller) --->
resume dwc3 device ---> resume xHCI device
no device attached: suspend xHCI device ---> suspend dwc3 device --->
suspend glue layer (we can power off the dwc3 controller now)
Though now there are no upstreamed glue drivers will power off dwc3
controller, should we consider this situation?
--
Baolin.wang
Best Regards
Re: Is it possible to use ftrace to measure secondary CPU bootup time
On Mon, 24 Jul 2017 13:46:07 +0800 "Huang\, Ying" wrote: > Hi, Steven, > > We are working on parallelizing secondary CPU bootup. So we need to > measure the bootup time of secondary CPU, that is, measure time spent in > smp_init() and its callees. But we found that ftrace now doesn't > support measure time spent in smp_init() because it is called too early > (before core_initcall()?). So, do you think it is possible to use > ftrace to measure secondary CPU bootup time? One could trace with function tracing that early, but that wont give you the timings you are looking for. The best it probably could do is to look at the function timestamps of what is called after smp_init. That is, trace smp_init() and sched_init_smp() and take the difference. Function graph tracing (which is what you are probably looking for) is much more heavy weight than function tracing. It requires some setup that isn't ready that early. Although, I'm sure I can work to get it there, but it's not trivial. -- Steve
[PATCH v2] kmemleak: add oom= runtime parameter
From: Shu Wang
When running memory stress tests, kmemleak could be easily disabled in
function create_object as system is out of memory and kmemleak failed to
alloc from object_cache. Since there's no way to enable kmemleak after
it's off, simply ignore the object_cache alloc failure will just loses
track of some memory objects, but could increase the usability of kmemleak
under memory stress.
The default action for oom is still disable kmemleak,
echo oom=ignore > /sys/kernel/debug/kmemleak can change to action to
ignore oom.
Signed-off-by: Shu Wang
---
Documentation/dev-tools/kmemleak.rst | 5 +
mm/kmemleak.c| 10 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/dev-tools/kmemleak.rst
b/Documentation/dev-tools/kmemleak.rst
index cb88626..3013809 100644
--- a/Documentation/dev-tools/kmemleak.rst
+++ b/Documentation/dev-tools/kmemleak.rst
@@ -60,6 +60,11 @@ Memory scanning parameters can be modified at run-time by
writing to the
or free all kmemleak objects if kmemleak has been disabled.
- dump=
dump information about the object found at
+- oom=disable
+disable kmemleak after system out of memory (default)
+- oom=ignore
+do not disable kmemleak after system out of memory
+(useful for memory stress test, but will lose some objects)
Kmemleak can also be disabled at boot-time by passing ``kmemleak=off`` on
the kernel command line.
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 7780cd8..b5cb2c6 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -236,6 +236,9 @@ static DEFINE_MUTEX(scan_mutex);
static int kmemleak_skip_disable;
/* If there are leaks that can be reported */
static bool kmemleak_found_leaks;
+/* If disable kmemleak after out of memory */
+static bool kmemleak_oom_disable = true;
+
/*
* Early object allocation/freeing logging. Kmemleak is initialized after the
@@ -556,7 +559,8 @@ static struct kmemleak_object *create_object(unsigned long
ptr, size_t size,
object = kmem_cache_alloc(object_cache, gfp_kmemleak_mask(gfp));
if (!object) {
pr_warn("Cannot allocate a kmemleak_object structure\n");
- kmemleak_disable();
+ if (kmemleak_oom_disable)
+ kmemleak_disable();
return NULL;
}
@@ -1888,6 +1892,10 @@ static ssize_t kmemleak_write(struct file *file, const
char __user *user_buf,
kmemleak_scan();
else if (strncmp(buf, "dump=", 5) == 0)
ret = dump_str_object_info(buf + 5);
+ else if (strncmp(buf, "oom=ignore", 10) == 0)
+ kmemleak_oom_disable = false;
+ else if (strncmp(buf, "oom=disable", 11) == 0)
+ kmemleak_oom_disable = true;
else
ret = -EINVAL;
--
2.5.0
Re: [PATCH 2/4] ACPI: Make acpi_dev_get_resources() method agnostic
On Sat, Jul 22, 2017 at 12:05:39AM +0200, Rafael J. Wysocki wrote: > On Thursday, July 20, 2017 03:45:14 PM Lorenzo Pieralisi wrote: > > The function acpi_dev_get_resources() is completely generic and > > can be used to parse resource objects that are not necessarily > > coming from the _CRS method but also from other objects eg _DMA > > that have the same _CRS resource format. > > > > Create an acpi_dev_get_resources() helper, internal to the ACPI > > resources parsing compilation unit, acpi_dev_get_resources_method(), > > that takes a char* parameter to detect which ACPI method should be > > called to retrieve the resources list and make acpi_dev_get_resources() > > call it with a method name _CRS leaving the API behaviour unchanged. > > > > Signed-off-by: Lorenzo Pieralisi > > Cc: "Rafael J. Wysocki" > > --- > > drivers/acpi/resource.c | 54 > > + > > 1 file changed, 32 insertions(+), 22 deletions(-) > > > > diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c > > index cd4c427..2b20a09 100644 > > --- a/drivers/acpi/resource.c > > +++ b/drivers/acpi/resource.c > > @@ -573,6 +573,36 @@ static acpi_status acpi_dev_process_resource(struct > > acpi_resource *ares, > > return AE_OK; > > } > > > > +static > > +int acpi_dev_get_resources_method(struct acpi_device *adev, > > Do not break lines like this, please. > > It should be > > static int acpi_dev_get... > > Also I would call it differently, maybe simply __acpi_dev_get_resources()? Ok, it was how I wanted to call it but was not sure you would be happy with it, I will rename it. > > + struct list_head *list, > > + int (*preproc)(struct acpi_resource *, void > > *), > > + void *preproc_data, char *method) > > const char *method ? Yes, will update. Thanks ! Lorenzo
Re: [PATCH 2/2] platform/x86: alienware-wmi: fix format string overflow warning
On Thu, Jul 20, 2017 at 7:00 PM, Arnd Bergmann wrote:
> gcc points out a possible format string overflow for a large value of 'zone':
>
> drivers/platform/x86/alienware-wmi.c: In function 'alienware_wmi_init':
> drivers/platform/x86/alienware-wmi.c:461:24: error: '%02X' directive writing
> between 2 and 8 bytes into a region of size 6 [-Werror=format-overflow=]
>sprintf(buffer, "zone%02X", i);
> ^~~~
> drivers/platform/x86/alienware-wmi.c:461:19: note: directive argument in the
> range [0, 2147483646]
>sprintf(buffer, "zone%02X", i);
>^~
> drivers/platform/x86/alienware-wmi.c:461:3: note: 'sprintf' output between 7
> and 13 bytes into a destination of size 10
>
> This replaces the 'int' variable with an 'u8' to make sure
> it always fits, renaming the variable to 'zone' for clarity.
>
> Unfortunately, gcc-7.1.1 still warns about it with that change, which
> seems to be unintended by the gcc developers. I have opened a bug
> against gcc with a reduced test case. As a workaround, I also
> change the format string to use "%02hhX", which shuts up the
> warning in that version.
>
Thanks, pushed to testing with slight change (+ empty lines after u8
zone; where it's applicable).
I'm not going to move this to fixes queue since it looks to me not
critical at all. Drop me a message if you think otherwise.
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81483
> Link: https://patchwork.ozlabs.org/patch/788415/
> Suggested-by: Andy Shevchenko
> Signed-off-by: Arnd Bergmann
> ---
> v2: completely rewrite the patch after discussing with Andy
> ---
> drivers/platform/x86/alienware-wmi.c | 38
> ++--
> 1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/platform/x86/alienware-wmi.c
> b/drivers/platform/x86/alienware-wmi.c
> index 0831b428c217..c56a9ecba959 100644
> --- a/drivers/platform/x86/alienware-wmi.c
> +++ b/drivers/platform/x86/alienware-wmi.c
> @@ -255,12 +255,12 @@ static int parse_rgb(const char *buf, struct
> platform_zone *zone)
>
> static struct platform_zone *match_zone(struct device_attribute *attr)
> {
> - int i;
> - for (i = 0; i < quirks->num_zones; i++) {
> - if ((struct device_attribute *)zone_data[i].attr == attr) {
> + u8 zone;
> + for (zone = 0; zone < quirks->num_zones; zone++) {
> + if ((struct device_attribute *)zone_data[zone].attr == attr) {
> pr_debug("alienware-wmi: matched zone location: %d\n",
> -zone_data[i].location);
> - return &zone_data[i];
> +zone_data[zone].location);
> + return &zone_data[zone];
> }
> }
> return NULL;
> @@ -420,7 +420,7 @@ static DEVICE_ATTR(lighting_control_state, 0644,
> show_control_state,
>
> static int alienware_zone_init(struct platform_device *dev)
> {
> - int i;
> + u8 zone;
> char buffer[10];
> char *name;
>
> @@ -457,19 +457,19 @@ static int alienware_zone_init(struct platform_device
> *dev)
> if (!zone_data)
> return -ENOMEM;
>
> - for (i = 0; i < quirks->num_zones; i++) {
> - sprintf(buffer, "zone%02X", i);
> + for (zone = 0; zone < quirks->num_zones; zone++) {
> + sprintf(buffer, "zone%02hhX", zone);
> name = kstrdup(buffer, GFP_KERNEL);
> if (name == NULL)
> return 1;
> - sysfs_attr_init(&zone_dev_attrs[i].attr);
> - zone_dev_attrs[i].attr.name = name;
> - zone_dev_attrs[i].attr.mode = 0644;
> - zone_dev_attrs[i].show = zone_show;
> - zone_dev_attrs[i].store = zone_set;
> - zone_data[i].location = i;
> - zone_attrs[i] = &zone_dev_attrs[i].attr;
> - zone_data[i].attr = &zone_dev_attrs[i];
> + sysfs_attr_init(&zone_dev_attrs[zone].attr);
> + zone_dev_attrs[zone].attr.name = name;
> + zone_dev_attrs[zone].attr.mode = 0644;
> + zone_dev_attrs[zone].show = zone_show;
> + zone_dev_attrs[zone].store = zone_set;
> + zone_data[zone].location = zone;
> + zone_attrs[zone] = &zone_dev_attrs[zone].attr;
> + zone_data[zone].attr = &zone_dev_attrs[zone];
> }
> zone_attrs[quirks->num_zones] = &dev_attr_lighting_control_state.attr;
> zone_attribute_group.attrs = zone_attrs;
> @@ -484,9 +484,9 @@ static void alienware_zone_exit(struct platform_device
> *dev)
> sysfs_remove_group(&dev->dev.kobj, &zone_attribute_group);
> led_classdev_unregister(&global_led);
> if (zone_dev_attrs) {
> - int i;
> - for (i = 0; i < quirks->num_zones; i++)
> - kfree(zone_dev_attrs[i
Re: [PATCH] f2fs: let __get_victim successfully get a segno in corner case
Hi Jay,
fggc_threshold is 507, reserved_segment is 462.
On 2017/7/22 5:07, Jaegeuk Kim wrote:
Hi Yunlong,
On 07/20, Yunlong Song wrote:
Hi, Jay,
The distribution is like this, unit is segment counts:
cnt_free: 0 (free blocks)
cnt_full: 25182 (segment which has 512 blocks)
cnt_over: 25192 (segment which valid blocks over fggc_threshold)
cnt_below: 870 (segment which valid blocks below fggc_threshold)
What are the values of fggc_threshold and ovp ratio or reserved_segments?
How was the proc/segment_info?
Thanks,
The test is fragment test, add and delete small files over and over.
On 2017/7/18 0:56, Jaegeuk Kim wrote:
On 07/16, sylinux wrote:
In fact，this is not "suppose" case yet, we have already met this problem
several times in some test suits for corner case, or I cannot notice that this could
happen.
So, have you taken a look at distribution of valid blocks in that case?
I'm wondering what distribution can cause this.
Thanks,
发自网易邮箱大师
On 07/16/2017 09:09, Jaegeuk Kim wrote:
Hi Yunlong,
On 07/14, Yunlong Song wrote:
Suppose that the valid blocks of each section are all over sbi->fggc_threshold,
How about adding a kernel message first to detect your *supposed* sceanrio?
If that happens, it'll be a sort of bug which we haven't assumed.
Thanks,
and even has_not_enough_free_secs is true, f2fs_gc cannot do its job since the
no_fggc_candidate always returns true. As a result, the reserved segments can be
used up, and finally there is no free segment at all, and get_new_segment cannot
get a free segment, filesystem will trap into a wrong status.
To fix this, we record the segno which has a rough minimum cost and return it to
__get_victim to continue f2fs_gc's job.
Signed-off-by: Yunlong Song
---
fs/f2fs/gc.c | 19 ++-
fs/f2fs/segment.h | 17 ++---
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index fa3d2e2..965e783 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -178,6 +178,8 @@ static void select_policy(struct f2fs_sb_info *sbi, int
gc_type,
p->offset = 0;
else
p->offset = SIT_I(sbi)->last_victim[p->gc_mode];
+
+p->min_cost_r = UINT_MAX;
}
static unsigned int get_max_cost(struct f2fs_sb_info *sbi,
@@ -194,7 +196,7 @@ static unsigned int get_max_cost(struct f2fs_sb_info *sbi,
return 0;
}
-static unsigned int check_bg_victims(struct f2fs_sb_info *sbi)
+static unsigned int check_bg_victims(struct f2fs_sb_info *sbi, struct
victim_sel_policy *p)
{
struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
unsigned int secno;
@@ -208,11 +210,12 @@ static unsigned int check_bg_victims(struct f2fs_sb_info
*sbi)
if (sec_usage_check(sbi, secno))
continue;
-if (no_fggc_candidate(sbi, secno))
+p->cur_segno_r = GET_SEG_FROM_SEC(sbi, secno);
+if (no_fggc_candidate(sbi, secno, p))
continue;
clear_bit(secno, dirty_i->victim_secmap);
-return GET_SEG_FROM_SEC(sbi, secno);
+return p->cur_segno_r;
}
return NULL_SEGNO;
}
@@ -332,7 +335,7 @@ static int get_victim_by_default(struct f2fs_sb_info *sbi,
last_victim = sm->last_victim[p.gc_mode];
if (p.alloc_mode == LFS && gc_type == FG_GC) {
-p.min_segno = check_bg_victims(sbi);
+p.min_segno = check_bg_victims(sbi, &p);
if (p.min_segno != NULL_SEGNO)
goto got_it;
}
@@ -369,8 +372,9 @@ static int get_victim_by_default(struct f2fs_sb_info *sbi,
goto next;
if (gc_type == BG_GC && test_bit(secno, dirty_i->victim_secmap))
goto next;
+p.cur_segno_r = segno;
if (gc_type == FG_GC && p.alloc_mode == LFS &&
-no_fggc_candidate(sbi, secno))
+no_fggc_candidate(sbi, secno, &p))
goto next;
cost = get_gc_cost(sbi, segno, &p);
@@ -403,6 +407,11 @@ static int get_victim_by_default(struct f2fs_sb_info *sbi,
trace_f2fs_get_victim(sbi->sb, type, gc_type, &p,
sbi->cur_victim_sec,
prefree_segments(sbi), free_segments(sbi));
+} else if (has_not_enough_free_secs(sbi, 0, 0)) {
+p.min_segno = p.min_segno_r;
+if (p.alloc_mode == LFS && gc_type == FG_GC)
+clear_bit(GET_SEC_FROM_SEG(sbi, p.min_segno),
dirty_i->victim_secmap);
+goto got_it;
}
out:
mutex_unlock(&dirty_i->seglist_lock);
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 6b871b4..7d2d0f3 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -169,6 +169,9 @@ struct victim_sel_policy {
unsigned int ofs_unit;/* bitmap search unit */
unsigned int min_cost;/* minimum cost */
unsigned int min_segno;/* segment # having min. cost */
+unsigned int min_cost_r;/* rough minimum cost */
+unsigned int min_segno_
[PATCH v4 1/2] x86/amd: Refactor topology extension related code
From: Borislav Petkov
Refactoring in preparation for subsequent changes.
There is no functional change.
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/kernel/cpu/amd.c | 78 ++-
1 file changed, 44 insertions(+), 34 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index bb5abe8..a2a52b5 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -296,13 +296,55 @@ static int nearby_node(int apicid)
}
#endif
+#ifdef CONFIG_SMP
+
+/*
+ * Get topology information via X86_FEATURE_TOPOEXT.
+ */
+static void __get_topoext(struct cpuinfo_x86 *c, int cpu)
+{
+ u32 eax, ebx, ecx, edx;
+ u8 node_id;
+
+ cpuid(0x801e, &eax, &ebx, &ecx, &edx);
+
+ node_id = ecx & 0xff;
+ smp_num_siblings = ((ebx >> 8) & 0xff) + 1;
+
+ if (c->x86 == 0x15)
+ c->cu_id = ebx & 0xff;
+
+ if (c->x86 >= 0x17) {
+ c->cpu_core_id = ebx & 0xff;
+
+ if (smp_num_siblings > 1)
+ c->x86_max_cores /= smp_num_siblings;
+ }
+
+ /*
+* We may have multiple LLCs if L3 caches exist, so check if we
+* have an L3 cache by looking at the L3 cache CPUID leaf.
+*/
+ if (cpuid_edx(0x8006)) {
+ if (c->x86 == 0x17) {
+ /*
+* LLC is at the core complex level.
+* Core complex id is ApicId[3].
+*/
+ per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
+ } else {
+ /* LLC is at the node level. */
+ per_cpu(cpu_llc_id, cpu) = node_id;
+ }
+ }
+}
+
/*
* Fixup core topology information for
* (1) AMD multi-node processors
* Assumption: Number of cores in each internal node is the same.
* (2) AMD processors supporting compute units
*/
-#ifdef CONFIG_SMP
static void amd_get_topology(struct cpuinfo_x86 *c)
{
u8 node_id;
@@ -310,39 +352,7 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
/* get information required for multi-node processors */
if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
- u32 eax, ebx, ecx, edx;
-
- cpuid(0x801e, &eax, &ebx, &ecx, &edx);
-
- node_id = ecx & 0xff;
- smp_num_siblings = ((ebx >> 8) & 0xff) + 1;
-
- if (c->x86 == 0x15)
- c->cu_id = ebx & 0xff;
-
- if (c->x86 >= 0x17) {
- c->cpu_core_id = ebx & 0xff;
-
- if (smp_num_siblings > 1)
- c->x86_max_cores /= smp_num_siblings;
- }
-
- /*
-* We may have multiple LLCs if L3 caches exist, so check if we
-* have an L3 cache by looking at the L3 cache CPUID leaf.
-*/
- if (cpuid_edx(0x8006)) {
- if (c->x86 == 0x17) {
- /*
-* LLC is at the core complex level.
-* Core complex id is ApicId[3].
-*/
- per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
- } else {
- /* LLC is at the node level. */
- per_cpu(cpu_llc_id, cpu) = node_id;
- }
- }
+ __get_topoext(c, cpu);
} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
u64 value;
--
2.7.4
[PATCH v4 0/2] x86/amd: Refactor and fixup family17h cpu_core_id
Changes from V3 (https://lkml.org/lkml/2017/7/24/2) * Use a cleaner version of refactor patch 1/2 from Boris instead. Changes from V2 (https://lkml.org/lkml/2017/7/21/730) * In patch 1/2 * Fix kbuild error for the __get_topoext() due to #ifdef CONFIG_SMP. * Do not move node_id declaration in the refactored function. Changes from V1 (https://lkml.org/lkml/2017/7/20/180) * Refactor topology extension logic into __get_topoext() (per Boris) Borislav Petkov (1): x86/amd: Refactor topology extension related code Suravee Suthikulpanit (1): x86/amd: Fixup cpu_core_id for family17h downcore configuration arch/x86/kernel/cpu/amd.c | 110 -- 1 file changed, 77 insertions(+), 33 deletions(-) -- 2.7.4
[PATCH v4 2/2] x86/amd: Fixup cpu_core_id for family17h downcore configuration
For family17h, current cpu_core_id is directly taken from the value
CPUID_Fn801E_EBX[7:0] (CoreId), which is the physical ID of the
core within a die. However, on system with downcore configuration
(where not all physical cores within a die are available), this could
result in the case where cpu_core_id > (cores_per_node - 1).
Fix up the cpu_core_id by breaking down the bitfields of CoreId,
and calculate relative ID using available topology information.
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/kernel/cpu/amd.c | 74 ++-
1 file changed, 54 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index a2a52b5..b5ea28f 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -305,37 +305,71 @@ static void __get_topoext(struct cpuinfo_x86 *c, int cpu)
{
u32 eax, ebx, ecx, edx;
u8 node_id;
+ u16 l3_nshared = 0;
+
+ if (cpuid_edx(0x8006)) {
+ cpuid_count(0x801d, 3, &eax, &ebx, &ecx, &edx);
+ l3_nshared = ((eax >> 14) & 0xfff) + 1;
+ }
cpuid(0x801e, &eax, &ebx, &ecx, &edx);
node_id = ecx & 0xff;
smp_num_siblings = ((ebx >> 8) & 0xff) + 1;
- if (c->x86 == 0x15)
- c->cu_id = ebx & 0xff;
-
- if (c->x86 >= 0x17) {
- c->cpu_core_id = ebx & 0xff;
-
- if (smp_num_siblings > 1)
- c->x86_max_cores /= smp_num_siblings;
- }
+ switch (c->x86) {
+ case 0x17: {
+ u32 tmp, ccx_offset, cpu_offset;
- /*
-* We may have multiple LLCs if L3 caches exist, so check if we
-* have an L3 cache by looking at the L3 cache CPUID leaf.
-*/
- if (cpuid_edx(0x8006)) {
- if (c->x86 == 0x17) {
+ /*
+* In family 17h, the CPUID_Fn801E_EBX[7:0] (CoreId)
+* is non-contiguous in downcore and non-SMT cases.
+* Fixup the cpu_core_id to be contiguous for cores within
+* the die.
+*/
+ tmp = ebx & 0xff;
+ if (smp_num_siblings == 1) {
/*
-* LLC is at the core complex level.
-* Core complex id is ApicId[3].
+* CoreId bit-encoding for SMT-disabled
+* [7:4] : die
+* [3] : ccx
+* [2:0] : core
*/
- per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
+ ccx_offset = ((tmp >> 3) & 1) * l3_nshared;
+ cpu_offset = tmp & 7;
} else {
- /* LLC is at the node level. */
- per_cpu(cpu_llc_id, cpu) = node_id;
+ /*
+* CoreId bit-encoding for SMT-enabled
+* [7:3] : die
+* [2] : ccx
+* [1:0] : core
+*/
+ ccx_offset = ((tmp >> 2) & 1) * l3_nshared /
+ smp_num_siblings;
+ cpu_offset = tmp & 3;
+ c->x86_max_cores /= smp_num_siblings;
+
}
+ c->cpu_core_id = ccx_offset + cpu_offset;
+
+ /*
+* Family17h L3 cache (LLC) is at Core Complex (CCX).
+* There could be multiple CCXs in a node.
+* CCX ID is ApicId[3].
+*/
+ per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
+
+ pr_debug("Fixup coreid:%#x to cpu_core_id:%#x\n",
+tmp, c->cpu_core_id);
+ break;
+ }
+ case 0x15:
+ c->cu_id = ebx & 0xff;
+ /* Follow through */
+ default:
+ /* LLC is default to L3, which generally per-node */
+ if (l3_nshared > 0)
+ per_cpu(cpu_llc_id, cpu) = node_id;
}
}
--
2.7.4
Re: [PATCH v2 2/2] Telemetry: remove redundant macro definition
On Sat, Jul 22, 2017 at 2:02 AM, Darren Hart wrote: > On Fri, Jul 21, 2017 at 03:29:39AM +, Chakravarty, Souvik K wrote: >> Just missed the email from Darren. > > :-) > >> Reviewed-by: Souvik K Chakravarty > > Thank you Souvik. > > While these one liners are OK for trivial changes like this, please note that > Andy and I depend on individual driver maintainers to provide thorough > reviews, > and it helps to document that review to help us understand what sorts of > things > you considered before approving the patch. Please keep this in mind in the > future for more complex changes. > > This set is on Andy's queue, so the final review/follow-up will come from him. > Pushed both to testing, thanks! > Thanks, > >> >> > -Original Message- >> > From: Chakravarty, Souvik K >> > Sent: Friday, July 21, 2017 8:45 AM >> > To: 'Rajneesh Bhardwaj' ; platform-driver- >> > x...@vger.kernel.org >> > Cc: dvh...@infradead.org; a...@infradead.org; linux- >> > ker...@vger.kernel.org; Murthy, Shanth ; >> > Bhardwaj, Rajneesh >> > Subject: RE: [PATCH v2 2/2] Telemetry: remove redundant macro definition >> > >> > Both set of two looks good. +1. >> > >> > > -Original Message- >> > > From: platform-driver-x86-ow...@vger.kernel.org >> > > [mailto:platform-driver- x86-ow...@vger.kernel.org] On Behalf Of >> > > Rajneesh Bhardwaj >> > > Sent: Thursday, July 20, 2017 7:51 PM >> > > To: platform-driver-...@vger.kernel.org >> > > Cc: dvh...@infradead.org; a...@infradead.org; linux- >> > > ker...@vger.kernel.org; Murthy, Shanth ; >> > > Chakravarty, Souvik K ; Bhardwaj, >> > > Rajneesh >> > > Subject: [PATCH v2 2/2] Telemetry: remove redundant macro definition >> > > >> > > Telemetry driver includes intel_telemetry.h which defines >> > > TELEM_MAX_OS_ALLOCATED_EVENTS already. >> > > >> > > Signed-off-by: Rajneesh Bhardwaj >> > > --- >> > > drivers/platform/x86/intel_telemetry_pltdrv.c | 1 - >> > > 1 file changed, 1 deletion(-) >> > > >> > > diff --git a/drivers/platform/x86/intel_telemetry_pltdrv.c >> > > b/drivers/platform/x86/intel_telemetry_pltdrv.c >> > > index 6393b3b1d5a6..e0424d5a795a 100644 >> > > --- a/drivers/platform/x86/intel_telemetry_pltdrv.c >> > > +++ b/drivers/platform/x86/intel_telemetry_pltdrv.c >> > > @@ -46,7 +46,6 @@ >> > > #define TELEM_SAMPLING_DEFAULT_PERIOD0xD >> > > >> > > #define TELEM_MAX_EVENTS_SRAM28 >> > > -#define TELEM_MAX_OS_ALLOCATED_EVENTS20 >> > > #define TELEM_SSRAM_STARTTIME_OFFSET 8 >> > > #define TELEM_SSRAM_EVTLOG_OFFSET16 >> > > >> > > -- >> > > 2.7.4 >> >> > > -- > Darren Hart > VMware Open Source Technology Center -- With Best Regards, Andy Shevchenko
Re: [PATCH 6/9] mm, page_alloc: simplify zonelist initialization
On 07/21/2017 04:39 PM, Michal Hocko wrote: > From: Michal Hocko > > build_zonelists gradually builds zonelists from the nearest to the most > distant node. As we do not know how many populated zones we will have in > each node we rely on the _zoneref to terminate initialized part of the > zonelist by a NULL zone. While this is functionally correct it is quite > suboptimal because we cannot allow updaters to race with zonelists > users because they could see an empty zonelist and fail the allocation > or hit the OOM killer in the worst case. > > We can do much better, though. We can store the node ordering into an > already existing node_order array and then give this array to > build_zonelists_in_node_order and do the whole initialization at once. > zonelists consumers still might see halfway initialized state but that > should be much more tolerateable because the list will not be empty and > they would either see some zone twice or skip over some zone(s) in the > worst case which shouldn't lead to immediate failures. > > While at it let's simplify build_zonelists_node which is rather > confusing now. It gets an index into the zoneref array and returns > the updated index for the next iteration. Let's rename the function > to build_zonerefs_node to better reflect its purpose and give it > zoneref array to update. The function doesn't the index anymore. It > just returns the number of added zones so that the caller can advance > the zonered array start for the next update. > > This patch alone doesn't introduce any functional change yet, though, it > is merely a preparatory work for later changes. > > Changes since v1 > - build_zonelists_node -> build_zonerefs_node and operate directly on > zonerefs array rather than play tricks with index into the array. > - give build_zonelists_in_node_order nr_nodes to not iterate over all > MAX_NUMNODES as per Mel > > Signed-off-by: Michal Hocko Acked-by: Vlastimil Babka
Re: WARN_ON_ONCE(work > weight) in napi_poll()
On 07/18/2017 09:47 AM, Ryan Hsu wrote:
> On 07/11/2017 06:19 PM, Igor Mitsyanko wrote:
>
>> On 07/11/2017 10:28 AM, Andrey Ryabinin wrote:
>>>
>>> It gave me this:
>>>
>>> [118648.825347] #1 quota too big 72 64 16
>>> [118648.825351] #2 quota too big 72 64 16
>>> [118648.825471] [ cut here ]
>>> [118648.825484] WARNING: CPU: 0 PID: 0 at ../net/core/dev.c:5274
>>> net_rx_action+0x258/0x360
>>>
>>> So this means that we didn't met the condition bellow, i.e.
>>> skb_queue_empty() returned true.
>>>
>>> ath10k_htt_txrx_compl_task():
>>>
>>> if ((quota > ATH10K_NAPI_QUOTA_LIMIT) &&
>>> !skb_queue_empty(&htt->rx_in_ord_compl_q)) {
>>> resched_napi = true;
>>> goto exit;
>>> }
>>>
Also WLAN.RM.2.0-00180-QCARMSWPZ-1 firmware is a bit old, could you also
update firmware to give it a try?
https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0/4.4
>>>
>>> Will try.
>>>
>>
>> Maybe ath10k_htt_rx_in_ord_ind() has to accept "budget_left" parameter and
>> use it to limit number of processed MSDUs in queued AMSDU and saving rest
>> for later (NAPI has to be rescheduled in this case).
>> It seems natural that this problem happens with current logic, in case AMSDU
>> in Rx queue has more elements then left in budget.
>
> Thanks, likely in current logic, it does have chance to exceed the budget
> while dequeuing from the last list.
>
> Can you give it a try this one? for QCA6174 reorder is offload, so this
> should be good enough for your case to test, will have to check non-offload
> reorder case... but let me know if you're seeing something different
>
I've been running with this patch almost a week and haven't seen the WARNING.
One week is usually enough to trigger it several times.
I guess we can assume that the patch fixed the problem.
Re: [PATCH 2/3] thunderbold: use uuid_t instead of uuid_be
On Thu, Jul 20, 2017 at 09:56:23AM +0200, Christoph Hellwig wrote: > Switch thunderbolt to the new uuid type. > > Signed-off-by: Christoph Hellwig You have a typo in $subject: thunderbold -> thunderbolt. Otherwise looks good and still works fine :) Acked-by: Mika Westerberg
Re: A udev rule to serve the change event of ACPI container?
On Mon, Jul 24, 2017 at 10:57:02AM +0200, Michal Hocko wrote: > On Wed 19-07-17 17:09:10, Joey Lee wrote: > > On Mon, Jul 17, 2017 at 11:05:25AM +0200, Michal Hocko wrote: > [...] > > > The problem I have with this expectation is that userspace will never > > > have a good atomic view of the whole container. So it can only try to > > > > I agreed! > > > > Even a userspace application can handle part of offline jobs. It's > > still possible that other kernel/userland compenents are using the > > resource in container. > > > > > eject and then hope that nobody has onlined part of the container. > > > If you emit offline event to the userspace the cleanup can be done and > > > after the last component goes offline then the eject can be done > > > atomically. > > > > The thing that we didn't align is how does kernel maintains the flag > > of ejection state on container. > > Why it cannot be an attribute of the container? The flag would be set > when the eject operation is requested and cleared when either the > operation is successful (all parts offline and eject operation acked > by the BIOS) or it is terminated. > For the success case, yes, we can clear the flag when the _EJ0 of container is success. But for the fail case, we don't know when the operation is terminated. > [...] > > Base on the above figure, if userspace didn't do anything or it > > just performs part of offline jobs. Then the container's [eject] > > state will be always _SET_ there, and kernel will always check > > the the latest child offline state when any child be offlined > > by userspace. > > What is a problem about that? The eject is simply in progress until all > is set. Or maybe I just misunderstood. > I agree, but it's only for success case. For fail case, kernel can not wait forever. Can we? > > > > On the other hand, for retry BIOS, we will apply the same > > _eject_ flag approach on retry BIOS. If the OS performs > > offline/ejection jobs too long then the retry BIOS is finally > > time out. There doesn't have way for OS to aware the timeout. > > Doesn't BIOS notify the OS that the eject has timed out? > No, there doesn't have interface to notify OS for BIOS time out. Thanks a lot! Joey Lee
Re: Kernel BUG at fs/namei.c:248
This bug still occurring on linux-next : 4.13.0-rc2-next-20170724. >>> [ 1245.412625] kernel BUG at >>> /srv/oe/build/tmp-rpb-glibc/work-shared/hikey/kernel-source/fs/namei.c:248! >> >> Interesting... Looks like double-put or memory corruptor of some sort. >> Nothing obvious jumps out at the first glance; I'll look into that when >> I get back to better connectivity tonight. [ 1233.512841] kernel BUG at /srv/oe/build/tmp-rpb-glibc/work-shared/hikey/kernel-source/fs/namei.c:248! zram load module [ 1233.522161] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP successful set m[ 1233.529054] Modules linked in: zram lzo test_printf algif_hash af_alg adv7511 kirin_drm drm_kms_helper dw_drm_dsi drm asix usbnet fuse [last unloaded: zram] [ 1233.544586] CPU: 0 PID: 14163 Comm: systemd-udevd Not tainted 4.13.0-rc2-next-20170724 #1 LAVA test job id, https://lkft.validation.linaro.org/scheduler/job/15352#L3402 > > I am able to reproduce this BUG by running zram test cases multiple > times in a row. > http://people.linaro.org/~naresh.kamboju/zram.tar.gz > > Ref: > LKFT: linux-mainline: Kernel BUG at fs/namei.c:248 > https://bugs.linaro.org/show_bug.cgi?id=3140
Re: [PATCH v2 2/4] dmaengine: Add STM32 MDMA driver
On 07/21/2017 12:32 PM, Pierre Yves MORDRET wrote:
>
>
> On 07/21/2017 11:54 AM, Vinod Koul wrote:
>> On Fri, Jul 21, 2017 at 09:30:00AM +, Pierre Yves MORDRET wrote:
> +static enum dma_slave_buswidth stm32_mdma_get_max_width(u32 buf_len,
> u32
tlen)
> +{
> +enum dma_slave_buswidth max_width = DMA_SLAVE_BUSWIDTH_8_BYTES;
> +
> +while (((buf_len % max_width) || (tlen < max_width)) &&
> + (max_width > DMA_SLAVE_BUSWIDTH_1_BYTE))
> +max_width = max_width >> 1;
ok, this is a bit hard to read...
>>>
>>> This code snippet has already been reworked and optimized. Would you mind
>>> to
>>> provide me a example with your expectation ? Thanks
>>
>> Code is optimized yes, but readable no
>>
>> I would like readability to be improved upon...
>>
>
> gotcha
>
Doest he code snippet below has a better looking for you ?
for (max_width = DMA_SLAVE_BUSWIDTH_8_BYTES;
max_width > DMA_SLAVE_BUSWIDTH_1_BYTE; max_width >>= 1)
if (((buf_len % max_width) == 0) && (tlen >= max_width))
break;
On 07/21/2017 07:17 PM, Vinod Koul wrote:
> On Fri, Jul 21, 2017 at 10:32:49AM +, Pierre Yves MORDRET wrote:
>> +static int stm32_mdma_set_xfer_param(struct stm32_mdma_chan *chan,
>> + enum dma_transfer_direction
>> direction,
>> + u32 *mdma_ccr, u32 *mdma_ctcr,
>> + u32 *mdma_ctbr, u32 buf_len)
>> +{
>> +struct stm32_mdma_device *dmadev = stm32_mdma_get_dev(chan);
>> +struct stm32_mdma_chan_config *chan_config = &chan->chan_config;
>> +enum dma_slave_buswidth src_addr_width, dst_addr_width;
>> +phys_addr_t src_addr, dst_addr;
>> +int src_bus_width, dst_bus_width;
>> +u32 src_maxburst, dst_maxburst, src_best_burst, dst_best_burst;
>> +u32 ccr, ctcr, ctbr, tlen;
>> +
>> +src_addr_width = chan->dma_config.src_addr_width;
>> +dst_addr_width = chan->dma_config.dst_addr_width;
>> +src_maxburst = chan->dma_config.src_maxburst;
>> +dst_maxburst = chan->dma_config.dst_maxburst;
>> +src_addr = chan->dma_config.src_addr;
>> +dst_addr = chan->dma_config.dst_addr;
>
> this doesn't seem right to me, only the periphral address would come from
> slave_config, the memory address is passed as an arg to transfer..
>
> ...
>
Correct. But these locals are managed in the case statement below. if
direction
is Mem2Dev only dst_addr(Peripheral) is considered. In the other way
around with
Dev2Mem direction only src_addr(Peripheral) is considered.
However to disambiguate I can move src_addr & dst_addr affectation in the
corresponding case statement if you'd like.
>>>
>>> But below you are over writing both, so in effect this is wasted cycles..
>>> anyway latter one is more clear, so lets remove from here.
>>>
>>
>> Sorry I don't follow ... or miss something
>> For instance if direction is Mem2Dev ..._xfer_param is going to configure
>> Destination Bus width and Addr given by slave_config. ..._setup_xfer in its
>> turn
>> will configure source given as parameter.
>> Don't the see the over-writing
>
> ah re-looking at it, yes you are right.
>
> The above two assignments threw me off, I should have read it properly.
>
> But I think calculating for src and dstn always might not be optimal as you
> would use one only, so should these be moved to respective case where they
> are used...
>
Agree. This is my planned btw
Thanks
Py.
