* Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool
From: Rafał Miłecki @ 2017-01-06 22:40 UTC (permalink / raw)
To: Rahul Krishnan
Cc: Michael Büsch, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <CACna6ryhvkSaHgU9igshnMjNg=wgeXd3p57VXxbr0ykoEtLH_g@mail.gmail.com>
On 6 January 2017 at 23:39, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> wrot=
e:
> On 6 January 2017 at 16:20, Rahul Krishnan <mrahul.krishnan@gmail.com> wr=
ote:
>> This patch removes unnecessary return statement using spatch.
>> Signed-off-by: Rahul Krishnan <mrahul.krishnan@gmail.com>
Also an extra line break above Signed-off-by is preferred. Look at
"git log" to get am overview.
^ permalink raw reply
* Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool
From: Michael Büsch @ 2017-01-06 22:46 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Rahul Krishnan, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <CACna6ryhvkSaHgU9igshnMjNg=wgeXd3p57VXxbr0ykoEtLH_g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 399 bytes --]
> > @@ -1272,9 +1272,7 @@ u32 ssb_admatch_size(u32 adm)
> > default:
> > SSB_WARN_ON(1);
> > }
> > - size = (1 << (size + 1));
> > -
> > - return size;
> > + return (1 << (size + 1));
> > }
> > EXPORT_SYMBOL(ssb_admatch_size);
I'm all for cleaning up code, but I don't really see how this
change improves the code.
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool
From: Julian Calaby @ 2017-01-07 0:52 UTC (permalink / raw)
To: Rahul Krishnan
Cc: Michael Büsch, linux-wireless, linux-kernel@vger.kernel.org
In-Reply-To: <20170106152043.GA6383@rahul>
Hi Rahul,
On Sat, Jan 7, 2017 at 2:20 AM, Rahul Krishnan
<mrahul.krishnan@gmail.com> wrote:
> This patch removes unnecessary return statement using spatch.
This doesn't describe the patch.
> Signed-off-by: Rahul Krishnan <mrahul.krishnan@gmail.com>
> ---
> drivers/ssb/main.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
> index d1a7507..ae3b7fe 100644
> --- a/drivers/ssb/main.c
> +++ b/drivers/ssb/main.c
> @@ -1,4 +1,4 @@
> -/*
> + patch /home/rahul/git/kernels/staging/drivers//*
What is the purpose of this change, won't this cause the file to fail
to compile?
> * Sonics Silicon Backplane
> * Subsystem core
> *
> @@ -1272,9 +1272,7 @@ u32 ssb_admatch_size(u32 adm)
> default:
> SSB_WARN_ON(1);
> }
> - size = (1 << (size + 1));
> -
> - return size;
> + return (1 << (size + 1));
Is the size variable used elsewhere? If not, it's declaration should
probably be removed.
Also, there should be a blank line before the return statement.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Stephen Hemminger @ 2017-01-07 3:13 UTC (permalink / raw)
To: Linus Lüssing
Cc: netdev, David S . Miller, bridge, linux-kernel, linux-wireless,
Felix Fietkau
In-Reply-To: <20170102193214.31723-1-linus.luessing@c0d3.blue>
On Mon, 2 Jan 2017 20:32:14 +0100
Linus L=C3=BCssing <linus.luessing@c0d3.blue> wrote:
> This feature is intended for interface types which have a more reliable
> and/or efficient way to deliver unicast packets than broadcast ones
> (e.g. wifi).
Why is this not done in MAC80211 rather than bridge?
^ permalink raw reply
* Re: [PATCH v2 3/4] cfg80211: Accept multiple RSSI thresholds for CQM
From: Andrew Zaborowski @ 2017-01-07 9:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1483616947.4394.10.camel@sipsolutions.net>
Hi,
On 5 January 2017 at 06:49, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2017-01-04 at 15:19 -0500, Andrew Zaborowski wrote:
>> On 4 January 2017 at 10:53, Johannes Berg <johannes@sipsolutions.net>
>> wrote:
>> > Thus, you either need an nl80211 protocol feature bit (enum
>> > nl80211_protocol_features) or a new attribute, or so, I think.
>>
>> True, I'd assumed that netlink would check for exact attribute length
>> with NLA_S32.
>>
>> I'll add the feature bit but I wonder if it's better as a
>> driver/device feature (enum nl80211_ext_feature_index) so that it can
>> take into account whether rdev->set_cqm_rssi_range_config is set.
>
> Well, it's even more complicated than that because mac80211 may have
> the callback but still not be able to support it, with filtering,
> perhaps? Not quite sure now.
With the basic mac80211 implementation in my patch 4/4 this feature
should be set when IEEE80211_VIF_BEACON_FILTER is not set. The
problem with a nl80211_ext_feature is that it's per wiphy instead of
per interface. So in the case mac80211, it would need to be set if
all interfaces can accept lists of thresholds and that can change
dynamically as interfaces are added. And nl80211 has no per-interface
features.
I wonder if it's better to add a ieee80211_hw_flags flag to advertise
this feature per wiphy, or, as an approximation, set the flag based on
the default interface that is created in ieee80211_register_hw.
Best regards
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: M. Braun @ 2017-01-07 10:32 UTC (permalink / raw)
To: Johannes Berg, Felix Fietkau, Linus Lüssing, netdev
Cc: David S . Miller, Stephen Hemminger, bridge, linux-kernel,
linux-wireless
In-Reply-To: <1483710841.12677.1.camel@sipsolutions.net>
Am 06.01.2017 um 14:54 schrieb Johannes Berg:
>
>> The bridge layer can use IGMP snooping to ensure that the multicast
>> stream is only transmitted to clients that are actually a member of
>> the group. Can the mac80211 feature do the same?
>
> No, it'll convert the packet for all clients that are behind that
> netdev. But that's an argument for dropping the mac80211 feature, which
> hasn't been merged upstream yet, no?
But there is multicast/broadcast traffic like e.g. ARP and some IP
multicast groups that are not covered by IGMP snooping. The mac80211
patch converts this to unicast as well, which the bridge cannot do.
That way, these features both complement and overlap each other.
Regards,
Michael
^ permalink raw reply
* Re: [PATCH] brcmfmac: check if we can support used firmware API version
From: Arend Van Spriel @ 2017-01-07 11:44 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Rafał Miłecki
In-Reply-To: <CACna6rwJAjK1_Wpyj_NaOwdkegGONhTsS+-ckafkmyFRXAdphw@mail.gmail.com>
On 5-1-2017 11:06, Rafał Miłecki wrote:
> On 5 January 2017 at 10:50, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 3-1-2017 17:11, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>
>>> Every new firmware API will most likely require changes in our code to
>>> support it. Right now we support 2 versions only. Refuse to init if we
>>> detect newer version.
>>>
>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>> ---
>>> Hi Arend,
>>>
>>> I think you were concerned about possible firmware API changes. Please
>>> review this patch, I hope it's a proper check for running unsupported
>>> firmware version which could result in broken communication between host
>>> driver and a device.
>>> ---
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> index 0babfc7..c69ae84 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> @@ -6816,6 +6816,11 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
>>> brcmf_err("Failed to get D11 version (%d)\n", err);
>>> goto priv_out;
>>> }
>>> + if (io_type > BRCMU_D11AC_IOTYPE) {
>>> + brcmf_err("Unsupported IO version %d\n", io_type);
>>> + goto priv_out;
>>> + }
>>
>> I prefer to have this in brcmu_d11_attach() and have it return an error.
>
> My too, but since you made brcmu_d11_attach part of *utils* and new IO
> version support may require driver changes, I didn't want to mess
> these two.
>
> If it was up to me, I would keep brcmu_d11_attach in brcmfmac code and
> then add a proper check in this function indeed.
>
> Is there any reason you made brcmu_d11_attach part of utils?
The plan was/is to add 11ac support in brcmsmac so it would need the
brcmu_d11_*() functions.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Arend Van Spriel @ 2017-01-07 12:52 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Johannes Berg, linux-wireless@vger.kernel.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree@vger.kernel.org, Rob Herring,
Rafał Miłecki
In-Reply-To: <CACna6rw22benfuw_7BSFw1wedavmMJWTo_hfPLCVa1t0kV+Aqg@mail.gmail.com>
On 5-1-2017 11:02, Rafał Miłecki wrote:
> On 5 January 2017 at 10:31, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 4-1-2017 22:19, Rafał Miłecki wrote:
>>> On 4 January 2017 at 21:07, Arend Van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>> On 4-1-2017 18:58, Rafał Miłecki wrote:
>>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>>
>>>>> There are some devices (e.g. Netgear R8000 home router) with one chipset
>>>>> model used for different radios, some of them limited to subbands. NVRAM
>>>>> entries don't contain any extra info on such limitations and firmware
>>>>> reports full list of channels to us. We need to store extra limitation
>>>>> info in DT to support such devices properly.
>>>>>
>>>>> Now there is a cfg80211 helper for reading such info use it in brcmfmac.
>>>>> This patch adds check for channel being disabled with orig_flags which
>>>>> is how this wiphy helper and wiphy_register work.
>>>>>
>>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>>>> ---
>>>>> This patch should probably go through wireless-driver-next which is why
>>>>> it got weird number 4/3. I'm sending it just as a proof of concept.
>>>>> It was succesfully tested on SmartRG SR400ac with BCM43602.
>>>>>
>>>>> V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
>>>>> V5: Update commit message
>>>>> V6: Call wiphy_read_of_freq_limits after brcmf_setup_wiphybands to make it work
>>>>> with helper setting "flags" instead of "orig_flags".
>>>>> ---
>>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 ++++++++-
>>>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>> index ccae3bb..a008ba5 100644
>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>> @@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg,
>>>>> band->band);
>>>>> channel[index].hw_value = ch.control_ch_num;
>>>>>
>>>>> + if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
>>>>> + continue;
>>>>> +
>>>>
>>>> So to be clear this is still needed for subsequent calls to
>>>> brcmf_setup_wiphybands(). The subsequent calls are done from the
>>>> regulatory notifier. So I think we have an issue with this approach. Say
>>>> the device comes up with US. That would set DISABLED flags for channels
>>>> 12 to 14. With a country update to PL we would want to enable channels
>>>> 12 and 13, right? The orig_flags are copied from the initial flags
>>>> during wiphy_register() so it seems we will skip enabling 12 and 13. I
>>>> think we should remove the check above and call
>>>> wiphy_read_of_freq_limits() as a last step within
>>>> brcmf_setup_wiphybands(). It means it is called every time, but it
>>>> safeguards that the limits in DT are always applied.
>>>
>>> I'm not exactly happy with channels management in brcmfmac. Before
>>> calling wiphy_register it already disables channels unavailable for
>>> current country. This results in setting IEEE80211_CHAN_DISABLED in
>>
>> What do you mean by current country. There is none that we are aware off
>> in the driver. So we obtain the channels for the current
>> country/revision in the firmware and enable those before
>> wiphy_register(). This all is within the probe/init sequence so I do not
>> really see an issue. As the wiphy object is not yet registered there is
>> no user-space awareness
>
> It seems I'm terrible as describing my patches/problems/ideas :( Here
> I used 1 inaccurate word and you couldn't understand my point.
Well. Because of our track record of miscommunication and other
annoyances I want to be sure this time :-p
> By "current country" I meant current region (and so a set of
> regulatory rules) used by the firmware. I believe firmware describes
> it using "ccode" and "regrev".
>
> Now, about the issue I see:
>
> AFAIU if you set IEEE80211_CHAN_DISABLED in "orig_flags" it's meant to
> be there for good. Some reference code that makes me believe so
Indeed. Admittedly, it is the first time I became aware of it when
Johannes brought it up.
> (reg.c):
> pr_debug("Disabling freq %d MHz for good\n", chan->center_freq);
> chan->orig_flags |= IEEE80211_CHAN_DISABLED;
>
> This is what happens with brcmfmac right now. If firmware doesn't
> report some channels, you set "flags" to IEEE80211_CHAN_DISABLED for
> them. Then you call wiphy_register which copies that "flags" to the
> "orig_flags". I read it as: we are never going to use these channels.
>
> Now, consider you support regdom change (I do with my local patches).
> You translate alpha2 to a proper firmware request (board specific!),
> you execute it and then firmware may allow you to use channels that
> you marked as disabled for good. You would need to mess with
> orig_flags to recover from this issue.
>
> Does my explanation make more sense of this issue now?
Sure. It seems we should leave all channels enabled and disable them
after wiphy_register() based on firmware information. Or did you have
something else in mind. DFS channels may need to pass a feature check in
firmware and always be disabled otherwise.
>>> orig_flags of channels that may become available later, after country
>>> change. Please note it happens even right now, without this patch.
>>
>> Nope. As stated earlier the country setting in firmware is not updated
>> unless you provide a *proper* mapping of user-space country code to
>> firmware country code/revision. That is the reason, ie. firmware simply
>> returns the same list of channels as nothing changed from its
>> perspective. We may actually drop 11d support.
>
> I implemented mapping support locally, this is the feature I'm talking about.
Ok. So this is not an upstream feature. Or are you getting the mapping
from DT?
>>> Maybe you can workaround this by ignoring orig_flags in custom
>>> regulatory code, but I'd just prefer to have it nicely handled in the
>>> first place.
>>
>> Please care to explain your ideas before putting any effort in this
>> "feature". As the author of the code that makes you unhappy and as
>> driver maintainer I would like to get a clearer picture of your point of
>> view. What exactly is the issue that makes you unhappy.
>
> I meant that problem with "orig_flags" I described in the first
> paragraph. I wasn't trying to hide whatever issue I'm seeing, I swear
> ;)
>
>
>>> This is the next feature I'm going to work on. AFAIU this patch won't
>>> be applied for now (it's for wireless-drivers-next and we first need
>>> to get wiphy_read_of_freq_limits in that tree). By the time that
>>> happens I may have another patchset cleaning brcmfmac ready. And FWIW
>>> this patch wouldn't make things worse *at this point* as we don't
>>> really support country switching for any device yet.
>>
>> Now who is *we*? We as Broadcom can, because we know how to map the ISO
>> 3166-1 country code to firmware country code/revision for a specific
>> firmware release. Firmware uses its own regulatory rules which may
>> differ from what regdb has. Now I know Intel submitted a mechanism to
>> export firmware rules to regdb so maybe we should consider switching to
>> that api if that has been upstreamed. Need to check.
>
> We as a driver developers. Please read
> "we don't really support country switching for any device yet"
> as
> "brcmfmac doesn't really support country switching for any device yet"
>
> Does it help to get the context?
I indeed prefer to talk about the driver instead of we. Indeed it is
true due to the orig_flags behavior although that only seems to involve
regulatory code. Could it be that brcmfmac undo that through the notifier?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH V6 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rafał Miłecki @ 2017-01-07 12:53 UTC (permalink / raw)
To: Johannes Berg
Cc: Rob Herring, linux-wireless, Martin Blumenstingl, Felix Fietkau,
Arend van Spriel, Arnd Bergmann, devicetree@vger.kernel.org,
Rafał Miłecki
In-Reply-To: <1483707597.12677.0.camel@sipsolutions.net>
On 6 January 2017 at 13:59, Johannes Berg <johannes@sipsolutions.net> wrote=
:
> On Thu, 2017-01-05 at 10:34 -0600, Rob Herring wrote:
>> On Thu, Jan 5, 2017 at 5:51 AM, Johannes Berg <johannes@sipsolutions.
>> net> wrote:
>> >
>> > > Acked-by: Rob Herring <robh@kernel.org>
>> >
>> > Do I take that to mean that we'll merge it through the subsystem
>> > tree,
>> > and not go through some common DT tree?
>>
>> Yes, that's generally the case when bindings are in a series with
>> driver changes.
>
> Alright, thanks.
>
> I've applied patches 1-3, patch 4 obviously still needs work (and
> probably won't go through my tree anyway.)
>
> Note that I made some documentation fixes in patch 3, Rafa=C5=82, please
> check.
Looks great, thanks everyone for your help on getting this patchset in shap=
e!
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Rafał Miłecki @ 2017-01-07 12:58 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Johannes Berg, linux-wireless@vger.kernel.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree@vger.kernel.org, Rob Herring,
Rafał Miłecki
In-Reply-To: <36d2dbd1-bcbe-021b-dd7f-068a5b9739ef@broadcom.com>
On 7 January 2017 at 13:52, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 5-1-2017 11:02, Rafa=C5=82 Mi=C5=82ecki wrote:
>> On 5 January 2017 at 10:31, Arend Van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>> On 4-1-2017 22:19, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>> On 4 January 2017 at 21:07, Arend Van Spriel
>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>> On 4-1-2017 18:58, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>>>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>>>
>>>>>> There are some devices (e.g. Netgear R8000 home router) with one chi=
pset
>>>>>> model used for different radios, some of them limited to subbands. N=
VRAM
>>>>>> entries don't contain any extra info on such limitations and firmwar=
e
>>>>>> reports full list of channels to us. We need to store extra limitati=
on
>>>>>> info in DT to support such devices properly.
>>>>>>
>>>>>> Now there is a cfg80211 helper for reading such info use it in brcmf=
mac.
>>>>>> This patch adds check for channel being disabled with orig_flags whi=
ch
>>>>>> is how this wiphy helper and wiphy_register work.
>>>>>>
>>>>>> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>>> ---
>>>>>> This patch should probably go through wireless-driver-next which is =
why
>>>>>> it got weird number 4/3. I'm sending it just as a proof of concept.
>>>>>> It was succesfully tested on SmartRG SR400ac with BCM43602.
>>>>>>
>>>>>> V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
>>>>>> V5: Update commit message
>>>>>> V6: Call wiphy_read_of_freq_limits after brcmf_setup_wiphybands to m=
ake it work
>>>>>> with helper setting "flags" instead of "orig_flags".
>>>>>> ---
>>>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 +++=
+++++-
>>>>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg802=
11.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>>> index ccae3bb..a008ba5 100644
>>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>>> @@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct brc=
mf_cfg80211_info *cfg,
>>>>>> band->band);
>>>>>> channel[index].hw_value =3D ch.control_ch_num;
>>>>>>
>>>>>> + if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
>>>>>> + continue;
>>>>>> +
>>>>>
>>>>> So to be clear this is still needed for subsequent calls to
>>>>> brcmf_setup_wiphybands(). The subsequent calls are done from the
>>>>> regulatory notifier. So I think we have an issue with this approach. =
Say
>>>>> the device comes up with US. That would set DISABLED flags for channe=
ls
>>>>> 12 to 14. With a country update to PL we would want to enable channel=
s
>>>>> 12 and 13, right? The orig_flags are copied from the initial flags
>>>>> during wiphy_register() so it seems we will skip enabling 12 and 13. =
I
>>>>> think we should remove the check above and call
>>>>> wiphy_read_of_freq_limits() as a last step within
>>>>> brcmf_setup_wiphybands(). It means it is called every time, but it
>>>>> safeguards that the limits in DT are always applied.
>>>>
>>>> I'm not exactly happy with channels management in brcmfmac. Before
>>>> calling wiphy_register it already disables channels unavailable for
>>>> current country. This results in setting IEEE80211_CHAN_DISABLED in
>>>
>>> What do you mean by current country. There is none that we are aware of=
f
>>> in the driver. So we obtain the channels for the current
>>> country/revision in the firmware and enable those before
>>> wiphy_register(). This all is within the probe/init sequence so I do no=
t
>>> really see an issue. As the wiphy object is not yet registered there is
>>> no user-space awareness
>>
>> It seems I'm terrible as describing my patches/problems/ideas :( Here
>> I used 1 inaccurate word and you couldn't understand my point.
>
> Well. Because of our track record of miscommunication and other
> annoyances I want to be sure this time :-p
>
>> By "current country" I meant current region (and so a set of
>> regulatory rules) used by the firmware. I believe firmware describes
>> it using "ccode" and "regrev".
>>
>> Now, about the issue I see:
>>
>> AFAIU if you set IEEE80211_CHAN_DISABLED in "orig_flags" it's meant to
>> be there for good. Some reference code that makes me believe so
>
> Indeed. Admittedly, it is the first time I became aware of it when
> Johannes brought it up.
>
>> (reg.c):
>> pr_debug("Disabling freq %d MHz for good\n", chan->center_freq);
>> chan->orig_flags |=3D IEEE80211_CHAN_DISABLED;
>>
>> This is what happens with brcmfmac right now. If firmware doesn't
>> report some channels, you set "flags" to IEEE80211_CHAN_DISABLED for
>> them. Then you call wiphy_register which copies that "flags" to the
>> "orig_flags". I read it as: we are never going to use these channels.
>>
>> Now, consider you support regdom change (I do with my local patches).
>> You translate alpha2 to a proper firmware request (board specific!),
>> you execute it and then firmware may allow you to use channels that
>> you marked as disabled for good. You would need to mess with
>> orig_flags to recover from this issue.
>>
>> Does my explanation make more sense of this issue now?
>
> Sure. It seems we should leave all channels enabled and disable them
> after wiphy_register() based on firmware information. Or did you have
> something else in mind. DFS channels may need to pass a feature check in
> firmware and always be disabled otherwise.
I got in mind exactly what you described. I didn't look at DFS channels yet=
.
>>>> orig_flags of channels that may become available later, after country
>>>> change. Please note it happens even right now, without this patch.
>>>
>>> Nope. As stated earlier the country setting in firmware is not updated
>>> unless you provide a *proper* mapping of user-space country code to
>>> firmware country code/revision. That is the reason, ie. firmware simply
>>> returns the same list of channels as nothing changed from its
>>> perspective. We may actually drop 11d support.
>>
>> I implemented mapping support locally, this is the feature I'm talking a=
bout.
>
> Ok. So this is not an upstream feature. Or are you getting the mapping
> from DT?
I'll send patch next week. So far I put mapping table directly in a
driver, but I think it's better to have this in DT.
>>>> Maybe you can workaround this by ignoring orig_flags in custom
>>>> regulatory code, but I'd just prefer to have it nicely handled in the
>>>> first place.
>>>
>>> Please care to explain your ideas before putting any effort in this
>>> "feature". As the author of the code that makes you unhappy and as
>>> driver maintainer I would like to get a clearer picture of your point o=
f
>>> view. What exactly is the issue that makes you unhappy.
>>
>> I meant that problem with "orig_flags" I described in the first
>> paragraph. I wasn't trying to hide whatever issue I'm seeing, I swear
>> ;)
>>
>>
>>>> This is the next feature I'm going to work on. AFAIU this patch won't
>>>> be applied for now (it's for wireless-drivers-next and we first need
>>>> to get wiphy_read_of_freq_limits in that tree). By the time that
>>>> happens I may have another patchset cleaning brcmfmac ready. And FWIW
>>>> this patch wouldn't make things worse *at this point* as we don't
>>>> really support country switching for any device yet.
>>>
>>> Now who is *we*? We as Broadcom can, because we know how to map the ISO
>>> 3166-1 country code to firmware country code/revision for a specific
>>> firmware release. Firmware uses its own regulatory rules which may
>>> differ from what regdb has. Now I know Intel submitted a mechanism to
>>> export firmware rules to regdb so maybe we should consider switching to
>>> that api if that has been upstreamed. Need to check.
>>
>> We as a driver developers. Please read
>> "we don't really support country switching for any device yet"
>> as
>> "brcmfmac doesn't really support country switching for any device yet"
>>
>> Does it help to get the context?
>
> I indeed prefer to talk about the driver instead of we. Indeed it is
> true due to the orig_flags behavior although that only seems to involve
> regulatory code. Could it be that brcmfmac undo that through the notifier=
?
I guess you could touch orig_flags, but I don't know if it's preferred
way. This is probably question to Johannes & cfg80211 guys.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool
From: kbuild test robot @ 2017-01-07 13:39 UTC (permalink / raw)
To: Rahul Krishnan; +Cc: kbuild-all, m, linux-wireless, linux-kernel
In-Reply-To: <20170106152043.GA6383@rahul>
[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]
Hi Rahul,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Rahul-Krishnan/ssb-main-c-This-patch-removes-unnecessary-return-statement-using-spatch-tool/20170107-205451
config: x86_64-randconfig-x008-201701 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> drivers/ssb/main.c:1:8: error: expected '=', ',', ';', 'asm' or '__attribute__' before '/' token
patch /home/rahul/git/kernels/staging/drivers//*
^
>> drivers/ssb/main.c:6:43: error: stray '@' in program
* Copyright 2006, 2007, Michael Buesch <m@bues.ch>
^
vim +1 drivers/ssb/main.c
> 1 patch /home/rahul/git/kernels/staging/drivers//*
2 * Sonics Silicon Backplane
3 * Subsystem core
4 *
5 * Copyright 2005, Broadcom Corporation
> 6 * Copyright 2006, 2007, Michael Buesch <m@bues.ch>
7 *
8 * Licensed under the GNU/GPL. See COPYING for details.
9 */
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27927 bytes --]
^ permalink raw reply
* Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool
From: kbuild test robot @ 2017-01-07 13:57 UTC (permalink / raw)
To: Rahul Krishnan; +Cc: kbuild-all, m, linux-wireless, linux-kernel
In-Reply-To: <20170106152043.GA6383@rahul>
[-- Attachment #1: Type: text/plain, Size: 26233 bytes --]
Hi Rahul,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Rahul-Krishnan/ssb-main-c-This-patch-removes-unnecessary-return-statement-using-spatch-tool/20170107-205451
config: i386-randconfig-r0-201701 (attached as .config)
compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/ssb/main.c:1:8: error: expected '=', ',', ';', 'asm' or '__attribute__' before '/' token
patch /home/rahul/git/kernels/staging/drivers//*
^
drivers/ssb/main.c:6:43: error: stray '@' in program
* Copyright 2006, 2007, Michael Buesch <m@bues.ch>
^
In file included from include/linux/ioport.h:12:0,
from include/linux/device.h:16,
from include/linux/ssb/ssb.h:4,
from drivers/ssb/ssb_private.h:4,
from drivers/ssb/main.c:11:
>> include/linux/compiler.h:110:34: warning: 'struct ftrace_branch_data' declared inside parameter list
void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
^
>> include/linux/compiler.h:110:34: warning: its scope is only this definition or declaration, which is probably not what you want
include/linux/err.h: In function 'IS_ERR':
include/linux/compiler.h:117:18: error: variable '______f' has initializer but incomplete type
static struct ftrace_branch_data \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/compiler.h:117:18: error: unknown field 'func' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/compiler.h:121:13: warning: excess elements in struct initializer
.func = __func__, \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/compiler.h:121:13: note: (near initialization for '______f')
.func = __func__, \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/compiler.h:117:18: error: unknown field 'file' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/err.h:35:40: warning: excess elements in struct initializer
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/err.h:35:40: note: (near initialization for '______f')
include/linux/compiler.h:117:18: error: unknown field 'line' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/err.h:35:40: warning: excess elements in struct initializer
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/err.h:35:40: note: (near initialization for '______f')
include/linux/compiler.h:120:5: error: storage size of '______f' isn't known
______f = { \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/compiler.h:120:5: warning: unused variable '______f' [-Wunused-variable]
______f = { \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
--
^
include/linux/compiler.h:121:13: note: (near initialization for '______f')
.func = __func__, \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
arch/x86/include/asm/preempt.h:98:9: note: in expansion of macro 'unlikely'
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
include/linux/compiler.h:117:18: error: unknown field 'file' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
arch/x86/include/asm/preempt.h:98:9: note: in expansion of macro 'unlikely'
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
arch/x86/include/asm/preempt.h:98:67: warning: excess elements in struct initializer
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
arch/x86/include/asm/preempt.h:98:67: note: (near initialization for '______f')
include/linux/compiler.h:117:18: error: unknown field 'line' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
arch/x86/include/asm/preempt.h:98:9: note: in expansion of macro 'unlikely'
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
arch/x86/include/asm/preempt.h:98:67: warning: excess elements in struct initializer
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
arch/x86/include/asm/preempt.h:98:67: note: (near initialization for '______f')
include/linux/compiler.h:120:5: error: storage size of '______f' isn't known
______f = { \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
arch/x86/include/asm/preempt.h:98:9: note: in expansion of macro 'unlikely'
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
include/linux/compiler.h:120:5: warning: unused variable '______f' [-Wunused-variable]
______f = { \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
arch/x86/include/asm/preempt.h:98:9: note: in expansion of macro 'unlikely'
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
include/asm-generic/qspinlock.h: In function 'queued_spin_lock':
include/linux/compiler.h:117:18: error: variable '______f' has initializer but incomplete type
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
include/linux/compiler.h:117:18: error: unknown field 'func' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
include/linux/compiler.h:121:13: warning: excess elements in struct initializer
.func = __func__, \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
include/linux/compiler.h:121:13: note: (near initialization for '______f')
.func = __func__, \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
include/linux/compiler.h:117:18: error: unknown field 'file' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
>> include/asm-generic/qspinlock.h:101:21: warning: excess elements in struct initializer
if (likely(val == 0))
^
include/asm-generic/qspinlock.h:101:21: note: (near initialization for '______f')
include/linux/compiler.h:117:18: error: unknown field 'line' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
>> include/asm-generic/qspinlock.h:101:21: warning: excess elements in struct initializer
if (likely(val == 0))
^
include/asm-generic/qspinlock.h:101:21: note: (near initialization for '______f')
include/linux/compiler.h:120:5: error: storage size of '______f' isn't known
______f = { \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
include/linux/compiler.h:120:5: warning: unused variable '______f' [-Wunused-variable]
______f = { \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
include/asm-generic/qrwlock.h: In function 'queued_read_trylock':
include/linux/compiler.h:117:18: error: variable '______f' has initializer but incomplete type
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
include/linux/compiler.h:117:18: error: unknown field 'func' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
include/linux/compiler.h:121:13: warning: excess elements in struct initializer
.func = __func__, \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
include/linux/compiler.h:121:13: note: (near initialization for '______f')
.func = __func__, \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
include/linux/compiler.h:117:18: error: unknown field 'file' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
>> include/asm-generic/qrwlock.h:83:32: warning: excess elements in struct initializer
if (likely(!(cnts & _QW_WMASK))) {
^
include/asm-generic/qrwlock.h:83:32: note: (near initialization for '______f')
include/linux/compiler.h:117:18: error: unknown field 'line' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
>> include/asm-generic/qrwlock.h:83:32: warning: excess elements in struct initializer
if (likely(!(cnts & _QW_WMASK))) {
^
include/asm-generic/qrwlock.h:83:32: note: (near initialization for '______f')
include/linux/compiler.h:120:5: error: storage size of '______f' isn't known
______f = { \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
include/linux/compiler.h:120:5: warning: unused variable '______f' [-Wunused-variable]
______f = { \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
include/linux/compiler.h:117:18: error: variable '______f' has initializer but incomplete type
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/linux/compiler.h:117:18: error: unknown field 'func' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/linux/compiler.h:121:13: warning: excess elements in struct initializer
.func = __func__, \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/linux/compiler.h:121:13: note: (near initialization for '______f')
.func = __func__, \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/linux/compiler.h:117:18: error: unknown field 'file' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/asm-generic/qrwlock.h:85:33: warning: excess elements in struct initializer
if (likely(!(cnts & _QW_WMASK)))
^
include/asm-generic/qrwlock.h:85:33: note: (near initialization for '______f')
include/linux/compiler.h:117:18: error: unknown field 'line' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/asm-generic/qrwlock.h:85:33: warning: excess elements in struct initializer
if (likely(!(cnts & _QW_WMASK)))
^
include/asm-generic/qrwlock.h:85:33: note: (near initialization for '______f')
include/linux/compiler.h:120:5: error: storage size of '______f' isn't known
______f = { \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/linux/compiler.h:120:5: warning: unused variable '______f' [-Wunused-variable]
______f = { \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
..
vim +212 drivers/ssb/main.c
3ba6018a Michael Buesch 2009-11-23 196 *
3ba6018a Michael Buesch 2009-11-23 197 * After freezing no device driver will be handling a device
3ba6018a Michael Buesch 2009-11-23 198 * on this bus anymore. ssb_devices_thaw() must be called after
3ba6018a Michael Buesch 2009-11-23 199 * a successful freeze to reactivate the devices.
3ba6018a Michael Buesch 2009-11-23 200 *
3ba6018a Michael Buesch 2009-11-23 201 * @bus: The bus.
3ba6018a Michael Buesch 2009-11-23 202 * @ctx: Context structure. Pass this to ssb_devices_thaw().
3ba6018a Michael Buesch 2009-11-23 203 */
3ba6018a Michael Buesch 2009-11-23 204 int ssb_devices_freeze(struct ssb_bus *bus, struct ssb_freeze_context *ctx)
61e115a5 Michael Buesch 2007-09-18 205 {
3ba6018a Michael Buesch 2009-11-23 206 struct ssb_device *sdev;
3ba6018a Michael Buesch 2009-11-23 207 struct ssb_driver *sdrv;
3ba6018a Michael Buesch 2009-11-23 208 unsigned int i;
3ba6018a Michael Buesch 2009-11-23 209
3ba6018a Michael Buesch 2009-11-23 210 memset(ctx, 0, sizeof(*ctx));
3ba6018a Michael Buesch 2009-11-23 211 ctx->bus = bus;
3ba6018a Michael Buesch 2009-11-23 @212 SSB_WARN_ON(bus->nr_devices > ARRAY_SIZE(ctx->device_frozen));
61e115a5 Michael Buesch 2007-09-18 213
61e115a5 Michael Buesch 2007-09-18 214 for (i = 0; i < bus->nr_devices; i++) {
3ba6018a Michael Buesch 2009-11-23 215 sdev = ssb_device_get(&bus->devices[i]);
3ba6018a Michael Buesch 2009-11-23 216
3ba6018a Michael Buesch 2009-11-23 217 if (!sdev->dev || !sdev->dev->driver ||
3ba6018a Michael Buesch 2009-11-23 218 !device_is_registered(sdev->dev)) {
3ba6018a Michael Buesch 2009-11-23 219 ssb_device_put(sdev);
61e115a5 Michael Buesch 2007-09-18 220 continue;
:::::: The code at line 212 was first introduced by commit
:::::: 3ba6018aa314559c5867138a8173b068268a70db ssb: Fix SPROM writing
:::::: TO: Michael Buesch <mb@bu3sch.de>
:::::: CC: John W. Linville <linville@tuxdriver.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 21800 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Linus Lüssing @ 2017-01-07 14:55 UTC (permalink / raw)
To: M. Braun
Cc: Johannes Berg, Felix Fietkau, netdev, David S . Miller,
Stephen Hemminger, bridge, linux-kernel, linux-wireless
In-Reply-To: <22fad045-57c6-7789-d19f-f47bd0faf441@fami-braun.de>
On Sat, Jan 07, 2017 at 11:32:57AM +0100, M. Braun wrote:
> Am 06.01.2017 um 14:54 schrieb Johannes Berg:
> >
> >> The bridge layer can use IGMP snooping to ensure that the multicast
> >> stream is only transmitted to clients that are actually a member of
> >> the group. Can the mac80211 feature do the same?
> >
> > No, it'll convert the packet for all clients that are behind that
> > netdev. But that's an argument for dropping the mac80211 feature, which
> > hasn't been merged upstream yet, no?
>
> But there is multicast/broadcast traffic like e.g. ARP and some IP
> multicast groups that are not covered by IGMP snooping. The mac80211
> patch converts this to unicast as well, which the bridge cannot do.
>
> That way, these features both complement and overlap each other.
Right, I'd agree with that.
I didn't write it explicitly in the commit message, but yes, the
like anything concerning bridge multicast snooping, bridge
multicast-to-unicast can only affect packets as noted in
RFC4541 ("Considerations for Internet Group Management Protocol (IGMP)
and Multicast Listener Discovery (MLD) Snooping Switches"), too.
So it is only working for IPv4 multicast, excluding link-local
(224.0.0.0/24), and IPv6 multicast, excluding all-host-multicast
(ff02::1).
And does not concern ARP in any way.
The nice complementary effect is, that the bridge can first sieve
out those IP packets thanks to IGMP/MLD snooping knowledge and for
anything else, like ARP, 224.0.0.x or ff02::1, the mac80211
multicast-to-unicast could do its job.
For APs with a small number of STAs (like your private home AP),
you might want to enable both bridge multicast-to-unicast and
mac80211 multicast-to-unicast for this complementary effect. While
on public APs with 30 to 50 STAs with varying distances and bitrates,
you might only one to enable the bridge one, because sending an ARP
packet 50x might actually reduce performance and airtime
significantly.
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Linus Lüssing @ 2017-01-07 15:06 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, David S . Miller, bridge, linux-kernel, linux-wireless,
Felix Fietkau
In-Reply-To: <20170106191356.43740a26@xeon-e3>
On Fri, Jan 06, 2017 at 07:13:56PM -0800, Stephen Hemminger wrote:
> On Mon, 2 Jan 2017 20:32:14 +0100
> Linus Lüssing <linus.luessing@c0d3.blue> wrote:
>
> > This feature is intended for interface types which have a more reliable
> > and/or efficient way to deliver unicast packets than broadcast ones
> > (e.g. wifi).
>
>
> Why is this not done in MAC80211 rather than bridge?
Because mac80211 does not have the IGMP/MLD snooping code as
the bridge has?
Reimplementing the snooping in mac80211 does not make sense
because of duplicating code. Moving the snooping code from the
bridge to mac80211 does not make sense either, because we want
multicast snooping, software based, (virtually) wired switches,
too.
The "best way" (TM) would probably be to migrate the IGMP/MLD
snooping from the bridge code to the net device code on the long
run to make such a database usable for any kind of device, without
needing this bridge hack.
But such a migration would also need a way more invasive patchset.
While Felix's idea might look a little "ugly" due it's hacky
nature, I think it is also quite beautiful thanks to it's
simplicity.
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Linus Lüssing @ 2017-01-07 15:15 UTC (permalink / raw)
To: Johannes Berg
Cc: netdev, David S . Miller, Stephen Hemminger, bridge, linux-kernel,
linux-wireless, Felix Fietkau, Michael Braun
In-Reply-To: <1483706872.4089.8.camel@sipsolutions.net>
On Fri, Jan 06, 2017 at 01:47:52PM +0100, Johannes Berg wrote:
> How does this compare and/or relate to the multicast-to-unicast feature
> we were going to add to the wifi stack, particularly mac80211? Do we
> perhaps not need that feature at all, if bridging will have it?
>
> I suppose that the feature there could apply also to locally generated
> traffic when the AP interface isn't in a bridge, but I think I could
> live with requiring the AP to be put into a bridge to achieve a similar
> configuration?
>
> Additionally, on an unrelated note, this seems to apply generically to
> all kinds of frames, losing information by replacing the address.
> Shouldn't it have similar limitations as the wifi stack feature has
> then, like only applying to ARP, IPv4, IPv6 and not general protocols?
(should all three be answered with Michael's and my reply to
Michael's mail, I think)
>
> Also, it should probably come with the same caveat as we documented for
> the wifi feature:
>
> Note that this may break certain expectations of the receiver,
> such as the ability to drop unicast IP packets received within
> multicast L2 frames, or the ability to not send ICMP destination
> unreachable messages for packets received in L2 multicast (which
> is required, but the receiver can't tell the difference if this
> new option is enabled.)
Actually, I do not quite understand that remark in the mac80211
multicast-to-unicast patch. IP should not care about the ethernet
header?
^ permalink raw reply
* Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Rafał Miłecki @ 2017-01-07 17:36 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Johannes Berg, linux-wireless@vger.kernel.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree@vger.kernel.org, Rob Herring,
Rafał Miłecki
In-Reply-To: <CACna6rw22benfuw_7BSFw1wedavmMJWTo_hfPLCVa1t0kV+Aqg@mail.gmail.com>
On 5 January 2017 at 11:02, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> wrot=
e:
> On 5 January 2017 at 10:31, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 4-1-2017 22:19, Rafa=C5=82 Mi=C5=82ecki wrote:
>>> I'm not exactly happy with channels management in brcmfmac. Before
>>> calling wiphy_register it already disables channels unavailable for
>>> current country. This results in setting IEEE80211_CHAN_DISABLED in
>>
>> What do you mean by current country. There is none that we are aware off
>> in the driver. So we obtain the channels for the current
>> country/revision in the firmware and enable those before
>> wiphy_register(). This all is within the probe/init sequence so I do not
>> really see an issue. As the wiphy object is not yet registered there is
>> no user-space awareness
>
> It seems I'm terrible as describing my patches/problems/ideas :( Here
> I used 1 inaccurate word and you couldn't understand my point.
>
> By "current country" I meant current region (and so a set of
> regulatory rules) used by the firmware. I believe firmware describes
> it using "ccode" and "regrev".
>
> Now, about the issue I see:
>
> AFAIU if you set IEEE80211_CHAN_DISABLED in "orig_flags" it's meant to
> be there for good. Some reference code that makes me believe so
> (reg.c):
> pr_debug("Disabling freq %d MHz for good\n", chan->center_freq);
> chan->orig_flags |=3D IEEE80211_CHAN_DISABLED;
>
> This is what happens with brcmfmac right now. If firmware doesn't
> report some channels, you set "flags" to IEEE80211_CHAN_DISABLED for
> them. Then you call wiphy_register which copies that "flags" to the
> "orig_flags". I read it as: we are never going to use these channels.
>
> Now, consider you support regdom change (I do with my local patches).
> You translate alpha2 to a proper firmware request (board specific!),
> you execute it and then firmware may allow you to use channels that
> you marked as disabled for good. You would need to mess with
> orig_flags to recover from this issue.
I was wrong about this. Current notifier implementation in brcmfmac
doesn't care about "orig_flags" and it just sets "flags" as it wants.
This way it can enable even these channels that were believed to be
disabled for good (DISABLED in "orig_flags").
For my test I booted SR400ac with ccode & regrev set to values that
didn't allow me to use channels 149 - 165 (5735 - 5835). It matches my
current country:
country PL: DFS-ETSI
(2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
Then I used "iw reg set ??" to set country that allows these channels.
My locally modified brcmfmac driver sent proper "country" iovar to the
firmware and queried it for the updated "chanspecs". See my debugging
messages below:
brcmfmac: [brcmf_construct_chaninfo] hw_value:34 orig_flags:0x101 flags:0x0=
01
brcmfmac: [brcmf_construct_chaninfo] hw_value:36 orig_flags:0x1a0 flags:0x0=
a0
brcmfmac: [brcmf_construct_chaninfo] hw_value:38 orig_flags:0x101 flags:0x0=
01
brcmfmac: [brcmf_construct_chaninfo] hw_value:40 orig_flags:0x190 flags:0x0=
90
brcmfmac: [brcmf_construct_chaninfo] hw_value:42 orig_flags:0x101 flags:0x0=
01
brcmfmac: [brcmf_construct_chaninfo] hw_value:44 orig_flags:0x1a0 flags:0x0=
a0
brcmfmac: [brcmf_construct_chaninfo] hw_value:46 orig_flags:0x101 flags:0x0=
01
brcmfmac: [brcmf_construct_chaninfo] hw_value:48 orig_flags:0x190 flags:0x0=
90
brcmfmac: [brcmf_construct_chaninfo] hw_value:52 orig_flags:0x1aa flags:0x0=
aa
brcmfmac: [brcmf_construct_chaninfo] hw_value:56 orig_flags:0x19a flags:0x0=
9a
brcmfmac: [brcmf_construct_chaninfo] hw_value:60 orig_flags:0x1aa flags:0x0=
aa
brcmfmac: [brcmf_construct_chaninfo] hw_value:64 orig_flags:0x19a flags:0x0=
9a
brcmfmac: [brcmf_construct_chaninfo] hw_value:100 orig_flags:0x1aa flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:104 orig_flags:0x19a flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:108 orig_flags:0x1aa flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:112 orig_flags:0x19a flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:116 orig_flags:0x1aa flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:120 orig_flags:0x19a flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:124 orig_flags:0x1aa flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:128 orig_flags:0x19a flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:132 orig_flags:0x1aa flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:136 orig_flags:0x19a flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:140 orig_flags:0x1ba flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:144 orig_flags:0x101 flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:149 orig_flags:0x101 flags:0x=
0a0
brcmfmac: [brcmf_construct_chaninfo] hw_value:153 orig_flags:0x101 flags:0x=
090
brcmfmac: [brcmf_construct_chaninfo] hw_value:157 orig_flags:0x101 flags:0x=
0a0
brcmfmac: [brcmf_construct_chaninfo] hw_value:161 orig_flags:0x101 flags:0x=
090
brcmfmac: [brcmf_construct_chaninfo] hw_value:165 orig_flags:0x101 flags:0x=
0b0
As you can see brcmfmac dropped IEEE80211_CHAN_DISABLED (hint: 0x1)
for channels 149 - 165 even though they were disabled according to the
"orig_flags".
So this patch with its
if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
continue;
could be considered some kind of regression. My change wouldn't allow
enabling such channels anymore.
Of course noone would notice this as noone uses country_codes table
yet I guess (except for me locally). Anyway, this patch should be
reworked to make sure it still allows implementing support for
country_codes tables in the future.
^ permalink raw reply
* [PATCH 1/2] brcmfmac: don't preset all channels as disabled
From: Rafał Miłecki @ 2017-01-07 20:36 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
During init we take care of regulatory stuff by disabling all
unavailable channels (see brcmf_construct_chaninfo) so this predisabling
them is not really required (and this patch won't change any behavior).
It will on the other hand allow more detailed runtime control over
channels which is the main reason for this change.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 895404c..45ee5b6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -138,7 +138,6 @@ static struct ieee80211_rate __wl_rates[] = {
.band = NL80211_BAND_2GHZ, \
.center_freq = (_freq), \
.hw_value = (_channel), \
- .flags = IEEE80211_CHAN_DISABLED, \
.max_antenna_gain = 0, \
.max_power = 30, \
}
@@ -147,7 +146,6 @@ static struct ieee80211_rate __wl_rates[] = {
.band = NL80211_BAND_5GHZ, \
.center_freq = 5000 + (5 * (_channel)), \
.hw_value = (_channel), \
- .flags = IEEE80211_CHAN_DISABLED, \
.max_antenna_gain = 0, \
.max_power = 30, \
}
--
2.10.1
^ permalink raw reply related
* [PATCH 2/2] brcmfmac: setup wiphy bands after registering it first
From: Rafał Miłecki @ 2017-01-07 20:36 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170107203605.24866-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
During bands setup we disable all channels that firmware doesn't support
in the current regulatory setup. If we do this before wiphy_register
it will result in copying set flags (including IEEE80211_CHAN_DISABLED)
to the orig_flags which is supposed to be persistent. We don't want this
as regulatory change may result in enabling some channels. We shouldn't
mess with orig_flags then (by changing them or ignoring them) so it's
better to just take care of their proper values.
This patch cleanups code a bit (by taking orig_flags more seriously) and
allows further improvements like disabling really unavailable channels.
We will need that e.g. if some frequencies should be disabled for good
due to hardware setup (design).
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 45ee5b6..729bf33 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6477,8 +6477,7 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp)
wiphy->bands[NL80211_BAND_5GHZ] = band;
}
}
- err = brcmf_setup_wiphybands(wiphy);
- return err;
+ return 0;
}
static s32 brcmf_config_dongle(struct brcmf_cfg80211_info *cfg)
@@ -6843,6 +6842,12 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
goto priv_out;
}
+ err = brcmf_setup_wiphybands(wiphy);
+ if (err) {
+ brcmf_err("Setting wiphy bands failed (%d)\n", err);
+ goto wiphy_unreg_out;
+ }
+
/* If cfg80211 didn't disable 40MHz HT CAP in wiphy_register(),
* setup 40MHz in 2GHz band and enable OBSS scanning.
*/
--
2.10.1
^ permalink raw reply related
* [PATCH] brcmfmac: make brcmf_of_probe more generic
From: Rafał Miłecki @ 2017-01-07 22:43 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
We may want to use Open Firmware for other devices than just SDIO ones.
In future we may want to support more Broadcom properties so there is
really no reason for such limitation.
Call brcmf_of_probe for all kind of devices & move extra conditions to
the body of that funcion.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 8 +++-----
drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 7 +++++--
drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.h | 6 ++++--
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index 3e15d64..b1f574f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -299,11 +299,9 @@ struct brcmf_mp_device *brcmf_get_module_param(struct device *dev,
}
}
}
- if ((bus_type == BRCMF_BUSTYPE_SDIO) && (!found)) {
- /* No platform data for this device. In case of SDIO try OF
- * (Open Firwmare) Device Tree.
- */
- brcmf_of_probe(dev, &settings->bus.sdio);
+ if (!found) {
+ /* No platform data for this device, try OF (Open Firwmare) */
+ brcmf_of_probe(dev, bus_type, settings);
}
return settings;
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
index 425c41d..aee6e59 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -23,14 +23,17 @@
#include "common.h"
#include "of.h"
-void brcmf_of_probe(struct device *dev, struct brcmfmac_sdio_pd *sdio)
+void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type,
+ struct brcmf_mp_device *settings)
{
+ struct brcmfmac_sdio_pd *sdio = &settings->bus.sdio;
struct device_node *np = dev->of_node;
int irq;
u32 irqf;
u32 val;
- if (!np || !of_device_is_compatible(np, "brcm,bcm4329-fmac"))
+ if (!np || bus_type != BRCMF_BUSTYPE_SDIO ||
+ !of_device_is_compatible(np, "brcm,bcm4329-fmac"))
return;
if (of_property_read_u32(np, "brcm,drive-strength", &val) == 0)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.h
index a9d94c1..95b7032 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.h
@@ -14,9 +14,11 @@
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#ifdef CONFIG_OF
-void brcmf_of_probe(struct device *dev, struct brcmfmac_sdio_pd *sdio);
+void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type,
+ struct brcmf_mp_device *settings);
#else
-static void brcmf_of_probe(struct device *dev, struct brcmfmac_sdio_pd *sdio)
+static void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type,
+ struct brcmf_mp_device *settings)
{
}
#endif /* CONFIG_OF */
--
2.10.1
^ permalink raw reply related
* Re: [PATCH V2 1/3] cfg80211: allow passing struct device in the wiphy_new call
From: kbuild test robot @ 2017-01-08 7:38 UTC (permalink / raw)
To: Rafał Miłecki
Cc: kbuild-all, Johannes Berg, linux-wireless, Martin Blumenstingl,
Felix Fietkau, Arend van Spriel, Arnd Bergmann, devicetree,
Rafał Miłecki
In-Reply-To: <20170102132747.3491-1-zajec5@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3878 bytes --]
Hi Rafał,
[auto build test WARNING on mac80211-next/master]
[also build test WARNING on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/cfg80211-allow-passing-struct-device-in-the-wiphy_new-call/20170103-014525
base: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
config: x86_64-randconfig-s2-01081447 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/net/wireless/intersil/orinoco/cfg.c: In function 'orinoco_wiphy_init':
>> drivers/net/wireless/intersil/orinoco/cfg.c:26: warning: unused variable 'priv'
drivers/net/wireless/intersil/orinoco/cfg.o: warning: objtool: orinoco_set_wiphy_params()+0x1e: function has unreachable instruction
vim +/priv +26 drivers/net/wireless/intersil/orinoco/cfg.c
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 10
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 11 #include "cfg.h"
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 12
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 13 /* Supported bitrates. Must agree with hw.c */
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 14 static struct ieee80211_rate orinoco_rates[] = {
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 15 { .bitrate = 10 },
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 16 { .bitrate = 20 },
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 17 { .bitrate = 55 },
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 18 { .bitrate = 110 },
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 19 };
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 20
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 21 static const void * const orinoco_wiphy_privid = &orinoco_wiphy_privid;
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 22
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 23 /* Called after orinoco_private is allocated. */
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 24 void orinoco_wiphy_init(struct wiphy *wiphy)
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 25 {
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 @26 struct orinoco_private *priv = wiphy_priv(wiphy);
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 27
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 28 wiphy->privid = orinoco_wiphy_privid;
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 29 }
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 30
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 31 /* Called after firmware is initialised */
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 32 int orinoco_wiphy_register(struct wiphy *wiphy)
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 33 {
ea60a6aa drivers/net/wireless/orinoco/cfg.c David Kilroy 2009-06-18 34 struct orinoco_private *priv = wiphy_priv(wiphy);
:::::: The code at line 26 was first introduced by commit
:::::: ea60a6aaf55984a13a7150568cc103d006e86ab2 orinoco: initiate cfg80211 conversion
:::::: TO: David Kilroy <kilroyd@googlemail.com>
:::::: CC: John W. Linville <linville@tuxdriver.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26253 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] brcmfmac: setup wiphy bands after registering it first
From: Arend Van Spriel @ 2017-01-08 13:00 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170107203605.24866-2-zajec5@gmail.com>
On 7-1-2017 21:36, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> During bands setup we disable all channels that firmware doesn't support
> in the current regulatory setup. If we do this before wiphy_register
> it will result in copying set flags (including IEEE80211_CHAN_DISABLED)
> to the orig_flags which is supposed to be persistent. We don't want this
> as regulatory change may result in enabling some channels. We shouldn't
> mess with orig_flags then (by changing them or ignoring them) so it's
> better to just take care of their proper values.
>
> This patch cleanups code a bit (by taking orig_flags more seriously) and
> allows further improvements like disabling really unavailable channels.
> We will need that e.g. if some frequencies should be disabled for good
> due to hardware setup (design).
I think this and previous patch are too dependent and prefer to have
them in a single patch. Despite that for both:
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 45ee5b6..729bf33 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -6477,8 +6477,7 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp)
> wiphy->bands[NL80211_BAND_5GHZ] = band;
> }
> }
> - err = brcmf_setup_wiphybands(wiphy);
> - return err;
> + return 0;
> }
>
> static s32 brcmf_config_dongle(struct brcmf_cfg80211_info *cfg)
> @@ -6843,6 +6842,12 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
> goto priv_out;
> }
>
> + err = brcmf_setup_wiphybands(wiphy);
> + if (err) {
> + brcmf_err("Setting wiphy bands failed (%d)\n", err);
> + goto wiphy_unreg_out;
> + }
> +
> /* If cfg80211 didn't disable 40MHz HT CAP in wiphy_register(),
> * setup 40MHz in 2GHz band and enable OBSS scanning.
> */
>
^ permalink raw reply
* Re: [PATCH 2/2] brcmfmac: setup wiphy bands after registering it first
From: Rafał Miłecki @ 2017-01-08 15:03 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Rafał Miłecki
In-Reply-To: <117c6355-a612-1797-a1ae-225f68543568@broadcom.com>
On 8 January 2017 at 14:00, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 7-1-2017 21:36, Rafa=C5=82 Mi=C5=82ecki wrote:
>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>
>> During bands setup we disable all channels that firmware doesn't support
>> in the current regulatory setup. If we do this before wiphy_register
>> it will result in copying set flags (including IEEE80211_CHAN_DISABLED)
>> to the orig_flags which is supposed to be persistent. We don't want this
>> as regulatory change may result in enabling some channels. We shouldn't
>> mess with orig_flags then (by changing them or ignoring them) so it's
>> better to just take care of their proper values.
>>
>> This patch cleanups code a bit (by taking orig_flags more seriously) and
>> allows further improvements like disabling really unavailable channels.
>> We will need that e.g. if some frequencies should be disabled for good
>> due to hardware setup (design).
>
> I think this and previous patch are too dependent and prefer to have
> them in a single patch. Despite that for both:
>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
This time to make sure I can be easily understood I decided to use two
smaller patches & describe each of them with all the details that came
to my mind. I also made sure (and described that) that applying only
1/2 won't break anything (we never wan't to break potential bisecting
process).
I can work on merging (squashing) these 2 patches but then I need to
rework commit messages & I'll risk someone will say my description
isn't clear enough or my patch is too complex...
If there isn't a real problem (and maybe having 2 patches makes
following changes more easily) maybe let's stick to this patchset?
--=20
Rafa=C5=82
^ permalink raw reply
* Searching new home for ath[59]k-devel mailing lists
From: Michael Renzmann @ 2017-01-08 17:15 UTC (permalink / raw)
To: linux-wireless; +Cc: ath5k-devel, ath9k-devel
Hi all.
Out of history, the ath5k-devel and ath9k-devel mailing lists have been
and still are hosted on the mailing list server of the MadWifi project. I
intend to shut the server down, and thus I'm searching a new loving home
for the lists.
Besides a new home the lists also need some attention - both would receive
a fair amount of spam, and thus they need someone who takes care of some
kind of moderating posts and/or filtering spam.
To be honest, I've not been following things at all for many months. From
what I can tell it seems that ath5k-devel is pretty quiet. ath9k-devel,
however, still sees a fair amount of communication; but I didn't look at
how much of that traffic actually took place here on linux-wireless, just
CC'ing ath9k-devel.
This is to say, if there is a broad agreement that one of the lists or
both of them are no longer required, I'm fine with just closing them in an
ordered fashion.
I'm looking forward for your suggestions. Please keep me CC'ed, as I'm not
subscribed to linux-wireless.
Bye, Mike
^ permalink raw reply
* Re: [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Geoff Lansberry @ 2017-01-08 22:32 UTC (permalink / raw)
To: Mark Greer
Cc: linux-wireless, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, robh+dt, mark.rutland, netdev, devicetree,
linux-kernel, Justin Bronder, Jaret Cantu
In-Reply-To: <20170103212136.GA9899@animalcreek.com>
On Tue, Jan 3, 2017 at 4:21 PM, Mark Greer <mgreer@animalcreek.com> wrote:
> On Tue, Jan 03, 2017 at 01:35:18PM -0500, Geoff Lansberry wrote:
>> On Tue, Jan 3, 2017 at 11:33 AM, Mark Greer <mgreer@animalcreek.com> wrote:
>> > On Tue, Dec 27, 2016 at 09:18:32AM -0500, Geoff Lansberry wrote:
>
>> >> In the meantime - here is some more info about how we use it.
>> >>
>> >> We do use NFC structures. I did find an interesting clue in that
>> >> there are certain bottles that cause neard to segfault, I'm not sure
>> >> what is different about them. We write a string, like
>> >> "coppola_chardonnay_2015" to the bottles.
>> >
>> > Off the top of my head, it could be the length of the text.
>> > It would be useful to compare the data that works to the data
>> > that doesn't work. Can you install NXP's 'TagInfo' app on a
>> > smartphone and scan tags with working & non-working data?
>> > You can email the data from the app to yourself, edit out
>> > the cruft, and share here.
>>
>> The data is always the same - and the tags are all the same. Only
>> difference is that the tag is physically different, and perhaps
>> orientation; distance from antenna to tag is fixed.
>
> Interesting... They're all type 2 tags, right?
Yes type 2.
>
>> I can't even
>> write the tags at all, so reading them will show blank. Also a minor
>> but significant detail, is that the tags are embedded in such a way
>> that the phone cannot get close enough to them to connect.
>
> This section had me completely confused for a couple minutes until I realized
> that you mean that you can read & write the tags using the trf7970a with
> an attached antenna but not with your phone. Is that correct?
Correct, due to the physical arrangement of the part the tag is embedded in.
>
> If so, try a tag that isn't embedded in something else and move it around
> the back of the phone. Try to find where it works best. The phone
> manufacturers are notorius for paying little attention to the NFC antenna
> they put on their products. For example, I have a Samsung S5 next to me
> and it seems to work best around the center of the phone. I've used others
> where I had to use the upper-left or upper-right corner of the phone.
I can borrow a phone and try, I do have some other tags. This will
take me some time and
I'm not optimistic that we will learn much, other than that the tag
was not programmed when
it does not work. Don't wait on this answer.
>
> Mark
> --
^ permalink raw reply
* [PATCH] nfc: don't be making arch specific unaligned decisions at driver level.
From: Paul Gortmaker @ 2017-01-09 0:19 UTC (permalink / raw)
To: linux-kernel
Cc: Paul Gortmaker, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, Tony Luck, Fenghua Yu, linux-ia64, linux-wireless
Currently ia64 fails building allmodconfig with variations of:
In file included from drivers/nfc/nxp-nci/i2c.c:39:0:
./include/linux/unaligned/access_ok.h:62:29: error: redefinition of ‘put_unaligned_be64’
static __always_inline void put_unaligned_be64(u64 val, void *p)
^~~~~~~~~~~~~~~~~~
In file included from ./arch/ia64/include/asm/unaligned.h:5:0,
from ./arch/ia64/include/asm/io.h:22,
from ./arch/ia64/include/asm/smp.h:20,
from ./include/linux/smp.h:59,
from ./include/linux/topology.h:33,
from ./include/linux/gfp.h:8,
from ./include/linux/slab.h:14,
from ./include/linux/resource_ext.h:19,
from ./include/linux/acpi.h:26,
from drivers/nfc/nxp-nci/i2c.c:28:
./include/linux/unaligned/be_byteshift.h:65:20: note: previous definition of ‘put_unaligned_be64’ was here
static inline void put_unaligned_be64(u64 val, void *p)
^~~~~~~~~~~~~~~~~~
scripts/Makefile.build:293: recipe for target 'drivers/nfc/nxp-nci/i2c.o' failed
The easiest explanation for this is to look at the non-arch users in
the following output:
linux$git grep include.*access_ok.h
arch/arm64/crypto/crc32-arm64.c:#include <linux/unaligned/access_ok.h>
arch/cris/include/asm/unaligned.h:#include <linux/unaligned/access_ok.h>
arch/m68k/include/asm/unaligned.h:#include <linux/unaligned/access_ok.h>
arch/mn10300/include/asm/unaligned.h:#include <linux/unaligned/access_ok.h>
arch/powerpc/include/asm/unaligned.h:#include <linux/unaligned/access_ok.h>
arch/s390/include/asm/unaligned.h:#include <linux/unaligned/access_ok.h>
arch/x86/include/asm/unaligned.h:#include <linux/unaligned/access_ok.h>
drivers/nfc/nfcmrvl/fw_dnld.c:#include <linux/unaligned/access_ok.h>
drivers/nfc/nxp-nci/firmware.c:#include <linux/unaligned/access_ok.h>
drivers/nfc/nxp-nci/i2c.c:#include <linux/unaligned/access_ok.h>
include/asm-generic/unaligned.h:# include <linux/unaligned/access_ok.h>
Note that nfc is essentially the only non-arch user in the above.
When it forces use of access_ok.h, it will break any arch that has
already selected be_byteshift.h (or other conflicting implementations)
at the arch level.
The decision of what variant for unaligned access to use needs to be
left to the arch level and not used at the driver level. Delete the
errant includes, as the right ones will be pulled in at the arch
level, giving us just the one definition that is needed.
See commit 064106a91be5 ("kernel: add common infrastructure for
unaligned access") as a reference.
Cc: Lauro Ramos Venancio <lauro.venancio@openbossa.org>
Cc: Aloisio Almeida Jr <aloisio.almeida@openbossa.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/drivers/nfc/nfcmrvl/fw_dnld.c b/drivers/nfc/nfcmrvl/fw_dnld.c
index f8dcdf4b24f6..32144d66ba88 100644
--- a/drivers/nfc/nfcmrvl/fw_dnld.c
+++ b/drivers/nfc/nfcmrvl/fw_dnld.c
@@ -17,7 +17,6 @@
*/
#include <linux/module.h>
-#include <linux/unaligned/access_ok.h>
#include <linux/firmware.h>
#include <linux/nfc.h>
#include <net/nfc/nci.h>
diff --git a/drivers/nfc/nxp-nci/firmware.c b/drivers/nfc/nxp-nci/firmware.c
index 5291797324ba..f2bd651fc60d 100644
--- a/drivers/nfc/nxp-nci/firmware.c
+++ b/drivers/nfc/nxp-nci/firmware.c
@@ -24,7 +24,6 @@
#include <linux/completion.h>
#include <linux/firmware.h>
#include <linux/nfc.h>
-#include <linux/unaligned/access_ok.h>
#include "nxp-nci.h"
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 36099e557730..d25f6257458e 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -36,7 +36,6 @@
#include <linux/of_gpio.h>
#include <linux/of_irq.h>
#include <linux/platform_data/nxp-nci.h>
-#include <linux/unaligned/access_ok.h>
#include <net/nfc/nfc.h>
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox