On Fri, Jul 08, 2011 at 09:11:43AM +0200, Paul Walmsley wrote: > On Thu, 7 Jul 2011, Martin Fouts wrote: > > > From: Tony Lindgren [tony@xxxxxxxxxxx] > > > > > 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. > > Uhhh... > > The original 4430 data, which is mostly what we're talking about here, was > added in 2009. Maybe a few people inside TI knew what was going to change > and what was going to be the same for future OMAP4 parts. But even if > someone did know, the decision of what to call a chip often isn't up to > engineers, it's up to marketing, which picks whatever name they like. > You know, like Linux 2.6.40^H^H^H^H^H^H3.0. > > So back in 2009, the submitter and maintainers were faced with a choice: > > Option 1. Submit patches with facts. "OMAP4430". Don't speculate what > future, as-yet-nonexistent products will be numbered, and what their > feature set will be. Plan to generalize later once it is known exactly > what needs to be generalized. > > Option 2. Try to predict what marketing will call the next chip, and what > features will still be present, then put that into the codebase. > "OMAP44XX". Hope you guess right so you don't have to change them all if > marketing or engineering comes up with something different. > > So, what's the right answer? Option 3. have engineering and marketing names and use the engineering names in the code. Cheers, Peter. -- 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
