[PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Gianfranco Costamagna]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

(resending from my debian.org mail address, to avoid spam filtering)

Hi Broadcom developers and linux wireless list.

We found a possible issue in the cfg80211 implementation of the regulatory domain rules:

        .reg_rules = {
                /* IEEE 802.11b/g, channels 1..11 */
                REG_RULE(2412-10, 2472+10, 40, 6, 20, 0),


the referred channel 11 has/should have a frequency of 2462, not 2472 (corresponding to channel 13).
Is this a typo in the code or the above comment?

(I'm not sure why the override of reg.c is in place for 2.4 Ghz frequencies)

Can you please double check and in case apply the attached patch?

thanks,
-- 

Gianfranco Costamagna

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-broadcom-cfg80211-fix-regulatory-channel-frequency.patch --]
[-- Type: text/x-diff, Size: 1248 bytes --]

From dc2eaeba8cf3d992a18745cfef1b74bbfc11715b Mon Sep 17 00:00:00 2001
From: Arlone Marco <marco.arlone@roj.com>
Date: Sat, 22 Oct 2016 15:08:35 +0200
Subject: [PATCH] broadcom cfg80211: fix regulatory channel frequency channel
 11 is actually 2462, not 2472 (that is channel 13 instead)

Signed-off-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>
Signed-off-by: Arlone Marco <marco.arlone@roj.com>
Signed-off-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>

---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b777e1b..d71f959 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -204,7 +204,7 @@ static const struct ieee80211_regdomain brcmf_regdom = {
 	.alpha2 =  "99",
 	.reg_rules = {
 		/* IEEE 802.11b/g, channels 1..11 */
-		REG_RULE(2412-10, 2472+10, 40, 6, 20, 0),
+		REG_RULE(2412-10, 2462+10, 40, 6, 20, 0),
 		/* If any */
 		/* IEEE 802.11 channel 14 - Only JP enables
 		 * this and for 802.11b only
-- 
2.7.4

Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Arend Van Spriel]

On 28-10-2016 18:15, Gianfranco Costamagna wrote:
> (resending from my debian.org mail address, to avoid spam filtering)
> 
> Hi Broadcom developers and linux wireless list.
> 
> We found a possible issue in the cfg80211 implementation of the regulatory domain rules:
> 
>         .reg_rules = {
>                 /* IEEE 802.11b/g, channels 1..11 */
>                 REG_RULE(2412-10, 2472+10, 40, 6, 20, 0),
> 
> 
> the referred channel 11 has/should have a frequency of 2462, not 2472 (corresponding to channel 13).
> Is this a typo in the code or the above comment?
> 
> (I'm not sure why the override of reg.c is in place for 2.4 Ghz frequencies)
> 
> Can you please double check and in case apply the attached patch?

checking.... stay tuned.

Regards,
Arend

Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Arend Van Spriel]

On 28-10-2016 22:41, Arend Van Spriel wrote:
> On 28-10-2016 18:15, Gianfranco Costamagna wrote:
>> (resending from my debian.org mail address, to avoid spam filtering)
>>
>> Hi Broadcom developers and linux wireless list.
>>
>> We found a possible issue in the cfg80211 implementation of the regulatory domain rules:
>>
>>         .reg_rules = {
>>                 /* IEEE 802.11b/g, channels 1..11 */
>>                 REG_RULE(2412-10, 2472+10, 40, 6, 20, 0),
>>
>>
>> the referred channel 11 has/should have a frequency of 2462, not 2472 (corresponding to channel 13).
>> Is this a typo in the code or the above comment?
>>
>> (I'm not sure why the override of reg.c is in place for 2.4 Ghz frequencies)
>>
>> Can you please double check and in case apply the attached patch?
> 
> checking.... stay tuned.

Hi Gianfranco,

Finally response. As it turns out the range was explcitly changed
enabling channels 12 and 13 to be used where applicable. They forgot to
update the comment.

Regards,
Arend

Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Gianfranco Costamagna]

Hi Arend,


>Finally response. As it turns out the range was explcitly changed

>enabling channels 12 and 13 to be used where applicable. They forgot to
>update the comment.


so, the struct in net/wireless/reg.c is actually used in that case?

static const struct ieee80211_regdomain world_regdom = {

do you plan to update the comment?

thanks!

Gianfranco

Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Arend Van Spriel]

On 14-11-2016 12:34, Gianfranco Costamagna wrote:
> Hi Arend,
> 
> 
>> Finally response. As it turns out the range was explcitly changed
> 
>> enabling channels 12 and 13 to be used where applicable. They forgot to
>> update the comment.
> 
> 
> so, the struct in net/wireless/reg.c is actually used in that case?
> 
> static const struct ieee80211_regdomain world_regdom = {
> 
> do you plan to update the comment?

Well, not before you pointed it out ;-). You are welcome to send a patch
fixing it. Otherwise, I will take care of it.

Regards,
Arend

Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Gianfranco Costamagna]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

Hi Arend,



>Well, not before you pointed it out ;-). You are welcome to send a patch
>fixing it. Otherwise, I will take care of it.


attaching a format-patch like version.
I don't think we need a Tested-by or whatever, because it is just a typo in a comment.
(this is my first contribution, feel free to rebase or change whatever you prefer
to make it in line with other styles)

(I gave authorship to Marco, the first one who discovered such typo)

thanks!

G.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-cfg80211-fix-typo-in-REG-channel-frequency-comment.patch --]
[-- Type: text/x-diff, Size: 1229 bytes --]

From bf0cdd8ad27833639447a3071d662f79a7219b1d Mon Sep 17 00:00:00 2001
From: Arlone Marco <marco.arlone@roj.com>
Date: Sat, 22 Oct 2016 15:08:35 +0200
Subject: [PATCH] broadcom cfg80211: fix typo in REG channel frequency comment

frequency 2472 corresponds to channel 13, not channel 11

Signed-off-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>
Signed-off-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>
Signed-off-by: Arlone Marco <marco.arlone@roj.com>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b777e1b..b4d8b1b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -203,7 +203,7 @@ static const struct ieee80211_regdomain brcmf_regdom = {
 	.n_reg_rules = 4,
 	.alpha2 =  "99",
 	.reg_rules = {
-		/* IEEE 802.11b/g, channels 1..11 */
+		/* IEEE 802.11b/g, channels 1..13 */
 		REG_RULE(2412-10, 2472+10, 40, 6, 20, 0),
 		/* If any */
 		/* IEEE 802.11 channel 14 - Only JP enables
-- 
2.7.4

Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Kalle Valo]

Gianfranco Costamagna <locutusofborg@debian.org> writes:

>> Well, not before you pointed it out ;-). You are welcome to send a patch
>> fixing it. Otherwise, I will take care of it.
>
> attaching a format-patch like version.
> I don't think we need a Tested-by or whatever, because it is just a typo in a comment.
> (this is my first contribution, feel free to rebase or change whatever you prefer
> to make it in line with other styles)
>
> (I gave authorship to Marco, the first one who discovered such typo)

[...]

> Signed-off-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>
> Signed-off-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>
> Signed-off-by: Arlone Marco <marco.arlone@roj.com>

Please note that you cannot add Signed-off-by for other people without
their explicit approval (see Documentation/SubmittingPatches). I don't
know if they did it in this case or not, but wanted to point out this
anyway.

-- 
Kalle Valo

Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Gianfranco Costamagna]

Hi,


> Signed-off-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>

> Signed-off-by: Arlone Marco <marco.arlone@roj.com>

>Please note that you cannot add Signed-off-by for other people without
>their explicit approval (see Documentation/SubmittingPatches). I don't
>know if they did it in this case or not, but wanted to point out this
>anyway.


The first signoff is myself, with the company email, the other two signoffs
are from: the author, and Nicola, who did work with me to test it
(even if a typo fix is not "testable").

Nicola, Marco, is it ok to add your two names in the signoff part?
(that was a verbal talk, I don't have anything written)

Gianfranco

RE: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Nicola Smaldone]

Tm8gcHJvYmxlbSBmb3IgbWUsIHRoYW5rcy4NCg0KTmljb2xhIFNNQUxET05F
DQp3d3cudGllcnJhdGVsZW1hdGljcy5jb20NCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IEdpYW5mcmFuY28gQ29zdGFtYWduYSBbbWFp
bHRvOmxvY3V0dXNvZmJvcmdAZGViaWFuLm9yZ10gDQpTZW50OiBtYXJ0ZWTD
rCAxNSBub3ZlbWJyZSAyMDE2IDE0OjE0DQpUbzogS2FsbGUgVmFsbyA8a3Zh
bG9AY29kZWF1cm9yYS5vcmc+DQpDYzogQXJlbmQgVmFuIFNwcmllbCA8YXJl
bmQudmFuc3ByaWVsQGJyb2FkY29tLmNvbT47IGJyY204MDIxMS1kZXYtbGlz
dEBicm9hZGNvbS5jb207IGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9y
ZzsgTmljb2xhIFNtYWxkb25lIDxuc21hbGRvbmVAdGllcnJhdGVsZW1hdGlj
cy5jb20+OyBNYXJjby5BcmxvbmVAcm9qLmNvbQ0KU3ViamVjdDogUmU6IFtQ
QVRDSF0gYnJvYWRjb20vYnJjbTgwMjExL2JyY21mbWFjL2NmZzgwMjExIGRy
aXZlciwgYmFkIHJlZ3VsYXRvcnkgZG9tYWluIGZyZXF1ZW5jeSB2YWx1ZQ0K
DQpIaSwNCg0KDQo+IFNpZ25lZC1vZmYtYnk6IE5pY29sYSBTbWFsZG9uZSA8
bmljb2xhLnNtYWxkb25lQHRpZXJyYXNlcnZpY2UuY29tPg0KDQo+IFNpZ25l
ZC1vZmYtYnk6IEFybG9uZSBNYXJjbyA8bWFyY28uYXJsb25lQHJvai5jb20+
DQoNCj5QbGVhc2Ugbm90ZSB0aGF0IHlvdSBjYW5ub3QgYWRkIFNpZ25lZC1v
ZmYtYnkgZm9yIG90aGVyIHBlb3BsZSB3aXRob3V0IA0KPnRoZWlyIGV4cGxp
Y2l0IGFwcHJvdmFsIChzZWUgRG9jdW1lbnRhdGlvbi9TdWJtaXR0aW5nUGF0
Y2hlcykuIEkgZG9uJ3QgDQo+a25vdyBpZiB0aGV5IGRpZCBpdCBpbiB0aGlz
IGNhc2Ugb3Igbm90LCBidXQgd2FudGVkIHRvIHBvaW50IG91dCB0aGlzIA0K
PmFueXdheS4NCg0KDQpUaGUgZmlyc3Qgc2lnbm9mZiBpcyBteXNlbGYsIHdp
dGggdGhlIGNvbXBhbnkgZW1haWwsIHRoZSBvdGhlciB0d28gc2lnbm9mZnMg
YXJlIGZyb206IHRoZSBhdXRob3IsIGFuZCBOaWNvbGEsIHdobyBkaWQgd29y
ayB3aXRoIG1lIHRvIHRlc3QgaXQgKGV2ZW4gaWYgYSB0eXBvIGZpeCBpcyBu
b3QgInRlc3RhYmxlIikuDQoNCk5pY29sYSwgTWFyY28sIGlzIGl0IG9rIHRv
IGFkZCB5b3VyIHR3byBuYW1lcyBpbiB0aGUgc2lnbm9mZiBwYXJ0Pw0KKHRo
YXQgd2FzIGEgdmVyYmFsIHRhbGssIEkgZG9uJ3QgaGF2ZSBhbnl0aGluZyB3
cml0dGVuKQ0KDQpHaWFuZnJhbmNvDQoKQ29uZmlkZW50aWFsaXR5IE5vdGlj
ZTogVGhpcyBtZXNzYWdlIChpbmNsdWRpbmcgYXR0YWNobWVudHMpIGlzIGEg
cHJpdmF0ZSBjb21tdW5pY2F0aW9uIHNvbGVseQ0KZm9yIHVzZSBvZiB0aGUg
aW50ZW5kZWQgcmVjaXBpZW50KHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50
ZW5kZWQgcmVjaXBpZW50KHMpIG9yIGJlbGlldmUgeW91DQpyZWNlaXZlZCB0
aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk
aWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSB0aGlzIG1lc3NhZ2UuIEFueQ0Kb3Ro
ZXIgdXNlLCByZXRlbnRpb24sIGRpc3NlbWluYXRpb24gb3IgY29weWluZyBp
cyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgYSB2aW9sYXRpb24gb2YgbGF3LA0K
aW5jbHVkaW5nIHRoZSBFbGVjdHJvbmljIENvbW11bmljYXRpb24gUHJpdmFj
eSBBY3Qgb2YgMTk4Ni4=

R: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Arlone Marco]

Tm8gcHJvYmxlbSBmb3IgbWUsIGFsc28uDQoNCk1hcmNvIEFybG9uZQ0KDQotLS0tLU1lc3Nh
Z2dpbyBvcmlnaW5hbGUtLS0tLQ0KRGE6IE5pY29sYSBTbWFsZG9uZSBbbWFpbHRvOm5zbWFs
ZG9uZUB0aWVycmF0ZWxlbWF0aWNzLmNvbV0gDQpJbnZpYXRvOiBtYXJ0ZWTDrCAxNSBub3Zl
bWJyZSAyMDE2IDE0OjE4DQpBOiBHaWFuZnJhbmNvIENvc3RhbWFnbmE7IEthbGxlIFZhbG8N
CkNjOiBBcmVuZCBWYW4gU3ByaWVsOyBicmNtODAyMTEtZGV2LWxpc3RAYnJvYWRjb20uY29t
OyBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IEFybG9uZSBNYXJjbw0KT2dnZXR0
bzogUkU6IFtQQVRDSF0gYnJvYWRjb20vYnJjbTgwMjExL2JyY21mbWFjL2NmZzgwMjExIGRy
aXZlciwgYmFkIHJlZ3VsYXRvcnkgZG9tYWluIGZyZXF1ZW5jeSB2YWx1ZQ0KDQpObyBwcm9i
bGVtIGZvciBtZSwgdGhhbmtzLg0KDQpOaWNvbGEgU01BTERPTkUNCnd3dy50aWVycmF0ZWxl
bWF0aWNzLmNvbQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogR2lhbmZy
YW5jbyBDb3N0YW1hZ25hIFttYWlsdG86bG9jdXR1c29mYm9yZ0BkZWJpYW4ub3JnXQ0KU2Vu
dDogbWFydGVkw6wgMTUgbm92ZW1icmUgMjAxNiAxNDoxNA0KVG86IEthbGxlIFZhbG8gPGt2
YWxvQGNvZGVhdXJvcmEub3JnPg0KQ2M6IEFyZW5kIFZhbiBTcHJpZWwgPGFyZW5kLnZhbnNw
cmllbEBicm9hZGNvbS5jb20+OyBicmNtODAyMTEtZGV2LWxpc3RAYnJvYWRjb20uY29tOyBs
aW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IE5pY29sYSBTbWFsZG9uZSA8bnNtYWxk
b25lQHRpZXJyYXRlbGVtYXRpY3MuY29tPjsgTWFyY28uQXJsb25lQHJvai5jb20NClN1Ympl
Y3Q6IFJlOiBbUEFUQ0hdIGJyb2FkY29tL2JyY204MDIxMS9icmNtZm1hYy9jZmc4MDIxMSBk
cml2ZXIsIGJhZCByZWd1bGF0b3J5IGRvbWFpbiBmcmVxdWVuY3kgdmFsdWUNCg0KSGksDQoN
Cg0KPiBTaWduZWQtb2ZmLWJ5OiBOaWNvbGEgU21hbGRvbmUgPG5pY29sYS5zbWFsZG9uZUB0
aWVycmFzZXJ2aWNlLmNvbT4NCg0KPiBTaWduZWQtb2ZmLWJ5OiBBcmxvbmUgTWFyY28gPG1h
cmNvLmFybG9uZUByb2ouY29tPg0KDQo+UGxlYXNlIG5vdGUgdGhhdCB5b3UgY2Fubm90IGFk
ZCBTaWduZWQtb2ZmLWJ5IGZvciBvdGhlciBwZW9wbGUgd2l0aG91dCANCj50aGVpciBleHBs
aWNpdCBhcHByb3ZhbCAoc2VlIERvY3VtZW50YXRpb24vU3VibWl0dGluZ1BhdGNoZXMpLiBJ
IGRvbid0IA0KPmtub3cgaWYgdGhleSBkaWQgaXQgaW4gdGhpcyBjYXNlIG9yIG5vdCwgYnV0
IHdhbnRlZCB0byBwb2ludCBvdXQgdGhpcyANCj5hbnl3YXkuDQoNCg0KVGhlIGZpcnN0IHNp
Z25vZmYgaXMgbXlzZWxmLCB3aXRoIHRoZSBjb21wYW55IGVtYWlsLCB0aGUgb3RoZXIgdHdv
IHNpZ25vZmZzIGFyZSBmcm9tOiB0aGUgYXV0aG9yLCBhbmQgTmljb2xhLCB3aG8gZGlkIHdv
cmsgd2l0aCBtZSB0byB0ZXN0IGl0IChldmVuIGlmIGEgdHlwbyBmaXggaXMgbm90ICJ0ZXN0
YWJsZSIpLg0KDQpOaWNvbGEsIE1hcmNvLCBpcyBpdCBvayB0byBhZGQgeW91ciB0d28gbmFt
ZXMgaW4gdGhlIHNpZ25vZmYgcGFydD8NCih0aGF0IHdhcyBhIHZlcmJhbCB0YWxrLCBJIGRv
bid0IGhhdmUgYW55dGhpbmcgd3JpdHRlbikNCg0KR2lhbmZyYW5jbw0KDQpDb25maWRlbnRp
YWxpdHkgTm90aWNlOiBUaGlzIG1lc3NhZ2UgKGluY2x1ZGluZyBhdHRhY2htZW50cykgaXMg
YSBwcml2YXRlIGNvbW11bmljYXRpb24gc29sZWx5IGZvciB1c2Ugb2YgdGhlIGludGVuZGVk
IHJlY2lwaWVudChzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudChz
KSBvciBiZWxpZXZlIHlvdSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIG5vdGlm
eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSB0aGlzIG1lc3NhZ2Uu
IEFueSBvdGhlciB1c2UsIHJldGVudGlvbiwgZGlzc2VtaW5hdGlvbiBvciBjb3B5aW5nIGlz
IHByb2hpYml0ZWQgYW5kIG1heSBiZSBhIHZpb2xhdGlvbiBvZiBsYXcsIGluY2x1ZGluZyB0
aGUgRWxlY3Ryb25pYyBDb21tdW5pY2F0aW9uIFByaXZhY3kgQWN0IG9mIDE5ODYuDQoNCkZv
bGxvdyB1cyBvbiBZb3VUdWJlOiBodHRwczovL3d3dy55b3V0dWJlLmNvbS9jaGFubmVsL1VD
OW5US2plcThVZHhFeEtuQ05YRFBtQQ0KDQpQcmltYSBkaSBzdGFtcGFyZSwgcGVuc2EgYWxs
J2FtYmllbnRlICoqIFRoaW5rIGFib3V0IHRoZSBlbnZpcm9ubWVudCBiZWZvcmUgcHJpbnRp
bmcNCg0KDQpST0ogUy5yLmwuIC0gQmllbGxhIC0gSXRhbHkgICh3d3cucm9qLmNvbSkgDQpU
ZWw6ICszOS4wMTUuODQ4MDExMSAgIEZheDogKzM5LjAxNS40MDU4MTUvODQ4MDIwOQ0KDQpU
aGlzIGUtbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgaXMgY29uZmlk
ZW50aWFsIGFuZCBpbnRlbmRlZCBvbmx5IGZvciB0aGUgc3RhdGVkIGFkZHJlc3NlZShzKS4g
QW55IHVuYXV0aG9yaXNlZCBkaXNjbG9zdXJlLCB1c2Ugb3IgZGlzc2VtaW5hdGlvbiwgZWl0
aGVyIHdob2xlIG9yIHBhcnRpYWwsIGJ5IHBlcnNvbiBvciBlbnRpdGllcyBvdGhlciB0aGFu
IHRoZSBhZGRyZXNzZWUocykgaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2Vu
ZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBpZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUt
bWFpbCBieSBtaXN0YWtlIGFuZCBkZWxldGUgdGhpcyBlLW1haWwgZnJvbSB5b3VyIHN5c3Rl
bS4gDQpQbGVhc2Ugbm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQg
aW4gdGhpcyBlLW1haWwgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBhcmUg
bm90IG5lY2Vzc2FyaWx5IGVuZG9yc2VkIGJ5IHRoZSBjb21wYW55LiBBbHRob3VnaCB0aGUg
Y29tcGFueSBoYXMgdGFrZW4gcmVhc29uYWJsZSBwcmVjYXV0aW9ucyB0byBlbnN1cmUgbm8g
dmlydXNlcyBhcmUgcHJlc2VudCBpbiB0aGlzIGUtbWFpbCwgdGhlIGNvbXBhbnkgY2Fubm90
IGFjY2VwdCByZXNwb25zaWJpbGl0eSBmb3IgYW55IGxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcg
ZnJvbSB0aGUgdXNlIG9mIHRoaXMgZS1tYWlsIG9yIGF0dGFjaG1lbnRzLiANCg0K

Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Kalle Valo]

Gianfranco Costamagna <locutusofborg@debian.org> writes:

>> Signed-off-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>
>
>> Signed-off-by: Arlone Marco <marco.arlone@roj.com>
>
>>Please note that you cannot add Signed-off-by for other people without
>>their explicit approval (see Documentation/SubmittingPatches). I don't
>>know if they did it in this case or not, but wanted to point out this
>>anyway.
>
>
> The first signoff is myself, with the company email, the other two signoffs
> are from: the author, and Nicola, who did work with me to test it
> (even if a typo fix is not "testable").
>
> Nicola, Marco, is it ok to add your two names in the signoff part?
> (that was a verbal talk, I don't have anything written)

Good, so we got now approvals from both of them. Thanks.

-- 
Kalle Valo

Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Arend Van Spriel]

On 15-11-2016 12:10, Kalle Valo wrote:
> Gianfranco Costamagna <locutusofborg@debian.org> writes:
> 
>>> Well, not before you pointed it out ;-). You are welcome to send a patch
>>> fixing it. Otherwise, I will take care of it.
>>
>> attaching a format-patch like version.
>> I don't think we need a Tested-by or whatever, because it is just a typo in a comment.
>> (this is my first contribution, feel free to rebase or change whatever you prefer
>> to make it in line with other styles)
>>
>> (I gave authorship to Marco, the first one who discovered such typo)
> 
> [...]
> 
>> Signed-off-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>
>> Signed-off-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>
>> Signed-off-by: Arlone Marco <marco.arlone@roj.com>
> 
> Please note that you cannot add Signed-off-by for other people without
> their explicit approval (see Documentation/SubmittingPatches). I don't
> know if they did it in this case or not, but wanted to point out this
> anyway.

Thanks, Kalle

It was on my list to give a contrib boot camp here. So let's go over
things here albeit it late.

Hi Gianfrance,

A couple of things from which you may benefit for future contributions.
Basic info can be found in Documentation/SubmittingPatches as Kalle
indicated.

Patches should not be submitted as attachments. After doing 'git
format-patch' the easiest way is using 'git send-email' (which requires
you to have sendmail on your system properly setup). I tend to send
patches to Kalle and Cc: linux-wireless, but that is my personal
preference. Sending it to the list should be sufficient as patchwork
will pick it up [1].

When it comes to attribution of others you should have their approval
for Signed-off-by. However, reading your remarks it seems a proper way
is below:

Reported-by: Arlone Marco <marco.arlone@roj.com>
Tested-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>
Signed-off-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>

Regards,
Arend

[1] https://patchwork.kernel.org/project/linux-wireless/list/