Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2015144pxa; Mon, 24 Aug 2020 02:35:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4xhEF4OnQ0UeqLRRO0bCPHvjlTNjeJou5dc3NSA70rZoScGCzZoit6GooOt9zXKJrtHAy X-Received: by 2002:a05:6402:1a46:: with SMTP id bf6mr4419982edb.284.1598261705163; Mon, 24 Aug 2020 02:35:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598261705; cv=none; d=google.com; s=arc-20160816; b=YXl7uwKAlxheBYjpQhW7ilZchLj0ux2dSF/RHi2I8YUcOzxDyD9T8ziQNh6UidVBBg pvaI+z8+gaAZ1gTq0ay/WZv+qBDY8GQyorC84fXT0yMsBHUL9EhENYLfl57bJKsl9hRd cvPhQjJly0XSly2nFSZSX08XN5WNL//8Vpz4lV8A4u3+08Th7Y+leKyxEvcvnemedXKq Eam9IujVTtQIuAmjR4DCN5TlZJB79836nTZ9Q3jdy6wMCEteP6b7+EdG7JBVsj1MIclR RMPq8huMHGjPR54FzfHyaVsjl6WL9R8Bgc0TDCgBY+7EfXoUFoXKsaEGlsle6bgPZQuN Hu1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=xC6W/od4+gn+oN6TUYyujTcu9vE42RRECqv0GzFZjPw=; b=YuyBzxR2MPhf3+LVbMjjqWiGPvZb9iFXTRINo5u1PrH1vZ0xj0V3qEXhk+tQ2Y8BHf 0y2++pLY7My+aLQHDtWZUqH/fxftsDHj3UDS/nyCewCAC2eDgstP36/5tzN6megnGVHD g9VNY+VltqYUgHr9MB3yvW3S6FkAJNB9juHF/HWB1/xaB88JkJIKVGFy4flFofVr60AZ vR8M74pw3lkuRKBTr7FI9OQ50AJkG787J2HfwsoG9JjG54Y33cloBq5H7G4zdmWYSOWf HzXlmTqcl1xPwnrPTw4S3IAm2rm689W9p6FLnz1brdM9M+AyqICp+zJaHzmUdsmoD8eR wgsQ== ARC-Authentication-Results: i=1; mx.google.com; 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 t19si6206707ejd.62.2020.08.24.02.34.42; Mon, 24 Aug 2020 02:35:05 -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; 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 S1729886AbgHXJcK (ORCPT + 99 others); Mon, 24 Aug 2020 05:32:10 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:42443 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727979AbgHXJb7 (ORCPT ); Mon, 24 Aug 2020 05:31:59 -0400 Received: from mail-qk1-f175.google.com ([209.85.222.175]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1Mmhs6-1ksanj0nG2-00jr41 for ; Mon, 24 Aug 2020 11:31:57 +0200 Received: by mail-qk1-f175.google.com with SMTP id o64so646362qkb.10 for ; Mon, 24 Aug 2020 02:31:57 -0700 (PDT) X-Gm-Message-State: AOAM533v6SWiioqxbULtDg4BqOcTc4TY3R0RenIjEdid64IdsWLIoCOX pb1lmDDAawNZuBLueNg7hVWqUgu1sYZND2rf1JI= X-Received: by 2002:a37:6351:: with SMTP id x78mr3784606qkb.394.1598261516064; Mon, 24 Aug 2020 02:31:56 -0700 (PDT) MIME-Version: 1.0 References: <20200819065721.GA1375436@lahna.fi.intel.com> <20200819091123.GE1375436@lahna.fi.intel.com> <20200824082227.GU1375436@lahna.fi.intel.com> <20200824091542.GC1375436@lahna.fi.intel.com> In-Reply-To: <20200824091542.GC1375436@lahna.fi.intel.com> From: Arnd Bergmann Date: Mon, 24 Aug 2020 11:31:40 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mtd: spi-nor: intel-spi: Do not try to make the SPI flash chip writable To: Mika Westerberg Cc: Daniel Gutson , Tudor Ambarus , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Boris Brezillon , linux-mtd , "linux-kernel@vger.kernel.org" , Alex Bazhaniuk , Richard Hughes , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:9MRxlt0Co5Qo01nf04WGTXUzmZCIo6K9bDq3wim04WYi5XrZ6CE PbMjkFKybNuz2ibgHMd/zpbK1sklOCs6OpJF3ujMQ2Xurf7zzV0vBMi5EyxHmMW/grUlokm nIyiePVI8AaC13W5hv3pcxtfAdkN8ANRrFkVTVD/emBnA817EDcSWwtf+2y2OJVaHqUvC+L ylJiIO7E5TofA8hRtvD0w== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Rwmn3vxa2Gk=:iXkpmQ4yLDYnBpCgaVdEOb X08T6Ooy4oQn6XKeWLG9HTBQ/L/kT2be9yq6Jy4/kc6tQ/io/UfMEYVPUqE3TdA9lgzempoD9 AXVt9TPYFz/Atrlp6q82siJIWwz2j5M2TrHzKeoRpZkyMXGsd7AADQPnZrF4YZrpvcjk31os7 4zTRRQo6L0WI5PO/04YgZBofUGG48fUp/3kVMCJZmQ82eal7jlfcFM9m+jjf5wE/fmu8K+rE2 15JgemkunSNusFa7wQmz/5BZuruWysDAPgJ8eGlN7flke7w7/if67eX8DyucNgPtpR4yAbpFb UfDrVRHaiSaeMisQLSKMgw+Oc99yG25Jk95mDt2QaJBvM3bp/pEbovLwUibtqF9bRm3+OP6Sv hW3QlAhKkiqCIJSmRVy/JCscFk0OdFkBp0V/0UpeZ/2S2lChJjUsCxqg5AQlPj7QkL9upmD/7 FQzXn/XHA66ZS2nOsHM5usLL0nqTHn2BD5bq2Lc3T2BFg8QS0GiMfGaWG9VMGqeWq80pDXJiw JePwbi386jB4u9tULim0RoFmDWrJ5/v3awUSL1KVXMdVt1Gzp4U/adpCnqH5SLEeawEoYN/BS qRaHBVqhcZa3wVYzXgi1EsgK0vhuKsJ48C2l7mBCKpnJ/UL/pKsmjAxvN4PYkIOiXe9Y/ZZyx ETZSBF1YC3DGIOn1LV74geDNGnsLWblAyb67ewwOoz7If2FXelI6AG77v9umXt5glOx2ayQZb gs9Wn7exvQMY4DmrYfiQndGJdAdpUEjHgQPinOtIDzu8OqLtsnEUOee9Orsl/KFdXPRdznwsb PR0vx+DxChrOPyFaYawgL3qsR53OqEvWaFyZLGjbjFiKxf6MR7DBoNrrUqPgy3dn74AR19uKL JxxmokeUv37hxNauTEOkjOC7WlIUQEiEOhRN/nvU5hm+mOhoiHAXZ+zbHmdAdYCvSvf4xe1v7 dxzCvftKOfoMvNi4Vh4vxddcowYToKgGIrx30YfRaCLZ0tufm2VIl Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 24, 2020 at 11:15 AM Mika Westerberg wrote: > On Mon, Aug 24, 2020 at 11:08:33AM +0200, Arnd Bergmann wrote: > > On Mon, Aug 24, 2020 at 10:22 AM Mika Westerberg > > wrote: > > > On Sat, Aug 22, 2020 at 06:06:03PM +0200, Arnd Bergmann wrote: > > > > On Wed, Aug 19, 2020 at 11:11 AM Mika Westerberg > > > > > > > > The mtd core just checks both the permissions on the device node (which > > > > default to 0600 without any special udev rules) and the MTD_WRITEABLE > > > > on the underlying device that is controlled by the module parameter > > > > in case of intel-spi{,-platform,-pci}.c. > > > > > > OK, thanks. > > > > > > Since we cannot really get rid of the module parameter (AFAIK there are > > > users for it), I still think we should just make the "writeable" to > > > apply to the PCI part as well. That should at least make it consistent, > > > and it also solves Daniel's case. > > > > Can you explain Daniel's case then? I still don't understand what he > > actually wants. > > > > As I keep repeating, the module parameter *does* apply to the pci > > driver front-end since it determines whether the driver will disallow > > writes to the mtd device without it. The only difference is that the pci > > driver will attempt to set the hardware bit without checking the > > module parameter first, while the platform driver does not. If the > > module parameter is not set however, the state of the hardware > > bit is never checked again. > > I think Daniel wants the PCI driver not to set the hardware bit by > default (same as the platform driver). Sure, but *why*? Arnd