Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751134AbWEFXQ2 (ORCPT ); Sat, 6 May 2006 19:16:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751136AbWEFXQ2 (ORCPT ); Sat, 6 May 2006 19:16:28 -0400 Received: from khc.piap.pl ([195.187.100.11]:58119 "EHLO khc.piap.pl") by vger.kernel.org with ESMTP id S1751134AbWEFXQ1 (ORCPT ); Sat, 6 May 2006 19:16:27 -0400 To: "Jon Smirl" Cc: "Dave Airlie" , "Greg KH" , "Ian Romanick" , "Dave Airlie" , "Arjan van de Ven" , linux-kernel@vger.kernel.org Subject: Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access References: <20060505210614.GB7365@kroah.com> <9e4733910605051415o48fddbafpf0f8b096f971e482@mail.gmail.com> <20060505222738.GA8985@kroah.com> <9e4733910605051705j755ad61dm1c07c66c2c24c525@mail.gmail.com> <21d7e9970605051857l4415a04ai7d1b1f886bb01cee@mail.gmail.com> <9e4733910605052039n7d2debbse0fd07e0d1d059fb@mail.gmail.com> <9e4733910605060608l57c1a215pa300c326ef1eef4b@mail.gmail.com> <9e4733910605061124u6b1c4b88nd84faa914c72521f@mail.gmail.com> From: Krzysztof Halasa Date: Sun, 07 May 2006 01:16:25 +0200 In-Reply-To: <9e4733910605061124u6b1c4b88nd84faa914c72521f@mail.gmail.com> (Jon Smirl's message of "Sat, 6 May 2006 14:24:35 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1491 Lines: 36 "Jon Smirl" writes: >> The card in question _has_ a driver. I, for example, just need a way >> to write EEPROM data to it (vendor/device ID etc). The card has to be >> selected by PCI bus and slot (device) number, not by device class >> and/or IDs, because it can contain garbage and/or some generic IDs >> with generic device class. > > Hardware like you describe violates the PCI spec What exactly does it violate? > and it should not be > expected that Linux will support it in the general case. It sounds > like this is some kind of prototype hardware. No. Just one of the final steps of production, or in-system update. > I would probably handle this by writing an unbound device driver that > exposes a sysfs file for bus:slot. When you write the bus:slot to the > file it would then bind to the appropriate hardware and enable it. The > newly bound driver would support the driver firmware loader interface > as a means of getting your data in. What is also needed is that end users perform this task from time to time. They generally don't want to have to compile the kernel :-) You know, even now it can be done (entirely in userspace), and only enabling the device seems a bit dangerous. -- Krzysztof Halasa - 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/