From: Jeff Johnson <quic_jjohnson@quicinc.com>
To: Kalle Valo <kvalo@kernel.org>
Cc: Karthikeyan Periyasamy <quic_periyasa@quicinc.com>,
<ath12k@lists.infradead.org>, <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH v2 4/4] wifi: ath12k: Refactor data path cmem init
Date: Mon, 22 Apr 2024 09:09:46 -0700 [thread overview]
Message-ID: <f30ad02c-0c52-4a28-b63f-22ae84f23b77@quicinc.com> (raw)
In-Reply-To: <87y195vc0w.fsf@kernel.org>
On 4/22/2024 5:04 AM, Kalle Valo wrote:
> Jeff Johnson <quic_jjohnson@quicinc.com> writes:
>
>>>>> + default:
>>>>> + ath12k_err(ab, "invalid descriptor type %d in cmem init\n", type);
>>>>> + return;
>>>>> + }
>>>>> +
>>>>> + /* Write to PPT in CMEM */
>>>>> + for (i = start; i < end; i++)
>>>>> + ath12k_hif_write32(ab, cmem_base + ATH12K_PPT_ADDR_OFFSET(i),
>>>>> + dp->spt_info[i].paddr >> ATH12K_SPT_4K_ALIGN_OFFSET);
>>>>> +}
>>>>
>>>> Here's a good example why I don't like functions returning void. How do
>>>> we handle the errors in this case?
>>>>
>>>
>>> sure, will handle the error case in the caller.
>>>
>>
>> this is a static function with one caller. the only error is the default case
>> which will never be hit. adding logic to return an error and then check it in
>> the caller seems like overkill. why not just WARN() in the default case since
>> this would be a logic error with newly added code?
>
> I think the software will be more robust then all errors are properly
> handled in a uniform way. For example, will everyone notice the warning
> message? What if the function is extended later and then the person
> doesn't add any error handling "because it didn't have that even
> earlier"? It's also a lot easier to review if error handling follows the
> same style throughout the driver.
A large number of coding errors occur in exception paths. So minimizing the
number of exception paths decreases the opportunity for introducing these kind
of errors. So the real trick is making sure "all errors are properly handled
in a uniform way"
/jeff
prev parent reply other threads:[~2024-04-22 16:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 15:14 [PATCH v2 0/4] wifi: ath12k: Refactor hardware cookie conversion Karthikeyan Periyasamy
2024-04-09 15:14 ` [PATCH v2 1/4] wifi: ath12k: avoid redundant code in Rx cookie conversion init Karthikeyan Periyasamy
2024-04-09 15:14 ` [PATCH v2 2/4] wifi: ath12k: Refactor the hardware " Karthikeyan Periyasamy
2024-04-09 15:14 ` [PATCH v2 3/4] wifi: ath12k: displace the Tx and Rx descriptor in cookie conversion table Karthikeyan Periyasamy
2024-04-09 15:14 ` [PATCH v2 4/4] wifi: ath12k: Refactor data path cmem init Karthikeyan Periyasamy
2024-04-11 9:45 ` Kalle Valo
2024-04-11 10:07 ` Karthikeyan Periyasamy
2024-04-11 15:20 ` Jeff Johnson
2024-04-22 12:04 ` Kalle Valo
2024-04-22 16:09 ` Jeff Johnson [this message]
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=f30ad02c-0c52-4a28-b63f-22ae84f23b77@quicinc.com \
--to=quic_jjohnson@quicinc.com \
--cc=ath12k@lists.infradead.org \
--cc=kvalo@kernel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).