search for: oetj

...a macro, the result is build failure as the macro tries to dereference > > void*. > > > > Fix by reordering code slightly, so we always pass > > struct page * to page_address. > > Thanks for the clue! I was just investigating a similar failure in -next. > > Gr{oetje,eeting}s, > > Geert You don't mean linux-next? And not in virtio-net? I don't see page_address being used on void * anywhere there. > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org > > In personal co...

...a macro, the result is build failure as the macro tries to dereference > > void*. > > > > Fix by reordering code slightly, so we always pass > > struct page * to page_address. > > Thanks for the clue! I was just investigating a similar failure in -next. > > Gr{oetje,eeting}s, > > Geert You don't mean linux-next? And not in virtio-net? I don't see page_address being used on void * anywhere there. > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org > > In personal co...

...ether via "next". */ > > struct vring_desc { > > /* Address (guest-physical). */ > > - __u64 addr; > > + __virtio64 addr; > > ... and __le64? > > There's already lots of precedence or this, even in include/uapi/. > > Gr{oetje,eeting}s, > > Geert __le would make people think they can use le16-to_cpu() which is wrong. -- MST

...ether via "next". */ > > struct vring_desc { > > /* Address (guest-physical). */ > > - __u64 addr; > > + __virtio64 addr; > > ... and __le64? > > There's already lots of precedence or this, even in include/uapi/. > > Gr{oetje,eeting}s, > > Geert __le would make people think they can use le16-to_cpu() which is wrong. -- MST

...failure as the macro tries to dereference >> > void*. >> > >> > Fix by reordering code slightly, so we always pass >> > struct page * to page_address. >> >> Thanks for the clue! I was just investigating a similar failure in -next. >> >> Gr{oetje,eeting}s, >> >> Geert > > You don't mean linux-next? And not in virtio-net? I don't see page_address > being used on void * anywhere there. http://kisskb.ellerman.id.au/kisskb/buildresult/10469287/ I'm making {,set}page_address() static in...

As a result of backporting a bugfix, virtio_net started passing void * to page_address, assuming that it will get silently converted to struct page *. But this does not happen on architectures where page_address is a macro, the result is build failure as the macro tries to dereference void*. Fix by reordering code slightly, so we always pass struct page * to page_address. Reported-by: Guenter

As a result of backporting a bugfix, virtio_net started passing void * to page_address, assuming that it will get silently converted to struct page *. But this does not happen on architectures where page_address is a macro, the result is build failure as the macro tries to dereference void*. Fix by reordering code slightly, so we always pass struct page * to page_address. Reported-by: Guenter

...lp text, so users know if they want to enable this option or not. Thanks! > +if VHOST_MENU > + > config VHOST_NET > tristate "Host kernel accelerator for virtio net" > depends on NET && EVENTFD && (TUN || !TUN) && (TAP || !TAP) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like...

...lp text, so users know if they want to enable this option or not. Thanks! > +if VHOST_MENU > + > config VHOST_NET > tristate "Host kernel accelerator for virtio net" > depends on NET && EVENTFD && (TUN || !TUN) && (TAP || !TAP) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like...

...elect VDPA > + select VHOST_RING > + default n > + help > + vDPA networking device simulator which loop TX traffic back > + to RX. This device is used for testing, prototyping and > + development of vDPA. > + > +endif # VDPA_MENU Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like...

...; make[1]: *** [Makefile:1693: drivers] Error 2 > make: *** [Makefile:179: sub-make] Error 2 Looks like you forgot to update the forward declaration in drivers/net/ethernet/8390/8390.h There may be others... http://kisskb.ellerman.id.au/kisskb/head/6cf8298daad041cd15dc514d8a4f93ca3636c84e/ Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like...

...atic __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u) > > which truncates the result to 32 bit. Woops. See also my unanswered question in "atomic64 on 32-bit vs 64-bit (was: Re: Add virtio gpu driver.)", which is still valid: https://lkml.org/lkml/2015/6/28/18 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like...

...atic __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u) > > which truncates the result to 32 bit. Woops. See also my unanswered question in "atomic64 on 32-bit vs 64-bit (was: Re: Add virtio gpu driver.)", which is still valid: https://lkml.org/lkml/2015/6/28/18 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like...

On Fri, 30 Nov 2018 14:12:19 -0800 Jarkko Sakkinen <jarkko.sakkinen at linux.intel.com> wrote: > As a maintainer myself (and based on somewhat disturbed feedback from > other maintainers) I can only make the conclusion that nobody knows what > the responsibility part here means. > > I would interpret, if I read it like at lawyer at least, that even for > existing code you

...rovide sane defaults. > > > So it looks like VHOST_MENU is actually matching rule b). > So what's the problem we are trying to solve with this patch, exactly? > > Geert could you clarify pls? I can confirm VHOST_MENU is matching rule b), so it is safe to always enable it. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like...

..._NON_CONSISTENT (1UL << 4) > +#define DMA_ATTR_NO_KERNEL_MAPPING (1UL << 5) > +#define DMA_ATTR_SKIP_CPU_SYNC (1UL << 6) > +#define DMA_ATTR_FORCE_CONTIGUOUS (1UL << 7) > +#define DMA_ATTR_ALLOC_SINGLE_PAGES (1UL << 8) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like...

...d use appropriate language. | Content that already exists predating the Code of Conduct will not be | addressed now as a violation. However: | Inappropriate language can be seen as a | bug, though; such bugs will be fixed more quickly if any interested | parties submit patches to that effect. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like...

...work. Essentially, > each accessor call becomes a little critical section on its own and > ensures that the access happens as expected by the programmer." That is exactly the use case here: all above are accessor functions. Why would ioreadX() not need volatile, while readY() does? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like...

...==== > The first 5 patches - iomap, alpha, sh, parisc and powerpc - should probably go > via one tree, or even squashed into one. Yes, they should be squashed, cfr. Arnd's comment. I also wouldn't bother doing the updates in patches 6-10. The rest looks good to me. Thanks a lot! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like...

...th/ath5k/ahb.c:141:18: warning: passing argument 1 of ?ioread32? makes pointer from integer without a cast [-Wint-conversion] > reg = ioread32(AR5K_AR2315_AHB_ARB_CTL); That's an argument for keeping the cast to "void __iomem *", not for adding the "const", right? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like...