From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262529AbVAESMi (ORCPT ); Wed, 5 Jan 2005 13:12:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262531AbVAESLw (ORCPT ); Wed, 5 Jan 2005 13:11:52 -0500 Received: from mail.suse.de ([195.135.220.2]:40599 "EHLO Cantor.suse.de") by vger.kernel.org with ESMTP id S262529AbVAESIZ (ORCPT ); Wed, 5 Jan 2005 13:08:25 -0500 Date: Wed, 05 Jan 2005 17:26:04 +0100 Message-ID: From: Takashi Iwai To: Pavel Machek Cc: kernel list , Linux-pm mailing list , Andrew Morton Subject: Re: Power management of old ISA devices (Re: mark older power managment as deprecated) In-Reply-To: <20050104202245.GB7924@elf.ucw.cz> References: <20050104124659.GA22256@elf.ucw.cz> <20050104202245.GB7924@elf.ucw.cz> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 15) (Security Through Obscurity) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At Tue, 4 Jan 2005 21:22:45 +0100, Pavel Machek wrote: > > Hi! > > > > What about this patch? It marks old power managemnt as obsolete (and > > > also adds some sparse-style type checking; typedefs were already there > > > so why not use them?). I think it should go in, so that we can get a > > > rid of old power managment infrastructure post-2.6.11. > > > > ALSA core part still includes pm_register/unregister() for old > > (non-PnP) ISA devices. > > > > What is the proper way to register/unregister PM hooks for such > > devices? > > How are PnP ISA devices handled? Sorry, correction: pm_register() is used for both ISA PnP and non-PnP devices. > Right solution for ISA devices is probably to create an ISA bus in > driver model, and hook such devices there.... Yep. > Alternatively, you might just hang them onto platform bus, in similar > way i8042 uses... This looks easier to implement as a temporary solution until ISA bus is implemented. We know how many instances are to be initiailized in advance, so each driver object can have a unique name. > Imagine this configuration: > > cpu -- PCI #1 -- PCI to PCI bridge -- PCI #2 -- PCI to ISA bridge -- sound card #1 on 0x100 > \- PCI to PCI bridge -- PCI #3 -- PCI to ISA bridge -- sound card #2 on 0x100 > > ...would you say that's supported? If yes you'd need to create ISA > buses and do it properly, otherwise hooking to platform bus is > probably acceptable. Well, I don't think this can be problematic on ISA soundcards with platform_device. Anyway, I'll try to implement platform_device at first as a test... Thanks! Takashi