From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [RFC] Architecture independent pcibios? Date: Wed, 09 Oct 2013 21:37:48 +1100 Message-ID: <1381315068.4330.1.camel@pasglop> References: <20131008144211.GA25231@e102652-lin.cambridge.arm.com> <525438F6.3090600@gmail.com> <1381264135.645.230.camel@pasglop> <20131009090923.GE25606@e102652-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20131009090923.GE25606@e102652-lin.cambridge.arm.com> Sender: linux-pci-owner@vger.kernel.org To: Liviu Dudau Cc: Rob Herring , Bjorn Helgaas , "linux-pci@vger.kernel.org" , Catalin Marinas , Olof Johansson , Arnd Bergmann , Michal Simek , "grant.likely@linaro.org" , "devicetree@vger.kernel.org" List-Id: devicetree@vger.kernel.org On Wed, 2013-10-09 at 10:09 +0100, Liviu Dudau wrote: > On Tue, Oct 08, 2013 at 09:28:55PM +0100, Benjamin Herrenschmidt wrot= e: > > On Tue, 2013-10-08 at 11:55 -0500, Rob Herring wrote: > > > > > > I wonder if pci_process_bridge_OF_ranges() would fit somewhere = in > > > > drivers/of? The implementations I looked at are mostly concern= ed with > > > > parsing OF resources, and they don't have much to do with PCI > > > > directly. > > > > > > This was being done until Ben weighed in: > > > > > > https://lkml.org/lkml/2013/5/4/103 > > > > Well, I proposed an alternative (better) approach which I of course= had > > no time to actually implement yet :-) >=20 > In order to avoid any confusion, could you please point me again to t= he > relevant message(s) where you proposed your approach? The one pointed to by the above URL ? > > I have done the changes I needed to do to powerpc > > pci_process_bridge_OF_ranges so it would be possible to move that n= ow to > > a generic place, but I still think it's not a great idea. It means = the > > pci_controller structure with its resources will have to become gen= eric > > which somewhat overlaps with the pci_host_bridge that Bjorn introdu= ced, > > so that's really not great. > > > > I still think an arch with DT and simpler PCI code that powerpc cou= ld > > start looking at the transition to a better model that I hinted at.= =2E. >=20 > As tempting as it is to start anew and with a cleaner code, I am wary > that porting the existing platforms to the new code will take longer > that way. My intentions are to make the (probably infrequent) task of > adding a new architecture to the PCI infrastructure a simple and > straighforward task. But adding code for my platform is no guarantee > that new ones will have an easier job. It still makes little sense to generalize a pci_controller with resources & offset on top of the generic pci_host_bridge with apertures= =2E Ben. > Best regards, > Liviu >=20 > > > > Cheers, > > Ben. > > > > > > >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | I would like to | > | fix the world, | > | but they're not | > | giving me the | > \ source code! / > --------------- > =C2=AF\_(=E3=83=84)_/=C2=AF >=20 > -- IMPORTANT NOTICE: The contents of this email and any attachments a= re confidential and may also be privileged. If you are not the intended= recipient, please notify the sender immediately and do not disclose th= e contents to any other person, use it for any purpose, or store or cop= y the information in any medium. Thank you. >=20 > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, = Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 = 9NJ, Registered in England & Wales, Company No: 2548782