Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934677AbaDJGMZ (ORCPT ); Thu, 10 Apr 2014 02:12:25 -0400 Received: from mail-ee0-f47.google.com ([74.125.83.47]:34995 "EHLO mail-ee0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750942AbaDJGMX (ORCPT ); Thu, 10 Apr 2014 02:12:23 -0400 Message-ID: <53463641.1030800@monstr.eu> Date: Thu, 10 Apr 2014 08:12:17 +0200 From: Michal Simek Reply-To: monstr@monstr.eu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: Borislav Petkov CC: Punnaiah Choudary , Rob Herring , Punnaiah Choudary Kalluri , Doug Thompson , "devicetree@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , linux-edac@vger.kernel.org, Michal Simek , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Rob Landley , punnaiah choudary kalluri , punnaiah choudary kalluri , Russell King Subject: Re: [RFC PATCH] edac: add support for ARM PL310 L2 cache parity References: <1393770760-32550-1-git-send-email-punnaia@xilinx.com> <20140409113246.GA8778@pd.tnic> <20140409151932.GK6529@pd.tnic> <20140409174701.GO6529@pd.tnic> In-Reply-To: <20140409174701.GO6529@pd.tnic> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ME3xMGXB0ilkieRoxEIfFGdTbD860ewG6" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ME3xMGXB0ilkieRoxEIfFGdTbD860ewG6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/09/2014 07:47 PM, Borislav Petkov wrote: > On Wed, Apr 09, 2014 at 10:59:49PM +0530, Punnaiah Choudary wrote: >> There is a driver file cache-l2x0.c under arch/arm/mm for pl310 cache >> configuration and management. Russel king had suggested to use >> single driver file for both pl310 edac implementation and cache-l2x0.c= >> Here is the thread >> http://www.spinics.net/lists/arm-kernel/msg320407.html >> >> please provide your inputs >=20 > Well, it is very simple - you don't really need an EDAC compilation uni= t > just so that you can report errors - you can very well do that in your > cache-l2x0.c and boom, problem solved. >=20 > Simply move the irq handler and the parity error checker to that file. I am just curious about this recommendation. Does it mean that we shouldn= 't use edac interface just for reporting problems? I didn't play with it but I guess that there is a record about edac drive= r via sysfs, etc. You could read some useful information that you know what it is protected and I hope that edac interface bring any value to reporting errors comparing to just printk message from IRQ handler. My question is if using printk in IRQ handler and report problem is equal= to reporting this via edac interface. Or it is just easy way to do but using edac interface is right solution and how to do it properly is different question. Thanks, Michal --=20 Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform --ME3xMGXB0ilkieRoxEIfFGdTbD860ewG6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNGNkEACgkQykllyylKDCFcdwCfWd+zLKLdg7fKhj2az7pGDH2u 6eEAn14us5SrSATJ2vm0EKz1wf7BtV8B =Jujl -----END PGP SIGNATURE----- --ME3xMGXB0ilkieRoxEIfFGdTbD860ewG6-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/