Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp9561589imu; Sat, 29 Dec 2018 23:27:38 -0800 (PST) X-Google-Smtp-Source: ALg8bN5y1594qfWqs9J5+YxWNUIo/pYRSVbAsRb5bjKXhT4KzjyRXglX3Ih6ZKfkDkushKdw0PlZ X-Received: by 2002:a17:902:3124:: with SMTP id w33mr33606819plb.241.1546154858097; Sat, 29 Dec 2018 23:27:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546154858; cv=none; d=google.com; s=arc-20160816; b=L2B2bvvvenUGr3mpG2mULXq4L8tLpfgh7M42Vw18Jq1CcFcB4uNuXYEWcfacTH0NZt 1E60pzir98CYPk8AKD3eC7u//hjAKbpCOU5ZM2/6Vv16YHLIrxjD7esLdCTTVq0ZC/BW Zk1xAWjuI62zFYO7A3rE6b8Tj8HdwhyRZ1Prpd+QP41Cnual+LjUD5dQ+18F4cRUJ/h4 ptZeKN5AzDy2g7HcXfoIQN9b4JtXXPCmkasxdrpuEdN8crU9ZkkaMBC7XmeaKnO2LNuD Q1Wmuzrf3DO/3PA4TIRwk+/7Jbh85JvsqeAwnJ2YlQZTyppM1vzFWSEoF/OIyQut1RbV cHuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:message-id :in-reply-to:subject:cc:to:from:date; bh=ZRoreNy8vLLfmS4q/A1E0KjEeX2ZHA65/xfKGcGd2T4=; b=pTYZewzh2FLjMlP7OMhrwGoNgotk7QCcbDTuuKzWHXZmIU1933l7UhmpDjOlL0J1L+ lOUwyGfszsSoxD/8qFxnbohxhIHSdFDcoJPG7JnJaVj/y24OHTe2fwli8SLswfo0bxBM ndNwth8bDPcbVP67tjCXWg/xEVzZU2hRvEq570I86AV1Fvm0a0cuH3ouI2YLqtkxytUg SkUlAbySbC9Brq/ye9Ptf+l61rOtodq6bcrbMwWvDVtMXdjNN8YKkkQ44GIgfkpvuSd9 ReOvXG8lkMgzZrRZlq+aJ+A9KpgGIfYguqSj4xm6Yrbar8IGOoTRYsq+DgewU3CDijyD 1hdQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v141si44844799pfc.260.2018.12.29.23.27.08; Sat, 29 Dec 2018 23:27:38 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726051AbeL3HZq (ORCPT + 99 others); Sun, 30 Dec 2018 02:25:46 -0500 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:52436 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726006AbeL3HZp (ORCPT ); Sun, 30 Dec 2018 02:25:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id CCF2021FEF; Sun, 30 Dec 2018 02:25:41 -0500 (EST) Date: Sun, 30 Dec 2018 18:25:38 +1100 (AEDT) From: Finn Thain To: Arnd Bergmann cc: Greg Kroah-Hartman , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Linux Kernel Mailing List , linux-m68k , linuxppc-dev Subject: Re: [PATCH v8 18/25] powerpc: Implement nvram sync ioctl In-Reply-To: Message-ID: References: <3ba1dd965c1097e00463eafe7c7d5fd93bbed836.1545784679.git.fthain@telegraphics.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 29 Dec 2018, Arnd Bergmann wrote: > > --- a/drivers/char/nvram.c > > +++ b/drivers/char/nvram.c > > @@ -48,6 +48,10 @@ > > #include > > #include > > > > +#ifdef CONFIG_PPC > > +#include > > +#include > > +#endif > > > > static DEFINE_MUTEX(nvram_mutex); > > static DEFINE_SPINLOCK(nvram_state_lock); > > @@ -331,6 +335,37 @@ static long nvram_misc_ioctl(struct file *file, unsigned int cmd, > > long ret = -ENOTTY; > > > > switch (cmd) { > > +#ifdef CONFIG_PPC > > + case OBSOLETE_PMAC_NVRAM_GET_OFFSET: > > + pr_warn("nvram: Using obsolete PMAC_NVRAM_GET_OFFSET ioctl\n"); > > + /* fall through */ > > + case IOC_NVRAM_GET_OFFSET: > > + ret = -EINVAL; > > +#ifdef CONFIG_PPC_PMAC > > I think it would make be nicer here to keep the ppc bits in arch/ppc, > and instead add a .ioctl() callback to nvram_ops. > The problem with having an nvram_ops.ioctl() method is the code in the !PPC branch. That code would get duplicated because it's needed by both X86 and M68K, to implement the checksum ioctls. > > @@ -369,12 +405,14 @@ static int nvram_misc_open(struct inode *inode, struct file *file) > > return -EBUSY; > > } > > > > +#ifndef CONFIG_PPC > > /* Prevent multiple writers if the set_checksum ioctl is implemented. */ > > if ((arch_nvram_ops.set_checksum != NULL) && > > (file->f_mode & FMODE_WRITE) && (nvram_open_mode & NVRAM_WRITE)) { > > spin_unlock(&nvram_state_lock); > > return -EBUSY; > > } > > +#endif > > > > diff --git a/include/linux/nvram.h b/include/linux/nvram.h > > index b7bfaec60a43..24a57675dba1 100644 > > --- a/include/linux/nvram.h > > +++ b/include/linux/nvram.h > > @@ -18,8 +18,12 @@ struct nvram_ops { > > unsigned char (*read_byte)(int); > > void (*write_byte)(unsigned char, int); > > ssize_t (*get_size)(void); > > +#ifdef CONFIG_PPC > > + long (*sync)(void); > > +#else > > long (*set_checksum)(void); > > long (*initialize)(void); > > +#endif > > }; > > Maybe just leave all entries visible here, and avoid the above #ifdef checks. > The #ifdef isn't there just to save a few bytes, though it does do that. It's really meant to cause a build failure when I mess up somewhere. But I'm happy to change it if you can see a reason to do so (?) -- > Arnd >