* Martin Fouts <[email protected]> [110707 17:26]: > From: Tony Lindgren [[email protected]] > > >> * Martin Fouts <[email protected]> [110707 10:20]: > > >>>From: Tony Lindgren [[email protected]] > > >> > If we're just doing a bunch of renames all over the place to add support > >> > for a new processor variant, something is wrong. This is exactly the kind > >> > of "crazy churn" Linus was complaining about. In this case the crazy > >> > churn > >> > is "let's rename 4430 to 44XX all over the place". > > > >> To me, this is not 'crazy churn', but rather, correcting an earlier > >> oversight. I did not understand Linus to say > >> "never fix a naming oversight", but "don't change names without a good > >> reason." > > > I think this is crazy churn. It does not fix the problem we have, which > > is "how can we support lots of SoCs in a sane way". It just postpones > > fixing the problem until the next SoC variant comes around. And now > > we already have the exact same problem with both the am3505 support > > and 4460 support. > > We are looking at different aspects of the problem. "How can we support lots > of SoCs in a sane way" is obviously the key problem. I was referring to the > smaller, ongoing problem that every device dependent piece of code has: "how > do we best communicate what variants are supported by this code."
Heh I see :) Yes that's a problem too, we still have mach-omap2 as the subach name.. > > The second problem we have here is "why does adding 4460 support depend > > on a cosmetic clean-up patch". That dependency should not exist at all > > as it seems the 4460 patches should work even without this patch. > > I agree. Had the original submitter had the foresight to realize that the > code should work for all 44xx family processors, we would have no issue at > all. Do we promulgate that oversight and introduce ambiguity about what is > really supported in those files, or do we correct it? Well sounds like we might be able to get rid of CHIP_IS in the *_data.c files if we use SoC variant specific lists. Of course Paul might have some other ideas here. > >> It seems to me that there is also a bullet to bite here. To achieve the > >> sort of rationalization across the arm architecture that is > >> envisioned, inconsistencies in naming styles between platforms will have > >> to be reconciled and resolved, lest the habit continue. > > > Sure things should be fixed, but things should be fixed properly. Here > > we are repeating the CHIP_IS flag in hundreds of places where it really > > should be only checked once after SoC is detected. And then based on > > that a SoC specifc list of devices can then be initialized. > > Yes. I was unclear. I didn't mean we should duplicate the 4430 code and > make small changes to it, to create nearly identical 4460 code. I only meant > that the unified code that works for 4430 and 4460 should not rely on names > that make it appear that one SoC is supported but not the other. I do not > feel that the later is cosmetic, although I agree it can be postponed.-- I think if this clean-up is not absolutely necessary we should queue the clean-up separately just to avoid the dependency between various patches. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
