Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp2411505pxb; Sun, 30 Jan 2022 15:40:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJyBUvL1pP+a357URHNNrvPAbW7/CtRrPxz8dwa/V8JAb9MQqDTDaDGV2S5OQwgPYMvVm2Ft X-Received: by 2002:a17:907:97c1:: with SMTP id js1mr4072252ejc.234.1643586018833; Sun, 30 Jan 2022 15:40:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643586018; cv=none; d=google.com; s=arc-20160816; b=T7E9TXYVqnpIj5aQJxHj/GLdcylxjuPSMrKwiM7m6hVcQYju9pnHm0xtnOKmFr98Tc a21M+T6bNeVPzP8H6E0klwtvlugoLlyTeskIvagfzQ4TYSn3wBuDSdDqZ+2RJbmS9EKn mkJzmqDQpywAWRxEtYOPfCiENiGps75AwipyVTnWxkM12y2piR3+5LpzYVVFIrlLz1KN EsO9BdYHZVDv1QNkaHxW4e9POeEWYaKvth5V8vci731xsXcVYZbWt8HkA/NJ06YNQueQ 8NEZ5UsgzwPCq37xOVh2keD31855agtZkfkCjtEwZ6u8zwtSBhVVwlNXHOx4oc1oqi8/ XsWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:in-reply-to :date:references:subject:cc:to:from:dkim-signature; bh=3yD9uR7Kzo55SniJCmwHbxaQvpB7m6dWO4Zg7FzD1sQ=; b=H0GaZCErvzLT1opR3HtUK5M3ei+imUoQl0yG4hQ0yXj4t6Zy3155KdIsoP+gThDAfF X1MJcmxaga/OALaW2YXEAq4PEdLYk6gyjfBL05156IsDFAR9y6eZ/S4odrsT71QsOGgd QIPZg6Sa39vLCM4l4/GqoxpaySfj5P1BxxBYlFEHyhK2ivX4SHGvsWst4tUhUk1FBJ8o ryDuNlng2PGDOf9XqG9UlFg/7EhW5UMDAaBQd7n37Sf3vDm3ieXHi7AJg8UrtIO/rmSr aP2eOLTDmSVkxz9JBIq1Ja0+wGyVeOMp9we8HTVCcGIvj2+J4bz7FA8dFAaTgKfFOPY5 mY+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=etzYMrTu; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m9si3941429edd.66.2022.01.30.15.40.01; Sun, 30 Jan 2022 15:40:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=etzYMrTu; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-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 S233666AbiA1Khy (ORCPT + 72 others); Fri, 28 Jan 2022 05:37:54 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:47504 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229462AbiA1Khx (ORCPT ); Fri, 28 Jan 2022 05:37:53 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7C4DDB824E4; Fri, 28 Jan 2022 10:37:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21457C340E0; Fri, 28 Jan 2022 10:37:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643366271; bh=ysNEYwSdpCi6tFVlLx1/q5nHXNJqjoxSYhq3w+gi2so=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=etzYMrTucld4zPDlWJofz0p4FikaxGA2VAIKXeGLTq9Ir6bz488LmszQB7jUb3vWc V43tgZ/j/QLiRBY9JkJi7JDrEnmAPzgeUIsABFzU/EnxG+JmwuGsoDmZkJQH6nSkkB oGRWWk/t10Yw7cv5Y9lwUBCrEJJ1OlLAAvvMdzTf1PI29biiRhieulgM2cpvVpHqoh B/wx7248+5fjXUo1QKvqNTZ1U5BsnUORRu21MTuIG4LmMA0nBFY4kZBvmuxBAd+rtK 8merRipkzLoMLIgXvNcAmxgo22yHhfm7cXSjag2H63qFLvm0mpoxgFwApPBRVU8Hyy zU5UWdhqK+6gQ== From: Kalle Valo To: Manikanta Pubbisetty Cc: , , , Subject: Re: [PATCH v2 05/19] ath11k: Remove core PCI references from PCI common code References: <1642337235-8618-1-git-send-email-quic_mpubbise@quicinc.com> <1642337235-8618-6-git-send-email-quic_mpubbise@quicinc.com> <87a6fggo0h.fsf@kernel.org> Date: Fri, 28 Jan 2022 12:37:48 +0200 In-Reply-To: <87a6fggo0h.fsf@kernel.org> (Kalle Valo's message of "Fri, 28 Jan 2022 12:20:30 +0200") Message-ID: <871r0sgn7n.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Kalle Valo writes: > Manikanta Pubbisetty writes: > >> Remove core PCI and ath11k PCI references(struct ath11k_pci) >> from PCI common code. Since, PCI common code will be used >> by hybrid bus devices, this code should be independent >> from ATH11K PCI references and Linux core PCI references >> like struct pci_dev. >> >> Since this change introduces function callbacks for bus wakeup >> and bus release operations, wakeup_mhi HW param is no longer >> needed and hence it is removed completely. Alternatively, bus >> wakeup/release ops for QCA9074 are initialized to NULL as >> QCA9704 does not need bus wakeup/release for register accesses. >> >> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00573-QCAMSLSWPLZ-1 >> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 >> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 >> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1 >> >> Signed-off-by: Manikanta Pubbisetty > > [...] > >> @@ -651,6 +653,13 @@ struct ath11k_bus_params { >> bool fixed_bdf_addr; >> bool fixed_mem_region; >> bool static_window_map; >> + struct { >> + void (*wakeup)(struct ath11k_base *ab); >> + void (*release)(struct ath11k_base *ab); >> + int (*get_msi_irq)(struct ath11k_base *ab, unsigned int vector); >> + void (*window_write32)(struct ath11k_base *ab, u32 offset, u32 value); >> + u32 (*window_read32)(struct ath11k_base *ab, u32 offset); >> + } ops; >> }; > > Please don't use bus_params for this, I'm starting to suspect that we > actually need to remove struct ath11k_bus_params altogether. It would be > cleaner to have separate 'struct ath11k_pci_ops' or something like that. And after looking at this more it seems .get_msi_irq is the only function which actually has two different implementations. The other four are either run or not run, there's no difference in the implementation. So would it be cleaner to have a some sort check within the function for these other four, instead using function pointers? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches