On Mon, Sep 09, 2013 at 04:12:21PM -0500, Daniel Santos wrote: > On 09/09/2013 06:06 AM, Mark Brown wrote: > >On Sat, Sep 07, 2013 at 07:19:06PM -0500, Daniel Santos wrote: > >>I have some secondary (and less important) questions about how to > >>integrate this with device drivers that want a DT / open firmware > >>config (which I know almost nothing about at this time), but that > >>can wait. > >Could you be more specific about what you mean by "integrate" here? > One of my original requirements for this driver is that it is > 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. OK, this is a lot like the plugin modules that are fairly common in 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 hardware > 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. That doesn't seem so bad, you can just have the decode of the main VID/PID kick off the decode of the EEPROM contents. > At the time I wrote this, I knew very little about the device tree > 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. Device tree is more applicable on a system level, it's not 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.) makes > 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. It doesn't seem unreasonable to me, though it'd be good to review the specifics of course.
Attachment:
signature.asc
Description: Digital signature
