From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752207AbbIRISK (ORCPT ); Fri, 18 Sep 2015 04:18:10 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:49863 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751764AbbIRISE (ORCPT ); Fri, 18 Sep 2015 04:18:04 -0400 Date: Fri, 18 Sep 2015 18:17:30 +1000 (AEST) From: Finn Thain To: Benjamin Herrenschmidt cc: linux-kernel@vger.kernel.org, linux-m68k@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Paul Mackerras , Michael Ellerman , Arnd Bergmann , Greg Kroah-Hartman , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , linux-fbdev@vger.kernel.org Subject: Re: [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() In-Reply-To: Message-ID: References: <20150712102527.356151908@telegraphics.com.au> <20150712102531.505897278@telegraphics.com.au> <1436874720.3948.252.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ben, On Thu, 16 Jul 2015, I wrote: > On Wed, 15 Jul 2015, I wrote: > > > On Tue, 14 Jul 2015, Benjamin Herrenschmidt wrote: > > > > > Maybe we should have a dedicated accessor for "mac_xpram" ... > > > ... > > The arch_nvram_ops methods don't deal with structures like partitions ... Instead of the accessor you suggested, perhaps it would be better to add a method like arch_nvram_ops.get_partition, to replace the pmac_get_partition() exported function? The call sites for pmac_get_partition() are in the implementation of the IOC_NVRAM_GET_OFFSET ioctl that's used with /dev/nvram, and in pmac_xpram_read(). pmac_xpram_write() has no caller and could be removed. But this doesn't have much to do with linux-fbdev. I think the old NV_CMODE/NV_VMODE issues*, which this patch avoids, are irrelevant to the problem of nvram module re-use, which is the aim of this patch series. But if those issues really are relevant then we should move the discussion to the revised patch, that is, [RFC v6 16/25] powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 and CONFIG_PPC_PMAC and CONFIG_NVRAM. (There was no response to any patch in RFC v6 from any PowerPC maintainers, which is why I've revived this thread.) * https://lists.ozlabs.org/pipermail/linuxppc-dev/2001-November/012662.html -- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Finn Thain Date: Fri, 18 Sep 2015 08:17:30 +0000 Subject: Re: [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram Message-Id: List-Id: References: <20150712102527.356151908@telegraphics.com.au> <20150712102531.505897278@telegraphics.com.au> <1436874720.3948.252.camel@kernel.crashing.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Benjamin Herrenschmidt Cc: linux-kernel@vger.kernel.org, linux-m68k@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Paul Mackerras , Michael Ellerman , Arnd Bergmann , Greg Kroah-Hartman , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , linux-fbdev@vger.kernel.org Hi Ben, On Thu, 16 Jul 2015, I wrote: > On Wed, 15 Jul 2015, I wrote: > > > On Tue, 14 Jul 2015, Benjamin Herrenschmidt wrote: > > > > > Maybe we should have a dedicated accessor for "mac_xpram" ... > > > ... > > The arch_nvram_ops methods don't deal with structures like partitions ... Instead of the accessor you suggested, perhaps it would be better to add a method like arch_nvram_ops.get_partition, to replace the pmac_get_partition() exported function? The call sites for pmac_get_partition() are in the implementation of the IOC_NVRAM_GET_OFFSET ioctl that's used with /dev/nvram, and in pmac_xpram_read(). pmac_xpram_write() has no caller and could be removed. But this doesn't have much to do with linux-fbdev. I think the old NV_CMODE/NV_VMODE issues*, which this patch avoids, are irrelevant to the problem of nvram module re-use, which is the aim of this patch series. But if those issues really are relevant then we should move the discussion to the revised patch, that is, [RFC v6 16/25] powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 and CONFIG_PPC_PMAC and CONFIG_NVRAM. (There was no response to any patch in RFC v6 from any PowerPC maintainers, which is why I've revived this thread.) * https://lists.ozlabs.org/pipermail/linuxppc-dev/2001-November/012662.html --