Re: [PATCH] sound: soc: soc-pcm: Remove useless varialbe 'i'
On 1/3/15 17:59, Takashi Iwai wrote: > At Sat, 03 Jan 2015 17:45:57 +0800, > Chen Gang wrote: >> >> 'i' is useless in soc_pcm_set_msb(), so remove it, the related warning >> (with allmodconfig under s390): >> >> CC [M] sound/soc/soc-pcm.o >> sound/soc/soc-pcm.c: In function 'soc_pcm_set_msb': >> sound/soc/soc-pcm.c:307:11: warning: unused variable 'i' >> [-Wunused-variable] >> int ret, i; >> ^ > > Thanks, but this was already fixed. > OK, thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- 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] s390: boot: compressed: misc: Express the return value of _sclp_print_early()
On 1/5/15 17:21, Heiko Carstens wrote: > On Sat, Jan 03, 2015 at 05:29:07PM +0800, Chen Gang wrote: >> _sclp_print_early() has return value: at present, return 0 for OK, 1 for >> failure. It returns '%r2', so use 'long' as return value (upper caller >> can check '%r2' directly). The related warning: >> >> CC arch/s390/boot/compressed/misc.o >> arch/s390/boot/compressed/misc.c:66:8: warning: type defaults to 'int' in >> declaration of '_sclp_print_early' [-Wimplicit-int] >>extern _sclp_print_early(const char *); >> ^ >> >> At present, _sclp_print_early() is only used by puts(), so can still >> remain its declaration in 'misc.c' file. >> >> Signed-off-by: Chen Gang >> --- >> arch/s390/boot/compressed/misc.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/s390/boot/compressed/misc.c >> b/arch/s390/boot/compressed/misc.c >> index 57cbaff..09003b2 100644 >> --- a/arch/s390/boot/compressed/misc.c >> +++ b/arch/s390/boot/compressed/misc.c >> @@ -63,7 +63,7 @@ static unsigned long free_mem_end_ptr; >> #include "../../../../lib/decompress_unxz.c" >> #endif >> >> -extern _sclp_print_early(const char *); >> +extern long _sclp_print_early(const char *); > > Thanks, applied. However I moved the declaration to the sclp header file. > OK, Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- 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] s390: include: timex: Use macro CLOCK_STORE_SIZE instead of hard code number
On 01/05/2015 04:59 PM, Martin Schwidefsky wrote:
> On Sat, 03 Jan 2015 11:44:04 +0800
> Chen Gang wrote:
>
>>
>> Thank you for your work.
>>
>> In honest, originally, I was not sure whether it would cause bug (do not
>> know gcc would generic incorrect code for it). :-)
>
> Even if the code happened to be correct it does not matter. The intention
> of the sizeof() has been to get to the correct 16, not 8. The fix is
> fine as it is.
>
Excuse me, my English is not quite well, I am not quite sure about what
you said (might misunderstand what you said), so I provide the related
information below for confirmation, please check, thanks.
sizeof(clk) is for a pointer, not for an array (for C language, it
treats array parameter as a pointer), the related demo is below:
[root@localhost test]# cat ./test.c
#include
static inline void get_tod_clock_ext(char clk[16])
{
typedef struct { char _[sizeof(clk)]; } addrtype;
printf("\nsize: %ld\n", sizeof(addrtype));
}
int main()
{
char clk[16];
get_tod_clock_ext(clk);
return 0;
}
[root@localhost test]# cc -Wall -O2 -o test test.c
[root@localhost test]# ./test
size: 8
[root@localhost test]# cc -v
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)
[root@localhost test]#
Thanks.
--
Open, share, and attitude like air, water, and life which God blessed.
--
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] s390: include: timex: Use macro CLOCK_STORE_SIZE instead of hard code number
On 1/7/15 23:36, Martin Schwidefsky wrote: > On Wed, 07 Jan 2015 22:45:11 +0800 > Chen Gang S wrote: > >> On 01/05/2015 04:59 PM, Martin Schwidefsky wrote: >>> On Sat, 03 Jan 2015 11:44:04 +0800 >>> Chen Gang wrote: >>> >>>> >>>> Thank you for your work. >>>> >>>> In honest, originally, I was not sure whether it would cause bug (do not >>>> know gcc would generic incorrect code for it). :-) >>> >>> Even if the code happened to be correct it does not matter. The intention >>> of the sizeof() has been to get to the correct 16, not 8. The fix is >>> fine as it is. >>> >> >> Excuse me, my English is not quite well, I am not quite sure about what >> you said (might misunderstand what you said), so I provide the related >> information below for confirmation, please check, thanks. >> >> sizeof(clk) is for a pointer, not for an array (for C language, it >> treats array parameter as a pointer), the related demo is below: > > And your patch fixes this problem. My comment was in regard to the > impact of the original bug. As the typeof construct is used to > prevent the compiler from over-optimizing, the code can come out > correct even if the bug is present. > OK, thank you for your reply. In honest, I still not quite understand your meaning, I guess it is only because of my poor English, and it doesn't matter for others members, so not need additional reply for it (but welcome reply). For details (please check, if still interest): > And your patch fixes this problem. My comment was in regard to the > impact of the original bug. I can understand the 2 contents above. > As the typeof construct is used to > prevent the compiler from over-optimizing, I can understand, yeah, typeof() is useful for declaring an array. >the code can come out > correct even if the bug is present. > Sorry, I can not understand: I know every words, and it seems I can understand the whole sentence, but for me, it seems have a conflict meaning with the original sentences. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- 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] drm: Kconfig: Let all DRM_GEM_CMA_HELPER related macros depend on HAVE_DMA_ATTRS
> On 2/3/15 05:26, Chen Gang S wrote: > > [...] > >> >> - Xtensa gcc5 cross compiler has issues: >> >>it causes more than 10 broken areas with allmodconfig (but no issues >>with defconfig). I guess, in fact, it is only 1 real issue (which can >>cause all breaks), and I shall try to fix it within this month. >> > > I finish analysing for it, it is really only one issue for gcc5, and I > guess, this issue is also not only for xtensa. I send related fix patch > to gcc patch mailing list, hope it can pass checking. > > The cause is "the variables are not initialized before using them", the > bug information is "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65117";. > > After fix this issue, it can build xtensa Linux kernel with allmodconfig > successfully. > Oh, sorry, my fix is incorrect, but gcc related members will fix it. I guess, it will be fixed soon. But because of this issue, I can send another patch for gcc (it can not fix this issue, but it is related with this issue) :-). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- 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] net: bluetooth: hci_sock: Use 'const u32 *' instead of 'void *' for 2nd parameter of hci_test_bit()
hci_test_bit() does not modify 2nd parameter, so it is better to let it
be constant, or may cause build warning. The related warning (with
allmodconfig under xtensa):
net/bluetooth/hci_sock.c: In function 'hci_sock_sendmsg':
net/bluetooth/hci_sock.c:955:8: warning: passing argument 2 of 'hci_test_bit'
discards 'const' qualifier from pointer target type
[-Wdiscarded-array-qualifiers]
&hci_sec_filter.ocf_mask[ogf])) &&
^
net/bluetooth/hci_sock.c:49:19: note: expected 'void *' but argument is of
type 'const __u32 (*)[4] {aka const unsigned int (*)[4]}'
static inline int hci_test_bit(int nr, void *addr)
^
hci_test_bit() always treats 2nd parameter is u32, and all callers also
know about it, so 2nd parameter of hci_test_bit() need use 'const u32 *'
instead of 'void *'.
C language treats the array function parameter as a pointer, so the
caller need not use '&' for the 2 demotion array, or it reports warning:
'const unsigned int (*)[4]' is different with 'const unsigned int *'.
Signed-off-by: Chen Gang
---
net/bluetooth/hci_sock.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 1d65c5b..04124ec 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -46,9 +46,9 @@ struct hci_pinfo {
unsigned shortchannel;
};
-static inline int hci_test_bit(int nr, void *addr)
+static inline int hci_test_bit(int nr, const u32 *addr)
{
- return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
+ return *(addr + (nr >> 5)) & ((u32) 1 << (nr & 31));
}
/* Security filter */
@@ -107,7 +107,7 @@ static bool is_filtered_packet(struct sock *sk, struct
sk_buff *skb)
flt_event = (*(__u8 *)skb->data & HCI_FLT_EVENT_BITS);
- if (!hci_test_bit(flt_event, &flt->event_mask))
+ if (!hci_test_bit(flt_event, (u32 *)&flt->event_mask))
return true;
/* Check filter only when opcode is set */
@@ -952,7 +952,7 @@ static int hci_sock_sendmsg(struct kiocb *iocb, struct
socket *sock,
if (((ogf > HCI_SFLT_MAX_OGF) ||
!hci_test_bit(ocf & HCI_FLT_OCF_BITS,
- &hci_sec_filter.ocf_mask[ogf])) &&
+ hci_sec_filter.ocf_mask[ogf])) &&
!capable(CAP_NET_RAW)) {
err = -EPERM;
goto drop;
--
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/
Re: [PATCH v3] net: bluetooth: hci_sock: Use 'const u32 *' instead of 'void *' for 2nd parameter of hci_test_bit()
On 2/8/15 03:52, Joe Perches wrote:
> On Sat, 2015-02-07 at 21:24 +0800, Chen Gang S wrote:
>> hci_test_bit() does not modify 2nd parameter, so it is better to let it
>> be constant, or may cause build warning. The related warning (with
>> allmodconfig under xtensa):
>>
>> net/bluetooth/hci_sock.c: In function 'hci_sock_sendmsg':
>> net/bluetooth/hci_sock.c:955:8: warning: passing argument 2 of
>> 'hci_test_bit' discards 'const' qualifier from pointer target type
>> [-Wdiscarded-array-qualifiers]
>> &hci_sec_filter.ocf_mask[ogf])) &&
>> ^
>> net/bluetooth/hci_sock.c:49:19: note: expected 'void *' but argument is of
>> type 'const __u32 (*)[4] {aka const unsigned int (*)[4]}'
>>static inline int hci_test_bit(int nr, void *addr)
>> ^
>>
>> hci_test_bit() always treats 2nd parameter is u32, and all callers also
>> know about it, so 2nd parameter of hci_test_bit() need use 'const u32 *'
>> instead of 'void *'.
>>
>> C language treats the array function parameter as a pointer, so the
>> caller need not use '&' for the 2 demotion array, or it reports warning:
>> 'const unsigned int (*)[4]' is different with 'const unsigned int *'.
>
> I still think you are possibly papering over potential bugs
> on big-endian 64 bit systems.
>
> unsigned long vs u32.
>
> How are the bits actually set?
>
>From current usage of event_mask, "(u32 *) f->event_mask" is only for
event_mask data storage, not for calculation (always as "u32 *" for
calculation).
[root@localhost linux-next]# grep -rn "\" include/net/bluetooth
net/bluetooth
include/net/bluetooth/hci_sock.h:51: unsigned long event_mask[2];
include/net/bluetooth/hci_sock.h:57: __u32 event_mask[2];
net/bluetooth/hci_sock.c:59: __u32 event_mask[2];
net/bluetooth/hci_sock.c:110: if (!hci_test_bit(flt_event, (u32
*)&flt->event_mask))
net/bluetooth/hci_sock.c:1041:uf.event_mask[0] =
*((u32 *) f->event_mask + 0);
net/bluetooth/hci_sock.c:1042:uf.event_mask[1] =
*((u32 *) f->event_mask + 1);
net/bluetooth/hci_sock.c:1053:uf.event_mask[0] &=
*((u32 *) hci_sec_filter.event_mask + 0);
net/bluetooth/hci_sock.c:1054:uf.event_mask[1] &=
*((u32 *) hci_sec_filter.event_mask + 1);
net/bluetooth/hci_sock.c:1062:*((u32 *) f->event_mask
+ 0) = uf.event_mask[0];
net/bluetooth/hci_sock.c:1063:*((u32 *) f->event_mask
+ 1) = uf.event_mask[1];
net/bluetooth/hci_sock.c:1124:uf.event_mask[0] =
*((u32 *) f->event_mask + 0);
net/bluetooth/hci_sock.c:1125:uf.event_mask[1] =
*((u32 *) f->event_mask + 1);
Calculation is machine endian dependency, but event_mask is always as
"u32 *" for calculation, so there is no any type cast for calculation,
it is OK.
Storage is independent from machine endian, but it depends on machine
bits. In our case, 'unsigned long' array has enough space to accept u32
array, so there is no any data overwritten, it is OK.
By the way, I intended to remain event_mask as 'unsigned long' type,
because I am not quite sure whether it is also used by another modules
in kernel (or any other systems). May we change it to u32?
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
--
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] net: bluetooth: hci_sock: Use 'const u32 *' instead of 'void *' for 2nd parameter of hci_test_bit()
On 2/8/15 08:00, Chen Gang S wrote:
> On 2/8/15 03:52, Joe Perches wrote:
>> On Sat, 2015-02-07 at 21:24 +0800, Chen Gang S wrote:
>>> hci_test_bit() does not modify 2nd parameter, so it is better to let it
>>> be constant, or may cause build warning. The related warning (with
>>> allmodconfig under xtensa):
>>>
>>> net/bluetooth/hci_sock.c: In function 'hci_sock_sendmsg':
>>> net/bluetooth/hci_sock.c:955:8: warning: passing argument 2 of
>>> 'hci_test_bit' discards 'const' qualifier from pointer target type
>>> [-Wdiscarded-array-qualifiers]
>>> &hci_sec_filter.ocf_mask[ogf])) &&
>>> ^
>>> net/bluetooth/hci_sock.c:49:19: note: expected 'void *' but argument is
>>> of type 'const __u32 (*)[4] {aka const unsigned int (*)[4]}'
>>>static inline int hci_test_bit(int nr, void *addr)
>>> ^
>>>
>>> hci_test_bit() always treats 2nd parameter is u32, and all callers also
>>> know about it, so 2nd parameter of hci_test_bit() need use 'const u32 *'
>>> instead of 'void *'.
>>>
>>> C language treats the array function parameter as a pointer, so the
>>> caller need not use '&' for the 2 demotion array, or it reports warning:
>>> 'const unsigned int (*)[4]' is different with 'const unsigned int *'.
>>
>> I still think you are possibly papering over potential bugs
>> on big-endian 64 bit systems.
>>
>> unsigned long vs u32.
>>
>> How are the bits actually set?
>>
>
>>From current usage of event_mask, "(u32 *) f->event_mask" is only for
> event_mask data storage, not for calculation (always as "u32 *" for
> calculation).
>
> [root@localhost linux-next]# grep -rn "\"
> include/net/bluetooth net/bluetooth
> include/net/bluetooth/hci_sock.h:51:unsigned long event_mask[2];
e.g. use "unsigned char event_mask[2 * sizeof(unsigned long)]" instead
of "unsigned long event_mask[2]".
There is still no any issue within "hci_sock.c" (although I am not sure
whether this modification may cause issues in another modules outside
kernel).
Thanks.
> include/net/bluetooth/hci_sock.h:57:__u32 event_mask[2];
> net/bluetooth/hci_sock.c:59:__u32 event_mask[2];
> net/bluetooth/hci_sock.c:110: if (!hci_test_bit(flt_event, (u32
> *)&flt->event_mask))
> net/bluetooth/hci_sock.c:1041: uf.event_mask[0] =
> *((u32 *) f->event_mask + 0);
> net/bluetooth/hci_sock.c:1042: uf.event_mask[1] =
> *((u32 *) f->event_mask + 1);
> net/bluetooth/hci_sock.c:1053: uf.event_mask[0] &=
> *((u32 *) hci_sec_filter.event_mask + 0);
> net/bluetooth/hci_sock.c:1054: uf.event_mask[1] &=
> *((u32 *) hci_sec_filter.event_mask + 1);
> net/bluetooth/hci_sock.c:1062: *((u32 *) f->event_mask
> + 0) = uf.event_mask[0];
> net/bluetooth/hci_sock.c:1063: *((u32 *) f->event_mask
> + 1) = uf.event_mask[1];
> net/bluetooth/hci_sock.c:1124: uf.event_mask[0] =
> *((u32 *) f->event_mask + 0);
> net/bluetooth/hci_sock.c:1125: uf.event_mask[1] =
> *((u32 *) f->event_mask + 1);
>
> Calculation is machine endian dependency, but event_mask is always as
> "u32 *" for calculation, so there is no any type cast for calculation,
> it is OK.
>
> Storage is independent from machine endian, but it depends on machine
> bits. In our case, 'unsigned long' array has enough space to accept u32
> array, so there is no any data overwritten, it is OK.
>
>
> By the way, I intended to remain event_mask as 'unsigned long' type,
> because I am not quite sure whether it is also used by another modules
> in kernel (or any other systems). May we change it to u32?
>
> Thanks.
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
--
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] net: bluetooth: hci_sock: Use 'const u32 *' instead of 'void *' for 2nd parameter of hci_test_bit()
On 2/9/15 04:17, Marcel Holtmann wrote:
> Hi Chen,
>
> hci_test_bit() does not modify 2nd parameter, so it is better to let it
> be constant, or may cause build warning. The related warning (with
> allmodconfig under xtensa):
>
> net/bluetooth/hci_sock.c: In function 'hci_sock_sendmsg':
> net/bluetooth/hci_sock.c:955:8: warning: passing argument 2 of
> 'hci_test_bit' discards 'const' qualifier from pointer target type
> [-Wdiscarded-array-qualifiers]
> &hci_sec_filter.ocf_mask[ogf])) &&
> ^
> net/bluetooth/hci_sock.c:49:19: note: expected 'void *' but argument is
> of type 'const __u32 (*)[4] {aka const unsigned int (*)[4]}'
> static inline int hci_test_bit(int nr, void *addr)
> ^
>
> hci_test_bit() always treats 2nd parameter is u32, and all callers also
> know about it, so 2nd parameter of hci_test_bit() need use 'const u32 *'
> instead of 'void *'.
>
> C language treats the array function parameter as a pointer, so the
> caller need not use '&' for the 2 demotion array, or it reports warning:
> 'const unsigned int (*)[4]' is different with 'const unsigned int *'.
I still think you are possibly papering over potential bugs
on big-endian 64 bit systems.
unsigned long vs u32.
How are the bits actually set?
>>>
From current usage of event_mask, "(u32 *) f->event_mask" is only for
>>> event_mask data storage, not for calculation (always as "u32 *" for
>>> calculation).
>>>
>>> [root@localhost linux-next]# grep -rn "\"
>>> include/net/bluetooth net/bluetooth
>>> include/net/bluetooth/hci_sock.h:51: unsigned long event_mask[2];
>>
>> e.g. use "unsigned char event_mask[2 * sizeof(unsigned long)]" instead
>> of "unsigned long event_mask[2]".
>>
>> There is still no any issue within "hci_sock.c" (although I am not sure
>> whether this modification may cause issues in another modules outside
>> kernel).
>
> what about writing a test case for userspace that ensures that things are
> working correctly. As I said before, we left it this way since it is part of
> the API.
>
If it is really the API which can be used outside kernel, what you said
sounds reasonable to me. But I guess, except the related orgnizations/
company/members, most of kernel members can not give a suitable test:
- It is an API, but we only know kernel part implementation, and we
also know that the kernel part implementation intends to use
"unsigned long event_mask[2]" and "u32 *" type cast.
- We don't know the other part implementation (we event don't know
whether it is open source). And also it is out of most of kernel
members' current border (e.g. me).
- If the other part implementation match what kernel part has done, it
is OK, else it should cause issue.
So at present, in kernel part, we can only say the original authors
intended to do like this. And only within kernel part, it can not cause
issue. I guess, original authors originally knew what we talk about.
This patch is for fixing building warnings without any negative effect.
And most of us are not the suitable members to continue analyzing. So
at present, for me, we can accept this patch.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
--
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] net: bluetooth: hci_sock: Use 'const u32 *' instead of 'void *' for 2nd parameter of hci_test_bit()
On 2/10/15 00:57, David Laight wrote: > From: Marcel Holtmann >> Hi David, >> So at present, in kernel part, we can only say the original authors intended to do like this. And only within kernel part, it can not cause issue. I guess, original authors originally knew what we talk about. >>> >>> I've just searched for hci_u*filter it is all horrid. >>> Look at the code for get/set_sockopt of HCI_FILTER. >>> Someone seems to have done a complete 'bodge job' of fixing the user >>> interface >>> for apps (32bit and 64bit) on 64bit kernels. >> >> we are actually fully aware of that. Just keep in mind that this code is >> from 2.4.6 kernel and with >> that most likely 14 years old by now. Unfortunately it ended up as userspace >> API. > > AFAICT the userspace API is always __u32[2] the long[2] is never exposed > to userspace (certainly not through the socket option code). > > Quite why all the casts were added - instead of changing the type > is probably hidden in the annals of the source repo. > Some serious archaeology might be in order. > For me, I guess what you said above sounds reasonable. But excuse me, I am not familiar with the related modules outside Linux kernel (at present, it is out of my border). I guess, I am not the suitable member to make the related fix patch for this issue. Welcome any other members to send the fix patch for it. And for me, if "hci_u*filter" is related with the modules outside kernel (I guess, it should be), I recommend to put it to the related "uapi" header. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- 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] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()
On 2/5/15 05:09, Marcel Holtmann wrote:
> Hi Sergei,
>
-static inline int hci_test_bit(int nr, void *addr)
+static inline int hci_test_bit(int nr, const void *addr)
{
return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
}
>>
>>> Is there a 'standard' function lurking that will do the above.
>>> On x86 the cpus 'bit test' instruction will handle bit numbers
>>> greater than the word size - so it can be a single instruction.
>>
>> Of course, there's test_bit().
>
> we did leave hci_test_bit in the code since there are some userspace facing
> API that we can not change. Remember that the origin of this code is from
> 2.4.6 kernel.
>
> So we can only change this if you can ensure not to break the userspace API.
> So might want to write unit tests to ensure working HCI filter before even
> considering touching this.
>
For me, we have to remain hci_test_bit(), it is for "__u32 *" (which we
can not change). The common test_bit() is for "unsigned long *", in this
case, I guess it may cause issue under 64-bit environments.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
--
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] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()
On 2/5/15 18:14, David Laight wrote:
> From: Chen Gang S [mailto:gang.c...@sunrus.com.cn]
>> On 2/5/15 05:09, Marcel Holtmann wrote:
>>> Hi Sergei,
>>>
>>>>>> -static inline int hci_test_bit(int nr, void *addr)
>>>>>> +static inline int hci_test_bit(int nr, const void *addr)
>>>>>> {
>>>>>> return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
>>>>>> }
>>>>
>>>>> Is there a 'standard' function lurking that will do the above.
>>>>> On x86 the cpus 'bit test' instruction will handle bit numbers
>>>>> greater than the word size - so it can be a single instruction.
>>>>
>>>> Of course, there's test_bit().
>>>
>>> we did leave hci_test_bit in the code since there are some userspace facing
>>> API that we can not change. Remember that the origin of this code is
>>> from 2.4.6 kernel.
>>>
>>> So we can only change this if you can ensure not to break the userspace API.
>>> So might want to write unit tests to ensure working HCI filter before even
>>> considering touching this.
>>>
>>
>> For me, we have to remain hci_test_bit(), it is for "__u32 *" (which we
>> can not change). The common test_bit() is for "unsigned long *", in this
>> case, I guess it may cause issue under 64-bit environments.
>
> Except that half the time you are passing a 'long *' and you haven't
> explained why this isn't broken on 64bit architectures.
>
Maybe we are misunderstanding with each other (excuse me for my pool
English). What I want to say is:
- hci_test_bit() is OK (current implementation can not cause issue for
64-bit machine).
- But if we use test_bit(), I guess it will cause issue for 64-bit
machine.
> Note that on LE systems the size of the accesses used to access a dense
> bit array don't matter. This is not true of BE systems.
>
Yes, what you said above sounds reasonable to me, too.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
--
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] drm: Kconfig: Let all DRM_GEM_CMA_HELPER related macros depend on HAVE_DMA_ATTRS
DRM_GEM_CMA_HELPER is depend on HAVE_DMA_ATTRS, or it will break the building. The related error (with allmodconfig under xtensa): CC [M] drivers/gpu/drm/drm_gem_cma_helper.o drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_create': drivers/gpu/drm/drm_gem_cma_helper.c:110:19: error: implicit declaration of function 'dma_alloc_writecombine' [-Werror=implicit-function-declaration] cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size, ^ drivers/gpu/drm/drm_gem_cma_helper.c:110:17: warning: assignment makes pointer from integer without a cast [-Wint-conversion] cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size, ^ drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_free_object': drivers/gpu/drm/drm_gem_cma_helper.c:193:3: error: implicit declaration of function 'dma_free_writecombine' [-Werror=implicit-function-declaration] dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size, ^ drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_mmap_obj': drivers/gpu/drm/drm_gem_cma_helper.c:330:8: error: implicit declaration of function 'dma_mmap_writecombine' [-Werror=implicit-function-declaration] ret = dma_mmap_writecombine(cma_obj->base.dev->dev, vma, ^ Signed-off-by: Chen Gang --- drivers/gpu/drm/Kconfig | 3 ++- drivers/gpu/drm/atmel-hlcdc/Kconfig | 2 +- drivers/gpu/drm/imx/Kconfig | 2 +- drivers/gpu/drm/rcar-du/Kconfig | 2 +- drivers/gpu/drm/shmobile/Kconfig| 2 +- drivers/gpu/drm/sti/Kconfig | 2 +- drivers/gpu/drm/tilcdc/Kconfig | 2 +- 7 files changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 308c104..151a050 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -62,12 +62,13 @@ config DRM_TTM config DRM_GEM_CMA_HELPER bool - depends on DRM + depends on DRM && HAVE_DMA_ATTRS help Choose this if you need the GEM CMA helper functions config DRM_KMS_CMA_HELPER bool + depends on DRM && HAVE_DMA_ATTRS select DRM_GEM_CMA_HELPER select DRM_KMS_FB_HELPER select FB_SYS_FILLRECT diff --git a/drivers/gpu/drm/atmel-hlcdc/Kconfig b/drivers/gpu/drm/atmel-hlcdc/Kconfig index 1a08562..219fc87 100644 --- a/drivers/gpu/drm/atmel-hlcdc/Kconfig +++ b/drivers/gpu/drm/atmel-hlcdc/Kconfig @@ -1,6 +1,6 @@ config DRM_ATMEL_HLCDC tristate "DRM Support for ATMEL HLCDC Display Controller" - depends on DRM && OF && COMMON_CLK && MFD_ATMEL_HLCDC + depends on DRM && OF && COMMON_CLK && MFD_ATMEL_HLCDC && HAVE_DMA_ATTRS select DRM_GEM_CMA_HELPER select DRM_KMS_HELPER select DRM_KMS_FB_HELPER diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig index 5d5e4092..33cdddf 100644 --- a/drivers/gpu/drm/imx/Kconfig +++ b/drivers/gpu/drm/imx/Kconfig @@ -5,7 +5,7 @@ config DRM_IMX select VIDEOMODE_HELPERS select DRM_GEM_CMA_HELPER select DRM_KMS_CMA_HELPER - depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM) + depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM) && HAVE_DMA_ATTRS depends on IMX_IPUV3_CORE help enable i.MX graphics support diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig index 2324a52..11485a4 100644 --- a/drivers/gpu/drm/rcar-du/Kconfig +++ b/drivers/gpu/drm/rcar-du/Kconfig @@ -1,6 +1,6 @@ config DRM_RCAR_DU tristate "DRM Support for R-Car Display Unit" - depends on DRM && ARM + depends on DRM && ARM && HAVE_DMA_ATTRS depends on ARCH_SHMOBILE || COMPILE_TEST select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER diff --git a/drivers/gpu/drm/shmobile/Kconfig b/drivers/gpu/drm/shmobile/Kconfig index a50fe0e..7321c41 100644 --- a/drivers/gpu/drm/shmobile/Kconfig +++ b/drivers/gpu/drm/shmobile/Kconfig @@ -1,6 +1,6 @@ config DRM_SHMOBILE tristate "DRM Support for SH Mobile" - depends on DRM && ARM + depends on DRM && ARM && HAVE_DMA_ATTRS depends on ARCH_SHMOBILE || COMPILE_TEST select BACKLIGHT_CLASS_DEVICE select DRM_KMS_HELPER diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig index d6d6b70..1fdb74b 100644 --- a/drivers/gpu/drm/sti/Kconfig +++ b/drivers/gpu/drm/sti/Kconfig @@ -1,6 +1,6 @@ config DRM_STI tristate "DRM Support for STMicroelectronics SoC stiH41x Series" - depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM) + depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM) && HAVE_DMA_ATTRS select RESET_CONTROLLER select DRM_KMS_HELPER select DRM_GEM_CMA_HELPER diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig index 7c3ef79..8394a0b 100644 --- a/drivers/gpu/drm/tilcdc/Kconfig +++ b/drivers/gpu/drm/tilcdc/Kconfig @@ -1,6 +1,6 @@ config DR
[PATCH] rc: st_rc: Use CONFIG_PM_SLEEP instead of CONFIG_PM for st_rc_suspend() and st_rc_resume()
st_rc_suspend() and st_rc_resume() depend on CONFIG_PM_SLEEP finally, so
they need CONFIG_PM_SLEEP instead of CONFIG_PM, or they will cause build
warning (with allmodconfig under xtensa):
CC [M] drivers/media/pci/smipcie/smipcie.o
drivers/media/rc/st_rc.c:338:12: warning: 'st_rc_suspend' defined but not
used [-Wunused-function]
static int st_rc_suspend(struct device *dev)
^
drivers/media/rc/st_rc.c:359:12: warning: 'st_rc_resume' defined but not used
[-Wunused-function]
static int st_rc_resume(struct device *dev)
^
Signed-off-by: Chen Gang
---
drivers/media/rc/st_rc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 0e758ae..fbfe958 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -334,7 +334,7 @@ err:
return ret;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int st_rc_suspend(struct device *dev)
{
struct st_rc_device *rc_dev = dev_get_drvdata(dev);
--
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] net: usb: sr9700: Use 'SR_' prefix for the common register macros
The commone register macors (e.g. RSR) is too commont to drivers, it may
be conflict with the architectures (e.g. xtensa, sh).
The related warnings (with allmodconfig under xtensa):
CC [M] drivers/net/usb/sr9700.o
In file included from drivers/net/usb/sr9700.c:24:0:
drivers/net/usb/sr9700.h:65:0: warning: "RSR" redefined
#define RSR 0x06
^
In file included from ./arch/xtensa/include/asm/bitops.h:22:0,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/net/usb/sr9700.c:13:
./arch/xtensa/include/asm/processor.h:190:0: note: this is the location of
the previous definition
#define RSR(v,sr) __asm__ __volatile__ ("rsr %0,"__stringify(sr) : "=a"(v));
^
Signed-off-by: Chen Gang
---
drivers/net/usb/sr9700.c | 36 +-
drivers/net/usb/sr9700.h | 66
2 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
index 99b69af..4a1e9c4 100644
--- a/drivers/net/usb/sr9700.c
+++ b/drivers/net/usb/sr9700.c
@@ -77,7 +77,7 @@ static int wait_phy_eeprom_ready(struct usbnet *dev, int phy)
int ret;
udelay(1);
- ret = sr_read_reg(dev, EPCR, &tmp);
+ ret = sr_read_reg(dev, SR_EPCR, &tmp);
if (ret < 0)
return ret;
@@ -98,15 +98,15 @@ static int sr_share_read_word(struct usbnet *dev, int phy,
u8 reg,
mutex_lock(&dev->phy_mutex);
- sr_write_reg(dev, EPAR, phy ? (reg | EPAR_PHY_ADR) : reg);
- sr_write_reg(dev, EPCR, phy ? (EPCR_EPOS | EPCR_ERPRR) : EPCR_ERPRR);
+ sr_write_reg(dev, SR_EPAR, phy ? (reg | EPAR_PHY_ADR) : reg);
+ sr_write_reg(dev, SR_EPCR, phy ? (EPCR_EPOS | EPCR_ERPRR) : EPCR_ERPRR);
ret = wait_phy_eeprom_ready(dev, phy);
if (ret < 0)
goto out_unlock;
- sr_write_reg(dev, EPCR, 0x0);
- ret = sr_read(dev, EPDR, 2, value);
+ sr_write_reg(dev, SR_EPCR, 0x0);
+ ret = sr_read(dev, SR_EPDR, 2, value);
netdev_dbg(dev->net, "read shared %d 0x%02x returned 0x%04x, %d\n",
phy, reg, *value, ret);
@@ -123,19 +123,19 @@ static int sr_share_write_word(struct usbnet *dev, int
phy, u8 reg,
mutex_lock(&dev->phy_mutex);
- ret = sr_write(dev, EPDR, 2, &value);
+ ret = sr_write(dev, SR_EPDR, 2, &value);
if (ret < 0)
goto out_unlock;
- sr_write_reg(dev, EPAR, phy ? (reg | EPAR_PHY_ADR) : reg);
- sr_write_reg(dev, EPCR, phy ? (EPCR_WEP | EPCR_EPOS | EPCR_ERPRW) :
+ sr_write_reg(dev, SR_EPAR, phy ? (reg | EPAR_PHY_ADR) : reg);
+ sr_write_reg(dev, SR_EPCR, phy ? (EPCR_WEP | EPCR_EPOS | EPCR_ERPRW) :
(EPCR_WEP | EPCR_ERPRW));
ret = wait_phy_eeprom_ready(dev, phy);
if (ret < 0)
goto out_unlock;
- sr_write_reg(dev, EPCR, 0x0);
+ sr_write_reg(dev, SR_EPCR, 0x0);
out_unlock:
mutex_unlock(&dev->phy_mutex);
@@ -188,7 +188,7 @@ static int sr_mdio_read(struct net_device *netdev, int
phy_id, int loc)
if (loc == MII_BMSR) {
u8 value;
- sr_read_reg(dev, NSR, &value);
+ sr_read_reg(dev, SR_NSR, &value);
if (value & NSR_LINKST)
rc = 1;
}
@@ -228,7 +228,7 @@ static u32 sr9700_get_link(struct net_device *netdev)
int rc = 0;
/* Get the Link Status directly */
- sr_read_reg(dev, NSR, &value);
+ sr_read_reg(dev, SR_NSR, &value);
if (value & NSR_LINKST)
rc = 1;
@@ -281,8 +281,8 @@ static void sr9700_set_multicast(struct net_device *netdev)
}
}
- sr_write_async(dev, MAR, SR_MCAST_SIZE, hashes);
- sr_write_reg_async(dev, RCR, rx_ctl);
+ sr_write_async(dev, SR_MAR, SR_MCAST_SIZE, hashes);
+ sr_write_reg_async(dev, SR_RCR, rx_ctl);
}
static int sr9700_set_mac_address(struct net_device *netdev, void *p)
@@ -297,7 +297,7 @@ static int sr9700_set_mac_address(struct net_device
*netdev, void *p)
}
memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
- sr_write_async(dev, PAR, 6, netdev->dev_addr);
+ sr_write_async(dev, SR_PAR, 6, netdev->dev_addr);
return 0;
}
@@ -340,7 +340,7 @@ static int sr9700_bind(struct usbnet *dev, struct
usb_interface *intf)
mii->phy_id_mask = 0x1f;
mii->reg_num_mask = 0x1f;
- sr_write_reg(dev, NCR, NCR_RST);
+ sr_write_reg(dev, SR_NCR, NCR_RST);
udelay(20);
/* read MAC
@@ -348,17 +348,17 @@ static int sr9700_bind(struct usbnet *dev, struct
usb_interface *intf)
* EEPROM automatically to PAR. In case there is no EEPROM exte
[PATCH v2] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()
hci_test_bit() does not modify 2nd parameter, so it is better to let it
be constant, or may cause build warning. The related warning (with
allmodconfig under xtensa):
net/bluetooth/hci_sock.c: In function 'hci_sock_sendmsg':
net/bluetooth/hci_sock.c:955:8: warning: passing argument 2 of 'hci_test_bit'
discards 'const' qualifier from pointer target type
[-Wdiscarded-array-qualifiers]
&hci_sec_filter.ocf_mask[ogf])) &&
^
net/bluetooth/hci_sock.c:49:19: note: expected 'void *' but argument is of
type 'const __u32 (*)[4] {aka const unsigned int (*)[4]}'
static inline int hci_test_bit(int nr, void *addr)
^
Signed-off-by: Chen Gang
---
net/bluetooth/hci_sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 80c5a79..858b53a 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -46,7 +46,7 @@ struct hci_pinfo {
unsigned shortchannel;
};
-static inline int hci_test_bit(int nr, void *addr)
+static inline int hci_test_bit(int nr, const void *addr)
{
return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
}
--
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/
Re: [PATCH] drm: Kconfig: Let all DRM_GEM_CMA_HELPER related macros depend on HAVE_DMA_ATTRS
After this fixing building patch, xtensa can pass allmodconfig. - There are still several warnings for it (I sent several patches for them, but not for all). - Xtensa gcc5 cross compiler has issues: it causes more than 10 broken areas with allmodconfig (but no issues with defconfig). I guess, in fact, it is only 1 real issue (which can cause all breaks), and I shall try to fix it within this month. Welcome any ideas, suggestions, or completions. Thanks. On 2/1/15 22:08, Chen Gang S wrote: > DRM_GEM_CMA_HELPER is depend on HAVE_DMA_ATTRS, or it will break the > building. The related error (with allmodconfig under xtensa): > > CC [M] drivers/gpu/drm/drm_gem_cma_helper.o > drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_create': > drivers/gpu/drm/drm_gem_cma_helper.c:110:19: error: implicit declaration of > function 'dma_alloc_writecombine' [-Werror=implicit-function-declaration] > cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size, > ^ > drivers/gpu/drm/drm_gem_cma_helper.c:110:17: warning: assignment makes > pointer from integer without a cast [-Wint-conversion] > cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size, >^ > drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_free_object': > drivers/gpu/drm/drm_gem_cma_helper.c:193:3: error: implicit declaration of > function 'dma_free_writecombine' [-Werror=implicit-function-declaration] > dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size, > ^ > drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_mmap_obj': > drivers/gpu/drm/drm_gem_cma_helper.c:330:8: error: implicit declaration of > function 'dma_mmap_writecombine' [-Werror=implicit-function-declaration] > ret = dma_mmap_writecombine(cma_obj->base.dev->dev, vma, > ^ > > Signed-off-by: Chen Gang > --- > drivers/gpu/drm/Kconfig | 3 ++- > drivers/gpu/drm/atmel-hlcdc/Kconfig | 2 +- > drivers/gpu/drm/imx/Kconfig | 2 +- > drivers/gpu/drm/rcar-du/Kconfig | 2 +- > drivers/gpu/drm/shmobile/Kconfig| 2 +- > drivers/gpu/drm/sti/Kconfig | 2 +- > drivers/gpu/drm/tilcdc/Kconfig | 2 +- > 7 files changed, 8 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 308c104..151a050 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -62,12 +62,13 @@ config DRM_TTM > > config DRM_GEM_CMA_HELPER > bool > - depends on DRM > + depends on DRM && HAVE_DMA_ATTRS > help > Choose this if you need the GEM CMA helper functions > > config DRM_KMS_CMA_HELPER > bool > + depends on DRM && HAVE_DMA_ATTRS > select DRM_GEM_CMA_HELPER > select DRM_KMS_FB_HELPER > select FB_SYS_FILLRECT > diff --git a/drivers/gpu/drm/atmel-hlcdc/Kconfig > b/drivers/gpu/drm/atmel-hlcdc/Kconfig > index 1a08562..219fc87 100644 > --- a/drivers/gpu/drm/atmel-hlcdc/Kconfig > +++ b/drivers/gpu/drm/atmel-hlcdc/Kconfig > @@ -1,6 +1,6 @@ > config DRM_ATMEL_HLCDC > tristate "DRM Support for ATMEL HLCDC Display Controller" > - depends on DRM && OF && COMMON_CLK && MFD_ATMEL_HLCDC > + depends on DRM && OF && COMMON_CLK && MFD_ATMEL_HLCDC && HAVE_DMA_ATTRS > select DRM_GEM_CMA_HELPER > select DRM_KMS_HELPER > select DRM_KMS_FB_HELPER > diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig > index 5d5e4092..33cdddf 100644 > --- a/drivers/gpu/drm/imx/Kconfig > +++ b/drivers/gpu/drm/imx/Kconfig > @@ -5,7 +5,7 @@ config DRM_IMX > select VIDEOMODE_HELPERS > select DRM_GEM_CMA_HELPER > select DRM_KMS_CMA_HELPER > - depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM) > + depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM) && HAVE_DMA_ATTRS > depends on IMX_IPUV3_CORE > help > enable i.MX graphics support > diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig > index 2324a52..11485a4 100644 > --- a/drivers/gpu/drm/rcar-du/Kconfig > +++ b/drivers/gpu/drm/rcar-du/Kconfig > @@ -1,6 +1,6 @@ > config DRM_RCAR_DU > tristate "DRM Support for R-Car Display Unit" > - depends on DRM && ARM > + depends on DRM && ARM && HAVE_DMA_ATTRS > depends on ARCH_SHMOBILE || COMPILE_TEST > select DRM_KMS_HELPER > select DRM_KMS_CMA_HELPER > diff --git a/drivers/gpu/drm/shmobile/Kconfig > b/drivers
Re: [PATCH v2] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()
On 2/3/15 05:20, Joe Perches wrote:
> On Tue, 2015-02-03 at 05:14 +0800, Chen Gang S wrote:
>> hci_test_bit() does not modify 2nd parameter, so it is better to let it
>> be constant, or may cause build warning. The related warning (with
>> allmodconfig under xtensa):
> []
>> diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
> []
>> @@ -46,7 +46,7 @@ struct hci_pinfo {
>> unsigned shortchannel;
>> };
>>
>> -static inline int hci_test_bit(int nr, void *addr)
>> +static inline int hci_test_bit(int nr, const void *addr)
>> {
>> return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
>> }
>
> It's probably better to use const __u32 * here too, but the
> real thing I wonder is whether or not there's an issue with
> one of the 2 uses of this function.
>
> One of them passes a unsigned long *, the other a u32 *.
>
> $ git grep -w hci_test_bit
> net/bluetooth/hci_sock.c:static inline int hci_test_bit(int nr, void *addr)
> net/bluetooth/hci_sock.c: if (!hci_test_bit(flt_event,
> &flt->event_mask))
> net/bluetooth/hci_sock.c:!hci_test_bit(ocf &
> HCI_FLT_OCF_BITS,
> net/bluetooth/hci_sock.c-
> &hci_sec_filter.ocf_mask[ogf])) &&
>
> hci_sec_filter.ocf_mask is __u32
> but flt->event_mask is unsigned long.
>
> Any possible issue here on 64-bit systems?
>
For me, it can not cause issue on 64-bit systems. hci_test_bit() treats
'addr' as "__u32 *", and has to use the pointer to do something.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
--
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] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()
On 2/3/15 10:32, Chen Gang S wrote:
> On 2/3/15 05:20, Joe Perches wrote:
>> On Tue, 2015-02-03 at 05:14 +0800, Chen Gang S wrote:
>>> hci_test_bit() does not modify 2nd parameter, so it is better to let it
>>> be constant, or may cause build warning. The related warning (with
>>> allmodconfig under xtensa):
>> []
>>> diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
>> []
>>> @@ -46,7 +46,7 @@ struct hci_pinfo {
>>> unsigned shortchannel;
>>> };
>>>
>>> -static inline int hci_test_bit(int nr, void *addr)
>>> +static inline int hci_test_bit(int nr, const void *addr)
>>> {
>>> return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
>>> }
>>
>> It's probably better to use const __u32 * here too, but the
>> real thing I wonder is whether or not there's an issue with
>> one of the 2 uses of this function.
>>
>> One of them passes a unsigned long *, the other a u32 *.
>>
>> $ git grep -w hci_test_bit
>> net/bluetooth/hci_sock.c:static inline int hci_test_bit(int nr, void *addr)
>> net/bluetooth/hci_sock.c: if (!hci_test_bit(flt_event,
>> &flt->event_mask))
>> net/bluetooth/hci_sock.c:!hci_test_bit(ocf &
>> HCI_FLT_OCF_BITS,
>> net/bluetooth/hci_sock.c-
>> &hci_sec_filter.ocf_mask[ogf])) &&
>>
>> hci_sec_filter.ocf_mask is __u32
>> but flt->event_mask is unsigned long.
>>
>> Any possible issue here on 64-bit systems?
>>
>
> For me, it can not cause issue on 64-bit systems. hci_test_bit() treats
> 'addr' as "__u32 *", and has to use the pointer to do something.
>
'event_mask' is intended to type cast to "__u32 *" within 'hci_sock.c'.
So for me, "const __u32 *" is better than "const void *" for 2nd
parameter of hci_test_bit().
If what I said above is correct, and also if necessary, I shall patch v3
for it.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
--
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] drm: Kconfig: Let all DRM_GEM_CMA_HELPER related macros depend on HAVE_DMA_ATTRS
On 02/03/2015 06:45 PM, Laurent Pinchart wrote: > Hi Chen, > > Thank you for the patch. > > On Sunday 01 February 2015 22:08:33 Chen Gang S wrote: >> DRM_GEM_CMA_HELPER is depend on HAVE_DMA_ATTRS, or it will break the >> building. The related error (with allmodconfig under xtensa): >> >> CC [M] drivers/gpu/drm/drm_gem_cma_helper.o >> drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_create': >> drivers/gpu/drm/drm_gem_cma_helper.c:110:19: error: implicit declaration >> of function 'dma_alloc_writecombine' >> [-Werror=implicit-function-declaration] cma_obj->vaddr = >> dma_alloc_writecombine(drm->dev, size, >> ^ >> drivers/gpu/drm/drm_gem_cma_helper.c:110:17: warning: assignment makes >> pointer from integer without a cast [-Wint-conversion] cma_obj->vaddr = >> dma_alloc_writecombine(drm->dev, size, >>^ >> drivers/gpu/drm/drm_gem_cma_helper.c: In function >> 'drm_gem_cma_free_object': drivers/gpu/drm/drm_gem_cma_helper.c:193:3: >> error: implicit declaration of function 'dma_free_writecombine' >> [-Werror=implicit-function-declaration] >> dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size, >> ^ >> drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_mmap_obj': >> drivers/gpu/drm/drm_gem_cma_helper.c:330:8: error: implicit declaration of >> function 'dma_mmap_writecombine' [-Werror=implicit-function-declaration] >> ret = dma_mmap_writecombine(cma_obj->base.dev->dev, vma, >> ^ >> >> Signed-off-by: Chen Gang >> --- >> drivers/gpu/drm/Kconfig | 3 ++- >> drivers/gpu/drm/atmel-hlcdc/Kconfig | 2 +- >> drivers/gpu/drm/imx/Kconfig | 2 +- >> drivers/gpu/drm/rcar-du/Kconfig | 2 +- >> drivers/gpu/drm/shmobile/Kconfig| 2 +- >> drivers/gpu/drm/sti/Kconfig | 2 +- >> drivers/gpu/drm/tilcdc/Kconfig | 2 +- >> 7 files changed, 8 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index 308c104..151a050 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -62,12 +62,13 @@ config DRM_TTM >> >> config DRM_GEM_CMA_HELPER >> bool >> -depends on DRM >> +depends on DRM && HAVE_DMA_ATTRS >> help >>Choose this if you need the GEM CMA helper functions >> >> config DRM_KMS_CMA_HELPER >> bool >> +depends on DRM && HAVE_DMA_ATTRS >> select DRM_GEM_CMA_HELPER >> select DRM_KMS_FB_HELPER >> select FB_SYS_FILLRECT >> diff --git a/drivers/gpu/drm/atmel-hlcdc/Kconfig >> b/drivers/gpu/drm/atmel-hlcdc/Kconfig index 1a08562..219fc87 100644 >> --- a/drivers/gpu/drm/atmel-hlcdc/Kconfig >> +++ b/drivers/gpu/drm/atmel-hlcdc/Kconfig >> @@ -1,6 +1,6 @@ >> config DRM_ATMEL_HLCDC >> tristate "DRM Support for ATMEL HLCDC Display Controller" >> -depends on DRM && OF && COMMON_CLK && MFD_ATMEL_HLCDC >> +depends on DRM && OF && COMMON_CLK && MFD_ATMEL_HLCDC && HAVE_DMA_ATTRS > > I don't like having to add the explicit dependency to all users of > DRM_GEM_CMA_HELPER and DRM_KMS_CMA_HELPER, but there's no way around this > given the select vs. depends issues in Kconfig. > > A better solution in the longer term would be to implement HAVE_DMA_ATTRS > support for xtensa (and all the other architectures that miss it), but this > patch looks fine to me as an interim solution. > > Acked-by: Laurent Pinchart > OK, thanks. At present, 15 archs implement HAVE_DMA_ATTRS. I guess, it is not quite easy to let the left 15 archs support HAVE_DMA_ATTRS, so we have to accept the current interim solution. Thanks. -- Open, share, and attitude like air, water, and life which God blessed. -- 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/
Fwd: [PATCH] c6x: Makefile: Add -D__linux__
Just forward mail. Forwarded Message Subject: [PATCH] c6x: Makefile: Add -D__linux__ Date: Tue, 03 Mar 2015 06:33:42 +0800 From: Chen Gang <762976...@qq.com> To: Mark Salter , a-jacqu...@ti.com CC: linux-c6x-...@linux-c6x.org , linux-kernel@vger.kernel.org For gcc5 c6x raw compiler, at present, it may not define __linux__, so c6x kernel still needs to define __linux__ just like another archs have done. The related error: CC [M] fs/coda/psdev.o In file included from include/linux/coda.h:64:0, from fs/coda/psdev.c:45: include/uapi/linux/coda.h:221:2: error: unknown type name 'u_quad_t' u_quad_t va_size; /* file size in bytes */ ^ include/uapi/linux/coda.h:229:2: error: unknown type name 'u_quad_t' u_quad_t va_bytes; /* bytes of disk space held by file */ ^ include/uapi/linux/coda.h:230:2: error: unknown type name 'u_quad_t' u_quad_t va_filerev; /* file modification number */ ^ Signed-off-by: Chen Gang --- arch/c6x/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/c6x/Makefile b/arch/c6x/Makefile index e72eb34..6b0be67 100644 --- a/arch/c6x/Makefile +++ b/arch/c6x/Makefile @@ -8,7 +8,7 @@ KBUILD_DEFCONFIG := dsk6455_defconfig -cflags-y += -mno-dsbt -msdata=none +cflags-y += -mno-dsbt -msdata=none -D__linux__ cflags-$(CONFIG_C6X_BIG_KERNEL) += -mlong-calls -- 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/
Fwd: [PATCH] mm: memcontrol: Let mem_cgroup_move_account() have effect only if MMU enabled
Just forward mail.
Forwarded Message
Subject: [PATCH] mm: memcontrol: Let mem_cgroup_move_account() have effect only
if MMU enabled
Date: Tue, 03 Mar 2015 06:42:01 +0800
From: Chen Gang <762976...@qq.com>
To: han...@cmpxchg.org, mho...@suse.cz
CC: cgro...@vger.kernel.org, linux...@kvack.org, linux-kernel@vger.kernel.org
When !MMU, it will report warning. The related warning with allmodconfig
under c6x:
CC mm/memcontrol.o
mm/memcontrol.c:2802:12: warning: 'mem_cgroup_move_account' defined but not
used [-Wunused-function]
static int mem_cgroup_move_account(struct page *page,
^
Signed-off-by: Chen Gang
---
mm/memcontrol.c | 172
1 file changed, 86 insertions(+), 86 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 0c86945..80f26f5 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2785,92 +2785,6 @@ void mem_cgroup_split_huge_fixup(struct page *head)
}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
-/**
- * mem_cgroup_move_account - move account of the page
- * @page: the page
- * @nr_pages: number of regular pages (>1 for huge pages)
- * @from: mem_cgroup which the page is moved from.
- * @to:mem_cgroup which the page is moved to. @from != @to.
- *
- * The caller must confirm following.
- * - page is not on LRU (isolate_page() is useful.)
- * - compound_lock is held when nr_pages > 1
- *
- * This function doesn't do "charge" to new cgroup and doesn't do "uncharge"
- * from old cgroup.
- */
-static int mem_cgroup_move_account(struct page *page,
- unsigned int nr_pages,
- struct mem_cgroup *from,
- struct mem_cgroup *to)
-{
- unsigned long flags;
- int ret;
-
- VM_BUG_ON(from == to);
- VM_BUG_ON_PAGE(PageLRU(page), page);
- /*
-* The page is isolated from LRU. So, collapse function
-* will not handle this page. But page splitting can happen.
-* Do this check under compound_page_lock(). The caller should
-* hold it.
-*/
- ret = -EBUSY;
- if (nr_pages > 1 && !PageTransHuge(page))
- goto out;
-
- /*
-* Prevent mem_cgroup_migrate() from looking at page->mem_cgroup
-* of its source page while we change it: page migration takes
-* both pages off the LRU, but page cache replacement doesn't.
-*/
- if (!trylock_page(page))
- goto out;
-
- ret = -EINVAL;
- if (page->mem_cgroup != from)
- goto out_unlock;
-
- spin_lock_irqsave(&from->move_lock, flags);
-
- if (!PageAnon(page) && page_mapped(page)) {
- __this_cpu_sub(from->stat->count[MEM_CGROUP_STAT_FILE_MAPPED],
- nr_pages);
- __this_cpu_add(to->stat->count[MEM_CGROUP_STAT_FILE_MAPPED],
- nr_pages);
- }
-
- if (PageWriteback(page)) {
- __this_cpu_sub(from->stat->count[MEM_CGROUP_STAT_WRITEBACK],
- nr_pages);
- __this_cpu_add(to->stat->count[MEM_CGROUP_STAT_WRITEBACK],
- nr_pages);
- }
-
- /*
-* It is safe to change page->mem_cgroup here because the page
-* is referenced, charged, and isolated - we can't race with
-* uncharging, charging, migration, or LRU putback.
-*/
-
- /* caller should have done css_get */
- page->mem_cgroup = to;
- spin_unlock_irqrestore(&from->move_lock, flags);
-
- ret = 0;
-
- local_irq_disable();
- mem_cgroup_charge_statistics(to, page, nr_pages);
- memcg_check_events(to, page);
- mem_cgroup_charge_statistics(from, page, -nr_pages);
- memcg_check_events(from, page);
- local_irq_enable();
-out_unlock:
- unlock_page(page);
-out:
- return ret;
-}
-
#ifdef CONFIG_MEMCG_SWAP
static void mem_cgroup_swap_statistics(struct mem_cgroup *memcg,
bool charge)
@@ -4822,6 +4736,92 @@ static struct page *mc_handle_file_pte(struct
vm_area_struct *vma,
return page;
}
+/**
+ * mem_cgroup_move_account - move account of the page
+ * @page: the page
+ * @nr_pages: number of regular pages (>1 for huge pages)
+ * @from: mem_cgroup which the page is moved from.
+ * @to:mem_cgroup which the page is moved to. @from != @to.
+ *
+ * The caller must confirm following.
+ * - page is not on LRU (isolate_page() is useful.)
+ * - compound_lock is held when nr_pages > 1
+ *
+ * This function doesn't do "charge" to new cgroup and doesn't do "uncharge"
+ * from old cgroup.
+ */
+static int mem_cgroup_move_account(struct page *page,
+ unsigned int nr_pages,
+ struct mem_cgroup *from,
+ struct mem_cgroup *t
Fwd: [PATCH] c6x: asm: pgtable: Define dummy pgprot_writecombine for !MMU
Forwarded Message
Subject: [PATCH] c6x: asm: pgtable: Define dummy pgprot_writecombine for !MMU
Date: Tue, 03 Mar 2015 07:06:25 +0800
From: Chen Gang <762976...@qq.com>
To: msal...@redhat.com, a-jacqu...@ti.com
CC: kirill.shute...@linux.intel.com, Andrew Morton ,
linux-c6x-...@linux-c6x.org ,
linux-kernel@vger.kernel.org
When !MMU, asm-generic will not define default pgprot_writecombine, so
c6x needs to define it by itself. The related error:
CC [M] fs/pstore/ram_core.o
fs/pstore/ram_core.c: In function 'persistent_ram_vmap':
fs/pstore/ram_core.c:399:10: error: implicit declaration of function
'pgprot_writecombine' [-Werror=implicit-function-declaration]
prot = pgprot_writecombine(PAGE_KERNEL);
^
fs/pstore/ram_core.c:399:8: error: incompatible types when assigning to type
'pgprot_t {aka struct }' from type 'int'
prot = pgprot_writecombine(PAGE_KERNEL);
^
Signed-off-by: Chen Gang
---
arch/c6x/include/asm/pgtable.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/c6x/include/asm/pgtable.h b/arch/c6x/include/asm/pgtable.h
index 78d4483..ec4db6d 100644
--- a/arch/c6x/include/asm/pgtable.h
+++ b/arch/c6x/include/asm/pgtable.h
@@ -67,6 +67,11 @@ extern unsigned long empty_zero_page;
*/
#define pgtable_cache_init() do { } while (0)
+/*
+ * c6x is !MMU, so define the simpliest implementation
+ */
+#define pgprot_writecombine pgprot_noncached
+
#include
#endif /* _ASM_C6X_PGTABLE_H */
--
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/
Fwd: [PATCH] c6x: asm: Add default flat.h according to xtensa architecture
Just forward the original mail. Forwarded Message Subject: [PATCH] c6x: asm: Add default flat.h according to xtensa architecture Date: Tue, 03 Mar 2015 07:24:26 +0800 From: Chen Gang <762976...@qq.com> To: msal...@redhat.com, a-jacqu...@ti.com CC: linux-c6x-...@linux-c6x.org , linux-kernel@vger.kernel.org For supporting uClinux flat-format executables, c6x needs to define the fewest features to support it, at present, xtensa architecture has the fewest feature for it, so just copy xtensa flat.h. The related error: CC fs/binfmt_flat.o In file included from fs/binfmt_flat.c:36:0: include/linux/flat.h:12:22: fatal error: asm/flat.h: No such file or directory Signed-off-by: Chen Gang --- arch/c6x/include/asm/flat.h | 12 1 file changed, 12 insertions(+) create mode 100644 arch/c6x/include/asm/flat.h diff --git a/arch/c6x/include/asm/flat.h b/arch/c6x/include/asm/flat.h new file mode 100644 index 000..94c44ab --- /dev/null +++ b/arch/c6x/include/asm/flat.h @@ -0,0 +1,12 @@ +#ifndef __ASM_C6X_FLAT_H +#define __ASM_C6X_FLAT_H + +#define flat_argvp_envp_on_stack() 0 +#define flat_old_ram_flag(flags) (flags) +#define flat_reloc_valid(reloc, size) ((reloc) <= (size)) +#define flat_get_addr_from_rp(rp, relval, flags, p)get_unaligned(rp) +#define flat_put_addr_at_rp(rp, val, relval) put_unaligned(val, rp) +#define flat_get_relocate_addr(rel)(rel) +#define flat_set_persistent(relval, p) 0 + +#endif /* __ASM_C6X_FLAT_H */ -- 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/
Re: [PATCH] rc: st_rc: Use CONFIG_PM_SLEEP instead of CONFIG_PM for st_rc_suspend() and st_rc_resume()
Hello Maintainers:
Please help to process this patch, when you have time.
Thanks.
On 2/2/15 15:54, Patrice Chotard wrote:
> Hi Chen
>
> On 02/01/2015 03:42 PM, Chen Gang S wrote:
>> st_rc_suspend() and st_rc_resume() depend on CONFIG_PM_SLEEP finally, so
>> they need CONFIG_PM_SLEEP instead of CONFIG_PM, or they will cause build
>> warning (with allmodconfig under xtensa):
>>
>> CC [M] drivers/media/pci/smipcie/smipcie.o
>>drivers/media/rc/st_rc.c:338:12: warning: 'st_rc_suspend' defined but not
>> used [-Wunused-function]
>> static int st_rc_suspend(struct device *dev)
>>^
>>drivers/media/rc/st_rc.c:359:12: warning: 'st_rc_resume' defined but not
>> used [-Wunused-function]
>> static int st_rc_resume(struct device *dev)
>>^
>>
>> Signed-off-by: Chen Gang
>> ---
>> drivers/media/rc/st_rc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
>> index 0e758ae..fbfe958 100644
>> --- a/drivers/media/rc/st_rc.c
>> +++ b/drivers/media/rc/st_rc.c
>> @@ -334,7 +334,7 @@ err:
>> return ret;
>> }
>> -#ifdef CONFIG_PM
>> +#ifdef CONFIG_PM_SLEEP
>> static int st_rc_suspend(struct device *dev)
>> {
>> struct st_rc_device *rc_dev = dev_get_drvdata(dev);
>
> Acked-by: Patrice Chotard
>
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
--
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] drm: Kconfig: Let all DRM_GEM_CMA_HELPER related macros depend on HAVE_DMA_ATTRS
On 2/3/15 05:26, Chen Gang S wrote: [...] > > - Xtensa gcc5 cross compiler has issues: > >it causes more than 10 broken areas with allmodconfig (but no issues >with defconfig). I guess, in fact, it is only 1 real issue (which can >cause all breaks), and I shall try to fix it within this month. > I finish analysing for it, it is really only one issue for gcc5, and I guess, this issue is also not only for xtensa. I send related fix patch to gcc patch mailing list, hope it can pass checking. The cause is "the variables are not initialized before using them", the bug information is "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65117";. After fix this issue, it can build xtensa Linux kernel with allmodconfig successfully. [...] Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- 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/
Fwd: [PATCH] c6x: kernel: setup: Include "linux/console.h" if both VT and DUMMY_CONSOLE enabled
This patch below is sent from my other email address (762976...@qq.com), but is rejected by linux-kernel@vger.kernel.org, so I forward it by my original email address. Excuse me, I will leave current company soon (sunrus.com.cn), so I have to change my email address too. At present, gmail in China is still not stable enough, so I have to use other personal email: 762976...@qq.com. If linux-kernel mailing list can not accept personal qq email address, please let me know, I shall try to look for another personal email addresses. Thanks. Forwarded Message Subject: [PATCH] c6x: kernel: setup: Include "linux/console.h" if both VT and DUMMY_CONSOLE enabled Date: Sun, 01 Mar 2015 15:59:19 +0800 From: Chen Gang <762976...@qq.com> To: msal...@redhat.com, a-jacqu...@ti.com, r...@kernel.org CC: linux-c6x-...@linux-c6x.org , linux-kernel@vger.kernel.org Or c6x will cause building break for allmodconfig, the related error: CC arch/c6x/kernel/setup.o arch/c6x/kernel/setup.c: In function 'setup_arch': arch/c6x/kernel/setup.c:433:2: error: 'conswitchp' undeclared (first use in this function) conswitchp = &dummy_con; ^ arch/c6x/kernel/setup.c:433:2: note: each undeclared identifier is reported only once for each function it appears in arch/c6x/kernel/setup.c:433:16: error: 'dummy_con' undeclared (first use in this function) conswitchp = &dummy_con; ^ Signed-off-by: Chen Gang --- arch/c6x/kernel/setup.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/c6x/kernel/setup.c b/arch/c6x/kernel/setup.c index 7571288..a5f6e0e 100644 --- a/arch/c6x/kernel/setup.c +++ b/arch/c6x/kernel/setup.c @@ -26,7 +26,9 @@ #include #include #include - +#if defined(CONFIG_VT) && defined(CONFIG_DUMMY_CONSOLE) +#include +#endif #include #include -- 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/
Fwd: [PATCH] c6x: kernel: setup: Type cast 'fdt' to "void *" for early_init_dt_scan() in machine_init()
Just forward to linux kernel mailing list. Thanks. Forwarded Message Subject: [PATCH] c6x: kernel: setup: Type cast 'fdt' to "void *" for early_init_dt_scan() in machine_init() Date: Sun, 01 Mar 2015 16:11:29 +0800 From: Chen Gang <762976...@qq.com> To: msal...@redhat.com, a-jacqu...@ti.com, r...@kernel.org CC: linux-c6x-...@linux-c6x.org , linux-kernel@vger.kernel.org early_init_dt_scan() accepts "void *", so c6x needs to type cast 'fdt' to "void *" to avoid warning: CC arch/c6x/kernel/setup.o arch/c6x/kernel/setup.c: In function 'machine_init': arch/c6x/kernel/setup.c:290:21: warning: passing argument 1 of 'early_init_dt_scan' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] early_init_dt_scan(fdt); ^ In file included from arch/c6x/kernel/setup.c:19:0: include/linux/of_fdt.h:75:13: note: expected 'void *' but argument is of type 'const void *' extern bool early_init_dt_scan(void *params); ^ Signed-off-by: Chen Gang --- arch/c6x/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/c6x/kernel/setup.c b/arch/c6x/kernel/setup.c index a5f6e0e..e5ea757 100644 --- a/arch/c6x/kernel/setup.c +++ b/arch/c6x/kernel/setup.c @@ -289,7 +289,7 @@ notrace void __init machine_init(unsigned long dt_ptr) fdt = dtb; /* Do some early initialization based on the flat device tree */ - early_init_dt_scan(fdt); + early_init_dt_scan((void *)fdt); parse_early_param(); } -- 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/
Fwd: [PATCH] c6x: kernel: setup: Type cast 'fdt' to "void *" for early_init_dt_scan() in machine_init()
Just forward to linux kernel mailing list. Thanks. Forwarded Message Subject: [PATCH] c6x: kernel: setup: Type cast 'fdt' to "void *" for early_init_dt_scan() in machine_init() Date: Sun, 01 Mar 2015 16:31:29 +0800 From: Chen Gang <762976...@qq.com> To: msal...@redhat.com, a-jacqu...@ti.com CC: linux-c6x-...@linux-c6x.org, linux-kernel@vger.kernel.org early_init_dt_scan() accepts "void *", so c6x needs to type cast 'fdt' to "void *" to avoid warning: CC arch/c6x/kernel/setup.o arch/c6x/kernel/setup.c: In function 'machine_init': arch/c6x/kernel/setup.c:290:21: warning: passing argument 1 of 'early_init_dt_scan' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] early_init_dt_scan(fdt); ^ In file included from arch/c6x/kernel/setup.c:19:0: include/linux/of_fdt.h:75:13: note: expected 'void *' but argument is of type 'const void *' extern bool early_init_dt_scan(void *params); ^ Signed-off-by: Chen Gang --- arch/c6x/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/c6x/kernel/setup.c b/arch/c6x/kernel/setup.c index a5f6e0e..e5ea757 100644 --- a/arch/c6x/kernel/setup.c +++ b/arch/c6x/kernel/setup.c @@ -289,7 +289,7 @@ notrace void __init machine_init(unsigned long dt_ptr) fdt = dtb; /* Do some early initialization based on the flat device tree */ - early_init_dt_scan(fdt); + early_init_dt_scan((void *)fdt); parse_early_param(); } -- 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/
