public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Minu Jin <s9430939@naver.com>
To: dan.carpenter@linaro.org
Cc: gregkh@linuxfoundation.org, andriy.shevchenko@linux.intel.com,
	abrahamadekunle50@gmail.com, zxcv2569763104@gmail.com,
	milospuric856@gmail.com, karanja99erick@gmail.com,
	weibu@redadmin.org, linux-staging@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 1/3] staging: rtl8723bs: change return type of _rtw_pktfile_read to int
Date: Thu, 22 Jan 2026 22:23:11 +0900	[thread overview]
Message-ID: <aXIkvw2bVfQwpqWF@JMW-Ubuntu> (raw)

Hi Dan,

Thanks for the feedback.
I'll drop the type-change patch and reorganize the series
into two patches for v6 as you suggested.

Regarding the return type,
I’ve audited the call sites including set_qos(), update_attrib(),
and rtw_xmitframe_coalesce(), along with their callers rtw_xmit() and xmit_frames().

Since these functions handle errors immediately and exit,
I initially thought a negative return value would be safe.

I'm curious if I missed a specific scenario in the current code,
or if your advice is more about general defensive programming—such as avoiding
future risks like implicit casting or pointer arithmetic issues.

I’d appreciate your insight on this
so I can better understand the preferred approach in the kernel.

Best regards

Minu Jin

             reply	other threads:[~2026-01-22 13:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-22 13:23 Minu Jin [this message]
2026-01-22 15:31 ` [PATCH v5 1/3] staging: rtl8723bs: change return type of _rtw_pktfile_read to int Dan Carpenter
  -- strict thread matches above, loose matches on Subject: below --
2026-01-22 14:23 Minu Jin
2026-01-22 14:35 ` Greg KH
2026-01-22  4:14 [PATCH v5 0/3] staging: rtl8723bs: improve error handling in _rtw_pktfile_read Minu Jin
2026-01-22  4:14 ` [PATCH v5 1/3] staging: rtl8723bs: change return type of _rtw_pktfile_read to int Minu Jin
2026-01-22  5:35   ` Dan Carpenter

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=aXIkvw2bVfQwpqWF@JMW-Ubuntu \
    --to=s9430939@naver.com \
    --cc=abrahamadekunle50@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dan.carpenter@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=karanja99erick@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=milospuric856@gmail.com \
    --cc=weibu@redadmin.org \
    --cc=zxcv2569763104@gmail.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