Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp6659190imm; Wed, 27 Jun 2018 11:03:01 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIOsjnJC72oQNRDcsOUxKO1ZUEP34ak6ukqxNRxvfue/AEOigTgJBCMFWa8yt4Kyj2yvFcV X-Received: by 2002:a17:902:3303:: with SMTP id a3-v6mr7176449plc.209.1530122581062; Wed, 27 Jun 2018 11:03:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530122581; cv=none; d=google.com; s=arc-20160816; b=G4r/h+5b5q+IPN8zeQ0orhQvtFnDYMKI31gM5UFyJ/kpR2NodjmnXR0WE5ZlKwgJWo 5S61wnL+53q7LNZXiL+L+yn5YGdsRI4nxpYZp8g5QuVkFjJ8cuMghUHFyFyQKA9g0qj4 AvjlTzHwxBk/200XE+AMvs8mlsVA1g24Sn0KcQOUeuwF42fei49MPbFjpREPphqLaKm0 EKeKsOMMNoePtCNAI/VtU6S7Og8cKUGD7LweCrLXNYAmQQIQOZexha5AiYG84rk0AUDy 7P0NZLyc4D2GI8Oxun02osjd6Fx8KRxoU4uSuyBJxtIs5Dmz9k6gbyLVO1EX4ou9QQgi 5RCg== 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=8aQTQVdviNIcBILHEWPlzuDTw87Apo6Ii8ubiqjCTA8=; b=T4o/70AJOFbZI5/xtZfgXkuQUHVN48xfNZpyP5CmkOHpe6468MLZR7U21jIVyC1l/0 lVOIgnu9SV+KVptq5yCrjTu7SGegKACKYyg17XvjakNfotkJQFnG0pq82pGVDzaOpmPf INudyX/OtyQMDNrPV3IiqBCjgRnqryhxi6DwLLHaz416e1AE45mbk9pMy+empETeDn5q d6065I6ZodFp1eSqX4LSgTaUPjZU4gwdBSGQe+VFzgbJJNsKyWAcuBfrhb5TCynTFI0r 4EVD1xd7O2UuP4po6FhxQWuVB+yI8I2lSM8GwsBxB20u7wuOHi8nF1lDKUE5+ZyHGhzk IVHA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f1-v6si5095197plm.375.2018.06.27.11.02.46; Wed, 27 Jun 2018 11:03:01 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934833AbeF0SB4 (ORCPT + 99 others); Wed, 27 Jun 2018 14:01:56 -0400 Received: from mga14.intel.com ([192.55.52.115]:24946 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934333AbeF0SBz (ORCPT ); Wed, 27 Jun 2018 14:01:55 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2018 11:01:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,280,1526367600"; d="scan'208";a="61936094" Received: from yoojae-mobl1.amr.corp.intel.com (HELO [10.7.153.149]) ([10.7.153.149]) by fmsmga002.fm.intel.com with ESMTP; 27 Jun 2018 11:01:53 -0700 Subject: Re: [PATCH] i2c: aspeed: Improve driver to support multi-master use cases stably To: Jarkko Nikula , Brendan Higgins , Benjamin Herrenschmidt , Joel Stanley , Andrew Jeffery , linux-i2c@vger.kernel.org, openbmc@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org Cc: James Feist , Vernon Mauery References: <20180626165812.4141-1-jae.hyun.yoo@linux.intel.com> <60d0dad1-b735-0650-47b4-40c57b1a5209@linux.intel.com> From: Jae Hyun Yoo Message-ID: Date: Wed, 27 Jun 2018 11:01:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <60d0dad1-b735-0650-47b4-40c57b1a5209@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jarkko, Thanks for the review. Please see my answer below. On 6/27/2018 12:48 AM, Jarkko Nikula wrote: > Hi > > On 06/26/2018 07:58 PM, Jae Hyun Yoo wrote: >> BMC firmware should support some multi-master use cases such as >> multi-node, >> IPMB, BMC-ME link and so on but the current ASPEED I2C driver is a bit >> unstable for the multi-master use case. So this patch improves ASPEED I2C >> driver to support the multi-master use case stably. >> >> Changes: >> * Added XFER_MODE status register checking logic into >>    aspeed_i2c_master_xfer to improve the current bus busy checking logic. >> * Changed the order of enum aspeed_i2c_master_state and >>    enum aspeed_i2c_slave_state defines to make their initial values >> set to >>    ASPEED_I2C_MASTER_INACTIVE and ASPEED_I2C_SLAVE_STOP respectively. >>    In case of multi-master use with previous code, if a slave data comes >>    ahead of the first master xfer, master_state starts from an invalid >>    state. This change fixed the issue. >> * Adjusted spin_lock scope to make it wrap the whole irq handler using >>    a single lock and unlock pair covers both master and slave handlers. >> * Added irq_status variable as a member of the struct aspeed_i2c_bus to >>    collect handled interrupt bits throughout the master and the slave irq >>    handlers. >> * Added control logic to put an order on calling the master and the slave >>    irq handlers based on their current states. >> > This does many unrelated looking changes in one patch making it more > vulnerable for potential multiple regressions. For instance busy > checking goes from single read to loop with 250 ms timeout in this patch > while changing also spin lock logic and interrupt handling. > > Now if there is some regression it might be difficult to find what > change in this patch is causing it and more over things goes more > complicated if some other kind of regressions are found pointing into > the same commit. > > I suggest splitting this into multiple smaller patches. For instance > having first simple conversions patches that are unlikely to cause a > regression like one patch adding '\n' to error print, another moving > irq_status variable into struct aspeed_i2c_bus and so on followed by > patches that change logic like busy checking, spin lock change and then > patch or more for multi-master support. > Yes, that makes sense and I agree with you. I'll split out this patch into multiple smaller patches as you suggested. Thanks, Jae