On 7/12/16 12:20, Michael Ellerman wrote:
> Chen Gang <cheng...@emindsoft.com.cn> writes:
>
>> On 7/11/16 07:47, Dave Hansen wrote:
>>> On 07/09/2016 09:29 AM, cheng...@emindsoft.com.cn wrote:
>>>> -static inline int arch_validate_prot(unsig
), then
- Finish left architectures which need __BUILDING_TIME_BIG_ENDIAN__
(4 patches, I guess).
Welcome any ideas, suggestions, or completions. And if no additional
reply, I shall not send any additional information any more to avoid
spam to other members.
Thanks.
On 08/24/2014 04:38 PM, Chen Gang
Hello Maintainers:
Is this patch OK? If it pass basic checking, please let me know, and I
shall try to make another related patch for KBuild (I can do nothing
related with Kbuild, before get confirmation for this patch).
Thanks.
On 8/15/14 17:01, Chen Gang wrote:
On 8/15/14 6:14, Chen Gang
On 8/15/14 6:14, Chen Gang wrote:
On 08/15/2014 02:04 AM, Ralf Baechle wrote:
OK, thanks, I assumes when support both endian, the default choice is
CPU_BIG_ENDIAN, although no default value for choice (originally, I did
worry about it).
So I think you can just drop the MIPS segment
in alpha order.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
arch/alpha/Kconfig | 1 +
arch/arc/Kconfig| 1 +
arch/arm/Kconfig| 1 +
arch/arm64/Kconfig | 1 +
arch/avr32/Kconfig | 1 +
arch/blackfin/Kconfig | 1 +
arch/c6x/Kconfig| 1 +
arch
On 08/15/2014 02:04 AM, Ralf Baechle wrote:
On Fri, Aug 15, 2014 at 12:54:53AM +0800, Chen Gang wrote:
Normal architectures:
- Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc
- Little endian: alpha, blackfin, cris, hexagon, ia64, metag, mn10300,
score
On 08/15/2014 02:27 AM, Lennox Wu wrote:
I don't think it's necessary, what's the benfit?
2014-08-15 2:21 GMT+08:00 Vineet Gupta vineet.gup...@synopsys.com:
On Thursday 14 August 2014 09:55 AM, Chen Gang wrote:
[...]
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 9596b0a..e939abd
On 8/15/14 7:12, Vineet Gupta wrote:
On Thursday 14 August 2014 03:22 PM, Chen Gang wrote:
For many individual modules may need check CPU_LITTLE_ENDIAN or
CPU_BIG_ENDIAN, which is an architecture's attribute.
Or they have to list many architectures which they support, which they
don't
On 8/15/14 9:52, Max Filippov wrote:
On Fri, Aug 15, 2014 at 5:47 AM, Max Filippov jcmvb...@gmail.com wrote:
Hi Chen,
On Thu, Aug 14, 2014 at 8:54 PM, Chen Gang gang.chen.5...@gmail.com wrote:
Normal architectures:
- Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc
- Little
On 11/01/2013 12:25 AM, Rafael J. Wysocki wrote:
On 10/31/2013 3:18 AM, Chen Gang wrote:
Hello Maintainers
It is removed by bcc8edb driver core: remove dev_attrs from struct
class in Oct 5 2013. But 75d2364 PowerCap: Add class driver still
use it in Oct 11 2013.
The related error
by default]
Please give a check thanks.
Thanks.
--
Chen Gang
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
]
arch/powerpc/platforms/powernv/rng.c:85:12: warning: assignment makes pointer
from integer without a cast [enabled by default]
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/platforms/powernv/rng.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch
On 09/26/2013 06:29 PM, Mark Brown wrote:
On Mon, Sep 23, 2013 at 11:36:21AM +0800, Chen Gang wrote:
NO_IRQ may be defined as '(unsigned int) -1' in some architectures
(arm, sh ...), and either may not be defined in some architectures
which can enable SND_SOC_FSL_SSI (e.g. allmodconfig for arc
, or will cause compiling issue or run
time bug in some architectures.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
sound/soc/fsl/fsl_ssi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 6ac8730..6c17d3e 100644
of checking NO_IRQ, or will cause compiling
issue or run time bug in some architectures.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
sound/soc/fsl/fsl_ssi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index
On 08/05/2013 12:34 PM, Paul Mackerras wrote:
On Mon, Jul 22, 2013 at 02:32:35PM +0800, Chen Gang wrote:
'rmls' is 'unsigned long', lpcr_rmls() will return negative number when
failure occurs, so it need a type cast for comparing.
'lpid' is 'unsigned long', kvmppc_alloc_lpid() return
Hello Maintainers:
Please help check this patch whether OK or not, when you have time.
Thanks.
On 07/22/2013 02:32 PM, Chen Gang wrote:
'rmls' is 'unsigned long', lpcr_rmls() will return negative number when
failure occurs, so it need a type cast for comparing.
'lpid' is 'unsigned long
On 07/26/2013 07:45 PM, Chen Gang wrote:
c0080d30: 00 00 04 ac .long 0x4ac
c0080d34: 60 00 00 00 nop
c0080d38: 60 00 00 00 nop
c0080d3c: 60 00 00 00 nop
816 case 'm':
817 cmd = inchar
On 07/25/2013 01:51 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
For an extern function, if the performance is not sensible, better to
have the return value which can indicate the failure with the negative
number.
The return value is meaningless
On 07/25/2013 02:03 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 15:51 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
For an extern function, if the performance is not sensible, better to
have the return value which can indicate the failure
On 07/25/2013 03:33 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 14:17 +0800, Chen Gang wrote:
Hmm... for an extern function (espeically have been implemented in
various modules), normally, we can assume it may fail in some cases
(although now, we don't know what cases can
On 07/25/2013 04:06 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 15:59 +0800, Chen Gang wrote:
For my opinion: one fix may like below (assume have removed max_cpus)
which is more reasonable for code readers.
So instead of just failing to bring the secondary CPUs, but potentially
On 07/25/2013 04:28 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 16:22 +0800, Chen Gang wrote:
On 07/25/2013 04:06 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 15:59 +0800, Chen Gang wrote:
For my opinion: one fix may like below (assume have removed max_cpus
On 07/24/2013 08:38 AM, Chen Gang wrote:
On 07/23/2013 09:58 PM, Michael Ellerman wrote:
On Mon, Jul 22, 2013 at 03:02:53PM +0800, Chen Gang wrote:
Hello Maintainers:
With allmodconfig and EXTRA_CFLAGS=-W, it reports warnings below:
arch/powerpc/xmon/xmon.c:3027:6: warning: variable ‘i
On 07/25/2013 11:15 AM, Michael Ellerman wrote:
On Wed, Jul 24, 2013 at 10:09:33AM +0800, Chen Gang wrote:
On 07/24/2013 09:16 AM, Michael Ellerman wrote:
On Wed, Jul 24, 2013 at 08:28:07AM +0800, Chen Gang wrote:
On 07/23/2013 09:44 PM, Michael Ellerman wrote:
On Mon, Jul 22, 2013
.
Thanks.
--
Chen Gang
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 07/23/2013 09:44 PM, Michael Ellerman wrote:
On Mon, Jul 22, 2013 at 12:21:16PM +0530, Srivatsa S. Bhat wrote:
On 07/22/2013 12:10 PM, Chen Gang wrote:
Since not need 'max_cpus' after the related commit, the related code
are useless too, need be removed.
The related commit:
c1aa687
On 07/23/2013 09:58 PM, Michael Ellerman wrote:
On Mon, Jul 22, 2013 at 03:02:53PM +0800, Chen Gang wrote:
Hello Maintainers:
With allmodconfig and EXTRA_CFLAGS=-W, it reports warnings below:
arch/powerpc/xmon/xmon.c:3027:6: warning: variable ‘i’ might be clobbered by
‘longjmp’ or ‘vfork
On 07/24/2013 09:16 AM, Michael Ellerman wrote:
On Wed, Jul 24, 2013 at 08:28:07AM +0800, Chen Gang wrote:
On 07/23/2013 09:44 PM, Michael Ellerman wrote:
On Mon, Jul 22, 2013 at 12:21:16PM +0530, Srivatsa S. Bhat wrote:
On 07/22/2013 12:10 PM, Chen Gang wrote:
Since not need 'max_cpus
but not
used [-Wunused-but-set-parameter]
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/kernel/smp.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 38b0ba6..8c2bae4 100644
--- a/arch
On 07/22/2013 02:18 PM, Srivatsa S. Bhat wrote:
On 07/22/2013 11:28 AM, Chen Gang wrote:
Since not need 'max_cpus' after the related commit, the related code
are useless too, need be removed.
The related commit:
c1aa687 powerpc: Clean up obsolete code relating to decrementer
'rmls' is 'unsigned long', lpcr_rmls() will return negative number when
failure occurs, so it need a type cast for comparing.
'lpid' is 'unsigned long', kvmppc_alloc_lpid() return negative number
when failure occurs, so it need a type cast for comparing.
Signed-off-by: Chen Gang gang.c
but not
used [-Wunused-but-set-parameter]
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/kernel/smp.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 38b0ba6..7edbd5b 100644
--- a/arch
annotation or the annotation of .pnv_pci_init_ioda_phb is wrong.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/platforms/powernv/pci-ioda.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc
On 07/22/2013 02:51 PM, Srivatsa S. Bhat wrote:
On 07/22/2013 12:10 PM, Chen Gang wrote:
Since not need 'max_cpus' after the related commit, the related code
are useless too, need be removed.
The related commit:
c1aa687 powerpc: Clean up obsolete code relating to decrementer
’ [-Wclobbered]
arch/powerpc/xmon/xmon.c:352:48: warning: argument ‘fromipi’ might be clobbered
by ‘longjmp’ or ‘vfork’ [-Wclobbered]
Excuse me, I am not quite sure about it whether can cause issue or not.
Welcome any members' suggestions or completions for it.
Thanks.
--
Chen Gang
On 07/23/2013 08:28 AM, Bjorn Helgaas wrote:
On Mon, Jul 22, 2013 at 12:52 AM, Chen Gang gang.c...@asianux.com wrote:
pnv_pci_init_ioda2_phb() is only used during boot up, so need add
'__init' to save the related memory, and avoid related warning:
The function .pnv_pci_init_ioda2_phb
Hello Maintainers:
Please help check this patch whether is OK, when you have time.
Thanks.
On 05/21/2013 05:20 PM, Chen Gang wrote:
When error occurs, need return the related error code to let upper
caller know about it.
ppc_md.nvram_size() can return the error code (e.g
features for all platforms,
since most of architectures need not support it, and the architecture
which really need minimal size, can implement it by itself as a
architecture specific feature.
Thanks.
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev
Hello Maintainers:
Please help check this patch whether is OK, when you have time.
Thanks.
On 05/21/2013 05:20 PM, Chen Gang wrote:
When error occurs, need return the related error code to let upper
caller know about it.
ppc_md.nvram_size() can return the error code (e.g
inline asm code, then
followed by 'unreachable' function, or another more better fix ways).
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/arm/Kconfig |1 -
arch/avr32/Kconfig|1 -
arch/blackfin/Kconfig |1 -
arch/h8300/Kconfig|1 -
arch
).
So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/arm/Kconfig |1 -
arch/avr32/Kconfig|1 -
arch/blackfin/Kconfig |1 -
arch/h8300/Kconfig|1 -
arch/hexagon/Kconfig
On 05/23/2013 05:12 PM, Geert Uytterhoeven wrote:
On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
On Thu, May 23, 2013 at 9:57 AM, Chen Gang gang.c...@asianux.com wrote:
-config
to Disabling this option, let it specify its own BUG().
So, most of architectures need not consider this issue again.
Thanks.
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org
BUG(), if
they want some special features.
SO most of arches can skip this issue.
Thanks.
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
*/
27
28 #include asm-generic/bug.h
29
30 #endif
Thanks.
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 05/24/2013 10:13 AM, Chen Gang wrote:
On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
On Thursday 23 May 2013, Russell King - ARM Linux
On 05/21/2013 04:10 PM, Paul Mackerras wrote:
On Tue, May 21, 2013 at 01:48:58PM +0800, Chen Gang wrote:
When error occurs, need return the related error code to let upper
caller know about it.
ppc_md.nvram_size() can return the error code (e.g. core99_nvram_size()
in 'arch/powerpc
.
The original related patch: f9ce299 [PATCH] powerpc: fix large nvram
access.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/kernel/nvram_64.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel
: f9ce299 [PATCH] powerpc: fix large nvram
access
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/kernel/nvram_64.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
index 48fbc2b
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月27日 17:32, Mike Qiu wrote:
I think the diff v2 is correct, but is not the best one for this issue.
I prefer the Paul's patch for this issue which has better performance
:-)
yes, I use your patch and it can work, also Paul's patch can work too.
Good news.
Bye !
:-)
--
Chen
On 2013年04月25日 13:36, Chen Gang wrote:
On 2013年04月25日 12:05, Mike Qiu wrote:
I will try, and plan to get a result within this week (2013-04-28)
Thanks.
Hi
This has block my work now
So I hope you can take a look ASAP
Thanks
:)
The root cause is the room 0x500..0xc00 is not enough when
/kernel/exceptions-64s.S:258: Error: attempt to move .org backwards
make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/include/asm/kvm_asm.h |2 +-
arch/powerpc/kernel/exceptions-64s.S |6 +++---
2 files changed, 4 insertions
Hello Mike:
Please try this patch, at least it can pass compiling with the config
file which you provided under my cross-compiling envrionments.
I do not give a running test now, so better to try to run the new kernel
with this patch.
Thanks.
On 2013年04月25日 16:18, Chen Gang wrote:
When
On 2013年04月25日 17:00, Michael Neuling wrote:
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/include/asm/kvm_asm.h |2 +-
arch/powerpc/kernel/exceptions-64s.S |6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include
On 2013年04月25日 17:05, Chen Gang wrote:
On 2013年04月25日 17:00, Michael Neuling wrote:
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/include/asm/kvm_asm.h |2 +-
arch/powerpc/kernel/exceptions-64s.S |6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff
as my original reply to Mike to bypass it, but get no reply, I
guess he has to face the CONFIG_KVM_BOOK3S_64_PR.
Now, I am just fixing it, when I finish one patch, please help check.
Thanks.
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing
-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/kernel/exceptions-64s.S | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index e789ee7..8997de2 100644
--- a/arch/powerpc/kernel/exceptions
Hello Mike:
This patch can pass compiling with Mike's config file, under my
cross-compiling environments, but does not run under the real machine,
please try it.
Welcome other members to help check this patch whether valid.
Thanks.
On 2013年04月25日 19:51, Chen Gang wrote:
When
On 2013年04月26日 09:06, Chen Gang wrote:
CFAR is the Come From Register. It saves the location of the last
branch and is hence overwritten by any branch.
Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
. = 0x900
.globl decrementer_pSeries
On 2013年04月26日 09:18, Chen Gang wrote:
On 2013年04月26日 09:06, Chen Gang wrote:
CFAR is the Come From Register. It saves the location of the last
branch and is hence overwritten by any branch.
Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
. = 0x900
.globl
On 2013年04月26日 09:58, Mike Qiu wrote:
于 2013/4/25 19:16, Chen Gang 写道:
On 2013年04月25日 14:25, Paul Mackerras wrote:
On Thu, Apr 25, 2013 at 12:05:54PM +0800, Mike Qiu wrote:
This has block my work now
So I hope you can take a look ASAP
Thanks
:)
Mike
As a quick fix, turn
On 2013年04月26日 10:03, Mike Qiu wrote:
�� 2013/4/26 9:36, Chen Gang �:
On 2013��04��26�� 09:18, Chen Gang wrote:
On 2013��04��26�� 09:06, Chen Gang wrote:
CFAR is the Come From Register. It saves the location of the last
branch and is hence overwritten by any branch.
Do we process
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 wrote:
On 2013��04��26�� 09:06, Chen Gang wrote:
CFAR is the Come From Register. It saves the location
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 wrote:
On 2013��04��26�� 09:06, Chen Gang wrote:
CFAR is the Come From
, EXC_STD, SOFTEN_TEST_PR)
+
STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
On 2013年04月24日 14:28, Vasant Hegde wrote:
On 04/23/2013 08:42 AM, Chen Gang wrote:
need set '\0' for 'local_buffer'.
SPLPAR_MAXLENGTH is 1026, RTAS_DATA_BUF_SIZE is 4096. so the contents of
rtas_data_buf may truncated in memcpy.
if contents are really truncated.
the splpar_strlen
On 2013年04月24日 15:23, Vasant Hegde wrote:
On 04/24/2013 12:33 PM, Chen Gang wrote:
On 2013年04月24日 14:28, Vasant Hegde wrote:
On 04/23/2013 08:42 AM, Chen Gang wrote:
need set '\0' for 'local_buffer'.
SPLPAR_MAXLENGTH is 1026, RTAS_DATA_BUF_SIZE is 4096. so the
contents of
rtas_data_buf
Hello Vasant Hegde:
How about this patch, is it OK ?
Thanks.
On 2013年03月25日 12:30, Chen Gang wrote:
Hello Maintainers:
could you help check this patch whether is ok ?
thanks.
On 2013年02月17日 12:00, Chen Gang wrote:
Hello relative members:
please give a glance to this patch
the memory.
Thanks.
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
you post the resulting config here?
Do you have commit in your tree?
commit 087aa036eb79f24b856893190359ba812b460f45
Author: Chen Gang gang.c...@asianux.com
powerpc: make additional room in exception vector area
Sure, that commit certainly in my git tree. And I just try to remove
.
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 2013年04月23日 08:31, Benjamin Herrenschmidt wrote:
On Thu, 2013-04-18 at 12:45 +0800, Chen Gang wrote:
Hello Maintainers:
in arch/powerpc/kernel/lparcfg.c, parse_system_parameter_string()
need set '\0' for 'local_buffer'.
the reason is:
SPLPAR_MAXLENGTH is 1026
. that will cause memory access violation.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/kernel/lparcfg.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index 801a757..d92f387 100644
--- a/arch/powerpc
Hello Maintainers:
in arch/powerpc/kernel/lparcfg.c, parse_system_parameter_string()
need set '\0' for 'local_buffer'.
the reason is:
SPLPAR_MAXLENGTH is 1026, RTAS_DATA_BUF_SIZE is 4096
the contents of rtas_data_buf may truncated in memcpy (line 301).
if contents are
The FWNMI region is fixed at 0x7000 and the vector are now overflowing
that with allmodconfig. Fix that by moving slb_miss_realmode code out
of that region as it doesn't need to be that close to the call sites
(it is a _GLOBAL function)
Signed-off-by: Chen Gang gang.c...@asianux.com
Hello Maintainers:
could you help check this patch whether is ok ?
thanks.
On 2013年03月20日 14:30, Chen Gang wrote:
the smp_release_cpus is a normal funciton and called in normal environments,
but it calls the __initdata spinning_secondaries.
need modify spinning_secondaries
Hello Maintainers:
could you help check this patch whether is ok ?
thanks.
On 2013年02月17日 12:00, Chen Gang wrote:
Hello relative members:
please give a glance to this patch, when you have time.
thanks.
:-)
gchen.
于 2013年01月24日 12:14, Chen Gang 写道:
for tmp_part
On 2013年03月25日 13:14, Stephen Rothwell wrote:
Hi all,
On Mon, 25 Mar 2013 09:31:31 +0800 Chen Gang gang.c...@asianux.com wrote:
The FWNMI region is fixed at 0x7000 and the vector are now overflowing
that with allmodconfig. Fix that by moving slb_miss_realmode code out
On 2013年03月21日 20:38, Benjamin Herrenschmidt wrote:
On Thu, 2013-03-21 at 16:26 +0800, Chen Gang F T wrote:
it seems:
only move slb_miss_realmode to the end, can fix this issue without
negative effect.
Thanks. I'm currently on vacation, I'll have a closer look when I'm back
unless
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
happen in any config
combinations ?
let allmodconfig can not create this config combinamtions:
64-bit build that enables EPAPR_PARAVIRT but not PPC_BOOK3E_64.
thanks.
--
Chen Gang
Flying Transformer
___
Linuxppc-dev mailing list
Linuxppc
.
-
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/kernel/setup_64.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 75fbaceb..e8a2f2e 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b
continue: make additional room in exception vector area.
(if get no reply within a week: before 2013-03-28, I should continue)
welcome any members' (especially Benjamin) suggestions or completions.
thanks.
:-)
On 2013年03月15日 13:14, Chen Gang wrote:
于 2013年03月15日 12:52, Michael Neuling 写
/head_64.S
(head_64.S includes exceptions-64.S)
thanks.
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
time resource.
(originally, I worked for x86(_64) core dump analysing for kernel and
user programs)
thanks.
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc
Hello Benjamin Herrenschmidt:
how about this patch ? is it correct ?
thanks.
:-)
gchen.
于 2013年01月24日 12:14, Chen Gang 写道:
for tmp_part-header.name:
it is Terminating null required only for names 12 chars.
so need to limit the %.12s for it in printk
additional
于 2013年03月08日 19:11, David Laight 写道:
Using strlcpy() also stops someone else having to check it
again in a few years time.
yes.
:-)
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
originally I did not notice src buf len and dest buf len are the same.
so origianlly, it is not a bug issue, it is only for beautify code.
and now, using strcpy is better.
Signed-off-by: Chen Gang gang.c...@asianux.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
drivers/tty/hvc
)
it is really for beautify code.
can I send a fixup patch only for the comments ?
thanks.
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
于 2013年03月08日 12:33, Benjamin Herrenschmidt 写道:
On Fri, 2013-03-08 at 12:23 +0800, Chen Gang wrote:
really it is: using strlcpy doesn't hurt.
the comments and subject of original commit are not quite precision:
it is not for a bug issue (originally I say it is for bug issue
于 2013年03月08日 13:08, Benjamin Herrenschmidt 写道:
Yes, the code is fine as it is now.
ok, thanks.
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
于 2013年03月05日 17:36, Jiri Slaby 写道:
On 03/05/2013 02:58 AM, Chen Gang wrote:
于 2013年02月28日 21:47, Jiri Slaby 写道:
when strlen(pi-location_code[0]) == HVCS_CLC_LENGTH + 2
It cannot, pi-location_code is defined as char[HVCS_CLC_LENGTH + 1].
really, it is, I did not notice
oh, this patch has integrated into next-20130307 tree.
(commit 9276dfd27897a0b29d8b5814f39a1f82f56b6b6b)
it seems we need a regression for this commit, then I send patch v2
is it correct ?
:-)
于 2013年03月07日 12:10, Chen Gang 写道:
于 2013年03月05日 17:36, Jiri Slaby 写道:
On 03/05/2013
于 2013年03月07日 14:05, Benjamin Herrenschmidt 写道:
On Thu, 2013-03-07 at 12:34 +0800, Chen Gang wrote:
oh, this patch has integrated into next-20130307 tree.
(commit 9276dfd27897a0b29d8b5814f39a1f82f56b6b6b)
it seems we need a regression for this commit, then I send patch v2
to do.
excuse me:
within this week, maybe can not get my mail reply, too.
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
于 2013年02月28日 18:41, Jiri Slaby 写道:
On 02/26/2013 04:43 AM, Chen Gang wrote:
when strlen pi-location_code is larger than HVCS_CLC_LENGTH + 1,
original implementation can not let hvcsd-p_location_code NUL
terminated.
so need fix it (also can simplify the code)
It should never
于 2013年02月28日 19:13, Chen Gang 写道:
于 2013年02月28日 18:41, Jiri Slaby 写道:
On 02/26/2013 04:43 AM, Chen Gang wrote:
when strlen pi-location_code is larger than HVCS_CLC_LENGTH + 1,
original implementation can not let hvcsd-p_location_code NUL
terminated.
so need fix it (also can
the dest buf len is 80 (HVCS_CLC_LENGTH + 1).
the src buf len is PAGE_SIZE.
if src buf string len is more than 80, it will cause issue.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/platforms/pseries/hvcserver.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions
1 - 100 of 103 matches
Mail list logo
