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.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED 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 D3473C4360F for ; Thu, 4 Apr 2019 01:17:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9917C20820 for ; Thu, 4 Apr 2019 01:17:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554340675; bh=yymA39LA7eJhd4jifzcnBTuqwG6z3k/nJ6Y3aNW27CM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=zPN1fqrIoPaCnSNe7u2UV6CzgQrr72o7g6p5DPc4dZbg9Sxl91lPMC38JppKN2kIK ApCT+Ijx6DlotvVRBDXiiuT4hjkeu4YSg1i43d3t2P0ceLcJBymyx1NO/A2WHrs4N9 7xVdv24gnVzJ/+i4iHRMt4u8gQJPjipUnEVsv2fM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726562AbfDDBRy (ORCPT ); Wed, 3 Apr 2019 21:17:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:59704 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726199AbfDDBRx (ORCPT ); Wed, 3 Apr 2019 21:17:53 -0400 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 12E14214AF; Thu, 4 Apr 2019 01:17:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554340672; bh=yymA39LA7eJhd4jifzcnBTuqwG6z3k/nJ6Y3aNW27CM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=KMMvpBcd+8+8mUzQDL3mu0fy9Ee8SOWNXRlPtHcV6miPg/IvZfqIilysmFFcuR6Du sS+KJesDNdCTAYJzf5v7T5uoscT2ZiEkME95L5BGrtVtCWGJJ7Gch53w/VQ6ZMmSZg 2wuA+4Svz5cUxrkl+6aVTmvsFpsnH0HqyPmYrHOI= Received: by mail-qk1-f170.google.com with SMTP id w20so647855qka.7; Wed, 03 Apr 2019 18:17:52 -0700 (PDT) X-Gm-Message-State: APjAAAXyPCT5GOaL6Zh0Khg5Pb8xTwWCAyIt82qev+oYQVK1skhSWtEE Joa516YqGDKAY6ipBBcV7TdnsIeOdMDmD4uXAw== X-Google-Smtp-Source: APXvYqwKIU4/yzVU4Q4LwBsOvfW/bsQjbS96OYjtGaJX057xOqCvfP0RUE3l13IxpMkg1qhSYBZ6Y/oNt1wLpqGqwrw= X-Received: by 2002:ae9:e313:: with SMTP id v19mr2647385qkf.153.1554340671248; Wed, 03 Apr 2019 18:17:51 -0700 (PDT) MIME-Version: 1.0 References: <1552382461-13051-1-git-send-email-yash.shah@sifive.com> <1552382461-13051-2-git-send-email-yash.shah@sifive.com> <20190328131657.GA9056@bogus> <8e574cfa-29d9-0f0a-d670-c4869bd262c4@arm.com> In-Reply-To: <8e574cfa-29d9-0f0a-d670-c4869bd262c4@arm.com> From: Rob Herring Date: Wed, 3 Apr 2019 20:17:40 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] edac: sifive: Add DT documentation for SiFive L2 cache Controller To: James Morse 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 1, 2019 at 11:36 AM James Morse wrote: > > 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? Yeah, it could get a bit messy. I think we'd have to always do things as described above for anything using that set of components. If you truly have some set of multiple blocks and any combination of them can appear, then we shouldn't be trying to have a single driver and EDAC needs to change to support that IMO. However, I'd guess things are not that stable to have many different combinations of components. SoCs have new DDR controllers practically every generation for example. > > 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. If we follow what the current OS wants, then what is right will change. Rob 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: Rob Herring Message-Id: Date: Wed, 3 Apr 2019 20:17:40 -0500 To: James Morse 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: T24gTW9uLCBBcHIgMSwgMjAxOSBhdCAxMTozNiBBTSBKYW1lcyBNb3JzZSA8amFtZXMubW9yc2VA YXJtLmNvbT4gd3JvdGU6Cj4KPiBIaSBSb2IsCj4KPiBPbiAyOS8wMy8yMDE5IDE0OjExLCBSb2Ig SGVycmluZyB3cm90ZToKPiA+IE9uIFRodSwgTWFyIDI4LCAyMDE5IGF0IDE6NDcgUE0gSmFtZXMg TW9yc2UgPGphbWVzLm1vcnNlQGFybS5jb20+IHdyb3RlOgo+ID4+IE9uIDI4LzAzLzIwMTkgMTM6 MTYsIFJvYiBIZXJyaW5nIHdyb3RlOgo+ID4+PiBPbiBUdWUsIE1hciAxMiwgMjAxOSBhdCAwMjo1 MTowMFBNICswNTMwLCBZYXNoIFNoYWggd3JvdGU6Cj4gPj4+PiBEVCBkb2N1bWVudGF0aW9uIGZv ciBMMiBjYWNoZSBjb250cm9sbGVyIGFkZGVkLgo+Cj4gPj4+PiBkaWZmIC0tZ2l0IGEvRG9jdW1l bnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2VkYWMvc2lmaXZlLWVkYWMtbDIudHh0IGIvRG9j dW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2VkYWMvc2lmaXZlLWVkYWMtbDIudHh0Cj4g Pj4+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NAo+ID4+Pj4gaW5kZXggMDAwMDAwMC4uYWJjZTA5Zgo+ ID4+Pj4gLS0tIC9kZXYvbnVsbAo+ID4+Pj4gKysrIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVl L2JpbmRpbmdzL2VkYWMvc2lmaXZlLWVkYWMtbDIudHh0Cj4gPj4+PiBAQCAtMCwwICsxLDMxIEBA Cj4gPj4+PiArU2lGaXZlIEwyIENhY2hlIEVEQUMgZHJpdmVyIGRldmljZSB0cmVlIGJpbmRpbmdz Cj4gPj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQo+ID4+Pj4gK1RoaXMgZHJpdmVyIHVzZXMgdGhlIEVEQUMgZnJhbWV3b3JrIHRvIHJlcG9ydCBM MiBjYWNoZSBjb250cm9sbGVyIEVDQyBlcnJvcnMuCj4gPj4+Cj4gPj4+IEJpbmRpbmdzIGFyZSBm b3IgaC93IGJsb2Nrcywgbm90IGRyaXZlcnMuIChBbmQgQm9yaXMgbWF5IHdhbnQgYSBzaW5nbGUK PiA+Pj4gZHJpdmVyLCBidXQgYmluZGluZ3Mgc2hvdWxkIHJlZmxlY3QgdGhlIGgvdywgbm90IHdo YXQgTGludXggKGN1cnJlbnRseSkKPiA+Pj4gd2FudHMuCj4gPj4KPiA+PiBGb3IgaC93IGJsb2Nr IGNvbXBhdGlibGVzIGFuZCBlZGFjLCBJIHRoaW5rIGFsbCB3ZSBuZWVkIG5vdyBpcyB0byBlbnN1 cmUgdGhlIERUIGNvbnRhaW5zCj4gPj4gdGhlIHRocmVlIGNvbXBhdGlibGUgc3RyaW5nczogcGxh dGZvcm0gKGlmIHRoZXJlIGlzIG9uZSksIHNvYyBhbmQgaXAtbmFtZSAoaWYgaXRzIGEKPiA+PiBy ZS11c2FibGUgdGhpbmcpLgo+ID4+IFRoaXMgaXMgc28gdGhhdCBsaW51eCBjYW4gcGljayB0aGUg YmlnZ2VzdCBvZiB0aGUgdGhyZWUgKHVzdWFsbHkgcGxhdGZvcm0pIHRvIHByb2JlIHRoZQo+ID4+ IGRyaXZlciBmcm9tLCBhcyB0aGlzIGxldHMgdXMgY2FwdHVyZSBwbGF0Zm9ybSBwcm9wZXJ0aWVz IHdlIG9ubHkgZmluZCBvdXQgYWJvdXQgbGF0ZXIuCj4gPgo+ID4gRFQgaXMgbm90IHRoZSBvbmx5 IHdoYXQgdG8gaW5zdGFudGlhdGUgZHJpdmVycy4gSWYgdGhlIE9TIHJlYWxseSB3YW50cwo+ID4g dG8gaGF2ZSBhIHNpbmdsZSBkcml2ZXIgZm9yIG11bHRpcGxlIGgvdyBibG9ja3MsIHRoZW4gaXQg bmVlZHMgdG8KPiA+IGluc3RhbnRpYXRlIGEgZHJpdmVyIGl0c2VsZiAoYmFzZWQgb24gdGhlIHRv cC1sZXZlbCBjb21wYXRpYmxlCj4gPiBwcm9iYWJseSkgYW5kIHRoZW4gdGhhdCBkcml2ZXIgY2Fu IGZpbmQgdGhlIERUIG5vZGVzIGl0IG5lZWRzIGl0c2VsZi4KPgo+IEkgdGhpbmsgdGhpcyBpcyB3 aGVyZSB3ZSBhcmUgaGVhZGluZy4gKGJ1dCBJIG5lZWQgdG8gZ2V0IG15IGhlYWQgcm91bmQgdGhp cyB0b3AtbGV2ZWwgdGhpbmcpLgo+Cj4gQ2FuIHRoZSBPUyBkbyBib3RoLCBkZXBlbmRpbmcgb24g dGhlIHBsYXRmb3JtPwo+IGUuZy4gb24gYSBzeXN0ZW0gd2l0aCBvbmUgY29tcG9uZW50IHRoZSBk cml2ZXIgcnVucyAnc3RhbmRhbG9uZScsIHdoZXJlYXMgb24gYSBiaWdnZXIKPiBzeXN0ZW0gd2l0 aCBtdWx0aXBsZSBjb21wb25lbnRzIHRoZSBzYW1lIGRyaXZlciBpcyB1c2VkIGFzIGEgbGlicmFy eSBieSBzb21ldGhpbmcgZWxzZS4KPgo+IEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIHdvdWxkIHdvcmsg aWYgdGhlIGNvbW1vbiBjb21wb25lbnQncyBEVCBlbnRyeSBsb29rcyB0aGUgc2FtZSBvbiBib3Ro Cj4gcGxhdGZvcm1zLiBXb3VsZG4ndCB0aGlzIGRlcGVuZCBvbiB0aGUgb3JkZXIgc3R1ZmYgaXMg ZG9uZSBpbiwgb3IgJ2J1dCBub3QgdGhpcyBvbmUnCj4gY2hlY2tzIGluIHRoZSBkcml2ZXI/CgpZ ZWFoLCBpdCBjb3VsZCBnZXQgYSBiaXQgbWVzc3kuIEkgdGhpbmsgd2UnZCBoYXZlIHRvIGFsd2F5 cyBkbyB0aGluZ3MKYXMgZGVzY3JpYmVkIGFib3ZlIGZvciBhbnl0aGluZyB1c2luZyB0aGF0IHNl dCBvZiBjb21wb25lbnRzLiBJZiB5b3UKdHJ1bHkgaGF2ZSBzb21lIHNldCBvZiBtdWx0aXBsZSBi bG9ja3MgYW5kIGFueSBjb21iaW5hdGlvbiBvZiB0aGVtIGNhbgphcHBlYXIsIHRoZW4gd2Ugc2hv dWxkbid0IGJlIHRyeWluZyB0byBoYXZlIGEgc2luZ2xlIGRyaXZlciBhbmQgRURBQwpuZWVkcyB0 byBjaGFuZ2UgdG8gc3VwcG9ydCB0aGF0IElNTy4gSG93ZXZlciwgSSdkIGd1ZXNzIHRoaW5ncyBh cmUgbm90CnRoYXQgc3RhYmxlIHRvIGhhdmUgbWFueSBkaWZmZXJlbnQgY29tYmluYXRpb25zIG9m IGNvbXBvbmVudHMuIFNvQ3MKaGF2ZSBuZXcgRERSIGNvbnRyb2xsZXJzIHByYWN0aWNhbGx5IGV2 ZXJ5IGdlbmVyYXRpb24gZm9yIGV4YW1wbGUuCgo+ID4gSW4gYW55IGNhc2UsIGl0J3MgYWxsIGly cmVsZXZhbnQgdG8gdGhlIERUIGJpbmRpbmcuIFdlIGRvbid0IGRlc2lnbgo+ID4gYmluZGluZ3Mg YXJvdW5kIHdoYXQgc29tZSBwYXJ0aWN1bGFyIE9TIHdhbnRzLgo+Cj4gSSBhZ3JlZS4KPgo+IFdo YXQgd2Ugd2FudCB0byBkbyBpcyBzcG90IHRoZSBwcm9ibGVtcyBvbiB0aGUgaG9yaXpvbiBzbyB3 ZSBlaXRoZXIgaGF2ZSB0aGUgcmlnaHQKPiBpbmZvcm1hdGlvbiBpbiB0aGUgRFQgdG9kYXksIG9y IGF0IGxlYXN0IGtub3cgd2hhdCBpdCBsb29rcyBsaWtlIHNvIHdlIGRvbid0IGNhdXNlIGEKPiBy ZWdyZXNzaW9uIHdoZW4gYSBuZXcgcGxhdGZvcm0gbWFrZXMgcHJldmlvdXMgYmVoYXZpb3VyIGdl bmVyaWMvYS1saWJyYXJ5LgoKSWYgd2UgZm9sbG93IHdoYXQgdGhlIGN1cnJlbnQgT1Mgd2FudHMs IHRoZW4gd2hhdCBpcyByaWdodCB3aWxsIGNoYW5nZS4KClJvYgo= 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,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 DE1B6C4360F for ; Thu, 4 Apr 2019 01:17:59 +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 AE4A820820 for ; Thu, 4 Apr 2019 01:17:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="QGqcnH9Z"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="KMMvpBcd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE4A820820 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=RTvKmAGpQyMnJb9ZF51GwzrjWB9jZUH36YAkiu/+yDA=; b=QGqcnH9ZMtbLD9 lfsK9yMZbZcTVymca9vyu6+EW8C7bSfrm3ap7hVXnTgSO7fEaZ5xRdkCzcPDaJE1IztLYRKP1z3AD ID+PzwdY5WIVoWQWgMH7jdt4ZpgA9bt629VYTfHaf4hDwJ7z68LbWd5mWtaGXrw9pq2e2tMBNO6mk ggNehAg+tRE8bpVOc3FkYosr0PoWUtpQXJqa87FnSxJCp9F5uHbTC5OiF5pyzL0FuJ/BPUAwEb1Zl PuHFMLDPMOJbbJEZOrFJmTh2Bj5dAHBf7Gaf3bND8LPcRt9CSrIpPRj+m20v5U10HtYoJOlL+HrCV MvcbNZkGN+tIt19oIarw==; 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 1hBr0t-0005j3-NU; Thu, 04 Apr 2019 01:17:55 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBr0r-0005ij-5L for linux-riscv@lists.infradead.org; Thu, 04 Apr 2019 01:17:54 +0000 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0461E20820 for ; Thu, 4 Apr 2019 01:17:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554340672; bh=yymA39LA7eJhd4jifzcnBTuqwG6z3k/nJ6Y3aNW27CM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=KMMvpBcd+8+8mUzQDL3mu0fy9Ee8SOWNXRlPtHcV6miPg/IvZfqIilysmFFcuR6Du sS+KJesDNdCTAYJzf5v7T5uoscT2ZiEkME95L5BGrtVtCWGJJ7Gch53w/VQ6ZMmSZg 2wuA+4Svz5cUxrkl+6aVTmvsFpsnH0HqyPmYrHOI= Received: by mail-qk1-f180.google.com with SMTP id c20so635499qkc.10 for ; Wed, 03 Apr 2019 18:17:51 -0700 (PDT) X-Gm-Message-State: APjAAAWLMvzwcQElLiJ9poNN06dgj7HCX1yvWWhco4cnEEiHSYwBTyWV SmzPUpyHLc5S6aRqjwemVy/wZc+YVIeC2e6pgg== X-Google-Smtp-Source: APXvYqwKIU4/yzVU4Q4LwBsOvfW/bsQjbS96OYjtGaJX057xOqCvfP0RUE3l13IxpMkg1qhSYBZ6Y/oNt1wLpqGqwrw= X-Received: by 2002:ae9:e313:: with SMTP id v19mr2647385qkf.153.1554340671248; Wed, 03 Apr 2019 18:17:51 -0700 (PDT) MIME-Version: 1.0 References: <1552382461-13051-1-git-send-email-yash.shah@sifive.com> <1552382461-13051-2-git-send-email-yash.shah@sifive.com> <20190328131657.GA9056@bogus> <8e574cfa-29d9-0f0a-d670-c4869bd262c4@arm.com> In-Reply-To: <8e574cfa-29d9-0f0a-d670-c4869bd262c4@arm.com> From: Rob Herring Date: Wed, 3 Apr 2019 20:17:40 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] edac: sifive: Add DT documentation for SiFive L2 cache Controller To: James Morse X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190403_181753_239948_D3552149 X-CRM114-Status: GOOD ( 27.56 ) 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 On Mon, Apr 1, 2019 at 11:36 AM James Morse wrote: > > 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? Yeah, it could get a bit messy. I think we'd have to always do things as described above for anything using that set of components. If you truly have some set of multiple blocks and any combination of them can appear, then we shouldn't be trying to have a single driver and EDAC needs to change to support that IMO. However, I'd guess things are not that stable to have many different combinations of components. SoCs have new DDR controllers practically every generation for example. > > 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. If we follow what the current OS wants, then what is right will change. Rob _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv