similar to: [PATCH stable-only] virtio-net: fix build on m68k and sparc64

Displaying 20 results from an estimated 4000 matches similar to: "[PATCH stable-only] virtio-net: fix build on m68k and sparc64"

2014 Jan 15
2
[PATCH stable-only] virtio-net: fix build on m68k and sparc64
On Wed, Jan 15, 2014 at 09:36:13AM +0100, Geert Uytterhoeven wrote: > On Wed, Jan 15, 2014 at 9:26 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > 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
2014 Jan 15
2
[PATCH stable-only] virtio-net: fix build on m68k and sparc64
On Wed, Jan 15, 2014 at 09:36:13AM +0100, Geert Uytterhoeven wrote: > On Wed, Jan 15, 2014 at 9:26 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > 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
2014 Jan 15
0
[PATCH stable-only] virtio-net: fix build on m68k and sparc64
On Wed, Jan 15, 2014 at 9:46 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Wed, Jan 15, 2014 at 09:36:13AM +0100, Geert Uytterhoeven wrote: >> On Wed, Jan 15, 2014 at 9:26 AM, Michael S. Tsirkin <mst at redhat.com> wrote: >> > As a result of backporting a bugfix, virtio_net started passing void * >> > to page_address, assuming that it will get
2014 Jan 15
0
[PATCH stable-only] virtio-net: fix build on m68k and sparc64
On Wed, Jan 15, 2014 at 9:26 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > 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 >
2014 Nov 24
2
[PATCH v3 04/41] virtio: memory access APIs
On Mon, Nov 24, 2014 at 01:03:24PM +0100, Geert Uytterhoeven wrote: > On Mon, Nov 24, 2014 at 12:52 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > > virtio 1.0 makes all memory structures LE, so > > we need APIs to conditionally do a byteswap on BE > > architectures. > > > > To make it easier to check code statically, > > add virtio specific types
2014 Nov 24
2
[PATCH v3 04/41] virtio: memory access APIs
On Mon, Nov 24, 2014 at 01:03:24PM +0100, Geert Uytterhoeven wrote: > On Mon, Nov 24, 2014 at 12:52 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > > virtio 1.0 makes all memory structures LE, so > > we need APIs to conditionally do a byteswap on BE > > architectures. > > > > To make it easier to check code statically, > > add virtio specific types
2020 Apr 10
2
vhost: refine vhost and vringh kconfig
Hi Jason, On Thu, Apr 9, 2020 at 6:04 AM Linux Kernel Mailing List <linux-kernel at vger.kernel.org> wrote: > Commit: 20c384f1ea1a0bc7320bc445c72dd02d2970d594 > Parent: 5a6b4cc5b7a1892a8d7f63d6cbac6e0ae2a9d031 > Refname: refs/heads/master > Web: https://git.kernel.org/torvalds/c/20c384f1ea1a0bc7320bc445c72dd02d2970d594 > Author: Jason Wang <jasowang
2020 Apr 10
2
vhost: refine vhost and vringh kconfig
Hi Jason, On Thu, Apr 9, 2020 at 6:04 AM Linux Kernel Mailing List <linux-kernel at vger.kernel.org> wrote: > Commit: 20c384f1ea1a0bc7320bc445c72dd02d2970d594 > Parent: 5a6b4cc5b7a1892a8d7f63d6cbac6e0ae2a9d031 > Refname: refs/heads/master > Web: https://git.kernel.org/torvalds/c/20c384f1ea1a0bc7320bc445c72dd02d2970d594 > Author: Jason Wang <jasowang
2019 Dec 09
1
[PATCH RFC net-next v8 1/3] netdev: pass the stuck queue to the timeout handler
Hi Michael, On Tue, Dec 3, 2019 at 9:21 PM Michael S. Tsirkin <mst at redhat.com> wrote: > This allows incrementing the correct timeout statistic without any mess. > Down the road, devices can learn to reset just the specific queue. > > The patch was generated with the following script: [...] > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > ---
2018 Nov 30
5
[PATCH RFC 00/15] Zero ****s, hugload of hugs <3
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
2015 Oct 19
2
[PATCH] drm/virtio: use %llu format string form atomic64_t
On Wed, Oct 7, 2015 at 1:23 PM, Arnd Bergmann <arnd at arndb.de> wrote: > On Wednesday 07 October 2015 13:04:06 Arnd Bergmann wrote: >> On Wednesday 07 October 2015 11:45:02 Russell King - ARM Linux wrote: >> > On Wed, Oct 07, 2015 at 12:41:21PM +0200, Arnd Bergmann wrote: >> > > The virtgpu driver prints the last_seq variable using the %ld or >> > >
2015 Oct 19
2
[PATCH] drm/virtio: use %llu format string form atomic64_t
On Wed, Oct 7, 2015 at 1:23 PM, Arnd Bergmann <arnd at arndb.de> wrote: > On Wednesday 07 October 2015 13:04:06 Arnd Bergmann wrote: >> On Wednesday 07 October 2015 11:45:02 Russell King - ARM Linux wrote: >> > On Wed, Oct 07, 2015 at 12:41:21PM +0200, Arnd Bergmann wrote: >> > > The virtgpu driver prints the last_seq variable using the %ld or >> > >
2020 Apr 05
4
[PATCH] vdpa-sim: depend on HAS_DMA
set_dma_ops isn't available on all architectures: make ARCH=um ... drivers/vdpa/vdpa_sim/vdpa_sim.c: In function 'vdpasim_create': >> drivers/vdpa/vdpa_sim/vdpa_sim.c:324:2: error: implicit declaration of function 'set_dma_ops'; did you mean 'set_groups'? +[-Werror=implicit-function-declaration] set_dma_ops(dev, &vdpasim_dma_ops);
2020 Apr 05
4
[PATCH] vdpa-sim: depend on HAS_DMA
set_dma_ops isn't available on all architectures: make ARCH=um ... drivers/vdpa/vdpa_sim/vdpa_sim.c: In function 'vdpasim_create': >> drivers/vdpa/vdpa_sim/vdpa_sim.c:324:2: error: implicit declaration of function 'set_dma_ops'; did you mean 'set_groups'? +[-Werror=implicit-function-declaration] set_dma_ops(dev, &vdpasim_dma_ops);
2025 Jan 21
1
[PATCH v2 0/5] drm/connector: make mode_valid() callback accept const mode pointer
On Tue, 21 Jan 2025 at 11:13, Geert Uytterhoeven <geert at linux-m68k.org> wrote: > > Hi Dmitry, > > On Tue, Jan 7, 2025 at 12:31?PM Dmitry Baryshkov > <dmitry.baryshkov at linaro.org> wrote: > > On Sat, 14 Dec 2024 15:37:04 +0200, Dmitry Baryshkov wrote: > > > While working on the generic mode_valid() implementation for the HDMI > > > Connector
2025 Jan 16
3
[PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
On Thu, Jan 16, 2025 at 11:03?AM Tomi Valkeinen <tomi.valkeinen at ideasonboard.com> wrote: > On 16/01/2025 10:09, Thomas Zimmermann wrote: > > Am 15.01.25 um 15:20 schrieb Tomi Valkeinen: > > [...] > >> > >> My point is that we have the current UAPI, and we have userspace using > >> it, but we don't have clear rules what the ioctl does with
2013 Nov 15
2
[PATCH -tip RFC v2 01/22] kprobes: Prohibit probing on .entry.text code
On Fri, 15 Nov 2013 04:53:18 +0000 Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > .entry.text is a code area which is used for interrupt/syscall > entries, and there are many sensitive codes. > Thus, it is better to prohibit probing on all of such codes > instead of a part of that. > Since some symbols are already registered on kprobe blacklist, > this also
2013 Nov 15
2
[PATCH -tip RFC v2 01/22] kprobes: Prohibit probing on .entry.text code
On Fri, 15 Nov 2013 04:53:18 +0000 Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > .entry.text is a code area which is used for interrupt/syscall > entries, and there are many sensitive codes. > Thus, it is better to prohibit probing on all of such codes > instead of a part of that. > Since some symbols are already registered on kprobe blacklist, > this also
2020 Jan 08
4
[RFT 00/13] iomap: Constify ioreadX() iomem argument
Le 08/01/2020 ? 09:18, Krzysztof Kozlowski a ?crit?: > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven <geert at linux-m68k.org> wrote: >> >> Hi Krzysztof, >> >> On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote: >>> On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski <krzk at kernel.org> wrote: >>>>
2025 Jan 07
1
[PATCH v2 0/5] drm/connector: make mode_valid() callback accept const mode pointer
On Sat, 14 Dec 2024 15:37:04 +0200, Dmitry Baryshkov wrote: > While working on the generic mode_valid() implementation for the HDMI > Connector framework I noticed that unlike other DRM objects > drm_connector accepts non-const pointer to struct drm_display_mode, > while obviously mode_valid() isn't expected to modify the argument. > > Mass-change the DRM framework code to