All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: Greg KH <greg@kroah.com>, Matthew Wilcox <matthew@wil.cx>,
	linux-pci@atrey.karlin.mff.cuni.cz,
	Linux Arch list <linux-arch@vger.kernel.org>
Subject: Re: RFC: rewrite Documentation/pci.txt v3
Date: Sat, 21 Oct 2006 14:55:29 +0200	[thread overview]
Message-ID: <200610211455.29837.ak@suse.de> (raw)
In-Reply-To: <20061021071436.GA29248@colo.lackof.org>

On Saturday 21 October 2006 09:14, Grant Grundler wrote:

I think you should add a note somewhere that the driver
should be prepared to initialize the device from any
state it put it in before. That is important for kexec
which tries to reinit the drivers after a crash.

And add a reference to kerneldoc somewhere too? There
is some PCI documentation in there (although it probably
could need some overall editing) 

> 3.2 Set the DMA mask size
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> [ If anything below doesn't make sense, it means you need to read
>   Documentation/DMA-API.txt. This section is just a reminder that
>   drivers need to indicate DMA capabilities of the device and is not
>   an authoritative source for DMA interfaces. ]
> 
> While all drivers should explictly indicate the DMA capability

I think it's ok to rely on the defaults if 0xffffffff is suitable

And perhaps one sentence what a consistent allocation is.

> 4  PCI device shutdown
> ~~~~~~~~~~~~~~~~~~~~~~
> When a PCI device driver is being unloaded, most of the follow 
> steps need to be performed:
> 
> 	disable the device from generating IRQs
> 	release the IRQ (free_irq())
> 	stop all DMA activity
> 	release DMA buffers (both streaming and consistent)
> 	unregister from other subsystems (e.g. scsi or netdev)
> 	Disable device from responding to MMIO/IO Port addresses
> 	release MMIO/IO Port resource(s)


put the pci_dev you got during explicit probing? For the normal
probing path the higher layer takes care of it I think.

 
>    If you don't have a struct pci_dev available, you can call
> pci_bus_(read|write)_config_(byte|word|dword) to access a given device
> and function on that bus.


This shouldn't happen in driver code right? I would remove it.

People who want to do such low level things can read the source
or kerneldoc.
 
>    If you access fields in the standard portion of the config header, please
> use symbolic names of locations and bits declared in <linux/pci.h>.
> 
>    If you need to access Extended PCI Capability registers, just call
> pci_find_capability() for the particular capability and it will find the
> corresponding register block for you.
> 
> 
> 6. Other interesting functions
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> pci_find_slot()			Find pci_dev corresponding to given bus and
> 				slot numbers.

Again i don't think that fits here.

> pci_set_power_state()		Set PCI Power Management state (0=D0 ... 3=D3)
> pci_find_capability()		Find specified capability in device's capability
> 				list.
> pci_module_init()		Inline helper function for ensuring correct
> 				pci_driver initialization and error handling.

Perhaps that should be described at the beginning?

> pci_resource_start()		Returns bus start address for a given PCI region
> pci_resource_end()		Returns bus end address for a given PCI region
> pci_resource_len()		Returns the byte length of a PCI region

And that in the section for resources?

-Andi

  reply	other threads:[~2006-10-21 12:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-21  7:14 RFC: rewrite Documentation/pci.txt v3 Grant Grundler
2006-10-21 12:55 ` Andi Kleen [this message]
2006-10-22 19:03   ` Grant Grundler
2006-10-22 21:44     ` Andi Kleen
2006-10-23  4:19       ` Grant Grundler
2006-10-23 19:20 ` Randy Dunlap
2006-10-24  7:33   ` Grant Grundler

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=200610211455.29837.ak@suse.de \
    --to=ak@suse.de \
    --cc=greg@kroah.com \
    --cc=grundler@parisc-linux.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=matthew@wil.cx \
    /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.