PCI Hotplug Drivers for 2.5
Quoted 3 lines · Jung-Ik
Greg,
Please find the attached ACPI based PCI Hotplug driver.
But the code you sent has all of the ACPI stuff not enabled, right?
As an example from your patch:
+enum php_ctlr_type phphpc_get_ctlr_type()
+{
+ return PCI;
+}
It never returns any other type, so the ACPI or ISA sections of the driver will never get called. Or am I missing something?
Quoted 3 lines
intcphp:
Php driver source for Compaq or compatible Intel Hotplug controllers on IA32 or DIG64-ACPI compliant IA64 platforms.
So this overloads the current Compaq driver? It looks like this "new" driver will also handle all of the same controllers the current Compaq driver does, right? If not, it sure looks like you are accepting all of the same PCI ID values :)
Quoted 3 lines
intcphp driver is overhauled per your requirements:
+ Abstraction module is removed.
It's now two modules driver like others.
Thank you for making this change, I appreciate it.
Quoted 1 line
+ typedefs are removed except callback function.
Thanks.
Quoted 1 line
+
LINUX_VERSIONchecks are removed.
And replaced with the odd BEFORE_2_5 check :)
Please just rip these out and send a version that is only for the 2.5 kernel.
Some of your #ifdef CONFIG_IA64 should be moved to header files only (and probably documented why you really need to sleep extra amounts for ia64 machines only.
What's the #ifdef WORK_QUEUE for?
Quoted 4 lines
intcphp is much based on cpqphp driver but has been modified to be
controller independent on DIG64/ACPI compliant IPF servers as well as non-ACPI based IA32 servers. Thus code looks similar but integration is not that easy and will take time and consents of affected drivers owners.
The code looks _very_ similar. In fact, at first glance it looks like almost a straight copy of the existing Compaq code. Why not just submit a patch against that driver that adds the extra functionality that you need for your hardware? That would be much smaller, and decrease the amount of duplicated code in the kernel tree.
Also, why doesn't the ACPI PCI hotplug driver work for your machines? I've seen it work on a very wide range of processors (i386 and ia64), and manufacturers, and any specific issues with your hardware would probably be better addressed with patches to the existing ACPI driver.
Quoted 6 lines
We understand there needs more integration and cleanup to make
common codes topci_hotplugcore as you indicated. This task, however, requires time and changes in every php driver with owners' consensus on common php controller/slot objects, while satisfying requirements in the near future. We look forward to discussing this with you and other contributors.
Great, I do too. Please, make a proposal about what to merge into the core. I do NOT want to see another driver have to duplicate the PCI resource management code again without a very good reason for doing it.
Quoted 1 line
Until then, please allow us to co-exist this driver.
There's no rush, let's work together to get this done properly.
thanks,
greg k-h
Hi,
Quoted 4 lines · On Wed, 23 Oct 2002 22:10:08 -0700 Greg KH <[email protected]> wrote:
Also, why doesn't the ACPI PCI hotplug driver work for your machines? I've seen it work on a very wide range of processors (i386 and ia64), and manufacturers, and any specific issues with your hardware would probably be better addressed with patches to the existing ACPI driver.
The ACPI spec provides very limited control of actual hardware (With ACPI, we don't have common method for controlling such as Bus speed, LED etc.).
So if a hardware comes with well-documented hotplug controller, we can achieve finer control over the hardware.
The SHPC specification defines it still depends on ACPI for managing resources, etc. So resource management portion can be and *should be* shared with all PCI hotplug drivers that use ACPI for resource management.
I think the most important thing is everyone agree on the direction in which we should go before we code anything, in order not to waste our time.
Thanks,
Signature · 1 line
KOCHI, Takayoshi <[email protected]/[email protected]>
Quoted 10 lines · Takayoshi
Hi,
Quoted 4 lines · On Wed, 23 Oct 2002 22:10:08 -0700 Greg KH <[email protected]> wrote:
Also, why doesn't the ACPI PCI hotplug driver work for your machines? I've seen it work on a very wide range of processors (i386 and ia64), and manufacturers, and any specific issues with your hardware would probably be better addressed with patches to the existing ACPI driver.
Quoted 5 lines
The ACPI spec provides very limited control of actual hardware (With ACPI, we don't have common method for controlling such as Bus speed, LED etc.).
So if a hardware comes with well-documented hotplug controller, we can achieve finer control over the hardware.
Ah, I didn't realize this. So for some machines (like IBM's x440), we should stick with using the hotplug controller driver, instead of using the ACPI driver. Sounds reasonable to me.
Quoted 8 lines
The SHPC specification defines it still depends on ACPI for managing resources, etc. So resource management portion can be and *should be* shared with all PCI hotplug drivers that use ACPI for resource management.
I think the most important thing is everyone agree on the direction in which we should go before we code anything, in order not to waste our time.
I think we now all agree that resource management should move into a place where it can be shared by all pci hotplug drivers, right?
If so, anyone want to propose some common code? I think the stuff in the ACPI driver that was pulled from the Compaq driver is a great start. I can try to pull this into the core myself, but if the Intel developers have the time, and energy, I would greatly appreciate their help (or anyone else who wants to join in.)
thanks,
greg k-h
Quoted 8 lines · Greg KH
I think we now all agree that resource management should move into a place where it can be shared by all pci hotplug drivers, right?
If so, anyone want to propose some common code? I think the stuff in the ACPI driver that was pulled from the Compaq driver is a great start. I can try to pull this into the core myself, but if the Intel developers have the time, and energy, I would greatly appreciate their help (or anyone else who wants to join in.)
We already _have_ a lot of common code in drivers/pci, but it's not compiled in for x86 or ia64. some other architectures don't assign PCI resources in the `BIOS' so we get to do it. setup-bus.c, setup-res.c and setup-irq.c all seem to duplicate some part of the code currently found in each and every hotplug driver.
Signature · 1 line
Revolutions do not require corporate support.
Quoted 10 lines · Greg KH
Quoted 8 lines
The SHPC specification defines it still depends on ACPI for managing resources, etc. So resource management portion can be and *should be* shared with all PCI hotplug drivers that use ACPI for resource management.
I think the most important thing is everyone agree on the direction in which we should go before we code anything, in order not to waste our time.
Quoted 4 lines
I think we now all agree that resource management should move into a place where it can be shared by all pci hotplug drivers, right?
If so, anyone want to propose some common code?
drivers/pci/setup* is not enough?
I am surprised that anything needed to be added here...
Hi Greg,
My answers are next to your comments.
thanks,
J.I.
Quoted 10 lines
-----Original Message-----
From: Greg KH [mailto:[email protected]]
Sent: Wednesday, October 23, 2002 10:10 PM
To: Lee, Jung-Ik
Cc: 'KOCHI, Takayoshi'; Luck, Tony; [email protected]; linux ia64 kernel list; linux-kernel
Subject: Re: PCI Hotplug Drivers for 2.5
Quoted 6 lines
Quoted 3 lines · Jung-Ik
Greg,
Please find the attached ACPI based PCI Hotplug driver.
But the code you sent has all of the ACPI stuff not enabled, right?
ACPI is a must for PHP enumeration/configuration and resource management for DIG64/ACPI compliant platforms. ACPI method is optional for controller/slot operations(event management). intcphp driver conforms to ACPI resource management. I didn't enable ACPI based event management for PHP since it is optional and provides less feature than controller based solution - LED, MRL, Bus/Adapter speeds/capabilities, etc.
Quoted 11 lines
As an example from your patch:
(quoted diff) +4
-0+enum php_ctlr_type phphpc_get_ctlr_type() +{ + return PCI; +}It never returns any other type, so the ACPI or ISA sections of the driver will never get called. Or am I missing something?
This is because this release only addresses PCI version only. I can take this out too, with ease :)
Quoted 10 lines
Quoted 3 lines
intcphp:
Php driver source for Compaq or compatible Intel Hotplug controllers on IA32 or DIG64-ACPI compliant IA64 platforms.So this overloads the current Compaq driver? It looks like this "new" driver will also handle all of the same controllers the current Compaq driver does, right? If not, it sure looks like you are accepting all of
the same PCI ID values :)
Probably, as PCI ID indicates :)
Quoted 8 lines
Quoted 3 lines
intcphp driver is overhauled per your requirements:
+ Abstraction module is removed.
It's now two modules driver like others.Thank you for making this change, I appreciate it.
Quoted 1 line
+ typedefs are removed except callback function.
Quoted 8 lines
Thanks.
Quoted 1 line
+
LINUX_VERSIONchecks are removed.And replaced with the odd
BEFORE_2_5check :)
Please just rip these out and send a version that is only for the 2.5 kernel.
Ah, you noticed it.. OK (pain in my heart :))
Quoted 6 lines
Some of your #ifdef
CONFIG_IA64should be moved to header files only (and probably documented why you really need to sleep extra amounts for
ia64 machines only.What's the #ifdef
WORK_QUEUEfor?
Not used. Will take out.
Quoted 17 lines
Quoted 2 lines
intcphp is much based on cpqphp driver but has been
modified to be
Quoted 1 line
controller independent on DIG64/ACPI compliant IPF servers
as well as
Quoted 1 line
non-ACPI based IA32 servers. Thus code looks similar but
integration is not
Quoted 1 line
that easy and will take time and consents of affected
drivers owners.
The code looks _very_ similar. In fact, at first glance it looks like almost a straight copy of the existing Compaq code. Why not just submit
a patch against that driver that adds the extra functionality that you need for your hardware? That would be much smaller, and decrease the amount of duplicated code in the kernel tree.
Quoted 5 lines
Also, why doesn't the ACPI PCI hotplug driver work for your machines? I've seen it work on a very wide range of processors (i386 and ia64), and manufacturers, and any specific issues with your hardware would probably be better addressed with patches to the existing ACPI driver.
With some reasons such as what Tak described.
Quoted 10 lines
Quoted 2 lines
We understand there needs more integration and cleanup to make
common codes topci_hotplugcore as you indicated. Thistask, however,
Quoted 1 line
requires time and changes in every php driver with owners'
consensus on
Quoted 1 line
common php controller/slot objects, while satisfying
requirements in the
Quoted 2 lines
near future. We look forward to discussing this with you and other contributors.
Quoted 9 lines
Great, I do too. Please, make a proposal about what to merge into the core. I do NOT want to see another driver have to duplicate the PCI resource management code again without a very good reason for doing it.
Quoted 1 line
Until then, please allow us to co-exist this driver.
There's no rush, let's work together to get this done properly.
We need this driver as it's the only solution for DIG64 compliant IPF platforms.
Can we work in parallel ? - Make this driver available and we all work together for enhanced pci_hotplug core. Also I'll talk with cpqphp owner over the integration of the two.
Quoted 4 lines
thanks,
greg k-h
Quoted 4 lines
I think we now all agree that resource management should move into a place where it can be shared by all pci hotplug drivers, right?
Quoted 8 lines
If so, anyone want to propose some common code? I think the stuff in the ACPI driver that was pulled from the Compaq driver is a great start.
I can try to pull this into the core myself, but if the Intel developers
have the time, and energy, I would greatly appreciate their help (or anyone else who wants to join in.)
Resource Management code in phprm.h works fine for both ACPI based platforms and non-ACPI platforms (smbios, BIOS $HRT, pcibios_pci_irq_routing...) doing php enumeration, configuration, resource allocation, etc. Only phprm_acpi.c is included in this release for size matters.
intcphp driver is free from controller type, IA32/IPF, ACPI/non-ACPI and depending on kernel configuration, it can bind to either ACPI PHPRM or non-ACPI PHPRM.
PCI resource handling code - that does add/delete/sort/combine, etc on pci_resource - has nothing to do with ACPI or non-ACPI so it should be common across cpqphp, ibmphp, acpiphp and intcphp. They are duplicated and varied due to mother structures differences.
Quoted 4 lines
thanks,
greg k-h
Quoted 7 lines · Jung-Ik
ACPI is a must for PHP enumeration/configuration and resource management for DIG64/ACPI compliant platforms. ACPI method is optional for controller/slot operations(event management). intcphp driver conforms to ACPI resource management. I didn't enable ACPI based event management for PHP since it is optional and provides less feature than controller based solution - LED, MRL, Bus/Adapter speeds/capabilities, etc.
But as the code you sent me isn't enabled for ACPI, I don't see how it ties into the existing Compaq based PCI driver. How does this work? Are you trying to have 1 driver handle both the PCI and ACPI functionality?
Quoted 7 lines
Quoted 7 lines
As an example from your patch:
(quoted diff) +4
-0+enum php_ctlr_type phphpc_get_ctlr_type() +{ + return PCI; +}
Quoted 5 lines
Quoted 3 lines
It never returns any other type, so the ACPI or ISA sections of the driver will never get called. Or am I missing something?
This is because this release only addresses PCI version only. I can take this out too, with ease :)
As this means there is a lot of "dead code" in the driver, you should take all of it out.
Quoted 11 lines
Quoted 10 lines
Quoted 3 lines
intcphp:
Php driver source for Compaq or compatible Intel Hotplug controllers on IA32 or DIG64-ACPI compliant IA64 platforms.So this overloads the current Compaq driver? It looks like this "new" driver will also handle all of the same controllers the current Compaq driver does, right? If not, it sure looks like you are accepting all of
the same PCI ID values :)Probably, as PCI ID indicates :)
Ok, no, I will not accept this driver then, as you are duplicating the entire Compaq driver. Just provide a patch for the existing driver with your new functionality.
Quoted 7 lines
Quoted 6 lines
Quoted 1 line
+
LINUX_VERSIONchecks are removed.And replaced with the odd
BEFORE_2_5check :)
Please just rip these out and send a version that is only for the 2.5 kernel.Ah, you noticed it.. OK (pain in my heart :))
Hm, directly trying to sneak something by me, by just renaming a #define. Not nice. :(
Quoted 4 lines
We need this driver as it's the only solution for DIG64 compliant IPF platforms.
Can we work in parallel ? - Make this driver available and we all work together for enhancedpci_hotplugcore.
No, does your driver _have_ to be in the 2.5 kernel tree right now for some reason? Can't anyone who _has_ to have PCI Hotplug support for these types of machines (and I don't think there are any types of these machines currently shipping, right? And they wouldn't be running a 2.5 kernel on them, right?) just grab your driver if they really need it?
Quoted 1 line
Also I'll talk with cpqphp owner over the integration of the two.
You're talking to him :)
thanks,
greg k-h
Quoted 10 lines · Jeff Garzik
Quoted 4 lines · Greg KH
I think we now all agree that resource management should move into a place where it can be shared by all pci hotplug drivers, right?
If so, anyone want to propose some common code?
drivers/pci/setup*is not enough?I am surprised that anything needed to be added here...
There was some reason that code would not work out when I looked at it over a year ago. But I don't remember why, so I'll go look at it again, thanks for pointing it out.
greg k-h
Quoted 2 lines
We need this driver as it's the only solution for DIG64 compliant IPF platforms.
No, not for all DIG64 compliant IPF platforms. NEC TX7 is also a DIG64 compliant IPF platform but doesn't need your driver.
DIG64(2.1) only states that:
Firmware Support for PCI Hot-Plug
: Recommended if PCI Hot-Plug is
implemented
ACPI Support for PCI Hot-Plug : Recommended for platforms that
implement PCI Hot-Plug without SHPC
Using PCI Hot-Plug Specifications
: Recommended if PCI Hot-Plug is
implemented
The spec also states that any PCI Hot-Plug controller must follow one of PCI Hot-Plug spec 1.1, SHPC 1.0 or CompactPCI Hot Swap spec. It also strongly recommends SHPC 1.0, which is not covered by J.I.'s driver yet.
But anyway Itanium2 platform using intel's hot-plug controller will be shipping soon and J.I.'s driver has much better functionality than acpiphp. This would be a decent reason for having the driver in the mainline.
And this also motivates us to clean up the duplicated code if it were in mainline:)
Thanks,
Signature · 1 line
KOCHI, Takayoshi <[email protected]/[email protected]>
Quoted 10 lines · Jung-Ik
Quoted 2 lines
ACPI is a must for PHP enumeration/configuration and
resource management for
Quoted 1 line
DIG64/ACPI compliant platforms. ACPI method is optional for
controller/slot
Quoted 1 line
operations(event management). intcphp driver conforms to
ACPI resource
Quoted 1 line
management. I didn't enable ACPI based event management for
PHP since it is
Quoted 8 lines
Quoted 1 line
optional and provides less feature than controller based
solution - LED,
Quoted 1 line
MRL, Bus/Adapter speeds/capabilities, etc.
But as the code you sent me isn't enabled for ACPI, I don't see how it ties into the existing Compaq based PCI driver. How does this work? Are you trying to have 1 driver handle both the PCI and ACPI functionality?
Let me try again :)
**resource management**
Non-ACPI platforms uses $HRT/EBDA, pcibios_*(), SMBIOS, etc. for slot enumeration/configuration.
DIG64/ACPI, and SHPC requires ACPI for this. IPF platforms only have ACPI _CRS, _PRT, _HPP, _BBN, _STA, _ADR, _SUN, etc on the namespace for PHP, and we have to use them. (as a side note, this functionality is common for other hotplug-* as mentioned in first mail. No API will be common for hotplug-everything, but functionality is common and has not to be duplicated)
**event management in terms of controller/slot operations ** ACPI provides only _EJ0, _PS?, _STA, etc for slot operations but these are not mandatory. That means, we can use either ACPI method or controller driver.
intcphp driver has not enabled ACPI method based solution but uses controller driver.
intcphp driver is also capable of performing ACPI method based solution since it works on ACPI namespace. This is why acpiphp and intcphp could be sharing resource management and event management.
Quoted 10 lines
Quoted 9 lines
Quoted 9 lines
As an example from your patch:
(quoted diff) +4
-0+enum php_ctlr_type phphpc_get_ctlr_type() +{ + return PCI; +}It never returns any other type, so the ACPI or ISA
sections of the
Quoted 8 lines
Quoted 3 lines
Quoted 2 lines
driver will never get called. Or am I missing something?
This is because this release only addresses PCI version
only. I can take
Quoted 1 line
this out too, with ease :)
As this means there is a lot of "dead code" in the driver, you should take all of it out.
Well, I removed many dead codes from the base driver. This is not dead code but needed to support other types.
However, if it's not acceptable, I'll remove them.
Quoted 2 lines
Hm, directly trying to sneak something by me, by just renaming a #define. Not nice. :(
No intention like that at all. Please regard this as bright side of engineers simple version control w/ commonly used #ifdefs :) Anyway, they'll be removed per your requirement.
Quoted 8 lines
Quoted 2 lines
We need this driver as it's the only solution for DIG64
compliant IPF
Quoted 2 lines
platforms.
Can we work in parallel ? - Make this driver available andwe all work
Quoted 1 line
together for enhanced
pci_hotplugcore.
Quoted 7 lines
No, does your driver _have_ to be in the 2.5 kernel tree right now for some reason? Can't anyone who _has_ to have PCI Hotplug support for these types of machines (and I don't think there are any types of these
machines currently shipping, right? And they wouldn't be running a 2.5
kernel on them, right?) just grab your driver if they really need it?
It's not my area to answer. It's product marketting. I do not want to skrew marketting :)
We want the driver available before they compalint it :|
BTW, do we know how far is 2.6, even roughly ?
Quoted 4 lines
Quoted 2 lines
Also I'll talk with cpqphp owner over the integration of the two.
You're talking to him :)
Ah. I now know why you are the one who talks about this :) OK, then, I'll send you a patch against your cpqphp driver asap.
Thanks,
J.I.
Quoted 6 lines · Takayoshi
Quoted 2 lines
We need this driver as it's the only solution for DIG64 compliant IPF platforms.
No, not for all DIG64 compliant IPF platforms. NEC TX7 is also a DIG64 compliant IPF platform but doesn't need your driver.
Tangent:
Intel is wrong by renaming IA64 to "IPF".
It was previously used as "Intel Processor Family". IA64 is a far better name, and I will continue to use that in preference to IPF. Re-using an acronym is silly and creates confusion.
Jeff
Quoted 10 lines · Jung-Ik
**resource management**
Non-ACPI platforms uses $HRT/EBDA, pcibios_*(), SMBIOS, etc. for slot enumeration/configuration.
DIG64/ACPI, and SHPC requires ACPI for this. IPF platforms only have ACPI_CRS,_PRT,_HPP,_BBN,_STA,_ADR,_SUN, etc on the namespace for PHP, and we have to use them. (as a side note, this functionality is common for other hotplug-* as mentioned in first mail. No API will be common for hotplug-everything, but functionality is common and has not to be duplicated)
Quoted 9 lines
**event management in terms of controller/slot operations ** ACPI provides only
_EJ0,_PS?,_STA, etc for slot operations but these are not mandatory. That means, we can use either ACPI method or controller driver.
intcphp driver has not enabled ACPI method based solution but uses controller driver.
intcphp driver is also capable of performing ACPI method based solution since it works on ACPI namespace. This is why acpiphp and intcphp could be sharing resource management and event management.
Sounds like we want a library of ACPI code that can be used by individual drivers rather than an ACPI driver with pluggable event management functions then.
Signature · 1 line
Revolutions do not require corporate support.
Quoted 24 lines
Quoted 2 lines
**resource management**
Non-ACPI platforms uses $HRT/EBDA, pcibios_*(), SMBIOS,etc. for slot
Quoted 2 lines
enumeration/configuration.
DIG64/ACPI, and SHPC requires ACPI for this. IPF platformsonly have ACPI
Quoted 1 line
_CRS,_PRT,_HPP,_BBN,_STA,_ADR,_SUN, etc on thenamespace for PHP, and
Quoted 1 line
we have to use them. (as a side note, this functionality is
common for other
Quoted 6 lines
hotplug-* as mentioned in first mail. No API will be common for hotplug-everything, but functionality is common and has not to be duplicated)
**event management in terms of controller/slot operations ** ACPI provides only
_EJ0,_PS?,_STA, etc for slotoperations but these are
Quoted 1 line
not mandatory. That means, we can use either ACPI method or
controller
Quoted 4 lines
driver.
intcphp driver has not enabled ACPI method based solution but uses controller driver.
intcphp driver is also capable of performing ACPI methodbased solution
Quoted 8 lines
Quoted 1 line
since it works on ACPI namespace. This is why acpiphp and
intcphp could be
Quoted 1 line
sharing resource management and event management.
Sounds like we want a library of ACPI code that can be used by individual
drivers rather than an ACPI driver with pluggable event management functions then.
Right, that's where we're getting at.
Quoted 6 lines
Quoted 1 line
We need this driver as it's the only solution for DIG64
compliant IPF
Quoted 1 line
platforms.
No, not for all DIG64 compliant IPF platforms. NEC TX7 is also a DIG64 compliant IPF platform but doesn't need your driver.
Well, I forgot acpiphp driver was removed in this driver patch :) acpiphp is also for DIG64/ACPI and will do for some DIG64/ACPI machines while intcphp is feature full driver for IPF platform PHP.
Quoted 11 lines
DIG64(2.1) only states that:
Firmware Support for PCI Hot-Plug
: Recommended if PCI Hot-Plug is
implemented
ACPI Support for PCI Hot-Plug : Recommended for platforms that
implement PCI Hot-Plug without SHPC
Using PCI Hot-Plug Specifications
: Recommended if PCI Hot-Plug is
implemented
ACPI IS mandatory for DIG64 PHP resource management by SHPC, while ACPI based slot operation is not required.
The above sentence only could be misleading.
Quoted 5 lines
The spec also states that any PCI Hot-Plug controller must follow one of PCI Hot-Plug spec 1.1, SHPC 1.0 or CompactPCI Hot Swap spec. It also strongly recommends SHPC 1.0, which is not covered by J.I.'s driver yet.
intcphp is desined with SHPC on plan in terms of ACPI resource management, as SHPC spec says
"DIG64 compliant platforms must use ACPI to describe resource allocation." But it is not completely ready for SHPC yet. It's a matter of deployment schedules of dependencies such as HPRT, ACPI methods OSHP, HBRB, etc which will need to be enabled in Linux kernel ACPI driver/platform firmware.
Quoted 8 lines
But anyway Itanium2 platform using intel's hot-plug controller will be shipping soon and J.I.'s driver has much better functionality than acpiphp. This would be a decent reason for having the driver in the mainline.
And this also motivates us to clean up the duplicated code if it were in mainline:)
\o/ second to this :)
Quoted 5 lines
Thanks,
Signature · 1 line
KOCHI, Takayoshi <[email protected]/[email protected]>
Quoted 11 lines · Jung-Ik
**resource management**
Non-ACPI platforms uses $HRT/EBDA, pcibios_*(), SMBIOS, etc. for slot enumeration/configuration.
DIG64/ACPI, and SHPC requires ACPI for this. IPF platforms only have ACPI_CRS,_PRT,_HPP,_BBN,_STA,_ADR,_SUN, etc on the namespace for PHP, and we have to use them. (as a side note, this functionality is common for other hotplug-* as mentioned in first mail. No API will be common for hotplug-everything, but functionality is common and has not to be duplicated)
Quoted 9 lines
**event management in terms of controller/slot operations ** ACPI provides only
_EJ0,_PS?,_STA, etc for slot operations but these are not mandatory. That means, we can use either ACPI method or controller driver.
intcphp driver has not enabled ACPI method based solution but uses controller driver.
intcphp driver is also capable of performing ACPI method based solution since it works on ACPI namespace. This is why acpiphp and intcphp could be sharing resource management and event management.
Ok, that makes more sense to me now. Thank you for taking the time to explain this.
Quoted 6 lines
Quoted 2 lines
As this means there is a lot of "dead code" in the driver, you should take all of it out.
Well, I removed many dead codes from the base driver. This is not dead code but needed to support other types.
However, if it's not acceptable, I'll remove them.
If the code can never be called, it looks pretty dead to me :)
But as you're going to be sending me a patch for the existing driver, we don't have to worry about this anymore.
Quoted 1 line
OK, then, I'll send you a patch against your cpqphp driver asap.
Looking forward to it.
thanks,
greg k-h