Re: upgrade to 3.8.1 : BUG Scheduling while atomic in bonding driver:
On 03/07/2013 03:05 PM, Linda Walsh wrote: > > > > > Michael Wang wrote: >> On 03/02/2013 01:21 PM, Linda Walsh wrote: >> Update -- it *used* to stop the messages in 3.6.7. >> >> It no longer stops the messages in 3.8.1 -- (and isn't present by >> default -- tried >> adding the unlock/lock -- no difference. >> >> Weird. *sigh* >> >> Hi, Linda >> >> Do you have the BUG log after applied this patch? >> >> bond->lock seems to be the only one who will add the preempt_count, the >> patch should works... >> >> And have you tried the 3.9.0-rc1, is the issue still exist? >> >> Regards, >> Michael Wang > --- > > What do you mean by 'bug log', do you mean kernel log --- including > the log from boot, in case anything weird pops out, but bug happens > edited out stretch of repetitious looking stuff that was unlikely to > be related... But do you have the log after applied the change which unlock bond->lock before enter bond_update_speed_duplex() ? you mentioned that the fix doesn't address the problem, but I'd like to take a look at the log, may be there will be more clue ;-) And have you tried 3.9.0-rc1? may be the issue already solved. Regards, Michael Wang > > > [0.00] Initializing cgroup subsys cpuset > [0.00] Initializing cgroup subsys cpu > [0.00] Linux version 3.8.1-Isht-Van (law@Ishtar) (gcc version > 4.6.2 (SUSE Linux) ) #6 SMP PREEMPT Fri Mar 1 20:29:32 PST 2013 > [0.00] Command line: BOOT_IMAGE=381-Isht-Van rw root=/dev/sdc1 > root=/dev/sdc1 showopts console=ttyS0,115200n8 console=tty0 elevator=cfq > pcie_aspm=force pcie_ports=native reboot=bios > [0.00] KERNEL supported cpus: > [0.00] Intel GenuineIntel > [0.00] e820: BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x0009] usable > ... > [0.00] BIOS-e820: [mem 0x0001-0x000c2fff] usable > [0.00] NX (Execute Disable) protection: active > [0.00] SMBIOS 2.6 present. > [0.00] DMI: Dell Inc. PowerEdge T610/0CX0R0, BIOS 6.1.0 10/18/2011 > [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved > [0.00] e820: remove [mem 0x000a-0x000f] usable > [0.00] e820: last_pfn = 0xc3 max_arch_pfn = 0x4 > [0.00] MTRR default type: uncachable > [0.00] MTRR fixed ranges enabled: > ... > [0.00] EC000-F write-protect > [0.00] MTRR variable ranges enabled: > [0.00] 0 base 00 mask FF8000 write-back > ... > [0.00] 7 base 0C mask FFC000 write-back > [0.00] 8 disabled > [0.00] 9 disabled > [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new > 0x7010600070106 > [0.00] e820: update [mem 0xd000-0x] usable ==> reserved > [0.00] e820: last_pfn = 0xcf379 max_arch_pfn = 0x4 > [0.00] initial memory mapped: [mem 0x-0x1fff] > [0.00] Base memory trampoline at [88098000] 98000 size 24576 > [0.00] Using GB pages for direct mapping > [0.00] init_memory_mapping: [mem 0x-0xcf378fff] > [0.00] [mem 0x-0xbfff] page 1G > [0.00] [mem 0xc000-0xcf1f] page 2M > [0.00] [mem 0xcf20-0xcf378fff] page 4k > [0.00] kernel direct mapping tables up to 0xcf378fff @ [mem > 0x1fffd000-0x1fff] > [0.00] init_memory_mapping: [mem 0x1-0xc2fff] > [0.00] [mem 0x1-0xb] page 1G > [0.00] [mem 0xc-0xc2fff] page 2M > [0.00] kernel direct mapping tables up to 0xc2fff @ [mem > 0xcf377000-0xcf378fff] > [0.00] ACPI: RSDP 000f1170 00024 (v02 DELL ) > ... > [0.00] ACPI: TCPA cf3b3f34 00064 (v02 DELL PE_SC3 > 0001 DELL 0001) > [0.00] ACPI: SSDT cf3b7000 037A4 (v01 INTEL PPM RCM > 8001 INTL 20061109) > [0.00] ACPI: Local APIC address 0xfee0 > ... > [0.00] SRAT: PXM 2 -> APIC 0x14 -> Node 1 > [0.00] SRAT: Node 1 PXM 2 [mem 0x-0xcfff] > [0.00] SRAT: Node 1 PXM 2 [mem 0x1-0x62fff] > [0.00] SRAT: Node 0 PXM 1 [mem 0x63000-0xc2fff] > [0.00] NUMA: Node 1 [mem 0x-0xcfff] + [mem > 0x1-0x62fff] -> [mem 0x-0x62fff] > [0.00] Initmem setup node 0 [mem 0x63000-0xc2fff] > [0.00] NODE_DATA [mem 0xc2fffd000-0xc2fff] > [0.00] Initmem setup node 1 [mem 0x-0x62fff] > [0.00] NODE_DATA [mem 0x62fffd000-0x62fff] > [0.00] [ea00-ea0018bf] PMD -> > [880617e0-88062fdf] on node 1 > [0.00] [ea0018c0-ea0030bf] PMD -> > [880c1760-880c2f5f] on node 0 > [0.00] Zone ranges: > [0.00] DMA [mem 0x1000-0x00ff] > [0.00] DMA
[PATCH for 3.9] memcg: initialize kmem-cache destroying work earlier
This patch fixes warning from lockdep caused by calling cancel_work_sync()
for uninitialized struct work. This path has been triggered by destructon
kmem-cache hierarchy via destroying its root kmem-cache.
Signed-off-by: Konstantin Khlebnikov
Cc: Glauber Costa
Cc: Andrew Morton
---
[ 250.781400] cache 88003c072d80
[ 250.783706] obj 88003b41 cache 88003c072d80
[ 250.786312] obj 88003b924000 cache 88003c20bd40
[ 250.787233] INFO: trying to register non-static key.
[ 250.788046] the code is fine but needs lockdep annotation.
[ 250.788184] turning off the locking correctness validator.
[ 250.788184] Pid: 2825, comm: insmod Tainted: G O
3.9.0-rc1-next-20130307+ #611
[ 250.788184] Call Trace:
[ 250.788184] [] __lock_acquire+0x16a2/0x1cb0
[ 250.788184] [] lock_acquire+0x8a/0x120
[ 250.788184] [] ? cancel_delayed_work+0xb0/0xb0
[ 250.788184] [] flush_work+0x38/0x2a0
[ 250.788184] [] ? cancel_delayed_work+0xb0/0xb0
[ 250.788184] [] ? mark_held_locks+0xae/0x120
[ 250.788184] [] ? __cancel_work_timer+0x7d/0xf0
[ 250.788184] [] ? trace_hardirqs_on_caller+0x105/0x1d0
[ 250.788184] [] __cancel_work_timer+0x89/0xf0
[ 250.788184] [] cancel_work_sync+0xb/0x10
[ 250.788184] [] kmem_cache_destroy_memcg_children+0x81/0xb0
[ 250.788184] [] kmem_cache_destroy+0xf/0xe0
[ 250.788184] [] init_module+0xcb/0x1000 [kmem_test]
[ 250.788184] [] ? 0xa0009fff
[ 250.788184] [] do_one_initcall+0x11a/0x170
[ 250.788184] [] load_module+0x19b0/0x2320
[ 250.788184] [] ? __unlink_module+0x30/0x30
[ 250.788184] [] ? retint_restore_args+0xe/0xe
[ 250.788184] [] ? retint_restore_args+0xe/0xe
[ 250.788184] [] SyS_init_module+0xc6/0xf0
[ 250.788184] [] system_call_fastpath+0x16/0x1b
---
#include
#include
#include
#include
int __init mod_init(void)
{
int size = 256;
struct kmem_cache *cache;
void *obj;
struct page *page;
cache = kmem_cache_create("kmem_cache_test", size, size, 0, NULL);
if (!cache)
return -ENOMEM;
printk("cache %p\n", cache);
obj = kmem_cache_alloc(cache, GFP_KERNEL);
if (obj) {
page = virt_to_head_page(obj);
printk("obj %p cache %p\n", obj, page->slab_cache);
kmem_cache_free(cache, obj);
}
flush_scheduled_work();
obj = kmem_cache_alloc(cache, GFP_KERNEL);
if (obj) {
page = virt_to_head_page(obj);
printk("obj %p cache %p\n", obj, page->slab_cache);
kmem_cache_free(cache, obj);
}
kmem_cache_destroy(cache);
return -EBUSY;
}
module_init(mod_init);
MODULE_LICENSE("GPL");
---
mm/memcontrol.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 669d16a..690fa8c 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3078,6 +3078,8 @@ void memcg_update_array_size(int num)
memcg_limited_groups_array_size = memcg_caches_array_size(num);
}
+static void kmem_cache_destroy_work_func(struct work_struct *w);
+
int memcg_update_cache_size(struct kmem_cache *s, int num_groups)
{
struct memcg_cache_params *cur_params = s->memcg_params;
@@ -3097,6 +3099,8 @@ int memcg_update_cache_size(struct kmem_cache *s, int
num_groups)
return -ENOMEM;
}
+ INIT_WORK(&s->memcg_params->destroy,
+ kmem_cache_destroy_work_func);
s->memcg_params->is_root_cache = true;
/*
@@ -3144,6 +3148,8 @@ int memcg_register_cache(struct mem_cgroup *memcg, struct
kmem_cache *s,
if (!s->memcg_params)
return -ENOMEM;
+ INIT_WORK(&s->memcg_params->destroy,
+ kmem_cache_destroy_work_func);
if (memcg) {
s->memcg_params->memcg = memcg;
s->memcg_params->root_cache = root_cache;
@@ -3424,8 +3430,6 @@ static void mem_cgroup_destroy_all_caches(struct
mem_cgroup *memcg)
list_for_each_entry(params, &memcg->memcg_slab_caches, list) {
cachep = memcg_params_to_cache(params);
cachep->memcg_params->dead = true;
- INIT_WORK(&cachep->memcg_params->destroy,
- kmem_cache_destroy_work_func);
schedule_work(&cachep->memcg_params->destroy);
}
mutex_unlock(&memcg->slab_caches_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: [PATCH 5/6] ima: Allow appraisal of digitally signed files only
On Tue, Mar 5, 2013 at 9:13 PM, Vivek Goyal wrote:
> On Thu, Feb 14, 2013 at 02:55:44PM -0500, Vivek Goyal wrote:
>> Currently ima appraises all the files as specified by the rule. So
>> if one wants to create a system where only few executables are
>> signed, that system will not work with IMA.
>>
>> With secureboot, one needs to disable kexec so that unsigned kernels
>> can't be booted. To avoid this problem, it was proposed that sign
>> /sbin/kexec binary and if signatures are verified successfully, give
>> an special capability to the /sbin/kexec process. And in secureboot
>> mode processes with that special capability can invoke sys_kexec()
>> system call.
>>
>> So there is a need for IMA to allow appraising only signed binaries.
>> Unsigned binaries will pass the appraisal too, but will not get the
>> special capability. (Capability patches for that are yet to be written).
>>
>> This patch adds new option, appraise_type=imasig_optional to allow
>> appraisal to pass even if no signatures are present on the file. If
>> signatures are present, then it has to be valid digital signature,
>> otherwise appraisal will fail.
>>
>> Signed-off-by: Vivek Goyal
>> ---
>> Documentation/ABI/testing/ima_policy |2 +-
>> security/integrity/ima/ima_main.c| 14 --
>> security/integrity/ima/ima_policy.c |2 ++
>> security/integrity/integrity.h |1 +
>> 4 files changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/ABI/testing/ima_policy
>> b/Documentation/ABI/testing/ima_policy
>> index de16de3..cc69872 100644
>> --- a/Documentation/ABI/testing/ima_policy
>> +++ b/Documentation/ABI/testing/ima_policy
>> @@ -30,7 +30,7 @@ Description:
>> uid:= decimal value
>> fowner:=decimal value
>> lsm:are LSM specific
>> - option: appraise_type:= [imasig]
>> + option: appraise_type:= [imasig] | [optional]
>>
>> default policy:
>> # PROC_SUPER_MAGIC
>> diff --git a/security/integrity/ima/ima_main.c
>> b/security/integrity/ima/ima_main.c
>> index 3e751a9..da9e348 100644
>> --- a/security/integrity/ima/ima_main.c
>> +++ b/security/integrity/ima/ima_main.c
>> @@ -207,8 +207,18 @@ out_digsig:
>> rc = -EACCES;
>> out:
>> mutex_unlock(&inode->i_mutex);
>> - if ((rc && must_appraise) && (ima_appraise & IMA_APPRAISE_ENFORCE))
>> - return -EACCES;
>> + if ((rc && must_appraise) && (ima_appraise & IMA_APPRAISE_ENFORCE)) {
>> + /*
>> + * If IMA_APPRAISAL_OPT is set, then access is allowed
>> + * even if hash or digital signatures are not present.
>> + */
>> + if ((iint->flags & IMA_APPRAISAL_OPT) &&
>> + (rc == INTEGRITY_XATTR_NOTSUPP ||
>> + rc == INTEGRITY_IMA_NOLABEL))
>> + return 0;
>> + else
>> + return -EACCES;
>
> I think there is problem here. "appraise_type=optional" can be specified
> per rule/hook. So two different hooks can specify two different rules.
>
> appraise func=MMAP_CHECK appraise_type=optional
> appraise func=BPRM_CHECK
>
> I think if a file is first mmaped(), then appraisal will take place and
> IMA_APPRAISAL_OPT will be set in iint->flags.
>
> Later when BPRM_CHECK hook gets executed, and it will return success
> based on IMA_APPRAISAL_OPT even if there was no label. And that's not
> what exec() expects.
>
> So storing IMA_APPRAISAL_OPT in iint->flags seems wrong (espectially as
> part of IMA_ACTION_FLAGS bits). I think only bits which are valid
> across all rules/hooks should be stored here.
>
> Any property which is hook/rule specific should either not be stored
> or should be stroed in hook specific property area.
>
> We don't have enough space to store more hook specific properties, so
> I will explore the option of passing around this flag when hook is being
> executed and then discard it.
>
Hi,
I think there is no need to store optional in iint->flags.
Just test "action" which is returned by ima_get_action().
Then it will be rule specific...
- Dmitry
> Thanks
> Vivek
>
>> + }
>> return 0;
>> }
>>
>> diff --git a/security/integrity/ima/ima_policy.c
>> b/security/integrity/ima/ima_policy.c
>> index 4adcd0f..fd92dc3d4 100644
>> --- a/security/integrity/ima/ima_policy.c
>> +++ b/security/integrity/ima/ima_policy.c
>> @@ -598,6 +598,8 @@ static int ima_parse_rule(char *rule, struct
>> ima_rule_entry *entry)
>> ima_log_string(ab, "appraise_type", args[0].from);
>> if ((strcmp(args[0].from, "imasig")) == 0)
>> entry->flags |= IMA_DIGSIG_REQUIRED;
>> + else if ((strcmp(args[0].from, "optional")) == 0)
>> + entry->flags |= IMA_APPRAISAL_OPT;
>> else
>> result = -EINVAL;
[PATCH] intel_idle: set the state_tables array into __initdata to save mem
Currently, in intel_idle.c, there are 5 state_tables array, every
array size is sizeof(struct cpuidle_state) * CPUIDLE_STATE_MAX.
But after intel_idle_probe(), just only one array is useful.
Here we can just define one static state_table, and initialize it
in intel_idle_probe(), and set other data state_tables as __initdata.
It can save about 3K, which also benefits mobile devices.
Signed-off-by: liu chuansheng
---
drivers/idle/intel_idle.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 5d66750..0642bfe 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -99,7 +99,7 @@ static int intel_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index);
static int intel_idle_cpu_init(int cpu);
-static struct cpuidle_state *cpuidle_state_table;
+static struct cpuidle_state cpuidle_state_table[CPUIDLE_STATE_MAX];
/*
* Set this flag for states where the HW flushes the TLB for us
@@ -124,7 +124,7 @@ static struct cpuidle_state *cpuidle_state_table;
* which is also the index into the MWAIT hint array.
* Thus C0 is a dummy.
*/
-static struct cpuidle_state nehalem_cstates[CPUIDLE_STATE_MAX] = {
+static struct cpuidle_state nehalem_cstates[CPUIDLE_STATE_MAX] __initdata = {
{
.name = "C1-NHM",
.desc = "MWAIT 0x00",
@@ -157,7 +157,7 @@ static struct cpuidle_state
nehalem_cstates[CPUIDLE_STATE_MAX] = {
.enter = NULL }
};
-static struct cpuidle_state snb_cstates[CPUIDLE_STATE_MAX] = {
+static struct cpuidle_state snb_cstates[CPUIDLE_STATE_MAX] __initdata = {
{
.name = "C1-SNB",
.desc = "MWAIT 0x00",
@@ -197,7 +197,7 @@ static struct cpuidle_state snb_cstates[CPUIDLE_STATE_MAX]
= {
.enter = NULL }
};
-static struct cpuidle_state ivb_cstates[CPUIDLE_STATE_MAX] = {
+static struct cpuidle_state ivb_cstates[CPUIDLE_STATE_MAX] __initdata = {
{
.name = "C1-IVB",
.desc = "MWAIT 0x00",
@@ -237,7 +237,7 @@ static struct cpuidle_state ivb_cstates[CPUIDLE_STATE_MAX]
= {
.enter = NULL }
};
-static struct cpuidle_state hsw_cstates[CPUIDLE_STATE_MAX] = {
+static struct cpuidle_state hsw_cstates[CPUIDLE_STATE_MAX] __initdata = {
{
.name = "C1-HSW",
.desc = "MWAIT 0x00",
@@ -277,7 +277,7 @@ static struct cpuidle_state hsw_cstates[CPUIDLE_STATE_MAX]
= {
.enter = NULL }
};
-static struct cpuidle_state atom_cstates[CPUIDLE_STATE_MAX] = {
+static struct cpuidle_state atom_cstates[CPUIDLE_STATE_MAX] __initdata = {
{
.name = "C1E-ATM",
.desc = "MWAIT 0x00",
@@ -504,7 +504,12 @@ static int intel_idle_probe(void)
pr_debug(PREFIX "MWAIT substates: 0x%x\n", mwait_substates);
icpu = (const struct idle_cpu *)id->driver_data;
- cpuidle_state_table = icpu->state_table;
+ /* Copy the icpu->state_table into cpuidle_state_table,
+* The pointing array by icpu->state_table is with __initdata,
+* which will be freed after kernel init ending.
+*/
+ memcpy(cpuidle_state_table, icpu->state_table,
+ sizeof(cpuidle_state_table));
if (boot_cpu_has(X86_FEATURE_ARAT)) /* Always Reliable APIC Timer */
lapic_timer_reliable_states = LAPIC_TIMER_ALWAYS_RELIABLE;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH linux-next] procfs: fix rcu-lock/unlock in proc_reg_open() and proc_reg_release()
fix for a21813be23329e2788164eab532e79cb0e513cfc (linux-next)
"procfs: improve scaling in proc"
Signed-off-by: Konstantin Khlebnikov
Cc: Nathan Zimmer
Cc: Andrew Morton
---
fs/proc/inode.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index 64d..073846c 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -352,7 +352,7 @@ static int proc_reg_open(struct inode *inode, struct file
*file)
atomic_inc(&pde->pde_users);
open = fops->open;
release = fops->release;
- rcu_read_lock();
+ rcu_read_unlock();
if (open)
rv = open(inode, file);
@@ -400,6 +400,7 @@ static int proc_reg_release(struct inode *inode, struct
file *file)
rcu_read_lock();
fops = rcu_dereference(pde->proc_fops);
if (!fops) {
+ rcu_read_unlock();
/*
* Can't simply exit, __fput() will think that everything is OK,
* and move on to freeing struct file. remove_proc_entry() will
--
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 LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Thu, 2013-03-07 at 03:17 +, Will Deacon wrote: > > I looked and couldn't see an existing 64 bit xchg, was I looking in the > > wrong place? Ah, wait, I see atomic64_xchg now. But that needs an > > atomic64_t while I have a xen_ulong_t (which == 64 bits on ARM). This is > > a kernel<->hypervisor ABI so I can't just change it to an atomic64_t. I > > suppose I could cast (see below, untested) but that seems rather icky. > > You can play some container_of tricks, like we do in cmpxchg64 to get this > right. Alternatively, we could look at an xchg8 implementation which some > other architectures have (although they seem to be 64-bit machines). I went with the container of trick + appropriate Kconfig depends and sent a patch out a couple of seconds ago. Thanks for your help/advice! Ian. -- 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: Byteorder conditional compilation problems
On Wed, Mar 6, 2013 at 6:37 PM, Linus Torvalds
wrote:
> On Wed, Mar 6, 2013 at 8:43 AM, David Howells wrote:
>> Scripting a change from "defined(__XXX_ENDIAN)" to
>> "(__XXX_ENDIAN==__BYTEORDER)"
>> should be easy to script.
>
> How about we just make the rule be that we shouldn't test __xyz_ENDIAN
> at all, and instead always use CONFIG_xyz_ENDIAN, which isn't
> ambiguous. And then have the exporter of the uapi header files just
> sed-script that into __xyz_ENDIAN == __BYTEORDER.
I was going to suggest a checkpatch test, but your suggestion is a
better solution.
Still, we may want the checkpatch test, to make sure no one explicitly does the
moronic byte order check.
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/
[PATCH] davinci: vpif: Fix module build for capture and display
From: Lad, Prabhakar
export the symbols which are used by two modules vpif_capture and
vpif_display.
This patch fixes following error:
ERROR: "ch_params" [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: "vpif_ch_params_count" [drivers/media/platform/davinci/vpif_display.ko]
undefined!
ERROR: "vpif_base" [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: "ch_params" [drivers/media/platform/davinci/vpif_capture.ko] undefined!
ERROR: "vpif_ch_params_count" [drivers/media/platform/davinci/vpif_capture.ko]
undefined!
ERROR: "vpif_base" [drivers/media/platform/davinci/vpif_capture.ko] undefined!
make[1]: *** [__modpost] Error 1
Reported-by: Sekhar Nori
Signed-off-by: Lad, Prabhakar
---
drivers/media/platform/davinci/vpif.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif.c
b/drivers/media/platform/davinci/vpif.c
index 28638a8..8fbb4a2 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -44,6 +44,8 @@ static struct resource*res;
spinlock_t vpif_lock;
void __iomem *vpif_base;
+EXPORT_SYMBOL(vpif_base);
+
struct clk *vpif_clk;
/**
@@ -220,8 +222,10 @@ const struct vpif_channel_config_params ch_params[] = {
.stdid = V4L2_STD_625_50,
},
};
+EXPORT_SYMBOL(ch_params);
const unsigned int vpif_ch_params_count = ARRAY_SIZE(ch_params);
+EXPORT_SYMBOL(vpif_ch_params_count);
static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
{
--
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/
Re: virtual irq isssue - regmap_irq
On Thu, Mar 07, 2013 at 12:27:52PM +0530, Ashish Jangam wrote: > In regmap_irq if irq_base is unknown then regmap creates virq starting from 0 > and it seems that in kernel 3.8 virq 0 usage is not permitted, since during > irq > registration kernel throws a message "error: irq_desc already associated". > I'm not sure if this requires fix in regmap_irq or kernel, can you please > comment on this? This is a bug in your platform which will affect anything using a linear domain. The platform isn't setting up its interrupts correctly so that the core knows that those interrupts are reserved, ideally the platform would just use domains for everything but at least irq_alloc_decs() needs to know what is going on. signature.asc Description: Digital signature
Re: [PATCH 1/1 v4] pwm_bl: Add support for backlight enable regulator
On Wed, Mar 06, 2013 at 09:17:18AM -0800, Andrew Chew wrote:
[...]
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index 069983c..ff98cdd 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -20,10 +20,13 @@
> #include
> #include
> #include
> +#include
>
> struct pwm_bl_data {
> struct pwm_device *pwm;
> struct device *dev;
> + struct regulator*en_supply;
Can this be renamed to enable_supply to match the DT property name?
> + boolen_supply_enabled;
This boolean can be dropped. As discussed in a previous thread, the
pwm-backlight driver shouldn't need to know about any other uses of the
regulator.
> +static void pwm_backlight_enable(struct backlight_device *bl)
> +{
> + struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
> +
> + pwm_enable(pb->pwm);
> +
> + if (pb->en_supply && !pb->en_supply_enabled) {
> + if (regulator_enable(pb->en_supply) != 0)
> + dev_warn(&bl->dev, "Failed to enable regulator");
> + else
> + pb->en_supply_enabled = true;
> + }
> +}
> +
> +static void pwm_backlight_disable(struct backlight_device *bl)
> +{
> + struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
> +
> + if (pb->en_supply && pb->en_supply_enabled) {
> + if (regulator_disable(pb->en_supply) != 0)
> + dev_warn(&bl->dev, "Failed to disable regulator");
> + else
> + pb->en_supply_enabled = false;
> + }
> +
> + pwm_disable(pb->pwm);
> +}
Alex already brought this up: shouldn't the sequences be reversed. That
is, when enabling the backlight, turn on the regulator first, then
enable the PWM. When disabling, disable the PWM first, then turn off the
regulator?
> @@ -213,6 +238,13 @@ static int pwm_backlight_probe(struct platform_device
> *pdev)
> pb->exit = data->exit;
> pb->dev = &pdev->dev;
>
> + pb->en_supply = devm_regulator_get(&pdev->dev, "enable");
> + if (IS_ERR(pb->en_supply)) {
> + ret = PTR_ERR(pb->en_supply);
> + pb->en_supply = NULL;
> + goto err_alloc;
> + }
This effectively makes the regulator mandatory, so the board files that
use pwm-backlight need to be updated or otherwise will break.
Thierry
pgpoh9e9w6I_4.pgp
Description: PGP signature
Re: upgrade to 3.8.1 : BUG Scheduling while atomic in bonding driver:
Michael Wang wrote: > On 03/02/2013 01:21 PM, Linda Walsh wrote: > Update -- it *used* to stop the messages in 3.6.7. > > It no longer stops the messages in 3.8.1 -- (and isn't present by > default -- tried > adding the unlock/lock -- no difference. > > Weird. *sigh* > > Hi, Linda > > Do you have the BUG log after applied this patch? > > bond->lock seems to be the only one who will add the preempt_count, the > patch should works... > > And have you tried the 3.9.0-rc1, is the issue still exist? > > Regards, > Michael Wang --- What do you mean by 'bug log', do you mean kernel log --- including the log from boot, in case anything weird pops out, but bug happens edited out stretch of repetitious looking stuff that was unlikely to be related... [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.8.1-Isht-Van (law@Ishtar) (gcc version 4.6.2 (SUSE Linux) ) #6 SMP PREEMPT Fri Mar 1 20:29:32 PST 2013 [0.00] Command line: BOOT_IMAGE=381-Isht-Van rw root=/dev/sdc1 root=/dev/sdc1 showopts console=ttyS0,115200n8 console=tty0 elevator=cfq pcie_aspm=force pcie_ports=native reboot=bios [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009] usable ... [0.00] BIOS-e820: [mem 0x0001-0x000c2fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: Dell Inc. PowerEdge T610/0CX0R0, BIOS 6.1.0 10/18/2011 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0xc3 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: ... [0.00] EC000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask FF8000 write-back ... [0.00] 7 base 0C mask FFC000 write-back [0.00] 8 disabled [0.00] 9 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: update [mem 0xd000-0x] usable ==> reserved [0.00] e820: last_pfn = 0xcf379 max_arch_pfn = 0x4 [0.00] initial memory mapped: [mem 0x-0x1fff] [0.00] Base memory trampoline at [88098000] 98000 size 24576 [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0xcf378fff] [0.00] [mem 0x-0xbfff] page 1G [0.00] [mem 0xc000-0xcf1f] page 2M [0.00] [mem 0xcf20-0xcf378fff] page 4k [0.00] kernel direct mapping tables up to 0xcf378fff @ [mem 0x1fffd000-0x1fff] [0.00] init_memory_mapping: [mem 0x1-0xc2fff] [0.00] [mem 0x1-0xb] page 1G [0.00] [mem 0xc-0xc2fff] page 2M [0.00] kernel direct mapping tables up to 0xc2fff @ [mem 0xcf377000-0xcf378fff] [0.00] ACPI: RSDP 000f1170 00024 (v02 DELL ) ... [0.00] ACPI: TCPA cf3b3f34 00064 (v02 DELL PE_SC3 0001 DELL 0001) [0.00] ACPI: SSDT cf3b7000 037A4 (v01 INTEL PPM RCM 8001 INTL 20061109) [0.00] ACPI: Local APIC address 0xfee0 ... [0.00] SRAT: PXM 2 -> APIC 0x14 -> Node 1 [0.00] SRAT: Node 1 PXM 2 [mem 0x-0xcfff] [0.00] SRAT: Node 1 PXM 2 [mem 0x1-0x62fff] [0.00] SRAT: Node 0 PXM 1 [mem 0x63000-0xc2fff] [0.00] NUMA: Node 1 [mem 0x-0xcfff] + [mem 0x1-0x62fff] -> [mem 0x-0x62fff] [0.00] Initmem setup node 0 [mem 0x63000-0xc2fff] [0.00] NODE_DATA [mem 0xc2fffd000-0xc2fff] [0.00] Initmem setup node 1 [mem 0x-0x62fff] [0.00] NODE_DATA [mem 0x62fffd000-0x62fff] [0.00] [ea00-ea0018bf] PMD -> [880617e0-88062fdf] on node 1 [0.00] [ea0018c0-ea0030bf] PMD -> [880c1760-880c2f5f] on node 0 [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x1-0xc2fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 1: [mem 0x1000-0x0009] [0.00] node 1: [mem 0x0010-0xcf378fff] [0.00] node 1: [mem 0x1-0x62fff] [0.00] node 0: [mem 0x63000-0xc2fff] [0.00] On node 0 totalpages: 6291456 [0.00] Normal zone: 98304 pages used for memmap [0.00] Normal zone: 6193152 pages, LIFO batch:31 [
Re: [PATCH] virtio-spec: Define virtio-mmio registers as LE
Pawel Moll writes: > On Tue, 2013-03-05 at 00:11 +, Rusty Russell wrote: >> Pawel Moll writes: >> > On Fri, 2013-03-01 at 11:21 +, Marc Zyngier wrote: >> >> > Having said that, Rusty was contemplating enforcing LE config space in >> >> > the new PCI layout... >> >> >> >> I wouldn't complain about that, and would like to see a similar thing on >> >> MMIO. >> > >> > Wherever PCI goes, MMIO follows :-) >> >> Yes, but if you switch from 'guest-endian' to 'little-endian' how will >> you tell? For PCI, we'd detect it by using the new layout. > > The version register/value. At some point of time there will be a > new(ish) MMIO layout anyway to deal with 64-bit addresses, replacing the > ring page number with two 32-bit hi/lo physical address registers. This > was discussed not long after the driver got merged... As long as you have a plan for older guests... >> I'd rather you specify MMIO as little endian, and we fix the kernel >> config accessors to be endian aware (ie. 8, 16, 32, 64-bit accessors). >> Since noone BE is using MMIO right now, it's safe... > > That's absolutely fine with me, however I don't see anything I could do > in the virtio_mmio driver and spec - the virtio_config_ops specifies > get/set as void * operations and I simply do byte-by-byte copy. Have I > missed some config/endianess/PCI related discussion? Yes, that's exactly what I mean, they'd have to be split into 8/16/32/64 accessors. Which would do byte-by-byte for PCI. The spec can simply be updated. 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 2/7] tick: Convert broadcast cpu bitmaps to cpumask_var_t
Thomas Gleixner writes: > Signed-off-by: Thomas Gleixner > Cc: Rusty Russell > --- > kernel/time/tick-broadcast.c | 86 > +-- > kernel/time/tick-common.c|1 > kernel/time/tick-internal.h |3 + > 3 files changed, 46 insertions(+), 44 deletions(-) > > Index: tip/kernel/time/tick-broadcast.c > === > --- tip.orig/kernel/time/tick-broadcast.c > +++ tip/kernel/time/tick-broadcast.c > @@ -28,9 +28,8 @@ > */ > > static struct tick_device tick_broadcast_device; > -/* FIXME: Use cpumask_var_t. */ > -static DECLARE_BITMAP(tick_broadcast_mask, NR_CPUS); > -static DECLARE_BITMAP(tmpmask, NR_CPUS); > +static cpumask_var_t tick_broadcast_mask; > +static cpumask_var_t tmpmask; > static DEFINE_RAW_SPINLOCK(tick_broadcast_lock); > static int tick_broadcast_force; Thanks, this is a nice cleanup. 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/
virtual irq isssue - regmap_irq
Hi, In regmap_irq if irq_base is unknown then regmap creates virq starting from 0 and it seems that in kernel 3.8 virq 0 usage is not permitted, since during irq registration kernel throws a message "error: irq_desc already associated". I'm not sure if this requires fix in regmap_irq or kernel, can you please comment on this? Thanks, Ashish -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] of: dma: make #dma-cells optional
On Wed, Feb 27, 2013 at 06:57:57PM -0600, Rob Herring wrote: > From: Rob Herring > > For controllers with no requests/clients (memory to memory only), the Change log is truncated... > > Signed-off-by: Rob Herring > Cc: Vinod Koul > Cc: Dan Williams > Cc: Grant Likely > --- > Documentation/devicetree/bindings/dma/dma.txt |7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/dma/dma.txt > b/Documentation/devicetree/bindings/dma/dma.txt > index 8f504e6..d388f06 100644 > --- a/Documentation/devicetree/bindings/dma/dma.txt > +++ b/Documentation/devicetree/bindings/dma/dma.txt > @@ -8,9 +8,10 @@ controller. > * DMA controller > > Required property: > -- #dma-cells:Must be at least 1. Used to provide DMA > controller > - specific information. See DMA client binding below for > - more details. > +- #dma-cells:Required for controllers with requests. > Optional for > + memory to memory only DMA controllers. Must be at least > + 1. Used to provide DMA controller specific information. > + See DMA client binding below for more details. > > Optional properties: > - dma-channels: Number of DMA channels supported by the controller. > -- > 1.7.10.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
On Wed, 2013-03-06 at 23:47 -0700, Stephen Warren wrote: > On 03/06/2013 05:40 PM, Joe Perches wrote: > > Which is why I showed the whole thing in a single patch. > > No worries if it's simply to increase the patch count... > > I'm not sure what showed refers to? The changes I posted with the suggestion https://lkml.org/lkml/2013/3/6/468 > I guess if I squashed /everything/ into a single commit (i.e. the change > to the Tegra section in MAINTAINERS too) then there wouldn't be any > bisect issues. I really don't care about patch count. The reason for >1 > patch is that there's often push-back if doing logically separate things > (adding N: feature, modifying a MAINTAINERS entry to use it, removing > part of K: feature) in a single patch... Not from me anyway. I think it's a single logical change and it's trivial too. No worries whatever happens. -- 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 V4] ARM: dts: add minimal DT support for DevKit8000.
Hi, On 03/06/2013 06:53 PM, Tony Lindgren wrote: > * Anil Kumar [130305 18:40]: >> Hi Tony, >> From: linux-arm-kernel [mailto:linux-arm-kernel- boun...@lists.infradead.org] On Behalf Of Anil Kumar Sent: Wednesday, February 27, 2013 8:03 AM To: devicetree-disc...@lists.ozlabs.org; linux-o...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org Cc: li...@arm.linux.org.uk; Cousson, Benoit; Tony Lindgren; Grant Likely; Anil Kumar; tho...@tomweber.eu Subject: Re: FW: [PATCH V4] ARM: dts: add minimal DT support for DevKit8000. Hi, > > DevKit8000 is a beagle board clone from Timll, sold by > armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D, > S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and > JTAG interface. > > This patch adds the basic DT support for devkit8000. At this time, Information > of twl4030 (PMIC), MMC1, I2C1 and leds are added. > > Signed-off-by: Anil Kumar > Tested-by: Thomas Weber Gentle Ping. As there are no review comments on this patch, Could you please pull this patch ? >> >> Gentle Ping. >> >> This patch also got Reviewed-by: Manish Badarkhe >> and as patch "ARM: dts: omap3-devkit8000: Enable audio support" has already >> got >> "Acked-by: Peter Ujfalusi " but it is on the >> top of this patch. >> So, Could you please pull this patch in one of your omap branch? or >> you want me to >> do rebase this patch on top of v3.9-rc1 ? > > Let's wait for Benoit to queue it as he has a bunch of .dts changes already > applied. Too bad we missed v3.9 merge window for those, but hopefully > we can get them queued early for v3.10. Yep, sorry for having missed 3.9, I was a little bit sick at the wrong moment :-( I'm starting queuing the pending patches, and should have enough to push to you just after Linaro Connect. Regards, Benoit -- 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] fix a typo in afkey
From: Junwei Zhang
Signed-off-by: Martin Zhang
---
net/key/af_key.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 556fdaf..8555f33 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -2201,7 +2201,7 @@ static int pfkey_spdadd(struct sock *sk, struct sk_buff
*skb, const struct sadb_
XFRM_POLICY_BLOCK : XFRM_POLICY_ALLOW);
xp->priority = pol->sadb_x_policy_priority;
- sa = ext_hdrs[SADB_EXT_ADDRESS_SRC-1],
+ sa = ext_hdrs[SADB_EXT_ADDRESS_SRC-1];
xp->family = pfkey_sadb_addr2xfrm_addr(sa, &xp->selector.saddr);
if (!xp->family) {
err = -EINVAL;
@@ -2214,7 +2214,7 @@ static int pfkey_spdadd(struct sock *sk, struct sk_buff
*skb, const struct sadb_
if (xp->selector.sport)
xp->selector.sport_mask = htons(0x);
- sa = ext_hdrs[SADB_EXT_ADDRESS_DST-1],
+ sa = ext_hdrs[SADB_EXT_ADDRESS_DST-1];
pfkey_sadb_addr2xfrm_addr(sa, &xp->selector.daddr);
xp->selector.prefixlen_d = sa->sadb_address_prefixlen;
@@ -2315,7 +2315,7 @@ static int pfkey_spddelete(struct sock *sk, struct
sk_buff *skb, const struct sa
memset(&sel, 0, sizeof(sel));
- sa = ext_hdrs[SADB_EXT_ADDRESS_SRC-1],
+ sa = ext_hdrs[SADB_EXT_ADDRESS_SRC-1];
sel.family = pfkey_sadb_addr2xfrm_addr(sa, &sel.saddr);
sel.prefixlen_s = sa->sadb_address_prefixlen;
sel.proto = pfkey_proto_to_xfrm(sa->sadb_address_proto);
@@ -2323,7 +2323,7 @@ static int pfkey_spddelete(struct sock *sk, struct
sk_buff *skb, const struct sa
if (sel.sport)
sel.sport_mask = htons(0x);
- sa = ext_hdrs[SADB_EXT_ADDRESS_DST-1],
+ sa = ext_hdrs[SADB_EXT_ADDRESS_DST-1];
pfkey_sadb_addr2xfrm_addr(sa, &sel.daddr);
sel.prefixlen_d = sa->sadb_address_prefixlen;
sel.proto = pfkey_proto_to_xfrm(sa->sadb_address_proto);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
On 03/06/2013 05:40 PM, Joe Perches wrote: > On Wed, 2013-03-06 at 17:34 -0700, Stephen Warren wrote: >> On 03/06/2013 05:30 PM, Joe Perches wrote: >>> On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote: From: Stephen Warren This reverts most of eb90d08 "get_maintainer: allow keywords to match filenames"; all except the parts that are required to implement the new N: entry type. >>> >>> Just combine patches 1 and 3 into a single patch. >> >> That would break bisectability; using MAINTAINERS after applying a >> squashed 1+3 but without patch 2 applied would not operate as desired. > > > > Which is why I showed the whole thing in a single patch. > No worries if it's simply to increase the patch count... I'm not sure what showed refers to? I guess if I squashed /everything/ into a single commit (i.e. the change to the Tegra section in MAINTAINERS too) then there wouldn't be any bisect issues. I really don't care about patch count. The reason for >1 patch is that there's often push-back if doing logically separate things (adding N: feature, modifying a MAINTAINERS entry to use it, removing part of K: feature) in a single patch... -- 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 00/10] dmatest: update the module to use debugfs
On Mon, Mar 04, 2013 at 11:09:24AM +0200, Andy Shevchenko wrote: > The first approach to get dmatest module more flexible and easier to play > with. > The amount of patches could be reduced, but I would like to get a comments > first on smaller pieces. The entire series creates dmatest.txt file in the > Documentation folder. Similar description is scattered through the commit > messages. > > Module was tested on Intel Medfield and Lynxpoint systems with dw_dmac DMA > controller embedded. Overall the series looks good. I think it can applied in this form as well. > > Andy Shevchenko (10): > dmatest: cancel thread immediately when asked for > dmatest: allocate memory for pq_coefs from heap > dmatest: create dmatest_info to keep test parameters > dmatest: move dmatest_channels and nr_channels to dmatest_info > dmatest: split test parameters to separate structure > dmatest: run test via debugfs > dmatest: return actual state in 'run' file > dmatest: define MAX_ERROR_COUNT constant > dmatest: gather test results in the linked list > dmatest: append verify result to results > > Documentation/dmatest.txt | 81 + > drivers/dma/dmatest.c | 887 > +++--- > 2 files changed, 832 insertions(+), 136 deletions(-) > create mode 100644 Documentation/dmatest.txt > > -- > 1.8.2.rc0.22.gb3600c3 > -- 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 v9 3/9] ARM: edma: add AM33XX support to the private EDMA API
On Wed, Mar 6, 2013 at 6:15 PM, Matt Porter wrote:
> Adds support for parsing the TI EDMA DT data into the
> required EDMA private API platform data. Enables runtime
> PM support to initialize the EDMA hwmod. Adds AM33XX EDMA
> crossbar event mux support. Enables build on OMAP.
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> +static int edma_xbar_event_map(struct device *dev,
> + struct device_node *node,
> + struct edma_soc_info *pdata, int len)
> +{
> + int ret = 0;
> + int i;
> + struct resource res;
> + void *xbar;
> + const s16 (*xbar_chans)[2];
> + u32 shift, offset, mux;
> +
> + xbar_chans = devm_kzalloc(dev,
> + len/sizeof(s16) + 2*sizeof(s16),
> + GFP_KERNEL);
> + if (!xbar_chans)
> + return -ENOMEM;
> +
> + ret = of_address_to_resource(node, 1, &res);
> + if (ret)
> + return -EIO;
> +
> + xbar = devm_ioremap(dev, res.start, resource_size(&res));
> + if (!xbar)
> + return -ENOMEM;
> +
> + ret = edma_of_read_u32_to_s16_array(node,
> + "ti,edma-xbar-event-map",
> + (s16 *)xbar_chans,
> + len/sizeof(u32));
> + if (ret)
> + return -EIO;
> +
> + for (i = 0; xbar_chans[i][0] != -1; i++) {
> + shift = (xbar_chans[i][1] % 4) * 8;
Looks like shift = (xbar_chans[i][1] & 0x03) << 3;
> + offset = xbar_chans[i][1] >> 2;
> + offset <<= 2;
Is it offset = xbar_chans[i][1] & 0xfffc; ?
> + mux = readl((void *)((u32)xbar + offset));
> + mux &= ~(0xff << shift);
> + mux |= xbar_chans[i][0] << shift;
> + writel(mux, (void *)((u32)xbar + offset));
> + }
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] tmpfs: fix mempolicy object leaks
Hi Hugh, On 03/06/2013 03:40 AM, Hugh Dickins wrote: On Mon, 4 Mar 2013, Will Huck wrote: Could you explain me why shmem has more relationship with mempolicy? It seems that there are many codes in shmem handle mempolicy, but other components in mm subsystem just have little. NUMA mempolicy is mostly handled in mm/mempolicy.c, which services the mbind, migrate_pages, set_mempolicy, get_mempolicy system calls: which govern how process memory is distributed across NUMA nodes. mm/shmem.c is affected because it was also found useful to specify mempolicy on the shared memory objects which may back process memory: that includes SysV SHM and POSIX shared memory and tmpfs. mm/hugetlb.c contains some mempolicy handling for hugetlbfs; fs/ramfs is kept minimal, so nothing in there. Those are the memory-based filesystems, where NUMA mempolicy is most natural. The regular filesystems could support shared mempolicy too, but that would raise more awkward design questions. I found that if mbind several processes to one node and almost exhaust memory, processes will just stuck and no processes make progress or be killed. Is it normal? Hugh -- 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] gpio: gpio-ich: fix ichx_gpio_check_available() return what callers expect
On Thu, Mar 07, 2013 at 04:23:56AM +0100, Linus Walleij wrote:
> Hi Mika,
>
> On Wed, Feb 27, 2013 at 4:25 PM, Mika Westerberg
> wrote:
>
> > -static int ichx_gpio_check_available(struct gpio_chip *gpio, unsigned nr)
> > +static bool ichx_gpio_check_available(struct gpio_chip *gpio, unsigned nr)
> > {
> > - return (ichx_priv.use_gpio & (1 << (nr / 32))) ? 0 : -ENXIO;
> > + return ichx_priv.use_gpio & (1 << (nr / 32));
> > }
>
> Strictly speaking what you're returning there is not a bool.
> Shouldn't it be:
>
> return !!(ichx_priv.use_gpio & (1 << (nr / 32)));
>
> ?
A C reference manual says something like: When converting any scalar value
to type _Bool, all nonzero values are converted to 1, while zero values are
converted to 0 (1 being canonical value for true).
However, I'm happy to send a patch changing this if you like so (Grant
applied the patch already).
--
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: use after free in sysfs_find_dirent
On Thu, Mar 07, 2013 at 02:02:30PM +0800, Greg Kroah-Hartman wrote: > On Thu, Mar 07, 2013 at 12:28:54AM -0500, Dave Jones wrote: > > general protection fault: [#1] PREEMPT SMP > > Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock bnep fuse > > rfcomm hidp l2tp_ppp l2tp_core 8021q garp mrp dlci pppoe pppox ppp_generic > > slhc scsi_transport_iscsi rose caif_socket caif can_raw bridge af_key > > can_bcm llc2 stp can netrom phonet af_rxrpc nfnetlink ipt_ULOG x25 rds > > irda crc_ccitt ax25 ipx p8023 p8022 decnet atm appletalk psnap llc nfc > > lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack > > nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek > > snd_hda_intel snd_hda_codec snd_pcm btusb snd_page_alloc bluetooth > > snd_timer snd microcode rfkill usb_debug serio_raw pcspkr edac_core > > soundcore vhost_net tun r8169 macvtap macvlan mii kvm_amd kvm > > CPU 0 > > Pid: 23476, comm: trinity-child1 Not tainted 3.9.0-rc1+ #69 Gigabyte > > Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H > > RIP: 0010:[] [] > > sysfs_find_dirent+0x47/0xf0 > > RSP: 0018:88000585bd68 EFLAGS: 00010202 > > RAX: 94be55f6 RBX: 6b6b6b6b6b6b6b6b RCX: 6b6b6b6b > > RDX: RSI: RDI: > > RBP: 88000585bd88 R08: R09: > > R10: R11: R12: 0029c161 > > R13: 8800a8918288 R14: R15: 0009 > > FS: 7fa12651e740() GS:88012ae0() > > knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 0010 CR3: 1a128000 CR4: 07f0 > > DR0: DR1: DR2: > > DR3: DR6: 0ff0 DR7: 0400 > > Process trinity-child1 (pid: 23476, threadinfo 88000585a000, task > > 8800cd454920) > > Stack: > > 880128edc1e8 8800a8918250 fffe 88012265f430 > > 88000585bdb8 812357cd 8800a8918250 8801226514d0 > > 88000585bf38 88000585bde8 811bb30d > > Call Trace: > > [] sysfs_lookup+0x6d/0xe0 > > [] lookup_real+0x1d/0x60 > > [] __lookup_hash+0x38/0x50 > > [] lookup_hash+0x19/0x20 > > [] kern_path_create+0x93/0x170 > > [] ? getname_flags.part.32+0x86/0x150 > > [] user_path_create+0x4a/0x70 > > [] sys_mkdirat+0x39/0xe0 > > [] system_call_fastpath+0x16/0x1b > > Code: 00 48 8b 9f 88 00 00 00 f6 c4 0f 0f 95 c0 48 85 f6 0f 95 c2 38 d0 75 > > 79 4c 89 ee 4c 89 f7 e8 91 ef ff ff 41 89 c4 48 85 db 74 1d <8b> 4b 28 41 > > 39 cc 74 21 44 89 e0 29 c8 83 f8 00 7c 2c 74 45 48 > > RIP [] sysfs_find_dirent+0x47/0xf0 > > RSP > > ---[ end trace 4ba97703eaafbb8b ]--- > > Any hint as to what was happening here when this crashed? Given I haven't seen this (or the other sysfs bug) before today, I'm going to assume it's due to one of the features I added to trinity today. 1. Instead of just relying on filenames it gathers from sysfs on startup, it now also generates mangled variants of them. (Appending a / followed by garbage for eg) 2. When a syscall wants a page of memory, it now sometimes hands it one filled with malformed UTF-8 characters. 3. A combo of the above, that garbage appended to a pathname may be unicode junk. Could be some of those that caused these bugs. I just retried rerunning the test a few times. Every time I run for a while I end up with different crashes. It's raining bugs over here. (Here's another sysfs one below) Running 'trinity -c mkdirat -V /sys' doesn't seem to trigger it, so it's an interaction with something else maybe. The one common thing here is that 6b6b6b6b6b6b6b6b showing up in every trace, suggesting a use-after-free bugs. They may all be different manifestations of the same underlying bug if there's some kind of refcounting bug perhaps. (This may also be why telling it to do just mkdirat isn't triggering it, if it's racing with some other operation) Getting this stuff easily reproducable is pretty hard. The best I can offer right now is that it seems to trigger *something* bad quickly, even if it's not necessarily the exact same trace. Dave general protection fault: [#1] PREEMPT SMP Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock fuse bnep hidp dlci 8021q garp mrp bridge stp l2tp_ppp l2tp_core scsi_transport_iscsi rfcomm ipt_ULOG nfnetlink nfc rose af_key appletalk can_raw can_bcm netrom x25 ipx caif_socket af_rxrpc rds p8023 psnap p8022 ax25 irda pppoe decnet can pppox llc2 caif crc_ccitt ppp_generic slhc atm phonet llc lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm btusb bluetooth snd_page_alloc snd_timer microcode snd serio_raw pcspkr usb_debug
[RESEND 2/2] ARM: davinci: da850: add tps6507x regulator DT data
Add tps6507x regulator device tree data to da850-evm by
adding regulator consumers with tightened constraints
and regulator-name.TPS6507x regulator handle can be obtained
by using this regulator name.
Regulator constraints are added as per da850 board file.
Regulator names are given as per maximum output voltage the
regulator is capable to provide.
for e.g. regulator name for dcdc1 is "VDCDC1_3.3V".
Also, add tps6507x PMIC I2C slave device under I2C0 node.
Tested on da850-evm.
Signed-off-by: Vishwanathrao Badarkhe, Manish
---
:100644 100644 f712fb6... d1d091b... M arch/arm/boot/dts/da850-evm.dts
arch/arm/boot/dts/da850-evm.dts | 63 +++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index f712fb6..d1d091b 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -35,6 +35,10 @@
clock-frequency = <10>;
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins>;
+
+ tps: tps@48 {
+ reg = <0x48>;
+ };
};
wdt: wdt@1c21000 {
status = "okay";
@@ -45,4 +49,63 @@
pinctrl-names = "default";
pinctrl-0 = <&nand_cs3_pins>;
};
+ vbat: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vbat";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-boot-on;
+ };
+};
+
+/include/ "tps6507x.dtsi"
+
+&tps {
+ vdcdc1_2-supply = <&vbat>;
+ vdcdc3-supply = <&vbat>;
+ vldo1_2-supply = <&vbat>;
+
+ regulators {
+ vdcdc1_reg: regulator@0 {
+ regulator-name = "VDCDC1_3.3V";
+ regulator-min-microvolt = <315>;
+ regulator-max-microvolt = <345>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdcdc2_reg: regulator@1 {
+ regulator-name = "VDCDC2_3.3V";
+ regulator-min-microvolt = <171>;
+ regulator-max-microvolt = <345>;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,defdcdc_default = <1>;
+ };
+
+ vdcdc3_reg: regulator@2 {
+ regulator-name = "VDCDC3_1.2V";
+ regulator-min-microvolt = <95>;
+ regulator-max-microvolt = <135>;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,defdcdc_default = <1>;
+ };
+
+ ldo1_reg: regulator@3 {
+ regulator-name = "LDO1_1.8V";
+ regulator-min-microvolt = <171>;
+ regulator-max-microvolt = <189>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: regulator@4 {
+ regulator-name = "LDO2_1.2V";
+ regulator-min-microvolt = <114>;
+ regulator-max-microvolt = <132>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
};
--
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/
[RESEND 1/2] ARM: regulator: add tps6507x device tree data
Add device tree data for tps6507x regulator by adding
all tps6507x regulator nodes. Regulators are initialized
based on compatible name provided in tps6507x DT file.
All tps6507x PMIC regulator device tree nodes are placed
in a separate device tree include file (tps6507x.dtsi).
tps6507x.dtsi file is created using datasheet
http://www.ti.com/lit/ds/symlink/tps65070.pdf
Tested on da850-evm.
Signed-off-by: Vishwanathrao Badarkhe, Manish
---
:00 100644 000... 4c326e5... A arch/arm/boot/dts/tps6507x.dtsi
arch/arm/boot/dts/tps6507x.dtsi | 47 +++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tps6507x.dtsi b/arch/arm/boot/dts/tps6507x.dtsi
new file mode 100644
index 000..4c326e5
--- /dev/null
+++ b/arch/arm/boot/dts/tps6507x.dtsi
@@ -0,0 +1,47 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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.
+ */
+
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/tps65070.pdf
+ */
+
+&tps {
+ compatible = "ti,tps6507x";
+
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vdcdc1_reg: regulator@0 {
+ reg = <0>;
+ regulator-compatible = "VDCDC1";
+ };
+
+ vdcdc2_reg: regulator@1 {
+ reg = <1>;
+ regulator-compatible = "VDCDC2";
+ };
+
+ vdcdc3_reg: regulator@2 {
+ reg = <2>;
+ regulator-compatible = "VDCDC3";
+ };
+
+ ldo1_reg: regulator@3 {
+ reg = <3>;
+ regulator-compatible = "LDO1";
+ };
+
+ ldo2_reg: regulator@4 {
+ reg = <4>;
+ regulator-compatible = "LDO2";
+ };
+
+ };
+};
--
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/
[RESEND 0/2] davinci: Add device tree data for tps6507x.
Add device tree data for regulator via tps6507x mfd device in da850-evm. Applies on top of v3.9-rc1 of linus tree. Tested on da850-evm device. Test procedure followed as below: Once device boots up, issue command as: $for reg in /sys/class/regulator/*; do echo $reg `cat $reg/name` `cat $reg/state` `cat $reg/microvolts`; done This command will print all available regulators with its name, status (enabled/disabled) and voltages(in microvolts) like as below: /sys/class/regulator/regulator.1 VDCDC1_3.3V enabled 330 /sys/class/regulator/regulator.2 VDCDC2_3.3V enabled 330 /sys/class/regulator/regulator.3 VDCDC3_1.2V enabled 120 /sys/class/regulator/regulator.4 LDO1_1.8V enabled 180 /sys/class/regulator/regulator.5 LDO2_1.2V enabled 120 Note: Some of patches in this series are already accepted and residing in v3.9-rc1 kernel. These patches are as follows: 1. mfd: tps6507x: add device-tree support. 2. regulator: tps6507x: add device tree support. 3. ARM: davinci: da850: add DT node for I2C0. Vishwanathrao Badarkhe, Manish (2): ARM: regulator: add tps6507x device tree data ARM: davinci: da850: add tps6507x regulator DT data arch/arm/boot/dts/da850-evm.dts | 63 +++ arch/arm/boot/dts/tps6507x.dtsi | 47 + 2 files changed, 110 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/tps6507x.dtsi -- 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/
Re: cgroup: INFO: suspicious RCU usage. in cgroup_name
On 2013/3/7 14:15, Michael Wang wrote:
> On 03/07/2013 12:02 AM, Sasha Levin wrote:
>> Hi all,
>>
>> While fuzzing with trinity inside a KVM tools guest running latest -next
>> kernel
>> I've stumbled on the following:
>>
>> [ 450.180599] ===
>> [ 450.181392] [ INFO: suspicious RCU usage. ]
>> [ 450.182101] 3.9.0-rc1-next-20130305-sasha-00048-g35e9ec5-dirty #1032
>> Tainted: GW
>> [ 450.183482] ---
>> [ 450.184343] include/linux/cgroup.h:429 suspicious rcu_dereference_check()
>> usage!
>> [ 450.185575]
>> [ 450.185575] other info that might help us debug this:
>> [ 450.185575]
>> [ 450.186961]
>> [ 450.186961] rcu_scheduler_active = 1, debug_locks = 1
>> [ 450.188001] 4 locks held by kworker/u:0/6:
>> [ 450.188646] #0: (khelper){.+.+.+}, at: []
>> process_one_work+0x238/0x570
>> [ 450.190186] #1: ((&sub_info->work)){+.+.+.}, at: []
>> process_one_work+0x238/0x570
>> [ 450.191824] #2: (&(&p->alloc_lock)->rlock){+.+.-.}, at:
>> [] dump_header+0x43/0xe0
>
> Hi, Sasha
>
> I suppose this is the warn context:
>
> cpuset_print_task_mems_allowed() -> task_cs() -> task_subsys_state()
>
> and this is the definition of task_subsys_state():
>
> #define task_subsys_state_check(task, subsys_id, __c) \
> rcu_dereference_check(task->cgroups->subsys[subsys_id], \
> lockdep_is_held(&task->alloc_lock) || \
> cgroup_lock_is_held() || (__c))
>
> the condition "lockdep_is_held(&task->alloc_lock)" should match (#2
> lock), the warn doesn't make sense to me...
>
nope..note this is 3.9-rc1-next, not 3.9-rc1.
The warning is from this:
/* Caller should hold rcu_read_lock() */
static inline const char *cgroup_name(const struct cgroup *cgrp)
{
return rcu_dereference(cgrp->name)->name;
}
I've cooked up a patch. Will send out today.
--
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: cgroup: INFO: suspicious RCU usage. in cgroup_name
On 03/07/2013 12:02 AM, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running latest -next
> kernel
> I've stumbled on the following:
>
> [ 450.180599] ===
> [ 450.181392] [ INFO: suspicious RCU usage. ]
> [ 450.182101] 3.9.0-rc1-next-20130305-sasha-00048-g35e9ec5-dirty #1032
> Tainted: GW
> [ 450.183482] ---
> [ 450.184343] include/linux/cgroup.h:429 suspicious rcu_dereference_check()
> usage!
> [ 450.185575]
> [ 450.185575] other info that might help us debug this:
> [ 450.185575]
> [ 450.186961]
> [ 450.186961] rcu_scheduler_active = 1, debug_locks = 1
> [ 450.188001] 4 locks held by kworker/u:0/6:
> [ 450.188646] #0: (khelper){.+.+.+}, at: []
> process_one_work+0x238/0x570
> [ 450.190186] #1: ((&sub_info->work)){+.+.+.}, at: []
> process_one_work+0x238/0x570
> [ 450.191824] #2: (&(&p->alloc_lock)->rlock){+.+.-.}, at:
> [] dump_header+0x43/0xe0
Hi, Sasha
I suppose this is the warn context:
cpuset_print_task_mems_allowed() -> task_cs() -> task_subsys_state()
and this is the definition of task_subsys_state():
#define task_subsys_state_check(task, subsys_id, __c) \
rcu_dereference_check(task->cgroups->subsys[subsys_id], \
lockdep_is_held(&task->alloc_lock) || \
cgroup_lock_is_held() || (__c))
the condition "lockdep_is_held(&task->alloc_lock)" should match (#2
lock), the warn doesn't make sense to me...
Regards,
Michael Wang
> [ 450.193366] #3: (cpuset_buffer_lock){+.+...}, at: []
> cpuset_print_task_mems_allowed+0x60/0x150
> [ 450.195281]
> [ 450.195281] stack backtrace:
> [ 450.195987] Pid: 6, comm: kworker/u:0 Tainted: GW
> 3.9.0-rc1-next-20130305-sasha-00048-g35e9ec5-dirty #1032
> [ 450.197678] Call Trace:
> [ 450.198086] [] lockdep_rcu_suspicious+0x113/0x130
> [ 450.199077] [] cpuset_print_task_mems_allowed+0xe7/0x150
> [ 450.200263] [] dump_header+0x7c/0xe0
> [ 450.201135] [] oom_kill_process+0x82/0x370
> [ 450.202048] [] out_of_memory+0x1ab/0x200
> [ 450.202921] [] ? _raw_write_unlock_irq+0x50/0x80
> [ 450.204068] [] __alloc_pages_slowpath+0x5bf/0x700
> [ 450.205075] [] __alloc_pages_nodemask+0x2d5/0x400
> [ 450.206067] [] dup_task_struct+0x68/0x1c0
> [ 450.206975] [] copy_process+0xe9/0xfd0
> [ 450.207798] [] ? sched_clock_local+0x25/0x90
> [ 450.208679] [] ? call_helper+0x20/0x20
> [ 450.209496] [] do_fork+0xbb/0x280
> [ 450.210384] [] kernel_thread+0x21/0x30
> [ 450.211323] [] __call_usermodehelper+0x33/0xa0
> [ 450.212260] [] process_one_work+0x368/0x570
> [ 450.213201] [] ? process_one_work+0x238/0x570
> [ 450.214248] [] worker_thread+0x1f5/0x340
> [ 450.215159] [] ? manage_workers+0x160/0x160
> [ 450.216078] [] kthread+0xe2/0xf0
> [ 450.216901] [] ? __lock_release+0x1da/0x1f0
> [ 450.217824] [] ? __init_kthread_worker+0x70/0x70
> [ 450.218791] [] ret_from_fork+0x7c/0xb0
> [ 450.219627] [] ? __init_kthread_worker+0x70/0x70
> [ 450.220780] kworker/u:0 cpuset=/ mems_allowed=0
>
> The offending commit looks like "cgroup: fix cgroup_path() vs rename() race".
>
>
> Thanks,
> Sasha
> --
> 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: [RFC][PATCH 2/2] tracing: Do not return EINVAL in snapshot when not allocated
(03/06/2013 10:49 PM), Steven Rostedt wrote: > From: "Steven Rostedt (Red Hat)" > > To use the tracing snapshot feature, writing a '1' into the snapshot > file causes the snapshot buffer to be allocated if it has not already > been allocated and dose a 'swap' with the main buffer, so that the > snapshot now contains what was in the main buffer, and the main buffer > now writes to what was the snapshot buffer. > > To free the snapshot buffer, a '0' is written into the snapshot file. > > To clear the snapshot buffer, any number but a '0' or '1' is written > into the snapshot file. But if the file is not allocated it returns > -EINVAL error code. This is rather pointless. It is better just to > do nothing and return success. > > Cc: Hiraku Toyooka > Signed-off-by: Steven Rostedt > --- Acked-by: Hiraku Toyooka > kernel/trace/trace.c |2 -- > 1 file changed, 2 deletions(-) > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > index 9e3120b..1f835a8 100644 > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -4167,8 +4167,6 @@ tracing_snapshot_write(struct file *filp, const char > __user *ubuf, size_t cnt, > default: > if (current_trace->allocated_snapshot) > tracing_reset_online_cpus(&max_tr); > - else > - ret = -EINVAL; > break; > } > > -- 1.7.10.4 . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/2] tracing: Add help of snapshot feature when snapshot is empty
(03/06/2013 10:49 PM), Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> When cat'ing the snapshot file, instead of showing an empty trace
> header like the trace file does, show how to use the snapshot
> feature.
>
> Also, this is a good place to show if the snapshot has been allocated
> or not. Users may want to "pre allocate" the snapshot to have a fast
> "swap" of the current buffer. Otherwise, a swap would be slow and might
> fail as it would need to allocate the snapshot buffer, and that might
> fail under tight memory constraints.
>
> Here's what it looked like before:
>
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 0/0 #P:4
> #
> # _-=> irqs-off
> # / _=> need-resched
> #| / _---=> hardirq/softirq
> #|| / _--=> preempt-depth
> #||| / delay
> # TASK-PID CPU# TIMESTAMP FUNCTION
> # | | | | |
>
> Here's what it looks like now:
>
> # tracer: nop
> #
> #
> # * Snapshot is freed *
> #
> # Snapshot commands:
> # echo 0 > snapshot : Clears and frees snapshot buffer
> # echo 1 > snapshot : Allocates snapshot buffer, if not already allocated.
> # Takes a snapshot of the main buffer.
> # echo 2 > snapshot : Clears snapshot buffer (but does not allocate)
> # (Doesn't have to be '2' works with any number that
> # is not a '0' or '1')
>
> Cc: Hiraku Toyooka
> Signed-off-by: Steven Rostedt
> ---
Acked-by: Hiraku Toyooka
> kernel/trace/trace.c | 25 -
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index c2e2c23..9e3120b 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -2400,6 +2400,27 @@ static void test_ftrace_alive(struct seq_file *m)
> seq_printf(m, "# MAY BE MISSING FUNCTION EVENTS\n");
> }
>
> +#ifdef CONFIG_TRACER_MAX_TRACE
> +static void print_snapshot_help(struct seq_file *m, struct trace_iterator
> *iter)
> +{
> + if (iter->trace->allocated_snapshot)
> + seq_printf(m, "#\n# * Snapshot is allocated *\n#\n");
> + else
> + seq_printf(m, "#\n# * Snapshot is freed *\n#\n");
> +
> + seq_printf(m, "# Snapshot commands:\n");
> + seq_printf(m, "# echo 0 > snapshot : Clears and frees snapshot
> buffer\n");
> + seq_printf(m, "# echo 1 > snapshot : Allocates snapshot buffer, if not
> already allocated.\n");
> + seq_printf(m, "# Takes a snapshot of the main
> buffer.\n");
> + seq_printf(m, "# echo 2 > snapshot : Clears snapshot buffer (but does
> not allocate)\n");
> + seq_printf(m, "# (Doesn't have to be '2' works
> with any number that\n");
> + seq_printf(m, "# is not a '0' or '1')\n");
> +}
> +#else
> +/* Should never be called */
> +static inline void print_snapshot_help(struct seq_file *m, struct
> trace_iterator *iter) { }
> +#endif
> +
> static int s_show(struct seq_file *m, void *v)
> {
> struct trace_iterator *iter = v;
> @@ -2411,7 +2432,9 @@ static int s_show(struct seq_file *m, void *v)
> seq_puts(m, "#\n");
> test_ftrace_alive(m);
> }
> - if (iter->trace && iter->trace->print_header)
> + if (iter->snapshot && trace_empty(iter))
> + print_snapshot_help(m, iter);
> + else if (iter->trace && iter->trace->print_header)
> iter->trace->print_header(m);
> else
> trace_default_header(m);
> -- 1.7.10.4 .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sysfs_dir_cache slab corruption
On Thu, Mar 07, 2013 at 12:33:53AM -0500, Dave Jones wrote: > And even more sysfs fallout (From a clean boot).. > > = > BUG sysfs_dir_cache (Not tainted): Poison overwritten > - > > Disabling lock debugging due to kernel taint > INFO: 0x8801239a85b8-0x8801239a85b8. First byte 0x69 instead of 0x6b > INFO: Allocated in sysfs_new_dirent+0x59/0x130 age=493166 cpu=3 pid=301 > __slab_alloc+0x4ed/0x584 > kmem_cache_alloc+0x2c0/0x330 > sysfs_new_dirent+0x59/0x130 > sysfs_add_file_mode+0x6b/0x110 > sysfs_add_file+0x12/0x20 > sysfs_create_file+0x26/0x30 > load_module+0x1360/0x28d0 > sys_init_module+0xd7/0x120 > system_call_fastpath+0x16/0x1b > INFO: Freed in release_sysfs_dirent+0x81/0x100 age=10736 cpu=3 pid=8692 > __slab_free+0x3c/0x3de > kmem_cache_free+0x362/0x380 > release_sysfs_dirent+0x81/0x100 > sysfs_dir_pos+0x46/0xf0 > sysfs_readdir+0x9a/0x2b0 > vfs_readdir+0xb8/0xf0 > sys_getdents64+0x8f/0x110 > system_call_fastpath+0x16/0x1b > INFO: Slab 0xea00048e6a00 objects=16 used=16 fp=0x (null) > flags=0x50004080 > INFO: Object 0x8801239a85b8 @offset=1464 fp=0x (null) > > Bytes b4 8801239a85a8: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a > > Object 8801239a85b8: 69 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > ikkk > Object 8801239a85c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 8801239a85d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 8801239a85e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 8801239a85f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 8801239a8608: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 8801239a8618: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 8801239a8628: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 8801239a8638: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Object 8801239a8648: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 > kkk. > Redzone 8801239a8658: bb bb bb bb bb bb bb bb > > Padding 8801239a8798: 5a 5a 5a 5a 5a 5a 5a 5a > > Pid: 15728, comm: modprobe Tainted: GB3.9.0-rc1+ #69 > Call Trace: > [] ? print_section+0x3d/0x40 > [] print_trailer+0xfe/0x160 > [] check_bytes_and_report+0xef/0x130 > [] check_object+0x1c6/0x240 > [] ? check_slab+0x89/0x130 > [] ? sysfs_new_dirent+0x59/0x130 > [] alloc_debug_processing+0x67/0x109 > [] __slab_alloc+0x4ed/0x584 > [] ? sysfs_new_dirent+0x59/0x130 > [] kmem_cache_alloc+0x2c0/0x330 > [] ? sysfs_new_dirent+0x59/0x130 > [] sysfs_new_dirent+0x59/0x130 > [] sysfs_add_file_mode+0x6b/0x110 > [] internal_create_group+0xd0/0x210 > [] sysfs_create_group+0x13/0x20 > [] load_module+0x22d1/0x28d0 > [] ? ddebug_proc_open+0xc0/0xc0 > [] ? put_lock_stats.isra.23+0xe/0x40 > [] sys_init_module+0xd7/0x120 > [] system_call_fastpath+0x16/0x1b > FIX sysfs_dir_cache: Restoring 0x8801239a85b8-0x8801239a85b8=0x6b > Hm, a module was being loaded. Odd, I haven't seen this before, I'm guessing that 3.8 doesn't show this, right? 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: use after free in sysfs_find_dirent
On Thu, Mar 07, 2013 at 12:28:54AM -0500, Dave Jones wrote: > general protection fault: [#1] PREEMPT SMP > Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock bnep fuse rfcomm > hidp l2tp_ppp l2tp_core 8021q garp mrp dlci pppoe pppox ppp_generic slhc > scsi_transport_iscsi rose caif_socket caif can_raw bridge af_key can_bcm llc2 > stp can netrom phonet af_rxrpc nfnetlink ipt_ULOG x25 rds irda crc_ccitt ax25 > ipx p8023 p8022 decnet atm appletalk psnap llc nfc lockd sunrpc ip6t_REJECT > nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter > ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm btusb > snd_page_alloc bluetooth snd_timer snd microcode rfkill usb_debug serio_raw > pcspkr edac_core soundcore vhost_net tun r8169 macvtap macvlan mii kvm_amd kvm > CPU 0 > Pid: 23476, comm: trinity-child1 Not tainted 3.9.0-rc1+ #69 Gigabyte > Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H > RIP: 0010:[] [] > sysfs_find_dirent+0x47/0xf0 > RSP: 0018:88000585bd68 EFLAGS: 00010202 > RAX: 94be55f6 RBX: 6b6b6b6b6b6b6b6b RCX: 6b6b6b6b > RDX: RSI: RDI: > RBP: 88000585bd88 R08: R09: > R10: R11: R12: 0029c161 > R13: 8800a8918288 R14: R15: 0009 > FS: 7fa12651e740() GS:88012ae0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 0010 CR3: 1a128000 CR4: 07f0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process trinity-child1 (pid: 23476, threadinfo 88000585a000, task > 8800cd454920) > Stack: > 880128edc1e8 8800a8918250 fffe 88012265f430 > 88000585bdb8 812357cd 8800a8918250 8801226514d0 > 88000585bf38 88000585bde8 811bb30d > Call Trace: > [] sysfs_lookup+0x6d/0xe0 > [] lookup_real+0x1d/0x60 > [] __lookup_hash+0x38/0x50 > [] lookup_hash+0x19/0x20 > [] kern_path_create+0x93/0x170 > [] ? getname_flags.part.32+0x86/0x150 > [] user_path_create+0x4a/0x70 > [] sys_mkdirat+0x39/0xe0 > [] system_call_fastpath+0x16/0x1b > Code: 00 48 8b 9f 88 00 00 00 f6 c4 0f 0f 95 c0 48 85 f6 0f 95 c2 38 d0 75 79 > 4c 89 ee 4c 89 f7 e8 91 ef ff ff 41 89 c4 48 85 db 74 1d <8b> 4b 28 41 39 cc > 74 21 44 89 e0 29 c8 83 f8 00 7c 2c 74 45 48 > RIP [] sysfs_find_dirent+0x47/0xf0 > RSP > ---[ end trace 4ba97703eaafbb8b ]--- Any hint as to what was happening here when this crashed? 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/
Re: [PATCH 1/6] platform-drivers: msm: add single-wire serial bus interface (SSBI) driver
On Wed, Mar 06, 2013 at 09:20:45PM -0800, David Brown wrote:
> Greg Kroah-Hartman writes:
>
> > On Wed, Mar 06, 2013 at 04:29:42PM -0800, David Brown wrote:
> >> +menu "Qualcomm MSM SSBI bus support"
> >> + depends on ARCH_MSM
> >
> > Why?
>
> In the sense that ARCH_MSM are the only devices that ever were, or ever
> will be made with this device. It doesn't strictly depend on it, but do
> we want to clutter the config for everything else.
It's not "clutter". You want me to build this on other platforms, to
catch api and other types of build breakages. This is the way for
almost all Linux drivers.
> >> +config MSM_SSBI
> >> + bool "Qualcomm Single-wire Serial Bus Interface (SSBI)"
> >
> > Why can't this be a module?
>
> Without this device, the PMIC drivers won't work, regulators can't be
> turned on, and most of the other devices won't work. I can try if it
> can still be made a module, and it might be good at exercising the
> deferred probe mechanism.
If the PMIC drivers are dependant on the symbols in this module, there
should not be any problems, right?
> So, a deeper question. I've resent this driver with minimal change.
> I've also made some other changes as patches afterwards. Do we want
> these squashed into a single patch, or the initial one (not authored by
> me) followed by updates?
To preserve the authorship, you might want to fix this stuff with
follow-on patches. As long as the original patch can build properly.
> >> +static struct platform_driver msm_ssbi_driver = {
> >> + .probe = msm_ssbi_probe,
> >> + .remove = __exit_p(msm_ssbi_remove),
> >
> > You just oopsed if someone unbound your device from the driver from
> > userspace. Not good.
>
> I did catch this one in a later patch :-) I can clean it up in the
> driver, though, since it looks like some more work needs to go into
> this.
Yes, but it's very close, fix this all up and resend your series and all
should be fine.
Nice job,
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: upgrade to 3.8.1 : BUG Scheduling while atomic in bonding driver:
On 03/02/2013 01:21 PM, Linda Walsh wrote:
>
>
>
>
> Linda Walsh wrote:
>>
>>
>> This patch is not in the latest kernel. I don't know if it is the
>> 'best' way, but it does stop BUG error messages.
> ---
> Update -- it *used* to stop the messages in 3.6.7.
>
> It no longer stops the messages in 3.8.1 -- (and isn't present by
> default -- tried
> adding the unlock/lock -- no difference.
>
> Weird. *sigh*
Hi, Linda
Do you have the BUG log after applied this patch?
bond->lock seems to be the only one who will add the preempt_count, the
patch should works...
And have you tried the 3.9.0-rc1, is the issue still exist?
Regards,
Michael Wang
>
>>
>>
>> Original Message
>> Subject: Re: BUG: scheduling while atomic:
>> ifup-bonding/3711/0x0002 -- V3.6.7
>> Date:Wed, 28 Nov 2012 13:17:31 -0800
>> From:Linda Walsh
>> To: Cong Wang
>> CC: LKML , Linux Kernel Network
>> Developers
>> References: <50b5248a.5010...@tlinx.org>
>>
>>
>>
>>
>> Cong Wang wrote:
>>> Does this quick fix help?
>>> diff --git a/drivers/net/bonding/bond_main.c
>>> b/drivers/net/bonding/bond_main.c
>>> index 5f5b69f..4a4d9eb 100644
>>> --- a/drivers/net/bonding/bond_main.c
>>> +++ b/drivers/net/bonding/bond_main.c
>>> @@ -1785,7 +1785,9 @@ int bond_enslave(struct net_device *bond_dev,
>>> struct net_device *slave_dev)
>>> new_slave->link == BOND_LINK_DOWN ? "DOWN" :
>>> (new_slave->link == BOND_LINK_UP ? "UP" : "BACK"));
>>>
>>> + read_unlock(&bond->lock);
>>> bond_update_speed_duplex(new_slave);
>>> + read_lock(&bond->lock);
>>>
>>> if (USES_PRIMARY(bond->params.mode) && bond->params.primary[0]) {
>>> /* if there is a primary slave, remember it */
>>>
>>> Thanks!
>>>
>>
>>
>>
>>
>> Eric Dumazet wrote:
>>> On Fri, 2013-03-01 at 00:15 -0800, Linda Walsh wrote:
>>>
Just installed 3.8.1
Thought this had been fixed? Note it causes the kernel to
show up as tainted after the 1st...
>>>
>>> CC netdev & Jay Vosburgh & Jeff Kirsher
>>>
>>>
As the system was coming up and initializing the bond0 driver:
[ 19.847743] ixgbe :06:00.0: registered PHC device on eth_s2_0
[ 20.258245] BUG: scheduling while atomic: ifup-bonding/2003/0x0002
[ 20.264812] 4 locks held by ifup-bonding/2003:
[ 20.269298] #0: (&buffer->mutex){..}, at: []
sysfs_write_file+0x3f/0x150
[ 20.278319] #1: (s_active#59){..}, at: []
sysfs_write_file+0xbb/0x150
[ 20.287088] #2: (rtnl_mutex){..}, at: []
rtnl_trylock+0x10/0x20
[ 20.295373] #3: (&bond->lock){..}, at: []
bond_enslave+0x4ef/0xb80
[ 20.303912] Modules linked in: iptable_filter kvm_intel kvm acpi_cpufreq
mperf button processor mousedev iTCO_wdt
[ 20.314695] Pid: 2003, comm: ifup-bonding Not tainted 3.8.1-Isht-Van #5
[ 20.321340] Call Trace:
[ 20.323833] [] __schedule_bug+0x5e/0x6c
[ 20.329356] [] __schedule+0x762/0x7f0
[ 20.334701] [] schedule+0x24/0x70
[ 20.339703] []
schedule_hrtimeout_range_clock+0xa4/0x130
[ 20.346699] [] ? update_rmtp+0x60/0x60
[ 20.352130] [] ? hrtimer_start_range_ns+0xf/0x20
[ 20.358434] [] schedule_hrtimeout_range+0xe/0x10
[ 20.364734] [] usleep_range+0x3b/0x40
[ 20.370082] []
ixgbe_acquire_swfw_sync_X540+0xbc/0x100
[ 20.376905] [] ixgbe_read_phy_reg_generic+0x3d/0x140
[ 20.383553] []
ixgbe_get_copper_link_capabilities_generic+0x2c/0x60
[ 20.391499] [] ? bond_enslave+0x4ef/0xb80
[ 20.397194] [] ixgbe_get_settings+0x34/0x340
[ 20.403148] [] __ethtool_get_settings+0x88/0x130
[ 20.409448] [] bond_update_speed_duplex+0x23/0x60
[ 20.415833] [] bond_enslave+0x559/0xb80
[ 20.421356] [] bonding_store_slaves+0x16f/0x1c0
[ 20.427569] [] dev_attr_store+0x13/0x30
[ 20.433091] [] sysfs_write_file+0xd4/0x150
[ 20.438872] [] vfs_write+0xb1/0x190
[ 20.444047] [] sys_write+0x50/0xa0
[ 20.449137] [] system_call_fastpath+0x16/0x1b
[ 20.455264] BUG: scheduling while atomic: ifup-bonding/2003/0x0002
[ 20.461851] 4 locks held by ifup-bonding/2003:
[ 20.466334] #0: (&buffer->mutex){..}, at: []
sysfs_write_file+0x3f/0x150
[ 20.475356] #1: (s_active#59){..}, at: []
sysfs_write_file+0xbb/0x150
[ 20.484117] #2: (rtnl_mutex){..}, at: []
rtnl_trylock+0x10/0x20
[ 20.492403] #3: (&bond->lock){..}, at: []
bond_enslave+0x4ef/0xb80
[ 20.500902] Modules linked in: iptable_filter kvm_intel kvm acpi_cpufreq
mperf button processor mousedev iTCO_wdt
[ 20.511640] Pid: 2003, comm: ifup-bonding Tainted: GW
3.8.1-Isht-Van #5
[ 20.519240] Call Trace:
[ 20.521729] [] __schedule_bug+0x5e/0x6c
[
[PATCH v2] CAIF: fix indentation for function arguments
This lines up function arguments on second and subsequent lines at the
first column after the openning parenthesis of the first line.
Signed-off-by: Silviu-Mihai Popescu
---
net/caif/caif_dev.c |9 +
net/caif/caif_socket.c | 22 +++---
net/caif/caif_usb.c |4 ++--
net/caif/cfcnfg.c | 19 +--
net/caif/cfctrl.c | 14 +++---
net/caif/cffrml.c |4 ++--
net/caif/cfmuxl.c |4 ++--
net/caif/cfpkt_skbuff.c |8
net/caif/cfrfml.c |4 ++--
net/caif/cfserl.c |4 ++--
net/caif/cfsrvl.c | 13 ++---
net/caif/chnl_net.c |6 +++---
12 files changed, 55 insertions(+), 56 deletions(-)
diff --git a/net/caif/caif_dev.c b/net/caif/caif_dev.c
index 21760f0..df6d56d 100644
--- a/net/caif/caif_dev.c
+++ b/net/caif/caif_dev.c
@@ -301,10 +301,11 @@ static void dev_flowctrl(struct net_device *dev, int on)
}
void caif_enroll_dev(struct net_device *dev, struct caif_dev_common *caifdev,
- struct cflayer *link_support, int head_room,
- struct cflayer **layer, int (**rcv_func)(
- struct sk_buff *, struct net_device *,
- struct packet_type *, struct net_device *))
+struct cflayer *link_support, int head_room,
+struct cflayer **layer,
+int (**rcv_func)(struct sk_buff *, struct net_device *,
+ struct packet_type *,
+ struct net_device *))
{
struct caif_device_entry *caifd;
enum cfcnfg_phy_preference pref;
diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
index 095259f..1d337e0 100644
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@ -197,8 +197,8 @@ static void cfsk_put(struct cflayer *layr)
/* Packet Control Callback function called from CAIF */
static void caif_ctrl_cb(struct cflayer *layr,
- enum caif_ctrlcmd flow,
- int phyid)
+enum caif_ctrlcmd flow,
+int phyid)
{
struct caifsock *cf_sk = container_of(layr, struct caifsock, layer);
switch (flow) {
@@ -274,7 +274,7 @@ static void caif_check_flow_release(struct sock *sk)
* changed locking, address handling and added MSG_TRUNC.
*/
static int caif_seqpkt_recvmsg(struct kiocb *iocb, struct socket *sock,
- struct msghdr *m, size_t len, int flags)
+ struct msghdr *m, size_t len, int flags)
{
struct sock *sk = sock->sk;
@@ -346,8 +346,8 @@ static long caif_stream_data_wait(struct sock *sk, long
timeo)
* changed locking calls, changed address handling.
*/
static int caif_stream_recvmsg(struct kiocb *iocb, struct socket *sock,
- struct msghdr *msg, size_t size,
- int flags)
+ struct msghdr *msg, size_t size,
+ int flags)
{
struct sock *sk = sock->sk;
int copied = 0;
@@ -462,7 +462,7 @@ out:
* CAIF flow-on and sock_writable.
*/
static long caif_wait_for_flow_on(struct caifsock *cf_sk,
- int wait_writeable, long timeo, int *err)
+ int wait_writeable, long timeo, int *err)
{
struct sock *sk = &cf_sk->sk;
DEFINE_WAIT(wait);
@@ -516,7 +516,7 @@ static int transmit_skb(struct sk_buff *skb, struct
caifsock *cf_sk,
/* Copied from af_unix:unix_dgram_sendmsg, and adapted to CAIF */
static int caif_seqpkt_sendmsg(struct kiocb *kiocb, struct socket *sock,
- struct msghdr *msg, size_t len)
+ struct msghdr *msg, size_t len)
{
struct sock *sk = sock->sk;
struct caifsock *cf_sk = container_of(sk, struct caifsock, sk);
@@ -591,7 +591,7 @@ err:
* and other minor adaptations.
*/
static int caif_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
- struct msghdr *msg, size_t len)
+ struct msghdr *msg, size_t len)
{
struct sock *sk = sock->sk;
struct caifsock *cf_sk = container_of(sk, struct caifsock, sk);
@@ -670,7 +670,7 @@ out_err:
}
static int setsockopt(struct socket *sock,
- int lvl, int opt, char __user *ov, unsigned int ol)
+ int lvl, int opt, char __user *ov, unsigned int ol)
{
struct sock *sk = sock->sk;
struct caifsock *cf_sk = container_of(sk, struct caifsock, sk);
@@ -932,7 +932,7 @@ static int caif_release(struct socket *sock)
/* Copied from af_unix.c:unix_poll(), added CAIF tx_flow handling */
static unsigned int caif_poll(struct file *file,
- struct socket *sock, poll_table *wait)
+
sysfs_dir_cache slab corruption
And even more sysfs fallout (From a clean boot).. = BUG sysfs_dir_cache (Not tainted): Poison overwritten - Disabling lock debugging due to kernel taint INFO: 0x8801239a85b8-0x8801239a85b8. First byte 0x69 instead of 0x6b INFO: Allocated in sysfs_new_dirent+0x59/0x130 age=493166 cpu=3 pid=301 __slab_alloc+0x4ed/0x584 kmem_cache_alloc+0x2c0/0x330 sysfs_new_dirent+0x59/0x130 sysfs_add_file_mode+0x6b/0x110 sysfs_add_file+0x12/0x20 sysfs_create_file+0x26/0x30 load_module+0x1360/0x28d0 sys_init_module+0xd7/0x120 system_call_fastpath+0x16/0x1b INFO: Freed in release_sysfs_dirent+0x81/0x100 age=10736 cpu=3 pid=8692 __slab_free+0x3c/0x3de kmem_cache_free+0x362/0x380 release_sysfs_dirent+0x81/0x100 sysfs_dir_pos+0x46/0xf0 sysfs_readdir+0x9a/0x2b0 vfs_readdir+0xb8/0xf0 sys_getdents64+0x8f/0x110 system_call_fastpath+0x16/0x1b INFO: Slab 0xea00048e6a00 objects=16 used=16 fp=0x (null) flags=0x50004080 INFO: Object 0x8801239a85b8 @offset=1464 fp=0x (null) Bytes b4 8801239a85a8: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a Object 8801239a85b8: 69 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ikkk Object 8801239a85c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 8801239a85d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 8801239a85e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 8801239a85f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 8801239a8608: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 8801239a8618: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 8801239a8628: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 8801239a8638: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 8801239a8648: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkk. Redzone 8801239a8658: bb bb bb bb bb bb bb bb Padding 8801239a8798: 5a 5a 5a 5a 5a 5a 5a 5a Pid: 15728, comm: modprobe Tainted: GB3.9.0-rc1+ #69 Call Trace: [] ? print_section+0x3d/0x40 [] print_trailer+0xfe/0x160 [] check_bytes_and_report+0xef/0x130 [] check_object+0x1c6/0x240 [] ? check_slab+0x89/0x130 [] ? sysfs_new_dirent+0x59/0x130 [] alloc_debug_processing+0x67/0x109 [] __slab_alloc+0x4ed/0x584 [] ? sysfs_new_dirent+0x59/0x130 [] kmem_cache_alloc+0x2c0/0x330 [] ? sysfs_new_dirent+0x59/0x130 [] sysfs_new_dirent+0x59/0x130 [] sysfs_add_file_mode+0x6b/0x110 [] internal_create_group+0xd0/0x210 [] sysfs_create_group+0x13/0x20 [] load_module+0x22d1/0x28d0 [] ? ddebug_proc_open+0xc0/0xc0 [] ? put_lock_stats.isra.23+0xe/0x40 [] sys_init_module+0xd7/0x120 [] system_call_fastpath+0x16/0x1b FIX sysfs_dir_cache: Restoring 0x8801239a85b8-0x8801239a85b8=0x6b -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Porter, Matt
> Sent: Thursday, March 07, 2013 9:47 AM
> To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
> Lindgren; Russell King
> Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List; Linux
> Kernel Mailing List; Linux MMC List
> Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support
>
> Adds AM33XX MMC support for am335x-bone, am335x-evm, and
> am335x-evmsk.
>
> Signed-off-by: Matt Porter
> Acked-by: Tony Lindgren
> ---
> arch/arm/boot/dts/am335x-bone.dts |7 +++
> arch/arm/boot/dts/am335x-evm.dts |7 +++
> arch/arm/boot/dts/am335x-evmsk.dts |7 +++
> arch/arm/boot/dts/am33xx.dtsi | 28
> 4 files changed, 49 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone.dts
> b/arch/arm/boot/dts/am335x-bone.dts
> index 11b240c..a154ce0 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -120,6 +120,8 @@
> };
>
> ldo3_reg: regulator@5 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> regulator-always-on;
> };
>
> @@ -136,3 +138,8 @@
> &cpsw_emac1 {
> phy_id = <&davinci_mdio>, <1>;
> };
> +
> +&mmc1 {
> + status = "okay";
> + vmmc-supply = <&ldo3_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am335x-evm.dts
> b/arch/arm/boot/dts/am335x-evm.dts
> index d649644..2907da6 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -232,6 +232,8 @@
> };
>
> vmmc_reg: regulator@12 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> regulator-always-on;
> };
> };
> @@ -244,3 +246,8 @@
> &cpsw_emac1 {
> phy_id = <&davinci_mdio>, <1>;
> };
> +
> +&mmc1 {
> + status = "okay";
> + vmmc-supply = <&vmmc_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
> b/arch/arm/boot/dts/am335x-evmsk.dts
> index f5a6162..f050c46 100644
> --- a/arch/arm/boot/dts/am335x-evmsk.dts
> +++ b/arch/arm/boot/dts/am335x-evmsk.dts
> @@ -244,7 +244,14 @@
> };
>
> vmmc_reg: regulator@12 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> regulator-always-on;
> };
> };
> };
> +
> +&mmc1 {
> + status = "okay";
> + vmmc-supply = <&vmmc_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi
> b/arch/arm/boot/dts/am33xx.dtsi
> index c3c781a..e029eea 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -234,6 +234,34 @@
> status = "disabled";
> };
>
> + mmc1: mmc@4806 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc1";
> + ti,dual-volt;
> + ti,needs-special-reset;
> + dmas = <&edma 24
> + &edma 25>;
> + dma-names = "tx", "rx";
> + status = "disabled";
> + };
> +
> + mmc2: mmc@481d8000 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc2";
> + ti,needs-special-reset;
> + dmas = <&edma 2
> + &edma 3>;
> + dma-names = "tx", "rx";
> + status = "disabled";
> + };
> +
> + mmc3: mmc@4781 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc3";
> + ti,needs-special-reset;
> + status = "disabled";
> + };
Any specific reason why you did not add edma entry here as well?
Also, I wonder why "interrupt" property is not coming here, I understand
That hwmod is filling the gap here; but I would still recommend you to complete
The DT node, as we only support DT boot.
I will test the whole patch series today and update you.
Thanks,
Vaibhav
> +
> wdt2: wdt@44e35000 {
> compatible = "ti,omap3-wdt";
> ti,hwmods = "wd_timer2";
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf, tools: Fix compilation without newt support
On Wed, 6 Mar 2013 15:19:17 -0800, Andi Kleen wrote: > From: Andi Kleen > > Fix > > builtin-annotate.c: In function ‘hists__find_annotations’: > builtin-annotate.c:161:4: error: duplicate case value > builtin-annotate.c:154:4: error: previously used here > > and > > builtin-report.c:479:15: error: ‘K_SWITCH_INPUT_DATA’ undeclared (first use > in this function) > builtin-report.c:479:15: note: each undeclared identifier is reported only > once for each function it appears in > builtin-report.c: In function ‘cmd_report’: > builtin-report.c:823:13: error: ‘K_SWITCH_INPUT_DATA’ undeclared (first use > in this function) > > by changing the values of the fallback K_LEFT, K_RIGHT and adding a > dummy K_SWITCH_INPUT_DATA too The fixes are already in the acme/perf/core. Thanks, Namhyung -- 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/
use after free in sysfs_find_dirent
general protection fault: [#1] PREEMPT SMP Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock bnep fuse rfcomm hidp l2tp_ppp l2tp_core 8021q garp mrp dlci pppoe pppox ppp_generic slhc scsi_transport_iscsi rose caif_socket caif can_raw bridge af_key can_bcm llc2 stp can netrom phonet af_rxrpc nfnetlink ipt_ULOG x25 rds irda crc_ccitt ax25 ipx p8023 p8022 decnet atm appletalk psnap llc nfc lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm btusb snd_page_alloc bluetooth snd_timer snd microcode rfkill usb_debug serio_raw pcspkr edac_core soundcore vhost_net tun r8169 macvtap macvlan mii kvm_amd kvm CPU 0 Pid: 23476, comm: trinity-child1 Not tainted 3.9.0-rc1+ #69 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H RIP: 0010:[] [] sysfs_find_dirent+0x47/0xf0 RSP: 0018:88000585bd68 EFLAGS: 00010202 RAX: 94be55f6 RBX: 6b6b6b6b6b6b6b6b RCX: 6b6b6b6b RDX: RSI: RDI: RBP: 88000585bd88 R08: R09: R10: R11: R12: 0029c161 R13: 8800a8918288 R14: R15: 0009 FS: 7fa12651e740() GS:88012ae0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0010 CR3: 1a128000 CR4: 07f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process trinity-child1 (pid: 23476, threadinfo 88000585a000, task 8800cd454920) Stack: 880128edc1e8 8800a8918250 fffe 88012265f430 88000585bdb8 812357cd 8800a8918250 8801226514d0 88000585bf38 88000585bde8 811bb30d Call Trace: [] sysfs_lookup+0x6d/0xe0 [] lookup_real+0x1d/0x60 [] __lookup_hash+0x38/0x50 [] lookup_hash+0x19/0x20 [] kern_path_create+0x93/0x170 [] ? getname_flags.part.32+0x86/0x150 [] user_path_create+0x4a/0x70 [] sys_mkdirat+0x39/0xe0 [] system_call_fastpath+0x16/0x1b Code: 00 48 8b 9f 88 00 00 00 f6 c4 0f 0f 95 c0 48 85 f6 0f 95 c2 38 d0 75 79 4c 89 ee 4c 89 f7 e8 91 ef ff ff 41 89 c4 48 85 db 74 1d <8b> 4b 28 41 39 cc 74 21 44 89 e0 29 c8 83 f8 00 7c 2c 74 45 48 RIP [] sysfs_find_dirent+0x47/0xf0 RSP ---[ end trace 4ba97703eaafbb8b ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] perf, tools: Define MADV_*HUGEPAGE for old kernels
Hi Andi, On Wed, 6 Mar 2013 15:19:16 -0800, Andi Kleen wrote: > From: Andi Kleen > > Avoids this on RHEL6: > > bench/numa.c: In function ‘alloc_data’: > bench/numa.c:334: error: ‘MADV_HUGEPAGE’ undeclared (first use in this > function) > bench/numa.c:334: error: (Each undeclared identifier is reported only once > bench/numa.c:334: error: for each function it appears in.) > bench/numa.c:341: error: ‘MADV_NOHUGEPAGE’ undeclared (first use in this > function) The fix was posted already but there's an issue also. Please see https://lkml.org/lkml/2013/3/6/2 Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] ssbi: Fix exit mismatch in remove function
Greg Kroah-Hartman writes: > On Wed, Mar 06, 2013 at 04:29:44PM -0800, David Brown wrote: >> msm_ssbi_remove is referenced with __exit_p, but not declared with >> __exit. This causes a warning when the driver is not built as a >> module: >> >> drivers/ssbi/ssbi.c:341:23: warning: 'msm_ssbi_remove' defined but not used >> [-Wunused-function] >> >> Fix by adding the __exit declaration to the function. >> >> Signed-off-by: David Brown >> --- >> drivers/ssbi/ssbi.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/ssbi/ssbi.c b/drivers/ssbi/ssbi.c >> index 86d8416..4d503da 100644 >> --- a/drivers/ssbi/ssbi.c >> +++ b/drivers/ssbi/ssbi.c >> @@ -337,7 +337,7 @@ err_get_mem_res: >> return ret; >> } >> >> -static int msm_ssbi_remove(struct platform_device *pdev) >> +static int __exit msm_ssbi_remove(struct platform_device *pdev) > > No, remove the __exit_p marking instead, unless you want your kernel to > be oopsed :) Thanks. Oopsing is not fun. David -- sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] platform-drivers: msm: add single-wire serial bus interface (SSBI) driver
Greg Kroah-Hartman writes:
> On Wed, Mar 06, 2013 at 04:29:42PM -0800, David Brown wrote:
>> +menu "Qualcomm MSM SSBI bus support"
>> +depends on ARCH_MSM
>
> Why?
In the sense that ARCH_MSM are the only devices that ever were, or ever
will be made with this device. It doesn't strictly depend on it, but do
we want to clutter the config for everything else.
>> +config MSM_SSBI
>> +bool "Qualcomm Single-wire Serial Bus Interface (SSBI)"
>
> Why can't this be a module?
Without this device, the PMIC drivers won't work, regulators can't be
turned on, and most of the other devices won't work. I can try if it
can still be made a module, and it might be good at exercising the
deferred probe mechanism.
So, a deeper question. I've resent this driver with minimal change.
I've also made some other changes as patches afterwards. Do we want
these squashed into a single patch, or the initial one (not authored by
me) followed by updates?
>> +#
>> +# Makefile for the MSM specific device drivers.
>
> MSM?
>
> No comment needed at all in this file :)
Thanks, missed this. I think the original patch was using platform/msm,
and the minimalist comment almost made sense in that context.
>> +struct msm_ssbi {
>> +struct device *dev;
>> +struct device *slave;
>
> Really? Two pointers to devices? Why? Shouldn't this have a struct
> device embedded in it instead of the dev member being a pointer?
I'll go through this more thoroughly and organize things better.
>> +static int ssbi_wait_mask(struct msm_ssbi *ssbi, u32 set_mask, u32 clr_mask)
>> +{
>> +u32 timeout = SSBI_TIMEOUT_US;
>> +u32 val;
>> +
>> +while (timeout--) {
>> +val = ssbi_readl(ssbi, SSBI2_STATUS);
>> +if (((val & set_mask) == set_mask) && ((val & clr_mask) == 0))
>> +return 0;
>> +udelay(1);
>
> Busy loop? Really?
I'm not sure what else to do here. The controller is only slightly more
than a bit-banged bus. I think the reason for the longer possibly delay
is because there is an arbiter (the PMIC is shared with the radio CPU).
I'll investigate further.
>> +}
>> +
>> +dev_err(ssbi->dev, "%s: timeout (status %x set_mask %x clr_mask %x)\n",
>> +__func__, ssbi_readl(ssbi, SSBI2_STATUS), set_mask, clr_mask);
>
> Why polute the log with this? What can a user do with it?
Nothing in fact, other than possibly learn that things, indeed aren't
working. I'll take it and the others out.
>> +static int
>> +msm_ssbi_write_bytes(struct msm_ssbi *ssbi, u16 addr, u8 *buf, int len)
>> +{
>> +int ret = 0;
>> +
>> +if (ssbi->controller_type == MSM_SBI_CTRL_SSBI2) {
>> +u32 mode2 = ssbi_readl(ssbi, SSBI2_MODE2);
>> +mode2 = SET_SSBI_MODE2_REG_ADDR_15_8(mode2, addr);
>> +ssbi_writel(ssbi, mode2, SSBI2_MODE2);
>> +}
>
> Perhaps have a controller type write function that can handle this type
> of stuff instead of putting it in the "generic" write path?
Yes, that's a better approach.
>> +EXPORT_SYMBOL(msm_ssbi_read);
>
> msm_*? Why not just ssbi_*?
I'm fine with ssbi. It is very MSM specific, though.
> EXPORT_SYMBOL_GPL()?
Yes, it's definitely a kernel internal API.
>> +static struct platform_driver msm_ssbi_driver = {
>> +.probe = msm_ssbi_probe,
>> +.remove = __exit_p(msm_ssbi_remove),
>
> You just oopsed if someone unbound your device from the driver from
> userspace. Not good.
I did catch this one in a later patch :-) I can clean it up in the
driver, though, since it looks like some more work needs to go into
this.
Thanks,
David
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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] KEYS: Fix race with concurrent install_user_keyrings()
On Wed, 6 Mar 2013, David Howells wrote: > Reported-by: Mateusz Guzik > Signed-off-by: David Howells Acked-by: James Morris -- James Morris -- 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] Select VIRT_TO_BUS directly where needed
In commit 887cbce0adea ("arch Kconfig: centralise
CONFIG_ARCH_NO_VIRT_TO_BUS") I introduced the config sybmol
HAVE_VIRT_TO_BUS and selected that where needed. I am not sure what I was
thinking. Instead, just directly select VIRT_TO_BUS where it is needed.
Signed-off-by: Stephen Rothwell
---
arch/Kconfig| 7 ---
arch/alpha/Kconfig | 2 +-
arch/arm/Kconfig| 2 +-
arch/avr32/Kconfig | 2 +-
arch/blackfin/Kconfig | 2 +-
arch/cris/Kconfig | 2 +-
arch/frv/Kconfig| 2 +-
arch/h8300/Kconfig | 2 +-
arch/ia64/Kconfig | 2 +-
arch/m32r/Kconfig | 2 +-
arch/m68k/Kconfig | 2 +-
arch/microblaze/Kconfig | 2 +-
arch/mips/Kconfig | 2 +-
arch/mn10300/Kconfig| 2 +-
arch/openrisc/Kconfig | 2 +-
arch/parisc/Kconfig | 2 +-
arch/powerpc/Kconfig| 2 +-
arch/s390/Kconfig | 2 +-
arch/score/Kconfig | 2 +-
arch/tile/Kconfig | 2 +-
arch/unicore32/Kconfig | 2 +-
arch/x86/Kconfig| 2 +-
arch/xtensa/Kconfig | 2 +-
mm/Kconfig | 8 ++--
24 files changed, 28 insertions(+), 31 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 5a1779c..1455579 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -319,13 +319,6 @@ config ARCH_WANT_OLD_COMPAT_IPC
select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
bool
-config HAVE_VIRT_TO_BUS
- bool
- help
- An architecture should select this if it implements the
- deprecated interface virt_to_bus(). All new architectures
- should probably not select this.
-
config HAVE_ARCH_SECCOMP_FILTER
bool
help
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 5833aa4..8a33ba0 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -9,7 +9,7 @@ config ALPHA
select HAVE_PERF_EVENTS
select HAVE_DMA_ATTRS
select HAVE_GENERIC_HARDIRQS
- select HAVE_VIRT_TO_BUS
+ select VIRT_TO_BUS
select GENERIC_IRQ_PROBE
select AUTO_IRQ_AFFINITY if SMP
select GENERIC_IRQ_SHOW
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b71469..fc6fe23 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -49,7 +49,7 @@ config ARM
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_UID16
- select HAVE_VIRT_TO_BUS
+ select VIRT_TO_BUS
select KTIME_SCALAR
select PERF_USE_VMALLOC
select RTC_LIB
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index 9b89257..c1a868d 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -7,7 +7,7 @@ config AVR32
select HAVE_OPROFILE
select HAVE_KPROBES
select HAVE_GENERIC_HARDIRQS
- select HAVE_VIRT_TO_BUS
+ select VIRT_TO_BUS
select GENERIC_IRQ_PROBE
select GENERIC_ATOMIC64
select HARDIRQS_SW_RESEND
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index 600494c..c3f2e0b 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -33,7 +33,7 @@ config BLACKFIN
select ARCH_HAVE_CUSTOM_GPIO_H
select ARCH_WANT_OPTIONAL_GPIOLIB
select HAVE_UID16
- select HAVE_VIRT_TO_BUS
+ select VIRT_TO_BUS
select ARCH_WANT_IPC_PARSE_VERSION
select HAVE_GENERIC_HARDIRQS
select GENERIC_ATOMIC64
diff --git a/arch/cris/Kconfig b/arch/cris/Kconfig
index bb0ac66..06dd026 100644
--- a/arch/cris/Kconfig
+++ b/arch/cris/Kconfig
@@ -43,7 +43,7 @@ config CRIS
select GENERIC_ATOMIC64
select HAVE_GENERIC_HARDIRQS
select HAVE_UID16
- select HAVE_VIRT_TO_BUS
+ select VIRT_TO_BUS
select ARCH_WANT_IPC_PARSE_VERSION
select GENERIC_IRQ_SHOW
select GENERIC_IOMAP
diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig
index 12369b1..2ce731f 100644
--- a/arch/frv/Kconfig
+++ b/arch/frv/Kconfig
@@ -6,7 +6,7 @@ config FRV
select HAVE_PERF_EVENTS
select HAVE_UID16
select HAVE_GENERIC_HARDIRQS
- select HAVE_VIRT_TO_BUS
+ select VIRT_TO_BUS
select GENERIC_IRQ_SHOW
select HAVE_DEBUG_BUGVERBOSE
select ARCH_HAVE_NMI_SAFE_CMPXCHG
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index ae8551e..79250de 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -5,7 +5,7 @@ config H8300
select HAVE_GENERIC_HARDIRQS
select GENERIC_ATOMIC64
select HAVE_UID16
- select HAVE_VIRT_TO_BUS
+ select VIRT_TO_BUS
select ARCH_WANT_IPC_PARSE_VERSION
select GENERIC_IRQ_SHOW
select GENERIC_CPU_DEVICES
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 33f3fdc..9a02f71 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -26,7 +26,7 @@ config IA64
select HAVE_MEMBLOCK
select HAVE_MEMBLOCK_NODE_MAP
select HAVE_VIRT_CPU_ACCOUNTING
- select HAVE_VIRT_TO_BUS
+ select VIRT_TO_BUS
select ARCH_DISCARD_MEMBLOCK
select GENERIC_IRQ_
Suggestion for fixing the variable length array used in the kernel.
Hi,
I am looking at the current sparse warning on the kernel source.
One category of those warning are produce by the variable length array.
We all know that the kernel stack has a limit so we don't want to allocate
too much stack to the variable size array.
Is there a recommended way to fix those warnings? Is it worth while to
fix it at all? I am looking forward to some kind of guideline how to handle
this.
Some of them has estimated size limited, like the one fournd in decode_rs.c
/* Err+Eras Locator poly and syndrome poly The maximum value
* of nroots is 8. So the necessary stack size will be about
* 220 bytes max.
*/
uint16_t lambda[nroots + 1], syn[nroots];
uint16_t b[nroots + 1], t[nroots + 1], omega[nroots + 1];
uint16_t root[nroots], reg[nroots + 1], loc[nroots];
Some of them did not said the size estimation but you kind of know
they are not likely to blow up the stack:
In xen_flush_tlb_others
struct {
struct mmuext_op op;
#ifdef CONFIG_SMP
DECLARE_BITMAP(mask, num_processors);
#else
DECLARE_BITMAP(mask, NR_CPUS);
#endif
} *args;
And also some of them are harder to tell from the context if
there will be a size limit:
int snd_pcm_hw_refine(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
unsigned int k;
struct snd_pcm_hardware *hw;
struct snd_interval *i = NULL;
struct snd_mask *m = NULL;
struct snd_pcm_hw_constraints *constrs =
&substream->runtime->hw_constraints;
unsigned int rstamps[constrs->rules_num];
<-
Chris
--
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 0/3] Enable multiple MSI feature in pSeries
Hi all Any comments? or any questions about my patchset? Thanks Mike 在 2013-01-15二的 15:38 +0800，Mike Qiu写道： > Currently, multiple MSI feature hasn't been enabled in pSeries, > These patches try to enbale this feature. > > These patches have been tested by using ipr driver, and the driver patch > has been made by Wen Xiong : > > [PATCH 0/7] Add support for new IBM SAS controllers > > Test platform: One partition of pSeries with one cpu core(4 SMTs) and >RAID bus controller: IBM PCI-E IPR SAS Adapter (ASIC) in POWER7 > OS version: SUSE Linux Enterprise Server 11 SP2 (ppc64) with 3.8-rc3 kernel > > IRQ 21 and 22 are assigned to the ipr device which support 2 mutiple MSI. > > The test results is shown by 'cat /proc/interrups': > CPU0 CPU1 CPU2 CPU3 > 16: 240458 261601 226310 200425 XICS Level IPI > 17: 0 0 0 0 XICS Level RAS_EPOW > 18: 10 0 3 2 XICS Level > hvc_console > 19: 122182 28481 28527 28864 XICS Level ibmvscsi > 20:5067388226108118 XICS Level eth0 > 21: 6 5 5 5 XICS Level host1-0 > 22:817814816813 XICS Level host1-1 > LOC: 398077 316725 231882 203049 Local timer interrupts > SPU: 1659919961903 Spurious interrupts > CNT: 0 0 0 0 Performance > monitoring interrupts > MCE: 0 0 0 0 Machine check exceptions > > Mike Qiu (3): > irq: Set multiple MSI descriptor data for multiple IRQs > irq: Add hw continuous IRQs map to virtual continuous IRQs support > powerpc/pci: Enable pSeries multiple MSI feature > > arch/powerpc/kernel/msi.c|4 -- > arch/powerpc/platforms/pseries/msi.c | 62 - > include/linux/irq.h |4 ++ > include/linux/irqdomain.h|3 ++ > kernel/irq/chip.c| 40 - > kernel/irq/irqdomain.c | 61 + > 6 files changed, 158 insertions(+), 16 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/
[PATCH] vhost_net: remove tx polling state
After commit 2b8b328b61c799957a456a5a8dab8cc7dea68575 (vhost_net: handle polling
errors when setting backend), we in fact track the polling state through
poll->wqh, so there's no need to duplicate the work with an extra
vhost_net_polling_state. So this patch removes this and make the code simpler.
Signed-off-by: Jason Wang
---
drivers/vhost/net.c | 60
drivers/vhost/vhost.c |3 ++
2 files changed, 13 insertions(+), 50 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 959b1cd..d1a03dd 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -64,20 +64,10 @@ enum {
VHOST_NET_VQ_MAX = 2,
};
-enum vhost_net_poll_state {
- VHOST_NET_POLL_DISABLED = 0,
- VHOST_NET_POLL_STARTED = 1,
- VHOST_NET_POLL_STOPPED = 2,
-};
-
struct vhost_net {
struct vhost_dev dev;
struct vhost_virtqueue vqs[VHOST_NET_VQ_MAX];
struct vhost_poll poll[VHOST_NET_VQ_MAX];
- /* Tells us whether we are polling a socket for TX.
-* We only do this when socket buffer fills up.
-* Protected by tx vq lock. */
- enum vhost_net_poll_state tx_poll_state;
/* Number of TX recently submitted.
* Protected by tx vq lock. */
unsigned tx_packets;
@@ -155,28 +145,6 @@ static void copy_iovec_hdr(const struct iovec *from,
struct iovec *to,
}
}
-/* Caller must have TX VQ lock */
-static void tx_poll_stop(struct vhost_net *net)
-{
- if (likely(net->tx_poll_state != VHOST_NET_POLL_STARTED))
- return;
- vhost_poll_stop(net->poll + VHOST_NET_VQ_TX);
- net->tx_poll_state = VHOST_NET_POLL_STOPPED;
-}
-
-/* Caller must have TX VQ lock */
-static int tx_poll_start(struct vhost_net *net, struct socket *sock)
-{
- int ret;
-
- if (unlikely(net->tx_poll_state != VHOST_NET_POLL_STOPPED))
- return 0;
- ret = vhost_poll_start(net->poll + VHOST_NET_VQ_TX, sock->file);
- if (!ret)
- net->tx_poll_state = VHOST_NET_POLL_STARTED;
- return ret;
-}
-
/* In case of DMA done not in order in lower device driver for some reason.
* upend_idx is used to track end of used idx, done_idx is used to track head
* of used idx. Once lower device DMA done contiguously, we will signal KVM
@@ -231,6 +199,7 @@ static void vhost_zerocopy_callback(struct ubuf_info *ubuf,
bool success)
static void handle_tx(struct vhost_net *net)
{
struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
+ struct vhost_poll *poll = net->poll + VHOST_NET_VQ_TX;
unsigned out, in, s;
int head;
struct msghdr msg = {
@@ -256,7 +225,7 @@ static void handle_tx(struct vhost_net *net)
wmem = atomic_read(&sock->sk->sk_wmem_alloc);
if (wmem >= sock->sk->sk_sndbuf) {
mutex_lock(&vq->mutex);
- tx_poll_start(net, sock);
+ vhost_poll_start(poll, sock->file);
mutex_unlock(&vq->mutex);
return;
}
@@ -265,7 +234,7 @@ static void handle_tx(struct vhost_net *net)
vhost_disable_notify(&net->dev, vq);
if (wmem < sock->sk->sk_sndbuf / 2)
- tx_poll_stop(net);
+ vhost_poll_stop(poll);
hdr_size = vq->vhost_hlen;
zcopy = vq->ubufs;
@@ -287,7 +256,7 @@ static void handle_tx(struct vhost_net *net)
wmem = atomic_read(&sock->sk->sk_wmem_alloc);
if (wmem >= sock->sk->sk_sndbuf * 3 / 4) {
- tx_poll_start(net, sock);
+ vhost_poll_start(poll, sock->file);
set_bit(SOCK_ASYNC_NOSPACE, &sock->flags);
break;
}
@@ -298,7 +267,7 @@ static void handle_tx(struct vhost_net *net)
(vq->upend_idx - vq->done_idx) :
(vq->upend_idx + UIO_MAXIOV - vq->done_idx);
if (unlikely(num_pends > VHOST_MAX_PEND)) {
- tx_poll_start(net, sock);
+ vhost_poll_start(poll, sock->file);
set_bit(SOCK_ASYNC_NOSPACE, &sock->flags);
break;
}
@@ -364,7 +333,7 @@ static void handle_tx(struct vhost_net *net)
}
vhost_discard_vq_desc(vq, 1);
if (err == -EAGAIN || err == -ENOBUFS)
- tx_poll_start(net, sock);
+ vhost_poll_start(poll, sock->file);
break;
}
if (err != len)
@@ -627,7 +596,6 @@ static int vhost_net_open(struct inode *inode, struct file
*f)
vhost_poll_init(n->poll + VHOST_NET_VQ_TX, handle_tx_net, POLLOUT, dev);
vhost_poll_init(n->poll + VHOST_N
Re: change of behavior for madvise in 3.9-rc1
On Wed, Mar 06, 2013 at 11:05:04PM -0500, CAI Qian wrote: > Bisecting indicated that this commit, > 1998cc048901109a29924380b8e91bc049b32951 > mm: make madvise(MADV_WILLNEED) support swap file prefetch > > Caused an LTP test failure, > http://goo.gl/1FVPy > > madvise021 TPASS : failed as expected: TEST_ERRNO=EINVAL(22): Invalid > argument > madvise022 TPASS : failed as expected: TEST_ERRNO=EINVAL(22): Invalid > argument > madvise023 TPASS : failed as expected: TEST_ERRNO=EINVAL(22): Invalid > argument > madvise024 TPASS : failed as expected: TEST_ERRNO=ENOMEM(12): Cannot > allocate memory > madvise025 TFAIL : madvise succeeded unexpectedly > > While it passed without the above commit > madvise021 TPASS : failed as expected: TEST_ERRNO=EINVAL(22): Invalid > argument > madvise022 TPASS : failed as expected: TEST_ERRNO=EINVAL(22): Invalid > argument > madvise023 TPASS : failed as expected: TEST_ERRNO=EINVAL(22): Invalid > argument > madvise024 TPASS : failed as expected: TEST_ERRNO=ENOMEM(12): Cannot > allocate memory > madvise025 TPASS : failed as expected: TEST_ERRNO=EBADF(9): Bad file > descriptor I thought this is expected behavior. madvise(MADV_WILLNEED) to anonymous memory doesn't return -EBADF now, as now we support swap prefretch. Thanks, Shaohua -- 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] AB8500 Power and MFD related updates
The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: Linux 3.9-rc1 (2013-03-03 15:11:05 -0800) are available in the git repository at: git://git.linaro.org/people/ljones/linux-3.0-ux500.git for-mfd-and-power for you to fetch changes up to b09f86dbfc20d9420dac43dba016cb65b582c983: ab8500-charger: Do not use [delayed_]work_pending() (2013-03-07 12:35:59 +0800) Daniel WILLERUD (1): mfd: ab8500-gpadc: Implemented suspend/resume Dariusz Szymczak (1): mfd: ab8500-core: Hierarchical interrupt registers Hakan Berg (3): ab8500-btemp: Filter btemp readings ab8500-fg: Allow capacity to raise from 1% when charging ab8500-charger: Add AB8505_USB_LINK_STATUS Jonas Aaberg (3): mfd: ab8500-gpadc: Reread on failure mfd: ab8500-debug: Better error handling on crash mfd: ab8500-debug: Add wake-up info Lee Jones (33): mfd: ab8500-gpadc: Add gpadc hw conversion mfd: ab8500-core: APE Interrupts are not cleared mfd: ab8500-debug: Function to save all ABB registers to mem mfd: ab8500-core: Add ADC support for ab8540 mfd: ab8500-core: Rework MFD sub-device initialisation structures mfd: ab8500-core: Add Interrupt support for ab8540 mfd: ab8500-debugfs: Add tests for ab8540 based platform initialisations mfd: ab8500-debug: Add support for ab8505 and ab9540 mfd: ab8500-sysctrl: Add new reset function mfd: ab8500-gpadc: Add support for the AB8540 mfd: ab8500-debug: Add support for the AB8540 mfd: ab8500-gpadc: Optimise GPADC driver mfd: ab8500-core: Add additional resources to ab8505_iddet_resources mfd: ab8500-debugfs: Dump sim registers mfd: ab8500-debug: Add ADC input channel usb_id in debugfs mfd: ab8500-debugfs: Change AB8500 debug permissions mfd: ab8500-debug: Add register map for ab8540. mfd: ab8500-debugfs: Trivially beautify the debugfs driver pm2301_charger: Remove __exit, __init and __devexit_p() abx500-chargalg: Store the AB8500 MFD parent device for platform differentiation ab8500-fg: Add power cut feature for ab8505 and ab8540 ab8500-charger: Trivial coding style changes ab8500-bm: Quick re-attach charging behaviour ab8500-bm: Charge only mode fixes for the ab9540 ab8500_charger: Prevent auto drop of VBUS ab8500-bm: Add usb power path support ab8500-bm: Add support for the new ab8540 platform abx500-chargalg: Prevent the watchdog from being kicked twice ab8500-chargalg: Use hrtimer pm2301-charger: Add pm_runtime_resume & pm_runtime_suspend ab8500-charger: Remove duplicate code abx500-chargalg: Add charging current step interface ab8500-charger: Do not use [delayed_]work_pending() Linus Walleij (1): mfd: ab8500-debug: Add explicit dependencies M BenZoubeir (1): pm2301-charger: Adjust interrupt handler behavior Marcus Cooper (4): pm2301-charger: Always compile the PM2301 Charger driver with AB8500 Battery Mgnt ab8500-charger: Use USBLink1Status Register ab8500-charger: Add UsbLineCtrl2 reference ab8500-bm: Trivially fix up some incorrect and out-of-date comments Marcus Danielsson (1): mfd: ab8500-sysctrl: Error check clean up Martin Bergstrom (1): ab8500-fg: Report unscaled capacity Mattias Wallin (2): mfd: ab8500-debug: Print banks in hex mfd: ab8500-core: Show turn on status at boot Mustapha Ben Zoubeir (1): pm2301-charger: Resolve I2C detection problem on ab9540 Per Forlin (1): pm2301-charger: Force main charger detect Rabin Vincent (2): mfd: ab8500-sysctrl: AB8505 doesn't have SYSCLKREQ5..8 ab8500-charger: Run detect workaround only on AB8500 Rajkumar Kasirajan (2): mfd: ab8500-sysctrl: Update correct turn on status pm2301-charger: Enable SW EOC control on the ab9540 Rupesh Kumar (8): pm2301-charger: Support for over voltage protection on the ab9540 pm2301-charger: Die temp thermal protection pm2301-charger: Wake system when ext charger is plugged-in ab8500-btemp: Defer btemp filtering while initialising pm2301-charger: Removed unused code from PM2301 driver pm2301-charger: Charging LED control for pm2301 pm2301-charger: Wake device on register access pm2301-charger: Reference put missing after access Ulf Hansson (1): mfd: ab8500-core: Add abx500-clk as an mfd child device Yang QU (1): ab8500-charger: Add backup battery charge voltages on the ab8540 lme00437 (2): pm2301-charger: lpn pin used only in C2C boards ab8500-fg: Change current calculation srinidhi kasagar (2): mfd: ab8500-debug: Convert to kstrtoul_from_user abx500-chargalg: Use module_platform_driver() rather drivers/mfd/ab8500-core.c | 544 - drivers/mfd/ab8500-debug
Re: [PATCH] Be explicit about what the x86 0x020c boot parameter version requires.
On 03/06/2013 10:00 AM, Peter Jones wrote: > This should help avoid making the incorrect change in non-compliant > bootloaders. > > Signed-off-by: Peter Jones > --- > Documentation/x86/boot.txt | 5 +++-- > arch/x86/include/asm/bootparam_utils.h | 7 +++ > 2 files changed, 10 insertions(+), 2 deletions(-) > > diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt > index 3840b6f..72702db 100644 > --- a/Documentation/x86/boot.txt > +++ b/Documentation/x86/boot.txt > @@ -1110,7 +1110,8 @@ firmware, 'table' is the EFI system table - these are > the first two > arguments of the "handoff state" as described in section 2.3 of the > UEFI specification. 'bp' is the boot loader-allocated boot params. > > -The boot loader *must* fill out the following fields in bp, > +The boot loader *must* zero the entirity of bp, and then fill out the > +following fields: > > o hdr.code32_start > o hdr.cmd_line_ptr > @@ -1118,4 +1119,4 @@ The boot loader *must* fill out the following fields in > bp, > o hdr.ramdisk_image (if applicable) > o hdr.ramdisk_size (if applicable) > Wait a bloody minute here... I seem to have managed to miss something big. Matt, should we not be copying the setup part of the structure just as we do for the normal 32/64-bit protocol? If not, why not? -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] perf: Reset detached siblings' group_flags
From: Namhyung Kim Currently if a group_leader event is deleted, the sibling events are upgraded to singleton events of a same group list. At this time, the siblings inherit the leader's group_flags. However, if the group has mixed hw/sw events the leader's group_flag does not contain PERF_GROUP_SOFTWARE so sibling sw events will miss the flag also. Fix it. Cc: Jiri Olsa Cc: Frederic Weisbecker Signed-off-by: Namhyung Kim --- kernel/events/core.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 5c75791d7269..007dfe846d4d 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -1107,8 +1107,9 @@ static void perf_group_detach(struct perf_event *event) list_move_tail(&sibling->group_entry, list); sibling->group_leader = sibling; - /* Inherit group flags from the previous leader */ - sibling->group_flags = event->group_flags; + /* Reset group flags for each siblings */ + sibling->group_flags = is_software_event(sibling) ? + PERF_GROUP_SOFTWARE : 0; } out: -- 1.7.11.7 -- 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/2] perf: Fix mixed hw/sw event group initialization
From: Namhyung Kim
There's a problem with mixed hw/sw group when the leader is a software
event. For instance:
$ perf stat -e '{task-clock,cycles,faults}' sleep 1
Performance counter stats for 'sleep 1':
0.273436 task-clock#0.000 CPUs utilized
962,965 cycles#3.522 GHz
faults
1.000804279 seconds time elapsed
Jiri's patch 0231bb533675 ("perf: Fix event group context move") fixed
a part of problem but there's a devil still..
The problem arose when a sw event is added to already moved (to hw
context) group whose leader also is a sw event. In the above example
1. task-clock (sw event) is a group leader (has PERF_GROUP_SOFTWARE)
2. cycles (hw event) is added, so the leader moved to the hw context
3. faults (sw event) is added but the leader also is a sw event
4. after find_get_context(), ctx is not same as leader->ctx since the
leader had moved to the hw context (-EINVAL)
Fix it by adding new PERF_GROUP_MIXED flag and use leader's ctx->pmu
if it's set.
$ perf -state -e '{task-clock,cycles,faults}' sleep 1
Performance counter stats for 'sleep 1':
0.670405 task-clock#0.001 CPUs utilized
933,264 cycles#1.392 GHz
176 faults#0.263 M/sec
1.001506178 seconds time elapsed
Reported-by: Andreas Hollmann
Cc: Jiri Olsa
Cc: Vince Weaver
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
include/linux/perf_event.h | 1 +
kernel/events/core.c | 37 ++---
2 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index e47ee462c2f2..001a3b64fe61 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -285,6 +285,7 @@ typedef void (*perf_overflow_handler_t)(struct perf_event *,
enum perf_group_flag {
PERF_GROUP_SOFTWARE = 0x1,
+ PERF_GROUP_MIXED= 0x2,
};
#define SWEVENT_HLIST_BITS 8
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 007dfe846d4d..06266d5ed500 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6441,6 +6441,8 @@ out:
* @pid: target pid
* @cpu: target cpu
* @group_fd: group leader event fd
+ * @flags: flags which controls the meaning of arguments.
+ * see PERF_FLAG_*
*/
SYSCALL_DEFINE5(perf_event_open,
struct perf_event_attr __user *, attr_uptr,
@@ -6536,26 +6538,30 @@ SYSCALL_DEFINE5(perf_event_open,
*/
pmu = event->pmu;
- if (group_leader &&
- (is_software_event(event) != is_software_event(group_leader))) {
- if (is_software_event(event)) {
- /*
-* If event and group_leader are not both a software
-* event, and event is, then group leader is not.
-*
-* Allow the addition of software events to !software
-* groups, this is safe because software events never
-* fail to schedule.
-*/
- pmu = group_leader->pmu;
- } else if (is_software_event(group_leader) &&
- (group_leader->group_flags & PERF_GROUP_SOFTWARE)) {
+ if (group_leader) {
+ if (group_leader->group_flags & PERF_GROUP_SOFTWARE) {
/*
* In case the group is a pure software group, and we
* try to add a hardware event, move the whole group to
* the hardware context.
*/
- move_group = 1;
+ if (!is_software_event(event))
+ move_group = 1;
+ } else if (group_leader->group_flags & PERF_GROUP_MIXED) {
+ /*
+* The group leader was moved on to a hardware context,
+* so move this event also.
+*/
+ if (is_software_event(event))
+ pmu = group_leader->ctx->pmu;
+ } else if (!is_software_event(group_leader)) {
+ /*
+* Allow the addition of software events to !software
+* groups, this is safe because software events never
+* fail to schedule.
+*/
+ if (is_software_event(event))
+ pmu = group_leader->pmu;
}
}
@@ -6650,6 +6656,7 @@ SYSCALL_DEFINE5(perf_event_open,
perf_install_in_context(ctx, sibling, event->cpu);
get_
[PATCH 1/2] mmc: omap_hsmmc: set max_segs based on dma engine limits
The EDMA DMAC has a hardware limitation that prevents supporting scatter gather lists with any number of segments. The DMA Engine API reports the maximum number of segments a channel can support via the optional dma_get_slave_sg_limits() API. If the max_nr_segs limit is present, the value is used to configure mmc->max_segs appropriately. Signed-off-by: Matt Porter Acked-by: Tony Lindgren --- drivers/mmc/host/omap_hsmmc.c |8 1 file changed, 8 insertions(+) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index e79b12d..f74d2ef 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1769,6 +1769,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev) const struct of_device_id *match; dma_cap_mask_t mask; unsigned tx_req, rx_req; + struct dma_slave_sg_limits *dma_sg_limits; struct pinctrl *pinctrl; match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev); @@ -1935,6 +1936,13 @@ static int omap_hsmmc_probe(struct platform_device *pdev) goto err_irq; } + /* Some DMA Engines only handle a limited number of SG segments */ + dma_sg_limits = dma_get_slave_sg_limits(host->rx_chan, + DMA_SLAVE_BUSWIDTH_4_BYTES, + mmc->max_blk_size / 4); + if (dma_sg_limits && dma_sg_limits->max_seg_nr) + mmc->max_segs = dma_sg_limits->max_seg_nr; + /* Request IRQ for MMC operations */ ret = request_irq(host->irq, omap_hsmmc_irq, 0, mmc_hostname(mmc), host); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARM: dts: add AM33XX MMC support
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk.
Signed-off-by: Matt Porter
Acked-by: Tony Lindgren
---
arch/arm/boot/dts/am335x-bone.dts |7 +++
arch/arm/boot/dts/am335x-evm.dts |7 +++
arch/arm/boot/dts/am335x-evmsk.dts |7 +++
arch/arm/boot/dts/am33xx.dtsi | 28
4 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..a154ce0 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -120,6 +120,8 @@
};
ldo3_reg: regulator@5 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
@@ -136,3 +138,8 @@
&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&ldo3_reg>;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d649644..2907da6 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -232,6 +232,8 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
};
@@ -244,3 +246,8 @@
&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&vmmc_reg>;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..f050c46 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -244,7 +244,14 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
};
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&vmmc_reg>;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c3c781a..e029eea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -234,6 +234,34 @@
status = "disabled";
};
+ mmc1: mmc@4806 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc1";
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = <&edma 24
+ &edma 25>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ mmc2: mmc@481d8000 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc2";
+ ti,needs-special-reset;
+ dmas = <&edma 2
+ &edma 3>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ mmc3: mmc@4781 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc3";
+ ti,needs-special-reset;
+ status = "disabled";
+ };
+
wdt2: wdt@44e35000 {
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] AM33xx mmc support
This series enable MMC support on AM33xx platforms. Support for platforms incorporating the EDMA DMAC is added using the dma_get_slave_sg_limits() api. AM33xx DTS supported is added for Beaglebone, AM335x-EVM, and AM335x-EVMSK. These patches were split out from the v5 version of the AM33xx DMA series and split from the generic DT/dmanegine omap_hsmmc changes. The series has the following dependencies: - edma private api error check fix http://www.spinics.net/lists/arm-kernel/msg227886.html - DMA Engine support for AM33XX http://www.spinics.net/lists/linux-omap/msg87634.html - omap_hsmmc DT DMA Client support http://www.spinics.net/lists/linux-omap/msg87623.html - dmaengine: add slave sg transfer limits api https://lkml.org/lkml/2013/3/6/462 Matt Porter (2): mmc: omap_hsmmc: set max_segs based on dma engine limits ARM: dts: add AM33XX MMC support arch/arm/boot/dts/am335x-bone.dts |7 +++ arch/arm/boot/dts/am335x-evm.dts |7 +++ arch/arm/boot/dts/am335x-evmsk.dts |7 +++ arch/arm/boot/dts/am33xx.dtsi | 28 drivers/mmc/host/omap_hsmmc.c |8 5 files changed, 57 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
they scale at same frequency. The nature of exynos5440 clock controller is
different from previous exynos controllers so not using the common exynos
cpufreq framework. The major difference being interrupt notfication for
frequency change. Also, OPP library is used for device tree parsing to get
different parameters like frequency, voltage etc. Since the opp library sorts
the frequency table in ascending order so they are again re-arranged in
descending order. This will have one-to-one mapping with the clock controller
state management logic.
Signed-off-by: Amit Daniel Kachhap
---
Changes in V3:
* Converted the driver to probe based as suggested by Viresh. This is also
beneficial for multiplatform kernel.
* Other coding guidelines related changes.
Changes in V2:
* Added OPP library support to parse DT parameters.
* Removed a hack to handle interrupts in bootup.
* Implemented other review comments from Viresh and Inder.
All these patches are dependent on Thomas Abraham common clock patches.
(http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15860.html)
This whole patch series is based on 3.9-rc1.
.../bindings/cpufreq/cpufreq-exynos5440.txt| 29 ++
drivers/cpufreq/Kconfig.arm|9 +
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/exynos5440-cpufreq.c | 467
4 files changed, 506 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 000..a0dbe0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,29 @@
+
+Exynos5440 cpufreq driver
+---
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- operating-points: Table of frequencies and voltage CPU could be transitioned
into,
+ in the decreasing order. Frequency should be in KHZ units and voltage
+ should be in microvolts.
+
+Optional properties:
+- clock-latency: Clock monitor latency in microsecond.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+
+ cpufreq@16 {
+ compatible = "samsung,exynos5440-cpufreq";
+ reg = <0x16 0x1000>;
+ interrupts = <0 57 0>;
+ operating-points = <
+ 100 975000
+ 80 925000>;
+ clock-latency = <10>;
+ };
+
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 030ddf6..7ed9c4a 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -77,6 +77,15 @@ config ARM_EXYNOS5250_CPUFREQ
This adds the CPUFreq driver for Samsung EXYNOS5250
SoC.
+config ARM_EXYNOS5440_CPUFREQ
+ def_bool SOC_EXYNOS5440
+ depends on HAVE_CLK && PM_OPP && OF
+ help
+ This adds the CPUFreq driver for Samsung EXYNOS5440
+ SoC. The nature of exynos5440 clock controller is
+ different than previous exynos controllers so not using
+ the common exynos framework.
+
config ARM_KIRKWOOD_CPUFREQ
def_bool ARCH_KIRKWOOD && OF
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 863fd18..c841438 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
new file mode 100644
index 000..ea3d46d
--- /dev/null
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -0,0 +1,467 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Amit Daniel Kachhap
+ *
+ * EXYNOS5440 - CPU frequency scaling support
+ *
+ * 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.
+*/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
Re: [PATCH 1/3] mfd: ab3100-otp: use module_platform_driver_probe()
On Tue, Mar 5, 2013 at 5:47 AM, Jingoo Han wrote: > This patch uses module_platform_driver_probe() macro which makes > the code smaller and simpler. > > Signed-off-by: Jingoo Han Acked-by: Linus Walleij Yours, Linus Walleij -- 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 4/4] dts: Add cpufreq controller node for Exynos5440 SoC
Add cpufreq controller device node for Exynos5440 SoC for passing
parameters like controller base address, interrupt and cpufreq
table. This node is added outside cpu0 as this driver is now a platform
driver and a new device structure is needed.
Signed-off-by: Amit Daniel Kachhap
---
Changes in V3:
* Moved the DT node outside cpu0 node as the driver is now a platform
driver.
arch/arm/boot/dts/exynos5440.dtsi | 12
arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index 5f3562a..4b29a5a 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -63,6 +63,18 @@
};
+ cpufreq@16 {
+ compatible = "samsung,exynos5440-cpufreq";
+ reg = <0x16 0x1000>;
+ interrupts = <0 57 0>;
+ operating-points = <
+ /* KHZuV */
+ 120 1025000
+ 100 975000
+ 80 925000
+ >;
+ };
+
serial@B {
compatible = "samsung,exynos4210-uart";
reg = <0xB 0x1000>;
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index acaeb14..0a446c4 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -145,6 +145,8 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
static const struct of_dev_auxdata exynos5440_auxdata_lookup[] __initconst = {
OF_DEV_AUXDATA("samsung,exynos4210-uart", EXYNOS5440_PA_UART0,
"exynos4210-uart.0", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5440-cpufreq", 0x16,
+ "exynos5440-cpufreq", NULL),
{},
};
--
1.7.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 V3 2/4] cpufreq: exynos: Remove error return even if no soc is found
This patch helps to have single binary for exynos5440 and previous
exynos soc's. This change is needed for adding exynos5440 cpufreq driver
which does not uses exynos-cpufreq common file and adds it own driver.
Signed-off-by: Amit Daniel Kachhap
---
drivers/cpufreq/exynos-cpufreq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 78057a3..ee75997 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -297,7 +297,7 @@ static int __init exynos_cpufreq_init(void)
else if (soc_is_exynos5250())
ret = exynos5250_cpufreq_init(exynos_info);
else
- pr_err("%s: CPU type not found\n", __func__);
+ return 0;
if (ret)
goto err_vdd_arm;
--
1.7.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 V3 3/4] arm: exynos: Enable OPP library support for exynos5440
The OPP library support is needed for exynos5440 cpu frequency dynamic scaling driver. Signed-off-by: Amit Daniel Kachhap --- arch/arm/mach-exynos/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 70f94c8..d5dde07 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -72,10 +72,12 @@ config SOC_EXYNOS5440 bool "SAMSUNG EXYNOS5440" default y depends on ARCH_EXYNOS5 + select ARCH_HAS_OPP select ARM_ARCH_TIMER select AUTO_ZRELADDR select PINCTRL select PINCTRL_EXYNOS5440 + select PM_OPP help Enable EXYNOS5440 SoC support -- 1.7.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/
linux-next: Tree for Mar 7
Hi all, Changes since 20130306: The staging tree lost its build failure. The gpio tree still had its build failure for which I reverted a commit. 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 217 trees (counting Linus' and 28 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 (9f22578 Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc) Merging fixes/master (d287b87 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) Merging kbuild-current/rc-fixes (02f3e53 Merge branch 'yem-kconfig-rc-fixes' of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes) Merging arm-current/fixes (3f7d1fe ARM: 7665/1: Wire up kcmp syscall) Merging m68k-current/for-linus (5618395 m68k: Sort out !CONFIG_MMU_SUN3 vs. CONFIG_HAS_DMA) Merging powerpc-merge/merge (54c9b225 powerpc: Set DSCR bit in FSCR setup) Merging sparc/master (a295642 sparc,leon: fix GRPCI2 device0 PCI config space access) Merging net/master (f8af75f tun: add a missing nf_reset() in tun_net_xmit()) Merging ipsec/master (85dfb74 af_key: initialize satype in key_notify_policy_flush()) Merging sound-current/for-linus (85c50a5 ALSA: seq: seq_oss_event: missing range checks) Merging pci-current/for-linus (249bfb8 PCI/PM: Clean up PME state when removing a device) Merging wireless/master (930df2d Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless) Merging driver-core.current/driver-core-linus (6dbe51c Linux 3.9-rc1) Merging tty.current/tty-linus (34dcfb8 TTY: disable debugging warning) Merging usb.current/usb-linus (feca774 USB: EHCI: don't check DMA values in QH overlays) Merging staging.current/staging-linus (1223ad3 Merge tag 'iio-fixes-for-3.9a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (6dbe51c Linux 3.9-rc1) Merging input-current/for-linus (171fb58 Input: ALPS - update documentation for recent touchpad driver mods) Merging md-current/for-linus (f3378b4 md: expedite metadata update when switching read-auto -> active) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (8fd61d3 crypto: user - ensure user supplied strings are nul-terminated) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (084a0ec x86: add CONFIG_X86_MOVBE option) CONFLICT (content): Merge conflict in arch/x86/Kconfig CONFLICT (content): Merge conflict in arch/powerpc/Kconfig Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6) Merging devicetree-current/devicetree/merge (ab28698 of: define struct device in of_platform.h if !OF_DEVICE and !OF_ADDRESS) Merging spi-current/spi/merge (d3601e5 spi/sh-hspi: fix return value check in hspi_probe().) Merging gpio-current/gpio/merge (e97f9b5 gpio/gpio-ich: fix ichx_gpio_check_available() return what callers expect) Merging
Re: [PATCH v6 1/2] mfd: syscon: Removed unneeded field "dev" from private driver structure
> Signed-off-by: Alexander Shiyan
> ---
> drivers/mfd/syscon.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index 61aea63..674af14 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -25,17 +25,15 @@
> static struct platform_driver syscon_driver;
>
> struct syscon {
> - struct device *dev;
> void __iomem *base;
> struct regmap *regmap;
> };
>
> static int syscon_match(struct device *dev, void *data)
> {
> - struct syscon *syscon = dev_get_drvdata(dev);
> struct device_node *dn = data;
>
> - return (syscon->dev->of_node == dn) ? 1 : 0;
> + return (dev->of_node == dn) ? 1 : 0;
> }
>
> struct regmap *syscon_node_to_regmap(struct device_node *np)
> @@ -130,7 +128,6 @@ static int syscon_probe(struct platform_device *pdev)
> return PTR_ERR(syscon->regmap);
> }
>
> - syscon->dev = dev;
> platform_set_drvdata(pdev, syscon);
>
> dev_info(dev, "syscon regmap start 0x%x end 0x%x registered\n",
> --
> 1.7.12.4
ping
---
change of behavior for madvise in 3.9-rc1
Bisecting indicated that this commit, 1998cc048901109a29924380b8e91bc049b32951 mm: make madvise(MADV_WILLNEED) support swap file prefetch Caused an LTP test failure, http://goo.gl/1FVPy madvise021 TPASS : failed as expected: TEST_ERRNO=EINVAL(22): Invalid argument madvise022 TPASS : failed as expected: TEST_ERRNO=EINVAL(22): Invalid argument madvise023 TPASS : failed as expected: TEST_ERRNO=EINVAL(22): Invalid argument madvise024 TPASS : failed as expected: TEST_ERRNO=ENOMEM(12): Cannot allocate memory madvise025 TFAIL : madvise succeeded unexpectedly While it passed without the above commit madvise021 TPASS : failed as expected: TEST_ERRNO=EINVAL(22): Invalid argument madvise022 TPASS : failed as expected: TEST_ERRNO=EINVAL(22): Invalid argument madvise023 TPASS : failed as expected: TEST_ERRNO=EINVAL(22): Invalid argument madvise024 TPASS : failed as expected: TEST_ERRNO=ENOMEM(12): Cannot allocate memory madvise025 TPASS : failed as expected: TEST_ERRNO=EBADF(9): Bad file descriptor CAI Qian -- 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] ARM: keep __my_cpu_offset consistent with generic one
Hi, On Thu, Mar 7, 2013 at 11:44 AM, Will Deacon wrote: > > For the record, can you include a backtrace or something please? The lock_release_holdtime() will access percpu variable, so every lock release may trigger the hang if CONFIG_LOCK_STAT is enabled, and there are many lock acquire/release before setup_arch. No detailed backtrace since only early_printk can work at that time. > description makes it sounds like a caller bug, so it would be good to > document a valid user of per-cpu before cpu_init(). OK, I will add the document: lockdep will use percpu variable before cpu_init() called inside setup_arch(). Thanks, -- Ming Lei -- 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] ARM: keep __my_cpu_offset consistent with generic one
Hello, On Thu, Mar 07, 2013 at 02:47:48AM +, Ming Lei wrote: > Commit 14318efb(ARM: 7587/1: implement optimized percpu variable access) > introduces arm's __my_cpu_offset to optimize percpu vaiable access, > which really works well on hackbench test, but may cause __my_cpu_offset > to return garbage value before it is initialized in cpu_init() called > by setup_arch, so accessing a percpu variable before setup_arch may cause > kernel hang. But the generic__my_cpu_offset always returns zero before > percpu area is brought up. > > So the patch tries to clear __my_cpu_offset on boot CPU early > to avoid boot hang. > > At least now percpu variable is accessed by lockdep before > setup_arch(), and enabling CONFIG_LOCK_STAT or CONFIG_DEBUG_LOCKDEP > can trigger kernel hang. For the record, can you include a backtrace or something please? The description makes it sounds like a caller bug, so it would be good to document a valid user of per-cpu before cpu_init(). Will -- 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] gpio: Add device driver for GRGPIO cores and support custom accessors with gpio-generic
On Mon, Mar 4, 2013 at 10:46 AM, Andreas Larsson wrote:
> [Me]
>>> +struct grgpio_priv {
>>> + struct bgpio_chip bgc;
>>> + struct grgpio_regs __iomem *regs;
>>> +
>>> + u32 imask; /* irq mask shadow register */
>>> + s32 *irqmap;/* maps offset to irq or -1 if no irq */
>>
>>
>> irqmap? Argh what is this... I think you want to use irqdomain
>> for this instead. (Documentation/IRQ-domain.txt)
>
>
> Yeah, that comment is not clear. An entry in the irqmap array (for a gpio
> line) can be either -1 indicating no irq for that line or an index into the
> array of irq:s for the of device. Thus it is simply either -1 or a valid
> second argument to irq_of_parse_and_map.
So just make the mapping function in the irqdomain handle that?
Maybe I'm talking weird, I'm not really familiar with
irq_of_parse_and_map().
> Given that this is generally running on SPARC, it seems irqdomain is not an
> option (IRQ_DOMAIN is not selected by SPARC).
That has nothing to do with this. This driver can just select IRQ_DOMAIN
in *it's* Kconfig entry.
Using irqdomain for a certain irq_chip does not at all mandate that the
entire system has to use irqdomain for everything, and two wrongs does
not make one right.
> Given this, is just a better formulated comment OK with you in this case?
No...
Yours,
Linus Walleij
--
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.9-rc1: hz.bc compilation breakage
On 03/06/2013 06:36 AM, Maxime Ripard wrote:
> Hi,
>
> I'm compiling the kernel for an iMX28(ARM) board, and since 3.9-rc1, I
> get the following error at compilation time:
>
> make[3]: *** No rule to make target
> `/home/max/Work/2012/crystalfontz/rewrite/linux-dt/include/config/hz.h',
> needed by `kernel/hz.bc'. Stop.
>
> I'm doing a clean out-of-tree build, with the following configuration
> file: http://code.bulix.org/m4y7se-83102?raw
>
> Reverting commit 1b66e0fd ("kernel: Replace timeconst.pl with a bc
> script") make the compilation go on as usual.
>
That file should have been created by "make *config", and I just
verified that it does indeed do so. That file is a sentinel for
configuration changes; the entire build system depends on it.
I am not sure what you mean with "clean out-of-tree", however.
kbuild people: is there anything wrong with how this dependency is
specified?
-hpa
--
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 RFT] pinctrl: single: Fix build error
On Mon, Mar 4, 2013 at 6:47 AM, Axel Lin wrote: > If pcs->is_pinconf is false, it means does not support pinconf. > If pcs->is_pinconf is true, is_generic flag is always true. > > This patch fixes below build error: > > CC [M] drivers/pinctrl/pinctrl-single.o > drivers/pinctrl/pinctrl-single.c: In function 'pcs_probe': > drivers/pinctrl/pinctrl-single.c:1441:3: error: assignment of member > 'is_generic' in read-only object > make[2]: *** [drivers/pinctrl/pinctrl-single.o] Error 1 > make[1]: *** [drivers/pinctrl] Error 2 > make: *** [drivers] Error 2 > > Signed-off-by: Axel Lin Patch applied with Haojian's ACK, thanks! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 16/16] ARM: dts: add pinctrl property for spi node for atmel SoC
Signed-off-by: Wenyou Yang
Cc: li...@arm.linux.org.uk
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/at91sam9260.dtsi | 22 ++
arch/arm/boot/dts/at91sam9263.dtsi | 22 ++
arch/arm/boot/dts/at91sam9g45.dtsi | 22 ++
arch/arm/boot/dts/at91sam9n12.dtsi | 22 ++
arch/arm/boot/dts/at91sam9x5.dtsi | 22 ++
5 files changed, 110 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
b/arch/arm/boot/dts/at91sam9260.dtsi
index 6e31dc8..39253b9 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -322,6 +322,24 @@
};
};
+ spi0 {
+ pinctrl_spi0: spi0-0 {
+ atmel,pins =
+ <0 0 0x1 0x0/* PA0
periph A SPI0_MISO pin */
+0 1 0x1 0x0/* PA1
periph A SPI0_MOSI pin */
+0 2 0x1 0x0>; /* PA2
periph A SPI0_SPCK pin */
+ };
+ };
+
+ spi1 {
+ pinctrl_spi1: spi1-0 {
+ atmel,pins =
+ <1 0 0x1 0x0/* PB0
periph A SPI1_MISO pin */
+1 1 0x1 0x0/* PB1
periph A SPI1_MOSI pin */
+1 2 0x1 0x0>; /* PB2
periph A SPI1_SPCK pin */
+ };
+ };
+
pioA: gpio@f400 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xf400 0x200>;
@@ -477,6 +495,8 @@
compatible = "atmel,at91rm9200-spi";
reg = <0xfffc8000 0x200>;
interrupts = <12 4 3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spi0>;
status = "disabled";
};
@@ -486,6 +506,8 @@
compatible = "atmel,at91rm9200-spi";
reg = <0xfffcc000 0x200>;
interrupts = <13 4 3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spi1>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi
b/arch/arm/boot/dts/at91sam9263.dtsi
index 6c6d9ae..94b58ab 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -303,6 +303,24 @@
};
};
+ spi0 {
+ pinctrl_spi0: spi0-0 {
+ atmel,pins =
+ <0 0 0x2 0x0/* PA0
periph B SPI0_MISO pin */
+0 1 0x2 0x0/* PA1
periph B SPI0_MOSI pin */
+0 2 0x2 0x0>; /* PA2
periph B SPI0_SPCK pin */
+ };
+ };
+
+ spi1 {
+ pinctrl_spi1: spi1-0 {
+ atmel,pins =
+ <1 12 0x1 0x0 /* PB12
periph A SPI1_MISO pin */
+1 13 0x1 0x0 /* PB13
periph A SPI1_MOSI pin */
+1 14 0x1 0x0>; /* PB14
periph A SPI1_SPCK pin */
+ };
+ };
+
pioA: gpio@f200 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xf200 0x200>;
@@ -469,6 +487,8 @@
compatible = "atmel,at91rm9200-spi";
reg = <0xfffa4000 0x200>;
interrupts = <14 4 3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spi0>;
status = "disabled";
};
@@ -478,6 +498,8 @@
compatible = "atmel,at91rm9200-spi"
[PATCH v6 15/16] ARM: dts: add spi nodes for the atmel boards
From: Richard Genoud
Signed-off-by: Richard Genoud
[wenyou.y...@atmel.com: added spi nodes for the sam9263ek, sam9g20ek,
sam9m10g45ek and sam9n12ek boards]
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang
Cc: li...@arm.linux.org.uk
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/at91sam9263ek.dts | 10 ++
arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 10 ++
arch/arm/boot/dts/at91sam9m10g45ek.dts | 10 ++
arch/arm/boot/dts/at91sam9n12ek.dts | 10 ++
arch/arm/boot/dts/at91sam9x5ek.dtsi | 10 ++
5 files changed, 50 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9263ek.dts
b/arch/arm/boot/dts/at91sam9263ek.dts
index 1eb0872..a14e424 100644
--- a/arch/arm/boot/dts/at91sam9263ek.dts
+++ b/arch/arm/boot/dts/at91sam9263ek.dts
@@ -79,6 +79,16 @@
};
};
};
+
+ spi0: spi@fffa4000 {
+ status = "okay";
+ cs-gpios = <&pioA 5 0>, <0>, <0>, <0>;
+ mtd_dataflash@0 {
+ compatible = "atmel,at45",
"atmel,dataflash";
+ spi-max-frequency = <5000>;
+ reg = <0>;
+ };
+ };
};
nand0: nand@4000 {
diff --git a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
index da15e83..23d1f46 100644
--- a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
@@ -96,6 +96,16 @@
status = "okay";
pinctrl-0 = <&pinctrl_ssc0_tx>;
};
+
+ spi0: spi@fffc8000 {
+ status = "okay";
+ cs-gpios = <0>, <&pioC 11 0>, <0>, <0>;
+ mtd_dataflash@0 {
+ compatible = "atmel,at45",
"atmel,dataflash";
+ spi-max-frequency = <5000>;
+ reg = <1>;
+ };
+ };
};
nand0: nand@4000 {
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts
b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index 20c3191..92c52a7 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -102,6 +102,16 @@
};
};
};
+
+ spi0: spi@fffa4000{
+ status = "okay";
+ cs-gpios = <&pioB 3 0>, <0>, <0>, <0>;
+ mtd_dataflash@0 {
+ compatible = "atmel,at45",
"atmel,dataflash";
+ spi-max-frequency = <1300>;
+ reg = <0>;
+ };
+ };
};
nand0: nand@4000 {
diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts
b/arch/arm/boot/dts/at91sam9n12ek.dts
index d400f8d..34c842b 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -67,6 +67,16 @@
};
};
};
+
+ spi0: spi@f000 {
+ status = "okay";
+ cs-gpios = <&pioA 14 0>, <0>, <0>, <0>;
+ m25p80@0 {
+ compatible = "atmel,at25df321a";
+ spi-max-frequency = <5000>;
+ reg = <0>;
+ };
+ };
};
nand0: nand@4000 {
diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi
b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index 8a7cf1d..09f5e66 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -84,6 +84,16 @@
};
};
};
+
+ spi0: spi@f000 {
+ status = "okay";
+ cs-gpios = <&pioA 14 0>, <0>, <0>, <0>;
+ m25p80@0 {
+ compatible = "atmel,at25df321a";
+ spi-max-frequency = <5000>;
+ reg = <0>;
+ };
+ }
[PATCH v6 14/16] ARM: dts: add spi nodes for atmel SoC
From: Richard Genoud
Signed-off-by: Richard Genoud
[wenyou.y...@atmel.com: add spi nodes for sam9260, sam9263, sam9g45 and sam9n12]
[wenyou.y...@atmel.com: remove spi property "cs-gpios" to the board dts files]
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang
Cc: li...@arm.linux.org.uk
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/at91sam9260.dtsi | 18 ++
arch/arm/boot/dts/at91sam9263.dtsi | 18 ++
arch/arm/boot/dts/at91sam9g45.dtsi | 18 ++
arch/arm/boot/dts/at91sam9n12.dtsi | 18 ++
arch/arm/boot/dts/at91sam9x5.dtsi | 18 ++
5 files changed, 90 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
b/arch/arm/boot/dts/at91sam9260.dtsi
index cb7bcc5..6e31dc8 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -471,6 +471,24 @@
status = "disabled";
};
+ spi0: spi@fffc8000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "atmel,at91rm9200-spi";
+ reg = <0xfffc8000 0x200>;
+ interrupts = <12 4 3>;
+ status = "disabled";
+ };
+
+ spi1: spi@fffcc000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "atmel,at91rm9200-spi";
+ reg = <0xfffcc000 0x200>;
+ interrupts = <13 4 3>;
+ status = "disabled";
+ };
+
adc0: adc@fffe {
compatible = "atmel,at91sam9260-adc";
reg = <0xfffe 0x100>;
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi
b/arch/arm/boot/dts/at91sam9263.dtsi
index 271d4de..6c6d9ae 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -462,6 +462,24 @@
reg = <0xfd40 0x10>;
status = "disabled";
};
+
+ spi0: spi@fffa4000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "atmel,at91rm9200-spi";
+ reg = <0xfffa4000 0x200>;
+ interrupts = <14 4 3>;
+ status = "disabled";
+ };
+
+ spi1: spi@fffa8000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "atmel,at91rm9200-spi";
+ reg = <0xfffa8000 0x200>;
+ interrupts = <15 4 3>;
+ status = "disabled";
+ };
};
nand0: nand@4000 {
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi
b/arch/arm/boot/dts/at91sam9g45.dtsi
index 6b1d4ca..e085b8a 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -531,6 +531,24 @@
reg = <0xfd40 0x10>;
status = "disabled";
};
+
+ spi0: spi@fffa4000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "atmel,at91rm9200-spi";
+ reg = <0xfffa4000 0x200>;
+ interrupts = <14 4 3>;
+ status = "disabled";
+ };
+
+ spi1: spi@fffa8000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "atmel,at91rm9200-spi";
+ reg = <0xfffa8000 0x200>;
+ interrupts = <15 4 3>;
+ status = "disabled";
+ };
};
nand0: nand@4000 {
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi
b/arch/arm/boot/dts/at91sam9n12.dtsi
index 7750f98..f3f87ef3 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -373,6 +373,24 @@
#size-cells = <0>;
status = "disabled";
};
+
+ spi0: spi@f000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
[PATCH v6 13/16] ARM: at91: add clocks for spi dt entries
From: Richard Genoud
Signed-off-by: Richard Genoud
[
Cc: li...@arm.linux.org.uk
Cc: li...@maxim.org.za
Cc: linux-kernel@vger.kernel.org
---
arch/arm/mach-at91/at91sam9260.c |2 ++
arch/arm/mach-at91/at91sam9g45.c |2 ++
arch/arm/mach-at91/at91sam9n12.c |2 ++
arch/arm/mach-at91/at91sam9x5.c |2 ++
4 files changed, 8 insertions(+)
diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index b67cd53..44199bc 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -232,6 +232,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("t2_clk", "fffdc000.timer", &tc5_clk),
CLKDEV_CON_DEV_ID("hclk", "50.ohci", &ohci_clk),
CLKDEV_CON_DEV_ID("mci_clk", "fffa8000.mmc", &mmc_clk),
+ CLKDEV_CON_DEV_ID("spi_clk", "fffc8000.spi", &spi0_clk),
+ CLKDEV_CON_DEV_ID("spi_clk", "fffcc000.spi", &spi1_clk),
/* fake hclk clock */
CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk),
CLKDEV_CON_ID("pioA", &pioA_clk),
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index d3addee..2ec5efe 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -262,6 +262,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("mci_clk", "fffd.mmc", &mmc1_clk),
CLKDEV_CON_DEV_ID(NULL, "fff84000.i2c", &twi0_clk),
CLKDEV_CON_DEV_ID(NULL, "fff88000.i2c", &twi1_clk),
+ CLKDEV_CON_DEV_ID("spi_clk", "fffa4000.spi", &spi0_clk),
+ CLKDEV_CON_DEV_ID("spi_clk", "fffa8000.spi", &spi1_clk),
/* fake hclk clock */
CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &uhphs_clk),
CLKDEV_CON_DEV_ID(NULL, "f200.gpio", &pioA_clk),
diff --git a/arch/arm/mach-at91/at91sam9n12.c b/arch/arm/mach-at91/at91sam9n12.c
index 5dfc8fd..ccd0783 100644
--- a/arch/arm/mach-at91/at91sam9n12.c
+++ b/arch/arm/mach-at91/at91sam9n12.c
@@ -172,6 +172,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("dma_clk", "ec00.dma-controller", &dma_clk),
CLKDEV_CON_DEV_ID(NULL, "f801.i2c", &twi0_clk),
CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", &twi1_clk),
+ CLKDEV_CON_DEV_ID("spi_clk", "f000.spi", &spi0_clk),
+ CLKDEV_CON_DEV_ID("spi_clk", "f0004000.spi", &spi1_clk),
CLKDEV_CON_DEV_ID(NULL, "f400.gpio", &pioAB_clk),
CLKDEV_CON_DEV_ID(NULL, "f600.gpio", &pioAB_clk),
CLKDEV_CON_DEV_ID(NULL, "f800.gpio", &pioCD_clk),
diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
index 44a9a62..a200d8a 100644
--- a/arch/arm/mach-at91/at91sam9x5.c
+++ b/arch/arm/mach-at91/at91sam9x5.c
@@ -237,6 +237,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID(NULL, "f801.i2c", &twi0_clk),
CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", &twi1_clk),
CLKDEV_CON_DEV_ID(NULL, "f8018000.i2c", &twi2_clk),
+ CLKDEV_CON_DEV_ID("spi_clk", "f000.spi", &spi0_clk),
+ CLKDEV_CON_DEV_ID("spi_clk", "f0004000.spi", &spi1_clk),
CLKDEV_CON_DEV_ID(NULL, "f400.gpio", &pioAB_clk),
CLKDEV_CON_DEV_ID(NULL, "f600.gpio", &pioAB_clk),
CLKDEV_CON_DEV_ID(NULL, "f800.gpio", &pioCD_clk),
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 12/16] spi/spi-atmel: add pinctrl support for atmel spi
Signed-off-by: Wenyou Yang
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
---
drivers/spi/spi-atmel.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 1e212d1..6b166f4 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1493,11 +1494,18 @@ static int atmel_spi_probe(struct platform_device *pdev)
int ret;
struct spi_master *master;
struct atmel_spi*as;
+ struct pinctrl *pinctrl;
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!regs)
return -ENXIO;
+ pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(pinctrl)) {
+ dev_err(&pdev->dev, "Failed to request pinctrl\n");
+ return PTR_ERR(pinctrl);
+ }
+
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return irq;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 11/16] spi/spi-atmel: correct 16 bits transfers with DMA
From: Richard Genoud
Signed-off-by: Richard Genoud
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang
---
drivers/spi/spi-atmel.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index d287889..1e212d1 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -388,12 +388,18 @@ static inline int atmel_spi_xfer_can_be_chained(struct
spi_transfer *xfer)
}
static int atmel_spi_dma_slave_config(struct atmel_spi *as,
- struct dma_slave_config *slave_config)
+ struct dma_slave_config *slave_config,
+ u8 bits_per_word)
{
int err = 0;
- slave_config->dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
- slave_config->src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+ if (bits_per_word > 8) {
+ slave_config->dst_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+ slave_config->src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+ } else {
+ slave_config->dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+ slave_config->src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+ }
slave_config->dst_addr = (dma_addr_t)as->phybase + SPI_TDR;
slave_config->src_addr = (dma_addr_t)as->phybase + SPI_RDR;
@@ -454,7 +460,7 @@ static int atmel_spi_configure_dma(struct atmel_spi *as)
goto error;
}
- err = atmel_spi_dma_slave_config(as, &slave_config);
+ err = atmel_spi_dma_slave_config(as, &slave_config, 8);
if (err)
goto error;
@@ -588,10 +594,9 @@ static int atmel_spi_next_xfer_dma_submit(struct
spi_master *master,
*plen = len;
- if (atmel_spi_dma_slave_config(as, &slave_config))
+ if (atmel_spi_dma_slave_config(as, &slave_config, 8))
goto err_exit;
-
/* Send both scatterlists */
rxdesc = rxchan->device->device_prep_slave_sg(rxchan,
&as->dma.sgrx,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 10/16] spi/spi-atmel: correct 16 bits transfers using PIO
From: Richard Genoud
Signed-off-by: Richard Genoud
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang
---
drivers/spi/spi-atmel.c | 46 +-
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 40fd8786..d287889 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -520,13 +520,17 @@ static void atmel_spi_next_xfer_pio(struct spi_master
*master,
}
if (xfer->tx_buf)
- spi_writel(as, TDR, *(u8 *)(xfer->tx_buf));
+ if (xfer->bits_per_word > 8)
+ spi_writel(as, TDR, *(u16 *)(xfer->tx_buf));
+ else
+ spi_writel(as, TDR, *(u8 *)(xfer->tx_buf));
else
spi_writel(as, TDR, 0);
dev_dbg(master->dev.parent,
- " start pio xfer %p: len %u tx %p rx %p\n",
- xfer, xfer->len, xfer->tx_buf, xfer->rx_buf);
+ " start pio xfer %p: len %u tx %p rx %p bitpw %d\n",
+ xfer, xfer->len, xfer->tx_buf, xfer->rx_buf,
+ xfer->bits_per_word);
/* Enable relevant interrupts */
spi_writel(as, IER, SPI_BIT(RDRF) | SPI_BIT(OVRES));
@@ -945,21 +949,39 @@ atmel_spi_pump_pio_data(struct atmel_spi *as, struct
spi_transfer *xfer)
{
u8 *txp;
u8 *rxp;
+ u16 *txp16;
+ u16 *rxp16;
unsigned long xfer_pos = xfer->len - as->current_remaining_bytes;
if (xfer->rx_buf) {
- rxp = ((u8 *)xfer->rx_buf) + xfer_pos;
- *rxp = spi_readl(as, RDR);
+ if (xfer->bits_per_word > 8) {
+ rxp16 = (u16 *)(((u8 *)xfer->rx_buf) + xfer_pos);
+ *rxp16 = spi_readl(as, RDR);
+ } else {
+ rxp = ((u8 *)xfer->rx_buf) + xfer_pos;
+ *rxp = spi_readl(as, RDR);
+ }
} else {
spi_readl(as, RDR);
}
-
- as->current_remaining_bytes--;
+ if (xfer->bits_per_word > 8) {
+ as->current_remaining_bytes -= 2;
+ if (as->current_remaining_bytes < 0)
+ as->current_remaining_bytes = 0;
+ } else {
+ as->current_remaining_bytes--;
+ }
if (as->current_remaining_bytes) {
if (xfer->tx_buf) {
- txp = ((u8 *)xfer->tx_buf) + xfer_pos + 1;
- spi_writel(as, TDR, *txp);
+ if (xfer->bits_per_word > 8) {
+ txp16 = (u16 *)(((u8 *)xfer->tx_buf)
+ + xfer_pos + 2);
+ spi_writel(as, TDR, *txp16);
+ } else {
+ txp = ((u8 *)xfer->tx_buf) + xfer_pos + 1;
+ spi_writel(as, TDR, *txp);
+ }
} else {
spi_writel(as, TDR, 0);
}
@@ -1372,6 +1394,12 @@ static int atmel_spi_transfer(struct spi_device *spi,
struct spi_message *msg)
return -ENOPROTOOPT;
}
}
+ if (xfer->bits_per_word > 8) {
+ if (xfer->len % 2) {
+ dev_dbg(&spi->dev, "buffer len should be 16
bits aligned\n");
+ return -EINVAL;
+ }
+ }
if (xfer->speed_hz < spi->max_speed_hz) {
dev_dbg(&spi->dev,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 09/16] spi/spi-atmel: fix spi-atmel driver to adapt to slave_config changes
From: Richard Genoud
This is the following of the patch e2b35f3dbfc080f15b72834d08f04f0269dbe9be
Signed-off-by: Richard Genoud
[wenyou.y...@atmel.com: BUG: dmaengine mode when enable both spi0 and spi1,
spi0 doesn't work]
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
---
drivers/spi/spi-atmel.c | 61 +++
1 file changed, 51 insertions(+), 10 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index f6ef86b..40fd8786 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -387,6 +387,37 @@ static inline int atmel_spi_xfer_can_be_chained(struct
spi_transfer *xfer)
return xfer->delay_usecs == 0 && !xfer->cs_change;
}
+static int atmel_spi_dma_slave_config(struct atmel_spi *as,
+ struct dma_slave_config *slave_config)
+{
+ int err = 0;
+
+ slave_config->dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+ slave_config->src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+
+ slave_config->dst_addr = (dma_addr_t)as->phybase + SPI_TDR;
+ slave_config->src_addr = (dma_addr_t)as->phybase + SPI_RDR;
+ slave_config->src_maxburst = 1;
+ slave_config->dst_maxburst = 1;
+ slave_config->device_fc = false;
+
+ slave_config->direction = DMA_MEM_TO_DEV;
+ if (dmaengine_slave_config(as->dma.chan_tx, slave_config)) {
+ dev_err(&as->pdev->dev,
+ "failed to configure tx dma channel\n");
+ err = -EINVAL;
+ }
+
+ slave_config->direction = DMA_DEV_TO_MEM;
+ if (dmaengine_slave_config(as->dma.chan_rx, slave_config)) {
+ dev_err(&as->pdev->dev,
+ "failed to configure rx dma channel\n");
+ err = -EINVAL;
+ }
+
+ return err;
+}
+
static bool filter(struct dma_chan *chan, void *slave)
{
struct at_dma_slave *sl = slave;
@@ -402,14 +433,12 @@ static bool filter(struct dma_chan *chan, void *slave)
static int atmel_spi_configure_dma(struct atmel_spi *as)
{
struct at_dma_slave *sdata = &as->dma.dma_slave;
+ struct dma_slave_config slave_config;
+ int err;
if (sdata && sdata->dma_dev) {
dma_cap_mask_t mask;
- /* setup DMA addresses */
- sdata->rx_reg = (dma_addr_t)as->phybase + SPI_RDR;
- sdata->tx_reg = (dma_addr_t)as->phybase + SPI_TDR;
-
/* Try to grab two DMA channels */
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
@@ -419,21 +448,27 @@ static int atmel_spi_configure_dma(struct atmel_spi *as)
dma_request_channel(mask, filter, sdata);
}
if (!as->dma.chan_rx || !as->dma.chan_tx) {
- if (as->dma.chan_rx)
- dma_release_channel(as->dma.chan_rx);
- if (as->dma.chan_tx)
- dma_release_channel(as->dma.chan_tx);
dev_err(&as->pdev->dev,
"DMA channel not available, unable to use SPI\n");
- return -EBUSY;
+ err = -EBUSY;
+ goto error;
}
+ err = atmel_spi_dma_slave_config(as, &slave_config);
+ if (err)
+ goto error;
+
dev_info(&as->pdev->dev,
"Using %s (tx) and %s (rx) for DMA transfers\n",
dma_chan_name(as->dma.chan_tx),
dma_chan_name(as->dma.chan_rx));
-
return 0;
+error:
+ if (as->dma.chan_rx)
+ dma_release_channel(as->dma.chan_rx);
+ if (as->dma.chan_tx)
+ dma_release_channel(as->dma.chan_tx);
+ return err;
}
static void atmel_spi_stop_dma(struct atmel_spi *as)
@@ -510,6 +545,7 @@ static int atmel_spi_next_xfer_dma_submit(struct spi_master
*master,
struct dma_chan *txchan = as->dma.chan_tx;
struct dma_async_tx_descriptor *rxdesc;
struct dma_async_tx_descriptor *txdesc;
+ struct dma_slave_config slave_config;
dma_cookie_tcookie;
u32 len = *plen;
@@ -548,6 +584,10 @@ static int atmel_spi_next_xfer_dma_submit(struct
spi_master *master,
*plen = len;
+ if (atmel_spi_dma_slave_config(as, &slave_config))
+ goto err_exit;
+
+
/* Send both scatterlists */
rxdesc = rxchan->device->device_prep_slave_sg(rxchan,
&as->dma.sgrx,
@@ -596,6 +636,7 @@ static int atmel_spi_next_xfer_dma_submit(struct spi_master
*master,
err_dma:
spi_writel(as, IDR, SPI_BIT(OVRES));
atmel_spi_stop_dma(as);
+err_exit:
atmel_spi_lock(as);
return -ENOMEM;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[PATCH v6 08/16] spi/spi-atmel: add dmaengine support
From: Nicolas Ferre
Add dmaengine support.
For different SoC, the "has_dma_support" is used to select
the transfer mode: dmaengine or PDC.
The "has_dma_support" member of the capabilities struct is used to select
the transfer mode: dmaengine or PDC.
For the dmaengine transfer mode, if it fails to config dmaengine,
or if the message len less than 16 bytes, it will use the PIO transfer mode.
Signed-off-by: Nicolas Ferre
[wenyou.y...@atmel.com: using "has_dma_support" to select dmaengine as the spi
xfer mode]
[wenyou.y...@atmel.com: fix DMA: OOPS if buffer > 4096 bytes]
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang
Cc: richard.gen...@gmail.com
Cc: spi-devel-gene...@lists.sourceforge.ne
Cc: linux-kernel@vger.kernel.org
---
This patch is based on the original patch from Nicolas
[PATCH] spi/atmel_spi: add dmaengine support
and merge the patches from Richard Genoud
[PATCH] spi-atmel: update with dmaengine interface
[PATCH] spi-atmel: fix __init/__devinit sections mismatch
Hi, Richard,
Could you sign your signature in this patch?
Best Regards,
Wenyou Yang
drivers/spi/spi-atmel.c | 541 +--
1 file changed, 520 insertions(+), 21 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index a483929..f6ef86b 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -15,11 +15,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
@@ -182,6 +184,22 @@
#define spi_writel(port,reg,value) \
__raw_writel((value), (port)->regs + SPI_##reg)
+/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
+ * cache operations; better heuristics consider wordsize and bitrate.
+ */
+#define DMA_MIN_BYTES 16
+
+struct atmel_spi_dma {
+ struct dma_chan *chan_rx;
+ struct dma_chan *chan_tx;
+ struct scatterlist sgrx;
+ struct scatterlist sgtx;
+ struct dma_async_tx_descriptor *data_desc_rx;
+ struct dma_async_tx_descriptor *data_desc_tx;
+
+ struct at_dma_slave dma_slave;
+};
+
struct atmel_spi_caps {
boolis_spi2;
boolhas_wdrbt;
@@ -206,16 +224,23 @@ struct atmel_spi {
u8 stopping;
struct list_headqueue;
+ struct tasklet_struct tasklet;
struct spi_transfer *current_transfer;
unsigned long current_remaining_bytes;
struct spi_transfer *next_transfer;
unsigned long next_remaining_bytes;
int done_status;
+ /* scratch buffer */
void*buffer;
dma_addr_t buffer_dma;
struct atmel_spi_caps caps;
+
+ booluse_dma;
+ booluse_pdc;
+ /* dmaengine data */
+ struct atmel_spi_dmadma;
};
/* Controller-specific per-slave state */
@@ -284,6 +309,7 @@ static void cs_activate(struct atmel_spi *as, struct
spi_device *spi)
| SPI_BIT(MODFDIS)
| SPI_BIT(MSTR));
}
+
mr = spi_readl(as, MR);
gpio_set_value(asd->npcs_pin, active);
} else {
@@ -344,6 +370,12 @@ static void atmel_spi_unlock(struct atmel_spi *as)
spin_unlock_irqrestore(&as->lock, as->flags);
}
+static inline bool atmel_spi_use_dma(struct atmel_spi *as,
+ struct spi_transfer *xfer)
+{
+ return as->use_dma && xfer->len >= DMA_MIN_BYTES;
+}
+
static inline int atmel_spi_xfer_is_last(struct spi_message *msg,
struct spi_transfer *xfer)
{
@@ -355,6 +387,219 @@ static inline int atmel_spi_xfer_can_be_chained(struct
spi_transfer *xfer)
return xfer->delay_usecs == 0 && !xfer->cs_change;
}
+static bool filter(struct dma_chan *chan, void *slave)
+{
+ struct at_dma_slave *sl = slave;
+
+ if (sl->dma_dev == chan->device->dev) {
+ chan->private = sl;
+ return true;
+ } else {
+ return false;
+ }
+}
+
+static int atmel_spi_configure_dma(struct atmel_spi *as)
+{
+ struct at_dma_slave *sdata = &as->dma.dma_slave;
+
+ if (sdata && sdata->dma_dev) {
+ dma_cap_mask_t mask;
+
+ /* setup DMA addresses */
+ sdata->rx_reg = (dma_addr_t)as->phybase + SPI_RDR;
+ sdata->tx_reg = (dma_addr_t)as->phybase + SPI_TDR;
+
+ /* Try to grab two DMA channels */
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_SLAVE, mask);
+ as->dma.chan_tx = dma_request_channel(mask, filter, sdata);
+ if (as->dma.chan_tx)
+ as->dma.chan_rx =
+
[PATCH v6 07/16] spi/spi-atmel: add flag to controller data for lock operations
From: Nicolas Ferre
Will allow to drop the lock during DMA operations.
Signed-off-by: Nicolas Ferre
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang
---
drivers/spi/spi-atmel.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 5c91408..a483929 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -195,6 +195,7 @@ struct atmel_spi_caps {
*/
struct atmel_spi {
spinlock_t lock;
+ unsigned long flags;
resource_size_t phybase;
void __iomem*regs;
@@ -333,6 +334,16 @@ static void cs_deactivate(struct atmel_spi *as, struct
spi_device *spi)
gpio_set_value(asd->npcs_pin, !active);
}
+static void atmel_spi_lock(struct atmel_spi *as)
+{
+ spin_lock_irqsave(&as->lock, as->flags);
+}
+
+static void atmel_spi_unlock(struct atmel_spi *as)
+{
+ spin_unlock_irqrestore(&as->lock, as->flags);
+}
+
static inline int atmel_spi_xfer_is_last(struct spi_message *msg,
struct spi_transfer *xfer)
{
@@ -569,9 +580,9 @@ atmel_spi_msg_done(struct spi_master *master, struct
atmel_spi *as,
"xfer complete: %u bytes transferred\n",
msg->actual_length);
- spin_unlock(&as->lock);
+ atmel_spi_unlock(as);
msg->complete(msg->context);
- spin_lock(&as->lock);
+ atmel_spi_lock(as);
as->current_transfer = NULL;
as->next_transfer = NULL;
@@ -802,13 +813,11 @@ static int atmel_spi_setup(struct spi_device *spi)
spi->controller_state = asd;
gpio_direction_output(npcs_pin, !(spi->mode & SPI_CS_HIGH));
} else {
- unsigned long flags;
-
- spin_lock_irqsave(&as->lock, flags);
+ atmel_spi_lock(as);
if (as->stay == spi)
as->stay = NULL;
cs_deactivate(as, spi);
- spin_unlock_irqrestore(&as->lock, flags);
+ atmel_spi_unlock(as);
}
asd->csr = csr;
@@ -827,7 +836,6 @@ static int atmel_spi_transfer(struct spi_device *spi,
struct spi_message *msg)
{
struct atmel_spi*as;
struct spi_transfer *xfer;
- unsigned long flags;
struct device *controller = spi->master->dev.parent;
u8 bits;
struct atmel_spi_device *asd;
@@ -892,11 +900,11 @@ static int atmel_spi_transfer(struct spi_device *spi,
struct spi_message *msg)
msg->status = -EINPROGRESS;
msg->actual_length = 0;
- spin_lock_irqsave(&as->lock, flags);
+ atmel_spi_lock(as);
list_add_tail(&msg->queue, &as->queue);
if (!as->current_transfer)
atmel_spi_next_message(spi->master);
- spin_unlock_irqrestore(&as->lock, flags);
+ atmel_spi_unlock(as);
return 0;
}
@@ -906,17 +914,16 @@ static void atmel_spi_cleanup(struct spi_device *spi)
struct atmel_spi*as = spi_master_get_devdata(spi->master);
struct atmel_spi_device *asd = spi->controller_state;
unsignedgpio = (unsigned) spi->controller_data;
- unsigned long flags;
if (!asd)
return;
- spin_lock_irqsave(&as->lock, flags);
+ atmel_spi_lock(as);
if (as->stay == spi) {
as->stay = NULL;
cs_deactivate(as, spi);
}
- spin_unlock_irqrestore(&as->lock, flags);
+ atmel_spi_unlock(as);
spi->controller_state = NULL;
gpio_free(gpio);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 06/16] spi/spi-atmel: status information passed through controller data
From: Nicolas Ferre
The status of transfer is stored in controller data structure
so that it can be used not only by atmel_spi_msg_done() function.
This will be useful for upcoming dmaengine enabled driver.
Signed-off-by: Nicolas Ferre
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang
---
drivers/spi/spi-atmel.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 2f61a80..5c91408 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -209,6 +209,7 @@ struct atmel_spi {
unsigned long current_remaining_bytes;
struct spi_transfer *next_transfer;
unsigned long next_remaining_bytes;
+ int done_status;
void*buffer;
dma_addr_t buffer_dma;
@@ -554,15 +555,15 @@ static void atmel_spi_dma_unmap_xfer(struct spi_master
*master,
static void
atmel_spi_msg_done(struct spi_master *master, struct atmel_spi *as,
- struct spi_message *msg, int status, int stay)
+ struct spi_message *msg, int stay)
{
- if (!stay || status < 0)
+ if (!stay || as->done_status < 0)
cs_deactivate(as, msg->spi);
else
as->stay = msg->spi;
list_del(&msg->queue);
- msg->status = status;
+ msg->status = as->done_status;
dev_dbg(master->dev.parent,
"xfer complete: %u bytes transferred\n",
@@ -574,6 +575,7 @@ atmel_spi_msg_done(struct spi_master *master, struct
atmel_spi *as,
as->current_transfer = NULL;
as->next_transfer = NULL;
+ as->done_status = 0;
/* continue if needed */
if (list_empty(&as->queue) || as->stopping)
@@ -651,7 +653,8 @@ atmel_spi_interrupt(int irq, void *dev_id)
/* Clear any overrun happening while cleaning up */
spi_readl(as, SR);
- atmel_spi_msg_done(master, as, msg, -EIO, 0);
+ as->done_status = -EIO;
+ atmel_spi_msg_done(master, as, msg, 0);
} else if (pending & (SPI_BIT(RXBUFF) | SPI_BIT(ENDRX))) {
ret = IRQ_HANDLED;
@@ -669,7 +672,7 @@ atmel_spi_interrupt(int irq, void *dev_id)
if (atmel_spi_xfer_is_last(msg, xfer)) {
/* report completed message */
- atmel_spi_msg_done(master, as, msg, 0,
+ atmel_spi_msg_done(master, as, msg,
xfer->cs_change);
} else {
if (xfer->cs_change) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] [PATCH 05/24] rtc: rtc-coh901331: use module_platform_driver_probe()
On Mon, Mar 4, 2013 at 8:59 AM, Jingoo Han wrote: > This patch uses module_platform_driver_probe() macro which makes > the code smaller and simpler. > > Signed-off-by: Jingoo Han Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 05/16] spi/spi-atmel: call unmapping on transfers buffers
From: Nicolas Ferre
Signed-off-by: Nicolas Ferre
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang
---
drivers/spi/spi-atmel.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index ce9c894..2f61a80 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1049,6 +1049,7 @@ static int atmel_spi_remove(struct platform_device *pdev)
struct spi_master *master = platform_get_drvdata(pdev);
struct atmel_spi*as = spi_master_get_devdata(master);
struct spi_message *msg;
+ struct spi_transfer *xfer;
/* reset the hardware and block queue progress */
spin_lock_irq(&as->lock);
@@ -1060,9 +1061,10 @@ static int atmel_spi_remove(struct platform_device *pdev)
/* Terminate remaining queued transfers */
list_for_each_entry(msg, &as->queue, queue) {
- /* REVISIT unmapping the dma is a NOP on ARM and AVR32
-* but we shouldn't depend on that...
-*/
+ list_for_each_entry(xfer, &msg->transfers, transfer_list) {
+ if (!msg->is_dma_mapped)
+ atmel_spi_dma_unmap_xfer(master, xfer);
+ }
msg->status = -ESHUTDOWN;
msg->complete(msg->context);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 04/16] spi/spi-atmel: add physical base address
From: Nicolas Ferre
Needed for future use with dmaengine enabled driver.
Signed-off-by: Nicolas Ferre
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang
---
drivers/spi/spi-atmel.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index e05aa8c..ce9c894 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -196,6 +196,7 @@ struct atmel_spi_caps {
struct atmel_spi {
spinlock_t lock;
+ resource_size_t phybase;
void __iomem*regs;
int irq;
struct clk *clk;
@@ -993,6 +994,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
as->regs = ioremap(regs->start, resource_size(regs));
if (!as->regs)
goto out_free_buffer;
+ as->phybase = regs->start;
as->irq = irq;
as->clk = clk;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] [PATCH 01/24] rtc: rtc-ab3100: use module_platform_driver_probe()
On Mon, Mar 4, 2013 at 8:57 AM, Jingoo Han wrote: > This patch uses module_platform_driver_probe() macro which makes > the code smaller and simpler. > > Signed-off-by: Jingoo Han Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 03/16] spi/spi-atmel: add support transfer on CS1,2,3, not only on CS0
Signed-off-by: Wenyou Yang
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
---
drivers/spi/spi-atmel.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 8724157..e05aa8c 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -255,11 +255,6 @@ static bool atmel_spi_is_v2(struct atmel_spi *as)
* Master on Chip Select 0.") No workaround exists for that ... so for
* nCS0 on that chip, we (a) don't use the GPIO, (b) can't support CS_HIGH,
* and (c) will trigger that first erratum in some cases.
- *
- * TODO: Test if the atmel_spi_is_v2() branch below works on
- * AT91RM9200 if we use some other register than CSR0. However, don't
- * do this unconditionally since AP7000 has an errata where the BITS
- * field in CSR0 overrides all other CSRs.
*/
static void cs_activate(struct atmel_spi *as, struct spi_device *spi)
@@ -269,18 +264,22 @@ static void cs_activate(struct atmel_spi *as, struct
spi_device *spi)
u32 mr;
if (atmel_spi_is_v2(as)) {
- /*
-* Always use CSR0. This ensures that the clock
-* switches to the correct idle polarity before we
-* toggle the CS.
+ spi_writel(as, CSR0 + 4 * spi->chip_select, asd->csr);
+ /* For the low SPI version, there is a issue that PDC transfer
+* on CS1,2,3 needs SPI_CSR0.BITS config as SPI_CSR1,2,3.BITS
*/
spi_writel(as, CSR0, asd->csr);
if (as->caps.has_wdrbt) {
- spi_writel(as, MR, SPI_BF(PCS, 0x0e) | SPI_BIT(WDRBT)
- | SPI_BIT(MODFDIS) | SPI_BIT(MSTR));
+ spi_writel(as, MR,
+ SPI_BF(PCS, ~(0x01 << spi->chip_select))
+ | SPI_BIT(WDRBT)
+ | SPI_BIT(MODFDIS)
+ | SPI_BIT(MSTR));
} else {
- spi_writel(as, MR, SPI_BF(PCS, 0x0e) | SPI_BIT(MODFDIS)
- | SPI_BIT(MSTR));
+ spi_writel(as, MR,
+ SPI_BF(PCS, ~(0x01 << spi->chip_select))
+ | SPI_BIT(MODFDIS)
+ | SPI_BIT(MSTR));
}
mr = spi_readl(as, MR);
gpio_set_value(asd->npcs_pin, active);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 02/16] spi/spi-atmel: detect the capabilities of SPI core by reading the VERSION register.
The "has_dma_support" needed for future use with dmaengine driver.
Signed-off-by: Wenyou Yang
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
---
drivers/spi/spi-atmel.c | 66 +++
1 file changed, 50 insertions(+), 16 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 1eca815..8724157 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -22,9 +22,8 @@
#include
#include
-#include
-#include
-#include
+#include
+#include
/* SPI register offsets */
#define SPI_CR 0x
@@ -39,6 +38,7 @@
#define SPI_CSR1 0x0034
#define SPI_CSR2 0x0038
#define SPI_CSR3 0x003c
+#define SPI_VERSION0x00fc
#define SPI_RPR0x0100
#define SPI_RCR0x0104
#define SPI_TPR0x0108
@@ -71,6 +71,8 @@
#define SPI_FDIV_SIZE 1
#define SPI_MODFDIS_OFFSET 4
#define SPI_MODFDIS_SIZE 1
+#define SPI_WDRBT_OFFSET 5
+#define SPI_WDRBT_SIZE 1
#define SPI_LLB_OFFSET 7
#define SPI_LLB_SIZE 1
#define SPI_PCS_OFFSET 16
@@ -180,6 +182,11 @@
#define spi_writel(port,reg,value) \
__raw_writel((value), (port)->regs + SPI_##reg)
+struct atmel_spi_caps {
+ boolis_spi2;
+ boolhas_wdrbt;
+ boolhas_dma_support;
+};
/*
* The core SPI transfer engine just talks to a register bank to set up
@@ -204,6 +211,8 @@ struct atmel_spi {
void*buffer;
dma_addr_t buffer_dma;
+
+ struct atmel_spi_caps caps;
};
/* Controller-specific per-slave state */
@@ -222,14 +231,10 @@ struct atmel_spi_device {
* - SPI_SR.TXEMPTY, SPI_SR.NSSR (and corresponding irqs)
* - SPI_CSRx.CSAAT
* - SPI_CSRx.SBCR allows faster clocking
- *
- * We can determine the controller version by reading the VERSION
- * register, but I haven't checked that it exists on all chips, and
- * this is cheaper anyway.
*/
-static bool atmel_spi_is_v2(void)
+static bool atmel_spi_is_v2(struct atmel_spi *as)
{
- return !cpu_is_at91rm9200();
+ return as->caps.is_spi2;
}
/*
@@ -263,15 +268,20 @@ static void cs_activate(struct atmel_spi *as, struct
spi_device *spi)
unsigned active = spi->mode & SPI_CS_HIGH;
u32 mr;
- if (atmel_spi_is_v2()) {
+ if (atmel_spi_is_v2(as)) {
/*
* Always use CSR0. This ensures that the clock
* switches to the correct idle polarity before we
* toggle the CS.
*/
spi_writel(as, CSR0, asd->csr);
- spi_writel(as, MR, SPI_BF(PCS, 0x0e) | SPI_BIT(MODFDIS)
+ if (as->caps.has_wdrbt) {
+ spi_writel(as, MR, SPI_BF(PCS, 0x0e) | SPI_BIT(WDRBT)
+ | SPI_BIT(MODFDIS) | SPI_BIT(MSTR));
+ } else {
+ spi_writel(as, MR, SPI_BF(PCS, 0x0e) | SPI_BIT(MODFDIS)
| SPI_BIT(MSTR));
+ }
mr = spi_readl(as, MR);
gpio_set_value(asd->npcs_pin, active);
} else {
@@ -318,7 +328,7 @@ static void cs_deactivate(struct atmel_spi *as, struct
spi_device *spi)
asd->npcs_pin, active ? " (low)" : "",
mr);
- if (atmel_spi_is_v2() || spi->chip_select != 0)
+ if (atmel_spi_is_v2(as) || spi->chip_select != 0)
gpio_set_value(asd->npcs_pin, !active);
}
@@ -719,7 +729,7 @@ static int atmel_spi_setup(struct spi_device *spi)
}
/* see notes above re chipselect */
- if (!atmel_spi_is_v2()
+ if (!atmel_spi_is_v2(as)
&& spi->chip_select == 0
&& (spi->mode & SPI_CS_HIGH)) {
dev_dbg(&spi->dev, "setup: can't be active-high\n");
@@ -728,7 +738,7 @@ static int atmel_spi_setup(struct spi_device *spi)
/* v1 chips start out at half the peripheral bus speed. */
bus_hz = clk_get_rate(as->clk);
- if (!atmel_spi_is_v2())
+ if (!atmel_spi_is_v2(as))
bus_hz /= 2;
if (spi->max_speed_hz) {
@@ -804,7 +814,7 @@ static int atmel_spi_setup(struct spi_device *spi)
"setup: %lu Hz bpw %u mode 0x%x -> csr%d %08x\n",
bus_hz / scbr, bits, spi->mode, spi->chip_select, csr);
- if (!atmel_spi_is_v2())
+ if (!atmel_spi_is_v2(as))
spi_writel(as, CSR0 + 4 * spi->chip_select, csr);
return 0;
@@ -910,6 +920,23 @@ static void atmel_sp
[PATCH v6 01/16] spi/spi-atmel: fix probing failure after xfer->speed_hz set
commit: 059b8ffeee5b427949872bb6ed5db5ae0788054e
cause the atmel spi probing failure.
Signed-off-by: Wenyou Yang
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
---
drivers/spi/spi-atmel.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 656d137..1eca815 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -846,9 +846,9 @@ static int atmel_spi_transfer(struct spi_device *spi,
struct spi_message *msg)
}
}
- /* FIXME implement these protocol options!! */
- if (xfer->speed_hz) {
- dev_dbg(&spi->dev, "no protocol options yet\n");
+ if (xfer->speed_hz < spi->max_speed_hz) {
+ dev_dbg(&spi->dev,
+ "speed in transfer less than bus speed\n");
return -ENOPROTOOPT;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 0/3] pinctrl: exynos: add support for Samsung's Exynos5250
Thomas Abraham wrote: > > On 7 March 2013 05:41, Kukjin Kim wrote: > > Thomas Abraham wrote: > >> > >> Changes since v1: > >> - Change the compatible string from "samsung,pinctrl-exynos5250" to > >> "samsung,exynos5250-pinctrl". > >> - Rebased to v3.9-rc1 > >> > > > > Thomas, this stuff is already in my tree for v3.10, and above changes > > included in there. Do you want to replace with this patches? > > Dear Mr. Kim, > > The v2 version includes one fix for the compatilble string. It changes > the compatible string from "samsung,pinctrl-exynos5250" to > "samsung,exynos5250-pinctrl". So could you pick this v2 series instead > of the series which you have already merged. > Hey, probably, you didn't check my tree. As I said, already changed/fixed. - Kukjin -- 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] gpio: gpio-ich: fix ichx_gpio_check_available() return what callers expect
Hi Mika,
On Wed, Feb 27, 2013 at 4:25 PM, Mika Westerberg
wrote:
> -static int ichx_gpio_check_available(struct gpio_chip *gpio, unsigned nr)
> +static bool ichx_gpio_check_available(struct gpio_chip *gpio, unsigned nr)
> {
> - return (ichx_priv.use_gpio & (1 << (nr / 32))) ? 0 : -ENXIO;
> + return ichx_priv.use_gpio & (1 << (nr / 32));
> }
Strictly speaking what you're returning there is not a bool.
Shouldn't it be:
return !!(ichx_priv.use_gpio & (1 << (nr / 32)));
?
Yours,
Linus Walleij
--
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] pinctrl: exynos: add support for Samsung's Exynos5250
On 7 March 2013 05:41, Kukjin Kim wrote: > Thomas Abraham wrote: >> >> Changes since v1: >> - Change the compatible string from "samsung,pinctrl-exynos5250" to >> "samsung,exynos5250-pinctrl". >> - Rebased to v3.9-rc1 >> > > Thomas, this stuff is already in my tree for v3.10, and above changes > included in there. Do you want to replace with this patches? Dear Mr. Kim, The v2 version includes one fix for the compatilble string. It changes the compatible string from "samsung,pinctrl-exynos5250" to "samsung,exynos5250-pinctrl". So could you pick this v2 series instead of the series which you have already merged. Thanks, Thomas. > > - Kukjin > >> This patch series add pinctrl driver support for Samsung's Exynos5250 SoC. >> The first patch adds the required Exynos5250 SoC specific data which is >> used by the Samsung pinctrl driver to setup the pinctrl/pinmux/eint >> controllers. The second and third patches skips the wakeup interrupt and >> gpiolib registration if the pinctrl support is enabled for Exynos5250. >> >> Thomas Abraham (3): >> pinctrl: exynos: add exynos5250 SoC specific data >> gpio: samsung: skip gpiolib registration if pinctrl support is enabled >> for exynos5250 >> arm: exynos: skip wakeup interrupt registration for exynos5250 if >> pinctrl is enabled >> >> arch/arm/mach-exynos/common.c |1 + >> drivers/gpio/gpio-samsung.c |1 + >> drivers/pinctrl/pinctrl-exynos.c | 108 >> + >> drivers/pinctrl/pinctrl-samsung.c |2 + >> drivers/pinctrl/pinctrl-samsung.h |1 + >> 5 files changed, 113 insertions(+), 0 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] USB: storage: fix Huawei mode switching regression
On Thu, Mar 07, 2013 at 02:54:38AM +, Fangxiaozhi (Franko) wrote: > Dear All： > As far as I know, except switching in kernel, there isn't any mode switch > solution on Android now. > Do you have any good ideas for the mode switch on Android system? Please discuss this with the Android developers, there's nothing that us (the kernel community) can do about the Android userspace code, sorry. Please work with Google to solve this properly there. good luck, 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 LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
Hi Ian, On Tue, Mar 05, 2013 at 09:29:57AM +, Ian Campbell wrote: > On Tue, 2013-03-05 at 08:08 +, Will Deacon wrote: > > Cheers Rob, that was enough to reproduce for me. The problem is likely that > > CONFIG_AEABI=n, so the ABI doesn't actually mandate even base registers for > > 64-bit values in registers. > > Me too. > > > Ian -- this would be fixed if you used our atomic64 routines instead of > > inventing your own :) > > I looked and couldn't see an existing 64 bit xchg, was I looking in the > wrong place? Ah, wait, I see atomic64_xchg now. But that needs an > atomic64_t while I have a xen_ulong_t (which == 64 bits on ARM). This is > a kernel<->hypervisor ABI so I can't just change it to an atomic64_t. I > suppose I could cast (see below, untested) but that seems rather icky. You can play some container_of tricks, like we do in cmpxchg64 to get this right. Alternatively, we could look at an xchg8 implementation which some other architectures have (although they seem to be 64-bit machines). Will -- 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 0/4] Alter steal-time reporting in the guest
On Wed, Mar 06, 2013 at 09:52:16PM -0300, Marcelo Tosatti wrote: > On Wed, Mar 06, 2013 at 10:29:12AM -0600, Michael Wolf wrote: > > I looked at doing that once but was told that I was changing the > > interface in an unacceptable way, because now I was not reporting all of > > the elapsed time. I agree it would make things simpler. > > Pointer to that claim, please? Back in about 2004 or 2005 or so I was looking at changing how user and system times were calculated (in the context of trying to find a better way to report resources used by a thread in an SMT processor). I found that utilities such as top expected the deltas in the /proc/stat numbers to add up to elapsed time, and would report strange and inconsistent results if that wasn't the case. Unfortunately at this distance I don't recall the exact details. I don't know whether the expectation that the deltas in the /proc/stat numbers over a period of time add up to the elapsed real time is documented anywhere, but I wouldn't be at all surprised if some programs depend on it, so it's better to maintain that property. Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] iio: adc: exynos5_adc: fix compilation warnings
Fixes the compilation warnings and potential NULL pointer
dereferencing pointed out by "Dan Carpenter".
Signed-off-by: Naveen Krishna Ch
Cc: Jonathan Cameron
Cc: Lars-Peter Clausen
Series-to: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Dan Carpenter
---
Changes since v1:
Made the exynos_adc driver depends on CONFIG_OF.
drivers/iio/adc/Kconfig |1 +
drivers/iio/adc/exynos_adc.c | 21 ++---
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a40d3c2..9c45c0f 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -105,6 +105,7 @@ config AT91_ADC
config EXYNOS_ADC
bool "Exynos ADC driver support"
+ depends on OF
help
Core support for the ADC block found in the Samsung EXYNOS series
of SoCs for drivers such as the touchscreen and hwmon to use to share
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index ed6fdd7..4fd5e3a 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -92,7 +92,7 @@ struct exynos_adc {
struct completion completion;
u32 value;
- unsigned intversion;
+ unsigned intversion;
};
static const struct of_device_id exynos_adc_match[] = {
@@ -102,12 +102,12 @@ static const struct of_device_id exynos_adc_match[] = {
};
MODULE_DEVICE_TABLE(of, exynos_adc_match);
-static inline unsigned int exynos_adc_get_version(struct platform_device *pdev)
+static inline int exynos_adc_get_version(struct platform_device *pdev)
{
const struct of_device_id *match;
match = of_match_node(exynos_adc_match, pdev->dev.of_node);
- return (unsigned int)match->data;
+ return (int)match->data;
}
static int exynos_read_raw(struct iio_dev *indio_dev,
@@ -117,7 +117,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
long mask)
{
struct exynos_adc *info = iio_priv(indio_dev);
- unsigned long timeout;
+ int timeout;
u32 con1, con2;
if (mask != IIO_CHAN_INFO_RAW)
@@ -255,7 +255,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
struct iio_dev *indio_dev = NULL;
struct resource *mem;
int ret = -ENODEV;
- int irq;
+ int irq, version;
if (!np)
return ret;
@@ -268,6 +268,15 @@ static int exynos_adc_probe(struct platform_device *pdev)
info = iio_priv(indio_dev);
+ version = exynos_adc_get_version(pdev);
+ if (version < 0) {
+ dev_err(&pdev->dev, "no matching of_node, err = %d\n", version);
+ ret = version;
+ goto err_iio;
+ }
+
+ info->version = version;
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
info->regs = devm_request_and_ioremap(&pdev->dev, mem);
@@ -311,8 +320,6 @@ static int exynos_adc_probe(struct platform_device *pdev)
goto err_irq;
}
- info->version = exynos_adc_get_version(pdev);
-
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = dev_name(&pdev->dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: mxs: cfa10049: Fix fb initialisation function
On Tue, Mar 05, 2013 at 04:13:35PM +0100, Maxime Ripard wrote:
> Commit 1fe42740 ("ARM: dts: mxs: Add the LCD to the 10049 board") seem
> to have been applied with some fuzzyness, and the framebuffer
> initialisation code for the CFA-10049 ended up in the CFA-10037
> initialisation function.
>
> Signed-off-by: Maxime Ripard
Thanks, applied.
Shawn
--
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] USB: storage: fix Huawei mode switching regression
Dear All：
As far as I know, except switching in kernel, there isn't any mode
switch solution on Android now.
Do you have any good ideas for the mode switch on Android system?
Best Regards,
Franko Fang
> -Original Message-
> From: Dan Williams [mailto:d...@redhat.com]
> Sent: Wednesday, March 06, 2013 11:46 PM
> To: Greg KH
> Cc: Linlei (Lei Lin); Bjørn Mork; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Xueguiying (Zihan); Yili (Neil); Wangyuhua;
> Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net;
> sebast...@breakpoint.cc; stable; Fangxiaozhi (Franko)
> Subject: Re: 答复: [PATCH] USB: storage: fix Huawei mode switching
> regression
>
> On Wed, 2013-03-06 at 09:44 +0800, Greg KH wrote:
> > On Wed, Mar 06, 2013 at 01:34:44AM +, Linlei (Lei Lin) wrote:
> > > Hello Mork,
> > >
> > > >> -- Because in the embedded linux system, Android, or Chrome
> > > >> OS, etc. They don't integrate userspace usb_modeswitch utility
> > > >> for switching.
> > >
> > > >Why not? If they can upgrade the kernel, then they most certainly can
> install a userspace utility.
> > >
> > > >There is no excuse for an embedded system to do this differently.
> > > >Please see e.g. OpenWRT as an example of an embedded system doing
> this correctly.
> > >
> > > But currently Android and Chrome OS has not integrated the
> > > usb_modeswitch utility.
> >
> > That is not a kernel problem. I find it hard to believe that Chrome
> > OS would not gladly accept code to resolve this issue, can't you put
> > it into the modemmanager or whatever Chrome OS uses to handle their
> > wireless modems?
>
> They use ModemManager, and that's still not the best place to put
> modeswitching. The best place to modeswitch anything is usb_modeswitch.
> No sense duplicating the functionality that usb_modeswitch already supplies.
>
> Dan
>
> >
> > As for Android, sorry, you are on your own, you will just have to deal
> > with the individual OEMs that are incorporating your hardware :(
> >
> > > From a vendor's point of view, our purpose is to make our devices be
> > > supported natively by those OS.
> >
> > We have a solution, usb_modeswitch, any user should be using that.
> >
> > > So we consider that add the switch function to the kernel resolves
> > > the problem from the source.
> > > Then this function will be inherited by Android & Chrome OS.
> >
> > Don't circumvent horribly governed userspace projects by getting
> > changes into the Linux kernel. Go fix those projects instead.
> >
> > Good luck,
> >
> > greg k-h
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[RFC PATCH] ARM: keep __my_cpu_offset consistent with generic one
Commit 14318efb(ARM: 7587/1: implement optimized percpu variable access) introduces arm's __my_cpu_offset to optimize percpu vaiable access, which really works well on hackbench test, but may cause __my_cpu_offset to return garbage value before it is initialized in cpu_init() called by setup_arch, so accessing a percpu variable before setup_arch may cause kernel hang. But the generic__my_cpu_offset always returns zero before percpu area is brought up. So the patch tries to clear __my_cpu_offset on boot CPU early to avoid boot hang. At least now percpu variable is accessed by lockdep before setup_arch(), and enabling CONFIG_LOCK_STAT or CONFIG_DEBUG_LOCKDEP can trigger kernel hang. Cc: Tejun Heo Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Rob Herring Cc: Will Deacon Cc: Nicolas Pitre Cc: Russell King Signed-off-by: Ming Lei --- arch/arm/kernel/setup.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index 3f6cbb2..bc7ee4b 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c @@ -439,6 +439,13 @@ void __init smp_setup_processor_id(void) for (i = 1; i < nr_cpu_ids; ++i) cpu_logical_map(i) = i == cpu ? 0 : i; + /* +* clear __my_cpu_offset on boot CPU early to avoid hang +* caused by accessing percpu variable before percpu area is +* brought up +*/ + set_my_cpu_offset(0); + printk(KERN_INFO "Booting Linux on physical CPU 0x%x\n", mpidr); } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] regulator updates for v3.9
The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: Linux 3.9-rc1 (2013-03-03 15:11:05 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/regulator-3.9-rc1 for you to fetch changes up to 8870d4029acda2666700bb5fd94d46b143f92ec4: Merge remote-tracking branch 'regulator/fix/twl' into tmp (2013-03-05 10:12:43 +0800) regulator: Fixes for v3.9 A few small things here and there, nothing major here really. The conversion of twl4030ldo_ops to get_voltage_sel is a fix, as covered in the commit log it fixes inconsistency in handling of the IS_UNSUP() feature in the driver. Andrzej Hajda (1): regulator: fixed regulator_bulk_enable unwinding code Axel Lin (1): regulator: twl: Convert twl4030ldo_ops to get_voltage_sel Dmitry Torokhov (1): regulator: db8500-prcmu - remove incorrect __exit markup Graeme Gregory (1): regulator: palmas: fix number of SMPS voltages Mark Brown (5): Merge remote-tracking branch 'regulator/fix/core' into tmp Merge remote-tracking branch 'regulator/fix/db8500' into tmp Merge remote-tracking branch 'regulator/fix/doc' into tmp Merge remote-tracking branch 'regulator/fix/palmas' into tmp Merge remote-tracking branch 'regulator/fix/twl' into tmp Nishanth Menon (2): regulator: core: update kernel documentation for regulator_desc regulator: core: fix documentation error in regulator_allow_bypass drivers/regulator/core.c | 12 drivers/regulator/db8500-prcmu.c |4 ++-- drivers/regulator/palmas-regulator.c |3 ++- drivers/regulator/twl-regulator.c|9 - include/linux/regulator/driver.h |2 ++ 5 files changed, 18 insertions(+), 12 deletions(-) signature.asc Description: Digital signature
[PATCH] perf, tools: Make perf stat -I ... CSV output flat
From: Andi Kleen
The new perf stat interval code is quite useful, especially when the
data is post processed. Unfortunately the default -x, output is not
very friendly to programs when it contains more than one event.
Each event is printed on its own line, each keyed with the time.
You cannot directly feed it to gnuplot or into R to
compare different events at a specific point in time.
This patch normalizes the output so that a single line contains all
the events for a given time period. Each event is an own column.
With that it's quite easy to do plots and other analysis,
as this is the normalized format many data processing programs expect.
This is not fully normalized yet, as per cpu counts also
end up on the same line (fixing this would be more intrusive)
But good enough for most purposes.
The non CSV output is not changed.
Example:
$ perf stat -o /tmp/x.csv -I 100 -x, bc <<< 2^40 > /dev/null
$ gnuplot
gnuplot> set datafile separator ","
gnuplot> set terminal dumb
gnuplot> plot "/tmp/x.csv" every ::3 using 1:3
110 +++-+-++-+-+++
+ + +"/tmp/x.csv" every ::3 using 1:3 A+
100 ++ AAAAAAAA AAAA++
90 ++ ++
||
80 ++ ++
||
70 ++ ++
||
60 ++ ++
50 ++ ++
||
40 ++ ++
||
30 ++ ++
||
20 ++ ++
10 ++ ++
+ + + ++ + +A+
0 +++-+-++-+-+++
0.2 0.4 0.6 0.8 11.2 1.4 1.6
Cc: eran...@google.com
---
tools/perf/builtin-stat.c | 118 +++--
1 files changed, 82 insertions(+), 36 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index e6f4d1d..81d704a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -66,8 +66,10 @@
#define CNTR_NOT_COUNTED ""
static void print_stat(int argc, const char **argv);
-static void print_counter_aggr(struct perf_evsel *counter, char *prefix);
-static void print_counter(struct perf_evsel *counter, char *prefix);
+static void print_counter_aggr(struct perf_evsel *counter, char *prefix, int
delim,
+ int name);
+static void print_counter(struct perf_evsel *counter, char *prefix, int delim,
+ int name);
static void print_aggr_socket(char *prefix);
/* Default events used for perf stat -T */
@@ -343,6 +345,7 @@ static void print_interval(void)
struct perf_stat *ps;
struct timespec ts, rs;
char prefix[64];
+ int delim = '\n';
if (no_aggr) {
list_for_each_entry(counter, &evsel_list->entries, node) {
@@ -373,15 +376,23 @@ static void print_interval(void)
if (++num_print_interval == 25)
num_print_interval = 0;
+ if (csv_output) {
+ delim = ',';
+ fprintf(output, "%s,", prefix);
+ prefix[0] = 0;
+ }
+
if (aggr_socket)
print_aggr_socket(prefix);
else if (no_aggr) {
list_for_each_entry(counter, &evsel_list->entries, node)
- print_counter(counter, prefix);
+ print_counter(counter, prefix, delim, !csv_output);
} else {
list_for_each_entry(counter, &evsel_list->entries, node)
- print_counter_aggr(counter, prefix);
+ print_counter_aggr(counter, prefix, delim, !csv_output);
}
+ if (csv_output)
+ fputc('\n', output);
}
static int __run_perf_stat(int argc __maybe_unused, const char **argv)
@@ -503,6 +514,21 @@ static int __run_perf_stat(int argc __maybe_unused, const
char **argv)
t0 = rdclock();
clock_gettime(CLOCK_MONOTONIC, &ref_time);
+ if (interval
[GIT PULL] regmap update for v3.9
The following changes since commit a2b37efc4e2aa76a5be29bbde8a2cd1c9c9066bc: Merge remote-tracking branch 'regmap/topic/no-bus' into regmap-next (2013-02-14 17:11:09 +) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git tags/regmap-v3.9-rc1 for you to fetch changes up to 283189d3be56aa6db6f192bb255df68493cd79ac: regmap: irq: call pm_runtime_put in pm_runtime_get_sync failed case (2013-03-01 14:54:16 +0800) regmap: PM fix for v3.9 A simple fix to stop us leaking a runtime PM reference in the case where we fail to enable a device. Li Fei (1): regmap: irq: call pm_runtime_put in pm_runtime_get_sync failed case drivers/base/regmap/regmap-irq.c |1 + 1 file changed, 1 insertion(+) signature.asc Description: Digital signature
