From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754774AbcKJIiy (ORCPT ); Thu, 10 Nov 2016 03:38:54 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:52397 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753880AbcKJIiw (ORCPT ); Thu, 10 Nov 2016 03:38:52 -0500 X-Greylist: delayed 493 seconds by postgrey-1.27 at vger.kernel.org; Thu, 10 Nov 2016 03:38:52 EST Date: Thu, 10 Nov 2016 09:30:37 +0100 From: Thomas Petazzoni To: Jason Gunthorpe Cc: Jason Cooper , Bjorn Helgaas , Gregory CLEMENT , linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] PCI: mvebu: Take control of mbus windows setup by the firmware Message-ID: <20161110093037.376ae79d@free-electrons.com> In-Reply-To: <20161026174440.GA24717@obsidianresearch.com> References: <20161026174440.GA24717@obsidianresearch.com> Organization: Free Electrons X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Wed, 26 Oct 2016 11:44:40 -0600, Jason Gunthorpe wrote: > The firmware may setup the mbus to access PCI-E and indicate this > has happened with a ranges mapping for the PCI-E ID. If this happens > then the mbus setup and the pci dynamic setup conflict, creating > problems. > > Have PCI-E assume control of the firmware specified default mapping by > setting the value of the bridge window to match the firmware mapping. > > Signed-off-by: Jason Gunthorpe Sorry for the late feedback. I am not sure to fully understand what you are trying to do here. However, one thing that confuses me specifically is how can the kernel get any MBus mapping set up by the firmware? Indeed, when the mvebu-mbus driver initializes, it destroys all existing MBus windows that might have been left by the firmware/bootloader: static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus, phys_addr_t mbuswins_phys_base, size_t mbuswins_size, phys_addr_t sdramwins_phys_base, size_t sdramwins_size, phys_addr_t mbusbridge_phys_base, size_t mbusbridge_size, bool is_coherent) [...] for (win = 0; win < mbus->soc->num_wins; win++) mvebu_mbus_disable_window(mbus, win); Why does Linux needs to rely on what the firmware has setup in terms of MBus windows? Why can't Linux just find out the right BAR base/size like it is doing for all other devices? Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com