Hi, On Tue, Apr 09, 2013 at 02:00:46PM -0500, Daniel Santos wrote: > >>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 not sure you can. There is no standardization wrt USB to SPI > >bridges, so your device implements a proprietary protocol (even if > >simple). > > > >>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 > >this might cause problems. If everybody has the same idVendor/idProduct > >pair but functionality is different... ugh > Well, we don't have the $3500 for a vendor id. :( I presume that > others may do the same thing, hopefully mostly with DIY-type of > projects. heh :-) > >Your core driver would instantiate each of those children devices based > >on what's the requested state of the pin. > > > >>* 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.) > >is this mandatory, or something you decided to do ? If it's mandatory to > >program pin assignment like that, then you can very easily figure out > >how to use that information to instantiate proper children during your > >core driver's probe routine. > > Well, I guess I need to be more clear about this. I'm talking about > 3 separate entities really: > > 1. the MCP2210 chip its self, > 2. the hardware device that I'm creating that makes use of this chip and > 3. any hardware devices that others may create with it. > > So one idea of how to do this is to have generic MCP2210 driver that > does pretty much nothing by its self (not 100% sure how this should > work). Then, I would have a driver for my device, that would use the > generic MCP2210 driver to manage all of the communication with the > MCP2210 and I would simply feed it my hardware configuration (wiring, > SPI timings, etc.), causing it to expose SPI devices, GPIO lines, > LEDs, etc. as you described. Then, a 3rd party could do the same > (hopefully, they will modify the idVendor & idProduct though. :) I > suppose there's room for an MCP2210 userspace driver that utilizes > the generic one to interface with the chip and just provides an > interface to userspace, but I'm not personally interested in such a > thing myself. > > So I'm thinking that with my own driver, I would look for the > idVendor and idProduct of the unmodified MCP2210 (because I'm a poor > bastard) and then -ENODEV unless the product & mfg strings also no need to look for it, just use the id_table to match your idVendor and idProduct. Driver model will make sure to bind your device properly so you can assume that if your probe() has been called, it's because driver model has found idVendor/idProduct properly. > match. Then, I can read the EEPROM to cook up my config. (One > complexity is that our device can have various features & hardware > present or not, so that's another reason for us to stick the hardware > setup in the EEPROM.) alright. > Does that make sense? Also, the "generic driver" then becomes more of > a library than an actual driver, huh? I think it should still be a driver, just an MFD driver. > >If it's not mandatory, then it gets tricky to support multiple users. > >Can users write whatever they want to EEPROM or is there a specified > >format ? > > The MCP2210 allows you to write-protect the persistent settings > (including the EEPROM contents) with a password or just permanently > lock them. You have to issue USB commands to alter the EEPROM and I > don't plan on exposing that to userspace from the driver for my > product. So if anybody changes them, its their own damn fault. :) right on ;-) > >In any case, there are ways to make it work, just some are easier to > >code then the others ;-) > > Well this helps a great deal, thank you! I want to try to keep this > simple, but I also would like it to be re-usable. There are > currently USB to serial, 1-wire and I think i2c in the kernel already > and I would expect this class of device will become more prevalent in > the future. my suggestion would be: write it very simple, if in the future some similar device comes around, then we think about re-factoring and making it more generic ;-) -- balbi
Attachment:
signature.asc
Description: Digital signature
