Received: by 10.223.185.116 with SMTP id b49csp517907wrg; Fri, 23 Feb 2018 02:27:31 -0800 (PST) X-Google-Smtp-Source: AH8x224FEoS/iqvpImbUOC92/VQ2w0Urjdy34JpTHg8kjsdVpQxcaosnkw5L8yJoHx4XCrcAXT08 X-Received: by 10.99.127.69 with SMTP id p5mr1066837pgn.346.1519381651370; Fri, 23 Feb 2018 02:27:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519381651; cv=none; d=google.com; s=arc-20160816; b=Pb0WklLRVfRn8nr3Ffa2hBPp5LhNHhyeWDqdcfVYYQ95mkRW5nC5DVC8LhEIpA+nhu sulojjUCgZb9tFQgCsNfHzjycdZR8eMe/wP9PFdv0fPT2qBmKxomN6UisCTPeVWvO5b3 ePJMOE/C7R50YKBrOtqH5MZST+5m839L2EWekWFq5QIUlDpjUUx5+/VcAjU8G7eGUwRb 0y9fXDoz2DkPuZLdC1Ueuzi010e4KR/3Tk7/uDMnRUz9Nbswad6LYLbV2zCL6MAGTW4N EeZz2W6F0nYbjGDclGBDjljGycURDOWpL/jsWZdoqHKuJ1AbLc7oVKeHan297KoyLM2z bNiA== 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:mime-version :organization:references:in-reply-to:date:to:from:subject:message-id :arc-authentication-results; bh=q/CITCxFlgqvPU9qAPcWAJD+MjCohAXL7WwQQys8EEA=; b=dE/aWQtVVbStsqHiX6pgE64sgcqAY0Hu9SCu4EIS4Q/VSD2CAL/Yaj8+pH4+ayZyt4 nY+KvpRQz/Xm37eqdM3czfhN1XWtkiIGX97K6lR3B43p9lJxT4uOr37+J2ayAMaPLeRo OTe1DhN4H1ku7byMo1jC5L4FJoZ5uev6egSzfyNxlX3kbdwwCnMHpIlDwD7dL41GFb3q D19MAQsCHreQcPC484HQnzq1vhaLDa1F7QNZTlMM50Dm0w1+0BUr8fAv1wsOCvOeG8oF ipy5am8/NPqFsjFkQOAWNPc3DGqFjqeWBR6Qw45BwMDBpg4y5aNMLnpml6+uc7lJKjFu o4LQ== 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 b13si1605109pfi.53.2018.02.23.02.27.17; Fri, 23 Feb 2018 02:27:31 -0800 (PST) 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 S1751845AbeBWKZl (ORCPT + 99 others); Fri, 23 Feb 2018 05:25:41 -0500 Received: from mga14.intel.com ([192.55.52.115]:48791 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751800AbeBWKZj (ORCPT ); Fri, 23 Feb 2018 05:25:39 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2018 02:25:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,382,1515484800"; d="scan'208";a="206378503" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.86]) by fmsmga005.fm.intel.com with ESMTP; 23 Feb 2018 02:25:36 -0800 Message-ID: <1519381535.10722.99.camel@linux.intel.com> Subject: Re: [PATCH arm/aspeed/ast2500 v2] eSPI: add ASPEED AST2500 eSPI driver to boot a host with PCH runs on eSPI From: Andy Shevchenko To: Haiyue Wang , joel@jms.id.au, andrew@aj.id.au, arnd@arndb.de, gregkh@linuxfoundation.org, openbmc@lists.ozlabs.org, linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org Date: Fri, 23 Feb 2018 12:25:35 +0200 In-Reply-To: <1519369459-12468-1-git-send-email-haiyue.wang@linux.intel.com> References: <1519369459-12468-1-git-send-email-haiyue.wang@linux.intel.com> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.5-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-02-23 at 15:04 +0800, Haiyue Wang wrote: > When PCH works under eSPI mode, the PMC (Power Management Controller) > in > PCH is waiting for SUS_ACK from BMC after it alerts SUS_WARN. It is in > dead loop if no SUS_ACK assert. This is the basic requirement for the > BMC > works as eSPI slave. So, do we have an agreement that the driver should go in this shape w/o interacting with SPI subsystem? Also few comments below. > +config ASPEED_ESPI_SLAVE > + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP_MMIO I would rather split this to two depends on REGMAP_MMIO depends on ARCH_ASPEED || COMPILE_TEST > + tristate "Aspeed ast2500 eSPI slave device driver" > + ---help--- > + Control Aspeed ast2500 eSPI slave controller to handle > event > + which needs the firmware's processing. > +#include What exactly requires this header? > +static int aspeed_espi_slave_probe(struct platform_device *pdev) > +{ > + struct aspeed_espi_slave_data *priv; > + struct device *dev = &pdev->dev; > + struct resource *res; > + void __iomem *regs; > + int rc; > + > + dev_set_name(dev, DEVICE_NAME); Do this after checks and memory allocations. > + > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + regs = devm_ioremap_resource(dev, res); > + if (IS_ERR(regs)) > + return PTR_ERR(regs); > + > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); > + if (!priv) > + return -ENOMEM; > + > + priv->map = devm_regmap_init_mmio(dev, regs, > &espi_slave_regmap_cfg); > + if (IS_ERR(priv->map)) > + return PTR_ERR(priv->map); > + > +static const struct of_device_id of_espi_slave_match_table[] = { > + { .compatible = "aspeed,ast2500-espi-slave" }, > + { } > +}; > +MODULE_DEVICE_TABLE(of, of_espi_slave_match_table); This one should be closer to the struct of_device_id. -- Andy Shevchenko Intel Finland Oy