Received: by 10.213.65.68 with SMTP id h4csp261815imn; Tue, 20 Mar 2018 02:55:00 -0700 (PDT) X-Google-Smtp-Source: AG47ELudLZvgDYH/MQByrDEWKgBAl/wLfE0KPVKQnLN97k7CeBl6AnfVQT6Na38iPgXgkwL8UyTY X-Received: by 10.101.68.82 with SMTP id e18mr11586661pgq.329.1521539700547; Tue, 20 Mar 2018 02:55:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521539700; cv=none; d=google.com; s=arc-20160816; b=MnDX3pBY1TmQ+y/GADTWudpZCnnObQqW0hJPcEs+oLxbuv/1GwDBuPK1XKy5ismkEB aAliIDo1s099CaaKPH71wG3Twb+C71BYUUjVmBzWZcTXV6OFsKgPuFlesnLsnysfgfx+ 2hvM0Avo0HGj2XIlQaIsLch/tdRr5tObiEldCFimR/+UPeuBjggIS7OrIU4Ze/rsJykv BA3n94+7nhOV14Nr4hAs+JIIo1Lq0rYID6C8lRgzmLQhDBCuDR8RYwSt77+HtxQKh+0i ToFKjgvw7GzaRE1o72EwB/Io8mxhDDgFax7Yaje22gCCDqiBip3YTaUvMu0LbUhNBXRw /wsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=/Jb3c43SLI2F2w6d8QCLR8wEo/8nOcRSu4o7QQkTU6A=; b=aw2xF690IPTxqZT4FKT1bT2il2eqK5/4ypZngVVD8kBMad3D5nR0GhW9SyICCllrsr T8Eo5D1BxvOrbxbgX0JXM7epE2QU/oPJgZVUDR6UAawARh84HqcaKWC6VsJDUy4tNOeR 4j2XT74pi01tS4ss2oqWg7vfsdJWzF+7SuUrkQX5SPeQsF8eZffa1EHpIHpmmn0FJ/ZU O2eyo9+es/SZHyKTyqwx531Hk7iSoxZVGoWDSxu4xm8d/fHUWMtJrhGDguuzIPXYshkV jyps7Fh1Nyq6lleC0cg3q6lvJNDD8hJV5rSNEbMAuPSeZNsDGztcIS5mluV/ExKJMCqA V3xA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 15-v6si1168071pla.342.2018.03.20.02.54.43; Tue, 20 Mar 2018 02:55:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752605AbeCTJwr (ORCPT + 99 others); Tue, 20 Mar 2018 05:52:47 -0400 Received: from www.zeus03.de ([194.117.254.33]:46600 "EHLO mail.zeus03.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752597AbeCTJwo (ORCPT ); Tue, 20 Mar 2018 05:52:44 -0400 Received: (qmail 7014 invoked from network); 20 Mar 2018 10:52:42 +0100 Received: from p200300cf5bcb8300021de0fffea0c865.dip0.t-ipconnect.de (HELO localhost) (l3s3148p1@2003:cf:5bcb:8300:21d:e0ff:fea0:c865) by mail.zeus03.de with ESMTPSA (ECDHE-RSA-AES256-GCM-SHA384 encrypted, authenticated); 20 Mar 2018 10:52:42 +0100 Date: Tue, 20 Mar 2018 10:52:42 +0100 From: Wolfram Sang To: Pierre Yves MORDRET Cc: Maxime Coquelin , Alexandre Torgue , linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RESEND PATCH v1 2/6] i2c: i2c-stm32f7: Add slave support Message-ID: <20180320095242.tedafu5wphsx55qx@katana> References: <1520852023-27083-1-git-send-email-pierre-yves.mordret@st.com> <1520852023-27083-3-git-send-email-pierre-yves.mordret@st.com> <20180317205109.gocf5wemtjkyomct@ninjato> <5a3c5b21-bc66-ce73-a997-f686ecc275f3@st.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5jxnagqpgmadd775" Content-Disposition: inline In-Reply-To: <5a3c5b21-bc66-ce73-a997-f686ecc275f3@st.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --5jxnagqpgmadd775 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I do believe the hw can support it, even it looks odd to me having the same I2C > in slave and master mode at the same time. I2C is multi-master, so it is perfectly valid for a device to be master and slave. I do have seen designs making use of that more than once. > Nevertheless the driver is devised to support either master or slave more but > not at the same time. Why should we limit ourselves here? Also, why should we have an unnecessary configuration option? Unless the HW is broken and does not support it, I usually don't accept slave-only solutions. If the needs for master and slave arises later, this is hard to refactor and better done properly right away. Is it so hard? Usually you have irqs for master and for slave seperated, so you can code things quite orthogonal. Check de20d1857dd6 ("i2c: rcar: add slave support") as an example. --5jxnagqpgmadd775 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAlqw2eoACgkQFA3kzBSg KbYyDRAAjXCW/pmeZcMJjdvfYFoNwGZsP22j3BZeEZItjKNlwS5wh8dXRqCHxHkZ XY3c0gph1dMRtw8hvKZwVKhX6s4rQkDs2o7QaNgI1rvgm5i8iZQo23sAjvrsC2cm FKjavVHfwXwarR5Va/5AzZCFHCCPjXt4hKO/7Fs3FbpCi/aw+T2D0q9EUQp6V+f1 ifdzbBKwSaxF3QVSCNRlwQ2s++MU5jq0iwAKB/CWKrFzJ3sZkimIvRdugQ/0PpyG 7gGTon6SCIZNHv68zGX2Iv4FiNmhJCBc2jEjXnUr0eVw/wh0R5guL9Yg+XJe67uT bGVODYb4p/jD4myVy9WGll2DwJhCltHcl+wE/+3TFd+vr2pghsgN0UL9SIhOM+R2 1R9U1a1puIBK5HFTwJTVH3531+2QopOojneoHI9zsjBCpt6Sr0yYZdf8NWP9jk3e +boQuEfr4dUnVazCPpyKwaM5EsdWn4pEysmcCqnePgFd7MVXQ5sB2njx8PA5VEi2 Lhje8MmjKuj7LImLZvp6mEyU5C3V6pBnFNueWKuAxGCHTxSzS+PYq+gAUPLVXUXb fAeouu4ttp3xgURU9Oeq38hAqZjbWYpmriq9ktMOvrZK6NMNp3ncK198qmuZXr7x WxAo04uSBia+ydp8rklNY27v0PH2ZAfCeXTNL6wRPSJkM6HjxDI= =CXbC -----END PGP SIGNATURE----- --5jxnagqpgmadd775--