From: Hans de Goede <hdegoede@redhat.com>
To: Alexander Kapshuk <alexander.kapshuk@gmail.com>
Cc: "Greg KH" <gregkh@linuxfoundation.org>,
michael.thayer@oracle.com, dri-devel@lists.freedesktop.org,
peda@axentia.se, "Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Cihangir Aktürk" <cakturk@gmail.com>,
"Sean Paul" <seanpaul@chromium.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] vboxvideo: Fix incorrect type in assignment sparse warning
Date: Sat, 6 Jan 2018 20:43:59 +0100 [thread overview]
Message-ID: <6f4de025-b126-9819-d789-ef611c9f82d9@redhat.com> (raw)
In-Reply-To: <CAJ1xhMUYpSo_5w_kxsgMB7rTikNHr-1=zxAXO2iFNcEy0=WXKA@mail.gmail.com>
HI,
On 06-01-18 20:30, Alexander Kapshuk wrote:
> On Sat, Jan 6, 2018 at 6:00 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>>
>> On 06-01-18 15:20, Alexander Kapshuk wrote:
>>>
>>> On Mon, Dec 25, 2017 at 04:42:59PM +0200, Alexander Kapshuk wrote:
>>>>
>>>> Sparse emitted the following warning:
>>>> ../drivers/staging/vboxvideo/vbox_fb.c:173:27: warning: incorrect type in
>>>> assignment (different address spaces)
>>>> ../drivers/staging/vboxvideo/vbox_fb.c:173:27: expected char [noderef]
>>>> <asn:2>*screen_base
>>>> ../drivers/staging/vboxvideo/vbox_fb.c:173:27: got void *virtual
>>>>
>>>> The vbox_bo buffer object kernel mapping is handled by a call
>>>> to ttm_bo_kmap() prior to the assignment of bo->kmap.virtual to
>>>> info->screen_base of type char __iomem*.
>>>> Casting bo->kmap.virtual to char __iomem* in this assignment fixes
>>>> the warning.
>>>>
>>>> vboxvideo: Fix address space of expression removal sparse warning
>>>>
>>>> Sparse emitted the following warning:
>>>> ../drivers/staging/vboxvideo/vbox_main.c:64:25: warning: cast removes
>>>> address space of expression
>>>>
>>>> vbox->vbva_buffers iomapping is handled by calling vbox_accel_init()
>>>> from vbox_hw_init().
>>>> __force attribute is used in assignment to vbva to fix the warning.
>>>>
>>>> Signed-off-by: Alexander Kapshuk <alexander.kapshuk@gmail.com>
>>>> ---
>>>> drivers/staging/vboxvideo/vbox_fb.c | 2 +-
>>>> drivers/staging/vboxvideo/vbox_main.c | 2 +-
>>>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/staging/vboxvideo/vbox_fb.c
>>>> b/drivers/staging/vboxvideo/vbox_fb.c
>>>> index 8aed248db6e2..43c39eca4ae1 100644
>>>> --- a/drivers/staging/vboxvideo/vbox_fb.c
>>>> +++ b/drivers/staging/vboxvideo/vbox_fb.c
>>>> @@ -170,7 +170,7 @@ static int vboxfb_create(struct drm_fb_helper
>>>> *helper,
>>>> drm_fb_helper_fill_var(info, &fbdev->helper, sizes->fb_width,
>>>> sizes->fb_height);
>>>>
>>>> - info->screen_base = bo->kmap.virtual;
>>>> + info->screen_base = (char __iomem *)bo->kmap.virtual;
>>>> info->screen_size = size;
>>>>
>>>> #ifdef CONFIG_DRM_KMS_FB_HELPER
>>
>>
>> This fix looks good to me.
>>
>>>> diff --git a/drivers/staging/vboxvideo/vbox_main.c
>>>> b/drivers/staging/vboxvideo/vbox_main.c
>>>> index 80bd039fa08e..973b3bcc04b1 100644
>>>> --- a/drivers/staging/vboxvideo/vbox_main.c
>>>> +++ b/drivers/staging/vboxvideo/vbox_main.c
>>>> @@ -61,7 +61,7 @@ void vbox_enable_accel(struct vbox_private *vbox)
>>>> if (vbox->vbva_info[i].vbva)
>>>> continue;
>>>>
>>>> - vbva = (void *)vbox->vbva_buffers + i *
>>>> VBVA_MIN_BUFFER_SIZE;
>>>> + vbva = (void __force *)vbox->vbva_buffers + i *
>>>> VBVA_MIN_BUFFER_SIZE;
>>>> if (!vbva_enable(&vbox->vbva_info[i],
>>>> vbox->guest_pool, vbva, i)) {
>>>> /* very old host or driver error. */
>>
>>
>> Hmm, isn't there a cleaner way to fix this ? Maybe make vbva_enable's
>> argument (and the local vbva variable) of type u8 __iomem * too ?
>>
>> Regards,
>>
>> Hans
>
> Hi Hans,
>
> Thanks for your prompt response.
>
> I had a good look at the vbva_enable() function's definition and to
> the best of my knowledge, changing vbva's type from 'struct
> vbva_buffer *' to 'u8 __iomem *' wouldn't work.
> vbva_enable() relies on vbva's type being a pointer to 'struct vbva_buffer':
> vbva's memory gets set to zero;
> some of vbva's members are initialised to particular values;
> vbva_ctx->vbva expects vbva to be a pointer to 'struct vbva_buffer' as well;
>
> Or am I misreading this?
No your not misreading this I did not check the function myself before
commenting myself, my bad.
> What are your thoughts on this?
Lets just move ahead with your original fix:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
next prev parent reply other threads:[~2018-01-06 19:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-06 19:30 Alexander Kapshuk
2018-01-06 19:43 ` Hans de Goede [this message]
2018-01-06 19:56 ` Alexander Kapshuk
2018-01-06 20:00 ` Hans de Goede
2018-01-06 20:02 ` Alexander Kapshuk
-- strict thread matches above, loose matches on Subject: below --
2017-12-25 14:42 Alexander Kapshuk
2018-01-06 14:20 ` Alexander Kapshuk
2018-01-06 16:00 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6f4de025-b126-9819-d789-ef611c9f82d9@redhat.com \
--to=hdegoede@redhat.com \
--cc=alexander.kapshuk@gmail.com \
--cc=cakturk@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.thayer@oracle.com \
--cc=peda@axentia.se \
--cc=seanpaul@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®