All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Walmsley <paul.walmsley@sifive.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Borislav Petkov <bp@alien8.de>,
	palmer@sifive.com, linux-riscv@lists.infradead.org,
	linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yash Shah <yash.shah@sifive.com>
Subject: Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc
Date: Fri, 6 Sep 2019 15:33:02 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.9999.1909061527510.6292@viisi.sifive.com> (raw)
In-Reply-To: <20190819062619.GA20211@lst.de>

On Mon, 19 Aug 2019, Christoph Hellwig wrote:

> On Mon, Aug 19, 2019 at 08:09:04AM +0200, Borislav Petkov wrote:
> > On Sun, Aug 18, 2019 at 10:29:35AM +0200, Christoph Hellwig wrote:
> > > The sifive_l2_cache.c is in no way related to RISC-V architecture
> > > memory management.  It is a little stub driver working around the fact
> > > that the EDAC maintainers prefer their drivers to be structured in a
> > > certain way
> > 
> > That changed recently so I guess we can do the per-IP block driver after
> > all, if people would still prefer it.
> 
> That would seem like the best idea.  But I don't really know this code
> well enough myself, and I really need to get this code out of the
> forced on RISC-V codebase as some SOCs I'm working with simply don't
> have the memory for it..

If that's your primary concern, then in the short term, how about just 
sending a single-line patch to the arch/riscv/mm Makefile to skip building 
it if !CONFIG_SOC_SIFIVE?  Assuming, that is, you won't be enabling EDAC 
support for those low-end SoCs.  Then you won't need to get the ack 
from the EDAC folks in the short term.  

Then a patch to make the SiFive platform EDAC driver build contingent on 
CONFIG_SOC_SIFIVE could be sent separately.


- Paul

WARNING: multiple messages have this Message-ID (diff)
From: Paul Walmsley <paul.walmsley@sifive.com>
To: Christoph Hellwig <hch@lst.de>
Cc: palmer@sifive.com, linux-kernel@vger.kernel.org,
	Yash Shah <yash.shah@sifive.com>, Borislav Petkov <bp@alien8.de>,
	linux-riscv@lists.infradead.org, linux-edac@vger.kernel.org
Subject: Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc
Date: Fri, 6 Sep 2019 15:33:02 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.9999.1909061527510.6292@viisi.sifive.com> (raw)
In-Reply-To: <20190819062619.GA20211@lst.de>

On Mon, 19 Aug 2019, Christoph Hellwig wrote:

> On Mon, Aug 19, 2019 at 08:09:04AM +0200, Borislav Petkov wrote:
> > On Sun, Aug 18, 2019 at 10:29:35AM +0200, Christoph Hellwig wrote:
> > > The sifive_l2_cache.c is in no way related to RISC-V architecture
> > > memory management.  It is a little stub driver working around the fact
> > > that the EDAC maintainers prefer their drivers to be structured in a
> > > certain way
> > 
> > That changed recently so I guess we can do the per-IP block driver after
> > all, if people would still prefer it.
> 
> That would seem like the best idea.  But I don't really know this code
> well enough myself, and I really need to get this code out of the
> forced on RISC-V codebase as some SOCs I'm working with simply don't
> have the memory for it..

If that's your primary concern, then in the short term, how about just 
sending a single-line patch to the arch/riscv/mm Makefile to skip building 
it if !CONFIG_SOC_SIFIVE?  Assuming, that is, you won't be enabling EDAC 
support for those low-end SoCs.  Then you won't need to get the ack 
from the EDAC folks in the short term.  

Then a patch to make the SiFive platform EDAC driver build contingent on 
CONFIG_SOC_SIFIVE could be sent separately.


- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2019-09-06 22:33 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-18  8:29 [PATCH] riscv: move sifive_l2_cache.c to drivers/soc Christoph Hellwig
2019-08-18  8:29 ` Christoph Hellwig
2019-08-19  4:44 ` Anup Patel
2019-08-19  4:44   ` Anup Patel
2019-08-19  6:09 ` Borislav Petkov
2019-08-19  6:09   ` Borislav Petkov
2019-08-19  6:26   ` Christoph Hellwig
2019-08-19  6:26     ` Christoph Hellwig
2019-08-20  6:03     ` Yash Shah
2019-08-20  6:03       ` Yash Shah
2019-08-22  9:26     ` Mauro Carvalho Chehab
2019-08-22  9:26       ` Mauro Carvalho Chehab
2019-08-31  2:53       ` Paul Walmsley
2019-08-31  2:53         ` Paul Walmsley
2019-09-01  8:00         ` Christoph Hellwig
2019-09-01  8:00           ` Christoph Hellwig
2019-09-27 22:53       ` Christoph Hellwig
2019-09-27 22:53         ` Christoph Hellwig
2019-10-17 17:19         ` Christoph Hellwig
2019-10-17 17:19           ` Christoph Hellwig
2019-09-06 22:33     ` Paul Walmsley [this message]
2019-09-06 22:33       ` Paul Walmsley
2019-09-07  4:42       ` Christoph Hellwig
2019-09-07  4:42         ` Christoph Hellwig
2019-09-06 22:27 ` Paul Walmsley
2019-09-06 22:27   ` Paul Walmsley
2019-09-06 22:36   ` Paul Walmsley
2019-09-06 22:36     ` Paul Walmsley
2019-09-07  4:40     ` Christoph Hellwig
2019-09-07  4:40       ` Christoph Hellwig
2019-09-07  4:39   ` Christoph Hellwig
2019-09-07  4:39     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.9999.1909061527510.6292@viisi.sifive.com \
    --to=paul.walmsley@sifive.com \
    --cc=bp@alien8.de \
    --cc=hch@lst.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@sifive.com \
    --cc=yash.shah@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.