From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) (using TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 26E521A000B for ; Wed, 17 Feb 2016 00:20:41 +1100 (AEDT) Received: from localhost by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 16 Feb 2016 06:20:39 -0700 Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 8F8BA3E4004C for ; Tue, 16 Feb 2016 06:20:36 -0700 (MST) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u1GDKaJ625755686 for ; Tue, 16 Feb 2016 06:20:36 -0700 Received: from d03av01.boulder.ibm.com (localhost [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u1GDKa2O007202 for ; Tue, 16 Feb 2016 06:20:36 -0700 Received: from oc5780617838.ibm.com ([9.80.84.27]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u1GDKY5V007104 for ; Tue, 16 Feb 2016 06:20:34 -0700 Subject: Re: [RFC, kernel] powerpc/ioda: Set "read" permission when "write" is set To: linuxppc-dev@lists.ozlabs.org References: <20160216031824.E5C8E140761@ozlabs.org> From: Douglas Miller Message-ID: <56C32222.6050704@linux.vnet.ibm.com> Date: Tue, 16 Feb 2016 07:20:34 -0600 MIME-Version: 1.0 In-Reply-To: <20160216031824.E5C8E140761@ozlabs.org> Content-Type: text/plain; charset=utf-8; format=flowed List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 02/15/2016 09:18 PM, Michael Ellerman wrote: > On Tue, 2016-12-01 at 04:40:20 UTC, Alexey Kardashevskiy wrote: >> Quite often drivers set only "write" permission assuming that this >> includes "read" permission as well and this works on plenty platforms. >> However IODA2 is strict about this and produces an EEH when "read" >> permission is not and reading happens. >> >> This adds a workaround in IODA code to always add the "read" bit when >> the "write" bit is set. >> >> Cc: Benjamin Herrenschmidt >> Signed-off-by: Alexey Kardashevskiy >> Tested-by: Douglas Miller > Are you planning on sending a non-RFC version of this? > > If so is it an urgent fix I should send upstream now? And if so should it > also be CC'ed to stable? > > cheers I vote for the more-urgent case. This is the result of a fairly recent change in behavior and we may not have found all the adapters that will break yet. If we get this upstream sooner, it means less exposure.