linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Tom Roberts <tjroberts@lucent.com>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Curious limitation in copy_from_user()
Date: Fri, 26 May 2000 15:30:13 -0500	[thread overview]
Message-ID: <392EDED5.33749798@lucent.com> (raw)


While porting Linux PPC to my hardware, I discovered a curious
limitation in copy_from_user() -- it cannot handle uncached memory.
I had mapped some main memory as uncached (using a BAT) because it
is a communication buffer to the host (this is an ISA peripheral
board with a PPC604 on it, and I'm trying to get Linux up on the 604;
this was inside my console driver).

Note that copy_to_user() does not have this limitation -- basically
copy_tofrom_user() is using dcbz-s to improve performance, so if the
destination is uncached you get an exception in the kernel. My first
workaround was simply to do a two-stage copy via a tmp[] buffer on
the stack. Then I did it right by writing a cache_flush() routine
and referencing the buffer via the usual (cached) kernel virtual
address. Of course I called cache_flush() before copy_to_user from
the host->board buffer, and called cache_flush() after copy_from_user
to the board->host buffer (because the host can only reference
physical memory, not the 604's cache).

	Note that in an SMP configuration you need to lock the buffer
	from other CPUs. In my case there is only one 604, and each
	buffer is dedicated to one-way traffic, so no locking is needed.

I still need the uncached address to reference the queue pointers,
but that is done using simple pointer dereferencing and is OK.


Tom Roberts	tjroberts@lucent.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

             reply	other threads:[~2000-05-26 20:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-26 20:30 Tom Roberts [this message]
2000-05-26 20:54 ` Curious limitation in copy_from_user() Dan Malek

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=392EDED5.33749798@lucent.com \
    --to=tjroberts@lucent.com \
    --cc=linuxppc-embedded@lists.linuxppc.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;
as well as URLs for NNTP newsgroup(s).