All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yash Shah <yash.shah@sifive.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Borislav Petkov <bp@alien8.de>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	linux-riscv@lists.infradead.org, linux-edac@vger.kernel.org,
	"linux-kernel@vger.kernel.org List"
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc
Date: Tue, 20 Aug 2019 11:33:07 +0530	[thread overview]
Message-ID: <CAJ2_jOE+JX201biExFRziPTuw3tYFJwsrc5h-Uvg+=fcaobTww@mail.gmail.com> (raw)
In-Reply-To: <20190819062619.GA20211@lst.de>

On Mon, Aug 19, 2019 at 11:56 AM Christoph Hellwig <hch@lst.de> 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..
>
> So unless someone signs up to do a per-IP block edac drivers instead
> very quickly I'd still like to see something like this go into 5.4
> for now.

As of now, we can pull this patch into 5.4. Later, I will review if
per-IP block edac driver is needed and if so, will take care of
implementing it.

- Yash

WARNING: multiple messages have this Message-ID (diff)
From: Yash Shah <yash.shah@sifive.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Palmer Dabbelt <palmer@sifive.com>,
	"linux-kernel@vger.kernel.org List"
	<linux-kernel@vger.kernel.org>, Borislav Petkov <bp@alien8.de>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	linux-riscv@lists.infradead.org, linux-edac@vger.kernel.org
Subject: Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc
Date: Tue, 20 Aug 2019 11:33:07 +0530	[thread overview]
Message-ID: <CAJ2_jOE+JX201biExFRziPTuw3tYFJwsrc5h-Uvg+=fcaobTww@mail.gmail.com> (raw)
In-Reply-To: <20190819062619.GA20211@lst.de>

On Mon, Aug 19, 2019 at 11:56 AM Christoph Hellwig <hch@lst.de> 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..
>
> So unless someone signs up to do a per-IP block edac drivers instead
> very quickly I'd still like to see something like this go into 5.4
> for now.

As of now, we can pull this patch into 5.4. Later, I will review if
per-IP block edac driver is needed and if so, will take care of
implementing it.

- Yash

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

  reply	other threads:[~2019-08-20  6:03 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 [this message]
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
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='CAJ2_jOE+JX201biExFRziPTuw3tYFJwsrc5h-Uvg+=fcaobTww@mail.gmail.com' \
    --to=yash.shah@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=paul.walmsley@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.