Re: [PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250
Hi,
On 04/25/2014 02:54 PM, Tushar Behera wrote:
> On 04/25/2014 11:13 AM, Chanwoo Choi wrote:
>> Hi,
>>
>> On 04/25/2014 01:30 PM, Tushar Behera wrote:
>>> On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
This patch fix the offset of CPU boot address and don't need to send smc
call
of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250
removes
WFE in secure mode.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/mach-exynos/firmware.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/firmware.c
b/arch/arm/mach-exynos/firmware.c
index aa01c42..386d01d 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -31,11 +31,17 @@ static int exynos_do_idle(void)
static int exynos_cpu_boot(int cpu)
{
/*
+ * Exynos3250 doesn't need to send smc command for secondary CPU boot
+ * because Exynos3250 removes WFE in secure mode.
+ */
+ if (soc_is_exynos3250())
+ return 0;
+ /*
* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
* But, Exynos4212 has only one secondary CPU so second parameter
* isn't used for informing secure firmware about CPU id.
*/
- if (soc_is_exynos4212())
+ else if (soc_is_exynos4212())
>>>
>>> This changes is not required.
>>
>> Do you mean it as following?
>>
>> if (soc_is_exynos3250())
>> return 0
>>
>> if (soc_is_exynos4212())
>> cpu = 0;
>>
>
> Yes, logically the flow would be same and code would be more readable.
OK, I'll fix it.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] staging: panel: fix sparse warnings in lcd_write
On Wed, Apr 23, 2014 at 07:35:02PM +0200, Bastien Armand wrote:
> On Tue, Apr 22, 2014 at 01:01:45PM +0300, Dan Carpenter wrote:
> > Btw, this whole function is terrible. It should be reading larger
> > chunks at once instead of get_user() for each character.
Just for the record, very small character counts may be sent to an LCD
panel, in general these are 2 lines of 16 characters, and at most 2x40,
and changes are very rare. The worst case will be if someone displays
the time of day, it will change every second.
> > > + if (lcd_enabled && lcd_initialized) {
> > > + for (; count-- > 0; tmp++) {
> > > + if (!in_interrupt() && (((count + 1) & 0x1f) == 0))
> > > + /* let's be a little nice with other processes
> > > +that need some CPU */
> > > + schedule();
> >
> > This schedule() isn't needed. It just prints a line or two at start up
> > and some other debug output or something. Small small.
> >
>
> I hesitated to remove it. I leave it here as it was allready in lcd_write.
> Perhaps, I could send another patch to remove it.
I believe it can go. I have some memories of it when I was developing the
driver because I didn't know if some LCDs would need long pauses between
each character. Hmmm well, thinking about it after re-reading the code,
we could wait up to 20+40+120 = 180 microseconds when sending one command
(eg: position change), or 20+40+45 = 105 microseconds when sending one
char. That's basically 180+40*105 = 4.185 milliseconds for one full line,
or 8 milliseconds for two lines of 40 chars. So maybe we should keep the
schedule() in the end...
Best regards,
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250
On 04/25/2014 11:13 AM, Chanwoo Choi wrote:
> Hi,
>
> On 04/25/2014 01:30 PM, Tushar Behera wrote:
>> On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
>>> This patch fix the offset of CPU boot address and don't need to send smc
>>> call
>>> of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250
>>> removes
>>> WFE in secure mode.
>>>
>>> Signed-off-by: Chanwoo Choi
>>> Acked-by: Kyungmin Park
>>> ---
>>> arch/arm/mach-exynos/firmware.c | 10 --
>>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/firmware.c
>>> b/arch/arm/mach-exynos/firmware.c
>>> index aa01c42..386d01d 100644
>>> --- a/arch/arm/mach-exynos/firmware.c
>>> +++ b/arch/arm/mach-exynos/firmware.c
>>> @@ -31,11 +31,17 @@ static int exynos_do_idle(void)
>>> static int exynos_cpu_boot(int cpu)
>>> {
>>> /*
>>> +* Exynos3250 doesn't need to send smc command for secondary CPU boot
>>> +* because Exynos3250 removes WFE in secure mode.
>>> +*/
>>> + if (soc_is_exynos3250())
>>> + return 0;
>>> + /*
>>> * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
>>> * But, Exynos4212 has only one secondary CPU so second parameter
>>> * isn't used for informing secure firmware about CPU id.
>>> */
>>> - if (soc_is_exynos4212())
>>> + else if (soc_is_exynos4212())
>>
>> This changes is not required.
>
> Do you mean it as following?
>
> if (soc_is_exynos3250())
> return 0
>
> if (soc_is_exynos4212())
> cpu = 0;
>
Yes, logically the flow would be same and code would be more readable.
>>
>>> cpu = 0;
>>>
>>> exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
>>> @@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned
>>> long boot_addr)
>>> {
>>> void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
>>>
>>> - if (!soc_is_exynos4212())
>>> + if (!soc_is_exynos4212() && !soc_is_exynos3250())
>>> boot_reg += 4*cpu;
>>>
>>> __raw_writel(boot_addr, boot_reg);
>>>
>>
>>
>
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched, fair: Stop searching for tasks in newidle balance if there are runnable tasks
On Thu, 2014-04-24 at 20:33 -0700, Jason Low wrote: > On Fri, 2014-04-25 at 04:45 +0200, Mike Galbraith wrote: > > On Thu, 2014-04-24 at 18:52 +0200, Peter Zijlstra wrote: > > > On Thu, Apr 24, 2014 at 09:43:09AM -0700, Jason Low wrote: > > > > If the below patch is what you were referring to, I believe this > > > > can help too. This was also something that I was testing out before > > > > we went with those patches which compares avg_idle with idle balance > > > > cost. I recall seeing somewhere around a +7% performance improvement > > > > in at least least 1 of the AIM7 workloads. I can do some more testing > > > > with this. > > > > > > Yes, exactly that. > > > > > > I can't remember the details, but I suspect we feared the less agressive > > > idle balance due to that patch (it will only pull a single task, instead > > > of multiple) would cause more idle_balance invocations and thereby > > > decrease throughput. > > > > > > So I suppose something with _many_ bursty threads which leads to severe > > > inequalities would be the workload to trigger that. > > > > > > Not sure we've ever seen that.. maybe Mike remembers, he seems to have a > > > head for such details. > > > > I don't recall ever seeing such. > > Hmmm, could commit: 1b9508f6831e (sched: Rate-limit newidle) be related > to what Peter's referring to? The patch mentioned that the rate-limit > benefited "sysbench oltp". That's the opposite, was to prevent way too much idle balancing, which was demolishing fast mover loads. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] Add support for flag status register on Micron chips.
On Tue, Apr 22, 2014 at 01:48:21PM -0500, Graham Moore wrote:
> On Tue, Apr 22, 2014 at 11:55 AM, Marek Vasut wrote:
> > Are you sure the n25q512a doesn't use FSR ? Do n25q512a{1,8}3 share the same
> > IDs?
>
> I looked at the datasheet and the n25q512a *does* have the same FSR
> usage note, so I suppose I should add USE_FSR to it as well. But how
> is it working now? Maybe nobody is actually using that chip.
> Yes, n25q512a{1,8}3 share the same id, 0x20ba20.
>
could use the ext_id to distinguish them ? just as we did for Spansion NOR.
i dumped out 5 bytes of my n25q256a: 0x20, 0xba, 0x19, 0x10, 0x00.
thanks
Huang Shijie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250
Hi,
On 04/25/2014 01:30 PM, Tushar Behera wrote:
> On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
>> This patch fix the offset of CPU boot address and don't need to send smc call
>> of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 removes
>> WFE in secure mode.
>>
>> Signed-off-by: Chanwoo Choi
>> Acked-by: Kyungmin Park
>> ---
>> arch/arm/mach-exynos/firmware.c | 10 --
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/firmware.c
>> b/arch/arm/mach-exynos/firmware.c
>> index aa01c42..386d01d 100644
>> --- a/arch/arm/mach-exynos/firmware.c
>> +++ b/arch/arm/mach-exynos/firmware.c
>> @@ -31,11 +31,17 @@ static int exynos_do_idle(void)
>> static int exynos_cpu_boot(int cpu)
>> {
>> /*
>> + * Exynos3250 doesn't need to send smc command for secondary CPU boot
>> + * because Exynos3250 removes WFE in secure mode.
>> + */
>> +if (soc_is_exynos3250())
>> +return 0;
>> +/*
>> * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
>> * But, Exynos4212 has only one secondary CPU so second parameter
>> * isn't used for informing secure firmware about CPU id.
>> */
>> -if (soc_is_exynos4212())
>> +else if (soc_is_exynos4212())
>
> This changes is not required.
Do you mean it as following?
if (soc_is_exynos3250())
return 0
if (soc_is_exynos4212())
cpu = 0;
>
>> cpu = 0;
>>
>> exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
>> @@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long
>> boot_addr)
>> {
>> void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
>>
>> -if (!soc_is_exynos4212())
>> +if (!soc_is_exynos4212() && !soc_is_exynos3250())
>> boot_reg += 4*cpu;
>>
>> __raw_writel(boot_addr, boot_reg);
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] sysrq,rcu: suppress RCU stall warnings while sysrq runs
On Thu, 2014-04-24 at 09:04 -0400, Rik van Riel wrote:
> diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> index 4c0a9b0..2ac3289 100644
> --- a/kernel/rcu/update.c
> +++ b/kernel/rcu/update.c
> @@ -320,6 +320,17 @@ int rcu_jiffies_till_stall_check(void)
> return till_stall_check * HZ + RCU_STALL_DELAY_DELTA;
> }
>
> +void rcu_sysrq_start(void)
> +{
> + rcu_cpu_stall_suppress = 2;
> +}
Monster box folks seem to routinely kill that at boot, probably won't
want it coming back to life at the poke of a button.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 6/7] arm64: mm: Implement 4 levels of translation tables
On Thursday, April 24, 2014 1:02 AM, Steve Capper wrote: > On Fri, Apr 18, 2014 at 04:59:20PM +0900, Jungseok Lee wrote: > > This patch implements 4 levels of translation tables since 3 levels of > > page tables with 4KB pages cannot support 40-bit physical address > > space described in [1] due to the following issue. > > > > It is a restriction that kernel logical memory map with 4KB + 3 levels > > (0xffc0-0x) cannot cover RAM region from > > 544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create > > mapping for this region in map_mem function since __phys_to_virt for > > this region reaches to address overflow. > > > > If SoC design follows the document, [1], over 32GB RAM would be placed > > from 544GB. Even 64GB system is supposed to use the region from 544GB > > to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 > > levels of page tables to avoid hacking __virt_to_phys and __phys_to_virt. > > > > However, it is recommended 4 levels of page table should be only > > enabled if memory map is too sparse or there is about 512GB RAM. > > Hello Jungseok, > A few comments can be found inline... Hi Steve, The comments are very helpful. Thanks. [ ... ] > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index > > 0fd5650..f313a7a 100644 > > --- a/arch/arm64/kernel/head.S > > +++ b/arch/arm64/kernel/head.S > > @@ -37,8 +37,8 @@ > > > > /* > > * swapper_pg_dir is the virtual address of the initial page table. > > We place > > - * the page tables 3 * PAGE_SIZE below KERNEL_RAM_VADDR. The > > idmap_pg_dir has > > - * 2 pages and is placed below swapper_pg_dir. > > + * the page tables 4 * PAGE_SIZE below KERNEL_RAM_VADDR. The > > + idmap_pg_dir has > > + * 3 pages and is placed below swapper_pg_dir. > > */ > > #define KERNEL_RAM_VADDR (PAGE_OFFSET + TEXT_OFFSET) > > > > @@ -46,8 +46,8 @@ > > #error KERNEL_RAM_VADDR must start at 0xXXX8 #endif > > > > -#define SWAPPER_DIR_SIZE (3 * PAGE_SIZE) > > -#define IDMAP_DIR_SIZE (2 * PAGE_SIZE) > > +#define SWAPPER_DIR_SIZE (4 * PAGE_SIZE) > > +#define IDMAP_DIR_SIZE (3 * PAGE_SIZE) > > > > .globl swapper_pg_dir > > .equswapper_pg_dir, KERNEL_RAM_VADDR - SWAPPER_DIR_SIZE > > @@ -371,16 +371,29 @@ ENDPROC(__calc_phys_offset) > > > > /* > > * Macro to populate the PGD for the corresponding block entry in the > > next > > - * level (tbl) for the given virtual address. > > + * levels (tbl1 and tbl2) for the given virtual address. > > * > > - * Preserves: pgd, tbl, virt > > + * Preserves: pgd, tbl1, tbl2, virt > > tbl1 and tbl2 are *not* preserved for 4 level. tbl1 is bumped up one page to > make space for the pud, > then fed into create_block_mapping later. Your logic can be extended to 3 levels. In an original code, tbl is fed into create_block_mapping. That is why I've written them down as "preserves". I will fix it in the next version. > > * Corrupts: tmp1, tmp2 > > */ > > - .macro create_pgd_entry, pgd, tbl, virt, tmp1, tmp2 > > + .macro create_pgd_entry, pgd, tbl1, tbl2, virt, tmp1, tmp2 > > lsr \tmp1, \virt, #PGDIR_SHIFT > > and \tmp1, \tmp1, #PTRS_PER_PGD - 1 // PGD index > > - orr \tmp2, \tbl, #3 // PGD entry table type > > + orr \tmp2, \tbl1, #3// PGD entry table type > > str \tmp2, [\pgd, \tmp1, lsl #3] > > +#ifdef CONFIG_ARM64_4_LEVELS > > + ldr \tbl2, =FIXADDR_TOP > > + cmp \tbl2, \virt > > Do we need this extra logic? See my other comment below where the fixed > mapping is placed down. > > > + add \tbl2, \tbl1, #PAGE_SIZE > > + b.ne1f > > + add \tbl2, \tbl2, #PAGE_SIZE > > +1: > > + lsr \tmp1, \virt, #PUD_SHIFT > > + and \tmp1, \tmp1, #PTRS_PER_PUD - 1 // PUD index > > + orr \tmp2, \tbl2, #3// PUD entry table type > > + str \tmp2, [\tbl1, \tmp1, lsl #3] > > + mov \tbl1, \tbl2 > > +#endif > > It may be easier to read to have a create_pud_entry macro too? Okay. I will write a create_pud_entry macro. > > .endm > > > > /* > > @@ -444,7 +457,7 @@ __create_page_tables: > > add x0, x25, #PAGE_SIZE // section table address > > ldr x3, =KERNEL_START > > add x3, x3, x28 // __pa(KERNEL_START) > > - create_pgd_entry x25, x0, x3, x5, x6 > > + create_pgd_entry x25, x0, x1, x3, x5, x6 > > ldr x6, =KERNEL_END > > mov x5, x3 // __pa(KERNEL_START) > > add x6, x6, x28 // __pa(KERNEL_END) > > @@ -455,7 +468,7 @@ __create_page_tables: > > */ > > add x0, x26, #PAGE_SIZE // section table address > > mov x5, #PAGE_OFFSET > > - create_pgd_entry x26, x0, x5, x3, x6 > > + create_pgd_entry x26, x0, x1, x5, x3, x6 > > ldr x6, =KERNEL_END > > mov x3, x24 // phys offset > >
Re: [RFC 0/4] Migrate timers away from cpuset on setting cpuset.quiesce
On 2014/04/25 13:51, Viresh Kumar wrote: > On 25 April 2014 06:01, Daniel Sangorrin > wrote: >> I can't keep it as a separate patch and so would be required to merge it into my original patch.. >>> >>> And the reason being: "No patch is supposed to break things, otherwise >>> git bisect wouldn't work smoothly".. And so git bisect would complain >>> this issue after my patch and so I have to merge the fixes you gave into >>> the original patch as its not yet merged. >>> -- >>> To unsubscribe from this list: send the line "unsubscribe cgroups" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> Ok, no problem then. > > Do you want me to add your Tested-by for my next version ? > > Sure. Tested-by: Daniel Sangorrin -- Toshiba Corporate Software Engineering Center Daniel SANGORRIN E-mail: daniel.sangor...@toshiba.co.jp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] sched, balancing: Update rq->max_idle_balance_cost whenever newidle balance is attempted
Hi Jason,
On 04/25/2014 03:48 AM, Jason Low wrote:
> On Thu, 2014-04-24 at 19:14 +0200, Peter Zijlstra wrote:
>> On Thu, Apr 24, 2014 at 09:53:37AM -0700, Jason Low wrote:
>>>
>>> So I thought that the original rationale (commit 1bd77f2d) behind
>>> updating rq->next_balance in idle_balance() is that, if we are going
>>> idle (!pulled_task), we want to ensure that the next_balance gets
>>> calculated without the busy_factor.
>>>
>>> If the rq is busy, then rq->next_balance gets updated based on
>>> sd->interval * busy_factor. However, when the rq goes from "busy"
>>> to idle, rq->next_balance might still have been calculated under
>>> the assumption that the rq is busy. Thus, if we are going idle, we
>>> would then properly update next_balance without the busy factor
>>> if we update when !pulled_task.
>>>
>>
>> Its late here and I'm confused!
>>
>> So the for_each_domain() loop calculates a new next_balance based on
>> ->balance_interval (which has that busy_factor on, right).
>>
>> But if it fails to pull anything, we'll (potentially) iterate the entire
>> tree up to the largest domain; and supposedly set next_balanced to the
>> largest possible interval.
>>
>> So when we go from busy to idle (!pulled_task), we actually set
>> ->next_balance to the longest interval. Whereas the commit you
>> referenced says it sets it to a shorter while.
>>
>> Not seeing it.
>
> So this is the way I understand that code:
>
> In rebalance_domain, next_balance is suppose to be set to the
> minimum of all sd->last_balance + interval so that we properly call
> into rebalance_domains() if one of the domains is due for a balance.
>
> In the domain traversals:
>
> if (time_after(next_balance, sd->last_balance + interval))
> next_balance = sd->last_balance + interval;
>
> we update next_balance to a new value if the current next_balance
> is after, and we only update next_balance to a smaller value.
>
> In rebalance_domains, we have code:
>
> interval = sd->balance_interval;
> if (idle != CPU_IDLE)
> interval *= sd->busy_factor;
>
> ...
>
> if (time_after(next_balance, sd->last_balance + interval)) {
> next_balance = sd->last_balance + interval;
>
> ...
>
> rq->next_balance = next_balance;
>
> In the CPU_IDLE case, interval would not include the busy factor,
> whereas in the !CPU_IDLE case, we multiply the interval by the
> sd->busy_factor.
>
> So as an example, if a CPU is not idle and we run this:
>
> rebalance_domain()
> interval = 1 ms;
> if (idle != CPU_IDLE)
> interval *= 64;
>
> next_balance = sd->last_balance + 64 ms
>
> rq->next_balance = next_balance
>
> The rq->next_balance is set to a large value since the CPU is not idle.
>
> Then, let's say the CPU then goes idle 1 ms later. The
> rq->next_balance can be up to 63 ms later, because we computed
> it when the CPU is not idle. Now that we are going idle,
> we would have to wait a long time for the next balance.
>
> So I believe that the initial reason why rq->next_balance was
> updated in idle_balance is that if the CPU is in the process
> of going idle (!pulled_task in idle_balance()), we can reset the
> rq->next_balance based on the interval = 1 ms, as oppose to
> having it remain up to 64 ms later (in idle_balance(), interval
> doesn't get multiplied by sd->busy_factor).
I agree with this. However I am concerned with an additional point that
I have mentioned in my reply to Peter's mail on this thread.
Should we verify if rq->next_balance update is independent of
pulled_tasks? sd->balance_interval is changed during load_balance() and
rq->next_balance should perhaps consider that?
Regards
Preeti U Murthy
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] sched, balancing: Update rq->max_idle_balance_cost whenever newidle balance is attempted
On 04/24/2014 10:44 PM, Peter Zijlstra wrote: > On Thu, Apr 24, 2014 at 09:53:37AM -0700, Jason Low wrote: >> >> So I thought that the original rationale (commit 1bd77f2d) behind >> updating rq->next_balance in idle_balance() is that, if we are going >> idle (!pulled_task), we want to ensure that the next_balance gets >> calculated without the busy_factor. >> >> If the rq is busy, then rq->next_balance gets updated based on >> sd->interval * busy_factor. However, when the rq goes from "busy" >> to idle, rq->next_balance might still have been calculated under >> the assumption that the rq is busy. Thus, if we are going idle, we >> would then properly update next_balance without the busy factor >> if we update when !pulled_task. >> > > Its late here and I'm confused! > > So the for_each_domain() loop calculates a new next_balance based on > ->balance_interval (which has that busy_factor on, right). > > But if it fails to pull anything, we'll (potentially) iterate the entire > tree up to the largest domain; and supposedly set next_balanced to the > largest possible interval. *to the smallest possible interval. > > So when we go from busy to idle (!pulled_task), we actually set > ->next_balance to the longest interval. Whereas the commit you > referenced says it sets it to a shorter while. We will set next_balance to the earliest balance time among the sched domains iterated. > > Not seeing it. > > So the code as modified by Ingo in one of the initial CFS commits, will > move the ->next_balance time ahead if the balance succeeded > (pulled_task), thereby reflecting that we are busy and we just did a > balance so we need not do one again soon. (we might want to re-think > this if we really make the idle balance only pull 1 task max). > > Of course, I've now gone over this code 3 times today, so I'm terminally > confused. I am unable to understand how updating of rq->next_balance should depend solely on the pulled_task parameter( I am not considering the expiry of rq->next_balance here). True that we will need to override the busy_factor in rq->next_balance if we do not pull any tasks and go to idle. Besides that however we will probably need to override rq->next_balance irrespective of whether we pull any tasks. Lets look at what happens to the sd->balance_interval in load_balance(). If we pull tasks then it is set to min_interval. If active balance occurs or if tasks are pinned then we push the interval farther away.In the former case where it is set to min_interval, pulled_tasks > 0, in the latter case, especially the pinned case, pulled_task=0 (not sure about the active balance case). If after this modification on sd->balance_interval, rq->next_balance > sd->last_balance + sd->balance_interval then shouldn't we be resetting rq->next_balance? And if we should, then the dependence on pulled_tasks is not justified is it? All this assuming that rq->next_balance should always reflect the minimum value of sd->next_balance among the sched domains of which the rq is a part. Regards Preeti U Murthy > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ftrace/module: Hardcode ftrace_module_init() call into load_module()
(2014/04/24 23:54), Steven Rostedt wrote:
> [
> Rusty, you can take this patch, or if you want, you can give me
> an Acked-by, and I'll push this through my tree.
> ]
>
>
>>From 3ad4487ccecb8eb799c8e96309f256a1c9296685 Mon Sep 17 00:00:00 2001
> From: "Steven Rostedt (Red Hat)"
> Date: Thu, 24 Apr 2014 10:40:12 -0400
> Subject: [PATCH] ftrace/module: Hardcode ftrace_module_init() call into
> load_module()
>
> A race exists between module loading and enabling of function tracer.
>
> CPU 1 CPU 2
> - -
> load_module()
>module->state = MODULE_STATE_COMING
>
> register_ftrace_function()
>mutex_lock(_lock);
>ftrace_startup()
> update_ftrace_function();
> ftrace_arch_code_modify_prepare()
> set_all_module_text_rw();
>
> ftrace_arch_code_modify_post_process()
>set_all_module_text_ro();
>
> [ here all module text is set to RO,
> including the module that is
> loading!! ]
>
>blocking_notifier_call_chain(MODULE_STATE_COMING);
> ftrace_init_module()
>
> [ tries to modify code, but it's RO, and fails!
>ftrace_bug() is called]
>
> When this race happens, ftrace_bug() will produces a nasty warning and
> all of the function tracing features will be disabled until reboot.
>
> The simple solution is to treate module load the same way the core
> kernel is treated at boot. To hardcode the ftrace function modification
> of converting calls to mcount into nops. This is done in init/main.c
> there's no reason it could not be done in load_module(). This gives
> a better control of the changes and doesn't tie the state of the
> module to its notifiers as much. Ftrace is special, it needs to be
> treated as such.
>
> The reason this would work, is that the ftrace_module_init() would be
> called while the module is in MODULE_STATE_UNFORMED, which is ignored
> by the set_all_module_text_ro() call.
>
> Link:
> http://lkml.kernel.org/r/1395637826-3312-1-git-send-email-indou.ta...@jp.fujitsu.com
>
> Reported-by: Takao Indoh
> Cc: sta...@vger.kernel.org # 2.6.38+
> Signed-off-by: Steven Rostedt
Looks good to me.
Reviewed-by: Masami Hiramatsu
Thank you,
> ---
> include/linux/ftrace.h | 2 ++
> kernel/module.c| 3 +++
> kernel/trace/ftrace.c | 27 ---
> 3 files changed, 9 insertions(+), 23 deletions(-)
>
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 9212b01..ae9504b 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -535,6 +535,7 @@ static inline int ftrace_modify_call(struct dyn_ftrace
> *rec, unsigned long old_a
> extern int ftrace_arch_read_dyn_info(char *buf, int size);
>
> extern int skip_trace(unsigned long ip);
> +extern void ftrace_module_init(struct module *mod);
>
> extern void ftrace_disable_daemon(void);
> extern void ftrace_enable_daemon(void);
> @@ -544,6 +545,7 @@ static inline int ftrace_force_update(void) { return 0; }
> static inline void ftrace_disable_daemon(void) { }
> static inline void ftrace_enable_daemon(void) { }
> static inline void ftrace_release_mod(struct module *mod) {}
> +static inline void ftrace_module_init(struct module *mod) {}
> static inline __init int register_ftrace_command(struct ftrace_func_command
> *cmd)
> {
> return -EINVAL;
> diff --git a/kernel/module.c b/kernel/module.c
> index 1186940..5f14fec 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3271,6 +3271,9 @@ static int load_module(struct load_info *info, const
> char __user *uargs,
>
> dynamic_debug_setup(info->debug, info->num_debug);
>
> + /* Ftrace init must be called in the MODULE_STATE_UNFORMED state */
> + ftrace_module_init(mod);
> +
> /* Finally it's fully formed, ready to start executing. */
> err = complete_formation(mod, info);
> if (err)
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 1fd4b94..4a54a25 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -4330,16 +4330,11 @@ static void ftrace_init_module(struct module *mod,
> ftrace_process_locs(mod, start, end);
> }
>
> -static int ftrace_module_notify_enter(struct notifier_block *self,
> - unsigned long val, void *data)
> +void ftrace_module_init(struct module *mod)
> {
> - struct module *mod = data;
> -
> - if (val == MODULE_STATE_COMING)
> - ftrace_init_module(mod, mod->ftrace_callsites,
> -mod->ftrace_callsites +
> -mod->num_ftrace_callsites);
> -
[PATCH] f2fs-tools: announce dual licenses with GPL and LGPL v2
This patch announces LGPL v2 for the following files. - include/f2fs_fs.h - lib/libf2fs.c - lib/libf2fs_io.c - mkfs/f2fs_format.c - mkfs/f2fs_format_main.c - mkfs/f2fs_format_utils.c - mkfs/f2fs_format_utils.h Signed-off-by: Jaegeuk Kim --- COPYING | 492 +++ include/f2fs_fs.h| 4 +- lib/libf2fs.c| 4 +- lib/libf2fs_io.c | 4 +- mkfs/f2fs_format.c | 4 +- mkfs/f2fs_format_main.c | 4 +- mkfs/f2fs_format_utils.c | 4 +- mkfs/f2fs_format_utils.h | 4 +- 8 files changed, 499 insertions(+), 21 deletions(-) diff --git a/COPYING b/COPYING index 21cd6db..88dc016 100644 --- a/COPYING +++ b/COPYING @@ -1,5 +1,15 @@ The tools for F2FS are covered by GNU Public License version 2. +Exceptionally, the following files are also covered by the GNU Library General +Public License Version 2 as the dual licenses. +- include/f2fs_fs.h +- lib/libf2fs.c +- lib/libf2fs_io.c +- mkfs/f2fs_format.c +- mkfs/f2fs_format_main.c +- mkfs/f2fs_format_utils.c +- mkfs/f2fs_format_utils.h + Copyright (c) 2012 Samsung Electronics Co., Ltd. http://www.samsung.com/ @@ -348,4 +358,486 @@ proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. + + GNU LIBRARY GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1991 Free Software Foundation, Inc. + 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the library GPL. It is + numbered 2 because it goes with version 2 of the ordinary GPL.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Library General Public License, applies to some +specially designated Free Software Foundation software, and to any +other libraries whose authors decide to use it. You can use it for +your libraries, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if +you distribute copies of the library, or if you modify it. + + For example, if you distribute copies of the library, whether gratis +or for a fee, you must give the recipients all the rights that we gave +you. You must make sure that they, too, receive or can get the source +code. If you link a program with the library, you must provide +complete object files to the recipients so that they can relink them +with the library, after making changes to the library and recompiling +it. And you must show them these terms so they know their rights. + + Our method of protecting your rights has two steps: (1) copyright +the library, and (2) offer you this license which gives you legal +permission to copy, distribute and/or modify the library. + + Also, for each distributor's protection, we want to make certain +that everyone understands that there is no warranty for this free +library. If the library is modified by someone else and passed on, we +want its recipients to know that what they have is not the original +version, so that any problems introduced by others will not reflect on +the original authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that companies distributing free +software will individually obtain patent licenses, thus in effect +transforming the program into proprietary software. To prevent this, +we have made it clear that any patent must be licensed for everyone's +free use or not licensed at all. + + Most GNU software, including some libraries, is covered by the ordinary +GNU General Public License, which was designed for utility programs. This +license, the GNU Library General Public
Re: [GIT PULL] serial: Cadence
On 04/25/2014 01:23 AM, Greg Kroah-Hartman wrote: > On Thu, Apr 24, 2014 at 07:30:48AM +0200, Michal Simek wrote: >> On 04/24/2014 01:48 AM, Greg Kroah-Hartman wrote: >>> On Wed, Apr 23, 2014 at 08:11:15AM +0200, Michal Simek wrote: Hi Greg, this is around for a while and I would like to close it. I have applied patches 1-7 from v3. Patches 8 and 9 should go through arm-soc tree and I will add them to my zynq/dt branch. Please apply these patches to your tree. If this should go through different tree please let me know. Thanks, Michal The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) are available in the git repository at: git://git.monstr.eu/linux-2.6-microblaze.git tags/cadence-uart-for-3.16 >>> >>> I can't take git pulles from random internet sites, sorry. Just send >>> these as email and I will queue them up. >> >> I wouldn't say random. This repo is listed in my Microblaze maintainer >> fragment >> and I used signed tag and you have sign my key that's why you can easily >> check it. > > If you have a signed key, why aren't you using git.kernel.org? Again, I > can't pull from any non-kernel.org sites, sorry. ok. I have never had a need to have git repo at kernel.org. But maybe I should asked for one. >> Anyway we have sent v3 patches via email twice. >> Origin v3: >> https://lkml.org/lkml/2014/3/12/499 >> >> Resent v3: >> https://lkml.org/lkml/2014/4/4/523 >> >> Patches 1-7 should go through your tree. > > I've now applied these, sorry for the delay. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature
Re: [PATCHv4 7/7] ARM: dts: Add device tree sources for Exynos3250
On 04/25/2014 01:38 PM, Tushar Behera wrote: > On 04/25/2014 06:46 AM, Chanwoo Choi wrote: >> From: Tomasz Figa >> >> This patch add new exynos3250.dtsi to support Exynos3250 SoC based on >> Cortex-A7 >> dual core and includes following dt nodes: >> > > [ ... ] > >> --- >> arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 +++ >> arch/arm/boot/dts/exynos3250.dtsi | 405 + >> arch/arm/boot/dts/exynos4212-tizenw.dts | 926 >> ++ > > exynos4412-tizenw.dts related changes are unrelated. Right, It is may mistake. I'll resend this patch. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: exynos5: Initialise Samsung High Speed I2C controller early
On 04/24/2014 09:55 PM, Mark Brown wrote: > On Thu, Apr 24, 2014 at 08:18:36PM +0530, Naveen Krishna Chatradhi wrote: >> This patch moves initialization code to subsys_initcall() to ensure >> that the i2c bus is available early so the regulators can be quickly >> probed and available for other devices on their probe() call. > >> Such solution has been proposed by Mark Brown to fix the problem of >> the regulators not beeing available on the peripheral device probe(): >> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011971.html > > What specifically is this needed for? We *should* be able to use > deferred probe for most things, but I know that not all subsystems are > able to yet. > DRM-Exynos is one such sub-system right now that doesn't handle deferred probe well. That is one of the reasons for this patch. -- Tushar Behera -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/4] Migrate timers away from cpuset on setting cpuset.quiesce
On 25 April 2014 06:01, Daniel Sangorrin wrote: > >>> I can't keep it as a separate patch and so would be required to merge >>> it into my original patch.. >> >> And the reason being: "No patch is supposed to break things, otherwise >> git bisect wouldn't work smoothly".. And so git bisect would complain >> this issue after my patch and so I have to merge the fixes you gave into >> the original patch as its not yet merged. >> -- >> To unsubscribe from this list: send the line "unsubscribe cgroups" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > Ok, no problem then. Do you want me to add your Tested-by for my next version ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.15-rc2: longhaul cpufreq stalls tasks for 120s+
On 25 April 2014 00:33, Meelis Roos wrote: > [ 240.140176] INFO: task kworker/0:1:116 blocked for more than 120 seconds. > [ 240.140353] Not tainted 3.15.0-rc2-dirty #37 > [ 240.140485] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.140687] kworker/0:1 D cf6afd50 0 116 2 0x > [ 240.140938] Workqueue: events od_dbs_timer > [ 240.141103] cf6afd98 0082 0002 cf6afd50 c1040d91 cf6affec > cf6ad310 cf6ad310 > [ 240.142479] c1286dcb 0002 cf6afd70 c1040f14 ce460b30 > 0282 0046 > [ 240.143011] 0282 ce460b30 cf6afd78 c1040f39 cf6afd88 0282 > cf6afdb0 ce460b30 > [ 240.143544] Call Trace: > [ 240.143706] [] ? mark_held_locks+0x4b/0x61 > [ 240.143883] [] ? _raw_spin_unlock_irqrestore+0x33/0x3f > [ 240.144043] [] ? trace_hardirqs_on_caller+0x16d/0x187 > [ 240.144203] [] ? trace_hardirqs_on+0xb/0xd > [ 240.144358] [] schedule+0x5d/0x5f > [ 240.144527] [] cpufreq_freq_transition_begin+0x4a/0x9d > [ 240.144687] [] ? __wake_up_sync+0x14/0x14 > [ 240.144860] [] longhaul_setstate+0x88/0x2f1 [longhaul] > [ 240.145023] [] ? srcu_notifier_call_chain+0x1a/0x1c > [ 240.145186] [] ? cpufreq_freq_transition_begin+0x95/0x9d > [ 240.145350] [] longhaul_target+0x7c/0x8b [longhaul] > [ 240.145511] [] __cpufreq_driver_target+0xfe/0x148 Am I reading it correctly? It looks like we are starting another transition from notifier chain, but I couldn't figure out how from code. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv4 7/7] ARM: dts: Add device tree sources for Exynos3250
On 04/25/2014 06:46 AM, Chanwoo Choi wrote: > From: Tomasz Figa > > This patch add new exynos3250.dtsi to support Exynos3250 SoC based on > Cortex-A7 > dual core and includes following dt nodes: > [ ... ] > --- > arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 +++ > arch/arm/boot/dts/exynos3250.dtsi | 405 + > arch/arm/boot/dts/exynos4212-tizenw.dts | 926 > ++ exynos4412-tizenw.dts related changes are unrelated. -- Tushar Behera -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250
On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
> This patch fix the offset of CPU boot address and don't need to send smc call
> of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 removes
> WFE in secure mode.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> ---
> arch/arm/mach-exynos/firmware.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
> index aa01c42..386d01d 100644
> --- a/arch/arm/mach-exynos/firmware.c
> +++ b/arch/arm/mach-exynos/firmware.c
> @@ -31,11 +31,17 @@ static int exynos_do_idle(void)
> static int exynos_cpu_boot(int cpu)
> {
> /*
> + * Exynos3250 doesn't need to send smc command for secondary CPU boot
> + * because Exynos3250 removes WFE in secure mode.
> + */
> + if (soc_is_exynos3250())
> + return 0;
> + /*
>* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
>* But, Exynos4212 has only one secondary CPU so second parameter
>* isn't used for informing secure firmware about CPU id.
>*/
> - if (soc_is_exynos4212())
> + else if (soc_is_exynos4212())
This changes is not required.
> cpu = 0;
>
> exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
> @@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long
> boot_addr)
> {
> void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
>
> - if (!soc_is_exynos4212())
> + if (!soc_is_exynos4212() && !soc_is_exynos3250())
> boot_reg += 4*cpu;
>
> __raw_writel(boot_addr, boot_reg);
>
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/6] Clean up and unify the vDSO
On 04/24/2014 03:08 PM, Andy Lutomirski wrote: > This rewrites a bunch of the vdso code. After these patches, the vvar > and hpet pages are mapped directly after the vdso text on all five vdso > variants. The fixmaps are gone on 64-bit systems. > > It would be possible to build the x32 vdso the normal way on top of > these patches. > > I haven't touched the pvclock code. I'd want to understand why it > exists, why it isn't using rdtsc, and why it has two rdtsc_barrier calls > before rearranging it. In a discussion with Marcello Tosatti, I think > we concluded that the kvmclock code could be significantly simplified > and sped up without breaking anything, but I want to save that for > later. > > This should apply to -linus or to tip/x86/vdso. It's also here: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=vdso/cleanups > > and it has survived the build bot for a day. > This doesn't apply cleanly on top of v3.15-rc2. Could I ask you do rebase it again? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/6] Clean up and unify the vDSO
Nevermind, forget the last message... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] ASoC: SAMSUNG: Add sound card driver for Snow board
On 04/24/2014 07:09 PM, Mark Brown wrote:
> On Wed, Apr 23, 2014 at 02:31:45PM +0530, Tushar Behera wrote:
>
>> +Required properties:
>> +- compatible : Can be one of the following,
>> +"google,snow-audio-max98090" or
>> +"google,snow-audio-max98095"
>> +- samsung,i2s-controller: The phandle of the Samsung I2S0 controller
>
> This should be any I2S controller, not just I2S0?
>
Yes, right. It can be any I2S controller. Just that, right now it is
wired to I2S0.
>> +- samsung,audio-codec: The phandle of the audio codec
>
> This binding only has one I2S controller and CODEC. However...
>
>> +static struct snd_soc_dai_link snow_dai[] = {
>> +{ /* Playback DAI i/f */
>> +.name = "Playback",
>> +.stream_name = "Playback",
>> +.codec_dai_name = "HiFi",
>> +.dai_fmt = SND_SOC_DAIFMT_I2S |
>> +SND_SOC_DAIFMT_NB_NF |
>> +SND_SOC_DAIFMT_CBS_CFS,
>> +}, { /* Capture DAI i/f */
>> +.name = "Capture",
>> +.stream_name = "Capture",
>> +.codec_dai_name = "HiFi",
>> +.dai_fmt = SND_SOC_DAIFMT_I2S |
>> +SND_SOC_DAIFMT_NB_NF |
>> +SND_SOC_DAIFMT_CBS_CFS,
>> +},
>> +};
>
> ...for some reason we have separate capture and playback DAI links
That was lack of understanding from my side. I was of the impression
that the back-end uses different DAI interfaces for aplay and arecord,
which certainly is not the case. I will remove the 'Capture' dai and
make 'Playback' dai as the primary DAI.
> defined. Why is that? Also, why is the secondary I2S playback stream
> not supported (this may be a reason to restrict to only the one I2S
> interface)?
AFAICS, I2S driver doesn't support secondary DAI with DT (dai type is
always TYPE_PRI in case of DT). Hence I could not find a setup to test
secondary dai with this board.
>
> Please also use subject lines consistent with the subsystem - NO NEED TO
> SHOUT.
>
Noted, will take care.
Thanks.
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] swap: change swap_info singly-linked list to list_head
On Fri, Apr 25, 2014 at 2:48 AM, Dan Streetman wrote:
> On Wed, Apr 23, 2014 at 6:34 AM, Mel Gorman wrote:
>> On Sat, Apr 12, 2014 at 05:00:53PM -0400, Dan Streetman wrote:
>>> Replace the singly-linked list tracking active, i.e. swapon'ed,
>>> swap_info_struct entries with a doubly-linked list using struct list_heads.
>>> Simplify the logic iterating and manipulating the list of entries,
>>> especially get_swap_page(), by using standard list_head functions,
>>> and removing the highest priority iteration logic.
>>>
>>> The change fixes the bug:
>>> https://lkml.org/lkml/2014/2/13/181
>>> in which different priority swap entries after the highest priority entry
>>> are incorrectly used equally in pairs. The swap behavior is now as
>>> advertised, i.e. different priority swap entries are used in order, and
>>> equal priority swap targets are used concurrently.
>>>
>>> Signed-off-by: Dan Streetman
>>> ---
>>> include/linux/swap.h | 7 +--
>>> include/linux/swapfile.h | 2 +-
>>> mm/frontswap.c | 13 ++--
>>> mm/swapfile.c| 156
>>> +--
>>> 4 files changed, 63 insertions(+), 115 deletions(-)
>>>
>>> diff --git a/include/linux/swap.h b/include/linux/swap.h
>>> index 3507115..96662d8 100644
>>> --- a/include/linux/swap.h
>>> +++ b/include/linux/swap.h
>>> @@ -214,8 +214,8 @@ struct percpu_cluster {
>>> struct swap_info_struct {
>>> unsigned long flags; /* SWP_USED etc: see above */
>>> signed shortprio; /* swap priority of this type */
>>> + struct list_head list; /* entry in swap list */
>>> signed char type; /* strange name for an index */
>>> - signed char next; /* next type on the swap list */
>>> unsigned intmax;/* extent of the swap_map */
>>> unsigned char *swap_map;/* vmalloc'ed array of usage counts */
>>> struct swap_cluster_info *cluster_info; /* cluster info. Only for SSD
>>> */
>>> @@ -255,11 +255,6 @@ struct swap_info_struct {
>>> struct swap_cluster_info discard_cluster_tail; /* list tail of
>>> discard clusters */
>>> };
>>>
>>> -struct swap_list_t {
>>> - int head; /* head of priority-ordered swapfile list */
>>> - int next; /* swapfile to be used next */
>>> -};
>>> -
>>> /* linux/mm/workingset.c */
>>> void *workingset_eviction(struct address_space *mapping, struct page
>>> *page);
>>> bool workingset_refault(void *shadow);
>>> diff --git a/include/linux/swapfile.h b/include/linux/swapfile.h
>>> index e282624..2eab382 100644
>>> --- a/include/linux/swapfile.h
>>> +++ b/include/linux/swapfile.h
>>> @@ -6,7 +6,7 @@
>>> * want to expose them to the dozens of source files that include swap.h
>>> */
>>> extern spinlock_t swap_lock;
>>> -extern struct swap_list_t swap_list;
>>> +extern struct list_head swap_list_head;
>>> extern struct swap_info_struct *swap_info[];
>>> extern int try_to_unuse(unsigned int, bool, unsigned long);
>>>
>>> diff --git a/mm/frontswap.c b/mm/frontswap.c
>>> index 1b24bdc..fae1160 100644
>>> --- a/mm/frontswap.c
>>> +++ b/mm/frontswap.c
>>> @@ -327,15 +327,12 @@ EXPORT_SYMBOL(__frontswap_invalidate_area);
>>>
>>> static unsigned long __frontswap_curr_pages(void)
>>> {
>>> - int type;
>>> unsigned long totalpages = 0;
>>> struct swap_info_struct *si = NULL;
>>>
>>> assert_spin_locked(_lock);
>>> - for (type = swap_list.head; type >= 0; type = si->next) {
>>> - si = swap_info[type];
>>> + list_for_each_entry(si, _list_head, list)
>>> totalpages += atomic_read(>frontswap_pages);
>>> - }
>>> return totalpages;
>>> }
>>>
>>> @@ -347,11 +344,9 @@ static int __frontswap_unuse_pages(unsigned long
>>> total, unsigned long *unused,
>>> int si_frontswap_pages;
>>> unsigned long total_pages_to_unuse = total;
>>> unsigned long pages = 0, pages_to_unuse = 0;
>>> - int type;
>>>
>>> assert_spin_locked(_lock);
>>> - for (type = swap_list.head; type >= 0; type = si->next) {
>>> - si = swap_info[type];
>>> + list_for_each_entry(si, _list_head, list) {
>>> si_frontswap_pages = atomic_read(>frontswap_pages);
>>> if (total_pages_to_unuse < si_frontswap_pages) {
>>> pages = pages_to_unuse = total_pages_to_unuse;
>>
>> The frontswap shrink code looks suspicious. If the target is smaller than
>> the total number of frontswap pages then it does nothing. The callers
>> appear to get this right at least. Similarly, if the first swapfile has
>> fewer frontswap pages than the target then it does not unuse the target
>> number of pages because it only handles one swap file. It's outside the
>> scope of your patch to address this or wonder if xen balloon driver is
>> really using it the way it's expected.
>
> I didn't look into the frontswap shrinking code, but I agree the
> existing logic
Re: [PATCH 1/5] qlge: Convert /n to \n
On 4/24/14 6:50 PM, "Joe Perches" wrote: >Use a newline character appropriately. > >Signed-off-by: Joe Perches >--- > drivers/net/ethernet/qlogic/qlge/qlge_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_main.c >b/drivers/net/ethernet/qlogic/qlge/qlge_main.c >index 0a1d76a..6e36fe1 100644 >--- a/drivers/net/ethernet/qlogic/qlge/qlge_main.c >+++ b/drivers/net/ethernet/qlogic/qlge/qlge_main.c >@@ -3595,7 +3595,7 @@ static int ql_request_irq(struct ql_adapter *qdev) > } > return status; > err_irq: >- netif_err(qdev, ifup, qdev->ndev, "Failed to get the interrupts!!!/n"); >+ netif_err(qdev, ifup, qdev->ndev, "Failed to get the interrupts!!!\n"); > ql_free_irq(qdev); > return status; > } >-- >1.8.1.2.459.gbcd45b4.dirty Acked-by: Jitendra Kalsaria -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Staging: comedi: drivers: fixed a coding style issue.
>From 38e0d5778bd97062115e7d8a8ca40d18f3d71707 Mon Sep 17 00:00:00 2001
From: Nicolas Del Piano
Date: Thu, 24 Apr 2014 18:46:49 -0300
Subject: [PATCH] Staging: comedi: drivers: fixed a missing blank line after a
declaration coding style.
Fixed a coding style issue.
Signed-off-by: Nicolas Del Piano
---
drivers/staging/comedi/drivers.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/comedi/drivers.c b/drivers/staging/comedi/drivers.c
index cb5d214..71569bc 100644
--- a/drivers/staging/comedi/drivers.c
+++ b/drivers/staging/comedi/drivers.c
@@ -439,6 +439,7 @@ static void *comedi_recognize(struct comedi_driver *driv, const char *name)
static void comedi_report_boards(struct comedi_driver *driv)
{
unsigned int i;
+
const char *const *name_ptr;
pr_info("comedi: valid board names for %s driver are:\n",
--
1.7.9.5
Re: dropping capabilities in user namespace
Aditya Kali writes:
> On Wed, Apr 23, 2014 at 2:17 AM, Eric W. Biederman
> wrote:
>> Aditya Kali writes:
>>
>>> Hi all,
>>>
>>> I am trying to understand the behavior of how we can drop capabilities
>>> inside user namespace. i.e., I want to start a process inside user
>>> namespace with its effective and permitted capability sets cleared.
>>
>> Please note to start with that at the point you are in a user namespace
>> all of your capabilities are relative to that user namespace.
>>
>> Now I have not had any problem dropping capabilities in a user namespace
>> so you are doing something weird. Let me see if I can see what that
>> weird thing is.
>>
>>> A typical way in which a root (uid=0) process can drop its privileges is:
>>>
>>> prctl(PR_SET_KEEPCAPS, 0, 0, 0, 0);
>>
>> You clear this bit in securebits that should already be clear anyay.
>>
>>> setresuid(uid, uid, uid); // At this point, permitted and effective
>>> capabilities are cleared
>>> exec()
>>>
>>> But this sequence of operation inside a user namespace does not work
>>> as expected:
>>
>>
>> As I look at this it seems to work as designed. By not starting with
>> uid 0 you are triggered the non-zero uid with caps section of the code
>> that has always behaved differently.
>>
>>> Assume /proc/pid/uid_map has entry: uid uid 1
>>>
>>> attach_user_ns(pid); // OR create_user_ns() & write_uid_map()
>>> prctl(PR_SET_KEEPCAPS, 0, 0, 0, 0);
>>> setresuid(uid, uid, uid); // Fails to reset capabilities
>>> exec()
>>>
>>> The exec()ed process starts with correct uid set, but still with all
>>> the capabilities.
>>>
>>> The differentiating factor here seems to be the 'root_uid' value in
>>> security/commoncap.c:cap_emulate_setxuid():
>>>
>>> static inline void cap_emulate_setxuid(struct cred *new, const struct cred
>>> *old)
>>> {
>>> kuid_t root_uid = make_kuid(old->user_ns, 0);
>>>
>>> if ((uid_eq(old->uid, root_uid) ||
>>> uid_eq(old->euid, root_uid) ||
>>> uid_eq(old->suid, root_uid)) &&
>>> (!uid_eq(new->uid, root_uid) &&
>>> !uid_eq(new->euid, root_uid) &&
>>> !uid_eq(new->suid, root_uid)) &&
>>> !issecure(SECURE_KEEP_CAPS)) {
>>> cap_clear(new->cap_permitted);
>>> cap_clear(new->cap_effective);
>>> }
>>> ...
>>>
>>> There are couple of problems here:
>>> (1) In above example when there is no mapping for uid 0 inside
>>> old->user_ns, make_kuid() returns INVALID_UID. Since we go on to
>>> compare root_uid without first checking if its even valid, we never
>>> satisfy the 'if' condition and never clear the caps. This looks like a
>>> bug.
>>
>> INVALID_UID will never be in a capability set, so the comparison is
>> guaranteed against root_uid is guaranteed to fail if there is not a root
>> uid. That is correct.
>>
>
> So this does seem like a regression in userns w.r.t.
> global/init-user-ns. (See below for correct example when the behavior
> is different).
It is outside of the conditions that can exist without user namespaces
so it can not possibly be a regression.
It may be a violation of expectations, but I am not certain it is wrong.
Most of the way capabilities work when you don't trigger their backwards
compatible behavior violates expectations.
>>> (2) Even if there is some mapping for uid 0 inside old->user_ns (say
>>> "0 1"), since old->uid = 0, and root_uid= (or some non-zero
>>> uid), the 'if' condition again remains unsatisfied.
>>
>> Correct. Because this code is not supposed to do something if you have
>> caps and your uid is not zero.
>>
>>> It looks like currently the only case where global root (uid=0)
>>> process can drop its capabilities inside a user namespace is by having
>>> "0 0 " mapping in the uid_map file. It seems wrong to expose
>>> global root in user namespace just to drop privileges!
>>
>> Where does global root come into this? Nothing above is global root
>> specific? Or do you just mean you are starting all of this as the
>> global root user?
>>
>
> I am starting my program as global root user, yes. The program
> attaches to given user namespaces, sets uid to given uid and does some
> work (which it expects to do as user without any capabilities).
>
> I made a mistake in my example above. If I exec() at the end, the
> capabilities do get cleared as you suggest. The problematic case is:
>
> attach_to_userns(pid)
> prctl(PR_SET_KEEPCAPS, 0, 0, 0, 0);
> setresuid(uid, uid, uid); // Fails to reset capabilities
> pause() / sleep(...) / do_some_work_as_uid() [[ no exec, sorry ]]
>
> And I was looking at the Cap* fields in /proc//status
> from another terminal. I noticed that the capabilities were not reset
> after the setresuid() call. This behavior is different as compared to
> what happens in init_user_ns.
Yes this behavior is different as compared to what happens without user
namespaces involved, and I grant it is a bit surprising.
>>> So I feel we
>>> need to fix the condition checks everywhere we are using make_kuid()
>>> in
Re: [PATCH RESEND] zram: correct offset usage in zram_bio_discard
On Thu, Apr 24, 2014 at 3:31 PM, Sergey Senozhatsky
wrote:
> Hello Minchan,
>
> On (04/24/14 11:06), Minchan Kim wrote:
>> Hello,
>>
>> On Wed, Apr 23, 2014 at 04:41:15PM +0800, Weijie Yang wrote:
>> > We want to skip the physical block(PAGE_SIZE) which is partially
>> > covered by the discard bio, so we check the remaining size and
>> > subtract it if there is a need to goto the next physical block.
>> >
>> > The current offset usage in zram_bio_discard is incorrect, it will
>> > cause its upper filesystem breakdown.
>> > Consider the following scenario:
>> > on some architecture or config, PAGE_SIZE is 64K for example,
>> > filesystem is set up on zram disk without PAGE_SIZE aligned,
>> > a discard bio leads to a offset = 4K and size=72K,
>> > normally, it should not really discard any physical block as it
>> > partially cover two physical blocks.
>> > However, with the current offset usage, it will discard the second
>> > physical block and free its memory, which will cause filesystem breakdown.
>> >
>> > This patch corrects the offset usage in zram_bio_discard.
>>
>> Nice catch.
>> Surely we need fix but I'd like to go further. Let's think.
>> How do you find that? Real problem or code review?
>> I'd like to know how much that happens in real practice because if it's
>> a lot, it means discard support is just an overhead without any benefit.
>>
>> If you just found it with code review(ie, don't have any data),
>> would you mind adding some stat like 'num_discard/failed_discard' so
>> we can keep an eye on that. Although it's for rare case, I think it's worth.
>> Because someone would do swapon zram with --discard,
>> it could make same problem due to early page freeing of zram-swap to
>> avoid duplicating VM-owned memory and ZRAM-owned memory.
>>
>> We can guide to zram-swap user not to use swapon with --discard but
>> I don't want it because swap_slot_free_notify is really mess which
>> violates layering so I hope replace it with discard finally so such
>> statistics really help us to drive that way more quickly.
>>
Actually, I found this issue by code review not real practice.
I agree with you that it is worthy of adding some stat on discard behavior,
I will send a patch about it.
As to zram-swap, I think we could drop swap_slot_free_notify by using discard,
there is no technical issue as swap_extent is aligned to PAGE_SIZE and we
discard swap_cluster at a time.
However, what I worry about is that we can not force end-user to use --discard,
if someone forget it(we can not expect every end-user understand the
kernel mechanism),
he will not get the benefit of zram-swap and be confused.
So, is there any possibility that kernel do it transparently? May be
we need modify
the swap subsystem to surpport different hierarchical swapfiles.
Thanks for your advice, I really admire your further thinking.
>
> I second this. if we could drop swap_slot_free_notify that'd be nice.
>
> -ss
>
>> >
>> > Signed-off-by: Weijie Yang
>> > Acked-by: Joonsoo Kim
>> > ---
>> > drivers/block/zram/zram_drv.c |4 ++--
>> > 1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
>> > index 9849b52..48eccb3 100644
>> > --- a/drivers/block/zram/zram_drv.c
>> > +++ b/drivers/block/zram/zram_drv.c
>> > @@ -572,10 +572,10 @@ static void zram_bio_discard(struct zram *zram, u32
>> > index,
>> > * skipping this logical block is appropriate here.
>> > */
>> > if (offset) {
>> > - if (n < offset)
>> > + if (n <= (PAGE_SIZE - offset))
>> > return;
>> >
>> > - n -= offset;
>> > + n -= (PAGE_SIZE - offset);
>> > index++;
>> > }
>> >
>> > --
>> > 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/
>>
>> --
>> 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/
[RFC] A new CPU load metric for power-efficient scheduler: CPU ConCurrency
Hi Ingo, PeterZ, and others, The current scheduler’s load balancing is completely work-conserving. In some workload, generally low CPU utilization but immersed with CPU bursts of transient tasks, migrating task to engage all available CPUs for work-conserving can lead to significant overhead: cache locality loss, idle/active HW state transitional latency and power, shallower idle state, etc, which are both power and performance inefficient especially for today’s low power processors in mobile. This RFC introduces a sense of idleness-conserving into work-conserving (by all means, we really don’t want to be overwhelming in only one way). But to what extent the idleness-conserving should be, bearing in mind that we don’t want to sacrifice performance? We first need a load/idleness indicator to that end. Thanks to CFS’s “model an ideal, precise multi-tasking CPU”, tasks can be seen as concurrently running (the tasks in the runqueue). So it is natural to use task concurrency as load indicator. Having said that, we do two things: 1) Divide continuous time into periods of time, and average task concurrency in period, for tolerating the transient bursts: a = sum(concurrency * time) / period 2) Exponentially decay past periods, and synthesize them all, for hysteresis to load drops or resilience to load rises (let f be decaying factor, and a_x the xth period average since period 0): s = a_n + f^1 * a_n-1 + f^2 * a_n-2 +, …..,+ f^(n-1) * a_1 + f^n * a_0 We name this load indicator as CPU ConCurrency (CC): task concurrency determines how many CPUs are needed to be running concurrently. To track CC, we intercept the scheduler in 1) enqueue, 2) dequeue, 3) scheduler tick, and 4) enter/exit idle. By CC, we implemented a Workload Consolidation patch on two Intel mobile platforms (a quad-core composed of two dual-core modules): contain load and load balancing in the first dual-core when aggregated CC low, and if not in the full quad-core. Results show that we got power savings and no substantial performance regression (even gains for some). Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched, fair: Stop searching for tasks in newidle balance if there are runnable tasks
On Fri, 2014-04-25 at 04:45 +0200, Mike Galbraith wrote: > On Thu, 2014-04-24 at 18:52 +0200, Peter Zijlstra wrote: > > On Thu, Apr 24, 2014 at 09:43:09AM -0700, Jason Low wrote: > > > If the below patch is what you were referring to, I believe this > > > can help too. This was also something that I was testing out before > > > we went with those patches which compares avg_idle with idle balance > > > cost. I recall seeing somewhere around a +7% performance improvement > > > in at least least 1 of the AIM7 workloads. I can do some more testing > > > with this. > > > > Yes, exactly that. > > > > I can't remember the details, but I suspect we feared the less agressive > > idle balance due to that patch (it will only pull a single task, instead > > of multiple) would cause more idle_balance invocations and thereby > > decrease throughput. > > > > So I suppose something with _many_ bursty threads which leads to severe > > inequalities would be the workload to trigger that. > > > > Not sure we've ever seen that.. maybe Mike remembers, he seems to have a > > head for such details. > > I don't recall ever seeing such. Hmmm, could commit: 1b9508f6831e (sched: Rate-limit newidle) be related to what Peter's referring to? The patch mentioned that the rate-limit benefited "sysbench oltp". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: fs: dcookie: freeing active timer
On 04/24/2014 07:49 PM, Al Viro wrote: > On Thu, Apr 24, 2014 at 10:55:58PM +0100, Al Viro wrote: >> On Thu, Apr 24, 2014 at 01:34:14PM -0400, Sasha Levin wrote: >> Why does that code bother with destroying/creating that sucker dynamically? Is there any point at all? >>> >>> I'm not sure about the dynamic allocation part, but I fear that if we just >>> switch to using static allocations it'll hide the underlying issue that >>> triggered this bug instead of fixing it. >> >> FWIW, slub.c variant of kmem_cache_destroy() is buggered - struct kobject >> embedded into struct kmem_cache, its ktype is slab_ktype, which has >> NULL ->release()... > > BTW, if your config has CONFIG_DEBUG_KOBJECT_RELEASE, that's exactly where > that warning comes from. Got broken by commit b7454a, > Author: Glauber Costa > Date: Fri Oct 19 18:20:25 2012 +0400 > > mm/sl[au]b: Move slabinfo processing to slab_common.c > > We *do* need ->release(). Greg and guilty parties Cc'd... We actually had that conversation a long time ago, and Christoph has sent out a patch to fix that (http://www.spinics.net/lists/netdev/msg259431.html). I was assuming that it was merged upstream and went straight to blaming fs/ (and Greg's drivers/usb/ actually) without checking that first. Sorry! Could someone pretty please merge that patch? Specially since Greg acked it? Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] perf tests: Add a test case for hists filtering
Now we have changed how hists stats are accounted especially when
filter(s) applied. So add a test case to verify it.
Signed-off-by: Namhyung Kim
---
tools/perf/Makefile.perf| 1 +
tools/perf/tests/builtin-test.c | 4 +
tools/perf/tests/hists_filter.c | 315
tools/perf/tests/tests.h| 1 +
4 files changed, 321 insertions(+)
create mode 100644 tools/perf/tests/hists_filter.c
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 1490afeb7252..68e4d011d407 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -398,6 +398,7 @@ LIB_OBJS += $(OUTPUT)tests/evsel-tp-sched.o
LIB_OBJS += $(OUTPUT)tests/pmu.o
LIB_OBJS += $(OUTPUT)tests/hists_common.o
LIB_OBJS += $(OUTPUT)tests/hists_link.o
+LIB_OBJS += $(OUTPUT)tests/hists_filter.o
LIB_OBJS += $(OUTPUT)tests/python-use.o
LIB_OBJS += $(OUTPUT)tests/bp_signal.o
LIB_OBJS += $(OUTPUT)tests/bp_signal_overflow.o
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index b11bf8a08430..ceb9daebc389 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -124,6 +124,10 @@ static struct test {
#endif
#endif
{
+ .desc = "Test filtering hist entries",
+ .func = test__hists_filter,
+ },
+ {
.func = NULL,
},
};
diff --git a/tools/perf/tests/hists_filter.c b/tools/perf/tests/hists_filter.c
new file mode 100644
index ..23dc2f4d12c3
--- /dev/null
+++ b/tools/perf/tests/hists_filter.c
@@ -0,0 +1,315 @@
+#include "perf.h"
+#include "util/debug.h"
+#include "util/symbol.h"
+#include "util/sort.h"
+#include "util/evsel.h"
+#include "util/evlist.h"
+#include "util/machine.h"
+#include "util/thread.h"
+#include "util/parse-events.h"
+#include "tests/tests.h"
+#include "tests/hists_common.h"
+
+struct sample {
+ u32 pid;
+ u64 ip;
+ struct thread *thread;
+ struct map *map;
+ struct symbol *sym;
+};
+
+/* For the numbers, see hists_common.c */
+static struct sample fake_samples[] = {
+ /* perf [kernel] schedule() */
+ { .pid = 100, .ip = 0xf + 700, },
+ /* perf [perf] main() */
+ { .pid = 100, .ip = 0x4 + 700, },
+ /* perf [libc] malloc() */
+ { .pid = 100, .ip = 0x5 + 700, },
+ /* perf [perf] main() */
+ { .pid = 200, .ip = 0x4 + 700, }, /* will be merged */
+ /* perf [perf] cmd_record() */
+ { .pid = 200, .ip = 0x4 + 900, },
+ /* perf [kernel] page_fault() */
+ { .pid = 200, .ip = 0xf + 800, },
+ /* bash [bash] main() */
+ { .pid = 300, .ip = 0x4 + 700, },
+ /* bash [bash] xmalloc() */
+ { .pid = 300, .ip = 0x4 + 800, },
+ /* bash [libc] malloc() */
+ { .pid = 300, .ip = 0x5 + 700, },
+ /* bash [kernel] page_fault() */
+ { .pid = 300, .ip = 0xf + 800, },
+};
+
+static int add_hist_entries(struct perf_evlist *evlist, struct machine
*machine)
+{
+ struct perf_evsel *evsel;
+ struct addr_location al;
+ struct hist_entry *he;
+ struct perf_sample sample = { .cpu = 0, };
+ size_t i;
+
+ /*
+* each evsel will have 10 samples but the 4th sample
+* (perf [perf] main) will be collapsed to an existing entry
+* so total 9 entries will be in the tree.
+*/
+ evlist__for_each(evlist, evsel) {
+ for (i = 0; i < ARRAY_SIZE(fake_samples); i++) {
+ const union perf_event event = {
+ .header = {
+ .misc = PERF_RECORD_MISC_USER,
+ },
+ };
+
+ /* make sure it has no filter at first */
+ evsel->hists.thread_filter = NULL;
+ evsel->hists.dso_filter = NULL;
+ evsel->hists.symbol_filter_str = NULL;
+
+ sample.pid = fake_samples[i].pid;
+ sample.ip = fake_samples[i].ip;
+
+ if (perf_event__preprocess_sample(, machine, ,
+ ) < 0)
+ goto out;
+
+ he = __hists__add_entry(>hists, , NULL,
+ NULL, NULL, 100, 1, 0);
+ if (he == NULL)
+ goto out;
+
+ fake_samples[i].thread = al.thread;
+ fake_samples[i].map = al.map;
+ fake_samples[i].sym = al.sym;
+
+ hists__inc_nr_events(he->hists, PERF_RECORD_SAMPLE);
+ if (!he->filtered)
+ he->hists->stats.nr_non_filtered_samples++;
+ }
+ }
+
+ return 0;
+
+out:
+ pr_debug("Not enough
[PATCH 1/2] perf tests: Factor out fake_setup_machine()
The fake_setup_machine() is for setting up a environment for testing
various hists operations. As it'll be used for other test cases it'd
better factoring it out.
Signed-off-by: Namhyung Kim
---
tools/perf/Makefile.perf| 1 +
tools/perf/tests/hists_common.c | 148
tools/perf/tests/hists_common.h | 44
tools/perf/tests/hists_link.c | 141 +-
4 files changed, 195 insertions(+), 139 deletions(-)
create mode 100644 tools/perf/tests/hists_common.c
create mode 100644 tools/perf/tests/hists_common.h
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index eb57e2cf1b4c..1490afeb7252 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -396,6 +396,7 @@ LIB_OBJS += $(OUTPUT)tests/rdpmc.o
LIB_OBJS += $(OUTPUT)tests/evsel-roundtrip-name.o
LIB_OBJS += $(OUTPUT)tests/evsel-tp-sched.o
LIB_OBJS += $(OUTPUT)tests/pmu.o
+LIB_OBJS += $(OUTPUT)tests/hists_common.o
LIB_OBJS += $(OUTPUT)tests/hists_link.o
LIB_OBJS += $(OUTPUT)tests/python-use.o
LIB_OBJS += $(OUTPUT)tests/bp_signal.o
diff --git a/tools/perf/tests/hists_common.c b/tools/perf/tests/hists_common.c
new file mode 100644
index ..44655b395bb9
--- /dev/null
+++ b/tools/perf/tests/hists_common.c
@@ -0,0 +1,148 @@
+#include "perf.h"
+#include "util/debug.h"
+#include "util/symbol.h"
+#include "util/sort.h"
+#include "util/evsel.h"
+#include "util/evlist.h"
+#include "util/machine.h"
+#include "util/thread.h"
+#include "tests/hists_common.h"
+
+static struct {
+ u32 pid;
+ const char *comm;
+} fake_threads[] = {
+ { 100, "perf" },
+ { 200, "perf" },
+ { 300, "bash" },
+};
+
+static struct {
+ u32 pid;
+ u64 start;
+ const char *filename;
+} fake_mmap_info[] = {
+ { 100, 0x4, "perf" },
+ { 100, 0x5, "libc" },
+ { 100, 0xf, "[kernel]" },
+ { 200, 0x4, "perf" },
+ { 200, 0x5, "libc" },
+ { 200, 0xf, "[kernel]" },
+ { 300, 0x4, "bash" },
+ { 300, 0x5, "libc" },
+ { 300, 0xf, "[kernel]" },
+};
+
+struct fake_sym {
+ u64 start;
+ u64 length;
+ const char *name;
+};
+
+static struct fake_sym perf_syms[] = {
+ { 700, 100, "main" },
+ { 800, 100, "run_command" },
+ { 900, 100, "cmd_record" },
+};
+
+static struct fake_sym bash_syms[] = {
+ { 700, 100, "main" },
+ { 800, 100, "xmalloc" },
+ { 900, 100, "xfree" },
+};
+
+static struct fake_sym libc_syms[] = {
+ { 700, 100, "malloc" },
+ { 800, 100, "free" },
+ { 900, 100, "realloc" },
+};
+
+static struct fake_sym kernel_syms[] = {
+ { 700, 100, "schedule" },
+ { 800, 100, "page_fault" },
+ { 900, 100, "sys_perf_event_open" },
+};
+
+static struct {
+ const char *dso_name;
+ struct fake_sym *syms;
+ size_t nr_syms;
+} fake_symbols[] = {
+ { "perf", perf_syms, ARRAY_SIZE(perf_syms) },
+ { "bash", bash_syms, ARRAY_SIZE(bash_syms) },
+ { "libc", libc_syms, ARRAY_SIZE(libc_syms) },
+ { "[kernel]", kernel_syms, ARRAY_SIZE(kernel_syms) },
+};
+
+struct machine *setup_fake_machine(struct machines *machines)
+{
+ struct machine *machine = machines__find(machines, HOST_KERNEL_ID);
+ size_t i;
+
+ if (machine == NULL) {
+ pr_debug("Not enough memory for machine setup\n");
+ return NULL;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(fake_threads); i++) {
+ struct thread *thread;
+
+ thread = machine__findnew_thread(machine, fake_threads[i].pid,
+fake_threads[i].pid);
+ if (thread == NULL)
+ goto out;
+
+ thread__set_comm(thread, fake_threads[i].comm, 0);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(fake_mmap_info); i++) {
+ union perf_event fake_mmap_event = {
+ .mmap = {
+ .header = { .misc = PERF_RECORD_MISC_USER, },
+ .pid = fake_mmap_info[i].pid,
+ .tid = fake_mmap_info[i].pid,
+ .start = fake_mmap_info[i].start,
+ .len = 0x1000ULL,
+ .pgoff = 0ULL,
+ },
+ };
+
+ strcpy(fake_mmap_event.mmap.filename,
+ fake_mmap_info[i].filename);
+
+ machine__process_mmap_event(machine, _mmap_event, NULL);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(fake_symbols); i++) {
+ size_t k;
+ struct dso *dso;
+
+ dso = __dsos__findnew(>user_dsos,
+ fake_symbols[i].dso_name);
+ if (dso == NULL)
+ goto out;
+
+ /* emulate dso__load() */
+
Re: Re: [PATCH] uprobes/x86: Refuse to attach uprobe to "word-sized" branch insns
(2014/04/25 2:33), Oleg Nesterov wrote:
> Thanks!
>
> Masami, Jim, any acks?
>
> On 04/24, Denys Vlasenko wrote:
>>
>> All branch insns on x86 can be prefixed with the operand-size
>> override prefix, 0x66. It was only ever useful for performing
>> jumps to 32-bit offsets in 16-bit code segments.
>>
>> In 32-bit code, such instructions are useless since
>> they cause IP truncation to 16 bits, and in case of call insns,
>> they save only 16 bits of return address and misalign
>> the stack pointer as a "bonus".
>>
>> In 64-bit code, such instructions are treated differently by Intel
>> and AMD CPUs: Intel ignores the prefix altogether,
>> AMD treats them the same as in 32-bit mode.
>>
>> Before this patch, the emulation code would execute
>> the instructions as if they have no 0x66 prefix.
>>
>> With this patch, we refuse to attach uprobes to such insns.
>>
>> Signed-off-by: Denys Vlasenko
>> Cc: Oleg Nesterov
Acked-by: Masami Hiramatsu
Thank you :)
>> ---
>> arch/x86/kernel/uprobes.c | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
>> index ace2291..29b152d 100644
>> --- a/arch/x86/kernel/uprobes.c
>> +++ b/arch/x86/kernel/uprobes.c
>> @@ -582,6 +582,7 @@ static struct uprobe_xol_ops branch_xol_ops = {
>> /* Returns -ENOSYS if branch_xol_ops doesn't handle this insn */
>> static int branch_setup_xol_ops(struct arch_uprobe *auprobe, struct insn
>> *insn)
>> {
>> +int i;
>> u8 opc1 = OPCODE1(insn);
>>
>> /* has the side-effect of processing the entire instruction */
>> @@ -612,6 +613,17 @@ static int branch_setup_xol_ops(struct arch_uprobe
>> *auprobe, struct insn *insn)
>> return -ENOSYS;
>> }
>>
>> +/*
>> + * 16-bit overrides such as CALLW (66 e8 nn nn) are not supported.
>> + * Intel and AMD behavior differ in 64-bit mode: Intel ignores 66
>> prefix.
>> + * No one uses these insns.
>> + * Reject any branch insns with such prefix.
>> + */
>> +for (i = 0; i < insn->prefixes.nbytes; i++) {
>> +if (insn->prefixes.bytes[i] == 0x66)
>> +return -ENOTSUPP;
>> +}
>> +
>> auprobe->branch.opc1 = opc1;
>> auprobe->branch.ilen = insn->length;
>> auprobe->branch.offs = insn->immediate.value;
>> --
>> 1.8.1.4
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research 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/
[PATCHv2 2/2] arm64: topology: add MPIDR-based detection
Create cpu topology based on MPIDR. When hardware sets MPIDR to sane
values, this method will always work. Therefore it should also work well
as the fallback method. [1]
When we have multiple processing elements in the system, we create
the cpu topology by mapping each affinity level (from lowest to highest)
to threads (if they exist), cores, and clusters.
We combine data from all higher affinity levels into cluster_id
so we don't lose any information from MPIDR. [2]
[1] http://www.spinics.net/lists/arm-kernel/msg317445.html
[2] https://lkml.org/lkml/2014/4/23/703
Signed-off-by: Zi Shen Lim
---
v1->v2: Addressed comments from Mark Brown.
- Reduce noise. Use pr_debug instead of pr_info.
- Don't ignore higher affinity levels.
arch/arm64/include/asm/cputype.h | 2 ++
arch/arm64/kernel/topology.c | 34 ++
2 files changed, 36 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index c404fb0..7639e8b 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -18,6 +18,8 @@
#define INVALID_HWID ULONG_MAX
+#define MPIDR_UP_BITMASK (0x1 << 30)
+#define MPIDR_MT_BITMASK (0x1 << 24)
#define MPIDR_HWID_BITMASK 0xff00ff
#define MPIDR_LEVEL_BITS_SHIFT 3
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 3e06b0b..7dbf981 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -19,6 +19,8 @@
#include
#include
+#include
+#include
#include
/*
@@ -71,6 +73,38 @@ static void update_siblings_masks(unsigned int cpuid)
void store_cpu_topology(unsigned int cpuid)
{
+ struct cpu_topology *cpuid_topo = _topology[cpuid];
+ u64 mpidr;
+
+ mpidr = read_cpuid_mpidr();
+
+ /* Create cpu topology mapping based on MPIDR. */
+ if (mpidr & MPIDR_UP_BITMASK) {
+ /* Uniprocessor system */
+ cpuid_topo->thread_id = -1;
+ cpuid_topo->core_id= MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cpuid_topo->cluster_id = -1;
+ } else if (mpidr & MPIDR_MT_BITMASK) {
+ /* Multiprocessor system : Multi-threads per core */
+ cpuid_topo->thread_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cpuid_topo->core_id= MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ cpuid_topo->cluster_id =
+ MPIDR_AFFINITY_LEVEL(mpidr, 2) |
+ MPIDR_AFFINITY_LEVEL(mpidr, 3) <<
mpidr_hash.shift_aff[3];
+ } else {
+ /* Multiprocessor system : Single-thread per core */
+ cpuid_topo->thread_id = -1;
+ cpuid_topo->core_id= MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cpuid_topo->cluster_id =
+ MPIDR_AFFINITY_LEVEL(mpidr, 1) |
+ MPIDR_AFFINITY_LEVEL(mpidr, 2) <<
mpidr_hash.shift_aff[2] |
+ MPIDR_AFFINITY_LEVEL(mpidr, 3) <<
mpidr_hash.shift_aff[3];
+ }
+
+ pr_debug("CPU%u: cluster %d core %d thread %d mpidr %llx\n",
+cpuid, cpuid_topo->cluster_id, cpuid_topo->core_id,
+cpuid_topo->thread_id, mpidr);
+
update_siblings_masks(cpuid);
}
--
1.8.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 0/2] arm64 topology updates
In this updated series, I've added Mark Brown's review-by to PATCH 1/2. I've addressed Mark's comments for PATCH 2/2. In order not to lose any information from MPIDR bits, we map all higher affinity levels into "cluster". This approach is similar to how Mark is handling multi-level clusters in DT. Many thanks to Mark for review and comments! Link to initial posting of this series: https://lkml.org/lkml/2014/4/22/950 Zi Shen Lim (2): arm64, sched: Remove unused mc_capable() and smt_capable() arm64: topology: add MPIDR-based detection arch/arm64/include/asm/cputype.h | 2 ++ arch/arm64/include/asm/topology.h | 3 --- arch/arm64/kernel/topology.c | 34 ++ 3 files changed, 36 insertions(+), 3 deletions(-) -- 1.8.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 1/2] arm64, sched: Remove unused mc_capable() and smt_capable()
Remove unused and deprecated mc_capable() and smt_capable().
Both were added recently by f6e763b93a6c ("arm64: topology:
Implement basic CPU topology support"). Uses of both were removed
by 8e7fbcbc22c1 ("sched: Remove stale power aware scheduling
remnants and dysfunctional knobs").
Reviewed-by: Mark Brown
Signed-off-by: Zi Shen Lim
---
v1->v2: No changes.
- Added Mark's review-by.
arch/arm64/include/asm/topology.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/include/asm/topology.h
b/arch/arm64/include/asm/topology.h
index 0172e6d..7ebcd31 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -20,9 +20,6 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
#define topology_core_cpumask(cpu) (_topology[cpu].core_sibling)
#define topology_thread_cpumask(cpu) (_topology[cpu].thread_sibling)
-#define mc_capable() (cpu_topology[0].cluster_id != -1)
-#define smt_capable() (cpu_topology[0].thread_id != -1)
-
void init_cpu_topology(void);
void store_cpu_topology(unsigned int cpuid);
const struct cpumask *cpu_coregroup_mask(int cpu);
--
1.8.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4 0/3] usb: chipidea: msm: Clean and fix glue layer driver
> > On Thu, 2014-04-24 at 08:38 +0800, Peter Chen wrote: > > On Wed, Apr 23, 2014 at 03:28:01PM +0300, Ivan T. Ivanov wrote: > > > From: "Ivan T. Ivanov" > > > > > > This series intend to fix driver, which was broken for a while. > > > It is used to create peripheral role device, which in coordination > > > with phy-usb-msm driver could provide USB2.0 gadget support for > > > Qualcomm targets. > > > > > > Changes since version 3. > > > > > > - Fix typo in devicetree description file. > > > > > > Previews version can be found here: > > > > Since in your phy's patchset, you also access portsc which is in > > chipidea register region, it is not a standard way. > > In case, you will change something at chipidea driver in future when > > you re-work your next revision phy's patchset, I do not send this > > patchset to Greg right now. > > > > Did you see problems with _this_ particular patch set? There is no direct > dependency between PHY patches and these changes. > I have not seen problems for this patch set, if you make sure the current phy operation (eg, "phy_type) at chipidea core does not affect you, I am glad to accept this. Peter
[PATCH]staging:iio:ad2s1200 fix missing parenthesis in a for statment.
Signed-off-by: Jimmy Li
---
drivers/staging/iio/resolver/ad2s1200.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/iio/resolver/ad2s1200.c
b/drivers/staging/iio/resolver/ad2s1200.c
index e2b4820..017d2f8 100644
--- a/drivers/staging/iio/resolver/ad2s1200.c
+++ b/drivers/staging/iio/resolver/ad2s1200.c
@@ -107,7 +107,7 @@ static int ad2s1200_probe(struct spi_device *spi)
int pn, ret = 0;
unsigned short *pins = spi->dev.platform_data;
- for (pn = 0; pn < AD2S1200_PN; pn++)
+ for (pn = 0; pn < AD2S1200_PN; pn++) {
ret = devm_gpio_request_one(>dev, pins[pn], GPIOF_DIR_OUT,
DRV_NAME);
if (ret) {
@@ -115,6 +115,7 @@ static int ad2s1200_probe(struct spi_device *spi)
pins[pn]);
return ret;
}
+ }
indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
if (!indio_dev)
return -ENOMEM;
--
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 V3] Add support for flag status register on Micron chips.
On Fri, Apr 25, 2014 at 04:42:33AM +0200, Marek Vasut wrote:
> On Friday, April 25, 2014 at 03:34:36 AM, Huang Shijie wrote:
> > On Tue, Apr 22, 2014 at 09:03:16AM -0500, Graham Moore wrote:
> > > Some new Micron flash chips require reading the flag
> > > status register to determine when operations have completed.
> > >
> > > Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
> > > require reading the status register before reading the flag status
> > > register.
> > >
> > > This patch adds support for the flag status register in the n25q512ax3
> > > and n25q00 Micron QSPI flash chips.
> > >
> > > Signed-off-by: Graham Moore
> > > ---
> > > V3:
> > > Rebase to l2-mtd spinor branch.
> > > V2:
> > > Remove leading underscore in function names.
> > > Remove type cast in dev_err call and use the proper format
> > > specifier instead.
> > > ---
> > >
> > > drivers/mtd/spi-nor/spi-nor.c | 51
> > > + include/linux/mtd/spi-nor.h
> > > |4
> > > 2 files changed, 55 insertions(+)
> > >
> > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > b/drivers/mtd/spi-nor/spi-nor.c index d6f44d5..24b84d8 100644
> > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > @@ -48,6 +48,25 @@ static int read_sr(struct spi_nor *nor)
> > >
> > > }
> > >
> > > /*
> > >
> > > + * Read the flag status register, returning its value in the location
> > > + * Return the status register value.
> > > + * Returns negative if error occurred.
> > > + */
> > > +static int read_fsr(struct spi_nor *nor)
> > > +{
> > > + int ret;
> > > + u8 val;
> > > +
> > > + ret = nor->read_reg(nor, SPINOR_OP_RDFSR, , 1);
> > > + if (ret < 0) {
> > > + pr_err("error %d reading FSR\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + return val;
> > > +}
> > > +
> > > +/*
> > >
> > > * Read configuration register, returning its value in the
> > > * location. Return the configuration register value.
> > > * Returns negative if error occured.
> > >
> > > @@ -165,6 +184,32 @@ static int spi_nor_wait_till_ready(struct spi_nor
> > > *nor)
> > >
> > > return -ETIMEDOUT;
> > >
> > > }
> > >
> > > +static int spi_nor_wait_till_fsr_ready(struct spi_nor *nor)
> > > +{
> > > + unsigned long deadline;
> > > + int sr;
> > > + int fsr;
> > > +
> > > + deadline = jiffies + MAX_READY_WAIT_JIFFIES;
> > > +
> > > + do {
> > > + cond_resched();
> > > +
> > > + sr = read_sr(nor);
> > > + if (sr < 0)
> > > + break;
> > > + else if (!(sr & SR_WIP)) {
> > > + fsr = read_fsr(nor);
> > > + if (fsr < 0)
> > > + break;
> > > + if (fsr & FSR_READY)
> > > + return 0;
> > > + }
> > > + } while (!time_after_eq(jiffies, deadline));
> > > +
> > > + return -ETIMEDOUT;
> > > +}
> > > +
> > >
> > > /*
> > >
> > > * Service routine to read status register until ready, or timeout
> > > occurs. * Returns non-zero if error.
> > >
> > > @@ -402,6 +447,7 @@ struct flash_info {
> > >
> > > #define SECT_4K_PMC 0x10/* SPINOR_OP_BE_4K_PMC works
> uniformly */
> > > #define SPI_NOR_DUAL_READ 0x20/* Flash supports Dual Read */
> > > #define SPI_NOR_QUAD_READ 0x40/* Flash supports Quad Read */
> > >
> > > +#define USE_FSR 0x80/* use flag status register */
> > >
> > > };
> > >
> > > #define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)
> > > \
> > >
> > > @@ -488,6 +534,8 @@ const struct spi_device_id spi_nor_ids[] = {
> > >
> > > { "n25q128a13", INFO(0x20ba18, 0, 64 * 1024, 256, 0) },
> > > { "n25q256a",INFO(0x20ba19, 0, 64 * 1024, 512, SECT_4K) },
> > > { "n25q512a",INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
> > >
> > > + { "n25q512ax3", INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
> > > + { "n25q00", INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },
> > >
> > > /* PMC */
> > > { "pm25lv512", INFO(0,0, 32 * 1024,2, SECT_4K_PMC) },
> > >
> > > @@ -965,6 +1013,9 @@ int spi_nor_scan(struct spi_nor *nor, const struct
> > > spi_device_id *id,
> > >
> > > else
> > >
> > > mtd->_write = spi_nor_write;
> > >
> > > + if (info->flags & USE_FSR)
> > > + nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > > +
> >
> > the drivers may fills this hook itself, so the code should like this:
> >--
> > if ((info->flags & USE_FSR) &&
> > nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
> > nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> >--
sorry, the code should like this:
--
if ((info->flags & USE_FSR) &&
nor->wait_till_ready ==
Re: [PATCH V3] Add support for flag status register on Micron chips.
On Fri, Apr 25, 2014 at 04:42:33AM +0200, Marek Vasut wrote:
> On Friday, April 25, 2014 at 03:34:36 AM, Huang Shijie wrote:
> > On Tue, Apr 22, 2014 at 09:03:16AM -0500, Graham Moore wrote:
> > > Some new Micron flash chips require reading the flag
> > > status register to determine when operations have completed.
> > >
> > > Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
> > > require reading the status register before reading the flag status
> > > register.
> > >
> > > This patch adds support for the flag status register in the n25q512ax3
> > > and n25q00 Micron QSPI flash chips.
> > >
> > > Signed-off-by: Graham Moore
> > > ---
> > > V3:
> > > Rebase to l2-mtd spinor branch.
> > > V2:
> > > Remove leading underscore in function names.
> > > Remove type cast in dev_err call and use the proper format
> > > specifier instead.
> > > ---
> > >
> > > drivers/mtd/spi-nor/spi-nor.c | 51
> > > + include/linux/mtd/spi-nor.h
> > > |4
> > > 2 files changed, 55 insertions(+)
> > >
> > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > b/drivers/mtd/spi-nor/spi-nor.c index d6f44d5..24b84d8 100644
> > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > @@ -48,6 +48,25 @@ static int read_sr(struct spi_nor *nor)
> > >
> > > }
> > >
> > > /*
> > >
> > > + * Read the flag status register, returning its value in the location
> > > + * Return the status register value.
> > > + * Returns negative if error occurred.
> > > + */
> > > +static int read_fsr(struct spi_nor *nor)
> > > +{
> > > + int ret;
> > > + u8 val;
> > > +
> > > + ret = nor->read_reg(nor, SPINOR_OP_RDFSR, , 1);
> > > + if (ret < 0) {
> > > + pr_err("error %d reading FSR\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + return val;
> > > +}
> > > +
> > > +/*
> > >
> > > * Read configuration register, returning its value in the
> > > * location. Return the configuration register value.
> > > * Returns negative if error occured.
> > >
> > > @@ -165,6 +184,32 @@ static int spi_nor_wait_till_ready(struct spi_nor
> > > *nor)
> > >
> > > return -ETIMEDOUT;
> > >
> > > }
> > >
> > > +static int spi_nor_wait_till_fsr_ready(struct spi_nor *nor)
> > > +{
> > > + unsigned long deadline;
> > > + int sr;
> > > + int fsr;
> > > +
> > > + deadline = jiffies + MAX_READY_WAIT_JIFFIES;
> > > +
> > > + do {
> > > + cond_resched();
> > > +
> > > + sr = read_sr(nor);
> > > + if (sr < 0)
> > > + break;
> > > + else if (!(sr & SR_WIP)) {
> > > + fsr = read_fsr(nor);
> > > + if (fsr < 0)
> > > + break;
> > > + if (fsr & FSR_READY)
> > > + return 0;
> > > + }
> > > + } while (!time_after_eq(jiffies, deadline));
> > > +
> > > + return -ETIMEDOUT;
> > > +}
> > > +
> > >
> > > /*
> > >
> > > * Service routine to read status register until ready, or timeout
> > > occurs. * Returns non-zero if error.
> > >
> > > @@ -402,6 +447,7 @@ struct flash_info {
> > >
> > > #define SECT_4K_PMC 0x10/* SPINOR_OP_BE_4K_PMC works
> uniformly */
> > > #define SPI_NOR_DUAL_READ 0x20/* Flash supports Dual Read */
> > > #define SPI_NOR_QUAD_READ 0x40/* Flash supports Quad Read */
> > >
> > > +#define USE_FSR 0x80/* use flag status register */
> > >
> > > };
> > >
> > > #define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)
> > > \
> > >
> > > @@ -488,6 +534,8 @@ const struct spi_device_id spi_nor_ids[] = {
> > >
> > > { "n25q128a13", INFO(0x20ba18, 0, 64 * 1024, 256, 0) },
> > > { "n25q256a",INFO(0x20ba19, 0, 64 * 1024, 512, SECT_4K) },
> > > { "n25q512a",INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
> > >
> > > + { "n25q512ax3", INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
> > > + { "n25q00", INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },
> > >
> > > /* PMC */
> > > { "pm25lv512", INFO(0,0, 32 * 1024,2, SECT_4K_PMC) },
> > >
> > > @@ -965,6 +1013,9 @@ int spi_nor_scan(struct spi_nor *nor, const struct
> > > spi_device_id *id,
> > >
> > > else
> > >
> > > mtd->_write = spi_nor_write;
> > >
> > > + if (info->flags & USE_FSR)
> > > + nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > > +
> >
> > the drivers may fills this hook itself, so the code should like this:
> >--
> > if ((info->flags & USE_FSR) &&
> > nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
> > nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> >--
>
> I sense a misdesign of the SPI NOR subsystem here. The subsystem and the
> driver
> compete for a function pointer here ? I guess one should have precedence in
> some
>
Re: mmotm 2014-04-24-13-07 uploaded
On Thu, Apr 24, 2014 at 03:40:29PM -0700, Randy Dunlap wrote: > On 04/24/14 13:08, a...@linux-foundation.org wrote: > > The mm-of-the-moment snapshot 2014-04-24-13-07 has been uploaded to > > > >http://www.ozlabs.org/~akpm/mmotm/ > > > > mmotm-readme.txt says > > > > README for mm-of-the-moment: > > > > http://www.ozlabs.org/~akpm/mmotm/ > > > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > > more than once a week. > > > > You will need quilt to apply these patches to the latest Linus release (3.x > > or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in > > http://ozlabs.org/~akpm/mmotm/series > > > > uml on x86_64 defconfig: > > drivers/built-in.o: In function `__handle_sysrq': > drivers/tty/sysrq.c:514: undefined reference to `rcu_sysrq_start' > drivers/tty/sysrq.c:558: undefined reference to `rcu_sysrq_end' Hmmm... Looks like Rik's patch needs declarations in rcupdate.h. Not sure how I missed that... :-/ Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [perf] more perf_fuzzer memory corruption
I got the bug to trigger again, this time it finally managed to hit a debug_objects WARNING if that's any additional help. The bug followed the same pattern, software event (PERF_TYPE_SOFTWARE / PERF_COUNT_SW_TASK_CLOCK) created, fork happens, event closes in parent, child killed, rcu grace period expires and kfree but event still active. here's the kernel message followed by excerpts from the trace, I can provide full trace if anyone cares. Vince [ 2226.252441] [ cut here ] [ 2226.257503] WARNING: CPU: 4 PID: 0 at lib/debugobjects.c:260 debug_print_object+0x83/0xa0() [ 2226.266545] ODEBUG: free active (active state 0) object type: hrtimer hint: perf_swevent_hrtimer+0x0/0x140 [ 2226.276952] Modules linked in: fuse x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic coretemp snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep kvm i915 crct10dif_pclmul crc32_pclmul iTCO_wdt snd_pcm drm_kms_helper ghash_clmulni_intel iTCO_vendor_support snd_seq snd_timer snd_seq_device aesni_intel snd lpc_ich drm evdev i2c_i801 aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd psmouse soundcore serio_raw pcspkr i2c_algo_bit parport_pc parport mei_me mei mfd_core i2c_core wmi button processor video battery tpm_tis tpm sg sd_mod sr_mod crc_t10dif crct10dif_common cdrom ehci_pci ahci e1000e xhci_hcd ehci_hcd libahci libata ptp crc32c_intel usbcore scsi_mod usb_common pps_core fan thermal thermal_sys [ 2226.350769] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 3.15.0-rc1+ #87 [ 2226.357730] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS 01/26/2014 [ 2226.365658] 0009 88011eb03cd8 8164f7b3 88011eb03d20 [ 2226.373728] 88011eb03d10 810647cd 8800ce03c888 81c433e0 [ 2226.381835] 81a19730 8800cf4e 8800ce03c888 88011eb03d70 [ 2226.389820] Call Trace: [ 2226.392428][] dump_stack+0x45/0x56 [ 2226.398595] [] warn_slowpath_common+0x7d/0xa0 [ 2226.405059] [] warn_slowpath_fmt+0x4c/0x50 [ 2226.411240] [] debug_print_object+0x83/0xa0 [ 2226.417535] [] ? __perf_event_overflow+0x270/0x270 [ 2226.424463] [] debug_check_no_obj_freed+0x263/0x360 [ 2226.431500] [] ? free_event_rcu+0x2a/0x30 [ 2226.437579] [] kfree+0xb0/0x560 [ 2226.442740] [] ? rcu_process_callbacks+0x236/0x620 [ 2226.449658] [] ? pmu_dev_release+0x10/0x10 [ 2226.455811] [] free_event_rcu+0x2a/0x30 [ 2226.461727] [] rcu_process_callbacks+0x29d/0x620 [ 2226.468440] [] ? rcu_process_callbacks+0x236/0x620 [ 2226.475384] [] __do_softirq+0xf5/0x290 [ 2226.481210] [] irq_exit+0xad/0xc0 [ 2226.486540] [] smp_apic_timer_interrupt+0x45/0x60 [ 2226.493350] [] apic_timer_interrupt+0x6d/0x80 [ 2226.499798][] ? tick_nohz_idle_exit+0x12e/0x1b0 [ 2226.507192] [] cpu_startup_entry+0x12e/0x3d0 [ 2226.513542] [] start_secondary+0x193/0x200 [ 2226.519706] ---[ end trace ec55e71b02ef43b3 ]--- Event Created: <...>-13590 [000] 2225.706150: sys_enter:NR 298 (699a70, 0, , , 8, 8) <...>-13590 [000] 2225.706160: kmalloc: (perf_event_alloc+0x55) call_site=8113a565 ptr=0x8800cfa02000 bytes_req=1272 bytes_alloc=2048 gfp_flags=GFP_KERNEL|GFP_ZERO <...>-13590 [000] 2225.706180: bprint: SYSC_perf_event_open: Opened: 1 1 0 (PERF_TYPE_SOFTWARE,PERF_COUNT_SW_TASK_CLOCK) <...>-13590 [000] 2225.706180: sys_exit: NR 298 = 14 (0xe) Fork: <...>-13590 [003] 2226.204981: sys_enter:NR 56 (1200011, 0, 0, 7f6fab28b9d0, 0, 3516) Close in parent: <...>-13590 [003] 2226.216548: sys_enter:NR 3 (e, 11000, 11000, 22, 7f6fab0780b4, 7f6fab078120) <...>-14467 [004] 2226.216548: mm_page_free: page=0xea0002d567e0 pfn=47540192 order=0 <...>-13590 [003] 2226.216549: sys_exit: NR 3 = 0 Kill of child: <...>-13590 [002] 2226.245087: sys_enter:NR 62 (3884, 9, 7, 1, 7f6fab0780fc, 7f6fab078120) Grace period expire/kfree: -0 [004] 2226.252428: kfree: (free_event_rcu+0x2a) call_site=811316aa ptr=0x8800cfa02000 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Add support for flag status register on Micron chips.
On Tue, Apr 22, 2014 at 09:03:16AM -0500, Graham Moore wrote:
> Some new Micron flash chips require reading the flag
> status register to determine when operations have completed.
>
> Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
> require reading the status register before reading the flag status register.
>
> This patch adds support for the flag status register in the n25q512ax3 and
> n25q00
> Micron QSPI flash chips.
>
> Signed-off-by: Graham Moore
> ---
> V3:
> Rebase to l2-mtd spinor branch.
> V2:
> Remove leading underscore in function names.
> Remove type cast in dev_err call and use the proper format
> specifier instead.
> ---
> drivers/mtd/spi-nor/spi-nor.c | 51
> +
> include/linux/mtd/spi-nor.h |4
> 2 files changed, 55 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index d6f44d5..24b84d8 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -48,6 +48,25 @@ static int read_sr(struct spi_nor *nor)
> }
>
> /*
> + * Read the flag status register, returning its value in the location
> + * Return the status register value.
> + * Returns negative if error occurred.
> + */
> +static int read_fsr(struct spi_nor *nor)
> +{
> + int ret;
> + u8 val;
> +
> + ret = nor->read_reg(nor, SPINOR_OP_RDFSR, , 1);
> + if (ret < 0) {
> + pr_err("error %d reading FSR\n", ret);
> + return ret;
> + }
> +
> + return val;
> +}
> +
> +/*
> * Read configuration register, returning its value in the
> * location. Return the configuration register value.
> * Returns negative if error occured.
> @@ -165,6 +184,32 @@ static int spi_nor_wait_till_ready(struct spi_nor *nor)
> return -ETIMEDOUT;
> }
>
> +static int spi_nor_wait_till_fsr_ready(struct spi_nor *nor)
> +{
> + unsigned long deadline;
> + int sr;
> + int fsr;
> +
> + deadline = jiffies + MAX_READY_WAIT_JIFFIES;
> +
> + do {
> + cond_resched();
> +
> + sr = read_sr(nor);
> + if (sr < 0)
> + break;
> + else if (!(sr & SR_WIP)) {
> + fsr = read_fsr(nor);
> + if (fsr < 0)
> + break;
> + if (fsr & FSR_READY)
> + return 0;
> + }
> + } while (!time_after_eq(jiffies, deadline));
> +
> + return -ETIMEDOUT;
> +}
> +
> /*
> * Service routine to read status register until ready, or timeout occurs.
> * Returns non-zero if error.
> @@ -402,6 +447,7 @@ struct flash_info {
> #define SECT_4K_PMC 0x10/* SPINOR_OP_BE_4K_PMC works
> uniformly */
> #define SPI_NOR_DUAL_READ 0x20/* Flash supports Dual Read */
> #define SPI_NOR_QUAD_READ 0x40/* Flash supports Quad Read */
> +#define USE_FSR 0x80/* use flag status register */
> };
>
> #define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
> @@ -488,6 +534,8 @@ const struct spi_device_id spi_nor_ids[] = {
> { "n25q128a13", INFO(0x20ba18, 0, 64 * 1024, 256, 0) },
> { "n25q256a",INFO(0x20ba19, 0, 64 * 1024, 512, SECT_4K) },
> { "n25q512a",INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
> + { "n25q512ax3", INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
> + { "n25q00", INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },
>
> /* PMC */
> { "pm25lv512", INFO(0,0, 32 * 1024,2, SECT_4K_PMC) },
> @@ -965,6 +1013,9 @@ int spi_nor_scan(struct spi_nor *nor, const struct
> spi_device_id *id,
> else
> mtd->_write = spi_nor_write;
>
> + if (info->flags & USE_FSR)
> + nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> +
the drivers may fills this hook itself, so the code should like this:
--
if ((info->flags & USE_FSR) &&
nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
--
thanks
Huang Shijie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched, fair: Stop searching for tasks in newidle balance if there are runnable tasks
On Thu, 2014-04-24 at 18:52 +0200, Peter Zijlstra wrote: > On Thu, Apr 24, 2014 at 09:43:09AM -0700, Jason Low wrote: > > If the below patch is what you were referring to, I believe this > > can help too. This was also something that I was testing out before > > we went with those patches which compares avg_idle with idle balance > > cost. I recall seeing somewhere around a +7% performance improvement > > in at least least 1 of the AIM7 workloads. I can do some more testing > > with this. > > Yes, exactly that. > > I can't remember the details, but I suspect we feared the less agressive > idle balance due to that patch (it will only pull a single task, instead > of multiple) would cause more idle_balance invocations and thereby > decrease throughput. > > So I suppose something with _many_ bursty threads which leads to severe > inequalities would be the workload to trigger that. > > Not sure we've ever seen that.. maybe Mike remembers, he seems to have a > head for such details. I don't recall ever seeing such. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] Add support for flag status register on Micron chips.
On Friday, April 25, 2014 at 03:34:36 AM, Huang Shijie wrote:
> On Tue, Apr 22, 2014 at 09:03:16AM -0500, Graham Moore wrote:
> > Some new Micron flash chips require reading the flag
> > status register to determine when operations have completed.
> >
> > Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
> > require reading the status register before reading the flag status
> > register.
> >
> > This patch adds support for the flag status register in the n25q512ax3
> > and n25q00 Micron QSPI flash chips.
> >
> > Signed-off-by: Graham Moore
> > ---
> > V3:
> > Rebase to l2-mtd spinor branch.
> > V2:
> > Remove leading underscore in function names.
> > Remove type cast in dev_err call and use the proper format
> > specifier instead.
> > ---
> >
> > drivers/mtd/spi-nor/spi-nor.c | 51
> > + include/linux/mtd/spi-nor.h
> > |4
> > 2 files changed, 55 insertions(+)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > b/drivers/mtd/spi-nor/spi-nor.c index d6f44d5..24b84d8 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -48,6 +48,25 @@ static int read_sr(struct spi_nor *nor)
> >
> > }
> >
> > /*
> >
> > + * Read the flag status register, returning its value in the location
> > + * Return the status register value.
> > + * Returns negative if error occurred.
> > + */
> > +static int read_fsr(struct spi_nor *nor)
> > +{
> > + int ret;
> > + u8 val;
> > +
> > + ret = nor->read_reg(nor, SPINOR_OP_RDFSR, , 1);
> > + if (ret < 0) {
> > + pr_err("error %d reading FSR\n", ret);
> > + return ret;
> > + }
> > +
> > + return val;
> > +}
> > +
> > +/*
> >
> > * Read configuration register, returning its value in the
> > * location. Return the configuration register value.
> > * Returns negative if error occured.
> >
> > @@ -165,6 +184,32 @@ static int spi_nor_wait_till_ready(struct spi_nor
> > *nor)
> >
> > return -ETIMEDOUT;
> >
> > }
> >
> > +static int spi_nor_wait_till_fsr_ready(struct spi_nor *nor)
> > +{
> > + unsigned long deadline;
> > + int sr;
> > + int fsr;
> > +
> > + deadline = jiffies + MAX_READY_WAIT_JIFFIES;
> > +
> > + do {
> > + cond_resched();
> > +
> > + sr = read_sr(nor);
> > + if (sr < 0)
> > + break;
> > + else if (!(sr & SR_WIP)) {
> > + fsr = read_fsr(nor);
> > + if (fsr < 0)
> > + break;
> > + if (fsr & FSR_READY)
> > + return 0;
> > + }
> > + } while (!time_after_eq(jiffies, deadline));
> > +
> > + return -ETIMEDOUT;
> > +}
> > +
> >
> > /*
> >
> > * Service routine to read status register until ready, or timeout
> > occurs. * Returns non-zero if error.
> >
> > @@ -402,6 +447,7 @@ struct flash_info {
> >
> > #defineSECT_4K_PMC 0x10/* SPINOR_OP_BE_4K_PMC works
uniformly */
> > #defineSPI_NOR_DUAL_READ 0x20/* Flash supports Dual Read */
> > #defineSPI_NOR_QUAD_READ 0x40/* Flash supports Quad Read */
> >
> > +#defineUSE_FSR 0x80/* use flag status register */
> >
> > };
> >
> > #define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
> >
> > @@ -488,6 +534,8 @@ const struct spi_device_id spi_nor_ids[] = {
> >
> > { "n25q128a13", INFO(0x20ba18, 0, 64 * 1024, 256, 0) },
> > { "n25q256a",INFO(0x20ba19, 0, 64 * 1024, 512, SECT_4K) },
> > { "n25q512a",INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
> >
> > + { "n25q512ax3", INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
> > + { "n25q00", INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },
> >
> > /* PMC */
> > { "pm25lv512", INFO(0,0, 32 * 1024,2, SECT_4K_PMC) },
> >
> > @@ -965,6 +1013,9 @@ int spi_nor_scan(struct spi_nor *nor, const struct
> > spi_device_id *id,
> >
> > else
> >
> > mtd->_write = spi_nor_write;
> >
> > + if (info->flags & USE_FSR)
> > + nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > +
>
> the drivers may fills this hook itself, so the code should like this:
>--
> if ((info->flags & USE_FSR) &&
> nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
> nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
>--
I sense a misdesign of the SPI NOR subsystem here. The subsystem and the driver
compete for a function pointer here ? I guess one should have precedence in
some
way then ... and also, they should be two different pointers, where the
subsystem decides which to use.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[ANNOUNCE] 3.2.57-rt83
Dear RT Folks, I'm pleased to announce the 3.2.57-rt83 stable release. This release is just an update to the new stable 3.2.57 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.2-rt Head SHA1: 918a65748450b9d5ca92dcf6607b7225b6c0e2de Or to build 3.2.57-rt83 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.57.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.57-rt83.patch.xz Enjoy, -- 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/
[ANNOUNCE] 3.4.87-rt108
Dear RT Folks, I'm pleased to announce the 3.4.87-rt108 stable release. This release is just an update to the new stable 3.4.87 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.4-rt Head SHA1: 7fbe72bbd5515be5c0039f48327ce40975d2036e Or to build 3.4.87-rt108 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.87.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.87-rt108.patch.xz Enjoy, -- 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/
[ANNOUNCE] 3.10.37-rt37
Dear RT Folks, I'm pleased to announce the 3.10.37-rt37 stable release. This release is just an update to the new stable 3.10.37 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.10-rt Head SHA1: dbd6cbf37e9c627d224eda99a997eec2d4125095 Or to build 3.10.37-rt37 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.10.37.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patch-3.10.37-rt37.patch.xz Enjoy, -- 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/
Re: pull request: bluetooth 2014-04-24
On Thu, Apr 24, 2014 at 06:51:13PM -0700, Marcel Holtmann wrote: > Hi John, > > > This tag has a lot of stuff in it not in the wireless tree. > > Please only send me pull requests that only include patches related > > to Bluetooth. > > > >> Some fixes for 3.15. There is a revert for the intel driver, a new device > >> id, > >> and two important SSP fixes from Johan. > >> Also we've noticed that your wireless.git tree is not up to date, so this > >> pull > >> was rebased on top of net.git. If you pull from this you'll will be pulling > >> net/master from yesterday as well. > > as Gustavo explained, this is against net.git since wireless.git has not yet > been rebased. > > Regards > > Marcel wireless.git is where it is going to be. It is based from a few dozen commits before -rc1, which was what Dave had as the base of his tree when I started merging post -rc1 fixes into wireless.git. I'm sorry if this is inconvenient, but among other things this keeps net.git and linux.git stuff from getting into wireless-testing.git prematurely. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: serial: fix sysfs-attribute removal deadlock
On Thu, 2014-04-24 at 16:52 +0200, Johan Hovold wrote: > On Thu, Apr 24, 2014 at 10:35:17AM -0400, Tejun Heo wrote: > > On Thu, Apr 24, 2014 at 04:29:15PM +0800, Li Zhong wrote: > > > On Wed, 2014-04-23 at 10:19 -0400, Tejun Heo wrote: > > > > cc'ing Li Zhong who's working on a simliar issue in the following > > > > thread and quoting whole body. > > > > > > > > http://thread.gmane.org/gmane.linux.kernel/1680706 > > > > > > > > Li, this is another variation of the same problem. Maybe this can be > > > > covered by your work too? > > > > > > It seems to me that it is about write something to driver attribute, and > > > driver unloading. If so, maybe it's not easy to reuse the help functions > > > created for device attribute, and device removing. > > > > > > But I guess the idea to break the active protection could still be > > > applied here: > > > > > > Maybe we could try_module_get() here (like the other option suggested by > > > Johan?), and break active protection if we could get the module, > > > something like below? > > > > I don't get why try_module_get() matters here. We can't call into > > ->store if the object at hand is already destroyed and the underlying > > module can't go away if the target device is still alive. > > try_module_get() doesn't actually protect the object. Why does that > > matter? This is self removal, right? Can you please take a look at > > kernfs_remove_self()? > > No, this isn't self removal. The driver-attribute (not device-attribute) > store operation simply grabs a lock that is also held while the driver > is being deregistered at module unload. Taking a reference to the module > in this case will prevent deregistration while store is running. > > But it seems like this can be solved for usb-serial by simply not > holding the lock while deregistering. I didn't look carefully about this lock. But I'm not sure whether there are such requirements for driver attributes: some lock needs be grabbed in the driver attributes store callbacks, and the same lock also needs to be grabbed during driver unregister. If we have such requirements currently or in the future, I think they could all be solved by breaking active protection after get the module reference. Thanks, Zhong > > Johan > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC]How to improve KVM VM resource assignment and per-vm process/thread scheduling.
Hi, ALL Currently kvm hypervisor have lots of features depend on linux standard apis, like vcpupin/mempin/processpin etc. But in the real production environment, we need an automated resource assign and/or scheduling, is there any plan to implement it? resource assignment requirements like: cpu eligible by the VMs In case it is eligible, whether it is in use if it is in use, whether it is dedicated to one VM, or can be shared by many VMs In case of Shared CPU need to configure oversubscription ratio used ratio info So does memory, I/O device assignment requirements. per-vm process/thread scheduling requirements like: On hypervisor side, VMs use vhost-net, virtio-scsi devices have qemu io-thread, vhost-net thread, ovs thread, hNIC interrupt context(hirq/softirq), you shoud place there threads on the same numa node to gain best performance, another important thing, you should balance these threads' cpuload on all the numa cores to avoid unbalance between vcpu usable resources. Thanks. Peter Huang
Re: [PATCH] USB: serial: fix sysfs-attribute removal deadlock
On Thu, 2014-04-24 at 10:35 -0400, Tejun Heo wrote: > On Thu, Apr 24, 2014 at 04:29:15PM +0800, Li Zhong wrote: > > On Wed, 2014-04-23 at 10:19 -0400, Tejun Heo wrote: > > > cc'ing Li Zhong who's working on a simliar issue in the following > > > thread and quoting whole body. > > > > > > http://thread.gmane.org/gmane.linux.kernel/1680706 > > > > > > Li, this is another variation of the same problem. Maybe this can be > > > covered by your work too? > > > > It seems to me that it is about write something to driver attribute, and > > driver unloading. If so, maybe it's not easy to reuse the help functions > > created for device attribute, and device removing. > > > > But I guess the idea to break the active protection could still be > > applied here: > > > > Maybe we could try_module_get() here (like the other option suggested by > > Johan?), and break active protection if we could get the module, > > something like below? > > I don't get why try_module_get() matters here. We can't call into > ->store if the object at hand is already destroyed and the underlying > module can't go away if the target device is still alive. > try_module_get() doesn't actually protect the object. Why does that > matter? This is self removal, right? Can you please take a look at > kernfs_remove_self()? This is about one process writing something to driver attributes, and one process trying to unload this driver. I think try_module_get() could detect whether the driver is being unloaded, and if not, prevent it from being unloaded, so it could protect the object here by not allow the driver to be unloaded. And if the driver is being unloaded, we could abort the write operation directly. Thanks, Zhong > > 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.11 052/182] [SCSI] fix our current target reap infrastructure
On Thu, 2014-04-24 at 09:49 +0100, Luis Henriques wrote: > 3.11.10.9 -stable review patch. If anyone has any objections, please let me > know. > > -- > > From: James Bottomley > > commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59 upstream. > > This patch eliminates the reap_ref and replaces it with a proper kref. > On last put of this kref, the target is removed from visibility in > sysfs. The final call to scsi_target_reap() for the device is done from > __scsi_remove_device() and only if the device was made visible. This > ensures that the target disappears as soon as the last device is gone > rather than waiting until final release of the device (which is often > too long). > > Reviewed-by: Alan Stern > Tested-by: Sarah Sharp > Signed-off-by: James Bottomley > Signed-off-by: Luis Henriques [...] This and the next patch were commented "delay backport by 2 months for field testing". Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Re: [PATCH 3.10 00/23] 3.10.38-stable review
On 04/24/2014 06:49 PM, Greg Kroah-Hartman wrote: On Thu, Apr 24, 2014 at 05:18:42PM -0700, Guenter Roeck wrote: On 04/24/2014 02:48 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.38 release. There are 23 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Apr 26 21:48:09 UTC 2014. Anything received after that time might be too late. Build results: total: 126 pass: 122 skipped: 4 fail: 0 Qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. But wait ... I have 24 patches in this series, not 23. Did you add one ? I count 23, I removed one a few days ago, did your scrips miss that? Yes, looks like it (for both releases). Wonder what happened. I'll update manually and let you know if there are any problems. 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 3.8 068/133] [SCSI] fix our current target reap infrastructure
On Tue, 2014-04-22 at 13:13 -0700, Kamal Mostafa wrote: > 3.8.13.22 -stable review patch. If anyone has any objections, please let me > know. > > -- > > From: James Bottomley > > commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59 upstream. > > This patch eliminates the reap_ref and replaces it with a proper kref. > On last put of this kref, the target is removed from visibility in > sysfs. The final call to scsi_target_reap() for the device is done from > __scsi_remove_device() and only if the device was made visible. This > ensures that the target disappears as soon as the last device is gone > rather than waiting until final release of the device (which is often > too long). > > Reviewed-by: Alan Stern > Tested-by: Sarah Sharp > Signed-off-by: James Bottomley > Signed-off-by: Kamal Mostafa [...] This and the next patch had the comment "delay backport by 2 months for field testing". Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Re: [RFC PATCH v5 1/2] Use lock_device_hotplug() in cpu_probe_store() and cpu_release_store()
On Thu, 2014-04-24 at 10:32 -0400, Tejun Heo wrote: > Hello, > > On Thu, Apr 24, 2014 at 04:37:23PM +0800, Li Zhong wrote: > > On Wed, 2014-04-23 at 10:39 -0400, Tejun Heo wrote: > > After thinking it harder, I still couldn't see ABBA here ... > > > > the active protection taken here is for "probe/release" which will not > > be waited for removing something like "online" under cpu#? Or my > > assumption that s_active for different files are different locks are > > completely wrong? Or I missed something else? > > I'm probably confused about the locking. I was thinking a scenario > like the following. > > A. CPU on/offline > >grabs s_active protection of online node >grabs cpu subsys mutex >perform on/offline >releases cpu subsys mutex >releases s_active protection of online node so the chain here is s_active(online) -> cpu_subsys_mutex > > B. CPU release > >grabs s_active protection of release node >grabs cpu subsys mutex >performs removal of the CPU >removes the online node >releases cpu subsys mutex >releases s_active protection of release node and the chain here is s_active(release) -> cpu_subsys_mutex -> s_active(online) > > A nests cpu subsys mutex under s_active of the online node. B nests > s_active of the online node under the cpu subsys mutex. What am I > missing? >From the above two chain, I think the problem is cpu_subsys_mutex and s_active(online), which is the deadlock we are trying to solve in patch #2. I seems to me s_active(release) here doesn't have lock issues? Thanks, Zhong > > Thanks. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] qlge: Convert /n to \n
Use a newline character appropriately. Signed-off-by: Joe Perches --- drivers/net/ethernet/qlogic/qlge/qlge_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_main.c b/drivers/net/ethernet/qlogic/qlge/qlge_main.c index 0a1d76a..6e36fe1 100644 --- a/drivers/net/ethernet/qlogic/qlge/qlge_main.c +++ b/drivers/net/ethernet/qlogic/qlge/qlge_main.c @@ -3595,7 +3595,7 @@ static int ql_request_irq(struct ql_adapter *qdev) } return status; err_irq: - netif_err(qdev, ifup, qdev->ndev, "Failed to get the interrupts!!!/n"); + netif_err(qdev, ifup, qdev->ndev, "Failed to get the interrupts!!!\n"); ql_free_irq(qdev); return status; } -- 1.8.1.2.459.gbcd45b4.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] treewide: Convert logging message misuses of /n to \n
Joe Perches (5): qlge: Convert /n to \n iwlegacy: Convert /n to \n staging: rtl: Convert /n to \n appledisplay: Convert /n to \n sound: tlv320aic31xx: Convert /n to \n drivers/net/ethernet/qlogic/qlge/qlge_main.c | 2 +- drivers/net/wireless/iwlegacy/3945.c | 2 +- drivers/net/wireless/iwlegacy/4965-mac.c | 2 +- drivers/staging/rtl8188eu/hal/usb_ops_linux.c | 2 +- drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 +- drivers/staging/rtl8723au/hal/usb_ops_linux.c | 4 ++-- drivers/staging/rtl8723au/os_dep/usb_intf.c | 2 +- drivers/usb/misc/appledisplay.c | 2 +- sound/soc/codecs/tlv320aic31xx.c | 2 +- 9 files changed, 10 insertions(+), 10 deletions(-) -- 1.8.1.2.459.gbcd45b4.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth 2014-04-24
Hi John, > This tag has a lot of stuff in it not in the wireless tree. > Please only send me pull requests that only include patches related > to Bluetooth. > >> Some fixes for 3.15. There is a revert for the intel driver, a new device id, >> and two important SSP fixes from Johan. >> Also we've noticed that your wireless.git tree is not up to date, so this >> pull >> was rebased on top of net.git. If you pull from this you'll will be pulling >> net/master from yesterday as well. as Gustavo explained, this is against net.git since wireless.git has not yet been rebased. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] appledisplay: Convert /n to \n
Use a newline character appropriately. Signed-off-by: Joe Perches --- drivers/usb/misc/appledisplay.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/misc/appledisplay.c b/drivers/usb/misc/appledisplay.c index ba6a5d6..f37c78d 100644 --- a/drivers/usb/misc/appledisplay.c +++ b/drivers/usb/misc/appledisplay.c @@ -110,7 +110,7 @@ static void appledisplay_complete(struct urb *urb) __func__, status); return; default: - dev_dbg(dev, "%s - nonzero urb status received: %d/n", + dev_dbg(dev, "%s - nonzero urb status received: %d\n", __func__, status); goto exit; } -- 1.8.1.2.459.gbcd45b4.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] staging: rtl: Convert /n to \n
Use a newline character appropriately.
Signed-off-by: Joe Perches
---
drivers/staging/rtl8188eu/hal/usb_ops_linux.c | 2 +-
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 +-
drivers/staging/rtl8723au/hal/usb_ops_linux.c | 4 ++--
drivers/staging/rtl8723au/os_dep/usb_intf.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
b/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
index 1fa5370..e94c689 100644
--- a/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
+++ b/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
@@ -559,7 +559,7 @@ static void usb_read_port_complete(struct urb *purb, struct
pt_regs *regs)
rtw_read_port(adapt, precvpriv->ff_hwaddr, 0, (unsigned
char *)precvbuf);
break;
case -EINPROGRESS:
- DBG_88E("ERROR: URB IS IN PROGRESS!/n");
+ DBG_88E("ERROR: URB IS IN PROGRESS!\n");
break;
default:
break;
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 49a4ce4..b899191 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -128,7 +128,7 @@ static u8 rtw_init_intf_priv(struct dvobj_priv *dvobj)
dvobj->usb_alloc_vendor_req_buf = rtw_zmalloc(MAX_USB_IO_CTL_SIZE);
if (dvobj->usb_alloc_vendor_req_buf == NULL) {
- DBG_88E("alloc usb_vendor_req_buf failed... /n");
+ DBG_88E("alloc usb_vendor_req_buf failed...\n");
rst = _FAIL;
goto exit;
}
diff --git a/drivers/staging/rtl8723au/hal/usb_ops_linux.c
b/drivers/staging/rtl8723au/hal/usb_ops_linux.c
index 0311cdf..f5a6e61 100644
--- a/drivers/staging/rtl8723au/hal/usb_ops_linux.c
+++ b/drivers/staging/rtl8723au/hal/usb_ops_linux.c
@@ -415,7 +415,7 @@ urb_submit:
case -EPROTO:
break;
case -EINPROGRESS:
- DBG_8723A("ERROR: URB IS IN PROGRESS!/n");
+ DBG_8723A("ERROR: URB IS IN PROGRESS!\n");
break;
default:
break;
@@ -711,7 +711,7 @@ static void usb_read_port_complete(struct urb *purb, struct
pt_regs *regs)
0, precvbuf);
break;
case -EINPROGRESS:
- DBG_8723A("ERROR: URB IS IN PROGRESS!/n");
+ DBG_8723A("ERROR: URB IS IN PROGRESS!\n");
break;
default:
break;
diff --git a/drivers/staging/rtl8723au/os_dep/usb_intf.c
b/drivers/staging/rtl8723au/os_dep/usb_intf.c
index 31ab346..287439a 100644
--- a/drivers/staging/rtl8723au/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8723au/os_dep/usb_intf.c
@@ -109,7 +109,7 @@ static u8 rtw_init_intf_priv(struct dvobj_priv *dvobj)
dvobj->usb_alloc_vendor_req_buf = kzalloc(MAX_USB_IO_CTL_SIZE,
GFP_KERNEL);
if (dvobj->usb_alloc_vendor_req_buf == NULL) {
- DBG_8723A("alloc usb_vendor_req_buf failed... /n");
+ DBG_8723A("alloc usb_vendor_req_buf failed...\n");
rst = _FAIL;
goto exit;
}
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ignore ,keep for efi earlyprintk
On 04/24/14 at 12:45pm, Ingo Molnar wrote: > > * Dave Young wrote: > > > earlyprint=efi,keep results a kernel hang after "Freeing unused kernel > > memory" > > That's a bug. > > > > > Actually efi earlyprintk is using __init functions such as early_ioremap > > etc. > > Thus efi earlyconsole can not be kept. > > > > So just ignore it and give out a warning to user. > > So, bugs should be fixed, not worked around. > > earlyprintk=,keep is really useful for the occasional difficult low > level bug in the printk code or similar, because earlyprintk is a > completely separate code path from printk(). I thought that earlyprintk is just for debugging before real console is available. But it does help debugging printk as you said. Will think about how to fix it. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 5/5] sound: tlv320aic31xx: Convert /n to \n
Use a newline character appropriately. Signed-off-by: Joe Perches --- sound/soc/codecs/tlv320aic31xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c index b93d500..2341910 100644 --- a/sound/soc/codecs/tlv320aic31xx.c +++ b/sound/soc/codecs/tlv320aic31xx.c @@ -377,7 +377,7 @@ static int aic31xx_dapm_power_event(struct snd_soc_dapm_widget *w, reg = AIC31XX_ADCFLAG; break; default: - dev_err(w->codec->dev, "Unknown widget '%s' calling %s/n", + dev_err(w->codec->dev, "Unknown widget '%s' calling %s\n", w->name, __func__); return -EINVAL; } -- 1.8.1.2.459.gbcd45b4.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] iwlegacy: Convert /n to \n
Use a newline character appropriately.
Signed-off-by: Joe Perches
---
drivers/net/wireless/iwlegacy/3945.c | 2 +-
drivers/net/wireless/iwlegacy/4965-mac.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlegacy/3945.c
b/drivers/net/wireless/iwlegacy/3945.c
index d37a6fd..b598e28 100644
--- a/drivers/net/wireless/iwlegacy/3945.c
+++ b/drivers/net/wireless/iwlegacy/3945.c
@@ -573,7 +573,7 @@ il3945_hdl_rx(struct il_priv *il, struct il_rx_buf *rxb)
rx_status.flag |= RX_FLAG_SHORTPRE;
if ((unlikely(rx_stats->phy_count > 20))) {
- D_DROP("dsp size out of range [0,20]: %d/n",
+ D_DROP("dsp size out of range [0,20]: %d\n",
rx_stats->phy_count);
return;
}
diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c
b/drivers/net/wireless/iwlegacy/4965-mac.c
index 888ad5c..c159c05 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -670,7 +670,7 @@ il4965_hdl_rx(struct il_priv *il, struct il_rx_buf *rxb)
}
if ((unlikely(phy_res->cfg_phy_cnt > 20))) {
- D_DROP("dsp size out of range [0,20]: %d/n",
+ D_DROP("dsp size out of range [0,20]: %d\n",
phy_res->cfg_phy_cnt);
return;
}
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/33] 3.14.2-stable review
On Thu, Apr 24, 2014 at 05:21:50PM -0700, Guenter Roeck wrote: > On 04/24/2014 02:48 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.14.2 release. > > There are 33 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat Apr 26 21:44:12 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 126 pass: 121 skipped: 4 fail: 1 > > Qemu tests all passed. Results are expected. > For reference, the failing build is powerpc:allmodconfig, which is failing > upstream as well. > > Details are available at http://server.roeck-us.net:8010/builders. > > Note that the series has 34 patches for me, not 33. Same here, I removed one a few days ago, did you miss that? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/23] 3.10.38-stable review
On Thu, Apr 24, 2014 at 05:18:42PM -0700, Guenter Roeck wrote: > On 04/24/2014 02:48 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.10.38 release. > > There are 23 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat Apr 26 21:48:09 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 126 pass: 122 skipped: 4 fail: 0 > > Qemu tests all passed. Results are as expected. > > Details are available at http://server.roeck-us.net:8010/builders. > > But wait ... I have 24 patches in this series, not 23. Did you add one ? I count 23, I removed one a few days ago, did your scrips miss that? thanks for testing, 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/
[BUG] kmemleak on __radix_tree_preload
Hi mm folks, When I was testing recent linus tree, I got several kmemleaks as below. Could any of you guys guide how to fix this? Thanks, 0. Test - fsstress on f2fs 1. Kernel version commit 4d0fa8a0f01272d4de33704f20303dcecdb55df1 Merge: 39bfe90 b5539fa Author: Linus Torvalds Date: Tue Apr 22 09:28:02 2014 -0700 Merge tag 'gpio-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull gpio fixes from Linus Walleij: 2. Bug This is one of the results, but all the results indicate __radix_tree_preload. unreferenced object 0x88002ae2a238 (size 576): comm "fsstress", pid 25019, jiffies 4295651360 (age 2276.104s) hex dump (first 32 bytes): 01 00 00 00 81 ff ff ff 00 00 00 00 00 00 00 00 40 7d 37 81 ff ff ff ff 50 a2 e2 2a 00 88 ff ff @}7.P..* backtrace: [] kmemleak_alloc+0x26/0x50 [] kmem_cache_alloc+0xdc/0x190 [] __radix_tree_preload+0x49/0xc0 [] radix_tree_maybe_preload+0x21/0x30 [] add_to_page_cache_lru+0x3c/0xc0 [] grab_cache_page_write_begin+0x98/0xf0 [] f2fs_write_begin+0xa1/0x370 [f2fs] [] generic_perform_write+0xc7/0x1e0 [] __generic_file_aio_write+0x1d0/0x400 [] generic_file_aio_write+0x60/0xe0 [] do_sync_write+0x5a/0x90 [] vfs_write+0xc5/0x1f0 [] SyS_write+0x52/0xb0 [] system_call_fastpath+0x16/0x1b [] 0x -- Jaegeuk Kim Samsung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v5 2/2] Use kernfs_break_active_protection() for device online store callbacks
On Thu, 2014-04-24 at 12:02 +0200, Rafael J. Wysocki wrote: > On 4/24/2014 10:59 AM, Li Zhong wrote: > > On Wed, 2014-04-23 at 18:12 +0200, Rafael J. Wysocki wrote: > >> On 4/23/2014 4:23 PM, Tejun Heo wrote: > >>> Hello, Rafael. > >> Hi, > >> > >>> On Wed, Apr 23, 2014 at 12:21:33AM +0200, Rafael J. Wysocki wrote: > Can you please elaborate a bit? > >>> Because it can get involved in larger locking dependency issues by > >>> joining dependency graphs of two otherwise largely disjoint > >>> subsystems. It has potential to create possible deadlocks which don't > >>> need to exist. > >> Well, I do my best not to add unnecessary locks if that's what you mean. > >> > It is there to protect hotplug operations involving multiple devices > (in different subsystems) from racing with each other. Why exactly > is it bad? > >>> But why would different subsystems, say cpu and memory, use the same > >>> lock? Wouldn't those subsystems already have proper locking inside > >>> their own subsystems? > >> That locking is not sufficient. > >> > >>> Why add this additional global lock across multiple subsystems? > >> That basically is because of how eject works when it is triggered via ACPI. > >> > >> It is signaled for a device at the top of a subtree. It may be a > >> container of some sort and the eject involves everything below that > >> device in the ACPI namespace. That may involve multiple subsystem > >> (CPUs, memory, PCI host bridge, etc.). > >> > >> We do that in two steps, offline (which can fail) and eject proper > >> (which can't fail and makes all of the involved devices go away). All > >> that has to be done in one go with respect to the sysfs-triggered > >> offline/online and that's why the lock is there. > > Thank you for the education. It's more clear to me now why we need this > > lock. > > > > I still have some small questions about when this lock is needed: > > > > I could understand sysfs-triggered online is not acceptable when > > removing devices in multiple subsystems. But maybe concurrent offline > > and remove(with proper per subsystem locks) seems not harmful? > > > > And if we just want to remove some devices in a specific subsystem, e.g. > > like writing /cpu/release, if it just wants to offline and remove some > > cpus, then maybe we don't require the device_hotplug_lock to be taken? > > No and no. > > If the offline phase fails for any device in the subtree, we roll back > the operation > and online devices that have already been offlined by it. Also the ACPI > hot-addition > needs to acquire device_hotplug_lock so that it doesn't race with ejects > and so > that lock needs to be taken by sysfs-triggered offline too. I can understand that hot-addition needs the device_hotplug lock, but still not very clear about the offline. I guess your are describing following scenario: user A: (trying remove cpu 1 and memory 1-10) lock_device_hotplug offline cpu with cpu locks -- successful offline memories with memory locks -- failed, e.g. for memory8 online cpu and memory with their locks unlock_device_hotplug user B: (trying offline cpu 1) offline cpu with cpu locks But I don't see any problem for user B not taking the device_hotplug lock. The result may be different for user B to take or not take the lock. But I think it could be seen as concurrent online/offline for cpu1 under cpu hotplug locks, which just depends on which is executed last? Or did I miss something here? Thanks, Zhong > 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: pull request: bluetooth 2014-04-24
This tag has a lot of stuff in it not in the wireless tree. Please only send me pull requests that only include patches related to Bluetooth. John On Thu, Apr 24, 2014 at 11:53:29AM -0300, Gustavo Padovan wrote: > Hi John, > > Some fixes for 3.15. There is a revert for the intel driver, a new device id, > and two important SSP fixes from Johan. > Also we've noticed that your wireless.git tree is not up to date, so this pull > was rebased on top of net.git. If you pull from this you'll will be pulling > net/master from yesterday as well. > > Please pull or let me know of any concerns you have. Thanks! > > Gustavo > > --- > The following changes since commit 6a51b5e4d59e00051e65e836520912cd7c717be1: > > hisax/icc: add missing semicolon after label (2014-04-22 21:22:47 -0400) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git > for-upstream > > for you to fetch changes up to b66a81831359495b3768ace72452209cdf5d6614: > > Bluetooth: Add support for Lite-on [04ca:3007] (2014-04-24 12:43:33 +0300) > > > Johan Hedberg (2): > Bluetooth: Fix triggering BR/EDR L2CAP Connect too early > Bluetooth: Fix redundant encryption request for reauthentication > > Marcel Holtmann (1): > Revert "Bluetooth: Enable autosuspend for Intel Bluetooth device" > > Mohammed Habibulla (1): > Bluetooth: Add support for Lite-on [04ca:3007] > > drivers/bluetooth/ath3k.c | 2 ++ > drivers/bluetooth/btusb.c | 5 ++--- > net/bluetooth/hci_conn.c | 9 ++--- > net/bluetooth/hci_event.c | 6 ++ > 4 files changed, 16 insertions(+), 6 deletions(-) > -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Tux3 Report: Untar Unleashed
Hi, It is about time to post Tux3 patches for review. Almost. Running the classic kernel untar test on an older 60 MB/sec hard disk turned up a performance gap versus Ext4 by a factor of six. Hmm, that is in the range where it could be a basic design bug, we need to do something. Tux3 performed fine on the actual untar, but syncing those thousands of small files to disk was slow. The cause turned out to be multiple issues. Two were unimplemented design features. For every file, we were writing a btree root and a leaf block with pointers to data extents. Instead, most btrees can be "zero depth" with just a leaf block and no index block. And many files are just a single extent so the btree is not needed at all. When writing lots of small files, we were transferring up to three times more blocks than necessary. The kernel tarball showed a metadata-to-data ratio of about 1.2. This is way too high, it should be less than a tenth of that. After factoring out those extra blocks, a huge performance gap still remains. This must have something to do with seeking, but our disk layout for this load is pretty good, so what is going on? It turns out to be important not only to write to the right place, but at the right time. The block scheduler tries to merge physically contiguous requests even when submitted out of order, but if the requests are too far apart in time, an earlier request may have already left the queue by the time an adjacent request shows up. This causes extra, costly seeks on spinning disks. Ideally, we want our writes contiguous in both time and space. Then the disk hardware should be able to make seek costs effectively disappear and stream the data out at close to media speed. Fixes for these issues took the form of patches from Hirofumi to eliminate redundant btree roots and submit metadata writes in a better order for block scheduling, and a patch from me to implement a planned "direct extent" feature to eliminate btrees completely for small files. Iterative improvements went something like this: * Start: 60 seconds to sync but Ext4 only needs 10 seconds * Eliminate most btree roots => now sync in 53 seconds * Submit file btree together with data => sync in 19 seconds * Eliminate btree complete for small files => 15 seconds * Flush inode table blocks after all data => 8 seconds We ended up with: untar: real 0m2.706s user 0m0.360s sys 0m2.160s sync: real 0m8.651s user 0m0.000s sys 0m0.024s Ext4 takes about 4 seconds to untar and 10 seconds to sync, turning in a respectable 50 MB/sec write bandwidth on a 62 MB/sec disk. Tux3 now syncs at 60 MB/sec, or 97% of raw media bandwidth. So we went from 500% slower to 23% faster, woohoo. The cost for this is that we dropped out of sight for a few weeks. Maybe it was worth it because the performance artifact was so big that it could have been a major design deficiency instead of what it really was: leaving some details for later. When we checked read performance on the untarred tree, we immediately saw mixed results. Re-tarring the kernel tree is faster than Ext4, but directory listing is slower by a multiple. So we need to analyze and fix ls without breaking the good tar and untar behavior. The question is, is it worth another delay before putting Tux3 patches up for review? I think not. In fact, by going quiet when we hit these things, we detract from the spectator sport aspect of open source. It might not be any faster to work in public, but it is more fun. Plus, it engraves a record on the internet as a guide for the next effort to invent a new and wonderful filesystem. It is hard to overstate the value to our project of all the historical chatter about design and development process for Ext4 and other Linux filesystems. We often find ourselves retracing the same learning processes. By doing this work in public, we give something back. Improving ls performance to Ext4 standards may just be a matter of implementing inode table readahead, or it might be that plus something else. In any case, this will go on the longish list of important issues that are not central. Inline data is a related item already on that list. There is a nice plan for it, where the same design feature handles inline files and tail packing, similar to extended attributes. In particular, most directories in the kernel tarball are small enough to inline, which could speed up ls significantly. With most files and directories inlined, a Tux3 filesystem becomes a single, fatter btree, with different issues and tradeoffs. On the whole, I expect substantial improvements in both space utilization and performance. The final chapter in the tar performance saga has yet to be written. We also need to ask why we are putting so much effort into performing well on spinning disks, which are rapidly disappearing. Two reasons. First, spinning disks are not gone yet, they are just migrating to a
[PATCH 1/1] x86/apic: add apic_irqs bitmap to identify irqs from apic
During irq migration, fixup_irqs() in arch/x86/kernel/irq.c will
call irq_force_complete_move() for every valid irqs, including
whose irq_chip is not apic(like ioapic_chip, msi_chip, etc) kind.
While the function irq_force_complete_move() in
arch/x86/kernel/apic/io_apic.c will treat all input irqs as apic
kind, which has the structure irq_cfg as its chip_data and with
chance to be modified.
During supporting intel MID platform, some new irq_chip were added
like gpio, whose sub-irqs are valid and will call
irq_force_complete_move(). We met one softlockup/hardlockup issue
while adding a new pmic irq_chip, whose chip_data's value condition
triggered IPI send for clean up vector when miss calling
irq_force_complete_move(), then one lock field in its chip_data
was unexpected modified.
This patch add an apic_irqs bitmap to identify irqs from apic
irq_chip, this bitmap only be set when apic kind of irq try to
assign_irq_vector, and clear when __clear_irq_vector.
By checking apic_irqs bitmap, irq_force_complete_move() can avoid
being called when input irq does not belong to apic kind of irq_chip.
Signed-off-by: Jason Chen
---
arch/x86/kernel/apic/io_apic.c | 21 -
include/linux/irqdesc.h| 6 ++
kernel/irq/internals.h | 6 --
3 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 6ad4658..1e2bcb5 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -37,6 +37,7 @@
#include
#include /* time_after() */
#include
+#include
#include
#include
#include
@@ -74,6 +75,8 @@ int sis_apic_bug = -1;
static DEFINE_RAW_SPINLOCK(ioapic_lock);
static DEFINE_RAW_SPINLOCK(vector_lock);
+static DECLARE_BITMAP(apic_irqs, IRQ_BITMAP_BITS);
+
static struct ioapic {
/*
* # of IRQ routing registers
@@ -1158,6 +1161,10 @@ next:
err = 0;
break;
}
+
+ if (err == 0)
+ set_bit(irq, apic_irqs);
+
free_cpumask_var(tmp_mask);
return err;
}
@@ -1185,6 +1192,7 @@ static void __clear_irq_vector(int irq, struct irq_cfg
*cfg)
cfg->vector = 0;
cpumask_clear(cfg->domain);
+ clear_bit(irq, apic_irqs);
if (likely(!cfg->move_in_progress))
return;
@@ -1213,6 +1221,9 @@ void __setup_vector_irq(int cpu)
raw_spin_lock(_lock);
/* Mark the inuse vectors */
for_each_active_irq(irq) {
+ if (!test_bit(irq, apic_irqs))
+ continue;
+
cfg = irq_get_chip_data(irq);
if (!cfg)
continue;
@@ -2268,7 +2279,12 @@ static void irq_complete_move(struct irq_cfg *cfg)
void irq_force_complete_move(int irq)
{
- struct irq_cfg *cfg = irq_get_chip_data(irq);
+ struct irq_cfg *cfg;
+
+ if (!test_bit(irq, apic_irqs))
+ return;
+
+ cfg = irq_get_chip_data(irq);
if (!cfg)
return;
@@ -2541,6 +2557,9 @@ static inline void init_IO_APIC_traps(void)
* 0x80, because int 0x80 is hm, kind of importantish. ;)
*/
for_each_active_irq(irq) {
+ if (!test_bit(irq, apic_irqs))
+ continue;
+
cfg = irq_get_chip_data(irq);
if (IO_APIC_IRQ(irq) && cfg && !cfg->vector) {
/*
diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
index 26e2661..1b20979 100644
--- a/include/linux/irqdesc.h
+++ b/include/linux/irqdesc.h
@@ -1,6 +1,12 @@
#ifndef _LINUX_IRQDESC_H
#define _LINUX_IRQDESC_H
+#ifdef CONFIG_SPARSE_IRQ
+# define IRQ_BITMAP_BITS (NR_IRQS + 8196)
+#else
+# define IRQ_BITMAP_BITS NR_IRQS
+#endif
+
/*
* Core internal functions to deal with irq descriptors
*
diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
index ddf1ffe..b2fb994 100644
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -8,12 +8,6 @@
#include
#include
-#ifdef CONFIG_SPARSE_IRQ
-# define IRQ_BITMAP_BITS (NR_IRQS + 8196)
-#else
-# define IRQ_BITMAP_BITS NR_IRQS
-#endif
-
#define istate core_internal_state__do_not_mess_with_it
extern bool noirqdebug;
--
1.8.1.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/
Re: [PATCH 3/3] sched, fair: Stop searching for tasks in newidle balance if there are runnable tasks
On Thu, 2014-04-24 at 18:52 +0200, Peter Zijlstra wrote: > On Thu, Apr 24, 2014 at 09:43:09AM -0700, Jason Low wrote: > > If the below patch is what you were referring to, I believe this > > can help too. This was also something that I was testing out before > > we went with those patches which compares avg_idle with idle balance > > cost. I recall seeing somewhere around a +7% performance improvement > > in at least least 1 of the AIM7 workloads. I can do some more testing > > with this. > > Yes, exactly that. > > I can't remember the details, but I suspect we feared the less agressive > idle balance due to that patch (it will only pull a single task, instead > of multiple) would cause more idle_balance invocations and thereby > decrease throughput. > > So I suppose something with _many_ bursty threads which leads to severe > inequalities would be the workload to trigger that. > > Not sure we've ever seen that.. maybe Mike remembers, he seems to have a > head for such details. Okay, so running the AIM7 fserver workload, I didn't see any noticeable performance gains with having move_tasks() pull at most one task. The +7% performance improvement that I saw was without the idle balance cost patches. I think that with those idle balance cost patches, there aren't as much benefits with this patch, and allowing more than 1 task to be pulled in move_task(), like we have now, may be the best option. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mfd: rdc321x: Fix off-by-one for ngpio setting
The valid gpio is GPIO0 ~ GPIO58, so ngpio should be 59.
This patch also renames RDC321X_MAX_GPIO to RDC321X_NUM_GPIO because it
actually means the number of available GPIOs.
Signed-off-by: Axel Lin
Acked-by: Linus Walleij
---
drivers/mfd/rdc321x-southbridge.c | 2 +-
include/linux/mfd/rdc321x.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/rdc321x-southbridge.c
b/drivers/mfd/rdc321x-southbridge.c
index c795697..6575585 100644
--- a/drivers/mfd/rdc321x-southbridge.c
+++ b/drivers/mfd/rdc321x-southbridge.c
@@ -38,7 +38,7 @@ static struct resource rdc321x_wdt_resource[] = {
};
static struct rdc321x_gpio_pdata rdc321x_gpio_pdata = {
- .max_gpios = RDC321X_MAX_GPIO,
+ .max_gpios = RDC321X_NUM_GPIO,
};
static struct resource rdc321x_gpio_resources[] = {
diff --git a/include/linux/mfd/rdc321x.h b/include/linux/mfd/rdc321x.h
index 4bdf19c..442743a 100644
--- a/include/linux/mfd/rdc321x.h
+++ b/include/linux/mfd/rdc321x.h
@@ -12,7 +12,7 @@
#define RDC321X_GPIO_CTRL_REG2 0x84
#define RDC321X_GPIO_DATA_REG2 0x88
-#define RDC321X_MAX_GPIO 58
+#define RDC321X_NUM_GPIO 59
struct rdc321x_gpio_pdata {
struct pci_dev *sb_pdev;
--
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/
[PATCHv4 2/7] ARM: EXYNOS: Support secondary CPU boot of Exynos4212
From: Kyungmin Park
This patch fix the offset of CPU boot address and change parameter of smc call
of SMC_CMD_CPU1BOOT command for Exynos4212.
Signed-off-by: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
arch/arm/mach-exynos/firmware.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 932129e..aa01c42 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -18,6 +18,8 @@
#include
+#include
+
#include "smc.h"
static int exynos_do_idle(void)
@@ -28,13 +30,24 @@ static int exynos_do_idle(void)
static int exynos_cpu_boot(int cpu)
{
+ /*
+* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
+* But, Exynos4212 has only one secondary CPU so second parameter
+* isn't used for informing secure firmware about CPU id.
+*/
+ if (soc_is_exynos4212())
+ cpu = 0;
+
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
}
static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
{
- void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+ void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
+
+ if (!soc_is_exynos4212())
+ boot_reg += 4*cpu;
__raw_writel(boot_addr, boot_reg);
return 0;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 0/7] Support new Exynos3250 SoC based on Cortex-A7 dual core
This patchset support new Exynos3250 Samsung SoC based on Cortex-A7 dual core. Exynos3250 is a System-On-Chip (SoC) that is based on 32-bit RISC processor for Smartphone. It is desigend with the 28nm low-power high-K metal gate process and provides the best performance features. This patchset include some patches such as: - Support booting of Exynos3250 - Supoort uart/mct/adc/gic/i2c/spi/power-domain/pmu/mshc/pwm/amba - Support the clock control for Exynos3250 using common clk framework [Pinctrl patch for Exynos3250] The pinctrl patch for Exynos3250 has been merged in pinctrl.git of Linus Walleij - [1] https://lkml.org/lkml/2014/4/23/72 This patchset is based on following git repo/branch. - git repo : git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git - branch : for-next (Linux 3.15-rc1) Changes from v3: - Remove all dependency about following patchset to remove static memory mapping for SYSRAM[1] / PMU ([2] or [3]). If following patchset merged, I'll send a further patches to support SYSRAM/PMU for secondary CPU. [1] http://www.spinics.net/lists/arm-kernel/msg323011.html [2] https://lkml.org/lkml/2014/4/2/48 [3] http://www.spinics.net/lists/arm-kernel/msg316013.html Changes from v2: - Remove static memory mapping about SYSRAM/PMU such as following patches: ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250 ARM: EXYNOS: Add IO mapping for PMU of Exynos3250 - Add description for secondary CPU boot of Exynos4212/Exynos3250 - Fix description in exynos_cpu_die() to remove particular SoC series - Fix minor coding style - Add documentation for Exynos3250 clock controller Changes from v1: - Add new "samsung,exynos3" compatible name - Add comment about exynos_cpu_boot in Exynos4212 - Remove unnecessary 'goto' statement in firmware.c - Use read_cpuid_part_number() function instead of assembler directly - Post separated pinctrl patch from this patchset : https://lkml.org/lkml/2014/4/13/156 - Remove unused pmu interrupts due to Exynos3250 dual-core - Cosolidate all the patches related to exynos3250.dtsi into one patch - Fix gic compatible name to "cortex-a15-gic" because Cortex-A7 GIC is same - Add sign-off of sender to all this patches - Fix minor typo Chanwoo Choi (4): ARM: EXYNOS: Add Exynos3250 SoC ID ARM: EXYNOS: Support secondary CPU boot of Exynos3250 ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7 dt-bindings: add documentation for Exynos3250 clock controller Kyungmin Park (1): ARM: EXYNOS: Support secondary CPU boot of Exynos4212 Tomasz Figa (2): clk: samsung: exynos3250: Add clocks using common clock framework ARM: dts: Add device tree sources for Exynos3250 .../devicetree/bindings/clock/exynos3250-clock.txt | 41 + arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 +++ arch/arm/boot/dts/exynos3250.dtsi | 405 + arch/arm/boot/dts/exynos4212-tizenw.dts| 926 + arch/arm/mach-exynos/Kconfig | 22 + arch/arm/mach-exynos/exynos.c | 2 + arch/arm/mach-exynos/firmware.c| 21 +- arch/arm/mach-exynos/hotplug.c | 19 +- arch/arm/plat-samsung/include/plat/cpu.h | 10 + drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos3250.c | 785 + include/dt-bindings/clock/exynos3250.h | 256 ++ 12 files changed, 2957 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/exynos3250-clock.txt create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi create mode 100644 arch/arm/boot/dts/exynos3250.dtsi create mode 100644 arch/arm/boot/dts/exynos4212-tizenw.dts create mode 100644 drivers/clk/samsung/clk-exynos3250.c create mode 100644 include/dt-bindings/clock/exynos3250.h -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 7/7] ARM: dts: Add device tree sources for Exynos3250
From: Tomasz Figa
This patch add new exynos3250.dtsi to support Exynos3250 SoC based on Cortex-A7
dual core and includes following dt nodes:
- GIC interrupt controller
- Pinctrl to control GPIOs
- Clock controller
- CPU information (Cortex-A7 dual core)
- UART to support serial port
- MCT (Multi Core Timer)
- ADC (Analog Digital Converter)
- I2C/SPI bus
- Power domain
- PMU (Performance Monitoring Unit)
- MSHC (Mobile Storage Host Controller)
- PWM (Pluse Width Modulation)
- AMBA bus
Signed-off-by: Tomasz Figa
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
Signed-off-by: Inki Dae
Signed-off-by: Hyunhee Kim
Signed-off-by: Jaehoon Chung
Signed-off-by: Bartlomiej Zolnierkiewicz
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 +++
arch/arm/boot/dts/exynos3250.dtsi | 405 +
arch/arm/boot/dts/exynos4212-tizenw.dts | 926 ++
3 files changed, 1808 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
create mode 100644 arch/arm/boot/dts/exynos4212-tizenw.dts
diff --git a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
new file mode 100644
index 000..976490b
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
@@ -0,0 +1,477 @@
+/*
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config optiosn are listed as
device
+ * tree nodes are listed in this file.
+ *
+ * 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.
+*/
+
+/ {
+ pinctrl@1140 {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb: gpb {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc0: gpc0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc1: gpc1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd0: gpd0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd1: gpd1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ uart0_data: uart0-data {
+ samsung,pins = "gpa0-0", "gpa0-1";
+ samsung,pin-function = <0x2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart0_fctl: uart0-fctl {
+ samsung,pins = "gpa0-2", "gpa0-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_data: uart1-data {
+ samsung,pins = "gpa0-4", "gpa0-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_fctl: uart1-fctl {
+ samsung,pins = "gpa0-6", "gpa0-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c2_bus: i2c2-bus {
+ samsung,pins = "gpa0-6", "gpa0-7";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+
[PATCHv4 5/7] clk: samsung: exynos3250: Add clocks using common clock framework
From: Tomasz Figa This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7 using common clock framework. The CMU (Clock Management Unit) of Exynos3250 control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses, and function clocks for individual IPs. The CMU of Exynos3250 includes following clock doamins: - CPU block for Cortex-A7 MPCore processor - LEFTBUS/RIGHTBUS block - TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR Cc: Mike Turquette Cc: Kukjin Kim Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Tomasz Figa Signed-off-by: Chanwoo Choi Signed-off-by: Hyunhee Kim Signed-off-by: Sylwester Nawrocki Signed-off-by: Inki Dae Signed-off-by: Seung-Woo Kim Signed-off-by: Jaehoon Chung Signed-off-by: Karol Wrona Signed-off-by: YoungJun Cho Signed-off-by: Kyungmin Park --- drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos3250.c | 785 + include/dt-bindings/clock/exynos3250.h | 256 +++ 3 files changed, 1042 insertions(+) create mode 100644 drivers/clk/samsung/clk-exynos3250.c create mode 100644 include/dt-bindings/clock/exynos3250.h diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile index 8eb4799..d120797 100644 --- a/drivers/clk/samsung/Makefile +++ b/drivers/clk/samsung/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o +obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o diff --git a/drivers/clk/samsung/clk-exynos3250.c b/drivers/clk/samsung/clk-exynos3250.c new file mode 100644 index 000..0574a76 --- /dev/null +++ b/drivers/clk/samsung/clk-exynos3250.c @@ -0,0 +1,785 @@ +/* + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * + * 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. + * + * Common Clock Framework support for Exynos3250 SoC. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "clk.h" +#include "clk-pll.h" + +#define SRC_LEFTBUS0x4200 +#define DIV_LEFTBUS0x4500 +#define GATE_IP_LEFTBUS0x4800 +#define SRC_RIGHTBUS 0x8200 +#define DIV_RIGHTBUS 0x8500 +#define GATE_IP_RIGHTBUS 0x8800 +#define GATE_IP_PERIR 0x8960 +#define MPLL_LOCK 0xc010 +#define MPLL_CON0 0xc110 +#define VPLL_LOCK 0xc020 +#define VPLL_CON0 0xc120 +#define UPLL_LOCK 0xc030 +#define UPLL_CON0 0xc130 +#define SRC_TOP0 0xc210 +#define SRC_TOP1 0xc214 +#define SRC_CAM0xc220 +#define SRC_MFC0xc228 +#define SRC_G3D0xc22c +#define SRC_LCD0xc234 +#define SRC_ISP0xc238 +#define SRC_FSYS 0xc240 +#define SRC_PERIL0 0xc250 +#define SRC_PERIL1 0xc254 +#define SRC_MASK_TOP 0xc310 +#define SRC_MASK_CAM 0xc320 +#define SRC_MASK_LCD 0xc334 +#define SRC_MASK_ISP 0xc338 +#define SRC_MASK_FSYS 0xc340 +#define SRC_MASK_PERIL00xc350 +#define SRC_MASK_PERIL10xc354 +#define DIV_TOP0xc510 +#define DIV_CAM0xc520 +#define DIV_MFC0xc528 +#define DIV_G3D0xc52c +#define DIV_LCD0xc534 +#define DIV_ISP0xc538 +#define DIV_FSYS0 0xc540 +#define DIV_FSYS1 0xc544 +#define DIV_FSYS2 0xc548 +#define DIV_PERIL0 0xc550 +#define DIV_PERIL1 0xc554 +#define DIV_PERIL3 0xc55c +#define DIV_PERIL4 0xc560 +#define DIV_PERIL5 0xc564 +#define DIV_CAM1 0xc568 +#define CLKDIV2_RATIO 0xc580 +#define GATE_SCLK_CAM 0xc820 +#define GATE_SCLK_MFC 0xc828 +#define GATE_SCLK_G3D 0xc82c +#define GATE_SCLK_LCD 0xc834 +#define GATE_SCLK_ISP_TOP 0xc838 +#define GATE_SCLK_FSYS 0xc840 +#define GATE_SCLK_PERIL0xc850 +#define GATE_IP_CAM0xc920 +#define GATE_IP_MFC0xc928 +#define GATE_IP_G3D0xc92c +#define GATE_IP_LCD0xc934 +#define GATE_IP_ISP0xc938 +#define GATE_IP_FSYS 0xc940 +#define GATE_IP_PERIL 0xc950 +#define GATE_BLOCK 0xc970 +#define APLL_LOCK 0x14000 +#define APLL_CON0 0x14100 +#define SRC_CPU0x14200 +#define DIV_CPU0
[PATCHv4 4/7] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
This patch decide proper lowpower mode of either a15 or a9 according to own ID
from Main ID register.
Cc: Arnd Bergmann
Cc: Marc Zynigier
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/mach-exynos/hotplug.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..acf3119 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -135,16 +135,21 @@ void __ref exynos_cpu_die(unsigned int cpu)
int primary_part = 0;
/*
-* we're ready for shutdown now, so do it.
-* Exynos4 is A9 based while Exynos5 is A15; check the CPU part
-* number by reading the Main ID register and then perform the
-* appropriate sequence for entering low power.
+* Prepare the CPU for shutting down. The required sequence of
+* operations depends on core type. CPUID part number can be used to
+* determine the right way.
*/
- asm("mrc p15, 0, %0, c0, c0, 0" : "=r"(primary_part) : : "cc");
- if ((primary_part & 0xfff0) == 0xc0f0)
+ primary_part = read_cpuid_part_number();
+
+ switch (primary_part) {
+ case ARM_CPU_PART_CORTEX_A7:
+ case ARM_CPU_PART_CORTEX_A15:
cpu_enter_lowpower_a15();
- else
+ break;
+ default:
cpu_enter_lowpower_a9();
+ break;
+ }
platform_do_lowpower(cpu, );
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 6/7] dt-bindings: add documentation for Exynos3250 clock controller
The Exynos3250 clocks are statically listed and registered using the
Samsung specific common clock helper functions. Both device tree based
clock lookup and clkdev based clock lookups are supported.
Cc: Mike Turquette
Cc: Kukjin Kim
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Randy Dunlap
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Signed-off-by: Tomasz Figa
Acked-by: Kyungmin Park
---
.../devicetree/bindings/clock/exynos3250-clock.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/exynos3250-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
new file mode 100644
index 000..aadc9c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
@@ -0,0 +1,41 @@
+* Samsung Exynos3250 Clock Controller
+
+The Exynos3250 clock controller generates and supplies clock to various
+controllers within the Exynos3250 SoC.
+
+Required Properties:
+
+- compatible: should be one of the following.
+ - "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos3250.h header and can be used in device
+tree sources.
+
+Example 1: An example of a clock controller node is listed below.
+
+ cmu: clock-controller@1003 {
+ compatible = "samsung,exynos3250-cmu";
+ reg = <0x1003 0x2>;
+ #clock-cells = <1>;
+ };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+ controller. Refer to the standard clock bindings for information
+ about 'clocks' and 'clock-names' property.
+
+ serial@1380 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x1380 0x100>;
+ interrupts = <0 109 0>;
+ clocks = < CLK_UART0>, < CLK_SCLK_UART0>;
+ clock-names = "uart", "clk_uart_baud0";
+ };
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 1/7] ARM: EXYNOS: Add Exynos3250 SoC ID
This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that
is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses Cortex-A7
dual cores and has a target speed of 1.0GHz.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/mach-exynos/Kconfig | 22 ++
arch/arm/mach-exynos/exynos.c| 2 ++
arch/arm/plat-samsung/include/plat/cpu.h | 10 ++
3 files changed, 34 insertions(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..6da8a68 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -11,6 +11,17 @@ if ARCH_EXYNOS
menu "SAMSUNG EXYNOS SoCs Support"
+config ARCH_EXYNOS3
+ bool "SAMSUNG EXYNOS3"
+ select ARM_AMBA
+ select CLKSRC_OF
+ select HAVE_ARM_SCU if SMP
+ select HAVE_SMP
+ select PINCTRL
+ select PM_GENERIC_DOMAINS if PM_RUNTIME
+ help
+ Samsung EXYNOS3 SoCs based systems
+
config ARCH_EXYNOS4
bool "SAMSUNG EXYNOS4"
default y
@@ -41,6 +52,17 @@ config ARCH_EXYNOS5
comment "EXYNOS SoCs"
+config SOC_EXYNOS3250
+ bool "SAMSUNG EXYNOS3250"
+ default y
+ depends on ARCH_EXYNOS3
+ select ARCH_HAS_BANDGAP
+ select ARM_CPU_SUSPEND if PM
+ select PINCTRL_EXYNOS
+ select SAMSUNG_DMADEV
+ help
+ Enable EXYNOS3250 CPU support
+
config CPU_EXYNOS4210
bool "SAMSUNG EXYNOS4210"
default y
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 6a5fe18..e7dc6fd 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -346,6 +346,8 @@ static void __init exynos_dt_machine_init(void)
}
static char const *exynos_dt_compat[] __initconst = {
+ "samsung,exynos3",
+ "samsung,exynos3250",
"samsung,exynos4",
"samsung,exynos4210",
"samsung,exynos4212",
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index 5992b8d..3d808f6b 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -43,6 +43,9 @@ extern unsigned long samsung_cpu_id;
#define S5PV210_CPU_ID 0x4311
#define S5PV210_CPU_MASK 0xF000
+#define EXYNOS3250_SOC_ID 0xE3472000
+#define EXYNOS3_SOC_MASK0xF000
+
#define EXYNOS4210_CPU_ID 0x4321
#define EXYNOS4212_CPU_ID 0x4322
#define EXYNOS4412_CPU_ID 0xE4412200
@@ -68,6 +71,7 @@ IS_SAMSUNG_CPU(s5p6440, S5P6440_CPU_ID, S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5p6450, S5P6450_CPU_ID, S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5pc100, S5PC100_CPU_ID, S5PC100_CPU_MASK)
IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_MASK)
+IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
@@ -126,6 +130,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
EXYNOS5_SOC_MASK)
# define soc_is_s5pv210() 0
#endif
+#if defined(CONFIG_SOC_EXYNOS3250)
+# define soc_is_exynos3250()is_samsung_exynos3250()
+#else
+# define soc_is_exynos3250()0
+#endif
+
#if defined(CONFIG_CPU_EXYNOS4210)
# define soc_is_exynos4210() is_samsung_exynos4210()
#else
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250
This patch fix the offset of CPU boot address and don't need to send smc call
of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 removes
WFE in secure mode.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/mach-exynos/firmware.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index aa01c42..386d01d 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -31,11 +31,17 @@ static int exynos_do_idle(void)
static int exynos_cpu_boot(int cpu)
{
/*
+* Exynos3250 doesn't need to send smc command for secondary CPU boot
+* because Exynos3250 removes WFE in secure mode.
+*/
+ if (soc_is_exynos3250())
+ return 0;
+ /*
* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
* But, Exynos4212 has only one secondary CPU so second parameter
* isn't used for informing secure firmware about CPU id.
*/
- if (soc_is_exynos4212())
+ else if (soc_is_exynos4212())
cpu = 0;
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
@@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long
boot_addr)
{
void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
- if (!soc_is_exynos4212())
+ if (!soc_is_exynos4212() && !soc_is_exynos3250())
boot_reg += 4*cpu;
__raw_writel(boot_addr, boot_reg);
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 1/2] serial: sc16is7xx
From: Jon Ringle The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel high performance UART. The SC16IS7xx's internal register set is backward-compatible with the widely used and widely popular 16C450. The SC16IS7xx also provides additional advanced features such as auto hardware and software flow control, automatic RS-485 support, and software reset. Signed-off-by: Jon Ringle --- drivers/tty/serial/Kconfig |9 + drivers/tty/serial/Makefile |1 + drivers/tty/serial/sc16is7xx.c | 1279 ++ include/uapi/linux/serial_core.h |3 + 4 files changed, 1292 insertions(+) create mode 100644 drivers/tty/serial/sc16is7xx.c diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 988fa2b..c3e2b32 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1178,6 +1178,15 @@ config SERIAL_SCCNXP_CONSOLE help Support for console on SCCNXP serial ports. +config SERIAL_SC16IS7XX + tristate "SC16IS7xx serial support" + select SERIAL_CORE + select REGMAP_I2C if I2C + help + This selects support for SC16IS7xx serial ports. + Supported ICs are SC16IS740, SC16IS741, SC16IS750, SC16IS752, + SC16IS760 and SC16IS762. + config SERIAL_BFIN_SPORT tristate "Blackfin SPORT emulate UART" depends on BLACKFIN diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile index 3a5be46..712732b 100644 --- a/drivers/tty/serial/Makefile +++ b/drivers/tty/serial/Makefile @@ -51,6 +51,7 @@ obj-$(CONFIG_SERIAL_MPSC) += mpsc.o obj-$(CONFIG_SERIAL_SB1250_DUART) += sb1250-duart.o obj-$(CONFIG_ETRAX_SERIAL) += crisv10.o obj-$(CONFIG_SERIAL_SCCNXP) += sccnxp.o +obj-$(CONFIG_SERIAL_SC16IS7XX) += sc16is7xx.o obj-$(CONFIG_SERIAL_JSM) += jsm/ obj-$(CONFIG_SERIAL_TXX9) += serial_txx9.o obj-$(CONFIG_SERIAL_VR41XX) += vr41xx_siu.o diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c new file mode 100644 index 000..ed139f5 --- /dev/null +++ b/drivers/tty/serial/sc16is7xx.c @@ -0,0 +1,1279 @@ +/* + * SC16IS7xx tty serial driver - Copyright (C) 2014 GridPoint + * Author: Jon Ringle + * + * Based on max310x.c, by Alexander Shiyan + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define SC16IS7XX_NAME "sc16is7xx" + +/* SC16IS7XX register definitions */ +#define SC16IS7XX_RHR_REG (0x00) /* RX FIFO */ +#define SC16IS7XX_THR_REG (0x00) /* TX FIFO */ +#define SC16IS7XX_IER_REG (0x01) /* Interrupt enable */ +#define SC16IS7XX_IIR_REG (0x02) /* Interrupt Identification */ +#define SC16IS7XX_FCR_REG (0x02) /* FIFO control */ +#define SC16IS7XX_LCR_REG (0x03) /* Line Control */ +#define SC16IS7XX_MCR_REG (0x04) /* Modem Control */ +#define SC16IS7XX_LSR_REG (0x05) /* Line Status */ +#define SC16IS7XX_MSR_REG (0x06) /* Modem Status */ +#define SC16IS7XX_SPR_REG (0x07) /* Scratch Pad */ +#define SC16IS7XX_TXLVL_REG(0x08) /* TX FIFO level */ +#define SC16IS7XX_RXLVL_REG(0x09) /* RX FIFO level */ +#define SC16IS7XX_IODIR_REG(0x0a) /* I/O Direction + * - only on 75x/76x + */ +#define SC16IS7XX_IOSTATE_REG (0x0b) /* I/O State + * - only on 75x/76x + */ +#define SC16IS7XX_IOINTENA_REG (0x0c) /* I/O Interrupt Enable + * - only on 75x/76x + */ +#define SC16IS7XX_IOCONTROL_REG(0x0e) /* I/O Control + * - only on 75x/76x + */ +#define SC16IS7XX_EFCR_REG (0x0f) /* Extra Features Control */ + +/* TCR/TLR Register set: Only if ((MCR[2] == 1) && (EFR[4] == 1)) */ +#define SC16IS7XX_TCR_REG (0x06) /* Transmit control */ +#define SC16IS7XX_TLR_REG (0x07) /* Trigger level */ + +/* Special Register set: Only if ((LCR[7] == 1) && (LCR != 0xBF)) */ +#define SC16IS7XX_DLL_REG (0x00) /* Divisor Latch Low */ +#define SC16IS7XX_DLH_REG (0x01) /* Divisor Latch High */ + +/* Enhanced Register set: Only if (LCR == 0xBF) */ +#define SC16IS7XX_EFR_REG (0x02) /* Enhanced Features */ +#define SC16IS7XX_XON1_REG (0x04) /* Xon1
[PATCH v7 2/2] serial: sc16is7xx: Add bindings documentation for the SC16IS7XX UARTs
From: Jon Ringle
This patch adds the devicetree documentation for the NXP SC16IS7XX UARTs.
Signed-off-by: Jon Ringle
---
.../devicetree/bindings/serial/nxp,sc16is7xx.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
new file mode 100644
index 000..246c795
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
@@ -0,0 +1,33 @@
+* NXP SC16IS7xx advanced Universal Asynchronous Receiver-Transmitter (UART)
+
+Required properties:
+- compatible: Should be one of the following:
+ - "nxp,sc16is740" for NXP SC16IS740,
+ - "nxp,sc16is741" for NXP SC16IS741,
+ - "nxp,sc16is750" for NXP SC16IS750,
+ - "nxp,sc16is752" for NXP SC16IS752,
+ - "nxp,sc16is760" for NXP SC16IS760,
+ - "nxp,sc16is762" for NXP SC16IS762.
+- reg: I2C address of the SC16IS7xx device.
+- interrupt-parent: The phandle for the interrupt controller that
+ services interrupts for this IC.
+- interrupts: Should contain the UART interrupt
+- clocks: Reference to the IC source clock.
+
+Optional properties:
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Should be two. The first cell is the GPIO number and
+ the second cell is used to specify the GPIO polarity:
+0 = active high,
+1 = active low.
+
+Example:
+sc16is750: sc16is750@51 {
+compatible = "nxp,sc16is750";
+reg = <0x51>;
+clocks = <>;
+interrupt-parent = <>;
+interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+gpio-controller;
+#gpio-cells = <2>;
+};
--
1.8.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb_wwan: some improvement on write and resume
When enable usb serial for modem data, sometimes the tty is blocked
in tty_wait_until_sent because portdata->out_busy always is set and
have no chance to be cleared.
We have found two scenarios lead to portdata->out_busy problem.
1. usb_wwan_write set portdata->out_busy firstly, then try autopm
async with error. No out urb submit and no usb_wwan_outdat_callback
to this write, portdata->out_busy can't be cleared.
2. usb_wwan_resume run play_delayed() and spin_unlock, but
intfdata->suspended still is not set to zero. At this time
usb_wwan_write is called and anchor the urb to delay list. Then resume
keep running but the delayed urb have no chance to be commit until next
resume. If the time of next resume is far away, tty will be blocked
in tty_wait_until_sent during time.
The patch make some enhancement on write and resume.
1. clear portdata->out_busy if usb_wwan_write try autopm async with
error.
2. put play_Delayed and intfdata->suspended together in the spinlock,
it's to avoid the write race during resume.
Signed-off-by: xiao jin
Signed-off-by: Zhang, Qi1
Reviewed-by: David Cohen
---
drivers/usb/serial/usb_wwan.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/serial/usb_wwan.c b/drivers/usb/serial/usb_wwan.c
index 640fe01..8e06afc 100644
--- a/drivers/usb/serial/usb_wwan.c
+++ b/drivers/usb/serial/usb_wwan.c
@@ -228,8 +228,10 @@ int usb_wwan_write(struct tty_struct *tty, struct
usb_serial_port *port,
usb_pipeendpoint(this_urb->pipe), i);
err = usb_autopm_get_interface_async(port->serial->interface);
- if (err < 0)
+ if (err < 0) {
+ clear_bit(i, >out_busy);
break;
+ }
/* send the data */
memcpy(this_urb->transfer_buffer, buf, todo);
@@ -661,17 +663,15 @@ int usb_wwan_resume(struct usb_serial *serial)
}
}
+ spin_lock_irq(>susp_lock);
for (i = 0; i < serial->num_ports; i++) {
/* walk all ports */
port = serial->port[i];
portdata = usb_get_serial_port_data(port);
/* skip closed ports */
- spin_lock_irq(>susp_lock);
- if (!portdata || !portdata->opened) {
- spin_unlock_irq(>susp_lock);
+ if (!portdata || !portdata->opened)
continue;
- }
for (j = 0; j < N_IN_URB; j++) {
urb = portdata->in_urbs[j];
@@ -684,9 +684,7 @@ int usb_wwan_resume(struct usb_serial *serial)
}
}
play_delayed(port);
- spin_unlock_irq(>susp_lock);
}
- spin_lock_irq(>susp_lock);
intfdata->suspended = 0;
spin_unlock_irq(>susp_lock);
err_out:
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] arm: fixmap: implement __set_fixmap()
Rabin,
On Fri, Apr 4, 2014 at 2:27 PM, Rabin Vincent wrote:
> This is used from set_fixmap() and clear_fixmap() via
> asm-generic/fixmap.h.
>
> Signed-off-by: Rabin Vincent
> ---
> Needs "arm: use generic fixmap.h", available in linux-next.
>
> arch/arm/include/asm/fixmap.h | 2 ++
> arch/arm/mm/mmu.c | 7 +++
> 2 files changed, 9 insertions(+)
>
> diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
> index 68ea615..55ed076 100644
> --- a/arch/arm/include/asm/fixmap.h
> +++ b/arch/arm/include/asm/fixmap.h
> @@ -23,6 +23,8 @@ enum fixed_addresses {
> __end_of_fixed_addresses
> };
>
> +void __set_fixmap(enum fixed_addresses idx, unsigned long phys, pgprot_t
> prot);
nit: I think you should use phys_addr_t for the physical address, right?
void __set_fixmap(enum fixed_addresses idx, phys_addr_t phys, pgprot_t prot);
...I'm no expert at fixmap, but otherwise this looks pretty reasonable to me.
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] inetpeer_gc_worker: trivial cleanup
Do not initialize list twice.
list_replace_init() already takes care of initializing list.
We don't need to initialize it with LIST_HEAD() beforehand.
Signed-off-by: xiao jin
Reviewed-by: David Cohen
---
net/ipv4/inetpeer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
index 48f4244..c98cf14 100644
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -120,7 +120,7 @@ int inet_peer_maxttl __read_mostly = 10 * 60 * HZ; /*
usual time to live: 10 min
static void inetpeer_gc_worker(struct work_struct *work)
{
struct inet_peer *p, *n, *c;
- LIST_HEAD(list);
+ struct list_head list;
spin_lock_bh(_lock);
list_replace_init(_list, );
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] timer_stats: add core information to event counters
Add information specifying the CPU core where timer callbacks (events)
were executed to the output of /proc/timer_stats.
Signed-off-by: Daniel Sangorrin
Signed-off-by: Yoshitake Kobayashi
---
Documentation/timers/timer_stats.txt | 43
kernel/time/timer_stats.c| 20 +
2 files changed, 35 insertions(+), 28 deletions(-)
diff --git a/Documentation/timers/timer_stats.txt
b/Documentation/timers/timer_stats.txt
index 8abd40b..aeb467f 100644
--- a/Documentation/timers/timer_stats.txt
+++ b/Documentation/timers/timer_stats.txt
@@ -21,7 +21,7 @@ Linux system over a sample period:
- the name of the process which initialized the timer
- the function where the timer was initialized
- the callback function which is associated to the timer
-- the number of events (callbacks)
+- the number of events (callbacks) executed per core
timer_stats adds an entry to /proc: /proc/timer_stats
@@ -45,24 +45,29 @@ readouts.
Sample output of /proc/timer_stats:
-Timerstats sample period: 3.888770 s
- 12, 0 swapper hrtimer_stop_sched_tick (hrtimer_sched_tick)
- 15, 1 swapper hcd_submit_urb (rh_timer_func)
- 4, 959 kedacschedule_timeout (process_timeout)
- 1, 0 swapper page_writeback_init (wb_timer_fn)
- 28, 0 swapper hrtimer_stop_sched_tick (hrtimer_sched_tick)
- 22, 2948 IRQ 4tty_flip_buffer_push (delayed_work_timer_fn)
- 3, 3100 bash schedule_timeout (process_timeout)
- 1, 1 swapper queue_delayed_work_on (delayed_work_timer_fn)
- 1, 1 swapper queue_delayed_work_on (delayed_work_timer_fn)
- 1, 1 swapper neigh_table_init_no_netlink (neigh_periodic_timer)
- 1, 2292 ip __netdev_watchdog_up (dev_watchdog)
- 1,23 events/1 do_cache_clean (delayed_work_timer_fn)
-90 total events, 30.0 events/sec
-
-The first column is the number of events, the second column the pid, the third
-column is the name of the process. The forth column shows the function which
-initialized the timer and in parenthesis the callback function which was
+Timer Stats Version: v0.3
+Sample period: 4.365 s
+Collection: inactive
+ 0, 4366, 0 swapper/1tick_setup_sched_timer
(tick_sched_timer)
+ 4366, 0, 1 swapper/0tick_setup_sched_timer
(tick_sched_timer)
+ 0, 5, 1132 sshd sk_reset_timer (tcp_write_timer)
+ 0, 4, 515 apache2 schedule_hrtimeout_range_clock
(hrtimer_wakeup)
+16, 0, 0 swapper/0usb_hcd_poll_rh_status (rh_timer_func)
+16, 0, 0 swapper/0usb_hcd_poll_rh_status (rh_timer_func)
+16, 0, 0 swapper/0usb_hcd_poll_rh_status (rh_timer_func)
+16, 0, 0 swapper/0usb_hcd_poll_rh_status (rh_timer_func)
+16, 0, 0 swapper/0usb_hcd_poll_rh_status (rh_timer_func)
+ 0, 7, 0 swapper/1sk_reset_timer (tcp_delack_timer)
+ 3, 4, 0 swapper/0clocksource_watchdog
(clocksource_watchdog)
+0D, 3D,13 kworker/1:0 queue_delayed_work_on
(delayed_work_timer_fn)
+3D, 0D,22 kworker/0:1 queue_delayed_work_on
(delayed_work_timer_fn)
+ 1, 0,22 kworker/0:1 e1000_watchdog_task (e1000_watchdog)
+8842 total events, 2025.658 events/sec
+
+The first comma-separated columns represent the number of events (one
+column per present core), the next column the pid, and the next one is the
+name of the process. The last column shows the function which
+initialized the timer and in parentheses the callback function which was
executed on expiry.
Thomas, Ingo
diff --git a/kernel/time/timer_stats.c b/kernel/time/timer_stats.c
index 1fb08f2..53d1544 100644
--- a/kernel/time/timer_stats.c
+++ b/kernel/time/timer_stats.c
@@ -67,7 +67,7 @@ struct entry {
/*
* Number of timeout events:
*/
- unsigned long count;
+ unsigned long count[NR_CPUS];
unsigned inttimer_flag;
/*
@@ -203,7 +203,7 @@ static struct entry *tstat_lookup(struct entry *entry, char
*comm)
curr = alloc_entry();
if (curr) {
*curr = *entry;
- curr->count = 0;
+ memset(curr->count, 0, sizeof(curr->count));
curr->next = NULL;
memcpy(curr->comm, comm, TASK_COMM_LEN);
@@ -259,7 +259,7 @@ void timer_stats_update_stats(void *timer, pid_t pid, void
*startf,
entry = tstat_lookup(, comm);
if (likely(entry))
- entry->count++;
+ entry->count[raw_smp_processor_id()]++;
else
atomic_inc(_count);
@@ -284,7 +284,7 @@ static int tstats_show(struct seq_file *m, void *v)
unsigned long ms;
long events = 0;
ktime_t time;
- int i;
+ int i, cpu;
[PATCH] cleanup_net: trivial cleanup
Do not initialize net_kill_list twice.
list_replace_init() already takes care of initializing net_kill_list.
We don't need to initialize it with LIST_HEAD() beforehand.
Signed-off-by: xiao jin
Reviewed-by: David Cohen
---
net/core/net_namespace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 81d3a9a..05e949d 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -273,7 +273,7 @@ static void cleanup_net(struct work_struct *work)
{
const struct pernet_operations *ops;
struct net *net, *tmp;
- LIST_HEAD(net_kill_list);
+ struct list_head net_kill_list;
LIST_HEAD(net_exit_list);
/* Atomically snapshot the list of namespaces to cleanup */
--
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/
[PATCHv4 3/9] extcon: max8997: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
---
drivers/extcon/extcon-max8997.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index 804a446..d9f7f1b 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -699,16 +699,15 @@ static int max8997_muic_probe(struct platform_device
*pdev)
}
/* External connector */
- info->edev = devm_kzalloc(>dev, sizeof(struct extcon_dev),
- GFP_KERNEL);
- if (!info->edev) {
+ info->edev = devm_extcon_dev_allocate(>dev, max8997_extcon_cable);
+ if (IS_ERR(info->edev)) {
dev_err(>dev, "failed to allocate memory for extcon\n");
ret = -ENOMEM;
goto err_irq;
}
info->edev->name = DEV_NAME;
info->edev->dev.parent = >dev;
- info->edev->supported_cable = max8997_extcon_cable;
+
ret = devm_extcon_dev_register(>dev, info->edev);
if (ret) {
dev_err(>dev, "failed to register extcon device\n");
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] kernel/power/hibernate.c: use unsigned variables instead of signed variables in swsusp_show_speed()
do_div() needs 'u64' type, or it reports warning. And negative number
is meaningless for "speed", so change all signed to unsigned within
swsusp_show_speed().
The related warning (with allmodconfig for unicore32):
CC kernel/power/hibernate.o
kernel/power/hibernate.c: In function ‘swsusp_show_speed’:
kernel/power/hibernate.c:237: warning: comparison of distinct pointer types
lacks a cast
Signed-off-by: Chen Gang
---
kernel/power/hibernate.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index f4f2073..afc11a0 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -228,19 +228,23 @@ static void platform_recover(int platform_mode)
void swsusp_show_speed(struct timeval *start, struct timeval *stop,
unsigned nr_pages, char *msg)
{
- s64 elapsed_centisecs64;
- int centisecs;
- int k;
- int kps;
+ u64 elapsed_centisecs64;
+ unsigned int centisecs;
+ unsigned int k;
+ unsigned int kps;
elapsed_centisecs64 = timeval_to_ns(stop) - timeval_to_ns(start);
+ /*
+* If "(s64)elapsed_centisecs64 < 0", it will print long elapsed time,
+* it is obvious enough for what went wrong.
+*/
do_div(elapsed_centisecs64, NSEC_PER_SEC / 100);
centisecs = elapsed_centisecs64;
if (centisecs == 0)
centisecs = 1; /* avoid div-by-zero */
k = nr_pages * (PAGE_SIZE / 1024);
kps = (k * 100) / centisecs;
- printk(KERN_INFO "PM: %s %d kbytes in %d.%02d seconds (%d.%02d MB/s)\n",
+ printk(KERN_INFO "PM: %s %u kbytes in %u.%02u seconds (%u.%02u MB/s)\n",
msg, k,
centisecs / 100, centisecs % 100,
kps / 1000, (kps % 1000) / 10);
--
1.9.2.459.g68773ac
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 1/9] extcon: Add extcon_dev_allocate/free() to control the memory of extcon device
This patch add APIs to control the extcon device on extcon provider driver.
The extcon_dev_allocate() allocates the memory of extcon device and initializes
supported cables. And then extcon_dev_free() decrement the reference of the
device of extcon device and free the memory of the extcon device. This APIs
must need to implement devm_extcon_dev_allocate()/free() APIs.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-class.c | 36
include/linux/extcon.h| 13 +
2 files changed, 49 insertions(+)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index f6df689..654ed52 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -565,6 +565,42 @@ static void dummy_sysfs_dev_release(struct device *dev)
{
}
+/*
+ * extcon_dev_allocate() - Allocate the memory of extcon device.
+ * @supported_cable: Array of supported cable names ending with NULL.
+ * If supported_cable is NULL, cable name related APIs
+ * are disabled.
+ *
+ * This function allocates the memory for extcon device without allocating
+ * memory in each extcon provider driver and initialize default setting for
+ * extcon device.
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail
+ */
+struct extcon_dev *extcon_dev_allocate(const char **supported_cable)
+{
+ struct extcon_dev *edev;
+
+ edev = kzalloc(sizeof(*edev), GFP_KERNEL);
+ if (!edev)
+ return ERR_PTR(-ENOMEM);
+
+ edev->max_supported = 0;
+ edev->supported_cable = supported_cable;
+
+ return edev;
+}
+
+/*
+ * extcon_dev_free() - Free the memory of extcon device.
+ * @edev: the extcon device to free
+ */
+void extcon_dev_free(struct extcon_dev *edev)
+{
+ kfree(edev);
+}
+EXPORT_SYMBOL_GPL(extcon_dev_free);
+
/**
* extcon_dev_register() - Register a new extcon device
* @edev : the new extcon device (should be allocated before calling)
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 548447b..f4fc983 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -192,6 +192,12 @@ extern void devm_extcon_dev_unregister(struct device *dev,
extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
/*
+ * Following APIs control the memory of extcon device.
+ */
+extern struct extcon_dev *extcon_dev_allocate(const char **cables);
+extern void extcon_dev_free(struct extcon_dev *edev);
+
+/*
* get/set/update_state access the 32b encoded state value, which represents
* states of all possible cables of the multistate port. For example, if one
* calls extcon_set_state(edev, 0x7), it may mean that all the three cables
@@ -267,6 +273,13 @@ static inline int devm_extcon_dev_register(struct device
*dev,
static inline void devm_extcon_dev_unregister(struct device *dev,
struct extcon_dev *edev) { }
+static inline struct extcon_dev *extcon_dev_allocate(const char **cables)
+{
+ return ERR_PTR(-ENOMEM);
+}
+
+static inline void extcon_dev_free(struct extcon_dev *edev) { }
+
static inline u32 extcon_get_state(struct extcon_dev *edev)
{
return 0;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 2/9] extcon: Add devm_extcon_dev_allocate/free to manage the resource of extcon device
This patch add device managed devm_extcon_dev_{allocate,free} to automatically
free the memory of extcon_dev structure without handling free operation.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-class.c | 72 +++
include/linux/extcon.h| 11 +++
2 files changed, 71 insertions(+), 12 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 654ed52..24ede8b 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -601,6 +601,66 @@ void extcon_dev_free(struct extcon_dev *edev)
}
EXPORT_SYMBOL_GPL(extcon_dev_free);
+static int devm_extcon_dev_match(struct device *dev, void *res, void *data)
+{
+ struct extcon_dev **r = res;
+
+ if (!r || !*r) {
+ WARN_ON(!r || !*r);
+ return 0;
+ }
+
+ return *r == data;
+}
+
+static void devm_extcon_dev_release(struct device *dev, void *res)
+{
+ extcon_dev_free(*(struct extcon_dev **)res);
+}
+
+/**
+ * devm_extcon_dev_allocate - Allocate managed extcon device
+ * @dev: device owning the extcon device being created
+ * @supported_cable: Array of supported cable names ending with NULL.
+ * If supported_cable is NULL, cable name related APIs
+ * are disabled.
+ *
+ * This function manages automatically the memory of extcon device using device
+ * resource management and simplify the control of freeing the memory of extcon
+ * device.
+ *
+ * Returns the pointer memory of allocated extcon_dev if success
+ * or ERR_PTR(err) if fail
+ */
+struct extcon_dev *devm_extcon_dev_allocate(struct device *dev,
+ const char **supported_cable)
+{
+ struct extcon_dev **ptr, *edev;
+
+ ptr = devres_alloc(devm_extcon_dev_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ edev = extcon_dev_allocate(supported_cable);
+ if (IS_ERR(edev)) {
+ devres_free(ptr);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ *ptr = edev;
+ devres_add(dev, ptr);
+
+ return edev;
+}
+EXPORT_SYMBOL_GPL(devm_extcon_dev_allocate);
+
+void devm_extcon_dev_free(struct device *dev, struct extcon_dev *edev)
+{
+ WARN_ON(devres_release(dev, devm_extcon_dev_release,
+ devm_extcon_dev_match, edev));
+}
+EXPORT_SYMBOL_GPL(devm_extcon_dev_free);
+
/**
* extcon_dev_register() - Register a new extcon device
* @edev : the new extcon device (should be allocated before calling)
@@ -860,18 +920,6 @@ static void devm_extcon_dev_unreg(struct device *dev, void
*res)
extcon_dev_unregister(*(struct extcon_dev **)res);
}
-static int devm_extcon_dev_match(struct device *dev, void *res, void *data)
-{
- struct extcon_dev **r = res;
-
- if (!r || !*r) {
- WARN_ON(!r || !*r);
- return 0;
- }
-
- return *r == data;
-}
-
/**
* devm_extcon_dev_register() - Resource-managed extcon_dev_register()
* @dev: device to allocate extcon device
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index f4fc983..3fd831b 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -196,6 +196,9 @@ extern struct extcon_dev *extcon_get_extcon_dev(const char
*extcon_name);
*/
extern struct extcon_dev *extcon_dev_allocate(const char **cables);
extern void extcon_dev_free(struct extcon_dev *edev);
+extern struct extcon_dev *devm_extcon_dev_allocate(struct device *dev,
+ const char **cables);
+extern void devm_extcon_dev_free(struct device *dev, struct extcon_dev *edev);
/*
* get/set/update_state access the 32b encoded state value, which represents
@@ -280,6 +283,14 @@ static inline struct extcon_dev *extcon_dev_allocate(const
char **cables)
static inline void extcon_dev_free(struct extcon_dev *edev) { }
+static inline struct extcon_dev *devm_extcon_dev_allocate(struct device *dev,
+ const char **cables)
+{
+ return ERR_PTR(-ENOMEM);
+}
+
+static inline void devm_extcon_dev_free(struct extcon_dev *edev) { }
+
static inline u32 extcon_get_state(struct extcon_dev *edev)
{
return 0;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 7/9] extcon: adc-jack: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-adc-jack.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index 549d820..e18f95b 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -39,7 +39,7 @@
* @chan: iio channel being queried.
*/
struct adc_jack_data {
- struct extcon_dev edev;
+ struct extcon_dev *edev;
const char **cable_names;
int num_cables;
@@ -64,7 +64,7 @@ static void adc_jack_handler(struct work_struct *work)
ret = iio_read_channel_raw(data->chan, _val);
if (ret < 0) {
- dev_err(>edev.dev, "read channel() error: %d\n", ret);
+ dev_err(>edev->dev, "read channel() error: %d\n", ret);
return;
}
@@ -80,7 +80,7 @@ static void adc_jack_handler(struct work_struct *work)
}
/* if no def has met, it means state = 0 (no cables attached) */
- extcon_set_state(>edev, state);
+ extcon_set_state(data->edev, state);
}
static irqreturn_t adc_jack_irq_thread(int irq, void *_data)
@@ -102,18 +102,21 @@ static int adc_jack_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
- data->edev.name = pdata->name;
-
if (!pdata->cable_names) {
dev_err(>dev, "error: cable_names not defined.\n");
return -EINVAL;
}
- data->edev.dev.parent = >dev;
- data->edev.supported_cable = pdata->cable_names;
+ data->edev = devm_extcon_dev_allocate(>dev, pdata->cable_names);
+ if (IS_ERR(data->edev)) {
+ dev_err(>dev, "failed to allocate extcon device\n");
+ return -ENOMEM;
+ }
+ data->edev->dev.parent = >dev;
+ data->edev->name = pdata->name;
/* Check the length of array and set num_cables */
- for (i = 0; data->edev.supported_cable[i]; i++)
+ for (i = 0; data->edev->supported_cable[i]; i++)
;
if (i == 0 || i > SUPPORTED_CABLE_MAX) {
dev_err(>dev, "error: pdata->cable_names size = %d\n",
@@ -144,7 +147,7 @@ static int adc_jack_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, data);
- err = devm_extcon_dev_register(>dev, >edev);
+ err = devm_extcon_dev_register(>dev, data->edev);
if (err)
return err;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 4/9] extcon: max77693: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
---
drivers/extcon/extcon-max77693.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index f0f18e2..2c7c3e1 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -1175,23 +1175,22 @@ static int max77693_muic_probe(struct platform_device
*pdev)
}
/* Initialize extcon device */
- info->edev = devm_kzalloc(>dev, sizeof(struct extcon_dev),
- GFP_KERNEL);
- if (!info->edev) {
+ info->edev = devm_extcon_dev_allocate(>dev,
+ max77693_extcon_cable);
+ if (IS_ERR(info->edev)) {
dev_err(>dev, "failed to allocate memory for extcon\n");
ret = -ENOMEM;
goto err_irq;
}
info->edev->name = DEV_NAME;
info->edev->dev.parent = >dev;
- info->edev->supported_cable = max77693_extcon_cable;
+
ret = devm_extcon_dev_register(>dev, info->edev);
if (ret) {
dev_err(>dev, "failed to register extcon device\n");
goto err_irq;
}
-
/* Initialize MUIC register by using platform data or default data */
if (pdata && pdata->muic_data) {
init_data = pdata->muic_data->init_data;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 5/9] extcon: max14577: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Cc: Krzysztof Kozlowski
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
---
drivers/extcon/extcon-max14577.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index d17dd4f..d49e891 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -739,14 +739,15 @@ static int max14577_muic_probe(struct platform_device
*pdev)
}
/* Initialize extcon device */
- info->edev = devm_kzalloc(>dev, sizeof(*info->edev), GFP_KERNEL);
- if (!info->edev) {
+ info->edev = devm_extcon_dev_allocate(>dev,
+ max14577_extcon_cable);
+ if (IS_ERR(info->edev)) {
dev_err(>dev, "failed to allocate memory for extcon\n");
return -ENOMEM;
}
info->edev->name = dev_name(>dev);
- info->edev->supported_cable = max14577_extcon_cable;
+
ret = devm_extcon_dev_register(>dev, info->edev);
if (ret) {
dev_err(>dev, "failed to register extcon device\n");
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 8/9] extcon: gpio: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-gpio.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 43af34c..645b283 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -32,7 +32,7 @@
#include
struct gpio_extcon_data {
- struct extcon_dev edev;
+ struct extcon_dev *edev;
unsigned gpio;
bool gpio_active_low;
const char *state_on;
@@ -53,7 +53,7 @@ static void gpio_extcon_work(struct work_struct *work)
state = gpio_get_value(data->gpio);
if (data->gpio_active_low)
state = !state;
- extcon_set_state(>edev, state);
+ extcon_set_state(data->edev, state);
}
static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
@@ -67,9 +67,10 @@ static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
static ssize_t extcon_gpio_print_state(struct extcon_dev *edev, char *buf)
{
- struct gpio_extcon_data *extcon_data =
- container_of(edev, struct gpio_extcon_data, edev);
+ struct device *dev = edev->dev.parent;
+ struct gpio_extcon_data *extcon_data = dev_get_drvdata(dev);
const char *state;
+
if (extcon_get_state(edev))
state = extcon_data->state_on;
else
@@ -98,15 +99,21 @@ static int gpio_extcon_probe(struct platform_device *pdev)
if (!extcon_data)
return -ENOMEM;
- extcon_data->edev.name = pdata->name;
- extcon_data->edev.dev.parent = >dev;
+ extcon_data->edev = devm_extcon_dev_allocate(>dev, NULL);
+ if (IS_ERR(extcon_data->edev)) {
+ dev_err(>dev, "failed to allocate extcon device\n");
+ return -ENOMEM;
+ }
+ extcon_data->edev->name = pdata->name;
+ extcon_data->edev->dev.parent = >dev;
+
extcon_data->gpio = pdata->gpio;
extcon_data->gpio_active_low = pdata->gpio_active_low;
extcon_data->state_on = pdata->state_on;
extcon_data->state_off = pdata->state_off;
extcon_data->check_on_resume = pdata->check_on_resume;
if (pdata->state_on && pdata->state_off)
- extcon_data->edev.print_state = extcon_gpio_print_state;
+ extcon_data->edev->print_state = extcon_gpio_print_state;
ret = devm_gpio_request_one(>dev, extcon_data->gpio, GPIOF_DIR_IN,
pdev->name);
@@ -121,7 +128,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
msecs_to_jiffies(pdata->debounce);
}
- ret = devm_extcon_dev_register(>dev, _data->edev);
+ ret = devm_extcon_dev_register(>dev, extcon_data->edev);
if (ret < 0)
return ret;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 9/9] extcon: palmas: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Cc: Graeme Gregory
Cc: Kishon Vijay Abraham I
Cc: Felipe Balbi
Cc: Samuel Ortiz
Cc: Lee Jones
Signed-off-by: Chanwoo Choi
Acked-by: Lee Jones
Acked-by: Felipe Balbi
Tested-by: Felipe Balbi
---
drivers/extcon/extcon-palmas.c | 35 ---
include/linux/mfd/palmas.h | 2 +-
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 1a770e0..7417ce8 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -57,7 +57,7 @@ static irqreturn_t palmas_vbus_irq_handler(int irq, void
*_palmas_usb)
if (vbus_line_state & PALMAS_INT3_LINE_STATE_VBUS) {
if (palmas_usb->linkstat != PALMAS_USB_STATE_VBUS) {
palmas_usb->linkstat = PALMAS_USB_STATE_VBUS;
- extcon_set_cable_state(_usb->edev, "USB", true);
+ extcon_set_cable_state(palmas_usb->edev, "USB", true);
dev_info(palmas_usb->dev, "USB cable is attached\n");
} else {
dev_dbg(palmas_usb->dev,
@@ -66,7 +66,7 @@ static irqreturn_t palmas_vbus_irq_handler(int irq, void
*_palmas_usb)
} else if (!(vbus_line_state & PALMAS_INT3_LINE_STATE_VBUS)) {
if (palmas_usb->linkstat == PALMAS_USB_STATE_VBUS) {
palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
- extcon_set_cable_state(_usb->edev, "USB", false);
+ extcon_set_cable_state(palmas_usb->edev, "USB", false);
dev_info(palmas_usb->dev, "USB cable is detached\n");
} else {
dev_dbg(palmas_usb->dev,
@@ -93,7 +93,7 @@ static irqreturn_t palmas_id_irq_handler(int irq, void
*_palmas_usb)
PALMAS_USB_ID_INT_LATCH_CLR,
PALMAS_USB_ID_INT_EN_HI_CLR_ID_GND);
palmas_usb->linkstat = PALMAS_USB_STATE_ID;
- extcon_set_cable_state(_usb->edev, "USB-HOST", true);
+ extcon_set_cable_state(palmas_usb->edev, "USB-HOST", true);
dev_info(palmas_usb->dev, "USB-HOST cable is attached\n");
} else if ((set & PALMAS_USB_ID_INT_SRC_ID_FLOAT) &&
(id_src & PALMAS_USB_ID_INT_SRC_ID_FLOAT)) {
@@ -101,17 +101,17 @@ static irqreturn_t palmas_id_irq_handler(int irq, void
*_palmas_usb)
PALMAS_USB_ID_INT_LATCH_CLR,
PALMAS_USB_ID_INT_EN_HI_CLR_ID_FLOAT);
palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
- extcon_set_cable_state(_usb->edev, "USB-HOST", false);
+ extcon_set_cable_state(palmas_usb->edev, "USB-HOST", false);
dev_info(palmas_usb->dev, "USB-HOST cable is detached\n");
} else if ((palmas_usb->linkstat == PALMAS_USB_STATE_ID) &&
(!(set & PALMAS_USB_ID_INT_SRC_ID_GND))) {
palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
- extcon_set_cable_state(_usb->edev, "USB-HOST", false);
+ extcon_set_cable_state(palmas_usb->edev, "USB-HOST", false);
dev_info(palmas_usb->dev, "USB-HOST cable is detached\n");
} else if ((palmas_usb->linkstat == PALMAS_USB_STATE_DISCONNECT) &&
(id_src & PALMAS_USB_ID_INT_SRC_ID_GND)) {
palmas_usb->linkstat = PALMAS_USB_STATE_ID;
- extcon_set_cable_state(_usb->edev, "USB-HOST", true);
+ extcon_set_cable_state(palmas_usb->edev, "USB-HOST", true);
dev_info(palmas_usb->dev, " USB-HOST cable is attached\n");
}
@@ -187,15 +187,20 @@ static int palmas_usb_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, palmas_usb);
- palmas_usb->edev.supported_cable = palmas_extcon_cable;
- palmas_usb->edev.dev.parent = palmas_usb->dev;
- palmas_usb->edev.name = kstrdup(node->name, GFP_KERNEL);
- palmas_usb->edev.mutually_exclusive = mutually_exclusive;
+ palmas_usb->edev = devm_extcon_dev_allocate(>dev,
+ palmas_extcon_cable);
+ if (IS_ERR(palmas_usb->edev)) {
+ dev_err(>dev, "failed to allocate extcon device\n");
+ return -ENOMEM;
+ }
+ palmas_usb->edev->name = kstrdup(node->name, GFP_KERNEL);
+ palmas_usb->edev->dev.parent = palmas_usb->dev;
+ palmas_usb->edev->mutually_exclusive = mutually_exclusive;
- status = devm_extcon_dev_register(>dev, _usb->edev);
+ status = devm_extcon_dev_register(>dev, palmas_usb->edev);
if (status) {
dev_err(>dev, "failed to register extcon device\n");
- kfree(palmas_usb->edev.name);
+
[PATCHv4 6/9] extcon: arizona: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Cc: Charles Keepax
Cc: Mark Brown
Cc: patc...@opensource.wolfsonmicro.com
Signed-off-by: Chanwoo Choi
Acked-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index f63fa6f..6c84e3d 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -91,7 +91,7 @@ struct arizona_extcon_info {
int hpdet_ip;
- struct extcon_dev edev;
+ struct extcon_dev *edev;
};
static const struct arizona_micd_config micd_default_modes[] = {
@@ -546,7 +546,7 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
}
/* If the cable was removed while measuring ignore the result */
- ret = extcon_get_cable_state_(>edev, ARIZONA_CABLE_MECHANICAL);
+ ret = extcon_get_cable_state_(info->edev, ARIZONA_CABLE_MECHANICAL);
if (ret < 0) {
dev_err(arizona->dev, "Failed to check cable state: %d\n",
ret);
@@ -581,7 +581,7 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
else
report = ARIZONA_CABLE_HEADPHONE;
- ret = extcon_set_cable_state_(>edev, report, true);
+ ret = extcon_set_cable_state_(info->edev, report, true);
if (ret != 0)
dev_err(arizona->dev, "Failed to report HP/line: %d\n",
ret);
@@ -664,7 +664,7 @@ err:
ARIZONA_ACCDET_MODE_MASK, ARIZONA_ACCDET_MODE_MIC);
/* Just report headphone */
- ret = extcon_update_state(>edev,
+ ret = extcon_update_state(info->edev,
1 << ARIZONA_CABLE_HEADPHONE,
1 << ARIZONA_CABLE_HEADPHONE);
if (ret != 0)
@@ -723,7 +723,7 @@ err:
ARIZONA_ACCDET_MODE_MASK, ARIZONA_ACCDET_MODE_MIC);
/* Just report headphone */
- ret = extcon_update_state(>edev,
+ ret = extcon_update_state(info->edev,
1 << ARIZONA_CABLE_HEADPHONE,
1 << ARIZONA_CABLE_HEADPHONE);
if (ret != 0)
@@ -764,7 +764,7 @@ static void arizona_micd_detect(struct work_struct *work)
mutex_lock(>lock);
/* If the cable was removed while measuring ignore the result */
- ret = extcon_get_cable_state_(>edev, ARIZONA_CABLE_MECHANICAL);
+ ret = extcon_get_cable_state_(info->edev, ARIZONA_CABLE_MECHANICAL);
if (ret < 0) {
dev_err(arizona->dev, "Failed to check cable state: %d\n",
ret);
@@ -812,7 +812,7 @@ static void arizona_micd_detect(struct work_struct *work)
if (info->detecting && (val & ARIZONA_MICD_LVL_8)) {
arizona_identify_headphone(info);
- ret = extcon_update_state(>edev,
+ ret = extcon_update_state(info->edev,
1 << ARIZONA_CABLE_MICROPHONE,
1 << ARIZONA_CABLE_MICROPHONE);
@@ -999,7 +999,7 @@ static irqreturn_t arizona_jackdet(int irq, void *data)
if (info->last_jackdet == present) {
dev_dbg(arizona->dev, "Detected jack\n");
- ret = extcon_set_cable_state_(>edev,
+ ret = extcon_set_cable_state_(info->edev,
ARIZONA_CABLE_MECHANICAL, true);
if (ret != 0)
@@ -1038,7 +1038,7 @@ static irqreturn_t arizona_jackdet(int irq, void *data)
info->micd_ranges[i].key, 0);
input_sync(info->input);
- ret = extcon_update_state(>edev, 0x, 0);
+ ret = extcon_update_state(info->edev, 0x, 0);
if (ret != 0)
dev_err(arizona->dev, "Removal report failed: %d\n",
ret);
@@ -1150,11 +1150,15 @@ static int arizona_extcon_probe(struct platform_device
*pdev)
break;
}
- info->edev.name = "Headset Jack";
- info->edev.dev.parent = arizona->dev;
- info->edev.supported_cable = arizona_cable;
+ info->edev = devm_extcon_dev_allocate(>dev, arizona_cable);
+ if (IS_ERR(info->edev)) {
+ dev_err(>dev, "failed to allocate extcon device\n");
+ return -ENOMEM;
+ }
+ info->edev->name = "Headset Jack";
+ info->edev->dev.parent = arizona->dev;
- ret = devm_extcon_dev_register(>dev, >edev);
+ ret = devm_extcon_dev_register(>dev, info->edev);
if (ret < 0) {
dev_err(arizona->dev, "extcon_dev_register() failed: %d\n",
ret);
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe
[PATCHv4 0/9] extcon: Support devm_extcon_dev_allocate/free()
This patchset add devm_extcon_dev_allocate/free() for the resource management of extcon device. And devm_extcon_dev_allocate() handles all of supported cables. Changes from v3: - Change return value of extcon_dev_allocate()/devm_extcon_dev_allocate() if failed to allocate the memory of extcon device (NULL -> ERR_PTR(-ENOMEM)) - All of extcon provier drivers check return value using IS_ERR() macro - Fix the description of function due to changing return type if failure Changes from v2: - Resolve bisectable issue about patch-1 extcon: Add extcon_dev_allocate/free() to control the memory of extcon device - extcon_dev_allocate/free() don't handle all behaviors for supported cables Changes from v1: - Rebase it on latest extcon-next branch Chanwoo Choi (9): extcon: Add extcon_dev_allocate/free() to control the memory of extcon device extcon: Add devm_extcon_dev_allocate/free to manage the resource of extcon device extcon: max8997: Use devm_extcon_dev_allocate for extcon_dev extcon: max77693: Use devm_extcon_dev_allocate for extcon_dev extcon: max14577: Use devm_extcon_dev_allocate for extcon_dev extcon: arizona: Use devm_extcon_dev_allocate for extcon_dev extcon: adc-jack: Use devm_extcon_dev_allocate for extcon_dev extcon: gpio: Use devm_extcon_dev_allocate for extcon_dev extcon: palmas: Use devm_extcon_dev_allocate for extcon_dev drivers/extcon/extcon-adc-jack.c | 21 drivers/extcon/extcon-arizona.c | 30 ++- drivers/extcon/extcon-class.c| 108 ++- drivers/extcon/extcon-gpio.c | 23 ++--- drivers/extcon/extcon-max14577.c | 7 +-- drivers/extcon/extcon-max77693.c | 9 ++-- drivers/extcon/extcon-max8997.c | 7 ++- drivers/extcon/extcon-palmas.c | 35 +++-- include/linux/extcon.h | 24 + include/linux/mfd/palmas.h | 2 +- 10 files changed, 196 insertions(+), 70 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
