On Mon, 2015-11-02 at 10:41 -0800, Ram Pai wrote: > On Mon, Nov 02, 2015 at 12:23:36PM +1100, Michael Ellerman wrote: > > On Fri, 2015-10-30 at 15:31 -0700, Ram Pai wrote: > > > icswx occasionally under heavy load sets bit 3 of condition register 0. > > > > Why? > > The hardware manual says that bit is undefined, though it is set under some > conditions.
Which hardware manual? Last I checked none of this was documented anywhere public. But the out of date RFC I have does define bit zero to mean something. > > > Currently that bit is interpreted by the driver as a failure, when > > > it should have calmly ignored it. > > > > Should the fix be in icswx or the driver? Please justify your choice. > > Yes there are two solutions. One is icswx macro should not expose that > bit to its consumers. Or the driver/consumers can ignore that bit. I > think it makes more sense to contain it in one place, which is icswx > instruction. Drivers or whoever calls icswx should not know > more than what they need to know. This patch uses the first approach. Yep, I'm fine with doing it in icswx if we're 100% sure the bit is always undefined. > > This sounds like it's fixing a bug so shouldn't the patch go to stable? And > > if > > so which version(s) should it apply to? > > It should go to stable v4.2. I will tag it to stable, in my next version. Thanks. cheers _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
