Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp1668889ybg; Wed, 29 Jul 2020 22:33:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyE44LOeYUKXkjvZUGjKyKNNtdOG6oVd4NM6krWxq+isufILzBCH0fCCrJucCYNpnjZP9TI X-Received: by 2002:a05:6402:17ab:: with SMTP id j11mr1096391edy.28.1596087180022; Wed, 29 Jul 2020 22:33:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596087180; cv=none; d=google.com; s=arc-20160816; b=GnJxBBpw8nngWYWq7NaJEz7VOGmLCN9CyxmlqiUXKdACqUDE2JK3dsy8mr06qnDIPq dmVs8I0UHvkCNCHy+5r4CtX6Mmc5tqgpG1Nt+XkG5oqJVBHqTRZtydX3lhrrRTd+jM8p U3CsxWFIpekO9qzEBCy0Tj+OhMnbcXDIN+TfFrpMM22XtHp55LhFSMnsxQPef+MiglBc lPzhai+CIW6TbYPKNBWtcSSJV/nTKW6+TvZKjILwpepbKJmvojOS0DFa4d4GIlF5GJfn 4o6Iq8YAxITxqymUtMub1F0bKtXybu2hoVqPd44/VFcG+KVTbdR8yAIPtamKrKglaO9m I0EQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=i49fuyEqdW6oc9V+1nGUNuEoqPjEo5XVNW/L+NVjogM=; b=T8pZ7dl1oZUHi4vRjxa9pMcEKLuMz3ofd7PBS9GsmD56mZeUdjJwUivjzWt1gS8lqr FkkRh4zhDHIubNqmhe293BnffVu+aiz1G+Zqlt2gs3WNyKw8Ky87mPfY0LLZOjWsvJwv 6O7hKutvk9+LOxa1fvmDwCrWBRuE96ukNkNqH91FposA5RkpFdXbSoO6r0jPPDnSgCr3 HawOADiK/0B1r/yoIza4CCeIjEGl1OzbiofBjNltgeo8J/adcjZKrCjunBsSwLbRQgrf OQn9gINlVyTtq4p/q7Tb6qw/YEd4/DiQBMpNZA3JUQdBxZ38ju+gvQnPOMdh3KyiX4Zc RcgA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=VpV2wkx3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a26si2447842eds.337.2020.07.29.22.32.38; Wed, 29 Jul 2020 22:33:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=VpV2wkx3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728611AbgG3FbU (ORCPT + 99 others); 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