[including extra context because some of the thread went to the wrong I2C list]
David Gibson wrote: > On Wed, Nov 05, 2008 at 04:35:03PM -0800, Mike Ditto wrote: >> David Gibson wrote: >> > What does worry me, however, is the description says it's about >> > whether the driver "should" enable the filter. Generally the device >> > tree doesn't attempt to say what users "should" do with the hardware, >> > just what the characteristics of the hardware are. >> > >> > What's the underlying difference here that affects the driver's choice >> > to enable the filter or not? >> >> I think it's a hardware/environment design parameter - e.g. if the I2C >> bus has hot-pluggable devices, long PCB traces, or a hierarchy of >> multiplexed bus segments, these can result in a noisy SCL signal that >> needs to be filtered. It's also a recommended mitigation for errata >> in certain CPU revs. > > Ah, ok. Well the CPU revision thing could be selected based on the > CPU revision, but the other conditions are a property of the board > wiring. Obviously it's hard to precisely characterize what it says > about the hardware, which is usually best avoided for devtree > properties, but I can see why this is more-or-less unavoidable in this > case. > > Ok. This property name and meaning looks ok to me. I would suggest a > note in the binding roughly explaining what leads to the property > being set (basically what you just told me in the paragraph above). Will do. I'll send a revised patch shortly. Thanks, -=] Mike [=- _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev