Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deduplication is too greedy #32

Open
Florob opened this issue May 19, 2023 · 1 comment
Open

Deduplication is too greedy #32

Florob opened this issue May 19, 2023 · 1 comment

Comments

@Florob
Copy link

Florob commented May 19, 2023

The current deduplication algorithm is too greedy, at least with respect to fieldsets. The equivalence check currently ignores field names and descriptions, leading to arguably incorrect results.

E.g. looking at the imxrt1061 CCM (which is its own module) many fieldsets are taken from the imxrt1015 definition. The result is that multiple existing clock gates are documented as "Reserved".

The concrete case I stumbled over was that on imxrt106x FLEXIO2_CLK_PRED and FLEXIO2_CLK_PODF don't exist. Instead these fields are called FLEXIO1_CLK_PRED/FLEXIO1_CLK_PODF. I.e. these fields names exist twice on two different registers. This is incorrect on imxrt106x, even though it is correct in the SVD.

@mciantyre
Copy link
Member

Good find. Correcting the greedy combination of fieldsets seems to be straightforward; see #33. Greedy enum variant combinations are a larger problem, as it results in both incorrect Rust symbols and incorrect documentation. I'm pondering fixes for both in the other linked PRs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants