Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2007137pxa; Mon, 24 Aug 2020 02:17:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwiKXDKKVrT3OJEeOY0Ce5WAMcH7SUoPwwedF5Fkx36q6ErVjGHKN4BBY1U3leI3olpbDQo X-Received: by 2002:a17:906:289a:: with SMTP id o26mr4575754ejd.309.1598260626604; Mon, 24 Aug 2020 02:17:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598260626; cv=none; d=google.com; s=arc-20160816; b=uYmPrtEMsQ0VcjibbdyNGHUwjTJvMBEcn52KzUKeMECpiDmuysMw8TLdajc+S7X0Di 8yCx2EeC0XSMZK1RUcct68j9r5rlguAkfdxWa5YyeJCMA/mgbIzMhMqSAuBSDxac6P0r /v2iPmn0wPnM25ZC7Fzq0VeeqznAq+PPYBJG+YHPICl8GK4mnQNSrqw3OlHE7tvHur2c s93vqucwzfccBR4eVZ5mQqibzVoRE2fzGP/WZj41c3Nc9d8Ey0hb3lfi36Y/BessUDes H8YVQTXUOTfj13FhuoG11+Prwc0U+abButwJgR3HeFELGSHk+PWI43/29oazQlaUhjud YKsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=TYdqklXrEldEjZQgk0XbAqXC5J9mIpMcXcj6ZnlHAMc=; b=FpW5yRAWfiO42etpFgFO/FysB4QPLDPARBYgnd6D1e4eXz2G9T/msnnrJBTjXDVgmz NgfXTKWQlGrtpTIb5nF+i4kzVL2+3Xf2cv994K8hSV5jkDlJJf7+lqqXREAw1COrUyyX Qyd5uygk8uzs64/IP5DkQBJoY4PqE9GhTSFdLCf9AptyU+g4pESyo7yHqCQTPXrF8uNu 6iNw1nxs3LH0D1C7ozrhn9RseA7r1OGLYzfutDigN16XnYjTBs7zbbbozk+P2b3TNt4z byN/NNPug2mdF87/em+URRt4+tHJcC43nV316NZ1PoZmK9gAWr93gZkDSFrCLkCf+DVj BJYQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com 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.16.44; Mon, 24 Aug 2020 02:17:06 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730202AbgHXJQQ (ORCPT + 99 others); Mon, 24 Aug 2020 05:16:16 -0400 Received: from mga07.intel.com ([134.134.136.100]:20462 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729832AbgHXJPr (ORCPT ); Mon, 24 Aug 2020 05:15:47 -0400 IronPort-SDR: rYN1T3dFnLRSwhyS870Xw/VDuojw4+1XTAQduL9hzRj+nZPJAb6EiGvKIJAdH2v63mAniPQ8CF je38qDQXA3Gg== X-IronPort-AV: E=McAfee;i="6000,8403,9722"; a="220135688" X-IronPort-AV: E=Sophos;i="5.76,347,1592895600"; d="scan'208";a="220135688" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Aug 2020 02:15:47 -0700 IronPort-SDR: Gy6kGGugzZLcfjZhdktYlsZL/u42rahULw/UFaWwpFFyVMGMZTAs7Y3XCgwQYCYe4N5IBMT2P+ DBGlxuDDWzvg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,347,1592895600"; d="scan'208";a="402270489" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.163]) by fmsmga001.fm.intel.com with SMTP; 24 Aug 2020 02:15:43 -0700 Received: by lahna (sSMTP sendmail emulation); Mon, 24 Aug 2020 12:15:42 +0300 Date: Mon, 24 Aug 2020 12:15:42 +0300 From: Mika Westerberg To: Arnd Bergmann 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 Subject: Re: [PATCH] mtd: spi-nor: intel-spi: Do not try to make the SPI flash chip writable Message-ID: <20200824091542.GC1375436@lahna.fi.intel.com> References: <20200819065721.GA1375436@lahna.fi.intel.com> <20200819091123.GE1375436@lahna.fi.intel.com> <20200824082227.GU1375436@lahna.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo 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: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).