[PATCH] telit: use g_assert instead of g_assert_true / g_assert_false

[Ben Chan]

`g_assert_true' and `g_assert_false' are defined in glib 2.38 or later.
The minimum glib version currently required by ModemMamanger is 2.36.
While `g_assert_true' and `g_assert_false' may be preferred over the
more generic `g_assert', it seems like overkill to bump the minimum glib
version requirement just for that. When more code in ModemManager later
requires newer versions of glib, we can migrate all existing code to use
`g_assert_true' and `g_assert_false' when appropriate.
---
 plugins/telit/tests/test-mm-modem-helpers-telit.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/plugins/telit/tests/test-mm-modem-helpers-telit.c 
b/plugins/telit/tests/test-mm-modem-helpers-telit.c
index 2da60c11..88a889e6 100644
--- a/plugins/telit/tests/test-mm-modem-helpers-telit.c
+++ b/plugins/telit/tests/test-mm-modem-helpers-telit.c
@@ -101,9 +101,9 @@ test_mm_bands_contains (void) {
 for (i = 0; i < 3; i++)
 g_array_append_val (mm_bands, i);
 
-g_assert_true (mm_telit_bands_contains (mm_bands, 2));
-g_assert_true (mm_telit_bands_contains (mm_bands, 2));
-g_assert_false (mm_telit_bands_contains (mm_bands, 3));
+g_assert (mm_telit_bands_contains (mm_bands, 2));
+g_assert (mm_telit_bands_contains (mm_bands, 2));
+g_assert (!mm_telit_bands_contains (mm_bands, 3));
 
 g_array_free (mm_bands, TRUE);
 }
@@ -134,7 +134,7 @@ test_parse_band_flag_str (void) {
_flags,
);
 g_assert_no_error (error);
-g_assert_true (res);
+g_assert (res);
 
 for (j = 0; j < band_flag_test[i].band_flags_len; j++) {
 guint ref;
@@ -143,7 +143,7 @@ test_parse_band_flag_str (void) {
 ref = band_flag_test[i].band_flags[j];
 cur = g_array_index (band_flags, guint, j);
 
-g_assert_true (ref == cur);
+g_assert (ref == cur);
 }
 
 g_array_free (band_flags, TRUE);
@@ -225,7 +225,7 @@ test_parse_supported_bands_response (void) {
,
);
 g_assert_no_error (error);
-g_assert_true (res);
+g_assert (res);
 
 
 for (j = 0; j < supported_band_mapping_tests[i].mm_bands_len; j++) {
@@ -302,7 +302,7 @@ test_parse_current_bands_response (void) {
,
);
 g_assert_no_error (error);
-g_assert_true (res);
+g_assert (res);
 
 
 for (j = 0; j < current_band_mapping_tests[i].mm_bands_len; j++) {
-- 
2.11.0.390.gc69c2f50cf-goog

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [systemd-devel] WebUSB

[Christer Weinigel]

On 2017-01-10 19:55, Lars Knudsen wrote:
> On Tue, Jan 10, 2017 at 7:08 PM, Dan Williams  > wrote:
> And we're quite happy to keep blacklisting specific VID/PID combos we
> know are not modems. Another possible solution is to greylist devices
> that happen to have webusb descriptors, such that they won't get auto-
> probed, but could be probed on-demand via D-Bus.  But I'd rather that
> happen via udev rules than MM trying to walk USB device attributes and
> parsing webusb descriptors.
> 
> Actually, that sounds like a very good compromise.  I remember my own
> struggles 3-4 years ago when I had to get a device working properly on
> ChromeOS and Ubuntu, where the firmware had to handle that the first ~16
> seconds it would *sometimes* get sent strange AT commands (the probing)
> all while the system thought it could already start speaking with the
> device over e.g. chrome.serial.  Eventually you (modemmanager) were kind
> enough to get our VID/PID listed and ChromeOS was quick to pick it up
> (~5-6 months to get in stable) and ubuntu so kind to upgrade to the
> version of modemmanager including our blacklisting approx 2.5 years
> later (sigh) ;)

Weird question: should modem manager really autoprobe _every_ serial
device nowdays?  99% of the devices I connect to my laptop are not
modems.  They are serial ports on development platforms, RS485
interfaces, Arduinos with a FTDI, CP210x or CH341 USB-UART bridge, and
so on.  Modems with a physical serial port are almost nonexistent today.
 For me it's a pain in the back to have to update the blacklist of
things modem manger shouldn't touch.

Wouldn't it be better to whitelist known ḿodems and have modem manager
ignore everything else?  Devices which are so new that modem manager
don't know about them can be configured manually.

At least to me that seems like a much more sane default.

  /Christer
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [systemd-devel] WebUSB

[Oliver Neukum]

Am Mittwoch, den 11.01.2017, 16:01 +0100 schrieb Lars Knudsen:
> If it can be invoked via DBus - what is the harm to only do the scan
> for the greylisted (in this case webusb) modems when the user
> actually wants to search for a modem (like a printer) - and leave the
> poor devices alone otherwise?  In headless systems, it will not be
> the same problem as they will most probably be custom made anyway.

Why have a list at all? Would you want the kernel to do an unrequested
probe of a device (function) with WebUSB descriptors at all?
It seems to me that the finest granularity you might need is by
device class, e.g. probing HID devices, so you don't block
the keyboard.

Regards
Oliver

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [systemd-devel] WebUSB

[Oliver Neukum]

On Tue, 2017-01-10 at 19:55 +0100, Lars Knudsen wrote



> And we're quite happy to keep blacklisting specific VID/PID
> combos we
> know are not modems. Another possible solution is to greylist
> devices
> that happen to have webusb descriptors, such that they won't
> get auto-
> probed, but could be probed on-demand via D-Bus.  But I'd
> rather that
> happen via udev rules than MM trying to walk USB device
> attributes and
> parsing webusb descriptors.

> 
> If greylisting prevents auto-probing, I think it would be very
> valuable for devices with a WebUSB header because those will in most
> cases (as I see them used) be industrial things (like my current
> medical company employer) or IoT devices.  And waiting ~16 seconds for
> a fallback to USB Serial where WebUSB is not available (or for other
> reasons not chosen), can be a real pain.
> 
> 
> I agree that a solid udev rule would be a good way forward (I'll look
> into greylisting and see if I can come up with something that covers)
> and maybe this could also be the place to do the user space access (or
> not - I'll try to come back with something.

I am afraid this would not work. Or rather it would work once.
But as soon as the driver is already loaded, it will bind and
we have a beautiful race condition, which the kernel will almost
certainly win.
> 
And if we happen to look at a storage device we may see an unclean
removal if you kick the kernel off a device. I am afraid if you
really want to go to triggered probing, you need a sysctl for that.

Regards
Oliver


___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [systemd-devel] WebUSB

[Dan Williams]

On Wed, 2017-01-11 at 16:01 +0100, Lars Knudsen wrote:
> If it can be invoked via DBus - what is the harm to only do the scan
> for
> the greylisted (in this case webusb) modems when the user actually
> wants to
> search for a modem (like a printer) - and leave the poor devices
> alone
> otherwise?  In headless systems, it will not be the same problem as
> they
> will most probably be custom made anyway.

Yes, headless/embedded/industrial systems are fairly easy as they are
well controlled.  Desktop-type use-cases expect things to just work
when plugged in, but modem (and USB device in general) OEMs are a
contrary bunch and often don't bother to identify their devices in a
way that lets them be used easily by the OS.

I'd love a magic "this is a modem!" descriptor, but we don't have one
and never will.  While I don't want to get into a huge UI discussion,
unless devices are network connected, searching isn't the normal way
devices get found.  They get plugged in, and they just work.  And we
get to figure out all the details like this :)

Related question though; if it's a webusb modem or even a cdc-acm
device, is the issue the *time* taken by probing, or the AT/DM requests
themselves?  Most devices I know of (modem or not) will disregard
communication they don't know about as a function of their protocol. 
MM's probe process does not alter device state in any way, just
requests informational responses.

Dan

> On Wed, Jan 11, 2017 at 3:32 PM, Dan Williams 
> wrote:
> 
> > On Wed, 2017-01-11 at 14:21 +0100, Christer Weinigel wrote:
> > > On 2017-01-10 19:55, Lars Knudsen wrote:
> > > > On Tue, Jan 10, 2017 at 7:08 PM, Dan Williams  > > > > wrote:
> > > > And we're quite happy to keep blacklisting specific VID/PID
> > > > combos we
> > > > know are not modems. Another possible solution is to
> > > > greylist
> > > > devices
> > > > that happen to have webusb descriptors, such that they
> > > > won't
> > > > get auto-
> > > > probed, but could be probed on-demand via D-Bus.  But I'd
> > > > rather that
> > > > happen via udev rules than MM trying to walk USB device
> > > > attributes and
> > > > parsing webusb descriptors.
> > > > 
> > > > Actually, that sounds like a very good compromise.  I remember
> > > > my
> > > > own
> > > > struggles 3-4 years ago when I had to get a device working
> > > > properly
> > > > on
> > > > ChromeOS and Ubuntu, where the firmware had to handle that the
> > > > first ~16
> > > > seconds it would *sometimes* get sent strange AT commands (the
> > > > probing)
> > > > all while the system thought it could already start speaking
> > > > with
> > > > the
> > > > device over e.g. chrome.serial.  Eventually you (modemmanager)
> > > > were
> > > > kind
> > > > enough to get our VID/PID listed and ChromeOS was quick to pick
> > > > it
> > > > up
> > > > (~5-6 months to get in stable) and ubuntu so kind to upgrade to
> > > > the
> > > > version of modemmanager including our blacklisting approx 2.5
> > > > years
> > > > later (sigh) ;)
> > > 
> > > Weird question: should modem manager really autoprobe _every_
> > > serial
> > > device nowdays?  99% of the devices I connect to my laptop are
> > > not
> > > modems.  They are serial ports on development platforms, RS485
> > > interfaces, Arduinos with a FTDI, CP210x or CH341 USB-UART
> > > bridge,
> > > and
> > > so on.  Modems with a physical serial port are almost nonexistent
> > > today.
> > >  For me it's a pain in the back to have to update the blacklist
> > > of
> > > things modem manger shouldn't touch.
> > 
> > MM does already whitelist platform serial devices (eg, i8250 UART)
> > and
> > already greylists USB<->serial adapters like FTDI and CP210x.
> > 
> > Unfortunately, you'd be surprised how many modems actually *do* get
> > hooked up with USB<->serial converters like FTDI and CP210x.  Modem
> > manufacturers often build these chips into devices so the modem
> > looks
> > like USB but uses a generic VID/PID and a generic driver (FTDI).
> > 
> > If you have updates to the blacklist, we'd happily take them.
> > 
> > > Wouldn't it be better to whitelist known ḿodems and have modem
> > > manager
> > > ignore everything else?  Devices which are so new that modem
> > > manager
> > > don't know about them can be configured manually.
> > 
> > I ran a list of explicit modem VID/PID pairs in kernel drivers
> > (like
> > option, qmi_wwan, sierra, hso, etc) 2 years ago and there were
> > >1000
> > known WWAN modems.
> > 
> > That >1000 does *not* count attribute-matched devices like CDC ACM
> > devices, CDC WDM/ether, generic serial bridge modems (FTDI/CP210x),
> > or
> > USB interface class/subclass/protocol matching which many Huawei
> > devices now use instead.  Whitelisting is simply not really an
> > option,
> > unfortunately, as too many new modem devices actually do come out
> > every
> > year.  Thankfully, many these days are MBIM (thanks to Windows 

Re: [systemd-devel] WebUSB

[Aleksander Morgado]

On Wed, Jan 11, 2017 at 2:21 PM, Christer Weinigel  wrote:
>> Actually, that sounds like a very good compromise.  I remember my own
>> struggles 3-4 years ago when I had to get a device working properly on
>> ChromeOS and Ubuntu, where the firmware had to handle that the first ~16
>> seconds it would *sometimes* get sent strange AT commands (the probing)
>> all while the system thought it could already start speaking with the
>> device over e.g. chrome.serial.  Eventually you (modemmanager) were kind
>> enough to get our VID/PID listed and ChromeOS was quick to pick it up
>> (~5-6 months to get in stable) and ubuntu so kind to upgrade to the
>> version of modemmanager including our blacklisting approx 2.5 years
>> later (sigh) ;)
>
> Weird question: should modem manager really autoprobe _every_ serial
> device nowdays?  99% of the devices I connect to my laptop are not
> modems.  They are serial ports on development platforms, RS485
> interfaces, Arduinos with a FTDI, CP210x or CH341 USB-UART bridge, and
> so on.  Modems with a physical serial port are almost nonexistent today.
>  For me it's a pain in the back to have to update the blacklist of
> things modem manger shouldn't touch.
>
> Wouldn't it be better to whitelist known ḿodems and have modem manager
> ignore everything else?  Devices which are so new that modem manager
> don't know about them can be configured manually.
>
> At least to me that seems like a much more sane default.

Not a weird question, we've already discussed this same thing several times.
https://bugs.freedesktop.org/show_bug.cgi?id=85007

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel