Unload the driver if platform_driver register fails, add README to explain the history of MTS-IO4.9.1

1 files changed, 67 insertions, 0 deletions

diff --git a/README b/README
index d4a3df6..980ea75 100644
--- a/README
+++ b/README
@@ -15,3 +15,70 @@ 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 be 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.
+