在 2016/1/5 0:34, Arnd Bergmann 写道:
On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
在 2016/1/4 19:13, Arnd Bergmann 写道:
On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
在 2015/12/31 23:00, Rongrong Zou 写道:
*/
compatible = "low-pin-count";
device_type = "isa";
#address-cells = <2>;
#size-cells = <1>;
reg = <0x0 0xa01b0000 0x0 0x10000>;
ranges = <0x1 0x0 0x0 0x0 0x1000>;
/*
* ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1,
0x000000e4, 4>".
*
*/
ipmi_0:ipmi@000000e4{
device_type = "ipmi";
compatible = "ipmi-bt";
reg = <0x1 0x000000e4 0x4>;
};
This looks wrong: the property above says that the I/O port range is
translated to MMIO address 0x00000000 to 0x00010000, which is not
true on your hardware. I think this needs to be changed in the code
so the ranges property is not required for I/O ports.
Ranges property can set empty, but this means 1:1 translation. the I/O
port range is translated to MMIO address 0x00000001 00000000 to
0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
I/O port resource from dts.
As I said, nothing should really require the ranges property here, unless
you have a valid IORESOURCE_MEM translation. The code that requires
the ranges to be present is wrong.
I think the openfirmware(DT) do not support for those unmapped I/O ports,
because I
must get resource by calling of_address_to_resource(), which have to call
pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
better idea for this now. Maybe liviu can give me some opinions.
/**
* of_address_to_resource - Translate device tree address and return as resource
*
* Note that if your address is a PIO address, the conversion will fail if
* the physical address can't be internally converted to an IO token with
* pci_address_to_pio(), that is because it's either called to early or it
* can't be matched to any host bridge IO space
*/
int of_address_to_resource(struct device_node *dev, int index,
struct resource *r)
For ipmi driver, I can get I/O port resource by DMI rather than dts.
No, the ipmi driver uses the resource that belongs to the platform
device already, you can't rely on DMI data to be present there.
Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
openfirmware and a few other), I think we just use one of them, not all of them.
It depend on vendor's hardware solution actually.
Arnd
.
Thanks,
Rongrong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
