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=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=unavailable 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 35AB6C43381 for ; Tue, 12 Mar 2019 15:45:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0E1012147C for ; Tue, 12 Mar 2019 15:45:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726329AbfCLPpE (ORCPT ); Tue, 12 Mar 2019 11:45:04 -0400 Received: from sauhun.de ([88.99.104.3]:40280 "EHLO pokefinder.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726255AbfCLPpE (ORCPT ); Tue, 12 Mar 2019 11:45:04 -0400 Received: from localhost (p54B335FE.dip0.t-ipconnect.de [84.179.53.254]) by pokefinder.org (Postfix) with ESMTPSA id A876C2C282F; Tue, 12 Mar 2019 16:45:01 +0100 (CET) Date: Tue, 12 Mar 2019 16:45:01 +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: <20190312154501.6v2symbq6eutp6dj@ninjato> References: <20190302134735.4393-1-wsa+renesas@sang-engineering.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zkokbbl47s6o5i5w" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-renesas-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org --zkokbbl47s6o5i5w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > So, finally, here is the second RFC for supporting I2C transfers in ato= mic > > contexts (i.e. very late). This will need some text because I tried som= e things > > on the way but had to discard them. However, I think it is important to= have > > that documented. >=20 > > Sorry, no TLDR; text here - I think this topic deserves a few words ;) >=20 > Thank you for this work! It was indeed interesting reading. Thanks, glad to hear that :) > And since your series is targetting some exiting use cases, I would > drop as well academic variants of brain-damaged hw design, I think it > worth to go. Well, yes and no. I am with you that some complicated muxed setups could be argued to be way over the top. However, with the panic fault-injector, I can get my simple "PMIC directly (even exclusively) attached to root adapter" setup to stall. By simply ignoring the lock, such setups could work again. But this series does not implement this because it would need a redesign, i.e. tie into i2c_transfer and not later in __i2c_transfer. Yet, before doing this, I was interested in discussion if ignoring the lock is really desirable. This series seems like a valid approach to me if we still want to respect the locking. --zkokbbl47s6o5i5w Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAlyH0/0ACgkQFA3kzBSg Kbb02g//bFuyt6ZF0xKTx4YGhpVUmqDkQpdYzmFvXr2J4/UUeL43QsGvO4P05zuh in13OeiEaWgo1tnE6u9E+DrzEDzPNRiTwER4SB24KbymIncuoyNhBE0UIbuglcbE j1XUxgKQMl4YhZuTKGWZVuBCFaPty4vSxSzjrYgE2pk59ETbZiKOplCkklTHhfVX u77k21N3rO8DJpqhRAsEc2hA5hIH8PTw/TfDlwC6/QQNmHZDHxBS7Ae6t36mkhSS jHhI17n+oXL/WJqcQp0vPaU7rXuS8ZMw9VuoB/djEuZC7POxydKERicPKUKpcM8x iFBWBP370FOQGXxOnCUrwz6j9cooR3D7frKliTmQYWn3WKf1mf7lcW1cVqpxzp5h U+PbpWwI1ZmqixC2XhNfhmKuWaLfIcCj0UacaSge0Fya+P1nIg+RSnm0OBuMa0uW wKrVXMKUPcDY8IFcqygQE0kkmPnws5kQI1/mN62efcLmI5+Z/zNNx+y1Axyv8Mq8 dteeml5Ig8tiRzUDLBmCv/MYMDEJTi4guZe7NLPCz04Z8TGMgXtp0bkoFM5TRwET iWl3w9okHcetxUO8Mf2RkS80p6yy0b0B1Z9ND4IjcSkvunXxRl+ygtwjHtd68iZK ujH2j4D5SGLXuygLnSsjpJXRzN+FjoXnuF1Y880JSCoNhJ6aL0c= =rDLe -----END PGP SIGNATURE----- --zkokbbl47s6o5i5w--