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=-3.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,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 E9958C3A5A2 for ; Tue, 3 Sep 2019 16:52:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BB49422CF8 for ; Tue, 3 Sep 2019 16:52:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="YuGW0e5H" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729056AbfICQwK (ORCPT ); Tue, 3 Sep 2019 12:52:10 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:45523 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729557AbfICQwK (ORCPT ); Tue, 3 Sep 2019 12:52:10 -0400 Received: by mail-pg1-f193.google.com with SMTP id 4so5911314pgm.12 for ; Tue, 03 Sep 2019 09:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=message-id:mime-version:content-transfer-encoding:in-reply-to :references:cc:subject:to:from:user-agent:date; bh=h8ngCQI7EcgQWs7APOFWbvcG4aSSwNLHZV1kuBNnkzI=; b=YuGW0e5HrYZ6b94ppeM5MXTtua4CcL16l3ub8KkaJuMmVJgtVIA/KuvNZdHKhrB1aP b3xLah9iPDQQvqGgTvGVB8dqgoQ9yfLVsPeFjXoqLZvmFulF6BltLka8xKVVoApPI6WU 4RodOC944LFAyTo5JOofVH8PPXRQOMmmtgcaA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version :content-transfer-encoding:in-reply-to:references:cc:subject:to:from :user-agent:date; bh=h8ngCQI7EcgQWs7APOFWbvcG4aSSwNLHZV1kuBNnkzI=; b=Fn4qOJeLfwigsvTrWMzNmzi9yuVp9L5pC1kiwvRmzXdbxGA4N/TcBTIsg637PC0S8M gL4yzlzyQHteQ21/h64yk9oVjJsotZ61EKiTJtA146mv9U7qZmQVEkoj2IGsMpdX/PGj fiUVI9WChxcUrV3Oh2B+zDZaTsVj8zy2X2c1TSeec19oEm/Z/xPoB1ECER6oc+137pBn ZsGkXuhmJeQ0zNM+Gt1BWPp3KtkdDZGymB5cmVCH7GedqpKmprWAymetca9qt6juvNj5 UMwOawif21QvXjr7eHp0C0cUNNB0FJb6vZHLFOC+IZjrR2HJS2u3B2S7e3M6mFtdmdNI RM2A== X-Gm-Message-State: APjAAAVcMoGTUkoC2JB5f19ZNEOuV1q+8qHRmunBwUVwARdTLSGhiNHa tWQ6gaACs+RSjEYqFab2zY122w== X-Google-Smtp-Source: APXvYqwtlv4autqI3NKfe7BRjyKjRftw9BYTCaZgTZpqVeHhpReslgkrKgkusl97Sb4RiFhhgxGohA== X-Received: by 2002:a63:ee08:: with SMTP id e8mr31805414pgi.70.1567529529306; Tue, 03 Sep 2019 09:52:09 -0700 (PDT) Received: from chromium.org ([2620:15c:202:1:fa53:7765:582b:82b9]) by smtp.gmail.com with ESMTPSA id v12sm16966488pff.40.2019.09.03.09.52.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Sep 2019 09:52:08 -0700 (PDT) Message-ID: <5d6e9a38.1c69fb81.ad03c.cb4c@mx.google.com> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20190829224110.91103-1-swboyd@chromium.org> <20190829224110.91103-5-swboyd@chromium.org> Cc: Andrey Pronin , linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, Duncan Laurie , Jason Gunthorpe , Arnd Bergmann , Greg Kroah-Hartman , Guenter Roeck , Alexander Steffen , Heiko Stuebner Subject: Re: [PATCH v6 4/4] tpm: tpm_tis_spi: Support cr50 devices To: Jarkko Sakkinen , Peter Huewe From: Stephen Boyd User-Agent: alot/0.8.1 Date: Tue, 03 Sep 2019 09:52:07 -0700 Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org Quoting Jarkko Sakkinen (2019-09-03 09:39:51) > On Thu, 2019-08-29 at 15:41 -0700, Stephen Boyd wrote: > > From: Andrey Pronin > >=20 > > Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50 > > firmware. The firmware running on the currently supported H1 Secure > > Microcontroller requires a special driver to handle its specifics: > >=20 > > - need to ensure a certain delay between SPI transactions, or else > > the chip may miss some part of the next transaction > > - if there is no SPI activity for some time, it may go to sleep, > > and needs to be waken up before sending further commands > > - access to vendor-specific registers > >=20 > > Cr50 firmware has a requirement to wait for the TPM to wakeup before > > sending commands over the SPI bus. Otherwise, the firmware could be in > > deep sleep and not respond. The method to wait for the device to wakeup > > is slightly different than the usual flow control mechanism described in > > the TCG SPI spec. Add a completion to tpm_tis_spi_transfer() before we > > start a SPI transfer so we can keep track of the last time the TPM > > driver accessed the SPI bus to support the flow control mechanism. > >=20 > > Split the cr50 logic off into a different file to keep it out of the > > normal code flow of the existing SPI driver while making it all part of > > the same module when the code is optionally compiled into the same > > module. Export a new function, tpm_tis_spi_init(), and the associated > > read/write/transfer APIs so that we can do this. Make the cr50 code wrap > > the tpm_tis_spi_phy struct with its own struct to override the behavior > > of tpm_tis_spi_transfer() by supplying a custom flow control hook. This > > shares the most code between the core driver and the cr50 support > > without combining everything into the core driver or exporting module > > symbols. > >=20 > > Signed-off-by: Andrey Pronin > > Cc: Andrey Pronin > > Cc: Duncan Laurie > > Cc: Jason Gunthorpe > > Cc: Arnd Bergmann > > Cc: Greg Kroah-Hartman > > Cc: Guenter Roeck > > Cc: Alexander Steffen > > Cc: Heiko Stuebner >=20 > Had to time to look at this patch set after all before LPC. I just > realized that the kconfig has taken away. Not sure why is that > because there's been only request to not have a new LKM. There > still should be ability opt-out to have Cr50 support in vmlinux. >=20 That's fair. I'll put the Kconfig option back. There's still the small issue of what to do about the module name. Should I rename the tpm_tis_spi.c file to something else so that the module can keep the same name? Or was the tpm_tis_spi_mod.ko trick from v5 good enough?