Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965475AbbEMPxD (ORCPT ); Wed, 13 May 2015 11:53:03 -0400 Received: from mail-la0-f51.google.com ([209.85.215.51]:34750 "EHLO mail-la0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964942AbbEMPw6 (ORCPT ); Wed, 13 May 2015 11:52:58 -0400 MIME-Version: 1.0 In-Reply-To: <20150513153740.GC11677@kroah.com> References: <1431462804-30467-1-git-send-email-maxime.ripard@free-electrons.com> <20150513112604.GI3066@sirena.org.uk> <20150513153740.GC11677@kroah.com> From: Michal Suchanek Date: Wed, 13 May 2015 17:52:16 +0200 Message-ID: Subject: Re: [PATCH] spi: Force the registration of the spidev devices To: Greg Kroah-Hartman Cc: Mark Brown , Maxime Ripard , Linux Kernel Mailing List , Hans de Goede , linux-spi , Martin Sperl Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2070 Lines: 45 On 13 May 2015 at 17:37, Greg Kroah-Hartman wrote: > On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote: >> On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote: >> >> > While this is nicer than the DT solution because of its accurate hardware >> > representation, it's still not perfect because you might not have access to the >> > DT, or you might be driving a completely generic device (such as a >> > microcontroller) that might be used for something else in a different >> > context/board. >> >> Greg, you're copied on this because this seems to be a generic problem >> that should perhaps be solved at a driver model level - having a way to >> bind userspace access to devices that we don't otherwise have a driver >> for. The subsystem could specify the UIO driver to use when no other >> driver is available. > > That doesn't really work. I've been talking to the ACPI people about > this, and the problem is "don't otherwise have a driver for" is an > impossible thing to prove, as you never know when a driver is going to > be loaded from userspace. Yes, exactly. That's why binding spidev in addition to regular drivers or have spidev bind always and get unbound when another driver tries to bind the CS is preferable. The latter is pretty much specifying an UIO driver to use when no other driver is available in the light of the fact that 'is available' might change over time. You can prove that a driver is not available right now. > > You can easily bind drivers to devices today from userspace, why not > just use the built-in functionality you have today if you "know" that > there is no driver for this hardware. > And what exactly do you bind the driver to when there is no device created with the built-in functionality you have today? Thanks Michal -- 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/