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

Device map addresses proposal #8

Open
aacuevas opened this issue Feb 24, 2024 · 1 comment
Open

Device map addresses proposal #8

aacuevas opened this issue Feb 24, 2024 · 1 comment

Comments

@aacuevas
Copy link

Ported from jonnew/ONI#8

Original text:

Currently device map addresses are set as
Reserved(16).HubIdx(8).DevIdx(8)

However, it might make more sense to redefine those as HubIdx(16).DevIdx(16) even if not all implementations are able to use the full address range (for example, ONIX current implementation is limited to 8bit dev indexes).

To retain compatibility across devices, the special device IDs could be defined as such:
-Invalid device: DevIdx is all binary ones
-HUB control device: DevIdx is Invalid device - 1 (all ones except LSB)

A specific implementation able only to use a subset of the ranges would perform automatic bit expansion/trimming when translating addresses to the 32-bit interface defined by the standard.

@aacuevas
Copy link
Author

Limits on max devices per hub and max hubs per host should be informed to the software layer through the capabilities registers suggested on #6

The main issue is, this breaks compatibility with existing hardware, as it sends the map in the rsv.rsv.hub.dev format, but I believe it's worth it for future-proofing the spec. We could require a fw update to comply with the spec or we could create a "legacy" version of the onidrivers that handle this case, for existing hardware. A discussion is warranted.

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

1 participant