All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Noralf Trønnes" <noralf@tronnes.org>
To: Dan Carpenter <dan.carpenter@oracle.com>,
	Andrey Utkin <andrey.krieger.utkin@gmail.com>
Cc: OSUOSL Drivers <devel@driverdev.osuosl.org>,
	kernel-mentors@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"kernel-janitors@vger.kernel.org"
	<kernel-janitors@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] [RFC] drivers/staging/fbtft: fix sparse warnings
Date: Mon, 23 Feb 2015 19:27:49 +0000	[thread overview]
Message-ID: <54EB7F35.6040605@tronnes.org> (raw)
In-Reply-To: <20150223183544.GB5064@mwanda>


>>>> diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/staging/fbtft/fb_agm1264k-fl.c
>>>> index 9cc7d25..9114239 100644
>>>> --- a/drivers/staging/fbtft/fb_agm1264k-fl.c
>>>> +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
>>>> @@ -273,7 +273,7 @@ construct_line_bitmap(struct fbtft_par *par, u8 *dest, signed short *src,
>>>>
>>>>   static int write_vmem(struct fbtft_par *par, size_t offset, size_t len)
>>>>   {
>>>> -     u16 *vmem16 = (u16 *)par->info->screen_base;
>>>> +     u16 __iomem *vmem16 = (u16 __iomem *)par->info->screen_base;
>>> I haven't looked.  What is the type for ->screen_base and why can't it
>>> be declared as __iomem type?
>> http://lxr.free-electrons.com/source/include/linux/fb.h#L486
>> screen_base is component of struct fb_info, defined as "char __iomem *".
>> In drivers/staging/fbtft/fbtft-core.c, it looks to be actually set to
>> a pointer resulting from vzalloc().
> Hm, you're right.  Normally, it's an __iomem * but this time it's not
> an __iomem pointer.  Adding anotations to mark it as __iomem is wrong
> and adding calls to ioread16() is buggy.
>
> There are a couple ways to make these warnings go away.  The simplest
> is just to silence the warning with __force:
>
> 	u16 *vmem16 = (u16 __force *)par->info->screen_base;

This is how some fbdev drivers with vmalloc'ed memory does this:

video/fbdev/{metronomefb.c,hecubafb.c}:
unsigned char *buf = (unsigned char __force *)par->info->screen_base;
info->screen_base = (char __force __iomem *)videomemory;

drivers/video/fbdev/ssd1307fb.c (this one is quite new: 3.15):
u8 __iomem *dst; dst = (void __force *) (info->screen_base + p);
info->screen_base = (u8 __force __iomem *)vmem;

We have to use screen_base because of vmalloc'ed memory and deferred io
(fb_deferred_io_page).

> I'm not terribly familiar with this code.  I don't know that this is the
> cleanest approach.  We could also just leave the code alone for now and
> ignore the warning.

Yes, it's best to leave this alone for now.
I'm working on a proposal to provide better layering and minimal coupling
to fbdev. This will hopefully lead to screen_base eventually being used
only twice in the fbtft module and nowhere else.


Regards,
Noralf Trønnes

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: "Noralf Trønnes" <noralf@tronnes.org>
To: Dan Carpenter <dan.carpenter@oracle.com>,
	Andrey Utkin <andrey.krieger.utkin@gmail.com>
Cc: OSUOSL Drivers <devel@driverdev.osuosl.org>,
	kernel-mentors@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"kernel-janitors@vger.kernel.org"
	<kernel-janitors@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] [RFC] drivers/staging/fbtft: fix sparse warnings
Date: Mon, 23 Feb 2015 20:27:49 +0100	[thread overview]
Message-ID: <54EB7F35.6040605@tronnes.org> (raw)
In-Reply-To: <20150223183544.GB5064@mwanda>


>>>> diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/staging/fbtft/fb_agm1264k-fl.c
>>>> index 9cc7d25..9114239 100644
>>>> --- a/drivers/staging/fbtft/fb_agm1264k-fl.c
>>>> +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
>>>> @@ -273,7 +273,7 @@ construct_line_bitmap(struct fbtft_par *par, u8 *dest, signed short *src,
>>>>
>>>>   static int write_vmem(struct fbtft_par *par, size_t offset, size_t len)
>>>>   {
>>>> -     u16 *vmem16 = (u16 *)par->info->screen_base;
>>>> +     u16 __iomem *vmem16 = (u16 __iomem *)par->info->screen_base;
>>> I haven't looked.  What is the type for ->screen_base and why can't it
>>> be declared as __iomem type?
>> http://lxr.free-electrons.com/source/include/linux/fb.h#L486
>> screen_base is component of struct fb_info, defined as "char __iomem *".
>> In drivers/staging/fbtft/fbtft-core.c, it looks to be actually set to
>> a pointer resulting from vzalloc().
> Hm, you're right.  Normally, it's an __iomem * but this time it's not
> an __iomem pointer.  Adding anotations to mark it as __iomem is wrong
> and adding calls to ioread16() is buggy.
>
> There are a couple ways to make these warnings go away.  The simplest
> is just to silence the warning with __force:
>
> 	u16 *vmem16 = (u16 __force *)par->info->screen_base;

This is how some fbdev drivers with vmalloc'ed memory does this:

video/fbdev/{metronomefb.c,hecubafb.c}:
unsigned char *buf = (unsigned char __force *)par->info->screen_base;
info->screen_base = (char __force __iomem *)videomemory;

drivers/video/fbdev/ssd1307fb.c (this one is quite new: 3.15):
u8 __iomem *dst; dst = (void __force *) (info->screen_base + p);
info->screen_base = (u8 __force __iomem *)vmem;

We have to use screen_base because of vmalloc'ed memory and deferred io
(fb_deferred_io_page).

> I'm not terribly familiar with this code.  I don't know that this is the
> cleanest approach.  We could also just leave the code alone for now and
> ignore the warning.

Yes, it's best to leave this alone for now.
I'm working on a proposal to provide better layering and minimal coupling
to fbdev. This will hopefully lead to screen_base eventually being used
only twice in the fbtft module and nowhere else.


Regards,
Noralf Trønnes


  reply	other threads:[~2015-02-23 19:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-20 21:34 [PATCH] [RFC] drivers/staging/fbtft: fix sparse warnings Andrey Utkin
2015-02-20 21:34 ` Andrey Utkin
2015-02-21 18:58 ` Dan Carpenter
2015-02-21 18:58   ` Dan Carpenter
2015-02-23 17:06   ` Andrey Utkin
2015-02-23 17:06     ` Andrey Utkin
2015-02-23 18:35     ` Dan Carpenter
2015-02-23 18:35       ` Dan Carpenter
2015-02-23 19:27       ` Noralf Trønnes [this message]
2015-02-23 19:27         ` Noralf Trønnes
2015-02-23 20:38         ` Andrey Utkin
2015-02-23 20:38           ` Andrey Utkin

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=54EB7F35.6040605@tronnes.org \
    --to=noralf@tronnes.org \
    --cc=andrey.krieger.utkin@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=kernel-mentors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.