brcmfmac: add the BRCM 4364 found in MacBook Pro 15,2
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH v2 1/1 brcmfmac: add the BRCM 4364 found in MacBook Pro 15,2
The 2018 13" MacBook Pro (MacBookPro15,2) has a Broadcom chip, the 4364. This chip appears to be specific to Apple and is not found in other hardware.
Add this chip to the brcmfmac driver so that it can be recognized automatically. Note that the PCI device id is 4464 even though the chip is referred to as the 4364.
---
Changes from v1:
* Base off wireless-drivers-next instead of Linus's master.
--- drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 1 + drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 3 +++ drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 2 ++ 3 files changed, 6 insertions(+)
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c +1 -0
@@ -723,6 +723,7 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv *ci)return 0x200000 ;case BRCM_CC_4359_CHIP_ID :return (ci->pub.chiprev <9 ) ?0x180000 :0x160000 ; +case BRCM_CC_4364_CHIP_ID :case CY_CC_4373_CHIP_ID :return 0x160000 ;default :
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +3 -0
@@ -52,6 +52,7 @@ BRCMF_FW_DEF(4356, "brcmfmac4356-pcie");BRCMF_FW_DEF (43570 ,"brcmfmac43570-pcie" );BRCMF_FW_DEF (4358 ,"brcmfmac4358-pcie" );BRCMF_FW_DEF (4359 ,"brcmfmac4359-pcie" ); +BRCMF_FW_DEF (4364 ,"brcmfmac4364-pcie" );BRCMF_FW_DEF (4365B ,"brcmfmac4365b-pcie" ); BRCMF_FW_DEF(4365C, "brcmfmac4365c-pcie");BRCMF_FW_DEF (4366B ,"brcmfmac4366b-pcie" );
@@ -70,6 +71,7 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {BRCMF_FW_ENTRY (BRCM_CC_43570_CHIP_ID ,0xFFFFFFFF ,43570 ),BRCMF_FW_ENTRY (BRCM_CC_4358_CHIP_ID ,0xFFFFFFFF ,4358 ),BRCMF_FW_ENTRY (BRCM_CC_4359_CHIP_ID ,0xFFFFFFFF ,4359 ), +BRCMF_FW_ENTRY (BRCM_CC_4364_CHIP_ID ,0xFFFFFFFF ,4364 ),BRCMF_FW_ENTRY (BRCM_CC_4365_CHIP_ID ,0x0000000F ,4365B ), BRCMF_FW_ENTRY(BRCM_CC_4365_CHIP_ID, 0xFFFFFFF0, 4365C), BRCMF_FW_ENTRY(BRCM_CC_4366_CHIP_ID, 0x0000000F, 4366B),
@@ -2105,6 +2107,7 @@ static const struct pci_device_id brcmf_pcie_devid_table[] = {BRCMF_PCIE_DEVICE (BRCM_PCIE_43602_2G_DEVICE_ID ),BRCMF_PCIE_DEVICE (BRCM_PCIE_43602_5G_DEVICE_ID ),BRCMF_PCIE_DEVICE (BRCM_PCIE_43602_RAW_DEVICE_ID ), +BRCMF_PCIE_DEVICE (BRCM_PCIE_4364_DEVICE_ID ),BRCMF_PCIE_DEVICE (BRCM_PCIE_4365_DEVICE_ID ),BRCMF_PCIE_DEVICE (BRCM_PCIE_4365_2G_DEVICE_ID ), BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_5G_DEVICE_ID),
drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h +2 -0
@@ -44,6 +44,7 @@#define BRCM_CC_4358_CHIP_ID 0x4358#define BRCM_CC_4359_CHIP_ID 0x4359#define BRCM_CC_43602_CHIP_ID 43602 +#define BRCM_CC_4364_CHIP_ID 0x4364#define BRCM_CC_4365_CHIP_ID 0x4365#define BRCM_CC_4366_CHIP_ID 0x4366#define BRCM_CC_43664_CHIP_ID 43664
@@ -74,6 +75,7 @@#define BRCM_PCIE_43602_2G_DEVICE_ID 0x43bb#define BRCM_PCIE_43602_5G_DEVICE_ID 0x43bc#define BRCM_PCIE_43602_RAW_DEVICE_ID 43602 +#define BRCM_PCIE_4364_DEVICE_ID 0x4464#define BRCM_PCIE_4365_DEVICE_ID 0x43ca#define BRCM_PCIE_4365_2G_DEVICE_ID 0x43cb#define BRCM_PCIE_4365_5G_DEVICE_ID 0x43cc
Arend Van Spriel
maintainerQuoted 7 lines · brian m. carlson
The 2018 13" MacBook Pro (MacBookPro15,2) has a Broadcom chip, the 4364. This chip appears to be specific to Apple and is not found in other hardware.
Add this chip to the brcmfmac driver so that it can be recognized automatically. Note that the PCI device id is 4464 even though the chip is referred to as the 4364.
So what is the plan regarding firmware. In the previous patch you mentioned it can be copied from macos, but I am not sure if that is acceptable from legal perspective. At least Linux distributions will have problem with that for sure.
Regards,
Arend
Quoted 7 lines · Arend Van Spriel
Quoted 4 lines · brian m. carlson
The 2018 13" MacBook Pro (MacBookPro15,2) has a Broadcom chip, the 4364. This chip appears to be specific to Apple and is not found in other hardware.
Quoted 8 lines
Quoted 3 lines
Add this chip to the brcmfmac driver so that it can be recognized automatically. Note that the PCI device id is 4464 even though the chip is referred to as the 4364.
So what is the plan regarding firmware. In the previous patch you mentioned it can be copied from macos, but I am not sure if that is acceptable from legal perspective. At least Linux distributions will have problem with that for sure.
I don't have a way to solve that problem. The firmware copyright presumably belongs to Broadcom and they would be able to grant that permission or ship firmware through the normal channels.
As far as I know, this chip only comes with Apple systems, so users will acquire the system with macOS. I'm not aware of any legal reason that a user cannot copy the firmware from one location on their hard disk to another, so users will probably be able to legally use the firmware, even if it's not shipped with distros.
There is also precedent for users acquiring firmware themselves via the b43 and b43legacy drivers, where users have to use a script to extract the firmware from other drivers.
I wish I had a better answer to this, but I don't work for Broadcom or anyone associated with it and am just trying to get the Mac I was given for $DAYJOB to work with Linux. Perhaps since you do you'd be willing to ask them to release the firmware.
The alternative is that the chip doesn't work at all (and can't be added via the new_id sysfs entry because of the rambase setting) and users have to compile a custom patched kernel to make their wireless card work at all. I'd really prefer to avoid that if possible, since it's a strictly worse experience in every way.
Signature · 2 lines
brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Arend Van Spriel
maintainerQuoted 21 lines · brian m. carlson
Quoted 7 lines · Arend Van Spriel
Quoted 4 lines · brian m. carlson
The 2018 13" MacBook Pro (MacBookPro15,2) has a Broadcom chip, the 4364. This chip appears to be specific to Apple and is not found in other hardware.
Quoted 8 lines
Quoted 3 lines
Add this chip to the brcmfmac driver so that it can be recognized automatically. Note that the PCI device id is 4464 even though the chip is referred to as the 4364.
So what is the plan regarding firmware. In the previous patch you mentioned it can be copied from macos, but I am not sure if that is acceptable from legal perspective. At least Linux distributions will have problem with that for sure.
I don't have a way to solve that problem. The firmware copyright presumably belongs to Broadcom and they would be able to grant that permission or ship firmware through the normal channels.
Quoted 5 lines
As far as I know, this chip only comes with Apple systems, so users will acquire the system with macOS. I'm not aware of any legal reason that a user cannot copy the firmware from one location on their hard disk to another, so users will probably be able to legally use the firmware, even if it's not shipped with distros.
I think you are right provided they use it on the same system they acquired.
Quoted 9 lines
There is also precedent for users acquiring firmware themselves via the b43 and b43legacy drivers, where users have to use a script to extract the firmware from other drivers.
I wish I had a better answer to this, but I don't work for Broadcom or anyone associated with it and am just trying to get the Mac I was given for $DAYJOB to work with Linux. Perhaps since you do you'd be willing to ask them to release the firmware.
Quoted 5 lines
The alternative is that the chip doesn't work at all (and can't be added via the
new_idsysfs entry because of the rambase setting) and users have to compile a custom patched kernel to make their wireless card work at all. I'd really prefer to avoid that if possible, since it's a strictly worse experience in every way.
How about putting this device under some Kconfig flag. If distro kernel start probing the device and fail, most users will probably turn to their distro for help. Having a Kconfig with a good description could avoid that. It would mean an extra step of building the driver though.
Regards,
Arend
Quoted 16 lines · Arend Van Spriel
Quoted 9 lines · brian m. carlson
There is also precedent for users acquiring firmware themselves via the b43 and b43legacy drivers, where users have to use a script to extract the firmware from other drivers.
I wish I had a better answer to this, but I don't work for Broadcom or anyone associated with it and am just trying to get the Mac I was given for $DAYJOB to work with Linux. Perhaps since you do you'd be willing to ask them to release the firmware.
Quoted 5 lines
The alternative is that the chip doesn't work at all (and can't be added via the
new_idsysfs entry because of the rambase setting) and users have to compile a custom patched kernel to make their wireless card work at all. I'd really prefer to avoid that if possible, since it's a strictly worse experience in every way.
Quoted 4 lines
How about putting this device under some
Kconfigflag. If distro kernel start probing the device and fail, most users will probably turn to their distro for help. Having aKconfigwith a good description could avoid that. It would mean an extra step of building the driver though.
I can certainly do that. I don't think it provides a lot of value, since the only benefit I see is that it avoids warning about missing firmware that the distro can't ship. A typical Debian system currently warns about missing firmware for numerous other drivers (e.g., i915) at the moment without ill consequences.
But if you'd prefer it that way, I can provide a v3 that does that.
Signature · 2 lines
brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Quoted 15 lines · Arend Van Spriel
Quoted 9 lines
There is also precedent for users acquiring firmware themselves via the b43 and b43legacy drivers, where users have to use a script to extract the firmware from other drivers.
I wish I had a better answer to this, but I don't work for Broadcom or anyone associated with it and am just trying to get the Mac I was given for $DAYJOB to work with Linux. Perhaps since you do you'd be willing to ask them to release the firmware.
Quoted 5 lines
The alternative is that the chip doesn't work at all (and can't be added via the
new_idsysfs entry because of the rambase setting) and users have to compile a custom patched kernel to make their wireless card work at all. I'd really prefer to avoid that if possible, since it's a strictly worse experience in every way.
Quoted 5 lines
How about putting this device under some
Kconfigflag. If distro kernel start probing the device and fail, most users will probably turn to their distro for help. Having aKconfigwith a good description could avoid that. It would mean an extra step of building the driver though.
I don't understand the issue you are trying to solve. If the firmware image is missing there's a clear error message in the log and the kernel continues to operate normally, right? That way users have a clear understanding why their wireless is not working, and hopefully push Broadcom to release the firmware with a suitable license :)
Signature · 1 line
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Arend Van Spriel
maintainerQuoted 23 lines · Kalle Valo
Quoted 15 lines · Arend Van Spriel
Quoted 9 lines
There is also precedent for users acquiring firmware themselves via the b43 and b43legacy drivers, where users have to use a script to extract the firmware from other drivers.
I wish I had a better answer to this, but I don't work for Broadcom or anyone associated with it and am just trying to get the Mac I was given for $DAYJOB to work with Linux. Perhaps since you do you'd be willing to ask them to release the firmware.
Quoted 5 lines
The alternative is that the chip doesn't work at all (and can't be added via the
new_idsysfs entry because of the rambase setting) and users have to compile a custom patched kernel to make their wireless card work at all. I'd really prefer to avoid that if possible, since it's a strictly worse experience in every way.Quoted 5 lines
How about putting this device under some
Kconfigflag. If distro kernel start probing the device and fail, most users will probably turn to their distro for help. Having aKconfigwith a good description could avoid that. It would mean an extra step of building the driver though.
Quoted 5 lines
I don't understand the issue you are trying to solve. If the firmware image is missing there's a clear error message in the log and the kernel continues to operate normally, right? That way users have a clear understanding why their wireless is not working, and hopefully push Broadcom to release the firmware with a suitable license :)
Hi Kalle,
Actually as there is precedent of firmwareless drivers in distros I am fine with the change as is.
Regards,
Arend
Quoted 9 lines · brian m. carlson
The 2018 13" MacBook Pro (MacBookPro15,2) has a Broadcom chip, the 4364. This chip appears to be specific to Apple and is not found in other hardware.
Add this chip to the brcmfmac driver so that it can be recognized automatically. Note that the PCI device id is 4464 even though the chip is referred to as the 4364.
Signed-off-by brian m. carlson <[email protected]>
Patch applied to wireless-drivers-next.git, thanks.
24f0bd136264 brcmfmac: add the BRCM 4364 found in MacBook Pro 15,2
Signature · 3 lines
https://patchwork.kernel.org/patch/11351949/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches