profiles: improve SUPPORTED_DEVICES handling and profile identification by map-b · Pull Request #1533 · openwrt/asu

map-b · 2025-12-04T18:50:45Z

The actual handling does not allow to several devices share a DTS compatible string to allow image compatibility between them.

Take the lists as lists and select the profile after checking all possible candidates.
Throw a new validation exception when it is not possible to identify a profile which will help to identify inconsistencies.

This also can help to make a little bit clearer the difference between "profile" and "DTS compatible string".

*There is not need to add [profile] to SUPPORTED_DEVICES list anymore.

asu/asu/util.py

Line 566 in 0328704

for name in data.get("supported_devices", []) + [profile]

Reasoning about the reverts: #1511 (comment) I would like to add that those commits would make harder to understand how we are handling the translation from Device Tree compatible strings to actual profiles names.

Before: ¹

'glinet,gl-mt2500': 'glinet_gl-mt2500-airoha',
'glinet,mt2500-emmc': 'glinet_gl-mt2500-airoha',
'glinet,gl-mt2500-airoha': 'glinet_gl-mt2500-airoha',
'glinet_gl-mt2500': 'glinet_gl-mt2500',
'glinet_gl-mt2500-airoha': 'glinet_gl-mt2500-airoha'

After:

'glinet_gl-mt2500': ['glinet,gl-mt2500', 'glinet,mt2500-emmc', 'glinet,gl-mt2500-airoha', 'glinet_gl-mt2500'],
'glinet_gl-mt2500-airoha': ['glinet,gl-mt2500-airoha', 'glinet,mt2500-emmc', 'glinet,gl-mt2500', 'glinet_gl-mt2500-airoha'],

Fixes: #1525
Fixes: openwrt/openwrt#20566

https://github.com/openwrt/asu/issues/1525#issuecomment-3497242570 ↩

This reverts commit 1579236.

efahl · 2025-12-05T19:09:16Z

Hard NAK.

Is this AI slop code? You've broken event logging, broken a bug fix and removed an important test case.

As I've already explained to you several times, the root cause of this issue is incorrect metadata coming from upstream. Attempting to work around the upstream issue in the ASU server does not fix anything and leaves several other things broken (specifically both sysupgrade and the Firmware Selector).

map-b · 2025-12-05T19:40:58Z

In those two reverts, included in this PR, you were mixing totally the translation or the DT compatible strings into actually profiles, that is not sanitize that is lose track of what are the strings sended by ASU clients(if they do not try to translate before sending them) and the actual profiles which are used in ImageBuilders. It is not AI sope code, a bit unrespectfully comment was that.

If you do not want to reason, it is over, It is really sad.

map-b · 2025-12-05T19:48:52Z

asu/routers/api.py

-    # Sanitize the profile in case the client did not (bug in older LuCI app).
-    build_request.profile = build_request.profile.replace(",", "_")
-
-    add_build_event("requests")


This revert d7fd828 made this, I am not sure why. You are right on that.

You've broken event logging

This reverts commit 2e9edfd.

The actual handling does not allow to several devices share a DTS compatible string to allow image compatibility between them. Take the lists as lists and select the profile after checking all possible candidates. Throw a new validation exception when it is not possible to identify a profile which will help to identify inconsistencies. This also can help to make a little bit clearer the difference between "profile" and "DTS compatible string". * There is not need to add [profile] to SUPPORTED_DEVICES list anymore. Before: [1] 'glinet,gl-mt2500': 'glinet_gl-mt2500-airoha', 'glinet,mt2500-emmc': 'glinet_gl-mt2500-airoha', 'glinet,gl-mt2500-airoha': 'glinet_gl-mt2500-airoha', 'glinet_gl-mt2500': 'glinet_gl-mt2500', 'glinet_gl-mt2500-airoha': 'glinet_gl-mt2500-airoha' After: 'glinet_gl-mt2500': ['glinet,gl-mt2500', 'glinet,mt2500-emmc', 'glinet,gl-mt2500-airoha', 'glinet_gl-mt2500'], 'glinet_gl-mt2500-airoha': ['glinet,gl-mt2500-airoha', 'glinet,mt2500-emmc', 'glinet,gl-mt2500', 'glinet_gl-mt2500-airoha'], [1]: openwrt#1525 (comment) Fixes: openwrt#1525 Fixes: openwrt/openwrt#20566

They share the same "compatible" in device tree causing some incompatibilities (ASU profile identification), assign a unique "compatible" and "model" to each variant.[1][2] Commit [3] just avoided ASU profile identification limitation[4] but not fixed the root cause. [1]: openwrt#20632 (comment) [2]: openwrt#20632 (comment) [3]: openwrt@b71f466 [4]: openwrt/asu#1533 Fixes: b71f466 ("mediatek: filogic: fix supported_devices list for gl-mt2500") Fixes: 8d30e07 ("mediatek: filogic: fix for new GL.iNet GL-MT2500/GL-MT2500A hardware revision") Fixes: openwrt#20566 Fixes(partially): openwrt/asu#1525 Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com>

These devices share the same "compatible" in device tree causing some incompatibilities (sysupgrades, ASU profile identification), assign a unique "compatible" and "model" to each variant. Context: Commit [1] added each variant's dts compatible to the SUPPORTED_DEVICES field of the other variant to make easy sysupgrades between these physically indistinguishable devices variants possible. But there were found three issues which does not allow this: - the sysupgrade's stricter check still used in some sysupgrade paths(this check is being replaced(and redundant) with the newer fwtool's SUPPORTED_DEVICES check using the info in images METADATA), this check will fail when sysupgrading from a different board_name(compatible dts) that the image was created for (image profile name).[2] - ASU needs unique "dts compatible" to identify the devices profile. - and an ASU's profile identification limitation when several devices from a common target share SUPPORTED_DEVICES entries.[3] There is a proposal for these issues but not yet implemented [4][3]. Until these issues are fixed we won't allow "easy" sysupgrades between these two device variants. Commit [5] avoided the ASU profile identification limitation but missed the required two unique dts compatibles in order to make the two variants fully work, although not allowing easy sysupgrade between them. [1]: openwrt@8d30e07 [2]: sysupgrade stricter check openwrt#20566 (comment) [3]: ASU proposal openwrt/asu#1533 [4]: allow easy sysupgrade proposal openwrt#20947 [5]: openwrt@b71f466 Fixes: b71f466 ("mediatek: filogic: fix supported_devices list for gl-mt2500") Fixes: 8d30e07 ("mediatek: filogic: fix for new GL.iNet GL-MT2500/GL-MT2500A hardware revision") Fixes: openwrt#20566 Fixes: openwrt/asu#1525 Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com>

These devices share the same "compatible" in device tree causing some incompatibilities (sysupgrades, ASU profile identification), assign a unique "compatible" and "model" to each variant. Context: Commit [1] added each variant's dts compatible to the SUPPORTED_DEVICES field of the other variant to make easy sysupgrades between these physically indistinguishable devices variants possible. But there were found three issues which does not allow this: - the sysupgrade's stricter check still used in some sysupgrade paths(this check is being replaced(and redundant) with the newer fwtool's SUPPORTED_DEVICES check using the info in images METADATA), this check will fail when sysupgrading from a different board_name(compatible dts) that the image was created for (image profile name).[2] - ASU needs unique "dts compatible" to identify the devices profile. - and an ASU's profile identification limitation when several devices from a common target share SUPPORTED_DEVICES entries.[3] There is a proposal for these issues but not yet implemented [4][3]. Until these issues are fixed we won't allow "easy" sysupgrades between these two device variants. Commit [5] avoided the ASU profile identification limitation but missed the required two unique dts compatibles in order to make the two variants fully work, although not allowing easy sysupgrade between them. [1]: openwrt@8d30e07 [2]: sysupgrade stricter check openwrt#20566 (comment) [3]: ASU proposal openwrt/asu#1533 [4]: allow easy sysupgrade proposal openwrt#20947 [5]: openwrt@b71f466 Fixes: b71f466 ("mediatek: filogic: fix supported_devices list for gl-mt2500") Fixes: 8d30e07 ("mediatek: filogic: fix for new GL.iNet GL-MT2500/GL-MT2500A hardware revision") Fixes: openwrt#20566 Fixes: openwrt/asu#1525 Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com> Link: openwrt#21842 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

These devices share the same "compatible" in device tree causing some incompatibilities (sysupgrades, ASU profile identification), assign a unique "compatible" and "model" to each variant. Context: Commit [1] added each variant's dts compatible to the SUPPORTED_DEVICES field of the other variant to make easy sysupgrades between these physically indistinguishable devices variants possible. But there were found three issues which does not allow this: - the sysupgrade's stricter check still used in some sysupgrade paths(this check is being replaced(and redundant) with the newer fwtool's SUPPORTED_DEVICES check using the info in images METADATA), this check will fail when sysupgrading from a different board_name(compatible dts) that the image was created for (image profile name).[2] - ASU needs unique "dts compatible" to identify the devices profile. - and an ASU's profile identification limitation when several devices from a common target share SUPPORTED_DEVICES entries.[3] There is a proposal for these issues but not yet implemented [4][3]. Until these issues are fixed we won't allow "easy" sysupgrades between these two device variants. Commit [5] avoided the ASU profile identification limitation but missed the required two unique dts compatibles in order to make the two variants fully work, although not allowing easy sysupgrade between them. [1]: 8d30e07 [2]: sysupgrade stricter check #20566 (comment) [3]: ASU proposal openwrt/asu#1533 [4]: allow easy sysupgrade proposal #20947 [5]: b71f466 Fixes: b71f466 ("mediatek: filogic: fix supported_devices list for gl-mt2500") Fixes: 8d30e07 ("mediatek: filogic: fix for new GL.iNet GL-MT2500/GL-MT2500A hardware revision") Fixes: #20566 Fixes: openwrt/asu#1525 Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com> Link: #21842 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 7aa1f7e)

Revert "build-request: sanitize incoming "supported devices" list"

423489e

This reverts commit 1579236.

This was referenced Dec 4, 2025

Attended Sysupgrade OpenWrt 24.10.3 to 24.10.4 on GL-MT2500 #1525

Closed

Attended Sysupgrade and owut upgrade broken: invalid sysupgrade file openwrt/openwrt#20566

Closed

mediatek: filogic: gl-mt2500 fix compatibles openwrt/openwrt#20947

Open

map-b commented Dec 5, 2025

View reviewed changes

map-b added 2 commits December 5, 2025 21:08

Revert "build-request: sanitize profile before use"

d7fd828

This reverts commit 2e9edfd.

map-b force-pushed the improve-supported-devices-handling branch from 96024c1 to e8bf73f Compare December 5, 2025 20:11

map-b mentioned this pull request Dec 26, 2025

asu: revert sanitize #1554

Closed

map-b mentioned this pull request Jan 19, 2026

realtek: add Zyxel GS1900-24 B1 openwrt/openwrt#21595

Merged

map-b mentioned this pull request Feb 2, 2026

mediatek: filogic: fix supported_devices list for gl-mt2500 openwrt/openwrt#20632

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

profiles: improve SUPPORTED_DEVICES handling and profile identification#1533

profiles: improve SUPPORTED_DEVICES handling and profile identification#1533
map-b wants to merge 3 commits intoopenwrt:mainfrom
map-b:improve-supported-devices-handling

map-b commented Dec 4, 2025

Uh oh!

efahl commented Dec 5, 2025

Uh oh!

map-b commented Dec 5, 2025

Uh oh!

map-b Dec 5, 2025 •

edited

Loading

Uh oh!

map-b Dec 5, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

map-b commented Dec 4, 2025

Footnotes

Uh oh!

efahl commented Dec 5, 2025

Uh oh!

map-b commented Dec 5, 2025

Uh oh!

map-b Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

map-b Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

map-b Dec 5, 2025 •

edited

Loading