From: Trent Piepho <xyzzy@speakeasy.org>
To: Alex Chiang <achiang@hp.com>
Cc: "Darrick J. Wong" <djwong@us.ibm.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
linux-pci <linux-pci@vger.kernel.org>
Subject: Re: [PATCH] fakephp: Allocate PCI resources before adding the device
Date: Wed, 26 Nov 2008 17:44:35 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.58.0811261647410.24816@shell4.speakeasy.net> (raw)
In-Reply-To: <20081126225535.GA27936@ldl.fc.hp.com>
On Wed, 26 Nov 2008, Alex Chiang wrote:
> * Trent Piepho <xyzzy@speakeasy.org>:
> > > I doubt that, sysfs interfaces change all the time. I think only the
> > > syscall interface has any sort of stability guarantee.
> >
> > The ones meant to be used from userspace usually don't. At least that
> > doesn't seem to be what Linus is saying here http://lwn.net/Articles/172986/
> >
> > I've written software that uses an established interface, which has been
> > the same for years, and I see someone went and broke it, no warning. That
> > hardly seems reasonable.
>
> Which commit are you talking about?
>
> fe99740cac117f208707488c03f3789cf4904957
> PCI: construct one fakephp slot per PCI slot
This one. It will break any software that used the existing interface.
> Sorry for your frustration. Both patchsets went through multiple
> revisions, and had plenty of input from the various PCI
> developers. At the time, no one seemed to think that the proposed
> changes were unreasonable.
I wonder how many users of fakephp saw them? I can't monitor every patch
to linux kernel. I checked the lkml archive and didn't see any discussion
of the change to the fakephp interface. There was stuff about the other
patches, but nothing about that.
Is there a reason you had to change it? It breaks an existing interface.
It's clearly more inefficient and complicated to find a slot using it. The
exiting PCI device name, like "0000:01:00.0", has been used in the sysfs
interface and with tools like lspci since forever. Why should
/sys/bus/pci/slots use different names from /sys/bus/pci/devices for the
same device?
> > > > useless. How are you supposed to figure out which "fake-n" directory is
> > > > the right one to disable the device you want?
> > >
> > > cat /sys/bus/pci/slots/fake*/address
> >
> > Ahh, my kernel doesn't have an address attribute in the slot directories.
>
> That is bizarre. You are saying that you're getting slot entries
> without address files?
>
> Can you send the output of 'ls /sys/bus/pci/slots' and also:
>
> $ for i in /sys/bus/pci/slots ; do ls $i ; done
>
> What kernel are you on?
It's a 2.6.23 kernel, but I've back-ported the PCI code from 2.6.26 since
there were a number of important powerpc improvements that I needed. I
assure you there is no 'address' attribute in the directories in
bus/pci/slots. /sys/bus/pci/slots/* == /sys/bus/pci/devices/*, which is
quite nice.
> > Still, this is much more inefficient than the previous way. It also has a
> > race condition. After scanning each fake* device to find the one with the
> > correct address there is a window before the power attribute is written.
> > The fake* device might change in that time and one could write to the wrong
> > power attribute.
>
> There is no way for fakephp to hot-add devices. The only use case
> is to hot-remove devices.
Sure it's possible to hot-add devices. Look at the patch to fakephp just
previous to your first patch:
commit ca99eb8c2d56bdfff0161388b81e641f4e039b3f
Author: Trent Piepho <tpiepho@freescale.com>
Date: Mon Apr 7 16:04:16 2008 -0700
PCI: Hotplug: fakephp: Return success, not ENODEV, when bus rescan is triggered
What is the purpose of a bus rescan, if not to hot-add devices?
> Once fakephp is loaded, the fake* entry created in sysfs will not
> change.
>
> Maybe you're talking about something else. Some more context for
> what you're trying to do, please?
/ # lspci
00:00.0 PCI bridge: Freescale Semiconductor Inc MPC8572 PowerQUICC III PCIe Host Controller (rev 11)
01:00.0 Signal processing controller: Freescale Semiconductor Inc Aurora Nexus Trace Interface
/ # echo 0 > /sys/bus/pci/slots/`lspci -Dm -d 1957:fc00|cut -d\ -f1`/power
/ # lspci
00:00.0 PCI bridge: Freescale Semiconductor Inc MPC8572 PowerQUICC III PCIe Host Controller (rev 11)
/ # [reload the image on the FPGA, which implements the PCI-E interface]
/ # echo 1 > /sys/bus/pci/slots/0000:00:00.0/power
/ # lspci
00:00.0 PCI bridge: Freescale Semiconductor Inc MPC8572 PowerQUICC III PCIe Host Controller (rev 11)
01:00.0 Signal processing controller: Freescale Semiconductor Inc Aurora Nexus Trace Interface
Note that the device doesn't exist after boot, as the image on the FPGA
which implements the PCI-E interface must be loaded from Linux first. When
the image is reloaded in the middle step, it could change the device into a
completely different one. Different PCI id, different BARs, PCI-E link
width changing from 4x to 8x, and so on. I just don't have any visibly
different images handy that run on the hardware I have online at the
moment.
Having a PCI/PCI-E interface that exists in an FPGA isn't uncommon for
custom hardware. An IP block for a PCI/whatever interface is a standard
feature for any FPGA powerful enough for that sort of thing. I know there
are others who use fakephp for this same thing with there FPGA based
hardware.
next prev parent reply other threads:[~2008-11-27 1:44 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-25 21:24 Darrick J. Wong
2008-11-25 21:43 ` Greg KH
2008-11-26 4:46 ` Trent Piepho
2008-11-26 7:48 ` Darrick J. Wong
2008-11-26 9:56 ` Trent Piepho
2008-11-26 18:18 ` Darrick J. Wong
2008-11-26 22:23 ` Trent Piepho
2008-11-26 22:55 ` Alex Chiang
2008-11-27 1:44 ` Trent Piepho [this message]
2008-11-27 2:42 ` Matthew Wilcox
2008-11-28 10:11 ` Trent Piepho
2008-11-28 18:57 ` Matthew Wilcox
2008-11-28 21:21 ` Trent Piepho
2008-11-28 21:30 ` Matthew Wilcox
2008-12-01 1:10 ` Problems with fakephp Trent Piepho
2008-12-16 20:28 ` fixup PCI device booleans in sysfs Jesse Barnes
2008-11-28 23:18 ` [PATCH] fakephp: Allocate PCI resources before adding the device Alex Chiang
2008-12-01 13:00 ` Problems with fakephp Trent Piepho
2008-12-01 13:36 ` Trent Piepho
2008-12-01 14:08 ` [PATCH] PCI: Method for removing PCI devices Trent Piepho
2008-12-01 14:40 ` Greg KH
2008-12-01 14:08 ` [PATCH] PCI: Legacy fakephp driver Trent Piepho
2008-12-02 3:16 ` Problems with fakephp Alex Chiang
2008-12-03 4:07 ` Trent Piepho
2008-12-03 4:38 ` Alex Chiang
2008-12-03 17:22 ` Rolf Eike Beer
2008-12-03 17:43 ` Alex Chiang
2008-12-03 17:55 ` Rolf Eike Beer
2008-12-03 18:22 ` Alex Chiang
2008-12-08 21:09 ` Rolf Eike Beer
2008-11-27 1:52 ` [PATCH] fakephp: Allocate PCI resources before adding the device Darrick J. Wong
2008-11-28 9:51 ` Trent Piepho
2008-11-28 18:42 ` Rolf Eike Beer
2008-11-28 21:06 ` Trent Piepho
2008-12-01 17:08 ` Rolf Eike Beer
2008-12-16 19:33 ` Jesse Barnes
2008-12-16 20:56 ` [PATCH] fakephp: Allocate PCI resources before adding the?device Darrick J. Wong
2008-12-21 2:23 ` Trent Piepho
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=Pine.LNX.4.58.0811261647410.24816@shell4.speakeasy.net \
--to=xyzzy@speakeasy.org \
--cc=achiang@hp.com \
--cc=djwong@us.ibm.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.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
all inboxes | Powered by JetHome®