mbox series

[v1,0/3] Add AP6275P wireless support

Message ID 20240620020015.4021696-1-jacobe.zang@wesion.com
Headers show
Series Add AP6275P wireless support | expand

Message

Jacobe Zang June 20, 2024, 2 a.m. UTC
These add AP6275P wireless support on Khadas Edge2. Enable 32k clock 
for Wi-Fi module and extend the hardware IDs table in the brcmfmac 
driver for it to attach.

Jacobe Zang (3):
  arm64: dts: rockchip: Add AP6275P wireless support to Khadas Edge 2
  net: wireless: brcmfmac: Add optional 32k clock enable support
  net: wireless: brcmfmac: Add support for AP6275P

 .../boot/dts/rockchip/rk3588s-khadas-edge2.dts   | 16 ++++++++++++++++
 .../wireless/broadcom/brcm80211/brcmfmac/pcie.c  | 15 ++++++++++++++-
 .../broadcom/brcm80211/include/brcm_hw_ids.h     |  2 ++
 3 files changed, 32 insertions(+), 1 deletion(-)

Comments

Arend Van Spriel June 22, 2024, 10:59 a.m. UTC | #1
On 6/22/2024 2:22 AM, Ondřej Jirman wrote:
> On Thu, Jun 20, 2024 at 10:00:15AM GMT, Jacobe Zang wrote:
>> This module features BCM43752A2 chipset. The firmware requires
>> randomness seeding, so enabled it.
> 
> Any reason to strip info about origin of the patch, my SoB and
> present this work as your own?
> 
> Original patch here https://megous.com/git/linux/commit/?h=ap6275p-6.10&id=1a99573bc8ed412e60e1969c0b29d53a0e5782e0
> 
> regards,
> 	o.
> 
>> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com>

I sincerely hope this is just a rookie mistake so please carefully read 
the URL below:

https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Hope it helps.

Regards,
Arend

>> ---
>>   drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c      | 5 ++++-
>>   .../net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h    | 2 ++
>>   2 files changed, 6 insertions(+), 1 deletion(-)
Arend Van Spriel June 23, 2024, 5:34 a.m. UTC | #2
On June 23, 2024 4:21:46 AM Jacobe Zang <jacobe.zang@wesion.com> wrote:

>> Any reason to strip info about origin of the patch, my SoB and
>> present this work as your own?
>
> Sincerely express my apology to Ondrej. It's really my mistake. After 
> getting your permission if I could submit the patches. I jsut think if the 
> author and submitter is not the same person is strange so I changed it. 
> Next tiem I will avoid this mistake. Apologize again.
>
>
>> I sincerely hope this is just a rookie mistake so please carefully read
> the URL below:
>
>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>
> Thanks for the guidance Arend. After reading the document I realized what a 
> stupid mistake I made.
>
> BTW I have another question, except the SoB of the real author, should I 
> also post the original link in commit message?

Not really necessary. You may if you think that it's useful. Always add 
your SoB and keep SoB tags present untouched.

Regards,
Arend
Ondřej Jirman June 23, 2024, 8:01 a.m. UTC | #3
Hi Jacobe,

On Sun, Jun 23, 2024 at 02:21:39AM GMT, Jacobe Zang wrote:
> > Any reason to strip info about origin of the patch, my SoB and
> > present this work as your own?
> 
> Sincerely express my apology to Ondrej. It's really my mistake. After getting
> your permission if I could submit the patches. I jsut think if the author and
> submitter is not the same person is strange so I changed it. Next tiem I will
> avoid this mistake. Apologize again.
> 
> 
> > I sincerely hope this is just a rookie mistake so please carefully read
> the URL below:
> 
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> 
> Thanks for the guidance Arend. After reading the document I realized what a stupid mistake I made.
> 
> BTW I have another question, except the SoB of the real author, should I also post the original link in commit message?

I suggest keeping at least this part:

> Partially copied from https://lore.kernel.org/all/c7b331edd65b66521a6605177d654e55051568a3.camel@toradex.com/
> 
> (No Signed-off-by provided in the email. The code looks like some
> data copied probably from a vendor driver and adapted for the upstream
> one.)

I'm not the complete author of the patch either. I just figured out why
just adding device/chip IDs was not enough compared to what Marcel Ziswiler
tried and expanded the patch from his email, to make it work.

People using baords with AP6275P (eg. I did my debugging on QuartzPro64) will
also be interested in how to get the firmware for AP6275P, and there are some
hints for that in the above link, too. (FW filename that is in the patch for the
driver doesn't match FW name as distributed by eg. SparkLAN, which makes it
harder to find it just based on FW name from the code)

Although it would be nice to have the firmware available in linux-firmware.

Kind regards,
	o.

> ---
> Best Regards
> Jacobe
Jacobe Zang June 23, 2024, 10:11 a.m. UTC | #4
> Although it would be nice to have the firmware available in linux-firmware.

I think this is a better idea. If we get details from what linux-firmware installed we can found that it has already include the brcm firmware. Only different models from AP6275P. 


---
Best Regards
Jacobe