Hi
Am 10.05.23 um 20:20 schrieb Sui Jingfeng:
Hi, Thomas
I love your patch, yet something to improve:
On 2023/5/10 19:05, Thomas Zimmermann wrote:
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergmann
Reviewed-by: Sam Ravnborg
Reviewed-by:
Hi
Am 10.05.23 um 17:54 schrieb Arnd Bergmann:
On Wed, May 10, 2023, at 16:27, Thomas Zimmermann wrote:
Am 10.05.23 um 16:15 schrieb Arnd Bergmann:
On Wed, May 10, 2023, at 16:03, kernel test robot wrote:
I think that's a preexisting bug and I have no idea what the
correct solution is. Loo
Functions that work on a pointer to virtual memory such as
virt_to_pfn() and users of that function such as
virt_to_page() are supposed to pass a pointer to virtual
memory, ideally a (void *) or other pointer. However since
many architectures implement virt_to_pfn() as a macro,
this function become
The virt_addr_valid() should be passed a pointer, the current
code passing a long unsigned int is just exploiting the
unintentional polymorphism of these calls being implemented
as preprocessor macros.
Signed-off-by: Linus Walleij
---
fs/proc/kcore.c | 2 +-
1 file changed, 1 insertion(+), 1 del
This is an attempt to harden the typing on virt_to_pfn()
and pfn_to_virt().
Making virt_to_pfn() a static inline taking a strongly typed
(const void *) makes the contract of a passing a pointer of that
type to the function explicit and exposes any misuse of the
macro virt_to_pfn() acting polymorph
Making virt_to_pfn() a static inline taking a strongly typed
(const void *) makes the contract of a passing a pointer of that
type to the function explicit and exposes any misuse of the
macro virt_to_pfn() acting polymorphic and accepting many types
such as (void *), (unitptr_t) or (unsigned long)
Like the other calls in this function virt_to_page() expects
a pointer, not an integer.
However since many architectures implement virt_to_pfn() as
a macro, this function becomes polymorphic and accepts both a
(unsigned long) and a (void *).
Fix this up with an explicit cast.
Signed-off-by: Linu
Hi Arnd,
CC Artur, who's working on HP Jornada 680.
On Wed, May 10, 2023 at 5:55 PM Arnd Bergmann wrote:
> On Wed, May 10, 2023, at 16:27, Thomas Zimmermann wrote:
> > Am 10.05.23 um 16:15 schrieb Arnd Bergmann:
> >> On Wed, May 10, 2023, at 16:03, kernel test robot wrote:
>
> >> I think that's
Making virt_to_pfn() a static inline taking a strongly typed
(const void *) makes the contract of a passing a pointer of that
type to the function explicit and exposes any misuse of the
macro virt_to_pfn() acting polymorphic and accepting many types
such as (void *), (unitptr_t) or (unsigned long)
On Thu, May 11, 2023, at 14:35, Geert Uytterhoeven wrote:
> CC Artur, who's working on HP Jornada 680.
>
> On Wed, May 10, 2023 at 5:55 PM Arnd Bergmann wrote:
>> On Wed, May 10, 2023, at 16:27, Thomas Zimmermann wrote:
>> > Am 10.05.23 um 16:15 schrieb Arnd Bergmann:
>> >> On Wed, May 10, 2023, a
Like the other calls in this function virt_to_page() expects
a pointer, not an integer.
However since many architectures implement virt_to_pfn() as
a macro, this function becomes polymorphic and accepts both a
(unsigned long) and a (void *).
Fix this up with an explicit cast.
Signed-off-by: Linu
Functions that work on a pointer to virtual memory such as
virt_to_pfn() and users of that function such as
virt_to_page() are supposed to pass a pointer to virtual
memory, ideally a (void *) or other pointer. However since
many architectures implement virt_to_pfn() as a macro,
this function become
Like the other calls in this function virt_to_page() expects
a pointer, not an integer.
However since many architectures implement virt_to_pfn() as
a macro, this function becomes polymorphic and accepts both a
(unsigned long) and a (void *).
Fix this up with an explicit cast.
Signed-off-by: Linu
Functions that work on a pointer to virtual memory such as
virt_to_pfn() and users of that function such as
virt_to_page() are supposed to pass a pointer to virtual
memory, ideally a (void *) or other pointer. However since
many architectures implement virt_to_pfn() as a macro,
this function become
Making virt_to_pfn() a static inline taking a strongly typed
(const void *) makes the contract of a passing a pointer of that
type to the function explicit and exposes any misuse of the
macro virt_to_pfn() acting polymorphic and accepting many types
such as (void *), (unitptr_t) or (unsigned long)
Making virt_to_pfn() a static inline taking a strongly typed
(const void *) makes the contract of a passing a pointer of that
type to the function explicit and exposes any misuse of the
macro virt_to_pfn() acting polymorphic and accepting many types
such as (void *), (unitptr_t) or (unsigned long)
Like the other calls in this function virt_to_page() expects
a pointer, not an integer.
However since many architectures implement virt_to_pfn() as
a macro, this function becomes polymorphic and accepts both a
(unsigned long) and a (void *).
Fix this up with an explicit cast.
Signed-off-by: Linu
On 5/11/23 09:55, Thomas Zimmermann wrote:
Hi
Am 10.05.23 um 20:20 schrieb Sui Jingfeng:
Hi, Thomas
I love your patch, yet something to improve:
On 2023/5/10 19:05, Thomas Zimmermann wrote:
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergma
Hi Helge,
On Thu, May 11, 2023 at 3:05 PM Helge Deller wrote:
> On 5/11/23 09:55, Thomas Zimmermann wrote:
> > But the work I do within fbdev is mostly for improving DRM.
>
> Sure.
>
> > For the
> > other issues in this file, I don't think that matroxfb should even be
> > around any longer. Fbdev
Hi
Am 10.05.23 um 17:54 schrieb Arnd Bergmann:
On Wed, May 10, 2023, at 16:27, Thomas Zimmermann wrote:
Am 10.05.23 um 16:15 schrieb Arnd Bergmann:
On Wed, May 10, 2023, at 16:03, kernel test robot wrote:
I think that's a preexisting bug and I have no idea what the
correct solution is. Loo
On 2023-05-11 14:35, Geert Uytterhoeven wrote:
Hi Arnd,
CC Artur, who's working on HP Jornada 680.
Thanks for CC'ing me - I faced this exact issue while working on my
(still not upstreamed) hd6446x PCMCIA controller driver. The PCMCIA
subsystem uses `inb/outb`, which expect the `sh_io_port_base
Hi
Am 11.05.23 um 15:05 schrieb Helge Deller:
On 5/11/23 09:55, Thomas Zimmermann wrote:
Hi
Am 10.05.23 um 20:20 schrieb Sui Jingfeng:
Hi, Thomas
I love your patch, yet something to improve:
On 2023/5/10 19:05, Thomas Zimmermann wrote:
Fix coding style. No functional changes.
Signed-off
On Thu, May 11, 2023, at 15:22, Artur Rojek wrote:
> On 2023-05-11 14:35, Geert Uytterhoeven wrote:
>>
>> CC Artur, who's working on HP Jornada 680.
> Thanks for CC'ing me - I faced this exact issue while working on my
> (still not upstreamed) hd6446x PCMCIA controller driver. The PCMCIA
> subsyst
On 5/11/23 15:10, Geert Uytterhoeven wrote:
Hi Helge,
On Thu, May 11, 2023 at 3:05 PM Helge Deller wrote:
On 5/11/23 09:55, Thomas Zimmermann wrote:
But the work I do within fbdev is mostly for improving DRM.
Sure.
For the
other issues in this file, I don't think that matroxfb should even
Current definition of THREAD_SHIFT is (PAGE_SHIFT << THREAD_SIZE_ORDER)
look incorrect. It should be (PAGE_SHIFT + THREAD_SIZE_ORDER) because
the following equation should hold:
Say PAGE_SHIFT == 13 (as the default value in ARC)
THREAD_SIZE_ORDER == 1 (as CONFIG_16KSTACKS=y)
THREAD_SIZE == (1 <<
Rename 16KSTACKS to DEBUG_STACKS.
arch/arc/Kconfig.debug says that the default stack size is 8KB
and it will become 16KB stack if 16KSTACKS is set.
However, the stack size is based on PAGE_SIZE, and it is
configurable by CONFIG_ARC_PAGE_SIZE_16K or CONFIG_ARC_PAGE_SIZE_4K.
See arch/arc/include/u
Hi,
When I read the arch/arc code, I first found that the
definition of THREAD_SHIFT looks incorrect and the
description of 16KSTACKS looks confusing. I submit
these 2 small patches to address the issue I found.
Min-Hua Chen (2):
ARC: fix incorrect THREAD_SHIFT definition
ARC: rename 16KSTACK
On 5/11/23 16:27, Thomas Zimmermann wrote:
But the work I do within fbdev is mostly for improving DRM.
Sure.
For the
other issues in this file, I don't think that matroxfb should even be
around any longer. Fbdev has been deprecated for a long time. But a
small number of drivers are still in u
28 matches
Mail list logo
