This is the kernel module that instantiates
/sys/devices/platform/mts-io

A shell utility is included to read
driver created files in the platform/mts-io
directory.

A binary utility is included to reset
the LoRa 2.1 board.  The mts-io driver
does not instantiate any resets for the
LoRa 2.1 board.  Instead this board is
reset via the mainboard I2C bus which includes
the on-board EE-PROM.

dev_dbg can be turned on when loading the
mts-io driver.  See debug/README and
debug/etc/modprobe.d/mts-io.conf

HISTORY:
Before the 4.9 kernel, mLinux used a patch
of the GPIO library to add pull up and pull
down capability to the GPIO flags.

This patch did not easily fit with
newer kernels.  So instead, the pull
up and pull down code was moved todata
device tree and AT91Pincontrol
(for Atmel processors)
from the mts-io driver.

When the mts-io module was loaded, the
device tree was scanned, and the
pinctrl elements in device tree
associated with the mts-io driver
were loaded.

Before the 4.9 version of the mts-io
driver, on initial load, the probe
function was executed.  The probe
function in the device tree model
of the kernel causes a search
of the device tree and when
an element is found with the appropriate
compatible property, that part of the device tree
is loaded.  This caused the attached
pinctrl sections to be read and the pins
configured.

Because the kernel doc suggests adding
a number at the end of a node name, mts-io-0
was chosen.

Because the mts-io driver had always allocated
its own platform, it already had a
platform called mts-io.  Because of this, we
did a platform_driver_register, followed
immediately by a platform_driver_unregister.
This allowed us to set up the pins using
device tree and allowed us to keep all
the old code that created and used the
platform driver with a minimum of changes.
The device tree used mts-io-0 for the 
mts-io driver node which became
/sys/devices/platform/mts-io-0.  The
mts-io driver continues to use
/sys/devices/platform/mts-io.

Now at the 4.9 mts-io version level,
an attempt is made to move towards using
the gpio connection-id's from the
newer gpiod library.  These connection-ids
are referred to as "names" in device tree
documentation.  It is no longer possible
to free the platform loaded by 
platform_driver_register, because
we need to use these device tree
entries later in the driver.

GPIO pins are then attached through the GPIO
descriptor found by making a call to
kernel functions like devm_gpiod_get_optional(),
which has a connection-ID as its second
parameter.