"Virtual" Interrupts -- Need help please
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.
Quoted 4 lines · 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.
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.
Quoted 4 lines
So do i create an IRQ domain and then call
generic_handle_irq()from my URBcomplete()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.
Quoted 2 lines
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
Quoted 15 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines · Guenter Roeck
Quoted 4 lines · 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.
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.
Quoted 10 lines
It is modeled as mfd driver, which I think you might want to consider as well.
Quoted 4 lines
So do i create an IRQ domain and then call
generic_handle_irq()from my URBcomplete()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/mfdsolving the same problem, ie using irq domains to pass interrupts to client drivers. Look forirq_domain_add_simple().drivers/mfd/tc3589x.cseems 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!
Quoted 7 lines
Quoted 3 lines
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
Quoted 17 lines · Daniel Santos
Quoted 8 lines · Guenter Roeck
Quoted 4 lines · 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.
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.
Quoted 5 lines
It is modeled as mfd driver, which I think you might want to consider as well.
Quoted 2 lines
So do i create an IRQ domain and then call
generic_handle_irq()from my URBcomplete()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?
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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/mfdsolving the same problem, ie using irq domains to pass interrupts to client drivers. Look forirq_domain_add_simple().drivers/mfd/tc3589x.cseems 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 :).
Quoted 10 lines
Quoted 7 lines
Quoted 3 lines
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.
Quoted 2 lines
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
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.
Quoted 10 lines · Daniel Santos
Quoted 5 lines
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.
Am 09.09.2013 13:02, schrieb Mark Brown:
Quoted 5 lines · Guenter Roeck
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
Quoted 7 lines · Alexander Holler
Am 09.09.2013 13:02, schrieb Mark Brown:
Quoted 5 lines · Guenter Roeck
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.
Quoted 6 lines
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
Am 09.09.2013 13:45, schrieb Guenter Roeck:
Quoted 11 lines · Alexander Holler
Quoted 10 lines
Am 09.09.2013 13:02, schrieb Mark Brown:
Quoted 5 lines · Guenter Roeck
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.
Quoted 8 lines
Quoted 8 lines
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. ;)
Quoted 6 lines
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 1 line
everyone.
Regards,
Alexander Holler
Quoted 7 lines · Alexander Holler
Am 09.09.2013 13:02, schrieb Mark Brown:
Quoted 2 lines
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.
Quoted 9 lines
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.
Quoted 3 lines
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.
Am 09.09.2013 15:45, schrieb Mark Brown:
Quoted 22 lines · Alexander Holler
Quoted 7 lines
Am 09.09.2013 13:02, schrieb Mark Brown:
Quoted 2 lines
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.
Quoted 8 lines
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.
Quoted 8 lines
Quoted 3 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Daniel Santos
So do i create an IRQ domain and then call
generic_handle_irq()from my URBcomplete()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.
Quoted 4 lines
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?
Quoted 11 lines · Mark Brown
Quoted 6 lines · Daniel Santos
So do i create an IRQ domain and then call
generic_handle_irq()from my URBcomplete()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.
Quoted 5 lines
Quoted 4 lines
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
Quoted 10 lines · Daniel Santos
Quoted 8 lines · Mark Brown
Quoted 4 lines · Daniel Santos
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?
Quoted 12 lines
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.
Quoted 8 lines
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.
Quoted 7 lines
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 structdevice_nodeand 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.
Quoted 5 lines
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.
Quoted 13 lines · Mark Brown
Quoted 4 lines · Daniel Santos
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
Quoted 8 lines
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.
Quoted 7 lines
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.
Quoted 10 lines
Quoted 8 lines
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.
Quoted 7 lines
Quoted 7 lines
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 structdevice_nodeand didn't not accept NULL. This made me think that I was missing something.
Quoted 5 lines
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. :)
Quoted 7 lines
Quoted 5 lines
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. :)