From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757691AbZBZW3A (ORCPT ); Thu, 26 Feb 2009 17:29:00 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753638AbZBZW2w (ORCPT ); Thu, 26 Feb 2009 17:28:52 -0500 Received: from mail-ew0-f177.google.com ([209.85.219.177]:64544 "EHLO mail-ew0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753307AbZBZW2v convert rfc822-to-8bit (ORCPT ); Thu, 26 Feb 2009 17:28:51 -0500 MIME-Version: 1.0 In-Reply-To: References: <20090218151132.476.81706.stgit@localhost.localdomain> <20090218183945.GA31797@suse.de> Date: Thu, 26 Feb 2009 23:28:48 +0100 Message-ID: Subject: Re: [PATCH] Export device_add_attributes() so drivers can use it. From: Kay Sievers To: Grant Likely Cc: Greg KH , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 20, 2009 at 16:28, Grant Likely wrote: > Thanks for the reply, it clarifies a lot.  It sounds like this really > should be documented (in Documentation/driver-model/device.txt?).  I'm > happy to add a blurb to that effect and send a patch, but I want to > make sure I really understand the model before I do so.  I've got a > couple more questions below: > > On Thu, Feb 19, 2009 at 4:08 PM, Kay Sievers wrote: > [...] >> If an attribute is not available at event time, nothing of this can >> ever work. If you look a the device a second later, you will see the >> proper looking files and values, and all the test programs will work, >> but it will always fail at device creation. > [...] >> That all might not be needed for your specific setup/driver/device and >> may work fine for your need. But we don't want to encourage anybody >> with another new API which creates the usual trouble we need to fix >> later. > > Fair enough > >> And we need to fix things like this all the time. > > Can you point me at a 'textbook' example of one of these fixups? Here are a few cases of broken atribute timing, a quick git search has found: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f7120a4f75168df3c02efacd10403a4ba0bcb29d http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8a89efd18aa15bb832778baa4e6eee3857ecada4 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b23dd6f8a718e5339de4f7d86ce76a078b5f771 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2e5f10e4f0a9649186d8a8c793822b2e0dae8373 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bfd129445f23c037d9a440ebfa4109e11c220301 Regarding the split of the driver device and the device to bind to: the platform stuff is kind of "special", because it is often used for devices/buses which can not be enumerated. With buses which need enumeration, it's pretty obvious that the enumeration creates their own devices, which then a driver can bind to, and where the driver creates its own driver instance for it. Like nobody would expect a network driver to add the netif properties directly to the pci device, and so on. Many platform devices are just static placeholders, and then it is not obvious that userspace still prefers another device instance while binding a driver, but in most cases it's worth the effort, because then all devices, regardless which bus is backing them, can be handled the same way with a "hotplug handler" like udev. Thanks, Kay