From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60D84C43470 for ; Tue, 6 Apr 2021 13:24:18 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DABF6613E6 for ; Tue, 6 Apr 2021 13:24:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DABF6613E6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wb7a8/HIgKshvyFEciDvjsm+C2fF2eF/4Y58FS9EGKc=; b=VZD42JIVcwSBsUQqovRKeLnOh ZWZdbWwpc/DozHiXR5pp2W7JyAnbWxueegYWX4G6uXd2IKbR6wQ5XjAvhS+P/k3g99gvM8QgymbY5 zRq+wv5oQSbRc69sQPGrEe12PZGM6E9+qH3igNGTmg84TZIoaU9cBswQ74+PXpWBfNsW4XnKNhaYS q1uS7LJoWqTaWXE2YDAO2ZT4SL4roCk8b4IS3SaXVRRXN0Rm4jl4oMYpnjry+LhHLWa8lv69ntNLx MOSPX0u/Akoh5modjicos/7czopGHHowjx4chGhXV7jdj/2uEbpeYKJ811OKqWpJTssNIDR8GvdCJ S1uKNDWjQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lTlev-002grG-MH; Tue, 06 Apr 2021 13:22:22 +0000 Received: from mga09.intel.com ([134.134.136.24]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lTlep-002gq7-Qx for linux-arm-kernel@lists.infradead.org; Tue, 06 Apr 2021 13:22:18 +0000 IronPort-SDR: FqHcxpkG68TH/7OAOK0mtZyuR15+Z4Aifgo7euTR07CQNnGvlz2+7nNkOQ6QESi4yatnbZELyq YbrfWcd2gpKw== X-IronPort-AV: E=McAfee;i="6000,8403,9946"; a="193174386" X-IronPort-AV: E=Sophos;i="5.81,309,1610438400"; d="scan'208";a="193174386" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2021 06:22:09 -0700 IronPort-SDR: 6F6fMunmDKi9b4oJzFoNeL2C2XgciVVaoki4Yi0yYBkg3MnC3shLBS4RGfx56+aCyh0Ck0FUI9 iEnCYrk08FIA== X-IronPort-AV: E=Sophos;i="5.81,309,1610438400"; d="scan'208";a="529807929" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2021 06:22:07 -0700 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1lTlef-001iw4-0G; Tue, 06 Apr 2021 16:22:05 +0300 Date: Tue, 6 Apr 2021 16:22:04 +0300 From: Andy Shevchenko To: Paul Fertser Cc: Ernesto Corona , linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v29 0/6] JTAG driver introduction Message-ID: References: <20200413222920.4722-1-ernesto.corona@intel.com> <20210115104635.GA2971@home.paul.comp> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210115104635.GA2971@home.paul.comp> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210406_142216_428072_E2635E1A X-CRM114-Status: GOOD ( 32.38 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jan 15, 2021 at 01:46:35PM +0300, Paul Fertser wrote: > Hello, > > This is a multi-part review of the series, with general notes inline > in this message, and specific points raised as replies to the > individual patches. > > On Mon, Apr 13, 2020 at 03:29:14PM -0700, Ernesto Corona wrote: > > We propose to implement general JTAG interface and infrastructure > > to communicate with user layer application. > > Working with a Tioga Pass server platform I needed to use the JTAG > master controller of an ASPEED AST2500 SoC to configure a Lattice > LCMXO2-4000HC CPLD. I'm mentioning these fine details because that's > the only proper runtime testing I performed, but my review is not > limited to that. > > Being a long-time OpenOCD community member, I got familiar with many > different facilities and protocols offered by hardware JTAG adapters, > and of wide range of usecases as I was providing end-user > support. This is my perspective when looking at these patches. > > I have to note that the current v29 version of the series is broken in > several aspects: Is it correct that this series is actually abandoned so far? > 1. The aspeed driver fails probe(), see the driver review for details; > > 2. The uapi include header is unusable; > > 3. The offered userspace implementation wasn't updated to the latest > API, but even with the changes to make it compile it's still a mess > too horrible to be used in production; > > Points 1 and 2 will be addressed in separate mails. To workaround > point 3 I prepared a recipe with an additional patch[0] so that > mlnx_cpldprog can be at least compiled and used for some minimal > testing. > > The shortcomings of mlnx_cpldprog are numerous: > > 1. It doesn't consistently choose between hardware and bitbang modes; > > 2. Even though it checks TDO it doesn't print any errors on mismatch > and continues playing back the SVF as if it's all right; > > 3. It has JTAG speed hardcoded; > > 4. It doesn't implement RUNTEST so with the CPLD I'm using it's always > _not_ working properly, failing silently; > > 5. It is just awfully slow, taking about 40 minutes to play back a > file that takes 1.5 minutes with OpenOCD with the same hardware and > kernel driver. > > So I added support for the proposed API to OpenOCD: patch that applies > to the version in OpenBMC[1], patch for the latest version[2]. And > since it can do much more than just playing back SVF I hope this can > highlight some essential API shortcomings if it's meant to be > generic. My impression is that in its current state it's not adequate > for the purpose. > > [0] https://bitbucket.org/paulfertser/mlnx_cpldprog_bitbake > [1] http://openocd.zylin.com/#/c/5976/ > [2] http://openocd.zylin.com/#/c/5975/ -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel