linux: enable CONFIG_BT_HCIUART_BCM

[paepckehh]

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:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• 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.

[hraban]

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]

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]

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]

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.

[paepckehh]

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

[drupol]

Diff LGTM

[Mic92]

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]

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]

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]

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'

[jottr]

Can this be backported to 24.05?