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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 DABD6C43381 for ; Mon, 1 Apr 2019 16:36:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B3E0420883 for ; Mon, 1 Apr 2019 16:36:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728700AbfDAQgF (ORCPT ); Mon, 1 Apr 2019 12:36:05 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:37522 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727021AbfDAQgF (ORCPT ); Mon, 1 Apr 2019 12:36:05 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D3C1CA78; Mon, 1 Apr 2019 09:36:04 -0700 (PDT) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DDDB83F690; Mon, 1 Apr 2019 09:36:02 -0700 (PDT) Subject: Re: [PATCH 1/2] edac: sifive: Add DT documentation for SiFive L2 cache Controller To: Rob Herring Cc: Yash Shah , linux-riscv@lists.infradead.org, linux-edac@vger.kernel.org, Palmer Dabbelt , Paul Walmsley , "linux-kernel@vger.kernel.org" , Mark Rutland , Albert Ou , Borislav Petkov , Mauro Carvalho Chehab , devicetree@vger.kernel.org References: <1552382461-13051-1-git-send-email-yash.shah@sifive.com> <1552382461-13051-2-git-send-email-yash.shah@sifive.com> <20190328131657.GA9056@bogus> From: James Morse Message-ID: <8e574cfa-29d9-0f0a-d670-c4869bd262c4@arm.com> Date: Mon, 1 Apr 2019 17:36:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, On 29/03/2019 14:11, Rob Herring wrote: > On Thu, Mar 28, 2019 at 1:47 PM James Morse wrote: >> On 28/03/2019 13:16, Rob Herring wrote: >>> On Tue, Mar 12, 2019 at 02:51:00PM +0530, Yash Shah wrote: >>>> DT documentation for L2 cache controller added. >>>> diff --git a/Documentation/devicetree/bindings/edac/sifive-edac-l2.txt b/Documentation/devicetree/bindings/edac/sifive-edac-l2.txt >>>> new file mode 100644 >>>> index 0000000..abce09f >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/edac/sifive-edac-l2.txt >>>> @@ -0,0 +1,31 @@ >>>> +SiFive L2 Cache EDAC driver device tree bindings >>>> +------------------------------------------------- >>>> +This driver uses the EDAC framework to report L2 cache controller ECC errors. >>> >>> Bindings are for h/w blocks, not drivers. (And Boris may want a single >>> driver, but bindings should reflect the h/w, not what Linux (currently) >>> wants. >> >> For h/w block compatibles and edac, I think all we need now is to ensure the DT contains >> the three compatible strings: platform (if there is one), soc and ip-name (if its a >> re-usable thing). >> This is so that linux can pick the biggest of the three (usually platform) to probe the >> driver from, as this lets us capture platform properties we only find out about later. > > DT is not the only what to instantiate drivers. If the OS really wants > to have a single driver for multiple h/w blocks, then it needs to > instantiate a driver itself (based on the top-level compatible > probably) and then that driver can find the DT nodes it needs itself. I think this is where we are heading. (but I need to get my head round this top-level thing). Can the OS do both, depending on the platform? e.g. on a system with one component the driver runs 'standalone', whereas on a bigger system with multiple components the same driver is used as a library by something else. I don't see how this would work if the common component's DT entry looks the same on both platforms. Wouldn't this depend on the order stuff is done in, or 'but not this one' checks in the driver? > In any case, it's all irrelevant to the DT binding. We don't design > bindings around what some particular OS wants. I agree. What we want to do is spot the problems on the horizon so we either have the right information in the DT today, or at least know what it looks like so we don't cause a regression when a new platform makes previous behaviour generic/a-library. Thanks, James From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [1/2] edac: sifive: Add DT documentation for SiFive L2 cache Controller From: James Morse Message-Id: <8e574cfa-29d9-0f0a-d670-c4869bd262c4@arm.com> Date: Mon, 1 Apr 2019 17:36:01 +0100 To: Rob Herring Cc: Yash Shah , linux-riscv@lists.infradead.org, linux-edac@vger.kernel.org, Palmer Dabbelt , Paul Walmsley , "linux-kernel@vger.kernel.org" , Mark Rutland , Albert Ou , Borislav Petkov , Mauro Carvalho Chehab , devicetree@vger.kernel.org List-ID: SGkgUm9iLAoKT24gMjkvMDMvMjAxOSAxNDoxMSwgUm9iIEhlcnJpbmcgd3JvdGU6Cj4gT24gVGh1 LCBNYXIgMjgsIDIwMTkgYXQgMTo0NyBQTSBKYW1lcyBNb3JzZSA8amFtZXMubW9yc2VAYXJtLmNv bT4gd3JvdGU6Cj4+IE9uIDI4LzAzLzIwMTkgMTM6MTYsIFJvYiBIZXJyaW5nIHdyb3RlOgo+Pj4g T24gVHVlLCBNYXIgMTIsIDIwMTkgYXQgMDI6NTE6MDBQTSArMDUzMCwgWWFzaCBTaGFoIHdyb3Rl Ogo+Pj4+IERUIGRvY3VtZW50YXRpb24gZm9yIEwyIGNhY2hlIGNvbnRyb2xsZXIgYWRkZWQuCgo+ Pj4+IGRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvZWRhYy9z aWZpdmUtZWRhYy1sMi50eHQgYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvZWRh Yy9zaWZpdmUtZWRhYy1sMi50eHQKPj4+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NAo+Pj4+IGluZGV4 IDAwMDAwMDAuLmFiY2UwOWYKPj4+PiAtLS0gL2Rldi9udWxsCj4+Pj4gKysrIGIvRG9jdW1lbnRh dGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2VkYWMvc2lmaXZlLWVkYWMtbDIudHh0Cj4+Pj4gQEAg LTAsMCArMSwzMSBAQAo+Pj4+ICtTaUZpdmUgTDIgQ2FjaGUgRURBQyBkcml2ZXIgZGV2aWNlIHRy ZWUgYmluZGluZ3MKPj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQo+Pj4+ICtUaGlzIGRyaXZlciB1c2VzIHRoZSBFREFDIGZyYW1ld29yayB0byBy ZXBvcnQgTDIgY2FjaGUgY29udHJvbGxlciBFQ0MgZXJyb3JzLgo+Pj4KPj4+IEJpbmRpbmdzIGFy ZSBmb3IgaC93IGJsb2Nrcywgbm90IGRyaXZlcnMuIChBbmQgQm9yaXMgbWF5IHdhbnQgYSBzaW5n bGUKPj4+IGRyaXZlciwgYnV0IGJpbmRpbmdzIHNob3VsZCByZWZsZWN0IHRoZSBoL3csIG5vdCB3 aGF0IExpbnV4IChjdXJyZW50bHkpCj4+PiB3YW50cy4KPj4KPj4gRm9yIGgvdyBibG9jayBjb21w YXRpYmxlcyBhbmQgZWRhYywgSSB0aGluayBhbGwgd2UgbmVlZCBub3cgaXMgdG8gZW5zdXJlIHRo ZSBEVCBjb250YWlucwo+PiB0aGUgdGhyZWUgY29tcGF0aWJsZSBzdHJpbmdzOiBwbGF0Zm9ybSAo aWYgdGhlcmUgaXMgb25lKSwgc29jIGFuZCBpcC1uYW1lIChpZiBpdHMgYQo+PiByZS11c2FibGUg dGhpbmcpLgo+PiBUaGlzIGlzIHNvIHRoYXQgbGludXggY2FuIHBpY2sgdGhlIGJpZ2dlc3Qgb2Yg dGhlIHRocmVlICh1c3VhbGx5IHBsYXRmb3JtKSB0byBwcm9iZSB0aGUKPj4gZHJpdmVyIGZyb20s IGFzIHRoaXMgbGV0cyB1cyBjYXB0dXJlIHBsYXRmb3JtIHByb3BlcnRpZXMgd2Ugb25seSBmaW5k IG91dCBhYm91dCBsYXRlci4KPiAKPiBEVCBpcyBub3QgdGhlIG9ubHkgd2hhdCB0byBpbnN0YW50 aWF0ZSBkcml2ZXJzLiBJZiB0aGUgT1MgcmVhbGx5IHdhbnRzCj4gdG8gaGF2ZSBhIHNpbmdsZSBk cml2ZXIgZm9yIG11bHRpcGxlIGgvdyBibG9ja3MsIHRoZW4gaXQgbmVlZHMgdG8KPiBpbnN0YW50 aWF0ZSBhIGRyaXZlciBpdHNlbGYgKGJhc2VkIG9uIHRoZSB0b3AtbGV2ZWwgY29tcGF0aWJsZQo+ IHByb2JhYmx5KSBhbmQgdGhlbiB0aGF0IGRyaXZlciBjYW4gZmluZCB0aGUgRFQgbm9kZXMgaXQg bmVlZHMgaXRzZWxmLgoKSSB0aGluayB0aGlzIGlzIHdoZXJlIHdlIGFyZSBoZWFkaW5nLiAoYnV0 IEkgbmVlZCB0byBnZXQgbXkgaGVhZCByb3VuZCB0aGlzIHRvcC1sZXZlbCB0aGluZykuCgpDYW4g dGhlIE9TIGRvIGJvdGgsIGRlcGVuZGluZyBvbiB0aGUgcGxhdGZvcm0/CmUuZy4gb24gYSBzeXN0 ZW0gd2l0aCBvbmUgY29tcG9uZW50IHRoZSBkcml2ZXIgcnVucyAnc3RhbmRhbG9uZScsIHdoZXJl YXMgb24gYSBiaWdnZXIKc3lzdGVtIHdpdGggbXVsdGlwbGUgY29tcG9uZW50cyB0aGUgc2FtZSBk cml2ZXIgaXMgdXNlZCBhcyBhIGxpYnJhcnkgYnkgc29tZXRoaW5nIGVsc2UuCgpJIGRvbid0IHNl ZSBob3cgdGhpcyB3b3VsZCB3b3JrIGlmIHRoZSBjb21tb24gY29tcG9uZW50J3MgRFQgZW50cnkg bG9va3MgdGhlIHNhbWUgb24gYm90aApwbGF0Zm9ybXMuIFdvdWxkbid0IHRoaXMgZGVwZW5kIG9u IHRoZSBvcmRlciBzdHVmZiBpcyBkb25lIGluLCBvciAnYnV0IG5vdCB0aGlzIG9uZScKY2hlY2tz IGluIHRoZSBkcml2ZXI/CgoKPiBJbiBhbnkgY2FzZSwgaXQncyBhbGwgaXJyZWxldmFudCB0byB0 aGUgRFQgYmluZGluZy4gV2UgZG9uJ3QgZGVzaWduCj4gYmluZGluZ3MgYXJvdW5kIHdoYXQgc29t ZSBwYXJ0aWN1bGFyIE9TIHdhbnRzLgoKSSBhZ3JlZS4KCldoYXQgd2Ugd2FudCB0byBkbyBpcyBz cG90IHRoZSBwcm9ibGVtcyBvbiB0aGUgaG9yaXpvbiBzbyB3ZSBlaXRoZXIgaGF2ZSB0aGUgcmln aHQKaW5mb3JtYXRpb24gaW4gdGhlIERUIHRvZGF5LCBvciBhdCBsZWFzdCBrbm93IHdoYXQgaXQg bG9va3MgbGlrZSBzbyB3ZSBkb24ndCBjYXVzZSBhCnJlZ3Jlc3Npb24gd2hlbiBhIG5ldyBwbGF0 Zm9ybSBtYWtlcyBwcmV2aW91cyBiZWhhdmlvdXIgZ2VuZXJpYy9hLWxpYnJhcnkuCgoKVGhhbmtz LAoKSmFtZXMK 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=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_PASS autolearn=unavailable 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 8946CC43381 for ; Mon, 1 Apr 2019 16:36:15 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 5DF6320883 for ; Mon, 1 Apr 2019 16:36:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="cl8cAyDj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5DF6320883 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=yBonj9rhJSfdjFaEJt3nuGKTBG9YllXrMXd6vENnhz4=; b=cl8cAyDjjqt+kc XYV3vjOOwU0FB3SbTX1C8gbq2RfpdNUK84W9euzp9Olr61nW3/AbyTMsD8QMwVZqSP7ApqI43EN1p HUTvd8nQ1UsapJecrVs2561tvJOwdRJvkiYdHXJ0eNArDBj9U0p5fklBIqyMcqvPstgiTJN0HvCip unzxnUMmO7rrlrhgmqW4hkDLC6cn9s+Q4+3S405e9vrExMUlhrTOZkmWShB6ElITngeqb/TiMXMi2 C55oGqaO4KZO8iMuksmcdqbc1+cSBkJt1bdtC+nD+Oc6gHx3g/CXXrz8I9zhA7wmT58zIm0vvZzSf 6FXPAIz/7Oo9TopCn5Eg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hAzus-0002A4-KY; Mon, 01 Apr 2019 16:36:10 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hAzuq-00025F-HS for linux-riscv@lists.infradead.org; Mon, 01 Apr 2019 16:36:09 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D3C1CA78; Mon, 1 Apr 2019 09:36:04 -0700 (PDT) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DDDB83F690; Mon, 1 Apr 2019 09:36:02 -0700 (PDT) Subject: Re: [PATCH 1/2] edac: sifive: Add DT documentation for SiFive L2 cache Controller To: Rob Herring References: <1552382461-13051-1-git-send-email-yash.shah@sifive.com> <1552382461-13051-2-git-send-email-yash.shah@sifive.com> <20190328131657.GA9056@bogus> From: James Morse Message-ID: <8e574cfa-29d9-0f0a-d670-c4869bd262c4@arm.com> Date: Mon, 1 Apr 2019 17:36:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190401_093608_586780_13F6AA6B X-CRM114-Status: GOOD ( 22.33 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, Albert Ou , Palmer Dabbelt , "linux-kernel@vger.kernel.org" , Yash Shah , Borislav Petkov , Paul Walmsley , linux-riscv@lists.infradead.org, Mauro Carvalho Chehab , linux-edac@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org Hi Rob, On 29/03/2019 14:11, Rob Herring wrote: > On Thu, Mar 28, 2019 at 1:47 PM James Morse wrote: >> On 28/03/2019 13:16, Rob Herring wrote: >>> On Tue, Mar 12, 2019 at 02:51:00PM +0530, Yash Shah wrote: >>>> DT documentation for L2 cache controller added. >>>> diff --git a/Documentation/devicetree/bindings/edac/sifive-edac-l2.txt b/Documentation/devicetree/bindings/edac/sifive-edac-l2.txt >>>> new file mode 100644 >>>> index 0000000..abce09f >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/edac/sifive-edac-l2.txt >>>> @@ -0,0 +1,31 @@ >>>> +SiFive L2 Cache EDAC driver device tree bindings >>>> +------------------------------------------------- >>>> +This driver uses the EDAC framework to report L2 cache controller ECC errors. >>> >>> Bindings are for h/w blocks, not drivers. (And Boris may want a single >>> driver, but bindings should reflect the h/w, not what Linux (currently) >>> wants. >> >> For h/w block compatibles and edac, I think all we need now is to ensure the DT contains >> the three compatible strings: platform (if there is one), soc and ip-name (if its a >> re-usable thing). >> This is so that linux can pick the biggest of the three (usually platform) to probe the >> driver from, as this lets us capture platform properties we only find out about later. > > DT is not the only what to instantiate drivers. If the OS really wants > to have a single driver for multiple h/w blocks, then it needs to > instantiate a driver itself (based on the top-level compatible > probably) and then that driver can find the DT nodes it needs itself. I think this is where we are heading. (but I need to get my head round this top-level thing). Can the OS do both, depending on the platform? e.g. on a system with one component the driver runs 'standalone', whereas on a bigger system with multiple components the same driver is used as a library by something else. I don't see how this would work if the common component's DT entry looks the same on both platforms. Wouldn't this depend on the order stuff is done in, or 'but not this one' checks in the driver? > In any case, it's all irrelevant to the DT binding. We don't design > bindings around what some particular OS wants. I agree. What we want to do is spot the problems on the horizon so we either have the right information in the DT today, or at least know what it looks like so we don't cause a regression when a new platform makes previous behaviour generic/a-library. Thanks, James _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv