Re: [ALSA STABLE 3/3] a few more -- unregister platform device again if probe was unsuccessful

[Greg KH]

On Thu, Apr 13, 2006 at 06:05:50PM +0100, Russell King wrote:
> On Thu, Apr 13, 2006 at 06:17:49PM +0200, Rene Herman wrote:
> > Russell King wrote:
> > 
> > >On Thu, Apr 13, 2006 at 04:05:33PM +0200, Rene Herman wrote:
> > 
> > >>Not honouring/passing up probe() method error returns, not even -ENODEV, 
> > >>makes some sense for discoverable busses such as PCI where you at least 
> > >>have a driver independent bus_id sitting in /sys/devices/pci* that you 
> > >>can later echo into /sys/bus/pci/drivers/*/bind to make the driver bind 
> > >>to a device, but not much sense for the platform bus. Platform devices 
> > >>only "exist" (in /sys/devices/platform) due to the driver creating them 
> > >>itself and keeping them after failing a probe means that directory 
> > >>becomes an enumeration of the drivers we loaded, rather than a view of 
> > >>what's present in the system.
> > >
> > >Incorrect.  In some circumstances, they may be created by architecture
> > >support code, and might be created and destroyed dynamically by
> > >architecture support code.
> > 
> > Okay, thanks, that's relevant information. Please explain though what's 
> > incorrect about the fact that for these ISA devices on the plain old PC, 
> > with nothing other than the driver available to probe for them, just 
> > keeping them registered after failing a probe turns 
> > /sys/devices/platform into a view of "what drivers did we load".
> 
> If a driver for an ISA device only wants to register a device and driver
> if the hardware exists, it needs to handle behaviour itself and not force
> such behaviour on the upper layers (which is what you're arguing for.)
> 
> > >>The driver model crowd did not seem exceedingly interested in the 
> > >>problem though:
> > >>
> > >>http://marc.theaimsgroup.com/?l=linux-kernel&m=114417829014332&w=2
> > >
> > >Incorrect summary.  The ALSA use model of the driver model doesn't fit
> > >with the driver model use model.  It's not that we're not interested
> > >in it - it's that it's perverted to the way driver model folk intend
> > >the subsystem to work, and the way that platform devices are used on
> > >some architectures.
> > 
> > And I take it that interest is reflected in getting a grand total of 0 
> > comments from anyone on my own feeble attempts to suggest things in that 
> > thread such as the settable flag that would make the driver model pass 
> > up the error return from probe when set, or having an additional 
> > .discover method, or ..
> 
> I never commented on it because I'm not specifically a driver model
> person - I just happen to be one of the major users of platform devices,
> though I have put forward some changes to the platform driver model to
> facilitate getting rid of quite frankly some extremely poor and buggy
> driver code (and fixed up that crap code in the process.)
> 
> Greg is the maintainer of the driver model, and it's Greg who needs to
> comment on changes to the way it works.

Hm, I didn't see any patches sent to comment on :)

Anyway, no, no wierd flags to make the core pass stuff up on probe,
that's just a mess.

I still really don't understand why these ALSA drivers are so unlike any
of the zillion other drivers we have in the kernel that work just fine
today.  But to be fair, I've only been barely paying attention to this
thread.  Once the bad driver core patch was dropped from my tree, I've
been off doing other things...

> > M'kay. I believe there's one clean way out of this. We could add an "isa 
> > bus", where the _user_ would first need to setup the hardware from 
> > userspace by echoing values into sysfs. Say, something like:
> 
> Maybe this is the best solution for ISA devices - they do appear to
> have differing semantics at the probe level from platform devices.
> Maybe this "discovery" should be part of the bus matching method, prior
> to the driver probe method being called?  With an ISA bus type, you can
> certainly arrange for that to happen without changing existing driver
> model behaviour.

I know that Adam Belay had some work for ISA devices along these lines.
You might want to ask him, as he understands the issues involved here.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/