[PATCH] build: put DT "compatible" value as "board_name" in profiles.json

[mail at adrianschmutzler.de]

> -----Original Message-----
> From: Rafał Miłecki [mailto:rafal at milecki.pl]
> Sent: Donnerstag, 9. Juli 2020 11:12
> To: Daniel Golle <daniel at makrotopia.org>
> Cc: Rafał Miłecki <zajec5 at gmail.com>; Paul Spooren <mail at aparcar.org>;
> openwrt-devel at lists.openwrt.org; Adrian Schmutzler
> <freifunk at adrianschmutzler.de>; Petr Štetiar <ynezz at true.cz>; Moritz
> Warning <moritzwarning at web.de>; Imre Kaloz <kaloz at dune.hu>
> Subject: Re: [PATCH] build: put DT "compatible" value as "board_name" in
> profiles.json
> 
> On 2020-07-09 10:49, Daniel Golle wrote:
> > On Wed, Jul 08, 2020 at 11:32:43PM +0200, Rafał Miłecki wrote:
> >> On 08.07.2020 21:34, Paul Spooren wrote:
> >> > I think there is a policy for new DT devices to use the compatible string
> as profile.
> >> >
> >> > Multiple targets contain the following line in the target Makefile, which
> automatically adds the profile name as supported device:
> >> >
> >> > SUPPORTED_DEVICES := $(subst _,$(comma),$(1))
> >> >
> >> > So ideally for all devices using DT, the profile and compatible string are
> the same except for '_' replaced by ','.
> >> >
> >> > For instance, the "Linksys WRT3200ACM" has the profile ID
> `linksys_wrt3200acm` and the automatically added compatible string
> `linksys,wrt3200acm`. So if that device wanted to search the
> `mvebu/cortexa9/profiles.json` for available sysupgrades, it takes the first
> entry from /proc/device-tree/compatible, replaces ',' with '_' find images in
> profiles.json['profiles']['linksys_wrt3200acm']['images'].
> >> >
> >> > For cases where DT compatible and OpenWrt profile ID/name where
> different either one was patched[0].
> >>
> >> There are still few exceptions like:
> >> linksys-ea9500 vs. compatible = "linksys,panamera"
> >> luxul-xwr-3150 vs. compatible = "luxul,xwr-3150-v1"
> >> luxul-xbr-4500 vs. compatible = "luxul,xbr-4500-v1"

Essentially, we should be able to exploit SUPPORTED_DEVICES for that. Even if there is no sysupgrade with metadata available on the target, the SUPPORTED_DEVICES could indicate which board names would be possible for upgrade.
This would also enable the possibility of a 1:n relationship (instead of a 1:1), i.e. one profile might be used for multiple "board names" (e.g. if you look at x86).

The problem will arise from the opposite situation: e.g. in ar71xx, the same board name might be used for many profiles. With a board-name-based approach, we will never be able to support these for auto-upgrade or similar.
However, I think ar71xx has been the last target that does this to a big extent. There are rare cases where the same DTS is used for more than one profile, but I think we can just ignore those for the moment.
However, if we exploit the board name for that purpose, we should be aware that we move its use away from the initial intention (as in ar71xx, where it really described a board, not a device). I'm fine with that, as that's what I'm trying to enforce lately anyway, but not everyone might be.

The implementation of "proper" board names for the non-DT targets then is not much more than some boring work to do (though e.g. bcm47xx could actually benefit from it).

Best

Adrian

> >>
> >> This is a bit of problem because:
> >> 1. I can't change "panamera" to "ea9500" as I was explicitly asked to
> >>    stick to "panamera" by Imre when upstreaming that DTS
> >
> > I agree we should respect the artistic preferences of contributors to
> > some degree.
> > However, in this case, is there any reason for that somehow secretive
> > naming scheme beyond personal preference?
> > Having a consistent and easy to understand codebase also weights a bit
> > higher than that to me.
> 
> For Linksys, as said, I was told by Imre to use that magic "paramera"
> string. The only explanation I got was that it was "discussed for other
> platforms". For reference, see:
> 
> [PATCH] ARM: dts: BCM5301X: Add basic DT for Linksys EA9500
> https://patchwork.kernel.org/patch/9588095/
> 
> For Luxul devices "-v1" suffix was initially used (during development) and
> later it was decided V2 won't ever appear. So filename got simplified.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20200709/933b1238/attachment.sig>