"Virtual" Interrupts -- Need help please

"Virtual" Interrupts -- Need help please

[Daniel Santos]

I've posted a number of requests for aid on this and have gotten very 
little responses and none that were helpful. I have spent at least 24 
hours of research time on this and just a little direction from somebody 
who knows this subsystem can help me immensely as the IRQ subsystem is 
new to me.

This is for the MCP2210 driver (a USB to SPI/GPIO bridge) and my driver 
is the first of its class for the Linux kernel, giving me less to look 
at as an example.  I intend to use standard drivers for whatever I have 
connected at the other end.  For this to work, I need to supply 
interrupts for some of these drivers to work correctly.  How do I do 
this? Every thing else on this driver is ready to go and my handler 
functions for this are empty and waiting for some code.

So do i create an IRQ domain and then call generic_handle_irq() from my 
URB complete() function? If so, which type of IRQ Domain is appropriate 
for this? Unlike typical platform devices, these are dynamically added 
and removed throughout the life of the kernel, adding to the challenge.  
So, if I understand correctly, my base IRQ number needs to be 
dynamically generated.  How should I manage this?

Finally, if you have any example drivers that are doing something 
similar, that would be SO very helpful as well!

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.

Any help *greatly* appreciated and thank you in advance!

Daniel

PS: If interested, my current driver here: 
https://github.com/daniel-santos/mcp2210-linux. I  haven't sought review 
yet because I want to finish it first.

Re: "Virtual" Interrupts -- Need help please

[Guenter Roeck]

On 09/07/2013 05:19 PM, Daniel Santos wrote:
> I've posted a number of requests for aid on this and have gotten very little responses and none that were helpful. I have spent at least 24 hours of research time on this and just a little direction from somebody who knows this subsystem can help me immensely as the IRQ subsystem is new to me.
>
> This is for the MCP2210 driver (a USB to SPI/GPIO bridge) and my driver is the first of its class for the Linux kernel, giving me less to look at as an example.  I intend to use standard drivers for whatever I have connected at the other end.  For this to work, I need to supply interrupts for some of these drivers to work correctly.  How do I do this? Every thing else on this driver is ready to go and my handler functions for this are empty and waiting for some code.
>
Not really. Have a look at https://github.com/groeck/diolan even though the SPI part there
still isn't working and it is far from being acceptable upstream in its current form.
It also doesn't support interrupts.

It is modeled as mfd driver, which I think you might want to consider as well.

> So do i create an IRQ domain and then call generic_handle_irq() from my URB complete() function? If so, which type of IRQ Domain is appropriate for this? Unlike typical platform devices, these are dynamically added and removed throughout the life of the kernel, adding to the challenge. So, if I understand correctly, my base IRQ number needs to be dynamically generated.  How should I manage this?
>
> Finally, if you have any example drivers that are doing something similar, that would be SO very helpful as well!
>
There are several drivers in drivers/mfd solving the same problem, ie using
irq domains to pass interrupts to client drivers. Look for irq_domain_add_simple().
drivers/mfd/tc3589x.c seems to be a good example.

> 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.
>
If you look into the mfd subsystem, you may notice that it handles at least some of the complexity
of interrupt handling as well as devicetree integration. One more reason to use it.

Guenter

> Any help *greatly* appreciated and thank you in advance!
>
> Daniel
>
> PS: If interested, my current driver here: https://github.com/daniel-santos/mcp2210-linux. I  haven't sought review yet because I want to finish it first.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>
>

Re: "Virtual" Interrupts -- Need help please

[Daniel Santos]

On 09/07/2013 07:52 PM, Guenter Roeck wrote:
> On 09/07/2013 05:19 PM, Daniel Santos wrote:
>> I've posted a number of requests for aid on this and have gotten very 
>> little responses and none that were helpful. I have spent at least 24 
>> hours of research time on this and just a little direction from 
>> somebody who knows this subsystem can help me immensely as the IRQ 
>> subsystem is new to me.
>>
>> This is for the MCP2210 driver (a USB to SPI/GPIO bridge) and my 
>> driver is the first of its class for the Linux kernel, giving me less 
>> to look at as an example.  I intend to use standard drivers for 
>> whatever I have connected at the other end.  For this to work, I need 
>> to supply interrupts for some of these drivers to work correctly.  
>> How do I do this? Every thing else on this driver is ready to go and 
>> my handler functions for this are empty and waiting for some code.
>>
> Not really. Have a look at https://github.com/groeck/diolan even 
> though the SPI part there
> still isn't working and it is far from being acceptable upstream in 
> its current form.
> It also doesn't support interrupts.

Oh, this is wonderful to know!  While I like breaking new ground, I 
certainly don't enjoy doing it when I'm trying to write my first device 
driver and having to learn so many new things.

>
> It is modeled as mfd driver, which I think you might want to consider 
> as well.
>
>> So do i create an IRQ domain and then call generic_handle_irq() from 
>> my URB complete() function? If so, which type of IRQ Domain is 
>> appropriate for this? Unlike typical platform devices, these are 
>> dynamically added and removed throughout the life of the kernel, 
>> adding to the challenge. So, if I understand correctly, my base IRQ 
>> number needs to be dynamically generated.  How should I manage this?
>>
>> Finally, if you have any example drivers that are doing something 
>> similar, that would be SO very helpful as well!
>>
> There are several drivers in drivers/mfd solving the same problem, ie 
> using
> irq domains to pass interrupts to client drivers. Look for 
> irq_domain_add_simple().
> drivers/mfd/tc3589x.c seems to be a good example.

Ahh, wonderful! I was looking at a lot of the code in mfd, but it 
contains so many things that I don't understand yet, so it's been harder 
to be clear on what the driver is doing and why w/o extensive 
examination & study of the subsystems it's using.  This will help!

>
>> 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.
>>
> If you look into the mfd subsystem, you may notice that it handles at 
> least some of the complexity
> of interrupt handling as well as devicetree integration. One more 
> reason to use it.
>
> Guenter

Even better, thank you very much!! If this thing had more EEPROM storage 
I would consider using the OF format for it's settings, but I only have 
256 bytes to play with so I'm using a custom compression/encoding.

I'm hoping to present this for an initial review in a month or so. I'm 
sure you guys will shred it, but I'm excited about it anyway! :)

Thanks again!
Daniel

Re: "Virtual" Interrupts -- Need help please

[Guenter Roeck]

On 09/08/2013 04:50 PM, Daniel Santos wrote:
> On 09/07/2013 07:52 PM, Guenter Roeck wrote:
>> On 09/07/2013 05:19 PM, Daniel Santos wrote:
>>> I've posted a number of requests for aid on this and have gotten very little responses and none that were helpful. I have spent at least 24 hours of research time on this and just a little direction from somebody who knows this subsystem can help me immensely as the IRQ subsystem is new to me.
>>>
>>> This is for the MCP2210 driver (a USB to SPI/GPIO bridge) and my driver is the first of its class for the Linux kernel, giving me less to look at as an example.  I intend to use standard drivers for whatever I have connected at the other end.  For this to work, I need to supply interrupts for some of these drivers to work correctly. How do I do this? Every thing else on this driver is ready to go and my handler functions for this are empty and waiting for some code.
>>>
>> Not really. Have a look at https://github.com/groeck/diolan even though the SPI part there
>> still isn't working and it is far from being acceptable upstream in its current form.
>> It also doesn't support interrupts.
>
> Oh, this is wonderful to know!  While I like breaking new ground, I certainly don't enjoy doing it when I'm trying to write my first device driver and having to learn so many new things.
>
>>
>> It is modeled as mfd driver, which I think you might want to consider as well.
>>
>>> So do i create an IRQ domain and then call generic_handle_irq() from my URB complete() function? If so, which type of IRQ Domain is appropriate for this? Unlike typical platform devices, these are dynamically added and removed throughout the life of the kernel, adding to the challenge. So, if I understand correctly, my base IRQ number needs to be dynamically generated.  How should I manage this?
>>>
>>> Finally, if you have any example drivers that are doing something similar, that would be SO very helpful as well!
>>>
>> There are several drivers in drivers/mfd solving the same problem, ie using
>> irq domains to pass interrupts to client drivers. Look for irq_domain_add_simple().
>> drivers/mfd/tc3589x.c seems to be a good example.
>
> Ahh, wonderful! I was looking at a lot of the code in mfd, but it contains so many things that I don't understand yet, so it's been harder to be clear on what the driver is doing and why w/o extensive examination & study of the subsystems it's using.  This will help!
>

Yes, one of the issues with mfd is its lack of documentation. I am sure the maintainer
will appreciate if you solve that problem by writing it :).

>>
>>> 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.
>>>
>> If you look into the mfd subsystem, you may notice that it handles at least some of the complexity
>> of interrupt handling as well as devicetree integration. One more reason to use it.
>>
>> Guenter
>
> Even better, thank you very much!! If this thing had more EEPROM storage I would consider using the OF format for it's settings, but I only have 256 bytes to play with so I'm using a custom compression/encoding.
>

You should really use devicetree anyway. How you get it loaded on demand is another question. Lack of storage is not a reason.
Custom data will likely not be accepted upstream, if you had that in mind.

On the other side, we'll need PC/x86 support as well (or at least I do), so support for platform data based initialization
data will be necessary as well.

> I'm hoping to present this for an initial review in a month or so. I'm sure you guys will shred it, but I'm excited about it anyway! :)
>

Let me know when you have something to test. I just ordered an evaluation board for that chip, so I'll need it soon ;).

Guenter

Re: "Virtual" Interrupts -- Need help please

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On Sun, Sep 08, 2013 at 05:35:56PM -0700, Guenter Roeck wrote:

Please fix your mailer to word wrap within paragraphs, not doing this
makes your mail very hard to read.  It looks like your mailer has also
reflowed Daniel's mail.

> On 09/08/2013 04:50 PM, Daniel Santos wrote:

> >Even better, thank you very much!! If this thing had more EEPROM
> >storage I would consider using the OF format for it's settings, but I
> >only have 256 bytes to play with so I'm using a custom
> >compression/encoding.

> You should really use devicetree anyway. How you get it loaded on
> demand is another question. Lack of storage is not a reason.  Custom
> data will likely not be accepted upstream, if you had that in mind.

If it's embedded into the device that shouldn't be such a problem -
especially for something on a pluggable bus that could be used with any
architecture device tree is pretty much a secondary concern.  Device
tree is far from universal and the main concern where it is used is
with avoiding static board files.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: "Virtual" Interrupts -- Need help please

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

On Sat, Sep 07, 2013 at 07:19:06PM -0500, Daniel Santos wrote:

> So do i create an IRQ domain and then call generic_handle_irq() from
> my URB complete() function? If so, which type of IRQ Domain is
> appropriate for this? Unlike typical platform devices, these are
> dynamically added and removed throughout the life of the kernel,
> adding to the challenge.  So, if I understand correctly, my base IRQ
> number needs to be dynamically generated.  How should I manage this?

Unless you have a particular reason for using something else you should
be using a linear domain - that's the default, it's very simple to work
with.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: "Virtual" Interrupts -- Need help please

[Alexander Holler]

Am 09.09.2013 13:02, schrieb Mark Brown:
> On Sun, Sep 08, 2013 at 05:35:56PM -0700, Guenter Roeck wrote:
>
> Please fix your mailer to word wrap within paragraphs, not doing this
> makes your mail very hard to read.  It looks like your mailer has also
> reflowed Daniel's mail.

That's just wrong. Mail readers should wrap lines, not senders. And 
readers can do this since some decades.

The reason is obvious: No sender knows the line width the receiver can 
display. So, for example, if the sender hard breaks lines every 80 
chars, a reader with a device which just displays 60 characters at max. 
will see every second line with at most 20 characters. I assume you can 
guess how such does look like. Furthermore there are still a lot of 
people which do like to read mails with line length as long their 
display is possible to show, and hard breaking lines on the receiver 
side does make such impossible.

So the correct behaviour is to not hard break lines on the sender side 
and leave that to the reader on the receiving side, as only the 
receiving side knows the line width.

Alexander Holler

Re: "Virtual" Interrupts -- Need help please

[Guenter Roeck]

On 09/09/2013 04:18 AM, Alexander Holler wrote:
> Am 09.09.2013 13:02, schrieb Mark Brown:
>> On Sun, Sep 08, 2013 at 05:35:56PM -0700, Guenter Roeck wrote:
>>
>> Please fix your mailer to word wrap within paragraphs, not doing this
>> makes your mail very hard to read.  It looks like your mailer has also
>> reflowed Daniel's mail.
>
> That's just wrong. Mail readers should wrap lines, not senders. And readers can do this since some decades.
>
> The reason is obvious: No sender knows the line width the receiver can display. So, for example, if the sender hard breaks lines every 80 chars, a reader with a device which just displays 60 characters at max. will see every second line with at most 20 characters. I assume you can guess how such does look like. Furthermore there are still a lot of people which do like to read mails with line length as long their display is possible to show, and hard breaking lines on the receiver side does make such impossible.
>
> So the correct behaviour is to not hard break lines on the sender side and leave that to the reader on the receiving side, as only the receiving side knows the line width.
>

I am using thunderbird and/or mutt. I don't think they reflow anything,
or at least the logged mail doesn't seem to have been reflowed (nor
does the text above).

As for what I write myself, I prefer to wrap manually, meaning automatic
insertion of newlines is turned off. Guess I can not do it right for everyone.

Guenter

Re: "Virtual" Interrupts -- Need help please

[Alexander Holler]

Am 09.09.2013 13:45, schrieb Guenter Roeck:
> On 09/09/2013 04:18 AM, Alexander Holler wrote:
>> Am 09.09.2013 13:02, schrieb Mark Brown:
>>> On Sun, Sep 08, 2013 at 05:35:56PM -0700, Guenter Roeck wrote:
>>>
>>> Please fix your mailer to word wrap within paragraphs, not doing this
>>> makes your mail very hard to read.  It looks like your mailer has also
>>> reflowed Daniel's mail.
>>
>> That's just wrong. Mail readers should wrap lines, not senders. And
>> readers can do this since some decades.
>>
>> The reason is obvious: No sender knows the line width the receiver can
>> display. So, for example, if the sender hard breaks lines every 80
>> chars, a reader with a device which just displays 60 characters at
>> max. will see every second line with at most 20 characters. I assume
>> you can guess how such does look like. Furthermore there are still a
>> lot of people which do like to read mails with line length as long
>> their display is possible to show, and hard breaking lines on the
>> receiver side does make such impossible.

Uups, sorry, I meant on the sender side here. ;)

>>
>> So the correct behaviour is to not hard break lines on the sender side
>> and leave that to the reader on the receiving side, as only the
>> receiving side knows the line width.
>>
>
> I am using thunderbird and/or mutt. I don't think they reflow anything,
> or at least the logged mail doesn't seem to have been reflowed (nor
> does the text above).
>
> As for what I write myself, I prefer to wrap manually, meaning automatic
> insertion of newlines is turned off. Guess I can not do it right for

That just the right thing to do.

> everyone.


Regards,

Alexander Holler

Re: "Virtual" Interrupts -- Need help please

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

On Mon, Sep 09, 2013 at 01:18:01PM +0200, Alexander Holler wrote:
> Am 09.09.2013 13:02, schrieb Mark Brown:

> >makes your mail very hard to read.  It looks like your mailer has also
> >reflowed Daniel's mail.

> That's just wrong. Mail readers should wrap lines, not senders. And
> readers can do this since some decades.

There's a specific way for senders to request that if it's desired, set
format=flowed in the MIME type to tell the recipient that the formatting
isn't important.

> The reason is obvious: No sender knows the line width the receiver
> can display. So, for example, if the sender hard breaks lines every
> 80 chars, a reader with a device which just displays 60 characters
> at max. will see every second line with at most 20 characters. I
> assume you can guess how such does look like. Furthermore there are
> still a lot of people which do like to read mails with line length
> as long their display is possible to show, and hard breaking lines
> on the receiver side does make such impossible.

> So the correct behaviour is to not hard break lines on the sender
> side and leave that to the reader on the receiving side, as only the
> receiving side knows the line width.

This doesn't work well with lots of content (like patches) commonly
handled in technical contexts - the line breaks actually mean something
and it's hard fo the mail client to figure out what is going on unless
someone tells it.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: "Virtual" Interrupts -- Need help please

[Alexander Holler]

Am 09.09.2013 15:45, schrieb Mark Brown:
> On Mon, Sep 09, 2013 at 01:18:01PM +0200, Alexander Holler wrote:
>> Am 09.09.2013 13:02, schrieb Mark Brown:
> 
>>> makes your mail very hard to read.  It looks like your mailer has also
>>> reflowed Daniel's mail.
> 
>> That's just wrong. Mail readers should wrap lines, not senders. And
>> readers can do this since some decades.
> 
> There's a specific way for senders to request that if it's desired, set
> format=flowed in the MIME type to tell the recipient that the formatting
> isn't important.
> 
>> The reason is obvious: No sender knows the line width the receiver
>> can display. So, for example, if the sender hard breaks lines every
>> 80 chars, a reader with a device which just displays 60 characters
>> at max. will see every second line with at most 20 characters. I
>> assume you can guess how such does look like. Furthermore there are
>> still a lot of people which do like to read mails with line length
>> as long their display is possible to show, and hard breaking lines
>> on the receiver side does make such impossible.
> 
>> So the correct behaviour is to not hard break lines on the sender
>> side and leave that to the reader on the receiving side, as only the
>> receiving side knows the line width.
> 
> This doesn't work well with lots of content (like patches) commonly
> handled in technical contexts - the line breaks actually mean something
> and it's hard fo the mail client to figure out what is going on unless
> someone tells it.

I wonder what all the hard line breaks you added to your mail do mean?

Hard line breaks in paragraphs, as you've requested, doesn't mean
anything. They just make eamils extremly ugly, e.g. your one is
displayed here with a whole lot of unused white space because I'm not
using a CGA screen. And people who do read your mail on a phone with
less than 80 or 75 chars will see it as even more ugly.

And imho it just works if hard line breaks are used where they belong
too, the code or to end paragraphs or otherwise where they have a
meaning, but not just always after 75 or 80 chars.

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "Virtual" Interrupts -- Need help please

[Daniel Santos]

On 09/09/2013 06:06 AM, Mark Brown wrote:
> On Sat, Sep 07, 2013 at 07:19:06PM -0500, Daniel Santos wrote:
>
>> So do i create an IRQ domain and then call generic_handle_irq() from
>> my URB complete() function? If so, which type of IRQ Domain is
>> appropriate for this? Unlike typical platform devices, these are
>> dynamically added and removed throughout the life of the kernel,
>> adding to the challenge.  So, if I understand correctly, my base IRQ
>> number needs to be dynamically generated.  How should I manage this?
> Unless you have a particular reason for using something else you should
> be using a linear domain - that's the default, it's very simple to work
> with.

Cool, thank you.

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

Hmm.  Well one shortcoming of my driver has been lacking a way to tell 
the spi protocol driver which IRQ to use for interrupts.  Yet another 
oversight on my behalf, as struct spi_device contains an int irq field 
just for this purpose. *sigh*  Well, at least that's one problem put to 
rest, but I should probably elaborate further on this.  Sorry in advance 
for the long response.

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.

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.

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.

So basically, it's a can of worms. :)  I wanted to get the interrupts 
working first so I could confront this once I had a fully working 
driver, but I suppose there's no time like the present.

So more specifically, on the EEPROM, I'm now storing the following 
(basically, everything in my struct board_config: 
https://github.com/daniel-santos/mcp2210-linux/blob/master/mcp2210.h#L483):
* an optional name for the device or pin (for GPIOs, this is the name 
they get exported with)
* an optional modalias for spi devices (defaults to "spidev") -- which 
of course I know mixes OS with hardware, but should be easily 
translatable for drivers for lessor operating systems.
* for spi devices, mode, min & max bitrate and timing requirements 
(various delay values)
* for gpios and the MCP2210's dedicated "interrupt counter" pin, an 
optional interrupt offset for producing IRQs
* for gpios, the interrupt edge type (the dedicated interrupt counter 
manages this elsewhere)
* how often it wants to have it's gpios and the "interrupt counter" 
polled (if applicable)
* and soon to be added: an interrupt offset for SPI devices that want to 
consume IRQs (but only those generated by this MCP2210 device)

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.

Thanks,
Daniel

Re: "Virtual" Interrupts -- Need help please

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3528 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: "Virtual" Interrupts -- Need help please

[Daniel Santos]

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