The class-code property of PCI devices should also include the prog interface field. This patch adds this.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu =================================================================== --- drivers/pci.c (revision 1269) +++ drivers/pci.c (working copy) @@ -893,11 +893,13 @@ int status,id; uint16_t vendor_id, device_id; uint8_t rev; + uint8_t class_prog; uint32_t class_code;
vendor_id = pci_config_read16(addr, PCI_VENDOR_ID); device_id = pci_config_read16(addr, PCI_DEVICE_ID); rev = pci_config_read8(addr, PCI_REVISION_ID); + class_prog = pci_config_read8(addr, PCI_CLASS_PROG); class_code = pci_config_read16(addr, PCI_CLASS_DEVICE);
if (pci_dev) { @@ -925,7 +927,7 @@ set_int_property(dev, "vendor-id", vendor_id); set_int_property(dev, "device-id", device_id); set_int_property(dev, "revision-id", rev); - set_int_property(dev, "class-code", class_code << 8); + set_int_property(dev, "class-code", class_code << 8 | class_prog);
if (config->irq_pin) { OLDWORLD(set_int_property(dev, "AAPL,interrupts", ===============================================================
On 27/02/14 01:05, BALATON Zoltan wrote:
The class-code property of PCI devices should also include the prog interface field. This patch adds this.
Signed-off-by: BALATON Zoltanbalaton@eik.bme.hu
--- drivers/pci.c (revision 1269) +++ drivers/pci.c (working copy) @@ -893,11 +893,13 @@ int status,id; uint16_t vendor_id, device_id; uint8_t rev;
uint8_t class_prog; uint32_t class_code;
vendor_id = pci_config_read16(addr, PCI_VENDOR_ID); device_id = pci_config_read16(addr, PCI_DEVICE_ID); rev = pci_config_read8(addr, PCI_REVISION_ID);
class_prog = pci_config_read8(addr, PCI_CLASS_PROG); class_code = pci_config_read16(addr, PCI_CLASS_DEVICE);
if (pci_dev) {
@@ -925,7 +927,7 @@ set_int_property(dev, "vendor-id", vendor_id); set_int_property(dev, "device-id", device_id); set_int_property(dev, "revision-id", rev);
- set_int_property(dev, "class-code", class_code<< 8);
set_int_property(dev, "class-code", class_code<< 8 | class_prog);
if (config->irq_pin) { OLDWORLD(set_int_property(dev, "AAPL,interrupts",
===============================================================
These seems to agree with my reading of http://wiki.osdev.org/PCI#Class_Codes, although the concatenation of the 3 different fields into the class-code property doesn't seem to be documented in the PCI bindings... do you know is it either an implicit or explicit part of the PCI specification?
ATB,
Mark.
On Thu, 27 Feb 2014, Mark Cave-Ayland wrote:
These seems to agree with my reading of http://wiki.osdev.org/PCI#Class_Codes, although the concatenation of the 3 different fields into the class-code property doesn't seem to be documented in the PCI bindings... do you know is it either an implicit or explicit part of the PCI specification?
I don't know anything about specs but (apart from this change making the MorphOS bootloader happy) I've found some more evidence here:
http://johannes.sipsolutions.net/PowerBook/openfirmware-device-tree
See the usb and firewire ports, as for most others the Prog I/F field is 0.
Regards, BALATON Zoltan
On 28/02/14 11:25, BALATON Zoltan wrote:
On Thu, 27 Feb 2014, Mark Cave-Ayland wrote:
These seems to agree with my reading of http://wiki.osdev.org/PCI#Class_Codes, although the concatenation of the 3 different fields into the class-code property doesn't seem to be documented in the PCI bindings... do you know is it either an implicit or explicit part of the PCI specification?
I don't know anything about specs but (apart from this change making the MorphOS bootloader happy) I've found some more evidence here:
http://johannes.sipsolutions.net/PowerBook/openfirmware-device-tree
See the usb and firewire ports, as for most others the Prog I/F field is 0.
Okay that's good enough for me, and it seems to pass all my image tests so I've committed the change to SVN trunk - thanks for the patch!
ATB,
Mark.
-
BALATON Zoltan -
Mark Cave-Ayland