The hpc_get_mode1_ECC_cap() function of SHPCHP driver seems to refer
the wrong bit for refering the "Mode 1 ECC Capability" bit. This bug
seems not to cause any problem so far. But I think this should be
fixed. This patch fixes this bug.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The hpc_get_max_bus_speed() function of the SHPCHP driver seems to
refer wrong bits in the "Slot Avail Register I" and "Slot Avail
Register II". This patch fixes this bug. And this also cleanup the
code.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Reduce the number of debug messages generated if shpchp debug is
enabled. I tried to restrict this to removing debug messages that
are either early-driver-debug type messages, or print information
that can be inferred through other debug prints.
Signed-off-by: Rajesh Shah <rajesh.shah@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Remove un-necessary header includes, remove dead code, remove
some type casts, receive function return in the correct data
type...
Signed-off-by: Rajesh Shah <rajesh.shah@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Reduce the SHPC hotplug driver's dependence on ACPI. We don't
walk the acpi namespace anymore to build a list of bridges and
devices. The remaining interaction with ACPI is to run the
_OSHP method to transition control of hotplug hardware from
system BIOS to the shpc hotplug driver, and to run the _HPP
method to get hotplug device parameters like cache line size,
latency timer and SERR/PERR enable from BIOS.
Note that one of the side effects of this patch is that shpchp
does not enable the hot-added device or its DMA bus mastering
automatically now. It expects the device driver to do that.
This may break some drivers and we will have to fix them as
they are reported.
Signed-off-by: Rajesh Shah <rajesh.shah@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Kenji Kaneshige