Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1107883imm; Tue, 15 May 2018 14:00:33 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr8+qG7McfwM9H9rTOJWIOqVemP2w2+EPXcselZBV0BOb0WjoLMxxI9J9XK+IxGj4QW84xI X-Received: by 2002:a65:52c8:: with SMTP id z8-v6mr8836912pgp.46.1526418033823; Tue, 15 May 2018 14:00:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526418033; cv=none; d=google.com; s=arc-20160816; b=C4cAwPBlZWcCWzsWj6vz3pr8aV/8suwV1GFox/jV6QQ9FJsZT115dt6Q+XB/gIPVXO XQ/hDClXWClKnCTeXBehE28tIk8tZDqWdIRoAjKFuV3VJ/2KMcK6y3qRuJcrCehOCk5m 9p5/EwW/idrGvkdILG6NklCLr6WXod8fTuizhkMycdxXM2cPPZjycoaHnAFQwyfeQHoj fa/l6zOc8Bxhg5eKyDD1ktVR0+wYMny9iOWVw5qCFg+z25T4a1X+EHR936SBLFLekMZc cQ5ZAakmcyCr+z6UmCZ7BNjdYHwnFOenb9CgQVWPimpWQFmaRXEZ0uIw41Jte03wB+N6 QlqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=j9sl9NJGrODU8bMiyN+yHAfwthgnEbsFVrH/Zmfi9R0=; b=x5/OYsAnrUyw92twBZ8v8ZOOkKwy1yj1GGW5TdG1ZjyUdVlyufJdLXzxK285suZnZP 0OFgVXwqqphAr2FvBlu1UCPFCGXvGFjGKFYfF7yLWG2mp54ajzM9aI41Hup6hlkrDb7T WUz96u9okOhD8zmidzUXG2ZmBV9Fninak+wSnwt5VJxieB8iL/n48USuQeA6EZP8Abf8 2mErBrUNwacPGe4LOmMnImT8u6sLdWxUp0HCgD/8IDu3bSC9NTtQgtqhVi2jRCpBUQ41 6z1sY9Qk/PvUs8dWTM3PmGHYlDNtsHUSkemgSt5s73KoHDynvjPKC+vDbiGZWafL4NpC AifQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KkZV71Z5; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l16-v6si702809pgc.177.2018.05.15.14.00.18; Tue, 15 May 2018 14:00:33 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KkZV71Z5; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752575AbeEOVAG (ORCPT + 99 others); Tue, 15 May 2018 17:00:06 -0400 Received: from mail-qk0-f195.google.com ([209.85.220.195]:35512 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752354AbeEOVAC (ORCPT ); Tue, 15 May 2018 17:00:02 -0400 Received: by mail-qk0-f195.google.com with SMTP id c137-v6so1339375qkg.2; Tue, 15 May 2018 14:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j9sl9NJGrODU8bMiyN+yHAfwthgnEbsFVrH/Zmfi9R0=; b=KkZV71Z5xoV4QZDJQ1rzL/UhryI8WsEKOPyFQ4islzJRYRDJhbaYkacn6VEgEiSCjN ntrABx9gORtG3VRf1rHN6+DxiWbpDqQ25y/FLrqGnS/a75B4wvc8vBV+hJt9rPNXsjvV JFgf34hkiKFXxzHAa0kI+ZV/Kf89MUPs5x3varxCignCCxZ3TZReuCinxiNqlSOWmqcm wEwU+WNShgSb5YUiry19WDa2zwWgV63M6a1k0SpWH6bOPz3CxehxHB45O5cUtUg/5NSD Nlu7tIRt/SvMgK6AX2HF4QmF0I9KVOVXDldWNSWd0psb7IlB7RYcAgElNws804WkujKH oWXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j9sl9NJGrODU8bMiyN+yHAfwthgnEbsFVrH/Zmfi9R0=; b=g26weBzAW4y7C0Y0w7wx66kEd7M1AWZPEwoMUvPYf/nrh2xkm8Ybkgwx/M1mCGKDi6 BVkA3r769PnUvFzL7gErSHZ/pCT7EOp4Uv7bhZYCoXuUPOXb85uumdEk0P3+jdIiMzp/ KmmdHoDQmev9frBv9WsI4mzforAas5i124ajiMzWLj9lNr3pYoR6GEWSqpQhGcb60LUh lhOukjs7iDFkO6TfBDE/hIcM8aJknWJNzpq/WdbB8tjDtWRLhrbTd9ZplFrWH2qwEQ/M 6fLTbB7WPFT1JlzYr04FhDwIFNtapKwtPAPa5i1hT2j6fMDl0LkoXHNSBoynjwrPov9q AH7A== X-Gm-Message-State: ALKqPwf6Z39Z1mKeRyB/HvF2a+yccIfnOJG3bGIjPgt7Hu75FwXPeRUP rjQIRuD4OSDgMo4zFgbgJEcxAfsrLAn7P7MBBoY= X-Received: by 2002:a37:d1d3:: with SMTP id o80-v6mr14384609qkl.3.1526418001153; Tue, 15 May 2018 14:00:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.152.150 with HTTP; Tue, 15 May 2018 14:00:00 -0700 (PDT) In-Reply-To: <1526394095-5069-3-git-send-email-oleksandrs@mellanox.com> References: <1526394095-5069-1-git-send-email-oleksandrs@mellanox.com> <1526394095-5069-3-git-send-email-oleksandrs@mellanox.com> From: Andy Shevchenko Date: Wed, 16 May 2018 00:00:00 +0300 Message-ID: Subject: Re: [patch v21 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver To: Oleksandr Shamray Cc: Greg Kroah-Hartman , Arnd Bergmann , Linux Kernel Mailing List , linux-arm Mailing List , devicetree , openbmc@lists.ozlabs.org, Joel Stanley , =?UTF-8?B?SmnFmcOtIFDDrXJrbw==?= , Tobias Klauser , "open list:SERIAL DRIVERS" , Vadim Pasternak , system-sw-low-level@mellanox.com, Rob Herring , openocd-devel-owner@lists.sourceforge.net, linux-api@vger.kernel.org, "David S. Miller" , Mauro Carvalho Chehab , Jiri Pirko Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 15, 2018 at 5:21 PM, Oleksandr Shamray wrote: > Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller. > > Driver implements the following jtag ops: > - freq_get; > - freq_set; > - status_get; > - idle; > - xfer; > > It has been tested on Mellanox system with BMC equipped with > Aspeed 2520 SoC for programming CPLD devices. > +#define ASPEED_JTAG_DATA 0x00 > +#define ASPEED_JTAG_INST 0x04 > +#define ASPEED_JTAG_CTRL 0x08 > +#define ASPEED_JTAG_ISR 0x0C > +#define ASPEED_JTAG_SW 0x10 > +#define ASPEED_JTAG_TCK 0x14 > +#define ASPEED_JTAG_EC 0x18 > + > +#define ASPEED_JTAG_DATA_MSB 0x01 > +#define ASPEED_JTAG_DATA_CHUNK_SIZE 0x20 > +#define ASPEED_JTAG_IOUT_LEN(len) (ASPEED_JTAG_CTL_ENG_EN |\ > + ASPEED_JTAG_CTL_ENG_OUT_EN |\ > + ASPEED_JTAG_CTL_INST_LEN(len)) Better to read #define MY_COOL_CONST_OR_MACRO(xxx) \ ... > +#define ASPEED_JTAG_DOUT_LEN(len) (ASPEED_JTAG_CTL_ENG_EN |\ > + ASPEED_JTAG_CTL_ENG_OUT_EN |\ > + ASPEED_JTAG_CTL_DATA_LEN(len)) Ditto. > +static char *end_status_str[] = {"idle", "ir pause", "drpause"}; > +static int aspeed_jtag_freq_set(struct jtag *jtag, u32 freq) > +{ > + struct aspeed_jtag *aspeed_jtag = jtag_priv(jtag); > + unsigned long apb_frq; > + u32 tck_val; > + u16 div; > + > + apb_frq = clk_get_rate(aspeed_jtag->pclk); > + div = (apb_frq % freq == 0) ? (apb_frq / freq) - 1 : (apb_frq / freq); Isn't it the same as div = (apb_frq - 1) / freq; ? > + tck_val = aspeed_jtag_read(aspeed_jtag, ASPEED_JTAG_TCK); > + aspeed_jtag_write(aspeed_jtag, > + (tck_val & ASPEED_JTAG_TCK_DIVISOR_MASK) | div, > + ASPEED_JTAG_TCK); > + return 0; > +} > +static void aspeed_jtag_sw_delay(struct aspeed_jtag *aspeed_jtag, int cnt) > +{ > + int i; > + > + for (i = 0; i < cnt; i++) > + aspeed_jtag_read(aspeed_jtag, ASPEED_JTAG_SW); Isn't it readsl() (or how it's called, I don't remember). > +} > +static void aspeed_jtag_wait_instruction_pause(struct aspeed_jtag *aspeed_jtag) > +{ > + wait_event_interruptible(aspeed_jtag->jtag_wq, aspeed_jtag->flag & > + ASPEED_JTAG_ISR_INST_PAUSE); In such cases I prefer to see a new line with a parameter in full. Check all places. > + aspeed_jtag->flag &= ~ASPEED_JTAG_ISR_INST_PAUSE; > +} > +static void aspeed_jtag_sm_cycle(struct aspeed_jtag *aspeed_jtag, const u8 *tms, > + int len) > +{ > + int i; > + > + for (i = 0; i < len; i++) > + aspeed_jtag_tck_cycle(aspeed_jtag, tms[i], 0); > +} > + > +static void aspeed_jtag_run_test_idle_sw(struct aspeed_jtag *aspeed_jtag, > + struct jtag_run_test_idle *runtest) > +{ > + static const u8 sm_pause_irpause[] = {1, 1, 1, 1, 0, 1, 0}; > + static const u8 sm_pause_drpause[] = {1, 1, 1, 0, 1, 0}; > + static const u8 sm_idle_irpause[] = {1, 1, 0, 1, 0}; > + static const u8 sm_idle_drpause[] = {1, 0, 1, 0}; > + static const u8 sm_pause_idle[] = {1, 1, 0}; > + int i; > + > + /* SW mode from idle/pause-> to pause/idle */ > + if (runtest->reset) { > + for (i = 0; i < ASPEED_JTAG_RESET_CNTR; i++) > + aspeed_jtag_tck_cycle(aspeed_jtag, 1, 0); > + } I would rather split this big switch to a few helper functions per each status of surrounding switch. > + > + /* Stay on IDLE for at least TCK cycle */ > + for (i = 0; i < runtest->tck; i++) > + aspeed_jtag_tck_cycle(aspeed_jtag, 0, 0); > +} > +/** > + * aspeed_jtag_run_test_idle: > + * JTAG reset: generates at least 9 TMS high and 1 TMS low to force > + * devices into Run-Test/Idle State. > + */ It's rather broken kernel doc. > + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_CTL_ENG_EN | > + ASPEED_JTAG_CTL_ENG_OUT_EN | > + ASPEED_JTAG_CTL_FORCE_TMS, ASPEED_JTAG_CTRL); > + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_EC_GO_IDLE, > + ASPEED_JTAG_EC); > + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_SW_MODE_EN | > + ASPEED_JTAG_SW_MODE_TDIO, ASPEED_JTAG_SW); Here you have permutations of flag some of which are repeatetive in the code. Perhaps make additional definitions instead. Check other similar places. > + char tdo; Indentation. > + if (xfer->direction == JTAG_READ_XFER) > + tdi = UINT_MAX; > + else > + tdi = data[index]; > + if (xfer->direction == JTAG_READ_XFER) > + tdi = UINT_MAX; > + else > + tdi = data[index]; Take your time to think how the above duplication can be avoided. > + } > + } > + > + tdo = aspeed_jtag_tck_cycle(aspeed_jtag, 1, tdi & ASPEED_JTAG_DATA_MSB); > + data[index] |= tdo << (shift_bits % ASPEED_JTAG_DATA_CHUNK_SIZE); > +} > + if (endstate != JTAG_STATE_IDLE) { Why not to use positive check? > + int i; > + > + for (i = 0; i <= xfer->length / BITS_PER_BYTE; i++) { > + pos += snprintf(&dbg_str[pos], sizeof(dbg_str) - pos, > + "0x%02x ", xfer_data[i]); > + } Oh, NO! Consider reading printk-formats (for %*ph) and other documentation about available APIs. > + if (!(aspeed_jtag->mode & JTAG_XFER_HW_MODE)) { > + /* SW mode */ This is rather too complex to be in one function. > + } else { > + /* hw mode */ > + aspeed_jtag_write(aspeed_jtag, 0, ASPEED_JTAG_SW); > + aspeed_jtag_xfer_hw(aspeed_jtag, xfer, data); For symmetry it might be another function. > + } > + dev_dbg(aspeed_jtag->dev, "status %x\n", status); Perhaps someone should become familiar with tracepoints? > + dev_err(aspeed_jtag->dev, "irq status:%x\n", > + status); Huh, really?! SPAM. (I would drop it completely, though you may use ratelimited variant) > + ret = IRQ_NONE; > + } > + return ret; > +} > + clk_prepare_enable(aspeed_jtag->pclk); This might fail. > + dev_dbg(&pdev->dev, "IRQ %d.\n", aspeed_jtag->irq); Noise even for debug. > + err = jtag_register(jtag); Perhaps we might have devm_ variant of this. Check how SPI framework deal with a such. > +static int aspeed_jtag_remove(struct platform_device *pdev) > +{ > + struct jtag *jtag; > + > + jtag = platform_get_drvdata(pdev); Usually we put this on one line > + aspeed_jtag_deinit(pdev, jtag_priv(jtag)); > + jtag_unregister(jtag); > + jtag_free(jtag); > + return 0; > +} -- With Best Regards, Andy Shevchenko