> From: Greg KH [mailto:[email protected]]
> In 2.5 we now have a
> pci_bus_read_*
> and pci_bus_write_* functions, which the pci hotplug drivers use, as
> they at least know the bus on which the devices they are
> looking for are
> on. I also had to convert over some ACPI code that was using the
> pci_read_config functions to get everything to work properly, but I
> don't seem to be able to find that code in the latest 2.5 tree, so I
> guess you don't need to do that anymore?
It's still there in drivers/acpi/osl.c. We use the pci_root_ops directly,
instead of bus->ops (which is usually set to pci_root_ops anyways) but I
just mention this as a sidenote.
Regards -- Andy
On Thu, Oct 31, 2002 at 02:00:27PM -0800, Grover, Andrew wrote:
> > From: Greg KH [mailto:[email protected]]
> > In 2.5 we now have a
> > pci_bus_read_*
> > and pci_bus_write_* functions, which the pci hotplug drivers use, as
> > they at least know the bus on which the devices they are
> > looking for are
> > on. I also had to convert over some ACPI code that was using the
> > pci_read_config functions to get everything to work properly, but I
> > don't seem to be able to find that code in the latest 2.5 tree, so I
> > guess you don't need to do that anymore?
>
> It's still there in drivers/acpi/osl.c. We use the pci_root_ops directly,
> instead of bus->ops (which is usually set to pci_root_ops anyways) but I
> just mention this as a sidenote.
Ah, thanks for pointing it out, I try to forget my forays into the ACPI
code :)
But even then, you are building up a few pci structures yourself to talk
to the pci device. In looking at the few places you call this function,
is there any reason that acpi_ex_pci_config_space_handler() can't just
call pci_bus_* itself, instead of having to go through
acpi_os_read_pci_configuration()? If so, the one other usage of the
acpi_os_read_pci_configuration() can cause that function to be
simplified a lot.
Anyway, this is a nice diversion from the real problem here, for 2.4,
should I just backport the pci_ops changes which will allow pci
hotplugging to work again on ia64, or do we want to do something else?
thanks,
greg k-h
On Thu, 31 Oct 2002, Greg KH wrote:
[snip]
> Anyway, this is a nice diversion from the real problem here, for 2.4,
> should I just backport the pci_ops changes which will allow pci
> hotplugging to work again on ia64, or do we want to do something else?
It would be nice from a hotplug driver maintenance point of view if the
2.4 and 2.5 interfaces were the same IMO. How about submitting the change
in 2.4.21-pre?
Scott
--
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: [email protected]
On Thu, 31 Oct 2002 14:11:36 -0800
Greg KH <[email protected]> wrote:
> But even then, you are building up a few pci structures yourself to talk
> to the pci device. In looking at the few places you call this function,
> is there any reason that acpi_ex_pci_config_space_handler() can't just
> call pci_bus_* itself, instead of having to go through
> acpi_os_read_pci_configuration()? If so, the one other usage of the
> acpi_os_read_pci_configuration() can cause that function to be
> simplified a lot.
That's because of Linux port of ACPI CA structure.
ACPI CA divides the acpi driver into OS independent part and os dependent
part. acpi_ex_pci_config_space_handler exists in OS-independent
part and acpi_os_read_pci_configuration exists in OS-dependent
part. The OS independent part is shared with other OSes, while
OS dependent part (acpi_os_xxx functions) are Linux specific.
That's the way ACPI driver designers took and Linux can benefit
from other OS's feedback in OS-independent part.
> Anyway, this is a nice diversion from the real problem here, for 2.4,
> should I just backport the pci_ops changes which will allow pci
> hotplugging to work again on ia64, or do we want to do something else?
It would be great if we had the same 2.5 functions in 2.4.
Thanks,
--
KOCHI, Takayoshi <[email protected]/[email protected]>
On Thu, Oct 31, 2002 at 05:50:06PM -0500, Scott Murray wrote:
> On Thu, 31 Oct 2002, Greg KH wrote:
> [snip]
> > Anyway, this is a nice diversion from the real problem here, for 2.4,
> > should I just backport the pci_ops changes which will allow pci
> > hotplugging to work again on ia64, or do we want to do something else?
>
> It would be nice from a hotplug driver maintenance point of view if the
> 2.4 and 2.5 interfaces were the same IMO.
Yes it would be, but it's not a necessary thing :)
> How about submitting the change in 2.4.21-pre?
It is a _very_ big change. It hits every architecture. It was the
right thing to do in 2.5, I'm just questioning if it's the right thing
to do in 2.4 because of the magnitude of it.
So, if people say it's ok, I'll do it. But I would like to hear from
the PPC64 group first, as I know I caused them a lot of grief and rework
because of it.
thanks,
greg k-h
On Thu, Oct 31, 2002 at 03:37:16PM -0800, KOCHI, Takayoshi wrote:
>
> On Thu, 31 Oct 2002 14:11:36 -0800
> Greg KH <[email protected]> wrote:
>
> > But even then, you are building up a few pci structures yourself to talk
> > to the pci device. In looking at the few places you call this function,
> > is there any reason that acpi_ex_pci_config_space_handler() can't just
> > call pci_bus_* itself, instead of having to go through
> > acpi_os_read_pci_configuration()? If so, the one other usage of the
> > acpi_os_read_pci_configuration() can cause that function to be
> > simplified a lot.
>
> That's because of Linux port of ACPI CA structure.
> ACPI CA divides the acpi driver into OS independent part and os dependent
> part. acpi_ex_pci_config_space_handler exists in OS-independent
> part and acpi_os_read_pci_configuration exists in OS-dependent
> part. The OS independent part is shared with other OSes, while
> OS dependent part (acpi_os_xxx functions) are Linux specific.
Ok, if you want to drag that baggage around for forever, fine. But
don't force me to change anything in the pci core to enable that baggage
to stay :)
> That's the way ACPI driver designers took and Linux can benefit
> from other OS's feedback in OS-independent part.
Can I ask if any of the development for other OSs has actually helped
Linux development? I'm just curious.
And isn't the ACPI core development basically finished, so that now we
can start to do these OS dependent optimizations to allow the ACPI code
base to start to shrink and move towards looking more like the rest of
the kernel code, instead of looking like "something that got run through
a Linux kernelizer style generator"?
> > Anyway, this is a nice diversion from the real problem here, for 2.4,
> > should I just backport the pci_ops changes which will allow pci
> > hotplugging to work again on ia64, or do we want to do something else?
>
> It would be great if we had the same 2.5 functions in 2.4.
It would be, but as I just said in a different response, it's a _big_
change. I can't just go breaking different arch's with impunity as I've
been doing in 2.5 :)
thanks,
greg k-h
On Thu, 31 Oct 2002, Greg KH wrote:
> On Thu, Oct 31, 2002 at 05:50:06PM -0500, Scott Murray wrote:
> > On Thu, 31 Oct 2002, Greg KH wrote:
> > [snip]
> > > Anyway, this is a nice diversion from the real problem here, for 2.4,
> > > should I just backport the pci_ops changes which will allow pci
> > > hotplugging to work again on ia64, or do we want to do something else?
> >
> > It would be nice from a hotplug driver maintenance point of view if the
> > 2.4 and 2.5 interfaces were the same IMO.
>
> Yes it would be, but it's not a necessary thing :)
Yeah, yeah, I can deal. ;)
> > How about submitting the change in 2.4.21-pre?
>
> It is a _very_ big change. It hits every architecture. It was the
> right thing to do in 2.5, I'm just questioning if it's the right thing
> to do in 2.4 because of the magnitude of it.
>
> So, if people say it's ok, I'll do it. But I would like to hear from
> the PPC64 group first, as I know I caused them a lot of grief and rework
> because of it.
I hadn't realized the magnitude of the changes from the previous
discussion here on the list, my apologies.
Scott
--
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: [email protected]
On Thu, 31 Oct 2002 15:54:57 -0800
Greg KH <[email protected]> wrote:
> > That's the way ACPI driver designers took and Linux can benefit
> > from other OS's feedback in OS-independent part.
>
> Can I ask if any of the development for other OSs has actually helped
> Linux development? I'm just curious.
FreeBSD's acpi project is a good example.
http://www.jp.freebsd.org/acpi/index.html
(though this page doesn't seem to reflect recent status)
They share the same code base (OS-independent part) as Linux
and troubles FreeBSD had are troubles Linux will have or vice versa.
Its mailing-list is based in Japan but most discussions
are in English and some intel developers are also in the list.
AFAIK the aic7xxx driver has similar structure.
Thanks,
--
KOCHI, Takayoshi <[email protected]/[email protected]>
On Thu, Oct 31, 2002 at 04:23:56PM -0800, KOCHI, Takayoshi wrote:
>
> On Thu, 31 Oct 2002 15:54:57 -0800
> Greg KH <[email protected]> wrote:
>
> > > That's the way ACPI driver designers took and Linux can benefit
> > > from other OS's feedback in OS-independent part.
> >
> > Can I ask if any of the development for other OSs has actually helped
> > Linux development? I'm just curious.
>
> FreeBSD's acpi project is a good example.
> http://www.jp.freebsd.org/acpi/index.html
> (though this page doesn't seem to reflect recent status)
>
> They share the same code base (OS-independent part) as Linux
> and troubles FreeBSD had are troubles Linux will have or vice versa.
>
> Its mailing-list is based in Japan but most discussions
> are in English and some intel developers are also in the list.
Nice, thanks for pointing that out. But what about the fact that I
think we can now start optimizing certain parts of the "generic" code to
play nicer with Linux?
> AFAIK the aic7xxx driver has similar structure.
Some other SCSI drivers have this kind of structure. And in the end,
it's a big pain. If it makes the aic7xxx driver author's life easier,
all the better, as he's doing that work. I just hope the upcoming 2.5
scsi core changes will not mess with him too much.
And that's the biggest problem with portions of code that try to be "os
independent", it usually causes bloat, and keeps other developers from
trying to help out with the project (any change I would make would most
likely be a Linux specific change, and be refused by the maintainer.)
It requires yet another "shim" layer between the driver's core logic,
and the OS, and the kernel sure doesn't need anymore of those...
OS independent drivers have been proven to not work, you don't see UDI
in production use now do you?
Now I don't mean this to be an ACPI rant, I know why they did their code
this way, and without it, there probably would not be any ACPI Linux
code. I just don't think it's the best way (from an engineering
standpoint) to do things. And again, we are getting way off topic from
the original problem, sorry.
thanks,
greg k-h