linux-kernel - Re: linux-next: manual merge of the devicetree tree with the powerpc tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1331713762.3105.121.camel@pasglop>
Date:	Wed, 14 Mar 2012 19:29:22 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Gavin Shan <shangw@...ux.vnet.ibm.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	Paul Mackerras <paulus@...ba.org>,
	linuxppc-dev@...ts.ozlabs.org,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: linux-next: manual merge of the devicetree tree with the
 powerpc tree

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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/