From: Dave Jiang <djiang@mvista.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linuxppc-dev@ozlabs.org, norsk5@yahoo.com,
bluesmoke-devel@lists.sourceforge.net
Subject: Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver
Date: Mon, 30 Jul 2007 09:40:13 -0700 [thread overview]
Message-ID: <46AE146D.8010504@mvista.com> (raw)
In-Reply-To: <200707291606.21612.arnd@arndb.de>
Arnd Bergmann wrote:
> On Friday 27 July 2007, Dave Jiang wrote:
>> +static struct of_device_id mpc85xx_pci_err_of_match[] = {
>> + {
>> + .type = "pci",
>> + .compatible = "fsl,mpc8540-pci",
>> + },
>> + {},
>> +};
>> +
>> +static struct of_platform_driver mpc85xx_pci_err_driver = {
>> + .owner = THIS_MODULE,
>> + .name = "mpc85xx_pci_err",
>> + .match_table = mpc85xx_pci_err_of_match,
>> + .probe = mpc85xx_pci_err_probe,
>> + .remove = mpc85xx_pci_err_remove,
>> + .driver = {
>> + .name = "mpc85xx_pci_err",
>> + .owner = THIS_MODULE,
>> + },
>> +};
>
> This is a little problematic, if we want to make the PCI bus implementation
> use the PCI code from arch/powerpc/kernel/of_platform.c in the future.
> Right now this is not possible, because that code is still 64-bit only,
> but that may change in the future. Since only one driver can bind
> to the pci host bridge device, the mpc85xx_pci_err driver would conflict
> with the PCI driver itself, which you probably don't intend.
>
> I'd suggest either to integrate EDAC into the 85xx specific PCI code,
> or to have an extra device in the device tree for this.
How about I create a platform device just for EDAC and leave the PCI of_device
to the 85xx PCI code? That would be a lot less modification than adding a
device for every PCI hose per DTS file.... Just a thought....
>> + res = of_register_platform_driver(&mpc85xx_mc_err_driver) ? : res;
>> +
>> + res = of_register_platform_driver(&mpc85xx_l2_err_driver) ? : res;
>> +
>> +#ifdef CONFIG_PCI
>> + res = of_register_platform_driver(&mpc85xx_pci_err_driver) ? : res;
>> +#endif
>> +
>> + /*
>> + * need to clear HID1[RFXE] to disable machine check int
>> + * so we can catch it
>> + */
>> + if (edac_op_state == EDAC_OPSTATE_INT) {
>> + orig_hid1 = mfspr(SPRN_HID1);
>> +
>> + mtspr(SPRN_HID1, (orig_hid1 & ~0x20000));
>> + }
>> +
>> + return res;
>> +}
>
> The error handling could use some improvement here. In particular, you should
> unregister the buses in the failure path, maybe you need to clean up other
> parts as well.
I think I want individual "devices" work even some may fail or be missing. For
example, even if L2 fails to register, I still want to be able to get the
memory controller to report errors. So I really don't want to unregister
everything that initialized properly even though some failures exists. Maybe I
need to clean it up a little bit.
--
------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
next prev parent reply other threads:[~2007-07-30 16:36 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-26 22:22 [PATCH 2/2] powerpc: MPC85xx EDAC device driver Dave Jiang
2007-07-29 14:06 ` Arnd Bergmann
2007-07-30 16:40 ` Dave Jiang [this message]
2007-07-30 17:28 ` Arnd Bergmann
2007-07-30 17:48 ` Dave Jiang
2007-07-30 18:46 ` Arnd Bergmann
2007-07-30 19:29 ` Dave Jiang
2007-07-30 19:58 ` Arnd Bergmann
2007-07-30 20:17 ` Dave Jiang
2007-07-30 21:44 ` Linas Vepstas
2007-07-30 22:47 ` Doug Thompson
2007-08-01 19:48 ` EDAC & PCI error recovery (was Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver) Linas Vepstas
2007-08-01 20:34 ` EDAC stats " Doug Thompson
2007-07-30 22:58 ` [PATCH 2/2] powerpc: MPC85xx EDAC device driver Dave Jiang
2007-07-31 20:49 ` Dave Jiang
2007-07-31 22:07 ` Arnd Bergmann
2007-07-31 22:24 ` Dave Jiang
2007-07-31 22:25 ` Arnd Bergmann
2007-08-01 0:16 ` Dave Jiang
2007-08-01 8:36 ` Arnd Bergmann
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=46AE146D.8010504@mvista.com \
--to=djiang@mvista.com \
--cc=arnd@arndb.de \
--cc=bluesmoke-devel@lists.sourceforge.net \
--cc=linuxppc-dev@ozlabs.org \
--cc=norsk5@yahoo.com \
/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;
as well as URLs for NNTP newsgroup(s).