On Mon, Sep 09, 2013 at 04:12:21PM -0500, Daniel Santos wrote:One of my original requirements for this driver is that it isOK, this is a lot like the plugin modules that are fairly common in
reusable for different devices that use the MCP2210, not just my own
hardware. There are a number of ways to accomplish this, but I'm
still new to Linux device drivers, so I don't know how an "abstract
driver" would work other than just making it a library that doesn't
register its self as a driver. The theory is that you should be
able to specify your own USB vid/pid and have your driver probe on
that, then feed the generic MCP2210 driver/library your board wiring
information and any parameters your other drivers need (spi or
gpio-driven peripherals on the board) and let the MCP2210
driver/library do potentially everything else for you, unless your
device has some needs that aren't covered.
embedded reference designs. I do have some ideas for how to put an
indirection layer in front of them but I'm not sure they're that
exciting - I expect what you end up doing will be having tables of child
device configurations registered based on the vendor ID, the vendor ID
support in the USB subsystem will let you provide either an index into
an array or just a pointer to the data for the specific board.
Another requirement is for my specific device to vary its hardwareThat doesn't seem so bad, you can just have the decode of the main
somewhat, but (possibly) use the same vid/pid for these. Maybe this
is some cardinal sin and a unique pid and model number for each
variant is called for (like I said, I'm still new to this stuff).
None the less, I've dealt with these two problems by creating an
encoding scheme (which I've dubbed "Creek", since I figured I was up
one if it didn't work) that compresses the data so that it will fit
easily in the 256 bytes of user-EEPROM on the chip.
VID/PID kick off the decode of the EEPROM contents.
At the time I wrote this, I knew very little about the device treeDevice tree is more applicable on a system level, it's not something
and nothing about this Open Firmware format, so now I want to make
sure I'm not re-inventing some wheel or circumventing a standard
unnecessarily. Then, as I was working on figuring out how to
propagate IRQs, I noticed that the irq_domain_add_linear() accepted
a pointer to struct device_node and didn't not accept NULL. This
made me think that I was missing something.
it's sensible to mandate for a USB device. The struct device is as much
for in kernel usage as anything else, there are helpers to make DT
transparent but it all works perfectly fine on systems that don't even
have DT support built in.
So in summary, I need to make sure that what I'm doing 1.) makesIt doesn't seem unreasonable to me, though it'd be good to review the
sense, 2.) adheres to standards (unless the standard fails to
fulfill the real-world requirements) and 3.) doesn't unnecessarily
introduce a new way to do something that's already done better
elsewhere.
specifics of course.