From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: linux-next: manual merge of the devicetree tree with the powerpc tree Date: Wed, 14 Mar 2012 19:29:22 +1100 Message-ID: <1331713762.3105.121.camel@pasglop> References: <20120313160100.c8cc3fd2b3d1f485ef7e7954@canb.auug.org.au> <20120313182612.0546D3E053B@localhost> <20120314015356.GA4028@shangw> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from gate.crashing.org ([63.228.1.57]:38348 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932102Ab2CNI37 (ORCPT ); Wed, 14 Mar 2012 04:29:59 -0400 In-Reply-To: <20120314015356.GA4028@shangw> Sender: linux-next-owner@vger.kernel.org List-ID: To: Gavin Shan Cc: Grant Likely , linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, Paul Mackerras , linuxppc-dev@lists.ozlabs.org, Stephen Rothwell On Wed, 2012-03-14 at 09:53 +0800, Gavin Shan wrote: > > +#if defined(CONFIG_EEH) > > > +static inline struct eeh_dev *of_node_to_eeh_dev(struct device_node *dn) > > > +{ > > > + return dn->edev; > > > +} > > > +#endif > > > > Ben, What is this? I don't want the eeh_dev pointer in struct device_node. Up to > > now we've avoided putting any reverse references into device_nodes. For everything > > else we use a reverse lookup, particularly for devices, to avoid growing the > > device_node for each new type of lookup. > > > > It's used to trace the EEH device. When EEH (Enhanced Error Hanlding) is enabled, > EEH device will be created against PCI sensitive OF node to trace the EEH state > accordingly. Since you don't want see this in struct device_node, we have to change > struct eeh_dev for a little bit to so that all struct eeh_dev instances will form > a global list and we can search eeh_dev according to the given device_node through > the global list. > > I don't know the policy or rule here for much. I think we can have 2 options. > > 1. Keep the code as being, and fix it later. > 2. Fix it now. My bad, it's a mis-review, I thought it was still in pci_dn, I din't catch Gavin moving it to device-node. Yes, Gavin, we need to do something else, a chained list we walk or something like that. For the "fast path" which is when we have a pci_dev around, we can either add it to dev_archdata or hijack the pci-dev platform_data (I don't think anything uses it, Grant, do you know of anything ?) The patches are already in -next and I won't rebase, so we need to fix it on top of the existing patches. Gavin, can you make a patch that puts it back into pci_dn to begin with, then we can contemplate what better long term solution we have ? Cheers, Ben.