public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: punnaiah choudary kalluri <punnaia@xilinx.com>
Cc: Punnaiah Choudary Kalluri <punnaiah.choudary.kalluri@xilinx.com>,
	dougthompson@xmission.com,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"pawel.moll@arm.com" <pawel.moll@arm.com>,
	"michal.simek@xilinx.com" <michal.simek@xilinx.com>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>, Rob Landley <rob@landley.net>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	linux-edac@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Punnaiah Choudary <kpc528@gmail.com>,
	anirudh@xilinx.com, svemula@xilinx.com
Subject: Re: [RFC PATCH v3] edac: synps: Added EDAC support for zynq ddr ecc controller
Date: Mon, 28 Jul 2014 20:01:36 +0200	[thread overview]
Message-ID: <20140728180136.GB7100@pd.tnic> (raw)
In-Reply-To: <CAGnW=BaEn7mjW3fmCcuyqgsgG=L_j_1zwK9kXAsx9GsBbOXXfA@mail.gmail.com>

On Mon, Jul 28, 2014 at 10:53:26PM +0530, punnaiah choudary kalluri wrote:
> I can agree with you that we can use shorter names.But ZYNQ has
> programmable logic next to processing system where one can add soft
> memory controller in the same system and may use different driver. So,
> the edac driver for zynq may include multiple drivers for different
> memory controllers in the same file. In this case it is difficult to
> maintain generic macros as you suggested above.

So?

You can still shorten them a bit - the current names are awfully long.
SYNPS_DDRC_ECC_ is too much information, for example. We know it is DDR
and we know it is about ECC. So do SYNPS and ZYNQ or OTHER or whatever
you wanna call it prefix and then the rest. I.e.,

    SYNPS_<reg>_<bits*>
    ZYNQ_<reg>_bits*>

You can even use single letter prefixes like S_ and Z_ and add a comment
explaining what those mean. Still much more readable than the long
repeating prefixes currently.

> Also the current edac framework for edac memory controllers is
> expecting the mc_num from the driver while allocating the memory
> controller instance using the edac_mc_alloc function. This requirement
> mandates that if the system contains two different memory controllers
> then the corresponding edac drivers should be in single file.

So you're telling me that you want one edac driver for *two* memory
controllers which can be present on a single system *at* *the* *same*
*time*? Is that it?

How exactly is that topology supposed to look like, work, etc, etc? What
kind of error reporting do you imagine you want to do with EDAC?

IOW, more info would be appreciated.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  reply	other threads:[~2014-07-28 18:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-26 18:40 [RFC PATCH v3] edac: synps: Added EDAC support for zynq ddr ecc controller Punnaiah Choudary Kalluri
2014-07-28 11:34 ` Borislav Petkov
2014-07-28 17:23   ` punnaiah choudary kalluri
2014-07-28 18:01     ` Borislav Petkov [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-07-30 15:41 Punnaiah Choudary Kalluri
2014-07-31 11:33 ` Borislav Petkov
2014-07-31 12:13   ` Michal Simek
2014-07-31 13:17     ` Borislav Petkov
2014-07-31 13:36       ` Michal Simek
2014-07-31 13:56         ` Borislav Petkov
2014-07-31 14:19           ` Punnaiah Choudary Kalluri
     [not found] <03CA77BA8AF6F1469AEDFBDA1322A7B74821CC98@XAP-PVEXMBX01.xlnx.xilinx.com>
2014-07-31  9:33 ` Michal Simek

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=20140728180136.GB7100@pd.tnic \
    --to=bp@alien8.de \
    --cc=anirudh@xilinx.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dougthompson@xmission.com \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=kpc528@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=michal.simek@xilinx.com \
    --cc=pawel.moll@arm.com \
    --cc=punnaia@xilinx.com \
    --cc=punnaiah.choudary.kalluri@xilinx.com \
    --cc=rob@landley.net \
    --cc=robh+dt@kernel.org \
    --cc=svemula@xilinx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox