<div dir="ltr">Hi Aleksander,<div><br></div><div>I've got some problems configuring MM for this test. This is the message I got just after applying the patch:<br><br><div><div>ModemManager[28005]: <debug> [1490621030.009049] [mm-base-manager.c:263] device_added(): (tty/ttyS0): adding device at sysfs path: /sys/devices/pnp0/00:05/tty/ttyS0</div><div>ModemManager[28005]: <debug> [1490621030.009100] [kerneldevice/mm-kernel-device-udev.c:474] kernel_device_is_candidate(): (tty/ttyS0): port's parent platform driver is not whitelisted</div></div><div><br></div><div>I saw the other email about udev rule to whitelist the serial device, but it seems I could not get it right.</div><div><br></div><div>This is the udevadm info about the serial that responds to AT commands</div><div><br></div><div><div>$ udevadm info --attribute-walk /sys/class/tty/ttyS0</div><div><br></div><div>Udevadm info starts with the device specified by the devpath and then</div><div>walks up the chain of parent devices. It prints for every device</div><div>found, all possible attributes in the udev rules key format.</div><div>A rule to match, can be composed by the attributes of the device</div><div>and the attributes from one single parent device.</div><div><br></div><div>  looking at device '/devices/pnp0/00:05/tty/ttyS0':</div><div>    KERNEL=="ttyS0"</div><div>    SUBSYSTEM=="tty"</div><div>    DRIVER==""</div><div><br></div><div>  looking at parent device '/devices/pnp0/00:05':</div><div>    KERNELS=="00:05"</div><div>    SUBSYSTEMS=="pnp"</div><div>    DRIVERS=="serial"</div><div>    ATTRS{id}=="PNP0501"</div><div><br></div><div>  looking at parent device '/devices/pnp0':</div><div>    KERNELS=="pnp0"</div><div>    SUBSYSTEMS==""</div><div>    DRIVERS==""</div><div><br></div><div>I tried adding the line</div><div><br></div><div>    DRIVERS=="serial", ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"<br></div><div><br></div></div><div>to 77-mm-platform-serial-whitelist.rules and reloading the rules, but it doesn't seem the correct way to do it.</div><div><br></div><div>What am I doing wrong?</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, 25 Mar 2017 at 19:32 Aleksander Morgado <<a href="mailto:aleksander@aleksander.es">aleksander@aleksander.es</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Dan, Daniele, Carlo & everyone,<br class="gmail_msg">
<br class="gmail_msg">
This series of patches tries to implement proper flow control settings on the serial port, and is based on letting MM detect which are the supported modes with AT+IFC=?. This makes it unnecessary to subclass the flow control setting in plugins for modems that don't support XON/XOFF (what was being used as default), like the Telit plugin.<br class="gmail_msg">
<br class="gmail_msg">
The new logic will:<br class="gmail_msg">
  * Always open the serial ports without any flow control enabled.<br class="gmail_msg">
  * Query the modem which flow control methods are supported, with AT+IFC=?.<br class="gmail_msg">
  * If supported, prefer RTS/CTS over XON/XOFF, and notify the modem via AT+IFC=x,x our selection.<br class="gmail_msg">
  * When the port gets connected after an ATD call, reconfigure the TTY with the flow control attributes corresponding to the method we selected via AT+IFC.<br class="gmail_msg">
  * pppd may be run without any of the explicit options regarding flow control, which means that whatever was configured in the TTY is used.<br class="gmail_msg">
  * On port disconnection, we clear the flow control attributes of the TTY explicitly, although this is really not totally needed as we fully close and re-open the port (and during the re-open the port is opened without flow control enabled).<br class="gmail_msg">
<br class="gmail_msg">
I prepared this logic for the Telit LE866-SV1, although it really is generic for every RS232 modem out there.<br class="gmail_msg">
<br class="gmail_msg">
What do you guys think?<br class="gmail_msg">
<br class="gmail_msg">
[PATCH 1/8] helpers: new parser for AT+IFC=?<br class="gmail_msg">
[PATCH 2/8] broadband-modem: query supported flow control modes<br class="gmail_msg">
[PATCH 3/8] wavecom: ignore custom flow control handling<br class="gmail_msg">
[PATCH 4/8] telit: ignore custom flow control handling<br class="gmail_msg">
[PATCH 5/8] port-serial: new internal method to run tcsetattr()<br class="gmail_msg">
[PATCH 6/8] port-serial: new method to explicitly set flow control<br class="gmail_msg">
[PATCH 7/8] port-serial: remove all default flow control settings<br class="gmail_msg">
[PATCH 8/8] broadband-bearer: once connected, set flow control<br class="gmail_msg">
</blockquote></div>