On Wed, Sep 24, 2014 at 01:10:51PM +0100, Mark Rutland wrote: > On Wed, Sep 24, 2014 at 12:19:45PM +0100, Tomasz Figa wrote: > > On 24.09.2014 13:14, Mark Rutland wrote: > > > I'm not too keen on tristate properties. Is this level of flexibility > > > really required? I would say that we need a way to enable _and_ disable these features, because: 1. When we converted the L2 code to DT, no one thought about creating a full and proper DT specification for the L2 code. So, we have the situation today where platform code (and firmware code) enables or disables these features depending on platform knowledge. 2. If we are going to specify these options as a boolean-enable value, this implies that the lack of the boolean disables the option. We have pre-existing DT files which do not contain this option, but the platform may rely on the feature being enabled. This is precisely the kind of mess that happens when incomplete DT bindings are accepted. DT bindings for any device should be _full_ bindings from the start, and not a half-hearted attempt at the job. As much as we don't like tristate properties, we only have ourselves to blame for them becoming a necessity in cases like this. > With the lack of warnings for present but empty properties, I can forsee > people placing empty properties (as the names make them sound like > booleans which enable features). > > Surely for enabling/disabling options we should only need to override > one-way, disabling a feature that causes breakage for some reason? > Otherwise we can keep the reset value (which might be sub-optimal). What if enabling prefetching on an existing platform causes a failure? That's a regression on a previously working DT file, and needing a DT update to resolve. The obvious alternative is we have two properties per feature - one boolean to enable, and one boolean to disable the feature. We already have a number of negative properties because of exactly the same problem I mention above (where the driver has assumed defaults for one platform which are not appropriate for all platforms.) > > As for why they cause crashes, I'm not an expert if it is about L2C > > internals, so I can't really tell, but apparently the cache can work > > correctly only on certain settings. > > Likewise, I'm no expert on the l2x0 family. It would be nice to know if > this justs masks an issue elsewhere in Linux, is required for some > reason by the interconnect, etc. I guess we don't have enough > information to figure that out. No, it would be nice to have some errata information... -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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
