On 05/23/2013 05:12 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
> 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 wrote:
>>>&g
c,
score, tile, um, unicore32, xtensa).
So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.
Signed-off-by: Chen Gang
---
arch/arm/Kconfig |1 -
arch/avr32/Kconfig|1 -
arch/blackfin/Kconfig |1 -
arch/h8300/Kconfig|1 -
a
neric/bug.h" which is only for common features.
And each architecture can customize their own BUG(), if one architecture
wants 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
--
then let the specific architectures to implement their own BUG(), if
they want some special features.
SO most of arches can skip this issue.
Thanks.
--
Chen Gang
Asianux Corporation
--
Try New Relic Now & We&#
6 #ifdef CONFIG_DEBUG_BUGVERBOSE
7 #ifndef CONFIG_SUN3
8 #define BUG() do { \
9 printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
10 __builtin_trap(); \
11 } while (0)
12 #else
13 #define BUG() do { \
14 printk("kernel BUG at %s:%d!\n", __
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
>> wrote:
>>>> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>>>>> On Thursda
ures
(e.g. minimal size implementation), can customize their own BUG() and
__WARN_TAINT() to give a better fix (e.g. use one inline asm code, then
followed by 'unreachable' function, or another more better fix ways).
Signed-off-by: Chen Gang
---
arch/arm/Kconfig |1 -
provide the "disable CONFIG_BUG", some of 'crazy users'
(e.g. randconfig) may make 'noise' to most of architectures.
So we need not provide "disable CONFIG_BUG" features for all platforms,
since most of architectures need not s
e a dummy
ioremap() which return NULL, so can be generic enough to mach all cases.
>> > For our case, the ".config" file does not define 'CONFIG_HAS_IOMEM', can
>> > I assume it means "CONFIG_HAS_IOMEM=n" ?
> If I'm not mistaken it works
ivers that cannot work.
> And they may fail in a very bad way.
That is our 'platform' guys feeling, not the 'module' guys, as
'platform' guys, it is better to provide the choice to 'module' guys,
and let them decide by themselves, not forced by us.
Thanks.
On 06/26/2013 02:54 PM, Richard Weinberger wrote:
> Hi!
>
> Am 26.06.2013 08:31, schrieb Chen Gang:
>> For "User Mode Linux", it may enable 'MMU', but not need implement
>> ioremap and iounmap, so "include/asm-generic/io.h" need notice this
MMU) || defined(CONFIG_UML)
>
Oh, really it is. :-)
Thanks.
--
Chen Gang
Asianux Corporation
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
On 06/26/2013 05:38 PM, Richard Weinberger wrote:
> Am 26.06.2013 11:33, schrieb Chen Gang:
>> > On 06/26/2013 05:03 PM, Richard Weinberger wrote:
>>> >> Am 26.06.2013 10:58, schrieb Chen Gang:
>>>>> >>>
On 06/26/2013 06:17 PM, Richard Weinberger wrote:
> Am 26.06.2013 12:01, schrieb Chen Gang:
>> > On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote:
>>> >> On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger
>>> >> wrote:
>>>>>>> &g
>> >
>> > But "no io memory" is not the excuse to not define the related dummy
>> > function.
> UML has no io memory, period.
> Same applies for s390, it also includes asm-generic/io.h in the !CONFIG_PCI
> case.
> UML and s390 are very special here
On 06/26/2013 05:03 PM, Richard Weinberger wrote:
> Am 26.06.2013 10:58, schrieb Chen Gang:
>> > On 06/26/2013 04:39 PM, Richard Weinberger wrote:
>>>>>>>>>>> >>>>>>>>>> The drivers internal code has already check the re
’ [-Werror=implicit-function-declaration]
drivers/ptp/ptp_pch.c:621:13: warning: assignment makes pointer from integer
without a cast [enabled by default]
cc1: some warnings being treated as errors
Signed-off-by: Chen Gang
---
arch/um/include/asm/Kbuild |1 +
include/asm-generic/
On 06/26/2013 06:22 PM, Chen Gang wrote:
> On 06/26/2013 06:17 PM, Richard Weinberger wrote:
>> Am 26.06.2013 12:01, schrieb Chen Gang:
>>>> On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote:
>>>>>> On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger
>
On 07/01/2013 09:40 AM, Chen Gang wrote:
> On 06/26/2013 06:22 PM, Chen Gang wrote:
>> > On 06/26/2013 06:17 PM, Richard Weinberger wrote:
>>> >> Am 26.06.2013 12:01, schrieb Chen Gang:
>>>>> >>>> On 06/26/2013 05:48 PM, Geert Uytterhoeven
On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote:
> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang wrote:
>> > 'asm-generic' need provide necessary configuration checking, if can't
>> > pass checking, 'asm-generic' shouldn't implement it.
>>
lated dummy contents
for it.
Part of 'COMPLE_TEST' help contents in "init/Kconfig":
"...Despite they cannot be loaded there (or even when they load they cannot
be used due to missing HW support)..."
Signed-off-by: Chen Gang
---
include/asm-generic/io.h | 22
On 07/02/2013 06:57 PM, Geert Uytterhoeven wrote:
> On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang wrote:
>> > On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote:
>>> >> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang wrote:
>>>>> >>> > 'asm
On 07/03/2013 08:51 AM, Chen Gang wrote:
> On 07/02/2013 06:57 PM, Geert Uytterhoeven wrote:
>> On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang wrote:
>>>> On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote:
>>>>>> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang wrote
On 07/04/2013 09:12 AM, Greg KH wrote:
> On Thu, Jul 04, 2013 at 08:57:34AM +0800, Chen Gang wrote:
>> > 'COMPILE_TEST=y' will let 'asm-generic' provide self checking sevices to
>> > both modules and architectures (especially with allmodconfig and
>>
odules issue, the root cause is:
"now, 'asm-generic' doesn't provide the related necessary public
services for it".
Thanks.
On 07/03/2013 04:43 PM, Chen Gang wrote:
> On 07/03/2013 04:14 PM, Arnd Bergmann wrote:
>> On Wednesday 03 July 2013, Chen Gang wrote:
>&
On 07/04/2013 12:08 PM, Greg KH wrote:
> On Thu, Jul 04, 2013 at 11:26:53AM +0800, Chen Gang F T wrote:
>> > Please see the related comment in "init/Kconfig" of next-* tree.
> This is now in Linus's tree for 3.11.
>
OK, thanks (at least for me, it is a good
On 07/04/2013 02:12 PM, Greg KH wrote:
> On Thu, Jul 04, 2013 at 12:50:31PM +0800, Chen Gang wrote:
>> On 07/04/2013 12:08 PM, Greg KH wrote:
>>>>> config COMPILE_TEST
>>>>>bool "Compile also drivers which will not load"
>>>>>
On 07/05/2013 08:12 AM, Greg KH wrote:
> On Fri, Jul 05, 2013 at 08:03:31AM +0800, Chen Gang F T wrote:
>> > On 07/04/2013 05:25 PM, Arnd Bergmann wrote:
>>> > > On Thursday 04 July 2013, Chen Gang wrote:
>>> > >
>>>>> &
On 07/04/2013 04:09 PM, Geert Uytterhoeven wrote:
> On Thu, Jul 4, 2013 at 8:12 AM, Greg KH wrote:
>> > On Thu, Jul 04, 2013 at 12:50:31PM +0800, Chen Gang wrote:
>>> >> On 07/04/2013 12:08 PM, Greg KH wrote:
>>>>>> >> >> > config C
ree_tlb();
pgd_clear();
pud_free_tlb();
Signed-off-by: Chen Gang
---
arch/um/kernel/skas/mmu.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/um/kernel/skas/mmu.c b/arch/um/kernel/skas/mmu.c
index 007d550..3fd1951 100644
--- a/arch/um/kernel/skas
On 11/13/2013 05:07 PM, Richard Weinberger wrote:
> Am 13.11.2013 06:06, schrieb Chen Gang:
>> Unfortunately, p?d_alloc() and p?d_free() are not pair!! If p?d_alloc()
>> succeed, they may be used, so in the next failure, we have to skip them
>> to let exit_mmap() or do_m
Firstly, thank you for spending your time resources to reply so many
details.
On 11/14/2013 01:20 PM, Hugh Dickins wrote:
> On Wed, 13 Nov 2013, Chen Gang wrote:
>
>> Unfortunately, p?d_alloc() and p?d_free() are not pair!! If p?d_alloc()
>> succeed, they may be used, so i
On 11/14/2013 02:48 PM, Chen Gang wrote:
>> >From the look of it, if an error did occur in init_stub_pte(),
>> > then the special mapping of STUB_CODE and STUB_DATA would not
>> > be installed, so this area would be invisible to munmap and exit,
>> > and with
On 11/14/2013 03:55 PM, Richard Weinberger wrote:
> Am 14.11.2013 08:33, schrieb Chen Gang:
>> > On 11/14/2013 02:48 PM, Chen Gang wrote:
>>>> >>> >From the look of it, if an error did occur in init_stub_pte(),
>>>>> >>>> then the spe
On 11/14/2013 03:33 PM, Chen Gang wrote:
> On 11/14/2013 02:48 PM, Chen Gang wrote:
>>> >From the look of it, if an error did occur in init_stub_pte(),
>>>> then the special mapping of STUB_CODE and STUB_DATA would not
>>>> be installed, so this area would be
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 :
>
>> On Thursday 14 August 2014 09:55 AM, Chen Gang wrote:
[...]
>>> diff --git a/arch/arc/Kconfig b/arch/arc
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,
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 architecture
the select value in alpha order.
Signed-off-by: Chen Gang
---
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/cri
On 8/15/14 9:52, Max Filippov wrote:
> On Fri, Aug 15, 2014 at 5:47 AM, Max Filippov wrote:
>> Hi Chen,
>>
>> On Thu, Aug 14, 2014 at 8:54 PM, Chen Gang wrote:
>>> Normal architectures:
>>>
>>> - Big endian: avr32, frv, m68k, openrisc, par
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 th
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
(hope I can finish), 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
bout that, then can fix this issue.
The related error (with allmodconfig under um):
MODPOST 1205 modules
ERROR: "syscall" [fs/hostfs/hostfs.ko] undefined!
Signed-off-by: Chen Gang
---
arch/um/kernel/ksyms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/um/ker
Hello Maintainers:
Please help check this patch, when you have time.
Thanks.
On 10/4/14 21:11, Chen Gang wrote:
> syscall() is implemented in libc.so/a (e.g. for glibc, in "syscall.o"),
> so for normal ".o" files, it is undefined, neither can be found within
> kerne
y make noises to many other members,
please reply mail next, which only contents the related members. And I
will follow with the address which you provide.
Thanks.
--
Chen Gang
--
This SF.net email is sponsored by Window
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 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&
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).
>
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
---
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&#x
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,
>> > randc
53 matches
Mail list logo
