From: Tony Lindgren [tony@xxxxxxxxxxx] >> * Martin Fouts <mfouts@xxxxxxxxxxxxxxx> [110707 10:20]: >>>From: Tony Lindgren [tony@xxxxxxxxxxx] >> > 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." > 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? >> 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.-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
