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"
<sandals@xxxxxxxxxxxxxxxxxxxx> 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
