Re: [PATCH] sched: smart wake-affine
On Mon, 2013-07-15 at 13:13 +0800, Michael Wang wrote: > Hi, Davidlohr > > On 07/09/2013 10:52 AM, Michael Wang wrote: > > On 07/09/2013 10:36 AM, Davidlohr Bueso wrote: > > [snip] > >>> 2. is the 3.10-rc5 in image also disabled the hyperthreading? > >> > >> Yes, I happened to have data already collected for 3.10-rc5. While the > >> runs with this patch was with -rc7, unless there was some performance > >> related commit I missed, I don't think the performance difference was > >> because of that. > >> > >>> 3. is the v3 patch set show the same issue? > >> > >> Uhmmm shoot, I didn't realize there was a v3, sorry about that. > >> > >> /me takes another look at the thread. > > > > V3 will reduce the overhead, should make things better, especially when > > workload is high and platform is big (your box is really what I desired > > ;-), honestly). > > > > And if it is possible, comparison based on the same basement will be > > better :) > > I have done some tests with reaim high_systime workfile, and I could not > find regression on my box (the tool itself has some issue, but I got the > results), v3 works well. Sorry for the delay. I'm glad you reminded me since I already had the data. > > I suppose the issue have been addressed, but please let us know if v3 > also show regression on your box, we could try to solve the problem ;-) It has, high_systime no longer shows a hit and all workloads remain basically the same. Tested-by: Davidlohr Bueso Thanks. > > Regards, > Michael Wang > > > > > Regards, > > Michael Wang > > > >> > >> Thanks, > >> Davidlohr > >> > > > > -- > > 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/ > > > -- 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 4/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
On 07/10/2013 05:23 PM, Roger Quadros wrote:
> In order to support wake up from suspend use the pinctrl
> framework to put the USB host pins in IDLE state during suspend.
>
> CC: Samuel Ortiz
> Signed-off-by: Roger Quadros
[...]
> @@ -608,6 +618,14 @@ static int usbhs_omap_probe(struct platform_device *pdev)
> return -ENOMEM;
> }
>
> + if (!dev->pins || !dev->pins->idle_state) {
> + /* If IDLE pins are not available, we can't remote wakeup,
> + * so prevent idling in that case.
> + */
nit: multi-line comment style
Also, if there are no pins, aren't the pinctrl ops nops anyways? IOW,
not sure the need
for this is clear, and it's not mentioned in the changelog.
Kevin
--
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 V10 12/18] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks
On 07/14/2013 07:18 PM, Gleb Natapov wrote:
On Mon, Jun 24, 2013 at 06:13:04PM +0530, Raghavendra K T wrote:
kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks
From: Srivatsa Vaddagiri
kvm_hc_kick_cpu allows the calling vcpu to kick another vcpu out of halt state.
the presence of these hypercalls is indicated to guest via
kvm_feature_pv_unhalt.
Signed-off-by: Srivatsa Vaddagiri
Signed-off-by: Suzuki Poulose
[Raghu: Apic related changes, folding pvunhalted into vcpu_runnable]
Signed-off-by: Raghavendra K T
---
arch/x86/include/asm/kvm_host.h |5 +
arch/x86/include/uapi/asm/kvm_para.h |1 +
arch/x86/kvm/cpuid.c |3 ++-
arch/x86/kvm/x86.c | 37 ++
include/uapi/linux/kvm_para.h|1 +
5 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3741c65..95702de 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -503,6 +503,11 @@ struct kvm_vcpu_arch {
* instruction.
*/
bool write_fault_to_shadow_pgtable;
+
+ /* pv related host specific info */
+ struct {
+ bool pv_unhalted;
+ } pv;
};
struct kvm_lpage_info {
diff --git a/arch/x86/include/uapi/asm/kvm_para.h
b/arch/x86/include/uapi/asm/kvm_para.h
index 06fdbd9..94dc8ca 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -23,6 +23,7 @@
#define KVM_FEATURE_ASYNC_PF 4
#define KVM_FEATURE_STEAL_TIME5
#define KVM_FEATURE_PV_EOI6
+#define KVM_FEATURE_PV_UNHALT 7
/* The last 8 bits are used to indicate how to interpret the flags field
* in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index a20ecb5..b110fe6 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -413,7 +413,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32
function,
(1 << KVM_FEATURE_CLOCKSOURCE2) |
(1 << KVM_FEATURE_ASYNC_PF) |
(1 << KVM_FEATURE_PV_EOI) |
-(1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
+(1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
+(1 << KVM_FEATURE_PV_UNHALT);
if (sched_info_on())
entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 094b5d9..f8bea30 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5449,6 +5449,36 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
return 1;
}
+/*
+ * kvm_pv_kick_cpu_op: Kick a vcpu.
+ *
+ * @apicid - apicid of vcpu to be kicked.
+ */
+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
+{
+ struct kvm_vcpu *vcpu = NULL;
+ int i;
+
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ if (!kvm_apic_present(vcpu))
+ continue;
+
+ if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
+ break;
+ }
+ if (vcpu) {
+ /*
+* Setting unhalt flag here can result in spurious runnable
+* state when unhalt reset does not happen in vcpu_block.
+* But that is harmless since that should soon result in halt.
+*/
+ vcpu->arch.pv.pv_unhalted = true;
+ /* We need everybody see unhalt before vcpu unblocks */
+ smp_wmb();
+ kvm_vcpu_kick(vcpu);
+ }
+}
+
int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
{
unsigned long nr, a0, a1, a2, a3, ret;
@@ -5482,6 +5512,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
case KVM_HC_VAPIC_POLL_IRQ:
ret = 0;
break;
+ case KVM_HC_KICK_CPU:
+ kvm_pv_kick_cpu_op(vcpu->kvm, a0);
Lets make it hypercall with two parameters:
a0 - flags
a1 - apic id of a cpu to kick
A0 have to be zero. This will make it more extensible.
Good point. 'll incorporate that.
--
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] module: ppc64 module CRC relocation fix causes perf issues
Anton Blanchard writes: > Module CRCs are implemented as absolute symbols that get resolved by > a linker script. We build an intermediate .o that contains an > unresolved symbol for each CRC. genksysms parses this .o, calculates > the CRCs and writes a linker script that "resolves" the symbols to > the calculated CRC. > > Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols > that need relocating and relocates them at boot. Commit d4703aef > (module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y) > added a hook to reverse the bogus relocations. Part of this patch > created a symbol at 0x0: > > # head -2 /proc/kallsyms > T reloc_start > c000 T .__start > > This reloc_start symbol is causing lots of confusion to perf. It > thinks reloc_start is a massive function that stretches from 0x0 to > 0xc000 and we get various cryptic errors out of perf, > including: > > problem incrementing symbol count, skipping event > > This patch removes the reloc_start linker script label and instead > defines it as PHYSICAL_START. We also need to wrap it with > CONFIG_PPC64 because the ppc32 kernel can set a non zero > PHYSICAL_START at compile time and we wouldn't want to subtract > it from the CRCs in that case. > > Signed-off-by: Anton Blanchard > Cc: Acked-by: Rusty Russell Ben? Cheers, Rusty. -- 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] lib: One less subtraction in binary search iterations.
Wedson Almeida Filho writes: > The subtraction is removed at the expense of generality: when the element size > is 1, the array length cannot exceed half the architecture's addressable > memory. People do copy code, so I prefer to set the best example possible. Unless it's a useful optimization, I think it should stay the way it is. Cheers, Rusty. -- 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/
Please add PTR_RET tree.
Temporary branch for PTR_RET -> PTR_ERR_OR_ZERO and associated cleanups. git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git PTR_RET Log appended. Contributors and people who didn't already ack CC'd. Cheers, Rusty. commit 6e8b8726ad503214ba66e34aed69aff41de33489 Author: Rusty Russell Date: Mon Jul 15 11:19:32 2013 +0930 PTR_RET is now PTR_ERR_OR_ZERO True, it's often used in return statements, but after much bikeshedding it's probably better to have an explicit name. (I tried just putting the IS_ERR check inside PTR_ERR itself and gcc usually generated no more code. But that clashes current expectations of how PTR_ERR behaves, so having a separate function is better). Suggested-by: Julia Lawall Suggested-by: "Michael S. Tsirkin" Cc: Julia Lawall Cc: "Michael S. Tsirkin" Signed-off-by: Rusty Russell commit 8c6ffba0eddc8c110dbf444f51354ce42069abfc Author: Rusty Russell Date: Mon Jul 15 11:20:32 2013 +0930 PTR_RET is now PTR_ERR_OR_ZERO(): Replace most. Sweep of the simple cases. Cc: net...@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: Julia Lawall Signed-off-by: Rusty Russell Acked-by: David S. Miller Acked-by: Benjamin Herrenschmidt commit 228b82211b47b597fa75dff2ac146b40eaaddf18 Author: Rusty Russell Date: Mon Jul 15 11:21:32 2013 +0930 s390: Replace weird use of PTR_RET. Saves repeating "(void __force *)__uptr" but it's less clear. Using the output of PTR_RET() to determine the error rather than just testing IS_ERR() is odd. For example, I *assume* __gptr_to_uptr() never returns NULL? Because the __ret would be 0 for the old code. The new version is clearer, IMHO: it would try to get_user() on that address. If you hate this variant, I can just s/PTR_RET/PTR_ERR_OR_ZERO/ instead. Cc: Christian Borntraeger Cc: Martin Schwidefsky Signed-off-by: Rusty Russell Acked-by: Heiko Carstens commit 5d7e438629413586ab78779751caa6e713c2234c Author: Rusty Russell Date: Mon Jul 15 11:22:32 2013 +0930 acpi: Replace weird use of PTR_RET. This functions is really weird. It sets rc to -ENOMEM, then overrides it. It was converted to PTR_RET in a1458187 when it should have simply been rewritten. This version makes it more explicit, with a single IS_ERR() test. Cc: Alexandru Gheorghiu Signed-off-by: Rusty Russell Acked-by: Rafael J. Wysocki commit 5795c6ac7c77dc2363c41948cf828916c17cf78f Author: Rusty Russell Date: Mon Jul 15 11:23:32 2013 +0930 pinctrl: don't use PTR_RET(). We've already tested that it's an error. Cc: Sebastian Hesselbarth Signed-off-by: Rusty Russell commit 60d676c007964576e83d791fc0908af8d133519f Author: Rusty Russell Date: Mon Jul 15 11:24:08 2013 +0930 remoteproc: don't use PTR_RET(). We've already tested that it's an error. Cc: Robert Tivy Signed-off-by: Rusty Russell Acked-by: Ohad Ben-Cohen commit 8a1d41cfeaf59a07acc7b1b3620ad6aa5cf47dc2 Author: Rusty Russell Date: Mon Jul 15 11:24:08 2013 +0930 staging/zcache: don't use PTR_RET(). We've already tested that it's an error. Cc: Dan Magenheimer Signed-off-by: Rusty Russell commit 6b4f2b56a48c8ea9775bd2b29681725d4474367a Author: Rusty Russell Date: Mon Jul 15 11:24:08 2013 +0930 mm/oom_kill: remove weird use of ERR_PTR()/PTR_ERR(). The normal expectation for ERR_PTR() is to put a negative errno into a pointer. oom_kill puts the magic -1 in the result (and has since pre-git), which is probably clearer with an explicit cast. Cc: Andrew Morton Signed-off-by: Rusty Russell -- 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] sched: smart wake-affine
Hi, Davidlohr On 07/09/2013 10:52 AM, Michael Wang wrote: > On 07/09/2013 10:36 AM, Davidlohr Bueso wrote: > [snip] >>> 2. is the 3.10-rc5 in image also disabled the hyperthreading? >> >> Yes, I happened to have data already collected for 3.10-rc5. While the >> runs with this patch was with -rc7, unless there was some performance >> related commit I missed, I don't think the performance difference was >> because of that. >> >>> 3. is the v3 patch set show the same issue? >> >> Uhmmm shoot, I didn't realize there was a v3, sorry about that. >> >> /me takes another look at the thread. > > V3 will reduce the overhead, should make things better, especially when > workload is high and platform is big (your box is really what I desired > ;-), honestly). > > And if it is possible, comparison based on the same basement will be > better :) I have done some tests with reaim high_systime workfile, and I could not find regression on my box (the tool itself has some issue, but I got the results), v3 works well. I suppose the issue have been addressed, but please let us know if v3 also show regression on your box, we could try to solve the problem ;-) Regards, Michael Wang > > Regards, > Michael Wang > >> >> Thanks, >> Davidlohr >> > > -- > 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/ > -- 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/2] Drivers: hv: balloon: Fix a bug in the hot-add code
On 07/15/2013 01:38 PM, K. Y. Srinivasan wrote:
> As we hot-add 128 MB chunks of memory, we wait to ensure that the memory
> is onlined before attempting to hot-add the next chunk. If the udev rule for
> memory hot-add is not executed within the allowed time, we would rollback the
> state and abort further hot-add. Since the hot-add has succeeded and the only
> failure is that the memory is not onlined within the allowed time, we should
> not
> be rolling back the state. Fix this bug.
>
> Signed-off-by: K. Y. Srinivasan
> Cc: Stable
> ---
> drivers/hv/hv_balloon.c | 13 +
> 1 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index 4c605c7..61b7351 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -562,7 +562,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned
> long size,
> struct hv_hotadd_state *has)
> {
> int ret = 0;
> - int i, nid, t;
> + int i, nid;
> unsigned long start_pfn;
> unsigned long processed_pfn;
> unsigned long total_pfn = pfn_count;
> @@ -607,14 +607,11 @@ static void hv_mem_hot_add(unsigned long start,
> unsigned long size,
>
> /*
>* Wait for the memory block to be onlined.
> + * Since the hot add has succeeded, it is ok to
> + * proceed even if the pages in the hot added region
> + * have not been "onlined" within the allowed time.
>*/
> - t = wait_for_completion_timeout(_device.ol_waitevent, 5*HZ);
> - if (t == 0) {
> - pr_info("hot_add memory timedout\n");
> - has->ha_end_pfn -= HA_CHUNK;
> - has->covered_end_pfn -= processed_pfn;
> - break;
> - }
> + wait_for_completion_timeout(_device.ol_waitevent, 5*HZ);
>
> }
>
Acked-by: Jason Wang
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/
[PATCH 1/3] powerpc: Add iommu domain pointer to device archdata
Add an iommu domain pointer to device (powerpc) archdata. Devices
are attached to iommu domains and this pointer provides a mechanism
to correlate between a device and the associated iommu domain. This
field is set when a device is attached to a domain.
Signed-off-by: Varun Sethi
Acked-by: Kumar Gala
---
- rebased patch to 3.11-rc1
arch/powerpc/include/asm/device.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 77e97dd..38faede 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -28,6 +28,9 @@ struct dev_archdata {
void*iommu_table_base;
} dma_data;
+#ifdef CONFIG_IOMMU_API
+ void*iommu_domain;
+#endif
#ifdef CONFIG_SWIOTLB
dma_addr_t max_direct_dma_addr;
#endif
--
1.7.4.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/
[PATCH 2/3 v19] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
Added the following domain attributes for the FSL PAMU driver:
1. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
2. Added an attribute for enabling/disabling DMA to a particular
memory window.
3. Added domain attribute to check for PAMUV1 specific constraints.
Signed-off-by: Varun Sethi
---
v19:
- rebased to 3.11-rc1
- no changes since v16
v16 changes:
- rebased to 3.10-rc6
v15 changes:
- Moved fsl_pamu_stash.h under arch/powerpc/include/asm.
v14 changes:
- Add FSL prefix to PAMU attributes.
v13 changes:
- created a new file include/linux/fsl_pamu_stash.h for stash
attributes.
v12 changes:
- Moved PAMU specifc stash ids and structures to PAMU header file.
- no change in v11.
- no change in v10.
arch/powerpc/include/asm/fsl_pamu_stash.h | 39 +
include/linux/iommu.h | 16
2 files changed, 55 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsl_pamu_stash.h
diff --git a/arch/powerpc/include/asm/fsl_pamu_stash.h
b/arch/powerpc/include/asm/fsl_pamu_stash.h
new file mode 100644
index 000..caa1b21
--- /dev/null
+++ b/arch/powerpc/include/asm/fsl_pamu_stash.h
@@ -0,0 +1,39 @@
+/*
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ */
+
+#ifndef __FSL_PAMU_STASH_H
+#define __FSL_PAMU_STASH_H
+
+/* cache stash targets */
+enum pamu_stash_target {
+ PAMU_ATTR_CACHE_L1 = 1,
+ PAMU_ATTR_CACHE_L2,
+ PAMU_ATTR_CACHE_L3,
+};
+
+/*
+ * This attribute allows configuring stashig specific parameters
+ * in the PAMU hardware.
+ */
+
+struct pamu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
+};
+
+#endif /* __FSL_PAMU_STASH_H */
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 3aeb730..7ea319e 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -58,10 +58,26 @@ struct iommu_domain {
#define IOMMU_CAP_CACHE_COHERENCY 0x1
#define IOMMU_CAP_INTR_REMAP 0x2 /* isolates device intrs */
+/*
+ * Following constraints are specifc to FSL_PAMUV1:
+ * -aperture must be power of 2, and naturally aligned
+ * -number of windows must be power of 2, and address space size
+ * of each window is determined by aperture size / # of windows
+ * -the actual size of the mapped region of a window must be power
+ * of 2 starting with 4KB and physical address must be naturally
+ * aligned.
+ * DOMAIN_ATTR_FSL_PAMUV1 corresponds to the above mentioned contraints.
+ * The caller can invoke iommu_domain_get_attr to check if the underlying
+ * iommu implementation supports these constraints.
+ */
+
enum iommu_attr {
DOMAIN_ATTR_GEOMETRY,
DOMAIN_ATTR_PAGING,
DOMAIN_ATTR_WINDOWS,
+ DOMAIN_ATTR_FSL_PAMU_STASH,
+ DOMAIN_ATTR_FSL_PAMU_ENABLE,
+ DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_MAX,
};
--
1.7.4.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/
[PATCH V2 2/2] Drivers: hv: balloon: Do not post pressure status if interrupted
When we are posting pressure status, we may get interrupted and handle the un-balloon operation. In this case just don't post the status as we know the pressure status is stale. Signed-off-by: K. Y. Srinivasan Cc: Stable --- drivers/hv/hv_balloon.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c index 61b7351..deb5c25 100644 --- a/drivers/hv/hv_balloon.c +++ b/drivers/hv/hv_balloon.c @@ -975,6 +975,14 @@ static void post_status(struct hv_dynmem_device *dm) dm->num_pages_ballooned + compute_balloon_floor(); + /* +* If our transaction ID is no longer current, just don't +* send the status. This can happen if we were interrupted +* after we picked our transaction ID. +*/ + if (status.hdr.trans_id != atomic_read(_id)) + return; + vmbus_sendpacket(dm->dev->channel, , sizeof(struct dm_status), (unsigned long)NULL, -- 1.7.4.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/
[PATCH V2 1/2] Drivers: hv: balloon: Fix a bug in the hot-add code
As we hot-add 128 MB chunks of memory, we wait to ensure that the memory
is onlined before attempting to hot-add the next chunk. If the udev rule for
memory hot-add is not executed within the allowed time, we would rollback the
state and abort further hot-add. Since the hot-add has succeeded and the only
failure is that the memory is not onlined within the allowed time, we should not
be rolling back the state. Fix this bug.
Signed-off-by: K. Y. Srinivasan
Cc: Stable
---
drivers/hv/hv_balloon.c | 13 +
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 4c605c7..61b7351 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -562,7 +562,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned
long size,
struct hv_hotadd_state *has)
{
int ret = 0;
- int i, nid, t;
+ int i, nid;
unsigned long start_pfn;
unsigned long processed_pfn;
unsigned long total_pfn = pfn_count;
@@ -607,14 +607,11 @@ static void hv_mem_hot_add(unsigned long start, unsigned
long size,
/*
* Wait for the memory block to be onlined.
+* Since the hot add has succeeded, it is ok to
+* proceed even if the pages in the hot added region
+* have not been "onlined" within the allowed time.
*/
- t = wait_for_completion_timeout(_device.ol_waitevent, 5*HZ);
- if (t == 0) {
- pr_info("hot_add memory timedout\n");
- has->ha_end_pfn -= HA_CHUNK;
- has->covered_end_pfn -= processed_pfn;
- break;
- }
+ wait_for_completion_timeout(_device.ol_waitevent, 5*HZ);
}
--
1.7.4.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/
[PATCH V2 0/2] Drivers: hv: balloon: Fix some issues in the balloon driver
This patch set adresses a couple of issues discovered in the balloon driver: 1. Prevent stale pressure report being posted. 2. If memory is not brought online within the allowed time, do not roll back hot add state if hot add succeeded. In this version of the patch set, I have added additional comments to the patch: 0001-Drivers-hv-balloon-Fix-a-bug-in-the-hot-add-code.patch based on the comments from Ben Hutchings . K. Y. Srinivasan (2): Drivers: hv: balloon: Fix a bug in the hot-add code Drivers: hv: balloon: Do not post pressure status if interrupted drivers/hv/hv_balloon.c | 21 + 1 files changed, 13 insertions(+), 8 deletions(-) -- 1.7.4.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/
[PATCH] usb: udc: add gadget state kobject uevent
usb: udc: add gadget state kobject uevent
Add USB_UDC_STATE environment variable in udc uevent
callback and trigger kobject_uevent in usb_gadget_set_state
to inform the user-space the state of the gadget.
Signed-off-by: Rong Wang
diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index ffd8fa5..05715d1 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
@@ -101,11 +101,32 @@ EXPORT_SYMBOL_GPL(usb_gadget_unmap_request);
/* - */
+/**
+ * usb_gadget_set_state - set usb gadget state
+ * @gadget: gadget device
+ * @state: state defined in USB specification ch9
+ * Context: !in_interrupt()
+ */
void usb_gadget_set_state(struct usb_gadget *gadget,
enum usb_device_state state)
{
+ struct usb_udc *udc = NULL;
+
gadget->state = state;
sysfs_notify(>dev.kobj, NULL, "status");
+
+ mutex_lock(_lock);
+ list_for_each_entry(udc, _list, list)
+ if (udc->gadget == gadget)
+ goto found;
+
+ dev_err(gadget->dev.parent, "gadget not registered.\n");
+ mutex_unlock(_lock);
+ return;
+
+found:
+ mutex_unlock(_lock);
+ kobject_uevent(>dev.kobj, KOBJ_CHANGE);
}
EXPORT_SYMBOL_GPL(usb_gadget_set_state);
@@ -538,6 +559,15 @@ static int usb_udc_uevent(struct device *dev,
struct kobj_uevent_env *env)
}
}
+ if (udc->gadget) {
+ ret = add_uevent_var(env, "USB_UDC_STATE=%s",
+ usb_state_string(udc->gadget->state));
+ if (ret) {
+ dev_err(dev, "failed to add uevent USB_UDC_STATE\n");
+ return ret;
+ }
+ }
+
return 0;
}
--
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: [3.10.1 MEI_ME] strange kernel crash
> -Original Message-
> From: Konstantin Khlebnikov [mailto:koc...@gmail.com] On Behalf Of
> Konstantin Khlebnikov
> Sent: Monday, July 15, 2013 05:39
> To: linux-kernel@vger.kernel.org; Winkler, Tomas; linux-
> wirel...@vger.kernel.org
> Subject: Re: [3.10.1 MEI_ME] strange kernel crash
>
> This has happened again. This time without warnings and without suspend-
> resume.
> Seems like 'mei_me' corrupts kernel memory.
I will post the fix today I hope.
Thanks
Tomas
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [REGRESSION 3.10.1] System does not wake up from suspend
On Sun, Jul 14, 2013 at 09:36:25PM -0700, Sören Brinkmann wrote: > Hi Greg, > > since upgrading to 3.10.1 I find my system not waking up from suspend > from time to time. Unfortunately, I couldn't figure out how to reliably > reproduce the issue. Sometimes it works just fine. > > All I know so far: > On 3.10 I had my system completely freezing a few times. But that did > not seem to be related to suspend/resume. I never experienced the > behavior described below on 3.10. > > On 3.10.1 I hit this bug a few times, that my system did not wake up. > I.e. the screen stayed black and the power LED kept flashing. But > nothing brought the system back up and I had to longpress power to reset > the system. > I had none of the system freezes like the ones described above anymore. Fortunately, 3.10.1 is very small. The only patch it contains which is related to suspend is 18/19 (cpufreq ondemand governor). Maybe you're having a problem with cpufreq on this machine in fact. You may want to try to force it to performance mode or powersave mode and try for a while, it is possible that both 3.10 and 3.10.1 will work fine. Best regards, Willy -- 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: [ 00/19] 3.10.1-stable review
On Mon, Jul 15, 2013 at 12:12:04PM +0800, Li Zefan wrote: > > It is *my* conception of the stable branch, but I think that many people > > have different expectations about what should be merged or not. For example > > in old LTS branches, I used to merge what was relevant for servers only, > > We have lots of embeded systems running 2.6.32 kernel. And we encountered > a critical bug, and we had to backported some patches which are not bug fixes > to prevent the bug from happening. If these patches are not too numerous nor too big, and that what they fix is really obvious, it could be useful to discuss their merging on the stable list, especially if you believe the bug is not specific to your environment. Thanks, Willy -- 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/
[GIT PULL] ext4 bug fixes
The following changes since commit 6ae06ff51eab5dcbbf959b05ce0f11003a305ba5: ext4: optimize starting extent in ext4_ext_rm_leaf() (2013-07-01 08:12:41 -0400) are available in the git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus for you to fetch changes up to e7676a704ee0a1ef71a6b23760b5a8f6896cb1a1: ext4: don't allow ext4_free_blocks() to fail due to ENOMEM (2013-07-13 00:40:35 -0400) Various regression and bug fixes for ext4. Anatol Pomozov (1): ext4: rate limit printk in buffer_io_error() Jan Kara (2): ext4: silence warning in ext4_writepages() ext4: fix warning in ext4_evict_inode() Theodore Ts'o (4): ext4: fix ext4_get_group_number() ext4: don't show usrquota/grpquota twice in /proc/mounts ext4: fix spelling errors and a comment in extent_status tree ext4: don't allow ext4_free_blocks() to fail due to ENOMEM fs/ext4/balloc.c | 4 ++-- fs/ext4/extents_status.c | 22 ++ fs/ext4/inode.c | 12 ++-- fs/ext4/mballoc.c| 11 --- fs/ext4/page-io.c| 35 +-- fs/ext4/super.c | 14 -- 6 files changed, 51 insertions(+), 47 deletions(-) -- 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 V3 1/3] dts: change Marvell prefix to 'marvell'
On Sat, Jul 13, 2013 at 12:56:25PM -0700, Olof Johansson wrote:
> On Wed, Jul 10, 2013 at 2:50 PM, Jason Cooper wrote:
> > On Wed, Jul 10, 2013 at 10:08:50PM +0800, Haojian Zhuang wrote:
> >> On Wed, Jul 10, 2013 at 8:24 PM, Jason Cooper wrote:
> >> > On Wed, Jul 10, 2013 at 04:19:46PM +0800, Haojian Zhuang wrote:
> >> >> On Tue, Jul 9, 2013 at 8:49 PM, Jason Cooper
> >> >> wrote:
> >> >> > Neil,
> >> >> >
> >> >> > On Tue, Jul 09, 2013 at 02:42:44PM +0800, Neil Zhang wrote:
> >> >> >> The documented vendor prefix for Marvell is 'marvell', not 'mrvl', so
> >> >> >> let's change it.
> >> >> >>
> >> >> >> Signed-off-by: Neil Zhang
> >> >> >> ---
> >> >> >> .../devicetree/bindings/arm/mrvl/intc.txt | 16 +++---
> >> >> >> .../devicetree/bindings/arm/mrvl/mrvl.txt |6 +-
> >> >> >> .../devicetree/bindings/arm/mrvl/timer.txt |4 +-
> >> >> >> Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 14 +++---
> >> >> >> .../devicetree/bindings/mmc/sdhci-pxa.txt |8 ++--
> >> >> >> .../devicetree/bindings/rtc/sa1100-rtc.txt |4 +-
> >> >> >> .../devicetree/bindings/serial/mrvl-serial.txt |2 +-
> >> >> >> arch/arm/boot/dts/mmp2-brownstone.dts |2 +-
> >> >> >> arch/arm/boot/dts/mmp2.dtsi| 56
> >> >> >> ++--
> >> >> >> arch/arm/boot/dts/pxa168-aspenite.dts |2 +-
> >> >> >> arch/arm/boot/dts/pxa168.dtsi | 24
> >> >> >> arch/arm/boot/dts/pxa2xx.dtsi | 16 +++---
> >> >> >> arch/arm/boot/dts/pxa3xx.dtsi |2 +-
> >> >> >> arch/arm/boot/dts/pxa910-dkb.dts |2 +-
> >> >> >> arch/arm/boot/dts/pxa910.dtsi | 27 +-
> >> >> >> arch/arm/mach-mmp/irq.c| 16 +++---
> >> >> >> arch/arm/mach-mmp/mmp-dt.c | 28 +-
> >> >> >> arch/arm/mach-mmp/mmp2-dt.c| 16 +++---
> >> >> >> arch/arm/mach-mmp/time.c |2 +-
> >> >> >> arch/arm/mach-pxa/pxa-dt.c | 14 +++---
> >> >> >> drivers/i2c/busses/i2c-pxa.c | 10 ++--
> >> >> >> drivers/mmc/host/sdhci-pxav2.c |4 +-
> >> >> >> drivers/mmc/host/sdhci-pxav3.c |4 +-
> >> >> >> drivers/rtc/rtc-sa1100.c |4 +-
> >> >> >> drivers/tty/serial/pxa.c |4 +-
> >> >> >> 25 files changed, 144 insertions(+), 143 deletions(-)
> >> >> >
> >> >> > I agree with the need to change, however, this has been in the binding
> >> >> > documentation since v3.5. I wish we had caught this when we decided
> >> >> > against using stock ticker symbols (not all stock markets use
> >> >> > alphabetical abbreviated names, not all companies are listed on any
> >> >> > stock exchange).
> >> >> >
> >> >> > To do this properly, the drivers are going to have to be compatible
> >> >> > with
> >> >> > the old and the new names, and the binding docs updated to reflect the
> >> >> > legacy name and the preferred name.
> >> >> >
> >> >>
> >> >> It's better to only use the new names.
> >> >
> >> > In the dts{i}, yes. But we don't want to break systems in the field
> >> > with "mrvl,..." compatible strings. Therefore, at least the drivers
> >> > need an extra compatible string to support "mrvl,...".
> >> >
> >> > If it had just been since v3.9, it'd be different/simpler. However,
> >> > several vendors have opted to use kernels newer than v3.5, which makes
> >> > this scenario a real possibility.
> >> >
> >> > thx,
> >> >
> >> > Jason.
> >>
> >> Is there any vendor using DT for this Marvell chip? I think the answer is
> >> no.
> >
> > Well, Daniel Drake spoke up for OLPC. Does that count?
>
> There's stock ticker history for MRVL is available for at least as far
> back as 2001, so it's been around for a while. I would argue that the
> powerpc guys made a mistake by using the marvell prefix. Either way,
> they are not likely to add any new driver or code anytime soon for
> these platforms.
I think this boils down to which is more important, adhering to stock
tickers, or adhering to what's actually in the kernel before we (arm-soc
dt effort) got here?
I don't mind if the answer is either way, but back when we started
converting kirkwood to DT we had this discussion, and settled on
"marvell,..." because of powerpc/mv643xx_eth. Now, it appears we're
flip-flopping.
> Given that we are using mrvl extensively already,
?! Only -mmp and -pxa have used mrvl. _everything_ for -kirkwood,
-dove, -orion5x, and -mvebu has used marvell.
$ git grep 'compatible\b.*\bmrvl,' -- drivers/ | wc -l
9
$ git grep 'compatible\b.*\bmarvell,' -- drivers/ | wc -l
54
This is from mvebu/for-next, and does _not_ include Sebastian's patches
going though DaveM's tree adding proper bindings to
Re: [PATCH] driver-core: fix new kernel-doc warning in base/platform.c
On Sun, Jul 14, 2013 at 05:43:06PM -0700, Randy Dunlap wrote: > From: Randy Dunlap > > Fix new kernel-doc warning in drivers/base/platform.c: > > Warning(drivers/base/platform.c:528): No description found for parameter > 'owner' > > Signed-off-by: Randy Dunlap > --- > drivers/base/platform.c |1 + > 1 file changed, 1 insertion(+) > > --- lnx-311-rc1.orig/drivers/base/platform.c > +++ lnx-311-rc1/drivers/base/platform.c > @@ -522,6 +522,7 @@ static void platform_drv_shutdown(struct > /** > * __platform_driver_register - register a driver for platform-level devices > * @drv: platform driver structure > + * @owner: owning module/driver > */ > int __platform_driver_register(struct platform_driver *drv, > struct module *owner) Thanks, I'll queue this up with my next round of patches for Linus. 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/
[PATCH] virtio-net: put virtio net header inline with data
From: Michael S. Tsirkin
For small packets we can simplify xmit processing
by linearizing buffers with the header:
most packets seem to have enough head room
we can use for this purpose.
Since existing hypervisors require that header
is the first s/g element, we need a feature bit
for this.
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Rusty Russell
---
drivers/net/virtio_net.c| 42 +
include/uapi/linux/virtio_net.h | 4 +++-
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 3d2a90a..f216002 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -106,6 +106,9 @@ struct virtnet_info {
/* Has control virtqueue */
bool has_cvq;
+ /* Host can handle any s/g split between our header and packet data */
+ bool any_header_sg;
+
/* enable config space updates */
bool config_enable;
@@ -669,12 +672,28 @@ static void free_old_xmit_skbs(struct send_queue *sq)
static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
{
- struct skb_vnet_hdr *hdr = skb_vnet_hdr(skb);
+ struct skb_vnet_hdr *hdr;
const unsigned char *dest = ((struct ethhdr *)skb->data)->h_dest;
struct virtnet_info *vi = sq->vq->vdev->priv;
unsigned num_sg;
+ unsigned hdr_len;
+ bool can_push;
pr_debug("%s: xmit %p %pM\n", vi->dev->name, skb, dest);
+ if (vi->mergeable_rx_bufs)
+ hdr_len = sizeof hdr->mhdr;
+ else
+ hdr_len = sizeof hdr->hdr;
+
+ can_push = vi->any_header_sg &&
+ !((unsigned long)skb->data & (__alignof__(*hdr) - 1)) &&
+ !skb_header_cloned(skb) && skb_headroom(skb) >= hdr_len;
+ /* Even if we can, don't push here yet as this would skew
+* csum_start offset below. */
+ if (can_push)
+ hdr = (struct skb_vnet_hdr *)(skb->data - hdr_len);
+ else
+ hdr = skb_vnet_hdr(skb);
if (skb->ip_summed == CHECKSUM_PARTIAL) {
hdr->hdr.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
@@ -703,15 +722,18 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff
*skb)
hdr->hdr.gso_size = hdr->hdr.hdr_len = 0;
}
- hdr->mhdr.num_buffers = 0;
-
- /* Encode metadata header at front. */
if (vi->mergeable_rx_bufs)
- sg_set_buf(sq->sg, >mhdr, sizeof hdr->mhdr);
- else
- sg_set_buf(sq->sg, >hdr, sizeof hdr->hdr);
+ hdr->mhdr.num_buffers = 0;
- num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
+ if (can_push) {
+ __skb_push(skb, hdr_len);
+ num_sg = skb_to_sgvec(skb, sq->sg, 0, skb->len);
+ /* Pull header back to avoid skew in tx bytes calculations. */
+ __skb_pull(skb, hdr_len);
+ } else {
+ sg_set_buf(sq->sg, hdr, hdr_len);
+ num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
+ }
return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb, GFP_ATOMIC);
}
@@ -1552,6 +1574,9 @@ static int virtnet_probe(struct virtio_device *vdev)
if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF))
vi->mergeable_rx_bufs = true;
+ if (virtio_has_feature(vdev, VIRTIO_F_ANY_LAYOUT))
+ vi->any_header_sg = true;
+
if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
vi->has_cvq = true;
@@ -1727,6 +1752,7 @@ static unsigned int features[] = {
VIRTIO_NET_F_CTRL_RX, VIRTIO_NET_F_CTRL_VLAN,
VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
VIRTIO_NET_F_CTRL_MAC_ADDR,
+ VIRTIO_F_ANY_LAYOUT,
};
static struct virtio_driver virtio_net_driver = {
diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
index c520203..227d4ce 100644
--- a/include/uapi/linux/virtio_net.h
+++ b/include/uapi/linux/virtio_net.h
@@ -70,7 +70,9 @@ struct virtio_net_config {
__u16 max_virtqueue_pairs;
} __attribute__((packed));
-/* This is the first element of the scatter-gather list. If you don't
+/* This header comes first in the scatter-gather list.
+ * If VIRTIO_F_ANY_LAYOUT is not negotiated, it must
+ * be the first element of the scatter-gather list. If you don't
* specify GSO or CSUM features, you can simply ignore the header. */
struct virtio_net_hdr {
#define VIRTIO_NET_HDR_F_NEEDS_CSUM1 // Use csum_start, csum_offset
--
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] virtio-net: put virtio net header inline with data
"Michael S. Tsirkin" writes: > On Tue, Jul 09, 2013 at 05:38:51PM +0930, Rusty Russell wrote: >> "Michael S. Tsirkin" writes: >> > On Tue, Jul 09, 2013 at 11:46:23AM +0930, Rusty Russell wrote: >> >> "Michael S. Tsirkin" writes: >> >> > For small packets we can simplify xmit processing >> >> > by linearizing buffers with the header: >> >> > most packets seem to have enough head room >> >> > we can use for this purpose. >> >> > Since existing hypervisors require that header >> >> > is the first s/g element, we need a feature bit >> >> > for this. >> >> > >> >> > Signed-off-by: Michael S. Tsirkin >> >> > --- >> >> > >> >> > Note: this needs to be applied on top of patch >> >> > defining VIRTIO_F_ANY_LAYOUT - bit to be >> >> > selected by Rusty. >> >> > >> >> > The following patch should work for any definition of >> >> > VIRTIO_F_ANY_LAYOUT - I used bit 31 for testing. >> >> > Rusty, could you please pick a valid bit for VIRTIO_F_ANY_LAYOUT >> >> > and squeeze this patch into 3.11? >> >> >> >> Sorry, it's too late. >> >> >> >> First, I've been a bit lax in sending patches via DaveM, and this is >> >> definitely his territory (ie. more net than virtio). >> > >> > Let's do this: I'll send a patch series, you ack and we see >> > what happens? >> >> If you convince DaveM, I won't object :) >> >> >> Secondly, it needs baking and testing time. >> >> >> >> Cheers, >> >> Rusty. >> > >> > I did some testing on this. But proper testing just isn't happening out >> > of tree. >> >> But it will get into linux-next for the *next* merge window. >> >> Cheers, >> Rusty. > > Okay. Can you put it on virtio-next then? > I don't see it there ... Here's the general order: - 1 week before Linus merge window: I stop putting new stuff into xxx-next. - Linus merge window open: I push stuff to Linus, new stuff stays in -pending. - Linus merge window close: I ff my -next trees to -rc1, merge stuff from -pending. In this case, your patch will go from pending-rebases to DaveM, not virtio-next. Which I will do now... Cheers, Rusty. -- 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] mm/hugetlb: per-vma instantiation mutexes
This seems incorrect. hugetlb_instantiation_mutex protects chains of struct
file_region
in inode->i_mapping->private_list (VM_MAYSHARE) or vma_resv_map(vma)->regions
(!VM_MAYSHARE)
These chains obviously can be shared between several vmas, so per-vma lock
cannot protect them.
Davidlohr Bueso wrote:
The hugetlb_instantiation_mutex serializes hugepage allocation and instantiation
in the page directory entry. It was found that this mutex can become quite
contended
during the early phases of large databases which make use of huge pages - for
instance
startup and initial runs. One clear example is a 1.5Gb Oracle database, where
lockstat
reports that this mutex can be one of the top 5 most contended locks in the
kernel during
the first few minutes:
hugetlb_instantiation_mutex: 10678 10678
---
hugetlb_instantiation_mutex10678 []
hugetlb_fault+0x9e/0x340
---
hugetlb_instantiation_mutex10678 []
hugetlb_fault+0x9e/0x340
contentions: 10678
acquisitions: 99476
waittime-total: 76888911.01 us
Instead of serializing each hugetlb fault, we can deal with concurrent faults
for pages
in different vmas. The per-vma mutex is initialized when creating a new vma.
So, back to
the example above, we now get much less contention:
>hugetlb_instantiation_mutex: 1 1
-
>hugetlb_instantiation_mutex 1 []
hugetlb_fault+0xa6/0x350
-
>hugetlb_instantiation_mutex 1[]
hugetlb_fault+0xa6/0x350
contentions: 1
acquisitions:108092
waittime-total: 621.24 us
Signed-off-by: Davidlohr Bueso
---
include/linux/mm_types.h | 3 +++
mm/hugetlb.c | 12 +---
mm/mmap.c| 3 +++
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index fb425aa..b45fd87 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -289,6 +289,9 @@ struct vm_area_struct {
#ifdef CONFIG_NUMA
struct mempolicy *vm_policy;/* NUMA policy for the VMA */
#endif
+#ifdef CONFIG_HUGETLB_PAGE
+ struct mutex hugetlb_instantiation_mutex;
+#endif
};
struct core_thread {
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 83aff0a..12e665b 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -137,12 +137,12 @@ static inline struct hugepage_subpool *subpool_vma(struct
vm_area_struct *vma)
* The region data structures are protected by a combination of the mmap_sem
* and the hugetlb_instantion_mutex. To access or modify a region the caller
* must either hold the mmap_sem for write, or the mmap_sem for read and
- * the hugetlb_instantiation mutex:
+ * the vma's hugetlb_instantiation mutex:
*
*down_write(>mmap_sem);
* or
*down_read(>mmap_sem);
- * mutex_lock(_instantiation_mutex);
+ * mutex_lock(>hugetlb_instantiation_mutex);
*/
struct file_region {
struct list_head link;
@@ -2547,7 +2547,7 @@ static int unmap_ref_private(struct mm_struct *mm, struct
vm_area_struct *vma,
/*
* Hugetlb_cow() should be called with page lock of the original hugepage
held.
- * Called with hugetlb_instantiation_mutex held and pte_page locked so we
+ * Called with the vma's hugetlb_instantiation_mutex held and pte_page locked
so we
* cannot race with other handlers or page migration.
* Keep the pte_same checks anyway to make transition from the mutex easier.
*/
@@ -2847,7 +2847,6 @@ int hugetlb_fault(struct mm_struct *mm, struct
vm_area_struct *vma,
int ret;
struct page *page = NULL;
struct page *pagecache_page = NULL;
- static DEFINE_MUTEX(hugetlb_instantiation_mutex);
struct hstate *h = hstate_vma(vma);
address&= huge_page_mask(h);
@@ -2872,7 +2871,7 @@ int hugetlb_fault(struct mm_struct *mm, struct
vm_area_struct *vma,
* get spurious allocation failures if two CPUs race to instantiate
* the same page in the page cache.
*/
- mutex_lock(_instantiation_mutex);
+ mutex_lock(>hugetlb_instantiation_mutex);
entry = huge_ptep_get(ptep);
if (huge_pte_none(entry)) {
ret = hugetlb_no_page(mm, vma, address, ptep, flags);
@@ -2943,8 +2942,7 @@ out_page_table_lock:
put_page(page);
out_mutex:
- mutex_unlock(_instantiation_mutex);
-
+ mutex_unlock(>hugetlb_instantiation_mutex);
return ret;
}
diff --git a/mm/mmap.c b/mm/mmap.c
index fbad7b0..8f0b034 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1543,6 +1543,9 @@ munmap_back:
vma->vm_page_prot = vm_get_page_prot(vm_flags);
vma->vm_pgoff = pgoff;
INIT_LIST_HEAD(>anon_vma_chain);
+#ifdef CONFIG_HUGETLB_PAGE
+ mutex_init(>hugetlb_instantiation_mutex);
+#endif
error = -EINVAL;/* when rejecting
Re: [ 00/19] 3.10.1-stable review
> It is *my* conception of the stable branch, but I think that many people > have different expectations about what should be merged or not. For example > in old LTS branches, I used to merge what was relevant for servers only, We have lots of embeded systems running 2.6.32 kernel. And we encountered a critical bug, and we had to backported some patches which are not bug fixes to prevent the bug from happening. > because I saw no reason why an old kernel would be used on a laptop (eg: > 2.4). So I always skipped wifi, alsa, drm, etc... With 2.6.32, the Debian > kernel guys provided me with a lot of fixes in these areas, explaining > that these fixes addressed issues that their users were facing, and they > were perfectly right. It's just that I didn't expect this at all. -- 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] module: ppc64 module CRC relocation fix causes perf issues
Module CRCs are implemented as absolute symbols that get resolved by
a linker script. We build an intermediate .o that contains an
unresolved symbol for each CRC. genksysms parses this .o, calculates
the CRCs and writes a linker script that "resolves" the symbols to
the calculated CRC.
Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols
that need relocating and relocates them at boot. Commit d4703aef
(module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y)
added a hook to reverse the bogus relocations. Part of this patch
created a symbol at 0x0:
# head -2 /proc/kallsyms
T reloc_start
c000 T .__start
This reloc_start symbol is causing lots of confusion to perf. It
thinks reloc_start is a massive function that stretches from 0x0 to
0xc000 and we get various cryptic errors out of perf,
including:
problem incrementing symbol count, skipping event
This patch removes the reloc_start linker script label and instead
defines it as PHYSICAL_START. We also need to wrap it with
CONFIG_PPC64 because the ppc32 kernel can set a non zero
PHYSICAL_START at compile time and we wouldn't want to subtract
it from the CRCs in that case.
Signed-off-by: Anton Blanchard
Cc:
---
This bug was originally reported on Fedora 19 (3.9.x), so I've marked
it for stable.
Index: b/arch/powerpc/include/asm/module.h
===
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -82,10 +82,9 @@ struct exception_table_entry;
void sort_ex_table(struct exception_table_entry *start,
struct exception_table_entry *finish);
-#ifdef CONFIG_MODVERSIONS
+#if defined(CONFIG_MODVERSIONS) && defined(CONFIG_PPC64)
#define ARCH_RELOCATES_KCRCTAB
-
-extern const unsigned long reloc_start[];
+#define reloc_start PHYSICAL_START
#endif
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_MODULE_H */
Index: b/arch/powerpc/kernel/vmlinux.lds.S
===
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -38,9 +38,6 @@ jiffies = jiffies_64 + 4;
#endif
SECTIONS
{
- . = 0;
- reloc_start = .;
-
. = KERNELBASE;
/*
--
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/
Replica Soccer paidat jalkapallon ystäville
Nauti jalkapallo kausi ja näyttää rakkautta suosikki joukkue replica jalkapallo pelipaidat. Ne voivat olla apt että jalkapallofanit, jotka rakastavat kaiken peliin ja kävellä ulos oikea tapa edustaa villitys suhteen jalkapallo pelipaidat halvalla suosikki joukkue. Ostot jäljennöksiä osoittaa, että sinun ei tarvitse viettää paljon ympäri pelipaidat, jotka mahdollistavat sen silti ilmaista ex tyttöystävä että peli. Erilaisia Replica Soccer paidat ovat myynnissä ostajia, jotka löytävät ne helposti nyt. Salaisuus menestykseen on kuitenkin oltava pelipaita, että ei ole pelkästään hyvä kopio, mutta on hyödyllisin laatua samanaikaisesti. Useat valmistaa jotka tarjoavat käyttäen jäljennöksiä usein vaarantaa ympäri huippuosaamista tuotteen vähentämiseksi kirjataan ostohinnan ja ansaita enemmän voittoa. Tämäntyyppinen pelipaita voi etsiä halpoja, joka mahdollistaa sen jopa tulla epämiellyttävä. Kiva valmistajat taata, että ne käyttävät parasta laatua ainetta valmistaakseen pelipaidat. He käyttävät puuvillaa,jalkapallo pelipaidat painatus jotta ne, jotka eivät yksinkertaisesti näyttää hyvältä, mutta on varsin mukava käyttää. Tällaiset Replica jalkapallo pelipaidat ovat omiaan henkilöille, jotka ei ole varaa saada kalliita alkuperäisiin. Ne laittaa ne näyttävät muodikas myös tukea heidän paras joukkue. Nykyään jalkapallofaneja voisi myös odottaa saada Custom pelipaidat, jotka kantavat yhteistä pelaajat nimen ja numeron. On monia valmistajia, jotka pystyvät esitellä teille tämän palvelun ja voit helposti saada oikea pelipaita. Tässä tapauksessa sinun kannattaa tehdä tilauksen etukäteen ja kertoa heille, mitä nimen tai numeron mitä tarvitset Custom pelipaidat. Custom pelipaidat eivät yleensä ole helposti saatavilla kaikki nykyiset myymälät ja näin voit etsiä online-valmistaja, joka voi tarjota samaa. Tällainen valmistaja auttaa sinua saamaan Replica Soccer paitoja eri joukkueet ja voit helposti valita yksi, joka edustaa paras joukkue. Web-pohjainen myymälöissä ylläpitää kokoelma kodin jersey ja menossa pois pelipaidat, jotka ovat saatavilla eri kokoja. --- posted at http://www.serverphorums.com http://www.serverphorums.com/read.php?12,742844,742844#msg-742844 -- 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] usb: udc: add gadget state kobject uevent
usb: udc: add gadget state kobject uevent
Add USB_UDC_STATE environment variable in udc uevent
callback and trigger kobject_uevent in usb_gadget_set_state
to inform the user-space the state of the gadget.
Signed-off-by: Rong Wang
diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index ffd8fa5..05715d1 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
@@ -101,11 +101,32 @@ EXPORT_SYMBOL_GPL(usb_gadget_unmap_request);
/* - */
+/**
+ * usb_gadget_set_state - set usb gadget state
+ * @gadget: gadget device
+ * @state: state defined in USB specification ch9
+ * Context: !in_interrupt()
+ */
void usb_gadget_set_state(struct usb_gadget *gadget,
enum usb_device_state state)
{
+ struct usb_udc *udc = NULL;
+
gadget->state = state;
sysfs_notify(>dev.kobj, NULL, "status");
+
+ mutex_lock(_lock);
+ list_for_each_entry(udc, _list, list)
+ if (udc->gadget == gadget)
+ goto found;
+
+ dev_err(gadget->dev.parent, "gadget not registered.\n");
+ mutex_unlock(_lock);
+ return;
+
+found:
+ mutex_unlock(_lock);
+ kobject_uevent(>dev.kobj, KOBJ_CHANGE);
}
EXPORT_SYMBOL_GPL(usb_gadget_set_state);
@@ -538,6 +559,15 @@ static int usb_udc_uevent(struct device *dev,
struct kobj_uevent_env *env)
}
}
+ if (udc->gadget) {
+ ret = add_uevent_var(env, "USB_UDC_STATE=%s",
+ usb_state_string(udc->gadget->state));
+ if (ret) {
+ dev_err(dev, "failed to add uevent USB_UDC_STATE\n");
+ return ret;
+ }
+ }
+
return 0;
}
--
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: [LOCKDEP] cpufreq: possible circular locking dependency detected
On 07/14/2013 08:06 PM, Sergey Senozhatsky wrote:
> On (07/14/13 14:47), Sergey Senozhatsky wrote:
>>
>> Now, as I fixed radeon kms, I can see:
>>
>> [ 806.660530] [ cut here ]
>> [ 806.660539] WARNING: CPU: 0 PID: 2389 at arch/x86/kernel/smp.c:124
>> native_smp_send_reschedule+0x57/0x60()
>
> Well, this one is obviously not a lockdep error, I meant that previous
> tests with disabled lockdep were invalid. Will re-do.
>
And may be we could try below patch to get more info, I've moved the timing
of restore stop flag from 'after STOP' to 'before START', I suppose that
could create a window to prevent the work re-queue, it could at least provide
us more info...
I think I may need to setup a environment for debug now, what's the steps to
produce this WARN?
Regards,
Michael Wang
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index dc9b72e..b1446fe 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -178,13 +178,14 @@ void gov_queue_work(struct dbs_data *dbs_data, struct
cpufreq_policy *policy,
{
int i;
+ if (!dbs_data->queue_start)
+ return;
+
if (!all_cpus) {
__gov_queue_work(smp_processor_id(), dbs_data, delay);
} else {
- get_online_cpus();
for_each_cpu(i, policy->cpus)
__gov_queue_work(i, dbs_data, delay);
- put_online_cpus();
}
}
EXPORT_SYMBOL_GPL(gov_queue_work);
@@ -193,12 +194,26 @@ static inline void gov_cancel_work(struct dbs_data
*dbs_data,
struct cpufreq_policy *policy)
{
struct cpu_dbs_common_info *cdbs;
- int i;
+ int i, round = 2;
+ dbs_data->queue_start = 0;
+redo:
+ round--;
for_each_cpu(i, policy->cpus) {
cdbs = dbs_data->cdata->get_cpu_cdbs(i);
cancel_delayed_work_sync(>work);
}
+
+ /*
+* Since there is no lock to prvent re-queue the
+* cancelled work, some early cancelled work might
+* have been queued again by later cancelled work.
+*
+* Flush the work again with dbs_data->queue_stop
+* enabled, this time there will be no survivors.
+*/
+ if (round)
+ goto redo;
}
/* Will return if we need to evaluate cpu load again or not */
@@ -391,6 +406,7 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
/* Initiate timer time stamp */
cpu_cdbs->time_stamp = ktime_get();
+ dbs_data->queue_start = 1;
gov_queue_work(dbs_data, policy,
delay_for_sampling_rate(sampling_rate), true);
diff --git a/drivers/cpufreq/cpufreq_governor.h
b/drivers/cpufreq/cpufreq_governor.h
index e16a961..9116135 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -213,6 +213,7 @@ struct dbs_data {
unsigned int min_sampling_rate;
int usage_count;
void *tuners;
+ int queue_start;
/* dbs_mutex protects dbs_enable in governor start/stop */
struct mutex mutex;
> -ss
>
>>> Regards,
>>> Michael Wang
>>>
>>> diff --git a/drivers/cpufreq/cpufreq_governor.c
>>> b/drivers/cpufreq/cpufreq_governor.c
>>> index dc9b72e..a64b544 100644
>>> --- a/drivers/cpufreq/cpufreq_governor.c
>>> +++ b/drivers/cpufreq/cpufreq_governor.c
>>> @@ -178,13 +178,14 @@ void gov_queue_work(struct dbs_data *dbs_data, struct
>>> cpufreq_policy *policy,
>>> {
>>> int i;
>>>
>>> + if (dbs_data->queue_stop)
>>> + return;
>>> +
>>> if (!all_cpus) {
>>> __gov_queue_work(smp_processor_id(), dbs_data, delay);
>>> } else {
>>> - get_online_cpus();
>>> for_each_cpu(i, policy->cpus)
>>> __gov_queue_work(i, dbs_data, delay);
>>> - put_online_cpus();
>>> }
>>> }
>>> EXPORT_SYMBOL_GPL(gov_queue_work);
>>> @@ -193,12 +194,27 @@ static inline void gov_cancel_work(struct dbs_data
>>> *dbs_data,
>>> struct cpufreq_policy *policy)
>>> {
>>> struct cpu_dbs_common_info *cdbs;
>>> - int i;
>>> + int i, round = 2;
>>>
>>> + dbs_data->queue_stop = 1;
>>> +redo:
>>> + round--;
>>> for_each_cpu(i, policy->cpus) {
>>> cdbs = dbs_data->cdata->get_cpu_cdbs(i);
>>> cancel_delayed_work_sync(>work);
>>> }
>>> +
>>> + /*
>>> +* Since there is no lock to prvent re-queue the
>>> +* cancelled work, some early cancelled work might
>>> +* have been queued again by later cancelled work.
>>> +*
>>> +* Flush the work again with dbs_data->queue_stop
>>> +* enabled, this time there will be no survivors.
>>> +*/
>>> + if (round)
>>> + goto redo;
>>> + dbs_data->queue_stop = 0;
>>> }
>>>
>>> /* Will return if we need to evaluate cpu load again or not */
>>> diff --git
Re: Oops (NULL ptr deref) while loading some module
* On 15.07.2013 01:54 AM, Mihai Moldovan wrote: > This is obviously happening while booting and udev is loading *some* module, > but > I have no idea which module is affected as such. Quick correction: actually, at that time udev hasn't even started. udev is being started by my initramfs one good second later, so at the time of those Oopses, the root fs wasn't even mounted yet. Maybe the initramfs, but I'm not too sure either. [4.769188] dracut: dracut-029 [4.789227] systemd-udevd[1984]: starting version 204 What is the kernel trying to modprobe? Off what location, exactly? It can't be /, as that isn't even mounted yet. The initramfs? Maybe, but this has NO modules packed up whatsoever. I just double-checked. root@valery/tmp/foo# ls lib/modules/3.10.1-OSS4.2-dirty modules.alias modules.alias.bin modules.builtin modules.builtin.bin modules.dep modules.dep.bin modules.devname modules.order modules.softdep modules.symbols modules.symbols.bin The initramfs is solely used for assembling the RAID arrays when booting and does not include any modules. I just upgraded to 3.10.1 and am still seeing this. Interesting issue, isn't it? :) Mihai smime.p7s Description: S/MIME Cryptographic Signature
linux-next: Tree for Jul 15
Hi all, The merge window is closed. Time to clean up all those unclean trees. The good among you can just fast forward to v3.11-rc1 ;-) Changes since 20130712: The akpm tree lost some patches that turned up elsewhere. 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" as mentioned in the FAQ on the wiki (see below). 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. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 230 trees (counting Linus' and 33 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. 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. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (ad81f05 Linux 3.11-rc1) Merging fixes/master (8177a9d lseek(fd, n, SEEK_END) does *not* go to eof - n) Merging kbuild-current/rc-fixes (42a0940 Merge branch 'yem-kconfig-rc-fixes' of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes) Merging arc-current/for-curr (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging arm-current/fixes (cbbe6f8 ARM: 7778/1: smp_twd: twd_update_frequency need be run on all online CPUs) Merging m68k-current/for-linus (767bcb4 Merge branch 'exotic-arch-fixes' into for-next) Merging metag-fixes/fixes (d903bca metag: checksum.h: fix carry in csum_tcpudp_nofold) Merging powerpc-merge/merge (ea461ab powerpc/eeh: Fix fetching bus for single-dev-PE) Merging sparc/master (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging net/master (63345b4 Merge branch 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86) Merging ipsec/master (01cb71d net_sched: restore "overhead xxx" handling) Merging sound-current/for-linus (42d4ab8 ALSA: usb-audio: fix regression for fixed stream quirk) Merging pci-current/for-linus (65694c5 x86/PCI: Map PCI setup data with ioremap() so it can be in highmem) Merging wireless/master (57bf744 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth) Merging driver-core.current/driver-core-linus (ad81f05 Linux 3.11-rc1) Merging tty.current/tty-linus (ad81f05 Linux 3.11-rc1) Merging usb.current/usb-linus (ad81f05 Linux 3.11-rc1) Merging staging.current/staging-linus (ad81f05 Linux 3.11-rc1) Merging char-misc.current/char-misc-linus (ad81f05 Linux 3.11-rc1) Merging input-current/for-linus (88ce3c3 Merge branch 'next' into for-linus) Merging md-current/for-linus (1376512 md/raid10: fix bug which causes all RAID10 reshapes to move no data.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (9c23b7d crypto: caam - Fixed the memory out of bound overwrite issue) Merging ide/master (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (d94ea3f irqchip: Return -EPERM for reserved IRQs) Merging devicetree-current/devicetree/merge (706b78f dtc: ensure #line directives don't consume data from the next line) Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error) Merging gpio-current/gpio/merge (397eada gpio/omap: don't use linear domain mapping for OMAP1) Merging rr-fixes/fixes (6407d75 virtio_console: fix uapi header) Merging mfd-fixes/master (5649d8f mfd: ab8500-sysctrl: Let sysctrl driver work without
Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal
Hi Morten, On 07/12/2013 07:18 PM, Morten Rasmussen wrote: > On Thu, Jul 11, 2013 at 12:34:49PM +0100, Preeti U Murthy wrote: >> Hi Morten, >> >> I have a few quick comments. >> >> I am concerned too about scheduler making its load balancing decisions >> based on the cpu frequency for the reason that it could create an >> imbalance in the load across cpus. >> >> Scheduler could keep loading a cpu, because its cpu frequency goes on >> increasing, and it could keep un-loading a cpu because its cpu frequency >> goes on decreasing. This increase and decrease as an effect of the load >> itself. This is of course assuming that the driver would make its >> decisions proportional to the cpu load. There could be many more >> complications, if the driver makes its decisions on factors unknown to >> the scheduler. >> >> Therefore my suggestion is that we should simply have the scheduler >> asking for increase/decrease in the frequency and letting it at that. > > If I understand correctly your concern is about the effect of frequency > scaling on load-balancing when using tracked load (PJT's) for the task > loads as it is done in Alex Shi's patches. > > That problem is present even with the existing cpufreq governors and has > not been addressed yet. Tasks on cpus at low frequencies appear bigger > since they run longer, which will cause the load-balancer to think the > cpu loaded and move tasks to other cpus. That will cause cpufreq to > lower the frequency of that cpu and make any remaining tasks look even > bigger. The story repeats itself. > > One might be tempted to suggest to use arch_scale_freq_power to tell the > load-balancer about frequency scaling. But in its current form it will > actually make it worse, as cpu_power is currently used to indicate max > compute capacity and not the current one. > > I don't understand how a simple up/down request from the scheduler would > solve that problem. It would just make frequency scaling slower if you > only go up or down one step at the time. Much like the existing > conservative cpufreq governor that nobody uses. Maybe I am missing > something? > > I think we should look into scaling the tracked load by some metric that > represents the current performance of the cpu whenever the tracked load > is updated as it was suggested by Arjan in our previous discussion. I > included it in my power scheduler design proposal, but I haven't done > anything about it yet. > > In short, I agree that there is a problem around load-balancing and > frequency scaling that needs to be fixed. Without Alex's patches the > problem is not present as task load doesn't depend on the cpu load of the > task. My concern is something like this: Scheduler sees a cpu loaded, asks the driver for an increase in its frequency. Let us assume now that the driver agrees to increase the frequency. Next time the scheduler checks this cpu, it has higher capacity due to the increase in the frequency. It loads it more. Now the load is high again, an increase in cpu frequency is asked. This cycle if it repeats will see a few cpus heavily loaded with the maximum frequency that it could possibly run at, while the rest are not at all. Will this patch result in such a see-saw situation? This is something I am unable to make out. Currently the scheduler sees all cpus alike at a core level. So the bias towards some cpu is based only on the load. But in this patch, the bias in scheduling can be based on cpu frequency as well. What kind of an impact can this have on load balancing? This is my primary concern. Probably you will be able to see this in your testing. But just bringing out this point. > >> Secondly, I think we should spend more time on when to make a call to >> the frequency driver in your patchset regarding the change in the >> frequency of the CPU, the scheduler wishes to request. The reason being, >> the whole effort of integrating the knowledge of cpu frequency >> statistics into the scheduler is being done because the scheduler can >> call the frequency driver at times *complimenting* load balancing, >> unlike now. > > I don't think I get your point here. The current policy in this patch > set is just a prototype that should be improved. The power scheduler > does complement the load-balancer already by asking for frequency > changes as the cpu load changes. Scenario : Lets say the scheduler at some point finds that load balancing cannot be done for performance at some point in time. At this time, it would be good to have the frequencies of the cpus boosted. In the existing implementation, the cpu frequency governor gets called after certain intervals of time, asynchronous with the load balancing. In the above scenario the frequency governor would probably not come to the rescue in time to ask for a boost in the frequency of the cpus. Your patch has the potential to solve this. We are now considering calling calculate_cpu_capacities() in the scheduler tick. Will this solve the above
Re: [RFC 3/4] Seperate page initialization into a separate function.
On Fri, Jul 12, 2013 at 08:06:52PM -0700, Yinghai Lu wrote:
> On Thu, Jul 11, 2013 at 7:03 PM, Robin Holt wrote:
> > Currently, memmap_init_zone() has all the smarts for initializing a
> > single page. When we convert to initializing pages in a 2MiB chunk,
> > we will need to do this equivalent work from two separate places
> > so we are breaking out a helper function.
> >
> > Signed-off-by: Robin Holt
> > Signed-off-by: Nate Zimmer
> > To: "H. Peter Anvin"
> > To: Ingo Molnar
> > Cc: Linux Kernel
> > Cc: Linux MM
> > Cc: Rob Landley
> > Cc: Mike Travis
> > Cc: Daniel J Blueman
> > Cc: Andrew Morton
> > Cc: Greg KH
> > Cc: Yinghai Lu
> > Cc: Mel Gorman
> > ---
> > mm/mm_init.c| 2 +-
> > mm/page_alloc.c | 75
> > +
> > 2 files changed, 45 insertions(+), 32 deletions(-)
> >
> > diff --git a/mm/mm_init.c b/mm/mm_init.c
> > index c280a02..be8a539 100644
> > --- a/mm/mm_init.c
> > +++ b/mm/mm_init.c
> > @@ -128,7 +128,7 @@ void __init mminit_verify_pageflags_layout(void)
> > BUG_ON(or_mask != add_mask);
> > }
> >
> > -void __meminit mminit_verify_page_links(struct page *page, enum zone_type
> > zone,
> > +void mminit_verify_page_links(struct page *page, enum zone_type zone,
> > unsigned long nid, unsigned long pfn)
> > {
> > BUG_ON(page_to_nid(page) != nid);
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index c3edb62..635b131 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -697,6 +697,49 @@ static void free_one_page(struct zone *zone, struct
> > page *page, int order,
> > spin_unlock(>lock);
> > }
> >
> > +static void __init_single_page(struct page *page, unsigned long zone, int
> > nid, int reserved)
> > +{
> > + unsigned long pfn = page_to_pfn(page);
> > + struct zone *z = _DATA(nid)->node_zones[zone];
> > +
> > + set_page_links(page, zone, nid, pfn);
> > + mminit_verify_page_links(page, zone, nid, pfn);
> > + init_page_count(page);
> > + page_mapcount_reset(page);
> > + page_nid_reset_last(page);
> > + if (reserved) {
> > + SetPageReserved(page);
> > + } else {
> > + ClearPageReserved(page);
> > + set_page_count(page, 0);
> > + }
> > + /*
> > +* Mark the block movable so that blocks are reserved for
> > +* movable at startup. This will force kernel allocations
> > +* to reserve their blocks rather than leaking throughout
> > +* the address space during boot when many long-lived
> > +* kernel allocations are made. Later some blocks near
> > +* the start are marked MIGRATE_RESERVE by
> > +* setup_zone_migrate_reserve()
> > +*
> > +* bitmap is created for zone's valid pfn range. but memmap
> > +* can be created for invalid pages (for alignment)
> > +* check here not to call set_pageblock_migratetype() against
> > +* pfn out of zone.
> > +*/
> > + if ((z->zone_start_pfn <= pfn)
> > + && (pfn < zone_end_pfn(z))
> > + && !(pfn & (pageblock_nr_pages - 1)))
> > + set_pageblock_migratetype(page, MIGRATE_MOVABLE);
> > +
> > + INIT_LIST_HEAD(>lru);
> > +#ifdef WANT_PAGE_VIRTUAL
> > + /* The shift won't overflow because ZONE_NORMAL is below 4G. */
> > + if (!is_highmem_idx(zone))
> > + set_page_address(page, __va(pfn << PAGE_SHIFT));
> > +#endif
> > +}
> > +
> > static bool free_pages_prepare(struct page *page, unsigned int order)
> > {
> > int i;
> > @@ -3934,37 +3977,7 @@ void __meminit memmap_init_zone(unsigned long size,
> > int nid, unsigned long zone,
> > continue;
> > }
> > page = pfn_to_page(pfn);
> > - set_page_links(page, zone, nid, pfn);
> > - mminit_verify_page_links(page, zone, nid, pfn);
> > - init_page_count(page);
> > - page_mapcount_reset(page);
> > - page_nid_reset_last(page);
> > - SetPageReserved(page);
> > - /*
> > -* Mark the block movable so that blocks are reserved for
> > -* movable at startup. This will force kernel allocations
> > -* to reserve their blocks rather than leaking throughout
> > -* the address space during boot when many long-lived
> > -* kernel allocations are made. Later some blocks near
> > -* the start are marked MIGRATE_RESERVE by
> > -* setup_zone_migrate_reserve()
> > -*
> > -* bitmap is created for zone's valid pfn range. but memmap
> > -* can be created for invalid pages (for alignment)
> > -* check here not to call set_pageblock_migratetype()
> > against
> > -* pfn out of
Re: [PATCH] mm/hugetlb: per-vma instantiation mutexes
On Fri, 2013-07-12 at 17:54 -0700, Hugh Dickins wrote:
> Adding the essential David Gibson to the Cc list.
>
> On Fri, 12 Jul 2013, Davidlohr Bueso wrote:
>
> > The hugetlb_instantiation_mutex serializes hugepage allocation and
> > instantiation
> > in the page directory entry. It was found that this mutex can become quite
> > contended
> > during the early phases of large databases which make use of huge pages -
> > for instance
> > startup and initial runs. One clear example is a 1.5Gb Oracle database,
> > where lockstat
> > reports that this mutex can be one of the top 5 most contended locks in the
> > kernel during
> > the first few minutes:
> >
> > hugetlb_instantiation_mutex: 10678 10678
> > ---
> > hugetlb_instantiation_mutex10678 []
> > hugetlb_fault+0x9e/0x340
> > ---
> > hugetlb_instantiation_mutex10678 []
> > hugetlb_fault+0x9e/0x340
> >
> > contentions: 10678
> > acquisitions: 99476
> > waittime-total: 76888911.01 us
> >
> > Instead of serializing each hugetlb fault, we can deal with concurrent
> > faults for pages
> > in different vmas. The per-vma mutex is initialized when creating a new
> > vma. So, back to
> > the example above, we now get much less contention:
> >
> > >hugetlb_instantiation_mutex: 1 1
> >-
> >>hugetlb_instantiation_mutex 1 []
> > hugetlb_fault+0xa6/0x350
> >-
> >>hugetlb_instantiation_mutex 1[]
> > hugetlb_fault+0xa6/0x350
> >
> > contentions: 1
> > acquisitions:108092
> > waittime-total: 621.24 us
> >
> > Signed-off-by: Davidlohr Bueso
>
> I agree this is a problem worth solving,
> but I doubt this patch is the right solution.
>
> > ---
> > include/linux/mm_types.h | 3 +++
> > mm/hugetlb.c | 12 +---
> > mm/mmap.c| 3 +++
> > 3 files changed, 11 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index fb425aa..b45fd87 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -289,6 +289,9 @@ struct vm_area_struct {
> > #ifdef CONFIG_NUMA
> > struct mempolicy *vm_policy;/* NUMA policy for the VMA */
> > #endif
> > +#ifdef CONFIG_HUGETLB_PAGE
> > + struct mutex hugetlb_instantiation_mutex;
> > +#endif
> > };
>
> Bloating every vm_area_struct with a rarely useful mutex:
> I'm sure you can construct cases where per-vma mutex would win over
> per-mm mutex, but they will have to be very common to justify the bloat.
>
I cannot disagree here, this was my main concern about this patch, and,
as you mentioned, if we can just get rid of the need for the lock, much
better.
> >
> > struct core_thread {
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 83aff0a..12e665b 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -137,12 +137,12 @@ static inline struct hugepage_subpool
> > *subpool_vma(struct vm_area_struct *vma)
> > * The region data structures are protected by a combination of the
> > mmap_sem
> > * and the hugetlb_instantion_mutex. To access or modify a region the
> > caller
> > * must either hold the mmap_sem for write, or the mmap_sem for read and
> > - * the hugetlb_instantiation mutex:
> > + * the vma's hugetlb_instantiation mutex:
>
> Reading the existing comment, this change looks very suspicious to me.
> A per-vma mutex is just not going to provide the necessary exclusion, is
> it? (But I recall next to nothing about these regions and reservations.)
>
> > *
> > * down_write(>mmap_sem);
> > * or
> > * down_read(>mmap_sem);
> > - * mutex_lock(_instantiation_mutex);
> > + * mutex_lock(>hugetlb_instantiation_mutex);
> > */
> > struct file_region {
> > struct list_head link;
> > @@ -2547,7 +2547,7 @@ static int unmap_ref_private(struct mm_struct *mm,
> > struct vm_area_struct *vma,
> >
> > /*
> > * Hugetlb_cow() should be called with page lock of the original hugepage
> > held.
> > - * Called with hugetlb_instantiation_mutex held and pte_page locked so we
> > + * Called with the vma's hugetlb_instantiation_mutex held and pte_page
> > locked so we
> > * cannot race with other handlers or page migration.
> > * Keep the pte_same checks anyway to make transition from the mutex
> > easier.
> > */
> > @@ -2847,7 +2847,6 @@ int hugetlb_fault(struct mm_struct *mm, struct
> > vm_area_struct *vma,
> > int ret;
> > struct page *page = NULL;
> > struct page *pagecache_page = NULL;
> > - static DEFINE_MUTEX(hugetlb_instantiation_mutex);
> > struct hstate *h = hstate_vma(vma);
> >
> > address &= huge_page_mask(h);
> > @@ -2872,7 +2871,7 @@ int hugetlb_fault(struct mm_struct *mm, struct
> > vm_area_struct *vma,
> > * get spurious allocation failures if two CPUs race to
Re: sunrpc/clnt.c: BUG kmalloc-256 (Not tainted): Poison overwritten
On Sun, 2013-07-14 at 10:02 +0200, Toralf Förster wrote: > This bisected commit produces at a 32 bit user mode linux guest the attached > BUG : > > commit 245268c951262b861bc1be4e9dc812352499 > Author: Trond Myklebust > Date: Wed Jul 10 15:33:01 2013 -0400 > > SUNRPC: Fix a deadlock in rpc_client_register() > > Commit 384816051ca9125cd54750e59c780c2a2655fa4f (SUNRPC: fix races on > PipeFS MOUNT notifications) introduces a regression when we call > rpc_setup_pipedir() with RPCSEC_GSS as the auth flavour. > > By calling rpcauth_create() while holding the sn->pipefs_sb_lock, we > end up deadlocking in gss_pipes_dentries_create_net(). > Fix is to register the client and release the mutex before calling > rpcauth_create(). > > Reported-by: Weston Andros Adamson > Tested-by: Weston Andros Adamson > Cc: Stanislav Kinsbursky > Cc: # : 3848160: SUNRPC: fix races on PipeFS > MOUNT > Cc: # : e73f4cc: SUNRPC: split client creation > Signed-off-by: Trond Myklebust > > > > > > > 2013-07-13T22:09:07.000+02:00 trinity sm-notify[1042]: Version 1.2.6 starting > 2013-07-13T22:09:07.000+02:00 trinity sm-notify[1042]: Backgrounding to > notify hosts... > 2013-07-13T22:09:07.000+02:00 trinity sm-notify[1043]: Running as root. > chown /var/lib/nfs to choose different user > 2013-07-13T22:09:10.000+02:00 trinity mount[1047]: mount to NFS server > 'n22stab4' failed: No route to host, retrying > 2013-07-13T22:09:11.000+02:00 trinity dhcpcd[971]: eth0: sending IPv6 Router > Solicitation > 2013-07-13T22:09:11.000+02:00 trinity dhcpcd[971]: eth0: no IPv6 Routers > available > 2013-07-13T22:09:13.000+02:00 trinity mount[1048]: mount to NFS server > 'n22stab4' failed: No route to host, retrying > 2013-07-13T22:09:13.647+02:00 trinity kernel: > = > 2013-07-13T22:09:13.647+02:00 trinity kernel: BUG kmalloc-256 (Not tainted): > Poison overwritten > 2013-07-13T22:09:13.647+02:00 trinity kernel: > - > 2013-07-13T22:09:13.647+02:00 trinity kernel: > 2013-07-13T22:09:13.647+02:00 trinity kernel: Disabling lock debugging due to > kernel taint > 2013-07-13T22:09:13.647+02:00 trinity kernel: INFO: 0x49b1ed18-0x49b1ed1b. > First byte 0x74 instead of 0x6b > 2013-07-13T22:09:13.647+02:00 trinity kernel: INFO: Allocated in > rpc_new_client+0x81/0x3a0 age=300 cpu=0 pid=1049 > 2013-07-13T22:09:13.647+02:00 trinity kernel: INFO: Freed in > rpc_new_client+0x35a/0x3a0 age=300 cpu=0 pid=1049 > 2013-07-13T22:09:13.647+02:00 trinity kernel: INFO: Slab 0x0b87bac0 > objects=13 used=13 fp=0x (null) flags=0x0080 > 2013-07-13T22:09:13.647+02:00 trinity kernel: INFO: Object 0x49b1ed10 > @offset=3344 fp=0x49b1ee40 > 2013-07-13T22:09:13.653+02:00 trinity kernel: > 2013-07-13T22:09:13.653+02:00 trinity kernel: Bytes b4 49b1ed00: f6 03 00 00 > bd 94 ff ff 5a 5a 5a 5a 5a 5a 5a 5a > 2013-07-13T22:09:13.653+02:00 trinity kernel: Object 49b1ed10: 6b 6b 6b 6b 6b > 6b 6b 6b 74 3a 85 49 6b 6b 6b 6b t:.I > 2013-07-13T22:09:13.653+02:00 trinity kernel: Object 49b1ed20: 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 2013-07-13T22:09:13.653+02:00 trinity kernel: Object 49b1ed30: 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 2013-07-13T22:09:13.653+02:00 trinity kernel: Object 49b1ed40: 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 2013-07-13T22:09:13.653+02:00 trinity kernel: Object 49b1ed50: 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 2013-07-13T22:09:13.653+02:00 trinity kernel: Object 49b1ed60: 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 2013-07-13T22:09:13.653+02:00 trinity kernel: Object 49b1ed70: 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 2013-07-13T22:09:13.653+02:00 trinity kernel: Object 49b1ed80: 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 2013-07-13T22:09:13.660+02:00 trinity kernel: Object 49b1ed90: 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 2013-07-13T22:09:13.660+02:00 trinity kernel: Object 49b1eda0: 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 2013-07-13T22:09:13.660+02:00 trinity kernel: Object 49b1edb0: 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 2013-07-13T22:09:13.660+02:00 trinity kernel: Object 49b1edc0: 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 2013-07-13T22:09:13.660+02:00 trinity kernel: Object 49b1edd0: 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 2013-07-13T22:09:13.660+02:00 trinity kernel: Object 49b1ede0: 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 2013-07-13T22:09:13.660+02:00 trinity kernel: Object 49b1edf0: 6b 6b 6b 6b 6b > 6b
Re: [LOCKDEP] cpufreq: possible circular locking dependency detected
On 07/14/2013 11:56 PM, Rafael J. Wysocki wrote:
[snip]
>> +
>> +/*
>> + * Since there is no lock to prvent re-queue the
>> + * cancelled work, some early cancelled work might
>> + * have been queued again by later cancelled work.
>> + *
>> + * Flush the work again with dbs_data->queue_stop
>> + * enabled, this time there will be no survivors.
>> + */
>> +if (round)
>> +goto redo;
>
> Well, what about doing:
>
> for (round = 2; round; round--)
> for_each_cpu(i, policy->cpus) {
> cdbs = dbs_data->cdata->get_cpu_cdbs(i);
> cancel_delayed_work_sync(>work);
> }
>
> instead?
>
It could works, while I was a little dislike to use nested 'for' logical...
Anyway, seems like we have not solved the issue yet, so let's put these
down and focus on the fix firstly ;-)
Regards,
Michael Wang
>> +dbs_data->queue_stop = 0;
>> }
>>
>> /* Will return if we need to evaluate cpu load again or not */
>> diff --git a/drivers/cpufreq/cpufreq_governor.h
>> b/drivers/cpufreq/cpufreq_governor.h
>> index e16a961..9116135 100644
>> --- a/drivers/cpufreq/cpufreq_governor.h
>> +++ b/drivers/cpufreq/cpufreq_governor.h
>> @@ -213,6 +213,7 @@ struct dbs_data {
>> unsigned int min_sampling_rate;
>> int usage_count;
>> void *tuners;
>> +int queue_stop;
>>
>> /* dbs_mutex protects dbs_enable in governor start/stop */
>> struct mutex mutex;
>>
>
>
--
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: [LOCKDEP] cpufreq: possible circular locking dependency detected
On 07/14/2013 07:47 PM, Sergey Senozhatsky wrote:
[snip]
>
> Hello,
>
> I just realized that lockdep was disabling itself at startup (after recent AMD
> radeon patch set) due to radeon kms error:
>
> [4.790019] [drm] Loading CEDAR Microcode
> [4.790943] r600_cp: Failed to load firmware "radeon/CEDAR_smc.bin"
> [4.791152] [drm:evergreen_startup] *ERROR* Failed to load firmware!
> [4.791330] radeon :01:00.0: disabling GPU acceleration
> [4.792633] INFO: trying to register non-static key.
> [4.792792] the code is fine but needs lockdep annotation.
> [4.792953] turning off the locking correctness validator.
>
>
> Now, as I fixed radeon kms, I can see:
>
> [ 806.660530] [ cut here ]
> [ 806.660539] WARNING: CPU: 0 PID: 2389 at arch/x86/kernel/smp.c:124
> native_smp_send_reschedule+0x57/0x60()
>
> [ 806.660572] Workqueue: events od_dbs_timer
> [ 806.660575] 0009 8801531cfbd8 816044ee
>
> [ 806.660577] 8801531cfc10 8104995d 0003
> 8801531f8000
> [ 806.660579] 00010001ee39 0003 0003
> 8801531cfc20
> [ 806.660580] Call Trace:
> [ 806.660587] [] dump_stack+0x4e/0x82
> [ 806.660591] [] warn_slowpath_common+0x7d/0xa0
> [ 806.660593] [] warn_slowpath_null+0x1a/0x20
> [ 806.660595] [] native_smp_send_reschedule+0x57/0x60
> [ 806.660599] [] wake_up_nohz_cpu+0x61/0xb0
> [ 806.660603] [] add_timer_on+0x8d/0x1e0
> [ 806.660607] [] __queue_delayed_work+0x166/0x1a0
> [ 806.660609] [] ? try_to_grab_pending+0xd9/0x1a0
> [ 806.660611] [] mod_delayed_work_on+0x4f/0x90
> [ 806.660613] [] gov_queue_work+0x56/0xd0
> [ 806.660615] [] od_dbs_timer+0xc0/0x160
> [ 806.660617] [] process_one_work+0x1cd/0x6a0
> [ 806.660619] [] ? process_one_work+0x163/0x6a0
> [ 806.660622] [] worker_thread+0x121/0x3a0
> [ 806.660627] [] ? trace_hardirqs_on+0xd/0x10
> [ 806.660629] [] ? manage_workers.isra.24+0x2a0/0x2a0
> [ 806.660633] [] kthread+0xdb/0xe0
> [ 806.660635] [] ? insert_kthread_work+0x70/0x70
> [ 806.660639] [] ret_from_fork+0x7c/0xb0
> [ 806.660640] [] ? insert_kthread_work+0x70/0x70
> [ 806.660642] ---[ end trace 01ae278488a0ad6d ]---
So it back again...
Currently I have some assumptions in my mind:
1. we still failed to stop od_dbs_timer after STOP notify.
2. there is some code else which restart the work after STOP notify.
3. policy->cpus is broken.
I think we need a more detail investigation this time, let's catch the
mouse out ;-)
Regards,
Michael Wang
>
>
> The same problem why get/put_online_cpus() has been added to
> __gov_queue_work()
>
> commit 2f7021a815f20f3481c10884fe9735ce2a56db35
> Author: Michael Wang
>
> cpufreq: protect 'policy->cpus' from offlining during
> __gov_queue_work()
>
> -ss
>
>> Regards,
>> Michael Wang
>>
>> diff --git a/drivers/cpufreq/cpufreq_governor.c
>> b/drivers/cpufreq/cpufreq_governor.c
>> index dc9b72e..a64b544 100644
>> --- a/drivers/cpufreq/cpufreq_governor.c
>> +++ b/drivers/cpufreq/cpufreq_governor.c
>> @@ -178,13 +178,14 @@ void gov_queue_work(struct dbs_data *dbs_data, struct
>> cpufreq_policy *policy,
>> {
>> int i;
>>
>> +if (dbs_data->queue_stop)
>> +return;
>> +
>> if (!all_cpus) {
>> __gov_queue_work(smp_processor_id(), dbs_data, delay);
>> } else {
>> -get_online_cpus();
>> for_each_cpu(i, policy->cpus)
>> __gov_queue_work(i, dbs_data, delay);
>> -put_online_cpus();
>> }
>> }
>> EXPORT_SYMBOL_GPL(gov_queue_work);
>> @@ -193,12 +194,27 @@ static inline void gov_cancel_work(struct dbs_data
>> *dbs_data,
>> struct cpufreq_policy *policy)
>> {
>> struct cpu_dbs_common_info *cdbs;
>> -int i;
>> +int i, round = 2;
>>
>> +dbs_data->queue_stop = 1;
>> +redo:
>> +round--;
>> for_each_cpu(i, policy->cpus) {
>> cdbs = dbs_data->cdata->get_cpu_cdbs(i);
>> cancel_delayed_work_sync(>work);
>> }
>> +
>> +/*
>> + * Since there is no lock to prvent re-queue the
>> + * cancelled work, some early cancelled work might
>> + * have been queued again by later cancelled work.
>> + *
>> + * Flush the work again with dbs_data->queue_stop
>> + * enabled, this time there will be no survivors.
>> + */
>> +if (round)
>> +goto redo;
>> +dbs_data->queue_stop = 0;
>> }
>>
>> /* Will return if we need to evaluate cpu load again or not */
>> diff --git a/drivers/cpufreq/cpufreq_governor.h
>> b/drivers/cpufreq/cpufreq_governor.h
>> index e16a961..9116135 100644
>> --- a/drivers/cpufreq/cpufreq_governor.h
>> +++ b/drivers/cpufreq/cpufreq_governor.h
>> @@ -213,6 +213,7 @@ struct dbs_data {
>> unsigned int min_sampling_rate;
>> int usage_count;
>> void *tuners;
>> +int queue_stop;
>>
>> /* dbs_mutex protects dbs_enable in
Re: [3.10.1 MEI_ME] strange kernel crash
This has happened again. This time without warnings and without suspend-resume. Seems like 'mei_me' corrupts kernel memory. My setup is simple: it's thinkpad x220 which receives flow of wake-on-lan packets via the ethernet. [ 6596.895370] mei_me :00:16.0: version message writet failed [ 6596.895373] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 6596.895376] mei_me :00:16.0: version message writet failed [ 6596.895378] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 6596.895381] mei_me :00:16.0: version message writet failed [ 6596.895383] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 6596.895386] mei_me :00:16.0: version message writet failed [ 6596.895388] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 6596.895391] mei_me :00:16.0: version message writet failed [ 6596.895394] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 6596.895397] mei_me :00:16.0: version message writet failed [ 6596.895399] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 6596.895402] general protection fault: [#1] SMP [ 6596.895423] Modules linked in: iwldvm iwlwifi nfsd auth_rpcgss oid_registry nfs_acl nfs lockd sunrpc bridge stp llc tun fuse snd_hda_codec_hdmi snd_hda_codec_conexant iTCO_wdt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc intel_powerclamp coretemp snd_seq_midi snd_seq_midi_event kvm_intel kvm snd_rawmidi cdc_ncm usbnet mii uvcvideo cdc_acm cdc_wdm snd_seq videobuf2_vmalloc snd_seq_device snd_timer videobuf2_memops videobuf2_core videodev lpc_ich mfd_core thinkpad_acpi snd wmi i915 soundcore drm_kms_helper hid_logitech_dj sdhci_pci sdhci e1000e ptp [ 6596.895425] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.10.1-zurg-1-gaa457b5 #107 [ 6596.895426] Hardware name: LENOVO 4291QY6/4291QY6, BIOS 8DET51WW (1.21 ) 08/02/2011 [ 6596.895427] task: 88040c0bc560 ti: 88040c12e000 task.ti: 88040c12e000 [ 6596.895433] RIP: 0010:[] [] load_cr3+0x21/0x30 [ 6596.895434] RSP: 0018:88040c12fe78 EFLAGS: 00010002 [ 6596.895435] RAX: 77ff8000 RBX: 88040abf1380 RCX: 0002 [ 6596.895436] RDX: 8000 RSI: 88040595be70 RDI: 7801 [ 6596.895436] RBP: 88040c12fe78 R08: R09: 0001 [ 6596.895437] R10: 0001 R11: 7fff R12: 88041e292dc0 [ 6596.895438] R13: 88040abf1380 R14: R15: 88040595be70 [ 6596.895440] FS: () GS:88041e28() knlGS: [ 6596.895440] CS: 0010 DS: ES: CR0: 80050033 [ 6596.895441] CR2: 7f3ec00571e8 CR3: 000408848000 CR4: 000407e0 [ 6596.895442] DR0: DR1: DR2: [ 6596.895443] DR3: DR6: 0ff0 DR7: 0400 [ 6596.895443] Stack: [ 6596.895445] 88040c12fed8 81626aa4 88040c12ffd8 00012dc0 [ 6596.895446] 88040c12ffd8 00012dc0 88040c0bc560 88040c12ffd8 [ 6596.895447] 88040c12ffd8 88040c12ffd8 88040c12ffd8 88040c12ffd8 [ 6596.895448] Call Trace: [ 6596.895454] [] __schedule+0x784/0x7c0 [ 6596.895456] [] schedule_preempt_disabled+0x29/0x70 [ 6596.895459] [] cpu_startup_entry+0x1f5/0x230 [ 6596.895461] [] ? clockevents_config_and_register+0x28/0x30 [ 6596.895464] [] start_secondary+0x209/0x20b [ 6596.895479] Code: e8 05 b1 5a 00 5b 41 5c 5d c3 ba 00 00 00 80 48 b8 00 00 00 80 ff 77 00 00 55 48 01 d7 48 0f 42 05 a5 6b b9 00 48 89 e5 48 01 c7 <0f> 22 df 66 66 66 90 5d c3 66 0f 1f 44 00 00 66 66 66 66 90 48 [ 6596.895481] RIP [] load_cr3+0x21/0x30 [ 6596.895481] RSP Konstantin Khlebnikov wrote: first and only warning had happened here: Jul 14 22:49:33 zurg kernel: [ 6169.400920] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 22:50:03 zurg kernel: [ 6199.422111] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 22:50:33 zurg kernel: [ 6229.443292] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 22:51:03 zurg kernel: [ 6259.464476] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 22:51:33 zurg kernel: [ 6289.485675] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 22:52:03 zurg kernel: [ 6319.506868] mei_me :00:16.0: unexpected reset: dev_state = RESETTING soon after that kernel had crashed [ 6349.664704] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 6349.664709] mei_me :00:16.0: version message writet failed [ 6349.664711] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 6349.664714] mei_me :00:16.0: version message writet failed [ 6349.664716] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 6349.664719] mei_me :00:16.0: version message writet failed [ 6349.988121] kernel tried to execute NX-protected page - exploit attempt? (uid: 1000) [
Re: [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On 07/13/2013 08:46 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows [8] doesn't use the ACPI interface, including the fact that
> it's broken on a bunch of machines when the OS claims to support
> Windows 8. The simplest thing to do appears to be to disable the
> ACPI backlight interface on these systems".
>
> There's a problem with that approach, however, because simply
> avoiding to register the ACPI backlight interface if the firmware
> calls _OSI for Windows 8 may not work in the following situations:
> (1) The ACPI backlight interface actually works on the given system
> and the i915 driver is not loaded (e.g. another graphics driver
> is used).
> (2) The ACPI backlight interface doesn't work on the given system,
> but there is a vendor platform driver that will register its
> own, equally broken, backlight interface if not prevented from
> doing so by the ACPI subsystem.
> Therefore we need to allow the ACPI backlight interface to be
> registered until the i915 driver is loaded which then will unregister
> it if the firmware has called _OSI for Windows 8 (or will register
> the ACPI video driver without backlight support if not already
> present).
>
> For this reason, introduce an alternative function for registering
> ACPI video, acpi_video_register_with_quirks(), that will check
> whether or not the ACPI video driver has already been registered
> and whether or not the backlight Windows 8 quirk has to be applied.
> If the quirk has to be applied, it will block the ACPI backlight
> support and either unregister the backlight interface if the ACPI
> video driver has already been registered, or register the ACPI
> video driver without the backlight interface otherwise. Make
> the i915 driver use acpi_video_register_with_quirks() instead of
> acpi_video_register() in i915_driver_load().
>
> This change is based on earlier patches from Matthew Garrett,
> Chun-Yi Lee and Seth Forshee and Aaron Lu's comments.
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Aaron Lu
BTW, I also tested on a Toshiba laptop Z830 where its AML code
claims support of win8, the result is as expected: ACPI video
interface is removed, i915 Xorg driver picks intel_backlight.
Thanks for the fix.
-Aaron
> ---
> drivers/acpi/internal.h | 11 ++
> drivers/acpi/video.c| 65
>
> drivers/acpi/video_detect.c | 21
> drivers/gpu/drm/i915/i915_dma.c |2 -
> include/acpi/video.h| 11 ++
> include/linux/acpi.h|1
> 6 files changed, 103 insertions(+), 8 deletions(-)
>
> Index: linux-pm/drivers/acpi/video.c
> ===
> --- linux-pm.orig/drivers/acpi/video.c
> +++ linux-pm/drivers/acpi/video.c
> @@ -44,6 +44,8 @@
> #include
> #include
>
> +#include "internal.h"
> +
> #define PREFIX "ACPI: "
>
> #define ACPI_VIDEO_BUS_NAME "Video Bus"
> @@ -898,7 +900,7 @@ static void acpi_video_device_find_cap(s
> device->cap._DDC = 1;
> }
>
> - if (acpi_video_backlight_support()) {
> + if (acpi_video_verify_backlight_support()) {
> struct backlight_properties props;
> struct pci_dev *pdev;
> acpi_handle acpi_parent;
> @@ -1854,6 +1856,46 @@ static int acpi_video_bus_remove(struct
> return 0;
> }
>
> +static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
> + void *context, void **rv)
> +{
> + struct acpi_device *acpi_dev;
> + struct acpi_video_bus *video;
> + struct acpi_video_device *dev, *next;
> +
> + if (acpi_bus_get_device(handle, _dev))
> + return AE_OK;
> +
> + if (acpi_match_device_ids(acpi_dev, video_device_ids))
> + return AE_OK;
> +
> + video = acpi_driver_data(acpi_dev);
> + if (!video)
> + return AE_OK;
> +
> + acpi_video_bus_stop_devices(video);
> + mutex_lock(>device_list_lock);
> + list_for_each_entry_safe(dev, next, >video_device_list, entry) {
> + if (dev->backlight) {
> + backlight_device_unregister(dev->backlight);
> + dev->backlight = NULL;
> + kfree(dev->brightness->levels);
> + kfree(dev->brightness);
> + }
> + if (dev->cooling_dev) {
> + sysfs_remove_link(>dev->dev.kobj,
> + "thermal_cooling");
> + sysfs_remove_link(>cooling_dev->device.kobj,
> + "device");
> +
Re: next-20130709 DMAR issues
I have met a bug with the same error message, its cause was that the bios did not allocate RMRR/DRHD(can't remember which one) for the device. Thanks ZhenHua On 07/12/2013 10:31 PM, Joerg Roedel wrote: Thanks for the heads-up, Ingo. On Fri, Jul 12, 2013 at 02:14:20PM +0200, Ingo Molnar wrote: Jul 10 12:20:19 turing-police kernel: [0.021583] DMAR:[fault reason 06] PTE Read access is not set Now I have 3 extra messages talking about handling a fault status. lspci says 00:1f.2 is: 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) This could be caused by some change in the SATA driver stack. Maybe a DMA buffer is used after unmap or something. If this doesn't ring any bells, I'l go do the bisect thing... Yes, a bisection would help here, thanks for doing this. Joerg . -- 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] kernel: trace: remove __init from race_selftest_startup_function() and trace_selftest_startup_function_graph()
On 07/12/2013 03:20 PM, Chen Gang wrote:
> On 07/12/2013 11:04 AM, Chen Gang wrote:
>> On 07/12/2013 10:38 AM, Steven Rostedt wrote:
>>> On Fri, 2013-07-12 at 09:58 +0800, Chen Gang wrote:
On 07/12/2013 09:41 AM, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote:
>
>>> Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c)
>>> use '__init', so not waste memory keeping them around ?
> Yeah, they should all be set to __init, but that's pretty low on the
> totem poll, as distros don't enable selftests in their main kernels.
Excuse me, my English is not quite well, I guess your meaning is:
they should all be set to '__init', although it is minor in real world.
Is it correct ?
>>>
>>> Correct.
>>>
For me, I recommend to let all *selftest* as the same: "all add '
__init' or none add '__init'" (if choose add, all report warnings).
Is it suitable to still send new related patch for it ? If so, could
you provide your suggesting choice (all add, or none add) ?
>>>
>>> Does this patch fix your warning?
>>>
>>> -- Steve
>>>
>>
>
> After the test, they will not report the related warning.
>
> Hmm..., but that will let another none *selftest* functions miss
> '__read_mostly'.
>
> Do the original *selftest* intend to have no '__init' so can fit other
> none *selftest* with '__read_mostly', and without warnings ?
>
> Welcome any members' suggestions or completions.
>
> Thanks.
>
Hello Frederic and Ingo:
Could you provide your suggestions or completions for it ?
The trace_selftest_startup_* funcitons are mostly added by you without
'__init', do you have additional considerations about it (intend to have
no '__init') ?
If no reply, I recommend to keep no '__init': apply this patch or
regress part of the patch "f1ed7c7 ftrace: Do not run selftest if
command line parameter is set" (at least, it can avoid related warnings
and treat all *selftest* fair).
Thanks.
>> I guess it can (although I do not give a compiling test), it seems a
>> better fixing.
>>
>> And is it suitable to let all *selftest* as the same ? (all add, or none
>> add '__init').
>>
>> Thanks.
>>
>>> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
>>> index a4ed382..5e794d1 100644
>>> --- a/kernel/trace/trace.h
>>> +++ b/kernel/trace/trace.h
>>> @@ -680,6 +680,15 @@ extern int trace_selftest_startup_sched_switch(struct
>>> tracer *trace,
>>>struct trace_array *tr);
>>> extern int trace_selftest_startup_branch(struct tracer *trace,
>>> struct trace_array *tr);
>>> +/*
>>> + * Tracer data references selftest functions that only occur
>>> + * on boot up. These can be __init functions. Thus, when selftests
>>> + * are enabled, then the tracers need to reference __init functions.
>>> + */
>>> +#define __tracer_data __refdata
>>> +#else
>>> +/* Tracers are seldom changed. Optimize when selftests are disabled. */
>>> +#define __tracer_data __read_mostly
>>> #endif /* CONFIG_FTRACE_STARTUP_TEST */
>>>
>>> extern void *head_page(struct trace_array_cpu *data);
>>> diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
>>> index b863f93..38fe148 100644
>>> --- a/kernel/trace/trace_functions.c
>>> +++ b/kernel/trace/trace_functions.c
>>> @@ -199,7 +199,7 @@ static int func_set_flag(u32 old_flags, u32 bit, int
>>> set)
>>> return 0;
>>> }
>>>
>>> -static struct tracer function_trace __read_mostly =
>>> +static struct tracer function_trace __tracer_data =
>>> {
>>> .name = "function",
>>> .init = function_trace_init,
>>>
>>>
>>>
>>>
>>
>>
>
>
--
Chen Gang
--
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: [ 00/19] 3.10.1-stable review
On Sun, 2013-07-14 at 18:40 -0700, Linus Torvalds wrote: > Not before it's been in the distro, no. Something like a PCI change > *definitely* should never be marked for stable, unless it causes > crashes or is a _new_ regression that causes dead machines. > > Because the likelihood that that 4-5 line "obvious" change breaks > things is pretty high. It needs testing elsewhere - on the machines > that weren't broken - in a big way first. > > And don't bother talking about "obvious fix". Especially not when it > comes to the PCI code. PCI resource allocation code for sure. A bug specific to the hotplug code path not so ... (for example, a too short reset delay or shit like that). I agree with you overall but there's still a judgement call happening at some point I assume and we get at least *some* flexibility as maintainers as to what we want going there or not right ? :-) Cheers, Ben. -- 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/9] sched: Power scheduler design proposal
On 07/14/2013 12:14 AM, Arjan van de Ven wrote: > > > on thinking more about the short running task thing; there is an > optimization we currently don't do, > mostly for hyperthreading. (and HT is just one out of a set of cases > with similar power behavior) > If we know a task runs briefly AND is not performance critical, it's > much much better to place it on > a hyperthreading buddy of an already busy core than it is to place it on > an empty core (or to delay it). > Yes a HT pair isn't the same performance as a full core, but in terms of > power the 2nd half of a HT pair > is nearly free... so if there's a task that's not performance sensitive > (and won't disturb the other task too much, > e.g. runs briefly enough)... it's better to pack onto a core than to > spread. > you can generalize this to a class of systems where adding work to a > core (read: group of cpus that share resources) > is significantly cheaper than running on a full empty core. Right! That is one of purpose that my old power sheduling's wanna do: https://lkml.org/lkml/2013/4/3/747 Vincent's patchset also target at this. -- Thanks Alex -- 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/
Linus-next stats (Was: Linux 3.11-rc1)
On Sun, 14 Jul 2013 16:57:23 -0700 Linus Torvalds wrote: > > This merge window was smaller in terms of number of commits than the > 3.10 merge window, but we actually have more new lines. Most of that > seems to be in staging - a full third of all changes by line-count is > staging, and merging in Lustre is the bulk of that. Let's see how that > all turns out, I have to say that we don't have a great track record > on merging filesystems through staging. > > Ignoring the lustre merge, I think this really was a somewhat calmer > merge window. We had a few trees with problems, and we have an > on-going debate about stable patches that was triggered largely thanks > to this merge window, so now we'll have something to discuss for the > kernel summit. But on the whole, I suspect we might be starting to see > the traditional summer slump (Australia notwithstanding). As usual, the executive friendly graph is at http://neuling.org/linux-next-size.html :-) (No merge commits counted, next-20130701 was the linux-next based on v3.10) Commits in v3.11-rc1 (relative to v3.10): 9494 Commits in next-20130701: 8929 Commits with the same SHA1: 7670 Commits with the same patch_id:759 (1) Commits with the same subject line: 55 (1) (1) not counting those in the lines above. So commits in -rc1 that were "in" next-20130701:848489.4% (essentially unchanged from 89.3% last time) Commits in -rc1 that were not in next-20120722: 101010.6% Pretty good, but it would be still nice to figure out where the last lot came from. I have the "git log --oneline --no-walk" list if someone wants them. Some breakdown of that list: Top ten first word of commit summary: 80 btrfs 41 arm 35 [scsi] 32 net 28 drm/exynos 25 perf 25 drm/radeon/dpm 19 vxlan 17 input 16 tracing Top ten authors: 56 Ben Skeggs 36 Alex Deucher 27 Josef Bacik 24 Miao Xie 16 J. Bruce Fields 16 Bart Van Assche 13 Stephen Hemminger 12 Michael Ellerman 12 Al Viro 10 Wei Yongjun Top ten commiters: 130 David S. Miller 81 Josef Bacik 68 Ben Skeggs 64 Linus Torvalds 39 Benjamin Herrenschmidt 37 Alex Deucher 35 James Bottomley 24 Dave Airlie 23 Thomas Gleixner 23 Arnaldo Carvalho de Melo Quite a few of these could be bug fixes (especially DaveM's). There are also 444 commits in next-20130701 that didn't make it into v3.11-rc1. Top twelve first word of commit summary: 66 arm 37 mtd 31 drm/i915 11 rsxx 10 ocfs2 9 xen-blkback 8 selinux 7 kdb 6 drbd 6 cris 6 clocksource 6 acpi Top ten authors: 43 Andrew Morton 28 Paul Gortmaker 19 Sascha Hauer 18 Dave Chinner 15 Alexander Shiyan 12 Roger Pau Monne 12 Michal Simek 11 Philip J Kelleher 10 Joern Engel 10 Daniel Vetter Some of Andrew's patches are fixes for other patches in his tree (and have been merged into those). Paul's patches are the __cpuinit removal series that should be applied right after -rc1. Top ten commiters: 184 Stephen Rothwell 39 Artem Bityutskiy 36 Shawn Guo 31 Daniel Vetter 18 Konrad Rzeszutek Wilk 17 Michal Simek 17 Jens Axboe 14 Simon Horman 14 Joern Engel 11 Rafael J. Wysocki Well, that's embarrasing :-) Those commits by me are from the quilt series (including Andrew's mmotm tree). Some of the above will have been merged into other patches or replaced, I guess. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpcQ7xnv2w9R.pgp Description: PGP signature
Re: [ 00/19] 3.10.1-stable review
On Sun, Jul 14, 2013 at 4:52 PM, Benjamin Herrenschmidt wrote: > > So if I read this (and stable_kernel_rules.txt) correctly, that means that > for example, let's say, we find in RHEL66 or SLES42 (possibly following > a user report), for example, that PCI hotplug is broken with some category > of devices on some machines. > > We do a fix, it's roughtly 4 or 5 lines, pretty self contained. We get it > into the distro. > > That still doesn't qualify for stable right ? Not before it's been in the distro, no. Something like a PCI change *definitely* should never be marked for stable, unless it causes crashes or is a _new_ regression that causes dead machines. Because the likelihood that that 4-5 line "obvious" change breaks things is pretty high. It needs testing elsewhere - on the machines that weren't broken - in a big way first. And don't bother talking about "obvious fix". Especially not when it comes to the PCI code. 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: boot tracing
On 07/12/2013 04:53 PM, Ingo Molnar wrote: * Borislav Petkov wrote: On Fri, Jul 12, 2013 at 10:27:56AM +0200, Ingo Molnar wrote: Robert Richter and Boris Petkov are working on 'persistent events' support for perf, which will eventually allow boot time profiling - I'm not sure if the patches and the tooling support is ready enough yet for your purposes. Nope, not yet but we're getting there. Robert, Boris, the following workflow would be pretty intuitive: - kernel developer sets boot flag: perf=boot,freq=1khz,size=16MB What does perf=boot mean? I assume boot tracing. In this case it would mean boot profiling - i.e. a cycles hardware-PMU event collecting into a perf trace buffer as usual. Essentially a 'perf record -a' work-alike, just one that gets activated as early as practical, and which would allow the profiling of memory initialization. Now, one extra complication here is that to be able to profile buddy allocator this persistent event would have to work before the buddy allocator is active :-/ So this sort of profiling would have to use memblock_alloc(). Could perf=boot be used to sample the performance of memblock subsystem? I think the perf subsystem is too late to be initialized and monitor this. Just wanted to highlight this usecase, we might eventually want to support it. [ Note that this is different from boot tracing of one or more trace events - but it's a conceptually pretty close cousin. ] Thanks, Ingo -- 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/ -- 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] m68knommu: Mark functions only called from setup_arch() __init
Hi Geert,
On 30/06/13 19:58, Geert Uytterhoeven wrote:
> Some functions that are only called (indirectly) from setup_arch() lack
> __init annotations.
>
> Signed-off-by: Geert Uytterhoeven
Thanks. Applied to m68knommu git tree.
Regards
Greg
> ---
> This is sort of a v2 of "m68knommu: Mark config_BSP() __init", adding
> parse_uboot_commandline(), init_hardware(), m360_cpm_reset()
>
> arch/m68k/kernel/setup_no.c |2 +-
> arch/m68k/platform/68000/m68328.c |3 ++-
> arch/m68k/platform/68000/m68EZ328.c |3 ++-
> arch/m68k/platform/68000/m68VZ328.c |9 +
> arch/m68k/platform/68360/commproc.c |3 ++-
> arch/m68k/platform/68360/config.c |3 ++-
> 6 files changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
> index 911ba47..5b16f5d 100644
> --- a/arch/m68k/kernel/setup_no.c
> +++ b/arch/m68k/kernel/setup_no.c
> @@ -118,7 +118,7 @@ void (*mach_power_off)(void);
> *
> * Returns:
> */
> -void parse_uboot_commandline(char *commandp, int size)
> +static void __init parse_uboot_commandline(char *commandp, int size)
> {
> extern unsigned long _init_sp;
> unsigned long *sp;
> diff --git a/arch/m68k/platform/68000/m68328.c
> b/arch/m68k/platform/68000/m68328.c
> index a86eb66..e53caf4 100644
> --- a/arch/m68k/platform/68000/m68328.c
> +++ b/arch/m68k/platform/68000/m68328.c
> @@ -15,6 +15,7 @@
>
> /***/
>
> +#include
> #include
> #include
> #include
> @@ -42,7 +43,7 @@ void m68328_reset (void)
>
> /***/
>
> -void config_BSP(char *command, int len)
> +void __init config_BSP(char *command, int len)
> {
>printk(KERN_INFO "\n68328 support D. Jeff Dionne \n");
>printk(KERN_INFO "68328 support Kenneth Albanowski \n");
> diff --git a/arch/m68k/platform/68000/m68EZ328.c
> b/arch/m68k/platform/68000/m68EZ328.c
> index a6eb72d..332b5e8 100644
> --- a/arch/m68k/platform/68000/m68EZ328.c
> +++ b/arch/m68k/platform/68000/m68EZ328.c
> @@ -13,6 +13,7 @@
>
> /***/
>
> +#include
> #include
> #include
> #include
> @@ -52,7 +53,7 @@ _bsc1(unsigned char *, gethwaddr, int, a)
> _bsc1(char *, getbenv, char *, a)
> #endif
>
> -void config_BSP(char *command, int len)
> +void __init config_BSP(char *command, int len)
> {
>unsigned char *p;
>
> diff --git a/arch/m68k/platform/68000/m68VZ328.c
> b/arch/m68k/platform/68000/m68VZ328.c
> index eb6964f..fd66583 100644
> --- a/arch/m68k/platform/68000/m68VZ328.c
> +++ b/arch/m68k/platform/68000/m68VZ328.c
> @@ -14,6 +14,7 @@
>
> /***/
>
> +#include
> #include
> #include
> #include
> @@ -59,7 +60,7 @@ static void m68vz328_reset(void)
> );
> }
>
> -static void init_hardware(char *command, int size)
> +static void __init init_hardware(char *command, int size)
> {
> #ifdef CONFIG_DIRECT_IO_ACCESS
> SCR = 0x10; /* allow user access to
> internal registers */
> @@ -145,7 +146,7 @@ _bsc0(char *, getserialnum)
> _bsc1(unsigned char *, gethwaddr, int, a)
> _bsc1(char *, getbenv, char *, a)
>
> -static void init_hardware(char *command, int size)
> +static void __init init_hardware(char *command, int size)
> {
> char *p;
>
> @@ -167,7 +168,7 @@ static void m68vz328_reset(void)
> {
> }
>
> -static void init_hardware(char *command, int size)
> +static void __init init_hardware(char *command, int size)
> {
> }
>
> @@ -175,7 +176,7 @@ static void init_hardware(char *command, int size)
> #endif
> /***/
>
> -void config_BSP(char *command, int size)
> +void __init config_BSP(char *command, int size)
> {
> printk(KERN_INFO "68VZ328 DragonBallVZ support (c) 2001 Lineo, Inc.\n");
>
> diff --git a/arch/m68k/platform/68360/commproc.c
> b/arch/m68k/platform/68360/commproc.c
> index 8e4e10c..315727b 100644
> --- a/arch/m68k/platform/68360/commproc.c
> +++ b/arch/m68k/platform/68360/commproc.c
> @@ -31,6 +31,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -77,7 +78,7 @@ void m360_cpm_reset(void);
>
>
>
> -void m360_cpm_reset()
> +void __init m360_cpm_reset()
> {
> /* pte_t *pte; */
>
> diff --git a/arch/m68k/platform/68360/config.c
> b/arch/m68k/platform/68360/config.c
> index 9877cef..0570741 100644
> --- a/arch/m68k/platform/68360/config.c
> +++ b/arch/m68k/platform/68360/config.c
> @@ -11,6 +11,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -140,7 +141,7 @@ _bsc1(char *, getbenv, char *, a)
> #endif
>
>
> -void config_BSP(char *command, int len)
> +void __init config_BSP(char
Re: [PATCH v2] regulator: pfuze100: add pfuze100 regulator driver
The patch looks good. Comments below are mostly random coding style
nitpicks.
On Fri, Jul 12, 2013 at 12:54:15PM +0800, Robin Gong wrote:
> Add pfuze100 regulator driver.
>
> Signed-off-by: Robin Gong
> ---
> .../devicetree/bindings/regulator/pfuze100.txt | 113 +
> drivers/regulator/Kconfig |7 +
> drivers/regulator/Makefile |1 +
> drivers/regulator/pfuze100-regulator.c | 489
>
> include/linux/regulator/pfuze.h| 49 ++
We should probably name the header in the same way as driver file, so
pfuze100.h?
> 5 files changed, 659 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/pfuze100.txt
> create mode 100644 drivers/regulator/pfuze100-regulator.c
> create mode 100644 include/linux/regulator/pfuze.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt
> b/Documentation/devicetree/bindings/regulator/pfuze100.txt
> new file mode 100644
> index 000..d9fc752
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt
> @@ -0,0 +1,113 @@
> +PFUZE100 family of regulators
> +
> +Required properties:
> +- compatible: "fsl,pfuze100"
> +- reg: I2C slave address
> +- regulators: This is the list of child nodes that specify the regulator
> + initialization data for defined regulators. Please refer to below doc
> + Documentation/devicetree/bindings/regulator/regulator.txt.
> +
> + The valid names for regulators are:
> + sw1ab,sw1c,sw2,sw3a,sw3b,sw4,swbst,vsnvs,vrefddr,vgen1~vgen6
> +
> +Each regulator is defined using the standard binding for regulators.
> +
> +Example:
> +
> + pmic: pfuze100@08 {
> + compatible = "fsl,pfuze100";
> + reg = <0x08>;
> +
> + regulators {
> + sw1a_reg: sw1ab {
> + regulator-min-microvolt = <110>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw1c_reg: sw1c {
> + regulator-min-microvolt = <11>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw2_reg: sw2 {
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3a_reg: sw3a {
> + regulator-min-microvolt = <40>;
> + regulator-max-microvolt = <1975000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3b_reg: sw3b {
> + regulator-min-microvolt = <40>;
> + regulator-max-microvolt = <1975000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw4_reg: sw4 {
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + swbst_reg: swbst {
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <515>;
> + };
> +
> + snvs_reg: vsnvs {
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <300>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vref_reg: vrefddr {
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vgen1_reg: vgen1 {
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <155>;
> + };
> +
> + vgen2_reg: vgen2 {
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <155>;
> + };
> +
> + vgen3_reg: vgen3 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> +
Re: [PATCH re-send] backlight: lp855x_bl: support new LP8555 device
On Tuesday, July 09, 2013 6:12 PM, Kim, Milo wrote: > > LP8555 is one of LP855x family device. > This device needs pre_init_device() and post_init_device() driver structure. > It's same as LP8557, so the device configuration code is shared with LP8557. > Backlight outputs are generated from dual DC-DC boost converters. > It's configurable EPROM settings which are defined in the platform data. > > Driver documentation and device tree bindings are updated. > > Signed-off-by: Milo Kim It looks good. Acked-by: Jingoo Han Best regards, Jingoo Han > --- > This patch is re-sent with additional Cc lists. > > Documentation/backlight/lp855x-driver.txt |5 ++-- > .../devicetree/bindings/video/backlight/lp855x.txt | 29 > +++- > drivers/video/backlight/Kconfig|4 +-- > drivers/video/backlight/lp855x_bl.c| 17 ++-- > include/linux/platform_data/lp855x.h | 19 + > 5 files changed, 67 insertions(+), 7 deletions(-) > -- 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] PM: avoid 'autosleep' in shutdown progress
On Sat, 2013-07-13 at 13:56 +0200, Pavel Machek wrote: > On Fri 2013-07-12 10:37:33, Alan Stern wrote: > > On Fri, 12 Jul 2013, Yanmin Zhang wrote: > > > > > On Thu, 2013-07-11 at 16:03 +0800, shuox@intel.com wrote: > > > > From: Liu ShuoX > > > > > > > > In shutdown progress, system is possible to do power transition > > > > (such as suspend-to-ram) in parallel. It is unreasonable. So, > > > > fixes it by adding a system_state checking and queue try_to_suspend > > > > again when system status is not running. > > > > > > > > Signed-off-by: Liu ShuoX > > > > --- > > > > kernel/power/autosleep.c |3 ++- > > > > 1 files changed, 2 insertions(+), 1 deletions(-) > > > > > > > Without this patch, we hit an hang issue on Android. > > > > > > Scenario: > > > Kernel starts shutdown and calls all device driver's shutdown callback. > > > When a driver's shutdown is called, the last wakelock is released and > > > suspend-to-ram starts. However, as some driver's shut down callbacks > > > already shut down devices and disable runtime pm, the suspend-to-ram > > > calls driver's suspend callback without noticing that device is already > > > off and causes crash. > > > We know the drivers should be fixed, but can we also change generic > > > codes a little to make it stronger? > > > > Indeed, this does seem like the sort of thing we want to have. > > Allowing an "automatic" or "opportunistic" sleep in the middle of a > > shutdown makes no sense at all. In fact, it might be a good idea to > > disable system sleep completely at this time -- not even a write to > > /sys/power/state should be allowed to interrupt a shutdown. > > I'm not completely sure, but as long as userland is running, we should > have system_state == RUNNING, no? No. The reboot/shutdown is started by application processes, then kernel changes system_state quickly. See kernel_restart_prepare, kernel_shutdown_prepare. But indeed, it's a good question. We hit many other issues around rebooting. When system is rebooting, user space processes are still running. There is no freeze step. Some processes might jump in to access devices. To avoid it, we have to add some tricks in some device drivers. It's a little crazy. -- 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 0/3] Use PCIe DSN to improve pciehp_resume
On 2013/7/13 18:20, Paul Bolle wrote: > Yijing, > > On Fri, 2013-07-12 at 09:52 +0800, Yijing Wang wrote: >> Do you wireless card support Device Serial Number ? >> You can confirm it by lspci -vvv. > > Yes, it does: > lspci -vvv -s 03:00 | grep Serial > Capabilities: [140 v1] Device Serial Number [...] > OK, I got it, thanks! > > Paul Bolle > > > -- Thanks! Yijing -- 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] wait.c: fix new wake_up_atomic_t kernel-doc warnings
From: Randy Dunlap Fix new kernel-doc warnings in kernel/wait.c: Warning(kernel/wait.c:374): No description found for parameter 'p' Warning(kernel/wait.c:374): Excess function parameter 'word' description in 'wake_up_atomic_t' Warning(kernel/wait.c:374): Excess function parameter 'bit' description in 'wake_up_atomic_t' Signed-off-by: Randy Dunlap Cc: David Howells --- kernel/wait.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- lnx-311-rc1.orig/kernel/wait.c +++ lnx-311-rc1/kernel/wait.c @@ -362,8 +362,7 @@ EXPORT_SYMBOL(out_of_line_wait_on_atomic /** * wake_up_atomic_t - Wake up a waiter on a atomic_t - * @word: The word being waited on, a kernel virtual address - * @bit: The bit of the word being waited on + * @p: The atomic_t being waited on, a kernel virtual address * * Wake up anyone waiting for the atomic_t to go to zero. * -- 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] driver-core: fix new kernel-doc warning in base/platform.c
From: Randy Dunlap Fix new kernel-doc warning in drivers/base/platform.c: Warning(drivers/base/platform.c:528): No description found for parameter 'owner' Signed-off-by: Randy Dunlap --- drivers/base/platform.c |1 + 1 file changed, 1 insertion(+) --- lnx-311-rc1.orig/drivers/base/platform.c +++ lnx-311-rc1/drivers/base/platform.c @@ -522,6 +522,7 @@ static void platform_drv_shutdown(struct /** * __platform_driver_register - register a driver for platform-level devices * @drv: platform driver structure + * @owner: owning module/driver */ int __platform_driver_register(struct platform_driver *drv, struct module *owner) -- 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 v3 01/10] Driver core and sysfs changes for attribute groups
On Mon, Jul 15, 2013 at 10:27:00AM +1000, Stephen Rothwell wrote: > Hi Greg, > > On Sun, 14 Jul 2013 16:05:50 -0700 Greg Kroah-Hartman > wrote: > > > > Anyone else have a better name for this macro: > > #define DEVICE_PATTR(_name) _attr_##_name.attr > > that they can think of? It will cut down on the typing done for > > attribute lists. > > Just one small peeve I have about all these places we do symbol pasting, > is that it makes it impossible to find some things because grep complete > fails us. We type them once (often by cutting and pasting), but try to > find them who knows how many times? > > Just saying ... Yeah, I know. But realize that the dev_attr_##_name variable was originally created with a: DEV_ATTR_RO(sysfs_file_name); macro in the first place, so even trying to grep for dev_attr* brings up nothing. At least this way the grep would find the same thing, so it does make a little bit sense in a way, right? Or am I just trying to justify it as I'm tired of typing all that... 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 v3 01/10] Driver core and sysfs changes for attribute groups
Hi Greg, On Sun, 14 Jul 2013 16:05:50 -0700 Greg Kroah-Hartman wrote: > > Anyone else have a better name for this macro: > #define DEVICE_PATTR(_name) _attr_##_name.attr > that they can think of? It will cut down on the typing done for > attribute lists. Just one small peeve I have about all these places we do symbol pasting, is that it makes it impossible to find some things because grep complete fails us. We type them once (often by cutting and pasting), but try to find them who knows how many times? Just saying ... -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpIUr7mB0b5_.pgp Description: PGP signature
Re: linux-next: rebase of the drivers-x86 tree
Hi Matthew, On Wed, 10 Jul 2013 20:08:39 -0400 Matthew Garrett wrote: > > Because I noticed that one of the patches changed the permissions on a > file to 755 and rewrote it. That is hardly a reason to rebase your tree. Just add another commit to correct the situation. The tree as it stood would not have affected anyone's building, running or bisecting. And why do I now have three versions of your tree? The one in linux-next on Friday, the one in linux-next today, and the one you asked Linus to pull. I hope you don't have any developers trying to develop stuff based on your tree :-( And yes, this is a rhetorical question, just trying to get you to think about your process. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpvSP6q0HbkG.pgp Description: PGP signature
Re: [PATCH] power: Fix comment typo in pm_wakeup.h
On Thursday, July 11, 2013 01:55:58 PM Chanwoo Choi wrote: > This patch fix typo (sorce -> source) > > Signed-off-by: Chanwoo Choi Applied. Thanks, Rafael > --- > include/linux/pm_wakeup.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h > index 569781f..a0f7080 100644 > --- a/include/linux/pm_wakeup.h > +++ b/include/linux/pm_wakeup.h > @@ -36,8 +36,8 @@ > * @last_time: Monotonic clock when the wakeup source's was touched last > time. > * @prevent_sleep_time: Total time this source has been preventing autosleep. > * @event_count: Number of signaled wakeup events. > - * @active_count: Number of times the wakeup sorce was activated. > - * @relax_count: Number of times the wakeup sorce was deactivated. > + * @active_count: Number of times the wakeup source was activated. > + * @relax_count: Number of times the wakeup source was deactivated. > * @expire_count: Number of times the wakeup source's timeout has expired. > * @wakeup_count: Number of times the wakeup source might abort suspend. > * @active: Status of the wakeup source. > -- I speak only for myself. Rafael J. Wysocki, 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] PM: avoid 'autosleep' in shutdown progress
On Friday, July 12, 2013 02:14:11 PM Yanmin Zhang wrote:
> On Thu, 2013-07-11 at 16:03 +0800, shuox@intel.com wrote:
> > From: Liu ShuoX
> >
> > In shutdown progress, system is possible to do power transition
> > (such as suspend-to-ram) in parallel. It is unreasonable. So,
> > fixes it by adding a system_state checking and queue try_to_suspend
> > again when system status is not running.
> >
> > Signed-off-by: Liu ShuoX
> > ---
> > kernel/power/autosleep.c |3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> Without this patch, we hit an hang issue on Android.
>
> Scenario:
> Kernel starts shutdown and calls all device driver's shutdown callback.
> When a driver's shutdown is called, the last wakelock is released and
> suspend-to-ram starts. However, as some driver's shut down callbacks
> already shut down devices and disable runtime pm, the suspend-to-ram
> calls driver's suspend callback without noticing that device is already
> off and causes crash.
OK, queued up as a fix for 3.11, with a modified changelog (I used your
scenario above in it).
Thanks,
Rafael
> We know the drivers should be fixed, but can we also change generic
> codes a little to make it stronger?
>
> > diff --git a/kernel/power/autosleep.c b/kernel/power/autosleep.c
> > index c6422ff..9012ecf 100644
> > --- a/kernel/power/autosleep.c
> > +++ b/kernel/power/autosleep.c
> > @@ -32,7 +32,8 @@ static void try_to_suspend(struct work_struct *work)
> >
> > mutex_lock(_lock);
> >
> > - if (!pm_save_wakeup_count(initial_count)) {
> > + if (!pm_save_wakeup_count(initial_count) ||
> > + system_state != SYSTEM_RUNNING) {
> > mutex_unlock(_lock);
> > goto out;
> > }
>
>
> --
> 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
--
I speak only for myself.
Rafael J. Wysocki, 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] cpufreq: s3c24xx: rename CONFIG_CPU_FREQ_S3C24XX_DEBUGFS
On Sunday, July 14, 2013 08:29:56 PM Paul Bolle wrote:
> The Kconfig symbol CPU_FREQ_S3C24XX_DEBUGFS was renamed to
> ARM_S3C24XX_CPUFREQ_DEBUGFS in commit f023f8dd59 ("cpufreq: s3c24xx:
> move cpufreq driver to drivers/cpufreq"). But that commit missed one
> instance of its macro CONFIG_CPU_FREQ_S3C24XX_DEBUGFS. Rename it too.
>
> Signed-off-by: Paul Bolle
Queued up as a fix for 3.11.
Thanks,
Rafael
> ---
> Untested. Needs compile testing. But please note that setting
> ARM_S3C24XX_CPUFREQ_DEBUGFS should currently lead to compile errors.
>
> drivers/cpufreq/s3c24xx-cpufreq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/s3c24xx-cpufreq.c
> b/drivers/cpufreq/s3c24xx-cpufreq.c
> index 3513e74..87781eb 100644
> --- a/drivers/cpufreq/s3c24xx-cpufreq.c
> +++ b/drivers/cpufreq/s3c24xx-cpufreq.c
> @@ -49,7 +49,7 @@ static struct clk *clk_hclk;
> static struct clk *clk_pclk;
> static struct clk *clk_arm;
>
> -#ifdef CONFIG_CPU_FREQ_S3C24XX_DEBUGFS
> +#ifdef CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS
> struct s3c_cpufreq_config *s3c_cpufreq_getconfig(void)
> {
> return _cur;
> @@ -59,7 +59,7 @@ struct s3c_iotimings *s3c_cpufreq_getiotimings(void)
> {
> return _iotiming;
> }
> -#endif /* CONFIG_CPU_FREQ_S3C24XX_DEBUGFS */
> +#endif /* CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS */
>
> static void s3c_cpufreq_getcur(struct s3c_cpufreq_config *cfg)
> {
>
--
I speak only for myself.
Rafael J. Wysocki, 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/
Oops (NULL ptr deref) while loading some module
Hi all, I'm seeing following oopses when booting up my kernel: [3.173479] BUG: unable to handle kernel NULL pointer dereference at (null) [3.173602] IP: [] futex_wake+0x74/0x130 [3.173679] PGD 231d65067 PUD 231d64067 PMD 0 [3.173783] Oops: [#1] SMP [3.173870] Modules linked in: [3.173936] CPU 0 [3.173959] Pid: 615, comm: modprobe Not tainted 3.9.6-OSS4.2-dirty #34 /DQ45CB [3.174091] RIP: 0010:[] [] futex_wake+0x74/0x130 [3.174195] RSP: 0018:8802311dbda8 EFLAGS: 00010246 [3.174249] RAX: RBX: RCX: 7f125139 [3.174306] RDX: RSI: 3c28288f RDI: 8222ee70 [3.174363] RBP: 8802311dbe08 R08: efa13b63 R09: [3.174420] R10: R11: 0202 R12: 8222ee70 [3.174477] R13: R14: 8222ee78 R15: [3.174535] FS: 7ff44c2a3700() GS:88023bc0() knlGS: [3.174620] CS: 0010 DS: ES: CR0: 80050033 [3.174676] CR2: CR3: 000231d61000 CR4: 000407f0 [3.174734] DR0: DR1: DR2: [3.174791] DR3: DR6: 0ff0 DR7: 0400 [3.174849] Process modprobe (pid: 615, threadinfo 8802311da000, task 880231e272c0) [3.174935] Stack: [3.174984] 880231d62a10 00010001 07f8 7fff78d0a000 [3.175139] 8802311e8000 091c 8802311dbdf8 [3.175293] 0001 7fff78d0a91c 0001 [3.175447] Call Trace: [3.175499] [] do_futex+0x100/0xab0 [3.17] [] ? __do_page_fault+0x244/0x4e0 [3.175611] [] ? mntput+0x21/0x30 [3.175666] [] ? __fput+0x16b/0x240 [3.175721] [] sys_futex+0x88/0x180 [3.175775] [] ? do_page_fault+0x9/0x10 [3.175830] [] system_call_fastpath+0x16/0x1b [3.175886] Code: ff ff 85 c0 41 89 c7 0f 85 b0 00 00 00 48 8d 7d b8 e8 61 f9 ff ff 49 89 c4 48 89 c7 e8 46 0d 8a 00 49 8b 44 24 08 4d 8d 74 24 08 <48> 8b 18 48 8d 78 e8 48 83 eb 18 49 39 c6 75 23 eb 6a 66 2e 0f [3.176678] RIP [] futex_wake+0x74/0x130 [3.176678] RSP [3.176678] CR2: [3.177366] ---[ end trace 7213d911e494c10b ]--- [3.177823] BUG: unable to handle kernel NULL pointer dereference at (null) [3.177944] IP: [] futex_wake+0x74/0x130 [3.178017] PGD 2311f4067 PUD 2311f5067 PMD 0 [3.178122] Oops: [#2] SMP [3.178207] Modules linked in: [3.178274] CPU 0 [3.178296] Pid: 617, comm: modprobe Tainted: G D 3.9.6-OSS4.2-dirty #34 /DQ45CB [3.178428] RIP: 0010:[] [] futex_wake+0x74/0x130 [3.178531] RSP: 0018:880231213da8 EFLAGS: 00010246 [3.178585] RAX: RBX: RCX: 006a3b48 [3.178643] RDX: RSI: 1d796f0a RDI: 8222ec60 [3.178700] RBP: 880231213e08 R08: cbc14f19 R09: [3.178758] R10: R11: 0202 R12: 8222ec60 [3.178816] R13: R14: 8222ec68 R15: [3.178873] FS: 7f5baf639700() GS:88023bc0() knlGS: [3.178958] CS: 0010 DS: ES: CR0: 80050033 [3.179013] CR2: CR3: 0002311f7000 CR4: 000407f0 [3.179071] DR0: DR1: DR2: [3.179128] DR3: DR6: 0ff0 DR7: 0400 [3.179185] Process modprobe (pid: 617, threadinfo 880231212000, task 880231e26540) [3.179270] Stack: [3.179318] 8802311f3a10 00010001 07f0 7fff80ed6000 [3.179472] 8802311e8340 082c 880231213df8 [3.179626] 0001 7fff80ed682c 0001 [3.179780] Call Trace: [3.179829] [] do_futex+0x100/0xab0 [3.179884] [] ? __do_page_fault+0x244/0x4e0 [3.179940] [] ? mntput+0x21/0x30 [3.179994] [] ? __fput+0x16b/0x240 [3.180071] [] sys_futex+0x88/0x180 [3.180126] [] ? do_page_fault+0x9/0x10 [3.180183] [] system_call_fastpath+0x16/0x1b [3.180238] Code: ff ff 85 c0 41 89 c7 0f 85 b0 00 00 00 48 8d 7d b8 e8 61 f9 ff ff 49 89 c4 48 89 c7 e8 46 0d 8a 00 49 8b 44 24 08 4d 8d 74 24 08 <48> 8b 18 48 8d 78 e8 48 83 eb 18 49 39 c6 75 23 eb 6a 66 2e 0f [3.180892] RIP [] futex_wake+0x74/0x130 [3.180892] RSP [3.180892] CR2: [3.181699] ---[ end trace 7213d911e494c10c ]--- This is obviously happening while booting and udev is loading *some* module, but I have no idea which module is affected as such. Luckily, my module list is quite concise: Module
Re: [RFC][PATCH] mm: madvise: MADV_POPULATE for quick pre-faulting
On Sun, Jul 14, 2013 at 11:12:58AM +0800, Sam Ben wrote: > On 07/02/2013 10:37 AM, Zheng Liu wrote: > >On Mon, Jul 01, 2013 at 09:16:46AM -0700, Dave Hansen wrote: > >>On 06/28/2013 07:20 PM, Zheng Liu wrote: > >IOW, a process needing to do a bunch of MAP_POPULATEs isn't > >parallelizable, but one using this mechanism would be. > >>>I look at the code, and it seems that we will handle MAP_POPULATE flag > >>>after we release mmap_sem locking in vm_mmap_pgoff(): > >>> > >>> down_write(>mmap_sem); > >>> ret = do_mmap_pgoff(file, addr, len, prot, flag, pgoff, > >>> ); > >>> up_write(>mmap_sem); > >>> if (populate) > >>> mm_populate(ret, populate); > >>> > >>>Am I missing something? > >>I went and did my same test using mmap(MAP_POPULATE)/munmap() pair > >>versus using MADV_POPULATE in 160 threads in parallel. > >> > >>MADV_POPULATE was about 10x faster in the threaded configuration. > >> > >>With MADV_POPULATE, the biggest cost is shipping the mmap_sem cacheline > >>around so that we can write the reader count update in to it. With > >>mmap(), there is a lot of _contention_ on that lock which is much, much > >>more expensive than simply bouncing a cacheline around. > >Thanks for your explanation. > > > >FWIW, it would be great if we can let MAP_POPULATE flag support shared > >mappings because in our product system there has a lot of applications > >that uses mmap(2) and then pre-faults this mapping. Currently these > >applications need to pre-fault the mapping manually. > > How do you pre-fault the mapping manually in your product system? By > walking through the file touching each page? Yes, in our product system most applications do like this. Regards, - Zheng -- 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 3.11-rc1
It's been two weeks, and the merge window has closed. If I missed anything, holler, but I don't have anything pending that I am aware of. This merge window was smaller in terms of number of commits than the 3.10 merge window, but we actually have more new lines. Most of that seems to be in staging - a full third of all changes by line-count is staging, and merging in Lustre is the bulk of that. Let's see how that all turns out, I have to say that we don't have a great track record on merging filesystems through staging. Ignoring the lustre merge, I think this really was a somewhat calmer merge window. We had a few trees with problems, and we have an on-going debate about stable patches that was triggered largely thanks to this merge window, so now we'll have something to discuss for the kernel summit. But on the whole, I suspect we might be starting to see the traditional summer slump (Australia notwithstanding). Despite being a bit smaller than the last merge window, it's not like this was a _tiny_ one, and so as usual I'm only summarizing with the normal -rc1 mergelog: and as usual the people credited here are *not* the people who actually wrote the code (although in some cases that is true), they are the people who I merged the code from. Hey, let's all start testing, Linus --- Al Viro: (4) VFS patches (part 1) second set of VFS changes third set of VFS updates more vfs stuff Alasdair G Kergon: (1) device-mapper changes Alex Williamson: (1) vfio updates Andrew Morton: (3) first patch-bomb second patch-bomb more patches Anton Vorontsov: (1) battery subsystem update Arnd Bergmann: (7) ARM SoC non-cricitical bug fixes ARM SoC cleanups ARM SoC specific changes ARM SoC board specific changes ARM SoC device tree changes ARM SoC driver specific changes ARM SoC late changes Artem Bityutskiy: (2) ubifs fix ubi fixes Ben Herrenschmidt: (1) powerpc updates Ben Myers: (2) xfs update more xfs updates Bjorn Helgaas: (1) PCI changes Borislav Petkov: (1) AMD EDAC update Bruce Fields: (1) nfsd changes Bryan Wu: (1) LED subsystem updates Catalin Marinas: (1) ARM64 updates Chris Ball: (1) MMC updates Chris Mason: (1) btrfs update Chris Zankel: (1) Xtensa updates Dave Airlie: (1) drm updates Dave Hansen: (2) branch 'kconfig-diet' Kconfig menu diet patches Dave Kleikamp: (1) jfs update David Howells: (1) FS-Cache updates David Miller: (4) networking updates IDE updates Sparc bugfixes networking fixes David Teigland: (1) dlm updates Dmitry Torokhov: (2) input updates second round of input updates Eric Van Hensbergen: (2) 9p update second round of 9p patches Geert Uytterhoeven: (2) m68k updates "exotic" arch fixes Gleb Natapov: (1) more KVM changes Grant Likely: (2) device tree updates irqdomain refactoring Greg KH: (5) USB updates tty/serial updates staging tree update char/misc updates driver core updates Guenter Roeck: (1) hwmon updates Helge Deller: (1) parisc updates Herbert Xu: (1) crypto update Ingo Molnar: (22) locking changes WW mutex support RCU updates core irq changes perf updates scheduler updates voluntary preemption fixes asm/x86 changes x86 boot build fix x86 cleanups x86 cpu updates x86 debug update x86 EFI changes x86 FPU changes x86 microcode loading update x86 mm changes x86 platform updates x86 RAS update x86 tracing updates x86 UV update x86 fix perf fixes Jaegeuk Kim: (1) f2fs updates James Bottomley: (2) first round of SCSI updates final round of SCSI updates James Hogan: (2) Metag architecture changes arch/metag fixes James Morris: (1) security subsystem updates Jan Kara: (1) ext3 fix and quota cleanup Jean Delvare: (1) hwmon update Jean-Christophe PLAGNIOL-VILLARD: (1) fbdev update Jens Axboe: (1) core block IO updates Jiri Kosina: (2) HID updates trivial tree updates Joerg Roedel: (1) IOMMU updates Konrad Rzeszutek Wilk: (1) Xen bugfixes Linus Walleij: (2) GPIO updates pin control changes Marek Szyprowski: (1) ARM DMA mapping updates Mark Brown: (4) regmap updates spi updates regulator updates regulator fixes Martin Schwidefsky: (1) s390 updates Matthew Garrett: (1) x86 platform driver updates Mauro Carvalho Chehab: (1)
Re: [ 00/19] 3.10.1-stable review
On Fri, 2013-07-12 at 10:50 -0700, Linus Torvalds wrote: > You cut out the important part: > > - It must fix a problem that causes a build error (but not for things >marked CONFIG_BROKEN), an oops, a hang, data corruption, a real >security issue, or some "oh, that's not good" issue. In short, something >critical. > > That list is not a "or" list, it's an "and" list - it needs to follow > *all* the rules. The exception is the "New device IDs and quirks are > also accepted", which maybe should be made more clearly separate. So if I read this (and stable_kernel_rules.txt) correctly, that means that for example, let's say, we find in RHEL66 or SLES42 (possibly following a user report), for example, that PCI hotplug is broken with some category of devices on some machines. We do a fix, it's roughtly 4 or 5 lines, pretty self contained. We get it into the distro. That still doesn't qualify for stable right ? We have to start shooting at every distro around separately or wait for users of those other distros to also hit it ? Where is the line when something "Doesn't work" (without crashing/oops'ing or being a security issue) ? My personal line so far has been to take it and send it to -stable if the patch is simple enough and self contained (little risk of side effects). But I can stop if that's indeed the accepted rule. Cheers, Ben. -- 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] sysfs: add support for binary attributes in groups
groups should be able to support binary attributes, just like it
supports "normal" attributes. This lets us only handle one type of
structure, groups, throughout the driver core and subsystems, making
binary attributes a "full fledged" part of the driver model, and not
something just "tacked on".
Reported-by: Oliver Schinagl
Reviewed-by: Guenter Roeck
Tested-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
---
fs/sysfs/group.c | 66 +++
include/linux/sysfs.h | 4 ++--
2 files changed, 48 insertions(+), 22 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index aec3d5c9..e5719c60 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -20,38 +20,64 @@ static void remove_files(struct sysfs_dirent *dir_sd,
struct kobject *kobj,
const struct attribute_group *grp)
{
struct attribute *const* attr;
- int i;
+ struct bin_attribute *const* bin_attr;
- for (i = 0, attr = grp->attrs; *attr; i++, attr++)
- sysfs_hash_and_remove(dir_sd, NULL, (*attr)->name);
+ if (grp->attrs)
+ for (attr = grp->attrs; *attr; attr++)
+ sysfs_hash_and_remove(dir_sd, NULL, (*attr)->name);
+ if (grp->bin_attrs)
+ for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++)
+ sysfs_remove_bin_file(kobj, *bin_attr);
}
static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
const struct attribute_group *grp, int update)
{
struct attribute *const* attr;
+ struct bin_attribute *const* bin_attr;
int error = 0, i;
- for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
- umode_t mode = 0;
+ if (grp->attrs) {
+ for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
+ umode_t mode = 0;
+
+ /*
+* In update mode, we're changing the permissions or
+* visibility. Do this by first removing then
+* re-adding (if required) the file.
+*/
+ if (update)
+ sysfs_hash_and_remove(dir_sd, NULL,
+ (*attr)->name);
+ if (grp->is_visible) {
+ mode = grp->is_visible(kobj, *attr, i);
+ if (!mode)
+ continue;
+ }
+ error = sysfs_add_file_mode(dir_sd, *attr,
+ SYSFS_KOBJ_ATTR,
+ (*attr)->mode | mode);
+ if (unlikely(error))
+ break;
+ }
+ if (error) {
+ remove_files(dir_sd, kobj, grp);
+ goto exit;
+ }
+ }
- /* in update mode, we're changing the permissions or
-* visibility. Do this by first removing then
-* re-adding (if required) the file */
- if (update)
- sysfs_hash_and_remove(dir_sd, NULL, (*attr)->name);
- if (grp->is_visible) {
- mode = grp->is_visible(kobj, *attr, i);
- if (!mode)
- continue;
+ if (grp->bin_attrs) {
+ for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++) {
+ if (update)
+ sysfs_remove_bin_file(kobj, *bin_attr);
+ error = sysfs_create_bin_file(kobj, *bin_attr);
+ if (error)
+ break;
}
- error = sysfs_add_file_mode(dir_sd, *attr, SYSFS_KOBJ_ATTR,
- (*attr)->mode | mode);
- if (unlikely(error))
- break;
+ if (error)
+ remove_files(dir_sd, kobj, grp);
}
- if (error)
- remove_files(dir_sd, kobj, grp);
+exit:
return error;
}
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index d50a96b9..2c3b6a30 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -21,6 +21,7 @@
struct kobject;
struct module;
+struct bin_attribute;
enum kobj_ns_type;
struct attribute {
@@ -59,10 +60,9 @@ struct attribute_group {
umode_t (*is_visible)(struct kobject *,
struct attribute *, int);
struct attribute**attrs;
+ struct bin_attribute**bin_attrs;
};
-
-
/**
* Use these macros to make defining attributes easier. See
include/linux/device.h
* for examples..
--
Re: [PATCH v2 2/7] sysfs.h: add ATTRIBUTE_GROUPS() macro
On Mon, Jul 15, 2013 at 12:55:22AM +0200, Oliver Schinagl wrote: > Greg, > > Haven't heard anything about this v2 patch, I know you are very busy > but with the merge window closing today/yesterday just wondering > about the status of it all. Just refreshed them against 3.11-rc1 and sent them out a mere seconds ago :) thanks, 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/
[PATCH 03/10] sysfs.h: add BIN_ATTR macro
This makes it easier to create static binary attributes, which is needed
in a number of drivers, instead of "open coding" them.
Reviewed-by: Guenter Roeck
Tested-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
---
include/linux/sysfs.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index f62ff01e..d50a96b9 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -132,6 +132,15 @@ struct bin_attribute {
*/
#define sysfs_bin_attr_init(bin_attr) sysfs_attr_init(&(bin_attr)->attr)
+/* macro to create static binary attributes easier */
+#define BIN_ATTR(_name, _mode, _read, _write, _size) \
+struct bin_attribute bin_attr_##_name = { \
+ .attr = {.name = __stringify(_name), .mode = _mode }, \
+ .read = _read,\
+ .write = _write, \
+ .size = _size,\
+}
+
struct sysfs_ops {
ssize_t (*show)(struct kobject *, struct attribute *,char *);
ssize_t (*store)(struct kobject *,struct attribute *,const char *,
size_t);
--
1.8.3.rc0.20.gb99dd2e
--
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] driver core: device.h: add RW and RO attribute macros
Make it easier to create attributes without having to always audit the
mode settings.
Reviewed-by: Guenter Roeck
Tested-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
---
include/linux/device.h | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index bcf8c0d4..f207a8f4 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -47,7 +47,11 @@ struct bus_attribute {
};
#define BUS_ATTR(_name, _mode, _show, _store) \
-struct bus_attribute bus_attr_##_name = __ATTR(_name, _mode, _show, _store)
+ struct bus_attribute bus_attr_##_name = __ATTR(_name, _mode, _show,
_store)
+#define BUS_ATTR_RW(_name) \
+ struct bus_attribute bus_attr_##_name = __ATTR_RW(_name)
+#define BUS_ATTR_RO(_name) \
+ struct bus_attribute bus_attr_##_name = __ATTR_RO(_name)
extern int __must_check bus_create_file(struct bus_type *,
struct bus_attribute *);
@@ -261,9 +265,12 @@ struct driver_attribute {
size_t count);
};
-#define DRIVER_ATTR(_name, _mode, _show, _store) \
-struct driver_attribute driver_attr_##_name = \
- __ATTR(_name, _mode, _show, _store)
+#define DRIVER_ATTR(_name, _mode, _show, _store) \
+ struct driver_attribute driver_attr_##_name = __ATTR(_name, _mode,
_show, _store)
+#define DRIVER_ATTR_RW(_name) \
+ struct driver_attribute driver_attr_##_name = __ATTR_RW(_name)
+#define DRIVER_ATTR_RO(_name) \
+ struct driver_attribute driver_attr_##_name = __ATTR_RO(_name)
extern int __must_check driver_create_file(struct device_driver *driver,
const struct driver_attribute *attr);
@@ -414,8 +421,12 @@ struct class_attribute {
const struct class_attribute *attr);
};
-#define CLASS_ATTR(_name, _mode, _show, _store)\
-struct class_attribute class_attr_##_name = __ATTR(_name, _mode, _show, _store)
+#define CLASS_ATTR(_name, _mode, _show, _store) \
+ struct class_attribute class_attr_##_name = __ATTR(_name, _mode, _show,
_store)
+#define CLASS_ATTR_RW(_name) \
+ struct class_attribute class_attr_##_name = __ATTR_RW(_name)
+#define CLASS_ATTR_RO(_name) \
+ struct class_attribute class_attr_##_name = __ATTR_RO(_name)
extern int __must_check class_create_file(struct class *class,
const struct class_attribute *attr);
@@ -423,7 +434,6 @@ extern void class_remove_file(struct class *class,
const struct class_attribute *attr);
/* Simple class attribute that is just a static string */
-
struct class_attribute_string {
struct class_attribute attr;
char *str;
@@ -512,6 +522,10 @@ ssize_t device_store_bool(struct device *dev, struct
device_attribute *attr,
#define DEVICE_ATTR(_name, _mode, _show, _store) \
struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show,
_store)
+#define DEVICE_ATTR_RW(_name) \
+ struct device_attribute dev_attr_##_name = __ATTR_RW(_name)
+#define DEVICE_ATTR_RO(_name) \
+ struct device_attribute dev_attr_##_name = __ATTR_RO(_name)
#define DEVICE_ULONG_ATTR(_name, _mode, _var) \
struct dev_ext_attribute dev_attr_##_name = \
{ __ATTR(_name, _mode, device_show_ulong, device_store_ulong),
&(_var) }
--
1.8.3.rc0.20.gb99dd2e
--
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 08/10] driver core: add default groups to struct class
We should be using groups, not attribute lists, for classes to allow
subdirectories, and soon, binary files. Groups are just more flexible
overall, so add them.
The dev_attrs list will go away after all in-kernel users are converted
to use dev_groups.
Reviewed-by: Guenter Roeck
Tested-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/core.c| 9 -
include/linux/device.h | 4 +++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index a8aae182..8856d745 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -528,9 +528,12 @@ static int device_add_attrs(struct device *dev)
int error;
if (class) {
- error = device_add_attributes(dev, class->dev_attrs);
+ error = device_add_groups(dev, class->dev_groups);
if (error)
return error;
+ error = device_add_attributes(dev, class->dev_attrs);
+ if (error)
+ goto err_remove_class_groups;
error = device_add_bin_attributes(dev, class->dev_bin_attrs);
if (error)
goto err_remove_class_attrs;
@@ -563,6 +566,9 @@ static int device_add_attrs(struct device *dev)
err_remove_class_attrs:
if (class)
device_remove_attributes(dev, class->dev_attrs);
+ err_remove_class_groups:
+ if (class)
+ device_remove_groups(dev, class->dev_groups);
return error;
}
@@ -581,6 +587,7 @@ static void device_remove_attrs(struct device *dev)
if (class) {
device_remove_attributes(dev, class->dev_attrs);
device_remove_bin_attributes(dev, class->dev_bin_attrs);
+ device_remove_groups(dev, class->dev_groups);
}
}
diff --git a/include/linux/device.h b/include/linux/device.h
index bd5931e8..22b546a5 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -320,6 +320,7 @@ int subsys_virtual_register(struct bus_type *subsys,
* @name: Name of the class.
* @owner: The module owner.
* @class_attrs: Default attributes of this class.
+ * @dev_groups:Default attributes of the devices that belong to the
class.
* @dev_attrs: Default attributes of the devices belong to the class.
* @dev_bin_attrs: Default binary attributes of the devices belong to the
class.
* @dev_kobj: The kobject that represents this class and links it into the
hierarchy.
@@ -349,7 +350,8 @@ struct class {
struct module *owner;
struct class_attribute *class_attrs;
- struct device_attribute *dev_attrs;
+ struct device_attribute *dev_attrs; /* use dev_groups
instead */
+ const struct attribute_group**dev_groups;
struct bin_attribute*dev_bin_attrs;
struct kobject *dev_kobj;
--
1.8.3.rc0.20.gb99dd2e
--
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] driver core: Introduce device_create_groups
From: Guenter Roeck
device_create_groups lets callers create devices as well as associated
sysfs attributes with a single call. This avoids race conditions seen
if sysfs attributes on new devices are created later.
[fixed up comment block placement and add checks for printk buffer
formats - gregkh]
Signed-off-by: Guenter Roeck
Cc: Jean Delvare
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/core.c| 111 -
include/linux/device.h | 5 +++
2 files changed, 88 insertions(+), 28 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index dc3ea237..a8aae182 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1667,34 +1667,11 @@ static void device_create_release(struct device *dev)
kfree(dev);
}
-/**
- * device_create_vargs - creates a device and registers it with sysfs
- * @class: pointer to the struct class that this device should be registered to
- * @parent: pointer to the parent struct device of this new device, if any
- * @devt: the dev_t for the char device to be added
- * @drvdata: the data to be added to the device for callbacks
- * @fmt: string for the device's name
- * @args: va_list for the device's name
- *
- * This function can be used by char device classes. A struct device
- * will be created in sysfs, registered to the specified class.
- *
- * A "dev" file will be created, showing the dev_t for the device, if
- * the dev_t is not 0,0.
- * If a pointer to a parent struct device is passed in, the newly created
- * struct device will be a child of that device in sysfs.
- * The pointer to the struct device will be returned from the call.
- * Any further sysfs files that might be required can be created using this
- * pointer.
- *
- * Returns device pointer on success, or ERR_PTR() on error.
- *
- * Note: the struct class passed to this function must have previously
- * been created with a call to class_create().
- */
-struct device *device_create_vargs(struct class *class, struct device *parent,
- dev_t devt, void *drvdata, const char *fmt,
- va_list args)
+static struct device *
+device_create_groups_vargs(struct class *class, struct device *parent,
+ dev_t devt, void *drvdata,
+ const struct attribute_group **groups,
+ const char *fmt, va_list args)
{
struct device *dev = NULL;
int retval = -ENODEV;
@@ -1711,6 +1688,7 @@ struct device *device_create_vargs(struct class *class,
struct device *parent,
dev->devt = devt;
dev->class = class;
dev->parent = parent;
+ dev->groups = groups;
dev->release = device_create_release;
dev_set_drvdata(dev, drvdata);
@@ -1728,6 +1706,39 @@ error:
put_device(dev);
return ERR_PTR(retval);
}
+
+/**
+ * device_create_vargs - creates a device and registers it with sysfs
+ * @class: pointer to the struct class that this device should be registered to
+ * @parent: pointer to the parent struct device of this new device, if any
+ * @devt: the dev_t for the char device to be added
+ * @drvdata: the data to be added to the device for callbacks
+ * @fmt: string for the device's name
+ * @args: va_list for the device's name
+ *
+ * This function can be used by char device classes. A struct device
+ * will be created in sysfs, registered to the specified class.
+ *
+ * A "dev" file will be created, showing the dev_t for the device, if
+ * the dev_t is not 0,0.
+ * If a pointer to a parent struct device is passed in, the newly created
+ * struct device will be a child of that device in sysfs.
+ * The pointer to the struct device will be returned from the call.
+ * Any further sysfs files that might be required can be created using this
+ * pointer.
+ *
+ * Returns device pointer on success, or ERR_PTR() on error.
+ *
+ * Note: the struct class passed to this function must have previously
+ * been created with a call to class_create().
+ */
+struct device *device_create_vargs(struct class *class, struct device *parent,
+ dev_t devt, void *drvdata, const char *fmt,
+ va_list args)
+{
+ return device_create_groups_vargs(class, parent, devt, drvdata, NULL,
+ fmt, args);
+}
EXPORT_SYMBOL_GPL(device_create_vargs);
/**
@@ -1767,6 +1778,50 @@ struct device *device_create(struct class *class, struct
device *parent,
}
EXPORT_SYMBOL_GPL(device_create);
+/**
+ * device_create_with_groups - creates a device and registers it with sysfs
+ * @class: pointer to the struct class that this device should be registered to
+ * @parent: pointer to the parent struct device of this new device, if any
+ * @devt: the dev_t for the char device to be added
+ * @drvdata: the data to be added to the device for callbacks
+ * @groups: NULL-terminated list of attribute
[PATCH 06/10] sysfs: prevent warning when only using binary attributes
From: Oliver Schinagl
When only using bin_attrs instead of attrs the kernel prints a warning
and refuses to create the sysfs entry. This fixes that.
Signed-off-by: Oliver Schinagl
Signed-off-by: Greg Kroah-Hartman
---
fs/sysfs/group.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index e5719c60..09a1a25c 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -93,8 +93,8 @@ static int internal_create_group(struct kobject *kobj, int
update,
/* Updates may happen before the object has been instantiated */
if (unlikely(update && !kobj->sd))
return -EINVAL;
- if (!grp->attrs) {
- WARN(1, "sysfs: attrs not set by subsystem for group: %s/%s\n",
+ if (!grp->attrs && !grp->bin_attrs) {
+ WARN(1, "sysfs: (bin_)attrs not set by subsystem for group:
%s/%s\n",
kobj->name, grp->name ? "" : grp->name);
return -EINVAL;
}
--
1.8.3.rc0.20.gb99dd2e
--
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: [ 00/19] 3.10.1-stable review
On Thu, 2013-07-11 at 15:01 -0700, Greg Kroah-Hartman wrote: > s is the start of the stable review cycle for the 3.10.1 release. > There are 19 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 Sat Jul 13 21:45:35 UTC 2013. > Anything received after that time might be too late. And you expect that we all have time to dig that out from lkml in 1 day ? You have a rant about powerpc and don't CC me ? :-) This one is really important/urgent: 74251fe21bfa9310ddba9e0436d1fcf389e602ee "powerpc/powernv: Fix iommu initialization again" Cheers, Ben. -- 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] sysfs: use file mode defines from stat.h
From: Oliver Schinagl
With the last patches stat.h was included to the header, and thus those
permission defines should be used.
Signed-off-by: Oliver Schinagl
Signed-off-by: Greg Kroah-Hartman
---
include/linux/sysfs.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index d907a732..9e8a9b55 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -69,18 +69,19 @@ struct attribute_group {
* for examples..
*/
-#define __ATTR(_name,_mode,_show,_store) { \
- .attr = {.name = __stringify(_name), .mode = _mode }, \
- .show = _show,\
- .store = _store, \
+#define __ATTR(_name,_mode,_show,_store) { \
+ .attr = {.name = __stringify(_name), .mode = _mode }, \
+ .show = _show,\
+ .store = _store, \
}
-#define __ATTR_RO(_name) { \
- .attr = { .name = __stringify(_name), .mode = 0444 }, \
- .show = _name##_show, \
+#define __ATTR_RO(_name) { \
+ .attr = { .name = __stringify(_name), .mode = S_IRUGO }, \
+ .show = _name##_show, \
}
-#define __ATTR_RW(_name) __ATTR(_name, 0644, _name##_show, _name##_store)
+#define __ATTR_RW(_name) __ATTR(_name, (S_IWUSR | S_IRUGO),\
+_name##_show, _name##_store)
#define __ATTR_NULL { .attr = { .name = NULL } }
--
1.8.3.rc0.20.gb99dd2e
--
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 01/10] Driver core and sysfs changes for attribute groups
Hi all, Here is the third iteration of the patchset to add better attribute group support to the driver core and sysfs. Others have now tested it, and we got 3 more patches fixing a warning that was showing up when binary attributes were in a group with no "normal" attributes, and some more helper macros were added and cleaned up. I've booted this successfully against 3.11-rc1 with no problems (am sending these from that machine.) Ian, I didn't add a DEVICE_PATTR() macro yet, that can come later. I considered it, but that would also mean a BUS_PATTR() and the like, which I guess works, but I hate even a _hint_ of "Hungarian" notation, which this implies. Anyone else have a better name for this macro: #define DEVICE_PATTR(_name) _attr_##_name.attr that they can think of? It will cut down on the typing done for attribute lists. changes from v3: - tested by Guenter - patches from Oliver added - refreshed on 3.11-rc1 (minor fuzz) - Ian glanced at them. changes from v2: - actually boots - 7th patch added properly - added BUS_ATTR, CLASS_ATTR, and DRIVER_ATTR RW and RO macros to help with converting code to use attributes properly. thanks, 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/
[PATCH 01/10] sysfs.h: add __ATTR_RW() macro
A number of parts of the kernel created their own version of this, might
as well have the sysfs core provide it instead.
Reviewed-by: Guenter Roeck
Tested-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
---
include/linux/sysfs.h | 2 ++
kernel/events/core.c | 2 --
mm/backing-dev.c | 2 --
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index e2cee22f..9cd20c84 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -79,6 +79,8 @@ struct attribute_group {
.show = _name##_show, \
}
+#define __ATTR_RW(_name) __ATTR(_name, 0644, _name##_show, _name##_store)
+
#define __ATTR_NULL { .attr = { .name = NULL } }
#ifdef CONFIG_DEBUG_LOCK_ALLOC
diff --git a/kernel/events/core.c b/kernel/events/core.c
index eba8fb58..dd987802 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6234,8 +6234,6 @@ perf_event_mux_interval_ms_store(struct device *dev,
return count;
}
-#define __ATTR_RW(attr) __ATTR(attr, 0644, attr##_show, attr##_store)
-
static struct device_attribute pmu_dev_attrs[] = {
__ATTR_RO(type),
__ATTR_RW(perf_event_mux_interval_ms),
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index d014ee5f..e04454cd 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -232,8 +232,6 @@ static ssize_t stable_pages_required_show(struct device
*dev,
bdi_cap_stable_pages_required(bdi) ? 1 : 0);
}
-#define __ATTR_RW(attr) __ATTR(attr, 0644, attr##_show, attr##_store)
-
static struct device_attribute bdi_dev_attrs[] = {
__ATTR_RW(read_ahead_kb),
__ATTR_RW(min_ratio),
--
1.8.3.rc0.20.gb99dd2e
--
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 09/10] sysfs: add more helper macro's for (bin_)attribute(_groups)
From: Oliver Schinagl
With the recent changes to sysfs there's various helper macro's.
However there's no RW, RO BIN_ helper macro's. This patch adds them.
Signed-off-by: Oliver Schinagl
Signed-off-by: Greg Kroah-Hartman
---
include/linux/sysfs.h | 51 ++-
1 file changed, 38 insertions(+), 13 deletions(-)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 2c3b6a30..d907a732 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
struct kobject;
@@ -94,15 +95,18 @@ struct attribute_group {
#define __ATTR_IGNORE_LOCKDEP __ATTR
#endif
-#define ATTRIBUTE_GROUPS(name) \
-static const struct attribute_group name##_group = { \
- .attrs = name##_attrs, \
-}; \
-static const struct attribute_group *name##_groups[] = { \
- ##_group, \
+#define __ATTRIBUTE_GROUPS(_name) \
+static const struct attribute_group *_name##_groups[] = { \
+ &_name##_group, \
NULL, \
}
+#define ATTRIBUTE_GROUPS(_name)\
+static const struct attribute_group _name##_group = { \
+ .attrs = _name##_attrs, \
+}; \
+__ATTRIBUTE_GROUPS(_name)
+
#define attr_name(_attr) (_attr).attr.name
struct file;
@@ -132,15 +136,36 @@ struct bin_attribute {
*/
#define sysfs_bin_attr_init(bin_attr) sysfs_attr_init(&(bin_attr)->attr)
-/* macro to create static binary attributes easier */
-#define BIN_ATTR(_name, _mode, _read, _write, _size) \
-struct bin_attribute bin_attr_##_name = { \
- .attr = {.name = __stringify(_name), .mode = _mode }, \
- .read = _read,\
- .write = _write, \
- .size = _size,\
+/* macros to create static binary attributes easier */
+#define __BIN_ATTR(_name, _mode, _read, _write, _size) { \
+ .attr = { .name = __stringify(_name), .mode = _mode }, \
+ .read = _read,\
+ .write = _write, \
+ .size = _size,\
+}
+
+#define __BIN_ATTR_RO(_name, _size) { \
+ .attr = { .name = __stringify(_name), .mode = S_IRUGO }, \
+ .read = _name##_read, \
+ .size = _size,\
}
+#define __BIN_ATTR_RW(_name, _size) __BIN_ATTR(_name, \
+ (S_IWUSR | S_IRUGO), _name##_read, \
+ _name##_write)
+
+#define __BIN_ATTR_NULL __ATTR_NULL
+
+#define BIN_ATTR(_name, _mode, _read, _write, _size) \
+struct bin_attribute bin_attr_##_name = __BIN_ATTR(_name, _mode, _read,
\
+ _write, _size)
+
+#define BIN_ATTR_RO(_name, _size) \
+struct bin_attribute bin_attr_##_name = __BIN_ATTR_RO(_name, _size)
+
+#define BIN_ATTR_RW(_name, _size) \
+struct bin_attribute bin_attr_##_name = __BIN_ATTR_RW(_name, _size)
+
struct sysfs_ops {
ssize_t (*show)(struct kobject *, struct attribute *,char *);
ssize_t (*store)(struct kobject *,struct attribute *,const char *,
size_t);
--
1.8.3.rc0.20.gb99dd2e
--
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 02/10] sysfs.h: add ATTRIBUTE_GROUPS() macro
To make it easier for driver subsystems to work with attribute groups,
create the ATTRIBUTE_GROUPS macro to remove some of the repetitive
typing for the most common use for attribute groups.
Reviewed-by: Guenter Roeck
Tested-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
---
include/linux/sysfs.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 9cd20c84..f62ff01e 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -94,6 +94,15 @@ struct attribute_group {
#define __ATTR_IGNORE_LOCKDEP __ATTR
#endif
+#define ATTRIBUTE_GROUPS(name) \
+static const struct attribute_group name##_group = { \
+ .attrs = name##_attrs, \
+}; \
+static const struct attribute_group *name##_groups[] = { \
+ ##_group, \
+ NULL, \
+}
+
#define attr_name(_attr) (_attr).attr.name
struct file;
--
1.8.3.rc0.20.gb99dd2e
--
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: [ 00/19] 3.10.1-stable review
On Thu, 2013-07-11 at 15:44 -0700, Greg Kroah-Hartman wrote: > > And the later in -rc we are, the more reluctant some people seem to be > > at sending stuff. Which, for slowing things down as we go through -rc is > > great, > > but not so much when people stop sending _everything_ and start thinking > > "I'll just get it in stable in a few weeks". > > The 20 powerpc patches are proof of that. I'm amost considering just > not applying them at all, as obviously they weren't all that important. Can you stop about powerpc for a minute Greg ? It's becoming tiring When it's not this (seriously ? We are by FAR not the worst managed architecture around here but you seem to pick on any opportunity, public medium, etc... to trash us for whatever reason, time to find another axe to grind really). Also look at the damn history. We rarely had that much stuff going back. You know 3.10 is special and you probably know why, and I've mentioned already that a lot of that stuff you are complaining about affects HW that people do NOT have presently access to outside of IBM. Please, go play another violin. Ben. -- 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: [ 00/19] 3.10.1-stable review
On Thu, 2013-07-11 at 18:14 -0400, Josh Boyer wrote: >Why are subsystem maintainers holding on to fixes that are > > _supposedly_ affecting all users? I mean, 21 powerpc core changes > > that I don't see until a -rc1 merge? It's as if developers don't > > expect people to use a .0 release and are relying on me to get the > > fixes they have burried in their trees out to users. Let me guess, a lot of these are Power8 fixes ... This is a bit special this time around... we introduced some of the support in 3.9 and added a bunch in 3.10. We found bugs, it's brand new HW (not even final yet), and nobody out there has access to it nor will for a little while longer, so indeed nobody is going to use 3.10.0. I've been pushing back on a lot of it as a maintainer (which is why a lot of stuff ended up in 3.10 instead of 3.9), but granted probably not enough this time around. It's hard because the guys are getting a LOT of pressure in part because of distro schedules. As you are aware (and I mentioned in another email), some enterprise distros impose a very specific schedule for stuff to go upstream, and if that misses, well you are out of the game for years or lots of $ to convince them otherwise. Additionally, one of them has brain damaged rules about preserving kernel ABIs which prevents any significant addition for the entire lifetime of the distro major release. This is bad, this should not affect upstream in theory, but in practice it does because if we don't get into the damn enterprise distro, the whole exercise is pointless to begin with and we may as well not release the machines and stop the Linux business altogether. So I make compromises. I delay some stuff because it's really not ready, and I take some because it affects things like thread_struct layout which I know *WILL* break kABI and will be VERY hard to get back to the distro later, fully expecting that various bits of fixes are going to eventually trickle later on until it's ready for public consumption. Ben. -- 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/7] sysfs.h: add ATTRIBUTE_GROUPS() macro
Greg,
Haven't heard anything about this v2 patch, I know you are very busy but
with the merge window closing today/yesterday just wondering about the
status of it all.
Oliver
On 11-07-13 22:55, Oliver Schinagl wrote:
On 07/11/13 22:26, Greg Kroah-Hartman wrote:
On Thu, Jul 11, 2013 at 10:09:11PM +0200, Oliver Schinagl wrote:
On 07/11/13 19:06, Greg Kroah-Hartman wrote:
On Thu, Jul 11, 2013 at 01:58:29PM +0200, Oliver Schinagl wrote:
On 11-07-13 02:36, Greg Kroah-Hartman wrote:
To make it easier for driver subsystems to work with attribute
groups,
create the ATTRIBUTE_GROUPS macro to remove some of the repetitive
typing for the most common use for attribute groups.
But binary groups are discriminated against :(
Yes, as they are "rarer" by far, as they should be. binary sysfs
files
should almost never be used, as they are only "pass-through" files to
the hardware, so I want to see you do more work in order to use
them, as
they should not be created lightly.
I guess I can see a valid reason here, but they are only helper
macro's making life easier for people who do need to use these and
are on par with the non-binary versions. And we already have quite
some binary attributes, probably far less then normal ones :)
I only count about 100 valid binary files in the tree at the moment,
that's not really all that many to handle.
100 is quite a few :) But point taken.
Anyway, wouldn't all users be reviewed anyway? But I guess it's a
small safety net to make it not TOO easy.
exactly :)
I aggree and this is a v2 that strips all the additional bits.
A few comments left below.
The attached patch should help here.
Can you give me an example of using these macros? I seem to be
lost in
them somehow, or maybe my morning coffee just hasn't kicked in...
Yeah, I kinda added the whole shebang there :) I was trying being
helpful :(
I suppose one more additional helper wouldn't be bad to have:
#define ATTRIBUTE_(BIN_)GROUPS_R[O/W](_name(, _size)) \
ATTRIBUTE_(BIN_)ATTR_R[O/W](_name, _size); \
ATTRIBUTE_(BIN_)GROUPS(_name)
Would that ever be needed?
Of ourse, by the lazy :)
I think now you create an attribute in a group as this (with this
patch):
ATTRIBUTE_ATTR_RO(name, SIZE);
but "raw" attributes are rare, you really want a "device", "class", or
"bus" attribute, right?
I suppose so, But I got stuck in the rare case some how initially. I
registered my driver with module_platform_driver(); and in that struct
i had the "device_driver" which had a group attribute so I used that.
I already learned from maxime that that is the wrong way :) and
hopefully I'll figure out what the right way will be soon ;)
ATTRIBUTE_GROUPS(name);
.group = name;
After that last addition, you'd simply do:
ATTRIBUTE_GROUPS_RO(name);
.group = name;
saves a whole line :)
Not worth it :)
>From 003ab7a74ff689daa6934e7bc50c498b2d35a1cc Mon Sep 17 00:00:00
2001
From: Oliver Schinagl
Date: Thu, 11 Jul 2013 13:48:18 +0200
Subject: [PATCH] sysfs: add more helper macro's for
(bin_)attribute(_groups)
With the recent changes to sysfs there's various helper macro's.
However there's no RW, RO BIN_ helper macro's. This patch adds them.
Additionally there are no BIN_ group helpers so there's that aswell
Moreso, if both bin and normal attribute groups are used, there's a
simple helper for that, though the naming code be better. _TXT_
for the
show/store ones and neither TXT or BIN for both, but that would
change
things to extensivly.
Finally there's also helpers for ATTRIBUTE_ATTRS.
After this patch, create default attributes can be as easy as:
ATTRIBUTE_(BIN_)ATTR_RO(name, SIZE);
ATTRIBUTE_BIN_GROUPS(name);
Signed-off-by: Oliver Schinagl
---
include/linux/sysfs.h | 96
---
1 file changed, 84 insertions(+), 12 deletions(-)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 2c3b6a3..0ebed11 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
struct kobject;
@@ -94,15 +95,32 @@ struct attribute_group {
#define __ATTR_IGNORE_LOCKDEP__ATTR
#endif
-#define ATTRIBUTE_GROUPS(name)\
-static const struct attribute_group name##_group = {\
-.attrs = name##_attrs,\
+#define __ATTRIBUTE_GROUPS(_name)\
+static const struct attribute_group *_name##_groups[] = {\
+&_name##_group,\
+NULL,\
+}
+
+#define ATTRIBUTE_GROUPS(_name)\
+static const struct attribute_group _name##_group = {\
+.attrs = _name##_attrs,\
};\
-static const struct attribute_group *name##_groups[] = {\
-##_group,\
+__ATTRIBUTE_GROUPS(_name)
+
+#define __ATTRIBUTE_ATTRS(_name)\
+struct bin_attribute
Re: [ 00/19] 3.10.1-stable review
On Fri, 2013-07-12 at 10:05 -0700, Greg Kroah-Hartman wrote: > Specific example is, again, the powerpc patches. Out of 21 patches > marked for stable that showed up in the -rc1 merge, at least 7 of them > had _plenty_ of time to get into 3.10.0 as they are weeks, and sometimes > months, old. Some of the other ones seem _very_ new, being only days > old before they hit Linus's tree, which makes me worry about them for > totally different reasons (i.e. not tested in linux-next at all.) So for the old ones that's me not actively sending you stuff that has a CC stable tag when I merge it. I should probably fix that indeed. This is especially true of (but not exclusively) stuff that I don't apply myself but merge via somebody else branch. For the new stuff, this is a combinations of some last minute fuckups which are pretty specific to 3.10 and for which I'm in part responsible, and in part due to us basically ramping up testing on Power8 and getting ready for the next RHEL & SLES at the same time, thus doing more testing internally. You'll notice that a lot of that stuff is P8 support so testing in "next" isn't going to help much since nobody outside of IBM has access to these guys yet. We are getting the stuff out there due to distro unrealistic expectations of having upstream code for new machines years before a release. Also keep in mind that sometimes, that stuff has been around on patchwork for a while and got tested by various people, but the patch got a last minute rev of improved changeset comment or cosmetic polish. > I can put a "delay" on patches to not hit a stable release for a few > weeks until they get some testing in Linus's tree, but in reality, > what's that going to help with? Depends. In some of the patches I put in for stable, they fix something that 3.10 broke and the fixes are quite self-contained, waiting makes no sense. At some stage I make a judgement call on a given patch, how "obvious" the fix is (I know they never are completely ... well most of the time), how invasive it is, what risk it represents outside of the are that it "fixes". I do mistakes, but generally I am fairly conservative in that area. > I guess I can just not apply them at all, tough-love and all that, but > that just puts an extra burden on the distro kernel maintainers to have > to go dig up the fixes for their users. You know how the distro can be about that... especially when they invent idiotic junk such as kABI which prevents you from fixing things properly for the sake of [probably illegal] binary drivers, and so on... Distro seem to enjoy establishing a process that guarantee that an "enterprise release" is entirely comprise of utter junk (not even talking about all the in-house untested broken stupid crap they add to their kernels while at the same time being hard-ass with fixes coming from the vendors). > Although really, who cares about powerpc anymore :) That was unfair :-) Cheers, Ben. -- 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] N900: add device tree
Hi,
On Sat, Jul 13, 2013 at 02:17:09PM +0200, Pavel Machek wrote:
>
> This adds device tree with neccessary support to boot with functional
> video (on both emulator and real N900 device).
>
> Signed-off-by: Pavel Machek
You can also add:
Signed-off-by: Aaro Koskinen
Thanks,
A.
>
> ---
>
> From v1: Aaro wants just GPLv2, so I did that. I re-enabled parts that
> can be enabled on 3.10, and tested it on that kernel.
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f0895c5..1950aed 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -141,6 +141,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> omap3-devkit8000.dtb \
> omap3-beagle-xm.dtb \
> omap3-evm.dtb \
> + omap3-n900.dtb \
> omap3-tobi.dtb \
> omap3-igep0020.dtb \
> omap3-igep0030.dtb \
> diff --git a/arch/arm/boot/dts/omap3-n900.dts
> b/arch/arm/boot/dts/omap3-n900.dts
> new file mode 100644
> index 000..fb461bf
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -0,0 +1,92 @@
> +/*
> + * Copyright (C) 2013 Pavel Machek
> + * Copyright 2013 Aaro Koskinen
> + *
> + * 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.
> + */
> +
> +/dts-v1/;
> +
> +/include/ "omap34xx.dtsi"
> +
> +/ {
> + model = "Nokia N900";
> + compatible = "nokia,omap3-n900", "ti,omap3";
> +
> + cpus {
> + cpu@0 {
> + cpu0-supply = <>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x1000>; /* 256 MB */
> + };
> +
> +};
> +
> + {
> + clock-frequency = <220>;
> +
> + twl: twl@48 {
> + reg = <0x48>;
> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> + interrupt-parent = <>;
> + };
> +};
> +
> +/include/ "twl4030.dtsi"
> +
> +_gpio {
> + ti,pullups = <0x0>;
> + ti,pulldowns= <0x03ff3f>; /* BIT(0..5) | BIT(8..17) */
> +};
> +
> + {
> + clock-frequency = <40>;
> +};
> +
> + {
> + clock-frequency = <10>;
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + // For some reason, touchscreen is neccessary for screen to work at
> + // all on real hw. It works well without it on emulator.
> + //
> + // Also... order in the device tree actually matters here.
> + tsc2005@0 {
> + compatible = "tsc2005";
> + spi-max-frequency = <600>;
> + reg = <0>;
> + };
> + mipid@2 {
> + compatible = "acx565akm";
> + spi-max-frequency = <600>;
> + reg = <2>;
> + // turbo_mode = 0,
> + // cs_per_word = 0
> + };
> +};
> +
> +_otg_hs {
> + interface-type = <0>;
> + usb-phy = <_phy>;
> + mode = <2>;
> + power = <50>;
> +};
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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] drm/i915: fix long-standing SNB regression in power consumption after resume
On Sun, Jul 14, 2013 at 06:52:39PM +0200, Daniel Vetter wrote:
> On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov
> wrote:
> > This patch fixes regression in power consumtion of sandy bridge gpu, which
> > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking
> > that
> > it's extremely busy. After that it never reaches rc6 state.
> >
> > Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
> > ("drm/i915: load boot context at driver init time"). Without documentation
> > it's not clear what is happening here, probably this breaks internal state
> > of
> > hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake
> > during whole initialization sequence in gen6_init_clock_gating() fixes this
> > bug.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
> > Signed-off-by: Konstantin Khlebnikov
>
> We already hold an forcewake reference while setting up the rps stuff,
> should we maybe hold the forcewake for the entire duration, i.e. grab
> it here in clock_gating and release it only in gen6/vlv_enable_rps?
> Can you please test that version, too?
>
> In any case the forcewake grabbing here in the clock gating function
> needs a big comment that otherwise setting the MCTL register might
> break rc6 entry.
It is not clear why the forcewake works, but is easy to imagine one of
the operations in that sequence requires the GPU to be awake at the time
of programming for it to succeed. MBCTL:EnableBootFetch does seem the most
suspicious from its wording in the bspec. I guess all instances of
poking this bit should be protected similary (snb, ivb, vlv, hsw).
Based on that reasoning and that waking the GPU up here has no negative
consequences, and so long as all paths are fixed, I am happy to give this
an Acked-by: Chris Wilson
Also, we need to reapply the w/a after a Function Level Reset, in other
words we do need to repeat the init_clock_gating after
intel_gpu_reset().
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
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] powerpc/pseries: drop "select HOTPLUG"
On Sun, 2013-07-14 at 13:02 +0200, Paul Bolle wrote:
> The Kconfig symbol HOTPLUG was removed with commit 40b313608a ("Finally
> eradicate CONFIG_HOTPLUG"). But there's still one select statement for
> that symbol. It seems that select statement was added after the patch to
> remove CONFIG_HOTPLUG was submitted. Anyhow, it is useless and can be
> dropped.
Thanks. I'll apply.
Ben.
> Signed-off-by: Paul Bolle
> ---
> Not tested.
>
> arch/powerpc/platforms/pseries/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/Kconfig
> b/arch/powerpc/platforms/pseries/Kconfig
> index 1bd3399..62b4f80 100644
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -19,7 +19,6 @@ config PPC_PSERIES
> select ZLIB_DEFLATE
> select PPC_DOORBELL
> select HAVE_CONTEXT_TRACKING
> - select HOTPLUG if SMP
> select HOTPLUG_CPU if SMP
> default y
>
--
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/1] MAINTAINERS: Change maintainer for cyttsp driver
I haven't had time to work on this driver for a long time and Ferruh has been doing a great job making it more generic, adding support for new hardware and providing bug fixes. So, let's make MAINTAINERS reflect reality and add him as the cyttsp maintainer instead of me. Also, since Ferruh works for Cypress, we may change the driver status from Maintained to Supported. Signed-off-by: Javier Martinez Canillas --- Ferruh, please send your ack if you are willing to take over maintainance of this driver. Also, please confirm that you have been working on behalf of Cypress instead of doing it on your free time. Otherwise we should keep the driver status to maintained instead supported. Thanks a lot and best regards, Javier MAINTAINERS |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9d771d9..4ba996c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2458,9 +2458,9 @@ S:Maintained F: drivers/media/common/cypress_firmware* CYTTSP TOUCHSCREEN DRIVER -M: Javier Martinez Canillas +M: Ferruh Yigit L: linux-in...@vger.kernel.org -S: Maintained +S: Supported F: drivers/input/touchscreen/cyttsp* F: include/linux/input/cyttsp.h -- 1.7.7.6 -- 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/1] MAINTAINERS: Change maintainer for cyttsp driver
I haven't had time to work on this driver for a long time and Ferruh has been doing a great job making it more generic, adding support for new hardware and providing bug fixes. So, let's make MAINTAINERS reflect reality and add him as the cyttsp maintainer instead of me. Also, since Ferruh works for Cypress, we may change the driver status from Maintained to Supported. Signed-off-by: Javier Martinez Canillas --- Ferruh, please send your ack if you are willing to take over maintainance of this driver. Also, please confirm that you have been working on behalf of Cypress instead of doing it on your free time. Otherwise we should keep the driver status to maintained instead supported. Thanks a lot and best regards, Javier MAINTAINERS |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9d771d9..4ba996c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2458,9 +2458,9 @@ S:Maintained F: drivers/media/common/cypress_firmware* CYTTSP TOUCHSCREEN DRIVER -M: Javier Martinez Canillas +M: Ferruh Yigit L: linux-in...@vger.kernel.org -S: Maintained +S: Supported F: drivers/input/touchscreen/cyttsp* F: include/linux/input/cyttsp.h -- 1.7.7.6 -- 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] x86/asm: avoid mnemonics without type suffix
I think best would be to just find some way to implement LOCK prefix patching using atomic compiler intrinsics and then switch to those Then all this inline assembler horror could be ifdef'ed away for old compilers only, and likely the generated code would be better as the compiler could optimize more. Or just give up on LOCK patching, as single CPU systems and VMs are less and less interesting? -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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] HID: kye: Add report fixup for Genius Gx Imperator Keyboard
On Fri, 12 Jul 2013, Benjamin Tissoires wrote:
> Genius Gx Imperator Keyboard presents the same problem in its report
> descriptors than Genius Gila Gaming Mouse.
> Use the same fixup for both.
>
> Fixes:
> https://bugzilla.redhat.com/show_bug.cgi?id=928561
>
> Reported-and-tested-by: Honza Brazdil
> Signed-off-by: Benjamin Tissoires
> ---
>
> Hi Jiri,
>
> I have been reported this broken Genius device too.
> The patch applies on top of the branch for-3.11/upstream, but feel free to
> schedule it for 3.11 or 3.12. This time, only the multimedia (and macros) keys
> are broken. The core keyboard part is working fine without the patch.
>
> Cheers,
> Benjamin
>
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/hid-kye.c | 45 -
> 2 files changed, 29 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index b2b692e..1f28df9 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -475,6 +475,7 @@
> #define USB_VENDOR_ID_KYE0x0458
> #define USB_DEVICE_ID_KYE_ERGO_525V 0x0087
> #define USB_DEVICE_ID_GENIUS_GILA_GAMING_MOUSE 0x0138
> +#define USB_DEVICE_ID_GENIUS_GX_IMPERATOR0x4018
> #define USB_DEVICE_ID_KYE_GPEN_560 0x5003
> #define USB_DEVICE_ID_KYE_EASYPEN_I405X 0x5010
> #define USB_DEVICE_ID_KYE_MOUSEPEN_I608X 0x5011
> diff --git a/drivers/hid/hid-kye.c b/drivers/hid/hid-kye.c
> index 1e2ee2aa..7384512 100644
> --- a/drivers/hid/hid-kye.c
> +++ b/drivers/hid/hid-kye.c
> @@ -268,6 +268,26 @@ static __u8 easypen_m610x_rdesc_fixed[] = {
> 0xC0 /* End Collection */
> };
>
> +static __u8 *kye_consumer_control_fixup(struct hid_device *hdev, __u8 *rdesc,
> + unsigned int *rsize, int offset, const char *device_name) {
> + /*
> + * the fixup that need to be done:
> + * - change Usage Maximum in the Comsumer Control
> + * (report ID 3) to a reasonable value
> + */
> + if (*rsize >= offset + 31 &&
> + /* Usage Page (Consumer Devices) */
> + rdesc[offset] == 0x05 && rdesc[offset + 1] == 0x0c &&
> + /* Usage (Consumer Control) */
> + rdesc[offset + 2] == 0x09 && rdesc[offset + 3] == 0x01 &&
> + /* Usage Maximum > 12287 */
> + rdesc[offset + 10] == 0x2a && rdesc[offset + 12] > 0x2f) {
> + hid_info(hdev, "fixing up %s report descriptor\n", device_name);
> + rdesc[offset + 12] = 0x2f;
> + }
> + return rdesc;
> +}
> +
> static __u8 *kye_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> unsigned int *rsize)
> {
> @@ -315,23 +335,12 @@ static __u8 *kye_report_fixup(struct hid_device *hdev,
> __u8 *rdesc,
> }
> break;
> case USB_DEVICE_ID_GENIUS_GILA_GAMING_MOUSE:
> - /*
> - * the fixup that need to be done:
> - * - change Usage Maximum in the Comsumer Control
> - * (report ID 3) to a reasonable value
> - */
> - if (*rsize >= 135 &&
> - /* Usage Page (Consumer Devices) */
> - rdesc[104] == 0x05 && rdesc[105] == 0x0c &&
> - /* Usage (Consumer Control) */
> - rdesc[106] == 0x09 && rdesc[107] == 0x01 &&
> - /* Usage Maximum > 12287 */
> - rdesc[114] == 0x2a && rdesc[116] > 0x2f) {
> - hid_info(hdev,
> - "fixing up Genius Gila Gaming Mouse "
> - "report descriptor\n");
> - rdesc[116] = 0x2f;
> - }
> + rdesc = kye_consumer_control_fixup(hdev, rdesc, rsize, 104,
> + "Genius Gila Gaming Mouse");
> + break;
> + case USB_DEVICE_ID_GENIUS_GX_IMPERATOR:
> + rdesc = kye_consumer_control_fixup(hdev, rdesc, rsize, 83,
> + "Genius Gx Imperator Keyboard");
> break;
> }
> return rdesc;
> @@ -428,6 +437,8 @@ static const struct hid_device_id kye_devices[] = {
> USB_DEVICE_ID_KYE_EASYPEN_M610X) },
> { HID_USB_DEVICE(USB_VENDOR_ID_KYE,
> USB_DEVICE_ID_GENIUS_GILA_GAMING_MOUSE) },
> + { HID_USB_DEVICE(USB_VENDOR_ID_KYE,
> + USB_DEVICE_ID_GENIUS_GX_IMPERATOR) },
> { }
> };
Hi Benjamin,
I guess you are missing update of hid_have_special_driver[] list?
--
Jiri Kosina
SUSE Labs
--
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/
It is Private
It is Private I am George Daniels, a Banker and credit system programmer (HSBC bank). I saw your email address while browsing through the bank D.T.C Screen in my office yesterday so I decided to use this very chance to know you. I believe we should use every opportunity to know each other better. However, I am contacting you for obvious reason which you will understand. I am sending this mail just to know if this email address is OK, reply me back so that I will send more details to you. I have a very important thing to discuss with you, I look forward to receiving your response at georgedani...@postino.net. Have a pleasant day. George Daniels -- 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] media: i2c: adv7343: add OF support
Hi Prabhakar,
On 07/13/2013 01:12 PM, Prabhakar Lad wrote:
From: "Lad, Prabhakar"
add OF support for the adv7343 driver.
Signed-off-by: Lad, Prabhakar
---
Changes for v2:
1: Fixed naming of properties.
.../devicetree/bindings/media/i2c/adv7343.txt | 54
drivers/media/i2c/adv7343.c| 65 +++-
2 files changed, 118 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/adv7343.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7343.txt
b/Documentation/devicetree/bindings/media/i2c/adv7343.txt
new file mode 100644
index 000..1d2e854
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adv7343.txt
@@ -0,0 +1,54 @@
+* Analog Devices adv7343 video encoder
+
+The ADV7343 are high speed, digital-to-analog video encoders in a 64-lead LQFP
+package. Six high speed, 3.3 V, 11-bit video DACs provide support for composite
+(CVBS), S-Video (Y-C), and component (YPrPb/RGB) analog outputs in standard
+definition (SD), enhanced definition (ED), or high definition (HD) video
+formats.
+
+Required Properties :
+- compatible: Must be "ad,adv7343"
Please have a look at Documentation/devicetree/bindings/vendor-prefixes.txt.
'ad' is a vendor prefix reserved for "Avionic Design GmbH".
For "Analog Devices, Inc." 'adi' should be used.
If I would have to draft a new DT binding proposal checklist checking
vendor-prefixes.txt would certainly be one of the first steps.
+Optional Properties :
+- ad,adv7343-power-mode-sleep-mode: on enable the current consumption is
+reduced to micro ampere level. All DACs and
+the internal PLL circuit are disabled.
+- ad,adv7343-power-mode-pll-ctrl: PLL and oversampling control. This control
+ allows internal PLL 1 circuit to be powered
+ down and the oversampling to beswitched off.
+- ad,adv7343-power-mode-dac-1: power on/off DAC 1, 0 = OFF and 1 = ON.
+- ad,adv7343-power-mode-dac-2: power on/off DAC 2, 0 = OFF and 1 = ON.
+- ad,adv7343-power-mode-dac-3: power on/off DAC 3, 0 = OFF and 1 = ON.
+- ad,adv7343-power-mode-dac-4: power on/off DAC 4, 0 = OFF and 1 = ON.
+- ad,adv7343-power-mode-dac-5: power on/off DAC 5, 0 = OFF and 1 = ON.
+- ad,adv7343-power-mode-dac-6: power on/off DAC 6, 0 = OFF and 1 = ON.
+- ad,adv7343-sd-config-dac-out-1: Configure SD DAC Output 1.
+- ad,adv7343-sd-config-dac-out-2: Configure SD DAC Output 2.
All these properties look more like hardware configuration, rather than
hardware description. So at first sight I would say none of these properties
is suitable for the device tree.
sleep mode and pll ctrl should likely only have default values in the
driver.
sleep-mode disables all DAC, while power-mode-dac-? does power on/off
(enables / disables?) individual DACs. How those properties interact,
what's
going on here exactly ? :)
That said, how about only leaving the properties indicating which DACs
(including SD DACs) should be enabled ? E.g.
adi,dac-enable - an array indicating which DACs are enabled, in order
DAC1...DAC6, 1 to enable DAC, 0 to disable.
adi,sd-dac-enable - an array indicating which SD DACs are enabled, in order
DAC1...DAC2, 1 to enable SD DAC, 0 to disable.
Please note you don't need ",adv7343-" prefix in each single property
for that device.
+Example:
+
+i2c0@1c22000 {
+ ...
+ ...
+
+ adv7343@2a {
+ compatible = "ad,adv7343";
+ reg =<0x2a>;
+
+ port {
+ adv7343_1: endpoint {
+ ad,adv7343-power-mode-sleep-mode;
+ ad,adv7343-power-mode-pll-ctrl;
+ ad,adv7343-power-mode-dac-1;
+ ad,adv7343-power-mode-dac-2;
+ ad,adv7343-power-mode-dac-3;
+ ad,adv7343-power-mode-dac-4;
+ ad,adv7343-power-mode-dac-5;
+ ad,adv7343-power-mode-dac-6;
Then this would have become:
adi,dac-enable = <1 1 1 1 1 1>;
But I would put some disabled DACs in the example as well:
/* Use DAC1..3, DAC6 */
adi,dac-enable = <1 1 1 0 0 1>;
+ ad,adv7343-sd-config-dac-out-1;
+ ad,adv7343-sd-config-dac-out-2;
And this:
adi,sd-dac-enable = <1 1>;
+ };
+ };
+ };
+ ...
+};
diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
index 7606218..22ee6f4 100644
---
Re: [ 00/19] 3.10.1-stable review
On Sun, Jul 14, 2013 at 7:24 AM, Guenter Roeck wrote:
>> You are confusing the words "real" and "critical" perhaps. I, and other
>
> A typical classification of bugs might be
> critical: mission critical, no workaround, must be fixed prior to
> customer release
> severe (high): related to core functionality, must fix, but not
> necessarily in first release.
> moderate (medium): Bugs that do not affect any critical user
> functionality; typically has workaround
> minor (low): Bugs that do not interfere with core functionality
> and are just annoyances that may or may not ever be fixed
> cosmetic: misspellings
>
> Such classifications are widely used in the industry. The term "affecting
> users"
> might apply to all of those, and even a cosmetic bug is "real".
And typically there's a distinction between severity (how bad is it), and
priority (how soon it should be fixed), wich are not always linearly correlated.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] rtc: Add MOXA ART RTC driver
On Thursday 11 July 2013, Jonas Jensen wrote: > Add RTC driver for MOXA ART SoCs. > + > +#define GPIO_EM1240_OUTPUT 1 > +#define GPIO_EM1240_INPUT0 > + > +#define GPIO_RTC_SCLK(5) > +#define GPIO_RTC_DATA(6) > +#define GPIO_RTC_RESET (7) Since this is a DT-only platform, you should not really have hardcoded GPIO numbers. > + devm_gpio_request(>dev, GPIO_RTC_DATA, "rtc_data"); > + devm_gpio_request(>dev, GPIO_RTC_SCLK, "rtc_sclk"); > + devm_gpio_request(>dev, GPIO_RTC_RESET, "rtc_reset"); Instead, you should use of_get_named_gpio() here, and add a binding document that describes the names. Arnd -- 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] SLAB changes for v3.11-rc0
On Sun, Jul 14, 2013 at 12:06 PM, Pekka Enberg wrote: > > The tree also contains Christoph's unification work that I merged in > too late had to revert because it broke things. We'll try again for > v3.12. Ugh. I'll merge the commits leading up to that, but not the actual broken try at unification at all. There's just one one-liner patch in between the broken commits and their reverts, I don't see the point of pulling that part at all, and I can take the one-liner separately. 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] misc: add driver for Renesas R-Car Gyro-ADC/speed-pulse interfaces
Hello. On 07/14/2013 12:12 PM, Lars-Peter Clausen wrote: And are you sure you want to control this through sysfs? There's no other better user/kernel apis for it? I found none, besides ioctl(), as the device driven is rather unique. But I thought that sysfs is "ioctl() today", so I went with it... It does sound like it would fit better into IIO than just a misc driver, even if it's the only hardware of its kind. I got somewhat familiarized myself with drivers/iio/ infrastructure and I have found a place only the for ADC device in which the customer currently has no interest. The other trouble is that I'll have to backport this driver to 3.4 which doesn't contain the IIO infrastructure at all. :-( It has, it's just still in staging in 3.4. But the API (except for minor modifications) and more importantly the ABI are the same. Thank you for the useful information. I wouldn't probably have figured it out to search there. There is a angular velocity channel type in IIO. maybe that could be used to report the Speed-Pulse-ADC values. You probably misunderstood from my terse description. Multichannel ADC interface is separate from the speed-pulse interface which has on its single input digital PWM signal of varying frequency. Speed pulse i/f measures pulse count and period. I've found no adequate channel type in IIO infrastructure so far. I'll mail the IIO maintainers with a request for help probably... - Lars WBR, Sergei -- 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: [LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix
On Sun, Jul 14, 2013 at 12:30 PM, Tim Northover wrote: > > I don't think you've actually tested that, have you? (x86-64) Oh, you're right, for constants > 5 bits you have that other thing going on. I didn't think about the fact that the constant changed in the middle of the thread (it started out as 1). We use the gcc constraint "I" (0-31) in the kernel for this reason. 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 2/2] media: i2c: tvp7002: add OF support
Hi Prabhakar, On 07/12/2013 06:43 AM, Prabhakar Lad wrote: On Fri, Jul 12, 2013 at 3:34 AM, Sylwester Nawrocki wrote: On 07/11/2013 07:09 PM, Prabhakar Lad wrote: [...] And include/media/tvp70002.h: * fid_polarity: * 0 -> the field ID output is set to logic 1 for an odd * field (field 1) and set to logic 0 for an even * field (field 0). * 1 -> operation with polarity inverted. Do you know if the chip automatically selects video sync source (sync-on-green vs. VSYNC/HSYNC) and there is no need to configure this on the analogue input side ? At least the driver seems to always select the default SOGIN_1 input (TVP7002_IN_MUX_SEL_1 register is set only at initialization time). Yes the driver is selecting the default SOGIN_1 input. Or perhaps it just outputs on SOGOUT, VSOUT, HSOUT lines whatever is fed to its analogue inputs, and any further processing unit need to determine what synchronization signal is present and should be used ? Yes that correct, there is a register (Sync Detect Status) which detects the sync for you. I suspect that we don't need, e.g. another endpoint node to specify the configuration of the TVP7002 analogue input interface, that would contain a property like video-sync. If I understand correctly you mean if there are two tvp7002 devices connected we don’t need to specify video-sync property, but my question how do we specify this property in common then ? No, I thought about two port sub-nodes of a single device node, one for the TVP7002 video input and one for the output. But it seems there is no need for that, i.e. to specify the input configuration statically in the firmware. The chip detects the signals automatically, i.e. it uses whatever is available, and it allows querying the selection status at run time. What would really need to be configured statically in DT in that case then ? Some initial video sync configuration ? I guess it could be well hard coded in the driver, since the hardware does run time detection anyway. Yes the chip detects the signal automatically, What I want to configure in the DT case is say if SOG signal is detected, I want to invert the polarity of it this is what I am trying to set in DT case whether to invert or not. 0 = Normal operation (default) 1 = SOG output polarity inverted Something similar to fid_polarity. Then as I suggested earlier, let's just add 'sync-on-green-active' DT property for that. I wouldn't expect the DT properties to be directly replacing your driver platform_data members. Saying in the binding that this is a normal operation and that is an inverted one is not very useful in general, as you would need to dig in the binding's description what "normal" exactly means. sync-on-green-active = <1>; seems much more explicit than, e.g. sync-on-green-inverted. By looking at the sync-on-green-active property each device driver would determine whether it means normal or inverted operation for its device. -- Thanks, Sylwester -- 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: [LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix
On 07/14/2013 12:30 PM, Tim Northover wrote:
>> And that is why I think you should just consider "bt $x,y" to be
>> trivially the same thing and not at all ambiguous. Because there is
>> ABSOLUTELY ZERO ambiguity when people write
>>
>>bt $63, mem
>>
>> Zero. Nada. None. The semantics are *exactly* the same for btl and btq
>> in this case, so why would you want the user to specify one or the
>> other?
> I don't think you've actually tested that, have you? (x86-64)
>
> int main() {
> long val = 0x;
> char res;
>
> asm("btl $63, %1\n\tsetc %0" : "=r"(res) : "m"(val));
> printf("%d\n", res);
>
> asm("btq $63, %1\n\tsetc %0" : "=r"(res) : "m"(val));
> printf("%d\n", res);
> }
Blerk. It doesn't undermine the original point - that gas can
unambiguously choose the right operation size for a constant bit offset
- but yes, the operation size is meaningful in the case of a immediate
bit offset. Its pretty nasty of Intel to hide that detail in Table 3-2,
far from the instructions which use it...
J
>
> Tim.
>
--
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/
[3.10.1] strange kernel crash after thousands suspend-resume cycles
first and only warning had happened here: Jul 14 20:42:50 zurg kernel: [ 225.991608] [ cut here ] Jul 14 20:42:50 zurg kernel: [ 225.991613] WARNING: at net/mac80211/pm.c:113 __ieee80211_suspend+0x6ad/0x6d0() Jul 14 20:42:50 zurg kernel: [ 225.991633] Modules linked in: iwldvm iwlwifi nfsd auth_rpcgss oid_registry nfs_acl nfs lockd sunrpc bridge stp llc tun fuse snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc thinkpad_acpi snd_seq_midi snd_seq_midi_event iTCO_wdt snd_rawmidi intel_powerclamp coretemp hid_logitech_dj cdc_ncm uvcvideo kvm_intel kvm usbnet videobuf2_vmalloc videobuf2_memops mii videobuf2_core videodev cdc_wdm cdc_acm snd_seq snd_seq_device snd_timer i915 snd soundcore lpc_ich mfd_core wmi drm_kms_helper sdhci_pci sdhci e1000e ptp Jul 14 20:42:50 zurg kernel: [ 225.991635] CPU: 0 PID: 4940 Comm: pm-suspend Not tainted 3.10.1-zurg-1-gaa457b5 #107 Jul 14 20:42:50 zurg kernel: [ 225.991636] Hardware name: LENOVO 4291QY6/4291QY6, BIOS 8DET51WW (1.21 ) 08/02/2011 Jul 14 20:42:50 zurg kernel: [ 225.991637] 0009 8803f5761c40 81621b62 8803f5761c78 Jul 14 20:42:50 zurg kernel: [ 225.991638] 8104e8b1 880405560640 8804055612f8 Jul 14 20:42:50 zurg kernel: [ 225.991639] 8804055612f8 880405560860 8803f5761c88 8104e98a Jul 14 20:42:50 zurg kernel: [ 225.991640] Call Trace: Jul 14 20:42:50 zurg kernel: [ 225.991643] [] dump_stack+0x19/0x1b Jul 14 20:42:50 zurg kernel: [ 225.991646] [] warn_slowpath_common+0x61/0x80 Jul 14 20:42:50 zurg kernel: [ 225.991647] [] warn_slowpath_null+0x1a/0x20 Jul 14 20:42:50 zurg kernel: [ 225.991648] [] __ieee80211_suspend+0x6ad/0x6d0 Jul 14 20:42:50 zurg kernel: [ 225.991651] [] ieee80211_suspend+0x1a/0x30 Jul 14 20:42:50 zurg kernel: [ 225.991653] [] wiphy_suspend+0x77/0x200 Jul 14 20:42:50 zurg kernel: [ 225.991654] [] ? addresses_show+0xa0/0xa0 Jul 14 20:42:50 zurg kernel: [ 225.991656] [] legacy_suspend+0x28/0x60 Jul 14 20:42:50 zurg kernel: [ 225.991659] [] __device_suspend+0x2c6/0x330 Jul 14 20:42:50 zurg kernel: [ 225.991660] [] dpm_suspend+0x58/0x220 Jul 14 20:42:50 zurg kernel: [ 225.991661] [] dpm_suspend_start+0x57/0x60 Jul 14 20:42:50 zurg kernel: [ 225.991663] [] suspend_devices_and_enter+0x70/0x480 Jul 14 20:42:50 zurg kernel: [ 225.991665] [] pm_suspend+0x178/0x260 Jul 14 20:42:50 zurg kernel: [ 225.991666] [] state_store+0x75/0xf0 Jul 14 20:42:50 zurg kernel: [ 225.991668] [] kobj_attr_store+0xf/0x20 Jul 14 20:42:50 zurg kernel: [ 225.991670] [] sysfs_write_file+0xd3/0x150 Jul 14 20:42:50 zurg kernel: [ 225.991673] [] vfs_write+0xb9/0x1c0 Jul 14 20:42:50 zurg kernel: [ 225.991674] [] SyS_write+0x49/0xa0 Jul 14 20:42:50 zurg kernel: [ 225.991677] [] system_call_fastpath+0x16/0x1b Jul 14 20:42:50 zurg kernel: [ 225.991678] ---[ end trace 996fb345fab7f015 ]--- after that kernel has worked fine for a hour and has done thousands s2ram suspend-resume cycles but 'mei_me' has started generating endless noise... Jul 14 21:52:28 zurg kernel: [ 2749.332358] cfg80211: Regulatory domain changed to country: RU Jul 14 21:52:28 zurg kernel: [ 2749.332368] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Jul 14 21:52:28 zurg kernel: [ 2749.332373] cfg80211: (2402000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm) Jul 14 21:52:28 zurg kernel: [ 2749.332378] cfg80211: (5735000 KHz - 5835000 KHz @ 2 KHz), (N/A, 3000 mBm) Jul 14 21:52:29 zurg kernel: [ 2749.928395] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Jul 14 21:52:35 zurg kernel: [ 2755.840385] IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready Jul 14 21:52:54 zurg kernel: [ 2775.005762] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 21:52:54 zurg kernel: [ 2775.007722] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 21:52:54 zurg kernel: [ 2775.011081] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 21:52:54 zurg kernel: [ 2775.011534] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 21:52:54 zurg kernel: [ 2775.011560] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 21:52:54 zurg kernel: [ 2775.011752] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 21:52:54 zurg kernel: [ 2775.013369] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 21:52:54 zurg kernel: [ 2775.013731] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 21:52:54 zurg kernel: [ 2775.013756] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 21:52:54 zurg kernel: [ 2775.013980] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 21:52:54 zurg kernel: [ 2775.014346] mei_me :00:16.0: unexpected reset: dev_state = RESETTING Jul 14 21:52:54
Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
On Thursday 11 July 2013, Neil Zhang wrote: > > > > To do this properly, the drivers are going to have to be compatible > > > > with the old and the new names, and the binding docs updated to > > > > reflect the legacy name and the preferred name. > > > > > > Properly would be as above. You can stop using stock tickers for new > > > company names, but anything that has been defined in a device tree > > > before has to stay that way, and all the manufacturer prefixes to > > > device names should be the same. What you're proposing is purely > > > driver bloat and increasing the size of kernel. > > > > *I'm* not proposing to change the name, Neil is. I'm proposing that > > iff they chose to do that, don't break sh*t along the way. > > > > What's your opinion? We discussed the topic of fixing bad bindings vs. keeping backwards compatibility during last week's Linaro Connect. The main outcome was that we need to have a better review for new bindings getting merged to avoid this situation in the future, but the general consensus seems that bindings that are already in use but were never reviewed properly (which should have caught this) should be changed. We will likely establish an annotation in the binding soon to mark those that can not be changed as opposed to those that are not considered stable yet. Arnd -- 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: [LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix
> And that is why I think you should just consider "bt $x,y" to be
> trivially the same thing and not at all ambiguous. Because there is
> ABSOLUTELY ZERO ambiguity when people write
>
>bt $63, mem
>
> Zero. Nada. None. The semantics are *exactly* the same for btl and btq
> in this case, so why would you want the user to specify one or the
> other?
I don't think you've actually tested that, have you? (x86-64)
int main() {
long val = 0x;
char res;
asm("btl $63, %1\n\tsetc %0" : "=r"(res) : "m"(val));
printf("%d\n", res);
asm("btq $63, %1\n\tsetc %0" : "=r"(res) : "m"(val));
printf("%d\n", res);
}
Tim.
--
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] x86/asm: avoid mnemonics without type suffix
On Sun, Jul 14, 2013 at 12:23 PM, Jeremy Fitzhardinge wrote: > > It looks like that if the base address isn't aligned then neither is the > generated access, so you could get a protection fault if it overlaps a > page boundary, which is a semantic rather than purely operational > difference. You could also get AC fault for the btq if the thing is only long-aligned. But yes, I checked the Intel manuals too, and the access size is actually not well-specified (even the 16-bit case says "may", I think), so both the page-fault and the alignment fault are purely theoretical. And i'm too lazy to bother trying the (easily testable) alignment fault case in practice, since (a) nobody cares and (b) nobody cares. In the (unlikely) situation that somebody actually cares, that somebody should obviously then have to specify "btl" vs "btq". Assuming the hardware cares, which is testable but might be micro-architecture dependent. 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 RFC v3] media: OF: add video sync endpoint property
Hi Prabhakar,
On 07/12/2013 06:29 AM, Prabhakar Lad wrote:
On Fri, Jul 12, 2013 at 2:45 AM, Sylwester Nawrocki
wrote:
On 07/11/2013 01:41 PM, Prabhakar Lad wrote:
[...]
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index aa59639..1a54530 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -100,6 +100,26 @@ static void v4l2_of_parse_parallel_bus(const struct
device_node *node,
if (!of_property_read_u32(node, "data-shift",))
bus->data_shift = v;
+ if (!of_property_read_u32(node, "video-sync",)) {
+ switch (v) {
+ case V4L2_MBUS_VIDEO_SEPARATE_SYNC:
+ flags |= V4L2_MBUS_VIDEO_SEPARATE_SYNC;
I'm not convinced all those video sync types is something that really
belongs
to the flags field. In my understanding this field is supposed to hold
only
the _signal polarity_ information.
Ok, so there should be a function say v4l2_of_parse_signal_polarity()
to get the polarity alone then.
I don't think this is required, I would just extend
v4l2_of_parse_parallel_bus()
function to also handle sync-on-green-active property.
If that is the case than I have to add a member say 'signal_polarity'
in struct v4l2_of_bus_parallel and assign the polarity to it.
Let me know if you are OK with it.
It probably would have been sensible to do something like this, however
I can't
see any advantage at the moment. struct v4l2_of_bus_parallel::flags
currently
holds all the polarity flags. Let's just add relevant macros for
sync-on-green
and store them in the flags field, as is done with the others.
Those V4L2_MUS_* flags are used by soc-camera to negotiate the
capabilities,
so I would rather not split them further without good reason, even though
struct v4l2_mbus_config::flags is used in those negotiation routines,
rather
than struct v4l2_of_bus_parallel::flags.
--
Thanks,
Sylwester
--
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/
