[PATCH 1/2] nas: add Get Operator Name and Operator Name indication
Aleksander Morgado
aleksander at aleksander.es
Mon Feb 13 23:46:39 UTC 2017
On Mon, Feb 13, 2017 at 10:57 PM, Dan Williams <dcbw at redhat.com> wrote:
>> > > > + // NAS common TLVs
>> > > > +
>> > > > + { "common-ref" : "NAS Service Provider Name",
>> > > > + "name" : "Service Provider Name",
>> > > > + "id" : "0x10",
>> > > > + "mandatory" : "no",
>> > > > + "type" : "TLV",
>> > > > + "format" : "sequence",
>> > > > + "contents" : [ { "name" : "Display
>> > > > Condition",
>> > > > + "format" : "guint8" },
>> > >
>> > > Any idea what this display condition is?
>> >
>> > Looks like this TLV is really just EFspn in QMI TLV form. So the
>> > Display Condition is from ETSI TS 151 011 EFspn docs, which is a
>> > bitfield:
>> >
>> > b1=0: display of registered PLMN not required when
>> > registered PLMN is either HPLMN or a PLMN in
>> > the Service Provider PLMNN List (see EF SPDI ).
>> > (I have 3 MVNO SIMs that return 0)
>> >
>> > b1=1: display of registered PLMN required when
>> > registered PLMN is either HPLMN or a PLMN in
>> > the Service Provider PLMN List (see EF SPDI ).
>> > (I have 1 MVNO SIM that returns 1)
>> >
>> > b2=0: display of the service provider name is
>> > required when registered PLMN is neither HPLMN
>> > nor a PLMN in the service provider PLMN
>> > list(see EF SPDI ).
>> >
>> > b2=1: display of the service provider name is not
>> > required when registered PLMN is neither HPLMN
>> > nor a PLMN in the service provider PLMN
>> > list(see EF SPDI ).
>> >
>> > I suppose we could enum it for clarity?
>>
>> Definitely yes. Maybe a flags enumeration with 2 items is just
>> enough?
>> Or better to have all 4 combinations in an enumeration?
>
> So I did this as you'll see in the v2 patch. But damn is the name long
> since 1 << 0 means "required to show" but 1 << 1 means "not required to
> show". Thanks ETSI!
Heh; well at least is more or less clear from the flag name what the
flag is about. I prefer a long name than "what was this b2 flag for".
--
Aleksander
https://aleksander.es
More information about the libqmi-devel
mailing list