* [PATCH v3 18/28] drm/qxl: switch to drm_*_get(), drm_*_put() helpers
From: Cihangir Akturk @ 2017-08-11 12:33 UTC (permalink / raw)
Cc: David Airlie, linux-kernel, dri-devel, virtualization,
Cihangir Akturk, daniel, Dave Airlie
In-Reply-To: <1502454794-28558-1-git-send-email-cakturk@gmail.com>
Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference()
and drm_*_unreference() helpers.
drm_*_reference() and drm_*_unreference() functions are just
compatibility alias for drm_*_get() and drm_*_put() and should not be
used by new code. So convert all users of compatibility functions to
use the new APIs.
Generated by: scripts/coccinelle/api/drm-get-put.cocci
Signed-off-by: Cihangir Akturk <cakturk@gmail.com>
---
drivers/gpu/drm/qxl/qxl_display.c | 4 ++--
drivers/gpu/drm/qxl/qxl_dumb.c | 2 +-
drivers/gpu/drm/qxl/qxl_fb.c | 6 +++---
drivers/gpu/drm/qxl/qxl_gem.c | 2 +-
drivers/gpu/drm/qxl/qxl_ioctl.c | 4 ++--
drivers/gpu/drm/qxl/qxl_object.c | 6 +++---
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c
index 14c5613..a54a766 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -306,7 +306,7 @@ void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct qxl_framebuffer *qxl_fb = to_qxl_framebuffer(fb);
- drm_gem_object_unreference_unlocked(qxl_fb->obj);
+ drm_gem_object_put_unlocked(qxl_fb->obj);
drm_framebuffer_cleanup(fb);
kfree(qxl_fb);
}
@@ -1106,7 +1106,7 @@ qxl_user_framebuffer_create(struct drm_device *dev,
ret = qxl_framebuffer_init(dev, qxl_fb, mode_cmd, obj, &qxl_fb_funcs);
if (ret) {
kfree(qxl_fb);
- drm_gem_object_unreference_unlocked(obj);
+ drm_gem_object_put_unlocked(obj);
return NULL;
}
diff --git a/drivers/gpu/drm/qxl/qxl_dumb.c b/drivers/gpu/drm/qxl/qxl_dumb.c
index 5e65d5d..a0c9e73 100644
--- a/drivers/gpu/drm/qxl/qxl_dumb.c
+++ b/drivers/gpu/drm/qxl/qxl_dumb.c
@@ -81,6 +81,6 @@ int qxl_mode_dumb_mmap(struct drm_file *file_priv,
return -ENOENT;
qobj = gem_to_qxl_bo(gobj);
*offset_p = qxl_bo_mmap_offset(qobj);
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
return 0;
}
diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 844c4a3..52903ef 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -95,7 +95,7 @@ static void qxlfb_destroy_pinned_object(struct drm_gem_object *gobj)
qxl_bo_kunmap(qbo);
qxl_bo_unpin(qbo);
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
}
int qxl_get_handle_for_primary_fb(struct qxl_device *qdev,
@@ -319,11 +319,11 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev,
qxl_bo_unpin(qbo);
}
if (fb && ret) {
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
drm_framebuffer_cleanup(fb);
kfree(fb);
}
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
return ret;
}
diff --git a/drivers/gpu/drm/qxl/qxl_gem.c b/drivers/gpu/drm/qxl/qxl_gem.c
index 85f5467..f5c1e78 100644
--- a/drivers/gpu/drm/qxl/qxl_gem.c
+++ b/drivers/gpu/drm/qxl/qxl_gem.c
@@ -98,7 +98,7 @@ int qxl_gem_object_create_with_handle(struct qxl_device *qdev,
return r;
/* drop reference from allocate - handle holds it now */
*qobj = gem_to_qxl_bo(gobj);
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
return 0;
}
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index 31effed..7b141db 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -121,7 +121,7 @@ static int qxlhw_handle_to_bo(struct drm_file *file_priv, uint64_t handle,
qobj = gem_to_qxl_bo(gobj);
ret = qxl_release_list_add(release, qobj);
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
if (ret)
return ret;
@@ -343,7 +343,7 @@ static int qxl_update_area_ioctl(struct drm_device *dev, void *data,
qxl_bo_unreserve(qobj);
out:
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
return ret;
}
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index 0a67ddf..c4aebcf 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -211,13 +211,13 @@ void qxl_bo_unref(struct qxl_bo **bo)
if ((*bo) == NULL)
return;
- drm_gem_object_unreference_unlocked(&(*bo)->gem_base);
+ drm_gem_object_put_unlocked(&(*bo)->gem_base);
*bo = NULL;
}
struct qxl_bo *qxl_bo_ref(struct qxl_bo *bo)
{
- drm_gem_object_reference(&bo->gem_base);
+ drm_gem_object_get(&bo->gem_base);
return bo;
}
@@ -316,7 +316,7 @@ void qxl_bo_force_delete(struct qxl_device *qdev)
list_del_init(&bo->list);
mutex_unlock(&qdev->gem.mutex);
/* this should unref the ttm bo */
- drm_gem_object_unreference_unlocked(&bo->gem_base);
+ drm_gem_object_put_unlocked(&bo->gem_base);
}
}
--
2.7.4
^ permalink raw reply related
* [PATCH v3 26/28] drm/virtio: switch to drm_*_get(), drm_*_put() helpers
From: Cihangir Akturk @ 2017-08-11 12:33 UTC (permalink / raw)
Cc: David Airlie, linux-kernel, dri-devel, virtualization,
Cihangir Akturk, daniel
In-Reply-To: <1502454794-28558-1-git-send-email-cakturk@gmail.com>
Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference()
and drm_*_unreference() helpers.
drm_*_reference() and drm_*_unreference() functions are just
compatibility alias for drm_*_get() and drm_*_put() and should not be
used by new code. So convert all users of compatibility functions to
use the new APIs.
Generated by: scripts/coccinelle/api/drm-get-put.cocci
Signed-off-by: Cihangir Akturk <cakturk@gmail.com>
---
drivers/gpu/drm/virtio/virtgpu_display.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_gem.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 14 +++++++-------
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
index b6d5205..41b0930 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -53,7 +53,7 @@ static void virtio_gpu_user_framebuffer_destroy(struct drm_framebuffer *fb)
struct virtio_gpu_framebuffer *virtio_gpu_fb
= to_virtio_gpu_framebuffer(fb);
- drm_gem_object_unreference_unlocked(virtio_gpu_fb->obj);
+ drm_gem_object_put_unlocked(virtio_gpu_fb->obj);
drm_framebuffer_cleanup(fb);
kfree(virtio_gpu_fb);
}
@@ -327,7 +327,7 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
ret = virtio_gpu_framebuffer_init(dev, virtio_gpu_fb, mode_cmd, obj);
if (ret) {
kfree(virtio_gpu_fb);
- drm_gem_object_unreference_unlocked(obj);
+ drm_gem_object_put_unlocked(obj);
return NULL;
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c
index cc025d8..78da210 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -72,7 +72,7 @@ int virtio_gpu_gem_create(struct drm_file *file,
*obj_p = &obj->gem_base;
/* drop reference from allocate - handle holds it now */
- drm_gem_object_unreference_unlocked(&obj->gem_base);
+ drm_gem_object_put_unlocked(&obj->gem_base);
*handle_p = handle;
return 0;
@@ -137,7 +137,7 @@ int virtio_gpu_mode_dumb_mmap(struct drm_file *file_priv,
return -ENOENT;
obj = gem_to_virtio_gpu_obj(gobj);
*offset_p = virtio_gpu_object_mmap_offset(obj);
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
return 0;
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index b94bd54..461f81a 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -86,7 +86,7 @@ static void virtio_gpu_unref_list(struct list_head *head)
bo = buf->bo;
qobj = container_of(bo, struct virtio_gpu_object, tbo);
- drm_gem_object_unreference_unlocked(&qobj->gem_base);
+ drm_gem_object_put_unlocked(&qobj->gem_base);
}
}
@@ -261,7 +261,7 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
ret = virtio_gpu_object_attach(vgdev, qobj, res_id, NULL);
} else {
/* use a gem reference since unref list undoes them */
- drm_gem_object_reference(&qobj->gem_base);
+ drm_gem_object_get(&qobj->gem_base);
mainbuf.bo = &qobj->tbo;
list_add(&mainbuf.head, &validate_list);
@@ -304,7 +304,7 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
}
return ret;
}
- drm_gem_object_unreference_unlocked(obj);
+ drm_gem_object_put_unlocked(obj);
rc->res_handle = res_id; /* similiar to a VM address */
rc->bo_handle = handle;
@@ -341,7 +341,7 @@ static int virtio_gpu_resource_info_ioctl(struct drm_device *dev, void *data,
ri->size = qobj->gem_base.size;
ri->res_handle = qobj->hw_res_handle;
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
return 0;
}
@@ -389,7 +389,7 @@ static int virtio_gpu_transfer_from_host_ioctl(struct drm_device *dev,
out_unres:
virtio_gpu_object_unreserve(qobj);
out:
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
return ret;
}
@@ -439,7 +439,7 @@ static int virtio_gpu_transfer_to_host_ioctl(struct drm_device *dev, void *data,
out_unres:
virtio_gpu_object_unreserve(qobj);
out:
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
return ret;
}
@@ -462,7 +462,7 @@ static int virtio_gpu_wait_ioctl(struct drm_device *dev, void *data,
nowait = true;
ret = virtio_gpu_object_wait(qobj, nowait);
- drm_gem_object_unreference_unlocked(gobj);
+ drm_gem_object_put_unlocked(gobj);
return ret;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.
From: Paolo Bonzini @ 2017-08-11 14:09 UTC (permalink / raw)
To: Michael S. Tsirkin, Richard W.M. Jones
Cc: jejb, martin.petersen, linux-scsi, linux-kernel, virtualization,
hch
In-Reply-To: <20170811003621-mutt-send-email-mst@kernel.org>
On 10/08/2017 23:41, Michael S. Tsirkin wrote:
>>> Then we probably should fail probe if vq size is too small.
>> What does this mean?
>
> We must prevent driver from submitting s/g lists > vq size to device.
What is the rationale for the limit? It makes no sense if indirect
descriptors are available, especially because...
> Either tell linux to avoid s/g lists that are too long, or
> simply fail request if this happens, or refuse to attach driver to device.
>
> Later option would look something like this within probe:
>
> for (i = VIRTIO_SCSI_VQ_BASE; i < num_vqs; i++)
> if (vqs[i]->num < MAX_SG_USED_BY_LINUX)
> goto err;
>
>
> I don't know what's MAX_SG_USED_BY_LINUX though.
>
... both virtio-blk and virtio-scsi transmit their own value for the
maximum sg list size (max_seg in virtio-scsi, seg_max in virtio-blk).
Paolo
^ permalink raw reply
* RE: [PATCH v3 00/28] DRM API Conversions
From: Deucher, Alexander @ 2017-08-11 14:24 UTC (permalink / raw)
To: 'Cihangir Akturk'
Cc: devel@driverdev.osuosl.org, linux-arm-msm@vger.kernel.org,
intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, etnaviv@lists.freedesktop.org,
amd-gfx@lists.freedesktop.org, daniel@ffwll.ch,
nouveau@lists.freedesktop.org, linux-tegra@vger.kernel.org,
virtualization@lists.linux-foundation.org,
freedreno@lists.freedesktop.org
In-Reply-To: <1502454794-28558-1-git-send-email-cakturk@gmail.com>
> -----Original Message-----
> From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf
> Of Cihangir Akturk
> Sent: Friday, August 11, 2017 8:33 AM
> Cc: devel@driverdev.osuosl.org; linux-arm-msm@vger.kernel.org; intel-
> gfx@lists.freedesktop.org; linux-kernel@vger.kernel.org; dri-
> devel@lists.freedesktop.org; etnaviv@lists.freedesktop.org; Cihangir Akturk;
> amd-gfx@lists.freedesktop.org; daniel@ffwll.ch;
> nouveau@lists.freedesktop.org; linux-tegra@vger.kernel.org;
> virtualization@lists.linux-foundation.org; freedreno@lists.freedesktop.org
> Subject: [PATCH v3 00/28] DRM API Conversions
>
> Changes since v2:
>
> - Patch series is based on *drm-misc-next* as suggested by Sean Paul.
>
> - Dropped patch 05 (drm/atmel-hlcdc) and patch 25 (drm/vc4) from v2,
> since they were already pulled in the drm-misc-next
>
> Changes since v1:
>
> - This time patches were generated with coccinelle instead of my own
> script, as suggested by Daniel Vetter.
>
> - Fixed the typo in commit messages. s/adn/and
>
FWIW, I already picked up v1 of these patches for radeon and amdgpu.
Alex
> Note: I've included r-b, a-b tags, as these patches are identical to v1
> except for the file: drivers/gpu/drm/i915/i915_gem_object.h
>
> This patch set replaces the occurrences of drm_*_reference() and
> drm_*_unreference() with the new drm_*_get() and drm_*_put()
> functions.
> All patches in the series do the same thing, converting to the new APIs.
> I created patches per DRM driver as suggested by Daniel Vetter.
>
> This patch set was generated by scripts/coccinelle/api/drm-get-put.cocci
>
> Previous thread can be reached at:
> https://marc.info/?l=dri-devel&m=150178288816047
>
> Background:
>
> In the kernel, reference counting APIs use *_get(), *_put() style naming
> to reference-count the objects. But DRM subsystem uses a different
> naming for them such as *_reference(), *_unreference() which is
> inconsistent with the other reference counting APIs in the kernel. To
> solve this consistency issue, Thierry Reding introduced a couple of
> functions and compatibility aliases in the following commits for them.
>
> commit 020a218f95bd3ceff7dd1022ff7ebc0497bc7bf9
> Author: Thierry Reding <treding@nvidia.com>
> Date: Tue Feb 28 15:46:38 2017 +0100
>
> drm: Introduce drm_mode_object_{get,put}()
>
> commit ad09360750afa18a0a0ce0253d6ea6033abc22e7
> Author: Thierry Reding <treding@nvidia.com>
> Date: Tue Feb 28 15:46:39 2017 +0100
>
> drm: Introduce drm_connector_{get,put}()
>
> commit a4a69da06bc11a937a6e417938b1bb698ee1fa46
> Author: Thierry Reding <treding@nvidia.com>
> Date: Tue Feb 28 15:46:40 2017 +0100
>
> drm: Introduce drm_framebuffer_{get,put}()
>
> commit e6b62714e87c8811d5564b6a0738dcde63a51774
> Author: Thierry Reding <treding@nvidia.com>
> Date: Tue Feb 28 15:46:41 2017 +0100
>
> drm: Introduce drm_gem_object_{get,put}()
>
> commit 6472e5090be7c78749a3c279b4faae87ab835c40
> Author: Thierry Reding <treding@nvidia.com>
> Date: Tue Feb 28 15:46:42 2017 +0100
>
> drm: Introduce drm_property_blob_{get,put}()
>
> Cihangir Akturk (28):
> drm/amdgpu: switch to drm_*_get(), drm_*_put() helpers
> drm: mali-dp: switch to drm_*_get(), drm_*_put() helpers
> drm/armada: switch to drm_*_get(), drm_*_put() helpers
> drm/ast: switch to drm_*_get(), drm_*_put() helpers
> drm/bochs: switch to drm_*_get(), drm_*_put() helpers
> drm/cirrus: switch to drm_*_get(), drm_*_put() helpers
> drm/etnaviv: switch to drm_*_get(), drm_*_put() helpers
> drm/exynos: switch to drm_*_get(), drm_*_put() helpers
> drm/gma500: switch to drm_*_get(), drm_*_put() helpers
> drm/hisilicon: switch to drm_*_get(), drm_*_put() helpers
> drm/i915: switch to drm_*_get(), drm_*_put() helpers
> drm/imx: switch to drm_*_get(), drm_*_put() helpers
> drm/mediatek: switch to drm_*_get(), drm_*_put() helpers
> drm/mgag200: switch to drm_*_get(), drm_*_put() helpers
> drm/msm: switch to drm_*_get(), drm_*_put() helpers
> drm/nouveau: switch to drm_*_get(), drm_*_put() helpers
> drm/omapdrm: switch to drm_*_get(), drm_*_put() helpers
> drm/qxl: switch to drm_*_get(), drm_*_put() helpers
> drm/radeon: switch to drm_*_get(), drm_*_put() helpers
> drm/rockchip: switch to drm_*_get(), drm_*_put() helpers
> drm/tegra: switch to drm_*_get(), drm_*_put() helpers
> drm/tilcdc: switch to drm_*_get(), drm_*_put() helpers
> drm/udl: switch to drm_*_get(), drm_*_put() helpers
> drm/vc4: switch to drm_*_get(), drm_*_put() helpers
> drm/vgem: switch to drm_*_get(), drm_*_put() helpers
> drm/virtio: switch to drm_*_get(), drm_*_put() helpers
> drm/vmwgfx: switch to drm_*_get(), drm_*_put() helpers
> drm: vboxvideo: switch to drm_*_get(), drm_*_put() helpers
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 22 ++++++++---------
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 6 ++---
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 6 ++---
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 ++---
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 6 ++---
> drivers/gpu/drm/arm/malidp_planes.c | 2 +-
> drivers/gpu/drm/armada/armada_crtc.c | 22 ++++++++---------
> drivers/gpu/drm/armada/armada_drv.c | 2 +-
> drivers/gpu/drm/armada/armada_fb.c | 8 +++---
> drivers/gpu/drm/armada/armada_fbdev.c | 6 ++---
> drivers/gpu/drm/armada/armada_gem.c | 14 +++++------
> drivers/gpu/drm/armada/armada_overlay.c | 4 +--
> drivers/gpu/drm/ast/ast_fb.c | 2 +-
> drivers/gpu/drm/ast/ast_main.c | 10 ++++----
> drivers/gpu/drm/ast/ast_mode.c | 6 ++---
> drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +-
> drivers/gpu/drm/bochs/bochs_mm.c | 10 ++++----
> drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
> drivers/gpu/drm/cirrus/cirrus_main.c | 10 ++++----
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 8 +++---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 20 +++++++--------
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 +--
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 +--
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 ++++-----
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
> drivers/gpu/drm/gma500/framebuffer.c | 4 +--
> drivers/gpu/drm/gma500/gem.c | 4 +--
> drivers/gpu/drm/gma500/gma_display.c | 6 ++---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 4 +--
> drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 8 +++---
> drivers/gpu/drm/i915/i915_gem_object.h | 4 +--
> drivers/gpu/drm/i915/intel_display.c | 24 +++++++++---------
> drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> drivers/gpu/drm/i915/intel_fbdev.c | 4 +--
> drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_drm_fb.c | 4 +--
> drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_cursor.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_fb.c | 4 +--
> drivers/gpu/drm/mgag200/mgag200_main.c | 10 ++++----
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 10 ++++----
> drivers/gpu/drm/msm/adreno/a5xx_power.c | 2 +-
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 6 ++---
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 2 +-
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 2 +-
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 4 +--
> drivers/gpu/drm/msm/msm_drv.c | 8 +++---
> drivers/gpu/drm/msm/msm_fb.c | 4 +--
> drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
> drivers/gpu/drm/msm/msm_gem.c | 8 +++---
> drivers/gpu/drm/msm/msm_gem_submit.c | 4 +--
> drivers/gpu/drm/msm/msm_gpu.c | 4 +--
> drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_display.c | 8 +++---
> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_gem.c | 14 +++++------
> drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_fb.c | 4 +--
> drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_gem.c | 4 +--
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 +-
> drivers/gpu/drm/qxl/qxl_display.c | 4 +--
> drivers/gpu/drm/qxl/qxl_dumb.c | 2 +-
> drivers/gpu/drm/qxl/qxl_fb.c | 6 ++---
> drivers/gpu/drm/qxl/qxl_gem.c | 2 +-
> drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +--
> drivers/gpu/drm/qxl/qxl_object.c | 6 ++---
> drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
> drivers/gpu/drm/radeon/radeon_cursor.c | 6 ++---
> drivers/gpu/drm/radeon/radeon_display.c | 12 ++++-----
> drivers/gpu/drm/radeon/radeon_fb.c | 4 +--
> drivers/gpu/drm/radeon/radeon_gem.c | 30 +++++++++++------------
> drivers/gpu/drm/radeon/radeon_object.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 6 ++---
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +--
> drivers/gpu/drm/tegra/drm.c | 12 ++++-----
> drivers/gpu/drm/tegra/fb.c | 8 +++---
> drivers/gpu/drm/tegra/gem.c | 10 ++++----
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 6 ++---
> drivers/gpu/drm/udl/udl_fb.c | 6 ++---
> drivers/gpu/drm/udl/udl_gem.c | 4 +--
> drivers/gpu/drm/vc4/vc4_bo.c | 2 +-
> drivers/gpu/drm/vgem/vgem_drv.c | 4 +--
> drivers/gpu/drm/vgem/vgem_fence.c | 2 +-
> drivers/gpu/drm/virtio/virtgpu_display.c | 4 +--
> drivers/gpu/drm/virtio/virtgpu_gem.c | 4 +--
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 14 +++++------
> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 4 +--
> drivers/staging/vboxvideo/vbox_fb.c | 2 +-
> drivers/staging/vboxvideo/vbox_main.c | 8 +++---
> drivers/staging/vboxvideo/vbox_mode.c | 2 +-
> 103 files changed, 294 insertions(+), 294 deletions(-)
>
> --
> 2.7.4
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH v3 00/28] DRM API Conversions
From: Cihangir Akturk @ 2017-08-11 15:21 UTC (permalink / raw)
To: Deucher, Alexander
Cc: devel@driverdev.osuosl.org, linux-arm-msm@vger.kernel.org,
intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, etnaviv@lists.freedesktop.org,
amd-gfx@lists.freedesktop.org, daniel@ffwll.ch,
nouveau@lists.freedesktop.org, linux-tegra@vger.kernel.org,
virtualization@lists.linux-foundation.org,
freedreno@lists.freedesktop.org
In-Reply-To: <BN6PR12MB1652ECFCCFB8284DD7A34F7EF7890@BN6PR12MB1652.namprd12.prod.outlook.com>
On Fri, Aug 11, 2017 at 02:24:19PM +0000, Deucher, Alexander wrote:
> > -----Original Message-----
> > From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf
> > Of Cihangir Akturk
> > Sent: Friday, August 11, 2017 8:33 AM
> > Cc: devel@driverdev.osuosl.org; linux-arm-msm@vger.kernel.org; intel-
> > gfx@lists.freedesktop.org; linux-kernel@vger.kernel.org; dri-
> > devel@lists.freedesktop.org; etnaviv@lists.freedesktop.org; Cihangir Akturk;
> > amd-gfx@lists.freedesktop.org; daniel@ffwll.ch;
> > nouveau@lists.freedesktop.org; linux-tegra@vger.kernel.org;
> > virtualization@lists.linux-foundation.org; freedreno@lists.freedesktop.org
> > Subject: [PATCH v3 00/28] DRM API Conversions
> >
> > Changes since v2:
> >
> > - Patch series is based on *drm-misc-next* as suggested by Sean Paul.
> >
> > - Dropped patch 05 (drm/atmel-hlcdc) and patch 25 (drm/vc4) from v2,
> > since they were already pulled in the drm-misc-next
> >
> > Changes since v1:
> >
> > - This time patches were generated with coccinelle instead of my own
> > script, as suggested by Daniel Vetter.
> >
> > - Fixed the typo in commit messages. s/adn/and
> >
>
> FWIW, I already picked up v1 of these patches for radeon and amdgpu.
I think you can skip these patches of v3 for amdgpu and radeon, as
they have remained unchanged since v1.
>
> Alex
>
> > Note: I've included r-b, a-b tags, as these patches are identical to v1
> > except for the file: drivers/gpu/drm/i915/i915_gem_object.h
> >
> > This patch set replaces the occurrences of drm_*_reference() and
> > drm_*_unreference() with the new drm_*_get() and drm_*_put()
> > functions.
> > All patches in the series do the same thing, converting to the new APIs.
> > I created patches per DRM driver as suggested by Daniel Vetter.
> >
> > This patch set was generated by scripts/coccinelle/api/drm-get-put.cocci
> >
> > Previous thread can be reached at:
> > https://marc.info/?l=dri-devel&m=150178288816047
> >
> > Background:
> >
> > In the kernel, reference counting APIs use *_get(), *_put() style naming
> > to reference-count the objects. But DRM subsystem uses a different
> > naming for them such as *_reference(), *_unreference() which is
> > inconsistent with the other reference counting APIs in the kernel. To
> > solve this consistency issue, Thierry Reding introduced a couple of
> > functions and compatibility aliases in the following commits for them.
> >
> > commit 020a218f95bd3ceff7dd1022ff7ebc0497bc7bf9
> > Author: Thierry Reding <treding@nvidia.com>
> > Date: Tue Feb 28 15:46:38 2017 +0100
> >
> > drm: Introduce drm_mode_object_{get,put}()
> >
> > commit ad09360750afa18a0a0ce0253d6ea6033abc22e7
> > Author: Thierry Reding <treding@nvidia.com>
> > Date: Tue Feb 28 15:46:39 2017 +0100
> >
> > drm: Introduce drm_connector_{get,put}()
> >
> > commit a4a69da06bc11a937a6e417938b1bb698ee1fa46
> > Author: Thierry Reding <treding@nvidia.com>
> > Date: Tue Feb 28 15:46:40 2017 +0100
> >
> > drm: Introduce drm_framebuffer_{get,put}()
> >
> > commit e6b62714e87c8811d5564b6a0738dcde63a51774
> > Author: Thierry Reding <treding@nvidia.com>
> > Date: Tue Feb 28 15:46:41 2017 +0100
> >
> > drm: Introduce drm_gem_object_{get,put}()
> >
> > commit 6472e5090be7c78749a3c279b4faae87ab835c40
> > Author: Thierry Reding <treding@nvidia.com>
> > Date: Tue Feb 28 15:46:42 2017 +0100
> >
> > drm: Introduce drm_property_blob_{get,put}()
> >
> > Cihangir Akturk (28):
> > drm/amdgpu: switch to drm_*_get(), drm_*_put() helpers
> > drm: mali-dp: switch to drm_*_get(), drm_*_put() helpers
> > drm/armada: switch to drm_*_get(), drm_*_put() helpers
> > drm/ast: switch to drm_*_get(), drm_*_put() helpers
> > drm/bochs: switch to drm_*_get(), drm_*_put() helpers
> > drm/cirrus: switch to drm_*_get(), drm_*_put() helpers
> > drm/etnaviv: switch to drm_*_get(), drm_*_put() helpers
> > drm/exynos: switch to drm_*_get(), drm_*_put() helpers
> > drm/gma500: switch to drm_*_get(), drm_*_put() helpers
> > drm/hisilicon: switch to drm_*_get(), drm_*_put() helpers
> > drm/i915: switch to drm_*_get(), drm_*_put() helpers
> > drm/imx: switch to drm_*_get(), drm_*_put() helpers
> > drm/mediatek: switch to drm_*_get(), drm_*_put() helpers
> > drm/mgag200: switch to drm_*_get(), drm_*_put() helpers
> > drm/msm: switch to drm_*_get(), drm_*_put() helpers
> > drm/nouveau: switch to drm_*_get(), drm_*_put() helpers
> > drm/omapdrm: switch to drm_*_get(), drm_*_put() helpers
> > drm/qxl: switch to drm_*_get(), drm_*_put() helpers
> > drm/radeon: switch to drm_*_get(), drm_*_put() helpers
> > drm/rockchip: switch to drm_*_get(), drm_*_put() helpers
> > drm/tegra: switch to drm_*_get(), drm_*_put() helpers
> > drm/tilcdc: switch to drm_*_get(), drm_*_put() helpers
> > drm/udl: switch to drm_*_get(), drm_*_put() helpers
> > drm/vc4: switch to drm_*_get(), drm_*_put() helpers
> > drm/vgem: switch to drm_*_get(), drm_*_put() helpers
> > drm/virtio: switch to drm_*_get(), drm_*_put() helpers
> > drm/vmwgfx: switch to drm_*_get(), drm_*_put() helpers
> > drm: vboxvideo: switch to drm_*_get(), drm_*_put() helpers
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +--
> > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 22 ++++++++---------
> > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 6 ++---
> > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 6 ++---
> > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 ++---
> > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 6 ++---
> > drivers/gpu/drm/arm/malidp_planes.c | 2 +-
> > drivers/gpu/drm/armada/armada_crtc.c | 22 ++++++++---------
> > drivers/gpu/drm/armada/armada_drv.c | 2 +-
> > drivers/gpu/drm/armada/armada_fb.c | 8 +++---
> > drivers/gpu/drm/armada/armada_fbdev.c | 6 ++---
> > drivers/gpu/drm/armada/armada_gem.c | 14 +++++------
> > drivers/gpu/drm/armada/armada_overlay.c | 4 +--
> > drivers/gpu/drm/ast/ast_fb.c | 2 +-
> > drivers/gpu/drm/ast/ast_main.c | 10 ++++----
> > drivers/gpu/drm/ast/ast_mode.c | 6 ++---
> > drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +-
> > drivers/gpu/drm/bochs/bochs_mm.c | 10 ++++----
> > drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
> > drivers/gpu/drm/cirrus/cirrus_main.c | 10 ++++----
> > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 8 +++---
> > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 20 +++++++--------
> > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
> > drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 +--
> > drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 +--
> > drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 ++++-----
> > drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
> > drivers/gpu/drm/gma500/framebuffer.c | 4 +--
> > drivers/gpu/drm/gma500/gem.c | 4 +--
> > drivers/gpu/drm/gma500/gma_display.c | 6 ++---
> > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 4 +--
> > drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 8 +++---
> > drivers/gpu/drm/i915/i915_gem_object.h | 4 +--
> > drivers/gpu/drm/i915/intel_display.c | 24 +++++++++---------
> > drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> > drivers/gpu/drm/i915/intel_fbdev.c | 4 +--
> > drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +-
> > drivers/gpu/drm/mediatek/mtk_drm_fb.c | 4 +--
> > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 +-
> > drivers/gpu/drm/mgag200/mgag200_cursor.c | 2 +-
> > drivers/gpu/drm/mgag200/mgag200_fb.c | 4 +--
> > drivers/gpu/drm/mgag200/mgag200_main.c | 10 ++++----
> > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 10 ++++----
> > drivers/gpu/drm/msm/adreno/a5xx_power.c | 2 +-
> > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
> > drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 6 ++---
> > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 2 +-
> > drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 2 +-
> > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 4 +--
> > drivers/gpu/drm/msm/msm_drv.c | 8 +++---
> > drivers/gpu/drm/msm/msm_fb.c | 4 +--
> > drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
> > drivers/gpu/drm/msm/msm_gem.c | 8 +++---
> > drivers/gpu/drm/msm/msm_gem_submit.c | 4 +--
> > drivers/gpu/drm/msm/msm_gpu.c | 4 +--
> > drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +-
> > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 +-
> > drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-
> > drivers/gpu/drm/nouveau/nouveau_display.c | 8 +++---
> > drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
> > drivers/gpu/drm/nouveau/nouveau_gem.c | 14 +++++------
> > drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
> > drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
> > drivers/gpu/drm/omapdrm/omap_fb.c | 4 +--
> > drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
> > drivers/gpu/drm/omapdrm/omap_gem.c | 4 +--
> > drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 +-
> > drivers/gpu/drm/qxl/qxl_display.c | 4 +--
> > drivers/gpu/drm/qxl/qxl_dumb.c | 2 +-
> > drivers/gpu/drm/qxl/qxl_fb.c | 6 ++---
> > drivers/gpu/drm/qxl/qxl_gem.c | 2 +-
> > drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +--
> > drivers/gpu/drm/qxl/qxl_object.c | 6 ++---
> > drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
> > drivers/gpu/drm/radeon/radeon_cursor.c | 6 ++---
> > drivers/gpu/drm/radeon/radeon_display.c | 12 ++++-----
> > drivers/gpu/drm/radeon/radeon_fb.c | 4 +--
> > drivers/gpu/drm/radeon/radeon_gem.c | 30 +++++++++++------------
> > drivers/gpu/drm/radeon/radeon_object.c | 2 +-
> > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 6 ++---
> > drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +-
> > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +-
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +--
> > drivers/gpu/drm/tegra/drm.c | 12 ++++-----
> > drivers/gpu/drm/tegra/fb.c | 8 +++---
> > drivers/gpu/drm/tegra/gem.c | 10 ++++----
> > drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 6 ++---
> > drivers/gpu/drm/udl/udl_fb.c | 6 ++---
> > drivers/gpu/drm/udl/udl_gem.c | 4 +--
> > drivers/gpu/drm/vc4/vc4_bo.c | 2 +-
> > drivers/gpu/drm/vgem/vgem_drv.c | 4 +--
> > drivers/gpu/drm/vgem/vgem_fence.c | 2 +-
> > drivers/gpu/drm/virtio/virtgpu_display.c | 4 +--
> > drivers/gpu/drm/virtio/virtgpu_gem.c | 4 +--
> > drivers/gpu/drm/virtio/virtgpu_ioctl.c | 14 +++++------
> > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 4 +--
> > drivers/staging/vboxvideo/vbox_fb.c | 2 +-
> > drivers/staging/vboxvideo/vbox_main.c | 8 +++---
> > drivers/staging/vboxvideo/vbox_mode.c | 2 +-
> > 103 files changed, 294 insertions(+), 294 deletions(-)
> >
> > --
> > 2.7.4
> >
> > _______________________________________________
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH v3 06/28] drm/cirrus: switch to drm_*_get(), drm_*_put() helpers
From: Sean Paul @ 2017-08-11 16:02 UTC (permalink / raw)
To: Cihangir Akturk
Cc: David Airlie, Daniel Vetter, linux-kernel, dri-devel,
Gabriel Krisman Bertazi, Sean Paul, daniel, Alex Deucher,
Dave Airlie, virtualization, Peter Rosin, Ville Syrjälä,
Laurent Pinchart
In-Reply-To: <1502454794-28558-7-git-send-email-cakturk@gmail.com>
On Fri, Aug 11, 2017 at 03:32:52PM +0300, Cihangir Akturk wrote:
> Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference()
> and drm_*_unreference() helpers.
>
> drm_*_reference() and drm_*_unreference() functions are just
> compatibility alias for drm_*_get() and drm_*_put() and should not be
> used by new code. So convert all users of compatibility functions to
> use the new APIs.
>
> Generated by: scripts/coccinelle/api/drm-get-put.cocci
>
> Signed-off-by: Cihangir Akturk <cakturk@gmail.com>
Applied to drm-misc-next, thank you!
Sean
> ---
> drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
> drivers/gpu/drm/cirrus/cirrus_main.c | 10 +++++-----
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index 0f6815f..32fbfba 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -251,7 +251,7 @@ static int cirrus_fbdev_destroy(struct drm_device *dev,
> drm_fb_helper_unregister_fbi(&gfbdev->helper);
>
> if (gfb->obj) {
> - drm_gem_object_unreference_unlocked(gfb->obj);
> + drm_gem_object_put_unlocked(gfb->obj);
> gfb->obj = NULL;
> }
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c b/drivers/gpu/drm/cirrus/cirrus_main.c
> index e7fc95f..b5f5285 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_main.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_main.c
> @@ -18,7 +18,7 @@ static void cirrus_user_framebuffer_destroy(struct drm_framebuffer *fb)
> {
> struct cirrus_framebuffer *cirrus_fb = to_cirrus_framebuffer(fb);
>
> - drm_gem_object_unreference_unlocked(cirrus_fb->obj);
> + drm_gem_object_put_unlocked(cirrus_fb->obj);
> drm_framebuffer_cleanup(fb);
> kfree(fb);
> }
> @@ -67,13 +67,13 @@ cirrus_user_framebuffer_create(struct drm_device *dev,
>
> cirrus_fb = kzalloc(sizeof(*cirrus_fb), GFP_KERNEL);
> if (!cirrus_fb) {
> - drm_gem_object_unreference_unlocked(obj);
> + drm_gem_object_put_unlocked(obj);
> return ERR_PTR(-ENOMEM);
> }
>
> ret = cirrus_framebuffer_init(dev, cirrus_fb, mode_cmd, obj);
> if (ret) {
> - drm_gem_object_unreference_unlocked(obj);
> + drm_gem_object_put_unlocked(obj);
> kfree(cirrus_fb);
> return ERR_PTR(ret);
> }
> @@ -261,7 +261,7 @@ int cirrus_dumb_create(struct drm_file *file,
> return ret;
>
> ret = drm_gem_handle_create(file, gobj, &handle);
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> if (ret)
> return ret;
>
> @@ -310,7 +310,7 @@ cirrus_dumb_mmap_offset(struct drm_file *file,
> bo = gem_to_cirrus_bo(obj);
> *offset = cirrus_bo_mmap_offset(bo);
>
> - drm_gem_object_unreference_unlocked(obj);
> + drm_gem_object_put_unlocked(obj);
>
> return 0;
> }
> --
> 2.7.4
>
--
Sean Paul, Software Engineer, Google / Chromium OS
^ permalink raw reply
* Re: [PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.
From: Michael S. Tsirkin @ 2017-08-11 17:23 UTC (permalink / raw)
To: Paolo Bonzini
Cc: jejb, linux-scsi, martin.petersen, linux-kernel, virtualization,
hch
In-Reply-To: <64d3c483-076b-1362-b284-30dda704f80c@redhat.com>
On Fri, Aug 11, 2017 at 04:09:26PM +0200, Paolo Bonzini wrote:
> On 10/08/2017 23:41, Michael S. Tsirkin wrote:
> >>> Then we probably should fail probe if vq size is too small.
> >> What does this mean?
> >
> > We must prevent driver from submitting s/g lists > vq size to device.
>
> What is the rationale for the limit?
So the host knows what it needs to support.
> It makes no sense if indirect
> descriptors are available, especially because...
>
> > Either tell linux to avoid s/g lists that are too long, or
> > simply fail request if this happens, or refuse to attach driver to device.
> >
> > Later option would look something like this within probe:
> >
> > for (i = VIRTIO_SCSI_VQ_BASE; i < num_vqs; i++)
> > if (vqs[i]->num < MAX_SG_USED_BY_LINUX)
> > goto err;
> >
> >
> > I don't know what's MAX_SG_USED_BY_LINUX though.
> >
>
> ... both virtio-blk and virtio-scsi transmit their own value for the
> maximum sg list size (max_seg in virtio-scsi, seg_max in virtio-blk).
>
> Paolo
No other device has it, and it seemed like a good idea to
limit it generally at the time.
we can fix the spec to relax the requirement for blk and scsi -
want to submit a proposal? Alternatively, add a generic field
for that.
For a quick fix, make sure vq size is >= max sg.
--
MST
^ permalink raw reply
* Re: [PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.
From: Paolo Bonzini @ 2017-08-11 18:36 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: jejb, linux-scsi, martin.petersen, linux-kernel, virtualization,
hch
In-Reply-To: <20170811201843-mutt-send-email-mst@kernel.org>
On 11/08/2017 19:23, Michael S. Tsirkin wrote:
> On Fri, Aug 11, 2017 at 04:09:26PM +0200, Paolo Bonzini wrote:
>> On 10/08/2017 23:41, Michael S. Tsirkin wrote:
>>>>> Then we probably should fail probe if vq size is too small.
>>>> What does this mean?
>>>
>>> We must prevent driver from submitting s/g lists > vq size to device.
>>
>> What is the rationale for the limit?
>
> So the host knows what it needs to support.
>
>> both virtio-blk and virtio-scsi transmit their own value for the
>> maximum sg list size (max_seg in virtio-scsi, seg_max in virtio-blk).
>
> No other device has it, and it seemed like a good idea to
> limit it generally at the time.
>
> we can fix the spec to relax the requirement for blk and scsi -
> want to submit a proposal? Alternatively, add a generic field
> for that.
Yes, I can submit a proposal. blk and scsi are the ones that are most
likely to have very long sg lists.
When I was designing scsi I just copied that field from blk. :)
Paolo
^ permalink raw reply
* [PATCH] virtio-net: make array guest_offloads static
From: Colin King @ 2017-08-12 21:45 UTC (permalink / raw)
To: Michael S . Tsirkin, Jason Wang, virtualization, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The array guest_offloads is local to the source and does not need to
be in global scope, so make it static. Also tweak formatting.
Cleans up sparse warnings:
symbol 'guest_offloads' was not declared. Should it be static?
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/virtio_net.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index e90de2186ffc..a3f3c66b4530 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -57,10 +57,12 @@ DECLARE_EWMA(pkt_len, 0, 64)
#define VIRTNET_DRIVER_VERSION "1.0.0"
-const unsigned long guest_offloads[] = { VIRTIO_NET_F_GUEST_TSO4,
- VIRTIO_NET_F_GUEST_TSO6,
- VIRTIO_NET_F_GUEST_ECN,
- VIRTIO_NET_F_GUEST_UFO };
+static const unsigned long guest_offloads[] = {
+ VIRTIO_NET_F_GUEST_TSO4,
+ VIRTIO_NET_F_GUEST_TSO6,
+ VIRTIO_NET_F_GUEST_ECN,
+ VIRTIO_NET_F_GUEST_UFO
+};
struct virtnet_stats {
struct u64_stats_sync tx_syncp;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net] Revert "vhost: cache used event for better performance"
From: Koichiro Den @ 2017-08-13 14:11 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20170809073422-mutt-send-email-mst@kernel.org>
Thanks for your comments, Michael and Jason. And I'm sorry about late response.
To be honest, I am on a summer vacation until next Tuesday.
I noticed that what I wrote was not sufficient. Regardless of caching mechanism
existence, the "event" could legitimately be at any point out of the latest
interval, which vhost_notify checks it against, meaning that if it's out of the
interval we cannot distinguish whether or not it lags behind or has a lead. And
it seems to conform to the spec. Thanks for leading me to the spec. The corner
case I point out here is:
(0) event idx feature turned on + TX napi turned off
-> (1) guest-side TX traffic bursting occurs and delayed callback set
-> (2) some interruption triggers skb_xmit_done
-> (3) guest-side modest traffic makes the interval proceed to unbounded extent
without updating "event" since NO_INTERRUPT continues to be set on its shadow
flag.
IMHO, if you plan to make TX napi the only choice, doing this sort of
optimisation beforehand seems likely to be in vain.
So, if the none-TX napi case continues to coexist, what I would like to suggest
is not just the sort of my last email, but like making maximum staleness of
"event" less than or equal to vq.num, and afterward caching suggestion.
Otherwise, I guess I should not repost my last email since it would make matters
too complicated even though it will soon be removed when TX-napi becomes the
only choice.
Thanks!
On Wed, 2017-08-09 at 07:37 +0300, Michael S. Tsirkin wrote:
> On Wed, Aug 09, 2017 at 10:38:10AM +0800, Jason Wang wrote:
> > I think don't think current code can work well if vq.num is grater than
> > 2^15. Since all cached idx is u16. This looks like a bug which needs to be
> > fixed.
>
> That's a limitation of virtio 1.0.
>
> > > * else if the interval of vq.num is [2^15, 2^16):
> > > the logic in the original patch (809ecb9bca6a9) suffices
> > > * else (= less than 2^15) (optional):
> > > checking only (vring_need_event(vq->last_used_event, new + vq->num, new)
> > > would suffice.
> > >
> > > Am I missing something, or is this irrelevant?
>
> Could you pls repost the suggestion copying virtio-dev mailing list
> (subscriber only, sorry about that, but host/guest ABI discussions
> need to copy that list)?
>
> > Looks not, I think this may work. Let me do some test.
> >
> > Thanks
>
> I think that at this point it's prudent to add a feature bit
> as the virtio spec does not require to never move the event index back.
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net] Revert "vhost: cache used event for better performance"
From: Koichiro Den @ 2017-08-13 16:12 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <1502633460.3547.1.camel@klaipeden.com>
Sorry I mistakenly focused on NET case, please pass it over. I will do any
relevant suggestion in patch-based way. Thanks.
On Sun, 2017-08-13 at 23:11 +0900, Koichiro Den wrote:
> Thanks for your comments, Michael and Jason. And I'm sorry about late
> response.
> To be honest, I am on a summer vacation until next Tuesday.
>
> I noticed that what I wrote was not sufficient. Regardless of caching
> mechanism
> existence, the "event" could legitimately be at any point out of the latest
> interval, which vhost_notify checks it against, meaning that if it's out of
> the
> interval we cannot distinguish whether or not it lags behind or has a
> lead. And
> it seems to conform to the spec. Thanks for leading me to the spec. The corner
> case I point out here is:
> (0) event idx feature turned on + TX napi turned off
> -> (1) guest-side TX traffic bursting occurs and delayed callback set
> -> (2) some interruption triggers skb_xmit_done
> -> (3) guest-side modest traffic makes the interval proceed to unbounded
> extent
> without updating "event" since NO_INTERRUPT continues to be set on its shadow
> flag.
>
> IMHO, if you plan to make TX napi the only choice, doing this sort of
> optimisation beforehand seems likely to be in vain.
>
> So, if the none-TX napi case continues to coexist, what I would like to
> suggest
> is not just the sort of my last email, but like making maximum staleness of
> "event" less than or equal to vq.num, and afterward caching suggestion.
> Otherwise, I guess I should not repost my last email since it would make
> matters
> too complicated even though it will soon be removed when TX-napi becomes the
> only choice.
>
> Thanks!
>
>
> On Wed, 2017-08-09 at 07:37 +0300, Michael S. Tsirkin wrote:
> > On Wed, Aug 09, 2017 at 10:38:10AM +0800, Jason Wang wrote:
> > > I think don't think current code can work well if vq.num is grater than
> > > 2^15. Since all cached idx is u16. This looks like a bug which needs to be
> > > fixed.
> >
> > That's a limitation of virtio 1.0.
> >
> > > > * else if the interval of vq.num is [2^15, 2^16):
> > > > the logic in the original patch (809ecb9bca6a9) suffices
> > > > * else (= less than 2^15) (optional):
> > > > checking only (vring_need_event(vq->last_used_event, new + vq->num, new)
> > > > would suffice.
> > > >
> > > > Am I missing something, or is this irrelevant?
> >
> > Could you pls repost the suggestion copying virtio-dev mailing list
> > (subscriber only, sorry about that, but host/guest ABI discussions
> > need to copy that list)?
> >
> > > Looks not, I think this may work. Let me do some test.
> > >
> > > Thanks
> >
> > I think that at this point it's prudent to add a feature bit
> > as the virtio spec does not require to never move the event index back.
> >
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] virtio-net: make array guest_offloads static
From: David Miller @ 2017-08-14 3:10 UTC (permalink / raw)
To: colin.king; +Cc: mst, netdev, kernel-janitors, linux-kernel, virtualization
In-Reply-To: <20170812214553.6073-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 12 Aug 2017 22:45:53 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The array guest_offloads is local to the source and does not need to
> be in global scope, so make it static. Also tweak formatting.
>
> Cleans up sparse warnings:
> symbol 'guest_offloads' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* RE: [RFC] virtio-iommu version 0.4
From: Tian, Kevin @ 2017-08-14 8:27 UTC (permalink / raw)
To: Jean-Philippe Brucker, iommu@lists.linux-foundation.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
virtio-dev@lists.oasis-open.org
Cc: lorenzo.pieralisi@arm.com, mst@redhat.com, marc.zyngier@arm.com,
will.deacon@arm.com, eric.auger@redhat.com, robin.murphy@arm.com,
eric.auger.pro@gmail.com
In-Reply-To: <20170804181927.12148-1-jean-philippe.brucker@arm.com>
> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker@arm.com]
> Sent: Saturday, August 5, 2017 2:19 AM
>
> This is the continuation of my proposal for virtio-iommu, the para-
> virtualized IOMMU. Here is a summary of the changes since last time [1]:
>
> * The virtio-iommu document now resembles an actual specification. It is
> split into a formal description of the virtio device, and implementation
> notes. Please find sources and binaries at [2].
>
> * Added a probe request to describe to the guest different properties that
> do not fit in firmware or in the virtio config space. This is a
> necessary stepping stone for extending the virtio-iommu.
>
> * There is a working Qemu prototype [3], thanks to Eric Auger and Bharat
> Bhushan.
>
> You can find the Linux driver and kvmtool device at [4] and [5]. I
> plan to rework driver and kvmtool device slightly before sending the
> patches.
>
> To understand the virtio-iommu, I advise to first read introduction and
> motivation, then skim through implementation notes and finally look at the
> device specification.
>
> I wasn't sure how to organize the review. For those who prefer to comment
> inline, I attached v0.4 of device-operations.tex and topology.tex+MSI.tex
> to this thread. They are the biggest chunks of the document. But LaTeX
> isn't very pleasant to read, so you can simply send a list of comments in
> relation to section numbers and a few words of context, we'll manage.
>
> ---
> Version numbers 0.1-0.4 are arbitrary. I'm hoping they allow to compare
> more easily differences since the RFC (see [6]), but haven't been made
> public so far. This is the first public posting since initial proposal
> [1], and the following describes all changes.
>
> ## v0.1 ##
>
> Content is the same as the RFC, but formatted to LaTeX. 'make' generates
> one PDF and one HTML document.
>
> ## v0.2 ##
>
> Add introductions, improve topology example and firmware description
> based
> on feedback and a number of useful discussions.
>
> ## v0.3 ##
>
> Add normative sections (MUST, SHOULD, etc). Clarify some things, tighten
> the device and driver behaviour. Unmap semantics are consolidated; they
> are now closer to VFIO Type1 v2 semantics.
>
> ## v0.4 ##
>
> Introduce PROBE requests. They provide per-endpoint information to the
> driver that couldn't be described otherwise.
>
> For the moment, they allow to handle MSIs on x86 virtual platforms (see
> 3.2). To do that we communicate reserved IOVA regions, that will also be
> useful for describing regions that cannot be mapped for a given endpoint,
> for instance addresses that correspond to a PCI bridge window.
>
> Introducing such a large framework for this tiny feature may seem
> overkill, but it is needed for future extensions of the virtio-iommu and I
> believe it really is worth the effort.
>
> ## Future ##
>
> Other extensions are in preparation. I won't detail them here because v0.4
> already is a lot to digest, but in short, building on top of PROBE:
>
> * First, since the IOMMU is paravirtualized, the device can expose some
> properties of the physical topology to the guest, and let it allocate
> resources more efficiently. For example, when the virtio-iommu manages
> both physical and emulated endpoints, with different underlying IOMMUs,
> we now have a way to describe multiple page and block granularities,
> instead of forcing the guest to use the most restricted one for all
> endpoints. This will most likely be in v0.5.
emulated IOMMU has similar requirement, e.g. available PASID bits,
address widths, etc. which may break guest usage if not aligned to
physical limitation. Suppose we can introduce a general interface
through VFIO for all vIOMMU incarnations.
>
> * Then on top of that, a major improvement will describe hardware
> acceleration features available to the guest. There is what I call "Page
> Table Handover" (or simply, from the host POV, "Nested"), the ability
> for the guest to manipulate its own page tables instead of sending
> MAP/UNMAP requests to the host. This, along with IO Page Fault
> reporting, will also permit SVM virtualization on different platforms.
what's your planned cadence for future versions? :-)
>
> Thanks,
> Jean
>
> [1] http://www.spinics.net/lists/kvm/msg147990.html
> [2] git://linux-arm.org/virtio-iommu.git branch viommu/v0.4
> http://www.linux-arm.org/git?p=virtio-
> iommu.git;a=blob;f=dist/v0.4/virtio-iommu-v0.4.pdf
> I reiterate the disclaimers: don't use this document as a reference,
> it's a draft. It's also not an OASIS document yet. It may be riddled
> with mistakes. As this is a working draft, it is unstable and I do not
> guarantee backward compatibility of future versions.
> [3] https://lists.gnu.org/archive/html/qemu-arm/2017-08/msg00004.html
> [4] git://linux-arm.org/linux-jpb.git virtio-iommu/v0.4
> Warning: UAPI headers have changed! They didn't follow the spec,
> please update. (Use branch v0.1, that has the old headers, for the
> Qemu prototype [3])
> [5] git://linux-arm.org/kvmtool-jpb.git virtio-iommu/v0.4
> Warning: command-line has changed! Use --viommu vfio[,opts] and
> --viommu virtio[,opts] to instantiate a device.
> [6] http://www.linux-arm.org/git?p=virtio-iommu.git;a=tree;f=dist/diffs
^ permalink raw reply
* Re: [RFC] virtio-iommu version 0.4
From: Jean-Philippe Brucker @ 2017-08-14 9:38 UTC (permalink / raw)
To: Tian, Kevin, iommu@lists.linux-foundation.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
virtio-dev@lists.oasis-open.org
Cc: lorenzo.pieralisi@arm.com, mst@redhat.com, marc.zyngier@arm.com,
will.deacon@arm.com, eric.auger@redhat.com, robin.murphy@arm.com,
eric.auger.pro@gmail.com
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D190D7173C@SHSMSX101.ccr.corp.intel.com>
On 14/08/17 09:27, Tian, Kevin wrote:
>> * First, since the IOMMU is paravirtualized, the device can expose some
>> properties of the physical topology to the guest, and let it allocate
>> resources more efficiently. For example, when the virtio-iommu manages
>> both physical and emulated endpoints, with different underlying IOMMUs,
>> we now have a way to describe multiple page and block granularities,
>> instead of forcing the guest to use the most restricted one for all
>> endpoints. This will most likely be in v0.5.
>
> emulated IOMMU has similar requirement, e.g. available PASID bits,
> address widths, etc. which may break guest usage if not aligned to
> physical limitation. Suppose we can introduce a general interface
> through VFIO for all vIOMMU incarnations.
A nice location for this kind of info would be sysfs, as discussed in the
SVM virtualization thread [1]. Properties of an IOMMU could be described
in /sys/class/iommu/<dev>. Properties of a PCI device are available in its
PASID/PRI capabilities. For platform devices we'll have to look at DT and
ACPI properties in /sys/firmware.
>> * Then on top of that, a major improvement will describe hardware
>> acceleration features available to the guest. There is what I call "Page
>> Table Handover" (or simply, from the host POV, "Nested"), the ability
>> for the guest to manipulate its own page tables instead of sending
>> MAP/UNMAP requests to the host. This, along with IO Page Fault
>> reporting, will also permit SVM virtualization on different platforms.
>
> what's your planned cadence for future versions? :-)
Hard to say, it depends on a number of things. I have various other tasks
eating up my bandwidth at the moment and I may have to considerably rework
this version depending on the feedback it gets. Ideally, I would like to
get the base driver merged and a proposal for hardware acceleration out by
the end of the year, but I obviously can't make any guarantee.
Thanks,
Jean
[1] https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg05731.html
^ permalink raw reply
* [PATCH net-next 0/4] various sizeof cleanups
From: Stephen Hemminger @ 2017-08-15 17:29 UTC (permalink / raw)
To: mlindner, stephen, mst, jasowang
Cc: linux-rdma, netdev, Stephen Hemminger, virtualization
Noticed some places that were using sizeof as an operator.
This is legal C but is not the convention used in the kernel.
Stephen Hemminger (4):
tun/tap: use paren's with sizeof
virtio: put paren around sizeof
skge: add paren around sizeof arg
mlx4: sizeof style usage
drivers/net/ethernet/marvell/skge.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/alloc.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/cmd.c | 4 ++--
drivers/net/ethernet/mellanox/mlx4/en_resources.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/eq.c | 20 +++++++++---------
drivers/net/ethernet/mellanox/mlx4/fw.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/icm.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/icm.h | 4 ++--
drivers/net/ethernet/mellanox/mlx4/intf.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/main.c | 12 +++++------
drivers/net/ethernet/mellanox/mlx4/mcg.c | 12 +++++------
drivers/net/ethernet/mellanox/mlx4/mr.c | 10 ++++-----
drivers/net/ethernet/mellanox/mlx4/qp.c | 12 +++++------
.../net/ethernet/mellanox/mlx4/resource_tracker.c | 24 +++++++++++-----------
drivers/net/tap.c | 2 +-
drivers/net/tun.c | 2 +-
drivers/net/virtio_net.c | 2 +-
19 files changed, 60 insertions(+), 60 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH net-next 1/4] tun/tap: use paren's with sizeof
From: Stephen Hemminger @ 2017-08-15 17:29 UTC (permalink / raw)
To: mlindner, stephen, mst, jasowang
Cc: linux-rdma, netdev, Stephen Hemminger, virtualization
In-Reply-To: <20170815172919.26153-1-sthemmin@microsoft.com>
Although sizeof is an operator in C. The kernel coding style convention
is to always use it like a function and add parenthesis.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/tap.c | 2 +-
drivers/net/tun.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index 0d039411e64c..21b71ae947fd 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -1215,7 +1215,7 @@ int tap_queue_resize(struct tap_dev *tap)
int n = tap->numqueues;
int ret, i = 0;
- arrays = kmalloc(sizeof *arrays * n, GFP_KERNEL);
+ arrays = kmalloc_array(n, sizeof(*arrays), GFP_KERNEL);
if (!arrays)
return -ENOMEM;
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 5892284eb8d0..f5017121cd57 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2737,7 +2737,7 @@ static int tun_queue_resize(struct tun_struct *tun)
int n = tun->numqueues + tun->numdisabled;
int ret, i;
- arrays = kmalloc(sizeof *arrays * n, GFP_KERNEL);
+ arrays = kmalloc_array(n, sizeof(*arrays), GFP_KERNEL);
if (!arrays)
return -ENOMEM;
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 2/4] virtio: put paren around sizeof
From: Stephen Hemminger @ 2017-08-15 17:29 UTC (permalink / raw)
To: mlindner, stephen, mst, jasowang
Cc: linux-rdma, netdev, Stephen Hemminger, virtualization
In-Reply-To: <20170815172919.26153-1-sthemmin@microsoft.com>
Kernel coding style is to put paren around operand of sizeof.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index a3f3c66b4530..4302f313d9a7 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -319,7 +319,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
hdr_len = vi->hdr_len;
if (vi->mergeable_rx_bufs)
- hdr_padded_len = sizeof *hdr;
+ hdr_padded_len = sizeof(*hdr);
else
hdr_padded_len = sizeof(struct padded_vnet_hdr);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 3/4] skge: add paren around sizeof arg
From: Stephen Hemminger @ 2017-08-15 17:29 UTC (permalink / raw)
To: mlindner, stephen, mst, jasowang
Cc: linux-rdma, netdev, Stephen Hemminger, virtualization
In-Reply-To: <20170815172919.26153-1-sthemmin@microsoft.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/ethernet/marvell/skge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index 5d7d94de4e00..8a835e82256a 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -3516,7 +3516,7 @@ static const char *skge_board_name(const struct skge_hw *hw)
if (skge_chips[i].id == hw->chip_id)
return skge_chips[i].name;
- snprintf(buf, sizeof buf, "chipid 0x%x", hw->chip_id);
+ snprintf(buf, sizeof(buf), "chipid 0x%x", hw->chip_id);
return buf;
}
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 4/4] mlx4: sizeof style usage
From: Stephen Hemminger @ 2017-08-15 17:29 UTC (permalink / raw)
To: mlindner, stephen, mst, jasowang
Cc: linux-rdma, netdev, Stephen Hemminger, virtualization
In-Reply-To: <20170815172919.26153-1-sthemmin@microsoft.com>
The kernel coding style is to treat sizeof as a function
(ie. with parenthesis) not as an operator.
Also use kcalloc and kmalloc_array
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/ethernet/mellanox/mlx4/alloc.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/cmd.c | 4 ++--
drivers/net/ethernet/mellanox/mlx4/en_resources.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/eq.c | 20 +++++++++---------
drivers/net/ethernet/mellanox/mlx4/fw.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/icm.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/icm.h | 4 ++--
drivers/net/ethernet/mellanox/mlx4/intf.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/main.c | 12 +++++------
drivers/net/ethernet/mellanox/mlx4/mcg.c | 12 +++++------
drivers/net/ethernet/mellanox/mlx4/mr.c | 10 ++++-----
drivers/net/ethernet/mellanox/mlx4/qp.c | 12 +++++------
.../net/ethernet/mellanox/mlx4/resource_tracker.c | 24 +++++++++++-----------
15 files changed, 56 insertions(+), 56 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/alloc.c b/drivers/net/ethernet/mellanox/mlx4/alloc.c
index b651c1210555..6dabd983e7e0 100644
--- a/drivers/net/ethernet/mellanox/mlx4/alloc.c
+++ b/drivers/net/ethernet/mellanox/mlx4/alloc.c
@@ -186,7 +186,7 @@ int mlx4_bitmap_init(struct mlx4_bitmap *bitmap, u32 num, u32 mask,
bitmap->effective_len = bitmap->avail;
spin_lock_init(&bitmap->lock);
bitmap->table = kzalloc(BITS_TO_LONGS(bitmap->max) *
- sizeof (long), GFP_KERNEL);
+ sizeof(long), GFP_KERNEL);
if (!bitmap->table)
return -ENOMEM;
diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index 674773b28b2e..97aed30ead21 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -2637,7 +2637,7 @@ int mlx4_cmd_use_events(struct mlx4_dev *dev)
int err = 0;
priv->cmd.context = kmalloc(priv->cmd.max_cmds *
- sizeof (struct mlx4_cmd_context),
+ sizeof(struct mlx4_cmd_context),
GFP_KERNEL);
if (!priv->cmd.context)
return -ENOMEM;
@@ -2695,7 +2695,7 @@ struct mlx4_cmd_mailbox *mlx4_alloc_cmd_mailbox(struct mlx4_dev *dev)
{
struct mlx4_cmd_mailbox *mailbox;
- mailbox = kmalloc(sizeof *mailbox, GFP_KERNEL);
+ mailbox = kmalloc(sizeof(*mailbox), GFP_KERNEL);
if (!mailbox)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_resources.c b/drivers/net/ethernet/mellanox/mlx4/en_resources.c
index 86d2d42d658d..5a47f9669621 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_resources.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_resources.c
@@ -44,7 +44,7 @@ void mlx4_en_fill_qp_context(struct mlx4_en_priv *priv, int size, int stride,
struct mlx4_en_dev *mdev = priv->mdev;
struct net_device *dev = priv->dev;
- memset(context, 0, sizeof *context);
+ memset(context, 0, sizeof(*context));
context->flags = cpu_to_be32(7 << 16 | rss << MLX4_RSS_QPC_FLAG_OFFSET);
context->pd = cpu_to_be32(mdev->priv_pdn);
context->mtu_msgmax = 0xff;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index bf1638044a7a..dcb8f8f84a97 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -1056,7 +1056,7 @@ static int mlx4_en_config_rss_qp(struct mlx4_en_priv *priv, int qpn,
}
qp->event = mlx4_en_sqp_event;
- memset(context, 0, sizeof *context);
+ memset(context, 0, sizeof(*context));
mlx4_en_fill_qp_context(priv, ring->actual_size, ring->stride, 0, 0,
qpn, ring->cqn, -1, context);
context->db_rec_addr = cpu_to_be64(ring->wqres.db.dma);
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index 73faa3d77921..bcf422efd3b8 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -643,7 +643,7 @@ static void build_inline_wqe(struct mlx4_en_tx_desc *tx_desc,
void *fragptr)
{
struct mlx4_wqe_inline_seg *inl = &tx_desc->inl;
- int spc = MLX4_INLINE_ALIGN - CTRL_SIZE - sizeof *inl;
+ int spc = MLX4_INLINE_ALIGN - CTRL_SIZE - sizeof(*inl);
unsigned int hlen = skb_headlen(skb);
if (skb->len <= spc) {
diff --git a/drivers/net/ethernet/mellanox/mlx4/eq.c b/drivers/net/ethernet/mellanox/mlx4/eq.c
index 07406cf2eacd..b98698bf75dd 100644
--- a/drivers/net/ethernet/mellanox/mlx4/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/eq.c
@@ -259,7 +259,7 @@ int mlx4_gen_pkey_eqe(struct mlx4_dev *dev, int slave, u8 port)
if (!s_slave->active)
return 0;
- memset(&eqe, 0, sizeof eqe);
+ memset(&eqe, 0, sizeof(eqe));
eqe.type = MLX4_EVENT_TYPE_PORT_MNG_CHG_EVENT;
eqe.subtype = MLX4_DEV_PMC_SUBTYPE_PKEY_TABLE;
@@ -276,7 +276,7 @@ int mlx4_gen_guid_change_eqe(struct mlx4_dev *dev, int slave, u8 port)
/*don't send if we don't have the that slave */
if (dev->persist->num_vfs < slave)
return 0;
- memset(&eqe, 0, sizeof eqe);
+ memset(&eqe, 0, sizeof(eqe));
eqe.type = MLX4_EVENT_TYPE_PORT_MNG_CHG_EVENT;
eqe.subtype = MLX4_DEV_PMC_SUBTYPE_GUID_INFO;
@@ -295,7 +295,7 @@ int mlx4_gen_port_state_change_eqe(struct mlx4_dev *dev, int slave, u8 port,
/*don't send if we don't have the that slave */
if (dev->persist->num_vfs < slave)
return 0;
- memset(&eqe, 0, sizeof eqe);
+ memset(&eqe, 0, sizeof(eqe));
eqe.type = MLX4_EVENT_TYPE_PORT_CHANGE;
eqe.subtype = port_subtype_change;
@@ -432,7 +432,7 @@ int mlx4_gen_slaves_port_mgt_ev(struct mlx4_dev *dev, u8 port, int attr)
{
struct mlx4_eqe eqe;
- memset(&eqe, 0, sizeof eqe);
+ memset(&eqe, 0, sizeof(eqe));
eqe.type = MLX4_EVENT_TYPE_PORT_MNG_CHG_EVENT;
eqe.subtype = MLX4_DEV_PMC_SUBTYPE_PORT_INFO;
@@ -726,7 +726,7 @@ static int mlx4_eq_int(struct mlx4_dev *dev, struct mlx4_eq *eq)
}
memcpy(&priv->mfunc.master.comm_arm_bit_vector,
eqe->event.comm_channel_arm.bit_vec,
- sizeof eqe->event.comm_channel_arm.bit_vec);
+ sizeof(eqe)->event.comm_channel_arm.bit_vec);
queue_work(priv->mfunc.master.comm_wq,
&priv->mfunc.master.comm_work);
break;
@@ -984,15 +984,15 @@ static int mlx4_create_eq(struct mlx4_dev *dev, int nent,
*/
npages = PAGE_ALIGN(eq->nent * dev->caps.eqe_size) / PAGE_SIZE;
- eq->page_list = kmalloc(npages * sizeof *eq->page_list,
- GFP_KERNEL);
+ eq->page_list = kmalloc_array(npages, sizeof(*eq->page_list),
+ GFP_KERNEL);
if (!eq->page_list)
goto err_out;
for (i = 0; i < npages; ++i)
eq->page_list[i].buf = NULL;
- dma_list = kmalloc(npages * sizeof *dma_list, GFP_KERNEL);
+ dma_list = kmalloc_array(npages, sizeof(*dma_list), GFP_KERNEL);
if (!dma_list)
goto err_out_free;
@@ -1161,7 +1161,7 @@ int mlx4_alloc_eq_table(struct mlx4_dev *dev)
struct mlx4_priv *priv = mlx4_priv(dev);
priv->eq_table.eq = kcalloc(dev->caps.num_eqs - dev->caps.reserved_eqs,
- sizeof *priv->eq_table.eq, GFP_KERNEL);
+ sizeof(*priv->eq_table.eq), GFP_KERNEL);
if (!priv->eq_table.eq)
return -ENOMEM;
@@ -1180,7 +1180,7 @@ int mlx4_init_eq_table(struct mlx4_dev *dev)
int i;
priv->eq_table.uar_map = kcalloc(mlx4_num_eq_uar(dev),
- sizeof *priv->eq_table.uar_map,
+ sizeof(*priv->eq_table.uar_map),
GFP_KERNEL);
if (!priv->eq_table.uar_map) {
err = -ENOMEM;
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 041c0ed65929..042707623922 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -57,7 +57,7 @@ MODULE_PARM_DESC(enable_qos, "Enable Enhanced QoS support (default: off)");
do { \
void *__p = (char *) (source) + (offset); \
u64 val; \
- switch (sizeof (dest)) { \
+ switch (sizeof(dest)) { \
case 1: (dest) = *(u8 *) __p; break; \
case 2: (dest) = be16_to_cpup(__p); break; \
case 4: (dest) = be32_to_cpup(__p); break; \
diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c b/drivers/net/ethernet/mellanox/mlx4/icm.c
index 5a7816e7c7b4..a822f7a56bc5 100644
--- a/drivers/net/ethernet/mellanox/mlx4/icm.c
+++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
@@ -400,7 +400,7 @@ int mlx4_init_icm_table(struct mlx4_dev *dev, struct mlx4_icm_table *table,
obj_per_chunk = MLX4_TABLE_CHUNK_SIZE / obj_size;
num_icm = (nobj + obj_per_chunk - 1) / obj_per_chunk;
- table->icm = kcalloc(num_icm, sizeof *table->icm, GFP_KERNEL);
+ table->icm = kcalloc(num_icm, sizeof(*table->icm), GFP_KERNEL);
if (!table->icm)
return -ENOMEM;
table->virt = virt;
diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.h b/drivers/net/ethernet/mellanox/mlx4/icm.h
index dee67fa39107..c9169a490557 100644
--- a/drivers/net/ethernet/mellanox/mlx4/icm.h
+++ b/drivers/net/ethernet/mellanox/mlx4/icm.h
@@ -39,8 +39,8 @@
#include <linux/mutex.h>
#define MLX4_ICM_CHUNK_LEN \
- ((256 - sizeof (struct list_head) - 2 * sizeof (int)) / \
- (sizeof (struct scatterlist)))
+ ((256 - sizeof(struct list_head) - 2 * sizeof(int)) / \
+ (sizeof(struct scatterlist)))
enum {
MLX4_ICM_PAGE_SHIFT = 12,
diff --git a/drivers/net/ethernet/mellanox/mlx4/intf.c b/drivers/net/ethernet/mellanox/mlx4/intf.c
index e00f627331cb..2edcce98ab2d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/intf.c
+++ b/drivers/net/ethernet/mellanox/mlx4/intf.c
@@ -53,7 +53,7 @@ static void mlx4_add_device(struct mlx4_interface *intf, struct mlx4_priv *priv)
{
struct mlx4_device_context *dev_ctx;
- dev_ctx = kmalloc(sizeof *dev_ctx, GFP_KERNEL);
+ dev_ctx = kmalloc(sizeof(*dev_ctx), GFP_KERNEL);
if (!dev_ctx)
return;
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 09b9bc17bce9..69ea6af46fd7 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -925,10 +925,10 @@ static int mlx4_slave_cap(struct mlx4_dev *dev)
mlx4_replace_zero_macs(dev);
dev->caps.qp0_qkey = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
- dev->caps.qp0_tunnel = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
- dev->caps.qp0_proxy = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
- dev->caps.qp1_tunnel = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
- dev->caps.qp1_proxy = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
+ dev->caps.qp0_tunnel = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
+ dev->caps.qp0_proxy = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
+ dev->caps.qp1_tunnel = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
+ dev->caps.qp1_proxy = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
if (!dev->caps.qp0_tunnel || !dev->caps.qp0_proxy ||
!dev->caps.qp1_tunnel || !dev->caps.qp1_proxy ||
@@ -2399,7 +2399,7 @@ static int mlx4_init_hca(struct mlx4_dev *dev)
dev->caps.rx_checksum_flags_port[2] = params.rx_csum_flags_port_2;
}
priv->eq_table.inta_pin = adapter.inta_pin;
- memcpy(dev->board_id, adapter.board_id, sizeof dev->board_id);
+ memcpy(dev->board_id, adapter.board_id, sizeof(dev->board_id));
return 0;
@@ -2869,7 +2869,7 @@ static void mlx4_enable_msi_x(struct mlx4_dev *dev)
dev->caps.num_eqs - dev->caps.reserved_eqs,
MAX_MSIX);
- entries = kcalloc(nreq, sizeof *entries, GFP_KERNEL);
+ entries = kcalloc(nreq, sizeof(*entries), GFP_KERNEL);
if (!entries)
goto no_msi;
diff --git a/drivers/net/ethernet/mellanox/mlx4/mcg.c b/drivers/net/ethernet/mellanox/mlx4/mcg.c
index 0710b3677464..4c5306dbcf11 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mcg.c
+++ b/drivers/net/ethernet/mellanox/mlx4/mcg.c
@@ -162,7 +162,7 @@ static int new_steering_entry(struct mlx4_dev *dev, u8 port,
return -EINVAL;
s_steer = &mlx4_priv(dev)->steer[port - 1];
- new_entry = kzalloc(sizeof *new_entry, GFP_KERNEL);
+ new_entry = kzalloc(sizeof(*new_entry), GFP_KERNEL);
if (!new_entry)
return -ENOMEM;
@@ -175,7 +175,7 @@ static int new_steering_entry(struct mlx4_dev *dev, u8 port,
*/
pqp = get_promisc_qp(dev, port, steer, qpn);
if (pqp) {
- dqp = kmalloc(sizeof *dqp, GFP_KERNEL);
+ dqp = kmalloc(sizeof(*dqp), GFP_KERNEL);
if (!dqp) {
err = -ENOMEM;
goto out_alloc;
@@ -274,7 +274,7 @@ static int existing_steering_entry(struct mlx4_dev *dev, u8 port,
}
/* add the qp as a duplicate on this index */
- dqp = kmalloc(sizeof *dqp, GFP_KERNEL);
+ dqp = kmalloc(sizeof(*dqp), GFP_KERNEL);
if (!dqp)
return -ENOMEM;
dqp->qpn = qpn;
@@ -443,7 +443,7 @@ static int add_promisc_qp(struct mlx4_dev *dev, u8 port,
goto out_mutex;
}
- pqp = kmalloc(sizeof *pqp, GFP_KERNEL);
+ pqp = kmalloc(sizeof(*pqp), GFP_KERNEL);
if (!pqp) {
err = -ENOMEM;
goto out_mutex;
@@ -514,7 +514,7 @@ static int add_promisc_qp(struct mlx4_dev *dev, u8 port,
/* add the new qpn to list of promisc qps */
list_add_tail(&pqp->list, &s_steer->promisc_qps[steer]);
/* now need to add all the promisc qps to default entry */
- memset(mgm, 0, sizeof *mgm);
+ memset(mgm, 0, sizeof(*mgm));
members_count = 0;
list_for_each_entry(dqp, &s_steer->promisc_qps[steer], list) {
if (members_count == dev->caps.num_qp_per_mgm) {
@@ -1144,7 +1144,7 @@ int mlx4_qp_attach_common(struct mlx4_dev *dev, struct mlx4_qp *qp, u8 gid[16],
index += dev->caps.num_mgms;
new_entry = 1;
- memset(mgm, 0, sizeof *mgm);
+ memset(mgm, 0, sizeof(*mgm));
memcpy(mgm->gid, gid, 16);
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/mr.c b/drivers/net/ethernet/mellanox/mlx4/mr.c
index 24282cd017d3..c7c0764991c9 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mr.c
+++ b/drivers/net/ethernet/mellanox/mlx4/mr.c
@@ -106,9 +106,9 @@ static int mlx4_buddy_init(struct mlx4_buddy *buddy, int max_order)
buddy->max_order = max_order;
spin_lock_init(&buddy->lock);
- buddy->bits = kcalloc(buddy->max_order + 1, sizeof (long *),
+ buddy->bits = kcalloc(buddy->max_order + 1, sizeof(long *),
GFP_KERNEL);
- buddy->num_free = kcalloc((buddy->max_order + 1), sizeof *buddy->num_free,
+ buddy->num_free = kcalloc(buddy->max_order + 1, sizeof(*buddy->num_free),
GFP_KERNEL);
if (!buddy->bits || !buddy->num_free)
goto err_out;
@@ -703,13 +703,13 @@ static int mlx4_write_mtt_chunk(struct mlx4_dev *dev, struct mlx4_mtt *mtt,
return -ENOMEM;
dma_sync_single_for_cpu(&dev->persist->pdev->dev, dma_handle,
- npages * sizeof (u64), DMA_TO_DEVICE);
+ npages * sizeof(u64), DMA_TO_DEVICE);
for (i = 0; i < npages; ++i)
mtts[i] = cpu_to_be64(page_list[i] | MLX4_MTT_FLAG_PRESENT);
dma_sync_single_for_device(&dev->persist->pdev->dev, dma_handle,
- npages * sizeof (u64), DMA_TO_DEVICE);
+ npages * sizeof(u64), DMA_TO_DEVICE);
return 0;
}
@@ -1052,7 +1052,7 @@ int mlx4_fmr_alloc(struct mlx4_dev *dev, u32 pd, u32 access, int max_pages,
return -EINVAL;
/* All MTTs must fit in the same page */
- if (max_pages * sizeof *fmr->mtts > PAGE_SIZE)
+ if (max_pages * sizeof(*fmr->mtts) > PAGE_SIZE)
return -EINVAL;
fmr->page_shift = page_shift;
diff --git a/drivers/net/ethernet/mellanox/mlx4/qp.c b/drivers/net/ethernet/mellanox/mlx4/qp.c
index 26747212526b..2b067763a6bc 100644
--- a/drivers/net/ethernet/mellanox/mlx4/qp.c
+++ b/drivers/net/ethernet/mellanox/mlx4/qp.c
@@ -174,7 +174,7 @@ static int __mlx4_qp_modify(struct mlx4_dev *dev, struct mlx4_mtt *mtt,
cpu_to_be16(mlx4_qp_roce_entropy(dev, qp->qpn));
*(__be32 *) mailbox->buf = cpu_to_be32(optpar);
- memcpy(mailbox->buf + 8, context, sizeof *context);
+ memcpy(mailbox->buf + 8, context, sizeof(*context));
((struct mlx4_qp_context *) (mailbox->buf + 8))->local_qpn =
cpu_to_be32(qp->qpn);
@@ -844,10 +844,10 @@ int mlx4_init_qp_table(struct mlx4_dev *dev)
/* In mfunc, calculate proxy and tunnel qp offsets for the PF here,
* since the PF does not call mlx4_slave_caps */
- dev->caps.qp0_tunnel = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
- dev->caps.qp0_proxy = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
- dev->caps.qp1_tunnel = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
- dev->caps.qp1_proxy = kcalloc(dev->caps.num_ports, sizeof (u32), GFP_KERNEL);
+ dev->caps.qp0_tunnel = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
+ dev->caps.qp0_proxy = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
+ dev->caps.qp1_tunnel = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
+ dev->caps.qp1_proxy = kcalloc(dev->caps.num_ports, sizeof(u32), GFP_KERNEL);
if (!dev->caps.qp0_tunnel || !dev->caps.qp0_proxy ||
!dev->caps.qp1_tunnel || !dev->caps.qp1_proxy) {
@@ -907,7 +907,7 @@ int mlx4_qp_query(struct mlx4_dev *dev, struct mlx4_qp *qp,
MLX4_CMD_QUERY_QP, MLX4_CMD_TIME_CLASS_A,
MLX4_CMD_WRAPPED);
if (!err)
- memcpy(context, mailbox->buf + 8, sizeof *context);
+ memcpy(context, mailbox->buf + 8, sizeof(*context));
mlx4_free_cmd_mailbox(dev, mailbox);
return err;
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index 215e21c3dc8a..fabb53379727 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -1040,7 +1040,7 @@ static struct res_common *alloc_qp_tr(int id)
{
struct res_qp *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1058,7 +1058,7 @@ static struct res_common *alloc_mtt_tr(int id, int order)
{
struct res_mtt *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1074,7 +1074,7 @@ static struct res_common *alloc_mpt_tr(int id, int key)
{
struct res_mpt *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1089,7 +1089,7 @@ static struct res_common *alloc_eq_tr(int id)
{
struct res_eq *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1103,7 +1103,7 @@ static struct res_common *alloc_cq_tr(int id)
{
struct res_cq *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1118,7 +1118,7 @@ static struct res_common *alloc_srq_tr(int id)
{
struct res_srq *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1133,7 +1133,7 @@ static struct res_common *alloc_counter_tr(int id, int port)
{
struct res_counter *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1148,7 +1148,7 @@ static struct res_common *alloc_xrcdn_tr(int id)
{
struct res_xrcdn *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1162,7 +1162,7 @@ static struct res_common *alloc_fs_rule_tr(u64 id, int qpn)
{
struct res_fs_rule *ret;
- ret = kzalloc(sizeof *ret, GFP_KERNEL);
+ ret = kzalloc(sizeof(*ret), GFP_KERNEL);
if (!ret)
return NULL;
@@ -1274,7 +1274,7 @@ static int add_res_range(struct mlx4_dev *dev, int slave, u64 base, int count,
struct mlx4_resource_tracker *tracker = &priv->mfunc.master.res_tracker;
struct rb_root *root = &tracker->res_tree[type];
- res_arr = kzalloc(count * sizeof *res_arr, GFP_KERNEL);
+ res_arr = kcalloc(count, sizeof(*res_arr), GFP_KERNEL);
if (!res_arr)
return -ENOMEM;
@@ -2027,7 +2027,7 @@ static int mac_add_to_slave(struct mlx4_dev *dev, int slave, u64 mac, int port,
if (mlx4_grant_resource(dev, slave, RES_MAC, 1, port))
return -EINVAL;
- res = kzalloc(sizeof *res, GFP_KERNEL);
+ res = kzalloc(sizeof(*res), GFP_KERNEL);
if (!res) {
mlx4_release_resource(dev, slave, RES_MAC, 1, port);
return -ENOMEM;
@@ -4020,7 +4020,7 @@ static int add_mcg_res(struct mlx4_dev *dev, int slave, struct res_qp *rqp,
struct res_gid *res;
int err;
- res = kzalloc(sizeof *res, GFP_KERNEL);
+ res = kzalloc(sizeof(*res), GFP_KERNEL);
if (!res)
return -ENOMEM;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next 4/4] mlx4: sizeof style usage
From: Leon Romanovsky @ 2017-08-15 18:13 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Stephen Hemminger, mst, linux-rdma, netdev, virtualization,
mlindner
In-Reply-To: <20170815172919.26153-5-sthemmin@microsoft.com>
[-- Attachment #1.1: Type: text/plain, Size: 1403 bytes --]
On Tue, Aug 15, 2017 at 10:29:19AM -0700, Stephen Hemminger wrote:
> The kernel coding style is to treat sizeof as a function
> (ie. with parenthesis) not as an operator.
>
> Also use kcalloc and kmalloc_array
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> drivers/net/ethernet/mellanox/mlx4/alloc.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/cmd.c | 4 ++--
> drivers/net/ethernet/mellanox/mlx4/en_resources.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/eq.c | 20 +++++++++---------
> drivers/net/ethernet/mellanox/mlx4/fw.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/icm.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/icm.h | 4 ++--
> drivers/net/ethernet/mellanox/mlx4/intf.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/main.c | 12 +++++------
> drivers/net/ethernet/mellanox/mlx4/mcg.c | 12 +++++------
> drivers/net/ethernet/mellanox/mlx4/mr.c | 10 ++++-----
> drivers/net/ethernet/mellanox/mlx4/qp.c | 12 +++++------
> .../net/ethernet/mellanox/mlx4/resource_tracker.c | 24 +++++++++++-----------
> 15 files changed, 56 insertions(+), 56 deletions(-)
>
Thanks,
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net-next 0/4] various sizeof cleanups
From: Michael S. Tsirkin @ 2017-08-15 19:47 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Stephen Hemminger, linux-rdma, netdev, virtualization, mlindner
In-Reply-To: <20170815172919.26153-1-sthemmin@microsoft.com>
On Tue, Aug 15, 2017 at 10:29:15AM -0700, Stephen Hemminger wrote:
> Noticed some places that were using sizeof as an operator.
> This is legal C but is not the convention used in the kernel.
>
> Stephen Hemminger (4):
> tun/tap: use paren's with sizeof
> virtio: put paren around sizeof
> skge: add paren around sizeof arg
> mlx4: sizeof style usage
for tun and virtio:
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> drivers/net/ethernet/marvell/skge.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/alloc.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/cmd.c | 4 ++--
> drivers/net/ethernet/mellanox/mlx4/en_resources.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/eq.c | 20 +++++++++---------
> drivers/net/ethernet/mellanox/mlx4/fw.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/icm.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/icm.h | 4 ++--
> drivers/net/ethernet/mellanox/mlx4/intf.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/main.c | 12 +++++------
> drivers/net/ethernet/mellanox/mlx4/mcg.c | 12 +++++------
> drivers/net/ethernet/mellanox/mlx4/mr.c | 10 ++++-----
> drivers/net/ethernet/mellanox/mlx4/qp.c | 12 +++++------
> .../net/ethernet/mellanox/mlx4/resource_tracker.c | 24 +++++++++++-----------
> drivers/net/tap.c | 2 +-
> drivers/net/tun.c | 2 +-
> drivers/net/virtio_net.c | 2 +-
> 19 files changed, 60 insertions(+), 60 deletions(-)
>
> --
> 2.11.0
^ permalink raw reply
* Re: [virtio-dev] [RFC] virtio-iommu version 0.4
From: Adam Tao @ 2017-08-16 4:08 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: virtio-dev, lorenzo.pieralisi, kvm, mst, marc.zyngier,
will.deacon, virtualization, eric.auger, iommu, robin.murphy,
eric.auger.pro
In-Reply-To: <20170804181927.12148-1-jean-philippe.brucker@arm.com>
On Fri, Aug 04, 2017 at 07:19:25PM +0100, Jean-Philippe Brucker wrote:
> This is the continuation of my proposal for virtio-iommu, the para-
> virtualized IOMMU. Here is a summary of the changes since last time [1]:
>
> * The virtio-iommu document now resembles an actual specification. It is
> split into a formal description of the virtio device, and implementation
> notes. Please find sources and binaries at [2].
>
> * Added a probe request to describe to the guest different properties that
> do not fit in firmware or in the virtio config space. This is a
> necessary stepping stone for extending the virtio-iommu.
>
> * There is a working Qemu prototype [3], thanks to Eric Auger and Bharat
> Bhushan.
Hi, Brucker
I read the related spec for virtio IOMMU,
I am wondering if we support both the virtual and physical devices in
the guest to use the virtio IOMMU, how can we config the related address
translation for the different type of devices.
e.g.
1. for Virtio devs(e.g. virtio-net), we can change the memmap table used
by the vhost device.
2. for physical devices we can directly config the IOMMU/SMMU on the
host.
So do you know are there any RFCs for the back-end implementation for the virtio-IOMMU
thanks
Adam
>
> You can find the Linux driver and kvmtool device at [4] and [5]. I
> plan to rework driver and kvmtool device slightly before sending the
> patches.
>
> To understand the virtio-iommu, I advise to first read introduction and
> motivation, then skim through implementation notes and finally look at the
> device specification.
>
> I wasn't sure how to organize the review. For those who prefer to comment
> inline, I attached v0.4 of device-operations.tex and topology.tex+MSI.tex
> to this thread. They are the biggest chunks of the document. But LaTeX
> isn't very pleasant to read, so you can simply send a list of comments in
> relation to section numbers and a few words of context, we'll manage.
>
> ---
> Version numbers 0.1-0.4 are arbitrary. I'm hoping they allow to compare
> more easily differences since the RFC (see [6]), but haven't been made
> public so far. This is the first public posting since initial proposal
> [1], and the following describes all changes.
>
> ## v0.1 ##
>
> Content is the same as the RFC, but formatted to LaTeX. 'make' generates
> one PDF and one HTML document.
>
> ## v0.2 ##
>
> Add introductions, improve topology example and firmware description based
> on feedback and a number of useful discussions.
>
> ## v0.3 ##
>
> Add normative sections (MUST, SHOULD, etc). Clarify some things, tighten
> the device and driver behaviour. Unmap semantics are consolidated; they
> are now closer to VFIO Type1 v2 semantics.
>
> ## v0.4 ##
>
> Introduce PROBE requests. They provide per-endpoint information to the
> driver that couldn't be described otherwise.
>
> For the moment, they allow to handle MSIs on x86 virtual platforms (see
> 3.2). To do that we communicate reserved IOVA regions, that will also be
> useful for describing regions that cannot be mapped for a given endpoint,
> for instance addresses that correspond to a PCI bridge window.
>
> Introducing such a large framework for this tiny feature may seem
> overkill, but it is needed for future extensions of the virtio-iommu and I
> believe it really is worth the effort.
>
> ## Future ##
>
> Other extensions are in preparation. I won't detail them here because v0.4
> already is a lot to digest, but in short, building on top of PROBE:
>
> * First, since the IOMMU is paravirtualized, the device can expose some
> properties of the physical topology to the guest, and let it allocate
> resources more efficiently. For example, when the virtio-iommu manages
> both physical and emulated endpoints, with different underlying IOMMUs,
> we now have a way to describe multiple page and block granularities,
> instead of forcing the guest to use the most restricted one for all
> endpoints. This will most likely be in v0.5.
>
> * Then on top of that, a major improvement will describe hardware
> acceleration features available to the guest. There is what I call "Page
> Table Handover" (or simply, from the host POV, "Nested"), the ability
> for the guest to manipulate its own page tables instead of sending
> MAP/UNMAP requests to the host. This, along with IO Page Fault
> reporting, will also permit SVM virtualization on different platforms.
>
> Thanks,
> Jean
>
> [1] http://www.spinics.net/lists/kvm/msg147990.html
> [2] git://linux-arm.org/virtio-iommu.git branch viommu/v0.4
> http://www.linux-arm.org/git?p=virtio-iommu.git;a=blob;f=dist/v0.4/virtio-iommu-v0.4.pdf
> I reiterate the disclaimers: don't use this document as a reference,
> it's a draft. It's also not an OASIS document yet. It may be riddled
> with mistakes. As this is a working draft, it is unstable and I do not
> guarantee backward compatibility of future versions.
> [3] https://lists.gnu.org/archive/html/qemu-arm/2017-08/msg00004.html
> [4] git://linux-arm.org/linux-jpb.git virtio-iommu/v0.4
> Warning: UAPI headers have changed! They didn't follow the spec,
> please update. (Use branch v0.1, that has the old headers, for the
> Qemu prototype [3])
> [5] git://linux-arm.org/kvmtool-jpb.git virtio-iommu/v0.4
> Warning: command-line has changed! Use --viommu vfio[,opts] and
> --viommu virtio[,opts] to instantiate a device.
> [6] http://www.linux-arm.org/git?p=virtio-iommu.git;a=tree;f=dist/diffs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply
* Re: [virtio-dev] [PATCH v13 0/5] Virtio-balloon Enhancement
From: Adam Tao @ 2017-08-16 5:57 UTC (permalink / raw)
To: Wei Wang
Cc: aarcange, virtio-dev, kvm, mst, amit.shah, liliang.opensource,
mawilcox, linux-kernel, mhocko, linux-mm, yang.zhang.wz, quan.xu,
cornelia.huck, pbonzini, akpm, virtualization, mgorman
In-Reply-To: <1501742299-4369-1-git-send-email-wei.w.wang@intel.com>
On Thu, Aug 03, 2017 at 02:38:14PM +0800, Wei Wang wrote:
> This patch series enhances the existing virtio-balloon with the following
> new features:
> 1) fast ballooning: transfer ballooned pages between the guest and host in
> chunks using sgs, instead of one by one; and
> 2) free_page_vq: a new virtqueue to report guest free pages to the host.
>
Hi wei,
The reason we add the new vq for the migration feature is based on
what(original design based on inflate and deflate vq)?
I am wondering if we add new feature in the future do we still need to add new type
of vq?
Do we need to add one command queue for the common purpose(including
different type of requests except the in/deflate ones)?
Thanks
Adam
> The second feature can be used to accelerate live migration of VMs. Here
> are some details:
>
> Live migration needs to transfer the VM's memory from the source machine
> to the destination round by round. For the 1st round, all the VM's memory
> is transferred. From the 2nd round, only the pieces of memory that were
> written by the guest (after the 1st round) are transferred. One method
> that is popularly used by the hypervisor to track which part of memory is
> written is to write-protect all the guest memory.
>
> The second feature enables the optimization of the 1st round memory
> transfer - the hypervisor can skip the transfer of guest free pages in the
> 1st round. It is not concerned that the memory pages are used after they
> are given to the hypervisor as a hint of the free pages, because they will
> be tracked by the hypervisor and transferred in the next round if they are
> used and written.
>
> Change Log:
> v12->v13:
> 1) mm: use a callback function to handle the the free page blocks from the
> report function. This avoids exposing the zone internal to a kernel module.
> 2) virtio-balloon: send balloon pages or a free page block using a single sg
> each time. This has the benefits of simpler implementation with no new APIs.
> 3) virtio-balloon: the free_page_vq is used to report free pages only (no
> multiple usages interleaving)
> 4) virtio-balloon: Balloon pages and free page blocks are sent via input sgs,
> and the completion signal to the host is sent via an output sg.
>
> v11->v12:
> 1) xbitmap: use the xbitmap from Matthew Wilcox to record ballooned pages.
> 2) virtio-ring: enable the driver to build up a desc chain using vring desc.
> 3) virtio-ring: Add locking to the existing START_USE() and END_USE() macro
> to lock/unlock the vq when a vq operation starts/ends.
> 4) virtio-ring: add virtqueue_kick_sync() and virtqueue_kick_async()
> 5) virtio-balloon: describe chunks of ballooned pages and free pages blocks
> directly using one or more chains of desc from the vq.
>
> v10->v11:
> 1) virtio_balloon: use vring_desc to describe a chunk;
> 2) virtio_ring: support to add an indirect desc table to virtqueue;
> 3) virtio_balloon: use cmdq to report guest memory statistics.
>
> v9->v10:
> 1) mm: put report_unused_page_block() under CONFIG_VIRTIO_BALLOON;
> 2) virtio-balloon: add virtballoon_validate();
> 3) virtio-balloon: msg format change;
> 4) virtio-balloon: move miscq handling to a task on system_freezable_wq;
> 5) virtio-balloon: code cleanup.
>
> v8->v9:
> 1) Split the two new features, VIRTIO_BALLOON_F_BALLOON_CHUNKS and
> VIRTIO_BALLOON_F_MISC_VQ, which were mixed together in the previous
> implementation;
> 2) Simpler function to get the free page block.
>
> v7->v8:
> 1) Use only one chunk format, instead of two.
> 2) re-write the virtio-balloon implementation patch.
> 3) commit changes
> 4) patch re-org
>
> Matthew Wilcox (1):
> Introduce xbitmap
>
> Wei Wang (4):
> xbitmap: add xb_find_next_bit() and xb_zero()
> virtio-balloon: VIRTIO_BALLOON_F_SG
> mm: support reporting free page blocks
> virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
>
> drivers/virtio/virtio_balloon.c | 302 +++++++++++++++++++++++++++++++-----
> include/linux/mm.h | 7 +
> include/linux/mmzone.h | 5 +
> include/linux/radix-tree.h | 2 +
> include/linux/xbitmap.h | 53 +++++++
> include/uapi/linux/virtio_balloon.h | 2 +
> lib/radix-tree.c | 167 +++++++++++++++++++-
> mm/page_alloc.c | 109 +++++++++++++
> 8 files changed, 609 insertions(+), 38 deletions(-)
> create mode 100644 include/linux/xbitmap.h
>
> --
> 2.7.4
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply
* Re: [virtio-dev] [PATCH v13 0/5] Virtio-balloon Enhancement
From: Wei Wang @ 2017-08-16 9:33 UTC (permalink / raw)
To: Adam Tao
Cc: aarcange, virtio-dev, kvm, mst, amit.shah, liliang.opensource,
mawilcox, linux-kernel, mhocko, linux-mm, yang.zhang.wz, quan.xu,
cornelia.huck, pbonzini, akpm, virtualization, mgorman
In-Reply-To: <20170816055704.GB21088@shay3t003839711.china.huawei.com>
On 08/16/2017 01:57 PM, Adam Tao wrote:
> On Thu, Aug 03, 2017 at 02:38:14PM +0800, Wei Wang wrote:
>> This patch series enhances the existing virtio-balloon with the following
>> new features:
>> 1) fast ballooning: transfer ballooned pages between the guest and host in
>> chunks using sgs, instead of one by one; and
>> 2) free_page_vq: a new virtqueue to report guest free pages to the host.
>>
> Hi wei,
> The reason we add the new vq for the migration feature is based on
> what(original design based on inflate and deflate vq)?
> I am wondering if we add new feature in the future do we still need to add new type
> of vq?
> Do we need to add one command queue for the common purpose(including
> different type of requests except the in/deflate ones)?
> Thanks
> Adam
Hi Adam,
The the free_page_vq is added to report free pages to the hypervisor.
Neither inflate nor deflate vq was for this purpose.
Based on the current implementation, a vq dedicated to one usage (i.e.
report
free pages) is better, since mixing with other usages, e.g. a command vq to
handle multiple commands at the same time, would have some issues (e.g. one
being delayed by another due to some resource control), and it also
results in
more complex interfaces between the driver and device.
For future usages which are still unknown at present, I think we can discuss
them case by case in the future.
Best,
Wei
^ permalink raw reply
* Re: [PATCH net-next 0/4] various sizeof cleanups
From: David Miller @ 2017-08-16 18:02 UTC (permalink / raw)
To: stephen; +Cc: sthemmin, mst, linux-rdma, netdev, virtualization, mlindner
In-Reply-To: <20170815172919.26153-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 15 Aug 2017 10:29:15 -0700
> Noticed some places that were using sizeof as an operator.
> This is legal C but is not the convention used in the kernel.
Series applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox