On Thursday 13 March 2008 06:04:08 am Thomas Renninger wrote: > On Wed, 2008-03-12 at 13:45 -0400, Len Brown wrote: > > On Wednesday 12 March 2008, Dave Jones wrote: > ... > > Thomas worked on a patch to make resource allocation dynamic and do away > > with these limits. Unfortunately it was rather large and it wasn't in > > time for the 2.6.25-rc1 window. > > I had the problem that I could not test on isa systems. > Rene Herman helped here a lot. > There are still open issues, last state was (comment from Rene): > ------------------------ > No. Please note we're talking about ISAPnP, not PnPBIOS. No BIOS > involved at all. > > Driver (sound/isa/cs423x/cs4236.c) furthermore does not use anything but > the PnP layer itself. Start at snd_cs423x_pnpc_detect, which is the > pnp .probe() method. > > I'll look into providing a more extensive answer and/or test whatever > comes in later. > ------------------------- > I can also look at this, any hints until then are appreciated. > > I also expect Bjorn was bound to other bugs and pushing things in a rush > is not good thing anyway. > At the end I asked for a macro problem I only had a rather ugly > solution, didn't get an answer (IIRC I also added a compile bug in my > suggestions) and things got stuck... > > Do you want me to rework the patches, lay out where I see problems and > give it another try to get this into -mm? I'm sorry that I haven't responded to this. I have some reservations, but I wanted to try out some alternate ideas before just being a nay- sayer because usually my grand ideas turn out to have fatal flaws. My current grand but untested idea is that struct pnp_resource_table is too exposed and should be better abstracted, even inside the PNP subsystem. Since PNP is supposed to be a way to discover platform devices, I'm looking at the platform device interfaces for ideas. Whatever we do, I think it has to be done incrementally to make it reviewable and bisectable. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
