Messages in this thread | | | Date | Tue, 22 Mar 2005 12:00:08 +0100 | From | Pavel Machek <> | Subject | Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389 |
| |
Hi!
> > Yes, but it is needed. There are many drivers, and they look at > > numerical value of PMSG_*. I'm proceeding in steps. I hopefully killed > > all direct accesses to the constants, and will switch constants to > > something else... But that is going to be tommorow (need some sleep). > The patches are going to acquire correct PCI device sleep state for > suspend/resume. We discussed the issue several months ago. My plan is we > first introduce 'platform_pci_set_power_state', then merge the > 'platform_pci_choose_state' patch after Pavel's pm_message_t conversion > finished. Maybe Len mislead my comments. > > Anyway for the callback, my intend is platform_pci_choose_state accept > the pm_message_t parameter, and it return an 'int', since platform > method possibly failed and then pci_choose_state translate the return > value to pci_power_t.
You can't just retype around like that. You may want it take pci_power_t * as an argument, and then return 0/-ENODEV or something like that. But you can't retype between int and pm_message_t...
Plus that function should have a documentation somewhere!
> > Could you just revert those two patches? First one is very > > wrong. Second one might be fixed, but... See comments below. > I think the platform_pci_set_power_state should be ok, did you see it > causes oops?
No its just ugly and uses __force in "creative" way. That one can be recovered. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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/
| |