Received: by 10.213.65.68 with SMTP id h4csp276217imn; Tue, 20 Mar 2018 03:18:58 -0700 (PDT) X-Google-Smtp-Source: AG47ELs9Z5LJR4eXNKeiLlkQX3zjE1afKV8JAY4RYw9e89xqef6yAgV25mxbDtoTL0xCBaRj4Q0g X-Received: by 10.101.89.6 with SMTP id f6mr11442580pgu.178.1521541138164; Tue, 20 Mar 2018 03:18:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521541138; cv=none; d=google.com; s=arc-20160816; b=nLGa0UyiIGkqpdM+/KWopyALIlS5CBalwfiCu0OPoXLV7hkytEAMccRWUXYKHpfdmI wmomicO886qD/gae75xMKoOC6orhYNJLE1uOTB/q3tpbtNiKdA7dLAQ4TCbuc3vC4ejZ kUB+0rLIN1PZ89wjD3BrrNbUKeIuvfvGWVAxBtOW03/pwH0vN7CFhceJ96E0XrwRvKU4 N9BG2DlhZfH6SqwcvSZU0C8SVYVpAoeFKpttvwNd07xyrVlzHhJkPWXkCv5rjjuIhVvK KiHEF+8M4hHemRN3FeDSsf/IYCv0+3PPm3EyUglVIB09SUN7AfDnDkraZUYWC0bp8v56 9VYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=ak2iQPuvY6HWSqmSKufvbLlWsDROJtSX+FsY1ngzvIs=; b=sMb5im096fizBJZD6DIrtDfEBJIzL8vomT6+Dc/Q2/239k9RgbcrjN/Zvs/yDgg9r2 P1B/QvYkLjer8dEPAMPkLqJJ7GwhNVlLDroFDvrvbhUjl/D5ImR4DMIaSIXg7mTsErIg f1RRMeRMB6tj0ySqN3ugZTTzCilNzTt387NfNsgPYlhxnVBhCX31fef5mpLjke3GR8/l Q3mIwq+P7963E9+jtRYIDI65bqxp1zMTpMLMXyFsnjFoDQkC1GwOXS232PMYgitsHOJl c4JONaEhIQY1dgiydHRQbH4/uf60oKi5NUV+frPidaTP8EFAsM9ze5tAfRgncnAvC06B I3mg== 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 x6-v6si1274233pln.708.2018.03.20.03.18.44; Tue, 20 Mar 2018 03:18:58 -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 S1752618AbeCTKRm (ORCPT + 99 others); Tue, 20 Mar 2018 06:17:42 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:46743 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752097AbeCTKRi (ORCPT ); Tue, 20 Mar 2018 06:17:38 -0400 Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx08-.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w2KADkcK005834; Tue, 20 Mar 2018 11:17:23 +0100 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx08-00178001.pphosted.com with ESMTP id 2grtsg717s-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Mar 2018 11:17:23 +0100 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 794EB56; Tue, 20 Mar 2018 10:17:22 +0000 (GMT) Received: from Webmail-eu.st.com (sfhdag5node2.st.com [10.75.127.14]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 4F0F12554; Tue, 20 Mar 2018 10:17:22 +0000 (GMT) Received: from [10.201.23.236] (10.75.127.50) by SFHDAG5NODE2.st.com (10.75.127.14) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Mar 2018 11:17:21 +0100 Subject: Re: [RESEND PATCH v1 2/6] i2c: i2c-stm32f7: Add slave support To: Wolfram Sang CC: Maxime Coquelin , Alexandre Torgue , , , 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> <20180320095242.tedafu5wphsx55qx@katana> From: Pierre Yves MORDRET Message-ID: Date: Tue, 20 Mar 2018 11:17:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180320095242.tedafu5wphsx55qx@katana> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.50] X-ClientProxiedBy: SFHDAG2NODE3.st.com (10.75.127.6) To SFHDAG5NODE2.st.com (10.75.127.14) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-03-20_04:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/20/2018 10:52 AM, Wolfram Sang wrote: > >> 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. > I need to check at my end but status bits are shared between master and slave in my IP: i.e. Tx Empty, Rx Empty, NAxk, Stop. Both bits have a meaning in either master and slave mode. In your case status bits are separated between master and slave. BTW I need to think about it.