Received: by 2002:a5d:925a:0:0:0:0:0 with SMTP id e26csp925895iol; Thu, 9 Jun 2022 17:48:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxroMkVaL61//RruQp50GxGbZIMQJGkw7eMzMGKqp3DwvgSvFi7VDNOauKZynqQBB5Wd747 X-Received: by 2002:a05:6402:5306:b0:430:97ab:51f with SMTP id eo6-20020a056402530600b0043097ab051fmr34983648edb.171.1654822130281; Thu, 09 Jun 2022 17:48:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654822130; cv=none; d=google.com; s=arc-20160816; b=KGog6JZKTz/9l3jerFMbjjC4UIAJEQiOFOUK0RlpS9//xh3QtmEFtMtUtcqBoq61TA WCa2HPuZFgiuwa+Uc3bIkQoSEOZn3OEuPC39ARbz6VWopxbBvGP2gDihKkWMwLuNtXJ/ CW+/jMusYljqSq4ah0yD/EyOrWQ2BtkDnNFekmu/H1NX2Sn9uX/r3f+HQBVqBwdfJBKc gDy9qESpdWPuJL3LPBqzoD8fAG2YD2AA7ZhHIXOu2083q5zLwntW6u2q/K4KrDty3rS7 R4+810BDUWLnk19Si7eV6jCJ4IRmx/zGqPGq/rO4n2/vhn98zJFn0hUdc+//TS0wl5/h 9Y4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:dkim-signature; bh=42dVl+dLpD7QSWQsIf+VQkh5WLgD2mgYvKLrXf7Os/g=; b=AZFdJSWJaKo3OYX32oyM7qVtfbXvLfGK8113lACAn88F9/tUbufpHTPU0E20K8XCAG JJbFI/+NCV1dDASHY/ClILLlv9ZSoCW/VVgW4AMBXiV1BbvkGTDZmO8olqjB7Gq/dV89 bpIoGYtKnsQb91fOl9z3LSpg4bEHgWp6anmQQa4KqbwV7jz/qJ9zc/oyPNKxo3rZHIko jBlpf/LlbQlbgdiaM3traK/bknliEu1lxn1MQz1ZocL8NpNt1bekCVphlAfv0FMeqxLh OI6ggut5SReo3MJVAXrI8F6RrHc/N11Ihngr8OpOtf6oFkMjVT4r9/HjkWRS0BUOmgFc z9ZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YhzIx4zX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e11-20020a50ec8b000000b0042df402f255si24269605edr.210.2022.06.09.17.48.24; Thu, 09 Jun 2022 17:48:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YhzIx4zX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235030AbiFJAa6 (ORCPT + 99 others); Thu, 9 Jun 2022 20:30:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46804 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230371AbiFJAa4 (ORCPT ); Thu, 9 Jun 2022 20:30:56 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B08222C12E for ; Thu, 9 Jun 2022 17:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654821052; x=1686357052; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=ElC5/vrGK81B1vG9DhjSFK/X+qtdP0hbu7/JdDZXK94=; b=YhzIx4zXh5Irlq0EAzO2QV94kga0kTWt8HKOyz/0Hpk+opvvn9PvpH8K xoYdYzleho7bzPXwd1RyuNhwFNiirpk+OczTzXTHn+P3Ag7Po+zMjmrVC V8dEdDy4EjMQnke+BwX+RdTccBp2P4FoPKwc6CRuM7GnhpPawpYknI4zx vXxgFykNQDoh75yiDG7jml/0tQe2ri/8m/qelHl9j/6GuQTL9JG7qW03S oBB9C39nSb33acjrcmtyXqD0Xxl9SXFriBi90gcz7/45WYYm8A0uaV0V2 6SjcsMUdXCkRgf/cx4dFhuy+t2BcXft988ORetIv8rIkd3Z8iCUNPPx0g g==; X-IronPort-AV: E=McAfee;i="6400,9594,10373"; a="341533770" X-IronPort-AV: E=Sophos;i="5.91,288,1647327600"; d="scan'208";a="341533770" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2022 17:30:52 -0700 X-IronPort-AV: E=Sophos;i="5.91,288,1647327600"; d="scan'208";a="827901500" Received: from rhweight-wrk1.ra.intel.com ([137.102.106.43]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2022 17:30:51 -0700 Date: Thu, 9 Jun 2022 17:30:43 -0700 (PDT) From: matthew.gerlach@linux.intel.com X-X-Sender: mgerlach@rhweight-WRK1 To: Mark Brown cc: "Zhang, Tianfei" , "gregkh@linuxfoundation.org" , "rafael@kernel.org" , "linux-kernel@vger.kernel.org" , "Wu, Hao" , "trix@redhat.com" , "Xu, Yilun" , "Weight, Russell H" Subject: Re: [PATCH v1] regmap: add generic indirect regmap support In-Reply-To: Message-ID: References: <20220607013755.594554-1-tianfei.zhang@intel.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 9 Jun 2022, Mark Brown wrote: > On Wed, Jun 08, 2022 at 11:54:26PM +0000, Zhang, Tianfei wrote: > >>>> Would a different name help? >>> >>> This wouldn't address the major problem which is... >>> >>>>>> + writel(0, ctx->base + INDIRECT_CMD_OFF); >>>>>> + ret = readl_poll_timeout((ctx->base + INDIRECT_CMD_OFF), cmd, >>>>>> + (!cmd), INDIRECT_INT_US, >>> INDIRECT_TIMEOUT_US); >>>>>> + if (ret) >>>>>> + dev_err(ctx->dev, "%s timed out on clearing cmd 0x%xn", >>>>>> +__func__, cmd); >>> >>>>> ...and this doesn't look particularly generic, it looks like it's >>>>> for some particular controller/bridge? >>> >>> ...that this appears to be entirely specific to some particular device, it's got >>> things like hard coded register addresses and timeouts which mean it can't be >>> reused. >> >> Yet, this is a register access hardware controller/bridge widely used in FPGA IP blocks, like PMCI, HSSI. >> How about we change the patch title like this: > >> regmap: add indirect register controller support > > No, please enage with my feedback above. > Hi Mark, I think part of the confusion is that this patch should have been included in a patch set that actually uses this regmap. This patch really should be included with the following: https://lore.kernel.org/all/20220607032833.3482-1-tianfei.zhang@intel.com The hard coded register definitions are offsets to the passed in void __iomem base address. This set of registers provides the semantics of indirect register read/write to whatever the register set is connected to on the back end. Conceptually this could be considered a specific type indirect register access controller, but currently we have very different backend implementations in RTL. Part of our intent is to have consistent register interfaces for our FPGA IP so multiple drivers can reuse this regmap. I totally agree the hardcoded timeout values used for polling should be parameterized. We would like to submit a v2 patch set that combines this patch with the first consumer of the regmap, PMCI. We would also parameterize the timeout values, but most importantly the name must be better. It is a long name, but how about something like "Intel FPGA Indirect Register Interface"? Matthew Gerlach