From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756439AbbAPPyv (ORCPT ); Fri, 16 Jan 2015 10:54:51 -0500 Received: from mout.kundenserver.de ([212.227.17.10]:52922 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751690AbbAPPyu (ORCPT ); Fri, 16 Jan 2015 10:54:50 -0500 From: Arnd Bergmann To: linaro-acpi@lists.linaro.org Cc: Will Deacon , Catalin Marinas , Yijing Wang , Rob Herring , Timur Tabi , ACPI Devel Mailing List , Tom Lendacky , "phoenix.liyi@huawei.com" , Robert Richter , Jason Cooper , Marc Zyngier , "jcm@redhat.com" , Mark Brown , Bjorn Helgaas , "linux-arm-kernel@lists.infradead.org" , Randy Dunlap , "Rafael J. Wysocki" , Linux Kernel Mailing List , Olof Johansson Subject: Re: [Linaro-acpi] [PATCH v7 00/17] Introduce ACPI for ARM64 based on ACPI 5.1 Date: Fri, 16 Jan 2015 16:53:33 +0100 Message-ID: <1887263.kzglbjcc0t@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20150116154913.GW7091@arm.com> References: <1421247905-3749-1-git-send-email-hanjun.guo@linaro.org> <1809831.d9GPSfLUEN@wuerfel> <20150116154913.GW7091@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:bwTF70bGhHtUtZGUXhtUmUioGOKJPQiyxKfDfEEVuTJAWVnnP/l ZT/4GVzS1NN6fGyX1FJQfdLn5llvPzbfw0n6z/+5zFji4y9kGGZRiTusJYisvJWdV7ixI4b /XfyrolBzz/kLF37VaY+zoVHZKRoO6YQ6X3ATlZGr2IQ1SBIHsMcZudIr+L/7fKqdmyRO6U vP8RMsVs3CnGcWlhe5tNg== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 16 January 2015 15:49:13 Will Deacon wrote: > > The on-board ethernet on Seattle requires the driver to program its AXI > attributes, so configuring it to be a coherent master actually means > "program the same cacheable AXI settings as you have on the CPU". That > sounds like Linux should be doing it to me, but even if the firmware takes > a guess at "normal cacheable WBRWA", it's not clear to me whether that > register persists across things like adapter reset. > > Tom? > > There's also the situation where the firmware hasn't initialised the > register and Linux realises this during probe. What should it do then? In case of a 10gbit ethernet adapter, there really should be no question regarding whether to set it coherent or not. Can't Linux just always set this AXI attribute in the driver? Arnd