Hello!
My bother & I are working on a project where we're planning on using
these inexpensive Microchip MCP2210 USB to SPI bridge w/ GPIO devices.
Mathew King at Trilithic started a driver and kindly released it on
github (https://github.com/MathewKing/mcp2210-linux), but he wont be
using the chip or developing the driver further, so I'm picking it up
(and with his blessings even! :) However, rather than a driver written
specifically for our product, I would like a generic or abstract MCP2210
driver that can be re-used by others. So how do I go about this?
I'm still pretty new to Linux device drivers & the device driver model,
so there may be existing abstractions & libraries that I'm just not yet
aware of. We're not planning on changing the USB vendor/product ID (as
I'm sure many users of this chip will opt) and each or our devices can
have different hardware & wirings attached to the MCP2210. Since SPI
devices cannot be auto-configured, we plan to probe as follows:
* In the USB probe, examine the iProduct string to match our specific
product (maybe iManufacturer as well) and if it matches, to bind to the
device.
* The MCP2210 has 9 GP pins that can each be used as either an SPI chip
select, GPIO or a 'dedicated function' (power LED, interrupt input line,
etc.). Once bound, we can examine the 'power-up chip settings' (section
3.1.7 in the datasheet --
http://ww1.microchip.com/downloads/en/DeviceDoc/22288A.pdf) and treat
that as the specification as to how each GP pin is used in this device.
* Finally, retrieve the (previously stored) data from the 256 bytes of
user non-volatile EEPROM. On this, we plan to store the device
information that each of the GP pins configured for SPI CS lines are
connected as well as the use for any GPIO lines. (Pins configured for
'dedicated function' need no other information.)
I'm not yet settled on the exact mechanism, format, etc. for this
'device information' on the EEPROM, but between this and what the driver
knows it must specify unambiguously what devices are connected to what
CS pins, how to talk to them (timings, etc.). So once we know what
we're connected to and how to talk to it, we can do our SPI probe.
While I anticipate this to work great for my stuff, it would be absurd
to impose this schema on somebody else using this chip (with the
original vendor/product id or not). Thus, I'm not sure how to go about
coding the MCP2210 driver as an abstract interface to take care of the
details of this device, accepting an external configuration during the
USB probe and exposing what is actually needed to other drivers (or
*cringe* userspace), rending the code both attractive and reusable.
Here are the things I've thought of:
1. Discover that the kernel already contains an abstraction layer for an
x to SPI bridge device and that I just need to write an MCP2210 driver
for it!
2. Create my own abstract x to SPI bridge API (or 'KPI') and then
implement my MCP2210 driver as a provider for said API -- not a very
attractive option for my expertise level! Not that I can't do it, I
just question how attractive it will be for to others to use. :)
3. Write the MCP2210 driver code as a generic C library used to *create*
other drivers, but not create a specific MCP2210 driver, and then
implement my driver using the generic MCP2210 driver library.
Obviously, by far, option 1 would be the best! Also, I'm intentionally
ignoring userspace options via generic-hid (there is already a
user-space library for using this chip --
https://github.com/kerrydwong/MCP2210-Library). If somebody strongly
feels that there's merit to doing this from userspace, please speak up. :)
Other options, opinions and/or advice would be greatly appreciated!
Thanks,
Daniel Santos
--
To unsubscribe from this list: send the line 'unsubscribe linux-usb' in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html