From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A541CC43381 for ; Mon, 25 Mar 2019 13:40:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7DFDF2084D for ; Mon, 25 Mar 2019 13:40:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729003AbfCYNkY (ORCPT ); Mon, 25 Mar 2019 09:40:24 -0400 Received: from sauhun.de ([88.99.104.3]:46124 "EHLO pokefinder.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726059AbfCYNkX (ORCPT ); Mon, 25 Mar 2019 09:40:23 -0400 Received: from localhost (p54B33284.dip0.t-ipconnect.de [84.179.50.132]) by pokefinder.org (Postfix) with ESMTPSA id 06A7E2C0963; Mon, 25 Mar 2019 14:40:20 +0100 (CET) Date: Mon, 25 Mar 2019 14:40:20 +0100 From: Wolfram Sang To: Andy Shevchenko Cc: Wolfram Sang , linux-i2c , Linux-Renesas , Linux Kernel Mailing List , linux-arm Mailing List , Keerthy , Peter Rosin , Tony Lindgren , Russell King , Andy Shevchenko , Stefan Lengfeld , Phil Reid , Tero Kristo , Linux OMAP Mailing List , linux-tegra@vger.kernel.org Subject: Re: [RFC PATCH v2 0/7] i2c: core: introduce atomic transfers Message-ID: <20190325134020.GA3375@kunai> References: <20190302134735.4393-1-wsa+renesas@sang-engineering.com> <20190312154501.6v2symbq6eutp6dj@ninjato> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <20190312154501.6v2symbq6eutp6dj@ninjato> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > This series seems like a valid approach to me if we still want to > respect the locking. And I am leaning to that it is good enough. I think pragmatism is OK here: The users who want this feature simply want to reboot their system, mostly development systems. They can't reboot otherwise. Except for the HW switch they are currently using anyhow. The panic fault-injector can create an inconsistent situation on the I2C bus when you want to reboot after an OOPS while a transfer was in progress. However, if rebooting in such scenarios is critical for you, you a) shouldn't reboot via I2C, and/or b) should have a watchdog in place. We can't guarantee to always fix this sitution. At best, we could just try to be better for some cases. However, this would mean having a backdoor to skip the locking scheme which doesn't sound right. Maybe just accepting the deadlock is not too bad because it will reliably point out a design flaw of the system (hopefully during the development stage)? Final call for other thoughts/comments. PS: I am still interested in the use of in_atomic() here. I wonder if it is correct. If a change is needed, it should probably be a seperate series, though. --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAlyY2kAACgkQFA3kzBSg KbZo2g//dCNbQqq7JCJ5Lv/VujuOvXfvIAhTdixDdvjH0OB63oi+g7uOczVtHA3C MwOtHz0SzrK28zgFKP54noME6BxsaNA/wkFGRidTz5e1SbxgEuDBefLKTjo6eXWV w4qE87SZteJtKQhMTu2fMELiwDQoI3mVfWuBEucdhIqa9zumT6RALS5z/miAzr6E M53RUZ+k/tOanoOyuDN99mvhL3YSKNqPXe6Ixayx5VX9tVZAi+ua2nl9STbdsIio lwiBv3A4i/DEw7SMl3hxJfyQs2CE3y7Ix7EDJE85pGGruCY7QD9HpH6KNadmhg2q YMtSymts2f5jy1ZKtdrd9R7oR/Ihw6ZyaUME3qU92igmnAdIOJsDXPVoWQruSsLE 6z0v5rsqQ6Vk+hSUbKEC6Ild80zEuKOcuQW12dHeZI+m6+7duLlvafp9RnKBK0pO bkmJchXcOTwLUUT/Y93zmI2cbPrGwx6Bjkbyv2I5O7asAxDHTJBG6qjBeaLaxrpq 8PoNHnbrfNburNrmt90qCM/5MTT1B1VK+ghoy2vLD0mjf0Y9DQd4WyCyK1+p781Q CdqGh08ptk2VCdnRe8/WBjHIJ4T4FVM43nrDx+86nVXbgmHYhjYF5LPEl1K9svpe loGz64ibwn+UIG/8rZZaYauCzqdgYjGRHtp807khprYzC/KfHI0= =gywM -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP--