On Fri, Sep 19, 2008 at 01:02:11PM -0500, Kumar Gala wrote: [...] >>> Anton> This is purposely. We also need support for 8610, and maybe >>> Anton> later we'll find another chip with the same unit. So, to not >>> touch >>> Anton> the Kconfig for every new chip I just made it PPC32-wide. >>> Other >>> Anton> option is to depend on FSL_SOC, but the driver really does not >>> Anton> depend on any fsl_soc stuff... >>> >>> Adding another symbol to the Kconfig once it is verified that a new >>> SoC is compatible doesn't seem like a big deal - Figuring out all the >>> knobs we already have is, without having options for stuff that is >>> known to be irrelevant for the SoC. >>> >>> The other 83xx specific drivers also depend on PPC_83xx. >> >> Lets wait for Kumar's comments. We've already had a PPC_* mess >> for the USB_EHCI_FSL symbol. What I've learned from it, is that >> huge PPC_* list isn't perfect either. > > I've alone glanced over this, but some initial comments are.. lets > rename the thing to not be 83xx specific since 8610 uses it and I'm sure > we'll have other parts that do similar things.
Ok, mpc8xxx_gpio.c would be fine? (Note that I'm agree with 8xxx, for the file name). > With regards to the binding, lets make it generic like 'fsl,mpc8xxx- > gpio", "fsl,CHIP-gpio" and than we can use cpm1/cpm2/pq1/pq2 as prefixes > to distinguish and major differences. But for compatible entry, shouldn't we use the last compatiblle entry as a generic one? Then fsl,mpc8349-gpio is perfectly valid. I.e., for MPC8610 chips we will have: "fsl,mpc8610-gpio", "fsl,mpc8349-gpio" The last entry is most generic, and 8610 is registers-compatible with the earlier (8349) chips. I thought that we tend to not do "made up" 8xxx things in the device tree... Am I wrong? Thanks! -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
