Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Message-ID: <ab57ba73-ce62-43fc-9cb1-d2db1bd13cd9@os.amperecomputing.com>
Date:   Mon, 30 Oct 2023 17:12:01 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] i2c: designware: Fix corrupted memory seen in the ISR
To:     Wolfram Sang <wsa@kernel.org>,
        Jarkko Nikula <jarkko.nikula@linux.intel.com>,
        Serge Semin <fancer.lancer@gmail.com>,
        Yann Sionneau <ysionneau@kalrayinc.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Yann Sionneau <yann@sionneau.net>,
        Will Deacon <will@kernel.org>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Jan Dabros <jsd@semihalf.com>,
        Andi Shyti <andi.shyti@kernel.org>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
References: <ZQm1UyZ0g7KxRW3a@arm.com>
 <cde7e2fc-2e13-4b82-98b3-3d3a52c4c185@os.amperecomputing.com>
 <p7wl7fk4cdyhvw2mfsa6sfc7dhfls3foplmzwj6pzstargt2oh@33zuuznup2gq>
 <ZQq2cT+/QCenR5gx@shikoro>
 <ba6d4378-b646-4514-3a45-4b6c951fbb9c@kalrayinc.com>
 <9219ad29-b9a3-4f07-81b5-43b4b6d9d178@os.amperecomputing.com>
 <d65lwrkji3rvw6r4jdcumo4zu3hbu6zpv6xq73hw6hcshvhtkw@jvuohb3f3loo>
 <3a305e74-2235-47ab-8564-0c594f24dc0a@os.amperecomputing.com>
 <ZRSEntqne/1y1ozq@shikoro>
 <1d56ceef-6573-43b9-a050-124c341a0698@linux.intel.com>
 <ZTpLHZZYtd1WgBu6@ninjato>
Content-Language: en-US
From:   Jan Bottorff <janb@os.amperecomputing.com>
In-Reply-To: <ZTpLHZZYtd1WgBu6@ninjato>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aGp1MDE1aUo5dCtwekNJNWRkUDlZMzhFcm5XS0I1ZU9QQXE2em1TdjNnbXRa?=
 =?utf-8?B?QkZZaGJnSUZET2ZYMCtmMVJwMUNjT2hZaUZ0V1V3VktVeUxNYURMVkZ0bWlr?=
 =?utf-8?B?UmRXajJaYzE4dExndVI0K252cXNpbHlKcFo2TjRiVFVkNFFrdzVpdVZsS1BD?=
 =?utf-8?B?M2tNZkN4amVPYVc2YVk5dm9yY3JQSzY5SnkwMkNjZU5kb2laVWJESXNDSzBJ?=
 =?utf-8?B?MUtSTWZkNHBuT1l2c3A3M0pIdGNkVEFudGVRTWZkaVdvVEY3RDZzS2RFUGhB?=
 =?utf-8?B?bGRGQnBUZkJ4ckZ6UVRVcnZ4QUNzTHlyZGtUV21JajkyUWFEVkNvTEJPZWRC?=
 =?utf-8?B?RnNmL2ZCVEI4VXdCajBCbXUxaGdlQk9yaEdicFZxcDUzT0N0bFBCd0F1M29j?=
 =?utf-8?B?V1JFMlRJMVlWK0UzWXRDT1diL1hUQXR2Rm01My82cGtMZk1oSHZlRlVCcEll?=
 =?utf-8?B?cEhycXplM0tYUjU4Sk96OGNlamxwejh0RXJ5QkdnM0w4VlRhYUoyZ3RNRHc4?=
 =?utf-8?B?OEJuTWdKYkx0OGRzNFd3c1dnUzdaR0ZjS3B4Z1NPVlFWelZvVHowSDdaV3dr?=
 =?utf-8?B?cEtYcXpJUjhxcmxEcTNkZHdsVGJ6eXNoZUN5L2FxUkVlWTIybVhmQW1aakhG?=
 =?utf-8?B?Z0xZc3Avc1daSnhCTUlESlVpWG8xamtnR05mWDNhejVvUlozT0ViRlN2WHY4?=
 =?utf-8?B?QldHTE1oaC95b1J6OXQ2VTFma1VXbFlYSEJMU3NjcDU0WVdRak4wVzhlVWlw?=
 =?utf-8?B?cTNxVWYvZVhVVjRoenI3SlUzRGNhSWVpcGhSVEdFTXcvQVBvbEl6d1RFWTNl?=
 =?utf-8?B?U0xBTTV4VkRIWGIrMHFiRGRsR0NRZjBLY3NVeGkvZWQvSDk3dXFsWmFyZXAy?=
 =?utf-8?B?WmVzSWpGdmxsNmc3aTFDaGw2SVF2U0IydHYzLy9HMDVSUHZzZmc0R3ZrdVZK?=
 =?utf-8?B?aWZwT1lPRUZpZDRzTGh3dnpyUFZHcWxKYU1CR1ovRHh5U3Y2eDFjOG1qbVFE?=
 =?utf-8?B?TFJ3S1N0eGNGSCt6U09QQjhzd21hSzV4NDhySEVxajMvMHFwZ1kxcWFXTWxh?=
 =?utf-8?B?Myt6UUk5QTBUSGNLU1ZjdEpNVmE1Kzl6YmhCbk1DdHF2WDhGUGZnaitzYTFK?=
 =?utf-8?B?UjB2a3hNWFdCN1BpME5KUFE4ZGZROXAyMlNQSkpSV0FLNnpYcHcyWU1Oaitk?=
 =?utf-8?B?bE9VQjdkcTQwSVpOV255RkZiQ0l5Tng1aFRNQlN5SnRZRlZKMjk1Z0JMM0Rm?=
 =?utf-8?B?bklPcFNMSThlOGdtZjNkR2MwaFlBMThNVU41T2l3eU9CcHlETndpMlA3VVMx?=
 =?utf-8?B?UFp6OTJnYm1ZN3lZdExJTlJzWkIwK21tWWU2Y1hCV0poVDVrMmpkNjFYbXFD?=
 =?utf-8?B?bjZETWJnYzgxMXh0ZDQwNlFDVzdwY0U1alJVMElDZUIwYW1ESzRwc1pjRVBt?=
 =?utf-8?B?R1BqdXRTdHBJVTMxUlNJYmFBcnp4WFQxeXRzcno5QjA2UUVma0NVZHRkVWdq?=
 =?utf-8?B?ekMzYWdMWTNyUFE4VEJadnNjYlltRTZ5SFgwT0NDaTVWZk96MmhQMVBsYkdP?=
 =?utf-8?B?SjZoajVkcUhkNit2aXJob1lNZ3ZoczJ2RjIwNmFPb3dBcmttVE44ZXJjcWJU?=
 =?utf-8?B?ZGdzdVUzcTNjOEpBZ3YxRjFKWkEwR0NKaHJwNjFmU0sxMUhGNlBmaWlORlhZ?=
 =?utf-8?B?ZEtvNjAwN29yQ2l4alM0RHhLNXBjY2M5cXFKN3NDcGxFajFpdXc2STNwRGxy?=
 =?utf-8?B?UUZIZjZUckNNY1ozMnQ4ZTM2V3RuRjJIUVJPMTZXekJndkpLeFBCaUNIaFpq?=
 =?utf-8?B?cEd4NCtyT05ZT3dsLzAvRzZLOEZNdkhZeVBFbXNOc1kwK2hXbG1Zc3RFS2FX?=
 =?utf-8?B?eUlHNzdta3lRbzl1YjhXRnU4SWVhMHpxbW1ycmZwcm40ay9QUnNiWlpMYWtG?=
 =?utf-8?B?L3dUc3czVWZ3Q2s3ZlhaNUpPTTQvSUtuU2RueHBYWG1hOHRuU1VuYW1mVXpY?=
 =?utf-8?B?RzkzVTJwR2liM0kwR0hhU0RFeDMxYUlSN1hrUFJPQUhvcU5FbzRJTnNrRVhV?=
 =?utf-8?B?eG5BbW5aRVlYK0ZqNTd3QWVvcFgvZlFKUUZrTmhsOEFuNi9rcnF5K3oxMUhy?=
 =?utf-8?B?Wlg4bU9VZ2pBOFZwZU4zTmZsQStjYk55eWJuOEZmV09QbkZxT0NycGlCVmtw?=
 =?utf-8?Q?g/KQnMTvkKs0xqf4fB+9zkw=3D?=
X-OriginatorOrg: os.amperecomputing.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6577d21b-1bd0-492a-e5e7-08dbd9a603fa
X-MS-Exchange-CrossTenant-AuthSource: PH0PR01MB7475.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2023 00:12:05.8830
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: l4RIn5Ip/6ZGixUWRwFqVmnoVq4wbRaYqgefQnevAZipn379Wgh6omsj6sQ7Q2WEt9ukmiQsk2e9/17YbH6kudS0hZ6fX+82sN3gi+2gqLw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR01MB7744
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Mon, 30 Oct 2023 17:12:27 -0700 (PDT)

On 10/26/2023 4:18 AM, Wolfram Sang wrote:
> So, someone wants to come up with a patch to move to non-relaxed io
> accessors?
> 
Is the current thinking to just make writes to DW_IC_INTR_MASK use the 
non-relaxed variant or something more broad?

 From a safest functioning viewpoint, we talked about making all 
accessors default to non-relaxed variants. A couple of pretty good 
arguments from knowledgeable people favored this. I know there also was 
some concerns about potential performance impact this might have 
although the counter argument was this is a pretty low speed device so 
some extra cpu cycles on register accesses were not likely to degrade 
overall performance.

I could make the patch if we have consensus (or maintainers decision) on 
which way to go: 1) only writes to DW_IC_INTR_MASK are non-relaxed, 2) 
make all read/write accessors use the non-relaxed version.

I'm personally in camp #2, safety first, performance fine tuning later 
if needed. Latent missing barrier bugs are difficult and time consuming 
to find.

- Jan