[PATCH] pwm: Add missing static storage class specifiers in core.c file
Fixes the following sparse warnings:
drivers/pwm/core.c:152:6: warning:
symbol 'of_pwmchip_add' was not declared. Should it be static?
drivers/pwm/core.c:165:6: warning:
symbol 'of_pwmchip_remove' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
drivers/pwm/core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index ecb7690..4a8bdfa 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -149,7 +149,7 @@ static struct pwm_device *of_pwm_simple_xlate(struct
pwm_chip *pc,
return pwm;
}
-void of_pwmchip_add(struct pwm_chip *chip)
+static void of_pwmchip_add(struct pwm_chip *chip)
{
if (!chip->dev || !chip->dev->of_node)
return;
@@ -162,7 +162,7 @@ void of_pwmchip_add(struct pwm_chip *chip)
of_node_get(chip->dev->of_node);
}
-void of_pwmchip_remove(struct pwm_chip *chip)
+static void of_pwmchip_remove(struct pwm_chip *chip)
{
if (chip->dev && chip->dev->of_node)
of_node_put(chip->dev->of_node);
--
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: [RFC PATCH 1/3] ACPIHP: introduce a framework for ACPI based system device hotplug
Hi,
A little problem here. :)
On 07/28/2012 07:42 PM, Jiang Liu wrote:
> +int acpihp_register_slot(struct acpihp_slot *slot)
> +{
> + int ret;
> + char *name;
> + size_t off;
> +
> + if (!slot || !slot->slot_ops)
> + return -EINVAL;
> +
> + /* Hook top level hotplug slots under ACPI root device */
> + if (slot->parent)
> + slot->dev.parent = &slot->parent->dev;
> + else
> + slot->dev.parent = &acpi_root->dev;
> +
> + ret = device_add(&slot->dev);
> + if (!ret) {
> + slot->flags |= ACPIHP_SLOT_FLAG_REGISTERED;
> + name = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (name) {
> + off = acpihp_generate_link_name(slot, name, 0);
> + name[off - 1] = '\0';
> + sysfs_create_link(&acpihp_slot_kset->kobj,
> + &slot->dev.kobj, name);
I got a compiler warning here:
CC drivers/acpi/hotplug/core.o
drivers/acpi/hotplug/core.c: In function ‘acpihp_register_slot’:
drivers/acpi/hotplug/core.c:199: warning: ignoring return value of
‘sysfs_create_link’, declared with attribute warn_unused_result
Seems that we need to check the sysfs_create_link()'s return value here, and if
it fails,
shall we at least give a warning message here ?
Thanks. :)
> + kfree(name);
> + }
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpihp_register_slot);
--
Best Regards,
Tang chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
oops in x86/oprofile/dump_stack with 3.4.6
Hi all,
A couple of days ago I tried to use oprofile with enabling call graph in
a recent build of 3.4.6. this causes a OOPS
"BUG: unable to handle kernel paging request at 636f7270".
The oops can be often reproduced by the following steps on my board
based on Intel Atom.
opcontrol --no-vmlinux
opcontrol -c 10
opcontrol -e BR_INST_RETIRED:8000
opcontrl -s
With a few seconds I get the oops.
I've spent some time investigating the problem, and found it is possible
that the marked line in dump_strace function results in the oops as the
content of stack
variable is less than CONFIG_PAGE_OFFSET(0xc000_).
arch/x86/kernel/dumpstack_32.c
int dump_stack()
...
for (;;) {
struct thread_info *context;
context = (struct thread_info *)
((unsigned long)stack & (~(THREAD_SIZE - 1)));
bp = ops->walk_stack(context, stack, bp, ops, data, NULL, &graph);
-> stack = (unsigned long *)context->previous_esp;
if (!stack)
break;
if (ops->stack(data, "IRQ") < 0)
break;
touch_nmi_watchdog();
}
...
Actually I think this scenario should not happen, because the stack
should be kernel stack or irq stack.
So I changed this function by adding simplistic check to avoid this
scenario. It seems to work for my board.
for (;;) {
struct thread_info *context;
+ /*
+* Somehow stack may be less than CONFIG_PAGE_OFFSET,
+* So we should temporarily avoid the scenario before
+* figuring out the root cause.
+*/
+ if (stack < CONFIG_PAGE_OFFSET)
+ break;
context = (struct thread_info *)
((unsigned long)stack & (~(THREAD_SIZE - 1)));
Any suggestion for the change.
Thanks
Wei
The following is the oops I encountered.
BUG: unable to handle kernel paging request at 636f7270
IP: [] print_context_stack+0x69/0x130
*pde =
Oops: [#1] PREEMPT SMP
LTT NESTING LEVEL : 0
Modules linked in:
Pid: 0, comm: swapper/0 Not tainted
3.4.6-WR5.0+snapshot-20120801_standard #9 To be filled by O.E.M. To be
filled by O.E.M./To be filled by O.E.M.
EIP: 0060:[] EFLAGS: 00010046 CPU: 0
EIP is at print_context_stack+0x69/0x130
EAX: 002e EBX: 636f7270 ECX: EDX: 0401
ESI: e000 EDI: EBP: f680be98 ESP: f680be68
DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
CR0: 8005003b CR2: 636f7270 CR3: 0192e000 CR4: 07d0
DR0: DR1: DR2: DR3:
DR6: 0ff0 DR7: 0400
Process swapper/0 (pid: 0, ti=f680a000 task=c183cfa0 task.ti=c1832000)
Stack:
c1761c2c 636f7270 636f6000 636f7ffc 636f6000 c1833ed4 e000
c1833ed4 636f7270 c1dc 636f6000 f680bec8 c1004218 c1dc f680bedc
f680beb4 c1833ed4 f680bec0 c1833ed4 f680bfc4 000a
Call Trace:
[] dump_trace+0x68/0xf0
[] x86_backtrace+0xb2/0xc0
[] oprofile_add_sample+0xa2/0xc0
[] ? do_softirq+0x6f/0xa0
[] ppro_check_ctrs+0x79/0x100
[] ? ppro_shutdown+0x60/0x60
[] profile_exceptions_notify+0x8f/0xb0
[] nmi_handle.isra.0+0x48/0x70
[] do_nmi+0xff/0x570
[] ? run_rebalance_domains+0x155/0x180
[] ? get_parent_ip+0xb/0x40
[] ? __local_bh_enable+0x29/0x70
[] ? ftrace_define_fields_irq_handler_entry+0x80/0x80
[] nmi_stack_correct+0x28/0x2d
[] ? ftrace_define_fields_irq_handler_entry+0x80/0x80
[] ? do_softirq+0x6f/0xa0
[] irq_exit+0x65/0x70
[] do_IRQ+0x51/0xc0
[] common_interrupt+0x29/0x30
[] ? amd_get_subcaches+0x4b/0x90
[] ? intel_idle+0xc6/0x120
[] cpuidle_enter+0x19/0x30
[] cpuidle_idle_call+0xa0/0x320
[] cpu_idle+0x5a/0xc0
[] rest_init+0x6c/0x74
[] start_kernel+0x2fe/0x305
[] ? repair_env_string+0x51/0x51
[] i386_start_kernel+0x78/0x7d
Code: 00 00 3b 5d dc 72 13 8b 45 f0 8d 64 24 24 5b 5e 5f 5d c3 8d b4 26
00 00 00 00 3b 5d ec 72 e8 81 fb ff ff ff bf 0f 86 a3 00 00 00 <8b> 33
89 f0 e8 ae e5 03 00 85 c0 74 1e 8b 45 f0 83 c0 04 39 c3
EIP: [] print_context_stack+0x69/0x130 SS:ESP 0068:f680be68
CR2: 636f7270
---[ end trace d4af25ee5ff6fd8c ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v5] mmc: core: Remove bounce buffer in mmc_send_cxd_data()
It is expected that Extended CSD register(the size of this register
is larger than CID/CSD) will be referenced more frequently as more
fields have been added to Extended CSD and it seems that it is not
a good option to double the memory used.
This patch is intended to avoid the use of bounce buffer for reading
Extended CSD register in mmc_send_cxd_data(). It will provide a better
performance gain by removing memcpy() overhead for a half KiB and
a redundant bounce buffer allocated repeatedly at the cost of providing
DMA-capable buffer from upper caller(but on-stack buffer is allowed
with no performance gain).
Signed-off-by: Kyungsik Lee
Signed-off-by: S, Venkatraman
---
Changes in v2:
- Handling on-stack buffer if it's used in caller.
Changes in v3:
- Remove unnecesary code.
Changes in v4:
- Modify codes based-on S, Venkatraman's comments.
Changes in v5:
- Modify commit log and add NOTE description.
---
drivers/mmc/core/mmc_ops.c | 58 +++
1 files changed, 42 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 0ed2cc5..acf578d 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -230,6 +230,10 @@ mmc_send_cxd_native(struct mmc_host *host, u32 arg, u32
*cxd, int opcode)
return 0;
}
+/*
+ * NOTE: void *buf, Caller for the buf is required to use DMA-capable
+ * buffer or on-stack buffer(with some overhead in callee).
+ */
static int
mmc_send_cxd_data(struct mmc_card *card, struct mmc_host *host,
u32 opcode, void *buf, unsigned len)
@@ -239,13 +243,19 @@ mmc_send_cxd_data(struct mmc_card *card, struct mmc_host
*host,
struct mmc_data data = {0};
struct scatterlist sg;
void *data_buf;
+ int is_on_stack;
- /* dma onto stack is unsafe/nonportable, but callers to this
-* routine normally provide temporary on-stack buffers ...
-*/
- data_buf = kmalloc(len, GFP_KERNEL);
- if (data_buf == NULL)
- return -ENOMEM;
+ is_on_stack = object_is_on_stack(buf);
+ if (is_on_stack) {
+
+ /* dma onto stack is unsafe/nonportable, but callers to this
+* routine normally provide temporary on-stack buffers ...
+*/
+ data_buf = kmalloc(len, GFP_KERNEL);
+ if (data_buf == NULL)
+ return -ENOMEM;
+ } else
+ data_buf = buf;
mrq.cmd = &cmd;
mrq.data = &data;
@@ -280,8 +290,10 @@ mmc_send_cxd_data(struct mmc_card *card, struct mmc_host
*host,
mmc_wait_for_req(host, &mrq);
- memcpy(buf, data_buf, len);
- kfree(data_buf);
+ if (is_on_stack) {
+ memcpy(buf, data_buf, len);
+ kfree(data_buf);
+ }
if (cmd.error)
return cmd.error;
@@ -294,24 +306,32 @@ mmc_send_cxd_data(struct mmc_card *card, struct mmc_host
*host,
int mmc_send_csd(struct mmc_card *card, u32 *csd)
{
int ret, i;
+ u32 *csd_tmp;
if (!mmc_host_is_spi(card->host))
return mmc_send_cxd_native(card->host, card->rca << 16,
csd, MMC_SEND_CSD);
- ret = mmc_send_cxd_data(card, card->host, MMC_SEND_CSD, csd, 16);
+ csd_tmp = kmalloc(16, GFP_KERNEL);
+ if (!csd_tmp)
+ return -ENOMEM;
+
+ ret = mmc_send_cxd_data(card, card->host, MMC_SEND_CSD, csd_tmp, 16);
if (ret)
- return ret;
+ goto err;
for (i = 0;i < 4;i++)
- csd[i] = be32_to_cpu(csd[i]);
+ csd[i] = be32_to_cpu(csd_tmp[i]);
- return 0;
+err:
+ kfree(csd_tmp);
+ return ret;
}
int mmc_send_cid(struct mmc_host *host, u32 *cid)
{
int ret, i;
+ u32 *cid_tmp;
if (!mmc_host_is_spi(host)) {
if (!host->card)
@@ -320,14 +340,20 @@ int mmc_send_cid(struct mmc_host *host, u32 *cid)
cid, MMC_SEND_CID);
}
- ret = mmc_send_cxd_data(NULL, host, MMC_SEND_CID, cid, 16);
+ cid_tmp = kmalloc(16, GFP_KERNEL);
+ if (!cid_tmp)
+ return -ENOMEM;
+
+ ret = mmc_send_cxd_data(NULL, host, MMC_SEND_CID, cid_tmp, 16);
if (ret)
- return ret;
+ goto err;
for (i = 0;i < 4;i++)
- cid[i] = be32_to_cpu(cid[i]);
+ cid[i] = be32_to_cpu(cid_tmp[i]);
- return 0;
+err:
+ kfree(cid_tmp);
+ return ret;
}
int mmc_send_ext_csd(struct mmc_card *card, u8 *ext_csd)
--
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/
Re: [RFC PATCH 1/3] ACPIHP: introduce a framework for ACPI based system device hotplug
On 2012-8-2 15:07, Tang Chen wrote:
> Hi,
>
> A little problem here. :)
>
> On 07/28/2012 07:42 PM, Jiang Liu wrote:
>> +int acpihp_register_slot(struct acpihp_slot *slot)
>> +{
>> +int ret;
>> +char *name;
>> +size_t off;
>> +
>> +if (!slot || !slot->slot_ops)
>> +return -EINVAL;
>> +
>> +/* Hook top level hotplug slots under ACPI root device */
>> +if (slot->parent)
>> +slot->dev.parent = &slot->parent->dev;
>> +else
>> +slot->dev.parent = &acpi_root->dev;
>> +
>> +ret = device_add(&slot->dev);
>> +if (!ret) {
>> +slot->flags |= ACPIHP_SLOT_FLAG_REGISTERED;
>> +name = kmalloc(PAGE_SIZE, GFP_KERNEL);
>> +if (name) {
>> +off = acpihp_generate_link_name(slot, name, 0);
>> +name[off - 1] = '\0';
>> +sysfs_create_link(&acpihp_slot_kset->kobj,
>> + &slot->dev.kobj, name);
>
> I got a compiler warning here:
> CC drivers/acpi/hotplug/core.o
> drivers/acpi/hotplug/core.c: In function ‘acpihp_register_slot’:
> drivers/acpi/hotplug/core.c:199: warning: ignoring return value of
> ‘sysfs_create_link’, declared with attribute warn_unused_result
>
> Seems that we need to check the sysfs_create_link()'s return value here, and
> if it fails,
> shall we at least give a warning message here ?
>
> Thanks. :)
Hi Tang,
Thanks for your comments, will fix it in next version.
Regards!
Gerry
>
>
>> +kfree(name);
>> +}
>> +}
>> +
>> +return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(acpihp_register_slot);
>
--
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] powerpc: fix personality handling in ppc64_personality()
Directly comparing current->personality against PER_LINUX32 doesn't work in cases when any of the personality flags stored in the top three bytes are used. Directly forcefully setting personality to PER_LINUX32 or PER_LINUX discards any flags stored in the top three bytes Use personality() macro to compare only PER_MASK bytes and make sure that we are setting only the bits that should be set, instead of overwriting the whole value. Signed-off-by: Jiri Kosina --- changed since v1: fix the bit ops to reflect the fact that PER_LINUX is actually 0 arch/powerpc/kernel/syscalls.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c index f2496f2..dc1558e 100644 --- a/arch/powerpc/kernel/syscalls.c +++ b/arch/powerpc/kernel/syscalls.c @@ -107,11 +107,11 @@ long ppc64_personality(unsigned long personality) long ret; if (personality(current->personality) == PER_LINUX32 - && personality == PER_LINUX) - personality = PER_LINUX32; + && personality(personality) == PER_LINUX) + personality |= PER_LINUX32; ret = sys_personality(personality); - if (ret == PER_LINUX32) - ret = PER_LINUX; + if (personality(ret) == PER_LINUX32) + ret &= ~PER_LINUX32; return ret; } #endif -- 1.7.3.1 -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation/kvm : Add documentation on Hypercalls
On 08/01/2012 11:55 PM, Marcelo Tosatti wrote: On Wed, Aug 01, 2012 at 04:19:01PM +0530, Raghavendra K T wrote: On 08/01/2012 08:37 AM, Marcelo Tosatti wrote: On Tue, Jul 24, 2012 at 02:23:59PM +0530, Raghavendra K T wrote: From: Raghavendra K T Thanks Alex for KVM_HC_FEATURES inputs and Jan for VAPIC_POLL_IRQ, and Peter (HPA) for suggesting hypercall ABI addition. Signed-off-by: Raghavendra K T --- [...] + + Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively. + The hypercall number should be placed in rax and the return value will be + placed in rax. No other registers will be clobbered unless explicitly stated + by the particular hypercall. It depends on the hypercall. It happens that current hypercalls use the four registers, but its not an ABI (hyper-v hypercalls uses r8, for example). Okay, agree. I did not know about hyper-v. Above one is for X86 and KVM (and not X86 / hyper-v). So I should remove ABI and probably say, Just say "Linux x86 Hypercall", yeah. Ok, Thanks Marcelo.will respin patches with the changes you suggested. Also I would like add Alex's description on ppc hypercalls into Documentation/virtual/kvm/ppc-pv.txt with Alex from/sob or suggested-by in a separate patch unless I see any objection to that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] [S390] do not clobber personality flags in sys_32_personality()
There are multiple errors in how sys_32_personality() handles personality
flags stored in top three bytes.
- directly comparing current->personality against PER_LINUX32 doesn't work
in cases when any of the personality flags stored in the top three bytes
are used.
- directly forcefully setting personality to PER_LINUX32 or PER_LINUX
discards any flags stored in the top three bytes
Fix the first one by properly using personality() macro to compare only
PER_MASK bytes.
Fix the second one by setting only the bits that should be set, instead of
overwriting the whole value.
Signed-off-by: Jiri Kosina
---
changed since v1: fix the bit ops to reflect the fact that PER_LINUX is
actually 0
arch/s390/kernel/sys_s390.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kernel/sys_s390.c b/arch/s390/kernel/sys_s390.c
index b4a29ee..d0964d2 100644
--- a/arch/s390/kernel/sys_s390.c
+++ b/arch/s390/kernel/sys_s390.c
@@ -81,11 +81,12 @@ SYSCALL_DEFINE1(s390_personality, unsigned int, personality)
{
unsigned int ret;
- if (current->personality == PER_LINUX32 && personality == PER_LINUX)
- personality = PER_LINUX32;
+ if (personality(current->personality) == PER_LINUX32 &&
+ personality(personality) == PER_LINUX)
+ personality |= PER_LINUX32;
ret = sys_personality(personality);
- if (ret == PER_LINUX32)
- ret = PER_LINUX;
+ if (personality(ret) == PER_LINUX32)
+ ret &= ~PER_LINUX32;
return ret;
}
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] parisc: fix personality flag check in copy_thread()
Directly comparing task_struct->personality against PER_* is not fully
correct, as it doesn't take flags potentially stored in top three bytes
into account.
Analogically, directly forcefully setting personality to PER_LINUX32 or
PER_LINUX discards any flags stored in the top three bytes.
Signed-off-by: Jiri Kosina
---
changed since v1: fix the bit ops to reflect the fact that PER_LINUX is
actually 0
arch/parisc/kernel/process.c|2 +-
arch/parisc/kernel/sys_parisc.c |8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
index d4b94b3..2c05a92 100644
--- a/arch/parisc/kernel/process.c
+++ b/arch/parisc/kernel/process.c
@@ -309,7 +309,7 @@ copy_thread(unsigned long clone_flags, unsigned long usp,
cregs->ksp = (unsigned long)stack
+ (pregs->gr[21] & (THREAD_SIZE - 1));
cregs->gr[30] = usp;
- if (p->personality == PER_HPUX) {
+ if (personality(p->personality) == PER_HPUX) {
#ifdef CONFIG_HPUX
cregs->kpc = (unsigned long) &hpux_child_return;
#else
diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c
index c9b9322..7f9658e 100644
--- a/arch/parisc/kernel/sys_parisc.c
+++ b/arch/parisc/kernel/sys_parisc.c
@@ -225,12 +225,12 @@ long parisc_personality(unsigned long personality)
long err;
if (personality(current->personality) == PER_LINUX32
- && personality == PER_LINUX)
- personality = PER_LINUX32;
+ && personality(personality) == PER_LINUX)
+ personality |= PER_LINUX32;
err = sys_personality(personality);
- if (err == PER_LINUX32)
- err = PER_LINUX;
+ if (personality(err) == PER_LINUX32)
+ err &= ~PER_LINUX32;
return err;
}
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] sparc64: do not clobber personality flags in sys_sparc64_personality()
>From 4f000eda5917ceecb03767962026cc6a390b8216 Mon Sep 17 00:00:00 2001
From: Jiri Kosina
Date: Wed, 1 Aug 2012 21:10:51 +0200
Subject: [PATCH 4/4] sparc64: do not clobber personality flags in
sys_sparc64_personality()
There are multiple errors in how sys_sparc64_personality() handles
personality flags stored in top three bytes.
- directly comparing current->personality against PER_LINUX32 doesn't work
in cases when any of the personality flags stored in the top three bytes
are used.
- directly forcefully setting personality to PER_LINUX32 or PER_LINUX
discards any flags stored in the top three bytes
Fix the first one by properly using personality() macro to compare only
PER_MASK bytes.
Fix the second one by setting only the bits that should be set, instead of
overwriting the whole value.
Signed-off-by: Jiri Kosina
---
changed since v1: fix the bit ops to reflect the fact that PER_LINUX is
actually 0
arch/sparc/kernel/sys_sparc_64.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/sparc/kernel/sys_sparc_64.c b/arch/sparc/kernel/sys_sparc_64.c
index 0dc1f57..11c6c96 100644
--- a/arch/sparc/kernel/sys_sparc_64.c
+++ b/arch/sparc/kernel/sys_sparc_64.c
@@ -502,12 +502,12 @@ SYSCALL_DEFINE1(sparc64_personality, unsigned long,
personality)
{
int ret;
- if (current->personality == PER_LINUX32 &&
- personality == PER_LINUX)
- personality = PER_LINUX32;
+ if (personality(current->personality) == PER_LINUX32 &&
+ personality(personality) == PER_LINUX)
+ personality |= PER_LINUX32;
ret = sys_personality(personality);
- if (ret == PER_LINUX32)
- ret = PER_LINUX;
+ if (personality(ret) == PER_LINUX32)
+ ret &= ~PER_LINUX32;
return ret;
}
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -alternative] mm: hugetlbfs: Close race during teardown of hugetlbfs shared page tables V2 (resend)
Hi Larry, On Wed 01-08-12 11:06:33, Larry Woodman wrote: > On 08/01/2012 08:32 AM, Michal Hocko wrote: > > > >I am really lame :/. The previous patch is wrong as well for goto out > >branch. The updated patch as follows: > This patch worked fine Michal! Thanks for the good news! > You and Mel can duke it out over who's is best. :) The answer is clear here ;) Mel did the hard work of identifying the culprit so kudos go to him. I just tried to solve the issue more inside x86 arch code. The pmd allocation outside of sharing code seemed strange to me for quite some time I just underestimated its consequences completely. Both approaches have some pros. Mel's patch is more resistant to other not-yet-discovered races and it also makes the arch independent code more robust because relying on the pmd trick is not ideal. On the other hand, mine is more coupled with the sharing code so it makes the code easier to follow and also makes the sharing more effective because racing processes see pmd populated when checking for shareable mappings. So I am more inclined to mine but I don't want to push it because both are good and make sense. What other people think? > > Larry > -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Remove obsolete Chelsio cxgb3 firmware
From: Tim Gardner Date: Wed, 1 Aug 2012 13:17:50 -0600 > The current firmware version used by the device driver > is 7.12.0 > > Cc: Paul Gortmaker > Cc: Ben Hutchings > Cc: James Bottomley > Cc: Dan Williams > Cc: Divy Le Ray > Cc: net...@vger.kernel.org > Signed-off-by: Tim Gardner "git am" refuses to apply this to current 'net': Applying: firmware: Remove obsolete Chelsio cxgb3 firmware error: removal patch leaves file contents error: firmware/cxgb3/t3fw-7.10.0.bin.ihex: patch does not apply -- 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] bnx2x: fix mem leak when command is unknown
From: Jesper Juhl Date: Tue, 31 Jul 2012 23:39:37 +0200 (CEST) > In bnx2x_mcast_enqueue_cmd() we'll leak the memory allocated to > 'new_cmd' if we hit the deafault case of the 'switch (cmd)'. > Add a 'kfree(new_cmd)' to that case to avoid the leak. > > Signed-off-by: Jesper Juhl Applied. -- 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] drm: ignore disconnected <-> unknown status changes
On an AOpen i915GMm-hfs the hotplug events generated by transitions between connector_status_unknown and connector_status_disconnected cause screen distortions. The attached patch cures the problem by disabling the generation of hotplug events in those cases. That should be safe for everybody as the only relevant changes are those from / to connector_status_connected. cu, Knut >From f631128c46f916eb58bbdabf867248a04a0d2fc5 Mon Sep 17 00:00:00 2001 From: Knut Petersen Date: Thu, 2 Aug 2012 08:52:04 +0200 Subject: [PATCH] drm: ignore disconnected <-> unknown status changes Only generate a hotplug event if the status changed to / from connector_status_connected. On some hardware the connector status is oscillating between disconnected and unknown, and the hotplug events mirroring these transitions cause screen distortions. As the only reasonable action on such a status change is to ignore it, it also is safe not to genereate a hotplug event at all. Needed for / tested on AOpen i915GMm-hfs mobo. Signed-off-by: Knut Petersen --- drivers/gpu/drm/drm_crtc_helper.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 3252e70..fb6160b 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -954,7 +954,11 @@ static void output_poll_execute(struct work_struct *work) connector->base.id, drm_get_connector_name(connector), old_status, connector->status); - if (old_status != connector->status) + /* changes are only relevant if previous or + current status is connector_status_connected */ + if (old_status != connector->status && + (old_status == connector_status_connected || + connector->status == connector_status_connected)) changed = true; } -- 1.7.7
Re: kernel BUG at fs/buffer.c:2886! Linux 3.5.0
Hi, So 12 commits left, corresponding to this bisection log git bisect start # bad: [2d534926205db9ffce4bbbde67cb9b2cee4b835c] Merge tag 'irqdomain-for-linus' of git://git.secretlab.ca/git/linux-2.6 git bisect bad 2d534926205db9ffce4bbbde67cb9b2cee4b835c # good: [c3b92c8787367a8bb53d57d9789b558f1295cc96] Linux 3.1 git bisect good c3b92c8787367a8bb53d57d9789b558f1295cc96 # good: [95211279c5ad00a317c98221d7e4365e02f20836] Merge branch 'akpm' (Andrew's patch-bomb) git bisect good 95211279c5ad00a317c98221d7e4365e02f20836 # good: [654443e20dfc0617231f28a07c96a979ee1a0239] Merge branch 'perf-uprobes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good 654443e20dfc0617231f28a07c96a979ee1a0239 # bad: [f0a08fcb5972167e55faa330c4a24fbaa3328b1f] Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile git bisect bad f0a08fcb5972167e55faa330c4a24fbaa3328b1f # bad: [f5e7e844a571124ffc117d4696787d6afc4fc5ae] Merge tag 'for-linus-3.5-20120601' of git://git.infradead.org/linux-mtd git bisect bad f5e7e844a571124ffc117d4696787d6afc4fc5ae # good: [f465d145d76803fe6332092775d891c8c509aa44] Merge tag 'cleanup-initcall' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good f465d145d76803fe6332092775d891c8c509aa44 # good: [a70f35af4e49f87ba4b6c4b30220fbb66cd74af6] Merge branch 'for-3.5/drivers' of git://git.kernel.dk/linux-block git bisect good a70f35af4e49f87ba4b6c4b30220fbb66cd74af6 # good: [a00b6151a2ae4c52576c35d3998e144a993d50b8] Merge branch 'for-3.5-take-2' of git://linux-nfs.org/~bfields/linux git bisect good a00b6151a2ae4c52576c35d3998e144a993d50b8 # bad: [1193755ac6328ad240ba987e6ec41d5e8baf0680] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs git bisect bad 1193755ac6328ad240ba987e6ec41d5e8baf0680 # good: [51eab603f5c86dd1eae4c525df3e7f7eeab401d6] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs git bisect good 51eab603f5c86dd1eae4c525df3e7f7eeab401d6 # bad: [eb36c5873b96e8c7376768d3906da74aae6e3839] new helper: vm_mmap_pgoff() git bisect bad eb36c5873b96e8c7376768d3906da74aae6e3839 # skip: [eea62f831b8030b0eeea8314eed73b6132d1de26] brlocks/lglocks: turn into functions git bisect skip eea62f831b8030b0eeea8314eed73b6132d1de26 # good: [52576da3545e78c534d901a39f6f2391665c641b] hpfs: bitmaps are little-endian git bisect good 52576da3545e78c534d901a39f6f2391665c641b # bad: [3ed37648e1cbf1bbebc200c6ea8fd8daf8325843] fs: move file_remove_suid() to fs/inode.c git bisect bad 3ed37648e1cbf1bbebc200c6ea8fd8daf8325843 # bad: [962830df366b66e71849040770ae6ba55a8b4aec] brlocks/lglocks: API cleanups git bisect bad 962830df366b66e71849040770ae6ba55a8b4aec the commit left are commit 962830df366b66e71849040770ae6ba55a8b4aec Author: Andi Kleen Date: Tue May 8 13:32:02 2012 +0930 brlocks/lglocks: API cleanups commit eea62f831b8030b0eeea8314eed73b6132d1de26 Author: Andi Kleen Date: Tue May 8 13:32:24 2012 +0930 brlocks/lglocks: turn into functions commit 9dd6fa03ab31bb57cee4623a689d058d222fbe68 Author: Rusty Russell Date: Tue May 8 13:29:45 2012 +0930 lglock: remove online variants of lock commit ea022dfb3c2a4680483b00eb2fecc9fc4f6091d1 Author: Al Viro Date: Thu May 3 10:14:29 2012 -0400 ocfs: simplify symlink handling commit 408bd629badbd4353b238ab6f58001529b274d73 Author: Al Viro Date: Thu May 3 09:34:20 2012 -0400 get rid of pointless allocations and copying in ecryptfs_follow_link() switch to generic_readlink(), while we are at it commit 28fe3c1963b0bafa56ec92df1987828090151d87 Author: Al Viro Date: Tue Apr 17 16:41:13 2012 -0400 hpfs: assorted endianness annotations commit 77ee26e44c28823a29bc09091950544566ae7cea Author: Al Viro Date: Tue Apr 17 16:26:46 2012 -0400 hpfs: annotate ea commit 46287aa652fa8ea1edac41817ddc63332495ffc3 Author: Al Viro Date: Tue Apr 17 16:20:49 2012 -0400 hpfs: annotate struct hpfs_dirent commit 6ce2bbba5266c1dd5c27dd8af1887ed8ca564919 Author: Al Viro Date: Tue Apr 17 16:11:25 2012 -0400 hpfs: annotate struct anode commit 2b9f1cc29ba0e56089fe04501ec6d3b49eee3c3e Author: Al Viro Date: Tue Apr 17 16:09:25 2012 -0400 hpfs: annotate struct fnode commit ddc19e6e04c1131a48f5b9a25aa433bbd8430cdd Author: Al Viro Date: Tue Apr 17 15:59:35 2012 -0400 hpfs: annotate btree nodes, get rid of bitfields mess commit 39413c6046de282a92739110cfafb8f1e862680d Author: Al Viro Date: Tue Apr 17 15:32:22 2012 -0400 hpfs: annotate struct dnode After that bisection start to be quite hard : i have compile error or unbootable kernel or unrelated OOPS For the record the BUG that i'm chasing is this one : [ 934.933390] kernel BUG at fs/buffer.c:2882! [ 934.933401] invalid opcode: [#1] SMP [ 934.933412] CPU 0 [ 934.933419] Modules linked in: drbd lru_cache [ 934.933429] [ 934.933437] Pid: 4301, comm: deliver Not tainted 3.4.0+ #16 HP ProLiant ML15
Re: [PATCH 2/5] clk: mmp: add clock definition for pxa168
On Tue, Jul 31, 2012 at 7:54 PM, Arnd Bergmann wrote: > On Tuesday 31 July 2012, Chao Xie wrote: >> +#define APBC_RTC APBC_REG(0x28) >> +#define APBC_TWSI0 APBC_REG(0x2c) >> +#define APBC_KPC APBC_REG(0x30) >> +#define APBC_UART0 APBC_REG(0x00) >> +#define APBC_UART1 APBC_REG(0x04) >> +#define APBC_GPIO APBC_REG(0x08) >> +#define APBC_PWM0 APBC_REG(0x0c) >> +#define APBC_PWM1 APBC_REG(0x10) >> +#define APBC_PWM2 APBC_REG(0x14) >> +#define APBC_PWM3 APBC_REG(0x18) >> +#define APBC_SSP0 APBC_REG(0x81c) >> +#define APBC_SSP1 APBC_REG(0x820) >> +#define APBC_SSP2 APBC_REG(0x84c) >> +#define APBC_SSP3 APBC_REG(0x858) >> +#define APBC_SSP4 APBC_REG(0x85c) >> +#define APBC_TWSI1 APBC_REG(0x6c) >> +#define APBC_UART2 APBC_REG(0x70) >> + >> +#define APMU_SDH0 APMU_REG(0x54) >> +#define APMU_SDH1 APMU_REG(0x58) >> +#define APMU_USB APMU_REG(0x5c) >> +#define APMU_DISP0 APMU_REG(0x4c) >> +#define APMU_CCIC0 APMU_REG(0x50) >> +#define APMU_DFC APMU_REG(0x60) > > Same comment as for patch 1: get the address from the device tree and just > define those macros to the offset, like: > > #define APBC_RTC 0x28 > > apbc_clks[rtc_clk] = mmp_clk_register_apbc(rtc_clk, clk32k, APBC_RTC, 10, > APBC_POWER_CTRL, mmp_clk_lock); > clk_register_clkdev(apbc_clks[rtc_clk], NULL, "sa1100-rtc"); > > Arnd > hi I would like to keep the mmp_clk_register_apbc to receive the "reg base" not "reg offset". It will be aligned with other kind of clock register APIs. To read out APBC base register from device tree can be added at the clock-pxa168.c, and it can map the registers and pass to the mmp_clk_register_apbc. Now, i have talked to Haojian who is doing device tree maintainer in pxa/mmp. This kind of support is not added. I suggest that after device tree support in clock can be added later after other functionality of the clock framework is fine. -- 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] sparc64: do not clobber personality flags in sys_sparc64_personality()
From: Jiri Kosina Date: Thu, 2 Aug 2012 09:12:46 +0200 (CEST) > From 4f000eda5917ceecb03767962026cc6a390b8216 Mon Sep 17 00:00:00 2001 > From: Jiri Kosina > Date: Wed, 1 Aug 2012 21:10:51 +0200 > Subject: [PATCH 4/4] sparc64: do not clobber personality flags in > sys_sparc64_personality() > > There are multiple errors in how sys_sparc64_personality() handles > personality flags stored in top three bytes. > > - directly comparing current->personality against PER_LINUX32 doesn't work > in cases when any of the personality flags stored in the top three bytes > are used. > - directly forcefully setting personality to PER_LINUX32 or PER_LINUX > discards any flags stored in the top three bytes > > Fix the first one by properly using personality() macro to compare only > PER_MASK bytes. > Fix the second one by setting only the bits that should be set, instead of > overwriting the whole value. > > Signed-off-by: Jiri Kosina Applied, thanks a lot Jiri. -- 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] pwm: Add missing static storage class specifiers in core.c file
On Thu, Aug 02, 2012 at 12:32:42PM +0530, Sachin Kamat wrote: > Fixes the following sparse warnings: > drivers/pwm/core.c:152:6: warning: > symbol 'of_pwmchip_add' was not declared. Should it be static? > drivers/pwm/core.c:165:6: warning: > symbol 'of_pwmchip_remove' was not declared. Should it be static? > > Signed-off-by: Sachin Kamat Applied, thanks. Thierry pgp12ap8zwrMw.pgp Description: PGP signature
Re: [PATCH 01/24] arm: initial Xen support
On Wed, 2012-08-01 at 19:27 +0100, Rob Herring wrote: > On 07/26/2012 10:33 AM, Stefano Stabellini wrote: > > - Basic hypervisor.h and interface.h definitions. > > - Skelethon enlighten.c, set xen_start_info to an empty struct. > > - Do not limit xen_initial_domain to PV guests. > > > > The new code only compiles when CONFIG_XEN is set, that is going to be > > added to arch/arm/Kconfig in a later patch. > > > > Signed-off-by: Stefano Stabellini > > --- > > arch/arm/Makefile |1 + > > arch/arm/include/asm/hypervisor.h |6 +++ > > arch/arm/include/asm/xen/hypervisor.h | 19 ++ > > arch/arm/include/asm/xen/interface.h | 64 > > + > > These headers don't seem particularly ARM specific. Could they be moved > to asm-generic or include/linux? Or perhaps include/xen. A bunch of it also looks like x86 specific stuff which has crept in. e.g. PARAVIRT_LAZY_FOO and paravirt_get_lazy_mode() are arch/x86 specific and shouldn't be called from common code (and aren't, AFAICT). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v5 3/6] fsl-dma: change release process of dma descriptor for supporting async_tx
> -Original Message- > From: Ira W. Snyder [mailto:i...@ovro.caltech.edu] > Sent: Thursday, August 02, 2012 1:25 AM > To: Liu Qiang-B32616 > Cc: linux-cry...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux- > ker...@vger.kernel.org; dan.j.willi...@gmail.com; Vinod Koul; > herb...@gondor.hengli.com.au; Dan Williams; da...@davemloft.net > Subject: Re: [PATCH v5 3/6] fsl-dma: change release process of dma > descriptor for supporting async_tx > > On Wed, Aug 01, 2012 at 04:49:17PM +0800, qiang@freescale.com wrote: > > From: Qiang Liu > > > > Fix the potential risk when enable config NET_DMA and ASYNC_TX. > > Async_tx is lack of support in current release process of dma > > descriptor, all descriptors will be released whatever is acked or > > no-acked by async_tx, so there is a potential race condition when dma > > engine is uesd by others clients (e.g. when enable NET_DMA to offload > TCP). > > > > In our case, a race condition which is raised when use both of talitos > > and dmaengine to offload xor is because napi scheduler will sync all > > pending requests in dma channels, it affects the process of raid > > operations due to ack_tx is not checked in fsl dma. The no-acked > > descriptor is freed which is submitted just now, as a dependent tx, > > this freed descriptor trigger > > BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit(). > > > > TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf4 CPU: 0 > > GPR00: 0001 ecf41ca0 ee44/921a94a0 003f 0001 c00593e4 > > 0001 > > GPR08: a7a7a7a7 0001 045/92002 42028042 100a38d4 > > ed576d98 > > GPR16: ed5a11b0 2b162000 0200 046/92000 2d555000 > > ed3015e8 c15a7aa0 > > GPR24: c155fc40 ecb63220 ecf41d28 e47/92f640bb0 > > ef640c30 ecf41ca0 NIP [c02b048c] async_tx_submit+0x6c/0x2b4 LR > > [c02b068c] async_tx_submit+0x26c/0x2b4 Call Trace: > > [ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable) > > [ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c [ecf41d20] [c0421064] > > async_copy_data+0xa0/0x17c [ecf41d70] [c0421cf4] > > __raid_run_ops+0x874/0xe10 [ecf41df0] [c0426ee4] > > handle_stripe+0x820/0x25e8 [ecf41e90] [c0429080] raid5d+0x3d4/0x5b4 > > [ecf41f40] [c04329b8] md_thread+0x138/0x16c [ecf41f90] [c008277c] > > kthread+0x8c/0x90 [ecf41ff0] [c0011630] kernel_thread+0x4c/0x68 > > > > Another major modification in this patch is the change to completed > > descriptors, there is a potential risk which caused by exception > > interrupt, all descriptors in ld_running list are seemed completed > > when an interrupt raised, it works fine under normal condition, but if > > there is an exception occured, it cannot work as our excepted. > > Hardware should not depend on s/w list, the right way is to read > > current descriptor address register to find the last completed > > descriptor. If an interrupt is raised by an error, all descriptors in > > ld_running should not be seemed finished, or these unfinished > descriptors in ld_running will be released wrongly. > > > > A simple way to reproduce, > > Enable dmatest first, then insert some bad descriptors which can > > trigger Programming Error interrupts before the good descriptors. > > Last, the good descriptors will be freed before they are processsed > > because of the exception intrerrupt. > > > > Note: the bad descriptors are only for simulating an exception > interrupt. > > This case can illustrate the potential risk in current fsl-dma very > well. > > > > I've never managed to trigger a PE (programming error) interrupt on the > 83xx hardware. Any time I intentionally caused an error, the hardware > wedged itself. The CB (channel busy) bit is stuck high, and cannot be > cleared without a hard reset of the board. Sorry, the exception indeed will be occurred, actually, the capability DMA_INTERRUPT will reproduce the issue under conditions. It will trigger a exception because of bad descriptor (length is zero, src and dst are zero, a->b->c->bada->badb->d, we cannot find out which one is really finished in an interrupt tasklet). So, we'd better consider this case. BTW, I have already found out your patch which is used to resolve the issue of dma lock, http://lkml.indiana.edu/hypermail/linux/kernel/1103.0/01519.html > > I agree the "snoop on the hardware" technique works. As far as I can tell, > you have implemented the code correctly. > > The MPC8349EARM.pdf from Freescale indicates that the hardware will halt > in response to a programming error, and generate a PE interrupt. See > section 12.5.3.3 (pg 568). > > The driver, as it is written, will never recover from such a condition. > Since you are complaining about this situation, do you intend to fix it? Frankly, I don't think your patch really can resolve the issue. Now, I understand what problem happen to you, I will follow it. Yes, you are right, the driver will never recover except reset the board. I see your description and I can reproduce i
Re: [PATCH -alternative] mm: hugetlbfs: Close race during teardown of hugetlbfs shared page tables V2 (resend)
On Thu, Aug 02, 2012 at 09:19:34AM +0200, Michal Hocko wrote: > Hi Larry, > > On Wed 01-08-12 11:06:33, Larry Woodman wrote: > > On 08/01/2012 08:32 AM, Michal Hocko wrote: > > > > > >I am really lame :/. The previous patch is wrong as well for goto out > > >branch. The updated patch as follows: > > This patch worked fine Michal! > > Thanks for the good news! > > > You and Mel can duke it out over who's is best. :) > > The answer is clear here ;) Mel did the hard work of identifying the > culprit so kudos go to him. I'm happy once it's fixed! > I just tried to solve the issue more inside x86 arch code. The pmd > allocation outside of sharing code seemed strange to me for quite some > time I just underestimated its consequences completely. > > Both approaches have some pros. Mel's patch is more resistant to other > not-yet-discovered races and it also makes the arch independent code > more robust because relying on the pmd trick is not ideal. If there is another race then it is best to hear about it, understand it and fix the underlying problem. More importantly, your patch ensures that two processes faulting at the same time will share page tables with each other. My patch only noted that this missed opportunity could cause problems with fork. > On the other hand, mine is more coupled with the sharing code so it > makes the code easier to follow and also makes the sharing more > effective because racing processes see pmd populated when checking for > shareable mappings. > It could do with a small comment above huge_pmd_share() explaining that calling pmd_alloc() under the i_mmap_mutex is necessary to prevent two parallel faults missing a sharing opportunity with each other but it's not mandatory. > So I am more inclined to mine but I don't want to push it because both > are good and make sense. What other people think? > I vote yours Reviewed-by: Mel Gorman -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Need help debugging crazy kernel memory issue
> kernel-2.6.32-220.17.1.el6.x86_64 > kernel-2.6.32-220.23.1.el6.x86_64 > kernel-2.6.32-279.1.1.el6.x86_64 You need to contact your vendor for RHEL based kernels - they are sufficiently different to upstream and from a long time back (with backports). This is the wrong place unless you can duplicate it with an upstream 3.2, 3.4 or similar kernel. Alan -- 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 07/13] perf: Add attribute to filter out callchains
On Wed, Aug 01, 2012 at 02:10:59PM +0400, Jiri Olsa wrote:
> From: Frederic Weisbecker
>
> Introducing following bits to the the perf_event_attr struct:
> - exclude_callchain_kernel to filter out kernel callchain
> from the sample dump
> - exclude_callchain_user to filter out user callchain
> from the sample dump
>
> We need to be able to disable standard user callchain dump
> when we use the dwarf cfi callchain mode, because frame
> pointer based user callchains are useless in this mode.
>
> Implementing also exclude_callchain_kernel to have complete
> set of options.
>
> Signed-off-by: Frederic Weisbecker
> [ Added kernel callchains filtering ]
> Signed-off-by: Jiri Olsa
> CC: Andrew Vagin
Acked-by: Andrew Vagin
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index c4582bb..0902d4a 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4130,8 +4130,12 @@ void perf_prepare_sample(struct perf_event_header
> *header,
>
> if (sample_type & PERF_SAMPLE_CALLCHAIN) {
> int size = 1;
> + int kernel = !event->attr.exclude_callchain_kernel;
> + int user = !event->attr.exclude_callchain_user;
>
> - data->callchain = perf_callchain(event, regs);
> + if (kernel || user)
> + data->callchain = perf_callchain(event, regs,
> + kernel, user);
I am not sure, that we need two arguments kernel and user here,
we can get them from event inside perf_callchain...
>
> if (data->callchain)
> size += data->callchain->nr;
> diff --git a/kernel/events/internal.h b/kernel/events/internal.h
> index ce7bdfc..95d0215 100644
> --- a/kernel/events/internal.h
> +++ b/kernel/events/internal.h
> @@ -126,7 +126,8 @@ DEFINE_OUTPUT_COPY(__output_copy_user,
> arch_perf_out_copy_user)
>
> /* Callchain handling */
> extern struct perf_callchain_entry *
> -perf_callchain(struct perf_event *event, struct pt_regs *regs);
> +perf_callchain(struct perf_event *event, struct pt_regs *regs,
> +int kernel, int user);
> extern int get_callchain_buffers(void);
> extern void put_callchain_buffers(void);
>
> --
> 1.7.7.6
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: OMAP: omap_device: expose hwmod assert/deassert to omap devices
Hi Omar
On Mon, 16 Jul 2012, Omar Ramirez Luna wrote:
> This APIs are meant to be an interface to hwmod assert/deassert
> function, omap devices can call them through their platform data
> to control their reset lines, they are expected to know the name
> of the reset line they are trying to control.
>
> Signed-off-by: Omar Ramirez Luna
This one has been queued for 3.7 with a few changes. Some more detail was
added to the function documentationrovement. Also the multiple
assignments were removed per Documentation/CodingStyle chapter 1:
"Don't put multiple assignments on a single line either."
Please let me know if you have any comments.
- Paul
From: Omar Ramirez Luna
Date: Mon, 16 Jul 2012 14:21:25 -0500
Subject: [PATCH] ARM: OMAP2+: omap_device: expose hwmod assert/deassert to
omap devices
This API is meant to be an interface to hwmod assert/deassert
function, omap devices can call them through their platform data to
control their reset lines, they are expected to know the name of the
reset line they are trying to control.
Signed-off-by: Omar Ramirez Luna
[p...@pwsan.com: tweaked some documentation; fixed CodingStyle issue]
Signed-off-by: Paul Walmsley
---
arch/arm/plat-omap/include/plat/omap_device.h |4 ++
arch/arm/plat-omap/omap_device.c | 55 +
2 files changed, 59 insertions(+)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 4327b2c..27bcc24 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -118,6 +118,10 @@ int omap_device_get_context_loss_count(struct
platform_device *pdev);
/* Other */
+int omap_device_assert_hardreset(struct platform_device *pdev,
+const char *name);
+int omap_device_deassert_hardreset(struct platform_device *pdev,
+const char *name);
int omap_device_idle_hwmods(struct omap_device *od);
int omap_device_enable_hwmods(struct omap_device *od);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index c490240..3b02312 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -925,6 +925,61 @@ int omap_device_shutdown(struct platform_device *pdev)
}
/**
+ * omap_device_assert_hardreset - set a device's hardreset line
+ * @pdev: struct platform_device * to reset
+ * @name: const char * name of the reset line
+ *
+ * Set the hardreset line identified by @name on the IP blocks
+ * associated with the hwmods backing the platform_device @pdev. All
+ * of the hwmods associated with @pdev must have the same hardreset
+ * line linked to them for this to work. Passes along the return value
+ * of omap_hwmod_assert_hardreset() in the event of any failure, or
+ * returns 0 upon success.
+ */
+int omap_device_assert_hardreset(struct platform_device *pdev, const char
*name)
+{
+ struct omap_device *od = to_omap_device(pdev);
+ int ret = 0;
+ int i;
+
+ for (i = 0; i < od->hwmods_cnt; i++) {
+ ret = omap_hwmod_assert_hardreset(od->hwmods[i], name);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+/**
+ * omap_device_deassert_hardreset - release a device's hardreset line
+ * @pdev: struct platform_device * to reset
+ * @name: const char * name of the reset line
+ *
+ * Release the hardreset line identified by @name on the IP blocks
+ * associated with the hwmods backing the platform_device @pdev. All
+ * of the hwmods associated with @pdev must have the same hardreset
+ * line linked to them for this to work. Passes along the return
+ * value of omap_hwmod_deassert_hardreset() in the event of any
+ * failure, or returns 0 upon success.
+ */
+int omap_device_deassert_hardreset(struct platform_device *pdev,
+ const char *name)
+{
+ struct omap_device *od = to_omap_device(pdev);
+ int ret = 0;
+ int i;
+
+ for (i = 0; i < od->hwmods_cnt; i++) {
+ ret = omap_hwmod_deassert_hardreset(od->hwmods[i], name);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+/**
* omap_device_align_pm_lat - activate/deactivate device to match wakeup lat
lim
* @od: struct omap_device *
*
--
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: [alsa-devel] [PATCH 1/6] ASoC: dapm: If one widget fails, do not force all subsequent widgets to fail too
On Wed, Aug 01, 2012 at 08:41:34PM +0100, Mark Brown wrote: > On Wed, Aug 01, 2012 at 05:08:24PM +0100, Mark Brown wrote: > > On Wed, Aug 01, 2012 at 02:50:32PM +0100, Lee Jones wrote: > > > > >It's very disappointing to see such an error exist, and even more > > > >disappointing that there's no interest in fixing the driver. > > > > This is incorrect. I'm sure the driver will be fixed post-haste when > > > Ola returns back from vacation. If I can find some time I might > > > dabble in the mean-time also. > > > It may not be what you're intending but it's unfortuantely what's I'm > > seeing. > > Just to expand on this a bit since I've found myself pushing back in > this sort of way far too often with these recent serieses and it's > making everyone grumpy: > > What I'm seeing here is a lot of patches getting sent with problems that > I'd really not expect from someone sending such a high volume of > patches. Things like the lack of documentation for the DT bindings for > example, it's something that's mandatory and which people doing lots of > device tree work really ought to be aware of. There's also noticable > pushback with fixing some of these issues, and like I say this happens > often enough to be really noticeable. > > This isn't awesome from a review point of view, it's not nice to find > issues in things and when it happens a lot for the wrong sort of thing > it ends up seeming like the time spent doing the reviews isn't valued. Okay, seeing as we're lying our cards on the table, here's my hand: I'm in a very difficult position here. My initial task was to enable Device Tree on all drivers associated with the Snowball low-cost development board. I was working very closely with Arnd, who was regularly requesting code restructuring, both within the drivers and in platform code. Something I was only too pleased to do. Then some of the original authors noticed the restructuring and I subsequently spent a great deal of time defending my actions. Now we have some systems in place to keep everyone informed and happy. Over time, the requests for Maintainers have Snowballed (pun intended). My task now seems to be enabling drivers for Device Tree _and_ fix all associated driver bugs, including any requested restructuring and API adoption. What you fail to notice is that I am only one person, and hopping all over the code-base trying to do everyone's bidding is no mean feat. In reality I am no more obliged to fix driver bugs than you are. In fact as the Maintainer of some of these subsystems, perhaps you could even help out a bit? With regards to the documentation, I am perfectly aware that any new binding needs to be documented. Leaving it out was intentional until we can agree on the bindings. After you told me you review the documentation rather than the code bindings themselves ( pffft... ;) ) I added the documentation to the patch-set. I always had every intention of writing them! On your last point about feeling undervalued, that's not the case at all. I do respect your opinion and value your reviews. They are always completed quickly and are very thorough. If I had one complaint it's that you are _too_ stringent. Some of this stuff really doesn't matter. We are all trying to do good things here. Please try not to be too over- critical. We all know Mainlining is a good thing. Perhaps less people would be so frightened of it, thus more people would do it if the reviews weren't such a ball-ache ( for want of a better expression :) ). -- 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] ipv6: Fix premature timeout for MLDv1 compatibility mode
The timeout for MLDv1 compatibility mode is now calculated according to Section 9.2 in RFC 3810. Signed-off-by: Dragos Ilie --- net/ipv6/mcast.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c index 92f8e48..ef824a0 100644 --- a/net/ipv6/mcast.c +++ b/net/ipv6/mcast.c @@ -109,6 +109,7 @@ static int ip6_mc_leave_src(struct sock *sk, struct ipv6_mc_socklist *iml, #define IGMP6_UNSOLICITED_IVAL (10*HZ) #define MLD_QRV_DEFAULT2 +#define MLD_QIVAL_DEFAULT (125*HZ) #define MLD_V1_SEEN(idev) (dev_net((idev)->dev)->ipv6.devconf_all->force_mld_version == 1 || \ (idev)->cnf.force_mld_version == 1 || \ @@ -1152,7 +1153,7 @@ int igmp6_event_query(struct sk_buff *skb) /* Translate milliseconds to jiffies */ max_delay = (ntohs(mld->mld_maxdelay)*HZ)/1000; - switchback = (idev->mc_qrv + 1) * max_delay; + switchback = (idev->mc_qrv * MLD_QIVAL_DEFAULT) + max_delay; idev->mc_v1_seen = jiffies + switchback; /* cancel the interface change timer */ -- 1.7.8.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: OMAP: hwmod: revise deassert sequence
Hello OMar, On Mon, 16 Jul 2012, Omar Ramirez Luna wrote: > For a reset sequence to complete cleanly, a module needs its > associated clocks to be enabled, otherwise the timeout check > in prcm code can print a false failure (failed to hardreset) > that occurs because the clocks aren't powered ON and the status > bit checked can't transition without them. > > Signed-off-by: Omar Ramirez Luna Is enabling the clocks sufficient? Or do we also need to enable the IP block, e.g. by calling if (soc_ops.enable_module) soc_ops.enable_module(oh); as we do on OMAP4+ in _enable() ? - 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 1/8] USB:support the new interfaces of Huawei Data Card devices in option driver
From: fangxiaozhi 1. This patch is based on the kernel of 3.5 2. In this patch, we add new micro for matching the series USB devices with vendor ID and interface information. 3. In this patch, we add new declarations into option.c to support the new interfaces of Huawei Data Card devices. And at the same time, remove the redundant declarations from option.c. Signed-off-by: fangxiaozhi --- --- test/linux-3.5/include/linux/usb.h 2012-07-22 04:58:29.0 +0800 +++ linux-3.5/include/linux/usb.h 2012-07-26 14:40:40.0 +0800 @@ -828,6 +828,27 @@ static inline int usb_make_path(struct u .bInterfaceClass = (cl), \ .bInterfaceSubClass = (sc), \ .bInterfaceProtocol = (pr) +/** + * * USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb device with a class of usb interfaces, but independent of product ID + * @vend: the 16 bit USB Vendor ID + * @cl: bInterfaceClass value + * @sc: bInterfaceSubClass value + * @pr: bInterfaceProtocol value + * + * This macro is used to create a struct usb_device_id that matches a + * series of devices with a vendor ID and a specific class of interfaces. + * + * This is especially useful when explicitly matching the specific interface for series of different devices with + * the same vendor. + */ + +#define USB_VENDOR_AND_INTERFACE_INFO(vend, cl, sc, pr) \ + .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \ + | USB_DEVICE_ID_MATCH_VENDOR, \ + .idVendor = (vend), \ + .bInterfaceClass = (cl), \ + .bInterfaceSubClass = (sc), \ + .bInterfaceProtocol = (pr) /* --- */ --- test/linux-3.5/drivers/usb/serial/option.c 2012-07-22 04:58:29.0 +0800 +++ linux-3.5/drivers/usb/serial/option.c 2012-07-26 15:51:30.0 +0800 @@ -80,85 +80,9 @@ static void option_instat_callback(struc #define OPTION_PRODUCT_GTM380_MODEM0x7201 #define HUAWEI_VENDOR_ID 0x12D1 -#define HUAWEI_PRODUCT_E6000x1001 -#define HUAWEI_PRODUCT_E2200x1003 -#define HUAWEI_PRODUCT_E220BIS 0x1004 -#define HUAWEI_PRODUCT_E1401 0x1401 -#define HUAWEI_PRODUCT_E1402 0x1402 -#define HUAWEI_PRODUCT_E1403 0x1403 -#define HUAWEI_PRODUCT_E1404 0x1404 -#define HUAWEI_PRODUCT_E1405 0x1405 -#define HUAWEI_PRODUCT_E1406 0x1406 -#define HUAWEI_PRODUCT_E1407 0x1407 -#define HUAWEI_PRODUCT_E1408 0x1408 -#define HUAWEI_PRODUCT_E1409 0x1409 -#define HUAWEI_PRODUCT_E140A 0x140A -#define HUAWEI_PRODUCT_E140B 0x140B -#define HUAWEI_PRODUCT_E140C 0x140C -#define HUAWEI_PRODUCT_E140D 0x140D -#define HUAWEI_PRODUCT_E140E 0x140E -#define HUAWEI_PRODUCT_E140F 0x140F -#define HUAWEI_PRODUCT_E1410 0x1410 -#define HUAWEI_PRODUCT_E1411 0x1411 -#define HUAWEI_PRODUCT_E1412 0x1412 -#define HUAWEI_PRODUCT_E1413 0x1413 -#define HUAWEI_PRODUCT_E1414 0x1414 -#define HUAWEI_PRODUCT_E1415 0x1415 -#define HUAWEI_PRODUCT_E1416 0x1416 -#define HUAWEI_PRODUCT_E1417 0x1417 -#define HUAWEI_PRODUCT_E1418 0x1418 -#define HUAWEI_PRODUCT_E1419 0x1419 -#define HUAWEI_PRODUCT_E141A 0x141A -#define HUAWEI_PRODUCT_E141B 0x141B -#define HUAWEI_PRODUCT_E141C 0x141C -#define HUAWEI_PRODUCT_E141D 0x141D -#define HUAWEI_PRODUCT_E141E 0x141E -#define HUAWEI_PRODUCT_E141F 0x141F -#define HUAWEI_PRODUCT_E1420 0x1420 -#define HUAWEI_PRODUCT_E1421 0x1421 -#define HUAWEI_PRODUCT_E1422 0x1422 -#define HUAWEI_PRODUCT_E1423 0x1423 -#define HUAWEI_PRODUCT_E1424 0x1424 -#define HUAWEI_PRODUCT_E1425 0x1425 -#define HUAWEI_PRODUCT_E1426 0x1426 -#define HUAWEI_PRODUCT_E1427 0x1427 -#define HUAWEI_PRODUCT_E1428 0x1428 -#define HUAWEI_PRODUCT_E1429 0x1429 -#define HUAWEI_PRODUCT_E142A 0x142A -#define HUAWEI_PRODUCT_E142B 0x142B -#define HUAWEI_PRODUCT_E142C 0x142C -#define HUAWEI_PRODUCT_E142D 0x142D -#define HUAWEI_PRODUCT_E142E 0x142E -#define HUAWEI_PRODUCT_E142F 0x142F -#define HUAWEI_PRODUCT_E1430 0x1430 -#define HUAWEI_PRODUCT_E1431 0x1431 -#define HUAWEI_PRODUCT_E1432 0x1432 -#define HUAWEI_PRODUCT_E1433
Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
On 07/31/2012 07:45 AM, Stephen Warren wrote:
Oh I see. That's a little confusing. Why not just reference the relevant
resources directly in each step; something more like:
gpio@1 {
action = "enable-gpio";
gpio = <&gpio 1 0>;
};
I guess that might make parsing/building a little harder, since you'd
have to detect when you'd already done gpio_request() on a given GPIO
and not repeat it or something like that, but to me this makes the DT a
lot easier to comprehend.
I tried to move towards having the phandles directly in the sequences
themselves - that reminded me why I did not do that in the first place.
Let's say we have a sequence like this (reg property omitted on purpose):
power-on-sequence {
step@0 {
regulator = <&backlight_reg>;
enable;
};
step@1 {
delay = <1>;
};
step@2 {
pwm = <&pwm 2 500>;
enable;
};
step@3 {
gpio = <&gpio 28 0>;
enable;
};
};
The problem is, how do we turn these phandles into the resource of
interest. The type of the resource can be infered by the name of the
property. The hard part is resolving the resource from the phandle - it
seems like the API just does not allow to do this. GPIO has
of_get_named_gpio, but AFAIK there are no equivalent for regulator
consumer and PWM: the only way to use the DT with them is through
get_regulator and get_pwm which work at the device level.
Or is there a way that I overlooked?
Thanks,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
checkpatch.pl: Wrong check SINGLE_STATEMENT_DO_WHILE_MACRO
Hi,
I think your check for SINGLE_STATEMENT_DO_WHILE_MACRO is wrong. Just to give
an example:
#define foobar(x) \
do { \
if (pizza_ready(x)) \
eat_pizza(x); \
} while (0)
if (hungry(y))
foobar(x);
else
barfoo(x);
checkpatch does now complain about something like "WARNING: Single statement
macros should not use a do {} while (0) loop"
But we would have an ambiguous else when the do-while is removed. The code
works as expected with the do-while but the else is "attached" to the wrong
"if" when the do-while is removed.
And yes, this example is made that easy to make it easy to understand. There
are examples were static inline code would not work very well (vararg for
example).
Please fix or remove your check. Otherwise some people will be start to
overeagerly change these macros and break the kernel doing that.
--
Franz Schrober
--
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] Hardware breakpoints: Invoke __perf_event_disable() if interrupts are already disabled
Hi Frederick,
I've added a check to make sure we are targeting the current task. This
applies on top of v3.5. Kindly review.
Thanks,
Naveen
History:
v3: Added check to make sure we only target "current" task.
v2: Use __perf_event_disable() directly
__
From: K.Prasad
While debugging a warning message on PowerPC while using hardware
breakpoints, it was discovered that when perf_event_disable is invoked
through hw_breakpoint_handler function with interrupts disabled, a
subsequent IPI in the code path would trigger a WARN_ON_ONCE message in
smp_call_function_single function.
This patch calls __perf_event_disable() when interrupts are already
disabled, instead of perf_event_disable().
Reported-by: Edjunior Barbosa Machado
Signed-off-by: K.Prasad
[naveen.n@linux.vnet.ibm.com: v3: Check to make sure we target current task]
Signed-off-by: Naveen N. Rao
---
include/linux/perf_event.h|2 ++
kernel/events/core.c |2 +-
kernel/events/hw_breakpoint.c | 11 ++-
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 45db49f..c289ba0 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1292,6 +1292,7 @@ extern int perf_swevent_get_recursion_context(void);
extern void perf_swevent_put_recursion_context(int rctx);
extern void perf_event_enable(struct perf_event *event);
extern void perf_event_disable(struct perf_event *event);
+extern int __perf_event_disable(void *info);
extern void perf_event_task_tick(void);
#else
static inline void
@@ -1330,6 +1331,7 @@ static inline int
perf_swevent_get_recursion_context(void) { return -1; }
static inline void perf_swevent_put_recursion_context(int rctx)
{ }
static inline void perf_event_enable(struct perf_event *event) { }
static inline void perf_event_disable(struct perf_event *event)
{ }
+static inline int __perf_event_disable(void *info) { }
static inline void perf_event_task_tick(void) { }
#endif
diff --git a/kernel/events/core.c b/kernel/events/core.c
index d7d71d6..0ad0fc9 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1253,7 +1253,7 @@ retry:
/*
* Cross CPU call to disable a performance event
*/
-static int __perf_event_disable(void *info)
+int __perf_event_disable(void *info)
{
struct perf_event *event = info;
struct perf_event_context *ctx = event->ctx;
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index bb38c4d..9a7b487 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -453,7 +453,16 @@ int modify_user_hw_breakpoint(struct perf_event *bp,
struct perf_event_attr *att
int old_type = bp->attr.bp_type;
int err = 0;
- perf_event_disable(bp);
+ /*
+* modify_user_hw_breakpoint can be invoked with IRQs disabled and
hence it
+* will not be possible to raise IPIs that invoke __perf_event_disable.
+* So call the function directly after making sure we are targeting the
+* current task.
+*/
+ if (irqs_disabled() && bp->ctx && bp->ctx->task == current)
+ __perf_event_disable(bp);
+ else
+ perf_event_disable(bp);
bp->attr.bp_addr = attr->bp_addr;
bp->attr.bp_type = attr->bp_type;
--
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 v3 1/3] runtime interpreted power sequences
On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
> On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >Oh I see. That's a little confusing. Why not just reference the relevant
> >resources directly in each step; something more like:
> >
> > gpio@1 {
> > action = "enable-gpio";
> > gpio = <&gpio 1 0>;
> > };
> >
> >I guess that might make parsing/building a little harder, since you'd
> >have to detect when you'd already done gpio_request() on a given GPIO
> >and not repeat it or something like that, but to me this makes the DT a
> >lot easier to comprehend.
>
> I tried to move towards having the phandles directly in the
> sequences themselves - that reminded me why I did not do that in the
> first place. Let's say we have a sequence like this (reg property
> omitted on purpose):
>
> power-on-sequence {
> step@0 {
> regulator = <&backlight_reg>;
> enable;
> };
> step@1 {
> delay = <1>;
> };
> step@2 {
> pwm = <&pwm 2 500>;
> enable;
> };
> step@3 {
> gpio = <&gpio 28 0>;
> enable;
> };
> };
>
> The problem is, how do we turn these phandles into the resource of
> interest. The type of the resource can be infered by the name of the
> property. The hard part is resolving the resource from the phandle -
> it seems like the API just does not allow to do this. GPIO has
> of_get_named_gpio, but AFAIK there are no equivalent for regulator
> consumer and PWM: the only way to use the DT with them is through
> get_regulator and get_pwm which work at the device level.
>
> Or is there a way that I overlooked?
No, you are right. Perhaps we should add exported functions that do the
equivalent of of_pwm_request() or the regulator_dev_lookup() and
of_get_regulator() pair.
Thierry
pgpPaKZbKYHag.pgp
Description: PGP signature
Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
On Thu 02 Aug 2012 05:21:57 PM JST, Thierry Reding wrote:
* PGP Signed by an unknown key
On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen Warren wrote:
Oh I see. That's a little confusing. Why not just reference the relevant
resources directly in each step; something more like:
gpio@1 {
action = "enable-gpio";
gpio = <&gpio 1 0>;
};
I guess that might make parsing/building a little harder, since you'd
have to detect when you'd already done gpio_request() on a given GPIO
and not repeat it or something like that, but to me this makes the DT a
lot easier to comprehend.
I tried to move towards having the phandles directly in the
sequences themselves - that reminded me why I did not do that in the
first place. Let's say we have a sequence like this (reg property
omitted on purpose):
power-on-sequence {
step@0 {
regulator = <&backlight_reg>;
enable;
};
step@1 {
delay = <1>;
};
step@2 {
pwm = <&pwm 2 500>;
enable;
};
step@3 {
gpio = <&gpio 28 0>;
enable;
};
};
The problem is, how do we turn these phandles into the resource of
interest. The type of the resource can be infered by the name of the
property. The hard part is resolving the resource from the phandle -
it seems like the API just does not allow to do this. GPIO has
of_get_named_gpio, but AFAIK there are no equivalent for regulator
consumer and PWM: the only way to use the DT with them is through
get_regulator and get_pwm which work at the device level.
Or is there a way that I overlooked?
No, you are right. Perhaps we should add exported functions that do the
equivalent of of_pwm_request() or the regulator_dev_lookup() and
of_get_regulator() pair.
How would that be looked with respect to "good DT practices"? I can
somehow understand the wish to restrain DT access to these functions
that integrate well with current workflows. Aren't we going to be
frowned upon if we make more low-level functions public?
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix NULL-pointer dereference on scsi_run_queue
This patch is to fix a oops from a torn down device. When scsi_run_queue process starved queues, scsi_request_fn can race with scsi_remove_device. In this case, rarely, scsi_request_fn release the last reference and set sdev->request_queue to NULL. It result in NULL-pointer dereference when spin_unlock is tried with (NULL)-> queue_lock. We need to add an extra reference to the device on both sides of the __blk_run_queue to hold reference until scsi_request_fn is finished. [8.042972] Unable to handle kernel NULL pointer dereference at virtual address 0240 [8.051061] pgd = 80004000 [8.053762] [0240] *pgd= [8.057342] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [8.062736] Modules linked in: [8.065793] CPU: 0Not tainted (3.4.2+ #313) [8.070418] PC is at scsi_run_queue+0x19c/0x2b8 [8.074947] LR is at scsi_run_queue+0x198/0x2b8 [8.079476] pc : [<802569a0>]lr : [<8025699c>]psr: 2193 [8.079481] sp : 9f915f10 ip : 0f01 fp : 0001 [8.090953] r10: 9f09d424 r9 : 8055294c r8 : 9f915f20 [8.096172] r7 : 9f914000 r6 : r5 : 9f09e000 r4 : 9f09d400 [8.102694] r3 : r2 : 80504a14 r1 : 6193 r0 : 0043 [8.109219] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [8.116612] Control: 10c53c7d Table: 1f1f804a DAC: 0015 [8.122355] Process kworker/0:1 (pid: 312, stack limit = 0x9f9142f0) [8.128705] Stack: (0x9f915f10 to 0x9f916000) [8.133059] 5f00: 9f1e8000 6113 [8.141236] 5f20: 9f915f20 9f915f20 0001 9f9be1c0 8095f480 80963100 9f914000 [8.149414] 5f40: 80963105 80258304 9f09da70 80034858 9f9fb6c0 0001 9f9be1c0 [8.157591] 5f60: 8095f480 8095f488 9f9be1d0 9f914000 804edf80 804fff08 0009 80037044 [8.165767] 5f80: 804edfc0 804edfc0 804edfc0 804edf80 804edf80 804edf80 0001 9f859ee8 [8.173943] 5fa0: 9f915fcc 9f9be1c0 80036ed4 8003ac64 [8.182119] 5fc0: 9f859ee8 9f9be1c0 9f915fd8 9f915fd8 [8.190296] 5fe0: 9f859ee8 8003abd8 80014c0c 0013 80014c0c [8.198494] [<802569a0>] (scsi_run_queue+0x19c/0x2b8) from [<80034858>] (process_one_work+0x118/0x39c) [8.207812] [<80034858>] (process_one_work+0x118/0x39c) from [<80037044>] (worker_thread+0x170/0x368) [8.217047] [<80037044>] (worker_thread+0x170/0x368) from [<8003ac64>] (kthread+0x8c/0x98) [8.225337] [<8003ac64>] (kthread+0x8c/0x98) from [<80014c0c>] (kernel_thread_exit+0x0/0x8) [8.233692] Code: e59f011c e58dc000 eb05457e e5953004 (e5930240) [8.240026] __scsi_remove_device:962 9f1e8000 [8.240140] ---[ end trace 1ec4a0217c9f24f3 ]--- Signed-off-by: Chanho Min --- drivers/scsi/scsi_lib.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index b583277..1868c35 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -436,9 +436,13 @@ static void scsi_run_queue(struct request_queue *q) } spin_unlock(shost->host_lock); + /* hold a reference on the device so it doesn't release device */ + get_device(&sdev->sdev_gendev); spin_lock(sdev->request_queue->queue_lock); __blk_run_queue(sdev->request_queue); spin_unlock(sdev->request_queue->queue_lock); + /* ok to remove device now */ + put_device(&sdev->sdev_gendev); spin_lock(shost->host_lock); } /* put any unprocessed entries back */ -- 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/
Re: [PATCH v7 2/2] kvm: KVM_EOIFD, an eventfd for EOIs
On Mon, Jul 30, 2012 at 07:12:15PM -0600, Alex Williamson wrote: > > > > > > > kvm_eoifd.fd specifies the eventfd used for > > > > > > > +notification. KVM_EOIFD_FLAG_DEASSIGN is used to de-assign an > > > > > > > eoifd > > > > > > > +once assigned. KVM_EOIFD also requires additional bits set in > > > > > > > +kvm_eoifd.flags to bind to the proper interrupt line. The > > > > > > > +KVM_EOIFD_FLAG_LEVEL_IRQFD indicates that kvm_eoifd.key is > > > > > > > provided > > > > > > > +and is a key from a level triggered interrupt (configured from > > > > > > > +KVM_IRQFD using KVM_IRQFD_FLAG_LEVEL). The EOI notification is > > > > > > > bound > > > > > > > +to the same GSI and irqchip input as the irqfd. Both > > > > > > > kvm_eoifd.key > > > > > > > +and KVM_EOIFD_FLAG_LEVEL_IRQFD must be specified on assignment > > > > > > > and > > > > > > > +de-assignment of KVM_EOIFD. A level irqfd may only be bound to a > > > > > > > +single eoifd. KVM_CAP_EOIFD_LEVEL_IRQFD indicates support of > > > > > > > +KVM_EOIFD_FLAG_LEVEL_IRQFD. > > > > > > > > > > > > > > > > > > > Hmm returning the key means we'll need to keep refcounting for > > > > > > source > > > > > > IDs around forever. I liked passing the fd better: make > > > > > > implementation > > > > > > match interface and not the other way around. > > > > > > > > > > False, a source ID has a finite lifecycle. The fd approach was > > > > > broken. > > > > > Holding the irqfd context imposed too many dependencies between eoifd > > > > > and irqfd necessitating things like one interface disabling another. > > > > > I > > > > > thoroughly disagree with that approach. > > > > > > > > You keep saying this but it is still true: once irqfd > > > > is closed eoifd does not get any more interrupts. > > > > > > How does that matter? > > > > Well if it does not get events it is disabled. > > so you have one ifc disabling another, anyway. > > And a level irqfd without an eoifd can never be de-asserted. Either we > make modular components, assemble them to do useful work, and > disassemble them independently so they can be used by future interfaces > or we bundle eoifd as just an option of irqfd. Which is it gonna be? I'm fine just making it an option. I think Gleb wanted a separate EOIFD to handle timedrift but it later seemed that eventfd is not suitable for that? -- MST -- 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 v3 1/3] runtime interpreted power sequences
On Thu, Aug 02, 2012 at 05:27:44PM +0900, Alex Courbot wrote:
> On Thu 02 Aug 2012 05:21:57 PM JST, Thierry Reding wrote:
> >* PGP Signed by an unknown key
> >
> >On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
> >>On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >>>Oh I see. That's a little confusing. Why not just reference the relevant
> >>>resources directly in each step; something more like:
> >>>
> >>> gpio@1 {
> >>> action = "enable-gpio";
> >>> gpio = <&gpio 1 0>;
> >>> };
> >>>
> >>>I guess that might make parsing/building a little harder, since you'd
> >>>have to detect when you'd already done gpio_request() on a given GPIO
> >>>and not repeat it or something like that, but to me this makes the DT a
> >>>lot easier to comprehend.
> >>
> >>I tried to move towards having the phandles directly in the
> >>sequences themselves - that reminded me why I did not do that in the
> >>first place. Let's say we have a sequence like this (reg property
> >>omitted on purpose):
> >>
> >>power-on-sequence {
> >>step@0 {
> >>regulator = <&backlight_reg>;
> >>enable;
> >>};
> >>step@1 {
> >>delay = <1>;
> >>};
> >>step@2 {
> >>pwm = <&pwm 2 500>;
> >>enable;
> >>};
> >>step@3 {
> >>gpio = <&gpio 28 0>;
> >>enable;
> >>};
> >>};
> >>
> >>The problem is, how do we turn these phandles into the resource of
> >>interest. The type of the resource can be infered by the name of the
> >>property. The hard part is resolving the resource from the phandle -
> >>it seems like the API just does not allow to do this. GPIO has
> >>of_get_named_gpio, but AFAIK there are no equivalent for regulator
> >>consumer and PWM: the only way to use the DT with them is through
> >>get_regulator and get_pwm which work at the device level.
> >>
> >>Or is there a way that I overlooked?
> >
> >No, you are right. Perhaps we should add exported functions that do the
> >equivalent of of_pwm_request() or the regulator_dev_lookup() and
> >of_get_regulator() pair.
>
> How would that be looked with respect to "good DT practices"? I can
> somehow understand the wish to restrain DT access to these functions
> that integrate well with current workflows. Aren't we going to be
> frowned upon if we make more low-level functions public?
Yes, I think that's exactly what will happen.
Thierry
pgp46pSbKyCGr.pgp
Description: PGP signature
Re: [PATCH v2] parisc: fix personality flag check in copy_thread()
On Thu, 2012-08-02 at 09:12 +0200, Jiri Kosina wrote:
> Directly comparing task_struct->personality against PER_* is not fully
> correct, as it doesn't take flags potentially stored in top three bytes
> into account.
>
> Analogically, directly forcefully setting personality to PER_LINUX32 or
> PER_LINUX discards any flags stored in the top three bytes.
>
> Signed-off-by: Jiri Kosina
> ---
>
> changed since v1: fix the bit ops to reflect the fact that PER_LINUX is
> actually 0
Tell me what you're trying to achieve (or what problem you're trying to
solve), because personality is notoriously tricky.
Usually personality = is desired because if you look at the
enum for personality, it does set the top three bits in quite a few
cases. We actually don't need any of the top 3 byte features ... but I
think making sure they're zeroed out is the correct thing to do.
In particular, if we ever get around to a 64 bit user space, our
personality will be PER_LINUX_FDPIC and then we will be setting the top
three bytes.
James
> arch/parisc/kernel/process.c|2 +-
> arch/parisc/kernel/sys_parisc.c |8
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
> index d4b94b3..2c05a92 100644
> --- a/arch/parisc/kernel/process.c
> +++ b/arch/parisc/kernel/process.c
> @@ -309,7 +309,7 @@ copy_thread(unsigned long clone_flags, unsigned long usp,
> cregs->ksp = (unsigned long)stack
> + (pregs->gr[21] & (THREAD_SIZE - 1));
> cregs->gr[30] = usp;
> - if (p->personality == PER_HPUX) {
> + if (personality(p->personality) == PER_HPUX) {
> #ifdef CONFIG_HPUX
> cregs->kpc = (unsigned long) &hpux_child_return;
> #else
> diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c
> index c9b9322..7f9658e 100644
> --- a/arch/parisc/kernel/sys_parisc.c
> +++ b/arch/parisc/kernel/sys_parisc.c
> @@ -225,12 +225,12 @@ long parisc_personality(unsigned long personality)
> long err;
>
> if (personality(current->personality) == PER_LINUX32
> - && personality == PER_LINUX)
> - personality = PER_LINUX32;
> + && personality(personality) == PER_LINUX)
> + personality |= PER_LINUX32;
>
> err = sys_personality(personality);
> - if (err == PER_LINUX32)
> - err = PER_LINUX;
> + if (personality(err) == PER_LINUX32)
> + err &= ~PER_LINUX32;
>
> return err;
> }
>
--
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 07/13] perf: Add attribute to filter out callchains
On Thu, Aug 02, 2012 at 11:38:26AM +0400, Andrew Vagin wrote:
> On Wed, Aug 01, 2012 at 02:10:59PM +0400, Jiri Olsa wrote:
> > From: Frederic Weisbecker
> >
> > Introducing following bits to the the perf_event_attr struct:
> > - exclude_callchain_kernel to filter out kernel callchain
> > from the sample dump
> > - exclude_callchain_user to filter out user callchain
> > from the sample dump
> >
> > We need to be able to disable standard user callchain dump
> > when we use the dwarf cfi callchain mode, because frame
> > pointer based user callchains are useless in this mode.
> >
> > Implementing also exclude_callchain_kernel to have complete
> > set of options.
> >
> > Signed-off-by: Frederic Weisbecker
> > [ Added kernel callchains filtering ]
> > Signed-off-by: Jiri Olsa
> > CC: Andrew Vagin
>
> Acked-by: Andrew Vagin
>
>
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index c4582bb..0902d4a 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -4130,8 +4130,12 @@ void perf_prepare_sample(struct perf_event_header
> > *header,
> >
> > if (sample_type & PERF_SAMPLE_CALLCHAIN) {
> > int size = 1;
> > + int kernel = !event->attr.exclude_callchain_kernel;
> > + int user = !event->attr.exclude_callchain_user;
> >
> > - data->callchain = perf_callchain(event, regs);
> > + if (kernel || user)
> > + data->callchain = perf_callchain(event, regs,
> > +kernel, user);
> I am not sure, that we need two arguments kernel and user here,
> we can get them from event inside perf_callchain...
right.. I'll send an update with other fixies
thanks
jirka
--
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/
[NEW DRIVER V1 7/7] DA9058 REGULATOR driver
This is the REGULATOR component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the core DA9058 MFD driver.
Signed-off-by: Tony Olech (at Home)
---
drivers/regulator/Kconfig| 11 +
drivers/regulator/Makefile |1 +
drivers/regulator/da9058-regulator.c | 336 ++
3 files changed, 348 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/da9058-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c86b886..1fc04f9 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -64,6 +64,17 @@ config REGULATOR_USERSPACE_CONSUMER
If unsure, say no.
+config REGULATOR_DA9058
+ tristate "Support regulators on Dialog Semiconductor DA9058 PMIC"
+ depends on MFD_DA9058
+ help
+ Say y here to support the BUCKs and LDOs regulators found on
+ Dialog Semiconductor DA9058 PMIC.
+
+ This driver can also be built as a module. If so, the module
+ will be called da9058-regulator.
+
+
config REGULATOR_GPIO
tristate "GPIO regulator support"
depends on GENERIC_GPIO
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 977fd46..f4d0bff 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_REGULATOR_DBX500_PRCMU) += dbx500-prcmu.o
obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
obj-$(CONFIG_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
+obj-$(CONFIG_REGULATOR_DA9058) += da9058-regulator.o
obj-$(CONFIG_REGULATOR_LP3971) += lp3971.o
obj-$(CONFIG_REGULATOR_LP3972) += lp3972.o
obj-$(CONFIG_REGULATOR_MAX1586) += max1586.o
diff --git a/drivers/regulator/da9058-regulator.c
b/drivers/regulator/da9058-regulator.c
new file mode 100644
index 000..842b793
--- /dev/null
+++ b/drivers/regulator/da9058-regulator.c
@@ -0,0 +1,336 @@
+/*
+ * Copyright (C) 2012 Dialog Semiconductor Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct da9058_regulator {
+ struct da9058 *da9058;
+ int control_voltage_step;
+ int control_register;
+ int control_enable_mask;
+ int ramp_register;
+ int ramp_enable_mask;
+ int fixed_voltage;
+ struct platform_device *pdev;
+ struct regulator_dev *reg_dev;
+ struct regulator_desc desc;
+ struct regulator_init_data init;
+};
+
+static unsigned int da9058_regulator_val_to_mvolts(unsigned int val,
+ struct regulator_dev *rdev)
+{
+ struct da9058_regulator *regulator = rdev_get_drvdata(rdev);
+ struct regulation_constraints *constraints = rdev->constraints;
+ int min_mV = constraints->min_uV / 1000;
+
+ return (val * regulator->control_voltage_step) + min_mV;
+}
+
+static unsigned int da9058_regulator_mvolts_to_val(unsigned int mV,
+ struct regulator_dev *rdev)
+{
+ struct da9058_regulator *regulator = rdev_get_drvdata(rdev);
+ struct regulation_constraints *constraints = rdev->constraints;
+ int min_mV = constraints->min_uV / 1000;
+
+ return (mV - min_mV) / regulator->control_voltage_step;
+}
+
+static int da9058_regulator_is_enabled(struct regulator_dev *rdev)
+{
+ struct da9058_regulator *regulator = rdev_get_drvdata(rdev);
+ struct da9058 *da9058 = regulator->da9058;
+ int ret;
+ u8 val;
+
+ if (!regulator->control_register)
+ return -EINVAL;
+
+ ret = da9058_reg_read(da9058, regulator->control_register, &val);
+ if (ret)
+ return ret;
+
+ if (regulator->control_enable_mask&val)
+ return true;
+ else
+ return false;
+}
+
+static int da9058_regulator_set_voltage(struct regulator_dev *rdev,
+ int min_uV, int max_uV,
+ unsigned *selector)
+{
+ struct da9058_regulator *regulator = rdev_get_drvdata(rdev);
+ struct da9058 *da9058 = regulator->da9058;
+ struct regulation_constraints *constraints = rdev->constraints;
+ int mV_val, min_mV, max_mV, tmp, ret;
+ int tmp_max_mV, tmp_min_mV;
+ u8 val;
+
+ if (regulator->control_voltage_step == 0)
+ return -EINVAL;
+
+ max_mV = max_uV / 1000;
+ min_mV = min_uV / 1000;
+ tmp_max_mV = constraints->max_uV / 1000;
+ tmp_min_mV = constraints->min_uV / 1000;
+
+ if (0 == max_mV)
+
[NEW DRIVER V1 4/7] DA9058 RTC driver
This is the RTC component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the core DA9058 MFD driver.
Signed-off-by: Tony Olech (at Home)
---
drivers/rtc/Kconfig | 21 ++-
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-da9058.c | 456 ++
3 files changed, 472 insertions(+), 6 deletions(-)
create mode 100644 drivers/rtc/rtc-da9058.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 08cbdb9..1e0e47b 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -120,11 +120,6 @@ config RTC_DRV_TEST
This driver can also be built as a module. If so, the module
will be called rtc-test.
-comment "I2C RTC drivers"
- depends on I2C
-
-if I2C
-
config RTC_DRV_88PM860X
tristate "Marvell 88PM860x"
depends on RTC_CLASS && I2C && MFD_88PM860X
@@ -135,6 +130,21 @@ config RTC_DRV_88PM860X
This driver can also be built as a module. If so, the module
will be called rtc-88pm860x.
+comment "I2C RTC drivers"
+ depends on I2C
+
+if I2C
+
+config RTC_DRV_DA9058
+ tristate "Dialog DA9058"
+ depends on MFD_DA9058
+ help
+ If you say yes here you will get support for the
+ RTC of the Dialog DA9058 PMIC.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-da9058.
+
config RTC_DRV_DS1307
tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025"
help
@@ -163,7 +173,6 @@ config RTC_DRV_DS1374
This driver can also be built as a module. If so, the module
will be called rtc-ds1374.
-
config RTC_DRV_DS1672
tristate "Dallas/Maxim DS1672"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 2973921..b772f05 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_RTC_DRV_CMOS)+= rtc-cmos.o
obj-$(CONFIG_RTC_DRV_COH901331)+= rtc-coh901331.o
obj-$(CONFIG_RTC_DRV_DA9052) += rtc-da9052.o
obj-$(CONFIG_RTC_DRV_DAVINCI) += rtc-davinci.o
+obj-$(CONFIG_RTC_DRV_DA9058) += rtc-da9058.o
obj-$(CONFIG_RTC_DRV_DM355EVM) += rtc-dm355evm.o
obj-$(CONFIG_RTC_DRV_VRTC) += rtc-mrst.o
obj-$(CONFIG_RTC_DRV_DS1216) += rtc-ds1216.o
diff --git a/drivers/rtc/rtc-da9058.c b/drivers/rtc/rtc-da9058.c
new file mode 100644
index 000..30745e5
--- /dev/null
+++ b/drivers/rtc/rtc-da9058.c
@@ -0,0 +1,456 @@
+/*
+ * Copyright (C) 2012 Dialog Semiconductor Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Limit values
+ */
+#define DA9058_RTC_SECONDS_LIMIT 59
+#define DA9058_RTC_MINUTES_LIMIT 59
+#define DA9058_RTC_HOURS_LIMIT 23
+#define DA9058_RTC_DAYS_LIMIT 31
+#define DA9058_RTC_MONTHS_LIMIT12
+#define DA9058_RTC_YEARS_LIMIT 63
+
+struct da9058_rtc {
+ struct da9058 *da9058;
+ struct platform_device *pdev;
+ struct rtc_device *rtc_dev;
+ int alarm_irq;
+ int tick_irq;
+ int alarm_enabled; /* used over suspend/resume */
+};
+
+static int da9058_rtc_check_param(struct rtc_time *rtc_tm)
+{
+ if ((rtc_tm->tm_sec > DA9058_RTC_SECONDS_LIMIT) || (rtc_tm->tm_sec < 0))
+ return -EIO;
+
+ if ((rtc_tm->tm_min > DA9058_RTC_MINUTES_LIMIT) || (rtc_tm->tm_min < 0))
+ return -EIO;
+
+ if ((rtc_tm->tm_hour > DA9058_RTC_HOURS_LIMIT) || (rtc_tm->tm_hour < 0))
+ return -EIO;
+
+ if (rtc_tm->tm_mday == 0)
+ return -EIO;
+
+ if ((rtc_tm->tm_mon > DA9058_RTC_MONTHS_LIMIT) || (rtc_tm->tm_mon <= 0))
+ return -EIO;
+
+ if ((rtc_tm->tm_year > DA9058_RTC_YEARS_LIMIT) || (rtc_tm->tm_year < 0))
+ return -EIO;
+
+ return 0;
+}
+
+static int da9058_rtc_readtime(struct device *dev, struct rtc_time *tm)
+{
+ struct da9058_rtc *rtc = dev_get_drvdata(dev);
+ struct da9058 *da9058 = rtc->da9058;
+ u8 rtc_time[6];
+ int ret;
+
+ ret = da9058_bulk_read(da9058, DA9058_COUNTS_REG, rtc_time, 6);
+ if (ret)
+ return ret;
+
+ tm->tm_sec = rtc_time[0] & DA9058_RTC_SECS_MASK;
+
+ tm->tm_min = rtc_time[1] & DA9058_RTC_MINS_MASK;
+
+ tm->tm_hour = rtc_time[2] & DA9058_RTC_HRS_MASK;
+
+ tm->tm_mday = (rtc_time[3] & DA9058_RTC_DAY_MASK);
+
+ tm->tm_mon = (rtc_time[4] & DA9058_RTC_MTH_MASK);
+
+ tm->tm_year = (rtc_time[5] & DA9058_RTC_YRS_MASK);
+
+ ret = da9058_rtc_check_param(t
[NEW DRIVER V1 2/7] DA9058 ONKEY driver
This is the ONKEY component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the core DA9058 MFD driver.
Signed-off-by: Tony Olech (at Home)
---
drivers/input/misc/Kconfig| 10 ++
drivers/input/misc/Makefile |1 +
drivers/input/misc/da9058_onkey.c | 170 +
3 files changed, 181 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/da9058_onkey.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 7faf4a7..697b703 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -73,6 +73,16 @@ config INPUT_BMA150
To compile this driver as a module, choose M here: the
module will be called bma150.
+config INPUT_DA9058_ONKEY
+ tristate "DA9058 ONKEY support"
+ depends on MFD_DA9058
+ help
+ Support the ONKEY of DA9058 PMICs as an input device
+ reporting power button status.
+
+ To compile this driver as a module, choose M here: the module
+ will be called da9058_onkey.
+
config INPUT_PCSPKR
tristate "PC Speaker support"
depends on PCSPKR_PLATFORM
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index f55cdf4..048d50e 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_INPUT_PCF8574) += pcf8574_keypad.o
obj-$(CONFIG_INPUT_PCSPKR) += pcspkr.o
obj-$(CONFIG_INPUT_PM8XXX_VIBRATOR)+= pm8xxx-vibrator.o
obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY)+= pmic8xxx-pwrkey.o
+obj-$(CONFIG_INPUT_DA9058_ONKEY) += da9058_onkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
diff --git a/drivers/input/misc/da9058_onkey.c
b/drivers/input/misc/da9058_onkey.c
new file mode 100644
index 000..94c14f9
--- /dev/null
+++ b/drivers/input/misc/da9058_onkey.c
@@ -0,0 +1,170 @@
+/*
+ * Copyright (C) 2012 Dialog Semiconductor Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+struct da9058_onkey {
+ struct da9058 *da9058;
+ struct platform_device *pdev;
+ struct input_dev *input;
+ struct delayed_work work;
+ int irq;
+};
+
+static void da9058_onkey_poll(struct work_struct *work)
+{
+ struct da9058_onkey *onkey = container_of(work, struct da9058_onkey,
+ work.work);
+ struct da9058 *da9058 = onkey->da9058;
+ int poll, ret;
+ u8 sa;
+
+ ret = da9058_reg_read(da9058, DA9058_STATUSA_REG, &sa);
+ if (ret) {
+ dev_dbg(&onkey->pdev->dev, "Failed to read ONKEY: %d\n", ret);
+ poll = 1;
+ } else if (sa & DA9058_STATUSA_NONKEY) {
+ poll = 0;
+ } else {
+ poll = 1;
+ }
+
+ input_report_key(onkey->input, KEY_POWER, poll);
+ input_sync(onkey->input);
+
+ if (poll)
+ schedule_delayed_work(&onkey->work, msecs_to_jiffies(50));
+}
+
+static irqreturn_t da9058_onkey_event_handler(int irq, void *data)
+{
+ struct da9058_onkey *onkey = data;
+
+ schedule_delayed_work(&onkey->work, 0);
+
+ return IRQ_HANDLED;
+}
+
+static int __devinit da9058_onkey_probe(struct platform_device *pdev)
+{
+ struct da9058 *da9058 = dev_get_drvdata(pdev->dev.parent);
+ const struct mfd_cell *cell = mfd_get_cell(pdev);
+ struct da9058_onkey_pdata *onkey_pdata;
+ struct da9058_onkey *onkey;
+ int ret;
+
+ if (cell == NULL) {
+ ret = -ENODEV;
+ goto exit;
+ }
+
+ onkey_pdata = cell->platform_data;
+
+ if (onkey_pdata == NULL) {
+ ret = -EINVAL;
+ goto exit;
+ }
+
+ dev_info(&pdev->dev, "Starting ONKEY\n");
+
+ onkey = devm_kzalloc(&pdev->dev, sizeof(struct da9058_onkey),
+ GFP_KERNEL);
+ if (!onkey) {
+ ret = -ENOMEM;
+ goto exit;
+ }
+
+ platform_set_drvdata(pdev, onkey);
+
+ onkey->da9058 = da9058;
+ onkey->pdev = pdev;
+
+ INIT_DELAYED_WORK(&onkey->work, da9058_onkey_poll);
+
+ onkey->input = input_allocate_device();
+ if (!onkey->input) {
+ dev_err(&pdev->dev, "failed to allocate data device\n");
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ onkey->input->evbit[0] = BIT_MASK(EV_KEY);
+ onkey->input->keybit[BIT_WORD
[NEW DRIVER V1 5/7] DA9058 GPIO driver
This is the GPIO component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the core DA9058 MFD driver.
Signed-off-by: Tony Olech (at Home)
---
drivers/gpio/Kconfig | 12 ++
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-da9058.c | 375
3 files changed, 388 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/gpio-da9058.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 542f0c0..63b574a 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -86,6 +86,18 @@ config GPIO_DA9052
help
Say yes here to enable the GPIO driver for the DA9052 chip.
+config GPIO_DA9058
+ tristate "Dialog DA9058 GPIO"
+ depends on MFD_DA9058
+ help
+ Say yes here to enable the GPIO driver for the DA9058 chip.
+
+ The Dialog DA9058 PMIC chip has 2 GPIO pins that can be
+ be controller by this driver.
+
+ If driver is built as a module it will be called da9058-gpio.
+
+
config GPIO_MAX730X
tristate
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 0f55662..209224a 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_GPIO_ADP5520)+= gpio-adp5520.o
obj-$(CONFIG_GPIO_ADP5588) += gpio-adp5588.o
obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
obj-$(CONFIG_GPIO_CS5535) += gpio-cs5535.o
+obj-$(CONFIG_GPIO_DA9058) += gpio-da9058.o
obj-$(CONFIG_GPIO_DA9052) += gpio-da9052.o
obj-$(CONFIG_ARCH_DAVINCI) += gpio-davinci.o
obj-$(CONFIG_GPIO_EM) += gpio-em.o
diff --git a/drivers/gpio/gpio-da9058.c b/drivers/gpio/gpio-da9058.c
new file mode 100644
index 000..c0b34c5
--- /dev/null
+++ b/drivers/gpio/gpio-da9058.c
@@ -0,0 +1,375 @@
+/*
+ * Copyright (C) 2012 Dialog Semiconductor Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * There are only 2 available GPIO pins on the DA9058 PMIC
+ *
+ * Thus this driver distinguishes them by the offset number
+ * being zero or non-zero for simplicity
+ */
+
+struct da9058_gpio {
+ struct da9058 *da9058;
+ struct platform_device *pdev;
+ struct gpio_chip gp;
+ struct mutex lock;
+ u8 inp_config;
+ u8 out_config;
+};
+
+static struct da9058_gpio *gpio_chip_to_da9058_gpio(struct gpio_chip *chip)
+{
+ return container_of(chip, struct da9058_gpio, gp);
+}
+
+static int da9058_gpio_get(struct gpio_chip *gc, unsigned offset)
+{
+ struct da9058_gpio *gpio = gpio_chip_to_da9058_gpio(gc);
+ struct da9058 *da9058 = gpio->da9058;
+ u8 gpio_level;
+ int ret;
+
+ if (offset > 1)
+ return -EINVAL;
+
+ mutex_lock(&gpio->lock);
+ ret = da9058_reg_read(da9058, DA9058_STATUSC_REG, &gpio_level);
+ mutex_unlock(&gpio->lock);
+ if (ret < 0)
+ return ret;
+
+ if (offset) {
+ if (gpio_level & DA9058_STATUSC_GPI1)
+ return 1;
+ else
+ return 0;
+ } else {
+ if (gpio_level & DA9058_STATUSC_GPI0)
+ return 1;
+ else
+ return 0;
+ }
+}
+
+static void da9058_gpio_set(struct gpio_chip *gc, unsigned offset, int value)
+{
+ struct da9058_gpio *gpio = gpio_chip_to_da9058_gpio(gc);
+ struct da9058 *da9058 = gpio->da9058;
+ u8 gpio_cntrl;
+ int ret;
+
+ if (offset > 1) {
+ dev_err(da9058->dev,
+ "Failed to set GPIO%d output=%d because illegal GPIO\n",
+ offset, value);
+ return;
+ }
+
+ mutex_lock(&gpio->lock);
+
+ ret = da9058_reg_read(da9058, DA9058_GPIO0001_REG, &gpio_cntrl);
+ if (ret)
+ goto exit;
+
+ if (offset) {
+ u8 value_bits = value ? 0x80 : 0x00;
+
+ gpio->out_config &= ~0x80;
+ gpio->out_config |= value_bits;
+
+ if (!(gpio_cntrl & 0x20))
+ goto exit;
+
+ gpio_cntrl &= ~0xF0;
+ gpio_cntrl |= 0xF0 & gpio->out_config;
+
+ ret = da9058_reg_write(da9058, DA9058_GPIO0001_REG, gpio_cntrl);
+ } else {
+ u8 value_bits = value ? 0x08 : 0x00;
+
+ gpio->out_config &= ~0x08;
+ gpio->out_config |= value_bits;
+
+ if (!(gpio_cntrl & 0x02))
+ goto exit;
+
+ gpio
[NEW DRIVER V1 1/7] DA9058 MFD core and ADC driver
This is the MFD core driver for the Dialog DA9058 PMIC.
This driver, via MFD CELLs, causes all the component drivers to be
loaded, if it is a module, and initialized via their probe methods.
It also provides access to the ADC functions on the PMIC.
All the other component drivers depend on this one.
Signed-off-by: Tony Olech (at Home)
---
drivers/mfd/Kconfig | 18 ++
drivers/mfd/Makefile |3 +
drivers/mfd/da9058-core.c| 320 ++
drivers/mfd/da9058-i2c.c | 102 +++
drivers/mfd/da9058-irq.c | 66 +
include/linux/mfd/da9058/bat.h | 33 +++
include/linux/mfd/da9058/codec.h | 21 ++
include/linux/mfd/da9058/core.h | 69 +
include/linux/mfd/da9058/gpio.h | 19 ++
include/linux/mfd/da9058/hwmon.h | 20 ++
include/linux/mfd/da9058/irq.h | 45
include/linux/mfd/da9058/onkey.h | 17 ++
include/linux/mfd/da9058/pdata.h | 28 ++
include/linux/mfd/da9058/registers.h | 480 ++
include/linux/mfd/da9058/regulator.h | 33 +++
include/linux/mfd/da9058/rtc.h | 17 ++
16 files changed, 1291 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/da9058-core.c
create mode 100644 drivers/mfd/da9058-i2c.c
create mode 100644 drivers/mfd/da9058-irq.c
create mode 100644 include/linux/mfd/da9058/bat.h
create mode 100644 include/linux/mfd/da9058/codec.h
create mode 100644 include/linux/mfd/da9058/core.h
create mode 100644 include/linux/mfd/da9058/gpio.h
create mode 100644 include/linux/mfd/da9058/hwmon.h
create mode 100644 include/linux/mfd/da9058/irq.h
create mode 100644 include/linux/mfd/da9058/onkey.h
create mode 100644 include/linux/mfd/da9058/pdata.h
create mode 100644 include/linux/mfd/da9058/registers.h
create mode 100644 include/linux/mfd/da9058/regulator.h
create mode 100644 include/linux/mfd/da9058/rtc.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 92144ed..3fa1a75 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -3,6 +3,7 @@
#
if HAS_IOMEM
+
menu "Multifunction device drivers"
config MFD_CORE
@@ -20,6 +21,23 @@ config MFD_88PM860X
select individual components like voltage regulators, RTC and
battery-charger under the corresponding menus.
+config MFD_DA9058
+ tristate "Dialog Semiconductor DA9058 PMIC Support"
+ depends on I2C
+ select REGMAP_I2C
+ select REGMAP_IRQ
+ select MFD_CORE
+ help
+ Say yes here for support of Dialog Semiconductor DA9058. This is
+ a Power Management IC. This driver provides common support for
+ accessing the device as well as the I2C interface to the chip itself.
+ Additional drivers must be enabled in order to use the functionality
+ of the device.
+
+ This driver can be built as a module, but since the functionality
+ of the device includes regulators it probably should be built into
+ the kernel. If built as a module it will be called "da9058"
+
config MFD_SM501
tristate "Support for Silicon Motion SM501"
---help---
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 75f6ed6..1853278 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -86,6 +86,9 @@ obj-$(CONFIG_MFD_MAX8998) += max8998.o max8998-irq.o
pcf50633-objs := pcf50633-core.o pcf50633-irq.o
obj-$(CONFIG_MFD_PCF50633) += pcf50633.o
+da9058-objs= da9058-irq.o da9058-i2c.o da9058-core.o
da9058-info.o
+obj-$(CONFIG_MFD_DA9058) += da9058.o
+
obj-$(CONFIG_PCF50633_ADC) += pcf50633-adc.o
obj-$(CONFIG_PCF50633_GPIO)+= pcf50633-gpio.o
obj-$(CONFIG_ABX500_CORE) += abx500-core.o
diff --git a/drivers/mfd/da9058-core.c b/drivers/mfd/da9058-core.c
new file mode 100644
index 000..370dcec
--- /dev/null
+++ b/drivers/mfd/da9058-core.c
@@ -0,0 +1,320 @@
+/*
+ * Copyright (C) 2012 Dialog Semiconductor Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+static int da9058_register_read(struct da9058 *da9058, u8 const reg, u8 *val)
+{
+ unsigned int ival;
+ int ret = regmap_read(da9058->regmap, reg, &ival);
+
+ *val = ival;
+ return ret;
+}
+
+static int da9058_register_write(struct da9058 *da9058, u8 const reg, u8 val)
+{
+ return regmap_write(da9058->regmap, reg, val);
+}
+
+static int da9058_register_raw_read(struct da9058 *da9058, u8 const reg,
+
[NEW DRIVER V1 6/7] DA9058 HWMON driver
This is the HWMON component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the core DA9058 MFD driver.
Signed-off-by: Tony Olech (at Home)
---
drivers/hwmon/Kconfig| 10 +
drivers/hwmon/Makefile |1 +
drivers/hwmon/da9058-hwmon.c | 389 ++
3 files changed, 400 insertions(+), 0 deletions(-)
create mode 100644 drivers/hwmon/da9058-hwmon.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 6f1d167..0986f43 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -294,6 +294,16 @@ config SENSORS_ATXP1
This driver can also be built as a module. If so, the module
will be called atxp1.
+config SENSORS_DA9058
+ tristate "Dialog Semiconductor DA9058 ADC"
+ depends on I2C
+ help
+ If you say yes here you get support for ADC on the Dialog
+ Semiconductor DA9058 PMIC.
+
+ This driver can also be built as a module. If so, the module
+ will be called da9058-hwmon.
+
config SENSORS_DS620
tristate "Dallas Semiconductor DS620"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index e1eeac1..be99572 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o
obj-$(CONFIG_SENSORS_ATXP1)+= atxp1.o
obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o
obj-$(CONFIG_SENSORS_DME1737) += dme1737.o
+obj-$(CONFIG_SENSORS_DA9058) += da9058-hwmon.o
obj-$(CONFIG_SENSORS_DS620)+= ds620.o
obj-$(CONFIG_SENSORS_DS1621) += ds1621.o
obj-$(CONFIG_SENSORS_EMC1403) += emc1403.o
diff --git a/drivers/hwmon/da9058-hwmon.c b/drivers/hwmon/da9058-hwmon.c
new file mode 100644
index 000..bc3b89c
--- /dev/null
+++ b/drivers/hwmon/da9058-hwmon.c
@@ -0,0 +1,389 @@
+/*
+ * Copyright (C) 2012 Dialog Semiconductor Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct da9058_hwmon {
+ struct da9058 *da9058;
+ struct platform_device *pdev;
+
+ struct device *class_device;
+ struct mutexhwmon_lock;
+ int use_automatic_adc;
+ int temp_adc_resistance;
+ int vf_adc_resistance;
+};
+
+static ssize_t da9058_read_tbat(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct da9058_hwmon *hwmon = dev_get_drvdata(dev);
+ int voltage; /* x000 .. xFFF = 0 .. 2500 mV */
+ int ret;
+
+ ret = da9058_adc_read(hwmon->da9058, DA9058_ADCMAN_MUXSEL_TEMP,
+ hwmon->use_automatic_adc, &voltage);
+ if (ret)
+ return ret;
+
+ return sprintf(buf, "%d\n", voltage * 2500 / 0xFFF);
+}
+
+static ssize_t da9058_read_vbat(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct da9058_hwmon *hwmon = dev_get_drvdata(dev);
+ int voltage; /* x000 .. xFFF = 2500 .. 4500 mV */
+ int ret;
+
+ ret = da9058_adc_read(hwmon->da9058, DA9058_ADCMAN_MUXSEL_VBAT,
+ hwmon->use_automatic_adc, &voltage);
+ if (ret)
+ return ret;
+
+ return sprintf(buf, "%d\n", 2500 + voltage * 2000 / 0xFFF);
+}
+
+static ssize_t da9058_read_misc_channel(struct device *dev,
+ struct device_attribute *devattr,
+ char *buf)
+{
+ struct da9058_hwmon *hwmon = dev_get_drvdata(dev);
+ int channel = to_sensor_dev_attr(devattr)->index;
+ int voltage; /* xFFF .. x800 = 0 .. 2500 mV */
+ int ret;
+
+ ret = da9058_adc_read(hwmon->da9058, channel,
+ hwmon->use_automatic_adc, &voltage);
+ if (ret)
+ return ret;
+
+ return sprintf(buf, "%d\n", (0xFFF - voltage) * 2500 / 0x7FF);
+}
+
+/*
+ * The algorithm for converting the value is
+ * Degrees celsius = 1.708 * (TJUNC_RES - T_OFFSET) - 108.8
+ * T_OFFSET is a trim value used to improve accuracy of the result
+ */
+static ssize_t da9058_read_tjunc(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct da9058_hwmon *hwmon = dev_get_drvdata(dev);
+ int tjunc;
+ u8 toffset;
+ int ret;
+
+ ret = da9058_reg_read(hwmon->da9058, DA9058_TOFFSET_REG, &toffset);
+ if (ret < 0)
+ return ret;
+
+ ret = da9058_adc_read(hwmon->da9058, DA9058_ADCMAN_MUXSEL_TJUNC,
+
[NEW DRIVER V1 3/7] DA9058 POWER driver
This is the POWER component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the core DA9058 MFD driver.
Signed-off-by: Tony Olech (at Home)
---
drivers/power/Kconfig| 10 +
drivers/power/Makefile |1 +
drivers/power/da9058_power.c | 403 ++
3 files changed, 414 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/da9058_power.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index e3a3b49..e0b4d34 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -8,6 +8,16 @@ menuconfig POWER_SUPPLY
if POWER_SUPPLY
+config BATTERY_DA9058
+ tristate "DA9058 battery charger support"
+ depends on MFD_DA9058
+ help
+ Say Y here to enable support for the battery charger in the Dialog
+ DA9058 PMIC.
+
+ To compile this driver as a module, choose M here: the module
+ will be called da9058_power.
+
config POWER_SUPPLY_DEBUG
bool "Power supply debug"
help
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b6b2434..8a4a049 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_WM831X_POWER)+= wm831x_power.o
obj-$(CONFIG_WM8350_POWER) += wm8350_power.o
obj-$(CONFIG_TEST_POWER) += test_power.o
+obj-$(CONFIG_BATTERY_DA9058) += da9058_power.o
obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o
obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o
obj-$(CONFIG_BATTERY_DS2781) += ds2781_battery.o
diff --git a/drivers/power/da9058_power.c b/drivers/power/da9058_power.c
new file mode 100644
index 000..5adfe07
--- /dev/null
+++ b/drivers/power/da9058_power.c
@@ -0,0 +1,403 @@
+/*
+ * Copyright (C) 2012 Dialog Semiconductor Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+struct da9058_power {
+ struct da9058 *da9058;
+ struct platform_device *pdev;
+ struct power_supply battery;
+
+ int battery_type;
+ u8 illegalbattery;
+ u8 health;
+ u16 bat_temp;
+ u16 bat_voltage;
+ u8 cal_capacity;
+ int bat_low_limit;
+ int use_automatic_adc;
+ int temperature_points;
+ struct da9058_temp_capacity (*temp_tables)[];
+};
+
+static inline u8 bat_temp_reg_to_C(u16 value)
+{
+ return 55 - value;
+}
+
+static inline u8 bat_mV_to_reg(u16 value)
+{
+ return ((value - 4100) / 100) << 4;
+}
+
+static inline u8 bat_drop_mV_to_reg(u16 value)
+{
+ return ((value - 100) / 100) << 6;
+}
+
+static inline u16 bat_reg_to_mV(u8 value)
+{
+ return (value * 100) + 4100;
+}
+
+static inline u16 bat_drop_reg_to_mV(u8 value)
+{
+ return (value * 100) + 100;
+}
+
+static inline u8 vbat_thr_mV_to_reg(u16 value)
+{
+ return (value - 2500) / 8;
+}
+
+static inline u16 vddout_reg_to_mV(u8 value)
+{
+ return (value * 8) + 2500;
+}
+
+static inline u16 volt_bit_reg_to_mV(u16 value)
+{
+ return (value * 2) + 2500;
+}
+
+static inline u16 volt_reg_to_mV(u16 value)
+{
+ return (((value * 610 * 100) / 115) + 240) / 1000;
+}
+
+static inline u16 volt_10bit_reg_to_mV(u16 value)
+{
+ return (((value * 1510 * 100) / 75) + 240) / 1000;
+}
+
+static inline u8 bit8_mV_to_reg(u16 value)
+{
+ return (value * 2500) / 256000;
+}
+
+/*
+ * to convert the ADC reading to milliVolts:
+ * LL00 for automatic conversion
+ * for manual conversion
+ * 2.5Volts == 0x --> 2500
+ * 4.5Volts == 0x0FFF --> 4500
+ */
+static int da9058_read_battery_millivolts(struct da9058_power *power)
+{
+ struct da9058 *da9058 = power->da9058;
+ int vbat;
+ int ret;
+
+ ret = da9058_adc_read(da9058, DA9058_ADCMAN_MUXSEL_VBAT,
+ power->use_automatic_adc, &vbat);
+
+ if (ret)
+ return ret;
+
+ power->bat_voltage = (2500*0x0FFF + vbat*2000)/0x0FFF;
+
+ return 0;
+}
+
+static int da9058_battery_temperature_tbat(struct da9058_power *power)
+{
+ struct da9058 *da9058 = power->da9058;
+ int temp;
+ int ret;
+
+ ret = da9058_adc_read(da9058, DA9058_ADCMAN_MUXSEL_TEMP,
+ power->use_automatic_adc, &temp);
+
+ if (ret)
+ return ret;
+
+ power->bat_temp = temp;
+
+ return 0;
+}
+
+static u32 interpolated(u32 vbat_lower, u32 vbat_upper, u32 level_lower,
+ u32 level_upper, u32 vbat)
+{
+ s32 temp;
+
+ /*apply formula y= yk + (x <96> xk) * (yk+1 <96> yk)/(xk+1 - xk) */
+
+ tem
[NEW DRIVER V1 0/7] please comment on this new PMIC driver
This is submission attempt number 1 to have this driver included in the linux kernel source tree. This is the driver for the Dialog DA9058. The DA9058 is a low power Power Management Integrated Circuit with extra functionality. It is a Multi Function Device controlled only from an I2C bus whose components can raise an interrupt request on a single IRQ line. The driver for the DA9058 consists of a core (i2c) device driver that instantiates the individual component device drivers for: hwmon - 5 ADC channels gpio - 2 available pins onkey - 1 device regulator - 4 BUCKS, 19 LDO and 3 fixed rtc - low power clock power - battery information All the above six component device drivers depend on the 'core' driver, which in number one in the patch series. This driver has been tested on a Samsung SMDK6410 connected to a Dialog DA9058 Evaluation Board via one GPIO and a 3-wire I2C connection. All the components can be builtin to the kernel or compiled as modules. As far as I can tell, all the latest APIs both for the core driver and all the component drivers have been adhered to, but if I have missed something please let me know. Many thanks, Anthony Olech, Dialog Semiconductor Ltd. Tony Olech (at Home) (7): DA9058 MFD core and ADC driver DA9058 ONKEY driver DA9058 POWER driver DA9058 RTC driver DA9058 GPIO driver DA9058 HWMON driver DA9058 REGULATOR driver drivers/gpio/Kconfig | 12 + drivers/gpio/Makefile|1 + drivers/gpio/gpio-da9058.c | 375 ++ drivers/hwmon/Kconfig| 10 + drivers/hwmon/Makefile |1 + drivers/hwmon/da9058-hwmon.c | 389 +++ drivers/input/misc/Kconfig | 10 + drivers/input/misc/Makefile |1 + drivers/input/misc/da9058_onkey.c| 170 drivers/mfd/Kconfig | 18 ++ drivers/mfd/Makefile |3 + drivers/mfd/da9058-core.c| 320 ++ drivers/mfd/da9058-i2c.c | 102 +++ drivers/mfd/da9058-irq.c | 66 + drivers/power/Kconfig| 10 + drivers/power/Makefile |1 + drivers/power/da9058_power.c | 403 drivers/regulator/Kconfig| 11 + drivers/regulator/Makefile |1 + drivers/regulator/da9058-regulator.c | 336 drivers/rtc/Kconfig | 21 +- drivers/rtc/Makefile |1 + drivers/rtc/rtc-da9058.c | 456 include/linux/mfd/da9058/bat.h | 33 +++ include/linux/mfd/da9058/codec.h | 21 ++ include/linux/mfd/da9058/core.h | 69 + include/linux/mfd/da9058/gpio.h | 19 ++ include/linux/mfd/da9058/hwmon.h | 20 ++ include/linux/mfd/da9058/irq.h | 45 include/linux/mfd/da9058/onkey.h | 17 ++ include/linux/mfd/da9058/pdata.h | 28 ++ include/linux/mfd/da9058/registers.h | 480 ++ include/linux/mfd/da9058/regulator.h | 33 +++ include/linux/mfd/da9058/rtc.h | 17 ++ 34 files changed, 3494 insertions(+), 6 deletions(-) create mode 100644 drivers/gpio/gpio-da9058.c create mode 100644 drivers/hwmon/da9058-hwmon.c create mode 100644 drivers/input/misc/da9058_onkey.c create mode 100644 drivers/mfd/da9058-core.c create mode 100644 drivers/mfd/da9058-i2c.c create mode 100644 drivers/mfd/da9058-irq.c create mode 100644 drivers/power/da9058_power.c create mode 100644 drivers/regulator/da9058-regulator.c create mode 100644 drivers/rtc/rtc-da9058.c create mode 100644 include/linux/mfd/da9058/bat.h create mode 100644 include/linux/mfd/da9058/codec.h create mode 100644 include/linux/mfd/da9058/core.h create mode 100644 include/linux/mfd/da9058/gpio.h create mode 100644 include/linux/mfd/da9058/hwmon.h create mode 100644 include/linux/mfd/da9058/irq.h create mode 100644 include/linux/mfd/da9058/onkey.h create mode 100644 include/linux/mfd/da9058/pdata.h create mode 100644 include/linux/mfd/da9058/registers.h create mode 100644 include/linux/mfd/da9058/regulator.h create mode 100644 include/linux/mfd/da9058/rtc.h -- end-of-patch for NEW DRIVER V1 -- 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] pwm: samsung: add missing device pointer to struct pwm_chip
This patch adds missing device pointer to struct pwm_chip. If the device pointer is NULL, pwmchip_add() will return error. Signed-off-by: Jingoo Han --- drivers/pwm/pwm-samsung.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c index d103865..e5187c0 100644 --- a/drivers/pwm/pwm-samsung.c +++ b/drivers/pwm/pwm-samsung.c @@ -225,6 +225,7 @@ static int s3c_pwm_probe(struct platform_device *pdev) /* calculate base of control bits in TCON */ s3c->tcon_base = id == 0 ? 0 : (id * 4) + 4; + s3c->chip.dev = &pdev->dev; s3c->chip.ops = &s3c_pwm_ops; s3c->chip.base = -1; s3c->chip.npwm = 1; -- 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 2/2] pwm: samsung: fix the number of PWMs
Samsung SoC can provide 4 PWMs; thus, the number of PWMs should be
set as 4.
Signed-off-by: Jingoo Han
---
drivers/pwm/pwm-samsung.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index e5187c0..32562c6 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -228,7 +228,7 @@ static int s3c_pwm_probe(struct platform_device *pdev)
s3c->chip.dev = &pdev->dev;
s3c->chip.ops = &s3c_pwm_ops;
s3c->chip.base = -1;
- s3c->chip.npwm = 1;
+ s3c->chip.npwm = 4;
s3c->clk = devm_clk_get(dev, "pwm-tin");
if (IS_ERR(s3c->clk)) {
--
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/
Re: [PATCH] fix NULL-pointer dereference on scsi_run_queue
On Thu, 2012-08-02 at 17:41 +0900, Chanho Min wrote: > This patch is to fix a oops from a torn down device. When > scsi_run_queue process starved queues, scsi_request_fn can race with > scsi_remove_device. In this case, rarely, scsi_request_fn release the > last reference and set sdev->request_queue to NULL. It result in > NULL-pointer dereference when spin_unlock is tried with (NULL)-> > queue_lock. We need to add an extra reference to the device on both > sides of the __blk_run_queue to hold reference until scsi_request_fn > is finished. You need a recent kernel with this patch: commit 940f5d47e2f2e1fa00443921a0abf4822335b54d Author: Bart Van Assche Date: Fri Jun 29 15:34:26 2012 + [SCSI] Avoid dangling pointer in scsi_requeue_command() James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] syscalls,x86: Add execveat() system call (v2)
On Thu, Aug 2, 2012 at 7:55 AM, Al Viro wrote:
>> This means you need an x32 version of the function -- execve
>> unfortunately is one of the few system calls which require a special x32
>> version (although it's a simple wrapper around sys32_execve). See
>> sys_x32_execve.
>
> I *really* strongly object to doing that thing before we sanitize the
> situation with sys_execve().
"That thing" = "creating an x32 entry stub", or "merging execveat() at all"?
(snip)
> The thing is, there's essentially no reason to have more than one
> implementation. What they are (badly) doing is "we need to find
> pt_regs to pass to do_execve(), the thing we are after has to be near
> our stack frame, so let's try to get to it that way".
Hang on...it's not just sys_execve that fits that description, is it?
You seem to be describing every call that needs a pt_regs parameter,
which at a glance is anything with a stub_ or PTREGSCALL in
arch/x86/kernel/entry_{32,64}.S. That's: clone, fork, vfork,
sigaltstack, iopl, execve, sigreturn, rt_sigreturn, vm86, vm86old.
Most of those are handled by a common PTREGSCALL macro, but there are
a few that get special treatment (different set on each arch - on
x86-64 it's execve and rt_sigreturn ; on i386 it's just clone).
Is there's something special about execve in particular, or do you
want to overhaul all the ptregscalls?
Meredydd
--
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] i2c: muxes: fix build break
Seems a new parameter is added to i2c_add_mux_adapter().
All its references, except for the one present in
i2c-mux-pinctrl.c, were updated.
As this is causing build break, pushing current patch to fix it.
Signed-off-by: Venu Byravarasu
---
drivers/i2c/muxes/i2c-mux-pinctrl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pinctrl.c
b/drivers/i2c/muxes/i2c-mux-pinctrl.c
index 46a6697..5f097f3 100644
--- a/drivers/i2c/muxes/i2c-mux-pinctrl.c
+++ b/drivers/i2c/muxes/i2c-mux-pinctrl.c
@@ -221,7 +221,7 @@ static int __devinit i2c_mux_pinctrl_probe(struct
platform_device *pdev)
(mux->pdata->base_bus_num + i) : 0;
mux->busses[i] = i2c_add_mux_adapter(mux->parent, &pdev->dev,
-mux, bus, i,
+mux, bus, i, 0,
i2c_mux_pinctrl_select,
deselect);
if (!mux->busses[i]) {
--
1.7.1.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: [RFC][PATCH v3 1/3] runtime interpreted power sequences
On Thu 02 Aug 2012 05:45:41 PM JST, Thierry Reding wrote:
* PGP Signed by an unknown key
On Thu, Aug 02, 2012 at 05:27:44PM +0900, Alex Courbot wrote:
On Thu 02 Aug 2012 05:21:57 PM JST, Thierry Reding wrote:
Old Signed by an unknown key
On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen Warren wrote:
Oh I see. That's a little confusing. Why not just reference the relevant
resources directly in each step; something more like:
gpio@1 {
action = "enable-gpio";
gpio = <&gpio 1 0>;
};
I guess that might make parsing/building a little harder, since you'd
have to detect when you'd already done gpio_request() on a given GPIO
and not repeat it or something like that, but to me this makes the DT a
lot easier to comprehend.
I tried to move towards having the phandles directly in the
sequences themselves - that reminded me why I did not do that in the
first place. Let's say we have a sequence like this (reg property
omitted on purpose):
power-on-sequence {
step@0 {
regulator = <&backlight_reg>;
enable;
};
step@1 {
delay = <1>;
};
step@2 {
pwm = <&pwm 2 500>;
enable;
};
step@3 {
gpio = <&gpio 28 0>;
enable;
};
};
The problem is, how do we turn these phandles into the resource of
interest. The type of the resource can be infered by the name of the
property. The hard part is resolving the resource from the phandle -
it seems like the API just does not allow to do this. GPIO has
of_get_named_gpio, but AFAIK there are no equivalent for regulator
consumer and PWM: the only way to use the DT with them is through
get_regulator and get_pwm which work at the device level.
Or is there a way that I overlooked?
No, you are right. Perhaps we should add exported functions that do the
equivalent of of_pwm_request() or the regulator_dev_lookup() and
of_get_regulator() pair.
How would that be looked with respect to "good DT practices"? I can
somehow understand the wish to restrain DT access to these functions
that integrate well with current workflows. Aren't we going to be
frowned upon if we make more low-level functions public?
Yes, I think that's exactly what will happen.
Probably not worth to try this then?
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[REGRESSION] kernel 3.5 / drm mode probe problem on i915GM
Hi! On an AOpen i915GMm-hfs a monitor connected to DVI-1 works well with both kernel 3.4.7 and 3.5. A monitor connected to VGA-1 boots to 1280x1024 with kernel 3.4.7 and 1024x768 with kernel 3.5. kernel 3.5 <7>[3.132038] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1] probed modes : <7>[3.132043] [drm:drm_mode_debug_printmodeline], Modeline 81:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa <7>[3.132049] [drm:drm_mode_debug_printmodeline], Modeline 79:"800x600" 60 4 800 840 968 1056 600 601 605 628 0x40 0x5 <7>[3.132054] [drm:drm_mode_debug_printmodeline], Modeline 78:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5 <7>[3.132060] [drm:drm_mode_debug_printmodeline], Modeline 80:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5 <7>[3.132066] [drm:drm_mode_debug_printmodeline], Modeline 77:"640x480" 60 25175 640 656 752 800 480 489 492 525 0x40 0xa kernel 3.4.7 = <7>[2.864191] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1] <7>[2.893552] [drm:intel_crt_detect_ddc], CRT detected via DDC:0x50 [EDID] <7>[2.922029] [drm:drm_edid_to_eld], ELD: no CEA Extension found <7>[2.922041] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1] probed modes : <7>[2.922047] [drm:drm_mode_debug_printmodeline], Modeline 69:"1280x1024" 75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5 <7>[2.922054] [drm:drm_mode_debug_printmodeline], Modeline 61:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5 <7>[2.922061] [drm:drm_mode_debug_printmodeline], Modeline 76:"1152x864" 75 108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5 <7>[2.922069] [drm:drm_mode_debug_printmodeline], Modeline 70:"1024x768" 75 78800 1024 1040 1136 1312 768 769 772 800 0x40 0x5 <7>[2.922076] [drm:drm_mode_debug_printmodeline], Modeline 71:"1024x768" 70 75000 1024 1048 1184 1328 768 771 777 806 0x40 0xa <7>[2.922083] [drm:drm_mode_debug_printmodeline], Modeline 72:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa <7>[2.922090] [drm:drm_mode_debug_printmodeline], Modeline 73:"832x624" 75 57284 832 864 928 1152 624 625 628 667 0x40 0xa <7>[2.922097] [drm:drm_mode_debug_printmodeline], Modeline 75:"800x600" 72 5 800 856 976 1040 600 637 643 666 0x40 0x5 <7>[2.922104] [drm:drm_mode_debug_printmodeline], Modeline 74:"800x600" 75 49500 800 816 896 1056 600 601 604 625 0x40 0x5 <7>[2.922111] [drm:drm_mode_debug_printmodeline], Modeline 62:"800x600" 60 4 800 840 968 1056 600 601 605 628 0x40 0x5 <7>[2.922118] [drm:drm_mode_debug_printmodeline], Modeline 63:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5 <7>[2.922125] [drm:drm_mode_debug_printmodeline], Modeline 65:"640x480" 73 31500 640 664 704 832 480 489 491 520 0x40 0xa <7>[2.922132] [drm:drm_mode_debug_printmodeline], Modeline 64:"640x480" 75 31500 640 656 720 840 480 481 484 500 0x40 0xa <7>[2.922139] [drm:drm_mode_debug_printmodeline], Modeline 66:"640x480" 67 30240 640 704 768 864 480 483 486 525 0x40 0xa <7>[2.922146] [drm:drm_mode_debug_printmodeline], Modeline 67:"640x480" 60 25200 640 656 752 800 480 490 492 525 0x40 0xa <7>[2.922153] [drm:drm_mode_debug_printmodeline], Modeline 68:"720x400" 70 28320 720 738 846 900 400 412 414 449 0x40 0x6 Xorg.0.log (kernel 3.4.7) === [ 1168.382] (II) intel(0): EDID for output VGA1 [ 1168.382] (II) intel(0): Manufacturer: TAR Model: c49 Serial#: 9571 [ 1168.383] (II) intel(0): Year: 2006 Week: 2 [ 1168.383] (II) intel(0): EDID Version: 1.3 [ 1168.383] (II) intel(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V [ 1168.383] (II) intel(0): Sync: Separate [ 1168.383] (II) intel(0): Max Image Size [cm]: horiz.: 38 vert.: 30 [ 1168.383] (II) intel(0): Gamma: 2.20 [ 1168.383] (II) intel(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display [ 1168.383] (II) intel(0): First detailed timing is preferred mode [ 1168.383] (II) intel(0): redX: 0.644 redY: 0.338 greenX: 0.270 greenY: 0.602 [ 1168.383] (II) intel(0): blueX: 0.140 blueY: 0.084 whiteX: 0.313 whiteY: 0.329 [ 1168.383] (II) intel(0): Supported established timings: [ 1168.383] (II) intel(0): 720x400@70Hz [ 1168.383] (II) intel(0): 640x480@60Hz [ 1168.383] (II) intel(0): 640x480@67Hz [ 1168.383] (II) intel(0): 640x480@72Hz [ 1168.383] (II) intel(0): 640x480@75Hz [ 1168.383] (II) intel(0): 800x600@56Hz [ 1168.383] (II) intel(0): 800x600@60Hz [ 1168.383] (II) intel(0): 800x600@72Hz [ 1168.383] (II) intel(0): 800x600@75Hz [ 1168.383] (II) intel(0): 832x624@75Hz [ 1168.383] (II) intel(0): 1024x768@60Hz [ 1168.383] (II) intel(0): 1024x768@70Hz [ 1168.383] (II) intel(0): 1024x768@75Hz [ 1168.383] (II) intel(0): 1280x1024@75Hz [ 1168.383] (II) intel(0): 1152x864@75Hz [ 1168.383] (II) intel(0): Manufacturer's mask: 0 [ 1168.383] (II) intel(0): Sup
Re: [PATCH] fix NULL-pointer dereference on scsi_run_queue
On Thu, Aug 2, 2012 at 5:57 PM, James Bottomley wrote: > On Thu, 2012-08-02 at 17:41 +0900, Chanho Min wrote: >> This patch is to fix a oops from a torn down device. When >> scsi_run_queue process starved queues, scsi_request_fn can race with >> scsi_remove_device. In this case, rarely, scsi_request_fn release the >> last reference and set sdev->request_queue to NULL. It result in >> NULL-pointer dereference when spin_unlock is tried with (NULL)-> >> queue_lock. We need to add an extra reference to the device on both >> sides of the __blk_run_queue to hold reference until scsi_request_fn >> is finished. > > You need a recent kernel with this patch: > > commit 940f5d47e2f2e1fa00443921a0abf4822335b54d > Author: Bart Van Assche > Date: Fri Jun 29 15:34:26 2012 + > > [SCSI] Avoid dangling pointer in scsi_requeue_command() > > James It is different from my case. This is occured inside scsi_run_queue and on processing starved_list. Another sdev is obtained from starved_list. -- 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: linux-next: removal of some trees
On 08/02/2012 06:41 AM, Stephen Rothwell wrote: Hi Ben, Since I haven't been able to fetch these trees for quite some time and I haven't heard from you about them, I am removing the following trees from linux-next. If/When you have time to maintain these trees again, we can add them back without problems. samsung git://git.fluff.org/bjdooks/linux.git#next-samsung bjdooks-i2c git://git.fluff.org/bjdooks/linux.git#next-i2c Hi, Stephen, By the way, please remove my kmap_atomic tree[1] as well, its mission is completed now. :) Thanks! 1. git://github.com/congwang/linux -- 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] fix NULL-pointer dereference on scsi_run_queue
On Thu, 2012-08-02 at 18:28 +0900, Chanho Min wrote: > On Thu, Aug 2, 2012 at 5:57 PM, James Bottomley > wrote: > > On Thu, 2012-08-02 at 17:41 +0900, Chanho Min wrote: > >> This patch is to fix a oops from a torn down device. When > >> scsi_run_queue process starved queues, scsi_request_fn can race with > >> scsi_remove_device. In this case, rarely, scsi_request_fn release the > >> last reference and set sdev->request_queue to NULL. It result in > >> NULL-pointer dereference when spin_unlock is tried with (NULL)-> > >> queue_lock. We need to add an extra reference to the device on both > >> sides of the __blk_run_queue to hold reference until scsi_request_fn > >> is finished. > > > > You need a recent kernel with this patch: > > > > commit 940f5d47e2f2e1fa00443921a0abf4822335b54d > > Author: Bart Van Assche > > Date: Fri Jun 29 15:34:26 2012 + > > > > [SCSI] Avoid dangling pointer in scsi_requeue_command() > > > > James > It is different from my case. This is occured inside scsi_run_queue > and on processing starved_list. > Another sdev is obtained from starved_list. Does it occur with that patch applied? If it does, the likely fix would be to take a copy of the queue ... but I'd like to understand why first. An active command has an automatic reference to the sdev_gendev, so it shouldn't be the normal case. This was broken by unprep because it releases the command from the queue and drops the reference. We may have another case like unjprep, but in that case, we need to find it ... trying to add extra get/put_device() calls will paper over the problem. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: abort secondary CPU bring-up gracefully if do_boot_cpu timed out on cpu_callin_mask
Hi Toshi, I'm sorry for delayed response, I was on vacation. Thanks for looking at the patch, my comments are below. PS: I'm not happy with introducing one more sync point and bitmat. Well, it's necessary to somehow notify being on-lined CPU that master CPU will wait for it, but perhaps it could be done even earlier than in this patch and less stuff should be backed-out. Currently master CPU spins on cpu_callin_mask till secondary CPU sets it in smp_callin(). Then master CPU leaves do_boot_cpu() and does nothing in native_cpu_up() first waiting for secondary CPU in check_tsc_sync_source() or if that is skipped then immediately spinning on 'while (!cpu_online(cpu))'. Master CPU will do nothing and will not call any CPU notifiers until secondary CPU reports that it is ONLINE by setting bit in cpu_online_mask at the end of start_secondary(). So questions to experts are: 1. what is purpose of cpu_callin_mask 2. why master CPU spins on cpu_callin_mask but not on cpu_initialized_mask In current state of code, it looks like cpu_callin_mask is not necessary and we could remove it completely and spin on cpu_initialized_mask in do_boot_cpu() instead. Then when master CPU sees secondary CPU in cpu_initialized_mask it could set cpu_callout_mask to ack its intention not to cancel and wait until secondary CPU is booted. PS2: I wish x86 maintainers were more responsive to the topic and in discussion we could find a way to fix problem. With their expertise, It's surely easier to spot potential issues and see correct approach for the fix. - Original Message - From: "Toshi Kani" To: imamm...@redhat.com Cc: linux-kernel@vger.kernel.org, pra...@redhat.com, o...@redhat.com, r...@landley.net, t...@linutronix.de, mi...@redhat.com, h...@zytor.com, x...@kernel.org, l...@mit.edu, "suresh b siddha" , a...@redhat.com, "a p zijlstra" , johns...@us.ibm.com, "toshi kani" Sent: Wednesday, July 11, 2012 11:49:19 PM Subject: Re: [PATCH 1/2] x86: abort secondary CPU bring-up gracefully if do_boot_cpu timed out on cpu_callin_mask Hi Igor, This is a nice work to handle CPU bring-up error properly. My comments are in-line below. On Wed, 2012-07-11 at 14:12 -0600, Toshi Kani wrote: > Master CPU may timeout before cpu_callin_mask is set and cancel > booting CPU, but being onlined CPU still continues to boot, sets > cpu_active_mask (CPU_STARTING notifiers) and spins in > check_tsc_sync_target() for master cpu to arrive. Following attempt > to online another cpu hangs in stop_machine, initiated from here: > > smp_callin -> > smp_store_cpu_info -> > identify_secondary_cpu -> > mtrr_ap_init -> set_mtrr_from_inactive_cpu > > stop_machine waits on completion of stop_work on all CPUs from > cpu_active_mask including a failed CPU that spins in > check_tsc_sync_target(). > > Issue could be fixed if being onlined CPU continues to boot and > calls > notify_cpu_starting(cpuid) only when master CPU waits for it to > come online. If master CPU times out on cpu_callin_mask and goes > via > cancel path, the being onlined CPU should gracefully shutdown > itself. > > Patch introduces cpu_may_complete_boot_mask to notify a being > onlined > CPU that it may call notify_cpu_starting(cpuid) and continue to > boot > when master CPU goes via normal boot path and going to wait till > the > being onlined CPU completes its initialization. > > normal boot sequence will look like: > master CPU1 being onlined CPU2 > > * wait for CPU2 in cpu_callin_mask > - > * set CPU2 in > cpu_callin_mask > * wait till CPU1 set CPU2 > bit > in > cpu_may_complete_boot_mask > - > * set CPU2 bit in >cpu_may_complete_boot_mask > * return from do_boot_cpu() and >wait in > - check_tsc_sync_source() or > - while (!cpu_online(CPU2)) > - > * call > notify_cpu_starting() > and continue CPU2 initialization >* mark itself as ONLINE > - > * return to _cpu_up and call >cpu_notify(CPU_ONLINE, ...) > > cancel/error path will look like: > master CPU1 being onlined CPU2 > > * time out on cpu_callin_mask > - >* set CPU2 in >cpu_callin_mask >
Re: [RFC 1/4] hashtable: introduce a small and naive hashtable
On Wed, Aug 01, 2012 at 11:27:49AM -0700, Tejun Heo wrote: > On Wed, Aug 01, 2012 at 08:24:32PM +0200, Sasha Levin wrote: > > On 08/01/2012 08:21 PM, Tejun Heo wrote: > > > On Wed, Aug 01, 2012 at 08:19:52PM +0200, Sasha Levin wrote: > > >> If we switch to using functions, we could no longer hide it anywhere > > >> (we'd need to either turn the buckets into a struct, or have the > > >> user pass it around to all functions). > > > > > > Create an outer struct hash_table which remembers the size? > > > > Possible. I just wanted to avoid creating new structs where they're not > > really required. > > > > Do you think it's worth it for eliminating those two macros? > > What if someone wants to allocate hashtable dynamically which isn't > too unlikely? In particular, once this goes in, I'd like to add RCU-based hash resizing to it, which will require wrapping the hash table in a struct that also contains the size. So, please do consider having such a struct rather than relying on static array sizes. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: muxes: fix build break
Hi Venu,
On Thu, 2 Aug 2012 14:42:17 +0530, Venu Byravarasu wrote:
> Seems a new parameter is added to i2c_add_mux_adapter().
> All its references, except for the one present in
> i2c-mux-pinctrl.c, were updated.
> As this is causing build break, pushing current patch to fix it.
Thanks for the heads up. When I wrote the patch adding the parameter,
the i2c-mux-pinctrl driver wasn't upstream yet, that's why I missed it.
>
> Signed-off-by: Venu Byravarasu
> ---
> drivers/i2c/muxes/i2c-mux-pinctrl.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/muxes/i2c-mux-pinctrl.c
> b/drivers/i2c/muxes/i2c-mux-pinctrl.c
> index 46a6697..5f097f3 100644
> --- a/drivers/i2c/muxes/i2c-mux-pinctrl.c
> +++ b/drivers/i2c/muxes/i2c-mux-pinctrl.c
> @@ -221,7 +221,7 @@ static int __devinit i2c_mux_pinctrl_probe(struct
> platform_device *pdev)
> (mux->pdata->base_bus_num + i) : 0;
>
> mux->busses[i] = i2c_add_mux_adapter(mux->parent, &pdev->dev,
> - mux, bus, i,
> + mux, bus, i, 0,
>i2c_mux_pinctrl_select,
>deselect);
> if (!mux->busses[i]) {
As the problematic patch isn't upstream yet, I've simply folded the
above into it:
http://khali.linux-fr.org/devel/linux-3/jdelvare-i2c/i2c-mux-support-class.patch
Thanks again,
--
Jean Delvare
--
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] pwm: samsung: fix the number of PWMs
On Thu, Aug 02, 2012 at 05:56:27PM +0900, Jingoo Han wrote: > Samsung SoC can provide 4 PWMs; thus, the number of PWMs should be > set as 4. > > Signed-off-by: Jingoo Han > --- > drivers/pwm/pwm-samsung.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c > index e5187c0..32562c6 100644 > --- a/drivers/pwm/pwm-samsung.c > +++ b/drivers/pwm/pwm-samsung.c > @@ -228,7 +228,7 @@ static int s3c_pwm_probe(struct platform_device *pdev) > s3c->chip.dev = &pdev->dev; > s3c->chip.ops = &s3c_pwm_ops; > s3c->chip.base = -1; > - s3c->chip.npwm = 1; > + s3c->chip.npwm = 4; I don't think this is correct. The driver seems to be using the platform device id as index currently, which indicates that the driver is bound against 4 different platform devices, each representing a single PWM. If you want to service multiple PWM devices by a single instance you need to make further changes to the driver. For instance the tcon_base is initialized based on the platform id. This could easily be replaced by making it depend on the .hwpwm member of pwm_device. You may also want to consider making the driver a proper module if that works on the platforms that need it. I see that it is currently an arch_initcall, but it might be cleaner to use deferred driver probe instead. Thierry pgpka37bI1qm6.pgp Description: PGP signature
Re: [PATCH 1/6] ASoC: dapm: If one widget fails, do not force all subsequent widgets to fail too
On Thu, Aug 02, 2012 at 07:58:24AM +0200, Ola Lilja wrote: > Accusing me of having "no interest in fixing the driver" is just absurd > regarding the time I've spent on this. I'm also still driving for Sorry, this is more directed at the current round of fixes that are being sent than the driver itself - the patches to bodge around the issue are being pushed fairly aggressively as an urgent fix without even mentioning what the issue is. I don't have any concerns with the driver, only with the way it's being fixed. > Regarding the problem with the failing DAPM-widget I can probably guess > What is going wrong when Lee is trying it out. There will be two failing > clock-supply widgets due to the fact that on the mainline-code these > clocks simply is not there yet. I have, of course, tested this driver > before submitting it, and I wouldn't dream on submitting a driver where > there were failing widgets/routes. Internally, I have put a patch with our > clock-tree for Ux500 on, but this is not mainline-quality code and that is This sort of reliance on out of tree patches which any real user of the device would be expected to have sounds like exactly the sort of thing I'd expect to have caused an issue like this, and obviously the fix here is to get the clocks in place (even if just as stubs, though I'd expect there to be a major impact on the functionality of the device if it's not clocked...) rather than to just bodge out the error checking. It does also suggest that the DT binding for this device will need to include the setup of these clocks (I believe the clock bindings for DT have just gone into mainline this merge window but I'd need to check). -- 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 1/4] hashtable: introduce a small and naive hashtable
On 08/02/2012 12:45 AM, Tejun Heo wrote:
> On Thu, Aug 02, 2012 at 12:41:56AM +0200, Sasha Levin wrote:
>> How would your DEFINE_HASHTABLE look like if we got for the simple
>> 'struct hash_table' approach?
>
> I think defining a different enclosing anonymous struct which the
> requested number of array entries and then aliasing the actual
> hash_table to that symbol should work. It's rather horrible and I'm
> not sure it's worth the trouble.
I agree that this is probably not worth the trouble.
At the moment I see two alternatives:
1. Dynamically allocate the hash buckets.
2. Use the first bucket to store size. Something like the follows:
#define HASH_TABLE(name, bits) \
struct hlist_head name[1 << bits + 1];
#define HASH_TABLE_INIT (bits) ({name[0].next = bits});
And then have hash_{add,get} just skip the first bucket.
While it's not a pretty hack, I don't see a nice way to avoid having to
dynamically allocate buckets for all cases.
--
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] drivers: usb: musb: cleanup while removing musb omap glue driver
No functional change. Just replaced the call to platform_device_del and platform_device_put with platform_device_unregister. Signed-off-by: Kishon Vijay Abraham I --- drivers/usb/musb/omap2430.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 5fdb9da..392fc7a 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -509,8 +509,7 @@ static int __devexit omap2430_remove(struct platform_device *pdev) struct omap2430_glue*glue = platform_get_drvdata(pdev); cancel_work_sync(&glue->omap_musb_mailbox_work); - platform_device_del(glue->musb); - platform_device_put(glue->musb); + platform_device_unregister(glue->musb); return 0; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc/smp: Do not disable IPI interrupts during suspend
On Sat, Jul 28, 2012 at 08:20:31AM +1000, Benjamin Herrenschmidt wrote: > On Fri, 2012-07-27 at 16:58 -0500, Kumar Gala wrote: > > On Jul 20, 2012, at 7:47 AM, Zhao Chenhui wrote: > > > > > During suspend, all interrupts including IPI will be disabled. In this > > > case, > > > the suspend process will hang in SMP. To prevent this, pass the flag > > > IRQF_NO_SUSPEND when requesting IPI irq. > > > > > > Signed-off-by: Zhao Chenhui > > > Signed-off-by: Li Yang > > > --- > > > arch/powerpc/kernel/smp.c |2 +- > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > BenH, > > > > Can you ack? > > No I'll merge it but not until it's been in next for a bit unless you > have some strong emergency there, it's on my mental list of things to > shovel into next after rc1. > > Curiosity: didn't we use to disable all non-boot CPUs on suspend ? > > Cheers, > Ben. Yes, we disabled all non-boot CPUs on suspend by calling disable_nonboot_cpus(). The disable_nonboot_cpus() needs IPIs to work. But prior to calling disable_nonboot_cpus(), the IPIs are disabled in dpm_suspend_noirq(). -Chenhui -- 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] uprobes: Ignore unsupported instructions in uprobe_mmap
uprobe_mmap()->install_breakpoint() can fail if the probed insn is not
supported (remember, uprobe_register() succeeds if nobody mmaps
inode/offset). Failure in uprobe_mmap() causes mmap_region/do_fork to
fail too.
However failing mmap_region()/do_fork() because of a probe on an
unsupported instruction is wrong.
Hence change uprobe_mmap() to ignore unsupported instructions.
Oleg Nesterov analyzed the root cause of this problem.
While at it, add a missing put_uprobe() in the path where uprobe_mmap()
races with uprobe_unregister().
Reported-by: William Cohen
Signed-off-by: Srikar Dronamraju
Cc: Oleg Nesterov
Cc: # v3.5
---
kernel/events/uprobes.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index c08a22d..c8a8c39 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1051,8 +1051,10 @@ int uprobe_mmap(struct vm_area_struct *vma)
if (ret == -EEXIST) {
ret = 0;
- if (!is_swbp_at_addr(vma->vm_mm, vaddr))
+ if (!is_swbp_at_addr(vma->vm_mm, vaddr)) {
+ put_uprobe(uprobe);
continue;
+ }
/*
* Unable to insert a breakpoint, but
@@ -1060,6 +1062,15 @@ int uprobe_mmap(struct vm_area_struct *vma)
* probe count.
*/
atomic_inc(&vma->vm_mm->uprobes_state.count);
+ } else if (ret == -ENOTSUPP) {
+ /*
+* A probe at unsupported instruction
+* shouldnt cause mmap_region() / do_fork()
+* to fail.
+*/
+ ret = 0;
+ put_uprobe(uprobe);
+ continue;
}
if (!ret)
--
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] spi: omap2-mcspi: Fix the error handling in probe
On Wednesday 01 August 2012 08:37 PM, Guenter Roeck wrote:
> On Wed, Aug 01, 2012 at 03:06:28PM +0530, Shubhrajyoti D wrote:
>> The kfree() is taken care of by the spi core (spi_master_release() function)
>> that is called once the last reference to the underlying struct device has
>> been released. So the driver need not call kfree.
>>
>> Also the put was missed in some of the error handling fix the same.
>> There by fixing the missing device_put in some of the error paths.
>>
>> Cc: Guenter Roeck
> Reported-by: may be better here.
My bad. I should have done.
>
>> Signed-off-by: Shubhrajyoti D
> Acked-by: Guenter Roeck
thanks.
> I suspect that "spi_master_put(master);" may also be missing in
> omap2_mcspi_remove(), but we'll need someone to confirm that.
Looks unlikely.
spi_master_put does a
...
if (master)
put_device(&master->dev);
...
In remove I call
spi_unregister_master
...
*/
void spi_unregister_master(struct spi_master *master)
{
int dummy;
[...]
dummy = device_for_each_child(&master->dev, NULL, __unregister);
device_unregister(&master->dev);
}
and
void device_unregister(struct device *dev)
{
[..]
device_del(dev);
put_device(dev);
}
Hope my understanding is correct.
> Thanks,
> Guenter
>
>> ---
>> drivers/spi/spi-omap2-mcspi.c |6 ++
>> 1 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
>> index 7d46b15..b5035e2 100644
>> --- a/drivers/spi/spi-omap2-mcspi.c
>> +++ b/drivers/spi/spi-omap2-mcspi.c
>> @@ -1203,18 +1203,16 @@ static int __devinit omap2_mcspi_probe(struct
>> platform_device *pdev)
>>
>> status = spi_register_master(master);
>> if (status < 0)
>> -goto err_spi_register;
>> +goto disable_pm;
>>
>> return status;
>>
>> -err_spi_register:
>> -spi_master_put(master);
>> disable_pm:
>> pm_runtime_disable(&pdev->dev);
>> dma_chnl_free:
>> kfree(mcspi->dma_channels);
>> free_master:
>> -kfree(master);
>> +spi_master_put(master);
>> platform_set_drvdata(pdev, NULL);
>> return status;
>> }
>> --
>> 1.7.5.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] iio: lm3533-als: Fix build warnings
Fix below build warnings:
CC [M] drivers/iio/light/lm3533-als.o
drivers/iio/light/lm3533-als.c:667:8: warning: initialization from incompatible
pointer type [enabled by default]
drivers/iio/light/lm3533-als.c:667:8: warning: (near initialization for
'dev_attr_in_illuminance0_thresh_either_en.show') [enabled by default]
drivers/iio/light/lm3533-als.c:667:8: warning: initialization from incompatible
pointer type [enabled by default]
drivers/iio/light/lm3533-als.c:667:8: warning: (near initialization for
'dev_attr_in_illuminance0_thresh_either_en.store') [enabled by default]
Signed-off-by: Axel Lin
---
drivers/iio/light/lm3533-als.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/light/lm3533-als.c b/drivers/iio/light/lm3533-als.c
index c3e7bac..e45712a9 100644
--- a/drivers/iio/light/lm3533-als.c
+++ b/drivers/iio/light/lm3533-als.c
@@ -404,7 +404,7 @@ out:
return ret;
}
-static int show_thresh_either_en(struct device *dev,
+static ssize_t show_thresh_either_en(struct device *dev,
struct device_attribute *attr,
char *buf)
{
@@ -424,7 +424,7 @@ static int show_thresh_either_en(struct device *dev,
return scnprintf(buf, PAGE_SIZE, "%u\n", enable);
}
-static int store_thresh_either_en(struct device *dev,
+static ssize_t store_thresh_either_en(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t len)
{
--
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] Documentation/kvm : Add documentation on Hypercalls
On 02.08.2012, at 09:08, Raghavendra K T wrote: > On 08/01/2012 11:55 PM, Marcelo Tosatti wrote: >> On Wed, Aug 01, 2012 at 04:19:01PM +0530, Raghavendra K T wrote: >>> On 08/01/2012 08:37 AM, Marcelo Tosatti wrote: On Tue, Jul 24, 2012 at 02:23:59PM +0530, Raghavendra K T wrote: > From: Raghavendra K T > > Thanks Alex for KVM_HC_FEATURES inputs and Jan for VAPIC_POLL_IRQ, > and Peter (HPA) for suggesting hypercall ABI addition. > > Signed-off-by: Raghavendra K T > --- > [...] > + > + Up to four arguments may be passed in rbx, rcx, rdx, and rsi > respectively. > + The hypercall number should be placed in rax and the return value will > be > + placed in rax. No other registers will be clobbered unless explicitly > stated > + by the particular hypercall. It depends on the hypercall. It happens that current hypercalls use the four registers, but its not an ABI (hyper-v hypercalls uses r8, for example). >>> >>> Okay, agree. I did not know about hyper-v. Above one is for X86 and >>> KVM (and not X86 / hyper-v). So I should remove ABI and probably say, >> >> Just say "Linux x86 Hypercall", yeah. >> > > Ok, Thanks Marcelo.will respin patches with the changes you suggested. > > Also I would like add Alex's description on ppc hypercalls > into Documentation/virtual/kvm/ppc-pv.txt with Alex from/sob or > suggested-by in a separate patch unless I see any objection to that. > Yeah, don't stall this on me :) Alex-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW DRIVER V1 1/7] DA9058 MFD core and ADC driver
On Thu, Aug 02, 2012 at 09:48:55AM +0100, Anthony Olech wrote:
> +#if 0
> + return regmap_bulk_read(da9058->regmap, reg, val, val_count);
> +#else
> + int ret = regmap_bulk_read(da9058->regmap, reg, val, val_count);
> + return ret;
> +#endif
This shouldn't be going into mainline...
> +/*
> + * if the PMIC is in automatic ADC consersion mode we have the choice
> + * of just getting the last (automatic) conversion or doing a manual
> + * conversion anyway.
> + *
> + * if the PMIC is not in automatic ADC consersion mode we have no choice
> + * we just have to ignore the requested mode and just do a manual
> + * ADC conversion.
> + */
> +static int da9058_automatic_adc_conversion(struct da9058 *da9058,
> + const int channel, int *value)
This ADC stuff should be an IIO driver now.
> + if (pdata->init_board_irq) {
> + ret = pdata->init_board_irq();
> + if (ret)
Why is this conditional? With irqdomains there's no real reason to not
allocate the IRQs even if you can't usefully use them and it helps make
the code simpler.
> + goto err4;
Named labesl are *much* better, it's vastly less painful if you need to
add new code.
> + da9058->reg_read = da9058_register_read;
> + da9058->reg_write = da9058_register_write;
> + da9058->reg_raw_read = da9058_register_raw_read;
> + da9058->reg_raw_write = da9058_register_raw_write;
> + da9058->reg_bulk_read = da9058_register_bulk_read;
> + da9058->reg_bulk_write = da9058_register_bulk_write;
> + da9058->reg_update_bits = da9058_register_update_bits;
These are always the same thing. Just have some inline functions in the
header if you find this useful, the vtable in the driver is just
replicating what regmap does and making things more complicated.
> +int da9058_to_virt_irq_num(struct da9058 *da9058, int irq)
> +{
> + return da9058->irq_base + irq;
> +}
> +EXPORT_SYMBOL_GPL(da9058_to_virt_irq_num);
This should be calling regmap_irq_get_virq() and a static inlinne in the
header.
> + dev_info(da9058->dev, "IRQ %d mapped to virtual array based at %d\n",
> + da9058->chip_irq, da9058->irq_base);
This sort of log message isn't terribly useful and isn't accurate with
irq domains.
--
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: [NEW DRIVER V1 0/7] please comment on this new PMIC driver
On Thu, Aug 02, 2012 at 09:48:58AM +0100, Anthony Olech wrote: > This is submission attempt number 1 to have this driver included in > the linux kernel source tree. This is the driver for the Dialog DA9058. I just noticed that you haven't CCed the maintainers for most of this stuff on your patches... you should always do this if you want review. -- 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: [NEW DRIVER V1 5/7] DA9058 GPIO driver
On Thu, Aug 02, 2012 at 09:48:57AM +0100, Anthony Olech wrote:
> + mutex_lock(&gpio->lock);
> + ret = da9058_reg_read(da9058, DA9058_STATUSC_REG, &gpio_level);
> + mutex_unlock(&gpio->lock);
regmap already does locking for you.
> + ret = da9058_reg_read(da9058, DA9058_GPIO0001_REG, &gpio_cntrl);
> + if (ret)
> + goto exit;
> +
> + if (offset) {
> + gpio_cntrl &= ~0xF0;
> + gpio_cntrl |= 0xF0 & gpio->out_config;
> +
> + ret = da9058_reg_write(da9058, DA9058_GPIO0001_REG, gpio_cntrl);
Just use regmap_update_bits().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCHv5 09/11] modem_shm: Character device for SHM channel access.
On Tue, 31 Jan 2012 09:48:44 +0100
Sjur Brændeland wrote:
> Add a character device implementation for the SHM stream channels.
> The character device provides asynchronous IO and ring-buffer handling.
> The device copies data directly from the Shared Memory area into
> user-land buffers.
What is the use case for this - it seems a little odd that it's not using
the tty layer so won't work with all the normal modem apps as anyone
would expect and want ?
> +static unsigned int shmchr_chrpoll(struct file *filp, poll_table *waittab)
> +{
> + struct shmchr_char_dev *dev = filp->private_data;
> + unsigned int mask = 0;
> +
> + if (dev == NULL) {
> + mdev_dbg(dev, "private_data not set!\n");
> + return -EBADFD;
> + }
How can this occur. If it can't occur why check ? BUG_ON() would
certainly be better to as you'd get a trace and it would get captured not
silently ignored and problems never detected.
An if.. dbg sequence to end users is basically "silently pretend we
didn't break and hope", which isn't ideal at all.
> +
> + /* I want to be alone on dev (except status and queue). */
> + if (mutex_lock_interruptible(&dev->mutex)) {
> + mdev_dbg(dev, "mutex_lock_interruptible got signalled\n");
> + mask |= POLLERR;
> + goto out_unlocked;
That's very odd behaviour for poll() and may confuse apps. Can the mutex
ever be held for a long time ?
--
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: [NEW DRIVER V1 7/7] DA9058 REGULATOR driver
On Thu, Aug 02, 2012 at 09:48:58AM +0100, Anthony Olech wrote:
Overall the big issue here is that the driver isn't making much use of
framework features, there should be a *lot* less code here.
> +static unsigned int da9058_regulator_val_to_mvolts(unsigned int val,
> + struct regulator_dev *rdev)
regualtor_map_voltage_linear()
> + ret = da9058_reg_read(da9058, regulator->control_register, &val);
> + if (ret)
> + return ret;
> +
> + if (regulator->control_enable_mask&val)
> + return true;
> + else
> + return false;
regulator_is_enabled_regmap().
> +static int da9058_regulator_set_voltage(struct regulator_dev *rdev,
> + int min_uV, int max_uV,
> + unsigned *selector)
Should be set_voltage_sel().
> + if (regulator->ramp_register && regulator->ramp_enable_mask)
> + ret =
> + da9058_set_bits(da9058, regulator->ramp_register,
> + regulator->ramp_enable_mask);
What is this doing?
> + if (regulator->control_voltage_step == 0) {
> + if (da9058_regulator_is_enabled(rdev))
> + return regulator->fixed_voltage;
> + else
> + return 0;
> + }
No, don't do stuff like this - implement a separate op (or just use the
standard ops in this case).
> +
> + ret = da9058_reg_read(da9058, regulator->control_register, &val);
> + if (ret)
> + return ret;
This should just be regulator_get_voltage_sel_regmap().
> +static int da9058_regulator_enable(struct regulator_dev *rdev)
> +{
regulator_enable_regmap() and similarly for all the others.
> +static unsigned int da9058_regulator_get_mode(struct regulator_dev *rdev)
> +{
> + return REGULATOR_MODE_NORMAL;
> +}
If you don't support modes don't implement the op.
> + regulator_pdata = cell->platform_data;
> + if (regulator_pdata == NULL) {
> + ret = -EINVAL;
> + goto exit;
> + }
The driver should be able to start without any platform data.
> + dev_info(&pdev->dev, "Starting REGULATOR %d = %s\n",
> + regulator_pdata->regulator_id,
> + regulator_pdata->regulator_name);
There's a couple of issues here. One is that you shouldn't be logging
anything here, log messages on driver load are only useful if you're
saying something you've identified from the hardware - for example,
logging the device revision on startup is very helpful. The other is
that you shouldn't need to supply a name and ID as platform data since
that's exactly how the platform bus binds drivers.
> + regulator->control_voltage_step = regulator_pdata->control_voltage_step;
> + regulator->control_register = regulator_pdata->control_register;
> + regulator->control_enable_mask = regulator_pdata->control_enable_mask;
> + regulator->ramp_register = regulator_pdata->ramp_register;
> + regulator->ramp_enable_mask = regulator_pdata->ramp_enable_mask;
> + regulator->fixed_voltage = regulator_pdata->fixed_voltage;
Your MFD didn't visibly provide any of this stuff, though I may have
missed it, and honestly I'd expect most of this to be in the driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] syscalls,x86: Add execveat() system call (v2)
On Thu, Aug 02, 2012 at 10:14:53AM +0100, Meredydd Luff wrote:
> On Thu, Aug 2, 2012 at 7:55 AM, Al Viro wrote:
> >> This means you need an x32 version of the function -- execve
> >> unfortunately is one of the few system calls which require a special x32
> >> version (although it's a simple wrapper around sys32_execve). See
> >> sys_x32_execve.
> >
> > I *really* strongly object to doing that thing before we sanitize the
> > situation with sys_execve().
>
> "That thing" = "creating an x32 entry stub", or "merging execveat() at all"?
>
> (snip)
> > The thing is, there's essentially no reason to have more than one
> > implementation. What they are (badly) doing is "we need to find
> > pt_regs to pass to do_execve(), the thing we are after has to be near
> > our stack frame, so let's try to get to it that way".
>
> Hang on...it's not just sys_execve that fits that description, is it?
> You seem to be describing every call that needs a pt_regs parameter,
> which at a glance is anything with a stub_ or PTREGSCALL in
> arch/x86/kernel/entry_{32,64}.S. That's: clone, fork, vfork,
> sigaltstack, iopl, execve, sigreturn, rt_sigreturn, vm86, vm86old.
> Most of those are handled by a common PTREGSCALL macro, but there are
> a few that get special treatment (different set on each arch - on
> x86-64 it's execve and rt_sigreturn ; on i386 it's just clone).
>
> Is there's something special about execve in particular, or do you
> want to overhaul all the ptregscalls?
You are looking at that from the wrong side; it's not that this
set of syscalls on x86 has the same kind of wrapper - it's that
on different architectures the kludges are seriously different
and fairly brittle. sigaltstack(), BTW, doesn't need to be
arch-specific at all - if you check what its pt_regs argument
is used for, we just need something like current_user_stack_pointer()
and that's it. It's a different patch series, anyway.
There's a difference between "here's the syscall implementation,
here's its hookup for x86, let other architectures update their
syscall tables" and "here's the implementation in arch/x86 and its
hookup for x86; let other architectures port it in whatever way
they need". The latter is a recipe for breakage - we'd been
through that kind of story quite a few times.
Out of that set, vm86/vm86old/iopl are genuine x86-only syscalls.
sigreturn and rt_sigreturn are weird, subtle and, sadly,
unmergable - syscall restart prevention logics is different
enough to make it not feasible at the moment. It's a serious
source of PITA, BTW - quite a few of those had the same bugs,
years after they'd been discovered and fixed on a subset of
architectures. Been there, fixed some of those, the latest
batch this April... fork/vfork/clone is an interesting
question - IIRC, there are seriously subtle issues of some
sort on sparc, but I don't remember details right now.
Really, go and grep for do_execve; most of the callers will
be in execve(2) implementations. Look at them carefully -
while some get pt_regs from some wrapper, there's a bunch
that does that manually in C. "Ugly" doesn't even begin
to describe what's being done...
FWIW, I've just pushed (completely untested) arm and alpha
parts of what I described into signal.git#execve2; x86 is
next. Note that after that sys_execve() is identical on
converted architectures and can be merged; ditto for
kernel_execve(). After I do x86 counterpart, I'll
take those guys to fs/exec.c under ifdef for new __ARCH_HAS_...
(and define it on already converted ones, obviously).
Then your patch goes there, except that implementation
gets put into fs/exec.c, under the same ifdef. And with
current_pt_regs() used instead of the extra argument,
of course. From that point on it can be used on any converted
architecture. And conversion consists of
* providing ret_from_kernel_execve() that would
put pt_regs where they belong and return to userland.
* providing current_pt_regs(), with default being
just task_pt_regs(current).
* defining that new __ARCH_HAS_...
* removing sys_execve()/kernel_execve() implementations;
the ones in fs/exec.c will work just fine.
Can be done at leisure, architecture by architecture. It's
obviously the next cycle fodder - we have only a couple of
days left of this merge window, anyway.
I really think that this pair of primitives is the right
way to deal with execve mess.
--
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/5] clk: mmp: add clock definition for pxa168
On Thursday 02 August 2012, Chao Xie wrote: > > #define APBC_RTC 0x28 > > > > apbc_clks[rtc_clk] = mmp_clk_register_apbc(rtc_clk, clk32k, APBC_RTC, 10, > > APBC_POWER_CTRL, mmp_clk_lock); > > clk_register_clkdev(apbc_clks[rtc_clk], NULL, "sa1100-rtc"); > > > > Arnd > > > hi > I would like to keep the mmp_clk_register_apbc to receive the "reg > base" not "reg offset". > It will be aligned with other kind of clock register APIs. > To read out APBC base register from device tree can be added at the > clock-pxa168.c, and it can map the registers and pass to the > mmp_clk_register_apbc. Right, my mistake. The above should have been something like #define APBC_RTC 0x28 apbc_clks[rtc_clk] = mmp_clk_register_apbc(rtc_clk, clk32k, clock_base + APBC_RTC, 10, APBC_POWER_CTRL, mmp_clk_lock); clk_register_clkdev(apbc_clks[rtc_clk], NULL, "sa1100-rtc"); instead, with clock_base pointing to the __iomem token for the clock controller. > Now, i have talked to Haojian who is doing device tree maintainer in > pxa/mmp. This kind of support is not added. > I suggest that after device tree support in clock can be added later > after other functionality of the clock framework is fine. You can do device tree support as a second step, but in this first step, you should already start using ioremap to get the virtual address of the clock controller, rather than hardcoding it. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] hashtable: introduce a small and naive hashtable
On Thu, Aug 02, 2012 at 12:00:33PM +0200, Sasha Levin wrote:
> On 08/02/2012 12:45 AM, Tejun Heo wrote:
> > On Thu, Aug 02, 2012 at 12:41:56AM +0200, Sasha Levin wrote:
> >> How would your DEFINE_HASHTABLE look like if we got for the simple
> >> 'struct hash_table' approach?
> >
> > I think defining a different enclosing anonymous struct which the
> > requested number of array entries and then aliasing the actual
> > hash_table to that symbol should work. It's rather horrible and I'm
> > not sure it's worth the trouble.
>
> I agree that this is probably not worth the trouble.
>
> At the moment I see two alternatives:
>
> 1. Dynamically allocate the hash buckets.
>
> 2. Use the first bucket to store size. Something like the follows:
>
> #define HASH_TABLE(name, bits) \
> struct hlist_head name[1 << bits + 1];
>
> #define HASH_TABLE_INIT (bits) ({name[0].next = bits});
>
> And then have hash_{add,get} just skip the first bucket.
>
>
> While it's not a pretty hack, I don't see a nice way to avoid having to
> dynamically allocate buckets for all cases.
What about using a C99 flexible array member? Kernel style prohibits
variable-length arrays, but I don't think the same rationale applies to
flexible array members.
struct hash_table {
size_t count;
struct hlist_head buckets[];
};
#define DEFINE_HASH_TABLE(name, length) struct hash_table name = { .count =
length, .buckets = { [0 ... (length - 1)] = HLIST_HEAD_INIT } }
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR
On Wed, Aug 01, 2012 at 11:02:42PM -0500, Seth Forshee wrote: > On Wed, Aug 01, 2012 at 04:21:47PM -0700, Greg KH wrote: > > On Wed, Aug 01, 2012 at 05:54:00PM +0100, Matthew Garrett wrote: > > > On Tue, Jul 31, 2012 at 03:32:40PM -0700, Greg KH wrote: > > > > > > > With this series, does the latest MacBook work properly for the Intel > > > > graphics driver? Or is this to resolve some other hardware issue? > > > > > > Apple only seem to provide the ROM for the radeon. Intel normally > > > stands a much better chance of working without a ROM - the only thing it > > > really uses it for is the VBT, and I'm thinking about a couple of ways > > > of handlng that. > > > > Ok, thanks for letting me know. For some reason, the gmux isn't working > > on the latest MacBook Pro so I can't get the vga switched to the Intel > > PCI device. Rumor has it the osx tool at > > http://codykrieger.com/gfxCardStatus will switch into the Intel chip > > until the laptop is hard powered off, so it is possible, just need to > > figure out how to make the hardware do the switch... > > There's a tool that enables some verbose logging which records all the > I/O to the gmux. It works for me with a Macbook Pro 8,2 running OS X > Lion, so you might give it a try. > > All you need to do is clone https://github.com/ah-/switcher.git, build, > and run switcher. If it works you'll see messages prefixed with AGC in > dmesg. Then you can use gfxCardStatus to force some switches between the > integrated and discrete cards. After that you'll want to grab > /var/log/kern.log to get the full logs of everything that happened. > > If you try this and it works, I'd appreciate it if you could send me a > copy of kern.log so I can apply the information towards getting graphics > switching into apple-gmux. Francois, any chance you can ty this and let Seth know the results? I don't have OSX on my machine anymore to do this myself. 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 v2] futex: mark get_robust_list as deprecated
On Fri, Mar 23, 2012 at 8:08 PM, Kees Cook wrote: > Notify get_robust_list users that the syscall is going away. > > Suggested-by: Thomas Gleixner > Signed-off-by: Kees Cook > --- I'm using this system call in an application and noticed that's marked as deprecated now. My application collects all kind of information from crashing programs. It's installed in /proc/sys/kernel/core_pattern. If program X is crashing it executes get_robust_list(X) to get the address of the robust list and reads the list from /proc/X/mem. Is there another way to get the robust list from another program (by it's pid)? -- Thanks, //richard -- 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: [NEW DRIVER V1 0/7] please comment on this new PMIC driver
Thanks Mark, for your very helpful comments on all on the patches in this first submission attempt, I will digest and regurgitate a second attempt as soon as I can. best regards, Tony Olech -Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: 02 August 2012 11:17 To: Opensource [Anthony Olech] Cc: LKML Subject: Re: [NEW DRIVER V1 0/7] please comment on this new PMIC driver On Thu, Aug 02, 2012 at 09:48:58AM +0100, Anthony Olech wrote: > This is submission attempt number 1 to have this driver included in > the linux kernel source tree. This is the driver for the Dialog DA9058. I just noticed that you haven't CCed the maintainers for most of this stuff on your patches... you should always do this if you want review. -- 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] isdnloop: fix and simplify isdnloop_init()
On Thu, Aug 02, 2012 at 12:01:58PM +0800, Fengguang Wu wrote: > Remove the non-sense isdnloop revision transform code, so as to fix: > > [ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7 > [ 22.097508] isdnloop: (loop0) virtual card added > [ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is > corrupted in: 83244972 > [ 22.174400] > [ 22.436157] Pid: 1, comm: swapper Not tainted > 3.5.0-bisect-00018-gfa8bbb1-dirty #129 > [ 22.624071] Call Trace: > [ 22.720558] [] ? CallcNew+0x56/0x56 > [ 22.815248] [] panic+0x110/0x329 > [ 22.914330] [] ? isdnloop_init+0xaf/0xb1 > [ 23.014800] [] ? CallcNew+0x56/0x56 > [ 23.090763] [] __stack_chk_fail+0x2b/0x30 > [ 23.185748] [] isdnloop_init+0xaf/0xb1 > > Signed-off-by: Fengguang Wu > --- > drivers/isdn/isdnloop/isdnloop.c | 13 ++--- > 1 file changed, 2 insertions(+), 11 deletions(-) Please use scripts/get_maintainer.pl to send this to the correct people (hint, you got one address right, lkml, but that was it.) 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] isdnloop: fix and simplify isdnloop_init()
[Add more CC]
On Thu, Aug 02, 2012 at 12:01:58PM +0800, Fengguang Wu wrote:
> Remove the non-sense isdnloop revision transform code, so as to fix:
>
> [ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
> [ 22.097508] isdnloop: (loop0) virtual card added
> [ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is
> corrupted in: 83244972
> [ 22.174400]
> [ 22.436157] Pid: 1, comm: swapper Not tainted
> 3.5.0-bisect-00018-gfa8bbb1-dirty #129
> [ 22.624071] Call Trace:
> [ 22.720558] [] ? CallcNew+0x56/0x56
> [ 22.815248] [] panic+0x110/0x329
> [ 22.914330] [] ? isdnloop_init+0xaf/0xb1
> [ 23.014800] [] ? CallcNew+0x56/0x56
> [ 23.090763] [] __stack_chk_fail+0x2b/0x30
> [ 23.185748] [] isdnloop_init+0xaf/0xb1
>
> Signed-off-by: Fengguang Wu
> ---
> drivers/isdn/isdnloop/isdnloop.c | 13 ++---
> 1 file changed, 2 insertions(+), 11 deletions(-)
>
> --- linux.orig/drivers/isdn/isdnloop/isdnloop.c 2012-05-24
> 19:03:06.748430938 +0800
> +++ linux/drivers/isdn/isdnloop/isdnloop.c2012-08-02 11:57:16.806437909
> +0800
> @@ -16,7 +16,7 @@
> #include
> #include "isdnloop.h"
>
> -static char *revision = "$Revision: 1.11.6.7 $";
> +static char *revision = "1.11.6.7";
> static char *isdnloop_id = "loop0";
>
> MODULE_DESCRIPTION("ISDN4Linux: Pseudo Driver that simulates an ISDN card");
> @@ -1494,16 +1494,7 @@ isdnloop_addcard(char *id1)
> static int __init
> isdnloop_init(void)
> {
> - char *p;
> - char rev[10];
> -
> - if ((p = strchr(revision, ':'))) {
> - strcpy(rev, p + 1);
> - p = strchr(rev, '$');
> - *p = 0;
> - } else
> - strcpy(rev, " ??? ");
> - printk(KERN_NOTICE "isdnloop-ISDN-driver Rev%s\n", rev);
> + printk(KERN_NOTICE "isdnloop-ISDN-driver Rev %s\n", revision);
>
> if (isdnloop_id)
> return (isdnloop_addcard(isdnloop_id));
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] syscalls,x86: Add execveat() system call (v2)
On Thu, Aug 2, 2012 at 11:30 AM, Al Viro wrote: > FWIW, I've just pushed (completely untested) arm and alpha > parts of what I described into signal.git#execve2; x86 is > next. Note that after that sys_execve() is identical on > converted architectures and can be merged; ditto for > kernel_execve(). After I do x86 counterpart, I'll > take those guys to fs/exec.c under ifdef for new __ARCH_HAS_... > (and define it on already converted ones, obviously). > Then your patch goes there, except that implementation > gets put into fs/exec.c, under the same ifdef. And with > current_pt_regs() used instead of the extra argument, > of course. From that point on it can be used on any converted > architecture. OK, that makes sense to me. What would you need from me, and when? Should I just wait for your #ifdef-ed sys_execve() in fs/exec.c, and re-spin the patch based on that? Is there anything else I can/should do in the meantime to make this patch acceptable? Meredydd -- 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] perf, x86: Fix uncore_types_exit section mismatch
From: Borislav Petkov
Fix the following section mismatch:
WARNING: arch/x86/kernel/cpu/built-in.o(.text+0x7ad9): Section mismatch in
reference from the function uncore_types_exit() to the function
.init.text:uncore_type_exit()
The function uncore_types_exit() references
the function __init uncore_type_exit().
This is often because uncore_types_exit lacks a __init
annotation or the annotation of uncore_type_exit is wrong.
caused by 14371cce03c2 ("perf: Add generic PCI uncore PMU device
support").
Cc: Zheng Yan
Cc: Peter Zijlstra
Cc: Ingo Molnar
Link:
http://lkml.kernel.org/r/1339741902-8449-8-git-send-email-zheng.z@intel.com
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 7563fda9f033..a7ccd68aa13a 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -2373,7 +2373,7 @@ static void __init uncore_type_exit(struct
intel_uncore_type *type)
type->attr_groups[1] = NULL;
}
-static void uncore_types_exit(struct intel_uncore_type **types)
+static void __init uncore_types_exit(struct intel_uncore_type **types)
{
int i;
for (i = 0; types[i]; i++)
--
1.7.11.rc1
--
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] isdnloop: fix and simplify isdnloop_init()
On Thu, Aug 02, 2012 at 06:44:56PM +0800, Fengguang Wu wrote: > [Add more CC] That's not going to do much, you just sent them a patch they can't apply without editing by hand :( -- 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] isdnloop: fix and simplify isdnloop_init()
On Thu, Aug 02, 2012 at 06:44:56PM +0800, Fengguang Wu wrote: > [Add more CC] > That's not helpful... Resend the patch to netdev in a way that applies. regards, dan carpenter -- 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:musb:musb_host: Handle highmem in PIO mode
On Thu, Aug 02, 2012 at 12:06:42PM +0530, Virupax Sadashivpetimath wrote: > In case of USB bulk transfer, when himem page > is received, the usb_sg_init function sets the > urb transfer buffer to NULL. When such URB > transfer is handled, kernel crashes in PIO mode. > Handle this by mapping the highmem buffer in PIO mode. > > Signed-off-by: Virupax Sadashivpetimath > Why is this not a problem in any other host controller? Are you sure this fix is correct? Why do you need to modify the struct urb for this? 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] isdnloop: fix and simplify isdnloop_init()
On Thu, Aug 02, 2012 at 01:57:36PM +0300, Dan Carpenter wrote: > On Thu, Aug 02, 2012 at 06:44:56PM +0800, Fengguang Wu wrote: > > [Add more CC] > > > > That's not helpful... Resend the patch to netdev in a way that > applies. OK, sorry... -- 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] isdnloop: fix and simplify isdnloop_init()
Fix a buffer overflow bug by removing the revision transform code.
[ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
[ 22.097508] isdnloop: (loop0) virtual card added
[ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is
corrupted in: 83244972
[ 22.174400]
[ 22.436157] Pid: 1, comm: swapper Not tainted
3.5.0-bisect-00018-gfa8bbb1-dirty #129
[ 22.624071] Call Trace:
[ 22.720558] [] ? CallcNew+0x56/0x56
[ 22.815248] [] panic+0x110/0x329
[ 22.914330] [] ? isdnloop_init+0xaf/0xb1
[ 23.014800] [] ? CallcNew+0x56/0x56
[ 23.090763] [] __stack_chk_fail+0x2b/0x30
[ 23.185748] [] isdnloop_init+0xaf/0xb1
Signed-off-by: Fengguang Wu
---
drivers/isdn/isdnloop/isdnloop.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
--- linux.orig/drivers/isdn/isdnloop/isdnloop.c 2012-05-24 19:03:06.748430938
+0800
+++ linux/drivers/isdn/isdnloop/isdnloop.c 2012-08-02 11:57:16.806437909
+0800
@@ -16,7 +16,7 @@
#include
#include "isdnloop.h"
-static char *revision = "$Revision: 1.11.6.7 $";
+static char *revision = "1.11.6.7";
static char *isdnloop_id = "loop0";
MODULE_DESCRIPTION("ISDN4Linux: Pseudo Driver that simulates an ISDN card");
@@ -1494,16 +1494,7 @@ isdnloop_addcard(char *id1)
static int __init
isdnloop_init(void)
{
- char *p;
- char rev[10];
-
- if ((p = strchr(revision, ':'))) {
- strcpy(rev, p + 1);
- p = strchr(rev, '$');
- *p = 0;
- } else
- strcpy(rev, " ??? ");
- printk(KERN_NOTICE "isdnloop-ISDN-driver Rev%s\n", rev);
+ printk(KERN_NOTICE "isdnloop-ISDN-driver Rev %s\n", revision);
if (isdnloop_id)
return (isdnloop_addcard(isdnloop_id));
--
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: WARNING: at mm/page_alloc.c:4514 free_area_init_node+0x4f/0x37b()
On Thu, Aug 02, 2012 at 08:33:35AM +0900, Minchan Kim wrote:
> Hello Borislav,
>
> On Wed, Aug 01, 2012 at 07:38:37PM +0200, Borislav Petkov wrote:
> > Hi,
> >
> > I'm hitting the WARN_ON in $Subject with latest linus:
> > v3.5-8833-g2d534926205d on a 4-node AMD system. As it looks from
> > dmesg, it is happening on node 0, 1 and 2 but not on 3. Probably the
> > pgdat->nr_zones thing but I'll have to add more dbg code to be sure.
>
> As I look the code quickly, free_area_init_node initializes node_id and
> node_start_pfn doublely. They were initialized by setup_node_data.
>
> Could you test below patch? It's not a totally right way to fix it but
> I want to confirm why it happens.
>
> (I'm on vacation now so please understand that it hard to reach me)
I sincerely hope you're not going to interrupt your vacation because of
this.
:-).
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 889532b..009ac28 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4511,7 +4511,7 @@ void __paginginit free_area_init_node(int nid, unsigned
> long *zones_size,
> pg_data_t *pgdat = NODE_DATA(nid);
>
> /* pg_data_t should be reset to zero when it's allocated */
> - WARN_ON(pgdat->nr_zones || pgdat->node_start_pfn ||
> pgdat->classzone_idx);
> + WARN_ON(pgdat->nr_zones || pgdat->classzone_idx);
>
> pgdat->node_id = nid;
> pgdat->node_start_pfn = node_start_pfn;
Yep, you were right: ->node_start_pfn is set. I added additional debug
output for more info:
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 889532b8e6c1..c249abe4fee2 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4511,7 +4511,17 @@ void __paginginit free_area_init_node(int nid, unsigned
long *zones_size,
pg_data_t *pgdat = NODE_DATA(nid);
/* pg_data_t should be reset to zero when it's allocated */
- WARN_ON(pgdat->nr_zones || pgdat->node_start_pfn ||
pgdat->classzone_idx);
+ WARN_ON(pgdat->nr_zones || pgdat->classzone_idx);
+
+ if (pgdat->node_start_pfn)
+ pr_warn("%s: pgdat->node_start_pfn: %lu\n", __func__,
pgdat->node_start_pfn);
+
+ if (pgdat->nr_zones)
+ pr_warn("%s: pgdat->nr_zones: %d\n", __func__, pgdat->nr_zones);
+
+ if (pgdat->classzone_idx)
+ pr_warn("%s: pgdat->classzone_idx: %d\n", __func__,
pgdat->classzone_idx);
+
pgdat->node_id = nid;
pgdat->node_start_pfn = node_start_pfn;
Here's what it says:
[0.00] On node 0 totalpages: 4193848
[0.00] DMA zone: 64 pages used for memmap
[0.00] DMA zone: 6 pages reserved
[0.00] DMA zone: 3890 pages, LIFO batch:0
[0.00] DMA32 zone: 16320 pages used for memmap
[0.00] DMA32 zone: 798464 pages, LIFO batch:31
[0.00] Normal zone: 52736 pages used for memmap
[0.00] Normal zone: 3322368 pages, LIFO batch:31
[0.00] free_area_init_node: pgdat->node_start_pfn: 4423680 <
[0.00] On node 1 totalpages: 4194304
[0.00] Normal zone: 65536 pages used for memmap
[0.00] Normal zone: 4128768 pages, LIFO batch:31
[0.00] free_area_init_node: pgdat->node_start_pfn: 8617984 <
[0.00] On node 2 totalpages: 4194304
[0.00] Normal zone: 65536 pages used for memmap
[0.00] Normal zone: 4128768 pages, LIFO batch:31
[0.00] free_area_init_node: pgdat->node_start_pfn: 12812288 <
[0.00] On node 3 totalpages: 4194304
[0.00] Normal zone: 65536 pages used for memmap
[0.00] Normal zone: 4128768 pages, LIFO batch:31
[0.00] ACPI: PM-Timer IO Port: 0x2008
[0.00] ACPI: Local APIC address 0xfee0
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
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 v8 5/7] powerpc/85xx: add sleep and deep sleep support
On Tue, Jul 31, 2012 at 09:15:33AM -0500, Kumar Gala wrote:
>
> On Jul 20, 2012, at 7:42 AM, Zhao Chenhui wrote:
>
> > In sleep PM mode, the clocks of e500 core and unused IP blocks is
> > turned off. IP blocks which are allowed to wake up the processor
> > are still running.
> >
> > Some Freescale chips like MPC8536 and P1022 has deep sleep PM mode
> > in addtion to the sleep PM mode.
> >
> > While in deep sleep PM mode, additionally, the power supply is
> > removed from e500 core and most IP blocks. Only the blocks needed
> > to wake up the chip out of deep sleep are ON.
> >
> > This patch supports 32-bit and 36-bit address space.
> >
> > The sleep mode is equal to the Standby state in Linux. The deep sleep
> > mode is equal to the Suspend-to-RAM state of Linux Power Management.
> >
> > Command to enter sleep mode.
> > echo standby > /sys/power/state
> > Command to enter deep sleep mode.
> > echo mem > /sys/power/state
> >
> > Signed-off-by: Dave Liu
> > Signed-off-by: Li Yang
> > Signed-off-by: Jin Qing
> > Signed-off-by: Jerry Huang
> > Cc: Scott Wood
> > Signed-off-by: Zhao Chenhui
> > ---
> > arch/powerpc/Kconfig |2 +-
> > arch/powerpc/include/asm/cacheflush.h |2 +
> > arch/powerpc/kernel/Makefile |3 +
> > arch/powerpc/kernel/l2cache_85xx.S| 56 +++
> > arch/powerpc/platforms/85xx/Makefile |2 +-
> > arch/powerpc/platforms/85xx/sleep.S | 621
> > +
> > arch/powerpc/sysdev/fsl_pmc.c | 98 +-
> > arch/powerpc/sysdev/fsl_soc.h |5 +
> > 8 files changed, 769 insertions(+), 20 deletions(-)
> > create mode 100644 arch/powerpc/kernel/l2cache_85xx.S
> > create mode 100644 arch/powerpc/platforms/85xx/sleep.S
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index a7c6914..9d6de82 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -665,7 +665,7 @@ config FSL_PCI
> > config FSL_PMC
> > bool
> > default y
> > - depends on SUSPEND && (PPC_85xx || PPC_86xx)
> > + depends on SUSPEND && (PPC_85xx || PPC_86xx) && !PPC_E500MC
> > help
> > Freescale MPC85xx/MPC86xx power management controller support
> > (suspend/resume). For MPC83xx see platforms/83xx/suspend.c
> > diff --git a/arch/powerpc/include/asm/cacheflush.h
> > b/arch/powerpc/include/asm/cacheflush.h
> > index b843e35..6c5f1c2 100644
> > --- a/arch/powerpc/include/asm/cacheflush.h
> > +++ b/arch/powerpc/include/asm/cacheflush.h
> > @@ -58,6 +58,8 @@ extern void flush_inval_dcache_range(unsigned long start,
> > unsigned long stop);
> > extern void flush_dcache_phys_range(unsigned long start, unsigned long
> > stop);
> > #endif
> >
> > +extern void flush_dcache_L1(void);
> > +
> > #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
> > do { \
> > memcpy(dst, src, len); \
> > diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> > index 83afacd..0ddef24 100644
> > --- a/arch/powerpc/kernel/Makefile
> > +++ b/arch/powerpc/kernel/Makefile
> > @@ -64,6 +64,9 @@ obj-$(CONFIG_FA_DUMP) += fadump.o
> > ifeq ($(CONFIG_PPC32),y)
> > obj-$(CONFIG_E500) += idle_e500.o
> > endif
> > +ifneq ($(CONFIG_PPC_E500MC),y)
> > +obj-$(CONFIG_PPC_85xx) += l2cache_85xx.o
> > +endif
>
> why do we need this, beyond reduce code size on an e500mc kernel build? If
> so why isn't 85xx/sleep.S doing the same thing?
> - k
>
Yes, it is a little awkward. I have an idea to put e500/e500mc/e5500/e6500
related flush cache routines
into this file, and rename it to cache_fsl_booke.S.
As for 85xx/sleep.S, it is used by fsl_pmc.c. I will use CONFIG_FSL_PMC to
guard it.
-Chenhui
--
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] futex: mark get_robust_list as deprecated
richard -rw- weinberger writes: > On Fri, Mar 23, 2012 at 8:08 PM, Kees Cook wrote: >> Notify get_robust_list users that the syscall is going away. >> >> Suggested-by: Thomas Gleixner >> Signed-off-by: Kees Cook >> --- > > I'm using this system call in an application and noticed that's marked > as deprecated now. > My application collects all kind of information from crashing programs. > It's installed in /proc/sys/kernel/core_pattern. > > If program X is crashing it executes get_robust_list(X) to get the > address of the robust list > and reads the list from /proc/X/mem. > > Is there another way to get the robust list from another program (by it's > pid)? The folks doing checkpoint/restart claim to not need this, so there might be a way either that or they just haven't hit this problem yet. What you are doing sounds like a reasonable use of get_robust_list to me. Eric -- 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] spi: omap2-mcspi: Fix the error handling in probe
The kfree() is taken care of by the spi core (spi_master_release() function) that is called once the last reference to the underlying struct device has been released. So the driver need not call kfree. Also the put was missed in some of the error handling fix the same. There by fixing the missing device_put in some of the error paths. Acked-by: Guenter Roeck Reported-by: Guenter Roeck Signed-off-by: Shubhrajyoti D --- drivers/spi/spi-omap2-mcspi.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index bc47781..b2fb141 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -1228,18 +1228,16 @@ static int __devinit omap2_mcspi_probe(struct platform_device *pdev) status = spi_register_master(master); if (status < 0) - goto err_spi_register; + goto disable_pm; return status; -err_spi_register: - spi_master_put(master); disable_pm: pm_runtime_disable(&pdev->dev); dma_chnl_free: kfree(mcspi->dma_channels); free_master: - kfree(master); + spi_master_put(master); platform_set_drvdata(pdev, NULL); return status; } -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v5 3/6] fsl-dma: change release process of dma descriptor for supporting async_tx
Hi Ira, Here, I want to talk about the issue of dma lock when use dmatest with original patch. I do some tests on p1022ds, 2 cores, 6 dma channels (actually is 4 channels, I am investigating why is 6, but it doesn't matter). I would like to share with you to find something:) First, it is easy to reproduce your issue with 6 channels after up to 200,000 iterations per channel, there is not any response from terminal, then I run top to see the 2 cores load, I found cpu load is 100%, terminal won't update any info after a long time; Second, I only enable 4 channels to run dmatest, I found cpu load is 50% per channel, terminal also update info after a long time; Last, I only enable 1 channel to run dmatest, serial interrupt is attached to core1, and dma channel interrupt is attached to core0, I found terminal is very slow after boot up, but it's only slow whatever how many interrupts raised by the only dma channel (over 900,000 iterations). So I want to know, our test results are same? How do you know dma engine is self locked but not for heavy cpu load, there is no chance to schedule? I also read dmatest.c, there is not any sleep to release cpu (msleep(100) if tx is null). If our test results are same, I think I can explain why your original patch can "fix" the issue of dma lock, because your patch avoid mass cpu data operation. 83xx is old, and P1 series is low end chip of Freescale, this maybe the reason why p4080 cannot reproduce this issue. You can have a test to verify my point if you are available. I will follow this issue until it's resolved. I will let you know if any other new clues. Thanks. > -Original Message- > From: Ira W. Snyder [mailto:i...@ovro.caltech.edu] > Sent: Thursday, August 02, 2012 1:25 AM > To: Liu Qiang-B32616 > Cc: linux-cry...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux- > ker...@vger.kernel.org; dan.j.willi...@gmail.com; Vinod Koul; > herb...@gondor.hengli.com.au; Dan Williams; da...@davemloft.net > Subject: Re: [PATCH v5 3/6] fsl-dma: change release process of dma > descriptor for supporting async_tx > > On Wed, Aug 01, 2012 at 04:49:17PM +0800, qiang@freescale.com wrote: > > From: Qiang Liu > > > > Fix the potential risk when enable config NET_DMA and ASYNC_TX. > > Async_tx is lack of support in current release process of dma > descriptor, > > all descriptors will be released whatever is acked or no-acked by > async_tx, > > so there is a potential race condition when dma engine is uesd by > others > > clients (e.g. when enable NET_DMA to offload TCP). > > > > In our case, a race condition which is raised when use both of talitos > > and dmaengine to offload xor is because napi scheduler will sync all > > pending requests in dma channels, it affects the process of raid > operations > > due to ack_tx is not checked in fsl dma. The no-acked descriptor is > freed > > which is submitted just now, as a dependent tx, this freed descriptor > trigger > > BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit(). > > > > TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf4 CPU: 0 > > GPR00: 0001 ecf41ca0 ee44/921a94a0 003f 0001 c00593e4 > 0001 > > GPR08: a7a7a7a7 0001 045/92002 42028042 100a38d4 > ed576d98 > > GPR16: ed5a11b0 2b162000 0200 046/92000 2d555000 > ed3015e8 c15a7aa0 > > GPR24: c155fc40 ecb63220 ecf41d28 e47/92f640bb0 > ef640c30 ecf41ca0 > > NIP [c02b048c] async_tx_submit+0x6c/0x2b4 > > LR [c02b068c] async_tx_submit+0x26c/0x2b4 > > Call Trace: > > [ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable) > > [ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c > > [ecf41d20] [c0421064] async_copy_data+0xa0/0x17c > > [ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10 > > [ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8 > > [ecf41e90] [c0429080] raid5d+0x3d4/0x5b4 > > [ecf41f40] [c04329b8] md_thread+0x138/0x16c > > [ecf41f90] [c008277c] kthread+0x8c/0x90 > > [ecf41ff0] [c0011630] kernel_thread+0x4c/0x68 > > > > Another major modification in this patch is the change to completed > descriptors, > > there is a potential risk which caused by exception interrupt, all > descriptors > > in ld_running list are seemed completed when an interrupt raised, it > works fine > > under normal condition, but if there is an exception occured, it cannot > work > > as our excepted. Hardware should not depend on s/w list, the right way > is > > to read current descriptor address register to find the last completed > > descriptor. If an interrupt is raised by an error, all descriptors in > ld_running > > should not be seemed finished, or these unfinished descriptors in > ld_running > > will be released wrongly. > > > > A simple way to reproduce, > > Enable dmatest first, then insert some bad descriptors which can > trigger > > Programming Error interrupts before the good descriptors. Last, the > good > > descriptors will be freed before they are processsed because of
Re: [RFC 1/4] hashtable: introduce a small and naive hashtable
On 08/02/2012 12:32 PM, Josh Triplett wrote:
> On Thu, Aug 02, 2012 at 12:00:33PM +0200, Sasha Levin wrote:
>> On 08/02/2012 12:45 AM, Tejun Heo wrote:
>>> On Thu, Aug 02, 2012 at 12:41:56AM +0200, Sasha Levin wrote:
How would your DEFINE_HASHTABLE look like if we got for the simple
'struct hash_table' approach?
>>>
>>> I think defining a different enclosing anonymous struct which the
>>> requested number of array entries and then aliasing the actual
>>> hash_table to that symbol should work. It's rather horrible and I'm
>>> not sure it's worth the trouble.
>>
>> I agree that this is probably not worth the trouble.
>>
>> At the moment I see two alternatives:
>>
>> 1. Dynamically allocate the hash buckets.
>>
>> 2. Use the first bucket to store size. Something like the follows:
>>
>> #define HASH_TABLE(name, bits) \
>> struct hlist_head name[1 << bits + 1];
>>
>> #define HASH_TABLE_INIT (bits) ({name[0].next = bits});
>>
>> And then have hash_{add,get} just skip the first bucket.
>>
>>
>> While it's not a pretty hack, I don't see a nice way to avoid having to
>> dynamically allocate buckets for all cases.
>
> What about using a C99 flexible array member? Kernel style prohibits
> variable-length arrays, but I don't think the same rationale applies to
> flexible array members.
>
> struct hash_table {
> size_t count;
> struct hlist_head buckets[];
> };
>
> #define DEFINE_HASH_TABLE(name, length) struct hash_table name = { .count =
> length, .buckets = { [0 ... (length - 1)] = HLIST_HEAD_INIT } }
The limitation of this approach is that the struct hash_table variable must be
'static', which is a bit limiting - see for example the use of hashtable in
'struct user_namespace'.
>
> - Josh Triplett
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: tps6586x: add support for SYS rail
Device have SYS rail which is always ON. It is system
power bus. LDO5 and LDO_RTC get powered through this rail
internally. Add support for this rail and make the
LDO5/LDO_RTC input supply to "sys".
Update document accordingly.
Signed-off-by: Laxman Dewangan
---
.../devicetree/bindings/regulator/tps6586x.txt | 67
drivers/mfd/tps6586x.c | 16 +
drivers/regulator/tps6586x-regulator.c | 43 -
include/linux/mfd/tps6586x.h |1 +
4 files changed, 99 insertions(+), 28 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/tps6586x.txt
b/Documentation/devicetree/bindings/regulator/tps6586x.txt
index da80c2a..6b7300a 100644
--- a/Documentation/devicetree/bindings/regulator/tps6586x.txt
+++ b/Documentation/devicetree/bindings/regulator/tps6586x.txt
@@ -8,7 +8,8 @@ Required properties:
- gpio-controller: mark the device as a GPIO controller
- regulators: list of regulators provided by this controller, must have
property "regulator-compatible" to match their hardware counterparts:
- sm[0-2], ldo[0-9] and ldo_rtc
+ sys, sm[0-2], ldo[0-9] and ldo_rtc
+- sys-supply: The input supply for SYS.
- vin-sm0-supply: The input supply for the SM0.
- vin-sm1-supply: The input supply for the SM1.
- vin-sm2-supply: The input supply for the SM2.
@@ -20,6 +21,9 @@ Required properties:
Each regulator is defined using the standard binding for regulators.
+Note: LDO5 and LDO_RTC is supplied by SYS regulator internally and driver
+ take care of making proper parent child relationship.
+
Example:
pmu: tps6586x@34 {
@@ -30,6 +34,7 @@ Example:
#gpio-cells = <2>;
gpio-controller;
+ sys-supply = <&some_reg>;
vin-sm0-supply = <&some_reg>;
vin-sm1-supply = <&some_reg>;
vin-sm2-supply = <&some_reg>;
@@ -43,8 +48,18 @@ Example:
#address-cells = <1>;
#size-cells = <0>;
- sm0_reg: regulator@0 {
+ sys_reg: regulator@0 {
reg = <0>;
+ regulator-compatible = "sys";
+ regulator-name = "vdd_sys";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sm0_reg: regulator@1 {
+ reg = <1>;
regulator-compatible = "sm0";
regulator-min-microvolt = < 725000>;
regulator-max-microvolt = <150>;
@@ -52,8 +67,8 @@ Example:
regulator-always-on;
};
- sm1_reg: regulator@1 {
- reg = <1>;
+ sm1_reg: regulator@2 {
+ reg = <2>;
regulator-compatible = "sm1";
regulator-min-microvolt = < 725000>;
regulator-max-microvolt = <150>;
@@ -61,8 +76,8 @@ Example:
regulator-always-on;
};
- sm2_reg: regulator@2 {
- reg = <2>;
+ sm2_reg: regulator@3 {
+ reg = <3>;
regulator-compatible = "sm2";
regulator-min-microvolt = <300>;
regulator-max-microvolt = <455>;
@@ -70,72 +85,72 @@ Example:
regulator-always-on;
};
- ldo0_reg: regulator@3 {
- reg = <3>;
+ ldo0_reg: regulator@4 {
+ reg = <4>;
regulator-compatible = "ldo0";
regulator-name = "PCIE CLK";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
- ldo1_reg: regulator@4 {
- reg = <4>;
+ ldo1_reg: regulator@5 {
+ reg = <5>;
regulator-compatible = "ldo1";
regulator-min-microvolt = < 725000>;
regulator-max-microvolt = <150>;
};
- ldo2_reg: regulator@5 {
- reg = <5>;
+ ldo2_reg: regulator@6
Re: [PATCH] regulator: tps6586x: add support for SYS rail
On Thu, Aug 02, 2012 at 04:46:33PM +0530, Laxman Dewangan wrote:
> +static const unsigned int tps6586x_sys_voltages[] = {
> + 500,
> +};
Is the system rail actually regulated or is it just a nominal 5V?
Normally it's just the raw, unregulated input switched in with FETs or
whatever.
--
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] parisc: fix personality flag check in copy_thread()
On Thu, 2 Aug 2012, James Bottomley wrote: > > Directly comparing task_struct->personality against PER_* is not fully > > correct, as it doesn't take flags potentially stored in top three bytes > > into account. > > > > Analogically, directly forcefully setting personality to PER_LINUX32 or > > PER_LINUX discards any flags stored in the top three bytes. > > > > Signed-off-by: Jiri Kosina > > --- > > > > changed since v1: fix the bit ops to reflect the fact that PER_LINUX is > > actually 0 > > Tell me what you're trying to achieve (or what problem you're trying to > solve), because personality is notoriously tricky. Long story short -- I was debugging a problem where 'setarch --uname-2.6' would not work on s390 on (older) 3.x kernel. Turned out to be a corruption of top bytes of personality across exec() on s390. I was doing quite some over-the-tree grepping during this, and found out that at least parisc, powerpc and sparc64 (davem already queued my patch for this) would under some silently ignore discard the top bytes of personality flags passed to sys_personality(). In case of parsic, let's take a process with current->personality == PER_LINUX32 callling personality(PER_LINUX | UNAME26). The if (personality(current->personality) == PER_LINUX32 && personality == PER_LINUX) personality = PER_LINUX32; would that have no effect, and sys_personality() would be called with (PER_LINUX | UNAME26) instead of PER_LINUX32, just because of UNAME26 being set as well. That doesn't seem really correct. Is it? -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] implement uid and gid mount options for ext2, ext3 and ext4
When using 'real' file systems on removable storage devices such as hard disks or usb sticks people quickly face the problem that their Linux users have different uids on different machines. Therefore one cannot modify or even read files created on a different machine without running chown as root or storing everything with mode 777. Simple file systems such as vfat don't have that problem as they don't store file ownership information and one can pass the uid files should belong to as mount option. The following three patches implement the uid (and gid) mount option for ext2, ext3 and ext4 to make them actually useful on removable media. If a file system is mounted with the uid option all files appear to be owned by the specified uid. Only newly created files actually end up with that uid as owner on disk though. Ownership of existing files cannot be changed permanently if the uid option was specified. Optionally a second uid (diskuid) can be specified. This one is actually written to the file system then. Useful if the filesytem is also used on a system that does not support the uid option. The feature can be used in two ways. Firstly via fstab by having the admin add 'uid=useruid' in the fs_mntops column in addition to the 'user' or 'users' option. Secondly via e.g. udisks which would automatically pass the uid of the calling user as option. Ludwig Nussel (3): implement uid and gid mount options for ext2 implement uid and gid mount options for ext3 implement uid and gid mount options for ext4 Documentation/filesystems/ext2.txt |9 Documentation/filesystems/ext3.txt |9 Documentation/filesystems/ext4.txt |9 fs/ext2/ext2.h |8 +++ fs/ext2/inode.c| 48 +- fs/ext2/super.c| 95 +++- fs/ext3/ext3.h |8 +++ fs/ext3/inode.c| 54 ++-- fs/ext3/super.c| 95 +++- fs/ext4/ext4.h |4 ++ fs/ext4/inode.c| 52 ++-- fs/ext4/super.c| 87 - 12 Dateien geändert, 433 Zeilen hinzugefügt(+), 45 Zeilen entfernt(-) -- 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/
[PATCH 3/3] implement uid and gid mount options for ext4
Signed-off-by: Ludwig Nussel
---
Documentation/filesystems/ext4.txt |9
fs/ext4/ext4.h |4 ++
fs/ext4/inode.c| 52 +++--
fs/ext4/super.c| 87 +++-
4 Dateien geändert, 137 Zeilen hinzugefügt(+), 15 Zeilen entfernt(-)
diff --git a/Documentation/filesystems/ext4.txt
b/Documentation/filesystems/ext4.txt
index 1b7f9ac..b388ab5 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -245,6 +245,15 @@ resgid=n The group ID which may use the reserved
blocks.
resuid=n The user ID which may use the reserved blocks.
+uid=n[:m] Make all files appear to belong to uid n.
+ Useful for e.g. removable media with fstab
+ options 'user,uid=useruid'. The optional second
+ uid m is actually written to the file system.
+
+gid=n[:m] Make all files appear to belong to gid n.
+ The optional second gid m is actually written to
+ the file system.
+
sb=n Use alternate superblock at this location.
quota These options are ignored by the filesystem. They
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index c3411d4..070e3ad 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -1177,6 +1177,10 @@ struct ext4_sb_info {
ext4_fsblk_t s_sb_block;
kuid_t s_resuid;
kgid_t s_resgid;
+ kuid_t s_uid; /* make all files appear to belong to this uid */
+ kuid_t s_diskuid; /* write this uid to disk (if s_uid != 0) */
+ kgid_t s_gid; /* make all files appear to belong to this gid */
+ kgid_t s_diskgid; /* write this gid to disk (if s_gid != 0) */
unsigned short s_mount_state;
unsigned short s_pad;
int s_addr_per_block_bits;
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 6324f74..b02ec15 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3838,8 +3838,14 @@ struct inode *ext4_iget(struct super_block *sb, unsigned
long ino)
i_uid |= le16_to_cpu(raw_inode->i_uid_high) << 16;
i_gid |= le16_to_cpu(raw_inode->i_gid_high) << 16;
}
- i_uid_write(inode, i_uid);
- i_gid_write(inode, i_gid);
+ if (uid_valid(EXT4_SB(sb)->s_uid))
+ inode->i_uid = EXT4_SB(sb)->s_uid;
+ else
+ i_uid_write(inode, i_uid);
+ if (gid_valid(EXT4_SB(sb)->s_gid))
+ inode->i_gid = EXT4_SB(sb)->s_gid;
+ else
+ i_gid_write(inode, i_gid);
set_nlink(inode, le16_to_cpu(raw_inode->i_links_count));
ext4_clear_state_flags(ei); /* Only relevant on 32-bit archs */
@@ -4054,6 +4060,10 @@ static int ext4_do_update_inode(handle_t *handle,
int err = 0, rc, block;
uid_t i_uid;
gid_t i_gid;
+ __le16 uid_low;
+ __le16 gid_low;
+ __le16 uid_high;
+ __le16 gid_high;
/* For fields not not tracking in the in-memory inode,
* initialise them to zero for new inodes. */
@@ -4064,28 +4074,42 @@ static int ext4_do_update_inode(handle_t *handle,
raw_inode->i_mode = cpu_to_le16(inode->i_mode);
i_uid = i_uid_read(inode);
i_gid = i_gid_read(inode);
+ if (uid_valid(EXT4_SB(inode->i_sb)->s_uid))
+ i_uid = from_kuid(&init_user_ns,
EXT4_SB(inode->i_sb)->s_diskuid);
+ if (gid_valid(EXT4_SB(inode->i_sb)->s_gid))
+ i_gid = from_kgid(&init_user_ns,
EXT4_SB(inode->i_sb)->s_diskgid);
if (!(test_opt(inode->i_sb, NO_UID32))) {
- raw_inode->i_uid_low = cpu_to_le16(low_16_bits(i_uid));
- raw_inode->i_gid_low = cpu_to_le16(low_16_bits(i_gid));
+ uid_low = cpu_to_le16(low_16_bits(i_uid));
+ gid_low = cpu_to_le16(low_16_bits(i_gid));
/*
* Fix up interoperability with old kernels. Otherwise, old inodes get
* re-used with the upper 16 bits of the uid/gid intact
*/
if (!ei->i_dtime) {
- raw_inode->i_uid_high =
- cpu_to_le16(high_16_bits(i_uid));
- raw_inode->i_gid_high =
- cpu_to_le16(high_16_bits(i_gid));
+ uid_high = cpu_to_le16(high_16_bits(i_uid));
+ gid_high = cpu_to_le16(high_16_bits(i_gid));
} else {
- raw_inode->i_uid_high = 0;
- raw_inode->i_gid_high = 0;
+ uid_high = 0;
+ gid_high = 0;
}
} else {
- raw_inode->i_uid_low = cpu_to_le16(fs_high2lowuid(i_uid));
- raw_inode->i_gid_low = cpu_to_le16(fs_high2lowgid(i_gid));
- raw_inode->i_uid_high = 0;
- raw_inode->i_gid_high = 0
[PATCH 2/3] implement uid and gid mount options for ext3
Signed-off-by: Ludwig Nussel
---
Documentation/filesystems/ext3.txt |9
fs/ext3/ext3.h |8 +++
fs/ext3/inode.c| 54 ++--
fs/ext3/super.c| 95 +++-
4 Dateien geändert, 149 Zeilen hinzugefügt(+), 17 Zeilen entfernt(-)
diff --git a/Documentation/filesystems/ext3.txt
b/Documentation/filesystems/ext3.txt
index 293855e..bd586d9 100644
--- a/Documentation/filesystems/ext3.txt
+++ b/Documentation/filesystems/ext3.txt
@@ -124,6 +124,15 @@ resgid=n The group ID which may use the reserved
blocks.
resuid=n The user ID which may use the reserved blocks.
+uid=n[:m] Make all files appear to belong to uid n.
+ Useful for e.g. removable media with fstab
+ options 'user,uid=useruid'. The optional second
+ uid m is actually written to the file system.
+
+gid=n[:m] Make all files appear to belong to gid n.
+ The optional second gid m is actually written to
+ the file system.
+
sb=n Use alternate superblock at this location.
quota These options are ignored by the filesystem. They
diff --git a/fs/ext3/ext3.h b/fs/ext3/ext3.h
index e85ff15..401114d 100644
--- a/fs/ext3/ext3.h
+++ b/fs/ext3/ext3.h
@@ -245,6 +245,10 @@ struct ext3_mount_options {
unsigned long s_mount_opt;
kuid_t s_resuid;
kgid_t s_resgid;
+ kuid_t s_uid;
+ kuid_t s_diskuid;
+ kgid_t s_gid;
+ kgid_t s_diskgid;
unsigned long s_commit_interval;
#ifdef CONFIG_QUOTA
int s_jquota_fmt;
@@ -639,6 +643,10 @@ struct ext3_sb_info {
ext3_fsblk_t s_sb_block;
kuid_t s_resuid;
kgid_t s_resgid;
+ kuid_t s_uid; /* make all files appear to belong to this uid */
+ kuid_t s_diskuid; /* write this uid to disk (if s_uid != 0) */
+ kgid_t s_gid; /* make all files appear to belong to this gid */
+ kgid_t s_diskgid; /* write this gid to disk (if s_gid != 0) */
unsigned short s_mount_state;
unsigned short s_pad;
int s_addr_per_block_bits;
diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c
index 9a4a5c4..c1176ae 100644
--- a/fs/ext3/inode.c
+++ b/fs/ext3/inode.c
@@ -2915,8 +2915,14 @@ struct inode *ext3_iget(struct super_block *sb, unsigned
long ino)
i_uid |= le16_to_cpu(raw_inode->i_uid_high) << 16;
i_gid |= le16_to_cpu(raw_inode->i_gid_high) << 16;
}
- i_uid_write(inode, i_uid);
- i_gid_write(inode, i_gid);
+ if (uid_valid(EXT3_SB(sb)->s_uid))
+ inode->i_uid = EXT3_SB(sb)->s_uid;
+ else
+ i_uid_write(inode, i_uid);
+ if (gid_valid(EXT3_SB(sb)->s_gid))
+ inode->i_gid = EXT3_SB(sb)->s_gid;
+ else
+ i_gid_write(inode, i_gid);
set_nlink(inode, le16_to_cpu(raw_inode->i_links_count));
inode->i_size = le32_to_cpu(raw_inode->i_size);
inode->i_atime.tv_sec = (signed)le32_to_cpu(raw_inode->i_atime);
@@ -3074,6 +3080,10 @@ static int ext3_do_update_inode(handle_t *handle,
int err = 0, rc, block;
uid_t i_uid;
gid_t i_gid;
+ __le16 uid_low;
+ __le16 gid_low;
+ __le16 uid_high;
+ __le16 gid_high;
again:
/* we can't allow multiple procs in here at once, its a bit racey */
@@ -3088,30 +3098,42 @@ again:
raw_inode->i_mode = cpu_to_le16(inode->i_mode);
i_uid = i_uid_read(inode);
i_gid = i_gid_read(inode);
+ if (uid_valid(EXT3_SB(inode->i_sb)->s_uid))
+ i_uid = from_kuid(&init_user_ns,
EXT3_SB(inode->i_sb)->s_diskuid);
+ if (gid_valid(EXT3_SB(inode->i_sb)->s_gid))
+ i_gid = from_kgid(&init_user_ns,
EXT3_SB(inode->i_sb)->s_diskgid);
if(!(test_opt(inode->i_sb, NO_UID32))) {
- raw_inode->i_uid_low = cpu_to_le16(low_16_bits(i_uid));
- raw_inode->i_gid_low = cpu_to_le16(low_16_bits(i_gid));
+ uid_low = cpu_to_le16(low_16_bits(i_uid));
+ gid_low = cpu_to_le16(low_16_bits(i_gid));
/*
* Fix up interoperability with old kernels. Otherwise, old inodes get
* re-used with the upper 16 bits of the uid/gid intact
*/
if(!ei->i_dtime) {
- raw_inode->i_uid_high =
- cpu_to_le16(high_16_bits(i_uid));
- raw_inode->i_gid_high =
- cpu_to_le16(high_16_bits(i_gid));
+ uid_high = cpu_to_le16(high_16_bits(i_uid));
+ gid_high = cpu_to_le16(high_16_bits(i_gid));
} else {
- raw_inode->i_uid_high = 0;
- raw_inode->i_gid_high = 0;
+ uid_high = 0;
+
