Question re DeviceTree addressing

[Caleb James DeLisle]

Thank you very much, that clears things up a lot.

Thanks,
Caleb

On 04/04/2023 05:33, Florian Fainelli wrote:
> 
> 
> On 4/3/2023 7:00 AM, Caleb James DeLisle wrote:
>> Hello folks,
>>
>> I've been working on trying to port an en7526 and in doing so I'm trying to learn how to at least 
>> partially write a DTS file from an old style header full of #defines.
>>
>> I ran into a bit of a quandry, I'm comparing the mt7621.dtsi file to an older MT7621 memory map 
>> header:
>>
>> https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7621.dtsi#L100
>>
>> https://github.com/keenetic/kernel-49/blob/master/arch/mips/include/asm/rt2880/rt_mmap.h#L48
>>
>> ```
>>      palmbus: palmbus at 1e000000 {
>>          compatible = "palmbus";
>>          reg = <0x1e000000 0x100000>;
>>          ranges = <0x0 0x1e000000 0x0fffff>;
>>
>> [...]
>>
>>          i2c: i2c at 900 {
>>              compatible = "mediatek,mt7621-i2c";
>>              reg = <0x900 0x100>;
>> ```
>>
>> For me, means there should be an I2C controller mapped at address 0x1e000900.
> 
> Correct.
> 
>>
>> But looking at rt_mmap.h I see:
>>
>> ```
>> #define RALINK_I2C_BASE            0xBE000900
>> ```
>>
>> And in fact almost everything is based on 0xBE000000, except UART and USB addresses which are 
>> "correct". And I see these 0xBE000000 addresses being passed through KSEG1ADDR() so it seems they 
>> are physical memory addresses, not virtual.
> 
> KSEG1ADDR does a logical or so it would not be altering RALINK_I2C_BASE when OR'd with 0xa0000000 
> (KSEG1) you would still get 0xBE000900.
> 
> It seems to me like in places where it may be necessary to pass a physical address they used 
> physical addresses such that ioremap() ends-up returning a proper kernel virtual address in KSEG1, 
> however everywhere else the driver might have just directly de-referenced the constant which ends-up 
> working just fine as well.
> 
> HTH