On 07/06/2015 06:48 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Sun, 5 Jul 2015 18:57:51 +0200 Geert Uytterhoeven
> wrote:
>>
>> On Sat, Jul 4, 2015 at 11:35 PM, Chen Gang
>> wrote:
>>> It needs clk_add_alias() from clk drivers, which is implemen
lmodconfig under cris for next-20150702):
drivers/built-in.o: In function `board_staging_register_clock':
drivers/staging/board/board.c:131: undefined reference to `clk_add_alias'
Signed-off-by: Chen Gang
---
drivers/staging/board/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 del
t it includes
"asm/unaligned.h" too. And also include "asm/byteorder.h" since it is
the first include file".
Signed-off-by: Chen Gang
---
drivers/staging/rtl8192e/rtl819x_BAProc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/r
config | xargs grep --color 64K" to find all 64K
page macros.
Signed-off-by: Chen Gang
---
drivers/staging/lustre/lustre/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/Kconfig
b/drivers/staging/lustre/lustre/Kconfig
index 4f65ba1..
;-';
> sptlrpc_flavor2name_bulk(sf, &bspec[1], sizeof(bspec) - 1);
> - strncat(buf, bspec, bufsize);
> + strlcat(buf, bspec, bufsize);
> }
>
> - buf[bufsize - 1] = '\0';
> return buf;
> }
> EXPO
‘dbg_iounmap’:
drivers/staging/unisys/include/uisutils.h:108:2: error: implicit declaration
of function ‘iounmap’ [-Werror=implicit-function-declaration]
iounmap(addr);
^
Signed-off-by: Chen Gang
---
drivers/staging/unisys/uislib/Kconfig | 2 +-
drivers/staging/unisys/visorchipset
ed-off-by: Chen Gang
---
drivers/staging/comedi/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/comedi/Kconfig b/drivers/staging/comedi/Kconfig
index a8bc2b5..b709736 100644
--- a/drivers/staging/comedi/Kconfig
+++ b/drivers/staging/comedi/Kconfig
@@ -426,6 +426,7
On 07/25/2014 11:39 AM, Nick Krause wrote:
> On Thu, Jul 24, 2014 at 11:34 PM, Chen Gang wrote:
>>
>>
>> On 07/25/2014 11:30 AM, Nick Krause wrote:
>>> On Thu, Jul 24, 2014 at 11:21 PM, Chen Gang
>>> wrote:
>>>>
>>>>
>>>
On 07/25/2014 11:30 AM, Nick Krause wrote:
> On Thu, Jul 24, 2014 at 11:21 PM, Chen Gang wrote:
>>
>>
>> On 07/25/2014 11:13 AM, Nick Krause wrote:
>>> On Thu, Jul 24, 2014 at 11:09 PM, Chen Gang
>>> wrote:
>>>>
>>>>
>>>
On 07/25/2014 11:13 AM, Nick Krause wrote:
> On Thu, Jul 24, 2014 at 11:09 PM, Chen Gang wrote:
>>
>>
>> On 07/25/2014 10:53 AM, Nick Krause wrote:
>>> On Thu, Jul 24, 2014 at 10:47 PM, Chen Gang
>>> wrote:
>>>>
>>>>
>>>
On 07/25/2014 10:53 AM, Nick Krause wrote:
> On Thu, Jul 24, 2014 at 10:47 PM, Chen Gang wrote:
>>
>>
>> On 07/25/2014 10:20 AM, Nick Krause wrote:
>>> On Thu, Jul 24, 2014 at 10:15 PM, Chen Gang
>>> wrote:
>>>>
>>>> Excu
On 07/25/2014 10:20 AM, Nick Krause wrote:
> On Thu, Jul 24, 2014 at 10:15 PM, Chen Gang wrote:
>>
>> Excuse me, I did not see the patch details, but I guess it is about
>> whether welcome a new member to upstream kernel. For me, I have 3 ideas
>> about it if I am
a deal.
>>>> Take the challenge at http://eudyptula-challenge.org. After you've solved
>>>> all
>>>> tasks we'll accept patches from you.
>>>>
>>>> --
>>>> Thanks,
>>>> //richard
>>> Tha
On 07/23/2014 07:30 PM, Dan Carpenter wrote:
> On Wed, Jul 23, 2014 at 07:09:22PM +0800, Chen Gang wrote:
>>
>>
>> On 07/17/2014 05:19 PM, Chen Gang wrote:
>>>
>>>
>>> On 07/17/2014 05:16 PM, Dan Carpenter wrote:
>>>&g
On 07/17/2014 05:19 PM, Chen Gang wrote:
>
>
> On 07/17/2014 05:16 PM, Dan Carpenter wrote:
>> On Thu, Jul 17, 2014 at 04:59:09PM +0800, Chen Gang wrote:
>>>>> + return (__force void __iomem *)ERR_PTR(-ENXIO);
>>>>
>>>> T
On 07/22/2014 06:32 PM, Arnd Bergmann wrote:
> On Sunday 20 July 2014 17:45:40 Chen Gang wrote:
>>>
>>> Next, I shall:
>>>
>>> - Remove HAS_IOMEM and NO_IOMEM from kernel, firstly.
>>>
>>> - Try to make dummy IOMEM functions for score
On 07/20/2014 05:51 PM, Chen Gang wrote:
> On 07/20/2014 05:45 PM, Richard Weinberger wrote:
>>
>>
>> Am 20.07.2014 10:38, schrieb Chen Gang:
>>> On 07/19/2014 02:02 AM, Chen Gang wrote:
>>>>> 2014-07-18 18:51 GMT+08:00 Richard Weinberger :
>>>
On 07/20/2014 05:45 PM, Richard Weinberger wrote:
>
>
> Am 20.07.2014 10:38, schrieb Chen Gang:
>> On 07/19/2014 02:02 AM, Chen Gang wrote:
>>>> 2014-07-18 18:51 GMT+08:00 Richard Weinberger :
>>>>> Am 18.07.2014 12:44, schrieb Chen Gang:
>>>&
On 07/20/2014 04:38 PM, Chen Gang wrote:
> On 07/19/2014 02:02 AM, Chen Gang wrote:
>>> 2014-07-18 18:51 GMT+08:00 Richard Weinberger :
>>>> Am 18.07.2014 12:44, schrieb Chen Gang:
>>>>> On 07/18/2014 03:35 PM, Richard Weinberger wrote:
>&g
On 07/19/2014 02:02 AM, Chen Gang wrote:
>> 2014-07-18 18:51 GMT+08:00 Richard Weinberger :
>>> Am 18.07.2014 12:44, schrieb Chen Gang:
>>>> On 07/18/2014 03:35 PM, Richard Weinberger wrote:
>>>>> Am 18.07.2014 02:36, schrieb Chen Gang:
>>>&g
-07-18 18:51 GMT+08:00 Richard Weinberger :
>> Am 18.07.2014 12:44, schrieb Chen Gang:
>>> On 07/18/2014 03:35 PM, Richard Weinberger wrote:
>>>> Am 18.07.2014 02:36, schrieb Chen Gang:
>>>>>
>>>>> On 07/18/2014 02:09 AM, Richard Weinberger wro
On 07/18/2014 03:35 PM, Richard Weinberger wrote:
> Am 18.07.2014 02:36, schrieb Chen Gang:
>>
>> On 07/18/2014 02:09 AM, Richard Weinberger wrote:
>>> Am 17.07.2014 12:48, schrieb Arnd Bergmann:
>>>> AFAICT, NO_IOMEM only has a real purpose on UML these days
ppear in generic include directory. And
then remove all HAS_IOMEM and NO_IOMEM from kernel.
If score sticks to NO_IOMEM, and can not remove score from kernel only
because of this reason. I also suggest implement dummy functions within
score itself.
Thanks.
--
Chen Gang
Open, share, and attit
On 07/18/2014 05:05 AM, Arnd Bergmann wrote:
> On Thursday 17 July 2014 16:41:14 Chris Metcalf wrote:
>> On 7/17/2014 7:28 AM, Chen Gang wrote:
>>> On 07/17/2014 06:48 PM, Arnd Bergmann wrote:
>>>> AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we
On 07/17/2014 06:38 PM, Arnd Bergmann wrote:
> On Thursday 17 July 2014 17:29:31 Chen Gang wrote:
>>>
>>> COMPILE_TEST is a great tool in general, but it has its limits.
>>> In particular, the case for !CONFIG_IOMEM is completely obscure
>>> and we won'
On 07/17/2014 06:58 PM, Richard Weinberger wrote:
> Am 17.07.2014 12:28, schrieb Arnd Bergmann:
>> On Thursday 17 July 2014 11:26:57 Richard Weinberger wrote:
>>> Am 17.07.2014 11:20, schrieb Arnd Bergmann:
>>>> On Thursday 17 July
On 07/17/2014 06:48 PM, Arnd Bergmann wrote:
> On Thursday 17 July 2014 12:40:25 Lars-Peter Clausen wrote:
>> On 07/17/2014 11:20 AM, Arnd Bergmann wrote:
>>> On Thursday 17 July 2014 09:27:58 Chen Gang wrote:
>>>> gfp_t gfp_
eed
communicate with gcc/binutils members.
At present, the related score maintainers are still active in upstream
kernel, so we also need the related maintainers' ideas and suggestions.
Thanks
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On 07/17/2014 05:20 PM, Arnd Bergmann wrote:
> On Thursday 17 July 2014 09:27:58 Chen Gang wrote:
>> gfp_t gfp_mask, unsigned int order);
>> extern void devm_free_pages(struct device *dev, unsigned long addr);
>>
>> +#ifde
On 07/17/2014 05:16 PM, Dan Carpenter wrote:
> On Thu, Jul 17, 2014 at 04:59:09PM +0800, Chen Gang wrote:
>>>> + return (__force void __iomem *)ERR_PTR(-ENXIO);
>>>
>>> There's apparently an IOMEM_ERR_PTR() for this nowadays...
>>>
>>
>&g
On 07/17/2014 04:37 PM, Thierry Reding wrote:
> On Thu, Jul 17, 2014 at 09:27:58AM +0800, Chen Gang wrote:
> [...]
>> diff --git a/include/linux/device.h b/include/linux/device.h
>> index c2421e0..a7500c3 100644
>> --- a/include/linux/device.h
>> +++ b/include/linux
On 07/15/2014 10:38 PM, Chen Gang wrote:
> On 07/15/2014 09:11 AM, Chen Gang wrote:
>>
>>
>> On 07/15/2014 08:53 AM, Guenter Roeck wrote:
>>> On 07/14/2014 05:34 PM, Chen Gang wrote:
>>>> On 07/14/2014 05:22 PM, Chen Gang wrote:
>>>
On 07/15/2014 09:11 AM, Chen Gang wrote:
>
>
> On 07/15/2014 08:53 AM, Guenter Roeck wrote:
>> On 07/14/2014 05:34 PM, Chen Gang wrote:
>>> On 07/14/2014 05:22 PM, Chen Gang wrote:
>>>>
>>>> 在 2014年7月14日,下午4:57,Richard Weinberger 写道:
>>&g
在 2014年7月15日,上午9:40,Greg Kroah-Hartman 写道:
> On Mon, Jul 14, 2014 at 08:04:15PM +0800, Chen Gang wrote:
>>
>> For drivers/staging/lustre/lustre/include/lustre_sec.h:391:
>>
>> - staging tree: use '\t ' between 'die' and '(
On 07/15/2014 08:53 AM, Guenter Roeck wrote:
> On 07/14/2014 05:34 PM, Chen Gang wrote:
>> On 07/14/2014 05:22 PM, Chen Gang wrote:
>>>
>>> 在 2014年7月14日,下午4:57,Richard Weinberger 写道:
>>>
>>>> Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
>&g
On 07/14/2014 05:22 PM, Chen Gang wrote:
>
> 在 2014年7月14日,下午4:57,Richard Weinberger 写道:
>
>> Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
>>> On 07/14/2014 10:31 AM, Richard Weinberger wrote:
>>>> Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
>
On 07/14/2014 05:22 PM, Chen Gang wrote:
>
> 在 2014年7月14日,下午4:57,Richard Weinberger 写道:
>
>> Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
>>> On 07/14/2014 10:31 AM, Richard Weinberger wrote:
>>>> Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
>
pc/sec.o] Error 1
> make[4]: *** [drivers/staging/lustre/lustre/ptlrpc] Error 2
> make[3]: *** [drivers/staging/lustre/lustre] Error 2
> make[2]: *** [drivers/staging/lustre] Error 2
> make[1]: *** [drivers/staging] Error 2
> make: *** [drivers] Error 2
>
>
> Si
ctx->cc_ops->die(req->rq_cli_ctx, 0);
^
make[5]: *** [drivers/staging/lustre/lustre/ptlrpc/sec.o] Error 1
make[4]: *** [drivers/staging/lustre/lustre/ptlrpc] Error 2
make[3]: *** [drivers/staging/lustre/lustre] Error 2
make[2]: *** [drivers/staging/lustr
t really any
>> different from making the driver selectable via COMPILE_TEST for any other
>> platform. To hit the issue you'd have to instantiate a device driver
>> instance for a device that
>> physically does not exist. This will always result in a failure.
>
> Okay, y
On 07/14/2014 06:50 AM, Greg Kroah-Hartman wrote:
> On Mon, Jul 14, 2014 at 06:38:24AM +0800, Chen Gang wrote:
>> On 07/14/2014 06:31 AM, Chen Gang wrote:
>>> On 07/14/2014 05:41 AM, Chen Gang wrote:
>>>> On 07/14/2014 03:05 AM, Greg Kroah-Hartman wrote:
>>&g
On 07/14/2014 06:31 AM, Chen Gang wrote:
> On 07/14/2014 05:41 AM, Chen Gang wrote:
>> On 07/14/2014 03:05 AM, Greg Kroah-Hartman wrote:
>>> On Sun, Jul 13, 2014 at 10:50:55PM +0800, Chen Gang wrote:
>>>> Some of architectures have already defined 'die' a
On 07/14/2014 05:41 AM, Chen Gang wrote:
> On 07/14/2014 03:05 AM, Greg Kroah-Hartman wrote:
>> On Sun, Jul 13, 2014 at 10:50:55PM +0800, Chen Gang wrote:
>>> Some of architectures have already defined 'die' as macro, so can not use
>>> this common name as
On 07/14/2014 03:05 AM, Greg Kroah-Hartman wrote:
> On Sun, Jul 13, 2014 at 10:50:55PM +0800, Chen Gang wrote:
>> Some of architectures have already defined 'die' as macro, so can not use
>> this common name as declaration in other modules, or will cause compiling
>
That
> said you'll probably not run a kernel that was built with COMPILE_TEST on
> your real hardware since it contains so many drivers that are completely
> useless on your hardware. The idea of COMPILE_TEST is to have as much compile
> test exposure a
;cc_ops->die(req->rq_cli_ctx, 0);
^
make[5]: *** [drivers/staging/lustre/lustre/ptlrpc/sec.o] Error 1
make[4]: *** [drivers/staging/lustre/lustre/ptlrpc] Error 2
make[3]: *** [drivers/staging/lustre/lustre] Error 2
make[2]: *** [drivers/staging/lustr
On 07/13/2014 11:14 AM, Chen Gang wrote:
[...]
> And also find a compiler issue, I will try to fix it, but shall not notify
> kernel mailing list, again. The related issue is below (it seems a kernel
> issue, but in fact, it is a compiler's issue):
>
> CC [M] drivers/s
MXS_LRADC need HAS_IOMEM, so let it depend on HAS_IOMEM
The related error (with allmodconfig under score):
MODPOST 1365 modules
ERROR: "devm_ioremap_resource" [drivers/staging/iio/adc/mxs-lradc.ko]
undefined!
Signed-off-by: Chen Gang
---
drivers/staging/iio/adc/Kconfig | 2
onable as not all architectures support iomem.
>
OK, thanks. And I shall split them into several patches, although we can
understand that score may not need them.
Thanks.
--
Chen Gang
Open share and attitude like air water and life which God blessed
___
tx, 0);
^
make[5]: *** [drivers/staging/lustre/lustre/ptlrpc/sec.o] Error 1
make[4]: *** [drivers/staging/lustre/lustre/ptlrpc] Error 2
make[3]: *** [drivers/staging/lustre/lustre] Error 2
make[2]: *** [drivers/staging/lustre] Error 2
make[1]: *** [drivers/staging
" [drivers/input/serio/olpc_apsp.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/input/serio/arc_ps2.ko] undefined!
Signed-off-by: Chen Gang
---
drivers/input/serio/Kconfig | 3 ++-
drivers/pwm/Kconfig | 2 +-
drivers/staging/iio/adc/Kconfig | 2 +-
drivers/watchdog
treated as errors
make[4]: *** [drivers/staging/android/ion/ion_cma_heap.o] Error 1
make[3]: *** [drivers/staging/android/ion] Error 2
make[2]: *** [drivers/staging/android] Error 2
make[1]: *** [drivers/staging] Error 2
make: *** [drivers] Error 2
Signed-off-by: Chen Gang
---
drivers/staging/and
This reverts commit b73db54750482cf3910046c82a84ce8c1684dfbe.
This re-factor did not notice about 'buf' and 'remain' which have
effect in whole dgrp_receive() wide, so need revert.
Signed-off-by: Chen Gang
---
drivers/staging/dgrp/dgrp_net_ops.c | 330 +--
On 02/03/2014 06:03 PM, Chen Gang wrote:
> On 02/03/2014 04:58 PM, Dan Carpenter wrote:
>> On Sat, Feb 01, 2014 at 09:57:39PM +0800, Chen Gang wrote:
>>> It seems, our kernel still stick to treate 'pack' region have effect
>>> with both 'align' and
On 02/03/2014 06:22 PM, James Hogan wrote:
> On 03/02/14 10:05, David Laight wrote:
>> From: Dan Carpenter
>>> On Sat, Feb 01, 2014 at 09:57:39PM +0800, Chen Gang wrote:
>>>> It seems, our kernel still stick to treate 'pack' region have effect
>>>&
On 02/03/2014 06:05 PM, David Laight wrote:
> From: Dan Carpenter
>> On Sat, Feb 01, 2014 at 09:57:39PM +0800, Chen Gang wrote:
>>> It seems, our kernel still stick to treate 'pack' region have effect
>>> with both 'align' and 'sizeof'
On 02/03/2014 04:58 PM, Dan Carpenter wrote:
> On Sat, Feb 01, 2014 at 09:57:39PM +0800, Chen Gang wrote:
>> It seems, our kernel still stick to treate 'pack' region have effect
>> with both 'align' and 'sizeof'.
>>
>
> It's not about
On 01/25/2014 07:55 PM, Chen Gang wrote:
> On 01/21/2014 06:36 PM, James Hogan wrote:
>> Hi Dan,
>>
>> On 20/01/14 21:13, Dan Carpenter wrote:
>>> I made a quick and dirty sparse patch to check for this. I don't think
>>> I will bother trying to se
Oh, sorry, I forgot to ask: "should I need send the revert path for it"?
Thanks.
On 02/01/2014 02:11 PM, Chen Gang wrote:
> After check, for me, reverting is OK enough. I did not find issues of
> original implementation (related things look reasonable to me).
>
> Original
orm the test after
re-factor, so welcome any other members to help re-factor and perform a
test.
Welcome any additional suggestions, discussions and completions.
Thanks.
On 01/25/2014 06:45 PM, Chen Gang wrote:
> On 01/23/2014 11:16 PM, Dan Carpenter wrote:
>> On Tue, Dec 10, 2013 at 01:05:46PM +
Hello Maintainers:
Please help check this patch when you have time, thanks.
On 01/18/2014 05:04 PM, Chen Gang wrote:
> Need add "linux/io.h" to pass compiling under metag architecture with
> allmodconfig (which use the default 'virt_to_phys'), the related error:
>
k alignment explicitly in kernel source code, it need be
fixed within kernel: "apply related patches (pack each struct or
union), but the related patch comments need be improved".
Is what I guess correct?
Thanks.
--
Chen Gang
Open, share and attit
I plan to finish it within next month (2014-02-28).
BTW: my current related time resources are:
2014-01: make driver, user mode library, and Java demo under android.
In Chinese Festival, I have time resource to upstream kernel and qemu.
2014-02: migrate diver, library, and develop an obj-C
On 01/18/2014 10:24 PM, Dan Carpenter wrote:
> On Sat, Jan 18, 2014 at 06:26:10PM +0800, Chen Gang wrote:
>> On 01/18/2014 06:05 PM, Dan Carpenter wrote:
>>> On Sat, Jan 18, 2014 at 05:50:34PM +0800, Chen Gang wrote:
>>>> Unfortunately, not all compilers assume
On 01/18/2014 06:05 PM, Dan Carpenter wrote:
> On Sat, Jan 18, 2014 at 05:50:34PM +0800, Chen Gang wrote:
>> Unfortunately, not all compilers assumes the structures within a pack
>> region also need be packed (e.g. metag), so need add a pack explicitly
>> to satisfy all
ot;, so
still use it instead of '__packed'.
Signed-off-by: Chen Gang
---
drivers/staging/lustre/lustre/include/lustre/lustre_user.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
b/drivers/stagin
on_dummy_init':
drivers/staging/android/ion/ion_dummy_driver.c:81: error: implicit
declaration of function 'virt_to_phys'
Signed-off-by: Chen Gang
---
drivers/staging/android/ion/ion_dummy_driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/android/ion/ion_d
th
> the fix. It's not the end of the world if we have to do that.
>
Yeah, please help to try, when you have free time (in fact, I often make
some common sense mistakes... so just feel free). :-)
Thanks.
--
Chen Gang
Open, share, and at
On 12/10/2013 05:10 PM, Dan Carpenter wrote:
> On Tue, Dec 10, 2013 at 01:07:58PM +0800, Chen Gang wrote:
>> Hello Maintainers:
>>
>> The compiler help me find a warning about it, please help check thanks.
>>
>> The related git commit: "b73db54 Staging: dgrp:
On 12/10/2013 01:17 PM, Greg KH wrote:
> On Tue, Dec 10, 2013 at 01:07:58PM +0800, Chen Gang wrote:
>> Hello Maintainers:
>>
>> The compiler help me find a warning about it, please help check thanks.
>>
>> The related git commit: "b73db54 Staging: dgrp: Refa
_net_ops.o
drivers/staging/dgrp/dgrp_net_ops.c: In function 'handle_data_in_packet':
drivers/staging/dgrp/dgrp_net_ops.c:2392: warning: 'buf' is used
uninitialized in this function
Thanks.
--
Chen Gang
Open, share, and attitude like air, wa
Oh, another member has already fixed it (found earlier than me), and
integrated it into next-20131203 tree, so this patch is obsoleted.
The related git commit is "8aced95 staging: ft1000: fix use of
potentially uninitialized variable"
Thanks.
On 11/27/2013 05:27 PM, Chen Gang wrote:
On 11/27/2013 06:43 PM, Dan Carpenter wrote:
> On Wed, Nov 27, 2013 at 12:24:22PM +0800, Chen Gang wrote:
>> On 11/27/2013 12:03 PM, Greg KH wrote:
>>> On Wed, Nov 27, 2013 at 11:48:08AM +0800, Chen Gang wrote:
>>>> dev_*() assumes 'go' is already initial
On 11/27/2013 05:18 PM, Josh Triplett wrote:
> On Wed, Nov 27, 2013 at 11:01:18AM +0800, Chen Gang wrote:
>> If "!bool_case", it returns unexpected value instead of STATUS_SUCCESS,
>> so need fix it, the related warning (with allmodconfig under hexagon):
>>
>&g
On 11/27/2013 12:03 PM, Greg KH wrote:
> On Wed, Nov 27, 2013 at 11:48:08AM +0800, Chen Gang wrote:
>> dev_*() assumes 'go' is already initialized, so need use pr_*() instead
>> of before 'go' initialized. Related warning (with allmodconfig under
>> he
007_usb_probe':
drivers/staging/media/go7007/go7007-usb.c:1060:2: warning: 'go' may be used
uninitialized in this function [-Wuninitialized]
Also remove useless code after 'return' statement.
Signed-off-by: Chen Gang
---
drivers/staging/media/go7007/go7007-usb.c | 1
On 11/27/2013 11:21 AM, Joe Perches wrote:
> On Wed, 2013-11-27 at 11:17 +0800, Chen Gang wrote:
>> dev_*() assumes 'go' is already initialized, so need use pr_*() instead
>> of before 'go' initialized.
> []
>> diff --git a/drivers/staging/media/go7
include/uapi/linux/swab.h:53:9: warning: 'msgsz' may be used uninitialized in
this function [-Wuninitialized]
drivers/staging/ft1000/ft1000-usb/ft1000_debug.c:533:17: note: 'msgsz' was
declared here
Signed-off-by: Chen Gang
---
drivers/staging/ft1000/ft1000-usb/ft10
007_usb_probe':
drivers/staging/media/go7007/go7007-usb.c:1060:2: warning: 'go' may be used
uninitialized in this function [-Wuninitialized]
Also remove useless code after 'return' statement.
Signed-off-by: Chen Gang
---
drivers/staging/media/go7007/go7007-usb.c | 1
st_code_segment':
drivers/staging/ft1000/ft1000-usb/ft1000_download.c:581:6: warning: 'status'
may be used uninitialized in this function [-Wuninitialized]
Signed-off-by: Chen Gang
---
.../staging/ft1000/ft1000-usb/ft1000_download.c|2 +-
1 files changed, 1 insertions(+)
On 11/02/2013 05:26 PM, Samuel Thibault wrote:
> Chen Gang, le Thu 31 Oct 2013 15:27:37 +0800, a �crit :
>> > If SERIAL_PORT_DFNS isn't present by platform, it need be defined to
>> > "nothing", like the 8250 serial driver does it.
>> >
>> > A
After add this patch, it can let serialio.c generated ".o" file.
If need additional trying, please let me know, thanks.
On 10/31/2013 03:27 PM, Chen Gang wrote:
> If SERIAL_PORT_DFNS isn't present by platform, it need be defined to
> "nothing", like the 8250
If architectures don't support SERIAL_PORT_DFNS, they need not define
it to "nothing", the related drivers need do it by themselves (e.g.
8250 serial driver).
Signed-off-by: Chen Gang
---
arch/frv/include/asm/serial.h|2 --
arch/parisc/include/asm/serial.h |2 --
2 f
nt is not
constant
drivers/staging/speakup/serialio.c:12:2: error: (near initialization for
'rs_table[2].baud_base')
drivers/staging/speakup/serialio.c:12:2: error: initializer element is not
constant
drivers/staging/speakup/serialio.c:12:2: error: (near initialization for
'rs_t
On 10/31/2013 02:46 PM, Vineet Gupta wrote:
> On 10/31/2013 06:57 AM, Chen Gang wrote:
>> On 10/26/2013 09:18 PM, Chen Gang wrote:
>>> On 10/25/2013 01:29 PM, Greg KH wrote:
>>>> No, just use the platform-specific SERIAL_PORT_DNFS, instead of having a
>>>>
ng/speakup/serialio.c:12:2: error: (near initialization for
'rs_table[3].baud_base')
Signed-off-by: Chen Gang
---
arch/arc/include/asm/serial.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arc/include/asm/serial.h b/arch/arc/include/asm/serial.h
index
On 10/26/2013 09:18 PM, Chen Gang wrote:
> On 10/25/2013 01:29 PM, Greg KH wrote:
>> No, just use the platform-specific SERIAL_PORT_DNFS, instead of having a
>> copy of it here in this driver, which is just wrong. So please remove
>> this, and just rely on the system version
On 10/25/2013 01:29 PM, Greg KH wrote:
> On Wed, Oct 23, 2013 at 11:20:12AM +0800, Chen Gang wrote:
>> For some architectures (e.g. arc), BASE_BAUD cannot be constant number.
>> So have to delay initializing 'old_serial_port.baud_base', or can not
>> pass com
If command line use EXTRA_CFLAGS (e.g. "EXTRA_CFLAGS=-mmedium-calls"
for arc architecture, with allmodconfig), it can not pass compiling,
the related error:
drivers/staging/rtl8188eu/core/rtw_ap.c:22:27: fatal error: osdep_service.h:
No such file or directory
Signed-off-by: Chen G
On 10/24/2013 12:06 AM, Larry Finger wrote:
> On 10/23/2013 03:52 AM, Chen Gang wrote:
>> If command line use EXTRA_CFLAGS (e.g. "EXTRA_CFLAGS=-mmedium-calls"
>> for arc architecture, with allmodconfig), it can not pass compiling,
>> the related error:
>>
If command line use EXTRA_CFLAGS (e.g. "EXTRA_CFLAGS=-mmedium-calls"
for arc architecture, with allmodconfig), it can not pass compiling,
the related error:
drivers/staging/rtl8188eu/core/rtw_ap.c:22:27: fatal error: osdep_service.h:
No such file or directory
Signed-off-by:
drivers/staging/speakup/serialio.c:12:2: error: (near initialization for
> 'rs_table[2].baud_base')
> drivers/staging/speakup/serialio.c:12:2: error: initializer element is not
> constant
> drivers/staging/speakup/serialio.c:12:2: error: (near initialization for
drivers/staging/speakup/serialio.c:12:2: error: initializer element is not
constant
drivers/staging/speakup/serialio.c:12:2: error: (near initialization for
'rs_table[3].baud_base')
Signed-off-by: Chen Gang
---
drivers/staging/speakup/serialio.c |7 +--
drivers/staging/spe
the driver main
header file.
So move DG_NAME and DG_PART to "dgap_driver.h", it not only can make
code clearer, but also can avoid compiling failure when EXTRA_CFLAGS
appended to make command line (e.g. "EXTRA_CFLAGS=-W").
Signed-off-by: Chen Gang
---
drivers/staging/dgap/Ma
On 09/21/2013 07:22 PM, Dan Carpenter wrote:
> On Sat, Sep 21, 2013 at 07:12:36PM +0800, Chen Gang wrote:
>> Need use 'ccflags-y' instead of EXTRA_CFLAGS, or compiling issue will
>> be occurred with "EXTRA_CFLAGS=-W".
>>
>
> Just add it to drivers/st
Need use 'ccflags-y' instead of EXTRA_CFLAGS, or compiling issue will
be occurred with "EXTRA_CFLAGS=-W".
Also can reference scripts/checkpatch.pl (1755..1766) to know about it.
Signed-off-by: Chen Gang
---
drivers/staging/dgap/Makefile |2 +-
1 files changed, 1 insert
rs/staging/android/binder.c:626: undefined reference to `zap_page_range'
drivers/built-in.o: In function `binder_mmap':
drivers/staging/android/binder.c:2744: undefined reference to `get_vm_area'
Signed-off-by: Chen Gang
---
drivers/staging/android/Kconfig |1 +
1 files ch
-declaration]
drivers/staging/dgnc/dgnc_cls.c:1407:3: error: implicit declaration of
function ‘iounmap’ [-Werror=implicit-function-declaration]
Signed-off-by: Chen Gang
---
drivers/staging/dgnc/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/dgnc
98 matches
Mail list logo