From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15675C48BDF for ; Thu, 24 Jun 2021 11:42:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E3E4F613B9 for ; Thu, 24 Jun 2021 11:42:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229630AbhFXLo0 (ORCPT ); Thu, 24 Jun 2021 07:44:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:44302 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229445AbhFXLoW (ORCPT ); Thu, 24 Jun 2021 07:44:22 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 81A15613B9; Thu, 24 Jun 2021 11:42:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1624534923; bh=qJmXgN7CIXV0tAhUIHPht8LddBB9hfJphL9CMTVxFb8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VlEpJ2aKToVGA22EHZeTVKlQFXxm7cxvLCefs+NKe/FGOi15cc0+MGRNK1Euf2Oi5 9MTzqZNJSeeCF5lbTPZmQpImOvopB8MPsbFOg1MfGGy38d6bd3gRIjgM7wN4YRt9t5 vNzYIzadfI+zb2rnb+Nni0mnqO9bN32nKDskPkEw= Date: Thu, 24 Jun 2021 13:42:00 +0200 From: "gregkh@linuxfoundation.org" To: Hans-Gert Dahmen Cc: David Laight , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "philipp.deppenwiese@immu.ne" Subject: Re: [PATCH] firmware: export x86_64 platform flash bios region via sysfs Message-ID: References: <20210622142334.14883-1-hans-gert.dahmen@immu.ne> <5ee9e467bfbf49d29cb54679d2dce1c3@AcuMS.aculab.com> <7f076743-3dd6-d397-d3cc-8c31e080695c@immu.ne> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7f076743-3dd6-d397-d3cc-8c31e080695c@immu.ne> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 24, 2021 at 01:20:28PM +0200, Hans-Gert Dahmen wrote: > > On 23.06.21 14:40, gregkh@linuxfoundation.org wrote: > > > On Wed, Jun 23, 2021 at 02:17:54PM +0200, Hans-Gert Dahmen wrote: > > > Hi, > > > Yes. The window is part of the DMI interface and the south bridge or PCH > > > converts the bus cycles to SPI reads. It is because this region contains the > > > reset vector address of your CPU and the very first instruction it executes > > > after a reset when the internal setup is done will actually be loaded from > > > the serial SPI bus. It is AFAIK part of AMD's original 64-bit specification. > > The point is that you will never be able to do this for all devices. > > You should ONLY be allowed to have this module bind to the hardware that > > you KNOW it will work with. > > > > So please work off of a DMI table, or some such hardware description, > > instead of just blindly enabling it for all systems. > > I was referring to the DMI/QPI/PCI interface that connects the ICH/PCH/south > bridge to the CPU. I have gone through all datasheets of intel ICH and PCH > and they state that the address range from 0xff000000 through 0xffffffff is > a fixed mapping that cannot be changed (no BAR) except for the original ICH > (dating back to 1999) where the window is only 8MB. The original ICH is for > 32-bit systems only so all 64-bit Intel systems that exist have this > feature. I have talked to somebody who works with future Intel hardware and > the person indicated that it is not likely to change. > > This is why I made the module depend on X86_64. I still have to do the same > complete research for AMD systems which is a little harder to do, so I am > proposing to check if the root complex has Intel's vendor ID and only load > the module on 64-bit Intel systems until I can confirm the same behavior for > all 64-bit AMD systems. Then I could check if the root complex is Intel or > AMD. Would that suffice as "some such hardware description"? That would help, yes. Especially given the other types of Intel-like cpus we are seeing in the wild these days (not all the world is Intel and AMD...) But what is this really going to be used for? What userspace tools need this type of direct access to do something useful? thanks, greg k-h