Re: [RFC PATCH 1/5] bpf: Put perf_events check ahead of bpf prog
On 2015/7/2 11:50, Alexei Starovoitov wrote: On 6/30/15 7:57 PM, He Kuang wrote: When we add a kprobe point and record events by perf, the execution path of all threads on each cpu will enter this point, but perf may only record events on a particular thread or cpu at this kprobe point, a check on call->perf_events list filters out the threads which perf is not recording. I think there is a better way to do that. You're adding artificial per_cpu filtering whereas you really need per_pid filtering. I think the differences between you and He Kuang is the order of filtering. In He Kuang's view, perf's original filtering mechanism (implicit or explicit) should takes precedence over BPF filter, because what the user want is to filter events with *an additional* BPF filter. So filters should be run by following order: event -> X -> Y -> Z -> BPF filter +-> perf.data | `-> dropped (In the above diagram, X represents limitations which prevent an event to be triggered. For example, kprobe reentering. Y represents implicit filters, like checking of call->perf_events, which is used to filter events from other CPU out (per-pid perf event is also done by it). Z represents explicit filter which is set using PERF_EVENT_IOC_SET_FILTER by user.) So only those events which should be collected by perf without BPF filter should be passed to BPF program. The above is our understanding of ideal BPF filters. Therefore, to create a ideal BPF filter, it should be better to put BPF filters into perf_tp_filter_match(). In current implementation, BPF filters take effects in the middle of kprobe event processing: event -> X -> BPF filter -> Y -> Z +-> perf.data | `-> dropped And this patch changes the ordering to: event -> X -> Y -> BPF filter -> Z +-> perf.data | `-> dropped Both are not ideal, but He Kuang's patch moves BPF filter to correct direction. It uses a relativly lower-cost operation (checking of call->perf_events) to reduce the need of calling BPF filters. I'd like to discuss with you about the correctness of our understanding. Do you have any strong reason to put BPF filters at such an early stage? Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: smp_store_mb() oddity..
On Wed, Jul 01, 2015 at 07:17:55PM +0200, Peter Zijlstra wrote:
> ---
> Subject: locking/arch: Make smp_store_mb() use smp_mb()
>
> Linus noticed that there were a few smp_store_mb() implementations that
> used mb(), which is inconsistent with the new naming.
>
> Since all smp_store_mb() users really are about SMP ordering, not IO
> ordering, change them all to be consistent.
>
> Cc: Tony Luck
> Cc: Benjamin Herrenschmidt
> Cc: Heiko Carstens
> Suggested-by: Linus Torvalds
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> diff --git a/arch/s390/include/asm/barrier.h b/arch/s390/include/asm/barrier.h
> index e6f8615a11eb..a4dea6050c77 100644
> --- a/arch/s390/include/asm/barrier.h
> +++ b/arch/s390/include/asm/barrier.h
> @@ -36,7 +36,7 @@
> #define smp_mb__before_atomic() smp_mb()
> #define smp_mb__after_atomic() smp_mb()
>
> -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value);
> mb(); } while (0)
> +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value);
> smp_mb(); } while (0)
>
> #define smp_store_release(p, v)
> \
for the s390 part:
Acked-by: Heiko Carstens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] powerpc/numa: initialize distance lookup table from drconf path
In some situations, a NUMA guest that supports
ibm,dynamic-memory-reconfiguration node will end up having flat NUMA
distances between nodes. This is because of two problems in the
current code.
1) Different representations of associativity lists.
There is an assumption about the associativity list in
initialize_distance_lookup_table(). Associativity list has two forms:
a) [cpu,memory]@x/ibm,associativity has following
format:
b) ibm,dynamic-reconfiguration-memory/ibm,associativity-lookup-arrays
M = the number of associativity lists
N = the number of entries per associativity list
Fix initialize_distance_lookup_table() so that it does not assume
"case a". And update the caller to skip the length field before
sending the associativity list.
2) Distance table not getting updated from drconf path.
Node distance table will not get initialized in certain cases as
ibm,dynamic-reconfiguration-memory path does not initialize the
lookup table.
Call initialize_distance_lookup_table() from drconf path with
appropriate associativity list.
Reported-by: Bharata B Rao
Signed-off-by: Nikunj A Dadhania
Acked-by: Anton Blanchard
---
* Rebased to mpe/next
* Dropped RFC tag
* Updated commit log
arch/powerpc/mm/numa.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 5e80621..8b9502a 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -225,7 +225,7 @@ static void initialize_distance_lookup_table(int nid,
for (i = 0; i < distance_ref_points_depth; i++) {
const __be32 *entry;
- entry = [be32_to_cpu(distance_ref_points[i])];
+ entry = [be32_to_cpu(distance_ref_points[i]) - 1];
distance_lookup_table[nid][i] = of_read_number(entry, 1);
}
}
@@ -248,8 +248,12 @@ static int associativity_to_nid(const __be32
*associativity)
nid = -1;
if (nid > 0 &&
- of_read_number(associativity, 1) >= distance_ref_points_depth)
- initialize_distance_lookup_table(nid, associativity);
+ of_read_number(associativity, 1) >= distance_ref_points_depth) {
+ /*
+* Skip the length field and send start of associativity array
+*/
+ initialize_distance_lookup_table(nid, associativity + 1);
+ }
out:
return nid;
@@ -507,6 +511,12 @@ static int of_drconf_to_nid_single(struct of_drconf_cell
*drmem,
if (nid == 0x || nid >= MAX_NUMNODES)
nid = default_nid;
+
+ if (nid > 0) {
+ index = drmem->aa_index * aa->array_sz;
+ initialize_distance_lookup_table(nid,
+ >arrays[index]);
+ }
}
return nid;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jul 2
Hi all, Please do not add any v4.3 related material to your linux-next included branches until after v4.2-rc1 is released. Changes since 20150701: The kbuild tree gained a conflict against Linus' tree. I dropped a patch from the akpm tree since the commit it was fixing has been removed. Non-merge commits (relative to Linus' tree): 1535 1385 files changed, 86704 insertions(+), 19334 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 221 trees (counting Linus' and 31 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (6ac15baacb6e Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging fixes/master (658faec53209 Add __init attribute to new_kmalloc_cache) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (0bbe6b5a73c0 ARM: 8388/1: tcm: Don't crash when TCM banks are protected by TrustZone) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge-mpe/fixes (b953c0d234bc Linux 4.1) Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (4a10a91756ef Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit) Merging net/master (b922622ec6ef sock_diag: don't broadcast kernel sockets) Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at start of day.) Merging sound-current/for-linus (0755e74b8f04 ALSA: Fix uninintialized error return) Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during alignment reordering) Merging wireless-drivers/master (38fe44e61a89 Merge tag 'iwlwifi-for-kalle-2015-05-28' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (d4a4f75cd8f2 Linux 4.1-rc7) Merging tty.current/tty-linus (d4a4f75cd8f2 Linux 4.1-rc7) Merging usb.current/usb-linus (d4a4f75cd8f2 Linux 4.1-rc7) Merging usb-gadget-fixes/fixes (c94e289f195e usb: gadget: remove incorrect __init/__exit annotations) Merging usb-serial-fixes/usb-linus (0f57d86787d8 Linux 4.1-rc8) Merging staging.current/staging-linus (6aaf0da8728c Merge tag 'md/4.2' of git://neil.brown.name/md) Merging char-misc.current/char-misc-linus (2a298679b411 Merge tag 'usb-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb) Merging input-current/for-linus (f7ebc4dcdeb1 Merge branch 'next' into for-linus) Merging crypto-current/master (0fbafd06bdde crypto: aesni - fix failing setkey for rfc4106-gcm-aesni) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (f36963c9d3f6 cpumask_set_cpu_local_first => cpumask_local_spread, lament) Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible timeout) Merging kselftest-fixes/fixes (ba155e2d21f6 Linux 4.1-rc5) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM) Merging drm-intel-fixes/for-linux-next-fixes (b953c0d234bc Linux 4.1) Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of git://git.k
ARC build -O3 (was Re: subtle side effect of commit a1c48bb160f836)
On Wednesday 01 July 2015 08:49 PM, Michal Marek wrote:
> On Wed, Jun 24, 2015 at 05:50:16PM +0530, Vineet Gupta wrote:
>> On Thursday 18 June 2015 04:02 PM, Vineet Gupta wrote:
>>> On Thursday 18 June 2015 03:44 PM, Michal Marek wrote:
Uh, this is not what I meant. KCFLAGS is a *user* setting. It's meant to
be set in the environment or command line.
>>>
>>> Well I don't want to rely on external settings whatsoever to enforce this.
>>> If this
>>> is not the right way, what do u suggest I do to help fix this.
>>
>>
>> Can I keep this seeming abuse of KCFLAGS or do u suggest alternate approach
>> I can
>> code up !
>
> Hi Vineet, sorry for the late reply.
NP !
> I had something like the below
> patch in mind, simply allow arc to specify -O3 in ARCH_CFLAGS (that part
> I'm leaving up to you).
See below !
> From e458fdf4ae37e1adce81b58d96b1075b4f0656e6 Mon Sep 17 00:00:00 2001
> From: Michal Marek
> Date: Wed, 1 Jul 2015 17:13:16 +0200
> Subject: [PATCH] kbuild: Allow arch Makefiles to override {cpp,ld,c}flags
>
> Since commit a1c48bb1 (Makefile: Fix unrecognized cross-compiler command
> line options), the arch Makefile is included earlier by the main
> Makefile, preventing the arc architecture to set its -O3 compiler
> option. Since there might be more use cases for an arch Makefile to
> fine-tune the options, add support for ARCH_CPPFLAGS, ARCH_AFLAGS and
> ARCH_CFLAGS variables that are appended to the respective kbuild
> variables. The user still has the final say via the KCPPFLAGS, KAFLAGS
> and KCFLAGS variables.
>
> Reported-by: Vineet Gupta
> Signed-off-by: Michal Marek
Sweet, that works for me with the following patch below.
Some logistics things:
- It would be nice to keep both of these patches together - do u want to do
that or want me to pick this one up
- For ARC this fixes a regression starting 3.16 - so I'll need a stable backport
which but obviously requires above to go to stable. Do u have any issues with
that. Shall we do the stable request after these hit the mainline...
->
>From 5458aa05ca3b2c57b683a27ce8226ab5029b9686 Mon Sep 17 00:00:00 2001
From: Vineet Gupta
Date: Thu, 18 Jun 2015 13:54:01 +0530
Subject: [PATCH] ARC: Override toplevel default -O2 with -O3
ARC kernels have historically been built with -O3, despite top level
Makefile defaulting to -O2. This was facilitated by implicitly ordering
of arch makefile include AFTER top level assigned -O2.
An upstream fix to top level a1c48bb160f ("Makefile: Fix unrecognized
cross-compiler command line options") changed the ordering, making ARC
-O3 defunt.
Fix that by NOT relying on any ordering whatsoever and use the proper
arch override facility now present in kbuild (ARCH_*FLAGS)
Suggested-by: Michal Marek
Cc: Geert Uytterhoeven
Signed-off-by: Vineet Gupta
---
arch/arc/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 6107062c0111..46d87310220d 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -49,7 +49,8 @@ endif
ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
# Generic build system uses -O2, we want -O3
-cflags-y += -O3
+# Note: No need to add to cflags-y as that happens anyways
+ARCH_CFLAGS += -O3
endif
# small data is default for elf32 tool-chain. If not usable, disable it
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arm64: cpuidle: add __init section marker to arm_cpuidle_init
On 02.07.2015 13:58, Jisheng Zhang wrote: > Dear Krzysztof, > > On Thu, 2 Jul 2015 12:59:44 +0900 > Krzysztof Kozlowski wrote: > >> 2015-07-02 11:14 GMT+09:00 Jisheng Zhang : >>> It is not needed after booting, this patch moves the arm_cpuidle_init() >>> function to the __init section. >>> >>> Signed-off-by: Jisheng Zhang >>> --- >>> arch/arm64/include/asm/cpuidle.h | 2 +- >>> arch/arm64/kernel/cpuidle.c | 2 +- >>> 2 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/arm64/include/asm/cpuidle.h >>> b/arch/arm64/include/asm/cpuidle.h >>> index 0f74f05..5748d3b 100644 >>> --- a/arch/arm64/include/asm/cpuidle.h >>> +++ b/arch/arm64/include/asm/cpuidle.h >>> @@ -4,7 +4,7 @@ >>> #include >>> >>> #ifdef CONFIG_CPU_IDLE >>> -extern int arm_cpuidle_init(unsigned int cpu); >>> +extern int __init arm_cpuidle_init(unsigned int cpu); >> >> No, not here but... >> >>> extern int arm_cpuidle_suspend(int index); >>> #else >>> static inline int arm_cpuidle_init(unsigned int cpu) >> >> ... here so the stub for !CONFIG_CPU_IDLE would be marked as well. > > when !CONFIG_CPU_IDLE, arm_cpuidle_init() is inlined, and just return > -EOPNOTSUPP; > Per my understanding, it will be optimized out by compiler. I'm not sure > whether > there is any benefit to mark inlined function as __init. But Per my check, all > other inlined functions in linux kernel have no __init. What do you think? Yes, you're right, the inline is sufficient so this means that actually the first patch was correct. The __init is not needed in extern declaration. For both versions then: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/10] crypto: omap-aes: gcm: Handle inputs properly
Its not necessary that assoc data and plain text is passed always.
Add these checks before processing the input.
Signed-off-by: Lokesh Vutla
---
drivers/crypto/omap-aes-gcm.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 1be9d91..72815af 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -87,7 +87,7 @@ static int omap_aes_gcm_copy_buffers(struct omap_aes_dev *dd,
struct aead_request *req)
{
void *buf_in;
- int alen, clen;
+ int alen, clen, nsg;
struct crypto_aead *aead = crypto_aead_reqtfm(req);
unsigned int authlen = crypto_aead_authsize(aead);
u32 dec = !(dd->flags & FLAGS_ENCRYPT);
@@ -97,12 +97,18 @@ static int omap_aes_gcm_copy_buffers(struct omap_aes_dev
*dd,
dd->sgs_copied = 0;
- sg_init_table(dd->in_sgl, 2);
- buf_in = sg_virt(req->assoc);
- sg_set_buf(dd->in_sgl, buf_in, alen);
+ nsg = 1 + !!(req->assoclen && req->cryptlen);
- buf_in = sg_virt(req->src);
- sg_set_buf(>in_sgl[1], buf_in, clen);
+ sg_init_table(dd->in_sgl, nsg);
+ if (req->assoclen) {
+ buf_in = sg_virt(req->assoc);
+ sg_set_buf(dd->in_sgl, buf_in, alen);
+ }
+
+ if (req->cryptlen) {
+ buf_in = sg_virt(req->src);
+ sg_set_buf(>in_sgl[nsg - 1], buf_in, clen);
+ }
dd->in_sg = dd->in_sgl;
dd->total = clen;
@@ -258,6 +264,8 @@ static int omap_aes_gcm_crypt(struct aead_request *req,
unsigned long mode)
{
struct omap_aes_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
struct omap_aes_reqctx *rctx = aead_request_ctx(req);
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ unsigned int authlen = crypto_aead_authsize(aead);
struct omap_aes_dev *dd;
__be32 counter = cpu_to_be32(1);
int err;
@@ -270,6 +278,12 @@ static int omap_aes_gcm_crypt(struct aead_request *req,
unsigned long mode)
if (err)
return err;
+ if (req->assoclen + req->cryptlen == 0) {
+ scatterwalk_map_and_copy(ctx->auth_tag, req->dst, 0, authlen,
+1);
+ return 0;
+ }
+
dd = omap_aes_find_dev(ctx);
if (!dd)
return -ENODEV;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/10] crypto: tcrypt: Added speed tests for Async AEAD crypto alogrithms
Adding simple speed tests for a range of block sizes for Async AEAD crypto
algorithms.
Signed-off-by: Lokesh Vutla
---
crypto/tcrypt.c | 233 +++
crypto/tcrypt.h |1 +
2 files changed, 234 insertions(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 1a28001..b37f3f4 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -992,6 +992,234 @@ out:
crypto_free_ahash(tfm);
}
+static inline int do_one_aead_op(struct aead_request *req, int ret)
+{
+ if (ret == -EINPROGRESS || ret == -EBUSY) {
+ struct tcrypt_result *tr = req->base.data;
+
+ ret = wait_for_completion_interruptible(>completion);
+ if (!ret)
+ ret = tr->err;
+ reinit_completion(>completion);
+ }
+
+ return ret;
+}
+
+static int test_aaead_jiffies(struct aead_request *req, int enc,
+ int blen, int sec)
+{
+ unsigned long start, end;
+ int bcount;
+ int ret;
+
+ for (start = jiffies, end = start + sec * HZ, bcount = 0;
+time_before(jiffies, end); bcount++) {
+ if (enc)
+ ret = do_one_aead_op(req, crypto_aead_encrypt(req));
+ else
+ ret = do_one_aead_op(req, crypto_aead_decrypt(req));
+
+ if (ret)
+ return ret;
+ }
+
+ pr_cont("%d operations in %d seconds (%ld bytes)\n",
+ bcount, sec, (long)bcount * blen);
+ return 0;
+}
+
+static int test_aaead_cycles(struct aead_request *req, int enc, int blen)
+{
+ unsigned long cycles = 0;
+ int ret = 0;
+ int i;
+
+ /* Warm-up run. */
+ for (i = 0; i < 4; i++) {
+ if (enc)
+ ret = do_one_aead_op(req, crypto_aead_encrypt(req));
+ else
+ ret = do_one_aead_op(req, crypto_aead_decrypt(req));
+
+ if (ret)
+ goto out;
+ }
+
+ /* The real thing. */
+ for (i = 0; i < 8; i++) {
+ cycles_t start, end;
+
+ start = get_cycles();
+ if (enc)
+ ret = do_one_aead_op(req, crypto_aead_encrypt(req));
+ else
+ ret = do_one_aead_op(req, crypto_aead_decrypt(req));
+
+ end = get_cycles();
+
+ if (ret)
+ goto out;
+
+ cycles += end - start;
+ }
+
+out:
+ if (ret == 0)
+ pr_cont("1 operation in %lu cycles (%d bytes)\n",
+ (cycles + 4) / 8, blen);
+
+ return ret;
+}
+
+static void test_aaead_speed(const char *algo, int enc, unsigned int sec,
+struct aead_speed_template *template,
+unsigned int tcount, u8 authsize,
+unsigned int aad_size, u8 *keysize)
+{
+ unsigned int i, j;
+ struct crypto_aead *tfm;
+ int ret = -ENOMEM;
+ const char *key;
+ struct aead_request *req;
+ struct scatterlist *sg;
+ struct scatterlist *asg;
+ struct scatterlist *sgout;
+ const char *e;
+ void *assoc;
+ char iv[MAX_IVLEN];
+ char *xbuf[XBUFSIZE];
+ char *xoutbuf[XBUFSIZE];
+ char *axbuf[XBUFSIZE];
+ unsigned int *b_size;
+ unsigned int iv_len;
+ struct tcrypt_result result;
+
+ if (enc == ENCRYPT)
+ e = "encryption";
+ else
+ e = "decryption";
+
+ if (testmgr_alloc_buf(xbuf))
+ goto out_noxbuf;
+ if (testmgr_alloc_buf(axbuf))
+ goto out_noaxbuf;
+ if (testmgr_alloc_buf(xoutbuf))
+ goto out_nooutbuf;
+
+ sg = kmalloc(sizeof(*sg) * 8 * 3, GFP_KERNEL);
+ if (!sg)
+ goto out_nosg;
+ asg = [8];
+ sgout = [8];
+
+ init_completion();
+ pr_info("\ntesting speed of %s %s\n", algo, e);
+
+ tfm = crypto_alloc_aead(algo, 0, 0);
+
+ if (IS_ERR(tfm)) {
+ pr_err("alg: aead: Failed to load transform for %s: %ld\n",
+ algo, PTR_ERR(tfm));
+ return;
+ }
+
+ req = aead_request_alloc(tfm, GFP_KERNEL);
+ if (!req) {
+ pr_err("alg: aead: Failed to allocate request for %s\n",
+ algo);
+ goto out;
+ }
+
+ aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
+ tcrypt_complete, );
+
+ i = 0;
+ do {
+ b_size = aead_sizes;
+ do {
+ assoc = axbuf[0];
+
+ if (aad_size < PAGE_SIZE) {
+ memset(assoc, 0xff, aad_size);
+ } else {
+ pr_err("associate data length (%u) too big\n",
+
[PATCH 03/10] crypto: aead: Add aead_request_cast() api
Add aead_request_cast() api to get pointer to aead_request
from cryto_async_request.
Signed-off-by: Lokesh Vutla
---
include/linux/crypto.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 10df5d2..20fac3d 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -1460,6 +1460,12 @@ static inline void aead_request_set_tfm(struct
aead_request *req,
req->base.tfm = crypto_aead_tfm(crypto_aead_crt(tfm)->base);
}
+static inline struct aead_request *aead_request_cast(
+ struct crypto_async_request *req)
+{
+ return container_of(req, struct aead_request, base);
+}
+
/**
* aead_request_alloc() - allocate request data structure
* @tfm: cipher handle to be registered with the request
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/10] crypto: omap-aes: Use BIT() macro
Use BIT()/GENMASK() macros for all register definitions instead of hand-writing bit masks. Signed-off-by: Lokesh Vutla --- drivers/crypto/omap-aes.c | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c index 96fc7f7..d974ab6 100644 --- a/drivers/crypto/omap-aes.c +++ b/drivers/crypto/omap-aes.c @@ -52,30 +52,30 @@ #define AES_REG_IV(dd, x) ((dd)->pdata->iv_ofs + ((x) * 0x04)) #define AES_REG_CTRL(dd) ((dd)->pdata->ctrl_ofs) -#define AES_REG_CTRL_CTR_WIDTH_MASK(3 << 7) -#define AES_REG_CTRL_CTR_WIDTH_32 (0 << 7) -#define AES_REG_CTRL_CTR_WIDTH_64 (1 << 7) -#define AES_REG_CTRL_CTR_WIDTH_96 (2 << 7) -#define AES_REG_CTRL_CTR_WIDTH_128 (3 << 7) -#define AES_REG_CTRL_CTR (1 << 6) -#define AES_REG_CTRL_CBC (1 << 5) -#define AES_REG_CTRL_KEY_SIZE (3 << 3) -#define AES_REG_CTRL_DIRECTION (1 << 2) -#define AES_REG_CTRL_INPUT_READY (1 << 1) -#define AES_REG_CTRL_OUTPUT_READY (1 << 0) -#define AES_REG_CTRL_MASK FLD_MASK(24, 2) +#define AES_REG_CTRL_CTR_WIDTH_MASKGENMASK(8, 7) +#define AES_REG_CTRL_CTR_WIDTH_32 0 +#define AES_REG_CTRL_CTR_WIDTH_64 BIT(7) +#define AES_REG_CTRL_CTR_WIDTH_96 BIT(8) +#define AES_REG_CTRL_CTR_WIDTH_128 GENMASK(8, 7) +#define AES_REG_CTRL_CTR BIT(6) +#define AES_REG_CTRL_CBC BIT(5) +#define AES_REG_CTRL_KEY_SIZE GENMASK(4, 3) +#define AES_REG_CTRL_DIRECTION BIT(2) +#define AES_REG_CTRL_INPUT_READY BIT(1) +#define AES_REG_CTRL_OUTPUT_READY BIT(0) +#define AES_REG_CTRL_MASK GENMASK(24, 2) #define AES_REG_DATA_N(dd, x) ((dd)->pdata->data_ofs + ((x) * 0x04)) #define AES_REG_REV(dd)((dd)->pdata->rev_ofs) #define AES_REG_MASK(dd) ((dd)->pdata->mask_ofs) -#define AES_REG_MASK_SIDLE (1 << 6) -#define AES_REG_MASK_START (1 << 5) -#define AES_REG_MASK_DMA_OUT_EN(1 << 3) -#define AES_REG_MASK_DMA_IN_EN (1 << 2) -#define AES_REG_MASK_SOFTRESET (1 << 1) -#define AES_REG_AUTOIDLE (1 << 0) +#define AES_REG_MASK_SIDLE BIT(6) +#define AES_REG_MASK_START BIT(5) +#define AES_REG_MASK_DMA_OUT_ENBIT(3) +#define AES_REG_MASK_DMA_IN_EN BIT(2) +#define AES_REG_MASK_SOFTRESET BIT(1) +#define AES_REG_AUTOIDLE BIT(0) #define AES_REG_LENGTH_N(x)(0x54 + ((x) * 0x04)) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/10] crypto: omap-aes: Add support for GCM mode
OMAP AES hw supports aes gcm mode.
Adding support for GCM mode in omap-aes driver.
Signed-off-by: Lokesh Vutla
---
drivers/crypto/Makefile |3 +-
drivers/crypto/omap-aes-gcm.c | 304 +
drivers/crypto/omap-aes.c | 238 +---
drivers/crypto/omap-aes.h | 205 +++
4 files changed, 575 insertions(+), 175 deletions(-)
create mode 100644 drivers/crypto/omap-aes-gcm.c
create mode 100644 drivers/crypto/omap-aes.h
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index fb84be7..3afad7b 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -13,7 +13,8 @@ obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o
obj-$(CONFIG_CRYPTO_DEV_NIAGARA2) += n2_crypto.o
n2_crypto-y := n2_core.o n2_asm.o
obj-$(CONFIG_CRYPTO_DEV_NX) += nx/
-obj-$(CONFIG_CRYPTO_DEV_OMAP_AES) += omap-aes.o
+obj-$(CONFIG_CRYPTO_DEV_OMAP_AES) += omap-aes-driver.o
+omap-aes-driver-objs := omap-aes.o omap-aes-gcm.o
obj-$(CONFIG_CRYPTO_DEV_OMAP_DES) += omap-des.o
obj-$(CONFIG_CRYPTO_DEV_OMAP_SHAM) += omap-sham.o
obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
new file mode 100644
index 000..1be9d91
--- /dev/null
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -0,0 +1,304 @@
+/*
+ * Cryptographic API.
+ *
+ * Support for OMAP AES GCM HW acceleration.
+ *
+ * Copyright (c) 2015 Texas Instruments Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "omap-aes.h"
+
+static int omap_aes_gcm_handle_queue(struct omap_aes_dev *dd,
+struct aead_request *req);
+
+static void omap_aes_gcm_finish_req(struct omap_aes_dev *dd, int ret)
+{
+ struct aead_request *req = dd->aead_req;
+
+ dd->flags &= ~FLAGS_BUSY;
+ dd->in_sg = NULL;
+ dd->out_sg = NULL;
+
+ req->base.complete(>base, ret);
+}
+
+static void omap_aes_gcm_done_task(struct omap_aes_dev *dd)
+{
+ u8 *tag;
+ int alen, clen, i, ret = 0, nsg;
+
+ alen = ALIGN(dd->assoc_len, AES_BLOCK_SIZE);
+ clen = ALIGN(dd->total, AES_BLOCK_SIZE);
+
+ nsg = 1 + !!(dd->assoc_len && dd->total);
+
+ if (!dd->pio_only) {
+ dma_sync_sg_for_device(dd->dev, dd->out_sg, dd->out_sg_len,
+ DMA_FROM_DEVICE);
+ dma_unmap_sg(dd->dev, dd->in_sg, dd->in_sg_len, DMA_TO_DEVICE);
+ dma_unmap_sg(dd->dev, dd->out_sg, dd->out_sg_len,
+DMA_FROM_DEVICE);
+ omap_aes_crypt_dma_stop(dd);
+ }
+
+ if (dd->flags & FLAGS_ENCRYPT)
+ scatterwalk_map_and_copy(dd->ctx->auth_tag, dd->aead_req->dst,
+dd->total, dd->authsize, 1);
+
+ if (!(dd->flags & FLAGS_ENCRYPT)) {
+ tag = (u8 *)dd->ctx->auth_tag;
+ for (i = 0; i < dd->authsize; i++) {
+ if (tag[i]) {
+ dev_err(dd->dev, "GCM decryption: Tag Message
is wrong\n");
+ ret = -EBADMSG;
+ }
+ }
+ }
+
+ omap_aes_gcm_finish_req(dd, ret);
+ omap_aes_gcm_handle_queue(dd, NULL);
+}
+
+static int omap_aes_gcm_copy_buffers(struct omap_aes_dev *dd,
+struct aead_request *req)
+{
+ void *buf_in;
+ int alen, clen;
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ unsigned int authlen = crypto_aead_authsize(aead);
+ u32 dec = !(dd->flags & FLAGS_ENCRYPT);
+
+ alen = req->assoclen;
+ clen = req->cryptlen - (dec * authlen);
+
+ dd->sgs_copied = 0;
+
+ sg_init_table(dd->in_sgl, 2);
+ buf_in = sg_virt(req->assoc);
+ sg_set_buf(dd->in_sgl, buf_in, alen);
+
+ buf_in = sg_virt(req->src);
+ sg_set_buf(>in_sgl[1], buf_in, clen);
+
+ dd->in_sg = dd->in_sgl;
+ dd->total = clen;
+ dd->assoc_len = req->assoclen;
+ dd->authsize = authlen;
+ dd->out_sg = req->dst;
+
+ dd->in_sg_len = scatterwalk_bytes_sglen(dd->in_sg, alen + clen);
+ dd->out_sg_len = scatterwalk_bytes_sglen(dd->out_sg, clen);
+
+ return 0;
+}
+
+static void tcrypt_complete(struct crypto_async_request *req, int err)
+{
+ struct tcrypt_result *res = req->data;
+
+ if (err == -EINPROGRESS)
+ return;
+
+ res->err = err;
+ complete(>completion);
+}
+
+static int do_encrypt_iv(struct aead_request *req, u32 *tag)
+{
+ struct
[PATCH 08/10] crypto: omap-aes: gmc: Add algo info
Now the driver supports gcm mode, add omap-aes-gcm
algo info to omap-aes driver.
Signed-off-by: Lokesh Vutla
---
drivers/crypto/omap-aes.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index e5e9a19..11f3850 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -789,6 +789,28 @@ static struct crypto_alg algs_ctr[] = {
.decrypt= omap_aes_ctr_decrypt,
}
},
+{
+ .cra_name = "gcm(aes)",
+ .cra_driver_name= "gcm-aes-omap",
+ .cra_priority = 100,
+ .cra_flags = CRYPTO_ALG_TYPE_AEAD | CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_KERN_DRIVER_ONLY,
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_ctxsize= sizeof(struct omap_aes_ctx),
+ .cra_alignmask = 0xf,
+ .cra_type = _aead_type,
+ .cra_module = THIS_MODULE,
+ .cra_init = omap_aes_gcm_cra_init,
+ .cra_exit = omap_aes_cra_exit,
+ .cra_u.aead = {
+ .maxauthsize= AES_BLOCK_SIZE,
+ .geniv = "eseqiv",
+ .ivsize = AES_BLOCK_SIZE,
+ .setkey = omap_aes_gcm_setkey,
+ .encrypt= omap_aes_gcm_encrypt,
+ .decrypt= omap_aes_gcm_decrypt,
+ }
+},
};
static struct omap_aes_algs_info omap_aes_algs_info_ecb_cbc[] = {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/10] crypto: omap-aes: gcm: Add support for unaligned lengths
Check if the inputs are not aligned, if not process
the input before starting the hw acceleration.
Similarly after completition of hw acceleration.
Signed-off-by: Lokesh Vutla
---
drivers/crypto/omap-aes-gcm.c | 82 +
1 file changed, 74 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 72815af..9c68ff0 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -48,8 +48,9 @@ static void omap_aes_gcm_finish_req(struct omap_aes_dev *dd,
int ret)
static void omap_aes_gcm_done_task(struct omap_aes_dev *dd)
{
+ void *buf;
u8 *tag;
- int alen, clen, i, ret = 0, nsg;
+ int pages, alen, clen, i, ret = 0, nsg;
alen = ALIGN(dd->assoc_len, AES_BLOCK_SIZE);
clen = ALIGN(dd->total, AES_BLOCK_SIZE);
@@ -65,10 +66,29 @@ static void omap_aes_gcm_done_task(struct omap_aes_dev *dd)
omap_aes_crypt_dma_stop(dd);
}
+ if (dd->sgs_copied & AES_OUT_DATA_COPIED) {
+ buf = sg_virt(>out_sgl);
+ scatterwalk_map_and_copy(buf, dd->orig_out, 0, dd->total, 1);
+
+ pages = get_order(clen);
+ free_pages((unsigned long)buf, pages);
+ }
+
if (dd->flags & FLAGS_ENCRYPT)
scatterwalk_map_and_copy(dd->ctx->auth_tag, dd->aead_req->dst,
dd->total, dd->authsize, 1);
+ if (dd->sgs_copied & AES_ASSOC_DATA_COPIED) {
+ buf = sg_virt(>in_sgl[0]);
+ pages = get_order(alen);
+ free_pages((unsigned long)buf, pages);
+ }
+ if (dd->sgs_copied & AES_IN_DATA_COPIED) {
+ buf = sg_virt(>in_sgl[nsg - 1]);
+ pages = get_order(clen);
+ free_pages((unsigned long)buf, pages);
+ }
+
if (!(dd->flags & FLAGS_ENCRYPT)) {
tag = (u8 *)dd->ctx->auth_tag;
for (i = 0; i < dd->authsize; i++) {
@@ -87,13 +107,14 @@ static int omap_aes_gcm_copy_buffers(struct omap_aes_dev
*dd,
struct aead_request *req)
{
void *buf_in;
- int alen, clen, nsg;
+ int pages, alen, clen, cryptlen, nsg;
struct crypto_aead *aead = crypto_aead_reqtfm(req);
unsigned int authlen = crypto_aead_authsize(aead);
u32 dec = !(dd->flags & FLAGS_ENCRYPT);
- alen = req->assoclen;
- clen = req->cryptlen - (dec * authlen);
+ alen = ALIGN(req->assoclen, AES_BLOCK_SIZE);
+ cryptlen = req->cryptlen - (dec * authlen);
+ clen = ALIGN(cryptlen, AES_BLOCK_SIZE);
dd->sgs_copied = 0;
@@ -101,20 +122,65 @@ static int omap_aes_gcm_copy_buffers(struct omap_aes_dev
*dd,
sg_init_table(dd->in_sgl, nsg);
if (req->assoclen) {
- buf_in = sg_virt(req->assoc);
+ if (omap_aes_check_aligned(req->assoc, req->assoclen)) {
+ dd->sgs_copied |= AES_ASSOC_DATA_COPIED;
+ pages = get_order(alen);
+ buf_in = (void *)__get_free_pages(GFP_ATOMIC, pages);
+ if (!buf_in) {
+ pr_err("Couldn't allocate for unaligncases.\n");
+ return -1;
+ }
+
+ scatterwalk_map_and_copy(buf_in, req->assoc, 0,
+req->assoclen, 0);
+ memset(buf_in + req->assoclen, 0, alen - req->assoclen);
+ } else {
+ buf_in = sg_virt(req->assoc);
+ }
sg_set_buf(dd->in_sgl, buf_in, alen);
}
if (req->cryptlen) {
- buf_in = sg_virt(req->src);
+ if (omap_aes_check_aligned(req->src, req->cryptlen)) {
+ dd->sgs_copied |= AES_IN_DATA_COPIED;
+ pages = get_order(clen);
+ buf_in = (void *)__get_free_pages(GFP_ATOMIC, pages);
+ if (!buf_in) {
+ pr_err("Couldn't allocate for unaligncases.\n");
+ return -1;
+ }
+
+ memset(buf_in + cryptlen, 0, clen - cryptlen);
+ scatterwalk_map_and_copy(buf_in, req->src, 0, cryptlen,
+0);
+ } else {
+ buf_in = sg_virt(req->src);
+ }
sg_set_buf(>in_sgl[nsg - 1], buf_in, clen);
}
dd->in_sg = dd->in_sgl;
- dd->total = clen;
+ dd->total = cryptlen;
dd->assoc_len = req->assoclen;
dd->authsize = authlen;
- dd->out_sg = req->dst;
+
+ if (omap_aes_check_aligned(req->dst, cryptlen)) {
+ pages = get_order(clen);
+
+ buf_in = (void
[PATCH 09/10] crypto: omap-aes: gcm: Add support for PIO mode
Add support for PIO mode for GCM mode.
Signed-off-by: Lokesh Vutla
---
drivers/crypto/omap-aes-gcm.c | 10 ++
drivers/crypto/omap-aes.c | 24 ++--
drivers/crypto/omap-aes.h |3 ++-
3 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 9c68ff0..370891b 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -52,8 +52,8 @@ static void omap_aes_gcm_done_task(struct omap_aes_dev *dd)
u8 *tag;
int pages, alen, clen, i, ret = 0, nsg;
- alen = ALIGN(dd->assoc_len, AES_BLOCK_SIZE);
- clen = ALIGN(dd->total, AES_BLOCK_SIZE);
+ alen = ALIGN(dd->assoc_len_save, AES_BLOCK_SIZE);
+ clen = ALIGN(dd->total_save, AES_BLOCK_SIZE);
nsg = 1 + !!(dd->assoc_len && dd->total);
@@ -161,7 +161,9 @@ static int omap_aes_gcm_copy_buffers(struct omap_aes_dev
*dd,
dd->in_sg = dd->in_sgl;
dd->total = cryptlen;
+ dd->total_save = cryptlen;
dd->assoc_len = req->assoclen;
+ dd->assoc_len_save = req->assoclen;
dd->authsize = authlen;
if (omap_aes_check_aligned(req->dst, cryptlen)) {
@@ -248,14 +250,14 @@ static int do_encrypt_iv(struct aead_request *req, u32
*tag)
return ret;
}
-void omap_aes_gcm_dma_out_callback(void *data)
+void omap_aes_gcm_process_auth_tag(void *data)
{
struct omap_aes_dev *dd = data;
int i, val;
u32 *auth_tag, tag[4];
if (!(dd->flags & FLAGS_ENCRYPT))
- scatterwalk_map_and_copy(tag, dd->aead_req->src, dd->total,
+ scatterwalk_map_and_copy(tag, dd->aead_req->src, dd->total_save,
dd->authsize, 0);
auth_tag = dd->ctx->auth_tag;
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 11f3850..8aeb913 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -340,7 +340,7 @@ static int omap_aes_crypt_dma(struct omap_aes_dev *dd,
}
if (dd->flags & FLAGS_GCM)
- tx_out->callback = omap_aes_gcm_dma_out_callback;
+ tx_out->callback = omap_aes_gcm_process_auth_tag;
else
tx_out->callback = omap_aes_dma_out_callback;
tx_out->callback_param = dd;
@@ -927,8 +927,15 @@ static irqreturn_t omap_aes_irq(int irq, void *dev_id)
status &= ~AES_REG_IRQ_DATA_IN;
omap_aes_write(dd, AES_REG_IRQ_STATUS(dd), status);
- /* Enable DATA_OUT interrupt */
- omap_aes_write(dd, AES_REG_IRQ_ENABLE(dd), 0x4);
+ /*
+* if GCM mode enable DATA_IN till assoc data is copied
+* else Enable DATA_OUT interrupt
+* */
+ if ((dd->flags & FLAGS_GCM) && dd->assoc_len)
+ dd->assoc_len -= min((size_t)AES_BLOCK_SIZE,
+dd->assoc_len);
+ else
+ omap_aes_write(dd, AES_REG_IRQ_ENABLE(dd), 0x4);
} else if (status & AES_REG_IRQ_DATA_OUT) {
omap_aes_write(dd, AES_REG_IRQ_ENABLE(dd), 0x0);
@@ -961,12 +968,17 @@ static irqreturn_t omap_aes_irq(int irq, void *dev_id)
status &= ~AES_REG_IRQ_DATA_OUT;
omap_aes_write(dd, AES_REG_IRQ_STATUS(dd), status);
- if (!dd->total)
+ if (!dd->total) {
/* All bytes read! */
- tasklet_schedule(>done_task);
- else
+ if (dd->flags & FLAGS_GCM)
+ /* Process auth tag and call done_task */
+ omap_aes_gcm_process_auth_tag(dd);
+ else
+ tasklet_schedule(>done_task);
+ } else {
/* Enable DATA_IN interrupt for next block */
omap_aes_write(dd, AES_REG_IRQ_ENABLE(dd), 0x2);
+ }
}
return IRQ_HANDLED;
diff --git a/drivers/crypto/omap-aes.h b/drivers/crypto/omap-aes.h
index 0863874..e0621dd 100644
--- a/drivers/crypto/omap-aes.h
+++ b/drivers/crypto/omap-aes.h
@@ -164,6 +164,7 @@ struct omap_aes_dev {
size_t total;
size_t total_save;
size_t assoc_len;
+ size_t assoc_len_save;
size_t authsize;
struct scatterlist *in_sg;
@@ -199,7 +200,7 @@ int omap_aes_gcm_decrypt(struct aead_request *req);
int omap_aes_write_ctrl(struct omap_aes_dev *dd);
int omap_aes_check_aligned(struct scatterlist *sg, int total);
int omap_aes_crypt_dma_start(struct omap_aes_dev *dd);
-void omap_aes_gcm_dma_out_callback(void *data);
+void omap_aes_gcm_process_auth_tag(void *data);
int
[PATCH 02/10] crypto: omap-aes: Fix configuring of AES mode
AES_CTRL_REG is used to configure AES mode. Before configuring
any mode we need to make sure all other modes are reset or else
driver will misbehave. So mask all modes before configuring
any AES mode.
Signed-off-by: Lokesh Vutla
---
drivers/crypto/omap-aes.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index a923101..96fc7f7 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -63,6 +63,7 @@
#define AES_REG_CTRL_DIRECTION (1 << 2)
#define AES_REG_CTRL_INPUT_READY (1 << 1)
#define AES_REG_CTRL_OUTPUT_READY (1 << 0)
+#define AES_REG_CTRL_MASK FLD_MASK(24, 2)
#define AES_REG_DATA_N(dd, x) ((dd)->pdata->data_ofs + ((x) * 0x04))
@@ -254,7 +255,7 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
{
unsigned int key32;
int i, err;
- u32 val, mask = 0;
+ u32 val;
err = omap_aes_hw_init(dd);
if (err)
@@ -274,17 +275,13 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
val = FLD_VAL(((dd->ctx->keylen >> 3) - 1), 4, 3);
if (dd->flags & FLAGS_CBC)
val |= AES_REG_CTRL_CBC;
- if (dd->flags & FLAGS_CTR) {
+ if (dd->flags & FLAGS_CTR)
val |= AES_REG_CTRL_CTR | AES_REG_CTRL_CTR_WIDTH_128;
- mask = AES_REG_CTRL_CTR | AES_REG_CTRL_CTR_WIDTH_MASK;
- }
+
if (dd->flags & FLAGS_ENCRYPT)
val |= AES_REG_CTRL_DIRECTION;
- mask |= AES_REG_CTRL_CBC | AES_REG_CTRL_DIRECTION |
- AES_REG_CTRL_KEY_SIZE;
-
- omap_aes_write_mask(dd, AES_REG_CTRL(dd), val, mask);
+ omap_aes_write_mask(dd, AES_REG_CTRL(dd), val, AES_REG_CTRL_MASK);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/10] crypto: omap-aes: Add support for lengths not aligned with AES_BLOCK_SIZE
OMAP AES driver returns an error if the data is not aligned with
AES_BLOCK_SIZE bytes.
But OMAP AES hw allows data input upto 1 byte aligned, but still
zeros are to be appended and complete AES_BLOCK_SIZE has to be written.
And correct length has to be passed in LENGTH field.
Adding support for inputs not aligned with AES_BLOCK_SIZE.
Signed-off-by: Lokesh Vutla
---
drivers/crypto/omap-aes.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 9a28b7e..a923101 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -558,6 +558,9 @@ static int omap_aes_check_aligned(struct scatterlist *sg,
int total)
{
int len = 0;
+ if (!IS_ALIGNED(total, AES_BLOCK_SIZE))
+ return -1;
+
while (sg) {
if (!IS_ALIGNED(sg->offset, 4))
return -1;
@@ -577,9 +580,10 @@ static int omap_aes_check_aligned(struct scatterlist *sg,
int total)
static int omap_aes_copy_sgs(struct omap_aes_dev *dd)
{
void *buf_in, *buf_out;
- int pages;
+ int pages, total;
- pages = get_order(dd->total);
+ total = ALIGN(dd->total, AES_BLOCK_SIZE);
+ pages = get_order(total);
buf_in = (void *)__get_free_pages(GFP_ATOMIC, pages);
buf_out = (void *)__get_free_pages(GFP_ATOMIC, pages);
@@ -594,11 +598,11 @@ static int omap_aes_copy_sgs(struct omap_aes_dev *dd)
sg_copy_buf(buf_in, dd->in_sg, 0, dd->total, 0);
sg_init_table(>in_sgl, 1);
- sg_set_buf(>in_sgl, buf_in, dd->total);
+ sg_set_buf(>in_sgl, buf_in, total);
dd->in_sg = >in_sgl;
sg_init_table(>out_sgl, 1);
- sg_set_buf(>out_sgl, buf_out, dd->total);
+ sg_set_buf(>out_sgl, buf_out, total);
dd->out_sg = >out_sgl;
return 0;
@@ -611,7 +615,7 @@ static int omap_aes_handle_queue(struct omap_aes_dev *dd,
struct omap_aes_ctx *ctx;
struct omap_aes_reqctx *rctx;
unsigned long flags;
- int err, ret = 0;
+ int err, ret = 0, len;
spin_lock_irqsave(>lock, flags);
if (req)
@@ -650,8 +654,9 @@ static int omap_aes_handle_queue(struct omap_aes_dev *dd,
dd->sgs_copied = 0;
}
- dd->in_sg_len = scatterwalk_bytes_sglen(dd->in_sg, dd->total);
- dd->out_sg_len = scatterwalk_bytes_sglen(dd->out_sg, dd->total);
+ len = ALIGN(dd->total, AES_BLOCK_SIZE);
+ dd->in_sg_len = scatterwalk_bytes_sglen(dd->in_sg, len);
+ dd->out_sg_len = scatterwalk_bytes_sglen(dd->out_sg, len);
BUG_ON(dd->in_sg_len < 0 || dd->out_sg_len < 0);
rctx = ablkcipher_request_ctx(req);
@@ -678,7 +683,7 @@ static void omap_aes_done_task(unsigned long data)
{
struct omap_aes_dev *dd = (struct omap_aes_dev *)data;
void *buf_in, *buf_out;
- int pages;
+ int pages, len;
pr_debug("enter done_task\n");
@@ -697,7 +702,8 @@ static void omap_aes_done_task(unsigned long data)
sg_copy_buf(buf_out, dd->orig_out, 0, dd->total_save, 1);
- pages = get_order(dd->total_save);
+ len = ALIGN(dd->total_save, AES_BLOCK_SIZE);
+ pages = get_order(len);
free_pages((unsigned long)buf_in, pages);
free_pages((unsigned long)buf_out, pages);
}
@@ -726,11 +732,6 @@ static int omap_aes_crypt(struct ablkcipher_request *req,
unsigned long mode)
!!(mode & FLAGS_ENCRYPT),
!!(mode & FLAGS_CBC));
- if (!IS_ALIGNED(req->nbytes, AES_BLOCK_SIZE)) {
- pr_err("request size is not exact amount of AES blocks\n");
- return -EINVAL;
- }
-
dd = omap_aes_find_dev(ctx);
if (!dd)
return -ENODEV;
@@ -1046,9 +1047,7 @@ static irqreturn_t omap_aes_irq(int irq, void *dev_id)
}
}
- dd->total -= AES_BLOCK_SIZE;
-
- BUG_ON(dd->total < 0);
+ dd->total -= min_t(size_t, AES_BLOCK_SIZE, dd->total);
/* Clear IRQ status */
status &= ~AES_REG_IRQ_DATA_OUT;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/10] crypto: omap-aes: Add support for GCM mode
This series does some basic cleanup and adds support for AES GCM mode for omap aes driver. Also adds a test case for async aead algos. Tested on BeagelBoneBlack: http://pastebin.ubuntu.com/11808341/ Lokesh Vutla (10): crypto: omap-aes: Add support for lengths not aligned with AES_BLOCK_SIZE crypto: omap-aes: Fix configuring of AES mode crypto: aead: Add aead_request_cast() api crypto: omap-aes: Use BIT() macro crypto: omap-aes: Add support for GCM mode crypto: omap-aes: gcm: Handle inputs properly crypto: omap-aes: gcm: Add support for unaligned lengths crypto: omap-aes: gmc: Add algo info crypto: omap-aes: gcm: Add support for PIO mode crypto: tcrypt: Added speed tests for Async AEAD crypto alogrithms crypto/tcrypt.c | 233 + crypto/tcrypt.h |1 + drivers/crypto/Makefile |3 +- drivers/crypto/omap-aes-gcm.c | 386 + drivers/crypto/omap-aes.c | 322 +- drivers/crypto/omap-aes.h | 206 ++ include/linux/crypto.h|6 + 7 files changed, 955 insertions(+), 202 deletions(-) create mode 100644 drivers/crypto/omap-aes-gcm.c create mode 100644 drivers/crypto/omap-aes.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] phy: berlin-usb: fix divider for BG2
The USB PLL divider set by the marvell,berlin2-usb-phy compatible is not
correct for BG2. We couldn't change it before because BG2Q incorrectly
used the same compatible string. Now that BG2Q's compatible is fixed,
change BG2's divider to the correct value.
Signed-off-by: Thomas Hebb
---
drivers/phy/phy-berlin-usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/phy-berlin-usb.c b/drivers/phy/phy-berlin-usb.c
index ab54f28..335e06d 100644
--- a/drivers/phy/phy-berlin-usb.c
+++ b/drivers/phy/phy-berlin-usb.c
@@ -105,7 +105,7 @@
static const u32 phy_berlin_pll_dividers[] = {
/* Berlin 2 */
- CLK_REF_DIV(0xc) | FEEDBACK_CLK_DIV(0x54),
+ CLK_REF_DIV(0x6) | FEEDBACK_CLK_DIV(0x55),
/* Berlin 2CD/Q */
CLK_REF_DIV(0xc) | FEEDBACK_CLK_DIV(0x54),
};
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] phy: berlin-usb: rename table copied from SATA PHY
We're not in a SATA PHY driver, so the of_match table shouldn't have
"sata" in its name.
Signed-off-by: Thomas Hebb
Suggested-by: Sebastian Hesselbarth
---
drivers/phy/phy-berlin-usb.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/phy-berlin-usb.c b/drivers/phy/phy-berlin-usb.c
index 335e06d..7143cd3 100644
--- a/drivers/phy/phy-berlin-usb.c
+++ b/drivers/phy/phy-berlin-usb.c
@@ -152,7 +152,7 @@ static struct phy_ops phy_berlin_usb_ops = {
.owner = THIS_MODULE,
};
-static const struct of_device_id phy_berlin_sata_of_match[] = {
+static const struct of_device_id phy_berlin_usb_of_match[] = {
{
.compatible = "marvell,berlin2-usb-phy",
.data = _berlin_pll_dividers[0],
@@ -163,12 +163,12 @@ static const struct of_device_id
phy_berlin_sata_of_match[] = {
},
{ },
};
-MODULE_DEVICE_TABLE(of, phy_berlin_sata_of_match);
+MODULE_DEVICE_TABLE(of, phy_berlin_usb_of_match);
static int phy_berlin_usb_probe(struct platform_device *pdev)
{
const struct of_device_id *match =
- of_match_device(phy_berlin_sata_of_match, >dev);
+ of_match_device(phy_berlin_usb_of_match, >dev);
struct phy_berlin_usb_priv *priv;
struct resource *res;
struct phy *phy;
@@ -208,7 +208,7 @@ static struct platform_driver phy_berlin_usb_driver = {
.driver = {
.name = "phy-berlin-usb",
.owner = THIS_MODULE,
- .of_match_table = phy_berlin_sata_of_match,
+ .of_match_table = phy_berlin_usb_of_match,
},
};
module_platform_driver(phy_berlin_usb_driver);
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] ARM: dts: berlin: change BG2Q's USB PHY compatible
Currently, BG2Q shares a compatible with BG2. This is incorrect, since
BG2 and BG2Q use different USB PLL dividers. In reality, BG2Q shares a
divider with BG2CD. Change BG2Q's USB PHY compatible string to reflect
that.
Signed-off-by: Thomas Hebb
---
arch/arm/boot/dts/berlin2q.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 63a4849..d4dbd28 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -152,7 +152,7 @@
};
usb_phy2: phy@a2f400 {
- compatible = "marvell,berlin2-usb-phy";
+ compatible = "marvell,berlin2cd-usb-phy";
reg = <0xa2f400 0x128>;
#phy-cells = <0>;
resets = <_rst 0x104 14>;
@@ -170,7 +170,7 @@
};
usb_phy0: phy@b74000 {
- compatible = "marvell,berlin2-usb-phy";
+ compatible = "marvell,berlin2cd-usb-phy";
reg = <0xb74000 0x128>;
#phy-cells = <0>;
resets = <_rst 0x104 12>;
@@ -178,7 +178,7 @@
};
usb_phy1: phy@b78000 {
- compatible = "marvell,berlin2-usb-phy";
+ compatible = "marvell,berlin2cd-usb-phy";
reg = <0xb78000 0x128>;
#phy-cells = <0>;
resets = <_rst 0x104 13>;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] phy: berlin-usb: fix divider for BG2CD
The marvell,berlin2cd-usb-phy compatible incorrectly sets the PLL
divider to BG2's value instead of BG2CD/BG2Q's. Change it to the right
value.
Signed-off-by: Thomas Hebb
Cc: sta...@vger.kernel.org
---
drivers/phy/phy-berlin-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-berlin-usb.c b/drivers/phy/phy-berlin-usb.c
index c6fc95b..ab54f28 100644
--- a/drivers/phy/phy-berlin-usb.c
+++ b/drivers/phy/phy-berlin-usb.c
@@ -106,8 +106,8 @@
static const u32 phy_berlin_pll_dividers[] = {
/* Berlin 2 */
CLK_REF_DIV(0xc) | FEEDBACK_CLK_DIV(0x54),
- /* Berlin 2CD */
- CLK_REF_DIV(0x6) | FEEDBACK_CLK_DIV(0x55),
+ /* Berlin 2CD/Q */
+ CLK_REF_DIV(0xc) | FEEDBACK_CLK_DIV(0x54),
};
struct phy_berlin_usb_priv {
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] phy: berlin-usb: PLL divider fixes
The USB PLL dividers currently set by phy-berlin-usb are incorrect for BG2 and BG2CD (i.e. all Berlin variants but BG2Q). This series fixes the divider values for those two chips and additionally corrects the name of the of_match table to no longer contain "sata" (which was presumably mistakenly carried over from phy-berlin-sata). I have verified that the new divider values work on BG2CD and Antoine Tenart has verified that they work on BG2Q. The divider value for BG2 was taken from bootloader source but has not been tested. Thomas Hebb (4): phy: berlin-usb: fix divider for BG2CD ARM: dts: berlin: change BG2Q's USB PHY compatible phy: berlin-usb: fix divider for BG2 phy: berlin-usb: rename table copied from SATA PHY arch/arm/boot/dts/berlin2q.dtsi | 6 +++--- drivers/phy/phy-berlin-usb.c| 12 ++-- 2 files changed, 9 insertions(+), 9 deletions(-) -- 2.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arm64: cpuidle: add __init section marker to arm_cpuidle_init
Dear Krzysztof, On Thu, 2 Jul 2015 12:59:44 +0900 Krzysztof Kozlowski wrote: > 2015-07-02 11:14 GMT+09:00 Jisheng Zhang : > > It is not needed after booting, this patch moves the arm_cpuidle_init() > > function to the __init section. > > > > Signed-off-by: Jisheng Zhang > > --- > > arch/arm64/include/asm/cpuidle.h | 2 +- > > arch/arm64/kernel/cpuidle.c | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm64/include/asm/cpuidle.h > > b/arch/arm64/include/asm/cpuidle.h > > index 0f74f05..5748d3b 100644 > > --- a/arch/arm64/include/asm/cpuidle.h > > +++ b/arch/arm64/include/asm/cpuidle.h > > @@ -4,7 +4,7 @@ > > #include > > > > #ifdef CONFIG_CPU_IDLE > > -extern int arm_cpuidle_init(unsigned int cpu); > > +extern int __init arm_cpuidle_init(unsigned int cpu); > > No, not here but... > > > extern int arm_cpuidle_suspend(int index); > > #else > > static inline int arm_cpuidle_init(unsigned int cpu) > > ... here so the stub for !CONFIG_CPU_IDLE would be marked as well. when !CONFIG_CPU_IDLE, arm_cpuidle_init() is inlined, and just return -EOPNOTSUPP; Per my understanding, it will be optimized out by compiler. I'm not sure whether there is any benefit to mark inlined function as __init. But Per my check, all other inlined functions in linux kernel have no __init. What do you think? Thanks, Jisheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] drm/rockchip: vop: optimize virtual stride calculate
On Fri, Jun 26, 2015 at 7:07 PM, Mark Yao wrote: > vir_stride need number words of the virtual width, and fb->pitches > save bytes_per_pixel, so just div 4 switch to stride. > > Signed-off-by: Mark Yao > --- > Changes in v2: None > > drivers/gpu/drm/rockchip/rockchip_drm_vop.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > index 6188221..3c9f4f3 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > @@ -644,7 +644,7 @@ static int vop_update_plane_event(struct drm_plane *plane, > offset += (src.y1 >> 16) * fb->pitches[0]; > yrgb_mst = rk_obj->dma_addr + offset; > > - y_vir_stride = fb->pitches[0] / (fb->bits_per_pixel >> 3); > + y_vir_stride = fb->pitches[0] >> 2; If the unit of y_vir_stride is words then doesn't it mean that the calculation before this patch was just invalid? If yes, shouldn't the subject actually say "Fix virtual stride calculation"? Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[lkp] [zswap] c00ed16a9eb: zswap: zpool creation failed
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit c00ed16a9eb98a7fc076e227bdd95c1451ca1e6e ("zswap: runtime
enable/disable")
The following new message in kernel log may make end user confusing:
[5.296308] zswap: loading zswap
[5.299289] zpool: creating pool type zbud
[5.302081] zpool: no driver for type zbud
[5.310432] zswap: zbud zpool not available
[5.313658] zswap: zpool creation failed
Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.1.0 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set
#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
# CONFIG_MEMCG_KMEM is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
CONFIG_RT_GROUP_SCHED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
# CONFIG_IPC_NS is not set
CONFIG_USER_NS=y
# CONFIG_PID_NS is not set
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
Re: [PATCH v3] video-lp8788: Delete a check before backlight_device_unregister()
> On 2015. 7. 1., at PM 7:30, SF Markus Elfring
> wrote:
>
> From: Markus Elfring
> Date: Wed, 1 Jul 2015 12:08:31 +0200
>
> The backlight_device_unregister() function tests whether its argument
> is NULL and then returns immediately.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
It looks good.
Acked-by: Jingoo Han
> ---
> drivers/video/backlight/lp8788_bl.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/lp8788_bl.c
> b/drivers/video/backlight/lp8788_bl.c
> index e418d5b..5d583d7 100644
> --- a/drivers/video/backlight/lp8788_bl.c
> +++ b/drivers/video/backlight/lp8788_bl.c
> @@ -221,8 +221,7 @@ static void lp8788_backlight_unregister(struct lp8788_bl
> *bl)
> {
>struct backlight_device *bl_dev = bl->bl_dev;
>
> -if (bl_dev)
> -backlight_device_unregister(bl_dev);
> +backlight_device_unregister(bl_dev);
> }
>
> static ssize_t lp8788_get_bl_ctl_mode(struct device *dev,
> --
> 2.4.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/34] 3.14.47-stable review
On Wed, Jul 01, 2015 at 07:19:54PM -0700, Guenter Roeck wrote: > On 07/01/2015 11:40 AM, Greg Kroah-Hartman wrote: > >This is the start of the stable review cycle for the 3.14.47 release. > >There are 34 patches in this series, all will be posted as a response > >to this one. If anyone has any issues with these being applied, please > >let me know. > > > >Responses should be made by Fri Jul 3 18:39:45 UTC 2015. > >Anything received after that time might be too late. > > > > Build results: > total: 120 pass: 120 fail: 0 > Qemu test results: > total: 30 pass: 30 fail: 0 > > Details are available at http://server.roeck-us.net:8010/builders. Great, thanks for running these tests and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock controllers
On Thu, Jul 2, 2015 at 10:52 AM, James Liao wrote:
> Hi Daniel,
>
>> > +Required Properties:
>> > +
>> > +- compatible: Should be:
>> > + - "mediatek,mt8173-imgsys", "syscon"
>> > +- #clock-cells: Must be 1
>> > +
>> > +The imgsys controller uses the common clk binding from
>> > +Documentation/devicetree/bindings/clock/clock-bindings.txt
>> > +The available clocks are defined in dt-bindings/clock/mt*-clk.h.
>> > +
>> > +Example:
>> > +
>> > +imgsys: imgsys@1500 {
>>
>> Since these nodes will be supplying clocks to the rest of the system,
>> I think the "name" part of each of these should all be
>> "clock-controller", like topckgen and apmixedsys:
>>
>> imgsys: clock-controller@1500 {
>
> These subsystems (and topckgen also) also contains other functions such
> as reset controller, which may be implemented in clk/mediatek/ in the
> future. It is suitable to use "clock-controller" as their name?
Hmm,
I don't know the "right way" to do this either.
Pardon me if you've already had these discussions.
I only recently started looking at these clock nodes in detail :-).
I think what we really have in register space is a "syscon", as
described in [0]:
[0] Documentation/devicetree/bindings/mfd/syscon.txt
So, we can define this block of registers as a syscon:
mmsys_syscon: syscon@1400 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
};
Then for the clock controller functionality, we create a node with a
"clock-controller" name and a "-clock" compatible, like this:
mmsys_clock: clock-controller {
compatible = "mediatek,mt8173-mmsys-clock";
#clock-cells = <1>;
mediatek,syscon = <_syscon>;
};
You could then do:
CLK_OF_DECLARE(mtk_mmsys, "mediatek,mt8173-mmsys-clock", mtk_mmsys_init);
If you want to reuse the same register range for some other
functionality, we could then use a different node, with a different
compatible:
mmsys: reset-controller {
compatible = "mediatek,mt8173-mmsys-reset";
mediatek,syscon = <_syscon>;
};
What do you think of this approach?
Thanks!
-Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm tree with the userns tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in:
fs/nsfs.c
between the userns tree and patch
"nsfs: fix for seq_printf() API change"
from the akpm tree.
The commit ed2ffc74eee8 ("nsfs: Add a show_path method to fix mountinfo")
that was being fixed by the akpm tree patch was dropped from the usernsn
tree, so I dropped the akpm tree patch as well.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpSc8R2DsKdt.pgp
Description: OpenPGP digital signature
Re: [PATCH] arm64: dts: mt8173: add clock_null
On Thu, Jul 2, 2015 at 11:06 AM, James Liao wrote:
> Hi Daniel,
>
> On Wed, 2015-07-01 at 19:54 +0800, Daniel Kurtz wrote:
>> On Wed, Jul 1, 2015 at 2:49 PM, Sascha Hauer wrote:
>> > The problem is not that you use fixed clocks for non software
>> > controllable clocks of unknwown rates, but that you try to use a single
>> > clock for all of them and name it 'dummy' or 'null'. Name it
>> >
>> > dpi_ck {
>> > compatible = "fixed-clock";
>> > rate = <0>; /* unknown, generated by some Analog block */
>> > };
>>
>> It would be nice, though, to use the real clock rates.
>> Otherwise, we end up with a bunch of unknown clock rates, like this:
>>
>>clock enable_cnt prepare_cntrate
>> accuracy phase
>>
>> clk_null 22 0
>>0 0
>> mm_lvds_cts 00 0
>>0 0
>> mm_lvds_pixel 00 0
>>0 0
>> mm_dpi1_pixel 00 0
>>0 0
>
>> Furthermore, at least some of these children clocks are possible
>> source clocks for other clocks for which we do want to know the
>> resulting frequency. For example, the "dmpll_*" clocks are mux inputs
>> for many of the subsystem clocks.
>
> These clocks such as clkph_mck_o are configured by other modules before
> kernel init, and their rates may different among platforms.
What other modules?
Do you mean the rates are configured by firmware?
How are the rates set?
Are there registers that configure its rate?
If so, why can't the kernel read these registers and compute the current rate?
For mt8173, we are essentially discussing the following clocks (whose
sole parent is clk_null):
FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "clk_null", 15),
GATE_MM1(CLK_MM_DSI0_DIGITAL, "mm_dsi0_digital", "clk_null", 5),
GATE_MM1(CLK_MM_DSI1_DIGITAL, "mm_dsi1_digital", "clk_null", 7),
GATE_MM1(CLK_MM_DPI1_PIXEL, "mm_dpi1_pixel", "clk_null", 10),
GATE_MM1(CLK_MM_LVDS_PIXEL, "mm_lvds_pixel", "clk_null", 16),
GATE_MM1(CLK_MM_LVDS_CTS, "mm_lvds_cts", "clk_null", 17),
clkph_mck_o - This is the parent for dmpll_*, which are themselves
(potential) parent clocks for nearly every subsystem.
In fact, as shown above, the dmpll_* is the selected parent for
several other clocks, which all end up with an unknown rate.
So, I think it is worth investigating a little more how to properly
read or otherwise specify the rate for clkph_mck_o.
dpi_ck, infra_cpum, mm_dsi0_digital, mm_dsi1_digital, mm_lvds_cts -
These are a dead-end (internal?) clock.
It is probably fine if their rates are unknown (0 Hz).
usb_syspll_125m - This sounds like a fixed 125 MHz clock. It is also
a possible parent usb30 clock, so its value will propagate.
hdmitx_dig_cts - This is the root clock for the tree leading to
mm_hdmi_pllck, which includes hdmitxpll_d* and hdmi_sel.
However, I don't know how "mm_hdmi_pllck" is used.
mm_dpi1_pixel, mm_lvds_pixel - These two look very suspicious. The
similar "mm_dpi0_pixel" and "mm_hdmi_pixel" have parent dpi0_sel.
It looks like maybe they should have "dpi1_sel" or "dpilvds_sel" as
parents, but the _sel are not hooked up.
-Dan
> So we can't
> use a hard-coded rate for them. And we also don't care the actual rate
> of these clocks, so assign a dummy rate such as 0 to them should be a
> better way.
>
>
> Best regards,
>
> james
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] smpboot.c: move setup_vector_irq after set_cpu_online
While running cpuhotplug + reboot test, I can easily hit a IPANIC on kernel 3.14. [ 106.107851] BUG: unable to handle kernel NULL pointer dereference at 0040 [ 106.116702] IP: [ 106.118490] [] check_irq_vectors_for_cpu_disable+0x76/0x180 [ 106.126809] PGD 0 [ 106.129110] Oops: [#1] PREEMPT SMP [ 106.133613] Modules linked in: atomisp_css2401a0_v21 lm3554 ov2722 hid_sensor_hub sens_col_core hid_heci_ish heci_ish heci vidt_driver rfkill_gpi o bcmdhd_pcie(O) cfg80211 ov5693 videobuf_vmalloc pn544_nfc(C) videobuf_core bt_lpm 6lowpan_iphc ip6table_raw iptable_raw atmel_mxt_ts [ 106.161897] CPU: 2 PID: 18 Comm: migration/2 Tainted: GWC O 3.14.37-x86_64-L1-R467-g68db82c #1 [ 106.172323] Hardware name: Intel Corporation CHERRYVIEW C0 PLATFORM/Cherry Trail FFD, BIOS CH2TFFD.X64.0004.R83.1506171149 06/17/2015 [ 106.185758] task: 880077e98510 ti: 880077e9a000 task.ti: 880077e9a000 [ 106.194143] RIP: 0010:[] [ 106.198646] [] check_irq_vectors_for_cpu_disable+0x76/0x180 [ 106.206969] RSP: :880077e9bcf8 EFLAGS: 00010046 [ 106.212926] RAX: RBX: 00d3 RCX: [ 106.220921] RDX: RSI: 0088 RDI: 0001 [ 106.228918] RBP: 880077e9bd28 R08: R09: 8800784008e0 [ 106.236915] R10: 000a R11: R12: 0015 [ 106.244911] R13: R14: 0088 R15: 0002 [ 106.252898] FS: () GS:88007a30() knlGS: [ 106.261961] CS: 0010 DS: ES: CR0: 8005003b [ 106.268405] CR2: 0040 CR3: 6e03c000 CR4: 001007e0 [ 106.276400] Last Branch Records: [ 106.280052]to: [] page_fault+0x0/0x80 [ 106.286335] from: [] check_irq_vectors_for_cpu_disable+0x76/0x180 [ 106.295044]to: [] check_irq_vectors_for_cpu_disable+0x73/0x180 [ 106.303749] from: [] irq_to_desc+0x18/0x20 [ 106.310227]to: [] irq_to_desc+0x17/0x20 [ 106.316701] from: [] radix_tree_lookup+0xc/0x10 [ 106.323655]to: [] radix_tree_lookup+0xb/0x10 [ 106.330616] from: [] radix_tree_lookup_element+0x55/0x90 [ 106.338450]to: [] radix_tree_lookup_element+0x30/0x90 [ 106.346274] from: [] radix_tree_lookup_element+0x50/0x90 [ 106.354108]to: [] radix_tree_lookup_element+0x3b/0x90 [ 106.361934] from: [] radix_tree_lookup_element+0x2d/0x90 [ 106.369750]to: [] radix_tree_lookup_element+0x0/0x90 [ 106.377487] from: [] radix_tree_lookup+0x6/0x10 [ 106.384447]to: [] radix_tree_lookup+0x0/0x10 [ 106.391408] from: [] irq_to_desc+0x12/0x20 [ 106.397882] Stack: [ 106.400140] 0002810bb4f2 88006e07bde8 88006e07bd88 [ 106.408551] 8110a801 0202 880077e9bd40 81030f62 [ 106.416967] 0282 880077e9bd58 819dd043 0003 [ 106.425375] Call Trace: [ 106.428136] [] ? multi_cpu_stop+0x1/0x110 [ 106.434475] [] native_cpu_disable+0x12/0x40 [ 106.441018] [] take_cpu_down+0x13/0x40 [ 106.447074] [] multi_cpu_stop+0xc1/0x110 [ 106.453324] [] ? cpu_stop_should_run+0x50/0x50 [ 106.460156] [] cpu_stopper_thread+0x78/0x150 [ 106.466795] [] ? _raw_spin_unlock_irq+0x1e/0x40 [ 106.473726] [] ? finish_task_switch+0x57/0xd0 [ 106.480464] [] ? __schedule+0x37e/0x7b0 [ 106.486619] [] smpboot_thread_fn+0x17d/0x2b0 [ 106.493259] [] ? SyS_setgroups+0x160/0x160 [ 106.499704] [] kthread+0xe4/0x100 We find latest upstream has commit d97eb8966c91f2c9d05f0a22eb89ed5b76d966d1 to solve this IPANIC. But from the link http://lkml.kernel.org/r/20150204132754.ga10...@suse.de, it looks the root cause is not clear. As it's easily to hit with the specific test case, we have more check and find the IPANIC scenario as below. cpu N (N = 1, or 2, or 3) cpu 0 native_cpu_up device_shutdown => do_boot_cpu => start_secondary => smp_callin => setup_vector_irq => __setup_vector_irq => free_msi_irqs => arch_teardown_msi_irqs => default_teardown_msi_irqs => arch_teardown_msi_irq => native_teardown_msi_irq => destroy_irq => __clear_irq_vector => set_cpu_online The cpu still is not online when clear irq vector, it makes the irq number remain in irq vector after free_msi_irqs. Next native_cpu_disable() will hit NULL pointer when check irq vector. The patch move setup_vector_irq after set_cpu_online. Signed-off-by:
running out of tags in 9P (was Re: [git pull] vfs part 2)
[9p and sunrpc folks added to Cc]
On Thu, Jul 02, 2015 at 04:20:42AM +0100, Al Viro wrote:
> On Wed, Jul 01, 2015 at 07:44:08PM +0100, Al Viro wrote:
> > Mismatched reply could also be a possibility, but only if we end up with
> > sending more than one request with the same tag without waiting for response
> > for the first one.
>
> ... and I think I see what's going on. Tags are 16bit. Suppose the
> server stalls for some reason *and* we keep piling the requests up.
> New tags keep being grabbed by this:
>
> tag = P9_NOTAG;
> if (type != P9_TVERSION) {
> tag = p9_idpool_get(c->tagpool);
> if (tag < 0)
> return ERR_PTR(-ENOMEM);
> }
> tag is int here. Then we pass tag to
> req = p9_tag_alloc(c, tag, req_size);
> and that's what sets req->tc->tag. OK, but... The argument of p9_tag_alloc()
> in u16, so after 2^16 pending requests we'll wrap around. p9_idpool_get()
> will happily return values greater than 65535 - it's using idr and it's
> used (with different pools) for 16bit tags and 32bit FIDs.
>
> Now, p9_tag_alloc(c, 65539, max_size) will return the same req we'd got from
> p9_tag_alloc(c, 3, max_size). And we are fucked - as far as the server is
> concerned, we'd just sent another request with tag 3. And on the client
> there are two threads waiting for responses on the same p9_req_t. Both
> happen to be TWRITE. Response to the first request arrives and we happen
> to let the second thread go at it first. Voila - the first request had
> been for page-sized write() and got successfully handled. The _second_ one
> had been short and is very surprised to see confirmation of 4Kb worth of
> data having been written.
>
> It should be easy to confirm - in p9_client_prepare_req() add
> if (WARN_ON_ONCE(tag != (u16)tag)) {
> p9_idpool_put(tag, c->tagpool);
> return ERR_PTR(-ENOMEM);
> }
> right after
> tag = p9_idpool_get(c->tagpool);
> if (tag < 0)
> return ERR_PTR(-ENOMEM);
>
> and see if it triggers. I'm not sure if failing with ENOMEM is the
> right response (another variant is to sleep there until the pile
> gets cleaned or until we get killed), and WARN_ON_ONCE() is definitely
> not for the real work, but it will do for confirming that this is what
> we are hitting.
FWIW, we probably would be better off with throttling rather than ENOMEM
in such situations. I'm not familiar with sunrpc enough to be sure how
to do that right way (note that RPC equivalent of 9P tags is 32bit, so
the throttling there is based on memory shortage rather than running out
of XID space), but the interesting issues should be similar - potential
deadlocks in near-OOM situations. Suggestions?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arm64: cpuidle: add __init section marker to arm_cpuidle_init
2015-07-02 11:14 GMT+09:00 Jisheng Zhang : > It is not needed after booting, this patch moves the arm_cpuidle_init() > function to the __init section. > > Signed-off-by: Jisheng Zhang > --- > arch/arm64/include/asm/cpuidle.h | 2 +- > arch/arm64/kernel/cpuidle.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/cpuidle.h > b/arch/arm64/include/asm/cpuidle.h > index 0f74f05..5748d3b 100644 > --- a/arch/arm64/include/asm/cpuidle.h > +++ b/arch/arm64/include/asm/cpuidle.h > @@ -4,7 +4,7 @@ > #include > > #ifdef CONFIG_CPU_IDLE > -extern int arm_cpuidle_init(unsigned int cpu); > +extern int __init arm_cpuidle_init(unsigned int cpu); No, not here but... > extern int arm_cpuidle_suspend(int index); > #else > static inline int arm_cpuidle_init(unsigned int cpu) ... here so the stub for !CONFIG_CPU_IDLE would be marked as well. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: commit 4066c33d0308f8 breaks booting under KVM
On Mon, Jun 29, 2015 at 10:01 PM, Christoph Lameter wrote:
>
> On Fri, 26 Jun 2015, Linus Torvalds wrote:
>
> > Does reverting it fix everything? I'll give people another day or so to see
> > if they can see what's wrong, but I guess I'll just revert if no fix end up
> > being forthcoming..
>
> Reversion will only affect a special slub debug kernel option and we have
> run without the static names for years. So ok to revert.
>
>
> the problem here is the sequencing of SLAB bootstrap. SLAB bootstrap
> requires certain kmalloc caches to be initialized in a specific sequence
> and that has always caused fragility. Slab cache creation may
> generate a "off slab" configuration which means a kmem_cache
> will then refer to a kmem_cache from the kmalloc array that may not be
> there.
>
> Gavin: Please check your logic here. The two small caches are not always
> created and they often lead to off slab configurations. It depends on the
> minimum aligment required by the architecture. These also need to be
> created in the proper sequence.
>
> Note that you removed the comment that said:
>
> /*
> -* Caches that are not of the two-to-the-power-of size.
> -* These have to be created immediately after the
> -* earlier power of two caches
> +* "i == 2" is the "kmalloc-192" case which is the last
> special
> +* case for initialization and it's the point to jump to
>
> The modification you have made does create the non power of two caches not
> in sequence anymore but before all others!
>
> Here is the new code.
>
> void __init create_kmalloc_caches(unsigned long flags)
> {
> int i;
>
> for (i = KMALLOC_LOOP_LOW; i <= KMALLOC_SHIFT_HIGH; i++) {
> if (!kmalloc_caches[i]) {
> kmalloc_caches[i] = create_kmalloc_cache(
> kmalloc_info[i].name,
> kmalloc_info[i].size,
> flags);
> }
>
> /*
> * "i == 2" is the "kmalloc-192" case which is the last
> special
> * case for initialization and it's the point to jump to
> * allocate the minimize size of the object. In slab
> allocator,
> * the KMALLOC_SHIFT_LOW = 5. So, it needs to skip 2^3 and 2^4
> * and go straight to allocate 2^5. If the ARCH_DMA_MINALIGN
> is
> * defined, it may be larger than 2^5 and here is also the
> * trick to skip the empty gap.
> */
> if (i == 2)
> i = (KMALLOC_SHIFT_LOW - 1);
> }
Sorry, it's my fault, I didn't notice that the 96 and 192 bytes kmem_cache
need to be initialized after initialization of the power of 2 caches. I
saw that in another thread the fix patch had been sent out. Really
appreciate for the help. I'll be more prudent in the future.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
failing while writing to disk with BIOS in realmode setup
What might I be doing wrong? Why won't this code succeed to write to
the (otherwise empty) drive 1 from kernel setup's main? I'm 100%
certain this is the code I'm booting (with grub/bzImage); it's as though
the intcalls just never happen (or fail for some reason I can't get
telemetry on, which is why I'm trying this technique in the first place).
--- /var/tmp/main.c 2015-06-30 14:08:52.435618099 -0700
+++ arch/x86/boot/main.c2015-07-01 20:33:32.227506260 -0700
@@ -132,6 +131,8 @@
}
}
+char block[512] = "DJM WAS HERE ";
+
void main(void)
{
/* First, copy the boot header into the "zeropage" */
@@ -142,6 +143,22 @@
if (cmdline_find_option_bool("debug"))
puts("early console in setup code\n");
+ struct biosregs ireg, oreg;
+ initregs();
+ ireg.ah = 0;// reset drive 81
+ ireg.dl = 0x81;
+ intcall(0x13, , );
+
+ initregs();
+ ireg.ah = 0x03; // write AL sectors to drive DL CHS CH/DH/CL
+ ireg.al = 1;
+ ireg.dl = 0x81;
+ ireg.cl = 1;
+ ireg.dh = 0;
+ ireg.es = ds();
+ ireg.bx = (uint)(uintptr_t)
+
+ intcall(0x13, , );
/* End of heap check */
init_heap();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Make eBPF programs output data to perf event
On 7/1/15 8:38 PM, He Kuang wrote: On 2015/7/2 10:48, Alexei Starovoitov wrote: On 7/1/15 4:58 AM, Peter Zijlstra wrote: But why create a separate trace buffer, it should go into the regular perf buffer. +1 I think +static char __percpu *perf_extra_trace_buf[PERF_NR_CONTEXTS]; is redundant. It adds quite a bit of unnecessary complexity to the whole patch set. Also the call to bpf_output_sample() is not effective unless program returns 1. It's a confusing user interface. Also you cannot ever do: BPF_FUNC_probe_read, +BPF_FUNC_output_sample, BPF_FUNC_ktime_get_ns, new functions must be added to the end. Why not just do: perf_trace_buf_prepare() + perf_trace_buf_submit() from the helper? No changes to current code. No need to call __get_data_size() and other overhead. The helper can be called multiple times from the same program. imo much cleaner. Invoke perf_trace_buf_submit() will generate a second perf event (header->type = PERF_RECORD_SAMPLE) entry which is different from the event entry outputed by the orignial kprobe. So the final result of the example in 00/00 patch may like this: sample entry 1(from bpf_prog): comm timestamp1 generic_perform_write pmu_value=0x1234 sample entry 2(from original kprobe): comm timestamp2 generic_perform_write: (81140b60) Compared with current implementation: combined sample entry: comm timestamp generic_perform_write: (81140b60) pmu_value=0x1234 The former two entries may be discontinuous as there are multiple threads and kprobes to be recorded, and there's a chance that one entry is missed but the other is recorded. What we need is the pmu_value read when 'generic_perform_write' enters, the two entries result is not intuitive enough and userspace tools have to do the work to find and combine those two sample entries to get the result. Just change your example to return 0 and user space will see one sample. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/5] bpf: Put perf_events check ahead of bpf prog
On 6/30/15 7:57 PM, He Kuang wrote: When we add a kprobe point and record events by perf, the execution path of all threads on each cpu will enter this point, but perf may only record events on a particular thread or cpu at this kprobe point, a check on call->perf_events list filters out the threads which perf is not recording. I think there is a better way to do that. You're adding artificial per_cpu filtering whereas you really need per_pid filtering. The patch kinda worked, but looks more by accident. The accurate way to do per_pid filtering is to automatically add 'if ((u32)bpf_get_current_pid_tgid() != expected_pid) return 0;' as the first statement of the program. You already have nice infra to add prologue to the program. So I think adding above 'if' on user space side of perf is a preferred way to achieve that. Also such per_pid filtering should be smart. The command 'perf record -a -e my_prog.o -- sleep 10' should collect all things that my_prog was attached to and not only things that happened as part of sleep. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] powerpc/numa: initialize distance lookup table from drconf path
On Thu, 2015-07-02 at 08:31 +1000, Anton Blanchard wrote: > Hi Nikunj, > > > > Thanks for the patch. Have we tested that this doesn't regress the > > > non dynamic representation? > > > > Yes, that is tested. And works as expected. > > Great, you can add: > > Acked-by: Anton Blanchard Hi Nikunj, Please resend a non-RFC version, with the updated changelog and Anton's ack included. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Make eBPF programs output data to perf event
On 2015/7/2 10:48, Alexei Starovoitov wrote: On 7/1/15 4:58 AM, Peter Zijlstra wrote: But why create a separate trace buffer, it should go into the regular perf buffer. +1 I think +static char __percpu *perf_extra_trace_buf[PERF_NR_CONTEXTS]; is redundant. It adds quite a bit of unnecessary complexity to the whole patch set. Also the call to bpf_output_sample() is not effective unless program returns 1. It's a confusing user interface. Also you cannot ever do: BPF_FUNC_probe_read, +BPF_FUNC_output_sample, BPF_FUNC_ktime_get_ns, new functions must be added to the end. Why not just do: perf_trace_buf_prepare() + perf_trace_buf_submit() from the helper? No changes to current code. No need to call __get_data_size() and other overhead. The helper can be called multiple times from the same program. imo much cleaner. Invoke perf_trace_buf_submit() will generate a second perf event (header->type = PERF_RECORD_SAMPLE) entry which is different from the event entry outputed by the orignial kprobe. So the final result of the example in 00/00 patch may like this: sample entry 1(from bpf_prog): comm timestamp1 generic_perform_write pmu_value=0x1234 sample entry 2(from original kprobe): comm timestamp2 generic_perform_write: (81140b60) Compared with current implementation: combined sample entry: comm timestamp generic_perform_write: (81140b60) pmu_value=0x1234 The former two entries may be discontinuous as there are multiple threads and kprobes to be recorded, and there's a chance that one entry is missed but the other is recorded. What we need is the pmu_value read when 'generic_perform_write' enters, the two entries result is not intuitive enough and userspace tools have to do the work to find and combine those two sample entries to get the result. Thank you. Also how about calling this helper: bpf_trace_buf_submit(void *stack_ptr, int size) ? bpf_output_sample, I think, is odd name. It's not a sample. May be other name? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v2 1/3] mm, oom: organize oom context into struct
> Subject: [patch v2 1/3] mm, oom: organize oom context into struct
[patch v2 2/3] mm, oom: organize oom context into struct
[patch v2 3/3] mm, oom: organize oom context into struct
I am wondering if a redelivery is needed for the same 3 subject lines.
Hillf
>
> There are essential elements to an oom context that are passed around to
> multiple functions.
>
> Organize these elements into a new struct, struct oom_control, that
> specifies the context for an oom condition.
>
> This patch introduces no functional change.
>
> Acked-by: Michal Hocko
> Signed-off-by: David Rientjes
> ---
> v2: fix changelog typo per Sergey
>
> drivers/tty/sysrq.c | 12 +-
> include/linux/oom.h | 25 +++-
> mm/memcontrol.c | 16 +---
> mm/oom_kill.c | 115
>
> mm/page_alloc.c | 10 -
> 5 files changed, 98 insertions(+), 80 deletions(-)
>
> diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
> --- a/drivers/tty/sysrq.c
> +++ b/drivers/tty/sysrq.c
> @@ -353,9 +353,17 @@ static struct sysrq_key_op sysrq_term_op = {
>
> static void moom_callback(struct work_struct *ignored)
> {
> + const gfp_t gfp_mask = GFP_KERNEL;
> + struct oom_control oc = {
> + .zonelist = node_zonelist(first_memory_node, gfp_mask),
> + .nodemask = NULL,
> + .gfp_mask = gfp_mask,
> + .order = 0,
> + .force_kill = true,
> + };
> +
> mutex_lock(_lock);
> - if (!out_of_memory(node_zonelist(first_memory_node, GFP_KERNEL),
> -GFP_KERNEL, 0, NULL, true))
> + if (!out_of_memory())
> pr_info("OOM request ignored because killer is disabled\n");
> mutex_unlock(_lock);
> }
> diff --git a/include/linux/oom.h b/include/linux/oom.h
> --- a/include/linux/oom.h
> +++ b/include/linux/oom.h
> @@ -12,6 +12,14 @@ struct notifier_block;
> struct mem_cgroup;
> struct task_struct;
>
> +struct oom_control {
> + struct zonelist *zonelist;
> + nodemask_t *nodemask;
> + gfp_t gfp_mask;
> + int order;
> + boolforce_kill;
> +};
> +
> /*
> * Types of limitations to the nodes from which allocations may occur
> */
> @@ -57,21 +65,18 @@ extern unsigned long oom_badness(struct task_struct *p,
>
> extern int oom_kills_count(void);
> extern void note_oom_kill(void);
> -extern void oom_kill_process(struct task_struct *p, gfp_t gfp_mask, int
> order,
> +extern void oom_kill_process(struct oom_control *oc, struct task_struct *p,
>unsigned int points, unsigned long totalpages,
> - struct mem_cgroup *memcg, nodemask_t *nodemask,
> - const char *message);
> + struct mem_cgroup *memcg, const char *message);
>
> -extern void check_panic_on_oom(enum oom_constraint constraint, gfp_t
> gfp_mask,
> -int order, const nodemask_t *nodemask,
> +extern void check_panic_on_oom(struct oom_control *oc,
> +enum oom_constraint constraint,
> struct mem_cgroup *memcg);
>
> -extern enum oom_scan_t oom_scan_process_thread(struct task_struct *task,
> - unsigned long totalpages, const nodemask_t *nodemask,
> - bool force_kill);
> +extern enum oom_scan_t oom_scan_process_thread(struct oom_control *oc,
> + struct task_struct *task, unsigned long totalpages);
>
> -extern bool out_of_memory(struct zonelist *zonelist, gfp_t gfp_mask,
> - int order, nodemask_t *mask, bool force_kill);
> +extern bool out_of_memory(struct oom_control *oc);
>
> extern void exit_oom_victim(void);
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1545,6 +1545,13 @@ static unsigned long mem_cgroup_get_limit(struct
> mem_cgroup *memcg)
> static void mem_cgroup_out_of_memory(struct mem_cgroup *memcg, gfp_t
> gfp_mask,
>int order)
> {
> + struct oom_control oc = {
> + .zonelist = NULL,
> + .nodemask = NULL,
> + .gfp_mask = gfp_mask,
> + .order = order,
> + .force_kill = false,
> + };
> struct mem_cgroup *iter;
> unsigned long chosen_points = 0;
> unsigned long totalpages;
> @@ -1563,7 +1570,7 @@ static void mem_cgroup_out_of_memory(struct mem_cgroup
> *memcg, gfp_t gfp_mask,
> goto unlock;
> }
>
> - check_panic_on_oom(CONSTRAINT_MEMCG, gfp_mask, order, NULL, memcg);
> + check_panic_on_oom(, CONSTRAINT_MEMCG, memcg);
> totalpages = mem_cgroup_get_limit(memcg) ? : 1;
> for_each_mem_cgroup_tree(iter, memcg) {
> struct css_task_iter it;
> @@ -1571,8 +1578,7 @@ static void mem_cgroup_out_of_memory(struct mem_cgroup
> *memcg, gfp_t gfp_mask,
>
>
Re: [PATCH 2/2] ARM: dts: mediatek: add mt6580 basic support
Hi Matthias
May I double confirm with you that soc node is MUST removed?
If yes, we will upstream dtsi with this format for other new chips.
Thanks.
On Thu, 2015-06-25 at 08:15 +0800, Mars Cheng wrote:
> On Wed, 2015-06-24 at 22:25 +0200, Matthias Brugger wrote:
> > On Wednesday, June 24, 2015 07:59:13 PM Mars Cheng wrote:
> > > On Tue, 2015-06-23 at 21:45 +0200, Matthias Brugger wrote:
> > > > > + soc {
> > > >
> > > > Please drop the soc node as well and just add the components directly.
> > > >
> > > > Thanks,
> > > > Matthias
> > >
> > > May I know the reason to remove the soc node? I follow other .dtsi
> > > to add this node.
> >
> > The device tree is reflecting the hardware, if you add a soc node like
> > this, it
> > is seen like a bus, but there is not really a bus.
> >
> > I think point of view about this has change over time and nowadays it is
> > preferred not to add a soc node.
> >
> > Regards,
> > Matthias
> Got it. Will remove the soc node and prepare the new patch.
>
> Thanks a lot.
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] mfd : t7l66xb: remove unnecessary pdata check
o Making pdata NULL check to (!pdata) as coding standard and all other checks in file. o Removing redundant check of pdata, because we already check for pdata, and also derefernced before this check. Signed-off-by: Maninder Singh --- v2: changing subject line. drivers/mfd/t7l66xb.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/t7l66xb.c b/drivers/mfd/t7l66xb.c index c09fb5d..854b05f 100644 --- a/drivers/mfd/t7l66xb.c +++ b/drivers/mfd/t7l66xb.c @@ -318,7 +318,7 @@ static int t7l66xb_probe(struct platform_device *dev) struct resource *iomem, *rscr; int ret; - if (pdata == NULL) + if (!pdata) return -EINVAL; iomem = platform_get_resource(dev, IORESOURCE_MEM, 0); @@ -371,7 +371,7 @@ static int t7l66xb_probe(struct platform_device *dev) clk_prepare_enable(t7l66xb->clk48m); - if (pdata && pdata->enable) + if (pdata->enable) pdata->enable(dev); /* Mask all interrupts */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] vfs part 2
On Wed, Jul 01, 2015 at 07:44:08PM +0100, Al Viro wrote:
> Mismatched reply could also be a possibility, but only if we end up with
> sending more than one request with the same tag without waiting for response
> for the first one.
... and I think I see what's going on. Tags are 16bit. Suppose the
server stalls for some reason *and* we keep piling the requests up.
New tags keep being grabbed by this:
tag = P9_NOTAG;
if (type != P9_TVERSION) {
tag = p9_idpool_get(c->tagpool);
if (tag < 0)
return ERR_PTR(-ENOMEM);
}
tag is int here. Then we pass tag to
req = p9_tag_alloc(c, tag, req_size);
and that's what sets req->tc->tag. OK, but... The argument of p9_tag_alloc()
in u16, so after 2^16 pending requests we'll wrap around. p9_idpool_get()
will happily return values greater than 65535 - it's using idr and it's
used (with different pools) for 16bit tags and 32bit FIDs.
Now, p9_tag_alloc(c, 65539, max_size) will return the same req we'd got from
p9_tag_alloc(c, 3, max_size). And we are fucked - as far as the server is
concerned, we'd just sent another request with tag 3. And on the client
there are two threads waiting for responses on the same p9_req_t. Both
happen to be TWRITE. Response to the first request arrives and we happen
to let the second thread go at it first. Voila - the first request had
been for page-sized write() and got successfully handled. The _second_ one
had been short and is very surprised to see confirmation of 4Kb worth of
data having been written.
It should be easy to confirm - in p9_client_prepare_req() add
if (WARN_ON_ONCE(tag != (u16)tag)) {
p9_idpool_put(tag, c->tagpool);
return ERR_PTR(-ENOMEM);
}
right after
tag = p9_idpool_get(c->tagpool);
if (tag < 0)
return ERR_PTR(-ENOMEM);
and see if it triggers. I'm not sure if failing with ENOMEM is the
right response (another variant is to sleep there until the pile
gets cleaned or until we get killed), and WARN_ON_ONCE() is definitely
not for the real work, but it will do for confirming that this is what
we are hitting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones
On Thu, Jul 02, 2015 at 04:50:45AM +0200, Mike Galbraith wrote: > On Wed, 2015-07-01 at 19:18 -0700, Paul E. McKenney wrote: > > > Does their normal workload trigger the condition that results in the > > expedited grace period? If so, do they use NO_HZ_FULL? > > They're having no trouble that I'm aware of, and I definitely would be > made aware. They're not currently using a kernel with NO_HZ_FULL even > built in, as that stuff is far far too raw in the current kernel. > > They may meet a NO_HZ_FULL enabled kernel soonish, but will be told to > not turn it on for anything other than pure compute, as NO_HZ_FULL is > currently not usable for mixed load in partitioned box, much less rt. OK, sounds like synchronize_rcu_expedited() is a complete non-problem for them, then. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] mfd: remove unnecessary check
Hello, >>> >> > >>> >> > Signed-off-by: Maninder Singh >>> >> > Reviewed-by: Vaneet Narang >>> >> > --- >>> >> > drivers/mfd/t7l66xb.c |4 ++-- >>> >> > 1 file changed, 2 insertions(+), 2 deletions(-) >>> >> >>> >> Applied, with a properly formatted subject line. >>> > >>> > Should have probably been more forthcomming with some advice. >>> > >>> > Next time, please use `git log --oneline -- ` to see what >>> > the accepted format is. I did not know this thing. I will keep that in mind from next time thanks. >>> ... and a spell-check could be useful as well :). The reviewed-by tag >>> was not sent on LKML and the person (Vaneet Narang) was not even CC-ed >>> so I think it should be dropped. Thanks for your feedback and noticing spell mistake "statndard" :-) and I applied reviewed-by tag in patch, it is not from LKML, because if we reply any mail, our email client broke the mail thread, Like my this reply will break down the mail chain from LKML. >> Fair points. Patch dropped. > >I meant the reviewed-by tag should be dropped :) . > >So now... Maninder Singh, could you resent the patch with this minor >issues fixed? Yes I am sending patch with these fixes. Thanks, Maninder .
Re: [PATCH V2 2/3] hwmon:f71882fg fix f81866a temp/beep setting
Hi Guenter,
Guenter Roeck 於 2015/7/2 上午 05:04 寫道:
Hi Peter,
+} else {
+size = ARRAY_SIZE(f_temp_beep_attr[0];
TskTsk ... turns out you didn't even compile test this code.
How am I supposed to know that it is working ?
Sorry, It's my fault.
I should re-testing patch after fix checkpatch.sh warnings.
I'll re-confirm all patches again before send it to maintainer.
--
With Best Regards,
Peter Hung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 51/51] ext2: enable cgroup writeback support
On Wed, Jul 01, 2015 at 09:29:12PM +0200, Jan Kara wrote: > On Fri 22-05-15 17:14:05, Tejun Heo wrote: > > Writeback now supports cgroup writeback and the generic writeback, > > buffer, libfs, and mpage helpers that ext2 uses are all updated to > > work with cgroup writeback. > > > > This patch enables cgroup writeback for ext2 by adding > > FS_CGROUP_WRITEBACK to its ->fs_flags. > > > > Signed-off-by: Tejun Heo > > Cc: Jens Axboe > > Cc: Jan Kara > > Cc: linux-e...@vger.kernel.org > > Hallelujah! > > Reviewed-by: Jan Kara Hooray! Thanks a lot for going through all the patches! :) -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] suspend: delete sys_sync()
>> The _vast_ majority of systems using Linux suspend today are under >> an Android user-space. Android has no assumption that that suspend to >> mem will necessarily stay suspended for a long time. > > Indeed, however your change was not android-specific, and it is not > "comfortable" on x86-style hardware and usage patterns. "comfortable on x86-style and usage patterns"? If you mean "traditional" instead of "comfortable", where "tradition" is based on 10-year old systems, then sure. But today, my x86 Android tablet is quite "comfortable" without a sys_sync() in the kernel suspend path. No, this isn't Android specific, Android is just the highest-volume demand, making it an obvious example. Chrome is the #1 selling "x86-style" clamshell laptop. Chrome is not only "comfortable" with fast suspend/resume, the Chrome developers demand it. > That said, as long as x86 will still try to safeguard my data during mem > sleep/resume as it does today, I have no strong feelings about > light/heavy-weight "mem" sleep being strictly a compile-time selectable > thing, or a more flexible runtime-selectable behavior. The observation here is that the kernel should not force every system to sys_sync() on every suspend. The only question is how to best implement that. The obvious solution was to delete this forced policy from the kernel, and let user-space handle it. Rafael has not agreed to push that obvious, though less-than-gentle solution upstream, and so I'll re-send the historic patch that allows distros to still sync like it is 1999, if they want to:-) thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 45/51] writeback: implement wb_wait_for_single_work()
Hello, On Wed, Jul 01, 2015 at 09:07:35PM +0200, Jan Kara wrote: > I don't understand, why is the special handling with single_wait, > single_done necessary. When we fail to allocate work and thus use the > base_work for submission, we can still use the standard completion mechanism > to wait for work to finish, can't we? Indeed. I'm not sure why I didn't do that. I'll try. > BTW: Again it would be easier for me to review this if the implementation > of this function was in one patch with the use of it so that one can see > how it gets used... Same point on this one as before. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: dts: mt8173: add clock_null
Hi Daniel,
On Wed, 2015-07-01 at 19:54 +0800, Daniel Kurtz wrote:
> On Wed, Jul 1, 2015 at 2:49 PM, Sascha Hauer wrote:
> > The problem is not that you use fixed clocks for non software
> > controllable clocks of unknwown rates, but that you try to use a single
> > clock for all of them and name it 'dummy' or 'null'. Name it
> >
> > dpi_ck {
> > compatible = "fixed-clock";
> > rate = <0>; /* unknown, generated by some Analog block */
> > };
>
> It would be nice, though, to use the real clock rates.
> Otherwise, we end up with a bunch of unknown clock rates, like this:
>
>clock enable_cnt prepare_cntrate
> accuracy phase
>
> clk_null 22 0
>0 0
> mm_lvds_cts 00 0
>0 0
> mm_lvds_pixel 00 0
>0 0
> mm_dpi1_pixel 00 0
>0 0
> Furthermore, at least some of these children clocks are possible
> source clocks for other clocks for which we do want to know the
> resulting frequency. For example, the "dmpll_*" clocks are mux inputs
> for many of the subsystem clocks.
These clocks such as clkph_mck_o are configured by other modules before
kernel init, and their rates may different among platforms. So we can't
use a hard-coded rate for them. And we also don't care the actual rate
of these clocks, so assign a dummy rate such as 0 to them should be a
better way.
Best regards,
james
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 44/51] writeback: implement bdi_wait_for_completion()
Hello, Jan. On Wed, Jul 01, 2015 at 06:04:37PM +0200, Jan Kara wrote: > I'd find it better to extend completions to allow doing what you need. It > isn't that special. It seems it would be enough to implement > > void wait_for_completions(struct completion *x, int n); > > where @n is the number of completions to wait for. And the implementation > can stay as is, only in do_wait_for_common() we change checks for x->done == > 0 to "x->done < n". That's about it... I don't know. While I agree that it'd be nice to have a generic event count & trigger mechanism in the kernel, I don't think extending completion is a good idea - the count then works both ways as the event counter && listener counter and effectively becomes a semaphore which usually doesn't end well. There are very few cases where we want the counter works both ways and I personally think we'd be far better served if those rare cases implement something custom rather than generic mechanism becoming cryptic trying to cover everything. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI, Repair of outdated variable
variable "value" in struct acpi_pnp_device_id has been changed to "string". Signed-off-by: xiaofeng.yan --- drivers/acpi/acpica/nsdumpdv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/nsdumpdv.c b/drivers/acpi/acpica/nsdumpdv.c index 7dc367e..1af1af7 100644 --- a/drivers/acpi/acpica/nsdumpdv.c +++ b/drivers/acpi/acpica/nsdumpdv.c @@ -89,7 +89,7 @@ acpi_ns_dump_one_device(acpi_handle obj_handle, ACPI_DEBUG_PRINT_RAW((ACPI_DB_TABLES, "HID: %s, ADR: %8.8X%8.8X, Status: %X\n", - info->hardware_id.value, + info->hardware_id.string, ACPI_FORMAT_UINT64(info->address), info->current_status)); ACPI_FREE(info); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] dt-bindings: ARM: Mediatek: Document devicetree bindings for spi bus
On Mon, Jun 29, 2015 at 9:04 PM, Leilk Liu wrote:
> Signed-off-by: Leilk Liu
> ---
> .../devicetree/bindings/spi/spi-mt65xx.txt | 32
> ++
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/spi-mt65xx.txt
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
> b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
> new file mode 100644
> index 000..04c28fd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
> @@ -0,0 +1,32 @@
> +MTK SPI device
> +
> +Required properties:
> +- compatible: should be one of the following.
> +- mediatek,mt8173-spi: for mt8173 platforms
> +- mediatek,mt8135-spi: for mt8135 platforms
> +- mediatek,mt6589-spi: for mt6589 platforms
> +
> +- reg: Address and length of the register set for the device
> +
> +- interrupts: Should contain spi interrupt
> +
> +- clock-names: tuple listing input clock names.
> + Required elements: "main"
> +
> +- clocks: phandles to input clocks.
> +
> +- pad-select: should specify spi pad used, only required for MT8173.
> + This value should be 0~3.
> +
> +Example:
> +
> +- SoC Specific Portion:
> +spi: spi@1100a000 {
> + compatible = "mediatek,mt8173-spi";
> + reg = <0 0x1100a000 0 0x1000>;
> + interrupts = ;
> + clocks = < PERI_SPI0>;
CLK_PERI_SPI0
> + clock-names = "main";
> + pad-select = <1>;
According to [0], a SPI bus should also specify
address-cells/size-cells to allow SPI bus devices to specify a chip
select.
[0] Documentation/devicetree/bindings/spi/spi-bus.txt
- #address-cells - number of cells required to define a chip select
address on the SPI bus.
- #size-cells - should be zero.
The spi-bus document even describes how to mix "native" and gpio CS lines.
I am still not sure what to do with the "pad-select" feature.
Does "pad-select" just select one of 4 dedicated chip select lines?
Or, does it also change which CK/MOSI/MISO lines are used?
Ideally, the same CK/MOSI/MISO signals are sent on all CK/MOSI/MISO
lines enabled by pinctrl, and "pad-select" just chooses which CS_N
line to use.
In this case, we can use the SPI slave device reg value to select
which CS_N to use for any given device.
Furthermore, we can also support using additional cs-gpios.
However, if the pad-select also specifies which CK/MOSI/MISO pins are
used for a given transaction, then supporting cs-gpios becomes a bit
trickier, since the spi slave device would need to specify both which
gpio-cs to use, as well as which SPI pad it is connected to.
-Dan
> + status = "disabled";
> +};
> --
> 1.8.1.1.dirty
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 44/51] writeback: implement bdi_wait_for_completion()
On Wed, Jul 01, 2015 at 06:09:18PM +0200, Jan Kara wrote:
> > @@ -161,17 +178,34 @@ static void wb_queue_work(struct bdi_writeback *wb,
> > trace_writeback_queue(wb->bdi, work);
> >
> > spin_lock_bh(>work_lock);
> > - if (!test_bit(WB_registered, >state)) {
> > - if (work->done)
> > - complete(work->done);
> > + if (!test_bit(WB_registered, >state))
> > goto out_unlock;
>
> This seems like a change in behavior. Previously unregistered wbs just
> completed the work->done, now you don't complete them. Is that intentional?
If nothing is queued, the cnt is never increased and the wait becomes
noop. The default states are different between completion and
wb_completion. There's no need to do anything to indicate that
nothing needs to be waited.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2 block/for-linus] writeback: don't drain bdi_writeback_congested on bdi destruction
On 07/01/2015 07:53 PM, Tejun Heo wrote:
52ebea749aae ("writeback: make backing_dev_info host cgroup-specific
bdi_writebacks") made bdi (backing_dev_info) host per-cgroup wb's
(bdi_writeback's). As the congested state needs to be per-wb and
referenced from blkcg side and multiple wbs, the patch made all
non-root cong's (bdi_writeback_congested's) reference counted and
indexed on bdi.
Thanks Tejun,
I have applied your patches and no longer see the behavior
mentioned in the bug report. All is well!
-Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails
On Thu, Jul 02, 2015 at 02:03:14AM +, John Youn wrote: > On 6/29/2015 2:48 PM, Felipe Balbi wrote: > > Hi again, > > > > On Mon, Jun 29, 2015 at 04:47:01PM -0500, Felipe Balbi wrote: > >> On Thu, May 21, 2015 at 03:46:48PM +0530, Subbaraya Sundeep Bhatta wrote: > >>> We need to return error to caller if command is not sent to > >>> controller succesfully. > >>> > >>> Signed-off-by: Subbaraya Sundeep Bhatta > >>> Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver) > >>> Cc: > >>> --- > >>> v2 changes: > >>> Added Fixes and Cc in commit message. > >> > >> I noticed that this breaks at least my AM437x silicon with DWC3 2.40a > >> when used with g_zero and testusb. As of now, it could be that silicon > >> is mis-behaving because I got a Transfer Complete before the failing Set > >> Endpoint Transfer Resource command. > >> > >> In any case, can you run on your setup with g_zero and test.sh/testusb > >> [1]/[2] just to verify that it really works for you ? > >> > >> Meanwhile, I'll continue testing on my end. > >> > >> cheers > >> > >> [1] > >> https://gitorious.org/usb/usb-tools/source/47ef073d9b6c0eae816204c81374aafb795c6e40:testusb.c > >> [2] > >> https://gitorious.org/usb/usb-tools/source/47ef073d9b6c0eae816204c81374aafb795c6e40:test.sh > > > > Adding John here. John, any chance you could fire up dwc3 on HAPS and > > see wether it works or fails for you ? > > > > cheers > > > > Hi Felipe, > > Just an update on this. > > I'm trying to get this working with our latest IP with dwc3 from your > testing/next branch. It fails the usbtest with a problem unrelated to > this patch. > > It passes on 4.1.1. > > I'll have to look into the failure but I won't get to it until next > week as I'm off the rest of this week. interesting... If you could post failure signature, I can help looking at it, but I guess it's too late to ask :-) thanks for helping though -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 2/4] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock controllers
Hi Daniel,
> > +Required Properties:
> > +
> > +- compatible: Should be:
> > + - "mediatek,mt8173-imgsys", "syscon"
> > +- #clock-cells: Must be 1
> > +
> > +The imgsys controller uses the common clk binding from
> > +Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +The available clocks are defined in dt-bindings/clock/mt*-clk.h.
> > +
> > +Example:
> > +
> > +imgsys: imgsys@1500 {
>
> Since these nodes will be supplying clocks to the rest of the system,
> I think the "name" part of each of these should all be
> "clock-controller", like topckgen and apmixedsys:
>
> imgsys: clock-controller@1500 {
These subsystems (and topckgen also) also contains other functions such
as reset controller, which may be implemented in clk/mediatek/ in the
future. It is suitable to use "clock-controller" as their name?
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones
On Wed, 2015-07-01 at 19:18 -0700, Paul E. McKenney wrote: > Does their normal workload trigger the condition that results in the > expedited grace period? If so, do they use NO_HZ_FULL? They're having no trouble that I'm aware of, and I definitely would be made aware. They're not currently using a kernel with NO_HZ_FULL even built in, as that stuff is far far too raw in the current kernel. They may meet a NO_HZ_FULL enabled kernel soonish, but will be told to not turn it on for anything other than pure compute, as NO_HZ_FULL is currently not usable for mixed load in partitioned box, much less rt. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Make eBPF programs output data to perf event
On 7/1/15 4:58 AM, Peter Zijlstra wrote: But why create a separate trace buffer, it should go into the regular perf buffer. +1 I think +static char __percpu *perf_extra_trace_buf[PERF_NR_CONTEXTS]; is redundant. It adds quite a bit of unnecessary complexity to the whole patch set. Also the call to bpf_output_sample() is not effective unless program returns 1. It's a confusing user interface. Also you cannot ever do: BPF_FUNC_probe_read, + BPF_FUNC_output_sample, BPF_FUNC_ktime_get_ns, new functions must be added to the end. Why not just do: perf_trace_buf_prepare() + perf_trace_buf_submit() from the helper? No changes to current code. No need to call __get_data_size() and other overhead. The helper can be called multiple times from the same program. imo much cleaner. Also how about calling this helper: bpf_trace_buf_submit(void *stack_ptr, int size) ? bpf_output_sample, I think, is odd name. It's not a sample. May be other name? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 41/51] writeback: make wakeup_flusher_threads() handle multiple bdi_writeback's
Hello, On Wed, Jul 01, 2015 at 10:15:28AM +0200, Jan Kara wrote: > I was looking at who uses wakeup_flusher_threads(). There are two usecases: > > 1) sync() - we want to writeback everything > 2) We want to relieve memory pressure by cleaning and subsequently >reclaiming pages. > > Neither of these cares about number of pages too much if you write enough. What's enough tho? Saying "yeah let's try about 1000 pages" is one thing and "let's try about 1000 pages on each of 100 cgroups" is a quite different operation. Given the nature of "let's try to write some", I'd venture to say that writing somewhat less is an a lot better behavior than possibly trying to write out possibly huge amount given that the amount of fluctuation such behaviors may cause system-wide and how non-obvious the reasons for such fluctuations would be. > So similarly as we don't split the passed nr_pages argument among bdis, I bdi's are bound by actual hardware. wb's aren't. This is a purely logical construct and there can be a lot of them. Again, trying to write 1024 pages on each of 100 devices and trying to write 1024 * 100 pages to single device are quite different. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] mmc: sprd: add MMC host driver for Spreadtrum SoC
On Wed, Jul 1, 2015 at 5:57 PM, Jaehoon Chung wrote: > Hi, > > Is sdhost based on SDHCI controller? > Why don't use sdhci.c? Is there any reason? > > Best Regards, > Jaehoon Chung > Because of base64 code problem of his email server, I'm reporting his reply instead. >From Billows Wu Hi Jaehoon, Sdhost driver is not based on SDHCI controller. Our MMC controller is not a standard controller which meets host controller specification completely. We add some registers and change some bits in the remaining register, such as about clock and regulator portion. If our driver base on SDHCI controller, we must change many codes in sdhci.c, and our MMC driver will become more complicated. In order to better use our controller capability and make MMC driver more compact, we do not use SDHCI controller. Thanks. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 40/51] writeback: make bdi_start_background_writeback() take bdi_writeback instead of backing_dev_info
On Wed, Jul 01, 2015 at 09:50:09AM +0200, Jan Kara wrote: > Can we add a memcg id of the wb to the tracepoint please? Because just bdi > needn't be enough when debugging stuff... Sure, will add cgroup path to identify the actual wb. css IDs aren't visible to userland. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 39/51] writeback: make writeback_in_progress() take bdi_writeback instead of backing_dev_info
Hello, Jan. On Wed, Jul 01, 2015 at 09:47:08AM +0200, Jan Kara wrote: > BTW: It would have been easier for me to review this if e.g. a move from > bdi to wb parameter was split among less patches. The intermediate state > where some functions call partly bdi and party wb functions is strange and > it always makes me go search in the series whether the other part of the > function gets converted and whether they play well together... Similar argument. When reviewing big picture transitions, it *could* be easier to have larger lumps but I believe that's not necessarily because reviewing itself becomes easier but more because it becomes easier to skip what's uninteresting like actually verifying each change. Another aspect is that some of the changes are spread out. When each patch modifies one part, it's clear that all changes in the patch belong to that specific part; however, in larger lumps, there usually are a number of stragglers across the changes and associating them with other parts aren't necessarily trivial. This happens with patch descrption too. It becomes easier to slip in, intentionally or by mistake, unrelated changes without explaining what's going on. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 36/51] writeback: implement bdi_for_each_wb()
On Wed, Jul 01, 2015 at 09:27:57AM +0200, Jan Kara wrote:
> > +#define bdi_for_each_wb(wb_cur, bdi, iter, start_blkcg_id) \
> > + for ((iter)->next_id = (start_blkcg_id);\
> > +({ (wb_cur) = !(iter)->next_id++ ? &(bdi)->wb : NULL; }); )
> > +
>
> This looks quite confusing. Won't it be easier to understand as:
>
> struct wb_iter {
> } __attribute__ ((unused));
>
> #define bdi_for_each_wb(wb_cur, bdi, iter, start_blkcg_id) \
> if (((wb_cur) = (!start_blkcg_id ? &(bdi)->wb : NULL)))
But then break or continue wouldn't work as expected. It can get
really confusing when it's wrapped by an outer loop.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/34] 3.14.47-stable review
On 07/01/2015 11:40 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.47 release. There are 34 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Jul 3 18:39:45 UTC 2015. Anything received after that time might be too late. Build results: total: 120 pass: 120 fail: 0 Qemu test results: total: 30 pass: 30 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones
On Thu, Jul 02, 2015 at 03:59:55AM +0200, Mike Galbraith wrote:
> On Wed, 2015-07-01 at 18:34 -0700, j...@joshtriplett.org wrote:
> > On Thu, Jul 02, 2015 at 03:11:24AM +0200, Mike Galbraith wrote:
> > > On Wed, 2015-07-01 at 09:17 -0700, Paul E. McKenney wrote:
> > > > On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
> > > > > On Wed, Jul 01, 2015 at 07:00:31AM -0700, Paul E. McKenney wrote:
> > > > >
> > > > > > That is a bit extreme, Peter.
> > > > >
> > > > > Of course; but I'm really not seeing people taking due care with them
> > > >
> > > > ;-)
> > > >
> > > > > > Are a huge pile of them coming in this merge window or something?
> > > > > > What raised your concerns on this issue?
> > > > >
> > > > > This is complete horse manure (breaking the nvidiot binary blob is a
> > > > > good thing):
> > > > >
> > > > > 74b51ee152b6 ("ACPI / osl: speedup grace period in
> > > > > acpi_os_map_cleanup")
> > > >
> > > > Really???
> > > >
> > > > I am not concerned about this one. After all, one of the first things
> > > > that people do for OS-jitter-sensitive workloads is to get rid of
> > > > binary blobs.
> > >
> > > I know two users who have no choice but to use the nvidia driver with
> > > their realtime applications, as nouveau is not up to the task.
> >
> > Sounds like they have a relatively loose definition of "realtime", then.
>
> It would be better it they broke their beasts up into a bunch of small
> synchronized boxen, but they use big boxen here and now, with realtime
> rendering being a non-disposable portion of the load.
Does their normal workload trigger the condition that results in the
expedited grace period? If so, do they use NO_HZ_FULL? (I am guessing
"no".) If not, is the resulting double-context-switch on their worker
CPUs a real problem for them? (I am guessing "no" given that they have
not complained, at least not that I know of.)
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] clk: mediatek: mt8173: Fix enabling of critical clocks
Hi Daniel, On Wed, 2015-07-01 at 22:21 +0800, Daniel Kurtz wrote: > To be precise, it is the CLK_TOP clocks that have CLK_APMIXED PLLs as > their parents, so we cannot enable the CLK_TOP critical clocks until > the CLK_APMIXED clocks have all been registered. > > Please add something like the above to the commit message. OK. I'll add them. > > > > > +static struct clk_onecell_data *mt8173_top_clk_data; > > +static struct clk_onecell_data *mt8173_pll_clk_data; > > These globals can be: > __initdata > > > + > > +static void mtk_clk_enable_critical(void) > > And this function is: > > static void __init I'll add them in next patch. Best regards, James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: cpuidle: add __init section marker to arm_cpuidle_init
Dear Krzysztof, On Thu, 2 Jul 2015 10:56:47 +0900 Krzysztof Kozlowski wrote: > 2015-07-02 10:33 GMT+09:00 Jisheng Zhang : > > It is not needed after booting, this patch moves the arm_cpuidle_init() > > function to the __init section. > > > > Signed-off-by: Jisheng Zhang > > --- > > arch/arm64/kernel/cpuidle.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > This looks good but I think you can also mark the stub in > arch/arm64/include/asm/cpuidle.h. > Thanks for review. Has adopted your suggestion in v2. Thanks, Jisheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] arm64: cpuidle: add __init section marker to arm_cpuidle_init
It is not needed after booting, this patch moves the arm_cpuidle_init()
function to the __init section.
Signed-off-by: Jisheng Zhang
---
arch/arm64/include/asm/cpuidle.h | 2 +-
arch/arm64/kernel/cpuidle.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/cpuidle.h b/arch/arm64/include/asm/cpuidle.h
index 0f74f05..5748d3b 100644
--- a/arch/arm64/include/asm/cpuidle.h
+++ b/arch/arm64/include/asm/cpuidle.h
@@ -4,7 +4,7 @@
#include
#ifdef CONFIG_CPU_IDLE
-extern int arm_cpuidle_init(unsigned int cpu);
+extern int __init arm_cpuidle_init(unsigned int cpu);
extern int arm_cpuidle_suspend(int index);
#else
static inline int arm_cpuidle_init(unsigned int cpu)
diff --git a/arch/arm64/kernel/cpuidle.c b/arch/arm64/kernel/cpuidle.c
index 7ce589c..9047cab6 100644
--- a/arch/arm64/kernel/cpuidle.c
+++ b/arch/arm64/kernel/cpuidle.c
@@ -15,7 +15,7 @@
#include
#include
-int arm_cpuidle_init(unsigned int cpu)
+int __init arm_cpuidle_init(unsigned int cpu)
{
int ret = -EOPNOTSUPP;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCHv4 6/7] zsmalloc: account the number of compacted pages
On (07/01/15 16:29), Sergey Senozhatsky wrote:
> if (putback_zspage(.. src_page))
> pool->num_migrated++;
pool->num_migrated += class->pages_per_zspage;
Of course.
> (c) or we can check src_page fullness (or simply if src_page->inuse == 0)
> in __zs_compact() and increment ->num_migrated for ZS_EMPTY page. But this
> is what free_zspage() already does.
In other words, something like this (and we don't need nr_migrated in
zs_compact_control anymore). Not a real patch, just to demonstrate the
idea.
---
@@ -1596,8 +1596,6 @@ struct zs_compact_control {
/* Starting object index within @s_page which used for live object
* in the subpage. */
int index;
- /* How many of objects were migrated */
- int nr_migrated;
};
static int migrate_zspage(struct zs_pool *pool, struct size_class *class,
@@ -1634,7 +1632,6 @@ static int migrate_zspage(struct zs_pool *pool, struct
size_class *class,
record_obj(handle, free_obj);
unpin_tag(handle);
obj_free(pool, class, used_obj);
- cc->nr_migrated++;
}
/* Remember last position in this iteration */
@@ -1720,7 +1717,6 @@ static void __zs_compact(struct zs_pool *pool, struct
size_class *class)
struct page *src_page;
struct page *dst_page = NULL;
- cc.nr_migrated = 0;
spin_lock(>lock);
while ((src_page = isolate_source_page(class))) {
@@ -1748,6 +1744,9 @@ static void __zs_compact(struct zs_pool *pool, struct
size_class *class)
if (dst_page == NULL)
break;
+ if (!src_page->inuse)
+ pool->num_migrated += class->pages_per_zspage;
+
putback_zspage(pool, class, dst_page);
putback_zspage(pool, class, src_page);
spin_unlock(>lock);
@@ -1758,8 +1757,6 @@ static void __zs_compact(struct zs_pool *pool, struct
size_class *class)
if (src_page)
putback_zspage(pool, class, src_page);
- pool->num_migrated += cc.nr_migrated;
-
spin_unlock(>lock);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] clk: mediatek: mt8173: Fix enabling of critical clocks
On Wed, Jul 1, 2015 at 10:21 PM, Daniel Kurtz wrote:
> Hi James,
>
> To be precise, it is the CLK_TOP clocks that have CLK_APMIXED PLLs as
> their parents, so we cannot enable the CLK_TOP critical clocks until
> the CLK_APMIXED clocks have all been registered.
>
> Please add something like the above to the commit message.
>
> More comments inline...
>
> On Tue, Jun 30, 2015 at 10:58 AM, James Liao
> wrote:
>> From: Sascha Hauer
>>
>> On the MT8173 the clocks are provided by different units. To enable
>> the critical clocks we must be sure that all parent clocks are already
>> registered, otherwise the parents of the critical clocks end up being
>> unused and get disabled later. To find a place where all parents are
>> registered we try each time after we've registered some clocks if
>> all known providers are present now and only then we enable the critical
>> clocks
>>
>> Signed-off-by: Sascha Hauer
>> Signed-off-by: James Liao
>> ---
>> drivers/clk/mediatek/clk-mt8173.c | 26 +-
>> 1 file changed, 21 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/clk/mediatek/clk-mt8173.c
>> b/drivers/clk/mediatek/clk-mt8173.c
>> index 4b9e04c..c483336 100644
>> --- a/drivers/clk/mediatek/clk-mt8173.c
>> +++ b/drivers/clk/mediatek/clk-mt8173.c
>> @@ -700,6 +700,22 @@ static const struct mtk_composite peri_clks[]
>> __initconst = {
>> MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c,
>> 3, 1),
>> };
>>
>> +static struct clk_onecell_data *mt8173_top_clk_data;
>> +static struct clk_onecell_data *mt8173_pll_clk_data;
>
> These globals can be:
> __initdata
Oops, never mind about this comment...
Using "__initdata" for uninitialized variables doesn't make sense -
"__initdata" is for initialization data, not variables themselves.
Sorry for the noise,
-Dan
>
>> +
>> +static void mtk_clk_enable_critical(void)
>
> And this function is:
>
> static void __init
>
> Other than the above, this one is:
>
> Reviewed-by: Daniel Kurtz
>
> -Dan
>
>> +{
>> + if (!mt8173_top_clk_data || !mt8173_pll_clk_data)
>> + return;
>> +
>> +
>> clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
>> + clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA7PLL]);
>> + clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_MEM_SEL]);
>> + clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_DDRPHYCFG_SEL]);
>> + clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_CCI400_SEL]);
>> + clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_RTC_SEL]);
>> +}
>> +
>> static void __init mtk_topckgen_init(struct device_node *node)
>> {
>> struct clk_onecell_data *clk_data;
>> @@ -712,19 +728,19 @@ static void __init mtk_topckgen_init(struct
>> device_node *node)
>> return;
>> }
>>
>> - clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
>> + mt8173_top_clk_data = clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
>>
>> mtk_clk_register_factors(root_clk_alias, ARRAY_SIZE(root_clk_alias),
>> clk_data);
>> mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
>> mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes), base,
>> _clk_lock, clk_data);
>>
>> - clk_prepare_enable(clk_data->clks[CLK_TOP_CCI400_SEL]);
>> -
>> r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
>> if (r)
>> pr_err("%s(): could not register clock provider: %d\n",
>> __func__, r);
>> +
>> + mtk_clk_enable_critical();
>> }
>> CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt8173-topckgen", mtk_topckgen_init);
>>
>> @@ -818,13 +834,13 @@ static void __init mtk_apmixedsys_init(struct
>> device_node *node)
>> {
>> struct clk_onecell_data *clk_data;
>>
>> - clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
>> + mt8173_pll_clk_data = clk_data =
>> mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
>> if (!clk_data)
>> return;
>>
>> mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
>>
>> - clk_prepare_enable(clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
>> + mtk_clk_enable_critical();
>> }
>> CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt8173-apmixedsys",
>> mtk_apmixedsys_init);
>> --
>> 1.8.1.1.dirty
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v3 24/24] m68k: Dispatch nvram_ops calls to Atari or Mac functions
On Mon, 29 Jun 2015, Geert Uytterhoeven wrote:
> On Sun, Jun 28, 2015 at 3:42 AM, Finn Thain
> wrote:
> > --- linux.orig/arch/m68k/kernel/setup_mm.c 2015-06-28
> > 11:41:27.0 +1000
> > +++ linux/arch/m68k/kernel/setup_mm.c 2015-06-28 11:41:56.0 +1000
>
> > @@ -568,3 +569,109 @@ static int __init adb_probe_sync_enable
> >
> > __setup("adb_sync", adb_probe_sync_enable);
> > #endif /* CONFIG_ADB */
> > +
> > +#if IS_ENABLED(CONFIG_NVRAM)
> > +extern unsigned char mac_pram_read_byte(int);
> > +extern void mac_pram_write_byte(unsigned char, int);
> > +extern ssize_t mac_pram_get_size(void);
> > +
> > +extern ssize_t atari_nvram_read(char *, size_t, loff_t *);
> > +extern ssize_t atari_nvram_write(char *, size_t, loff_t *);
> > +extern long atari_nvram_set_checksum(void);
> > +extern long atari_nvram_initialize(void);
> > +extern ssize_t atari_nvram_get_size(void);
>
> Forward declarations belong in a header file, to be included by both
> producers and consumers.
Right, will fix. (That was how the v1 patch did this. Looks like I messed
it up.)
>
> > --- linux.orig/arch/m68k/Kconfig2015-06-28 11:41:39.0 +1000
> > +++ linux/arch/m68k/Kconfig 2015-06-28 11:41:56.0 +1000
> > @@ -72,7 +72,7 @@ config PGTABLE_LEVELS
> > default 3
> >
> > config HAVE_ARCH_NVRAM_OPS
> > - def_bool ATARI
> > + def_bool ATARI || MAC
>
> For maintainability, it's better to just have "bool" here, and let both
> the ATARI and MAC config symbols select HAVE_ARCH_NVRAM_OPS.
OK, will fix.
Thanks for your review.
--
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: dts: mt8173: add clock_null
Hi Sascha,
On Wed, 2015-07-01 at 08:49 +0200, Sascha Hauer wrote:
> On Tue, Jun 30, 2015 at 05:07:09PM +0800, James Liao wrote:
> > There are 4 clocks which are derived from clk_null directly in current
> > topckgen implementation:
> >
> > clkph_mck_o, dpi_ck, usb_syspll_125m, hdmitx_dig_cts
> >
> > Our designer mentioned 2 things about external clocks:
> >
> > 1. These 4 clocks come from analog macro, not from PLL, nor from
> > external clocks directly.
>
> Ok, this means there actually are clocks. We can't control these clock and
> they have some known or unknown rate. This makes them fixed clocks. Just
> specify them in the device tree and you are done. Give them reasonable
> names and the rate if you know it, 0 otherwise.
>
> The problem is not that you use fixed clocks for non software
> controllable clocks of unknwown rates, but that you try to use a single
> clock for all of them and name it 'dummy' or 'null'. Name it
>
> dpi_ck {
> compatible = "fixed-clock";
> rate = <0>; /* unknown, generated by some Analog block */
> };
>
> Technically it's the same, but it sounds much more professional and like
> you know what you are doing ;)
These clocks are SoC internal clocks. Is it suitable to specify them in
the device tree?
According to your and Heiko's suggestion, it looks the best way should
be specifying these clocks in the driver code without a dummy parent.
i.e.:
Original code:
FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
New code:
FIXED(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", UNKNOWN_RATE),
FIXED(CLK_TOP_DPI, "dpi_ck", UNKNOWN_RATE),
FIXED(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", UNKNOWN_RATE),
FIXED(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", UNKNOWN_RATE),
Then we don't need to specify a dummy clock such as clk_null in device
tree.
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND v2][GIT PULL] platform-drivers-x86 for 4.2-1
On Tue, Jun 30, 2015 at 2:24 PM, Darren Hart wrote: > > other: Use acpi_video_unregister_backlight instead of acpi_video_unregister in >serveral drivers. This was very annoying. Why? There were several pointless conflicts, because you and Rafael both applied some of the same patches from Hans de Goede, and then Rafael had further cleanups (also from Hans) on top of that, so as a result you have both sides doing changes, but not agreeing on just what the changes are. End result: conflict. The conflicts weren't hard to handle, since generally it was trivial to see that "ok, I had already gotten that change and then some" and just pick Rafael's side. But it's annoying because it shows that you guys are stepping on each others toes, and clearly it's not clear who maintains what. And you guys had clearly both been on the same mail thread, because Rafael had you as acking the changes that you had then also committed in your own tree. Please talk to each other so that you know who takes what, and we don't have this kind of unnecessary duplication and subsequent extra work. A few duplicate commits aren't the end of the world, so it's not like this is a serious problem, but it's an annoyance. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails
On 6/29/2015 2:48 PM, Felipe Balbi wrote: > Hi again, > > On Mon, Jun 29, 2015 at 04:47:01PM -0500, Felipe Balbi wrote: >> On Thu, May 21, 2015 at 03:46:48PM +0530, Subbaraya Sundeep Bhatta wrote: >>> We need to return error to caller if command is not sent to >>> controller succesfully. >>> >>> Signed-off-by: Subbaraya Sundeep Bhatta >>> Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver) >>> Cc: >>> --- >>> v2 changes: >>> Added Fixes and Cc in commit message. >> >> I noticed that this breaks at least my AM437x silicon with DWC3 2.40a >> when used with g_zero and testusb. As of now, it could be that silicon >> is mis-behaving because I got a Transfer Complete before the failing Set >> Endpoint Transfer Resource command. >> >> In any case, can you run on your setup with g_zero and test.sh/testusb >> [1]/[2] just to verify that it really works for you ? >> >> Meanwhile, I'll continue testing on my end. >> >> cheers >> >> [1] >> https://gitorious.org/usb/usb-tools/source/47ef073d9b6c0eae816204c81374aafb795c6e40:testusb.c >> [2] >> https://gitorious.org/usb/usb-tools/source/47ef073d9b6c0eae816204c81374aafb795c6e40:test.sh > > Adding John here. John, any chance you could fire up dwc3 on HAPS and > see wether it works or fails for you ? > > cheers > Hi Felipe, Just an update on this. I'm trying to get this working with our latest IP with dwc3 from your testing/next branch. It fails the usbtest with a problem unrelated to this patch. It passes on 4.1.1. I'll have to look into the failure but I won't get to it until next week as I'm off the rest of this week. Regards, John -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 33/51] writeback: make bdi_has_dirty_io() take multiple bdi_writeback's into account
Hello, Jan. On Tue, Jun 30, 2015 at 06:48:24PM +0200, Jan Kara wrote: > It looks OK although I find using total write bandwidth to detect whether > any wb has any dirty IO rather hacky. Frankly I'd prefer to just iterate > all wbs from bdi_has_dirty_io() since that isn't performance critical > and we iterate all wbs in those paths anyway... Hmm? When there are wb's to write out, maybe walking it twice isn't too bad; however, the problem, I think, is when there's nothing to do. When there are enough number of devices and cgroups, we end up making what used to be a trivial operation something which can be computationally significant. ie. userland behaviors which used to be completely fine because things are very cheap when there's nothing to do can become scalability liabilities. I don't think it's highly likely that this would become a visible issue but I feel pretty uneasy about making O(1) noops O(N), especially given that we need to maintain per-bdi fraction anyway. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v3 02/24] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
On Mon, 29 Jun 2015, Geert Uytterhoeven wrote:
> Hi Finn,
>
> On Sun, Jun 28, 2015 at 3:42 AM, Finn Thain
> wrote:
> > Change the vmode calculation from logical OR to bitwise OR, since it
> > is obviously wrong.
>
> Ideally, that should be a separate patch we can put on the fast track.
If you will fast track a portion of this patch series, that's great. I'll
send a separate patch. (However, IMHO, that portion which would ideally be
fast tracked is a matter of opinion.)
--
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones
On Wed, 2015-07-01 at 18:34 -0700, j...@joshtriplett.org wrote:
> On Thu, Jul 02, 2015 at 03:11:24AM +0200, Mike Galbraith wrote:
> > On Wed, 2015-07-01 at 09:17 -0700, Paul E. McKenney wrote:
> > > On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
> > > > On Wed, Jul 01, 2015 at 07:00:31AM -0700, Paul E. McKenney wrote:
> > > >
> > > > > That is a bit extreme, Peter.
> > > >
> > > > Of course; but I'm really not seeing people taking due care with them
> > >
> > > ;-)
> > >
> > > > > Are a huge pile of them coming in this merge window or something?
> > > > > What raised your concerns on this issue?
> > > >
> > > > This is complete horse manure (breaking the nvidiot binary blob is a
> > > > good thing):
> > > >
> > > > 74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")
> > >
> > > Really???
> > >
> > > I am not concerned about this one. After all, one of the first things
> > > that people do for OS-jitter-sensitive workloads is to get rid of
> > > binary blobs.
> >
> > I know two users who have no choice but to use the nvidia driver with
> > their realtime applications, as nouveau is not up to the task.
>
> Sounds like they have a relatively loose definition of "realtime", then.
It would be better it they broke their beasts up into a bunch of small
synchronized boxen, but they use big boxen here and now, with realtime
rendering being a non-disposable portion of the load.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: cpuidle: add __init section marker to arm_cpuidle_init
2015-07-02 10:33 GMT+09:00 Jisheng Zhang : > It is not needed after booting, this patch moves the arm_cpuidle_init() > function to the __init section. > > Signed-off-by: Jisheng Zhang > --- > arch/arm64/kernel/cpuidle.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) This looks good but I think you can also mark the stub in arch/arm64/include/asm/cpuidle.h. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Input: wdt87xx_i2c - Add a scaling factor for TOUCH_MAJOR event
Hi, Dmitry,
Ok, Thanks
I really appreciate your help !
BR,
Hn.chen
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Thursday, July 02, 2015 2:35 AM
To: Hn Chen
Cc: linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Input: wdt87xx_i2c - Add a scaling factor for TOUCH_MAJOR
event
On Wed, Jul 01, 2015 at 04:18:37PM +0800, HungNien Chen wrote:
> Get the scaling factor when it reads the sys params. The width value
> will multiple the factor and report the value in the TOUCH_MAJOR event.
>
> Signed-off-by: HungNien Chen
Applied, thank you, but I changed scl_fctr to scale_factor.
> ---
> drivers/input/touchscreen/wdt87xx_i2c.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/input/touchscreen/wdt87xx_i2c.c
> b/drivers/input/touchscreen/wdt87xx_i2c.c
> index c073ea9..b958d18 100644
> --- a/drivers/input/touchscreen/wdt87xx_i2c.c
> +++ b/drivers/input/touchscreen/wdt87xx_i2c.c
> @@ -23,7 +23,7 @@
> #include
>
> #define WDT87XX_NAME "wdt87xx_i2c"
> -#define WDT87XX_DRV_VER "0.9.5"
> +#define WDT87XX_DRV_VER "0.9.6"
> #define WDT87XX_FW_NAME "wdt87xx_fw.bin"
> #define WDT87XX_CFG_NAME "wdt87xx_cfg.bin"
>
> @@ -83,6 +83,7 @@
> #define CTL_PARAM_OFFSET_PHY_Y1 18
> #define CTL_PARAM_OFFSET_PHY_W 22
> #define CTL_PARAM_OFFSET_PHY_H 24
> +#define CTL_PARAM_OFFSET_FACTOR 32
>
> /* Communication commands */
> #define PACKET_SIZE 56
> @@ -161,6 +162,7 @@ struct wdt87xx_sys_param {
> u16 phy_ch_y;
> u16 phy_w;
> u16 phy_h;
> + u16 scl_fctr;
> u32 max_x;
> u32 max_y;
> };
> @@ -401,7 +403,7 @@ static int wdt87xx_get_sysparam(struct i2c_client *client,
> u8 buf[PKT_READ_SIZE];
> int error;
>
> - error = wdt87xx_get_string(client, STRIDX_PARAMETERS, buf, 32);
> + error = wdt87xx_get_string(client, STRIDX_PARAMETERS, buf, 34);
> if (error) {
> dev_err(>dev, "failed to get parameters\n");
> return error;
> @@ -414,6 +416,9 @@ static int wdt87xx_get_sysparam(struct i2c_client *client,
> param->phy_w = get_unaligned_le16(buf + CTL_PARAM_OFFSET_PHY_W) / 10;
> param->phy_h = get_unaligned_le16(buf + CTL_PARAM_OFFSET_PHY_H) /
> 10;
>
> + /* Get the scaling factor of pixel to logcial coordinate */
> + param->scl_fctr = get_unaligned_le16(buf + CTL_PARAM_OFFSET_FACTOR);
> +
> param->max_x = MAX_UNIT_AXIS;
> param->max_y = DIV_ROUND_CLOSEST(MAX_UNIT_AXIS * param->phy_h,
>param->phy_w);
> @@ -905,8 +910,8 @@ static void wdt87xx_report_contact(struct input_dev
> *input,
> u8 *buf)
> {
> int finger_id;
> - u32 x, y;
> - u8 w, p;
> + u32 x, y, w;
> + u8 p;
>
> finger_id = (buf[FINGER_EV_V1_OFFSET_ID] >> 3) - 1;
> if (finger_id < 0)
> @@ -917,6 +922,8 @@ static void wdt87xx_report_contact(struct input_dev
> *input,
> return;
>
> w = buf[FINGER_EV_V1_OFFSET_W];
> + w = w * param->scl_fctr;
> +
> p = buf[FINGER_EV_V1_OFFSET_P];
>
> x = get_unaligned_le16(buf + FINGER_EV_V1_OFFSET_X); @@ -995,7
> +1002,8 @@ static int wdt87xx_ts_create_input_device(struct wdt87xx_data *wdt)
> input_abs_set_res(input, ABS_MT_POSITION_X, res);
> input_abs_set_res(input, ABS_MT_POSITION_Y, res);
>
> - input_set_abs_params(input, ABS_MT_TOUCH_MAJOR, 0, 0xFF, 0, 0);
> + input_set_abs_params(input, ABS_MT_TOUCH_MAJOR, 0,
> + wdt->param.max_x, 0, 0);
> input_set_abs_params(input, ABS_MT_PRESSURE, 0, 0xFF, 0, 0);
>
> input_mt_init_slots(input, WDT_MAX_FINGER,
> --
> 1.9.1
>
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/51] writeback: implement and use inode_congested()
Hello, On Tue, Jun 30, 2015 at 05:21:05PM +0200, Jan Kara wrote: > Hum, is there any point in supporting NULL inode with inode_congested()? > That would look more like a programming bug than anything... Otherwise the > patch looks good to me so you can add: Those are inherited from the existing usages and all for swapper space. I think we should have a dummy inode instead of scattering NULL mapping->host test all over the place but that's for another day. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] kexec: Make a pair of map and unmap reserved pages when kdump fails to start
For some arch, kexec shall map the reserved pages, then use them, when
we try to start the kdump service.
Now kexec will never unmap the reserved pages, once it fails to continue
starting the kdump service.
Make a pair of reserved pages in kdump starting path, whatever kexec
fails or not.
Signed-off-by: Minfei Huang
---
v2:
- replace the "failure" label with "fail_unmap_pages"
v1:
- reconstruct the patch code
---
kernel/kexec.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 4589899..9cb09d9 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1291,35 +1291,37 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry,
unsigned long, nr_segments,
*/
kimage_free(xchg(_crash_image, NULL));
- result = kimage_alloc_init(, entry, nr_segments,
- segments, flags);
- crash_map_reserved_pages();
- } else {
- /* Loading another kernel to reboot into. */
-
- result = kimage_alloc_init(, entry, nr_segments,
- segments, flags);
}
+
+ result = kimage_alloc_init(, entry, nr_segments,
+ segments, flags);
if (result)
goto out;
+ if (flags & KEXEC_ON_CRASH)
+ crash_map_reserved_pages();
+
if (flags & KEXEC_PRESERVE_CONTEXT)
image->preserve_context = 1;
result = machine_kexec_prepare(image);
if (result)
- goto out;
+ goto fail_unmap_pages;
for (i = 0; i < nr_segments; i++) {
result = kimage_load_segment(image, >segment[i]);
if (result)
- goto out;
+ goto fail_unmap_pages;
}
kimage_terminate(image);
+
+fail_unmap_pages:
if (flags & KEXEC_ON_CRASH)
crash_unmap_reserved_pages();
}
- /* Install the new kernel, and Uninstall the old */
- image = xchg(dest_image, image);
+
+ if (result == 0)
+ /* Install the new kernel, and Uninstall the old */
+ image = xchg(dest_image, image);
out:
mutex_unlock(_mutex);
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Payment
Dear Winner, You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146. This compensation funds from the United Nation.Send us your personal details to deliver your funds. Gloria Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 28/51] writeback, blkcg: restructure blk_{set|clear}_queue_congested()
Hello, Jan. On Tue, Jun 30, 2015 at 05:02:54PM +0200, Jan Kara wrote: > BTW, I'd prefer if this was merged with the following patch. I was > wondering for a while about the condition at the beginning of > blk_clear_congested() only to learn it gets modified to the one I'd expect > in the following patch :) The patches are already merged, it's a bit too late to discuss but I usually try to keep each step quite granular. e.g. I try hard to avoid combining code relocation / restructuring with actual functional changes so that the code change A -> B -> C where B is functionally identical to A and C is different from B only where the actual functional changes occur. I think your argument is that as C is the final form, introducing B is actually harder for reviewing. I have to disagree with that pretty strongly. When you only think about the functional transformations A -> C might seem easier but given that we also want to verify the changes - both during development and review - it's far more beneficial to go through the intermediate stage as that isolates functional changes from mere code transformation. Another thing to consider is that there's a difference when one is reviewing a patch series as a whole tracking the development of big picture and later when somebody tries to debug or bisect a bug the patchset introduces. At that point, the general larger flow isn't really in the picture and combining structural and functional changes may make understanding what's going on significantly harder in addition to making such errors more likely and less detectable in the first place. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones
On Thu, Jul 02, 2015 at 03:11:24AM +0200, Mike Galbraith wrote:
> On Wed, 2015-07-01 at 09:17 -0700, Paul E. McKenney wrote:
> > On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
> > > On Wed, Jul 01, 2015 at 07:00:31AM -0700, Paul E. McKenney wrote:
> > >
> > > > That is a bit extreme, Peter.
> > >
> > > Of course; but I'm really not seeing people taking due care with them
> >
> > ;-)
> >
> > > > Are a huge pile of them coming in this merge window or something?
> > > > What raised your concerns on this issue?
> > >
> > > This is complete horse manure (breaking the nvidiot binary blob is a
> > > good thing):
> > >
> > > 74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")
> >
> > Really???
> >
> > I am not concerned about this one. After all, one of the first things
> > that people do for OS-jitter-sensitive workloads is to get rid of
> > binary blobs.
>
> I know two users who have no choice but to use the nvidia driver with
> their realtime applications, as nouveau is not up to the task.
Sounds like they have a relatively loose definition of "realtime", then.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: cpuidle: add __init section marker to arm_cpuidle_init
It is not needed after booting, this patch moves the arm_cpuidle_init()
function to the __init section.
Signed-off-by: Jisheng Zhang
---
arch/arm64/kernel/cpuidle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cpuidle.c b/arch/arm64/kernel/cpuidle.c
index 7ce589c..9047cab6 100644
--- a/arch/arm64/kernel/cpuidle.c
+++ b/arch/arm64/kernel/cpuidle.c
@@ -15,7 +15,7 @@
#include
#include
-int arm_cpuidle_init(unsigned int cpu)
+int __init arm_cpuidle_init(unsigned int cpu)
{
int ret = -EOPNOTSUPP;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/2] cpufreq: mediatek: Add MT8173 cpufreq driver
Hi Alexey,
On Thu, Jul 2, 2015 at 5:24 AM, Alexey Klimov wrote:
> Hi Pi-Cheng,
>
> On Wed, Jul 1, 2015 at 5:16 AM, Pi-Cheng Chen
> wrote:
>> This patch implements MT8173 cpufreq driver.
>>
>> Signed-off-by: Pi-Cheng Chen
>> ---
>> drivers/cpufreq/Kconfig.arm | 7 +
>> drivers/cpufreq/Makefile | 1 +
>> drivers/cpufreq/mt8173-cpufreq.c | 520
>> +++
>> 3 files changed, 528 insertions(+)
>> create mode 100644 drivers/cpufreq/mt8173-cpufreq.c
>>
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> index 611cb09..2a305c0 100644
>> --- a/drivers/cpufreq/Kconfig.arm
>> +++ b/drivers/cpufreq/Kconfig.arm
>> @@ -141,6 +141,13 @@ config ARM_KIRKWOOD_CPUFREQ
>> This adds the CPUFreq driver for Marvell Kirkwood
>> SoCs.
>>
>> +config ARM_MT8173_CPUFREQ
>> + bool "Mediatek MT8173 CPUFreq support"
>> + depends on ARCH_MEDIATEK && REGULATOR
>> + select PM_OPP
>> + help
>> + This adds the CPUFreq driver support for Mediatek MT8173 SoC.
>> +
>> config ARM_OMAP2PLUS_CPUFREQ
>> bool "TI OMAP2+"
>> depends on ARCH_OMAP2PLUS
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index cdce92a..97f9a9b 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -63,6 +63,7 @@ obj-$(CONFIG_ARM_HISI_ACPU_CPUFREQ) +=
>> hisi-acpu-cpufreq.o
>> obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
>> obj-$(CONFIG_ARM_INTEGRATOR) += integrator-cpufreq.o
>> obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
>> +obj-$(CONFIG_ARM_MT8173_CPUFREQ) += mt8173-cpufreq.o
>> obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
>> obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
>> obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
>> diff --git a/drivers/cpufreq/mt8173-cpufreq.c
>> b/drivers/cpufreq/mt8173-cpufreq.c
>> new file mode 100644
>> index 000..6284e67
>> --- /dev/null
>> +++ b/drivers/cpufreq/mt8173-cpufreq.c
>> @@ -0,0 +1,520 @@
>> +/*
>> + * Copyright (c) 2015 Linaro Ltd.
>> + * Author: Pi-Cheng Chen
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define MIN_VOLT_SHIFT (10)
>> +#define MAX_VOLT_SHIFT (20)
>> +#define MAX_VOLT_LIMIT (115)
>> +#define VOLT_TOL (1)
>> +
>> +/*
>> + * The struct mtk_cpu_dvfs_info holds necessary information for doing CPU
>> DVFS
>> + * on each CPU power/clock domain of Mediatek SoCs. Each CPU cluster in
>> + * Mediatek SoCs has two voltage inputs, Vproc and Vsram. In some cases the
>> two
>> + * voltage inputs need to be controlled under a hardware limitation:
>> + * 100mV < Vsram - Vproc < 200mV
>> + *
>> + * When scaling the clock frequency of a CPU clock domain, the clock source
>> + * needs to be switched to another stable PLL clock temporarily until
>> + * the original PLL becomes stable at target frequency.
>> + */
>> +struct mtk_cpu_dvfs_info {
>> + struct device *cpu_dev;
>> + struct regulator *proc_reg;
>> + struct regulator *sram_reg;
>> + struct clk *cpu_clk;
>> + struct clk *inter_clk;
>> + struct thermal_cooling_device *cdev;
>> + int intermediate_voltage;
>> + bool need_voltage_trace;
>> +};
>> +
>> +static int mtk_cpufreq_voltage_trace(struct mtk_cpu_dvfs_info *info,
>> +int new_vproc)
>> +{
>> + struct regulator *proc_reg = info->proc_reg;
>> + struct regulator *sram_reg = info->sram_reg;
>> + int old_vproc, old_vsram, new_vsram, vsram, vproc, ret;
>> +
>> + old_vproc = regulator_get_voltage(proc_reg);
>> + old_vsram = regulator_get_voltage(sram_reg);
>> + /* Vsram should not exceed the maximum allowed voltage of SoC. */
>> + new_vsram = min(new_vproc + MIN_VOLT_SHIFT, MAX_VOLT_LIMIT);
>> +
>> + if (old_vproc < new_vproc) {
>> + /*
>> +* When scaling up voltages, Vsram and Vproc scale up step
>> +* by step. At each step, set Vsram to (Vproc + 200mV) first,
>> +* then set Vproc to (Vsram - 100mV).
>> +* Keep doing it until Vsram and Vproc hit target voltages.
>> +*/
>> + do {
>> + old_vsram =
Re: [PATCH 26/51] writeback: let balance_dirty_pages() work on the matching cgroup bdi_writeback
Hello, Jan. On Tue, Jun 30, 2015 at 04:31:00PM +0200, Jan Kara wrote: ... > > + if (inode_cgwb_enabled(inode)) > > + wb = wb_get_create_current(bdi, GFP_KERNEL); > > + if (!wb) > > + wb = >wb; > > + > > So this effectively adds a radix tree lookup (of wb belonging to memcg) for > every set_page_dirty() call. That seems relatively costly to me. And all Hmmm... idk, radix tree lookups should be cheap especially when shallow and set_page_dirty(). It's a glorified array indexing. If not, we should really be improving radix tree implementation. That said, > that just to check wb->dirty_exceeded. Cannot we just use inode_to_wb() > instead? I understand results may be different if multiple memcgs share an > inode and that's the reason why you use wb_get_create_current(), right? > But for dirty_exceeded check it may be good enough? Yeah, that probably should work. I'll think more about it. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 22/51] writeback: add {CONFIG|BDI_CAP|FS}_CGROUP_WRITEBACK
Hello, Jan. On Tue, Jun 30, 2015 at 11:37:51AM +0200, Jan Kara wrote: > Hum, you later changed this to use a per-sb flag instead of a per-fs-type > flag, right? We could do it as well here but OK. The commits were already in stable branch at that point and landed in mainline during this merge window, so I'm afraid the review points will have to be addressed as additional patches. > One more question - what does prevent us from supporting CGROUP_WRITEBACK > for all bdis capable of writeback? I guess the reason is that currently > blkcgs are bound to request_queue and we have to have blkcg(s) for > CGROUP_WRITEBACK to work, am I right? But in principle tracking writeback > state and doing writeback per memcg doesn't seem to be bound to any device > properties so we could do that right? The main issue is that cgroup should somehow know how the processes are mapped to the underlying IO layer - the IO domain should somehow be defined. We can introduce an intermediate abstraction which maps to blkcg and whatever other cgroup controllers which may define cgroup IO domains but given that such cases would be fairly niche, I think we'd be better off making those corner cases represent themselves using blkcg rather than introducing an additional layer. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones
On Wed, 2015-07-01 at 09:17 -0700, Paul E. McKenney wrote:
> On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 01, 2015 at 07:00:31AM -0700, Paul E. McKenney wrote:
> >
> > > That is a bit extreme, Peter.
> >
> > Of course; but I'm really not seeing people taking due care with them
>
> ;-)
>
> > > Are a huge pile of them coming in this merge window or something?
> > > What raised your concerns on this issue?
> >
> > This is complete horse manure (breaking the nvidiot binary blob is a
> > good thing):
> >
> > 74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")
>
> Really???
>
> I am not concerned about this one. After all, one of the first things
> that people do for OS-jitter-sensitive workloads is to get rid of
> binary blobs.
I know two users who have no choice but to use the nvidia driver with
their realtime applications, as nouveau is not up to the task.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/48] Make the IRQCHIP_DECLARE macro globally accessible
At the moment the IRQCHIP_DECLARE macro is only declared locally in 'drivers/irqchip/irqchip.h'. That prevents from using it directly in arch/* directories whenever irqchip drivers only exist there, which happens in a few cases (e.g. arc, arm, microblaze and mips). This patch makes the macro to be globally defined, in include/linux/irqchip.h, and thus usable for arch-specific declarations of irqchip drivers. In this way, it is very similar to what clocksource does (ie CLOCKSOURCE_OF_DECLARE is defined in include/linux/clocksource.h). I split up everything into patches to make the integration easier. Please let me know if it's not, and in such case how to make it better. For now, patch 01 of this series transfers the declaration of the macro IRQCHIP_DECLARE to the global header 'include/linux/irqchip.h'. The following patches, from 02 to 47, modify all the irqchip drivers that use IRQCHIP_DECLARE, one by one. And finally, the last patch 48 removes the private and now useless header 'drivers/irqchip/irqchip.h'. Joel Joel Porquet (48): irqchip: move IRQCHIP_DECLARE macro to include/linux/irqchip.h irqchip:exynos-combiner: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:armada-370-xp: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:atmel-aic5: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:atmel-aic: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:bcm2835: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:bcm7038-l1: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:bcm7120-l2: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:brcmstb-l2: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:clps711x: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:crossbar: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:digicolor: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:dw-apb-ictl: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:gic: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:gic-v3: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:gic-v3-its: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:hip04: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:keystone: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:mips-gic: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:mmp: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:moxart: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:mtk-sysirq: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:mxs: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:nvic: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:omap-intc: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:or1k-pic: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:orion: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:s3c24xx: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:sirfsoc: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:sun4i: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:sunxi-nmi: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:tb10x: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:tegra: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:versatile-fpga: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:vf610-mscm-ir: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:vic: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:vt8500: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:xtensa-mx: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:xtensa-pic: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:zevio: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h irqchip:spear-shirq: IRQCHIP_DECLARE macro moved to include/linux/irqchip.h arc:irqchip: IRQCHIP_DECLARE macro is now accessible microblaze:irqchip: IRQCHIP_DECLARE macro is now accessible mips:irqchip: IRQCHIP_DECLARE macro is now accessible arm:exynos:irqchip: IRQCHIP_DECLARE macro is now accessible arm:imx:irqchip: IRQCHIP_DECLARE macro is now accessible arm:omap2:irqchip: IRQCHIP_DECLARE macro is now accessible irqchip: remove header drivers/irqchip/irqchip.h arch/arc/kernel/irq.c| 1 - arch/arm/mach-exynos/suspend.c | 3 ++- arch/arm/mach-imx/gpc.c | 7 ++- arch/arm/mach-omap2/omap-wakeupgen.c | 6 +- arch/microblaze/kernel/intc.c| 3 +-- arch/mips/bmips/irq.c| 2 +- drivers/irqchip/exynos-combiner.c| 3 +-- drivers/irqchip/irq-armada-370-xp.c
Re:Re: [PATCH] sched: fix BUG in preempt_notifier
This is a better way to solve this bug.
Thanks.
At 2015-07-01 15:41:28, "Wanpeng Li" wrote:
>
>
>On 7/1/15 2:33 PM, Lidong Chen wrote:
>> Signed-off-by: Lidong Chen
>
>Subject: sched,kvm: Fix KVM preempt_notifier usage
>
>The preempt-notifier API needs to sleep with the addition of the
>static_key, we do however need to hold off preemption while modifying
>the preempt notifier list, otherwise a preemption could observe an
>inconsistent list state.
>
>There is no reason to have preemption disabled in the caller,
>registering a preempt notifier is a purely task local affair.
>
>Therefore move the preempt_disable into the functions and change the
>callers to a preemptible context.
>
>Cc: Gleb Natapov
>Fixes: 1cde2930e154 ("sched/preempt: Add static_key() to preempt_notifiers")
>Reported-and-Tested-by: Pontus Fuchs
>Signed-off-by: Peter Zijlstra (Intel)
>
>
>If this commit in tip tree fix your bug?
>
>Regards,
>Wanpeng Li
>
>> ---
>> kernel/sched/core.c | 25 -
>> 1 file changed, 4 insertions(+), 21 deletions(-)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index b803e1b..4a5a964 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -2318,15 +2318,12 @@ void wake_up_new_task(struct task_struct *p)
>>
>> #ifdef CONFIG_PREEMPT_NOTIFIERS
>>
>> -static struct static_key preempt_notifier_key = STATIC_KEY_INIT_FALSE;
>> -
>> /**
>>* preempt_notifier_register - tell me when current is being preempted &
>> rescheduled
>>* @notifier: notifier struct to register
>>*/
>> void preempt_notifier_register(struct preempt_notifier *notifier)
>> {
>> -static_key_slow_inc(_notifier_key);
>> hlist_add_head(>link, >preempt_notifiers);
>> }
>> EXPORT_SYMBOL_GPL(preempt_notifier_register);
>> @@ -2340,11 +2337,10 @@ EXPORT_SYMBOL_GPL(preempt_notifier_register);
>> void preempt_notifier_unregister(struct preempt_notifier *notifier)
>> {
>> hlist_del(>link);
>> -static_key_slow_dec(_notifier_key);
>> }
>> EXPORT_SYMBOL_GPL(preempt_notifier_unregister);
>>
>> -static void __fire_sched_in_preempt_notifiers(struct task_struct *curr)
>> +static void fire_sched_in_preempt_notifiers(struct task_struct *curr)
>> {
>> struct preempt_notifier *notifier;
>>
>> @@ -2352,14 +2348,9 @@ static void __fire_sched_in_preempt_notifiers(struct
>> task_struct *curr)
>> notifier->ops->sched_in(notifier, raw_smp_processor_id());
>> }
>>
>> -static __always_inline void fire_sched_in_preempt_notifiers(struct
>> task_struct *curr)
>> -{
>> -if (static_key_false(_notifier_key))
>> -__fire_sched_in_preempt_notifiers(curr);
>> -}
>>
>> static void
>> -__fire_sched_out_preempt_notifiers(struct task_struct *curr,
>> +fire_sched_out_preempt_notifiers(struct task_struct *curr,
>> struct task_struct *next)
>> {
>> struct preempt_notifier *notifier;
>> @@ -2368,21 +2359,13 @@ __fire_sched_out_preempt_notifiers(struct
>> task_struct *curr,
>> notifier->ops->sched_out(notifier, next);
>> }
>>
>> -static __always_inline void
>> -fire_sched_out_preempt_notifiers(struct task_struct *curr,
>> - struct task_struct *next)
>> -{
>> -if (static_key_false(_notifier_key))
>> -__fire_sched_out_preempt_notifiers(curr, next);
>> -}
>> -
>> #else /* !CONFIG_PREEMPT_NOTIFIERS */
>>
>> -static inline void fire_sched_in_preempt_notifiers(struct task_struct *curr)
>> +static void fire_sched_in_preempt_notifiers(struct task_struct *curr)
>> {
>> }
>>
>> -static inline void
>> +static void
>> fire_sched_out_preempt_notifiers(struct task_struct *curr,
>> struct task_struct *next)
>> {
>
[PATCH 2/2 block/for-linus] writeback: don't drain bdi_writeback_congested on bdi destruction
52ebea749aae ("writeback: make backing_dev_info host cgroup-specific
bdi_writebacks") made bdi (backing_dev_info) host per-cgroup wb's
(bdi_writeback's). As the congested state needs to be per-wb and
referenced from blkcg side and multiple wbs, the patch made all
non-root cong's (bdi_writeback_congested's) reference counted and
indexed on bdi.
When a bdi is destroyed, cgwb_bdi_destroy() tries to drain all
non-root cong's; however, this can hang indefinitely because wb's can
also be referenced from blkcg_gq's which are destroyed after bdi
destruction is complete.
This patch fixes the bug by updating bdi destruction to not wait for
cong's to drain. A cong is unlinked from bdi->cgwb_congested_tree on
bdi destuction regardless of its reference count as the bdi may go
away any point after destruction. wb_congested_put() checks whether
the cong is already unlinked on release.
Signed-off-by: Tejun Heo
Reported-by: Jon Christopherson
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100681
Fixes: 52ebea749aae ("writeback: make backing_dev_info host cgroup-specific
bdi_writebacks")
---
mm/backing-dev.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -425,7 +425,6 @@ retry:
new_congested = NULL;
rb_link_node(>rb_node, parent, node);
rb_insert_color(>rb_node, >cgwb_congested_tree);
- atomic_inc(>usage_cnt);
goto found;
}
@@ -456,7 +455,6 @@ found:
*/
void wb_congested_put(struct bdi_writeback_congested *congested)
{
- struct backing_dev_info *bdi = congested->bdi;
unsigned long flags;
local_irq_save(flags);
@@ -465,12 +463,15 @@ void wb_congested_put(struct bdi_writeba
return;
}
- rb_erase(>rb_node, >bdi->cgwb_congested_tree);
+ /* bdi might already have been destroyed leaving @congested unlinked */
+ if (congested->bdi) {
+ rb_erase(>rb_node,
+>bdi->cgwb_congested_tree);
+ congested->bdi = NULL;
+ }
+
spin_unlock_irqrestore(_lock, flags);
kfree(congested);
-
- if (atomic_dec_and_test(>usage_cnt))
- wake_up_all(_release_wait);
}
static void cgwb_release_workfn(struct work_struct *work)
@@ -675,13 +676,22 @@ static int cgwb_bdi_init(struct backing_
static void cgwb_bdi_destroy(struct backing_dev_info *bdi)
{
struct radix_tree_iter iter;
+ struct bdi_writeback_congested *congested, *congested_n;
void **slot;
WARN_ON(test_bit(WB_registered, >wb.state));
spin_lock_irq(_lock);
+
radix_tree_for_each_slot(slot, >cgwb_tree, , 0)
cgwb_kill(*slot);
+
+ rbtree_postorder_for_each_entry_safe(congested, congested_n,
+ >cgwb_congested_tree, rb_node) {
+ rb_erase(>rb_node, >cgwb_congested_tree);
+ congested->bdi = NULL; /* mark @congested unlinked */
+ }
+
spin_unlock_irq(_lock);
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2 block/for-linus] writeback: don't embed root bdi_writeback_congested in bdi_writeback
52ebea749aae ("writeback: make backing_dev_info host cgroup-specific
bdi_writebacks") made bdi (backing_dev_info) host per-cgroup wb's
(bdi_writeback's). As the congested state needs to be per-wb and
referenced from blkcg side and multiple wbs, the patch made all
non-root cong's (bdi_writeback_congested's) reference counted and
indexed on bdi.
When a bdi is destroyed, cgwb_bdi_destroy() tries to drain all
non-root cong's; however, this can hang indefinitely because wb's can
also be referenced from blkcg_gq's which are destroyed after bdi
destruction is complete.
To fix the bug, bdi destruction will be updated to not wait for cong's
to drain, which naturally means that cong's may outlive the associated
bdi. This is fine for non-root cong's but is problematic for the root
cong's which are embedded in their bdi's as they may end up getting
dereferenced after the containing bdi's are freed.
This patch makes root cong's behave the same as non-root cong's. They
are no longer embedded in their bdi's but allocated separately during
bdi initialization, indexed and reference counted the same way.
* As cong handling is the same for all wb's, wb->congested
initialization is moved into wb_init().
* When !CONFIG_CGROUP_WRITEBACK, there was no indexing or refcnting.
bdi->wb_congested is now a pointer pointing to the root cong
allocated during bdi init and minimal refcnting operations are
implemented.
* The above makes root wb init paths diverge depending on
CONFIG_CGROUP_WRITEBACK. root wb init is moved to cgwb_bdi_init().
This patch in itself shouldn't cause any consequential behavior
differences but prepares for the actual fix.
Signed-off-by: Tejun Heo
Reported-by: Jon Christopherson
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100681
---
Hello,
These two patches are to fix a deadlock during bdi destruction which
was introduced by cgroup writeback changes. Jens, can you please
route these two once Jon confirms the fix?
Thanks.
include/linux/backing-dev-defs.h |5 +-
include/linux/backing-dev.h |5 +-
mm/backing-dev.c | 87 ---
3 files changed, 53 insertions(+), 44 deletions(-)
--- a/include/linux/backing-dev-defs.h
+++ b/include/linux/backing-dev-defs.h
@@ -50,10 +50,10 @@ enum wb_stat_item {
*/
struct bdi_writeback_congested {
unsigned long state;/* WB_[a]sync_congested flags */
+ atomic_t refcnt;/* nr of attached wb's and blkg */
#ifdef CONFIG_CGROUP_WRITEBACK
struct backing_dev_info *bdi; /* the associated bdi */
- atomic_t refcnt;/* nr of attached wb's and blkg */
int blkcg_id; /* ID of the associated blkcg */
struct rb_node rb_node; /* on bdi->cgwb_congestion_tree */
#endif
@@ -150,11 +150,12 @@ struct backing_dev_info {
atomic_long_t tot_write_bandwidth;
struct bdi_writeback wb; /* the root writeback info for this bdi */
- struct bdi_writeback_congested wb_congested; /* its congested state */
#ifdef CONFIG_CGROUP_WRITEBACK
struct radix_tree_root cgwb_tree; /* radix tree of active cgroup wbs */
struct rb_root cgwb_congested_tree; /* their congested states */
atomic_t usage_cnt; /* counts both cgwbs and cgwb_contested's */
+#else
+ struct bdi_writeback_congested *wb_congested;
#endif
wait_queue_head_t wb_waitq;
--- a/include/linux/backing-dev.h
+++ b/include/linux/backing-dev.h
@@ -465,11 +465,14 @@ static inline bool inode_cgwb_enabled(st
static inline struct bdi_writeback_congested *
wb_congested_get_create(struct backing_dev_info *bdi, int blkcg_id, gfp_t gfp)
{
- return bdi->wb.congested;
+ atomic_inc(>wb_congested->refcnt);
+ return bdi->wb_congested;
}
static inline void wb_congested_put(struct bdi_writeback_congested *congested)
{
+ if (atomic_dec_and_test(>refcnt))
+ kfree(congested);
}
static inline struct bdi_writeback *wb_find_current(struct backing_dev_info
*bdi)
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -287,7 +287,7 @@ void wb_wakeup_delayed(struct bdi_writeb
#define INIT_BW(100 << (20 - PAGE_SHIFT))
static int wb_init(struct bdi_writeback *wb, struct backing_dev_info *bdi,
- gfp_t gfp)
+ int blkcg_id, gfp_t gfp)
{
int i, err;
@@ -311,21 +311,29 @@ static int wb_init(struct bdi_writeback
INIT_LIST_HEAD(>work_list);
INIT_DELAYED_WORK(>dwork, wb_workfn);
+ wb->congested = wb_congested_get_create(bdi, blkcg_id, gfp);
+ if (!wb->congested)
+ return -ENOMEM;
+
err = fprop_local_init_percpu(>completions, gfp);
if (err)
- return err;
+ goto out_put_cong;
for (i = 0; i < NR_WB_STAT_ITEMS; i++) {
err = percpu_counter_init(>stat[i], 0, gfp);
- if (err) {
-
Re: [PATCH] power_supply: rt9455_charger: Properly notify userspace about charging events
2015-06-18 1:28 GMT+09:00 Anda-Maria Nicolae :
> Do not call power_supply_changed() when CHRVPI interrupt has occurred.
What I cannot find here is the answer to: why? I am not familiar with
the driver so this is just guessing that you wanted to notify
userspace about connected/disconnected charger. In both cases (before
and after the patch) this is achieved, isn't it?
Best regards,
Krzysztof
> CHRVPI interrupt occurs when the charger is connected to or disconnected
> from the power source. Call power_supply_changed() after PWR_RDY bit is
> read, to distinguish between connection to or disconnection from the power
> source.
> Also, call power_supply_changed() after the battery is reconnected to the
> charger, to notify userspace that the battery is no longer absent.
>
> Signed-off-by: Anda-Maria Nicolae
> ---
> drivers/power/rt9455_charger.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/power/rt9455_charger.c b/drivers/power/rt9455_charger.c
> index 08baac6..a49a9d4 100644
> --- a/drivers/power/rt9455_charger.c
> +++ b/drivers/power/rt9455_charger.c
> @@ -973,7 +973,6 @@ static int rt9455_irq_handler_check_irq2_register(struct
> rt9455_info *info,
>
> if (irq2 & GET_MASK(F_CHRVPI)) {
> dev_dbg(dev, "Charger fault occurred\n");
> - alert_userspace = true;
> /*
> * CHRVPI bit is set in 2 cases:
> * 1. when the power source is connected to the charger.
> @@ -981,6 +980,9 @@ static int rt9455_irq_handler_check_irq2_register(struct
> rt9455_info *info,
> * To identify the case, PWR_RDY bit is checked. Because
> * PWR_RDY bit is set / cleared after CHRVPI interrupt is
> * triggered, it is used delayed_work to later read PWR_RDY
> bit.
> +* Also, do not set to true alert_userspace, because there is
> no
> +* need to notify userspace when CHRVPI interrupt has
> occurred.
> +* Userspace will be notified after PWR_RDY bit is read.
> */
> queue_delayed_work(system_power_efficient_wq,
>>pwr_rdy_work,
> @@ -1178,7 +1180,7 @@ static irqreturn_t rt9455_irq_handler_thread(int irq,
> void *data)
> /*
> * Sometimes, an interrupt occurs while rt9455_probe()
> function
> * is executing and power_supply_register() is not yet called.
> -* Do not call power_supply_charged() in this case.
> +* Do not call power_supply_changed() in this case.
> */
> if (info->charger)
> power_supply_changed(info->charger);
> @@ -1478,6 +1480,11 @@ static void rt9455_pwr_rdy_work_callback(struct
> work_struct *work)
>RT9455_MAX_CHARGING_TIME * HZ);
> break;
> }
> + /*
> +* Notify userspace that the charger has been either connected to or
> +* disconnected from the power source.
> +*/
> + power_supply_changed(info->charger);
> }
>
> static void rt9455_max_charging_time_work_callback(struct work_struct *work)
> @@ -1533,6 +1540,11 @@ static void rt9455_batt_presence_work_callback(struct
> work_struct *work)
> if (ret)
> dev_err(dev, "Failed to unmask BATAB
> interrupt\n");
> }
> + /*
> +* Notify userspace that the battery is now connected to the
> +* charger.
> +*/
> + power_supply_changed(info->charger);
> }
> }
>
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dell-laptop: Clear buffer before each SMBIOS call
On Wed, Jul 01, 2015 at 08:08:19PM +0200, Pali Rohár wrote:
> Make sure that before initializing SMBIOS call input buffer does not contain
> any garbage (e.g values from previous SMBIOS call). This fix problem with
> passing undefined/random parameters to SMBIOS functions.
>
> Signed-off-by: Pali Rohár
> ---
> drivers/platform/x86/dell-laptop.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/dell-laptop.c
> b/drivers/platform/x86/dell-laptop.c
> index 35758cb..6728487 100644
> --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -310,10 +310,15 @@ static DEFINE_MUTEX(buffer_mutex);
>
> static int hwswitch_state;
>
> +static void clear_buffer(void)
> +{
> + memset(buffer, 0, sizeof(struct calling_interface_buffer));
> +}
> +
> static void get_buffer(void)
> {
> mutex_lock(_mutex);
> - memset(buffer, 0, sizeof(struct calling_interface_buffer));
> + clear_buffer();
> }
>
> static void release_buffer(void)
> @@ -557,6 +562,8 @@ static int dell_rfkill_set(void *data, bool blocked)
> !(buffer->output[1] & BIT(16)))
> disable = 1;
>
> + clear_buffer();
> +
> buffer->input[0] = (1 | (radio<<8) | (disable << 16));
> dell_send_request(buffer, 17, 11);
>
> @@ -571,6 +578,7 @@ static void dell_rfkill_update_sw_state(struct rfkill
> *rfkill, int radio,
> if (status & BIT(0)) {
> /* Has hw-switch, sync sw_state to BIOS */
> int block = rfkill_blocked(rfkill);
> + clear_buffer();
> buffer->input[0] = (1 | (radio << 8) | (block << 16));
> dell_send_request(buffer, 17, 11);
> } else {
> @@ -774,6 +782,7 @@ static int __init dell_setup_rfkill(void)
> dell_send_request(buffer, 17, 11);
> status = buffer->output[1];
> buffer->input[0] = 0x2;
> + clear_buffer();
> dell_send_request(buffer, 17, 11);
This clears the buffer after modifying input[0] and right before
dell_send_request... so you're sending a completely empty buffer? Is that
intentional here? I guess I would have expected the clear_buffer to be one line
earlier.
> hwswitch_state = buffer->output[1];
> release_buffer();
> --
> 1.7.9.5
>
>
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 2/3] ARM: dts: Add CPU OPP and regulator supply property for Exynos3250
This patch add CPU operating points which include CPU frequency and regulator
voltage to use generic cpufreq drivers.
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos3250-monk.dts | 4
arch/arm/boot/dts/exynos3250-rinato.dts | 4
arch/arm/boot/dts/exynos3250.dtsi | 15 +++
3 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index a5863acc5fff..7863265d4868 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -141,6 +141,10 @@
};
};
+ {
+ cpu0-supply = <_reg>;
+};
+
_usbphy {
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 031853b75528..ddd7ac283045 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -132,6 +132,10 @@
};
};
+ {
+ cpu0-supply = <_reg>;
+};
+
_usbphy {
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index d7201333e3bc..e0f3b2ed41a3 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -53,6 +53,21 @@
compatible = "arm,cortex-a7";
reg = <0>;
clock-frequency = <10>;
+ clocks = < CLK_ARM_CLK>;
+ clock-names = "cpu";
+
+ operating-points = <
+ 100 115
+ 90 1112500
+ 80 1075000
+ 70 1037500
+ 60 100
+ 50 962500
+ 40 925000
+ 30 887500
+ 20 85
+ 10 85
+ >;
};
cpu1: cpu@1 {
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 1/3] clk: samsung: exynos3250: Add cpu clock configuration data and instaniate cpu clock
This patch add CPU clock configuration data and instantiate the CPU clock type
for Exynos3250 to support Samsung specific cpu-clock type.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Reviewed-by: Krzysztof Kozlowski
---
drivers/clk/samsung/clk-exynos3250.c | 32 ++--
include/dt-bindings/clock/exynos3250.h | 1 +
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos3250.c
b/drivers/clk/samsung/clk-exynos3250.c
index 538de66a759e..378ad5ad3492 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -19,6 +19,7 @@
#include
#include "clk.h"
+#include "clk-cpu.h"
#include "clk-pll.h"
#define SRC_LEFTBUS0x4200
@@ -319,8 +320,10 @@ static struct samsung_mux_clock mux_clks[] __initdata = {
MUX(CLK_MOUT_MPLL_USER_C, "mout_mpll_user_c", mout_mpll_user_p,
SRC_CPU, 24, 1),
MUX(CLK_MOUT_HPM, "mout_hpm", mout_hpm_p, SRC_CPU, 20, 1),
- MUX(CLK_MOUT_CORE, "mout_core", mout_core_p, SRC_CPU, 16, 1),
- MUX(CLK_MOUT_APLL, "mout_apll", mout_apll_p, SRC_CPU, 0, 1),
+ MUX_F(CLK_MOUT_CORE, "mout_core", mout_core_p, SRC_CPU, 16, 1,
+ CLK_SET_RATE_PARENT, 0),
+ MUX_F(CLK_MOUT_APLL, "mout_apll", mout_apll_p, SRC_CPU, 0, 1,
+ CLK_SET_RATE_PARENT, 0),
};
static struct samsung_div_clock div_clks[] __initdata = {
@@ -772,6 +775,26 @@ static struct samsung_cmu_info cmu_info __initdata = {
.nr_clk_regs= ARRAY_SIZE(exynos3250_cmu_clk_regs),
};
+#define E3250_CPU_DIV0(apll, pclk_dbg, atb, corem) \
+ (((apll) << 24) | ((pclk_dbg) << 20) | ((atb) << 16) | \
+ ((corem) << 4))
+#define E3250_CPU_DIV1(hpm, copy) \
+ (((hpm) << 4) | ((copy) << 0))
+
+static const struct exynos_cpuclk_cfg_data e3250_armclk_d[] __initconst = {
+ { 100, E3250_CPU_DIV0(1, 7, 4, 1), E3250_CPU_DIV1(7, 7), },
+ { 90, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },
+ { 80, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },
+ { 70, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },
+ { 60, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },
+ { 50, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },
+ { 40, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },
+ { 30, E3250_CPU_DIV0(1, 5, 3, 1), E3250_CPU_DIV1(7, 7), },
+ { 20, E3250_CPU_DIV0(1, 3, 3, 1), E3250_CPU_DIV1(7, 7), },
+ { 10, E3250_CPU_DIV0(1, 1, 1, 1), E3250_CPU_DIV1(7, 7), },
+ { 0 },
+};
+
static void __init exynos3250_cmu_init(struct device_node *np)
{
struct samsung_clk_provider *ctx;
@@ -780,6 +803,11 @@ static void __init exynos3250_cmu_init(struct device_node
*np)
if (!ctx)
return;
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
+ mout_core_p[0], mout_core_p[1], 0x14200,
+ e3250_armclk_d, ARRAY_SIZE(e3250_armclk_d),
+ CLK_CPU_HAS_DIV1);
+
exynos3_core_down_clock(ctx->reg_base);
}
CLK_OF_DECLARE(exynos3250_cmu, "samsung,exynos3250-cmu", exynos3250_cmu_init);
diff --git a/include/dt-bindings/clock/exynos3250.h
b/include/dt-bindings/clock/exynos3250.h
index aab088d30199..63d01c15d2b3 100644
--- a/include/dt-bindings/clock/exynos3250.h
+++ b/include/dt-bindings/clock/exynos3250.h
@@ -31,6 +31,7 @@
#define CLK_FOUT_VPLL 4
#define CLK_FOUT_UPLL 5
#define CLK_FOUT_MPLL 6
+#define CLK_ARM_CLK7
/* Muxes */
#define CLK_MOUT_MPLL_USER_L 16
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250
This patchset use cpufreq-dt driver to support Exynos3250 cpufreq and tested it on Exynos3250-based Rinato board. Depends on: - next-20150701 tag (master branch) of linux-next kernel tree - This patch-set is based on Exynos5250 patch-set[1] because two patch-set modify the 'arch/arm/mach-exynos/exynos.c' to add the compatible string. [1] https://lkml.org/lkml/2015/6/29/361 : [PATCH v2 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform Changes from v5: (https://lkml.org/lkml/2015/7/1/324) - Reorder the cpu dt node in exynos3250-rinato/monk.dts alpabetically. - Add reviewed-by tag of Krzysztof Kozlowski Changes from v4: (https://lkml.org/lkml/2014/10/20/215) - Rebased on latest linux-next git repository. - Remove unnecessary divider clock flag from divider of DIV_CPU0/DIV_CPU1 register Changes from v3: - This patchset is based on 3.18-rc1 with new patchset[3] of Thomas Abraham [3] [PATCH v11 0/6] cpufreq: use generic cpufreq drivers for exynos platforms - http://www.spinics.net/lists/arm-kernel/msg370412.html Changes from v2: - Rebased on new patchset of Thomas Abraham and for-next branch of samsunc-clk.git of Tomasz Figa Changes from v1: - Rebased on new patchset[1] by Thomas Abraham [1] [PATCH v10 0/6] cpufreq: use generic cpufreq drivers for exynos platforms - http://www.spinics.net/lists/arm-kernel/msg364790.html - Modify clk-cpu.c to support Exynos3250 - Drop documentation patch on previous patchset[2] [2] http://www.spinics.net/lists/cpufreq/msg10265.html - Add only operating-points for Exynos3250 without armclk-divider-table Chanwoo Choi (3): clk: samsung: exynos3250: Add cpu clock configuration data and instaniate cpu clock ARM: dts: Add CPU OPP and regulator supply property for Exynos3250 ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver arch/arm/boot/dts/exynos3250-monk.dts | 4 arch/arm/boot/dts/exynos3250-rinato.dts | 4 arch/arm/boot/dts/exynos3250.dtsi | 15 +++ arch/arm/mach-exynos/exynos.c | 1 + drivers/clk/samsung/clk-exynos3250.c| 32 ++-- include/dt-bindings/clock/exynos3250.h | 1 + 6 files changed, 55 insertions(+), 2 deletions(-) -- 1.8.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 3/3] ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver
This patch add exynos3250 compatible string to exynos_cpufreq_matches
for supporting generic cpufreq driver on Exynos3250.
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/mach-exynos/exynos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 4015ec369ae5..77ac0216ddc4 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -225,6 +225,7 @@ static void __init exynos_init_irq(void)
}
static const struct of_device_id exynos_cpufreq_matches[] = {
+ { .compatible = "samsung,exynos3250", .data = "cpufreq-dt" },
{ .compatible = "samsung,exynos4210", .data = "cpufreq-dt" },
{ .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
{ /* sentinel */ }
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
