-
-
Notifications
You must be signed in to change notification settings - Fork 172
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
PCI: Use u8 as in the spec, add port docs #827
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks pretty good! I'm not sure why we were using u16
s instead of u8
s in the first place.
One request -- I'm not sure how I feel about #825, I may not merge that in yet. But the changes from commit 815484f are generally good, and also independent from #825. So let's keep this PR strictly about u16
--> u8
such that we can address #825 separately.
Basically, please remove all changes related to #825, e.g., the determine_mem_base
and BaseAddress
thing.
About #825: I guess you mean that the API for getting the base address is bad? I have more changes to come so it will not stay that way and I can read up on pci BARs to find out if returning an enum is sensible |
815484f
to
eb83c64
Compare
eb83c64
to
59118f7
Compare
Sorry for the second force-push, now it should be good though. The docs are better too now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, everything looks good now.
* No change in functionality -- just adhering to PCI spec. Co-authored-by: Kevin Boos <[email protected]> 346a116
* No change in functionality -- just adhering to PCI spec. Co-authored-by: Kevin Boos <[email protected]> 346a116
Please merge after #825.
I'm unsure if this is the right way to, like, do a follow-up PR?
I guess if the content is unrelated, I can start a completely different branch..
would be wild if one could specify that this PR depends on the previous one being done (which is very natural, similar to the git branch concept)