mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kumar Gala <galak@kernel.crashing.org>
To: Greg KH <greg@kroah.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: proper way to assign fixed PCI resources to a "hotplug" device
Date: Fri, 3 Mar 2006 17:28:50 -0600	[thread overview]
Message-ID: <B559AC6B-A9C9-425E-9288-EE7F9C99D8EB@kernel.crashing.org> (raw)
In-Reply-To: <20060303231807.GA28055@kroah.com>


On Mar 3, 2006, at 5:18 PM, Greg KH wrote:

> On Fri, Mar 03, 2006 at 04:39:52PM -0600, Kumar Gala wrote:
>> On Fri, 3 Mar 2006, Greg KH wrote:
>>
>>> On Fri, Mar 03, 2006 at 11:42:03AM -0600, Kumar Gala wrote:
>>>> I was wondering what the proper way to assign and setup a single  
>>>> PCI
>>>> device that comes into existence after the system has booted.  I  
>>>> have
>>>> an FPGA that we load from user space at which time it shows up  
>>>> on the
>>>> PCI bus.
>>>
>>> Idealy your BIOS would set up this information :)
>>
>> How would my BIOS know about a device that didn't exist when it  
>> booted.
>
> According to the PCI Hotplug spec, your BIOS needs to take that into
> consideration at boot time.  Yeah, it's a wierd thing, I agree, but is
> how this works for x86 systems.  The space and resources are reserved
> at boot time by the pci hotplug controller in anticipation of a device
> being added sometime in the future.
>
> Other arches do this differently (ppc64 has the stuff reserverd by the
> hypervisor), and then compat pci does it by just plain guessing.  It
> sounds like your situation is just like this one.

Well I reserve space for the device in my "BIOS".  However this is an  
embedded system so there isn't any calling out to the "BIOS" after  
linux has booted.  Is there some additional "work" that the x86  
systems do beyond ensure proper holes in the memory map exist for  
future devices to be placed into?

>> Or do you mean my BIOS would load the FPGA as well so it existed.
>
> No, see above.
>
>>>> It has a single BAR and I need to assign it at a fixed address  
>>>> in PCI
>>>> MMIO space.
>>>>
>>>> All of the exported interfaces I see have to do with having the
>>>> kernel assign the BAR automatically for me.
>>>>
>>>> the following looks like what I want to do:
>>>>
>>>> bus = pci_find_bus(0, 3);
>>>> dev = pci_scan_single_device(bus, devfn);
>>>> pci_bus_alloc_resource(...);
>>>> pci_update_resource(dev, dev->resource[0], 0);
>>>> pci_bus_add_devices(bus);
>>>>
>>>> However, pci_update_resource() is not an exported symbol, so I  
>>>> could
>>>> replace that code with the need updates to the actual BAR.
>>>>
>>>> Is this the "right" way to go about this or is there a better
>>>> mechanism to do this.
>>>
>>> Take a look at how the compat pci hotplug driver does this, you  
>>> probably
>>> just need to do the same as it.
>>
>> I'll take a look.  How about something like the following patch:
>
> Hm, I don't think this is needed, see how the cpcihp drivers do it in
> drivers/pci/hotplug/cpcihp*.c.  I think you can do things the same  
> way.

Ahh, looked at cpqphp_* and only found cpqhp_configure_device() of  
any use.  I'll take a look at cpcihp*.c

> But if not, I don't have any objection to adding this patch, you just
> need to prove you really need it :)

No problem, I asked because I'd prefer to use existing code to solve  
my problem.  Just need to understand how to get there.



- kumar

  reply	other threads:[~2006-03-03 23:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-03 17:42 Kumar Gala
2006-03-03 22:07 ` Greg KH
2006-03-03 22:39   ` Kumar Gala
2006-03-03 23:18     ` Greg KH
2006-03-03 23:28       ` Kumar Gala [this message]
2006-03-03 23:50         ` Scott Murray
2006-03-09 16:49       ` Kumar Gala
2006-03-03 23:18     ` Jeff Garzik
2006-03-08  2:00       ` Greg KH
2006-03-08  2:31         ` Tejun Heo
2006-03-08  5:27           ` Greg KH
2006-03-08 11:39             ` Ivan Kokshaysky
2006-03-08 16:40               ` thockin
2006-03-08 21:21                 ` Ivan Kokshaysky
2006-03-08 21:57                   ` thockin
2006-03-08 22:11                     ` Ivan Kokshaysky
2006-03-08 23:54                       ` thockin
2006-03-03 23:13   ` Kumar Gala
2006-03-03 23:27     ` Greg KH
2006-03-03 23:40       ` Scott Murray

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=B559AC6B-A9C9-425E-9288-EE7F9C99D8EB@kernel.crashing.org \
    --to=galak@kernel.crashing.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    /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

all inboxes | Powered by JetHome®