1/1 
|
Re: [oc] Re: PCI Linux driver
by b.badrignans on Oct 6, 2008 |
b.badrignans
Posts: 2 Joined: Aug 27, 2008 Last seen: Aug 31, 2012 |
||
|
Hi,
I re-up a very old post.
Just a question regarding the functions memcpy_fromio() and
memcpy_toio().
Does those functions generate write and read burst at the PCI level or
they are splitted into atomic read and write commands.
Thank you.
----- Original Message -----
From: "Miha Dolenc" miha at i...>
To: cores at o...>
pci at o...>
Date: Fri, 27 Jul 2001 08:22:52 +0200
Subject: [pci] Re: [oc] Re: PCI Linux driver
Andreas,
Thanks for your quick reply, comments and guidelines. This was
my first
Linux kernel programming attempt, so I'm not that current on kernel
versions, what functions are currently used and what's supposed to
be
deprecated. Maybe driver looks old, because I did it with help of
an old
book ;-) for kernels 2.1 and lower. I will repair it when needed.
If you are interested in helping out, you can join pci team mailing
list, so
we'll have experts on as many areas as possible. In that case, you
don't
have to worry about reading PCI spec, since a lot of us did it
already and
we could answer any question you might have ( at least we should be
able to
;-) ).
Have fun!
Miha Dolenc
----- Original Message -----
From: "Andreas Bombe" andreas.bombe at m...>
To: cores at o...>
Cc: pci at o...>
Sent: Friday, July 27, 2001 1:18 AM
Subject: [oc] Re: PCI Linux driver
> On Thu, Jul 26, 2001 at 02:35:37PM +0200, Miha Dolenc wrote:
> Hello everyone!
> > I have programmed one simple kernel interface for PCI device, which we
> will need, when PCI bridge project is finished. If anyone
here knows about
> Linux kernel and device drivers ( I don't ), I would ask
him/her to review
> sources and add, repair or comment on them.
> > I have knowledge in that area. Comes with dealing with the ieee1394
> subsystem in Linux, I guess :)
> > As far as I can see this is just a debug driver to test the PCI
> interface, so I can't make that much sense of it without
reading up on
> the PCI spec. I can comment on a few obvious errors.
> > The verify_area() call to verify user space pointers has not been
> necessary since Linux 2.2 since the get_user() and put_user()
macros are
> fault save, you just have to check their return values to see
if the
> access had an error.
> > Which leads to the second serious bug, you are not using them. You must
> never directly dereference user space pointers since you don't
know what
> awaits at the other end. Non-x86 architectures can have user
space in a
> different address space. Even on x86 verify_area() doesn't
allow you
> direct access, since it only checks permissions and the page
may well
> have to be paged in from disk first. See
include/asm/uacess.h.
>
> Same goes for PCI memory which you mustn't directly access either. It
> usually works on x86, but is not guaranteed to do so. You
have to use
> readX() and writeX() macros or the memcpy_fromio() and
memcpy_toio()
> functions. See include/asm/io.h.
> > Don't use the number tags in printk() directly, use the appropriate
> KERN_xxx defines from kernel.h. The you use is
KERN_ALERT and a bit
> over the top for debug messages. You can also leave them out
> altogether, they get a default level then. Not that big of a deal for a
> debug driver that won't be in everyday use around the world.
> > All of the above should be covered in the kernel hacking guide in
> Documentation/DocBook. You can generate them there with "make
psdocs",
> "make pdfdocs" or "make htmldocs" in the top directory, given
that you
> have the appropriate tools installed. You can also download
them
> already formatted somewhere, I think.
> > The build process is another problem. Since the subdirectory is not
> integrated into the kernel, this has to be done manually. It
is a
> requirement that modules are built with the same options and
include
> files as the kernel they will be used with. A separate build
may range
> from complete failure to subtle, hard to trace errors.
> > There is more than one way to solve this if you don't want to integrate
> it with the kernel directly. You can write a Makefile just as
if the
> driver were in fact integrated with the kernel, which allows
you to then
> do
> make -C $linux_src_dir modules SUBDIRS=$driver_src_dir
>
> I haven't tried that myself, but it is reported to work.
>
> --
> Andreas E. Bombe andreas.bombe at m...>
DSA key 0x04880A44
>
|
|||
1/1