From: Arjan van de Ven <arjan@infradead.org>
To: Dave Peterson <dsp@llnl.gov>
Cc: Greg KH <greg@kroah.com>, "Randy.Dunlap" <rdunlap@xenotime.net>,
linux-kernel@vger.kernel.org, torvalds@osdl.org, alan@redhat.com,
gregkh@kroah.com, Doug Thompson <dthompson@lnxi.com>,
bluesmoke-devel@lists.sourceforge.net
Subject: Re: [PATCH] EDAC: core EDAC support code
Date: Fri, 10 Mar 2006 08:36:58 +0100 [thread overview]
Message-ID: <1141976218.2876.2.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <200603091746.51686.dsp@llnl.gov>
On Thu, 2006-03-09 at 17:46 -0800, Dave Peterson wrote:
> > > Issue #3
> > > --------
> > > I am unclear about what to do here. If the list contents were
> > > read-only, it would be relatively easy to make
> > > /sys/devices/system/edac/pci/pci_parity_whitelist into a directory
> > > containing symlinks, one for each device. However, the user is
> > > supposed to be able to modify the list contents. This would imply
> > > that the user creates and destroys symlinks. Does sysfs currently
> > > support this sort of behavior? If not, what is the preferred
> > > means for implementing a user-modifiable set of values?
> >
> > No it doesn't. How big can this list get?
>
> It depends on how many PCI devices in your machine you wish to
> blacklist or whitelist. The motivation for this feature is that
> certain known badly-designed devices report an endless stream of
> spurious PCI bus parity errors. We want to skip such devices when
> checking for PCI bus parity errors.
ok so this is actually a per pci device property!
I would suggest moving this property to the pci device itself, not doing
it inside an edac directory.
by doing that you get the advantage that 1) it's a more logical place,
and 2) users can do it even for 1 of 2 cards, if they have 2 cards of
the same make and 3) you can use the generic kernel quirk interface for
this and 4) drivers can in principle control this for their hardware in
complex cases
I understand that on a PC, EDAC is the only user. but ppc has a similar
mechanism I suspect, and they more than likely would be able to share
this property....
next prev parent reply other threads:[~2006-03-10 7:37 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200601190414.k0J4EZCV021775@hera.kernel.org>
2006-03-05 10:18 ` Arjan van de Ven
2006-03-05 10:30 ` Arjan van de Ven
2006-03-06 18:14 ` Dave Peterson
2006-03-06 18:22 ` Randy.Dunlap
2006-03-07 17:03 ` Dave Peterson
2006-03-07 17:20 ` Greg KH
2006-03-08 0:29 ` Dave Peterson
2006-03-07 19:03 ` Arjan van de Ven
2006-03-07 19:05 ` Greg KH
2006-03-09 23:51 ` Dave Peterson
2006-03-10 0:02 ` Greg KH
2006-03-10 1:46 ` Dave Peterson
2006-03-10 7:36 ` Arjan van de Ven [this message]
2006-03-10 11:06 ` Tim Small
2006-03-10 11:40 ` Arjan van de Ven
2006-03-10 17:46 ` Dave Peterson
2006-03-10 17:58 ` Arjan van de Ven
2006-03-10 19:07 ` Dave Peterson
2006-03-10 19:33 ` Arjan van de Ven
2006-03-10 21:13 ` Dave Peterson
2006-03-10 21:23 ` Arjan van de Ven
2006-03-11 1:57 ` Dave Peterson
2006-03-11 7:18 ` Arjan van de Ven
2006-03-13 19:31 ` Dave Peterson
2006-03-06 19:52 ` Greg KH
2006-03-05 15:55 ` Greg KH
2006-03-05 16:24 ` Arjan van de Ven
2006-03-06 18:52 ` Dave Peterson
2006-03-06 19:53 ` Greg KH
2006-03-06 21:01 ` Dave Peterson
2006-03-06 21:07 ` Arjan van de Ven
2006-03-09 3:19 ` Dave Peterson
2006-03-09 3:44 ` Al Viro
2006-03-09 5:51 ` Greg KH
2006-03-06 21:32 ` Al Viro
2006-03-06 21:53 ` Greg KH
2006-03-06 22:24 ` Al Viro
2006-03-06 22:55 ` Greg KH
2006-03-07 10:41 ` Andrew Morton
2006-03-07 11:08 ` Al Viro
2006-03-08 2:46 ` Rusty Russell
2006-03-07 1:45 ` Dmitry Torokhov
2006-03-07 1:57 ` Greg KH
2006-03-07 2:10 ` Dmitry Torokhov
2006-03-07 16:47 ` Dave Peterson
2006-03-07 17:04 ` Greg KH
2006-03-07 17:06 ` Dave Peterson
2006-03-08 1:03 ` Dmitry Torokhov
2006-03-08 1:33 ` Greg KH
2006-03-10 0:44 Doug Thompson
2006-03-10 16:56 Doug Thompson
2006-03-10 17:11 ` Arjan van de Ven
2006-03-10 17:28 Doug Thompson
2006-03-10 20:37 Doug Thompson
2006-03-11 17:04 Doug Thompson
2006-03-13 19:35 ` Dave Peterson
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=1141976218.2876.2.camel@laptopd505.fenrus.org \
--to=arjan@infradead.org \
--cc=alan@redhat.com \
--cc=bluesmoke-devel@lists.sourceforge.net \
--cc=dsp@llnl.gov \
--cc=dthompson@lnxi.com \
--cc=greg@kroah.com \
--cc=gregkh@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
--cc=torvalds@osdl.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®