Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753640AbdHORyC (ORCPT ); Tue, 15 Aug 2017 13:54:02 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:35960 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753252AbdHORx7 (ORCPT ); Tue, 15 Aug 2017 13:53:59 -0400 Subject: Re: [PATCH v5 0/6] drivers/i2c: Add FSI-attached I2C master algorithm To: Peter Rosin , Christopher Bostic , Joel Stanley Cc: Linux Kernel Mailing List , linux-i2c@vger.kernel.org, devicetree , Wolfram Sang , Rob Herring , Jeremy Kerr , Andrew Jeffery , "Edward A. James" References: <1501089198-10356-1-git-send-email-eajames@linux.vnet.ibm.com> <59175354-07ba-2bbb-962e-ac1de36dfa4a@linux.vnet.ibm.com> <538605fe-f109-b84c-cc21-f1b9824ad5d0@axentia.se> From: Eddie James Date: Tue, 15 Aug 2017 12:53:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <538605fe-f109-b84c-cc21-f1b9824ad5d0@axentia.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-TM-AS-GCONF: 00 x-cbid: 17081517-0024-0000-0000-000002C00033 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007550; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000221; SDB=6.00902762; UDB=6.00452172; IPR=6.00682977; BA=6.00005534; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016707; XFM=3.00000015; UTC=2017-08-15 17:53:56 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17081517-0025-0000-0000-0000451B558D Message-Id: <7802dc48-6850-b7e3-5dbf-ee333cdf0c83@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-15_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708150299 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2961 Lines: 61 On 08/15/2017 12:35 PM, Peter Rosin wrote: > On 2017-08-15 18:28, Christopher Bostic wrote: >> On 8/15/17 3:10 AM, Joel Stanley wrote: >>> On Tue, Aug 15, 2017 at 4:06 PM, Peter Rosin wrote: >>>> On 2017-07-26 19:13, Eddie James wrote: >>>>> From: "Edward A. James" >>>>> >>>>> This series adds an algorithm for an I2C master physically located on an FSI >>>>> slave device. The I2C master has multiple ports, each of which may be connected >>>>> to an I2C slave. Access to the I2C master registers is achieved over FSI bus. >>>>> >>>>> Due to the multi-port nature of the I2C master, the driver instantiates a new >>>>> I2C adapter for each port connected to a slave. The connected ports should be >>>>> defined in the device tree under the I2C master device. >>>> Hmmm, AFAIU fsi is a bus, and on this bus you have some "client" device that >>>> happens to be an i2c master, and this is a driver for that "client". Is it >>>> totally inconceivable to have some other client device in the future that is >>>> implementing an i2c master differently, but still using the fsi bus? >>>> >>>> With that in mind, is it wise to pick the driver name from the bus that the >>>> device is connected to, and nothing else without further qualification? >>>> >>>> I don't see any "i2c-usb" driver, but I think there are a couple of i2c master >>>> drivers that communicate via usb. >>> You make a fair point. When I did a prototype of this driver I called >>> it i2c-cfam, as it is part of the CFAM hardware unit inside of the >>> Power8/Power9 processors. >>> >>> The documentation does call it FSI_I2CM, so that's an argument for the >>> current name. >>> >>> I'm not sure how accurate that name is. Chris, Eddie, do you have any >>> other suggestions? >> The I2C engine up to now has been always accessed via the FSI bus so >> historically I assume that's why its labelled as FSI_I2CM in the p8/p9 >> specs. There isn't any reason this I2C device couldn't be implemented >> in some other topology independent of FSI / CFAMs. In other words there >> are no FSI details internal to this I2C engine, an argument for removing >> the 'FSI' tag. > Note that I wasn't primarily concerned with this i2c engine growing some other > non-fsi interface (like many devices have both i2c and spi interface versions). > I was more concerned with some future and totally different i2c engine that > naturally sports a totally different register map but still uses the fsi bus. > > But you have a point. If this i2c engine evolves and ends up supporting some > other interface, then that too would be cause to regret the i2c-fsi name. i2c-cfam would work, though it would also be possible for another type of i2c engine to exist on a CFAM... it has been done in the past. Historically, this driver was called "iic-boe" for "Boeblingen". I'm not suggesting it's a good name for this driver, but it is unique... Edduie > > Cheers, > peda >