From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753815AbcFPHp7 (ORCPT ); Thu, 16 Jun 2016 03:45:59 -0400 Received: from mail-vk0-f50.google.com ([209.85.213.50]:35767 "EHLO mail-vk0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752187AbcFPHpw (ORCPT ); Thu, 16 Jun 2016 03:45:52 -0400 MIME-Version: 1.0 In-Reply-To: References: <1465822923-33599-1-git-send-email-liudongdong3@huawei.com> <1465822923-33599-2-git-send-email-liudongdong3@huawei.com> From: Duc Dang Date: Thu, 16 Jun 2016 00:45:21 -0700 Message-ID: Subject: Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks To: Jon Masters Cc: Gabriele Paoloni , "liudongdong (C)" , "helgaas@kernel.org" , "arnd@arndb.de" , "will.deacon@arm.com" , "catalin.marinas@arm.com" , "rafael@kernel.org" , "hanjun.guo@linaro.org" , "Lorenzo.Pieralisi@arm.com" , "okaya@codeaurora.org" , "jchandra@broadcom.com" , "tn@semihalf.com" , "linaro-acpi@lists.linaro.org" , "linux-pci@vger.kernel.org" , "Liviu.Dudau@arm.com" , "ddaney@caviumnetworks.com" , "jeremy.linton@arm.com" , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "robert.richter@caviumnetworks.com" , "Chenxin (Charles)" , "cov@codeaurora.org" , Wangyijing , "mw@semihalf.com" , "andrea.gallo@linaro.org" , Linuxarm , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters wrote: > On 06/13/2016 09:54 AM, Gabriele Paoloni wrote: >> Hi Tomasz, Jon > > Hi Gab, > > Sorry for the lag in following up. > > > >> As you can see here Liudongdong has replaced oem_revision with >> oem_table_id. >> >> Now it seems that there are some platforms that have already shipped >> using a matching based on the oem_revision (right Jon?) > > Actually, it turns out (Cov is correct) that we can just match on OEM > Table ID. The revision should not generally be needed and the vendors > will just need to make sure that they change OEM Table ID in future > silicon. An example from two shipping platforms: > > 1). AppliedMicro Mustang: > > [000h 0000 4] Signature : "MCFG" [Memory Mapped > Configuration table] > [004h 0004 4] Table Length : 0000003C > [008h 0008 1] Revision : 01 > [009h 0009 1] Checksum : 4A > [00Ah 0010 6] Oem ID : "APM " > [010h 0016 8] Oem Table ID : "XGENE " > [018h 0024 4] Oem Revision : 00000002 > [01Ch 0028 4] Asl Compiler ID : "INTL" > [020h 0032 4] Asl Compiler Revision : 20140724 > > 2). HP(E[0]) Moonshot: > > [000h 0000 4] Signature : "MCFG" [Memory Mapped > Configuration table] > [004h 0004 4] Table Length : 0000003C > [008h 0008 1] Revision : 01 > [009h 0009 1] Checksum : 48 > [00Ah 0010 6] Oem ID : "APM " > [010h 0016 8] Oem Table ID : "XGENE " > [018h 0024 4] Oem Revision : 00000001 > [01Ch 0028 4] Asl Compiler ID : "HP " > [020h 0032 4] Asl Compiler Revision : 00000001 > > I have pinged the semiconductor (Applied) and insisted upon a written > plan (which I have now) for handling the first affect generation(s) and > future chip roadmap stuff, along with how they plan to upstream this > immediately as part of this thread. I have also done similar with each > of the other vendors (this is something ARM or Linaro should be doing). > But I particularly care about X-Gene because I want it to be loved as > shipping silicon in production systems (Moonshot) that are sitting and > waiting in the Fedora Phoenix datacenter in large quantity to come > online if only an upstream kernel would actually boot on them :) Thanks for the MCFG information on Moonshot system, Jon. I will make sure the posted quirk for X-Gene takes care for HPE Moonshot system as well. Regards, Duc Dang. > >> However I guess that if in FW they have defined oem_table_id properly >> they should be able to use this mechanism without needing to a FW update. > > Correct. > >> Can these vendors confirm this? > > I've checked all current shipping silicon and prototypes. > >> Tomasz do you think this can work for Cavium Thunder? > > Will let the vendors followup directly as well. > > Jon. > > [0] Fortunately that name change doesn't factor when using semiconductor > matching...hopefully none of the non-complaint IP companies in gen1 > stuff get bought and change their table names. In the unlikely event > that that does happen, I will preemptively beat them up and ensure that > something crazy doesn't happen with table contents. > > -- > Computer Architect | Sent from my Fedora powered laptop