Received: by 2002:a05:6a10:eb0a:0:0:0:0 with SMTP id hx10csp1085502pxb; Fri, 4 Mar 2022 13:59:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJy62Lz4lhsyjdkiKJeBX9/9ol4RlFG0u4CQ6hN+YUdBdhEqN71WtTaTmBaHyqif0eFzfmpZ X-Received: by 2002:aa7:8318:0:b0:4f6:ba8c:17d6 with SMTP id bk24-20020aa78318000000b004f6ba8c17d6mr785767pfb.56.1646431153287; Fri, 04 Mar 2022 13:59:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646431153; cv=none; d=google.com; s=arc-20160816; b=c7V3Zfj8lyxeNZtGWIEPUi8BcbVdzw5VmqGvuj/Us0lxR5CpCwxGhMrM8B4tbWb6UP nfXIJRu0e7O0P0qBzdtGu5otfbHoSQFdg3DPo4A6Gw8AueC1JZhRJxdvlACV8JX0gBPh UoCrXGLIkBuLy/4TN5G4nDFFMxsFCk8RPK1jxbRw6nMEa7yuRXDx6aYrwWIpl8mgsPre Ykyb+XiPshoEZh3rWF4eXRmZnLT+Zc/NFEb/CKKHLrZe0BTiBwUNQQUHKYBLO9FrVyVe /cUzPknmhYa3qct1SM+Ac+mzbfs16BwDAaA+Fj63nhA2TrJfnvGmI4NhgzvbkwHUptv5 sITQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=ntN3yl5eMGGkiNg9DiYAf56yeIsPRxv4Lrtu44Q+nhs=; b=GBfaVeAQsLhJM1a8TOIbaDQnV2clNsJtfhL9HbkvR1lWXzIK7AZaB4oUbSlYaXEnYz QaAAS3+oVFnfO8vFnD2ZgilQIwo9JSKwfjBSBKDzsQcE5pd7t4bYI5CfA51P52CuCi/L AbbNG/81j1u6GE67KEVWJ3EiXIjWZ4So9FWWeS2zNCbeNByBPfIEPF295ebEOHwAWdvP MGX2m8FtoCD5OjJFRlURIJ/K5KZFAUflAwGLEuyyr/Lirnq0xAHPGZEXHG4NY13UAVOs OWAtkG06/DZ5Op3zhVR6ldabSOy48jHW2pg22UwHHvEDa9qkODIX2FIkGecVFDU4W2I3 FZ9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=Hl3mzwXm; 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=quicinc.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x71-20020a63864a000000b0037cecf71363si2138232pgd.287.2022.03.04.13.58.57; Fri, 04 Mar 2022 13:59:13 -0800 (PST) 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=@quicinc.com header.s=qcdkim header.b=Hl3mzwXm; 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=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229869AbiCDVrw (ORCPT + 99 others); Fri, 4 Mar 2022 16:47:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229468AbiCDVrv (ORCPT ); Fri, 4 Mar 2022 16:47:51 -0500 Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B517B2364FC; Fri, 4 Mar 2022 13:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1646430422; x=1677966422; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=ntN3yl5eMGGkiNg9DiYAf56yeIsPRxv4Lrtu44Q+nhs=; b=Hl3mzwXmyn7UZ3Re6DZnon2qX+15LRIqtA20sMq0KETBexMSJnTKFIBC GOUfEM/tYqkbSy6ua6I8nikXXkiDXsmBKym0LkAwA0RIkpgf0KfU9NZRU LIktaZz61LF7LDvIjdOIzBlbrECCDyZhy82aMVuAOX4I8OiIvd01kcOW6 0=; Received: from unknown (HELO ironmsg01-sd.qualcomm.com) ([10.53.140.141]) by alexa-out-sd-01.qualcomm.com with ESMTP; 04 Mar 2022 13:47:01 -0800 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg01-sd.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2022 13:47:01 -0800 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.15; Fri, 4 Mar 2022 13:47:01 -0800 Received: from [10.226.58.18] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.15; Fri, 4 Mar 2022 13:46:59 -0800 Message-ID: Date: Fri, 4 Mar 2022 14:46:59 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH v3 08/25] bus: mhi: ep: Add support for registering MHI endpoint controllers Content-Language: en-US To: Manivannan Sadhasivam , Alex Elder CC: , , , , , , , , , , References: <20220212182117.49438-1-manivannan.sadhasivam@linaro.org> <20220212182117.49438-9-manivannan.sadhasivam@linaro.org> <4cc78936-b419-4738-b5b2-65c53be06f33@linaro.org> <20220217095319.GA11964@workstation> From: Jeffrey Hugo In-Reply-To: <20220217095319.GA11964@workstation> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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 2/17/2022 2:53 AM, Manivannan Sadhasivam wrote: > On Tue, Feb 15, 2022 at 02:02:41PM -0600, Alex Elder wrote: > > [...] > >>> +#define MHI_REG_OFFSET 0x100 >>> +#define BHI_REG_OFFSET 0x200 >> >> Rather than defining the REG_OFFSET values here and adding >> them to every definition below, why not have the base >> address used (e.g., in mhi_write_reg_field()) be adjusted >> by the constant amount? >> >> I'm just looking at mhi_init_mmio() (in the existing code) >> as an example, but for example, the base address used >> comes from mhi_cntrl->regs. Can you instead just define >> a pointer somewhere that is the base of the MHI register >> range, which is already offset by the appropriate amount? >> > > I've defined two set of APIs for MHI and BHI read/write. They will add the > respective offsets. > While you are making changes, maybe don't have a set BHI_REG_OFFSET? Sure, I think it is always 0x200, but that is a convention and nothing I've seen in the spec mandates it. You can derive it from the bhi offset register. This way, if it ever moves in some future chip, this code should just work.