Nishanth Menon wrote: > Linus Walleij had written, on 09/16/2010 07:19 AM, the following: >> 2010/9/15 Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx>: >> >>> OMAP SOCs have a standard set of tuples consisting of frequency and >>> voltage pairs that the device will support per voltage domain. These >>> are called Operating Performance Points or OPPs. >>> (...) >>> This introduces a common handling OPP mechanism accross all OMAPs. >>> As a start this is used for OMAP3. >> OPPs are a generic concept, it's in silicon construction textbooks and all. >> Should this code not be made generic instead? You wouldn't make >> regulators or even DMA platform-specific these days, so why should >> OPPs be? > As far as I see this patch : > hwmod[1] which is omap specific which inturn depends on omap_device. - > this impacts opp_add function in the opp layer. Then wrap your local OPP in some clever way: struct omap_opp { struct hwmod foo; struct opp opp; }; container_of() is your friend. Alternatively and not as elegant is to provide an void *private_data; in the generic opp struct. And similar design patterns for code and other platform-specific hooks. Overridable struct opp_ops for example, the same way we just abstracted the l2x0 operations for example. It's not like there are no precedents in the linux kernel on how to handle a superclass of some struct, so how hard can it be? The fact that a single struct member is OMAP-specific doesn't nix the fact that the major part of this OPP framework is generic code. Yours, Linus Walleij -- 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