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]>
---
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(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 282d0bc14e8e..a3a257089696 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -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:
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 7ac72804e285..7a136af3148c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -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),
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
index d1037b6ef2d6..c6c4be05159d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -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
On January 26, 2020 8:34:18 PM "brian m. carlson"
<[email protected]> wrote:
> 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
On 2020-01-26 at 21:12:02, Arend Van Spriel wrote:
> On January 26, 2020 8:34:18 PM "brian m. carlson"
> <[email protected]> wrote:
>
> > 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.
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.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
On 1/27/2020 12:00 AM, brian m. carlson wrote:
> On 2020-01-26 at 21:12:02, Arend Van Spriel wrote:
>> On January 26, 2020 8:34:18 PM "brian m. carlson"
>> <[email protected]> wrote:
>>
>>> 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.
>
> 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.
I think you are right provided they use it on the same system they acquired.
> 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.
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
On 2020-01-28 at 09:47:37, Arend Van Spriel wrote:
> On 1/27/2020 12:00 AM, brian m. carlson wrote:
> > 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.
>
> 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.
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.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Arend Van Spriel <[email protected]> writes:
>> 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.
>
> 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.
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 :)
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On 1/29/2020 4:02 PM, Kalle Valo wrote:
> Arend Van Spriel <[email protected]> writes:
>
>>> 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.
>>
>> 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.
>
> 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
"brian m. carlson" <[email protected]> wrote:
> 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
--
https://patchwork.kernel.org/patch/11351949/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches