Received: by 10.223.176.5 with SMTP id f5csp55823wra; Thu, 8 Feb 2018 16:25:22 -0800 (PST) X-Google-Smtp-Source: AH8x2240YbHDzVC1b9Z+KBE5nrAD9HEwzf1Uh/lUpzN5bVzx7Oh4lNYrre/WQSRsUGwMhnd1ULfK X-Received: by 10.98.245.87 with SMTP id n84mr826136pfh.129.1518135922394; Thu, 08 Feb 2018 16:25:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518135922; cv=none; d=google.com; s=arc-20160816; b=E0QVPq1CCjXAeJu0fFp6XGUCmB8RCoH8ebTMUX7Q4jctjqYieAjlNpp+OkTbuZU2v8 7OFus6qg02Ppk6ZV4i2kH2zID9KbfJo7+0Kkcwei5zHUiK4C/PJcW2mrDquZXvo4HIUO o2o39er8qPY1aC8PKCKjU2DPhLrK4C5/Nfbb9SNFhWi1EQef5jZGSc9ztZNes0pqSbGP rIVKXk6XBxcsM/U/2V1kqsXR/geBnwUQUAEqwhMVRd+CHR3vGOsngBtzleLuUz292E6N mxX8pv80HMQbJ88tQleH2sZAsnwvrSwgDPgJGx7lTtcX17iTYIxvlJAZqW0BsGmGdkYM YTBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=r9il1Q3mmbIB3x6SCx1lAdnSzckYYzUAhhufrWINUoY=; b=XoGSrV8jaFRk1idKEJXuQuMkfJvMS3mKtGrwyTGd3BTbfCfJ766eACtIyCZBlhDRrx Y91gbNK74wgY961dW7uUGwv3JK7QDyH5gJe91cNNTY8JDb/I8j91/FCBoOdCsMlNKZGx 4pAxvC6CEMqmOVkLnQF8B6F+rBMqQxZMwEP03nMHjn9zmC2AzOrqrItWxMfgRZwZFtoY LyObz2EXCtIPOJTfSO5wf0JejnCMhlT2dvQpktT3ZOXSus4AeFQkDX8DiFzN7oQPGn4H P0I5HVwGEMPLSY69S4mCPN97QLSi+FxaDCTz5uh5CEct1NwfdetoNRXUkyxTNNTdTuIq ND3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=PAku0CjK; dkim=pass header.i=@codeaurora.org header.s=default header.b=kn+daYun; 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 e12si645676pgu.56.2018.02.08.16.25.08; Thu, 08 Feb 2018 16:25:22 -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; dkim=pass header.i=@codeaurora.org header.s=default header.b=PAku0CjK; dkim=pass header.i=@codeaurora.org header.s=default header.b=kn+daYun; 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 S1752248AbeBIAYT (ORCPT + 99 others); Thu, 8 Feb 2018 19:24:19 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:40254 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750961AbeBIAYR (ORCPT ); Thu, 8 Feb 2018 19:24:17 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 1BDE6601E6; Fri, 9 Feb 2018 00:24:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518135857; bh=kL6W1ZzsjF4+amgJHOj5lCxBk+gqs0otjV8aMvN5cBQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=PAku0CjKQkgse+vNAdp6ZbmHsXZLZxf7L8WVHt99ihO3uUJgCcq+jX7kl0wWERIok tlyUH2SAL7JsDLAUaFY6IGjJIiNmcJ0UsyuHBo4yiZMs7peHDH3CUv4ttGsu7WA5r0 glfvBafedH8ku5GBHAmtJ6rIkrs3LYFIA6ehgXxs= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 6B2EB601E6; Fri, 9 Feb 2018 00:24:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518135856; bh=kL6W1ZzsjF4+amgJHOj5lCxBk+gqs0otjV8aMvN5cBQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kn+daYunGDlb94S0eNn3+va5GyYnreuYtYHECIv5iJ+pUSdmRo0BEJifyWKH//Aar s+NTLqY0iOyzb+uuYt4cVKjFO0W6bJUl+VNb/VSQ0Nx3/2P6lWIHtGth5GEmt1cCc4 eeXb2BopcvlN99xaKFywPKh3KyrwMzbTmAXL1xPs= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 08 Feb 2018 16:24:16 -0800 From: Channa To: Matt Sealey Cc: linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-arm@lists.infradead.org, linux-kernel@vger.kernel.org, tsoni@codeaurora.org, Stephen Boyd , kyan@codeaurora.org, linux-kernel-owner@vger.kernel.org Subject: Re: [PATCH 1/2] dt-bindings: Documentation for qcom,llcc In-Reply-To: References: <1516924513-20183-1-git-send-email-ckadabi@codeaurora.org> <1516924513-20183-2-git-send-email-ckadabi@codeaurora.org> Message-ID: <0ce690ab886d4896506ba916d2d39554@codeaurora.org> X-Sender: ckadabi@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-02-08 08:52, Matt Sealey wrote: > Hiya, > > On 25 January 2018 at 17:55, Channagoud Kadabi > wrote: >> Documentation for last level cache controller device tree bindings, >> client bindings usage examples. > > [snippety snip] > >> +- llcc-bank-off: >> + Usage: required >> + Value Type: >> + Definition: Offsets of llcc banks from llcc base address >> starting from >> + LLCC bank0. >> + >> +- llcc-broadcast-off: >> + Usage: required >> + Value Type: >> + Definition: Offset of broadcast register from LLCC bank0 >> address. > > What's with the redundant namespacing? > > Have we not, as a community, realised that we do not need to namespace > properties which are only present under > a single binding or node, or even those that aren't? This mess started > with the regulator bindings and it's never > stopped. What are we at now, 25 years of device trees, 10 years of FDT > on Arm? > > Notwithstanding the complete waste of rodata in the kernel image for > matching (& increased time to compare), why > wouldn't you consider why "bank-offset" for your node be any different > than a common property for any other node? I will clean up the name space and use bank-offset for the property name. > > And if you need to describe register offsets... why aren't you able to > use the reg property? Reg property did not suit well for my need, so I choose to maintain offsets instead. The registers in the HW block are organized as (offset1) (offset2) (offset3) (offset4) Base(Block0) -- Block1 -- Block 2 -- Block 3 -- Broadcast_Block Each block has identical register mapping. You can think of it as 4 instances of identical HW. Broadcast block is to simplify writes, you don't need to write to individual blocks instead write to broadcast block. I use simple-mfd/syscon as the hardware has multiple functions. Doing regmap on the the Base (Block0) and maintaining offset makes the driver cleaner rather than using the reg property for each instance. > > Ta, > Matt -- -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project