On Mon, 2014-01-06 at 14:10 +0800, Lian Minghuan-b31939 wrote: > On 01/04/2014 06:19 AM, Scott Wood wrote: > > I don't like the extent to which this duplicates (not moves) PPC's struct > > pci_controller. Also this leaves some fields like "indirect_type" > > unexplained (PPC_INDIRECT_TYPE_xxx is only in the PPC header). > > > > Does the arch-independent part of the driver really need all this? Given > > how closely this tracks the PPC code, how would this work on ARM? > [Minghuan] I added the duplicate fields because PPC's struct > pci_controller need them. I think a better approach would be to create a cleanly architected arch-independent driver. Share what you reasonably can with the current fsl_pci.c, but not to the extent of propagating PPCisms that don't match up with what we ultimately want to see in generic code, or copying things that ought to be controller-independent infrastructure into controller-specific code. See these threads: http://www.spinics.net/lists/linux-pci/msg25769.html https://lkml.org/lkml/2013/5/4/103 > The following is for ARM, I will submit them after verification: [snip] > +static int fsl_pcie_register(struct fsl_pcie *pcie) > +{ > + pcie->controller = fsl_hw_pcie.nr_controllers; > + fsl_hw_pcie.nr_controllers = 1; > + fsl_hw_pcie.private_data = (void **)&pcie; I believe this should be: fsl_hw_pcie.private_data = pcie; > + pci_common_init(&fsl_hw_pcie); > + pci_assign_unassigned_resources(); > +#ifdef CONFIG_PCI_DOMAINS > + fsl_hw_pcie.domain++; > +#endif What serializes that non-atomic increment? -Scott -- 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
