From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] video via: fix iomem access
Date: Sat, 12 Mar 2011 15:34:07 +0000 [thread overview]
Message-ID: <4D7B926F.60400@gmx.de> (raw)
In-Reply-To: <20110303095901.2a283be0@nehalam>
Stephen Hemminger schrieb:
> This driver is not respecting the iomem memory space restrictions
> and does direct access. This works on x86 but is non-portable and
> should not be done. Converted memcpy() of 2 to readw.
> Last post increment of romptr was unnecessary since pointer never
> used after that.
>
> Found by sparse, compile tested only.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied (although it does not make a difference as viafb is x86 only). Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/via/lcd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- a/drivers/video/via/lcd.c 2011-03-03 09:09:10.552604209 -0800
> +++ b/drivers/video/via/lcd.c 2011-03-03 09:56:12.144398571 -0800
> @@ -1064,34 +1064,33 @@ static struct display_timing lcd_centeri
>
> bool viafb_lcd_get_mobile_state(bool *mobile)
> {
> - unsigned char *romptr, *tableptr;
> + unsigned char __iomem *romptr, *tableptr, *biosptr;
> u8 core_base;
> - unsigned char *biosptr;
> /* Rom address */
> - u32 romaddr = 0x000C0000;
> - u16 start_pattern = 0;
> + const u32 romaddr = 0x000C0000;
> + u16 start_pattern;
>
> biosptr = ioremap(romaddr, 0x10000);
> + start_pattern = readw(biosptr);
>
> - memcpy(&start_pattern, biosptr, 2);
> /* Compare pattern */
> if (start_pattern = 0xAA55) {
> /* Get the start of Table */
> /* 0x1B means BIOS offset position */
> romptr = biosptr + 0x1B;
> - tableptr = biosptr + *((u16 *) romptr);
> + tableptr = biosptr + readw(romptr);
>
> /* Get the start of biosver structure */
> /* 18 means BIOS version position. */
> romptr = tableptr + 18;
> - romptr = biosptr + *((u16 *) romptr);
> + romptr = biosptr + readw(romptr);
>
> /* The offset should be 44, but the
> actual image is less three char. */
> /* pRom += 44; */
> romptr += 41;
>
> - core_base = *romptr++;
> + core_base = readb(romptr);
>
> if (core_base & 0x8)
> *mobile = false;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" 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: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] video via: fix iomem access
Date: Sat, 12 Mar 2011 16:34:07 +0100 [thread overview]
Message-ID: <4D7B926F.60400@gmx.de> (raw)
In-Reply-To: <20110303095901.2a283be0@nehalam>
Stephen Hemminger schrieb:
> This driver is not respecting the iomem memory space restrictions
> and does direct access. This works on x86 but is non-portable and
> should not be done. Converted memcpy() of 2 to readw.
> Last post increment of romptr was unnecessary since pointer never
> used after that.
>
> Found by sparse, compile tested only.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied (although it does not make a difference as viafb is x86 only). Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/via/lcd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- a/drivers/video/via/lcd.c 2011-03-03 09:09:10.552604209 -0800
> +++ b/drivers/video/via/lcd.c 2011-03-03 09:56:12.144398571 -0800
> @@ -1064,34 +1064,33 @@ static struct display_timing lcd_centeri
>
> bool viafb_lcd_get_mobile_state(bool *mobile)
> {
> - unsigned char *romptr, *tableptr;
> + unsigned char __iomem *romptr, *tableptr, *biosptr;
> u8 core_base;
> - unsigned char *biosptr;
> /* Rom address */
> - u32 romaddr = 0x000C0000;
> - u16 start_pattern = 0;
> + const u32 romaddr = 0x000C0000;
> + u16 start_pattern;
>
> biosptr = ioremap(romaddr, 0x10000);
> + start_pattern = readw(biosptr);
>
> - memcpy(&start_pattern, biosptr, 2);
> /* Compare pattern */
> if (start_pattern == 0xAA55) {
> /* Get the start of Table */
> /* 0x1B means BIOS offset position */
> romptr = biosptr + 0x1B;
> - tableptr = biosptr + *((u16 *) romptr);
> + tableptr = biosptr + readw(romptr);
>
> /* Get the start of biosver structure */
> /* 18 means BIOS version position. */
> romptr = tableptr + 18;
> - romptr = biosptr + *((u16 *) romptr);
> + romptr = biosptr + readw(romptr);
>
> /* The offset should be 44, but the
> actual image is less three char. */
> /* pRom += 44; */
> romptr += 41;
>
> - core_base = *romptr++;
> + core_base = readb(romptr);
>
> if (core_base & 0x8)
> *mobile = false;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2011-03-12 15:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-03 17:59 [PATCH] video via: fix iomem access Stephen Hemminger
2011-03-03 17:59 ` Stephen Hemminger
2011-03-12 15:34 ` Florian Tobias Schandinat [this message]
2011-03-12 15:34 ` Florian Tobias Schandinat
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=4D7B926F.60400@gmx.de \
--to=florianschandinat@gmx.de \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shemminger@vyatta.com \
/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.