On Mon, Sep 07, 2015 at 05:14:22AM +0100, Ganapatrao Kulkarni wrote: > Hi Hanjun, > > On Wed, May 27, 2015 at 1:51 PM, Hanjun Guo <hanjun.guo@xxxxxxxxxx> wrote: > > Hi Liviu, > > > > On 2015???05???27??? 01:20, Jiang Liu wrote: > >> > >> On 2015/5/27 0:58, Liviu Dudau wrote: > >>> > >>> On Tue, May 26, 2015 at 01:49:14PM +0100, Hanjun Guo wrote: > >>>> > >>>> ARM64 ACPI based PCI host bridge init needs a arch dependent > >>>> struct pci_controller to accommodate common PCI host bridge > >>>> code which is introduced later, or it will lead to compile > >>>> errors on ARM64. > >>> > >>> > >>> Hi Hanjun, > >>> > >>> Two questions: why don't you introduce this patch next to the > >>> one that is going to make use of it (or even merge it there)? > > > > > > this is because of this patch is needed by Jiang Liu's patch set > > to fix the compile error on ARM64, I'd rather do that, but It's > > better to let Jiang Liu's patch goes in, and then this one, that's > > why I prepared a single patch for the struct. (I mentioned it > > in the cover letter) > > > >>> Second, why is the whole struct pci_controller not surrounded > >>> by #ifdef CONFIG_ACPI as you are implying that this is needed > >>> only for ACPI? > > > > > > I hope it can be reused, since the NUMA node and segment (domain) > > is both needed for DT and ACPI, if it's not the case foe now, I > > can surrounded them all by #ifdef CONFIG_ACPI. > we can make use of this structure to hold pci to numa node > mapping(pcibus_to_node). > can you please pull node member out of CONFIG_ACPI ifdef. > or you can put only acpi_device under ifdef. That struct disappeared in the latest series: https://lkml.org/lkml/2015/6/8/443 we have to have a common way to handle the NUMA info in DT and ACPI so we should still find a solution that can be shared between the two, it is yet another thing to take into account for PCI ACPI on arm64. Thanks, Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
