From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: vendor models and options
Date: Fri, 07 Sep 2018 10:09:32 -0500 [thread overview]
Message-ID: <da763150-e3c8-dfe4-da96-0c4e679f1aa2@gmail.com> (raw)
In-Reply-To: <CAKSBH7GEje3Gc71h1qDDnKineXL8MHtNBwZmyK+VbeJNh+JZaQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]
Hi Giacinto,
On 09/07/2018 03:09 AM, Giacinto Cifelli wrote:
> Dear Denis, all,
>
> while preparing the Gemalto driver, I see that there is a potential
> shortcoming with the vendor structure in the atmodem. I can set
> OFONO_VENDOR_GEMALTO_model, but this could be a very long list for all
> options to maintain. I see the tendency also for other manufacturers.
> Would it be ok if I convert the vendor integer in a structure with model
> and flags?
> This would make the current code more compact and clearer.
Feel free to suggest something more concrete illustrating how your
proposal would result in more compact code. It seems to me that it
would be quite disruptive, but I always try to have an open mind :)
But of course there are other 'creative' ways we can utilize to handle
this as well.
>
> The alternative of cloning the atmodem is less tempting, because then it
> needs constant monitoring of the atmodem to porting the features in it,
> or conversely missing features in this general driver. One example is
> for the indicators +CGREG/+CEREG/+C5GREG that we are adding in atmodem
> (gprs.c), instead of the unique +CGREG that doesn't work anymore for LTE
> (in the 27.007). If I add it in Gemalto driver, it will be missing in
> the atmodem.
Aren't these commands now standardized? Why do you need sub-model
information to handle this?
Either way, it is quite hard to give you any suggestions without seeing
concretely what you're trying to do. Perhaps you want to submit what
you have (or some subset that illustrates the issues you're having) to
the mailing list (even if it isn't completely ready, just tag it as
'RFC') and then I can give you more concrete feedback.
Regards,
-Denis
next prev parent reply other threads:[~2018-09-07 15:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-07 8:09 vendor models and options Giacinto Cifelli
2018-09-07 15:09 ` Denis Kenzior [this message]
2018-09-14 11:48 ` Giacinto Cifelli
2018-09-14 6:00 ` Denis Kenzior
2018-09-15 6:23 ` Giacinto Cifelli
2018-09-15 20:52 ` 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=da763150-e3c8-dfe4-da96-0c4e679f1aa2@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.