> -----Original Message----- > From: Jon Masters [mailto:j...@redhat.com] > Sent: 22 December 2015 16:45 > To: Gabriele Paoloni; Arnd Bergmann > Cc: Tomasz Nowicki; bhelg...@google.com; will.dea...@arm.com; > catalin.mari...@arm.com; r...@rjwysocki.net; hanjun....@linaro.org; > lorenzo.pieral...@arm.com; ok...@codeaurora.org; > jiang....@linux.intel.com; stefano.stabell...@eu.citrix.com; > robert.rich...@caviumnetworks.com; m...@semihalf.com; liviu.du...@arm.com; > dda...@caviumnetworks.com; t...@linutronix.de; Wangyijing; > suravee.suthikulpa...@amd.com; msal...@redhat.com; linux- > p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro- > a...@lists.linaro.org; jchan...@broadcom.com > Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space > accessors against platfrom specific quirks. > > On 12/22/2015 11:36 AM, Jon Masters wrote: > > On 12/22/2015 04:29 AM, Gabriele Paoloni wrote: > >> Hi Jon, thanks for replying > >> > >>> -----Original Message----- > >>> From: Jon Masters [mailto:j...@redhat.com] > >>> Sent: 21 December 2015 23:11 > >>> To: Arnd Bergmann > >>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelg...@google.com; > >>> will.dea...@arm.com; catalin.mari...@arm.com; r...@rjwysocki.net; > >>> hanjun....@linaro.org; lorenzo.pieral...@arm.com; > >>> ok...@codeaurora.org; jiang....@linux.intel.com; > >>> stefano.stabell...@eu.citrix.com; robert.rich...@caviumnetworks.com; > >>> m...@semihalf.com; liviu.du...@arm.com; dda...@caviumnetworks.com; > >>> t...@linutronix.de; Wangyijing; suravee.suthikulpa...@amd.com; > >>> msal...@redhat.com; linux- p...@vger.kernel.org; > >>> linux-arm-ker...@lists.infradead.org; linux- a...@vger.kernel.org; > >>> linux-kernel@vger.kernel.org; linaro- a...@lists.linaro.org; > >>> jchan...@broadcom.com > >>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space > >>> accessors against platfrom specific quirks. > >>> > >>> Sorry for top-posting. A quick note that SMBIOS3 is required by > SBBR > >>> so it can be presumed that compliant platforms will provide quirks > via DMI. > >> > >> Ok so you completely clarified my question 1). Many Thanks for this > > > > No problem. One of the (many) reasons I pushed for requiring > > SMBIOS/DMI in SBBR (I was lead author of one of the early drafts of > > that document) was to make the experience ultimately equivalent > across architectures. > > We already know how to do quirks and handle platform deviations, and > > the major Operating System vendors did not want to reinvent the wheel. > > Additional: it is clear that more prescription is required to get the > vendors onto the bandwagon that we have with other architectures (e.g. > that other one). So there will be a Red Hat "ARM server whitepaper" > coming in the early new year that will include the kind of "server 101" > material we want to make sure people know. Things like making sure you > implement and test PCIe correctly, handle backward compatibility (you > will build hardware in the future that runs my existing OS release), > design the hardware to allow for workarounds later, etc. I expect some > other Operating System vendors to be involved in reviewing that. > > Ultimately my objective is to make this whole thing dull and boring. > You will get RHEL(SA)/upstream kernels and it will either boot or it > will not. If it does not boot, vendor X screwed up their hardware. We > know this story, it's been this way for over a decade already, and that > is exactly how it is going to be with ARM servers shortly.
Ok got it. Many Thanks Gab > > Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
