Received: by 10.223.185.116 with SMTP id b49csp776196wrg; Tue, 20 Feb 2018 07:42:28 -0800 (PST) X-Google-Smtp-Source: AH8x227nO7TZgm2PnJuRz21tVWKNWKX3coMqRe2+2gUjui/A18fBEGA1SZHr02VGYiyF/6S8Pfbb X-Received: by 10.99.114.18 with SMTP id n18mr25737pgc.169.1519141348287; Tue, 20 Feb 2018 07:42:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519141348; cv=none; d=google.com; s=arc-20160816; b=wbun/LgGpFtFVykhmbz96hYajhOscGB1vKxnrUaKqX5YiagKufEu9h3JYpxOdVW3B4 P7BwzjGvMVVRFbPTRB7xzVQGC5kN4sZ1Y9j6b3R5okq5jO3fkgG3VBPh98lATLtpY6GP 6qacMZABhT5tDOeKY3JDOu6+2PpNdgd+DUeHwHKTSTJ8XA2bqryZOh4a872786+6WZXR 1vHUM7U042CXQanAoB4LQK1sPYNSIF+LSFsgNqxKjHY/gObce+k7zBXJzi4lLEy7lykA VrISUOnR96BfbAG4LAgxwomwqaAuV5owlcukSqZU7Sje7XUuF95vwzqftDMCrHo158Cp LbQA== 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:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=Kxz7xDrcQ3IlDsJhyexUQYJ/0avRxvC51jtFoMWWQzA=; b=smttBXQdWuE7dTkhNKLCOFFzXf+iBy0wyP34rJpUdvyBNnllcjK7/MDTKHsMFU6I+Q rTh3yoPDEx0YdjkEZEu94QgyVF8P1HfafcubVTbdcdfW5LAJEtEO1ddhlAqkcYkttXkS MWru0SUIuYfuh9UQq3ITAVB2YJ232sYoL4YcxxwEJ+AKEYWWzpTHdLB96+b26Hyx1zny QQMLbTVfyknkQUCxCP+tpaNhSx3eWUWZ8IvUz+ItdMY5Qw1CN1dQynVW2grOdOUdGoVm EnmaJTNWdAu+Z9CnKN0D70qSm36PMDVWK/2CpTzaF106Cg5c/Jqxh2Zv1Z7IinrAgv5L GZYw== 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 j73si6744632pgc.566.2018.02.20.07.42.13; Tue, 20 Feb 2018 07:42:28 -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 S1752554AbeBTPk0 (ORCPT + 99 others); Tue, 20 Feb 2018 10:40:26 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:37468 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752313AbeBTPkX (ORCPT ); Tue, 20 Feb 2018 10:40:23 -0500 Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id B7C14A6777900; Tue, 20 Feb 2018 23:40:14 +0800 (CST) Received: from [127.0.0.1] (10.202.227.238) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.361.1; Tue, 20 Feb 2018 23:40:06 +0800 Subject: Re: [PATCH v14 6/9] HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindings To: Andy Shevchenko References: <1519062520-198902-1-git-send-email-john.garry@huawei.com> <1519062520-198902-7-git-send-email-john.garry@huawei.com> CC: Mika Westerberg , "Rafael J. Wysocki" , Lorenzo Pieralisi , "Rafael J. Wysocki" , Hanjun Guo , "Rob Herring" , Bjorn Helgaas , "Arnd Bergmann" , Mark Rutland , Olof Johansson , Dann Frazier , Rob Herring , Joe Perches , Benjamin Herrenschmidt , , "Linux Kernel Mailing List" , ACPI Devel Maling List , Linuxarm , Corey Minyard , devicetree , Linux-Arch , Randy Dunlap From: John Garry Message-ID: Date: Tue, 20 Feb 2018 15:39:55 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.238] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/02/2018 14:50, Andy Shevchenko wrote: > On Mon, Feb 19, 2018 at 7:48 PM, John Garry wrote: >> From: Zhichang Yuan >> >> The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in >> I/O port addresses. This patch implements the LPC host controller driver >> which perform the I/O operations on the underlying hardware. >> We don't want to touch those existing peripherals' driver, such as ipmi-bt. >> So this driver applies the indirect-IO introduced in the previous patch >> after registering an indirect-IO node to the indirect-IO devices list which >> will be searched in the I/O accessors to retrieve the host-local I/O port. >> >> The driver config is set as a bool instead of a trisate. The reason >> here is that, by the very nature of the driver providing a logical >> PIO range, it does not make sense to have this driver as a loadable >> module. Another more specific reason is that the Huawei D03 board >> which includes hip06 SoC requires the LPC bus for UART console, so >> should be built in. > Hi Andy, >> +config HISILICON_LPC >> + bool "Support for ISA I/O space on Hisilicon hip06/7" >> + depends on (ARM64 && (ARCH_HISI || COMPILE_TEST)) > > Redundant parens. OK, these can be removed > >> + select INDIRECT_PIO >> + help >> + Driver needed for some legacy ISA devices attached to Low-Pin-Count >> + on Hisilicon hip06/7 SoC. > > > >> +#if LPC_MAX_DULEN > LPC_MAX_BURST >> +#error "LPC.. MAX_DULEN must be not bigger than MAX_OPCNT!" >> +#endif > > But here you can easily avoid an #error, by making them equal, just > issue a warning instead. These values are dictated by the HW. Well the burst length is. Regardless I have simplified the driver not to use the burst mode so I can remove. > >> +#if LPC_MAX_BURST % LPC_MAX_DULEN >> +#error "LPC.. LPC_MAX_BURST must be multiple of LPC_MAX_DULEN!" >> +#endif > > Is it like this, or also should be power of two? > As above >> +/* The command register fields */ >> +#define LPC_CMD_SAMEADDR 0x08 >> +#define LPC_CMD_TYPE_IO 0x00 > >> +#define LPC_CMD_WRITE 0x01 >> +#define LPC_CMD_READ 0x00 >> +/* the bit attribute is W1C. 1 represents OK. */ >> +#define LPC_STAT_BYIRQ 0x02 > > BIT() ? Not all, but I'll fix them up to be clearer > >> +#define LPC_STATUS_IDLE 0x01 >> +#define LPC_OP_FINISHED 0x02 >> + >> +#define LPC_START_WORK 0x01 > > Ditto? > >> +static inline int wait_lpc_idle(unsigned char *mbase, >> + unsigned int waitcnt) { >> + u32 opstatus; >> + >> + while (waitcnt--) { >> + ndelay(LPC_NSEC_PERWAIT); >> + opstatus = readl(mbase + LPC_REG_OP_STATUS); >> + if (opstatus & LPC_STATUS_IDLE) >> + return (opstatus & LPC_OP_FINISHED) ? 0 : (-EIO); >> + } >> + return -ETIME; > > Personally I prefer timeout loops in a do {} while (--count) style. OK, I think it's fine to change as mentioned > >> +} > >> +static int >> +hisi_lpc_target_in(struct hisi_lpc_dev *lpcdev, struct lpc_cycle_para *para, >> + unsigned long addr, unsigned char *buf, >> + unsigned long opcnt) >> +{ >> + unsigned int cmd_word; >> + unsigned int waitcnt; >> + unsigned long flags; >> + int ret; >> + >> + if (!buf || !opcnt || !para || !para->csize || !lpcdev) >> + return -EINVAL; > >> + >> + cmd_word = LPC_CMD_TYPE_IO | LPC_CMD_READ; >> + waitcnt = LPC_PEROP_WAITCNT; >> + if (!(para->opflags & FG_INCRADDR_LPC)) { >> + cmd_word |= LPC_CMD_SAMEADDR; >> + waitcnt = LPC_MAX_WAITCNT; >> + } >> + > >> + ret = 0; >> + > > Sounds redundant. it is, so I'll fix > >> + /* whole operation must be atomic */ >> + spin_lock_irqsave(&lpcdev->cycle_lock, flags); >> + >> + writel_relaxed(opcnt, lpcdev->membase + LPC_REG_OP_LEN); >> + >> + writel_relaxed(cmd_word, lpcdev->membase + LPC_REG_CMD); >> + >> + writel_relaxed(addr, lpcdev->membase + LPC_REG_ADDR); >> + >> + writel(LPC_START_WORK, lpcdev->membase + LPC_REG_START); >> + >> + /* whether the operation is finished */ >> + ret = wait_lpc_idle(lpcdev->membase, waitcnt); > >> + if (!ret) { > > I would rather go with usual pattern > if (ret) { > ... > return ret; > } > The intention was to not have 2 calls to free the spinlock. But we can go with the usual pattern. > >> + for (; opcnt; opcnt--, buf++) >> + *buf = readb(lpcdev->membase + LPC_REG_RDATA); > > Looks like a do {} while (slightly better for my opinion). > > do { > *buf++ = readb(lpcdev->membase + LPC_REG_RDATA); > } while (--opcnt); > ok >> + } >> + >> + spin_unlock_irqrestore(&lpcdev->cycle_lock, flags); >> + >> + return ret; >> +} > >> + for (; opcnt; buf++, opcnt--) >> + writeb(*buf, lpcdev->membase + LPC_REG_WDATA); > > Ditto. > Ditto >> +static u32 hisi_lpc_comm_in(void *hostdata, unsigned long pio, size_t dwidth) > >> + if (!lpcdev || !dwidth || dwidth > LPC_MAX_DULEN) >> + return -1; > > ~0 ? > I need to check the patchset for all of these :) >> + if (ret) >> + return -1; > > Ditto. > >> + do { >> + int ret; >> + >> + ret = hisi_lpc_target_in(lpcdev, &iopara, addr, >> + buf, dwidth); >> + if (ret) >> + return ret; >> + buf += dwidth; > >> + count--; >> + } while (count); > > } while (--count); > >> + do { >> + if (hisi_lpc_target_out(lpcdev, &iopara, addr, buf, >> + dwidth)) >> + break; >> + buf += dwidth; >> + count--; >> + } while (count); > > Ditto. ok, we can use the do-while loop > >> +static int hisi_lpc_probe(struct platform_device *pdev) >> +{ >> + struct device *dev = &pdev->dev; >> + struct acpi_device *acpi_device = ACPI_COMPANION(dev); >> + struct logic_pio_hwaddr *range; >> + struct hisi_lpc_dev *lpcdev; >> + struct resource *res; > >> + int ret = 0; > > Redundant assignment. Right > >> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > >> + if (!res) >> + return -ENODEV; > > Redundant. > Right, devm_ioremap_resource() can deal with res = NULL. >> + >> + lpcdev->membase = devm_ioremap_resource(dev, res); >> + if (IS_ERR(lpcdev->membase)) { > >> + dev_err(dev, "remap failed\n"); > > Redundant. right, an error is printed in devm_ioremap_resource() > >> + return PTR_ERR(lpcdev->membase); >> + } > >> + /* register the LPC host PIO resources */ > >> + if (!acpi_device) >> + ret = of_platform_populate(dev->of_node, NULL, NULL, dev); > >> + if (ret) { > >> + dev_err(dev, "populate children failed (%d)\n", ret); > > JFYI: ret is printed by device core if ->probe() fails. OK, so then this is superfluous > >> + return ret; >> + } > > This condition should go under if (!acpi_device) case. > Thanks, John