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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 98495C43387 for ; Wed, 2 Jan 2019 22:25:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6CFC1206C0 for ; Wed, 2 Jan 2019 22:25:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729754AbfABWZN (ORCPT ); Wed, 2 Jan 2019 17:25:13 -0500 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:33224 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729719AbfABWZM (ORCPT ); Wed, 2 Jan 2019 17:25:12 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id D1D4F29FC6; Wed, 2 Jan 2019 17:25:08 -0500 (EST) Date: Thu, 3 Jan 2019 09:25:08 +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 Tue, 1 Jan 2019, I wrote: > > There are no [nvram] ioctls common to all architectures. So your example > becomes, > > static long nvram_misc_ioctl(struct file *file, unsigned int cmd, > unsigned long arg) > { > if (ops->ioctl) > return ops->ioctl(file, cmd, arg); > return -ENOTTY; > } > > And then my objection is the same: m68k and x86 now have to duplicate > their common ops->ioctl() implementation. > Perhaps code duplication is inevitable. Either you punt the ioctl implementation from the char misc driver (and duplicate that ioctl implementation under arch/) or else you duplicate the char misc driver. Maybe this dilemma explains the situation we have now* which is duplicated drivers (drivers/char/nvram.c and drivers/char/generic_nvram.c). But this explanation doesn't seem to offer any solution. Re-using either of the existing drivers seems to be impossible. Different interpretations of the NVRAM Kconfig symbol accross the tree are not helping. And having separate Kconfig symbols (NVRAM and GENERIC_NVRAM) for the two drivers doesn't help either. But maybe the NVRAM symbol can be dropped from arch/powerpc and all of the powerpc drivers... * Actually, we presently have duplicated misc device drivers AND duplicated ioctl implementations too, for good measure. See arch/powerpc/kernel/nvram_64.c and drivers/char/generic_nvram.c. -- 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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable 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 3174DC43387 for ; Wed, 2 Jan 2019 22:27:11 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A64DD206C0 for ; Wed, 2 Jan 2019 22:27:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A64DD206C0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 43VQdm3Mz5zDqLd for ; Thu, 3 Jan 2019 09:27:08 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: lists.ozlabs.org; spf=none (mailfrom) smtp.mailfrom=telegraphics.com.au (client-ip=98.124.60.144; helo=kvm5.telegraphics.com.au; envelope-from=fthain@telegraphics.com.au; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Received: from kvm5.telegraphics.com.au (kvm5.telegraphics.com.au [98.124.60.144]) by lists.ozlabs.org (Postfix) with ESMTP id 43VQbZ28bXzDqJM for ; Thu, 3 Jan 2019 09:25:13 +1100 (AEDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id D1D4F29FC6; Wed, 2 Jan 2019 17:25:08 -0500 (EST) Date: Thu, 3 Jan 2019 09:25:08 +1100 (AEDT) From: Finn Thain To: Arnd Bergmann 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 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Greg Kroah-Hartman , Linux Kernel Mailing List , linux-m68k , Paul Mackerras , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, 1 Jan 2019, I wrote: > > There are no [nvram] ioctls common to all architectures. So your example > becomes, > > static long nvram_misc_ioctl(struct file *file, unsigned int cmd, > unsigned long arg) > { > if (ops->ioctl) > return ops->ioctl(file, cmd, arg); > return -ENOTTY; > } > > And then my objection is the same: m68k and x86 now have to duplicate > their common ops->ioctl() implementation. > Perhaps code duplication is inevitable. Either you punt the ioctl implementation from the char misc driver (and duplicate that ioctl implementation under arch/) or else you duplicate the char misc driver. Maybe this dilemma explains the situation we have now* which is duplicated drivers (drivers/char/nvram.c and drivers/char/generic_nvram.c). But this explanation doesn't seem to offer any solution. Re-using either of the existing drivers seems to be impossible. Different interpretations of the NVRAM Kconfig symbol accross the tree are not helping. And having separate Kconfig symbols (NVRAM and GENERIC_NVRAM) for the two drivers doesn't help either. But maybe the NVRAM symbol can be dropped from arch/powerpc and all of the powerpc drivers... * Actually, we presently have duplicated misc device drivers AND duplicated ioctl implementations too, for good measure. See arch/powerpc/kernel/nvram_64.c and drivers/char/generic_nvram.c. --