On Mon, Feb 28, 2005 at 07:05:54PM -0500, Adam Belay wrote:
> On Fri, 2005-02-25 at 15:41 -0800, Greg KH wrote:
> > On Thu, Feb 10, 2005 at 04:37:03PM -0500, Adam Belay wrote:
> > > On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
> > > > On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay
On Mon, Feb 28, 2005 at 07:05:54PM -0500, Adam Belay wrote:
On Fri, 2005-02-25 at 15:41 -0800, Greg KH wrote:
On Thu, Feb 10, 2005 at 04:37:03PM -0500, Adam Belay wrote:
On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
On Fri, 2005-02-25 at 15:41 -0800, Greg KH wrote:
> On Thu, Feb 10, 2005 at 04:37:03PM -0500, Adam Belay wrote:
> > On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
> > > On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > > > > I think the issue that Al raises about drivers
On Fri, 2005-02-25 at 15:41 -0800, Greg KH wrote:
On Thu, Feb 10, 2005 at 04:37:03PM -0500, Adam Belay wrote:
On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
I think the issue that Al raises about drivers grabbing
On Thu, Feb 10, 2005 at 04:37:03PM -0500, Adam Belay wrote:
> On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
> > On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > > > I think the issue that Al raises about drivers grabbing devices, and
> > > > then trying to unbind them might
On Thu, Feb 10, 2005 at 04:37:03PM -0500, Adam Belay wrote:
On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
I think the issue that Al raises about drivers grabbing devices, and
then trying to unbind them might be a real
On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
> On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > > I think the issue that Al raises about drivers grabbing devices, and
> > > then trying to unbind them might be a real problem.
> >
> > I agree. Do you think registering
On Thu, 2005-02-10 at 13:46 -0500, Dmitry Torokhov wrote:
> On Thu, 10 Feb 2005 10:33:38 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > >
> > > The second "*match" function in "struct device_driver" gives the driver
> > > a chance to
On Thu, 2005-02-10 at 10:12 -0800, Greg KH wrote:
> On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > On Thu, 2005-02-10 at 00:41 -0800, Greg KH wrote:
> > > On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote:
> > > > Hi,
> > > >
> > > > This patch adds initial support for
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > I think the issue that Al raises about drivers grabbing devices, and
> > then trying to unbind them might be a real problem.
>
> I agree. Do you think registering every in-kernel driver before probing
> hardware would solve this
On Thu, 10 Feb 2005 10:33:38 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> >
> > The second "*match" function in "struct device_driver" gives the driver
> > a chance to evaluate it's ability of controlling the device and solves a
> > few
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
>
> The second "*match" function in "struct device_driver" gives the driver
> a chance to evaluate it's ability of controlling the device and solves a
> few problems with the current implementation. (ex. it's not possible to
> detect
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> On Thu, 2005-02-10 at 00:41 -0800, Greg KH wrote:
> > On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote:
> > > Hi,
> > >
> > > This patch adds initial support for driver matching priorities to the
> > > driver model. It is
On Thu, 10 Feb 2005 12:18:37 -0500, Adam Belay <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-02-10 at 00:41 -0800, Greg KH wrote:
> > On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote:
> > > Hi,
> > >
> > > This patch adds initial support for driver matching priorities to the
> > > driver
On Thu, 2005-02-10 at 00:41 -0800, Greg KH wrote:
> On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote:
> > Hi,
> >
> > This patch adds initial support for driver matching priorities to the
> > driver model. It is needed for my work on converting the pci bridge
> > driver to use "struct
On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote:
> Hi,
>
> This patch adds initial support for driver matching priorities to the
> driver model. It is needed for my work on converting the pci bridge
> driver to use "struct device_driver". It may also be helpful for driver
> with more
On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote:
Hi,
This patch adds initial support for driver matching priorities to the
driver model. It is needed for my work on converting the pci bridge
driver to use struct device_driver. It may also be helpful for driver
with more complex
On Thu, 2005-02-10 at 00:41 -0800, Greg KH wrote:
On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote:
Hi,
This patch adds initial support for driver matching priorities to the
driver model. It is needed for my work on converting the pci bridge
driver to use struct
On Thu, 10 Feb 2005 12:18:37 -0500, Adam Belay [EMAIL PROTECTED] wrote:
On Thu, 2005-02-10 at 00:41 -0800, Greg KH wrote:
On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote:
Hi,
This patch adds initial support for driver matching priorities to the
driver model. It is needed
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
On Thu, 2005-02-10 at 00:41 -0800, Greg KH wrote:
On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote:
Hi,
This patch adds initial support for driver matching priorities to the
driver model. It is needed for my
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
The second *match function in struct device_driver gives the driver
a chance to evaluate it's ability of controlling the device and solves a
few problems with the current implementation. (ex. it's not possible to
detect ISA Modems
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
I think the issue that Al raises about drivers grabbing devices, and
then trying to unbind them might be a real problem.
I agree. Do you think registering every in-kernel driver before probing
hardware would solve this problem?
On Thu, 10 Feb 2005 10:33:38 -0800, Greg KH [EMAIL PROTECTED] wrote:
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
The second *match function in struct device_driver gives the driver
a chance to evaluate it's ability of controlling the device and solves a
few problems with
On Thu, 2005-02-10 at 10:12 -0800, Greg KH wrote:
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
On Thu, 2005-02-10 at 00:41 -0800, Greg KH wrote:
On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote:
Hi,
This patch adds initial support for driver matching
On Thu, 2005-02-10 at 13:46 -0500, Dmitry Torokhov wrote:
On Thu, 10 Feb 2005 10:33:38 -0800, Greg KH [EMAIL PROTECTED] wrote:
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
The second *match function in struct device_driver gives the driver
a chance to evaluate it's
On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
I think the issue that Al raises about drivers grabbing devices, and
then trying to unbind them might be a real problem.
I agree. Do you think registering every in-kernel
On Friday 28 January 2005 19:11, Al Viro wrote:
> On Fri, Jan 28, 2005 at 06:23:26PM -0500, Dmitry Torokhov wrote:
> > On Friday 28 JanuarDy 2005 17:30, Adam Belay wrote:
> > > Of course this patch is not going to be effective alone. We also need
> > > to change the init order. If a driver is
On Fri, Jan 28, 2005 at 06:23:26PM -0500, Dmitry Torokhov wrote:
> On Friday 28 January 2005 17:30, Adam Belay wrote:
> > Of course this patch is not going to be effective alone. We also need
> > to change the init order. If a driver is registered early but isn't the
> > best available, it will
On Fri, 2005-01-28 at 18:51 -0500, Dmitry Torokhov wrote:
> If generic driver binds to a device that is has no idea how to drive
> _at all_ then I will argue that the generic driver is broken. It should
> not bind to begin with.
>
In the case of pci bridges, sometimes we can't really tell if we
On Friday 28 January 2005 18:33, Adam Belay wrote:
> On Fri, 2005-01-28 at 18:23 -0500, Dmitry Torokhov wrote:
> > On Friday 28 January 2005 17:30, Adam Belay wrote:
> > > Of course this patch is not going to be effective alone. We also need
> > > to change the init order. If a driver is
On Fri, 2005-01-28 at 18:23 -0500, Dmitry Torokhov wrote:
> On Friday 28 January 2005 17:30, Adam Belay wrote:
> > Of course this patch is not going to be effective alone. We also need
> > to change the init order. If a driver is registered early but isn't the
> > best available, it will be
On Friday 28 January 2005 17:30, Adam Belay wrote:
> Of course this patch is not going to be effective alone. ÂWe also need
> to change the init order. ÂIf a driver is registered early but isn't the
> best available, it will be bound to the device prematurely. ÂThis would
> be a problem for carbus
Hi,
This patch adds initial support for driver matching priorities to the
driver model. It is needed for my work on converting the pci bridge
driver to use "struct device_driver". It may also be helpful for driver
with more complex (or long id lists as I've seen in many cases) matching
Hi,
This patch adds initial support for driver matching priorities to the
driver model. It is needed for my work on converting the pci bridge
driver to use struct device_driver. It may also be helpful for driver
with more complex (or long id lists as I've seen in many cases) matching
criteria.
On Friday 28 January 2005 17:30, Adam Belay wrote:
Of course this patch is not going to be effective alone. We also need
to change the init order. If a driver is registered early but isn't the
best available, it will be bound to the device prematurely. This would
be a problem for carbus
On Fri, 2005-01-28 at 18:23 -0500, Dmitry Torokhov wrote:
On Friday 28 January 2005 17:30, Adam Belay wrote:
Of course this patch is not going to be effective alone. We also need
to change the init order. If a driver is registered early but isn't the
best available, it will be bound to
On Friday 28 January 2005 18:33, Adam Belay wrote:
On Fri, 2005-01-28 at 18:23 -0500, Dmitry Torokhov wrote:
On Friday 28 January 2005 17:30, Adam Belay wrote:
Of course this patch is not going to be effective alone. We also need
to change the init order. If a driver is registered early
On Fri, 2005-01-28 at 18:51 -0500, Dmitry Torokhov wrote:
If generic driver binds to a device that is has no idea how to drive
_at all_ then I will argue that the generic driver is broken. It should
not bind to begin with.
In the case of pci bridges, sometimes we can't really tell if we can
On Fri, Jan 28, 2005 at 06:23:26PM -0500, Dmitry Torokhov wrote:
On Friday 28 January 2005 17:30, Adam Belay wrote:
Of course this patch is not going to be effective alone. We also need
to change the init order. If a driver is registered early but isn't the
best available, it will be
On Friday 28 January 2005 19:11, Al Viro wrote:
On Fri, Jan 28, 2005 at 06:23:26PM -0500, Dmitry Torokhov wrote:
On Friday 28 JanuarDy 2005 17:30, Adam Belay wrote:
Of course this patch is not going to be effective alone. We also need
to change the init order. If a driver is registered
40 matches
Mail list logo
