From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [PATCH v7 3/5] Documentation: Add documentation for the APM X-Gene SoC EDAC DTS binding Date: Thu, 30 Apr 2015 10:20:51 +0200 Message-ID: <20150430082051.GA3488@pd.tnic> References: <1430259045-19012-1-git-send-email-lho@apm.com> <1430259045-19012-2-git-send-email-lho@apm.com> <1430259045-19012-3-git-send-email-lho@apm.com> <1430259045-19012-4-git-send-email-lho@apm.com> <20150429214924.GH5498@pd.tnic> <20150429220830.GI5498@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rob Herring Cc: Loc Ho , Doug Thompson , Mauro Carvalho Chehab , Rob Herring , Mark Rutland , Ian Campbell , linux-edac-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "patches-qTEPVZfXA3Y@public.gmane.org" , Feng Kan List-Id: devicetree@vger.kernel.org On Wed, Apr 29, 2015 at 06:02:14PM -0500, Rob Herring wrote: > I think that it is silly to group otherwise independent things > together and generally not what we do anywhere else in the kernel. > They all likely have different capabilities and control mechanisms. So let's look at the other extremity here: the moment someone releases yet another "independent" IP block with some RAS functionality, same someone will create yet another _edac_ driver. How many independent IP blocks are there with RAS functionality? 10, 20, 100...? That number is most likely growing, I'd bet. Oh, and then there'll probably be functionality which is needed by two IP blocks so it needs to be shared. So we either copy'paste stuff or create a lib only for that functionality... Even worse, what if two EDAC drivers for two IP blocks would need to talk to each other. That'll be fun. Or there'll be a v2 of the IP block which has almost the same functionality but no 100% - just a *little* different. So then we go create _edac_ driver. Yuck! What I would prefer is to concentrate all vendor-specific RAS functionality in one single driver. Shared functionality is then taken care of automagically with all the synergies (I hate that word!) involved and no unnecessary too finer-grained splitting. In that case, we would only have to enable loading more than one EDAC drivers on a system which has different RAS IP blocks. Now *that* is a much cleaner solution IMO which will keep the sanity in EDAC-land above 0. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html