Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp1974324ybg; Thu, 30 Jul 2020 07:24:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzzEJ7q32QJ07az48dvubECKxKProHLqaQgMdaxYVsqYyG0lB8hVxm3ucyHvQ8wbdigy7BH X-Received: by 2002:a17:906:8d5:: with SMTP id o21mr3022120eje.155.1596119091972; Thu, 30 Jul 2020 07:24:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596119091; cv=none; d=google.com; s=arc-20160816; b=zOCtUNM8DIxdRwXKqnb0/OAw6RzsUTLpMtUa/tu7PZXryHXAmi62eQZtXri2vmZWmq +CsTZvXkbAlUO7A87CFS5NtzPnhE0WREQUP7hGAcpcbchFZwW4/QWUcXo62ss1nkJjhO R0/tZ89d+q+uK4Kv+320VkZkVBfH8pl2W9ZGATvWUBhnuS1lALFVbPGix/7gBv12ydON h7jCnsAc0Q/4EuRhUvePbi9jvaKTWsruXvpkYsiwlOQbzF9Tsb2fEGCj2hEquE74q+D8 gwr0Jp8A6PlWjyQmnCFM+nk41m5nl0piGXNdETCuT26Wy4yAwnXS/miY+hLjEGPzoEkp FZzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=F/jomJ6uLuwf7Rw57RY5/Ap0B+MxWKyeViCBM/4WQzw=; b=yMNLA2KLFkSW2N1f0awXfqPNx28U7Dcx7fnvbXw/1+G8MVknr9KdNlTwFR09QooiXj VJt8GUaMgD77YoPY2iAJyQTRdvJQPTYhuNupEVBdo++ZcMmH4B5zh764zVhuzO/r5xsT C8Z1VVbiZUcvHjfQtlD0w1aL46JerAy/Iti7mZ+rklShy30V3JLcGsZFFLc+FhqGYGC9 yumGqBOOeWhaK57vvo/zDpizjthiRT2tk+ahTh0448aMNGVXIJlAOT3u4HDognbXVeKU mK1x8mR3T8wGhrbAMnBFooTF64XFUXRANmM05AEYCcETeW4dOtyYhZXEX8qdnRbV0VKM ix+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@eclypsium.com header.s=google header.b=Nj1mCKyv; 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=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=eclypsium.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p8si3046553ejf.352.2020.07.30.07.24.28; Thu, 30 Jul 2020 07:24:51 -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=@eclypsium.com header.s=google header.b=Nj1mCKyv; 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=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=eclypsium.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729278AbgG3OVC (ORCPT + 99 others); Thu, 30 Jul 2020 10:21:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53962 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728286AbgG3OVB (ORCPT ); Thu, 30 Jul 2020 10:21:01 -0400 Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5E92C061574 for ; Thu, 30 Jul 2020 07:21:01 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id g26so25749797qka.3 for ; Thu, 30 Jul 2020 07:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclypsium.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=F/jomJ6uLuwf7Rw57RY5/Ap0B+MxWKyeViCBM/4WQzw=; b=Nj1mCKyvWXQ5WMAXKRNDk1pZNoJQX9fEIaJ63VFKTqrfKPJhxiM/Nml+21topTFOy4 G0TNK2Lz76W+LEenbSDrvqkaNJJxtL6L8J4wb4XkkwRmnFrEAh7u6babGn2OmNid7r7e djWhNr8OkPrZ071irRX2XiZCW0QB2JU4bSb6VyuTkfSY7Tb3vng6EQ1Nc5T5jgnYQ41n WlULoSZF6vgp8GYCcXSHCdXlUU1CXvs3gYtVhc/82lVnMlWSGs3IqR/TIZO5aRHc32pQ w0j7uEZIT1BIxkpYu0JelNwyCBxw5xSJ77BWWKPhlwSBzA/INGmz839oOgc+MSMXFU5e rn6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=F/jomJ6uLuwf7Rw57RY5/Ap0B+MxWKyeViCBM/4WQzw=; b=aerAriStoOLSPMqpMKmwsoVdwYXR6/5CnNFoPGEZ8csrswdusYCKqHw4Wu3OP+X9w0 zoY22Km1d8KJD/0l6rpc60lnVJZ5NdNI19+zDDByLSUidaQWumxvs0yBFfMTRTyYIGH6 i93gb0Z0A+S5xbDJL8iztRaFS3qpmEf2DWrhCtxDXVxeHrj185DEFDINjqAC8NM8c4Lo zKvNCugFImc+CM2x3aTFZlAD50pRhU1fyhFMASugiHGuwHvO+3fZTY3dmXiTVTCGKZBc hQ/GBKpwa58bkGm2EMDIhQCoJPDr6b/9nHsLmJqcbeATyGxlUJqqX7qTc0n4E3Zkb+vF EzrQ== X-Gm-Message-State: AOAM530BfTSfCO5bDl/uCU7psRqYq5V7trykxIr5JPu14eLkmLMRxLfE PPtPAKrXrd+E0Rt4VnK0bmbp0Y7Uoo1mLXO+h3Of5A== X-Received: by 2002:ae9:eb81:: with SMTP id b123mr38265818qkg.288.1596118860878; Thu, 30 Jul 2020 07:21:00 -0700 (PDT) MIME-Version: 1.0 References: <20200724212853.11601-1-daniel.gutson@eclypsium.com> <20200725055649.GA1047853@kroah.com> <20200726071723.GB441916@kroah.com> <20200730053108.GA3861609@kroah.com> In-Reply-To: From: Daniel Gutson Date: Thu, 30 Jul 2020 11:20:48 -0300 Message-ID: Subject: Re: [PATCH] Module argument to control whether intel-spi-pci attempts to turn the SPI flash chip writeable To: Arnd Bergmann Cc: Greg Kroah-Hartman , Tudor Ambarus , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Mika Westerberg , Boris Brezillon , linux-mtd , "linux-kernel@vger.kernel.org" , Alex Bazhaniuk , Richard Hughes Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 30, 2020 at 11:18 AM Daniel Gutson wrote= : > > On Thu, Jul 30, 2020 at 11:09 AM Arnd Bergmann wrote: > > > > On Thu, Jul 30, 2020 at 2:21 PM Daniel Gutson wr= ote: > > > El jue., 30 jul. 2020 2:31 a. m., Greg Kroah-Hartman escribi=C3=B3: > > >> > > >> Again, module parameters are working on a per-chunk-of-code basis, w= hile > > >> you want to work on a per-device basis, > > > > > > > > > I think there is a misunderstanding. What I want is to control (turn= on or off) is a very specific code snippet that provides the "functionalit= y" of trying to turn the chip writable. The rest of the device driver is fi= ne. > > > I assume that the one that doesn't understand is me. > > > > > > > I looked at the source code again and found that the existing module > > parameter applies to both the platform and pci device front-ends, both > > of which go through > > > > /* Prevent writes if not explicitly enabled */ > > if (!ispi->writeable || !writeable) > > ispi->nor.mtd.flags &=3D ~MTD_WRITEABLE; > > > > I think you missed > https://elixir.bootlin.com/linux/latest/source/drivers/mtd/spi-nor/contro= llers/intel-spi-pci.c#L44 > > /* Try to make the chip read/write */ > pci_read_config_dword(pdev, BCR, &bcr); > if (!(bcr & BCR_WPD)) { > bcr |=3D BCR_WPD; > pci_write_config_dword(pdev, BCR, bcr); > pci_read_config_dword(pdev, BCR, &bcr); > } > > in the probe function, and is executed always and unconditionally. To clarify, this is executed before intel-spi code. > > /* Try to make the chip read/write */ > pci_read_config_dword(pdev, BCR, &bcr); > if (!(bcr & BCR_WPD)) { > bcr |=3D BCR_WPD; > pci_write_config_dword(pdev, BCR, bcr); > pci_read_config_dword(pdev, BCR, &bcr); > } > > > Setting the PCI device writable in hardware makes it possible to > > actually write to it *only* if the module parameter is also set to '1'. > > One might disagree with that design, but I don't think your patch > > would make it any better, it just means one would have to set > > two module parameters instead of one. > > > > Arnd > > > > -- > Daniel Gutson > Argentina Site Director > Enginieering Director > Eclypsium > > Below The Surface: Get the latest threat research and insights on > firmware and supply chain threats from the research team at Eclypsium. > https://eclypsium.com/research/#threatreport --=20 Daniel Gutson Argentina Site Director Enginieering Director Eclypsium Below The Surface: Get the latest threat research and insights on firmware and supply chain threats from the research team at Eclypsium. https://eclypsium.com/research/#threatreport