On Thu, Feb 14, 2008 at 01:11:42PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 14 February 2008, Andreas Jaeger wrote:
> > Greg KH <[EMAIL PROTECTED]> writes:
> >
> > > How does the patch below look? I didn't want to remove the whole config
> > > option, as there is more to the logic
On Thu, Feb 14, 2008 at 01:11:42PM +0100, Bartlomiej Zolnierkiewicz wrote:
On Thursday 14 February 2008, Andreas Jaeger wrote:
Greg KH [EMAIL PROTECTED] writes:
How does the patch below look? I didn't want to remove the whole config
option, as there is more to the logic than just the
On Fri, Feb 15, 2008 at 10:28:22AM -0800, Greg KH wrote:
> That would be nice. Muli, want to make a patch for this?
Sure, I'll put something together.
Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Fri, Feb 15, 2008 at 10:28:22AM -0800, Greg KH wrote:
That would be nice. Muli, want to make a patch for this?
Sure, I'll put something together.
Cheers,
Muli
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Fri, Feb 15, 2008 at 04:31:40PM +0100, Sam Ravnborg wrote:
> On Fri, Feb 15, 2008 at 07:20:08AM -0800, Greg KH wrote:
> > On Fri, Feb 15, 2008 at 09:48:27AM +0200, Muli Ben-Yehuda wrote:
> > > In conclusion, our usage doesn't seem lika a good fit for the probe
> > > approach, although it could
2008/2/15, Sam Ravnborg <[EMAIL PROTECTED]>:
> On Fri, Feb 15, 2008 at 07:20:08AM -0800, Greg KH wrote:
> > On Fri, Feb 15, 2008 at 09:48:27AM +0200, Muli Ben-Yehuda wrote:
> > > In conclusion, our usage doesn't seem lika a good fit for the probe
> > > approach, although it could probably
On Fri, Feb 15, 2008 at 07:20:08AM -0800, Greg KH wrote:
> On Fri, Feb 15, 2008 at 09:48:27AM +0200, Muli Ben-Yehuda wrote:
> > In conclusion, our usage doesn't seem lika a good fit for the probe
> > approach, although it could probably converted provided we got the
> > ordering right with regards
On Fri, Feb 15, 2008 at 09:48:27AM +0200, Muli Ben-Yehuda wrote:
> In conclusion, our usage doesn't seem lika a good fit for the probe
> approach, although it could probably converted provided we got the
> ordering right with regards to regular PCI device
> initialization. Doesn't seem to be worth
On Fri, Feb 15, 2008 at 09:48:27AM +0200, Muli Ben-Yehuda wrote:
In conclusion, our usage doesn't seem lika a good fit for the probe
approach, although it could probably converted provided we got the
ordering right with regards to regular PCI device
initialization. Doesn't seem to be worth the
On Fri, Feb 15, 2008 at 07:20:08AM -0800, Greg KH wrote:
On Fri, Feb 15, 2008 at 09:48:27AM +0200, Muli Ben-Yehuda wrote:
In conclusion, our usage doesn't seem lika a good fit for the probe
approach, although it could probably converted provided we got the
ordering right with regards to
2008/2/15, Sam Ravnborg [EMAIL PROTECTED]:
On Fri, Feb 15, 2008 at 07:20:08AM -0800, Greg KH wrote:
On Fri, Feb 15, 2008 at 09:48:27AM +0200, Muli Ben-Yehuda wrote:
In conclusion, our usage doesn't seem lika a good fit for the probe
approach, although it could probably converted
On Fri, Feb 15, 2008 at 04:31:40PM +0100, Sam Ravnborg wrote:
On Fri, Feb 15, 2008 at 07:20:08AM -0800, Greg KH wrote:
On Fri, Feb 15, 2008 at 09:48:27AM +0200, Muli Ben-Yehuda wrote:
In conclusion, our usage doesn't seem lika a good fit for the probe
approach, although it could probably
On Thu, Feb 14, 2008 at 11:17:03PM -0800, Greg KH wrote:
> Hm, that's wierd. I thought I got something, until I realized that
> you are doing a lot of logic before you ever even determine that
> your hardware is present in the system. Why are you calling
> calgary_locate_bbars() and doing all
On Wed, Feb 13, 2008 at 10:14:59AM -0800, Greg KH wrote:
> On Wed, Feb 13, 2008 at 07:47:11PM +0200, Muli Ben-Yehuda wrote:
> > On Wed, Feb 13, 2008 at 09:32:03AM -0800, Greg KH wrote:
> >
> > > Is there some reason you aren't using the "real" PCI driver api here
> > > and registering a pci
On Thu, Feb 14, 2008 at 01:11:42PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 14 February 2008, Andreas Jaeger wrote:
> > Greg KH <[EMAIL PROTECTED]> writes:
> >
> > > How does the patch below look? I didn't want to remove the whole config
> > > option, as there is more to the logic
From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Subject: [PATCH] ide: mark "ide=reverse" option as obsolete
- it is valid only if "Probe IDE PCI devices in the PCI bus order
(DEPRECATED)" config option is used
- Greg needs to remove pci_get_device_reverse() for PCI core changes
Cc:
On Thursday 14 February 2008, Andreas Jaeger wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>
> > How does the patch below look? I didn't want to remove the whole config
> > option, as there is more to the logic than just the "reverse order"
> > stuff there.
>
> I think you miss Documentation -
On Thursday 14 February 2008, Andreas Jaeger wrote:
Greg KH [EMAIL PROTECTED] writes:
How does the patch below look? I didn't want to remove the whole config
option, as there is more to the logic than just the reverse order
stuff there.
I think you miss Documentation - it's mentioned
From: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Subject: [PATCH] ide: mark ide=reverse option as obsolete
- it is valid only if Probe IDE PCI devices in the PCI bus order
(DEPRECATED) config option is used
- Greg needs to remove pci_get_device_reverse() for PCI core changes
Cc: Greg
On Thu, Feb 14, 2008 at 01:11:42PM +0100, Bartlomiej Zolnierkiewicz wrote:
On Thursday 14 February 2008, Andreas Jaeger wrote:
Greg KH [EMAIL PROTECTED] writes:
How does the patch below look? I didn't want to remove the whole config
option, as there is more to the logic than just the
On Wed, Feb 13, 2008 at 10:14:59AM -0800, Greg KH wrote:
On Wed, Feb 13, 2008 at 07:47:11PM +0200, Muli Ben-Yehuda wrote:
On Wed, Feb 13, 2008 at 09:32:03AM -0800, Greg KH wrote:
Is there some reason you aren't using the real PCI driver api here
and registering a pci driver for these
On Thu, Feb 14, 2008 at 11:17:03PM -0800, Greg KH wrote:
Hm, that's wierd. I thought I got something, until I realized that
you are doing a lot of logic before you ever even determine that
your hardware is present in the system. Why are you calling
calgary_locate_bbars() and doing all of
Greg KH <[EMAIL PROTECTED]> writes:
> How does the patch below look? I didn't want to remove the whole config
> option, as there is more to the logic than just the "reverse order"
> stuff there.
I think you miss Documentation - it's mentioned in ide.txt and
kernel-parameters.txt,
Andreas
--
On Thu, Feb 14, 2008 at 01:02:55AM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 14 February 2008, Greg KH wrote:
> > On Wed, Feb 13, 2008 at 11:20:36PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > > On Wednesday 13 February 2008, Greg KH wrote:
> > > > On Wed, Feb 13, 2008 at 09:28:24AM
On Thursday 14 February 2008, Greg KH wrote:
> On Wed, Feb 13, 2008 at 11:20:36PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 13 February 2008, Greg KH wrote:
> > > On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg KH wrote:
> > > > On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej
On Wed, Feb 13, 2008 at 11:20:36PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 13 February 2008, Greg KH wrote:
> > On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg KH wrote:
> > > On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > > > On Wednesday 13 February
On Wednesday 13 February 2008, Greg KH wrote:
> On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg KH wrote:
> > On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > > On Wednesday 13 February 2008, Greg KH wrote:
> > > > On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox
On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg KH wrote:
> On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 13 February 2008, Greg KH wrote:
> > > On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote:
> > > > > Why does the calgary driver need this?
On Wed, Feb 13, 2008 at 07:47:11PM +0200, Muli Ben-Yehuda wrote:
> On Wed, Feb 13, 2008 at 09:32:03AM -0800, Greg KH wrote:
>
> > Is there some reason you aren't using the "real" PCI driver api here
> > and registering a pci driver for these devices? That would take the
> > whole "loop over all
On Wed, Feb 13, 2008 at 09:32:03AM -0800, Greg KH wrote:
> Is there some reason you aren't using the "real" PCI driver api here
> and registering a pci driver for these devices? That would take the
> whole "loop over all pci devices" logic out of the code entirely.
I recall we had a reason, but
On Wed, Feb 13, 2008 at 11:32:26AM +0200, Muli Ben-Yehuda wrote:
> On Tue, Feb 12, 2008 at 04:16:38PM -0800, Greg KH wrote:
>
> > Why does the calgary driver need this? Can we just use
> > pci_get_device() instead? Why do you need to walk the device list
> > backwards? Do you get false
On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 13 February 2008, Greg KH wrote:
> > On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote:
> > > > Why does the calgary driver need this? Can we just use pci_get_device()
> > > > instead? Why do you
On Wednesday 13 February 2008, Greg KH wrote:
> On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote:
> > > Why does the calgary driver need this? Can we just use pci_get_device()
> > > instead? Why do you need to walk the device list backwards? Do you get
> > > false positives going
On Tue, Feb 12, 2008 at 04:16:38PM -0800, Greg KH wrote:
> Why does the calgary driver need this? Can we just use
> pci_get_device() instead? Why do you need to walk the device list
> backwards? Do you get false positives going forward?
It's not strictly needed, we used it for symmetry. Feel
On Tue, Feb 12, 2008 at 04:16:38PM -0800, Greg KH wrote:
Why does the calgary driver need this? Can we just use
pci_get_device() instead? Why do you need to walk the device list
backwards? Do you get false positives going forward?
It's not strictly needed, we used it for symmetry. Feel
On Wednesday 13 February 2008, Greg KH wrote:
On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote:
Why does the calgary driver need this? Can we just use pci_get_device()
instead? Why do you need to walk the device list backwards? Do you get
false positives going forward?
It
On Wed, Feb 13, 2008 at 09:32:03AM -0800, Greg KH wrote:
Is there some reason you aren't using the real PCI driver api here
and registering a pci driver for these devices? That would take the
whole loop over all pci devices logic out of the code entirely.
I recall we had a reason, but I no
On Wed, Feb 13, 2008 at 11:32:26AM +0200, Muli Ben-Yehuda wrote:
On Tue, Feb 12, 2008 at 04:16:38PM -0800, Greg KH wrote:
Why does the calgary driver need this? Can we just use
pci_get_device() instead? Why do you need to walk the device list
backwards? Do you get false positives going
On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
On Wednesday 13 February 2008, Greg KH wrote:
On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote:
Why does the calgary driver need this? Can we just use pci_get_device()
instead? Why do you need to walk
On Wed, Feb 13, 2008 at 07:47:11PM +0200, Muli Ben-Yehuda wrote:
On Wed, Feb 13, 2008 at 09:32:03AM -0800, Greg KH wrote:
Is there some reason you aren't using the real PCI driver api here
and registering a pci driver for these devices? That would take the
whole loop over all pci devices
On Wednesday 13 February 2008, Greg KH wrote:
On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg KH wrote:
On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
On Wednesday 13 February 2008, Greg KH wrote:
On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote:
On Wed, Feb 13, 2008 at 11:20:36PM +0100, Bartlomiej Zolnierkiewicz wrote:
On Wednesday 13 February 2008, Greg KH wrote:
On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg KH wrote:
On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
On Wednesday 13 February 2008, Greg
On Thursday 14 February 2008, Greg KH wrote:
On Wed, Feb 13, 2008 at 11:20:36PM +0100, Bartlomiej Zolnierkiewicz wrote:
On Wednesday 13 February 2008, Greg KH wrote:
On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg KH wrote:
On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej
On Thu, Feb 14, 2008 at 01:02:55AM +0100, Bartlomiej Zolnierkiewicz wrote:
On Thursday 14 February 2008, Greg KH wrote:
On Wed, Feb 13, 2008 at 11:20:36PM +0100, Bartlomiej Zolnierkiewicz wrote:
On Wednesday 13 February 2008, Greg KH wrote:
On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg
Greg KH [EMAIL PROTECTED] writes:
How does the patch below look? I didn't want to remove the whole config
option, as there is more to the logic than just the reverse order
stuff there.
I think you miss Documentation - it's mentioned in ide.txt and
kernel-parameters.txt,
Andreas
--
Andreas
On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote:
> > Why does the calgary driver need this? Can we just use pci_get_device()
> > instead? Why do you need to walk the device list backwards? Do you get
> > false positives going forward?
>
> It doesn't look to be performance critical so
> Why does the calgary driver need this? Can we just use pci_get_device()
> instead? Why do you need to walk the device list backwards? Do you get
> false positives going forward?
It doesn't look to be performance critical so the driver can
pci_get_device until the end and use the final hit
On Tue, Feb 12, 2008 at 04:15:06PM -0800, Greg KH wrote:
> Hi,
>
> I'm reworking the pci device list logic (we currently keep all PCI
> devices in 2 lists, which isn't the nicest, we should be able to get
> away with only 1 list.)
>
> The only bother I've found so far is the
Why does the calgary driver need this? Can we just use pci_get_device()
instead? Why do you need to walk the device list backwards? Do you get
false positives going forward?
It doesn't look to be performance critical so the driver can
pci_get_device until the end and use the final hit
On Tue, Feb 12, 2008 at 04:15:06PM -0800, Greg KH wrote:
Hi,
I'm reworking the pci device list logic (we currently keep all PCI
devices in 2 lists, which isn't the nicest, we should be able to get
away with only 1 list.)
The only bother I've found so far is the pci_get_device_reverse()
On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote:
Why does the calgary driver need this? Can we just use pci_get_device()
instead? Why do you need to walk the device list backwards? Do you get
false positives going forward?
It doesn't look to be performance critical so the
51 matches
Mail list logo