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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 4FAEFC433E0 for ; Thu, 30 Jul 2020 05:32:02 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 1D64B20842 for ; Thu, 30 Jul 2020 05:32:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EjHNQw2+"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="VpV2wkx3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1D64B20842 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6zRT2rpASOK4s5qo3iKJBwd0alXeAKyKR+KcoG867ME=; b=EjHNQw2+ruD1qpKHZRMqpau5O +k/AJSO/ntSwg4aTgAVpLzDu/Om5qpXlLIzmo6SeEHGdKKg8vCSWg6ZTPZurCiWzRWtjSmRm35SXk EQskmp99iVVenyd6/wOXmhwSBHF2xh9HMpXV1MALMfhl2OgTRSa1oZ0JWMRyWRi6uZ53P2ZXDe5dm WDnTCIn6gvLSuYnFWRkafxhy1r6fB3m7SmdNEKOpmjA8z3rfE45YNxUNhUiaW1i7FK3nMxg7TGY0/ FPR9bA7daLh3v+Lz+nabWNt6il6aT9ebllCWfBtcUPkNukSPs9dkTG9eSCd9l2C3UvgsW+DtdVXfs HW1GG8/rA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k11A3-0005rN-H0; Thu, 30 Jul 2020 05:31:23 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k11A0-0005qt-3V for linux-mtd@lists.infradead.org; Thu, 30 Jul 2020 05:31:21 +0000 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 750DB20842; Thu, 30 Jul 2020 05:31:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596087079; bh=Dvo2/mKtVKTG0GN4Ptkmba8k3YXSZeccrO2bOD3DvS4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VpV2wkx35kvXQjleYoNCJcsBGjTxjZ5HYiB+hNWmiqiK671/+WrR5JYbDKTda0Ofe iJ2LMYGqOXjIwTDvGjHSf7jefTImzSy1nmFR/UX5WXw1aifCej7tQlxaK4nZGW+MhU W9NJrpkDjBfmT5UOj2a/UE8guQgDRF6qPj9UbvVE= Date: Thu, 30 Jul 2020 07:31:08 +0200 From: Greg Kroah-Hartman To: Daniel Gutson Subject: Re: [PATCH] Module argument to control whether intel-spi-pci attempts to turn the SPI flash chip writeable Message-ID: <20200730053108.GA3861609@kroah.com> References: <20200724212853.11601-1-daniel.gutson@eclypsium.com> <20200725055649.GA1047853@kroah.com> <20200726071723.GB441916@kroah.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200730_013120_377562_E6FFED92 X-CRM114-Status: GOOD ( 32.22 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Richard Hughes , Vignesh Raghavendra , Arnd Bergmann , Tudor Ambarus , Richard Weinberger , Boris Brezillon , "linux-kernel@vger.kernel.org" , linux-mtd , Miquel Raynal , Alex Bazhaniuk , Mika Westerberg Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Wed, Jul 29, 2020 at 05:54:35PM -0300, Daniel Gutson wrote: > On Mon, Jul 27, 2020 at 12:31 PM Daniel Gutson wro= te: > > > > On Mon, Jul 27, 2020 at 12:15 PM Arnd Bergmann wrote: > > > > > > On Mon, Jul 27, 2020 at 5:05 PM Daniel Gutson = wrote: > > > > On Sun, Jul 26, 2020 at 4:17 AM Greg Kroah-Hartman wrote: > > > >> > > > >> On Sat, Jul 25, 2020 at 02:20:03PM -0300, Daniel Gutson wrote: > > > >> > El s=E1b., 25 jul. 2020 2:56 a. m., Greg Kroah-Hartman < > > > >> > gregkh@linuxfoundation.org> escribi=F3: > > > >> > > > > >> > > > > >> > 1) I just did the same that intel-spi.c does. > > > >> > > > >> No need to copy bad examples :) > > > > > > > > > > > > Didn't know it was a bad example. What's is the current modern mech= anism that replaces initialization-time configuration? > > > > > > I'd say you'd generally want this to be a per-instance setting, which > > > could be a sysfs attribute of the physical device, or an ioctl for an > > > existing user space abstraction. > > > > But still, they are not equivalent. The initial configuration remains > > constant for the rest of the life of the driver, whereas the > > sysfs attribute is set after the initialization and can be re-set over > > time. I'm not asking module parameters "to come back" if > > they are now considered obsolete, I'm just trying to understand. > > > > > > > > In the changelog, you should also explain what this is used for. Do > > > you actually want to write to a device that is marked read-only, or > > > are you just trying to make the interface more consistent between the > > > two drivers? > > > > The device can either be locked or unlocked. If it is unlocked, it can > > be set writable depending on the module > > argument in intel-spi, or straight writable in intel-spi-pci. Which is > > dangerous. > > I wanted to make, as you say, the interface consistent. > > Exposing an interface to the user (via a sysfs attribute) to try to > > make the driver writable is definitively a bad idea. > > I'd rather do nothing (no module arg) rather than open that > > here-be-dragons door. > = > ping. > This is a real existing problem that I'm trying to address. > There's currently no way to prevent the kernel to try to turn > the SPI flash chip writable for the device IDs handled by > intel-spi-pci. And allowing userspace to switch it between > writable/non-writable is not an option. > What other mechanism can I use other than the module parameter, Again, module parameters are working on a per-chunk-of-code basis, while you want to work on a per-device basis, which is why you should not use a module parameter. good luck! greg k-h ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 98B8FC433DF for ; Thu, 30 Jul 2020 05:31:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 737DB2173E for ; Thu, 30 Jul 2020 05:31:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596087081; bh=Dvo2/mKtVKTG0GN4Ptkmba8k3YXSZeccrO2bOD3DvS4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=KZBZ3aWgj6xjYqrkvpA/o2mRKwiySn0AWDbShQbd+Yja2BI4b4fMz/+r5WIV8Zu0L Hy9AuMxYY3uRaVIubmSRCITC9WbagdLxyJg4uPIei265JqgENjlGAGoqQdpFAc5oeo CuKY60jbrfYFRQpwghAZkgpigZOabdjz1kaZPJB0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728615AbgG3FbU (ORCPT ); Thu, 30 Jul 2020 01:31:20 -0400 Received: from mail.kernel.org ([198.145.29.99]:54974 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726287AbgG3FbT (ORCPT ); Thu, 30 Jul 2020 01:31:19 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 750DB20842; Thu, 30 Jul 2020 05:31:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596087079; bh=Dvo2/mKtVKTG0GN4Ptkmba8k3YXSZeccrO2bOD3DvS4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VpV2wkx35kvXQjleYoNCJcsBGjTxjZ5HYiB+hNWmiqiK671/+WrR5JYbDKTda0Ofe iJ2LMYGqOXjIwTDvGjHSf7jefTImzSy1nmFR/UX5WXw1aifCej7tQlxaK4nZGW+MhU W9NJrpkDjBfmT5UOj2a/UE8guQgDRF6qPj9UbvVE= Date: Thu, 30 Jul 2020 07:31:08 +0200 From: Greg Kroah-Hartman To: Daniel Gutson Cc: Arnd Bergmann , Tudor Ambarus , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Mika Westerberg , Boris Brezillon , linux-mtd , "linux-kernel@vger.kernel.org" , Alex Bazhaniuk , Richard Hughes Subject: Re: [PATCH] Module argument to control whether intel-spi-pci attempts to turn the SPI flash chip writeable Message-ID: <20200730053108.GA3861609@kroah.com> References: <20200724212853.11601-1-daniel.gutson@eclypsium.com> <20200725055649.GA1047853@kroah.com> <20200726071723.GB441916@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 29, 2020 at 05:54:35PM -0300, Daniel Gutson wrote: > On Mon, Jul 27, 2020 at 12:31 PM Daniel Gutson wrote: > > > > On Mon, Jul 27, 2020 at 12:15 PM Arnd Bergmann wrote: > > > > > > On Mon, Jul 27, 2020 at 5:05 PM Daniel Gutson wrote: > > > > On Sun, Jul 26, 2020 at 4:17 AM Greg Kroah-Hartman wrote: > > > >> > > > >> On Sat, Jul 25, 2020 at 02:20:03PM -0300, Daniel Gutson wrote: > > > >> > El sáb., 25 jul. 2020 2:56 a. m., Greg Kroah-Hartman < > > > >> > gregkh@linuxfoundation.org> escribió: > > > >> > > > > >> > > > > >> > 1) I just did the same that intel-spi.c does. > > > >> > > > >> No need to copy bad examples :) > > > > > > > > > > > > Didn't know it was a bad example. What's is the current modern mechanism that replaces initialization-time configuration? > > > > > > I'd say you'd generally want this to be a per-instance setting, which > > > could be a sysfs attribute of the physical device, or an ioctl for an > > > existing user space abstraction. > > > > But still, they are not equivalent. The initial configuration remains > > constant for the rest of the life of the driver, whereas the > > sysfs attribute is set after the initialization and can be re-set over > > time. I'm not asking module parameters "to come back" if > > they are now considered obsolete, I'm just trying to understand. > > > > > > > > In the changelog, you should also explain what this is used for. Do > > > you actually want to write to a device that is marked read-only, or > > > are you just trying to make the interface more consistent between the > > > two drivers? > > > > The device can either be locked or unlocked. If it is unlocked, it can > > be set writable depending on the module > > argument in intel-spi, or straight writable in intel-spi-pci. Which is > > dangerous. > > I wanted to make, as you say, the interface consistent. > > Exposing an interface to the user (via a sysfs attribute) to try to > > make the driver writable is definitively a bad idea. > > I'd rather do nothing (no module arg) rather than open that > > here-be-dragons door. > > ping. > This is a real existing problem that I'm trying to address. > There's currently no way to prevent the kernel to try to turn > the SPI flash chip writable for the device IDs handled by > intel-spi-pci. And allowing userspace to switch it between > writable/non-writable is not an option. > What other mechanism can I use other than the module parameter, Again, module parameters are working on a per-chunk-of-code basis, while you want to work on a per-device basis, which is why you should not use a module parameter. good luck! greg k-h