RFC ARM: kirkwood: cleanup DT conversion
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 RFC Latest posting 4/40 of 8 patches 0 repliesNew
- v2 RFC posting 3/40 of 8 patches 0 repliesSuperseded
- v2 RFC posting 2/40 of 8 patches 0 repliesSuperseded
Earlier versions · 1
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v2 RFC posting 1/4 | 0 of 8 patches | 0 replies | Superseded |
Patches in v2 posting 4/4 No applies recorded yet
None of the 8 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [RFC V2 PATCH 0/8] ARM: kirkwood: cleanup DT conversion
Quoted 4 lines · Thomas Petazzoni
devices described in the DT, nothing different. In their ->probe() function, those driver call some
mvebu_setup_addr_decoding_window()function, which is part of an API provided by the address mapping driver.
I think that would be a layering mess to update these possibly shared drivers to conditionally call some mvebu specific function in some case, with some SOC specific set of parameters.. The MBUS driver should take care of that, just like the PCI framework takes care of address allocation.
Quoted 5 lines
The address at which we configure the various address decoding windows is an operating system specific decision, it is not a description of the hardware. Therefore, it shouldn't be encoded in the DT, because the DT describes the hardware, not the Linux-specific decisions on how the hardware should be used.
DT models PCI BARs/Bridge windows as well, which are functionally identical to the MBUS decode windows. There *is* a piece of address decoder hardware, and the DT binding for that kind of hardware is a bus with ranges. So it is completely appropriate to model that in DT.
The OF convention for bridge buses is to put the boot loader assigned address in the DT (under the assumption that the boot loader sets things up properly) so it is reasonable to include those addresses in DT as well..
If, someday, the MBUS driver wants to dynamically allocate every MBUS region, then that is fine, it can ignore/override the addresses from the DT, just like the PCI stuff does for BARs/etc, but for today without dynamic assignment it makes alot of sense to just use the DT values directly.
Jason