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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 C9D67C2D0E4 for ; Tue, 24 Nov 2020 17:52:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 673F420757 for ; Tue, 24 Nov 2020 17:52:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="OOAeaexT" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404166AbgKXRvv (ORCPT ); Tue, 24 Nov 2020 12:51:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404152AbgKXRvv (ORCPT ); Tue, 24 Nov 2020 12:51:51 -0500 Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF363C0617A6 for ; Tue, 24 Nov 2020 09:51:50 -0800 (PST) Received: by mail-ot1-x343.google.com with SMTP id z24so6155358oto.6 for ; Tue, 24 Nov 2020 09:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=dgZcAum397p2JLnSMu9Tfx6bFmJxJljXgwdxIBft2qU=; b=OOAeaexTNdWrtNkAmYHlsVBFA5sTlRmOiCsFvy4pL27tRynQOBBbcqmUn3veDD2lRu lwC1uI8VTYahxiSjJiZjhClgMUfsBfBbBkWftfy7pihRRTdR5mN7hCA2SgMzS8pi7a/7 OjPm6zaaP2vN9Geb6kS6S3Zi2N+ksSftuK+iKFOWNvgpnE9Ie5mhgB0Z8xyWNqfNKyit 436vILyqH/QaPh7syOXlp48jgjaa+WuY3DzwxmE9dXEbtemLjqqaP5OlUfq4j5GRtDpS IK119lCxbp3A5toiNMhLqDofinxMJTRFtIbrNRL5d4oipX5KnUaWN3vXZ/rRK+D7wGLX 8kfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=dgZcAum397p2JLnSMu9Tfx6bFmJxJljXgwdxIBft2qU=; b=o+B938Sz9Q5O+ayY+/xd5+HIU6cbkzf0PNONSrwz/3m7YFMXXIeyxd7A/lgrNNXM9l r8faFzqT+MUguoUF+c6ahWpAkxRrTPdmatvwxiSaNXBgIEmkNB96qw3kdbu2EFmUMJFf iA3rx7XWQWgXsktZkcJ7k3pmLQlnZf8OiniNBJaKvWZEcHoTm0er45nxHX+fWthsdbAc JmkTH8XnaTRxk01wxfkzZIfhjzdhoF/q7deidCHf+ty6pFTnVBYNsUjobS9DtDZVTu5i ocL2DtVGD/zMOpIi3lDu6o8K5TtdZl+1d1V62RzNcxirVtAU+7YQazLkEywl5cO2eSkQ S/iQ== X-Gm-Message-State: AOAM531W6Qh1UffLIG7gfRJ9EmC8iHdcf021xixgJlw9eLIr3SfxoCf0 6DB5abOZniq6VPTOorj7Bezrwg== X-Google-Smtp-Source: ABdhPJx0Bi9BI557Z8UPwegAPJqDFuQ2QJg9nE12QgAZLSFJWx9gcK7pnLUE2oNRHmHHuA+dXznesA== X-Received: by 2002:a9d:1f5:: with SMTP id e108mr4289207ote.309.1606240310256; Tue, 24 Nov 2020 09:51:50 -0800 (PST) Received: from builder.lan (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id u10sm10051960oig.54.2020.11.24.09.51.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Nov 2020 09:51:48 -0800 (PST) Date: Tue, 24 Nov 2020 11:51:46 -0600 From: Bjorn Andersson To: Amit Pundir , Rob Herring Cc: Kalle Valo , David S Miller , Jakub Kicinski , Jeffrey Hugo , John Stultz , Sumit Semwal , Konrad Dybcio , ath10k , dt , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, lkml Subject: Re: [PATCH] ath10k: Introduce a devicetree quirk to skip host cap QMI requests Message-ID: <20201124175146.GG185852@builder.lan> References: <1601058581-19461-1-git-send-email-amit.pundir@linaro.org> <20200929190817.GA968845@bogus> <20201029134017.GA807@yoga> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Tue 03 Nov 01:48 CST 2020, Amit Pundir wrote: > Hi Rob, Bjorn, Kalle, > > On Thu, 29 Oct 2020 at 19:10, Bjorn Andersson > wrote: > > > > On Tue 29 Sep 14:08 CDT 2020, Rob Herring wrote: > > > > > On Fri, Sep 25, 2020 at 11:59:41PM +0530, Amit Pundir wrote: > > > > There are firmware versions which do not support host capability > > > > QMI request. We suspect either the host cap is not implemented or > > > > there may be firmware specific issues, but apparently there seem > > > > to be a generation of firmware that has this particular behavior. > > > > > > > > For example, firmware build on Xiaomi Poco F1 (sdm845) phone: > > > > "QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1" > > > > > > > > If we do not skip the host cap QMI request on Poco F1, then we > > > > get a QMI_ERR_MALFORMED_MSG_V01 error message in the > > > > ath10k_qmi_host_cap_send_sync(). But this error message is not > > > > fatal to the firmware nor to the ath10k driver and we can still > > > > bring up the WiFi services successfully if we just ignore it. > > > > > > > > Hence introducing this DeviceTree quirk to skip host capability > > > > QMI request for the firmware versions which do not support this > > > > feature. > > > > > > So if you change the WiFi firmware, you may force a DT change too. Those > > > are pretty independent things otherwise. > > > > > > > Yes and that's not good. But I looked at somehow derive this from > > firmware version numbers etc and it's not working out, so I'm out of > > ideas for alternatives. > > > > > Why can't you just always ignore this error? If you can't deal with this > > > entirely in the driver, then it should be part of the WiFi firmware so > > > it's always in sync. > > > > > > > Unfortunately the firmware versions I've hit this problem on has gone > > belly up when receiving this request, that's why I asked Amit to add a > > flag to skip it. > > So what is next for this DT quirk? > Rob, we still have this problem and we've not come up with any way to determine in runtime that we need to skip this part of the initialization. Regards, Bjorn > I'm OK to go back to my previous of_machine_is_compatible() > device specific hack, for now, > https://patchwork.kernel.org/project/linux-wireless/patch/1600328501-8832-1-git-send-email-amit.pundir@linaro.org/ > till we have a reasonable fix in place or receive a vendor firmware > drop which fixes this problem (which I believe is highly unlikely > though, for this 2+ years old device). > > Regards, > Amit Pundir > > > > > That said, in the devices I've hit this I've managed to get newer > > firmware working, which doesn't have either problem. > > > > Regards, > > Bjorn From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ot1-x343.google.com ([2607:f8b0:4864:20::343]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1khcTo-0006Wq-Dp for ath10k@lists.infradead.org; Tue, 24 Nov 2020 17:51:53 +0000 Received: by mail-ot1-x343.google.com with SMTP id n12so16648927otk.0 for ; Tue, 24 Nov 2020 09:51:51 -0800 (PST) Date: Tue, 24 Nov 2020 11:51:46 -0600 From: Bjorn Andersson Subject: Re: [PATCH] ath10k: Introduce a devicetree quirk to skip host cap QMI requests Message-ID: <20201124175146.GG185852@builder.lan> References: <1601058581-19461-1-git-send-email-amit.pundir@linaro.org> <20200929190817.GA968845@bogus> <20201029134017.GA807@yoga> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Amit Pundir , Rob Herring Cc: dt , lkml , Jeffrey Hugo , netdev@vger.kernel.org, linux-wireless@vger.kernel.org, Konrad Dybcio , ath10k , David S Miller , John Stultz , Jakub Kicinski , Sumit Semwal , Kalle Valo On Tue 03 Nov 01:48 CST 2020, Amit Pundir wrote: > Hi Rob, Bjorn, Kalle, > > On Thu, 29 Oct 2020 at 19:10, Bjorn Andersson > wrote: > > > > On Tue 29 Sep 14:08 CDT 2020, Rob Herring wrote: > > > > > On Fri, Sep 25, 2020 at 11:59:41PM +0530, Amit Pundir wrote: > > > > There are firmware versions which do not support host capability > > > > QMI request. We suspect either the host cap is not implemented or > > > > there may be firmware specific issues, but apparently there seem > > > > to be a generation of firmware that has this particular behavior. > > > > > > > > For example, firmware build on Xiaomi Poco F1 (sdm845) phone: > > > > "QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1" > > > > > > > > If we do not skip the host cap QMI request on Poco F1, then we > > > > get a QMI_ERR_MALFORMED_MSG_V01 error message in the > > > > ath10k_qmi_host_cap_send_sync(). But this error message is not > > > > fatal to the firmware nor to the ath10k driver and we can still > > > > bring up the WiFi services successfully if we just ignore it. > > > > > > > > Hence introducing this DeviceTree quirk to skip host capability > > > > QMI request for the firmware versions which do not support this > > > > feature. > > > > > > So if you change the WiFi firmware, you may force a DT change too. Those > > > are pretty independent things otherwise. > > > > > > > Yes and that's not good. But I looked at somehow derive this from > > firmware version numbers etc and it's not working out, so I'm out of > > ideas for alternatives. > > > > > Why can't you just always ignore this error? If you can't deal with this > > > entirely in the driver, then it should be part of the WiFi firmware so > > > it's always in sync. > > > > > > > Unfortunately the firmware versions I've hit this problem on has gone > > belly up when receiving this request, that's why I asked Amit to add a > > flag to skip it. > > So what is next for this DT quirk? > Rob, we still have this problem and we've not come up with any way to determine in runtime that we need to skip this part of the initialization. Regards, Bjorn > I'm OK to go back to my previous of_machine_is_compatible() > device specific hack, for now, > https://patchwork.kernel.org/project/linux-wireless/patch/1600328501-8832-1-git-send-email-amit.pundir@linaro.org/ > till we have a reasonable fix in place or receive a vendor firmware > drop which fixes this problem (which I believe is highly unlikely > though, for this 2+ years old device). > > Regards, > Amit Pundir > > > > > That said, in the devices I've hit this I've managed to get newer > > firmware working, which doesn't have either problem. > > > > Regards, > > Bjorn _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k