Received: by 2002:a05:6358:700f:b0:131:369:b2a3 with SMTP id 15csp843743rwo; Wed, 2 Aug 2023 05:14:19 -0700 (PDT) X-Google-Smtp-Source: APBJJlGbO5RFpwAtEl9aw/AtQI7f/yThw6hNMVLOZGg9uGJrRuvq4DnqbAgsvouVeXKeFIMgP98z X-Received: by 2002:a17:90b:1001:b0:268:1f0a:9f12 with SMTP id gm1-20020a17090b100100b002681f0a9f12mr14420382pjb.29.1690978459609; Wed, 02 Aug 2023 05:14:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690978459; cv=none; d=google.com; s=arc-20160816; b=kqPvmXgmn4yvmzp8iKMK02CTOoIRJm6QqYmh7Anosd3kXqJzH1Hk7vLBdy1tOBJ2MP ul8b61NdCHhhJ37pkSBlqoQETayhcfXPGO+eU2rIgPs6QM8/Yng5TSe9V4R/f4hPxvV/ TBb1DycZfb7hrtSEgpp/1J03CaV3SB+Kc4EAzs4BL/D9W2fCcc1jX8GaO7w6/X6N9O+2 nBm1W3+2Kq0OJEboCezqKnCezXo47Dc45bvPlKWdWtraiUi2xUQDKoCH+KTpe60sRUpU FxiIUe+Uo9do5r25pa8V5w/BatFYQGB/LcasT+jwDcMn0C2IUJyRWp588CvHhDIilt4L 3RQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=ZrqB7bR3ZjA5s0ythRM1Jb5ByY3HxWh9nU0k3eVgy38=; fh=6buB1VmuRAlT/ZKhgQdfPK/L2AKzX55hpvgMOqa1hRo=; b=P0VdL2ZGrW8tfcg8RYEMD7+tGVkXTXIONlQjoMfhiZIRkNRRJjCQVZ8AIlXvusNSKo 2nplKoq+1k0A9+J0phKUVeqDf/swgnY2Emr/qF161DxVmxBPmWoXod/xq7GusZXSdNit 7kJ9+9aPWAkLstWEv1J6NYiNQK+BM4+nUIa5ac9cETvoGtDr8D50OvYn/CczqZtULYrf 7hV54QunSSgMvivmoU/gksso88m4a273AKkqb46fX9pdjMQbQ/S7wUZY5xri4as4oruT lbbcbIb96WKt4xyDkBXd8VymKGRFYLa7GCXwXaJJ/nHOftF9wzv8V4dkXBZapG/hvIk4 Eezw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Tek8esPJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m6-20020a633f06000000b00563fc72069asi3334356pga.94.2023.08.02.05.13.58; Wed, 02 Aug 2023 05:14:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Tek8esPJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234173AbjHBLU6 (ORCPT + 99 others); Wed, 2 Aug 2023 07:20:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49790 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232421AbjHBLU5 (ORCPT ); Wed, 2 Aug 2023 07:20:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3EF426A2 for ; Wed, 2 Aug 2023 04:20:42 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5DF5561939 for ; Wed, 2 Aug 2023 11:20:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F0B07C433C7; Wed, 2 Aug 2023 11:20:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690975240; bh=WD+SSKvIiKPnRV7ZbrF3+/bXbHW9DvArsnTM6PE24VM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Tek8esPJJh9XQS8B0tcf6QyBaku+4neVNlvdcUr/r74juDQhTl4aW4iMsWU0e3hDG p8WdPuk67yh/hYUeefVfwit7ExitogrqiEbizRLV//AQah0M4lPH29dSXjxkjn1lL3 O7y307dB7ku3LXBbKrQGbRPaAcJjt0lgfPveVmOTUTbSCFBkaEGwZLesZhtUCsq7/g rJH2n2quyjf66jDdFaCZQ0Z443pExWqhfA8t0r9UNs6G0MbInknzXQxSaC7JqR3LNa mxbz99QcP5eQAD9i2jhdl9cvc6byz5+8wT3rxNlBNSM/s57Begy/Q/3sfchOMgQrWi J6sUZoFLomOtw== Date: Wed, 2 Aug 2023 16:50:28 +0530 From: Manivannan Sadhasivam To: Jeffrey Hugo Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, mhi@lists.linux.dev Subject: Re: [PATCH v2 0/2] Add MHI quirk for QAIC Message-ID: <20230802112028.GG57374@thinkpad> References: <20230519163902.4170-1-quic_jhugo@quicinc.com> <20230608115928.GA5672@thinkpad> <507f4cc2-15c2-8323-878e-4da00505bc45@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <507f4cc2-15c2-8323-878e-4da00505bc45@quicinc.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 26, 2023 at 11:15:56AM -0600, Jeffrey Hugo wrote: > On 6/8/2023 5:59 AM, Manivannan Sadhasivam wrote: > > On Fri, May 19, 2023 at 10:39:00AM -0600, Jeffrey Hugo wrote: > > > With the QAIC driver in -next, I'd like to suggest some MHI changes that > > > specific to AIC100 devices, but perhaps provide a framework for other > > > device oddities. > > > > > > AIC100 devices technically violate the MHI spec in two ways. Sadly, these > > > issues comes from the device hardware, so host SW needs to work around > > > them. > > > > > > Thie first issue, presented in this series, has to do with the > > > SOC_HW_VERSION register. This register is suposed to be initialized by the > > > hardware prior to the MHI being accessable by the host to contain a > > > version string for the SoC of the device. This could be used by the host > > > MHI controller software to identify and handle version to version changes. > > > The AIC100 hardware does not initialize this register, and thus it > > > contains garbage. > > > > > > This would not be much of a problem normally - the QAIC driver would just > > > never use it. However the MHI stack uses this register as part of the init > > > sequence and if the controller reports that the register is inaccessable > > > then the init sequence fails. On some AIC100 cards, the garbage value > > > ends up being 0xFFFFFFFF which is PCIe spec defined to be a special value > > > indicating the access failed. The MHI controller cannot tell if that > > > value is a PCIe link issue, or just garbage. > > > > > > QAIC needs a way to tell MHI not to use this register. Other buses have a > > > quirk mechanism - a way to describe oddities in a particular > > > implementation that have some kind of workaround. Since this seems to be > > > the first need for such a thing in MHI, introduce a quirk framework. > > > > > > The second issue AIC100 has involves the PK Hash registers. A solution for > > > this is expected to be proposed in the near future and is anticipated to > > > make use of the quirk framework proposed here. With PK Hash, there are two > > > oddities to handle. AIC100 does not initialize these registers until the > > > SBL is running, which is later than the spec indicates, and in practice > > > is after MHI reads/caches them. Also, AIC100 does not have enough > > > registers defined to fully report the 5 PK Hash slots, so a custom > > > reporting format is defined by the device. > > > > > > > Looking at the two issues you reported above, it looks to me that they can be > > handled inside the aic100 mhi_controller driver itself. Since the MHI stack > > exports the read_reg callback to controller drivers, if some registers are not > > supported by the device, then the callback can provide some fixed dummy data > > emulating the register until the issue is fixed in the device (if at all). > > > > Quirk framework could be useful if the device misbehaves against the protocol > > itself but for the register issues like this, I think the controller driver can > > handle itself. > > > > What do you think? > > I think for the HW_VERSION register, your suggestion is very good, and > something I plan to adopt. > > For the PK Hash registers, I don't think it quite works. > > HW_VERSION I can hard code to a valid value, or just stub out to 0 since > that appears to be only consumed by the MHI Controller, and we don't use it. > > The PK Hash registers are programmed into the SoC, and can be unique from > SoC to SoC. I don't see how the driver can provide valid, but faked > information for them. Also, the user consumes this data via sysfs. We'd > like to give the data to the user, and we can't fake it. Also the data is > dynamic. > > Lets start with the dynamic data issue. Right now MHI reads these registers > once, and caches the values. I would propose a quirk to change that > behavior for AIC100, but does MHI really need to operate in a "read once" > mode? Would something actually break if MHI read the registers every time > the sysfs node is accessed? Then sysfs would display the latest data, which > would be beneficial to AIC100 and should not be a behavior change for other > devices which have static data (MHI just displays the same data because it > hasn't changed). > > Do you recall the reason behind making the PK Hash registers read once and > cached? > I don't see an issue with reading the PK hash dynamically. I think the intention for caching mostly come from the fact it was a static data. So you can dynamically read it all the time. - Mani > > > > - Mani > > > > > v2: > > > -Fix build error > > > -Fix typo in commit text > > > > > > Jeffrey Hugo (2): > > > bus: mhi: host: Add quirk framework and initial quirk > > > accel/qaic: Add MHI_QUIRK_SOC_HW_VERSION_UNRELIABLE > > > > > > drivers/accel/qaic/mhi_controller.c | 1 + > > > drivers/bus/mhi/host/init.c | 13 +++++++++---- > > > include/linux/mhi.h | 18 ++++++++++++++++++ > > > 3 files changed, 28 insertions(+), 4 deletions(-) > > > > > > -- > > > 2.40.1 > > > > > > > > > > -- மணிவண்ணன் சதாசிவம்