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.1 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 C8D2DC07E94 for ; Fri, 4 Jun 2021 11:30:03 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 6A90C613FF for ; Fri, 4 Jun 2021 11:30:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A90C613FF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com 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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=LrlKAVV19d5TgljyxBJZZw72BmAbWXVd01vdNuJfh+Y=; b=lb8+4Dy8S/0TZJ zWH6oq4bGdfUzg+DJs2VZwSrbhoDLlt59mQDPiLZuWC3e3v10UXvBBqBwBBkI4MPWIcWuVKXCkINV TYcktagxSJipPwOSinOoEcsndWn8tQz5EblKfJr6soIYTE1rB8M+DGFL2NS+JxmAlinfvXWiqPedL MNYBDpncN0Bq0OfAbqeYbFKszTRQCP4AKtdB4/KL9I+sb85czVo/anZsIpcyq31H7bUVeWw9ZZGUs mY8a3L5UkEJnYrGOwcw5hQGs2vw5txNz8pV8rnT9zAW5JyBNUsB0g/TpdEyypyXnYgyx0E2rqkjQh uinmaTIy27kcuBaRuDVQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lp80L-00DIui-Pu; Fri, 04 Jun 2021 11:28:46 +0000 Received: from mga12.intel.com ([192.55.52.136]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lp7zr-00DIld-Pv for linux-mtd@lists.infradead.org; Fri, 04 Jun 2021 11:28:17 +0000 IronPort-SDR: 6WRrss39+SqTviXSbRjmU0X3wt857ts79sZ49JSv/iijbzbIFsXAIFOfQVAmpZX+2eX4xL+OgQ wlQxS6FhZljQ== X-IronPort-AV: E=McAfee;i="6200,9189,10004"; a="183955201" X-IronPort-AV: E=Sophos;i="5.83,248,1616482800"; d="scan'208";a="183955201" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2021 04:28:13 -0700 IronPort-SDR: GsoL7S40iTOxvAVj62EE10SEu7FOG7583ynSch6fVy9+ICOAyKD/ZiV6/D+AqPWF1WSO2c8zCE cPY2osG/PjYg== X-IronPort-AV: E=Sophos;i="5.83,248,1616482800"; d="scan'208";a="446661891" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.163]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2021 04:28:10 -0700 Received: by lahna (sSMTP sendmail emulation); Fri, 04 Jun 2021 14:28:08 +0300 Date: Fri, 4 Jun 2021 14:28:08 +0300 From: Mika Westerberg To: Pratyush Yadav Cc: Michael Walle , Tudor Ambarus , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Mark Brown , linux-mtd@lists.infradead.org, linux-spi@vger.kernel.org Subject: Re: [PATCH] mtd: spi-nor: intel-spi: Add support for second flash chip Message-ID: References: <20210525160318.35802-1-mika.westerberg@linux.intel.com> <20210525191414.dc45h27rzqen4dce@ti.com> <20210526091250.GY291593@lahna.fi.intel.com> <20210526092417.GA291593@lahna.fi.intel.com> <20210526102810.GB291593@lahna.fi.intel.com> <20210603180843.hjzynysgby3d3e5r@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210603180843.hjzynysgby3d3e5r@ti.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210604_042815_897578_AC301E26 X-CRM114-Status: GOOD ( 40.31 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Thu, Jun 03, 2021 at 11:38:45PM +0530, Pratyush Yadav wrote: > +Mark, linux-spi list, > > On 03/06/21 02:07PM, Mika Westerberg wrote: > > Hi Tudor, > > > > On Mon, May 31, 2021 at 02:29:59PM +0300, Mika Westerberg wrote: > > > Hi guys, > > > > > > On Wed, May 26, 2021 at 01:28:16PM +0300, Mika Westerberg wrote: > > > > Hi, > > > > > > > > On Wed, May 26, 2021 at 11:31:58AM +0200, Michael Walle wrote: > > > > > > Oh, I see now this commit: > > > > > > > > > > > > a314f6367787 ("mtd: spi-nor: Convert cadence-quadspi to use spi-mem > > > > > > framework") > > > > > > > > > > > > So "SPI MEM" means generic SPI subsystem for memory mapped devices. > > > > > > Unfortunately Intel controller at least is not capable of running > > > > > > generic SPI transactions. It only supports accessing SPI-NOR flashes and > > > > > > for those there is small set of commands that supports. I don't think it > > > > > > is even possible to convert the driver to generic SPI subsystem. > > > > > > > > > > AFAIK it stands for SPI memory device (memory mapped is not a requirement). > > > > > Eg. spi-nxp-fspi doesn't support generic SPI devices either, but just SPI > > > > > flashes. So I'd guess SPI MEM is exactly what you are looking for. > > > > > > > > OK, I see that there is ->mem_ops that can be used to implement > > > > different higher level commands. What I'm not seeing is that how the > > > > child SPI flash is created using this scheme? DeviceTree and ACPI are > > > > supported fine but what about scanning? I mean the intel_spi driver has > > > > this: > > > > > > > > spi_nor_scan(&ispi->nor, NULL, &hwcaps); > > > > > > > > But if the driver is to be moved under drivers/spi/* you can't really > > > > call these functions anymore or can you? Or the point is to keep the > > > > driver under controllers/ and just call spi_nor_scan(), and in addition > > > > implement the new mem_ops? > > > > > > > > Thanks in advance and sorry about many questions but there does not seem > > > > to be a conversion guide nor any (non-DT/ACPI) examples that I can take > > > > a look. :-) > > > > > > Can you provide some guidance here? So in order to use the generic SPI > > > subsystem with "SPI MEM" parts of it, I would need to be able to create > > > the child SPI-NOR flash device without using ACPI or DT (as these > > > systems do not have any ACPI/DT description), or use spi_nor_scan() but > > > none of the driver under drivers/spi are calling it. > > > > As the main SPI-NOR maintainer, what's your take on this? > > I think this is more of a SPI or SPI MEM question, and less of a SPI NOR > question. SPI MEM would call spi_nor_probe() which in turn calls > spi_nor_scan(). > > So the question that needs to be answered is how to probe SPI MEM based > drivers without ACPI/DT. Yes, exactly. With ACPI/DT the SPI core handles this after the SPI master device is registered and that would result spi_nor_probe() to be called for the children. However, with this one there is no ACPI node for the controller (it is PCI enumerated) so there would need to be some way to create that child device. In the old days that would be "platform data" but that's pretty much frowned upon these days ;-) ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/