All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH v3] qmimodem: support wake on SMS receive
Date: Wed, 05 Jun 2019 10:09:55 -0500	[thread overview]
Message-ID: <6b881449-6cfc-c951-f8ce-06e94cb4674c@gmail.com> (raw)
In-Reply-To: <1507338948.2591.1559746007437@wamui-aurora.atl.sa.earthlink.net>

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

Hi Tom,

>>> Also, it may be clearer if the introduction of raw_read and the
>>> refactoring of this function are done as a separate commit.
>>>
>>
>> Hmm, looking at the "Quectel EC21" comment again, looks like the original code was done to address a quirk (ie, bug???) with that modem. I'll revert to reading both.

Jonas was the one who introduced that, so he would be the one to ask :)

>>
>> But, per spec, the 2 message TLVs are mutually exclusive, depending on the route action configuration. I'm referring to setting "new_list->route[0].action =" in get_routes_cb(). So, we shouldn't need to always read both since one is guaranteed to fail.
>>
>> Also, the original code, if somehow both "notify" and "message" are NULL, it'll erroneously use a null notify. I'll address this in the revert.
>>
> 
> On 2nd thought, my change is still ok per that "Quectel EC21" comment. I'll keep my changes and add 

Yes, it looked like it would work even for the quirky ec21, but I don't 
have enough context to say for sure.  Nor do I have a EC21 to test

comment to explain the 2 TLV that are being queried. Also, I introduced 
raw_read because I need to pull QMI_WMS_RAW_READ out of event_notify to 
service both event_notify and the message list. So, I'd like to keep 
this in the same commit.

Yes exactly my point.  You can have the first commit simply perform the 
'pull QMI_WMS_RAW_READ out of event_notify' transformation, which is 
more or less self-contained.  And then the second commit would use that 
new utility function in your message list code.

Smaller commits are easier to review.  When I mentor new contributors I 
always encourage them to split up their code as much as possible.  In 
this particular instance I won't insist too hard since it is likely fine 
either way :)

Regards,
-Denis

  reply	other threads:[~2019-06-05 15:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-28  1:48 [PATCH v3] qmimodem: support wake on SMS receive Tom Nguyen
2019-06-05 15:09 ` Denis Kenzior [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-09-28  1:48 Tom Nguyen
2019-09-28  1:48 Tom Nguyen
2019-09-28  1:48 Tom Nguyen
2019-05-24 17:56 ` Denis Kenzior

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=6b881449-6cfc-c951-f8ce-06e94cb4674c@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ofono@ofono.org \
    /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.