Message-ID: <5230AF80.8020100@att.net>
Date:	Wed, 11 Sep 2013 12:59:28 -0500
From:	Daniel Santos <danielfsantos@....net>
To:	Mark Brown <broonie@...nel.org>
CC:	linux-gpio <linux-gpio@...r.kernel.org>,
	linux-usb <linux-usb@...r.kernel.org>,
	linux-spi <linux-spi@...r.kernel.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: "Virtual" Interrupts -- Need help please

On 09/10/2013 01:01 PM, Mark Brown wrote:
> On Mon, Sep 09, 2013 at 04:12:21PM -0500, Daniel Santos wrote:
>> 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.

Hmm, I guess I was thinking about this in the other direction: A generic 
mcp2210 and then the new guy's writes a driver for his specific hardware 
with it's own vid/pid and he loads up mcp2210 and sends it config, but 
doesn't change mcp2210.  Honestly, I forget some of the dynamics of 
working with the kernel that differ from other projects -- anything can 
be modified at a later date to accommodate new hardware.  Just adding a 
new vid/pid entry with config would be much easier and lightweight.

>> 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.

Currently, I'm using magic.  I read the first 4 bytes of the user-EEPROM 
and if it's 0xc01df00d then I presume that it will feed me configuration 
data in the Creek format, after re-heating of course.  I left myself a 4 
bit format version field as well.

>> 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.

Ahh, well that's fun.  I want to learn about it none the less because 
the hardware that we'll interact with from usb to spi/gpio/i2s/smbus, 
etc. will typically be devices who's drivers are platform drivers.  
Thus, I would suspect that at least some of these drivers expect to be 
fed something DT or OF related?  One of my motivations here is to 
leverage existing drivers for such devices, although I'm having to write 
fresh ones for all of the chips I'm using in my real-world, actual 
money-producing project. :)

>> 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.

Wonderful!  It is certainly a relief and I very much appreciate your 
time and feedback! When I get things a little more stable and finish 
putting in the IRQ code, I would be very happy to get your help in 
reviewing it. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists