Re: [PATCH 0/8] mm: add page cache limit and reclaim feature
On 2014/6/16 20:50, Rafael Aquini wrote: > On Mon, Jun 16, 2014 at 01:14:22PM +0200, Michal Hocko wrote: >> On Mon 16-06-14 17:24:38, Xishi Qiu wrote: >>> When system(e.g. smart phone) running for a long time, the cache often takes >>> a large memory, maybe the free memory is less than 50M, then OOM will happen >>> if APP allocate a large order pages suddenly and memory reclaim too slowly. >> >> Have you ever seen this to happen? Page cache should be easy to reclaim and >> if there is too mach dirty memory then you should be able to tune the >> amount by dirty_bytes/ratio knob. If the page allocator falls back to >> OOM and there is a lot of page cache then I would call it a bug. I do >> not think that limiting the amount of the page cache globally makes >> sense. There are Unix systems which offer this feature but I think it is >> a bad interface which only papers over the reclaim inefficiency or lack >> of other isolations between loads. >> > +1 > > It would be good if you could show some numbers that serve as evidence > of your theory on "excessive" pagecache acting as a trigger to your > observed OOMs. I'm assuming, by your 'e.g', you're running a swapless > system, so I would think your system OOMs are due to inability to > reclaim anon memory, instead of pagecache. > Thank you for your reply. I'll try to find some examples in my company. > >>> Use "echo 3 > /proc/sys/vm/drop_caches" will drop the whole cache, this will >>> affect the performance, so it is used for debugging only. >>> > > If you are able to drop the whole pagecache by issuing the command > above, than it means the majority of it is just unmapped cache pages, > and those would be normally reclaimed upon demand by the PFRA. One more > thing that makes me wonder you're just seeing the effect of a leaky app > making the system unable to swap out anon pages. > I find the page cache will only be reclaimed when there is not enough memory. And in some smart phones, there is no swap disk. So I add a parameter to reclaim in circles. Thanks, Xishi Qiu > >>> suse has this feature, I tested it before, but it can not limit the page >>> cache >>> actually. So I rewrite the feature and add some parameters. >> >> The feature is there for historic reasons and I _really_ think the >> interface is not appropriate. If there is a big pagecache usage which >> affects other loads then Memory cgroup controller can be used to help >> from interference. >> >>> Christoph Lameter has written a patch "Limit the size of the pagecache" >>> http://marc.info/?l=linux-mm=116959990228182=2 >>> It changes in zone fallback, this is not a good way. >>> >>> The patchset is based on v3.15, it introduces two features, page cache limit >>> and page cache reclaim in circles. >>> >>> Add four parameters in /proc/sys/vm >>> >>> 1) cache_limit_mbytes >>> This is used to limit page cache amount. >>> The input unit is MB, value range is from 0 to totalram_pages. >>> If this is set to 0, it will not limit page cache. >>> When written to the file, cache_limit_ratio will be updated too. >>> The default value is 0. >>> >>> 2) cache_limit_ratio >>> This is used to limit page cache amount. >>> The input unit is percent, value range is from 0 to 100. >>> If this is set to 0, it will not limit page cache. >>> When written to the file, cache_limit_mbytes will be updated too. >>> The default value is 0. >>> >>> 3) cache_reclaim_s >>> This is used to reclaim page cache in circles. >>> The input unit is second, the minimum value is 0. >>> If this is set to 0, it will disable the feature. >>> The default value is 0. >>> >>> 4) cache_reclaim_weight >>> This is used to speed up page cache reclaim. >>> It depend on enabling cache_limit_mbytes/cache_limit_ratio or >>> cache_reclaim_s. >>> Value range is from 1(slow) to 100(fast). >>> The default value is 1. >>> >>> I tested the two features on my system(x86_64), it seems to work right. >>> However, as it changes the hot path "add_to_page_cache_lru()", I don't know >>> how much it will the affect the performance, maybe there are some errors >>> in the patches too, RFC. >> >> I haven't looked at patches yet but you would need to explain why the >> feature is needed much better and why the existing features are not >> sufficient. >> -- >> Michal Hocko >> SUSE Labs > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lib: add size unit t/p/e to memparse
On Tue, 17 Jun 2014, Gui Hecheng wrote:
> > > diff --git a/lib/cmdline.c b/lib/cmdline.c
> > > index d4932f7..76a712e 100644
> > > --- a/lib/cmdline.c
> > > +++ b/lib/cmdline.c
> > > @@ -121,11 +121,7 @@ EXPORT_SYMBOL(get_options);
> > > * @retptr: (output) Optional pointer to next char after parse
> > > completes
> > > *
> > > * Parses a string into a number. The number stored at @ptr is
> > > - * potentially suffixed with %K (for kilobytes, or 1024 bytes),
> > > - * %M (for megabytes, or 1048576 bytes), or %G (for gigabytes, or
> > > - * 1073741824). If the number is suffixed with K, M, or G, then
> > > - * the return value is the number multiplied by one kilobyte, one
> > > - * megabyte, or one gigabyte, respectively.
> > > + * potentially suffixed with K, M, G, T, P, E.
> > > */
> > >
> > > unsigned long long memparse(const char *ptr, char **retptr)
> > > @@ -135,6 +131,15 @@ unsigned long long memparse(const char *ptr, char
> > > **retptr)
> > > unsigned long long ret = simple_strtoull(ptr, , 0);
> > >
> > > switch (*endptr) {
> > > + case 'E':
> > > + case 'e':
> > > + ret <<= 10;
> > > + case 'P':
> > > + case 'p':
> > > + ret <<= 10;
> > > + case 'T':
> > > + case 't':
> > > + ret <<= 10;
> > > case 'G':
> > > case 'g':
> > > ret <<= 10;
> >
> > Seems fine since unsigned long long is always at least 64 bits, but
> > perhaps also change simple_strtoull() to use kstrtoull() at the same time
> > since the former is deprecated?
>
> Yes, that is a point. But the deprecated function is a separate problem
> and may not be included in this patch.
> Also, I find that simple_strtoull is used in many places in the kernel
> code, it is better to replace it globally?
>
If you're going to have a go at replacing the simple_strto*() functions
throughout the kernel, it's probably better to do it per subsystem (as
defined by the separate sections of MAINTAINERS) and propose the patches
individually to those maintainers. Once it has been removed entirely, you
can submit a patch to remove the functions themselves.
Be aware that there are many callers to the deprecated functions so it may
take a significant amount of time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 -next 1/9] DMA, CMA: fix possible memory leak
On Mon, Jun 16, 2014 at 03:27:19PM +0900, Minchan Kim wrote: > Hi, Joonsoo > > On Mon, Jun 16, 2014 at 02:40:43PM +0900, Joonsoo Kim wrote: > > We should free memory for bitmap when we find zone mis-match, > > otherwise this memory will leak. > > > > Additionally, I copy code comment from PPC KVM's CMA code to inform > > why we need to check zone mis-match. > > > > * Note > > Minchan suggested to add a tag for the stable, but, I don't do it, > > because I found this possibility during code-review and, IMO, > > this patch isn't suitable for stable tree. > > Nice idea to put the comment in here. Thanks Joonsoo. > > It seems you obey "It must fix a real bug that bothers people" > on Documentation/stable_kernel_rules.txt but it's a really obvious > bug and hard to get a report from people because limited user and > hard to detect small such small memory leak. > > In my experince, Andrew perfered stable marking for such a obvious > problem but simple fix like this but not sure so let's pass the decision > to him and will learn a lesson from him and will follow the decision > from now on. Yes, I intended to pass the decision to others. :) > > Thanks. > > Acked-by: Minchan Kim 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] ACPI/Battery: Retry to get Battery information if failed during probing
On 2014年06月17日 09:27, David Rientjes wrote:
> On Mon, 16 Jun 2014, Lan Tianyu wrote:
>
How about this?
- result = acpi_battery_update(battery, false);
- if (result)
+
+ /*
+* Some machines'(E,G Lenovo Z480) ECs are not stable
+* during boot up and this causes battery driver fails to be
+* probed due to failure of getting battery information
+* from EC sometimes. After several retries, the operation
+* may work. So add retry code here and 20ms sleep between
+* every retries.
+*/
+ while (acpi_battery_update(battery, false) && retry--)
+ msleep(20);
+ if (!retry) {
+ result = -ENODEV;
goto fail;
+ }
+
>>>
>>> I think you want --retry and not retry--.
>>
>> My original purpose is to retry 5 times after the first try fails.
>> If use "--retry" here, it just retries 4 times.
>>
>>> Otherwise it's possible for the
>>> final call to acpi_battery_update() to succeed and now it's returning
>>> -ENODEV.
>>>
>>
>> Yes, it maybe and I will change code like the following.
>>
>> while ((result = acpi_battery_update(battery, false)) && retry--)
>>msleep(20);
>> if (result)
>>goto fail;
>>
>
> Looks good.
>
Great. Thanks for review. :)
--
Best regards
Tianyu Lan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI/Battery: Retry to get Battery information if failed during probing
On Mon, 16 Jun 2014, Lan Tianyu wrote:
> >> How about this?
> >>
> >> - result = acpi_battery_update(battery, false);
> >> - if (result)
> >> +
> >> + /*
> >> +* Some machines'(E,G Lenovo Z480) ECs are not stable
> >> +* during boot up and this causes battery driver fails to be
> >> +* probed due to failure of getting battery information
> >> +* from EC sometimes. After several retries, the operation
> >> +* may work. So add retry code here and 20ms sleep between
> >> +* every retries.
> >> +*/
> >> + while (acpi_battery_update(battery, false) && retry--)
> >> + msleep(20);
> >> + if (!retry) {
> >> + result = -ENODEV;
> >> goto fail;
> >> + }
> >> +
> >
> > I think you want --retry and not retry--.
>
> My original purpose is to retry 5 times after the first try fails.
> If use "--retry" here, it just retries 4 times.
>
> > Otherwise it's possible for the
> > final call to acpi_battery_update() to succeed and now it's returning
> > -ENODEV.
> >
>
> Yes, it maybe and I will change code like the following.
>
> while ((result = acpi_battery_update(battery, false)) && retry--)
>msleep(20);
> if (result)
>goto fail;
>
Looks good.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] workqueue: use "pool->cpu < 0" to stand for an unbound pool
Hi, Tejun 3.16-rc1 came out. Could you review the patches? Thanks, Lai On 06/03/2014 03:31 PM, Lai Jiangshan wrote: > There is a piece of sanity checks code in the put_unbound_pool(). > The meaning of this code is "if it is not an unbound pool, it will complain > and return" IIUC. But the code uses "pool->flags & POOL_DISASSOCIATED" > imprecisely due to a non-unbound pool may also have this flags. > > We should use "pool->cpu < 0" to stand for an unbound pool, so we covert the > code to it. > > There is no strictly wrong if we still keep "pool->flags & POOL_DISASSOCIATED" > here, but it is just a noise if we keep it: > 1) we focus on "unbound" here, not "[dis]association". > 2) "pool->cpu < 0" already implies "pool->flags & POOL_DISASSOCIATED". > > Signed-off-by: Lai Jiangshan > --- > kernel/workqueue.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/kernel/workqueue.c b/kernel/workqueue.c > index 90a0fa5..724ae35 100644 > --- a/kernel/workqueue.c > +++ b/kernel/workqueue.c > @@ -3457,7 +3457,7 @@ static void put_unbound_pool(struct worker_pool *pool) > return; > > /* sanity checks */ > - if (WARN_ON(!(pool->flags & POOL_DISASSOCIATED)) || > + if (WARN_ON(!(pool->cpu < 0)) || > WARN_ON(!list_empty(>worklist))) > return; > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] lib: add size unit t/p/e to memparse
On Fri, 2014-06-13 at 14:58 -0700, David Rientjes wrote:
> On Fri, 13 Jun 2014, Gui Hecheng wrote:
>
> > diff --git a/lib/cmdline.c b/lib/cmdline.c
> > index d4932f7..76a712e 100644
> > --- a/lib/cmdline.c
> > +++ b/lib/cmdline.c
> > @@ -121,11 +121,7 @@ EXPORT_SYMBOL(get_options);
> > * @retptr: (output) Optional pointer to next char after parse completes
> > *
> > * Parses a string into a number. The number stored at @ptr is
> > - * potentially suffixed with %K (for kilobytes, or 1024 bytes),
> > - * %M (for megabytes, or 1048576 bytes), or %G (for gigabytes, or
> > - * 1073741824). If the number is suffixed with K, M, or G, then
> > - * the return value is the number multiplied by one kilobyte, one
> > - * megabyte, or one gigabyte, respectively.
> > + * potentially suffixed with K, M, G, T, P, E.
> > */
> >
> > unsigned long long memparse(const char *ptr, char **retptr)
> > @@ -135,6 +131,15 @@ unsigned long long memparse(const char *ptr, char
> > **retptr)
> > unsigned long long ret = simple_strtoull(ptr, , 0);
> >
> > switch (*endptr) {
> > + case 'E':
> > + case 'e':
> > + ret <<= 10;
> > + case 'P':
> > + case 'p':
> > + ret <<= 10;
> > + case 'T':
> > + case 't':
> > + ret <<= 10;
> > case 'G':
> > case 'g':
> > ret <<= 10;
>
> Seems fine since unsigned long long is always at least 64 bits, but
> perhaps also change simple_strtoull() to use kstrtoull() at the same time
> since the former is deprecated?
Yes, that is a point. But the deprecated function is a separate problem
and may not be included in this patch.
Also, I find that simple_strtoull is used in many places in the kernel
code, it is better to replace it globally?
-Gui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build warning after merge of the nfs tree
Hi Trond,
After merging the nfs tree, today's linux-next build (powerpc
ppc44x_defconfig and probably others) produced this warning:
fs/nfs/pagelist.c: In function 'nfs_initiate_pgio':
fs/nfs/pagelist.c:555:16: warning: unused variable 'inode' [-Wunused-variable]
struct inode *inode = hdr->inode;
^
Introduced by commit 30e4c73543b0 ("nfs: merge nfs_pgio_data into
_header").
"inode" is only used in a dprintk().
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH] ARM: Thumb-2: Fix out-of-range offset for Thumb-2 in, proc-macros.S
On 2014/6/16 21:49, Will Deacon wrote:
> On Tue, Jun 10, 2014 at 08:00:01AM +0100, Wang Weidong wrote:
>> The STR Instruction Encoding T4 points that the is in the
>> range 0-255.So split the instruction into two for Thumb-2. Just
>> like commit 874d5d3ccc("ARM: 6623/1: Thumb-2: Fix out-of-range
>> offset for Thumb-2 in proc-v7.S").
>>
>> Signed-off-by: Wang Weidong
>> ---
>> arch/arm/mm/proc-macros.S | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
>> index ee1d805..63f710c 100644
>> --- a/arch/arm/mm/proc-macros.S
>> +++ b/arch/arm/mm/proc-macros.S
>> @@ -252,7 +252,9 @@
>> tst r3, #L_PTE_PRESENT | L_PTE_YOUNG@ present and young?
>> movne r2, #0 @ no -> fault
>>
>> -str r2, [r0, #2048]!@ hardware version
>> + ARM( str r2, [r0, #2048]!) @ hardware version
>> + THUMB( add r0, r0, #2048 )
>> + THUMB( str r2, [r0])
>> mov ip, #0
>> mcr p15, 0, r0, c7, c10, 1 @ clean L1 D line
>> mcr p15, 0, ip, c7, c10, 4 @ data write barrier
>
> AFAICT this is in xscale_set_pte_ext_epilogue which should only be built as
> ARM. Are you seeing a real issue here?
>
> Will
>
Hi will,
I don't see any issue here. I just review the codes while I learn thumb-2.
It does only build as ARM, so ignore it.
Regards
Wang
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: Fix build warning
On Fri, 13 Jun 2014, Guenter Roeck wrote: > If compiled with W=1, the following warning is seen in arm builds. > > arch/arm/kernel/topology.c:278:25: warning: > type qualifiers ignored on function return type > > This is caused by a function returning 'const int', which doesn't > make sense to gcc. Drop 'const' to fix the problem. > > Reported-by: Vincent Guittot > Signed-off-by: Guenter Roeck Acked-by: David Rientjes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc: Fix build warning
On Fri, 13 Jun 2014, Guenter Roeck wrote:
> If compiled with W=1, the following warning is seen in powerpc builds.
>
> arch/powerpc/kernel/smp.c:750:18: warning:
> type qualifiers ignored on function return type
> static const int powerpc_smt_flags(void)
> ^
>
> This is caused by a function returning 'const int', which doesn't
> make sense to gcc. Drop 'const' to fix the problem.
>
> Reported-by: Vincent Guittot
> Signed-off-by: Guenter Roeck
Acked-by: David Rientjes
Although it's strange you report this happening on line 750 in the
changelog but the patch shows it differently.
> ---
> arch/powerpc/kernel/smp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 10e..49d5d4e 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -768,7 +768,7 @@ int setup_profiling_timer(unsigned int multiplier)
>
> #ifdef CONFIG_SCHED_SMT
> /* cpumask of CPUs with asymetric SMT dependancy */
> -static const int powerpc_smt_flags(void)
> +static int powerpc_smt_flags(void)
> {
> int flags = SD_SHARE_CPUPOWER | SD_SHARE_PKG_RESOURCES;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Check for Null return from logfs_readpage_nolock in btree_write_block
On Mon, 16 June 2014 20:46:32 -0400, Nick Krause wrote: > > You are right about the compile errors it compiles but with warning. > I am curious since the function is void how do you want me to > give the error back to logfs and in turn the other subsystems > of the kernel. My first question would be: What is the problem? If there is no problem, don't try to fix it. If there is a problem, your fix should contain a decent description of the problem as part of the commit message. Even if the patch itself ends up being bad, having a good problem description with a first stab at a fix serves as a useful bug report. Jörn -- Was there any time in human history where democratic forms continued when the citizens could not credibly defend their rights? -- Daniel Suarez -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] doc: update Documentation/sysctl/vm.txt
On 2014/6/17 0:57, Randy Dunlap wrote: > On 06/16/14 02:25, Xishi Qiu wrote: >> Update the doc. >> >> Signed-off-by: Xishi Qiu >> --- >> Documentation/sysctl/vm.txt | 43 >> +++ >> 1 files changed, 43 insertions(+), 0 deletions(-) >> >> diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt >> index dd9d0e3..8008e53 100644 >> --- a/Documentation/sysctl/vm.txt >> +++ b/Documentation/sysctl/vm.txt >> @@ -20,6 +20,10 @@ Currently, these files are in /proc/sys/vm: >> >> - admin_reserve_kbytes >> - block_dump >> +- cache_limit_mbytes >> +- cache_limit_ratio >> +- cache_reclaim_s >> +- cache_reclaim_weight >> - compact_memory >> - dirty_background_bytes >> - dirty_background_ratio >> @@ -97,6 +101,45 @@ information on block I/O debugging is in >> Documentation/laptops/laptop-mode.txt. >> >> == >> >> +cache_limit_mbytes >> + >> +This is used to limit page cache amount. The input unit is MB, value range >> +is from 0 to totalram_pages. If this is set to 0, it will not limit page >> cache. > > Where does one find the value of totalram_pages? > "cat /proc/meminfo | grep MemTotal" or "free -m" > Is totalram_pages in MB or does totalram_pages need to be divided by some > value > to convert it to MB? > Yes, should convert it to MB. Thanks, Xishi Qiu >> +When written to the file, cache_limit_ratio will be updated too. >> + >> +The default value is 0. >> + >> +== >> + >> +cache_limit_ratio >> + >> +This is used to limit page cache amount. The input unit is percent, value >> +range is from 0 to 100. If this is set to 0, it will not limit page cache. >> +When written to the file, cache_limit_mbytes will be updated too. >> + >> +The default value is 0. >> + >> +== >> + >> +cache_reclaim_s >> + >> +This is used to reclaim page cache in circles. The input unit is second, >> +the minimum value is 0. If this is set to 0, it will disable the feature. >> + >> +The default value is 0. >> + >> +== >> + >> +cache_reclaim_weight >> + >> +This is used to speed up page cache reclaim. It depend on enabling > >depends on > >> +cache_limit_mbytes/cache_limit_ratio or cache_reclaim_s. Value range is >> +from 1(slow) to 100(fast). >> + >> +The default value is 1. >> + >> +== >> + >> compact_memory >> >> Available only when CONFIG_COMPACTION is set. When 1 is written to the file, >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] spin_lock_*(): Always evaluate second argument
On Mon, 16 Jun 2014, Bart Van Assche wrote: > Evaluating a macro argument only if certain configuration options > have been selected is confusing and error-prone. Hence always > evaluate the second argument of spin_lock_nested() and > spin_lock_nest_lock(). > > This patch has the intentional side effect that it avoids that the > following warning is reported for netif_addr_lock_nested() when > building with CONFIG_DEBUG_LOCK_ALLOC=n and with W=1: > > include/linux/netdevice.h: In function 'netif_addr_lock_nested': > include/linux/netdevice.h:2865:6: warning: variable 'subclass' set but not > used [-Wunused-but-set-variable] > int subclass = SINGLE_DEPTH_NESTING; > ^ > > Signed-off-by: Bart Van Assche > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: David S. Miller Acked-by: David Rientjes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next 0/9] CMA: generalize CMA reserved area management code
On Mon, Jun 16, 2014 at 11:11:35AM +0200, Marek Szyprowski wrote: > Hello, > > On 2014-06-16 07:40, Joonsoo Kim wrote: > >Currently, there are two users on CMA functionality, one is the DMA > >subsystem and the other is the KVM on powerpc. They have their own code > >to manage CMA reserved area even if they looks really similar. > >>From my guess, it is caused by some needs on bitmap management. Kvm side > >wants to maintain bitmap not for 1 page, but for more size. Eventually it > >use bitmap where one bit represents 64 pages. > > > >When I implement CMA related patches, I should change those two places > >to apply my change and it seem to be painful to me. I want to change > >this situation and reduce future code management overhead through > >this patch. > > > >This change could also help developer who want to use CMA in their > >new feature development, since they can use CMA easily without > >copying & pasting this reserved area management code. > > > >v3: > > - Simplify old patch 1(log format fix) and move it to the end of patchset. > > - Patch 2: Pass aligned base and size to dma_contiguous_early_fixup() > > - Patch 5: Add some accessor functions to pass aligned base and size to > > dma_contiguous_early_fixup() function > > - Patch 5: Move MAX_CMA_AREAS definition to cma.h > > - Patch 6: Add CMA region zeroing to PPC KVM's CMA alloc function > > - Patch 8: put 'base' ahead of 'size' in cma_declare_contiguous() > > - Remaining minor fixes are noted in commit description of each one > > > >v2: > > - Although this patchset looks very different with v1, the end result, > > that is, mm/cma.c is same with v1's one. So I carry Ack to patch 6-7. > > > >This patchset is based on linux-next 20140610. > > Thanks for taking care of this. I will test it with my setup and if > everything goes well, I will take it to my -next tree. If any branch > is required for anyone to continue his works on top of those patches, > let me know, I will also prepare it. Hello, I'm glad to hear that. :) But, there is one concern. As you already know, I am preparing further patches (Aggressively allocate the pages on CMA reserved memory). It may be highly related to MM branch and also slightly depends on this CMA changes. In this case, what is the best strategy to merge this patchset? IMHO, Anrew's tree is more appropriate branch. If there is no issue in this case, I am willing to develope further patches based on your tree. 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/
[no subject]
-- Greetings in the Name of Our Lord, I have a charity proposal for you, reply back for more information. Thanks and God bless, Gina Rinehart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] slab: fix oops when reading /proc/slab_allocators
commit 'b1cb098: change the management method of free objects of the slab'
introduces bug on slab leak detector('/proc/slab_allocators'). This
detector works like as following decription.
1. traverse all objects on all the slabs.
2. determine whether it is active or not.
3. if active, print who allocate this object.
commit 'b1cb098' changes the way how to manage free objects, so logic
determining whether it is active or not is also changed. In before, we
regard object in cpu caches as inactive one, but, with this commit, we
mistakenly regard object in cpu caches as active one.
This intoduces kernel oops if DEBUG_PAGEALLOC is enabled.
If DEBUG_PAGEALLOC is enabled, kernel_map_pages() is used to detect
who corrupt free memory in the slab. It unmaps page table mapping if
object is free and map it if object is active. When slab leak detector
check object in cpu caches, it mistakenly think this object active so
try to access object memory to retrieve caller of allocation. At this
point, page table mapping to this object doesn't exist, so oops occurs.
Following is oops message reported from Dave.
It blew up when something tried to read /proc/slab_allocators
(Just cat it, and you should see the oops below)
Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
[snip...]
CPU: 1 PID: 9386 Comm: trinity-c33 Not tainted 3.14.0-rc5+ #131
task: 8801aa46e890 ti: 880076924000 task.ti: 880076924000
RIP: 0010:[] [] handle_slab+0x8a/0x180
RSP: 0018:880076925de0 EFLAGS: 00010002
RAX: 1000 RBX: RCX: 5ce85ce7
RDX: ea00079be100 RSI: 1000 RDI: 880107458000
RBP: 880076925e18 R08: 0001 R09:
R10: R11: 000f R12: 8801e6f84000
R13: ea00079be100 R14: 880107458000 R15: 88022bb8d2c0
FS: 7fb769e45740() GS:88024d04() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 8801e6f84ff8 CR3: a22db000 CR4: 001407e0
DR0: 02695000 DR1: 02695000 DR2:
DR3: DR6: fffe0ff0 DR7: 00070602
Stack:
8802339dcfc0 88022bb8d2c0 880107458000 88022bb8d2c0
8802339dd008 8802339dcfc0 ea00079be100 880076925e68
aa1ad9be 880203fe4f00 88022bb8d318 76925e98
Call Trace:
[] leaks_show+0xce/0x240
[] seq_read+0x28e/0x490
[] proc_reg_read+0x3d/0x80
[] vfs_read+0x9b/0x160
[] SyS_read+0x58/0xb0
[] tracesys+0xd4/0xd9
Code: f5 00 00 00 0f 1f 44 00 00 48 63 c8 44 3b 0c 8a 0f 84 e3 00 00 00 83 c0
01 44 39 c0 72 eb 41 f6 47 1a 01 0f 84 e9 00 00 00 89 f0 <4d> 8b 4c 04 f8 4d 85
c9 0f 84 88 00 00 00 49 8b 7e 08 4d 8d 46
RIP [] handle_slab+0x8a/0x180
RSP
CR2: 8801e6f84ff8
To fix the problem, I introduces object status buffer on each slab.
With this, we can track object status precisely, so slab leak detector
would not access active object and no kernel oops would occur.
Memory overhead caused by this fix is only imposed to
CONFIG_DEBUG_SLAB_LEAK which is mainly used for debugging, so memory
overhead isn't big problem.
Cc:
Reported-by: Dave Jones
Reported-by: Tetsuo Handa
Signed-off-by: Joonsoo Kim
---
Hello,
Please review this one. :)
There was some bug reports on this issue 2~3 month ago, and,
at that time, I sent the patch to fix the problem, but didn't get review.
So this issue is pending until now.
https://lkml.org/lkml/2014/4/9/191
https://lkml.org/lkml/2014/4/15/727
If possible, I'd like to merge this fix first rather than other slab
related patches.
Thanks.
diff --git a/mm/slab.c b/mm/slab.c
index 9ca3b87..cac4d74 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -386,6 +386,39 @@ static void **dbg_userword(struct kmem_cache *cachep, void
*objp)
#endif
+#define OBJECT_FREE (0)
+#define OBJECT_ACTIVE (1)
+
+#ifdef CONFIG_DEBUG_SLAB_LEAK
+
+static void set_obj_status(struct page *page, int idx, int val)
+{
+ int freelist_size;
+ char *status;
+ struct kmem_cache *cachep = page->slab_cache;
+
+ freelist_size = cachep->num * sizeof(freelist_idx_t);
+ status = (char *)page->freelist + freelist_size;
+ status[idx] = val;
+}
+
+static inline unsigned int get_obj_status(struct page *page, int idx)
+{
+ int freelist_size;
+ char *status;
+ struct kmem_cache *cachep = page->slab_cache;
+
+ freelist_size = cachep->num * sizeof(freelist_idx_t);
+ status = (char *)page->freelist + freelist_size;
+
+ return status[idx];
+}
+
+#else
+static inline void set_obj_status(struct page *page, int idx, int val) {}
+
+#endif
+
/*
* Do not go above this order unless 0 objects fit into the slab or
* overridden on the command line.
@@ -576,12 +609,30 @@ static inline struct array_cache *cpu_cache_get(struct
kmem_cache *cachep)
return cachep->array[smp_processor_id()];
}
+static
Re: [PATCH 1/2] mfd: rtsx: add dma transfer function
On 06/16/2014 08:20 PM, Lee Jones wrote: I don't see any glaring issues with this patch. Does it rely on the first patch, or vise versa, or can it just be applied? Hi Jones, [PATCH 2/2] need function defined in [PATCH 1/2]， so we provide interface in [mfd] and called in [mmc]. Best Regards. micky. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] hugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned entry
On Mon, 16 Jun 2014, Naoya Horiguchi wrote: > On Sun, Jun 15, 2014 at 05:19:29PM -0700, Hugh Dickins wrote: > > > > Hold on, that restriction of hugepage migration was marked for stable > > 3.12+, whereas this is marked for stable 2.6.36+ (a glance at my old > > trees suggests 2.6.37+, but you may know better - perhaps hugepage > > migration got backported to 2.6.36-stable, though hardly seems > > stable material). > > Sorry, I misinterpreted one thing. > I thought hugepage migration was merged at 2.6.36 because git-describe > shows v2.6.36-rc7-73-g290408d4a2 for commit 290408d4a2 "hugetlb: hugepage > migration core." But actually that's merged at commit f1ebdd60cc, or > v2.6.36-5792-gf1ebdd60cc73. So this is 2.6.37 stuff. > > Originally hugepage migration was used only for soft offlining in > mm/memory-failure.c which is available only in x86_64, so we implicitly > assumed that hugepage migration was restricted to x86_64. > At 3.12, hugepage migration became available for numa APIs like mbind(), > which are used for other architectures, so the restriction with > hugepage_migration_supported() became necessary since then. > This is the reason why the disablement was marked for 3.12+. > This patch are helpful before extension in 3.12, so it should be marked > 2.6.37+. That all makes sense to me now: thanks a lot for explaining the history. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mmc: rtsx: add support for async request
On 06/16/2014 08:40 PM, Ulf Hansson wrote:
On 16 June 2014 11:09, micky wrote:
On 06/16/2014 04:42 PM, Ulf Hansson wrote:
@@ -36,7 +37,10 @@ struct realtek_pci_sdmmc {
struct rtsx_pcr *pcr;
struct mmc_host *mmc;
struct mmc_request *mrq;
+ struct workqueue_struct *workq;
+#define SDMMC_WORKQ_NAME "rtsx_pci_sdmmc_workq"
+ struct work_struct work;
I am trying to understand why you need a work/workqueue to implement
this feature. Is that really the case?
Could you elaborate on the reasons?
Hi Uffe,
we need return as fast as possible in mmc_host_ops request(ops->request)
callback,
so the mmc core can continue handle next request.
when next request everything is ready, it will wait previous done(if not
done),
then call ops->request().
we can't use atomic context, because we use mutex_lock() to protect
ops->request should never executed in atomic context. Is that your concern?
Yes.
resource, and we have to hold the lock during handle request.
So I use workq, we just queue a work and return in ops->request(),
The mmc core can continue without blocking at ops->request().
Best Regards.
micky.
Kind regards
Uffe
.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/11] qspinlock: Paravirt support
I am resending it as my original reply has some HTML code & hence
rejected by the mailing lists.
On 06/15/2014 08:47 AM, Peter Zijlstra wrote:
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+
+/*
+ * Write a comment about how all this works...
+ */
+
+#define _Q_LOCKED_SLOW (2U<< _Q_LOCKED_OFFSET)
+
+struct pv_node {
+ struct mcs_spinlock mcs;
+ struct mcs_spinlock __offset[3];
+ int cpu, head;
+};
I am wondering why you need the separate cpu and head variables. I
thought one will be enough here. The wait code put the cpu number in
head, the the kick_cpu code kick the one in cpu which is just the cpu #
of the tail.
+
+#define INVALID_HEAD -1
+#define NO_HEADnr_cpu_ids
+
I think it is better to use a constant like -2 for NO_HEAD instead of an
external variable.
+void __pv_init_node(struct mcs_spinlock *node)
+{
+ struct pv_node *pn = (struct pv_node *)node;
+
+ BUILD_BUG_ON(sizeof(struct pv_node)> 5*sizeof(struct mcs_spinlock));
+
+ pn->cpu = smp_processor_id();
+ pn->head = INVALID_HEAD;
+}
+
+static inline struct pv_node *pv_decode_tail(u32 tail)
+{
+ return (struct pv_node *)decode_tail(tail);
+}
+
+void __pv_link_and_wait_node(u32 old, struct mcs_spinlock *node)
+{
+ struct pv_node *ppn, *pn = (struct pv_node *)node;
+ unsigned int count;
+
+ if (!(old& _Q_TAIL_MASK)) {
+ pn->head = NO_HEAD;
+ return;
+ }
+
+ ppn = pv_decode_tail(old);
+ ACCESS_ONCE(ppn->mcs.next) = node;
+
+ while (ppn->head == INVALID_HEAD)
+ cpu_relax();
+
+ pn->head = ppn->head;
A race can happen here as pn->head can be changed to the head cpu by the
head waiter while being changed by this function at the same time. It is
safer to use cmpxchg to make sure that there is no accidental
overwriting of the head CPU number.
+
+ for (;;) {
+ count = SPIN_THRESHOLD;
+
+ do {
+ if (smp_load_acquire(>locked))
+ return;
+
+ cpu_relax();
+ } while (--count);
+
+ pv_wait(>locked, 1);
+ }
+}
+
+void __pv_kick_node(struct mcs_spinlock *node)
+{
+ struct pv_node *pn = (struct pv_node *)node;
+
+ pv_kick(pn->cpu);
+}
+
+void __pv_wait_head(struct qspinlock *lock)
+{
+ unsigned int count;
+ struct pv_node *pn;
+ int val, old, new;
+
+ for (;;) {
+ count = SPIN_THRESHOLD;
+
+ do {
+ val = smp_load_acquire(>val.counter);
+ if (!(val& _Q_LOCKED_PENDING_MASK))
+ return;
+ } while (--count);
+
+ do {
+ pn = pv_decode_tail(atomic_read(>val));
+
+ while (pn->head == INVALID_HEAD)
+ cpu_relax();
+
+ pn->head = smp_processor_id();
+
+ } while (pn != pv_decode_tail(atomic_read(>val)));
+
+ /*
+* Set _Q_LOCKED_SLOW; bail when the lock is free.
+*/
+ val = atomic_read(>val);
+ for (;;) {
+ if (!(val& _Q_LOCKED_PENDING_MASK))
+ return;
+ new = val | _Q_LOCKED_SLOW;
+ old = atomic_cmpxchg(>val, val, new);
+ if (old == val)
+ break;
+ val = old;
+ }
+
+ /* XXX 16bit would be better */
+ pv_wait(>val.counter, new);
+ }
+}
+
+static void ___pv_kick_head(struct qspinlock *lock)
+{
+ struct pv_node *pn;
+
+ pn = pv_decode_tail(atomic_read(>val));
+
+ while (pn->head == INVALID_HEAD)
+ cpu_relax();
+
+ if (WARN_ON_ONCE(pn->head == NO_HEAD))
+ return;
+
+ pv_kick(pn->head);
+}
+
+void __pv_queue_unlock(struct qspinlock *lock)
+{
+ int val = atomic_read(>val);
+
+ native_queue_unlock(lock);
+
+ if (val& _Q_LOCKED_SLOW)
+ ___pv_kick_head(lock);
+}
+
Again a race can happen here between the reading and writing of the lock
value. I can't think of a good way to do that without using cmpxchg.
+#else
+
+static inline void pv_init_node(struct mcs_spinlock *node) { }
+static inline void pv_link_and_wait_node(u32 old, struct mcs_spinlock *node) {
}
+static inline void pv_kick_node(struct mcs_spinlock *node) { }
+
+static inline void pv_wait_head(struct qspinlock *lock) { }
+
+#endif
+
/**
* queue_spin_lock_slowpath - acquire the queue spinlock
* @lock: Pointer to queue spinlock structure
@@ -247,6 +417,9 @@ void queue_spin_lock_slowpath(struct qsp
BUILD_BUG_ON(CONFIG_NR_CPUS>= (1U<< _Q_TAIL_CPU_BITS));
+ if (pv_enabled())
+ goto queue;
+
if
Re: [RFC PATCH 2/2] block: virtio-blk: support multi virt queues per virtio-blk device
Ming Lei writes: > + if (virtio_has_feature(vdev, VIRTIO_BLK_F_MQ)) > + err = virtio_cread_feature(vdev, VIRTIO_BLK_F_MQ, > +struct virtio_blk_config, num_queues, > +_vqs); > + else > + num_vqs = 1; This is redundant: virtio_cread_feature() checks the feature. So, either: if (virtio_has_feature(vdev, VIRTIO_BLK_F_MQ)) virtio_cread(vdev, struct virtio_blk_config, num_queues, _vqs); else num_vqs = 1; Or: err = virtio_cread_feature(vdev, VIRTIO_BLK_F_MQ, struct virtio_blk_config, num_queues, _vqs); if (err) num_vqs = 1; Otherwise, the patch looks pretty straight-forward. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] include/uapi/linux/virtio_blk.h: introduce feature of VIRTIO_BLK_F_MQ
Ming Lei writes:
> Current virtio-blk spec only supports one virtual queue for transfering
> data between VM and host, and inside VM all kinds of operations on
> the virtual queue needs to hold one lock, so cause below problems:
>
> - no scalability
> - bad throughput
>
> So this patch requests to introduce feature of VIRTIO_BLK_F_MQ
> so that more than one virtual queues can be used to virtio-blk
> device, then above problems can be solved or eased.
>
> Signed-off-by: Ming Lei
> ---
> include/uapi/linux/virtio_blk.h |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/uapi/linux/virtio_blk.h b/include/uapi/linux/virtio_blk.h
> index 6d8e61c..c5a2751 100644
> --- a/include/uapi/linux/virtio_blk.h
> +++ b/include/uapi/linux/virtio_blk.h
> @@ -40,6 +40,7 @@
> #define VIRTIO_BLK_F_WCE 9 /* Writeback mode enabled after reset */
> #define VIRTIO_BLK_F_TOPOLOGY10 /* Topology information is
> available */
> #define VIRTIO_BLK_F_CONFIG_WCE 11 /* Writeback mode available in
> config */
> +#define VIRTIO_BLK_F_MQ 12 /* support more than one vq */
>
> #ifndef __KERNEL__
> /* Old (deprecated) name for VIRTIO_BLK_F_WCE. */
> @@ -77,6 +78,9 @@ struct virtio_blk_config {
>
> /* writeback mode (if VIRTIO_BLK_F_CONFIG_WCE) */
> __u8 wce;
> +
> + /* number of vqs, only available when VIRTIO_BLK_F_MQ is set */
> + __u16 num_queues;
> } __attribute__((packed));
Hmm, please pad this like so:
__u8 unused;
__u16 num_queues;
That avoids weird alignment.
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch: Warn on unnecessary void function return statements
My code has multiple exit lables:
void function(void)
{
...
if (err1)
goto exit1;
...
if (err2)
goto exit2;
...
return; /* Good return, no errors */
exit1:
printk(err1);
return;
exit2:
printk(err2);
}
The single tabbed return was required to prevent the good return & err1
messages cascading down. The extra exit label with a noop looks weird,
but is passing checkpatch.pl --strict, so I will go with that, thanks.
-Anish
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv2 0/2] regulator: of: Add support for pasing regulator suspend state
Hi Mark,
Could you please review this patchset?
Best Regards,
Chanwoo Choi
On 06/11/2014 09:41 AM, Chanwoo Choi wrote:
> The regulators would set different state/mode according to the kind of suspend
> state. So regulation_constraints structure has already regulator suspend
> state filed.
> This patch parse regulator suspend state from devicetree file.
>
> For example:
>
> ldoX_reg: LDOx {
> regulator-name = "VAP_XXX_1.2V";
> regulator-min-microvolt = <120>;
> regulator-max-microvolt = <120>;
> regulator-always-on;
>
> regulator-initial-state = <3>; /* PM_SUSPEND_MEM */
> regulator-state-standby {
> regulator-volt = <120>;
> regulator-mode = <0x2>; /* REGULATOR_MODE_NORMAL */
> };
>
> regulator-state-mem {
> regulator-volt = <120>;
> regulator-mode = <0x8>; /* REGULATOR_MODE_STANDBY */
> regulator-off-in-suspend;
> };
>
> regulator-state-disk {
> regulator-volt = <120>;
> regulator-mode = <0x2>; /* REGULATOR_MODE_NORMAL */
> regulator-on-in-suspend;
> };
> };
>
> Changes from v1:
> - Check whether regulator-initial-state and regulator-mode is correct or not
> - Add more detailed description about regulator-initial-state, regulator-mode
> and regulator-state-[standby/mem/disk] for devicetree bindings
> - Modify example of regulator suspend state in bindings documentation
>
> Chanwoo Choi (2):
> regulator: of: Add support for parsing regulator_state for suspend state
> dt-bindings: regulator: Add regulator suspend state for PM state
>
> .../devicetree/bindings/regulator/regulator.txt| 32 +
> drivers/regulator/of_regulator.c | 76
> +-
> 2 files changed, 106 insertions(+), 2 deletions(-)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] V4L: uvcvideo: Add support for relative pan/tilt controls
Map V4L2_CID_TILT_RELATIVE and V4L2_CID_PAN_RELATIVE to the standard UVC
CT_PANTILT_ABSOLUTE_CONTROL terminal control request.
Tested by plugging a Logitech ConferenceCam C3000e USB camera
and controlling pan/tilt from the userspace using the VIDIOC_S_CTRL ioctl.
Verified that it can pan and tilt at the same time in both directions.
Signed-off-by: Vincent Palatin
Change-Id: I7b70b228e5c0126683f5f0be34ffd2807f5783dc
---
drivers/media/usb/uvc/uvc_ctrl.c | 58 +---
1 file changed, 55 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index 0eb82106..af18120 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -309,9 +309,8 @@ static struct uvc_control_info uvc_ctrls[] = {
.selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
.index = 12,
.size = 4,
- .flags = UVC_CTRL_FLAG_SET_CUR | UVC_CTRL_FLAG_GET_MIN
- | UVC_CTRL_FLAG_GET_MAX | UVC_CTRL_FLAG_GET_RES
- | UVC_CTRL_FLAG_GET_DEF
+ .flags = UVC_CTRL_FLAG_SET_CUR
+ | UVC_CTRL_FLAG_GET_RANGE
| UVC_CTRL_FLAG_AUTO_UPDATE,
},
{
@@ -391,6 +390,35 @@ static void uvc_ctrl_set_zoom(struct uvc_control_mapping
*mapping,
data[2] = min((int)abs(value), 0xff);
}
+static __s32 uvc_ctrl_get_rel_speed(struct uvc_control_mapping *mapping,
+ __u8 query, const __u8 *data)
+{
+ int first = mapping->offset / 8;
+ __s8 rel = (__s8)data[first];
+
+ switch (query) {
+ case UVC_GET_CUR:
+ return (rel == 0) ? 0 : (rel > 0 ? data[first+1]
+: -data[first+1]);
+ case UVC_GET_MIN:
+ return -data[first+1];
+ case UVC_GET_MAX:
+ case UVC_GET_RES:
+ case UVC_GET_DEF:
+ default:
+ return data[first+1];
+ }
+}
+
+static void uvc_ctrl_set_rel_speed(struct uvc_control_mapping *mapping,
+ __s32 value, __u8 *data)
+{
+ int first = mapping->offset / 8;
+
+ data[first] = value == 0 ? 0 : (value > 0) ? 1 : 0xff;
+ data[first+1] = min_t(int, abs(value), 0xff);
+}
+
static struct uvc_control_mapping uvc_ctrl_mappings[] = {
{
.id = V4L2_CID_BRIGHTNESS,
@@ -677,6 +705,30 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.data_type = UVC_CTRL_DATA_TYPE_SIGNED,
},
{
+ .id = V4L2_CID_PAN_RELATIVE,
+ .name = "Pan (Relative)",
+ .entity = UVC_GUID_UVC_CAMERA,
+ .selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
+ .size = 16,
+ .offset = 0,
+ .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
+ .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
+ .get= uvc_ctrl_get_rel_speed,
+ .set= uvc_ctrl_set_rel_speed,
+ },
+ {
+ .id = V4L2_CID_TILT_RELATIVE,
+ .name = "Tilt (Relative)",
+ .entity = UVC_GUID_UVC_CAMERA,
+ .selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
+ .size = 16,
+ .offset = 16,
+ .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
+ .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
+ .get= uvc_ctrl_get_rel_speed,
+ .set= uvc_ctrl_set_rel_speed,
+ },
+ {
.id = V4L2_CID_PRIVACY,
.name = "Privacy",
.entity = UVC_GUID_UVC_CAMERA,
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFT v5h printk: allow increasing the ring buffer depending on the number of CPUs
From: "Luis R. Rodriguez" The default size of the ring buffer is too small for machines with a large amount of CPUs under heavy load. What ends up happening when debugging is the ring buffer overlaps and chews up old messages making debugging impossible unless the size is passed as a kernel parameter. An idle system upon boot up will on average spew out only about one or two extra lines but where this really matters is on heavy load and that will vary widely depending on the system and environment. There are mechanisms to help increase the kernel ring buffer for tracing through debugfs, and those interfaces even allow growing the kernel ring buffer per CPU. We also have a static value which can be passed upon boot. Relying on debugfs however is not ideal for production, and relying on the value passed upon bootup is can only used *after* an issue has creeped up. Instead of being reactive this adds a proactive measure which lets you scale the amount of contributions you'd expect to the kernel ring buffer under load by each CPU in the worst case scenario. We use num_possible_cpus() to avoid complexities which could be introduced by dynamically changing the ring buffer size at run time, num_possible_cpus() lets us use the upper limit on possible number of CPUs therefore avoiding having to deal with hotplugging CPUs on and off. This introduces the kernel configuration option LOG_CPU_MIN_BUF_SHIFT which is used to specify the maximum amount of contributions to the kernel ring buffer in the worst case before the kernel ring buffer flips over, the size is specified as a power of 2. The total amount of contributions made by each CPU must be greater than half of the default kernel ring buffer size (1 << LOG_BUF_SHIFT bytes) in order to trigger an increase upon bootup. The kernel ring buffer is increased to the next power of two that would fit the required minimum kernel ring buffer size plus the additional CPU contribution. For example if LOG_BUF_SHIFT is 18 (256 KB) you'd require at least 128 KB contributions by other CPUs in order to trigger an increase of the kernel ring buffer. With a LOG_CPU_BUF_SHIFT of 12 (4 KB) you'd require at least anything over > 64 possible CPUs to trigger an increase. If you had 128 possible CPUs the amount of minimum required kernel ring buffer bumps to: ((1 << 18) + ((128 - 1) * (1 << 12))) / 1024 = 764 KB Since we require the ring buffer to be a power of two this would the new required size would be 1024 KB. This CPU contributions are ignored when the "log_buf_len" kernel parameter is used as it forces the exact size of the ring buffer to an expected power of two value. In order to make this code a bit more legible, add a small enum to keep track of when the reasons of setting the ring buffer, and extend the documentation quite a bit to make all this clear. Cc: Michal Hocko Cc: Petr Mladek Cc: Andrew Morton Cc: Joe Perches Cc: Arun KS Cc: Kees Cook Cc: Davidlohr Bueso Cc: Chris Metcalf Cc: linux-kernel@vger.kernel.org Signed-off-by: Luis R. Rodriguez --- I've modified the computation to just go to the next power of two. All other implementations do that, and although its not well documented I rather follow that logic. Without the enum stuff this code can get ugly easy, while at it I also extended the documentation a bit more. Documentation/kernel-parameters.txt | 8 ++- init/Kconfig| 53 +- kernel/printk/printk.c | 108 ++-- 3 files changed, 162 insertions(+), 7 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 6eaa9cd..229d031 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1685,8 +1685,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. 7 (KERN_DEBUG) debug-level messages log_buf_len=n[KMG] Sets the size of the printk ring buffer, - in bytes. n must be a power of two. The default - size is set in the kernel config file. + in bytes. n must be a power of two and greater + than the minimal size. The minimal size is defined + by LOG_BUF_SHIFT kernel config parameter. There is + also CONFIG_LOG_CPU_MIN_BUF_SHIFT config parameter + that allows to increase the default size depending on + the number of CPUs. See init/Kconfig for more details. logo.nologo [FB] Disables display of the built-in Linux logo. This may be used to provide more screen space for diff --git a/init/Kconfig b/init/Kconfig index 9d76b99..69bdbcf 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -807,7 +807,11 @@ config LOG_BUF_SHIFT range 12 21 default 17 help - Select kernel log buffer
Re: [PATCH] infiniband: Fixes memory leak in send_flowc
On Mon, 16 Jun 2014, Nick Krause wrote:
> That's true David,
> I will resend this parch without the use of the pr_warn.
There's no patch to resend if you don't use pr_warn(). kfree_skb(skb) is
unnecessary if !skb, look at the first thing it checks:
void kfree_skb(struct sk_buff *skb)
{
if (unlikely(!skb))
return;
...
}
Thus, I don't see the memory leak you're referring to.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 -next 24/26] usb: Use dma_zalloc_coherent
On Mon, 2014-06-16 at 22:00 +, Paul Zimmerman wrote:
> > From: Joe Perches [mailto:j...@perches.com]
> > Sent: Sunday, June 15, 2014 1:38 PM
> >
> > Use the zeroing function instead of dma_alloc_coherent & memset(,0,)
> >
> > Signed-off-by: Joe Perches
> > ---
> > drivers/usb/dwc2/hcd_ddma.c | 20 +++-
> > drivers/usb/host/uhci-hcd.c | 7 +++
> > 2 files changed, 10 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/usb/dwc2/hcd_ddma.c b/drivers/usb/dwc2/hcd_ddma.c
> > index 3376177..ab8d7fc 100644
> > --- a/drivers/usb/dwc2/hcd_ddma.c
> > +++ b/drivers/usb/dwc2/hcd_ddma.c
> > @@ -87,17 +87,12 @@ static u16 dwc2_frame_incr_val(struct dwc2_qh *qh)
> > static int dwc2_desc_list_alloc(struct dwc2_hsotg *hsotg, struct dwc2_qh
> > *qh,
> > gfp_t flags)
> > {
> > - qh->desc_list = dma_alloc_coherent(hsotg->dev,
> > - sizeof(struct dwc2_hcd_dma_desc) *
> > - dwc2_max_desc_num(qh), >desc_list_dma,
> > - flags);
> > -
> > + qh->desc_list = dma_zalloc_coherent(hsotg->dev,
> > + sizeof(struct dwc2_hcd_dma_desc) *
> > dwc2_max_desc_num(qh),
> > + >desc_list_dma, flags);
>
> This will cause checkpatch to complain about a too-long line, surely?
Hi Paul.
It does and I don't care.
> If you fix that, you can add my acked-by for the dwc2 parts.
If you care that much, I can fix it for you, but I
think it's better as a long line.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] checkpatch: Warn on unnecessary void function return statements
On Mon, 2014-06-16 at 16:28 -0700, Anish Bhatt wrote:
> This seems to ignore the ability to exit from void
> return functions via a `return;` in case of an error
> or similar. Any attempt to bail out generates warnings
> with checkpathch.pl Perhaps it should check for returns
> only at the end of the function ? If not, is there a
> suggested way to do this ? goto labels can't be directly
> used in place either
The only time checkpatch should bleat any message
is when there is a return; statement indented with
a single tab.
This form should be fine and not generate any
checkpatch warning.
void function(void)
{
...
if (err)
return;
...
}
If you want to use exit labels, I suggest you
use this form:
void function(void)
{
...
if (err)
goto exit;
...
exit:
;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv6 2/3] regulator: s2mps11: Add support S2MPU02 regulator device
This patch add S2MPU02 regulator device to existing S2MPS11 device driver
because of little difference between S2MPS1x and S2MPU02. The S2MPU02
regulator device includes LDO[1-28] and BUCK[1-7].
Signed-off-by: Chanwoo Choi
[Add missing linear_min_sel of S2MPU02 LDO regulators by Jonghwa Lee]
Signed-off-by: Jonghwa Lee
Reviewed-by: Krzysztof Kozlowski
Acked-by: Mark Brown
Acked-by: Lee Jones
---
drivers/mfd/sec-core.c | 25 +++
drivers/regulator/s2mps11.c | 321 +---
include/linux/mfd/samsung/s2mpu02.h | 201 ++
3 files changed, 526 insertions(+), 21 deletions(-)
create mode 100644 include/linux/mfd/samsung/s2mpu02.h
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 15ba847..2621328 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -144,6 +145,18 @@ static bool s2mps11_volatile(struct device *dev, unsigned
int reg)
}
}
+static bool s2mpu02_volatile(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case S2MPU02_REG_INT1M:
+ case S2MPU02_REG_INT2M:
+ case S2MPU02_REG_INT3M:
+ return false;
+ default:
+ return true;
+ }
+}
+
static bool s5m8763_volatile(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -189,6 +202,15 @@ static const struct regmap_config s2mps14_regmap_config = {
.cache_type = REGCACHE_FLAT,
};
+static const struct regmap_config s2mpu02_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = S2MPU02_REG_DVSDATA,
+ .volatile_reg = s2mpu02_volatile,
+ .cache_type = REGCACHE_FLAT,
+};
+
static const struct regmap_config s5m8763_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -310,6 +332,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
case S5M8767X:
regmap = _regmap_config;
break;
+ case S2MPU02:
+ regmap = _regmap_config;
+ break;
default:
regmap = _regmap_config;
break;
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 02e2fb2..2daacc6 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
struct s2mps11_info {
unsigned int rdev_num;
@@ -40,11 +41,15 @@ struct s2mps11_info {
int ramp_delay16;
int ramp_delay7810;
int ramp_delay9;
+
+ enum sec_device_type dev_type;
+
/*
-* One bit for each S2MPS14 regulator whether the suspend mode
+* One bit for each S2MPS14/S2MPU02 regulator whether the suspend mode
* was enabled.
*/
- unsigned int s2mps14_suspend_state:30;
+ unsigned long long s2mps14_suspend_state:35;
+
/* Array of size rdev_num with GPIO-s for external sleep control */
int *ext_control_gpio;
};
@@ -415,12 +420,24 @@ static int s2mps14_regulator_enable(struct regulator_dev
*rdev)
struct s2mps11_info *s2mps11 = rdev_get_drvdata(rdev);
unsigned int val;
- if (s2mps11->s2mps14_suspend_state & (1 << rdev_get_id(rdev)))
- val = S2MPS14_ENABLE_SUSPEND;
- else if (gpio_is_valid(s2mps11->ext_control_gpio[rdev_get_id(rdev)]))
- val = S2MPS14_ENABLE_EXT_CONTROL;
- else
- val = rdev->desc->enable_mask;
+ switch (s2mps11->dev_type) {
+ case S2MPS14X:
+ if (s2mps11->s2mps14_suspend_state & (1 << rdev_get_id(rdev)))
+ val = S2MPS14_ENABLE_SUSPEND;
+ else if
(gpio_is_valid(s2mps11->ext_control_gpio[rdev_get_id(rdev)]))
+ val = S2MPS14_ENABLE_EXT_CONTROL;
+ else
+ val = rdev->desc->enable_mask;
+ break;
+ case S2MPU02:
+ if (s2mps11->s2mps14_suspend_state & (1 << rdev_get_id(rdev)))
+ val = S2MPU02_ENABLE_SUSPEND;
+ else
+ val = rdev->desc->enable_mask;
+ break;
+ default:
+ return -EINVAL;
+ };
return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
rdev->desc->enable_mask, val);
@@ -429,12 +446,38 @@ static int s2mps14_regulator_enable(struct regulator_dev
*rdev)
static int s2mps14_regulator_set_suspend_disable(struct regulator_dev *rdev)
{
int ret;
- unsigned int val;
+ unsigned int val, state;
struct s2mps11_info *s2mps11 = rdev_get_drvdata(rdev);
+ int rdev_id = rdev_get_id(rdev);
- /* LDO3 should be always on and does not support suspend mode */
- if (rdev_get_id(rdev) == S2MPS14_LDO3)
- return 0;
+ /* Below LDO should be always on or does not
[PATCHv6 1/3] mfd: sec-core: Add support for S2MPU02 device
Add support for Samsung S2MPU02 PMIC device to the MFD sec-core driver.
The S2MPU02 device includes PMIC/RTC/Clock devices.
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
---
drivers/mfd/sec-core.c | 46 +++-
drivers/mfd/sec-irq.c| 110 +--
include/linux/mfd/samsung/core.h | 1 +
include/linux/mfd/samsung/irq.h | 24 +
4 files changed, 151 insertions(+), 30 deletions(-)
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index be06d0a..15ba847 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -89,6 +89,15 @@ static const struct mfd_cell s2mpa01_devs[] = {
},
};
+static const struct mfd_cell s2mpu02_devs[] = {
+ { .name = "s2mpu02-pmic", },
+ { .name = "s2mpu02-rtc", },
+ {
+ .name = "s2mpu02-clk",
+ .of_compatible = "samsung,s2mpu02-clk",
+ }
+};
+
#ifdef CONFIG_OF
static const struct of_device_id sec_dt_match[] = {
{ .compatible = "samsung,s5m8767-pmic",
@@ -103,6 +112,9 @@ static const struct of_device_id sec_dt_match[] = {
.compatible = "samsung,s2mpa01-pmic",
.data = (void *)S2MPA01,
}, {
+ .compatible = "samsung,s2mpu02-pmic",
+ .data = (void *)S2MPU02,
+ }, {
/* Sentinel */
},
};
@@ -250,9 +262,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
{
struct sec_platform_data *pdata = dev_get_platdata(>dev);
const struct regmap_config *regmap;
+ const struct mfd_cell *sec_devs;
struct sec_pmic_dev *sec_pmic;
unsigned long device_type;
- int ret;
+ int ret, num_sec_devs;
sec_pmic = devm_kzalloc(>dev, sizeof(struct sec_pmic_dev),
GFP_KERNEL);
@@ -319,34 +332,39 @@ static int sec_pmic_probe(struct i2c_client *i2c,
switch (sec_pmic->device_type) {
case S5M8751X:
- ret = mfd_add_devices(sec_pmic->dev, -1, s5m8751_devs,
- ARRAY_SIZE(s5m8751_devs), NULL, 0, NULL);
+ sec_devs = s5m8751_devs;
+ num_sec_devs = ARRAY_SIZE(s5m8751_devs);
break;
case S5M8763X:
- ret = mfd_add_devices(sec_pmic->dev, -1, s5m8763_devs,
- ARRAY_SIZE(s5m8763_devs), NULL, 0, NULL);
+ sec_devs = s5m8763_devs;
+ num_sec_devs = ARRAY_SIZE(s5m8763_devs);
break;
case S5M8767X:
- ret = mfd_add_devices(sec_pmic->dev, -1, s5m8767_devs,
- ARRAY_SIZE(s5m8767_devs), NULL, 0, NULL);
+ sec_devs = s5m8767_devs;
+ num_sec_devs = ARRAY_SIZE(s5m8767_devs);
break;
case S2MPA01:
- ret = mfd_add_devices(sec_pmic->dev, -1, s2mpa01_devs,
- ARRAY_SIZE(s2mpa01_devs), NULL, 0, NULL);
+ sec_devs = s2mpa01_devs;
+ num_sec_devs = ARRAY_SIZE(s2mpa01_devs);
break;
case S2MPS11X:
- ret = mfd_add_devices(sec_pmic->dev, -1, s2mps11_devs,
- ARRAY_SIZE(s2mps11_devs), NULL, 0, NULL);
+ sec_devs = s2mps11_devs;
+ num_sec_devs = ARRAY_SIZE(s2mps11_devs);
break;
case S2MPS14X:
- ret = mfd_add_devices(sec_pmic->dev, -1, s2mps14_devs,
- ARRAY_SIZE(s2mps14_devs), NULL, 0, NULL);
+ sec_devs = s2mps14_devs;
+ num_sec_devs = ARRAY_SIZE(s2mps14_devs);
+ break;
+ case S2MPU02:
+ sec_devs = s2mpu02_devs;
+ num_sec_devs = ARRAY_SIZE(s2mpu02_devs);
break;
default:
/* If this happens the probe function is problem */
BUG();
}
-
+ ret = mfd_add_devices(sec_pmic->dev, -1, sec_devs, num_sec_devs, NULL,
+ 0, NULL);
if (ret)
goto err_mfd;
diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index 654e2c1..f9a5786 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -161,6 +162,77 @@ static const struct regmap_irq s2mps14_irqs[] = {
},
};
+static const struct regmap_irq s2mpu02_irqs[] = {
+ [S2MPU02_IRQ_PWRONF] = {
+ .reg_offset = 0,
+ .mask = S2MPS11_IRQ_PWRONF_MASK,
+ },
+ [S2MPU02_IRQ_PWRONR] = {
+ .reg_offset = 0,
+ .mask = S2MPS11_IRQ_PWRONR_MASK,
+ },
+ [S2MPU02_IRQ_JIGONBF] = {
+ .reg_offset = 0,
+ .mask = S2MPS11_IRQ_JIGONBF_MASK,
+ },
+ [S2MPU02_IRQ_JIGONBR] = {
+ .reg_offset
[PATCHv6 0/3] mfd: sec-core: Add support S2MPU02 PMIC device
This patchset add Samsung S2MPU02 PMIC device driver in exiting S2MPS11 PMIC driver because S2MPU02 has a little different between S2MPU02 and S2MPS1x. The S2MPU02 PMIC has LDO[1-28] and BUCK[1-7] regulators. Changes from v5: - Remove the duplicate code about mfd_add_devices() and regmap_add_irq_chip() - Add acked message by Lee Jones for mfd patch on patch2 Changes from v4: - This patchset is rebased on 'Linux 3.16-rc1'. Changes from v3: - Fix bug of s2mps14_regulator_set_suspend_disable() Changes from v2: - Change patchset name - Remove un-necessary switch statement - Add acked message by Mark Brown for regulator patch - Add reviewed message by Krzysztof Kozlowski for all patchs Changes from v1: - Fix typo about patch description - Use existing suspend_state variable instead of defining new variable for S2MPU02 - Remove unnecessary parameter of s2mps11_pmic_dt_parse() - Remove unfit comment of s2mpu02.h file - Both patch2 and patch3 should be squashed on patch2 Chanwoo Choi (3): mfd: sec-core: Add support for S2MPU02 device regulator: s2mps11: Add support S2MPU02 regulator device dt-bindings: mfd: s2mps11: Add support S2MPU02 PMIC Documentation/devicetree/bindings/mfd/s2mps11.txt | 7 +- drivers/mfd/sec-core.c| 71 - drivers/mfd/sec-irq.c | 110 ++-- drivers/regulator/s2mps11.c | 321 -- include/linux/mfd/samsung/core.h | 1 + include/linux/mfd/samsung/irq.h | 24 ++ include/linux/mfd/samsung/s2mpu02.h | 201 ++ 7 files changed, 682 insertions(+), 53 deletions(-) create mode 100644 include/linux/mfd/samsung/s2mpu02.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/
[PATCHv6 3/3] dt-bindings: mfd: s2mps11: Add support S2MPU02 PMIC
This patch add documentation for S2MPU02 PMIC device. S2MPU02 has a little difference from S2MPS11/S2MPS14 PMIC and has LDO[1-28]/Buck[1-7]. Signed-off-by: Chanwoo Choi Reviewed-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/mfd/s2mps11.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index d81ba30..f7c9180 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -1,5 +1,5 @@ -* Samsung S2MPS11 and S2MPS14 Voltage and Current Regulator +* Samsung S2MPS11, S2MPS14 and S2MPU02 Voltage and Current Regulator The Samsung S2MPS11 is a multi-function device which includes voltage and current regulators, RTC, charger controller and other sub-blocks. It is @@ -7,7 +7,8 @@ interfaced to the host controller using an I2C interface. Each sub-block is addressed by the host system using different I2C slave addresses. Required properties: -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps14-pmic". +- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps14-pmic" + or "samsung,s2mpu02-pmic". - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. Optional properties: @@ -81,11 +82,13 @@ as per the datasheet of s2mps11. - valid values for n are: - S2MPS11: 1 to 38 - S2MPS14: 1 to 25 + - S2MPU02: 1 to 28 - Example: LDO1, LD02, LDO28 - BUCKn - valid values for n are: - S2MPS11: 1 to 10 - S2MPS14: 1 to 5 + - S2MPU02: 1 to 7 - Example: BUCK1, BUCK2, BUCK9 Example: -- 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/
Re: [PATCH] ACPI: use kstrto*() instead of simple_strto*()
On Fri, 13 Jun 2014, Christoph Jaeger wrote: > simple_strto*() are obsolete; use kstrto*() instead. Add proper error > checking. > > Signed-off-by: Christoph Jaeger Acked-by: David Rientjes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] checkpatch: Warn on unnecessary void function return statements
This seems to ignore the ability to exit from void return functions via a `return;` in case of an error or similar. Any attempt to bail out generates warnings with checkpathch.pl Perhaps it should check for returns only at the end of the function ? If not, is there a suggested way to do this ? goto labels can't be directly used in place either -Anish Bhatt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 2/4] Documentation: dts: Add bindings for APM X-Gene SoC ethernet driver
This patch adds documentation for APM X-Gene SoC ethernet DTS binding.
Signed-off-by: Iyappan Subramanian
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
.../devicetree/bindings/net/apm-xgene-enet.txt | 72 ++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/apm-xgene-enet.txt
diff --git a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
new file mode 100644
index 000..3e2a295
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
@@ -0,0 +1,72 @@
+APM X-Gene SoC Ethernet nodes
+
+Ethernet nodes are defined to describe on-chip ethernet interfaces in
+APM X-Gene SoC.
+
+Required properties:
+- compatible: Should be "apm,xgene-enet"
+- reg: Address and length of the register set for the device. It contains the
+ information of registers in the same order as described by reg-names
+- reg-names: Should contain the register set names
+ "enet_csr": Ethernet control and status register address space
+ "ring_csr": Descriptor ring control and status register address
space
+ "ring_cmd": Descriptor ring command register address space
+- interrupts: Ethernet main interrupt
+- clocks: Reference to the clock entry.
+- local-mac-address: MAC address assigned to this device
+- phy-connection-type: Interface type between ethernet device and PHY device
+- phy-handle: Reference to a PHY node connected to this device
+
+- mdio:Device tree subnode with the following required
+ properties:
+
+ - compatible: Must be "apm,xgene-mdio".
+ - #address-cells: Must be <1>.
+ - #size-cells: Must be <0>.
+
+ For the phy on the mdio bus, there must be a node with the following
+ fields:
+
+ - compatible: PHY identifier. Please refer ./phy.txt for the format.
+ - reg: The ID number for the phy.
+
+Optional properties:
+- status : Should be "ok" or "disabled" for enabled/disabled.
+ Default is "ok".
+
+
+Example:
+ menetclk: menetclk {
+ compatible = "apm,xgene-device-clock";
+ clock-output-names = "menetclk";
+ status = "ok";
+ };
+
+ menet: ethernet@1702 {
+ compatible = "apm,xgene-enet";
+ status = "disabled";
+ reg = <0x0 0x1702 0x0 0xd100>,
+ <0x0 0X1703 0x0 0X400>,
+ <0x0 0X1000 0x0 0X200>;
+ reg-names = "enet_csr", "ring_csr", "ring_cmd";
+ interrupts = <0x0 0x3c 0x4>;
+ clocks = < 0>;
+ local-mac-address = [00 01 73 00 00 01];
+ phy-connection-type = "rgmii";
+ phy-handle = <>;
+ mdio {
+ compatible = "apm,xgene-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ menetphy: menetphy@3 {
+ compatible = "ethernet-phy-id001c.c915";
+ reg = <0x3>;
+ };
+
+ };
+ };
+
+/* Board-specific peripheral configurations */
+ {
+status = "ok";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include: kernel.h: rewrite min3, max3 and clamp using min and max
On Mon, 16 Jun 2014 16:54:32 -0700 (PDT) David Rientjes wrote: > > > On linux-next, allyesconfig has a 0.0001% savings as a result of the > patch, but I'd be worried about the extra temp variable it allocates on > the stack that is evident in the mm/slab.c disassembly unless all cases > can be audited to show that we're not potentially deep. A 0.0001% change means it's not worth changing, and we may be able to mark this up as a fluke in Michal's results. I'll give it a try on my 4.6.3 compiler. -- Steve > >text data bss dec hex filename > 108573045 2348801651580928183641989 af22785 > vmlinux.before > 108572908 2348801651580928183641852 af226fc > vmlinux.after -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 0/4] net: Add APM X-Gene SoC Ethernet driver support
Adding APM X-Gene SoC Ethernet driver. v6: Address comments from v5 review * added basic ethtool support * added ndo_get_stats64 call back * deleted priting Rx error messages * renamed set_bits to xgene_set_bits to fix kbuild error (make ARCH=powerpc) v5: Address comments from v4 review * Documentation: Added phy-handle, reg-names and changed mdio part * dtb: Added reg-names supplemental property * changed platform_get_resource to platform_get_resource_byname * added separate tx/rx set_desc/get_desc functions to do raw_write/raw_read * removed set_desc/get_desc table lookup logic * added error handling logic based on per packet descriptor bits * added software managed Rx packet and error counters * added busy wait for register read/writes * changed mdio_bus->id to avoid conflict * fixed mdio_bus leak in case of mdio_config error * changed phy reg hard coded value to MII_BMSR * changed phy addr hard coded value to phy_device->addr * added paranthesis around macro arguments * converted helper macros to inline functions * changed use of goto's only to common work such as cleanup v4: Address comments from v3 review * MAINTAINERS: changed status to supported * Kconfig: made default to no * changed to bool data type wherever applicable * cleaned up single bit set and masking code * removed statistics counters masking * removed unnecessary OOM message printing * fixed dma_map_single and dma_unmap_single size parameter * changed set bits macro body using new set_bits function v3: Address comments from v2 review * cleaned up set_desc and get_desc functions * added dtb mdio node and phy-handle subnode * renamed dtb phy-mode to phy-connection-type * added of_phy_connect call to connec to PHY * added empty line after last local variable declaration * removed type casting when not required * removed inline keyword from source files * removed CONFIG_CPU_BIG_ENDIAN ifdef v2 * Completely redesigned ethernet driver * Added support to work with big endian kernel * Renamed dtb phyid entry to phy_addr * Changed dtb local-mac-address entry to byte string format * Renamed dtb eth8clk entry to menetclk v1 * Initial version Signed-off-by: Iyappan Subramanian Signed-off-by: Ravi Patel Signed-off-by: Keyur Chudgar --- Iyappan Subramanian (4): MAINTAINERS: Add entry for APM X-Gene SoC ethernet driver Documentation: dts: Add bindings for APM X-Gene SoC ethernet driver dts: Add bindings for APM X-Gene SoC ethernet driver drivers: net: Add APM X-Gene SoC ethernet driver support. .../devicetree/bindings/net/apm-xgene-enet.txt | 72 ++ MAINTAINERS| 8 + arch/arm64/boot/dts/apm-mustang.dts| 4 + arch/arm64/boot/dts/apm-storm.dtsi | 30 +- drivers/net/ethernet/Kconfig | 1 + drivers/net/ethernet/Makefile | 1 + drivers/net/ethernet/apm/Kconfig | 1 + drivers/net/ethernet/apm/Makefile | 5 + drivers/net/ethernet/apm/xgene/Kconfig | 9 + drivers/net/ethernet/apm/xgene/Makefile| 6 + .../net/ethernet/apm/xgene/xgene_enet_ethtool.c| 125 +++ drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 848 +++ drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 394 + drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 937 + drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 109 +++ 15 files changed, 2547 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/apm-xgene-enet.txt create mode 100644 drivers/net/ethernet/apm/Kconfig create mode 100644 drivers/net/ethernet/apm/Makefile create mode 100644 drivers/net/ethernet/apm/xgene/Kconfig create mode 100644 drivers/net/ethernet/apm/xgene/Makefile create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.c create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mmc: Add hardware dependencies for sdhci-pxav3 and sdhci-pxav2
On Mon, Jun 16, 2014 at 8:18 PM, Jean Delvare wrote: > I seem to understand that the sdhci-pxav3 and sdhci-pxav2 drivers are > only needed on the MMP architecture. So add a hardware dependency on > ARCH_MMP, so that other users don't get to build useless drivers. > > Signed-off-by: Jean Delvare > Cc: Chris Ball > Cc: Ulf Hansson > Cc: Eric Miao > Cc: Haojian Zhuang > --- > Changes since v1: > * Rebased on kernel 3.16-rc1 > > drivers/mmc/host/Kconfig |2 ++ > 1 file changed, 2 insertions(+) > > --- linux-3.16-rc1.orig/drivers/mmc/host/Kconfig2014-06-16 > 14:03:26.195946537 +0200 > +++ linux-3.16-rc1/drivers/mmc/host/Kconfig 2014-06-16 14:04:02.128663037 > +0200 > @@ -217,6 +217,7 @@ config MMC_SDHCI_PXAV3 > tristate "Marvell MMP2 SD Host Controller support (PXAV3)" > depends on CLKDEV_LOOKUP > depends on MMC_SDHCI_PLTFM > + depends on ARCH_MMP || COMPILE_TEST > default CPU_MMP2 > help > This selects the Marvell(R) PXAV3 SD Host Controller. > @@ -229,6 +230,7 @@ config MMC_SDHCI_PXAV2 > tristate "Marvell PXA9XX SD Host Controller support (PXAV2)" > depends on CLKDEV_LOOKUP > depends on MMC_SDHCI_PLTFM > + depends on ARCH_MMP || COMPILE_TEST > default CPU_PXA910 > help > This selects the Marvell(R) PXAV2 SD Host Controller. > > Acked-by: Haojian Zhuang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 3/4] dts: Add bindings for APM X-Gene SoC ethernet driver
This patch adds bindings for APM X-Gene SoC ethernet driver.
Signed-off-by: Iyappan Subramanian
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
arch/arm64/boot/dts/apm-mustang.dts | 4
arch/arm64/boot/dts/apm-storm.dtsi | 30 +++---
2 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/apm-mustang.dts
b/arch/arm64/boot/dts/apm-mustang.dts
index 1247ca1..e2fb1ef 100644
--- a/arch/arm64/boot/dts/apm-mustang.dts
+++ b/arch/arm64/boot/dts/apm-mustang.dts
@@ -24,3 +24,7 @@
reg = < 0x1 0x 0x0 0x8000 >; /* Updated by
bootloader */
};
};
+
+ {
+ status = "ok";
+};
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index c5f0a47..bd7a614 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -167,14 +167,13 @@
clock-output-names = "ethclk";
};
- eth8clk: eth8clk {
+ menetclk: menetclk {
compatible = "apm,xgene-device-clock";
#clock-cells = <1>;
clocks = < 0>;
- clock-names = "eth8clk";
reg = <0x0 0x1702C000 0x0 0x1000>;
reg-names = "csr-reg";
- clock-output-names = "eth8clk";
+ clock-output-names = "menetclk";
};
sataphy1clk: sataphy1clk@1f21c000 {
@@ -363,5 +362,30 @@
#clock-cells = <1>;
clocks = < 0>;
};
+
+ menet: ethernet@1702 {
+ compatible = "apm,xgene-enet";
+ status = "disabled";
+ reg = <0x0 0x1702 0x0 0xd100>,
+ <0x0 0X1703 0x0 0X400>,
+ <0x0 0X1000 0x0 0X200>;
+ reg-names = "enet_csr", "ring_csr", "ring_cmd";
+ interrupts = <0x0 0x3c 0x4>;
+ dma-coherent;
+ clocks = < 0>;
+ local-mac-address = [00 01 73 00 00 01];
+ phy-connection-type = "rgmii";
+ phy-handle = <>;
+ mdio {
+ compatible = "apm,xgene-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ menetphy: menetphy@3 {
+ compatible = "ethernet-phy-id001c.c915";
+ reg = <0x3>;
+ };
+
+ };
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 1/4] MAINTAINERS: Add entry for APM X-Gene SoC ethernet driver
This patch adds a MAINTAINERS entry for APM X-Gene SoC ethernet driver. Signed-off-by: Iyappan Subramanian Signed-off-by: Ravi Patel Signed-off-by: Keyur Chudgar --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 134483f..d65a3be 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -700,6 +700,14 @@ S: Maintained F: drivers/net/appletalk/ F: net/appletalk/ +APPLIED MICRO (APM) X-GENE SOC ETHERNET DRIVER +M: Iyappan Subramanian +M: Keyur Chudgar +M: Ravi Patel +S: Supported +F: drivers/net/ethernet/apm/xgene/ +F: Documentation/devicetree/bindings/net/apm-xgene-enet.txt + APTINA CAMERA SENSOR PLL M: Laurent Pinchart L: linux-me...@vger.kernel.org -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio-pxa: gpio0 and gpio1 support on dt
On Thu, Jun 12, 2014 at 4:43 PM, Linus Walleij wrote: > On Thu, Jun 5, 2014 at 9:13 PM, Andrew Ruder > wrote: > >> pxa_gpio_probe() has some issues supporting the gpio0 and gpio1 >> interrupts under device-tree - it never actually sets up the chain >> handler to get interrupts on edge detect for GPIO0 and GPIO1. >> >> Signed-off-by: Andrew Ruder > > Makes perfect sense. Can I have an ACK from some PXA > maintainer on this? > > The PXA GPIO driver with it's messy irqchip registration looks > like a good candidate for switching to the gpiolib irqchip helpers > and rid some code. Just saying. > > Yours, > Linus Walleij Acked-by: Haojian Zhuang Yes, it's worth to rid some irqchip code. Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv5 1/3] mfd: sec-core: Add support for S2MPU02 device
Hi Lee,
On 06/16/2014 10:03 PM, Lee Jones wrote:
> On Mon, 16 Jun 2014, Chanwoo Choi wrote:
>
>> Add support for Samsung S2MPU02 PMIC device to the MFD sec-core driver.
>> The S2MPU02 device includes PMIC/RTC/Clock devices.
>>
>> Signed-off-by: Chanwoo Choi
>> Reviewed-by: Krzysztof Kozlowski
>> ---
>> drivers/mfd/sec-core.c | 19 +
>> drivers/mfd/sec-irq.c| 88
>>
>> include/linux/mfd/samsung/core.h | 1 +
>> include/linux/mfd/samsung/irq.h | 24 +++
>> 4 files changed, 132 insertions(+)
>>
>> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
>> index be06d0a..5e8784b 100644
>> --- a/drivers/mfd/sec-core.c
>> +++ b/drivers/mfd/sec-core.c
>> @@ -89,6 +89,17 @@ static const struct mfd_cell s2mpa01_devs[] = {
>> },
>> };
>>
>> +static const struct mfd_cell s2mpu02_devs[] = {
>> +{
>> +.name = "s2mpu02-pmic",
>> +}, {
>> +.name = "s2mpu02-rtc",
>
> Make these two one liners, so:
>
> { .name = "s2mpu02-pmic" },
> { .name = "s2mpu02-rtc" ),
OK, I'll modify it.
>
>> +}, {
>> +.name = "s2mpu02-clk",
>> +.of_compatible = "samsung,s2mpu02-clk",
>> +}
>> +};
>> +
>> #ifdef CONFIG_OF
>> static const struct of_device_id sec_dt_match[] = {
>> { .compatible = "samsung,s5m8767-pmic",
>> @@ -103,6 +114,9 @@ static const struct of_device_id sec_dt_match[] = {
>> .compatible = "samsung,s2mpa01-pmic",
>> .data = (void *)S2MPA01,
>> }, {
>> +.compatible = "samsung,s2mpu02-pmic",
>> +.data = (void *)S2MPU02,
>> +}, {
>> /* Sentinel */
>> },
>> };
>> @@ -342,6 +356,11 @@ static int sec_pmic_probe(struct i2c_client *i2c,
>> ret = mfd_add_devices(sec_pmic->dev, -1, s2mps14_devs,
>>ARRAY_SIZE(s2mps14_devs), NULL, 0, NULL);
>> break;
>> +case S2MPU02:
>> +ret = mfd_add_devices(sec_pmic->dev, -1, s2mpu02_devs,
>> + ARRAY_SIZE(s2mpu02_devs), NULL, 0, NULL);
>> +break;
>
> This is a bit bonkers. Instead of passing S2MPU02, why don't you pass
> a new container which holds s2mpu02_devs and s2mpu02_irq_chip, then
> you won't need new mfd_add_devices() and regmap_add_irq_chip() calls
> for every device you want to support.
OK, I'll remove duplicate code of mfd_add_devices() and regmap_add_irq_chip().
Best Regards,
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] infiniband: Fixes memory leak in send_flowc
On Mon, 16 Jun 2014, Nick Krause wrote: > If that is the case ,David I would mark bug id 44631 as closed due to no > need for my if statement. You don't want to depend on the implementation of the page allocator to never return NULL for orders < PAGE_ALLOC_COSTLY_ORDER with GFP_KERNEL, it could possibly change in the future and we wouldn't catch your dependency in send_flowc(). The size object size of the skbuff_head_cache slab cache could also change. You don't need the suggested pr_warn(), though, since the page allocation failure warning would also be noisy enough. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/1 RESEND] fs/ceph/export.c: add static to local function
On Sun, 15 Jun 2014, Fabian Frederick wrote:
> ceph_get_parent is only used in fs/ceph/export.c
>
> Cc: Sage Weil
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
> ---
> fs/ceph/export.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ceph/export.c b/fs/ceph/export.c
> index 00d6af6..8d7d782 100644
> --- a/fs/ceph/export.c
> +++ b/fs/ceph/export.c
> @@ -169,7 +169,7 @@ static struct dentry *__get_parent(struct super_block *sb,
> return dentry;
> }
>
> -struct dentry *ceph_get_parent(struct dentry *child)
> +static struct dentry *ceph_get_parent(struct dentry *child)
> {
> /* don't re-export snaps */
> if (ceph_snap(child->d_inode) != CEPH_NOSNAP)
Not sure what tree you're modifying, this is fixed by commit e84be11c5360
("ceph: ceph_get_parent() can be static") in Linus's tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM64: TTY: hvc_dcc: Add support for ARM64 dcc
Add support for debug communications channel based
hvc console for arm64 cpus.
Signed-off-by: Abhimanyu Kapur
---
arch/arm64/include/asm/dcc.h | 41 +
drivers/tty/hvc/Kconfig | 2 +-
2 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/include/asm/dcc.h
diff --git a/arch/arm64/include/asm/dcc.h b/arch/arm64/include/asm/dcc.h
new file mode 100644
index 000..ef74324
--- /dev/null
+++ b/arch/arm64/include/asm/dcc.h
@@ -0,0 +1,41 @@
+/* Copyright (c) 2014 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+
+static inline u32 __dcc_getstatus(void)
+{
+ u32 __ret;
+
+ asm volatile("mrs %0, mdccsr_el0" : "=r" (__ret)
+ : : "cc");
+
+ return __ret;
+}
+
+static inline char __dcc_getchar(void)
+{
+ char __c;
+
+ asm volatile("mrs %0, dbgdtrrx_el0" : "=r" (__c));
+ isb();
+
+ return __c;
+}
+
+static inline void __dcc_putchar(char c)
+{
+ asm volatile("msr dbgdtrtx_el0, %0"
+ : /* No output register */
+ : "r" (c));
+ isb();
+}
diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
index 8902f9b..02051a1 100644
--- a/drivers/tty/hvc/Kconfig
+++ b/drivers/tty/hvc/Kconfig
@@ -88,7 +88,7 @@ config HVC_UDBG
config HVC_DCC
bool "ARM JTAG DCC console"
- depends on ARM
+ depends on ARM || ARM64
select HVC_DRIVER
help
This console uses the JTAG DCC on ARM to create a console under the
HVC
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/2] Add test to validate udelay
Thanks for the fixups. I've requeued these for 3.17. thanks -john On Mon, Jun 16, 2014 at 2:58 PM, David Riley wrote: > This change adds a module and a script that makes use of it to > validate that udelay delays for at least as long as requested > (as compared to ktime). > > Changes since v1: > - allow udelay() to be 0.5% faster than requested as per feedback > > Changes since v2: > - fix permissions on udelay_test.sh script > - update commit message to indicate what this test targets > - fixed checkpatch whitespace error > - rebased > > Changes since v3: > - fixed xtensa compile warning (and other 32-bit platforms which > use the generic do_div) > - renamed and moved config option > > David Riley (2): > kernel: time: Add udelay_test module to validate udelay > tools: add script to test udelay > > kernel/time/Makefile | 1 + > kernel/time/udelay_test.c | 168 > ++ > lib/Kconfig.debug | 9 +++ > tools/time/udelay_test.sh | 66 ++ > 4 files changed, 244 insertions(+) > create mode 100644 kernel/time/udelay_test.c > create mode 100755 tools/time/udelay_test.sh > > -- > 2.0.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include: kernel.h: rewrite min3, max3 and clamp using min and max
On Mon, 16 Jun 2014, Andrew Morton wrote:
> On Mon, 16 Jun 2014 16:25:15 -0700 (PDT) David Rientjes
> wrote:
>
> > On Mon, 16 Jun 2014, Andrew Morton wrote:
> >
> > > > It appears that gcc is better at optimising a double call to min
> > > > and max rather than open coded min3 and max3. This can be observed
> > > > here:
> > > >
> > > > ...
> > > >
> > > > Furthermore, after ___make allmodconfig && make bzImage modules___ this
> > > > is the
> > > > comparison of image and modules sizes:
> > > >
> > > > # Without this patch applied
> > > > $ ls -l arch/x86/boot/bzImage **/*.ko |awk '{size += $5} END {print
> > > > size}'
> > > > 350715800
> > > >
> > > > # With this patch applied
> > > > $ ls -l arch/x86/boot/bzImage **/*.ko |awk '{size += $5} END {print
> > > > size}'
> > > > 349856528
> > >
> > > We saved nearly a megabyte by optimising min3(), max3() and clamp()?
> > >
> > > I'm counting a grand total of 182 callsites for those macros. So the
> > > saving is 4700 bytes per invokation? I don't believe it...
> > >
> >
> > I was checking just the instances of min3() in mm/ and gcc ends up
> > inlining transfer_objects() in mm/slab.c as a result of this change and
> > increases its text size:
> >
> >textdata bss dec hex filename
> > 28369 21559 4 49932c30c slab.o.before
> > 28399 21559 4 49962c32a slab.o.after
>
> Maybe that's a good thing in disguise: gcc said "hey this thing is now
> small enough to inline it".
>
On linux-next, allyesconfig has a 0.0001% savings as a result of the
patch, but I'd be worried about the extra temp variable it allocates on
the stack that is evident in the mm/slab.c disassembly unless all cases
can be audited to show that we're not potentially deep.
textdata bss dec hex filename
108573045 2348801651580928183641989 af22785
vmlinux.before
108572908 2348801651580928183641852 af226fc
vmlinux.after
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] offb: Fix little-endian support
On Mon, 2014-06-16 at 17:35 +1000, Benjamin Herrenschmidt wrote: > I somewhat doubt that this (and 5:5:5) actually work, do they ? the > green gets split into two separate fields, which we can't express > properly here... So the conclusion of further investigation is: - The right fix is to fix qemu to flip endian - There's an open discussion as to whether qemu could do it automatically when the guest endian changes on powerpc as a quick fix, the long run approach is to have a register to control it, I'm working on it. offb can then "learn" to flick it like it does the palette hack today. - If we want to ever support foreign endian offb with X, we need to do things a bit differently based on the foreign endian bit that is already there. - We must revert the existing cmap swap patch from the kernel, it's broken and will break things when we fix qemu (and breaks with real HW in LE mode). I've sent a revert request to Linus and CC'ed stable. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/vmscan.c: avoid recording the original scan targets in shrink_lruvec()
On Mon, 2014-06-16 at 16:42 -0700, Andrew Morton wrote: > On Mon, 16 Jun 2014 20:57:54 +0800 Chen Yucong wrote: > > > On Mon, 2014-06-09 at 21:27 +0800, Chen Yucong wrote: > > > Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the > > > original scan targets introduces extra 40 bytes on the stack. This patch > > > is able to avoid this situation and the call to memcpy(). At the same > > > time, > > > it does not change the relative design idea. > > > > > > ratio = original_nr_file / original_nr_anon; > > > > > > If (nr_file > nr_anon), then ratio = (nr_file - x) / nr_anon. > > > x = nr_file - ratio * nr_anon; > > > > > > if (nr_file <= nr_anon), then ratio = nr_file / (nr_anon - x). > > > x = nr_anon - nr_file / ratio; > > > > > Hi Andrew Morton, > > > > I think the patch > > > > [PATCH] > > mm-vmscanc-avoid-recording-the-original-scan-targets-in-shrink_lruvec-fix.patch > > > > which I committed should be discarded. > > OK, thanks. > > I assume you're referring to > mm-vmscanc-avoid-recording-the-original-scan-targets-in-shrink_lruvec.patch > - I don't think a -fix.patch existed? Yes. the patch that should be discarded is mm-vmscanc-avoid-recording-the-original-scan-targets-in-shrink_lruvec.patch thx! cyc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/vmscan.c: avoid recording the original scan targets in shrink_lruvec()
On Mon, Jun 16, 2014 at 04:42:37PM -0700, Andrew Morton wrote: > On Mon, 16 Jun 2014 20:57:54 +0800 Chen Yucong wrote: > > > On Mon, 2014-06-09 at 21:27 +0800, Chen Yucong wrote: > > > Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the > > > original scan targets introduces extra 40 bytes on the stack. This patch > > > is able to avoid this situation and the call to memcpy(). At the same > > > time, > > > it does not change the relative design idea. > > > > > > ratio = original_nr_file / original_nr_anon; > > > > > > If (nr_file > nr_anon), then ratio = (nr_file - x) / nr_anon. > > > x = nr_file - ratio * nr_anon; > > > > > > if (nr_file <= nr_anon), then ratio = nr_file / (nr_anon - x). > > > x = nr_anon - nr_file / ratio; > > > > > Hi Andrew Morton, > > > > I think the patch > > > > [PATCH] > > mm-vmscanc-avoid-recording-the-original-scan-targets-in-shrink_lruvec-fix.patch > > > > which I committed should be discarded. > > OK, thanks. > > I assume you're referring to > mm-vmscanc-avoid-recording-the-original-scan-targets-in-shrink_lruvec.patch True. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib.c: skip --param parameters
On Mon, 16 Jun 2014, Josh Triplett wrote:
> On Mon, Jun 16, 2014 at 01:43:06PM +0300, Andy Shevchenko wrote:
> > Very dumb patch to just skip --param allow-store-data-races=0 introduced in
> > newest Linux kernel buildsystem.
> >
> > Actually the option is present in few GCC versions and probably should be
> > handled properly.
> >
> > Signed-off-by: Andy Shevchenko
>
> As far as I can tell, this seems to only handle "--param arg"; however,
> according to the thread on LKML, GCC handles --param=arg as well. Could
> you please handle that variant too?
>
This is only from linux-next and not Linus's tree, correct?
Is this still necessary since the "./Makefile: tell gcc optimizer to never
introduce new data races" patch has been removed from -mm due to failures?
See http://marc.info/?l=linux-mm-commits=140295825623471
> > lib.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/lib.c b/lib.c
> > index bf3e91c..e56037b 100644
> > --- a/lib.c
> > +++ b/lib.c
> > @@ -673,6 +673,12 @@ static char **handle_version(char *arg, char **next)
> > exit(0);
> > }
> >
> > +static char **handle_param(char *arg, char **next)
> > +{
> > + ++next;
> > + return ++next;
> > +}
> > +
> > struct switches {
> > const char *name;
> > char **(*fn)(char *, char **);
> > @@ -681,6 +687,7 @@ struct switches {
> > static char **handle_long_options(char *arg, char **next)
> > {
> > static struct switches cmd[] = {
> > + { "param", handle_param },
> > { "version", handle_version },
> > { NULL, NULL }
> > };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/vmscan.c: avoid recording the original scan targets in shrink_lruvec()
On Mon, Jun 16, 2014 at 08:57:54PM +0800, Chen Yucong wrote:
> On Mon, 2014-06-09 at 21:27 +0800, Chen Yucong wrote:
> > Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the
> > original scan targets introduces extra 40 bytes on the stack. This patch
> > is able to avoid this situation and the call to memcpy(). At the same time,
> > it does not change the relative design idea.
> >
> > ratio = original_nr_file / original_nr_anon;
> >
> > If (nr_file > nr_anon), then ratio = (nr_file - x) / nr_anon.
> > x = nr_file - ratio * nr_anon;
> >
> > if (nr_file <= nr_anon), then ratio = nr_file / (nr_anon - x).
> > x = nr_anon - nr_file / ratio;
> >
> Hi Andrew Morton,
>
> I think the patch
>
> [PATCH]
> mm-vmscanc-avoid-recording-the-original-scan-targets-in-shrink_lruvec-fix.patch
>
> which I committed should be discarded. Because It have some critical
> defects.
> 1) If we want to solve the divide-by-zero and unfair problems, it
> needs to two variables for recording the ratios.
>
> 2) For "x = nr_file - ratio * nr_anon", the "x" is likely to be a
> negative number. we can assume:
>
> nr[LRU_ACTIVE_FILE] = 30
> nr[LRU_INACTIVE_FILE] = 30
> nr[LRU_ACTIVE_ANON] = 0
> nr[LRU_INACTIVE_ANON] = 40
>
> ratio = 60/40 = 3/2
>
> When the value of (nr_reclaimed < nr_to_reclaim) become false, there are
> the following results:
> nr[LRU_ACTIVE_FILE] = 15
> nr[LRU_INACTIVE_FILE] = 15
> nr[LRU_ACTIVE_ANON] = 0
> nr[LRU_INACTIVE_ANON] = 25
>
> nr_file = 30
> nr_anon = 25
>
> x = 30 - 25 * (3/2) = 30 - 37.5 = -7.5.
>
> The result is too terrible.
>
>3) This method is less accurate than the original, especially for the
> qualitative difference between FILE and ANON that is very small.
Yes, 3 changed old behavior. I'm ashamed but wanted to clean it up.
Is it worth to clean it up?
>From aedf8288e28a07bdd6c459a403f21cc2615ecc4e Mon Sep 17 00:00:00 2001
From: Minchan Kim
Date: Tue, 17 Jun 2014 08:36:56 +0900
Subject: [PATCH] mm: proportional scanning cleanup
It aims for clean up, not changing behaivor so if anyone doesn't
looks it's more readable or not enough for readability, it should
really drop.
Signed-off-by: Minchan Kim
---
mm/vmscan.c | 69 -
1 file changed, 36 insertions(+), 33 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 0f16ffe8eb67..acc29315bad0 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2054,19 +2054,18 @@ out:
*/
static void shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc)
{
- unsigned long nr[NR_LRU_LISTS];
unsigned long targets[NR_LRU_LISTS];
- unsigned long nr_to_scan;
+ unsigned long remains[NR_LRU_LISTS];
enum lru_list lru;
unsigned long nr_reclaimed = 0;
unsigned long nr_to_reclaim = sc->nr_to_reclaim;
struct blk_plug plug;
bool scan_adjusted;
- get_scan_count(lruvec, sc, nr);
+ get_scan_count(lruvec, sc, targets);
- /* Record the original scan target for proportional adjustments later */
- memcpy(targets, nr, sizeof(nr));
+ /* Keep the original scan target for proportional adjustments later */
+ memcpy(remains, targets, sizeof(targets));
/*
* Global reclaiming within direct reclaim at DEF_PRIORITY is a normal
@@ -2083,19 +2082,21 @@ static void shrink_lruvec(struct lruvec *lruvec, struct
scan_control *sc)
sc->priority == DEF_PRIORITY);
blk_start_plug();
- while (nr[LRU_INACTIVE_ANON] || nr[LRU_ACTIVE_FILE] ||
- nr[LRU_INACTIVE_FILE]) {
- unsigned long nr_anon, nr_file, percentage;
- unsigned long nr_scanned;
+ while (remains[LRU_INACTIVE_ANON] || remains[LRU_ACTIVE_FILE] ||
+ remains[LRU_INACTIVE_FILE]) {
+ unsigned long target, remain_anon, remain_file;
+ unsigned long percentage;
+ unsigned long nr_scanned, nr_to_scan;
for_each_evictable_lru(lru) {
- if (nr[lru]) {
- nr_to_scan = min(nr[lru], SWAP_CLUSTER_MAX);
- nr[lru] -= nr_to_scan;
+ if (!remains[lru])
+ continue;
- nr_reclaimed += shrink_list(lru, nr_to_scan,
- lruvec, sc);
- }
+ nr_to_scan = min(remains[lru], SWAP_CLUSTER_MAX);
+ remains[lru] -= nr_to_scan;
+
+ nr_reclaimed += shrink_list(lru, nr_to_scan,
+ lruvec, sc);
}
if (nr_reclaimed < nr_to_reclaim || scan_adjusted)
@@ -2108,8 +2109,10 @@ static void
Re: [PATCH] infiniband: Fixes memory leak in send_flowc
On Mon, 16 Jun 2014, Steve Wise wrote:
> On 6/16/2014 12:49 PM, Nicholas Krause wrote:
> > Signed-off-by: Nicholas Krause
> > ---
> > drivers/infiniband/hw/cxgb4/cm.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/infiniband/hw/cxgb4/cm.c
> > b/drivers/infiniband/hw/cxgb4/cm.c
> > index 5e153f6..867e664 100644
> > --- a/drivers/infiniband/hw/cxgb4/cm.c
> > +++ b/drivers/infiniband/hw/cxgb4/cm.c
> > @@ -455,8 +455,11 @@ static void send_flowc(struct c4iw_ep *ep, struct
> > sk_buff *skb)
> > unsigned int flowclen = 80;
> > struct fw_flowc_wr *flowc;
> > int i;
> > -
>
> Please add back the above blank line.
>
> > skb = get_skb(skb, flowclen, GFP_KERNEL);
> > + if (!skb) {
> > + kfree_skb(skb);
>
> Let's do a pr_warn() here;
>
> pr_warn(MOD "%s failed to allocate skb.\n", __func__);
>
No need, if the allocation from skbuff_head_cache fails in the slab
allocator, the page allocator will loop forever for orders less than
PAGE_ALLOC_COSTLY_ORDER or spew a page allocation failure warning with a
stack trace that indicated the high order page allocation failed in this
path.
>
> > + return;
> > + }
> > flowc = (struct fw_flowc_wr *)__skb_put(skb, flowclen);
> > flowc->op_to_nparams = cpu_to_be32(FW_WR_OP(FW_FLOWC_WR) |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Networking
On Mon, Jun 16, 2014 at 07:04:50PM -0400, Dave Jones wrote:
> On Sun, Jun 15, 2014 at 07:33:12PM -0700, David Miller wrote:
>
> > 1) Fix checksumming regressions, from Tom Herbert.
>
> Something still not right for me here.
> After about 5 minutes, I get an oops and then instant reboot/lock up.
>
> I haven't managed to get a trace over usb-serial because it seems to
> crash before it completes. Hand transcribed one looks like..
>
> rbp: 880236403970 r08: r09:
> r10: 005a r11: 02d7 f12: 880233000d80
> r13: 8800aa1a6fc2 r14: 880233001d40 f15: ac82
> fs: 0 fs: 88023640 knlGS: 0
> CS: 10 DS: 0 ES: 0 CR0: 80050033
> CR2: 8800aa1a8000 CR3: 1a0d000 CR4: 407f0
> Stack:
> 880236403988 81298bbc 16c0 8802364039e8
> 814ca05a 880233001d40 05a8e397 880233001680
> 0d420685ac82 012a 004e
> Call Trace:
>
> csum_partial
> tcp_gso_segment
> inet_gso_segment
> ? update_dl_migration
> skb_mac_gso_segment
> __skb_gso_segment
> dev_hard_start_xmit
> sch_direct_xmit
> __dev_queue_xmit
> ? dev_hard_start_xmit
> dev_queue_xmit
> ip_finish_output
> ? ip_output
> ip_output
> ip_forward_finish
> ip_forward
> ip_rcv_finish
> ip_rcv
> __netif_receive_skb_core
> ? __netif_receive_skb_core
> ? trace_hardirqs_on
> __netif_receive_skb
> netif_receive_skb_internal
> napi_gro_complete
> ? napi_gro_complete
> dev_gro_receive
> ? dev_gro_receive
> napi_gro_receive
> rtl8169_poll
> net_rx_action
> __do_softirq
> irq_exit
> do_IRQ
> common_interrupt
>
> cpuidle_enter_state
> cpuidle_enter
> cpu_startup_entry
> rest_init
> ? csum_partial_copy_generic
> start_kernel
> RIP: do_csum+0x83/0x180
>
> Code: 41 89 d2 74 45 89 d1 45 31 c0 48 89 fa 0f 1f 00 48 03 02 48 13 42
> 08 48 13 42 10 48 13 42 20 48 13 42 28 48 13 42 30 <48> 13 42 38 4c 11
> c0 48 83 c2 40 83 e9 01 75 d5 41 83 ea 01 49
>
> All code
>
>0:41 89 d2mov%edx,%r10d
>3:74 45 je 0x4a
>5:89 d1 mov%edx,%ecx
>7:45 31 c0xor%r8d,%r8d
>a:48 89 famov%rdi,%rdx
>d:0f 1f 00nopl (%rax)
> 10:48 03 02add(%rdx),%rax
> 13:48 13 42 08 adc0x8(%rdx),%rax
> 17:48 13 42 10 adc0x10(%rdx),%rax
> 1b:48 13 42 20 adc0x20(%rdx),%rax
> 1f:48 13 42 28 adc0x28(%rdx),%rax
> 23:48 13 42 30 adc0x30(%rdx),%rax
> 27:* 48 13 42 38 adc0x38(%rdx),%rax <-- trapping
> instruction
> 2b:4c 11 c0adc%r8,%rax
> 2e:48 83 c2 40 add$0x40,%rdx
> 32:83 e9 01sub$0x1,%ecx
> 35:75 d5 jne0xc
> 37:41 83 ea 01 sub$0x1,%r10d
> 3b:49 rex.WB
>
> Typical, rdx and rax had scrolled off the screen.
after removing the dump_stack invocations, I noticed that the reason
this is rebooting is probably because right after the initial oops
we hit the WARN_ON at arch/x86/kernel/smp.c:124
if (unlikely(cpu_is_offline(cpu))) {
WARN_ON(1);
return;
}
lol.
Anwyay, before all that nonsense, I now have the top of the oops..
BUG: unable to handle kernel paging request at 880218c18000
IP: do_csum+0x68
PGD: 2c6a067 PUD: 2c6d067 PMD 23fd1c067 PTE: 8000218c18060
RAX: 2090539bbf7b28f2 RBX: acb23d4e RCX: 000b
RDX: 880218c18000 RSI: 1c62 RDI: 880218c16680
Maybe also notable here is that the kernel is built with DEBUG_PAGEALLOC on.
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/
Re: [PATCHv5 2/3] regulator: s2mps11: Add support S2MPU02 regulator device
Hi Lee, On 06/16/2014 10:19 PM, Lee Jones wrote: > On Mon, 16 Jun 2014, Chanwoo Choi wrote: > >> This patch add S2MPU02 regulator device to existing S2MPS11 device driver >> because of little difference between S2MPS1x and S2MPU02. The S2MPU02 >> regulator device includes LDO[1-28] and BUCK[1-7]. >> >> Signed-off-by: Chanwoo Choi >> [Add missing linear_min_sel of S2MPU02 LDO regulators by Jonghwa Lee] >> Signed-off-by: Jonghwa Lee >> Reviewed-by: Krzysztof Kozlowski >> Acked-by: Mark Brown >> --- >> drivers/mfd/sec-core.c | 25 +++ >> drivers/regulator/s2mps11.c | 321 >> +--- >> include/linux/mfd/samsung/s2mpu02.h | 201 ++ >> 3 files changed, 526 insertions(+), 21 deletions(-) >> create mode 100644 include/linux/mfd/samsung/s2mpu02.h > > MFD changes look good to me. > > Acked-by: Lee Jones Thanks. > > I assume we have to wait for the other patches to be ready before > applying this one? We don't need to wait for the other patches because related patches was already merged on Linux 3.16-rc1. Best Regards, 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] mm/vmscan.c: avoid recording the original scan targets in shrink_lruvec()
On Mon, 16 Jun 2014 20:57:54 +0800 Chen Yucong wrote: > On Mon, 2014-06-09 at 21:27 +0800, Chen Yucong wrote: > > Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the > > original scan targets introduces extra 40 bytes on the stack. This patch > > is able to avoid this situation and the call to memcpy(). At the same time, > > it does not change the relative design idea. > > > > ratio = original_nr_file / original_nr_anon; > > > > If (nr_file > nr_anon), then ratio = (nr_file - x) / nr_anon. > > x = nr_file - ratio * nr_anon; > > > > if (nr_file <= nr_anon), then ratio = nr_file / (nr_anon - x). > > x = nr_anon - nr_file / ratio; > > > Hi Andrew Morton, > > I think the patch > > [PATCH] > mm-vmscanc-avoid-recording-the-original-scan-targets-in-shrink_lruvec-fix.patch > > which I committed should be discarded. OK, thanks. I assume you're referring to mm-vmscanc-avoid-recording-the-original-scan-targets-in-shrink_lruvec.patch - I don't think a -fix.patch existed? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] include: kernel.h: rewrite min3, max3 and clamp using min and max
On Mon, 16 Jun 2014 16:25:15 -0700 (PDT) David Rientjes
wrote:
> On Mon, 16 Jun 2014, Andrew Morton wrote:
>
> > > It appears that gcc is better at optimising a double call to min
> > > and max rather than open coded min3 and max3. This can be observed
> > > here:
> > >
> > > ...
> > >
> > > Furthermore, after ___make allmodconfig && make bzImage modules___ this
> > > is the
> > > comparison of image and modules sizes:
> > >
> > > # Without this patch applied
> > > $ ls -l arch/x86/boot/bzImage **/*.ko |awk '{size += $5} END {print
> > > size}'
> > > 350715800
> > >
> > > # With this patch applied
> > > $ ls -l arch/x86/boot/bzImage **/*.ko |awk '{size += $5} END {print
> > > size}'
> > > 349856528
> >
> > We saved nearly a megabyte by optimising min3(), max3() and clamp()?
> >
> > I'm counting a grand total of 182 callsites for those macros. So the
> > saving is 4700 bytes per invokation? I don't believe it...
> >
>
> I was checking just the instances of min3() in mm/ and gcc ends up
> inlining transfer_objects() in mm/slab.c as a result of this change and
> increases its text size:
>
>text data bss dec hex filename
> 28369 21559 4 49932c30c slab.o.before
> 28399 21559 4 49962c32a slab.o.after
Maybe that's a good thing in disguise: gcc said "hey this thing is now
small enough to inline it".
> It also seems to use one additional temp variable of type typeof(x) on the
> stack, so I do think the old version was superior.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the akpm-current tree
On Fri, 13 Jun 2014 15:16:52 +1000 Stephen Rothwell wrote: > At this point I got fed up and just dropped the akpm trees completely for > today. > > Was this stuff really meant for v3.16? 3.14 actually. Then 3.15. Now 3.16. It's been quiet a burden and seems to have been hitting more problems lately. It's unclear than it does much for efficiency and while the end result may be clearer to a newcomer, there's a cost to existing developers in churning the code around. So... I think I'll drop this version of the patchset. Naoya, please grab all the patches as they fly past and ensure that nothing gets lost in any future version, thanks. I'll retain mm-hugetlbfs-fix-rmapping-for-anonymous-hugepages-with-page_pgoff.patch mm-hugetlbfs-fix-rmapping-for-anonymous-hugepages-with-page_pgoff-v2.patch mm-hugetlbfs-fix-rmapping-for-anonymous-hugepages-with-page_pgoff-v3.patch mm-hugetlbfs-fix-rmapping-for-anonymous-hugepages-with-page_pgoff-v3-fix.patch and shall drop pagewalk-update-page-table-walker-core.patch pagewalk-update-page-table-walker-core-fix-end-address-calculation-in-walk_page_range.patch pagewalk-update-page-table-walker-core-fix-end-address-calculation-in-walk_page_range-fix.patch pagewalk-update-page-table-walker-core-fix.patch pagewalk-add-walk_page_vma.patch smaps-redefine-callback-functions-for-page-table-walker.patch clear_refs-redefine-callback-functions-for-page-table-walker.patch pagemap-redefine-callback-functions-for-page-table-walker.patch pagemap-redefine-callback-functions-for-page-table-walker-fix.patch numa_maps-redefine-callback-functions-for-page-table-walker.patch memcg-redefine-callback-functions-for-page-table-walker.patch arch-powerpc-mm-subpage-protc-use-walk_page_vma-instead-of-walk_page_range.patch pagewalk-remove-argument-hmask-from-hugetlb_entry.patch pagewalk-remove-argument-hmask-from-hugetlb_entry-fix.patch pagewalk-remove-argument-hmask-from-hugetlb_entry-fix-fix.patch mempolicy-apply-page-table-walker-on-queue_pages_range.patch mm-pagewalkc-move-pte-null-check.patch mm-prom-pid-clear_refs-avoid-split_huge_page.patch mm-pagewalk-remove-pgd_entry-and-pud_entry.patch mm-pagewalk-replace-mm_walk-skip-with-more-general-mm_walk-control.patch mm-pagewalk-replace-mm_walk-skip-with-more-general-mm_walk-control-fix.patch madvise-cleanup-swapin_walk_pmd_entry.patch madvise-cleanup-swapin_walk_pmd_entry-fix.patch memcg-separate-mem_cgroup_move_charge_pte_range.patch memcg-separate-mem_cgroup_move_charge_pte_range-checkpatch-fixes.patch arch-powerpc-mm-subpage-protc-cleanup-subpage_walk_pmd_entry.patch mm-pagewalk-move-pmd_trans_huge_lock-from-callbacks-to-common-code.patch mm-pagewalk-move-pmd_trans_huge_lock-from-callbacks-to-common-code-checkpatch-fixes.patch mincore-apply-page-table-walker-on-do_mincore.patch mincore-apply-page-table-walker-on-do_mincore-fix.patch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include: kernel.h: rewrite min3, max3 and clamp using min and max
On Mon, 16 Jun 2014, Andrew Morton wrote:
> > It appears that gcc is better at optimising a double call to min
> > and max rather than open coded min3 and max3. This can be observed
> > here:
> >
> > ...
> >
> > Furthermore, after ___make allmodconfig && make bzImage modules___ this is
> > the
> > comparison of image and modules sizes:
> >
> > # Without this patch applied
> > $ ls -l arch/x86/boot/bzImage **/*.ko |awk '{size += $5} END {print
> > size}'
> > 350715800
> >
> > # With this patch applied
> > $ ls -l arch/x86/boot/bzImage **/*.ko |awk '{size += $5} END {print
> > size}'
> > 349856528
>
> We saved nearly a megabyte by optimising min3(), max3() and clamp()?
>
> I'm counting a grand total of 182 callsites for those macros. So the
> saving is 4700 bytes per invokation? I don't believe it...
>
I was checking just the instances of min3() in mm/ and gcc ends up
inlining transfer_objects() in mm/slab.c as a result of this change and
increases its text size:
textdata bss dec hex filename
28369 21559 4 49932c30c slab.o.before
28399 21559 4 49962c32a slab.o.after
It also seems to use one additional temp variable of type typeof(x) on the
stack, so I do think the old version was superior.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] include: kernel.h: rewrite min3, max3 and clamp using min and max
On Mon, 16 Jun 2014 23:07:22 +0200 Michal Nazarewicz wrote:
> It appears that gcc is better at optimising a double call to min
> and max rather than open coded min3 and max3. This can be observed
> here:
>
> ...
>
> Furthermore, after ___make allmodconfig && make bzImage modules___ this is the
> comparison of image and modules sizes:
>
> # Without this patch applied
> $ ls -l arch/x86/boot/bzImage **/*.ko |awk '{size += $5} END {print size}'
> 350715800
>
> # With this patch applied
> $ ls -l arch/x86/boot/bzImage **/*.ko |awk '{size += $5} END {print size}'
> 349856528
We saved nearly a megabyte by optimising min3(), max3() and clamp()?
I'm counting a grand total of 182 callsites for those macros. So the
saving is 4700 bytes per invokation? I don't believe it...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: page_alloc: simplify drain_zone_pages by using min()
On Mon, 16 Jun 2014 23:08:14 +0200 Michal Nazarewicz wrote: > Instead of open-coding getting minimal value of two, just use min macro. > That is why it is there for. While changing the function also change > type of batch local variable to match type of per_cpu_pages::batch > (which is int). > I'm not sure why we made all the per_cpu_pages mambers `int'. Unsigned would make more sense. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 02/11] coresight: add CoreSight TMC driver
Thanks for the review - please see comments in-lined.
Mathieu
On 3 June 2014 03:09, Linus Walleij wrote:
> On Fri, May 30, 2014 at 3:43 PM, wrote:
>
>> +#define tmc_writel(drvdata, val, off) __raw_writel((val), drvdata->base +
>> off)
>> +#define tmc_readl(drvdata, off)__raw_readl(drvdata->base +
>> off)
>
> Why not writel_relaxed()/readl_relaxed()?
Done.
>
> Using __raw* accessors seem a bit thick. (Applies to all such defines.)
>
>> +#define TMC_LOCK(drvdata) \
>> +do { \
>> + /* settle everything first */ \
>> + mb(); \
>> + tmc_writel(drvdata, 0x0, CORESIGHT_LAR);\
>> +} while (0)
>> +#define TMC_UNLOCK(drvdata)\
>> +do { \
>> + tmc_writel(drvdata, CORESIGHT_UNLOCK, CORESIGHT_LAR); \
>> + /* make sure everyone sees this */ \
>> + mb(); \
>> +} while (0)
>
> Convert these to static inlines. No need for them to be #defines
> at all really.
Done.
>
>> +#define BYTES_PER_WORD 4
>
> But please. Just using the number 4 everywhere is clear enough.
>
>> +struct tmc_drvdata {
>> + void __iomem*base;
>> + struct device *dev;
>> + struct coresight_device *csdev;
>> + struct miscdevice miscdev;
>> + struct clk *clk;
>> + spinlock_t spinlock;
>> + int read_count;
>
> Can this really be negative?
It is useful for debugging, as an example see "tmc_release()". If the
count drops below '0' there is obviously a problem. Do you see a cost
in keeping this as an 'int'? What do you advise here?
>
>> + boolreading;
>> + char*buf;
>> + dma_addr_t paddr;
>> + void __iomem*vaddr;
>> + uint32_tsize;
>
> Use u32
>
>> + boolenable;
>> + enum tmc_config_typeconfig_type;
>> + uint32_ttrigger_cntr;
>
> Use u32
>
>> +};
>
> This struct overall could use some kerneldoc.
Would writing a comment for each field qualify?
>
>> +static void tmc_flush_and_stop(struct tmc_drvdata *drvdata)
>> +{
>> + int count;
>
> Why not call this variable "i" as per convention.
>
>> + uint32_t ffcr;
>
> u32
>
>> +
>> + ffcr = tmc_readl(drvdata, TMC_FFCR);
>> + ffcr |= BIT(12);
>> + tmc_writel(drvdata, ffcr, TMC_FFCR);
>> + ffcr |= BIT(6);
>
> A bit unclear what bit 12 and 6 does. Either #define them or add comments.
>
>> + tmc_writel(drvdata, ffcr, TMC_FFCR);
>> + /* Ensure flush completes */
>> + for (count = TIMEOUT_US; BVAL(tmc_readl(drvdata, TMC_FFCR), 6) != 0
>> + && count > 0; count--)
>> + udelay(1);
>> + WARN(count == 0, "timeout while flushing TMC, TMC_FFCR: %#x\n",
>> +tmc_readl(drvdata, TMC_FFCR));
>> +
>> + tmc_wait_for_ready(drvdata);
>> +}
>> +
>> +static void __tmc_enable(struct tmc_drvdata *drvdata)
>> +{
>> + tmc_writel(drvdata, 0x1, TMC_CTL);
>> +}
>> +
>> +static void __tmc_disable(struct tmc_drvdata *drvdata)
>> +{
>> + tmc_writel(drvdata, 0x0, TMC_CTL);
>> +}
>
> I actually understand what bit 0 does in this register, but could
> also be #defined.
>
>> +static void __tmc_etb_enable(struct tmc_drvdata *drvdata)
>> +{
>> + /* Zero out the memory to help with debug */
>> + memset(drvdata->buf, 0, drvdata->size);
>> +
>> + TMC_UNLOCK(drvdata);
>> +
>> + tmc_writel(drvdata, TMC_MODE_CIRCULAR_BUFFER, TMC_MODE);
>> + tmc_writel(drvdata, 0x133, TMC_FFCR);
>
> 0x133? Que ce que c'est?
>
>> + tmc_writel(drvdata, drvdata->trigger_cntr, TMC_TRG);
>> + __tmc_enable(drvdata);
>> +
>> + TMC_LOCK(drvdata);
>> +}
>> +
>> +static void __tmc_etr_enable(struct tmc_drvdata *drvdata)
>> +{
>> + uint32_t axictl;
>
> u32
>
>> + /* Zero out the memory to help with debug */
>> + memset(drvdata->vaddr, 0, drvdata->size);
>> +
>> + TMC_UNLOCK(drvdata);
>> +
>> + tmc_writel(drvdata, drvdata->size / BYTES_PER_WORD, TMC_RSZ);
>> + tmc_writel(drvdata, TMC_MODE_CIRCULAR_BUFFER, TMC_MODE);
>> +
>> + axictl = tmc_readl(drvdata, TMC_AXICTL);
>> + axictl |= (0xF << 8);
>> + tmc_writel(drvdata, axictl, TMC_AXICTL);
>> + axictl &= ~(0x1 << 7);
>> + tmc_writel(drvdata, axictl, TMC_AXICTL);
>> + axictl = (axictl & ~0x3) | 0x2;
>> + tmc_writel(drvdata, axictl, TMC_AXICTL);
>
> I don't understand these bits and shifts either.
>
>> +
Re: [PATCH] mm: page_alloc: simplify drain_zone_pages by using min()
On Mon, 16 Jun 2014, Michal Nazarewicz wrote: > Instead of open-coding getting minimal value of two, just use min macro. > That is why it is there for. While changing the function also change > type of batch local variable to match type of per_cpu_pages::batch > (which is int). > > Signed-off-by: Michal Nazarewicz Acked-by: David Rientjes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Networking
On Sun, Jun 15, 2014 at 07:33:12PM -0700, David Miller wrote: > 1) Fix checksumming regressions, from Tom Herbert. Something still not right for me here. After about 5 minutes, I get an oops and then instant reboot/lock up. I haven't managed to get a trace over usb-serial because it seems to crash before it completes. Hand transcribed one looks like.. rbp: 880236403970 r08: r09: r10: 005a r11: 02d7 f12: 880233000d80 r13: 8800aa1a6fc2 r14: 880233001d40 f15: ac82 fs: 0 fs: 88023640 knlGS: 0 CS: 10 DS: 0 ES: 0 CR0: 80050033 CR2: 8800aa1a8000 CR3: 1a0d000 CR4: 407f0 Stack: 880236403988 81298bbc 16c0 8802364039e8 814ca05a 880233001d40 05a8e397 880233001680 0d420685ac82 012a 004e Call Trace: csum_partial tcp_gso_segment inet_gso_segment ? update_dl_migration skb_mac_gso_segment __skb_gso_segment dev_hard_start_xmit sch_direct_xmit __dev_queue_xmit ? dev_hard_start_xmit dev_queue_xmit ip_finish_output ? ip_output ip_output ip_forward_finish ip_forward ip_rcv_finish ip_rcv __netif_receive_skb_core ? __netif_receive_skb_core ? trace_hardirqs_on __netif_receive_skb netif_receive_skb_internal napi_gro_complete ? napi_gro_complete dev_gro_receive ? dev_gro_receive napi_gro_receive rtl8169_poll net_rx_action __do_softirq irq_exit do_IRQ common_interrupt cpuidle_enter_state cpuidle_enter cpu_startup_entry rest_init ? csum_partial_copy_generic start_kernel RIP: do_csum+0x83/0x180 Code: 41 89 d2 74 45 89 d1 45 31 c0 48 89 fa 0f 1f 00 48 03 02 48 13 42 08 48 13 42 10 48 13 42 20 48 13 42 28 48 13 42 30 <48> 13 42 38 4c 11 c0 48 83 c2 40 83 e9 01 75 d5 41 83 ea 01 49 All code 0: 41 89 d2mov%edx,%r10d 3: 74 45 je 0x4a 5: 89 d1 mov%edx,%ecx 7: 45 31 c0xor%r8d,%r8d a: 48 89 famov%rdi,%rdx d: 0f 1f 00nopl (%rax) 10: 48 03 02add(%rdx),%rax 13: 48 13 42 08 adc0x8(%rdx),%rax 17: 48 13 42 10 adc0x10(%rdx),%rax 1b: 48 13 42 20 adc0x20(%rdx),%rax 1f: 48 13 42 28 adc0x28(%rdx),%rax 23: 48 13 42 30 adc0x30(%rdx),%rax 27:* 48 13 42 38 adc0x38(%rdx),%rax <-- trapping instruction 2b: 4c 11 c0adc%r8,%rax 2e: 48 83 c2 40 add$0x40,%rdx 32: 83 e9 01sub$0x1,%ecx 35: 75 d5 jne0xc 37: 41 83 ea 01 sub$0x1,%r10d 3b: 49 rex.WB Typical, rdx and rax had scrolled off the screen. I'll hobble some of the dump_stack output and see if I can get something useful. It's a two nic (both 8169's) box doing ip-masq and firewall duties. 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/
hi
Hello good day Did you recieve the mail i sent to y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/13] kexec: Implementation of new syscall kexec_file_load
On 06/16/2014 02:43 PM, Vivek Goyal wrote: >> >> Borislav and I talked about this briefly over IRC. A key part of that >> is that if userspace could manipulate this system call to consume an >> unreasonable amount of memory, we would have a problem, for example if >> this code used vzalloc() instead of kzalloc(). However, since >> kmalloc/kzalloc implies a relatively restrictive limit on the memory >> allocation size anyway, well short of anything that could cause OOM >> problems, that pretty much solves the problem. > > Actually currently I am using vzalloc() for command line buffer > allocation. > > image->cmdline_buf = vzalloc(cmdline_len); > if (!image->cmdline_buf) > goto out; > > Should I switch to using kzalloc() instead? > Yes. There is absolutely no valid reason to use vzalloc() for an object that small, and if someone manipulates the header to allow for a crazily large command line then you can trick the kernel into allocating arbitrary amounts of memory. -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 1/5] futex: Make unlock_pi more robust
On Tue, 2014-06-17 at 00:28 +0200, Thomas Gleixner wrote: > On Tue, 17 Jun 2014, Thomas Gleixner wrote: > > On Mon, 16 Jun 2014, Darren Hart wrote: > > > On Wed, 2014-06-11 at 20:45 +, Thomas Gleixner wrote: > > > In wake_futex_pi we verify ownership by matching pi_state->owner == > > > current, but here the only test is the TID value, which is set by > > > userspace - which we don't trust... > > > > > > I'm trying to determine if it matters in this case... if there are no > > > waiters, is the pi_state still around? If so, it does indeed matter, and > > > we should be verifying. > > > > Erm. The whole point of this patch is to do: > > > > - Find existing state first and handle it. > > > > - If no state exists and TID == current, take it > > > > - Otherwise create state > > Duh, that was the lock path. But here the point is: > > - Find existing state first and handle it. > > - If no state exists and TID == current, release it > Right, I understood your meaning, and I withdraw the concern. > The retry is obvious, right? Yes. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] devicetree: bindings: separate CPU enable method descriptions
The bindings for CPU enable methods are defined in ".../arm/cpus.txt". As additional 32-bit ARM CPUS are converted to use the "enable-method" CPU property to imply a particular set of SMP operations to use, the list of these methods is likely to become unwieldy. The current documentation already contains several property descriptions that are meaningful only for certain enable methods. This patch defines a new Documentation subdirectory whose purpose is to give each CPU enable method its own place to define how and when it's used, as well as what other properties (optional or required) are associated with the method. The existing enable method documentation is expanded and moved from ".../arm/cpus.txt" into new files accordingly. Signed-off-by: Alex Elder --- v4 - Rebased on top of v3.16-rc1. - Added description files for recently-added enable methods: "allwinner,sun6i-a31" "marvell,armada-375-smp" "marvell,armada-380-smp" "marvell,armada-xp-smp" "rockchip,rk3066-smp" - Updated "psci.txt" with a 32-bit ARM example. v3 - Got rid of contrived examples. - Identified some compatible CPUs more generically (e.g. using "Any AArch64 CPU") rather than using only specific compatible string values. - Fixed and reworded the "psci" description (without incorporating "arm/psci.txt"). - Now provide a more real example for the "spin-table" method. v2 - Rename "arm,psci.txt" to be "psci.txt" and fix its content. .../bindings/arm/cpu-enable-method/README | 20 +++ .../arm/cpu-enable-method/allwinner,sun6i-a31 | 44 +++ .../arm/cpu-enable-method/marvell,armada-xp-smp| 34 +++ .../arm/cpu-enable-method/marvell,armada375-smp| 31 +++ .../arm/cpu-enable-method/marvell,armada380-smp| 32 +++ .../bindings/arm/cpu-enable-method/psci.txt| 65 ++ .../arm/cpu-enable-method/qcom,gcc-msm8660 | 42 ++ .../arm/cpu-enable-method/qcom,kpss-acc-v1 | 56 +++ .../arm/cpu-enable-method/qcom,kpss-acc-v2 | 56 +++ .../arm/cpu-enable-method/rockchip,rk3066-smp | 32 +++ .../bindings/arm/cpu-enable-method/spin-table.txt | 55 ++ Documentation/devicetree/bindings/arm/cpus.txt | 29 +- 12 files changed, 470 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/README create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/allwinner,sun6i-a31 create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/marvell,armada-xp-smp create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/marvell,armada375-smp create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/marvell,armada380-smp create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/psci.txt create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/qcom,gcc-msm8660 create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/qcom,kpss-acc-v1 create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/qcom,kpss-acc-v2 create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/rockchip,rk3066-smp create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/spin-table.txt diff --git a/Documentation/devicetree/bindings/arm/cpu-enable-method/README b/Documentation/devicetree/bindings/arm/cpu-enable-method/README new file mode 100644 index 000..cc9431e --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cpu-enable-method/README @@ -0,0 +1,20 @@ +== +CPU enable-method bindings +== + +The device tree describes the layout of CPUs in a machine in a single "cpus" +node, which in turn contains a number of "cpu" sub-nodes defining properties +for each cpu. + +For multiprocessing configurations, CPU cores can be individually enabled +and disabled. The enabling capability is used for SMP startup as well as +CPU hotplug. A CPU enable method--normally specified in the device tree +using an "enable-method" property--defines how cores are enabled. If all +CPUs in a machine use the same enable method and related property values, +these properties should be defined in the "cpus" node, which associates the +property values with all CPUs. Alternatively, every "cpu" node can define +its "enable-method" separately. + +Documents in this directory define how each of the CPU enable methods are to +be used, as well the names and possible values of related properties that +are required by or affect each enable method. diff --git a/Documentation/devicetree/bindings/arm/cpu-enable-method/allwinner,sun6i-a31 b/Documentation/devicetree/bindings/arm/cpu-enable-method/allwinner,sun6i-a31 new file mode 100644 index 000..bbc661e --- /dev/null
Re: [patch 1/5] futex: Make unlock_pi more robust
On Tue, 2014-06-17 at 00:15 +0200, Thomas Gleixner wrote:
> On Mon, 16 Jun 2014, Darren Hart wrote:
> > On Wed, 2014-06-11 at 20:45 +, Thomas Gleixner wrote:
> > > static int futex_unlock_pi(u32 __user *uaddr, unsigned int flags)
> > > @@ -2417,57 +2401,47 @@ retry:
> > > return -EPERM;
> > >
> > > ret = get_futex_key(uaddr, flags & FLAGS_SHARED, ,
> > > VERIFY_WRITE);
> > > - if (unlikely(ret != 0))
> > > - goto out;
> > > + if (ret)
> > > + return ret;
> >
> > Looks like you're also trying to move away from a single exit point to
> > multiple exit points. I prefer the single exit (which you've probably
> > noticed :-), but it's a subjective thing, and so long as we are not
> > duplicating cleanup logic, I guess it's fine either way. This change was
> > not mentioned in the commit message though.
>
> I really did not think about mentioning that :)
>
> > > +* Check waiters first. We do not trust user space values at
> > > +* all and we at least want to know if user space fiddled
> > > +* with the futex value instead of blindly unlocking.
> > > +*/
> > > + match = futex_top_waiter(hb, );
> > > + if (match) {
> > > + ret = wake_futex_pi(uaddr, uval, match);
> > > /*
> > > -* The atomic access to the futex value
> > > -* generated a pagefault, so retry the
> > > -* user-access and the wakeup:
> > > +* The atomic access to the futex value generated a
> > > +* pagefault, so retry the user-access and the wakeup:
> > > */
> > > if (ret == -EFAULT)
> > > goto pi_faulted;
> > > goto out_unlock;
> > > }
> > > +
> > > /*
> > > -* No waiters - kernel unlocks the futex:
> > > +* We have no kernel internal state, i.e. no waiters in the
> > > +* kernel. Waiters which are about to queue themself are stuck
> >
> > themselves
> >
> > > +* on hb->lock. So we can safely ignore them. We do neither
> > > +* preserve the WAITERS bit not the OWNER_DIED one. We are the
> >
> > We preserve neither the WAITERS bit nor the OWNER_DIED bit.
> > (the above use of "do" and "not" is incorrect and could easily be
> > misinterpreted).
> >
> > > +* owner.
> >
> > In wake_futex_pi we verify ownership by matching pi_state->owner ==
> > current, but here the only test is the TID value, which is set by
> > userspace - which we don't trust...
> >
> > I'm trying to determine if it matters in this case... if there are no
> > waiters, is the pi_state still around? If so, it does indeed matter, and
> > we should be verifying.
>
> Erm. The whole point of this patch is to do:
>
> - Find existing state first and handle it.hehheh
>
> - If no state exists and TID == current, take it
>
> - Otherwise create state
Right, by 5/5 I realized that, duh, if there are no waiters, you can't
find a pi_state to check, so we have no choice here. Sorry, should have
come back and said as much. We can drop this concern.
> This all happens under hb->lock. So how should something create new
> state after we looked up existing state?
>
> > > */
> > > - ret = unlock_futex_pi(uaddr, uval);
> > > - if (ret == -EFAULT)
> > > + if (cmpxchg_futex_value_locked(, uaddr, uval, 0))
> > > goto pi_faulted;
> > >
> >
> > This refactoring seems like it would be best done as a prequel patch so
> > as not to confuse cleanup with functional change. At least that is what
> > you and others have beaten into me over the years ;-)
>
> Well, yes and no. I'll hapilly discuss that without after clarifying
> the issue below.
>
> > > + /*
> > > +* If uval has changed, let user space handle it.
> > > +*/
> > > + ret = (curval == uval) ? 0 : -EAGAIN;
> > > +
> > > out_unlock:
> > > spin_unlock(>lock);
> > > put_futex_key();
> > > -
> > > -out:
> > > return ret;
> > >
> >
> > By dropping this you won't return ret, but rather fall through into
> > pi_faulted... which certainly isn't what you wanted.
>
> By dropping the now unused "out" label I'm not longer returning ret?
>
Sigh. Nevermind.
> The resulting code is:
>
> out_unlock:
> spin_unlock(>lock);
> put_futex_key();
> return ret;
>
> If you can explain me how that "return ret" falls through to
> pi_faulted magically, then I'm definitely agreeing with you on this:
>
> > The need for better test coverage is very evident now :-)
>
> -ENOTENOUGHSLEEP or -ENOTENOUGHCOFFEE or -ENOGLASSES perhaps?
>
> I'm omitting some other politicially incorrect speculations for now.
Guilty as charged, on all counts I'm afraid.
So, my only reservation is the possible splitting out of the refactoring
bit. But that's minor. Either way:
Reviewed-by:
[PATCH v3 0/3] IIO: Add support for rotation from north usage attributes
These patches add support for rotation from north HID usage attributes to the magnetometer 3d driver. Changes from v2: Use devm_kcalloc for all dynamic allocations Cleanup formatting of if statements Scan for the usage attributes present then dynamically allocate iio channel and value arrays Use proper return errors (-EINVAL) and (-ENOMEM) Reyad Attiyat (3): iio: documentation: Added documentation for rotation from north usage attributes iio: types: Added support for rotation from north usage attributes iio: hid-sensor-magn-3d: Add support for rotation from north usage attributes Documentation/ABI/testing/sysfs-bus-iio | 79 +- drivers/iio/industrialio-core.c | 4 + drivers/iio/magnetometer/hid-sensor-magn-3d.c | 394 +- include/linux/iio/types.h | 4 + 4 files changed, 352 insertions(+), 129 deletions(-) -- 1.9.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/
[PATCH v3 1/3] iio: documentation: Added documentation for rotation from north usage attributes
Added documentation for the sysfs attributes added by the rotation from north usage attributes. Signed-off-by: Reyad Attiyat --- Documentation/ABI/testing/sysfs-bus-iio | 79 - 1 file changed, 78 insertions(+), 1 deletion(-) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index a9757dc..2837fd9 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -260,6 +260,10 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_scale +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_scale +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_tilt_comp_scale +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale KernelVersion: 2.6.35 @@ -447,6 +451,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_thresh_rising_en What: /sys/.../iio:deviceX/events/in_magn_y_thresh_falling_en What: /sys/.../iio:deviceX/events/in_magn_z_thresh_rising_en What: /sys/.../iio:deviceX/events/in_magn_z_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en @@ -492,6 +504,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_roc_rising_en What: /sys/.../iio:deviceX/events/in_magn_y_roc_falling_en What: /sys/.../iio:deviceX/events/in_magn_z_roc_rising_en What: /sys/.../iio:deviceX/events/in_magn_z_roc_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_roc_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_roc_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_roc_rising_en @@ -538,6 +558,14 @@ What: /sys/.../events/in_magn_y_raw_thresh_rising_value What: /sys/.../events/in_magn_y_raw_thresh_falling_value What: /sys/.../events/in_magn_z_raw_thresh_rising_value What: /sys/.../events/in_magn_z_raw_thresh_falling_value +What: /sys/.../events/in_rot_from_north_magnetic_raw_thresh_rising_value +What: /sys/.../events/in_rot_from_north_magnetic_raw_thresh_falling_value +What: /sys/.../events/in_rot_from_north_true_raw_thresh_rising_value +What: /sys/.../events/in_rot_from_north_true_raw_thresh_falling_value +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_rising_value +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_falling_value +What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_rising_value +What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_falling_value What: /sys/.../events/in_voltageY_supply_raw_thresh_rising_value What: /sys/.../events/in_voltageY_supply_raw_thresh_falling_value What: /sys/.../events/in_voltageY_raw_thresh_rising_value @@
[PATCH v3 2/3] iio: types: Added support for rotation from north usage attributes
Added the rotation from north usage attributes to the iio modifier enum and to
the iio modifier names array.
Signed-off-by: Reyad Attiyat
---
drivers/iio/industrialio-core.c | 4
include/linux/iio/types.h | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 4b1f375..af3e76d 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -87,6 +87,10 @@ static const char * const iio_modifier_names[] = {
[IIO_MOD_QUATERNION] = "quaternion",
[IIO_MOD_TEMP_AMBIENT] = "ambient",
[IIO_MOD_TEMP_OBJECT] = "object",
+ [IIO_MOD_NORTH_MAGN] = "from_north_magnetic",
+ [IIO_MOD_NORTH_TRUE] = "from_north_true",
+ [IIO_MOD_NORTH_MAGN_TILT_COMP] = "from_north_magnetic_tilt_comp",
+ [IIO_MOD_NORTH_TRUE_TILT_COMP] = "from_north_true_tilt_comp",
};
/* relies on pairs of these shared then separate */
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index d480631..d09c40d 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -56,6 +56,10 @@ enum iio_modifier {
IIO_MOD_QUATERNION,
IIO_MOD_TEMP_AMBIENT,
IIO_MOD_TEMP_OBJECT,
+ IIO_MOD_NORTH_MAGN,
+ IIO_MOD_NORTH_TRUE,
+ IIO_MOD_NORTH_MAGN_TILT_COMP,
+ IIO_MOD_NORTH_TRUE_TILT_COMP
};
enum iio_event_type {
--
1.9.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/
[PATCH v3 3/3] iio: hid-sensor-magn-3d: Add support for rotation from north usage attributes
Added the ability for this driver to scan for a range of hid usage attributes.
This allows for dynamic creation of iio channels such as rotation from north
and/or magnetic flux axises (X, Y, Z).
Signed-off-by: Reyad Attiyat
---
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 394 +-
1 file changed, 266 insertions(+), 128 deletions(-)
diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index 41cf29e..73e1272 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -35,6 +35,10 @@ enum magn_3d_channel {
CHANNEL_SCAN_INDEX_X,
CHANNEL_SCAN_INDEX_Y,
CHANNEL_SCAN_INDEX_Z,
+ CHANNEL_SCAN_INDEX_NORTH_MAGN,
+ CHANNEL_SCAN_INDEX_NORTH_TRUE,
+ CHANNEL_SCAN_INDEX_NORTH_MAGN_TILT_COMP,
+ CHANNEL_SCAN_INDEX_NORTH_TRUE_TILT_COMP,
MAGN_3D_CHANNEL_MAX,
};
@@ -42,63 +46,47 @@ struct magn_3d_state {
struct hid_sensor_hub_callbacks callbacks;
struct hid_sensor_common common_attributes;
struct hid_sensor_hub_attribute_info magn[MAGN_3D_CHANNEL_MAX];
- u32 magn_val[MAGN_3D_CHANNEL_MAX];
+ u32 *magn_val_addr[MAGN_3D_CHANNEL_MAX];
+ u32 *iio_val;
int scale_pre_decml;
int scale_post_decml;
int scale_precision;
int value_offset;
};
-static const u32 magn_3d_addresses[MAGN_3D_CHANNEL_MAX] = {
- HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS,
- HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS,
- HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS
-};
-/* Channel definitions */
-static const struct iio_chan_spec magn_3d_channels[] = {
- {
- .type = IIO_MAGN,
- .modified = 1,
- .channel2 = IIO_MOD_X,
- .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
- .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
- BIT(IIO_CHAN_INFO_SCALE) |
- BIT(IIO_CHAN_INFO_SAMP_FREQ) |
- BIT(IIO_CHAN_INFO_HYSTERESIS),
- .scan_index = CHANNEL_SCAN_INDEX_X,
- }, {
- .type = IIO_MAGN,
- .modified = 1,
- .channel2 = IIO_MOD_Y,
- .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
- .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
- BIT(IIO_CHAN_INFO_SCALE) |
- BIT(IIO_CHAN_INFO_SAMP_FREQ) |
- BIT(IIO_CHAN_INFO_HYSTERESIS),
- .scan_index = CHANNEL_SCAN_INDEX_Y,
- }, {
- .type = IIO_MAGN,
- .modified = 1,
- .channel2 = IIO_MOD_Z,
- .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
- .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
- BIT(IIO_CHAN_INFO_SCALE) |
- BIT(IIO_CHAN_INFO_SAMP_FREQ) |
- BIT(IIO_CHAN_INFO_HYSTERESIS),
- .scan_index = CHANNEL_SCAN_INDEX_Z,
+/* Find index into magn_3d_state magn[] and magn_val_addr[] from HID Usage */
+static int magn_3d_usage_id_to_chan_index(unsigned usage_id){
+ int offset;
+
+ switch (usage_id) {
+ case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS:
+ offset = CHANNEL_SCAN_INDEX_X;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS:
+ offset = CHANNEL_SCAN_INDEX_Y;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS:
+ offset = CHANNEL_SCAN_INDEX_Z;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_COMP_MAGN_NORTH:
+ offset = CHANNEL_SCAN_INDEX_NORTH_MAGN_TILT_COMP;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_COMP_TRUE_NORTH:
+ offset = CHANNEL_SCAN_INDEX_NORTH_TRUE_TILT_COMP;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_MAGN_NORTH:
+ offset = CHANNEL_SCAN_INDEX_NORTH_MAGN;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_TRUE_NORTH:
+ offset = CHANNEL_SCAN_INDEX_NORTH_TRUE;
+ break;
+ default:
+ offset = -EINVAL;
+ break;
}
-};
-/* Adjust channel real bits based on report descriptor */
-static void magn_3d_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
+ return offset;
}
/* Channel read_raw handler */
@@ -109,11 +97,14 @@ static int magn_3d_read_raw(struct iio_dev *indio_dev,
{
struct magn_3d_state *magn_state = iio_priv(indio_dev);
int report_id = -1;
- u32 address;
+ unsigned
Re: [patch 1/5] futex: Make unlock_pi more robust
On Tue, 17 Jun 2014, Thomas Gleixner wrote: > On Mon, 16 Jun 2014, Darren Hart wrote: > > On Wed, 2014-06-11 at 20:45 +, Thomas Gleixner wrote: > > In wake_futex_pi we verify ownership by matching pi_state->owner == > > current, but here the only test is the TID value, which is set by > > userspace - which we don't trust... > > > > I'm trying to determine if it matters in this case... if there are no > > waiters, is the pi_state still around? If so, it does indeed matter, and > > we should be verifying. > > Erm. The whole point of this patch is to do: > > - Find existing state first and handle it. > > - If no state exists and TID == current, take it > > - Otherwise create state Duh, that was the lock path. But here the point is: - Find existing state first and handle it. - If no state exists and TID == current, release it The retry is obvious, right? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Volatile Ranges (v14 - madvise reborn edition!)
Hello everyone, On Mon, Jun 16, 2014 at 01:12:41PM -0700, John Stultz wrote: > On Tue, Jun 3, 2014 at 7:57 AM, Johannes Weiner wrote: > > That, however, truly is a separate virtual memory feature. Would it > > be possible for you to take MADV_FREE and MADV_REVIVE as a base and > > implement an madvise op that switches the no-page behavior of a VMA > > from zero-filling to SIGBUS delivery? > > I'll see if I can look into it if I get some time. However, I suspect > its more likely I'll just have to admit defeat on this one and let > someone else champion the effort. Interest and reviews have seemingly > dropped again here and with other work ramping up, I'm not sure if > I'll be able to justify further work on this. :( About adding an madvise op that switches the no-page behavior from zero-filling to SIGBUS delivery (right now only for anonymous vmas but we can evaluate to extend it) I've mostly completed the userfaultfd/madvise(MADV_USERFAULT) according to the design I described earlier. Like we discussed earlier that may fit the bill if extended to tmpfs? The first preliminary tests just passed last week. http://git.kernel.org/cgit/linux/kernel/git/andrea/aa.git/?h=userfault If userfaultfd() isn't instantiated by the process, it only sends a SIBGUS to the thread accessing the unmapped virtual address (handle_mm_faults returns VM_FAULT_SIGBUS). The address of the fault is then available in siginfo->si_addr. You strictly need a memory externalization thread opening the userfaultfd and speaking the userfaultfd protocol only if you need to access the memory also through syscalls or drivers doing GUP calls. This allows memory mapped in a secondary MMU for example to be externalized without a single change to the secondary MMU code. The userfault becomes invisible to handle_mm_fault/gup()/gup_fast/FOLL_NOWAIT etc The only requirement is that the memory externalization thread never accesses any memory in the MADV_USERFAULT marked regions (and if it does because of a bug, the deadlock should be quite apparent by simply checking the stack trace of the externalization thread blocked in handle_userfault(), sigkill will then clear it up :). If you close the userfaultfd the SIGBUS behavior will immediately return for the MADV_USERFAULT marked regions and any hung task waiting to be waken will get an immediate SIGBUS. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/9] ata: Add support for the Tegra124 SATA controller
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
> This adds support for the integrated AHCI-compliant Serial ATA
> controller present on the NVIDIA Tegra124 system-on-chip.
> diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
> +static int tegra_ahci_controller_init(struct ahci_host_priv *hpriv)
> + /* Pad calibration */
> +
> + ret = tegra_fuse_readl(0x224, );
> + if (ret) {
> + dev_err(>pdev->dev,
> + "failed to read sata calibration fuse: %d\n", ret);
> + return ret;
> + }
> +
> + calib = tegra124_pad_calibration[val];
Shouldn't val be range-checked before blindly using it?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] futex: Make unlock_pi more robust
On Mon, 16 Jun 2014, Darren Hart wrote:
> On Wed, 2014-06-11 at 20:45 +, Thomas Gleixner wrote:
> > static int futex_unlock_pi(u32 __user *uaddr, unsigned int flags)
> > @@ -2417,57 +2401,47 @@ retry:
> > return -EPERM;
> >
> > ret = get_futex_key(uaddr, flags & FLAGS_SHARED, ,
> > VERIFY_WRITE);
> > - if (unlikely(ret != 0))
> > - goto out;
> > + if (ret)
> > + return ret;
>
> Looks like you're also trying to move away from a single exit point to
> multiple exit points. I prefer the single exit (which you've probably
> noticed :-), but it's a subjective thing, and so long as we are not
> duplicating cleanup logic, I guess it's fine either way. This change was
> not mentioned in the commit message though.
I really did not think about mentioning that :)
> > +* Check waiters first. We do not trust user space values at
> > +* all and we at least want to know if user space fiddled
> > +* with the futex value instead of blindly unlocking.
> > +*/
> > + match = futex_top_waiter(hb, );
> > + if (match) {
> > + ret = wake_futex_pi(uaddr, uval, match);
> > /*
> > -* The atomic access to the futex value
> > -* generated a pagefault, so retry the
> > -* user-access and the wakeup:
> > +* The atomic access to the futex value generated a
> > +* pagefault, so retry the user-access and the wakeup:
> > */
> > if (ret == -EFAULT)
> > goto pi_faulted;
> > goto out_unlock;
> > }
> > +
> > /*
> > -* No waiters - kernel unlocks the futex:
> > +* We have no kernel internal state, i.e. no waiters in the
> > +* kernel. Waiters which are about to queue themself are stuck
>
> themselves
>
> > +* on hb->lock. So we can safely ignore them. We do neither
> > +* preserve the WAITERS bit not the OWNER_DIED one. We are the
>
> We preserve neither the WAITERS bit nor the OWNER_DIED bit.
> (the above use of "do" and "not" is incorrect and could easily be
> misinterpreted).
>
> > +* owner.
>
> In wake_futex_pi we verify ownership by matching pi_state->owner ==
> current, but here the only test is the TID value, which is set by
> userspace - which we don't trust...
>
> I'm trying to determine if it matters in this case... if there are no
> waiters, is the pi_state still around? If so, it does indeed matter, and
> we should be verifying.
Erm. The whole point of this patch is to do:
- Find existing state first and handle it.
- If no state exists and TID == current, take it
- Otherwise create state
This all happens under hb->lock. So how should something create new
state after we looked up existing state?
> > */
> > - ret = unlock_futex_pi(uaddr, uval);
> > - if (ret == -EFAULT)
> > + if (cmpxchg_futex_value_locked(, uaddr, uval, 0))
> > goto pi_faulted;
> >
>
> This refactoring seems like it would be best done as a prequel patch so
> as not to confuse cleanup with functional change. At least that is what
> you and others have beaten into me over the years ;-)
Well, yes and no. I'll hapilly discuss that without after clarifying
the issue below.
> > + /*
> > +* If uval has changed, let user space handle it.
> > +*/
> > + ret = (curval == uval) ? 0 : -EAGAIN;
> > +
> > out_unlock:
> > spin_unlock(>lock);
> > put_futex_key();
> > -
> > -out:
> > return ret;
> >
>
> By dropping this you won't return ret, but rather fall through into
> pi_faulted... which certainly isn't what you wanted.
By dropping the now unused "out" label I'm not longer returning ret?
The resulting code is:
out_unlock:
spin_unlock(>lock);
put_futex_key();
return ret;
If you can explain me how that "return ret" falls through to
pi_faulted magically, then I'm definitely agreeing with you on this:
> The need for better test coverage is very evident now :-)
-ENOTENOUGHSLEEP or -ENOTENOUGHCOFFEE or -ENOGLASSES perhaps?
I'm omitting some other politicially incorrect speculations for now.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: ced1401: userspace: use1401.c: Cleaning up potential strncpy missing null-terminate
2014-06-16 21:09 GMT+02:00 Dan Carpenter : > On Mon, Jun 16, 2014 at 10:01:14PM +0300, Dan Carpenter wrote: >> >> No one calls U14DriverName() so just delete this function. > > Oh. This is a userspace library or something? I'm not sure what to do. > > How did you compile test this? Does your platform even provide > strlcpy()? > > Anyway, don't delete it like I said, but I still don't think your patch > helps here. > > regards, > dan carpenter > Hi I saw that these functions are not used, had planned type it in the cover letter to :-( Thought of userspec, but then it should definitely ensure the NULL char? Kind regards Rickard Strandqvist -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/13] kexec: Implementation of new syscall kexec_file_load
On Mon, Jun 16, 2014 at 05:43:13PM -0400, Vivek Goyal wrote: > Actually currently I am using vzalloc() for command line buffer > allocation. > > image->cmdline_buf = vzalloc(cmdline_len); > if (!image->cmdline_buf) > goto out; > > Should I switch to using kzalloc() instead? Well, vzalloc could trigger the OOM killer, can't it, for the right size? If so, then we will have a serious problem. And this snippet above is down the syscall path. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs/cifs: fix regression in cifs_create_mf_symlink()
Although I have merged this into cifs-2.6.git for-next, in my testing
I am also seeing this fail with vers=3.0 (and probably 2.0 and 2.1) so
I would like to fix that too (and mfsymlinks may be at least as
important there)
On Mon, Jun 16, 2014 at 8:49 AM, Stefan (metze) Metzmacher
wrote:
> Hi Steve,
>
> any comments on this? How can we get this fixed upstream?
>
> Thanks!
> metze
>
> Am 10.06.2014 12:03, schrieb Björn Baumbach:
>> commit d81b8a40e2ece0a9ab57b1fe1798e291e75bf8fc
>> ("CIFS: Cleanup cifs open codepath")
>> changed disposition to FILE_OPEN.
>>
>> Signed-off-by: Björn Baumbach
>> Signed-off-by: Stefan Metzmacher
>> Reviewed-by: Stefan Metzmacher
>> Cc: # v3.14+
>> Cc: Pavel Shilovsky
>> Cc: Steve French
>> ---
>> fs/cifs/link.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/cifs/link.c b/fs/cifs/link.c
>> index 264ece7..68559fd 100644
>> --- a/fs/cifs/link.c
>> +++ b/fs/cifs/link.c
>> @@ -374,7 +374,7 @@ cifs_create_mf_symlink(unsigned int xid, struct
>> cifs_tcon *tcon,
>> oparms.cifs_sb = cifs_sb;
>> oparms.desired_access = GENERIC_WRITE;
>> oparms.create_options = create_options;
>> - oparms.disposition = FILE_OPEN;
>> + oparms.disposition = FILE_CREATE;
>> oparms.path = path;
>> oparms.fid =
>> oparms.reconnect = false;
>>
>
--
Thanks,
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: [PATCH 7/9] ahci: Increase AHCI_MAX_CLKS to 4
On 06/04/2014 05:32 AM, Mikko Perttunen wrote: > The Tegra AHCI device requires four clocks, so increase the maximum > amount of handled clocks from three to four. Tejun, The SATA driver in patch 8/9 in this series would usually be applied in your ATA tree. However, it has a lot of compile-time dependencies on things outside the ATA tree that I expect you don't want to deal with. If you're OK with patches 7 and 8, could you ack them so that I can apply them to the Tegra tree? I assume the patches won't cause any significant conflicts, but if you need, I can certainly give you a signed tag back to allow you to merge the driver patch (plus the compile-time dependencies) into your tree later if needed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6] leds: USB: HID: Add support for MSI GT683R led panels
This driver adds support for USB controlled led panels that exists in
MSI GT683R laptop
Signed-off-by: Janne Kanniainen
---
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
- removing unneeded code
Changes in v3:
- implemented as HID device
- some cleanups and bug fixes
Changes in v4:
- more cleanups
- support for selecting leds
- suppport for selecting status
Changes in v5:
- mode attribute documented under Documentation/ABI
- made array for led_classdev
- led devices uses now recommended naming scheme
Changes in v6:
- flush_work added
- using hid device name instead of hard coded gt683r
- allocating name buffers with devm_kzalloc
There was a bug with "for", so I fixed it.
.../ABI/testing/sysfs-class-hid-driver-gt683r | 14 +
drivers/hid/Kconfig| 16 ++
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-gt683r.c | 318 +
drivers/hid/hid-ids.h | 2 +-
drivers/hid/usbhid/hid-quirks.c| 2 +-
7 files changed, 352 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
create mode 100644 drivers/hid/hid-gt683r.c
diff --git a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
new file mode 100644
index 000..6d0bd80
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
@@ -0,0 +1,14 @@
+What: /sys/class/hidraw//device/mode
+Date: Jun 2014
+KernelVersion: 3.17
+Contact: Janne Kanniainen
+Description:
+ Set the mode of LEDs
+
+ 0 - normal
+ 1 - audio
+ 2 - breathing
+
+ Normal: LEDs are on
+ Audio: LEDs brightness depends on sound level
+ Breathing: LEDs brightness varies at human breathing rate
\ No newline at end of file
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 7af9d0b..b88cabd 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -261,6 +261,22 @@ config HOLTEK_FF
Say Y here if you have a Holtek On Line Grip based game controller
and want to have force feedback support for it.
+config HID_GT683R
+ tristate "MSI GT68xR LED support"
+ depends on LEDS_CLASS && USB_HID
+ ---help---
+ Say Y here if you want to enable support for the MSI GT68xR LEDS
+
+ This driver support following modes:
+ - Normal: LEDs are on
+ - Audio: LEDs brightness depends on sound level
+ - Breathing: LEDs brightness varies at human breathing rate
+
+ You can also select which leds you want to enable.
+
+ Currently the following devices are know to be supported:
+ - MSI GT683R
+
config HID_HUION
tristate "Huion tablets"
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index fc712dd..7129311 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_HID_EMS_FF) += hid-emsff.o
obj-$(CONFIG_HID_ELECOM) += hid-elecom.o
obj-$(CONFIG_HID_ELO) += hid-elo.o
obj-$(CONFIG_HID_EZKEY)+= hid-ezkey.o
+obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-mouse.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index da52279..ec88fdb 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1827,6 +1827,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_2) },
diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
new file mode 100644
index 000..1b16250
--- /dev/null
+++ b/drivers/hid/hid-gt683r.c
@@ -0,0 +1,318 @@
+/*
+ * MSI GT683R led driver
+ *
+ * Copyright (c) 2014 Janne Kanniainen
+ *
+ * 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
Re: 3.15: kernel BUG at kernel/auditsc.c:1525!
On Mon, Jun 16, 2014 at 2:58 PM, H. Peter Anvin wrote: >> >> For 64-bit, I want to do this instead: >> >> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/seccomp-fastpath=a5ec2d7af2c54b55fc7201fa662138b53fbbda39 >> >> I see no reason why the 64-bit badsys code needs its own code path at >> all. I haven't sent it yet because AFAICT it doesn't fix any bug, and >> the series it's a part of isn't ready. >> >> I'm also contemplating rewriting the 64-bit syscall entry work path in C. >> > > Cute... although it still leaves an extra branch for the badsys. It > might perform better than a cmov, but it might not. I bet that the branch is faster in most cases -- I'd be somewhat surprised if CPUs can speculate through a cmov, and that value is needed for control flow almost immediately. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] ARM: tegra: Export tegra_powergate_power_on
On 06/04/2014 05:32 AM, Mikko Perttunen wrote: > This symbol needs to be exported to power on rails without using > tegra_powergate_sequence_power_up. tegra_powergate_sequence_power_up > cannot be used in situations where the driver wants to handle clocking > by itself. Thierry, are you OK with this change? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next 24/26] usb: Use dma_zalloc_coherent
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Sunday, June 15, 2014 1:38 PM
>
> Use the zeroing function instead of dma_alloc_coherent & memset(,0,)
>
> Signed-off-by: Joe Perches
> ---
> drivers/usb/dwc2/hcd_ddma.c | 20 +++-
> drivers/usb/host/uhci-hcd.c | 7 +++
> 2 files changed, 10 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/usb/dwc2/hcd_ddma.c b/drivers/usb/dwc2/hcd_ddma.c
> index 3376177..ab8d7fc 100644
> --- a/drivers/usb/dwc2/hcd_ddma.c
> +++ b/drivers/usb/dwc2/hcd_ddma.c
> @@ -87,17 +87,12 @@ static u16 dwc2_frame_incr_val(struct dwc2_qh *qh)
> static int dwc2_desc_list_alloc(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh,
> gfp_t flags)
> {
> - qh->desc_list = dma_alloc_coherent(hsotg->dev,
> - sizeof(struct dwc2_hcd_dma_desc) *
> - dwc2_max_desc_num(qh), >desc_list_dma,
> - flags);
> -
> + qh->desc_list = dma_zalloc_coherent(hsotg->dev,
> + sizeof(struct dwc2_hcd_dma_desc) *
> dwc2_max_desc_num(qh),
> + >desc_list_dma, flags);
This will cause checkpatch to complain about a too-long line, surely?
If you fix that, you can add my acked-by for the dwc2 parts.
--
Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/2] Add test to validate udelay
This change adds a module and a script that makes use of it to validate that udelay delays for at least as long as requested (as compared to ktime). Changes since v1: - allow udelay() to be 0.5% faster than requested as per feedback Changes since v2: - fix permissions on udelay_test.sh script - update commit message to indicate what this test targets - fixed checkpatch whitespace error - rebased Changes since v3: - fixed xtensa compile warning (and other 32-bit platforms which use the generic do_div) - renamed and moved config option David Riley (2): kernel: time: Add udelay_test module to validate udelay tools: add script to test udelay kernel/time/Makefile | 1 + kernel/time/udelay_test.c | 168 ++ lib/Kconfig.debug | 9 +++ tools/time/udelay_test.sh | 66 ++ 4 files changed, 244 insertions(+) create mode 100644 kernel/time/udelay_test.c create mode 100755 tools/time/udelay_test.sh -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.15: kernel BUG at kernel/auditsc.c:1525!
> > For 64-bit, I want to do this instead: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/seccomp-fastpath=a5ec2d7af2c54b55fc7201fa662138b53fbbda39 > > I see no reason why the 64-bit badsys code needs its own code path at > all. I haven't sent it yet because AFAICT it doesn't fix any bug, and > the series it's a part of isn't ready. > > I'm also contemplating rewriting the 64-bit syscall entry work path in C. > Cute... although it still leaves an extra branch for the badsys. It might perform better than a cmov, but it might not. -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/
[PATCH v4 2/2] tools: add script to test udelay
This script makes use of the udelay_test module to exercise udelay()
and ensure that it is delaying long enough (as compared to ktime).
Signed-off-by: David Riley
---
tools/time/udelay_test.sh | 66 +++
1 file changed, 66 insertions(+)
create mode 100755 tools/time/udelay_test.sh
diff --git a/tools/time/udelay_test.sh b/tools/time/udelay_test.sh
new file mode 100755
index 000..12d46b9
--- /dev/null
+++ b/tools/time/udelay_test.sh
@@ -0,0 +1,66 @@
+#!/bin/bash
+
+# udelay() test script
+#
+# Test is executed by writing and reading to /sys/kernel/debug/udelay_test
+# and exercises a variety of delays to ensure that udelay() is delaying
+# at least as long as requested (as compared to ktime).
+#
+# Copyright (C) 2014 Google, Inc.
+#
+# This software is licensed under the terms of the GNU General Public
+# License version 2, as published by the Free Software Foundation, and
+# may be copied, distributed, and modified under those terms.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+MODULE_NAME=udelay_test
+UDELAY_PATH=/sys/kernel/debug/udelay_test
+
+setup()
+{
+ /sbin/modprobe -q $MODULE_NAME
+ tmp_file=`mktemp`
+}
+
+test_one()
+{
+ delay=$1
+ echo $delay > $UDELAY_PATH
+ tee -a $tmp_file < $UDELAY_PATH
+}
+
+cleanup()
+{
+ if [ -f $tmp_file ]; then
+ rm $tmp_file
+ fi
+ /sbin/modprobe -q -r $MODULE_NAME
+}
+
+trap cleanup EXIT
+setup
+
+# Delay for a variety of times.
+# 1..200, 200..500 (by 10), 500..2000 (by 100)
+for (( delay = 1; delay < 200; delay += 1 )); do
+ test_one $delay
+done
+for (( delay = 200; delay < 500; delay += 10 )); do
+ test_one $delay
+done
+for (( delay = 500; delay <= 2000; delay += 100 )); do
+ test_one $delay
+done
+
+# Search for failures
+count=`grep -c FAIL $tmp_file`
+if [ $? -eq "0" ]; then
+ echo "ERROR: $count delays failed to delay long enough"
+ retcode=1
+fi
+
+exit $retcode
--
2.0.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 v4 1/2] kernel: time: Add udelay_test module to validate udelay
Create a module that allows udelay() to be executed to ensure that
it is delaying at least as long as requested (with a little bit of
error allowed).
There are some configurations which don't have reliably udelay
due to using a loop delay with cpufreq changes which should use
a counter time based delay instead. This test aims to identify
those configurations where timing is unreliable.
Signed-off-by: David Riley
---
kernel/time/Makefile | 1 +
kernel/time/udelay_test.c | 168 ++
lib/Kconfig.debug | 9 +++
3 files changed, 178 insertions(+)
create mode 100644 kernel/time/udelay_test.c
diff --git a/kernel/time/Makefile b/kernel/time/Makefile
index 57a413f..5b2dc10 100644
--- a/kernel/time/Makefile
+++ b/kernel/time/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_TICK_ONESHOT)+=
tick-oneshot.o
obj-$(CONFIG_TICK_ONESHOT) += tick-sched.o
obj-$(CONFIG_TIMER_STATS) += timer_stats.o
obj-$(CONFIG_DEBUG_FS) += timekeeping_debug.o
+obj-$(CONFIG_TEST_UDELAY) += udelay_test.o
diff --git a/kernel/time/udelay_test.c b/kernel/time/udelay_test.c
new file mode 100644
index 000..e622ba3
--- /dev/null
+++ b/kernel/time/udelay_test.c
@@ -0,0 +1,168 @@
+/*
+ * udelay() test kernel module
+ *
+ * Test is executed by writing and reading to /sys/kernel/debug/udelay_test
+ * Tests are configured by writing: USECS ITERATIONS
+ * Tests are executed by reading from the same file.
+ * Specifying usecs of 0 or negative values will run multiples tests.
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define DEFAULT_ITERATIONS 100
+
+#define DEBUGFS_FILENAME "udelay_test"
+
+static DEFINE_MUTEX(udelay_test_lock);
+static struct dentry *udelay_test_debugfs_file;
+static int udelay_test_usecs;
+static int udelay_test_iterations = DEFAULT_ITERATIONS;
+
+static int udelay_test_single(struct seq_file *s, int usecs, uint32_t iters)
+{
+ int min = 0, max = 0, fail_count = 0;
+ uint64_t sum = 0;
+ uint64_t avg;
+ int i;
+ /* Allow udelay to be up to 0.5% fast */
+ int allowed_error_ns = usecs * 5;
+
+ for (i = 0; i < iters; ++i) {
+ struct timespec ts1, ts2;
+ int time_passed;
+
+ ktime_get_ts();
+ udelay(usecs);
+ ktime_get_ts();
+ time_passed = timespec_to_ns() - timespec_to_ns();
+
+ if (i == 0 || time_passed < min)
+ min = time_passed;
+ if (i == 0 || time_passed > max)
+ max = time_passed;
+ if ((time_passed + allowed_error_ns) / 1000 < usecs)
+ ++fail_count;
+ WARN_ON(time_passed < 0);
+ sum += time_passed;
+ }
+
+ avg = sum;
+ do_div(avg, iters);
+ seq_printf(s, "%d usecs x %d: exp=%d allowed=%d min=%d avg=%lld max=%d",
+ usecs, iters, usecs * 1000,
+ (usecs * 1000) - allowed_error_ns, min, avg, max);
+ if (fail_count)
+ seq_printf(s, " FAIL=%d", fail_count);
+ seq_puts(s, "\n");
+
+ return 0;
+}
+
+static int udelay_test_show(struct seq_file *s, void *v)
+{
+ int usecs;
+ int iters;
+ int ret = 0;
+
+ mutex_lock(_test_lock);
+ usecs = udelay_test_usecs;
+ iters = udelay_test_iterations;
+ mutex_unlock(_test_lock);
+
+ if (usecs > 0 && iters > 0) {
+ return udelay_test_single(s, usecs, iters);
+ } else if (usecs == 0) {
+ struct timespec ts;
+
+ ktime_get_ts();
+ seq_printf(s, "udelay() test (lpj=%ld kt=%ld.%09ld)\n",
+ loops_per_jiffy, ts.tv_sec, ts.tv_nsec);
+ seq_puts(s, "usage:\n");
+ seq_puts(s, "echo USECS [ITERS] > " DEBUGFS_FILENAME "\n");
+ seq_puts(s, "cat " DEBUGFS_FILENAME "\n");
+ }
+
+ return ret;
+}
+
+static int udelay_test_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, udelay_test_show, inode->i_private);
+}
+
+static ssize_t udelay_test_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *pos)
+{
+ char lbuf[32];
+ int ret;
+ int usecs;
+ int iters;
+
+ if (count >= sizeof(lbuf))
+
Re: [PATCH 3/9] ARM: tegra: Add SATA and SATA power to Jetson TK1 device tree
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
> This enables the integrated SATA controller on the Tegra124 system-on-chip
> on the Jetson TK1 board and adds regulators for the onboard Molex connector
> commonly used to power SATA devices. The regulators are marked always-on
> since they can be used for other purposes than powering SATA devices.
> diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
> b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
> + sata@0,7002 {
> + target-supply = <_5v0_sata>;
regulators {
> + /* Molex power connector */
> + vdd_5v0_sata: regulator@13 {
> + compatible = "regulator-fixed";
> + reg = <13>;
> + regulator-name = "+5V_SATA";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = < TEGRA_GPIO(EE, 2) GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + vin-supply = <_5v0_sys>;
> + regulator-always-on;
> + };
Why is this always-on, considering that the SATA node references this,
and presumably the driver explicitly enables this regulator?
> +
> + vdd_12v0_sata: regulator@14 {
> + compatible = "regulator-fixed";
> + reg = <14>;
> + regulator-name = "+12V_SATA";
> + regulator-min-microvolt = <1200>;
> + regulator-max-microvolt = <1200>;
> + gpio = < TEGRA_GPIO(EE, 2) GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + vin-supply = <_mux>;
> + regulator-always-on;
> + };
> };
If there are two regulators required for the SATA devices, shouldn't the
SATA node's target-supply property reference them both? Well, I suppose
there'd need to be target-5v-supply and target-12v-supply properties,
since each regulator property can only reference a single supply, IIRC.
I think the DT binding needs to be updated for this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/11] qspinlock: Revert to test-and-set on hypervisors
On 06/15/2014 08:47 AM, Peter Zijlstra wrote:
When we detect a hypervisor (!paravirt, see later patches), revert to
a simple test-and-set lock to avoid the horrors of queue preemption.
Signed-off-by: Peter Zijlstra
---
arch/x86/include/asm/qspinlock.h | 14 ++
include/asm-generic/qspinlock.h |7 +++
kernel/locking/qspinlock.c |3 +++
3 files changed, 24 insertions(+)
--- a/arch/x86/include/asm/qspinlock.h
+++ b/arch/x86/include/asm/qspinlock.h
@@ -1,6 +1,7 @@
#ifndef _ASM_X86_QSPINLOCK_H
#define _ASM_X86_QSPINLOCK_H
+#include
#include
#if !defined(CONFIG_X86_OOSTORE)&& !defined(CONFIG_X86_PPRO_FENCE)
@@ -20,6 +21,19 @@ static inline void queue_spin_unlock(str
#endif /* !CONFIG_X86_OOSTORE&& !CONFIG_X86_PPRO_FENCE */
+#define virt_queue_spin_lock virt_queue_spin_lock
+
+static inline bool virt_queue_spin_lock(struct qspinlock *lock)
+{
+ if (!static_cpu_has(X86_FEATURE_HYPERVISOR))
+ return false;
+
+ while (atomic_cmpxchg(>val, 0, _Q_LOCKED_VAL) != 0)
+ cpu_relax();
+
+ return true;
+}
+
#include
#endif /* _ASM_X86_QSPINLOCK_H */
--- a/include/asm-generic/qspinlock.h
+++ b/include/asm-generic/qspinlock.h
@@ -98,6 +98,13 @@ static __always_inline void queue_spin_u
}
#endif
+#ifndef virt_queue_spin_lock
+static __always_inline bool virt_queue_spin_lock(struct qspinlock *lock)
+{
+ return false;
+}
+#endif
+
/*
* Initializier
*/
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -247,6 +247,9 @@ void queue_spin_lock_slowpath(struct qsp
BUILD_BUG_ON(CONFIG_NR_CPUS>= (1U<< _Q_TAIL_CPU_BITS));
+ if (virt_queue_spin_lock(lock))
+ return;
+
/*
* wait for in-progress pending->locked hand-overs
*
I just wonder if it is better to allow the kernel distributors to decide
if unfair lock should be the default for virtual guest. Anyway, I have
no objection to that myself.
-Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: kernel BUG at kernel/auditsc.c:1525!
On Mon, Jun 16, 2014 at 2:48 PM, H. Peter Anvin wrote: > On 06/16/2014 02:35 PM, Andy Lutomirski wrote: >> >> To hpa, etc: It appears that entry_32.S is missing any call to the >> audit exit hook on the badsys path. If I'm diagnosing this bug report >> correctly, this causes OOPSes. >> >> The the world at large: it's increasingly apparent that no one (except >> maybe the blackhats) has ever scrutinized the syscall auditing code. >> This is two old severe bugs in the code that have probably been there >> for a long time. >> > > Yes, the audit code is a total mess. > >> The bad syscall nr paths are their own incomprehensible route >> through the entry control flow. Rearrange them to work just like >> syscalls that return -ENOSYS. > > I have to admit... it sort of lends itself to a solution like this: > > /* For the 64-bit case, analogous code for 32 bits */ > movl $__NR_syscall_max+1,%ecx # *Not* __NR_syscall_max > cmpq %rcx,%rax > cmovae %rcx,%rax > movq %r10,%rcx > call *sys_call_table(,%rax,8) > > ... and having an extra (invalid) system call slot in the syscall table > beyond the end instead of branching off separately. > > (Note: we could use either cmova or cmovae, and either the 32- or 64-bit > form... the reason why is left as an exercise to the reader.) For 64-bit, I want to do this instead: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/seccomp-fastpath=a5ec2d7af2c54b55fc7201fa662138b53fbbda39 I see no reason why the 64-bit badsys code needs its own code path at all. I haven't sent it yet because AFAICT it doesn't fix any bug, and the series it's a part of isn't ready. I'm also contemplating rewriting the 64-bit syscall entry work path in C. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] of: Add NVIDIA Tegra SATA controller binding
On 06/04/2014 05:32 AM, Mikko Perttunen wrote: > This patch adds device tree binding documentation for the SATA > controller found on NVIDIA Tegra SoCs. Just one nit below: > diff --git a/Documentation/devicetree/bindings/ata/tegra-sata.txt > b/Documentation/devicetree/bindings/ata/tegra-sata.txt > + - clocks : Defines the clocks listed in the clock-names property. > + - clock-names : The following clock names must be present: > + - sata ... It would be nice if the binding could use the exact same wording as all the other Tegra bindings, i.e.: == - clocks : Must contain an entry for each entry in clock-names. See ../clocks/clock-bindings.txt for details. - clock-names : Must include the following entries: - pll_a - pll_a_out0 - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) == Same for the resets property. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: kernel BUG at kernel/auditsc.c:1525!
On 06/16/2014 02:35 PM, Andy Lutomirski wrote: > > To hpa, etc: It appears that entry_32.S is missing any call to the > audit exit hook on the badsys path. If I'm diagnosing this bug report > correctly, this causes OOPSes. > > The the world at large: it's increasingly apparent that no one (except > maybe the blackhats) has ever scrutinized the syscall auditing code. > This is two old severe bugs in the code that have probably been there > for a long time. > Yes, the audit code is a total mess. > The bad syscall nr paths are their own incomprehensible route > through the entry control flow. Rearrange them to work just like > syscalls that return -ENOSYS. I have to admit... it sort of lends itself to a solution like this: /* For the 64-bit case, analogous code for 32 bits */ movl $__NR_syscall_max+1,%ecx # *Not* __NR_syscall_max cmpq %rcx,%rax cmovae %rcx,%rax movq %r10,%rcx call *sys_call_table(,%rax,8) ... and having an extra (invalid) system call slot in the syscall table beyond the end instead of branching off separately. (Note: we could use either cmova or cmovae, and either the 32- or 64-bit form... the reason why is left as an exercise to the reader.) -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 4/9] clk: tegra: Enable hardware control of SATA PLL
On 06/04/2014 05:32 AM, Mikko Perttunen wrote: > This makes the SATA PLL be controlled by hardware instead of software. > This is required for working SATA support. Peter, could you please take patches 4 and 5 through the clock tree. As far as I can tell, there's no compile-time dependency in the clock patches, so they can go through a different tree to the rest of the series without issue. These 2 patches look fine to me, so consider them: Acked-by: Stephen Warren -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/10] mfd: cros_ec: Use struct cros_ec_command to communicate with the EC
From: Bill Richardson
This is some internal structure reorganization / renaming to prepare
for future patches that will add a userspace API to cros_ec. There
should be no visible changes.
Signed-off-by: Bill Richardson
Signed-off-by: Doug Anderson
---
drivers/mfd/cros_ec.c | 28 ++--
drivers/mfd/cros_ec_i2c.c | 24
drivers/mfd/cros_ec_spi.c | 16
include/linux/mfd/cros_ec.h | 35 ++-
4 files changed, 52 insertions(+), 51 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index a9eede5..9304056 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -25,22 +25,22 @@
#include
int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
- struct cros_ec_msg *msg)
+ struct cros_ec_command *msg)
{
uint8_t *out;
int csum, i;
- BUG_ON(msg->out_len > EC_PROTO2_MAX_PARAM_SIZE);
+ BUG_ON(msg->outsize > EC_PROTO2_MAX_PARAM_SIZE);
out = ec_dev->dout;
out[0] = EC_CMD_VERSION0 + msg->version;
- out[1] = msg->cmd;
- out[2] = msg->out_len;
+ out[1] = msg->command;
+ out[2] = msg->outsize;
csum = out[0] + out[1] + out[2];
- for (i = 0; i < msg->out_len; i++)
- csum += out[EC_MSG_TX_HEADER_BYTES + i] = msg->out_buf[i];
- out[EC_MSG_TX_HEADER_BYTES + msg->out_len] = (uint8_t)(csum & 0xff);
+ for (i = 0; i < msg->outsize; i++)
+ csum += out[EC_MSG_TX_HEADER_BYTES + i] = msg->outdata[i];
+ out[EC_MSG_TX_HEADER_BYTES + msg->outsize] = (uint8_t)(csum & 0xff);
- return EC_MSG_TX_PROTO_BYTES + msg->out_len;
+ return EC_MSG_TX_PROTO_BYTES + msg->outsize;
}
EXPORT_SYMBOL(cros_ec_prepare_tx);
@@ -48,14 +48,14 @@ static int cros_ec_command_sendrecv(struct cros_ec_device
*ec_dev,
uint16_t cmd, void *out_buf, int out_len,
void *in_buf, int in_len)
{
- struct cros_ec_msg msg;
+ struct cros_ec_command msg;
msg.version = cmd >> 8;
- msg.cmd = cmd & 0xff;
- msg.out_buf = out_buf;
- msg.out_len = out_len;
- msg.in_buf = in_buf;
- msg.in_len = in_len;
+ msg.command = cmd & 0xff;
+ msg.outdata = out_buf;
+ msg.outsize = out_len;
+ msg.indata = in_buf;
+ msg.insize = in_len;
return ec_dev->cmd_xfer(ec_dev, );
}
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 777e529..37ed12f 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -30,7 +30,7 @@ static inline struct cros_ec_device *to_ec_dev(struct device
*dev)
}
static int cros_ec_cmd_xfer_i2c(struct cros_ec_device *ec_dev,
- struct cros_ec_msg *msg)
+ struct cros_ec_command *msg)
{
struct i2c_client *client = ec_dev->priv;
int ret = -ENOMEM;
@@ -50,7 +50,7 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device *ec_dev,
* allocate larger packet (one byte for checksum, one byte for
* length, and one for result code)
*/
- packet_len = msg->in_len + 3;
+ packet_len = msg->insize + 3;
in_buf = kzalloc(packet_len, GFP_KERNEL);
if (!in_buf)
goto done;
@@ -61,7 +61,7 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device *ec_dev,
* allocate larger packet (one byte for checksum, one for
* command code, one for length, and one for command version)
*/
- packet_len = msg->out_len + 4;
+ packet_len = msg->outsize + 4;
out_buf = kzalloc(packet_len, GFP_KERNEL);
if (!out_buf)
goto done;
@@ -69,16 +69,16 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device
*ec_dev,
i2c_msg[0].buf = (char *)out_buf;
out_buf[0] = EC_CMD_VERSION0 + msg->version;
- out_buf[1] = msg->cmd;
- out_buf[2] = msg->out_len;
+ out_buf[1] = msg->command;
+ out_buf[2] = msg->outsize;
/* copy message payload and compute checksum */
sum = out_buf[0] + out_buf[1] + out_buf[2];
- for (i = 0; i < msg->out_len; i++) {
- out_buf[3 + i] = msg->out_buf[i];
+ for (i = 0; i < msg->outsize; i++) {
+ out_buf[3 + i] = msg->outdata[i];
sum += out_buf[3 + i];
}
- out_buf[3 + msg->out_len] = sum;
+ out_buf[3 + msg->outsize] = sum;
/* send command to EC and read answer */
ret = i2c_transfer(client->adapter, i2c_msg, 2);
@@ -94,20 +94,20 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device
*ec_dev,
/* check response error code */
if (i2c_msg[1].buf[0]) {
dev_warn(ec_dev->dev, "command 0x%02x returned an error %d\n",
-msg->cmd, i2c_msg[1].buf[0]);
+msg->command, i2c_msg[1].buf[0]);
[PATCH 05/10] mdf: cros_ec: Detect in-progress commands
From: Simon Glass
Some commands take a while to execute. Use -EAGAIN to signal this to the
caller.
Signed-off-by: Simon Glass
Signed-off-by: Doug Anderson
---
drivers/mfd/cros_ec_spi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 52d4d7b..c29a2d7 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -292,6 +292,12 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device
*ec_dev,
/* check response error code */
ptr = ec_dev->din;
if (ptr[0]) {
+ if (ptr[0] == EC_RES_IN_PROGRESS) {
+ dev_dbg(ec_dev->dev, "command 0x%02x in progress\n",
+ ec_msg->cmd);
+ ret = -EAGAIN;
+ goto exit;
+ }
dev_warn(ec_dev->dev, "command 0x%02x returned an error %d\n",
ec_msg->cmd, ptr[0]);
debug_packet(ec_dev->dev, "in_err", ptr, len);
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/13] kexec-bzImage: Support for loading bzImage using 64bit entry
On Mon, Jun 16, 2014 at 11:27:20PM +0200, Borislav Petkov wrote: > On Mon, Jun 16, 2014 at 05:15:00PM -0400, Vivek Goyal wrote: > > Do we want to show all the rejection messages from bzImage64 and > > bzImage32 loaders. It might be too verbose to show users that before > > vmlinux loader accepted the image other loaders on this arches rejcted > > the image. > > I get all that. But, if people want to get feedback from the system > about *why* their image didn't load, they absolutely have to enable > dynamic debug. And this is not optimal IMO because they will have to > look at the code first to see what they need to do. > > Or is kexec-tools going to be taught to interpret return values from the > syscall? In most of the cases return code is -ENOEXEC so kexec-tools can't figure out what's wrong. > > In any case, we want information about why an image fails loading to > reach the user in the easiest way possible. And why should the user need > to enable dynamic debug if he can get the info without doing so? > > Oh, and not everyone knows about dynamic debug so... > > And I don't think it'll be too much info - only the line which fails > the check will be printed before the image loader fails so that's > practically one error reason per failed image. > Ok, there will be one line of error and that's not too bad. I will convert these pr_debug() statements in bzImage_probe() to pr_err(). Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
