From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 95285B711B for ; Mon, 7 Feb 2011 10:50:19 +1100 (EST) Subject: RE: [PATCH] e500: Erratum cpu a005 workaround From: Benjamin Herrenschmidt To: Liu Yu-B13201 In-Reply-To: References: <1295935333-13045-1-git-send-email-yu.liu@freescale.com> <5DA54AEE-B8AC-452B-A56C-65B35391A97C@freescale.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Feb 2011 10:49:15 +1100 Message-ID: <1297036155.14982.19.camel@pasglop> Mime-Version: 1.0 Cc: Gala Kumar-B11780 , "linuxppc-dev@lists.ozlabs.org" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > > > > This isn't the way to do this. We normally add entries in > > cputable.c an add a new cpu_feature_bit for the errata. > > > > Than above we'd do: > > > > if (cur_cpu_spec->cpu_features & CPU_FTR_E500_A005_ERRATUM) > > > > > > IMHO, a cpu erratum is not a cpu feature. > See there're only 32 bits can be used for all PowerPC platform to represent cpu feature, > then is it worth consuming one of them to represent one e500 erratum? This is an interesting debate :-) We have used cpu_features for errata in the past. However, we are getting a bit short and I'd rather keep CPU features for things that are spread out in multiple places and/or hitting hot code path. If the workaround is very limited to a single non-critical code path, testing the PVR might actually be a nicer way to do it. Now, this specific patch is ... hrm ... hard to decide. I don't like that much the global variable. On the other hand, it's static and allows the whole business of this errata to be completely local to the math_efp.c file which is a good thing. So I'm tempted to say go with the patch as it-is, but I'll let Kumar ultimately decide. Cheers, Ben.