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

linux: enable CONFIG_BT_HCIUART_BCM #322964

Merged
merged 1 commit into from
Jun 30, 2024
Merged

linux: enable CONFIG_BT_HCIUART_BCM #322964

merged 1 commit into from
Jun 30, 2024

Conversation

paepckehh
Copy link
Contributor

Description of changes

Add linux kernel support for Broadcom Bluetooth HCI_SERIAL Interface. This will unlock on-board Bluetooth for some 2016-2019 Apple Intel Hardware Series (iMac, MacBookAir, MacBookPro), tested on MacBookPro14,1 - add some comments, reorg

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

Add linux kernel support for Broadcom Bluetooth HCI_SERIAL Interface.  This will unlock on-board Bluetooth for some 2016-2019 Apple Intel Hardware Series (iMac, MacBookAir, MacBookPro) - tested on MacBookPro14,1
@hraban
Copy link
Member

hraban commented Jun 27, 2024

This seems like a pretty heavy rebuild load for a merge into master. I have a feeling this would be better off going into staging, unless you chose master deliberately?

@hraban
Copy link
Member

hraban commented Jun 27, 2024

Search this page for the term "staging" for more information on the distinction between the two: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md

It also contains important instructions on how to rebase (not the usual way!) to avoid a mass ping of all contributors.

@paepckehh
Copy link
Contributor Author

To avoid to mess-up a re-base, I closed (without further notice / silently) directly the first PR, after the request to re-write the commit message arrived.

Thank you for your (kind) support - and the tip with the staging branch! (Next PR will definitely go there first. But I will RTFM first.)

@hraban
Copy link
Member

hraban commented Jun 27, 2024

To avoid to mess-up a re-base, I closed (without further notice / silently) directly the first PR, after the request to re-write the commit message arrived.

Thank you for your (kind) support - and the tip with the staging branch! (Next PR will definitely go there first. But I will RTFM first.)

I don't know what happened in another PR so forgive me if this was covered but what I'm trying to say is: this PR won't get accepted into master, it should be moved into staging , as per the contribution guidelines. It causes too many rebuilds to go into master.

@Aleksanaa Aleksanaa changed the base branch from master to staging June 27, 2024 18:42
@paepckehh
Copy link
Contributor Author

Fixed. Thank you for you patience! ( same with similar PR: #322968 )

Copy link
Contributor

@drupol drupol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Diff LGTM

@Mic92
Copy link
Member

Mic92 commented Jun 29, 2024

To avoid to mess-up a re-base, I closed (without further notice / silently) directly the first PR, after the request to re-write the commit message arrived.
Thank you for your (kind) support - and the tip with the staging branch! (Next PR will definitely go there first. But I will RTFM first.)

I don't know what happened in another PR so forgive me if this was covered but what I'm trying to say is: this PR won't get accepted into master, it should be moved into staging , as per the contribution guidelines. It causes too many rebuilds to go into master.

In general yes, not quite true for kernel changes we merge to master usually. Yes it's 5000 package changes but it's mostly kernel modules, the expensive part is building the kernels of which we don't have too many and the kernel modules after that build relatively quick. So in future you can keep kernel changes on master as it makes things easier to test

@hraban
Copy link
Member

hraban commented Jun 29, 2024

To avoid to mess-up a re-base, I closed (without further notice / silently) directly the first PR, after the request to re-write the commit message arrived.
Thank you for your (kind) support - and the tip with the staging branch! (Next PR will definitely go there first. But I will RTFM first.)

I don't know what happened in another PR so forgive me if this was covered but what I'm trying to say is: this PR won't get accepted into master, it should be moved into staging , as per the contribution guidelines. It causes too many rebuilds to go into master.

In general yes, not quite true for kernel changes we merge to master usually. Yes it's 5000 package changes but it's mostly kernel modules, the expensive part is building the kernels of which we don't have too many and the kernel modules after that build relatively quick. So in future you can keep kernel changes on master as it makes things easier to test

Thanks @Mic92 , sorry @paepckehh I wasn't aware of this :)

@paepckehh
Copy link
Contributor Author

No problem, always happy to learn new stuff (hydra & your staging process).

Should I manually switch back both kern-conf changes from the staging path (stalled anyway there?) to master - for progress?

@Mic92
Copy link
Member

Mic92 commented Jun 30, 2024

It's ok. I have staging now cached on my machine and can test the building kernels now anyhow.
This is what I run:

nix-review pr 322964 --package-regex 'linuxPackages.*kernel'

@wegank wegank added the 12.approvals: 1 This PR was reviewed and approved by one reputable person label Jun 30, 2024
@Mic92 Mic92 merged commit 06c0912 into NixOS:staging Jun 30, 2024
30 checks passed
@jottr
Copy link

jottr commented Aug 22, 2024

Can this be backported to 24.05?

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

Successfully merging this pull request may close these issues.

6 participants