From: Denis Kenzior <denkenz@gmail.com>
To: Grant Erickson <gerickson@nuovations.com>
Cc: ofono@lists.linux.dev
Subject: Re: [PATCH v2 4/7] qmi: Implement QMI service request rate limiting in 'can_write_data'.
Date: Fri, 14 Feb 2025 09:23:19 -0600 [thread overview]
Message-ID: <7dc06a7b-482f-4ea5-93ec-d645e046257e@gmail.com> (raw)
In-Reply-To: <500BF5FA-3998-40EA-BE10-EEB6955D8328@nuovations.com>
Hi Grant,
>
> There are two separate actions to be taken:
>
> 1. Performing the rate limit check before the request is dequeued and sent.
> 2. Setting the last sent time after the request is dequeued and successfully sent.
I'd rearrange the whole thing such that 2 isn't needed. If you update the last
sent time in 1, the worst that can happen is that the write() will fail. Which
will probably trigger a socket close shortly afterward anyway.
>
> So, there need to be two, separate conditional blocks for each.
>
Only if you want to deal with compiler warnings ;)
>> Also, don't you need last_req_sent_time_us to be initialized to be non-zero somehow? Otherwise it is dumb luck that last_req_sent_time_us is set to anything the first time (probably garbage data)
>
> I thought about zero-initializing it in ‘qmi_qmux_device_new’; however, diving into the
That is not what I'm talking about. l_new does indeed zero-initialize
everything. Explicit init to 0 is not needed (or wanted). See my reply to v3.
implementation of ‘l_new’, it appears as though all memory is zeroed out, so the
zero-initialization seemed redundant.
>
Regards,
-Denis
next prev parent reply other threads:[~2025-02-14 15:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-13 0:33 [PATCH v2 0/7] Add QMI Device Service Request Rate-limit Option Grant Erickson
2025-02-13 0:33 ` [PATCH v2 1/7] qmi: Added enumeration for device quirk flags Grant Erickson
2025-02-13 0:33 ` [PATCH v2 2/7] qmi: Added structure for device options Grant Erickson
2025-02-13 0:33 ` [PATCH v2 3/7] qmi: Added device options parameter to 'qmi_qmux_device_new' Grant Erickson
2025-02-13 0:33 ` [PATCH v2 4/7] qmi: Implement QMI service request rate limiting in 'can_write_data' Grant Erickson
2025-02-13 2:07 ` Denis Kenzior
2025-02-14 4:22 ` Grant Erickson
2025-02-14 4:54 ` Grant Erickson
2025-02-14 15:23 ` Denis Kenzior [this message]
2025-02-13 0:33 ` [PATCH v2 5/7] qmi: Handle request rate limit option in 'qmi_qmux_device_new' Grant Erickson
2025-02-13 0:33 ` [PATCH v2 6/7] udevng: Set the QMI minimum service request period for Quectel BG96 modems Grant Erickson
2025-02-13 0:33 ` [PATCH v2 7/7] gobi: Pass QMI qmux device options to 'qmi_qmux_device_new' Grant Erickson
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=7dc06a7b-482f-4ea5-93ec-d645e046257e@gmail.com \
--to=denkenz@gmail.com \
--cc=gerickson@nuovations.com \
--cc=ofono@lists.linux.dev \
/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.