All of lore.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:28 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.