Re: [PATCH] arm64: add kc_offset_to_vaddr and kc_vaddr_to_offset macro

[yalin wang]

ok

i will send a V2 patch for this change.
> On Sep 2, 2015, at 18:24, Will Deacon <will.dea...@arm.com> wrote:
> 
> On Sun, Aug 30, 2015 at 07:19:59AM +0100, yalin wang wrote:
>> This patch add kc_offset_to_vaddr() and kc_vaddr_to_offset(),
>> the default version doesn't work on arm64, because arm64 kernel address
>> is below the PAGE_OFFSET, like module address and vmemmap address are
>> all below PAGE_OFFSET address.
>> 
>> Signed-off-by: yalin wang <yalin.wang2...@gmail.com>
>> ---
>> arch/arm64/include/asm/pgtable.h | 2 ++
>> 1 file changed, 2 insertions(+)
>> 
>> diff --git a/arch/arm64/include/asm/pgtable.h 
>> b/arch/arm64/include/asm/pgtable.h
>> index d374191..ef1ed5c 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -660,6 +660,8 @@ static inline void update_mmu_cache(struct 
>> vm_area_struct *vma,
>> 
>> #define update_mmu_cache_pmd(vma, address, pmd) do { } while (0)
>> 
>> +#define kc_vaddr_to_offset(v) ((v) & ((1UL << VA_BITS) - 1))
>> +#define kc_offset_to_vaddr(o) ((o) | ~((1UL << VA_BITS) - 1))
> 
> I think it would be cleaner to define something like VIRTUAL_BASE, and
> then define the vmalloc area in terms of that as well as these kcore
> macros.
> 
> Will

--
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 V2] arm64: add kc_offset_to_vaddr and kc_vaddr_to_offset macro

[yalin wang]

This patch add kc_offset_to_vaddr() and kc_vaddr_to_offset(),
the default version doesn't work on arm64, because arm64 kernel address
is below the PAGE_OFFSET, like module address and vmemmap address are
all below PAGE_OFFSET address.

Signed-off-by: yalin wang <yalin.wang2...@gmail.com>
---
 arch/arm64/include/asm/memory.h  | 1 +
 arch/arm64/include/asm/pgtable.h | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index f800d45..2d09fe8 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -55,6 +55,7 @@
 #define PCI_IO_START   (PCI_IO_END - PCI_IO_SIZE)
 #define FIXADDR_TOP(PCI_IO_START - SZ_2M)
 #define TASK_SIZE_64   (UL(1) << VA_BITS)
+#define __VIRTUAL_MASK ((1UL << VA_BITS) - 1)
 
 #ifdef CONFIG_COMPAT
 #define TASK_SIZE_32   UL(0x1)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index d374191..9da6681 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -660,6 +660,8 @@ static inline void update_mmu_cache(struct vm_area_struct 
*vma,
 
 #define update_mmu_cache_pmd(vma, address, pmd) do { } while (0)
 
+#definekc_vaddr_to_offset(v) ((v) & __VIRTUAL_MASK)
+#definekc_offset_to_vaddr(o) ((o) | ~__VIRTUAL_MASK)
 #endif /* !__ASSEMBLY__ */
 
 #endif /* __ASM_PGTABLE_H */
-- 
1.9.1

--
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] arm64: add kc_offset_to_vaddr and kc_vaddr_to_offset macro

[yalin wang]

Ping ?
> On Aug 30, 2015, at 14:19, yalin wang  wrote:
> 
> This patch add kc_offset_to_vaddr() and kc_vaddr_to_offset(),
> the default version doesn't work on arm64, because arm64 kernel address
> is below the PAGE_OFFSET, like module address and vmemmap address are
> all below PAGE_OFFSET address.
> 
> Signed-off-by: yalin wang 
> ---
> arch/arm64/include/asm/pgtable.h | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/pgtable.h 
> b/arch/arm64/include/asm/pgtable.h
> index d374191..ef1ed5c 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -660,6 +660,8 @@ static inline void update_mmu_cache(struct vm_area_struct 
> *vma,
> 
> #define update_mmu_cache_pmd(vma, address, pmd) do { } while (0)
> 
> +#define  kc_vaddr_to_offset(v) ((v) & ((1UL << VA_BITS) - 1))
> +#define  kc_offset_to_vaddr(o) ((o) | ~((1UL << VA_BITS) - 1))
> #endif /* !__ASSEMBLY__ */
> 
> #endif /* __ASM_PGTABLE_H */
> -- 
> 1.9.1
> 

--
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 1/2] x86/bitops: implement __test_bit

[yalin wang]

> On Aug 31, 2015, at 15:59, Ingo Molnar  wrote:
> 
> 
> * Michael S. Tsirkin  wrote:
> 
>> On Sun, Aug 30, 2015 at 11:13:20PM -0700, H. Peter Anvin wrote:
>>> Presumably because gcc can't generate bt... whether or not it is worth it 
>>> is another matter.
>>> 
>>> On August 30, 2015 11:05:49 PM PDT, Ingo Molnar  wrote:
 
 * Michael S. Tsirkin  wrote:
 
> +static __always_inline int __constant_test_bit(long nr, const
 unsigned long *addr)
> +{
> + return ((1UL << (nr & (BITS_PER_LONG-1))) &
> + (addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
> +}
> +
> +static inline int __variable_test_bit(long nr, const unsigned long
 *addr)
> +{
> + int oldbit;
> +
> + asm volatile("bt %2,%1\n\t"
> +  "sbb %0,%0"
> +  : "=r" (oldbit)
> +  : "m" (*addr), "Ir" (nr));
> +
> + return oldbit;
> +}
 
 Color me confused, why use assembly for this at all?
 
 Why not just use C for testing the bit (i.e. turn __constant_test_bit()
 into 
 __test_bit()) - that would also allow the compiler to propagate the
 result, 
 potentially more optimally than we can do it via SBB...
 
 Thanks,
 
Ingo
>> 
>> Exactly:
>> 
>> 
>> Disassembly of section .text:
>> 
>>  <__variable_test_bit>:
>> __variable_test_bit():
>>   0:   8b 54 24 08 mov0x8(%esp),%edx
>>   4:   8b 44 24 04 mov0x4(%esp),%eax
>>   8:   0f a3 02bt %eax,(%edx)
>>   b:   19 c0   sbb%eax,%eax
>>   d:   c3  ret
>>   e:   66 90   xchg   %ax,%ax
>> 
>> 0010 <__constant_test_bit>:
>> __constant_test_bit():
>>  10:   8b 4c 24 04 mov0x4(%esp),%ecx
>>  14:   8b 44 24 08 mov0x8(%esp),%eax
>>  18:   89 ca   mov%ecx,%edx
>>  1a:   c1 fa 04sar$0x4,%edx
>>  1d:   8b 04 90mov(%eax,%edx,4),%eax
>>  20:   d3 e8   shr%cl,%eax
>>  22:   83 e0 01and$0x1,%eax
>>  25:   c3  ret
> 
> But that's due to the forced interface of generating a return code. Please 
> compare 
> it at an inlined usage site, where GCC is free to do the comparison directly 
> and 
> use the result in flags.
just curious :
it seems __variable_test_bit()  use less instructions,
why not always use __variable_test_bit() , remove __constant_test_bit() version 
?

Thanks




--
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] arm64: add kc_offset_to_vaddr and kc_vaddr_to_offset macro

[yalin wang]

Ping ?
> On Aug 30, 2015, at 14:19, yalin wang <yalin.wang2...@gmail.com> wrote:
> 
> This patch add kc_offset_to_vaddr() and kc_vaddr_to_offset(),
> the default version doesn't work on arm64, because arm64 kernel address
> is below the PAGE_OFFSET, like module address and vmemmap address are
> all below PAGE_OFFSET address.
> 
> Signed-off-by: yalin wang <yalin.wang2...@gmail.com>
> ---
> arch/arm64/include/asm/pgtable.h | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/pgtable.h 
> b/arch/arm64/include/asm/pgtable.h
> index d374191..ef1ed5c 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -660,6 +660,8 @@ static inline void update_mmu_cache(struct vm_area_struct 
> *vma,
> 
> #define update_mmu_cache_pmd(vma, address, pmd) do { } while (0)
> 
> +#define  kc_vaddr_to_offset(v) ((v) & ((1UL << VA_BITS) - 1))
> +#define  kc_offset_to_vaddr(o) ((o) | ~((1UL << VA_BITS) - 1))
> #endif /* !__ASSEMBLY__ */
> 
> #endif /* __ASM_PGTABLE_H */
> -- 
> 1.9.1
> 

--
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 1/2] x86/bitops: implement __test_bit

[yalin wang]

> On Aug 31, 2015, at 15:59, Ingo Molnar  wrote:
> 
> 
> * Michael S. Tsirkin  wrote:
> 
>> On Sun, Aug 30, 2015 at 11:13:20PM -0700, H. Peter Anvin wrote:
>>> Presumably because gcc can't generate bt... whether or not it is worth it 
>>> is another matter.
>>> 
>>> On August 30, 2015 11:05:49 PM PDT, Ingo Molnar  wrote:
 
 * Michael S. Tsirkin  wrote:
 
> +static __always_inline int __constant_test_bit(long nr, const
 unsigned long *addr)
> +{
> + return ((1UL << (nr & (BITS_PER_LONG-1))) &
> + (addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
> +}
> +
> +static inline int __variable_test_bit(long nr, const unsigned long
 *addr)
> +{
> + int oldbit;
> +
> + asm volatile("bt %2,%1\n\t"
> +  "sbb %0,%0"
> +  : "=r" (oldbit)
> +  : "m" (*addr), "Ir" (nr));
> +
> + return oldbit;
> +}
 
 Color me confused, why use assembly for this at all?
 
 Why not just use C for testing the bit (i.e. turn __constant_test_bit()
 into 
 __test_bit()) - that would also allow the compiler to propagate the
 result, 
 potentially more optimally than we can do it via SBB...
 
 Thanks,
 
Ingo
>> 
>> Exactly:
>> 
>> 
>> Disassembly of section .text:
>> 
>>  <__variable_test_bit>:
>> __variable_test_bit():
>>   0:   8b 54 24 08 mov0x8(%esp),%edx
>>   4:   8b 44 24 04 mov0x4(%esp),%eax
>>   8:   0f a3 02bt %eax,(%edx)
>>   b:   19 c0   sbb%eax,%eax
>>   d:   c3  ret
>>   e:   66 90   xchg   %ax,%ax
>> 
>> 0010 <__constant_test_bit>:
>> __constant_test_bit():
>>  10:   8b 4c 24 04 mov0x4(%esp),%ecx
>>  14:   8b 44 24 08 mov0x8(%esp),%eax
>>  18:   89 ca   mov%ecx,%edx
>>  1a:   c1 fa 04sar$0x4,%edx
>>  1d:   8b 04 90mov(%eax,%edx,4),%eax
>>  20:   d3 e8   shr%cl,%eax
>>  22:   83 e0 01and$0x1,%eax
>>  25:   c3  ret
> 
> But that's due to the forced interface of generating a return code. Please 
> compare 
> it at an inlined usage site, where GCC is free to do the comparison directly 
> and 
> use the result in flags.
just curious :
it seems __variable_test_bit()  use less instructions,
why not always use __variable_test_bit() , remove __constant_test_bit() version 
?

Thanks




--
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] task_work: remove fifo ordering guarantee

[yalin wang]

> On Aug 30, 2015, at 01:08, Linus Torvalds  
> wrote:
> 
> On Sat, Aug 29, 2015 at 7:11 AM, Eric Dumazet  wrote:
>> 
>> If this needs to be kept, maybe then add following, to make sure
>> we flush the list at most every BITS_PER_LONG files
> 
> Hmm.
> 
> I'm wondering if we should just make close_files() (or maybe even
> filp_close()) use a synchronous fput().
> 
> Iirc, the reason we delay fput() is that we had some nasty issues for
> the generic fput case. It was called from interrupt context by the aio
> code, and just in general there's a lot of nasty cases that can cause
> the final fput to happen (so there are lockdep issues with the mmap
> locks because the last fput being from munmap etc).
> 
> Maybe I forget some detail - it's been several years by now - but I
> think we could make the regular "close()" and "exit()" cases just use
> the synchronous fput (it's called "__fput_sync()" and currently
> explicitly limited to just kernel threads).
> 
> Al?
> 
> Because it feels all kinds of stupid to add things to the task-work
> queue just to then remove it almost immediately again. And
> close_files() is also called from various contexts. but the whole "put
> the final 'files_struct' case is certainly not at all as special as
> the 'put the final file'.
> 
>Linus
> —
why not provide API like:
fput()
fput_nosync() ?

because synchronous version are reasonable and safe in most time,
let the user to select which version to use is more feasible, no matter if it 
is kthread or not.

Thanks


--
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] arm64: add kc_offset_to_vaddr and kc_vaddr_to_offset macro

[yalin wang]

This patch add kc_offset_to_vaddr() and kc_vaddr_to_offset(),
the default version doesn't work on arm64, because arm64 kernel address
is below the PAGE_OFFSET, like module address and vmemmap address are
all below PAGE_OFFSET address.

Signed-off-by: yalin wang 
---
 arch/arm64/include/asm/pgtable.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index d374191..ef1ed5c 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -660,6 +660,8 @@ static inline void update_mmu_cache(struct vm_area_struct 
*vma,
 
 #define update_mmu_cache_pmd(vma, address, pmd) do { } while (0)
 
+#definekc_vaddr_to_offset(v) ((v) & ((1UL << VA_BITS) - 1))
+#definekc_offset_to_vaddr(o) ((o) | ~((1UL << VA_BITS) - 1))
 #endif /* !__ASSEMBLY__ */
 
 #endif /* __ASM_PGTABLE_H */
-- 
1.9.1

--
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] arm64: add kc_offset_to_vaddr and kc_vaddr_to_offset macro

[yalin wang]

This patch add kc_offset_to_vaddr() and kc_vaddr_to_offset(),
the default version doesn't work on arm64, because arm64 kernel address
is below the PAGE_OFFSET, like module address and vmemmap address are
all below PAGE_OFFSET address.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 arch/arm64/include/asm/pgtable.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index d374191..ef1ed5c 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -660,6 +660,8 @@ static inline void update_mmu_cache(struct vm_area_struct 
*vma,
 
 #define update_mmu_cache_pmd(vma, address, pmd) do { } while (0)
 
+#definekc_vaddr_to_offset(v) ((v)  ((1UL  VA_BITS) - 1))
+#definekc_offset_to_vaddr(o) ((o) | ~((1UL  VA_BITS) - 1))
 #endif /* !__ASSEMBLY__ */
 
 #endif /* __ASM_PGTABLE_H */
-- 
1.9.1

--
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] task_work: remove fifo ordering guarantee

[yalin wang]

 On Aug 30, 2015, at 01:08, Linus Torvalds torva...@linux-foundation.org 
 wrote:
 
 On Sat, Aug 29, 2015 at 7:11 AM, Eric Dumazet eric.duma...@gmail.com wrote:
 
 If this needs to be kept, maybe then add following, to make sure
 we flush the list at most every BITS_PER_LONG files
 
 Hmm.
 
 I'm wondering if we should just make close_files() (or maybe even
 filp_close()) use a synchronous fput().
 
 Iirc, the reason we delay fput() is that we had some nasty issues for
 the generic fput case. It was called from interrupt context by the aio
 code, and just in general there's a lot of nasty cases that can cause
 the final fput to happen (so there are lockdep issues with the mmap
 locks because the last fput being from munmap etc).
 
 Maybe I forget some detail - it's been several years by now - but I
 think we could make the regular close() and exit() cases just use
 the synchronous fput (it's called __fput_sync() and currently
 explicitly limited to just kernel threads).
 
 Al?
 
 Because it feels all kinds of stupid to add things to the task-work
 queue just to then remove it almost immediately again. And
 close_files() is also called from various contexts. but the whole put
 the final 'files_struct' case is certainly not at all as special as
 the 'put the final file'.
 
Linus
 —
why not provide API like:
fput()
fput_nosync() ?

because synchronous version are reasonable and safe in most time,
let the user to select which version to use is more feasible, no matter if it 
is kthread or not.

Thanks


--
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] arm64: ioremap: change ioremap prototype and add ioremap_cache macro

[yalin wang]

This patch change ioremap_*() first parameter type to resource_size_t to
be the same as other platforms, and add ioremap_cache macro,
because some code will test if this macro is defined or not, and
will generate a generric version if not defined, for example,
memremap.c do like this.

Signed-off-by: yalin wang 
---
 arch/arm64/include/asm/io.h | 5 +++--
 arch/arm64/mm/ioremap.c | 6 +++---
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 44be1e0..500e09f 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -163,15 +163,16 @@ extern void __memset_io(volatile void __iomem *, int, 
size_t);
 /*
  * I/O memory mapping functions.
  */
-extern void __iomem *__ioremap(phys_addr_t phys_addr, size_t size, pgprot_t 
prot);
+extern void __iomem *__ioremap(resource_size_t phys_addr, size_t size, 
pgprot_t prot);
 extern void __iounmap(volatile void __iomem *addr);
-extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
+extern void __iomem *ioremap_cache(resource_size_t phys_addr, size_t size);
 
 #define ioremap(addr, size)__ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
 #define ioremap_nocache(addr, size)__ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
 #define ioremap_wc(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_NORMAL_NC))
 #define ioremap_wt(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
 #define iounmap__iounmap
+#define ioremap_cache  ioremap_cache
 
 /*
  * io{read,write}{16,32}be() macros
diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
index 01e88c8..082e963 100644
--- a/arch/arm64/mm/ioremap.c
+++ b/arch/arm64/mm/ioremap.c
@@ -29,7 +29,7 @@
 #include 
 #include 
 
-static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
+static void __iomem *__ioremap_caller(resource_size_t phys_addr, size_t size,
  pgprot_t prot, void *caller)
 {
unsigned long last_addr;
@@ -73,7 +73,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, 
size_t size,
return (void __iomem *)(offset + addr);
 }
 
-void __iomem *__ioremap(phys_addr_t phys_addr, size_t size, pgprot_t prot)
+void __iomem *__ioremap(resource_size_t phys_addr, size_t size, pgprot_t prot)
 {
return __ioremap_caller(phys_addr, size, prot,
__builtin_return_address(0));
@@ -93,7 +93,7 @@ void __iounmap(volatile void __iomem *io_addr)
 }
 EXPORT_SYMBOL(__iounmap);
 
-void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
+void __iomem *ioremap_cache(resource_size_t phys_addr, size_t size)
 {
/* For normal memory we already have a cacheable mapping. */
if (pfn_valid(__phys_to_pfn(phys_addr)))
-- 
1.9.1

--
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] arm64: ioremap: change ioremap prototype and add ioremap_cache macro

[yalin wang]

This patch change ioremap_*() first parameter type to resource_size_t to
be the same as other platforms, and add ioremap_cache macro,
because some code will test if this macro is defined or not, and
will generate a generric version if not defined, for example,
memremap.c do like this.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 arch/arm64/include/asm/io.h | 5 +++--
 arch/arm64/mm/ioremap.c | 6 +++---
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 44be1e0..500e09f 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -163,15 +163,16 @@ extern void __memset_io(volatile void __iomem *, int, 
size_t);
 /*
  * I/O memory mapping functions.
  */
-extern void __iomem *__ioremap(phys_addr_t phys_addr, size_t size, pgprot_t 
prot);
+extern void __iomem *__ioremap(resource_size_t phys_addr, size_t size, 
pgprot_t prot);
 extern void __iounmap(volatile void __iomem *addr);
-extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
+extern void __iomem *ioremap_cache(resource_size_t phys_addr, size_t size);
 
 #define ioremap(addr, size)__ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
 #define ioremap_nocache(addr, size)__ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
 #define ioremap_wc(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_NORMAL_NC))
 #define ioremap_wt(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
 #define iounmap__iounmap
+#define ioremap_cache  ioremap_cache
 
 /*
  * io{read,write}{16,32}be() macros
diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
index 01e88c8..082e963 100644
--- a/arch/arm64/mm/ioremap.c
+++ b/arch/arm64/mm/ioremap.c
@@ -29,7 +29,7 @@
 #include asm/tlbflush.h
 #include asm/pgalloc.h
 
-static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
+static void __iomem *__ioremap_caller(resource_size_t phys_addr, size_t size,
  pgprot_t prot, void *caller)
 {
unsigned long last_addr;
@@ -73,7 +73,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, 
size_t size,
return (void __iomem *)(offset + addr);
 }
 
-void __iomem *__ioremap(phys_addr_t phys_addr, size_t size, pgprot_t prot)
+void __iomem *__ioremap(resource_size_t phys_addr, size_t size, pgprot_t prot)
 {
return __ioremap_caller(phys_addr, size, prot,
__builtin_return_address(0));
@@ -93,7 +93,7 @@ void __iounmap(volatile void __iomem *io_addr)
 }
 EXPORT_SYMBOL(__iounmap);
 
-void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
+void __iomem *ioremap_cache(resource_size_t phys_addr, size_t size)
 {
/* For normal memory we already have a cacheable mapping. */
if (pfn_valid(__phys_to_pfn(phys_addr)))
-- 
1.9.1

--
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: Problems loading firmware using built-in drivers with kernels that use initramfs.

[yalin wang]

> On Aug 26, 2015, at 04:26, Linus Torvalds  
> wrote:
> 
> On Tue, Aug 25, 2015 at 12:58 PM, Dmitry Torokhov
>  wrote:
>> 
>> Either build firmware in the kernel or ramdisk (so it is always
>> available), or make sure request_firmware() calls are not in driver's
>> probe() paths.
> 
> The correct answer is almost always that second one.
> 
> Drivers that load firmware in their probe parts are generally doign
> things wrong.
> 
> It's very occasionally the right thing to do - there are a few pieces
> of hardware where just about _everything_ about the device is in the
> firmware, and you simply can't even problem them before that, because
> you don't know what they *are* before the firmware has been loaded.
> The extreme case of that might be something like the base hardware
> being an FPGA that has a USB interface, but before the FPGA has been
> loaded, it basically has no identity. So there are probably valid
> cases in theory for loading firmware at probe time, but pretty much
> every single case I've ever actually seen, the probe knows what the
> actual hardware is from some identifiable piece, and the actual
> firmware loading should be delayed until the piece of hardware is
> actually opened.
> 
> So the "load firmware in probe routine" happens, and we shouldn't
> disallow it, but it should be considered a "last resort" kind of
> thing.
> 
> In general, things like sound drivers should *not* need to have their
> firmware in the initrd, even if you build them into the kernel. A disk
> driver? Yes. Maybe the root filesystem is on that disk, and you need
> the firmware for the disk driver to load it. But a sound device?
> Please just make sure that you load the firmware as late as possible.
> 
i remember lots of drivers load their firmware when some user space process
open the device node, that is to say, they load the firmware in 
->open() function, at this time , you can make sure the real filesystem is 
ready in
most time.  

i think your dsp firmware can also do like this.
you can refer to msm gnu driver:

static void load_gpu(struct drm_device *dev)
{
static DEFINE_MUTEX(init_lock);
struct msm_drm_private *priv = dev->dev_private;

mutex_lock(_lock);

if (!priv->gpu)
priv->gpu = adreno_load_gpu(dev);

mutex_unlock(_lock);
}

static int msm_open(struct drm_device *dev, struct drm_file *file)
{
struct msm_file_private *ctx;

/* For now, load gpu on open.. to avoid the requirement of having
 * firmware in the initrd.
 */
load_gpu(dev);

ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;

file->driver_priv = ctx;

return 0;
}
it load the firmware in open() function.

Thanks











--
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] arm: insn: use set_fixmap_offset to make it more clear

[yalin wang]

A little change to patch_map() function,
use set_fixmap_offset() to make code more clear.

Signed-off-by: yalin wang 
---
 arch/arm/kernel/patch.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c
index 69bda1a..5779105 100644
--- a/arch/arm/kernel/patch.c
+++ b/arch/arm/kernel/patch.c
@@ -36,9 +36,8 @@ static void __kprobes *patch_map(void *addr, int fixmap, 
unsigned long *flags)
else
__acquire(_lock);
 
-   set_fixmap(fixmap, page_to_phys(page));
-
-   return (void *) (__fix_to_virt(fixmap) + (uintaddr & ~PAGE_MASK));
+   return (void *)set_fixmap_offset(fixmap, page_to_phys(page) +
+   (uintaddr & ~PAGE_MASK));
 }
 
 static void __kprobes patch_unmap(int fixmap, unsigned long *flags)
-- 
1.9.1

--
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] dma/ipu: change ipu_irq_handler() to remove compile warning

[yalin wang]

> On Aug 25, 2015, at 16:07, Thomas Gleixner  wrote:
> 
> On Tue, 25 Aug 2015, yalin wang wrote:
>> Change ipu_irq_handler() to avoid gcc warning:
>> 
>> drivers/dma/ipu/ipu_irq.c:305:4: warning: 'irq' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>>generic_handle_irq(irq);
> 
> That's a false positive from GCC. irq is always initialized when
> generic_handle_irq() is called.
> 
>> Signed-off-by: yalin wang 
>> ---
>> drivers/dma/ipu/ipu_irq.c | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
>> index 7489d2a..1a74eee 100644
>> --- a/drivers/dma/ipu/ipu_irq.c
>> +++ b/drivers/dma/ipu/ipu_irq.c
>> @@ -286,23 +286,21 @@ static void ipu_irq_handler(unsigned int __irq, struct 
>> irq_desc *desc)
>>  raw_spin_unlock(_lock);
>>  while ((line = ffs(status))) {
>>  struct ipu_irq_map *map;
>> -unsigned int irq;
>> 
>>  line--;
>>  status &= ~(1UL << line);
>> 
>>  raw_spin_lock(_lock);
>>  map = src2map(32 * i + line);
>> -if (map)
>> -irq = map->irq;
>>  raw_spin_unlock(_lock);
>> 
>>  if (!map) {
>>  pr_err("IPU: Interrupt on unmapped source %u 
>> bank %d\n",
>> line, i);
>>  continue;
>> +} else {
>> +generic_handle_irq(map->irq);
> 
> So you change that from retrieving the irq number with bank lock held
> to an unprotected access.

i see,
i will send a V2 patch .

--
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 V2] dma/ipu: change ipu_irq_handler() to remove compile warning

[yalin wang]

Change ipu_irq_handler() to avoid gcc warning:

drivers/dma/ipu/ipu_irq.c:305:4: warning: 'irq' may be used
uninitialized in this function [-Wmaybe-uninitialized]
generic_handle_irq(irq);

Signed-off-by: yalin wang 
---
 drivers/dma/ipu/ipu_irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
index 7489d2a..4768a82 100644
--- a/drivers/dma/ipu/ipu_irq.c
+++ b/drivers/dma/ipu/ipu_irq.c
@@ -286,7 +286,7 @@ static void ipu_irq_handler(unsigned int __irq, struct 
irq_desc *desc)
raw_spin_unlock(_lock);
while ((line = ffs(status))) {
struct ipu_irq_map *map;
-   unsigned int irq;
+   unsigned int irq = NO_IRQ;
 
line--;
status &= ~(1UL << line);
-- 
1.9.1

--
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] dma/ipu: change ipu_irq_handler() to remove compile warning

[yalin wang]

Change ipu_irq_handler() to avoid gcc warning:

drivers/dma/ipu/ipu_irq.c:305:4: warning: 'irq' may be used
uninitialized in this function [-Wmaybe-uninitialized]
generic_handle_irq(irq);

Signed-off-by: yalin wang 
---
 drivers/dma/ipu/ipu_irq.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
index 7489d2a..1a74eee 100644
--- a/drivers/dma/ipu/ipu_irq.c
+++ b/drivers/dma/ipu/ipu_irq.c
@@ -286,23 +286,21 @@ static void ipu_irq_handler(unsigned int __irq, struct 
irq_desc *desc)
raw_spin_unlock(_lock);
while ((line = ffs(status))) {
struct ipu_irq_map *map;
-   unsigned int irq;
 
line--;
status &= ~(1UL << line);
 
raw_spin_lock(_lock);
map = src2map(32 * i + line);
-   if (map)
-   irq = map->irq;
raw_spin_unlock(_lock);
 
if (!map) {
pr_err("IPU: Interrupt on unmapped source %u 
bank %d\n",
   line, i);
continue;
+   } else {
+   generic_handle_irq(map->irq);
}
-   generic_handle_irq(irq);
}
}
 }
-- 
1.9.1

--
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/

[RFC] arm: change some function and data to init section

[yalin wang]

This patch change some function and the related data to init section,
they are only called by free_initmem(), can be freed safely after
boot up.

Signed-off-by: yalin wang 
---
 arch/arm/mm/init.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 8a63b4c..7b505de 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -577,7 +577,7 @@ struct section_perm {
pmdval_t clear;
 };
 
-static struct section_perm nx_perms[] = {
+static struct section_perm nx_perms[] __initdata = {
/* Make pages tables, etc before _stext RW (set NX). */
{
.start  = PAGE_OFFSET,
@@ -680,7 +680,7 @@ static inline bool arch_has_strict_perms(void)
}   \
 }
 
-static inline void fix_kernmem_perms(void)
+static void __init fix_kernmem_perms(void)
 {
set_section_perms(nx_perms, prot);
 }
@@ -706,7 +706,7 @@ void set_kernel_text_ro(void)
 static inline void fix_kernmem_perms(void) { }
 #endif /* CONFIG_ARM_KERNMEM_PERMS */
 
-void free_tcmmem(void)
+static void __init free_tcmmem(void)
 {
 #ifdef CONFIG_HAVE_TCM
extern char __tcm_start, __tcm_end;
@@ -716,7 +716,7 @@ void free_tcmmem(void)
 #endif
 }
 
-void free_initmem(void)
+void __init_refok free_initmem(void)
 {
fix_kernmem_perms();
free_tcmmem();
@@ -728,9 +728,9 @@ void free_initmem(void)
 
 #ifdef CONFIG_BLK_DEV_INITRD
 
-static int keep_initrd;
+static int keep_initrd __initdata;
 
-void free_initrd_mem(unsigned long start, unsigned long end)
+void __init free_initrd_mem(unsigned long start, unsigned long end)
 {
if (!keep_initrd) {
if (start == initrd_start)
-- 
1.9.1

--
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: Problems loading firmware using built-in drivers with kernels that use initramfs.

[yalin wang]

 On Aug 26, 2015, at 04:26, Linus Torvalds torva...@linux-foundation.org 
 wrote:
 
 On Tue, Aug 25, 2015 at 12:58 PM, Dmitry Torokhov
 dmitry.torok...@gmail.com wrote:
 
 Either build firmware in the kernel or ramdisk (so it is always
 available), or make sure request_firmware() calls are not in driver's
 probe() paths.
 
 The correct answer is almost always that second one.
 
 Drivers that load firmware in their probe parts are generally doign
 things wrong.
 
 It's very occasionally the right thing to do - there are a few pieces
 of hardware where just about _everything_ about the device is in the
 firmware, and you simply can't even problem them before that, because
 you don't know what they *are* before the firmware has been loaded.
 The extreme case of that might be something like the base hardware
 being an FPGA that has a USB interface, but before the FPGA has been
 loaded, it basically has no identity. So there are probably valid
 cases in theory for loading firmware at probe time, but pretty much
 every single case I've ever actually seen, the probe knows what the
 actual hardware is from some identifiable piece, and the actual
 firmware loading should be delayed until the piece of hardware is
 actually opened.
 
 So the load firmware in probe routine happens, and we shouldn't
 disallow it, but it should be considered a last resort kind of
 thing.
 
 In general, things like sound drivers should *not* need to have their
 firmware in the initrd, even if you build them into the kernel. A disk
 driver? Yes. Maybe the root filesystem is on that disk, and you need
 the firmware for the disk driver to load it. But a sound device?
 Please just make sure that you load the firmware as late as possible.
 
i remember lots of drivers load their firmware when some user space process
open the device node, that is to say, they load the firmware in 
-open() function, at this time , you can make sure the real filesystem is 
ready in
most time.  

i think your dsp firmware can also do like this.
you can refer to msm gnu driver:

static void load_gpu(struct drm_device *dev)
{
static DEFINE_MUTEX(init_lock);
struct msm_drm_private *priv = dev-dev_private;

mutex_lock(init_lock);

if (!priv-gpu)
priv-gpu = adreno_load_gpu(dev);

mutex_unlock(init_lock);
}

static int msm_open(struct drm_device *dev, struct drm_file *file)
{
struct msm_file_private *ctx;

/* For now, load gpu on open.. to avoid the requirement of having
 * firmware in the initrd.
 */
load_gpu(dev);

ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;

file-driver_priv = ctx;

return 0;
}
it load the firmware in open() function.

Thanks











--
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/

[RFC] arm: change some function and data to init section

[yalin wang]

This patch change some function and the related data to init section,
they are only called by free_initmem(), can be freed safely after
boot up.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 arch/arm/mm/init.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 8a63b4c..7b505de 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -577,7 +577,7 @@ struct section_perm {
pmdval_t clear;
 };
 
-static struct section_perm nx_perms[] = {
+static struct section_perm nx_perms[] __initdata = {
/* Make pages tables, etc before _stext RW (set NX). */
{
.start  = PAGE_OFFSET,
@@ -680,7 +680,7 @@ static inline bool arch_has_strict_perms(void)
}   \
 }
 
-static inline void fix_kernmem_perms(void)
+static void __init fix_kernmem_perms(void)
 {
set_section_perms(nx_perms, prot);
 }
@@ -706,7 +706,7 @@ void set_kernel_text_ro(void)
 static inline void fix_kernmem_perms(void) { }
 #endif /* CONFIG_ARM_KERNMEM_PERMS */
 
-void free_tcmmem(void)
+static void __init free_tcmmem(void)
 {
 #ifdef CONFIG_HAVE_TCM
extern char __tcm_start, __tcm_end;
@@ -716,7 +716,7 @@ void free_tcmmem(void)
 #endif
 }
 
-void free_initmem(void)
+void __init_refok free_initmem(void)
 {
fix_kernmem_perms();
free_tcmmem();
@@ -728,9 +728,9 @@ void free_initmem(void)
 
 #ifdef CONFIG_BLK_DEV_INITRD
 
-static int keep_initrd;
+static int keep_initrd __initdata;
 
-void free_initrd_mem(unsigned long start, unsigned long end)
+void __init free_initrd_mem(unsigned long start, unsigned long end)
 {
if (!keep_initrd) {
if (start == initrd_start)
-- 
1.9.1

--
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] dma/ipu: change ipu_irq_handler() to remove compile warning

[yalin wang]

Change ipu_irq_handler() to avoid gcc warning:

drivers/dma/ipu/ipu_irq.c:305:4: warning: 'irq' may be used
uninitialized in this function [-Wmaybe-uninitialized]
generic_handle_irq(irq);

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/dma/ipu/ipu_irq.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
index 7489d2a..1a74eee 100644
--- a/drivers/dma/ipu/ipu_irq.c
+++ b/drivers/dma/ipu/ipu_irq.c
@@ -286,23 +286,21 @@ static void ipu_irq_handler(unsigned int __irq, struct 
irq_desc *desc)
raw_spin_unlock(bank_lock);
while ((line = ffs(status))) {
struct ipu_irq_map *map;
-   unsigned int irq;
 
line--;
status = ~(1UL  line);
 
raw_spin_lock(bank_lock);
map = src2map(32 * i + line);
-   if (map)
-   irq = map-irq;
raw_spin_unlock(bank_lock);
 
if (!map) {
pr_err(IPU: Interrupt on unmapped source %u 
bank %d\n,
   line, i);
continue;
+   } else {
+   generic_handle_irq(map-irq);
}
-   generic_handle_irq(irq);
}
}
 }
-- 
1.9.1

--
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 V2] dma/ipu: change ipu_irq_handler() to remove compile warning

[yalin wang]

Change ipu_irq_handler() to avoid gcc warning:

drivers/dma/ipu/ipu_irq.c:305:4: warning: 'irq' may be used
uninitialized in this function [-Wmaybe-uninitialized]
generic_handle_irq(irq);

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/dma/ipu/ipu_irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
index 7489d2a..4768a82 100644
--- a/drivers/dma/ipu/ipu_irq.c
+++ b/drivers/dma/ipu/ipu_irq.c
@@ -286,7 +286,7 @@ static void ipu_irq_handler(unsigned int __irq, struct 
irq_desc *desc)
raw_spin_unlock(bank_lock);
while ((line = ffs(status))) {
struct ipu_irq_map *map;
-   unsigned int irq;
+   unsigned int irq = NO_IRQ;
 
line--;
status = ~(1UL  line);
-- 
1.9.1

--
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] dma/ipu: change ipu_irq_handler() to remove compile warning

[yalin wang]

 On Aug 25, 2015, at 16:07, Thomas Gleixner t...@linutronix.de wrote:
 
 On Tue, 25 Aug 2015, yalin wang wrote:
 Change ipu_irq_handler() to avoid gcc warning:
 
 drivers/dma/ipu/ipu_irq.c:305:4: warning: 'irq' may be used
 uninitialized in this function [-Wmaybe-uninitialized]
generic_handle_irq(irq);
 
 That's a false positive from GCC. irq is always initialized when
 generic_handle_irq() is called.
 
 Signed-off-by: yalin wang yalin.wang2...@gmail.com
 ---
 drivers/dma/ipu/ipu_irq.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
 index 7489d2a..1a74eee 100644
 --- a/drivers/dma/ipu/ipu_irq.c
 +++ b/drivers/dma/ipu/ipu_irq.c
 @@ -286,23 +286,21 @@ static void ipu_irq_handler(unsigned int __irq, struct 
 irq_desc *desc)
  raw_spin_unlock(bank_lock);
  while ((line = ffs(status))) {
  struct ipu_irq_map *map;
 -unsigned int irq;
 
  line--;
  status = ~(1UL  line);
 
  raw_spin_lock(bank_lock);
  map = src2map(32 * i + line);
 -if (map)
 -irq = map-irq;
  raw_spin_unlock(bank_lock);
 
  if (!map) {
  pr_err(IPU: Interrupt on unmapped source %u 
 bank %d\n,
 line, i);
  continue;
 +} else {
 +generic_handle_irq(map-irq);
 
 So you change that from retrieving the irq number with bank lock held
 to an unprotected access.

i see,
i will send a V2 patch .

--
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] arm: insn: use set_fixmap_offset to make it more clear

[yalin wang]

A little change to patch_map() function,
use set_fixmap_offset() to make code more clear.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 arch/arm/kernel/patch.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c
index 69bda1a..5779105 100644
--- a/arch/arm/kernel/patch.c
+++ b/arch/arm/kernel/patch.c
@@ -36,9 +36,8 @@ static void __kprobes *patch_map(void *addr, int fixmap, 
unsigned long *flags)
else
__acquire(patch_lock);
 
-   set_fixmap(fixmap, page_to_phys(page));
-
-   return (void *) (__fix_to_virt(fixmap) + (uintaddr  ~PAGE_MASK));
+   return (void *)set_fixmap_offset(fixmap, page_to_phys(page) +
+   (uintaddr  ~PAGE_MASK));
 }
 
 static void __kprobes patch_unmap(int fixmap, unsigned long *flags)
-- 
1.9.1

--
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] ipmi: add of_device_id in MODULE_DEVICE_TABLE

[yalin wang]

> On Aug 25, 2015, at 08:48, Corey Minyard  wrote:
> 
> Well, I should have compile tested first.  On x86_64:
> 
> 
>  CC [M]  drivers/char/ipmi/ipmi_si_intf.o
> In file included from ../drivers/char/ipmi/ipmi_si_intf.c:42:0:
> ../drivers/char/ipmi/ipmi_si_intf.c:2804:25: error: ‘ipmi_match’
> undeclared here (not in a function)
> MODULE_DEVICE_TABLE(of, ipmi_match);
> ^
> ../include/linux/module.h:223:21: note: in definition of macro
> ‘MODULE_DEVICE_TABLE’
> extern const typeof(name) __mod_##type##__##name##_device_table \
> ^
> ../include/linux/module.h:223:27: error:
> ‘__mod_of__ipmi_match_device_table’ aliased to undefined symbol ‘ipmi_match’
> extern const typeof(name) __mod_##type##__##name##_device_table \
>   ^
> ../drivers/char/ipmi/ipmi_si_intf.c:2804:1: note: in expansion of macro
> ‘MODULE_DEVICE_TABLE’
> MODULE_DEVICE_TABLE(of, ipmi_match);
> 
> 
> This has to compile on all arches.  I'm not sure what is wrong, but I've
> removed the patch.
> 
> -corey
it seems should be :

MODULE_DEVICE_TABLE(of, of_ipmi_match);
--
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: [RFC] fbdev/riva:change to use generice function to implement reverse_order()

[yalin wang]

> On Aug 22, 2015, at 15:53, Afzal Mohammed  wrote:
> 
> Hi,
> 
> On Fri, Aug 21, 2015 at 11:01:41AM +0300, Tomi Valkeinen wrote:
> 
 Possibly the patches are still good for x86 also, but that needs to be
 proven.
 
>>> not exactly, because x86_64 don’t have hardware instruction to do rbit OP,
>>> i compile by test :
>> 
>> For old drivers i386 may be more relevant than x86_64.
> 
> It seems asm bit reversal is supported in Kernel on arm & arm64 only,
> not sure whether any other arch even provide asm bit reversal
> instruction.

i only submit the bit reverse patch for arm / arm64 arch,
i am not sure if there are some other arch also have hard ware bit reverse 
instructions, need arch maintainers to submit if their arch also have these hard
ware instructions . :)

> 
>> These kind of optimizations should have some real world measurements,
> 
> Not for this case, but once measured on ARM, iirc, a 32-bit asm bit
> reversal as compared to doing it in C was taking 1 cycle as opposed to
> ~225 cycles!, of course writing optimized C could have made it fare
> better, but still would reach no-way near asm bit reversal.
> 


--
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: [x86] copy_from{to}_user question

[yalin wang]

> On Aug 22, 2015, at 17:05, Borislav Petkov  wrote:
> 
> On Fri, Aug 21, 2015 at 02:06:16PM -0700, H. Peter Anvin wrote:
>> What I'm saying is that we do do STAC, which *disables* SMAP.  We have
>> to do that because one pointer is known to be a user space pointer.
>> 
>> However, we currently don't verify that the *other* pointer is kernel
>> space, which it is supposed to be (if not, we should be using
>> copy_in_user).  We have to do this manually since we have to STAC which
>> means SMAP doesn't do anything at all.  I believe it would be a good
>> idea to add such checks (and they would even benefit non-SMAP hardware.)
> 
> Ah, ok, so we're on the same page.
> 
> And yep, Linus gave the probe_kernel_read() suggestion in another mail.
> 
i am not clear about what is STAC / SMAP ?
could you give me a link for understanding ?

Linus suggest to use probe_kernel_read() , but also said it is 
not efficient to use it, because we need copy the data 2 times by this method.

my patch suggests to use copy_in_user() ,
but seems not a generic(portable) function on all architectures.

Thanks--
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: [x86] copy_from{to}_user question

[yalin wang]

 On Aug 22, 2015, at 17:05, Borislav Petkov b...@suse.de wrote:
 
 On Fri, Aug 21, 2015 at 02:06:16PM -0700, H. Peter Anvin wrote:
 What I'm saying is that we do do STAC, which *disables* SMAP.  We have
 to do that because one pointer is known to be a user space pointer.
 
 However, we currently don't verify that the *other* pointer is kernel
 space, which it is supposed to be (if not, we should be using
 copy_in_user).  We have to do this manually since we have to STAC which
 means SMAP doesn't do anything at all.  I believe it would be a good
 idea to add such checks (and they would even benefit non-SMAP hardware.)
 
 Ah, ok, so we're on the same page.
 
 And yep, Linus gave the probe_kernel_read() suggestion in another mail.
 
i am not clear about what is STAC / SMAP ?
could you give me a link for understanding ?

Linus suggest to use probe_kernel_read() , but also said it is 
not efficient to use it, because we need copy the data 2 times by this method.

my patch suggests to use copy_in_user() ,
but seems not a generic(portable) function on all architectures.

Thanks--
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: [RFC] fbdev/riva:change to use generice function to implement reverse_order()

[yalin wang]

 On Aug 22, 2015, at 15:53, Afzal Mohammed afzal.mohd...@gmail.com wrote:
 
 Hi,
 
 On Fri, Aug 21, 2015 at 11:01:41AM +0300, Tomi Valkeinen wrote:
 
 Possibly the patches are still good for x86 also, but that needs to be
 proven.
 
 not exactly, because x86_64 don’t have hardware instruction to do rbit OP,
 i compile by test :
 
 For old drivers i386 may be more relevant than x86_64.
 
 It seems asm bit reversal is supported in Kernel on arm  arm64 only,
 not sure whether any other arch even provide asm bit reversal
 instruction.

i only submit the bit reverse patch for arm / arm64 arch,
i am not sure if there are some other arch also have hard ware bit reverse 
instructions, need arch maintainers to submit if their arch also have these hard
ware instructions . :)

 
 These kind of optimizations should have some real world measurements,
 
 Not for this case, but once measured on ARM, iirc, a 32-bit asm bit
 reversal as compared to doing it in C was taking 1 cycle as opposed to
 ~225 cycles!, of course writing optimized C could have made it fare
 better, but still would reach no-way near asm bit reversal.
 


--
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] ipmi: add of_device_id in MODULE_DEVICE_TABLE

[yalin wang]

 On Aug 25, 2015, at 08:48, Corey Minyard miny...@acm.org wrote:
 
 Well, I should have compile tested first.  On x86_64:
 
 
  CC [M]  drivers/char/ipmi/ipmi_si_intf.o
 In file included from ../drivers/char/ipmi/ipmi_si_intf.c:42:0:
 ../drivers/char/ipmi/ipmi_si_intf.c:2804:25: error: ‘ipmi_match’
 undeclared here (not in a function)
 MODULE_DEVICE_TABLE(of, ipmi_match);
 ^
 ../include/linux/module.h:223:21: note: in definition of macro
 ‘MODULE_DEVICE_TABLE’
 extern const typeof(name) __mod_##type##__##name##_device_table \
 ^
 ../include/linux/module.h:223:27: error:
 ‘__mod_of__ipmi_match_device_table’ aliased to undefined symbol ‘ipmi_match’
 extern const typeof(name) __mod_##type##__##name##_device_table \
   ^
 ../drivers/char/ipmi/ipmi_si_intf.c:2804:1: note: in expansion of macro
 ‘MODULE_DEVICE_TABLE’
 MODULE_DEVICE_TABLE(of, ipmi_match);
 
 
 This has to compile on all arches.  I'm not sure what is wrong, but I've
 removed the patch.
 
 -corey
it seems should be :

MODULE_DEVICE_TABLE(of, of_ipmi_match);
--
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: [RFC] fbdev/riva:change to use generice function to implement reverse_order()

[yalin wang]

> On Aug 21, 2015, at 14:41, Tomi Valkeinen  wrote:
> 
> 
> 
> On 20/08/15 14:30, yalin wang wrote:
>> 
>>> On Aug 20, 2015, at 19:02, Tomi Valkeinen  wrote:
>>> 
>>> 
>>> On 10/08/15 13:12, yalin wang wrote:
>>>> This change to use swab32(bitrev32()) to implement reverse_order()
>>>> function, have better performance on some platforms.
>>> 
>>> Which platforms? Presuming you tested this, roughly how much better
>>> performance? If you didn't, how do you know it's faster?
>> 
>> i investigate on arm64 platforms:
> 
> Ok. So is any arm64 platform actually using these devices? If these
> devices are mostly used by 32bit x86 platforms, optimizing them for
> arm64 doesn't make any sense.
> 
> Possibly the patches are still good for x86 also, but that needs to be
> proven.
> 
not exactly, because x86_64 don’t have hardware instruction to do rbit OP,
i compile by test :

use the patch:
  use swab32(bitrev32()):
  2775:   0f b6 d0movzbl %al,%edx   

 
  2778:   0f b6 c4movzbl %ah,%eax
  277b:   0f b6 92 00 00 00 00movzbl 0x0(%rdx),%edx
  2782:   0f b6 80 00 00 00 00movzbl 0x0(%rax),%eax
  2789:   c1 e2 08shl$0x8,%edx
  278c:   09 d0   or %edx,%eax
  278e:   0f b6 d5movzbl %ch,%edx
  2791:   0f b6 c9movzbl %cl,%ecx
  2794:   0f b6 89 00 00 00 00movzbl 0x0(%rcx),%ecx
  279b:   0f b6 92 00 00 00 00movzbl 0x0(%rdx),%edx
  27a2:   0f b7 c0movzwl %ax,%eax
  27a5:   c1 e1 08shl$0x8,%ecx
  27a8:   09 ca   or %ecx,%edx
  27aa:   c1 e2 10shl$0x10,%edx
  27ad:   09 d0   or %edx,%eax
  27af:   45 85 fftest   %r15d,%r15d
  27b2:   0f c8   bswap  %eax
4 memory access instructions,



without the patch:
use
do {\
-   u8 *a = (u8 *)(l);  \
-   a[0] = bitrev8(a[0]);   \
-   a[1] = bitrev8(a[1]);   \
-   a[2] = bitrev8(a[2]);   \
-   a[3] = bitrev8(a[3]);   \
-} while(0)



277b:   45 0f b6 80 00 00 00movzbl 0x0(%r8),%r8d
2782:   00 
2783:   c1 ee 10shr$0x10,%esi
2786:   89 f2   mov%esi,%edx
2788:   0f b6 f4movzbl %ah,%esi
278b:   c1 e8 18shr$0x18,%eax
278e:   0f b6 d2movzbl %dl,%edx
2791:   48 98   cltq   
2793:   45 85 edtest   %r13d,%r13d
2796:   0f b6 92 00 00 00 00movzbl 0x0(%rdx),%edx
279d:   0f b6 80 00 00 00 00movzbl 0x0(%rax),%eax
27a4:   44 88 85 54 ff ff ffmov%r8b,-0xac(%rbp)
27ab:   44 0f b6 86 00 00 00movzbl 0x0(%rsi),%r8d
27b2:   00 
27b3:   88 95 56 ff ff ff   mov%dl,-0xaa(%rbp)
27b9:   88 85 57 ff ff ff   mov%al,-0xa9(%rbp)
27bf:   44 88 85 55 ff ff ffmov%r8b,-0xab(%rbp)

6 memory access instructions, and generate more code that the patch .

because the original code use byte access 4 times , i don’t
think have better performance. :)

Thanks






--
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/

[RFC V2] fbdev/riva:change to use generice function to implement reverse_order()

[yalin wang]

This change to use swab32(bitrev32()) to implement reverse_order()
function, have better performance on some platforms.

Signed-off-by: yalin wang 
---
 drivers/video/fbdev/riva/fbdev.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index f1ad274..ccf0f82 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #ifdef CONFIG_PMAC_BACKLIGHT
 #include 
@@ -453,11 +454,7 @@ static inline unsigned char MISCin(struct riva_par *par)
 
 static inline void reverse_order(u32 *l)
 {
-   u8 *a = (u8 *)l;
-   a[0] = bitrev8(a[0]);
-   a[1] = bitrev8(a[1]);
-   a[2] = bitrev8(a[2]);
-   a[3] = bitrev8(a[3]);
+   *l = swab32(bitrev32(*l));
 }
 
 /* - *
-- 
1.9.1

--
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/

[RFC V2] fbdev/riva:change to use generice function to implement reverse_order()

[yalin wang]

This change to use swab32(bitrev32()) to implement reverse_order()
function, have better performance on some platforms.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/video/fbdev/riva/fbdev.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index f1ad274..ccf0f82 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -40,6 +40,7 @@
 #include linux/init.h
 #include linux/pci.h
 #include linux/backlight.h
+#include linux/swab.h
 #include linux/bitrev.h
 #ifdef CONFIG_PMAC_BACKLIGHT
 #include asm/machdep.h
@@ -453,11 +454,7 @@ static inline unsigned char MISCin(struct riva_par *par)
 
 static inline void reverse_order(u32 *l)
 {
-   u8 *a = (u8 *)l;
-   a[0] = bitrev8(a[0]);
-   a[1] = bitrev8(a[1]);
-   a[2] = bitrev8(a[2]);
-   a[3] = bitrev8(a[3]);
+   *l = swab32(bitrev32(*l));
 }
 
 /* - *
-- 
1.9.1

--
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: [RFC] fbdev/riva:change to use generice function to implement reverse_order()

[yalin wang]

 On Aug 21, 2015, at 14:41, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 
 
 
 On 20/08/15 14:30, yalin wang wrote:
 
 On Aug 20, 2015, at 19:02, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 
 
 On 10/08/15 13:12, yalin wang wrote:
 This change to use swab32(bitrev32()) to implement reverse_order()
 function, have better performance on some platforms.
 
 Which platforms? Presuming you tested this, roughly how much better
 performance? If you didn't, how do you know it's faster?
 
 i investigate on arm64 platforms:
 
 Ok. So is any arm64 platform actually using these devices? If these
 devices are mostly used by 32bit x86 platforms, optimizing them for
 arm64 doesn't make any sense.
 
 Possibly the patches are still good for x86 also, but that needs to be
 proven.
 
not exactly, because x86_64 don’t have hardware instruction to do rbit OP,
i compile by test :

use the patch:
  use swab32(bitrev32()):
  2775:   0f b6 d0movzbl %al,%edx   

 
  2778:   0f b6 c4movzbl %ah,%eax
  277b:   0f b6 92 00 00 00 00movzbl 0x0(%rdx),%edx
  2782:   0f b6 80 00 00 00 00movzbl 0x0(%rax),%eax
  2789:   c1 e2 08shl$0x8,%edx
  278c:   09 d0   or %edx,%eax
  278e:   0f b6 d5movzbl %ch,%edx
  2791:   0f b6 c9movzbl %cl,%ecx
  2794:   0f b6 89 00 00 00 00movzbl 0x0(%rcx),%ecx
  279b:   0f b6 92 00 00 00 00movzbl 0x0(%rdx),%edx
  27a2:   0f b7 c0movzwl %ax,%eax
  27a5:   c1 e1 08shl$0x8,%ecx
  27a8:   09 ca   or %ecx,%edx
  27aa:   c1 e2 10shl$0x10,%edx
  27ad:   09 d0   or %edx,%eax
  27af:   45 85 fftest   %r15d,%r15d
  27b2:   0f c8   bswap  %eax
4 memory access instructions,



without the patch:
use
do {\
-   u8 *a = (u8 *)(l);  \
-   a[0] = bitrev8(a[0]);   \
-   a[1] = bitrev8(a[1]);   \
-   a[2] = bitrev8(a[2]);   \
-   a[3] = bitrev8(a[3]);   \
-} while(0)



277b:   45 0f b6 80 00 00 00movzbl 0x0(%r8),%r8d
2782:   00 
2783:   c1 ee 10shr$0x10,%esi
2786:   89 f2   mov%esi,%edx
2788:   0f b6 f4movzbl %ah,%esi
278b:   c1 e8 18shr$0x18,%eax
278e:   0f b6 d2movzbl %dl,%edx
2791:   48 98   cltq   
2793:   45 85 edtest   %r13d,%r13d
2796:   0f b6 92 00 00 00 00movzbl 0x0(%rdx),%edx
279d:   0f b6 80 00 00 00 00movzbl 0x0(%rax),%eax
27a4:   44 88 85 54 ff ff ffmov%r8b,-0xac(%rbp)
27ab:   44 0f b6 86 00 00 00movzbl 0x0(%rsi),%r8d
27b2:   00 
27b3:   88 95 56 ff ff ff   mov%dl,-0xaa(%rbp)
27b9:   88 85 57 ff ff ff   mov%al,-0xa9(%rbp)
27bf:   44 88 85 55 ff ff ffmov%r8b,-0xab(%rbp)

6 memory access instructions, and generate more code that the patch .

because the original code use byte access 4 times , i don’t
think have better performance. :)

Thanks






--
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/

[RFC V2] fbdev/nvidia:change reverse_order() macro

[yalin wang]

This change reverse_order() to swab32(bitrev32()), so that
it can have better performance on some platforms.

Signed-off-by: yalin wang 
---
 drivers/video/fbdev/nvidia/nv_local.h | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/video/fbdev/nvidia/nv_local.h 
b/drivers/video/fbdev/nvidia/nv_local.h
index 68e508d..2c6baa1 100644
--- a/drivers/video/fbdev/nvidia/nv_local.h
+++ b/drivers/video/fbdev/nvidia/nv_local.h
@@ -97,18 +97,19 @@
 
 #ifdef __LITTLE_ENDIAN
 
+#include 
 #include 
+static inline void reverse_order(u32 *data)
+{
+   *data = swab32(bitrev32(*data));
+}
 
-#define reverse_order(l)\
-do {\
-   u8 *a = (u8 *)(l);  \
-   a[0] = bitrev8(a[0]);   \
-   a[1] = bitrev8(a[1]);   \
-   a[2] = bitrev8(a[2]);   \
-   a[3] = bitrev8(a[3]);   \
-} while(0)
 #else
-#define reverse_order(l) do { } while(0)
-#endif  /* __LITTLE_ENDIAN */
 
+static inline void reverse_order(u32 *data)
+{
+
+}
+
+#endif  /* __LITTLE_ENDIAN */
 #endif /* __NV_LOCAL_H__ */
-- 
1.9.1

--
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: [RFC] fbdev/riva:change to use generice function to implement reverse_order()

[yalin wang]

> On Aug 20, 2015, at 19:02, Tomi Valkeinen  wrote:
> 
> 
> On 10/08/15 13:12, yalin wang wrote:
>> This change to use swab32(bitrev32()) to implement reverse_order()
>> function, have better performance on some platforms.
> 
> Which platforms? Presuming you tested this, roughly how much better
> performance? If you didn't, how do you know it's faster?

i investigate on arm64 platforms:


for (j = dsize; j--;) {
tmp = data[k++];
tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
 bac:   110006a4add w4, w21, #0x1
 bb0:   5ac000a3rbitw3, w5

if (dsize) {
NVDmaStart(info, par, RECT_EXPAND_TWO_COLOR_DATA(0), dsize);

for (j = dsize; j--;) {
tmp = data[k++];
 bb4:   110006d6add w22, w22, #0x1
 bb8:   5ac00861rev w1, w3
tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
 bbc:   b9041e64str w4, [x19,#1052]
 bc0:   8b3548c2add x2, x6, w21, uxtw #2
 bc4:   b941str w1, [x2]


this is the disassemble code after apply the patch,
only need:
rbitw3, w5
rev w1, w3
2 instruction to get the reverse_order() result,
apparently after than the origianl macro code.

> 
>> Signed-off-by: yalin wang 
>> ---
>> drivers/video/fbdev/riva/fbdev.c | 19 ++-
>> 1 file changed, 6 insertions(+), 13 deletions(-)
>> 
>> diff --git a/drivers/video/fbdev/riva/fbdev.c 
>> b/drivers/video/fbdev/riva/fbdev.c
>> index f1ad274..4803901 100644
>> --- a/drivers/video/fbdev/riva/fbdev.c
>> +++ b/drivers/video/fbdev/riva/fbdev.c
>> @@ -40,6 +40,7 @@
>> #include 
>> #include 
>> #include 
>> +#include 
>> #include 
>> #ifdef CONFIG_PMAC_BACKLIGHT
>> #include 
>> @@ -84,6 +85,7 @@
>> #define SetBit(n)(1<<(n))
>> #define Set8Bits(value)  ((value)&0xff)
>> 
>> +#define reverse_order(v) swab32(bitrev32(v))
>> /* HW cursor parameters */
>> #define MAX_CURS 32
>> 
>> @@ -451,15 +453,6 @@ static inline unsigned char MISCin(struct riva_par *par)
>>  return (VGA_RD08(par->riva.PVIO, 0x3cc));
>> }
>> 
>> -static inline void reverse_order(u32 *l)
> 
> I would suggest to do the work in the inline function, instead of a
> macro. And if you keep the function prototype the same, then the changes
> to each reverse_order call site are not needed.
> 

ok, i will change to a inline function. 


--
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/

[RFC V2] fs/kcore: change copy_to_user to copy_in_user

[yalin wang]

The copy_to_user() here expect can fix the fault on both kernel and
user address, this is not true on other platforms except x86,
change to user copy_in_user() so that can detect the source and
destination address page fault, work as expected:

ENTRY(copy_user_generic_string)
ASM_STAC
cmpl $8,%edx
jb 2f   /* less than 8 bytes, go to byte copy loop */
ALIGN_DESTINATION
movl %edx,%ecx
shrl $3,%ecx
andl $7,%edx
1:  rep
movsq
2:  movl %edx,%ecx
3:  rep
movsb
xorl %eax,%eax
ASM_CLAC
ret

.section .fixup,"ax"
11: leal (%rdx,%rcx,8),%ecx
12: movl %ecx,%edx  /* ecx is zerorest also */
jmp copy_user_handle_tail
.previous

_ASM_EXTABLE(1b,11b)
_ASM_EXTABLE(3b,12b)
ENDPROC(copy_user_generic_string)

This is the x86 copy_to_user implementation, the fault instruction is
label 1b, 3b, because movsb instruction will fault on both source and
destination address, but on other platforms, like arm64 and arm:

ENTRY(__copy_to_user)
ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
CONFIG_ARM64_PAN)
add x5, x0, x2  // upper user buffer boundary
subsx2, x2, #16
b.mi1f
0:
ldp x3, x4, [x1], #16
subsx2, x2, #16
USER(9f, stpx3, x4, [x0], #16)
b.pl0b
1:  addsx2, x2, #8
b.mi2f
ldr x3, [x1], #8
sub x2, x2, #8
USER(9f, strx3, [x0], #8)
2:  addsx2, x2, #4
b.mi3f
ldr w3, [x1], #4
sub x2, x2, #4
USER(9f, strw3, [x0], #4)
3:  addsx2, x2, #2
b.mi4f
ldrhw3, [x1], #2
sub x2, x2, #2
USER(9f, strh   w3, [x0], #2)
4:  addsx2, x2, #1
b.mi5f
ldrbw3, [x1]
USER(9f, strb   w3, [x0])
5:  mov x0, #0

It only check the str instructions, means only check fault on destination
address, if the source address in kernel is invalid, it will result in
kernel panic(), this may happened in read_kcore() function, the
kern_addr_valid() only make sure the address is valid during call it,
when it returned, the kernel address may be invalid, like kunmap(),
setfixmap(), vfree() function will change kernel pagetables, and there is
not any sync between read_kcore() and kernel pagetable change. I change
to use copy_in_user(), so that can check both source and destination address,
avoid the kernel panic() in some unlucky circumstance.

Signed-off-by: yalin wang 
---
 fs/proc/kcore.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 92e6726..4f28deb 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -515,8 +515,12 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
} else {
if (kern_addr_valid(start)) {
unsigned long n;
-
-   n = copy_to_user(buffer, (char *)start, tsz);
+   if ((start + tsz < tsz) ||
+   (start + tsz) > TASK_SIZE)
+   return -EFAULT;
+   set_fs(KERNEL_DS);
+   n = copy_in_user(buffer, (char *)start, tsz);
+   set_fs(USER_DS);
/*
 * We cannot distinguish between fault on source
 * and fault on destination. When this happens
-- 
1.9.1

--
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: [RFC] fs/kcore: change copy_to_user to copy_in_user

[yalin wang]

> On Aug 20, 2015, at 17:58, Frans Klaver  wrote:
> 
> On Thu, Aug 20, 2015 at 10:59 AM, yalin wang  wrote:
>> the copy_to_user() here expect can fix the fault on both kernel and
>> user address, this is not true on other platforms except x86,
>> change to user copy_in_user() so that can detect the page fault,
>> work as expected.
> 
> Could you rephrase this into multiple sentences in comprehensible
> English? What is the expected behavior, what is the unexpected
> behavior and what can people do to trigger it?
> 
ok, i will send a V2 patch.

--
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] nvdimm: change to use generic kvfree()

[yalin wang]

Signed-off-by: yalin wang 
---
 drivers/nvdimm/dimm_devs.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/nvdimm/dimm_devs.c b/drivers/nvdimm/dimm_devs.c
index c05eb80..651b8d1 100644
--- a/drivers/nvdimm/dimm_devs.c
+++ b/drivers/nvdimm/dimm_devs.c
@@ -241,10 +241,7 @@ void nvdimm_drvdata_release(struct kref *kref)
nvdimm_free_dpa(ndd, res);
nvdimm_bus_unlock(dev);
 
-   if (ndd->data && is_vmalloc_addr(ndd->data))
-   vfree(ndd->data);
-   else
-   kfree(ndd->data);
+   kvfree(ndd->data);
kfree(ndd);
put_device(dev);
 }
-- 
1.9.1

--
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/

[RFC] fs/kcore: change copy_to_user to copy_in_user

[yalin wang]

the copy_to_user() here expect can fix the fault on both kernel and
user address, this is not true on other platforms except x86,
change to user copy_in_user() so that can detect the page fault,
work as expected.

Signed-off-by: yalin wang 
---
 fs/proc/kcore.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 92e6726..4f28deb 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -515,8 +515,12 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
} else {
if (kern_addr_valid(start)) {
unsigned long n;
-
-   n = copy_to_user(buffer, (char *)start, tsz);
+   if ((start + tsz < tsz) ||
+   (start + tsz) > TASK_SIZE)
+   return -EFAULT;
+   set_fs(KERNEL_DS);
+   n = copy_in_user(buffer, (char *)start, tsz);
+   set_fs(USER_DS);
/*
 * We cannot distinguish between fault on source
 * and fault on destination. When this happens
-- 
1.9.1

--
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: [x86] copy_from{to}_user question

[yalin wang]

> On Aug 17, 2015, at 12:16, Borislav Petkov  wrote:
> 
> On Mon, Aug 17, 2015 at 11:27:01AM +0800, yalin wang wrote:
>> i just want the x86 copy_from{to,in}_user() function have 
>> the same behaviour as other platforms.
> 
> Back to the original question from 2 mails ago:
> 
> How else would we be able to use the same function in copy_to and
> copy_from variants?
> 
>> and can disclose potential BUGs in kernel, if do like this.
> 
> Back to my other question:
> 
> Do you have any real life examples where you can trigger such bugs or is
> this only "potential"?
> 
> IOW, what I *think* you're trying to do sounds to me like unnecessary
> complication with no apparent gain *at* *all*. So show me why you want
> to do it: code it up, trigger a bug and show me why your version is
> better. No "but but it might be a good idea", no "potentially maybe",
> none of that maybe stuff. Write it, send it with instructions how
> someone else can apply it and trigger the issue. Ok?
> 
> 
i will loop you in a patch mail, for kcore driver rely on x86 copy_to_user()
feature like this , but not true on other platforms .

--
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/

[RFC] fbdev/nvidia:change reverse_order() macro

[yalin wang]

This change reverse_order() to swab32(bitrev32()), so that
it can have better performance on some platforms.

Signed-off-by: yalin wang 
---
 drivers/video/fbdev/nvidia/nv_accel.c |  4 ++--
 drivers/video/fbdev/nvidia/nv_local.h | 13 -
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/nvidia/nv_accel.c 
b/drivers/video/fbdev/nvidia/nv_accel.c
index ad6472a..c21cb34 100644
--- a/drivers/video/fbdev/nvidia/nv_accel.c
+++ b/drivers/video/fbdev/nvidia/nv_accel.c
@@ -382,7 +382,7 @@ static void nvidiafb_mono_color_expand(struct fb_info *info,
 
for (j = RECT_EXPAND_TWO_COLOR_DATA_MAX_DWORDS; j--;) {
tmp = data[k++];
-   reverse_order();
+   tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
}
 
@@ -394,7 +394,7 @@ static void nvidiafb_mono_color_expand(struct fb_info *info,
 
for (j = dsize; j--;) {
tmp = data[k++];
-   reverse_order();
+   tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
}
}
diff --git a/drivers/video/fbdev/nvidia/nv_local.h 
b/drivers/video/fbdev/nvidia/nv_local.h
index 68e508d..a0eb1f3 100644
--- a/drivers/video/fbdev/nvidia/nv_local.h
+++ b/drivers/video/fbdev/nvidia/nv_local.h
@@ -97,18 +97,13 @@
 
 #ifdef __LITTLE_ENDIAN
 
+#include 
 #include 
 
-#define reverse_order(l)\
-do {\
-   u8 *a = (u8 *)(l);  \
-   a[0] = bitrev8(a[0]);   \
-   a[1] = bitrev8(a[1]);   \
-   a[2] = bitrev8(a[2]);   \
-   a[3] = bitrev8(a[3]);   \
-} while(0)
+#define reverse_order(v)   swab32(bitrev32(v))
+
 #else
-#define reverse_order(l) do { } while(0)
+#define reverse_order(v)   (v)
 #endif  /* __LITTLE_ENDIAN */
 
 #endif /* __NV_LOCAL_H__ */
-- 
1.9.1

--
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] nvdimm: change to use generic kvfree()

[yalin wang]

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/nvdimm/dimm_devs.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/nvdimm/dimm_devs.c b/drivers/nvdimm/dimm_devs.c
index c05eb80..651b8d1 100644
--- a/drivers/nvdimm/dimm_devs.c
+++ b/drivers/nvdimm/dimm_devs.c
@@ -241,10 +241,7 @@ void nvdimm_drvdata_release(struct kref *kref)
nvdimm_free_dpa(ndd, res);
nvdimm_bus_unlock(dev);
 
-   if (ndd-data  is_vmalloc_addr(ndd-data))
-   vfree(ndd-data);
-   else
-   kfree(ndd-data);
+   kvfree(ndd-data);
kfree(ndd);
put_device(dev);
 }
-- 
1.9.1

--
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: [x86] copy_from{to}_user question

[yalin wang]

 On Aug 17, 2015, at 12:16, Borislav Petkov b...@suse.de wrote:
 
 On Mon, Aug 17, 2015 at 11:27:01AM +0800, yalin wang wrote:
 i just want the x86 copy_from{to,in}_user() function have 
 the same behaviour as other platforms.
 
 Back to the original question from 2 mails ago:
 
 How else would we be able to use the same function in copy_to and
 copy_from variants?
 
 and can disclose potential BUGs in kernel, if do like this.
 
 Back to my other question:
 
 Do you have any real life examples where you can trigger such bugs or is
 this only potential?
 
 IOW, what I *think* you're trying to do sounds to me like unnecessary
 complication with no apparent gain *at* *all*. So show me why you want
 to do it: code it up, trigger a bug and show me why your version is
 better. No but but it might be a good idea, no potentially maybe,
 none of that maybe stuff. Write it, send it with instructions how
 someone else can apply it and trigger the issue. Ok?
 
 
i will loop you in a patch mail, for kcore driver rely on x86 copy_to_user()
feature like this , but not true on other platforms .

--
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/

[RFC] fs/kcore: change copy_to_user to copy_in_user

[yalin wang]

the copy_to_user() here expect can fix the fault on both kernel and
user address, this is not true on other platforms except x86,
change to user copy_in_user() so that can detect the page fault,
work as expected.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 fs/proc/kcore.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 92e6726..4f28deb 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -515,8 +515,12 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
} else {
if (kern_addr_valid(start)) {
unsigned long n;
-
-   n = copy_to_user(buffer, (char *)start, tsz);
+   if ((start + tsz  tsz) ||
+   (start + tsz)  TASK_SIZE)
+   return -EFAULT;
+   set_fs(KERNEL_DS);
+   n = copy_in_user(buffer, (char *)start, tsz);
+   set_fs(USER_DS);
/*
 * We cannot distinguish between fault on source
 * and fault on destination. When this happens
-- 
1.9.1

--
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: [RFC] fs/kcore: change copy_to_user to copy_in_user

[yalin wang]

 On Aug 20, 2015, at 17:58, Frans Klaver franskla...@gmail.com wrote:
 
 On Thu, Aug 20, 2015 at 10:59 AM, yalin wang yalin.wang2...@gmail.com wrote:
 the copy_to_user() here expect can fix the fault on both kernel and
 user address, this is not true on other platforms except x86,
 change to user copy_in_user() so that can detect the page fault,
 work as expected.
 
 Could you rephrase this into multiple sentences in comprehensible
 English? What is the expected behavior, what is the unexpected
 behavior and what can people do to trigger it?
 
ok, i will send a V2 patch.

--
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: [RFC] fbdev/riva:change to use generice function to implement reverse_order()

[yalin wang]

 On Aug 20, 2015, at 19:02, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 
 
 On 10/08/15 13:12, yalin wang wrote:
 This change to use swab32(bitrev32()) to implement reverse_order()
 function, have better performance on some platforms.
 
 Which platforms? Presuming you tested this, roughly how much better
 performance? If you didn't, how do you know it's faster?

i investigate on arm64 platforms:


for (j = dsize; j--;) {
tmp = data[k++];
tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
 bac:   110006a4add w4, w21, #0x1
 bb0:   5ac000a3rbitw3, w5

if (dsize) {
NVDmaStart(info, par, RECT_EXPAND_TWO_COLOR_DATA(0), dsize);

for (j = dsize; j--;) {
tmp = data[k++];
 bb4:   110006d6add w22, w22, #0x1
 bb8:   5ac00861rev w1, w3
tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
 bbc:   b9041e64str w4, [x19,#1052]
 bc0:   8b3548c2add x2, x6, w21, uxtw #2
 bc4:   b941str w1, [x2]


this is the disassemble code after apply the patch,
only need:
rbitw3, w5
rev w1, w3
2 instruction to get the reverse_order() result,
apparently after than the origianl macro code.

 
 Signed-off-by: yalin wang yalin.wang2...@gmail.com
 ---
 drivers/video/fbdev/riva/fbdev.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)
 
 diff --git a/drivers/video/fbdev/riva/fbdev.c 
 b/drivers/video/fbdev/riva/fbdev.c
 index f1ad274..4803901 100644
 --- a/drivers/video/fbdev/riva/fbdev.c
 +++ b/drivers/video/fbdev/riva/fbdev.c
 @@ -40,6 +40,7 @@
 #include linux/init.h
 #include linux/pci.h
 #include linux/backlight.h
 +#include linux/swab.h
 #include linux/bitrev.h
 #ifdef CONFIG_PMAC_BACKLIGHT
 #include asm/machdep.h
 @@ -84,6 +85,7 @@
 #define SetBit(n)(1(n))
 #define Set8Bits(value)  ((value)0xff)
 
 +#define reverse_order(v) swab32(bitrev32(v))
 /* HW cursor parameters */
 #define MAX_CURS 32
 
 @@ -451,15 +453,6 @@ static inline unsigned char MISCin(struct riva_par *par)
  return (VGA_RD08(par-riva.PVIO, 0x3cc));
 }
 
 -static inline void reverse_order(u32 *l)
 
 I would suggest to do the work in the inline function, instead of a
 macro. And if you keep the function prototype the same, then the changes
 to each reverse_order call site are not needed.
 

ok, i will change to a inline function. 


--
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/

[RFC V2] fs/kcore: change copy_to_user to copy_in_user

[yalin wang]

The copy_to_user() here expect can fix the fault on both kernel and
user address, this is not true on other platforms except x86,
change to user copy_in_user() so that can detect the source and
destination address page fault, work as expected:

ENTRY(copy_user_generic_string)
ASM_STAC
cmpl $8,%edx
jb 2f   /* less than 8 bytes, go to byte copy loop */
ALIGN_DESTINATION
movl %edx,%ecx
shrl $3,%ecx
andl $7,%edx
1:  rep
movsq
2:  movl %edx,%ecx
3:  rep
movsb
xorl %eax,%eax
ASM_CLAC
ret

.section .fixup,ax
11: leal (%rdx,%rcx,8),%ecx
12: movl %ecx,%edx  /* ecx is zerorest also */
jmp copy_user_handle_tail
.previous

_ASM_EXTABLE(1b,11b)
_ASM_EXTABLE(3b,12b)
ENDPROC(copy_user_generic_string)

This is the x86 copy_to_user implementation, the fault instruction is
label 1b, 3b, because movsb instruction will fault on both source and
destination address, but on other platforms, like arm64 and arm:

ENTRY(__copy_to_user)
ALTERNATIVE(nop, __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
CONFIG_ARM64_PAN)
add x5, x0, x2  // upper user buffer boundary
subsx2, x2, #16
b.mi1f
0:
ldp x3, x4, [x1], #16
subsx2, x2, #16
USER(9f, stpx3, x4, [x0], #16)
b.pl0b
1:  addsx2, x2, #8
b.mi2f
ldr x3, [x1], #8
sub x2, x2, #8
USER(9f, strx3, [x0], #8)
2:  addsx2, x2, #4
b.mi3f
ldr w3, [x1], #4
sub x2, x2, #4
USER(9f, strw3, [x0], #4)
3:  addsx2, x2, #2
b.mi4f
ldrhw3, [x1], #2
sub x2, x2, #2
USER(9f, strh   w3, [x0], #2)
4:  addsx2, x2, #1
b.mi5f
ldrbw3, [x1]
USER(9f, strb   w3, [x0])
5:  mov x0, #0

It only check the str instructions, means only check fault on destination
address, if the source address in kernel is invalid, it will result in
kernel panic(), this may happened in read_kcore() function, the
kern_addr_valid() only make sure the address is valid during call it,
when it returned, the kernel address may be invalid, like kunmap(),
setfixmap(), vfree() function will change kernel pagetables, and there is
not any sync between read_kcore() and kernel pagetable change. I change
to use copy_in_user(), so that can check both source and destination address,
avoid the kernel panic() in some unlucky circumstance.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 fs/proc/kcore.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 92e6726..4f28deb 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -515,8 +515,12 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
} else {
if (kern_addr_valid(start)) {
unsigned long n;
-
-   n = copy_to_user(buffer, (char *)start, tsz);
+   if ((start + tsz  tsz) ||
+   (start + tsz)  TASK_SIZE)
+   return -EFAULT;
+   set_fs(KERNEL_DS);
+   n = copy_in_user(buffer, (char *)start, tsz);
+   set_fs(USER_DS);
/*
 * We cannot distinguish between fault on source
 * and fault on destination. When this happens
-- 
1.9.1

--
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/

[RFC V2] fbdev/nvidia:change reverse_order() macro

[yalin wang]

This change reverse_order() to swab32(bitrev32()), so that
it can have better performance on some platforms.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/video/fbdev/nvidia/nv_local.h | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/video/fbdev/nvidia/nv_local.h 
b/drivers/video/fbdev/nvidia/nv_local.h
index 68e508d..2c6baa1 100644
--- a/drivers/video/fbdev/nvidia/nv_local.h
+++ b/drivers/video/fbdev/nvidia/nv_local.h
@@ -97,18 +97,19 @@
 
 #ifdef __LITTLE_ENDIAN
 
+#include linux/swab.h
 #include linux/bitrev.h
+static inline void reverse_order(u32 *data)
+{
+   *data = swab32(bitrev32(*data));
+}
 
-#define reverse_order(l)\
-do {\
-   u8 *a = (u8 *)(l);  \
-   a[0] = bitrev8(a[0]);   \
-   a[1] = bitrev8(a[1]);   \
-   a[2] = bitrev8(a[2]);   \
-   a[3] = bitrev8(a[3]);   \
-} while(0)
 #else
-#define reverse_order(l) do { } while(0)
-#endif  /* __LITTLE_ENDIAN */
 
+static inline void reverse_order(u32 *data)
+{
+
+}
+
+#endif  /* __LITTLE_ENDIAN */
 #endif /* __NV_LOCAL_H__ */
-- 
1.9.1

--
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/

[RFC] fbdev/nvidia:change reverse_order() macro

[yalin wang]

This change reverse_order() to swab32(bitrev32()), so that
it can have better performance on some platforms.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/video/fbdev/nvidia/nv_accel.c |  4 ++--
 drivers/video/fbdev/nvidia/nv_local.h | 13 -
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/nvidia/nv_accel.c 
b/drivers/video/fbdev/nvidia/nv_accel.c
index ad6472a..c21cb34 100644
--- a/drivers/video/fbdev/nvidia/nv_accel.c
+++ b/drivers/video/fbdev/nvidia/nv_accel.c
@@ -382,7 +382,7 @@ static void nvidiafb_mono_color_expand(struct fb_info *info,
 
for (j = RECT_EXPAND_TWO_COLOR_DATA_MAX_DWORDS; j--;) {
tmp = data[k++];
-   reverse_order(tmp);
+   tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
}
 
@@ -394,7 +394,7 @@ static void nvidiafb_mono_color_expand(struct fb_info *info,
 
for (j = dsize; j--;) {
tmp = data[k++];
-   reverse_order(tmp);
+   tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
}
}
diff --git a/drivers/video/fbdev/nvidia/nv_local.h 
b/drivers/video/fbdev/nvidia/nv_local.h
index 68e508d..a0eb1f3 100644
--- a/drivers/video/fbdev/nvidia/nv_local.h
+++ b/drivers/video/fbdev/nvidia/nv_local.h
@@ -97,18 +97,13 @@
 
 #ifdef __LITTLE_ENDIAN
 
+#include linux/swab.h
 #include linux/bitrev.h
 
-#define reverse_order(l)\
-do {\
-   u8 *a = (u8 *)(l);  \
-   a[0] = bitrev8(a[0]);   \
-   a[1] = bitrev8(a[1]);   \
-   a[2] = bitrev8(a[2]);   \
-   a[3] = bitrev8(a[3]);   \
-} while(0)
+#define reverse_order(v)   swab32(bitrev32(v))
+
 #else
-#define reverse_order(l) do { } while(0)
+#define reverse_order(v)   (v)
 #endif  /* __LITTLE_ENDIAN */
 
 #endif /* __NV_LOCAL_H__ */
-- 
1.9.1

--
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: [x86] copy_from{to}_user question

[yalin wang]

> On Aug 14, 2015, at 00:43, Borislav Petkov  wrote:
> 
> On Thu, Aug 13, 2015 at 06:04:54PM +0800, yalin wang wrote:
>> we store type into one fix register, for example r12 ,
>> then in fix up code, we can know the exception is caused by copy_from
>> copy_to or copy_in user function by check r12 value(0 , 1 ,2 value), then if 
>> it is copy_from, we only allow read fault, if the exception is write fault, 
>> panic() .
>> 
>> the same rules also apply to copy_to / copy_in function .
>> 
>> is it possible to change it like this ?
> 
> ... and we'll do all that jumping through hoops to fix what actual,
> real-life problem exactly?
i just want the x86 copy_from{to,in}_user() function have 
the same behaviour as other platforms.
and can disclose potential BUGs in kernel, if do like this.

Thanks.

--
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: [x86] copy_from{to}_user question

[yalin wang]

 On Aug 14, 2015, at 00:43, Borislav Petkov b...@suse.de wrote:
 
 On Thu, Aug 13, 2015 at 06:04:54PM +0800, yalin wang wrote:
 we store type into one fix register, for example r12 ,
 then in fix up code, we can know the exception is caused by copy_from
 copy_to or copy_in user function by check r12 value(0 , 1 ,2 value), then if 
 it is copy_from, we only allow read fault, if the exception is write fault, 
 panic() .
 
 the same rules also apply to copy_to / copy_in function .
 
 is it possible to change it like this ?
 
 ... and we'll do all that jumping through hoops to fix what actual,
 real-life problem exactly?
i just want the x86 copy_from{to,in}_user() function have 
the same behaviour as other platforms.
and can disclose potential BUGs in kernel, if do like this.

Thanks.

--
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: [x86] copy_from{to}_user question

[yalin wang]

> On Aug 12, 2015, at 18:07, Borislav Petkov  wrote:
> 
> On Wed, Aug 12, 2015 at 05:01:14PM +0800, yalin wang wrote:
>> hi x86 maintainers,
>> 
>> i have a question about copy_from{to}_user() function,
>> i find on other platforms like arm/ arm64 /hexagon,
>> all copy_from{to}_user function only check source address for
>> copy_from and only check to address for copy_to user function,
>> never check both source and dest together,
>> 
>> but on x86 platform, i see copy_from{to}_user use a generic function
>> named copy_user_generic_unrolled() in arch/x86/lib/copy_user_64.S,
> 
> That one is the fallback and used only on machines which don't set
> X86_FEATURE_REP_GOOD or X86_FEATURE_ERMS. Basically old P4 and K7 and
> early K8s.
> 
i see, generically, it use 3 function for different processors,

static __always_inline __must_check unsigned long
copy_user_generic(void *to, const void *from, unsigned len)
{
unsigned ret;

/*
 * If CPU has ERMS feature, use copy_user_enhanced_fast_string.
 * Otherwise, if CPU has rep_good feature, use copy_user_generic_string.
 * Otherwise, use copy_user_generic_unrolled.
 */
alternative_call_2(copy_user_generic_unrolled,
 copy_user_generic_string,
 X86_FEATURE_REP_GOOD,
 copy_user_enhanced_fast_string,
 X86_FEATURE_ERMS,
 ASM_OUTPUT2("=a" (ret), "=D" (to), "=S" (from),
 "=d" (len)),
 "1" (to), "2" (from), "3" (len)
 : "memory", "rcx", "r8", "r9", "r10", "r11");
return ret;
}

>> it check source and dest address no matter it is copy_from user or
>> copy_to_user ,  is it correct? 
>> for copy_from_user i think only need check source address is enough,
> 
> How else would we be able to use the same function in copy_to and
> copy_from variants?

for 3 methods implemented here, i think can implemented by add one more 
function parameter,
like this:
#define COPY_FROM 0
#define COPY_TO 1
#define COPY_IN 2
copy_user_generic(void *to, const void *from, unsigned len, int type)

we store type into one fix register, for example r12 ,
then in fix up code, we can know the exception is caused by copy_from
copy_to or copy_in user function by check r12 value(0 , 1 ,2 value), then if 
it is copy_from, we only allow read fault, if the exception is write fault, 
panic() .

the same rules also apply to copy_to / copy_in function .

is it possible to change it like this ?

Thanks

















--
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: [x86] copy_from{to}_user question

[yalin wang]

 On Aug 12, 2015, at 18:07, Borislav Petkov b...@suse.de wrote:
 
 On Wed, Aug 12, 2015 at 05:01:14PM +0800, yalin wang wrote:
 hi x86 maintainers,
 
 i have a question about copy_from{to}_user() function,
 i find on other platforms like arm/ arm64 /hexagon,
 all copy_from{to}_user function only check source address for
 copy_from and only check to address for copy_to user function,
 never check both source and dest together,
 
 but on x86 platform, i see copy_from{to}_user use a generic function
 named copy_user_generic_unrolled() in arch/x86/lib/copy_user_64.S,
 
 That one is the fallback and used only on machines which don't set
 X86_FEATURE_REP_GOOD or X86_FEATURE_ERMS. Basically old P4 and K7 and
 early K8s.
 
i see, generically, it use 3 function for different processors,

static __always_inline __must_check unsigned long
copy_user_generic(void *to, const void *from, unsigned len)
{
unsigned ret;

/*
 * If CPU has ERMS feature, use copy_user_enhanced_fast_string.
 * Otherwise, if CPU has rep_good feature, use copy_user_generic_string.
 * Otherwise, use copy_user_generic_unrolled.
 */
alternative_call_2(copy_user_generic_unrolled,
 copy_user_generic_string,
 X86_FEATURE_REP_GOOD,
 copy_user_enhanced_fast_string,
 X86_FEATURE_ERMS,
 ASM_OUTPUT2(=a (ret), =D (to), =S (from),
 =d (len)),
 1 (to), 2 (from), 3 (len)
 : memory, rcx, r8, r9, r10, r11);
return ret;
}

 it check source and dest address no matter it is copy_from user or
 copy_to_user ,  is it correct? 
 for copy_from_user i think only need check source address is enough,
 
 How else would we be able to use the same function in copy_to and
 copy_from variants?

for 3 methods implemented here, i think can implemented by add one more 
function parameter,
like this:
#define COPY_FROM 0
#define COPY_TO 1
#define COPY_IN 2
copy_user_generic(void *to, const void *from, unsigned len, int type)

we store type into one fix register, for example r12 ,
then in fix up code, we can know the exception is caused by copy_from
copy_to or copy_in user function by check r12 value(0 , 1 ,2 value), then if 
it is copy_from, we only allow read fault, if the exception is write fault, 
panic() .

the same rules also apply to copy_to / copy_in function .

is it possible to change it like this ?

Thanks

















--
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/fddi: remove HWM_REVERSE() macro

[yalin wang]

HWM_REVERSE() macro is unused, remove it.

Signed-off-by: yalin wang 
---
 drivers/net/fddi/skfp/h/hwmtm.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/net/fddi/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h
index 5924d42..4ca2341 100644
--- a/drivers/net/fddi/skfp/h/hwmtm.h
+++ b/drivers/net/fddi/skfp/h/hwmtm.h
@@ -74,15 +74,6 @@
 #define NULL   0
 #endif
 
-#ifdef LITTLE_ENDIAN
-#define HWM_REVERSE(x) (x)
-#else
-#defineHWM_REVERSE(x)  x)<<24L)&0xff00L)   +   
\
-(((x)<< 8L)&0x00ffL)   +   \
-(((x)>> 8L)&0xff00L)   +   \
-(((x)>>24L)&0x00ffL))
-#endif
-
 #define C_INDIC(1L<<25)
 #define A_INDIC(1L<<26)
 #defineRD_FS_LOCAL 0x80
-- 
1.9.1

--
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] proc/kcore: remove unneeded white spaces

[yalin wang]

Signed-off-by: yalin wang 
---
 fs/proc/kcore.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 92e6726..3782dd1 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -86,8 +86,8 @@ static size_t get_kcore_size(int *nphdr, size_t *elf_buflen)
size = try;
*nphdr = *nphdr + 1;
}
-   *elf_buflen =   sizeof(struct elfhdr) + 
-   (*nphdr + 2)*sizeof(struct elf_phdr) + 
+   *elf_buflen =   sizeof(struct elfhdr) +
+   (*nphdr + 2)*sizeof(struct elf_phdr) +
3 * ((sizeof(struct elf_note)) +
 roundup(sizeof(CORE_STR), 4)) +
roundup(sizeof(struct elf_prstatus), 4) +
@@ -485,7 +485,7 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
start = kc_offset_to_vaddr(*fpos - elf_buflen);
if ((tsz = (PAGE_SIZE - (start & ~PAGE_MASK))) > buflen)
tsz = buflen;
-   
+
while (buflen) {
struct kcore_list *m;
 
@@ -523,7 +523,7 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
 * we clear too and hope it will trigger the
 * EFAULT again.
 */
-   if (n) { 
+   if (n) {
if (clear_user(buffer + tsz - n,
n))
return -EFAULT;
-- 
1.9.1

--
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/

[x86] copy_from{to}_user question

[yalin wang]

hi x86 maintainers,

i have a question about copy_from{to}_user() function,
i find on other platforms like arm/ arm64 /hexagon,
all copy_from{to}_user function only check source address for
copy_from and only check to address for copy_to user function,
never check both source and dest together,

but on x86 platform, i see copy_from{to}_user use a generic function
named copy_user_generic_unrolled() in arch/x86/lib/copy_user_64.S,

it check source and dest address no matter it is copy_from user or
copy_to_user ,  is it correct? 
for copy_from_user i think only need check source address is enough,
if check both address, may hide some kernel BUG, if the kernel address
is not valid, because the fix up code will fix it and kernel will
not panic in this situation.

another problems is that in ./fs/proc/kcore.c ,
read_kcore() function:


if (kern_addr_valid(start)) {
  unsigned long n;
  
  n = copy_to_user(buffer, (char *)start, tsz);
  /*

   
  ¦* We cannot distinguish between fault on source
  ¦* and fault on destination. When this happens
  ¦* we clear too and hope it will trigger the
  ¦* EFAULT again.
  ¦*/ 
  if (n) { 
  if (clear_user(buffer + tsz - n,
  n)) 
  return -EFAULT;
  }   
  } else {
  if (clear_user(buffer, tsz))
  return -EFAULT;
  }

it relies on copy_to_user() can fault on both user and kernel address,
it is not true on arm / arm64 /hexgon platforms, maybe some other platforms,
i don’t check all platform code.
and this code may result in kernel panic on these platforms.

i think x86’s copy_from{to}_user code need to change like other platforms.
or am i missing something ?

Thanks









--
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/fddi: remove HWM_REVERSE() macro

[yalin wang]

HWM_REVERSE() macro is unused, remove it.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/net/fddi/skfp/h/hwmtm.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/net/fddi/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h
index 5924d42..4ca2341 100644
--- a/drivers/net/fddi/skfp/h/hwmtm.h
+++ b/drivers/net/fddi/skfp/h/hwmtm.h
@@ -74,15 +74,6 @@
 #define NULL   0
 #endif
 
-#ifdef LITTLE_ENDIAN
-#define HWM_REVERSE(x) (x)
-#else
-#defineHWM_REVERSE(x)  x)24L)0xff00L)   +   
\
-(((x) 8L)0x00ffL)   +   \
-(((x) 8L)0xff00L)   +   \
-(((x)24L)0x00ffL))
-#endif
-
 #define C_INDIC(1L25)
 #define A_INDIC(1L26)
 #defineRD_FS_LOCAL 0x80
-- 
1.9.1

--
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/

[x86] copy_from{to}_user question

[yalin wang]

hi x86 maintainers,

i have a question about copy_from{to}_user() function,
i find on other platforms like arm/ arm64 /hexagon,
all copy_from{to}_user function only check source address for
copy_from and only check to address for copy_to user function,
never check both source and dest together,

but on x86 platform, i see copy_from{to}_user use a generic function
named copy_user_generic_unrolled() in arch/x86/lib/copy_user_64.S,

it check source and dest address no matter it is copy_from user or
copy_to_user ,  is it correct? 
for copy_from_user i think only need check source address is enough,
if check both address, may hide some kernel BUG, if the kernel address
is not valid, because the fix up code will fix it and kernel will
not panic in this situation.

another problems is that in ./fs/proc/kcore.c ,
read_kcore() function:


if (kern_addr_valid(start)) {
  unsigned long n;
  
  n = copy_to_user(buffer, (char *)start, tsz);
  /*

   
  ¦* We cannot distinguish between fault on source
  ¦* and fault on destination. When this happens
  ¦* we clear too and hope it will trigger the
  ¦* EFAULT again.
  ¦*/ 
  if (n) { 
  if (clear_user(buffer + tsz - n,
  n)) 
  return -EFAULT;
  }   
  } else {
  if (clear_user(buffer, tsz))
  return -EFAULT;
  }

it relies on copy_to_user() can fault on both user and kernel address,
it is not true on arm / arm64 /hexgon platforms, maybe some other platforms,
i don’t check all platform code.
and this code may result in kernel panic on these platforms.

i think x86’s copy_from{to}_user code need to change like other platforms.
or am i missing something ?

Thanks









--
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] proc/kcore: remove unneeded white spaces

[yalin wang]

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 fs/proc/kcore.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 92e6726..3782dd1 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -86,8 +86,8 @@ static size_t get_kcore_size(int *nphdr, size_t *elf_buflen)
size = try;
*nphdr = *nphdr + 1;
}
-   *elf_buflen =   sizeof(struct elfhdr) + 
-   (*nphdr + 2)*sizeof(struct elf_phdr) + 
+   *elf_buflen =   sizeof(struct elfhdr) +
+   (*nphdr + 2)*sizeof(struct elf_phdr) +
3 * ((sizeof(struct elf_note)) +
 roundup(sizeof(CORE_STR), 4)) +
roundup(sizeof(struct elf_prstatus), 4) +
@@ -485,7 +485,7 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
start = kc_offset_to_vaddr(*fpos - elf_buflen);
if ((tsz = (PAGE_SIZE - (start  ~PAGE_MASK)))  buflen)
tsz = buflen;
-   
+
while (buflen) {
struct kcore_list *m;
 
@@ -523,7 +523,7 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
 * we clear too and hope it will trigger the
 * EFAULT again.
 */
-   if (n) { 
+   if (n) {
if (clear_user(buffer + tsz - n,
n))
return -EFAULT;
-- 
1.9.1

--
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 Resend] net/fddi: remove HWM_REVERSE() macro

[yalin wang]

HWM_REVERSE() macro is unused, remove it.

Signed-off-by: yalin wang 
---
 drivers/net/fddi/skfp/h/hwmtm.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/net/fddi/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h
index 5924d42..4ca2341 100644
--- a/drivers/net/fddi/skfp/h/hwmtm.h
+++ b/drivers/net/fddi/skfp/h/hwmtm.h
@@ -74,15 +74,6 @@
 #define NULL   0
 #endif
 
-#ifdef LITTLE_ENDIAN
-#define HWM_REVERSE(x) (x)
-#else
-#defineHWM_REVERSE(x)  x)<<24L)&0xff00L)   +   
\
-(((x)<< 8L)&0x00ffL)   +   \
-(((x)>> 8L)&0xff00L)   +   \
-(((x)>>24L)&0x00ffL))
-#endif
-
 #define C_INDIC(1L<<25)
 #define A_INDIC(1L<<26)
 #defineRD_FS_LOCAL 0x80
-- 
1.9.1















--
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 Resend] net/fddi: remove HWM_REVERSE() macro

[yalin wang]

HWM_REVERSE() macro is unused, remove it.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/net/fddi/skfp/h/hwmtm.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/net/fddi/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h
index 5924d42..4ca2341 100644
--- a/drivers/net/fddi/skfp/h/hwmtm.h
+++ b/drivers/net/fddi/skfp/h/hwmtm.h
@@ -74,15 +74,6 @@
 #define NULL   0
 #endif
 
-#ifdef LITTLE_ENDIAN
-#define HWM_REVERSE(x) (x)
-#else
-#defineHWM_REVERSE(x)  x)24L)0xff00L)   +   
\
-(((x) 8L)0x00ffL)   +   \
-(((x) 8L)0xff00L)   +   \
-(((x)24L)0x00ffL))
-#endif
-
 #define C_INDIC(1L25)
 #define A_INDIC(1L26)
 #defineRD_FS_LOCAL 0x80
-- 
1.9.1















--
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 Resend] net/fddi: remove HWM_REVERSE() macro

[yalin wang]

> On Aug 11, 2015, at 13:37, David Miller  wrote:
> 
> From: yalin wang 
> Date: Tue, 11 Aug 2015 13:11:22 +0800
> 
>> HWM_REVERSE() macro is unused, remove it.
>> 
>> Signed-off-by: yalin wang 
> 
> You did not do as I asked you to, this patch is still corrupted
> and there is no way you successfully applied what is in this patch.
> 
>> -#defineHWM_REVERSE(x)  x)<<24L)&0xff00L)   +
>>\
>> -(((x)<< 8L)&0x00ffL)   +   \
>> -(((x)>> 8L)&0xff00L)   +   \
>> -(((x)>>24L)&0x00ffL))
> 
> This indentation here is spaces, whereas in the source files they
> are TABS.
> 
> Your email client did this.
> 
> If you fail to properly verify that your outgoing patches are not
> corrupted before submitting them here, I will stop reviewing and
> considering your changes.
> 
> Thank you.
ouch,  i am sorry that i am sending from windows PC,
let me check that .
Sorry for that .--
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] joystick/zhenhua: remove zhenhua_bitreverse()

[yalin wang]

This change remove zhenhua_bitreverse() function, use generic
bitrev8() function instead.

Signed-off-by: yalin wang 
---
 drivers/input/joystick/zhenhua.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/input/joystick/zhenhua.c b/drivers/input/joystick/zhenhua.c
index 30af2e8..4a8258b 100644
--- a/drivers/input/joystick/zhenhua.c
+++ b/drivers/input/joystick/zhenhua.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -72,16 +73,6 @@ struct zhenhua {
char phys[32];
 };
 
-
-/* bits in all incoming bytes needs to be "reversed" */
-static int zhenhua_bitreverse(int x)
-{
-   x = ((x & 0xaa) >> 1) | ((x & 0x55) << 1);
-   x = ((x & 0xcc) >> 2) | ((x & 0x33) << 2);
-   x = ((x & 0xf0) >> 4) | ((x & 0x0f) << 4);
-   return x;
-}
-
 /*
  * zhenhua_process_packet() decodes packets the driver receives from the
  * RC transmitter. It updates the data accordingly.
@@ -120,7 +111,7 @@ static irqreturn_t zhenhua_interrupt(struct serio *serio, 
unsigned char data, un
return IRQ_HANDLED; /* wrong MSB -- ignore this byte */
 
if (zhenhua->idx < ZHENHUA_MAX_LENGTH)
-   zhenhua->data[zhenhua->idx++] = zhenhua_bitreverse(data);
+   zhenhua->data[zhenhua->idx++] = bitrev8(data);
 
if (zhenhua->idx == ZHENHUA_MAX_LENGTH) {
zhenhua_process_packet(zhenhua);
-- 
1.9.1
--
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] zlib_deflate/deftree: Remove bi_reverse()

[yalin wang]

This change remove bi_reverse() and use generic bitrev32() instead,
have better performance on some platforms.

Signed-off-by: yalin wang 
---
 lib/zlib_deflate/deftree.c |  6 +++---
 lib/zlib_deflate/defutil.h | 16 
 2 files changed, 3 insertions(+), 19 deletions(-)

diff --git a/lib/zlib_deflate/deftree.c b/lib/zlib_deflate/deftree.c
index ddf3482..9b1756b 100644
--- a/lib/zlib_deflate/deftree.c
+++ b/lib/zlib_deflate/deftree.c
@@ -35,6 +35,7 @@
 /* #include "deflate.h" */
 
 #include 
+#include 
 #include "defutil.h"
 
 #ifdef DEBUG_ZLIB
@@ -146,7 +147,6 @@ static void send_all_trees (deflate_state *s, int lcodes, 
int dcodes,
 static void compress_block (deflate_state *s, ct_data *ltree,
ct_data *dtree);
 static void set_data_type  (deflate_state *s);
-static unsigned bi_reverse (unsigned value, int length);
 static void bi_windup  (deflate_state *s);
 static void bi_flush   (deflate_state *s);
 static void copy_block (deflate_state *s, char *buf, unsigned len,
@@ -284,7 +284,7 @@ static void tr_static_init(void)
 /* The static distance tree is trivial: */
 for (n = 0; n < D_CODES; n++) {
 static_dtree[n].Len = 5;
-static_dtree[n].Code = bi_reverse((unsigned)n, 5);
+static_dtree[n].Code = bitrev32((u32)n) >> (32 - 5);
 }
 static_init_done = 1;
 }
@@ -520,7 +520,7 @@ static void gen_codes(
 int len = tree[n].Len;
 if (len == 0) continue;
 /* Now reverse the bits */
-tree[n].Code = bi_reverse(next_code[len]++, len);
+tree[n].Code = bitrev32((u32)(next_code[len]++)) >> (32 - len);
 
 Tracecv(tree != static_ltree, (stderr,"\nn %3d %c l %2d c %4x (%x) ",
  n, (isgraph(n) ? n : ' '), len, tree[n].Code, next_code[len]-1));
diff --git a/lib/zlib_deflate/defutil.h b/lib/zlib_deflate/defutil.h
index b640b64..a8c3708 100644
--- a/lib/zlib_deflate/defutil.h
+++ b/lib/zlib_deflate/defutil.h
@@ -293,22 +293,6 @@ void zlib_tr_stored_type_only (deflate_state *);
 }
 
 /* ===
- * Reverse the first len bits of a code, using straightforward code (a faster
- * method would use a table)
- * IN assertion: 1 <= len <= 15
- */
-static inline unsigned bi_reverse(unsigned code, /* the value to invert */
- int len)   /* its bit length */
-{
-register unsigned res = 0;
-do {
-res |= code & 1;
-code >>= 1, res <<= 1;
-} while (--len > 0);
-return res >> 1;
-}
-
-/* ===
  * Flush the bit buffer, keeping at most 7 bits in it.
  */
 static inline void bi_flush(deflate_state *s)
-- 
1.9.1

--
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 v2 Resend] net/fddi: remove HWM_REVERSE() macro

[yalin wang]

HWM_REVERSE() macro is unused, remove it.

Signed-off-by: yalin wang 
---
drivers/net/fddi/skfp/h/hwmtm.h | 10 --
1 file changed, 10 deletions(-)

diff --git a/drivers/net/fddi/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h
index 5924d42..4ca2341 100644
--- a/drivers/net/fddi/skfp/h/hwmtm.h
+++ b/drivers/net/fddi/skfp/h/hwmtm.h
@@ -74,15 +74,6 @@
#define NULL   0
#endif

-#ifdef LITTLE_ENDIAN
-#define HWM_REVERSE(x) (x)
-#else
-#defineHWM_REVERSE(x)  x)<<24L)&0xff00L)   +   
\
-(((x)<< 8L)&0x00ffL)   +   \
-(((x)>> 8L)&0xff00L)   +   \
-(((x)>>24L)&0x00ffL))
-#endif
-
#define C_INDIC(1L<<25)
#define A_INDIC(1L<<26)
#defineRD_FS_LOCAL 0x80
-- 
1.9.1


--
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/fddi: remove HWM_REVERSE() macro

[yalin wang]

> On Aug 11, 2015, at 12:24, David Miller  wrote:
> 
> From: yalin wang 
> Date: Tue, 11 Aug 2015 09:57:21 +0800
> 
>> HWM_REVERSE() macro is unused, remove it.
>> 
>> Signed-off-by: yalin wang 
> 
> Your email client has corrupted this patch.
> 
> Please read Documentation/email-clients.txt, send a test patch to yourself,
> and only resubmit this change once you are able to successfully apply the
> patch you receive in that test email.
> 
> Thanks.
ok, Thanks.
--
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/

[RFC V2] bmac:change to use bitrev8() generic function

[yalin wang]

This change to use generic bitrev8() for bmac driver.

Signed-off-by: yalin wang 
---
 drivers/net/ethernet/apple/bmac.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/apple/bmac.c 
b/drivers/net/ethernet/apple/bmac.c
index a65d7a6..7f7a398 100644
--- a/drivers/net/ethernet/apple/bmac.c
+++ b/drivers/net/ethernet/apple/bmac.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -805,18 +806,6 @@ static irqreturn_t bmac_txdma_intr(int irq, void *dev_id)
 }
 
 #ifndef SUNHME_MULTICAST
-/* Real fast bit-reversal algorithm, 6-bit values */
-static int reverse6[64] = {
-   0x0,0x20,0x10,0x30,0x8,0x28,0x18,0x38,
-   0x4,0x24,0x14,0x34,0xc,0x2c,0x1c,0x3c,
-   0x2,0x22,0x12,0x32,0xa,0x2a,0x1a,0x3a,
-   0x6,0x26,0x16,0x36,0xe,0x2e,0x1e,0x3e,
-   0x1,0x21,0x11,0x31,0x9,0x29,0x19,0x39,
-   0x5,0x25,0x15,0x35,0xd,0x2d,0x1d,0x3d,
-   0x3,0x23,0x13,0x33,0xb,0x2b,0x1b,0x3b,
-   0x7,0x27,0x17,0x37,0xf,0x2f,0x1f,0x3f
-};
-
 static unsigned int
 crc416(unsigned int curval, unsigned short nxtval)
 {
@@ -871,7 +860,7 @@ bmac_addhash(struct bmac_data *bp, unsigned char *addr)
 
if (!(*addr)) return;
crc = bmac_crc((unsigned short *)addr) & 0x3f; /* Big-endian alert! */
-   crc = reverse6[crc];/* Hyperfast bit-reversing algorithm */
+   crc = bitrev8((u8)crc) >> 2;
if (bp->hash_use_count[crc]++) return; /* This bit is already set */
mask = crc % 16;
mask = (unsigned char)1 << mask;
@@ -886,7 +875,7 @@ bmac_removehash(struct bmac_data *bp, unsigned char *addr)
 
/* Now, delete the address from the filter copy, as indicated */
crc = bmac_crc((unsigned short *)addr) & 0x3f; /* Big-endian alert! */
-   crc = reverse6[crc];/* Hyperfast bit-reversing algorithm */
+   crc = bitrev8((u8)crc) >> 2;
if (bp->hash_use_count[crc] == 0) return; /* That bit wasn't in use! */
if (--bp->hash_use_count[crc]) return; /* That bit is still in use */
mask = crc % 16;
-- 
1.9.1
--
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: [RFC] bmac:change to use bitrev8() generic function

[yalin wang]

> On Aug 10, 2015, at 20:02, David Laight  wrote:
> 
>> From: Tobias Klauser
>> Sent: 10 August 2015 12:49
>> On 2015-08-10 at 11:53:41 +0200, yalin wang  wrote:
>>> This change to use generic bitrev8() for bmac driver.
> ...
>>> @@ -871,7 +860,7 @@ bmac_addhash(struct bmac_data *bp, unsigned char *addr)
>>> 
>>> if (!(*addr)) return;
>>> crc = bmac_crc((unsigned short *)addr) & 0x3f; /* Big-endian alert! */
> 
> Why not *((u8 *)addr + 1) & 0x3f
> 
>>> -   crc = reverse6[crc];/* Hyperfast bit-reversing algorithm */
>>> +   crc = bitrev8((u8)crc);
>> 
>> No, this won't work. reverse6 works on 6 bit values, while bitrev8 works
>> on 8bit values, e.g. reverse6[1] = 0x20, while bitrev8(1) = 0x80
> 
> You could use bitrev8(n) >> 2.
> 
> But that is a 'strange' map of a 7-bit value to a 6-bit one.
> 
> I thought it was more common for ethernet hardware to use the
> value of the crc register after all 6 bytes of the mac address
> had been processed.
oh, my mistake, i will change it in V2 for review.--
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 v2] net/fddi: remove HWM_REVERSE() macro

[yalin wang]

 HWM_REVERSE() macro is unused, remove it.

Signed-off-by: yalin wang 
---
 drivers/net/fddi/skfp/h/hwmtm.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/net/fddi/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h
index 5924d42..4ca2341 100644
--- a/drivers/net/fddi/skfp/h/hwmtm.h
+++ b/drivers/net/fddi/skfp/h/hwmtm.h
@@ -74,15 +74,6 @@
 #define NULL   0
 #endif
 
-#ifdef LITTLE_ENDIAN
-#define HWM_REVERSE(x) (x)
-#else
-#defineHWM_REVERSE(x)  x)<<24L)&0xff00L)   +   
\
-(((x)<< 8L)&0x00ffL)   +   \
-(((x)>> 8L)&0xff00L)   +   \
-(((x)>>24L)&0x00ffL))
-#endif
-
 #define C_INDIC(1L<<25)
 #define A_INDIC(1L<<26)
 #defineRD_FS_LOCAL 0x80
-- 
1.9.1

--
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] net/fddi:change HWM_REVERSE() macro

[yalin wang]

> On Aug 11, 2015, at 00:36, Joe Perches  wrote:
> 
> On Tue, 2015-08-11 at 00:14 +0800, yalin wang wrote:
>> HWM_REVERSE
> 
> Is unused and it would be better if removed.
> 
ok,  i will send V2 patch .
--
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] isdn:remove reverse_bits(), use revbit8()

[yalin wang]

> On Aug 11, 2015, at 05:30, David Miller  wrote:
> 
> From: yalin wang 
> Date: Mon, 10 Aug 2015 17:15:57 +0800
> 
>> This change isdn driver, remove reverse_bits() function,
>> use the generic revbit8() function instead.
>> 
>> Signed-off-by: yalin wang 
> 
> Applied, however please format your Subject lines better in the
> future.
> 
> There should be a space after the subsystem specifier and the ':'
> character.  So "isdn: "
> 
> Then you should capitalize the description in the Subject line
> because it is very much like an English sentence.
i see,
Thanks for your kindly remind !
--
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] lib/zlib_inflate:change REVERSE() macro

[yalin wang]

This patch change REVERSE() macro to use swab32() function,
so that can have more better performance on some platforms.

Signed-off-by: yalin wang 
---
lib/zlib_inflate/inflate.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/lib/zlib_inflate/inflate.c b/lib/zlib_inflate/inflate.c
index 58a733b..f2b68b6 100644
--- a/lib/zlib_inflate/inflate.c
+++ b/lib/zlib_inflate/inflate.c
@@ -10,6 +10,7 @@
 */

#include 
+#include 
#include "inftrees.h"
#include "inflate.h"
#include "inffast.h"
@@ -228,10 +229,7 @@ static int zlib_inflateSyncPacket(z_streamp strm)
} while (0)

/* Reverse the bytes in a 32-bit value */
-#define REVERSE(q) \
-q) >> 24) & 0xff) + (((q) >> 8) & 0xff00) + \
- (((q) & 0xff00) << 8) + (((q) & 0xff) << 24))
-
+#define REVERSE(q)  swab32(q)
/*
   inflate() uses a state machine to process as much input data and generate as
   much output data as possible before returning.  The state machine is
-- 
1.9.1

--
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/fddi:change HWM_REVERSE() macro

[yalin wang]

change HWM_REVERSE() macro to generic le32_to_cpu()

Signed-off-by: yalin wang 
---
 drivers/net/fddi/skfp/h/hwmtm.h | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/net/fddi/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h
index 5924d42..72701ef 100644
--- a/drivers/net/fddi/skfp/h/hwmtm.h
+++ b/drivers/net/fddi/skfp/h/hwmtm.h
@@ -14,7 +14,7 @@
 
 #ifndef_HWM_
 #define_HWM_
-
+#include 
 #include "mbuf.h"
 
 /*
@@ -74,14 +74,7 @@
 #define NULL   0
 #endif
 
-#ifdef LITTLE_ENDIAN
-#define HWM_REVERSE(x) (x)
-#else
-#defineHWM_REVERSE(x)  x)<<24L)&0xff00L)   +   
\
-(((x)<< 8L)&0x00ffL)   +   \
-(((x)>> 8L)&0xff00L)   +   \
-(((x)>>24L)&0x00ffL))
-#endif
+#define HWM_REVERSE(x) le32_to_cpu(x)
 
 #define C_INDIC(1L<<25)
 #define A_INDIC(1L<<26)
-- 
1.9.1



--
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] hwmon:change sht15_reverse()

[yalin wang]

This change sht15_reverse() to be generic bitrev8().

Signed-off-by: yalin wang 
---
 drivers/hwmon/sht15.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/hwmon/sht15.c b/drivers/hwmon/sht15.c
index 497a7f8..a2fdbb7 100644
--- a/drivers/hwmon/sht15.c
+++ b/drivers/hwmon/sht15.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Commands */
 #define SHT15_MEASURE_TEMP 0x03
@@ -173,19 +174,6 @@ struct sht15_data {
 };
 
 /**
- * sht15_reverse() - reverse a byte
- * @byte:byte to reverse.
- */
-static u8 sht15_reverse(u8 byte)
-{
-   u8 i, c;
-
-   for (c = 0, i = 0; i < 8; i++)
-   c |= (!!(byte & (1 << i))) << (7 - i);
-   return c;
-}
-
-/**
  * sht15_crc8() - compute crc8
  * @data:  sht15 specific data.
  * @value: sht15 retrieved data.
@@ -196,7 +184,7 @@ static u8 sht15_crc8(struct sht15_data *data,
const u8 *value,
int len)
 {
-   u8 crc = sht15_reverse(data->val_status & 0x0F);
+   u8 crc = bitrev8(data->val_status & 0x0F);
 
while (len--) {
crc = sht15_crc8_table[*value ^ crc];
@@ -477,7 +465,7 @@ static int sht15_update_status(struct sht15_data *data)
 
if (data->checksumming) {
sht15_ack(data);
-   dev_checksum = sht15_reverse(sht15_read_byte(data));
+   dev_checksum = bitrev8(sht15_read_byte(data));
checksum_vals[0] = SHT15_READ_STATUS;
checksum_vals[1] = status;
data->checksum_ok = (sht15_crc8(data, checksum_vals, 2)
@@ -864,7 +852,7 @@ static void sht15_bh_read_data(struct work_struct *work_s)
 */
if (sht15_ack(data))
goto wakeup;
-   dev_checksum = sht15_reverse(sht15_read_byte(data));
+   dev_checksum = bitrev8(sht15_read_byte(data));
checksum_vals[0] = (data->state == SHT15_READING_TEMP) ?
SHT15_MEASURE_TEMP : SHT15_MEASURE_RH;
checksum_vals[1] = (u8) (val >> 8);
-- 
1.9.1

yalin@ubuntu:~/linux-next$ 

--
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] fbdev/nvidia:change reverse_order() macro

[yalin wang]

This change reverse_order() to swab32(bitrev32()), so that
it can have better performance on some platforms.

Signed-off-by: yalin wang 
---
 drivers/video/fbdev/nvidia/nv_accel.c |  4 ++--
 drivers/video/fbdev/nvidia/nv_local.h | 13 -
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/nvidia/nv_accel.c 
b/drivers/video/fbdev/nvidia/nv_accel.c
index ad6472a..c21cb34 100644
--- a/drivers/video/fbdev/nvidia/nv_accel.c
+++ b/drivers/video/fbdev/nvidia/nv_accel.c
@@ -382,7 +382,7 @@ static void nvidiafb_mono_color_expand(struct fb_info *info,
 
for (j = RECT_EXPAND_TWO_COLOR_DATA_MAX_DWORDS; j--;) {
tmp = data[k++];
-   reverse_order();
+   tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
}
 
@@ -394,7 +394,7 @@ static void nvidiafb_mono_color_expand(struct fb_info *info,
 
for (j = dsize; j--;) {
tmp = data[k++];
-   reverse_order();
+   tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
}
}
diff --git a/drivers/video/fbdev/nvidia/nv_local.h 
b/drivers/video/fbdev/nvidia/nv_local.h
index 68e508d..a0eb1f3 100644
--- a/drivers/video/fbdev/nvidia/nv_local.h
+++ b/drivers/video/fbdev/nvidia/nv_local.h
@@ -97,18 +97,13 @@
 
 #ifdef __LITTLE_ENDIAN
 
+#include 
 #include 
 
-#define reverse_order(l)\
-do {\
-   u8 *a = (u8 *)(l);  \
-   a[0] = bitrev8(a[0]);   \
-   a[1] = bitrev8(a[1]);   \
-   a[2] = bitrev8(a[2]);   \
-   a[3] = bitrev8(a[3]);   \
-} while(0)
+#define reverse_order(v)   swab32(bitrev32(v))
+
 #else
-#define reverse_order(l) do { } while(0)
+#define reverse_order(v)   (v)
 #endif  /* __LITTLE_ENDIAN */
 
 #endif /* __NV_LOCAL_H__ */
-- 
1.9.1

--
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/

[RFC] fbdev/riva:change to use generice function to implement reverse_order()

[yalin wang]

This change to use swab32(bitrev32()) to implement reverse_order()
function, have better performance on some platforms.

Signed-off-by: yalin wang 
---
 drivers/video/fbdev/riva/fbdev.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index f1ad274..4803901 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #ifdef CONFIG_PMAC_BACKLIGHT
 #include 
@@ -84,6 +85,7 @@
 #define SetBit(n)  (1<<(n))
 #define Set8Bits(value)((value)&0xff)
 
+#define reverse_order(v) swab32(bitrev32(v))
 /* HW cursor parameters */
 #define MAX_CURS   32
 
@@ -451,15 +453,6 @@ static inline unsigned char MISCin(struct riva_par *par)
return (VGA_RD08(par->riva.PVIO, 0x3cc));
 }
 
-static inline void reverse_order(u32 *l)
-{
-   u8 *a = (u8 *)l;
-   a[0] = bitrev8(a[0]);
-   a[1] = bitrev8(a[1]);
-   a[2] = bitrev8(a[2]);
-   a[3] = bitrev8(a[3]);
-}
-
 /* - *
  *
  * cursor stuff
@@ -497,8 +490,8 @@ static void rivafb_load_cursor_image(struct riva_par *par, 
u8 *data8,
 
for (i = 0; i < h; i++) {
b = *data++;
-   reverse_order();
-   
+   b = reverse_order(b);
+
for (j = 0; j < w/2; j++) {
tmp = 0;
 #if defined (__BIG_ENDIAN)
@@ -1545,7 +1538,7 @@ static void rivafb_imageblit(struct fb_info *info,
for (i = 0; i < 16; i++) {
tmp = *((u32 *)cdat);
cdat = (u8 *)((u32 *)cdat + 1);
-   reverse_order();
+   tmp = reverse_order(tmp);
NV_WR32(d, i*4, tmp);
}
size -= 16;
@@ -1555,7 +1548,7 @@ static void rivafb_imageblit(struct fb_info *info,
for (i = 0; i < size; i++) {
tmp = *((u32 *) cdat);
cdat = (u8 *)((u32 *)cdat + 1);
-   reverse_order();
+   tmp = reverse_order(tmp);
NV_WR32(d, i*4, tmp);
}
}
-- 
1.9.1

--
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/

[RFC] bmac:change to use bitrev8() generic function

[yalin wang]

This change to use generic bitrev8() for bmac driver.

Signed-off-by: yalin wang 
---
 drivers/net/ethernet/apple/bmac.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/apple/bmac.c 
b/drivers/net/ethernet/apple/bmac.c
index a65d7a6..e749747 100644
--- a/drivers/net/ethernet/apple/bmac.c
+++ b/drivers/net/ethernet/apple/bmac.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -805,18 +806,6 @@ static irqreturn_t bmac_txdma_intr(int irq, void *dev_id)
 }
 
 #ifndef SUNHME_MULTICAST
-/* Real fast bit-reversal algorithm, 6-bit values */
-static int reverse6[64] = {
-   0x0,0x20,0x10,0x30,0x8,0x28,0x18,0x38,
-   0x4,0x24,0x14,0x34,0xc,0x2c,0x1c,0x3c,
-   0x2,0x22,0x12,0x32,0xa,0x2a,0x1a,0x3a,
-   0x6,0x26,0x16,0x36,0xe,0x2e,0x1e,0x3e,
-   0x1,0x21,0x11,0x31,0x9,0x29,0x19,0x39,
-   0x5,0x25,0x15,0x35,0xd,0x2d,0x1d,0x3d,
-   0x3,0x23,0x13,0x33,0xb,0x2b,0x1b,0x3b,
-   0x7,0x27,0x17,0x37,0xf,0x2f,0x1f,0x3f
-};
-
 static unsigned int
 crc416(unsigned int curval, unsigned short nxtval)
 {
@@ -871,7 +860,7 @@ bmac_addhash(struct bmac_data *bp, unsigned char *addr)
 
if (!(*addr)) return;
crc = bmac_crc((unsigned short *)addr) & 0x3f; /* Big-endian alert! */
-   crc = reverse6[crc];/* Hyperfast bit-reversing algorithm */
+   crc = bitrev8((u8)crc);
if (bp->hash_use_count[crc]++) return; /* This bit is already set */
mask = crc % 16;
mask = (unsigned char)1 << mask;
@@ -886,7 +875,7 @@ bmac_removehash(struct bmac_data *bp, unsigned char *addr)
 
/* Now, delete the address from the filter copy, as indicated */
crc = bmac_crc((unsigned short *)addr) & 0x3f; /* Big-endian alert! */
-   crc = reverse6[crc];/* Hyperfast bit-reversing algorithm */
+   crc = bitrev8((u8)crc);
if (bp->hash_use_count[crc] == 0) return; /* That bit wasn't in use! */
if (--bp->hash_use_count[crc]) return; /* That bit is still in use */
mask = crc % 16;
-- 
1.9.1
--
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] isdn:remove reverse_bits(), use revbit8()

[yalin wang]

This change isdn driver, remove reverse_bits() function,
use the generic revbit8() function instead.

Signed-off-by: yalin wang 
---
 drivers/isdn/mISDN/dsp_audio.c | 22 +-
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/drivers/isdn/mISDN/dsp_audio.c b/drivers/isdn/mISDN/dsp_audio.c
index 0602295..bbef98e 100644
--- a/drivers/isdn/mISDN/dsp_audio.c
+++ b/drivers/isdn/mISDN/dsp_audio.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "core.h"
 #include "dsp.h"
 
@@ -137,27 +138,14 @@ static unsigned char linear2ulaw(short sample)
return ulawbyte;
 }
 
-static int reverse_bits(int i)
-{
-   int z, j;
-   z = 0;
-
-   for (j = 0; j < 8; j++) {
-   if ((i & (1 << j)) != 0)
-   z |= 1 << (7 - j);
-   }
-   return z;
-}
-
-
 void dsp_audio_generate_law_tables(void)
 {
int i;
for (i = 0; i < 256; i++)
-   dsp_audio_alaw_to_s32[i] = alaw2linear(reverse_bits(i));
+   dsp_audio_alaw_to_s32[i] = alaw2linear(bitrev8((u8)i));
 
for (i = 0; i < 256; i++)
-   dsp_audio_ulaw_to_s32[i] = ulaw2linear(reverse_bits(i));
+   dsp_audio_ulaw_to_s32[i] = ulaw2linear(bitrev8((u8)i));
 
for (i = 0; i < 256; i++) {
dsp_audio_alaw_to_ulaw[i] =
@@ -176,13 +164,13 @@ dsp_audio_generate_s2law_table(void)
/* generating ulaw-table */
for (i = -32768; i < 32768; i++) {
dsp_audio_s16_to_law[i & 0x] =
-   reverse_bits(linear2ulaw(i));
+   bitrev8(linear2ulaw(i));
}
} else {
/* generating alaw-table */
for (i = -32768; i < 32768; i++) {
dsp_audio_s16_to_law[i & 0x] =
-   reverse_bits(linear2alaw(i));
+   bitrev8(linear2alaw(i));
}
}
 }
-- 
1.9.1

--
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/fddi: remove HWM_REVERSE() macro

[yalin wang]

 On Aug 11, 2015, at 12:24, David Miller da...@davemloft.net wrote:
 
 From: yalin wang yalin.wang2...@gmail.com
 Date: Tue, 11 Aug 2015 09:57:21 +0800
 
 HWM_REVERSE() macro is unused, remove it.
 
 Signed-off-by: yalin wang yalin.wang2...@gmail.com
 
 Your email client has corrupted this patch.
 
 Please read Documentation/email-clients.txt, send a test patch to yourself,
 and only resubmit this change once you are able to successfully apply the
 patch you receive in that test email.
 
 Thanks.
ok, Thanks.
--
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 v2 Resend] net/fddi: remove HWM_REVERSE() macro

[yalin wang]

HWM_REVERSE() macro is unused, remove it.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
drivers/net/fddi/skfp/h/hwmtm.h | 10 --
1 file changed, 10 deletions(-)

diff --git a/drivers/net/fddi/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h
index 5924d42..4ca2341 100644
--- a/drivers/net/fddi/skfp/h/hwmtm.h
+++ b/drivers/net/fddi/skfp/h/hwmtm.h
@@ -74,15 +74,6 @@
#define NULL   0
#endif

-#ifdef LITTLE_ENDIAN
-#define HWM_REVERSE(x) (x)
-#else
-#defineHWM_REVERSE(x)  x)24L)0xff00L)   +   
\
-(((x) 8L)0x00ffL)   +   \
-(((x) 8L)0xff00L)   +   \
-(((x)24L)0x00ffL))
-#endif
-
#define C_INDIC(1L25)
#define A_INDIC(1L26)
#defineRD_FS_LOCAL 0x80
-- 
1.9.1


--
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] zlib_deflate/deftree: Remove bi_reverse()

[yalin wang]

This change remove bi_reverse() and use generic bitrev32() instead,
have better performance on some platforms.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 lib/zlib_deflate/deftree.c |  6 +++---
 lib/zlib_deflate/defutil.h | 16 
 2 files changed, 3 insertions(+), 19 deletions(-)

diff --git a/lib/zlib_deflate/deftree.c b/lib/zlib_deflate/deftree.c
index ddf3482..9b1756b 100644
--- a/lib/zlib_deflate/deftree.c
+++ b/lib/zlib_deflate/deftree.c
@@ -35,6 +35,7 @@
 /* #include deflate.h */
 
 #include linux/zutil.h
+#include linux/bitrev.h
 #include defutil.h
 
 #ifdef DEBUG_ZLIB
@@ -146,7 +147,6 @@ static void send_all_trees (deflate_state *s, int lcodes, 
int dcodes,
 static void compress_block (deflate_state *s, ct_data *ltree,
ct_data *dtree);
 static void set_data_type  (deflate_state *s);
-static unsigned bi_reverse (unsigned value, int length);
 static void bi_windup  (deflate_state *s);
 static void bi_flush   (deflate_state *s);
 static void copy_block (deflate_state *s, char *buf, unsigned len,
@@ -284,7 +284,7 @@ static void tr_static_init(void)
 /* The static distance tree is trivial: */
 for (n = 0; n  D_CODES; n++) {
 static_dtree[n].Len = 5;
-static_dtree[n].Code = bi_reverse((unsigned)n, 5);
+static_dtree[n].Code = bitrev32((u32)n)  (32 - 5);
 }
 static_init_done = 1;
 }
@@ -520,7 +520,7 @@ static void gen_codes(
 int len = tree[n].Len;
 if (len == 0) continue;
 /* Now reverse the bits */
-tree[n].Code = bi_reverse(next_code[len]++, len);
+tree[n].Code = bitrev32((u32)(next_code[len]++))  (32 - len);
 
 Tracecv(tree != static_ltree, (stderr,\nn %3d %c l %2d c %4x (%x) ,
  n, (isgraph(n) ? n : ' '), len, tree[n].Code, next_code[len]-1));
diff --git a/lib/zlib_deflate/defutil.h b/lib/zlib_deflate/defutil.h
index b640b64..a8c3708 100644
--- a/lib/zlib_deflate/defutil.h
+++ b/lib/zlib_deflate/defutil.h
@@ -293,22 +293,6 @@ void zlib_tr_stored_type_only (deflate_state *);
 }
 
 /* ===
- * Reverse the first len bits of a code, using straightforward code (a faster
- * method would use a table)
- * IN assertion: 1 = len = 15
- */
-static inline unsigned bi_reverse(unsigned code, /* the value to invert */
- int len)   /* its bit length */
-{
-register unsigned res = 0;
-do {
-res |= code  1;
-code = 1, res = 1;
-} while (--len  0);
-return res  1;
-}
-
-/* ===
  * Flush the bit buffer, keeping at most 7 bits in it.
  */
 static inline void bi_flush(deflate_state *s)
-- 
1.9.1

--
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] joystick/zhenhua: remove zhenhua_bitreverse()

[yalin wang]

This change remove zhenhua_bitreverse() function, use generic
bitrev8() function instead.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/input/joystick/zhenhua.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/input/joystick/zhenhua.c b/drivers/input/joystick/zhenhua.c
index 30af2e8..4a8258b 100644
--- a/drivers/input/joystick/zhenhua.c
+++ b/drivers/input/joystick/zhenhua.c
@@ -47,6 +47,7 @@
 #include linux/kernel.h
 #include linux/module.h
 #include linux/slab.h
+#include linux/bitrev.h
 #include linux/input.h
 #include linux/serio.h
 
@@ -72,16 +73,6 @@ struct zhenhua {
char phys[32];
 };
 
-
-/* bits in all incoming bytes needs to be reversed */
-static int zhenhua_bitreverse(int x)
-{
-   x = ((x  0xaa)  1) | ((x  0x55)  1);
-   x = ((x  0xcc)  2) | ((x  0x33)  2);
-   x = ((x  0xf0)  4) | ((x  0x0f)  4);
-   return x;
-}
-
 /*
  * zhenhua_process_packet() decodes packets the driver receives from the
  * RC transmitter. It updates the data accordingly.
@@ -120,7 +111,7 @@ static irqreturn_t zhenhua_interrupt(struct serio *serio, 
unsigned char data, un
return IRQ_HANDLED; /* wrong MSB -- ignore this byte */
 
if (zhenhua-idx  ZHENHUA_MAX_LENGTH)
-   zhenhua-data[zhenhua-idx++] = zhenhua_bitreverse(data);
+   zhenhua-data[zhenhua-idx++] = bitrev8(data);
 
if (zhenhua-idx == ZHENHUA_MAX_LENGTH) {
zhenhua_process_packet(zhenhua);
-- 
1.9.1
--
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 Resend] net/fddi: remove HWM_REVERSE() macro

[yalin wang]

 On Aug 11, 2015, at 13:37, David Miller da...@davemloft.net wrote:
 
 From: yalin wang yalin.wang2...@gmail.com
 Date: Tue, 11 Aug 2015 13:11:22 +0800
 
 HWM_REVERSE() macro is unused, remove it.
 
 Signed-off-by: yalin wang yalin.wang2...@gmail.com
 
 You did not do as I asked you to, this patch is still corrupted
 and there is no way you successfully applied what is in this patch.
 
 -#defineHWM_REVERSE(x)  x)24L)0xff00L)   +
\
 -(((x) 8L)0x00ffL)   +   \
 -(((x) 8L)0xff00L)   +   \
 -(((x)24L)0x00ffL))
 
 This indentation here is spaces, whereas in the source files they
 are TABS.
 
 Your email client did this.
 
 If you fail to properly verify that your outgoing patches are not
 corrupted before submitting them here, I will stop reviewing and
 considering your changes.
 
 Thank you.
ouch,  i am sorry that i am sending from windows PC,
let me check that .
Sorry for that .--
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/fddi:change HWM_REVERSE() macro

[yalin wang]

change HWM_REVERSE() macro to generic le32_to_cpu()

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/net/fddi/skfp/h/hwmtm.h | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/net/fddi/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h
index 5924d42..72701ef 100644
--- a/drivers/net/fddi/skfp/h/hwmtm.h
+++ b/drivers/net/fddi/skfp/h/hwmtm.h
@@ -14,7 +14,7 @@
 
 #ifndef_HWM_
 #define_HWM_
-
+#include linux/byteorder/generic.h
 #include mbuf.h
 
 /*
@@ -74,14 +74,7 @@
 #define NULL   0
 #endif
 
-#ifdef LITTLE_ENDIAN
-#define HWM_REVERSE(x) (x)
-#else
-#defineHWM_REVERSE(x)  x)24L)0xff00L)   +   
\
-(((x) 8L)0x00ffL)   +   \
-(((x) 8L)0xff00L)   +   \
-(((x)24L)0x00ffL))
-#endif
+#define HWM_REVERSE(x) le32_to_cpu(x)
 
 #define C_INDIC(1L25)
 #define A_INDIC(1L26)
-- 
1.9.1



--
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] lib/zlib_inflate:change REVERSE() macro

[yalin wang]

This patch change REVERSE() macro to use swab32() function,
so that can have more better performance on some platforms.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
lib/zlib_inflate/inflate.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/lib/zlib_inflate/inflate.c b/lib/zlib_inflate/inflate.c
index 58a733b..f2b68b6 100644
--- a/lib/zlib_inflate/inflate.c
+++ b/lib/zlib_inflate/inflate.c
@@ -10,6 +10,7 @@
 */

#include linux/zutil.h
+#include linux/swab.h
#include inftrees.h
#include inflate.h
#include inffast.h
@@ -228,10 +229,7 @@ static int zlib_inflateSyncPacket(z_streamp strm)
} while (0)

/* Reverse the bytes in a 32-bit value */
-#define REVERSE(q) \
-q)  24)  0xff) + (((q)  8)  0xff00) + \
- (((q)  0xff00)  8) + (((q)  0xff)  24))
-
+#define REVERSE(q)  swab32(q)
/*
   inflate() uses a state machine to process as much input data and generate as
   much output data as possible before returning.  The state machine is
-- 
1.9.1

--
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] hwmon:change sht15_reverse()

[yalin wang]

This change sht15_reverse() to be generic bitrev8().

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/hwmon/sht15.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/hwmon/sht15.c b/drivers/hwmon/sht15.c
index 497a7f8..a2fdbb7 100644
--- a/drivers/hwmon/sht15.c
+++ b/drivers/hwmon/sht15.c
@@ -33,6 +33,7 @@
 #include linux/regulator/consumer.h
 #include linux/slab.h
 #include linux/atomic.h
+#include linux/bitrev.h
 
 /* Commands */
 #define SHT15_MEASURE_TEMP 0x03
@@ -173,19 +174,6 @@ struct sht15_data {
 };
 
 /**
- * sht15_reverse() - reverse a byte
- * @byte:byte to reverse.
- */
-static u8 sht15_reverse(u8 byte)
-{
-   u8 i, c;
-
-   for (c = 0, i = 0; i  8; i++)
-   c |= (!!(byte  (1  i)))  (7 - i);
-   return c;
-}
-
-/**
  * sht15_crc8() - compute crc8
  * @data:  sht15 specific data.
  * @value: sht15 retrieved data.
@@ -196,7 +184,7 @@ static u8 sht15_crc8(struct sht15_data *data,
const u8 *value,
int len)
 {
-   u8 crc = sht15_reverse(data-val_status  0x0F);
+   u8 crc = bitrev8(data-val_status  0x0F);
 
while (len--) {
crc = sht15_crc8_table[*value ^ crc];
@@ -477,7 +465,7 @@ static int sht15_update_status(struct sht15_data *data)
 
if (data-checksumming) {
sht15_ack(data);
-   dev_checksum = sht15_reverse(sht15_read_byte(data));
+   dev_checksum = bitrev8(sht15_read_byte(data));
checksum_vals[0] = SHT15_READ_STATUS;
checksum_vals[1] = status;
data-checksum_ok = (sht15_crc8(data, checksum_vals, 2)
@@ -864,7 +852,7 @@ static void sht15_bh_read_data(struct work_struct *work_s)
 */
if (sht15_ack(data))
goto wakeup;
-   dev_checksum = sht15_reverse(sht15_read_byte(data));
+   dev_checksum = bitrev8(sht15_read_byte(data));
checksum_vals[0] = (data-state == SHT15_READING_TEMP) ?
SHT15_MEASURE_TEMP : SHT15_MEASURE_RH;
checksum_vals[1] = (u8) (val  8);
-- 
1.9.1

yalin@ubuntu:~/linux-next$ 

--
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: [RFC] bmac:change to use bitrev8() generic function

[yalin wang]

 On Aug 10, 2015, at 20:02, David Laight david.lai...@aculab.com wrote:
 
 From: Tobias Klauser
 Sent: 10 August 2015 12:49
 On 2015-08-10 at 11:53:41 +0200, yalin wang yalin.wang2...@gmail.com wrote:
 This change to use generic bitrev8() for bmac driver.
 ...
 @@ -871,7 +860,7 @@ bmac_addhash(struct bmac_data *bp, unsigned char *addr)
 
 if (!(*addr)) return;
 crc = bmac_crc((unsigned short *)addr)  0x3f; /* Big-endian alert! */
 
 Why not *((u8 *)addr + 1)  0x3f
 
 -   crc = reverse6[crc];/* Hyperfast bit-reversing algorithm */
 +   crc = bitrev8((u8)crc);
 
 No, this won't work. reverse6 works on 6 bit values, while bitrev8 works
 on 8bit values, e.g. reverse6[1] = 0x20, while bitrev8(1) = 0x80
 
 You could use bitrev8(n)  2.
 
 But that is a 'strange' map of a 7-bit value to a 6-bit one.
 
 I thought it was more common for ethernet hardware to use the
 value of the crc register after all 6 bytes of the mac address
 had been processed.
oh, my mistake, i will change it in V2 for review.--
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/

[RFC V2] bmac:change to use bitrev8() generic function

[yalin wang]

This change to use generic bitrev8() for bmac driver.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/net/ethernet/apple/bmac.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/apple/bmac.c 
b/drivers/net/ethernet/apple/bmac.c
index a65d7a6..7f7a398 100644
--- a/drivers/net/ethernet/apple/bmac.c
+++ b/drivers/net/ethernet/apple/bmac.c
@@ -22,6 +22,7 @@
 #include linux/bitrev.h
 #include linux/ethtool.h
 #include linux/slab.h
+#include linux/bitrev.h
 #include asm/prom.h
 #include asm/dbdma.h
 #include asm/io.h
@@ -805,18 +806,6 @@ static irqreturn_t bmac_txdma_intr(int irq, void *dev_id)
 }
 
 #ifndef SUNHME_MULTICAST
-/* Real fast bit-reversal algorithm, 6-bit values */
-static int reverse6[64] = {
-   0x0,0x20,0x10,0x30,0x8,0x28,0x18,0x38,
-   0x4,0x24,0x14,0x34,0xc,0x2c,0x1c,0x3c,
-   0x2,0x22,0x12,0x32,0xa,0x2a,0x1a,0x3a,
-   0x6,0x26,0x16,0x36,0xe,0x2e,0x1e,0x3e,
-   0x1,0x21,0x11,0x31,0x9,0x29,0x19,0x39,
-   0x5,0x25,0x15,0x35,0xd,0x2d,0x1d,0x3d,
-   0x3,0x23,0x13,0x33,0xb,0x2b,0x1b,0x3b,
-   0x7,0x27,0x17,0x37,0xf,0x2f,0x1f,0x3f
-};
-
 static unsigned int
 crc416(unsigned int curval, unsigned short nxtval)
 {
@@ -871,7 +860,7 @@ bmac_addhash(struct bmac_data *bp, unsigned char *addr)
 
if (!(*addr)) return;
crc = bmac_crc((unsigned short *)addr)  0x3f; /* Big-endian alert! */
-   crc = reverse6[crc];/* Hyperfast bit-reversing algorithm */
+   crc = bitrev8((u8)crc)  2;
if (bp-hash_use_count[crc]++) return; /* This bit is already set */
mask = crc % 16;
mask = (unsigned char)1  mask;
@@ -886,7 +875,7 @@ bmac_removehash(struct bmac_data *bp, unsigned char *addr)
 
/* Now, delete the address from the filter copy, as indicated */
crc = bmac_crc((unsigned short *)addr)  0x3f; /* Big-endian alert! */
-   crc = reverse6[crc];/* Hyperfast bit-reversing algorithm */
+   crc = bitrev8((u8)crc)  2;
if (bp-hash_use_count[crc] == 0) return; /* That bit wasn't in use! */
if (--bp-hash_use_count[crc]) return; /* That bit is still in use */
mask = crc % 16;
-- 
1.9.1
--
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] isdn:remove reverse_bits(), use revbit8()

[yalin wang]

 On Aug 11, 2015, at 05:30, David Miller da...@davemloft.net wrote:
 
 From: yalin wang yalin.wang2...@gmail.com
 Date: Mon, 10 Aug 2015 17:15:57 +0800
 
 This change isdn driver, remove reverse_bits() function,
 use the generic revbit8() function instead.
 
 Signed-off-by: yalin wang yalin.wang2...@gmail.com
 
 Applied, however please format your Subject lines better in the
 future.
 
 There should be a space after the subsystem specifier and the ':'
 character.  So isdn: 
 
 Then you should capitalize the description in the Subject line
 because it is very much like an English sentence.
i see,
Thanks for your kindly remind !
--
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] net/fddi:change HWM_REVERSE() macro

[yalin wang]

 On Aug 11, 2015, at 00:36, Joe Perches j...@perches.com wrote:
 
 On Tue, 2015-08-11 at 00:14 +0800, yalin wang wrote:
 HWM_REVERSE
 
 Is unused and it would be better if removed.
 
ok,  i will send V2 patch .
--
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 v2] net/fddi: remove HWM_REVERSE() macro

[yalin wang]

 HWM_REVERSE() macro is unused, remove it.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/net/fddi/skfp/h/hwmtm.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/net/fddi/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h
index 5924d42..4ca2341 100644
--- a/drivers/net/fddi/skfp/h/hwmtm.h
+++ b/drivers/net/fddi/skfp/h/hwmtm.h
@@ -74,15 +74,6 @@
 #define NULL   0
 #endif
 
-#ifdef LITTLE_ENDIAN
-#define HWM_REVERSE(x) (x)
-#else
-#defineHWM_REVERSE(x)  x)24L)0xff00L)   +   
\
-(((x) 8L)0x00ffL)   +   \
-(((x) 8L)0xff00L)   +   \
-(((x)24L)0x00ffL))
-#endif
-
 #define C_INDIC(1L25)
 #define A_INDIC(1L26)
 #defineRD_FS_LOCAL 0x80
-- 
1.9.1

--
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] isdn:remove reverse_bits(), use revbit8()

[yalin wang]

This change isdn driver, remove reverse_bits() function,
use the generic revbit8() function instead.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/isdn/mISDN/dsp_audio.c | 22 +-
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/drivers/isdn/mISDN/dsp_audio.c b/drivers/isdn/mISDN/dsp_audio.c
index 0602295..bbef98e 100644
--- a/drivers/isdn/mISDN/dsp_audio.c
+++ b/drivers/isdn/mISDN/dsp_audio.c
@@ -13,6 +13,7 @@
 #include linux/mISDNif.h
 #include linux/mISDNdsp.h
 #include linux/export.h
+#include linux/bitrev.h
 #include core.h
 #include dsp.h
 
@@ -137,27 +138,14 @@ static unsigned char linear2ulaw(short sample)
return ulawbyte;
 }
 
-static int reverse_bits(int i)
-{
-   int z, j;
-   z = 0;
-
-   for (j = 0; j  8; j++) {
-   if ((i  (1  j)) != 0)
-   z |= 1  (7 - j);
-   }
-   return z;
-}
-
-
 void dsp_audio_generate_law_tables(void)
 {
int i;
for (i = 0; i  256; i++)
-   dsp_audio_alaw_to_s32[i] = alaw2linear(reverse_bits(i));
+   dsp_audio_alaw_to_s32[i] = alaw2linear(bitrev8((u8)i));
 
for (i = 0; i  256; i++)
-   dsp_audio_ulaw_to_s32[i] = ulaw2linear(reverse_bits(i));
+   dsp_audio_ulaw_to_s32[i] = ulaw2linear(bitrev8((u8)i));
 
for (i = 0; i  256; i++) {
dsp_audio_alaw_to_ulaw[i] =
@@ -176,13 +164,13 @@ dsp_audio_generate_s2law_table(void)
/* generating ulaw-table */
for (i = -32768; i  32768; i++) {
dsp_audio_s16_to_law[i  0x] =
-   reverse_bits(linear2ulaw(i));
+   bitrev8(linear2ulaw(i));
}
} else {
/* generating alaw-table */
for (i = -32768; i  32768; i++) {
dsp_audio_s16_to_law[i  0x] =
-   reverse_bits(linear2alaw(i));
+   bitrev8(linear2alaw(i));
}
}
 }
-- 
1.9.1

--
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/

[RFC] bmac:change to use bitrev8() generic function

[yalin wang]

This change to use generic bitrev8() for bmac driver.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/net/ethernet/apple/bmac.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/apple/bmac.c 
b/drivers/net/ethernet/apple/bmac.c
index a65d7a6..e749747 100644
--- a/drivers/net/ethernet/apple/bmac.c
+++ b/drivers/net/ethernet/apple/bmac.c
@@ -22,6 +22,7 @@
 #include linux/bitrev.h
 #include linux/ethtool.h
 #include linux/slab.h
+#include linux/bitrev.h
 #include asm/prom.h
 #include asm/dbdma.h
 #include asm/io.h
@@ -805,18 +806,6 @@ static irqreturn_t bmac_txdma_intr(int irq, void *dev_id)
 }
 
 #ifndef SUNHME_MULTICAST
-/* Real fast bit-reversal algorithm, 6-bit values */
-static int reverse6[64] = {
-   0x0,0x20,0x10,0x30,0x8,0x28,0x18,0x38,
-   0x4,0x24,0x14,0x34,0xc,0x2c,0x1c,0x3c,
-   0x2,0x22,0x12,0x32,0xa,0x2a,0x1a,0x3a,
-   0x6,0x26,0x16,0x36,0xe,0x2e,0x1e,0x3e,
-   0x1,0x21,0x11,0x31,0x9,0x29,0x19,0x39,
-   0x5,0x25,0x15,0x35,0xd,0x2d,0x1d,0x3d,
-   0x3,0x23,0x13,0x33,0xb,0x2b,0x1b,0x3b,
-   0x7,0x27,0x17,0x37,0xf,0x2f,0x1f,0x3f
-};
-
 static unsigned int
 crc416(unsigned int curval, unsigned short nxtval)
 {
@@ -871,7 +860,7 @@ bmac_addhash(struct bmac_data *bp, unsigned char *addr)
 
if (!(*addr)) return;
crc = bmac_crc((unsigned short *)addr)  0x3f; /* Big-endian alert! */
-   crc = reverse6[crc];/* Hyperfast bit-reversing algorithm */
+   crc = bitrev8((u8)crc);
if (bp-hash_use_count[crc]++) return; /* This bit is already set */
mask = crc % 16;
mask = (unsigned char)1  mask;
@@ -886,7 +875,7 @@ bmac_removehash(struct bmac_data *bp, unsigned char *addr)
 
/* Now, delete the address from the filter copy, as indicated */
crc = bmac_crc((unsigned short *)addr)  0x3f; /* Big-endian alert! */
-   crc = reverse6[crc];/* Hyperfast bit-reversing algorithm */
+   crc = bitrev8((u8)crc);
if (bp-hash_use_count[crc] == 0) return; /* That bit wasn't in use! */
if (--bp-hash_use_count[crc]) return; /* That bit is still in use */
mask = crc % 16;
-- 
1.9.1
--
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/

[RFC] fbdev/riva:change to use generice function to implement reverse_order()

[yalin wang]

This change to use swab32(bitrev32()) to implement reverse_order()
function, have better performance on some platforms.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/video/fbdev/riva/fbdev.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index f1ad274..4803901 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -40,6 +40,7 @@
 #include linux/init.h
 #include linux/pci.h
 #include linux/backlight.h
+#include linux/swab.h
 #include linux/bitrev.h
 #ifdef CONFIG_PMAC_BACKLIGHT
 #include asm/machdep.h
@@ -84,6 +85,7 @@
 #define SetBit(n)  (1(n))
 #define Set8Bits(value)((value)0xff)
 
+#define reverse_order(v) swab32(bitrev32(v))
 /* HW cursor parameters */
 #define MAX_CURS   32
 
@@ -451,15 +453,6 @@ static inline unsigned char MISCin(struct riva_par *par)
return (VGA_RD08(par-riva.PVIO, 0x3cc));
 }
 
-static inline void reverse_order(u32 *l)
-{
-   u8 *a = (u8 *)l;
-   a[0] = bitrev8(a[0]);
-   a[1] = bitrev8(a[1]);
-   a[2] = bitrev8(a[2]);
-   a[3] = bitrev8(a[3]);
-}
-
 /* - *
  *
  * cursor stuff
@@ -497,8 +490,8 @@ static void rivafb_load_cursor_image(struct riva_par *par, 
u8 *data8,
 
for (i = 0; i  h; i++) {
b = *data++;
-   reverse_order(b);
-   
+   b = reverse_order(b);
+
for (j = 0; j  w/2; j++) {
tmp = 0;
 #if defined (__BIG_ENDIAN)
@@ -1545,7 +1538,7 @@ static void rivafb_imageblit(struct fb_info *info,
for (i = 0; i  16; i++) {
tmp = *((u32 *)cdat);
cdat = (u8 *)((u32 *)cdat + 1);
-   reverse_order(tmp);
+   tmp = reverse_order(tmp);
NV_WR32(d, i*4, tmp);
}
size -= 16;
@@ -1555,7 +1548,7 @@ static void rivafb_imageblit(struct fb_info *info,
for (i = 0; i  size; i++) {
tmp = *((u32 *) cdat);
cdat = (u8 *)((u32 *)cdat + 1);
-   reverse_order(tmp);
+   tmp = reverse_order(tmp);
NV_WR32(d, i*4, tmp);
}
}
-- 
1.9.1

--
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] fbdev/nvidia:change reverse_order() macro

[yalin wang]

This change reverse_order() to swab32(bitrev32()), so that
it can have better performance on some platforms.

Signed-off-by: yalin wang yalin.wang2...@gmail.com
---
 drivers/video/fbdev/nvidia/nv_accel.c |  4 ++--
 drivers/video/fbdev/nvidia/nv_local.h | 13 -
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/nvidia/nv_accel.c 
b/drivers/video/fbdev/nvidia/nv_accel.c
index ad6472a..c21cb34 100644
--- a/drivers/video/fbdev/nvidia/nv_accel.c
+++ b/drivers/video/fbdev/nvidia/nv_accel.c
@@ -382,7 +382,7 @@ static void nvidiafb_mono_color_expand(struct fb_info *info,
 
for (j = RECT_EXPAND_TWO_COLOR_DATA_MAX_DWORDS; j--;) {
tmp = data[k++];
-   reverse_order(tmp);
+   tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
}
 
@@ -394,7 +394,7 @@ static void nvidiafb_mono_color_expand(struct fb_info *info,
 
for (j = dsize; j--;) {
tmp = data[k++];
-   reverse_order(tmp);
+   tmp = reverse_order(tmp);
NVDmaNext(par, tmp);
}
}
diff --git a/drivers/video/fbdev/nvidia/nv_local.h 
b/drivers/video/fbdev/nvidia/nv_local.h
index 68e508d..a0eb1f3 100644
--- a/drivers/video/fbdev/nvidia/nv_local.h
+++ b/drivers/video/fbdev/nvidia/nv_local.h
@@ -97,18 +97,13 @@
 
 #ifdef __LITTLE_ENDIAN
 
+#include linux/swab.h
 #include linux/bitrev.h
 
-#define reverse_order(l)\
-do {\
-   u8 *a = (u8 *)(l);  \
-   a[0] = bitrev8(a[0]);   \
-   a[1] = bitrev8(a[1]);   \
-   a[2] = bitrev8(a[2]);   \
-   a[3] = bitrev8(a[3]);   \
-} while(0)
+#define reverse_order(v)   swab32(bitrev32(v))
+
 #else
-#define reverse_order(l) do { } while(0)
+#define reverse_order(v)   (v)
 #endif  /* __LITTLE_ENDIAN */
 
 #endif /* __NV_LOCAL_H__ */
-- 
1.9.1

--
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: [RFC] kcore:change kcore_read to make sure the kernel read is safe

[yalin wang]

> On Aug 5, 2015, at 05:18, Dave Hansen  wrote:
> 
> On 08/03/2015 08:37 PM, yalin wang wrote:
>> This change kcore_read() to use __copy_from_user_inatomic() to
>> copy data from kernel address, because kern_addr_valid() just make sure
>> page table is valid during call it, whne it return, the page table may
>> change, for example, like set_fixmap() function will change kernel page
>> table, then maybe trigger kernel crash if encounter this unluckily.
> 
> I don't see any cases at the moment that will crash.  set_fixmap()
> doesn't ever clear out any ptes, right?
> 
> I guess the root problem here is that we don't have any good (generic)
> locking of kernel page tables inside the linear map.  Can you come up
> with a case where this will _actually_ crash?
> 
Thanks for your comments.
i don’t have crash for this, but when i read code, i see this part not safe,
so i make this patch :).

>> fs/proc/kcore.c | 30 --
>> 1 file changed, 24 insertions(+), 6 deletions(-)
>> 
>> diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
>> index 92e6726..b085fde 100644
>> --- a/fs/proc/kcore.c
>> +++ b/fs/proc/kcore.c
>> @@ -86,8 +86,8 @@ static size_t get_kcore_size(int *nphdr, size_t 
>> *elf_buflen)
>>  size = try;
>>  *nphdr = *nphdr + 1;
>>  }
>> -*elf_buflen =   sizeof(struct elfhdr) + 
>> -(*nphdr + 2)*sizeof(struct elf_phdr) + 
>> +*elf_buflen =   sizeof(struct elfhdr) +
>> +(*nphdr + 2)*sizeof(struct elf_phdr) +
> 
> I'm having a hard time spotting the change here.  Whitespace?
i  will seperate in another patch for format correctness.
> 
>>  3 * ((sizeof(struct elf_note)) +
>>   roundup(sizeof(CORE_STR), 4)) +
>>  roundup(sizeof(struct elf_prstatus), 4) +
>> @@ -435,6 +435,7 @@ read_kcore(struct file *file, char __user *buffer, 
>> size_t buflen, loff_t *fpos)
>>  size_t elf_buflen;
>>  int nphdr;
>>  unsigned long start;
>> +unsigned long page = 0;
>> 
>>  read_lock(_lock);
>>  size = get_kcore_size(, _buflen);
>> @@ -485,7 +486,7 @@ read_kcore(struct file *file, char __user *buffer, 
>> size_t buflen, loff_t *fpos)
>>  start = kc_offset_to_vaddr(*fpos - elf_buflen);
>>  if ((tsz = (PAGE_SIZE - (start & ~PAGE_MASK))) > buflen)
>>  tsz = buflen;
>> -
>> +
> 
> Please keep the unnecessary whitespace changes for another patch.
> 
>>  while (buflen) {
>>  struct kcore_list *m;
>> 
>> @@ -515,15 +516,32 @@ read_kcore(struct file *file, char __user *buffer, 
>> size_t buflen, loff_t *fpos)
>>  } else {
>>  if (kern_addr_valid(start)) {
>>  unsigned long n;
>> +mm_segment_t old_fs = get_fs();
>> +
>> +if (page == 0) {
>> +page = __get_free_page(GFP_KERNEL);
>> +if (page == 0)
>> +return -ENOMEM;
> 
> FWIW, we usually code this as "!page" instead of "page == 0".  I also
> wouldn't call it 'page'.
> 
> Also, why is this using a raw __get_free_page() while the code above it
> uses a kmalloc()?
> 
because i am using a page size buffer, more efficient  to use __get_free_page()
than  kmalloc() here .

>> -n = copy_to_user(buffer, (char *)start, tsz);
>> +}
>> +set_fs(KERNEL_DS);
>> +pagefault_disable();
>> +n = __copy_from_user_inatomic((void *)page,
>> +(__force const void __user *)start,
>> +tsz);
>> +pagefault_enable();
>> +set_fs(old_fs);
>> +if (n)
>> +memset((void *)page + tsz - n, 0, n);
>> +
>> +n = copy_to_user(buffer, (char *)page, tsz);
> 
> So, first of all, we are using __copy_from_user_inatomic() to copy to
> and from a *kernel* addresses, and it doesn't even get a comment? :)
> 
i will add comment.
> Fundamentally, we're trying to be able to safely survive faults in the
> kernel linear map here.  I think we'

Re: [RFC] kcore:change kcore_read to make sure the kernel read is safe

[yalin wang]

> On Aug 5, 2015, at 06:38, Andrew Morton  wrote:
> 
> On Tue, 4 Aug 2015 11:37:57 +0800 yalin wang  wrote:
> 
>> This change kcore_read() to use __copy_from_user_inatomic() to
>> copy data from kernel address, because kern_addr_valid() just make sure
>> page table is valid during call it, whne it return, the page table may
>> change, for example, like set_fixmap() function will change kernel page
>> table, then maybe trigger kernel crash if encounter this unluckily.
> 
> The changelog is a bit hard to follow.  How does this version look?
> 
> : read_kcore() does a copy_to_user() from kernel memory.  This could cause a
> : crash if the source (kernel) address is concurrently unmapped via, say,
> : set_fixmap().  The kern_addr_valid() check is racy and won't reliably
> : prevent this.
> : 
> : Change kcore_read() to use __copy_from_user_inatomic() via a temporary
> : buffer to catch such situations.
> 
> What actually happens when copy_to_user() gets a fault on the source
> address?  It *could* handle it and return -EFAULT.  I forget...
> 
> Also...  what is special about this particular copy_to_user()?  Isn't
> every copy_to_user() in the kernel vulnerable to a concurrent
> set_fixmap()?  Is it that only read_kcore() will read pages which are
> subject to set_fixmap() alteration?
> 
Thanks for your great comment .
i agree with your git change log,
one more question, at first i only focus on arm64 arch,
it only check __user* address during copy_from{to}_user,
but other architecther like X86 check both source and dest address
in copy_from{to}_user, is there some special reason do like this?
in my view , just need check __user* address is enough, and if also
have ex_table for kernel address access maybe hide some BUG in kernel ,
i think kernel don’t need it, or am i miss something ?

if copy_from{to}_user both check source and dest address,
we don’t need this patch, it is safe .
Maybe we need one more API , like:
copy_data_in_user(__user *source, __user *dest, size_t size)  ??
>> --- a/fs/proc/kcore.c
>> +++ b/fs/proc/kcore.c
>> @@ -86,8 +86,8 @@ static size_t get_kcore_size(int *nphdr, size_t 
>> *elf_buflen)
>>  size = try;
>>  *nphdr = *nphdr + 1;
>>  }
>> -*elf_buflen =   sizeof(struct elfhdr) + 
>> -(*nphdr + 2)*sizeof(struct elf_phdr) + 
>> +*elf_buflen =   sizeof(struct elfhdr) +
>> +(*nphdr + 2)*sizeof(struct elf_phdr) +
> 
> Unrelated whitespace fixes really shouldn't be in here.  They don't
> bother me too much, but some people get upset ;)
> 

i will seperate in another patch for format correctness.

>>  3 * ((sizeof(struct elf_note)) +
>>   roundup(sizeof(CORE_STR), 4)) +
>>  roundup(sizeof(struct elf_prstatus), 4) +
>> @@ -435,6 +435,7 @@ read_kcore(struct file *file, char __user *buffer, 
>> size_t buflen, loff_t *fpos)
>>  size_t elf_buflen;
>>  int nphdr;
>>  unsigned long start;
>> +unsigned long page = 0;
> 
> "page" isn't a very good name - when we see that identifier we expect
> it to be a `struct page *'.  Maybe call it copy_buf or something.
> 
> (And incoming argument "buffer" was poorly named.  "buffer" implies some
> temporary intermediate thing, which is inappropriate here!)
> 
will change name.

>>  read_lock(_lock);
>>  size = get_kcore_size(, _buflen);
>> @@ -485,7 +486,7 @@ read_kcore(struct file *file, char __user *buffer, 
>> size_t buflen, loff_t *fpos)
>>  start = kc_offset_to_vaddr(*fpos - elf_buflen);
>>  if ((tsz = (PAGE_SIZE - (start & ~PAGE_MASK))) > buflen)
>>  tsz = buflen;
>> -
>> +
>>  while (buflen) {
>>  struct kcore_list *m;
>> 
>> @@ -515,15 +516,32 @@ read_kcore(struct file *file, char __user *buffer, 
>> size_t buflen, loff_t *fpos)
>>  } else {
>>  if (kern_addr_valid(start)) {
> 
> Do we still need the (racy) kern_addr_valid() test?  The code should
> work OK if this is removed?
> 
Yes, can remove

>>  unsigned long n;
>> +mm_segment_t old_fs = get_fs();
>> +
>> +if (page == 0) {
>> +page = __get_free_page(GFP_KERNEL);
>> +if (page == 0)
>> +return -ENOMEM;
>> 
>> -n = copy_to_user(buffer, (char *)start, tsz);
>> + 

Re: [PATCH -v2 6/8] jump_label: Add a new static_key interface

[yalin wang]

> On Jul 28, 2015, at 21:21, Peter Zijlstra  wrote:
> 
> There are various problems and short-comings with the current
> static_key interface:
> 
> - static_key_{true,false}() read like a branch depending on the key
>   value, instead of the actual likely/unlikely branch depending on
>   init value.
> 
> - static_key_{true,false}() are, as stated above, tied to the
>   static_key init values STATIC_KEY_INIT_{TRUE,FALSE}.
> 
> - we're limited to the 2 (out of 4) possible options that compile to
>   a default NOP because that's what our arch_static_branch() assembly
>   emits.
> 
> So provide a new static_key interface:
> 
>  DEFINE_STATIC_KEY_TRUE(name);
>  DEFINE_STATIC_KEY_FALSE(name);
> 
> Which define a key of different types with an initial true/false
> value.
> 
> Then allow:
> 
>   static_branch_likely()
>   static_branch_unlikely()
> 
> to take a key of either type and emit the right instruction for the
> case.
> 
> This means adding a second arch_static_branch_jump() assembly helper
> which emits a JMP per default.
> 
> In order to determine the right instruction for the right state,
> encode the branch type in the LSB of jump_entry::key.
> 
> Signed-off-by: Peter Zijlstra (Intel) 
> ---
> 
is this means static_key_{true,false}() are deprecated ?
do you need mark static_key_{true,false}() as deprecated?
like this:
static __always_inline  __deprecated bool static_key_false(struct static_key 
*key)  ?
Thanks


--
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 6/8] jump_label: Add a new static_key interface

[yalin wang]

 On Jul 28, 2015, at 21:21, Peter Zijlstra pet...@infradead.org wrote:
 
 There are various problems and short-comings with the current
 static_key interface:
 
 - static_key_{true,false}() read like a branch depending on the key
   value, instead of the actual likely/unlikely branch depending on
   init value.
 
 - static_key_{true,false}() are, as stated above, tied to the
   static_key init values STATIC_KEY_INIT_{TRUE,FALSE}.
 
 - we're limited to the 2 (out of 4) possible options that compile to
   a default NOP because that's what our arch_static_branch() assembly
   emits.
 
 So provide a new static_key interface:
 
  DEFINE_STATIC_KEY_TRUE(name);
  DEFINE_STATIC_KEY_FALSE(name);
 
 Which define a key of different types with an initial true/false
 value.
 
 Then allow:
 
   static_branch_likely()
   static_branch_unlikely()
 
 to take a key of either type and emit the right instruction for the
 case.
 
 This means adding a second arch_static_branch_jump() assembly helper
 which emits a JMP per default.
 
 In order to determine the right instruction for the right state,
 encode the branch type in the LSB of jump_entry::key.
 
 Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org
 ---
 
is this means static_key_{true,false}() are deprecated ?
do you need mark static_key_{true,false}() as deprecated?
like this:
static __always_inline  __deprecated bool static_key_false(struct static_key 
*key)  ?
Thanks


--
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/