On Tuesday, 11 June 2024 12:26:17 CEST Leith Bade wrote: > For the record the issues I noticed are (comparing with U-boot and OpenWRTs > versions of the device tree files): > - mt7986a.dtsi is missing entry for the SNFI / SNAND interface to load > https://github.com/torvalds/linux/blob/83a7eefedc9b56fe7bfeff13b6c7356688ffa > 670/drivers/spi/spi-mtk-snfi.c this is not populated on the BPI-R3 but other > boards might use this
Generally, `*.dtsi` files get included into other files, usually `.dts` files. The `mt7986a.dtsi` (likely) describes the SoC, not the full device. The device likely has the flash chip, not the SoC, so the dts file should have an entry for the flash chip (the dts file for OpenWrt One does f.e.). > - in OpenWRT device tree there are a lot more entries in the efuse map > related to the USB and PCIe ports - it seems the USB and PCIe device entries > then use these efuse values DeviceTree files describe the hardware, so *ideally* there should be no difference between what the Linux kernel has (which is generally considered the upstream project for DT files) and what OpenWrt has/uses. Unfortunately, we don't live in an ideal world ;-) If OpenWrt's DT are better (I don't know), then it would be great if they would upstream their improvements to the Linux kernel. But AFAIK, OpenWrt has/manages their own kernel and DT files. I know u-boot now has an OF_UPSTREAM (OF=OpenFirmware=DT) 'setting', which I *think* means they're (in the process of) switching to using the Linux kernel's DeviceTree files. > - no hnat device - though maybe this is only usable with the proprietary > Mediatek driver code I have no idea what that is (for). > - in OpenWRT device tree there is a different "compatible" string for spi0 > (quad) and spi1 (single) - I am not sure if that matters with the upstream > driver, hopefully there is a way to check that the MTD device is using the > quad SPI / SPIM mode The "compatible" string is used to find the appropriate driver (IIUC), so if spi0 and spi1 have different "compatible"s, then they (apparently) need different drivers from them. But as said before, (technically) OpenWrt is their own project, so it doesn't have to match what current upstream does/has. (OpenWrt doesn't track Linus' 'master' branch but the most recent LTS version, which they then patch) > - the BPI-R3 .dtso overlay files for the NAND and NOR flash options have > partition definitions that don't match the device tree in U-boot and > OpenWRT - ideally these should match the partitions on a factory fresh > board which comes OpenWRT preloaded It (generally) doesn't sound good if different projects use/assume different partition layouts. It could be one (or more) projects have incorrect and/or incomplete implementation. I don't know. It could be worth investigating what the correct values are and submitting patches to those projects to get that fixed. > I noticed a few problems but I am not sure what normal protocol is - should > I report it as a bug to Linux directly? The best way to deal with it depends on the project (and could also depend on the subsystem of that project). AFAIK they all use Mailing Lists, but AFAIK OpenWrt also use Pull Requests on GH, which the (majority of the) Linux kernel does not. So you'll need to investigate how the project(s) you want to contribute too (generally) operates. And learn/verify whether what you found is actually a bug and in which project(s) the problem is, and not f.e. that you were looking in the wrong place (dtsi vs dts). HTH and have fun! Diederik PS: this bug report is probably not the right place for these kind of discussions
signature.asc
Description: This is a digitally signed message part.
