All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: James Hogan <james@albanarts.com>
Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fbdev@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Dave Airlie <airlied@redhat.com>,
	Marcin Slusarz <marcin.slusarz@gmail.com>,
	Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
	Denys Vlasenko <vda.linux@googlemail.com>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	James Simmons <jsimmons@infradead.org>
Subject: Re: [PATCH] fbmem: Fix fb_read, fb_write unaligned accesses.
Date: Tue, 21 Sep 2010 23:19:50 +0000	[thread overview]
Message-ID: <20100921161950.b7f45273.akpm@linux-foundation.org> (raw)
In-Reply-To: <201009180123.48303.james@albanarts.com>

On Sat, 18 Sep 2010 01:23:47 +0100
James Hogan <james@albanarts.com> wrote:

> Apologies for corrupted patch. I'll try again.
> Comments? I'd also appreciate if somebody familiar with sbus on sparc
> could check this patch is sane since I know virtually nothing about sbus
> and am not in a position to compile for sparc, let alone test on it:
> 
> fb_{read,write} access the framebuffer using lots of fb_{read,write}l's
> but don't check that the file position is aligned which can cause
> problems on some architectures which do not support unaligned accesses.

What are these "problems"?

I'd have thought they would be fairly fatal, in which case this is a
high-priority patch.  But I'd also have thought that the problems would
have been noted before now.

So I assume that you're doing something which nobody has done before.

Confused.  Help?

> Since the operations are essentially memcpy_{from,to}io, new
> fb_memcpy_{from,to}fb macros have been defined and these are used
> instead.
> 
> For Sparc, fb_{read,write} macros use sbus_{read,write}, so this defines
> new sbus_memcpy_{from,to}io functions the same as memcpy_{from,to}io but
> using sbus_{read,write}b instead of {read,write}b.

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: James Hogan <james@albanarts.com>
Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fbdev@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Dave Airlie <airlied@redhat.com>,
	Marcin Slusarz <marcin.slusarz@gmail.com>,
	Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
	Denys Vlasenko <vda.linux@googlemail.com>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	James Simmons <jsimmons@infradead.org>
Subject: Re: [PATCH] fbmem: Fix fb_read, fb_write unaligned accesses.
Date: Tue, 21 Sep 2010 16:19:50 -0700	[thread overview]
Message-ID: <20100921161950.b7f45273.akpm@linux-foundation.org> (raw)
In-Reply-To: <201009180123.48303.james@albanarts.com>

On Sat, 18 Sep 2010 01:23:47 +0100
James Hogan <james@albanarts.com> wrote:

> Apologies for corrupted patch. I'll try again.
> Comments? I'd also appreciate if somebody familiar with sbus on sparc
> could check this patch is sane since I know virtually nothing about sbus
> and am not in a position to compile for sparc, let alone test on it:
> 
> fb_{read,write} access the framebuffer using lots of fb_{read,write}l's
> but don't check that the file position is aligned which can cause
> problems on some architectures which do not support unaligned accesses.

What are these "problems"?

I'd have thought they would be fairly fatal, in which case this is a
high-priority patch.  But I'd also have thought that the problems would
have been noted before now.

So I assume that you're doing something which nobody has done before.

Confused.  Help?

> Since the operations are essentially memcpy_{from,to}io, new
> fb_memcpy_{from,to}fb macros have been defined and these are used
> instead.
> 
> For Sparc, fb_{read,write} macros use sbus_{read,write}, so this defines
> new sbus_memcpy_{from,to}io functions the same as memcpy_{from,to}io but
> using sbus_{read,write}b instead of {read,write}b.

  parent reply	other threads:[~2010-09-21 23:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-09 22:38 fb_write unaligned writes James Hogan
2010-09-17 18:11 ` Florian Tobias Schandinat
2010-09-17 23:57 ` [PATCH] fbmem: Fix fb_read, fb_write unaligned accesses James Hogan
2010-09-17 23:57   ` James Hogan
2010-09-18  0:15   ` David Miller
2010-09-18  0:15     ` David Miller
2010-09-18  0:23   ` James Hogan
2010-09-18  0:23     ` James Hogan
2010-09-18  3:17     ` David Miller
2010-09-18  3:17       ` David Miller
2010-09-20 19:27     ` Florian Tobias Schandinat
2010-09-20 19:27       ` Florian Tobias Schandinat
2010-09-21 23:19     ` Andrew Morton [this message]
2010-09-21 23:19       ` Andrew Morton
2010-09-22  0:00       ` James Hogan
2010-09-22  0:00         ` James Hogan
2010-09-18  0:11 ` fb_write unaligned writes James Hogan

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=20100921161950.b7f45273.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=FlorianSchandinat@gmx.de \
    --cc=airlied@redhat.com \
    --cc=davem@davemloft.net \
    --cc=james@albanarts.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jsimmons@infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcin.slusarz@gmail.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=vda.linux@googlemail.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.