devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Michal Simek <michal.simek@xilinx.com>
Cc: Punnaiah Choudary Kalluri <punnaiah.choudary.kalluri@xilinx.com>,
	"dougthompson@xmission.com" <dougthompson@xmission.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"pawel.moll@arm.com" <pawel.moll@arm.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-edac@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Punnaiah Choudary <kpc528@gmail.com>,
	Anirudha Sarangi <anirudh@xilinx.com>,
	Srikanth Vemula <svemula@xilinx.com>
Subject: Re: [RFC PATCH v3] edac: synps: Added EDAC support for zynq ddr ecc controller
Date: Thu, 31 Jul 2014 15:56:52 +0200	[thread overview]
Message-ID: <20140731135652.GD4375@pd.tnic> (raw)
In-Reply-To: <a366b39c-b354-4d90-8b1e-71e74ab77cf3@BL2FFO11FD011.protection.gbl>

On Thu, Jul 31, 2014 at 03:36:35PM +0200, Michal Simek wrote:
> Mixing functions for two/more different controller seems to me
> really messy.

Just stating that something is "really messy" without giving at least
one technical reason for it is not going to get you any further. So let
me give you mine:

I think it is not messy because one file contains all the EDAC code for
that system. Like every other system out there uses one EDAC driver.
Everything is nicely contained in one place, any communication between
the two memory controllers is done internally in that driver.

Having two drivers would make that much more complicated. But hey, if
you want to make your life more complicated because it is not enough
complicated, feel free to do so. Just make sure you don't impose any
restrictions on the rest of the subsystem.

> > -ENOPARSE for this sentence.
> 
> I meant by this this scenario - please correct me if I am completely wrong
> because I am not playing with this subsystem. My expectation is that
> memory controller number should be same all the time.
> 
> two memory controllers with the same edac driver.
> 
> Normal calling sequence:
> X probe - number 0
> Y probe - number 1
> 
> Different order/name (I think order is taken at the first place)
> in DTS should caused that X will have number 1 and Y number 0.
> 
> Another scenario:
> two controllers and one with external gpio reset for example.
> 
> X probe is called but gpio controller is not ready and gpio driver returns
> -EPROBE_DEFER then Y probe is called and get number 0. Then X probe is called
> again and get number 1.

Right, since you have a heterogeneous design, you'd need to account
for all that in your driver and deal with probing order. Like having a
way to ask a controller what kind of a controller it is and so on. I'm
afraid I don't know anything about your design to be of more help there.

However, doing this in one <name>_edac.c file is almost trivial than
doing it with two separate drivers. Unless you don't need to do any
meaningful communication between the PS and PL. Then it doesn't matter.

If I were you, I'd spend a more time on a proper design now so that all
my work later is easy. Adding two drivers just because it seems messy is
not a very good idea. What I would do is analyze all my use cases and
come up with a proper design then. But this is just me.

HTH.

-- 
Regards/Gruss,
    Boris.

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

  reply	other threads:[~2014-07-31 13:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-30 15:41 [RFC PATCH v3] edac: synps: Added EDAC support for zynq ddr ecc controller Punnaiah Choudary Kalluri
     [not found] ` <9dc2a947-d2ab-4f00-8ed3-d2499cb6fdfd-fm2tX0oQAVwurciUxeYi6OhlVc3/7hDbVaz/vdPVXQ4@public.gmane.org>
2014-07-31 11:33   ` Borislav Petkov
2014-07-31 12:13     ` Michal Simek
2014-07-31 13:17       ` Borislav Petkov
     [not found]         ` <20140731131702.GC4375-fF5Pk5pvG8Y@public.gmane.org>
2014-07-31 13:36           ` Michal Simek
2014-07-31 13:56             ` Borislav Petkov [this message]
2014-07-31 14:19               ` Punnaiah Choudary Kalluri
     [not found] <03CA77BA8AF6F1469AEDFBDA1322A7B74821CC98@XAP-PVEXMBX01.xlnx.xilinx.com>
2014-07-31  9:33 ` Michal Simek
  -- strict thread matches above, loose matches on Subject: below --
2014-07-26 18:40 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

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=20140731135652.GD4375@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=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;
as well as URLs for NNTP newsgroup(s).