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=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 1194CC2D0E4 for ; Tue, 24 Nov 2020 16:27:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 963E0206F9 for ; Tue, 24 Nov 2020 16:27:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="lg5QSCkm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390414AbgKXQ03 (ORCPT ); Tue, 24 Nov 2020 11:26:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389861AbgKXQ02 (ORCPT ); Tue, 24 Nov 2020 11:26:28 -0500 Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BB72AC0613D6 for ; Tue, 24 Nov 2020 08:26:28 -0800 (PST) Received: by mail-vs1-xe44.google.com with SMTP id u7so11385694vsq.11 for ; Tue, 24 Nov 2020 08:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e44wk8MkE5luS4VPP/tOiY6OXFFUDjOtoE11h9rO1rQ=; b=lg5QSCkmuSEcqU7ETiY5fcU2g7mMK28FXHVHIsk89BdwA6FH/G9weJb/h0Y1c0lroL HCJxIbgUiwFYvi73yMMUpfb6CYUya25UygMN/Tk9CNLjJbEvF86nu7hHFB3FOc5iVTtA lNmrZWaHZrpP1lUvJi4uJ5AR1+uDiypZBOMwE= 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; bh=e44wk8MkE5luS4VPP/tOiY6OXFFUDjOtoE11h9rO1rQ=; b=R2u2z+hrXavCytLp+zCSASOF26TVbNAtBHHoZPfR9IhXvuRc2bA8TyTk/gs98vFCHa Hn7VnluFO5/joBjYhiopKH1jDwUzNEBNZPHWDcHpL5e1VhTGomwqlR8kYBWsTLw45BK1 4ksIcVzSfV+krHOUwAJG8cGW0AmJJqarJxPBLC3kjmnuFCK2bakEvnX5NUk3P9X6mhdu MCcvLWmhjtDqVCzd0NbyaLWDLWvQ0EaWhnM9UOOqkcw7faE6LJ/0BTqrk7VYLtVwpcsA HO2snVWuyjuCH1Dt5VuiVHVDxRhvy8TEfzHDr7QxsIq+w9/Blw1TPwF84REkt7Phx2Hu kdxQ== X-Gm-Message-State: AOAM532lykK1ExlrCiL8tO6lu9dih4QWhR3vM8cBY9+PGcsnt+dhjS+7 R+877y8RIV6OiQuxYNeIlRf0U/4Z+PfL0w== X-Google-Smtp-Source: ABdhPJwE8yBIU30eot5MH3eVkiHR8RVH7mISfgmFrwmz+k4Zvw8t/3Fn61vKNxXvgKap0Mepir4MmA== X-Received: by 2002:a05:6102:5fb:: with SMTP id w27mr4116880vsf.24.1606235187556; Tue, 24 Nov 2020 08:26:27 -0800 (PST) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com. [209.85.217.54]) by smtp.gmail.com with ESMTPSA id x11sm1643207vsp.15.2020.11.24.08.26.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 08:26:26 -0800 (PST) Received: by mail-vs1-f54.google.com with SMTP id u24so11368277vsl.9 for ; Tue, 24 Nov 2020 08:26:26 -0800 (PST) X-Received: by 2002:a67:ef98:: with SMTP id r24mr4313446vsp.37.1606235186181; Tue, 24 Nov 2020 08:26:26 -0800 (PST) MIME-Version: 1.0 References: <20201112200906.991086-1-kuabhs@chromium.org> <20201112200856.v2.1.Ia526132a366886e3b5cf72433d0d58bb7bb1be0f@changeid> <002401d6c242$d78f2140$86ad63c0$@codeaurora.org> In-Reply-To: <002401d6c242$d78f2140$86ad63c0$@codeaurora.org> From: Doug Anderson Date: Tue, 24 Nov 2020 08:26:14 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/1] ath10k: add option for chip-id based BDF selection To: Rakesh Pillai Cc: Abhishek Kumar , Kalle Valo , LKML , ath10k , Brian Norris , linux-wireless , "David S. Miller" , Jakub Kicinski , netdev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, Nov 24, 2020 at 1:19 AM Rakesh Pillai wrote: > > > -----Original Message----- > > From: Doug Anderson > > Sent: Tuesday, November 24, 2020 6:27 AM > > To: Abhishek Kumar > > Cc: Kalle Valo ; Rakesh Pillai > > ; LKML ; ath10k > > ; Brian Norris ; > > linux-wireless ; David S. Miller > > ; Jakub Kicinski ; netdev > > > > Subject: Re: [PATCH v2 1/1] ath10k: add option for chip-id based BDF > > selection > > > > Hi, > > > > On Thu, Nov 12, 2020 at 12:09 PM Abhishek Kumar > > wrote: > > > > > > In some devices difference in chip-id should be enough to pick > > > the right BDF. Add another support for chip-id based BDF selection. > > > With this new option, ath10k supports 2 fallback options. > > > > > > The board name with chip-id as option looks as follows > > > board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=320' > > > > > > Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.2.2-00696-QCAHLSWMTPL-1 > > > Tested-on: QCA6174 HW3.2 WLAN.RM.4.4.1-00157-QCARMSWPZ-1 > > > Signed-off-by: Abhishek Kumar > > > --- > > > > > > (no changes since v1) > > > > I think you need to work on the method you're using to generate your > > patches. There are most definitely changes since v1. You described > > them in your cover letter (which you don't really need for a singleton > > patch) instead of here. > > > > > > > @@ -1438,12 +1439,17 @@ static int > > ath10k_core_create_board_name(struct ath10k *ar, char *name, > > > } > > > > > > if (ar->id.qmi_ids_valid) { > > > - if (with_variant && ar->id.bdf_ext[0] != '\0') > > > + if (with_additional_params && ar->id.bdf_ext[0] != '\0') > > > scnprintf(name, name_len, > > > "bus=%s,qmi-board-id=%x,qmi-chip-id=%x%s", > > > ath10k_bus_str(ar->hif.bus), > > > ar->id.qmi_board_id, ar->id.qmi_chip_id, > > > variant); > > > + else if (with_additional_params) > > > + scnprintf(name, name_len, > > > + "bus=%s,qmi-board-id=%x,qmi-chip-id=%x", > > > + ath10k_bus_str(ar->hif.bus), > > > + ar->id.qmi_board_id, ar->id.qmi_chip_id); > > > > I believe this is exactly opposite of what Rakesh was requesting. > > Specifically, he was trying to eliminate the extra scnprintf() but I > > think he still agreed that it was a good idea to generate 3 different > > strings. I believe the proper diff to apply to v1 is: > > > > https://crrev.com/c/255643 Wow, I seem to have deleted the last digit from my URL. Should have been: https://crrev.com/c/2556437 > > > > -Doug > > Hi Abhishek/Doug, > > I missed on reviewing this change. Also I agree with Doug that this is not the change I was looking for. > > The argument "with_variant" can be renamed to "with_extra_params". There is no need for any new argument to this function. > Case 1: with_extra_params=0, ar->id.bdf_ext[0] = 0 -> The default name will be used (bus=snoc,qmi_board_id=0xab) > Case 2: with_extra_params=1, ar->id.bdf_ext[0] = 0 -> bus=snoc,qmi_board_id=0xab,qmi_chip_id=0xcd > Case 3: with_extra_params=1, ar->id.bdf_ext[0] = "xyz" -> bus=snoc,qmi_board_id=0xab,qmi_chip_id=0xcd,variant=xyz > > ar->id.bdf_ext[0] depends on the DT entry for variant field. I'm confused about your suggestion. Maybe you can help clarify. Are you suggesting: a) Only two calls to ath10k_core_create_board_name() I'm pretty sure this will fail in some cases. Specifically consider the case where the device tree has a "variant" defined but the BRD file only has one entry for (board-id) and one for (board-id + chip-id) but no entry for (board-id + chip-id + variant). If you are only making two calls then I don't think you'll pick the right one. Said another way... If the device tree has a variant: 1. We should prefer a BRD entry that has board-id + chip-id + variant 2. If #1 isn't there, we should prefer a BRD entry that has board-id + chip-id 3. If #1 and #2 aren't there we fall back to a BRD entry that has board-id. ...without 3 calls to ath10k_core_create_board_name() we can't handle all 3 cases. b) Three calls to ath10k_core_create_board_name() but the caller manually whacks "ar->id.bdf_ext[0]" for one of the calls This doesn't look like it's a clean solution, but maybe I'm missing something. -Doug