On 01/10/2014 02:42 AM, Will Deacon wrote:
> On Thu, Jan 09, 2014 at 12:47:24PM +, Stefano Stabellini wrote:
>> On Thu, 9 Jan 2014, Arnd Bergmann wrote:
>>> On Thursday 09 January 2014, Will Deacon wrote:
On Wed, Jan 08, 2014 at 06:00:23PM +, Stefano Stabellini wrote:
> Remove
On 01/10/2014 02:42 AM, Will Deacon wrote:
On Thu, Jan 09, 2014 at 12:47:24PM +, Stefano Stabellini wrote:
On Thu, 9 Jan 2014, Arnd Bergmann wrote:
On Thursday 09 January 2014, Will Deacon wrote:
On Wed, Jan 08, 2014 at 06:00:23PM +, Stefano Stabellini wrote:
Remove !GENERIC_ATOMIC64
On 11/17/2013 07:35 PM, Chen Gang wrote:
> For all uapi headers, need use "_UAPI" prefix for its guard macro
> (which will be stripped by "scripts/headers_installer.sh").
>
> Also be sure that all standard header files have their guard macros.
>
I removed all files which only includes related
On 11/17/2013 07:35 PM, Chen Gang wrote:
For all uapi headers, need use _UAPI prefix for its guard macro
(which will be stripped by scripts/headers_installer.sh).
Also be sure that all standard header files have their guard macros.
I removed all files which only includes related
On 11/02/2013 02:32 AM, Joe Perches wrote:
> On Fri, 2013-11-01 at 19:20 +0800, Chen Gang wrote:
>> > Hello Joe:
> Hello Chen Gang.
>
>> > I meet a failure about "scripts/get_maintainers.pl", it is about the
>> > commit "750432d get_maintainer.pl incomplete output", if use original
>> >
On 11/02/2013 02:32 AM, Joe Perches wrote:
On Fri, 2013-11-01 at 19:20 +0800, Chen Gang wrote:
Hello Joe:
Hello Chen Gang.
I meet a failure about scripts/get_maintainers.pl, it is about the
commit 750432d get_maintainer.pl incomplete output, if use original
scripts/get_maintainer.pl,
On 10/26/2013 10:42 AM, Chen Gang wrote:
> On 10/24/2013 11:29 PM, Josh Boyer wrote:
>> On Wed, Oct 23, 2013 at 10:31 PM, Chen Gang wrote:
>>> For some architectures, tool chain is not smart enough to recognize the
>>> macro with multiple lines (e.g. arc tool chain), and for common ".S"
>>> file,
On 10/26/2013 10:42 AM, Chen Gang wrote:
On 10/24/2013 11:29 PM, Josh Boyer wrote:
On Wed, Oct 23, 2013 at 10:31 PM, Chen Gang gang.c...@asianux.com wrote:
For some architectures, tool chain is not smart enough to recognize the
macro with multiple lines (e.g. arc tool chain), and for common .S
On 10/03/2013 10:51 PM, Toshi Kani wrote:
> On Thu, 2013-10-03 at 00:49 +, Chen Gang wrote:
>> On 10/03/2013 03:33 AM, Toshi Kani wrote:
>>> On Thu, 2013-10-03 at 00:41 +0800, Chen Gang F T wrote:
>>>> On 10/02/2013 11:28 PM, Toshi Kani wrote:
>>>>>
On 10/03/2013 10:51 PM, Toshi Kani wrote:
On Thu, 2013-10-03 at 00:49 +, Chen Gang wrote:
On 10/03/2013 03:33 AM, Toshi Kani wrote:
On Thu, 2013-10-03 at 00:41 +0800, Chen Gang F T wrote:
On 10/02/2013 11:28 PM, Toshi Kani wrote:
On Wed, 2013-10-02 at 03:10 +, Chen Gang wrote:
Hello
On 10/02/2013 11:28 PM, Toshi Kani wrote:
> On Wed, 2013-10-02 at 03:10 +, Chen Gang wrote:
>> Hello Maintainers:
>>
>> Under my x86_64 dual core laptop, I build kernel next-20130927 with
>> 'allmodconfig', and install it, the machine can not start. Related
>> information is:
>>
>> after
On 10/02/2013 11:28 PM, Toshi Kani wrote:
On Wed, 2013-10-02 at 03:10 +, Chen Gang wrote:
Hello Maintainers:
Under my x86_64 dual core laptop, I build kernel next-20130927 with
'allmodconfig', and install it, the machine can not start. Related
information is:
after call
On 09/04/2013 03:36 AM, Paul E. McKenney wrote:
> On Mon, Aug 26, 2013 at 10:21:18AM +0800, Chen Gang F T wrote:
>>
>> Firstly, thank you for your reply with these details.
>>
>> On 08/26/2013 03:18 AM, Paul E. McKenney wrote:
>>> On Thu, Aug 22, 2013
Thank you for your valuable information: it will let kernel waste mails
less, and also can save my time resources.
On 09/04/2013 04:59 AM, Guenter Roeck wrote:
> On Tue, Sep 03, 2013 at 08:39:38PM +0100, Al Viro wrote:
>> On Tue, Sep 03, 2013 at 11:52:17AM +0800, Chen Gang
Thank you for your valuable information: it will let kernel waste mails
less, and also can save my time resources.
On 09/04/2013 04:59 AM, Guenter Roeck wrote:
On Tue, Sep 03, 2013 at 08:39:38PM +0100, Al Viro wrote:
On Tue, Sep 03, 2013 at 11:52:17AM +0800, Chen Gang F T wrote:
extreme
On 09/04/2013 03:36 AM, Paul E. McKenney wrote:
On Mon, Aug 26, 2013 at 10:21:18AM +0800, Chen Gang F T wrote:
Firstly, thank you for your reply with these details.
On 08/26/2013 03:18 AM, Paul E. McKenney wrote:
On Thu, Aug 22, 2013 at 11:01:53AM +0800, Chen Gang wrote:
On 08/21/2013 10
On 09/03/2013 11:26 AM, Guenter Roeck wrote:
> On 09/02/2013 07:53 PM, Chen Gang F T wrote:
>> Hello Guenter Roeck:
>>
>>
>> I don't care about whether I am in cc mailing list, but at least,
>> please help confirm 2 things:
>>
>>Is what I ha
Hello Guenter Roeck:
I don't care about whether I am in cc mailing list, but at least,
please help confirm 2 things:
Is what I had done for h8300 just making wastes and noisy in kernel and
related sub-system mailing list ?
and is the disccusion about h8300 between us also wastes and noisy
Hello Guenter Roeck:
I don't care about whether I am in cc mailing list, but at least,
please help confirm 2 things:
Is what I had done for h8300 just making wastes and noisy in kernel and
related sub-system mailing list ?
and is the disccusion about h8300 between us also wastes and noisy
On 09/03/2013 11:26 AM, Guenter Roeck wrote:
On 09/02/2013 07:53 PM, Chen Gang F T wrote:
Hello Guenter Roeck:
I don't care about whether I am in cc mailing list, but at least,
please help confirm 2 things:
Is what I had done for h8300 just making wastes and noisy in kernel
Firstly, thank you for your reply with these details.
On 08/26/2013 03:18 AM, Paul E. McKenney wrote:
> On Thu, Aug 22, 2013 at 11:01:53AM +0800, Chen Gang wrote:
>> On 08/21/2013 10:23 PM, Paul E. McKenney wrote:
>>> On Wed, Aug 21, 2013 at 01:59:29PM +0800, Chen Gang wrote:
>
> [ . . . ]
>
Firstly, thank you for your reply with these details.
On 08/26/2013 03:18 AM, Paul E. McKenney wrote:
On Thu, Aug 22, 2013 at 11:01:53AM +0800, Chen Gang wrote:
On 08/21/2013 10:23 PM, Paul E. McKenney wrote:
On Wed, Aug 21, 2013 at 01:59:29PM +0800, Chen Gang wrote:
[ . . . ]
Don't
On 08/20/2013 04:09 PM, Chen Gang wrote:
> On 08/20/2013 03:51 PM, Chen Gang wrote:
>> On 08/20/2013 03:48 PM, Chen Gang wrote:
>>> On 08/20/2013 02:47 PM, Cyrill Gorcunov wrote:
On Tue, Aug 20, 2013 at 01:41:40PM +0800, Chen Gang wrote:
>
>> sure you'll have to change shmem_show_mpol
On 08/20/2013 04:09 PM, Chen Gang wrote:
On 08/20/2013 03:51 PM, Chen Gang wrote:
On 08/20/2013 03:48 PM, Chen Gang wrote:
On 08/20/2013 02:47 PM, Cyrill Gorcunov wrote:
On Tue, Aug 20, 2013 at 01:41:40PM +0800, Chen Gang wrote:
sure you'll have to change shmem_show_mpol statement to return
On 08/07/2013 06:13 AM, Eric W. Biederman wrote:
> Andrew Morton writes:
>
>> On Tue, 06 Aug 2013 15:29:42 +0800 Chen Gang wrote:
>>
>>> Improve the usage of return value 'result', so not only can make code
>>> clearer to readers, but also can improve the performance.
>>
>> It used to be
On 08/07/2013 06:13 AM, Eric W. Biederman wrote:
Andrew Morton a...@linux-foundation.org writes:
On Tue, 06 Aug 2013 15:29:42 +0800 Chen Gang gang.c...@asianux.com wrote:
Improve the usage of return value 'result', so not only can make code
clearer to readers, but also can improve the
On 08/05/2013 09:37 AM, Greg Ungerer wrote:
> Hi Chen Gang,
>
> On 01/07/13 12:43, Chen Gang wrote:
>> Hello Maintainers:
>>
>> Please help check the patch whether OK or not, when you have time.
>>
>> Thanks.
>>
>> On 06/22/2013 02:49 PM, Chen Gang wrote:
>>>
>>> Define 'VM_DATA_DEFAULT_FLAGS'
On 08/05/2013 09:37 AM, Greg Ungerer wrote:
Hi Chen Gang,
On 01/07/13 12:43, Chen Gang wrote:
Hello Maintainers:
Please help check the patch whether OK or not, when you have time.
Thanks.
On 06/22/2013 02:49 PM, Chen Gang wrote:
Define 'VM_DATA_DEFAULT_FLAGS' when 'NOMMU' to pass
On 07/31/2013 09:53 AM, Chen Gang wrote:
> On 07/31/2013 09:44 AM, Chen Gang wrote:
>> On 07/30/2013 08:29 PM, Joe Perches wrote:
>>> On Tue, 2013-07-30 at 15:30 +0800, Chen Gang wrote:
'#else' is useless, need remove.
Signed-off-by: Chen Gang
---
include/linux/coda.h |
On 07/31/2013 09:53 AM, Chen Gang wrote:
On 07/31/2013 09:44 AM, Chen Gang wrote:
On 07/30/2013 08:29 PM, Joe Perches wrote:
On Tue, 2013-07-30 at 15:30 +0800, Chen Gang wrote:
'#else' is useless, need remove.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
include/linux/coda.h |1
On 07/10/2013 10:35 AM, Chen Gang wrote:
> On 07/10/2013 10:17 AM, Chen Gang F T wrote:
>> On 07/09/2013 04:07 PM, Rusty Russell wrote:
>>> Chen Gang writes:
>>>> When sysfs_create_file() fails, recommend to print the related failure
>>>> information. And
On 07/09/2013 04:07 PM, Rusty Russell wrote:
> Chen Gang writes:
>> When sysfs_create_file() fails, recommend to print the related failure
>> information. And it is useless to still 'KOBJ_ADD' to user space.
>>
>> Signed-off-by: Chen Gang
>
> sysfs_create_file() should not fail during boot,
On 07/09/2013 04:07 PM, Rusty Russell wrote:
Chen Gang gang.c...@asianux.com writes:
When sysfs_create_file() fails, recommend to print the related failure
information. And it is useless to still 'KOBJ_ADD' to user space.
Signed-off-by: Chen Gang gang.c...@asianux.com
sysfs_create_file()
On 07/10/2013 10:35 AM, Chen Gang wrote:
On 07/10/2013 10:17 AM, Chen Gang F T wrote:
On 07/09/2013 04:07 PM, Rusty Russell wrote:
Chen Gang gang.c...@asianux.com writes:
When sysfs_create_file() fails, recommend to print the related failure
information. And it is useless to still 'KOBJ_ADD
On 07/08/2013 10:26 PM, Paul Gortmaker wrote:
> [[PATCH] kernel/smp.c: free related resources when failure occurs in
> hotplug_cfd()] On 08/07/2013 (Mon 16:50) Chen Gang wrote:
>
>> > When failure occurs in hotplug_cfd(), need release related resources,
>> > or will cause memory leak.
>> >
>>
On 07/08/2013 10:26 PM, Paul Gortmaker wrote:
[[PATCH] kernel/smp.c: free related resources when failure occurs in
hotplug_cfd()] On 08/07/2013 (Mon 16:50) Chen Gang wrote:
When failure occurs in hotplug_cfd(), need release related resources,
or will cause memory leak.
Also
Firstly, thank you very much for your reply.
On 07/05/2013 07:13 PM, Arnd Bergmann wrote:
> On Friday 05 July 2013, Chen Gang F T wrote:
>> > Hello All:
>> >
>> > It seems 'asm-generic' dislikes 'mad users' (e.g allmodconfig,
>> > randconfig, and me).
>
Firstly, thank you very much for your reply.
On 07/05/2013 07:13 PM, Arnd Bergmann wrote:
On Friday 05 July 2013, Chen Gang F T wrote:
Hello All:
It seems 'asm-generic' dislikes 'mad users' (e.g allmodconfig,
randconfig, and me).
I guess the main reason is: 'asm-generic' thinks
me (a mad
user).
At last, I make an apologize to 'asm-generic' for my mad discussing.
Bye !!
On 07/05/2013 08:48 AM, Chen Gang F T wrote:
> On 07/05/2013 08:14 AM, Stephen Rothwell wrote:
>> On Fri, 05 Jul 2013 08:03:31 +0800 Chen Gang F T
>> wrote:
>>>>
>>>
me (a mad
user).
At last, I make an apologize to 'asm-generic' for my mad discussing.
Bye !!
On 07/05/2013 08:48 AM, Chen Gang F T wrote:
On 07/05/2013 08:14 AM, Stephen Rothwell wrote:
On Fri, 05 Jul 2013 08:03:31 +0800 Chen Gang F T
chen.gang.flying.transfor...@gmail.com wrote:
When
Hello maintainers:
Please help check this patch whether OK, when you have time.
Thanks.
On 06/28/2013 10:37 AM, Chen Gang wrote:
> Recommend to let the header file macro mark match the file name.
>
> Signed-off-by: Chen Gang
> ---
> include/asm-generic/iomap.h |6 +++---
> 1 files
On 07/05/2013 08:12 AM, Greg KH wrote:
> I'm done with this thread, it's madness..
Yeah, especially discussing with 'mad users' (e.g. allmodconfig,
randconfig, and me too). ;-)
Thanks.
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On 07/05/2013 08:14 AM, Stephen Rothwell wrote:
> On Fri, 05 Jul 2013 08:03:31 +0800 Chen Gang F T
> wrote:
>> >
>> > When a module select "COMPILE_TEST=y" (e.g with allmodconfig), it has
>> > right to compile under the architecture which no relate
On 07/04/2013 05:25 PM, Arnd Bergmann wrote:
> On Thursday 04 July 2013, Chen Gang wrote:
>
>> > --patch begin--
>> >
>> > 'asm-generic' need provide necessary configuration checking, if can't
>> > pass checking, 'asm-generic' shouldn't
On 07/04/2013 05:25 PM, Arnd Bergmann wrote:
On Thursday 04 July 2013, Chen Gang wrote:
--patch begin--
'asm-generic' need provide necessary configuration checking, if can't
pass checking, 'asm-generic' shouldn't implement it.
On 07/05/2013 08:14 AM, Stephen Rothwell wrote:
On Fri, 05 Jul 2013 08:03:31 +0800 Chen Gang F T
chen.gang.flying.transfor...@gmail.com wrote:
When a module select COMPILE_TEST=y (e.g with allmodconfig), it has
right to compile under the architecture which no related HW support
On 07/05/2013 08:12 AM, Greg KH wrote:
I'm done with this thread, it's madness..
Yeah, especially discussing with 'mad users' (e.g. allmodconfig,
randconfig, and me too). ;-)
Thanks.
--
Chen Gang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Hello maintainers:
Please help check this patch whether OK, when you have time.
Thanks.
On 06/28/2013 10:37 AM, Chen Gang wrote:
Recommend to let the header file macro mark match the file name.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
include/asm-generic/iomap.h |6 +++---
On 07/04/2013 11:06 AM, Steven Rostedt wrote:
> On Thu, 2013-07-04 at 10:42 +0800, Chen Gang F T wrote:
>
>> > Hmm..., I think maybe also has another way: get rid of 'COMPILE_TEST'
>> > (regress the related patch, which is only existent in next-* tree).
> I'
On 07/04/2013 10:29 AM, Steven Rostedt wrote:
> On Thu, 2013-07-04 at 10:10 +0800, Chen Gang F T wrote:
>
>> > Select "COMPILE_TEST=y" with allmodconfig, but can not pass compiling in
>> > many architectures, one of the most reasons is "HW does not suppo
On 07/04/2013 09:23 AM, Steven Rostedt wrote:
> On Wed, 2013-07-03 at 18:12 -0700, Greg KH wrote:
>
>> > confused,
> Good. I thought I was the only one. Confusion loves company, that way we
> can follow each other around in endless circles.
If you think, this mail has already make noises to many
On 07/04/2013 10:03 AM, Steven Rostedt wrote:
> On Thu, 2013-07-04 at 09:49 +0800, Chen Gang wrote:
>
>> > Hmm... at least, it is neither architectures issue nor modules issue.
>> >
>> > So we have to look for who have duty for it, since it is a 'generic'
>> > issue for many architectures and
On 07/04/2013 10:03 AM, Steven Rostedt wrote:
On Thu, 2013-07-04 at 09:49 +0800, Chen Gang wrote:
Hmm... at least, it is neither architectures issue nor modules issue.
So we have to look for who have duty for it, since it is a 'generic'
issue for many architectures and modules, we have
On 07/04/2013 09:23 AM, Steven Rostedt wrote:
On Wed, 2013-07-03 at 18:12 -0700, Greg KH wrote:
confused,
Good. I thought I was the only one. Confusion loves company, that way we
can follow each other around in endless circles.
If you think, this mail has already make noises to many other
On 07/04/2013 10:29 AM, Steven Rostedt wrote:
On Thu, 2013-07-04 at 10:10 +0800, Chen Gang F T wrote:
Select COMPILE_TEST=y with allmodconfig, but can not pass compiling in
many architectures, one of the most reasons is HW does not support.
'asm-generic' is really existent for a long
On 07/04/2013 11:06 AM, Steven Rostedt wrote:
On Thu, 2013-07-04 at 10:42 +0800, Chen Gang F T wrote:
Hmm..., I think maybe also has another way: get rid of 'COMPILE_TEST'
(regress the related patch, which is only existent in next-* tree).
I'm not working on linux-next at the moment. Hmm
On 2013年04月26日 11:54, Mike Qiu wrote:
> 于 2013/4/26 11:42, Chen Gang 写道:
>> On 2013年04月26日 11:25, Chen Gang wrote:
>>> On 2013年04月26日 11:08, Mike Qiu wrote:
于 2013/4/26 10:06, Chen Gang 写道:
> On 2013年04月26日 10:03, Mike Qiu wrote:
>> �� 2013/4/26 9:36, Chen Gang �:
On
On 2013年04月26日 11:54, Mike Qiu wrote:
于 2013/4/26 11:42, Chen Gang 写道:
On 2013年04月26日 11:25, Chen Gang wrote:
On 2013年04月26日 11:08, Mike Qiu wrote:
于 2013/4/26 10:06, Chen Gang 写道:
On 2013年04月26日 10:03, Mike Qiu wrote:
�� 2013/4/26 9:36, Chen Gang �:
On 2013��04��26�� 09:18, Chen Gang
On 2013年04月19日 20:13, Arnd Bergmann wrote:
> On Friday 19 April 2013, Chen Gang wrote:
>> > when compiling with allmodconfig, CONFIG_64BIT=y
>> > the file drivers/base/regmap/regmap-mmio.c will use readq and writeq.
>> >
>> > so we need implement these functions.
>> >
>> > BTW:
>> >
On 2013年04月19日 20:13, Arnd Bergmann wrote:
On Friday 19 April 2013, Chen Gang wrote:
when compiling with allmodconfig, CONFIG_64BIT=y
the file drivers/base/regmap/regmap-mmio.c will use readq and writeq.
so we need implement these functions.
BTW:
the coding style can not
On 2013年04月18日 04:07, Andrew Morton wrote:
> On Wed, 17 Apr 2013 12:04:02 +0800 Chen Gang wrote:
>
>> > since "normally audit_add_tree_rule() will free it on failure",
>> > need free it completely, when failure occures.
>> >
>> > need additional put_tree before return, since get_tree
On 2013年04月18日 04:07, Andrew Morton wrote:
On Wed, 17 Apr 2013 12:04:02 +0800 Chen Gang gang.c...@asianux.com wrote:
since normally audit_add_tree_rule() will free it on failure,
need free it completely, when failure occures.
need additional put_tree before return, since
On 2013年04月12日 22:29, Serge E. Hallyn wrote:
> Quoting Chen Gang (gang.c...@asianux.com):
>> >
>> > after kfree acct, also set ns->bacct to NULL.
>> >
>> > Signed-off-by: Chen Gang
> Acked-by: Serge Hallyn
>
thanks.
--
Chen Gang
Flying Transformer
--
To unsubscribe from this list:
On 2013年04月12日 22:29, Serge E. Hallyn wrote:
Quoting Chen Gang (gang.c...@asianux.com):
after kfree acct, also set ns-bacct to NULL.
Signed-off-by: Chen Gang gang.c...@asianux.com
Acked-by: Serge Hallyn serge.hal...@canonical.com
thanks.
--
Chen Gang
Flying Transformer
--
To
On 2013年04月09日 23:00, Steven Rostedt wrote:
> I'll queue this up for my 3.10 queue. I'm going to merge this patch with
> the previous patch you sent that updates trace.c
>
> Thanks,
>
> -- Steve
thanks too.
--
Chen Gang
Flying Transformer
--
To unsubscribe from this list: send the line
On 2013年04月09日 23:00, Steven Rostedt wrote:
I'll queue this up for my 3.10 queue. I'm going to merge this patch with
the previous patch you sent that updates trace.c
Thanks,
-- Steve
thanks too.
--
Chen Gang
Flying Transformer
--
To unsubscribe from this list: send the line
On 2013年03月29日 02:31, David Miller wrote:
> Please post networking patches to net...@vger.kernel.org, thanks.
ok, thanks.
it is my fault.
originally, I get mail addresses by ./scripts/get_maintainers.pl
it is a useful tool for members to get mail addresses.
I should fully use it,
On 2013年03月29日 02:31, David Miller wrote:
Please post networking patches to net...@vger.kernel.org, thanks.
ok, thanks.
it is my fault.
originally, I get mail addresses by ./scripts/get_maintainers.pl
it is a useful tool for members to get mail addresses.
I should fully use it,
On 2013年03月27日 22:04, Ed Cashin wrote:
> Thanks. Jens Axboe said about it to Dan Carpenter that ...
>
>> > It was fixed up yesterday, it was a merge error in the for-next branch.
thanks.
:-)
--
Chen Gang
Flying Transformer
--
To unsubscribe from this list: send the line "unsubscribe
On 2013年03月27日 22:04, Ed Cashin wrote:
Thanks. Jens Axboe said about it to Dan Carpenter that ...
It was fixed up yesterday, it was a merge error in the for-next branch.
thanks.
:-)
--
Chen Gang
Flying Transformer
--
To unsubscribe from this list: send the line unsubscribe
On 2013年03月23日 03:17, Yoder Stuart-B08248 wrote:
> allmodconfig is creating config combinations that don't
> happen in a normal build (at least currently)-- 64-bit build
> that enables EPAPR_PARAVIRT but not PPC_BOOK3E_64.
if it should not happen.
can we add dependency to let it will never
On 2013年03月23日 03:17, Yoder Stuart-B08248 wrote:
allmodconfig is creating config combinations that don't
happen in a normal build (at least currently)-- 64-bit build
that enables EPAPR_PARAVIRT but not PPC_BOOK3E_64.
if it should not happen.
can we add dependency to let it will never
it seems:
only move slb_miss_realmode to the end, can fix this issue without negative
effect.
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index 200afa5..56bd923 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++
it seems:
only move slb_miss_realmode to the end, can fix this issue without negative
effect.
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index 200afa5..56bd923 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++
On 2013年03月15日 19:29, Arnd Bergmann wrote:
> On Friday 15 March 2013, Chen Gang F T wrote:
>> > excuse me, my English is not quite well.
>> >
>> > I guess your meaning is:
>> > "that bug" means the toolchain's bug (need toolchain people fix
On 2013年03月15日 19:29, Arnd Bergmann wrote:
On Friday 15 March 2013, Chen Gang F T wrote:
excuse me, my English is not quite well.
I guess your meaning is:
that bug means the toolchain's bug (need toolchain people fix it).
prefer to apply your patch, before that bug is fixed
于 2013年03月15日 18:56, Arnd Bergmann 写道:
> Right. The fact that as prints a warning for those instructions makes sense
> given that we are telling it we want to run on *all* ARM architectures,
> and that ARMv8 has deprecated them officially.
>
> Of course, what is bogus about this is the "NULL"
于 2013年03月15日 18:56, Arnd Bergmann 写道:
Right. The fact that as prints a warning for those instructions makes sense
given that we are telling it we want to run on *all* ARM architectures,
and that ARMv8 has deprecated them officially.
Of course, what is bogus about this is the NULL part
Hello all:
Opinion:
after think of again, for "10 patches per month":
I think in kernel wide, it is not quite hard to perform.
Finished:
currently (within Jan 2013)
in next-20130125 tree, can find about 11 patches of mine.
patch contents: usb, staging, tty sub-systems, ...
Hello all:
Opinion:
after think of again, for 10 patches per month:
I think in kernel wide, it is not quite hard to perform.
Finished:
currently (within Jan 2013)
in next-20130125 tree, can find about 11 patches of mine.
patch contents: usb, staging, tty sub-systems, ...
于 2013年01月14日 23:12, Greg KH 写道:
> If you think you can do better than that, wonderful, I would love for
> you to start out reviewing code and helping with handling stuff like
> that. Please do so before complaining about anything.
it seems, he is not complaining, maybe for him, he has to
于 2013年01月14日 23:12, Greg KH 写道:
If you think you can do better than that, wonderful, I would love for
you to start out reviewing code and helping with handling stuff like
that. Please do so before complaining about anything.
it seems, he is not complaining, maybe for him, he has to treat
于 2013年01月14日 01:41, Guenter Roeck 写道:
> Maybe the confusion arises from the somewhat lax use of the term "const
> pointer", and the csomewhat confusing way of defining variable attributes in
> C.
> Strictly speaking,
> const char *name;
> which is identical to
> char const *name;
>
于 2013年01月14日 04:54, Cong Ding 写道:
> On Sun, Jan 13, 2013 at 9:10 AM, Chen Gang F T
> wrote:
>> > all together:
>> > kfree() should use 'const void *' as parameter type
>> > the free() of C Library is incorrect (it use void *).
> you are definitely wr
Hello Antoine:
after read through the whole reply of Linus Torvalds for it
(the time stamp is "Wed, 16 Jan 2008 10:39:00 -0800 (PST)").
at least for me, his reply is correct in details.
although what you said is also correct,
it seems you misunderstanding what he said.
all
Hello Antoine:
after read through the whole reply of Linus Torvalds for it
(the time stamp is Wed, 16 Jan 2008 10:39:00 -0800 (PST)).
at least for me, his reply is correct in details.
although what you said is also correct,
it seems you misunderstanding what he said.
all
于 2013年01月14日 04:54, Cong Ding 写道:
On Sun, Jan 13, 2013 at 9:10 AM, Chen Gang F T
chen.gang.flying.transfor...@gmail.com wrote:
all together:
kfree() should use 'const void *' as parameter type
the free() of C Library is incorrect (it use void *).
you are definitely wrong. both
于 2013年01月14日 01:41, Guenter Roeck 写道:
Maybe the confusion arises from the somewhat lax use of the term const
pointer, and the csomewhat confusing way of defining variable attributes in
C.
Strictly speaking,
const char *name;
which is identical to
char const *name;
is not a
于 2013年01月08日 22:53, Theodore Ts'o 写道:
firstly, thank you for your reply in details.
:-)
> yaffs2 is not a _standard_ file system for Android. There may be some
> phones which use it, but the much more common is either FAT (for the
> older phones) or ext4. The Google AOSP releases for
Hello all:
Consult:
whether the latest kernel can update the latest android OS ?
it is android 4.0 (kernel-3.0.8)
under arm Samsung S5PV210 with yaffs2 file system
Background:
development board:
the core hardware is Samsung S5PV210
the extended vendor is FriendlyARM (a
Hello all:
Consult:
whether the latest kernel can update the latest android OS ?
it is android 4.0 (kernel-3.0.8)
under arm Samsung S5PV210 with yaffs2 file system
Background:
development board:
the core hardware is Samsung S5PV210
the extended vendor is FriendlyARM (a
于 2013年01月08日 22:53, Theodore Ts'o 写道:
firstly, thank you for your reply in details.
:-)
yaffs2 is not a _standard_ file system for Android. There may be some
phones which use it, but the much more common is either FAT (for the
older phones) or ext4. The Google AOSP releases for pretty
于 2012年12月28日 13:12, amit mehta 写道:
On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote:
> can anybody tell me how to look into source code, as most are hidden in
> kernel.
You can find the Linux source code at http://kernel.org/ .
>> for browsing the code unfortunately
于 2012年12月28日 13:12, amit mehta 写道:
On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote:
> can anybody tell me how to look into source code, as most are hidden in
> kernel.
You can find the Linux source code at http://kernel.org/ .
>> for browsing the code unfortunately
于 2012年12月28日 13:12, amit mehta 写道:
On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote:
can anybody tell me how to look into source code, as most are hidden in
kernel.
You can find the Linux source code at http://kernel.org/ .
for browsing the code unfortunately there is no good
于 2012年12月28日 13:12, amit mehta 写道:
On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote:
can anybody tell me how to look into source code, as most are hidden in
kernel.
You can find the Linux source code at http://kernel.org/ .
for browsing the code unfortunately there is no good
96 matches
Mail list logo
