On Wed, Nov 12, 2008 at 10:37 AM, ron minnich rminnich@gmail.com wrote:
On Wed, Nov 12, 2008 at 8:25 AM, Myles Watson mylesgw@gmail.com wrote:
I forgot the rule. I'm down the path of creating static devices for each PNP device. :(
if you make a dts per PNP device, the dtc will do that for you.
don't go too far without a sanity test with me or you will go insane :-)
Which has absolutely no knowledge of the dts. We could, however, create
an
initialization function that copies all of the information from the dts
into
the specific device. It just has to be done before resource allocation, which means that pnp_enable_devices needs to be split and renamed.
as marc pointed out, the phase3_chip_setup_dev does have dts knowledge.
I'm seeing the problem more now. As you have pointed out, the pnp stuff has no good connection to anything else, and this needs to be fixed.
I have a generic pnp dts which has members io,irq,io2,irq2,drq
can I see it?
Shield your eyes from the ugliness :)
This patch creates a superio/winbond/*/pnp.dts which is generic enough that it probably should be extended if needed and moved to device/pnp.dts or superio/pnp.dts or something like that.
I wish that I could put pnp@W83267HF_KBC and have the define come out in the statictree.c, but it doesn't like that, so I have to duplicate the information.
Right now it does pnp@5 as a static child of ioport@2e. I have to fix that up in the code by assigning the pnp device's port from its parents. That could move.
In the pnp code, I changed it so that it doesn't allocate a pnp device if it doesn't find it, because that would mean that all the values were wrong for the ports, irqs, etc.
Signed-off-by: Myles Watson mylesgw@gmail.com
I signed it off in case I'm hit by a truck, for Uwe, but it shouldn't be committed.
Thanks, Myles