Re: [PATCH 12/16] drivers/cpufreq/pxa3xx-cpufreq.c: Avoid using ARRAY_AND_SIZE(e) as a function argument
On 12 August 2013 11:18, Julia Lawall wrote: > On Mon, 12 Aug 2013, Viresh Kumar wrote: > >> On 12 August 2013 11:15, Julia Lawall wrote: >> > I'm not sure to understand the sense of the question. >> >> I was talking about this :) >> >> (http://coccinelle.lip6.fr/) > > The URL of the tool if you can't figure out all the funny notation below. Okay ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tile: support kprobes on tilegx
Hello Tony,
(2013/08/10 4:08), Tony Lu wrote:
> This change includes support for Kprobes, Jprobes and Return Probes.
Thank you for the effort, this looks good for the first step.
However, it seems this only supports instructions which doesn't touch
the execution path. I don't know tile ISA, but it should have jump/branch/
call/return etc. Those should be fixed after singlestep out-of-line in
resume_execution(). Or, kprobes should reject to probe on such instructions
by arch_prepare_kprobe().
> +int __kprobes arch_prepare_kprobe(struct kprobe *p)
> +{
> + unsigned long addr = (unsigned long)p->addr;
> +
> + if (addr & (sizeof(kprobe_opcode_t) - 1))
> + return -EINVAL;
> +
> + /* insn: must be on special executable page on tile. */
> + p->ainsn.insn = get_insn_slot();
> + if (!p->ainsn.insn)
> + return -ENOMEM;
> +
> + /*
> + * In the kprobe->ainsn.insn[] array we store the original
> + * instruction at index zero and a break trap instruction at
> + * index one.
> + */
> + memcpy(>ainsn.insn[0], p->addr, sizeof(kprobe_opcode_t));
> + p->ainsn.insn[1] = breakpoint2_insn;
> + p->opcode = *p->addr;
> +
> + return 0;
> +}
[...]
> +/*
> + * Called after single-stepping. p->addr is the address of the
> + * instruction whose first byte has been replaced by the "break 0"
> + * temporarily put back the original opcode to single-step, we
> + * single-stepped a copy of the instruction. The address of this
> + * copy is p->ainsn.insn.
> + *
> + * This function prepares to return from the post-single-step
> + * breakpoint trap.
> + */
> +static void __kprobes resume_execution(struct kprobe *p,
> +struct pt_regs *regs,
> +struct kprobe_ctlblk *kcb)
> +{
> + unsigned long orig_pc = kcb->kprobe_saved_pc;
> + regs->pc = orig_pc + 8;
> +}
> +
I recommend you to fix that, at least filter out non-supported instructions
by arch_prepare_kprobe(), because no other users don't know which
instruction they can probe. :)
Thank you again!
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/16] drivers/cpufreq/pxa3xx-cpufreq.c: Avoid using ARRAY_AND_SIZE(e) as a function argument
On Mon, 12 Aug 2013, Viresh Kumar wrote: > On 12 August 2013 11:15, Julia Lawall wrote: > > I'm not sure to understand the sense of the question. > > I was talking about this :) > > (http://coccinelle.lip6.fr/) The URL of the tool if you can't figure out all the funny notation below. julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 12/16] drivers/cpufreq/pxa3xx-cpufreq.c: Avoid using ARRAY_AND_SIZE(e) as a function argument
On 12 August 2013 11:15, Julia Lawall wrote: > I'm not sure to understand the sense of the question. I was talking about this :) (http://coccinelle.lip6.fr/) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 12/16] drivers/cpufreq/pxa3xx-cpufreq.c: Avoid using ARRAY_AND_SIZE(e) as a function argument
On Mon, 12 Aug 2013, Viresh Kumar wrote: > On 11 August 2013 22:21, Julia Lawall wrote: > > From: Julia Lawall > > > > Replace ARRAY_AND_SIZE(e) in function argument position to avoid hiding the > > arity of the called function. > > Makes sense. > > > The semantic match that makes this change is as follows: > > (http://coccinelle.lip6.fr/) > > What is this doing here? I'm not sure to understand the sense of the question. The semantic patch explains exactly what considerations were used when making the transformation. That is, any function call, having a call to ARRAY_AND_SIZE as an argument is rewritten to replace the call to ARRAY_AND_SIZE with the correspondingtwo arguments. The transformation was performed entirely automatically, although in a lot of cases it was necessary to add newlines afterwards. julia > > // > > @@ > > expression e,f; > > @@ > > > > f(..., > > - ARRAY_AND_SIZE(e) > > + e,ARRAY_SIZE(e) > > ,...) > > // > > > > Signed-off-by: Julia Lawall > > > > --- > > Not compiled. > > > > drivers/cpufreq/pxa3xx-cpufreq.c |6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > Acked-by: Viresh Kumar > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD FX-4130 part only runs at 2.6/3.4GHz
On 10 August 2013 03:12, Pavel Machek wrote: > Hi! > > I have > > DMI: Gigabyte Technology Co., Ltd. GA-78LMT-S2P/GA-78LMT-S2P, BIOS F3 > 10/18/2012 > > mainboard and AMD FX-4130 processor. > > processor : 3 > vendor_id : AuthenticAMD > cpu family : 21 > model : 1 > model name: AMD FX(tm)-4130 Quad-Core Processor > stepping : 2 > microcode : 0x6000629 > cpu MHz : 1400.000 > cache size : 2048 KB > > ...but it seems to run slower than it should. According to box, stock > frequency should be 3.8GHz, with 3.9GHz turbo, but it only goes to > 3.4GHz (and seems to only go there in "turbo" mode -- not all cores at > once.) > > Kernel is: > > Linux version 3.11.0-rc2 (pavel@Elf) (gcc version 4.4.5 (Debian > 4.4.5-8) ) #320 SMP Fri Aug 9 23:22:58 CEST 2013 > > cpufreq says: > > pavel@Elf:~$ cat > /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies > 340 280 260 180 140 So, cpufreq doesn't have this frequency to set.. Which cpufreq driver are you using? > pavel@Elf:~$ > > Suspicious dmesg: > > ACPI Warning: \_PR_.C000._PSS: SubPackage[0,1] - suspicious power > dissipation values (20130517/nsrepair2-710) > acpi-cpufreq: overriding BIOS provided _PSD data > ACPI Warning: \_PR_.C001._PSS: SubPackage[0,1] - suspicious power > dissipation values (20130517/nsrepair2-710) > ACPI Warning: \_PR_.C002._PSS: SubPackage[0,1] - suspicious power > dissipation values (20130517/nsrepair2-710) > ACPI Warning: \_PR_.C003._PSS: SubPackage[0,1] - suspicious power > dissipation values (20130517/nsrepair2-710) > ALSA device list: > #0: HDA ATI SB at 0xfe024000 irq 16 > #1: HD-Audio Generic at 0xfdffc000 irq 19 > > I can manually tweak multiplier in the BIOS to get to 3812 (or so) > MHz, but the machine does not seem stable in that setting. > > Any idea what is going on? > > Thanks, > Pavel > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/16] drivers/cpufreq/pxa3xx-cpufreq.c: Avoid using ARRAY_AND_SIZE(e) as a function argument
On 11 August 2013 22:21, Julia Lawall wrote: > From: Julia Lawall > > Replace ARRAY_AND_SIZE(e) in function argument position to avoid hiding the > arity of the called function. Makes sense. > The semantic match that makes this change is as follows: > (http://coccinelle.lip6.fr/) What is this doing here? > // > @@ > expression e,f; > @@ > > f(..., > - ARRAY_AND_SIZE(e) > + e,ARRAY_SIZE(e) > ,...) > // > > Signed-off-by: Julia Lawall > > --- > Not compiled. > > drivers/cpufreq/pxa3xx-cpufreq.c |6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [cpufreq] BUG: unable to handle kernel NULL pointer dereference at (null)
On Sun, Aug 11, 2013 at 11:23 AM, Fengguang Wu wrote: > Greetings, > > I got the below dmesg and the first bad commit is > > commit 01e3e82efc6742d5cf7ba14fb7a9bea318b386d8 > Author: Lukasz Majewski > Date: Tue Aug 6 22:53:08 2013 +0530 > > cpufreq: Store cpufreq policies in a list > > Policies available in the cpufreq framework are now linked together. > They are accessible via cpufreq_policy_list defined in the cpufreq > core. > > Signed-off-by: Lukasz Majewski > Signed-off-by: Myungjoo Ham > Signed-off-by: Viresh Kumar > Signed-off-by: Rafael J. Wysocki Its already fixed by: c88a1f8b96e7384627b918dfabbfc0c615a4a914 in Rafael's bleeding-edge branch.. Thanks for reporting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] net: Add MOXA ART SoCs ethernet driver
From: Jonas Jensen Date: Thu, 8 Aug 2013 13:34:54 +0200 > The MOXA UC-711X hardware(s) has an ethernet controller that seem > to be developed internally. The IC used is "RTL8201CP". > > Since there is no public documentation, this driver is mostly the > one published by MOXA that has been heavily cleaned up / ported > from linux 2.6.9. > > Signed-off-by: Jonas Jensen Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] kprobes: Use KSYM_NAME_LEN to size identifier buffers
On Sat, Aug 10, 2013 at 05:55:33PM -0700, Andi Kleen wrote:
> From: Joe Mario
>
> Use KSYM_NAME_LEN to size identifier buffers, so that it can
> be easier increased.
>
> Cc: ana...@in.ibm.com
> Signed-off-by: Joe Mario
> Signed-off-by: Andi Kleen
Acked-by: Ananth N Mavinakayanahalli
> ---
> kernel/kprobes.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 6e33498..e174daf 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -2083,7 +2083,7 @@ static int __init init_kprobes(void)
> {
> int i, err = 0;
> unsigned long offset = 0, size = 0;
> - char *modname, namebuf[128];
> + char *modname, namebuf[KSYM_NAME_LEN];
> const char *symbol_name;
> void *addr;
> struct kprobe_blackpoint *kb;
> @@ -2209,7 +2209,7 @@ static int __kprobes show_kprobe_addr(struct seq_file
> *pi, void *v)
> const char *sym = NULL;
> unsigned int i = *(loff_t *) v;
> unsigned long offset = 0;
> - char *modname, namebuf[128];
> + char *modname, namebuf[KSYM_NAME_LEN];
>
> head = _table[i];
> preempt_disable();
> --
> 1.8.3.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 v3 02/12] ARM: edma: Don't clear EMR of channel in edma_stop
On Sun, Aug 11, 2013 at 11:25 PM, Sekhar Nori wrote: > On 8/8/2013 5:19 PM, Sekhar Nori wrote: >> On Monday 05 August 2013 09:44 PM, Joel Fernandes wrote: >>> We certainly don't want error conditions to be cleared any other >>> place but the EDMA error handler, as this will make us 'forget' >>> about missed events we might need to know errors have occurred. >>> >>> This fixes a race condition where the EMR was being cleared >>> by the transfer completion interrupt handler. >>> >>> Basically, what was happening was: >>> >>> Missed event >>> | >>> | >>> V >>> SG1-SG2-SG3-Null >>> \ >>> \__TC Interrupt (Almost same time as ARM is executing >>> TC interrupt handler, an event got missed and also forgotten >>> by clearing the EMR). >>> >>> This causes the following problems: >>> >>> 1. >>> If error interrupt is also pending and TC interrupt clears the EMR >>> by calling edma_stop as has been observed in the edma_callback function, >>> the ARM will execute the error interrupt even though the EMR is clear. >>> As a result, the dma_ccerr_handler returns IRQ_NONE. If this happens >>> enough number of times, IRQ subsystem disables the interrupt thinking >>> its spurious which makes error handler never execute again. >>> >>> 2. >>> Also even if error handler doesn't return IRQ_NONE, the removing of EMR >>> removes the knowledge about which channel had a missed event, and thus >>> a manual trigger on such channels cannot be performed. >>> >>> The EMR is ultimately being cleared by the Error interrupt handler >>> once it is handled so we remove code that does it in edma_stop and >>> allow it to happen there. >>> >>> Signed-off-by: Joel Fernandes >> >> Queuing this for v3.11 fixes. While committing, I changed the headline >> to remove capitalization and made it more readable by removing register >> level details. The new headline is: >> >> ARM: edma: don't clear missed events in edma_stop() > > Forgot to ask, should this be tagged for stable? IOW, how serious is > this race in current kernel (without the entire series applied)? I have > never observed it myself - so please provide details how easy/difficult > it is to hit this condition. The race was uncovered by recent EDMA patch series, So this patch can go in for next kernel release as such, I am not aware of any other DMA user that maybe uncovering the race condition. Thanks, -Joel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/12] ARM: edma: Don't clear EMR of channel in edma_stop
On 8/8/2013 5:19 PM, Sekhar Nori wrote: > On Monday 05 August 2013 09:44 PM, Joel Fernandes wrote: >> We certainly don't want error conditions to be cleared any other >> place but the EDMA error handler, as this will make us 'forget' >> about missed events we might need to know errors have occurred. >> >> This fixes a race condition where the EMR was being cleared >> by the transfer completion interrupt handler. >> >> Basically, what was happening was: >> >> Missed event >> | >> | >> V >> SG1-SG2-SG3-Null >> \ >> \__TC Interrupt (Almost same time as ARM is executing >> TC interrupt handler, an event got missed and also forgotten >> by clearing the EMR). >> >> This causes the following problems: >> >> 1. >> If error interrupt is also pending and TC interrupt clears the EMR >> by calling edma_stop as has been observed in the edma_callback function, >> the ARM will execute the error interrupt even though the EMR is clear. >> As a result, the dma_ccerr_handler returns IRQ_NONE. If this happens >> enough number of times, IRQ subsystem disables the interrupt thinking >> its spurious which makes error handler never execute again. >> >> 2. >> Also even if error handler doesn't return IRQ_NONE, the removing of EMR >> removes the knowledge about which channel had a missed event, and thus >> a manual trigger on such channels cannot be performed. >> >> The EMR is ultimately being cleared by the Error interrupt handler >> once it is handled so we remove code that does it in edma_stop and >> allow it to happen there. >> >> Signed-off-by: Joel Fernandes > > Queuing this for v3.11 fixes. While committing, I changed the headline > to remove capitalization and made it more readable by removing register > level details. The new headline is: > > ARM: edma: don't clear missed events in edma_stop() Forgot to ask, should this be tagged for stable? IOW, how serious is this race in current kernel (without the entire series applied)? I have never observed it myself - so please provide details how easy/difficult it is to hit this condition. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Should unprivileged linkat(..., AT_EMPTY_PATH) work on O_TMPFILE files?
"Aneesh Kumar K.V" writes:
> Andy Lutomirski writes:
>
>> On Sun, Aug 11, 2013 at 9:45 AM, Aneesh Kumar K.V
>> wrote:
>>> Andy Lutomirski writes:
>>>
The change:
commit f4e0c30c191f87851c4a53454abb55ee276f4a7e
Author: Al Viro
Date: Tue Jun 11 08:34:36 2013 +0400
allow the temp files created by open() to be linked to
O_TMPFILE | O_CREAT => linkat() with AT_SYMLINK_FOLLOW and
/proc/self/fd/
as oldpath (i.e. flink()) will create a link
O_TMPFILE | O_CREAT | O_EXCL => ENOENT on attempt to link those guys
Signed-off-by: Al Viro
makes it possible to hardlink an O_TMPFILE file using procfs. Should
linkat(fd, "", newdirfd, newpath, AT_EMPTY_PATH) also work?
AFAICS it currently requires CAP_DAC_READ_SEARCH, but I'm a bit
confused as to why linkat(..., AT_EMPTY_PATH) should have a stricter
check than linkat(AT_FDCWD, "/proc/self/fd/n", ...,
AT_SYMLINK_FOLLOW), (The relevant change is
11a7b371b64ef39fc5fb1b6f2218eef7c4d035e3.)
FWIW, this program works on Linux 3.9, which makes me doubt that the
security restriction on linkat is doing any good:
#include
#include
#include
#include
int main(int argc, char **argv)
{
char buf[128];
if (argc != 3)
errx(1, "Usage: flink FD PATH");
sprintf(buf, "/proc/self/fd/%d", atoi(argv[1]));
if (linkat(AT_FDCWD, buf, AT_FDCWD, argv[2], AT_SYMLINK_FOLLOW) != 0)
err(1, "linkat");
return 0;
}
Removing the check from the AT_EMPTY_PATH case would simplify code
that wants to write a file, fsync it, and then flink it in.
>>>
>>> I understand that this got merged upstream. But in case of the above
>>> test we would walk the path pointed by /proc/self/fd/ right ?
>>>
>>> ie,
>>>
>>> 20 -> /home/no-access/k
>>>
>>> will the above test work ? Now if i pass the '20' to another application
>>> I can affectively create a hardlink to that outside no-access and if k
>>> happens to have 'r' for others, then everybody will be able to read
>>> right ?. I understand that limitting the read access based on directory
>>> permission is not a good idea. But aren't we expected to keep that ?
>>
>> The symlinks in /proc/self/fd are rather magical and don't actually
>> walk the path. Give it a try :)
>>
>
> How about fd passed from one application to another(say from a1 to
> a2). a2 won't have read permission on /proc/a1/fd/ and also don't know
> the value of file descriptor he should use right ? Will the /proc/self/fd
> method work in such case ? IIUC with AT_EMPTY_PATH a2 can create the
> link in the above case right ? So if /proc/self/fd doesn't work should
> we allow that ?
Hmm I guess a2 will be able to use /proc/a2/fd/ to create a
link ?
-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Should unprivileged linkat(..., AT_EMPTY_PATH) work on O_TMPFILE files?
Andy Lutomirski writes:
> On Sun, Aug 11, 2013 at 9:45 AM, Aneesh Kumar K.V
> wrote:
>> Andy Lutomirski writes:
>>
>>> The change:
>>>
>>> commit f4e0c30c191f87851c4a53454abb55ee276f4a7e
>>> Author: Al Viro
>>> Date: Tue Jun 11 08:34:36 2013 +0400
>>>
>>> allow the temp files created by open() to be linked to
>>>
>>> O_TMPFILE | O_CREAT => linkat() with AT_SYMLINK_FOLLOW and
>>> /proc/self/fd/
>>> as oldpath (i.e. flink()) will create a link
>>> O_TMPFILE | O_CREAT | O_EXCL => ENOENT on attempt to link those guys
>>>
>>> Signed-off-by: Al Viro
>>>
>>> makes it possible to hardlink an O_TMPFILE file using procfs. Should
>>> linkat(fd, "", newdirfd, newpath, AT_EMPTY_PATH) also work?
>>>
>>> AFAICS it currently requires CAP_DAC_READ_SEARCH, but I'm a bit
>>> confused as to why linkat(..., AT_EMPTY_PATH) should have a stricter
>>> check than linkat(AT_FDCWD, "/proc/self/fd/n", ...,
>>> AT_SYMLINK_FOLLOW), (The relevant change is
>>> 11a7b371b64ef39fc5fb1b6f2218eef7c4d035e3.)
>>>
>>> FWIW, this program works on Linux 3.9, which makes me doubt that the
>>> security restriction on linkat is doing any good:
>>>
>>> #include
>>> #include
>>> #include
>>> #include
>>>
>>> int main(int argc, char **argv)
>>> {
>>> char buf[128];
>>>
>>> if (argc != 3)
>>> errx(1, "Usage: flink FD PATH");
>>>
>>> sprintf(buf, "/proc/self/fd/%d", atoi(argv[1]));
>>> if (linkat(AT_FDCWD, buf, AT_FDCWD, argv[2], AT_SYMLINK_FOLLOW) != 0)
>>> err(1, "linkat");
>>> return 0;
>>> }
>>>
>>>
>>> Removing the check from the AT_EMPTY_PATH case would simplify code
>>> that wants to write a file, fsync it, and then flink it in.
>>
>> I understand that this got merged upstream. But in case of the above
>> test we would walk the path pointed by /proc/self/fd/ right ?
>>
>> ie,
>>
>> 20 -> /home/no-access/k
>>
>> will the above test work ? Now if i pass the '20' to another application
>> I can affectively create a hardlink to that outside no-access and if k
>> happens to have 'r' for others, then everybody will be able to read
>> right ?. I understand that limitting the read access based on directory
>> permission is not a good idea. But aren't we expected to keep that ?
>
> The symlinks in /proc/self/fd are rather magical and don't actually
> walk the path. Give it a try :)
>
How about fd passed from one application to another(say from a1 to
a2). a2 won't have read permission on /proc/a1/fd/ and also don't know
the value of file descriptor he should use right ? Will the /proc/self/fd
method work in such case ? IIUC with AT_EMPTY_PATH a2 can create the
link in the above case right ? So if /proc/self/fd doesn't work should
we allow that ?
-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [for-next-3.11][PATCH 4/4] tracing: Fix reset of time stamps during trace_clock changes
On Thu, Aug 08, 2013 at 12:12:06PM -0400, Steven Rostedt wrote: > Greg, > > I'm testing the backports, and I found that this patch depends on commit > 10246fa35d4ffdfe472185d4cbf9c2dfd9a9f023 "tracing: Use flag > buffer_disabled for irqsoff tracer" > > Please add that to 3.10 before applying this fix. Oops, I sent out the "FAILED" email before seeing this, sorry about that. I've applied this patch, and now the original one applies as well, 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] zram: bug fix: delay lock holding in zram_slot_free_noity
Hello Greg, On Fri, Aug 09, 2013 at 04:39:08PM -0700, Greg Kroah-Hartman wrote: > On Tue, Aug 06, 2013 at 01:26:34AM +0900, Minchan Kim wrote: > > On Mon, Aug 05, 2013 at 04:18:34PM +0900, Minchan Kim wrote: > > > I was preparing to promote zram and it was almost done. > > > Before sending patch, I tried to test and eyebrows went up. > > > > > > [1] introduced down_write in zram_slot_free_notify to prevent race > > > between zram_slot_free_notify and zram_bvec_[read|write]. The race > > > could happen if somebody who has right permission to open swap device > > > is reading swap device while it is used by swap in parallel. > > > > > > However, zram_slot_free_notify is called with holding spin_lock of > > > swap layer so we shouldn't avoid holing mutex. Otherwise, lockdep > > > warns it. > > > > > > I guess, best solution is to redesign zram lock scheme totally but > > > we are on the verge of promoting so it's not desirable to change a lot > > > critical code and such big change isn't good shape for backporting to > > > stable trees so I think the simple patch is best at the moment. > > > > > > [1] [57ab0485, zram: use zram->lock to protect zram_free_page() > > > in swap free notify path] > > > > > > Cc: Jiang Liu > > > Cc: Nitin Gupta > > > Cc: sta...@vger.kernel.org > > > Signed-off-by: Minchan Kim > > > --- > > > drivers/staging/zram/zram_drv.c | 15 ++- > > > 1 file changed, 14 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/staging/zram/zram_drv.c > > > b/drivers/staging/zram/zram_drv.c > > > index 7ebf91d..7b574c4 100644 > > > --- a/drivers/staging/zram/zram_drv.c > > > +++ b/drivers/staging/zram/zram_drv.c > > > @@ -440,6 +440,13 @@ static int zram_bvec_write(struct zram *zram, struct > > > bio_vec *bvec, u32 index, > > > goto out; > > > } > > > > > > + /* > > > + * zram_slot_free_notify could miss free so that let's > > > + * double check. > > > + */ > > > + if (unlikely(meta->table[index].handle)) > > > + zram_free_page(zram, index); > > > + > > > ret = lzo1x_1_compress(uncmem, PAGE_SIZE, src, , > > > meta->compress_workmem); > > > > > > @@ -727,7 +734,13 @@ static void zram_slot_free_notify(struct > > > block_device *bdev, > > > struct zram *zram; > > > > > > zram = bdev->bd_disk->private_data; > > > - down_write(>lock); > > > + /* > > > + * The function is called in atomic context so down_write should > > > + * be prohibited. If we couldn't hold a mutex, the free could be > > > + * handled by zram_bvec_write later when same index is overwritten. > > > + */ > > > + if (!down_write_trylock(>lock)) > > > + return; > > > zram_free_page(zram, index); > > > up_write(>lock); > > > atomic64_inc(>stats.notify_free); > > > -- > > > 1.7.9.5 > > > > > > > How about this version? > > I'm guessing you tested it out? If so, please resend in a format that I > can apply it in. Sure, I will post soon. Thanks! -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2 0/4] mm: reclaim zbud pages on migration and compaction
Hello Benjamin,
On Sun, Aug 11, 2013 at 11:16:47PM -0400, Benjamin LaHaise wrote:
> Hello Minchan,
>
> On Mon, Aug 12, 2013 at 11:25:35AM +0900, Minchan Kim wrote:
> > Hello,
> >
> > On Fri, Aug 09, 2013 at 12:22:16PM +0200, Krzysztof Kozlowski wrote:
> > > Hi,
> > >
> > > Currently zbud pages are not movable and they cannot be allocated from CMA
> > > region. These patches try to address the problem by:
> >
> > The zcache, zram and GUP pages for memory-hotplug and/or CMA are
> > same situation.
> >
> > > 1. Adding a new form of reclaim of zbud pages.
> > > 2. Reclaiming zbud pages during migration and compaction.
> > > 3. Allocating zbud pages with __GFP_RECLAIMABLE flag.
> >
> > So I'd like to solve it with general approach.
> >
> > Each subsystem or GUP caller who want to pin pages long time should
> > create own migration handler and register the page into pin-page
> > control subsystem like this.
> >
> > driver/foo.c
> >
> > int foo_migrate(struct page *page, void *private);
> >
> > static struct pin_page_owner foo_migrate = {
> > .migrate = foo_migrate;
> > };
> >
> > int foo_allocate()
> > {
> > struct page *newpage = alloc_pages();
> > set_pinned_page(newpage, _migrate);
> > }
> >
> > And in compaction.c or somewhere where want to move/reclaim the page,
> > general VM can ask to owner if it founds it's pinned page.
> >
> > mm/compaction.c
> >
> > if (PagePinned(page)) {
> > struct pin_page_info *info = get_page_pin_info(page);
> > info->migrate(page);
> >
> > }
> >
> > Only hurdle for that is that we should introduce a new page flag and
> > I believe if we all agree this approch, we can find a solution at last.
> >
> > What do you think?
>
> I don't like this approach. There will be too many collisions in the
> hash that's been implemented (read: I don't think you can get away with
Yeb. That's why I'd like to change it with radix tree of pfn as
I mentioned as comment(just used hash for fast prototyping without big
considering).
> a naive implementation for core infrastructure that has to suite all
> users), you've got a global spin lock, and it doesn't take into account
I think batching-drain of pinned page would be sufficient for avoiding
global spinlock problem because we have been used it with page-allocator
which is one of most critical hotpath.
> NUMA issues. The address space migratepage method doesn't have those
NUMA issues? Could you elaborate it a bit?
> issues (at least where it is usable as in aio's use-case).
>
> If you're going to go down this path, you'll have to decide if *all* users
> of pinned pages are going to have to subscribe to supporting the un-pinning
> of pages, and that means taking a real hard look at how O_DIRECT pins pages.
> Once you start thinking about that, you'll find that addressing the
> performance concerns is going to be an essential part of any design work to
> be done in this area.
True. The patch I included just shows the cocnept so I didn't consider any
performance critical part but if we all agree this arpproch does make sense
and we can implement little overhead, I will step into next phase to enhance
performance.
Thanks for the input, Ben!
>
> -ben
> --
> "Thought is the essence of where you are now."
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] FMC: Staticize local symbols
This local symbol is used only in this file.
Fix the following sparse warnings:
drivers/fmc/fmc-write-eeprom.c:106:5: warning: symbol 'fwe_probe' was not
declared. Should it be static?
drivers/fmc/fmc-write-eeprom.c:147:5: warning: symbol 'fwe_remove' was not
declared. Should it be static?
Signed-off-by: Jingoo Han
---
drivers/fmc/fmc-write-eeprom.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/fmc/fmc-write-eeprom.c b/drivers/fmc/fmc-write-eeprom.c
index 2cc680d..ee5b479 100644
--- a/drivers/fmc/fmc-write-eeprom.c
+++ b/drivers/fmc/fmc-write-eeprom.c
@@ -103,7 +103,7 @@ static int fwe_run(struct fmc_device *fmc, const struct
firmware *fw, char *s)
* difficult to know in advance when probing the first card if others
* are there.
*/
-int fwe_probe(struct fmc_device *fmc)
+static int fwe_probe(struct fmc_device *fmc)
{
int err, index = 0;
const struct firmware *fw;
@@ -144,7 +144,7 @@ int fwe_probe(struct fmc_device *fmc)
return 0;
}
-int fwe_remove(struct fmc_device *fmc)
+static int fwe_remove(struct fmc_device *fmc)
{
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] powerpc/perf: Define big-endian version of perf_mem_data_src
On Mon, 12 Aug 2013, Michael Ellerman wrote: > > Yes I think so. The interface is already defined and it's little endian, > so on big endian we just need to swap. > > The only part I'm not clear on is how things are handled in perf > userspace, it seems to already do some byte swapping. It would be nice to clarify this. "struct perf_branch_entry" also has bitfields like this, though to make things more confusing that structure isn't exported via the uapi header so it's not clear how userspace code is supposed to interpret the values. As you say it gets complicated with perf userspace, especially in cases where you record the data on big-endian but then try to analyze the results on a little-endian machine. It would be nice to get confirmation that these bitfields will always be little-endian. I guess they currently are by definition because only x86/pebs sets data.data_src.val so far? Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2 0/4] mm: reclaim zbud pages on migration and compaction
Hello Minchan,
On Mon, Aug 12, 2013 at 11:25:35AM +0900, Minchan Kim wrote:
> Hello,
>
> On Fri, Aug 09, 2013 at 12:22:16PM +0200, Krzysztof Kozlowski wrote:
> > Hi,
> >
> > Currently zbud pages are not movable and they cannot be allocated from CMA
> > region. These patches try to address the problem by:
>
> The zcache, zram and GUP pages for memory-hotplug and/or CMA are
> same situation.
>
> > 1. Adding a new form of reclaim of zbud pages.
> > 2. Reclaiming zbud pages during migration and compaction.
> > 3. Allocating zbud pages with __GFP_RECLAIMABLE flag.
>
> So I'd like to solve it with general approach.
>
> Each subsystem or GUP caller who want to pin pages long time should
> create own migration handler and register the page into pin-page
> control subsystem like this.
>
> driver/foo.c
>
> int foo_migrate(struct page *page, void *private);
>
> static struct pin_page_owner foo_migrate = {
> .migrate = foo_migrate;
> };
>
> int foo_allocate()
> {
> struct page *newpage = alloc_pages();
> set_pinned_page(newpage, _migrate);
> }
>
> And in compaction.c or somewhere where want to move/reclaim the page,
> general VM can ask to owner if it founds it's pinned page.
>
> mm/compaction.c
>
> if (PagePinned(page)) {
> struct pin_page_info *info = get_page_pin_info(page);
> info->migrate(page);
>
> }
>
> Only hurdle for that is that we should introduce a new page flag and
> I believe if we all agree this approch, we can find a solution at last.
>
> What do you think?
I don't like this approach. There will be too many collisions in the
hash that's been implemented (read: I don't think you can get away with
a naive implementation for core infrastructure that has to suite all
users), you've got a global spin lock, and it doesn't take into account
NUMA issues. The address space migratepage method doesn't have those
issues (at least where it is usable as in aio's use-case).
If you're going to go down this path, you'll have to decide if *all* users
of pinned pages are going to have to subscribe to supporting the un-pinning
of pages, and that means taking a real hard look at how O_DIRECT pins pages.
Once you start thinking about that, you'll find that addressing the
performance concerns is going to be an essential part of any design work to
be done in this area.
-ben
--
"Thought is the essence of where you are now."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-Xtensa] Re: [PATCH] time: sched_clock: fix integer overflow
Hi Thomas, John,
On Mon, Jul 29, 2013 at 08:59:39AM +0300, Baruch Siach wrote:
> On Wed, Jul 17, 2013 at 12:46:53PM +0300, Baruch Siach wrote:
> > The expression '(1 << 32)' happens to evaluate as 0 on ARM, but it
> > evaluates as
> > 1 on xtensa and x86_64. This zeros sched_clock_mask, and breaks
> > sched_clock().
> > Set the type of 1 to 'unsigned long long' to get the value we need.
>
> Ping? -rc3 is out, and this bug (which currently breaks xtensa) is not fixed
> yet. Please consider applying.
Sorry to bother again, but -rc5 is here and xtensa sched_clock is still
broken.
baruch
> > Reported-by: Max Filippov
> > Tested-by: Max Filippov
> > Acked-by: Russell King
> > Signed-off-by: Baruch Siach
> > ---
> > kernel/time/sched_clock.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
> > index a326f27..0b479a6 100644
> > --- a/kernel/time/sched_clock.c
> > +++ b/kernel/time/sched_clock.c
> > @@ -121,7 +121,7 @@ void __init setup_sched_clock(u32 (*read)(void), int
> > bits, unsigned long rate)
> > BUG_ON(bits > 32);
> > WARN_ON(!irqs_disabled());
> > read_sched_clock = read;
> > - sched_clock_mask = (1 << bits) - 1;
> > + sched_clock_mask = (1ULL << bits) - 1;
> > cd.rate = rate;
> >
> > /* calculate the mult/shift to convert counter ticks to ns. */
> > --
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/14] cgroup: reorganize css init / exit paths
> /* invoke ->css_online() on a new CSS and mark it online if successful */
> -static int online_css(struct cgroup_subsys *ss, struct cgroup *cgrp)
> +static int online_css(struct cgroup_subsys_state *css)
> {
> - struct cgroup_subsys_state *css = cgroup_css(cgrp, ss->subsys_id);
> + struct cgroup_subsys *ss = css->ss;
> int ret = 0;
>
> lockdep_assert_held(_mutex);
> @@ -4342,9 +4340,9 @@ static int online_css(struct cgroup_subsys *ss, struct
> cgroup *cgrp)
> }
>
> /* if the CSS is online, invoke ->css_offline() on it and mark it offline */
> -static void offline_css(struct cgroup_subsys *ss, struct cgroup *cgrp)
> +static void offline_css(struct cgroup_subsys_state *css)
> {
> - struct cgroup_subsys_state *css = cgroup_css(cgrp, ss->subsys_id);
> + struct cgroup_subsys *ss = css->ss;
>
> lockdep_assert_held(_mutex);
>
> @@ -4442,10 +4440,10 @@ static long cgroup_create(struct cgroup *parent,
> struct dentry *dentry,
> goto err_free_all;
> }
>
> - init_cgroup_css(css, ss, cgrp);
> + init_css(css, ss, cgrp);
>
> if (ss->use_id) {
> - err = alloc_css_id(ss, parent, cgrp);
> + err = alloc_css_id(css);
> if (err)
> goto err_free_all;
> }
> @@ -4467,20 +4465,18 @@ static long cgroup_create(struct cgroup *parent,
> struct dentry *dentry,
> list_add_tail_rcu(>sibling, >parent->children);
> root->number_of_cgroups++;
>
> - /* each css holds a ref to the cgroup's dentry and the parent css */
> + /* hold a ref to the parent's dentry */
> + dget(parent->dentry);
> +
> for_each_root_subsys(root, ss) {
> struct cgroup_subsys_state *css = cgroup_css(cgrp,
> ss->subsys_id);
>
> + /* each css holds a ref to the cgroup and the parent css */
> dget(dentry);
> percpu_ref_get(>parent->refcnt);
We called dget() and percpu_ref_get() for each css unconditionally...
> - }
>
> - /* hold a ref to the parent's dentry */
> - dget(parent->dentry);
> -
> - /* creation succeeded, notify subsystems */
> - for_each_root_subsys(root, ss) {
> - err = online_css(ss, cgrp);
> + /* creation succeeded, notify subsystems */
> + err = online_css(css);
> if (err)
> goto err_destroy;
but now dget() and percpu_ref_get() may not be called for some css's,
but the code in failure path is not updated accordingly, which seems
wrong.
>
> @@ -4700,7 +4696,7 @@ static void cgroup_offline_fn(struct work_struct *work)
>* initate destruction.
>*/
> for_each_root_subsys(cgrp->root, ss)
> - offline_css(ss, cgrp);
> + offline_css(cgroup_css(cgrp, ss->subsys_id));
>
> /*
>* Put the css refs from cgroup_destroy_locked(). Each css holds
> @@ -4778,7 +4774,7 @@ static void __init cgroup_init_subsys(struct
> cgroup_subsys *ss)
> css = ss->css_alloc(cgroup_css(cgroup_dummy_top, ss->subsys_id));
> /* We don't handle early failures gracefully */
> BUG_ON(IS_ERR(css));
> - init_cgroup_css(css, ss, cgroup_dummy_top);
> + init_css(css, ss, cgroup_dummy_top);
>
> /* Update the init_css_set to contain a subsys
>* pointer to this state - since the subsystem is
> @@ -4793,7 +4789,7 @@ static void __init cgroup_init_subsys(struct
> cgroup_subsys *ss)
>* need to invoke fork callbacks here. */
> BUG_ON(!list_empty(_task.tasks));
>
> - BUG_ON(online_css(ss, cgroup_dummy_top));
> + BUG_ON(online_css(cgroup_css(cgroup_dummy_top, ss->subsys_id)));
>
> mutex_unlock(_mutex);
>
> @@ -4866,8 +4862,8 @@ int __init_or_module cgroup_load_subsys(struct
> cgroup_subsys *ss)
> ss->root = _dummy_root;
>
> /* our new subsystem will be attached to the dummy hierarchy. */
> - init_cgroup_css(css, ss, cgroup_dummy_top);
> - /* init_idr must be after init_cgroup_css because it sets css->id. */
> + init_css(css, ss, cgroup_dummy_top);
> + /* init_idr must be after init_css() because it sets css->id. */
> if (ss->use_id) {
> ret = cgroup_init_idr(ss, css);
> if (ret)
> @@ -4897,7 +4893,7 @@ int __init_or_module cgroup_load_subsys(struct
> cgroup_subsys *ss)
> }
> write_unlock(_set_lock);
>
> - ret = online_css(ss, cgroup_dummy_top);
> + ret = online_css(cgroup_css(cgroup_dummy_top, ss->subsys_id));
> if (ret)
> goto err_unload;
>
> @@ -4936,7 +4932,7 @@ void cgroup_unload_subsys(struct cgroup_subsys *ss)
>
> mutex_lock(_mutex);
>
> - offline_css(ss, cgroup_dummy_top);
> + offline_css(cgroup_css(cgroup_dummy_top, ss->subsys_id));
>
> if (ss->use_id)
> idr_destroy(>idr);
> @@ -5588,20 +5584,16 @@
kmemleak in apei_res_add
When running 3.10.3 with kmemleak enabled, I see following warnings from kmemleak: unreferenced object 0x88024d2219a0 (size 32): comm "swapper/0", pid 1, jiffies 4294894532 (age 26865.180s) hex dump (first 32 bytes): 58 de 0c 73 02 88 ff ff 58 de 0c 73 02 88 ff ff X..sX..s 18 50 fd 7d 00 00 00 00 3f 50 fd 7d 00 00 00 00 .P.}?P.} backtrace: [] kmemleak_alloc+0x21/0x3e [] kmemleak_alloc_recursive.constprop.58+0x16/0x18 [] kmem_cache_alloc_trace+0xe6/0x12f [] apei_res_add+0xb9/0xe8 [] collect_res_callback+0x6d/0x7c [] apei_exec_for_each_entry+0x78/0x93 [] apei_exec_collect_resources+0x15/0x17 [] erst_init+0x278/0x2a3 [] do_one_initcall+0x7b/0x116 [] kernel_init_freeable+0x13f/0x1cc [] kernel_init+0x9/0xd6 [] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88024d221980 (size 32): comm "swapper/0", pid 1, jiffies 4294894532 (age 26865.180s) hex dump (first 32 bytes): 68 de 0c 73 02 88 ff ff 68 de 0c 73 02 88 ff ff h..sh..s b2 00 00 00 00 00 00 00 b3 00 00 00 00 00 00 00 backtrace: [] kmemleak_alloc+0x21/0x3e [] kmemleak_alloc_recursive.constprop.58+0x16/0x18 [] kmem_cache_alloc_trace+0xe6/0x12f [] apei_res_add+0xb9/0xe8 [] collect_res_callback+0x6d/0x7c [] apei_exec_for_each_entry+0x78/0x93 [] apei_exec_collect_resources+0x15/0x17 [] erst_init+0x278/0x2a3 [] do_one_initcall+0x7b/0x116 [] kernel_init_freeable+0x13f/0x1cc [] kernel_init+0x9/0xd6 [] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88024d221960 (size 32): comm "swapper/0", pid 1, jiffies 4294894532 (age 26865.180s) hex dump (first 32 bytes): 00 de 0c 73 02 88 ff ff 40 19 22 4d 02 88 ff ff ...s@."M 00 50 09 7e 00 00 00 00 00 90 29 7e 00 00 00 00 .P.~..)~ backtrace: [] kmemleak_alloc+0x21/0x3e [] kmemleak_alloc_recursive.constprop.58+0x16/0x18 [] kmem_cache_alloc_trace+0xe6/0x12f [] apei_res_add+0xb9/0xe8 [] apei_get_nvs_callback+0x15/0x17 [] acpi_nvs_for_each_region+0x25/0x46 [] apei_resources_request+0x56/0x217 [] erst_init+0xbb/0x2a3 [] do_one_initcall+0x7b/0x116 [] kernel_init_freeable+0x13f/0x1cc [] kernel_init+0x9/0xd6 [] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88024d221940 (size 32): comm "swapper/0", pid 1, jiffies 4294894532 (age 26865.180s) hex dump (first 32 bytes): 60 19 22 4d 02 88 ff ff 00 de 0c 73 02 88 ff ff `."M...s 00 00 37 7f 00 00 00 00 00 60 3f 7f 00 00 00 00 ..7..`?. backtrace: [] kmemleak_alloc+0x21/0x3e [] kmemleak_alloc_recursive.constprop.58+0x16/0x18 [] kmem_cache_alloc_trace+0xe6/0x12f [] apei_res_add+0xb9/0xe8 [] apei_get_nvs_callback+0x15/0x17 [] acpi_nvs_for_each_region+0x25/0x46 [] apei_resources_request+0x56/0x217 [] erst_init+0xbb/0x2a3 [] do_one_initcall+0x7b/0x116 [] kernel_init_freeable+0x13f/0x1cc [] kernel_init+0x9/0xd6 [] ret_from_fork+0x7c/0xb0 [] 0x -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mmc:bfin_sdh change driver to use dev_pm_ops infrastructure
Acked-by: Sonic Zhang
>-Original Message-
>From: Shuah Khan [mailto:shuah...@samsung.com]
>Sent: Saturday, August 10, 2013 11:21 PM
>To: Zhang, Sonic; c...@laptop.org
>Cc: Shuah Khan; uclinux-dist-de...@blackfin.uclinux.org;
>linux-...@vger.kernel.org;
>linux-kernel@vger.kernel.org; shuahk...@gmail.com
>Subject: [PATCH] mmc:bfin_sdh change driver to use dev_pm_ops infrastructure
>
>Change bfin sdh platform driver to register pm ops using dev_pm_ops instead of
>legacy pm_ops infrastructure.
>
>Signed-off-by: Shuah Khan
>---
> drivers/mmc/host/bfin_sdh.c | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/mmc/host/bfin_sdh.c b/drivers/mmc/host/bfin_sdh.c index
>94fae2f..7b3e12f 100644
>--- a/drivers/mmc/host/bfin_sdh.c
>+++ b/drivers/mmc/host/bfin_sdh.c
>@@ -638,10 +638,11 @@ static int sdh_remove(struct platform_device *pdev) }
>
> #ifdef CONFIG_PM
>-static int sdh_suspend(struct platform_device *dev, pm_message_t state)
>+static int sdh_suspend(struct device *dev)
> {
>- struct mmc_host *mmc = platform_get_drvdata(dev);
>- struct bfin_sd_host *drv_data = get_sdh_data(dev);
>+ struct platform_device *pdev = to_platform_device(dev);
>+ struct mmc_host *mmc = platform_get_drvdata(pdev);
>+ struct bfin_sd_host *drv_data = get_sdh_data(pdev);
> int ret = 0;
>
> if (mmc)
>@@ -652,15 +653,16 @@ static int sdh_suspend(struct platform_device *dev,
>pm_message_t state)
> return ret;
> }
>
>-static int sdh_resume(struct platform_device *dev)
>+static int sdh_resume(struct device *dev)
> {
>- struct mmc_host *mmc = platform_get_drvdata(dev);
>- struct bfin_sd_host *drv_data = get_sdh_data(dev);
>+ struct platform_device *pdev = to_platform_device(dev);
>+ struct mmc_host *mmc = platform_get_drvdata(pdev);
>+ struct bfin_sd_host *drv_data = get_sdh_data(pdev);
> int ret = 0;
>
> ret = peripheral_request_list(drv_data->pin_req, DRIVER_NAME);
> if (ret) {
>- dev_err(>dev, "unable to request peripheral pins\n");
>+ dev_err(dev, "unable to request peripheral pins\n");
> return ret;
> }
>
>@@ -676,13 +678,14 @@ static int sdh_resume(struct platform_device *dev) #
>define sdh_resume NULL #endif
>
>+static SIMPLE_DEV_PM_OPS(sdh_dev_pm_ops, sdh_suspend, sdh_resume);
>+
> static struct platform_driver sdh_driver = {
> .probe = sdh_probe,
> .remove = sdh_remove,
>- .suspend = sdh_suspend,
>- .resume = sdh_resume,
> .driver = {
> .name = DRIVER_NAME,
>+ .pm = _dev_pm_ops,
> },
> };
>
>--
>1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mmc:bfin_sdh fix build warning in sdh_dma_irq()
Acked-by: Sonic Zhang
>-Original Message-
>From: Shuah Khan [mailto:shuah...@samsung.com]
>Sent: Saturday, August 10, 2013 11:21 PM
>To: Zhang, Sonic; c...@laptop.org
>Cc: Shuah Khan; uclinux-dist-de...@blackfin.uclinux.org;
>linux-...@vger.kernel.org;
>linux-kernel@vger.kernel.org; shuahk...@gmail.com
>Subject: [PATCH] mmc:bfin_sdh fix build warning in sdh_dma_irq()
>
>Fix the following build warning in sdh_dma_irq()
>drivers/mmc/host/bfin_sdh.c:466:2: warning: format %lx expects argument of
>type
>long unsigned int , but argument 5 has type int [-Wformat]
> dev_dbg(mmc_dev(host->mmc), "%s enter, irq_stat: 0x%04x\n", __func__,
>get_dma_curr_irqstat(host->dma_ch));
>
>Signed-off-by: Shuah Khan
>---
> drivers/mmc/host/bfin_sdh.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/mmc/host/bfin_sdh.c b/drivers/mmc/host/bfin_sdh.c index
>7b3e12f..61157c4 100644
>--- a/drivers/mmc/host/bfin_sdh.c
>+++ b/drivers/mmc/host/bfin_sdh.c
>@@ -463,7 +463,7 @@ static irqreturn_t sdh_dma_irq(int irq, void *devid) {
> struct sdh_host *host = devid;
>
>- dev_dbg(mmc_dev(host->mmc), "%s enter, irq_stat: 0x%04lx\n", __func__,
>+ dev_dbg(mmc_dev(host->mmc), "%s enter, irq_stat: 0x%04x\n", __func__,
> get_dma_curr_irqstat(host->dma_ch));
> clear_dma_irqstat(host->dma_ch);
> SSYNC();
>--
>1.7.10.4
>
Re: [RFC PATCH v2 0/4] mm: reclaim zbud pages on migration and compaction
Hello,
On Fri, Aug 09, 2013 at 12:22:16PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> Currently zbud pages are not movable and they cannot be allocated from CMA
> region. These patches try to address the problem by:
The zcache, zram and GUP pages for memory-hotplug and/or CMA are
same situation.
> 1. Adding a new form of reclaim of zbud pages.
> 2. Reclaiming zbud pages during migration and compaction.
> 3. Allocating zbud pages with __GFP_RECLAIMABLE flag.
So I'd like to solve it with general approach.
Each subsystem or GUP caller who want to pin pages long time should
create own migration handler and register the page into pin-page
control subsystem like this.
driver/foo.c
int foo_migrate(struct page *page, void *private);
static struct pin_page_owner foo_migrate = {
.migrate = foo_migrate;
};
int foo_allocate()
{
struct page *newpage = alloc_pages();
set_pinned_page(newpage, _migrate);
}
And in compaction.c or somewhere where want to move/reclaim the page,
general VM can ask to owner if it founds it's pinned page.
mm/compaction.c
if (PagePinned(page)) {
struct pin_page_info *info = get_page_pin_info(page);
info->migrate(page);
}
Only hurdle for that is that we should introduce a new page flag and
I believe if we all agree this approch, we can find a solution at last.
What do you think?
>From 9a4f652006b7d0c750933d738e1bd6f53754bcf6 Mon Sep 17 00:00:00 2001
From: Minchan Kim
Date: Sun, 11 Aug 2013 00:31:57 +0900
Subject: [RFC] pin page control subsystem
Signed-off-by: Minchan Kim
---
mm/Makefile |2 +-
mm/pin-page.c | 101 +
2 files changed, 102 insertions(+), 1 deletion(-)
create mode 100644 mm/pin-page.c
diff --git a/mm/Makefile b/mm/Makefile
index f008033..245c2f7 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -5,7 +5,7 @@
mmu-y := nommu.o
mmu-$(CONFIG_MMU) := fremap.o highmem.o madvise.o memory.o mincore.o \
mlock.o mmap.o mprotect.o mremap.o msync.o rmap.o \
- vmalloc.o pagewalk.o pgtable-generic.o
+ vmalloc.o pagewalk.o pgtable-generic.o pin-page.o
ifdef CONFIG_CROSS_MEMORY_ATTACH
mmu-$(CONFIG_MMU) += process_vm_access.o
diff --git a/mm/pin-page.c b/mm/pin-page.c
new file mode 100644
index 000..74b07f8
--- /dev/null
+++ b/mm/pin-page.c
@@ -0,0 +1,101 @@
+#include
+#include
+#include
+#include
+
+#define PPAGE_HASH_BITS 10
+
+static DEFINE_SPINLOCK(hash_lock);
+/*
+ * Should consider what's data struct we should use.
+ * It would be better use radix tree if we try to pin contigous
+ * pages a lot but if we pin spread pages, it wouldn't be a good idea.
+ */
+static DEFINE_HASHTABLE(pin_page_hash, PPAGE_HASH_BITS);
+
+/*
+ * Each subsystems should provide own page migration handler
+ */
+struct pin_page_owner {
+ int (*migrate)(struct page *page, void *private);
+};
+
+struct pin_page_info {
+ struct pin_page_owner *owner;
+ struct hlist_node hlist;
+
+ unsigned long pfn;
+ void *private;
+};
+
+/* TODO : Introduce new page flags */
+void SetPinnedPage(struct page *page)
+{
+
+}
+
+int PinnedPage(struct page *page)
+{
+ return 0;
+}
+
+/*
+ * GUP caller or subsystems which pin the page should call this function
+ * to register @page in pin-page control subsystem so that VM can ask us
+ * when it want to migrate @page.
+ *
+ * Each pinned page would have some private key to identify itself
+ * like custom-allocator-returned handle.
+ */
+int set_pinned_page(struct pin_page_owner *owner,
+ struct page *page, void *private)
+{
+ struct pin_page_info *pinfo = kmalloc(sizeof(pinfo), GFP_KERNEL);
+
+ INIT_HLIST_NODE(>hlist);
+ pinfo->owner = owner;
+
+ pinfo->pfn = page_to_pfn(page);
+ pinfo->private = private;
+
+ spin_lock(_lock);
+ hash_add(pin_page_hash, >hlist, pinfo->pfn);
+ spin_unlock(_lock);
+
+ SetPinnedPage(page);
+ return 0;
+};
+
+struct pin_page_info *get_pin_page_info(struct page *page)
+{
+ struct pin_page_info *tmp;
+ unsigned long pfn = page_to_pfn(page);
+
+ spin_lock(_lock);
+ hash_for_each_possible(pin_page_hash, tmp, hlist, pfn) {
+ if (tmp->pfn == pfn) {
+ spin_unlock(_lock);
+ return tmp;
+ }
+ }
+ spin_unlock(_lock);
+ return NULL;
+}
+
+/* Used in compaction.c */
+int migrate_pinned_page(struct page *page)
+{
+ int ret = 1;
+ struct pin_page_info *pinfo = NULL;
+
+ if (PinnedPage(page)) {
+ while ((pinfo = get_pin_page_info(page))) {
+ /* If one of owners failed, bail out */
+ if (pinfo->owner->migrate(page, pinfo->private))
+ break;
+ }
+
Re: Reading perf counters at ftrace trace boundaries
On 2013/8/12 8:03, Karim Yaghmour wrote: > > Wondering if there's a way for reading perf counters in the kernel. I'd > like to read/record perf counters on ftrace function tracing > entries/exits to provide a rundown of the value of various counters on > function call boundaries. > > [ Steven: apologies for sending you a duplicate here of what I somewhat > already sent privately. ] > If you want to base on ftrace, below two approach maybe take into use: - register_ftrace_function/unregister_ftrace_function - perf_event_create_kernel_counter (function event id is 1) the first one is simplest, IMO. You need to write your own kernel module to use these approach. jovi. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the cgroup tree with the net-next tree
Hi Tejun,
Today's linux-next merge of the cgroup tree got a conflict in
include/net/netprio_cgroup.h between commit 378307217ed9 ("cls_cgroup.h
netprio_cgroup.h: Remove extern from function prototypes") from the
net-next tree and commit 6d37b97428d2 ("netprio_cgroup: pass around @css
instead of @cgroup and kill struct cgroup_netprio_state") from the cgroup
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/net/netprio_cgroup.h
index 379dd5d,a24f8bb..000
--- a/include/net/netprio_cgroup.h
+++ b/include/net/netprio_cgroup.h
@@@ -25,11 -25,7 +25,7 @@@ struct netprio_map
u32 priomap[];
};
- struct cgroup_netprio_state {
- struct cgroup_subsys_state css;
- };
-
-extern void sock_update_netprioidx(struct sock *sk);
+void sock_update_netprioidx(struct sock *sk);
#if IS_BUILTIN(CONFIG_NETPRIO_CGROUP)
pgps9BGHkyzJk.pgp
Description: PGP signature
[patch 1/3 v2] raid5: offload stripe handle to workqueue
This is another attempt to create multiple threads to handle raid5 stripes.
This time I use workqueue.
raid5 handles request (especially write) in stripe unit. A stripe is page size
aligned/long and acrosses all disks. Writing to any disk sector, raid5 runs a
state machine for the corresponding stripe, which includes reading some disks
of the stripe, calculating parity, and writing some disks of the stripe. The
state machine is running in raid5d thread currently. Since there is only one
thread, it doesn't scale well for high speed storage. An obvious solution is
multi-threading.
To get better performance, we have some requirements:
a. locality. stripe corresponding to request submitted from one cpu is better
handled in thread in local cpu or local node. local cpu is preferred but some
times could be a bottleneck, for example, parity calculation is too heavy.
local node running has wide adaptability.
b. configurablity. Different setup of raid5 array might need diffent
configuration. Especially the thread number. More threads don't always mean
better performance because of lock contentions.
My original implementation is creating some kernel threads. There are
interfaces to control which cpu's stripe each thread should handle. And
userspace can set affinity of the threads. This provides biggest flexibility
and configurability. But it's hard to use and apparently a new thread pool
implementation is disfavor.
Recent workqueue improvement is quite promising. unbound workqueue will be
bound to numa node. If WQ_SYSFS is set in workqueue, there are sysfs option to
do affinity setting. For example, we can only include one HT sibling in
affinity. Since work is non-reentrant by default, and we can control running
thread number by limiting dispatched work_struct number.
In this patch, I created several stripe worker group. A group is a numa node.
stripes from cpus of one node will be added to a group list. Workqueue thread
of one node will only handle stripes of worker group of the node. In this way,
stripe handling has numa node locality. And as I said, we can control thread
number by limiting dispatched work_struct number.
The work_struct callback function handles several stripes in one run. A typical
work queue usage is to run one unit in each work_struct. In raid5 case, the
unit is a stripe. But we can't do that:
a. Though handling a stripe doesn't need lock because of reference accounting
and stripe isn't in any list, queuing a work_struct for each stripe will make
workqueue lock contended very heavily.
b. blk_start_plug()/blk_finish_plug() should surround stripe handle, as we
might dispatch request. If each work_struct only handles one stripe, such block
plug is meaningless.
This implementation can't do very fine grained configuration. But the numa
binding is most popular usage model, should be enough for most workloads.
Note: since we have only one stripe queue, switching to multi-thread might
decrease request size dispatching down to low level layer. The impact depends
on thread number, raid configuration and workload. So multi-thread raid5 might
not be proper for all setups.
Changes V1 -> V2:
1. remove WQ_NON_REENTRANT
2. disabling multi-threading by default
3. Add more descriptions in changelog
Signed-off-by: Shaohua Li
---
drivers/md/raid5.c | 196 -
drivers/md/raid5.h | 15
2 files changed, 196 insertions(+), 15 deletions(-)
Index: linux/drivers/md/raid5.c
===
--- linux.orig/drivers/md/raid5.c 2013-08-12 09:13:46.548632681 +0800
+++ linux/drivers/md/raid5.c2013-08-12 09:14:06.628380246 +0800
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
#include
#include "md.h"
@@ -60,6 +61,10 @@
#include "raid0.h"
#include "bitmap.h"
+#define cpu_to_group(cpu) cpu_to_node(cpu)
+#define ANY_GROUP NUMA_NO_NODE
+
+static struct workqueue_struct *raid5_wq;
/*
* Stripe cache
*/
@@ -200,6 +205,23 @@ static int stripe_operations_active(stru
test_bit(STRIPE_COMPUTE_RUN, >state);
}
+static void raid5_wakeup_stripe_thread(struct stripe_head *sh)
+{
+ struct r5conf *conf = sh->raid_conf;
+ struct r5worker_group *group;
+ int i;
+
+ if (conf->worker_cnt_per_group == 0) {
+ md_wakeup_thread(conf->mddev->thread);
+ return;
+ }
+
+ group = conf->worker_groups + cpu_to_group(sh->cpu);
+
+ for (i = 0; i < conf->worker_cnt_per_group; i++)
+ queue_work_on(sh->cpu, raid5_wq, >workers[i].work);
+}
+
static void do_release_stripe(struct r5conf *conf, struct stripe_head *sh)
{
BUG_ON(!list_empty(>lru));
@@ -212,9 +234,23 @@ static void do_release_stripe(struct r5c
sh->bm_seq - conf->seq_write > 0)
list_add_tail(>lru, >bitmap_list);
else {
+ int cpu = sh->cpu;
+
[patch 0/3 v2] raid5: make stripe handling multi-threading
Neil, This is another attempt to make raid5 stripe handling multi-threading. Recent workqueue improvement for unbound workqueue looks very promising to the raid5 usage. I had details in the first patch. The patches are against your tree with patch 'raid5: make release_stripe lockless' and 'raid5: fix stripe release order' but without 'raid5: create multiple threads to handle stripes' My test setup has 7 PCIe SSD, chunksize 8k, stripe_cache_size 2048. If enabling multi-threading, group_thread_cnt is set to 8. randwrite throughput(ratio) unpatch/patch requestsize(sectors) unpatch/patch 4k 1/5.9 8/8 8k 1/5.5 16/13 16k 1/4.8 16/13 32k 1/4.6 18/14 64k 1/4.7 17/13 128k1/4.2 23/16 256k1/3.5 41/21 512k1/3 75/28 1M 1/2.6 134/34 For example, in 1M randwrite test, patched kernel is 2.6x faster, but average request sending to each disk is drop to 34 sectors from 134 sectors long. Currently the biggest problem is request size is dropped, because there are multiple threads dispatching requests. This indicates multi-threading might not be proper for all setup, so I disable it by default in this version. But since throughput is largly improved, I thought this isn't a blocking issue. I'm still working on improving this, maybe schedule stripes from one block plug as a whole. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 3/3 v2] raid5: only wakeup necessary threads
If there are no enough stripes to handle, we'd better not always queue all
available work_structs. If one worker can only handle small or even none
stripes, it will impact request merge and create lock contention.
With this patch, the number of work_struct running will depend on pending
stripes number. Note: some statistics info used in the patch are accessed
without
locking protection. This should doesn't matter, we just try best to avoid queue
unnecessary work_struct.
Signed-off-by: Shaohua Li
---
drivers/md/raid5.c | 50 --
drivers/md/raid5.h |4
2 files changed, 48 insertions(+), 6 deletions(-)
Index: linux/drivers/md/raid5.c
===
--- linux.orig/drivers/md/raid5.c 2013-08-09 09:50:25.754255596 +0800
+++ linux/drivers/md/raid5.c2013-08-09 10:03:45.016208049 +0800
@@ -77,6 +77,7 @@ static struct workqueue_struct *raid5_wq
#define BYPASS_THRESHOLD 1
#define NR_HASH(PAGE_SIZE / sizeof(struct hlist_head))
#define HASH_MASK (NR_HASH - 1)
+#define MAX_STRIPE_BATCH 8
static inline struct hlist_head *stripe_hash(struct r5conf *conf, sector_t
sect)
{
@@ -209,6 +210,7 @@ static void raid5_wakeup_stripe_thread(s
{
struct r5conf *conf = sh->raid_conf;
struct r5worker_group *group;
+ int thread_cnt;
int i;
if (conf->worker_cnt_per_group == 0) {
@@ -218,8 +220,26 @@ static void raid5_wakeup_stripe_thread(s
group = conf->worker_groups + cpu_to_group(sh->cpu);
- for (i = 0; i < conf->worker_cnt_per_group; i++)
- queue_work_on(sh->cpu, raid5_wq, >workers[i].work);
+ group->workers[0].working = true;
+ /* at least one worker should run to avoid race */
+ queue_work_on(sh->cpu, raid5_wq, >workers[0].work);
+
+ thread_cnt = group->stripes_cnt / MAX_STRIPE_BATCH - 1;
+ /* wakeup more workers */
+ for (i = 1; i < conf->worker_cnt_per_group && thread_cnt > 0; i++) {
+ if (group->workers[i].working == false) {
+ group->workers[i].working = true;
+ queue_work_on(sh->cpu, raid5_wq,
+ >workers[i].work);
+ thread_cnt--;
+ } else if (group->workers[i].working_cnt <=
+ MAX_STRIPE_BATCH / 2)
+ /*
+* If a worker has no enough stripes handling, assume
+* it will fetch more stripes soon.
+*/
+ thread_cnt--;
+ }
}
static void do_release_stripe(struct r5conf *conf, struct stripe_head *sh)
@@ -248,6 +268,8 @@ static void do_release_stripe(struct r5c
struct r5worker_group *group;
group = conf->worker_groups + cpu_to_group(cpu);
list_add_tail(>lru, >handle_list);
+ group->stripes_cnt++;
+ sh->group = group;
}
raid5_wakeup_stripe_thread(sh);
return;
@@ -573,6 +595,10 @@ get_active_stripe(struct r5conf *conf, s
!test_bit(STRIPE_EXPANDING, >state))
BUG();
list_del_init(>lru);
+ if (sh->group) {
+ sh->group->stripes_cnt--;
+ sh->group = NULL;
+ }
}
}
} while (sh == NULL);
@@ -4143,6 +4169,7 @@ static struct stripe_head *__get_priorit
{
struct stripe_head *sh = NULL, *tmp;
struct list_head *handle_list = NULL;
+ struct r5worker_group *wg = NULL;
if (conf->worker_cnt_per_group == 0) {
handle_list = >handle_list;
@@ -4150,12 +4177,14 @@ static struct stripe_head *__get_priorit
handle_list = NULL;
} else if (group != ANY_GROUP) {
handle_list = >worker_groups[group].handle_list;
+ wg = >worker_groups[group];
if (list_empty(handle_list))
handle_list = NULL;
} else {
int i;
for (i = 0; i < conf->group_cnt; i++) {
handle_list = >worker_groups[i].handle_list;
+ wg = >worker_groups[i];
if (!list_empty(handle_list))
break;
}
@@ -4204,11 +4233,16 @@ static struct stripe_head *__get_priorit
if (conf->bypass_count < 0)
conf->bypass_count = 0;
}
+ wg = NULL;
}
if (!sh)
[patch 2/3 v2] raid5: sysfs entry to control worker thread number
Add a sysfs entry to control running workqueue thread number. If
group_thread_cnt is set to 0, we will disable workqueue offload handling of
stripes.
Signed-off-by: Shaohua Li
---
drivers/md/raid5.c | 60 +
1 file changed, 60 insertions(+)
Index: linux/drivers/md/raid5.c
===
--- linux.orig/drivers/md/raid5.c 2013-08-12 09:14:06.628380246 +0800
+++ linux/drivers/md/raid5.c2013-08-12 10:00:34.185337148 +0800
@@ -5141,10 +5141,70 @@ stripe_cache_active_show(struct mddev *m
static struct md_sysfs_entry
raid5_stripecache_active = __ATTR_RO(stripe_cache_active);
+static ssize_t
+raid5_show_group_thread_cnt(struct mddev *mddev, char *page)
+{
+ struct r5conf *conf = mddev->private;
+ if (conf)
+ return sprintf(page, "%d\n", conf->worker_cnt_per_group);
+ else
+ return 0;
+}
+
+static int alloc_thread_groups(struct r5conf *conf, int cnt);
+static ssize_t
+raid5_store_group_thread_cnt(struct mddev *mddev, const char *page, size_t len)
+{
+ struct r5conf *conf = mddev->private;
+ unsigned long new;
+ int err;
+ struct r5worker_group *old_groups;
+ int old_group_cnt;
+
+ if (len >= PAGE_SIZE)
+ return -EINVAL;
+ if (!conf)
+ return -ENODEV;
+
+ if (kstrtoul(page, 10, ))
+ return -EINVAL;
+
+ if (new == conf->worker_cnt_per_group)
+ return len;
+
+ mddev_suspend(mddev);
+
+ old_groups = conf->worker_groups;
+ old_group_cnt = conf->worker_cnt_per_group;
+
+ conf->worker_groups = NULL;
+ err = alloc_thread_groups(conf, new);
+ if (err) {
+ conf->worker_groups = old_groups;
+ conf->worker_cnt_per_group = old_group_cnt;
+ } else {
+ if (old_groups)
+ kfree(old_groups[0].workers);
+ kfree(old_groups);
+ }
+
+ mddev_resume(mddev);
+
+ if (err)
+ return err;
+ return len;
+}
+
+static struct md_sysfs_entry
+raid5_group_thread_cnt = __ATTR(group_thread_cnt, S_IRUGO | S_IWUSR,
+ raid5_show_group_thread_cnt,
+ raid5_store_group_thread_cnt);
+
static struct attribute *raid5_attrs[] = {
_stripecache_size.attr,
_stripecache_active.attr,
_preread_bypass_threshold.attr,
+ _group_thread_cnt.attr,
NULL,
};
static struct attribute_group raid5_attrs_group = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 07/16] iommu/exynos: support for device tree
On Fri, 09 Aug 2013 10:30:11 +0200, Tomasz Figa wrote:
> On Friday 09 of August 2013 15:37:30 Cho KyongHo wrote:
> > On Fri, 09 Aug 2013 00:41:25 +0200, Tomasz Figa wrote:
> > > Hi KyongHo,
> > >
> > > On Thursday 08 of August 2013 18:38:49 Cho KyongHo wrote:
> > > > This commit adds device tree support for System MMU.
> > > > This also include the following changes and enhancements:
> > > >
> > > > * use managed device helper functions.
> > > > Simplyfies System MMU device driver.
> > > >
> > > > * use only a single clock descriptor.
> > > > System MMU device descriptor is seperate if it is imposible to make
> > > > a single clock descriptor to make a device descriptor for a group of
> > > > System MMUs.
> > > >
> > > > * removed dbgname member from sysmmu_drvdata structure.
> > > > debugging kernel message for a System MMU is distinguisheable with
> > > > the
> > > > name of device descroptors.
> > >
> > > Please put all these three changes in separate patches. This patch is
> > > hard to review with all the changes mixed together...
> >
> > Ok.
> >
> > > In addition, I believe this is the patch that should be adding device
> > > tree binding documentation, not the 6/16 one, as this is where
> > > actually support for this binding gets added to the kernel.
> >
> > Oh, I didn't know that devicetree binding description and implementation
> > need to be in the same patch.
> > I will do as you advised.
>
> Thanks. We are still missing a "best practices" document about device tree
> binding development, so it might not be clear.
>
I saw Rob Herring has different idea about the seperation of patches.
Let's talk about it more.
> > > > Signed-off-by: Cho KyongHo
> > > > ---
> > > >
> > > > drivers/iommu/Kconfig|5 +-
> > > > drivers/iommu/exynos-iommu.c | 186
> > > >
> > > > - 2 files changed, 75
> > > > insertions(+), 116 deletions(-)
> > > >
> > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > > > index 820d85c..9ad45f1 100644
> > > > --- a/drivers/iommu/Kconfig
> > > > +++ b/drivers/iommu/Kconfig
> > > > @@ -168,16 +168,15 @@ config TEGRA_IOMMU_SMMU
> > > >
> > > > config EXYNOS_IOMMU
> > > >
> > > > bool "Exynos IOMMU Support"
> > > >
> > > > - depends on ARCH_EXYNOS && EXYNOS_DEV_SYSMMU
> > > > + depends on ARCH_EXYNOS
> > > >
> > > > select IOMMU_API
> > > >
> > > > + default n
> > > >
> > > > help
> > > >
> > > > Support for the IOMMU(System MMU) of Samsung Exynos
> > > > application
> > > > processor family. This enables H/W multimedia accellerators to
> > >
> > > see
> > >
> > > > non-linear physical memory chunks as a linear memory in their
> > > > address spaces
> > > >
> > > > - If unsure, say N here.
> > > > -
> > > >
> > > > config EXYNOS_IOMMU_DEBUG
> > > >
> > > > bool "Debugging log for Exynos IOMMU"
> > > > depends on EXYNOS_IOMMU
> > > >
> > > > diff --git a/drivers/iommu/exynos-iommu.c
> > > > b/drivers/iommu/exynos-iommu.c index a318049..0ee73e8 100644
> > > > --- a/drivers/iommu/exynos-iommu.c
> > > > +++ b/drivers/iommu/exynos-iommu.c
> > > > @@ -26,6 +26,7 @@
> > > >
> > > > #include
> > > > #include
> > > > #include
> > > >
> > > > +#include
> > > >
> > > > #include
> > > > #include
> > > >
> > > > @@ -170,15 +171,14 @@ struct sysmmu_drvdata {
> > > >
> > > > struct list_head node; /* entry of exynos_iommu_domain.clients
> > > > */
> > > > struct device *sysmmu; /* System MMU's device descriptor */
> > > > struct device *dev; /* Owner of system MMU */
> > > >
> > > > - char *dbgname;
> > > >
> > > > int nsfrs;
> > > >
> > > > - void __iomem **sfrbases;
> > > > - struct clk *clk[2];
> > > > + struct clk *clk;
> > > >
> > > > int activations;
> > > > rwlock_t lock;
> > > > struct iommu_domain *domain;
> > > > sysmmu_fault_handler_t fault_handler;
> > > > unsigned long pgtable;
> > > >
> > > > + void __iomem *sfrbases[0];
> > > >
> > > > };
> > > >
> > > > static bool set_sysmmu_active(struct sysmmu_drvdata *data)
> > > >
> > > > @@ -385,8 +385,8 @@ static irqreturn_t exynos_sysmmu_irq(int irq,
> > > > void
> > > > *dev_id) if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
> > > >
> > > > __raw_writel(1 << itype, data->sfrbases[i] +
> > >
> > > REG_INT_CLEAR);
> > >
> > > > else
> > > >
> > > > - dev_dbg(data->sysmmu, "(%s) %s is not handled.\n",
> > > > - data->dbgname,
> > > > sysmmu_fault_name[itype]);
> > > > + dev_dbg(data->sysmmu, "%s is not handled.\n",
> > > > + sysmmu_fault_name[itype]);
> > > >
> > > > if (itype != SYSMMU_FAULT_UNKNOWN)
> > > >
> > > > sysmmu_unblock(data->sfrbases[i]);
Re: Linux 3.4.57
diff --git a/Makefile b/Makefile
index 2fe1f6d..7f4df0c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 4
-SUBLEVEL = 56
+SUBLEVEL = 57
EXTRAVERSION =
NAME = Saber-toothed Squirrel
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 2d6e649..6610e81 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -132,7 +132,7 @@ static void __cpuinit mxcsr_feature_mask_init(void)
clts();
if (cpu_has_fxsr) {
memset(_scratch, 0, sizeof(struct i387_fxsave_struct));
- asm volatile("fxsave %0" : : "m" (fx_scratch));
+ asm volatile("fxsave %0" : "+m" (fx_scratch));
mask = fx_scratch.mxcsr_mask;
if (mask == 0)
mask = 0xffbf;
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 6ea287e2..9bdfcf5 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -117,6 +117,7 @@ struct acpi_battery {
struct acpi_device *device;
struct notifier_block pm_nb;
unsigned long update_time;
+ int revision;
int rate_now;
int capacity_now;
int voltage_now;
@@ -350,6 +351,7 @@ static struct acpi_offsets info_offsets[] = {
};
static struct acpi_offsets extended_info_offsets[] = {
+ {offsetof(struct acpi_battery, revision), 0},
{offsetof(struct acpi_battery, power_unit), 0},
{offsetof(struct acpi_battery, design_capacity), 0},
{offsetof(struct acpi_battery, full_charge_capacity), 0},
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 45c5cf8..232119a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -296,6 +296,7 @@ enum intel_pch {
#define QUIRK_PIPEA_FORCE (1<<0)
#define QUIRK_LVDS_SSC_DISABLE (1<<1)
+#define QUIRK_NO_PCH_PWM_ENABLE (1<<2)
struct intel_fbdev;
struct intel_fbc_work;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 84867a8..0e35922 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9160,6 +9160,17 @@ static void quirk_ssc_force_disable(struct drm_device
*dev)
dev_priv->quirks |= QUIRK_LVDS_SSC_DISABLE;
}
+/*
+ * Some machines (Dell XPS13) suffer broken backlight controls if
+ * BLM_PCH_PWM_ENABLE is set.
+ */
+static void quirk_no_pcm_pwm_enable(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ dev_priv->quirks |= QUIRK_NO_PCH_PWM_ENABLE;
+ DRM_INFO("applying no-PCH_PWM_ENABLE quirk\n");
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -9192,6 +9203,11 @@ struct intel_quirk intel_quirks[] = {
/* Sony Vaio Y cannot use SSC on LVDS */
{ 0x0046, 0x104d, 0x9076, quirk_ssc_force_disable },
+
+ /* Dell XPS13 HD Sandy Bridge */
+ { 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable },
+ /* Dell XPS13 HD and XPS13 FHD Ivy Bridge */
+ { 0x0166, 0x1028, 0x058b, quirk_no_pcm_pwm_enable },
};
static void intel_init_quirks(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 207180d..ab4d990 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -1097,7 +1097,8 @@ bool intel_lvds_init(struct drm_device *dev)
goto failed;
out:
- if (HAS_PCH_SPLIT(dev)) {
+ if (HAS_PCH_SPLIT(dev) &&
+ !(dev_priv->quirks & QUIRK_NO_PCH_PWM_ENABLE)) {
u32 pwm;
pipe = (I915_READ(PCH_LVDS) & LVDS_PIPEB_SELECT) ? 1 : 0;
diff --git a/drivers/net/arcnet/arcnet.c b/drivers/net/arcnet/arcnet.c
index a746ba2..a956053 100644
--- a/drivers/net/arcnet/arcnet.c
+++ b/drivers/net/arcnet/arcnet.c
@@ -1007,7 +1007,7 @@ static void arcnet_rx(struct net_device *dev, int bufnum)
soft =
- lp->hw.copy_from_card(dev, bufnum, 0, , sizeof(ARC_HDR_SIZE));
+ lp->hw.copy_from_card(dev, bufnum, 0, , ARC_HDR_SIZE);
if (pkt.hard.offset[0]) {
ofs = pkt.hard.offset[0];
length = 256 - ofs;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c
index d3695ed..a061e37 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c
@@ -108,9 +108,8 @@ s32 ixgbe_dcb_config_tx_desc_arbiter_82598(struct ixgbe_hw
*hw,
/* Enable arbiter */
reg &= ~IXGBE_DPMCS_ARBDIS;
- /* Enable DFP and Recycle mode */
- reg |= (IXGBE_DPMCS_TDPAC | IXGBE_DPMCS_TRM);
reg |= IXGBE_DPMCS_TSOEF;
+
/* Configure Max TSO packet size 34KB including payload and headers */
reg |= (0x4 << IXGBE_DPMCS_MTSOS_SHIFT);
diff --git a/drivers/net/ethernet/realtek/8139cp.c
b/drivers/net/ethernet/realtek/8139cp.c
index 4ce981c..2205db7
Linux 3.4.57
I'm announcing the release of the 3.4.57 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/x86/kernel/i387.c |2 drivers/acpi/battery.c |2 drivers/gpu/drm/i915/i915_drv.h|1 drivers/gpu/drm/i915/intel_display.c | 16 +++ drivers/gpu/drm/i915/intel_lvds.c |3 - drivers/net/arcnet/arcnet.c|2 drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c |3 - drivers/net/ethernet/realtek/8139cp.c | 48 +++-- drivers/net/usb/smsc75xx.c | 12 + drivers/net/wireless/ath/ath9k/htc_drv_init.c |1 drivers/net/wireless/mwifiex/sdio.c|4 - drivers/net/wireless/rt2x00/rt2x00queue.c | 18 --- drivers/tty/serial/mxs-auart.c | 38 +--- fs/notify/fanotify/fanotify_user.c |1 kernel/events/core.c | 30 ++--- kernel/sched/fair.c|2 net/ipv4/sysctl_net_ipv4.c |6 ++ net/ipv6/ip6mr.c |5 ++ net/key/af_key.c |4 + net/mac80211/rx.c | 10 +++- net/sched/sch_atm.c|1 net/sched/sch_cbq.c|1 net/sctp/outqueue.c|8 --- net/wireless/nl80211.c |7 ++- sound/core/compress_offload.c |2 26 files changed, 168 insertions(+), 61 deletions(-) Dan Carpenter (4): fanotify: info leak in copy_event_to_user() arcnet: cleanup sizeof parameter af_key: more info leaks in pfkey messages net_sched: info leak in atm_tc_dump_class() David S. Miller (1): net_sched: Fix stack info leak in cbq_dump_wrr(). Eric Dumazet (1): usbnet: do not pretend to support SG/TSO Greg Kroah-Hartman (1): Linux 3.4.57 H.J. Lu (1): x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz Hannes Frederic Sowa (1): ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup Jacob Keller (1): ixgbe: Fix Tx Hang issue with lldpad on 82598EB Jiri Olsa (1): perf: Fix event group context move Johannes Berg (1): mac80211: fix duplicate retransmission detection Kamal Mostafa (1): drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight Lan Tianyu (1): ACPI / battery: Fix parsing _BIX return value Michal Kazior (1): nl80211: fix mgmt tx status and testmode reporting for netns Michal Tesar (1): sysctl net: Keep tcp_syn_retries inside the boundary Neil Horman (2): sctp: fully initialize sctp_outq in sctp_outq_init 8139cp: Add dma_mapping_error checking Oleksij Rempel (1): ath9k_htc: do some initial hardware configuration Salman Qazi (1): perf: Use css_tryget() to avoid propping up css refcount Stanislaw Gruszka (1): rt2x00: fix stop queue Tomasz Moń (1): mwifiex: Add missing endian conversion. Uwe Kleine-König (2): serial/mxs-auart: fix race condition in interrupt handler serial/mxs-auart: increase time to wait for transmitter to become idle Vinod Koul (1): ALSA: compress: fix the return value for SNDRV_COMPRESS_VERSION Zhu Yanhai (1): sched: Fix the broken sched_rr_get_interval() signature.asc Description: Digital signature
Linux 3.0.90
I'm announcing the release of the 3.0.90 kernel. All users of the 3.0 kernel series must upgrade. The updated 3.0.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.0.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h MAINTAINERS |4 +- Makefile |2 - arch/x86/kernel/i387.c|2 - drivers/acpi/battery.c|2 + drivers/net/arcnet/arcnet.c |2 - drivers/net/usb/smsc75xx.c| 12 ++-- drivers/net/wireless/ath/ath9k/htc_drv_init.c |1 drivers/net/wireless/mwifiex/sdio.c |4 +- drivers/net/wireless/rt2x00/rt2x00queue.c | 18 +++- drivers/tty/serial/mxs-auart.c| 38 +++--- fs/notify/fanotify/fanotify_user.c|1 kernel/events/core.c | 30 +--- kernel/sched_fair.c |2 - net/ipv4/sysctl_net_ipv4.c|6 +++- net/ipv6/ip6mr.c |5 +++ net/key/af_key.c |4 ++ net/mac80211/rx.c | 10 +- net/sched/sch_atm.c |1 net/sched/sch_cbq.c |1 net/sctp/outqueue.c |8 + net/wireless/nl80211.c|7 +++- 21 files changed, 104 insertions(+), 56 deletions(-) Dan Carpenter (4): fanotify: info leak in copy_event_to_user() arcnet: cleanup sizeof parameter af_key: more info leaks in pfkey messages net_sched: info leak in atm_tc_dump_class() David S. Miller (1): net_sched: Fix stack info leak in cbq_dump_wrr(). Eric Dumazet (1): usbnet: do not pretend to support SG/TSO Greg Kroah-Hartman (2): MAINTAINERS: fix up stable_kernel_rules.txt location Linux 3.0.90 H.J. Lu (1): x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz Hannes Frederic Sowa (1): ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup Jiri Olsa (1): perf: Fix event group context move Johannes Berg (1): mac80211: fix duplicate retransmission detection Lan Tianyu (1): ACPI / battery: Fix parsing _BIX return value Michal Kazior (1): nl80211: fix mgmt tx status and testmode reporting for netns Michal Tesar (1): sysctl net: Keep tcp_syn_retries inside the boundary Neil Horman (1): sctp: fully initialize sctp_outq in sctp_outq_init Oleksij Rempel (1): ath9k_htc: do some initial hardware configuration Salman Qazi (1): perf: Use css_tryget() to avoid propping up css refcount Stanislaw Gruszka (1): rt2x00: fix stop queue Tomasz Moń (1): mwifiex: Add missing endian conversion. Uwe Kleine-König (2): serial/mxs-auart: fix race condition in interrupt handler serial/mxs-auart: increase time to wait for transmitter to become idle Zhu Yanhai (1): sched: Fix the broken sched_rr_get_interval() signature.asc Description: Digital signature
Re: Linux 3.0.90
diff --git a/MAINTAINERS b/MAINTAINERS
index d81f637..08e6f61 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5725,7 +5725,6 @@ P:Vincent Sanders
M: Simtec Linux Team
W: http://www.simtec.co.uk/products/EB110ATX/
S: Supported
-F: Documentation/stable_kernel_rules.txt
SIMTEC EB2410ITX (BAST)
P: Ben Dooks
@@ -6041,7 +6040,8 @@ F:arch/alpha/kernel/srm_env.c
STABLE BRANCH
M: Greg Kroah-Hartman
L: sta...@vger.kernel.org
-S: Maintained
+S: Supported
+F: Documentation/stable_kernel_rules.txt
STAGING SUBSYSTEM
M: Greg Kroah-Hartman
diff --git a/Makefile b/Makefile
index 45f74af..4789f7a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 0
-SUBLEVEL = 89
+SUBLEVEL = 90
EXTRAVERSION =
NAME = Sneaky Weasel
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 12aff25..f7183ec 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -51,7 +51,7 @@ void __cpuinit mxcsr_feature_mask_init(void)
clts();
if (cpu_has_fxsr) {
memset(_scratch, 0, sizeof(struct i387_fxsave_struct));
- asm volatile("fxsave %0" : : "m" (fx_scratch));
+ asm volatile("fxsave %0" : "+m" (fx_scratch));
mask = fx_scratch.mxcsr_mask;
if (mask == 0)
mask = 0xffbf;
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 4a15d57..908f40a 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -118,6 +118,7 @@ struct acpi_battery {
struct acpi_device *device;
struct notifier_block pm_nb;
unsigned long update_time;
+ int revision;
int rate_now;
int capacity_now;
int voltage_now;
@@ -350,6 +351,7 @@ static struct acpi_offsets info_offsets[] = {
};
static struct acpi_offsets extended_info_offsets[] = {
+ {offsetof(struct acpi_battery, revision), 0},
{offsetof(struct acpi_battery, power_unit), 0},
{offsetof(struct acpi_battery, design_capacity), 0},
{offsetof(struct acpi_battery, full_charge_capacity), 0},
diff --git a/drivers/net/arcnet/arcnet.c b/drivers/net/arcnet/arcnet.c
index a746ba2..a956053 100644
--- a/drivers/net/arcnet/arcnet.c
+++ b/drivers/net/arcnet/arcnet.c
@@ -1007,7 +1007,7 @@ static void arcnet_rx(struct net_device *dev, int bufnum)
soft =
- lp->hw.copy_from_card(dev, bufnum, 0, , sizeof(ARC_HDR_SIZE));
+ lp->hw.copy_from_card(dev, bufnum, 0, , ARC_HDR_SIZE);
if (pkt.hard.offset[0]) {
ofs = pkt.hard.offset[0];
length = 256 - ofs;
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 2f4775f..be27891 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -43,7 +43,6 @@
#define EEPROM_MAC_OFFSET (0x01)
#define DEFAULT_TX_CSUM_ENABLE (true)
#define DEFAULT_RX_CSUM_ENABLE (true)
-#define DEFAULT_TSO_ENABLE (true)
#define SMSC75XX_INTERNAL_PHY_ID (1)
#define SMSC75XX_TX_OVERHEAD (8)
#define MAX_RX_FIFO_SIZE (20 * 1024)
@@ -1034,17 +1033,14 @@ static int smsc75xx_bind(struct usbnet *dev, struct
usb_interface *intf)
INIT_WORK(>set_multicast, smsc75xx_deferred_multicast_write);
- if (DEFAULT_TX_CSUM_ENABLE) {
+ if (DEFAULT_TX_CSUM_ENABLE)
dev->net->features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
- if (DEFAULT_TSO_ENABLE)
- dev->net->features |= NETIF_F_SG |
- NETIF_F_TSO | NETIF_F_TSO6;
- }
+
if (DEFAULT_RX_CSUM_ENABLE)
dev->net->features |= NETIF_F_RXCSUM;
dev->net->hw_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
- NETIF_F_SG | NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_RXCSUM;
+ NETIF_F_RXCSUM;
/* Init all registers */
ret = smsc75xx_reset(dev);
@@ -1169,8 +1165,6 @@ static struct sk_buff *smsc75xx_tx_fixup(struct usbnet
*dev,
{
u32 tx_cmd_a, tx_cmd_b;
- skb_linearize(skb);
-
if (skb_headroom(skb) < SMSC75XX_TX_OVERHEAD) {
struct sk_buff *skb2 =
skb_copy_expand(skb, SMSC75XX_TX_OVERHEAD, 0, flags);
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 4099712..403d33f 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -873,6 +873,7 @@ static int ath9k_init_device(struct ath9k_htc_priv *priv,
if (error != 0)
goto err_rx;
+ ath9k_hw_disable(priv->ah);
#ifdef CONFIG_MAC80211_LEDS
/* must be initialized before ieee80211_register_hw */
priv->led_cdev.default_trigger =
ieee80211_create_tpt_led_trigger(priv->hw,
diff --git a/drivers/net/wireless/mwifiex/sdio.c
Linux 3.10.6
I'm announcing the release of the 3.10.6 kernel. All users of the 3.10 kernel series must upgrade. The updated 3.10.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.10.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |4 arch/arm/Kconfig |4 arch/arm/include/asm/a.out-core.h | 45 -- arch/arm/include/asm/elf.h |6 arch/arm/include/asm/mmu.h |3 arch/arm/include/asm/mmu_context.h | 20 ++ arch/arm/include/asm/page.h|2 arch/arm/include/asm/processor.h |4 arch/arm/include/asm/thread_info.h |1 arch/arm/include/uapi/asm/Kbuild |1 arch/arm/include/uapi/asm/a.out.h | 34 arch/arm/kernel/entry-armv.S | 103 +++--- arch/arm/kernel/fiq.c | 19 +- arch/arm/kernel/process.c | 46 ++ arch/arm/kernel/signal.c | 52 ++- arch/arm/kernel/signal.h | 12 - arch/arm/kernel/traps.c| 46 +++--- arch/arm/kernel/vmlinux.lds.S | 17 ++ arch/arm/mm/Kconfig| 34 arch/arm/mm/mmu.c | 14 + arch/arm/mm/proc-v7-2level.S |2 arch/arm/mm/proc-v7-3level.S |2 arch/arm/mm/proc-v7.S | 11 - arch/parisc/include/asm/parisc-device.h|3 arch/parisc/kernel/cache.c | 135 +- arch/parisc/kernel/inventory.c |1 arch/powerpc/include/asm/smp.h |4 arch/powerpc/mm/numa.c | 59 ++-- arch/s390/Kconfig |7 arch/s390/include/asm/bitops.h |2 arch/s390/kernel/setup.c |1 arch/s390/mm/init.c|1 arch/s390/oprofile/init.c |2 arch/x86/kernel/early-quirks.c | 14 + arch/x86/kernel/i387.c |2 drivers/acpi/battery.c |2 drivers/block/xen-blkfront.c | 36 ++--- drivers/bluetooth/ath3k.c | 46 +- drivers/bluetooth/btusb.c | 21 +- drivers/char/agp/parisc-agp.c |6 drivers/char/hw_random/bcm2835-rng.c |2 drivers/cpufreq/cpufreq.c | 19 +- drivers/cpuidle/governors/menu.c | 106 -- drivers/dma/pl330.c| 93 + drivers/gpu/drm/i915/intel_ddi.c | 10 - drivers/gpu/drm/i915/intel_display.c |8 - drivers/gpu/drm/i915/intel_drv.h |2 drivers/gpu/drm/radeon/radeon.h|3 drivers/gpu/drm/radeon/radeon_asic.c |8 - drivers/gpu/drm/radeon/radeon_fence.c |2 drivers/gpu/drm/radeon/radeon_uvd.c| 100 ++ drivers/gpu/drm/radeon/rv770.c |2 drivers/hwmon/max6697.c|4 drivers/macintosh/windfarm_rm31.c | 18 +- drivers/net/arcnet/arcnet.c|2 drivers/net/ethernet/atheros/atl1c/atl1c.h |3 drivers/net/ethernet/atheros/atl1c/atl1c_main.c| 40 + drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c |3 drivers/net/ethernet/mellanox/mlx4/fw.c| 11 - drivers/net/ethernet/mellanox/mlx4/main.c |2 drivers/net/ethernet/realtek/8139cp.c | 48 ++ drivers/net/ethernet/sfc/filter.c |4 drivers/net/usb/ax88179_178a.c |9 - drivers/net/usb/smsc75xx.c | 12 - drivers/net/wireless/ath/ath9k/hif_usb.c |4 drivers/net/wireless/ath/ath9k/htc_drv_init.c |1 drivers/net/wireless/ath/wil6210/debugfs.c |4 drivers/net/wireless/iwlwifi/dvm/main.c|2 drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h |1 drivers/net/wireless/iwlwifi/mvm/mac80211.c| 16 ++ drivers/net/wireless/iwlwifi/mvm/scan.c| 15 -- drivers/net/wireless/iwlwifi/mvm/sta.c | 19 +- drivers/net/wireless/iwlwifi/pcie/drv.c|1
Re: Non-enumerable devices on USB and other enumerable buses
On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote: > Looking at the enumerable buses in the kernel I don't see any which have > real support for any kind of registration of devices prior to their > enumeration. Similarly currently all the DT bindings in the kernel I've > been able to notice cover only non-enumerable buses. This generally > makes sense where enumerable buses are used in standard fashions since > the binding would be at best redundant and at worst inaccurate. However > there are often corner cases in embedded systems where hardware has been > hooked up outside of the normal enumeration mechanisms, for example with > software power control or extra signals wired. Not just "embedded", the Macbooks have this same issue as well I'm pretty sure, it's just that we don't know where those GPIOs are in order to be able to use them... > One example that's bugging me right now is that on the Insignal Arndale > platform there's a USB hub connected to one of the USB ports on the SoC > (not as a PHY, it seems we also need the internal PHY running to talk to > the device). The hub needs to be "plugged" into the SoC after the SoC > USB controller has started with some GPIOs so we need to tell the system > that the hub exists and needs to be synchronised with the USB controller. > > Another case that's going to be problematic once it's in mainline is > Slimbus - this is a bus used in some embedded audio subsystems which is > enumerable in a similar manner to USB but where the devices on the bus > are normally powered up only on demand (causing them to hotplug when > used and unplug when idle) and have at least interrupt lines wired to > the SoC using a normal interrupt outside the enumerable bus. > > I know there's been some discussion of this topic but do we have any > general consensus on how to handle such things both from a Linux driver > model point of view and from a DT/ACPI point of view? As these are usually bus-specific things, and really, platform-specific things, I'd fall back and just recommend a "platform driver" that "knows" about where these gpios are, and how/when to enable them, which will cause the discoverable bus logic to kick in now that it notices a device is present/removed. Perhaps a semi-generic "platform" driver could be created, that knows how to handle these settings in the DT, but odds are, that might be difficult to make generic enough to cover a wide range of boards, but without specifics, it's hard to tell. 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: Reading perf counters at ftrace trace boundaries
On 13-08-11 10:47 PM, Andi Kleen wrote: > That's what normal sampling already does. > > If you're worried about systematic shadow effects just randomize a bit. That's actually the point. I'd like to be able to study/compare both approaches. I could be completely off, but I'd like to see if a divide and conquer approach (i.e. based on ftrace) wouldn't take the guesswork out of smart randomization. Just a hunch. -- Karim Yaghmour CEO - Opersys inc. / www.opersys.com http://twitter.com/karimyaghmour -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 04/16] iommu/exynos: allocate lv2 page table from own slab
On Fri, 09 Aug 2013 11:35:20 +0200, Tomasz Figa wrote:
> On Friday 09 of August 2013 17:51:56 Cho KyongHo wrote:
> > On Fri, 09 Aug 2013 09:55:30 +0200, Tomasz Figa wrote:
> > > Hi KyongHo,
> > >
> > > On Friday 09 of August 2013 14:58:49 Cho KyongHo wrote:
> > > > On Thu, 08 Aug 2013 16:00:18 +0200, Tomasz Figa wrote:
> > > > > On Thursday 08 of August 2013 18:38:04 Cho KyongHo wrote:
> > > > > > Since kmalloc() does not guarantee that the allignment of 1KiB
> > > > > > when
> > > > > > it
> > > > > > allocates 1KiB, it is required to allocate lv2 page table from
> > > > > > own
> > > > > > slab that guarantees alignment of 1KiB
> > > > > >
> > > > > > Signed-off-by: Cho KyongHo
> > > > > > ---
> > > > > >
> > > > > > drivers/iommu/exynos-iommu.c | 24
> > > > > > 1 files changed, 20 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/iommu/exynos-iommu.c
> > > > > > b/drivers/iommu/exynos-iommu.c index d90e6fa..a318049 100644
> > > > > > --- a/drivers/iommu/exynos-iommu.c
> > > > > > +++ b/drivers/iommu/exynos-iommu.c
> > > > > > @@ -100,6 +100,8 @@
> > > > > >
> > > > > > #define REG_PB1_SADDR 0x054
> > > > > > #define REG_PB1_EADDR 0x058
> > > > > >
> > > > > > +static struct kmem_cache *lv2table_kmem_cache;
> > > > > > +
> > > > > >
> > > > > > static unsigned long *section_entry(unsigned long *pgtable,
> > > > > > unsigned
> > > > > >
> > > > > > long iova) {
> > > > > >
> > > > > > return pgtable + lv1ent_offset(iova);
> > > > > >
> > > > > > @@ -765,7 +767,8 @@ static void
> > > > > > exynos_iommu_domain_destroy(struct
> > > > > > iommu_domain *domain)
> > > > > >
> > > > > > for (i = 0; i < NUM_LV1ENTRIES; i++)
> > > > > >
> > > > > > if (lv1ent_page(priv->pgtable + i))
> > > > > >
> > > > > > - kfree(__va(lv2table_base(priv->pgtable + i)));
> > > > > > + kmem_cache_free(lv2table_kmem_cache,
> > > > > > +
> > > > > > __va(lv2table_base(priv->pgtable +
> > >
> > > i)));
> > >
> > > > > > free_pages((unsigned long)priv->pgtable, 2);
> > > > > > free_pages((unsigned long)priv->lv2entcnt, 1);
> > > > > >
> > > > > > @@ -861,7 +864,7 @@ static unsigned long *alloc_lv2entry(unsigned
> > > > > > long
> > > > > > *sent, unsigned long iova, if (lv1ent_fault(sent)) {
> > > > > >
> > > > > > unsigned long *pent;
> > > > > >
> > > > > > - pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
> > > > > > + pent = kmem_cache_zalloc(lv2table_kmem_cache,
> > > > > > GFP_ATOMIC);
> > > > > >
> > > > > > BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
> > > > > > if (!pent)
> > > > > >
> > > > > > return ERR_PTR(-ENOMEM);
> > > > > >
> > > > > > @@ -881,7 +884,7 @@ static int lv1set_section(unsigned long
> > > > > > *sent,
> > > > > > phys_addr_t paddr, short *pgcnt)
> > > > > >
> > > > > > if (lv1ent_page(sent)) {
> > > > > >
> > > > > > BUG_ON(*pgcnt != NUM_LV2ENTRIES);
> > > > > >
> > > > > > - kfree(page_entry(sent, 0));
> > > > > > + kmem_cache_free(lv2table_kmem_cache, page_entry(sent,
> > > > > > 0));
> > > > > >
> > > > > > *pgcnt = 0;
> > > > > >
> > > > > > }
> > > > > >
> > > > > > @@ -1082,10 +1085,23 @@ static int __init exynos_iommu_init(void)
> > > > > >
> > > > > > {
> > > > > >
> > > > > > int ret;
> > > > > >
> > > > > > + lv2table_kmem_cache =
> > > > > > kmem_cache_create("exynos-iommu-lv2table",
> > > > > > + LV2TABLE_SIZE, LV2TABLE_SIZE, 0, NULL);
> > > > > > + if (!lv2table_kmem_cache) {
> > > > > > + pr_err("%s: Failed to create kmem cache\n", __func__);
> > > > > > + return -ENOMEM;
> > > > > > + }
> > > > > > +
> > > > > >
> > > > > > ret = platform_driver_register(_sysmmu_driver);
> > > > > >
> > > > > > if (ret == 0)
> > > > > >
> > > > > > - bus_set_iommu(_bus_type, _iommu_ops);
> > > > > > + ret = bus_set_iommu(_bus_type,
> > >
> > > _iommu_ops);
> > >
> > > > > > +
> > > > > > + if (ret) {
> > > > > > + pr_err("%s: Failed to register exynos-iommu driver.\n",
> > > > > > +
> > > > > > __func__);
> > > > > > + kmem_cache_destroy(lv2table_kmem_cache);
> > > > > > + }
> > > > >
> > > > > What about making the return value handling here cleaner? For
> example:
> > > > > lv2table_kmem_cache = kmem_cache_create("exynos-iommu-lv2table",
> > > > >
> > > > > LV2TABLE_SIZE, LV2TABLE_SIZE, 0, NULL);
> > > > >
> > > > > if (!lv2table_kmem_cache) {
> > > > >
> > > > > ...
> > > > > return -ENOMEM;
> > > > >
> > > > > }
> > > > >
> > > > > ret =
Re: [PATCH v9 14/16] iommu/exynos: add support for power management subsystems.
On Fri, 09 Aug 2013 10:32:40 +0200, Tomasz Figa wrote: > On Friday 09 of August 2013 16:49:43 Cho KyongHo wrote: > > On Fri, 09 Aug 2013 01:03:05 +0200, Tomasz Figa wrote: > > > Hi KyongHo, > > > > > > nit: Please drop the trailing dot at the end of patch subject. > > > > Oh. I didn't catch that. > > Thank you. > > > > > On Thursday 08 of August 2013 18:41:17 Cho KyongHo wrote: > > > > This adds support for Advance Power Management and Runtime Power > > > > Management. > > > > > > This patch adds support for system-wide and runtime power management. > > > > Ok. > > > > > > Since System MMU is located in the same local power domain of its > > > > master H/W, System MMU must be initialized before it is working if > > > > its power domain was ever turned off. TLB invalidation according to > > > > unmapping on page tables must also be performed while power domain > > > > is > > > > turned on. > > > > > > > > This patch ensures that resume and runtime_resume(restore_state) > > > > functions in this driver is called before the calls to resume and > > > > runtime_resume callback functions in the drivers of master H/Ws. > > > > Likewise, suspend and runtime_suspend(save_state) functions in this > > > > driver is called after the calls to suspend and runtime_suspend in > > > > the > > > > drivers of master H/Ws. > > > > > > > > In order to get benefit of this support, the master H/W and its > > > > System > > > > MMU must resides in the same power domain in terms of Linux kernel. > > > > If > > > > a master H/W does not use generic I/O power domain, its driver must > > > > call iommu_attach_device() after its local power domain is turned > > > > on, > > > > iommu_detach_device before turned off. > > > > > > I don't get the point of this last paragraph. What a power domain can > > > be in other terms? Is there any other way to support power domains on > > > Exynos than generic power domains? > > > > I just addressed the case a device driver turns off local power of its > > device without the help of generic I/O powerdomain. > > Out of curiosity, do we have such cases for Exynos in mainline kernel? > IMHO this is what the generic PM core is for and drivers shouldn't care > about such low level PM details. I don't know if there is the case and I also agree with you. I hope that there is no case that I addressed. I just mentioned an exceptional case. The best way is that all device drivers of master H/W of System MMU register their defvice in a generic i/o powerdomain. Thank you. KyongHo. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Non-enumerable devices on USB and other enumerable buses
On Sun, 11 Aug 2013, Mark Brown wrote: > Looking at the enumerable buses in the kernel I don't see any which have > real support for any kind of registration of devices prior to their > enumeration. Similarly currently all the DT bindings in the kernel I've > been able to notice cover only non-enumerable buses. This generally > makes sense where enumerable buses are used in standard fashions since > the binding would be at best redundant and at worst inaccurate. However > there are often corner cases in embedded systems where hardware has been > hooked up outside of the normal enumeration mechanisms, for example with > software power control or extra signals wired. > > One example that's bugging me right now is that on the Insignal Arndale > platform there's a USB hub connected to one of the USB ports on the SoC > (not as a PHY, it seems we also need the internal PHY running to talk to > the device). The hub needs to be "plugged" into the SoC after the SoC > USB controller has started with some GPIOs so we need to tell the system > that the hub exists and needs to be synchronised with the USB controller. On the surface, this seems like a particularly simple case. Why wait until the SoC's USB controller has started? Why not "plug in" the hub via the GPIOs right from the beginning? > Another case that's going to be problematic once it's in mainline is > Slimbus - this is a bus used in some embedded audio subsystems which is > enumerable in a similar manner to USB but where the devices on the bus > are normally powered up only on demand (causing them to hotplug when > used and unplug when idle) and have at least interrupt lines wired to > the SoC using a normal interrupt outside the enumerable bus. That is indeed more difficult, because it requires geniune cooperation between the bus and platform subsystems. > I know there's been some discussion of this topic but do we have any > general consensus on how to handle such things both from a Linux driver > model point of view and from a DT/ACPI point of view? The discussion involved some sort of pattern matching based on the device name and the bus, but nothing was ever settled. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the wireless-next tree with the wireless tree
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/iwlwifi/pcie/trans.c between commit eabc4ac5d760
("iwlwifi: pcie: disable L1 Active after pci_enable_device") from
thewireless tree and commit f2532b04b2ec ("iwlwifi: pcie: don't disable
L1 for newest NICs") from the wireless-next tree.
I fixed it up (maybe - see below) and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/wireless/iwlwifi/pcie/trans.c
index 390e2f0,e52d1ce..000
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@@ -1502,16 -1400,22 +1400,22 @@@ struct iwl_trans *iwl_trans_pcie_alloc(
spin_lock_init(_pcie->reg_lock);
init_waitqueue_head(_pcie->ucode_write_waitq);
+ if (pci_enable_device(pdev)) {
+ err = -ENODEV;
+ goto out_no_pci;
+ }
+
- /* W/A - seems to solve weird behavior. We need to remove this if we
-* don't want to stay in L1 all the time. This wastes a lot of power */
- pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
- PCIE_LINK_STATE_CLKPM);
+ if (!cfg->base_params->pcie_l1_allowed) {
+ /*
+* W/A - seems to solve weird behavior. We need to remove this
+* if we don't want to stay in L1 all the time. This wastes a
+* lot of power.
+*/
+ pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S |
+ PCIE_LINK_STATE_L1 |
+ PCIE_LINK_STATE_CLKPM);
+ }
- if (pci_enable_device(pdev)) {
- err = -ENODEV;
- goto out_no_pci;
- }
-
pci_set_master(pdev);
err = pci_set_dma_mask(pdev, DMA_BIT_MASK(36));
pgpJzlGn6GFHO.pgp
Description: PGP signature
Re: Reading perf counters at ftrace trace boundaries
> Indeed. It doesn't actually have to be at every single ftrace > begin/exit. But possibly starting with some kind of every nth and then > drilling down as the culprit is incrementally singled-out. That's what normal sampling already does. If you're worried about systematic shadow effects just randomize a bit. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 3.11-rc5
Sadly, the numerology doesn't quite work out, and while releasing the final 3.11 today would be a lovely coincidence (Windows 3.11 was released twenty years ago today), it is not to be. Instead, we have 3.11-rc5. Which is showing signs of calming down, and is noticeably smaller than previous rc's (both in number of commits and in size of patch). Let's hope that trend isn't just a fluke. There really doesn't seem to be anything major here. The radeon changes are likely the most noticeable, but many of them are for the dynamic power management that is still off by default.. Other than that, misc media fixes, arch updates, some small filesystem updates etc. Nothing really stands out. Linus --- Aaro Koskinen (1): cpufreq: loongson2: fix regression related to clock management Aaron Lu (1): drm/i915: avoid brightness overflow when doing scale Afzal Mohammed (2): ARM: OMAP2+: hwmod: rt address space index for DT ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space Al Viro (1): reiserfs: fix deadlock in umount Alban Browaeys (1): [media] em28xx: fix assignment of the eeprom data Alex Deucher (11): drm/radeon: properly handle pm on gpu reset drm/radeon: select audio dto based on encoder id for DCE3 drm/radeon/dpm: adjust thermal protection requirements drm/radeon/dpm: fix spread spectrum setup (v2) drm/radeon/dpm: adjust power state properly for UVD on SI drm/radeon/dpm: disable sclk ss on rv6xx drm/radeon: fix audio dto calculation on DCE3+ (v3) drm/radeon: always program the MC on startup drm/radeon/cik: use a mutex to properly lock srbm instanced registers drm/radeon/dpm: require rlc for dpm drm/radeon: make missing smc ucode non-fatal Alexander Shiyan (1): [media] media: coda: Fix DT driver data pointer for i.MX27 Alexander Z Lam (2): tracing: Make TRACE_ITER_STOP_ON_FREE stop the correct buffer tracing: Fix reset of time stamps during trace_clock changes Alexey Khoroshilov (1): [media] hdpvr: fix iteration over uninitialized lists in hdpvr_probe() Amit Shah (5): virtio: console: fix race with port unplug and open/close virtio: console: fix race in port_fops_open() and port unplug virtio: console: clean up port data immediately at time of unplug virtio: console: fix raising SIGIO after port unplug virtio: console: return -ENODEV on all read operations after unplug Andrew Vagin (1): tracing: Fix fields of struct trace_iterator that are zeroed by mistake Andrzej Hajda (2): [media] DocBook: upgrade media_api DocBook version to 4.2 [media] v4l2: added missing mutex.h include to v4l2-ctrls.h Andy Lutomirski (2): fs: Fix file mode for O_TMPFILE fs: Allow unprivileged linkat(..., AT_EMPTY_PATH) aka flink Anton Blanchard (1): powerpc: On POWERNV enable PPC_DENORMALISATION by default Aruna Balakrishnaiah (2): powerpc/pseries: Fix buffer overflow when reading from pstore powerpc/pseries: Add backward compatibilty to read old kernel oops-log Asias He (1): virtio-scsi: Fix virtqueue affinity setup Casey Schaufler (1): Smack: IPv6 casting error fix for 3.11 Chen Gang (2): s390/Kconfig: select 'TTY' when 'S390_GUEST' is enabled powerpc/kvm: Add signed type cast for comparation Chris Leech (1): [SCSI] fnic: BUG: sleeping function called from invalid context during probe Christian Eggers (1): spi: spi-davinci: Fix direction in dma_map_single() Christian König (5): drm/radeon: fix halting UVD drm/radeon: only save UVD bo when we have open handles drm/radeon: stop sending invalid UVD destroy msg drm/radeon: add more UVD CS checking drm/radeon: remove unnecessary unpin Clemens Ladisch (1): ALSA: usb-audio: do not trust too-big wMaxPacketSize values Cong Ding (1): avr32: boards/atngw100/mrmt.c: fix building error Curt Brune (1): hwmon: (adt7470) Fix incorrect return code check Daniel Vetter (1): drm/i915: fix gen4 digital port hotplug definitions Dave Airlie (1): drm/ast: invalidate page tables when pinning a BO Dhaval Giani (1): tracing: Fix trace_dump_stack() proto when CONFIG_TRACING is not set Dominik Dingel (1): KVM: s390: move kvm_guest_enter,exit closer to sie Egbert Eich (1): drm/mgag200: Invalidate page tables when pinning a BO Eric Sandeen (1): ext4: destroy ext4_es_cachep on module unload Fabio Estevam (1): i2c: i2c-mxs: Use DMA mode even for small transfers Felipe Contreras (1): ACPI / video: improve quirk check in acpi_video_bqc_quirk() Florian Fainelli (1): MIPS: BMIPS: fix hardware interrupt routing for boot CPU != 0 H.J. Lu (1): x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz Hans Verkuil (2): [media] ml86v7667: fix compile warning: 'ret' set but not used [media] usbtv: fix dependency Hector
Re: Reading perf counters at ftrace trace boundaries
On 13-08-11 10:23 PM, Andi Kleen wrote: > KVM does it, see arch/x86/kvm/pmu.c. Essentially it would be doing RDPMC. Thx for the pointer, appreciated. > But the overhead will be likely very high, some sampling approach > is likely better. Indeed. It doesn't actually have to be at every single ftrace begin/exit. But possibly starting with some kind of every nth and then drilling down as the culprit is incrementally singled-out. -- Karim Yaghmour CEO - Opersys inc. / www.opersys.com http://twitter.com/karimyaghmour -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Reading perf counters at ftrace trace boundaries
Karim Yaghmour writes: > Wondering if there's a way for reading perf counters in the kernel. I'd > like to read/record perf counters on ftrace function tracing > entries/exits to provide a rundown of the value of various counters on > function call boundaries. KVM does it, see arch/x86/kvm/pmu.c. Essentially it would be doing RDPMC. But the overhead will be likely very high, some sampling approach is likely better. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iwlwifi: mvm: make debugfs write() operations write up to count bytes
Some debugfs write() operations of the MVM Firmware will ignore the
count argument, and will copy more bytes than what was specified.
Fix this by getting the right count of bytes.
This will also honor restrictions put on the number of bytes to write.
To be consitant this patch also switches the initializer from
'char buf[x] = {}' to the explicit memset() as it is done in other
places of the same file.
Cc: sta...@vger.kernel.org
Signed-off-by: Djalal Harouni
---
Patch compile tested only.
Dual BSD/GPLv2 license: Ok
drivers/net/wireless/iwlwifi/mvm/debugfs.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/debugfs.c
b/drivers/net/wireless/iwlwifi/mvm/debugfs.c
index 56f6827..ca368db 100644
--- a/drivers/net/wireless/iwlwifi/mvm/debugfs.c
+++ b/drivers/net/wireless/iwlwifi/mvm/debugfs.c
@@ -251,13 +251,16 @@ static ssize_t iwl_dbgfs_power_down_allow_write(struct
file *file,
size_t count, loff_t *ppos)
{
struct iwl_mvm *mvm = file->private_data;
- char buf[8] = {};
+ char buf[8];
int allow;
if (!mvm->ucode_loaded)
return -EIO;
- if (copy_from_user(buf, user_buf, sizeof(buf)))
+ memset(buf, 0, sizeof(buf));
+ if (count > sizeof(buf) - 1)
+ count = sizeof(buf) - 1;
+ if (copy_from_user(buf, user_buf, count))
return -EFAULT;
if (sscanf(buf, "%d", ) != 1)
@@ -278,10 +281,13 @@ static ssize_t iwl_dbgfs_power_down_d3_allow_write(struct
file *file,
size_t count, loff_t *ppos)
{
struct iwl_mvm *mvm = file->private_data;
- char buf[8] = {};
+ char buf[8];
int allow;
- if (copy_from_user(buf, user_buf, sizeof(buf)))
+ memset(buf, 0, sizeof(buf));
+ if (count > sizeof(buf) - 1)
+ count = sizeof(buf) - 1;
+ if (copy_from_user(buf, user_buf, count))
return -EFAULT;
if (sscanf(buf, "%d", ) != 1)
@@ -363,11 +369,14 @@ static ssize_t iwl_dbgfs_pm_params_write(struct file
*file,
struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
struct iwl_mvm *mvm = mvmvif->dbgfs_data;
enum iwl_dbgfs_pm_mask param;
- char buf[32] = {};
+ char buf[32];
int val;
int ret;
- if (copy_from_user(buf, user_buf, sizeof(buf)))
+ memset(buf, 0, sizeof(buf));
+ if (count > sizeof(buf) - 1)
+ count = sizeof(buf) - 1;
+ if (copy_from_user(buf, user_buf, count))
return -EFAULT;
if (!strncmp("keep_alive=", buf, 11)) {
@@ -824,10 +833,13 @@ static ssize_t iwl_dbgfs_d3_sram_write(struct file *file,
size_t count, loff_t *ppos)
{
struct iwl_mvm *mvm = file->private_data;
- char buf[8] = {};
+ char buf[8];
int store;
- if (copy_from_user(buf, user_buf, sizeof(buf)))
+ memset(buf, 0, sizeof(buf));
+ if (count > sizeof(buf) - 1)
+ count = sizeof(buf) - 1;
+ if (copy_from_user(buf, user_buf, count))
return -EFAULT;
if (sscanf(buf, "%d", ) != 1)
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI bus failures with qemu-arm in kernel 3.8+
On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: On Sun, Aug 11, 2013 at 08:54:43AM -0700, Guenter Roeck wrote: Hi, trying to boot arm versatile images with qemu results in the following error if I try to boot with a disk image. sym0: <895a> rev 0x0 at pci :00:0d.0 irq 92 sym0: SCSI BUS has been reset. scsi0 : sym-2.2.3 [...] scsi 0:0:0:0: ABORT operation started scsi 0:0:0:0: ABORT operation timed-out. [...] Yocto's 3.8 kernel images work, upstream kernels 3.8 and later fail (I did not check if/how earlier kernels are affected). Tracking this down shows that the problem is known and has been fixed with commit 351d1339 (arm: add dummy swizzle for versatile with qemu) in the Yocto 3.8 kernel at git://git.yoctoproject.org/linux-yocto-3.8. Would it be possible to submit this patch for inclusion into affected upstream kernels ? It could be that it's qemu's PCI routing is wrong - it's not the first time that qemu has got something wrong. Unfortunately, the PCI routing is totally undocumented, and as I understand it, there's very few backplanes out there now that finding out their real routing is virtually impossible. I'm loathed to change it unless someone can point to a definitive source of information on this. Maybe Paul can comment, as he wrote the patch. If it helps, I tried with qemu 1.4.0 from Ubuntu 13.4, qemu 1.4.0 from Poky 1.4.0-1, and qemu 1.5.2 from the qemu repository. Copying qemu-devel to increase the audience. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 33/35] power: use dev_get_platdata()
On Saturday, August 10, 2013 7:05 AM, Anton Vorontsov wrote: > On Tue, Jul 30, 2013 at 05:19:27PM +0900, Jingoo Han wrote: > > Use the wrapper function for retrieving the platform data instead of > > accessing dev->platform_data directly. > > Um.. what is the benefit or rationale of this patch? CC'ed Joe Perches, Dan Carpenter Hi Anton Vorontsov, Usually, using the wrapper function makes the code simpler. Also, it make the code more readable. Best regards, Jingoo Han -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] tracing: kill the no longer needed PITA code
On Sun, 11 Aug 2013 19:49:29 +0200 Oleg Nesterov wrote: > It seems that you have no more 3.11 patches. > > Should I resend this series? Only if it changed. I'll be looking into 3.12 patches come Monday. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Reading perf counters at ftrace trace boundaries
Wondering if there's a way for reading perf counters in the kernel. I'd like to read/record perf counters on ftrace function tracing entries/exits to provide a rundown of the value of various counters on function call boundaries. [ Steven: apologies for sending you a duplicate here of what I somewhat already sent privately. ] -- Karim Yaghmour CEO - Opersys inc. / www.opersys.com http://twitter.com/karimyaghmour -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] powerpc/perf: Define big-endian version of perf_mem_data_src
On Sat, Aug 10, 2013 at 10:34:58PM -0400, Vince Weaver wrote: > On Sat, 10 Aug 2013, Sukadev Bhattiprolu wrote: > > > > > include/uapi/linux/perf_event.h | 55 > > +++ > > 1 files changed, 55 insertions(+), 0 deletions(-) > > > +#define __PERF_LE 1234 > > +#define __PERF_BE 4321 > > + > > +#if defined(__KERNEL__) > > I could be wrong, but I thought files under uapi weren't supposed to > contain __KERNEL__ code. Wasn't that the whole point of uapi? Yes. > Also having the perf_event interface depend on endianess just seems like a > complicated mess. Can't we just declare the interface to be a certain > endianess and have the kernel byte-swap as necessary? Yes I think so. The interface is already defined and it's little endian, so on big endian we just need to swap. The only part I'm not clear on is how things are handled in perf userspace, it seems to already do some byte swapping. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 9/9] mm: workingset: keep shadow entries in check
I really like the idea of using the spare slots in the radix tree for something useful. It's amazing we haven't used that before. I wonder if with some clever encoding even more information could be fit? e.g. I assume you don't really need all bits of the refault distance, just a good enough approximation. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch for lost wakeups
On Sun, 2013-08-11 at 19:39 +0200, Oleg Nesterov wrote: > On 08/10, Long Gao wrote: > > > > By the way, could you help me join the linux kernel mailling list? > > Do you mean, you want to subscribe? > > Well, from http://www.tux.org/lkml/#s3-1 > > send the line "subscribe linux-kernel your_email@your_ISP" > in the body of the message to majord...@vger.kernel.org > > but since I was never subscribed I do not really know if this works ;) > > > I have sent two letters to "Linux Kernel Mailing > > List", > > but did not receive any confirmation letter, except for two letters > > containing > > instructions, 3X! > > If you simply want to send emails to this list, you do not need > to subscribe. However, I do not see your email in > > http://marc.info/?t=13759860691 > > Perhaps this list doesn't like chinese letters in subject/body? No, we get patches with UTC-16 characters in them OK. The usual reason vger drops an email is if there's a text/html part. The information about what vger drops is here: http://vger.kernel.org/majordomo-info.html 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 17/18] spi: s3c64xx: Always select S3C64XX_PL080 when ARCH_S3C64XX is enabled
Hi Mark, On Sunday 11 of August 2013 20:11:40 Mark Brown wrote: > On Sun, Aug 11, 2013 at 07:59:29PM +0200, Tomasz Figa wrote: > > @@ -366,7 +366,7 @@ config SPI_S3C24XX_FIQ > > > > config SPI_S3C64XX > > > > tristate "Samsung S3C64XX series type SPI" > > depends on (ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5P64X0 || > > ARCH_EXYNOS)> > > - select S3C64XX_DMA if ARCH_S3C64XX && !S3C64XX_PL080 > > + select S3C64XX_PL080 if ARCH_S3C64XX > > > > help > > > > SPI driver for Samsung S3C64XX and newer SoCs. > > Do we need the select here (or should we have other selects for the > Exynos SoCs)? The driver would build fine without this symbol selected, but since it relies on availability of DMA, it doesn't make too much sense to build it this way. This kind of selects makes kernel configuration more user friendly IMHO. Possibly adding appropriate selects (PL330) for s5p* and exynos could make sense. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] Platform: x86: chromeos_laptop - convert to i2c_driver to handle i915 race
Hi Martin, On Sun, Aug 11, 2013 at 12:54 PM, Martin Nordholts wrote: > I get this in dmesg --level err > (--notime) though > > find_i2c_adapter_num: i2c adapter i915 gmbus panel not found on system. > find_i2c_adapter_num: i2c adapter i915 gmbus vga not found on system. > find_i2c_adapter_num: i2c adapter i915 gmbus panel not found on system. > find_i2c_adapter_num: i2c adapter i915 gmbus panel not found on system. > find_i2c_adapter_num: i2c adapter i915 gmbus vga not found on system. > find_i2c_adapter_num: i2c adapter i915 gmbus panel not found on system. > find_i2c_adapter_num: i2c adapter i915 gmbus panel not found on system. > find_i2c_adapter_num: i2c adapter i915 gmbus vga not found on system. > find_i2c_adapter_num: i2c adapter i915 gmbus panel not found on system. > > Personally I don't like getting error messages when the driver works > as designed. I would prefer to have priority lowered to 'notice' on > those. Sounds good to me. I'll make this change. Thanks again! Benson -- Benson Leung Software Engineer, Chrom* OS ble...@chromium.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Non-enumerable devices on USB and other enumerable buses
On Sun, Aug 11, 2013 at 8:08 PM, Mark Brown wrote: > I know there's been some discussion of this topic but do we have any > general consensus on how to handle such things both from a Linux driver > model point of view and from a DT/ACPI point of view? There is precedence for describing enumerated device in the device tree. Real OpenFirmware platforms can and will enumerate the PCI and USB busses and pass a full tree to the OS. I don't think we want to full enumerating like that with either ACPI or FDT, but we could allow for sparse population of devices when something is fixed like a soldered down USB hub or USB Ethernet MAC. To make it work would probably require a hook in the USB enumeration path to look for matching nodes in DT/ACPI and attach it to the struct device. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: SCSI bus failures with qemu-arm in kernel 3.8+
On Sun, Aug 11, 2013 at 08:54:43AM -0700, Guenter Roeck wrote: > Hi, > > trying to boot arm versatile images with qemu results in the following error > if I try to boot with a disk image. > > sym0: <895a> rev 0x0 at pci :00:0d.0 irq 92 > sym0: SCSI BUS has been reset. > scsi0 : sym-2.2.3 > [...] > scsi 0:0:0:0: ABORT operation started > scsi 0:0:0:0: ABORT operation timed-out. > [...] > > Yocto's 3.8 kernel images work, upstream kernels 3.8 and later fail > (I did not check if/how earlier kernels are affected). > > Tracking this down shows that the problem is known and has been fixed with > commit 351d1339 (arm: add dummy swizzle for versatile with qemu) in the > Yocto 3.8 kernel at git://git.yoctoproject.org/linux-yocto-3.8. > > Would it be possible to submit this patch for inclusion into affected > upstream kernels ? It could be that it's qemu's PCI routing is wrong - it's not the first time that qemu has got something wrong. Unfortunately, the PCI routing is totally undocumented, and as I understand it, there's very few backplanes out there now that finding out their real routing is virtually impossible. I'm loathed to change it unless someone can point to a definitive source of information on this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 8/9] mm: thrash detection-based file cache sizing
On 08/07/2013 12:44 AM, Johannes Weiner wrote: To accomplish this, a per-zone counter is increased every time a page is evicted and a snapshot of that counter is stored as shadow entry in the page's now empty page cache radix tree slot. Upon refault of that page, the difference between the current value of that counter and the shadow entry value is called the refault distance. It tells how many pages have been evicted from the zone since that page's eviction, This explanation of refault distance seems correct... which is how many page slots are missing from the zone's inactive list for this page to get accessed twice while in memory. But this part seems slightly incorrect. IMHO the correct formulation would be "...how many page slots are AT MOST missing...". See below. If the number of missing slots is less than or equal to the number of active pages, increasing the inactive list at the cost of the active list would give this thrashing set a chance to establish itself: eviction counter = 4 evicted inactive active Page cache data: [ a b c d ] [ e f g h i j k ] [ l m n ] Shadow entries: 0 1 2 3 Refault distance: 4 3 2 1 Consider here that if 'd' was now accessed before 'c', I think 'e' would be evicted and eviction counter would be incremented to 5. So for 'c' you would now say that three slots would prevent the refault, but in fact two would still be sufficient. This potential imprecision could make the algorithm challenge more active pages than it should, but I am not sure how bad the consequences could be... so just pointing it out. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: build failure after merge of the ext4 tree
Sam, All,
On 2013-08-09 13:42 +0200, Sam Ravnborg spake thusly:
> On Thu, Aug 08, 2013 at 11:54:49PM +0200, Yann E. MORIN wrote:
> > Stephen, All,
> >
> > On 2013-08-08 21:16 +0200, Yann E. MORIN spake thusly:
> > > On 2013-08-08 10:36 +1000, Stephen Rothwell spake thusly:
> > > > On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell
> > > >
> > > > wrote:
> > > > >
> > > > > More quick testing with an empty file: v3.9 is OK, v3.10 gives
> > > > > CONFIG_MODULES unset.
> > >
> > > Sorry, I don't understand the above. Can you elaborate on what you did,
> > > what you got, what expected, so I can try to reproduce and fix this,
> > > please?
> >
> > Ok, I've had a look in the linux-next archives, and I think I got it.
> > Is the following right?
> >
> > git clean -d; git clean -dX # To be sure tree is clean
> > touch empty
> > make KCONFIG_ALLCONFIG=empty allmodconfig
> > grep MODULES .config
> > $ CONFIG_MODULES is not set
> >
> > If so, I think I found the reason: the modules symbol is _always_ set to
> > being valid as soon as KCONFIG_ALLCONFIG is read, even if it was not
> > present in that file.
> >
> > Since it is set to be valid, the following change means it is not
> > affected another value later on.
> >
> > So, I wonder what the best option is:
> > 1- revert the following, and find another solution,
> > 2- de-specialise the modules symbol,
> > 3- or further specialise the modules symbol.
>
> If we drop the special handling of "MODULES" and introduced
> the following in we may fix it - hopefully:
>
> config MODULES
> option modules
>
> The option handling is already in place. It is even documented :-)
Yes, indeed, that one is pretty easy! :-)
> At least we could then drop the sym_lookup here (zconf.y):
> if (!modules_sym->prop) {
> struct property *prop;
>
> prop = prop_alloc(P_DEFAULT, modules_sym);
> prop->expr = expr_alloc_symbol(sym_lookup("MODULES", 0));
> }
> Without the sym_lookup I think the symbol will not be defined and tus not
> marked valid.
Sorry, I don't understand what we should do here.
>From what I understand, here's what happens:
- there's no symbol that declared the 'modules' option, so the
modules_sym->prop is NULL;
- so we look for the symbol 'MODULES' and use that as the symbol used
to evaluate if tristates are enabled.
So, now we have 'option modules' added to MODULES, we never enter this
if() condition.
But what would happen to other projects that do not have a symbol set
with 'option modules' and no 'MODULES' symbol? Surely, those projects do
not need tristates, but what should the code do in this case?
So, I don't know what to replace this 'sym_lookup("MODULES", 0)' with.
> Soory - no patch as I am busy with day-time job stuff.
I hope you can share some guidnce here, please... ;-)
Regards,
Yann E. MORIN.
--
.-..--..
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `.---: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. |
'--^---^--^'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] coccinelle: replace 0/1 with false/true in functions returning bool
Acked-by: Julia Lawall
On Sun, 11 Aug 2013, Rasmus Villemoes wrote:
> This semantic patch replaces "return {0,1};" with "return
> {false,true};" in functions returning bool.
>
> Signed-off-by: Rasmus Villemoes
> ---
> v2: Simplified script, and eliminate whitespace mangling at the same
> time. Thanks to Julia Lawall.
>
> v3: Further improvements from Julia. In particular, it now also does
> header files.
>
> scripts/coccinelle/misc/boolreturn.cocci | 58
> ++
> 1 file changed, 58 insertions(+)
> create mode 100644 scripts/coccinelle/misc/boolreturn.cocci
>
> diff --git a/scripts/coccinelle/misc/boolreturn.cocci
> b/scripts/coccinelle/misc/boolreturn.cocci
> new file mode 100644
> index 000..a43c7b0
> --- /dev/null
> +++ b/scripts/coccinelle/misc/boolreturn.cocci
> @@ -0,0 +1,58 @@
> +/// Return statements in functions returning bool should use
> +/// true/false instead of 1/0.
> +//
> +// Confidence: High
> +// Options: --no-includes --include-headers
> +
> +virtual patch
> +virtual report
> +virtual context
> +
> +@r1 depends on patch@
> +identifier fn;
> +typedef bool;
> +symbol false;
> +symbol true;
> +@@
> +
> +bool fn ( ... )
> +{
> +<...
> +return
> +(
> +- 0
> ++ false
> +|
> +- 1
> ++ true
> +)
> + ;
> +...>
> +}
> +
> +@r2 depends on report || context@
> +identifier fn;
> +position p;
> +@@
> +
> +bool fn ( ... )
> +{
> +<...
> +return
> +(
> +* 0@p
> +|
> +* 1@p
> +)
> + ;
> +...>
> +}
> +
> +
> +@script:python depends on report@
> +p << r2.p;
> +fn << r2.fn;
> +@@
> +
> +msg = "WARNING: return of 0/1 in function '%s' with return type bool" % fn
> +coccilib.report.print_report(p[0], msg)
> --
> 1.7.9.5
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] SCSI fixes for 3.11-rc4
This is three bug fixes: An fnic warning caused by sleeping under a
lock, a major regression with our updated WRITE SAME/UNMAP logic which
caused tons of USB devices (and one RAID card) to cease to function and
a megaraid_sas firmware initialisation problem which causes kdump
failures.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Chris Leech (1):
fnic: BUG: sleeping function called from invalid context during probe
Martin K. Petersen (1):
Don't attempt to send extended INQUIRY command if skip_vpd_pages is set
sumit.sax...@lsi.com (1):
megaraid_sas: megaraid_sas driver init fails in kdump kernel
The diffstat is:
drivers/scsi/fnic/fnic.h | 2 +-
drivers/scsi/fnic/fnic_main.c | 22 +-
drivers/scsi/megaraid/megaraid_sas_base.c | 20 +++-
drivers/scsi/scsi.c | 3 +++
4 files changed, 28 insertions(+), 19 deletions(-)
And the full diff is attached below.
James
---
diff --git a/drivers/scsi/fnic/fnic.h b/drivers/scsi/fnic/fnic.h
index b6d1f92..c18c681 100644
--- a/drivers/scsi/fnic/fnic.h
+++ b/drivers/scsi/fnic/fnic.h
@@ -38,7 +38,7 @@
#define DRV_NAME "fnic"
#define DRV_DESCRIPTION"Cisco FCoE HBA Driver"
-#define DRV_VERSION"1.5.0.22"
+#define DRV_VERSION"1.5.0.23"
#define PFXDRV_NAME ": "
#define DFX DRV_NAME "%d: "
diff --git a/drivers/scsi/fnic/fnic_main.c b/drivers/scsi/fnic/fnic_main.c
index 5f09d18..42e15ee 100644
--- a/drivers/scsi/fnic/fnic_main.c
+++ b/drivers/scsi/fnic/fnic_main.c
@@ -642,19 +642,6 @@ static int fnic_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
INIT_WORK(>fip_frame_work, fnic_handle_fip_frame);
INIT_WORK(>event_work, fnic_handle_event);
skb_queue_head_init(>fip_frame_queue);
- spin_lock_irqsave(_list_lock, flags);
- if (!fnic_fip_queue) {
- fnic_fip_queue =
- create_singlethread_workqueue("fnic_fip_q");
- if (!fnic_fip_queue) {
- spin_unlock_irqrestore(_list_lock, flags);
- printk(KERN_ERR PFX "fnic FIP work queue "
-"create failed\n");
- err = -ENOMEM;
- goto err_out_free_max_pool;
- }
- }
- spin_unlock_irqrestore(_list_lock, flags);
INIT_LIST_HEAD(>evlist);
INIT_LIST_HEAD(>vlans);
} else {
@@ -960,6 +947,13 @@ static int __init fnic_init_module(void)
spin_lock_init(_list_lock);
INIT_LIST_HEAD(_list);
+ fnic_fip_queue = create_singlethread_workqueue("fnic_fip_q");
+ if (!fnic_fip_queue) {
+ printk(KERN_ERR PFX "fnic FIP work queue create failed\n");
+ err = -ENOMEM;
+ goto err_create_fip_workq;
+ }
+
fnic_fc_transport = fc_attach_transport(_fc_functions);
if (!fnic_fc_transport) {
printk(KERN_ERR PFX "fc_attach_transport error\n");
@@ -978,6 +972,8 @@ static int __init fnic_init_module(void)
err_pci_register:
fc_release_transport(fnic_fc_transport);
err_fc_transport:
+ destroy_workqueue(fnic_fip_queue);
+err_create_fip_workq:
destroy_workqueue(fnic_event_queue);
err_create_fnic_workq:
kmem_cache_destroy(fnic_io_req_cache);
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 0177295..1f0ca68 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -3547,11 +3547,21 @@ static int megasas_init_fw(struct megasas_instance
*instance)
break;
}
- /*
-* We expect the FW state to be READY
-*/
- if (megasas_transition_to_ready(instance, 0))
- goto fail_ready_state;
+ if (megasas_transition_to_ready(instance, 0)) {
+ atomic_set(>fw_reset_no_pci_access, 1);
+ instance->instancet->adp_reset
+ (instance, instance->reg_set);
+ atomic_set(>fw_reset_no_pci_access, 0);
+ dev_info(>pdev->dev,
+ "megasas: FW restarted successfully from %s!\n",
+ __func__);
+
+ /*waitting for about 30 second before retry*/
+ ssleep(30);
+
+ if (megasas_transition_to_ready(instance, 0))
+ goto fail_ready_state;
+ }
/*
* MSI-X host index 0 is common for all adapter.
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 3b1ea34..eaa808e 100644
--- a/drivers/scsi/scsi.c
+++
[PATCH v3] coccinelle: replace 0/1 with false/true in functions returning bool
This semantic patch replaces "return {0,1};" with "return
{false,true};" in functions returning bool.
Signed-off-by: Rasmus Villemoes
---
v2: Simplified script, and eliminate whitespace mangling at the same
time. Thanks to Julia Lawall.
v3: Further improvements from Julia. In particular, it now also does
header files.
scripts/coccinelle/misc/boolreturn.cocci | 58 ++
1 file changed, 58 insertions(+)
create mode 100644 scripts/coccinelle/misc/boolreturn.cocci
diff --git a/scripts/coccinelle/misc/boolreturn.cocci
b/scripts/coccinelle/misc/boolreturn.cocci
new file mode 100644
index 000..a43c7b0
--- /dev/null
+++ b/scripts/coccinelle/misc/boolreturn.cocci
@@ -0,0 +1,58 @@
+/// Return statements in functions returning bool should use
+/// true/false instead of 1/0.
+//
+// Confidence: High
+// Options: --no-includes --include-headers
+
+virtual patch
+virtual report
+virtual context
+
+@r1 depends on patch@
+identifier fn;
+typedef bool;
+symbol false;
+symbol true;
+@@
+
+bool fn ( ... )
+{
+<...
+return
+(
+- 0
++ false
+|
+- 1
++ true
+)
+ ;
+...>
+}
+
+@r2 depends on report || context@
+identifier fn;
+position p;
+@@
+
+bool fn ( ... )
+{
+<...
+return
+(
+* 0@p
+|
+* 1@p
+)
+ ;
+...>
+}
+
+
+@script:python depends on report@
+p << r2.p;
+fn << r2.fn;
+@@
+
+msg = "WARNING: return of 0/1 in function '%s' with return type bool" % fn
+coccilib.report.print_report(p[0], msg)
--
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: Cannot hot remove a memory device
On Thursday, August 08, 2013 04:50:42 PM Toshi Kani wrote: > On Fri, 2013-08-09 at 00:12 +0200, Rafael J. Wysocki wrote: > > On Thursday, August 08, 2013 11:15:20 AM Toshi Kani wrote: > > > On Fri, 2013-08-02 at 18:04 -0600, Toshi Kani wrote: > > > > On Sat, 2013-08-03 at 01:43 +0200, Rafael J. Wysocki wrote: > > > > > On Friday, August 02, 2013 03:46:15 PM Toshi Kani wrote: > > > > > > On Thu, 2013-08-01 at 23:43 +0200, Rafael J. Wysocki wrote: > > > : > > > > > > I think it fails with -EINVAL at the place with dev_warn(dev, "ACPI > > > > > > handle is already set\n"). When two ACPI memory objects associate > > > > > > with > > > > > > a same memory block, the bind procedure of the 2nd ACPI memory > > > > > > object > > > > > > sees that ACPI_HANDLE(dev) is already set to the 1st ACPI memory > > > > > > object. > > > > > > > > > > That sound's plausible, but I wonder how we can fix that? > > > > > > > > > > There's no way for a single physical device to have two different ACPI > > > > > "companions". It looks like the memory blocks should be 64 M each in > > > > > that > > > > > case. Or we need to create two child devices for each memory block > > > > > and > > > > > associate each of them with an ACPI object. That would lead to > > > > > complications > > > > > in the user space interface, though. > > > > > > > > Right. Even bigger issue is that I do not think __add_pages() and > > > > __remove_pages() can add / delete a memory chunk that is less than > > > > 128MB. 128MB is the granularity of them. So, we may just have to fail > > > > this case gracefully. > > > > > > FYI: I have submitted the patch blow to close this part of the issue... > > > > > > https://lkml.org/lkml/2013/8/8/396 > > > > That looks good to me, but we'd still need to make it possible to have > > memory blocks smaller than 128 MB ... > > Do you mean acpi_bind_one() needs to be able to handle such case? If > so, it should not be a problem since a memory block device won't be > created when add_memory() fails with the change above. So, there is no > binding to be done. If you mean add_memory() needs to be able to handle > a smaller range, that's quite a tough one unless we make the section > size smaller. > > BTW, when add_memory() fails, the memory hot-add request still succeeds > with no driver attached. This seems logical, but the added device is > useless when no handler is attached. And it does not allow ejecting the > device with no handler. I am not too worry about this since this is a > rare case, but it reminded me that the framework won't handle rollback. I'm not sure which rollback you mean. During removal? There are two slight problems here in my view. First, even if the device cannot be ejected directly, it still will be removed when its parent is ejected, so it may be more consistent to just allow everything to be ejected regardless of whether or not it has a scan handler. Second, I guess the removal is undesirable for memory devices for which the registration of the scan handler failed, so it would be good to fail the "offline" of such devices regardless of how we get there. That's why I thought it would be good to have an "offline disabled" flag in struct acpi_device. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ACPI, cpu hotplug: move try_offline_node() after acpi_unmap_lsapic()
On Friday, August 09, 2013 08:11:19 PM Toshi Kani wrote: > On Sat, 2013-08-10 at 01:29 +0200, Rafael J. Wysocki wrote: > > On Friday, August 09, 2013 04:16:56 PM Toshi Kani wrote: > > > On Fri, 2013-08-09 at 15:28 +0800, Tang Chen wrote: > > > > On 08/07/2013 12:56 AM, Toshi Kani wrote: > > > > > On Tue, 2013-08-06 at 19:11 +0900, Yasuaki Ishimatsu wrote: > > > > >> try_offline_node() checks that all cpus related with removed node > > > > >> have been > > > > >> removed by using cpu_present_bits. If all cpus related with removed > > > > >> node have > > > > >> been removed, try_offline_node() clears the node information. > > > > >> > > > > >> But try_offline_node() called from acpi_processor_remove() never > > > > >> clears > > > > >> the node information. For disabling cpu_present_bits, > > > > >> acpi_unmap_lsapic() > > > > >> need be called. But acpi_unmap_lsapic() is called after > > > > >> try_offline_node() > > > > >> runs. So when try_offline_node() runs, the cpu's cpu_present_bits is > > > > >> always > > > > >> set. > > > > >> > > > > >> This patch moves try_offline_node() after acpi_unmap_lsapic(). > > > > >> > > > > >> Signed-off-by: Yasuaki Ishimatsu > > > > > > > > > > The change looks good to me. > > > > > > > > > > Acked-by: Toshi Kani > > > > > > > > > > BTW, do you know why try_offline_node() has to use stop_machine()? > > > > > > > > try_offline_node() is used to check if the node could be hot-removed > > > > after each memory or cpu hot-remove operation. > > > > > > > > In memory hot-remove path, we have lock_memory_hotplug() to series all > > > > the memory hot-remove options. > > > > > > > > But when doing cpu hot-remove, > > > > > > > > acpi_processor_remove() > > > > |->try_offline_node() > > > > > > > > There is no lock to protect it. I think, when we are going to hot-remove > > > > a node, others should not do any memory or cpu hotplug operation. In > > > > memory > > > > hotplug path, we have lock_memory_hotplug(). But in cpu hotplug path, I > > > > didn't find any lock. So we used stop_machine() to call > > > > check_cpu_on_node(). > > > > If we find any cpu still present, we return and do not remove the node. > > > > > > CPU/Memory hotplug operations and sysfs eject are serialized with > > > acpi_os_hotplug_execute(). CPU online/offline is protected by > > > cpu_hotplug_[begin|done]() and [get|put]_online_cpus(). But, yes, > > > online/offline and hotplug operations are not serialized. I tried to > > > serialize them before, but that framework was not well received. > > > > What about lock_device_hotplug()? It is taken by both online/offline and > > the ACPI hotplug code, isn't it? > > Oh, that's right! I forgot about this one. Yes, lock_device_hotplug() > nicely protects online/offline and hotplug operations. :-) > > > > Anyway, it looks to me that cpu_up()->mem_online_node() path can race > > > with try_offline_node(). > > > > It can in principle, but I'm not sure if there's a way to trigger that > > race. Do you have an example? > > With lock_device_hotplug(), I agree that we do not have this race > condition -- cpu_up() may not run while other hotplug is running. > store_online() will be blocked at lock_device_hotplug() in such case. > When store_online() acquired the lock, this CPU may have been deleted. > So, we still need to make sure that this case is handled properly. Yes. > I suppose sysfs keeps *dev valid with ref_count (Is that right?). Yes, it does. > I think cpu_up() needs to check with cpu_present(), not cpu_possible(), at > the top. Otherwise, cpu_to_node(cpu) may return NUMA_NO_NODE (-1), which is > probably not a good value for node_online(nid). We do cpu_to_node(cpuid) in cpu_subsys_online() before that, so maybe it's better to check the result already there and bail out if that's negative? Something like the patch below. Thanks, Rafael --- drivers/base/cpu.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) Index: linux-pm/drivers/base/cpu.c === --- linux-pm.orig/drivers/base/cpu.c +++ linux-pm/drivers/base/cpu.c @@ -43,11 +43,14 @@ static int __ref cpu_subsys_online(struc struct cpu *cpu = container_of(dev, struct cpu, dev); int cpuid = dev->id; int from_nid, to_nid; - int ret; + int ret = -ENODEV; cpu_hotplug_driver_lock(); from_nid = cpu_to_node(cpuid); + if (from_nid == NUMA_NO_NODE) + goto out; + ret = cpu_up(cpuid); /* * When hot adding memory to memoryless node and enabling a cpu @@ -57,6 +60,7 @@ static int __ref cpu_subsys_online(struc if (from_nid != to_nid) change_cpu_under_node(cpu, from_nid, to_nid); + out: cpu_hotplug_driver_unlock(); return ret; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More
[PATCH 1/1] mtd: mtdoops: fix for a potential memory leak in mtdoops_notify_remove
we are allocating cxt->oops_page_used using vmalloc in mtdoops_notify_add for every mtd_info addition but not freeing it in mtdoops_notify_remove Signed-off-by: Nilanjan Roychowdhury --- drivers/mtd/mtdoops.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/mtdoops.c b/drivers/mtd/mtdoops.c index 97bb8f6..02f49aa 100644 --- a/drivers/mtd/mtdoops.c +++ b/drivers/mtd/mtdoops.c @@ -386,6 +386,7 @@ static void mtdoops_notify_remove(struct mtd_info *mtd) cxt->mtd = NULL; flush_work(>work_erase); flush_work(>work_write); + vfree(cxt->oops_page_used); } -- 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 0/1] Platform: x86: chromeos_laptop - convert to i2c_driver to handle i915 race
2013/8/7 Benson Leung > > If you get a chance, could you let me know if my deferred probe > changes work well in your configuration? I can confirm that your changes works, i.e. the touchpad and touchscreen works directly after boot on my 32GB non-LTE Chromebook Pixel. I applied the patches on a clean 3.11-rc4 tree using a localmodconfig on Debian 7.1. I get this in dmesg --level err (--notime) though find_i2c_adapter_num: i2c adapter i915 gmbus panel not found on system. find_i2c_adapter_num: i2c adapter i915 gmbus vga not found on system. find_i2c_adapter_num: i2c adapter i915 gmbus panel not found on system. find_i2c_adapter_num: i2c adapter i915 gmbus panel not found on system. find_i2c_adapter_num: i2c adapter i915 gmbus vga not found on system. find_i2c_adapter_num: i2c adapter i915 gmbus panel not found on system. find_i2c_adapter_num: i2c adapter i915 gmbus panel not found on system. find_i2c_adapter_num: i2c adapter i915 gmbus vga not found on system. find_i2c_adapter_num: i2c adapter i915 gmbus panel not found on system. Personally I don't like getting error messages when the driver works as designed. I would prefer to have priority lowered to 'notice' on those. Regards, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 17/18] spi: s3c64xx: Always select S3C64XX_PL080 when ARCH_S3C64XX is enabled
On Sun, Aug 11, 2013 at 07:59:29PM +0200, Tomasz Figa wrote: > @@ -366,7 +366,7 @@ config SPI_S3C24XX_FIQ > config SPI_S3C64XX > tristate "Samsung S3C64XX series type SPI" > depends on (ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5P64X0 || ARCH_EXYNOS) > - select S3C64XX_DMA if ARCH_S3C64XX && !S3C64XX_PL080 > + select S3C64XX_PL080 if ARCH_S3C64XX > help > SPI driver for Samsung S3C64XX and newer SoCs. Do we need the select here (or should we have other selects for the Exynos SoCs)? signature.asc Description: Digital signature
Non-enumerable devices on USB and other enumerable buses
Looking at the enumerable buses in the kernel I don't see any which have real support for any kind of registration of devices prior to their enumeration. Similarly currently all the DT bindings in the kernel I've been able to notice cover only non-enumerable buses. This generally makes sense where enumerable buses are used in standard fashions since the binding would be at best redundant and at worst inaccurate. However there are often corner cases in embedded systems where hardware has been hooked up outside of the normal enumeration mechanisms, for example with software power control or extra signals wired. One example that's bugging me right now is that on the Insignal Arndale platform there's a USB hub connected to one of the USB ports on the SoC (not as a PHY, it seems we also need the internal PHY running to talk to the device). The hub needs to be "plugged" into the SoC after the SoC USB controller has started with some GPIOs so we need to tell the system that the hub exists and needs to be synchronised with the USB controller. Another case that's going to be problematic once it's in mainline is Slimbus - this is a bus used in some embedded audio subsystems which is enumerable in a similar manner to USB but where the devices on the bus are normally powered up only on demand (causing them to hotplug when used and unplug when idle) and have at least interrupt lines wired to the SoC using a normal interrupt outside the enumerable bus. I know there's been some discussion of this topic but do we have any general consensus on how to handle such things both from a Linux driver model point of view and from a DT/ACPI point of view? signature.asc Description: Digital signature
Re: Should unprivileged linkat(..., AT_EMPTY_PATH) work on O_TMPFILE files?
On Sun, Aug 11, 2013 at 9:45 AM, Aneesh Kumar K.V
wrote:
> Andy Lutomirski writes:
>
>> The change:
>>
>> commit f4e0c30c191f87851c4a53454abb55ee276f4a7e
>> Author: Al Viro
>> Date: Tue Jun 11 08:34:36 2013 +0400
>>
>> allow the temp files created by open() to be linked to
>>
>> O_TMPFILE | O_CREAT => linkat() with AT_SYMLINK_FOLLOW and
>> /proc/self/fd/
>> as oldpath (i.e. flink()) will create a link
>> O_TMPFILE | O_CREAT | O_EXCL => ENOENT on attempt to link those guys
>>
>> Signed-off-by: Al Viro
>>
>> makes it possible to hardlink an O_TMPFILE file using procfs. Should
>> linkat(fd, "", newdirfd, newpath, AT_EMPTY_PATH) also work?
>>
>> AFAICS it currently requires CAP_DAC_READ_SEARCH, but I'm a bit
>> confused as to why linkat(..., AT_EMPTY_PATH) should have a stricter
>> check than linkat(AT_FDCWD, "/proc/self/fd/n", ...,
>> AT_SYMLINK_FOLLOW), (The relevant change is
>> 11a7b371b64ef39fc5fb1b6f2218eef7c4d035e3.)
>>
>> FWIW, this program works on Linux 3.9, which makes me doubt that the
>> security restriction on linkat is doing any good:
>>
>> #include
>> #include
>> #include
>> #include
>>
>> int main(int argc, char **argv)
>> {
>> char buf[128];
>>
>> if (argc != 3)
>> errx(1, "Usage: flink FD PATH");
>>
>> sprintf(buf, "/proc/self/fd/%d", atoi(argv[1]));
>> if (linkat(AT_FDCWD, buf, AT_FDCWD, argv[2], AT_SYMLINK_FOLLOW) != 0)
>> err(1, "linkat");
>> return 0;
>> }
>>
>>
>> Removing the check from the AT_EMPTY_PATH case would simplify code
>> that wants to write a file, fsync it, and then flink it in.
>
> I understand that this got merged upstream. But in case of the above
> test we would walk the path pointed by /proc/self/fd/ right ?
>
> ie,
>
> 20 -> /home/no-access/k
>
> will the above test work ? Now if i pass the '20' to another application
> I can affectively create a hardlink to that outside no-access and if k
> happens to have 'r' for others, then everybody will be able to read
> right ?. I understand that limitting the read access based on directory
> permission is not a good idea. But aren't we expected to keep that ?
The symlinks in /proc/self/fd are rather magical and don't actually
walk the path. Give it a try :)
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
> Оригинално писмо
>От: Dave Martin
>Относно: Re: [PATCH v3 1/2] ARM: OMAP: Add secure function omap_smc3() which
calling instruction smc #1
>До: Pali Rohár
>Изпратено на: Понеделник, 2013, Август 5 16:29:44 EEST
>
>
>On Sun, Aug 04, 2013 at 10:45:00AM +0200, Pali Rohár wrote:
>> Here is new version (v3) of omap secure part patch:
>>
>> Other secure functions omap_smc1() and omap_smc2() calling instruction smc
>> #0
>> but Nokia RX-51 board needs to call smc #1 for PPA access.
>>
>> Signed-off-by: Ivaylo Dimitrov
>> Signed-off-by: Pali Rohár
>> ---
>> diff --git a/arch/arm/mach-omap2/omap-secure.h
>> b/arch/arm/mach-omap2/omap-secure.h
>> index 0e72917..c4586f4 100644
>> --- a/arch/arm/mach-omap2/omap-secure.h
>> +++ b/arch/arm/mach-omap2/omap-secure.h
>> @@ -51,6 +51,7 @@
>> extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
>> u32 arg1, u32 arg2, u32 arg3, u32 arg4);
>> extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
>> +extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
>> extern phys_addr_t omap_secure_ram_mempool_base(void);
>> extern int omap_secure_ram_reserve_memblock(void);
>>
>> diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
>> index f6441c1..7bbc043 100644
>> --- a/arch/arm/mach-omap2/omap-smc.S
>> +++ b/arch/arm/mach-omap2/omap-smc.S
>> @@ -1,9 +1,11 @@
>> /*
>> - * OMAP44xx secure APIs file.
>> + * OMAP34xx and OMAP44xx secure APIs file.
>> *
>> * Copyright (C) 2010 Texas Instruments, Inc.
>> * Written by Santosh Shilimkar
>> *
>> + * Copyright (C) 2012 Ivaylo Dimitrov
>> + * Copyright (C) 2013 Pali Rohár
>> *
>> * This program is free software,you can redistribute it and/or modify
>> * it under the terms of the GNU General Public License version 2 as
>> @@ -54,6 +56,23 @@ ENTRY(omap_smc2)
>> ldmfd sp!, {r4-r12, pc}
>> ENDPROC(omap_smc2)
>>
>> +/**
>> + * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
>> + * Low level common routine for secure HAL and PPA APIs via smc #1
>> + * r0 - @service_id: Secure Service ID
>> + * r1 - @process_id: Process ID
>> + * r2 - @flag: Flag to indicate the criticality of operation
>> + * r3 - @pargs: Physical address of parameter list
>> + */
>> +ENTRY(omap_smc3)
>> + stmfd sp!, {r4-r11, lr}
>> + mov r12, r0 @ Copy the secure service ID
>> + mov r6, #0xff @ Indicate new Task call
>> + dsb @ Memory Barrier
>
>Can you explain _why_ the barrier is there? The reader doesn't need to
>be told that a barrier instruction is a barrier instruction.
>
>Cheers
>---Dave
>
Hi Dave,
Would quoting Santosh's explanation "DSBs were needed on OMAP for power
sequencing." do the job?
Something like "@ Needed on OMAP for power sequencing" instead of "@ Memory
Barrier".
I want to be sure I correctly understand your requirement.
Regards,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/16] sound/soc/pxa/mioa701_wm9713.c: Avoid using ARRAY_AND_SIZE(e) as a function argument
On Sun, Aug 11, 2013 at 06:51:42PM +0200, Julia Lawall wrote: > From: Julia Lawall > > Replace ARRAY_AND_SIZE(e) in function argument position to avoid hiding the > arity of the called function. Applied, thanks. signature.asc Description: Digital signature
[PATCH 00/18] ARM: s3c64xx: Let amba-pl08x driver handle DMA
This is first non-RFC version of my patches extending support of amba-pl08x DMA engine driver to PL080S DMA engine (PL080 modified by Samsung) found in Samsung S3C64xx SoCs. Due to changes scattered across different areas of kernel, patches are based on merged 3 branches: - for-next of Kgene's Samsung tree, - clk-next of Mike's clock tree, - next of Vinod's slave DMA tree. To ease testing I have prepared a branch in my private tree for anyone willing to check the patches out: git://github.com/tom3q/linux.git v3.12-pl080 Dependencies (already applied in my branch): - for patches 14 and 16 - CCF-based clock driver for s3c64xx. Some of the patches not related to the amba-pl08x driver itself can be likely applied into appropriate trees separately, namely: - 09/18 - ASoC: Samsung: Do not queue cyclic buffers multiple times, - 14/18 - clk: samsung: s3c64xx: Add aliases for DMA clocks. After patch 14/18, both old and new DMA drivers can be supported on S3C64xx, depending on Kconfig options. Patches 15-18 remove the old driver leaving support only for the generic pl08x driver. Feel free to drop those patches for now if we want more testing, but I don't suspect any problems. On S3C64xx-based Mini6410 and SMDK6410 boards, with I2S audio playback and capture (including full duplex operation) and also SPI using spidev: Tested-by: Tomasz Figa Changes since RFC v2: - Added clkdev lookups to old clock driver. - Added patches removing the old DMA driver and any remaining code needed by it. - Fixed DMA support for SPI. - Added a word about PL080S to amba-pl08x.c file header. - Changed definition of LLI words from enums to macros. - Extended debugging messages to handle PL080S variant as well. - Little cleanup of LLI dumping code. - Added check for peripheral flow control, which is unsupported by PL080S to dma_set_runtime_config. - Corrected transfer size mask of PL080S. Changes since RFC v1: - Returned to original way of storing quirks as booleans, as suggested by Russell, Linus and Arnd. - Added reg_config field to pl08x_phy_chan struct, which stores variant-specific address of channel config register, as suggested by Russell. - Simplified handling of extended maximum transfer size of PL080S (no more conditional passing of 0 as length to pl08x_cctl_bits()). - Reworked LLI handling in the driver to stop casting arbitrary memory to a struct and allow different word count of LLI entry, as suggested by Linus. - Removed AMBA ID override from S3C64xx PL080 initialization code. - Fixed brokenness of Samsung DMA wrapper API, which caused cyclic buffers to be queued multiple times when DMA engine is used. - Included patch adding clock aliases for DMA engines (depends on Common Clock Framework driver for S3C64xx). - Fixed several minor stylistic issues. For reference, here is the original description of the series: One of the biggest roadblocks on the way of S3C64xx to DeviceTree support is its DMA driver, which is completely platform-specific and provides private API (s3c-dma), not even saying that its design is completely against multiplatform-awareness. The DMA controller present on this SoC series is a custom variant of ARM PrimeCell PL080 modified by Samsung to add some extra features. It is mostly compatible with original PL080, except: - CH_CONTROL2 register is added between CH_CONTROL and CH_CONFIG, - offset of CH_CONFIG register is different, - transfer size field is moved from CH_CONTROL to CH_CONTROL2, - transfer size field is extended to 24 bits, allowing much bigger single transfer, - LLI consists of one more word, to account for CH_CONTROL2 register. Since all the rest is fully compatible with standard PL080 there is no point in having separate driver just for this single variant, so I decided to look into adding support for it to the amba-pl08x driver. There was already some attempt to achieve this before, but this was before Russel's big rework of the driver to use virtual channels, making the old patches being not much of use. This RFC series is a proof of concept that I managed to make during last days of hacking. Except one patch adding clkdev lookup to clock driver (which is being replaced with a CCF-compliant driver ATM), this is enough to get memcpy and slave transfers to work on S3C64xx. I have tested this on Mini6410 and SMDK6410 boards using dmatest for memcpy and Samsung I2S with madplay/aplay for slave transfers. Unfortunately I do not have access to other platforms with PL08x so I could not test for any regressions introduced on them. Credits for two patches go to Alban Bedel, who made a series fixing this driver to make it usable with audio drivers. I rebased his patches on top of mine and corrected coding style a bit. OK, that's all. Any comments are welcome. Feel free to start throwing eggs and tomatoes if you find this awful, but I won't be upset if I get some Tested-by or Acked-by as well. ;) Alban Bedel
[PATCH 02/18] dmaengine: PL08x: Add support for different offset of CONFIG register
Some variants of PL08x (namely PL080S, found in Samsung S3C64xx SoCs)
have CONFIG register at different offset. This patch makes the driver
use offset from vendor data struct.
Signed-off-by: Tomasz Figa
Reviewed-by: Linus Walleij
Acked-by: Vinod Koul
---
drivers/dma/amba-pl08x.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 6a12392..2538e05 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -102,6 +102,7 @@ struct pl08x_driver_data;
* missing
*/
struct vendor_data {
+ u8 config_offset;
u8 channels;
bool dualmaster;
bool nomadik;
@@ -145,6 +146,7 @@ struct pl08x_bus_data {
struct pl08x_phy_chan {
unsigned int id;
void __iomem *base;
+ void __iomem *reg_config;
spinlock_t lock;
struct pl08x_dma_chan *serving;
bool locked;
@@ -334,7 +336,7 @@ static int pl08x_phy_channel_busy(struct pl08x_phy_chan *ch)
{
unsigned int val;
- val = readl(ch->base + PL080_CH_CONFIG);
+ val = readl(ch->reg_config);
return val & PL080_CONFIG_ACTIVE;
}
@@ -373,7 +375,7 @@ static void pl08x_start_next_txd(struct pl08x_dma_chan
*plchan)
writel(lli->dst, phychan->base + PL080_CH_DST_ADDR);
writel(lli->lli, phychan->base + PL080_CH_LLI);
writel(lli->cctl, phychan->base + PL080_CH_CONTROL);
- writel(txd->ccfg, phychan->base + PL080_CH_CONFIG);
+ writel(txd->ccfg, phychan->reg_config);
/* Enable the DMA channel */
/* Do not access config register until channel shows as disabled */
@@ -381,11 +383,11 @@ static void pl08x_start_next_txd(struct pl08x_dma_chan
*plchan)
cpu_relax();
/* Do not access config register until channel shows as inactive */
- val = readl(phychan->base + PL080_CH_CONFIG);
+ val = readl(phychan->reg_config);
while ((val & PL080_CONFIG_ACTIVE) || (val & PL080_CONFIG_ENABLE))
- val = readl(phychan->base + PL080_CH_CONFIG);
+ val = readl(phychan->reg_config);
- writel(val | PL080_CONFIG_ENABLE, phychan->base + PL080_CH_CONFIG);
+ writel(val | PL080_CONFIG_ENABLE, phychan->reg_config);
}
/*
@@ -404,9 +406,9 @@ static void pl08x_pause_phy_chan(struct pl08x_phy_chan *ch)
int timeout;
/* Set the HALT bit and wait for the FIFO to drain */
- val = readl(ch->base + PL080_CH_CONFIG);
+ val = readl(ch->reg_config);
val |= PL080_CONFIG_HALT;
- writel(val, ch->base + PL080_CH_CONFIG);
+ writel(val, ch->reg_config);
/* Wait for channel inactive */
for (timeout = 1000; timeout; timeout--) {
@@ -423,9 +425,9 @@ static void pl08x_resume_phy_chan(struct pl08x_phy_chan *ch)
u32 val;
/* Clear the HALT bit */
- val = readl(ch->base + PL080_CH_CONFIG);
+ val = readl(ch->reg_config);
val &= ~PL080_CONFIG_HALT;
- writel(val, ch->base + PL080_CH_CONFIG);
+ writel(val, ch->reg_config);
}
/*
@@ -437,12 +439,12 @@ static void pl08x_resume_phy_chan(struct pl08x_phy_chan
*ch)
static void pl08x_terminate_phy_chan(struct pl08x_driver_data *pl08x,
struct pl08x_phy_chan *ch)
{
- u32 val = readl(ch->base + PL080_CH_CONFIG);
+ u32 val = readl(ch->reg_config);
val &= ~(PL080_CONFIG_ENABLE | PL080_CONFIG_ERR_IRQ_MASK |
PL080_CONFIG_TC_IRQ_MASK);
- writel(val, ch->base + PL080_CH_CONFIG);
+ writel(val, ch->reg_config);
writel(1 << ch->id, pl08x->base + PL080_ERR_CLEAR);
writel(1 << ch->id, pl08x->base + PL080_TC_CLEAR);
@@ -1952,6 +1954,7 @@ static int pl08x_probe(struct amba_device *adev, const
struct amba_id *id)
ch->id = i;
ch->base = pl08x->base + PL080_Cx_BASE(i);
+ ch->reg_config = ch->base + vd->config_offset;
spin_lock_init(>lock);
/*
@@ -1962,7 +1965,7 @@ static int pl08x_probe(struct amba_device *adev, const
struct amba_id *id)
if (vd->nomadik) {
u32 val;
- val = readl(ch->base + PL080_CH_CONFIG);
+ val = readl(ch->reg_config);
if (val & (PL080N_CONFIG_ITPROT |
PL080N_CONFIG_SECPROT)) {
dev_info(>dev, "physical channel %d
reserved for secure access only\n", i);
ch->locked = true;
@@ -2043,17 +2046,20 @@ out_no_pl08x:
/* PL080 has 8 channels and the PL080 have just 2 */
static struct vendor_data vendor_pl080 = {
+ .config_offset = PL080_CH_CONFIG,
.channels = 8,
.dualmaster = true,
};
static struct vendor_data vendor_nomadik = {
+ .config_offset = PL080_CH_CONFIG,
.channels = 8,
.dualmaster = true,
.nomadik = true,
};
static struct
[PATCH 01/18] dmaengine: PL08x: Refactor pl08x_getbytes_chan() to lower indentation
Further patch will introduce support for PL080S, which requires some
things to be done conditionally, thus increasing indentation level of
some functions even more.
This patch reduces indentation level of pl08x_getbytes_chan() function
by inverting several conditions and returning from function wherever
possible.
Signed-off-by: Tomasz Figa
Reviewed-by: Linus Walleij
---
drivers/dma/amba-pl08x.c | 53 ++--
1 file changed, 29 insertions(+), 24 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 06fe45c..6a12392 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -469,47 +469,52 @@ static inline u32 get_bytes_in_cctl(u32 cctl)
/* The channel should be paused when calling this */
static u32 pl08x_getbytes_chan(struct pl08x_dma_chan *plchan)
{
+ struct pl08x_lli *llis_va;
struct pl08x_phy_chan *ch;
+ dma_addr_t llis_bus;
struct pl08x_txd *txd;
- size_t bytes = 0;
+ size_t bytes;
+ int index;
+ u32 clli;
ch = plchan->phychan;
txd = plchan->at;
+ if (!ch || !txd)
+ return 0;
+
/*
* Follow the LLIs to get the number of remaining
* bytes in the currently active transaction.
*/
- if (ch && txd) {
- u32 clli = readl(ch->base + PL080_CH_LLI) & ~PL080_LLI_LM_AHB2;
+ clli = readl(ch->base + PL080_CH_LLI) & ~PL080_LLI_LM_AHB2;
- /* First get the remaining bytes in the active transfer */
- bytes = get_bytes_in_cctl(readl(ch->base + PL080_CH_CONTROL));
+ /* First get the remaining bytes in the active transfer */
+ bytes = get_bytes_in_cctl(readl(ch->base + PL080_CH_CONTROL));
- if (clli) {
- struct pl08x_lli *llis_va = txd->llis_va;
- dma_addr_t llis_bus = txd->llis_bus;
- int index;
+ if (!clli)
+ return bytes;
- BUG_ON(clli < llis_bus || clli >= llis_bus +
+ llis_va = txd->llis_va;
+ llis_bus = txd->llis_bus;
+
+ BUG_ON(clli < llis_bus || clli >= llis_bus +
sizeof(struct pl08x_lli) * MAX_NUM_TSFR_LLIS);
- /*
-* Locate the next LLI - as this is an array,
-* it's simple maths to find.
-*/
- index = (clli - llis_bus) / sizeof(struct pl08x_lli);
+ /*
+* Locate the next LLI - as this is an array,
+* it's simple maths to find.
+*/
+ index = (clli - llis_bus) / sizeof(struct pl08x_lli);
- for (; index < MAX_NUM_TSFR_LLIS; index++) {
- bytes += get_bytes_in_cctl(llis_va[index].cctl);
+ for (; index < MAX_NUM_TSFR_LLIS; index++) {
+ bytes += get_bytes_in_cctl(llis_va[index].cctl);
- /*
-* A LLI pointer of 0 terminates the LLI list
-*/
- if (!llis_va[index].lli)
- break;
- }
- }
+ /*
+* A LLI pointer of 0 terminates the LLI list
+*/
+ if (!llis_va[index].lli)
+ break;
}
return bytes;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/18] dmaengine: PL08x: Rework LLI handling to be less fragile
Currently memory allocated for LLIs is casted to an array of structs,
which is fragile and also limits the driver to a single, predefined LLI
layout, while there are some variants of PL08x, which have more fields
in LLI (namely PL080S with its extra CCTL2).
This patch makes LLIs a sequence of 32-bit words, which is just filled
with appropriate values in appropriate order and padded with required
amount of dummy words (currently zero, but PL080S will make better use
of this).
Suggested-by: Linus Walleij
Signed-off-by: Tomasz Figa
---
drivers/dma/amba-pl08x.c | 147 ++-
1 file changed, 82 insertions(+), 65 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 2538e05..d3399c2 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -108,19 +108,6 @@ struct vendor_data {
bool nomadik;
};
-/*
- * PL08X private data structures
- * An LLI struct - see PL08x TRM. Note that next uses bit[0] as a bus bit,
- * start & end do not - their bus bit info is in cctl. Also note that these
- * are fixed 32-bit quantities.
- */
-struct pl08x_lli {
- u32 src;
- u32 dst;
- u32 lli;
- u32 cctl;
-};
-
/**
* struct pl08x_bus_data - information of source or destination
* busses for a transfer
@@ -181,7 +168,7 @@ struct pl08x_txd {
struct virt_dma_desc vd;
struct list_head dsg_list;
dma_addr_t llis_bus;
- struct pl08x_lli *llis_va;
+ u32 *llis_va;
/* Default cctl value for LLIs */
u32 cctl;
/*
@@ -265,17 +252,27 @@ struct pl08x_driver_data {
struct dma_pool *pool;
u8 lli_buses;
u8 mem_buses;
+ u8 lli_words;
};
/*
* PL08X specific defines
*/
-/* Size (bytes) of each LLI buffer allocated for one transfer */
-# define PL08X_LLI_TSFR_SIZE 0x2000
+/* The order of words in an LLI. */
+#define PL080_LLI_SRC 0
+#define PL080_LLI_DST 1
+#define PL080_LLI_LLI 2
+#define PL080_LLI_CCTL 3
+
+/* Total words in an LLI. */
+#define PL080_LLI_WORDS4
-/* Maximum times we call dma_pool_alloc on this pool without freeing */
-#define MAX_NUM_TSFR_LLIS (PL08X_LLI_TSFR_SIZE/sizeof(struct pl08x_lli))
+/*
+ * Number of LLIs in each LLI buffer allocated for one transfer
+ * (maximum times we call dma_pool_alloc on this pool without freeing)
+ */
+#define MAX_NUM_TSFR_LLIS 512
#define PL08X_ALIGN8
static inline struct pl08x_dma_chan *to_pl08x_chan(struct dma_chan *chan)
@@ -340,6 +337,23 @@ static int pl08x_phy_channel_busy(struct pl08x_phy_chan
*ch)
return val & PL080_CONFIG_ACTIVE;
}
+static void pl08x_write_lli(struct pl08x_driver_data *pl08x,
+ struct pl08x_phy_chan *phychan, const u32 *lli, u32 ccfg)
+{
+ dev_vdbg(>adev->dev,
+ "WRITE channel %d: csrc=0x%08x, cdst=0x%08x, "
+ "clli=0x%08x, cctl=0x%08x, ccfg=0x%08x\n",
+ phychan->id, lli[PL080_LLI_SRC], lli[PL080_LLI_DST],
+ lli[PL080_LLI_LLI], lli[PL080_LLI_CCTL], ccfg);
+
+ writel_relaxed(lli[PL080_LLI_SRC], phychan->base + PL080_CH_SRC_ADDR);
+ writel_relaxed(lli[PL080_LLI_DST], phychan->base + PL080_CH_DST_ADDR);
+ writel_relaxed(lli[PL080_LLI_LLI], phychan->base + PL080_CH_LLI);
+ writel_relaxed(lli[PL080_LLI_CCTL], phychan->base + PL080_CH_CONTROL);
+
+ writel(ccfg, phychan->reg_config);
+}
+
/*
* Set the initial DMA register values i.e. those for the first LLI
* The next LLI pointer and the configuration interrupt bit have
@@ -352,7 +366,6 @@ static void pl08x_start_next_txd(struct pl08x_dma_chan
*plchan)
struct pl08x_phy_chan *phychan = plchan->phychan;
struct virt_dma_desc *vd = vchan_next_desc(>vc);
struct pl08x_txd *txd = to_pl08x_txd(>tx);
- struct pl08x_lli *lli;
u32 val;
list_del(>vd.node);
@@ -363,19 +376,7 @@ static void pl08x_start_next_txd(struct pl08x_dma_chan
*plchan)
while (pl08x_phy_channel_busy(phychan))
cpu_relax();
- lli = >llis_va[0];
-
- dev_vdbg(>adev->dev,
- "WRITE channel %d: csrc=0x%08x, cdst=0x%08x, "
- "clli=0x%08x, cctl=0x%08x, ccfg=0x%08x\n",
- phychan->id, lli->src, lli->dst, lli->lli, lli->cctl,
- txd->ccfg);
-
- writel(lli->src, phychan->base + PL080_CH_SRC_ADDR);
- writel(lli->dst, phychan->base + PL080_CH_DST_ADDR);
- writel(lli->lli, phychan->base + PL080_CH_LLI);
- writel(lli->cctl, phychan->base + PL080_CH_CONTROL);
- writel(txd->ccfg, phychan->reg_config);
+ pl08x_write_lli(pl08x, phychan, >llis_va[0], txd->ccfg);
/* Enable the DMA channel */
/* Do not access config register until channel shows as disabled */
@@ -471,12 +472,13 @@ static inline u32 get_bytes_in_cctl(u32 cctl)
/* The channel should be paused when calling this */
[PATCH 07/18] dmaengine: PL08x: Fix reading the byte count in cctl
From: Alban Bedel
There are more fields than just SWIDTH in CH_CONTROL register, so read
register value must be masked in addition to shifting.
Signed-off-by: Alban Bedel
Signed-off-by: Tomasz Figa
Reviewed-by: Linus Walleij
---
drivers/dma/amba-pl08x.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 4e4c3df..6b9cba2 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -480,6 +480,8 @@ static inline u32 get_bytes_in_cctl(u32 cctl)
/* The source width defines the number of bytes */
u32 bytes = cctl & PL080_CONTROL_TRANSFER_SIZE_MASK;
+ cctl &= PL080_CONTROL_SWIDTH_MASK;
+
switch (cctl >> PL080_CONTROL_SWIDTH_SHIFT) {
case PL080_WIDTH_8BIT:
break;
@@ -498,6 +500,8 @@ static inline u32 get_bytes_in_cctl_pl080s(u32 cctl, u32
cctl1)
/* The source width defines the number of bytes */
u32 bytes = cctl1 & PL080S_CONTROL_TRANSFER_SIZE_MASK;
+ cctl &= PL080_CONTROL_SWIDTH_MASK;
+
switch (cctl >> PL080_CONTROL_SWIDTH_SHIFT) {
case PL080_WIDTH_8BIT:
break;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/18] dmaengine: PL08x: Add support for PL080S variant
PL080S is a modified version of PL080 that can be found on Samsung SoCs,
such as S3C6400 and S3C6410.
It has different offset of CONFIG register, separate CONTROL1 register
that holds transfer size and larger maximum transfer size.
Signed-off-by: Tomasz Figa
Acked-by: Linus Walleij
---
drivers/dma/amba-pl08x.c | 145 -
include/linux/amba/pl080.h | 1 +
2 files changed, 119 insertions(+), 27 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 1fa05d6..75915be 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -24,6 +24,7 @@
*
* Documentation: ARM DDI 0196G == PL080
* Documentation: ARM DDI 0218E == PL081
+ * Documentation: S3C6410 User's Manual == PL080S
*
* PL080 & PL081 both have 16 sets of DMA signals that can be routed to any
* channel.
@@ -36,6 +37,14 @@
*
* The PL080 has a dual bus master, PL081 has a single master.
*
+ * PL080S is a version modified by Samsung and used in S3C64xx SoCs.
+ * It differs in following aspects:
+ * - CH_CONFIG register at different offset,
+ * - separate CH_CONTROL2 register for transfer size,
+ * - bigger maximum transfer size,
+ * - 8-word aligned LLI, instead of 4-word, due to extra CCTL2 word,
+ * - no support for peripheral flow control.
+ *
* Memory to peripheral transfer may be visualized as
* Get data from memory to DMAC
* Until no data left
@@ -64,10 +73,7 @@
* - Peripheral flow control: the transfer size is ignored (and should be
*zero). The data is transferred from the current LLI entry, until
*after the final transfer signalled by LBREQ or LSREQ. The DMAC
- *will then move to the next LLI entry.
- *
- * Global TODO:
- * - Break out common code from arch/arm/mach-s3c64xx and share
+ *will then move to the next LLI entry. Unsupported by PL080S.
*/
#include
#include
@@ -100,12 +106,15 @@ struct pl08x_driver_data;
* @nomadik: whether the channels have Nomadik security extension bits
* that need to be checked for permission before use and some registers are
* missing
+ * @pl080s: whether this version is a PL080S, which has separate register and
+ * LLI word for transfer size.
*/
struct vendor_data {
u8 config_offset;
u8 channels;
bool dualmaster;
bool nomadik;
+ bool pl080s;
};
/**
@@ -264,9 +273,11 @@ struct pl08x_driver_data {
#define PL080_LLI_DST 1
#define PL080_LLI_LLI 2
#define PL080_LLI_CCTL 3
+#define PL080S_LLI_CCTL2 4
/* Total words in an LLI. */
#define PL080_LLI_WORDS4
+#define PL080S_LLI_WORDS 8
/*
* Number of LLIs in each LLI buffer allocated for one transfer
@@ -340,17 +351,29 @@ static int pl08x_phy_channel_busy(struct pl08x_phy_chan
*ch)
static void pl08x_write_lli(struct pl08x_driver_data *pl08x,
struct pl08x_phy_chan *phychan, const u32 *lli, u32 ccfg)
{
- dev_vdbg(>adev->dev,
- "WRITE channel %d: csrc=0x%08x, cdst=0x%08x, "
- "clli=0x%08x, cctl=0x%08x, ccfg=0x%08x\n",
- phychan->id, lli[PL080_LLI_SRC], lli[PL080_LLI_DST],
- lli[PL080_LLI_LLI], lli[PL080_LLI_CCTL], ccfg);
+ if (pl08x->vd->pl080s)
+ dev_vdbg(>adev->dev,
+ "WRITE channel %d: csrc=0x%08x, cdst=0x%08x, "
+ "clli=0x%08x, cctl=0x%08x, cctl2=0x%08x, ccfg=0x%08x\n",
+ phychan->id, lli[PL080_LLI_SRC], lli[PL080_LLI_DST],
+ lli[PL080_LLI_LLI], lli[PL080_LLI_CCTL],
+ lli[PL080S_LLI_CCTL2], ccfg);
+ else
+ dev_vdbg(>adev->dev,
+ "WRITE channel %d: csrc=0x%08x, cdst=0x%08x, "
+ "clli=0x%08x, cctl=0x%08x, ccfg=0x%08x\n",
+ phychan->id, lli[PL080_LLI_SRC], lli[PL080_LLI_DST],
+ lli[PL080_LLI_LLI], lli[PL080_LLI_CCTL], ccfg);
writel_relaxed(lli[PL080_LLI_SRC], phychan->base + PL080_CH_SRC_ADDR);
writel_relaxed(lli[PL080_LLI_DST], phychan->base + PL080_CH_DST_ADDR);
writel_relaxed(lli[PL080_LLI_LLI], phychan->base + PL080_CH_LLI);
writel_relaxed(lli[PL080_LLI_CCTL], phychan->base + PL080_CH_CONTROL);
+ if (pl08x->vd->pl080s)
+ writel_relaxed(lli[PL080S_LLI_CCTL2],
+ phychan->base + PL080S_CH_CONTROL2);
+
writel(ccfg, phychan->reg_config);
}
@@ -469,6 +492,24 @@ static inline u32 get_bytes_in_cctl(u32 cctl)
return bytes;
}
+static inline u32 get_bytes_in_cctl_pl080s(u32 cctl, u32 cctl1)
+{
+ /* The source width defines the number of bytes */
+ u32 bytes = cctl1 & PL080S_CONTROL_TRANSFER_SIZE_MASK;
+
+ switch (cctl >> PL080_CONTROL_SWIDTH_SHIFT) {
+ case PL080_WIDTH_8BIT:
+ break;
+ case PL080_WIDTH_16BIT:
+ bytes *= 2;
+
[PATCH 04/18] dmaengine: PL08x: Move LLI dumping code into separate function
This patch refactors debugging code that dumps LLI entries by moving it
into separate function, which is stubbed when VERBOSE_DEBUG is not
selected. This allows us to get rid of the ugly ifdef from the body of
pl08x_fill_llis_for_desc().
No functional change is introduced by this patch.
Signed-off-by: Tomasz Figa
---
drivers/dma/amba-pl08x.c | 41 -
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index d3399c2..1fa05d6 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -814,6 +814,29 @@ static inline void prep_byte_width_lli(struct
pl08x_driver_data *pl08x,
(*total_bytes) += len;
}
+#ifdef VERBOSE_DEBUG
+static void pl08x_dump_lli(struct pl08x_driver_data *pl08x,
+ const u32 *llis_va, int num_llis)
+{
+ int i;
+
+ dev_vdbg(>adev->dev,
+ "%-3s %-9s %-10s %-10s %-10s %s\n",
+ "lli", "", "csrc", "cdst", "clli", "cctl");
+ for (i = 0; i < num_llis; i++) {
+ dev_vdbg(>adev->dev,
+ "%3d @%p: 0x%08x 0x%08x 0x%08x 0x%08x\n",
+ i, llis_va, llis_va[PL080_LLI_SRC],
+ llis_va[PL080_LLI_DST], llis_va[PL080_LLI_LLI],
+ llis_va[PL080_LLI_CCTL]);
+ llis_va += pl08x->lli_words;
+ }
+}
+#else
+static inline void pl08x_dump_lli(struct pl08x_driver_data *pl08x,
+ const u32 *llis_va, int num_llis) {}
+#endif
+
/*
* This fills in the table of LLIs for the transfer descriptor
* Note that we assume we never have to change the burst sizes
@@ -1033,23 +1056,7 @@ static int pl08x_fill_llis_for_desc(struct
pl08x_driver_data *pl08x,
/* The final LLI element shall also fire an interrupt. */
last_lli[PL080_LLI_CCTL] |= PL080_CONTROL_TC_IRQ_EN;
-#ifdef VERBOSE_DEBUG
- {
- int i;
-
- dev_vdbg(>adev->dev,
-"%-3s %-9s %-10s %-10s %-10s %s\n",
-"lli", "", "csrc", "cdst", "clli", "cctl");
- for (i = 0; i < num_llis; i++) {
- dev_vdbg(>adev->dev,
-"%3d @%p: 0x%08x 0x%08x 0x%08x 0x%08x\n",
-i, llis_va, llis_va[PL080_LLI_SRC],
-llis_va[PL080_LLI_DST], llis_va[PL080_LLI_LLI],
-llis_va[PL080_LLI_CCTL]);
- llis_va += pl08x->lli_words;
- }
- }
-#endif
+ pl08x_dump_lli(pl08x, llis_va, num_llis);
return num_llis;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/18] dmaengine: PL08x: Add cyclic transfer support
From: Alban Bedel
Many audio interface drivers require support of cyclic transfers to work
correctly, for example Samsung ASoC DMA driver. This patch adds support
for cyclic transfers to the amba-pl08x driver.
Signed-off-by: Alban Bedel
[tfiga: Rebase and slightly beautify the original patch.]
Signed-off-by: Tomasz Figa
Acked-by: Linus Walleij
---
drivers/dma/amba-pl08x.c | 147 +--
1 file changed, 118 insertions(+), 29 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 6b9cba2..cd29434 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -173,6 +173,7 @@ struct pl08x_sg {
* @ccfg: config reg values for current txd
* @done: this marks completed descriptors, which should not have their
* mux released.
+ * @cyclic: indicate cyclic transfers
*/
struct pl08x_txd {
struct virt_dma_desc vd;
@@ -187,6 +188,7 @@ struct pl08x_txd {
*/
u32 ccfg;
bool done;
+ bool cyclic;
};
/**
@@ -574,9 +576,9 @@ static u32 pl08x_getbytes_chan(struct pl08x_dma_chan
*plchan)
bytes += get_bytes_in_cctl(llis_va[PL080_LLI_CCTL]);
/*
-* A LLI pointer of 0 terminates the LLI list
+* A LLI pointer going backward terminates the LLI list
*/
- if (!llis_va[PL080_LLI_LLI])
+ if (llis_va[PL080_LLI_LLI] <= clli)
break;
}
@@ -1125,10 +1127,16 @@ static int pl08x_fill_llis_for_desc(struct
pl08x_driver_data *pl08x,
llis_va = txd->llis_va;
last_lli = llis_va + (num_llis - 1) * pl08x->lli_words;
- /* The final LLI terminates the LLI. */
- last_lli[PL080_LLI_LLI] = 0;
- /* The final LLI element shall also fire an interrupt. */
- last_lli[PL080_LLI_CCTL] |= PL080_CONTROL_TC_IRQ_EN;
+
+ if (txd->cyclic) {
+ /* Link back to the first LLI. */
+ last_lli[PL080_LLI_LLI] = txd->llis_bus | bd.lli_bus;
+ } else {
+ /* The final LLI terminates the LLI. */
+ last_lli[PL080_LLI_LLI] = 0;
+ /* The final LLI element shall also fire an interrupt. */
+ last_lli[PL080_LLI_CCTL] |= PL080_CONTROL_TC_IRQ_EN;
+ }
pl08x_dump_lli(pl08x, llis_va, num_llis);
@@ -1513,25 +1521,19 @@ static struct dma_async_tx_descriptor
*pl08x_prep_dma_memcpy(
return vchan_tx_prep(>vc, >vd, flags);
}
-static struct dma_async_tx_descriptor *pl08x_prep_slave_sg(
- struct dma_chan *chan, struct scatterlist *sgl,
- unsigned int sg_len, enum dma_transfer_direction direction,
- unsigned long flags, void *context)
+static struct pl08x_txd *pl08x_init_txd(
+ struct dma_chan *chan,
+ enum dma_transfer_direction direction,
+ dma_addr_t *slave_addr)
{
struct pl08x_dma_chan *plchan = to_pl08x_chan(chan);
struct pl08x_driver_data *pl08x = plchan->host;
struct pl08x_txd *txd;
- struct pl08x_sg *dsg;
- struct scatterlist *sg;
enum dma_slave_buswidth addr_width;
- dma_addr_t slave_addr;
int ret, tmp;
u8 src_buses, dst_buses;
u32 maxburst, cctl;
- dev_dbg(>adev->dev, "%s prepare transaction of %d bytes from
%s\n",
- __func__, sg_dma_len(sgl), plchan->name);
-
txd = pl08x_get_txd(plchan);
if (!txd) {
dev_err(>adev->dev, "%s no txd\n", __func__);
@@ -1545,14 +1547,14 @@ static struct dma_async_tx_descriptor
*pl08x_prep_slave_sg(
*/
if (direction == DMA_MEM_TO_DEV) {
cctl = PL080_CONTROL_SRC_INCR;
- slave_addr = plchan->cfg.dst_addr;
+ *slave_addr = plchan->cfg.dst_addr;
addr_width = plchan->cfg.dst_addr_width;
maxburst = plchan->cfg.dst_maxburst;
src_buses = pl08x->mem_buses;
dst_buses = plchan->cd->periph_buses;
} else if (direction == DMA_DEV_TO_MEM) {
cctl = PL080_CONTROL_DST_INCR;
- slave_addr = plchan->cfg.src_addr;
+ *slave_addr = plchan->cfg.src_addr;
addr_width = plchan->cfg.src_addr_width;
maxburst = plchan->cfg.src_maxburst;
src_buses = plchan->cd->periph_buses;
@@ -1601,24 +1603,107 @@ static struct dma_async_tx_descriptor
*pl08x_prep_slave_sg(
else
txd->ccfg |= plchan->signal << PL080_CONFIG_SRC_SEL_SHIFT;
+ return txd;
+}
+
+static int pl08x_tx_add_sg(struct pl08x_txd *txd,
+ enum dma_transfer_direction direction,
+ dma_addr_t slave_addr,
+ dma_addr_t buf_addr,
+ unsigned int len)
+{
+ struct pl08x_sg *dsg;
+
+ dsg = kzalloc(sizeof(struct
[PATCH 09/18] ASoC: Samsung: Do not queue cyclic buffers multiple times
The legacy S3C-DMA API required every period of a cyclic buffer to be
queued separately. After conversion of Samsung ASoC to Samsung DMA
wrappers somebody made an assumption that the same is needed for DMA
engine API, which is not true.
In effect, Samsung ASoC DMA code was queuing the whole cyclic buffer
multiple times with a shift of one period per iteration, leading to:
a) severe memory waste - up to 13x times more DMA transfer descriptors
are allocated than needed,
b) possible memory corruption, because further cyclic buffers were out
of the original buffers, due to the offset.
This patch fixes this problem by making the legacy S3C-DMA API use the
same semantics as DMA engine (the whole cyclic buffer is enqueued at
once) and modifying users of Samsung DMA wrappers in cyclic mode to
behave appropriately.
Signed-off-by: Tomasz Figa
Acked-by: Linus Walleij
---
arch/arm/plat-samsung/s3c-dma-ops.c | 13 +++--
sound/soc/samsung/dma.c | 7 +++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-samsung/s3c-dma-ops.c
b/arch/arm/plat-samsung/s3c-dma-ops.c
index 0cc40ae..98b10ba 100644
--- a/arch/arm/plat-samsung/s3c-dma-ops.c
+++ b/arch/arm/plat-samsung/s3c-dma-ops.c
@@ -82,7 +82,8 @@ static int s3c_dma_config(unsigned ch, struct
samsung_dma_config *param)
static int s3c_dma_prepare(unsigned ch, struct samsung_dma_prep *param)
{
struct cb_data *data;
- int len = (param->cap == DMA_CYCLIC) ? param->period : param->len;
+ dma_addr_t pos = param->buf;
+ dma_addr_t end = param->buf + param->len;
list_for_each_entry(data, _list, node)
if (data->ch == ch)
@@ -94,7 +95,15 @@ static int s3c_dma_prepare(unsigned ch, struct
samsung_dma_prep *param)
data->fp_param = param->fp_param;
}
- s3c2410_dma_enqueue(ch, (void *)data, param->buf, len);
+ if (param->cap != DMA_CYCLIC) {
+ s3c2410_dma_enqueue(ch, (void *)data, param->buf, param->len);
+ return 0;
+ }
+
+ while (pos < end) {
+ s3c2410_dma_enqueue(ch, (void *)data, pos, param->period);
+ pos += param->period;
+ }
return 0;
}
diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c
index 21b7926..6e2b2b4 100644
--- a/sound/soc/samsung/dma.c
+++ b/sound/soc/samsung/dma.c
@@ -90,6 +90,13 @@ static void dma_enqueue(struct snd_pcm_substream *substream)
dma_info.period = prtd->dma_period;
dma_info.len = prtd->dma_period*limit;
+ if (dma_info.cap == DMA_CYCLIC) {
+ dma_info.buf = pos;
+ prtd->params->ops->prepare(prtd->params->ch, _info);
+ prtd->dma_loaded += limit;
+ return;
+ }
+
while (prtd->dma_loaded < limit) {
pr_debug("dma_loaded: %d\n", prtd->dma_loaded);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/18] ASoC: Samsung: Do not require legacy DMA API in case of S3C64XX
With support for amba-pl08x driver, on S3C64xx the generic DMA engine API can be used instead of the private s3c-dma interface. Signed-off-by: Tomasz Figa Acked-by: Linus Walleij --- sound/soc/samsung/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index 9855dfc..55b514d 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -1,7 +1,7 @@ config SND_SOC_SAMSUNG tristate "ASoC support for Samsung" depends on PLAT_SAMSUNG - select S3C64XX_DMA if ARCH_S3C64XX + select S3C64XX_DMA if ARCH_S3C64XX && !S3C64XX_PL080 select S3C2410_DMA if ARCH_S3C24XX help Say Y or M if you want to add support for codecs attached to -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/18] clk: samsung: s3c64xx: Add aliases for DMA clocks
This patch adds clkdev aliases for clocks used by PL08x DMA driver.
Signed-off-by: Tomasz Figa
---
drivers/clk/samsung/clk-s3c64xx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/samsung/clk-s3c64xx.c
b/drivers/clk/samsung/clk-s3c64xx.c
index eeda567..79ee9a6 100644
--- a/drivers/clk/samsung/clk-s3c64xx.c
+++ b/drivers/clk/samsung/clk-s3c64xx.c
@@ -332,7 +332,9 @@ static struct samsung_clock_alias s3c64xx_clock_aliases[] =
{
ALIAS(HCLK_HSMMC0, "s3c-sdhci.0", "hsmmc"),
ALIAS(HCLK_HSMMC0, "s3c-sdhci.0", "mmc_busclk.0"),
ALIAS(HCLK_DMA1, NULL, "dma1"),
+ ALIAS(HCLK_DMA1, "dma-pl080s.1", "apb_pclk"),
ALIAS(HCLK_DMA0, NULL, "dma0"),
+ ALIAS(HCLK_DMA0, "dma-pl080s.0", "apb_pclk"),
ALIAS(HCLK_CAMIF, "s3c-camif", "camif"),
ALIAS(HCLK_LCD, "s3c-fb", "lcd"),
ALIAS(PCLK_SPI1, "s3c6410-spi.1", "spi"),
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/18] ARM: s3c64xx: Remove legacy DMA driver
Since support for generic PL08x DMA engine driver has been added, there
is no need to keep the old legacy driver, so this patch removes it.
Signed-off-by: Tomasz Figa
---
arch/arm/mach-s3c64xx/Kconfig| 5 -
arch/arm/mach-s3c64xx/Makefile | 1 -
arch/arm/mach-s3c64xx/dma.c | 753 ---
arch/arm/mach-s3c64xx/include/mach/dma.h | 123 -
4 files changed, 882 deletions(-)
delete mode 100644 arch/arm/mach-s3c64xx/dma.c
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 704c5e4..940dd7f 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -33,11 +33,6 @@ config S3C64XX_PL080
select AMBA_PL08X
select SAMSUNG_DMADEV
-config S3C64XX_DMA
- bool "S3C64XX DMA using legacy S3C DMA API"
- select S3C_DMA
- depends on !S3C64XX_PL080
-
config S3C64XX_SETUP_SDHCI
bool
select S3C64XX_SETUP_SDHCI_GPIO
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 4e3326a..5607547 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -26,7 +26,6 @@ obj-$(CONFIG_CPU_IDLE)+= cpuidle.o
# DMA support
-obj-$(CONFIG_S3C64XX_DMA) += dma.o
obj-$(CONFIG_S3C64XX_PL080)+= pl080.o
# Device support
diff --git a/arch/arm/mach-s3c64xx/dma.c b/arch/arm/mach-s3c64xx/dma.c
deleted file mode 100644
index 759846c..000
--- a/arch/arm/mach-s3c64xx/dma.c
+++ /dev/null
@@ -1,753 +0,0 @@
-/* linux/arch/arm/plat-s3c64xx/dma.c
- *
- * Copyright 2009 Openmoko, Inc.
- * Copyright 2009 Simtec Electronics
- * Ben Dooks
- * http://armlinux.simtec.co.uk/
- *
- * S3C64XX DMA core
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-
-#include "regs-sys.h"
-
-/* dma channel state information */
-
-struct s3c64xx_dmac {
- struct device dev;
- struct clk *clk;
- void __iomem*regs;
- struct s3c2410_dma_chan *channels;
- enum dma_ch chanbase;
-};
-
-/* pool to provide LLI buffers */
-static struct dma_pool *dma_pool;
-
-/* Debug configuration and code */
-
-static unsigned char debug_show_buffs = 0;
-
-static void dbg_showchan(struct s3c2410_dma_chan *chan)
-{
- pr_debug("DMA%d: %08x->%08x L %08x C %08x,%08x S %08x\n",
-chan->number,
-readl(chan->regs + PL080_CH_SRC_ADDR),
-readl(chan->regs + PL080_CH_DST_ADDR),
-readl(chan->regs + PL080_CH_LLI),
-readl(chan->regs + PL080_CH_CONTROL),
-readl(chan->regs + PL080S_CH_CONTROL2),
-readl(chan->regs + PL080S_CH_CONFIG));
-}
-
-static void show_lli(struct pl080s_lli *lli)
-{
- pr_debug("LLI[%p] %08x->%08x, NL %08x C %08x,%08x\n",
-lli, lli->src_addr, lli->dst_addr, lli->next_lli,
-lli->control0, lli->control1);
-}
-
-static void dbg_showbuffs(struct s3c2410_dma_chan *chan)
-{
- struct s3c64xx_dma_buff *ptr;
- struct s3c64xx_dma_buff *end;
-
- pr_debug("DMA%d: buffs next %p, curr %p, end %p\n",
-chan->number, chan->next, chan->curr, chan->end);
-
- ptr = chan->next;
- end = chan->end;
-
- if (debug_show_buffs) {
- for (; ptr != NULL; ptr = ptr->next) {
- pr_debug("DMA%d: %08x ",
-chan->number, ptr->lli_dma);
- show_lli(ptr->lli);
- }
- }
-}
-
-/* End of Debug */
-
-static struct s3c2410_dma_chan *s3c64xx_dma_map_channel(unsigned int channel)
-{
- struct s3c2410_dma_chan *chan;
- unsigned int start, offs;
-
- start = 0;
-
- if (channel >= DMACH_PCM1_TX)
- start = 8;
-
- for (offs = 0; offs < 8; offs++) {
- chan = _chans[start + offs];
- if (!chan->in_use)
- goto found;
- }
-
- return NULL;
-
-found:
- s3c_dma_chan_map[channel] = chan;
- return chan;
-}
-
-int s3c2410_dma_config(enum dma_ch channel, int xferunit)
-{
- struct s3c2410_dma_chan *chan = s3c_dma_lookup_channel(channel);
-
- if (chan == NULL)
- return -EINVAL;
-
- switch (xferunit) {
- case 1:
- chan->hw_width = 0;
- break;
- case 2:
- chan->hw_width = 1;
- break;
- case 4:
- chan->hw_width = 2;
- break;
- default:
- printk(KERN_ERR "%s: illegal width %d\n", __func__, xferunit);
- return -EINVAL;
- }
-
-
[PATCH 12/18] ARM: s3c64xx: Add support for DMA using generic amba-pl08x driver
This patch adds all required platform-specific data and initialization
code to support the generic amba-pl08x driver on S3C64xx SoCs.
Also some compatibility definitions are added to make the transition
from legacy API to DMA engine easier. The biggest hack here is passing
const char * pointers through DMA resource, casted to unsigned long,
but this is how Samsung DMA wrappers (used to support both s3c-dma and
DMA engine in drivers) are designed.
Signed-off-by: Tomasz Figa
---
arch/arm/Kconfig | 1 +
arch/arm/mach-s3c64xx/Kconfig| 8 +-
arch/arm/mach-s3c64xx/Makefile | 1 +
arch/arm/mach-s3c64xx/common.h | 5 +
arch/arm/mach-s3c64xx/include/mach/dma.h | 65
arch/arm/mach-s3c64xx/pl080.c| 244 +++
arch/arm/plat-samsung/devs.c | 6 +-
7 files changed, 326 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/mach-s3c64xx/pl080.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 43594d5..7e0e1b6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -721,6 +721,7 @@ config ARCH_S3C64XX
bool "Samsung S3C64XX"
select ARCH_HAS_CPUFREQ
select ARCH_REQUIRE_GPIOLIB
+ select ARM_AMBA
select ARM_VIC
select CLKDEV_LOOKUP
select CLKSRC_MMIO
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 2057853..704c5e4 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -28,9 +28,15 @@ config CPU_S3C6410
help
Enable S3C6410 CPU support
+config S3C64XX_PL080
+ bool "S3C64XX DMA using generic PL08x driver"
+ select AMBA_PL08X
+ select SAMSUNG_DMADEV
+
config S3C64XX_DMA
- bool "S3C64XX DMA"
+ bool "S3C64XX DMA using legacy S3C DMA API"
select S3C_DMA
+ depends on !S3C64XX_PL080
config S3C64XX_SETUP_SDHCI
bool
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 31d0c91..4e3326a 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_CPU_IDLE)+= cpuidle.o
# DMA support
obj-$(CONFIG_S3C64XX_DMA) += dma.o
+obj-$(CONFIG_S3C64XX_PL080)+= pl080.o
# Device support
diff --git a/arch/arm/mach-s3c64xx/common.h b/arch/arm/mach-s3c64xx/common.h
index e8f990b..4e84617 100644
--- a/arch/arm/mach-s3c64xx/common.h
+++ b/arch/arm/mach-s3c64xx/common.h
@@ -60,4 +60,9 @@ int __init s3c64xx_pm_late_initcall(void);
static inline int s3c64xx_pm_late_initcall(void) { return 0; }
#endif
+#ifdef CONFIG_S3C64XX_PL080
+extern struct pl08x_platform_data s3c64xx_dma0_plat_data;
+extern struct pl08x_platform_data s3c64xx_dma1_plat_data;
+#endif
+
#endif /* __ARCH_ARM_MACH_S3C64XX_COMMON_H */
diff --git a/arch/arm/mach-s3c64xx/include/mach/dma.h
b/arch/arm/mach-s3c64xx/include/mach/dma.h
index fe1a98c..6f88965 100644
--- a/arch/arm/mach-s3c64xx/include/mach/dma.h
+++ b/arch/arm/mach-s3c64xx/include/mach/dma.h
@@ -11,6 +11,8 @@
#ifndef __ASM_ARCH_DMA_H
#define __ASM_ARCH_DMA_H __FILE__
+#ifdef CONFIG_S3C64XX_DMA
+
#define S3C_DMA_CHANNELS (16)
/* see mach-s3c2410/dma.h for notes on dma channel numbers */
@@ -128,4 +130,67 @@ struct s3c2410_dma_chan {
#include
+#else
+
+#define S3C64XX_DMA_CHAN(name) ((unsigned long)(name))
+
+/* DMA0/SDMA0 */
+#define DMACH_UART0S3C64XX_DMA_CHAN("uart0_tx")
+#define DMACH_UART0_SRC2 S3C64XX_DMA_CHAN("uart0_rx")
+#define DMACH_UART1S3C64XX_DMA_CHAN("uart1_tx")
+#define DMACH_UART1_SRC2 S3C64XX_DMA_CHAN("uart1_rx")
+#define DMACH_UART2S3C64XX_DMA_CHAN("uart2_tx")
+#define DMACH_UART2_SRC2 S3C64XX_DMA_CHAN("uart2_rx")
+#define DMACH_UART3S3C64XX_DMA_CHAN("uart3_tx")
+#define DMACH_UART3_SRC2 S3C64XX_DMA_CHAN("uart3_rx")
+#define DMACH_PCM0_TX S3C64XX_DMA_CHAN("pcm0_tx")
+#define DMACH_PCM0_RX S3C64XX_DMA_CHAN("pcm0_rx")
+#define DMACH_I2S0_OUT S3C64XX_DMA_CHAN("i2s0_tx")
+#define DMACH_I2S0_IN S3C64XX_DMA_CHAN("i2s0_rx")
+#define DMACH_SPI0_TX S3C64XX_DMA_CHAN("spi0_tx")
+#define DMACH_SPI0_RX S3C64XX_DMA_CHAN("spi0_rx")
+#define DMACH_HSI_I2SV40_TXS3C64XX_DMA_CHAN("i2s2_tx")
+#define DMACH_HSI_I2SV40_RXS3C64XX_DMA_CHAN("i2s2_rx")
+
+/* DMA1/SDMA1 */
+#define DMACH_PCM1_TX S3C64XX_DMA_CHAN("pcm1_tx")
+#define DMACH_PCM1_RX S3C64XX_DMA_CHAN("pcm1_rx")
+#define DMACH_I2S1_OUT S3C64XX_DMA_CHAN("i2s1_tx")
+#define DMACH_I2S1_IN S3C64XX_DMA_CHAN("i2s1_rx")
+#define DMACH_SPI1_TX S3C64XX_DMA_CHAN("spi1_tx")
+#define DMACH_SPI1_RX S3C64XX_DMA_CHAN("spi1_rx")
+#define DMACH_AC97_PCMOUT S3C64XX_DMA_CHAN("ac97_out")
+#define DMACH_AC97_PCMIN S3C64XX_DMA_CHAN("ac97_in")
+#define DMACH_AC97_MICIN S3C64XX_DMA_CHAN("ac97_mic")
+#define DMACH_PWM
[PATCH 17/18] spi: s3c64xx: Always select S3C64XX_PL080 when ARCH_S3C64XX is enabled
The legacy S3C64xx DMA driver has been removed, DMA support on S3C64xx is provided only by the generic PL08x driver. This patch modifies the Kconfig entry of spi-s3c64xx driver, which relies on availability of DMA, to always select the S3C64XX_PL080 symbol. Signed-off-by: Tomasz Figa --- drivers/spi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 241a049..a13867e 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -366,7 +366,7 @@ config SPI_S3C24XX_FIQ config SPI_S3C64XX tristate "Samsung S3C64XX series type SPI" depends on (ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5P64X0 || ARCH_EXYNOS) - select S3C64XX_DMA if ARCH_S3C64XX && !S3C64XX_PL080 + select S3C64XX_PL080 if ARCH_S3C64XX help SPI driver for Samsung S3C64XX and newer SoCs. -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/18] clk: samsung: s3c64xx: Remove clock aliases of old DMA driver
Since the old DMA driver got removed, these aliases are no longer
necessary.
Signed-off-by: Tomasz Figa
---
drivers/clk/samsung/clk-s3c64xx.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-s3c64xx.c
b/drivers/clk/samsung/clk-s3c64xx.c
index 79ee9a6..dd47a83 100644
--- a/drivers/clk/samsung/clk-s3c64xx.c
+++ b/drivers/clk/samsung/clk-s3c64xx.c
@@ -331,9 +331,7 @@ static struct samsung_clock_alias s3c64xx_clock_aliases[] =
{
ALIAS(HCLK_HSMMC1, "s3c-sdhci.1", "mmc_busclk.0"),
ALIAS(HCLK_HSMMC0, "s3c-sdhci.0", "hsmmc"),
ALIAS(HCLK_HSMMC0, "s3c-sdhci.0", "mmc_busclk.0"),
- ALIAS(HCLK_DMA1, NULL, "dma1"),
ALIAS(HCLK_DMA1, "dma-pl080s.1", "apb_pclk"),
- ALIAS(HCLK_DMA0, NULL, "dma0"),
ALIAS(HCLK_DMA0, "dma-pl080s.0", "apb_pclk"),
ALIAS(HCLK_CAMIF, "s3c-camif", "camif"),
ALIAS(HCLK_LCD, "s3c-fb", "lcd"),
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 18/18] ASoC: Samsung: Always select S3C64XX_PL080 when ARCH_S3C64XX is enabled
The legacy S3C64xx DMA driver has been removed, DMA support on S3C64xx is provided only by the generic PL08x driver. This patch modifies the Kconfig entry of Samsung ASoC subsystem, which relies on availability of DMA, to always select the S3C64XX_PL080 symbol. Signed-off-by: Tomasz Figa --- sound/soc/samsung/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index 55b514d..5b5be90 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -1,7 +1,7 @@ config SND_SOC_SAMSUNG tristate "ASoC support for Samsung" depends on PLAT_SAMSUNG - select S3C64XX_DMA if ARCH_S3C64XX && !S3C64XX_PL080 + select S3C64XX_PL080 if ARCH_S3C64XX select S3C2410_DMA if ARCH_S3C24XX help Say Y or M if you want to add support for codecs attached to -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/18] dmaengine: PL08x: Add support for different maximum transfer size
PL080S has separate register to store transfer size in, allowing single
transfer to be much larger than in standard PL080.
This patch makes the amba-pl08x driver aware of this and removes writing
transfer size to reserved bits of CH_CONTROL register on PL080S, which
was not a problem witn transfer sizes fitting the original bitfield
of PL080, but now would overwrite other fields.
Signed-off-by: Tomasz Figa
Reviewed-by: Linus Walleij
Acked by: Vinod Koul
---
drivers/dma/amba-pl08x.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 75915be..4e4c3df 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -115,6 +115,7 @@ struct vendor_data {
bool dualmaster;
bool nomadik;
bool pl080s;
+ u32 max_transfer_size;
};
/**
@@ -783,6 +784,7 @@ static inline u32 pl08x_cctl_bits(u32 cctl, u8 srcwidth, u8
dstwidth,
break;
}
+ tsize &= PL080_CONTROL_TRANSFER_SIZE_MASK;
retbits |= tsize << PL080_CONTROL_TRANSFER_SIZE_SHIFT;
return retbits;
}
@@ -1050,7 +1052,7 @@ static int pl08x_fill_llis_for_desc(struct
pl08x_driver_data *pl08x,
* MIN(buswidths)
*/
max_bytes_per_lli = bd.srcbus.buswidth *
- PL080_CONTROL_TRANSFER_SIZE_MASK;
+ pl08x->vd->max_transfer_size;
dev_vdbg(>adev->dev,
"%s max bytes per lli = %zu\n",
__func__, max_bytes_per_lli);
@@ -2152,6 +2154,7 @@ static struct vendor_data vendor_pl080 = {
.config_offset = PL080_CH_CONFIG,
.channels = 8,
.dualmaster = true,
+ .max_transfer_size = PL080_CONTROL_TRANSFER_SIZE_MASK,
};
static struct vendor_data vendor_nomadik = {
@@ -2159,18 +2162,21 @@ static struct vendor_data vendor_nomadik = {
.channels = 8,
.dualmaster = true,
.nomadik = true,
+ .max_transfer_size = PL080_CONTROL_TRANSFER_SIZE_MASK,
};
static struct vendor_data vendor_pl080s = {
.config_offset = PL080S_CH_CONFIG,
.channels = 8,
.pl080s = true,
+ .max_transfer_size = PL080S_CONTROL_TRANSFER_SIZE_MASK,
};
static struct vendor_data vendor_pl081 = {
.config_offset = PL080_CH_CONFIG,
.channels = 2,
.dualmaster = false,
+ .max_transfer_size = PL080_CONTROL_TRANSFER_SIZE_MASK,
};
static struct amba_id pl08x_ids[] = {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/18] ARM: s3c64xx: clock: Add clkdev lookup for DMA clocks
This patch adds clkdev lookup entries for clocks used by PL08x DMA
driver.
Signed-off-by: Tomasz Figa
---
arch/arm/mach-s3c64xx/clock.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/clock.c b/arch/arm/mach-s3c64xx/clock.c
index 8499415..33aa851 100644
--- a/arch/arm/mach-s3c64xx/clock.c
+++ b/arch/arm/mach-s3c64xx/clock.c
@@ -194,16 +194,6 @@ static struct clk init_clocks_off[] = {
.enable = s3c64xx_hclk_ctrl,
.ctrlbit= S3C_CLKCON_HCLK_IHOST,
}, {
- .name = "dma0",
- .parent = _h,
- .enable = s3c64xx_hclk_ctrl,
- .ctrlbit= S3C_CLKCON_HCLK_DMA0,
- }, {
- .name = "dma1",
- .parent = _h,
- .enable = s3c64xx_hclk_ctrl,
- .ctrlbit= S3C_CLKCON_HCLK_DMA1,
- }, {
.name = "3dse",
.parent = _h,
.enable = s3c64xx_hclk_ctrl,
@@ -345,6 +335,20 @@ static struct clk clk_i2s2 = {
};
#endif
+static struct clk clk_dma0 = {
+ .name = "dma0",
+ .parent = _h,
+ .enable = s3c64xx_hclk_ctrl,
+ .ctrlbit= S3C_CLKCON_HCLK_DMA0,
+};
+
+static struct clk clk_dma1 = {
+ .name = "dma1",
+ .parent = _h,
+ .enable = s3c64xx_hclk_ctrl,
+ .ctrlbit= S3C_CLKCON_HCLK_DMA1,
+};
+
static struct clk init_clocks[] = {
{
.name = "lcd",
@@ -849,6 +853,8 @@ static struct clk *clk_cdev[] = {
_48m_spi1,
_i2s0,
_i2s1,
+ _dma0,
+ _dma1,
};
static struct clk_lookup s3c64xx_clk_lookup[] = {
@@ -873,6 +879,8 @@ static struct clk_lookup s3c64xx_clk_lookup[] = {
CLKDEV_INIT("samsung-i2s.2", "i2s_opclk0", _i2s2),
CLKDEV_INIT("samsung-i2s.2", "i2s_opclk1", _audio_bus2.clk),
#endif
+ CLKDEV_INIT("dma-pl080s.0", "apb_pclk", _dma0),
+ CLKDEV_INIT("dma-pl080s.1", "apb_pclk", _dma1),
};
#define GET_DIV(clk, field) clk) & field##_MASK) >> field##_SHIFT) + 1)
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/18] spi: s3c64xx: Do not require legacy DMA API in case of S3C64XX
With support for amba-pl08x driver, on S3C64xx the generic DMA engine API can be used instead of the private s3c-dma interface. Signed-off-by: Tomasz Figa Acked-by: Linus Walleij --- drivers/spi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 89cbbab..241a049 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -366,7 +366,7 @@ config SPI_S3C24XX_FIQ config SPI_S3C64XX tristate "Samsung S3C64XX series type SPI" depends on (ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5P64X0 || ARCH_EXYNOS) - select S3C64XX_DMA if ARCH_S3C64XX + select S3C64XX_DMA if ARCH_S3C64XX && !S3C64XX_PL080 help SPI driver for Samsung S3C64XX and newer SoCs. -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] __ptrace_may_access() should not deny sub-threads
From: Mark Grondona
__ptrace_may_access() checks get_dumpable/ptrace_has_cap/etc
if task != current, this can can lead to surprising results.
For example, a sub-thread can't readlink("/proc/self/exe") if
the executable is not readable. setup_new_exec()->would_dump()
notices that inode_permission(MAY_READ) fails and then it does
set_dumpable(suid_dumpable). After that get_dumpable() fails.
(It is not clear why proc_pid_readlink() checks get_dumpable(),
perhaps we could add PTRACE_MODE_NODUMPABLE)
Change __ptrace_may_access() to use same_thread_group() instead
of "task == current". Any security check is pointless when the
tasks share the same ->mm.
Signed-off-by: Mark Grondona
Signed-off-by: Ben Woodard
Signed-off-by: Oleg Nesterov
---
kernel/ptrace.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index a146ee3..dd562e9 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -236,7 +236,7 @@ static int __ptrace_may_access(struct task_struct *task,
unsigned int mode)
*/
int dumpable = 0;
/* Don't let security modules deny introspection */
- if (task == current)
+ if (same_thread_group(task, current))
return 0;
rcu_read_lock();
tcred = __task_cred(task);
--
1.5.5.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 0/3] tracing: kill the no longer needed PITA code
On 07/31, Steven Rostedt wrote: > > On Wed, 2013-07-31 at 19:31 +0200, Oleg Nesterov wrote: > > Hello. > > > > Simple cleanups on top of the recent (already applied) > > id/filter/format/enable changes. > > > > f_op->owner == mod is no longer needed and can go away. > > > > This patch set is not needed for 3.11. I'll be holding off my review > until I have all the 3.11 patches settled. It seems that you have no more 3.11 patches. Should I resend this series? Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 8/9] migrate: check movability of hugepage in unmap_and_move_huge_page()
Naoya Horiguchi writes:
> Currently hugepage migration works well only for pmd-based hugepages
> (mainly due to lack of testing,) so we had better not enable migration
> of other levels of hugepages until we are ready for it.
>
> Some users of hugepage migration (mbind, move_pages, and migrate_pages)
> do page table walk and check pud/pmd_huge() there, so they are safe.
> But the other users (softoffline and memory hotremove) don't do this,
> so without this patch they can try to migrate unexpected types of hugepages.
>
> To prevent this, we introduce hugepage_migration_support() as an architecture
> dependent check of whether hugepage are implemented on a pmd basis or not.
> And on some architecture multiple sizes of hugepages are available, so
> hugepage_migration_support() also checks hugepage size.
>
> Signed-off-by: Naoya Horiguchi
> ---
> arch/arm/mm/hugetlbpage.c | 5 +
> arch/arm64/mm/hugetlbpage.c | 5 +
> arch/ia64/mm/hugetlbpage.c| 5 +
> arch/metag/mm/hugetlbpage.c | 5 +
> arch/mips/mm/hugetlbpage.c| 5 +
> arch/powerpc/mm/hugetlbpage.c | 10 ++
> arch/s390/mm/hugetlbpage.c| 5 +
> arch/sh/mm/hugetlbpage.c | 5 +
> arch/sparc/mm/hugetlbpage.c | 5 +
> arch/tile/mm/hugetlbpage.c| 5 +
> arch/x86/mm/hugetlbpage.c | 8
> include/linux/hugetlb.h | 12
> mm/migrate.c | 10 ++
> 13 files changed, 85 insertions(+)
>
> diff --git v3.11-rc3.orig/arch/arm/mm/hugetlbpage.c
> v3.11-rc3/arch/arm/mm/hugetlbpage.c
> index 3d1e4a2..3f3b6a7 100644
> --- v3.11-rc3.orig/arch/arm/mm/hugetlbpage.c
> +++ v3.11-rc3/arch/arm/mm/hugetlbpage.c
> @@ -99,3 +99,8 @@ int pmd_huge(pmd_t pmd)
> {
> return pmd_val(pmd) && !(pmd_val(pmd) & PMD_TABLE_BIT);
> }
> +
> +int pmd_huge_support(void)
> +{
> + return 1;
> +}
> diff --git v3.11-rc3.orig/arch/arm64/mm/hugetlbpage.c
> v3.11-rc3/arch/arm64/mm/hugetlbpage.c
> index 2fc8258..5e9aec3 100644
> --- v3.11-rc3.orig/arch/arm64/mm/hugetlbpage.c
> +++ v3.11-rc3/arch/arm64/mm/hugetlbpage.c
> @@ -54,6 +54,11 @@ int pud_huge(pud_t pud)
> return !(pud_val(pud) & PUD_TABLE_BIT);
> }
>
> +int pmd_huge_support(void)
> +{
> + return 1;
> +}
> +
> static __init int setup_hugepagesz(char *opt)
> {
> unsigned long ps = memparse(opt, );
> diff --git v3.11-rc3.orig/arch/ia64/mm/hugetlbpage.c
> v3.11-rc3/arch/ia64/mm/hugetlbpage.c
> index 76069c1..68232db 100644
> --- v3.11-rc3.orig/arch/ia64/mm/hugetlbpage.c
> +++ v3.11-rc3/arch/ia64/mm/hugetlbpage.c
> @@ -114,6 +114,11 @@ int pud_huge(pud_t pud)
> return 0;
> }
>
> +int pmd_huge_support(void)
> +{
> + return 0;
> +}
> +
> struct page *
> follow_huge_pmd(struct mm_struct *mm, unsigned long address, pmd_t *pmd, int
> write)
> {
> diff --git v3.11-rc3.orig/arch/metag/mm/hugetlbpage.c
> v3.11-rc3/arch/metag/mm/hugetlbpage.c
> index 3c52fa6..0424315 100644
> --- v3.11-rc3.orig/arch/metag/mm/hugetlbpage.c
> +++ v3.11-rc3/arch/metag/mm/hugetlbpage.c
> @@ -110,6 +110,11 @@ int pud_huge(pud_t pud)
> return 0;
> }
>
> +int pmd_huge_support(void)
> +{
> + return 1;
> +}
> +
> struct page *follow_huge_pmd(struct mm_struct *mm, unsigned long address,
>pmd_t *pmd, int write)
> {
> diff --git v3.11-rc3.orig/arch/mips/mm/hugetlbpage.c
> v3.11-rc3/arch/mips/mm/hugetlbpage.c
> index a7fee0d..01fda44 100644
> --- v3.11-rc3.orig/arch/mips/mm/hugetlbpage.c
> +++ v3.11-rc3/arch/mips/mm/hugetlbpage.c
> @@ -85,6 +85,11 @@ int pud_huge(pud_t pud)
> return (pud_val(pud) & _PAGE_HUGE) != 0;
> }
>
> +int pmd_huge_support(void)
> +{
> + return 1;
> +}
> +
> struct page *
> follow_huge_pmd(struct mm_struct *mm, unsigned long address,
> pmd_t *pmd, int write)
> diff --git v3.11-rc3.orig/arch/powerpc/mm/hugetlbpage.c
> v3.11-rc3/arch/powerpc/mm/hugetlbpage.c
> index 834ca8e..d67db4b 100644
> --- v3.11-rc3.orig/arch/powerpc/mm/hugetlbpage.c
> +++ v3.11-rc3/arch/powerpc/mm/hugetlbpage.c
> @@ -86,6 +86,11 @@ int pgd_huge(pgd_t pgd)
>*/
> return ((pgd_val(pgd) & 0x3) != 0x0);
> }
> +
> +int pmd_huge_support(void)
> +{
> + return 1;
> +}
> #else
> int pmd_huge(pmd_t pmd)
> {
> @@ -101,6 +106,11 @@ int pgd_huge(pgd_t pgd)
> {
> return 0;
> }
> +
> +int pmd_huge_support(void)
> +{
> + return 0;
> +}
> #endif
>
> pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
> diff --git v3.11-rc3.orig/arch/s390/mm/hugetlbpage.c
> v3.11-rc3/arch/s390/mm/hugetlbpage.c
> index 121089d..951ee25 100644
> --- v3.11-rc3.orig/arch/s390/mm/hugetlbpage.c
> +++ v3.11-rc3/arch/s390/mm/hugetlbpage.c
> @@ -117,6 +117,11 @@ int pud_huge(pud_t pud)
> return 0;
> }
>
> +int pmd_huge_support(void)
> +{
> + return 1;
> +}
> +
> struct page *follow_huge_pmd(struct mm_struct *mm, unsigned long address,
>pmd_t *pmdp, int write)
> {
> diff --git
Re: Patch for lost wakeups
On 08/10, Long Gao wrote: > > By the way, could you help me join the linux kernel mailling list? Do you mean, you want to subscribe? Well, from http://www.tux.org/lkml/#s3-1 send the line "subscribe linux-kernel your_email@your_ISP" in the body of the message to majord...@vger.kernel.org but since I was never subscribed I do not really know if this works ;) > I have sent two letters to "Linux Kernel Mailing > List", > but did not receive any confirmation letter, except for two letters containing > instructions, 3X! If you simply want to send emails to this list, you do not need to subscribe. However, I do not see your email in http://marc.info/?t=13759860691 Perhaps this list doesn't like chinese letters in subject/body? Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 9/9] prepare to remove /proc/sys/vm/hugepages_treat_as_movable
Naoya Horiguchi writes:
> Now we have extended hugepage migration and it's opened to many users
> of page migration, which is a good reason to consider hugepage as movable.
> So we can go to the direction to remove this parameter. In order to
> allow userspace to prepare for the removal, let's leave this sysctl handler
> as noop for a while.
>
> Note that hugepage migration is available only for the architectures
> which implement hugepage on a pmd basis. On the other architectures,
> allocating hugepages from MOVABLE is not a good idea because it can
> break memory hotremove (which expects that all pages of ZONE_MOVABLE are
> movable.) So we choose GFP flags in accordance with mobility of hugepage.
>
> ChangeLog v5:
> - choose GFP flags in accordance with mobility of hugepage
>
> ChangeLog v3:
> - use WARN_ON_ONCE
>
> ChangeLog v2:
> - shift to noop function instead of completely removing the parameter
> - rename patch title
>
> Signed-off-by: Naoya Horiguchi
> Acked-by: Andi Kleen
> Reviewed-by: Wanpeng Li
Ok that mostly address the issue I raised last time, but how do archs
that don't support hugepage migration force the hugepage allocation from
movable zone. They were able to do that before with the sysctl you are
removing in this patch isn't it ? May be keep that interface and print a
warn_on of archs that support hugepage migration ?
> ---
> Documentation/sysctl/vm.txt | 13 ++---
> mm/hugetlb.c| 26 +++---
> 2 files changed, 17 insertions(+), 22 deletions(-)
>
> diff --git v3.11-rc3.orig/Documentation/sysctl/vm.txt
> v3.11-rc3/Documentation/sysctl/vm.txt
> index 36ecc26..6e211a1 100644
> --- v3.11-rc3.orig/Documentation/sysctl/vm.txt
> +++ v3.11-rc3/Documentation/sysctl/vm.txt
> @@ -200,17 +200,8 @@ fragmentation index is <= extfrag_threshold. The default
> value is 500.
>
> hugepages_treat_as_movable
>
> -This parameter is only useful when kernelcore= is specified at boot time to
> -create ZONE_MOVABLE for pages that may be reclaimed or migrated. Huge pages
> -are not movable so are not normally allocated from ZONE_MOVABLE. A non-zero
> -value written to hugepages_treat_as_movable allows huge pages to be allocated
> -from ZONE_MOVABLE.
> -
> -Once enabled, the ZONE_MOVABLE is treated as an area of memory the huge
> -pages pool can easily grow or shrink within. Assuming that applications are
> -not running that mlock() a lot of memory, it is likely the huge pages pool
> -can grow to the size of ZONE_MOVABLE by repeatedly entering the desired value
> -into nr_hugepages and triggering page reclaim.
> +This parameter is obsolete and planned to be removed. The value has no effect
> +on kernel's behavior.
>
> ==
>
> diff --git v3.11-rc3.orig/mm/hugetlb.c v3.11-rc3/mm/hugetlb.c
> index 3121915..b73 100644
> --- v3.11-rc3.orig/mm/hugetlb.c
> +++ v3.11-rc3/mm/hugetlb.c
> @@ -34,7 +34,6 @@
> #include "internal.h"
>
> const unsigned long hugetlb_zero = 0, hugetlb_infinity = ~0UL;
> -static gfp_t htlb_alloc_mask = GFP_HIGHUSER;
> unsigned long hugepages_treat_as_movable;
>
> int hugetlb_max_hstate __read_mostly;
> @@ -535,6 +534,15 @@ static struct page *dequeue_huge_page_node(struct hstate
> *h, int nid)
> return page;
> }
>
> +/* Movability of hugepages depends on migration support. */
> +static inline int htlb_alloc_mask(struct hstate *h)
> +{
> + if (hugepage_migration_support(h))
> + return GFP_HIGHUSER_MOVABLE;
> + else
> + return GFP_HIGHUSER;
> +}
> +
> static struct page *dequeue_huge_page_vma(struct hstate *h,
> struct vm_area_struct *vma,
> unsigned long address, int avoid_reserve)
> @@ -550,7 +558,7 @@ static struct page *dequeue_huge_page_vma(struct hstate
> *h,
> retry_cpuset:
> cpuset_mems_cookie = get_mems_allowed();
> zonelist = huge_zonelist(vma, address,
> - htlb_alloc_mask, , );
> + htlb_alloc_mask(h), , );
> /*
>* A child process with MAP_PRIVATE mappings created by their parent
>* have no page reserves. This check ensures that reservations are
> @@ -566,7 +574,7 @@ static struct page *dequeue_huge_page_vma(struct hstate
> *h,
>
> for_each_zone_zonelist_nodemask(zone, z, zonelist,
> MAX_NR_ZONES - 1, nodemask) {
> - if (cpuset_zone_allowed_softwall(zone, htlb_alloc_mask)) {
> + if (cpuset_zone_allowed_softwall(zone, htlb_alloc_mask(h))) {
> page = dequeue_huge_page_node(h, zone_to_nid(zone));
> if (page) {
> if (!avoid_reserve)
> @@ -723,7 +731,7 @@ static struct page *alloc_fresh_huge_page_node(struct
> hstate *h, int nid)
> return NULL;
>
> page = alloc_pages_exact_node(nid,
> -
Re: Patch for lost wakeups
On 08/11, Oleg Nesterov wrote: > > On 08/09, Linus Torvalds wrote: > > > > I guess that instead of a "smp_wmb()", we could do another > > "smp_mb__before_spinlock()" thing, like we already allow for other > > architectures to do a weaker form of mb in case the spinlock is > > already a full mb. That would allow avoiding extra synchronization. Do > > a > > > >#ifndef smp_mb__before_spinlock > > #define smp_mb__before_spinlock() smp_wmb() > >#endif > > > > in to not force everybody to implement it. Because > > a wmb+acquire should be close enough to a full mb that nobody cares > > (ok, so reads could move into the critical region from outside, but by > > the time anybody has called "schedule()", I can't see it mattering, so > > "close enough"). > > Yes, this is what I tried to suggest. And of course we should turn that > wmb() in try_to_wake_up() into smp_mb__before_spinlock(). > > I event started the patch, but we already have smp_mb__after_lock(), so > it should be smp_mb__before_lock() for consistency and we need to turn > it to "define" too. Or change ARCH_HAS_SMP_MB_AFTER_LOCK, or add > ARCH_HAS_SMP_MB_BEFORE_LOCK. Ah, please ignore. According to /bin/grep smp_mb__before_lock() no longer have users. So we can probably simply kill it in the same patch. I'll try to write the changelog and send it tomorrow. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 for lost wakeups
On 08/09, Linus Torvalds wrote: > > I guess that instead of a "smp_wmb()", we could do another > "smp_mb__before_spinlock()" thing, like we already allow for other > architectures to do a weaker form of mb in case the spinlock is > already a full mb. That would allow avoiding extra synchronization. Do > a > >#ifndef smp_mb__before_spinlock > #define smp_mb__before_spinlock() smp_wmb() >#endif > > in to not force everybody to implement it. Because > a wmb+acquire should be close enough to a full mb that nobody cares > (ok, so reads could move into the critical region from outside, but by > the time anybody has called "schedule()", I can't see it mattering, so > "close enough"). Yes, this is what I tried to suggest. And of course we should turn that wmb() in try_to_wake_up() into smp_mb__before_spinlock(). I event started the patch, but we already have smp_mb__after_lock(), so it should be smp_mb__before_lock() for consistency and we need to turn it to "define" too. Or change ARCH_HAS_SMP_MB_AFTER_LOCK, or add ARCH_HAS_SMP_MB_BEFORE_LOCK. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
