public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@kernel.org>
To: Karthikeyan Periyasamy <quic_periyasa@quicinc.com>
Cc: <ath12k@lists.infradead.org>,  <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 4/4] wifi: ath12k: Refactor MAC un/register helper function
Date: Mon, 15 Jan 2024 17:27:55 +0200	[thread overview]
Message-ID: <87v87u7h1g.fsf@kernel.org> (raw)
In-Reply-To: <269ea05b-d665-eceb-d7a1-d0ac20d341a7@quicinc.com> (Karthikeyan Periyasamy's message of "Tue, 9 Jan 2024 19:11:38 +0530")

Karthikeyan Periyasamy <quic_periyasa@quicinc.com> writes:

>> Is there a reason why you moved these two functions from mac.c to
>> core.c? This is mac level code anyway, right?
>
> This is not fully mac level code, some parts of SoC/chip level code
> bindup in the mac level. So i segregated the SoC level code like ab
> related param initialization handling from the mac level procedure.
>
> Now, mac/radio should take care only radio level handling procedure.
>
> In future for MLO, SoC level can be extend easily.

But is there a concrete reason to have the functions in core.c? In your
following patches I couldn't see why to move these functions to core.c,
everything seems to be suitable for mac.c.

I experimented this in the pending branch and moved the functions to
mac.c (tag ath-pending-202401151424):

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=bee89ac2b5755754849deaf7054828e982cc6658

I also fixed your other patchsets to match that and to me it makes more
sense to have everything in mac.c. I prefer to make core.c as simple as possible.

As you can see I also made changes to the patch titles to make them more
understandable:

wifi: ath12k: refactor ath12k_mac_register() and ath12k_mac_unregister()

Thoughts?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  reply	other threads:[~2024-01-15 15:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-06  3:49 [PATCH 0/4] wifi: ath12k: Refactor MAC alloc/destroy/un/register helper functions Karthikeyan Periyasamy
2023-12-06  3:49 ` [PATCH 1/4] wifi: ath12k: Refactor the DP pdev pre alloc call sequence Karthikeyan Periyasamy
2023-12-08  0:22   ` Jeff Johnson
2024-01-16 12:20   ` Kalle Valo
2023-12-06  3:49 ` [PATCH 2/4] wifi: ath12k: Refactor the MAC allocation and destroy Karthikeyan Periyasamy
2023-12-08  0:22   ` Jeff Johnson
2023-12-06  3:49 ` [PATCH 3/4] wifi: ath12k: Refactor MAC setup channel helper function Karthikeyan Periyasamy
2023-12-08  0:22   ` Jeff Johnson
2023-12-06  3:49 ` [PATCH 4/4] wifi: ath12k: Refactor MAC un/register " Karthikeyan Periyasamy
2023-12-08  0:23   ` Jeff Johnson
2024-01-09 13:25   ` Kalle Valo
2024-01-09 13:41     ` Karthikeyan Periyasamy
2024-01-15 15:27       ` Kalle Valo [this message]
2024-01-16  4:49         ` Karthikeyan Periyasamy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v87u7h1g.fsf@kernel.org \
    --to=kvalo@kernel.org \
    --cc=ath12k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=quic_periyasa@quicinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox